Документирование архитектуры программного обеспечения

Документирование архитектуры программного обеспечения
Документирование архитектуры программного обеспечения имеет большое значение как для
самих архитекторов, так для и организаторов проекта. Причем важным является не только
результат документирования, но и сам процесс. Архитектура представляет собой часть проекта,
которая должна быть известна всем участникам разработка, а не только коллективу
проектировщиков. Архитектурную документацию читают проектировщики, занимающиеся
вопросами развертывания и разработки сети, персонал, осуществляющий поддержку
программного обеспечения, операторы справочной системы и даже менеджеры проекта, но лишь
некоторые из них изучают подробное описание программного обеспечения. Документация,
описывающая архитектуру программного обеспечения, исчерпывающим образом излагает
основные аспекты системы и гарантирует, что система удовлетворяет предъявленным
требования. Документирование архитектуры вынуждает проектировщиков очень тщательно
рассматривать разные ее аспекты. В данной статье изложены некоторые предложения,
касающиеся архитектуры и ее документирование.
Как уже отмечалось, архитектура описывает набор проектных решений, правил и модулей, а так
же набор ограничений, характеризующих среду, в которой происходит проектирование и
реализация системы. Архитектура системы имеет несколько ракурсов, поэтому этот факт следует
отразить в ее описании. Как отмечалось в рекомендациях комитета IEEE 1471, архитектор может
изложить свою концепцию. Концепция должна содержать следующие описания.
1. Описание одной или нескольких модулей системы, а так же разных ракурсов (проекций)
этих моделей.
2. Описание организаторов проекта, заинтересованных в этих проекциях.
3. Задачи организаторов проекта, которые можно решить с помощью этих проекций.
Архитектура программного обеспечения рассматривается с разных точек зрения,
определяющих разные проекции. Эти проекции включают в себя артефакты проектирования,
представляющие важно для архитектуры.
Рассмотрим простой набор проекций, используемых при описании архитектуры программного
обеспечения. Этот набор проекций впервые бил предложен Кручтеном (Kruchten) и называется
архитектурной моделью 4 + 1.
1. Проекция требований (так называемая проекция сценариев). Эта проекция описывает
функциональные и нефункциональные требования, важные с архитектурной точки зрения.
Функциональные требования, влияющие на выбор архитектуры, определяют сценарии,
имеющие архитектурную важность и анализируемые на ранних этапах проектирования.
Нефункциональные требования, влияющие на выбор архитектуры, содержат перечень
архитектурных качеств системы (например, удобство, гибкость, производительность,
размер, масштабируемость, безопасность, секретность, ясность), экономические и
технологические ограничения (например, использование готовых программ, интеграции с
существующими системами, стратегия поворотного использования, требуемые
инструменты, структура коллектива разработчиков и график работ), а так же юридические
ограничения (например, соответствие определенным стандартам и нормативам). Эти
требования наиболее сильно влияют на выбор архитекторы и архитектурных механизмов,
перечисленных в логической концепции системы.
2. Логическая проекция. Эта проекция описывает элементы анализа и проектирования
важные с архитектурной точки зрения, отношения между ними, их организация в виде
компонентов, пакетов и уровней приложения, а так же немногочисленные избранные
реализации, иллюстрирующие взаимодействие архитектурных элементов в рамках
сценариев, связанных с проекцией требований. Кроме того, логическая проекция
описывает основные механизмы и модели, определяющее структуру системы.
3. Проекция реализации. Эта проекции описывает основные элементы реализации
(исполняемые модули и каталоги), а так же связи между ними. Эта проекция важна,
поскольку структура реализации сильно влияет на параллельное проектирование,
управление конфигурацией, интеграцию и тестирование.
4. Проекция процессов. Эта проекция описывает независимые потоки управления в системы
и логические элементы этих потоков.
5. Проекция развертывания. Эта проекция описывает узлы системы (например, компьютеры,
маршрутизаторы и виртуальные машины-контейнеры).
Название 4 + 1 является следствием спора, касающихся архитектурной концепции. Проекцию
требований следует рассматривать с архитектурной точки зрения. Она включает в себя описание
требований, влияющих на выбор архитектуры, и качеств, которые должна иметь система. Таким
образом, требования сильно влияют на архитектуру. Наиболее важные требования
рекомендуется выявлять и отслеживать на ранних этапах проектирования.
Буч (Booch), Рамбо (Rumbaugh) и Якобсон (Jacobson) считают, что каждую архитектурных проекций
можно изучать отдельно от других. В этом случае все участники проекта могут сосредоточиться на
той проекции, которая интересует его больше. Эти пять архитектурных проекций могу
взаимодействовать друг с другом (например, узлы из проекций развертывания содержать
элементы проекций реализации, которые, в свою очередь, относятся к физической реализации
логической проекции и проекции процессов).
Архитектор может свободно выбирать любой количество проекций, которое сочтет нужным
для описания архитектуры программного обеспечения (например, добавить проекцию данных
и проекцию опыта пользователя), а так же сокращать их число.
Многочисленные архитектурные концепции, как простые, так и сложные, имеют общие
характеристики. Среди них наиболее известная концепция Захмана (Zachman), архитектурная
концепции министерства обороны Министерства обороны (Department of Defense Architecture
Framework - DoDAF) и федеральная концепция (Federal Enterprise Architecture).
В некоторых случаях, в зависимости от проекта и используемого процесса, целесообразно собрать
всю требуемую информацию в описании архитектуры программного обеспечения (software
architecture document - SAD). Этот документ становиться основным артефактом, в котором описана
архитектура системы. Он содержит ссылки на все другие артефакты, относящиеся к архитектуре.
Чтобы понять архитектуру системы, следует обратиться к документы SAD. Этот документ должен
демонстрировать, как решен основные архитектурные задачи, поэтому его следует
организовывать в соответствии с архитектурными проекциями. Документ SAD должен изучаться
всем коллективом разработчиков и обновляться по мере развития проекта.