6.3. Подходы к оцениванию архитектуры

Для анализа характеристик архитектуры ПО и оценки её пригодности, а также для сравнительного анализа альтернативного набора архитектур в SEI был разработан ряд методов SAAM, ATAM, CBAM и ARID[2]. Подробное описание указанных методов в данной работе приводиться не будет, принципиально они похожи - в их основе лежит работа группы экспертов по определенным для каждого метода сценариям.

Рассмотрим их на примере использования метода SAAM (Software Architecture Analysis Method). Метод SAAM предполагает работу со сценариями, в содержании которых отражается необходимая для построения архитектуры и её оценивания система функциональных и нефункциональных требований к ПО.

Шаги метода:

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

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

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

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

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

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

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

Выполнение всех методов базируется на рассуждениях групп специально отобранных лиц и оформлении результатов их работы в виде определённой совокупности документов. В построении архитектуры ПО рекомендуется использовать стандарт IEEE-1471,опираясь и на другие стандарты и нормативы. Результат таких построений должен быть оформлен документально. Документирование должно сопровождать разработку архитектуры на всех этапах её жизненного цикла. Однозначных правил о требуемом наборе документов нет. Существуют только конкретные инструментально-технологические среды и практика авторитетных орга-низаций (например, Microsoft, IBM, Siemens).

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

Заключение

Понимание «Архитектуры» как составной части общего понятия «Программная инженерия» особенно важно в условиях постоянно повышающихся требований к качеству, скорости выполнения разработок и снижению расходов на выпуск конкретного продукта.

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

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

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