Разработка клиент-серверной архитектуры ИС для расчёта заработной платы с использованием паттерна MVC

Осуществим анализ предметной области на основе объектноориентированного подхода с помощью программы Bouml. Для этого в данной программе создаём диаграмму вариантов использования.

В данной диаграмме создаём двух актёров. Administrator(Администратор) и Worker(Сотрудник). Данные действующие лица относятся к предметной области – системы управления организацией. Администратором будет тот, кто может управлять базами данных, редактировать их. Следовательно, Сотрудник тот, над кем будут происходить действия, то есть начисления заработной платы, списание налогов, должность и так далее. Создаём их, в соответствии с рисунком 1.

Рисунок 1 – Актёры Administrator и Worker

После сoздадим первый вариант испoльзования «Authorization» (Автoризация пoльзователья). Она соответствует в ИС функции предоставление информационных ресурсов пользователям. Так как авторизация есть и у администратора и у сотрудника используем отношение ассоциации к обоим, в соответствии с рисунком 2.

Рисунок 2 – Authorization

После чего создаём вариант использования для администратора. Назовём его «Management account» (Управление аккаунтом). Администратор будет отвечать, как уже было сказано выше, за редактирование, удаление и создание новых пользователей. Используем между вариантом использования и администратором отношение ассоциацию, в соответствии с рисунком 3.

Рисунок 3 – Management Account

Вариант использования «Management account» включает в себя такие варианты использования как «Delete account»(Удаление аккаунта), «Change account»(Изменение аккаунта), «View account»(Просмотр аккаунта), «Add account»(Добавление аккаунта). В ИС управление аккаунтом соответствует функции сбора информации о пользователе. Зависимость с ними будет называться включение. Так же администратор будет управлять резервным копированием. Поэтому так же создадим вариант использования «Backup managment» (Управление резервным копированием») Он включает в себя «Delete backup»(Удаление резервного копирования), «Add backup»(Добавление резервного копирования) и «View backup»(Просмотр резервного копирования). Создадим данные варианты использования, в соответствии с рисунком 4.

Рисунок 4 – Зависимость включение

Далее создаём варианты использования для сотрудника. Первый вариант использования будет «Post management»(Управление должностью). Используем между сотрудником и вариантом использования отношение ассоциацию и имеет отношение ассоциация с вариантом использования «Management history», которую мы создадим далее. Так же вариант использования «Post management» включает в себя такие варианты использования как «Change post»(Изменить должность), «Delete post»(Удалить должность), «Add post»(Добавить должность), «View post»(посмотреть должность). Создадим данный вариант использования, в соответствии с рисунком 5.

Рисунок 5 – Post management

Далее создаём вариант использования «Management worker»(Управление сотрудниками). Он будет относится к администратору. Для сотрудников определяется должность. Используем между сотрудником и вариантом использования отношение ассоциацию, и используем ассоциацию данного варианта использования с вариантом использования «Management account». Так же вариант использования «Management user» включает в себя такие варианты использования как «Change user»(Изменить пользователя), «Delete user»(Удалить пользователя), «Add user»(Добавить пользователя), «View user (посмотреть пользователя). Создадим данный вариант использования, в соответствии с рисунком 6.

Рисунок 6 – «Management user»

Далее создаём вариант использования «Management fee and taxes»(Управление доплатной и налогами). Для  сотрудников определяется должность. Используем между  сотрудником и  вариантом использования отношение ассоциацию. Так же вариант использования «Management fee and taxes» включает в себя такие варианты использования как «Change fee and taxes»(Изменить доплату и налог), «Delete fee and taxes»(Удалить доплату и налог), «Add fee and taxes»(Добавить доплату и налог), «View fee and taxes (посмотреть доплату и налог). Создадим данный вариант использования, в соответствии с рисунком 7.

Рисунок 7 – Management fee and taxes

После чего создаём последний вариант использования «Managment history»(Управление доплатной и налогами). Используем между сотрудником и вариантом использования отношение ассоциацию и имеет отношение ассоциация с вариантом использования «Post managment» . Так же вариант использования «Managment history» включает в себя такие варианты использования как «Change history»(Изменить историю), «Delete history»(Удалить историю), «Add history»(Добавить историю), «View history (посмотреть историю). Создадим данный вариант использования, в соответствии с рисунком 8.

Рисунок 8 – Management history

После чего мы получаем полную диаграмму вариантов использования, в соответствии с рисунком 9.

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

2 ПРОЕКТИРОВАНИЕ АРХИТЕКТУРЫ ИС

Создадим диаграмму классов для каждого варианта использования, которые используют отношение ассоциацию. Это такие варианты использования как «Management account», «Post managment», «Management fee and taxes», «Management history», «Management worker», «Backup managment».

Сначала, рассмотрим классовую диаграмму для «Management account». В нём создаём класс «Account». В этом классе добавляем необходимые классы и атрибуты. Добавляем атрибуты такие как id_account (номер аккаунта), login (логин пользователя), password (пароль пользователя). В операции добавляем геттеры атрибутов. Геттеры – это методы для считывания данных из атрибутов. Также же стоит к операциям отнести конструкторы. Один из них без аргументов и инициализирующий атрибуты значений по умолчанию, а второй с аргументами для каждого атрибута. После чего у нас получается класс в соответствии с рисунком 9.

Account

• -    id_account: int

• -    login : string - password: int ♦ get_id_account(): int ♦ get_login(): string * get_password(): int ♦ Account(): Account ♦ Account(in id_account: int, in password : int, in login : string): Account

Рисунок 9 – Account

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

Рисунок 10 – Database

После создаём класс «View». В нём следует создать такие атрибуты как tvAccount, который будет позволять отображать данные всех аккаунтов в табличном виде, tfIdAccount, tfLogin, tfPassword они необходимы для редактирования соответствующих атрибутов клиента. Атрибуты bNew, bEdit, bLogin и bDelete для вызова действий добавлению, редактированию, логина и удаления данных. В итоге у нас должен получиться класс, в соответствии с рисунком 11.

View

• -    tvAccount: TableView

• -    tfkiAccount: TextField

• -    tfLogin : TextField

• -    tfPassword : TextField

• -    bNew : Button

• -    bEdit: Button

• -    bDelete: Button

• -    bLogin : Button

Рисунок 11 – View

И создаём последний класс «Controller». В нём создаём атрибуты db и v. Они связывают контроллер с классами модели и вида. Операции handleNew, handleUpdate и handleDelete, handleAuthorization отвечают за обработку нажатия на соответствующие кнопки в виде. И оператор initialize отвечает за инициализацию контроллера. Получаем класс, в соответствии с рисунком 12.

Controller

• ■    db : Database

• ■    v: View

• ■    handleNew(): void

• ■    handleUpdate(): void

• ■    handleDelete(): void

• ■    initialize(): void

• ■    hand leAuth о rizatio n (): vo id

Рисунок 12 – Controller

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

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

После чего расставим стереотипы для классов. Классы, относящиеся к модели, будут иметь стереотип «entity» (сущность), это классы Account и Database, классы относящиеся к виду будут иметь стереотип «boundary» (граничный), это класс View, и классы относящиеся к контроллеру будут иметь стереотип control (управляющий). Вот мы и получаем готовую диаграмму класса для «Management account», в соответствии с рисунком 14.

Q Account - id_account: int - login : string - password: int * get_id_account(): int                                                    v

tvAccount: TableView tfldAccount: TextField ttLogin : TextField ttPassword: TextField bNew : Button bEdit: Button bDelete: Button bLogin : Button

Controller

• -    db: Database

• -    handleNewO: void

• -    handleUpdate(): void

• -    MandleDeleteO: void

• -    initialize(): void

• -    handleAuthorizationO: void

+ get_login(): string * get_password(): int * Account(): Account

+ Account(in id_account: int, in password : int, in login : string): Account

О Database

• - conn : Connection

• ♦ DatabaseO: Database

• + open Connection (): bool

• ♦    closeConnectlonQ : void                                             ■

* newAccount(in idaccount: int, in login : string, in password : int): void

• ♦    updateAccount(in id_account: int, in login : string, in password : int): void ♦ deleteAccount(in id_account: int): void

• ♦    getAIAccount(): List

• ♦    Authorization(in login : string, in password : int): void

Рисунок 15 – Диаграмма классов для «Management account»

Далее разберём создание классовой диаграммы для «Post management». В Database нужно добавить newPost, updatePost,deletePost и getAllPost будут отвечать соответственно за добавление, обновление, удаление и просмотр данных об должности сотрудника и т.д. , так же стоит добавить атрибут conn. И добавить операции Database, openConnection, closeConnection. В View следует дописать свои атрибуты, которые будут отображать данные в табличном виде это: tfPost, tfDischarge, tfSalary tfUnion они отвечают за редактирование соответствующих атрибутов, post, discharge, salary, Union, которые мы добавим позже, также стоит написать атрибуты для вызова действий bEdit, bDelete, bNew. Controller будет аналогичен с прошлым Controller. После следует создать класс Post и в нём прописать атрибуты такие как post, который отвечает за должность и который использует связь с User, discharge, который отвечает за разряд сотрудника, и salary, который отвечает за заработанную плату сотрудника, Union, который отвечает за то что состоит ли сотрудник в Профсоюзе. Далее для них следует создать методы геттеры и конструкторы, которые мы разбирали выше. После чего добавляем недостающие классы, указываем отношения и расставляем стереотипы. В итоге у нас должна получиться классовая диаграмма, в соответствии с рисунком 16.

Q

tvPost: TableView tfPost: TextField tfDischarge : TextField tfSalary: TextField bNew : Button bEdit: Button bDelete : Button tfUnion: TextField

Post

• -    post: User

• -    discharge: int

• -    salary : int

• -    Union : string

• ♦    get_post(): Account

• ♦    get_discharge(): int

• ♦    get_salary(): int

• ♦    Post() ■ Post

• ♦    Post(in post: Account, in discharge : int, in salary : int, in Union : string): Post

• ♦    get_Union(): string

A         F

Database conn: Connection

.             Controller

• -    db : Database

• -    handleNewQ : void

• -    handleUpdate(): void

• -    handleDeleteO: void

• -    initialize(): void

DatabaseQ: Database openConnectionO: bool cbseConnection(): void newPost(in post: User, in discharge : int, in salary : int, in Union : string): void updatePost(in post: User, in discharge : int, in salary : int, in Union : string): void deletePost(in post: User, in discharge: int, in salary : int, in Union : string): void getAIIPost(): List

Рисунок 16 – Диаграмма классов для «Post management»

Далее разберём создание классовой диаграммы для «Management worker». В Database нужно добавить newUser, updateUser, deleteUser и getAllUser будут отвечать соответственно за добавление, обновление, удаление и просмотр данных о сотруднике, так же стоит добавить атрибут conn. И добавить операции Database, openConnection, closeConnection. В View следует дописать свои атрибуты, которые будут отображать данные в табличном виде это: tfFirstName, tfLastName, tfBirthday, tfPost, tfLogin, tfFullPayment, tfUnion они отвечают за редактирование соответствующих атрибутов first_name, last_name, birthday, post, login, fill_payment, Union которые мы добавил позже, также стоит написать атрибуты для вызова действий bEdit, bDelete, bNew. Controller будет аналогичен с прошлым Controller. После следует создать класс User и в нём прописать атрибуты такие как first_name, который за имя сотрудника, last_name, который отвечает за фамилию сотрудника birthday, который отвечает дату рождения сотрудника и post, который отвечает за должность сотрудника, login, который отвечает за логин сотрудника который связан с классом Account, full_payment, который отвечает за итоговую расчёт с сотрудником, Union, который отвечает за то состоит ли сотрудник в профсоюзе или нет, который связан с Post. Далее для них следует создать методы геттеры и конструкторы, которые мы разбирали выше. После чего добавляем недостающие классы, указываем отношения и расставляем стереотипы. В итоге у нас должна получиться классовая диаграмма, в соответствии с рисунком 17.

о

Ю tvUser: TableView tfFirstName : TextField tfLastName : TextField tfBirthday. TextField bNew : Button bEdt: Button bDelete: Button tfPost: TextField tfLogin: TextField tfFullPayment: TextField tfUnion: TextField

• -    first_name: string

• -    Iast_name: string

• -    birthday: Date

• -    post: string

• -    login : Account

• -    full_payment: int                                                                                                    ^..

• -    Union • Post

• ♦    get_first_name(): string

• ♦    get_last_name(): string

• ♦    get_birthday(). Date

• ♦    User(>: User

• ♦    User(n House : mt. in Name: string, in Street: string, m login : Account, in full_payment: mt, in Union : Post) User

  

  Controller

  
  

  db : Database

  handleNew(): void handleUpdate(): void handleDelete(): void initialize() void

  
  

• ♦    get_post(): string

• ♦    get_login(): Account

• ♦    get_full_payment(): int                                                                                              ^.

• ♦    get_Unk>n(): Post

О

Database

• -    conn • Connection

• ♦    Database(): Database

• ♦    openConnection(): bool

• ♦    closeConnection(): void

• ♦    newUser(in first_name . string, in last_name . string, in birthday . Date, in post. string, in login .Account, in full_payment. int, in Union . Post). void

• ♦    updateUser(ln flrst_name : string, in last_name string, in birthday Date, in post: string, in login : Account, in full_payment: Int, In Union : Post): void ♦ deieteUser(m first_name: string, in last_name : string, in birthday : Date, n post: string, in login : Account, in fuli_payment: int, m Union : Post): void

• ♦    getAIIUser(): List

Рисунок 17 – Диаграмма классов для «Management user»

Далее разберём создание классовой диаграммы для «Management fee and taxes». В Database нужно добавить newFee_Taxes, updateFee_Taxes, deleteFee_Taxes и getAllFee_Taxes будут отвечать соответственно за добавление, обновление, удаление и просмотр данных об зарплате и налогах, так же стоит добавить атрибут conn. И добавить операции Database, openConnection, closeConnection. В View следует дописать свои атрибуты, которые будут отображать данные в табличном виде это: tfUralCoeficient, tfTax, tfPensionFund, tfTradeUnion, tfLastName они отвечают за редактирование соответствующих атрибутов ural_coeficient, tax, pension_fund, trade_Union, last_name которые мы добавил позже, также стоит написать атрибуты для вызова действий bEdit, bDelete, bNew. Controller будет аналогичен с прошлым Controller. После следует создать класс Fee_Taxes и в нём прописать атрибуты такие как ural_coeficient, который отвечает за уральский коэффициент, tax, который отвечает за подоходный налог, pension_fund, который отвечает за пенсионные выплаты, и trade_Union, который отвечает за отчисление профсоюзу, если человек состоит в нём, last_name, который отвечает за фамилию сотрудника, который связан с классом User. Далее для них следует создать методы геттеры и конструкторы, которые мы разбирали выше. После чего добавляем недостающие классы, указываем отношения и расставляем стереотипы. В итоге у нас должна получиться классовая диаграмма, в соответствии с рисунком 18.

+ Database!): Database

♦ openConnectionf): bool

+ doseConnection{): void

♦ newFee_Taxes(in ural_coeffident: int, in tax: int, in pension_fund : int, in trade_Union : int, in Union : string, in last_name : User): void

+ updateFee_Taxes{in ural_coefficient: int, in tax : int, in pension_fund : int, in pension_f u nd : int, in trade_Union : int, in Union : string, in last_name: User): void

+ deleteFee_Taxes(in ural_coeffident: int, in tax: int, in pension_fund : int, in trade_Union : int, in Union : string, in last_name : User): void

+ getAI I Fee_Taxes(): List handleNewj) : void handleUpdateO : void handleDelete{): void initialize!) • void

- ural_coeffident: int

- tax: int

- pension_fund : int

- trade_Union : int

- Iast_name : User

+ get_ural_coeffident(): int

+ get_tax{): int

+ get_pension_fund{): int

+ get_trade_UnionO: int

+ Fee_Taxes() : Fee_Taxes

+ Fee_Taxes(in ural_coeffident: int, in tax : int, in pension_fund : int, in trade_Union : int, in Union : string, in last_name : User): Fee_Taxes

+ get_last_name(): User

Рисунок 18 – Диаграмма классов для «Management fee and taxes»

Далее разберём создание классовой диаграммы для «Management history». В Database нужно добавить newHistory, updateHistory, deleteHistory и getAllHistory будут отвечать соответственно за добавление, обновление, удаление и просмотр данных об должности сотрудника и т.д., так же стоит добавить атрибут conn. И добавить операции Database, openConnection, closeConnection. В View следует дописать свои атрибуты, которые будут отображать данные в табличном виде это: tfTotalAccrued, tfWithheld, tfFullPayment, tfDate они отвечают за редактирование соответствующих атрибутов total_accrued, withheld, full_payment, date, которые мы пропишем позже, также стоит написать атрибуты для вызова действий bEdit, bDelete, bNew. Controller будет аналогичен с прошлым Controller. После следует создать класс History и в нём прописать атрибуты такие как total_accrued, который отвечает сколько всего начислено, withheld, который отвечает сколько удержано, и full_payment, сколько выплачено сотруднику после вычетов всех сервисов, который связан с классом User, date, который отвечает за период отчётности. Далее для них следует создать методы геттеры и конструкторы, которые мы разбирали выше. После чего добавляем недостающие классы, указываем отношения и расставляем стереотипы. В итоге у нас должна получиться классовая диаграмма, в соответствии с рисунком 19.

о

History

- total_accrued int

- withheld: int

- full_payment: User

- date: Date

♦ get_total_accrued(). int

♦ get_withheld(): int

♦ get_full_payment(): User

♦ HistoryO: History

♦ History(in total_accrued : int, in withheld : int, in full_payment: int, in date : Date): History

♦ get_date(): Date

Ю

- tvHistory: TableView - tfTotalAccrued : TextField

- tfWithheld: TextFiled

- tfFullPayment: TextField

- bNew : Button

- bEdit: Button

- bDelete: Button

- tfDate : TextField

- conn : Connection

♦ Database(): Database

♦ openConnecton(): bool

♦ closeConnection(): void

♦ newHistory(in total_accrued : int, in withheld : int, in full_payment: User, in date : Date): void

♦ updateHistory(in total_accrued : int in withheld : int, in full_payment: User, in date : Date): void ♦ deleteHistoryiin total_accrued : Int, In withheld : Int, in fuli_payment User, In date : Date): void

♦ getAIIHistoryO: List

- db: Database

- handleNew(): void

- handleUpdate(): void

- handleDelete(): void

- initialize(): void

й

Database

Рисунок 19 – Диаграмма классов для «Management history»

За авторизацию отвечает класс «Account» и метод «Authorization, который использует bLogin, который находиться в View.

Далее разберём создание классовой диаграммы для «Backup managment». В Database нужно добавить newBackup, deleteBackup и getAllBackup будут отвечать соответственно за добавление, обновление, удаление и просмотр данных об резервном копирование, так же стоит добавить атрибут conn. И добавить операции Database, openConnection, closeConnection. В View следует дописать свои атрибуты, которые будут отображать данные в табличном виде это: tfDataBackup, tfBackupDescription они отвечают за редактирование соответствующих атрибутов data_backup, backup_description, которые мы пропишем позже, также стоит написать атрибуты для вызова действий bEdit, bDelete, bNew. Controller будет аналогичен с прошлым Controller. После следует создать класс Backup и в нём прописать атрибуты такие как dataBackup, который отвечает за дату бэкапа, backup_description, который отвечает за описание бэкапа,. Далее для них следует создать методы геттеры и конструкторы, которые мы разбирали выше. После чего добавляем недостающие классы, указываем отношения и расставляем стереотипы. В итоге у нас должна получиться классовая диаграмма, в соответствии с рисунком 20.

Backup

• -    dataBackup : Date

• -    backup_description: string

• *    get_dataBackup(): Date

• ♦    get_backup_description(): string

• ♦    BackupO: Backup

• ♦    Backup(in dataBackup : Date, in backup_description : string): Backup

Database

• -    conn : Connection

• ♦    Database(): Database

• ♦    openConnection(): bool

• ♦    closeConnection(): void

• ♦    newBackup(in dataBackup : Date, in backup_description : string): void

• ♦    deleteBackup(in dataBackup : Date, in backup_description : string): void

• ♦    getAIIBackupQ: List

  
  
  
  
  

  tvBackup: TableView tfDataBackup: TextFieki tfBackupDescription : TextFieki bNew : Button

  bDelete: Batton

  
  
  
  
  

  Controller

  db : Database

  handleNewQ: void handleDeleteO: void initialize(): void

  
  

Рисунок 20 – Диаграмма классов для «Backup managment»

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

Сначала следует создать «Component diagram» (диаграмму компонентов). Создадим для данной архитектурной системы application, которая будет являться клиентом и компонент database, который будет рассматриваться в качестве сервера и будет предоставлять нужную информацию клиенту. Далее выберем для application требуемые классы. Для меня это «Account», «Post», «Fee_Taxes», «Worker» и «History». Это означает, что компоненту, отвечающего за работу приложения, требуется соответствующая таблица в базе данных. Далее необходимо предоставить данные классы в компоненте database. Это означает, что компонент, отвечающий за базу данных, предоставляет таблицу для работы компонента, отвечающего за приложение. Далее отразим отношение на диаграмме компонентов. В нём один требует, а другой предоставляет. После чего зададим стереотипы для компонентов. Поскольку в компоненте database расположен класс сущность, то для данного компонента выберем соответствующий стереотип. Для компонента application выбран стереотип процесс для характеристики работающего приложения. После чего у нас должна получиться диаграмма компонентов, в соответствии с рисунком 21.

Рисунок 21 – Диаграмма компонентов

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

Рисунок 22 – Диаграмма развёртывания

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

___________________________________________________ Associated classes and extra definitions

Account [Main:: Managment account]

Controller [Main::Management fee and taxes]

Controller [Main::Managment account]

Controller [Main::Managment history]

Controller [Main::Postmanagment]

Database [Main::Management fee and taxes]

Database [Main::Managment account]

Database [Main::Managment history]

Database [Main:: Post managment]

Fee_Taxes [Main::Management fee and taxes]

History [Main::Managmenthistory]

Post [Main::Postmanagment]

View [Main::Management fee and taxes]

View [Main::Managment account]

View [Main::Managment history]

View [Main: :Post managment]

go up                                        go down

Рисунок 23 – Артефакт

После чего код начинает генерироваться.