05 Архитектура информационных систем. Атрибуты качества. Метод ADD

Архитектура информационных систем

Архитектура и проектирование информационных систем

2

Характеристики идеальной системы

Функциональность, необходимая заказчику

Возможность построения в заданный срок

Адекватность функционирования

Надежность

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

Безопасность

Приемлемость по затратам

3

Реальные факты

• Ни одна сложная система не идеальна• Архитектура системы является искусством

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

4

5 подходов к проектированию

Календарный стиль

Стиль, основанный на управлении требованиями

Стиль, основанный на процессе разработки документации

Стиль, основанный на управлении качеством

Архитектурный стиль

5

Календарный стиль

• Calendar-driven• Основан на графике работ• Проектные решения принимаются из целей и

задач конкретного этапа• Мало внимания уделяется процессу

разработки, документации, созданию стабильных архитектур и внесению изменений

• Высокая суммарная стоимость владения в долгосрочной перспективе

6

Управление требованиями

• Requirements-driven• Основное внимание уделяется функциональным

характеристикам системы• Проектные решения принимаются исходя из

локальных целей, связанных с реализаций определенных функций

• Эффективен при устойчивых требованиях• Недостаточное внимание требованиям стандарта

ISO 9126 (управление качеством)• Нестабильность разрабатываемых архитектур

7

Процесс разработки документации

• Documentation-driven• Вырожденный вариант стиля, основанного на

управлении качеством• Ориентирован на разработку документации• Применяется в государственных и крупных

компаниях• Большие затраты времени и сил на разработку

документации в ущерб качеству кода• Создаваемая документация часто не используется

ни пользователем, ни заказчиком

8

Управление качеством

• Quality-driven• Консервативный стиль• Для разработки систем с экстремальными

характеристиками• Определенные качества системы

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

9

Архитектурный стиль

• Architecture-driven• Создание фреймворков, легко адаптируемых ко

всем потенциальным требованиям• Проектирование включает две задачи: создания

фреймворка и создание конкретной системы• Устраняет недостатки стиля, основанного на

управлении требованиями• Обеспечивает оперативное изменение

существующей и добавление новой функциональности

Атрибуты качества

11

Атрибуты качества

• Качество ИС означает, что система – успешно справляется со всеми возлагаемыми на нее

задачами, – имеет хорошие показатели надежности и приемлемую

стоимость, – удобна в эксплуатации и обслуживании, – легко сочетается с другими системами и – в случае необходимости может быть модифицирована

• Разные пользователи имеют разные точки зрения на характеристики качества ИС

• Качество ПО определяется стандартом ISO 9126

12

Модель качества по ISO 9126

Функциональность


Производительность (Эффективность)

Удобство использования (Практичность)

Удобство сопровождения

Переносимость

13

Функциональность• Functionality• Способность ПО в определенных условиях решать задачи, нужные

пользователям• Функциональная пригодность (suitability)

– Способность решать нужный набор задач• Точность (accuracy)

– Способность выдавать нужный результат• Способность к взаимодействию (interoperability)

– Способность взаимодействовать с нужным набором других систем• Соответствие стандартам и правилам (compliance)

– Соответствие отраслевым стандартам, нормативным и законодательным актам, другим регулирующим нормам

• Защищенность (security)– Способность предотвращать неавторизованный и неразрешенный доступ к

данным и программам

14


• Reliability• Способность поддерживать определенную

работоспособность в заданных условиях• Зрелость, завершенность (maturity)

– Величина, обратная частоте отказов• Устойчивость к отказам (fault tolerance)

– Способность поддерживать заданный уровень работоспособности при отказах и нарушениях правил взаимодействия с окружением

• Способность к восстановлением (recoverability)– Способность восстанавливать определенный уровень

работоспособности и целостность данных после отказа

15

Производительность

• Efficiency• Способность при заданных условиях обеспечивать

необходимую работоспособность по отношению к выделяемым для этого ресурсам

• Временная эффективность (time behavior)– Способность выдавать ожидаемые результаты, обеспечивать

передачу необходимого объема данных за отведенное время• Эффективность использования ресурсов (resource

utilisation)– Способность решать нужные задачи с использованием

определенных объемов ресурсов определенных видов

16

Удобство использования• Usability• Способность быть удобным в обучении и использовании, а также

привлекательным для пользователей• Понятность (understandability)

– Показатель, обратный усилиям, которые затрачиваются пользователями на восприятие основных понятий и осознание их применимости для решения своих задач

• Удобство работы (operability)– Показатель, обратный усилиям, предпринимаемым пользователями для

решения своих задач с помощью ПО• Удобство обучения (learnability)

– Показатель, обратный усилиям, затрачиваемым пользователями на обучение работе

• Привлекательность (attractiveness)– Способность быть привлекательным для пользователей

17

Удобство сопровождения• Maintainability• Удобство проведения всех видов деятельности, связанных с

сопровождением программа• Анализируемость (analyzability)

– Удобство проведения анализа ошибок, дефектов, недостатков, необходимых изменения и их последствий

• Удобство внесение изменений (changeability)– Показатель, обратный трудозатратам на выполнение необходимых изменений

• Стабильность (stability)– Показатель, обратный риску возникновения неожиданных эффектов при

внесении необходимых изменений• Удобство проверки (testability)

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

18

Переносимость• Portability• Способность ПО сохранять работоспособность при переносе из одного

окружения в другое, включая организационные, аппаратные и программные аспекты окружения

• Адаптируемость (adaptability)– Способность приспосабливаться к различным окружениями без проведения для

этого действия помимо заранее предусмотренных• Удобство установки (installability)

– Способность ПО быть установленным или развернутым в определенном окружении

• Способность к сосуществованию (coexistence)– Способность сосуществовать с другими программами в общем окружении, деля с

ними ресурсы• Удобство замены (replaceability)

– Возможность применения данного ПО вместо другого для решения тех же задач в определенном окружении

19

Атрибуты качества по ISO 9126-4• Эффективность

– Способность ПО предоставлять пользователям возможность решать их задачи с необходимой точностью при использовании в данном контексте

• Продуктивность– Способность ПО предоставлять пользователям определенный

результаты в рамках ожидаемых затрат ресурсов• Безопасность

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

• Удовлетворение пользователей– Способность ПО приносить удовлетворение пользователям при

использовании в заданном контексте

Атрибуты качества системы

• Availability (Доступность)

• Modifiability (Модифицируемость)

• Performance (Производительность)

• Security (Безопасность)

• Testability (Тестируемость)

• Usability (Практичность)

Коммерческие Атрибуты

• Time (Сроки выхода на рынок)

• Cost (Стоимость и прибыль)

• Life Time (Срок службы системы)

• Target market ( Целевой рынок)

• Product Schedule (График развертывания продукта)

• Interoperability (Интеграция с существующими системами )

Атрибуты качества архитектуры

• Integrity (Целостность)

• Portability (переносимость)

• Reusability (Возможность повторного использования)

• Flexibility (Гибкость)• Reliability

(Надежность )• Robustness

(Живучесть)

20

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

Attribute-Driven Development

22

Архитектурно-экономический цикл

• Архитектура – результат технических, экономических, и социальных влияний

• Архитектура влияет на технические, экономические и социальные аспекты

23

Сценарий атрибута качества

24

Сценарий атрибута качества• Источник воздействия

– Субъект (человек, компьютерная система или объект, обладающий поведением), генерирующий воздействие

• Воздействие– Внутренний или внешний фактор, вызывающий реакцию системы

• Окружение– Условия , в которых происходит наблюдаемое воздействие. Система может

быть в рабочем режиме, работать с перегрузкой.• Артефакт

– То, на что оказывается воздействие. Совокупность систем, вся система, часть системы

• Реакция– Ответ на пришедшее воздействие

• Мера реакции– Когда происходит реакция, она должна быть измерена, чтобы сравнить с

исходными требованиями

Пример сценария «надежность вратаря»

Источник:Любой Игрок

Стимул:Удар по воротам

Среда:Соревновательные игры

Элемент:Вратарь Реакция:

Блокирование мяча

Измерение:Мяч должен быть не в воротах в 99% случаев атаки

25

26

Виды сценариев атрибутов качества

• Общий– Системно независимый и может быть

потенциально применен к любой системе• Частный (конкретный)– Специфичный для конкретной проектируемой

системы

27

Пример общего сценария

Реализация качества

Attribute-Driven Development

29

Тактики

• Качества достижимы через проектные решения

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

• Тактика– Проектное решение, которое влияет на

управление реакцией по атрибуту качества• Архитектурная стратегия– Совокупность тактик

30

Схема тактики

Тактика управления

реакциейСтимул Реакция

31

Тактики реализации готовности

Готовность

Обнаружение неисправностей

Восстановление: подготовка и исполнение

Восстановление: повторное введение

Предотвращение

Ping/echo-пакеты

Heartbeat-сообщения

Исключения

ГолосованиеАктивное

резервированиеПассивное

резервированиеРезерв

ЗатенениеПовторная

синхронизация состояния

Отчет

Снятие с эксплуатации

Диспетчер транзакцийТранзакции

Неи

спра

внос

ть

Мас

киро

вка

неис

прав

ност

ей и

ли в

осст

анов

лени

е

32

Тактики реализации модифицируемости

Модифицируемость

Локализация изменений

Предотвращение волнового

эффекта

Откладывание времени

связывания

Семантическая связность

Прогнозирование ожидаемых изменений

Обобщение модуляОграничение возможных альтернатив

Абстрагирование общих служб

Сокрытие информации

Обслуживание существующих интерфейсов

Ограничение каналов связи

Введение посредника

Регистрация в периоде прогона

Конфигурационные файлы

ПолиморфизмЗамена компонентов

Применение предписанных

протоколов

Пос

тупл

ение

изм

енен

ий

Изм

енен

ия в

несе

ны, п

роте

стир

ован

ы и

ра

змещ

ены

в с

рок

и в

рам

ках

бюдж

ета

33

Тактики реализации производительности

Производительность

Потребление ресурсов

Управление ресурсами

Арбитражресурсов

Повышение вычислительно эффективности

Снижение издержек вычисления

Контроль частоты поступления событий

Контроль частоты опроса

Введение параллелизма

Введение нескольких копий

Расширение доступных ресурсов

Политика планирования

Пос

тупл

ение

соб

ыти

й

Отк

лик

сген

ерир

ован

вов

рем

я

34

Тактики реализации практичности

Практичность

Отделение пользовательского

интерфейса

Поддержка инициативы

пользователя

Поддержка инициативы

системы

Отмена текущей операции

Отмена предыдущей операции

Группировка

Модель пользователяМодель системыМодель задачи

Запр

ос п

ольз

оват

еля

Пол

ьзов

ател

ь по

луча

ет ж

елае

мы

й от

вет и

пом

ощь

35

Метод ADD

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

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

36

Метод ADD следует циклу Демминга

СИСТЕМА

Требования атрибутов качества

Ограничения проектаФункциональные

требования

СИСТЕМА

Plan: Выбрать типы элементовDo: Определить элементыCheck: Проанализировать проект

37

Этапы метода ADDФункциональные

требованияПроектные

ограничения


Шаг 1. Определить достаточность информации по требованиям

Шаг 2. Выбрать элемент системы для декомпозиции

Шаг 3. Определить кандидаты архитектурных драйверов

Шаг 4. Выбрать проектные концепции, удовлетворяющие архитектурным драйвера

Шаг 5. Создать архитектурные элементы и распределить ответственности

Шаг 6. Определить интерфейсы созданных элементов

Шаг 7. Проверить и уточнить требования, сделать их ограничениями для архитектурных

элементов

Проект архитектуры

38

Функциональные требования

• Функции, которые должна выполнять система, чтобы удовлетворить заявленные и подразумеваемые потребности заинтересованных лиц– Система должна позволять пользователям покупать и

продавать ценные бумаги. – Система должна позволять пользователям просматривать

операции по счету. – Система должна осуществлять мониторинг и записывать ввод

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

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

всех спутников

39

Проектные ограничения

• Oracle 8.0 должны использоваться для хранения данных. • Системные услуги должны быть доступными через World

Wide Web. • Система должна быть реализована с использованием

Visual Basic. • Система должна взаимодействовать только с другими

системами через Publish / Subscribe. • Система должна работать на обеих платформах Windows

и Unix. • Система должна интегрироваться с унаследованными

приложениями.

40


• Степень, с которой система должна обладать различными свойствами– внедряемость: Система должна быть

работоспособна через шести месяцев. – доступность: Система должна восстановиться

после остановки процессора через одну секунды.

– производительность: Система должна обрабатывать входной сигнал от датчика в течение одной секунды.

41


– безопасность: Система должна запретить доступ неавторизованным пользователям 100% времени.

– проверяемость: Система должна позволить, чтобы модульные тесты могли быть выполнены в течение трех часов с покрытием до 85%.

– практичность: Система должна позволить пользователям отменить операцию в течение одной секунды.

– емкость: Система должна иметь максимум 50% загрузки процессора.

42

Шаг 1. Определить достаточность информации по требованиям

• Приоритезировать требования по важности• Проверить и составить сценарии для

атрибутов качества• Уточнить недостающую информацию

43

Шаг 2. Выбрать элемент системы для декомпозиции

• При первом входе в цикл выбрать всю систему для декомпозиции

• При последующих входах в цикл выбрать определенный структурный элемент– Текущее понимание архитектуры– Риски и трудности– Экономические критерии– Организационные критерии

44

Шаг 3. Определить кандидаты архитектурных драйверов

• Повторно приоритезировать каждое требования, применяя такие критерии, как важность для ЗЛ (В, С, Н) и влияние на архитектуру (В, С, Н)

• (В, В) (В, С) (В, Н) (С, В) (С, С) (С, Н) (Н, В) (Н, С) (Н, Н)

• Выбрать 5 - 6 высокоприоритетных требований – они будут кандидатами в архитектурные драйверы

45

Шаг 4. Выбрать проектные концепции, которые удовлетворяют архитектурным

драйверам (1)• Определить дизайнерские проблемы,

которые связаны с архитектурным драйвером. – Например, для эксплуатационной готовности,

основные проблемы проектирования могут быть профилактика неисправностей, обнаружение неисправностей и устранение неисправностей

46


драйверам (2)• Для каждой проектной проблемы составить

список альтернативных архитектурных шаблонов. Шаблоны получают из– Ваши знания, навыки и опыт– Известные архитектурные тактики– Иные источники: книги, статьи, материалы

конференции, поисковые системы, коммерческие продукты и т.п.

47


драйверам (3)• Составить матрицу соответствия

выбранных архитектурных паттернов с архитектурными драйверами и записать обоснование такого выбора

48


драйверам (4)• Сравните полученные шаблоны, определите как

они соотносятся друг с другом. Создайте новый шаблон:– Определите какие типы элементов разных шаблонов

соотносятся друг с другом– Определите какие типы элементов разных шаблонов

не соотносятся друг с другом– Найдите перекрытие функциональности как

показатель возможности объединения паттернов– Выявите новые типы элементов, образующиеся при

объединении шаблонов

49


драйверам (5)• Опишите выбранные шаблоны, используя

различные архитектурные представления (views)

50


драйверам (6)• Оцените и устраните несоответствия в проектных

концепциях– Оцените решение против архитектурных драйверов– Определите, есть ли не рассмотренные архитектурные

драйверы– Оцените архитектурные шаблоны или примените

дополнительные тактики, если решение не удовлетворяет архитектурным драйверам

– Оцените проект текущего элемента против других элементов архитектуры для разрешения несоответствий

51

Шаг 5. Создать архитектурные элементы и распределить ответственности (1)

• Создать по одному экземпляру по каждому типу элементов, выбранных на шаге 4

• Свяжите ответственности с каждым элементом согласно их типа– Элементы ping-типа связаны с ping функциональностью, ping

частотой, данными ping сигналов и с элементами, которым отправляются ping-сигналы

• Распределить ответственности родительского элемента по дочерним согласно обоснованию и их свойствам – если родительский элемент в банковской системе отвечает за

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

52

Шаг 5. Создать архитектурные элементы и распределить ответственности (2)

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

• Проанализируйте и задокументируйте проектные решения, используйте различные архитектурные представления

53

Шаг 6. Определите интерфейсы для созданных элементов

• Определить, какие сервисы предоставляет каждый элемент, в каких сервисах нуждается (запрашивает) каждый элемент

• Сервисы и их свойства определяют интерфейс элемента• Интерфейс включает

– Сигнатуру – синтаксис операций– Семантику операций (описание, предусловия и постусловия,

ограничения)– Информацию, которой обмениваются– Атрибуты качества частых элементов или операций– Обработку ошибок

54

Шаг 7. Проверить и уточнить требования. Сделать их ограничениями для созданных

элементов• Проверить, что все функциональные требования,

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

• Перевести все ответственности, которые были назначены на дочерние элементы, в функциональных требований для отдельных элементов

• Уточнить атрибуты качества для отдельных элементов, если требуется

55

Используемые источники

• Архитектура информационных систем: учебник для студ. учреждений высш. проф. образования / Б. Я. Советов, А. И. Водяхо, В.А. Дубенецкий, В.В. Цехановский. – М.: Издательский центр «Академия», 2012. – 288 с.

56

• Л. Басс, П. Клементс, р. Кацман. Архитектура программного обеспечения на практике. 2-е изд. – СПб: Питер, 2006.

05 Архитектура информационных систем. Атрибуты качества. Метод ADD

Education

driven

portability

attribute

ping

testability

reliability

interoperability

security