Разработка информационной системы 'Больница'

Пояснительная записка к курсовой работе

по дисциплине

Разработка и эксплуатация автоматизированных информационных систем

Тема

Разработка информационной системы «Больница»

Введение

В данной курсовой работе была разработана информационная система «Больница» посредствам прикладных программ, Erwin, и Microsoft Office Access, объединяющих между собой реализацию схем потоков данных, их зависимость друг от друга. Проект основан на автоматизации рутинных процессов повышающих эффективность работы больниц.

Цель курсовой работы - разработать информационную систему «Больница». Предмет курсовой работы - больница.

Объект исследования - работа больницы. В соответствии с поставленной цели, определены следующие задачи:

. Провести анализ рынка информационных систем, позволяющих автоматизировать работу больницы.

. Провести анализ предметной области «Больница»

. Построить диаграмму бизнес-процессов предметной области.

. Построить ЕR-модель предметной области.

. Создать информационную систему в выбранной СУБД.

1. Описание предметной области. Постановка задачи

Базу данных использует для работы коллектив врачей. В таблицы должны быть занесены имя, пол, дата рождения, телефон и домашний адрес каждого из пациентов. Всякий раз, когда врач осматривает больного (пришедшего на прием или на дому), фиксируется дата и место проведения осмотра, симптомы, диагноз и предписания больному, проставляется имя пациента и имя врача. Если врач прописывает больному какое-либо лекарство, в таблицу заносится название лекарства, способ его приема, словесное описание предполагаемого действия и возможных побочных эффектов.

Составить тексты запросов, определяющих:

) фамилии и инициалы пациентов, имеющих не менее трех сходных симптомов болезни, а также предполагаемые диагнозы;

) фамилии и инициалы пациентов, принятых в указанный диапазон дат каждым врачом центра;

) количество пациентов, принятых каждым врачом центра на дому;

) данные по распределению больных, принятых центром в текущем году, по возрастному составу;

) все виды диагнозов, поставленных врачами центра по любым двум симптомам (по выбору обучаемого).

. Выбор средств/методологии проектирования. Выбор СУБД

Под средствами проектирования информационных систем (СП ИС) будем понимать комплекс инструментальных средств, обеспечивающих в рамках выбранной методологии проектирования поддержку полного жизненного цикла (ЖЦ) ИС, который включает в себя, как правило, стратегическое планирование, анализ, проектирование, реализацию, внедрение и эксплуатацию. Каждый этап характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. При анализе СП их следует рассматривать не локально, а в комплексе, что позволяет реально охарактеризовать их достоинства, недостатки и место в общем технологическом цикле создания ИС.

Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности ИС, создаваемых в различных областях экономики.

Критерии выбора

Традиционно при обсуждении проблемы выбора СП (в особенности CASE-средств) большое внимание уделялось особенностям реализации той или иной методологии анализа предметной области (E-R, IDEF0, IDEF1Х, Gane/Sarson, Yordon, Barker и др.). Безусловно, богатство изобразительных и описательных средств дает возможность на этапах стратегического планирования и анализа построить наиболее полную и адекватную модель предметной области. С другой стороны, если говорить о конечных результатах - базах данных и приложениях, то обнаруживается, что часть описаний в них практически не отражается, оставаясь чисто декларативной (на выходе мы в любом случае получим описание БД в табличном представлении с минимальным набором ограничений целостности и исполнимый код приложений, большую часть которых составляют экранные формы, не выводимые непосредственно из моделей предметной области). Опытные аналитики и проектировщики всегда с большими или меньшими трудозатратами придут к нужному конечному результату независимо от того, какая конкретно методология или ее разновидность реализована в данном инструменте. Это, конечно, не означает, что методология не важна, напротив, отсутствие или неполнота описательных средств могут с самого начала значительно затруднить работу над проектом. Однако, зачастую на первом плане оказываются другие критерии, невыполнение которых может породить гораздо большие трудности.

Может создаться впечатление, что если можно сформировать необходимую аппаратную платформу из компонентов различных фирм-производителей, то так же просто можно выбрать и скомплексировать разные инструментальные средства, каждое из которых является одним из мировых лидеров в своем классе. Однако в случае инструментальных средств в настоящее время, в отличие от оборудования, отсутствуют международные стандарты на основные свойства конечных продуктов (программ, баз данных и их сопряжение). Однако, поскольку составные части проекта должны быть интегрированы в единый продукт, следовательно, имеет смысл рассматривать не любые, а только сопряженные инструментальные средства, которые в принципе могут быть ориентированы - даже внутри одного класса на разные методологии; при этом необходимо отбирать в состав комплекса СП средства, поддерживающие по крайней мере близкие методологии, если не одну и ту же.

Исходя из перечисленных выше соображений, примем в качестве основных критериев выбора СП следующие критерии:

Поддержка полного жизненного цикла ИС с обеспечением эволюционности ее развития.

Для существующих ИС должен обеспечиваться плавный переход из старой среды эксплуатации в новую с минимальными переделками и поддержкой эксплуатируемых баз данных и приложений, внедренных до начала работ по созданию новой системы.

Обеспечение целостности проекта и контроля за его состоянием.

Данное требование означает наличие единой технологической среды создания, сопровождения и развития ИС, а также целостность базы проектных данных (репозитория). Единая технологическая среда должна обеспечиваться за счет использования единственной CASE-системы для поддержки моделей ИС, а также за счет наличия программно-технологических интерфейсов между отдельными инструментальными средствами, сертифицированных и поддерживаемых фирмами- разработчиками соответствующих средств. В частности, интерфейс между CASE-системой и средствами разработки приложений должен выполнять две основные функции:

а) непосредственный переход в рамках единой среды от описания логики приложения, реализованного CASE-системой, к разработке пользовательского интерфейса (экранных форм);

б) перенос описания БД из репозитория CASE-системы в репозиторий средства разработки приложений и обратно.

Вся информация о проекте должна автоматически помещаться в базу проектных данных, при этом должны поддерживаться согласованность, непротиворечивость, полнота и минимальная избыточность проекта, а также корректность операций его редактирования. Это может быть достигнуто при условии исключения или существенного ограничения возможности актуализации репозитория различными средствами. Должны также обеспечиваться возможности для централизованного сбора, хранения и распределения информации между различными этапами проекта, группами разработчиков и выполняемыми операциями. Поддержка базы проектных данных может быть реализована собственными средствами СП или средствами целевой СУБД (второй вариант предпочтительнее, поскольку упрощается технология ведения репозитория).

Невыполнение требования целостности в условиях разобщенности разработчиков и временной протяженности крупного проекта может означать утрату контроля за его состоянием.

Независимость от программно-аппаратной платформы и СУБД.

Требование определяется неоднородностью среды функционирования ИС. Такая независимость может иметь две составляющих: независимость среды разработки и независимость среды эксплуатации приложений. Она обеспечивается за счет наличия совместимых версий СП для различных платформ и драйверов соответствующих сетевых протоколов, менеджеров транзакций и СУБД.

Один из дополнительных факторов, который при этом следует учитывать - это способ взаимодействия с СУБД (прямой или через ODBC), поскольку использование ODBC может заметно ухудшить производительность и надежность интерфейса.

Поддержка одновременной работы групп разработчиков.

Развитые СП должны обладать возможностями разделения полномочий персонала разработчиков и объединения отдельных работ в общий проект. Должна обеспечиваться одновременная работа проектировщиков БД и разработчиков приложений (разработчики приложений в такой ситуации могут начинать работу с базой данных, не дожидаясь полного завершения ее проектирования CASE-средствами). При этом все группы специалистов должны быть обеспечены адекватным инструментарием, а внесение изменений в проект различными разработчиками должно быть согласованным и корректным. Каждый разработчик должен иметь возможность работы со своим личным репозиторием, являющимся фрагментом или копией общего репозитория. Должны обеспечиваться содержательная интеграция всех изменений, вносимых разработчиками, в общем репозитории, одновременная доступность для разработчика общего и личного репозиториев и простота переноса объектов между ними.
Помимо перечисленных основных критериев, предварительный анализ при выборе СП должен учитывать следующие аспекты:

Возможность разработки приложений "клиент-сервер" требуемой конфигурации.

Подразумевается сочетание наличия развитой графической среды разработки приложений (многооконность, разнообразие стандартных графических объектов, разнообразие используемых шрифтов и т.д.) с возможностью декомпозиции (partitioning) приложения на "клиентскую" часть, реализующую пользовательский экранный интерфейс и "серверную" часть. При этом должна обеспечиваться возможность перемещения отдельных компонентов приложения между "клиентом" и "сервером" на наиболее подходящую платформу, обеспечивающую максимальную эффективность функционирования приложения в целом, а также возможность использования сервера приложений (менеджера транзакций).

Открытая архитектура и возможности экспорта/импорта.

Открытая и общедоступная информация об используемых форматах данных и прикладных программных интерфейсах должна позволять интегрировать инструментальные средства третьих фирм и относительно безболезненно переходить от одной системы к другой. Возможности экспорта/импорта означают, что спецификации, полученные на этапах анализа, проектирования и реализации для одной ИС, могут быть использованы для проектирования другой ИС. Повторное проектирование и реализация могут быть обеспечены при помощи средств экспорта/импорта спецификаций в различные СП.

Качество технической поддержки в России, стоимость приобретения и поддержки, опыт успешного использования.

Имеется в виду наличие квалифицированных дистрибьюторов и консультантов, быстрота обслуживания пользователей, высокое качество технической поддержки и обучения продукту и методологии его применения для больших коллективов разработчиков (наличие сведений о практике использования системы, качество документации, укомплектованность примерами и обучающими курсами, наличие прототипных проектов). Затраты на обучение новым технологиям значительны, однако потери от использования современных сложных технологий необученными специалистами могут оказаться значительно выше.

Кроме того, фирмы-поставщики инструментальных средств должны быть устойчивыми, так как технология выбирается не на один год, а также должны обеспечивать хорошую поддержку на территории России (горячая линия, консультации, обучение, консалтинг), возможно, через дистрибьюторов. Что касается стоимости, следует учитывать возможность получения бесплатной пробной лицензии (trial license), стоимость лицензии на одно рабочее место СП, скидки, предоставляемые фирмой в случае приобретения большого количества лицензий, необходимость приобретения run-time версий для эксплуатации приложений и т.д. В то же время стоимость продукта должна рассматриваться не сама по себе, а с учетом ее соответствия возможностям продукта.

Простота использования.

Учитываются следующие характеристики:

§ доступность пользовательского интерфейса;

§  время, необходимое для обучения;

§  простота инсталляции;

§  качество документации.

Обеспечение качества проектной документации.

Это требование относится к возможностям СП анализировать и проверять описания и документацию на полноту и непротиворечивость, а также на соответствие принятым в данной методологии стандартам и правилам (включая ГОСТ, ЕСПД). В результате анализа должна формироваться информация, указывающая на имеющиеся противоречия или неполноту в проектной документации. Должна быть также обеспечена возможность создавать новые формы документов, определяемые пользователями.

Использование общепринятых, стандартных нотаций и соглашений.

Для того, чтобы проект мог выполняться разными коллективами разработчиков, необходимо использование стандартных методов моделирования и стандартных нотаций, которые должны быть оформлены в виде нормативов до начала процесса проектирования. Несоблюдение данного требования ставит разработчиков в зависимость от фирмы-производителя данного средства, делает затруднительным формальный контроль корректности используемых нотаций и снижает возможности привлечения дополнительных коллективов разработчиков, поскольку число специалистов, знакомых с данным методом (нотацией) может быть ограниченным.

В идеальном случае (что, конечно же, далеко не всегда возможно) окончательный выбор может быть произведен по результатам тестирования в соответствии с заданным планом, которое должно включать имитацию проектирования реальной БД и разработки приложений и состоять из следующих шагов:

§ установка и конфигурирование (ясность и точность инструкций по установке, наличие подсказок в процессе установки, возможность установки по выбору и задания многопользовательской конфигурации);

§  разработка концептуальной схемы БД (понятность и простота построения, модификации и документирования различных элементов диаграмм "сущность-связь", отображение ограничений ссылочной целостности и бизнес- правил, управление режимом отображения);

§  формирование отчета о концептуальной схеме (список сущностей с определениями и атрибутами, включая указание ключей, список атрибутов, сгруппированных по сущностям, список связей между сущностями, возможность форматирования отчета, составления отчета по выделенной части схемы, передачи отчета, например, в другие приложения (текстовые процессоры));

§  разработка графической схемы БД для конкретной СУБД с учетом специфичных для нее структур данных и ограничений (выбор целевой СУБД и реализация элементов схемы - ввод и модификация имен таблиц и столбцов, определение типов данных, доменов, индексов, значений по умолчанию и неопределенных значений, порядка индексирования, а также задание ограничений ссылочной целостности и дополнительных бизнес-правил, характеризующих предметную область, управление триггерами и хранимыми процедурами);

§ формирование отчета о схеме БД (печать диаграммы схемы, списка таблиц с соответствующими столбцами, первичными ключами, индексами и т.д., возможность форматирования отчета, составления отчета по выделенной части схемы, передачи отчета в другие приложения);

§  генерация схемы БД (трансформация схемы БД в файл DDL в текстовом формате или непосредственный интерфейс с целевой СУБД);

§  разработка простейшего приложения (описание экранных форм, программирование или описание логики приложения и интерфейса с БД, загрузка БД тестовыми данными и тестирование приложения);

§  сопровождение схем БД (внесение изменений - создание новых сущностей и атрибутов, изменение схемы БД, повторная генерация схемы, управление версиями, обеспечение сохранности данных, синхронизация концептуальной схемы и самой БД);

§  обратное проектирование - реинжиниринг (полное и точное восстановление исходной концептуальной схемы по файлам DDL или непосредственно из словаря целевой СУБД).

В результате выполненного анализа может оказаться, что ни одно доступное средство не удовлетворяет в нужной мере всем основным критериям и не покрывает все потребности проекта. В этом случае может применяться набор средств, позволяющий построить на их базе единую технологическую среду.Access является настольной СУБД реляционного типа, которая имеет все необходимые средства для выполнения перечисленных выше функций. Достоинством Access является то, что она имеет очень простой графический интерфейс, который позволяет не только создавать собственную базу данных, но и разрабатывать простые и сложные приложения.

В отличие от других настольных СУБД, Access хранит все данные в одном файле, хотя и распределяет их по разным таблицам. Вы можете создать сколько угодно таблиц , используя те правила, которые были описаны выше. Самым важным правилом, которое необходимо соблюдать, является то, что в базе данных нужно хранить только необходимую информацию, и при этом все данные должны храниться только в одном месте.

3. Построение бизнес-процессов информационной системы

база физический данные интерфейс

Блок А0 представляет собой всю систему в целом. В данной схеме обработке подвергается информация о пациентах и врачах. Результатом является диагноз и назначение лекарств.

Рисунок 1. Блок А0.

Основные процессы системы:

• Блок А1 - учет пациентов. В этом блоке происходит запись пациента в базу.

• Блок А2 - учет приема. В этом блоке производятся прием заявки от пациента и прием у врача.

• Блок А3 - обследование. В этом блоке пациент обследуется, для выяснения более точного диагноза.

Рисунок 2. Блок А1, А2, А3

Декомпозиция блока А2:

• Блок А21 - прием заявки от пациента. Пациент звонит или приходит в больницу для записи на прием

• Блок А22 - прием у врача. Пациент приходит в назначенное время к врачу для назначения обследования.

Рисунок 3. Блок А21, А22

4. Построение инфологической (концептуальной) модели предметной области

В результате построения инфологической (концептуальной) модели предметной области было создано 6 сущностей.

Рисунок 4. Инфологическая модель ИС

5. Проектирование логической структуры базы данных

Рисунок 5. Логическая модель ИС

6. Проектирование физической структуры базы данных

В результате Проектирование физической структуры базы данных было создано 6 таблиц:

§ Врачи

§  Лекарства

§  Места

§  Назначения

§  Пациенты

§  Прием

Рисунок 6. Таблица «Врачи» в режиме Просмотра

Рисунок 7. Таблица «Врачи» в режиме Конструктора

Рисунок 8. Таблица «Лекарства» в режиме Просмотра

Рисунок 9. Таблица «Лекарства» в режиме Конструктора

Рисунок 10. Таблица «Места» в режиме Просмотра

Рисунок 11. Таблица «Места» в режиме Конструктора.

Рисунок 12. Таблица «Назначения» в режиме Просмотра

Рисунок 13. Таблица «Назначения» в режиме Конструктора

Рисунок 14. Таблица «Пациенты» в режиме Просмотра

Рисунок 15. Таблица «Пациенты» в режиме Конструктора

Рисунок 16. Таблица «Прием» в режиме Просмотра

Рисунок 17. Таблица «Прием» в режиме Конструктора

. Организация ввода данных

Форма «Прием» содержит информацию о приеме: ФИО врача, информации о приеме, назначенных лекарствах.

Рисунок 18. Форма «Прием» в режиме Просмотра

Форма «Врачи» содержит информацию о врачах: ФИО врача, информация о приемах.

Рисунок 19. Форма «Врачи» в режиме Просмотра

Форма «Лекарства» содержит информацию о лекарствах: название, действие, способ приема, побочное действие и информация о том кому это лекарство прописали.

Рисунок 20. Форма «Лекарства» в режиме Просмотра

Форма «Места» содержит информацию о местах: название и информация о приеме в этом месте.

Рисунок 21. Форма «Места» в режиме Просмотра.

Форма «Пациенты» содержит информацию о пациентах: ФИО пациента, пол, телефон, дата рождения, домашний адрес и информация о приемах этого пациента.

Рисунок 22. Форма «Пациенты» в режиме Просмотра

8. Организация поиска данных

Запрос «Возраст» содержит данные по распределению больных, принятых центром в текущем году, по возрастному составу

Рисунок 23. Запрос «Возраст» в режиме Конструктора.

Запрос «Диагноз» содержит все виды диагнозов, поставленных врачами центра по симптомам «температура» и любым диагнозам, содержащим «боль»

Рисунок 24. Запрос «Диагноз» в режиме Конструктора.

Рисунок 25. Запрос «Диапазон дат» в режиме Конструктора.

Запрос «На дому» содержит количество пациентов, принятых каждым врачом центра на дому.

Рисунок 26. Запрос «На дому» в режиме Конструктора

9. Описание отчетов информационной системы

Отчет «Возраст» содержит данные из запроса «Возраст»

Рисунок 27. Отчет «Возраст» в режиме просмотра

Отчет «Диагноз» содержит данные из запроса «Диагноз»

Рисунок 28. Отчет «Диагноз» в режиме просмотра

Отчет «Диапазон дат» содержит данные из запроса «Диапазон дат»

Рисунок 29. Отчет «Диапазон дат» в режиме просмотра

Отчет «На дому» содержит данные из запроса «На дому»

Рисунок 30. Отчет «На дому» в режиме просмотра

10. Разработка интерфейса

При запуске информационной системы загружается информационное меню изображенное на рисунке 31, которое позволяет получить доступ ко всем данным системы.

Рисунок 31. Главная кнопочная форма

Для того чтобы добавить данные в формы, нужно нажать кнопку «Добавить данные». Для того чтобы изменить формы, нужно нажать кнопку «Изменить данные».

Для того чтобы просмотреть отчеты по запросам, нужно нажать на кнопку «Просмотреть отчеты».

В форме «Ввод данных» и «Изменение данных» можно открыть формы: «Места», «Пациенты», «Лекарства», «Прием», «Врачи»

В форме «Просмотр отчетов» можно просмотреть отчеты : «Дапазон дат», «На дому», «Возраст», «Диагнозы».

Рисунок 32. Форма ввода данных

Рисунок 33. Форма изменения данных

Рисунок 34. Форма просмотра отчетов

Заключение

В результате проделанной работы выполнились следующие задачи:

• Проведен анализ рынка информационных систем, позволяющих автоматизировать работу магазина автозапчастей;

• Проведен анализ предметной области «Больница» ;

• Построена диаграмму бизнес-процессов предметной области ;

• Построена ЕR-модель предметной области;

• Создана информационная системы в СУБД Access предназначенная для автоматизации работы.

Список используемых источников

1.     Методические рекомендации по выполнению курсового проекта для очного и заочного отделения: «Разработка и эксплуатация автоматизированных информационных систем».

2.      Информационные системы Голицына О.Л., Максимов Н.В., Попов И.И.: учебное пособие. Москва: ФОРУМ: ИНФРА-М, 2014г. 496 стр.

.        Разработка и эксплуатация автоматизированных информационных систем Гагарина Л.Г., Киселев Д.В., Федотова Е.Л.: учеб. Пособие / Под ред. Проф. Л.Г.Гагариной. Москва: ИД «Форум»: ИНФРА-М, 2009г. 384 стр.

.        Информационные технологии в профессиональной деятельности. Михеев Е.В. Москва: ТК Велби, Проспект, 2007г. 448стр.

.        Фуфаев Э.В. Разработка и эксплуатация удаленных баз данных, Москва: Издательский центр «Академия» 2010г. 256 стр.

.        Информатика и компьютерные технологии. Автор: А. Я. Фридланд, Л. С. Ханамирова, И. А. Фридланд Москва: АСТ, Астрель 2003г. 272 стр.

.        Разработка клиент-серверных приложений в Delphi. Автор: Шкрыль А.А. Санкт - Петербург: БХВ - Петербург 2009г. 474 стр.

.        Основы многопоточного, параллельного и распределенного программирования Автор: Грегори Р. Эндрюс, Москва: Вильямс 2003г. 512 стр.

.        Объектно-ориентированный анализ и проектирование систем Автор: Эдвард Йордон, Карл Аргила Москва: Лори 2007г. 264 стр.