Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Otvety.docx
Скачиваний:
291
Добавлен:
11.03.2016
Размер:
22.4 Mб
Скачать

Вопрос 3. Модели доменов. Общие понятия и принципы

Классификация моделей:

  • формальные (использующие общепринятые правила, нотации и средства) и неформальные;

  • количественные (математические, динамические), позволяющие производить численные оценки и проверки;

  • качественные (текстовые, визуальные), предназначенные для понимания поведения и структуры системы;

  • описательные – предназначены только для восприятия человеком,

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

На каждом уровне абстракциимогут использоваться динамические и статические модели. Разработка моделей для различных доменов является итерационным процессом, связанным с рассмотрением различных уровней абстракции и связей между моделями отдельных доменов архитектуры. Например, на верхнем уровне описания контекста могут использоваться списки бизнес-сущностей (таких как "счет", "клиент" и т.д.), для архитектуры прикладных систем нужен список основных бизнес-процессов, а для технологической архитектуры – информация о местах расположения бизнеса. По мере детализации вместо списка бизнес-сущностей создаются семантические, логические и физические модели данных. Эти модели описывают архитектуру предприятия на различных уровнях абстракции (взгляды различных категорий людей).

Модели различных представлений и уровней

Принципы построения моделей

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

Пример моделей он-лайновой системы выполнения заказов магазином

Концептуальный уровень абстракции - динамическая модель взаимодействия между клиентом и магазином. Проектируемая система - как "черный ящик". Клиент и сотрудники магазина – внешние объекты. Весь процесс рассматривается с точки зрения клиента и сотрудника:

  • клиент осуществляет заказ через Интернет;

  • оплата выполняется с помощью кредитной карты;

  • заказ посылается по указанному адресу;

  • уведомление о выполнении заказа посылается по электронной почте.

Вопрос 4. Архитектура ит

Архитектура ИТ основана на потребностях бизнеса, ориентирована на будущие потребности и сфокусирована на прикладных системах. IT – архитектура - технологическая архитектура, определяющая инфраструктуру информационных систем.

Элементы описания архитектуры ИТ

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

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

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

  4. Процедуры.Процедуры – это инструкции, описывающие, как выполняются политики и стандарты. Процедуры устанавливают и описывают процессы, которые выполняются на регулярной основе.

  5. Руководства или рекомендации(guidelines). Руководства и рекомендации – это описания лучших практик или приемлемых подходов к практической реализации политик и процедур. Руководства могут стать стандартами.

Для описания "верхней" части этой пирамиды используются, в основном, декларируемые принципы."средняя"часть пирамиды, т.е. непосредственно архитектура, описывается в форме набора соответствующих моделей. «Нижняя»часть пирамиды связана с выработкой соответствующих правил, процедур или выбором стандартов. Т.е. ключевыми понятиями являются принципы, стандарты и модели. Стандарты разрабатываются на основе принципов и описывают, как принципы будут реализованы на практике.

Принципы создания архитектуры ИТ

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

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

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

Принципы и модели

Существуют два различных подхода к процессам разработки, описания и использования архитектуры предприятия:

  • основой архитектуры являются принципы,

  • основой архитектуры является процесс создания моделей.

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

Для второго подхода. Организация META Group полагает, что при описании существующей архитектуры (архитектуры "как есть") необходимо в большей степени руководствоваться декларациями принципов, на основе которых она построена; в то же время, будущие состояния архитектуры должны описываться с использованием соответствующих моделей, описывающих отдельные представления (домены) будущей архитектуры.

Стандарты

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

При разработке и использовании стандартов нужно учитывать следующие аспекты:

  1. Уделять большее внимание тем стандартам, которые обеспечивают эффективное использование базовых технологий, на которых построены многие системы и которые стали индустриальными стандартами. Примерами таких технологий для организаций являются XML, NET, Java (рассматриваемая не как язык, а как среда разработки).

  2. Определять стандарты процессов. Примерами являются процессы бизнес- моделирования, методы разработки систем, тестирования, интеграции.

  3. Уделять внимание интерфейсам. Понимание интерфейсов является основой для интеграции систем.

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

  5. Для того чтобы быть эффективным инструментом, стандарты должны включать списки конкретных версий технологий, интерфейсов программирования (API), утилит и т.д. Примерами могут быть версии систем управления базами данных, версии XML и т.п.

  6. Стандарты должны включать способы проверки на соответствие.

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

Руководства (рекомендации)

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]