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

УДК 004.6

Поварницын Е.Н. студент 2 курса

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

Россия, г. Архангельск РАЗРАБОТКА КЛИЕНТ-СЕРВЕРНОЙ АРХИТЕКТУРЫ ИС ДЛЯ

УЧЁТА СРЕДСТВ ВЫЧИСЛИТЕЛЬНОЙ И ОРГТЕХНИКИ С ИСПОЛЬЗОВАНИЕМ ПАТТЕРНА MVC

Аннотация: Статья посвящается разработке клиент-серверной архитектуры ИС для учёта средств вычислительной и оргтехники с использованием паттерна MVC. В неё рассматривается создание диаграммы вариантов использования, диаграмма классов. А также детально разобрана программа Bouml.

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

Povarnitsyn E.N.

student

2year, faculty "Information Systems and Technologies"

Northern Arctic Federal University Russia, Arkhangelsk

DEVELOPMENT OF CLIENT-SERVER IP ARCHITECTURE FOR ACCOUNTING OF COMPUTING AND OFFICE EQUIPMENT USING

THE MVC PATTERN

Annotation: The article is devoted to the development of the client-server architecture of the IC for training computer and office equipment using the MVC pattern. Use case diagram, class diagram. And also the Bouml program was disassembled in detail.

Keywords: Bouml, architecture, information systems, MVC, artifact

1. Варианты использования ИС

Осуществим анализ архитектуры информационной системы с помощью диаграммы вариантов использования. Для этого используем программу «Bouml». Для этого следует создать в ней новый проект. После чего в данном проекте мы создаем новый вид вариантов использования, а уже в нём саму диаграмму вариантов использования.

В нём я создал двух актёров, ну или двух действующих лиц. Это Administrator(администратор, т.е. тот кто управляет базами данных) внутреннее действующее лицо, и materially_responsible_person (материально ответственное лицо, т.е. тот кто отвечает за оргтехнику и средства ВТ), внешнее действующее лицо, работающие на предприятие, в соответствии с рисунком 1. Относящиеся к предметной области - системы управления организацией.

Рисунок 1 - Актёры Далее создадим вариант использования аи1:оп7а1:юп(т.е. авторизация пользователя). Она соответствует в ИС функции предоставление информационных ресурсов пользователям. Так как авторизация относиться и к администратору и к материально ответственному лицу используем отношение ассоциации и к тому и другому, в соответствии с рисунком 2.

Рисунок 2 - Autorization После чего следует создать вариант использования management account, для администратора, который будет отвечать за обработку данных пользователей и использовать между ними отношение ассоциацию, в соответствии с рисунком 3.

Рисунок 3 - Management account Вариант использования managment account (т.е. управление аккаунтом) включает такие варианты использования как добавление, изменение, удаление и просмотр данных пользователя (аккаунта), т.е например имя, фамилия, дата рождения и т.д (add,change,delete,view). В ИС управление аккаунтом соответствует функции сбора информации о пользователе. Сделаем зависимость включение с вариантом использования management account , в соответствии с рисунком 4.

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

materially_responsible_person(T.e. для материально ответственного лица). Такие как управление историей (management history), управление оргтехникой и компьютерным оборудованием(accounting of CE and office equipment), и управление отделами(department managment), после чего стоит сделать каждому варианту использования зависимость включение с такими вариантами использованиями как добавление, изменение, удаление и просмотр (add room, add department, add CE and of eq, change room, change department, change CE and eq, delete room, delete department, delete CE and of eq, view room, view department, view CE and of eq), в соответствии с рисунком 5.

Рисунок 5 - Варианты использования для materially_responsible_person В итоге мы получаем цельную диаграмму вариантов использования, в соответствии с рисунком 6.

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

2. Проектирования архитектуры ИС

Здесь стоит описать подробно каждую диаграмму классов для каждого варианта использования. Начнём с класса management account.

Следует создать новую классовую диаграмму специально для неё. В ней мы создаём класс Account. В данном классе нужно добавить атрибуты и операции. Здесь мы добавляем такие атрибуты как idaccount ( где будет айди аккаунта) , first_name (имя), last_name (фамилия), bi^May^^ рождение), login (логин пользователя), pass (пароль пользователя). В операции стоит добавить геттеры атрибутов. Геттеры - это методы для считывания данных из атрибутов. Также же стоит к операции отнести конструкторы. Один из них без аргументов и инициализирующий атрибуты значений по умолчанию, а второй с аргументами для каждого атрибута. В итоге у нас должен получиться класс в соответствии с рисунком 7.

Q

Account

- idaccaunt: int

- first_name: string

- Iast_name: string

- birthday: Date

- login : string

- pass: string

+ getjdaccountf): int + get_name(): string + get_iast_nanne(): string + get_birthday[): Date + Account^): Account

+ Account(in idaccount: int, in first_narme : string, in iast_name : string, in birthday : Date): Account + get_iogin(): string + get_pass(): string

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

Поскольку в основе информационной системы основу составляет база данных, где хранится вся информация, то добавим в модель ещё один класс -Database.

Для всех классов он почти аналогичен, так же как и класс View и Controller.

В Database в атрибутах стоит прописать атрибут conn, он позволяет хранить подключение к базе данных. Далее добавляем операции, ну или по-другому методы. openConnection и closeConnection будут отвечать за открытие и закрытие базы данных, newAccount, updateAccount,deleteAccount и getAllAccount будут отвечать соответственно за добавление, обновление, удаление и просмотр данных об аккаунте, так же следует добавить Autorization. Следует это всё оформить, в соответствии с рисунком 8.

Q

idaccaunt: int first_name: string last_name: string birthday: Date login : string pass : string

• get_idaccount(): int

■ get_name(): string

• get_lastjname(): string

• get_birthday(): Date - Accountf): Account

■ Accountfin idaccount: int, in first_name: string, in last_name: string, in birthday : Date): Account

■ getJoginO: string ^

■ get_pass(): string

r Q

- conn : Connection

Ю

View

tvAccount: TabieView<Account>

tfldAccount: TextField

tfFirstName: TextField

tflastName: TextField

tfBirthDay: TextField

bNew: Button

bEdit: Button

bDelete: Button

tfLogin : TextField

tfPass : TextField

+ DatabaseQ: Database + open Con nectionf): bool + colseConnectionQ: void

+ newAccountfin first_name: string, in last_name : string, in bithdate: Date, in login : string, in pass: string): void + updateAccountfin idaccount: int, in f]rst_name: string, in last_name: string, in birthday: Date, in login : string, in pass: string): void + deleteAccountfin idaccount: int): void + getAIIAccount(): List<Account> + Autorization (in login : string, in pass : string)

- db: Database ^ - v: View

- handleNewQ: void

- handlellpdatef): void

- handleDeleteQ: void

- initialize!;}: void

Рисунок 8 - Класс Database Далее создадим и рассмотрим класс View. В нём следует создать такие атрибуты как tvAccount, который будет позволять отображать данные всех

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

tvAccount: TableView<AccDunt> tf Id Account: TextField tfFirstName : TextField tflastName : TextField tfEirthCay: "extField

Рисунок 9 - Класс View После чего переходим к добавлению класса Controller. В нём создаём атрибуты db и v. Они связывают контроллер с классами модели и вида. Операции handleNew, handleUpdate и handleDelete отвечают за обработку нажатия на соответствующие кнопки в виде. И оператор initialize отвечает за инициализацию контроллера. После чего у нас должен получиться класс, в соответствии с рисунком 10.

handleHewQ: void

handleUpdateO :

handleDeleteQ: void

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

После чего расставим стереотипы для классов. Классы относящиеся к модели будут иметь стереотип сущность, это классы Account и Database,

классы относящиеся к вида будут иметь стереотип граничный, это класс View, и классы относящиеся к контроллеру будут иметь стереотип управляющий.

В итоге у нас должна получиться классовая диаграмма, в соответствии с рисунком 11.

Û Account

idaccaunt: int first_name: string last_name: string birthday: Date login : string pass: string

get_idaccount(): int get_name(): string get_last_nameO: string get_birthday(): Date

■ AccountQ: Account

■ Accountfin idaccount: int, in first_name : string, in last_name: string, in birthday: Date): Account getjoginf): string

■ get_pass(): string

Û Database

- conn : Connection

Ю

View

tvAccount : TableView<Accou nt>

tfldAccount : TextFiekJ

tfFirstName : TextFiekJ

tflastName : TextFiekJ

tfBirthDay : TextFiekJ

bNew : Button

bEdit : Button

bDelete : Button

tfLogin : TextFiekJ

tfPass : TextFiekJ

- DatabaseQ: Database

■ openConnectionQ: bool

• colseConnectionf): void

• newAccount(in first_name : string, in last_name : string, in bithdate : Date, in login : string, in pass : string): void

- updateAccount(in idaccount: int, in first_name : string, in last_name: string, in birthday: Date, in login : string, in pass: string): void

■ deleteAccount(in idaccount: int): void

- getAIIAccountQ: List<Account>

- Autorizationfln login : string, in pass: string)

- db : Database 4 - v : View

- handleNewQ : void

- handlellpdateO : void

- handleDeletef) : void

- initialize^) : void

Рисунок 11 - Классовая диаграмма management account Приступим к созданию классовой диаграммы management history. . В Database это одни и те же атрибуты и операции, с одним условиям, что нужно будет заменить параметры в updateHistory, newHistory и deleteHistory, так же стоит добавить атрибут conn. И добавить операции Database, openConnection, closeConnection и getAllHistory. В View следует дописать свои атрибуты, которые будут отображать данные в табличном виде это: tfNumber, tfPersonPost, tfDate, также стоит написать атрибуты для вызова действий bEdit, bDelete, bNew. Controller будет аналогичен с прошлым Controller. После следует создать класс History и в нём прописать атрибуты такие как number, отвечающий техника, который использует связь с facilities, Date, за дату передачи техник, и personal_post, отвечающий за пост ответственного за технику, который использует связь с Division. Далее для них следует создать методы геттеры и конструкторы, которые мы разбирали выше. После чего добавляем недостающие классы, указываем отношения и расставляем стереотипы. В итоге у нас должна получиться классовая диаграмма, в соответствии с рисунком 12.

Рисунок 12 - классовая диаграмма management history Далее создаём классовую диаграмму для accounting of CE and office. В нём создаём класс Facilities и прописываем в нём атрибуты. Number: номер техники, name: название техники, model: модель техники, Date_pok: дата приобретения, price: цена техники. После чего добавляем методы геттеры и конструкторы. Далее добавляем недостающие классы. В Database это одни и те же атрибуты и операции, с одним условиям, что нужно будет заменить параметры в updateFacilities, newFacilities, updateFacilities так же стоит добавить атрибут conn. И добавить операции Database, openConnection, closeConnection и getAllFacilities . В View следует дописать свои атрибуты, которые будут отображать данные в табличном виде это: tfNumber, tfName, tfModel, tfDataPok, tfPrice также стоит написать атрибуты для вызова действий bEdit, bDelete, bNew. Controller будет аналогичен с прошлым Controller. Указываем отношения и расставляем стереотипы. В итоге у нас должна получиться классовая диаграмма, в соответствии с рисунком 13.

Рисунок 13 - классовая диаграмма accounting of CE and office И создаём последнюю классовую диаграмму department management. В нём создаём класс Devision и прописывает такие атрибуты как number_room, который отвечает за номер подразделения, full_name, отвечает за полное название подразделения, short_name, отвечает за короткое название подразделения, main_personal_post, отвечает за пост руководителя, и personal_post, отвечает за материально ответственное лицо. После чего добавляем методы геттеры и конструкторы. Далее добавляем недостающие классы В Database это одни и те же атрибуты и операции, с одним условиям, что нужно будет заменить параметры в updateDivision, newDivision, updateDivison так же стоит добавить атрибут conn. И добавить операции Database, openConnection, closeConnection и getAllDivision . В View следует дописать свои атрибуты, которые будут отображать данные в табличном виде это: tfNumberRoom, tfFullName, tfShortName, tfMainPersonPost, tfPersonPosn также стоит написать атрибуты для вызова действий bEdit, bDelete, bNew. Controller будет аналогичен с прошлым Controller. Указываем отношения и расставляем стереотипы. В итоге у нас должна получиться классовая диаграмма, в соответствии с рисунком 14.

Рисунок 14 - классовая диаграмма department management

Классы отвечающие за авторизацию это класс Account и метод authorization.

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

Сначала следует создать диаграмму компонентов. Создадим для этой архитектурной системы application, которая будет являться клиентом и компонент database, который будет в качестве сервера и предоставляет нужную информацию клиенту. Далее выберем для application требуемые классы. Для меня это Account, Divison, Facilities и History. Это означает, что компоненту, отвечающего за работу приложения, требуется соответствующая таблица в базе данных. Далее необходимо предоставить данные классы в компоненте database. Это означает, что компонент, отвечающий за базу данных, предоставляет таблицу для работы компонента, отвечающего за приложение. Далее отразим отношение на диаграмме компонентов. В нём один требует, а другой предоставляет. После чего зададим стереотипы для компонентов. Поскольку в компоненте database расположен класс сущность, то для данного компонента выберем соответствующий стереотип. Для компонента application выбран стереотип процесс для характеристики работающего приложения. После чего у нас должна получиться диаграмма компонентов, в соответствии с рисунком 15.

History

Рисунок 15 - Диаграмма компонентов Далее перейдём к проектированию физической архитектуры, которая осуществляется с помощью диаграммы развёртывания. Сначала создадим саму диаграмму развёртывания. В ней добавляем сервер баз данных, который будет называться nix:DB-Server, и на котором будет размещён компонент database. После чего добавим узды для рабочих станций, назвав их :Workstation и соединим все узлы по топологии звезда. Далее разместим в узлах компоненты, в соответствии с рисунком 16.

Рисунок 16 - Диаграмма развёртывания После чего создаём артефакт для генерации кода java на основе классовой диаграммы. В нём необходимо выбрать с какими классами ассоциирован артефакт, в соответствии с рисунком 17.

Рисунок 17 - Артефакт Далее генерируем код и получаем его. У меня получился такой код.

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

1. Абрамова О.Ф. Введение в программную инженерную: методические указания к лабораторной работе на тему: «Основные сведения о ЦМЬ и ВОЦМЬ. Диаграмма вариантов использования» [Текст]. - Юрайт,2017 г.

2. Григорьев М.В. Проектирование информационных систем. Учебное пособие для вузов [Текст]. - Юрайт, 2018 г.