Автоматизація процесу програмування — це засіб автоматизації при створенні імітаційних програмних моделей, що дають змогу не тільки вилучити проміжну ланку між аналітиком і людиною, що приймає рішення, а й під час створення моделі використовувати терміни предметної галузі, в якій працює аналітик.
Комп'ютерна інженерія
Створення імітаційних моделей – складне завдання. Недарма у своїй праці Шенон ставить програмістів, які створюють програмні реалізації імітаційних моделей, вище, ніж системних програмістів. Так було названо нову наукову дисципліну, об'єктом дослідження якої є великі комп'ютерні системи і проблеми, що виникають під час їх створення.
У наш час продовжують розвиватись різні методи розробки складного програмного забезпечення. У рамках комп'ютерної інженерії робиться спроба визначити абстрактну систему понять цього процесу. Кожний новий підхід передбачає свою систему, яка схожа на інші, але має деякі нюанси.
У цьому розділі розглядаються відомі об'єктно-орієнтовані методи автоматизації створення програмних систем і розкриваються поняття, які використовуються під час розроблення засобів автоматизації проектування імітаційних моделей.
Застосовувана в моделюванні мова 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, C++ та ін. Отже, виникає проблема співіснування 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