Первая десятка рекомендаций по моделированию для системных инженеров: Рекомендация 6. Передача полномочий на основе модели сохраняет точность

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

Брюс Дуглас, главный популяризатор Rational, отделение системотехники

Фото автораБрюс Дуглас (Bruce Douglass) имеет более чем 30-летний опыт работы с программным обеспечением и специализируется на разработке систем реального времени и встраиваемых систем. Он автор процесса разработки встраиваемых систем реального времени IBM Rational Harmony™ (Harmony/ERT). Вместе с Питром Хофманом разработал оригинальный процесс Harmony, в котором системотехника и ПО сочетаются с узкоспециализированной автоматизацией для достижения гладкого, комплексного рабочего процесса. В IBM занимается консалтингом и преподаванием UML, SysML и DoDAF не только заказчикам программного обеспечения Rational, но и собственным инженерам, научным сотрудникам и специалистам по маркетингу IBM. Написал более 100 журнальных статей и 15 технических книг, является лектором и членом консультативного совета Конференции встраиваемых систем и Всемирной конференции UML. Его опыт включает в себя гибкую разработку и гибкие методы проектирования систем, а также разработку на основе модели и системы повышенной безопасности.



07.02.2014

Обычный подход к передаче материалов от этапа системного проектирования к последующим этапам проектирования (включая проектирование механических, электронных и программных элементов) предусматривает формулирование требований в текстовом виде. Эта процедура не только является весьма трудоемкой, она — как и в случае с системными требованиями — сопряжена со следующими проблемами:

  • Недостаточная детальность
  • Недостаточная полнота
  • Недостаточная точность
  • Недостаточная корректность

Если вы хотите создавать хорошие модели для системного проектирования, имеет смысл конструировать их с учетом передачи моделей и текста на следующий этап. На рис. 1 показан поток работ Harmony для передачи материалов на последующие этапы разработки.

Рисунок 1. Поток работ Harmony для передачи материалов на последующие этапы разработки
Downstream hand off

Два треда в этом потоке операций специфицируют физические интерфейсы между элементами. Это ситуация т.н. совместно используемой модели. Затем они создают итоговую техническую модель каждой подсистемы для использования на последующих этапах.

Совместно используемая модель содержит элементы, которые используют или к которым обращаются несколько подсистем. Это подразумевает наличие интерфейсов между системой и акторами, а также наличие интерфейсов между самими подсистемами. Значительная часть этой модели системного проектирования имеет специфицированные логические интерфейсы. Однако на этой стадии подсистемы должны обращаться к фактической намеченной реализации интерфейсов, то есть к физическим интерфейсам. Поток операций в левой части рисунка 2 преобразует информацию логического интерфейса в спецификации физического интерфейса, управление которыми затем осуществляет конфигурация.

В правой части рисунка 2 модели подсистем сначала импортируют свои спецификации из модели системного проектирования. Затем эти требования передаются соответствующим техническим дисциплинам (например, проработка механических, электрических и программных аспектов) в рамках подсистемы. Некоторые требования могут быть просто перенаправлены соответствующей дисциплине. Требование нередко реализуется посредством сочетания элементов из различных технических дисциплин. Такие требования необходимо разложить на производные требования, каждое из которых затем можно будет передать одной технической дисциплине. Обычно я делаю это с использованием структурной схемы – с помощью стереотипов и соглашений об именовании я выявляю на такой схеме элементы, которые по своей природе являются исключительно программными, механическими или электронными. После этого требования могут быть с легкостью связаны с соответствующими элементами.

Рисунок 2. Декомпозиция подсистемы на элементы, принадлежащие различным техническим дисциплинам
subsystems with boxes for each engineering discipline

Кликните, чтобы увидеть увеличенное изображение

Рисунок 2. Декомпозиция подсистемы на элементы, принадлежащие различным техническим дисциплинам

subsystems with boxes for each engineering discipline

Не менее важно определить интерфейсы между элементами, принадлежащими различным техническим дисциплинам, например, интерфейс между программными и электронными элементами. В результате инженеры с обеих сторон этого интерфейса будут иметь одинаковые "наборы ожиданий". Для этого я использую функцию языков UML и SysML под названием tagged values (тегированные значения). Тегированные значения позволяют определять значимые для модели метаданные. В случае интерфейса между программными и электронными элементами используются следующие метаданные.

  • Тип интерфейса (например, отображенная память, отображенный порт или отображенное прерывание).
  • Структура интерфейса.
  • Информация о синхронизации.

Спецификация для интерфейса между программными и электронными элементами показана на рис. 3.

Рисунок 3. Специфицирование интерфейса между программными и электронными элементами
metadata for the model

После завершения потока операций по передаче модели можно будет приступать к последующим этапам разработки.

Ресурсы

Научиться

  • Оригинал статьи: Top 10 modeling hints for system engineers: # 9 All models are abstractions but some are useful+.
  • Дополнительная информация о продукте Rational System Architect
  • Для получения дополнительной информации об инструменте Rational Rhapsody для коллективной управляемой моделями разработки встроенных систем познакомьтесь с обзором линейки продуктов Rational Rhapsody и посетите страницу Rational Rhapsody на сайте IBM developerWorks. Чтобы получить локальный экземпляр документации, посетите раздел Changing the location of help content в информационном центре по продукту Rational Rhapsody 7.6.
  • Для получения дополнительной информации о возможностях продукта Rational Rhapsody в области управления проектированием ознакомьтесь с инструментом IBM Rational Rhapsody Design Manager, который позволяет всем участникам группы разработки взаимодействовать, совместно использовать ресурсы, просматривать материалы, управлять проектированием и моделями. Кроме того, посетите страницу Design Management на сайте Jazz.net.
  • Посетите раздел по программному обеспечению Rational на сайте developerWorks и ознакомьтесь с техническими материалами, проверенными методиками и информацией по интегрированным решениям Rational для коллективного создания программного обеспечения и систем.
  • Следите на веб-сайте developerWorks за мероприятиями и трансляциями по техническим вопросам, посвященными различным продуктам IBM и актуальным темам ИТ-отрасли.
  • Углубите свои навыки. Ознакомьтесь с каталогом ресурсов для обучения и сертификации по продуктам Rational, который содержит множество курсов различного типа, охватывающих широкий диапазон тем. Некоторые из этих курсов можно пройти в любом месте и в любое время, а многие курсы категории Getting Started являются бесплатными.

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational
ArticleID=962105
ArticleTitle=Первая десятка рекомендаций по моделированию для системных инженеров: Рекомендация 6. Передача полномочий на основе модели сохраняет точность
publish-date=02072014