Структура модели UPIA

Вначале Бог сотворил небо и землю. Земля была безвидна и пуста, только Дух проносился над водами.
И сказал Бог: да будет свет! И стал свет.
И увидел Бог, что свет хорош, и отделил свет от тьмы.
И назвал Бог свет днем, а тьму ночью.
И был вечер, и было утро: день первый.

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

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

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

Если Вы посмотрите на дерево структуры проекта в представлении Project Explorer, Вы увидите некоторые новые стереотипы, которых нет в базовом UML2.

Рисунок 1: Структура проекта (по умолчанию).

Модель предприятия (Enterprise model)

Модель предприятия – это расширение элемента Package (UML2).

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

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

Модель предприятия может содержать один или более пакетов Описание архитектуры. Эти пакеты служат для декомпозиции модели согласно удобной Вам классификации, например, "как есть" и "как будет".

Описание архитектуры (Architecture Description)

Описание архитектуры – это также пакет UML2. Его назначение описано выше.

Модель предприятия должна содержать не менее одного пакета описания архитектуры.

Представление (View)

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

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

Точка зрения (Viewpoint)

Точка зрения – это расширение элемента Class (UML2)

Точка зрения – это набор соглашений для конструирования, интерпретации и анализа модели с позиции семейства заинтересованных лиц[2].

• Точка зрения – это шаблон для конструирования Представления (см. выше)
• Точки зрения определяют правила для представлений. Нет никакого установленного языком набора точек зрения
• Каждая точка зрения в описании архитектуры должна быть "объявлена" перед ее использованием

Точка зрения может также включить:

• Проверки соответствия или комплектности, связанные с основным методом, который будет применен к моделям в пределах представления
• Методы оценки или анализа, которые будут применены к моделям в пределах представления
• Эвристики, шаблоны или другие рекомендации, которые помогут в синтезе связанного представления или его моделей

Для каждой точки зрения определяются Интересы заинтересованных лиц, которые будет поддерживать точка зрения

Рассуждение о точках зрения и представлениях

Определения точки зрения и представления в UPIA соответствуют стандарту ISO/IEC 42010:2007. Некоторую дополнительную информацию вы можете получить в разделе Заинтересованные лица в UPIA в статье цикла Моделирование в TOGAF с использованием UML и здравого смысла[3].

Вообще, формально дело обстоит следующим образом:

С самого начала архитектурной работы идентифицируются ключевые лица, заинтересованные в архитектуре. Это те, для кого делается вся работа. Идентифицируется архитектурная информация, интересующая каждое заинтересованное лицо. (Архитектор должен удовлетворить Интересы заинтересованных лиц. Иначе он не получит от них никакой поддержки. А могут и выгнать!). Архитектор анализирует и группирует интересы так, чтобы удовлетворить заинтересованных лиц и не загружать не интересующей информацией. Так определяются Точки зрения, одинаковые для групп заинтересованных лиц. В точках зрения архитектор определяет способы представления нужной информации, алгоритм, фильтры и т.д., т.е Метод точки зрения. Для каждой точки зрения создается пакет (Представление), где и собирается вся необходимая информация.

Если бы так происходило всегда, архитектор, скорее всего, сошел бы с ума! Разработчики архитектурных каркасов (TOGAF, DoDAF и других) уже, по большей части, сделали эту работу. Например, в TOGAF представлен пример классификации заинтересованных лиц с их интересами и точками зрения. Аналогичную работу проделали авторы IBM RSx: представленный в этой статье шаблон содержит пакеты представлений и классы точек зрения[4].

Я поступаю следующим образом: У меня создан отдельный проект моделирования под названием MyReferenceLibrary, в котором храниться несколько переработанная модель "Заинтересованные лица – Интересы – Точки зрения – Шаблоны представления информации".

В конкретных проектах моделирования создаются только представления для хранения результатов обработки информации в соответствии с шаблонами. Несколько больше об этой "кухне" – в последующих выпусках обоих циклов.

Резюме архитектуры (Architecture Summary)

Резюме архитектуры – это экземпляр класса ArchitectureSummary из библиотеки профиля UPIA Model Library (или его специализации).

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

Класс ArchitectureSummary имеет набор атрибутов, значения которых определяются (не сразу) в процессе моделирования^[5]. Некоторые из них, например, analysisResult и recommendations, вообще могут быть определены  только на завершающем этапе моделирования.

Пакет Описание архитектуры должен иметь ссылку к экземпляру Резюме архитектуры.

Вопросы русификации

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

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

С другой стороны, все современные инструменты позволяют использовать русский язык для документирования моделей и модельных элементов.

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

Использование алиасов

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

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

Алиасы не могут использоваться в представлении Project Explorer.

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

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

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

Специализации классов

Достаточно часто для русификации можно использовать специализации классов библиотеки UPIA. На рисунке внизу показан пример специализации:

Рисунок 2: Пример специализации класса.

На рисунке 2 класс Резюме архитектуры[6] – это специализация класса ArchitectureSummary.

Обратите внимание, что класс Резюме архитектуры имеет некоторые дополнительные атрибуты, которые можно использовать для генерации представления AV-1 MODAF.

Переименование существующих элементов шаблона

Совершенно естественно, что шаблоны проектов, включенные в RSx, представлены на английском языке, и, может быть, придется затратить некоторое время на переименование элементов[7].

На рисунке показана диаграмма структуры архитектурного описании предприятия "Поиск и спасение":

Рисунок 3‑4: Структура архитектурного описания (на русском языке).