Как сделать красивую подачу архитектурного проекта
Обновлено: 26.07.2024
Хотелось разобраться, что вообще в себя включает процесс создания архитектуры программы, какие задачи при этом решаются, какие критерии используются (чтобы правила и принципы перестали быть всего лишь догмами, а стали бы понятны их логика и назначение). Тогда будет понятнее и какие инструменты лучше использовать в том или ином случае.
Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении. Материал собирался для себя, но, может, он окажется полезен кому-то еще. Мне данная работа позволила не только узнать много нового, но и в ином контексте взглянуть на кажущиеся уже почти банальными основные принципы ООП и по настоящему оценить их важность.
Информации оказалось довольно много, поэтому приведены лишь общая идея и краткие описания, дающие начальное представление о теме и понимание, где искать дальше.
Эффективность системы. В первую очередь программа, конечно же, должна решать поставленные задачи и хорошо выполнять свои функции, причем в различных условиях. Сюда можно отнести такие характеристики, как надежность, безопасность, производительность, способность справляться с увеличением нагрузки (масштабируемость) и т.п.
Иными словами: Должна быть возможность расширить/изменить поведение системы без изменения/переписывания уже существующих частей системы.
Масштабируемость процесса разработки. Возможность сократить срок разработки за счёт добавления к проекту новых людей. Архитектура должна позволять распараллелить процесс разработки, так чтобы множество людей могли работать над программой одновременно.
Существует целая методология разработки программ на основе тестов, которая так и называется — Разработка через тестирование (Test-Driven Development, TDD).
Возможность повторного использования. Систему желательно проектировать так, чтобы ее фрагменты можно было повторно использовать в других системах.
Хорошо структурированный, читаемый и понятный код. Сопровождаемость. Над программой, как правило, работает множество людей — одни уходят, приходят новые. После написания сопровождать программу тоже, как правило, приходится людям, не участвовавшем в ее разработке. Поэтому хорошая архитектура должна давать возможность относительно легко и быстро разобраться в системе новым людям. Проект должен быть хорошо структурирован, не содержать дублирования, иметь хорошо оформленный код и желательно документацию. И по возможности в системе лучше применять стандартные, общепринятые решения привычные для программистов. Чем экзотичнее система, тем сложнее ее понять другим (Принцип наименьшего удивления — Principle of least astonishment. Обычно, он используется в отношении пользовательского интерфейса, но применим и к написанию кода).
Удача заключается в том, что данное решение является не только единственно известным, но и универсальным. Помимо снижения сложности, оно одновременно обеспечивает гибкость системы, дает хорошие возможности для масштабирования, а также позволяет повышать устойчивость за счет дублирования критически важных частей.
Соответственно, когда речь идет о построении архитектуры программы, создании ее структуры, под этим, главным образом, подразумевается декомпозиция программы на подсистемы (функциональные модули, сервисы, слои, подпрограммы) и организация их взаимодействия друг с другом и внешним миром. Причем, чем более независимы подсистемы, тем безопаснее сосредоточиться на разработке каждой из них в отдельности в конкретный момент времени и при этом не заботиться обо всех остальных частях.
- Масштабируемость (Scalability)
возможность расширять систему и увеличивать ее производительность, за счет добавления новых модулей. - Ремонтопригодность (Maintainability)
изменение одного модуля не требует изменения других модулей - Заменимость модулей (Swappability)
модуль легко заменить на другой - Возможность тестирования (Unit Testing)
модуль можно отсоединить от всех остальных и протестировать / починить - Переиспользование (Reusability)
модуль может быть переиспользован в других программах и другом окружении - Сопровождаемость (Maintenance)
разбитую на модули программу легче понимать и сопровождать
"Архитектура идентифицирует главные компоненты системы и способы их взаимодействия. Также это выбор таких решений, которые интерпретируются как основополагающие и не подлежащие изменению в будущем."
"Архитектура — это организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением.
Система — это набор компонентов, объединенных для выполнения определенной функции."
1. Иерархическая
Не стоит сходу рубить приложение на сотни классов. Как уже говорилось, декомпозицию надо проводить иерархически — сначала систему разбивают на крупные функциональные модули/подсистемы, описывающие ее работу в самом общем виде. Затем, полученные модули, анализируются более детально и, в свою очередь, делятся на под-модули либо на объекты.
Перед тем как выделять объекты разделите систему на основные смысловые блоки хотя бы мысленно. Для небольших приложений двух уровней иерархии часто оказывается вполне достаточно — система вначале делится на подсистемы/пакеты, а пакеты делятся на классы.
Для обозримости на каждом иерархическом уровне рекомендуют выделять от 2 до 7 модулей.
2. Функциональная
Деление на модули/подсистемы лучше всего производить исходя из тех задач, которые решает система. Основная задача разбивается на составляющие ее подзадачи, которые могут решаться/выполняться независимо друг от друга. Каждый модуль должен отвечать за решение какой-то подзадачи и выполнять соответствующую ей функцию. Помимо функционального назначения модуль характеризуется также набором данных, необходимых ему для выполнения его функции, то есть:
Модуль = Функция + Данные, необходимые для ее выполнения.
Причем желательно, чтобы свою функцию модуль мог выполнить самостоятельно, без помощи остальных модулей, лишь на основе своих входящих данных.
Модуль — это не произвольный кусок кода, а отдельная функционально осмысленная и законченная программная единица (подпрограмма), которая обеспечивает решение некоторой задачи и в идеале может работать самостоятельно или в другом окружении и быть переиспользуемой. Модуль должен быть некой "целостностью, способной к относительной самостоятельности в поведении и развитии" (Кристофер Александер).
Таким образом, грамотная декомпозиция основывается, прежде всего, на анализе функций системы и необходимых для выполнения этих функций данных.
3. High Cohesion + Low Coupling
Самым же главным критерием качества декомпозиции является то, насколько модули сфокусированы на решение своих задач и независимы. Обычно это формулируют следующим образом: "Модули, полученные в результате декомпозиции, должны быть максимально сопряженны внутри (high internal cohesion) и минимально связанны друг с другом (low external coupling)."
Следствием High Cohesion является принцип единственной ответственности (Single Responsibility Principle — первый из пяти принципов SOLID), согласно которому любой объект/модуль должен иметь лишь одну обязанность и соответственно не должно быть больше одной причины для его изменения.
- функциональная целостность и завершенность — каждый модуль реализует одну функцию, но реализует хорошо и полностью; модуль самостоятельно (без помощи дополнительных средств) выполняет полный набор операций для реализации своей функции.
- один вход и один выход — на входе программный модуль получает определенный набор исходных данных, выполняет содержательную обработку и возвращает один набор результатных данных, т.е. реализуется стандартный принцип IPO — вход–процесс–выход;
- логическая независимость — результат работы программного модуля зависит только от исходных данных, но не зависит от работы других модулей;
- слабые информационные связи с другими модулями — обмен информацией между модулями должен быть по возможности минимизирован.
Делая декомпозицию системы желательно проверять ее качество задавая себе вопросы: "Какую функцию выполняет каждый модуль?", “Насколько модули легко тестировать?”, “Возможно ли использовать модули самостоятельно или в другом окружении?”, “Как сильно изменения в одном модуле отразятся на остальных?”
Для наглядности, картинка из неплохой статьи "Decoupling of Object-Oriented Systems", иллюстрирующая основные моменты, о которых будет идти речь.
1. Интерфейсы. Фасад
Главным, что позволяет уменьшать связанность системы, являются конечно же Интерфейсы (и стоящий за ними принцип Инкапсуляция + Абстракция + Полиморфизм):
Итак, когда взаимодействие и зависимости модулей описываются лишь с помощью интерфейсов, те есть абстракций, без использования знаний об их внутреннем устройстве и структуре, то фактически тем самым реализуется инкапсуляция, плюс мы имеем возможность расширять/изменять поведения системы за счет добавления и использования различных реализаций, то есть за счет полиморфизма. Из этого следует, что концепция интерфейсов включает в себя и в некотором смысле обобщает почти все основные принципы ООП — Инкапсуляцию, Абстракцию, Полиморфизм. Но тут возникает один вопрос. Когда проектирование идет не на уровне объектов, которые сами же и реализуют соответствующие интерфейсы, а на уровне модулей, то что является реализацией интерфейса модуля? Ответ: если говорить языком шаблонов, то как вариант, за реализацию интерфейса модуля может отвечать специальный объект — Фасад.
Фасад — это объект-интерфейс, аккумулирующий в себе высокоуровневый набор операций для работы с некоторой подсистемой, скрывающий за собой ее внутреннюю структуру и истинную сложность. Обеспечивает защиту от изменений в реализации подсистемы. Служит единой точкой входа — "вы пинаете фасад, а он знает, кого там надо пнуть в этой подсистеме, чтобы получить нужное".
2. Dependency Inversion. Корректное создание и получение зависимостей
- Модули верхнего уровня не должны зависеть от модулей нижнего уровня. И те, и другие должны зависеть от абстракций.
- Абстракции не должны зависеть от деталей. Реализация должна зависеть от абстракции.
Не смотря на свою фундаментальность и кажущуюся простоту это правило нарушается, пожалуй, чаще всего. А именно, каждый раз, когда в коде программы/модуля мы используем оператор new и создаем новый объект конкретного типа, то тем самым вместо зависимости от интерфейса образуется зависимость от реализации.
Понятно, что этого нельзя избежать и объекты где-то должны создаваться. Но, по крайней мере, нужно свести к минимуму количество мест, где это делается и в которых явно указываются классы, а также локализовать и изолировать такие места, чтобы они не были разбросаны по всему коду программы. Решение заключается в том, чтобы сконцентрировать создание новых объектов в рамках специализированных объектов и модулей — фабрик, сервис локаторов, IoC-контейнеров.
В каком-то смысле такое решение следует Принципу единственного выбора (Single Choice Principle), который говорит: "всякий раз, когда система программного обеспечения должна поддерживать множество альтернатив, их полный список должен быть известен только одному модулю системы". В этом случае, если в будущем придется добавить новые варианты (или новые реализации, как в рассматриваемом нами случае создания новых объектов), то достаточно будет произвести обновление только того модуля, в котором содержится эта информация, а все остальные модули останутся незатронутыми и смогут продолжать свою работу как обычно.
- что модуль делает, какую функцию выполняет
- что модулю нужно от его окружения, то есть с какими объектами/модулями ему придется иметь дело и
- как он это будет получать
-
Модуль сам создает объекты необходимые ему для работы.
Но, как и было сказано, модуль не может это сделать напрямую — для создания необходимо вызвать конструктор конкретного типа, и в результате модуль будет зависеть не от интерфейса, а от конкретной реализации. Решить проблему в данном случае позволяет шаблон Фабричный Метод (Factory Method).
"Суть заключается в том, что вместо непосредственного инстанцирования объекта через new, мы предоставляем классу-клиенту некоторый интерфейс для создания объектов. Поскольку такой интерфейс при правильном дизайне всегда может быть переопределён, мы получаем определённую гибкость при использовании низкоуровневых модулей в модулях высокого уровня".
В случаях, когда нужно создавать группы или семейства взаимосвязанных объектов, вместо Фабричного Метода используется Абстрактная Фабрика (Abstract factory).
Этот подход реализуется шаблоном Локатор Сервисов (Service Locator), основная идея которого заключается в том, что в программе имеется объект, знающий, как получить все зависимости (сервисы), которые могут потребоваться.
Главное отличие от фабрик в том, что Service Locator не создаёт объекты, а фактически уже содержит в себе инстанцированные объекты (или знает где/как их получить, а если и создает, то только один раз при первом обращении). Фабрика при каждом обращении создает новый объект, который вы получаете в полную собственность и можете делать с ним что хотите. Локатор же сервисов выдает ссылки на одни и те же, уже существующие объекты. Поэтому с объектами, выданными Service Locator, нужно быть очень осторожным, так как одновременно с вами ими может пользоваться кто-то еще.
Объекты в Service Locator могут быть добавлены напрямую, через конфигурационный файл, да и вообще любым удобным программисту способом. Сам Service Locator может быть статическим классом с набором статических методов, синглетоном или интерфейсом и передаваться требуемым классам через конструктор или метод.
Вообще говоря, Service Locator иногда называют антипаттерном и не рекомендуют использовать (главным образом потому, что он создает неявные связности и дает лишь видимость хорошего дизайна). Подробно можно почитать у Марка Симана:
Service Locator is an Anti-Pattern
Abstract Factory or Service Locator?
Это так и называется — Внедрение Зависимостей (Dependency Injection). Обычно требуемые зависимости передаются либо в качестве параметров конструктора (Constructor Injection), либо через методы класса (Setter injection).
Не будет преувеличением сказать, что использование интерфейсов для описания зависимостей между модулями (Dependency Inversion) + корректное создание и внедрение этих зависимостей (прежде всего Dependency Injection) являются центральными/базовыми техниками для снижения связанности. Они служат тем фундаментом, на котором вообще держится слабая связанность кода, его гибкость, устойчивость к изменениям, переиспользование, и без которого все остальные техники имеют мало смысла. Но, если с фундаментом все в порядке, то знание дополнительных приемов может быть очень даже полезным. Поэтому продолжим.
4. Замена прямых зависимостей на синхронизацию через общее ядро
5. Закон Деметры (law of Demeter)
Закон Деметры запрещает использование неявных зависимостей: "Объект A не должен иметь возможность получить непосредственный доступ к объекту C, если у объекта A есть доступ к объекту B и у объекта B есть доступ к объекту C". Java-пример.
6. Композиция вместо наследования
-
(небольшая полезная глава из UML Tutorial); ; ; ; — статья из которой хорошо видно что критерии тестируемости кода и хорошего дизайна совпадают; Мартина Фаулера.
В сообществе запрещается всё то, что запрещено правилами сайта :) Архитектурные проекты принимаются к публикации только при наличии:
-имени проекта (если имеется)
-места строительства (предполагаемого/фактического)
Документация не по ЕСКД! Переделать!
Какая-то херобора от руки, криворукие наброски, а не проект
Признаюсь честно - мне на внешний вид дома почти плевать, мне важнее удобный план с расстановкой мебели.
Струнный мост, Иерусалим
Новый дизайн сайта скрывает большую часть вертикальных картинок в ленте, поэтому полная версия без полей ниже, под катом
Canon 7d, Tokina 11-16mm f2.8, панорама
Фотограф - Алексей Голубев
Доминиканский собор, Львов
рисовалось ещё в прекрасные доковидные времена. когда захотел и рванул во львов, не переживая обо всём вот этом.
В Екатеринбурге построили дом с "дырой"
Горожане уже неделю гадают, зачем нужна эта пустота
Здание, скетч
Скетч, здание
Акварельный Город
Этого человека нужно всесоборно избрать на должность Главного Архитектора РПЦ!
Знакомьтесь - Тадао Андо, архитектор из Японии. Как увидел несколько его работ сразу понял - ВОТ ОНО! Идеальный дизайн культовых учреждений - простота, скромность, единение с окружающим миром.
Гравное же в религии не золотом всё увешать я правильно понимаю?
В Петербурге предлагают построить 320-ти купольный храм
Количество куполов символизирует надвигающийся 320-летний юбилей Санкт-Петербурга, а высота храма составит 141,8 метра, что отсылает к количеству дней Великой Отечественной войны.
В цокольном этаже предлагается устроить археологический музей, где будут экспонироваться остатки средневековых крепостей Ландскрона и Ниеншанц: пятигранная форма плана вторит очертаниям крепости XVII века.
Вокруг храма предлагается разбить ландшафтный парк и организовать парковку на 1703 машиноместа, что соответствует году основания Санкт-Петербурга.
Авторы проекта — инициативная группа PapaUrban. Коллектив не склонен причислять себя ни к православным активистам, ни к градозащитникам, однако, как утверждают авторы, существующие планы по строительству на этой территории бизнес-центра им не нравятся.
Наконец то добрался до широкоформатного сканера и смог отсканировать работы, котрые находятся в фондах Академии художеств. В этом посте мне хочется не только показать сами подачи проектов, но и эскизы и макеты к ним.
3 курс. 2-й семестр. "Ресторан в парке"
3 курс. 2-й семестр. "Интерьер ресторана"
4 курс. 1-й семестр. "Реставрационное училище"
4 курс. 1-й семестр. "Концертный зал камерной музыки"
4 курс. 1-й семестр. "Интерьер концертного зала"
4 курс. 2-й семестр. "Секционный жилой дом"
Комментарии 196
Очень интересные работы!
Однако позволю себе наглость внести немного критики… Последний дом — нереалистичен с представленными планировками. Нет замкнутых ядер жёсткости и нет конструкций, проходящих сквозь все этажи. Ну, это так, взгляд инженера-зануды)))
Макеты приятные. Их отдали или вуз хранит?
нравятся простые и понятные формы, цвета…подачи идеальные, как по мне…особенно понравился секционный жилой дом…"Ле Корбузье'вская тема" …)))))квартиры просторные довольно, в коридорах в футбол можно играть) а лоджии, как я понял, только для крайних секций?
нынешние последние работы можешь скинуть?
Ну вот, а ты машинами балуешься )) классные проекты
никогда не позно
А мне больше от руки всё нравится делать, нежели в автокадах и три-дэ-максах)))
Я сразу свою учёбу вспомнила.
Мило)
проекты очень достойные)
сам заканчивал строительный универ в СПб)))
ок, гляну) а ты как архитектор работаешь или строишь?
Ох… зашла на Ауди посмотреть, а тут такое… очень близкое… и актуальное… 6 лет учёбы на архитектурно-художественном факультете! проекты в ручную, ночи в обнимку с линейками, карандашами и т.д.
… диплом через 2 недели защищаю)
p.s. эскизы и проекты крутые!
удачи в этом интересном деле!
привет из Одессы)
Спасибо! И Вам удачи в защите!
спасибо) и было бы очень интересно взглянуть на нынешние проекты)
О это без проблем)) сейчас ссылки могу скинуть в личку
О так я это с удовольствием) посмотрю) вдохновлюсь)
жду жду жду :)
Боже как я тебе завидую! Я всегда мечтал заниматься архитектурой, но мои родители думали иначе, а они у меня суровые ребята. Рад, что ты смог совместить работу со своим увлечением. Я конечно тоже на свою стезю не очень жалуюсь, но всё равно знаю, что занимаюсь чем-то не тем.
В данном курсе изучаются все инструменты и тонкости Photoshop. Реализация сложных проектов теперь для вас не проблема!
Стоимость
Форма обучения
Длительность
Кому подойдет
Язык обучения
Начало курса
О курсе
Обучение состоит из нескольких этапов: разбор композиции и смарт объекты, работа с текстурами, интерьер, освещение, тени, воздушная перспектива, концептуальная подача, разрезы, обработка плана, реалистичная подача. Постоянная поддержка на каждом шаге изучения и подробная обратная связь от преподавателя, сделают из вас профессионала подачи в Photoshop!
КОМУ ПОДОЙДЁТ
Дизайнерам интерьера, архитекторам, проектировщикам, студентам профильных ВУЗов. Курс будет полезен и тем, кто хочет научится работать в Photoshop быстро и уверенно, чтобы применять его в других областях.
ЧЕМУ НАУЧИТЕСЬ
За время практики вы освоите Photoshop на профессиональном уровне. Получите реальный опыт создания архитектурной подачи с нуля, и сможете применять полученные навыки на практике. Создадите 3 вида подачи: реалистичную, концептуальную и оформление плана.
Почему мы
Все наши преподаватели профессионалы, с большим опытом реализации жилых и общественных проектов. За годы практики мы разработали эффективную структуру обучения, которая позволяет быстро освоить необходимые программы на профессиональном уровне.
Преподаватели
Архитектор, визуализатор, преподаватель в МАРШе, работает с КБ Стрелка
Как проходит обучение
Смотрите видео в уроке
Можете заходить на обучающую платформу с любого устройства и заниматься когда вам удобно.
Выполняете задание
Задаёте вопросы по уроку и отправляете задание на проверку преподавателю.
Получаете обратную связь
Гордитесь итоговой работой
Завершаете обучение по курсу итоговой работой, доведя её до идеала вместе с преподавателем.
Читайте также: