ittask10i

Загальна постановка задачі та варіанти

лабораторного практикуму

Задача:

"Фрагментарна реалізація систем управління табличними базами даних"

І. Загальні вимоги

Основні вимоги щодо структури бази:

кількість таблиць принципово не обмежена (реляції між таблицями не враховувати);

кількість полів та кількість записів у кожній таблиці також принципово не обмежені.

У кожній роботі треба забезпечити підтримку (для полів у таблицях) наступних (загальних для всіх варіантів!) типів:

integer;
real;
char;
string.

Також у кожній роботі треба реалізувати функціональну підтримку для:

створення бази;
створення (із валідацією даних) та знищення таблиці з бази;
перегляду та редагування рядків таблиці;
збереження табличної бази на диску та, навпаки, зчитування її з диску.

ІІ. Варіанти додаткових типів

Потрібно забезпечити підтримку (для можливого використання у таблицях) двох додаткових типів у відповідності з одним із наступних варіантів:

0) color (RGB код кольору); colorInvl;
1) текстові файли; integerInvl;
2) html-файли; stringInvl;
3) charInvl; string(charInvl);
4) перелiчуваний тип (множину значень складає набiр рядкiв); email;
5) date; dateInvl;
6) time; timeInvl;
7) $ (грошовий форматний тип, max$ =10,000,000,000,000.00); $Invl;
8) complexInteger; complexReal;
9) picture-файли (один з форматів); realInvl;

Примiтка. Типи із суфіксом Invl (наприклад, colorInvl, integerInvl тощо) є "iнтервальними" типами.

ІІІ. Варіанти додаткових операцiй над таблицями

Потрібно реалізувати операцiї над таблицями у відповідності з варіантом:

0) сортування таблиці за одним полем;
1) пошук (за шаблоном) та перегляд знайдених рядкiв таблицi;
2) об'єднання таблиць;
3) рiзниця таблиць;
4) перетин таблиць;
5) вилучення повторюваних рядкiв у таблиці;
6) прямий добуток двох таблиць;
7) проекцiя таблиць;
8) сполучення таблиць (за спiльним полем);
9) перейменування та/або перестановка колонок таблиці (з відповідною зміною схеми таблиці).

IV. Варіанти індивідуальних завдань

Загалом, окремий варіант індивідуального завдання визначається парою:

варіант додаткових типів даних (розділ II);

варіант додаткових операцій над таблицями бази (розділ III).

V. Завдання лабораторного практикуму

Попередній етап
0) Попередній етап (нульовий етап, допуск до виконання). Функціональна специфікація системи управління табличними базами даних (СУТБД) у вигляді однієї або кількох діаграм прецедентів UML.
Без здачі попереднього етапу не приймається жоден з основних етапів лабораторного практикуму.

Основні етапи

Основні етапи можуть виконуватись у будь-якому порядку до того ж вибірково.

Перелік варіантів основних етапів:

1) Використання UML при проектуванні та специфікації програмних систем.

Розробити щонайменше 12 UML-діаграм:

діаграм варіантів використання (діаграм прецедентів) - 1..* (щонайменше до трьох прецедентів потрібно описати потоки подій);

діаграм класів - 2..*. Щонайменше одна з них має містити класи "Таблиця" та "База", подаючи відношення як між цими класами, так і з класами, що використовуються для опису схем, рядків таблиці тощо. Щонайменше одна з діаграм має бути VOPC-діаграмою для “індивідуального” прецедента (відповідно до варіанту додаткової “індивідуальної” операції - див. розділ III ). (VOPC - це абревіатура від View Of Participating Classes);

діаграм діяльності - 0..*;.

діаграм взаємодії - 4..*. Щонайменше одна з діаграм має бути побудованою для “індивідуального” прецедента (у відповідності до варіанта додаткової операції).

діаграм станів - 0..*;

діаграм компонентів - 2..* (щонайменше по одній - для не розподіленої та розподіленої версій системи відповідно);

діаграм розгортання - 1..* (щонайменше - для розподіленої системи).

2-3) Розробка локальної (не розподіленої) версії СУТБД (із власною реалізацією класів "Таблиця" та "База"):

Розробка (власних!) класів для понять "Таблиця", "База" та, можливо, деяких інших класів, спряжених із поняттям "Таблиця" (наприклад, "Схема таблиці", "Атрибут", "Рядок таблиці" тощо).
Створення UML-діаграми класів (з наявними між класами відношеннями).
Проведення unit-тестування. Надати 3..* тести, один з яких має бути призначеним для тестуванням “індивідуальної” (варіантної) операції з розділу III.
Забезпечення інтерфейсу користувача на основі форм.

(Виконання двох пунктів розглядається як виконання одного етапу).

4-5) Один або два варіанти розподілених версій системи (із реалізацією програм-клієнтів та програм-серверів), використовуючи технології віддаленої взаємодії на зразок Java RMI/JRMP, Java RMI/IIOP, Net Remoting, WCF, IIOP Net, EJB тощо.

6) Web-сервіси (або SOAP-, SOAP/WSDL-, SOAP/XML-сервіси). Реалізація СУТБД на основі технології web-сервісів (сервер, клієнт).

7) Web-сервіси. Різні платформи. Для web-сервісу (серверної частини з попереднього етапу) розробити варіант клієнтської програми на "альтернативній платформі". Наприклад, для реалізованого на Java web-сервісу клієнтську частину можна розробити під .NET чи, навпаки, для реалізованого ASMX web-сервісу клієнтську частину можна розробити на Java). Клієнтський проект може бути функціонально обмеженим (*).

8) Варіант розподіленої версії з використанням COM або CORBA (сервер, клієнт).

9) Сумісність технологій. Серед можливих варіантів пропонуються такі: ASMX web-сервіси - WCF, Java RMI/IIOP - CORBA). Треба, наприклад, для ASMX web-сервісу (етап 6) розробити WCF-клієнт або, навпаки, для WCF-сервісу - ASMX-клієнт.

10) REST web-сервіси. Реалізація операцій над даними, орієнтуючись на їх ієрархічну структуру: база -> таблиця -> ... та на використання HTTP-запитів (як мінімум GET, POST та DELETE). Потрібно розробити REST API сервер та продемонструвати його роботу на відповідних тестових HTTP-запитах (Postman, cURL тощо).

11) REST web-сервіси + HATEOAS.

12) REST web-сервіси. Розробка OpenAPI Specification для взаємодії з ієрархічними даними (база, таблиця, ...).

13) REST web-сервіси. Реалізація серверного проєкту, використовуючи кодогенерацію стабу за OpenAPI Specification.

14) REST web-сервіси. Реалізація клієнтського проєкту за OpenAPI Specification.

15) GraphQL API. Потрібно розробити GraphQL API сервер для забезпечення, як мінімум, доступу до вхідних та результуючих даних варіантної операції, надаючи можливість обирати той чи інший рівень деталізації цих даних. Для демонстрації роботи сервера на тестових клієнтських HTTP-запитах окрім традиційних засобів (Postman, cURL тощо) можна скористатись Graphiql.

16) gRPC. Розподілена версія із використанням технології gRPC. Реалізація серверної і клієнтської програм здійснюється із використанням однієї мови. Проект може бути функціонально обмеженим (*)

17) gRPC. Розподілена версія із використанням технології gRPC. Реалізація серверної і клієнтської програм здійснюється із використанням різних мов. Проект може бути функціонально обмеженим (*)

18-19) Один або два варіанти Web-проектів. (AspNetWebApi, ASP .NET, ASP .NET MVC, WPF, JSP, JavaServlet, Spring, Struts, Struts 2, JSF, Tapestry, Wicket, GWT тощо). Кожен проект може бути функціонально обмеженим (*).

20) Web-проект із використанням AJAX. Щонайменше повинно забезпечуватись часткове перезавантаження web-сторінки. Проект може бути функціонально обмеженим (*).

21) Мобільний проект (Android, iOS, Windows Phone тощо). Проект може бути функціонально обмеженим (*).

22) Варіант проекту із використанням хмарних технологій (від Microsoft, Google, Amazon, Hiroku тощо). Проект може бути функціонально обмеженим (*).

23) Застосування мікросервісної архітектури при реалізації бізнес-логіки проекту.

24) Варіант проєкту із використанням реляційної СУБД (замість використання серіалізації об'єктів для збереження даних).

25) Варіант проєкту із використанням СУБД Mongo або її аналогів (замість використання серіалізації об'єктів для збереження даних).

26) (2-7 балів) Інтегроване (Mock-) тестування для однієї із розподілених версій.

27) (2-7 балів) Інтегроване (Mock-) тестування у проєктах, що використовують реальні СУБД (реляційні чи ні) для збереження даних (етапи 24, 25).

28) (2-7 балів) Ще одна версія мобільного проекту.

29) (2 бали) Рефлексія (reflection). Реалізація "динамічних викликів" на прикладі одного з об'єктів клієнтської частини розподіленої версії.

30) (4 бали) Рефлексія (reflection). Інтроспекція одного з основних бізнес-об'єктів, розробка GUI для надання значень параметрам та забезпечення викликів методів такого об'єкта.

(*) ЯК МІНІМУМ має забезпечуватись демонстрація виконання варіантної операції (див. розділ III ) над таблицями даних, що також відповідають варіанту (див. розділ II).

VI. Терміни виконання та форма звітування

Основні етапи можуть виконуватись у ДОВІЛЬНОМУ ПОРЯДКУ. Тому нижче вказані терміни звітування по КІЛЬКОСТІ ЕТАПІВ:
28.09 -- попередній етап;
05.10 -- 1 основний етап;
12.10 -- 2 основні етапи;
19.10 -- 3 основні етапи;
26.10 -- 4 основні етапи;
02.11 -- 5 основних етапів;
09.11 -- 6 основних етапів;
16.11 -- 7 основних етапів;
23.11 -- 8 основних етапів;
30.11 -- загальний ~~друкований~~ звіт.

За кожний повний чи неповний тиждень запізнення з виконанням етапу знімається 1 бал.

В останні два тижні теоретичного навчання дозволяється здавати не більше, ніж по два етапи.

З лабораторного практикуму готується загальний ~~друкований~~ звіт, який має складатись із звітів до окремих етапів (як складових частин загального звіту).

VII. Оцінювання

Кожен з основних етапів з 1 по 25 оцінюється в межах 7,5 балів.

За цікаві вирішення, прийоми, додаткові можливості можуть додаватись заохочувальні бали.

~~Тестові контрольні роботи сумарно оцінюються в межах 10 балів,~~ відповідь на іспиті - в межах 40 балів.