Как вы помните, по результатам оценки программной системы по методу АТАМ в нашем распоряжении оказался ряд документированных артефактов.

• Описание коммерческих задач, определяющих успешность системы.

• Набор архитектурных представлений, документирующих существующую или предложенную архитектуру.

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

• Ряд выявленных рисков.

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

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

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

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

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

Короче говоря, метод СВАМ исходит из предположения о том, что архитектурные стратегии (как совокупность архитектурных тактик) оказывают влияние на атрибуты качества системы, а те, в свою очередь, предоставляют заинтересованным лицам некоторые выгоды. Эти выгоды мы называем полезностью (utility). Любая архитектурная стратегия отличается той или иной полезностью для заинтересованных лиц. С другой стороны, есть издержки (стоимость) и время, которые необходимо потратить на реализацию этой стратегии. Отталкиваясь от этой информации, метод СВАМ помогает заинтересованным лицам в процессе выбора архитектурных стратегий, характеризующихся максимальной прибылью на инвестированный капитал (return on investment, ROI), — другими словами, наиболее выгодных с точки зрения соотношения выгод и издержек.

4.4.2.2.Реализация СВАМ

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

Рисунок 4.5 – Диаграмма процессов СВАМ

Этап 1: критический анализ сценариев. Критический анализ сценариев проводится в рамках АТАМ; на этом же этапе заинтересованные лица могут формулировать новые сценарии. Приоритеты расставляются в соответствии с потенциалом сценариев в контексте выполнения коммерческих задач системы; по результатам этапа для дальнейшего рассмотрения отбирается треть от общего первоначального числа сценариев.

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

Этап 3: расстановка сценариев согласно приоритетам. Каждому заинтересованному лицу выделяется 100 голосов, которые он берется распределить между сценариями, исходя из их желаемых значений реакции. После подсчета голосов для дальнейшего анализа остается только половина сценариев. Сценарию с наивысшим рангом присваивается вес 1.0, и, отталкиваясь от него, значения веса устанавливаются для всех остальных сценариев. Именно эти значения впоследствии задействуются при вычислении общей выгоды стратегии. Помимо прочего, на рассматриваемом этапе составляется список атрибутов качества, которые заинтересованные лица считают значимыми.

Этап 4: установление полезности. Для сценариев, оставшихся после проведения этапа 3, определяются значения полезности всех уровней реакции (наихудшего, текущего, желаемого, наилучшего) атрибута качества.

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

Этап 6: определение полезности «ожидаемых реактивных уровней атрибута качества путем интерполяции. Исходя из установленных значений полезности (отраженных на кривой полезности) для рассматриваемой архитектурной стратегии определяется полезность желаемого уровня реакции атрибута качества. Эта операция проводится для каждого из перечисленных на этапе 3 значимых атрибутов качества.

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

Этап 8: отбор архитектурных стратегий с учетом ROI, а также ограничений по стоимости и времени. Для каждой архитектурной стратегии определяются стоимостные и временные факторы. Значение ROI для стратегий определяется как отношение выгоды к издержкам. Архитектурные стратегии упорядочиваются по рангу согласно значениям ROI; впоследствии бюджет в первую очередь расходуется на высшие по рангу стратегии.

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

5.Технология MDA.

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

5.1.1.Концепция архитектуры, управляемой моделью

Технология Model Driven Architecture (MDA) — архитектура, управляемая моделью была разработана независимой некоммерческой организацией Object Management Group (OMG) — консорциум объектного управления. Она объединяет сотни компаний — производителей программного и аппаратного обеспечения.

В технологии MDA основным элементом проектирования считается модель.

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

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

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

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

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

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

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

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

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

Визуальные диаграммы чаще всего строятся с помощью унифицированного языка моделирования UML (Unified Modeling Language). Его стандарт разработан группой OMG для задач объектно-ориентированного проектирования

5.1.2.Модельные точки зрения и модели MDA

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

Точка зрения, независимая от вычислительных особенностей Computation Independent Viewpoint (CIV), нацелена на анализ системной среды и системных требований. Логика работы пока что не рассматривается — возможно, она еще не определена. В CIV учитываются программные, аппаратные и другие технологические ограничения, которые не связаны напрямую с внутренней архитектурой разрабатываемой программы.

Точка зрения, независимая от программно-аппаратной платформы Platform Independent Viewpoint (PIV), задает конкретные функциональные элементы системы, не зависящие от платформы. В ее рамках используются языки моделирования наподобие UML.

Точка зрения, зависящая от платформы Platform Specific Viewpoint (PSV), задает детали реализации, зависящие от используемых платформ и язы ков программирования. Она сочетает платформенно-независимую логику с дополнительными особенностями, вызванными использованием конкретной платформы или системы.

Каждая из этих точек зрения предлагает разные средства построения соответствующих моделей. Бизнес-аналитики, не знакомые с особенностями программной разработки, вырабатывают свои требования к системе на уровне CIV — с помощью так называемых вычислительно-независимых моделей (Computation Independent Model, CIM). Модели CIM задают основные требования к проекту и включают словари предметной области. Никакие технические характеристики в этих моделях не фиксируются.

Методология MDA описывает не столько моделирование, сколько метамоделирование, предусматривающее большую гибкость в конкретных, прикладных походах к моделированию.

Метамоделирование — способ описания моделей, определяющий механизмы построения конкретных моделей программных систем с помощью базового словаря и набора ограничений, налагаемых на создаваемые модели. Сегодня вместо термина BMDA корпорация Borland применяет новый термин ЕСО. Технология ECO {Enterprise Core Objects) — ключевые корпоративные объекты, — реализующая концепцию MDA, стала наиболее важным улучшением последних версий среды Delphi. Она представлена в Delphi 2006 в виде третьей версии ЕСО III. Каждый компонент ЕСО представляет собой своеобразную программную «обертку» положений концепции MDA. Он является промежуточным слоем между средствами визуального проектирования программных моделей и их конкретной реализацией на языках программирования Delphi и С#.