Проектирование информационных систем в среде Rational Rose

ВВЕДЕНИЕ

 

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

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

Для успешной реализации проекта объект проектирования «Приемное отделение стационара» должен быть прежде всего адекватно реализован в программной среде Rational Rose, должны быть построены полные и непротиворечивые функциональные и информационные модели ИС. При этом нашими задачами являются:

1. Построение use-case диаграммы
2. Построение sequence диаграмм
3. Построение диаграммы классов
4. Построение диаграммы сотрудничества

Построение визуальных моделей  позволяет решить сразу несколько  типичных проблем. Во-первых, и это  главное, технология визуального моделирования, позволяет работать со сложными и очень сложными системами и проектами. И не важно, преобладает ли в проекте "техническая сложность" (статическая) или "динамическая сложность управления". Также одним из достоинств этого программного продукта будет возможность использования диаграмм на языке UML. Можно сказать, что Rational Rose является графическим редактором UML диаграмм.

Унифицированный Язык Моделирования (UML):

- не зависит от объектно-ориентированных (ОО) языков программирования,

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

- может поддерживать любой ОО язык программирования.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

 

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

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

1.1 Проблемы предметной области.

 

После проведения исследования предметной области были выявлены следующие проблемы:

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2 ПОСТАНОВКА ЗАДАЧ ПРОЕКТИРОВАНИЯ

 

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

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

Основные задачи приемного отделения:

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

Для решения этих задач отделение должно выполнять следующие функции:

1. регистрация поступающих больных (обработка на компьютере);
2. врачебный осмотр и диагностика;
3. оформление учетной медицинской документации;

          В приемном отделении стационара имеется:

• Приемный покой, где непосредственно осуществляется прием больного в стационар. Здесь находится стол, компьютерная техника, весы, ростомер.
• Кабинет приема врача – здесь оказывает неотложную помощь ЛОР врач, травматолог и другие.
• Диагностическая палата –в диагностической палате врач осматривает пациентов, заполняет историю болезни. Здесь же находятся больные, для уточнения диагноза.
• Санитарная комната – комната предназначенная для нужд персонала и пациентов.

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

Разрабатываемая система является автоматизированной информационной системой «Приемного отделения стационара» и решает задачу автоматизации основных операций в деятельности оператора отвечающего за оформление записей на прием к врачам.

При создании нового врача оператор вносит в БД всю информацию о нем, которая включает:

1. Фамилию врача;
2. Имя врача;
3. Отчество врача;
4. Специализация врача;
5. Номер кабинета;
6. Время приема.

При оформлении нового пациента работник регистратуры вносит в БД всю информацию о нем, которая включает:

1. Фамилия пациента;
2. Имя пациента;
3. Отчество пациента;

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3 ОПИСАНИЕ ДИАГРАММ

 

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

 

1. Диаграмма использования (Use-case диаграмма)

 

Каждая такая диаграмма или, как ее обычно называют, каждый Use case – это описание сценария поведения, которому следуют действующие лица (Actors). Диаграмма вариантов использования описывает функциональное назначение системы, то есть то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.

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

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

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

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

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

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

Помимо актеров и вариантов использования, на данной диаграмме возможно расположить:

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

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

Отношения – описывающие взаимодействия экземпляров одних актеров и вариантов использования с экземплярами других актеров и вариантов. В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования.

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

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

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