Научная статья на тему 'РАЗРАБОТКА КЛИЕНТ-СЕРВЕРНОЙ АРХИТЕКТУРЫ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ УЧЕТА ПАЦИЕНТОВ КЛИНИЧЕСКОЙ БОЛЬНИЦЫ С ИСПОЛЬЗОВАНИЕМ ПАТТЕРНА MVC'

РАЗРАБОТКА КЛИЕНТ-СЕРВЕРНОЙ АРХИТЕКТУРЫ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ УЧЕТА ПАЦИЕНТОВ КЛИНИЧЕСКОЙ БОЛЬНИЦЫ С ИСПОЛЬЗОВАНИЕМ ПАТТЕРНА MVC Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
87
13
i Надоели баннеры? Вы всегда можете отключить рекламу.
Ключевые слова
ИНФОРМАЦИОННАЯ СИСТЕМА / АРХИТЕКТУРА / КЛАССЫ / BOUML / INFORMATION SYSTEM / ARCHITECTURE / CLASSES

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Федотов В.А.

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

i Надоели баннеры? Вы всегда можете отключить рекламу.
iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

DEVELOPMENT OF CLIENT-SERVER ARCHITECTURE OF THE INFORMATION SYSTEM FOR THE REGISTRATION OF PATIENTS AT A CLINICAL HOSPITAL USING THE MVC PATTERN

The article is devoted to the development of the client-server architecture of the information system.

Текст научной работы на тему «РАЗРАБОТКА КЛИЕНТ-СЕРВЕРНОЙ АРХИТЕКТУРЫ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ УЧЕТА ПАЦИЕНТОВ КЛИНИЧЕСКОЙ БОЛЬНИЦЫ С ИСПОЛЬЗОВАНИЕМ ПАТТЕРНА MVC»

Использованные источники:

1. Проблемы экономики и управления предприятиями, отраслями, комплексами: монография. Книга 30 / Е. Н. Волк, Б. Даулетбаков, Е. В. Джамай и др. / Под общ. ред. С. С. Чернова. — Новосибирск: Издательство ЦРНС, 2016. — 220 с.

2. Савенков И. Е. Понятие и сущность мотивации и стимулирования трудовых ресурсов предприятия [Текст] / И. Е. Савенков // Вестник тверского государственного технического университета. — 2014. — С. 215.

3. Теоретико-прикладные аспекты управления персоналом в малом и среднем бизнесе: [Текст] / колл. монография / Н. Н. Богдан, О. В. Горшкова, М. Ю. Дикусарова, М. Г. Масилова, Е. А. Могилёвкин, А. С. Новгородов, З. В. Якимова. - Владивосток: Изд-во ВГУЭС, 2015. - 240c.

УДК 004

Федотов В.А. студент 2 курса

факультет «Информационные системы и технологии» Северный Арктический федеральный университет Высшая школа информационных технологий и

автоматизированных систем Россия, г Архангельск РАЗРАБОТКА КЛИЕНТ-СЕРВЕРНОЙ АРХИТЕКТУРЫ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ УЧЕТА ПАЦИЕНТОВ КЛИНИЧЕСКОЙ БОЛЬНИЦЫ С ИСПОЛЬЗОВАНИЕМ ПАТТЕРНА

MVC

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

Ключевые слова: Информационная система, архитектура, классы, Bouml.

Fedotov V.A.

Student, 2year, faculty "Information Systems and Technology" Northern Arctic Federal University, Graduate School of Information

Technology and Automated Systems Russia, Arkhangelsk

DEVELOPMENT OF CLIENT-SERVER ARCHITECTURE OF THE INFORMATION SYSTEM FOR THE REGISTRATION OF PATIENTS AT A CLINICAL HOSPITAL USING THE MVC PATTERN

Annotation: The article is devoted to the development of the client-server architecture of the information system.

Keywords: Information system, architecture, classes, Bouml.

ВЕДЕНИЕ

Клиническая больница. Словесное описание предметной области: на каждого вновь поступившего больного заводится карточка медицинской статистики: ФИО больного, пол, возраст, предварительный диагноз, как поступил больной (направление поликлиники, доставлен скорой помощью и т.п.), дата поступления, прочее описание: примерный рост, цвет волос, особые приметы, примерный возраст, номер палаты, в которую положен больной. Информация о больном может быть неполной, если он не может ответить на вопросы. За время лечения в больнице больной может быть переведён в разные палаты, необходимо знать дату перевода, номер и телефон палаты. После окончания лечения фиксируется дата выписки и причина выписки либо другой исход (полное излечение, направлен в санаторий и т.п.).

1 ВАРИНТЫ ИСПОЛЬЗОВАНИЯ ИС

Составим диаграмму вариантов использования, которая описывает, как можно использовать данную информационную систему. Поместим два действующих лица на диаграмму вариантов использования. Первое действующее лицо получает название «Administrator», а второе - «Doctor». Действующие лица представлены на рисунке 1.

Рисунок 1 - Актеры

Далее определим каждому действующему лицу варианты использования информационной системой. Администратор будет использовать информационную систему для управления данными о больных (management account). Вариант использования администратора представлен на рисунке 2.

Рисунок 2 - Варианты использования

Доктор будет использовать информационную систему для: создания новой медицинской карты на каждого больного (management a medical record), создания информации о выписке больного (management statement), управления информацией о количестве людей в палате (management a ward), управления информацией о переводе больного из одной палаты в другую (management a transfer). Варианты использования доктора представлены на рисунке 3.

Рисунок 3 - Варианты использования

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

Авторизация (Authorization), представленный на рисунке 4.

Рисунок 4 - Авторизация

Используем отношения зависимости на диаграмме вариантов использования, которые предусматривают включение и расширение вариантов использования. Например, вариант использования Создание новой медицинской карты на каждого больного (management a medical card) включает такие варианты использования, как: добавление информации в карте (Add data Card), удаление информации в карте (Delete data Card), изменение информации в карте (Change data Card), просмотр информации в карте (View data Card).

Вариант использования Management statement: добавление информации о выписке (Add data Statement), удаление информации о выписке (Delete data Statement), изменение информации о выписке (Change data Statement), просмотр информации о выписке (View data Statement).

Вариант использования Management ward: добавление информации о палате (Add data Ward), удаление информации о палате (Delete data Ward), изменение информации о палате (Change data Ward), просмотр информации о палате (View data Ward).

Вариант использования Management transfer: добавление информации о переводе (Add data Transfer), удаление информации о переводе (Delete data Transfer), изменение информации о переводе (Change data Transfer), просмотр информации о переводе (View data Transfer).

Также все будут иметь зависимость <<Include>>.

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

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

2 проектирование архитектуры ис

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

Ранее для варианта использования Управления данными о больных (management account) были поставлены функциональные требования к информационной системе для возможности добавления, изменения, удаления и просмотра данных. Эти функции представлены на рисунке 6.

Рисунок 6 - Класс Управления данными о больных

Для реализации этих требований разработаем классы с атрибутами для хранения данных и операциями для выполнения действий с этими данными.

Будем использовать паттерн МоёеЬУш^^СойгоПег, который позволяет разделить данные приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента: модель, вид и контроллер.

Начнем проектирование с модели. Добавим класс Account, в соответствии с рисунком 7.

Account

Рисунок 7 - Класс Account

Добавим соответствующие атрибуты в класс Account, которые будут хранить данные о номере аккаунта (idAccount), имени (first_name), фамилии (last name), дате рождения (birth day), в соответствии с рисунком 8.

- first_name : string

- Iast_name : string

Рисунок 8 - Атрибуты класса Account

Добавим следующие геттеры - методы в класс Account: get_idAccount(), get_first_name(), get_last_name() и get_birth_day(), в соответствии с рисунком

9. Они нужны для считывания данных из атрибутов.

- Iast_name : string

+ get_first_name{): string + get_last_name{) : string + get_birth_day{) : Date

Рисунок 9 - Добавление операций в класс Account

Добавим в описание класса конструкторы, в соответствии с рисунком

10. Один из них без аргументов и инициализирующей атрибуты значения по умолчанию Account() : Account, другой с аргументами для каждого атрибута Account(in id Account : int, in first_name : string, in last_name : string, in birth_day : Date).

Account

- idAccount : int

- first_name : string

- last_name : string

- birth_day: Date

+ get_idAccount{) : int

+ get_first_name() : string

+ get_last_name{) : string

+ get_birth_day() : Date

+ AccountO : Account

+ Account(in idAccount : int, in first_name : string, in last_name : string, in birth_day : Date)

Рисунок 10 - Добавление конструкторов класса

В данной модели с классом Account не хватает операций по добавлению, изменению, удалению и просмотру данных о больном. Так как в основе информационной системы основу составляет база данных, где хранится вся информация, то добавим в модель еще один класс - Database, в соответствии с рисунком 11.

Database

- conn : Connection

+ Database() : Database

+ openConnection() : bool

+ closeConnectionQ: void

+ newAccount{in firstjiame : string, in last_name : string, in birth_day Date): void

+ updateAccountfin idAccount: int, in first_name : string, in last_naime string, in birth_day : Date) : void

+ deleteAccount(in idAccount : int) : void

+ getAIIAccount{) : List<Account>

Рисунок 11 - Описание класса Database

В классе Database атрибут conn хранит подключение к базе данных, методы openConnection() и closeConnection() соответственно отвечают за открытие и закрытие подключения к базе данных, а методы newAccount(), updateAccount, deleteAccount() и getAllAccount() соответственно отвечают за добавление, изменение, удаление и просмотр данных.

Начнем проектирование вида, для этого добавим еще один класс - View в соответствии с рисунком 12.

tvAccount: TableView<Account> tfidAccount: TextField tfFirstName : TextField tfLastName : TextField tfBirthDay : TextField bNew: Button bEdit: Button bDelete : Button

Рисунок 12 - Описание класса View

В классе View атрибут tvAccount будет отображать данные всех больных в табличном виде, tfidAccount, tfFirstName, tfLastName, tfBirthDay необходимы для редактирования соответствующих атрибутов больного, bNew, bEdit, bDelete - для вызова соответствующих действий по добавлению, редактированию и удалению данных.

Начнем проектирование контроллера, для этого добавим еще один класс - Controller, в соответствии с рисунком 13.

Controller

db : Database v : View

handleNew{): void handleUpdateQ : void handleDelete{) : void initializeQ : void

Рисунок 13 - Описание класса Controller

В классе Controller атрибуты db и v связывают контроллер с моделью и видом, операторы handleNew(), handleUpdate() и handleDelete() являются обработчиками событий нажатия на соответствующие кнопки (New, Update и Delete) в виде, оператор initialize() отвечает за инициализацию контроллера. Расставим отношения между классами, в соответствии с рисунком 14.

Account

- idAccount int

- first_name string

- last name stnng

- birth day Date

+ get _idAccount(): int + get_first_name[) stnng + get_iast_name() sfring + get_birth_day() Date + Account* i: Account + Account(m idAccount: int in first_name string, in last_nam« str ng. in birth_day Date)

_View_

tvAccount TabteV»w«Accounl> tfidAccount TextField

tfFirstNarrw : Те*lField tfLastName TextField tfBirthOay TertField bNew Button bEdit В utton bDelete Button

conn: Connoctioo_

t Database!» Database + openConnection() bool + clowConnecbont) void

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

+ newAccoont(in first_name string, in last_namo : string, in birth_day : Data): void ♦ updateAccount(in idAecount int. in first_name stnng in last_name string, in birth_day Data): void + deleteAccount(m idAccount int): void + gatAKAccountQ List< Ac count»

lb Database View

handleN«w() void handleUpdate)) void handieDeietei): void inibalize() void

Рисунок 14 - Отношения между классами

Между классами Conrtoller и Database, Controller и View отношение направленной ассоциации, поскольку в классе Controller присутствуют два атрибута типа Database и View. Отношение зависимости указана между классами Database и Account, Controller и Account, поскольку в методах этих классов будет использоваться Account.

Расставим стереотипы для классов, в соответствии с рисунком 15.

Рисунок 15 - Стереотипы классов

Аналогичным образом сделаем остальные 5 вариантов использования с классами, в которых создадим атрибуты для хранения данных и операциями для выполнения действий с этими данными. Диаграмма классов для Management a medical card представлена на рисунке 16.

Рисунок 16 - Management a médical card

В классе Card хранится информация о больном (Name - Имя, Surname -Фамилия, MiddleName - Отчество, Gender - Пол, Age - Возраст, Diagnosis -Диагноз, HospitalNumber - Номер больницы, DateArrived - Дата поступления, Hight - Рост, ColorHair - Цвет волос и AddInformation - Дополнительная информация).

В классе Database атрибут conn хранит подключение к базе данных, методы openConnection() и closeConnection() соответственно отвечают за открытие и закрытие подключения к базе данных, а методы newCard(), updateCard, deleteCard() и getAllCard() соответственно отвечают за добавление, изменение, удаление и просмотр данных.

В классе View атрибут tvCard будет отображать данные всех больных в

табличном виде, tfidCard, tfName, tfMiddleName, tfGender, tfAge, tfDiagnosis, tfHospitalNumber, tfDateArrived, tfHight, tfColorHair и tfAddInformation необходимы для редактирования соответствующих атрибутов больного, bNew, bEdit, bDelete - для вызова соответствующих действий по добавлению, редактированию и удалению данных.

В классе Controller атрибуты db и v связывают контроллер с моделью и видом, операторы handleNew(), handleUpdate() и handleDelete() являются обработчиками событий нажатия на соответствующие кнопки (New, Update и Delete) в виде, оператор initialize() отвечает за инициализацию контроллера.

Диаграмма классов для Management statement представлена на рисунке

17.

Рисунок 17 - Management statement

В классе Statement хранится информация о выписке больных (Name -имя, Surname - Фамилия, MiddleName - Отчество, Date_statement - Дата выписки, Reason_statement - Причина выписки, Sanatourium - Санаторий).

В классе Database атрибут conn хранит подключение к базе данных, методы openConnection() и closeConnection() соответственно отвечают за открытие и закрытие подключения к базе данных, а методы newStatement(), updateStatement, deleteStatement и getAllStatement() соответственно отвечают за добавление, изменение, удаление и просмотр данных.

В классе View атрибут tvStatement будет отображать данные всех больных в табличном виде, tfDate_statement, tfReason_statement, tfSanatourium необходимы для редактирования соответствующих атрибутов выписки, bNew, bEdit, bDelete - для вызова соответствующих действий по добавлению, редактированию и удалению данных.

В классе Controller атрибуты db и v связывают контроллер с моделью и видом, операторы handleNew(), handleUpdate() и handleDelete() являются обработчиками событий нажатия на соответствующие кнопки (New, Update и Delete) в виде, оператор initialize() отвечает за инициализацию контроллера.

Диаграмма классов для Management a ward представлена на рисунке 18.

Рисунок 18 - Management a ward

В классе Ward хранится информация о количестве людей в палате (Number - Номер, Number_phone - Номер телефона, Employment - Занятость палаты).

В классе Database атрибут conn хранит подключение к базе данных, методы openConnection() и closeConnection() соответственно отвечают за открытие и закрытие подключения к базе данных, а методы newWard (), updateWard, deleteWard() и getAllWard() соответственно отвечают за добавление, изменение, удаление и просмотр данных.

В классе View атрибут tvWard будет отображать данные о палатах в табличном виде, tfNumber, tfNumber_phone, tfEmployment необходимы для редактирования соответствующих атрибутов палаты, bNew, bEdit, bDelete -для вызова соответствующих действий по добавлению, редактированию и удалению данных.

В классе Controller атрибуты db и v связывают контроллер с моделью и видом, операторы handleNew(), handleUpdate() и handleDelete() являются обработчиками событий нажатия на соответствующие кнопки (New, Update и Delete) в виде, оператор initialize() отвечает за инициализацию контроллера.

Диаграмма классов для Management a transfer представлена на рисунке

19.

Рисунок 19 - Management a transfer

В классе Transfer хранится информация о переводы больных из одной палаты в другую (Name - Имя, Surname - Фамилия, MiddleName - Отчество, Date_transfer - Дата перевода, Number_ward - Номер палаты, Number_phone -Номер телефона).

В классе Database атрибут conn хранит подключение к базе данных, методы openConnection() и closeConnection() соответственно отвечают за открытие и закрытие подключения к базе данных, а методы newTransfer (), updateTransfer, deleteTransfer() и getAllTransfer () соответственно отвечают за добавление, изменение, удаление и просмотр данных.

В классе View атрибут tvTransfer будет отображать данные о палатах в табличном виде, tfDate_transfer, tfNumber_ward, tfNumber_phone необходимы для редактирования соответствующих атрибутов перевода, bNew, bEdit, bDelete - для вызова соответствующих действий по добавлению, редактированию и удалению данных.

В классе Controller атрибуты db и v связывают контроллер с моделью и видом, операторы handleNew(), handleUpdate() и handleDelete() являются обработчиками событий нажатия на соответствующие кнопки (New, Update и Delete) в виде, оператор initialize() отвечает за инициализацию контроллера.

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

Рисунок 20 - Authorization

В классе Authorization авторизация для входа в программу с помощью логина и пароля (Login - Логин, Password - пароль).

В классе Database атрибут conn хранит подключение к базе данных, методы openConnection() и closeConnection() соответственно отвечают за открытие и закрытие подключения к базе данных, а методы newAuthorization(), updateAuthorization, deleteAuthorization() и getAllAuthorization() соответственно отвечают за добавление, изменение, удаление и просмотр данных.

В классе View атрибут tvAuthorization будет отображать данные о палатах в табличном виде, tfLogin, tfPassword необходимы для редактирования соответствующих атрибутов перевода, bNew, bEdit, bDelete -для вызова соответствующих действий по добавлению, редактированию и удалению данных.

В классе Controller атрибуты db и v связывают контроллер с моделью и видом, операторы handleNew(), handleUpdate() и handleDelete() являются обработчиками событий нажатия на соответствующие кнопки (New, Update и Delete) в виде, оператор initialize() отвечает за инициализацию контроллера.

Для модульного представления программной архитектуры используются диаграммы компонентов (component diagrams). Компонент является пакетом или частью системы и содержит реализацию одного или нескольких классов.

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

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

Рисунок 21 - Компоненты информационной системы

Выберем компонент application, во вкладке Required classes и выберем класс Account, в соответствии с рисунком 22.

Рисунок 22 - Выбор требуемого класса

Далее необходимо открыть (Provided classes) этот класс в компоненте database, в соответствии с рисунком 23.

Uml Required classes Provided classes Realizing classes Properties

Stereotype filtering ' 1

Available classes Provided classes

Administrator [AIS] Card [AIS : : Management a medical record] Controller [AIS::Management a medical record] Controller [AIS:;Management a transfer] Controller [AIS: : Management a ward] Controller [AIS: : Management account] Controller [AIS::Management statement] Account [AIS::Managen" ent account]

Database [AIS: : Management a medical record] Database [AIS : ¡Management a transfer] Database [AIS : ¡Management a ward] Database [AIS:Management account] Database [AIS:Management statement] Doctor [AE] Statement [AIS : ¡Management statement] Transfer [AIS: ¡Management a transfer] View [AIS: ¡Management a medical record] View [AIS: Management a transfer] View [AIS: Management a ward] View [AIS: ¡Management account] View [AIS: ¡Management statement] ward [AIS : : Mana gerne nt a ward] * *

I OK ~| Cancel

Рисунок 23 - Выбор предоставляемого класса

Далее отразим отношение требует/предоставляет на диаграмме компонентов, в соответствии с рисунком 24.

«component» «component» ^¡J database

application Account

Рисунок 24 - Отношение между классами

Потом зададим стереотипы для компонентов, в соответствии с рисунком 25.

«process» application «entity» database

Account

Рисунок 25 - Определение стереотипов

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

Authorization

Рисунок 26 - Отношение между классами

Теперь начнем проектировать физическую архитектуру, которая осуществляется с помощью диаграмм развертывания (Deployment diagrams). Диаграммы развертывания помогают отобразить на единой схеме различные компоненты системы и их распределение по комплексу технических средств. Для создания диаграммы развертывания сначала требуется создать соответствующий вид из контекстного меню (New deployment view), а в ней создать диаграмму развертывания (New deployment diagram).

Откроем после и создадим на диаграмме сервер баз данных, на котором будет размещен компонент Database, в соответствии с рисунком 27.

/ /

:nix:DB-Server /

Рисунок 27 - Сервер баз данных

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

Рисунок 28 - Построение корпоративной сети

Разместим в узлах компоненты с помощью Add component, в соответствии с рисунком 29.

Рисунок 29 - Размещение компонентов на узлах Создадим артефакт для генерации кода Java на основе классовой диаграммы, в соответствии с рисунком 30.

Рисунок 30 - Создание артефакта

Далее выберем с какими классами ассоциируется артефакт, в соответствии с рисунком 31.

Рисунок 31 - Определение ассоциированных классов

Во вкладке Java Source при помощи кнопки Default definition получим описание классов, в соответствии с рисунком 32.

Рисунок 32 - Описание классов

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

Рисунок 33 - Месторасположение кода Java

Далее вернемся в артефакт и проверим проект на ошибки, в соответствии с рисунком 34.

Рисунок 34 - Проверка на ошибки

В указанном месте должен появиться файл, в соответствии с рисунком

35.

Рисунок 35 - Сгенерированный код 3 Сгенерированный код

Программный код на языке Java (листинг 1).

Листинг 1 - Код программы

class Account { private int idAccount; private String first_name; private String last_name; private Date birth_day;

public int get_idAccount() { }

public final String getFirst_name() {

return first_name; }

public final String getLast_name() {

return last_name; }

public final Date getBirth_day() {

return birth_day; }

public Account() { }

public Account(int idAccount, String first_name, String last_name, Date birth_day) {

}

class Card { private int idCard; private String Name;

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

private String Surname; private String MiddleName; private String Gender; private int Age; private String Diagnosis; private int HospitalNumber; private Date DateArrived; private int Height; private String ColorHair; private String AddInformation; public final int getIdCard() {

return idCard;

}

public final String getName() {

return Name; }

public final String getSurname() {

return Surname; }

public final String getMiddleName() {

return MiddleName;

}

public final String getGender() { return Gender;

public final int getAge() {

return Age; }

public final String getDiagnosis() {

return Diagnosis; }

public final int getHospitalNumber() {

return HospitalNumber;

}

public final Date getDateArrived() {

return DateArrived; }

public final int getHeight() {

return Height; }

public final String getColorHair() {

return ColorHair; }

public final String getAddInformation() {

return Addlnformation;

}

public Card() { }

public Card(int idCard, String Name, String Surname, String MiddleName,

String Gender, int Age, String Diagnosis, int HospitalNumber, Date

DateArrived, int Height, String ColorHair, String AddInformation) {

}

class Doctor { }

class Statement { private String Name; private String Surname; private String MiddleName; private Date Date_statement; private String Reason_statement; private String Sanatourium; public final String getName() {

return Name; }

public final String getSurname() {

return Surname; }

public final String getMiddleName() {

return MiddleName; }

public get_Date_statement() { }

public final String ${Reason_statement}(){throws} {

return Reason_statement; }

public String get_Sanatourium() { }

public Statement() { }

public Statement(String Name, String Surname, String MiddleName, Date

Date_statement, String Reason_statement, String Sanatourium)

}

} }

class Transfer { private String Name; private String Surname; private String MiddleName; public final String getName() {

return Name; }

public final String getSurname() {

return Surname; }

public final String getMiddleName() {

return MiddleName;

}

public get_Date_transfer() {

public int

${Number_ward}(){throws} {

return Number_ward; }

private Date Date_transfer; private int Number_ward; private int Number_phone;

public int get_Number_phone() { }

public Transfer() { }

public Transfer(String Name, String Surname, String MiddleName, Date

Date_transfer, int Number_ward, int Number_phone) { }

}

class Ward { private int Number; private int Number_phone; private String Employment; public final int getNumber() {

return Number; }

public final int getNumber_phone() { return Number_phone;

public final String getEmployment() {

return Employment; }

public Ward() { }

public Ward(int Number, int Number_phone, String Employment){ }

}

заключение

Я хочу подвести итог о проделанной мною работе, а именно о том, что цель работы достигнута. Я успешно выполнил поставленную задачу, разработав структуру программы, которая будет создавать данные о больном, выписке, палате и перемещениями между палатами. Также разработал диаграмму вариантов использования, а для каждого класса сделал классовую диаграмму. В завершении всего создал диаграммы компонентов и развёртывания. Как итог программа Bouml сгенерировала код на языке программирования Java.

Использованные источники:

1. Model-View-Controller - Википедия [Электронный ресурс].- Режим доступа: https://ru.wikipedia.org/wiki/Model-View-Controller (дата обращения: 25.02.2019)

i Надоели баннеры? Вы всегда можете отключить рекламу.