Методы композиции и декомпозиции исполняемых UML моделей

       

Конечные автоматы UML


Конечные автоматы UML могут описывать поведение следующих элементов исполняемых моделей: активный класс (active class), операция (operation), составное состояние (composite state). В [] было проведено количественное исследование моделей, используемых в реальных коммерческих проектах. Была составлена представительная выборка таких моделей, анализ которой показал, что, несмотря на наличие достаточно легко понимаемой структуры, почти у 90% исследованных элементов модели (диаграмм, автоматов), оставшиеся 10 % элементов, как правило, весьма сложны и, более того, именно они специфицируют основную логику работы системы. Таким образом, любые попытки понять и проанализировать поведенческие стороны сложной системы будут наталкиваться на необходимость изучения сложных конечных автоматов, описанных посредством громоздких диаграмм состояний. А так как для любой относительно нетривиальной модификации, количество которых за время жизни программной системы может исчисляться сотнями тысяч, требуется понимание логики работы системы, возникает потребность в методах, упрощающих восприятие системы и облегчающих ее понимание.

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

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

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

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

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


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