Полная версия

Главная arrow Информатика arrow Введение в архитектуру программного обеспечения

  • Увеличить шрифт
  • Уменьшить шрифт


<<   СОДЕРЖАНИЕ   >>

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

Для анализа характеристик архитектуры ПО и оценки ее пригодности, а также для сравнительного анализа альтернативного набора архитектур в SEI был разработан ряд методов SAAM, АТАМ, СВАМ и ARID12J. Подробное описание указанных методов в данной работе приводиться не будет, принципиально они похожи — в их основе лежит работа группы экспертов по определенным для каждого метода сценариям.

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

Шаги метода

  • 1. Определить архитектуру (или несколько сравниваемых архитектур). Описание архитектуры должно быть нормативным для используемой технологии разработки и, возможно, подготовленным для целей анализа и используемых методов оценки.
  • 2. Для оцениваемой архитектуры отобрать из библиотеки сценариев (если она есть) и из других источников представительный набор сценариев. Чем представительней и адекватней набор сценариев, тем выше будет качество анализа. Со сценариями можно связать ожидаемые риски.
  • 3. Провести классификацию сценариев с позиций их потенциальной реализуемости в рамках архитектуры (в том числе и с учетом возможных изменений архитектуры).
  • 4. Для каждого сценария с учетом их классификации провести оценку степени реализуемости в рамках оцениваемой архитектуры. Определиться с необходимыми изменениями архитектуры с достаточной степенью детализации.
  • 5. Выявить взаимодействие сценариев с учетом смысловых связей между взаимодействующими сценариями. Степень связности несет информацию о потенциальной декомпозиции структуры АС, зарегистрированной в описании архитектуры.
  • 6. Оценить архитектуру в целом (или сравнить несколько заданных архитектур). Для этого целесообразно использовать подходящие методы оценки, учитывающие важности сценариев и степень их поддержки архитектурой.

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

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

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

Контрольные вопросы

  • 1. Поясните на примере отличия характеристик качества с точки зрения разных групп стейкхолдеров.
  • 2. Поясните модель сценария при построении архитектуры с позиций качества.
  • 3. Поясните понятие «перспектива» при построении архитектуры ПО.
  • 4. Перечислите методы сравнительного анализа архитектур.
 
<<   СОДЕРЖАНИЕ   >>