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

Размещено на http://www.allbest.ru

72

Размещено на http://www.allbest.ru

СОДЕРЖАНИЕ

Введение

1. Постановка задачи

2. Анализ требований

2.1 Глоссарий проекта

2.2 Описание дополнительных спецификаций

2.3 Создание диаграммы вариантов использования

Анализ системы

3.1 Общая диаграмма классов

3.2 Создание диаграммы последовательности

3.3 Создание кооперативной диаграммы

3.4 Создание диаграммы классов

4. Проектирование системы

Заключение

Список использованной литературы

Введение

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

UML - это язык для визуализации, специфицирования, конструирования и документирования артефактов программных систем.

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

ПОСТАНОВКА ЗАДАЧИ

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

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

При проектировании модели информационной системы должны быть созданы:

диаграмма вариантов использования;

диаграмма последовательности;

кооперативная диаграмма;

диаграмма классов;

2. АНАЛИЗ ТРЕБОВАНИЙ

2.1 ГЛОССАРИЙ ПРОЕКТА

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

2.2 ОПИСАНИЕ ДОПОЛНИТЕЛЬНЫХ СПЕЦИФИКАЦИЙ

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

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

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

Если все ближайшие дни приема конкретного врача оказываются занятыми в то время, когда регистратор начинает запись на прием, то система должна известить его об этом.

Удобство использования. Пользовательский интерфейс должен быть Windows 95/98/2000 - совместимым.

Надежность. Система должна работать 24 часа в день, 7 дней в неделю, время простоя - не более 10%.

Производительность. Система должна поддерживать до 2000 пользователей, одновременно работающих с центральной базой данных, и до 500 пользователей, одновременно работающих с локальными серверами.

2.3 СОЗДАНИЕ ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

Диаграмма вариантов использования определяет поведение системы с точки зрения пользователя.

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

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

Разрабатывая диаграммы вариантов использования нужно придерживаться следующих правил:

не моделировать связи между действующими лицами;

не соединять стрелкой непосредственно два варианта использования;

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

Диаграмма вариантов использования для информационной системы выглядит следующим образом:

Рис.1. Диаграмма вариантов использования

На этой диаграмме несколько действующих лиц:

Пациент - лицо, желающее записать на прием;

Регистратор - лицо, осуществляющее запись на прием;

Врач - лицо, к которому осуществляется запись;

БД пациентов - совокупность данных обо всех элементах системы;

Расчетная система - способ получения информации обо всей системе.

Существует несколько вариантов использования:

Записаться на прием,

Просмотреть базу данных пациентов,

Ввести информацию о пациентах,

Выписать талон,

Закрыть регистрацию,

Получить информацию о пациентах.

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

3. АНАЛИЗ СИСТЕМЫ

3.1 ОБЩАЯ ДИАГРАММА КЛАССОВ

В потоках событий варианта использования были выявлены классы трех типов:

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

классы-сущности (Entity), представляющие собой ключевые абстракции (понятия) разрабатываемой системы: Пациент, расписание, врач, регистратор;

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

3.2 СОЗДАНИЕ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ

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

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

Рис. 2. Диаграмма последовательности - 1

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

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

Рис. 3. Диаграмма последовательности - 2

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

Рис. 4. Диаграмма последовательности - 3

3.3 СОЗДАНИЕ КООПЕРАТИВНОЙ ДИАГРАММЫ

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

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

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

Кооперативная диаграмма для диаграммы последовательности-1.

Рис. 5. Кооперативная диаграмма - 1

Кооперативная диаграмма для диаграммы последовательности-2:

Рис. 6. Кооперативная диаграмма -2

Кооперативная диаграмма для диаграммы последовательности - 3:

Рис. 7. Кооперативная диаграмма - 3

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

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

3.4 СОЗДАНИЕ ДИАГРАММЫ КЛАССОВ

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

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

Рис. 8. Диаграмма классов

информационная система диаграмма класс

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

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

Таким образом, диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними.

4. ПРОЕКТИРОВАНИЕ СИСТЕМЫ

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Вендров А.М. Практикум по проектированию ПО экономических ИС. - М.: Финансы и статистика, 2002.

2. Проектирование информационных систем: Учебное пособие/ Г.С. Федорова; Кафедра проектирования экономических информационных систем. - М.: МЭСИ, 2001. - 142 с.

3. Жданова Е.И., Диязитдинова А.Р. «Проектирование информационных систем», Самара,2009г.

4. Леоненков А.В. «Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose» - Интернет-университет информационных технологий, Бином. Лаборатория знаний, 2006.

Размещено на Allbest.ru