Как описать архитектуру программы


Как объяснить маме, что такое архитектура приложения? | Библиотека программиста

Мама не понимает, чем вы занимаетесь? Попробуйте объяснить. Начать лучше с основ, например, с разбора того, что такое архитектура приложения.

Это тема сложна для понимания, даже если вы немного разбираетесь в технологиях. Но если коротко, архитектура приложения − это набор методов и шаблонов, которые помогают разработчикам создавать структурированные приложения. В этом материале специалисты из команды Crypterium разбирают тему архитектуры и рассказывают о подходе компании к её разработке.

Front-end и Back-bend

Давайте в объяснении того, что есть архитектура приложения, отойдем от технических терминов и проведем аналогию с повседневной жизнью. Посмотрите на свое тело. Все, что находится снаружи, − голова и тело, − это front, а всё, что внутри, − сердце, мозг и внутренние органы, − back.

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

Ключевые принципы разработки Agile-приложения

Теперь, когда мы разобрались с различием front и back частей, давайте рассмотрим два ключевых подхода, которые используют современные разработчики: API First и Loose Coupling. Они позволяют программистам легко менять структуру приложения. Более того, они делают так, что каждая отдельная часть приложения может быть изменена без затрагивания остальных частей.

Метод API First отвечает за высокую скорость работы и нововведения. Идея в том, чтобы ввести данные и получить в ответ API, необходимый для Front-end и Back-end команд разработки: это позволяет им одновременно писать код и параллельно тестировать его. Преимущества метода заключаются в снижении издержек на разработку, увеличении скорости и снижении рисков.

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

Одна из функций, за которую команда приложения любит подход API First, называется Swagger − это open-source фреймворк, который помогает разработчикам строить архитектуру, проектировать и создавать документацию для своих приложений. Swagger автоматически генерирует описание API для большинства языков и фреймворков, для обеих − Front-end и Back-end − команд.

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

Система Loose Coupling уменьшает риск случайного изменения отдельных объектов, без изменения других − так как в приложении всё взаимосвязано, это может привести к поломкам и уязвимостям. Так вот, благодаря возможности ограничения работы отдельных соединений, система помогает найти и решить проблему быстрее, прямо во время тестирования.

Микросервисы против монолита

Благодаря принципам API First и Loose Coupling, приложение может выступать микросервисом − приложением, состоящем из независимых служб, способных работать самостоятельно, свободно масштабироваться на разных устройствах.

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

Представьте себе умный дом, где все можно контролировать и управлять с помощью одного устройства. Допустим, это устройство − * core *, а управляемыми элементами являются * services *. С помощью основного устройства вы можете открывать окна, включать телевизор или даже закрывать шторы. Так работает архитектура микросервисов.

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

Представьте себе многослойный шоколадный торт. Каждый новый слой делает торт ещё вкуснее, но вы не можете добавить слой с клубникой в середину, не изменив вкус и структуру торта. Можно считать, что у торта − монолитная архитектура.

.NET Core против JVM-платформ

Мультифункциональные приложения, например, мобильные кошельки, обычно связаны ещё с сотнями различных служб. Чтобы структурировать работу приложения, в Crypterium разделили команду Back-end разработчиков на две. Одна работает только над ядром продукта, вторая − над всем остальным, то есть авторизацией, коммуникацией и так далее.

Каждая команда использует собственные фреймворки. Основная выбрала .NET Core − платформу, которая характеризуется быстрой разработкой, отладкой и тестированием. Вдобавок, она высокопроизводительна, подходит для работы с кросс-платформенными приложениями и ориентирована на микросервисы. В то же время, остальные сервисы разрабатываются с помощью JVM-фреймворка, который, кстати, является прямым конкурентом продукту от Oracle.

Использование сразу двух популярных фреймворков позволяет выбирать из большего количества специалистов на рынке. Для .NET мы используем языки C, а для JVM − Kotlin и Java. Кроме того, эти же языки используются Android-разработчиками.

Функции Front-end команды

Команда Front-end специалистов следит за тем, чтобы приложение было удобным, а интерфейс − интуитивно-понятным и быстрым.

Android-версия приложения Crypterium основана на языках Java и Kotlin (как и среда JVM), а приложение iOS − на новом, простом в использовании языке программирования Swift. Функции языка включают в себя контроль доступа, управление памятью, отладку, цепочку вызовов и протокол-ориентированное программирование.

MVVM и роутинг для iOS

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

MVVM − это Model-View-ViewModel, где Model означает информацию о продукте, а View показывает, как клиенты видят продукт. В MVVM есть структура слоев: первый уровень − UI (пользовательский интерфейс). Другие уровни содержат сетевые и логические сервисы. Роутинг отвечает за технические процессы − действия пользователей, перемещения внутри приложения, регулируются именно им.

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

Чистая архитектура для Android

Чтобы повысить простоту обслуживания и гибкость приложений, команда Android решила использовать метод под названием «Чистая архитектура». Он гарантирует отсутствие ненужных связей и делает приложение более тестируемым.

Результатом является чистое, новое, свежее, простое в использовании приложение для Android с четырьмя уровнями:

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

Заключение

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

Если вам понравился материал о том, что такое архитектура приложения, посмотрите следующее:

Источник: Объясни это маме − что такое архитектура приложения on Hackernoon

proglib.io

Архитектура приложения малой кровью

Маленькая зарисовка на тему того, как разработать высокоуровневую архитектуру приложения. Предположим, что с будущей функциональностью Вы определились. Тогда Вы точно знаете, кто или что будет поставлять данные, кто/что будет их потреблять и какие преобразования данных должна выполнять сама система. Возьмите лист бумаги и карандаш. Если не сильно уверены в своих силах, то ещё и резинку, чтобы править схему. Более продвинутые читатели могут обратиться к профессиональным инструментам для проектирования архитектуры в электронном виде. Теперь выясните, кто будет обращаться к вашей системе, чтобы передать или забрать данные, а к чему будет обращаться Ваша программа. Те системы или пользователи, которые обращаются к программе сами, нарисуйте схематически на листе бумаги вверху. Те, к которым будет обращаться программа (включая БД), — снизу. Теперь нарисуйте под каждым нарисованным сверху субъектом прямоугольник с названием UI или API — это интерфейсы, к которым будет обращаться пользователь или внешняя управляющая система. Иногда UI тоже может обращаться к API. Объедините все прямоугольники с UI одним контуром и обзовите слоем представления. Объедините все прямоугольники с API и обзовите слоем сервисов. Для систем, нарисованных снизу, укажите компоненты, которые будут отвечать за доступ к этим системам. Объедините все эти компоненты одним контуром и обзовите слоем доступа к данным. Между слоем сервисов и слоем доступа к данным нарисуйте большой контур и назовите его слоем бизнес-логики. В маленьких прямоугольниках внутри этого контура перечислите основные бизнес-задачи. Один компонент Вашей системы будет решать одну бизнес-задачу. Теперь справа нарисуйте несколько длинных прямоугольников снизу доверху и напишите в них: журналирование, конфигурация, мониторинг производительности, обработка исключений и что-то ещё, что является общей инфраструктурой (или сквозной функциональностью) для всех слоёв вашей программы. Вы получили логическую архитектуру приложения. Разбросайте слои по серверам — получите физическую архитектуру. Теперь вам остаётся детально проработать каждый маленький квадратик. Маленький практический пример запрячу под кат. Для примера я возьму совершенно виртуальный проект системы контроля успеваемости для средней школы. Возьму её по двум причинам. Во-первых, все мы учились в школе. Во-вторых, у многих из нас дети сейчас учатся в той же школе. Из-за этого, надеюсь, предметная область будет всем понятна. Итак, наша система будет предназначена для ведения электронных дневников учащихся и электронных классных журналов. В довесок пусть система имеет некоторый дополнительный набор функций, позволяющий учащимся, родителям и преподавателям обмениваться сообщениями, а руководству школы — контролировать учебный процесс. Итак, пользователями нашей системы будут учащиеся, их родители, учителя и руководство школы. Кроме того, пользователями будут являться администраторы системы, которым важно получать информацию о событиях в системе и выполнять некоторые сервисные операции. Перечислять варианты использования не будем, не о них речь. Пользователи будут взаимодействовать с нашей системой либо посредством web-интерфейса, либо с помощью мобильного приложения. Оба пользовательских интерфейса предназначены для школ, которые не могут себе позволить разработку своего собственного сайта. Остальные смогут обращаться к нашей системе через web-сервисы. Сервисов будет четыре: электронный дневник, электронный журнал, организация учебного процесса и администрирование. Под слоем сервисов будет слой бизнес-логики, состоящий из десятка компонентов, решающих бизнес-задачи пользователей. Данные будут храниться в базе данных. Причём базы будет две: боевая и архивная. Система будет экспортировать/импортировать данные из файлов. Кроме того, будет две внешние системы, к которым наша система будет подключаться удалённо: система справочной информации и информационная система Департамента образования. Сквозную функциональность будут составлять механизмы журналирования, мониторинга, управления конфигурацией, обеспечения безопасности. В итоге, получаем вот такую простую схему:

Теперь можно выделить физические узлы. Web-интерфейс пользователя и сервисы будут развёрнуты в web-кластере. Слои бизнес-логики и доступа к данным будут реализованы на сервере приложений. Базы данных разместятся в отдельном отказоустойчивом кластере. Позже можно будет все узлы изобразить в виде красивой схемы физической архитектуры. Надеюсь, пример понятен.

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

Теги:
  • архитектура
  • проектирование

habr.com

Архитектура ИТ решений. Часть 1. Архитектура предприятия

Архитектура распределяет массы и объемы. Вдохновение превращает инертный камень в драму.

Ле Корбюзье.

Недавно столкнулся со следующей ситуацией, одна крупная ИТ компания подбирала для себя архитектора, с целью доработки компьютерной платформы «собственного исполнения». Такая работа, естественно, требовала привлечения специалиста высокой квалификации. А как это сделать дешево и сердито, чтобы призванный варяг был «и чтец и жнец и на дуде игрец»? Решили без всяких излишеств разработчика ПО, поименовать архитектором, и заполучить помимо кодировщика, еще и профессионала, способного разобраться с чужими решениями, до проектировать их на свое усмотрение, принимать самостоятельные решения и т.п… Когда стали выяснять, а как же в организации вообще обстоит дело с архитектурой, обозначились следующие тенденции. Есть ряд высококвалифицированных разработчиков, позиционируемых как архитекторы. Помимо непосредственно создания кода, они выполняют достаточно низкоуровневое проектирование различных технологических систем и задают вектор и горизонт их развития. Решения представлены ими в основном в виде текстовых описаний, разбавленных небольшим количеством схем, в основном производных от диаграмм компонентов. Каждый из архитекторов представляется уникальным и эксклюзивным носителем знаний, а по сути — является узким местом в процессе производства программных продуктов. Ведь на практике без его постоянных уточняющих консультаций, воспользоваться результатом евонной деятельности практически невозможно. Полная, логически выстроенная, структурированная картинка сложного решения есть лишь в его голове. И документации вроде бы много, но она разрознена по репозиториям проектов, Вики системам и т.п. Найти логически целостное описание решения и рекомендации по его использованию крайне сложно, а уж проследить ответвляющиеся частные технические решения по цепочке: от потребностей пользователя, до конечной поставки заказчику, вообще не реально, И это несмотря на то, что для заказчика обычно готовится некая версия на базе типового продукта, доработанного в соответствии с его специфическими потребностями. А ведь иногда бывает так необходимо отследить, например, с кем связан компонент, который предполагается использовать при проектировании нового модуля. С кем он, так сказать, разделен шестью рукопожатиями, и какое пагубное влияние могут оказать все эти неучтенные связи на стабильность его поведения. Подобная ситуация царит во многих крупных ИТ компаниях. Вроде есть архитекторы и архитектурные советы и прочие атрибуты «высокой» архитектуры, а порядка в этом царстве не наблюдается. По вышеперечисленным симптомам, выходит, что на предприятии свирепствует – «острая архитектурная недостаточность». Мне стало интересно разобраться со всеми аспектами архитектуры, собрав в данной статье структурированно и последовательно информацию о том, что же такое ИТ архитектура, кто такие ИТ архитекторы, и «с чем их едят».

II. Определение понятия «архитектура»

А что можно думать об архитектуре? Она, как солнце: большая, блестящая и она рядом.

Роджер Желязны. (Мастер сновидений)

Давайте для начала пройдемся по определениям. Архитектура системы — принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию. Очень скупая формулировка и развернуть ее, проиллюстрировав в полной мере смысл, сложно. Поэтому постараемся сузить проблематику и оттолкнемся от чего-то меньшего, например, составной части этой системы: Архитектура программного обеспечения (англ. software architecture) — совокупность важнейших решений об организации программной системы. Архитектура включает:
  • выбор структурных элементов и их интерфейсов, с помощью которых составлена система, а также их поведения в рамках сотрудничества структурных элементов;
  • соединение выбранных элементов структуры и поведения, во всё более крупные системы;
  • архитектурный стиль, который направляет всю организацию — все элементы, их интерфейсы, их сотрудничество и их соединение (1)
Довольно лаконичное определение, дополнив которое можно приблизится к пониманию, что же принято ассоциировать с явлением — ИТ Архитектура. Во-первых, это специально подобранный, набор структурных элементов, организованных определенными способами для взаимодействия друг с другом, складывающихся в единый программно-аппаратный комплекс. Я бы еще добавил: выстроенный в угоду достижения определенных бизнес целей. Во-вторых, место «совокупности этих элементов», как части, в более крупных системах, включая поведение, точки взаимодействия и т.п. То есть возможность абстрагирования рассматриваемой архитектуры на более высокий уровень, и соответственно детализация архитектуры в наборы составных архитектур нижнего уровня. В-третьих, использование всеми участниками — единого подхода для организации решений в процессе производства информационных систем. Раз уж речь зашла о едином подходе, давайте внесем ясность и в этот вопрос:Архитектурный подход (англ. architectural framework) — соглашения, принципы и практики для описания архитектуры, установленные для конкретной области применения и/или конкретным сообществом заинтересованных лиц (2). Ведь в ходе проектирования, разработки, развития и модернизации программной системы, «совокупность решений о ее организации» (Архитектура), требует постоянного обсуждения со всеми заинтересованными лицами проекта, включая бизнес. Опять же принципиально, чтобы все при этом выстраивали перед собой одну и туже картинку, в том числе учитывающую текущее актуальное состояние архитектуры.

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

1. Разделы ИТ Архитекторы

Поскольку понятие ИТ архитектуры охватывает целый букет аспектов производства программных продуктов, начиная еще от определения целей автоматизации и заканчивая аж утилизацией устаревшего в какой-то момент ПО, принято делить его на несколько частей: 1) Информационная архитектура (Enterprise Information Architecture, сокр. EIA), набор методик и инструментов, описывающий информационную модель предприятия. Включает:
  • базы данных и хранилища данных;
  • информационные потоки (как внутри организации, так и связи с внешним миром).
2) Архитектура прикладных решений (Enterprise Solution Architecture сокр. ESA) – представляет архитектуру приложений, включающую в себя совокупность программных продуктов и интерфейсов между ними. Делится на два направления:
  • область разработки прикладных систем;
  • портфель прикладных систем.
3) Техническая архитектура (Enterprise Technical Architecture сокр. ETA) — совокупность программно-аппаратных средств, методов и стандартов, обеспечивающих эффективное функционирование приложений. Описывает полное представление инфраструктуры предприятия, включая:
  • информацию об инфраструктуре предприятия;
  • системное программное обеспечение (СУБД, системы интеграции);
  • стандарты на программно-аппаратные средства;
  • средства обеспечения безопасности (программно-аппаратные);
  • системы управления инфраструктурой.
Плюс к этому добавляется и архитектура самого предмета автоматизации: 4) Бизнес-архитектура предприятия (Enterprise Business Architecture, ЕВА) — целевое построение организационной структуры предприятия, увязанное с его миссией, стратегией, бизнес-целями. В ходе построения бизнес-архитектуры определяются необходимые бизнес-процессы, информационные и материальные потоки, а также организационно-штатная структура. Соответственно для работы с каждым из вышеперечисленных разделов, требуется своя группа заинтересованных лиц, имеющих различную квалификацию и предпочтения, а возможно и цели. Поэтому многочисленные этапы ведения проекта порождают артефакты, описывающие аспекты архитектуры в разных стилях и жанрах. В добавок, они создаются чаще всего разнородными инструментами, используя разнообразные нотации, приемы, представления и т.п. Стало быть, каждому разделу архитектуры соответствует как минимум одна группа стейкхолдеров, имеющая свои взгляды на представления и методы описания архитектуры. Подыщем определение для этой реалии. Архитектурная группа описаний (англ. architectural view) — представление системы в целом с точки зрения связанного набора интересов. Каждая группа описаний относится к одному или более стейкхолдеру. Термин «группа описаний» употребляется для выражения архитектуры системы при некотором методе описания (2).Разобравшись вкратце с концепцией, направлениями и разделами архитектуры, а также выявив несовпадения в представлениях архитектуры разными группами заинтересованных лиц, перейдем к разбору непосредственно самих этих представлений (артефактов), отражающих архитектуру.

2. Представления ИТ Архитекторы

Нередко наблюдаю ситуации, когда очень интересные и перспективные замыслы гинут в болоте непонимания, только лишь из-за оторванности генератора идеи от общего уровня сознания профсообщества. Иными словами, он пытается донести концепцию, которая в его мыслях сложена в цельную и стройную идею, выдавая окружающим лишь ее “огрызки”: «ну ведь остальное и так понятно». А это «остальное» действительно не всегда понятно для электората, и он голосует против бредовой и непонятной с его точки зрения идеи, своим равнодушием и игнорированием. Автор же задумки зачастую просто не смекает, почему же все пошло не так, и отчего никто не проникся чудо решением. По всей вероятности нужна была какая-то подводка. А очень может быть, сначала надо было открыть людям целый новый мир, и только потом, в его свете, доносить эту свою идею. Это сродни тому, как иностранцу, не владеющему твоим родным языком, объяснять на нем теорию относительности Эйнштейна. Особенно если ты ее сам как-то не очень… Очевидно, что и для эффективного представления архитектурных решений всем заинтересованным лицам, требуется некий способ, позволяющий доступно, но достаточно развернуто донести их суть до максимально широкого круга лиц. Таким способом может служить принятый в организации стандарт — Архитектурное описание и соответствующие методы их поддержания. Для более точного осмысления этого явления, пустим в ход и их определение: Архитектурное описание (англ. architectural description) — рабочий продукт, использующийся для выражения архитектуры (2). Архитектурный метод описания (англ. architectural viewpoint) — спецификация соглашений для конструирования и применения группы описаний. Шаблон или образец, по которому разрабатываются отдельные группы описаний посредством установления назначений и аудитории для группы описаний, а также приемы их создания и анализа. Метод описания устанавливает соглашения, по которым группа описаний создается, отображается и анализируется. Тем самым метод описания определяет языки (включая нотации, описания или типы продуктов), применяемые для определения группы описаний, а также все связанные методы моделирования или приемы анализа, применяемые к данным представлениям группы описаний. Данные языки и приемы применяются для получения результатов, имеющих отношение к адресуемым интересам (2).Тем самым, выделенные архитектурные группы, используя единые архитектурные методы описания, значительно повышают эффективность своей работы, достигая максимально согласованного и целостного восприятия обсуждаемых проблем. Но можно ли загнать специалистов разных направлений, имеющих разную квалификацию, а возможно и образ мышления, в единые рамки, и действительно ли это так необходимо? Например, диаграмма, описывающая формирование целей и показателей на основании выявления стекхолдеров, вызовов и их проблематики см. рис.1, по своей природе очень сильно отличается от диаграмм со схемой прокладки сети, а также диаграмм в нотации UML и прочих.

Рисунок 1. Модель выработки целей и показателей На практике использование разнородных артефактов является большой проблемой, поскольку теряется возможность сквозной трассировки архитектурных решений от целей и стратегий к потребностям, далее к описанию бизнес-процессов и функций системы, от них к структуре данных и поведенческим моделям, от моделей к макетам экранов и т.д. по цепочке. Ведь создают все эти артефакты специалисты разных архитектурных групп, которые формировались сами по себе, подбирая годами под себя оптимальные инструменты и методики. Фиксируя все эти разнообразные описания и представления, возникает резонный вопрос: Как же их объединить в некий всеобъемлющий контекст? Например, для разработки больших информационных систем еще в конце прошлого века использовали модель Закмана (3), в качестве схемы организации архитектурных артефактов. Модель Закмана основана на дисциплине классической архитектуры и призвана обеспечить общее толкование архитектурных аспектов и предоставить набор перспектив, или структур (framework), для описания сложных корпоративных систем. Сама модель представляется в виде матрицы — таблицы, имеющей пять строк и шесть столбцов, см. рис. 2. Каждая ячейка таблицы – презентует набор артефактов, раскрывающих один из насущных аспектов архитектуры.

Рисунок 2. Представление модели Закмана Примечательно, что основная идея матрицы помимо того, чтобы вынудить заполнить все ячейки, не пропустив важные характеристики системы, состоит и в определении последовательности заполнения. Ведь только заполнив одни ячейки, открывается возможность на основании их заполнить следующие, пока пазлы не сложатся в цельную картинку. Таким образом, различные по своему представлению архитектурные описания ложатся в разные ячейки матрицы и ею же увязываются в единое архитектурное полотно. Стоит отметить, что на рисунке шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом. Модель Закмана со временем дорабатывалась и послужила прародителем для многих архитектурных каркасов и спецификаций. Одной из таких актуальных спецификаций является например, графический язык ArchiMate, содержащий набор понятий для описания архитектуры предприятия и фреймворк, представляющий логическую структуру для классификации этой информации Последняя версия стандарта 3.0 вышла в июне 2016 года. В ArchiMate, при создании моделей, используются базовые понятия «элемент» и «отношение» см. рис.3. На основе элементов и отношений строятся модели предприятия или его отдельных частей.

Рисунок 3. Основные понятия ArchiMate 3.0 Вся прелесть подхода состоит в том, что элементами могут быть проекции самых разнообразных реальных сущностей и явлений, встречающихся в жизни. Например, мотивационные элементы (стейкхолдеры, драйвер мотивации, цель, результат, ценность и т.д.), элементы организации и поведения (исполнители, роли, процессы, функции, события, взаимодействие и т.д.), бизнес элементы (информационный актив, соглашение, продукт/услуга, компонент приложения, интерфейс приложения, автоматизируемая функция и т.д.), технологические элементы (узел/ресурс, устройство, коммуникационная сеть, технологический процесс и т.д.). Каждый вид элемента представлен на диаграммах своим уникальным обозначением. Таким образом в одном информационном пространстве могут сочетаться столь разные отражения сущностей, явлений, событий, действий и т.д., образующих архитектуру предприятия. Сами модели располагают в одной из ячеек каркаса на пересечении Слоя (уровень представления) и Аспекта. Схематично структура фреймворка представлена на рис. 4.

Рисунок 4. Слои фреймворка ArchiMate 3.0 В качестве Слоев рассматриваются конструктивные субсистемы предприятия, образующие некое самодостаточное представление (срез) организации. А Аспекты в свою очередь относят элементы, к одному из трех основных типов: 1) Активный структурный элемент (active structure element) позиционирует его, как некую сущность, которая способна выполнять определенные действия 2) Пассивный структурный элемент (passive structure element) позиционирует его, как некоторый объект, над котором выполняются действия. 3) Элемент поведения (behavior element) определяется как некоторая единица действия, выполняемая одним или несколькими активными структурными элементами. Более подробно ознакомится со спецификацией можно в обзоре ArchiMate (4). Такого рода инструменты позволяют объединить в единое информационное пространство разнородные аспекты архитектуры, используя унифицированное архитектурное описание и методы, обеспечивая трассировку между диаграммами и элементами. Погрузившись во все эту «карусель» сложностей и разнообразия возникает один немаловажный вопрос: А всегда ли необходимо выполнять такой сложный и ресурсоемкий процесс описания архитектуры? На самом деле существует несколько подходов к ее построению, например: 1) Стандартный подход, заключается в разработке или выборе на начальном этапе общей схемы и правил для описания архитектуры. На основании выработанных стандартов, описывается базовая (текущая) архитектура, и отталкиваясь от нее, проектируется целевая (новая). Определив разницу, формируют мероприятия по переходу от базовой архитектуры к целевой. Только после этого начинается конструирование, приобретение и разработка компонентов системы. В качестве недостатков, можно выделить: существенные начальные инвестиций, как финансовые, так и временные. Также этот подход может привести к тому, что называется «паралич из-за анализа». 2) Подход «статус-кво». Разработка рассматривается как реакция на те или иные возникающие затруднения или воздействия. 3) Сегментный подход, опирается на модель разработки сегментов архитектуры в рамках общей структурированной схемы. Он сосредотачивается на главных областях бизнеса. Позволяет сократить возможные риски, обеспечить снижение начальных затрат и добиться быстрой отдачи от проекта. Могут возникнуть проблемы на этапе интеграции сегментов.

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

Итак сделаем краткую выжимку из рассмотренного нами материала:
  1. Архитектура предприятия связывает бизнес-потребности предприятия, информационные технологии, процессы стратегического бизнес-планирования, прикладные информационные системы и процессы их сопровождения.
  2. В процессе разработки и поддержания архитектуры предприятия участвуют разные группы заинтересованных лиц, имеющие различные требования к ее представлениям (архитектурный подход);
  3. Для удобства, архитектуру принято делить на разделы, соответствующие разным архитектурным зонам и подходам;
  4. Для разных архитектурных групп и подходов существуют различные группы описания (визуализации) архитектуры.
  5. Для удобства организации работы с разнородными артефактами используют архитектурные методы описания, представляющие собой специальные фреймворки и спецификации, и позволяющие работать со всеми артефактами в едином визуальном пространстве. Использование подобных конструкций помогает с одной стороны, логически разбить все представления архитектуры на отдельные разделы для упрощения их формирования и восприятия, а с другой – обеспечить возможность рассмотрения целостной архитектуры с изолированных точек зрения или соответствующих уровней абстракции.
  6. В зависимости от потребностей и возможностей предприятия, можно выбрать один из нескольких архитектурных подходов, различающихся по объему и составу выполняемых работ, что в свою очередь определяет уровень затрат и качество проектирования.

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

Об авторских тренингах на тему: «Архитектура ИТ решений» подробнее можно узнать на сайте компании ООО ИЦ Таврида

Теги:
  • архитектура системы
  • проектирование систем
  • архитектура приложений
  • архитектор

habr.com

1. Определение понятия архитектуры ПО

Министерство образования Республики Беларусь Учреждение образования

«Белорусский государственный университет информатики и радиоэлектроники»

Кафедра информатики

А.А. Волосевич

АРХИТЕКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Курс лекций для студентов специальности

1-40 01 03 Информатика и технологии программирования

Содержание

1.

Определение понятия архитектуры ПО....................................................

3

2.

Клиент-серверная модель.........................................................................

4

3.

Компонентная архитектура ......................................................................

5

4.

Многоуровневая архитектура...................................................................

5

5.

Шина сообщений......................................................................................

8

6.

Многозвенная архитектура.......................................................................

9

7.

Объектно-ориентированная архитектура ................................................

10

8.

Выделенное представление .....................................................................

11

9.

Архитектура, ориентированная на сервисы ............................................

12

Литература ..................................................................................................

13

Архитектура программного обеспечения (software architecture) – это пред-

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

Набор принципов, используемых в архитектуре, формирует архитектурный стиль (software architecture style). Применение архитектурного стиля сродни употреблению шаблона проектирования, но не на уровне компонента (модуля или класса), а на уровне всей создаваемой системы ПО. Как и шаблоны проектирования, архитектурные стили упрощают коммуникацию разработчиков и предлагают готовые решения целого класса абстрактных проблем. В таблице 1 представлено короткое описание основных архитектурных стилей.

Таблица 1

Основные архитектурные стили

Архитектурный стиль

Описание

Разделение системы на два приложения – клиент и сер-

Клиент-серверная модель

вер. При работе клиент посылает запросы на обслужива-

ние серверу

Деление системы на компоненты, которые могут быть

Компонентная архитектура

повторно использованы и не зависят друг от друга. Каж-

дый компонент снабжается известным интерфейсом для

коммуникаций

Многоуровневая архитектура

Разделение функций приложения на группы (уровни), ко-

торые организованы в виде стекового набора

Система, которая может посылать и передавать информа-

ционные сообщения в определённом формате по общему

Шина сообщений

коммуникационному каналу. Благодаря этому организу-

ется взаимодействие систем без указаний конкретных по-

лучателей сообщений

Разделение функций подобно многоуровневой архитек-

Многозвенная архитектура

туре, но группировка происходит не только на логиче-

ском, а и на физическом уровне – отдельным группам со-

ответствует отдельный компьютер (сервер, кластер)

Объектно-ориентированная

Представление системы в виде набора взаимодействую-

архитектура

щих объектов

Выделенное представление

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

модействия с пользователями и обработки данных

Архитектура, ориентирован-

Каждый компонент системы представлен в виде незави-

симого сервиса, предоставляющего свои функции по

ная на сервисы

стандартному протоколу

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

2. Клиент-серверная модель

Клиент-серверная модель (client-server model) описывает отношение между двумя компьютерными программами, в котором одна программа – клиент – выполняет запросы к другой программе – серверу. Эта модель решает, в основном, задачу развёртывания приложения. С использованием клиент-серверной модели созданы многие приложения для работы с базами данных, электронной почтой и для доступа к веб-ресурсам.

Перечислим основные принципы данного архитектурного стиля:

1.Клиент инициирует один или несколько запросов, ожидает ответа на них,

азатем обрабатывает ответы.

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

3.Клиент работает с пользователем напрямую, применяя графический ин-

терфейс.

4.Сервер не инициирует запросов.

5.Обычно для выполнения запросов клиенты проходят аутентификацию на сервере.

Главными преимуществами клиент-серверной модели являются:

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

–Централизованный доступ к данным. Так как данные хранятся только

на сервере, ими легко управлять (например, обеспечить обновление).

– Устойчивость и лёгкость сопровождения. Роль сервера могут выпол-

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

Рассмотрим некоторые варианты клиент-серверной модели. В системахкли-

ент-очередь-клиент (client-queue-client или passive queue) сервер исполняет роль очереди для данных клиентов. То есть, клиенты использую сервер только для обмена данными между собой. Пиринговые приложения (peer-to-peer application) – это вариация системы клиент-очередь-клиент, в которой любой клиент может играть роль сервера. Сервера приложений (application server) служат для размещения и выполнения программ, которыми управляет клиент.

Ключевым понятием компонентной архитектуры является компонент

(component). Это программный объект, спроектированный так, чтобы удовлетворять следующим требованиям:

1.Компонент допускает повторное использование в различных системах.

2.Компонент не хранит информации, специфичной для конкретного ПО, в котором он используется.

3.Допускается создание новых компонентов на основе существующих.

4.Компонент имеет известный интерфейс для взаимодействия, но скрывает

детали своей внутренней реализации.

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

Типичным примером компонентов являются элементы пользовательского интерфейса (элементы управления).

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

–Лёгкость развёртывания. Когда для компонента доступна новая версия, старая версия заменяется без влияния на остальные компоненты.

–Уменьшение стоимости. При разработке можно применять готовыеком-

поненты сторонних производителей.

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

–Уменьшение технической сложности. Обычно компоненты, составляю-

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

4. Многоуровневая архитектура

Многоуровневая архитектура (multilayered architecture) сосредоточена на иерархическом распределении отдельных частей системы при помощи эффективного разделения отношений. Каждая часть соотносится с определённым уровнем (layer), для каждого уровня заданы выполняемые им функции, уровни выстроены в стековую структуру (то есть находятся один поверх другого). Например, типичная многоуровневая архитектура веб-приложения включает уровень представления (компоненты пользовательского интерфейса), уровень бизнес-ло- гики (обработка данных) и уровень доступа к данным. При этом уровень представления считается высшим, за ним идёт уровень бизнес-логики, а за уровнем бизнес-логики – уровень доступа к данным.

Сформулируем основные принципы многоуровневой архитектуры:

1.Проектирование чётко устанавливает разграничение функций между уровнями.

2.Нижние уровни независимы от верхних уровней.

3. Верхние уровни вызывают функции нижних уровней, но при этом взаимодействуют только соседние уровни иерархии.

Использование многоуровневой архитектуры обеспечивает следующиепреимущества:

–Изоляция. Разработка и обновление ПО могут быть изолированы рамками одного уровня.

–Производительность. Распределение уровней на отдельные физические

компьютеры повышает производительность и отказоустойчивость.

– Тестируемость. Уровни допускают независимое тестирование. Многоуровневая архитектура активно применяется при создании бизнес -

приложений и сайтов, особенно приложений масштаба предприятия. При этом обычно используется следующий набор уровней (рис. 1):

Уровень представления (presentation layer) ответственен за взаимодействие с пользователем, ввод и вывод информации.

Бизнес-уровень или уровень бизнес-логики (business logic layer) обрабатывает информацию, реализуя конкретные бизнес-правила.

Уровень доступа к данным (data access layer) обеспечивает загрузку и сохранение информации, используя источник данных (файл, база данных) или внешний сервис.

Пользователи

Внешние

вызывающие

сервисы

Уровень

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

Бизнес-уровень

Рис. 1. Типичные уровни бизнес-приложения.

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

1 См. также статью http://msdn.microsoft.com/en-us/library/ff648105.aspx.

Пользователи

Компоненты пользовательского интерфейса

Компоненты сценариев

Интерфейсы сервисов

Рабочие

Бизнес-

Бизнес-

потоки

компоненты

сущности

Компоненты,

отвечающие за доступ

Агенты сервисов

к данным

Источники данных

Сервисы

Безопасность

Управление транзакциями

Связь

Рис. 2. Компоненты отдельных уровней.

1. Компоненты пользовательского интерфейса (UI Components). Они пред-

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

2. Компоненты сценариев (UI Process Components). Обычно система подчи-

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

3. Рабочие потоки (Business Workflows). После получения данных от пользователя они должны быть использованы при выполнении бизнес-процессов (рабочих потоков). Бизнес-процессы состоят из шагов, которые должны быть выполнены в определённом порядке. Например, система должна подсчитать общую сумму заказа, проверить данные кредитной карты и организовать доставку товара. При этом заранее неизвестно, сколько времени потребуется на выполнение этих шагов. Поэтому нужен механизм управления этими операциями.

studfiles.net

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

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

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

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

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

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

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

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

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

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

Повышение эффективности 1Т-подразделений. Этот результат достигается за счет автоматизации различных процессов.

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

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

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

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

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

Пример 5.1. Рассмотрим цели, которые должны быть учтены при создании архитектуры ПО для интернет-магазина по продаже сотовых телефонов:

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

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

Общей техникой постепенной доработки архитектуры является итеративная методика (пока не будут удовлетворены все требования и ограничения), включающая пять основных этапов (рис. 5.1).

  • 1. Определение целей архитектуры. Наличие четких целей поможет сосредоточиться на архитектуре и правильном отборе проблем для решения. Точно обозначенные цели помогают определить границы каждой фазы, т.е. момент, когда завершена текущая фаза и все готово для перехода к следующей.
  • 2. Выявление основных сценариев. Необходимо использовать основные (ключевые) сценарии, чтобы сосредоточиться на том, что имеет первостепенное значение, и проверить возможные варианты архитектур на соответствие этим сценариям.
  • 3. Создание прототипа приложения. Необходимо определить тип приложения, архитектуру развертывания, архитектурные стили и технологии, чтобы обеспечить соответствие дизайна реальным условиям, в которых будет функционировать создаваемое приложение.
  • 4. Выявление потенциальных проблем. Необходимо установить основные проблемные области на основании параметров качества и потребности в сквозной функциональности. Это области, в которых чаще всего делаются ошибки при проектировании приложения.

1. Определение целей архитектуры

\_____/

Рис. 5.1. Процесс создания архитектуры ПО

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

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

Определение целей архитектуры. Цели архитектуры — это задачи и ограничения, очерчивающие архитектуру и процесс проектирования ПС, определяющие объем работ и помогающие понять, когда, собственно, пора завершить процесс доработки (см. рис. 5.1). К ключевым моментам при определении целей архитектуры относятся следующие.

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

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

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

Пример 5.2. Рассмотрим процесс определения целей архитектуры при разработке интернет-магазина по продаже сотовых телефонов:

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

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

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

Диаграмма вариантов использования (рис. 5.2) состоит из следующих элементов: «актеров», для которых система производит действие (актер обозначается значком человечка); «действий», которые актеры хотят получить от системы (действие обозначается овалом); «комментариев» (отображаются в виде прямоугольников и соединяются с комментируемым элементом линией); «использования действий» (обозначается в виде стрелок, которые направлены от актера к действию, над стрелкой указывается ключевое слово «uses»); «расширения действий» или дополнительных действий (показывается в виде стрелки от действия-расширения к действию, которое оно расширяет, над стрелкой указывается ключевое слово «extends»; если одно действие включается в другое, то используется ключевое слово

Интернет-магазин по продаже сотовых телефонов

Рис. 5.2. Диаграмма вариантов использования для интернет-магазина

по продаже сотовых телефонов

Любой

пользователь сети

Заре ги сгр ирован н ы й пользователь

Только менеджер может изменять статус заказа

«include»). Диаграмма используется при проектировании архитектуры приложения.

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

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

Консольные приложения. Консоль подразумевает отображение только текстовых данных. Одним из представителей подобного приложения можно назвать файловый менеджер FAR, который является «наследником» аналогичных программ, используемых в операционной системе DOS.

Классические desktop-приложения. Такие приложения также называют «оконными». В них используется графический интерфейс и ввод информации осуществляется при помощи клавиатуры и мыши. Данные приложения позволяют создавать практически любые по сложности решения. Основным минусом является сложность обновления приложений у конечных пользователей.

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

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

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

Пример 5.4. Для создания интернет-магазина по продаже сотовых телефонов должно использоваться Web-приложение; и это решение, как правило, является требованием заказчика к разрабатываемому программному продукту.

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

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

Ограничения по программным требованиям. Например, использование конкретной операционной системы.

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

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

Пример 5.5. Для рассмотренного ранее интернет-магазина следует ввести следующие ограничения развертывания, заданные заказчиком: Web-сервер должен находиться на одном физическом сервере с базой данных, где будет храниться информация по заказам; необходимо использовать сервер на базе операционной системы Linux или Unix.

Page 2

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

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

Сочетание архитектурных стилей крайне полезно при построении УеЬ-приложений, где можно достичь эффективного разделения функциональности за счет применения многослойного архитектурного стиля. Таким образом, можно отделить логику представления от бизнес-логики и логики доступа к данным. Требования безопасности организации могут обусловливать либо 3-уровневое развертывание приложения, либо развертывание более чем с тремя уровнями. Уровень представления может развертываться в пограничной сети, располагающейся между внутренней сетью организации и внешней сетью. В качестве модели взаимодействия на уровне представления может применяться шаблон представления с отделением (разновидность многослойного стиля), такой как Мос1е1-йеу-Соп1:го11ег (МУС). Также можно выбрать архитектурный стиль 80А и реализовать связь между УеЬ-сервером и сервером приложений посредством обмена сообщениями.

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

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

Типовые архитектурные стили

Архитектурный стиль (парадигма)

Описание

Клиент-серверная

архитектура

Система разделяется на клиентскую и серверную части, где клиент посылает запросы к серверу. Во многих случаях в роли сервера выступает сервер БД, а логика приложения представлена процедурами

хранения

Компонентная архитектура

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

Проблемно-ориентированное проектирование (дизайн на основе предметной области)

Объектно-ориентированный стиль, ориентированный на моделирование сферы деловой активности и определяющий бизнес-объекты на основании сущностей данной предметной области

Многослойная архитектура

Функциональные области приложения разделяются на многослойные группы (уровни)

Архитектура на основе канала сообщений

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

/У-уровневая/З-уровневая

архитектура

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

Объектно-ориентированная

архитектура

Парадигма проектирования, основанная на распределении ответственности приложения (системы) между отдельными, многократно используемыми и самостоятельными объектами, содержащими данные и правила поведения

Сервисно-ориентированная архитектура (БОА)

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

Рис. 5.3. Архитектурный стиль «Клиент—сервер»

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

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

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

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

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

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

Рис. 5.4. Пример использования компонентов в интерфейсе пользователя

Данный архитектурный стиль обладает следующими преимуществами:

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

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

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

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

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

Преимущества данного архитектурного стиля состоят в следующем:

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

Рис. 5.5. Модель предметной области «Финансовые документы»

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

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

Многослойная архитектура. Данная архитектура обеспечивает группировку связной функциональности приложения в разных слоях, выстраиваемых вертикально, «поверх» друг друга. Функциональность каждого слоя объединена общей ролью или ответственностью. Слои слабо связаны, и между ними осуществляется явный обмен данными. Правильное разделение приложения на слои помогает поддерживать строгое разделение функциональности, что, в свою очередь, обеспечивает гибкость, а также удобство и простоту обслуживания.

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

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

На рис. 5.6 представлен пример трехслойной архитектуры приложения, где в качестве слоя данных (хранения информации) может выступать БД, модуль по хранению и чтению данных с диска. Этот слой может располагаться и на отдельном сервере (выделенный файл-сервер, сервер БД), и совместно с другим слоем (например, простое УеЬ-приложение, где сервер и БД располагаются на одном компьютере). Для УеЬ-приложений под слой логики (обработки информации) можно выделить УеЬ-сервер либо, для более сложных проектов, сервер приложений, а в качестве слоя представления (отображения информации) выступает браузер, где пользователь просматривает информацию.

Слой представления (отображения информации)

^

Слой логики (обработки информации)

Xх_X

V_Xх

Слой данных (хранения информации)

Рис. 5.6. Пример трехслойной архитектуры

К преимуществам данного архитектурного стиля можно отнести следующие его характеристики:

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

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

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

На рис. 5.7 приведен пример работы с шиной данных, где часть клиентов работает через УеЬ-сервер с корпоративными сервисами (каждый из которых установлен на отдельный сервер): получение данных из базы данных, работа с почтой, работа с файлами. Доступ к сервисам напрямую имеют клиенты, которые, например, подключены к корпоративной сети компании. Весь обмен информации производится через шину данных. Программы отсылают в ней запросы, шина данных определяет получателя (сервер/сервис), к которому адресован запрос, и направляет его к нему, а затем возвращает результат отправителю. Следует отметить, что в настоящее время существует

Рис. 5.7. Архитектурный стиль с использованием шины данных

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

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

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

Характеристиками /V-уровневой архитектуры являются функциональная декомпозиция приложения, сервисные компоненты и их распределенное развертывание, что обеспечивает высокую масштабируемость, доступность, управляемость и эффективность использования ресурсов. Каждый уровень абсолютно независим от всех остальных, кроме тех, с которыми он непосредственно соседствует: п-му уровню требуется лишь знать, как обрабатывать запрос от (п + 1 )-го уровня, как передавать этот запрос на (п - 1)-й уровень (если таковой имеется) и как обрабатывать результаты запроса. Связь между уровнями, как правило, асинхронная для обеспечения более высокой масштабируемости.

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

Данный архитектурный стиль обладает рядом преимуществ:

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

Рис. 5.8. Пример трехуровневой архитектуры

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

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

Основными принципами объектно-ориентированного архитектурного стиля являются: абстракция, композиция, наследование, инкапсуляция, полиморфизм, отделение.

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

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

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

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

Полиморфизм. Позволяет для конкретных объектов переопределять поведение базового типа (поддерживающее основные операции в приложении) путем реализации в них новых взаимозаменяемых типов.

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

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

Обычно объектная модель представляется в виде диаграммы классов. На рис. 5.9 приведен упрощенный пример такой диаграммы, где изображены три класса, причем классы «Teacher» и «Student» наследуют свое поведение и данные от класса «Persona».

К преимуществам данного архитектурного стиля относят:

  • • понятность — обеспечивается более близкое соответствие приложения реальным объектам, что и делает его более понятным;
  • • возможность повторного использования — реализуется через полиморфизм и абстракцию;
  • • тестируемость — улучшение тестируемости обеспечивается через инкапсуляцию;

Рис. 5.9. Пример диаграммы классов

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

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

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

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

Основные принципы данного архитектурного стиля:

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

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

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

Преимущества данного архитектурного стиля:

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

Рис. 5.10. Пример обмена информацией для сервис-ориентированных систем

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

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

Page 3

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

Любая система может рассматриваться с разных точек зрения: поведенческой (динамической); структурной (статической); логической (соответствие функциональным требованиям); физической (распределенность, локальность); реализации (как детали архитектуры представляются в коде) и т.п. В результате получаются различные архитектурные представления (View). Архитектурное представление может быть определено как частные аспекты программной архитектуры, рассматривающие специфические свойства программной системы. В свою очередь, дизайн системы — комплекс архитектурных представлений, достаточный для реализации системы и удовлетворения предъявляемых к ней требований. Для изображения большинства видов дизайна систем используются UML-диаграммы. Рассмотрим основные виды (точки зрения) представления архитектуры приложений и диаграммы, которые можно использовать при их проектировании.

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

Рис. 5.11. Пример функционального вида архитектуры приложения

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

Клиенты

Рис. 5.12. Пример физического вида архитектуры

?

а

?

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

начальное состояние: конечное состояние: состояние-действие: условие:

параллельное выполнение:

Начальное состояние может быть только одним, это начало диаграммы. Конечное состояние может быть только одним, на нем заканчивается диаграмма. Состояние-действие определяет любое возможное в данном состоянии действие (внутри данного блока пишется производимое действие). Условие позволяет изменять ход выполнение диаграммы по различным причинам; причины ветвления пишутся над линиями, исходящими из блока. Допускается параллельное выполнение процессов: либо в блок входит одна стрелка, а выходит несколько, каждая из которых означает начало параллельного выполнения процессов, либо в блок входит несколько стрелок, а выходит одна, что означает окончание параллельного выполнения процессов. Область построения диаграммы может разделяться вертикальными линиями; прямоугольник, который они образуют, выделяется как отдельная подсистема или пользователь, их названия пишутся в верхней части прямоугольника.

На рис. 5.13 показана диаграмма активности запроса клиентом списка товаров интернет-магазина. Клиент запрашивает список товаров. Если УеЬ-сервер недоступен, то он может либо еще раз запросить список товаров, либо отказаться от просмотра страницы. Если УеЬ-сервер доступен, то он параллельно делает запрос данных из БД и информирует браузер клиента о том, что данные запрошены. Здесь целесообразно применение «асинхронного агента» для показа того, что ожидаются данные клиенту. Если время получения запрошенной информации будет большим, то клиент будет видеть, что его запрос обрабатывается. После получения данных УеЬ-сервер формирует НТМЬ-страницу и отправляет ее браузеру клиента. Браузер клиента отображает полученную страницу.

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

Рис. 5.13. Пример диаграммы активности

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

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

Главное окно приложения

Товары

Войти в личный кабинет

Наименование телефона

Краткое описание

Рис. 5.14. Пример интерфейса пользователя

Page 4

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

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

  • • применимые к run-time, т.е. ко времени выполнения системы; например, среднее время отклика системы, позволяющее оценить качество дизайна с точки зрения производительности;
  • • ориентированные на design-time, т.е. позволяющие оценивать качество получаемого дизайна еще на этапе проектирования и, в общем случае, вплоть до тестирования включительно; например, средняя нагруженность классов бизнес-методами (в каждом классе бизнес-методов «в среднем» или «много»);
  • • атрибуты качества архитектурного дизайна как такового — концептуальная целостность дизайна, непротиворечивость, полнота, завершенность; например, любой определенный бизнес-метод является вызываемым, т.е. создан не потому, что может понадобиться в будущем, а определен в соответствии с требованиями или необходим для реализации дизайна в выбранном архитектурном стиле.

Существуют атрибуты, которые сложно измерить, например пор-тируемость (переносимость на другие платформы/операционные системы и т.д.) или безопасность. Измеряемые атрибуты качества описываются определенными метриками. Метрика позволяет количественно оценить атрибут качества, например «модифицируемость» и «сложность» системы.

Не надо путать атрибуты качества дизайна с атрибутами качества, используемыми в ряде требований, предъявляемых к системе. Часть из них может отображаться друг на друга и нести эквивалентную смысловую нагрузку, некоторые могут быть связаны, однако большая часть атрибутов качества дизайна является специфичной именно для дизайна и не связана с требованиями. Например, если используется платформа J2EE (Java 2 Enterprise Edition) и компонентная модель EJB (Enterprise JavaBeans), существуют признаки хорошего дизайна, специфичные для данной платформы и компонентной модели, но абсолютно никак не связанные с какими-либо требованиями к создаваемой на этой платформе программной системе.

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

  • • обзор дизайна (software design review), например неформальный обзор архитектуры членами проектной команды;
  • • статический анализ (,static analysis), например трассировка с требованиями;
  • • симуляция и прототипирование (.simulation and prototyping) — динамические техники проверки дизайна в целом или отдельных его атрибутов качества, например, для оценки производительности используемых архитектурных решений при симуляции нагрузки, близкой к прогнозируемым пиковым.
Page 5

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

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

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

Balsamiq Mockups — платный программный продукт, позволяющий проектировать Web-интерфейсы.

  • 1. Для чего необходим проект программной системы? Дайте определение проектирования ПС.
  • 2. Каковы основные цели проектирования? Что такое процесс проектирования?
  • 3. Каковы роли, которые могут участвовать в процессе проектирования? Назовите их основные задачи.
  • 4. Дайте определение архитектуры программного обеспечения.
  • 5. Какие задачи решает разработка архитектуры приложения?
  • 6. Как определяются исходные данные для проектирования архитектуры приложения?
  • 7. Какие задачи и ограничения определяют цели архитектуры приложения?
  • 8. Каковы основные типы разрабатываемых приложений?
  • 9. Перечислите и опишите основные ограничения развертывания.
  • 10. Дайте краткую характеристику архитектурным стилям проектирования.
  • 11. Какие из архитектурных стилей можно совмещать в одном архитектурном решении и какие нельзя? Почему?
  • 12. На какие ключевые вопросы следует обращать внимание при проектировании? Почему?
  • 13. Какие методы обеспечения отказоустойчивости используют наиболее часто? Перечислите достоинства и недостатки каждого из них.
  • 14. Как можно графически отобразить архитектуру ПС? Опишите основные средства отображения архитектуры ПС.
  • 15. Каковы основные атрибуты анализа качества программного дизайна?

studref.com

14 базовых программ для студентов-архитекторов :: Статьи

Татьяна Козлова окончила архитектурный колледж (МКАГ, бывший КАМС №17). Участвовала в Worldskills и BIM PROJECT 2018. Ведет инстаграм @zamotanya об архитектурных конкурсах, и учебных проектах.

Учеба в вузе, архитектурные конкурсы, первые проекты — всё это требует времени и сил, и, если не подходить к вопросу изобретательно, место творчества может занять всепоглощающая рутина. У меня есть такая хитроумная «палочка-выручалочка» — список самых любимых и полезных программ для архитекторов. Эти программы помогают мне воплощать задуманное, выполнять работу качественно и в срок. Считаю, что всем будущим архитекторам необходимо с ними познакомиться.

SketchUp

Наличие бесплатной/учебной версии: Pro — полная версия для коммерческого использования, Make — бесплатная функционально ограниченная версия.

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

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

Бонус: использование SketchUp совместно с Google Earth позволяет «вытащить» рельеф местности. Затем его можно импортировать в ARCHICAD как «ЗD-сетку геодезических данных».

Rhino + Grasshopper

Наличие бесплатной/учебной версии: ознакомительная бесплатная версия на 90 дней. Скидка 80% на лицензию для студентов и преподавателей.

Применение: 3D-моделирование.Использует алгоритмический подход к моделированию, открывая для архитектора практически безграничные возможности в создании сложных форм. Умеет работать в связке с моделью в ARCHICAD.

Расширение Grasshopper Live Connection позволяет осуществлять двунаправленный обмен геометрией на этапе эскизного проектирования и преобразовывать базовые геометрические формы в BIM-элементы, поддерживающие алгоритмическое редактирование.

Популярность параметрического моделирования растёт по всему миру. Поэтому — предлагаю не отставать. ;)

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

ARCHICAD

Наличие бесплатной/учебной версии: для студентов профильных вузов на весь срок обучения доступна полнофункциональная учебная версия.

Применение: эскизное проектирование, рабочая документация, сметная документация, трехмерная визуализация, анимация, верстка планшета.ARCHICAD — мощный BIM-инструмент для архитекторов. Проектируете в интуитивно понятной среде, при этом на выходе получаете самую подробную документацию.

Чаще всего выбор той или иной программы определяет учебный процесс: вы знаете и используете то, что вам преподают. Но затем, практически всегда, начинается этап самообразования и появляются соответствующие вопросы. У программы интуитивно понятный интерфейс? Она востребована у работодателя? Много ли бесплатных видеоуроков?

Положительные ответы на все эти вопросы я нашла в ARCHICAD — программе, в которой дополнительные функции не вселяют ужас, а сложные расчеты выполняешь за 3-4 клика мышкой. Пока мы учимся, некоторые строительные процессы не до конца нами поняты, но знание ARCHICAD на 200% даёт уверенность, что BIM — это уже настоящее, и освоение этого инструмента — правильный путь для тех, кто хочет стать востребованным специалистом.

Преимущества создания BIM-проекта становятся очевидными в ситуациях, когда необходимо внести изменения в модель. При использовании отдельных 2D-чертежей изменения вносятся на всех листах: переделываются планы, разрезы, фасады, проекции, сметные ведомости. Это колоссальный объем работ. В ARCHICAD создается единая модель, на основе которой строятся все проекции. Следовательно, при изменении модели коррективы будут отображаться на всех созданных чертежах. Невозможно представить ситуацию, когда в ARCHICAD фасад не соответствует плану, а разрез построен неверно.

Фрагмент конкурсных работ на BIM PROJECT, которые показывают использование ARCHICAD

Высоцкий пел: «Я не люблю фатального исхода...» А я не люблю, как в старые добрые времена, считать окна и стены, выискивая их на чертеже, чтобы вывести документацию. За меня эту работу выполнит ARCHICAD, к тому же без ошибок. Моё мнение — такую правильную лень должен проповедовать любой архитектор. Когда я участвовала в Worldskills, у нас было около 3 часов на вывод всех чертежей для проектного предложения. И в этой ситуации, когда дорога каждая секунда, оптимизация рабочего процесса была крайне необходима. Вручную считать экспликации и создавать таблицы никто не запрещал, но сдать модуль вовремя без использования интерактивных каталогов мы бы не смогли.

Вывод: лучше один раз научиться пользоваться каталогами — и быть самым счастливым архитектором на всю оставшуюся профессиональную жизнь!

Также не могу не упомянуть про поддержку IFC-формата. Industry Foundation Classes (IFC) — формат данных с открытой спецификацией, которая не контролируется ни одной компанией. Был разработан для упрощения взаимодействия в строительной индустрии. Используется как формат для информационной модели здания (Building Information Modeling).

ARCHICAD обладает гибкими настройками импорта: все элементы, предусмотренные в программе, обладают свойствами стандарта IFC. Если понадобится смежникам произвести расчет конструкций, например, в ЛИРА-САПР, вам достаточно будет только настроить IFC-схему. Раньше для этого переносили модель по 2D-чертежам и тратили на это минимум недели две.

Бонусы:

1. Удобный функционал для создания взрыв-схемы через использование инструментов «3D-cечение» и «3D-документ»:

2. обучающие видеоуроки на официальном YouTube-канале разработчика  «GRAPHISOFT Россия» (с этих видео я начала изучение ARCHICAD), здесь же можно почерпнуть много знаний о проектировании от ведущих российских бюро.

Разрезаем наш великий проект через 3D-сечение, применяем «вид проекции аксонометрия» — потому что модно. Создаем 3D-документ, настраиваем перья и графическую замену, помещаем сохраненный вид на лист. Повторить столько раз, сколько этажей. Готово. Ваша взрыв-схема готова, в вы — восхитительны!

Cinema 4D, Тwinmotion, Lumion, Artlantis

Наличие бесплатной/учебной версии: всеми разработчиками предоставляется бесплатная учебная версия.

Применение: визуализация проекта.

Лучшие приложения для визуализации модели ARCHICAD. Тwinmotion, Artlantis, Lumion — наиболее интуитивно понятные: подходят для быстрого изучения и позволяют с минимальными усилиями получить приемлемый результат.С 18-й версии ARCHICAD я всё реже использую сторонние рендеры, так как визуализацию теперь можно выполнить внутренним механизмом CineRender. Советую посмотреть YouTube-канал Светланы Гайос — там много полезного про визуализацию в ARCHICAD.

Бонусы:

  • экспорт моделей ARCHICAD в формате файлов Artlantis не требует перенастройки, потому что осуществляется с помощью расширения, которое умеет передавать геометрию, текстуры, перспективные камеры, источники света, солнце и слои;
  • это же расширение дает потрясающую возможность обновлять второй файл Artlantis, передавая в него настройки первого файла, если была изменена сама модель из ARCHICAD;
  • по той же схеме работает обновление исходного файла в Twinmotion;
  • в новой версии Lumion благодаря плагину LiveSync для ARCHICAD вы можете настроить визуализацию модели в режиме реального времени (см. ссылку на плагин ниже).

Пакет Adobe: Photoshop, InDesign, Illustrator

Наличие бесплатной/учебной версии: увы, нет, но есть скидки учащимся и преподавателям, подписка — помесячная. Бесплатная версия действует неделю.

Применение: пострендер, верстка планшета.Визуализация выполнена в ARCHICAD. Постобработка всегда в Adobe Photoshop: здесь применено коллажирование, а также фильтры и цветокоррекция

Adobe Photoshop — инструмент для обработки растровых (векторные — не советую) фотографий. «Дотянуть» рендер, произвести цветокоррекцию, добавить людей, атмосферности — всем этим занимаемся здесь.

Adobe InDesign — инструмент для верстки планшета или портфолио.

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

Бонус: фильтр «Волшебный карандаш» и цветокоррекция в Photoshop — мои главные помощники, когда надо очень быстро «причесать» рендер.

Например, чтобы сделать из рендера «почти чертеж», достаточно обесцветить изображение, применить фильтр «Очерченные края», а дальше на новом слое, залитым одним цветом, поиграть с режимами наложения.

BIMx

Наличие бесплатной/учебной версии: BIMx — бесплатная версия приложения для демонстрации архитектурных проектов, BIMx PRO — версия приложения с расширенным функционалом, обмен сообщениями в BIMcloud (удобно вносить правки), измерения в 2D и 3D. Доступно в AppStore и Google Play.

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

BIMx — лучший инструмент, чтобы донести до преподавателя/заказчика проектные идеи. Приложение позволяет посмотреть BIM-модель в 3D-пространстве, предоставляет удобную навигацию по 2D-документации — и все это через мобильное устройство, планшет. Также доступен просмотр в браузере.

Возможности:

  • 3D-модель;
  • 2D-документация;
  • эффектные плавные переходы между 3D- и 2D-проекциями;
  • 3D-сечения;
  • доступ к облачным хранилищам;
  • наборы информации об элементах;
  • отображение информации о зонах.

Бонус: покажи преподавателям проект на планшете или c помощью VR-очков и получи «пять» автоматом!

BIMsight и Solibri Viewer

Наличие бесплатной/учебной версии: распространяются бесплатно.

Применение: приложения для просмотра IFC-файлов.Студентам-архитекторам необходимо учиться работать с IFC, уметь проверять на корректность сохраненный IFC из ARCHICAD для последующего расчета и конструирования в ЛИРА-САПР или TEKLA.

 Про *dwg 

В ARCHICAD — удобный и интуитивно понятный импорт: достаточно перетащить в рабочее окно чертеж *dwg и можно начинать работать! Также стоит отметить платформу nanoCAD — бесплатный САПР с поддержкой формата *.dwg, СПДС которого заточены под российские стандарты и нормативы.

 Вместо послесловия 

Если вы дочитали до этого места, то вы действительно серьезно интересуетесь архитектурным софтом! Список вышел совсем не миниатюрный. Но лучше всего прочего — комплексный подход к делу, а для меня это — ARCHICAD. Программа помогает мне решать повседневные архитектурные задачи и совершенствуется вместе со мной.

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

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

archspeech.com


Смотрите также