Информационные подсистемы

Министерство образования и науки Российской Федерации

ГОУ ВПО СЕВЕРО-КАВКАЗСКИЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

Факультет информационных технологий и телекоммуникаций

Кафедра прикладной информатики

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

К КУРСОВОМУ ПРОЕКТУ НА ТЕМУ:

Разработка объектно-ориентированной модели информационной

подсистемы для регистратуры ЦРБ

Автор курсового проекта: Д.О. Никифорова

Направление: 080800.62 «Прикладная информатика»

Группа: ПИБ-081

Обозначение курсового проектаКП-СевКавГТУ-080800.62-061833-11

Руководитель проекта: к.т.н.,доцент В.Ф. Ляхов_

Ставрополь, 2011

Содержание

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

ОПРЕДЕЛЕНИЕ АТРИБУТОВ КЛАССОВ

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

ДИАГРАММЫ КОМПОНЕНТОВ

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

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

ЗАКЛЮЧЕНИЕ

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

Приложение А

ВВЕДЕНИЕ

UML (англ. <#"justify">В заключении подведены итоги курсового проектирования и сформулированы пути развития темы курсового проекта.

В приложение вынесены листинги кода проектируемой программы, сгенерированные RationalRose.

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

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

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

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

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

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

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

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

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

-добавлять информацию о новом пациенте в базу данных поликлиники;

-изменять имеющуюся информацию об уже занесенных в базу данных пациентах;

-просматривать данных о пациенте;

-выдавать пациенту талон на прием к врачу-специалисту;

Вывод

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

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

На данной диаграмме отражены отношения, существующие между актерами и прецедентами. Основная задача - представлять собой единое средство, дающее возможность <#"justify">-занесение информации о новом пациенте в базу данных;

-просмотр базы данных. Подразумевает поиск необходимой информации по необходимости;

-изменение данных о пациенте, ранее посещавшем данную поликлинику;

-

выдача талонов на прием к врачам-специалистам.

Рисунок 2.1 - Диаграмма вариантов использования «Регистратура»

Для создания диаграммы последовательности необходимо:

1.Запустить интегрированную среду разработки Rational Rose 2000.

2.Перейти к главной диаграмме (Main) Use case:

-путем нажатия на значке «+» рядом с представлением Use case, открыть представление;

-дважды щелкнув на главной диаграмме, открыть её.

3.С помощью кнопки Use Case (вариант использования) панели инструментов поместить на диаграмму новый вариант использования.

4.Ввести название «Выдать талон на прием».

.Повторив этапы 3 и 4, поместить на диаграмму оставшиеся преценденты:

-просмотр данных о пациенте;

-изменить данные о пациенте;

-добавить пациента в БД;

-узнать расписание работы врачей;

6.Используя кнопку Actor (действующее лицо) панели инструментов, поместить на диаграмму новое действующее лицо.

.Ввести имя «Работник регистратуры».

8.Повторив шаги шесть и семь, поместить на диаграмму еще одного актера действующее лицо «Пациент»

9.С помощью кнопки Unidirectional Association (Однонаправленная ассоциация) добавить связь между действующим лицом «Работник регистратуры» и всеми вариантами использования, исключая прецедент «Узнать расписание работы врачей»

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

Рассмотренные выше варианты использования инициируют последовательность действий (транзакций) в базе данных в ответ на действия со стороны работника регистратуры поликлиники.

Выводы

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

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

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

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

Рассмотрим вариант использования «Выдать талон на прием». Диаграмма последовательности приведена на рисунке 3.1.

Рисунок 3.1 - Диаграммапоследовательности для варианта использования «Выдать талон на прием»

На приведенной выше диаграмме выделены следующие объекты соответствующих классов:

-выбор врача - объект класса DocForm, отвечающий за выбор необходимого врача-специалиста;

-форма заполнения талона - объект класса TalonForm - конкретной формы ввода данных о выдаваемом талоне;

-управляющий БД - объект управляющего класса DBManager, выполняющий функции СУБД;

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

-управляющий транзакциями - объект класса TransactionManager, берущий на себя функции СУБД по управлению транзакциями.

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

1.Работник регистратуры создает новую запись о выдаваемом талоне в БД.

2.Сначала он открывает необходимую форму для выбора врача, а затем для заполнения талона.

.Вводит все необходимые поля в открытую форму.

.Сохраняет введенные данные.

.При этом информация отправляется в СУБД, которая обозначена на диаграмме как «Управляющий БД».

.СУБД создает новую пустую запись.

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

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

.Система управления транзакциями осуществляет транзакцию.

.Система управления транзакциями возвращает сообщение об успешности проведения транзакции или ошибке при её выполнении.

Выводы

. Была разработана диаграмма последовательности для варианта использования «Выдать талон на прием». Этот вариант использования является наиболее важной и наиболее сложно реализуемой задачей информационной подсистемы.

. При создании диаграммы были созданы пять классов: два управляющих, два «граничных»(Boundaries) и один «сущность».

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

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

Разработанная в данном курсовом проекте диаграмма сотрудничества описывает процесс выдачи талона на прием к врачу-специалисту (рисунок 4.1).

Рисунок 4.1 - Диаграмма сотрудничества для варианта использования «Выдача талона на прием»

Используемые объекты:

-выбор врача ( класс DocForm);

-заполнение талона (класс TalonForm);

-управляющий БД (класс DBManager);

-запись выдаче талона в БД (класс Talon);

-управляющий транзакциями (класс - TransactionManager).

На диаграмму были добавлены следующие сообщения, соотнесенные с операциями:

1.Create() - создать новую форму о выборе необходимого врача.

2.OpenForm() - открыть форму заполнения нового талона .

3.EnterData() - ввести данные на форму.

4.SaveInfo() - нажать кнопку сохранить на форме.

5.SaveTalon() - послать запрос в БД на сохранение информации.

6.CreateT() - создать пустую запись в БД.

7.EnterInfo() - редактирование вновь созданной записи: присвоение соответствующим полям таблицы ранее введенную информацию.

8.SaveTalon() - отправление команды в систему управления транзакциями на выполнение транзакции по изменению записи.

9.GetTalon() - возвращение результатов выполнения транзакции и вывод сообщения об ошибке, если транзакция не была завершена.

Выводы

1.Была спроектирована диаграмма сотрудничества для варианта использования «Выдача талона на прием». Во многом от правильности выполнения этого прецедента будет зависеть в дальнейшем успешность оперативного учета и функционирования всей системы в целом.

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

подсистема диаграмма поликлиника

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

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

. Создать пакеты:

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

б) в открывшемся меню выбрать пункт New ?Package (Создать ?Пакет);

в) ввести название пакета Entities (Сущности);

г) действуя аналогично, создать пакеты Boundaries (Границы) и Control (Управление).

. Создать главную диаграмму классов:

а) дважды кликнув мышью на главной диаграмме классов, открыть ее;

б) перетащить пакеты Boundaries и Control, Entities из браузера на диаграмму;

В результате выполнения указанных выше действий была создана главная диаграмма классов (рисунок 5.1).

Рисунок 5.1 - Диаграмма пакетов

Выводы

1.Для разработки диаграммы классов была использована форма пакетов. В результате созданы три основных пакета, объединяющих классы по стереотипам.

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

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

В результате разработанная ранее диаграмма классов примет вид (рисунок 6.1):

Рисунок 6.1 - Диаграмма классов для варианта использования «Выдача талона на прием»

Для добавления новой записи о талоне, работнику регистратуры введет следующую необходимую информацию (атрибуты класса Talon):

-TalonNumber - номер талона;

-DateVidachi - дата выдачи талона;

-DateTalon - дата, на которую выдан талон;

-PatientName - имя пациента;

-DocName - имя врача-специалиста;

-PolicNum - номер полиса пациента;

Назначения методов классов были рассмотрены ранее, в разделах три и четыре.

Выводы

1.Создана диаграмма классов для прецедента «Выдача талона на прием». Из диаграммы видно, что между классами существует определенная семантическая зависимость.

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

Находясь в конкретном состоянии, объект может выполнять определенные действия.

На рисунке 7.1 приведена диаграмма состояния для класса Talon. Диаграмма состояний создается путем выполнения следующих действий:

1.Найти в браузере класс Talon.

2.Щелкнуть на классе правой кнопкой мыши и в открывшемся меню указать пункт Open State Diagram (Открыть диаграмму состояний).

Добавление начального и конечного состояний производится через:

1.Нажатие на кнопку Start State (Начальное состояние) панели инструментов.

2.Далее необходимо поместить это состояние на диаграмму.

.Нажать кнопку End State (Конечное состояние) панели инструментов.

.Поместить это состояние на диаграмму.

Добавление состояний:

1.На панели инструментов нажать кнопку State (Состояние).

2.Поместить состояние на диаграмму.

.Назвать состояние «Инициализация».

4.Выполняя действия 1-3, добавить на диаграмму следующие состояния: «выполнен», «Инициализация», «отменен», «приостановлен».

Рисунок 7.1 - Диаграмма состояний класса Talon

Для добавления описаний состояний необходимо:

1.Дважды щелкнуть мышью на состоянии «Инициализация».

2.Перейти на вкладку Detail (Подробно).

.Щелкнуть правой кнопкой мыши в окне Actions (Действия).

.В открывшемся меню выбрать пункт Insert (Вставить).

.Дважды щелкнуть мышью на новом действии.

.Назвать его StoreData.

.Убедиться, что в окне When (Когда) указан пункт On Entry (На входе).

.Повторив шаги 3 - 7, добавить следующие действия:

-«Считывать информацию», в окне When указать Do;

-«Сохранить талон», указав On Exit;

9.Нажать два раза на ОК, чтобы закрыть спецификацию.

10.Дважды щелкнуть мышью на состоянии «отменен».

.Повторив шаги 2 - 7, добавить действие Store data, указав On Exit (На выходе)

.Нажать два раза на ОК, чтобы закрыть спецификацию.

.Дважды щелкнуть мышью на состоянии «выполнен».

.Повторив шаги со второго по седьмой, добавить действия:

-create talon, указав Do;

-savedata, указав OnEntry;

-save talon, указав On Exit.

Нажать два раза на ОК, чтобы закрыть спецификацию.

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

1.Нажать кнопку Transition (Переход) панели инструментов.

2.Щелкнуть мышью на начальном состоянии.

.Провести линию перехода к состоянию «Инициализация».

.Повторив шаги с первого по третий, создать следующие переходы:

-от состояния «Инициализация» к состоянию «приостановлен»;

-от «приостановлен» к состоянию «выполнен»;

-от состояния «Инициализация» к состоянию «отменен»;

-от состояния «отменен» к конечному состоянию;

-от состояния «выполнен» к конечному состоянию;

5.На панели инструментов нажать кнопку Transition to Self (Переход к себе).

6.Щелкнуть мышью на состоянии «приостановлен».

Для добавления описания переходов необходимо:

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

2.В поле Event (Событие) ввести фразу «Добавить талон».

.Щелкнув на кнопке ОК, закрыть окно спецификации.

.Повторив шаги с первого по третий, добавить событие «Отменить создание талона» к переходу между состояниями «Инициализация» и «отменен».

.Дважды щелкнув мышью на переходе от состояния «приостановлен» к состоянию «выполнен», открыть окно его спецификации.

.В поле Event (Событие) ввести фразу «Добавить недостающую информацию».

.Перейти на вкладку Detail (Подробно).

.В поле Condition (Условие) введите «нет пустых полей».

.Щелкнув на кнопке ОК, закрыть окно спецификации.

. Дважды щелкнуть мышью на рефлексивном переходе (Transition to Self) состояния «приостановлен».

. В поле Event (Событие) ввести фразу «Добавить информацию».

. Перейти на вкладку Detail (Подробно).

. В поле Condition (Условие) ввести «есть пустые поля».

. Щелкнув на кнопке ОК, закрыть окно спецификации.

На рисунке 7.2 представлена диаграмма компонентов. Она отображает распределение классов и объектов по компонентам при физическом проектировании.

Рисунок 7.2 - Диаграмма компонентов

Выводы

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

2.Из диаграммы компонентов видно, что разрабатываемая подсистема будет работать по технологии «клиент-сервер». К клиентской части приложения относятся классы DocForm и TalonForm и объекты этих классов. К серверной части приложения отнесены все остальные классы и их объекты.

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

Данная диаграмма служит для моделирования работающих узлов (аппаратных средств, англ. node) и артефактов, развёрнутых на них.

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

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

2.Нажать кнопку Processor (Процессор) панели инструментов.

.Щелкнув мышью на диаграмме, поместить туда процессор.

.Ввести имя процессора «Сервер БД».

.Повторив шаги 2-4, добавить следующие процессоры: «Сервер приложения», «рабочая станция №1», «рабочая станция №2».

.На панели инструментов нажать кнопку Device (Устройство).

.Щелкнув мышью на диаграмме, поместить туда устройство.

.Назвать его «Принтер».

Для добавления связей:

1.Нажать кнопку Connection (Связь) панели инструментов.

2.Щелкнуть мышью на процессоре «Сервер БД».

.Провести линию связи к процессору «Сервер приложения».

.Повторив шаги 1 ? 3, добавить следующие связи:

-от процессора «Сервер приложения» к процессору «рабочая станция №1»;

-от процессора «Сервер приложения» к процессору «рабочая станция №2»;

-от процессора «Сервер приложения» к устройству «Принтер».

Для добавления процессов:

1.Щелкнуть правой кнопкой мыши на процессоре «Сервер приложения» в браузере.

2.В открывшемся меню выберать пункт New ? Process (Создать ? Процесс).

.Ввести имя процесса ? TalonServerExe.

.Повторить шаги 1 ? 3, добить процессы:

-процесс TalonExe на процессоре «рабочая станция №1»;

-процесс ATMClientExe на процессоре «рабочая станция №2».

Для показа процессов на диаграмме необходимо:

1.Щелкнуть правой кнопкой мыши на процессоре «Сервер приложения».

2.В открывшемся меню выбрать пункт Show Processes (Показать процессы).

.Повторив шаги 1 и 2, показать процессы на следующих процессорах:

-рабочая станция №1;

-рабочая станция №2.

В результате проведения действий, описанных выше, была создана диаграмма размещения (рисунок 8.1).

Рисунок 8.1 - Диаграмма размещения

Выводы

1.Из диаграммы видно, что информационная подсистема регистратуры поликлиники построена на технологии «клиент-сервер». Это позволяет организовать одновременный доступ нескольких работников регистратуры к базе данных.

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

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

В RationalRose 2000 предусмотрена возможность генерации программного кода C++.

Для генерации программного кода на стандартном C++ необходимо:

. Создать компоненты (необязательно).

. Определить компоненты для классов (необязательно).

. Установить свойства генерации программного кода

(необязательно).

. Выбрать класс или компонент для генерации на диаграмме Классов

или Компонентов.

. Выбрать в меню Tools ?C++ ?Code Generation(рисунок 9.1)

. Выбрать в меню Tools ?C++ ?Browse Header или Browse Body

для просмотра сгенерированного программного кода.

Первый этап процесса генерации программного кода - создание

компонентов для классов. Это файлы с расширениями *. cpp (файл

реализации) и *. h (заголовочный файл). В C++ данный этап не является

обязательным. Если не описать компоненты, Rational Rose сгенерирует

файлы *. cpp и *. h для каждого класса. Тем не менее, настоятельно

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

классов на компоненты и моделировать зависимости между компонентами.

После создания компонентов и отображения классов, следующим

шагом является установка свойств генерации программного кода для

классов, компонентов, операций и других элементов модели.

Рисунок 9.1 - Окно генерации кода ANSI C++

Вывод

1.На основании созданных моделей компонентов, представленных в проекте, была произведена генерация программного кода на языке Visual C++. Сгенерированы файлы с расширениями .chh и .h для каждого класса.

ЗАКЛЮЧЕНИЕ

В результате выполнения курсового проекта была разработана объектно-ориентированная модель информационной подсистемы для регистратуры ЦРБ. Работа написана с помощью языка UML, с использованием среды разработки Rational Rose 2000. Общий объем разработанной подсистемы и сгенерированных файлов С++ составляет 2,53 Мбайт.

В результате работы созданы следующие диаграммы:

-прецедентов;

-последовательности;

-сотрудничества;

-классов;

-состояния для классов;

-компонентов;

-размещения.

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

Данная информационная подсистема построена на технологии «клиент-сервер». Это позволяет организовать одновременную работу нескольких работников регистратуры к базе данных.

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

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

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

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

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

2.Боггс У., Боггс М. UML и Rational Rose: Пер. с англ. - М.: Издательство «Лори», 2000.- 581 с., ил.

.Буч Г., Рамбо Д., Джекобсон А. UML: специальный справочник. - СПб.: Питер, 2002.- 432 с., ил.

.Ларман К. применение UML и шаблонов проектирования: Пер. с англ. - М.: Издательский дом «Вильямс», 2001. - 496 с., ил.

.ГОСТ 2.105-95 ЕСКД. Общие требования к текстовым документам

.ГОСТ 2.004-88 ЕСКД. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах ввода ЭВМ

.ГОСТ 2.104-68 ЕСКД. Основные надписи

.ГОСТ 2.106-68 ЕСКД. Текстовые документы

.ГОСТ 2.109-73 ЕСКД. Основные требования к чертежам

.ГОСТ 2.301-68 ЕСКД. Форматы

Приложение А

Листинги кода приложения, сгенерированные для разработанной информационной подсистемы bolnica.

А1. DBmanager.h

#ifndef DBMANAGER_H_HEADER_INCLUDED_B200D405

#define DBMANAGER_H_HEADER_INCLUDED_B200D405Talon;

//##ModelId=4DE4816102D8DBmanager

{

public:

//##ModelId=4DE481D003D7

SaveInfo();

//##ModelId=4DE4B79503D8

EnterInfo();

//##ModelId=4DE482E20232

Transaction *theTransaction;

//##ModelId=4DE482F20369

Talon *theTalon;

};

#endif /* DBMANAGER_H_HEADER_INCLUDED_B200D405 */

А2. DBmanager.cpp

#include "DBmanager.h"

#include "Talon.h"

//##ModelId=4DE481D003D7::SaveInfo()

{}

//##ModelId=4DE4B79503D8::EnterInfo()

{}

А3. DocForm.h

#ifndef DOCFORM_H_HEADER_INCLUDED_B200EE67

#define DOCFORM_H_HEADER_INCLUDED_B200EE67

// Форма выбора врача

//##ModelId=4DE3F14202F2DocForm

{

public:

//##ModelId=4DE3F1A10340

Boolean Create();

//##ModelId=4DE4824302B5

TalonForm *theTalonForm;

private:

//##ModelId=4DE47679006F

String listDoc;

//##ModelId=4DE476A5026A

Long Price;};

#endif /* DOCFORM_H_HEADER_INCLUDED_B200EE67 */

А4. DocForm.cpp

#include "DocForm.h"

//##ModelId=4DE3F1A10340DocForm::Create()

{}

А5. Talon1.cpp

#include "Talon.h"

//##ModelId=4DE3F3090076Talon::CreateT()

{}

//##ModelId=4DE3F317020D::EnterInfo()

{}

//##ModelId=4DE3F35301C6Talon::GetTalon()

{}

А6. Talon.h

#ifndef TALON_H_HEADER_INCLUDED_B200AB9B

#define TALON_H_HEADER_INCLUDED_B200AB9B

//##ModelId=4DE3F2F90026Talon

{

public:

//##ModelId=4DE3F3090076

Boolean CreateT();

//##ModelId=4DE3F317020D

EnterInfo();

//##ModelId=4DE3F35301C6

String GetTalon();

private:

//##ModelId=4DE4777E0379

Integer TalonNumber;

//##ModelId=4DE4779301B4

Date DateVidachi;

//##ModelId=4DE477B201C2

Date DateTalon;

//##ModelId=4DE477C0007B

String PatientName;

//##ModelId=4DE477DA029F

String DocName;

//##ModelId=4DE4AEBB02BF

String PolicNum;

};

#endif /* TALON_H_HEADER_INCLUDED_B200AB9B */

А7. TalonForm.cpp

#include "TalonForm.h"

//##ModelId=4DE3F20901DDTalonForm::OpenForm()

{}

//##ModelId=4DE3F2240361, Date:Date,Time:Date,DateTalon:Date TalonForm::EnterData(Integer TalonNumber, String Name, String Doc)

{}

//##ModelId=4DE3F22A0308TalonForm::SaveInfo()

{}

А8. TalonForm.h

#ifndef TALONFORM_H_HEADER_INCLUDED_B2008678

#define TALONFORM_H_HEADER_INCLUDED_B2008678

// Форма создания нового талона

//##ModelId=4DE3F1D200B9

class TalonForm

{

public:

//##ModelId=4DE3F20901DD

Boolean OpenForm();

//##ModelId=4DE3F2240361

String, Date:Date,Time:Date,DateTalon:Date EnterData(Integer TalonNumber, String Name, String Doc);

// Сохранение введенной в форму информации

//##ModelId=4DE3F22A0308

Boolean SaveInfo();

private:

//##ModelId=4DE476C5011E

String Name;

//##ModelId=4DE476D50285

String Doc;

//##ModelId=4DE476EB02AE

String Adress;

//##ModelId=4DE477020356

Date Date;

//##ModelId=4DE47712033B

Date Time;

//##ModelId=4DE47CF402C3

Integer TalonNumber;

//##ModelId=4DE47D050334

Date DateTalon;};

#endif /* TALONFORM_H_HEADER_INCLUDED_B2008678 */

А9. TalonItem.cpp

#include "TalonItem.h"

//##ModelId=4DE47C430165TalonItem::Create()

{}

//##ModelId=4DE47C4E01D1TalonItem::EnterData(Integer ID)

{}

//##ModelId=4DE47C5C0115TalonItem::GetTalon()

{}

А10. TalonItem.h

#ifndef TALONITEM_H_HEADER_INCLUDED_B200DEC5

#define TALONITEM_H_HEADER_INCLUDED_B200DEC5

//##ModelId=4DE47BC6025BTalonItem

{

public:

//##ModelId=4DE47C430165

Boolean Create();

//##ModelId=4DE47C4E01D1

Boolean EnterData(Integer ID = 0);

//##ModelId=4DE47C5C0115

String GetTalon();

private:

//##ModelId=4DE47C0701C4

Integer ItemID;

//##ModelId=4DE47C1C032E

String Description;

};

#endif /* TALONITEM_H_HEADER_INCLUDED_B200DEC5 */

А11. Transaction.cpp

#include "Transaction.h"

//##ModelId=4DE3F2E10263Transaction::SaveTalon(integer TalonNum)

{}

//##ModelId=4DE3F35A0265Transaction::SaveInfo()

{}

//##ModelId=4DE4B7E0032C::EnterInfo()

{}

А12. Transaction.h

#ifndef TRANSACTION_H_HEADER_INCLUDED_B200E029

#define TRANSACTION_H_HEADER_INCLUDED_B200E029

//##ModelId=4DE3F27F014CTransaction

{

public:

//##ModelId=4DE3F2E10263

Boolean SaveTalon(integer TalonNum);

//##ModelId=4DE3F35A0265

Integer SaveInfo();

//##ModelId=4DE4B7E0032C

EnterInfo();

};

#endif /* TRANSACTION_H_HEADER_INCLUDED_B200E029 */