
- •Лекція 1. Тема: ядра знань swebok
- •1.1. Аналіз і характеристика областей знань swebok
- •1.1.1 Основи програмних вимог (Software Requirements)
- •1.1.2. Проектування пз (Software design)
- •1.1.3. Конструювання пз (Software Construction)
- •1.1.4 Тестування пз (Software Testing)
- •1.1.5 Супровід пз (Software maintenance)
- •1.1.6. Управління конфігурацією пз (Software Configuration Management– scm)
- •1.1.7. Управління інженерією пз (Software Engineering Management)
- •1.1.8. Процес інженерії пз (Software Engineering Process)
- •1.1.9. Методи і засоби інженерії пз (Software Engineering Tools and Methods)
- •Лекція 2. Тема: життєвий цикл і етапи розробки програмного забезпечення
- •Лекція 3. Тема: еволюція моделей життєвого циклу програмного забезпечення
- •1.6. Прискорення розробки пз.
- •Лекція 4. Тема: оцінка якості процесів створення програмного забезпечення
- •Лекція 5. Тема: визначення вихідних даних для проектування програмного забезпечення
- •5.1 Визначення вимог до пз
- •5.2 Формування і аналіз вимог
- •5.2.1 Опорні точки зору
- •5.2.2 Сценарії
- •5.2.3 Етнографічний метод
- •5.3 Специфікація вимог
- •5.4 Атестація вимог
- •5.5 Класифікація програмних продуктів за функціональною ознакою
- •5.6 Основні експлуатаційні вимоги до програмних продуктів
- •5.7 Передпроектні дослідження предметної області
- •Лекція 6. Тема: розробка технічного завдання
- •2. Підстави для розробки
- •3. Призначення
- •4. Вимоги до програми або програмного виробу
- •5. Вимоги до програмної документації
- •1. Вступ
- •2. Підстава для розробки
- •3. Призначення
- •4. Вимоги до програми або програмного виробу
- •4.1. Вимоги до функціональних характеристик
- •Лекція 7. Тема: принципові рішення початкових етапів проектування
- •Контрольні питання і завдання
- •Аналіз вимог і визначення специфікацій програмного забезпечення при структурному підході
- •Лекція 8. Тема: Специфікації програмного забезпечення при структурному підході
- •Flow-форми
- •Діаграми Насси-Шнейдермана
- •Контрольні питання та завдання:
- •Лекція 9. Тема: діаграми потоків даних
- •Словник даних
- •Вміст словника даних
- •Лекція 10. Тема: діаграми «сутність-зв’язок»
- •Лекція 11. Тема: приклади побудови діаграм та специфікації процесів
- •Лекція 12 Тема: діаграми переходів станів
- •13.1. Структурна схема майбутнього програмного забезпечення
- •13.2 Використання методу покрокової деталізації для проектування структури програмного забезпечення
- •13.3 Структурні карти Константайна
- •13.4.Структурні карти Джексона
- •13.5 Характеристики хорошої моделі реалізації
- •Зчеплення
- •Зв’язаність
- •13.6 Функціональна схема
- •Лекція 14. Тема: методології структурного аналізу і проектування
- •Контрольні питання та завдання
- •Лекція 15. Тема: синтаксис діаграм
- •Контрольні питання та завдання
- •Лекція 16. Тема: Синтаксис діаграм
- •Збір інформації
- •Контрольні питання та завдання:
- •Лекція 17. Тема: побудова sadt-діаграм
- •17.2. Побудова sadt-діаграми для процесу “Побудова таблиць/графіків функцій однієї змінної”
- •Типи зв'язків між функціями
- •Лекція 18. Тема: доповнення до діаграм і моделей
- •Критерії оцінки і вибору
- •Функціональні характеристики
- •3. Загальні функції:
1.1.2. Проектування пз (Software design)
Проектування ПЗ – процес визначення архітектури, компонентів, інтерфейсів та інших характеристик системи і кінцевого результату [5].
Область знань «Проектування ПЗ (Software Design)» складається з наступних розділів:
– базові концепції проектування ПЗ (Software Design Basic Concepts)
– ключові питання проектування ПЗ (Key Issue in Software Design)
– структура і архітектура ПЗ (Software Structure and Architecture)
– аналіз і оцінка якості проектування ПЗ (Software Design Quality Analysis and
Evaluation),
– нотації проектування ПЗ (Software Design Notations)
– стратегія і методи проектування ПЗ (Software Design Strategies and Methods).
До базових концепцій проектування ПО відносяться процеси ЖЦ (стандарт ISO/IEC 12207), процес проектування архітектури з використанням різних принципів (об'єктного, компонентного і ін.) і техніки: абстракції, декомпозиції, інкапсуляції і ін. Автоматизована система піддається декомпозиції на окремі компоненти, вибираються необхідні артефакти (нотації, методи і ін.) програмної інженерії і будується архітектура ПЗ.
До ключових питань проектування ПЗ відносяться: декомпозиція на функціональні компоненти для незалежного і паралельного їх виконання, принципи розподілу компонентів в середовищі виконання і їх взаємодія між собою, механізми забезпечення якості і живучості системи і ін.
При проектуванні структури ПЗ використовується архітектурний стиль
проектування, заснований на визначенні основних елементів структури – підсистем, компонентів і зв'язків між ними.
Архітектура проекту – високорівневе представлення структури, що задається з допомогою патернів, компонентів і їх ідентифікація. Опис архітектури містить опис логіки окремих компонентів системи, достатній для проведення робіт по кодуванню, і зв'язків між ними. Існують і інші види структур, засновані на проектуванні зразків, шаблонів, сімействі програм і їх каркасів.
Патерн – це конструктивний елемент ПЗ, який задає взаємодію об'єктів (компонентів) проектованої системи, визначення ролей і відповідальності виконавців [5].
Патерн може бути: структурним, в якому визначаються типові композиції структур з об'єктів і класів діаграмами класів, об'єктів, зв'язків і інш.; поведінковим, таким, що визначає схеми взаємодії класів об'єктів і їх поведінку діаграмами активностей, взаємодії, потоків управління і інш.; креативним, що відображає типові схеми розподілу ролей екземплярів об'єктів діаграмами взаємодії, кооперації і ін.
Аналіз і оцінка якості проектування ПЗ включає заходи щодо аналізу сформульованих у вимогах атрибутів якості, оцінки різних аспектів ПЗ – розміру і структури ПЗ, функцій і якості проектування з допомогою формальних метрик (функціонально-орієнтованих, структурних і объектно-орієнтованих), а також проведення якісного аналізу результатів проектування шляхом статичного аналізу, моделювання і прототипування.
Нотації проектування дозволяють представити артефакти ПЗ і його структуру, а також поведінку системи. Існує два типи нотацій: структурні, поведінкові і безліч різних їх уявлень.
Структурні нотації є графічними, вони використовуються для уявлення структурних аспектів проектування, компонентів і їх взаємозв'язків, елементів архітектури і їх інтерфейсів. До них відносяться формальні мови специфікацій і проектування: ADL (Architecture Description Language), UML (Unified Modeling Language), ERD (Entity–Relation Diagrams), IDL (Interface Description Language), класи і об'єкти, компоненти і класи (CRC Cards), Use Case Driven і ін. Нотації включають мови опису архітектури і інтерфейсу, діаграми класів і об'єктів, діаграми суть-зв'язок, компонентів, розгортання, а також структурні діаграми і схеми.
Поведінкові нотації відображають динамічний аспект поведінки систем і їх компонентів. Таким нотаціям відповідають діаграми: Data Flow, Decision Tables Activity, Colloboration, Pre-Post Conditions, Sequence, таблиці ухвалення рішень, формальні мови специфікації, мови проектування PDL і ін.
Стратегія і методи проектування ПЗ. Даний розділ знань представляє різні стратегії і методи, які використовуються при проектуванні. До загальних стратегій відносяться: знизу-вгору, сверху–вниз, абстракції, патерни і ін.
Функционально–орієнтіровані (структурні) методи базуються на структурному аналізі, структурних картах, Dataflow-діаграммах і ін. Вони орієнтовані на ідентифікацію функцій і їх уточнення зверху–вниз, після чого проводиться розробка діаграм потоків даних і опис процесів. У об’єктно–орієнтованому проектуванні ключову роль грає спадкоємство, поліморфізм і інкапсуляція, а також абстрактні структури даних і відображення об'єктів [15]. Підходи, орієнтовані на структури даних, базуються на методі Джексона (Jackson) [9] і використовуються для задання вхідних і вихідних даних структурними діаграмами.
Компонентне проектування орієнтоване на використання і інтеграцію компонентів (особливо компонентів повторного використання) і на їх інтерфейс, що забезпечує взаємодію компонентів; є базисом інших видів програмування, зокрема сервісно-орієнтованого, в якому групи компонентів забезпечують функціональний сервіс. До інших методів відносяться: формальні, точні і трансформаційні методи, а також UML для моделювання архітектурних рішень за допомогою діаграм [16].
Таким чином, запропоновані в даній області знань підходи, стратегії і методи проектування ПЗ, засоби розподілу і взаємодії компонентів в різних середовищах є основними при розробці проекту із застосуванням різних елементів (шаблонів, сценаріїв, діаграм і ін.) і стилів проектування структури ПЗ, а також заходів щодо проведення аналізу отриманих на етапі проектування атрибутів якості ПЗ.