Проектування вбудованого програмного забезпечення

11

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

Чи вбудоване програмне забезпечення розроблене за допомогою UML так само, як це роблять настільні програми? Це найкращий варіант чи є кращий? Чи можу я мати кілька прикладів?

Чи є певний інструмент, який це робить?

embedded software

— Кассіо
джерело

8

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

— Wouter van Ooijen

3

Я повністю погоджуюся з коментарями @ Wouter щодо обмежених ресурсами програм, але я вважаю, що існують конкретні дизайнерські нюанси, пов’язані з використанням RTOS порівняно з м'яким графіком середовища розробки робочого столу, де блокування дзвінків є прийнятою практикою.

— HikeOnPast

1

Остерігайтеся перенапружених вбудованих систем. Дивіться також "Тостер царя" ee.ryerson.ca/~elf/hack/ktoast.html

— drxzcl

2

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

— Rocketmagnet

1

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

— drxzcl

8

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

Однак, наголос на Wouter, немає нічого особливого у вбудованому програмному забезпеченні. Я щодня пишу вбудоване програмне забезпечення для системи, яка працює на процесорах класу Pentium; UML цілком застосовно. Крім того, пам’ятайте, що багато аспектів програмного забезпечення управління були додані до UML з часом: є синтаксис для визначення синхронних чи асинхронних подій разом із часом відгуку в Послідовних діаграмах, поведінку типу Петрі можна знайти у Діаграмах активності, поведінка моделі Statecharts ще краще ніж діаграми стану можуть і т.д.

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

— ліндон
джерело

Дякую @lyndon. Але як ви моделюєте вбудоване програмне забезпечення щодня? Як ви думаєте, діаграми діяльності, державні машини та послідовність діаграм виконали б цю хитрість? Я насправді шукаю концепцію, що потрібно розробити, то які схеми потрібно зробити, щоб їх вставити в проектний документ, якщо він є для вбудованих систем.

— Кассіо

Найбільш часті конструкції, які я бачу, - це діаграми стану / діаграми стану та послідовність діаграм для щоденного використання. Я чесно думаю, що ми могли б отримати більше користі від діаграм класів, але я вважаю, що люди мають тенденцію просто створювати масові «об’єкти бога». О: компанія, про яку я думав, - Artisan Software. Це посилання може бути інформативним: werner.yellowcouch.org/Papers/rtuml/index.html#toc7

— lyndon

5

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

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

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

Візьміть будь-яку з цих порад, як вам подобається, я не спілкувався з речами RTOS ще з моїх днів в коледжі, і ніколи не "документував" роботу.

— Джон Л
джерело

Дякую @JonL. Отже, для того, щоб мати гарний дизайн-документ, мені просто потрібно було б розробити завдання, що стосуються моєї заявки? Крім того, я не дуже знайомий з алгоритмом планування, мені ніколи з цим не доводилося стикатися. Я використовую RTEMS.

— Кассіо

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

— Джон L

Так, я все ще знайомий з функціями RTOS. І дякую за запропонований підхід! Зробимо це! І як я вже говорив раніше, я новачок у вбудованому програмному забезпеченні, я не дуже впевнений, що потрібно. Було б непогано мати вбудовану архітектуру програмного забезпечення або проектний документ. У вас був би один із таких?

— Кассіо

"Більшість RTOS не написані об'єктно-орієнтованою мовою" Дійсно. Але для курсу моделювання та впровадження в режимі реального часу ми використовуємо простий (непередбачений) RTOS в C ++.

— Wouter van Ooijen

5

Моделювання - це все

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

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

— Wouter van Ooijen
джерело

Дякую @Wouter. Ви представили для мене нову концепцію: Діаграми структури завдань, приємно! Отже, це в C. Що б ви мали для документа з усіма вимогами, якби не UseCases?

— Кассіо

ІМО вам потрібен перелік ідентифікованих, більш-менш одноразових вимог, якщо тільки на основі ваших тестових випадків. Для мене UseCases - це лише метод потрапляння до такого списку. Хороший метод, в деяких випадках.

— Wouter van Ooijen

1

Я не спроектував нічого, що відповідає космосу. Але я працював у аерокосмічному підряднику Міністерства оборони (DoD), і багато моїх проектів були кваліфікованими польотами. Вони вимагають великої кількості документації щодо ваших конструкцій та надають описи предметів даних (DID), які детально описують те, що вони хочуть бачити.

Ви можете скористатися швидким пошуком DoD ASSIST, щоб побачити всі DID-документи для документів, які можуть знадобитися, якщо ви введете "програмне забезпечення" в поле "Слово в заголовку" і натисніть "Надіслати". (Мені здається смішним, що DoD-сайт видає попередження щодо безпеки сертифікатів, але запевняю, це безпечно).

Оскільки ви запитуєте конкретно про проектний документ, ось DID Опис дизайну програмного забезпечення (SDD). Вони наголошують на використанні слів для опису кожної частини конструкції. Але якщо використання UML, діаграм стану, блок-схем, псевдокоду тощо може покращити розуміння дизайну, то вони, звичайно, хотіли б, щоб ви включили його.

Який метод моделювання ви обрали, як заявили інші, залежить від вашого дизайну. Але я подумав, що перегляд DID для аерокосмічного програмного забезпечення може допомогти вам написати дизайн-документ, оскільки ваш проект пов'язаний з космосом.

— вбудований.кіль
джерело