Case-технологии - статьи

UML-диаграммы состояний


Рассмотрим наиболее характерный элемент диаграммы - состояние (Рисунок 1).

Рисунок 1.

Очевидно, основной смысл элемента - нахождение объекта в этом состоянии какое-то время, и выход из него при возникновении какого-то условия (события). Фактически же, представленный на рисунке объект в этом состоянии выполняет еще что-то, по каким-то правилам. Понять это можно, только прочитав его содержимое, и зная при этом определение его внутренней структуры. Фактически имеем довольно-таки сложный элемент, нагруженный, кроме базового определения, дополнительными понятиями:

  • Входное действие.
  • Выходное действие.
  • Действие внутреннее (деятельность).

Кроме того, в соответствии со стандартом UML, состояние может содержать:

  • Вложенные состояния.
  • Входные и выходные порты.

В итоге сложность понятия "состояние" получается настолько высокой, что становится сопоставимой со сложностью соответствующего ему кода.

Результаты аналогичного рассмотрения других элементов диаграммы состояний сведены в Таблицу 1.

Элемент диаграммы состояния Базовое понятие Нагружен понятиямиСостояние Действие Решение Событие

Состояние Состояние * ***  
Переход Действие   * * *
Решение Решение        
Событие Событие Не имеет специального обозначения

Таблица 1.

Как нетрудно заметить, основные элементы (кроме элемента «Решение») нагружены несколькими дополнительными понятиями. Между тем, все элементы и их «нагрузки», фактически являются производными от небольшого числа элементарных (базовых) понятий: Состояние, Действие, Решение, Событие.

В итоге, уже на этапе моделирования сложность создания представления посредством этих элементов сопоставима с прямым программированием. Но мы же еще только моделируем объект, а не программируем его! Получается, мы должны на разработку объекта затратить близкое к двойному количество труда. И ради чего? Ради получения более выразительного представления, которого к тому же зачастую бывает недостаточно для программирования объекта.

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

Подобные качества элементов в разной степени присутствуют и в других диаграммах UML.

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



Содержание раздела