WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     | 1 | 2 || 4 | 5 |   ...   | 9 |

- в узел «архитектура» как составляющая добавлен «стиль» (в общем случае интегрированная совокупность стилей) и отражн тот факт, что архитектура имеет определнные «спецификации»;

- для «архитектурного описания» показано, что оно осуществляется по определнной «схеме» или, что то же самое, согласно определнному шаблону (template);

- по узлу «среда» отмечена целесообразность учта «родственных систем», е «истории» и «силовых давлений».

2.4. Архитектурные концептуальные схемы 2.4.1. Определение и ретроспектива Как уже отмечалось выше, стандарт IEEE-1471 является концептуальной схемой, по образцу которой рекомендуется описывать архитектуру SIS. У этого стандарта были предшественники, а он сам использовался при построении других подобных конструктов. Таким образом, в практике архитектурных описаний SIS разного типа сложился специфический класс «Архитектурных концептуальных схем» (Architecture Frameworks, AF), принадлежность к которому конкретной «Концептуальной схемы» определяется по наличию у схемы вполне определнного набора признаков.

По сложившемуся пониманию конструкты AF являются обобщнными прагматически руководствами:

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

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

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

К числу особо важных составляющих AF относятся:

- «Виды», как средства для понимания, взаимопонимания и коммуникативного взаимодействия лиц, заинтересованных в разработке SIS;

- «Методы», предоставляющие дисциплину, для того чтобы собирать и организовывать данные и конструкты «видов» способом, помогающим гарантировать целостность, точность и завершнность архитектурного представления SIS;

- «Обучение/ опыт», что обеспечивает разумное и конструктивное применение методов и обслуживающих их инструментов.

2.4.2. Архитектурная концептуальная схема Дж. Захмана Особое место среди архитектурных концептуальных образцов занимает концептуальная схема Дж. Захмана [35], представленная на рис. 10. Схема изначально нацеливалась на системное представление задач информатизации, в которых приходится учитывать специфику SIS.

С момента своего создания (1987 год) схема Дж. Захмана постоянно усовершенствовалась, оставаясь определнного рода «вопросником» о существенных аспектах SIS. Схема построена в форме табличной структуры, для формирования и использования которой необходимо построить систему ответов, каждый из которых заполняет определнную позицию таблицы. Ответ может быть как простым, так и сложным. Одной из наиболее распространнных форм ответов является визуализируемая концептуальная модель.

Данные Функции Люди Время Мотивы Артефакты и документы Что Как Где Кто Когда Почему Рис. 10. Архитектурная схема Дж. Захмана То содержание, которое вкладывается в каждый ряд и каждый столбец схемы, представлено в таблице 1 и таблице 2.

Таблица Ряд схемы Содержание 1. Цели и границы (Вид Определяет основные цели и границы, в рамках которых планировщиков) должны приниматься архитектурные решения 2. Модель предприятия, Определяет сущность предприятия (системы), включая системы (Вид владельцев, структуры, процессы и организационные структуры ответственных за систему) 3. Модель базового понимания (информационного Определяет в более строгих терминах содержание ряда представления, Вид архитектора) Определяет, как и какая технология должна быть исполь4. Технологическая модель зована для того, чтобы запросы третьего ряда были удов(Вид проектировщиков) летворены 5.Детализированное предОпределяет детали проектирования, применяемые языкоставление (Вид разработвые средства, структуры данных и другие средства чика) 6. Функциональности сис- Определяет, как должны работать системы в рамках предтемы (Вид пользователей) приятия (в контексте окружения) Таблица Столбец Содержание 1. Данные (Структура, Фокусирует внимание на сущностях, объектах, компоненЧто) тах и отношениях между ними 2. Функции (Активность, Фокусирует внимание на той деятельности, которая осущеКак) ствляется организацией и поддерживается автоматизированными системами 3. Сеть работ (Месторас- Фокусирует внимание на географическом (физическом) положение, Где) распределении активностей 4. Люди (Кто) Фокусирует внимание на тех лицах, которые вовлечены в бизнес-процессы 5. Время (Когда) Фокусирует внимание на эффектах, связанных со временем (планирование, события) 6. Мотивации (Почему) Фокусирует внимание на целях, стратегиях и ограничениях, специфических для реализации системы Использование этой схемы предполагает, что лица, отвечающие за архитектуру системы, в том числе и типа SIS, заполнят «клетки» подходящим содержанием. Разумеется, содержание «клеток» включает спецификации (на уровне архитектуры) тех решений, которые по этой «клетке» приняты. В результате будет образована целостная архитектурная картина представляемой системы, например SIS, которая может быть использована в решении большинства из названных выше (п. 1.1.3) задач.

Заметим, что Дж. Захман разрабатывал свою схему для предприятия, использующего любые информационные технологии, но схема находит широкое применение в теории и практике SIS. Так, например, в работе [35] предложено развитие схемы Дж.



Захмана до трх измерений (рис.11), за счт перехода к многослойной структуре системы моделей.

Слои 1-Схема Захмана (слой 1) Рис. 11. «Трхмерная» схема Захмана В трхмерную структуру введены следующие дополнения, детализирующие содержание артефактов, которые приписываются «клеткам схемы Дж. Захмана»:

слой разработки, раскрывающий «Что» должно быть сделано для каждого артефакта, приписанного к «клетке» схемы Дж. Захмана;

слой метаданных, включающий описание информации, которая должна быть собрана и «Как» она должна быть организована;

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

слой ответственности, фиксирующий, «Кто» из команды разработчиков будет исполнять требуемые работы;

слой жизненного цикла, показывающий, «Где» в процессе разработки будет создан соответствующий артефакт;

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

Для предлагаемого расширения автором трехслойной модели разработаны детали для каждого слоя (и для каждой клетки слоя).

2.4.3. Архитектурная концептуальная схема DoDAF Эволюция архитектурной концептуальной схемы DoDAF (Department of Defense Architecture Framework), созданной по заказу Департамента обороны США [77], учитывает вс новое, что появляется в теории и практике предметной области «Архитектура SIS».

Архитектурное описание SIS в DoDAF строится на базе модели данных ядра архитектуры (Core Architecture Data Model, CADM) и артефактов архитектуры. CADM представляет собой стандартизованную систему понятий для определения видов и их составляющих в базе данных.

Вид понимается традиционно и представляет определнный объем операций, систем и технических стандартов. Каждый вид является хорошо определнным множеством элементов данных в составе CADM. Архитектурные артефакты документируются с использованием языка UML.

Виды объединены в четыре группы. Первая группа называется «Все виды» (All Views) и содержит обзор, обобщения и интегрированный словарь по архитектуре DoDAF. Остальные группы – это «Операционные виды» (Operational Views), «Системные виды» (System Views) и «Технические виды» (Technical Views). Обобщнная картина видов представлена на рис.12.

Операционные виды описывают специфику деятельности и операции, узлы операций, узлы соединений, информационный обмен, организационные отношения, правила операций, последовательности событий и логическую модель данных. Описания, содержащиеся в этой группе, распределены по 24 подвидам. (каждый подвид является видом по определению IEEE-1471).

Активности/ Операционные Задачи элементы Операционный вид Раскрывает, что необходимо делать и кто будет действовать Информационные потоки Системы Потоки данных Стандарты Правила Системный Вид технических вид стандартов Коммуникации Предписывает стандарты и соглашения Системы и их связность Рис.12. Архитектурная схема DoDAF (52 вида) Системные виды описывают систему и е компоненты, системные интерфейсы, коммуникативное взаимодействие, матрицу отношений на множестве систем и подсистем, функциональности, матрицу связности (traceability), эволюцию, использование и технологические предсказания. Группа состоит из подвидов.

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

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

Ближайшим родственником архитектурной схемы DoDAF является схема MoDAF, разработанная европейскими союзниками США. В число основных потребностей, приводящих к отличиям схемы MoDAF от схемы DoDAF, входят следующие потребности:

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

2. Потребность моделировать трансформационные программы и их взаимозависимости.

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

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

5. Потребность объединять информационные представления в традиционные модели архитектуры, чтобы обеспечить необходимой информацией работу архитекторов предприятия.

2.4.4. Архитектурная концептуальная схема TOGAF С момента е первого опубликования в 1995 году архитектурная концептуальная схема TOGAF (The Open Group Architecture Framework) развивается и используется. В настоящий момент времени доступна е версия TOGAF 8.1.1, структура которой представлена на рис. 13.

Предварительная схема и принципы Концепция архитектуры Управление Бизнес архитектура изменениями архитектуры Информационная Руководство по Система требования архитектура реализации Планирование Технологическая использования архитектура Возможности и решения Рис. 13. Жизненный цикл архитектуры SIS по TOGAF За каждым этапом (обозначены овалами) жизненного цикла стоит проверенная методика и руководство по использованию методики. Детальное описание концептуальной схемы TOGAF, включающее описание каждой из методик, представлено на сайте разработчиков TOGAF [81].

Применение TOGAF осуществляется как итеративный процесс. Итерации TOGAF (которые в руководствах называются циклами) обычно отличаются большей длительностью, чем итерации RUP, и объединяют несколько фаз реализации и обслуживания архитектуры предприятия. Это обусловлено тем, что область архитектуры предприятия шире области одного проекта RUP.





2.4.5.Архитектурная схема FEAF История схемы FEAF (Federal Enterprise Architecture Framework) началась в году. Е специфика (рис. 14) связана с е предназначением – разработка SIS в рамках системы задач государственного масштаба для США. Подобные задачи в нашей стране намечено решать в рамках «Электронной России». Последняя версия FEAF доступна по адресу www.eaframeworks.com/FEAF.

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

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

Рис. 14. Архитектурная схема FEAF 2.5. Сравнительное сопоставление архитектурных видов 2.5.1. Проблема стандартной концептуальной схемы Представленные выше архитектурные концептуальные схемы указывают на то, что организации и группы создают и поддерживают эволюционное развитие «собственных» понятийных схем. Одним из объяснений этого служит разнообразие предметных областей SIS, каждая из которых имеет специфику, которую и стараются учесть в «собственной » концептуальной схеме. Ещ одной причиной, возможно, является состояние теории и практики архитектуры SIS, которые ещ не достигли состояния, в котором можно было бы создать единую архитектурную концептуальную схему, детализирующую, например, стандарт IEEE-1471 до типологии видов, моделей и документов. К решению такой задачи можно продвинуться через сопоставление различных концептуальных схем и различных систем видов [46, 69]. Один из примеров [46] таких сопоставлений приведн ниже.

2.5.2. Сопоставление систем видов 2.5.2.1. Архитектура «4+1» Архитектура конкретной SIS описывается множеством ее представлений. В архитектуре SIS фиксируются главные решения проектирования структуры, показывающие, как приложение, вложенное в SIS, разделено на компоненты, и как связаны эти компоненты для получения полезной конфигурации. Эти решения должны вытекать из требований функциональности и других факторов. С другой стороны, эти решения устанавливают дальнейшие ограничения на требования и на будущие проектные решения нижнего уровня.

При использовании подхода «4+1» разработчики SIS начинают формирование архитектуры с типичного набора видов, представленного на рис. 15.

Логический вид Вид разработки Use- case Вид процессов Физический вид Рис. 15. Модель «4+1» Набор видов включает:

1. Use case вид, который содержит прецеденты и сценарии, охватывающие архитектурно существенное поведение, классы или технические риски. Вид является подмножеством модели прецедентов.

2. Логический вид, который содержит наиболее важные классы проекта, их организацию в пакеты и подсистемы различных уровней. Здесь содержится уже некоторая реализация прецедента. Это представление является подмножеством модели проекта 3. Вид с позиции разработки, который содержит краткий обзор модели выполнения в терминах модулей пакетов и уровней. Здесь описывается также распределение пакетов и классов (из логического представления) в пакетах и модулях представления выполнения. Это представление является подмножеством модели выполнения.

4. Вид с позиций процесса, содержащий описание задач (процессов и нитей), их взаимодействия и конфигурации и распределения объектов и классов по задачам. Потребность этого представления возникает, только если система имеет существенную степень параллелизма. В Rational Unified Process 5.1 представление процесса это подмножество модели проекта.

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

Дополнительные представления, например для представления интерфейса пользователя, представления защиты и представление данных не отвергаются, но ответственность за их связывание с базой «4+1» ложится на разработчиков SIS.

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

Но архитектура интересуется только некоторыми определенными аспектами:

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

Существенные элементы критические прецеденты, главные классы, общие механизмы и так далее, а не все элементы, представленные в модели.

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

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

Pages:     | 1 | 2 || 4 | 5 |   ...   | 9 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.