Разработка встроенного программного обеспечения

11

Я начинаю программирование встроенного программного обеспечения с использованием ОСРВ, и, поскольку я уже являюсь разработчиком приложений для настольных компьютеров, я постоянно задавался вопросом, каково это моделировать встроенное программное обеспечение с использованием диаграмм UML, таких как диаграммы действий, диаграммы последовательности, сценарии использования и т. Д.

Встроенное программное обеспечение разработано с использованием UML так же, как настольные приложения? Это лучший вариант или есть лучший? Могу ли я привести несколько примеров?

Есть ли конкретный инструмент, который делает это?

embedded software

— Кассио
источник

8

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

— Воутер ван Оойен

3

Я полностью согласен с комментариями @ Wouter по поводу приложений с ограниченными ресурсами, но я считаю, что есть определенные нюансы проектирования, связанные с использованием ОСРВ по сравнению со средой разработки рабочего стола с мягким расписанием, где блокировка вызовов является общепринятой практикой.

— HikeOnPast

1

Остерегайтесь сверхинженерных встроенных систем. Смотрите также «Тостер короля» ee.ryerson.ca/~elf/hack/ktoast.html

— drxzcl

2

@drxzcl - Не согласен. Во-первых, я не думаю, что вы можете быть слишком внимательны при разработке программного обеспечения для космических исследований . Во-вторых, подход Инженера к Королевскому Тостеру - причина, по которой столько хлеба сжигается. Большинство тостеров слишком просты для того, что на самом деле является нетривиальной работой.

— Ракетный магнит

1

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

— drxzcl

8

Существуют расширения реального времени для UML, которые были популяризированы компанией, чье имя в настоящий момент ускользает от меня. Я помню, как делал это несколько лет назад. Брюс Пауэлл Дуглас написал несколько книг на тему моделирования встроенных систем с использованием UML, но я думаю, что его компания - не та, о которой я думаю.

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

OTOH, многие люди предпочитают моделировать встроенное программное обеспечение, используя концепции структурированного проектирования и потоков данных. Это все о типе системы, которую вы разрабатываете, и что работает лучше всего.

— Линдон
источник

Спасибо @ Линдон. Но как вы моделируете встроенное программное обеспечение каждый день? Считаете ли вы, что диаграммы действий, конечные автоматы и диаграммы последовательностей могут помочь? Я на самом деле ищу понятие о том, что проектировать, а затем, какие схемы нужно сделать, чтобы вставить их в проектный документ, если таковой существует для встроенных систем.

— Кассио

Наиболее часто встречающиеся конструкции - это диаграммы состояний / диаграммы состояний и диаграммы последовательностей для повседневного использования. Честно говоря, я думаю, что мы могли бы получить больше пользы от диаграмм классов, но я обнаружил, что люди склонны просто создавать массивные "объекты бога". О: компания, о которой я думал, это Artisan Software. Эта ссылка может быть информативной: werner.yellowcouch.org/Papers/rtuml/index.html#toc7

— Линдон

5

Обращаясь к ОСРВ, мы обычно имеем дело с приложением, которое имеет много одновременных задач, которые необходимо оптимально запланировать, чтобы каждая из них своевременно выполняла свои сроки или безопасно делилась ресурсами. Выбранная вами среда RTOS реализует планировщик задач, и ваша задача (как правило) состоит в том, чтобы написать эти отдельные задачи с определенным набором свойств (период, приоритет и т. Д.) И затем передать их планировщику. Таким образом, для документирования, я бы выбрал подход к тщательному документированию каждой задачи

Большинство встроенного программного обеспечения и, насколько мне известно, большинство ОСРВ написаны не на объектно-ориентированном языке и, следовательно, могут не извлечь выгоду из многих вещей, которые ориентированы на это, например, диаграмм классов.

Однако при документировании ваших задач RTOS любая диаграмма, которая хорошо описывает задачу, будет большим преимуществом. Я думаю, что диаграмма последовательности для каждой задачи может быть очень полезной, например. Наряду с этим вы можете указать его жесткие требования, такие как период / частота, приоритет, любые совместно используемые ресурсы, которые он может использовать, требования преимущественного использования и т. Д. Также может быть полезно документировать, как вы настроили ОСРВ, и, возможно, машина его алгоритма планирования.

Примите любой из этих советов, как вам нравится, я не перепутал RTOS с тех пор, как я учился в колледже, и никогда не «документировал» работу.

— Джон Л
источник

Спасибо @JonL. Итак, для того, чтобы получить хороший проектный документ, мне просто нужно спроектировать задачи, связанные с моим приложением? Кроме того, я не очень знаком с алгоритмом планирования, мне никогда не приходилось с ним сталкиваться. Я использую RTEMS.

— Кассио

@ Кассио, я не говорю тебе делать то или иное, это действительно твое дело. Просто попробуйте сделать то, что необходимо. Если вы не знакомы с вашей ОСРВ, я думаю, что сначала стоит начать с нее, и как вы должны ее использовать, было бы неплохо для начала. Тогда вы можете начать разрабатывать свои задачи вокруг него.

— Джон Л

Да, я все еще знакомлюсь с функциями RTOS. И спасибо за предложенный подход! Сделаю это! И, как я уже говорил, я новичок во встроенном программном обеспечении, я не совсем уверен, что нужно. Было бы неплохо иметь встроенную программную архитектуру или проектный документ. Будете ли вы иметь один из них?

— Кассио

«Большинство ОСРВ написаны не на объектно-ориентированном языке». Но для курса по моделированию и реализации в реальном времени мы используем простую (не упреждающую) ОСРВ в C ++.

— Ваутер ван Ойджен

5

Моделирование это все о

зная, что является сложным и сложным в вашем приложении,
поиск инструмента моделирования / языка / абстракции / конвенции / обозначения, подходящего для этого аспекта
проектируя этот аспект

Следовательно, никакой инструмент моделирования / подход / и т. Д. Не подходит для всех ситуаций. Спутник, скорее всего, будет многозадачной системой реального времени, возможно, с более чем одним процессором. Структурные диаграммы задач, ЗППП и диаграммы последовательности, вероятно, полезны (это лишь некоторые из них). Если проект выполнен на C, диаграмма классов будет менее полезной (если она окажется очень полезной, выбор C, вероятно, был неправильным). Я не очень люблю UseCases, и у спутника an-sich нет пользователя. Варианты использования наиболее уместны в ситуации, когда вы хотите обсудить требования к вашей системе с нетехническим пользователем. Если вы находитесь в ситуации со спутниковым проектом, значит, что-то пошло не так.

— Воутер ван Оойен
источник

Спасибо @Wouter. Вы ввели для меня новую концепцию: диаграммы структуры задач, хорошо! Итак, это на C. Что бы вы имели для документа со всеми требованиями, если бы не UseCases?

— Кассио

IMO вам нужен список идентифицируемых, более или менее единичных требований, если только вы будете основывать свои тестовые примеры. Для меня UseCases - это просто способ попасть в такой список. Хороший метод, в некоторых случаях.

— Воутер ван Оойен

1

Я не проектировал ничего, что было бы ограничено в пространстве Но я работал в аэрокосмическом субподрядчике Министерства обороны США, и многие из моих проектов были квалифицированы для полетов. Они требуют много документации о ваших проектах и предоставляют описания элементов данных (DID), которые подробно описывают то, что они хотят видеть.

Вы можете использовать DoD ASSIST Quick Search, чтобы просмотреть все DID для документов, которые могут потребоваться, если вы введете «software» в поле «Word in In Title» и нажмете «Submit». (Мне смешно, что сайт DoD выдает предупреждение о безопасности сертификата, но, уверяю вас, это безопасно).

Поскольку вы спрашиваете конкретно о документе разработки, вот DID описания дизайна программного обеспечения (SDD). Они подчеркивают использование слов для описания каждой части дизайна. Но если использование UML, диаграмм состояний, потоковых диаграмм, псевдокода и т. Д. Может улучшить понимание проекта, то они, конечно, хотели бы, чтобы вы включили его.

Какой метод моделирования вы выберете, как говорили другие, зависит от вашего дизайна. Но я подумал, что просмотр DID для аэрокосмического программного обеспечения может помочь вам написать проектный документ, поскольку ваш проект связан с космосом.

— embedded.kyle
источник