- •Класифікація моделей систем. Роль інструментальної моделі у проектуванні програмного забезпечення.
- •Сучасні підходи до імітаційного моделювання, їх застосування у галузі «Програмна інженерія». Дискретно-подієве та агентне моделювання.
- •Компоненты системы дискретно-событийного моделирования
- •Список событий
- •Мета та задачі програмного проекту, вимоги до пз. Роль вимог у створенні надійного (відмовостійкого) програмного забезпечення.
- •Модель програмного забезпечення, етапи та особливості побудови моделі.
- •Модель зрілості процесів організації, модель cmmі, способи та методи cmmі у вдосконаленні бізнес-процесів розробки пз.
- •Моделі розробки програмного забезпечення. Модель водоспаду та ітеративна модель, застосування елементів даних моделей у сучасних методологіях розробки пз.
- •Моделі розробки програмного забезпечення. Методологія rup – загальна модель. Конус операційних маршрутів програмного проекту.
- •Моделі розробки програмного забезпечення. Методологія OpenUp.
- •Моделі розробки програмного забезпечення. Методології Microsoft Solutions Framework (msf), етапи управління великими програмними проектами.
- •Моделі розробки програмного забезпечення. Методологія fdd, Extreme Programming (xp).
- •Архітектура програмного проекту, керована моделями. Концепція mda.
- •Складові Model Driven Architecture, їх призначення.
- •Моделі розробки програмного забезпечення. Гнучкі методології розробки пз (Agile software development). Методологія Scrum. Ідея ефективного планування робочого навантаження учасників проекту.
- •Роли в скрам-процессе[править | править вики-текст]
- •Основные роли (Core roles) в методологии скрам («Свиньи»)[править | править вики-текст]
- •Дополнительные роли (Ancillary roles) в методологии скрам («Куры»)[править | править вики-текст]
- •Гнучка методологія розробки програмного забезпечення (Agile software development). Основні ідеї Agile.
- •Класифікація програмних проектів за управлінням.
- •Теорія систем. Дослідження рівноважних і нерівноважних систем. Важливість сучасного підходу, що використовується в теорії систем, для програмних проектів.
- •Теорія систем.
- •Теорія процесів. Формальний опис процесів. Специфікація процесу.
- •Теорія процесів. Поняття процесу, основні операції на процесах. Моделювання процесів.
- •Абстрактна та структурна теорії автоматів, їх особливості та приклади застосування.
- •Абстрактний автомат, визначення. Класифікація абстрактних автоматів.
- •Цифровий автомат, загальна структура та способи опису.
- •Динамічне моделювання паралельних програмних систем. Мережа Петрі, загальне визначення.
- •Класифікація мереж Петрі, основні інтерпретації, їх коротка характеристика.
- •Синхронні та асинхронні паралельні процеси, особливості їх моделювання.
- •Паралельний алгоритм, його відмінність від послідовного алгоритму. Моделювання паралельних алгоритмів.
- •Основні елементи мереж Петрі. Способи представлення мереж Петрі.
- •Динамічне та квазідинамічне моделювання програмних систем з паралелізмом. Методологія Business Process Modeling (на основі стандартів idef).
- •Цілі моделювання бізнес-процесів[ред. • ред. Код]
- •Використання[ред. • ред. Код]
- •Історія[ред. • ред. Код]
- •Зовнішнє проектування програмних систем. Принцип концептуальної цілісності.
- •Моделювання програмних систем. Uml-діаграми. Еволюція моделі програмної системи.
- •Нотація[ред. • ред. Код]
- •Діаграми Хареля[ред. • ред. Код]
- •Група uml-діаграм для побудови та уточнення архітектури програмної системи.
- •Докладніше[ред. • ред. Код]
- •Деталізоване проектування пс. Діаграми бізнес-класів та класів.
- •Зв'язки[ред. • ред. Код]
- •Асоціації[ред. • ред. Код]
- •Агрегація[ред. • ред. Код]
- •Композиція[ред. • ред. Код]
- •Відмінності між композицією і агрегацією[ред. • ред. Код]
- •Наслідування
- •Група uml-діаграм для опису поведінки програмної системи.
- •Група uml-діаграм для відображення взаємодії програмних компонентів проектованої системи.
- •Опис[ред. • ред. Код]
- •Метод Model Checking. Загальна характеристика методу.
- •Инструменты[править | править вики-текст]
- •Метод Model Checking. Темпоральні логіки.
- •Приклад[ред. • ред. Код]
- •Темпоральні логіки[ред. • ред. Код]
- •Структури Кріпке. Загальний алгоритм роботи.
- •Формальное определение[править | править вики-текст]
- •Model Checking. Алгоритм методу для ltl та ctl.
- •Середовище Simulink. Формування та імітація функціонування динамічних систем.
Агрегація[ред. • ред. Код]
Агрегація. Проста асоціація між двома класами відображає структурний відношення між рівноправними сутностями, коли обидва класу знаходяться на одному концептуальному рівні і ні один не є більш важливим, ніж інший. Але іноді доводиться моделювати відношення типу «частина/ціле», в якому один з класів має більш високий ранг (ціле) і складається з декількох менших за рангом (частин). Ставлення такого типу називають агрегацією; воно зараховане до відносин типу «має» (з урахуванням того, що об'єкт-ціле має кілька об'єктів-частин). Агрегація є окремим випадком асоціації і зображується у вигляді простої асоціації з незафарбованим ромбом з боку «цілого».
Графічно агрегація представляється порожнім ромбом на блоці класу, і лінією, яка від цього ромба до міститься класу.
Композиція[ред. • ред. Код]
Композиція - більш суворий варіант агрегації. Відома також як агрегація за значенням.
Композиція має жорстку залежність часу існування екземплярів класу контейнера та примірників містяться класів. Якщо контейнер буде знищений, то весь його вміст буде також знищено.
Графічно представляється як і агрегація, але з зафарбовані ромбиком.
Відмінності між композицією і агрегацією[ред. • ред. Код]
Відносини між класом Вуз і класами Студент і Факультет злегка відрізняються один від одного, хоча обидва є відносинами агрегування. В ВУЗі може бути будь-яку кількість студентів (включаючи нуль), і кожен студент може навчатися в одному або декількох вузах; вуз може складатися з одного або декількох факультетів, але кожен факультет належить одному і лише одному ВУЗу. Відношення між класами ВУЗ і Факультет називають композицією, так як при знищенні моделі Вуз моделі факультетів, що належать цьому ВНЗ, також повинні бути знищені. Студент і Вуз відносно агрегації тому, що Студента не можна видалити при знищенні Вузу. [1]
Наслідування
Група uml-діаграм для опису поведінки програмної системи.
Діаграма
розгортання (англ. deployment
diagram) — діаграма в UML,
на якій відображаються обчислювальні
вузли під час роботи програми, компоненти,
та об'єкти,
що виконуються на цих вузлах.[1] Компоненти
відповідають представленню робочих
екземплярів одиниць коду. Компоненти,
що не мають представлення під час роботи
програми на таких діаграмах не
відображаються; натомість, їх можна
відобразити на діаграмах
компонент.
Діаграма розгортання відображає робочі
екземпляри компонент, а діаграма
компонент, натомість, відображає зв'язки
між типами компонент.
Група uml-діаграм для відображення взаємодії програмних компонентів проектованої системи.
Діаграма компонент — в UML, діаграма, на якій відображаються компоненти, залежності та зв'язки між ними.[1]
Діаграма компонент відображає залежності між компонентами програмного забезпечення, включаючи компоненти вихідних кодів, бінарні компоненти, та компоненти, що можуть виконуватись. Модуль програмного забезпечення може бути представлено в якості компоненти. Деякі компоненти існують під час компіляції, деякі — під час компонування, а деякі під час роботи програми.
Діаграма компонент відображає лише структурні характеристики, для відображення окремих екземплярів компонент слід використовувати діаграму розгортування.
слід використовувати діаграму взаємодії, яка може відображати характеристики об'єктів та зв'язків. Екземпляр діаграми взаємодії створює діаграму об'єктів.
Діаграма об'єктів не відображає еволюцію системи під час роботи. Натомість, слід використовувати діаграми взаємодії з повідомленнями, або діаграми послідовності.
