системный анализ4,5,6

4.Механізм боротьби зі складністю на основі об’єктно-орієнтованої парадигми. (хз что тут надо =\ )

Об’єктно-орієнтована парадигма:

ОО-аналіз – це методологія, за допомогою якої вимоги до системи сприймаються з точки зору класів і об’єктів, виявлених в предметній області

ОО-проектування – це методологія проектування, що поєднує в собі процес об’єктної декомпозиції та прийоми представлення логічної та фізичної, а також статичної та динамічної моделей системи, яка проектується.

Об’єктно-орієнтоване програмування — це метод програмування, оснований на поданні програми у вигляді сукупності взаємодіючих об’єктів, кожен з яких є екземпляром певного класу, а класи є членами певної ієрархії наслідування

Послідовність виконання проекту: ОО-аналіз -> ОО-проектування -> ОО-програмування

Визначення об’єктно-орієнтованого програмування:

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

Об’єкт — Окремий екземпляр класу. Сукупність значень атрибутів окремого об’єкта називається станом.

Метод — Можливості об’єкта.

Обмін повідомленнями — Передача даних від одного процеса іншому, або надсилання викликів методів.

ПРИНЦИПЫ:

Успадкування — Клас може мати «підкласи», спеціалізовані, розширені версії надкласу. Можуть навіть утворюватись цілі дерева успадкування.

Інкапсуляція — приховування деталей про роботу класів від об’єктів, що їх використовують або надсилають їм повідомлення. Інкапсуляція досягається шляхом вказування, які класи можуть звертатися до членів об’єкта.

Абстрагування — спрощення складної дійсності шляхом моделювання класів, що відповідають проблемі, та використання найприйнятнішого рівня деталізації окремих аспектів проблеми.

Поліморфізм — означає залежність поведінки від класу, в якому ця поведінка викликається, тобто, два або більше класів можуть реагувати по різному на однакові повідомлення.

5.Класифікація прецедентів.

Прецеденти високого рівня – загальні визначення без деталізації



Розгорнуті прецеденти – більш детальний опис, ніж прецеденти високого рівня, призначені для поглибленого розуміння вимог і процесів, що відбуваються. Як правило, оформлюються у вигляді діалогу користувача і системи

ТАКЖЕ:

Головні прецеденти (primary use cases) – загальні процеси, наприклад, купівля товару

Другорядні прецеденти (secondary use cases) – менш значні чи більш рідкі процеси, наприклад, запит на асортимент нових товарів

Додаткові прецеденти (optional use cases) – процеси, що можуть бути не реалізовані у системі



И ЕЩЕ

Ідеальні

розгорнуті прецеденти, що відображають загальну сутність процесів без деталізації їх реалізації.

прецеденти високого рівня завжди ідеальні

Реальні

конкретно описують процес в термінах реальних проектних рішень, на основі конкретних технологій введення/виведення інформації та ін.

6.Визначення прецедентів за цілями користувачів.



Для ідентифікації та опису прецедентів важливо не забувати про їх зв’язок із цілями, що ставлять перед собою користувачі системи, у першу чергу основні актори.

Актор має цілі.

Ціль іменує прецедент.

Прецедент має сценарії.

Прецедентами визначається, що саме повинна виконувати система, причому, як правило, нічого не говориться про те, як вона це має робити. (Програмісти мають усвідомлювати необхідність у специфікації поведінки системи у вигляді «чорного ящика».)

Прецедент можна розглядати як колекцію сценаріїв. І не завжди (не у кожному сценарії) відповідна ціль виявляється досяжною.

Отже, опис прецедента доцільно поділяти дві частини: опис послідовності дій, коли “усе йде, як треба” та опис того, як поводиться система, коли відбувається якийсь збій.

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

Практика свідчить, що основний сценарій може займати лише від чверті до однієї десятої всього обсягу опису.