Разработка клиент-серверной архитектуры информационной системы для учета пациентов клинической больницы с использованием паттерна MVC
Бесплатный доступ
Статья посвящена разработке клиент-серверной архитектуры информационной системы.
Информационная система, архитектура, классы
Короткий адрес: https://sciup.org/140286076
IDR: 140286076
Текст научной статьи Разработка клиент-серверной архитектуры информационной системы для учета пациентов клинической больницы с использованием паттерна MVC
Клиническая больница. Словесное описание предметной области: на каждого вновь поступившего больного заводится карточка медицинской статистики: ФИО больного, пол, возраст, предварительный диагноз, как поступил больной (направление поликлиники, доставлен скорой помощью и т.п.), дата поступления, прочее описание: примерный рост, цвет волос, особые приметы, примерный возраст, номер палаты, в которую положен больной. Информация о больном может быть неполной, если он не может ответить на вопросы. За время лечения в больнице больной может быть переведён в разные палаты, необходимо знать дату перевода, номер и телефон палаты. После окончания лечения фиксируется дата выписки и причина выписки либо другой исход (полное излечение, направлен в санаторий и т.п.).
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).
Также все будут иметь зависимость <
На рисунке 5 представлена диаграмма вариантов использования, которая отражает будущие функции информационной системы, с использованием отношений ассоциации, зависимости и обобщения.

Рисунок 5 – Диаграмма вариантов использования
2 ПРОЕКТИРОВАНИЕ АРХИТЕКТУРЫ ИС
Для детального описания сущностей предметной области используем диаграммы классов. Диаграммы классов заполняются на основе вариантов использования информационной системы. Они содержат описание в виде классов и описание взаимодействия между ними.
Ранее для варианта использования Управления данными о больных (management account) были поставлены функциональные требования к информационной системе для возможности добавления, изменения, удаления и просмотра данных. Эти функции представлены на рисунке 6.

Рисунок 6 – Класс Управления данными о больных
Для реализации этих требований разработаем классы с атрибутами для хранения данных и операциями для выполнения действий с этими данными.
Будем использовать паттерн Model-View-Controller, который позволяет разделить данные приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента: модель, вид и контроллер.
Начнем проектирование с модели. Добавим класс Account, в соответствии с рисунком 7.

Рисунок 7 – Класс Account
Добавим соответствующие атрибуты в класс Account, которые будут хранить данные о номере аккаунта (idAccount), имени (first_name), фамилии (last_name), дате рождения (birth_day), в соответствии с рисунком 8.

Рисунок 8 – Атрибуты класса Account
Добавим следующие геттеры – методы в класс Account: get_idAccount(), get_first_name(), get_last_name() и get_birth_day(), в соответствии с рисунком 9. Они нужны для считывания данных из атрибутов.

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

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

Рисунок 11 – Описание класса Database
В классе Database атрибут conn хранит подключение к базе данных, методы openConnection() и closeConnection() соответственно отвечают за открытие и закрытие подключения к базе данных, а методы newAccount(), updateAccount, deleteAccount() и getAllAccount() соответственно отвечают за добавление, изменение, удаление и просмотр данных.
Начнем проектирование вида, для этого добавим еще один класс – View в соответствии с рисунком 12.

Рисунок 12 – Описание класса View
В классе View атрибут tvAccount будет отображать данные всех больных в табличном виде, tfidAccount, tfFirstName, tfLastName, tfBirthDay необходимы для редактирования соответствующих атрибутов больного, bNew, bEdit, bDelete – для вызова соответствующих действий по добавлению, редактированию и удалению данных.
Начнем проектирование контроллера, для этого добавим еще один класс – Controller, в соответствии с рисунком 13.
Controller
-
- db : Database
-
- v : View
-
- handleNew(): void
-
- handleUpdate(): void
-
- handleDelete() : void
-
- initialize() : void
Рисунок 13 – Описание класса Controller
В классе Controller атрибуты db и v связывают контроллер с моделью и видом, операторы handleNew(), handleUpdate() и handleDelete() являются обработчиками событий нажатия на соответствующие кнопки (New, Update и Delete) в виде, оператор initialize() отвечает за инициализацию контроллера.
Расставим отношения между классами, в соответствии с рисунком

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

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

Рисунок 16 – Management a medical 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.
u

-
- tvStatement: TableView
-
- tfDate_statatement: TextField
-
- tfReason_statement: TextField
-
- tfSanatorium: TextField
-
■ bNew: Button
-
- bEdit: Button
-
- bDelete: Button

Controller db: Database v: View handleNew(); void handlellpdateQ: void handleDelete(): void initialize(): void
Statement
-
■ Name: string
-
- Surname: string
-
- MiddleName: string
-
- Date_statement: Date
-
- Reason_statement: string
-
- Sanatourium : string
+ get_Name(): string
+ get_Surname(): string
+ get_MiddleName(): string
+ get_Date_statement(): string
+ get_Reason_statement(): string
+ get_Sanatourium(): string
+ Statement): Statement
-
♦ Statement(in Name: string, in Surname : string, in MiddleName: string, in Date_statement: Date, in Reason_statement: string, in Sanatourium : string): Statement
Q '
Database
-
■ conn: Connection
* Database(): Database
* openConnection(): bool
-
♦ closeConnectonQ: void
+ newStatement(in Name : string, in Surname : string, in MiddleName : string, in Date_statement: Date, in Reason_statement: string, in Sanatorium : string): void * updateStatement(in Name: string, in Surname : string, in MiddleName: string, in Date_statement: Date, in Reason_statement: string, in Sanatourium : string): void ♦ deleteStatement(): void
* getAIIStatement(): Li st< Statement*
Рисунок 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.

-
- tvTransfer: TableView
-
- tfD ate transfer: TextFi eld
-
- tfNumber ward: TextField
-
- tfNumber_phone: TextField
-
- bNew: Button
-
- bEdit: Button
-
- bDelete: Button

Controller db: Database v :View___________ handleNewQ: void handleUpdate(): void handleDeleteO: void initializeQ: void
Q
_______________________________________________________________ Transfer _______________________________________________________________
-
- Name: string
-
- Surname:string
-
- MiddleName: string
-
- D atejransfer: D ate
-
- Number_ward: int
-
- Number_phone: int
+ get_Name(): string
-
♦ get_Surname(): string
* get_MiddleName(): string
* get_Date_transfer():Date
+ get_Number_ward():int
+ get_Number_phone(): int
-
♦ Transfer(): Transfer
-
* Transfer(in Name : string, in Surname : string, in MiddleName: string, in Date transfer: Date, in Number ward : int, in Number_phone: int): Transfer
О Database
-
- conn: Connection
+ DatabaseO: Database
+ openConnectionf): bool
+ closeConnection(): void
+ newTransfer(in Name: string, in Surname: string, in MiddleName: string, in Date_transfer: Date, in Number_ward: int, in Number_phone: int): void + updateTransfer(in Name: string, in Surname: string, in MiddleName: string, in D atejransfer: Date, in Number_ward: int, in Number_phone: int): void
+ deleteTransfer():void
+ getAIITransfer(): List
Рисунок 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.

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

Рисунок 24 – Отношение между классами
Потом зададим стереотипы для компонентов, в соответствии с рисунком 25.

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

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

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

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

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

Рисунок 30 – Создание артефакта
Далее выберем с какими классами ассоциируется артефакт, в соответствии с рисунком 31.

Рисунок 31 – Определение ассоциированных классов
Во вкладке Java Sourсe при помощи кнопки 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;
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 AddInformation;
} 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.
Список литературы Разработка клиент-серверной архитектуры информационной системы для учета пациентов клинической больницы с использованием паттерна MVC
- Model-View-Controller - Википедия [Электронный ресурс].- Режим доступа: https://ru.wikipedia.org/wiki/Model-View-Controller (дата обращения: 25.02.2019)