Различия между отношениями включения и расширения

Следует остановиться на различиях, существующих между отношениями включения и расширения. В своей работе [4] Джим Коналлен приводит две диаграммы с использованием отношения включения и расширения, изображенные на рис. 3.12, и называет их эквивалентными.

Рисунок 3.12. Неэквивалентные диаграммы прецедентов

Строго говоря, это не верно. Понять разницу между двумя типами отношений довольно легко, если вдумчиво вчитаться в их определение. Отношение расширения “срабатывает” в точке расширения при условии истинности некоторого условия. Т.е. цепочка действий, содержащаяся в прецеденте, расширяющем базовый, может отработать, а может – нет. В отличие от отношения расширения, отношение включения всегда вызывает последовательность действий, содержащуюся в прецеденте, включаемом в базовый. Поэтому если предположить, что в системе, рассматриваемой в работе [4] модификация профайла пользователя невозможна без входа в систему путем авторизации, то справедливой является верхняя диаграмма.

Вместе с тем, Коналлен справедливо отмечает, что “для выбора необходимых терминов может понадобиться настоящее искусство”. С автором можно согласиться, если принять во внимание, что в более ранних версиях языка UML использовались отношения со стереотипами “uses”, “derived” и “owner”. В современных спецификациях унифицированного языка моделирования отношения с упомянутыми стереотипами отнесены к категории deprecated (дословно – обреченные, литературно – не рекомендуемые для использования). Инструментальные среды по-прежнему содержат данные отношения как предопределенные стереотипы отношений зависимости и ассоциации с целью поддержания совместимости.

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

Начиная с версии Rational Rose 2003, компания Rational Software, следуя новым спецификациям языка, представила в своей инструментальной среде отношения включения и расширения самостоятельными элементами диаграммы.

Основной ошибкой, допускаемой новичками при использовании рассмотренных типов отношений, является неверное направление стрелки, связывающей прецеденты. Обратите внимание: отношение включения направлено от базового прецедента к прецеденту, который в него включается, а отношения расширения – наоборот: от расширяющего прецедента к базовому.

Следует отметить некоторое отступление от идеи, которой служит диаграмма прецедентов и прикладными потребностями разработчиков. При разработке диаграммы прецедентов необходимо придерживаться принципа “черного ящика”, который гласит, что на данном этапе моделирования система, представленная на диаграмме совокупностью прецедентов, закрыта для изучения ее внутренних свойств. Однако, применяя отношения включения и расширения, мы движемся внутрь прецедентов, выделяем их составные части и фиксируем их в форме новых прецедентов (т.к. иных элементов диаграмма прецедентов разработчику не предоставляет). Такое “идеологическое отклонение” вызвано к жизни прикладными потребностями разработчиков, которые желают зафиксировать сервисы, которые с одной стороны не зависят от базовых прецедентов и могут быть рассмотрены обособлено, с другой стороны в контексте проекта имеют ценность, только будучи связаны с базовыми. Для иллюстрации сказанного обратимся к рис. 3.11. Прецедент “Авторизоваться” – не является сервисом, ради которого пользователь пойдет на сайт системы чтения и отправки электронной почты с использованием Web-интерфейса. Равно как и ради реализации сервиса “Авторизоваться” не будет создаваться целая система. Однако, во-первых, этот прецедент абсолютно необходим в рамках базового прецедента “Чтение и отправка почты”, что позволит системе “узнать” конкретного пользователя и предоставить ему доступ к его почтовому ящику. Во-вторых, подсистема авторизации представляет собой самостоятельную подсистему Web-сайта, которая может быть использована в других проектах.

Не следует злоупотреблять использованием отношений включения и расширения при создании диаграммы прецедентов. Зачастую это приводит к “сползанию” в функциональное разбиение системы путем введения прецедентов-функций. Подробнее этот вопрос рассматривается в разделе 3.12 “Прецеденты и функции”.

Отношение обобщения

Отношение обобщения (generalization relationship) служит для указания того факта, что некоторый прецедент A может быть обобщен до прецедента B. В этом случае прецедент A будет являться специализацией или потомком прецедента B, а B будет считаться предком или родителем прецедента A. Потомок наследует все свойства и поведение родителя и может быть дополнен новыми свойствами и особенностями поведения.

На диаграмме отношение обобщения представляется сплошной стрелкой, на конце которой располагается не закрашенный треугольник. Отношение обобщения всегда является направленным, указывая на родительский элемент, как показано на рис. 3.13.

Рисунок 3.13. Отношение обобщения между прецедентами

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

Пример использования отношения обобщения между прецедентами приведен  на рис. 3.14.

Рисунок 3.14. Пример использования отношения обобщения между прецедентами

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

Отношение обобщения может возникать и между актерами, как показано на рис. 3.15. Отношение обобщения, направленное от актера A к актеру B призвано отразить тот факт, что каждый экземпляр актера A является одновременно экземпляром актера B и обладает всеми его свойствами. В этом случае актер B является предком или родителем по отношению к актеру A, а актер A – его потомком.

 Рисунок 3.15. Отношение обобщения между актерами.

Пример использования отношения обобщения приведен на рис. 3.16. Имеется некоторая Web-ориентированная информационная система продажи товаров с использованием сети Internet. Разместить заказ посредством сайта может только зарегистрированный пользователь. Пользователь, не прошедший процедуру регистрации на сайте, может лишь просматривать каталог.

Рисунок 3.16. Пример использования отношения обобщения между актерами

Чтобы отразить на диаграмме тот факт, что зарегистрированный пользователь тоже имеет возможность просматривать каталог, введено отношение обобщения между актерами “Пользователь” и “Зарегистрированный пользователь”.

На практике отношение обобщения между прецедентами используется реже, чем отношение обобщения между актерами.

Установка границ системы

В своей работе [5] Крэг Ларман  справедливо отмечает важность корректной установки границ моделируемой сущности. Так идентифицировать внешние и внутренние свойства системы, сформулировать сервисы (прецеденты), адресованные элементам внешней среды (актерам) можно лишь предварительно установив ее границы.

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

Если в качестве моделируемой системы выбрать весь магазин розничной торговли, то в роли актера будет выступать покупатель, а кассир будет находиться внутри системы, выполняя свои производственные обязанности. Диаграмма прецедентов такой системы приведена на рис. 3.17.

 Рисунок 3.17. Прецедент и актер магазина розничной торговли

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

Рисунок 3.18. Прецедент и актер АИС магазина розничной торговли

Обратите внимание, что на рис. 3.18 отсутствует актер “Покупатель”, поскольку он непосредственно не взаимодействует с информационной системой, а значит, не является окружением системы и на диаграмме не отображается.

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

Прецеденты и функции

В литературе, посвященной объектно-ориентированному моделированию с использованием языка UML, не раз констатировался факт сложности восприятия концепции прецедентов. Прецедент – новое понятие, введенное авторами унифицированного языка моделирования. Устоявшиеся подходы к моделированию систем во главу угла ставят понятия алгоритмов, функции, диаграмм потоков данных и т.д. Возможно, именно в этом кроется основная причина ошибок, совершаемых новичками. Например, начинающим проектировщикам бывает непросто понять разницу между функцией и прецедентом. Для иллюстрации обратимся к статье Курта Биттнера (Kurt Bittner) [6] – топ-менеджера компании Rational Software.

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

Рисунок 3.19. Ошибочное решение. Прецеденты подобны пунктам меню системы или ее функциям.

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

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

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

Вернитесь к рис. 3.19 и спросите себя, хотели бы вы использовать систему, чтобы узнать информацию о заказе, который вы никогда не размещали? А изменить заказ, который вы никогда не отдавали в обработку? Разумеется - нет. Сами по себе эти возможности системы необходимы и полезны для вас только в том случае, если вы использовали систему по прямому назначению и разместили в ней свой заказ. Разложение системы на большое количество прецедентов фактически затеняет реальную цель ее создания и в ортодоксальном случае оканчивается созданием диаграммы, содержащей массу изолированных фрагментов ее поведения. В результате трудно сказать, делает ли система то, что от нее ожидают.

Принимая во внимание все вышеизложенное, корректная диаграмма должна иметь вид, приведенный на рис. 3.20.

Рисунок 3.20. Корректная диаграмма прецедентов.

Эта диаграмма охватывает все “прецеденты-функции”, на которые предыдущая диаграмма расколола приведенный на рис. 3.19 прецедент. Приведенная на рис. 3.20 диаграмма сфокусирована на полезности системы с точки зрения актера, а не на том, каким образом проектировщик делит и структурирует функциональные возможности системы. Если разработчик диаграммы раскалывает функциональность системы на отдельные прецеденты, он вынуждает заказчика, который, кстати, платит за разработку системы, повторно собирать воедино и анализировать расчлененные прецеденты, собирая их в нечто значимое для себя, чтобы понять, является ли система тем, чего он хочет и за что готов платить.

 Обилие “маленьких” прецедентов – распространенная проблема команд с выраженной тягой к функциональному разложению систем. Имена таких прецедентов читаются подобно списку функций, которые выполняет система: ввести заказ, просмотреть заказ, отменить заказ, выполнить заказ и т.д. Сначала это звучит неплохо, но дальше - больше. Даже для небольшой системы размещения заказов список формируемых таким образом прецедентов может насчитывать сотни. Двигаясь в таком направлении, команда тонет в море прецедентов, особенно если система “действительно большая”: на финише получаются сотни, а то и тысячи прецедентов.

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

Справедливости ради, следует отметить, что у описанного подхода, который можно считать классическим, поскольку базируется на положениях Rational Unified Process (RUP), есть и сторонники и противники. Речь идет о процессе ICONIX, представляющим собой нечто среднее между объемным рациональным унифицированным процессом (RUP) и весьма компактной методологией программирования eXtreme (XP). Желающие могут ознакомиться с основными положениями процесса ICONIX в работе [7].