AllFusion Component Modeler (ранее Paradigm Plus) - UML модели на все сто! - Программные продукты

Козодаев А.А.

Введение

AllFusion Component Modeler (ACM) является инструментом для моделирования системы полностью соответствующей спецификации UML версии 1.3. Однако на этапе сбора требований к проекту это соответствие оборачивается некоторыми неожиданными эффектами. В этой статье мы обсудим эти эффекты на примере Области Имен (Namespaces), Пакетов (Packages) и Разрешений (Permissions). Будут предложены некоторые подсказки и хитрости как работать с ACM и при этом избегать данных эффектов.

Области имен

Предположим, что вы вовлечены в разработку системного проекта для компании по прокату автомобилей. Наша цель - построить систему, которая будет поддерживать этапы заказа, резервирования и управления автопарком. Проект только начался и сейчас идет стадия сбора бизнес требований к проекту и их документирования. После общения с конечными пользователями, пытаясь понять бизнес заказчика, вы обнаруживаете множество концепций (понятий), которые можно выделить в классы: Авто, ТипАвто, Покупатель, Резервирование, Контракт и т.д. В итоге прогресса фазы сбора требований наши концепции все более проясняются, обнаруживается связь между ними, и мы решаем задокументировать наше видение системы в модели под названием "ПрокатАвтоБизнесМодель".

В результате ясного понимания количества понятий мы решаем разбить их по функциональному признаку. Рисунок 1 показывает нам, что понятия Авто и ТипАвто отнесены к функциональной области под названием МеханизмМдт, Резервирование включено в РезервированиеМдт и Контракт и Заказ отнесены к ЗаказМдт.

Рисунок 1 - бизнес концепции и функциональные области

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

Рисунок 2 - бизнес концепт диаграмма

В чем же причина? По-видимому, в том, что элемент Заказ не входит в пространство имен пакета МеханизмМдт! Рассмотрим некоторые фрагменты спецификации UML версии 1.4, которая объясняет UML описание пакетов (packages) и пространств имен (namespaces):

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

Элементы с именами, которые принадлежат одному и тому же пакету должны иметь уникальные имена в пределах пакета, однако элементы из различных пакетов могут иметь одинаковые имена. Возможны связи между элементами, содержащимися в одном пакете, а также между элементом из одного пакета и элементом из родительского пакета любого уровня. Другими словами элемент видит все вложенные уровни пакетов. Элементы в пакетах одного уровня, однако, инкапсулированы и априори не видимы друг другу. Тоже относится и к элементам вложенных пакетов (дочерних пакетов). Элементы других пакетов могут быть доступны путем импортирования/организации доступа к этим другим пакетам.

Зависимость импорт (зависимость разрешения со стереотипом ‘импорт’) одного пакета с другим означает то, что первый пакет импортирует все элементы с необходимой видимостью второго пакета.

Когда элемент импортирован в пакет, он расширяет пространство имен данного пакета (пакет не включает в себя импортируемый элемент).

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

Зависимость доступ (зависимость разрешения со стереотипом ‘доступ’) подобна зависимости импорт в том, что она делает элементы пакета поставщика доступными для пакета клиента. Однако в данном случае ни один из элементов пакета поставщика не включается в область имен пакета клиента. Элементы просто ссылаются на свое полное имя в случае ссылки на них в пакете-клиенте. [UML 1.4]

Итак, UML определяет то, что элементы модели в пакете МеханизмМдт могут ‘видеть’ друг друга, они принадлежат одному пространству имен. На диаграмме расположенной в пакете МеханизмМдт классы Авто и ТипАвто могут ссылаться просто на свои имена, потому что они находятся в одном пространстве имен. В случае если пакет МеханизмМдт будет иметь дочерний пакет, тогда классы не будут видны по умолчанию. Однако, диаграмма расположенная в этом дочернем пакете будет иметь классы Авто и ТипАвто в своей области имен и будет ссылаться на них по имени. Также по умолчанию ссылка на класс Заказ не может быть произведена просто по имени, так этот класс принадлежит тому же уровню пакета.

Разрешения (Permissions)

Класс Заказ представлен на нашей диаграмме своим полным именем, так как существует зависимость доступ из пакета МеханизмМдт для пакета ЗаказМдт. Однако совместима ли до сих пор наша модель с моделью UML? Да, это действительно так! Мы получили некоторый выигрыш от той тяжелой работы, которую незаметно выполняет ACM. На рисунке 3 мы видим, что во время перетаскивания класса Заказ с помощью техники Drag & Drop на диаграмму, АСМ создал зависимость доступ из пакета МеханизмМдт в пакет ЗаказМдт. Таким образом, мы удостоверяемся в том, что наша модель полностью соответствует спецификации UML.

Рисунок 3 - зависимость доступ

Зависимости пакета и свойства видимости элементов модели внутри пакета важны при моделировании систем с точки зрения реализации (видимость элементов модели не рассматривается в данном документе). Эти концепции эквивалентны синтаксическим и семантическим конструкциям в некоторых других языках, например конструкция ‘импорт’ в Java. На этапе сбора требований и даже на этапе моделирования спецификаций это далеко не так важно. Пакеты часто представляются как вспомогательные средства для классификации и с точки зрения видимости все элементы должны быть видны отовсюду.

Итак, вернемся к АвтоПрокатБизнесКонцептДиаграмма диаграмме, где мы бы хотели избавиться от полного имени для класса Заказ, так как это не существенно в нашем случае. Как вы можете предположить, это может быть легко сделано путем изменения зависимость доступ на зависимость импорт. Таким образом, пространство имен ЗаказМдт добавляется к пространству имен и на класс Заказ можно сослаться по его имени. Используя окно свойств, мы изменяем стереотип разрешения на импорт. Затем правой клавишей щелкаем на объекте диаграммы Заказ, выбираем ‘View’ и ‘Refresh’ и видим изменения на диаграмме. Это показано на рисунке 4.

Рисунок 4 - эффект применения зависимости импорт на бизнес концепт диаграмме

Доступ к элементам в других моделях

Так как сегодняшние системы больше не строятся с самого начала, по возможности необходимо повторно использовать результаты предыдущих проектов. Давайте предположим, что компания по прокату автомобилей уже выполнила проект, автоматизирующий собственную систему оформления заказов. На рисунке 5 показана наша рабочая область после импортирования ОплатаБизнесКонцепт модели. Здесь документирован пакет ПокупательМдт, который содержит концепции, к примеру Покупатель, и мы хотим их повторно использовать.

Рисунок 5 - элементы для повторного использования из других моделей

Рисунок 6 показывает нам результат, после того как мы перенесли класс Покупатель из ОплатаБизнесКонцептМодель на нашу диаграмму. Мы вновь наблюдаем, полное имя элемента, потому что по умолчанию ACM создает зависимость доступ из пакета МеханизмМдт в пакет ПокупательМдт. Изменение зависимости доступ на зависимость импорт позволяет нам избавиться от полного имени, как это обсуждалось ранее.

Рисунок 6 - перетаскивание элемента с другой модели

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

Давайте взглянем, что говорится в спецификации UML о моделях:

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

Связи между элементами различных моделей не имеют семантического влияния на содержание этих моделей из-за самодостаточности моделей. Однако, они полезны для отслеживания улучшений и для хранения изменений требований между моделями [UML1.4]

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

Глядя на рисунок 7, мы видим, что ACM не нарушил спецификации UML путем создания связи между моделями. Вместо этого во время перетаскивания класса Покупатель на диаграмму локальная копия данного элемента была создана вместе с копией пакета, которому этот элемент принадлежит. Именно так как требует UML спецификация, класс Покупатель на нашей диаграмме является элементом нашей собственной модели. Более того, для того чтобы быть в состоянии отслеживать источник (происхождение) элемента этой модели ACM создал абстракцию трассировки (trace abstraction) между двумя моделями.

Рисунок 7 - связь между моделями

Использования дот-нотации (the dot notation)

Мы увидели представление дот-нотации когда мы перетащили один из элементов пакета на диаграмму. Во время создания новых классов данная дот-нотация может быть использована для определения пакета, которому будут принадлежать вновь созданные элементы модели. Давайте убедимся в этом!

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

Выпадающий список будет показывать только те элементы, которые принадлежат данной диаграмме. Он не будет показывать все элементы модели, добавленные в пространство имен через зависимости импорт (из-за соображений производительности). В текущий момент пространство имен пакета МеханизмМдт состоит из классов Авто, ТипАвто, Заказ, Контракт, Покупатель. Когда вы наберете одно из этих имен, тогда существующий элемент модели будет размещен на диаграмме. Если вы впечатаете Резервирование, то будет создан новый класс Резервирование в пакете МеханизмМдт так как в нем нет зависимости импорт с пакетом РезервированиеМдт (т.е. Резервирование не принадлежит пространству имен пакета МеханизмМдт). С другой стороны, если вы впечатаете РезервированиеМдт::Резервирование тогда существующий класс будет помещен на диаграмму. В это же самое время ACM создаст зависимость доступ к пакету РезервированиеМдт. Когда вы хотите избавиться от имени пакета, то вам необходимо изменить стереотип разрешения на импорт и обновить текущую диаграмму.

Рисунок 8 - создание нового элемента на диаграмме

Заключение

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