Первая десятка рекомендаций по моделированию для системных инженеров: Рекомендация 10. Забудьте правило "7 ± 2"

Системные инженеры отреагировали на потребность в большей строгости, приняв стандарты на языки UML и SysML. Однако эти стандарты весьма сложны и не предоставляют рекомендаций о наилучшем применении методик моделирования с использованием языков UML/SysML для эффективного специфицирования требований и архитектур, а также о применении моделирования для исследования компромиссов и для проведения различных видов анализа, необходимых при системном проектировании. Д-р Дуглас более 30 лет предоставляет консультационные услуги и реализовал уже сотни проектов. Свои наблюдения и свой глубокий опыт в этой сфере он представил в виде перечня из десяти важнейших рекомендаций по системному проектированию на основе моделей.

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

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



04.02.2014

Примечание редактора:

На протяжении следующих десяти недель в разделе по программному обеспечению Rational на сайте developerWorks будут еженедельно публиковаться рекомендации Брюса Дугласа по моделированию для системных инженеров. Вне всякого сомнения, Брюс Дуглас — идеальный автор для таких рекомендаций. Кроме того, он делает это с юмором, что значительно упрощает усвоение материала. Мы надеемся, что эти рекомендации окажутся полезными в вашей работе.

Введение

За последние 20 лет системное проектирование претерпело значительные изменения. В частности, системное проектирование перешло от текстовых документов, описывающих аналитические результаты, к методам на основе моделей, которые абстрагируют систему в виде ее сущностных свойств для более целенаправленного и более строгого исследования. Этот переход был в значительной степени обусловлен популярностью языка UML (Unified Modeling Language), что привело к созданию дополняющего его производного стандартного языка моделирования под названием SysML (Systems Modeling Language). Мне посчастливилось заниматься разработкой стандартов обоих этих языков. Я долгое время работал системным инженером и инженером по встроенному программному обеспечению, поэтому в процессе работы над этими стандартами я предоставлял информацию о потребностях системных инженеров в области анализа и представления. Кроме того, я помогал обеспечить соответствие языка его назначению, состоящему в "поддержании и совершенствовании практики системного проектирования".

За десятилетия работы я имел дело с весьма разнообразным набором систем — от небольших имплантируемых устройств медицинского назначения до телекоммуникационных систем, электронного оборудования для вертолетов и космических кораблей. Я сталкивался с моделями, обладавшими различной степенью детальности, полноты, точности и полезности. Этот разнообразный опыт сформировал у меня устойчивое представление о том, что хорошо подходит для моделирования в системном проектировании и что, скажем так, "не столь эффективно". И вот сейчас я делюсь с вами первой десяткой сформулированных мной рекомендаций по эффективному моделированию для системных инженеров. Естественно, это далеко не все, что я могу сказать по данной теме, однако для начала сойдет.


Рекомендация 10: Забудьте правило "7 ± 2"

Вы наверняка слышали следующее выражение: "Все диаграммы должны содержать семь элементов, плюс–минус два".

Вы когда-либо интересовались, откуда происходит это утверждение?

В 1956 году Джордж Миллер (George Miller) опубликовал в журнале Psychology Review статью под названием The magical number seven, plus or minus two: some limits on our capacity for processing information (Магическое число семь, плюс-минус два: некоторые пределы нашей способности обрабатывать информацию). Эта статья рассматривала два аспекта запоминания стимулов. Первый аспект — это т. н. одномерная абсолютная оценка, которая измеряет способность человека распознавать несколько стимулов, отличающихся по одному измерению (например, по размеру или по цвету), и возвращать в виде результата ранее выученный ответ (например, нажатие кнопки). Другой рассматривавшийся в статье аспект — это объем памяти, способность человека запомнить список элементов, представленных ему на определенное время, а затем удаленных из его поля зрения. Как оказалось, обе эти характеристики ограничены (с точностью 50%) одним и тем же значением, а именно: семь элементов плюс-минус два.

Возникает интересный вопрос: какое отношение все это имеет к тому, сколько объектов должно быть в диаграмме модели?

Правильный ответ, разумеется — абсолютно никакого.

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

С другой стороны, модель любого приемлемого размера имеет сотни и даже тысячи элементов. Кроме того, очевидно, что невозможно поместить все эти элементы на одну диаграмму. И что же делать?

В качестве автора процесса Harmony я могу сформулировать следующую рекомендацию: каждая диаграмма должна представлять единственную концепцию и содержать все элементы, относящиеся к этой концепции. Эта концепция носит название "миссия диаграммы".

Некоторые диаграммы имеют достаточно четко выраженные миссии. Например, машина состояния UML или SysML отражает поведение одного класса или одного блока в системе. Другие диаграммы допускают более гибкое использование.

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

Диаграммы классов или блоков обладают еще более высокой степенью гибкости. Некоторые распространенные формулировки миссий для диаграмм классов или блоков:

  • Демонстрация конструктивных элементов, совместно реализующих более крупномасштабное поведение, например, вариант использования
  • Демонстрация связывания требований со структурными элементами или с вариантом использования
  • Демонстрация обобщающей таксономии
  • Демонстрация организационных аспектов модели (т. н. "диаграмма пакетов")
    Примечание:
    Стандарты UML и SysML плохо различают типы диаграмм и способы использования диаграмм. Диаграмма задачи — это диаграмма классов, предназначенная для демонстрации архитектуры параллельного исполнения; аналогичным образом, диаграмма структуры — это диаграмма классов, цель которой состоит в демонстрации внутренней структуры класса. Обе эти диаграммы являются диаграммами классов.
  • Демонстрация следующих архитектурных аспектов.
    • Архитектура подсистем и компонентов
    • Архитектура развертывания (распределение обязанностей между различными техническими дисциплинами)
    • Архитектура управления параллельным исполнением и ресурсами
    • Архитектура распределения
    • Архитектура гарантоспособности (защищенность, надежность и безопасность)
  • Демонстрация абстракции шаблона проектирования
    • Демонстрация моментального снимка экземпляра (диаграмма объектов)
    • Демонстрация интерфейсов между программными элементами
    • Демонстрация интерфейсов между техническими дисциплинами
    • Демонстрация структуры структурированного класса (диаграмма структуры)

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

Я предпочитаю четко декларировать миссию диаграммы в комментарии, помещенном в диаграмму. На рисунках 1 – 3 показаны типичные примеры.

Рисунок 1. Миссия: демонстрация требований, связанных с вариантом использования
personnel transport mission use case diagram
Рисунок 2. Миссия: демонстрация элементов проекта, взаимодействующих при реализации варианта использования
depict spatial relations
Рисунок 3. Миссия: демонстрация варианта использования (включая предварительные условия и постусловия)
scenario for the personnel transport use case

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

Итак, вы познакомились с десятой рекомендацией в моем списке. На следующей неделе будет опубликована рекомендация 9: «Все модели являются абстракциями, однако некоторые из них полезны». Оставайтесь на связи.

Ресурсы

Научиться

  • Оригинал статьи: Top 10 modeling hints for system engineers: #10 Forget 7 ± 2.
  • Дополнительная информация о продукте 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=961870
ArticleTitle=Первая десятка рекомендаций по моделированию для системных инженеров: Рекомендация 10. Забудьте правило "7 ± 2"
publish-date=02042014