Источник: SEI
September 2007
В этом отчете описывается, как архитектурные тактики основаны на параметрах моделей атрибутов качества.
Архитектурная тактика — это дизайнерское решение, которое влияет на то, насколько хорошо архитектура программного обеспечения соответствует определенному атрибуту качества.
В этом отчете описывается, как тактика основывается на параметрах моделей атрибутов качества.
Тактика предоставляет архитектурные средства настройки этих параметров, что, в свою очередь, может улучшить поведение результирующей системы, зависящее от атрибута качества.
В этом отчете обосновывается тактика модифицируемости с использованием устоявшихся концепций сцепления, сплоченности и стоимостной мотивации в качестве средств определения интересующих параметров. Затем описываются различные тактики, основанные на их способности контролировать эти параметры. В отчете также описывается стандартный набор архитектурных паттернов и их варианты с точки зрения использования этих тактик.
Модифицируемость — это одно из свойств программной системы, которое инженеры-программисты признают важным на протяжении многих лет. Основные концепции сцепления, сцепления и сокрытия информации возникли в 1970-х годах [Stevens 1974, Parnas 1972].
Большое количество архитектурных шаблонов также предназначено для поддержки изменяемости системы [Buschmann 1996]. В 2003 г. Басс и его коллеги представили концепцию архитектурной тактики модифицируемости для определения архитектурных преобразований, поддерживающих достижение модифицируемости [Bass 2003].
В этом отчете мы связываем сцепление и сплоченность с тактикой, а тактику с паттернами
Рисунок 1 представляет собой базовую модель теории массового обслуживания. События поступают, ставятся в очередь, обслуживаются сервером, отправляются в другую очередь, обслуживаются другим сервером, а затем выходят из системы.
Архитектурная тактика — это преобразование архитектуры, влияющее на параметры лежащей в основе модели атрибутов качества, которая в нашем примере является базовой моделью теории массового обслуживания
Три замечания, которые можно сделать об архитектурной тактике :
- Идентификация тактики зависит от определения параметров модели. Нам не нужны конкретные значения параметров или результирующие значения задержки и пропускной способности, чтобы определить тактику. Модель должна быть достаточно проанализирована, чтобы определить направление изменения отклика на основе направления изменения параметра. Например, сокращение среднего времени обслуживания приведет к уменьшению задержки и увеличению пропускной способности. Чтобы сделать это утверждение о направлении изменения, нет необходимости предсказывать величину изменения.
- Модель не обязательно должна быть подробным описанием системы. Добавление дополнительных деталей к модели добавляет дополнительные параметры, так что наш список параметров выше не является полным. Имея модель, мы можем определить все ее параметры. Детализация модели добавляет больше параметров. Например, можно критиковать рисунок 1 за то, что он не отражает классы заданий или очереди для сети. Эта критика основана на аргументе, что модель не отражает достаточно деталей для реалистичных прогнозов. Однако мы используем модель не для прогнозов, а только для идентификации параметров. Добавление сведений о классах заданий или очередях для сети добавит параметры и позволит нам определить дополнительные тактики, но это не противоречит идентификации параметров.
- Мы не утверждаем, что тактики в этом отчете полны, только то, что они представляют собой преобразования для изменения параметров. Параметры модели представляют собой возможности изменения параметров, но перечисленные тактики не обязательно являются всеми преобразованиями для их изменения. Например, существует несколько тактик производительности для сокращения среднего времени обслуживания, но возможны и дополнительные преобразования для сокращения этого времени. Мы ожидаем, что наши списки тактик включают наиболее распространенные приемы.
Аргумент, который мы приводим в пользу модифицируемости, аналогичен. Мы определяем несколько моделей атрибутов качества для модифицируемости и определяем параметры для них. Как только параметры определены, мы описываем некоторые архитектурные тактики, которые будут влиять на эти параметры, и мотивируем их с точки зрения связи между параметрами, на которые они влияют, и предсказаниями модели.
Три категории работы обеспечивают контекст для этого отчета: (1) связь и связность, (2) шаблоны и (3) методы достижения модифицируемости.
Стивенс, Майерс и Константин ввели понятия сцепления и сцепления в 1974 г. [Stevens 1974].
«Сцепление — это мера силы ассоциации, устанавливаемой соединением одного модуля с другим», и «связь уменьшается, когда отношения > между элементами, не входящими в один и тот же модуль, сведены к минимуму» [Стивенс, 1974, с. 117 и 121].
Сплоченность является мерой взаимосвязи между обязанностями конкретного модуля . Мы не будем пытаться резюмировать работу, основанную на связности и связности, которая была проделана с тех пор, за исключением того, что отметим, что эти концепции оказали очень большое влияние. Наше перечисление тактик основано на связности и сплоченности.
Архитектурные паттерны также оказали большое влияние с момента их введения Бушманном и его коллегами в 1996 г. [Buschmann 1996]. Коллекция архитектурных образцов, представленная этими авторами, является наиболее цитируемой. Они определяют архитектурный шаблон как «выражение фундаментальной схемы структурной организации программных систем. Он предоставляет набор предопределенных подсистем, определяет их обязанности и включает в себя правила и рекомендации по организации отношений между ними» [Бушманн, 1996, с. 12]. Мы продемонстрируем, как эти шаблоны и их варианты могут быть выражены с точки зрения архитектурной тактики.
Казман и Басс ввели несколько «единичных операций» в качестве первой попытки определить примитивы, используемые для достижения различных качеств [Казман, 1994].
Разделение — это единичная операция выборки. Набор единичных операций никогда не основывался на теории, а был получен из экспертной практики. Впоследствии архитектурные тактики были введены для множества различных атрибутов качества [Bass 2003, Ch. 5]. Тактика модифицируемости также была получена из экспертной практики и никогда не основывалась на теоретической основе модифицируемости. В этом отчете мы предоставляем теоретическое обоснование качества модифицируемости.
Модифицируемость — это атрибут качества архитектуры программного обеспечения, который относится к «стоимости изменений и относится к легкости, с которой программная система может приспосабливаться к изменениям» [Northrop 2004, p. 28].
Это поднимает четыре вопроса:
- Кто вносит изменения?
- Когда вносятся изменения?
- Что может измениться?
- Как измеряется стоимость изменений?
В этом отчете мы фокусируемся на модифицируемости следующим образом:
• Кто вносит изменения? Под модифицируемостью мы подразумеваем изменения, вносимые архитектором и разработчиком, хотя в других ситуациях модификации могут производиться другими участниками программной системы.
• Когда вносятся изменения?
На рис. 2 показано несколько моментов жизни фрагмента проекта, важных для нашего обсуждения. Часть системы спроектирована и позже изменена. Затем модифицированная часть системы развертывается и выполняется. В других ситуациях изменения могут быть внесены после развертывания, но это не представлено. Обратите внимание, что это представление не зависит от процесса разработки.
В водопадном процессе время относится ко всей системе, а в итеративном процессе время относится к той части системы, которая добавляется или изменяется в текущей итерации.
• Что может измениться?
Определение того, какие элементы должны быть изменены, является важной частью процесса спецификации и часто упускается из виду. Мы изучаем, как потенциал модифицируемости элементов может влиять на общие затраты. Определение потребностей конкретных элементов дизайна в изменяемости на ранних этапах процесса создания архитектуры снижает затраты и экономит время в целом, особенно если изменяемость должна быть гибкой. В этом отчете мы обеспокоены решениями, принятыми в отношении фрагмента проекта во время проектирования. Эти решения повлияют на сложность внесения конкретной модификации в этом фрагменте.
• Как измеряется стоимость изменений?
После указания изменения необходимо спроектировать, внедрить, протестировать и развернуть новую реализацию. Все эти действия имеют связанные с ними затраты, которые можно измерить. Наша мера модификации — это стоимость конкретной модификации для конкретного фрагмента конструкции. Любая тактика, основанная на соединении и связности, будет использоваться во время разработки, чтобы снизить стоимость последующего изменения во время модификации. Другие факторы, которые мы могли бы рассмотреть, включают стоимость реализации тактики, альтернативные издержки невозможности использовать деньги, потраченные на реализацию тактики, для других целей в период между временем разработки и временем модификации, вероятность того, что конкретная модификация будет на самом деле будет сделано, и количество раз, когда делается модификация определенного типа.
Решение о применении той или иной тактики является сложной функцией этих и других факторов. См. работу Ozkaya, Kazman и Klein для обсуждения одного метода лечения этих факторов [Ozkaya 2007]. В этом отчете мы игнорируем эти дополнительные факторы и интересуемся только стоимостью внесения конкретной модификации после того, как тактика была реализована.
Например, архитектор может выбрать применение тактики инкапсуляции к модулю во время разработки в ожидании модификаций, которые потребуются внутри модуля в более позднее время.
Стоимость реализации этой тактики для модуля включает определение интерфейса и ограничение внешнего доступа к модулю для использования только этого интерфейса. Существует также стоимость внесения изменений внутри модуля после его инкапсуляции. Эта стоимость, предположительно, будет ниже, чем была бы, если бы мы не создавали интерфейс.
Эта вторая стоимость — стоимость модификации с учетом применения тактики — является единственной стоимостью, на которой мы сосредоточимся в этом отчете.
Модель качества, имеет две категории, связанные с изменениями: ремонтопригодность и переносимость [ISO 2001]. Она определяет ремонтопригодность как возможность модификации программного продукта, а переносимость — как возможность переноса программного продукта из одной среды в другую. В нашем понимании переносимость
• была бы формой модифицируемости, если перенос продукта в другую среду требует изменения продукта
• не была бы формой модифицируемости, если возможность выполнения в другой среде уже существовала в продукте. подмножество того, что мы называем модифицируемостью.
Модифицируемость как концепция недостаточно конкретна, чтобы помочь разработчикам. Они должны знать, какие конкретные модификации ожидаются, чтобы применять соответствующую тактику, позволяющую осуществить эти модификации. В нашем обсуждении каждой тактики мы определяем модификацию, для которой эта тактика полезна.
Тактика модифицируемости — это преобразование архитектуры, улучшающее модифицируемость этой архитектуры.
Мы применяем подход, который мы набросали для производительности, к модифицируемости.
То есть мы начинаем с абстрактной модели проблемы модифицируемости, основанной на связности и связности, а затем определяем параметры этой абстрактной модели.
Модель, с которой мы начинаем, требует от нас более точного определения того, что понимается под связью и связностью, и использования этого понимания для определения соответствующих параметров.
Во-первых, мы обсудим сцепление и сплоченность и их значение. Их исходные определения даны в терминах модулей, но наш аргумент включает изменение функций, вычисляемых в модуле, и использует концепцию ответственности для описания вычислений модуля.
В частности, нас интересуют отношения между обязанностями. Мы вводим понятие «силы» связи двух обязанностей, чтобы мы могли утверждать, что тактика модифицируемости уменьшит силу связи и, следовательно, снизит стоимость модификации.
Мы определяем связь и связность с точки зрения ответственности, которая является концепцией в контексте программного обеспечения, происходящей из объектно-ориентированного проектирования [Wirfs-Brock 2003].
Ответственность — это действие, знание, которое необходимо поддерживать, или решение, которое должно выполняться программной системой или элементом этой системы. Одной из характеристик компьютерной системы являются обязанности системы, их назначение модулям и взаимосвязь между обязанностями [Clements 2003].
Мы предполагаем, что с каждой ответственностью связана стоимость модификации — стоимость модификации этой единственной обязанности.
Это явное упрощение, поскольку некоторые модификации конкретной ответственности могут стоить больше, чем другие. Дисперсия затрат в зависимости от типа модификации может быть смоделирована путем введения вероятностных функций. Наш аргумент не зависит от конкретных присвоенных значений, а скорее от идеи о том, что выполнение определенных преобразований не увеличит общую стоимость и снизит стоимость определенных модификаций.
Возможность реорганизации обязанностей является важным аспектом нашего обсуждения. Их можно было разложить:
например, ответственность за «управление банковскими счетами» может быть разделена на «аутентификацию пользователя», «просмотр счетов» и «перевод средств».
Обязанности могут быть объединены:
например, просто переверните предыдущий пример.
Их также можно было перемещать из одного модуля в другой. Любую реорганизацию можно рассматривать как разложение на более мелкие обязанности с последующим слиянием для получения нового набора обязанностей. Некоторые из наших тактик разделяют обязанности, некоторые объединяют обязанности, а третьи распределяют обязанности между модулями.
Мы используем одно отношение между двумя обязанностями — «сила» связи. Это отношение формально не определено Стивеном, Майерсом и Константином, но имплицитно присутствует в их обсуждении связи [Stevens 1974]. Мы определяем силу связи двух обязанностей как вероятность того, что модификация одной обязанности распространится на другую. Интуитивно две обязанности имеют высокую силу связи, если одна из них хорошо знает другую.
Это знание предполагает, что изменения одной обязанности в одном из модулей, возможно, должны быть отражены в другом. Используя наш пример с банком, модификация «аутентифицировать пользователя» может распространиться на «перевод средств». Мы используем силу связи, чтобы обеспечить вероятность того, что это распространение произойдет. Это частный случай концепции зависимости UML; хотя в UML зависимость либо существует, либо ее нет [OMG 2005]. В UML нет понятия силы зависимости.
Средняя стоимость изменения ответственности — это средняя стоимость непосредственного изменения этой ответственности плюс средняя стоимость изменения всех обязанностей, на которые распространяются дополнительные модификации.
Предположение, лежащее в основе определения высокой связанности, заключается в том, что модификации будут распространяться на те обязанности, которые сильно связаны с изменяемой ответственностью.
Связь — это асимметричное отношение: сила связи между ответственностью А и ответственностью В не обязательно равна силе связи между ответственностью В и ответственностью А.
Теперь мы можем определить два параметра, которые будем использовать для мотивации тактики модифицируемости.
Обратите внимание, что эти параметры не зависят от какой-либо конкретной модели прогнозирования затрат:
• средняя стоимость изменения одной обязанности: снижение средней стоимости модификации одной обязанности A и отсутствие других изменений снизит среднюю стоимость любой модификации, влияющей на A. Тактика что разделение обязанностей снизит среднюю стоимость внесения изменений в разделяемую ответственность.
• связь: уменьшение силы связи между двумя обязанностями A и B и отсутствие других изменений уменьшит стоимость любой модификации, влияющей на A. Тактики, уменьшающие связанность, — это те, которые устанавливают разного рода барьеры между обязанностями A и B.
Мы определили связь (хотя еще не сплоченность) с точки зрения ответственности.
Далее мы обсудим, что происходит, когда вводятся модули. В представлении «Модуль» [Clements 2003] обязанности назначаются модулям. Модули можно разложить и сформировать иерархию. Когда мы говорим об обязанностях A и B как о находящихся в одном модуле, мы имеем в виду самый глубокий модуль в иерархии, который содержит обе обязанности.
«Связь (Coupling) уменьшается, когда отношения между элементами, не входящими в один и тот же модуль, сведены к минимуму. Есть два способа добиться этого — свести к минимуму отношения между модулями и максимизировать отношения между элементами в одном и том же модуле» ? [Стивенс, 1974, с. 121].
Максимизация взаимосвязей между элементами в одном и том же модуле — это определение связности.
Мы превращаем сплоченность в наш третий параметр:
• сплоченность (cohesion) : если ответственность A имеет высокую степень связи с ответственностью B,
стоимость изменения ответственности A меньше, если A и B расположены в одном и том же модуле, чем если бы они были расположены в разных модулях.
В нашем использовании параметров мы не указываем явно на «высокую силу связи».
Мы предполагаем, что сила связи известна разработчикам через их понимание специфики решения.
Дополнительный параметр основан на том, когда в жизни системы происходит конкретная модификация. Сцепление и сцепление (Coupling and cohesion) легко переводятся в архитектурные термины, поскольку они имеют дело со структурными концепциями. Тактика, которую мы рассматриваем в этом разделе, называемая «тактикой отсроченного связывания», мотивирована соображениями стоимости.
Большинство моделей затрат основано не на структурных концепциях, а на некотором измерении объема функциональности и навыков разработчиков. Следствием этого для нас является то, что наша тактика основана на одном фундаментальном предположении: пока есть соответствующая подготовка, чем позже в жизни системы происходит модификация, тем меньше она будет стоить.
Ключевыми моментами являются «подходящая подготовка» и тот факт, что мы не учитываем стоимость подготовки к модификации (аналогично аргументам о связности и связности). «Подходящая подготовка» — это то, что отличает плановое изменение от незапланированного ремонта.
На рис. 2 показаны несколько различных периодов жизни фрагмента конструкции. Соответствующая подготовка происходит во время разработки и позволяет применять тактику отложенного связывания во время модификации, развертывания, начала выполнения или выполнения системы. Кроме того, мы будем утверждать, что подходящая подготовка основана на применении тактики сцепления и сцепления. То есть подготовка к отложенному решению основана на тактике, основанной на соображениях сцепления и сплоченности. Отсрочка принятия конкретного решения основывается на соображениях стоимости.
Каждая деятельность, время которой указано на рисунке 2, имеет стоимость.
Если на рис. 2 действие происходит позже, чем время модификации, с ним связаны затраты. Если это происходит раньше, стоимость не учитывается. Если модификация выполняется во время выполнения, например, с помощью сервера имен, модификация сама по себе не нуждается в тестировании или развертывании; следовательно, стоимость тестирования и развертывания для этой модификации равна нулю.
Четвертый параметр, который мы определяем исходя из соображений стоимости, это:
• время жизненного цикла модификации:
надлежащим образом подготовленная модификация, выполненная в конце жизненного цикла, будет стоить меньше, чем такая же модификация, сделанная ранее, потому что готовность системы означает, что некоторые из стоимость жизненного цикла будет равна нулю для модификаций позднего жизненного цикла.
Теперь мы готовы перечислить тактики модифицируемости. Ключевые моменты для рассмотрения:
• Тактика модифицируемости — это решение архитектурного проекта, которое влияет на параметры, основанные на связи и связности или на возможности пропустить определенные этапы жизненного цикла для фрагмента проекта.
• Мы хотим управлять тремя параметрами на основе связности и связи с помощью архитектурных средств. Мы будем использовать эти параметры как средство организации тактики.
• Один параметр основан на стоимости пропуска шагов в жизненном цикле фрагмента проекта. Тактика, вытекающая из этого параметра, становится возможной благодаря применению одной или нескольких тактик, основанных на соединении и сплочении.
• Мы должны быть конкретны в отношении ожидаемых модификаций, стоимость которых будет снижена за счет использования тактики.
Тактика, которую мы определим, организована на основе параметров моделей сцепления и сплоченности:
• снижение стоимости изменения одной обязанности. Разделение ответственности.
• повышение согласованности. поддержание семантической согласованности.
• Абстрактные общие службы.
• Снижения связанности
• Используйте инкапсуляцию.
• Используйте обертку.
• Поднимите уровень абстракции.
• Используйте посредника.
• Ограничение каналов связи.
Кроме того, мы утверждаем, что тактика, основанная на связывании и сплочении (coupling- and cohesion-based tactics) , делает возможной тактику отложенного связывания.
Отложенные привязки, которые мы рассматриваем, организованы на основе жизненного цикла системы или времени выполнения:
• время кодирования — — — использование аспектно-ориентированного программирования. Используйте полиморфизм. Параметризовать модули.
• время сборки — используйте замену компонентов.