- •Класифікація моделей систем. Роль інструментальної моделі у проектуванні програмного забезпечення.
- •Сучасні підходи до імітаційного моделювання, їх застосування у галузі «Програмна інженерія». Дискретно-подієве та агентне моделювання.
- •Компоненты системы дискретно-событийного моделирования
- •Список событий
- •Мета та задачі програмного проекту, вимоги до пз. Роль вимог у створенні надійного (відмовостійкого) програмного забезпечення.
- •Модель програмного забезпечення, етапи та особливості побудови моделі.
- •Модель зрілості процесів організації, модель 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. Формування та імітація функціонування динамічних систем.
Діаграми Хареля[ред. • ред. Код]
Діаграми станів Хареля (англ. David Harel[1] стають дедалі популярнішими після того, як варіант цих діаграм став частиною Unified Modeling Language. Цей вид діаграм дозволяє моделювання надстанів, ортогональних регіонів, та діяльності як складової стану.
Класичні діаграми станів вимагають створення окремих вершин для кожної допустимої комбінації параметрів, що визначають стан. Це може призводити до необхідності введення великої кількості вершин та переходів між ними для систем складніших за найпростіші. Така складність ускладнює перегляд та розуміння діаграми. Діаграми Хареля дозволяють моделювання багатьох автоматів з перетином функцій на одній діаграмі. Кожен з відокремлених автоматів може виконувати внутрішні переходи не впливаючи на інші автомати на діаграмі. Стан кожного з відокремленого автомата на діаграмі визначає стан системи. Діаграма Хареля еквівалентна діаграмі станів але полегшує перегляд та розуміння отриманих діаграм.
UML-діаграми. Діаграми діяльності.
Діаграма діяльності — в UML, візуальне представлення графу діяльностей. Граф діяльностей є різновидом графу станівскінченного автомату, вершинами якого є певні дії, а переходи відбуваються по завершенню дій.[1]
Дія (англ. action) є фундаментальною одиницею визначення поведінки в специфікації.[2] Дія отримує множину вхідних сигналів, та перетворює їх на множину вихідних сигналів. Одна із цих множин, або обидві водночас, можуть бути порожніми. Виконання дії відповідає виконанню окремої дії. Подібно до цього, виконання діяльності є виконанням окремої діяльності, буквально, включно із виконанням тих дій, що містяться в діяльності. Кожна дія в діяльності може виконуватись один, два, або більше разів під час одного виконання діяльності. Щонайменше, дії мають отримувати дані, перетворювати їх та тестувати, деякі дії можуть вимагати певної послідовності. Специфікація діяльності (на вищих рівнях сумісності) може дозволяти виконання декількох (логічних) потоків, та існування механізмів синхронізації для гарантування виконання дій у правильному порядку.
UML-діаграми. Діаграми послідовності.
Діаграма послідовності — в UML, діаграма послідовності відображає взаємодії об'єктів впорядкованих за часом. Зокрема, такі діаграми відображають задіяні об'єкти та послідовність відправлених повідомлень[1].
На діаграмі послідовностей показано у вигляді вертикальних ліній різні процеси або об'єкти, що існують водночас. Надіслані повідомлення зображуються у вигляді горизонтальних ліній, в порядку відправлення.
Визначені стандартом UML 2.0 діаграми послідовностей мають ті ж можливості що і визначені стандартом UML 1.x, та підтримують додаткові можливості зміни стандартного порядку повідомлень
Група uml-діаграм для побудови та уточнення архітектури програмної системи.
Діаграма об'єктів — в UML, діаграма, що відображає об'єкти та їх зв'язки в певний момент часу.[1] Діаграма об'єктів може розглядатись як окремий випадок діаграми класів, на якій можуть бути представлені як класи, так і екземпляри (об'єкти) класів. Схожою за змістом є діаграма взаємодії (англ. collaboration diagram).
Діаграми об'єктів не мають власної нотації. Оскільки діаграми класів можуть відображати об'єкти, то діаграма класів, на якій відображено лише об'єкти, та не відображено класи, може вважатись діаграмою об'єктів.
