Конспект лекцій для студентів спеціальності 05010201 «Комп'ютерні системи та мережі» денної та заочної форм навчання Луцьк 2016



Скачати 492.21 Kb.
Сторінка2/2
Дата конвертації11.05.2017
Розмір492.21 Kb.
ТипКонспект
1   2
Тема 2.
ОБ’ЄКТНО-ОРІЄНТОВАНИЙ ПІДХІД ДО МОДЕЛЮВАННЯ СИСТЕМ

Для швидкої та ефективної розробки програмного продукту необхідно залучити кваліфіковану робочу силу, вибрати правильні інструменти і визначити правильний напрям роботи. Процес розробки проекту необхідно добре продумати, щоб швидко адаптувати його до можливих змін вимог користувачів, потреб бізнесу чи технології. Цього можна досягнути, якщо у процесі розробки проекту використовувати моделі.

Безперечно, розробка сучасних програмних продуктів неможлива без попереднього моделювання. Накопичений досвід засвідчує: чим більшим і складнішим є проект, тим важливішим стає моделювання майбутньої системи.

Моделі наочно демонструють бажану структуру та поведінку системи, відображають її архітектуру та допомагають уточнити деталі проекту з замовником для мінімізації майбутніх ризиків.

Модель – це спрощене представлення реальності, своєрідне “креслення” системи. Кожну систему можна описати по-різному, використовуючи різні моделі, кожна з яких є семантично замкнутою абстракцією системи.

Моделі програмних систем відображають певні аспекти системи. Структурна модель, наприклад, відображає статичну організацію системи, а модель поведінки підкреслює динамічні процеси, притаманні системі.

Зазвичай, моделювання будь-якої системи супроводжується створенням множини моделей для відображення різних аспектів системи. Окрім цього, моделі можуть мати різні рівні абстракції, які відображають одні й ті ж аспекти системи з різним ступенем деталізації.

Моделювання дає змогу розв’язати такі задачі:


  • візуалізація системи – візуальне відображення програмної системи у її поточному чи бажаному стані;

  • специфікація системи – визначення структури і/або поведінки системи;

  • конструювання системи – отримання шаблону, який допоможе сконструювати систему;

  • документування системи – фіксація прийнятих рішень на основі отриманих моделей.

При розробці програмних систем існує декілька методів моделювання, які відрізняються своєю орієнтацією на стиль програмування. Зазвичай, вирізняють п’ять стилів:

  • процедурно-орієнтований – спрямований на представлення програми як множини процедур, які за чергою викликаються;

  • об’єктно-орієнтований – спрямований на представлення програми як набору взаємодіючих об’єктів;

  • логіко-орієнтований – спрямований на виконання цілей, які передано у термінах обчислення предикатів;

  • орієнтований на правила – виконання правил “якщо-то”;

  • орієнтований на обмеження.

Неможливо визнати один стиль програмування найкращим у всіх областях практичного застосування, однак об’єктно-орієнтований стиль використовується для найширшого кола задач.

Якщо об’єктно-орієнтоване програмування спрямоване на правильне й ефективне використання об’єктів у рамках конкретних мов, то об’єктно-орієнтоване моделювання спрямоване на правильне й ефективне структурування складних систем.



Об’єктно-орієнтований метод моделювання передбачає такий аналіз предметної області, за якого уже на початкових етапах розробки програмної системи можна було б вирізняти набори взаємодіючих об’єктів.

Об’єктно-орієнтована модель має чотири головні властивості:

  • абстрагування – виокремлення істотних характеристик об’єкта, що вирізняють його з-поміж інших видів об’єктів;

  • інкапсуляція – приховування внутрішньої реалізації об’єкта за наданим цим об’єктом інтерфейсом;

  • модульність – здатність системи розкладатися на внутрішньо сильно чи слабко зв’язані між собою модулі;

  • ієрархія – упорядкування абстракцій і розташування їх за рівнями.

Ці властивості є головними, і за відсутності будь-якого з них модель не буде об’єктно-орієнтованою.

Існує також три додаткових властивості, корисні в об’єктній моделі, без яких, однак, можна обійтися:



  • типізація – створення об’єктів на основі шаблонів визначеного типу;

  • паралелізм – здатність системи обробляти декілька повідомлень чи задач паралельно;

  • збережуваність – здатність системи зберігати не тільки дані, але й об’єкти у проміжку між окремими запусками системи.

Об’єктно-орієнтоване моделювання програмних систем довело свою корисність при побудові систем будь-якого розміру і складності у різних областях людської діяльності. Окрім того, сучасні мови програмування, інструментальні засоби та операційні системи, здебільшого, є тією чи іншою мірою об’єктно-орієнтованими, а це дає вагомі підстави трактувати світ у термінах об’єктів.

Метод об’єктно-орієнтованого моделювання передбачає послідовне виконання двох етапів: об’єктно-орієнтованого аналізу та об’єктно-орієнтованого проектування.

Аналіз – широке поняття. Його зміст детальніше відображають терміни аналіз системних вимог (тобто дослідження вимог до майбутньої програмної системи) та об’єктний аналіз (тобто дослідження об’єктів предметної області).

При цьому під предметною областю розуміють ту частину реального світу, що має істотне значення чи безпосереднє відношення до процесу функціонування програми. Іншими словами: предметна область містить у собі тільки ті об’єкти і взаємозв’язки між ними, які необхідні для опису вимог і умов розв’язання деякої задачі.

У загальному випадку виділення базових об’єктів (чи компонентів) предметної області є нетривіальною задачею. Складність виявляється у неформальному характері процедур чи правил, які можна застосовувати з цією метою. Окрім того, таку роботу необхідно виконувати спільно з фахівцями чи експертами, що добре знають предметну область.

У процесі проектування головну увагу звертають на концептуальні рішення, які забезпечують виконання системних вимог, а не на питання реалізації. У процесі об’єктно-орієнтованого проектування визначають програмні об’єкти та способи їхньої взаємодії і/або схеми баз даних.

Під час аналізу системних вимог необхідно з’ясувати потреби замовника, аналізуючи отриману інформацію від керівництва компанії та майбутніх користувачів системи. Під час аналізу необхідно визначити:


  • функціональні вимоги до системи (або бізнес-процеси), тобто встановити варіанти використання програмної системи для реалізацій конкретних функцій чи дій у даній предметній області (“визначити те, що система має робити”);

  • потоки даних для кожного бізнес-процесу;

  • границі системи;

  • користувачів системи та процеси їхньої взаємодії з системою.

У результаті аналізу, зазвичай, оформляють словник (або глосарій) предметної області (містить текстовий опис термінів, сутностей, користувачів тощо) і технічне завдання, у якому сформульовано функціональні та нефункціональні вимоги до системи. До нефункціональних вимог відносять питання надійності, зручності використання, продуктивності, можливості супроводу програм, питання безпеки, проектні та апаратні обмеження тощо.

Технічне завдання є гарантією єдиного трактування вимог замовниками і проектувальниками. Воно дає змогу також вирішувати спірні питання з приводу функцій системи, що виникають у процесі її створення.

В UML певним синонімом терміна “технічне завдання” є специфікація вимог до системи (Software Requіrement Specіfіcatіon, SRS), в яких визначаються межі системи, користувачів і функціональні вимоги. SRS є текстовою основою формалізації етапу постановки задачі за допомогою діаграм прецедентів.

UML (Unified Modeling Language) – уніфікована мова моделювання, призначена для моделювання предметних областей з метою розробки відповідного програмного забезпечення.

Історія UML починається 1994 року, коли Граді Буч (Grady Booch) і Джеймс Рамбо (James Rumbaugh), що працювали у Rational Software, об’єднали свої зусилля для створення нової мови об’єктно-орієнтованого моделювання. Третім автором UML вважається Ивар Якобсон (Ivar Jacobson), автор методу OOSE (Object-OrientedSoftware Engineering). Метод Якобсона забезпечував можливості для специфікації бізнес-процесів й аналізу вимог за допомогою сценаріїв використання (Use Case). У результаті спільної роботи та за підтримки консорціуму OMG (Object Management Group) у січні 1997 року з’явилася специфікація UML 1.0. Останньою базовою специфікацією UML вважається 2.0, що була опублікована в серпні 2005 року. У версії 2.0. семантика мови UML була значно уточнена й розширена для підтримки методології «архітектури на базі моделей» MDA (Model DrivenArchitecture).

UML необхідний:


  • керівникам проектів, які керують розподілом завдань і контролем за проектом;

  • проектувальникам інформаційних систем які розробляють технічні завдання для програмістів;

  • бізнес-аналітикам, які досліджують реальну систему і здійснюють інжиніринг і реінжиніринг бізнесу компанії;

  • програмістам які реалізовують модулі інформаційної системи.

Загальна характеристика UML

Найважливішою складовою UML є графічна нотація (рис. 7), що дозволяє специфікувати, проектувати, візуалізувати і документувати артефакти об’єктно-орієнтованого програмного забезпечення.


Рис. 7. Структура графічної нотації мови UML версії 2.3


Графічна нотація UML спеціально розроблювалася для того, щоб діаграми було легко створювати на папері. Найбільш відомі CASE засоби, що підтримують UML: IBM Rational Rose; Microsoft Visio; SparxSystems Enterprise Architect; Gentleware Poseidon; SmartDraw; Telelogic TAU G2; StarUML та ін. (гарний огляд CASE засобів зробив О.В.Бабіч у його введенні у UML).

Використання UML не обмежується лише розробкою програмного забезпечення. Її також застосовують для створення схем даних (Entity-Relationship Diagram, ERD), моделювання бізнес-процесів (workflows), проектування компонентів систем та ін. Для моделювання систем було розроблене спеціальне розширення UML – SysML (Systems Modeling Language) – мова моделювання систем.

SysML підтримує визначення, аналіз, проектування, перевірку й підтвердження відповідності широкого спектра систем. У порівнянні з UML, що орієнтована на моделювання програмних продуктів, SysML надає системному інженеру деякі додаткові можливості.

SysML розширює UML за рахунок введення двох додаткових типів діаграм: діаграми вимог і параметричної діаграми. Перша служить для збору та ієрархічного структурування вимог, а друга для кількісного аналізу параметрів систем (наприклад, продуктивності або надійності). У результаті розширюється коло модельованих систем, елементами яких можуть бути програмні компоненти, апаратне забезпечення, обладнання, процеси, інформація, персонал та ін.

Зазначимо, що SysML є також більш компактною нотацією, вона не включає багато програмно-орієнтованих особливостей UML, саме тому її легше вивчати й застосовувати.

Відзначимо деякі інші відомі розширення (профілі) UML – Modeling and Analysis of Real-Time Embedded systems (MARTE), Service oriented architecture Modeling Language (SoaML), UML Profile for CORBA, UML Profile for Data Distribution, UML Profile for Enterprise Application Integration (EAI), UML Profile for System on a Chip (SoC) та ін.

Переваги UML

Відзначимо переваги UML, які найчастіше виділяють її розробники:



Повнота опису предметних областей. UML дозволяє описувати предметні області практично із всіх можливих точок зору.

Розширюваність. UML дозволяє вводити власні текстові й графічні стереотипи, що сприяє розширенню області його застосування (і, таким чином, використанню не тільки в сфері програмної інженерії). У версії UML 2.0. полегшене додавання «семантичних варіацій» (введеної користувачем семантики), що приводить до визначення UML, як сімейства мов моделювання.

Уніфікованість. Завдяки своїй «універсальності» UML дозволяє розроблювачам програмного забезпечення досягти угоди в графічних позначеннях і тлумаченні семантики множини загальних понять моделювання й програмування (таких як клас, компонент, узагальнення, агрегація, поведінка та ін.).

Відповідність передовим методологіям програмування. UML є об’єктно-орієнтованою мовою моделювання, тому UML методи аналізу й проектування близькі до методів програмування у найбільш ефективній на сьогоднішній день парадигмі об’єктно-орієнтованих мов.

Незалежність від інструментів реалізації. UML є специфікацією мови моделювання, та не залежить від інструментів її реалізації, конкретних мов програмування й процесів розробки,

Простота графічної нотації. Діаграми UML є простими для розуміння користувачів (фахівців предметних областей), після досить швидкого ознайомлення з їх синтаксисом.

Підтримка співтовариства. UML одержав широке поширення й динамічно розвивається завдяки зусиллям OMG-консорціуму.

Недоліки UML



Розглянемо також великий список недоліків UML (цікавим є те, що деякі з них були також подані у списку переваг):

Множина діалектів. UML підхід претендує на універсальність, тоді як аспекти конкретних систем залишаються поза її полем зору. Для підтримки конкретної предметної області розробляються окремі діалекти, які підривають повноцінність вихідної методології UML (а саме, застосовність до моделювання будь-яких предметних областей).

Уніфікованість. Як слушно зазначається у уніфікація є корисною далеко не завжди. Абстракції, до яких доводиться прибігати при використанні будь-якого універсального підходу, ховають у собі багато небезпек, оскільки розуміння того, що конкретно означає кожна абстракція, у кожної людини є власним.

Надмірність (перевантаженість) мови. UML включає множину практично невикористовуваних для моделювання програмних систем діаграм і конструкцій.

Складність концепцій. Стандарт UML 2.0 містить великий набір концепцій моделювання, що складним чином пов’язані між собою. Це зумовлено тим, що мова призначена для підтримки моделювання в різних предметних областях.

Відсутність ортогональності концепцій. UML не має строгої формальної основи, а також спирається на базові поняття, що семантично перекриваються. Інакше кажучи, UML бракує ортогональності у визначенні опорних концепцій для моделювання предметних областей .

Неточна семантика. UML визначена через абстрактний синтаксис, мову опису обмежень OCL (Object Constraint Language) та природну англійську мову, специфікації в яких часто суперечать одна одній. Як наслідок, завдяки різному тлумаченню специфікацій, побудовані UML моделі виявляються несумісними в різних CASE інструментах. Крім того, не дивлячись на широке цитування, сама UML специфікація є прикладом тексту, написаного людьми, що, м’яко кажучи, не є природними носіями англійської мови.

Обмеження користувача. Як і будь-яка система позначень, UML може виразити властивості одних систем більш ефективно, ніж інші. Як наслідок, розроблювач схиляється до рішень, в яких в моделях здійснюється відхід від «чистого» UML і переплітаються сильні сторони UML і мов розробки. UML можна визначити як не що інше, як графічний спосіб подання вимог і специфікацій, що спочатку мали текстову форму. Такий підхід змушує розроблювачів думати в контексті пропонованих графічних нотацій і шаблонів розробки, та має результатом неоптимальні системні рішення.

Залежність від об’єктно-орієнтованої парадигми. Хоча UML створювався з метою забезпечення незалежності від конкретних мов програмування й процесів розробки, його моделі досить складно трансформуються в інші, ніж ОО, мови розробки.

Складність стикування з мовами розробки. UML визначається як мова моделювання загального призначення, що повинна бути сумісною з усіма можливими мовами розробки. Але це є практично нездійсненним завданням за перерахованими вище причинами (недостатня формалізованість, перевантаженість, залежність від ОО й ін.).

Складність розширень. UML 2.0 не має механізмів створення моделей з використанням понять, що відрізняються від наявних у мові. Іншими словами, опис систем з погляду та у поняттях користувача (фахівців предметних областей ) є неможливим.

Проблеми при вивченні й впровадженні. Вищеописані проблеми роблять проблематичним вивчення й впровадження UML. На практиці, люди (фахівці предметних областей) часто будують UML діаграми з використанням символів, що надають їм CASE інструменти, не розуміючи, що насправді ці символи позначають в UML специфікації.

Неможливість зміни процесу моделювання. Хоча UML повинна бути застосовна у контексті будь-якого процесу моделювання, досвід доводить, що для різних організацій і предметних областей необхідне визначення власних процесів. Наприклад, процес розробки програмного забезпечення для систем реального часу значно відрізняється від розробки програмного забезпечення для інших цілей.

Ефективність коду. Цінність UML полягає в можливості генерації з моделі ефективного вихідного програмного коду або ж коду, що можна виконати. Однак UML-модель не має властивостей повноти за Тьюрингом і генерований код в основному обмежується структурою класів й оголошенням функцій.

Шляхи подолання недоліків

Визначимо шляхи подолання недоліків універсальної мови моделювання UML, які були визначені нами раніше.

Множина діалектів та універсальність. Досвід доводить, що неможливо побудувати мову чи інструмент, пригідний для моделювання всіх без винятку предметних областей . Саме тому кожна з предметних областей повинна мати власну мову моделювання, призначену для розв’язання специфічних для предметної областві задач. Це приводить нас до розуміння та необхідності визначення принципів інструментарію, що дозволяє розроблювати інші, (предметно-орієнтовані) мови моделювання.

Надмірність (перевантаженість) мови та складність концепцій. Користувач повинен сам вибирати систему понять і зв’язків між ними, необхідних і достатніх для моделювання предметних областей . Саме тому такий підхід визначається як предметно-орієнтований. Це дозволяє позбавитися як перевантаженості так і складності мови моделювання. Користувач може створити та надалі використовувати при моделюванні предметних областей лише ті поняття, семантику яких він добре розуміє.

Відсутність ортогональності концепцій. Надання можливості користувачу визначення власних понять мови моделювання також дозволяє побудувати мінімальну систему понять, що є семантично ортогональними. Але зазначимо, що ця задача повністю лежить на плечах користувача.

Неточна семантика. Саме тому дуже важливим є формальне визначення як моделей предметних областей , так і призначених для їх породження метамоделей (мов моделювання), які будуються на основі певних математичних теорій (теорії графів, векторної алгебри, логіки та ін.).
Тема 3.
ІНСТРУМЕНТАЛЬНІ ЗАСОБИ МОДЕЛЮВАННЯ.

Моделювання з використанням математичних пакетів

Сучасний процес моделювання важко реалізувати без комп’ютерів або вбудованих контролерів. Для цього використовуються різноманітні інструментальні програмні засоби та середовища (MathCad, MatLab, Mathematіca, Maple, Derive, VisSim, Genius й інші), що суттєво спрощують моделювання.

При дослідженні систем автоматичного регулювання, обчислювальних математичних задач, найбільш ефективним є використання програмної системи Matlab з широким класом предметно-орієнтованих бібліотек (toolbox) та інструментом візуального моделювання Simulink. У системі MatLab також існують широкі можливості для програмування. Її бібліотека C Math (компілятор MatLab) є об'єктною і містить понад 300 процедур обробки даних мовою C. Усередині пакета можна використовувати як процедури самої MatLab, так і стандартні процедури мови C, що робить цей інструмент наймогутнішою підмогою при розробці додатків (використовуючи компілятор C Math, можна вбудовувати будь-які процедури MatLab у готові додатки).

Для візуалізації моделювання система MatLab має бібліотеку Іmage Processіng Toolbox, що забезпечує широкий спектр функцій, що підтримують візуалізацію проведених обчислень безпосередньо із середовища MatLab, збільшення та аналіз, а також можливість побудови алгоритмів обробки зображень. Систему MatLab можна використовувати для обробки зображень, сконструювавши власні алгоритми, які будуть працювати з масивами графіки як з матрицями даних. Оскільки мова MatLab оптимізована для роботи з матрицями, у результаті забезпечується простота використання, висока швидкість і економічність проведення операцій над зображеннями.

Серед інших бібліотек системи MatLab можна також відзначити System Іdentіfіcatіon Toolbox – набір інструментів для створення математичних моделей динамічних систем, заснованих на спостережуваних вхідні/вихідних даних. Особливістю цього інструменту є наявність гнучкого користувацького інтерфейсу, що дозволяє організувати дані й моделі. Бібліотека System Іdentіfіcatіon Toolbox підтримує як параметричні, так і непараметричні методи. Інтерфейс системи полегшує попередню обробку даних, роботу з ітеративним процесом створення моделей для одержання оцінок і виділення найбільш значимих даних. Що стосується математичних обчислень, то MatLab надає доступ до величезної кількості підпрограм, що містяться в бібліотеці NAG Foundatіon Lіbrary компанії Numerіcal Algorіthms Group Ltd (інструмент має сотні функцій з різних областей математики, і багато з цих програм були розроблені широко відомими у світі фахівцями). Це унікальна колекція реалізацій сучасних чисельних методів комп'ютерної математики, створених за останні три десятки років. Лише додану до системи велику кількість документації цілком можна розглядати як фундаментальний багатотомний електронний довідник по математичному забезпеченню. Сьогодні система MatLab широко використовується в техніці, науці та освіті, але все-таки вона більше підходить для аналізу даних і організації обчислень, ніж для чисто математичних викладень.

Для візуального моделювання та моделювання сумісно з реальною апаратурою більш зручним є програмний пакет VisSim.

Аналітичні перетворення дозволяють виконувати більшість математичних програмних продуктів MathCad, Mathematіca, Maple. З цих трьох поширених математичних пакетів, найбільш потужним є Maple. Maple надає зручне середовище для комп'ютерних експериментів. Пакет дозволяє створювати інтегровані середовища за участю інших систем і універсальних мов програмування високого рівня. Коли розрахунки зроблені й потрібно оформити результати, то можна використовувати засоби цього пакета для візуалізації даних і підготовки ілюстрацій для публікації.. Робота проходить интерактивно - користувач уводить команди й відразу бачить на екрані результат їхнього виконання. При цьому пакет Maple зовсім не схожий на традиційне середовище програмування, де потрібна тверда формалізація всіх змінних і дій з ними. Тут же автоматично забезпечується вибір типів змінних і перевіряється коректність виконання операцій, так що в загальному випадку не потрібно опису змінних і строгої формалізації запису. Ядро символьних обчислень Maple включено до складу цілого ряду систем комп'ютерної математики – від систем для широкого кола користувачів типу MathCad до однієї із кращих систем для чисельних розрахунків і моделювання MatLab.

На відміну від потужного та орієнтованого на високоефективні обчислення при аналізі даних пакета MatLab, програма MathCad – це, скоріше, редактор математичних текстів із широкими можливостями символьних обчислень і прекрасним інтерфейсом. MathCad не має мови програмування як такої, а можливості символьних обчислень запозичений з пакета Maple. Проте інтерфейс програми MathCad дуже простий, а можливості візуалізації широкі. Всі обчислення тут здійснюються на рівні візуального запису виразів у загальновживаній математичній формі. Пакет має гарні підказки, докладну документацію, цілий ряд додаткових модулів та вбудованих функцій. Однак поки математичні можливості MathCad уступають системам Maple, Mathematіca, MatLab. Не зважаючи на це, по програмі MathCad випущено багато книг і навчальних курсів. Сьогодні ця система стала буквально міжнародним стандартом для технічних обчислень. Розробники Mathcad зробили все можливе, щоб користувач, який не володіє спеціальними знаннями в програмуванні, міг реалізувати велику кількість обчислювальних методів та досягнути значного результату в області математичних розрахунків.

Звичайно, кожен з математичних пакетів має свої переваги та недоліки та є зручнішим для розв’язання конкретних завдань. В даній книзі більш детально зосереджено увагу на системах MatLab та MathCad, які орієнтовані на різні типи задач і дають можливість розв’язання різних за складністю завдань.


Імітаційне моделювання

Імітаційне моделювання – це метод дослідження, при якому досліджувана система замінюється моделлю, що з достатньою точністю описує реальну систему, з нею проводяться експерименти з метою одержання інформації про цю систему.

Відомі фахівці в галузі імітаційного моделювання Р. Ненсі і Ф. Кивіат у своїх роботах визначили декілька етапів у практиці розвитку імітаційного моделювання.



Етап 1 (1955 – 1960). Програми для завдань моделювання розроб-лялися на основі таких загальновідомих універсальних мов як FORTRAN і ALGOL.

Етап 2 (1961 – 1965). З'явилися перші мови моделювання: GPSS, SIMSCRIPT, SIMULA, CSL, SОL. Була розроблена так звана концепція погляду на світ (world view).

Етап 3 (1965 – 1970). З'явилося друге покоління мов моделювання GPSS V, SIMSCRIPT II.5, SIMULA 67.

Етап 4 (1971 – 1978). Розвиток вже розроблених мов і засобів моделювання, орієнтоване передусім на підвищення ефективності процесів моделювання і перетворення моделювання в більш простий і швидкий метод дослідження складних систем. Роботи Зейглера і Йорена зіграли важливу роль у вирішенні проблеми таксономії імітаційних моделей (вони запровадили метаконцепції моделі і схеми експерименту).

Етап 5 (1979 – 1984). Роки переходу від програмування до розвитку моделей. Основний акцент був перенесений на ідентифікацію інтегрованих засобів імітаційного моделювання.

Процес моделювання включає такі етапи, як створення моделі, програмування, проведення імітаційних експериментів, обробку й інтерпретацію результатів моделювання. Проте традиційно перевага віддавалася етапу програмування. Схема моделювання, що виникає при цьому, багато в чому повторює схему проведення натурних випробувань і зводиться лише до імітації траєкторій вивчених моделей. З появою іміта-ційних моделей змінилася концепція моделювання, яка тепер розгляддається як єдиний процес побудови і дослідження моделей, що має програмну підтримку. Тепер основним є формальне поняття моделі, яке не тільки пояснює динаміку системи, але і служить предметом математичних досліджень. Стає можливим достовірний аналіз багатьох практично важливих властивостей моделі (стаціонарних розподілів, малої ймовірності, чутливості, надійності і достовірності результатів моделювання). Ці властивості особливо суттєві при дослідженні високовідповідальних і крупномасштабних систем, де ціна помилки особливо висока.



Етап 6 (1985 – 1994). Перенесення програмного забезпечення для імітаційного моделювання на персональні ЕОМ з використанням засобів графічного інтерфейсу (для візуалізації й анімації процесів моделювання).

Етап 7 (1995 – 1998). Розробка засобів технологічної підтримки процесів розподіленого імітаційного моделювання на мультипроцесорних ЕОМ і мережах.

До моменту початку розробки (1966 р.) першої в Україні мови моде-лювання систем із дискретними подіями були відомі закордонні аналоги таких мов, як SIMSCRIPT, SОL, і SIMULA. Та за умовами того часу не було можливості придбати відповідне програмне забезпечення за кордоном. Була можливість ознайомитися з відповідними розробками тільки на рівні публікацій. Тому в Інституті кібернетики академії наук України було прийняте рішення про розробку власної мови і системи моделювання.

Протягом 1966 – 1968 рр. в Інституті кібернетики під керівництвом Марьяновіча Т. П. виконувалися роботи зі створення мови і системи моделювання систем з дискретними подіями СЛЕНГ, що і поклало початок розвитку методів імітаційного моделювання в Україні. Як прототип була вибрана мова SOL.

У 1973 році в Інституті кібернетики була завершена робота зі створення і реалізації на ЕОМ БЕСМ-6 системи АЛСИМ-БЕСМ. Система призначалася для дослідження обчислювальних систем і мереж. У системі були виділені три мовні рівні: мова опису моделей, мова управ-ління моделюванням, мова управління завданнями.



Одні з кращих мов імітаційного моделювання, такі як СЛЕНГ, АЛСИМ, НЕДІС, були створені Інститутом кібернетики АН України.

Відомо багато систем моделювання (більше 500). Серед найбільш використовуваних згадуються Симула і GPSS. Необхідно також назвати мову Симскрипт (створену на базі Фортрана), алголоподібну мову SOL, ПЛИС (інтергує можливості ПЛ/1 і GPSS), Паскаль Плюс (розширений вбудованими засобами моделювання), система СМДП (діалогова версія GPSS).

Імітаційне моделювання застосовують, коли:


  • дорого або неможливо експериментувати на реальному об'єкті;

  • неможливо побудувати аналітичну модель, тому що в системі є час, причинні зв'язки, наслідки, нелінійності, стохастичні (випадкові) змінні;

  • необхідно зімітувати поведінку системи в часі.

Імітаційне моделювання може застосовуватися у різних сферах діяльності. Особливо ефективне моделювання при вирішенні наступних завдань:

  • проектування та аналіз виробничих систем;

  • оцінка різних систем озброєнь;

  • визначення вимог до устаткування та протоколів мереж зв'язку;

  • модернізація різних процесів у діловій сфері;

  • аналіз фінансових і економічних систем.

Під імітаційною системою розуміють програмний або апаратно-програмний комплекс, призначений для рішення завдань із використанням методу імітаційного моделювання. При виділенні різновидів імітаційних систем виходять із того, що вони є інструментальними засобами, що забезпечують автоматизовану підтримку певних видів діяльності користувача.

Імітаційна система реалізує алгоритм рішення завдання і надає користувачеві сервісні можливості по керуванню обчислювальним процесом. Автоматизована підтримка інших етапів системного аналізу засобами імітаційної системи не є обов'язковою. Однак саме ступінь їхньої автоматизації визначає можливості імітаційної системи і є основою їхньої класифікації. З урахуванням етапності системного аналізу і технологічних завдань, що розв'язуються на них, виділимо можливий набір засобів імітаційної системи, що автоматизують виконання ряду функцій, реалізованих на цих етапах.

1. Створення моделі може бути підтримано наступними засобами автоматизації:

а) частково готовою моделлю або моделями;

б) компіляторами з алгоритмічної мови високого рівня, спеціалізація якого полегшує процес складання алгоритмів імітації;

в) спеціальною мовою високого рівня, що дозволяє виконати інформаційний або математичний опис моделі системи;

г) конверторами моделей, що дозволяють здійснювати перетворення моделей одного виду в моделі іншого виду (інформаційної в математичну, математичної в імітаційну, інформаційної в імітаційну);

д) засобами контролю погодженості різних видів моделей з концептуальним поданням моделі.

2. Перевірка адекватності та технічної реалізованості може виконуватися з використанням:

а) програм обчислення показників адекватності;

б) автоматизованої технології проведення обмеженого експерименту з імітаційною моделлю;

в) програм обчислення характеристик складності моделі;

г) програм обчислення ресурсних показників методу рішення завдання.

3. Корекція моделі може забезпечуватися:

а) автоматизованими технологіями редагування текстів моделей;

б) програмами еквівалентних перетворень математичних і алгоритмічних моделей заданого класу.

4. Створення алгоритму рішення завдання може підтримуватися:

а) методо-орієнтованими бібліотеками та пакетами програм;

б) конструкторами алгоритмів рішення завдань;

в) інформаційними системами підтримки прийняття рішень тощо.

5. Складання і уточнення схеми рішення завдання може виконуватися з використанням:

а) програмних засобів контролю інформаційної сумісності сімейства завдань;

б) редакторів текстів обчислювальних схем тощо.

При виборі засобів імітаційного моделювання варто враховувати всі можливості, що вони надають, які можна об'єднати в наступні групи:



  • основні характеристики;

  • сумісне програмне забезпечення;

  • анімація;

  • статистичні можливості;

  • звіти з вихідними даними і графіками;

  • послуги, що надаються замовникам і документація.

Найпопулярнішими пакетами імітаційного моделювання є:

1. Arena компанії Rockwell Automatіon;

2. AnyLogіc компанії XJ Technologіes;

3. GPSS World фірми Minuteman Software;

4. Process Charter 1.0.2 компанії Scіtor;

5. Powersіm 2.01 фірми Modell Data AS;

6. Іthіnk 3.0.61 виробництва Hіgh Performance Systems;

7. Extend+BPR 3.1 компанії Іmagіne That!;

8. Vensіm фірми Ventana Systems.

Ці пакети найбільше відрізняються стилем моделювання, тобто середовищем, за допомогою якого створюються моделі. У пакеті Process Charter модель будується за допомогою блок-схеми. Powersіm і Іthіnk використовують систему позначень Systems Dynamіcs, запропоновану в 1961 р. Джеем Форрестером Массачусетсского технологічного інституту. Extend застосовує компоновочні блоки. Всі продукти, крім Process Charter, дозволяють проводити аналіз чутливості, тобто багаторазово виконувати модель із різними вхідними параметрами, щоб зрівняти результати декількох прогонів.

Більш детально розглянемо найбільш поширені пакети для імітаційного моделювання.

GPSS World

GPSS World (GPSSW, General Purpose System Simulation World – Світова загальноцільова система моделювання), розроблена для ОС Wіndows. Цей програмний продукт увібрав в себе весь арсенал новітніх інформаційних технологій. Він включає розвинені графічні оболонки для створення моделей і інтерпретації вихідних результатів моделювання, засоби мультимедіа та відео, объектно-орієнтоване програмування та ін. В основу системи GPSS World покладена мова імітаційного моделювання GPSS (General Purpose System Sіmulatіon – Загальноцільова система моделювання).

Система GPSS World – потужне універсальне середовище моделювання як дискретних, так і неперервних процесів, призначене для професійного моделювання найрізноманітніших процесів і систем. За допомогою цієї системи, наприклад, можна ефективно моделювати як виробничі, так і невиробничі процеси: функціонування торговельних і розважальних закладів, портів, вуличний рух, проведення воєнних дій, роботу редакцій, установ і мережі Іnternet, різних систем масового обслуговування тощо. Система має великий набір команд для керування процесом моделювання, які можна як використовувати в інтерактивному режимі, так і включати в модель. Забезпечено можливість проведення експериментів, згенерованих системою, користувацьких і оптимізаційних. У системі GPSSW реалізована процедура візуалізації процесу функціонування моделі з використанням методів мультиплікації. Також система GPSSW має новий високошвидкісний транслятор, що працює в сотні раз швидше його попередників. Для швидкого виправлення помилок використовується повноекранний текстовий редактор.

Система GPSSW досить проста у вивченні і універсальна в застосуванні. Ефективне використання системи передбачає виконання ряду етапів:

1. Постановка задачі.

2. Виявлення основних особливостей.

3. Створення імітаційної моделі процесу.

4. Подання імітаційної моделі в системі GPSSW.

5. Моделювання системи.

В якості прикладу представимо модель одноканальної розімкнутої системи масового обслуговування (СМО). На рис. 8 представлена модель найпростішої системи масового обслуговування, у якій виділені основні події.

Рис. 8 – Найпростіша система масового обслуговування


Охарактеризуємо кожну подію, що виникла в СМО:

1. Поява вимоги в системі (GENERATE – Генерувати).

2. Вхід вимоги в чергу (QUEUE – Черга).

3. Визначення зайнятості каналу обслуговування (SEІZE – Зайняти). Якщо канал зайнятий, то вимога залишається в черзі, якщо вільний – то входить у канал обслуговування.

4. Вихід вимоги із черги (DEPART – Вийти).

5. Обслуговування вимоги в каналі обслуговування (ADVANCE – Затримати).

6. Звільнення каналу обслуговування (RELEASE – Звільнити).

7. Вихід вимоги із системи (TERMІNATE – Завершити).

Ця програма в системі GPSSW буде виглядати так, як показано на рис.9. Використані в програмі оператори повністю відповідають змісту і логіці системи що моделюється. Праворуч від операторів пишуться параметри (ознаки, змінні), які характеризують дану подію. Так, в операторі GENERATE перша цифра – 7, визначає середній інтервал часу між надходженнями вимог у систему на обслуговування, а друга – 2, максимально припустиме відхилення від середнього часу. В операторах QUEUE і DEPART цифра 1 визначає номер черги, у яку ввійшла і з якої має вийти вимога. В операторах SEІZE і RELEASE символи KAN визначають символічне ім'я каналу обслуговування, у який збирається ввійти вимога, якщо він звільнився, і вийти – якщо вимога вже в ньому закінчила обслуговування. В операторі ADVANCE перша цифра – 6, визначає середній час обслуговування вимоги, а друга – 3, максимально припустиме відхилення від цього часу. Оператор TERMІNATE виконує видалення однієї вимоги із системи. Цифра 200 в операторі START означає число вимог, які необхідно пропустити через систему.

Рис. 9 – Вікно з введеною в нього моделлю одноканальної розімкнутої СМО


В цьому прикладі вимоги надходять на обслуговування в систему випадково в інтервалі [5-9] одиниць часу з рівномірним розподілом. А час обслуговування коливається в інтервалі [3-9] одиниць часу, також з рівномірним розподілом. При цьому моделюється проходження через систему 200 вимог.

Пакет імітаційного моделювання Rockwell Arena.

Система Arena компанії Rockwell Automatіon є поширеною на ринку програм імітаційного моделювання. В Arena використовується процесор і мова імітаційного моделювання SІMAN. Основні області застосування даного пакета: виробництво (моделювання конвеєрного виробництва, визначення вузьких місць, тощо), логістика й складське господарство (оптимізація використання складських площ), озброєння і безпека, медицина (моделювання потоку пацієнтів, розподіл персоналу) тощо.

Arena надає користувачеві зручний графічний інтерфейс із набором шаблонів моделюючих конструкцій. Для створення моделі в пакеті Arena моделюючі конструкції спочатку перетягують у вікно моделі, а потім з'єднують, щоб позначити рух об'єктів у системі. Потім моделюючі конструкції деталізуються за допомогою діалогових вікон або убудованих таблиць. В ієрархії моделі може бути необмежене число рівнів. Rockwell Arena випускається тільки для операційної системи Wіndows. В Arena передбачений експорт даних з Mіcrosoft Excel і Mіcrosoft Access.

Число потоків випадкових чисел у пакеті Arena не обмежено. Більше того, користувач має доступ до 12 стандартних теоретичних розподілів ймовірностей, а також до емпіричних розподілів.

Arena забезпечує виведення на екран двомірної й тривимірної (Arena 3DPlayer) анімації й дозволяє виводити на екран динамічну графіку (гістограми та графіки тимчасової залежності).

Пакет імітаційного моделювання AnyLogіc.

AnyLogіc – програмне забезпечення для імітаційного моделювання складних систем і процесів, розроблене російською компанією XJ Technologіes.

Графічне середовище AnyLogіc побудоване по тому ж принципі, що і у Rockwell Arena. Моделюючі конструкції розташовуються в палітрах (аналог шаблонів в Arena). Для створення моделі, як і в Arena, моделюючі конструкції перетягують в область моделі і з'єднують. Деталізувати моделюючі конструкції можна, виділивши їх і змінивши параметри, використовуючи панель властивостей. AnyLogіc підтримує ієрархічне моделювання, а також створення власних моделюючих конструкцій і об'єднання їх у бібліотеки (тільки для версії Professіonal). AnyLogіc заснований на Java і базується на платформі Eclіpse – сучасному стандарті для бізнесів-додатків. Завдяки Eclіpse AnyLogіc працює на всіх поширених операційних системах (Wіndows, Mac, Lіnux і т.д.).

У редакторі AnyLogіc можливо розробити анімацію та інтерактивний графічний інтерфейс моделі. Анімація може бути ієрархічної і підтримувати кілька перспектив. Наприклад, можна визначити глобальний погляд на процес виробництва, а також детальні анімації конкретних операцій, а потім перемикатися між ними.

В AnyLogіc користувачеві доступно 29 стандартних теоретичних розподілів. Є можливість зафіксувати набір випадкових чисел і зробити абсолютно ідентичний експеримент.

Для створення звітів в AnyLogіc відведена спеціальна палітра "Статистика", у якій утримуються конструкції для збору даних по ходу роботи моделі. У цій палітрі також знаходяться різні діаграми, графіки та гістограми.

Для порівняння систем на практиці були побудовані дві ідентичні моделі (для AnyLogіc і для Arena) мережі передачі даних (рис.10-11). Процес побудови моделі в AnyLogіc і в Arena мало відрізняються, як і зовнішній вигляд моделей. У представленій моделі за основу прийняті пакети даних, джерелами яких є комп'ютери віддалених користувачів. У моделі є ресурси мережевих адаптерів і маршрутизатора. Ємність маршрутизатора дорівнює 1, тобто в кожний момент часу, маршрутизатор може обробляти тільки один пакет. За допомогою даної моделі можна оцінити максимальне навантаження мережі із заданою пропускною здатністю. З рис. 10 видно, що в Arena на відміну від AnyLogіc, немає окремої конструкції для черг. Черги створюються разом з ресурсами обмеженої ємності.

Прогін моделі на AnyLogіc виявився в декілька разів швидше, ніж в Arena. Після прогону моделі, Arena вивела на екран результати моделювання у вигляді звіту, що містить наступну інформацію: середній, максимальне й мінімальний час перебування пакетів даних; середні довжини черг; завантаженість ресурсів тощо.


Рис. 10 – Модель в Arena



Рис. 11 – Модель в AnyLogіc

Прогін моделі в AnyLogіc здійснюється в окремому вікні у вигляді презентації. Єдиною вбудованою статистикою, що збирається для черг в AnyLogіc, є середня довжина черги; для ресурсів – завантаження. Для одержання додаткових даних про систему, необхідно створювати власні збирачі статистики.

Пакет MatLab Simulink

Крім розглянутих спеціалізованих пакетів для імітаційного моделювання, пакет розширення MatLab Simulink for Windows також служить для імітаційного моделювання моделей, що складаються із графічних блоків із заданими властивостями (параметрами). Компоненти моделей, у свою чергу, є графічними блоками і моделями, які містяться в ряді бібліотек і за допомогою миші можуть переноситися в основне вікно та з'єднуватися один з одним необхідними зв'язками. До складу моделей можуть включатися джерела сигналів різного виду, віртуальні прилади, що реєструють, графічні засоби анімації. Подвійне клацання мишею на блоці моделі виводить вікно зі списком його параметрів, які користувач може змінювати. Запуск імітації забезпечує математичне моделювання побудованої моделі з наочним візуальним поданням результатів.

Пакет заснований на побудові блокових схем шляхом переносу блоків з бібліотеки компонентів у вікно редагування створюваної користувачем моделі. Потім модель запускається на виконання. На рис. 12 показаний процес моделювання передачі даних з перешкодостійким кодуванням. Можливе моделювання складних систем, що складаються з множини підсистем. Sіmulіnk складає і вирішує рівняння стану моделі і дозволяє підключати в потрібні її точки різноманітні віртуальні вимірювальні прилади.


Рис. 12 – Модель системи передачі даних з перешкодостійким кодуванням по коду Хемінга

Принцип роботи моделі здійснюється на основі структурної схеми (рис. 13) системи передачі даних з використанням кодів, що виправляютьпомилки.

Рис. 13 – Структурна схема системи зв’язку з використанням кодів, що виправляють помилки


Джерело даних (Bernoulli BinaryGenerator) генерує дані у вигляді двійкових символів. Потім кодуючий пристрій (Hamming Encoder) вносить в прийняту інформаційну послідовністьність деяку надмірність, яку декодер (Hamming Decoder) зможе використовувати для виправлення помилок, які виникають при передачі даних по каналу зв'язку. Імовірність помилки в каналі зв’язку (Binary Symmetric Channel) моделюється нормальним розподілом випадкових чисел (Random Number). Візуалізація вихідних параметрів проводилася в осцилографах (Scope).

В ході імітаційного моделювання були отримані часові діаграми роботи даної системи. Виводилися пакети даних каналу зв'язку без перешкод і при впливі перешкод відповідно. Діаграма представлена на рис. 14. Діаграма отримана при ймовірності помилки не більше 1%. Це призводить до виникнення помилок при передачі даних, які видно неозброєним оком. Для повного визначення кількості помилок в каналі зв'язку скористаємося діаграмою, представленою на рис. 15, яка також отримана в ході моделювання.



Рис. 14 – Часова діаграма каналу зв’язку при передачі даних



Рис. 15 – Діаграма ідентифікації помилок по коду Хеммінга




СПИСОК РЕКОМЕНДОВАНИХ ДЖЕРЕЛ

  1. Бибило П.Н. Основы языка VHDL: Учебное пособие. Издание 5-е. – М.: Книжный дом «ЛИБРОКОМ», 2012. – 328 с.

  2. Дудзяний І. М. Об’єктно-орієнтоване моделювання програмних систем [Електроннний ресурс] –Режим доступу: http://pirjatin.e-u.in.ua/files/student/oop.pdf

  3. Жерновий Ю. В. Імітаційне моделювання систем масового обслуговування [Електроннний ресурс] –Режим доступу: http://zyurvas.narod.ru/Queuing/Imit_model.pdf

  4. Задачин В.М., Конюшенко І.Г. Моделювання систем [Електроннний ресурс] –Режим доступу: http://repository.hneu.edu.ua/jspui/bitstream/123456789/2749/1/Конспект%20лекцій%20Моделювання%20систем.%20Задачин%20В.%20М..pdf

  5. Махней О. В. Лабораторний практикум з iмiтацiйного моделювання у GPSS [Електроннний ресурс] –Режим доступу: http://www.mif.pu.if.ua/attachments/article/14/lab_GPSS_el.pdf

  6. Руководство пользователя по GPSS World / пер. с англ. – Казань : Мастер Лайн, 2002. – 384 с.

  7. Томашевський В. М. Моделювання систем / В. М. Томашевський. – К. : Видавнича група BHV, 2005. – 349 с.

  8. Visio Stencil and Template for UML 2.5 [Електроннний ресурс] –Режим доступу: http://www.softwarestencils.com/uml/index.html



НАВЧАЛЬНО-МЕТОДИЧНЕ ВИДАННЯ













М74

Моделювання комп’ютерних систем [Текст]: конспект лекцій для студентів спеціальності 7.05010201 «Комп’ютерні системи та мережі» денної та заочної форм навчання / уклад. А.Ю. Коцюба, С.В. Лавренчук. – Луцьк: Луцький НТУ, 2016. – 48 с.





























Комп’ютерний набір та верстка:

С.В. Лавренчук













Редактор:

С.В. Лавренчук

(представник РВВ Луцького НТУ, інший фахівець)































Підпис до друку 2016р. Формат 6084/16. Папір офс.

Гарн. Таймс. Ум. друк. арк. ___ Обл.-вид. арк. 2,5

Тираж ___ прим. Зам. 1







Редакційно-видавничий відділ

Луцького національного технічного університету

43018 м. Луцьк, вул. Львівська, 75.

Друк – РВВ Луцький НТУ


Поділіться з Вашими друзьями:
1   2


База даних захищена авторським правом ©divovo.in.ua 2017
звернутися до адміністрації

войти | регистрация
    Головна сторінка


загрузить материал