2 Проектування системи
2.1 Побудова er-діаграми
На основі концептуальної моделі отримаємо наступні стержневі сутності – «Користувач» (Users), «Категорія» (BuildCategories), «Будiвля» (Realties). Як додаткові сутності було створено додаткові таблиці – «Пiдписки» (Subscribes), «Ролi користувачiв» (RoleUsers), «Ролi» (Roles) та «Зображення» (ImageAttachments).
Після цього визначені зв’язки між сутностіми. Сутність «Користувач» являє собою більш загальну сутність для усіх користувачів системи. Сутність «Категорія» створена для сбереження у собі інформації щодо конкретної категорії будiвель. Сутність «Будiвля» - це запис з информацiею про будiвлю.Сутність «Ролi користувачiв» грає роль ассоціації користувача та ролі. Вона має тільки ідентифікаційний номер користувача та ролі до якої він відноситься.
На основі вище зазначеного аналізу була побудована ER-діаграма (рис. 2.1)
Рисунок 2.1 – ER-діаграма.
2
Для більш повного уявлення про програму і розширеного розуміння завдання, були побудовані наочні UML діаграми, які дають більш повний опис програмного продукту, який буде створений в графічному вигляді.
UML - мова графічного опису для об'єктного моделювання в області розробки програмного забезпечення. UML є мовою широкого профілю, це відкритий стандарт, який використовує графічні позначення для створення абстрактної моделі системи, званої UML-моделлю [8].
На основі аналізу концептуальної моделі та постановки задачі були спроектовані такі UML-діаграми для полегшення проектування інформаційної системи:
діаграма прецедентів – діаграма, яка описує функціональне призначення системи або, іншими словами, те, що система буде робити в процесі свого функціонування. Діаграма прецедентів є вихідним концептуальним уявленням або концептуальною моделлю системи в процесі її проектування і розробки [8] (рис.2.2);
діаграма класів служить для представлення статичної структури моделі системи в термінології класів об'єктно-орієнтованого програмування. Діаграма класів може відбивати, зокрема, різні взаємозв'язки між окремими сутностями предметної області, такими як об'єкти і підсистеми, а також описує їхню внутрішню структуру і типи відносин. На даній діаграмі не вказується інформація про тимчасові аспектах функціонування системи. З цієї точки зору діаграма класів є подальшим розвитком концептуальної моделі проектованої системи (рис.2.3);
діаграма діяльності – UML-діаграма, на якій показано розкладання діяльності програми на її складові частини. Граф діяльностей є різновидом графу станів скінченного автомату, вершинами якого є певні дії, а переходи відбуваються по завершенню дій;
діаграма станів – діаграма, на якій зображени стани системи, та дії, які призводять до переходів між станами;
діаграма розгортання — діаграма в UML, на якій відображаються обчислювальні вузли під час роботи програми, компоненти, та об'єкти, що виконуються на цих вузлах. Компоненти відповідають представленню робочих екземплярів одиниць коду. Компоненти, що не мають представлення під час роботи програми на таких діаграмах не відображаються; натомість, їх можна відобразити на діаграмах компонент;
діаграма компонент — в UML, діаграма, на якій відображаються компоненти, залежності та зв'язки між ними. Діаграма компонент відображає залежності між компонентами програмного забезпечення, включаючи компоненти вихідних кодів, бінарні компоненти, та компоненти, що можуть виконуватись. Діаграма компонент відображає лише структурні характеристики, для відображення окремих екземплярів компонент слід використовувати діаграму розгортування.
На рисунку 2.2 зображена
User Case діаграма. З неї видно, що в системі
дві ролі – адмiнiстратор та користувач.
Рисунок 2.2 – Діаграма варіантів використання.
На рисунку 2.3 зображена діаграма класів. На нiй зображенi класи, що вiдносяться до обьектноi моделi хмарного застосування з вiдношеннями мiж ними. Нема сенсу приводити інші класи, бо вони є обслуговуючими і стандартними для розробки такого типу хмарних застосуваннь.
Рисунок 2.3 – Діаграма класів.
На рисунку 2.4 зображена діаграма активності. Вона приводить приклад можливого порядку дій при користуванні сайтом. Показано з яких сторінок на які можна перейти, приводяться запити на авторизацію при спробі отримати доступ до можливостей, що є тільки у користувача, згідно з діаграмою варіантів використання (рис. 2.1). Треба зауважити, що на діаграмі діаграмі не береться до уваги можливість користувача в будь який момент повернутись назад або завершити роботу із системою.
Рисунок 2.4 – Діаграма активності.
На рисунку 2.5 зображена діаграма станів. На ній зображені можливі стани роботи з сайтом. Перехід між станами виконується в залежності від дій користувача. Ми бачимо дві основних умови: користувач ще не авторизувався та вже авторизований. Якщо юзер не авторизований, то система знаходиться в стані авторизації. Якщо користувач хоче зареєструватися, система переходить до стану регістрації. Коли користувач авторизувався у системі, система переходить до стану авторизованої і приймає конкретні стани в залежності від дій користувача, такi як:
вiдображення списку нерухомостi;
вiдображення статистики;
редагування власних об’явлень;
створення власного об’явленя;
редагування персональноi iнформацii.
Вихід із загального стану є вихід користувача зі свого облікового запису.
Рисунок 2.5 – Діаграма станів
На рисунку 2.6 зображена діаграма компонентів. Діаграма компонентів описує особливості фізичного представлення системи. Діаграма компонентів дозволяє визначити архітектуру системи, що розробляється, встановивши залежності між програмними компонентами, в ролі яких може виступати вихідний, бінарний і виконуваний код (рис. 2.6);
З неї видно, що в системі є компонент серверу та його база даних, компонент «веб-клієнт», а також інтерфейс «REST API», що дає можливість написання клієнтів для мобільних пристроїв.
Рисунок 2.6 – Діаграма компонентів
Відповідно до діаграми компонентів побудована діаграма розгортання (рис. 2.7), на якій зображено місцезнаходження окремих компонентів системи.
Рисунок 2.7 – Діаграма розгортання
Діаграма розгортання – діаграма в UML, на якій відображаються обчислювальні вузли під час роботи програми, компоненти, та об'єкти, що виконуються на цих вузлах. Компоненти відповідають представленню робочих екземплярів одиниць коду. Компоненти, що не мають представлення під час роботи програми на таких діаграмах не відображаються; натомість, їх можна відобразити на діаграмі компонентів;