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

Атрибуты:

● Качества системы

○ готовность

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

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

○ безопасность

○ контроль на пригодность

○ практичность

● Качества архитектуры

○ корректность и завершенность

○ простота реализации

○ концептуальная целостность

● Коммерческие

○ срок выхода продукта

○ срок службы системы

○ поэтапное внедрение

○ интегрируемость с любыми системами

○ стоимость и прибыль

Сценарий — это требование к системе.

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

Элементы сценария:

● источник (субъект, порождающий событие)

● событие

● контекст (режим работы или условия, в которых находится система)

● объект (на который влияет событие)

● реакция (действие, предпринимаемое системой)

● количественная мера реакции (для оценки состояния системы)

Тактики реализации атрибутов качества используются воплощения атрибутов качества системы.

Тактика — проектное решение по управлению реакцией системы на различные события.

Готовность — вероятность функционирования системы в момент времени, когда в этом возникает необходимость.

Вычисляется как отношение наработки на отказ к средней наработке на отказ и средней продолжительности восстановления.

Модифицируемость – это простота или стоимость внесения изменений в систему.

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

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

1. Тактика снижения потребления ресурсов

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

b. Сокращение непроизводственных издержек. Отказ от посредников, лишних выводов и операций копирования данных.

c. Уменьшения частоты срабатывания.

d. Ограничение времени обработки входящих запросов.

e. Ограничение длины очереди входящих запросов.

2. Тактика управления ресурсами

a. Параллельная обработка поступающих запросов.

b. Дублирование данных или вычислений.

c. Увеличение вычислительной мощности системы.

3. Тактика доступа к ресурсам

a. FIFO.

b. На основе приоритетов.

i.Статические приоритеты в зависимости от времени запуска задачи

ii.Статические приоритеты в зависимости от предельного срока обработки

iii.Статические приоритеты в зависимости от частоты поступления запросов.

iv.Динамические приоритеты с циклическим обслуживанием запросов.

v.Динамические приоритеты в зависимости от предельного срока обработки

Безопасность — способность противостоять попыткам несанкционированного доступа к данным при одновременном обслуживании легальных пользователей.

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

1. Противодействие атакам

a. Аутентификация (проверка на то, является ли пользователем тем, за кого себя выдает)

b. Авторизация (проверка прав доступа авторизованного пользователя)

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

d. Защита от внешних воздействий (через ОС)

e. Ограничение сетевого доступа

2. Обнаружение атак

3. Восстановление после атак

4. Идентификация злоумышленника

a. Журнал транзакций

Контролепригодность — способность программы демонстрировать неисправность в процессе тестирования.

Тактики:

1. Документирование входных/выходных данных

a. Запись/считывание информации при прохождении через компонент

b. Тестирование компоненты (замена компонента эквивалентным)

2. Внутренний мониторинг (компонент сам регистрирует информацию о своем состоянии)

Практичность — степень простоты выполнения пользователем стоящей перед ним задачи.

Тактики:

1. Тактики на этапе проектирования

a. Отделение пользовательской информации от остальных компонентов системы (шаблоны архитектыры)

2. Тактики на этапе выполнения

a. Поддержка модели задач
Система определяет, что пользователь намерен сделать и пытается ему помочь.

b. Поддержка модели пользователя
Система собирает информацию о навыках пользователя.

c. Поддержка модели системы
Информирование пользователя о дальнейшем поведении системы.

5. Шаблоны архитектуры. Представление централизованных данных. Шаблоны «Общий репозиторий», «Активный репозиторий», «Классная доска».

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

Классификация по классу решаемых задач:

1. Представление по уровню

2. Представление потоков данных

3. Представление централизованных данных

4. Представление адаптации

5. Взаимодействие с пользователем

6. Представление языков программирования

7. Представление взаимодействия компонентов

8. Представление распределений

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

Общий репозиторий

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

● Предоставлять специфические средства доступа

● Быть масштабируемым

● Решать проблемы совместного доступа к данным

● Предоставлять механизм управления транзакцией

Активный репозиторий

Может информировать некоторое количество подписчиков об определенных событиях происходящих в репозиторий.

Классная доска

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

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

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

6. Шаблоны проектирования. Структурные шаблоны. Шаблон «Адаптер», «Заместитель».

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

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

Структурные шаблоны предлагают решения задач по средствам структурирования классов программы.

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

Заместитель (proxy) является заменителем другого объекта и контролирует доступ к нему.

Proxy хранит ссылку, которая позволяет ему общаться с RealSubject. Так же предоставляет интерфейс Subject, контроль доступа к RealSubject и может выполнять дополнительные функции.

● Удаленный заместитель. Кодирует запрос и отправляет объекту в другом адресном пространстве.

● Виртуальный заместитель. Позволяет отделить создание объекта.

● Защищающий заместитель. Проверяет, имеет ли вызывающий необходимые права доступа.

● Умный заместитель. Выполняет дополнительные действия до или после действия.

Шаблон Facade (Фасад) — Шаблон проектирования, позволяющий скрыть сложность системы путем сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы.

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

Классы подсистемы реализуют функциональность не зная о существовании фасада, а фасад адресует запросы клиентов подходящему объекту внутри системы.