Використання UML та ОСРВ при зміні парадигми програмування вбудованих систем від процедурного до об’єктно-орієнтованого, CASE-засоби (моделювання), Програмування, статті

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


Ця стаття сфокусована на тому, як підійти до ГО розробці ПО і чому нам слід використовувати цей потужний підхід.


Навіщо міняти парадигму?


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


На сьогоднішній день ми маємо в своєму розпорядженні двома характеризують критеріями для такого розгляду: обсяг ПЗ, вимірюваний в рядках коду (LOC) і складність ПО.


Давайте розглянемо історію розробки. Перші мікроконтролери перемістилися в світ електронного урядування близько 15 років тому. В цей час домінуючою платформою були маленькі 8-розрядні контролери. Через 5-7 років вимоги додатків виросли так істотно, що більшість з цих мікроконтролерів було замінено більш продуктивними 16-розрядними контролерами, а ще через 5-7 років для задоволення стійко зростаючим вимогам функціональності – 32-розрядними контролерами.


Якщо ми подивимося на середній розмір ПЗ, написаного в цих проектах, і виміряємо його в LOC, то побачимо наступні результати: в проектах, які використовують 8-розрядні контролери зазвичай писалося 8000 рядків коду; в проектах з 16-розрядними контролерами ми знаходимо близько 80 000 написаних рядків; і в 32-разраядних контролерах ми бачимо близько 1000000 рядків коду. Цей феномен зростання LOC спостерігається часто і майже у всіх додатках.


З цих спостережень ми можемо зробити висновок, що розмір коду, що підлягає розробці, збільшується приблизно в 10 разів кожні 5-7 років. Цей вражаючий ріст насправді відбувається ще швидше, тому що один тільки розмір програми насправді не є правильною ілюстрацією впливу зазначеного зростання на зусилля з програмування. Набагато кращим показником є ​​складність програми. Якщо ми виміряємо складність коду, то прийдемо до висновку, що зростання складності відбувається експоненціально щодо зростання LOC.


Ця величина зростання перевищує нашу здатність зрозуміти всі наслідки, до яких він веде. Чому? Тому що для порівняння зростання проектів є дуже небагато параметрів і це допомагає відповісти на питання, чому зростання проектів розробки ПЗ в принципі не можна повністю оцінити. Ось, найбільш яскравий момент: кількість розробників у вашому відділі ймовірно не зростає з такою ж неймовірною швидкістю, вірно? Бюджет для нових методів та інструментів розробки так само зростає повільніше, а ваша зарплата, ймовірно, не росте взагалі. Хіба не було б логічніше, якби всі ці ресурси зростали так само, як обсяги кодів? Зрозуміло, існує проста причина того, чому це не так: вартість кінцевого продукту, в якому використовується вбудовуване ПО, так же не росте значно. Отже, що ми повинні зробити по відношенню до цієї проблеми, так це підвищити свою ефективність, і шляхом до цього є зміна парадигми.


Як виглядає необхідна зміна парадигми?


Як виглядає ця зміна парадигми? Остання зміна була переходом від неструктурованого програмування до структурної. Цей крок був зроблений близько 8-15 років тому шляхом переходу з програмування на асемблері до програмування на високорівневої мовою на кшталт “С”. Отже, згідно з нашим графіком змін, нова заміна парадигми значно запізнилася. Існує стародавня стратегія, яка сьогодні зберігає ефективність і надалі продемонструє, чому зміна парадигми буде успішним. Стратегія, про яку ми говоримо, була названа “розділяй і володарюй” Юлієм Цезарем, “кінцеві елементи” – нашими колегами інженерами-механіками, і ООП (об’єктно-орієнтоване програмування) інженерами по ПЗ. За допомогою цієї стратегії можна знизити зростання складності. Це – простий секрет ООП.


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


Багато що читачі негайно предположат, що обговорюючи ООП ми маємо на увазі програмування на С + +. Однак це не так.


Одне програмування на С + + не дуже підходить для застосування ООП. На жаль, дуже часто невідомо, що ООП вимагає більше елементів на додаток до С + +. В платформенном програмуванні, наприклад, використовуються MFC (Microsoft Foundation Classes). Один з аспектів цього підходу полягає в тому, що адреса MFC є інтерфейсом до операційної системи. Ця операційна система визначає відгук програми в ході її виконання. Так от, в С + + упущено щось істотне: елементи для опису часу реакції при виконанні програми. Однак це – фундаментальна необхідність в орієнтованих на період виконання вбудованих додатках реального часу. Чому?


Розробка багаторівневих додатків з жорсткими вимогами до часу реакції


При розробці багаторівневого ПО необхідно брати до уваги наступні чотири площини:


· Рівень поведінки


· Рівень часу


· Рівень потоку даних


· Рівень пріоритетів


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


Отже, використовуючи типовий підхід до програмування, розробник змінює щось на рівні поведінки (наприклад, розширює ПО інструкціями, при цьому впливаючи в плані виконання на всю систему, приводячи, таким чином, до нової проблеми в зовсім іншій частині програми). При цьому виникає питання: яка мовна конструкція є в С + + для забезпечення особливої ​​поведінки з однією з частин програми? В С + + не існує таких конструкцій, але є дещо інше: MFC (Microsoft Foundation Classes). MFC містять конструкції, які формують інтерфейс до операційної системи. За допомогою цих конструкцій можна задавати особлива поведінка на етапі виконання як частина програми. Тоді операційна система піклується про те, що б на етапі виконання забезпечувалася можливість цього відгуку.


Існує багато інших сервісів, які надає ОСРВ для створення ГО інтерфейсів як невід’ємну частину програми (наприклад, функції асинхронного взаємодії). Звичайно, в рамках цієї статті ми не можемо привести приклади всіх видозмін цієї проблеми, але, сподіваємося, основний задум ясний.


Вбудовувані системи реального часу набагато більше орієнтовані на період виконання, ніж платформні системи, але ні С, ні С + + не пропонують хорошого механізму для опису відгуку періоду виконання, необхідного при проектуванні. Для досягнення цього потрібні системи часу виконання. У комерційних системах на кшталт CMX-RTX розробки CMX Systems доступна функціональність, іменована ОСРВ (Операційна Система Реального Часу). Сервіси ОСРВ є основою лінійки інтерфейсів, які реально здатні тільки пов’язувати один рівень коду і не можуть передавати на інший рівень. На цей випадок ОСРВ пропонує ряд конструктивних рішень. Найпростішими рішеннями є механізм диспетчеризації і механізм асинхронного взаємодії. Два цих загальних рішення дозволяють розробникам проектувати цільову архітектуру з використанням ГО інтерфейсів. Таким підходом досягається справжня інкапсуляція і це повинно бути першим кроком в кожному проекті із застосуванням ООП. Це підвищує зрозумілість і модифікованості, але існує ще одне, більше, гідність, яке буде використовувати реальний потенціал ефективності: поліпшення умов для перевикористання коду.


Основна вигода від підвищення ефективності шляхом перевикористання коду


У додатках обсягом понад 50 000 LOC вже більше немає можливості викинути старий вихідний код і почати новий проект “з нуля” (навіть якщо деякі розробники будуть пропонувати таке рішення). Тільки використовуючи повторно стільки коду, наскільки можливо ми можемо витримувати терміни виконання проектів, які стають все коротшими і коротшими. Об’єктно-орієнтовані інтерфейси є найбільш елементарними передумовами і вони надаються нам цільовими системами. На жаль, є певний недолік у використанні ОСРВ. Успішне перевикористання коду реально означає, що витрати на адаптацію існуючого ПО повинні бути настільки мінімальними, наскільки можливо. З цієї причини інтерфейси цільових систем по можливості завжди повинні залишатися незмінними.


Однак, якщо для нового завдання потрібно модифікувати комерційну ОСРВ, то “утилізувати” інтерфейс буде важко. Це було визнано автомобільної індустрією, і був створений стандарт, який називається стандартом OSEK для ОСРВ. Цей стандарт підходить для багатьох додатків і є сильно запізнілими кроком у вірному напрямку. Але паралельно з OSEK був розроблений інший, більш потужний, стандарт. Цей новий стандарт називається нотацією UML (Unified Modeling Language), стандартизованої OMG (Object Management Group).


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


Висновки


Перехід від процедурного програмування до ООП вирішить велику частину сьогоднішніх проблем і містить величезний потенціал підвищення ефективності, вкрай необхідної нам при розробці вбудованих систем. Основа цього переходу – це не С + +, як часто припускають, а використання проектування періоду виконання. Тому використання ОСРВ грає центральну роль в цьому переході. Спільно з використанням таких ГО нотацій, як С + + або, краще, UML, ця ефективність може бути помножена надзвичайно. Перевіреним рішенням, що застосовується на ринку протягом більш, ніж 3 років, є комбінація ОСРВ CMX-RTX і Rhapsody з С / С + +. Код, що генерується Rhapsody, оптимізований для додатків, що займають мало місця в пам’яті, і використання CMX-RTX. При такому підході типове додаток, включаючи CMX RTX, вимагає близько 18 Kбайт ПЗУ і 300 байт ОЗУ.


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


Ви вже тут?


Willert Software Tools GmbH

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


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

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

Ваш отзыв

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

*

*