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

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

2

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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ и науки РОССИЙСКОЙ ФЕДЕРАЦИИ

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

КУРГАНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

КУРСОВАЯ РАБОТА

ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ В СРЕДЕ RATIONAL ROSE

Содержание

Введение

1. Описание предметной области

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

2. Постановка задач проектирования

3. Описание диаграмм

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

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

3.3 Диаграмма сотрудничества

3.4 Диаграмма классов

Заключение

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

Приложение А. Диаграмма использования

Приложение Б. Диаграмма использования

Приложение В. Диаграмма использования

Приложение Г. Диаграмма использования

Приложение Д. Диаграмма последовательности

Приложение Е. Диаграмма сотрудничества

Приложение Ж. Диаграмма классов

Введение

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

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

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

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

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

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

Построение use-case диаграммы

Построение sequence диаграмм

Построение диаграммы классов

Построение диаграммы сотрудничества

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

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

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

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

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

1. Описание предметной области

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

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

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

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

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

затраты большого количества временных и человеческих ресурсов на обработку документов и необходимость увеличивать эти ресурсы с ростом количества клиентов;

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

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

при обращении пациента в различные поликлиники сети могут произойти ошибки при передаче сведений;

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

2. Постановка задач проектирования

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

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

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

прием, осмотр и обследование больных, поступающих в приемное отделение.

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

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

оформление и ведение установленной медицинской учетной документации.

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

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

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

врачебный осмотр и диагностика;

оформление учетной медицинской документации;

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

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

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

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

Санитарная комната - комната предназначенная для нужд персонала и пациентов.

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

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

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

Фамилию врача;

Имя врача;

Отчество врача;

Специализация врача;

Номер кабинета;

Время приема.

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

Фамилия пациента;

Имя пациента;

Отчество пациента;

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

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

3. Описание диаграмм

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отношение включения - указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования. Данное отношение является направленным и бинарным.

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

Дважды щелкнуть по пункту Main (Главная диаграмма) в разделе Use Case View (Представление прецедентов) в списке браузера, чтобы открыть диаграмму.

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

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

Чтобы создать коммуникативные ассоциации в программе Rational Rose необходимо:

На панели инструментов щелкнуть по кнопке Association (Ассоциативная связь) или по кнопке Unidirectional Association (Однонаправленная ассоциативная связь). Если нужная кнопка отсутствует нужно щелкнуть правой кнопкой мыши на панели инструментов, в появившемся контекстно-зависимом меню выбрать команду Customize (Настройка), чтобы добавить кнопку.

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

Дает она нам следующее:

В приложении А, Б, В и Г мы видим Use-case диаграмму, которая демонстрирует приемное отделение стационара:

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

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

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

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

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

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

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

Фокус управления - служит для выделения объектов, находящихся в активном состоянии.

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

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

В языке UML могут встречаться несколько разновидностей сообщений:

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

Вторая разновидность сообщения используется для обозначения простого (не вложенного) потока управления. Каждая такая стрелка указывает на прогресс одного шага потока. При этом соответствующие сообщения обычно являются асинхронными.

Для создания новой диаграммы последовательности необходимо щелкнуть правой кнопкой мыши на представлении Вариантов Использования браузера (Use Case View) или Логическом представлении (Logical View). В открывшемся меню выбрать пункт New > Sequence Diagram (Создать > Диаграмма последовательности). Далее ввести название диаграммы, после чего дважды щелкнуть по ней в браузере, чтобы открыть ее.

Для создания новой диаграммы последовательности необходимо щелкнуть правой кнопкой мыши на представлении Вариантов Использования браузера (Use Case View) или Логическом представлении (Logical View). В открывшемся меню выбрать пункт New > Sequence Diagram (Создать > Диаграмма последовательности). Далее ввести название диаграммы, после чего дважды щелкнуть по ней в браузере, чтобы открыть ее.

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

Для добавления нового сообщения объекта самому себе необходимо щелкнуть по кнопке Message to Self на панели Toolbox и щелкнуть по линии жизни объекта.

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

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

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

3.3 Диаграмма сотрудничества

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

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

По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.

Создание новой диаграммы кооперации: для создания новой диаграммы последовательности необходимо щелкнуть правой кнопкой мыши на представлении Вариантов Использования браузера (Use Case View) или Логическом представлении (Logical View). В открывшемся меню выбрать пункт New > Collaboration Diagram (Создать > Диаграмма кооперации). Далее ввести название диаграммы, после чего дважды щелкнуть по ней в браузере, чтобы открыть ее.

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

В окне спецификации для объекта можно задать: имя объекта (Name); класс, экземпляром которого является этот объект (Class), если класса еще нет в проекте, то здесь его можно создать, выбрав в выпадающем списке значение <New>; текстовое описание (Documentation); время жизни объекта (Persistence); является ли этот объект мультиобъектом (Multiple instances). Для добавления новой связи между объектами необходимо щелкнуть по кнопке Object Link на панели Toolbox, щелкнуть по одному объекту и не отпуская кнопку перетащить линию на другой объект.

Для добавления связи объекта с самим собой необходимо щелкнуть по кнопке Link To Self на панели Toolbox и щелкнуть по объекту.

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

3.4 Диаграмма классов

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

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

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

Кроме внутреннего устройства или структуры классов, на соответствующей диаграмме указываются различные отношения между классами. Базовыми отношениями или связями в языке UML являются:

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

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

Отношение обобщения - отношение между более общим элементом (родителем или предком) и более частным и специальным элементом (дочерним или потомком).

Программа Rational Rose автоматически создает главную диаграмму классов в логическом представлении модели.

Чтобы добавить пакеты к главной диаграмме классов нужно дважды щелкнуть по пункту списка Main Diagram (Главная диаграмма) в браузере, чтобы открыть диаграмму, а затем, выбрав нужный пакет, перетащить его на диаграмму.

Для создания главной диаграммы класса пакета в программе Rational Rose необходимо дважды щелкнуть по изображению пакета на диаграмме классов. После того, как пакет откроется, появится главная диаграмма классов. Для добавления классов, необходимо выбрать нужный класс и перетащить его с помощью мыши на диаграмму. Для отображения стереотипа класса на диаграмме можно воспользоваться командой Format > Stereotype Display (Формат > Показать стереотип).

Для установки/сброса видимости класса нужно установить/сбросить флажок Show Visibility (Показать видимость) на вкладке Diagram контекстно-зависимого меню Options (для конкретного класса) или меню Tools > Options (для отображения всех классов).

Данные диаграммы представлены в Приложении Ж.

Заключение

В результате курсового проектирования была разработана информационная система Отдела регистратуры «Городской поликлиники». Основой для создания информационной системы послужили проблемы предметной области. В качестве среды разработки было выбрано- Rational Rose 2006, предназначенное для автоматизации этапов анализа и проектирования предметной области.

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

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

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

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

1. Боггс У., Боггс М. UML и Rational Rose. М.: «Лори», 2000 г. - 582 с.

2. Трофимов С.А., CASE-технологии: Практическая работа в Rational Rose. - 2-е изд.-М.: Бином-Пресс, 2002.-288 с.

3. Буч Г., Рамбо Д., Джекобсон А., Язык UML. Руководство пользователя: Пер. с англ. - М.:ДМК, 2000. -432с.

4. Леоненков А., Самоучитель UML. - СПб: Питер, 2001. - 158 с.

5. Грехем И. Объектно-ориентированные методы. Принципы и практика - М.: "Вильямс", 2004. - 880 с.

6. Кьоу Дж., Джеанини М. Объектно-ориентированное программирование. Учебный курс - СПб: "Питер", 2005.- 238 с.

7. Ларман К. Применение UML и шаблонов проектирования - М.: "Вильямс", 2001. - 496 с.

8. Ларман К. Применение UML и шаблонов проектирования. 2-е издание - М.: "Вильямс", 2002. - 624 с.

9. Леоненков А.В. Самоучитель UML - СПб.: "БХВ - Петербург", 2001. - 304 с.

10. Леоненков А.В. Самоучитель UML. 2-е издание - СПб.: "БХВ-Петербург", 2004. - 432 с.

Приложение А. Диаграмма использования

Приложение Б. Диаграмма использования

Приложение В. Диаграмма использования

Приложение Г. Диаграмма использования

Приложение Д. Диаграмма последовательности

Приложение Е. Диаграмма сотрудничества

Приложение Ж. Диаграмма классов

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