Введение

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

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

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

Измерение качества обслуживания (QoS)

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

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

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

Для упрощения анализа моделей с точки зрения QoS разработан широкий спектр технологий, перечисленных выше. Например, для анализа производительности встроенного программного обеспечения реального времени применяется монотонный анализ пропускной способности [см. Klein, M. H., et al. A Practitioners' Handbook for Real-Time Analysis: Guide to Rate Monotonic Analysis for Real-Time Systems, Kluwer Academic Publishers, 1993], and Failure Mode Effects and Criticality Analysis (FMECA), for hardware failure and safety risk identification and characterization [see Kececioglu, Dimitri, Reliability Engineering Handbook, Vol. 2,  PTR Prentice Hall, 1991].

Поддержка различных методик анализа в UML реализована на с помощью механизма профилей (см. UML Profile for Schedulability, Performance, and Time Specification и UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms. Эти профили (их можно загрузить с сайта www.omg.org) содержат аннотации для моделей UML, позволяющие измерять характеристики моделей и сравнивать их с ожидаемыми величинами с помощью разнообразных инструментов и методик анализа.