Архитектура решения – «Меня собеседовали 6 директоров и вице-президент». Архитектор 4-го уровня EPAM про то, как разработчику вырасти до архитектора решений (+список книг)

Архитектура системы — Википедия

Архитектура системы — принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию[1]:3.

Понятие архитектуры в значительной мере субъективно и имеет множество противоречивых толкований; в лучшем случае оно отображает общую точку зрения команды разработчиков на результаты проектирования системы.[2]:27 Существует большое количество определений архитектуры. Коллекция определений, относящихся, в основном, к архитектуре программного обеспечения, собрана на сайте Института программной инженерии Университета Карнеги — Меллона[3].

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

[4]:272.

Другие определения архитектуры системы

  • Общий план или концепция, используемая для создания системы, такой как здание или информационная система, или абстрактное описание системы, её структуры, компонентов и их взаимосвязей (Defining Architecture for IT: A Framework of Frameworks, Gartner, 2002)[5]:79-80.
  • Конструктивные решения, которые после их принятия с трудом поддаются изменению; согласие в вопросе идентификации главных компонентов системы и способов их взаимодействия, а также выбор таких решений, которые интерпретируются как основополагающие и не подлежащие изменению в будущем.[2]:27

По мере роста сложности решаемых задач возникла необходимость структурирования систем. Однако практики нашли термин «структура» недостаточным для описания всех аспектов системы[4]:272.

Термин «архитектура» в системной инженерии ввел профессор университета Южной Калифорнии Эберхард Рехтин (англ. Eberhardt Rechtin) в начале 90-х годов XX-го века. Он считал, что по мере усложнения систем их «высокоуровневого проектирования» (или «концептуального проектирования»), как оно понималось в те годы, было недостаточно, чтобы приводить инженеров и проектировщиков к созданию точных и эффективных проектов. Он изучил архитектурные принципы в строительстве, чтобы понять, как создаются и разрабатываются сложные системы (например, здания)

[6]:223.

Рехтин поясняет термин архитектура системы следующим образом:

Суть создания архитектуры — структурирование. Структурирование может означать превращение формы в функцию, извлечение порядка из хаоса, или преобразование частично сформированных идей клиента в пригодную для работы концептуальную модель[6]:223-224.

Термины «архитектура» и «архитектурное проектирование» уже используются в течение приблизительно 30 лет, особенно интенсивно в программной инженерии и таких проблемных областях как ракетно-космическая отрасль[4]:272.

Для более подробного описания принципов построения архитектуры стандарт ISO/IEC/IEEE 42010-2011 вводит следующие понятия[7]:2.

  • Архитектурная группа описаний
    (англ. architectural view) — представление системы в целом с точки зрения связанного набора интересов. Каждая группа описаний относится к одному или более стейкхолдеру. Термин «группа описаний» употребляется для выражения архитектуры системы при некотором методе описания.
  • Архитектурное описание (англ. architectural description) — рабочий продукт, использующийся для выражения архитектуры.
  • Архитектурный подход (англ. architectural framework) — соглашения, принципы и практики для описания архитектуры, установленные для конкретной области применения и/или конкретным сообществом стейкхолдеров.
  • Архитектурный метод описания (англ. architectural viewpoint) — спецификация соглашений для конструирования и применения группы описаний. Шаблон или образец, по которому разрабатываются отдельные группы описаний посредством установления назначений и аудитории для группы описаний, а также приемы их создания и анализа. Метод описания устанавливает соглашения, по которым группа описаний создается, отображается и анализируется. Тем самым метод описания определяет языки (включая нотации, описания или типы продуктов), применяемые для определения группы описаний, а также все связанные методы моделирования или приемы анализа, применяемые к данным представлениям группы описаний. Данные языки и приемы применяются для получения результатов, имеющих отношение к адресуемым интересам.
  • Вид модели (англ. model kind) — соглашения по средствам моделирования (например, сети Петри, диаграммы классов, организационные диаграммы и т. д.).

Свод знаний по системной инженерии (SEBoK) делит архитектуру на логическую и физическую[4]:269.

Логическая архитектура[править | править код]

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

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

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

Временная архитектура. Временная архитектура является классификацией функций системы, которая получена в соответствии с уровнем частоты её исполнения. Временная архитектура включает в себя определение синхронных и асинхронных аспектов функций. Мониторинг решений, который происходит внутри системы, следует той же временной классификации [4]:287.

Физическая архитектура[править | править код]

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

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

Физическая архитектура является систематизацией физических элементов (элементов системы и физических интерфейсов), которые реализуют спроектированные решения для продукта, услуги или предприятия. Она предназначена для удовлетворения требований к системе и элементам логической архитектуры и реализуется через технологические элементы системы. Системные требования распределяются как на логическую, так и физическую архитектуру. Глобальная архитектура системы оценивается с помощью системного анализа и, после выполнения всех требований, становится основой для реализации системы[4]:296.

Концептуальная схема архитектурного описания (ISO/IEC 42010)

Архитектура может быть зафиксирована с помощью полного архитектурного описания (АО) (см. рисунок). Стандарт ISO/IEC/IEEE 42010-2011 предписывает различать концептуальную архитектуру

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

В сложных системах АО может разрабатываться не только для системы в целом, но и для компонентов системы. Два разных концептуальных АО могут включать группы описаний, которые будут соответствовать одному и тому же методу описания. Хотя системы, описываемые данными двумя группами описаний, будут соотноситься как целое и часть, это не пример множества групп описаний, соответствующих одному методу. Эти АО считаются отдельными, даже хотя они связаны через системы, которые они описывают[7]:3.

Концептуальный подход[править | править код]

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

На рисунке прямоугольники изображают классы сущностей.

Линии, соединяющие прямоугольники, изображают связи между сущностями. Связь включает две роли (по одной в каждом направлении). Каждая роль может по желанию быть именована меткой. Роль, направленная от A к B, [помечена] ближе к B, и наоборот. Например, роли между «системой» и «средой» могут читаться: «„система“ живёт в „среде“» и «„среда“ влияет на „систему“». На рисунке роли обладают арностью 1:1, если не указано иное. Роль может обладать множественной арностью, например, роль, обозначенная как «1..*», применяется для обозначения многих, как в связях «один ко многим» или «многие к одному». Ромб (на конце линии связи) обозначает отношение части целого. Например, «группы описаний» являются частью «архитектурного описания». Эта нотация заимствована из UML.

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

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

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

Любая система существует для реализации в своей среде одной или более миссий.

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

Архитектурное описание выбирает для применения один или более подходящих методов описания. Выбор методов описания обычно основывается на соображениях и интересах заинтересованных сторон, которым адресовано это АО. Определение метода описания может возникать совместно с АО, а может быть определено отдельно. Метод описания, определенный отдельно от АО называется библиотечным методом описания.

Группа описаний может состоять из одного или более архитектурных описаний. Каждое такое архитектурное описание разрабатывается с применением установленных соответствующим ему методов архитектурного описания. Архитектурное описание может входить более чем в одну группу описаний[7]:4-6.

Типы групп описаний архитектуры[править | править код]

Существует три типа группы описаний: функциональные, логические и физические. Каждая из групп предназначена для описания собственных точек зрения и соответствующего им уровня сложности[6]:224.

Функциональная группа описаний[править | править код]

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

[6]:224.

Логическая группа описаний[править | править код]

Данная группа обеспечивает представление с точки зрения руководителя или заказчика. Логическое представление включает продукты, которые определяют системные границы с её окружением и функциональные интерфейсы с внешними системами, также основные функции и поведение системы, потоки информации, внутренние и внешние наборы данных, внутренних и внешних пользователей, и внутренние функциональные интерфейсы. Примером продуктов могут быть блочные диаграммы функциональных потоков[en] (FFBD), контекстные диаграммы, N2-диаграммы[en], IDEF0-диаграммы, данные поточных диаграмм и различных стейкхолдеров — характерные продукты (в том числе бизнес-зависимые продукты)[6]:224.

Физическая группа описаний[править | править код]

Данная группа обеспечивает представление с точки зрения проектировщиков. Включает в себя:

  • продукты, которые определяют физические границы системы;
  • физические компоненты системы и то, как они взаимодействуют и влияют друг на друга;
  • внутренние базы данных и структуры данных;
  • инфраструктуру информационных технологий (ИТ) системы;
  • внешнюю ИТ-инфраструктуру, с которой система взаимодействует;
  • требования, необходимые для развития системы.

Продукт может включать в себя физические блок-схемы на довольно высоком уровне детализации, топологии базы данных, интерфейс управления документами и стандарты. Все из трёх типов групп должны присутствовать в каждом описании архитектуры[6]:224.

Архитектурные описания в ходе жизненного цикла могут различно применяться всеми стейкхолдерами. Такие применения включают, но не ограничиваются, следующим:

  • анализ альтернативных архитектур
  • деловое планирование перехода от унаследованной архитектуры к новой;
  • коммуникация организаций, участвующих в разработке, производстве, установке, эксплуатации и обслуживании систем;
  • коммуникация между заказчиками и разработчиками как часть подготовки соглашения;
  • критерии для сертификации соответствия реализации данной архитектуре;
  • документирование разработки и обслуживания, включая подготовку материалов для хранилищ с целью повторного использования и учебных материалов;
  • исходные данные для последующих мероприятий по системному проектированию и разработке;
  • исходные материалы для инструментов создания и анализа системы;
  • эксплуатационная и инфраструктурная поддержка; управление конфигурацией и ремонт; перепроектирование и обслуживание систем, подсистем и компонентов;
  • поддержка планирования и финансирования[7]:9.
  • ГОСТ Р ИСО/МЭК 15288—2008. Системная инженерия — Процессы жизненного цикла систем. — 2008.
  • Данилин А., Слюсаренко А. Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия. — М.: Интернет-университет информационных технологий, 2005. — 504 с. — ISBN 5-9556-0045-0.
  • Фаулер М. Архитектура корпоративных программных приложений.: Пер. с англ. — М.: Издательский дом «Вильямс», 2006. — 544 с. ISBN 5-8459-0579-6
  • Pyster, A., D. Olwell, N. Hutchison, S. Enck, J. Anthony, D. Henry, and A. Squires (eds). Guide to the Systems Engineering Body of Knowledge (SEBoK) version 1.0. — The Trustees of the Stevens Institute of Technology, 2012.
  • Kossiakoff A., Sweet W. N., Seymour S. J., Biemer S. M. Systems Engineering Principles and Practice. — 2-е изд. — Hoboken, New Jersey: A John Wiley & Sons, 2011. — 599 с. — ISBN 978-0-470-40548-2.
  • ISO/IEC 42010:2011. System and software engineering — Architecture description. — 2011.

Архитектура ИТ решений. Часть 2. Архитекторы / Habr

С предыдущей частью статьи можно ознакомиться, перейдя по ссылке

III Определение понятия архитектор


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

Зачастую в ИТ отрасли, говоря об ИТ архитекторе, подразумевают продвинутого разработчика, способного самостоятельно спроектировать, а главное реализовать большую сложную систему. А иногда попросту полагают, что это следующая ступенька в профессиональной иерархии разработчиков. Например, начал молодой специалист свою карьеру разработчика, ему присвоили скромное, но почетное звание Junior. Он учится, развивается профессионально, растет над собой и коллегами, и ему, в качестве компенсации за труд и упорство, торжественно присваивается звание Middle. Но он неугомонный и дальше не останавливается в развитии, совершает ряд подвигов, самоотверженно взвалив на себя ответственность за принимаемые решения. Глядишь, и его уже удостаивают высочайшего звания Sinior. А дальше? А если он не желает почивать на лаврах успеха и хочет развиваться, ему что присвоят под звуки фанфар генеральское звание Архитектора? Так ли это?

Специально ИТ архитекторов, насколько мне известно, не готовят в вузах. Чаще всего архитекторы получаются путем селекции из уже маститых специалистов в какой-либо ИТ области, «прокачивая» дополнительными знаниями до определенного уровня.

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

1. Обзор обязанностей и ответственности ИТ архитектора


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

Из определения следует, что деятельность ИТ архитекторов охватывает очень большой круг вопросов и компетенций. А поэтому есть необходимость делить ее по специализациям, например, соответствующим разделам архитектуры, рассмотренными нами в предыдущем разделе: Enterprise — Архитектор, Solution — Архитектор, Technical — Архитектор.

Чаще на практике можно встретить деление на: Бизнес — архитекторов и Технических архитекторов. При этом:

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

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

Итак, каков же набор профессиональных активностей должен вменяться в обязанности ИТ архитектора?

Для всех специализаций актуальны следующие тренды:

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

Читая статьи архитекторов о самих себе, в каждом абзаце чувствуется особая значимость этой позиции, принадлежность к высшей касте ИТ специалистов, не двусмысленно дающая понять, что их – архитекторов, на земле не так уж и много. Видимо и стать архитектором можно только обладая целым набором способностей, знаний и навыков. Чаще всего в литературе выделяют следующие:
  • Широкий кругозор, который необходимо постоянно поддерживать. Включая не только технологическую сторону, но и социальные моменты, аспекты экономической целесообразности и т.п.;
  • Умение работать в коллективе, завоевывать авторитет, управлять командой, проявлять дипломатичность;
  • Развитое чувство ответственности;
  • Способность и потребность к самообразованию;
  • Умение четко, доступно и аргументировано доносить свою точку зрения;
  • Чувство пропорции;
  • Умение чувствовать тенденции: изменений, развития, востребованности и т.п.;

Итак, что же делает архитектора такой важной и эксклюзивной персоной в организации?

2. Место ИТ Архитектора в процессе производства информационных систем


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

Рисунок 5. Структура взаимодействия ИТ архитектора

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

Чаще всего процесс производства программных продуктов начинается с зарождения у заказчика потребности в том или ином поступательном движении к собственному развитию. При этом, как правило, у него уже существует некая архитектура предприятия. Ведь выполняются какие-то процессы, существует организационная структура, регламенты взаимодействия. Наконец, наверняка должны быть вычислительные устройства, соединенные в сеть и какое-то программное обеспечение. Поэтому первое, чем должен озаботиться ИТ архитектор – это описание текущей архитектуры, базового ее состояния. И уже отталкиваясь от сего понимания, определив узкие места и дискомфортное, с точки зрения предприятия обустройство ее жизнедеятельности, проектировать новую, желаемую модель архитектуры, которую называют целевой. В вышеупомянутом документе с квалификационными требованиями, эта активность регламентирована как: «Сбор и анализ требований к разрабатываемой компоненте, оценка осуществимости и выработка критериев их выполнения» (5).

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

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

Для удобства восприятия и обсуждения, стратегия делится на сегменты, приоритезируется и обсчитывается на предмет трудозатрат, с прецизионностью «что-то около того». Этот документ становится предметом обсуждения и торга межу заказчиком (потребителем новаций), подрядчиками (исполнителями работ) и возможно, спонсорами, от которых требуется оплатить все эти изыски. Для проведения подобных работ ИТ архитектор должен уметь понимать бизнес и говорить с ним на одном (их родном) языке, максимально убедительно презентуя свои решения. В квалификационных требованиях, по этому поводу предписано: «Участие во взаимодействии с заказчиком по обсуждению проектных решений. Участие во взаимодействии с заказчиком по вопросам бюджетных расходов и сдачи проекта» (5).

Если концепция архитектуры и стратегия перехода к ней получили признание всех заинтересованных лиц и прошли горнило финансово-договорных испытаний, для дальнейшего производства информационной системы, необходимо разработать техническую документацию, включая Техническое задание. С этой задачей архитекторам чаще всего помогают справиться помощники, в виде: бизнес и системных аналитиков, технических писателей и прочих соучастников. Архитектор, в зависимости от своих предпочтений, возможностей и личной внутренней «коллективной интеллигентности», может в разной степени принимать персональное участие в данном процессе. Но основная его забота и ответственность — соблюсти строгое следование разработанной архитектуре и, в случае острой необходимости, зафиксировать изменения в ней. В квалификационных требованиях, это отмечено как: «Разработка требований различных типов к программному изделию. Обеспечение корректности и оптимальности архитектуры проекта. Участие в документировании проекта» (5).

В равной мере, на совести архитектора лежит еще и контроль полноты и комплектности артефактов, генерируемых проектной командой. Ведь они послужат основой для выполнения дальнейших работ по разработке собственно самого программного продукта, а также его тестированния, внедрения, поддержки и т.п. Все артефакты должны соответствовать стандартам фреймверка, выбранного в интересах предприятия, и призванного обеспечить полномасштабную поддержу описания архитектуры см. раздел II.2. Ведь как мы отметили в предыдущей части, именно наличие одних архитектурных артефактов в череде проектирования, предоставляет возможность для создания на их базе — следующих в цепочке артефактов. Этот технологический конвейер, должен шаг за шагом заполнять все пустоты в каркасе представления архитектуры предприятия. Об этом в квалификационных требованиях, естественно тоже упомянуто: «Контроль проектной и технической документации. Разработка концепции реализации системы программного изделия по спецификациям» (5).

Еще один важный аспект трудовой повинности архитектора – это определение экономической и деловой целесообразности внедрения целевой архитектуры. И в этом деле его главная опора и поддержка — руководитель проекта, а также руководители ключевых подразделений, участвующих в процессе разработки и внедрения информационной системы. Именно с их помощью архитектор должен определить возможность выполнения проекта в принципе, и в заданных рамках трудовых, финансовых и прочих затрат в частности. В квалификационных требованиях, указано: «Участие в планировании проекта, Участие в управлении проектом. Координация сбора и анализа требований к разрабатываемой компоненте, оценка осуществимости и выработка критериев их выполнения» (5).

Ну и конечно одной из центральной функций архитектора является контроль качества производства самого целевого продукта и его соответствия — концепции архитектуры. В квалификационных требованиях: «Контроль исполнения архитектурных решений. Анализ качества продукта и его соответствия требованиям и спецификациям» (5).

Контроль должен охватить все мероприятия, направленные на достижение выработанной стратегии ИТ модернизации предприятия. Включая, например, указанную в квалификационных требованиях: «Организацию и планирование тестирования» (5).

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

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

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

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

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

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

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

3. Резюме раздела


Подытожим рассмотренный материал.
  1. В связи с широчайшим кругом функциональных обязанностей, ИТ архитекторы делятся по специализациям. Каждая специализация охватывает конкретный круг вопросов, требующих владения определенными компетенциями, навыками и знаниями.
  2. Успешно выполнять функции архитектора может только специалист, обладающий определенным набором способностей и поведенческих моделей, с явно выраженным потенциалом развития.
  3. Архитектор должен обладать целым рядом компетенций, позволяющих ему–оценивать текущее состояние дел на предприятии, определять проблемы и узкие места, разрабатывать целевую архитектуру и формировать стратегию перехода к ней.
  4. Одним из архиполезных навыков архитектора является умение квалифицированно и эффективно общаться с разными группами заинтересованных лиц, учитывая их квалификацию, сферу деятельности и даже социальный статус.
  5. Архитектор должен уметь качественно оценивать деловые и экономические аспекты, предлагаемых им стратегий.
  6. Одной из важнейших функций архитектора является контроль, за качественным описанием архитектуры, соблюдением архитектурных решением в процессе производства информационной системы, качеством и точностью выполнения мероприятий по воплощению разработанной стратегии.

Список литературы1. Википедия. Архитектура программного обеспечения. [электронный ресурс] — Режим доступа: ru.wikipedia.org/wiki/Архитектура_программного_обеспечения, свободный. — Загл. с экрана.

2. Свободная энциклопедия Википедия. Архитектура системы. Режим доступа: ru.wikipedia.org/wiki/Архитектура_системы, свободный. — Загл. с экрана.

3. Ю.М, Мадорская. Схема Захмана при разработке требований к ИС. б.м.: Практика проектирования систем.-2015. [электронный ресурс]. Режим доступа: reqcenter.pro/zachman-framework, свободный. — Загл. с экрана.

4. Рубенчик, Андрей. Моделирование архитектуры предприятия. Обзор языка ArchiMate. Корпоративный менеджмент. [электронный ресурс]. Режим доступа: www.cfin.ru/itm/standards/ArchiMate.shtml, свободный. — Загл. с экрана.

5. коллектив, Авторский. Квалификационные требования в области информационных технологий «СИСТЕМНЫЙ АРХИТЕКТОР». Режим доступа rosexpertpravo.ru/law/Index2/1/4293830/4293830557.htm, свободный. — Загл. с экрана.

6. БудуГуру, Сайт. ИТ-архитектор. Режим доступа buduguru.org/profession/2, свободный. — Загл. с экрана.

Большой гайд по профессии архитектора решений (+список полезных ссылок)

Еще лет 10 лет назад роль архитектора решений (Solution Architect) на проектах выполняли сами разработчики. Теперь это отдельная профессия, довольно востребованная и активно обсуждаемая. Вместе с коллегами-архитекторами подробно разбираемся во всех деталях и рассказываем, как стать архитектором в EPAM.

Начнем с азов: что означает слово «решение» в контексте IT?


Это продукт или комплекс продуктов, который решает конкретную техническую или бизнес-задачу. Решение нужно бизнесу, чтобы увеличить прибыль: оно либо повышает доходы, либо снижает издержки — к примеру, автоматизирует бизнес-процессы и тем самым снижает расходы на оплату труда. Решение встраивается в архитектуру предприятия и связывается с другими ее компонентами. Большинство проектов EPAM направлены на создание решений: разработка от начала и до конца или отдельных компонентов.

Выходит, на каждом проекте по разработке нужен архитектор?


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

Алексей Кожемякин (Director, Technology Solutions, EPAM Belarus):
«Как только инженер задумался о нуждах бизнеса — он ступил на путь Solution Architect».

Почему раньше обходились и без архитекторов?


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

В отличие от разработчика, архитектор мыслит абстракциями более высокого уровня. Он размышляет не о взаимодействии классов, а о взаимодействии компонентов решения – приложений, веб-сервисов и так далее. Хотя, если требуется, он должен без проблем «провалиться» в детали кода. Кроме этого, бизнес-сторона решения для архитектора важна так же, как и техническая. Разработчики часто фокусируются на технологиях и новых библиотеках, с которыми хочется познакомиться; архитектор же отталкивается от интересов и потребностей заказчика.

Так кто главнее: архитектор или разработчик?


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

Конкретнее: какими задачами занимается архитектор решений?


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

Для некоторых частей решения SA делает proof-of-concept – небольшую экспериментально-исследовательскую задачу, чтобы понять, возможно ли реализовать тот или иной функционал.
Архитекторы участвуют в предпродажах, консультируют клиентов, проводят аудит архитектуры существующего решения – оценивают, насколько она эффективна для поставленных задач, можно ли ее оптимизировать, и если да, то как.

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

Владимир Казакевич (Senior Solution Architect, EPAM Belarus):
«Каждый понимает слово «бизнес» по-своему. И задача архитектора решений — вникнуть в бизнес заказчика настолько глубоко, насколько это возможно, а главное — результатом его работы должны быть решения, «заточенные» под конкретных заказчиков и их конкретные бизнес-проблемы».

А есть ли какие-то еще архитекторы?


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

В EPAM, например, архитекторы решений пока в большинстве.

Кто может стать архитектором решений?


Как правило, в архитекторы решений вырастают ведущие разработчики. Кандидату следует иметь солидный багаж технических знаний, широкий кругозор, а также опыт руководства командой и проектом. Лидерство и отличные коммуникационные навыки – мастхэв архитектора, который часто становится связующим звеном между командой заказчика и компании. Одна сторона ожидает, что архитектор придет, вникнет в положение дел, все объяснит и поможет с принятием решения. Проектная команда, в свою очередь, ждет от SA решения о том, что и как нужно делать, и в какой последовательности.
Роман Шрамков (Director, Technology Solutions, EPAM Ukraine):
«Для того, чтобы бизнес и менеджмент увидел возможности для применения технологий, нужен настоящий гик, который объяснит им какие в этом преимущества и как это можно сделать».

Помимо разработчиков, попробовать себя в архитектуре решений могут бизнес-аналитики, деливери-менеджеры, проектные менеджеры, ресурсные менеджеры, а также тестировщики-автоматизаторы: для них есть даже специальная поддисциплина — Solution Architecture in Test Automation.

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

Дмитрий Гурский (Lead Solution Architect, EPAM Belarus):
«У того, кто хочет стать архитектором, прежде всего, должно быть желание что-то создавать, строить. И это не навык, который можно прокачать, это внутренняя потребность — либо она есть, либо нет».

Какие образовательные программы для будущих архитекторов есть в EPAM?


Так как Solution Architect, как отдельная должность, появилась на рынке сравнительно недавно, ее понимание в разных компаниях отличается. В EPAM создан центр компетенций по архитектуре, команда которого формирует единое представление об этой роли, основываясь на опыте работы с клиентами, их бизнес-задачах и ожиданиях, лучших практиках, внутренних процессах и системах.

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

Для начала можно присоединиться к Architecture Excellence Initiative – глобальному архитектурному сообществу EPAM, чтобы быть в курсе последних новостей и тенденций в области архитектуры. Участники комьюнити еженедельно общаются с архитекторами из более чем 25 стран. Оперативный обмен кейсами, доступ к обширной библиотеке и вебинарам, собранной коллегами – это сюда.

Дальше – обучение в Solution Architecture School. Это уникальная программа, которую в компании создавали с нуля: групповые занятия с лекциями и практикой ведут действующие архитекторы компании. Здесь все как в обычной школе – домашние задания, включающие разработку дизайна, постоянное общение с преподавателями и защита контрольной выпускной работы.

Что делать, если пришел в EPAM уже архитектором?


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

Архитекторам буду рады в Global Solution Architecture Team – команде экспертов, которые активно участвуют в развитии дисциплины: разрабатывают лучшие практики в компании, координируют глобальные образовательные программы для архитекторов, консультируют коллег и клиентов.

Ну, а если не хочется останавливаться на достигнутом, можно стать студентом Solution Architecture University — трёхуровневой программы, которая помогает опытным архитекторам синхронизировать знания и заговорить на едином языке. У студентов есть возможность пройти сертификации в Software Engineering Institute, IASA Global и других ассоциациях, с которыми сотрудничает EPAM.

Еще одна инициатива — Solution Architecture Mentoring — менторами в которой выступают опытные архитекторы, технические директора и CTO компании. Менти вовлечены в переговоры с клиентами, вместе с наставниками работают над реальными проектами и задачами. Программа помогает архитекторам «прокачаться» в профессии и даже вырасти до уровня CTO.

Полезные ссылки для настоящих и будущих архитекторов:


Почитать об архитекторах решений в EPAM:
Интервью с CTO EPAM Эли Фельдманом
Lead Solution Architect Дмитрий Гурский об уровнях архитектуры в EPAM для dev.by
5 мифов о работе архитектора решений. Мнение Андрея Трубицына

Книги по теме «Архитектура решений»:
Software Architecture in Practice (3rd Edition)
Designing Software Architectures: A Practical Approach (SEI Series in Software Engineering) 1st Edition
Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspective
DevOps: A Software Architect’s Perspective (SEI Series in Software Engineering)
Implementing Domain-Driven Design

Видео:
The Hard Way to Architects from Front-enders
Authentic Reality: Creating Experiences for Today’s Customers
Blocking and Tackling: The Real Nuts and Bolts of Blockchain
Production Foundation Platform is a Bit More that a Data Lake
Happiness as a Service with Cloud Foundry and OpenShift

Архитектура программного обеспечения — Википедия

Архитектура программного обеспечения (англ. software architecture) — совокупность важнейших решений об организации программной системы. Архитектура включает:

  • выбор структурных элементов и их интерфейсов, с помощью которых составлена система, а также их поведения в рамках сотрудничества структурных элементов;
  • соединение выбранных элементов структуры и поведения во всё более крупные системы;
  • архитектурный стиль, который направляет всю организацию — все элементы, их интерфейсы, их сотрудничество и их соединение[1][2].

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

Общепринятого определения «архитектуры программного обеспечения» не существует. Так, сайт Software Engineering Institute приводит более 150 определений этого понятия[4][5].

Область компьютерных наук с момента своего образования столкнулась с проблемами, связанными со сложностью программных систем. Ранее проблемы сложности решались разработчиками путём правильного выбора структур данных, разработки алгоритмов и применения концепции разграничения полномочий. Хотя термин «архитектура программного обеспечения» является относительно новым для индустрии разработки ПО, фундаментальные принципы этой области неупорядоченно применялись пионерами разработки ПО начиная с середины 1980-х. Первые попытки осознать и объяснить программную архитектуру системы были полны неточностей и страдали от недостатка организованности, часто это была просто диаграмма из блоков, соединенных линиями. В 1990-е годы наблюдается попытка определить и систематизировать основные аспекты данной дисциплины. Первоначальный набор шаблонов проектирования, стилей проектирования, передового опыта (best practices), языков описания и формальная логика были разработаны в течение этого времени[6].

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

Являясь в настоящий момент своего развития дисциплиной без четких правил о «правильном» пути создания системы, проектирование архитектуры ПО все ещё является смесью науки и искусства. Аспект «искусства» заключается в том, что любая коммерческая система подразумевает наличие применения или миссии. С точки зрения пользователя программной архитектуры, программная архитектура дает направление для движения и решения задач, связанных со специальностью каждого такого пользователя, например, заинтересованного лица, разработчика ПО, группы поддержки ПО, специалиста по сопровождению ПО, специалиста по развертыванию ПО, тестера, а также конечных пользователей. В этом смысле архитектура программного обеспечения на самом деле объединяет различные точки зрения на систему. Тот факт, что эти несколько различных точек зрения могут быть объединены в архитектуре программного обеспечения, является аргументом в защиту необходимости и целесообразности создания архитектуры ПО ещё до этапа разработки ПО[7][8][9].

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

В развитии архитектуры программного обеспечения как дисциплины играют важную роль научно-исследовательские учреждения. Мэри Шоу и Дэвид Гэрлан из университета Carnegie Mellon написали книгу под названием «Архитектура программного обеспечения: перспективы новой дисциплины в 1996 году», в которой выдвинули концепции архитектуры программного обеспечения, такие как компоненты, соединители (connectors), стили и так далее. В калифорнийском университете институт Ирвайна по исследованию ПО в первую очередь исследует архитектурные стили, языки описания архитектуры и динамические архитектуры.

Первым стандартом программной архитектуры является стандарт IEEE 1471: ANSI / IEEE 1471—2000: Рекомендации по описанию преимущественно программных систем. Он был принят в 2007 году, под названием ISO ISO / IEC 42010:2007.

Языки описания архитектуры (ADLS) используются для описания архитектуры программного обеспечения. Различными организациями было разработано несколько различных ADLS, в том числе AADL (стандарт SAE), Wright (разработан в университете Carnegie Mellon), Acme (разработан в университете Carnegie Mellon), xADL (разработан в UCI), Darwin (разработан в Imperial College в Лондоне), DAOP-ADL (разработан в Университете Малаги), а также ByADL (Университет L’Aquila, Италия). Общими элементами для всех этих языков являются понятия компонента, коннектора и конфигурации. Также, помимо специализированных языков, для описания архитектуры часто используется унифицированный язык моделирования UML.

Архитектура ПО обычно содержит несколько видов, которые аналогичны различным типам чертежей в строительстве зданий. В онтологии, установленной ANSI / IEEE 1471—2000, виды являются экземплярами точки зрения, где точка зрения существует для описания архитектуры с точки зрения заданного множества заинтересованных лиц.

Архитектурный вид состоит из 2 компонентов:

  • Элементы
  • Отношения между элементами

Архитектурные виды можно поделить на 3 основных типа[10]:

  1. Модульные виды (англ. module views) — показывают систему как структуру из различных программных блоков.
  2. Компоненты-и-коннекторы (англ. component-and-connector views) — показывают систему как структуру из параллельно запущенных элементов (компонентов) и способов их взаимодействия (коннекторов).
  3. Размещение (англ. allocation views) — показывает размещение элементов системы во внешних средах.

Примеры модульных видов:

  • Декомпозиция (англ. decomposition view) — состоит из модулей в контексте отношения «является подмодулем»
  • Использование (англ. uses view) — состоит из модулей в контексте отношения «использует» (т.е. один модуль использует сервисы другого модуля)
  • Вид уровней (англ. layered view) — показывает структуру, в которой связанные по функциональности модули объединены в группы (уровни)
  • Вид классов/обобщений (англ. class/generalization view) — состоит из классов, связанные через отношения «наследуется от» и «является экземпляром»

Примеры видов компонентов-и-коннекторов:

  • Процессный вид (англ. process view) — состоит из процессов, соединённых операциями коммуникации, синхронизации и/или исключения
  • Параллельный вид (англ. concurrency view) — состоит из компонентов и коннекторов, где коннекторы представляют собой «логические потоки»
  • Вид обмена данными (англ. shared-data (repository) view) — состоит из компонентов и коннекторов, которые создают, сохраняют и получают постоянные данные
  • Вид клиент-сервер (англ. client-server view) — состоит из взаимодействующих клиентов и серверов, а также коннекторов между ними (например, протоколов и общих сообщений)

Примеры видов размещения:

  • Развертывание (англ. deployment view) — состоит из программных элементов, их размещения на физических носителях и коммуникационных элементов
  • Внедрение (англ. implementation view) — состоит из программных элементов и их соответствия файловым структурам в различных средах (разработческой, интеграционной и т.д.)
  • Распределение работы (англ. work assignment view) — состоит из модулей и описания того, кто ответственен за внедрение каждого из них

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

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

Примеры архитектурных шаблонов:

  • Многоуровневый шаблон (Layered pattern). Система разбивается на уровни, которые на диаграмме изображаются один над другим. Каждый уровень может вызывать только уровень на 1 ниже него. Таким образом разработку каждого уровня можно вести относительно независимо, что повышает модифицируемость системы. Недостатками данного подхода являются усложнение системы и снижение производительности.
  • Шаблон посредника (Broker pattern). Когда в системе присутствует большое количество модулей, их прямое взаимодействие друг с другом становится слишком сложным. Для решения проблемы вводится посредник (например, шина данных), по которой модули общаются друг с другом. Таким образом, повышается функциональная совместимость модулей системы. Все недостатки вытекают из наличия посредника: он понижает производительность, его недоступность может сделать недоступной всю систему, он может стать объектом атак и узким местом системы.
  • Шаблон «Модель-Представление-Контроллер» (Model-View-Controller pattern). Т.к. требования к интерфейсу меняются чаще всего, то возникает потребность часто его модифицировать, при этом сохраняя корректное взаимодействие с данными (чтение, сохранение). Для этого в шаблоне Model-View-Controller (MVC) интерфейс отделён от данных. Это позволяет менять интерфейсы, равно как и создавать их разные варианты. В MVC система разделена на:
    • Модель, хранящую данные
    • Представление, отображающее часть данных и взаимодействующее с пользователем
    • Контроллер, являющийся посредником между видами и моделью

Однако, концепция MVC имеет и свои недостатки. В частности, из-за усложнения взаимодействия падает скорость работы системы.

  • Клиент-серверный шаблон (Client-Server pattern). Если есть ограниченное число ресурсов, к которым требуется ограниченный правами доступ большого числа потребителей, то удобно реализовать клиент-серверную архитектуру. Такой подход повышает масштабируемость и доступность системы. Но при этом сервер может стать узким местом системы, при его недоступности становится недоступна вся система.

Базовые фреймворки для архитектуры ПО[править | править код]

Существуют следующие фреймворки (англ. software architecture frameworks), относящиеся к области архитектуры ПО:

  • 4+1
  • RM-ODP (Reference Model of Open Distributed Processing)
  • Service-Oriented Modeling Framework (SOMF)

Такие примеры архитектур, как фреймворк Захмана (Zachman Framework), DoDAF и TOGAF, относятся к области архитектуры предприятия (enterprise architectures).

  1. ↑ Kruchten, Philippe. The Rational Unified Process-An Introduction, Addison-Wesley, 1998
  2. ↑ Rumbaugh, J., Jacobsen, I. and Booch, G. The Unified Modelling Language Reference Manual. Reading, Mass.: Addison-Wesley, 1999
  3. ↑ Documenting Software Architectures: Views and Beyond, 2010, P.1.1. Overview.
  4. ↑ Documenting Software Architectures: Views and Beyond, 2010, P.1.2. Architecture and Quality Attributes.
  5. ↑ Software Architecture:Glossary, Software Engineering Institute
  6. ↑ What Is Your Definition of Software Architecture (англ.). resources.sei.cmu.edu. Дата обращения 23 октября 2019.
  7. ↑ ISO/IEC/IEEE 42010: Defining "architecture" (неопр.). www.iso-architecture.org. Дата обращения 23 октября 2019.
  8. M. Fowler. Design - Who needs an architect? // IEEE Software. — 2003-9. — Т. 20, вып. 5. — С. 11–13. — DOI:10.1109/MS.2003.1231144.
  9. ↑ An Introduction to Software Architecture (неопр.).
  10. Len Bass, Paul Clements, Rick Kazman. Software Architecture in Practice (3rd Edition) (SEI Series in Software Engineering). — 3 edition (October 5, 2012). — 2012. — 640 с. — ISBN 978-0321815736.
  • Paul Clements; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Paulo Merson; Robert Nord; Judith Stafford. Documenting Software Architectures: Views and Beyond. — Second Edition. — Addison-Wesley Professional, 2010. — ISBN 978-0-13-248861-7.
  • Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice, Third Edition. Addison Wesley, 2012, ISBN 978-0321815736 (This book, now in third edition, eloquently covers the fundamental concepts of the discipline. The theme is centered around achieving quality attributes of a system.)

Архитектурное решение — Википедия

Материал из Википедии — свободной энциклопедии

Архитекту́рное реше́ние (архитектурные решения, АР) — часть проектной работы, направленной на создание документации для производства строительных работ.

Архитектурное решение здания (архитектура здания) — авторский замысел объекта с комплексным решением функциональных, конструктивных, и эстетических требований к нему, а также социальных, экономических, санитарно-гигиенических, экологических, инженерно-технических аспектов, зафиксированных в архитектурной части документации для строительства (проекта) и реализуемые при строительстве. Главными разделами являются: архитектурно-художественные, архитектурно-планировочные и конструктивные решения[1].

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

  • конструктивный раздел;
  • инженерный раздел;
  • смета.

Архитектурно-планировочное решение

Архитектурно-планировочное решение здания — проектные материалы, представляющие поэтажные планы здания, проработанные с учётом планировочной схемы, функционально-планировочного и объёмно-планировочного решений[1].

Видео по теме

Архитектурно-художественное решение

Архитектурно-художественное решение (архитектурно-художественный образ, облик) здания — проектные материалы, представляющие внешний вид и интерьеры объекта, выполненные в соответствии с концепцией, выбранным архитектурным стилем, посредством проработки объёмно-пространственного, архитектурно-композиционного решений и архитектурно-художественных приёмов[1].

Архитектурно-композиционное решение

Архитектурно-композиционное решение здания — построение композиции объёмов всего здания, фасадов, интерьеров при обработке объёмно-пространственного решения посредством архитектоники объёмных форм и архитектурно-художественных приёмов[1].

Объёмно-планировочное решение

Объёмно-планировочное решение здания — решение поэтажных планов, где взаимосвязаны габариты и форма помещений в плане и в общем объёме здания[1].

Функционально-планировочное решение

Функционально-планировочное решение здания — решение поэтажных планов, где определены набор помещений, их назначение и функциональные взаимосвязи[1].

Объёмно-пространственное решение

Объёмно-пространственное решение здания — моделирование внешней формы объёма здания на основе объёмно-планировочного решения.

См. также

Примечания

Литература

  • Лахтин В. Н. Система расселения и архитектурно-планировочная структура городов Урала / В. Н. Лахтин. — М.: Стройиздат, 1977. — 128 с.

Архитектурное решение — Википедия. Что такое Архитектурное решение

Архитекту́рное реше́ние (архитектурные решения, АР) — часть проектной работы, направленной на создание документации для производства строительных работ.

Архитектурное решение здания (архитектура здания) — авторский замысел объекта с комплексным решением функциональных, конструктивных, и эстетических требований к нему, а также социальных, экономических, санитарно-гигиенических, экологических, инженерно-технических аспектов, зафиксированных в архитектурной части документации для строительства (проекта) и реализуемые при строительстве. Главными разделами являются: архитектурно-художественные, архитектурно-планировочные и конструктивные решения[1].

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

  • конструктивный раздел;
  • инженерный раздел;
  • смета.

Архитектурно-планировочное решение

Архитектурно-планировочное решение здания — проектные материалы, представляющие поэтажные планы здания, проработанные с учётом планировочной схемы, функционально-планировочного и объёмно-планировочного решений[1].

Архитектурно-художественное решение

Архитектурно-художественное решение (архитектурно-художественный образ, облик) здания — проектные материалы, представляющие внешний вид и интерьеры объекта, выполненные в соответствии с концепцией, выбранным архитектурным стилем, посредством проработки объёмно-пространственного, архитектурно-композиционного решений и архитектурно-художественных приёмов[1].

Архитектурно-композиционное решение

Архитектурно-композиционное решение здания — построение композиции объёмов всего здания, фасадов, интерьеров при обработке объёмно-пространственного решения посредством архитектоники объёмных форм и архитектурно-художественных приёмов[1].

Объёмно-планировочное решение

Объёмно-планировочное решение здания — решение поэтажных планов, где взаимосвязаны габариты и форма помещений в плане и в общем объёме здания[1].

Функционально-планировочное решение

Функционально-планировочное решение здания — решение поэтажных планов, где определены набор помещений, их назначение и функциональные взаимосвязи[1].

Объёмно-пространственное решение

Объёмно-пространственное решение здания — моделирование внешней формы объёма здания на основе объёмно-планировочного решения.

См. также

Примечания

Литература

  • Лахтин В. Н. Система расселения и архитектурно-планировочная структура городов Урала / В. Н. Лахтин. — М.: Стройиздат, 1977. — 128 с.

Архитектурное решение — Карта знаний

  • Архитекту́рное реше́ние (архитектурные решения, АР) — часть проектной работы, направленной на создание документации для производства строительных работ.

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

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

    * конструктивный раздел;

    * инженерный раздел;

    * смета.

Источник: Википедия

Связанные понятия

Архитектурный проект — архитектурная часть строительной и градостроительной документации, содержащая архитектурные решения в объеме, необходимом для разработки документации для строительства объектов, в проектировании которых необходимо участие архитектора. Архитектурные решения должны комплексно учитывать социальные, экономические, функциональные, инженерные, технические, противопожарные, санитарно-гигиенические, экологические, архитектурно-художественные и иные требования к объекту. Многофункциональное здание (англ. multifunctional building) — один из перспективных видов архитектурных объектов в современной городской застройке. Их строительство сегодня быстро и динамично развиваются, являясь востребованным объектом инвестиций, стимулируя при этом развитие новых технологий, инженерно-технических решений и архитектурно-планировочных приемов. Диза́йн интерье́ра (интерье́рный диза́йн) — отрасль дизайна, направленная на интерьер помещений с целью обеспечить удобство и эстетически приятное взаимодействие среды с людьми. Интерьерный дизайн сочетает в себе художественный и промышленный дизайн. Дизайнер выполняет оптимизацию труда в помещении, улучшает навигацию в крупных помещениях, разрабатывает оформление специализированных помещений (например, студий звукозаписи, киномонтажа, фотографии; аквапарков) согласно требованиям клиентов. Дизайнер... Градостроительное проектирование (городское проектирование) изучает пространственную конфигурацию, внешний облик и функциональность элементов города или иного населенного пункта. Особое внимание уделяется разработке конфигурации мест общего пользования, в которых осуществляется повседневная деятельность горожан (улицы, площади, парки, общественная инфраструктура). Градостроительное проектирование является дисциплиной, находящейся на стыке и синтезирующей подходы городского (урбанистического) планирования...

Упоминания в литературе

Таким образом, архитектурные решения являются составной частью проектной документации, а работы по разработке архитектурных решений – частью (видом) работ по подготовке проектной документации. При этом архитектурное решение в отдельности представляет собой авторский замысел архитектурного объекта (здания, сооружения, комплекса зданий и сооружений, их интерьера, объектов благоустройства, ландшафтного или садово-паркового искусства) – его внешнего и внутреннего облика, пространственной, планировочной и функциональной организации, зафиксированный в архитектурной части документации для строительства и реализованный в построенном архитектурном объекте. А в своей совокупности архитектурные решения, которые комплексно учитывают социальные, экономические, функциональные, инженерные, технические, противопожарные, санитарно-гигиенические, экологические, архитектурно-художественные и иные требования к объекту в объеме, необходимом для разработки документации для строительства объектов, в проектировании которых необходимо участие архитектора, содержатся в архитектурной части проектной документации – архитектурном проекте. В случае, если застройщик имеет намерение осуществить строительство, реконструкцию (далее – строительство) архитектурного объекта (здание, сооружение, комплекс зданий и сооружений, их интерьер, объекты благоустройства, ландшафтного или садово-паркового искусства, созданные на основе архитектурного проекта), для строительства которого требуется разрешение на строительство, он также обязан иметь архитектурный проект (архитектурный проект – архитектурная часть документации для строительства и градостроительной документации, содержащая архитектурные решения, которые комплексно учитывают социальные, экономические, функциональные, инженерные, технические, противопожарные, санитарно-эпидемиологические, экологические, архитектурно-художественные и иные требования к объекту в объеме, необходимом для разработки документации для строительства объектов, в проектировании которых необходимо участие архитектора), выполненный в соответствии с архитектурно-планировочным заданием (ст. 3 ФЗ «Об архитектурной деятельности в Российской Федерации»). АРХИТЕКТУРНОЕ РЕШЕНИЕ – авторский замысел архитектурного объекта, его внешнего и внутреннего облика, пространственной, планировочной и функциональной организации, зафиксированный в архитектурной части документации для строительства и реализованный в построенном архитектурном объекте (ст. 2 Федерального закона от 17 ноября 1995 г. № 169-ФЗ «Об архитектурной деятельности в Российской Федерации»). От архитектурного решения дома зачастую зависят взаимоотношения в семье. В удобном доме легче создать доброжелательный социальный микроклимат, тогда как дисгармония, сложные и напряженные отношения между близкими в большей мере характерны для дома, где жить неуютно. Социологический анализ бытовых процессов дает основание не только для улучшения планировки дома, но и создания архитектуры семейных отношений. Мебель. Существенную роль в интерьере ресторана играет мебель, которая должна гармонировать с его общим характером, отвечать эстетическим требованиям, предъявляемым к ней как к важному элементу интерьера. Форма мебели, ее цвет, расстановка – все это связывается с архитектурным решением зала, его декоративным оформлением. Первый проект архитектурного решения выполнил в 1935 году архитектор М. С. Жиров. Основное внимание он сосредоточил на соединяющей два путепровода насыпи, предложив сделать ее «местом отдыха» (!) и в соответствии с этим поставив по ее сторонам длинные и высокие колоннады[57]. По мысли автора, такое решение придало всему сооружению необходимую монументальность. Какой отдых можно было организовать близ оживленной магистрали, в дыму, извергаемом пролетавшими в нескольких метрах отсюда паровозами, М. С. Жирова, очевидно, не заботило. 1.1. Площади квартир типовой планировки (см. таблицу 1.1) относительно невелики, но все-таки больше, чем в домах советского периода (см. Приложение 2). Архитектурные решения зданий и кварталов не блещут разнообразием, инфраструктура территории ограничивается детскими площадками во дворах и магазинами шаговой доступности на первых этажах, строят такое жилье обычно в непрестижных районах массовой застройки столичных городов (для Москвы это Люберецкие поля, Северный-Виногра-дово, Щербинка, Зеленоград), а также в ближайших пригородах. Основными покупателями недорогих квартир являются либо молодые семьи, либо приезжие из других регионов, либо люди, которым надо срочно разъехаться, кроме того, в домах эконом-класса часть квартир выделяется под муниципальное жилье (для очередников и переселенцев из ветхого фонда), так что возможно неприятное соседство, включая и откровенных маргиналов. Что же – чудес на свете не бывает, либо дорого, но мило, либо дешево, но гнило, хотя «экономичное» жилье – совсем не означает «плохое», просто это самый нижний ценовой диапазон из всех предложений первичного рынка (подробнее об этом см. таблицу 1.2).

Связанные понятия (продолжение)

Архите́ктор (от др.-греч. αρχι- — главный, старший и др.-греч. τέκτων — плотник, строитель) — квалифицированный специалист, который на профессиональной основе осуществляет архитектурное проектирование (организацию архитектурной среды), включая проектирование зданий, в том числе разработку объёмно-планировочных и интерьерных решений. Адаптивная архитектура (Responsive architecture) — это развивающаяся область архитектурной практики, которая измеряет состояние окружающей среды, адаптируя свою форму, цвет или функцию к целям наибольшего соответствия требованиям эксплуатации. К адаптивной архитектуре относится вид архитектурных объектов, которые демонстрируют способность изменять свои характеристики в соответствии с изменениями условий эксплуатации. Архитектурная визуализация — графическое отображение объекта или градостроительной ситуации в архитектуре. Обладает определённой степенью информативности и позволяет наиболее полно представить внешние характеристики будущего сооружения. Генера́льный план (генплан, ГП) в общем смысле — проектный документ, на основании которого осуществляется планировка, застройка, реконструкция и иные виды градостроительного освоения территорий. Основной частью генерального плана (также называемой собственно генеральным планом) является масштабное изображение, полученное методом графического наложения чертежа проектируемого объекта на топографический, инженерно-топографический или фотографический план территории. При этом объектом проектирования... Архитекту́рная инжене́рия (англ. architectural engineering) — научная (инженерная) дисциплина, занимающаяся технологическими аспектами зданий. Соответствующая инженерная специальность называется инженер-архитектор или инженер-строитель. Проекти́рование — процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или её части (ISO 24765). Результатом проектирования является прое́кт — целостная совокупность моделей, свойств или характеристик, описанных в форме, пригодной для реализации системы.:272Проектирование, наряду с анализом требований, является частью большой стадии жизненного цикла системы, называемой определением системы (англ. system definition). Результаты этой стадии являются входной информацией... Типовое проектирование — разработка однотипных проектов зданий, конструкций, сооружений, деталей и других изделий, предназначенных для серийного строительства или производства. Архитекту́ра, или зо́дчество — искусство и наука строить, проектировать здания и сооружения (включая их комплексы), а также сама совокупность зданий и сооружений, создающих пространственную среду для жизни и деятельности человека. Архитектура создает материально организованную среду, необходимую людям для их жизни и деятельности, в соответствии с их устремлениями, а также современными техническими возможностями и эстетическими воззрениями. В архитектуре взаимосвязаны функциональные (назначение, польза... Руководство по энергоэффективному и экологическому проектированию, также Руководство по энергетическому и экологическому проектированию (англ. Leadership in Energy and Environmental Design, LEED) — добровольная система сертификации зданий, относящихся к зелёному строительству, разработанная в 1998 году «Американским советом по зелёным зданиям» для оценки энергоэффективности и экологичности проектов устойчивого развития. Объект капитального строительства — здание, строение, сооружение, а также объекты, строительство которых не завершено (объекты незавершённого строительства), за исключением временных построек, киосков, навесов и других подобных построек. Многофункциональное проектирование — практика градостроительства, предполагающая возможность различного использования зданий или строительных комплексов, комбинирование и совмещение жилого, коммерческого, производственного, административного землепользования. Реновация (лат. renovatio — обновление, возобновление, ремонт) — процесс улучшения, реконструкция, реставрация без разрушения целостности структуры. А́вторский надзо́р — контроль лица, осуществившего подготовку проектной документации, за соблюдением в процессе строительства требований проектной документации. Малые архитектурные формы (МАФ) — вспомогательные архитектурные сооружения, оборудование и художественно-декоративные элементы, обладающие собственными простыми функциями и дополняющие общую композицию архитектурного ансамбля застройки. Некоторые из элементов МАФ не несут утилитарных функций и имеют исключительно художественно-декоративное назначение. Малые архитектурные формы могут играть важную роль в архитектурном ансамбле. В ландшафтном дизайне они являются одними из основных элементов декоративного... Светопрозрачный фасад (КСФН, СПК) — ограждающая конструкция, предназначенная для освещения естественным светом помещений зданий (светопрозрачная конструкция фасада). В этом случае фасадом здания служит система из профилей (стоечно-ригельные, модульные СПК) или без профилей (безкаркасные, вантовые СПК), а также заполнения из стеклопакетов из различного архитектурного и строительного стекла. Системные профили могут быть выполнены из алюминиевых сплавов, стеклокомпозита и стали. Поливинилхлоридные профили... Советская архитектура охватывает период 1917—1991 годов. За это время в ней отразился ряд мировых архитектурных стилей — конструктивизм, рационализм, арт-деко, являющаяся смесью ар-деко, ампира и эклектики сталинская архитектура и брутализм. Эксплика́ция помеще́ний (лат. explicatio — объяснение, развёртывание) — пояснение к архитектурному проекту, эскизу или отдельной его части (как правило, плану) в виде перечня с указанием некоторых количественных, качественных, технических характеристик помещений. Наиболее распространенным видом экспликации является таблица, которая содержит числовые данные общей площади помещения и отдельных его частей. Также в таблице приводятся условные обозначения отдельных помещений, использованные для отображения... Фасадизм — архитектурно-строительный метод, подразумевающий создание фасада отдельно от остальной части здания. Чаще всего практикуется сохранение фасадов исторических зданий как встроенной или примыкающей части современных построек. Типовые проекты зданий общеобразовательных школ — проекты, по которым были построены школы в разных городах СССР.

Подробнее: Типовая школа

Зда́ние, синоним: дом — разновидность наземного строительного сооружения с помещениями, созданного в результате строительной деятельности в целях осуществления определенных потребительских функций, таких как проживание (жилище), хозяйственная или иная деятельность людей, размещение производства, хранение продукции или содержание животных. Здание включает в себя сети инженерно-технического обеспечения и системы (оборудование) инженерно-технического обеспечения. Здание может иметь также эксплуатируемые... Строительная инженерия (также инжиниринг) — инженерия в строительной отрасли, инженерное обеспечение строительства, охватывающее все фазы реализации инвестиционно-строительных проектов: проектирование, строительство, эксплуатацию объектов. В более узком смысле — инженерно-консультационные услуг промышленных, инфраструктурных и прочих объектов. Биотек или бионика — название современной «нео-органической» архитектуры, где выразительность конструкций достигается заимствованием природных форм. Нередко противопоставляется хай-теку. Жизненный цикл здания или сооружения — период, в течение которого осуществляются инженерные изыскания, проектирование, строительство (в том числе консервация), эксплуатация (в том числе текущие ремонты), реконструкция, капитальный ремонт, снос здания или сооружения. Специальные технические условия (СТУ) - технические нормы, разработанные для конкретного объекта капитального строительства, и содержащие дополнительные к установленным или отсутствующие технические требования в области безопасности, отражающие особенности инженерных изысканий, проектирования, строительства, эксплуатации, а также демонтажа (сноса) объекта. Данный документ также необходим в тех случаях, когда в ходе проектирования невозможно соблюсти выполнение действующих нормативных требований... Зелёное строительство (также Экологическое строительство, Экостроительство, Экодевелопмент) — это вид строительства и эксплуатации зданий, воздействие которых на окружающую среду минимально. Его целью является снижение уровня потребления энергетических и материальных ресурсов на протяжении всего жизненного цикла здания: от выбора участка по проектированию, строительству, эксплуатации, ремонту и сносу. Концептуальное проектирование технических систем — начальная стадия проектирования, на которой принимаются решения определяющие последующий облик, и проводится исследование и согласование параметров созданных технических решений с возможной их организацией. Ста́линская архитекту́ра— направление в архитектуре СССР с середины 1930-х до конца 1950-х годов, представляющее собой характерный узнаваемый сплав нескольких архитектурных стилей и отличающееся от предшествующих направлений в архитектуре СССР и архитектуры 1930—1950-х годов за рубежом. Пришедшая на смену рационализму и конструктивизму в период правления Иосифа Сталина, архитектурная политика способствовала становлению классического монументального стиля, во многих чертах близкого к ампиру, эклектике... Архитектура данных — в области информационных технологий архитектура данных состоит из моделей, политик, правил или стандартов, которые определяют, какие данные собираются, и как они хранятся, размещаются, интегрируются и используются для использования в системах данных и в организациях. Данные обычно являются одним из нескольких доменов архитектуры, которые составляют основу архитектуры предприятия или архитектуры решения. Архитекту́рный маке́т (фр. maquette, от итал. macchietta — набросок) — объёмно-пространственное изображение проектируемого или существующего сооружения, архитектурного ансамбля, города. Архитектурный макет либо достаточно точно воспроизводит оригинал в деталях, в таком случае его называют также моделью, либо с некоторой степенью приближения. Макеты создаются, чтобы проверить архитектурную композицию, согласованность частей сооружений, наглядно ознакомиться с увязкой рельефа местности и основных объемов... Управление проектированием — это организационно-техническая деятельность, которая в рамках условий поставленной задачи позволяет наилучшим образом разработать проектную документацию на новую продукцию. Типовые школы проекта архитектора Лидии Арушановны Степановой (Мосгорпроект) активно строились в Москве в период с 1949 до середины 1950-х годов. Четырёхэтажная школа на 880 учащихся была в 1949—1950 годах единственным типовым проектом, утверждённым к строительству в городе. В 1950 году Л. А. Степанова разработала новый проект пятиэтажной школы, ставший ещё более массовым. Всего в Москве было построено около сотни таких школьных зданий. Школы Л. А. Степановой выделяются характерным фасадом из красного... Серии жилых домов — жилые здания, построенные по объединенной в серию группе типовых проектов, которые, внутри серии могут отличаться этажностью, количеством секций, ориентацией и незначительными деталями архитектурной отделки. Как правило, серия жилых домов имеет ограниченный ряд планировок квартир, общий архитектурный стиль и технологию строительства. Применение серийного проектирования ориентировано на индустриализацию строительства и позволяет получить минимальную себестоимость квадратного метра... Кинетическая архитектура — это такое направление архитектуры, в котором здания сконструированы таким образом, что их части могут двигаться относительно друг друга, не нарушая общую целостность структуры. По-другому кинетическую архитектуру называют динамической, и относят к направлению архитектуры будущего. Сооруже́ние — это объемная, плоскостная или линейная строительная система, имеющая наземную, надземную и (или) подземную части, состоящая из несущих, а в отдельных случаях и ограждающих строительных конструкций и предназначенная для выполнения производственных процессов различного вида, хранения продукции, временного пребывания людей, перемещения людей и грузов (п. 23 ст. 2 Федерального закона от 30.12.2009 № 384-ФЗ «Технический регламент о безопасности зданий и сооружений»). Купольный дом (или купольное домостроение) считается относительно новым направлением в жилой архитектуре, несмотря на многовековую историю купольных жилых конструкций.

About Author


alexxlab

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *