Представления UML
Еще одна особенность UML - заложенное в нем многообразие представлений. Наличие нескольких представлений в модели, конечно же, дает более разностороннее, и в итоге более качественное понимание проектируемого объекта. Однако такое суждение справедливо только в первом приближении. Рассмотрим эту особенность более внимательно с точки зрения рассматриваемой области применения.
Для начала введем некоторые термины, необходимые для понимания последующего изложения.
Разработка программных систем представляет собой некоторое количество отображений, то есть создание ряда представлений проектируемой системы на основании разработанных ранее других представлений. Например, разработка программного кода - это отображение сформулированных ранее требований к системе, либо созданных ранее диаграмм, моделей, в упорядоченное множество операторов языка программирования. При прямом программировании выполняется отображение требований к системе в программный код (Рисунок 2). В случае использования CASE-средства выполняется несколько отображений. Например, в UML выполняются такие отображения: требования - диаграммы взаимодействия, требования - диаграммы состояний, требования - структурные диаграммы, и т.д. (Рисунок 3).
Рисунок 2.
Рисунок 3.
Однако, как говорится, отображение отображению рознь: качественно они могут сильно отличаться друг от друга. Для лучшего понимания этого введем простейшую классификацию отображений:
- Трансляция - когда элементы исходного представления, в т.ч. их совокупности (или их существенная часть), имеют соответствующие аналоги в виде элементов или их совокупностей в целевом представлении.
- Преобразование - когда элементы исходного представления или их совокупности не могут быть сопоставлены с элементами или их совокупностями в целевом представлении.
При некоторой схожести этих терминов (в том смысле, что оба они означают перевод из одной системы понятий в другую), трансляция - особенно в программистской среде - хорошо ассоциируется с формализованным процессом, что и требуется в данном случае. Преобразование же ассоциируется с чем-то гораздо менее определенным. Условимся считать эти два понятия своеобразными «полюсами», противоположными сторонами спектра возможных отображений
Если в первом случае можно определить некоторые стандартные процедуры отображения, вплоть до полной формализации процесса, то во втором - таких процедур либо не существует в принципе, либо возможное их количество незначительно. Отсюда вытекает оценка трудоемкости: если преобразование требует существенных трудозатрат, причем квалифицированного персонала, то с трансляцией может справиться практически любой специалист, знающий правила этой трансляции. Выполнение преобразования является в основном искусством, в то время как трансляция - довольно рутинный набор операций, легко поддающийся автоматизации.
В реальном мире, конечно же, имеется спектр возможных характеристик, то есть отображение может быть различным по качеству - от преобразования до трансляции. Практическая полезность данной классификации состоит в том, что конкретное отображение, его трудоемкость, требуемую квалификацию персонала, мы можем качественно оценивать путем определения степени приближения его к одному из краев этого спектра.
Отсюда вытекает возможность сопоставления представлений, связываемых отображением.
Введем еще одно понятие. Будем оценивать соотношение представлений, участвующих в отображении, степенью приближения этого отображения к преобразованию, и назовем эту характеристику «ортогональность». Она может принимать значения от нуля до максимума, то есть, от стопроцентной трансляции (нулевая ортогональность) до стопроцентного преобразования (максимальная ортогональность).
Термин «ортогональность» довольно успешно применяется в литературе для обозначения степени несоответствия различных представлений (см. например, []). Уточнение термина и сопоставление предыдущими понятиями введено исключительно с целью более однозначного понимания дальнейших рассуждений.
Исходное и целевое представления в преобразовании можно назвать ортогональными в том смысле, что они не имеют точек сопоставления. Это означает, что конкретная реализация (диаграмма, модель), выполненная в исходном представлении, может быть отображена в несколько практически эквивалентных по качеству реализаций в целевом представлении. Причем, количество возможных эквивалентов может быть и неограниченным, поскольку зависит только от разнообразия мышления выполняющих это преобразование специалистов. Степень ортогональности двух представлений соответствует степени приближения их отображения к преобразованию.
Примером трансляции может быть компиляция программного кода в язык ассемблера: элементы исходного представления - языка программирования - имеют соответствующие аналоги (элементы, или их совокупности) в целевом представлении - языке ассемблера. Пример преобразования - разработка структуры классов, когда исходным представлением являются функциональные требования к проектируемой системе: на сегодняшний день не существует однозначного соответствия между элементами требований и элементами структуры классов.
Теперь можно сформулировать еще одну характеристику качества CASE-инструмента применительно к рассматриваемой области: в процессе разработки программных средств количество отображений типа преобразование должно быть минимальным, в идеале - отсутствовать, в то время как количество отображений типа трансляция ограничивается только практическими соображениями.
Возвращаясь к UML и с учетом вышесказанного, отметим, что многообразие представлений, кроме положительного эффекта в виде более полного представления, создает и дополнительные проблемы. С одной стороны, требуется формирование, воплощение этих представлений в модели. То есть трудоемкость моделирования умножается на их (представлений) количество. С другой стороны, создание кода по спецификациям сразу нескольких различных представлений - гораздо более трудоемкая задача, нежели прямое программирование. К тому же некоторые из этих работ требуют преобразования, что по определению является искусством, то есть, задачей значительной трудоемкости. Если еще учесть итеративность разработки, которая представляет собой множитель для всех работ по моделированию, то мы получим весьма впечатляющие значения дополнительной трудоемкости. Эти суждения вполне согласуются с оценками сложности внедрения CASE-средств, приведенными в многочисленной литературе (см. например, [], []). Только причиной здесь, как мы видим, является не столько сложность проектируемой системы, сколько сложность инструмента, умноженная на специфику проектирования программных средств.
Еще одна особенность UML - то, что в нем сложно моделировать просто алгоритмы, обычные последовательности действий. Специального вида диаграмм не существует, а похожие виды (например, диаграмма активностей) обладают избыточной сложностью, и не имеют некоторых аналогов элементов алгоритмических схем. Между тем, алгоритмические схемы широко используются в разработке «средних» программных средств, поскольку обладают высокой степенью адекватности программному коду. В результате, как отмечено в [], в анализе реально выполненных проектов, «В рассмотренных моделях операции практически не обладали семантикой состояний, поэтому 99% операций описывались автоматами без состояний, вырождаясь в императивную последовательность действий», то есть автоматы фактически использовались для отображения алгоритмов. Что свидетельствует о наличии серьезной потребности в таких средствах, степень адекватности которых алгоритмическому представлению, программному коду, была бы достаточно высокой.
Резюмируем изложенное: существенными особенностями UML, усложняющими проектирование, являются необходимость разработки нескольких представлений проектируемой системы, иногда ортогональных исходному либо целевому представлению, избыточное многообразие этих представлений, а также неполная адекватность инструмента фактическим потребностям разработчиков.
Все вышесказанное в той же мере относится и к основанным на UML CASE-средствам, поскольку они автоматически воспроизводят избыточную сложность языка.
