АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
 Скачать 4.65 Mb.
|
Ключевым элементом рассматриваемого фреймворка является методика ADM, в соответствии с которой процесс разработки архитектуры разбивается на 9 фаз (рис. 9.9). ADM реализует итерационный процесс проектирования на двух уровнях. На верхнем уровне для каждой итерации повторяются действия, определенные на каждой из фаз, а на нижнем уровне реализуются итерации внутри отдельных фаз. Все решения принимаются исходя из текущих требований бизнеса и имеющихся решений. Рис. 9.9. Фазы процесса разработки архитектуры В таблице 9.1 представлена характеристика фаз процесса разработки архитектуры. Таблица 9.1 Характеристика фаз процесса разработки архитектуры
Каждая фаза, в свою очередь разбивается на этапы (Steps),которые, в свою очередь, могу разбиваться на еще более мелкие шаги. Для каждого этапа определяются решаемые задачи, входные данные и выходные артефакты. Например, фаза В включает следующие основные этапы: выбор эталонной модели, видов и инструментальных средств; формирование архитектурных описаний текущей и целевой архитектур; проведение анализа расхождений (gap analysis); разработка плана действий по переходу на новую архитектуру; проведение согласования со всеми заинтересованными сторонами; корректировка плана действий по результатам взаимодействия с заинтересованными сторонами; документирование архитектуры. Основными сферами применения TOGAF являются крупные организации, при этом TOGAF может использоваться как единственный фреймворк, так и совместно с другими фреймворками, которые ориентированы на конкретные предметные области, такие как оборона, финансы, здравоохранение. В состав TOGAF, в частности, входит отдельный документ, поясняющий соответствие между понятиями TOGAF и фреймворком Захмана. Если сравнивать TOGAF и фреймворк Захмана, то просматривается различие в подходах. Если фреймворк Захмана ориентирован на описание некоторой конкретной архитектуры и в его основе лежит таксономия, то в основе TOGAF лежит понятие архитектурного континиума, т.е. архитектура постоянно находится в процессе изменения, отслеживая изменения бизнес-требований, поэтому на первый план выходит ADM. 9.6. Другие архитектурные фреймворки К настоящему времени предложено большое большое количество разных, в частности архитектурных фреймворков, основные из которых были описаны выше. В данном параграфе кратко описываются еще несколько достаточно давно разработанных архитектурных фреймворков, которые оказали значительное влияние на формирование архитектурного подхода к проектированию ИС. Эталоннаямодельраспределеннойобработки (The Reference Model for Open Distributed Processing, RM-ODP). RM-ODP – это архитектурный фреймворк, разработанный ISO (International Organization for Standardization) и ITU (International Telecommunication Union). В рамках RM-ODP представляет собой архитектурную модель, которая была принята в качестве стандарта (ISO10746-1998). Эта модель относится, в первую очередь, к распределенным объектно-ориентированным системам, но может использоваться и применительно к другим типам распределенных систем. RM-ODP – это достаточно общая модель, которая может использоваться как мета архитектурная модель. Архитектурные виды, определяемые данной моделью, приведены на рис. 9.10.
Рис. 9.10. Архитектурные виды RM-ODP В рамках рассматриваемого фреймворка определены следующие архитектурные виды: корпоративный вид (Enterprise view), информационный вид (Information view), системный вид (System view), конструктивный вид (Construction view) и технологический вид (Technology view). Каждому из перечисленных видов соответствует собственная объектно-ориентированная модель. Основной целью RM-ODP является создание архитектур, не зависимых от платформы с целью построения оптимальной системы с точки зрения реализации нефункциональных характеристик. Корпоративный вид – это бизнес модель или модель требований, предъявляемых к проектируемой системе. Информационный вид описывает структуру и смысл обрабатываемой информации, а также способы ее обработки. Системный вид определяет внутренние и внешние интерфейсы разрабатываемой системы. Конструктивный вид определяет, каким образом реализуются распределенные взаимодействия между подсистемами с целью реализации требуемой функциональности. Технологический вид определяет способы реализации описанных выше моделей [99]. 4+1 модель.Это один из старейших фреймворков, который был предложен еще в конце 90-х годов как часть унифицированного процесса разработки ПО (Unified Software Development Process [118]. На рис. 9.11 показаны 5 архитектурных видов, определенных в рамках данного фреймворка.
Рис. 9.11. 4+1 модель. Архитектурные виды Сначала использовалось 5 архитектурных видов (views). Вид данных появился позже [118], однако название “4+1 view” сохранилось. Фреймворк использует следующие виды. Варианты использования (Usecaseview) – это центральный вид, это означает, что все архитектурные решения должны основываться на этом виде. Этот архитектурный вид определяет основные варианты использования создаваемой системы и используется в качестве основы для построения других архитектурных видов и для их валидации. Логический вид (Logicalview). Этот вид рассматривает архитектуру с точки зрения реализации функциональных требований. В рамках этого вида определяются основные блоки, из которых строится система (подсистемы, компоненты, классы) и способы их взаимодействия. Реализация (Implementation view). Этот архитектурный вид рассматривает систему точки зрения статическиз артефактов, таких как исходный код, графика и т.п, которые находятся в пакетах, библиотеках т.п. Данные (Data view). Этот вид описывает способы, которые используются для обмена данными между отдельными подсистемами в терминах форматов данных, а также место и способы хранения данных. Процессы (Process view). Этот вид содержит описание поведения системы, включая вопросы, связанные с параллельной обработкой. Размещение (Deployment view). Этот вид описывает, где располагаются статические артифакты, которые определены в рамках архитектурного вида Реализация [118]. |