Документирование архитектуры программного обеспечения Документирование архитектуры программного обеспечения имеет большое значение как для самих архитекторов, так для и организаторов проекта. Причем важным является не только результат документирования, но и сам процесс. Архитектура представляет собой часть проекта, которая должна быть известна всем участникам разработка, а не только коллективу проектировщиков. Архитектурную документацию читают проектировщики, занимающиеся вопросами развертывания и разработки сети, персонал, осуществляющий поддержку программного обеспечения, операторы справочной системы и даже менеджеры проекта, но лишь некоторые из них изучают подробное описание программного обеспечения. Документация, описывающая архитектуру программного обеспечения, исчерпывающим образом излагает основные аспекты системы и гарантирует, что система удовлетворяет предъявленным требования. Документирование архитектуры вынуждает проектировщиков очень тщательно рассматривать разные ее аспекты. В данной статье изложены некоторые предложения, касающиеся архитектуры и ее документирование. Как уже отмечалось, архитектура описывает набор проектных решений, правил и модулей, а так же набор ограничений, характеризующих среду, в которой происходит проектирование и реализация системы. Архитектура системы имеет несколько ракурсов, поэтому этот факт следует отразить в ее описании. Как отмечалось в рекомендациях комитета 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 должен изучаться всем коллективом разработчиков и обновляться по мере развития проекта.