Я начинаю программирование встроенного программного обеспечения с использованием ОСРВ, и, поскольку я уже являюсь разработчиком приложений для настольных компьютеров, я постоянно задавался вопросом, каково это моделировать встроенное программное обеспечение с использованием диаграмм UML, таких как диаграммы действий, диаграммы последовательности, сценарии использования и т. Д.
Встроенное программное обеспечение разработано с использованием UML так же, как настольные приложения? Это лучший вариант или есть лучший? Могу ли я привести несколько примеров?
Есть ли конкретный инструмент, который делает это?
Ответы:
Существуют расширения реального времени для UML, которые были популяризированы компанией, чье имя в настоящий момент ускользает от меня. Я помню, как делал это несколько лет назад. Брюс Пауэлл Дуглас написал несколько книг на тему моделирования встроенных систем с использованием UML, но я думаю, что его компания - не та, о которой я думаю.
Тем не менее, повторяя Wouter, нет ничего особенного во встроенном программном обеспечении как таковом. Я пишу встроенное программное обеспечение каждый день для системы, которая работает на процессорах класса Pentium; UML вполне применим. Кроме того, помните, что многие аспекты управляющего программного обеспечения были добавлены в UML с течением времени: существует синтаксис для указания синхронных или асинхронных событий наряду со временем отклика в диаграммах последовательности, поведение типа сети Петри можно найти в диаграммах действий, поведение модели диаграмм состояний еще лучше чем диаграммы состояний и т.д.
OTOH, многие люди предпочитают моделировать встроенное программное обеспечение, используя концепции структурированного проектирования и потоков данных. Это все о типе системы, которую вы разрабатываете, и что работает лучше всего.
источник
Обращаясь к ОСРВ, мы обычно имеем дело с приложением, которое имеет много одновременных задач, которые необходимо оптимально запланировать, чтобы каждая из них своевременно выполняла свои сроки или безопасно делилась ресурсами. Выбранная вами среда RTOS реализует планировщик задач, и ваша задача (как правило) состоит в том, чтобы написать эти отдельные задачи с определенным набором свойств (период, приоритет и т. Д.) И затем передать их планировщику. Таким образом, для документирования, я бы выбрал подход к тщательному документированию каждой задачи
Большинство встроенного программного обеспечения и, насколько мне известно, большинство ОСРВ написаны не на объектно-ориентированном языке и, следовательно, могут не извлечь выгоду из многих вещей, которые ориентированы на это, например, диаграмм классов.
Однако при документировании ваших задач RTOS любая диаграмма, которая хорошо описывает задачу, будет большим преимуществом. Я думаю, что диаграмма последовательности для каждой задачи может быть очень полезной, например. Наряду с этим вы можете указать его жесткие требования, такие как период / частота, приоритет, любые совместно используемые ресурсы, которые он может использовать, требования преимущественного использования и т. Д. Также может быть полезно документировать, как вы настроили ОСРВ, и, возможно, машина его алгоритма планирования.
Примите любой из этих советов, как вам нравится, я не перепутал RTOS с тех пор, как я учился в колледже, и никогда не «документировал» работу.
источник
Моделирование это все о
зная, что является сложным и сложным в вашем приложении,
поиск инструмента моделирования / языка / абстракции / конвенции / обозначения, подходящего для этого аспекта
проектируя этот аспект
Следовательно, никакой инструмент моделирования / подход / и т. Д. Не подходит для всех ситуаций. Спутник, скорее всего, будет многозадачной системой реального времени, возможно, с более чем одним процессором. Структурные диаграммы задач, ЗППП и диаграммы последовательности, вероятно, полезны (это лишь некоторые из них). Если проект выполнен на C, диаграмма классов будет менее полезной (если она окажется очень полезной, выбор C, вероятно, был неправильным). Я не очень люблю UseCases, и у спутника an-sich нет пользователя. Варианты использования наиболее уместны в ситуации, когда вы хотите обсудить требования к вашей системе с нетехническим пользователем. Если вы находитесь в ситуации со спутниковым проектом, значит, что-то пошло не так.
источник
Я не проектировал ничего, что было бы ограничено в пространстве Но я работал в аэрокосмическом субподрядчике Министерства обороны США, и многие из моих проектов были квалифицированы для полетов. Они требуют много документации о ваших проектах и предоставляют описания элементов данных (DID), которые подробно описывают то, что они хотят видеть.
Вы можете использовать DoD ASSIST Quick Search, чтобы просмотреть все DID для документов, которые могут потребоваться, если вы введете «software» в поле «Word in In Title» и нажмете «Submit». (Мне смешно, что сайт DoD выдает предупреждение о безопасности сертификата, но, уверяю вас, это безопасно).
Поскольку вы спрашиваете конкретно о документе разработки, вот DID описания дизайна программного обеспечения (SDD). Они подчеркивают использование слов для описания каждой части дизайна. Но если использование UML, диаграмм состояний, потоковых диаграмм, псевдокода и т. Д. Может улучшить понимание проекта, то они, конечно, хотели бы, чтобы вы включили его.
Какой метод моделирования вы выберете, как говорили другие, зависит от вашего дизайна. Но я подумал, что просмотр DID для аэрокосмического программного обеспечения может помочь вам написать проектный документ, поскольку ваш проект связан с космосом.
источник