Використання елементів uml в rup
Представлення |
Елементи |
Варанти |
Актори Варіанти використання Асоціації Діаграми варіантів використання Діаграми послідовності Діаграми кооперацій Пакети |
Продовж. табл. 3.1
Логічне |
Класи Діаграми класів Асоціації Діаграми дій Діаграми станів Пакети |
Компонентів |
Компоненти Діаграми компонентів Пакети |
Розміщення |
Процеси Процесори Пристрої Діаграми розміщення |
Таким чином, можливості моделювання ІС в RUP повністю визначаються можливостями UML.
Однак більшість сучасних методологій проектування носять “процесний” характер і не орієнтовані на використання якоїсь визначеної мови моделювання. Це стосується, в першу чергу, гнучких (Agile) методологій – SCRUM, eXtreme Programming (XP), Crystal, Adaptive Software Development (ASD), Feature Driven Development (FDD), Dynamic System Development Method (DSDM) та ін. Тобто в них специфікують процеси, що відбуваються при розробці, вимоги до команди розробників, але не вказуються мови і засоби моделювання, як це робиться, наприклад, в RUP. Одна і та ж методологія може використовувати різні інструменти залежно від досвіду та компетенції команди розробників.
Появу компонентного підходу до проектування розглядають як розвиток об’єктного підходу для проектування великих розподілених систем.
Компонентна розробка ПЗ (Component Based Development – CBD) – це спосіб розробки, при якому можливе повторне використання раніше створених компонентів за умови, що вони розроблялися з цією можливістю повторного використання.
До плюсів повторного використання ПЗ відноситься: підвищення надійності; зменшення проектних ризиків; ефективне використання фахівців; дотримання стандартів; прискорення розробки.
У той же час виникають проблеми підвищення вартості супроводу системи, пошуку і адаптації компонентів та ін.
Під компонентом, зазвичай, розуміють незалежний модуль програмного коду, призначений для повторного використання і розгортання.
Компоненти відрізняються також від класів об’єктно-орієнтованих мов за цілим рядом характеристик:
компонент є більшою структурною одиницею, ніж клас. Реалізація компонента часто складається з декількох тісно взаємопов'язаних класів;
компонент, зазвичай, не прив'язаний до певної мови програмування.
У той же час поняття “компонент” відмінне від традиційного поняття “програмний модуль”, оскільки компонент є самостійною атомарною для розгортування програмною одиницею, яка може поставлятися чи видалятися окремо від всієї іншої системи, тоді як програмний модуль має чітко описаний інтерфейс з оточенням.
Набір правил визначення інтерфейсів компонентів та їхніх реалізацій, а також правил, за якими компоненти працюють у системі і взаємодіють один з одним, прийнято поєднувати під назвою “компонентної моделі” (component model).
Існує декілька компонентних моделей від різних розробників, серед найбільш відомих:
COM (Component Object Model), COM+ від Mіcrosoft;
EJB (Enterprise Java-Beans) від Sun Mіcrosystems;
ССM (CORBA Component Model) від OMG.
Компонентна модель COM визначає протокол для створення і використання компонентів як усередині одного процесу, так і між різними процесами або комп'ютерами. Додатки для COM-моделі можуть створюватися засобами таких мов і середовищ розробки, як Vіsual Basіc, C++, .NET та ін., однак орієнтовані на ОС від Mіcrosoft. Тоді як JavaBeans не має властивості незалежності від мови програмування, проте підтримує різні платформи. CORBA ж відрізняється досить громіздким IDL-интерфейсом і як результат – складністю відображення однієї мови в іншу.
Застосування компонентного програмування покликане забезпечити більш просту і швидку розробку прикладного ПЗ на основі використання готових модулів-компонентів. Повторне застосування компонентів, дозволяє істотно скоротити витрати і терміни розробки ПЗ.
Найбільшою мірою орієнтованими на компонентну розробку є гнучкі методології та методології Microsoft Solutions Framework (MSF) – MSF for Agile Software Development та MSF for CMMI Process Improvement.
MSF рекомендує якнайчастіше збирати поточні версії всіх компонентів рішення для проведення тестування й аналізування. Цей підхід застосовується як до розробки програмного коду, так і до створення компонентів апаратного і ПЗ.
Модель проектної групи MSF (Microsoft Solutions Framework Team Model) описує підхід Майкрософта до організації працюючого над проектом персоналу і його діяльності в цілях максимізації успішності проекту. Дана модель визначає ролеві кластери, їх сфери компетенції і зони відповідальності, а також рекомендації членам проектної групи, що дозволяють їм успішно здійснювати свою місію по втіленню проекту в життя.
MSF і MOF пропонують перевірені роками рекомендації й методики по ефективному плануванню, розробці, впровадженню і супроводу бизнес‑рішень. Вони дозволяють максимізувати успішність і ефективність IT-проектів впродовж всього ЖЦ ІТ. У основу пропонованих концепцій покладено великий досвід, одержаний Майкрософт при здійсненні великих проектів у сфері ПЗ, досвід консультантів майкрософту, а також кращі з методик, напрацьовані світовою IT-індустрією.
Рішення бізнесу повинні створюватися з урахуванням поставлених термінів і в рамках відведеного бюджету. Цього легше добитися, застосовуючи підхід, що затвердений, перевірений. MSF пропонує перевірені методики для планування, створення і впровадження успішних рішень в IT-індустрії. Він не містить жорстких інструкцій; натомість пропонується гнучкий і масштабований підхід, здатний задовольнити потреби організації або проектної групи будь-якого розміру. Рекомендації MSF складаються із застосовних для більшості проектів принципів, моделей і дисциплін по управлінню розробниками, процесами і технологічними елементами.
MOF пропонує рекомендації, що допомагають забезпечити надійність (reliability), доступність (availability), зручність в супроводі (supportability) і керованість (manageability) IT-рішень, побудованих на базі продуктів і технологій Майкрософта. Принципи, моделі і дисципліни MOF піднімають кадрові, технологічні і технічні питання, що відносяться до управління складними (complex), розподіленими (distributed), різнорідними (heterogeneous) IT-системами.
Модель проектної групи MSF розроблялася протягом декількох років і виникла в результаті осмислення недоліків пірамідальної, ієрархічної структури традиційних проектних груп.
Відповідно до моделі MSF проектні групи будуються як невеликі багатопрофільні команди, члени яких розподіляють між собою відповідальність і доповнюють сфери компетенцій один одного. Це дозволяє чітко сфокусувати увагу на потребах проекту.
MSF включає ряд основних принципів. У цьому розділі говориться про тих з них, які мають відношення до успішної роботи команди.
Модель проектної групи MSF грунтується на твердженні про рівноправність ролей в команді. Кожен ролевий кластер представляє унікальну точку зору на проект, і в той же час ніхто не не в змозі успішно представляти всі можливі погляди, що відображають якісно різні цілі. Для дозволу цієї дилеми команда соратників (команда рівних, team of peers), що працює над проектом, повинна мати чітку форму звітності перед зацікавленими сторонами (stakeholders) при розподіленій відповідальності за досягнення загального успіху.
В рамках проектної групи кожен ролевий кластер звітує перед всією командою (як і перед всією організацією) про досягнення своєї мети. Кажучи інакше, кожен ролевий кластер звітує за свій внесок в остаточний результат. Відповідальність розподіляється серед членів команди, взаємозалежних з двох причин: по-перше, діяльність кожного з ролевих кластерів не може бути ізольована від роботи інших; по-друге, команда ефективніша, якщо кожному її члену зрозуміла повна картина того, що відбувається. Цей взаємозв'язок диктує необхідність для всіх членів команди висловлювати свою думку і вносити певний внесок в рішення питань, які лежать поза сферою їх звітності, забезпечуючи повноцінне використання всього спектру знань, компетенції й досвіду команди. Всі члени команди відповідають за успіх проекту; вони розділяють честь і славу у разі позитивного результату і повинні удосконалювати свій професійний рівень, працюючи над уроками менш вдалих проектів.
MSF відстоює необхідність вироблення єдиного бачення (shared vision) проекту, що формує цілісний підхід проектної групи до розробки IT-рішення.
Необхідно чітко розуміти цілі та завдання проекту або процесу, оскільки це основа всіх допущень про функціонування рішення в рамках організації-замовника. Це відноситься до сприйняття рішення як проектною групою, так і самим замовником. Загальне бачення чітко обкреслює зроблені припущення і забезпечує єдність мети всіх зацікавлених сторін. Це одна з основ моделі проектної групи MSF. Коли всі учасники проекту розуміють це і виробляють єдине бачення, вони набувають можливості погоджувати свої дії із загальною командною метою.
Не маючи такого бачення, члени проектної групи можуть керуватися поглядами, що суперечать один одному, на мету проекту, що значно утруднить роботу команди як єдиного цілого. І навіть у разі успіху члени команди навряд чи зможуть оцінити свій внесок, оскільки ця оцінка залежить від прийнятої точки зору.
Концепція “команди соратників” (teem of peers) означає рівноправне становлення кожної з ролей в команді. Це сприяє вільному спілкуванню, збільшує командну відповідальність і зумовлює рівну важливість кожної з шести якісних цілей. Щоб досягти успіху в рамках команди соратників (команди рівних), кожний з її членів, незалежно від ролі, повинен нести відповідальність за якість продукту, розуміти інтереси замовника і суть вирішуваного завдання бізнесу.
Хоча соратники рівні, ухвалення рішення методом консенсусу між ролями не тотожно ухваленню рішення методом консенсусу між співробітниками. Кожен ролевий кластер вимагає певної внутрішньої організаційної ієрархії для розподілу роботи і управління його ресурсами. Керівники ролевих кластерів відповідальні за організацію роботи, управління і координацію дій команди, тоді як її члени мають можливість зосередитися на своїх індивідуальних завданнях.
Малі багатопрофільні команди (small, multidisciplinary teams) мають ряд безперечних переваг. Одна з них – велика оперативність дій порівняно з крупними колективами. Тому при роботі над великими проектами краще створювати команди команд – набір малих груп, працюючих паралельно. При цьому працівники, що є експертами в певних областях або мають специфічні функції, одержують повноваження діяти в рамках своїх сфер компетенції.
Усередині проектної групи – і навіть усередині окремого ролевого кластера – існують завдання, що вимагають різних професійних навиків. Всі члени команди або ролевого кластера різні, що мають освіту, досвід і спеціалізацію, вносять свій унікальний внесок в роботу колективу і, у результаті, в створення кінцевого продукту.
Одна з цілей моделі проектної групи – зменшення витрат взаємодії. Як наслідок, команди мають менше перешкод для ефективного обміну інформацією. Крім структури організації, важливу роль в ефективності її внутрішніх і зовнішніх інформаційних потоків грає просторова близькість співробітників. Проте, хоча ідеальним вибором є зближення робочих місць, вимоги бізнесу і сучасні технологічні нововведення в комунікаціях роблять можливим створення успішних “віртуальних” команд.
Віртуальні команди – це команди, що взаємодіють і спілкуються головним чином за допомогою електронних комунікацій. Обмін інформацією в них йде через кордони країн і організацій, простір і час. Зв'язок з колегами через Internet в режимі реального часу корінним чином міняє принципи роботи і обміну інформацією. Internet стає для членів команди новим комунікаційним стандартом, і ПЗ, що робить можливою віддалену колективну роботу, відкриває шлях до подальшого підвищення продуктивності в нових умовах.
Для віртуальних команд модель проектної групи MSF є ключовою. Без належного рівня організації, об'єднуючого всі робочі ролі в єдине ціле, віддаленість працівників зажадала б ще більшої кількості дискусій, договорів і взаємозв'язків, жорсткішого планування і додаткових інструментів моніторингу проекту для забезпечення злагодженості роботи.
Життєво важлива складова віртуальної команди – це упевненість кожного її члена в можливості покластися на інших, що досягається виробленням загальної корпоративної культури, невпинною управлінською роботою і, як тільки це стає можливим, – перенесенням роботи в одне місце.
MSF заснований на постулаті про шість якісних цілей, досягнення яких визначає успішність проекту. Ці цілі обумовлюють модель проектної групи. Тоді як за успіх проекту відповідальна вся команда, кожний з її ролевих кластерів, визначуваних моделлю, асоційований з однією із згаданих шести цілей і працює над її досягненням.
Шість ролевих кластерів моделі проектної групи – це “Управління продуктом” (Менеджер продукту – product management), “Управління програмою” (Менеджер програми – program management), “Розробка” (Розробник – development), “Тестування” (Тестер – test), “Задоволення споживача” (Інструктор – user experience) і “Управління випуском” (Логистік – release management). Вони відповідальні за різні сфери компетенції (functional areas) і пов'язані з ними цілі і завдання. Іноді ролеві кластери називають просто ролями. Але у будь-якому разі суть концепції залишається тією ж – побудувати основу виробничих відносин і пов'язану з нею модель команди такими, щоб вони були пристосовуваними (масштабованими) для задоволення потреб будь-якого проекту. Одна роль (або один кластер) може бути представлена одним або декількома співробітниками, залежно від розміру проекту, його складності й професійних навиків, потрібних для реалізації всіх сфер компетенції кластера.
Модель проектної групи MSF підкреслює важливість побудови ролевих кластерів відповідно до потреб бізнесу. Угрупування зв'язаних областей компетенції, кожна з яких має свою специфіку, забезпечує хорошу збалансованість команди. Чітке визначення цілей підвищує рівень відповідальності та сприяє кращому їх сприйняттю проектною командою, що негайно позначається найкращим чином на якості випущеного продукту. Оскільки кожна з цілей однаково необхідна для успішності проекту, всі ролі знаходяться в рівноправних партнерських взаємовідношеннях з рівною значущістю при ухваленні рішень.
Використання ролевих кластерів не має на увазі і не нав'язує ніякої спеціальної структури організації або обов'язкових посад. Адміністративний склад ролей може широко варіюватися в різних організаціях і проектних групах. Найчастіше ролі розподіляються серед різних підрозділів однієї організації, але іноді частина їх відводиться співтовариству споживачів або зовнішнім відносно до організації консультантам і партнерам. Ключовим є чітке визначення працівників, відповідальних за кожен ролевий кластер, їх функцій, відповідальність й очікуваного внеску в кінцевий результат. Приведений на рис. 3.8 приклад не визначає вимог до організації груп напрямку. Наприклад, не всі групи напрямку повинні включати роль “Задоволення споживача”; вони повинні бути організовані відповідно до покладених на них завдань.
Рис. 3.8. Ролеві кластери моделі проектної групи MSF
Модель проектної групи MSF не забезпечує успіх сама по собі. Є багато інших чинників, що визначають успіх або невдачу проекту, але структура проектної групи, безумовно, вносить істотний внесок.
Навіть за наявності компетентних зацікавлених і працелюбних людей невірна структура команди здатна звести нанівець їх зусилля, замість того щоб привести їх до успіху. Погана структура команди може послужити причиною збільшення часу розробки, зниження якості, пониження морального духу, підвищення текучості кадрів і, зрештою, привести до відміни проекту.
Успішний проект завжди має хороший старт, який звичайно включає формування технічного завдання на проектування, початковий вибір створюваних моделей, організацію групи аналітиків, вибір Комітету технічного контролю і складання графіка робіт. Такий початок приводить до створення плану проекту, який координує зусилля багатьох людей і робить проект керованим.
Технічне завдання виробляється на найпершому етапі проекту (іноді технічне завдання називають концепцією проекту). У технічному завданні визначаються призначення, сфера, обмеження, очікувані результати і переваги проекту. Технічне завдання може також включати нарис плану проекту, який допомагає документувати попередні пропозиції організаторів і керівників проекту. Звичайно на цьому етапі зайняті невеликі колективи. Проте якщо проект дуже малий, він може бути ініційований одним автором.
Основні пункти роботи – які створювати моделі і в які терміни – плануються після формування технічного завдання. Це допомагає визначити найбільш важливі об'єкти, прояснити цілі проекту і розробити його детальний план. Перш ніж визначити основні пункти роботи, варто з'ясувати, що відомо з даної проблеми, яку нову інформацію треба зібрати і які джерела її доступні для проекту. Може бути навіть побудувати декілька невеликих SADT-моделей, щоб одержати ці відомості. Наприклад, часто будують модель самого проекту за допомогою SADT, щоб визначити, які моделі створюватимуться (поточні операції, майбутні операції, план перетворень, архітектура системи). План, заснований на такій інформації, швидше приведе до створення точних і корисних моделей.
Вірно вибрані основні пункти роботи служать базою правильного підбору колективу фахівців. Варто визначити число експертів, авторів, читачів і допоміжний персонал (бібліотекар, діловоди і технічні оформлювачі) для отримання необхідних результатів (уявлення про необхідний обсяг робіт дають огляди проектів в частині VI.), а також хто увійде до Комітету технічного контролю. Ці особи повинні відповідати за вирішення конфліктів (рис. 3.9).
Рис. 3.9. Групи напрямів
Design/IDEF дає також можливість створювати інформаційні моделі, які представляють як власні дані, так і зв'язки між ними в системі.
Інформація, що міститься в IDEF-моделях, експортується в будь-яку БД, а самі моделі можуть бути експортовані в Design/CPN – пакет динамічного моделювання і аналізування складних систем.
IDEF – cімейство стандартів обстеження організацій і проектування ІС.
Історично першим в 1981 р. був розроблений стандарт IDEF0 в рамках програми автоматизації промислових підприємств, позначений ICAM (Integrated Computer Aided Manufacturing). Методологія IDEF0 є наступним етапом розвитку добре відомої графічної мови опису функціональних систем SADT (Structured Analysis and Design Teqnique), яка була запропонована департаментом Військово-Повітряних Сил США. Власне сімейство стандартів IDEF успадкувало своє позначення від назви цієї програми (IDEF=ICAM DEFinition). В процесі практичної реалізації учасники програми ICAM зіткнулися з необхідністю розробки нових методів аналізування процесів взаємодії в промислових системах. При цьому, окрім вдосконаленого набору функцій для опису процесів бізнесу, однією з вимог до нового стандарту була наявність ефективної методології взаємодії в рамках “аналітик-фахівець”. Іншими словами, новий метод повинен був забезпечити групову роботу над створенням моделі, з безпосередньою участю всіх аналітиків і фахівців, зайнятих в рамках проекту.
В результаті пошуку відповідних рішень народилася методологія функціонального моделювання IDEF0. З 1981 р. стандарт IDEF0 зазнав декілька незначних зміни, в основному обмежувального характеру, і остання його редакція була випущена в грудні 1993 р. Національним Інститутом По Стандарам і Технологіях США (NIST).
Наприкінці 90-х років XX ст., коли на пострадянському ринку в належній мірі з'явилася конкуренція і рентабельність діяльності підприємств стала різко падати, керівники відчули величезні складнощі при спробах оптимізувати витрати, щоб продукція залишалася одночасно і прибуткової, і конкурентоздатної. Якраз у цей момент абсолютно чітко виявилася необхідність мати модель діяльності підприємства, яка відображала б всі механізми і принципи взаємозв'язку різних підсистем в рамках одного бізнесу.
Саме ж поняття “моделювання процесів” бізнесу прийшло в побут більшості аналітиків одночасно з появою на ринку складних програмних продуктів, призначених для комплексної автоматизації управління підприємством. Подібні системи завжди мають на увазі проведення глибокого передпроектного обстеження діяльності компанії. Результатом цього обстеження є експертний висновок, в якому окремими пунктами виносяться рекомендації по усуненню “вузьких місць” в управлінні діяльністю. На підставі цього висновку, безпосередньо перед проектом впровадження системи автоматизації, проводиться так звана “реорганізація процесів бізнесу”, іноді достатньо серйозна і хвороблива для компанії. Це і природно, колектив, складений роками, завжди складно примусити “думати по-новому”. Подібні комплексні обстеження підприємств завжди є складними і такими, що істотно відрізняються час від часу завданнями. Для вирішення подібних завдань моделювання складних систем існують добре обкатані методології і стандарти. До таких стандартів відносяться методології сімейства IDEF. З їх допомогою можна ефективно відображати і аналізувати моделі діяльності широкого спектру складних систем в різних розрізах. При цьому широта і глибина обстеження процесів в системі визначаються самим розробником, що дозволяє не перенавантажувати створювану модель зайвими даними.
В теперішній час до сімейства IDEF можна віднести наступні стандарти:
IDEF0 – Function Modeling – методологія функціонального моделювання. За допомогою наочної графічної мови IDEF0 система, що вивчається, предстає перед розробниками і аналітиками у вигляді набору взаємопов'язаних функцій (функціональних блоків – в термінах IDEF0). Як правило, моделювання засобами IDEF0 є першим етапом вивчення будь-якої системи;
IDEF1 – Information Modeling – методологія моделювання інформаційних потоків усередині системи, що дозволяє відображати і аналізувати їх структуру і взаємозв'язки;
IDEF1X (IDEF1 Extended) – Data Modeling – методологія побудови реляційних структур. IDEF1X відноситься до типу методологій “Суть-взаємозв'язок (ER – Entity-Relationship)” і, як правило, використовується для моделювання реляційних БД, що мають відношення до даної системи;
IDEF2 - Simulation Modeling – методологія динамічного моделювання розвитку систем. У зв'язку з вельми серйозними складнощами аналізування динамічних систем від цього стандарту практично відмовилися, і його розвиток припинився на самому початковому етапі. Проте в даний час присутні алгоритми та їх комп'ютерні реалізації, що дозволяють перетворювати набір статичних діаграм IDEF0 у динамічні моделі, побудовані на базі “розфарбованих мереж Петрі” (CPN – Color Petri Nets);
IDEF3 – Process Description Capture – методологія документування процесів, що відбуваються в системі, яка використовується, наприклад, при дослідженні технологічних процесів на підприємствах. З допомогою IDEF3 описуються сценарій і послідовність операцій для кожного процесу. IDEF3 має прямий взаємозв'язок з методологією IDEF0 – кожна функція (функціональний блок) може бути представлена у вигляді окремого процесу засобами IDEF3;
IDEF4 – Object-oriented Design – методологія побудови об'єктно-орієнтованих систем. Засоби IDEF4 дозволяють наочно відображати структуру об'єктів і закладені принципи їх взаємодії, тим самим дозволяючи аналізувати і оптимізувати складні об'єктно-орієнтовані системи;
IDEF5 – Ontology Description Capture – методологія онтологічного дослідження складних систем. За допомогою методології IDEF5 онтологія системи може бути описана за допомогою певного словника термінів і правил, на підставі яких можуть бути сформовані достовірні твердження про стан даної системи в деякий момент часу. На основі цих тверджень формуються висновки про подальший розвиток системи і проводиться її оптимізація;
IDEF6 - Design Rationale Capture;
IDEF7 - Information System Audit Method;
IDEF8 - User Interface Modeling;
IDEF9 - Scenario-driven Info Sys Design Spec;
IDEF10 - Implementation Architecture Modeling;
IDEF11 - Information Artifact Modeling;
IDEF12 - Organization Modeling;
IDEF13 - Three Schema Mapping Design;
IDEF14 - Network Design.
Як CASE-пакет по розробці ПЗ Design/IDEF підтримує перші стадії створення програмного продукту:
формулювання вимог і цілей проекту – визначення того, що проектована система робитиме;
розробка специфікацій – формалізований опис вимог;
створення проекту – визначення підсистем і взаємодій між ними;
документування проекту – створення БД проекту, текстуальний опис складових проекту;
аналізування проекту – перевірка проекту на повноту і несуперечність.
Результатом роботи пакета Design/IDEF є проект програмної системи, що складається з двох частин:
проекту функціональної структури системи, що містить ієрархічно зв'язані сторінки з IDEFO-діаграмами і що описує всі модулі (аж до елементарних функцій) системи, їх взаємозв'язки, вхідні і вихідні параметри;
проекту інформаційної структури системи – логічної моделі її БД, що описує всі структури і взаємозв'язки даних.
Обидва проекти перевіряються на повноту і несуперечність, супроводжуються БД проекту і документацією.
Design/IDEF працює в різних операційних середовищах: можна будувати моделі на IBM PC під MS-Windows, Macintosh або під Unix X Window System і переносити діаграми з одного операційного середовища в інше.
Основні елементи і поняття IDEF0
Графічна мова IDEF0 проста і гармонійна. В основу методології покладено чотири основних поняття.
Першим з них є поняття функціонального блоку (Activity Box). Функціональний блок графічно зображається у вигляді прямокутника і втілює собою деяку конкретну функцію в рамках даної системи. На вимоги стандарту назва кожного функціонального блоку повинна бути сформульована в дієслівному нахилі (наприклад, “проводити послуги”, а не “виробництво послуг”).
Кожна з чотирьох сторін функціонального блоку має своє певне значення (роль), при цьому:
верхня сторона має значення “Управління” (Control);
ліва сторона має значення “Вхід” (Input);
права сторона має значення “Вихід” (Output);
нижня сторона має значення “Механізм” (Mechanism).
Кожен функціональний блок в рамках єдиної даної системи повинен мати свій унікальний ідентифікаційний номер.
Обов'язкова наявність інтерфейсних дуг, що управляють, є однією з головних відмінностей стандарту IDEF0 від інших методологій класів DFD (Data Flow Diagram) і WFD (Work Flow Diagram).
Третім основним поняттям стандарту IDEF0 є декомпозиція (Decomposition). Принцип декомпозиції застосовується при розбитті складного процесу на складові його функції. При цьому рівень деталізації процесу визначається безпосередньо розробником моделі.
Декомпозиція дозволяє поступово і структуровано представляти модель системи у вигляді ієрархічної структури окремих діаграм, що робить її менш переобтяженою і легко засвоюваною.
Модель IDEF0 завжди починається з представлення системи як єдиного цілого – одного функціонального блоку з інтерфейсними дугами, що тягнуться за межі даної області. Така діаграма з одним функціональним блоком називається контекстною діаграмою і позначається ідентифікатором “А-0”.
У тексті пояснення до контекстної діаграми повинна бути вказана мета (Purpose) побудови діаграми у вигляді короткого опису і зафіксована точка зору (Viewpoint).
Визначення і формалізація мети розробки IDEF0 – моделі є украй важливим моментом. Фактично мета визначає відповідні сфери в досліджуваній системі, на яких необхідно фокусуватися в першу чергу. Наприклад, якщо ми моделюємо діяльність підприємства з метою побудови надалі на базі цієї моделі інформаційної системи, то ця модель буде істотно відрізнятися від тієї, яку б розробляли для того ж самого підприємства, але вже з метою оптимізації логістичних ланцюжків.
В середовище Visual Studio Team System інтегруються шаблони процесів залежно від того, яка процесна методологія розробки обрана для проекту, – якийсь з варіантів гнучкої (Agile) розробки, SCRUM, EUP, FDD чи CMMI. В Visual Studio Team System можуть використовуватися також візуальні конструктори с багатими можливостями для моделювання.
Так, на рівні платформ програмування компонентність підтримується досить широко. Але на рівні засобів візуального моделювання, призначених для аналізування і проектування таких систем, компонентність підтримується слабко і неповно.
При компонентній розробці деякими авторами пропонується спиратися на моделювання на основі UML. При цьому у UML компонент ототожнюється з класом або елементом фізичної структури ПЗ. Досліджено також можливості використання інших методів графічного моделювання при компонентній розробці ПЗ – зокрема, мови SDL (Specification and Description Language), моделей методології ROOM та ін.
Варто відмітити, що досить часто при проектуванні систем з використанням компонентних технологій взагалі не передбачається графічне моделювання, і розробники спираються лише на документування коду.
Так, компонентна розробка в рамках COM передбачає використання ієрархії класів MFC – узгодження префіксів імен класів, інтерфейсів при кодуванні.
Таким чином, на прикладі компонентної розробки можна константувати, як графічне моделювання може бути витіснене за рахунок представлення у доступній формі семантики взаємозв’язків між елементами системи.
Взагалі, поява компонентної розробки ПЗ висунула нові вимоги до моделювання систем, і застосування існуючих мов візуального моделювання виявилось занадто громіздким і сповільнюючим процеси.
Як структурне програмування обумовило появу структурних методів моделювання систем, об’єктно-орієнтоване програмування – появу об’єктно-орієнтованого підходу до проектування та об’єктно-орієнтованих мов візуального моделювання, так і компонентна розробка ПЗ вимагає іншого погляду на процеси моделювання систем.
Тому ряд колективів розробляють мови моделювання, орієнтовані на моделювання саме компонентних архітектур. Серед них Platform-Independent Component Modeling Language (PICML), а також Cadena, розроблена Kansas State University (KSU), та ін.
Cadena забезпечує каркас моделювання компонентів та перевірки моделей формальними методами (яка відсутня в PІCML). Проте, на відміну від PІCML, Cadena не підтримує об’єднання компонентів в пакети, генерацію описів розгортання та планування розгортання, ієрархічне моделювання компонентних збірок.
Необхідно також відмітити, що початкові ідеї компонентного підходу щодо поширення бібліотек компонентів та формування на їх основі програм не набули глобального розмаху в зв’язку з конкуренцією розробників компонентних моделей.
Розвитком компонентного підходу для веб-розробки можна вважати технологію веб-сервісів.
Ідеї, висловлені консорціумом OMG (Object Managemant Group) в концепції MDA (Model Driven Architecture – загальна архітектура модель-орієнтованої розробки ІС), були направлені на те, щоб об’єднати в рамках єдиної архітектури ті можливості автоматизації процесів побудови ІС, які існують на теперішній час.
Для підкреслення рівня даної концепції, варто зазначити, що OMG об’єднує на сьогодні більше 900 членів, включаючи основних виробників обчислювальної техніки і ПЗ (ІBM, Netscape, Hewlett-Packard, Phіlіps Telecommunіcatіons N.V., Oracle, Sun Mіcrosystems, 3Com Corporatіon, Amerіcan Aіrlіnes, Canon, Іnc., Data General, Unіsys Corporatіon та ін.) та займається розробкою, розповсюдженням і супроводженням специфікацій, орієнтованих на забезпечення витривалості, повторного використання та інтероперабельності бізнес-додатків.
Як головний постулат даної архітектури можна прийняти твердження про те, що основою сучасного методу проектування має бути деяка модель, яка дозволяла б описувати ІС та використовувалась при розробці нових версій систем чи при розробці аналогічних ІС. Практично, MDA є методом використання моделей при розробці ІС.
Основним сподіванням при розробці концепції MDA було забезпечення визначення машинопрочитуваних додатків та моделей даних, що будуть гнучкими у довготривалій перспективі при:
реалізації ІС (за рахунок нової інфраструктури реалізації, що може бути інтегрована з існуючими проектами);
інтеграції ІС (за рахунок існування при інтеграції не лише розробки, але й її проекту, може бути автоматизоване створення мостів для інтеграції даних та зв’язків з новими інфраструктурами);
експлуатації ІС (оскільки розробники матимуть доступ до специфікацій проекту – спрощуються процеси експлуатації);
тестуванні та моделюванні (оскільки моделі використовуються, для генерування коду, вони можуть бути перевірені на предмет задоволення вимог, протестовані на різних інфраструктурах та використані для моделювання поведінки системи).
Архітектура виділяє методи та інструментальні засоби, які необхідно використовувати для: визначення системи незалежно від платформи; визначення платформ; вибору конкретної платформи для системи та перетворення специфікації системи під цю платформу.
Концепцією чітко виділяється ряд моделей, їх зв’язок та використання.
Так, перша модель, названа CIM (Computation Independent Model – обчислювально незалежна модель) або доменною моделлю чи словником, не описує деталі структури системи, а містить відображення вимог до системи, ситуації, в яких система використовується, сформульовані експертами і, таким чином, дозволяє їм оперувати загальними поняттями. Для побудови такої моделі відповідно із специфікаціями можуть бути використані декілька UML-моделей двох типів: моделі з інформаційної точки зору та моделі з точки зору підприємства.
Другий тип моделі, передбачена MDA, – PIM (Platform Independent Model – платформо-незалежна модель) має описувати ІС незалежно від платформи (тобто без деталей її застосування на певній платформі) для того, щоб мати можливість використовувати цю модель із цілим рядом аналогічних платформ. Під платформами тут розуміється набір підсистем чи технологій, які забезпечують певну функціональність через інтерфейси (наприклад: CORBA, J2EE, Microsoft .NET та ін.). Дана модель може складатися із ряду специфікацій моделей – з інформаційної точки зору, з точки зору підприємства, з обчислювальної точки зору. В модель закладається лише бізнес-логіка, сценарії використання, функціональні вимоги й інша інформація про взаємодію системи з користувачем і про бажане поводження системи. При використанні MDA рекомендується доводити платформо-незалежну модель за досить високим ступенем деталізації, аж до використання високорівневої платформо-незалежної мови програмування для опису функціональності і створення виконуваної моделі. Однак деталі практичної реалізації не повинні бути присутніми у платформо-незалежній моделі.
Відображення одного типу моделей в іншій передбачає специфікацію перетворень будь-яких моделей, побудованих із використанням деякої мови для PIM у моделі деякою мовою для PSM.
Є різні можливості для відображення моделей, зокрема використання:
так званих “маркерів” (концептів відображення, в якості як елементів MOF-моделі чи інших метамоделей, типів, ролей та стереотипів з моделей);
метамоделей, заданих у певному форматі (наприклад MOF);
патернів-шаблонів відображення (що можуть включати певний набір маркерів).
Взагалі, ідеологію MDA можна зобразити у вигляді декількох рівнів (рис. 3.10). На самому верхньому рівні використовуються основні стандарти – UML, MOF XMI, за допомогою яких будуються метамоделі і моделі систем та встановлюються правила обміну даними. Перетворення в моделі PSM здійснюється з допомогою розроблених OMG стандартних відображень, різних для кожної платформи проміжного шару, – UML-профілів. Завдяки тому, що перетворення PІМ в PSM стандартизоване, можуть бути створені інструменти-аналізатори й генератори опису моделей, що істотно спрощують і автоматизують це перетворення. Далі описуються компонентні моделі, які складаються з інфраструктури розподілених об'єктів, підтримки транзакцій, механізмів подій, служби імен і служби підтримки довготривало існуючих об'єктів. І нарешті, застовуються галузеві стандарти, типові моделі ПрО.
Розробниками MDA велика увага приділена стандартизації сервісів і інтерфейсів. Передбачено значну кількість описів сервісів, як стандартних, тобто загальних для будь-якої сфери програмування, так і специфічних для певної сфери (компонентні розподілені системи, додатки реального часу, бізнес-додатки й т.д.). Стандартні сервіси й інтерфейси спрощують клієнтські додатки й виконують інтеграцію нових компонентів у середовище MDA простішою. Тобто MDA передбачає розробку стандартних сервісів, які підтримують відразу декілька технологій проміжного шару. Наприклад, можна створити репозитарий об'єктів, що надає відповідний сервіс системам як на базі CORBA, так і на базі Web-сервісів. Це не тільки спрощує розробку ПЗ, але й дозволяє організувати взаємодію різних систем.
Рис. 3.10. Використання стандартів в MDA
Так, якщо застосувати до PІМ кілька стандартних відображень на різні платформи, можна одержати кілька платформо-залежних моделей системи. Після необхідної доробки по цих моделях можна одержати реалізацію системи на декількох технологічних платформах. Тобто можна багаторазово використовувати одну платформо-незалежну модель, замість того щоб розробляти реалізацію системи на кожній платформі “з нуля”.
В MDA передбачена також можливість створення гетерогенних систем, частини яких функціонують на різних платформах проміжного шару й здатні взаємодіяти. Інструментарій, що проводить відображення, може не тільки створити PSM для кожної частини системи, але й, проаналізувавши їхню взаємодію на основі платформо-незалежної моделі, згенерувати сутності (опис інтерфейсів, код посередників, мостів і медіаторів), необхідні для міжплатформної взаємодії фрагментів системи – підсистему-адаптер.
У 2006 р. було розроблено розширення UML – мову SysML (Systems Modeling Language), яка на сьогодні фактично стала самостійною мовою. Як основні “стовпи”, що забезпечують всебічний опис систем, SysML виділяються моделювання:
структури системи (ієрархії та взаємодії між частинами) за рахунок модифікації діаграм класів у два типи діаграм блоків;
поведінки системи за рахунок модифікації діаграм дій та використання діаграм станів і послідовностей;
вимог до системи за рахунок введення нового типу діаграм для специфікації вимог – Requіrement Dіagrams;
властивостей об’єктів з допомогою нового типу діаграм – Parametric Dіagrams.
Так, для опису структури системи в SysML замість класичних UML-діаграм (класів, об'єктів й ін.) використовуються діаграми внутрішніх і зовнішніх блоків – модульних одиниць, інкапсулюючих атрибути, операції й обмеження, а також розподіл в інші модельні елементи та вимоги.
Взагалі, діаграми UML набули в SysML конкретного змісту, а також зв’язності через механізми розподілу (аllocation), зв’язку значень та верифікації.
Мова отримала можливості для підтримки розробки систем на різних стадіях – від специфікації вимог, аналізування і проектування до тестування працездатності.
Як і UML, SysML є мовою, а не методологією. Варіант використання SysML на різних стадіях створення ІС від компанії Telelogic подано на рис. 3.11.
Рис. 3.11. Процес розробки систем, оснований на використанні SysML
В SysML підтримується обмін моделями і даними в форматі XML Metadata Interchange (XMI), і як видно з рис. 3.11, отримані моделі передбачається зберігати в репозиторії з метою їх повторного використання.
На теперішній час SysML усоблює найбільш системний підхід до графічного моделювання складних систем, орієнтована саме на розробку на основі моделей й існує цілий ряд засобів, що її підтримують: Artіsan Studіo, SysML Toolkіt (EmbeddedPlus), Magіc Draw, Sparx Systems Enterprіse Archіtect, ІBM / Telelogіc Tau and Rhapsody, TopCased, Vіsіo SysML template та ін.