Принципы моделирования с использованием UML

Язык UML основан на некотором числе базовых понятий, которые могут быть изучены и применены большинством программистов и разработчиков, знакомых с методами объектно-ориентированного анализа и проектирования.

В основе моделирования с использованием UML лежит ряд ключевых принципов.

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

Принцип многомодельности, который сводится к утверждению о том, что никакая отдельно взятая модель не может с достаточной степенью адекватности описать различные аспекты сложной системы. Применительно к UML это означает, что достаточно полная модель сложной системы допускает некоторое число взаимосвязанных представлений (views), каждое из которых адекватно отражает некоторый аспект поведения или структуры системы. Интегрированная модель сложной системы представляется в виде совокупности диаграмм, приведенной на рис. 2.1.

Рис. 2.1. Интегрированная модель сложной системы в нотации UML

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

 

Рис. 2.2. Взаимосвязь представлений модели системы в процессе объектно-ориентированного анализа и проектирования

Процесс построения отдельных типов диаграмм имеет свои особенности, которые тесно связаны с семантикой диаграмм. Процесс ООАП в контексте языка UML получил специальное название – рациональный унифицированный процесс (Rational Unified Process - RUP). Концепция RUP и основные его элементы отражены в [2].

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

Результат моделирования

Результат моделирования зависит от класса моделируемой системы и цели, которую преследуют разработчики. В самом ортодоксальном случае результатом моделирования будет являться серия взаимосвязанных диаграмм, относящихся к различным уровням представления системы, снабженная подробной документацией и отчетами, создаваемыми инструментальными средствами поддержки. Более того, когда речь идет о создании автоматизированной информационной системы, возможна генерация каркаса программного кода на объектно-ориентированном языке программирования (в частности, такая возможность реализована в CASE-средстве Rational Rose).

 

Диаграмма прецедентов

Общие сведения

Диаграмма прецедентов (use case diagram) относится к концептуальному представлению системы, описывая назначение системы. Она разрабатывается для достижения следующих целей:

· определить границы и контекст моделируемой системы;

· сформулировать требования к поведению системы;

· создать и зафиксировать исходное концептуальное представление системы с целью его последующей детализации в форме логических и физических моделей;

· подготовить набор артефактов, используемых разработчиками системы для общения с ее заказчиками и будущими пользователями.

Основная идея состоит в представлении системы посредством совокупности прецедентов (use cases) – сервисов, адресованных конкретным потребителям. Любую сущность, взаимодействующую с системой извне, и являющуюся потребителем адресованного ей сервиса называют актером (actor). В роли актера может выступать человек, техническое устройство, программа, или другая система, служащая источником воздействия на моделируемую систему. С внутренней точки зрения прецедент представляет собой совокупность действий, выполняемых системой в ответ на запрос актера и приводящих к значимому для актера результату. При этом соблюдается принцип “черного ящика” – никакой информации о том, каким именно образом реализуется взаимодействие актера и системы, на диаграмме не приводится.

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

Прецеденты

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

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

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

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

 

Рисунок 3.1. Эквивалентные прецеденты.

В некоторых русскоязычных изданиях прецеденты называют вариантами использования.

Актеры

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

Стандартным обозначением актера является пиктограмма приведенная на рисунке 3.1, под которой располагается имя актера. Инструментальные среды позволяют изменять внешний вид пиктограммы актера, путем наложения на него стереотипов.

Имя актера начинается с заглавной буквы. Часто имена актеров совпадают с должностями, занимаемыми сотрудниками в организации. Например, кассир, продавец, менеджер, руководитель предприятия. Такая ситуация типична для многопользовательских информационных систем, включающих в себя АРМы, ориентированные на использование сотрудниками соответствующих подразделений. Однако, ключевым принципом в формировании имени актера безусловно является роль, которую он играет по отношению к системе. Из этого вытекает необходимость использовать в качестве имени актера нарицательные существительные, а не имена собственные. Во-первых, трудно представить, чтобы кто-либо играл по отношению к системе роль “Иван Грозный”. Во-вторых, получаемая в результате модель оказывается не привязанной к персоналиям. Например, сотрудник банка с фамилией Иванова в настоящий момент выступает по отношению к системе в роли операциониста, внося в нее сведения о клиентах банка и состоянии их счетов. На следующей неделе сотрудник Иванова продвинется по службе и займет пост начальника отдела. Отныне ей будут требоваться сводки и документы итоговой отчетности. Создаваемая диаграмма не должна утратить своей актуальности, поэтому в модель будут введены актеры, имена которых звучат как “Операционист” и “Руководитель отдела”.

Так как актер находится вне системы, его внутренняя структура никак не определяется, принципиально лишь выделять его роль по отношению к системе.

В некоторых русскоязычных изданиях можно встретить перевод термина “actor” как “действующее лицо” или “актор”.