Разработка клиент-серверной архитектуры информационной системы

Для моделирования предметной области используется определение бизнес-процессов которая представлена на рисунке 1.

Рисунок 1 – Модель вариантов использования

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

Первый исполнитель – repairer (ремонтник станков), второй исполнитель – mashineworker (рабочий, который делает детали на станке), третий исполнитель – stockmanager (управляющий складскими помещениями), четвёртый исполнитель – watchman (охраник, который следит за складскими помещениями), пятый исполнитель –mashinemanager (менеджер, который отвечает за починку станков), 2

шестой исполнитель – financial director (финансовый директор), седьмой исполнитель – detailmanager (менеджер, который отвечает за детали).

Бизнес процесс «production for the mashine» (производство за станком) отвечает за производственную деятельность рабочим за станком. Бизнес процесс «writing repair orders» (отправка закакза на ремонт) отвечает за отправку закакза на ремонт станка рабочим. Бизнес процесс «repair mashine» (ремонтирование станка) отвечает за ремонт станков ремонтником станков. Бизнес процесс «manage stock» (управление складом) отвечает за управление складом складским менеджером, который управляет складскими помещениями. Бизнес процесс «guard warehose» (охрана склада) отвечает за охрану склада, охранником. Бизнес процесс «receiving orders for repairs» (получение заказов на ремонт) отвечает за получение заказов на ремонт менеджером, который отвечает за починку станков. Бизнес процесс «issuance of repaired machines» (выдача отремонтированных станков) отвечает за выдачу отремонтированных станков менеджером, который отвечает за починку станков. Бизнес процесс «getting the detail on the invoice» (получение деталей по накладным) отвечает за получение деталей менеджером, который отвечает за детали. Бизнес процесс «financial management» (управление финансами) отвечает управление деньгами предприятия финансовым директором. Бизнес процесс «warehouse service payment» (оплата за обслуживание склада) отвечает за оплата за обслуживание склада финансовым директором. Бизнес процесс «purchase of parts» (закупка деталей) отвечает за закупку деталей финансовым директором.

После этого сделаем диаграмму вариантов использования клиент-серверной архитектуры информационной системы для комплектующих к станкам с использованием паттерна MVT нужно указать всех актёров. В нашем случае будут два актёра – admin (администратор информационной системы) и operator (оператор), которые оба являются staff (персоналом предприятия). А также варианты использования системы и взаимодействие актёров с этими вариантами. На рисунке 2 представлена диаграмма вариантов использования информационной системы.

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

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

Первый исполнитель – admin (администратор информационной системы), второй исполнитель – оператор. Оба эти исполнителя являются персоналом и имеют общий вариант использования –«authorization» (авторизация).

Вариант использования «user management» (управление пользователями информационной системы) отвечает за работу администратора с пользователями системы. В него входят добавление, просмотр, редактирование, удаление пользователей системы. Вариант использования «backup management» (управление резервными копиями) отвечает за работу администратора с резервными копиями. В него входят добавление, просмотр, удаление, и восстановление резервной копии. Вариант использования «detail management» (управление деталями) отвечает за работу оператора с деталями. В него входят добавление, просмотр, редактирование, удаление детали. Вариант использования «mashine management» (управление станками) отвечает за работу оператора со станками. В него входят добавление, просмотр, редактирование, удаление станка. Вариант использования «stock management» (управление складами) отвечает за работу оператора со складами. В него входят добавление, просмотр, редактирование, удаление склада. Вариант использования «worker management» (управление работниками) отвечает за работу оператора с работниками фирмы. В него входят добавление, просмотр, редактирование, удаление работника фирмы.

В нашей модели присутствует web-форма заполнения с кнопками и полями ввода и база данных объектов с сущностями этих объектов. Для рассматриваемого паттерна MVT нам нужно будет сделать средство просмотра, сущности, и шаблоны сущностей.

Управляющим классом в нашей модели будет View (средство просмотра), который включает в себя обработчики кнопок для добавления, изменения и удаления сущностей: ButtonNewWorker, ButtonEditWorker, ButtonDeleteWorker, ButtonNewMashine, ButtonEditMashine, ButtonDeleteMashine, ButtonNewDetail ButtonEditDetail,     ButtonDeleteDetail,     ButtonNewStock,     ButtonEditStock,

ButtonDeleteStock.

Класс View помогает пользователю просматривать и изменять содержания базы данных. Так же View будет управлять классами сущностями и граничными классами при помощи связи dependency.

Классами сущностями будут являться:

• -    класс Invoice содержащий атрибуты представляемого класса (idinvoice (хранит идентификатор накладной), numberstock (хранит номер склада), datedetail (хранит дату получения детали), pricedetail (хранит цену детали), Mashine_Folder (хранит информацию о станке), Worker_Folder (хранит информацию о рабочем), Detail_Folder (хранит информацию о детале), Stock_Folder (хранит информацию о складе));

• -    класс Worker содержащий атрибуты представляемого класса (idworker (хранит идентификатор рабочего), name (хранит имя рабочего), User_Managment_Folder (хранит информацию о пользователе));

• -    класс Mashine содержащий атрибуты представляемого класса (idmashine (хранит идентификатор станка), name (хранит модель станка), type (хранит тип станка), user (хранит информацию о пользователе));

• -    класс Detail содержащий атрибуты представляемого класса (iddetail (хранит идентификатор детали), name (название детали), arrivaldate (хранит дату прибытия детали), number_staff (хранит номер склада));

• -    класс Stock содержащий атрибуты представляемого класса idstock ((хранит идентификатор склада), street (хранит название улицы  склада),

house_number (хранит номер дома склада), square (хранит площадь склада));

• -    класс User_Management содержащий атрибуты представляемого класса (idUser (хранит идентификатор пользователя), login (хранит логин пользователя), password (хранит пароль пользователя));

• -    класс Backup_Management содержащий атрибуты представляемого класса (Date_creation (хранит дату создания), description (описание)).

Граничными классами будут являться:

• -    класс  Template__Invoice  содержащим  атрибуты  разметки  страницы

(tvInvoice, tflidinvoice, tflnumberstock, tfldatedetail, tflpricedetail);

• -    класс  Template__Worker  содержащим  атрибуты  разметки  страницы

(tvWorker, Tfldworker, tflname, dNew, dEdit, dDelete);

• -    класс  Template__Mashine  содержащим  атрибуты разметки  страницы

(tvMashine, tflmashine, tflname, tfltype, tflarrivaldate, tflmodel, dNew, dEdit, dDelete);

• -    класс Template__Detail содержащим атрибуты разметки страницы (tvDetail, tfldetail, tflname, tfltype, tflarrivaldate, tflmodel, tflnumber_staff, dNew, dEdit, dDelete);

• -    класс Template__Stock содержащим атрибуты разметки страницы (tvStock, tfldstock, tflstreet, tflhouse_number, tflsquare, dNew, dEdit, dDelete);

• -    класс  Template__User_Management  содержащим атрибуты разметки

страницы (tvUser_Management, tflLogin, tflPassword, dNew, dEdit, dDelete);

• -    класс Template_Backup_Management содержащим атрибуты разметки страницы (tvBackup_Management, tflDate_creation, tflDescription, dNew, dEdit, dDelete);

• -    класс Template_Autorization содержащим атрибуты разметки страницы (tflLogin, tflPassword, dEnter).

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

Рисунок 3 –Диаграмма классов с отношениями и описанием классов и определением стереотипов

Система состоит из трёх компонентов, согласно паттерну MVT – model, включающего в себя provided classes (предоставляемые классы) Detail, Mashine, Invoice, Stock, Worker, User_Management, Backup_Management, template включающего в себя provided classes (предоставляемые классы) Template_Detail, Template_Mashine, Template_Invoice, Template_Stock, Template_Worker, Template_Backup_Management, Template__User_Management, Template_Autoriztion, view, включающего в себя required classes (требуемые классы): Detail, Mashine, Invoice, Stock, Worker, User_Management, Backup_Management, Template_Detail, Template_Mashine, Template_Invoice, Template_Stock, Template_Worker,

Template_Backup_Management, Template__User_Management, Template_Autoriztion. На рисунке 4 показана component diagram (диаграмма компонентов).

Компонент model физически располагается на database server, компоненты view и template располагаются на web server. Главными элементами диаграммы являются узлы, которые связаны информационными путями по топологии звезда. Диаграмма развёртывания физической архитектуры с размещением компонентов на узлах показана на рисунке 5.

Рисунок 4 – Сomponent diagram

Рисунок 5 – Диаграмма развёртывания физической архитектуры

В базе данных, модель которой изображена на рисунке 6, содержатся таблицы накладная, рабочий, станок, деталь и склады. Классы представляются в базе данных таблицами, а их атрибуты – столбцами этой таблицы. Ассоциации между классами выражаются связями один к многим между таблицами. Связи между таблицами имеют вторичные и первичные ключи таблица invoice имеет первичный ключ idinvoice и 4 вторичных ключа: вторичный ключ Worker_idWorker, связанный с первичным ключом idWorker в таблице Worker, вторичный ключ Mashine_idMasine, связанный с первичным ключом idMashine в таблице Mashine, вторичный ключ Stock_idStock, связанный с первичным ключом idStock в таблице Stock, вторичный ключ Detail_idDetail, связанный с первичным ключом idDetail в таблице Detail. А также таблица Worker имеет вторичный ключ User_Managemant_idworker, связанный с первичным ключом idManager.

Рисунок 6 – Модель базы данных

Таблица рабочий содержит столбцы:    «idworker»,    «name»,

«User_Managemant_idUser». Типы её столбцов отображены в таблице 1.

Таблица 1 – Типы столбцов таблицы Worker

Название столбца	Тип
Idworker	int
Name	varchar
User_Managemant_idUser	int

Таблица станков содержит столбцы: «idmashine», «name», «type» и «Arrivaldate». Типы этих столбцов показаны в таблице 2.

Таблица 2 – Типы столбцов таблицы Mashine

Название столбца	Тип
Idmashine	int
Name	varchar
Type	varchar
Arrivaldate	Date

Таблица деталей содержит столбцы: «iddetail», «name», «arrivaldate» и «number_staff». Типы этих столбцов показаны в таблице 3.

Таблица 3 – Типы столбцов таблицы Detail

Название столбца	Тип
Iddetail	int
Name	varchar
Arrivaldate	Date
number_staff	int

Таблица складов содержит столбцы: «idstock», «street», «house_number», «square». Их типы показаны в таблице 4.

Таблица 4 – Типы столбцов таблицы Stock

Название столбца	Тип
idStock	int
Street	varchar
house_number	int
Square	int

Таблица накладных содержит столбцы:  «idinvoice», «numbersock»,

«datedetail»,     «pricedetail»,     «Mashine_idMashine»     «Worker_idWorker»,

«Detai_idDetail», «Stock_idStock». Их типы показаны в таблице 5.

Таблица 5 – Типы столбцов таблицы Invoice

Название столбца	Тип
Idinvoice	int
Numberstock	int
Datedetail	Date

Pricedetail	int
Mashine_idMashine	int
Stock_idStock	int
Worker_idWorker	int
Detail_idDetail	int

Таблица управления пользователями содержит столбы «idUser», «Login», «Password». Их типы показаны в таблице 6.

Таблица 6 – Типы столбцов таблицы User_Managemant

Название столбца	Тип
idUser	int
Login	varchar
Password	varchar