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

Создание UML фактически началось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединению методов Booch и ОМТ (Object Modeling Technique) под эгидой компании Rational Software. Тогда же, в 1995 г., к ним присоединился создатель метода OOSE (Object-oriented Software Engineering) Ивар Якобсон.Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их новыми возможностями. Главными в разработке UML были следующие цели:-предоставить пользователям готовый к использованию выразительный язык визуального моделирования, позволяющий разрабатывать осмысленные модели и обмениваться ими; В курсовом проекте разработана объектно-ориентированная модель информационной подсистемы учета пациентов стоматологической поликлиники. В первом разделе курсового проекта представлена основная характеристика предметной области, а также актуальность разработки объектно-ориентированной модели информационной подсистемы стоматологической поликлиники для учета пациентов.Стоматологическая поликлиника создана с целью оказания медицинской помощи и услуг населению.Здравоохранение является сферой деятельности государства по обеспечению прав граждан на жизнь и здоровье, которая рассматривается как одна из приоритетных в политической, экономической и социальной жизни государства и общества. Внедрение автоматизированных информационных систем в деятельность бюджетных организаций создает возможности для повышения качества документационного обеспечения управления и позволяет повысить производительность и качество управленческого труда. Разрабатываемая подсистема должна удовлетворять следующие потребности:-сбор, хранение, обработка и оперативная выдача информации о ходе лечебно-диагностического процесса; -повышение эффективности деятельности структурных подразделений медицинского учреждения при использовании иерархической системы сбора, хранения, передачи и централизованной обработки информации, содержащейся в амбулаторной карте и истории болезни, с оперативным доступом к информации рабочих мест; -повышение эффективности труда медицинского персонала, всех сотрудников медицинского учреждения за счет автоматизации трудоемких, рутинных операций (подготовке многочисленных выписок, справок, отчетов, дублирования результатов анализов и т. д.),-повышение достоверности данных и оперативности информационного обслуживания;Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Диаграмма прецедентов (использования) называется диаграмма, на которой показана совокупность прецедентов и актеров, а также отношения (зависимости, обобщения и ассоциации) между ними. Диаграмма этого вида представляет важную информацию - это одно из основных преимуществ ее применения. Изучая все множество вариантов использования и действующих лиц, определятся сфера применения системы (что она будет делать). С помощью кнопки Use Case (вариант использования) панели инструментов поместим на диаграмму новый вариант использования.Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. Диаграммы последовательности отражают поток событий, происходящих в рамках варианта использования. Рассмотрим вариант использования «Заключение договора». Диаграмма последовательности реализующая вариант использования «Заключение договора» приведен на рисунке 3.1. -управляющий транзакциями - объект класса TRANSACTIONMANAGER, берущий на себя функции СУБД по управлению транзакциями.Эта диаграмма не акцентирует внимание на последовательности передачи сообщений, она отражает наличие взаимосвязей вообще, то есть на этой диаграмме отражается наличие сообщений от клиентов к серверам. Диаграмма показывает взаимодействие между объектами, а не классами, то есть является мгновенным снимком объектов системы в некотором состоянии. Ведь объекты, в отличие от созданных на этапе проектирования классов, создаются и уничтожаются на всем протяжении работы программы. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений. В курсовом проекте была разработана диаграмма сотрудничества, описывающая ввод данных пациента (рисунок 4.1).На диаграмме классов отображаются некоторые классы и пакеты системы. Стереотипы - это механизм, позволяющий разделять классы на категории. Таким образом были созданы следующие пакеты: Entities (Сущности), Boundaries (Границы) и Control (Управление). Граничные классы (boundary classes) - это классы, которые расположены на границе системы и окружающей среды. В пакет «Boundaries» были добавлены следующие классы: класс INPUTFORMDOGOVOR (форма ввода информации о пациенте) и класс FORMUSLUG( форма ввода информации о видах услуг).В качестве языка программирования был выбран C , что позволило добавить к классам параметры операций, типы данных и типы возвращаемых значений. Атриб

Содержание

ВВЕДЕНИЕ

1. КРАТКАЯ ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Общая характеристика

1.2 Актуальность разрабатываемой подсистемы

1.3 Формулировка задач проектирования

2. СОЗДАНИЕ ДИАГРАММЫ ПРЕЦЕДЕНТОВ

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

4. СОЗДАНИЕ ДИАГРАММЫ СОТРУДНИЧЕСТВА

5. СОЗДАНИЯ ДИАГРАММОВ КЛАССОВ

6. ДОБАВЛЕНИЕ ДЕТАЛЕЙ К ОПИСАНИЯМ ОПЕРАЦИЙ И ОПРЕДЕЛЕНИЕ АТРИБУТОВ КЛАССОВ

7. СОЗДАНИЕ ДИАГРАММЫ СОСТОЯНИЙ

7.1 Создание диаграммы состояний для класса ENTERDOGOVOR

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

8. СОЗДАНИЕ ДИАГРАММЫ РАЗМЕЩЕНИЯ

9. ГЕНЕРАЦИЯ ПРОГРАММНОГО КОДА C

ЗАКЛЮЧЕНИЕ

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

Приложение