что такое архитектура проекта
Что такое архитектура проекта
Создание проекта веб-студией надо рассматривать с двух сторон: с позиции менеджера и с технической. Игнорирование любой из них с высокой долей вероятности ведёт к провалу заказа. На практике, особенно в небольшой студии, развести эти моменты бывает достаточно сложно, так как, например, ведущий программист выступает, как правило, ещё и менеджером проекта. В нашем курсе обе этих стороны будут постоянно пересекаться, но мы постараемся выделять и отделять организационные моменты от технических.
Проблемы перед веб-студиями возникают как только они получают заказ на проект чуть более сложный, чем обычно. Немного более сложный, немного более большой, немного более высоконагруженный. (В рамках Bitrix Framework это означает, что как только запросы клиента выходят за пределы административной части, инфоблоков с контентом, то начинаются сложности.) В этом курсе мы постараемся дать простые методики как выжить в данном случае.
Курс рассматривает вопросы создания высоконагруженных и сложных проектов без привязки к нашим продуктам. Примеры на базе платформы Bitrix Framework, приведённые в курсе, даны как один из вариантов реализации. Всё, что говорится на страницах ниже, можно применить и при работе с другими системами.
Баллы опыта
уроке.
Если нет интернета
Скачать материалы курса в формате EPUB. Файлы формата EPUB Чем открыть файл на
Android:
EPUB Reader
CoolReader
FBReader
Moon+ Reader
eBoox
iPhone:
FBReader
CoolReader
iBook
Bookmate
Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome
Архитектурный проект: что это
Архитектурные проект представляет собой строительную документацию, точнее, ту ее часть, которая должна содержать архитектурные планы и решения, объем которых должен быть достаточным для того, чтобы разработать остальную строительную документацию для зданий, в проектировании которых должен принимать участие архитектор.
В процессе разработки архитектурного проекта на каждой его стадии все принятые решения должны строго соответствовать всем необходимым требованиям и нормам. Все архитектурные проекты и решения должны учитывать следующие требования:
Какова цель разработки архитектурного проекта?
Главная цель любого архитектурного проекта – как можно более подробно описать и объяснить все инженерные или декоративные решения, основываясь на общепринятые нормативы и стандарты, при этом не нарушая их.
Кому нужен архитектурный проект? В первую очередь, наличие проекта требуют власти, которым он необходим для проверки соответствия объекта СНиПам и государтсвенным стандартам. Кроме того, архитектурный проект нужен самим строителям, чтобы правильно реализовать все идеи заказчика.
Место и значение архитектурного проекта в строительной документации
Создание архитектурно – строительного проектирования осуществляется в соответствии со статьей 48 ГСК РФ. Проект разрабатывается путем создания и подготовки проектной документации для объектов капитального строительства, а также к частям объектов, которые возводятся или находятся в процессе реконструкции на территории земельного участка, который принадлежит застройщику. Архитектурный проект разрабатывается также в случае проведения капитальных ремонтных работ объектов капитального строительства. В этом случае проект необходим, если в процессе ремонта будут затронуты конструктивные характеристики здания, от которых зависит их надежность и безопасность.
Архитектурно-проектная документация является предметом государственной экспертизы, и, одновременно, основанием для выдачи разрешения на строительство. Пункт 4 «Положения о составе разделов проектных документов и требованиям к их содержанию» включает в себя следующие указания на разработку документации.
Для того чтобы эффективно реализовать в процессе строительства все необходимые архитектурные, технические и прочие решения, которые указаны в проектных документах на объект капитального строительства, должна быть разработана рабочая документация, в состав которой входят текстовые документы, чертежи, все спецификации оборудования, изделий, и т.д.
Что включает в себя архитектурный проект
Примерный список необходимых документов для архитектурного проекта, который указан в законодательстве РФ:
Этот список не является полным и может корректироваться в зависимости от места расположения объекта строительства.
Типы архитектурных проектов
Архитектурные проекты, существующие сегодня, делятся на следующие типы:
Типовые архитектурные проекты чаще всего разрабатывают компании, которые задействованы в индивидуальном строительстве. Такой проект включает в себя документацию, которая нужна для получения разрешения на проведение строительных работ.
Эскизный проект включает в себя только внешнее изображение объекта строительства – его эскиз. После разработки эскизного проекта все последующие расчеты, включая работу архитектора фирма-застройщик должна обеспечивать отдельно. Спроектировать здание таким способом очень дорого и сложно.
Наибольшей популярностью пользуются готовые архитектурные проекты. Здания, которые были построены по готовому проекту, очень любят инвесторы. Кроме того, они обладают высокой ликвидностью на рынке недвижимости, и надежны для самих владельцев. Кроме того, дом, построенный по готовому проекту, один из самых экономных, так как на его строительство уходит намного меньше времени и денег, чем на строительство зданий по эскизу или типовому проекту.
Видео о подаче архитектурного проекта:
Состав проекта. Конструктивные и архитектурные решения в проекте
Архитектурный проект состоит из двух разделов: раздел Архитектурных решений, и Раздел конструктивных решений. Раздел архитектурных решений, в свою очередь включает в себя два подраздела: графический и текстовый. В текстовую часть проекта входят:
Графическая часть архитектурного проекта включает в себя:
В разделе конструктивных решений находится описание таких характеристик будущего здания и земельного участка:
В графическую часть входят планы и чертежи кровли, межэтажных перекрытий, фундамента здания, и план каждого этажа.
Этапы разработки архитектурного плана
В данном разделе представлен пошаговый алгоритм разработки архитектурного плана. Этапы разработки архитектурной документации следующие:
Для чего необходим архитектурный проект здания?
В случае отсутствия архитектурного проекта возможны следующие негативные последствия:
Хороший архитектурный план, разработанный профессионалом, полностью оправдывает себя в финансовом плане – как входе строительства, так и по его завершению.
Видео о составе архитектурного проекта:
Немного об архитектурах программного обеспечения
Никаких сомнений, что за последнее время мир только укрепил свою зависимость от программного обеспечения. Приложения должны обладать высокой доступностью, качественно выполнять требуемые функции и иметь адекватную стоимость. Эти характеристики, в той или иной степени, определяет архитектура ПО.
В стандарте IEEE 1471 дается следующее определение: «Архитектура – это базовая организация системы, которая описывает связи между компонентами этой системы (и внешней средой), а также определяет принципы её проектирования и развития». Однако многие другие определения архитектуры признают не только структурные элементы, но и их композиции, а также интерфейсы и другие соединительные звенья.
Пока что у нас нет общепринятой классификации архитектурных парадигм, но все-таки мы легко можем выделить несколько базовых и широко распространенных архитектурных паттернов или стилей. Взглянем на некоторые из них.
«Каналы и фильтры» (Pipes and Filters)
Рисунок 1 – Pipes and Filters
Этот вид архитектуры подходит в том случае, если процесс работы приложения распадается на несколько шагов, которые могут выполнятся отдельными обработчиками. Основными компонентами являются «фильтр» (filter) и «канал» (pipe). Иногда дополнительно выделяют «источник данных» (data source) и «потребитель данных» (data sink).
Каждый поток обработки данных – это серия чередующихся фильтров и каналов, начинающаяся источником данных и заканчивающаяся их потребителем. Каналы обеспечивают передачу данных и синхронизацию. Фильтр же принимает на вход данные и обрабатывает их, трансформируя в некое иное представление, а затем передает дальше.
К примеру, один из фильтров может реализовывать шифр Цезаря – шифр подстановки, в котором каждый символ в тексте заменяется символом, находящимся на некотором постоянном числе позиций левее или правее в алфавите. Одна из вариаций кода Цезаря – это ROT13, имеющая шаг равный 13.
Рисунок 2 – Принцип ROT13
Его достаточно просто реализовать с помощью стандартной терминальной утилиты Unix tr:
А вот код на Python:
Фильтры можно легко заменять, использовать повторно, переставлять местами, что дает возможность реализовывать множество функций на основе ограниченного набора компонентов. Более того, активные фильтры могут работать параллельно, что приводит к значительному повышению производительности на многопроцессорных системах. Однако есть и недостатки, например, фильтры зачастую тратят больше времени на преобразование входных данных, чем на их обработку.
В качестве примера использования этой архитектуры может служить оболочка UNIX Shell, одним из дизайнеров которой был Дуглас Макилрой (Douglas McIlroy). Другим примером может стать архитектура компилятора, если рассматривать её как последовательность фильтров: лексера, парсера, семантического анализатора и генератора кода.
Дополнительную информацию по этому типу архитектуры можно найти здесь и здесь.
Многоуровневая архитектура
Является одной из самых известных архитектур, в которой каждый слой выполняет определенную функцию. В зависимости от ваших нужд вы можете реализовать любое количество уровней, но слишком большое их количество приведет к чрезмерному усложнению системы. Часто выделяют три основных уровня: уровень представления, уровень логики и уровень данных.
Рисунок 2 – Многоуровневая архитектура
Слою не обязательно знать, что делают его соседи. Здесь проявляется такое свойство как разделение ответственности. Если все три слоя являются закрытыми, то запрос пользователя к верхнему уровню инициирует цепочку обращений с верхнего уровня до самого нижнего. В этом случае уровень представления отвечает за пользовательский интерфейс и отображение данных для пользователя и ничего не знает о существовании физического хранилища данных. Ничего о существовании базы данных не знает и уровень логики – его «беспокоят» только правила бизнес-логики. Доступ к базе данных имеет лишь через уровень управления данными.
Достоинствами применения такой архитектуры являются простота разработки (в основном из-за того, что этот вид архитектуры всем знаком) и простота тестирования. Среди недостатков можно выделить возможные сложности с производительностью и масштабированием – всему виной необходимость прохождения запросов и данных по всем уровням (опять же, в том случае, если все слои являются закрытыми).
Одним из самых известных примеров этого паттерна может служить сетевая модель OSI. Подробнее о многоуровневой архитектуре можно почитать, например, в блогах вот этих трех программистов и разработчиков:
Архитектура, управляемая событиями (EDA)
Это популярный адаптивный паттерн, широко используемый для создания масштабируемых систем. Чтобы ознакомиться с принципами событийно-ориентированной архитектуры, можете посмотреть вот это видео от Complexity Academy:
Рисунок 3 – Событийно-ориентированная архитектура
Если говорить о программном обеспечении, то в этой схеме существует два варианта событий: инициализирующее событие и событие, на которое реагируют обработчики. Обработчики являются изолированными независимыми компонентами, отвечающими (в идеале) за какую-нибудь одну задачу, и содержат бизнес-логику, необходимую для работы.
Посредник может быть реализован несколькими способами. Самый просто способ – это воспользоваться фреймворками для интеграции Apache Camel, Spring Integration или Mule ESB. Для больших приложений, которым требуется более сложные функции управления, вы можете реализовать посредника, используя концепцию управления бизнес-процессами (например движок jBPL).
Архитектура, управляемая событиями – это относительно сложный паттерн. Причиной тому – его распределенная и асинхронная природа. Вам придется решать проблемы фрагментации сети, обрабатывать ошибки очереди событий и так далее. Плюсами этой архитектуры могут служить высокая производительность, легкость развертки и поразительные возможности масштабирования. Однако возможно усложнение процесса тестирования системы.
Подробнее о событийно-ориентированной архитектуре можно почитать здесь.
Микроядерная архитектура
Паттерн состоит из двух компонентов: основной системы (ядра) и плагинов. Ядро содержит минимум бизнес-логики, но руководит загрузкой, выгрузкой и запуском необходимых плагинов. Таким образом, плагины оказываются несвязанными друг с другом.
Поскольку плагины могут разрабатываться независимо друг от друга, такие системы обладают очень высокой гибкостью и, как следствие, легко тестируются. Производительность приложения, построенного на основе такой архитектуры, напрямую зависит от количества подключенных и активных модулей.
Возможно самым лучшим примером микроядерной архитектуры будет Eclipse IDE. Скачивая Eclipse без надстроек, вы получаете совершенно пустой редактор. Однако с добавлением плагинов пустой редактор начнет превращаться в полезный и легко настраиваемый продукт. Еще один хороший пример – это браузер: дополнительные плагины позволяют расширить его функциональность.
Подробнее о микроядерной архитектуре можно узнать здесь и здесь.
Микросервисная архитектура
Этот тип архитектуры позволяет масштабировать приложения по оси Y «Куба масштабирования» (Scale Cube), описанного в книге «The Art of Scalability» Мартина Эбботта (Martin L. Abbott) и Майкла Фишера (Michael T. Fisher). В этом случае приложение разбивается на множество небольших сервисов, называемых микросервисами. Каждый микросервис включает в себя бизнес-логику и представляет собой совершенно независимый компонент. Сервисы одной системы могут быть написаны на различных языках программирования и общаться друг с другом, используя различные протоколы.
Поскольку каждый микросервис является отдельным проектом, вы можете распределить работу над ними между командами разработчиков, то есть над системой могут одновременно трудиться несколько десятков программистов. Микросервисная архитектура позволяет с легкостью масштабировать приложение – если вам понадобилось внедрить новую функцию (развертывать каждый микросервис можно по отдельности), просто напишите новый сервис, а если какой-то функцией никто не пользуется – отключите сервис.
Подробнее о микросервисных архитектурах вы можете почитать в следующих источниках: здесь, тут и вот тут.
Дополнительные материалы
В рамках этой статьи мы рассмотрели несколько видов архитектур программного обеспечения. Разумеется, здесь не было затронуто множество других паттернов. В качестве дополнительных материалов по теме можете посмотреть следующие ресурсы:
Помимо этого мы рассказываем о работе службы поддержки «облачного» провайдера и теме оптимизации производительности, к обсуждению которой мы планируем вернуться в одном из следующих материалов.
Архитектура IT-проекта с Attribute-Driven Design
Архитектура приложения — это его технологическая база, которая учитывает риски проекта, бюджет, требования и ограничения, потребности в масштабировании.
Помимо разработки архитектуры, на старте требуется приблизительно оценить объем и стоимость проекта. Для этого мы в своей практике используем одну из проверенных методологий создания архитектуры ПО — Attribute-Driven Design (ADD). При этом мы опираемся на атрибуты качества того или иного IT-продукта. На их основе мы на этапе оценки (пресейла) создаём архитектурную концепцию системы.
Рассмотрим этапы работы с архитектурной концепцией, возможные сложности и решения, исходя из опыта нашего Архитектурного комитета. Мы надеемся, что статья будет полезна архитекторам и разработчикам, желающим освоить методологию ADD, и может быть интересна смежным специалистам.
Именно IT-архитектор решает, как в конечном итоге будет выглядеть информационная система — в целом и в деталях. Ему требуется найти баланс между конкурирующими требованиями и ограничениями.
Если у вас есть детальное архитектурное решение, это позволит наиболее точно оценить сроки и стоимость реализации продукта. Кроме того, появляется возможность уже на старте определить характеристики системы, которая будет соответствовать бизнес-задачам. Среди критериев качества архитектуры – гибкость для масштабирования, снижение рисков, скорость работы и возможность независимого выбора подрядчиков.
О том, как выглядит день архитектора, и о наиболее требовательных к архитектуре проектах мы рассказывали ранее на Хабре и в нашем подкасте.
Требования и ограничения
Наша цель — спроектировать архитектуру систематическим, предсказуемым и экономически эффективным способом. Для этого нужно определить требования к продукту.
Как правило, техническое задание (ТЗ) на разработку продукта содержит требования, но не всегда они указаны в достаточном объеме. По этой причине в числе ключевых задач IT-архитектора – сбор и анализ требований, создание дизайна архитектуры и описание решения, его проверка, а также контроль и надзор во время разработки ПО.
Рассмотрим, что входит в список требований:
Цель проектирования
От цели зависит, что нам нужно на старте: детальная архитектура или приблизительное представление об устройстве системы, которое позволит оценить объем и стоимость работ.
Атрибуты качества, нефункциональные требования
Эти атрибуты определяют свойства системы, которые она должна демонстрировать — требования к производительности, доступности, безопасности, удобству использования.
Пример: система должна работать 24х7, допускается простой не более 30 минут в месяц.
Функциональные требования
Определяют действия, которые система способна выполнить.
Пример: возможность выгружать данные из файла и рассылать отчеты по email.
Системные требования
Возникают постепенно в процессе детализации и реализуются итеративно.
Пример: авторизация, ведение журнала действий, кэширование.
Ограничения
Не относятся напрямую к поведению системы и не поддаются нашему влиянию. Например, у клиента есть пожелания по разработке микросервисной, а не монолитной архитектуры. Также сюда относятся требования законодательства, например, в области хранения персональных данных.
Как правило, владелец продукта заранее не имеет полного списка требований к системе, поэтому архитектор непосредственно организует процесс их сбора и фиксации. Из всех требований к системе специалист обязан выделить архитектурно значимые, которые оказывают глубокое влияние на конечное решение.
Согласно методологии ADD, сбор требований – это первый этап работы. Его назначение:
— помочь оценить стоимость и график работ;
— выработать ключевые технологии;
— обеспечить достижение бизнес-целей в процессе разработки.
Далее рассмотрим остальные этапы проектирования.
Обзор методологии
1) Собираем требования
В качестве источника могут выступать результаты опросов стейк-холдеров, анализ бизнес-целей проекта и историй использования (user story). При этом важно конкретизировать, что имеет в виду клиент. Например, не просто «безотказная работа сайта», а «допустимый период простоя – 30 минут в месяц».
Далее мы оцениваем важность требований по двум критериям:
ценность для бизнеса;
степень влияния на архитектуру.
Уровни важности оцениваем по шкале HML (high, medium, low — высокий, средний, низкий). Таким образом, каждое требование будет иметь двухбуквенное сочетание. Архитектурно значимые пункты имеют обозначения HH, HM, HL, MH, MM. Стоит отметить, что большое число требований HH означает высокие риски на проекте.
2) Проектируем архитектуру
Мы проектируем архитектуру ПО, исходя из наиболее значимых атрибутов качества. Это рекурсивный процесс, в ходе которого система декомпозируется на более мелкие подсистемы.
ADD — первый метод, который концентрируется на атрибутах качества и способах их достижения. Важным вкладом ADD было признание того, что анализ и документация являются неотъемлемой частью процесса проектирования. Этот метод успешно применяется более 15 лет.
Сейчас актуальная версия ADD — 3.0, итеративная. Согласно ей, проектирование выполняется поэтапно в течение всего времени разработки системы, в каждом спринте. В ней по шагам описано руководство по тем задачам, которые необходимо выполнить в рамках каждой итерации.
Шаг 1. Проверка входных данных
Убеждаемся, что все необходимые данные и требования доступны, приоритизированы, корректны и выполнимы, а цель работы понятна.
Шаг 2. Определяем список требований к подсистеме
Ранжируем требования по важности для бизнеса и степени влияния на архитектуру, группируем в соответствии с оценкой HML, выбираем 5-6 приоритетных. Устанавливаем цель каждой итерации.
Шаг 3. Выбираем часть системы для проектирования
Исходим из риска и сложности реализации, ценности для бизнеса, критического пути и точности проработки требований. Строим работу на достижении требований, которые соответствуют целей итерации
Шаг 4. Определяем лучший вариант из возможных
Самый сложный пункт. Анализируем все варианты, находим преимущества и недостатки.
Шаг 5. Конкретизируем компоненты выбранной концепции, определяем обязанности и интерфейсы
Как правило, в начале работы концепция формулируется в общем виде. На данном этапе мы определяем все элементы подсистемы и ответственность каждого, выбираем интерфейс, через который компоненты взаимодействуют между собой.
Шаг 6. Делаем эскиз решения и краткое описание
Оформляем описание в наглядный документ, например, в виде UML-диаграммы или SFML. Нужно также зафиксировать все принятые решения, описать, на какие компромиссы мы пошли и какие альтернативы рассмотрели. Это поможет в дальнейшем оценить аргументы в пользу конкретной архитектуры и создать документацию.
Шаг 7. Проверка выполнения требований
На этом шаге методология рекомендует получить “второе мнение” других опытных коллег-архитекторов, для того чтобы подойти к процессу более объективно. Участие нескольких специалистов с их опытом и точкой зрения на архитектуру поможет оперативно выявить недочеты, если они есть.
Мы уточняем и конкретизируем требования, расставляем приоритеты и затем повторяем шаги со 2 по 7 в каждой итерации. Таким образом необходимо проработать все требования с высоким приоритетом, соблюдая все ограничения. Но не обязательно проводить итерации последовательно. Скорее всего, вы будете чередовать этапы проектирования и реализации системы.
3) Отслеживаем прогресс
Чтобы вовремя выполнить перечисленные выше шаги, архитектору нужно наблюдать за прогрессом работы команды и оперативно откликаться на изменения. Авторы методологии советуют отслеживать выполнение шагов с помощью архитектурного бэклога в виде канбан-доски. В ее столбцы мы помещаем архитектурно значимые требования, ограничения и системные задачи. Они могут иметь следующие статусы:
Not Yet Addressed (Еще не рассмотрено)
Partially Addressed (Рассмотрено частично)
Completely Addressed (Рассмотрено полностью)
Рассмотрим на примере
В заключение расскажем на примере о том, как закладывается архитектура по ADD.
Задача
К нам обратился зарубежный заказчик — владелец крупного хранилища данных, полученных из старинных газет (более 1 млрд отсканированных страниц). Заказчику потребовалось найти и собрать в единую базу знаний все брачные объявления, а также записи о свадьбах: кто, когда и на ком женился.
Чтобы обработать информацию и выделить нужные факты, мы использовали нейросеть. Инженеры заказчика ранее уже создали все необходимые модели TensorFlow, которые должны запускаться последовательно, образуя конвейер. На вход модели поступал результат работы предыдущей модели, преобразованный по определенному алгоритму. Модели работали с разной скоростью и имели разные требования к ресурсам (потребление оперативной памяти, нагрузка на процессор, потребность в GPU).
Чтобы выполнить проект в срок, мы определили, что в среднем нужно обрабатывать до 10 миллионов страниц в день. Запросы на обработку поступали неравномерно, в некоторые часы их количество было близко к нулю, в другие — составляло порядка одного-двух миллионов. Страница полностью обрабатывалась не позднее чем через час после поступления.
Заказчик планировал развернуть систему в облаке. Поэтому было важно оптимально использовать вычислительные ресурсы, чтобы минимизировать плату за их аренду.
Варианты использования
Вариант использования
Описание
Извлечение фактов из текста
На вход системы подается отсканированный текст. На выходе получаем JSON с извлеченными фактами на интересующую нас тему.
Атрибуты качества
Атрибут
Описание
До 10 миллионов страниц в день. Результат обработки страницы должен быть получен не позднее чем через 1 час.
Система должна уметь справляться с ростом нагрузки. Она неравномерная: от 0 до 2 миллионов запросов в час.
Необходимо оптимально использовать вычислительные ресурсы, чтобы минимизировать плату за их аренду.
Ограничения
Описание
Система должна быть развернута в облаке AWS.
Использовать для вычислений готовые модели TensorFlow. Модели работают с разной скоростью. Требования к ресурсам сильно отличаются: некоторые потребляют много оперативной памяти, другие сильно нагружают процессор, третьим для работы необходим GPU.
Архитектурные задачи
Описание
Спроектировать и описать высокоуровневую архитектуру системы
Процесс проектирования
После фиксации требований мы подготовились к тому, чтобы начать первую итерацию ADD.
Шаг 1. Проверка и анализ исходных данных
Категория
Детали
Категория
Детали
Спроектировать систему с нуля. Работа должна быть выполнена в виде последовательных коротких итераций, чтобы оперативно получать обратную связь.
Спроектировать систему с нуля. Работа должна быть выполнена в виде последовательных коротких итераций, чтобы оперативно получать обратную связь.