WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     | 1 |   ...   | 4 | 5 || 7 | 8 |   ...   | 9 |

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

Наиболее известной, среди используемых на практике, является формулировка отмеченной задачи и методика е решения в рамках метода анализа иерархий. Однако в архитектурной практике не распространено представление задачи выбора стиля как решения многокритериальной задачи в условиях неопределнностей. Этому мешает и тот факт, что в конкретной разработке SIS могут быть использованы несколько стилей, объединнных во взаимодополнительный комплекс. Взаимодополнительность стилей является типичным архитектурным решением в разработках сложных SIS.

Принято упрощать задачу выбора стилей до такого представления ситуации выбора, когда ситуация представлена некоторой совокупностью требований, а множество стилей – табличной структурой, в которой для каждого стиля отмечен тот набор требований, который он (в определнной степени) способен поддержать. Примером такой таблицы является результат сопоставления стилей, проведнный в [29] и пригодный для его использования в WEB-приложениях. Сопоставления архитектурных стилей проведены по характеристикам качества, что согласуется с подходами к разработке архитектуры с позиций качества.

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

В работе [29] представлены детальные характеристики стилей и обоснования для каждой оценки, зафиксированной в Таблице 5.

Таблица 5.

Архитектурный стиль Каналы и + - + + + + + фильтры Репозитарий ++ + + Клиент- - - + + + + серверный Многоуровневый - + + + + Многоуровневый - ++ + ++ + + клиентсерверный Виртуальная + - +- + + - + - машина Одноранговый - - + + + + Мобильный + ++ +- ++ + + - + 3.4. Архитектура и характеристики качества 3.4.1. Специфика требований к качеству SIS Выше не раз утверждалось, что на начальных этапах разработки SIS принципиальная роль возлагается на архитектурные решения по обеспечению требований к SIS, которые распределены по реализации SIS и отражают определнные «интересы» групп использования Исполнимость Эффективность Масштабируeмость Простота Развиваемость Расширяемость Привычность Конфигурируемость Повторность Визуализируемость Мобильность Наджность лиц, заинтересованных в разработке SIS и е использовании. К числу таких требований, в первую очередь, относятся характеристики качества SIS, общепринятая система которых определена стандартом ИСО/ИЭК- 9126.

Необходимо отметить, что проявления характеристик качества при эксплуатации SIS создают «слой» вокруг е базовых функциональностей [86], что образно отражено на рис.25. У такого слоя два проявления:

- во-первых, большинство характеристик качества воспринимаются пользователем SIS со стороны его контактного взаимодействия с SIS;

- во-вторых, характеристики качества формулируются, учитываются и оцениваются, начиная с ранних шагов разработки SIS.

Точка зрения Точка зрения Мобильность:

Адаптируемость Настраиваемость Совместимость Заменоспособность Функциональность:

Надежность:

Нормосоответствие Пригодность Завершенность Точность Отказоустойчивость Комплексируемость Восстанавливаемость Безопасность Нормосоответствие Нормосоответствие Базовые функциональности SIS Эффективность:

Удобство использования:

Время Понимаемость Ресурсы Осваиваемость Нормосоответствие Управляемость Сопровождаемость:

Привлекательность Анализируемость Нормосоответствие Модифицируемость Стабилизированность Тестируемость Точка зрения Нормосоответствие Точка зрения Рис. 25. Система функциональностей SIS Реальные (достигнутые в процессе разработки) характеристики качества SIS материализованы в е реализации, причем элементы материализации качества распределены среди базовых элементов SIS или встроены в них. В объектную структуризацию SIS «вшиты» (по аспектно-ориентированной терминологии) аспектные решения, обеспечивающие запланированные (с позиций качества) точки зрения на SIS.

В процессе разработки и использования SIS правомерны и практически полезны, например, «интерес» к SIS с позиций «удобства использования» или «сопровождаемости», а также «интерес» с позиции «безопасности» SIS. Практика «материализации интересов к качеству SIS» показывает, что такие интересы не удатся представить с помощью подходящего «вида» с точки зрения соответствующего качества. «Следы интереса» (метрики качества) приходится распределять по разным «видам», определнным в соответствии со стандартом IEEE-1471, и даже по разным моделям и документам «видов». «Интересы» конкретного качеств пересекают другие интересы (относятся к типу crosscutting concerns), в том числе и интересы других качеств.

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

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



Практика показывает, что обеспечение качества SIS не только запрос конкурентного рынка. Управляемая работа с требованиями качества в рамках АОП, включнная, например, в объектно-ориентированную технологию Rational Unified Process (RUP), способна дополнительно повысить успешность разработок SIS [40 ].

3.4.2. Подход к построению архитектуры с позиций качества Основной вклад в понимание и построение архитектуры с позиций качества внесли исследования и разработки института SEI [6], в рамках которых разработку SIS целесообразно проводить в соответствии со схемой, представленной на рис. 26. Схема указывает, что характеристики качества выполняют ключевую роль в построении архитектуры, которая, в свою очередь, управляет процессом разработки SIS. Разумеется, функциональность должна быть отражена в архитектуре обязательно, но варианты е реализации должны быть сбалансированы с достижением требуемых характеристик качества, а проблемы такого баланса лежат в области качества.

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

С Спецификация И системы С Определяет уровень качества Т Е Атрибуты системы качества М А Управляет Программная архитектура Управляет Система возможностей и Система качества Рис. 26. Управление качеством SIS Для таких рассуждений (а значит и для построения архитектуры) было предложено использовать сценарии, в каждом из которых отражена определнная «единица» реагирования SIS на заданные условия. Была предложена, испытана и внедрена в практику следующая модель сценария:

1. Источник стимула: сущность (актор, человек, компьютер,…), порождающая стимулы.

2. Стимул: предполагаемое воздействие на SIS.

3. Среда: условие или состояние, при котором воздействует стимул.

4. Артефакт: то, на что воздействует стимул.

5. Отклик: активность в ответ на стимул.

6. Мера отклика: требование, отражающее определнное проявление качества.

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

В таблице 6 и таблице 7 с иллюстративными целями (для деталей понимания) приведены примеры сценариев и значений каждой из составных частей сценария.

Таблица Часть сценария Возможное значение Источник Внутренний или внешний для системы Стимул Ошибка, упущение, сбой Артефакт Процессоры системы, каналы коммуникации Среда Нормативное реагирование. Отклонения от запланированных режимов Отклик Система должна обнаруживать и демонстрировать определнные события, указание на необходимость «ремонта» Мера реакции Допустимое время реагирования, допустимое время на устранение «неполадок» Таблица Часть сценария Возможное значение Источник Конечный пользователь, разработчик, системный администратор Стимул Желаемое добавление/модификация/ изменение функциональности, атрибута качества Артефакт Интерфейс, платформа, среда; система, взаимодействующая с разрабатываемой системой Среда Реальное время, время компиляции, время связывания, время разработки Отклик Локальные точки в архитектуре, которая должна быть изменена; модификации, которые не должны влиять на другие функции Мера реакции Цена в терминах усилий, финансовых средств и др.

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

Portion of Possible Values Portion of Possible Values Scenario Scenario Source Internal/external to system Source End user, developer, system administrator Stimulus Fault, omission, crash, timing, response Stimulus Wishes to add/delete/modify/vary functionality, Artity attribute, caSystem’s processors, communication channels, qualifact pacity persistent storage, processes Artifact System user interface, platf operation, degraded mode orm, environment; system Environment Normal that inter-operates with target system Response System should detect gn time Environment At runtime, compile time, build time, desievent, record it, notify appropriate parties, disable source of events, down for repair Response Locates places in architecturie to me,modified; makes be Response Availabil ty ti time interval, repair time modification without affecting other functionality;

Measure Группа сценариев 1 tests modification; deploys modification Группа сценариев N Группа сценариев … Response Cost in terms of number of elements affected, effort, Measure money; extent to which this affects other functions or quality attributes Рис. 27. Группирование сценариев Формирование и обработка сценариев подготавливают последующие действия с этой информацией. Детали таких действий будут представлены в следующем пункте обзора, причм не только с позиций методов, разработанных специалистами SEI.





В настоящее время популярна позиция, предложенная [73], которая исходит из семантического расширения каркаса IEEE-1471, представленного на рис. 28.

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

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

Перспектива безопасности Перспектива доступности Перспектива выполнения Перспектива нахождения Перспектива полезности Перспектива регулирования Перспектива поддержки и т.д.

Функциональный вид Вид разработки Информационный вид Вид развртывания Информационный вид Операционный вид Рис. 29. Отношения между видами и перспективами 3.5. Архитектурное проектирование 3.5.1. Основы проектирования архитектур Архитектура является одной из важнейших форм существования SIS, которая до е разработки не существовала или существовала как реализация предшествующей версии или версий. А значит, на определнном этапе разработки SIS с помощью определнного процесса и средств архитектура SIS должна быть создана, возможно, в новой версии.

Как и любой продукт деятельности, архитектура создатся для выполнения определнных позитивных функций, конкретнее, для обслуживания процесса разработки SIS, а также е использования и сопровождения. Основные задачи, в работе с которыми от наличия SIS достигаются определнные позитивы, были названы в п. 1.1.3. РаАрхитектура стороны Заинтересованные зумеется, позитивы достигаются не просто от наличия архитектуры SIS, а от того насколько при построении SIS были учтен факт и степень их достижения.

На практике широко используются архитектурно-центрированная разработка (Architecture-centric development) систем, интенсивно использующих ПО. Такой тип разработки включает:

- создание бизнес use-case для разрабатываемой системы;

- осознание (понимание) требований;

- создание или выбор архитектуры SIS;

- документирование и обсуждение архитектуры;

- анализ и оценка архитектуры;

- материализация системы на базе архитектуры;

- оценка и подтверждение того, что материализация SIS соответствует архитектуре.

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

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

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

Требования Требования предметной пользователей области АС Выбор:

Архитектурного стиля Функциональные Нефункциональные Образца архитектуры требования требования Архитектурной тактики Группирование по Действия по учту хаподсистемам АС рактеристик качества Синтез Коррекция Анализ Рис. 30. Построение архитектуры Процесс создания «архитектуры SIS» состоит из этапов, включающих этап е проектирования. Более точно, процесс создания архитектуры SIS, встроенный в процесс разработки SIS, носит спиралевидный итеративный характер, что приводит к возвратам к вопросам создания архитектуры SIS от «витка спирали к витку».

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

Pages:     | 1 |   ...   | 4 | 5 || 7 | 8 |   ...   | 9 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.