Post #892

Статья Дуэйна Перри и Александра Вольфа 'Foundations for the Study of Software Architecture' 1992 года достойна отдельного поста. Это одна из самых цитируемых работ по программной инженерии за всю историю. В ней много интересных тезисов. Например, что архитектура ПО больше всего похожа на архитектуру зданий: требует нескольких отдельных видов, отражающих разные аспекты одной системы (или здания); имеет выраженные архитектурные стили, определяющие используемые элементы и их возможные связи; при этом стили связаны с инженерными принципами (то, что ты строишь, зависит от того, как ты строишь) и с материалом (...и из чего ты строишь). Дальше они характеризуют разные уровни рассмотрения: — требования определяют информацию, процессы её обработки, а также характеристики этой информации и процессов обработки, требуемые пользователям; — архитектура занимается выбором архитектурных элементов, их взаимодействий, и ограничениями, накладываемыми на эти элементы и взаимодействия. Всё это нужно для создания основы, в рамках которой можно удовлетворить требования и которая послужит базой для проектирования. — проектирование (дизайн) касается модульности, детальных интерфейсов элементов, алгоритмов и процедур, а также типов данных, необходимых для поддержки архитектуры и удовлетворения требований. — реализация связана с представлением алгоритмов и типов данных, которые удовлетворяют проекту, архитектуре и требованиям. (Видимо, "представлением в виде кода") Тут авторы оговариваются, что не во всех системах нужны все уровни, и иногда можно просто начать программировать (например, в проектах с искусственным интеллектом — напомню, это 1992 год!) Распределение по уровням выглядит логично: сначала требования; потом выбор архитектуры, в которой, как кажется, можно реализовать эти требования; потом конкретный проект в выбранной архитектуре; и, наконец, реализация. Так что архитектор должен заниматься проектированием архитектуры, созданием основы. А конкретным дизайном может кто-то другой заняться. И если, по случайности, проектированием занимается архитектор — он просто выполняет другую роль в этот момент. Итак, авторы определяют архитектуру через три понятия: Software Architecture = { Elements, Form, Rationale } Элементы архитектуры делятся на три класса: * элементы обработки * элементы данных * соединительные элементы Форма состоит из взвешенных свойств и отношений. Взвешенных — потому что не все свойства одинаково важны для конкретной системы (в соответствии с требованиями). Свойства ограничивают выбор архитектурных элементов. Отношения ограничивают "размещение" архитектурных элементов — то, где они расположены и как они связаны между собой. Наконец, неотъемлемой, самой важной частью архитектуры является обоснование различных решений, принятых при определении архитектуры. Обоснование отражает мотивацию выбора архитектурного стиля, выбора элементов, и формы. Таким образом, главный документ архитектуры — не схема соединений конкретной системы (это проект). Главный документ — описание базовых принципов и принятых решений, то есть ADR. Собственно, архитектурный стиль — это некий набор готовых решений, которые умные люди уже сделали за вас. Две главные проблемы архитектуры проявляются при изменении систем: эрозия и дрейф. Эрозия — это нарушение принципов определенной архитектуры или выбранного архитектурного стиля, а дрейф — когда сами принципы уже невозможно определить. Интересно, как они определяют свойства — как состояния данных или результата обработки. То есть система описывается топологией связей и вот этими свойствами, практически через машину состояний. Это интересный подход, сегодня кажется утерянный. Мы моделируем потоки данных, процессы и команды, события, но архитекторы редко говорят про состояния (даже когда упоминают REST, который, по идее, должен как раз вокруг состояний строиться). А сложность архитектуры определяется как раз через сложность нотации, требуемой для описания состояний системы.