Процедура оценки компонентной архитектуры программного обеспечения

В этой статье проводится небольшое исследование современного состояния оценки архитектуры программного обеспечения с целью предоставления общего обзора по этому вопросу. Он охватывает такие темы, как: Что такое оценка? Каковы цели оценки архитектуры? Зачем оценивать архитектуру? Когда оценивать архитектуру? Каковы их характеристики? Кто участвует в оценке архитектуры? А также методы, используемые при оценке архитектуры, краткий анализ некоторых существующих методов оценки и предложение по оценке от LISI (Лаборатория исследований в области систем) информации), Университет Симона Боливара.

ВВЕДЕНИЕ

Архитектура программного обеспечения - это молодая практика, которая требует всего несколько лет постоянной работы. Он берет свое начало в 1960-х, но только в 1990-х Дьюэйн Перри и Александр Вольф разоблачили его в том смысле, в каком он известен сегодня. Это десятилетие считалось десятилетием архитектуры программного обеспечения, как и предсказывали Перри и Вольф. С этого момента архитектура программного обеспечения начала испытывать головокружительный бум как в академических кругах, так и в промышленности, развивая архитектурные стили, ADL (Architectural Description Legumes), хотя это то, что все еще остается немного девственным сегодня, среди прочего. Все это мешает созданию различных типов архитектур, например, основанных на компонентах.

Процедура-для-эволюции-из-программных архитектур-

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

Нет смысла использовать систему, которая не соответствует атрибутам качества, указанным в нефункциональных требованиях клиентов. Следовательно, проектирование правильной архитектуры будет определять успех или неудачу программной системы в зависимости от того, соответствует она своим целям или нет (4). В связи с этим «Для уменьшения таких рисков и в качестве хорошей инженерной практики рекомендуется проводить архитектурные оценки» (4).

В этой статье объясняется процедура выполнения Proofs of Concept для архитектуры программного обеспечения (оценка архитектуры), подчеркивается, почему это необходимо, преимущества, которые она предоставляет, а также выделяются некоторые существующие методы оценки и какие из них предлагает. В данном случае это MECABIC (Метод оценки качества архитектур, основанный на интеграции компонентов), основной целью которого является оценка и анализ качества архитектуры программного обеспечения этого типа. Метод предложен Александром Гонсалесом, Маризе Михаресом, Луисом Э. Мендосой, Анной Гриман, Марией Перес, LISI (Лаборатория исследований информационных систем), Университет Симона Боливара.

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

Материализация в архитектуре ERP.

Эта статья преследует следующие конкретные цели:

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

Статья состоит из двух глав:

В главе 1 проводится исследование современного состояния Proofs of Concept, дающее обзор теоретических аспектов, связанных с предметом; Некоторые методы или процедуры также подробно описаны, их характеристики представляют собой краткое сравнение между ними.

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

Объем данного документа является представить общий обзор оценки архитектуры и предполагает, что предлагаемый метод применяются к архитектуре модулей ERP (Enterprise Planning ресурсов), система планирования ресурсов, что компания развивается. Факультет 3 совместно с другими факультетами Университета информатики.

КОНЦЕПТУАЛЬНАЯ ОСНОВА

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

Качество программного обеспечения: качество программного обеспечения - это «соответствие функциональным требованиям и требованиям к производительности, установленным явно задокументированными стандартами разработки, а также неявным характеристикам, ожидаемым от всего профессионально разработанного программного обеспечения» (1).

Компонент: «Это часть четко идентифицируемой архитектуры программного обеспечения, независимая от приложения, в котором он используется, и других компонентов (частей), который описывает и выполняет конкретные и четкие функции в контексте архитектуры, он может быть изменен во время проект имеет четкую документацию, которая позволяет узнать его характеристики, атрибуты и поведение, возможность многократного использования и возможность взаимодействия с другими компонентами (частями) не снижает уровень эффективности архитектуры »(1).

Сценарий: сценарий состоит из трех частей: стимула, контекста и реакции. Стимул - это часть сценария, которая объясняет или описывает, что человек, участвующий в разработке, делает, чтобы инициировать взаимодействие с системой. Он может включать выполнение задачи, системные изменения, выполнение теста, настройку и т. Д. Контекст описывает, что происходит в системе в момент воздействия стимула. Ответ описывает через архитектуру, как система должна реагировать на стимул. Этот последний элемент позволяет установить, какой атрибут качества является ассоциированным (2). «Сценарии описывают ожидаемое или желаемое использование системы и обычно выражаются одним предложением» (3). «Они представляют собой абстракцию наиболее важных требований системы» (3).

Заинтересованные стороны: те люди, которые определенным образом связаны с системой, будь то разработчик, пользователь или менеджер и т. Д.

ГЛАВА 1. Изучение современного состояния

Введение

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

цели

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

Как определить, что это часть архитектуры?

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

Основные проблемы в проекте, вызванные Архитектурой (5):

• Он не отвечает необходимому качеству. Он не пытается удовлетворить потребности бизнеса. Недостаточная заинтересованность пользователей в завершении проекта (проблемы со связью).

• 50% отстающих проектов имеют проблемы в архитектуре.35% проектов, превышающих стоимость строительства, имеют проблемы в архитектуре.

Что такое оценка?

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

Цели оценки архитектуры

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

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

• Качественное измерение применяется для сравнения между кандидатами архитектуры и связано с намерением знать тот вариант, который лучше всего подходит определенный атрибут качества. Этот тип измерения дает положительные или отрицательные ответы, подробности. Более высокий уровень количественного измерениястремится получить значения, которые позволяют принимать решения относительно атрибутов качества архитектуры программного обеспечения. Общая схема - это сравнение с установленными запасами, как и в случае требований к производительности, для определения степени соответствия возможной архитектуре или для принятия решений по этому поводу. Такой подход позволяет сравнивать, но ограничен в обеих максимальных теоретических значениях не известны и минимальных измерениях, с которым выполняются comparación.La измерения максимальными и минимальными теоретическимОн рассматривает теоретические значения с целью сравнения измерения с указанными атрибутами качества. Знание максимальных или минимальных значений позволяет четко установить степень выполнения атрибутов качества.

В общем, предыдущий подход представляет цели для измерения атрибутов качества. Однако иногда оценка архитектуры программного обеспечения не дает числовых значений, позволяющих принимать непосредственное решение. Учитывая возможность проведения оценок на любом уровне процесса проектирования, с разными уровнями спецификации, Казман предлагает общую схему оценки архитектуры по признакам качества. В этом смысле Казман и его коллеги утверждают, что оценка Архитектуры не дает ответов типа «да - нет», «хорошо - плохо» или «6,75 из 10», а скорее объясняет, какие точки риска являются оцененный дизайн (2).

Одним из основных различий между подходами Bosch и Kazman является подход, который они используют для целей оценки. Основной характеристикой метода архитектурного проектирования, предложенного Bosch, является явная оценка атрибутов качества архитектуры в процессе проектирования. В этом смысле Bosch предлагает методы оценки: на основе сценария, моделирования, математической модели и опыта. Со своей стороны, Казман полагает, что характеристика или измерение атрибутов качества не представляет особого интереса на ранних этапах процесса проектирования. Его подход ориентирован на снижение риска, обнаруживая, где архитектурные решения влияют на интересующий атрибут качества (2).

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

Характеристики оценки архитектуры

• Это одна из основных точек оценки в рамках проекта, так как ошибки в ней могут привести к провалу проекта (5). Ее могут выполнять внутренние или внешние люди проекта, хотя самое интересное то, что ее выполняют внешние люди. (Наставники или региональные архитекторы) (5).

Как я могу быть уверен, что выбранная мной архитектура подходит для моего программного обеспечения?

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

Зачем оценивать архитектуру?

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

Атрибут качества - это характеристика качества, которая влияет на предмет. Где термин «характеристика» относится к нефункциональным аспектам, а термин «элемент» - к компоненту (4).

• Чем раньше будет обнаружена проблема в программном проекте, тем лучше. (5) Выполнение оценки архитектуры - самый экономичный способ избежать катастроф (5). Проанализировать и оценить качество, требуемое пользователями (5). Решения Ограничения проектирования (5) или реализации.
  • Устанавливает организационную структуру как разработки, построения, так и выполнения системы, обеспечивает атрибуты качества. o Позволяет создавать прототипы. Позволяет более точные оценки.
  Переносимая абстракция между системами (5)

Когда можно оценить архитектуру?

По словам Казмана, это можно сделать в любое время, но он предлагает два варианта, которые группируют два разных этапа: ранний и поздний (2).

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

Золотые правила определения того, когда проводить оценку (4):

1. Выполняйте оценку, когда группа разработчиков начинает принимать решения, которые напрямую влияют на архитектуру;… Когда стоимость отказа от этих решений может превышать стоимость проведения оценки.

Кто участвует в оценке?

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

Методы оценки

Существует группа методов оценки, которые классифицируются как качественные и количественные.

(5):

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

Рисунок №1: Классификация методов оценки (4)

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

Планировать или нет архитектуру

Оценки могут быть (4):

• Запланировано: это те, которые были запланированы для жизненного цикла разработки, поэтому они являются частью деятельности проекта. Незапланированный: это происходит, когда архитектура содержит несколько дефектов, которые были обнаружены на поздних этапах разработки, поэтому выполнение незапланированной оценки представляет собой задержку сроков поставки, а также увеличение стоимости проекта. По этой причине рекомендуется, чтобы в проектах рассматривалась возможность проведения одной или нескольких оценок архитектуры.

По каким качествам можно оценить Архитектуру?

В общих чертах Басс классифицирует атрибуты качества на две категории (2):

• Наблюдаемые через выполнение: те атрибуты, которые определяются на основе поведения системы во время выполнения. Описание некоторых из этих атрибутов представлено в таблице 1. Не наблюдаются при выполнении: те атрибуты, которые устанавливаются во время разработки системы. Описание некоторых из этих атрибутов представлено в таблице 2.

Таблица 1. Описание атрибутов качества, наблюдаемых при выполнении (2)

Атрибут качества	Описание
Доступность	Это мера доступности системы для использования (Barbacci et al, 1995).
конфиденциальность	Это отсутствие несанкционированного доступа к информации (Barbacci et al, 1995).
функциональность	Способность системы выполнять работу, для которой она была задумана (Казман и др., 2001).
Производительность	Это степень, в которой система или компонент выполняет свои назначенные функции в рамках определенных ограничений, таких как скорость, точность или использование памяти. (IEEE 610.12).
надежность	Это мера способности системы оставаться в рабочем состоянии

времени (Barbacci et al., 1995).

Внешняя безопасность	Отсутствие катастрофических последствий для окружающей среды. Это показатель отсутствия ошибок, приводящих к потере информации (Barbacci et al, 1995).
Внутренняя безопасность	Это мера способности системы противостоять попыткам несанкционированного использования и отказу в обслуживании при обслуживании законных пользователей (Kazman et al., 2001).

Таблица 2. Описание атрибутов качества, не наблюдаемых при исполнении (2)

Атрибут качества	Описание
Конфигурируемость	Возможность, предоставляемая опытному пользователю, для внесения определенных изменений в систему (Bosch et al., 1999).
Интегрирование	Это степень, в которой компоненты системы, которые были разработаны отдельно для интеграции, работают правильно. (Басс и др., 1998)
целостность	Это отсутствие несоответствующих изменений информации (Barbacci et al., 1995).
Interoperability	Это мера способности группы частей системы работать с другой системой. Это особый тип интегрируемости (Басс и др., 1998).
модифицируемость	Это возможность вносить в систему будущие изменения. (Бош и др., 1999).
Ремонтопригодность	Это способность подвергнуть систему ремонту и развитию. (Barbacci et al., 1995). Возможность быстро и недорого модифицировать систему (Bosch et al. 1999).
портативность	Это способность системы работать в различных вычислительных средах. Эти среды могут быть аппаратными, программными или их комбинацией (Kazman et al., 2001).
Повторное использование	Это способность спроектировать систему таким образом, чтобы ее структура или часть компонентов можно было повторно использовать в будущих приложениях (Bass et al. 1998).
Масштабируемость	Это степень, до которой может быть расширен архитектурный, информационный или процедурный дизайн (Pressman, 2002).
Емкость Тест	Это мера легкости, с которой программное обеспечение, подвергшееся серии тестов, может продемонстрировать свои недостатки. Это вероятность того, что, если у вас есть хотя бы один сбой, программное обеспечение выйдет из строя при следующем тестовом запуске (Bass et al. 1998).

Каковы преимущества проведения архитектурной оценки? (5)

• Финансы Объединяет заинтересованные стороны Принудительно формулирует конкретные цели в области качества Принудительно улучшает документацию по архитектуре Улучшает архитектуру Раннее обнаружение проблем Действительные требования, и я расставляю их по приоритетам Соберите основные принципы и принятые архитектурные решения.

Какие результаты дает оценка архитектуры?

После проведения оценки должен быть подготовлен отчет. Это должно быть представлено как предварительный документ, чтобы его могли исправить люди, участвовавшие в оценке. Содержание отчета отвечает на два типа вопросов (4):

• Была ли разработана наиболее подходящая архитектура для системы? Какая из предложенных архитектур является наиболее подходящей для создаваемой системы? В дополнение к ответам на эти вопросы в отчете также указывается, в какой степени были выполнены атрибуты качества.

Каковы результаты архитектурной оценки? (6)

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

Основные этапы оценки (5)

• Подготовка. oo Оценщик. o Объем.
  • Представление архитектуры.
  Реализация.
  • Представьте бизнес-задачу, которую необходимо решить, и предложенную архитектуру. o Оценивает, стоимость, функциональность, атрибуты качества. o Они рассматривают требования и возможные изменения, обсуждают проблемы и наблюдения.
  Создавайте и распространяйте результаты или вопросы и рекомендации. o Анализ рисков.

Методы архитектурной оценки

• ATAM (метод анализа архитектурного компромисса): он основан на трех различных областях: архитектурные стили, анализ атрибутов качества и метод оценки SAAM (метод анализа архитектуры программного обеспечения). Название метода ATAM происходит от того факта, что он раскрывает способ, которым конкретная архитектура удовлетворяет определенным атрибутам качества, и дает представление о том, как атрибуты качества взаимодействуют с другими.

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

Фигура 2. Концептуальная схема метода ATAM (7)

Метод оценки ATAM состоит из девяти шагов, сгруппированных в четыре этапа (презентация, исследование и анализ, тестирование и отчетность).

• Бош (2000). В нем говорится, что: «Процесс оценки следует рассматривать как итеративную деятельность, которая является частью процесса проектирования, а также итеративной. После оценки архитектуры она проходит фазу преобразования, предполагая, что она не удовлетворяет всем требованиям. Затем трансформированная архитектура снова оценивается »(2). Этот метод состоит из 5 шагов, разделенных на два этапа. ADR (Active Design Review). «ADR используется для оценки детальных проектов программных единиц, таких как компоненты или модули. Вопросы вращаются вокруг качества и полноты документации, а также достаточности, соответствия и удобства услуг, предоставляемых предлагаемым проектом »(2). ARID(Активные обзоры промежуточного дизайна). ARID - это недорогой и высокоэффективный метод, его удобно выполнять на ранних стадиях разработки (2). ARID - это гибрид между ADR и ATAM (8). Он основан на сборке проекта заинтересованных сторон для формулирования важных или значимых сценариев использования и тестировании проекта, чтобы увидеть, удовлетворяет ли он сценариям. В результате применения этой процедуры получается дизайн с высокой точностью, сопровождаемый высоким уровнем ознакомления с дизайном заинтересованных сторон. Этот метод состоит из 9 шагов, сгруппированных в два этапа (предыдущие действия и оценка) (9). Лосавио (2003):Это метод оценки и сравнения возможных архитектур программного обеспечения, в котором используется модель спецификации качества и атрибутов, адаптированная из модели ISO / IEC 9126. Спецификация атрибутов качества с использованием модели, основанной на международных стандартах, предлагает обзор всесторонние и глобальные атрибуты качества как для пользователей, так и для системных архитекторов в целях оценки (2). Метод включает семь мероприятий.

	ATAM	SAAM	ARID	Bosch (2000)	Лосавио (2003)
Предполагаемые атрибуты качества	модифицируемость Безопасность надежность Производительность	модифицируемость функциональность	Пригодность оцениваемого дизайна	Выбирается архитектором в зависимости от важности системы	функциональность надежность Юзабилити КПД Обслуживание портативность

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

• Таблица №3. Сравнение методов оценки (2).

Существуют и другие методы оценки архитектуры, которые оценивают конкретный атрибут качества:

• ALMA (Анализ изменяемости уровня архитектуры). Этот метод является результатом исследовательской работы Бренгтссона и Лассинга. Признаком качества, который анализирует этот метод, является простота модификации. Это относится к способности системы настраиваться в связи с изменениями требований или окружающей среды, а также добавлением новых функций (9).

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

Рисунок №3. Метод АЛМА (9)

• PASA (Оценка производительности архитектуры программного обеспечения). Признак качества, который анализирует этот метод, - производительность. Это интересно знать, сколько времени требуется программной системе, чтобы отреагировать при возникновении одного или нескольких событий, а также определить количество событий, обработанных в заданный интервал времени. PASA является результатом работы Уильямса и Смита, в нем используются различные методы оценки, такие как применение архитектурных стилей, антипаттернов, руководств по дизайну и моделей (9).

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

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

Рисунок №4. Метод PASS (9)

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

• SALUTA (Анализ удобства использования на уровне архитектуры на основе сценариев). Это первый метод, разработанный для оценки архитектур с точки зрения простоты использования системы, являющийся результатом исследований Фолмера и Гурпа (9).

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

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

Рекомендуется использовать после того, как архитектура будет определена, но до реализации (9). Та же учетная запись состоит из четырех шагов, как показано ниже:

Рисунок №5. SALUTA метод (9).

В процессе оценки участвуют: архитектор программного обеспечения, инженеры по требованиям или инженеры, ответственные за простоту использования (9).

• SNA (сетевой анализ выживаемости). Это метод, разработанный CERT (Группа реагирования на компьютерные чрезвычайные ситуации), которая является частью SEI (Институт программной инженерии).

Этот метод помогает определить живучесть в системе, анализируя

его архитектура. Выживание - это способность системы выполнять свою миссию вовремя, при наличии атак, сбоев или аварий. Для оценки выживаемости SNA использует три ключевых свойства: устойчивость, распознавание и восстановление (9).

Эта процедура может выполняться после спецификации архитектуры, во время реализации архитектуры или позже. СНС основана на методике использования сценариев и выделяет два типа сценариев (9):

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

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

Рисунок №6. Метод СНС (9).

Следующая таблица представляет собой сводку, сравнительную таблицу между этими ранее проанализированными методами:

Таблица №4. Сравнение методов ALMA, PASA, SALUTA и SNA (9).

ЧАСТИЧНЫЕ ВЫВОДЫ

• Метод ATAM оценивает более глубоко по сравнению с другими методами вопросы, связанные с архитектурой, такие как: атрибуты качества. На сегодняшний день было представлено несколько методов оценки архитектуры, некоторые из которых более полны, чем другие, но независимо от этого. Все они имеют что-то общее, а именно то, что они используют технику сценария как способ проверки того, в какой степени архитектура реагирует на атрибуты качества, требуемые системой.

ГЛАВА 2. Результаты и обсуждение

Введение

В этой главе предлагается процедура оценки компонентно-ориентированных программных архитектур (ASBC) с целью применения в архитектурах.

Сервисно-ориентированный (SOA). Этот анализ проводится с точки зрения того, что при определенных и определенных ситуациях или условиях услуга может рассматриваться как компонент.

цели

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

Предложение процедуры

В результате анализа сравнения различных методов было обнаружено, что метод анализа компромиссов архитектуры (ATAM) имеет набор шагов, группу оценки и набор более определенных выходных данных и не представляет никаких ограничений в отношении характеристики. качество для оценки. MECABIC вдохновлен ATAM, хотя для облегчения его применения в ASBC в некоторые из его этапов был включен подход к интеграции элементов дизайна, вдохновленный конструкцией архитектурных частей, принятой архитектурно-ориентированным дизайном (ABD). Кроме того, предлагается исходное дерево утилит, основанное на модели качества ISO-9126, созданной для архитектуры программного обеспечения, предложенной Losavio.Принятие этой модели компанией MECABIC позволяет сконцентрироваться на характеристиках, которые зависят исключительно от архитектуры, и, поскольку она является стандартом, способствует соответствию качественным характеристикам, учитываемым исследуемыми методами. Сценарии, включенные в это дерево, относятся к компонентным приложениям (1).

Команда оценки

В методе MECABIC участвуют три рабочие группы.

Таблица №5. Группы, участвующие в методе MECABIC (1).

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

Связанные Это люди, так или иначе вовлеченные в систему: программисты, пользователи, менеджеры на этапах 1, 3 и 4 и другие.

Инструменты и методы оценки

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

Этапы метода

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

Каждая из фаз с соответствующими шагами объясняется ниже.

1. Фаза презентации (1)

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

1. Презентация метода.

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

1. Презентация бизнес-руководств.

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

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

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

1. Этап исследования и анализа (1)

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

1. Идентификация элементов дизайна.

На этом этапе рассматриваются альтернативы архитектурного проектирования, которые позже будут проанализированы, чтобы увидеть, как они отвечают предъявляемым требованиям к качеству. Архитектура должна быть полностью оценена от системы с ее компонентами с наивысшей степенью детализации до минимального уровня детализации, который соответствует компонентам. В этом методе предлагается идентифицировать элементы дизайна в компонентной архитектуре как компонент и набор компонентов, с которыми он взаимодействует, набор ассоциаций, представляющих интерес для какой-либо конкретной характеристики качества, или набор решений, которые имеют влияние. значительно по сравнению с другими элементами дизайна.Чтобы идентифицировать элемент дизайна, необходимо рассмотреть услуги, предлагаемые доступными компонентами, и различные варианты, чтобы определить услуги компонентов, разработанных для системы. Способ документирования элементов дизайна зависит от важности, которую они могут иметь для оценки, набора решений или корректировок, которые необходимо сделать, а также от знаний заинтересованных сторон, присутствующих в оценке.

1. Генерация дерева утилит.

MECABIC предоставляет конкретное начальное дерево утилит для ASBC, из которого они выбирают набор интересующих сценариев (см. Таблицу № 6), который основан на модели качества ISO 9126-1 для программных архитектур, предложенной Losavio., Предполагается, что при применении метода функциональные возможности, присутствующие в системе, являются теми, которые необходимы пользователям, и, следовательно, сценарии пригодности (подхарактеристики функциональности) не включаются. Затем рассматриваются сценарии, не предусмотренные в исходном дереве полезности.

Таблица №6. Подмножество исходного дерева полезностей, предложенное методом (1)

Характерная черта	Суб-характеристика	стадия
функциональность	Interoperability	В системе есть компоненты, способные считывать данные из других систем. В системе есть компоненты, способные производить данные для другой системы.
	точность	Результаты, предлагаемые компонентами системы, точны. Связь между компонентами не влияет на точность данных
	Безопасность	Система обнаруживает действия злоумышленника и предотвращает доступ к компонентам, которые обрабатывают конфиденциальную информацию. Система гарантирует, что компоненты не потеряют данные в результате атаки (внутренней или внешней).
	покорность (Compliance)	Компоненты соответствуют стандарту надежности. Связь между компонентами не нарушает стандартов надежности.
надежность	зрелость	Компоненты системы обрабатывают неправильный ввод данных.
	Отказоустойчивость	Все операции, выполняемые компонентами, выполняются правильно в неблагоприятных условиях.
	Восстановление или восстановление способности	Компоненты системы не выходят из строя при определенных условиях. Столкнувшись с проблемами в среде, определенное подмножество компонентов может продолжать предоставлять свои услуги.
КПД	Время поведения	Система должна получить услуги своих компонентов в течение определенного времени.
	Используемые ресурсы	Компоненты могут надлежащим образом совместно использовать ресурсы. Система контролирует, чтобы ни один компонент не исчерпал ресурсы, когда они ей нужны.
Ремонтопригодность	Возможность изменения, стабильность, доказательство	Вы можете проверить состояние компонентов системы. Система обеспечивает простоту установки компонента.

Система должна облегчить замену / адаптацию компонента.

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

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

5.1. Выберите начальные сценарии для рассмотрения.

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

5.2. Предложение сценариев не рассматривается.

Этот шаг направлен на то, чтобы дать заинтересованным сторонам возможность проверить, нужно ли включать какой-либо другой сценарий в дерево утилит. Если определены сценарии качества, по которым участники достигли высокого консенсуса, их следует включить непосредственно в дерево полезности. Выбор остальных сценариев может быть сделан путем голосования, как первоначально было предложено ATAM. Затем представленные сценарии качества, не предусмотренные в таблице генерации исходного дерева полезности, организованы по характеристикам качества. Поскольку оценивается набор представляющих интерес характеристик, сценарии качества не должны присутствовать для всех известных характеристик качества. После получения сценариев для включения дерева утилит им присваивается приоритет.

5.3. Приоритезация сценариев качества.

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

1. Оцените риск игнорирования сценария. Необходимо ответить на вопросы: что произойдет, если этот сценарий не будет выполнен? Сколько людей будет затронуто? Можно ли компенсировать отсутствие реакции на этот сценарий? Оценить усилия, необходимые для достижения соответствия сценарию. В этом случае определяется, что для удовлетворения сценария необходимо внести изменения или интеграции новых компонентов. Наиболее сложными сценариями являются те, в которых требуется больше времени на анализ, а остальное следует сохранять как часть реестра.

Наконец, дерево утилит строится на основе результатов предыдущего шага. Приоритет сценария определяется в этом методе как пара (X, Y), в которой X определяет усилия по удовлетворению сценария, а Y указывает риски, которые возникают, исключая их из дерева прибылей. Возможные значения для X и Y: A (высокий), B (низкий) и M (средний). Сгенерированное дерево прибылей используется в качестве плана для остальной части оценки, выполняемой методом. Он также сообщает группе оценки, где проводить время и где тестировать архитектурные подходы и риски.

1. Анализ элементов дизайна для ASBC.

На этом этапе элементы дизайна, идентифицированные на шаге 4, или новые элементы дизайна, которые могут быть идентифицированы, анализируются, чтобы определить, как они влияют на производительность сценариев качества, представленных в дереве полезности, созданном на шаге 5.

• Анализ элементов дизайна, изученных на шаге 4.

В зависимости от типа элемента дизайна оценка будет разной. Компоненты предоставляют набор портов, которые необходимо расширить для предоставления новых услуг, которые, в свою очередь, могут быть предложены для расширения других компонентов. Необходимо оценить набор параметров, которые указывают способ определения взаимосвязи между портами (предложенный на шаге 4 и который может быть расширен на этом шаге с учетом созданного дерева утилит) в соответствии с некоторыми критериями качества. Сценарии качества должны применяться к созданной архитектуре. Команда оценки руководствуется вопросами анализа, предложенными методом, для принятия решений об архитектуре. Следует спросить, позволяют ли принятые решения достичь предложенных качественных сценариев.Если ответ отрицательный, любое из принятых решений следует пересмотреть. Некоторые вопросы, возникающие при использовании метода анализа элементов дизайна, приведены ниже.

Таблица №7. Некоторые вопросы для анализа выявленных элементов дизайна (1)

Характерная черта	Суб-характеристика	Вопросы анализа
функциональность	точность	Может ли связь между компонентами привести к неточностям в услугах, предлагаемых компонентами?
	Interoperability	Где находятся компоненты, которые позволяют системе взаимодействовать с другими системами?
надежность	зрелость	Существуют ли решения по минимизации неправильной обработки данных при обмене данными между компонентами?
	Отказоустойчивость	Как определить неисправность компонента?
КПД	Время поведения	Какова взаимосвязь между количеством компонентов разных частей архитектуры?
Ремонтопригодность	Возможность изменения, стабильность, доказательство	Как проверить правильность работы компонента? Как вы проверяете статус связи между компонентами? Как упростить замену компонентов?
портативность	Емкость Монтаж	Есть ли механизм, позволяющий определить, все ли компоненты системы установлены правильно?
	Сосуществование	Есть ли способ определить правила взаимодействия с компонентами системы, внешними по отношению к архитектуре?

• Документирование торговых точек, балансовых точек, рисков, не рисков и нерешенных вопросов.

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

1. Фаза тестирования (1)

В результате применения фаз 1 и 2 существует набор задокументированных архитектурных решений, которые были приняты с учетом созданного дерева утилит. На этом этапе принимаются решения, принятые до сих пор, и мы работаем со всеми, кто участвует в системе, чтобы создать окончательную архитектуру.

1. Обзор дерева утилит.

MECABIC предлагает использовать сценарии качества, чтобы представить интересы всех групп оценки и подтвердить, что желаемые требования к качеству были оценены. Группа оценки может облегчить разработку сценариев, используя набор шагов, предложенных на шаге 6. Сценарии дерева полезностей, которые не были рассмотрены, помещаются заинтересованными сторонами в пакет мозгового штурма, который дает возможность просмотреть недостаточно обслуживаемые сценарии. Сгенерированные сценарии сравниваются со списком, изначально рассмотренным в дереве утилит. Если рассмотрение и расстановка приоритетов совпадают, то оцениваемые сценарии можно считать адекватными для группы заинтересованных сторон в системе. Если они не совпадают,новые сценарии и / или их приоритет должны быть пересмотрены. Если между двумя группами заинтересованных сторон не достигнуто соглашение, возможно, их интересы не были адекватно представлены. Заинтересованные стороны должны также проанализировать сценарии, которые уже были оценены, чтобы убедиться, что они получили соответствующую важность. После рассмотрения нового сценария можно представить три случая:

1. Сценарий дублирует сценарий, уже рассмотренный в дереве утилит. Сценарий становится листом существующей ветви. Для сценария нет ветви, потому что он ранее не рассматривался.

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

1. Обзор определенных элементов дизайна.

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

1. Фаза генерации окончательной архитектуры и отчета (1)

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

1. Генерация договоров.

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

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

Чтобы завершить применение метода, краткое изложение его применения представляется в устной и / или письменной форме. Затем необходимо включить следующие документы, с которых началась оценка:

1. Бизнес-контекст Требования к качеству Созданная архитектура Анализ выявленных элементов дизайна Набор согласованных сценариев Набор вопросов для оценки атрибутов Дерево прибыли Документирование без рисков Конфиденциальные вопросы и точки переговоров

ЧАСТИЧНЫЕ ВЫВОДЫ

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

ВЫВОДЫ

• Хотя компонентная разработка программного обеспечения обещает значительно повысить уровень качества систем, оценка архитектуры программного обеспечения по-прежнему важна. Однако, чтобы применить традиционные методы архитектурной оценки, необходимо адаптировать их к характеру компонентов, чтобы применить метод MECABIC. Как в проанализированных методах, так и в предложенном, "сценарная техника" для оценки архитектур является наиболее подходящей. используется в качестве проверки степени соответствия определенного атрибута качества системным требованиям. Следует подчеркнуть, что метод оценки не лучше другого, а, скорее, позволяет лучше оценивать данный атрибут качества при определенных условиях, поэтому в зависимости от условий и того, что вы хотите оценить,будет использоваться метод оценки (который не обязательно должен быть единственным).

РЕКОМЕНДАЦИИ

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

• БИБЛИОГРАФИЯ Метод оценки архитектуры программного обеспечения на основе компонентов (MECABIC). Александр Гонсалес, Маризе Михарес, Луис Э. Мендоса, Анна Гриман, Мария Перес. Колумбия, Мексика: сн., 2005 г., том 1. Эрика Камачо, Фабио Кардесо, Габриэль Нуньес. Программные архитектуры. Рейносо, Карлос MSDN. MSDN. 26 июня 2006 г. http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.mspx. Оценка программных архитектур. Часть 1. Обзор. Гомес, Омар Сальвадор Гомес. 01, Мексика: Brainworx SA, 2007. 1870-0888. Густаво Андрес Брей, Гастон Эскобар, Николас Пассерини и Хуан Ариас.Архитектура ИТ-проекта. Архитектурная оценка. Буэнос-Айрес: Национальный технологический университет. Региональный факультет Буэнос-Айреса - Департамент систем, 2005. Хорхе Триньянес, Мария де лас Ньевес Фрейра. Управление программным обеспечением. Управление программным обеспечением. 2006. http://www.fing.edu.uy/inco/cursos/gestsoft/. Кляйн, Марк. SEI (Институт инженерии программного обеспечения). SEI (Институт инженерии программного обеспечения). Университет Карнеги-Меллона, 2007 г. http://www.sei.cmu.edu/architecture/ata_method.html. Климент, Пол. SEI (Институт разработки программного обеспечения). SEI (Институт разработки программного обеспечения). Август 2000 г. http://www.sei.cmu.edu/publications/documents/00.reports/00tn009.html. Std. Z39-18298-102. Оценка программных архитектур. Часть 2. Методы оценки.Гомес, Омар Сальвадор Гомес. 02, Мексика: Brainworx SA, 2007. 1870-0888.SEI (Институт разработки программного обеспечения). SEI (Институт разработки программного обеспечения). Университет Карнеги Меллон. www.sei.cmu.edu/architecture/arid.html.

Скачать оригинальный файл