2.4. Діаграма кооперацій
Діаграма кооперації призначена для специфікації структурних аспектів взаємодії. Головна особливість діаграми кооперації полягає в можливості графічно представити не тільки послідовність взаємодії, але й всі структурні відносини між об'єктами, що беруть участь у цій взаємодії.
На відміну від діаграми послідовності, на діаграмі кооперації зображуються тільки відносини між об'єктами, що грають певні ролі у взаємодії.
Рис. 4
2.5. Діаграми класів
Діаграма класів складається із множини елементів, які в сукупності відбивають декларативні знання про предметну область. Ці знання інтерпретуються в базових поняттях мови UML, таких як класи, інтерфейси й відносини між ними і їхніми складовими компонентами.
Клас (class) у мові UML служить для позначення множини об'єктів, які мають однакову структуру, поводженням і відносинами з об'єктами з інших класів.
Класи сутностей
Клас сутностей (entity class) моделює структуру даних і поведінка, що відрізняються стабільним характером
Класи границь
Класи границь (boundary classes) обслуговують процеси взаємодії між системою і її оточенням, забезпечуючи інтерфейси для користувачів і сторонніх систем (тобто активних суб'єктів).
Класи керування
Класи керування (control classes) знаходять застосування при реалізації характеристик поведінки системи, властивих одному або декільком варіантам використання, і координують події
Рис. 5
2.6. Діаграми станів
Діаграма станів по суті є графом спеціального виду, що представляє деякий автомат. Поняття автомата в контексті UML має досить специфічну семантику, заснованої на теорії автоматів
Початковий стан являє собою окремий випадок стану, що не містить ніяких внутрішніх дій. У цьому стані перебуває об'єкт за замовчуванням у початковий момент часу. Воно служить для вказівки на діаграмі станів графічної області, від якої починається процес зміни станів. Кінцевий (фінальний) стан являє собою окремий випадок стану, що також не містить ніяких внутрішніх дій.
Рис. 6
3. Опис програмної реалізації
3.1. Опис серверної частини проекту
Структура проекту:
Рис. 7
Обмін даними між клієнтом і сервером відбувається за допомогою технології AJAX.
Для AJAX запитів використовується окремий контролер:
function AjaxController(action, controller, data, successHandler, errorHandler)
action – метод, якому передаються дані
controller – контролер, якому передаються дані
data – об’єкт з даними, які передаються на сервер
successHandler – функція зворотноього виклику, яка буде виконана у разі успішного запиту на сервер
errorHandler - функція зворотноього виклику, яка буде виконана у разі невдалого запиту на сервер. Лістинг: с.23.
$.ajax({
url:'http://Managment/db/main.php',
method:"POST",
contentType: "application/json",
data:JSON.stringify(dataTotal),
success: function(data)
{
var response = jQuery.parseJSON(data);
c(response)
if(response.code == '000')
{
successHandler(response);
}
else
{
errorHandler(response.code);
}
}
Моде́ль–вигляд–контро́лер (або Модель–представлення–контролер, англ. Model-view-controller, MVC) — архітектурний шаблон, який використовується під час проектування та розробки програмного забезпечення.
Цей шаблон передбачає поділ системи на три взаємопов'язані частини: модель даних, вигляд (інтерфейс користувача) та модуль керування. Застосовується для відокремлення даних (моделі) від інтерфейсу користувача (вигляду) так, щоб зміни інтерфейсу користувача мінімально впливали на роботу з даними, а зміни в моделі даних могли здійснюватися без змін інтерфейсу користувача.
Мета шаблону — гнучкий дизайн програмного забезпечення, який повинен полегшувати подальші зміни чи розширення програм, а також надавати можливість повторного використання окремих компонентів програми. Крім того використання цього шаблону у великих системах сприяє впорядкованості їхньої структури і робить їх більш зрозумілими за рахунок зменшення складності.
Рис. 8
У додатку використовується окремий випадок даного шаблону.
В якості контролера виступає main.php - це єдина точка входу у додаток. Існують дві моделі:
groupController – описує функціонал груп студентів
studentController – описує функціонал студентів
Представлення відсутнє, дані з сервера напряму відправляються до клієнта. Це пояснюється тим, що у даному випадку додаток складається всього з однієї сторінки, і вихідні дані простіше опрацювати на клієнті. Використання View виправдане у CMS системах з широким функціоналом і значною кількістю сторінок.
Вхідні дані передаються відповідному контролеру, який опрацьовує їх та повертає результат клієнту - $response->done(). Лістинг: ст.35
if(method_exists($controller,$action))
{
$response->setData(call_user_func(array($controller, $action)));
$response->done();
}
else
{
$response->setError(101);
}
У випадку помилки - $response->setError(101) – робота PHP скрипта завершується, код та опис помилки відправляється клієнту.
Опис класів PHP:
Response – клас, який відповідає за доставку відповіді клієнту та перехоплення помилок.
Рис. 9 Приклад відповіді від сервера
controllersTemplate – абстрактний клас від якого наслідуються інші контролери.
groupController – контролер, описує функціонал груп
studentController – контролер, описує функціонал студентів
Приклад методу із groupController. Лістинг: с.35
public function getAllGroupsStudents()
{
$groups = $this->db->select('*', 'groups', '1');
$specialityKeys = $this->db->select('*', 'specialityKeys', '1');
$students = $this->db->select('s.*, gs.`groupId`', 'students `s` LEFT JOIN groupStudents gs ON s.`id` = gs.`studentId`', '1');
return ['groupsArr' => $groups, 'studentsArr' => $students, 'specialityKeys' => $specialityKeys];
}
Вхідні дані від клієнта проходять необхідну валідацію. За це відповідає клас Validator. У випадку не відповідності шаблону генерується помилка.
Приклад валідації даних при створенні групи:
if(empty($groupName) || !$this->validator->validateGroupName($groupName))
{
$this->response->setError(103);
}
if(empty($groupCurator) || !$this->validator->validateUserFirstLastSurName($groupCurator))
{
$this->response->setError(104);
}
if(!in_array($groupSpeciality, [1,2,3,4,5,6]))
{
$this->response->setError(105);
}