WWW.DISSERS.RU

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

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


Pages:     | 1 |   ...   | 5 | 6 || 8 | 9 |

3.5.2. Языки архитектурных описаний Разработка архитектуры SIS завершается представлением е проекта, получившего название «Архитектурное Описание». Такой проект носит концептуальный характер и состоит из текстовых единиц (неформального и/или полуформального и/или формального типов), таблиц и графических объектов (в число которых часто включают UML-диаграммы, построенные с использованием формализованного языка UML). Следовательно, при формировании конкретного АО архитектор (или группа архитекторов) стоит перед вопросом «Какие фрагменты АО на каком языке лучше описать» За время становления предметной области «Архитектура» был предложен, испытан и внедрн в практику ряд языков описания архитектуры (Architecture Description Languages, ADL). К числу таких языков относятся языки ACME [90], Aesop [91], C2 SADL [93], Rapide [94], Wright [95] и другие, представленные на рис. 31.

Рис. 31. Проблема выбора языка архитектурного описания В применениях языков архитектурного описания различаю как позитивы, так и негативы:

1. Позитивы:

- позволяют описывать архитектурные структуры формально;

- нацелены на их использование как человеком, так и машиной;

- поддерживают описание на более высоком уровне абстракции, чем это было возможно до описания;

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

- нацелены на автоматическое порождение определнных состояний или форм ПО.

2.Негативы:

- отсутствуют общепринятые соглашения о том, что ADLs должны представлять;

- представления на таких языках трудны для машинного разбора и не поддерживаются коммерческими продуктами;

- большая часть языков создана с академическими, а не коммерческими целями.

В настоящее время широкое использование для построения архитектурных описаний находит язык UML. Детальный анализ языков и причин их трудного внедрения в практику представлен в [75].

3.5.3. Методы проектирования В практике создания архитектур SIS накоплен достаточный опыт проектирования архитектуры, оформленный в виде методов. Так, например, с каждой из приведнных выше концептуальных архитектурных схем связана определнная система построения и использования архитектуры SIS. Легко доступны через Интернет, например, системы методов DoDAF [77], TOGAF [81] и FEAF [78]. Для небольших проектов интересна и полезна система методов SPAMMED [59].

В то же время особого внимания, из-за их пионерского вклада в теорию и практику архитектурного моделирования SIS, заслуживают методы, созданные в Институте программной инженерии Carnegie Mellon [6,17-20]. По этой причине раскроем эти методы в деталях.

Учными и специалистами SEI создана система методов разработки архитектуры, обслуживающих действия архитектора или архитекторов по основным этапам жизненного цикла. К числу этих методов относятся: Architecture Tradeoff Analysis Method (ATAM), Cost-Benefit Analysis Method (CBAM), Quality Attribute Workshop (QAW), Active Reviews for Intermediate Designs (ARID), Attribute-Driven Design (ADD). Место использования методов в рамках жизненного цикла отражено в таблице. 8.

Таблица Уровень жизненного цикла QAW ADD ATAM CBAM ARID Бизнес необходимости и ог- Ввод Ввод Ввод Ввод раничения Требования Ввод Ввод Ввод Ввод Вывод Вывод Вывод План архитектуры Вывод Ввод Ввод Ввод Вывод Вывод Детальный план Ввод Вывод Реализация Тестирование Развртывание Поддержка Ввод Вывод Разумеется, совокупность методов, разработанных в SEI, не перекрывает те виды активностей, которые приходится использовать при построении архитектуры.

Представим сущность этих методов, используя их имена в виде аббревиатуры на английском языке. Первым с позиций его включения в общий поток работ по разработке SIS является метод QAW. Его назначение связано с формированием подсистемы требований (как части общей системы требований), на основе которых будет проводиться разработка архитектурной модели. Метод «стоит» на границе между этапами «Анализ требований» и «Проектирование архитектуры». Его применение позволяет внести в общую систему требований вклад (в виде подсистемы этой системы), который будет использован при проектировании архитектуры SIS.

Метод QAW базируется на коллективной работе отобранной группы лиц и включает следующую совокупность действий:

1. Презентация группе метода QAW с позиций его сущности и методик.

2. Представление группе архитектурного плана.

3. Выбор и идентификация архитектурных драйверов (характеристик качества).

4. Выявление и формирование множества сценариев.

5. Отбор сводного списка сценариев.

6. Определение приоритетов в списке сценариев.

7. Коррекция списка и его систематизация.

Роль входной информации для такой работы выполняют бизнес use-case и документ «Концепция (Vision)» как архитектурный план. Результатами реализации метода являются откорректированный бизнес use-case и библиотека сценариев. Основная работы при исполнении метода осуществляется в виде рассуждений разной формы.

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

1. Отобрать модуль для декомпозиции.

2. Усовершенствовать представление модуля в соответствии со следующими шагами:

2.1. Выбрать архитектурные драйверы.

2.2. Выбрать архитектурные образцы, удовлетворяющие драйверам.



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

2.4. Определить интерфейсы с дочерними модулями 2.5. Проверить и откорректировать use-case и сценарии, выражающие качества, и сформировать на их базе ограничения для дочерних модулей.

3. Повторить шаги для следующего модуля.

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

Методы QAW и ADD представлены обобщнно по публикации [6] авторов методов, которая раскрывает возможность их включения в потоки работ RUP. Главным при исполнении методов является их опора на сценарии, при работе с которыми необходимо придерживаться следующих рекомендаций:

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

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

3. Особо внимание уделяется интерфейсам и обменам сообщениям между модулями для каждого сценария.

3.5.4. Подходы к оцениванию архитектуры Для анализа характеристик архитектуры SIS и оценки е пригодности, а также для сравнительного анализа альтернативного набора архитектур в SEI был разработан ряд методов [18], из которых первым был метод анализа архитектуры ПО (Software Architecture Analysis Method, SAAM), идея которого представлена на рис. 32.

Разработка сценариев Описание архитектуры Оценка сценария Оценка Интерактивная оценка сценариев Рис. 32. Схема анализа архитектуры В основе использования метода SAAM лежит работа со сценариями, в содержании которых отражается необходимая для построения архитектуры и е оценивания система функциональных и нефункциональных требований к SIS.

Применение метода предполагает выполнение следующих шагов:

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

2. Для оцениваемой архитектуры отобрать из библиотеки сценариев (если она есть) и из других источников представительный набор сценариев. Чем представительней и адекватней набор сценариев, тем выше будет качество анализа. Со сценариями можно связать ожидаемые риски.

3. Провести классификацию сценариев с позиций их потенциальной реализуемости в рамках архитектуры (в том числе и с учтом возможных изменений архитектуры).

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

5. Выявить взаимодействие сценариев с учтом смысловых связей между взаимодействующими сценариями. Степень связности нест информацию о потенциальной декомпозиции структуры SIS, зарегистрированной в описании архитектуры.

6. Оценить архитектуру в целом (или сравнить несколько заданных архитектур).

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

Кроме метода SAAM, в SEI для оценки архитектур были разработаны, испытаны и внедрены в практику методы ATAM, CBAM и ARID [6].

В основе метода ATAM лежит следующая совокупность шагов:

1. Презентация группе метода ATAM с позиций его сущности и методик.

2. Представление группе совокупности бизнес-драйверов.

3. Представление группе архитектуры.

4. Идентификация архитектурных подходов.

5. Формирование дерева качества.

6. Анализ архитектурных подходов.

7. Мозговой штурм и приписывание приоритетов сценариям.

8. Анализ архитектурных подходов.

9. Представление результата.

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

В основе метода CBAM лежит следующая совокупность шагов:

1. Проверить и сопоставить сценарии.

2. Усовершенствовать сценарии.

3. Приписать сценариям приоритеты.

4. Определиться с межсценарными характеристиками качества и построить их дерево.

5. Разработать архитектурные стратегии и определить уровни реакций атрибутов качества.

6. Определить выгоды от ожидаемых значений характеристик качества.

7. Вычислить общую выгоду, полученную от архитектурной стратегии.

8. Выбрать архитектурные стратегии на основе возврата от инвестиций.

9. Найти интуитивные подтверждения полученных результатов.

Входными данными для метода являются бизнес use-case, документация на архитектуру и содержимое библиотеки сценариев. В результате исполнения CBAM формируются архитектурные документы, включающие результаты оценок выгод, и предложения по развитию (обогащению) библиотеки сценариев. Основным видом работ при исполнении метода являются рассуждений (индивидуальные и коллективные).





В основе метода ARID лежит следующая совокупность шагов:

1. Определиться с группой рецензентов.

2. Подготовить справку по проектированию.

3. Подготовить группу родственных сценариев.

4. Подготовить другие необходимые материалы.

5. Провести презентацию (в группе рецензентов) сущности и деталей ARID.

6. Провести презентацию проекта.

7. Провести мозговой штурм и приписать приоритеты сценариям.

8. Применить сценарии.

9. Провести обобщение.

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

На практике применяют и другие методы проектирования архитектуры [25, 59, 80], но в любом случае исполнение этих методов базируется на рассуждениях групп специально отобранных лиц и оформлении результатов их работы в виде определнной совокупности документов.

3.5.5. Документирование архитектурных решений В построении архитектуры SIS рекомендуется (целесообразно и полезно) использовать стандарт IEEE-1471,опираясь и на другие стандарты и нормативы. Результат таких построений должен быть оформлен документально. В состав документов целесообразно включать не только окончательный результат, но и промежуточные результаты, то есть документирование должно сопровождать разработку архитектуры на всех этапах е жизненного цикла. Хорошим руководством по документированию архитектуры способна служить монография [17].

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

Разработка документации на архитектуру является работой, в процессе исполнения которой приходится решать определнные задачи. Сущность задач необходимо обязательно привязывать к тем нагрузкам, которые возлагаются на «документацию архитектурного описания». К основным применениям документации архитектуры относят:

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

2. Использование документации на архитектуру в виде средства коммуникации между лицами, вовлечнными в разработку SIS на всех этапах жизненного цикла, особенно на ранних этапах.

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

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

В основе системы документов на архитектуру SIS лежат документы (рис. 33), фиксирующие:

- «виды», вложенные в архитектуру;

- информацию, раскрывающую, как «виды» интегрируются в единое целое.

Состоит из Документация 1 1.* Вид на архитектуру АС 1 Включает Другая нормативная информация Рис. 33. Схема документирования Виды являются средством, вводящим в документацию базовую структуру не только SIS как целого, но и на уровне вида. В практике документирования зарекомендовала себя структура документов на вид, представленная на рис. 34.

Вид 1..* включает 1..* Документально соПакет видов Итоговый вид ответствует документации 1 поддержки включает включает 1 1 включает Основная пре- Документация под- Шаблон зентация держки вида Рис. 34. Структура документов Структура документов на вид включает следующее:

- в общем случае (из-за большого количества моделей и документов) документальное представление вида можно разложить по пакетам;

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

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

- если имеется шаблон (template) для документирования вида, то все отмеченные позиции заполняются в соответствии с шаблоном;

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

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

Pages:     | 1 |   ...   | 5 | 6 || 8 | 9 |










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

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