Архитектура ПО

Обсуждение

Как-то раз один менеджер объяснял основные идеи одного достаточно крупного проекта, которым он руководил. Он начертил на доске три кубика: frontend, backend, tools. И сказал, что это и есть главное строение проекта. И в смысле внутреннего устройства продукта, и в смысле распределения работ в команде по трем дистанционно разнесенным центрам разработки. Задачи backend сложные, ресурсоемкие, выполняются пакетно. Они отделены от графического интерфейса продукта (frontend), который также непросто устроен. Frontend – это пользовательский интерфейс: сложный, параметризуемый, с рядом встроенных пользовательских сервисов (в частности, браузер информации), а также настраиваемый. Обе эти подсистемы взаимодействуют друг с другом через хорошо определенный и детально описанный программный интерфейс: алгоритмы backend разбиты на методы, которые frontend может вызывать по особым правилам, с параметрами, выстраивая в цепочку для достижения своих задач. "Сбоку" от всего этого находятся дополнительные tools. Они интегрируются во frontend, но не пользуются методами backend, а реализуют свои задачи самостоятельно. Эти задачи не требуют сложной пакетной обработки, а нацелены на интерактивное взаимодействие с пользователем. При их реализации особенно много внимания уделялось usability.

Каждая из трех подсистем требовала от разработчиков особых навыков. В случае backend это было умение и опыт по реализации такого рода пакетных алгоритмов, в случае с frontend – умение создавать сложный пользовательский интерфейс, в случае с tools требовалось искусство в проектировании и реализации "легковесных" инструментов, предоставляющих пользователям системы дополнительные сервисные возможности. В том, чтобы разделить работы таким образом, был еще и ряд политических аспектов. В частности, руководство проекта хотело иметь процесс разработки пользовательского интерфейса рядом с собой, в одном из трех центров разработки, который совпадал со штаб-квартирой. Считалось, что внешний вид продукта очень важен для его успешной продажи и требует особенного внимания.

В результате выполнения проекта (а он развивался более 15 лет, достигая в апогее до 150 человек, одновременно занятых в нем) такая четкая структура несколько сместилась – так географически интерфейс почти "переехал" в тот центр, где разрабатывался backend. Но в целом такое сквозное разделение проекта на части оставалось много лет и было основным скелетом всей разработки. Это и есть пример архитектуры программного проекта.

Определение

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

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

Итак, архитектура продукта оказывается инвариантом проекта, встречается и неожиданно возникает в его разных частях. Это и есть аналог "простым" естественно-научным постулатам и законам, отсутствие которых в разработке ПО, по мнению Брукса, является причиной сложности ПО (в смысле хаоса, то есть "плохой" сложности). Создавать такие структуры – непростое дело, требующее большого искусства. Но именно это путь к управлению хаосом, увеличивающейся энтропией в виде изменяющихся требований к системе, потере разработчиками ясного понимания, какую же именно систему они создают. И именно разработка таких структур доставляет истинное творческое наслаждение при разработке программных систем. Хорошо "работают" простые модели, которые не просто создавать. Они оказываются путеводной нитью проекта, ведущей его через пучины хаоса. Эти модели имеют такое свойство, что показывая или упоминая о них можно рассказывать о проекте очень долго, их можно красиво оформить и повесить на стенку, а можно этого и не делать.

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

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

Множественность точек зрения

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

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

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

Рис. 4.1. Разные виды деятельности – разные взгляды на систему

Далее, в разработку/использование ПО вовлечено большое количество очень разных специалистов: программисты, инженеры, тестеры, технические писатели, менеджеры, заказчик, пользователи, продавцы-маркетологи и т. д. (см. рис. 4.2). Для всех этих специалистов нужна разная информация о программной системе. Представьте, что произойдет, если, например, продавцу или заказчику-непрограммисту в ответ на просьбу получше ознакомиться с ПО вы дадите почитать программные коды…

Рис. 4.2. Разные специалисты – разные взгляды на систему

Множественность точек зрения происходит также от того, что нет единых стандартов и норм разработки ПО. То есть разработка ПО во многом "state of art". Часто приходится изобретать новую точку зрения моделирования прямо по ситуации – чтобы именно этот эксперт тебя понял, чтобы именно эти особенности системы были отражены. Часто здесь – как в лотерее: создается несколько описаний системы с разных точек зрения, какое-то оказывается удачным и его все используют в дальнейшем.

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

Точка зрения (viewpoint) — это определенный взгляд на систему, который осуществляется для выполнения какой-то определенной задачи кем-либо из участников проекта. Точку зрения нужно ясно осознавать при создании визуальных моделей, например, варианты использования. Важно понимать, что она может быть в каждом конкретном случае своя. Важнейшими характеристиками точки зрения моделирования является цель (зачем создается модель) и целевая аудитория (то есть, для кого она предназначается).

Важным вопросом, на который нужно честно себе ответить в самом начале моделирования — это зачем вы используете диаграммы (в частности, UML). Это и есть определение цели моделирования. Потому, что так создавать модели правильно? И все проблемы (даже те, о которых ничего еще не известно) волшебным образом исчезнут? Очень часто, например, при создании модели случаев использования присутствует именно такая "цель" моделирования. А потом оказывается, что никакие проблемы не "вылечились", а наоборот, возникли новые (например, созданные нами диаграммы никто не понимает и не принимает). Да и сам аналитик чувствует, что диаграммы получились какие-то странные….

А может все происходит совсем не так. Например, аналитик действительно задался целью выявить требования к системе — не навязать свое собственное видение другим, а выяснить нужную информацию, смоделировать и изложить ее доступно. Для этого он и использует диаграммы случаев использования. Ему важно, чтобы будущие пользователи системы могли участвовать в этом процессе, диаграммы рисуются для них, они понятны и не избыточны. И эти же диаграммы структурируют и проясняют информацию для самого аналитика.

Подобных сюжетов на практике происходит множество. Тут важно понимать, что цель модели — это не какая-то гипотетическая задача типа "описания архитектуры, потому что так нужно, так правильно", а целевая аудитория — это не абстракция типа "люди, желающие познакомиться с ПО". И то и другое — что-то очень конкретное, реально существующее в проекте или рядом с ним. Ведь разработчики ПО не могут позволить себе за деньги заказчика создавать нечто на все века и для всех народов. И цель моделирования, и аудитория, которая будет работать с диаграммами, всегда существуют, важно лишь ясно понимать, какие они…

Вот полезный практический прием для ориентации на целевую аудиторию, для которой предназначена создаваемая вами модель. Можно выбрать одного представителя такой аудитории — конкретного и известного вам человека — и создавать диаграммы, понятные именно ему. При этом важно не обсуждать чрезмерно с ним ваши модели, поскольку это может создать дополнительный контекст, которого другие пользователи моделей будут лишены. Полезно представлять воображать себе этого человека при работе над моделями — его реакции, вопросы, недоумения и пр. И, исходя из этого, корректировать, исправлять созданное. И, конечно же, полезно проверить свои предположения, показав ему, что получилось.

Кроме того, важно, чтобы точка зрения была "живая", а не выдумывалась аналитиком или бездумно копировалась из книжек и тренингов, посвященных UML. Незаметно для себя аналитик может придумать свой собственный проект, своих собственных пользователей системы, заказчика и т.д. То есть аналитик исподволь, навязывает самому себе определенное восприятие реально существующих людей, задач, сильно искажая реальное положение дел. И именно в контексте этой воображаемой ситуации он создает свои модели. Но ведь реальные люди, реальные ситуации обладают своеобразием, большим диапазоном вариативности. Соответственно, аналитик должен обладать гибкостью сознания, большим диапазоном техник, а также чуткостью и искренним стремлением к тому, чтобы сделать каждый конкретный проект, где он участвует, более гармоничным, более адекватным.