Разработка объектно-ориентированной модели информационной подсистемы для регистратуры ЦРБ
Министерство образования и науки Российской Федерации
ГОУ ВПО СЕВЕРО-КАВКАЗСКИЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ
Факультет информационных технологий и телекоммуникаций
Кафедра прикладной информатики
ПОЯСНИТЕЛЬНАЯ
ЗАПИСКА
К
КУРСОВОМУ ПРОЕКТУ НА ТЕМУ:
Разработка
объектно-ориентированной модели информационной подсистемы для регистратуры ЦРБ
Автор курсового проекта
Д.О. Никифорова
Направление: 080800.62
«Прикладная информатика»
Группа: ПИБ-081
Руководитель проекта:
к.т.н., доцент В.Ф. Ляхов
Ставрополь,
2011
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
. КРАТКАЯ ХАРАКТЕРИСТИКА
ПРЕДМЕТНОЙ ОБЛАСТИ
.1 Общая характеристика
.2 Актуальность
разрабатываемой подсистемы
.3 Формулировка задач
проектирования
. СОЗДАНИЕ ДИАГРАММЫ
ПРЕЦЕДЕНТОВ
. СОЗДАНИЕ ДИАГРАММЫ
ПОСЛЕДОВАТЕЛЬНОСТИ
. СОЗДАНИЕ ДИАГРАММЫ
СОТРУДНИЧЕСТВА
. СОЗДАНИЕ ДИАГРАММЫ
КЛАССОВ
. ДОБАВЛЕНИЕ ДЕТАЛЕЙ К
ОПИСАНИЯМ ОПЕРАЦИЙ И ОПРЕДЕЛЕНИЕ АТРИБУТОВ КЛАССОВ
. СОЗДАНИЕ ДИАГРАММЫ
СОСТОЯНИЙ ДЛЯ КЛАССОВ И ДИАГРАММЫ КОМПОНЕНТОВ
. СОЗДАНИЕ ДИАГРАММЫ
РАЗМЕЩЕНИЯ
. ГЕНЕРАЦИЯ ПРОГРАММНОГО
КОДА C++
ЗАКЛЮЧЕНИЕ
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
Приложение А. Листинги
сгенерированных кодов для информационной подсистемы bolnica
ВВЕДЕНИЕ
UML (англ.
<#"522226.files/image001.gif">
Рисунок 2.1 - Диаграмма вариантов использования
«Регистратура»
6. Используя кнопку Actor (действующее лицо) панели
инструментов, поместить на диаграмму новое действующее лицо.
. Ввести имя «Работник регистратуры».
8. Повторив шаги шесть и семь, поместить на диаграмму
еще одного актера действующее лицо «Пациент»
9. С помощью кнопки Unidirectional Association (Однонаправленная
ассоциация) добавить связь между действующим лицом «Работник регистратуры» и
всеми вариантами использования, исключая прецедент «Узнать расписание работы
врачей»
. Аналогично добавить ассоциации между действующим лицом
«Пациент» и вариантами использования «Просмотр данных о пациенте» и «Узнать
расписание работы врачей».
Рассмотренные выше варианты использования инициируют
последовательность действий (транзакций) в базе данных в ответ на действия со
стороны работника регистратуры поликлиники [1].
Выводы
1. В результате проведения всех описанных выше действий была
создана диаграмма прецедентов, состоящая из двух актеров и пяти вариантов
использования. Основным действующим лицом является Работник регистратуры. Он
выполняет четыре действия: «Выдать талон на прием», «Добавить пациента в БД »,
«Изменить данные о пациенте», «Просмотр данных о пациенте».
. В результате анализа приведенной выше диаграммы вариантов
использования выяснилось, что наиболее важной и сложно реализуемой задачей
разработки информационной подсистемы является реализация выдачи талонов на
прием к врачу-специалисту, так как это является основным видом работы
регистратуры поликлиники.
3. СОЗДАНИЕ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ
На диаграмме последовательности изображено упорядоченное во
времени взаимодействие объектов [1].
Рассмотрим вариант использования «Выдать талон на прием».
Диаграмма последовательности приведена на рисунке 3.1.
На приведенной выше диаграмме выделены следующие объекты
соответствующих классов:
- выбор врача - объект класса DocForm, отвечающий за выбор
необходимого врача-специалиста;
- форма заполнения талона - объект класса TalonForm - конкретной формы ввода
данных о выдаваемом талоне;
- управляющий БД - объект управляющего
класса DBManager, выполняющий функции СУБД;
- запись о выдаче талона в БД - объект
класса Talon, инкапсулирующего в себе всю необходимую информацию о выдаваемом
талоне(имя врача и пациента, дата и время приема, др.);
- управляющий транзакциями - объект класса TransactionManager, берущий на себя функции
СУБД по управлению транзакциями [2].
Последовательность действий выглядит следующим образом:
1. Работник регистратуры создает новую запись о выдаваемом
талоне в БД.
2. Сначала он открывает необходимую форму для выбора
врача, а затем для заполнения талона.
. Вводит все необходимые поля в открытую форму.
. Сохраняет введенные данные.
. При этом информация отправляется в СУБД, которая
обозначена на диаграмме как «Управляющий БД».
. СУБД создает новую пустую запись.
Рисунок 3.1 - Диаграмма последовательности для варианта
использования «Выдать талон на прием»
1. 7. Генерируется изменение значения полей в соответствии с
введенными работником регистратуры данными.
8. Передает эту запись системе управления транзакциями,
которая обозначена на диаграмме как «Управляющий транзакциями».
. Система управления транзакциями осуществляет транзакцию.
. Система управления транзакциями возвращает сообщение
об успешности проведения транзакции или ошибке при её выполнении.
Выводы
1. Была разработана диаграмма последовательности для варианта
использования «Выдать талон на прием». Этот вариант использования является
наиболее важной и наиболее сложно реализуемой задачей информационной
подсистемы.
. При создании диаграммы были созданы пять классов: два
управляющих, два «граничных» и один «сущность».
4. СОЗДАНИЕ ДИАГРАММЫ СОТРУДНИЧЕСТВА
Разработанная в данном курсовом проекте диаграмма
сотрудничества описывает процесс выдачи талона на прием к врачу-специалисту
(рисунок 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() - возвращение результатов выполнения
транзакции и вывод сообщения об ошибке, если транзакция не была завершена.
Рисунок 4.1 - Диаграмма сотрудничества для варианта
использования «Выдача талона на прием»
Выводы
1. Была спроектирована диаграмма сотрудничества для варианта
использования «Выдача талона на прием». Во многом от правильности выполнения
этого прецедента будет зависеть в дальнейшем успешность оперативного учета и
функционирования всей системы в целом.
2. Да диаграмму были добавлены девять сообщений,
соотнесенные с соответствующими операциями.
5. СОЗДАНИЕ ДИАГРАММЫ КЛАССОВ
Для создания диаграммы классов необходимо выполнить следующую
последовательность действий:
. Создать пакеты:
а) путем нажатия правой клавиши мыши на логическом
представлении браузера;
б) в открывшемся меню выбрать пункт New ►Package
(Создать ►Пакет);
в) ввести название пакета Entities (Сущности);
г) действуя аналогично, создать пакеты Boundaries (Границы) и
Control (Управление).
. Создать главную диаграмму классов:
а) дважды кликнув мышью на главной диаграмме классов, открыть
ее;
б) перетащить пакеты Boundaries и Control, Entities из
браузера на диаграмму [3];
В результате выполнения указанных выше действий была создана
главная диаграмма классов (рисунок 5.1).
Рисунок 5.1 - Диаграмма пакетов
Выводы
1. Для разработки диаграммы классов была использована форма
пакетов. В результате созданы три основных пакета, объединяющих классы по
стереотипам.
2. Была разработана диаграмма пакетов, являющаяся одной
из форм диаграммы классов.
6. ДОБАВЛЕНИЕ ДЕТАЛЕЙ К ОПИСАНИЯМ ОПЕРАЦИЙ И
ОПРЕДЕЛЕНИЕ АТРИБУТОВ КЛАССОВ
После создания диаграммы классов для
варианта использования «Выдача талона на прием» необходимо произвести ее
заполнение. Языком программирования был выбран C++. Поэтому к классам можно
добавить необходимые параметры операций, типы данных и типы возвращаемых
значений.
В результате разработанная ранее диаграмма классов примет вид
,представленный на рисунке 6.1.
Для добавления новой записи о талоне, работнику регистратуры
введет следующую необходимую информацию (атрибуты класса Talon):
- TalonNumber - номер талона;
- DateVidachi - дата выдачи талона;
- DateTalon - дата, на которую выдан
талон;
- PatientName -
имя пациента;
- DocName - имя врача-специалиста;
- PolicNum - номер полиса пациента;
Назначения методов классов были рассмотрены ранее, в разделах
три и четыре [2].
Выводы
1. Создана диаграмма классов для прецедента «Выдача талона
на прием». Из диаграммы видно, что между классами существует определенная
семантическая зависимость.
2. На диаграмме для каждой семантической связи также
наглядно отображена множественность, показывающая, сколько экземпляров одного
класса взаимодействует с помощью этой связи с одним экземпляром другого класса
в определенный момент времени.
информационный программа автоматизация поликлиника
Рисунок 6.1 - Диаграмма классов для варианта использования
«Выдача талона на прием»
7. СОЗДАНИЕ ДИАГРАММЫ СОСТОЯНИЙ ДЛЯ КЛАССОВ И
ДИАГРАММЫ КОМПОНЕНТОВ
Находясь в конкретном состоянии, объект может выполнять
определенные действия.
На рисунке 7.1 приведена диаграмма состояния для класса Talon. Диаграмма состояний
создается путем выполнения следующих действий:
1. Найти в браузере класс Talon.
2. Щелкнуть на классе правой кнопкой мыши и в
открывшемся меню указать пункт Open State Diagram (Открыть диаграмму
состояний).
Добавление начального и конечного состояний производится
через:
1. Нажатие на кнопку Start State (Начальное состояние)
панели инструментов.
2. Далее необходимо поместить это состояние на
диаграмму.
. Нажать кнопку End State (Конечное состояние) панели
инструментов.
. Поместить это состояние на диаграмму.
Добавление состояний:
1. На панели инструментов нажать кнопку State (Состояние).
2. Поместить состояние на диаграмму.
. Назвать состояние «Инициализация».
. Выполняя действия 1-3, добавить на диаграмму следующие
состояния: «Выполнен», «Инициализация», «Отменен», «Приостановлен».
1. Дважды щелкнуть мышью на состоянии «Инициализация».
2. Перейти на вкладку Detail (Подробно).
. Щелкнуть правой кнопкой мыши в окне Actions
(Действия).
. В открывшемся меню выбрать пункт Insert (Вставить).
Рисунок 7.1 - Диаграмма состояний класса Talon
5. Дважды щелкнуть мышью на новом действии.
6. Назвать его 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. от состояния «Выполнен» к конечному состоянию;
6. На панели инструментов нажать кнопку Transition to Self
(Переход к себе).
. Щелкнуть мышью на состоянии «Приостановлен».
Для добавления описания переходов необходимо:
1. Дважды щелкнув мышью на переходе от «Инициализация» к
состоянию «Приостановлен», открыть окно спецификации перехода.
2. В поле Event (Событие) ввести фразу «Добавить талон».
. Щелкнув на кнопке ОК, закрыть окно спецификации.
. Повторив шаги с первого по третий, добавить событие
«Отменить создание талона» к переходу между состояниями «Инициализация» и
«Отменен».
. Дважды щелкнув мышью на переходе от состояния
«Приостановлен» к состоянию «Выполнен», открыть окно его спецификации.
. В поле Event (Событие) ввести фразу «Добавить
недостающую информацию».
. Перейти на вкладку Detail (Подробно).
. В поле Condition (Условие) введите «нет пустых
полей».
. Щелкнув на кнопке ОК, закрыть окно спецификации.
. Дважды щелкнуть мышью на рефлексивном переходе
(Transition to Self) состояния «Приостановлен».
. В поле Event (Событие) ввести фразу «Добавить
информацию».
. Перейти на вкладку Detail (Подробно).
. В поле Condition (Условие) ввести «есть пустые
поля».
. Щелкнув на кнопке ОК, закрыть окно спецификации [1].
На рисунке 7.2 представлена диаграмма компонентов. Она
отображает распределение классов и объектов по компонентам при физическом проектировании.
Рисунок 7.2 - Диаграмма компонентов для реализации классов
варианта использование «Выдать талон на прием»
Выводы
1. Была создана диаграмма состояний для класса Talon. Согласно этой диаграмме
объекты данного класса могут находиться в одном из четырех состояний:
инициализации, приостановки, отмены и завершения. Была также разработана
диаграмма компонентов, разделяющая систему на 2 компонента: клиент и сервер.
2. Из диаграммы компонентов видно, что разрабатываемая
подсистема будет работать по технологии «клиент-сервер». К клиентской части
приложения относятся классы DocForm и TalonForm и объекты этих классов. К серверной части
приложения отнесены все остальные классы и их объекты.
8. СОЗДАНИЕ ДИАГРАММЫ РАЗМЕЩЕНИЯ
Данная диаграмма служит для моделирования работающих узлов
(аппаратных средств, англ. node) и артефактов, развёрнутых на них.
Для заполнения диаграммы размещения необходимо выполнить
следующую последовательность действий:
1. Дважды щелкнув мышью на представлении размещения в
браузере, открыть диаграмму размещения.
2. Нажать кнопку Processor (Процессор) панели
инструментов.
. Щелкнув мышью на диаграмме, поместить туда
процессор.
. Ввести имя процессора «Сервер БД».
5. Повторив шаги 2-4, добавить следующие процессоры:
«Сервер приложения», «рабочая станция №1», «рабочая станция №2».
. На панели инструментов нажать кнопку Device
(Устройство).
. Щелкнув мышью на диаграмме, поместить туда
устройство.
. Назвать его «Принтер» [4].
Для добавления связей:
1. Нажать кнопку Connection (Связь) панели инструментов.
2. Щелкнуть мышью на процессоре «Сервер БД».
. Провести линию связи к процессору «Сервер
приложения».
- от процессора «Сервер приложения» к процессору
«рабочая станция №1»;
- от процессора «Сервер приложения» к
процессору «рабочая станция №2»;
- от процессора «Сервер приложения» к
устройству «Принтер».
Для добавления процессов:
1. Щелкнуть правой кнопкой мыши на процессоре «Сервер
приложения» в браузере.
2. В открывшемся меню выберать пункт New → Process
(Создать → Процесс).
3. Ввести имя процесса − TalonServerExe.
. Повторить шаги 1 − 3, добить процессы:
- процесс TalonExe на процессоре «рабочая станция №1»;
- процесс ATMClientExe на процессоре
«рабочая станция №2» [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 для просмотра сгенерированного программного кода [1].
Первый этап процесса генерации программного кода - создание
компонентов для классов. Это файлы с расширениями *. cpp (файл
реализации) и *. h (заголовочный файл). В C++ данный этап не
является обязательным. Если не описать компоненты, Rational Rose сгенерирует
файлы *. cpp и *. h для каждого класса. Тем не менее,
настоятельно рекомендуется создавать компоненты, что позволит управлять
отображением классов на компоненты и моделировать зависимости между
компонентами. После создания компонентов и отображения классов, следующим шагом
является установка свойств генерации программного кода для классов,
компонентов, операций и других элементов модели [3].
Вывод
1. На основании созданных моделей компонентов,
представленных в проекте, была произведена генерация программного кода на языке
Visual C++. Сгенерированы файлы с
расширениями .chh и .h для каждого класса.
Рисунок 9.1 - Окно генерации кода ANSI C++
ЗАКЛЮЧЕНИЕ
В результате выполнения курсового проекта была разработана
объектно-ориентированная модель информационной подсистемы для регистратуры ЦРБ.
Работа написана с помощью языка 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_B1FDABDA
#define DBMANAGER_H_HEADER_INCLUDED_B1FDABDA
//##ModelId=4DE4816102D8DBmanager
{:
//##ModelId=4DE481D003D7();
//##ModelId=4E0224750112();
//##ModelId=4E0224A302C9();
};
#endif /* DBMANAGER_H_HEADER_INCLUDED_B1FDABDA */
А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=4DE3F1A10340Create();
//##ModelId=4DE4824302B5*theTalonForm;
:
//##ModelId=4DE47679006FlistDoc;
//##ModelId=4DE476A5026APrice;};
#endif /* DOCFORM_H_HEADER_INCLUDED_B200EE67 */
А4. DocForm.cpp
#include "DocForm.h"
//##ModelId=4DE3F1A10340DocForm::Create()
{}
А5. Talon.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=4DE3F3090076CreateT();
//##ModelId=4DE3F317020D();
//##ModelId=4DE3F35301C6GetTalon();:
//##ModelId=4DE4777E0379TalonNumber;
//##ModelId=4DE4779301B4DateVidachi;
//##ModelId=4DE477B201C2DateTalon;
//##ModelId=4DE477C0007BPatientName;
//##ModelId=4DE477DA029FDocName;
//##ModelId=4DE4AEBB02BFPolicNum;
};
#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
{:
//##ModelId=4DE3F20901DDOpenForm();
//##ModelId=4DE3F2240361,
Date:Date,Time:Date,DateTalon:Date EnterData(Integer TalonNumber, String Name,
String Doc);
// Сохранение введенной в форму информации
//##ModelId=4DE3F22A0308
:
//##ModelId=4DE476C5011EName;
//##ModelId=4DE476D50285Doc;
//##ModelId=4DE476EB02AEAdress;
//##ModelId=4DE477020356Date;
//##ModelId=4DE47712033BTime;
//##ModelId=4DE47CF402C3TalonNumber;
//##ModelId=4DE47D050334DateTalon;};
#endif /* TALONFORM_H_HEADER_INCLUDED_B2008678 */
#endif /* TALONITEM_H_HEADER_INCLUDED_B200DEC5 */
А9. Transaction.cpp
#include "Transaction.h"
//##ModelId=4DE3F2E10263Transaction::SaveTalon(integer
TalonNum)
{}
//##ModelId=4DE3F35A0265Transaction::SaveInfo()
{}
//##ModelId=4DE4B7E0032C::EnterInfo()
{}
А10. Transaction.h
#ifndef TRANSACTION_H_HEADER_INCLUDED_B200E029
#define TRANSACTION_H_HEADER_INCLUDED_B200E029
//##ModelId=4DE3F27F014CTransaction
{:
//##ModelId=4DE3F2E10263SaveTalon(integer
TalonNum);
//##ModelId=4DE3F35A0265SaveInfo();
//##ModelId=4DE4B7E0032C();
};
#endif /* TRANSACTION_H_HEADER_INCLUDED_B200E029
*/