Разработка объектно-ориентированной модели информационной подсистемы стоматологическая поликлиника
Министерство образования и науки Российской
Федерации
ГОУ ВПО СЕВЕРО-КАВКАЗСКИЙ ТЕХНИЧЕСКИЙ
УНИВЕРСИТЕТ
Факультет информационных технологий и телекоммуникаций
Кафедра прикладной информатики
ПОЯСНИТЕЛЬНАЯ
ЗАПИСКА
К КУРСОВОМУ
ПРОЕКТУ
НА ТЕМУ:
Разработка объектно-ориентированной модели информационной подсистемы
стоматологическая поликлиника
Автор курсового проекта Т.И. Волосатова
Руководитель проекта: к.т.н., доцент В.Ф. Ляхов
Ставрополь,
2011
Содержание
ВВЕДЕНИЕ
1.
КРАТКАЯ ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ
1.1 Общая характеристика
.2 Актуальность
разрабатываемой подсистемы
.3 Формулировка задач
проектирования
2.
СОЗДАНИЕ ДИАГРАММЫ ПРЕЦЕДЕНТОВ
.
СОЗДАНИЕ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ
.
СОЗДАНИЕ ДИАГРАММЫ СОТРУДНИЧЕСТВА
.
СОЗДАНИЯ ДИАГРАММОВ КЛАССОВ
.
ДОБАВЛЕНИЕ ДЕТАЛЕЙ К ОПИСАНИЯМ ОПЕРАЦИЙ И ОПРЕДЕЛЕНИЕ АТРИБУТОВ КЛАССОВ
.
СОЗДАНИЕ ДИАГРАММЫ СОСТОЯНИЙ
7.1 Создание диаграммы
состояний для класса EnterDogovor
.2 Создание диаграммы
компонентов для классов
8.
СОЗДАНИЕ ДИАГРАММЫ РАЗМЕЩЕНИЯ
.
ГЕНЕРАЦИЯ ПРОГРАММНОГО КОДА C++
ЗАКЛЮЧЕНИЕ
БИБЛИОГРАФИЧЕСКИЙ
СПИСОК
Приложение
ВВЕДЕНИЕ
Унифицированный язык моделирования UML (Unified Modeling Language) - это
преемник того поколения методов ООАП, которые появились в конце 80-х и начале
90-х гг. Создание UML фактически началось в конце 1994 г., когда Гради Буч и
Джеймс Рамбо начали работу по объединению методов Booch и ОМТ (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. они создали первую
спецификацию объединенного метода, названного ими Unified Method, версия 0.8.
Тогда же, в 1995 г., к ним присоединился создатель метода OOSE (Object-oriented
Software Engineering) Ивар Якобсон.Таким образом, UML является прямым
объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их
новыми возможностями. Главными в разработке UML были следующие цели:
предоставить пользователям готовый к использованию выразительный язык
визуального моделирования, позволяющий разрабатывать осмысленные модели и
обмениваться ими;
предусмотреть механизмы расширяемости и специализации для расширения
базовых концепций;
обеспечить независимость от конкретных языков программирования и
процессов разработки;
обеспечить формальную основу для понимания этого языка моделирования;
(язык должен быть одновременно точным и доступным для понимания, без
лишнего формализма);
В курсовом проекте разработана
объектно-ориентированная модель информационной подсистемы учета пациентов
стоматологической поликлиники. Модель разработана с помощью программного
продукта Rational Rose 2000, с использованием языка UML.
В первом разделе курсового проекта представлена
основная характеристика предметной области, а также актуальность разработки
объектно-ориентированной модели информационной подсистемы стоматологической
поликлиники для учета пациентов.
Во втором разделе рассматривается создание диаграммы
прецедентов, ее основная характеристика. В этом разделе выделены актеры,
включенные в работу информационной подсистемы, а также рассмотрены их основные
действия.
В третьем разделе пояснительной записки
рассматривается создание диаграммы последовательности (sequence diagrams). Данная диаграмма предназначенная
для моделирования процесса обмена сообщениями между объектами.
В четвертом разделе рассматривается диаграмма
сотрудничества для прецедента информационной подсистемы «Заключение договора».
В пятом разделе описывается диаграмма классов для
прецедента «Заключение договора с пациентом».
В шестом разделе приводится и описывается диаграмма
классов прецедента «Оформление договора с пациентом», а также рассматриваются
основные добавленные атрибуты и операции.
В седьмом разделе приводится и описывается диаграммы
состояний для класса EnterDogovor. В этом же разделе приводится описание
диаграммы компонентов для прецедентов информационной подсистемы «Заключение
договора с пациентом».
В восьмом разделе пояснительной записки приводится и
описывается диаграмма размещения проектируемой информационной подсистемы.
В девятом разделе пояснительной записки приводится и
описывается порядок генерации программного кода на языке С++ для данной
информационной подсистемы.
В заключении подведены основные итоги курсового проектирования и
сформулированы перспективные направления развития темы курсового проекта.
В приложение вынесены листинги кода проектируемой программы,
сгенерированные RationalRose.
1. КРАТКАЯ ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ
.1 Общая характеристика
Разрабатываемая информационная подсистема предназначена для использования
в рамках информационной системы «Городская стоматологическая поликлиника»
(название условное; в дальнейшем просто «Поликлиника») для оперативного учета
пациентов, обратившихся за оказанием медицинской помощи.
.2 Актуальность разрабатываемой подсистемы
Стоматологическая поликлиника создана
с целью оказания медицинской помощи и услуг населению. В соответствии с уставом
учреждения задачами поликлиники являются удовлетворение потребностей населения
в лечении стоматологических заболеваний, зубопротезировании, повышении качества
диагностики и лечения стоматологических заболеваний, пропаганда здорового
образа жизни. Поликлиника обслуживает население города в рамках программы
обязательного медицинского страхования и эффективно сотрудничает со страховыми
компаниями. Кроме того, возросли требования населения к условиям, качеству и номенклатуре
предоставляемой медицинской и лекарственной помощи. Большое количество
пациентов обуславливает необходимость применения ПК при оперативном учете для
повышения производительности труда работников и повышения качества обслуживания
пациентов.
.3 Формулировка задач проектирования
Здравоохранение является сферой
деятельности государства по обеспечению прав граждан на жизнь и здоровье,
которая рассматривается как одна из приоритетных в политической, экономической
и социальной жизни государства и общества.
Внедрение автоматизированных информационных систем в деятельность
бюджетных организаций создает возможности для повышения качества
документационного обеспечения управления и позволяет повысить
производительность и качество управленческого труда.
Разрабатываемая подсистема должна удовлетворять следующие потребности:
-сбор, хранение, обработка и оперативная выдача информации о ходе
лечебно-диагностического процесса;
повышение эффективности управления за счет оперативности принятия и
повышения качества управленческих решений;
повышение эффективности деятельности структурных подразделений
медицинского учреждения при использовании иерархической системы сбора,
хранения, передачи и централизованной обработки информации, содержащейся в
амбулаторной карте и истории болезни, с оперативным доступом к информации
рабочих мест;
повышение эффективности труда медицинского персонала, всех сотрудников
медицинского учреждения за счет автоматизации трудоемких, рутинных операций
(подготовке многочисленных выписок, справок, отчетов, дублирования результатов
анализов и т. д.),
повышение достоверности данных и оперативности информационного
обслуживания;
организация информационного взаимодействия различных врачей-специалистов
с возможностью более полного обеспечения преемственности в оказании медицинской
помощи на всех этапах медицинского обслуживания (диспансерного, стационарного,
реабилитационного);
повышение качества принятия решений в процессе диагностики, лечения,
реабилитации за счет использования экспертной поддержки;
повышение эффективности диагностики и лечения за счет создания
медицинской базы данных;
анализ стоимости, контроль полноты и качества диагностических, лечебных и
реабилитационных мероприятий;
рационализация использования медицинских ресурсов (персонала, аппаратуры,
оснащения и т. д.);
Для эффективного функционирования поликлиники, информационная подсистема
учета пациентов должна выполнять ряд задач. Медсестра, выполняющая роль
оператора ПК или другое уполномоченное лицо осуществляет оперативный учет
обратившихся пациентов. В ее обязанности входит:
- добавление исчерпывающей информации о пациенте в базу данных.
В качестве такой информации могут выступать ФИО, номер полиса, вид
предоставляемой услуги, дата;
- консультация пациента;
- заключение договора.
Этот вид диаграмм позволяет создать список сценарий, которые выполняет
система. Часто этот вид диаграмм называют диаграммой функций, потому что на
основе набора таких диаграмм создается список требований к системе и
определяется множество выполняемых системой функций.
Диаграмма прецедентов (использования) называется диаграмма, на которой
показана совокупность прецедентов и актеров, а также отношения (зависимости,
обобщения и ассоциации) между ними. [1]
Диаграмма этого вида представляет важную информацию - это одно из
основных преимуществ ее применения. Взглянув на варианты использования можно
понять какие функциональные возможности будут заложены в систему. Рассматривая
действующих лиц можно выяснить кто конкретно будет с ней взаимодействовать.
Изучая все множество вариантов использования и действующих лиц, определятся
сфера применения системы (что она будет делать). Это помогает узнать также, что
она не будет делать, и внести коррективы.
На рисунке 2.1 приведена диаграмма использования, спроектированная в
среде RationalRose. Основными действующими лицами
(актерами) являются медсестра и главный врач. Медсестра выполняет три основных
действия:
- консультация;
- заключение договора;
- занесение учетной информации в БД. Предполагает внесение
исчерпывающей информации о пациенте. Такой как :ФИО пациента, номер полиса, вид
предоставляемой услуги, стоимость услуги, дата .
Главный врач выполняет следующие действия:
изготовление коронки зуба;
профессиональная гигиена полости рта;
лечение кариеса;
снятие слепка;
терапевтическое лечение;
фиксация коронки;
Для создания диаграммы последовательности:
. Запустим интегрированную среду разработки Rational Rose 2000.
. Перейдем к главной диаграмме (Main) Use case:
- в браузере щелкнем на значке «+» рядом с представлением Use
case, чтобы открыть представление;
- дважды щелкнув на главной диаграмме, откроем её.
. С помощью кнопки Use Case (вариант использования) панели
инструментов поместим на диаграмму новый вариант использования.
. Назовем его «Консультация ».
. Повторив этапы 3 и 4, поместим на диаграмму остальные варианты
использования
изготовление коронки зуба;
профессиональная гигиена полости рта;
лечение кариеса;
снятие слепка;
терапевтическое лечение;
фиксация коронки;
. С помощью кнопки Actor (действующее лицо) панели инструментов
поместим на диаграмму новое действующее лицо.
. Назовем его «Медсестра».
. Повторим действия и добавим новое действующее лицо (Актера).
Назовем его «Главный врач».
. С помощью кнопки Unidirectional Association (Однонаправленная
ассоциация) добавим ассоциации между действующими лицами «Медсестра», «Главный
врач» и всеми вариантами использования.
Рисунок 2.1 - Диаграмма прецедентов стоматологической поликлиники для
учета пациентов
Рассмотренные выше варианты использования инициируют последовательность
действий (транзакций) в базе данных в ответ на действия со стороны «Медсестра».
Была разработана диаграмма прецедентов, состоящая из двух актеров и
девяти вариантов использования. Основным действующим лицом является
«Медсестра». Она выполняет три действия: «консультация», «заключение договора»,
«занесение учетной информации».
Проанализировав приведенную выше диаграмму использования наглядно видно,
что наиболее важный и наиболее сложный прецедент подсистемы является заключение
договора, так как от правильности его выполнения зависит в дальнейшем
успешность оперативного учета.
3. СОЗДАНИЕ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ
Диаграммы взаимодействия (interaction diagrams) являются
моделями, описывающими поведение взаимодействующих групп объектов. Как правило,
диаграмма взаимодействия охватывает поведение объектов в рамках только одного
варианта использования. На такой диаграмме отображаются ряд объектов и те
сообщения, которыми они обмениваются между собой. Диаграммы последовательности
отражают поток событий, происходящих в рамках варианта использования. Диаграммы
последовательности очень просты и наглядны (в этом заключается самое большое их
достоинство) и существенно помогают разобраться в процессе поведения
системы.[2]
Рассмотрим вариант использования «Заключение договора». Диаграмма
последовательности реализующая вариант использования «Заключение договора»
приведен на рисунке 3.1.
На приведенной выше диаграмме выделены следующие объекты соответствующих
классов:
форма договора - объект класса FormDogovor ;
форма предоставляемых услуг - объект класса FormUslug;
управляющий БД - объект управляющего класса DBManager, выполняющий функции СУБД;
управляющий транзакциями - объект класса TransactionManager, берущий на себя функции СУБД по
управлению транзакциями.
Последовательность действий основного потока выглядит следующим образом:
. Медсестра создает запись о новом заключении договора в БД.
. При этом она открывает необходимую форму для ввода данных пациента.
Рисунок 3.1 - Диаграмма последовательности для варианта использования
«Заключение договора»
. Вводит все необходимые поля в открытую форму.
. Нажимает на клавишу «Сохранить».
. При этом информация отправляется в СУБД, которая обозначена на
диаграмме как «Управляющий БД».
. СУБД создает новую пустую запись.
. Генерирует изменяет значения полей в соответствии с введенными
медсестрой данными.
. Передает эту запись системе управления транзакциями, которая
обозначена на диаграмме как «Управляющий транзакциями».
. Система управления транзакциями осуществляет транзакцию.
. Система управления транзакциями возвращает сообщение об
успешности проведения транзакции или ошибке при её выполнении.
Была разработана диаграмма последовательности для варианта использования
«Заключение договора с пациентом». Этот вариант использования является наиболее
важной и наиболее сложно реализуемой задачей информационной подсистемы.
При создании диаграммы были созданы пять классов: два управляющих, два
«граничных»(Boundaries) и один «сущность».
К «управляющим» классам относятся DBManager и TransactionManager, они
контролируют последовательность событий этого варианта использования.
К граничным классам относятся FormUslug и InputFormDogovor, Граничные
классы, которые расположены на границе системы и окружающей среды. Они включают
все формы, отчеты, интерфейсы с аппаратурой (такой, как принтеры или сканеры) и
интерфейсы с другими системами.
К классам сущность относятся DogovorID и EnterDogovor. Классы-сущности
(entity classes) отражают основные понятия (абстракции) предметной
области и, как правило, содержат хранимую информацию
4. СОЗДАНИЕ ДИАГРАММЫ СОТРУДНИЧЕСТВА
Диаграммы сотрудничества - второй тип диаграмм взаимодействия - Collaboration Diagram - Г. Буч называет диаграммой объектов. Эта диаграмма
не акцентирует внимание на последовательности передачи сообщений, она отражает
наличие взаимосвязей вообще, то есть на этой диаграмме отражается наличие
сообщений от клиентов к серверам.
Диаграмма показывает взаимодействие между объектами, а
не классами, то есть является мгновенным снимком объектов системы в некотором
состоянии. Ведь объекты, в отличие от созданных на этапе проектирования
классов, создаются и уничтожаются на всем протяжении работы программы. И в
каждый момент имеется конкретная группа объектов, с которыми осуществляется
работа. [4]
Этот тип диаграмм позволяет описать взаимодействие
объектов, абстрагируясь от последовательности передаче сообщений. На этом типе
диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения
конкретного объекта и типы этих сообщений.
В курсовом проекте была разработана диаграмма
сотрудничества, описывающая ввод данных пациента (рисунок 4.1). На диаграммах
классов отображаются некоторые классы и пакеты системы. Это статические картины
фрагментов системы и связей между ними.
Были использованы объекты:
действующее лицо - Медсестра;
форма договора (класс InputFormDogovor);
управляющий БД (класс BDManager);
оформление договора (класс EnterDogovor);
управляющий транзакциями (класс TransactionManager).
На диаграмму были добавлены следующие сообщения,
соотнесённые с операциями:
. Createdogovor( ) - открыть новую форму о
вводе данных о пациенте;
. OpenForm( ) - открыть форму для ввода
пациентов;
. Data( ) - ввести данные о пациенте;
. SaveInfo( ) - кнопка сохранения;
. SaveInfo(Integer) - посылается запрос в БД на
сохранение информации.
Рисунок 4.1 - Диаграмма сотрудничества
стоматологической поликлиники для прецедента «Заключение договора»
. Была спроектирована диаграмма сотрудничества
для варианта использования «Заключение договора». Правильность этого варианта
использования будет зависеть в дальнейшем успешность оперативного учета и
функционирования всей системы в целом.
. Были добавлены сообщения, соотнесённые с
соответствующими операциями.
5. СОЗДАНИЯ ДИАГРАММОВ КЛАССОВ
На диаграмме классов отображаются некоторые классы и
пакеты системы. Эти статистические картины фрагментов системы и связей между
ними.
Ознакомившись с классами модели, для более наглядного
представления, они были сгруппированы по стереотипу (рисунок 5.1). Стереотипы -
это механизм, позволяющий разделять классы на категории. В языке UML основными
стереотипами являются: Boundary (граница), Entity (сущность) и Control
(управление). Таким образом были созданы следующие пакеты: Entities (Сущности), Boundaries (Границы) и Control (Управление). В эти пакеты были помещены советующие
им классы.
Рисунок 5.1 - Диаграмма пакетов
Граничные классы (boundary classes) - это классы,
которые расположены на границе системы и окружающей среды. Они включают все
формы, отчеты, интерфейсы с аппаратурой (такой, как принтеры или сканеры) и
интерфейсы с другими системами. В пакет «Boundaries» были добавлены следующие классы:
класс InputFormDogovor (форма ввода информации о пациенте)
и класс FormUslug( форма ввода информации о видах
услуг).
Классы-сущности (entity classes) отражают основные понятия (абстракции) предметной
области и, как правило, содержат хранимую информацию. В данный пакет были
добавлен класс EnterDogovor.
Также был создан и добавлен в пакет вспомогательный класс DogovorID, предназначенный для того, чтобы
облегчить контроль вводимых данных.
Управляющие классы (control classes) отвечают за координацию действий других классов.
Обычно у каждого варианта использования имеется один управляющий класс,
контролирующий последовательность событий этого варианта использования. В
данном проекте данную функцию выполняет класс DBManager, а также
TransactionManager.
1. В процессе разработки диаграммы классов был применен механизм
пакетов. Были созданы три основных пакета, объединяющих классы по стереотипам.
. Была разработана диаграмма пакетов, являющаяся одной из форм
диаграммы классов.
6. ДОБАВЛЕНИЕ ДЕТАЛЕЙ К ОПИСАНИЯМ ОПЕРАЦИЙ И ОПРЕДЕЛЕНИЕ АТРИБУТОВ
КЛАССОВ
Этот тип диаграмм позволяет создавать логическое представление системы,
на основе которого создаются исходный код описанных классов.
Диаграммы классов - центральное звено объектно-ориентированных методов.
Диаграмма классов определяет типы объектов системы и различного рода
статические связи, которые существуют между ними.[5]
После того как была, разработана диаграмма классов для
варианта использования «Заключение договора», начинается ее заполнение. В
качестве языка программирования был выбран C++, что позволило добавить к
классам параметры операций, типы данных и типы возвращаемых значений.
Атрибут - это элемент информации, связанный с классом. Они содержатся
внутри класса, поэтому они скрыты от других классов. В связи с этим иногда
требуется указать, какие классы имеют право читать и изменять атрибуты. Это
свойство называется видимостью атрибута (attribute visibility). Для определения атрибутов и
операций классов было произведено обращение к потоку событий. В результате к
классам были добавлены дополнительные атрибуты и связи между классами(рисунок
6.1).
Как видно из диаграммы, для добавления новой информации о заключенном договоре,
необходимо ввести следующую информацию (атрибуты класса EnterDogovor):
-Dogovor_namber: Integer - номер договора;
Pacient_Sername: String - фамилия
пациента;
– Pacient_Lastname: String - отчество пациента;
– Polis_namber- номер полиса;
-Prise_uslug- стоимость оказываемой услуги;
-Data:Date - дата приема;.
Рисунок 6.1 - Диаграмма классов для сценария «Оформление договора с
пациентом»
Назначение и описание основных методов классов были рассмотрены выше, в
третьем и четвертом разделах.
. Была разработана диаграмма классов для сценария «заключение
договора с пациентом». Как видно из диаграммы, между классами существует
определенная семантическая связь.
. На диаграмме для каждой семантической связи также наглядно отображена
множественность, показывающая, сколько экземпляров одного класса
взаимодействует с помощью этой связи с одним экземпляром другого класса в
определенный момент времени.
7. СОЗДАНИЕ ДИАГРАММЫ СОСТОЯНИЙ
7.1 Создание диаграммы состояний для класса EnterDogovor
Диаграммы состояний (State) предназначена для отображения состояний объектов
системы, имеющих сложную модель поведения. Состоянием (state) называется одно из возможных условий, в которых
может существовать объект.
Находясь в конкретном состоянии, объект может выполнять определенные
действия. Например, может генерировать отчет, осуществлять некоторые вычисления
или посылать событие другому объекту. С состоянием можно связывать действия
пяти типов: деятельность, входное действие, выходное действие, событие и
история состояния.
Многие требования к классу значительно изменяются при изменении состояния
его экземпляра. Например, записи, заполнение которых приостановлено, ведут себя
не так, как полностью заполненные записи, а те в свою очередь не так, как
отмененные записи.
На рисунке 7.1.1 приведена диаграмма состояния для класса InputFormDogovor. Этапы создания диаграммы состояний:
. Найти в браузере класс InputFormDogovor.
. Щелкнуть на классе правой кнопкой мыши и в открывшемся меню
указать пункт Open State Diagram (Открыть диаграмму состояний).
Добавление начального и конечного состояний:
. Нажать кнопку Start State (Начальное состояние) панели
инструментов.
. Поместить это состояние на диаграмму.
. Нажать кнопку End State (Конечное состояние) панели
инструментов.
. Поместить это состояние на диаграмму.
Добавление состояний:
. На панели инструментов нажать кнопку State (Состояние).
. Поместить состояние на диаграмму.
. Назвать состояние Otmenen.
. На панели инструментов нажать кнопку State (Состояние).
. Поместить состояние на диаграмму.
. Назвать состояние Vipolnen.
. На панели инструментов нажать кнопку State (Состояние).
. Поместить состояние на диаграмму внутрь суперсостояния.
. Назвать состояние Inizializaziya.
. На панели инструментов нажать кнопку State (Состояние).
. Назвать состояние Priostanovlen.
Рисунок 7.1.1 - Диаграмма состояния для класса InputFormDogovor
Описание состояний:
. Дважды щелкнуть мышью на состоянии Inizializaziya.
. Щелкнуть правой кнопкой мыши в окне Actions (Действия).
. В открывшемся меню выберать пункт Insert (Вставить).
. Дважды щелкнуть мышью на новом действии.
. Назвать его StoreDate.
. Убедиться, что в окне When (Когда) указан пункт On Entry (На
входе).
. Повторив шаги 3 - 7, добавить следующие действия:
- Collect Pacient Info, в окне When указать Entry
until Exit (Выполнять до завершения);
- Add Information Items, указав Entry until Exit (Выполнять до завершения);
. Нажать два раза на ОК, чтобы закрыть спецификацию.
. Дважды щелкнуть мышью на состоянии Otmenen.
. Повторив шаги 2 - 7, добавить действие Store cancellation data, указав On Exit
(На выходе)
. Нажать два раза на ОК, чтобы закрыть спецификацию.
. Дважды щелкнуть мышью на состоянии Vipolnen.
. Повторив шаги со второго по седьмой, добавить действие Create Otchet, указав Entry until Exit
. Нажать два раза на ОК, чтобы закрыть спецификацию.
.2 Создание диаграммы компонентов для классов
Добавление переходов:
. Нажать кнопку Transition (Переход) панели инструментов.
. Щелкнуть мышью на начальном состоянии.
. Провести линию перехода к состоянию Inizializaziya.
. Повторив шаги с первого по третий, создать следующие переходы:
от состояния Inizializaziya к состоянию Priostanovlen;
- от Priostanovlen к состоянию Vipolnen;
- от состояния Inizializaziya к состоянию Otmenen;
- от состояния Otmenen к конечному состоянию;
- от состояния Vipolnen к конечному состоянию;
. На панели инструментов нажать кнопку Transition to Self (Переход
к себе).
. Щелкнуть мышью на состоянии Priostanovlen.
Описание переходов:
. Дважды щелкнув мышью на переходе от состояния Inizializaziya к
состоянию Priostanovlen, открыть окно спецификации перехода.
. В поле Event (Событие) ввести фразу Zacluchit dogovor .
. Щелкнув на кнопке ОК, закрыть окно спецификации.
. Повторив шаги с первого по третий, добавить событие Otmenit' zapolnenie
к переходу между стоянием Inizializaziya и состоянием Otmenen.
. Дважды щелкнув мышью на переходе от состояния Priostanovlen к
состоянию Vipolnen, открыть окно его спецификации.
. В поле Event (Событие) ввести фразу Dobavit' novuu informaciu.
. Перейти на вкладку Detail (Подробно).
. В поле Condition (Условие) введите Ne ostalis nezapolnenie
polya.
. Щелкнув на кнопке ОК, закрыть окно спецификации.
. Дважды щелкнуть мышью на рефлексивном переходе (Transition to
Self) состояния Priostanovlen.
. В поле Event (Событие) ввести фразу Dobavit' novuu informaciu.
. Перейти на вкладку Detail (Подробно).
. В поле Condition (Условие) ввести ostautsya nezapolnenie polya.
. Щелкнув на кнопке ОК, закрыть окно спецификации.
Была также создана диаграмма компонентов, отображающая распределение
классов и объектов по компонентам при физическом проектировании «Заключение
договора». Как видно на рисунке 7.2.1 система была разложена на два компонента:
сервер и клиент. К клиентской части приложения относятся классы FormUslug и FormDogovor и объекты этих классов. К серверной
части приложения отнесены все остальные классы и объекты этих классов.
Рисунок 7.2.1 - Диаграмма компонентов InputFormDogovor
. Была создана диаграмма состояний для класса InputFormDogovor. Согласно этой диаграмме объекты
класса InputFormDogovor могут находиться в одном из четырех
состояний: инициализации, приостановки, отмены и завершения. Была также
разработана диаграмма компонентов, разделяющая систему на 2 компонента: клиент
и сервер.
. Из диаграммы компонентов видно, что разрабатываемая подсистема
будет работать по технологии «клиент-сервер». К клиентской части приложения
относятся классы FormUslug и FormDogovor и объекты этих классов. К серверной
части приложения отнесены все остальные классы и объекты этих классов.
8. СОЗДАНИЕ ДИАГРАММЫ РАЗМЕЩЕНИЯ
Этот вид диаграмм предназначен для анализа аппаратной части системы, то
есть «железа», а не программ. В прямом переводе с английского Deployment
означает «развертывание», но термин «топология» точнее отражает сущность этого
типа диаграмм. Иногда диаграммы топологии называют диаграммами размещения.
Добавление узлов к диаграмме размещения:
. Дважды щелкнув мышью на представлении размещения в браузере,
открыть диаграмму размещения.
. Нажать кнопку Processor (Процессор) панели инструментов.
. Щелкнув мышью на диаграмме, поместить туда процессор.
. Ввести имя процессора «Сервер базы данных».
. Повторив шаги 2-4, добавить следующие процессоры: «сервер
приложения», «клиентская рабочая станция №1», «клиентская рабочая станция №2».
. На панели инструментов нажать кнопку Device (Устройство).
. Щелкнув мышью на диаграмме, поместить туда устройство.
. Назвать его «Принтер».
Добавление связей:
. Нажать кнопку Connection (Связь) панели инструментов.
. Щелкнуть мышью на процессоре «Сервер базы данных».
. Провести линию связи к процессору «Сервер приложения».
. Повторив шаги 1 − 3, добавить следующие связи:
- от процессора «Сервер приложения» к процессору «Клиентская
рабочая станция №1»;
- от процессора «Сервер приложения» к процессору «Клиентская
рабочая станция №2»;
- от процессора «Сервер приложения» к устройству «Принтер».
Добавление процессов:
. Щелкнуть правой кнопкой мыши на процессоре «Сервер приложения» в
браузере.
. В открывшемся меню выбирать пункт New → Process (Создать →
Процесс).
. Повторить шаги 1 − 3, добить процессы:
- процесс DogovorClientExe
на процессоре «Клиентская рабочая станция №1»;
- процесс ATMClientExe на процессоре «Клиентская рабочая
станция №2».
Показ процессов на диаграмме:
. Щелкнуть правой кнопкой мыши на процессоре «Сервер приложения».
. В открывшемся меню выбрать пункт Show Processes (Показать
процессы).
. Повторив шаги 1 и 2, показать процессы на следующих процессорах:
- клиентская рабочая станция №1;
- клиентская рабочая станция №2.
Рисунок 8.1 - Диаграмма размещения EnterDogovor
Из диаграммы видно, что информационная подсистема стоматологическая
поликлиника построена на технологии «клиент-сервер». Это позволяет организовать
одновременный доступ нескольких операторов ПК к базе данных.
1. Клиентские программы будут работать в
нескольких местах. Через локальную вычислительную сеть поликлиники будет
осуществляться сообщение этой части программы с главным сервером системы, с
работающим программным обеспечением. В свою очередь, главный сервер посредством
локальной сети будет сообщаться с сервером базы данных. С главным сервером
соединен принтер. Главный сервер может находится в главном корпусе поликлиники.
9. ГЕНЕРАЦИЯ ПРОГРАММНОГО КОДА C++
Язык C++ является одним из наиболее широко применяемых на практике объектно-ориентированных
языков. Rational Rose интегрируется с C++ посредством генерации кода и
обратного проектирования. В Rational Rose 2000 предусмотрена возможность
генерации программного кода C++, а также интеграции с языком Visual C++ версии
6 компании Microsoft.
Для генерации программного кода на стандартном C++ необходимо:
. Создать компоненты;
. Определить компоненты для классов;
. Установить свойства генерации программного кода
. Выбрать класс или компонент для генерации на диаграмме Классов или
Компонентов.
5.Выбрать в меню Tools → ANSI C++ →
Generation Code.
6. Выбрать в меню Tools → ANSI C++ → Browse Header или Browse Body для просмотра
сгенерированного программного кода(рисунок 9.1)
Первый этап процесса генерации программного кода - создание компонентов
для классов. Это файлы с расширениями *. cpp и *. h. В C++ данный этап не
является обязательным. Если не описать компоненты, Rational Rose сгенерирует
файлы *. cpp и *. h для каждого класса. Тем не менее, рекомендуется создавать
компоненты, что позволит управлять отображением классов на компоненты и
моделировать зависимости между компонентами.
Для генерации кода Rational Rose 2000 использует самую различную
информацию, содержащуюся в модели. Анализируются множественность, имена ролей,
включение и другие характеристики каждой связи. Просматриваются атрибуты,
операции, видимость и другие детали каждого класса. Rational Rose 2000 выбирает
нужные для генерации кода сведения из всех данных, вводимых в окнах
спецификации различных элементов модели.
Рисунок 9.1 Генерация программного кода на С++
. На основании созданных моделей компонентов, представленных в
проекте была произведена генерация программного кода на языке C++.
. Листинги сгенерированного Rational Rose кода приложения для учета студентов университета на
языке С++ приведены в Приложении А. Общий размер сгенерированных файлов
составляет 7,38 кбайт.
ЗАКЛЮЧЕНИЕ
В результате выполнения курсового проекта была разработана
объектно-ориентированная модель информационной подсистемы стоматологическая
поликлиника для учета пациентов. Данная разработка написана с помощью языка UML, с использованием среды разработки -
программного продукта Rational Rose 2000.
Были реализованы следующие диаграммы:
- диаграмма прецедентов для стоматологической поликлиники;
- диаграмма последовательности для прецедента «Заключение
договора»;
диаграмма сотрудничества для информационной системы Стоматологической
поликлиники, отражающая реализацию прецедента «Заключение договора»;
- диаграмма классов для «Оформление договора с пациентом»;
- диаграмма состояния для классов «EnterDogovor»;;
- диаграмма компонентов «Заключения договора»;
- диаграмма размещения «Заключения договора».
Основным действующим лицом является медсестра. Она выполняет четыре действия:
«заключить договор», «консультация», «занести учетную информацию в БД».
Наиболее важной и наиболее сложно реализуемой задачей информационной
подсистемы является заключение договора, так как от правильности выполнения
этого прецедента зависит успешность оперативного учета в целом. Для решения
этой задачи были созданы пять классов: два «управляющих», два «граничных»(Boundaries) и один «сущность».
Информационная подсистема учета студентов университета построена на
технологии «клиент-сервер». Это позволяет организовать одновременный доступ
нескольких операторов ПК к базе данных.
Клиентские программы будут работать в нескольких
местах. Через локальную вычислительную сеть университета будет осуществляться
сообщение этой части программы с главным сервером системы, с работающим
программным обеспечением. В свою очередь, главный сервер посредством локальной
сети будет сообщаться с сервером базы данных. С главным сервером соединен
принтер. Главный сервер может находиться в главном корпусе поликлиники.
Были сгенерированы 12 файлов кода на языке С++ общим
размером 7,38 кбайт.
Разработанная в данном курсовом проекте модель позволяет производить
добавление информации о заключенном договоре с пациентом в базу данных,
ежедневное занесение оперативной информации о пациентах и поиск необходимой
информации.
Спецификация UML не определяет конкретный процесс
разработки, поэтому перспективным направлением разработки темы курсового
проекта является наполнение сгенерированной модели функциональным кодом.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
Для книг:
1. Марков А.
А., Моделирование информационно-вычислительных процессов. - М.: Изд-во МГТУ им.
Э. Баумана, 1999. - 360 с.
2. Боггс У.,
Боггс М.. UML и Rational
Rose: Пер. с англ. - М.: Издательство
«Лори», 2000.- 581 с., ил.
. Буч Г.,
Рамбо Д., Джекобсон А. UML: специальный справочник. - СПб.: Питер, 2002.- 432
с., ил.
4. Вендров
А.М. Проектирование программного обеспечения информационных систем. - М.:
Финансы и Статистика, 2002 - 352 c.: ил.
5. Ларман К.
применение UML и шаблонов проектирования: Пер. с англ. - М.: Издательский дом
«Вильямс», 2001. - 496 с., ил.
Для
стандартов:
. ГОСТ
2.105-95 ЕСКД. Общие требования к текстовым документам
. ГОСТ
2.004-88 ЕСКД. Общие требования к выполнению конструкторских и технологических
документов на печатающих и графических устройствах ввода ЭВМ
. ГОСТ
2.104-68 ЕСКД. Основные надписи
. ГОСТ
2.106-68 ЕСКД. Текстовые документы
. ГОСТ
2.109-73 ЕСКД. Основные требования к чертежам
. ГОСТ
2.301-68 ЕСКД. Форматы
Приложение
программный
код лечебный информационный
Листинги кода приложения для учета пациентов, сгенерированные Rational Rose на языке С++
A.1
Листинг файла DBMeneger.h
#ifndef DBMANAGER_H_HEADER_INCLUDED_B200C179
#define DBMANAGER_H_HEADER_INCLUDED_B200C179 EnterDogovor;
// Система управления базой данных
//##ModelId=453CF383009FDBManager
{:
//##ModelId=453CF4550169SaveInfo(Integer ZakazID);
//##ModelId=454DF91303DA*theTransactionManager;
};
#endif /* DBMANAGER_H_HEADER_INCLUDED_B200C179 */.2 Листинг файла
DBMeneger.cpp
#include "DBManager.h"
#include "EnterDogovor.h"
//##ModelId=453CF4550169DBManager::SaveInfo(Integer ZakazID)
{
}.3 Листинг файла DogovorID.cpp
#include "DogovorID.h"
//##ModelId=454DF234029ADogovorID::Create()
{
}
//##ModelId=454DF24203BDDogovorID::SetInfo(Integer ID)
{
}
//##ModelId=454DF25101C0DogovorID::GetInfo()
{
}.4 Листинг файла DogovorID.h
#ifndef DOGOVORID_H_HEADER_INCLUDED_B200C34A
#define DOGOVORID_H_HEADER_INCLUDED_B200C34A
//##ModelId=454DF0B10348DogovorID
{:
//##ModelId=454DF234029ACreate();
//##ModelId=454DF24203BDSetInfo(Integer ID = 0);
//##ModelId=454DF25101C0GetInfo();:
//##ModelId=454DF7F2032ADogovorID;
};
#endif /* DOGOVORID_H_HEADER_INCLUDED_B200C34A */.5 Листинг файла
EnterDogovor.cpp
#include "EnterDogovor.h"
//##ModelId=453CF4630336EnterDogovor::CreateEmptyRecord()
{
}
//##ModelId=453CF47D010D::PacientInfo()
{
}
//##ModelId=453CF48801B3::EnterInformation(Integer
dogovor_namber, String pacient_name, String pacient_sername, String
pacient_lastname, Integer polise_namber, String type_uslug, int prise_uslug,
data data)
{
}.6 Листинг файла EnterDogovor.h
#ifndef ENTERDOGOVOR_H_HEADER_INCLUDED_B200DB55
#define ENTERDOGOVOR_H_HEADER_INCLUDED_B200DB55
// Оформление договора
//##ModelId=453CF3E40275EnterDogovor
{:
//##ModelId=453CF4630336CreateEmptyRecord();
//##ModelId=453CF47D010D();
//##ModelId=453CF48801B3(Integer dogovor_namber, String
pacient_name, String pacient_sername, String pacient_lastname, Integer
polise_namber, String type_uslug, int prise_uslug, data data);
//##ModelId=4DE798F801D4dogovor_namber;
//##ModelId=4DE7991B0177pacient_name;
//##ModelId=4DE79935003Epacient_sername;
//##ModelId=454DF92B028A*theDogovorID;:
//##ModelId=4DE799530148pacient_lastname;
//##ModelId=4DE79A260128polise_namber;
//##ModelId=4DE79B470232type_uslug;
//##ModelId=4DE79B5B02EEprise_uslug;
//##ModelId=4DE79B720399data;
};.7 Листинг файла FormUslug.cpp
// Copyright (C) 1991 - 1999 Rational Software Corporation
#include "stdafx.h"
#include "InputFormDogovor.h"
#include "FormUslug.h"
//##ModelId=453CE6830108FormUslug::Create()
{
// TODO: Add your specialized code here.
// NOTE: Requires a correct return value to compile.
}.8 Листинг файла FormUslug.h
#include "FormUslug.h"
//##ModelId=453CE6830108FormUslug::Create()
{
}.9 Листинг файла InputFormDogovor.cpp
#include "InputFormDogovor.h"
#include "DBManager.h"
{
}
//##ModelId=453CF3C70346InputFormDogovor::EnterData()
{
}
//##ModelId=453CF4440006InputFormDogovor::SaveInfo()
{
}.10 Листинг файла InputFormDogovor.h
#ifndef INPUTFORMDOGOVOR_H_HEADER_INCLUDED_B200D863
#define INPUTFORMDOGOVOR_H_HEADER_INCLUDED_B200D863 DBManager;
// Форма ввода информации о пациенте
//##ModelId=453CF313010CInputFormDogovor
{:
//##ModelId=453CF349025EOpenForm();
//##ModelId=453CF3C70346EnterData();
//##ModelId=453CF4440006SaveInfo();
//##ModelId=454DF90C03DA*theDBManager;
};
#endif /* INPUTFOR MDOGOVOR_H_HEADER_INCLUDED_B200D863 */