Форма входа

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

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

Поиск

Наш опрос

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

Друзья сайта

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

    • Статистика

    Онлайн всего: 1
    Гостей: 1
    Пользователей: 0
    Среда, 24.04.2024, 18:12
    Приветствую Вас Гость
    Главная | Регистрация | Вход | RSS

    Я - Аналитик!

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

    Главная » Статьи » Архитектура предприятия » Архитектурные каркасы
    Расширение моделирования в TOGAF с использованием UML и здравого смысла
    Архитектура предприятия – это революционная идея, совершенно непохожая на что либо выдвигавшееся в разработке программных систем.
    Архитектура предприятия – это эволюционный шаг, естественным образом вытекающий из предшествующей истории. [1]
    Да. Подобные революции в науке, технике и производстве случаются с определенной периодичностью, и это, безусловно, хорошо. Грустно другое: логика революций, за редкими исключениями, направлена только на создание нового и, иногда неосознанно, на забвение хорошего старого.
     
    Что такое архитектура предприятия, если отойти от установленных технических терминов?
     
    Архитектура предприятия – это технология создания бизнеса и поддерживающих компонентов (в том числе программного обеспечения) как единой системы. Если традиционные технологии, например, RUP, поддерживали разработку программных систем, рассматривая бизнес как данность (бизнес был средой), то архитектура предприятия – это расширение объекта исследования и управления при разработке ПО, где новая среда – это, например, рынок.
    Объект, безусловно, стал сложнее. Участниками процесса стали новые люди, представляющие бизнес. Изменилась формулировка цели.
    Раньше:
    Реализовать (разработать или улучшить) программную систему, наилучшим образом поддерживающую возможности бизнеса в заданные сроки в рамках заданного бюджета.
    Теперь:
    Реализовать (разработать или улучшить) бизнес, наилучшим образом поддерживающий видение заинтересованных лиц в заданные сроки в рамках заданного бюджета.
    Может быть, эти формулировки кому-то покажутся слишком упрощенными, но скажите, что в них неправильно? В дальнейших рассуждениях мы будем отталкиваться от этих формулировок.
     
    Формулировки отличаются только границами аксиоматики: на каком уровне полученные неформальными методами пожелания (в RUP – потребности заинтересованных лиц) начинают реализовываться формальными (и неформальными) методами. Ну, а работа по реализации одна и та же: исследовать и документировать текущее состояние, исследовать и детализировать указанные на высоком уровне возможности, проанализировать расхождения между текущими и целевыми возможностями, спроектировать способы достижения целевого состояния и реализовать эти проекты. И всего то!
     

    Так к чему эти заумные рассуждения?

    А вот к чему.
     
    В индустрии программного обеспечения накоплен огромный опыт проектирования и разработки. Нет необходимости, да и возможности, перечислять все. В предполагаемом цикле статей акцент будет установлен на двух достижениях IT-шной мысли: объектно-ориентированный подход и язык UML и связанная с этим концепция управляемой моделью архитектуры (MDA).
     
    Первоначально Унифицированный язык моделирования (UML) был разработан для визуализации, специфицирования, конструирования и документирования артефактов объектно-ориентированных проектов программных систем. Сегодня UML 2 предоставляет непротиворечивый язык, который может быть использован для описания практически любых систем. Главные особенности языка, обеспечивающие эффективность его практического использования, это:
    • Акцент на семантике в противоположность нотации.
    Главное в UML – это модель, содержащая определения модельных элементов. Модельный элемент – это не картинка на диаграмме. Это объект. Установленный на диаграмму, элемент графически показывает свои свойства, и установленный на разные диаграммы элемент показывает свои свойства с различных точек зрения.
    UML – это язык моделирования, а не рисования. Фактически, в UML рисование – это удобный графический интерфейс и средство отображения содержания модели.
    • Беспрецедентная настраиваемость и расширяемость.
    Ядро метамодели UML содержит не так много элементов. Но к этим базовым элементам можно применять механизмы расширения, чтобы приспособить UML к потребностям моделирования в конкретной предметной области, технологии и даже к нуждам конкретного пользователя (этим не нужно злоупотреблять, или однажды Вас никто не поймет!). Эти механизмы – ключевые слова, стереотипы и профили. Инструментальные средства моделирования, отвечающие требованиям спецификации UML, должны включать механизмы расширения.
    Сегодня для UML2 разработано множество профилей моделирования. Разработчики инструментальных средств моделирования включают некоторые из них в свои продукты. Среди этих профилей UPDM от OMG и UPIA от IBM – это профили для моделирования архитектуры предприятия.
    Концепция управляемой моделью архитектуре базируется на следующих принципах:
    • Модели, выраженные в четкой нотации – это краеугольный камень к пониманию систем
    • Системы могут формироваться с помощью набора моделей при наложении ряда преобразований между моделями
    • Формальная поддержка описания моделей в наборе метамоделей облегчает интеграцию и преобразования и является базой для автоматизации
    • Инструментальные средства, поддерживающие MDA, должны иметь механизмы создания преобразований моделей.

    А зачем, собственно, нужно моделировать?

    1. Моделирование включает возможности увидеть объекты моделирования с высоты птичьего полета и увидеть (только) необходимые детали объектов в их спецификациях (борьба со сложностью)
    2. Инструментальные средства поддерживают целостность и непротиворечивость объектов в границах модели. Определения, включенные в модель, не будут противоречить друг другу
    3. Определение необходимых свойств объектов позволяет генерировать отчеты, документирующие актуальное состояние модели
    4. Средства преобразования моделей обеспечивают возможность создания новых модельных элементов из информации, уже содержащейся в модели, по формальным правилам (если эти правила определены)
        1. Расширение этого свойства – генерация из модели кода программного обеспечения (код на языке высокого уровня – это тоже модель!)
    О такой роли моделей, как предоставление языка для общения, можно и не говорить.

    TOGAF и моделирование

    Предполагается, что если Вы заинтересовались этим материалом, то Вы, в какой-то мере, знакомы с TOGAF. Тем не менее, прочитайте этот краткий обзор. Он представляет отношение автора публикации.
     
    TOGAF (The Open Group Architecture Framework) – это каркас архитектуры предприятия и жизненный цикл разработки и развития архитектуры предприятия, включая, в частности, и разработку и развитие ПО.
     
    Преимуществом TOGAF по сравнению с другими архитектурными каркасами (например, DoDAF) является его применимость к предприятиям практически любой сферы деятельности и возможность использования любых методик и инструментов, обеспечивающих получение определенных в TOGAF рабочих продуктов.
     
    С другой стороны, для практиков архитектуры эта сверхобщность TOGAF и отсутствие конкретики в мелочах является серьезным препятствием в использовании и, часто, является причиной разочарования в TOGAF вообще.
     
    Поставщики инструментальных средств, включающих в свои продукты моделирование TOGAF, как правило, не уделяют внимания методологическим вопросам, а только реализуют возможности моделирования элементов и диаграмм, рекомендуемых как рабочие продукты TOGAF.
     
    Физически TOGAF представлен в виде книги (778 страниц, 6 основных частей, называемых компонентами, + Предисловие, и 52 главы) и дополнительных материалов (шаблоны и примеры рабочих продуктов, учебные презентации и т.д.).
     
    Главных частей, наверное, две:
    Часть II, ADM – содержит описание метода разработки архитектуры (Architecture Development Method), и
    Часть V, Enterprise Continuum and Tools – содержит описание информационного наполнения TOGAF, в частности – рабочих продуктов.
    Другие части содержат комментарии и рекомендации по работе с ADM и информацией.
     
    ADM представляет процесс, состоящий из девяти фаз и процесса управления требованиями (см. рисунок 1).
     
     
    Цикл
    Рисунок 1. Метод разработки архитектуры TOGAF.
     
    Описанию каждой фазы посвящена отдельная глава. Структура глав одинакова:
    • Стремления
    • Подход
    • Исходная информация
    • Шаги
    • Выходная информация
    TOGAF описывает информационное наполнение архитектуры предприятия (рабочих продуктов, архитектурных артефактов, архитектурных поставок и компоновочных блоков), но не накладывает никаких ограничений на способы представления этой информации (правда, есть примеры и шаблоны текстовых документов) и, по большей части, на способы ее получения. Что касается использования моделей, то речь идет только о возможности представления иллюстративных графических материалов в самых разных нотациях, а то и вообще без всяких правил [2] . Термин "архитектурная модель" вообще не определен, а словосочетание используется для обозначения полного информационного наполнения архитектуры.
     
    В некоторых случаях, применение графики прямо не рекомендуется в связи со слабой формализуемостью явления. К таким явлениям-изгоям относится, в частности, управление заинтересованными лицами (TOGAF, глава 24).
    Вот с моделирования управления заинтересованными лицами мы и начнем в следующем выпуске расширение моделирования архитектуры в TOGAF.
     
    [1] Эта "почти цитата" заимствована из книги Timothy Budd "Объектно-ориентированное программирование в действии", 1997, где слово "ООП" заменено на "Архитектура предприятия", а слово "программирование" – на "разработка программных систем".
     
    [2] Кстати, тот факт, что в самом документе спецификации изредка встречаются разночтения, говорит о том, что и единой модели TOGAF (в том понимании, которое представлено выше) тоже не существует.

     
     
     
    Категория: Архитектурные каркасы | Добавил: lnew (09.12.2010)
    Просмотров: 3525 | Рейтинг: 0.0/0
    Всего комментариев: 0
    Имя *:
    Email *:
    Код *: