Задача на С++

Використати UML діаграми для опису структури існуючого коду та його рефакторінгу. Виконання цієї частини складається з наступних кроків:

1. Код має бути досить складним – тобто не рівня Hello world чи реалізації одного нескладного алгоритму (хоча це може бути кілька схожих чи якось пов’язаних алгоритмів, і на подальших кроках можна буде створити для них спільний програмний інтерфейс).

2. Реалізувати unit tests, шо описують функціональність обраної програми. (Якщо такі тести вже існують – їх можна доповнити, або залишити як є)

3. Побудувати UML діаграми, що описують обрану програму. Варто описати сценарії використання (UseCase), структуру коду (Class, Component, Object, Composite Structure, Deployment, Package, Profile), логіку та поведінку програми (Sequence, Communication, Timing, Activity, Interaction Overview,State). Для побудови деяких діаграм можна використати автоматичну генерацію діаграм з коду; але при цьому діаграми мають бути зрозумілими. Наприклад, взяти 100 класів і кинути їх усі на одну діаграму класів – мабуть, не найкращий варіант J

4. Запропонувати якісь зміни в структурі/інтерфейсі/реалізації програми. Це може бути кращий object-oriented design, кращий поділ на компоненти чи відокремлення різних аспектів (наприклад, логіки програми від графічного інтерфейсу), використання якихось патернів проектування, можливість вибору різних варіантів реалізації і т.д. Бажано використовувати побудовану модель програми для опису запропонованих змін. Запропоновані зміни треба узгодити з викладачем.

5. Реалізувати запропоновані зміни. 

6. Перевірити, що нова версія програми не вносить зміни в логіку/алгоритми (якщо це не було заплановано). Використати для цього реалізовані раніше unit tests і аналогічні тести, які будуть реалізовані для нової версії.

7. Порівняти попередню та оновлену версії програми за часом виконання окремих алгоритмів/функцій, обсягом коду і т.д.

Мета цієї частини – покращити структуру коду, зробити його більш гнучким та розширюваним. Як частину перетворень, можна реалізувати нову функціональність чи виправити недоліки в попередній – але це має бути додатково до покращень object-oriented design, а не замість нього.