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

Федеральное агентство по образованию  Российской Федерации

Государственное образовательное  учреждение высшего профессионального  образования

«Южно-Уральский государственный  университет»

Факультет «Экономика и управление»

Кафедра «Информатика»

 

 

 

 

 

 

Разработка модели системы автоматизации работы поликлиники

 

 

 

 

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

К КУРСОВОЙ РАБОТЕ

по дисциплине «разработка и  стандартизация»

ЮУрГУ – 080801.07-1927-561 ПЗ КП

 

 

 

 

Нормоконтролер, преподаватель Руководитель, преподаватель

С.Ю.Нестеренко   С.Ю.Нестеренко

_________________ 2011 г. _________________ 2011 г.

 

 

Автор проекта

студент группы ЭиУ-525

Кураченко Е.С.

_________________ 2011 г.

 

 

Проект защищен 

с оценкой

_______________________

_________________ 2011 г.

 

 

 

 

Челябинск 2011

 

АННОТАЦИЯ

 

Кураченко Е.С. Разработка модели системы автоматизации  работы поликлиники– Челябинск: ЮУрГУ, ЭиУ-525, 2011, с, рисунков 11, 4 таблицы, библиографический список - 4 наименований.

 

 

Темой курсового проекта  является разработка модели автоматизации системы обслуживания в поликлинике.

Для выполнения данной задачи необходимо изучить предметную область, построить UML -диаграммы модели, протестировать и оценить характеристики модели системы метриками Чидамбера-Кемерера.

 

Оглавление

 

ВВЕДЕНИЕ

UML (от англ. Unified Modeling Language — унифицированный язык моделирования) – язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна кодогенерация.

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

Преимущества UML

• UML объектно-ориентирован, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных ОО-языках;
• UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
• Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
• UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;
• UML получил широкое распространение и динамично развивается.

 

1 Разработка концептуальной модели системы

1.1 Основные и второстепенные цели создания программного продукта

Основная цель создания программного продукта — автоматизация системы обслуживания в поликлинике.

Второстепенные цели:

- автоматизация ввода информации  о пациентах;

- автоматизация форматирования  отчетов;

-автоматизация работы с историей  болезни;

1.2 Состав пользователей

Пользователями одной системы являются:

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

- врач осуществляет прием больных, формирует историю болезни;

1.3 Интересы групп пользователей

Группа пользователей "Администраторы" заинтересованы в:

• полноте  и актуальности собранных данных;
• ускорении ввода всей необходимой информации в базу данных;
• корректности и согласованности вводимой информации.

Группа пользователей "Врачи" заинтересованы в:

• полноте  и актуальности собранных данных;
• ускорении ввода всей необходимой информации в базу данных;
• корректности и согласованности вводимой информации.

1.4 Разделы программного продукта

Исходя из поставленных целей, а  также интересов пользователей  можно выделить следующие разделы  программы:

1. Модуль приема пациентов;
2. Модуль формирования истории болезни;
3. Модуль учета работы врачей;
4. Модуль регистрации пациентов;
5. Модуль выдачи талонов.

1.5 Диаграмма вариантов использования  (Use case diagram)

Диаграмма прецедентов (англ. use case diagram, диаграмма вариантов использования) — диаграмма, на которой отражены отношения, существующие между актерами и прецедентами.

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

При работе с вариантами использования  важно помнить несколько простых  правил:

• каждый прецедент относится как минимум к одному действующему лицу;
• каждый прецедент имеет инициатора;
• каждый прецедент приводит к соответствующему результату (результату с «бизнес-значением»).

Пример диаграммы использования модели автоматизации работы поликлиники представлен на рисунке 1.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

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

Описание актеров:

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

Администратор – актер, основная деятельность которого состоит в работе с информацией и пациентах, ввод и редактирование данных, выдача талонов.

Описание прецедентов:

Прием больных – данный прецедент  необходим для того, чтобы  врач вводил данные о пациенте, назначал лечение, ставил диагноз.

Формирование истории болезней – прецедент позволяет редактировать и вводить новую информацию в карточке пациента.

Учет работы врачей – данный прецедент доступен только администратору, который позволяет формировать отчеты о работе врачей.

Регистрация – прецедент позволяет осуществлять ввод новой информации о пациентах.

Выдача талонов – данный прецедент необходим для выдачи талонов, при посещении определенного врача.

 

2 Разработка логической  модели системы

1.   Диаграмма деятельности (Activity diagram)

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

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

На рисунке 2 представлена диаграмма  деятельности авторизации, а на рисунке 3 – прием пациента.

 

 

 

 

 

 

 

2.2 Диаграмма состояний

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

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

Данная диаграмма представлена на рисунке 4.

 

 

3. Диаграмма последовательностей (Sequence diagram)

Диаграмма последовательности (англ. sequence diagram) — диаграмма, на которой  показаны взаимодействия объектов, упорядоченные  по времени их проявления. Используется в языке UML.

Основными элементами диаграммы последовательности являются обозначения объектов (прямоугольники), вертикальные линии (англ. lifeline), отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами. На данной диаграмме объекты располагаются слева направо.

В UML диаграмма последовательности имеет как бы два измерения. Первое слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Крайним  слева на диаграмме изображается объект, который является инициатором взаимодействия. Правее изображается другой объект, который непосредственно взаимодействует с первым. Таким образом, все объекты на диаграмме последовательности образуют некоторый порядок, определяемый очередностью или степенью активности объектов при взаимодействии друг с другом.

Вторым измерением диаграммы последовательности является вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует  самая верхняя часть диаграммы. Взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим.

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

На рисунке 6 изображена диаграмма  формирования отчета. В первую очередь  администратор осуществляет запрос в базу данных на получение отчета, после чего ему возвращается результат.

 

 

2.4 Диаграмма классов (Class diagram)

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

Диаграмма классов представлена на рисунке 7. На данной диаграмме представлено взаимодействие классов разрабатываемого программного продукта.

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

 

 

 

Роль

+логин +пароль

 

Врач

+Войти() +История болезни ()

Администратор

+Войти() +Талон() +Отчеты()

История болезней

+дата +лечение +диагноз

+Добавить() +Изменить() +Удалить()

 

Отчеты

+Сформировать() +Удалить()

Талоны

+дата +список врачей

+Выдать()

 

 

 

ВрачФИО

+ФИО +профессия +расписание работы

+Выбрать()

Справочник

+Найти() +Добавить () +Редактировать () +Удалить ()

 
2.5 Диаграмма компонент (Component diagram)

Справочник

+Найти() +Добавить () +Редактировать () +Удалить ()

 
2.5 Диаграмма компонент (Component diagram)

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