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

РОЗДІЛ 3. Еволюція стратегічних моделей управління в сучасних інформаційних системах

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

Під проектуванням ІСрозуміють процес послідовної формалізації та деталізації проектних рішень на різноманітних стадіях ЖЦ ІС.

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

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

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

Технологія проектування ІС− це сукупність методології і засобів проектування ІС, а також методів й способів організації проектування (керування процесом створення і модернізації проекту ІС).

Технологія проектування ІС має задовольняти таким вимогам:

· забезпечувати відповідність створеного проекту ІС вимогам замовника;

· максимально відбивати всі етапи ЖЦ проекту;

· мінімізувати трудові та вартісні витрати на проектування і супроводження проекту;

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

· сприяти зростанню продуктивності праці проектувальника;

· забезпечувати надійність процесу проектування та експлуатації проекту;

· сприяти простому веденню проектної документації.

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

За ступенем автоматизації методи проектування поділяються на:

· комп'ютерного проектування,що забезпечує генерацію або конфігурацію (настроювання) проектних рішень на основі використання спеціальних інструментальних програмних засобів;

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

За ступенем використання ТПР розрізняють такі методи проектування:

· оригінального (індивідуального) проектування,коли проектні рішення розробляються “з нуля” відповідно до вимог до ІС;

· типового проектування,що передбачає конфігурацію ІС із готових ТПР (програмних модулів).

За ступенем адаптивності проектних рішень методи проектування поділяються на:

· параметризації,коли проектні рішення настроюються відповідно до змінюваних параметрів;

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

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

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

Виділяють дві основні групи нотацій в галузі проектування: структурні описи (статичні); поведінкові описи (динамічні представлення).

А також ряд основних груп методів проектування: функціонально-орієнтоване (структурне); проектування на основі структур даних; об’єктне проектування; компонентне проектування та ін.

Таким чином, з точки зору використовуваних стандартів графічного моделювання та методів проектування, можна виділити три основі групи методологій проектування ІС:

1) структурного проектування і моделювання (в основу яких покладено побудова графічних моделей функцій і процесів, що відбуваються в ІС);

2) об’єктного проектування і моделювання (в основі яких – виділення певних сутностей-об’єктів майбутньої системи). Окремим підвидом в цій групі будуть методології компонентного проектування;

3) компонентного проектування.

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

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

SADT (Structured Analysіs and Desіgn Technіgue) та методології, розроблені на його основі, наприклад IDEF0, які використовують функціональні діаграми;

Група методологій структурного аналізування і проектування SA/SD, в основу яких покладено використання діаграм потоків даних (DFD):

· IE (Information Engineering) – інформаційного моделювання Мартіна та ін.;

· SA (Structured Analysis) – структурного аналізу Де Марко;

· SA/RT (Structured Analysis with Real-time-Extensions) – структурного аналізу з розширенням для систем реального часу Хартлі, аналог SDRTS та ін.;

· SA/SD – структурного системного аналізування і проектування Йордана;

· SD (Structured Design) – структурного проектування Стівенса, Майера, Константайна;

· SDRTS (Structured Design of Real Time Systems) – структурного проектування систем реального часу Уорда-Меллора, розширення SA/SD;

· SRD (Structured Requirements Definition), розроблена Ken Orr в середині 70-х років минулого століття;

· SSA (Structured Systems Analysis) - структурного системного аналізу Гейна-Сарсона;

· SSADM (Structured Systems Analysis and Design Method), створена на початку 80-х років XX ст. і прийнята в 1993 р. як національний стандарт Великобританії, та ін.

Різні методології тією чи іншою мірою описують різні структурні аспекти ІС за допомогою різних типів діаграм. Так, в межах однієї методології можуть використовуватися і діаграми потоків даних (DFD) – для відображення функціонування системи, сумісно із словниками даних і специфікаціями процесів; і діаграми сутність-зв’язок (ERD) – для відображення даних; і навіть діаграми переходів станів (STD) – для відображення поведінки системи в часі.

Так, Software Engіneerіng (SE) передбачає низхідний поетапний підхід до розробки програмних систем, в результаті якого здійснюється поетапна декомпозиція функцій системи до рівня, достатнього для кодування. Такий підхід може використовуватися як при розробці систем реального часу, так і при розробці ІС. Іnformatіon Engіneerіng (ІE) є дисципліною побудови систем взагалі, а не лише розробки програмних систем, і включає етапи більш високого рівня (наприклад, стратегічне планування), однак на етапі проектування програмних систем ці дисципліни аналогічні; використовується лише для побудови ІС.

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

Сучасні інструментальні засоби можуть підтримувати відразу декілька методологій за рахунок реалізації різноманітних діаграмних технік:

· AllFusion Process modeler 7 (Bpwin 4) – підтримує IDEF0, IDEF3 та DFD-нотації;

· Aonix – підтримує методи як SA/SD, так і SA-RT;

· System Architect – підтримує методи Гейна-Сарсона, Йордона-Де-Марко, Йорда-Меллора, SSADM;

· WinA&D 5.1 – дозволяє зображувати DFD, ERD та інші моделі.

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

Взагалі, можна дійти висновку, що усі методології структурного проектуваня ІС передбачають низхідний підхід, при якому:

· здійснюється поетапне розбиття системи на функціональні підсистеми (функції-підфункції-задачі, аж до рівня процедур);

· формується ієрархічна структура функцій системи з обмеженим числом елементів на одному рівні (3 – 7);

· функції системи можуть ув’язуватися з даними і з об’єктами, що їх виконують.

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

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

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

Як результат, складові задачі організуються в ієрархічні деревоподібні структури.

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

IDEF0 – стандарт, що регламентує процес графічного моделювання бізнес-процесів. Основними операндами графічного моделювання є прямокутники, що відображають роботи (Activity), тобто бізнес-процеси, що підлягають моделюванню, і стрілки (Arrow), які мають різне значення залежно від їх початку і входу в прямокутник. Для опису робіт виділяються 4 типи стрілок:

1) “Mechanism” – “Механізм”, що виходить з нижньої грані зони побудови діаграми і входить в нижню грань прямокутника, який відображає роботу/процес, дає інформацію про те, ким або чим виконується конкретна робота/процес;

2) “Input” – “Вхід”, що виходить з лівої грані зони побудови діаграми і входить в ліву грань прямокутника, який відображає роботу/процес, визначає, що є входом роботи, тобто що обробляється і видозмінюється в процесі її виконання;

3) “Control” – “Управління”, що виходить з верхньої грані зони побудови діаграми і входить у верхню грань прямокутника, який відображає роботу/процес, визначає мотивацію або координацію процесу виконання роботи/процесу, тобто визначає, що є обмежуючими або стимулюючими її параметрами;

4) “Output” – “Вихід”, що виходить з правої грані прямокутника, який відображає роботу/процес, і входить в праву грань зони побудови діаграми, визначає результат здійснення роботи/процесу, тобто ціль її виконання.

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

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

Наприклад, змоделюємо бізнес-процес “Експлуатація інформаційної системи” за вимогами стандарту (IDEF0) (рис. 3.1).

Рис. 3.1. Опис бізнес-процесу за допомогою стрілок

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

Для опису робіт є чотири типи стрілок, їх виходи і входи жорстко регламентовані стандартом IDEF0, неможливо провести стрілку входу (Input) з лівої грані зони побудови діаграми в нижню грань прямокутника роботи і т.д.

Кожна стрілка на діаграмі несе в собі певну інформацію (вхідні дані роботи, її стимули/обмеження, хто/що її виконує та її результат) і повинна мати конкретне ім’я; крім того, кожну стрілку можна доповнити текстовим описом, так само, як і роботи. Опис стрілки можна виконати з допомогою діалогового “вікна” властивостей стрілки “Arrow Properties”.

Діаграма декомпозиції – це розбиття головного (батьківського) бізнес-процесу на складові підпроцеси/роботи. (IDEF0, DFD, IDEF3) та запис кількості робіт, які міститиме діаграма декомпозиції. Варто зазначити, що мінімальна кількість робіт, на які розбивається бізнес-процес, – 3, оскільки вважається недоцільним розписувати процес, що складається лише з двох робіт, а максимальна – 8, тому що навіть при 8 роботах переплетіння стрілок утворює нечитабельну сітку.

Кожну роботу необхідно пойменувати, описати за допомогою стрілок і доповнити текстовим описом. На діаграмі декомпозиції стрілки доцільно розгалужувати, а не створювати нові (маються на увазі стрілки, що виходять або входять в грані зони побудови). Якщо ж нова стрілка необхідна, то обов’язково потрібно провести її тунелювання, щоб уникнути порушень вимог стандарту IDEF0.

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

Так само, як і кожну роботу, кожну стрілку необхідно доповнити текстовим описом. В результаті отримуємо повноцінну діаграму декомпозиції (рис. 3.2).

Рис. 3.2. Готова діаграма декомпозиції 1-го рівня

Діаграми потоків даних (Data Flow Diagramming, DFD) використовуються для опису документообігу й обробки інформації. Так само, як і IDEF0, DFD, – це стандарт графічного моделювання бізнес-процесів (тобто дій), але його призначення відрізняється від призначення IDEF0. Відповідно він оперує іншими графічними об’єктами:

· основні процеси (Activity) обробки інформації та створення документів (бізнес-процеси) зображують прямокутником з закругленими кутами;

· стрілки (Arrow) відображують документи у русі, тобто їх переміщення від джерела до процесу обробки і від процесу до місця зберігання;

· зовнішні посилання (External references) зображуються у вигляді прямокутників з жирними лівою і верхньою гранями, служать для відображення джерела або “клієнта” документів/інформації;

· сховища даних (Data store) зображуються як прямокутники з подвійною лівою гранню і без правої грані; служать для відображення місця зберігання інформації/документів (тобто інформація в спокої).

На відміну від IDEF0, в DFD грані зони побудови діаграми не несуть інформативного навантаження, а тому стрілки не можуть ні виходити, ні входити в них – це порушує логіку стандарту DFD.

Кожній роботі потрібно присвоїти ім’я та доповнити текстовим описом, що здійснюється так само як аналогічний опис робіт в стандарті IDEF0 за допомогою діалогового “вікна” властивостей робіт Activity Properties або словника робіт Activity Dictionary.

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

Після закінчення опису процесу DFD-діаграма наведена на рис. 3.3.

Рис. 3.3. DFD-діаграма декомпозиції бізнес-процесу “Діяльність відділу прикладного програмного забезпечення”

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

· одиниці робіт (Activity/Unit of work, UOW) зображують прямокутником, розділеним на три частини;

· зв’язки (Arrow) показують взаємовідносини робіт;

· об’єкт посилання (Referent) зображується у вигляді прямокутників, розділених на дві частини, і служить для відображення ідей, концепцій чи даних, які не можна зв’язати за стрілкою або роботою;

· перехрестя (Junction) мають різне зображення залежно від їх значення, служать для відображення логіки взаємодії стрілок при їх злитті чи розчепленні або для відображення безлічі подій, які можуть або повинні бути завершені перед початком наступної роботи. Після закінчення опису процесу IDEF3-діаграма матиме вигляд зображений на рис. 3.4.

Рис. 3.4. IDEF3-діаграма декомпозиції бізнес-процесу “Діяльність відділу системного адміністрування”

Функціонально-вартісний аналіз (Activity Based Costing – ABC) являє собою сукупний облік витрат, пов’язаних з виконанням робіт, з метою визначення загальної вартості процесу. Функціонально-вартісний аналіз базується на моделі робіт, тому що кількісна оцінка неможлива без детального розуміння функціональності підприємства. Зазвичай АВС застосовують з метою зрозуміти походження вихідних витрат і полегшити вибір необхідної моделі робіт при реорганізації діяльності підприємства.

АВС може проводитися тільки тоді, коли модель бізнес процессу-послідовна (відповідає синтаксичним правилам IDEF0), коректна (охоплює всю розглядувану область) і стабільна (не підлягає змінам); іншими словами, коли створення моделі бізнес-процесу завершено.

АВС включає наступні основні поняття:

· об’єкт витрат – причина, через яку робота виконується, простіше – результат роботи;

· рушії витрат – характеристики входів і управлінь роботи, які впливають на те, як виконується робота та на тривалість її виконання;

· центри витрат, які можна трактувати як статті витрат.

При виконанні вартісного аналізу в BPwin спочатку задаються одиниці виміру часу і грошей. Потім описуються центри витрат (cost centers). Для внесення центрів витрат необхідно викликати діалогове вікно Cost Center Dictionary – головне “меню” “Dictionary”ð“ Cost Center...” (рис. 3.5).

Рис. 3.5. Діалогове вікно “Cost Center Dictionary”

Кожному центру витрат варто дати детальний опис у вікні “Definition”.

Для задання вартості роботи (для кожної недекомпонованої роботи) необхідно клацнути правою клавішею миші по роботі та в контекстному “меню” вибрати Cost. В закладці “Cost” діалогового вікна “Activity Properties” вказується частота проведення даної роботи в межах батьківської роботи (кількість раз, яку робота виконує в межах проведення батьківської роботи) – вікно Frequency і тривалість виконання роботи – вікно Duration. Потім варто вибрати зі списку один із центрів витрат і у вікні з назвою валюти, в якій проводиться аналіз (Гривна), задати його вартість для даної роботи. Аналогічно визначаються суми по кожному центру витрат, тобто задається вартість кожної роботи по кожній статті витрат. Якщо в процесі присвоєння вартості виникає необхідність внесення додаткових центрів витрат, діалогове вікно Cost Center Editor викликається прямо з діалогового вікна “Activity Properties”; закладка “Cost” – відповідною кнопкою Cost Center Editor…

Результати функціонально-вартісного аналізу наочно подаються в спеціальному звіті. Порядок виводу інформації визначається порядком встановлення “галочок” на відповідних пунктах звіту, що формується.

Діаграма “дерева” вузлів показує ієрархію робіт в моделі та дозволяє розглянути всю модель в цілому, але не показує взаємозв’язки між роботами (стрілки, перехрестя, посилання) (рис. 3.6).

Рис. 3.6. “Дерево” вузлів

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

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

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

Також у різних методологіях структурного проектування можна спостерігати, як поступово додаються нові описові “виміри” ІС. Так, SADT чітко регламентувала опис системи з точки зору її функцій та використовуваних для них даних і лише вказувала на можливість використання інших описів. SA/SD вже додатково передбачає ідентифікацію об’єктів, що надають необхідну для системи інформацію; деталізацію опису процесів та окремі діаграми для опису логіки взаємодії програмних модулів.

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

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

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

Різними авторами було створено цілий ряд об’єктно-орієнтованих методів візуального моделювання і проектування ІС. Однак ні один з цих методів не отримав загального визнання, допоки Буч, Рэмбо і Якобсон не поставили перед собою задачу створення уніфікованої мови моделювання (Unіfіed Modelіng Language – UML).

Основними при розробці UML були наступні цілі:

· надати користувачам готову до використання виразну мову візуального моделювання, що дозволяє їм розробляти осмислені моделі й обмінюватися ними;

· передбачити механізми розширюваності і спеціалізації для розширення базових концепцій;

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

· забезпечити формальну основу для розуміння цієї мови моделювання;

· стимулювати зростання ринку об’єктно-орієнтованих інструментальних засобів;

· передбачити підтримку таких високорівневих концепцій розробки, як співробітництво, середовища, зразки, компоненти;

· інтегрувати кращий практичний досвід.

Значимість розробки уніфікованої мови моделювання відмітили деякі компанії-розробники ПЗ, які взяли активну участь у розробці версії 1.0 мови UML. В теперішній час стандартом є мова UML 2.0. і на ринку ПЗ CASE-засобів представлений програмний продукт, що підтримує цю версію мови: Rational Rose, Paradigm Plus, Select Enterprise, Microsoft Visual Modeler for Visual Basic та ін.

В специфікаціях UML визначаються нотація та метамодель. Нотація – сукупність графічних елементів, використовуваних в моделях; метамодель – діаграма (зазвичай діаграма класів), яка визначає нотацію та дозволяє визначити, що таке синтаксично правильна модель (рис. 3.7).

Рис. 3.7. Структура мови UML

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

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

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

Проблема того, що основним застосуванням UML на теперішній час все ще залишається наочне відображення моделі проектованої системи для обговорення і спілкування розробників між собою та із замовником, вочевидь, полягає, у першу чергу, в тому, що не деталізовані специфікації, з допомогою яких здійснювався б перехід від проектних моделей до реалізацій систем. В результаті розробники інструментальних засобів на власний розсуд реалізують ці можливості. Так, ІBM Ratіonal Rose, орієнтований на інтеграцію з іншими ПЗ для забезпечення всього ЖЦ створення ІС, декларуючи підтримку UML різних версій дозволяє будувати діаграми всіх типів. Однак далі на основі цих діаграм може бути здійснена максимум-генерація класів. Всі описи не дають результатів на етапі розробки (генерації програмних кодів) – стани та дії над об’єктами, за допомогою яких можна описувати алгоритми, описуються впусту, навіть в такому засобі, як Gentleware Poseіdon for UML, можливості роботи з кодом явно ширші – передбачається редагування коду для методів діаграм класів і навіть (у варіанті Embedded Edition 5.0) генерація коду програм на C++, ANSI C та Java за діаграмами станів.

Популярність легендарного Telelogіc TAU (зараз Rational TAU) також була пов’язана, у першу чергу, із можливостями генерації кодів програм за діаграмами станів.

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

Окрім UML, серед графічних мов, на основі яких здійснюється об’єктне проектування ІС знашла поширення, хоч і значно менше, ніж UML, мова SDL (Specification and Description Language).

SDL є об’єктно-орієнтованою формальною мовою, розробленою Міжнародним телекомунікаційним союзом (ITU-T) як рекомендації Z.100. Можливості мови передбачають опис структури, поведінки та даних системи. На відміну від UML SDL, є формальною мовою, оскільки передбачає точну визначеність символів та понять. Типовими сферами використання стандарту є телекомунікаційні, аерокосмічні та інші складні розподілені системи, тобто ті системи, де моделювання функціональності не менш важливе, ніж моделювання об’єктів.

UML призначена для використання на стадії аналізування вимог до ІС та їх опису. Отримані в результаті класи можуть бути використані в діаграмах SDL (так само, як і дані, описані в ASN.1 та IDL). Зі специфікації системи на SDL можуть бути згенеровані тестові модулі в TTCN або ж коди системи.

Одна з найважливіших переваг SDL у порівнянні з UML полягає в тому, що SDL може виконувати ієрархічну декомпозицію внутрішньої структури системи. Таким чином, можливе моделювання структур довільної складності та опис динаміки системи в цілому. Реалізована мова в IBM Rational / Telelogic SDL, SDL Trados Studio 2009, Cinderella SDL та ін.

Як зазначалося, мови описів і специфікацій SDL-2000 і MSC істотно підвищують рівень автоматизації процесів проектування алгоритмів апаратно-програмних систем. Однак вони не забезпечують коректної специфікації вимог до систем. Серед недоліків відзначаються:

· відсутність регламентації взаємодії блоків та підблоків у SDL (напрямки зв’язків та часовий порядок) – опису властивостей;

· складність операційної семантики;

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

· відсутність підтримки програмними засобами проектування специфікацій у повному обсязі.

У зв’язку з тим ведуться дослідження щодо розвитку SDL – зокрема, можна назвати роботи зі створення мови SDL/PLUS, системи програмування алгоритмів та моделей (СПАМ) та поведінкової моделі Real, що об’єднує STD та SDL-нотації.

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

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

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

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

Серед відомих методологій об’єктно-орієнтованого проектування можна назвати: RUP (підтримується засобами Rational Software), MSF (Microsoft), Oracle PJM (Oracle) та ін.

Однією із найвідоміших методологій об’єктного проектування на теперішній час є RUP (Rational Unified Process – раціональний уніфікований процес), розроблена Якобсоном, Бучем і Рембо у 1999 р. Дана методологія передбачає чітко визначений процес, що охоплює весь ЖЦ проекту; ролі та відповідальність окремих виконавців; виконувані ними задачі, використовувані в процесі розробки моделі, звіти та ін.

Виділяється динамічна та статична структура RUP.

Динамічна структура RUP складається з чотирьох фаз, які можуть поділятися на ітерації:

1) дослідження– Inception (визначення границь системи, моделювання бізнес-процесів та робота з вимогами, видалення економічних ризиків) – результат – перший прототип системи;

2) уточнення плану – Elaboration (опрацювання вимог і вибір основних проектних рішень) – концептуальний прототип перетворюється в реальну систему, яку можна протестувати та оцінити обрані архітектурні рішення;

3) побудова – Construction (швидка і економічна розробка коду системи) – система готова до передачі замовнику для бета-тестування і приймально-здавальних випробувань;

4) розгортання – Transition (підготовка розробленого продукту до передачі замовнику або тиражування і розповсюдження).

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

Статична структура RUP складається з дисциплін, які розбиваються на процеси, задачі, артефакти, ролі.

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

Практично RUP – не набір жорстких правил, а рекомендації з використання кращих практичних методів розробки ПЗ, таких як:

· Ітеративна розробка.

· Керування вимогами.

· Використання модульних архітектур.

· Візуальне моделювання.

· Перевірка якості.

· Відстеження змін.

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

Моделювання здійснюється за допомогою Software Process Engineering Metamodel (SPEM) – стандарта моделювання процесів, основаного на Unified Modeling Language (UML).

Для забезпечення інструментальної підтримки всіх процесів ЖЦ RUP рекомендує використання спеціалізованих інструментальних засобів IBM Rational.

Для підтримки моделювання на основі методології RUP в Rational Rose Enterprise використовується Model Framework, що забезпечує:

· визначення мінімальної кількості діаграм для реалізації проекту;

· забезпечує основу для генерації звітів;

· загальну структуру моделі;

· зв’язок дій в RUP з діаграмами;

· керування стилями.

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

Таблиця 3.1