Опис модуля RUP для керованої моделями розробки систем, Комерція, Різне, статті

З журналу Rational Edge: Плагін для IBM Rational Unified Process (RUP) підтримує основні принципи системного проектування та керованої моделями розробки систем ((Model-Driven Systems Development, MDSD). Цей модуль буде особливо корисний керівникам проектів розробки систем, а також усім, хто має справу з аналізом і розробкою специфікацій систем, їх архітектурою, реалізацією і тестуванням.
З журналу The Rational Edge.



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


Системне проектування об’єднує всі групи розробників в єдину команду, створюючи основу структурованого процесу розробки, який проходить через всі стадії процесу – від вироблення концепції до розробки та запуску у промислову експлуатацію. Маючи на меті надання якісного продукту, який задовольняє вимогам користувачів, системне проектування враховує як технічні, так і бізнес-потреби всіх замовників. Члени Міжнародної ради з системного проектування (International Council on Systems Engineering, INCOSE) виробили погоджені визначення термінів “Система” і “Системне проектування.”


Керована моделями розробка систем (Model-Driven Systems Development, MDSD) підтримує визначення INCOSE. Вона допомагає в управлінні складністю проектування системи. Забезпечення необхідного рівня деталізації для кожного рівня моделі – важливий компонент MDSD. Для цього використовується ряд практичних прийомів, які можна назвати передовими методами, а саме:



Реалізація систем здійснюється шляхом:



Тепер, після виходу модуля MDSD для RUP, саме час розповісти про MDSD. У цій статті будуть розглянуті основні принципи MDSD, включаючи рівні моделювання, рівні декомпозиції, а також принципи, використані в MDSD для підтримки концепції Інтеграції моделі технологічної зрілості Інституту розробки програмного забезпечення (Capability Maturity Model Integration, CMMI).


Моделі і абстракція


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


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


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


Рівні декомпозиції


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


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


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


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


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



Про ці фактори ми докладніше поговоримо нижче.


Рівні моделей та їх призначення


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



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


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


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


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


Те, як відбувається проектування елемента, залежить від його типу. Програмні елементи можуть використовувати реалізації на основі UML або варіантів використання, – принцип, дуже схожий на MDSD, але застосовуваний на рівні проекту програмного забезпечення для створення технічного проекту ПЗ. Проект електронного компонента, швидше за все, буде представлений у вигляді схематичне діаграми, тоді як для елементів типу “трудові ресурси” можна використовувати організаційні діаграми і списки необхідних професійних навичок.


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


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


“Чорний ящик” і “білий ящик”


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


Операцію перемикання каналів на телевізійному приймачі можна описати, просто вказавши, що глядач натискає кнопку “+”, а телевізор перемикає поточний канал. Зверніть увагу на те, що тут не згадується екран або тюнер, тому що вони є внутрішніми елементами системи.


Подання у вигляді “білого ящика”, навпаки, містить інформацію про двох додаткових аспектах системи. Крім функцій введення і виведення вистава “білий ящик” описує:



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


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


Взаємодії між елементами


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


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


У той же час, те, що підкреслюється на якому рівні декомпозиції – це взаємодія між ідентифікованими на цьому рівні елементами. У наведеному вище прикладі це взаємодія між пасажиром і літаком, саме воно і описується. Те, які взаємодії є важливими для опису – це основний фактор в ухваленні рішення про те, які рівні декомпозиції використовувати. Розглянемо випадок з пілотом нашого комерційного літака. Чи є пілот частиною системи літака або він розглядається поза системою? Будь-який спосіб моделювання системи є коректним, і який спосіб вибрати, залежить від того, які взаємодії важливі в даній ситуації. Якщо важливо те, як пілот взаємодіє з літаком, тобто якщо літак вважається “чорним ящиком”, а для взаємодії з літаком як з єдиним цілим використовується деякий інтерфейс, то в цьому випадку можна описати пілота як окрему сутність на тому ж рівні, що й літак. Це дозволить описати взаємодію між пілотом і літаком як взаємодія з “чорним ящиком”. З іншого боку, можливо, має сенс розглядати пілота і літак разом як окремий елемент системи, тим самим виділяючи, скажімо, взаємодія диспетчерської вишки з елементом “Літак з пілотом”. За деякими міркувань, це може виявитися кращим підходом. Якщо ми розробляємо літак, то нас, швидше за все, цікавить те, як літак в цілому (включаючи екіпаж) взаємодіє із зовнішніми елементами, такими як диспетчерська вишка, пасажири і наземні служби аеропорту.


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


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


Інтеграція з RUP


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


RUP без модуля MDSD являє собою процес проектування програмного забезпечення. RUP з підключається модулем MDSD являє собою процес системного проектування, для якого проектування програмного забезпечення (за допомогою використання RUP) є підмножиною.


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


На Web-сайті RUP системне проектування не представлено явним чином у вигляді окремої дисципліни. Тим не менш, технологія MDSD, яка включає в себе існуючі дисципліни RUP, являє собою процес життєвого циклу системного проектування.


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


Процес RUP з розширенням MDSD застосуємо на якому рівні в ієрархії системи систем, в тому числі на найнижчому рівні, на якому (по крайней мере, для програмного забезпечення) поведінка підсистеми реалізується за допомогою спільної діяльності об’єктів ПО (і зв’язків). Зверніть увагу, що діяльність з розробки підсистеми з точки зору її розробників аналогічна загальній розробці систем в сенсі вимог до процесу: тобто вона повинна мати початкову фазу (Inception), фазу уточнення (Elaboration) і т. д. Тому, якщо ми розглянемо загальний план розробки системи, ми виявимо послідовність фаз RUP, а заглибившись на більш детальний рівень, знову зауважимо фази розробки в термінах RUP, або життєві цикли, по одному на кожну підсистему.


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


Стандарт інтеграції Capability Maturity Model Integration (CMMI) для розробки


MDSD відповідає моделі процесу CMMI-DEV v1.2, яка характеризує проектування систем і системних інженерів наступним чином:


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

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

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


Цей погляд на систему розширює уявлення про базове RUP, в якому термін “система” використовується для позначення програмного забезпечення та комп’ютерних апаратних пристроїв, на яких вона виконується. Крім того, відомо, що дуже часто застосування MDSD вимагає від розробників великого обсягу роботи, особливо якщо підсистеми, з яких складається система, самі є досить складними системами. При цьому мається на увазі, що RUP (або MDSD) в процесі розробки систем може застосовуватися не один раз.


Тому процес системного проектування повинен мати засоби для роботи з системами, що мають довільну складність і розмір і вимагають міждисциплінарного підходу до проектування, розробки і супроводу. В офіційному документі The Rational Unified Process for Systems Engineering (Процес RUP для системного проектування) пояснюються причини розробки процесу RUP для системного проектування (RUP for Systems Engineering, RUP SE). MDSD являє собою продукт еволюції RUP SE і доповнює модель процесу засобами, що дозволяють вирішити проблеми складності та розміру (як вимог і потреб замовника, так і проектних), якості сервісу та інших особливостей проектування, з якими стикаються системні інженери.


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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*