Пара слов об архитектуре и дизайне

В любой деятельности человек, прежде всего, стремиться к тому, чтобы в основе её лежали правильные соображения. Результатом «правильных соображений» может оказаться что угодно. У каждого свои взгляды на то, что считать правильным, и как правильно вести дела. Это и становится причиной большинства конфликтов. Программные системы не являются исключением.

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

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

Architecture is the organizational structure of a system.

IEEE Std. 610.12-1990

Архитектура – это организационная структура системы.

Стандарт IEEE 610.12-1990

Design – (1) The process of defining the architecture, components, interfaces, and other characteristics of a system or component. (2) The result of the process in (1).

IEEE Std. 610.12-1990

Дизайн – (1) Процесс задания архитектуры, компонентов, интерфейсов и других характеристик системы или компонента. (2) Результат этого процесса в (1).

Стандарт IEEE 610.12-1990

И расширенных:

The software architecture of a program or computing system is the structure or structures of the system, which comprise software components the externally-visible properties of those components and the relationships among them.

Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice, Addison-Wesley, 1998

Архитектура программной или вычислительной системы – это структура системы (или набор структур, её составляющих), которая включает в себя программные компоненты, видимые извне свойства этих компонентов и отношения между ними.

Лен Басс, Пол Клеменс, Рик Кацман, «Программная архитектура на практике», Addison-Wesley, 1998

Design is the activity of making explicit proposals for a change from an existing system to some future system which more closely approximate
mankind's concept of the ideal.

Tom Maver, Professor of Stathclyde University, Glasgow

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

Том Мавер, профессор университета Статклайд в Глазго

До совсем уж сложных:

Software architecture is a set of concepts and design decisions about the structure and texture of software that must be made prior to concurrent engineering to enable effective satisfaction of architecturally significant explicit functional and quality requirements and implicit requirements of the product family, the problem, and the solution domains.

Jazayeri, Ran, van der Linden: Software Architecture for Product Families: Principles and Practice, Addison Wesley Longman, 2000

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

Джэзаери, Ран, Ван дер Линден, «Программная архитектура для семейств продуктов: принципы и практика», Addison Wesley Longman, 2000

Design is the process of applying various techniques and principles for the purpose of defining a device, a process, or a system in sufficient detail to permit its physical realization.

Roger S. Pressman: Software Engineering: A Practioners Approach, McGraw-Hill, 1992

Дизайн – это процесс применения различных техник и принципов в целях задания устройства, процесса или системы в детализации, достаточной для их физической реализации.

Роджер С. Прессман, «Разработка программного обеспечения: подход практиков», McGraw-Hill, 1992

Пересечение понятий архитектуры и дизайна проявляется в ответе на вопрос о том, что же конкретно является результатом применения дизайна. Учитывая, что дизайн – это неотъемлемое свойство системы, порожденное применением практик определенного дизайна, довольно сложно сформулировать, как этот результат соотносится с архитектурой. К примеру, использование классов – это дизайн или архитектура? Проект начинается с архитектуры, но и на стадии завершения она всё еще с нами, только теперь может отличаться от первоначальной.

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

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

Также часто можно услышать, что где-то пожертвовали дизайном ради эффективности (под которой понимается скорость исполнения алгоритмов), или ради скорости разработки. Жертвуют ли архитектурой?

Архитектурой жертвовать нельзя. Как следует из определений, архитектура задается еще до начала параллельной разработки. Соответственно, нарушение архитектурных соглашений легко может привести к тому, что проект рассыплется, как Шалтай-болтай. Из другого определения видно, что архитектура – это набор свойств и соглашений, видимых извне. Нарушения в данной области приведут к тому, что продукт принципиально не сможет быть интегрирован с окружением и другими системами так, как это задумывалось. С такой точки зрения, разделение на архитектуру и дизайн также означает приоритетность определенных установок для команды проекта. Вероятно, архитектуру можно определить и так:

Проектные решения, которыми жертвуют только при пересмотре взглядов на проект в целом.

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

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

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

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

Вспоминаю, как в первый день руководитель отдела кадров знакомил меня с сотрудниками, представляя: «Наш новый главный архитектор». К концу того же дня один из моих новых коллег обратился ко мне, плохо понимая, в чем состоят мои обязанности. «В общем и целом, — заметил он, разглядывая стены и потолок, — здание выглядит неплохо. И что Вы намерены с ним делать?»

Стив Виноски, «Все начинается с архитектуры», Открытые системы, №1, 2004

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

Сравнение процесса создания программ с процессом возведения сооружений очень глубоко проникло в умы и отразилось в терминологии. Употребляются такие слова как architecture, build, framework и т.д. Очевидно, что подобное сравнение импонирует разработчикам. Вот некоторые особенности современного строительства, которые очень хотелось бы видеть в разработке ПО:

· Всё строится из готовых стандартных блоков;

· Много формальных методов для проектирования и собственно строительства;

· Наличие большого числа метрик для объективной оценки качества;

· Предсказуемость процесса во времени и затратах;

Ничто из этого на момент 2008 года не имеет ничего общего с разработкой ПО. Сравнение со строительством также переносит на программное обеспечение некоторые сомнительные следствия:

· Каждое здание имеет фундамент – значит, каждая программная система должна иметь свой фундамент, своё «ядро». Разработка такого ядра может легко занять 200% времени, выделенного на разработку всего продукта;

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

---