- •Класифікація моделей систем. Роль інструментальної моделі у проектуванні програмного забезпечення.
- •Сучасні підходи до імітаційного моделювання, їх застосування у галузі «Програмна інженерія». Дискретно-подієве та агентне моделювання.
- •Компоненты системы дискретно-событийного моделирования
- •Список событий
- •Мета та задачі програмного проекту, вимоги до пз. Роль вимог у створенні надійного (відмовостійкого) програмного забезпечення.
- •Модель програмного забезпечення, етапи та особливості побудови моделі.
- •Модель зрілості процесів організації, модель 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. Формування та імітація функціонування динамічних систем.
Історія[ред. • ред. Код]
Методи моделювання бізнес-процесів, таких як схема, функціональна блок-схема потоку, схема контролю, Діаграма Ганта, PERT-діаграми, і IDEF з'явилися з початку 20 століття. Діаграми Ганта були одними з перших в 1900 році, схеми в 1920 р. Функціональна блок-схема потоку і PERT в 1950-х, потоку даних і діаграми IDEF в 1970-х. Серед сучасних методів уніфікована мова моделювання.
Термін «моделювання бізнес-процесів» сам по собі був придуманий у 1960-ті роки в галузі інженерних систем. С. Вільямс в 1967 «Моделювання бізнес-процесів покращує адміністративний контроль» («Business Process Modeling Improves Administrative Control»). Його ідея полягала в тому, що методи для отримання більш глибокого розуміння фізичних систем управління можуть бути використані аналогічним чином для бізнес-процесів.
У 1990-х років термін «процес» набув нової парадигми. Нові методики, такі як реорганізація бізнес-процесів, впровадженняінноваційних бізнес-процесів, управління бізнес-процесами, комплексне бізнес-планування спрямовані на вдосконалення процесів у всіх традиційних функціях, які утворюють компанію.
Моделювання бізнес-процесів лягли в основу нових методик, що, наприклад, також підтримує збір даних, аналіз потоку, діаграми процесів та звітності. Близько 1995 були представлені перші програмні візуально-орієнтовані інструменти для моделювання і впровадження бізнес-процесів.
Зовнішнє проектування програмних систем. Принцип концептуальної цілісності.
При проектуванні систем вищого ієрархічного рівня, або уніфікованих систем, розробка ТЗ є самостійним етапом проектування. Таке проектування називається зовнішнім. При зовнішньому проектуванні, разом із технічними факторами, необхідно враховувати економічні показники, прогноз вартості ітерміни періодів проектування і виготовлення. На основі вивчення стану і перспектив науково-технічного прогресу група експертів формулює початковий варіант ТЗ на систему. Оцінку можливості виконання ТЗ і рекомендації по його користуванню одержують з допомогою проектних процедур внутрішнього проектування. Внутрішнім проектуванням називається безпосереднє проектування на любому рівні по ТЗ, розробленому на більш високому рівні.
Ещё один общенаучный принцип – принцип концептуального единства, без которого ни одна серьёзная научная работа не может иметь целостный вид и на выходе представлять аргументированные, не противоречащие друг другу результаты, положения и выводы. Каждый автор обосновывает и выстраивает собственную, либо же присоединяется к уже имеющейся концепции, по необходимости развивая её в соответствии со спецификой и направленностью проводимого исследования. В процессе научного поиска исследователь не должен быть скован заданными рамками, а, напротив, обязан постоянно проявлять творчество, менять и корректировать изначальную вариативную и, даже, базовую концептуальную составляющую, избегая при этом эклектики и предвзятости.
Моделювання програмних систем. Uml-діаграми. Еволюція моделі програмної системи.
Моделювання є найбільш ефективним способом дослідження складних систем різного призначення, – технічних, економічних, екологічних, соціальних, інформаційних – як на етапі їх проектування, так і в процесі експлуатації. Можливості моделювання систем далеко не вичерпані, тому постійно з’являються найновіші методи та технології моделювання.
Створення моделі – клопіткий і творчий процес, що вимагає від дослідника не тільки глибоких теоретичних знань з різних математичних та технічних дисциплін, але й творчого підходу до розв’язання задач, уміння генерувати певні евристики, що відповідають глибинній суті досліджуваного об’єкта.
Моделювання як спосіб пізнання використовувалось людиною з давніх часів. Але з появою комп’ютера моделювання систем збагатилось появою принципово нових методів моделювання таких, як імітаційне моделювання, еволюційне моделювання, методи групового урахування аргументів. Моделі і методи моделювання використовуються при створенні систем автоматизованого проектування, систем прийняття рішень, систем автоматизованого керування, систем штучного інтелекту. Потрібність у розв’язанні задач моделювання систем виникає не тільки у науковця, але й у проектувальника, виробника, ділової людини під час повсякденної праці.
Сучасні технології моделювання не тільки полегшили і прискорили процес побудови та дослідження моделі, але й значно наблизили сприйняття інформації спеціаліста з моделювання систем і спеціаліста, що працює у галузі, яка моделюється. Результати моделювання, які представлені засобами 3D анімації, допомагають знайти спільну мову і розуміння між спеціалістами з моделювання систем та спеціалістами, що працюють у галузі, яка моделюється.
UML (англ. Unified Modeling Language) — уніфікована мова моделювання, використовується у парадигмі об'єктно-орієнтованого програмування. Є невід'ємною частиною уніфікованого процесу розробки програмного забезпечення. UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, яка називаєтьсяUML-моделлю. UML був створений для визначення, візуалізації, проектування й документування в основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретованого коду можлива кодогенерація.
Перша версія (1.0) UML вийшла 13 січня 1997, вона була створена за запитом Object Management Group (OMG) — організації, відповідальної за прийняття стандартів в галузі об'єктних технологій і баз даних. Після обговорення, у вересні 1997 року, версія 1.1 UML була представлена на голосування в OMG. Розробку UML підтримали і вже тоді використовували як стандарт такі гранди ринку інформаційних технологій, як Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Sybase, Logic Works й інші.
Поточна версія — 2.0.
UML-діаграми. Діаграми бізнес-прецедентів та прецедентів.
Діаграма прецедентів — в UML, діаграма, на якій зображено відношення між акторами та прецедентами в системі.[1] Також, перекладається як діаграма варіантів використання.
