мі зображено один актор - учасник (вірно і для актора «Адміністратор»), один контролер (Контролер взаємодії з БД User) і дві сутності (База даних User і інтерфейс взаємодії (форма «Авторизація в системі »)).
Перед початком роботи користувач (учасник або адміністратор) робить запит на відкриття форми. Після її відкриття, користувач вводить особистий логін і пароль у відповідні поля форми для введення, після чого дані передаються контролеру, який встановлює з'єднання з базою даних користувачів і висунутих прав доступу. Далі контролер запитує у БД пароль по введеному логіну і після того, як прийде відповідь від БД, контролер здійснює порівняння введених даних з даними з БД. При підтвердженні введених користувачем даних, надається список прав доступу, з наступним інформуванням учасника про підтвердження автентичності логіна і пароля і про успішну авторизації.
. Діаграма послідовності для варіанту використання «Формування звіту» (див. малюнок N3).
. Діаграма послідовності для варіанту використання «Участь у турнірі» (див. малюнок N4).
5.3 Діаграма класів за рівнями
Діаграма класів визначає структуру системи, показуючи її класи, їх атрибути і оператори, а також взаємозв'язку цих класів. [2]
Архітектури клієнт - сервер в системах управління підприємством пов'язана з поділом будь прикладної програми на три основних компоненти або шари:
1. База даних - ER модель.
. Компоненти візуалізації даних - інтерфейси.
3. Компоненти бізнес логіки - контролери.
Як вже говорилося в розділі 4 «Розробка концепції АСОИУ», даний розподіл задовольняє основним принципам проектування архітектури:
1. Принцип «слабкою весняній пов'язаності» - кількість зв'язків між окремими підсистемами має бути мінімальним;
2. Принцип «сильного внутрішнього зчеплення» - зв'язність окремих частин всередині кожної підсистеми повинна бути максимальною.
В результаті розбиття системи на модулі виходять кілька підсистем, кожну з яких можна замінити аналогічною, не зачіпаючи при цьому інші підсистеми. За рахунок цього досягається гнучкість розроблюваної системи і легкість розвитку.
. Шар даних - ER модель. Шар даних описує структуру таблиць зберігаються в БД. Атрибути класів відповідають полях таблиці. [1] Діаграма шару даних представлена ??в прикладенийии P, малюнок P1. ER модель включає 6 сутностей:
1. Таблиця «User» - таблиця користувачів (логін, пароль і т.д.);
2. Таблиця «Message» - таблиця, яка зберігає в собі повідомлень з сайту;
. Таблиця «Role» - таблиця з правами доступу (тобто ролі: «Адміністратор», «Користувач (учасник турніру)»);
. Таблиця «Event» - таблиця (список) турнірів (тобто зберігаються турніри з посиланням на таблицю «Problem»);
. Таблиця «Problem» - таблиця з питаннями (умовами задач) і відповідями для турнірів;
. Таблиця «Player» - таблиця, в якій зберігаються результати турнірів.
. Шар подання - інтерфейси. Шар уявлень визначає форми, існуючі в системі. Кожен клас відповідає своїй формі. Діаграма ...
