Автоматизація процесу програмування це засіб автоматизації при створенні імітаційних програмних моделей що дають змогу н

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

Комп'ютерна інженерія

Докладніше: Комп'ютерна інженерія

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

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

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

Застосовувана в моделюванні мова SDL (Specification and Description Language) – це мова специфікацій та опису. Під специфікацією розуміють точне формальне визначення системи або її частини, під описом – неформальну специфікацію, яка ілюструє той або інший аспект системи. Описи використовують на початкових етапах розробки системи або для документування системи. На етапах детального проектування використовують специфікації, за якими передбачається виконання автоматичного генерування програмного коду. Той факт, що для різних етапів розробки системи пропонується одна мова, є суттєвою перевагою SDL, оскільки в такому випадку зникає проблема семантичних розривів.

Мова SDL

Мову SDL призначено для розробки подійно-орієнтованих розподілених систем. Ця мова почала розвиватись за сприяння міжнародного комітету ITU ще в 1976 році і є однією з найдавніших розробок в комп'ютерній інженерії. Існує два варіанти цієї мови – текстовий (SDL/PR) та графічний (SDL/GR), синтаксис яких здебільшого збігається. Викладення основ цієї мови можна знайти в літературі. Крім того, є російський варіант стислого викладення мов SDL і MSC (Message Sequence Chart).

Більше десяти компаній в Європі (Telelogic, Verigol та ін.) розробляють CASE-засоби (Computer-Aided Software Engineering – автоматизоване проектування і створення програм) на основі SDL. Ці продукти використовуються багатьма великими європейськими компаніями – виробниками телекомунікаційних систем. Крім мови SDL комітетом ITU запропоновано цілу низку стандартів на засоби розробки телекомунікаційних систем. Серед них мови високого рівня CHILL, MSC (графічна мова сценаріїв). У Європі щороку проходить велика кількість конференцій, на яких обговорюються різні аспекти цих стандартів.

Мова SDL як засіб аналізу систем широко використовується в європейських телекомунікаційних стандартах. її основними складовими є структурна модель і розширений скінченний автомат. Вони орієнтовані на здійснення специфікації подійно-орієнтованих систем, хоча мають ширше використання. Блочний аналіз є основою структурної декомпозиції системи за допомогою мови SDL. Він передбачає зображення системи у вигляді вкладених одна в одну частин (блоків), які не містять виконуваного коду, а містять лише описи. Блоки можуть відповідати великим модулям системи або підзавданням проекту. Виконуваний код у вигляді розширеного скінченного автомату міститься лише в листках дерева цієї декомпозиції, тобто процесах, які, подібно до блоків, можна поставити у відповідність об'єктам. Тому мову SDL було успішно розширено до об'єктно-орієнтованої мови.

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

Метод OOSE

Об'єктно-орієнтований програмний інжиніринг – OOSE (Object-Oriented Software Engineering) має основне завдання – наблизити комп'ютерну інженерію до типового промислового процесу, яким є, наприклад, будівництво. Основний принцип підходу – об'єктна орієнтованість, як аналізу, проектування, програмування, так і опису процесу розробки програмного забезпечення загалом.

Підхід призначено, у першу чергу, для розроблення великих систем. На основі OOSE створено метод Objectory, реалізований у продукті компанії Objectory AB. У 1995 році, після злиття цієї компанії з корпорацією Rational Software Corp., цей метод використовувався під час створення раціонального об'єднаного підходу – RUP (Rational Unified Approach). В OOSE пропонується компактний опис структури комп'ютерної інженерії, основою якої є поняття архітектури. Це поняття включає основні концепції і технології, визначені як об'єктно-орієнтовані, певний набір напівформальних моделей з графічними нотаціями, які надаються для опису розроблюваної системи.

Метод OOSE – лінійна послідовність кроків, тобто процедура для створення ідеальної системи «з нуля». За допомогою цього методу можна визначити, як застосовувати архітектуру для розроблення системи. Процес розробки є розширенням методу. На відміну від методу він, по-перше, орієнтований на ітеративне розроблення програмного забезпечення (сам метод лінійний) і по-друге – адаптований до практичного застосування (метод – це ідеальна послідовність кроків).І нарешті, інструментальні засоби – це реалізація архітектури, методу та процесу в конкретному програмному продукті – CASE-засобі, за допомогою якого відбувається розроблення системи. Аналіз і проектування в OOSE засновані на методі випадків використання (use case approach), за допомогою яких, через побудовані для них сценарії, виділяються об'єкти. Пропонується кілька об'єктних моделей для різних стадій розробки системи і, як у SDL, блочний аналіз.

Метод Буча

Праця Буча є класичною монографією, де висвітлюється об'єктно-орієнтований підхід до аналізу та проектування програмного забезпечення. За допомогою методу описуються об'єктна модель і візуальні засоби, а також сам процес розробки програмного забезпечення з визначенням цілей, видів діяльності та передбачуваних результатів. Крім того, розглядаються організаційні питання створення програмного забезпечення та вплив на них застосування об'єктно-орієнтованого підходу. Метод засновано на єдиній моделі класів. її пропонується використовувати на різних етапах розробки отримання єдиної специфікації системи, яка змінюється від однієї фази розробки до іншої. Як основні поняття у праці використовуються методологія і метод.

«Методологія – це набір методів, які застосовуються протягом всього життєвого циклу створення програмного забезпечення, поєднаних єдиною філософською концепцією». Такою концепцією в Буча є об'єктно-орієнтований погляд на світ. «Метод – це чітко визначений процес створення набору моделей за допомогою специфікованих нотацій; ці моделі описують різні аспекти програмного забезпечення». Буч називає свій підхід методом і ділить його на три частини – нотації, процес, прагматика.

Основа методу – можливість розглядати розроблювану систему з різних поглядів. Результат такого розгляду називається моделлю системи. Буч вирізняє такі типи моделей: логічну, фізичну, статичну та динамічну. Під моделлю розуміється як спосіб бачення, так і його результати. У першому випадку використовується також термін view, у перекладі з англійської – вид. Нотація – це графічна мова для опису моделей. Ця частина методу є формальною. Процес – це опис цілей, видів діяльності та результатів для різних фаз об'єктно-орієнтованого аналізу та проектування. Процес не формалізується як набір процедур, а поділяється на частини, для яких описуються інтерфейсні характеристики. Буч підкреслює, що його опис процесу не є набором готових рецептів.

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

У класичних працях, присвячених проблемі створення великих програмних систем на основі об'єктно-орієнтованого підходу, автори намагалися охопити всі боки життєвого циклу розробки програмного забезпечення, не залишаючи без уваги жодного організаційного питання. Але найбільше практичне втілення мали ті частини цих праць, в яких йдеться про візуальне моделювання як один з основних засобів аналізу та проектування великих програмних систем. Було створено велику кількість спеціалізованих програмних продуктів під загальною назвою CASE- засоби, які реалізують графічні нотації різних об'єктно-орієнтованих методологій. Нарешті, хаосу в цій галузі позбулися завдяки прийняттю стандарту щодо об'єктно-орієнтованих засобів візуальної специфікації – мови UML (Unified Modeling Language). Якщо слідувати структурі методу Буча, то можна сказати, що стандартизовано лише нотацію, а процес і прагматика в UML не увійшли, тобто було стандартизовано мову, а не способи її застосування.

Мова UML

Мова UML розвивається з 1994 року і є результатом злиття трьох найбільш відомих об'єктно-орієнтованих підходів: методу Буча, ОМТ і OOSE. У 1997 році мову UML було прийнято комітетом OMG як стандарт. Вона практично замінила собою всі інші об'єктно-орієнтовані підходи. Мова UML є грандіозною спробою розробити на основі об'єктно-орієнтованого підходу універсальну мову графічного моделювання для аналізу і проектування складних комп'ютерних систем. Вона об'єднує велику кількість різних графічних нотацій з метою впорядкування хаотичного набору графічних засобів, які використовуються під час створення програмного забезпечення. Стандартизація тут суттєво підвищує рівень розуміння між різними фахівцями, які розроблюють складну систему. Крім того, стандарт полегшує процес перенесення специфікацій, виконаних у різних CASE-пакетах. В основному документі щодо мови UML описано версію UML 1.1 1997 року. Ця праця ґрунтується на настанові з UML.

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

Підсистема аналогічна блоку SDL, але загалом система понять UML є більш загальною, ніж у SDL.

Методологія ROOM

Методологія ROOM (Real-Time Object-Oriented Modeling) – це об'єктно-орієнтована розробка систем реального часу. її розвиток пов'язаний з канадською компанією Object Time Limited, яка на основі цієї методології випустила програмний продукт ObjectTime. Методологію було розроблено в 1992 році. У 1994 році вийшла монографія, яка містить повний опис ROOM. Модель поведінки ROOM розглянуто в інших працях. Крім того, продовжує видаватись велика кількість статей, в яких описано різні аспекти використання цієї технології та подальший розвиток. Заслуговують на увагу праці, в яких описано, як ROOM «вкладається» в UML за допомогою механізму розширень UML. Матеріал, викладений у цих працях є базисом для створення мостів між програмними продуктами, які реалізують ROOM і UML.

У методології ROOM передбачено два рівні подання розроблюваної системи: рівень схем; рівень деталізації.

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

Мова UML є лише мовою моделювання і способи застосування винесені з її специфікації. Корпорацією IBM Rational Corp. створено надбудову над UML під назвою RUP (Rational Unified Process), яка дає змогу систематизувати процес створення програмного забезпечення на основі UML, пропонуючи використовувати певний набір програмних продуктів (головним чином, компанії Rational Corp.).

Метод RUP

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

Метод RUP передбачає інтерактивність усередині однієї фази. Як звичайно, результатом ітерації є прототип системи. Наводяться такі варіанти кількості ітерацій за фазами: [0,1,1,1], [1,2,2,1], [1,3,3,2]. Таким чином, формулюється загальне правило про кількість ітерацій усередині одного циклу: 6 ± 3.

Поняття фази є вдалою абстракцією для виділення етапів розробки системи. Це поняття узгоджує ітеративний процес розробки програмного забезпечення та лінійний порядок звітності.

Розроблення системи виконується в чотири фази за допомогою робочих процесів (workflow), які є послідовністю дій, пов'язаних загальною специфікою. Робочі процеси розподіляються за різними фазами і можуть протікати паралельно. Метод RUP передбачає виконання таких робочих процесів.

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

Фази метода RUP

1. Початок – фаза визначення меж проекту, оцінювання реальності його виконання (терміни, плани, кошти, люди, ризики).

2. Деталізація – фаза створення архітектурного прототипу системи, визначення вимоги до проекту, його вартості і терміну виконання, складання детального плану роботи.

3. Конструювання – фаза реалізації проекту.

4. Передавання – фаза передавання системи замовнику.

Робочі процеси Метода RUP

1. Бізнес-моделювання (Business Modeling).

2. Висування вимог (Requirements).

3. Аналіз і проектування (Analysis and Design).

4. Реалізація (Implementation).

5. Тестування (Testing).

6. Впровадження системи (Deployment).

Крім того вирізняють такі допоміжні процеси.

керування проектом (Project Management);

створення конфігурації змін та керування ними (Configuration and Change Management);

створення конфігурації середовища (Environment).

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

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

Програмні генератори імітаційних моделей

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

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

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

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

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

Для створення методики автоматизованого синтезу програмних реалізацій імітаційних моделей певного класу потрібно побудувати формалізовану модель системи чи процесу у вигляді теоретико-множинного опису. Широкий клас структур концептуальних і імітаційних моделей можна зобразити як орієнтовані графи у вигляді:

$G=(V,P,U)$ ,

де V – кінцева множина вершин; Р – кінцева множина дуг; U – функція, яка ставить у відповідність кожному ребру із множини Р упорядковану пару вершин із множини V.

Для програмного генератора, що розробляється, вершинам графа відповідає кінцева множина можливих атомарних підмоделей A1 об'єктів класів К. Характеристика класу К визначається сукупністю атрибутів b, які задають на полі класу

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

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

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

Див. також

Посилання

Програмування українською [ 10 листопада 2018 у Wayback Machine.]
Форум з програмування [ 21 травня 2012 у Wayback Machine.]

Література

Зубенко В. В. Програмування: навчальний посібник (гриф МОН України) / В. В. Зубенко, Л. Л. Омельчук. — К. : ВПЦ «Київський університет», 2011. — 623 c.
Нікітченко М. С. Теоретичні основи програмування: навчальний посібник / М.С Нікітченко — Ніжин: Видавництво НДУ імені Миколи Гоголя, 2010. — 121с.
Огірко І.В., Огірко О.І. Інформаційні технології і системи в умовах інклюзії. «Відкритий міжнародний університет розвитку людини «Україна». IV МІЖНАРОДНОЇ НАУКОВО-ПРАКТИЧНОЇ КОНФЕРЕНЦІЇ «ІНКЛЮЗИВНА ОСВІТА: ДОСВІД І ПЕРСПЕКТИВИ». м. Вінниця, 23 листопада 2017 року.c.24-30.
Огірко І.В., Огірко О.І. ІНФОРМАЦІЙНІ ТЕХНОЛОГІЇ ХМАРНИХ ОБЧИСЛЕНЬ. Матеріали конференції. «Інформаційні технології в освітньому процесі 2017». Чернігівський Державний педагогічний університет імені Т.Г. Шевченка: https://kafedraikt.blogspot.com/p/2016.html [ 13 жовтня 2018 у Wayback Machine.] . https://drive.google.com/file/d/1pT4tFqIkCMTHKq8q2fZSUYHUxV3CUeT0/view [ 20 вересня 2021 у Wayback Machine.]. 11-17 грудня 2017 року.c.61-72.