2. Використання діаграм послідовностей та діаграм класів при проектуванні програмних систем.
Діаграма послідовності — в UML, діаграма послідовності відображає взаємодії об'єктів впорядкованих за часом. Зокрема, такі діаграми відображають задіяні об'єкти та послідовність відправлених повідомлень[1].
На діаграмі послідовностей показано у вигляді вертикальних ліній різні процеси або об'єкти, що існують водночас. Надіслані повідомлення зображуються у вигляді горизонтальних ліній, в порядку відправлення.
Діагра́ма кла́сів — статичне представлення структури моделі. Відображає статичні (декларативні) елементи, такі як: класи, типи даних, їх зміст та відношення. Діаграма класів, також, може містити позначення для пакетів та може містити позначення для вкладених пакетів. На цій діаграмі показують класи, інтерфейси, об'єкти й кооперації, а також їхні відносини.
В розробці ПС на першому кроці потрібно побудувати діаграм прецедентів. Наступний крок - це побудова одночасно двох інших діаграм, послідовностей та класів. Діаграма послідовності надає можливість представляти сценарій прецедента графічно, шляхом відображення послідовності повідомлень, якими обмінюються об’єкти.
Виявлення об’єктів при розробленні діаграми слід розглядати як важливий крок на шляху до розроблення діаграм класів. Один з варіантів визначення класів під час побудови діаграм послідовностей – іменники у сценаріях(прецедентах).
3. Патерни проектування
За Кристофером Олександером, будь-який патерн описує задачу, що постійно постає та розв'язується, застосовуючи один і той же прийом так, що він стає у нагоді тисячі, мільйони разів і не потребує нічого нового.
Хоча Олександер мав на увазі патерни, що виникають при проектуванні архітектурних споруд, його підхід залишається справедливим й для патернів ОО проектування.
Патерн – це типове вирішення типової проблеми у даному контексті.
Об'єктно-орієнтований шаблон(патерн) найчастіше є зразком вирішення проблеми і відображає відношення між класами та об'єктами, без вказівки на те, як буде зрештою реалізоване це відношення.
GRASP(загальні шаблони розподілу обов`язків) – патерни, що використовуються в об`єктно-орієнтованому програмуванні для вирішення задач призначення обов`язків класам і об`єктам.
У загальному випадку опис патерну складається з чотирьох основних розділів:
Ім'я. Пославшись на нього, можна одразу описати як проблему проектування, так і її вирішення (словник патернів)
Задача. Опис того, коли варто застосовувати патерн.
Розв'язок . Абстрактний опис задачі проектування і того, як вона може бути розв'язана за допомогою деякого узагальненого сполучення класів чи об'єктів.
Результати. Описуються наслідки застосування патерну, різного роду компроміси, аналізується вибір мови реалізації.
Класифікації патернів:
Породжуючі патерни – пов'язані з процесом створення об'єктів:
Абстрактна фабрика (Abstract Factory)
Будівник (Builder)
Одинак (Singleton)
Прототип (Prototype)
Фабричний метод (Factory Method)
Структурні патерни – ґрунтуються на композиціях (структурних об'єднаннях) об'єктів чи класів. (Теза: замість успадкування – композиції).
Адаптер (Adapter)
Декоратор (Decorator)
Замісник (Proxy)
Компонувальник (Composite)
Міст (Bridge)
Легковаговик (Flyweight)
Фасад (Facade)
Патерни поведінки – характеризуються взаємодією об'єктів між собою (такі патерни можна розглядати як кооперації UML).
Відвідувач (Visitor)
Інтерпретатор (Interpreter)
Ітератор (Iterator)
Команда (Command)
Посередник (Mediator)
Спостерігач (Observer)
Стратегія (Strategy)
Шаблонний метод (Template Method)
Існують також і анти-патерни, їх можуть ще називати пастками. Це класи найчастіше впроваджуваних помилкових вирішень проблем. Їх вивчають як категорію, для запобігання застосування їх у майбутньому.
Термін походить з книги «Банди чотирьох» “Шаблони проектування”, де анти-патерни ставляться у протилежність до гарних патернів проектування.