В предыдущем посте "Описание архитектуры приложения" я приводил вариант описания архитектуры приложения, а теперь хочу дать чуть более подробное описание методики составления архитектурного описания приложения или проекта. Эта методика является неким адаптированным вариантом стандарта IEEE 1471 и не претендует на полноту. Основная цель - помочь командам выбрать направление для документирования архитектуры их проектов.

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

Functional viewpoint

Назначение

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

Представления

• Actors view
• Functions view
• Business processes view

Модели

• Use case diagram

Риски

• Сложность автоматизации функциональности
• Реализуемость и тестируемость функциональности

Domain viewpoint

Назначение

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

Представления

• Data entity view
• Data flow view
• Control flow view

Модели

• Class diagram (основные сущности)
• Activity diagram (обмен данными с внешними системами)
• Activity diagram (передача управления между сущностями)

Риски

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

Conceptual viewpoint

Назначение

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

Представления

• Tiers view
• Components view
• Dependencies view

Модели

• Component diagram

Риски

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

Behavioral viewpoint

Назначение

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

Представления

• Functional view
• Lifecycles view
• Dependencies view

Модели

• Sequence diagram
• State chart diagram

Риски

• Риски, связанные с коммуникациями между компонентами и внешними системами, например, устойчивость, пропускная способность, временные характеристики
• Уровень предсказуемости поведения компонентов (асинхронность и событийность взаимодействия приводит к сложности понимания происходящего)

Logical viewpoint

Назначение

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

Представления

• Patterns view
• Interfaces view
• Hierarchies view
• Abstracts view
• Dependencies view

Модели

• Class diagram

Риски

• Связность между классами
• Компактность и достаточность интерфейсов
• Изменение программных интерфейсов внешних систем, форматов сообщений и структур данных
• Рост количества иерархий, параллельные иерархии
• Рассогласование программных интерфейсов между компонентами

Persistence viewpoint

Назначение

Охватывает аспекты хранения состояния компонентов приложения и результатов работы. Описываются варианты кеширования. Описываются модели данных, аспекты аудита и обеспечения безопасности к данным. Подробные модели данных не обязательны, необходимо показать какие основные сущности хранятся в БД и предоставить количественные характеристики: количество записей, частота выполнения операций CRUD (вставка, чтение, удаление, добавление).

Представления

• Database view
• Cache view

Модели

• ER diagram (модели основных сущностей)
• Class diagram (модели кеширования)

Риски

• Несанкционированный доступ к данным, изменение структуры базы данных и параметров ее работы.
• Консистентность данных (дубликаты, битые ссылки)
• Снижение производительности, рост объема данных, увеличение нагрузки на сервер базы данных
• Распределение зон ответственности за реализацию логики между базой данных и другими компонентами

Deployment viewpoint

Назначение

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

Представления

• Reliability view
• Performance view
• Configuration view
• Dependencies view
• Support view

Модели (UML)

• Deployment diagram

Риски

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

Implementation viewpoint

Назначение

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

Представления

• Security view
• Components DEV view
• Components QA view
• Components PROD view
• Software engineering view
• Deployment view

Модели

• Deployment diagram
• Sequence diagram

Риски

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

Если у вас появились какие-то замечания, вопросы или предложения, то оставляйте их в комментариях к этому посту.

Еще интересные статьи на эту тему:

• Легкое документирование
• Лучше программировать, чем документировать
• Значение архитектуры для Agile разработки
• Связь архитектуры и процесса разработки
• Авторитетность и власть - разные значения одного слова "authority"