Рис. 5.3. Діаграми станів процесора (а) і верстата (б)
Причини зміни стану можуть задаватись аналітично як функції часу. Так, час напрацювання верстата на відмову можна задати у вигляді функції розподілу ймовірностей.
Для задания концептуальної структури можуть використовуватись формальні математичні моделі, такі як мережі Петрі, стохастичні мережі СМО, потокові діаграми та ін. Слід зазначити, що вже на цьому етапі на вибір структури може суттєво впливати вибір програмних засобів реалізації імітаційної моделі. Сучасні програмні засоби імітаційного моделювання мають різні візуальні компоненти, за допомогою яких можна побудувати концептуальну модель.
Побудова концептуальної моделі — найвідповідальніший етап моделювання. Неправильна концепція, покладена в основу моделі, неправильні припущення про взаємозв'язки змінних і параметрів призводять до того, що виконання подальших етапів побудови імітаційної моделі виявляється безглуздим і часто спричиняє невиправдані затрати.
Після побудови концептуальної моделі перевіряють її відповідність об'єкту моделювання, використовуючи метод оберненого перетворення. Розглядається побудована модель, здійснюється перехід до прийнятих припущень, апроксимацій та спрощень і повернення до реальних процесів і явищ системи, що моделюється.
Побудована концептуальна модель подається на обговорення експертам, які повинні визначити її відповідність цілям моделювання з погляду вирішення поставленої проблеми. У деяких випадках після створення концептуальної моделі і аналізу її функціонування фахівці можуть отримати достатню інформацію для суттєвого поліпшення роботи системи, яка моделюється, без побудови імітаційної моделі.
5.5. Вибір засобів реалізації імітаційної моделі
На цьому етапі виконуються роботи, пов'язані з підготовкою та реалізацією імітаційної моделі на комп'ютері. Розробляється логічна схема моделі, яка перетворюється потім у програму. Подальша формалізація концептуальної моделі відбувається на етапі розроблення структури імітаційної моделі, але слід мати на увазі, що відображення структури моделі залежить від обраних засобів програмування.
Програмна реалізація імітаційної моделі може бути створена за допомогою:
алгоритмічних мов загального призначення;
спеціалізованих мов моделювання;
пакетів прикладних програм для моделювання;
засобів автоматизації програмування імітаційних моделей;
діалогових і візуальних систем моделювання;
інтелектуальних систем моделювання.
Структуру моделі можна зобразити з використанням елементів програмних засобів створення імітаційної моделі. Тому, перш ніж розпочати розроблення структурної схеми імітаційної моделі, необхідно вибрати мову програмування, якою буде реалізовано модель.
Мову, якою буде здійснено програмну реалізацію імітаційної моделі, слід вибирати залежно від складності імітаційної моделі та типу наявного комп'ютера. Нині існує багато мов моделювання, орієнтованих як на суперкомп'ютери, так і на персональні комп'ютери. Спочатку потрібно визначити, як буде реалізовано імітаційну модель алгоритмічною мовою програмування загального призначення, об'єктно-орієнтованою мовою з візуальним середовищем або з використанням спеціалізованих засобів моделювання.
Щоб надати перевагу одному з вищевказаних засобів, необхідно спочатку визначити затрати на реалізацію моделі, враховуючи такі рекомендації.
Для реалізації простої імітаційної моделі можна використати алгоритмічну мову загального призначення, що дасть змогу отримати більш швидкодіючу модель.
У разі реалізації складної імітаційної моделі, що має велику кількість різних компонентів, перевагу належить віддавати спеціалізованим засобам моделювання. У випадку використання алгоритмічних мов з метою уніфікації програмних модулів і принципів структурного та модульного програмування, необхідно розробити засоби:
керування процесом моделювання в модельному часі;
збирання статистичних даних про роботу моделі;
генерування випадкових величин з різними законами розподілів імовірностей для моделювання стохастичних впливів;
діагностики помилок під час виконання програми моделювання.
Ці засоби існують у будь-якій мові моделювання або пакеті прикладних програм, орієнтованому на моделювання.
Перш за все на початковий вибір засобу моделювання впливає наявність його в даному комп'ютері. Під час попереднього вибору засобу необхідно визначити, чи досконало написано настанову та інструкції для користувача, чи забезпечує транслятор достовірну діагностику помилок, чи можливе швидке засвоєння цього засобу.
На наступному етапі потрібно оцінити можливості побудови програмної реалізації імітаційної моделі з допомогою цього засобу та проведення експериментів з моделлю. Для цього необхідно відповісти на такі запитання:
Які існують засоби генерування випадкових чисел і змінних?
Як здійснюється збирання статистичних даних моделювання?
Які можливості засобу щодо налагодження моделі?
Наскільки засіб відповідає можливості відображення структури модельованої системи, яка моделюється?
Які можливості засобу щодо зміни структури моделі?
Наскільки просто вносити зміни в програмну реалізацію моделі?
Чи легко обробляти отриманий статистичний матеріал за результатами прогонів моделі?
Чи існує інтерфейс з іншими програмними засобами (графічними, анімаційними, статистичними, оптимізаційними пакетами)?
Наскільки зручний інтерфейс між користувачем і програмою?
Чи дає засіб можливість формувати звіт про роботу моделі в зручному для користувача вигляді?
Чи можна використовувати засоби планування проведення експериментів та оптимізації для прийняття рішень?
Із безлічі можливих засобів моделювання перевагу належить віддавати тим засобам, що добре зарекомендували себе як перевірені та використання яких потребує мінімальних витрат на створення моделі та експериментування з нею.
5.6. Розроблення структурної схеми імітаційної моделі та опису її функціонування
На цьому етапі об'єкт моделювання остаточно формалізується у вигляді абстрактної системи. Для цього необхідно описати структуру системи та сукупність математичних описів усіх її елементів, зовнішніх впливів і взаємодій між усіма елементами в процесі функціонування системи.
Структура системи визначається з огляду на побудовану концептуальну модель і вибрані засоби моделювання. У разі реалізації імітаційної моделі алгоритмічною мовою загального призначення на структуру імітаційної моделі істотно впливає вибраний підхід до реалізації імітаційного алгоритму. У разі вибору об'єктно-орієнтованої мови описують класи та підкласи для статичних і динамічних об'єктів, задають інтерфейси, методи класів та властивості об'єктів.
Якщо модель буде реалізовано мовою моделювання GPSS [68], то структура моделі подається у вигляді блок-схеми, що складається з блоків різних типів. Набір блоків у блок-схемі визначає набір операторів мови, які описують структуру системи, що моделюється та логіку її функціонування. У такій схемі блоки відображають виконувані над транзактами операції, а стрілки між блоками — маршрути руху транзактів.Якщо імітаційною моделлю системи є СМО, то її структуру можна зобразити у вигляді схеми, на якій є генератори вимог, що надходять до системи, буферів або черг, пристроїв для обслуговування, які реалізують затримку вимог у системі. Черги до якого-небудь ресурсу утворюються через його зайнятість. На цій схемі може бути зображено програмні блоки, які реалізують необхідні функції в реальній системі. Якщо імітаційна модель будується як мережа Петрі, то структура мережі зображується у вигляді орієнтованого графу.
Якщо програмна реалізація імітаційної моделі здійснюється мовою, орієнтованою на процеси, то структуру моделі можна зобразити у вигляді ресурсів і шляхів проходження потоків повідомлень через ці ресурси. Структурну схему можна побудувати детальніше, якщо виділити всі типи подій для потоків повідомлень та дії, які належать до ресурсів. Фрагмент такої схеми зображено на рис. 5.4.
Рис. 5.4. Фрагмент структури імітаційної моделі технологічного обладнання
Стрілками позначено дії, пов'язані з потоком заготовок (повідомлень). Основними подіями в такій схемі є запит, призначення та звільнення ресурсів, таких як верстат і транспортний візок. Якщо ресурс уже зайнятий, до нього утворюється черга заготовок. На цій самій схемі може бути позначено умови зміни потоків повідомлень. Таку структурну схему імітаційної моделі називають діаграмою або картою подій. Для спрощення діаграми подій за значної кількості ресурсів однотипні ресурси доцільно групувати та визначати як узагальнений ресурс або клас.
Побудова діаграми подій — ефективний проміжний етап перетворення концептуальної моделі в програму імітаційної моделі, який дає змогу здебільшого пропускати етап алгоритмізації моделі та переходити безпосередньо до розроблення програми.
Для розробленої схеми імітаційної моделі описують її функціонування, появу повідомлень у моделі та їх рух по моделі з урахуванням прийнятих алгоритмів.
В описі слід відобразити закони або алгоритми появи повідомлень у моделі, правила входження в черги і виходу з них, алгоритми передавання повідомлень з одного блока моделі в інший, закони або алгоритми, за якими оброблюються (затримуються) повідомлення в блоках обслуговування, а також вибрані дисципліни обслуговування повідомлень.
5.7. Програмна реалізація імітаційної моделі
Програмну реалізацію імітаційної моделі рекомендується будувати за модульним принципом. Це дає змогу удосконалювати модель за допомогою ітераційного методу, додаючи до неї модуль за модулем. У процесі налагоджування та експериментування окремі модулі може бути замінено або змінено, що не призведе до істотних змін в усій моделі.
Структура програми моделі має відповідати структурі імітаційної моделі. Така побудова програми робить її наочною та полегшує її налагоджування. Кожний модуль програми має супроводжуватись коментарем. Програмування та налагоджування моделі доцільно провадити поетапно, з наступним збільшенням програмних модулів.
Для оцінювання правильності функціонування програмної реалізації імітаційної моделі проводяться пробні експерименти (тестування моделі), в яких широко використовуються налагоджувальні засоби вибраної системи моделювання. Більшість мов моделювання має засоби, які дають змогу слідкувати за трасами руху повідомлень у моделі, завдяки чому за різних початкових умов можна переконатися в тому, що модель працює так, як було задумано. Ця перевірка дає змогу визначити, чи відповідає відтворюваний програмою процес функціонування математичній моделі об'єкта і прийнятій концепції. У разі невідповідності процесів функціонування моделі та об'єкта програма коригується. Важливо визначити також чутливість моделі до вхідних даних і функцій розподілів випадкових величин. У тому випадку, коли при незначних змінах вхідних даних вихідні дані істотно змінюються, потрібно визначити блоки, на які впливають ці вхідні дані та у разі необхідності замінити ці блоки більш деталізованими.
Якщо в програмі передбачене закінчення моделювання із досягненням заданого значення модельного часу, то за умови, що прогін налагоджений, воно має бути малим. Це необхідно для того, щоб через модель встигло пройти небагато повідомлень. Таке обмеження слід накладати і тоді, коли передбачене закінчення моделювання під час досягнення заданої кількості повідомлень на виході моделі. Обмеження потрібне, тому що, як звичайно, програміст не впевнений у тому, що модель працюватиме правильно, і невідомо, скільки машинного часу може знадобитись для її прогону.
Типова помилка під час налагодження моделі пов'язана з неузгодженістю пропускної здатності окремих елементів системи, тобто повідомлення надходять у деякі елементи моделі частіше, ніж вони встигають обслуговуватись. Через це доцільно на деяких ділянках моделі, в яких можуть нагромаджуватись повідомлення, задавати обмежувальні умови на довжину черги. У разі виконання цих умов має видаватись повідомлення про те, що черга до певного елемента системи переповнена.
Після закінчення налагоджування функціонування програмної реалізації імітаційної моделі необхідно перевірити її працездатність в усьому діапазоні змін вхідних змінних. Усі значення змінних у моделі має бути зведено до вибраної одиниці модельного часу. Для остаточного тестування моделі на контрольних прикладах необхідно залучати тих людей, які не брали участі в програмуванні моделі, або майбутніх її користувачів. Більш детально процес тестування моделі описується під час розгляду питань про валідацію та верифікацію моделей.
5.8. Автоматизація програмування
Створення імітаційних моделей — складне завдання. Недарма у своїй праці Шеннон [67] ставить програмістів, які створюють програмні реалізації імітаційних моделей, вище, ніж системних програмістів. Перші мислять просторово — часовими образами. Для спрощення процесу створення імітаційних моделей розробляються засоби автоматизації, які дають змогу не тільки вилучити проміжну ланку між аналітиком і людиною, що приймає рішення, а й під час створення моделі використовувати терміни предметної галузі, в якій працює аналітик.
5.8.1. Комп'ютерна інженерія
У 1968 році на одній з конференцій НАТО з проблем розроблення програмного забезпечення було вжито термін «Software Engineering», який перекладається як комп'ютерна інженерія. Так було названо нову наукову дисципліну, об'єктом дослідження якої є великі комп'ютерні системи і проблеми, що виникають під час їх створення.
У наш час продовжують розвиватись різні методи розробки складного програмного забезпечення. У рамках комп'ютерної інженерії робиться спроба визначити абстрактну систему понять цього процесу. Кожний новий підхід передбачає свою систему, яка схожа на інші, але має деякі нюанси.
У цьому розділі розглядаються відомі об'єктно-орієнтовані методи автоматизації створення програмних систем і розкриваються поняття, які використовуються під час розроблення засобів автоматизації проектування імітаційних моделей.
5.8.2. Мова SDL
Застосовувана в моделюванні мова SDL (Specification and Description Language) — це мова специфікацій та опису. Під специфікацією розуміють точне формальне визначення системи або її частини, під описом — неформальну специфікацію, яка ілюструє той або інший аспект системи. Описи використовують на початкових етапах розробки системи або для документування системи. На етапах детального проектування використовують специфікації, за якими передбачається виконання автоматичного генерування програмного коду. Той факт, що для різних етапів розробки системи пропонується одна мова, є суттєвою перевагою SDL, оскільки в такому випадку зникає проблема семантичних розривів.
Мову SDL призначено для розробки подійно-орієнтованих розподілених систем. Ця мова почала розвиватись за сприяння міжнародного комітету ITU ще в 1976 році і є однією з найдавніших розробок в комп'ютерній інженерії. Існує два варіанти цієї мови — текстовий (SDL/PR) та графічний (SDL/GR), синтаксис яких здебільшого співпадає. Викладення основ цієї мови можна знайти в літературі [93]. Крім того, є російський варіант стислого викладення мов SDL і MSC (Message Sequence Chart) [17].
Більше десяти компаній в Європі (Telelogic, Verigol та ін.) розробляють CASE- засоби (Computer-Aided Software Engineering — автоматизоване проектування і створення програм) на основі SDL. Ці продукти використовуються багатьма великими європейськими компаніями — виробниками телекомунікаційних систем.
Крім мови SDL комітетом ITU запропоновано цілу низку стандартів на засоби розробки телекомунікаційних систем. Серед них мови високого рівня CHILL, MSC [35] (графічна мова сценаріїв). У Європі щороку проходить велика кількість конференцій, на яких обговорюються різні аспекти цих стандартів.
Мова SDL як засіб аналізу систем широко використовується в європейських телекомунікаційних стандартах. Її основними складовими є структурна модель і розширений скінченний автомат. Вони орієнтовані на здійснення специфікації подійно-орієнтованих систем, хоча мають ширше використання.
Блочний аналіз є основою структурної декомпозиції системи за допомогою мови SDL. Він передбачає зображення системи у вигляді вкладених одна в одну частин (блоків), які не містять виконуваного коду, а містять лише описи. Блоки можуть відповідати великим модулям системи або підзавданням проекту. Виконуваний код у вигляді розширеного скінченного автомату міститься лише в листках дерева цієї декомпозиції, тобто процесах, які, подібно до блоків, можна поставити у відповідність об'єктам. Тому мову SDL було успішно розширено до об'єктно-орієнтованої мови.
Існують графічні нотації, що призначені для використання на початкових етапах розробки системи, а також процес розробки програмного забезпечення на основі мови SDL. Але на сьогоднішній день ці нотації замінено мовою UML, яка потіснила також SDL. У праці [36] визнано, що SDL є мовою програмування, подібною до Java, С++ та ін. Отже, виникає проблема співіснування UML-описів і SDL-специфікацій.
5.8.3. Метод OOSE
об 'єктно-орієнтований програмний інжиніринг — OOSE (Object-Oriented Software Engineering) описано у монографії [77], яка є однією з фундаментальних праць у галузі досліджень об'єктно-орієнтованих методів розробки програмного забезпечення. Основне завдання цього підходу — наблизити комп'ютерну інженерію до типового промислового процесу, яким є, наприклад, будівництво. Основний принцип підходу — об'єктна орієнтованість, як аналізу, проектування, програмування, так і опису процесу розробки програмного забезпечення загалом.
Підхід призначено, у першу чергу, для розроблення великих систем. На рис. 5.5 зображено рівні технології комп'ютерної інженерії згідно з OOSE. На основі OOSE створено метод Objectory, реалізований у продукті компанії Objectory АВ. У 1995 році, після злиття цієї компанії з корпорацією Rational Software Corp., цей метод використовувався під час створення раціонального об'єднаного підходу — RUP (Rational Unified Approach).
|