Форма входа

Категории раздела

Моделирование интегрированной архитектуры [8]
UPIA и связанные материалы
Архитектурные каркасы [3]
TOGA, DoDAF и т.п.
Размышления о концепции интегрированного моделирования предприятия [3]
Статьи о разработке технологии интегрированного моделирования и управления предприятием

Поиск

Наш опрос

Интересны ли Вам статьи цикла "Повышение производительности аналитика"?
Всего ответов: 25

Друзья сайта

  • Официальный блог
  • Сообщество uCoz
  • FAQ по системе
  • Инструкции для uCoz
  • Статистика


    Онлайн всего: 1
    Гостей: 1
    Пользователей: 0
    Четверг, 28.03.2024, 13:43
    Приветствую Вас Гость
    Главная | Регистрация | Вход | RSS

    Я - Аналитик!

    Каталог статей

    Главная » Статьи » Архитектура предприятия » Моделирование интегрированной архитектуры

    Моделирование интегрированной архитектуры (8)

    Простой пример моделирования возможности

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

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

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

    "Исходный" термин Возможность описан в четвертой статье цикла.

    Конфигурация возможностей (Capability Configuration)

    CpblConf 

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

    Формально, Конфигурация возможностей должна конфигурировать не менее одной Возможности. На практике удобнее для каждой Возможности иметь одну (собственную) Конфигурацию возможностей.

    Конфигурация возможностей указывает на Ресурсы и Организационные ресурсы, которые используются конфигурацией для обеспечения Возможности (отношения Used by Configuration).

    Конфигурация возможностей указывает на Организационный ресурс, который управляет конфигурацией (отношение Manages Configuration).

    Конфигурация возможностей должна управляться в соответствии с Доктриной.

    Использование возможности (Capability Usage)

    CaplUsage 

    Использование возможности – это элемент операционной модели.

    Каждое Использование возможности описывает один способ, которым Возможность поддерживает Стратегические миссии предприятия.

    Использование возможности определяет кооперацию исполнителей (Роли возможности, Операционные узлы и Системы), которые взаимодействуют при осуществлении Возможности специфическим способом. Взаимодействия между исполнителями определяются Реализацией возможности.

    Использование возможности может определять Требования для использования возможности, Цели этого использования и поддерживаемые Стратегические миссии.

    Реализация возможности (Capability Realization)

     

    Реализация возможности – это элемент операционной модели.

    Реализация возможности описывает, как взаимодействуют исполнители (Роли возможности, Операционные узлы и Системы) для реализации Использования возможности.

    В операционной модели эти взаимодействия определяются Следами операционных событий (взаимодействием UML и его диаграммой последовательности) или Операционной деятельностью (деятельностью UML), а в системной модели – Следами системных событий и Функциями системы (действиями).

    Сообщения в следах событий и ребрах потока информации в деятельностях используются для генерации необходимых обменов ресурсами (Обмен информацией или Обмен данными).

    Операционный узел (Operational Node)

    OpNode 

    Операционный узел – это элемент операционной модели.

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

    Операционный узел выполняет действия, необходимые для реализации возможностей предприятия. Это достигается вызовом Операционных задач (операций), которые принадлежат Операционному узлу. Каждая Операционная задача – это спецификация связанного поведения, которое описано моделями деятельности (Операционнfz деятельностm), принадлежащими Операционному узлу.

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

    Операционный узел должен быть размещен в одном или более Системном агрегате.

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

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

    Системный агрегат (System Assembly)

     

    Системный агрегат – это элемент модели развертывания.

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

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

    Рассмотрим моделирование возможности на простом примере возможности Мониторинг обстановки.

    Представления возможности Мониторинг обстановки

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

    Далее, на концептуальной диаграмме (рисунок 4) показано, что функция мониторинга обстановки возложена на Узел мониторинга, который, после получения сигнала бедствия снабжает Центр контроля и управления информацией слежения за объектом, терпящим бедствие.

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

     

    Рисунок 1. Представления модели возможности Мониторинг обстановки в архитектурных моделях предприятия.

    Диаграмма сознательно упрощена. На ней представлены только главные элементы (описанные выше), представляющие возможность непосредственно. С этой целью модельные элементы изображены на фоне пакетов архитектурных моделей, каждая из которых представляет один архитектурный аспект (представление)[1].

    Моделирование деятельности

    Возможность Мониторинг обстановки реализует операционный узел Узел мониторинга (см. рисунок 1, внизу слева). Выше указано, что моделирование поведения операционного узла выполняется с использованием модельных элементов Операционная задача и Операционная деятельность, Кроме того, для моделирования деятельности Узла мониторинга нам потребуется модельный элемент Информационный элемент.

    Операционная задача (Operational Task)

     

    Операционная задача – это элемент операционной модели.

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

    Связанное поведение для Операционной задачи может быть Операционной деятельностью (UML Activity), Следом операционного события (UML Interaction) или Следом операционного состояния (UML StateMachine). Это поведение должно принадлежать тому же узлу, которому принадлежит Операционная задача.

    Операционная деятельность (Operational Activity)

     

    Операционная деятельность – это элемент операционной модели.

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

    Спецификацией для поведения должна быть Операционная задача, которая принадлежит тому же узлу, который имеет это поведение.

    Информационный элемент (Information Element)

     

    Информационный элемент – это элемент операционной модели.

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

    Информационный элемент может использоваться в одном или более Обменах информацией.

    Информационные элементы могут иметь отношения с другими Информационными элементами. Эти типы отношений можно показать на диаграмме классов. В модели UPIA Информационные элементы и их взаимосвязи определяют Логическую модель данных.

    Модель операционной деятельности Узла мониторинга

    Давайте вернемся к диаграмме на рисунке 1.

    Обратите внимание, что Узел мониторинга имеет три операционных задачи, две из них – приватные, и одна – публичная. Кроме того, на диаграмме представлена Операционная деятельность Мониторинг, принадлежащая узлу.

    На следующем рисунке представлена диаграмма операционной деятельности Мониторинг:

     

    Рисунок 2. Диаграмма деятельности Мониторинг.

    Как это работает?

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

    В случае обнаружения объекта Операционная задача Идентификация цели выполняет необходимую обработку информации и "возвращает" значение целеуказания, не прекращая при этом сканирования обстановки.

    Значение целеуказания – это экземпляр Информационного элемента (класса) Целеуказание (на диаграмме рисунок 1 элемент Целеуказание не показан).

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

    В следующем выпуске мы рассмотрим более сложный пример моделирования возможности и введем некоторые новые типы модельных элементов.



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

    Категория: Моделирование интегрированной архитектуры | Добавил: lnew (19.03.2011)
    Просмотров: 3566 | Комментарии: 1 | Рейтинг: 5.0/1
    Всего комментариев: 0
    Имя *:
    Email *:
    Код *: