Evaluation of the Story Driven Modeling Methodology: From Towers to Models

Pieter Van Gorp, University of Antwerp, Belgium

На http://dl.acm.org не найдена.

В статье развивается методология Story Driven Modeling. Основной целью данной методологии является разработка систематического подхода к превращению требуемых сценариев в структуру классов и реализацию методов. Методология предоставляет нотацию для записи use case сценариев и стратегию по обобщению описаний сценариев (Story Board) в общую реализацию методов (Story Diagrams). В данной работе автор уточняет стратегию для описанной ранее задачи о Ханойской Башне. Так же он приводит мотивировку, почему Story Driven Modeling может являться перспективной основой для разработчиков моделей преобразований (model transformation).

В первой части статьи, автор рассматривает задачу о Ханойской Башне. Имеется 3 Story Board’а для этой задачи (сценарии решения Ханойской Башни) для 1, 2 и 3 дисков. Их формальные описания предоставлены автором. Главная задача, на примере этой игровой ситуации показать основные принципы Story Driven Modeling по систематической трансформации этих 3-х сценариев в абстрактную и компактную Story Diagram.

Рисунок 1, Story Board для 3-х дисков

Автор начинает анализировать данные сценарии и отмечает, что можно выделить операцию move, которая переносит с одной башни диск на другую, используя третью (вспомогательную, на которую перекладывают лежащий сверху диск, если он есть). Сигнатура этого будущего метода такова – это диск, подножие целевой башни, подножие вспомогательной башни. Далее автор замечает, что Story Diagram может быть описана через Story Diagram метода moveLtoR, который передвигает все диски с лева на права. Эта диаграмма выглядит очень просто, фактически это один вызов метода move для самого большого диска. Таким образом, теперь неплохо бы было описать Story Diagram для метода move.

Рисунок 2, Story Diagram для moveLtoR

Для этого автор выделяет 2 Story Board для метода move полученные из Story Board для всей Ханойской Башни с одним и двумя дисками. Эти Story Board’ы можно объединить в Story Diagram. Возникший при этом конфликт потока управления(control flow) можно разрешить, используя ветвление: в первом состоянии новой Story Diagram можно проверить, есть ли над перемещаемым диском ещё один, если есть, то идти по одному из Story Board’ов (для двух дисков), если нет то, по другому.

Рисунок 3, Story Board для метода move (1 диск)

Рисунок 4, Story Board для метода move (2 диска)

Рисунок 5, объединение Story Board-ов в одну.

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

Рисунок 6, итоговая Story Diagram для метода move.

Основываясь на выше приведённом примере, автор отмечает, что в руководства к стратегиям, порождающим Story Diagram , приведённым в более ранних работах, можно внести некоторые дополнения. В частности, к стратегии “выявлять схожие виды деятельности в тело метода и попытаться объединить их”, можно добавить, что объединение может быть реализовано как через итеративный цикл, так и путём рекурсивного вызова. К стратегии “разрешать конфликты потока управления путем добавления условий в соответствующие ветвления”, можно добавить, что конфликты могут также возникать в результате слияния, и в нашем случае подобный конфликт получилось решить созданием суперкласса.

Во второй части, автор рассматривает аспекты применения Story Diagram в model transformation. Для начала он описывает основные принципы преобразований графов и приводит примитивные примеры. Далее автор рассматривает преобразование графов применительно к сетям Петри. Автор показывает, как можно реализовать сети Перти с помощью преобразований графов, но при этом отмечает, что для реализации условного и циклического поведения в сетях Петри приходится вводить чисто технические атрибуты, которые сильно загрязняют, лежащие в основе метамодели. Поэтому автор предлагает пользоваться Story Diagrams, в которых есть пять концепций моделирования трансформации управления потоком: последовательная композиция, условия, циклы while, итеративные циклы, вызовы методов. Далее подробно описываются эти концепции.

В заключении, автор отмечает, что на примере Ханойской Башни методология Story Driven Modeling показала себя с лучшей стороны, продемонстрировав систематический подход к выводу поведенческих моделей. Две предложенные эвристики, устранение неоднозначностей и дублирования, являются универсальными в том смысле, что они не зависят от конкретных целей. Однако, всё же задача о Ханойской Башне довольно специфична, и решения, подошедшие для неё, могут быть неприменимы для широкого спектра задач. Поэтому автор делает акцент на применении Story Driven Modeling в model transformation. Здесь у данного подхода имеются некоторые проблемы. Во-первых, качество Story Board зависит, это того как хорошо выделены основные концепты, использующиеся для описания use case’ов. Во-вторых, задача генерации Story Diagram из Story Board является предметом текущих исследований и требует хорошей способности к абстракции разработчика модели. Тем не менее, Story Diagrams предоставляют простые концепции, узнаваемые многими инженерами знающими ООП. В этом автор видит основное достоинство Story Driven Modeling в применении к model transformation.