Паттерны Архитектурного проектирования (v.1.0)(Archicad)

Небольшое вступление

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

Архитектура как отрасль очень сильно отстает от IT в плане инстурментов и методов разработки проектов. В IT давно есть среды разработки, а мы по прежнему создаем отдельные файлы и затем долго и нудно собираем их в один проект; ретроспективу после проекта некоторые основатели платных курсов называют своей уникальной методологией которую они придумали; и самое главное нету паттернов. Каждый раз в каждом проекте приходится подолгу объяснять одни и те же решения одних и тех же задач. И вот постепенно такая ситуация привела к решению, что пора сформировать/сформулировать эти самые паттерны для архитектурного проектирования. Прежде всего описанные ниже паттерны применимы к разработке в программе Archicad.


Перечень паттернов

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

Сборочные (или структурные)

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

  • Горизонтальная типовость

  • Вертикальная типовость

  • Компоновщик (или древовидная типовость)

  • Сам себе режисер

Преобразования элементов

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

  • Подмена (или заменитель)

  • Проводник

  • Тянущая привязка

  • Лосины (или натягивание на рельеф)

  • Единственный экземпляр

Координационные

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

  • Наблюдатель

  • Главный файл

  • Фантом

Вариантные

Определяют каким образом внутри проекта будут создаваться варианты

  • MODный вариант

  • Вариант через фильтр реконструкции (не придумал пока как короче назвать)

Подробное описание каждого

Горизонтальная типовость

Ссылка на файлы с примером реализации

Основной принцип - определение этажа как типа целиком

Задача: разбить по типовости большой многоэтажный комплекс. При этом часть элементов может повторяться с 5 по 24 этаж, часть только с 7 по 22, еще часть с 8 по 20.

Решение: распределяем типы буквально как идет повторение по этажам тип1 -> для 3-6, 23-24 этажей, тип2 -> 7,21-22 и тип3 -> 8-20

Плюсы: самая простая для понимания структура сборки. Минимум типовых этажей.

Минусы: будет много повторений элементов (ctrl+c, ctrl+v) и много лишней работы. В чистом виде дальше стадии ПП данный паттерн применять нецелесообразно, т.к. одно малейшее отличие и надо создавать другой тип с вытекающим дублированием огромного количества элементов. И каждый раз добавляя, изменяя элементы на одном типе - нужно будет повторить для идентичных элементов в другом типе

Схема:

Spoiler

Вертикальная типовость

Ссылка на файлы с примером реализации

Основной принцип - определение как типы отдельные группы повторяющихся элементов

Задача: такая же как и у предыдущего - разбить по типовости большой многоэтажный комплекс. При этом часть элементов может повторяться с 5 по 24 этаж, часть только с 7 по 22, еще часть с 8 по 20.

Решение: распределяем, дробим по повторяющимся группам элементов типы как тип1 -> для 3-24 этажей, тип2 -> 7-22 и тип3 -> 8-20, координация типов осуществляется через фоновую ссылку

Плюсы: нету повторяемости элементов. Относительно простая для понимания модель

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

Схема:

Spoiler

Компоновщик

Ссылка на файлы с примером реализации

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

Задача: такая же как и у предыдущего - разбить по типовости большой многоэтажный комплекс. При этом часть элементов может повторяться с 5 по 24 этаж, часть только с 7 по 22, еще часть с 8 по 20.

Решение: дробим по аналогии с Вертикальной типовостью. Создаем тип1 для частей, которые повторяются на 3-24, создаем тип2 для 7-22 и в него подгружаем уже готовый тип1, создаем тип3 для 8-20 и в него подгружаем уже готовый тип2

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

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

Схема:

Spoiler

Сам себе режиссер

Ссылка на файлы с примером реализации

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

Задача: собрать простую бим модель. Для упрощения архитектор сразу старается закладывать какую-нибудь типовость. Групп типовых элементов не так много, что бы создавать и выстраивать структуру из отдельных файлов.

Решение: создаем все в одном файле. У нас есть этажи основной модели (например с -1 по 5). Делаем небольшой отступ ниже ( -2, -3, -4) и начиная с -5го принимаем как этажи на которых будут располагаться типовые группы элементов. Затем эти типовые подгружаем в пространство основной модели. Таким образом получается, что файл вкладывается сам в себя. Сам себе служит .mod-ом

Схема:

Spoiler

Подмена

Ссылка на файлы с примером реализации

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

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

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

Настроить необходимо так: у элемента, которым собираемся вычитать - материал с максимальным приоритетом, вспомогательный слой, который будет скрыт (у нас для этого есть слой "Элементы выдавливания.ВСП"), уровень слоя выдавливания должен совпадать со слоями, на которых лежат целевые элементы в которых собрались делать подмену. Затем моделим то, чем хотим подменить. Эти элементы уже должны использовать слой с другим уровнем, чтобы их так же не вычло по приоритету материалов. В примере подмена реализована как отдельный мод.

Минусы: подходит только для декоративных элементов, инженерии и для локальной пробы вариантов на ранних стадиях проекта.

Схема:

Spoiler

Проводник

Ссылка на файлы с примером реализации

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

Задача: Есть собранная база юнитов (юнит - группа элементов, которые отстраиваются и специфицируются как один объект), например, перемычки или вентблоки. И нужно их затянуть в разные проекты. Глобально в базе, если жестко замаркировать, то в проектах в ведомостях могут получиться разбежности типа ВБ-01 ВБ-04. В каждом проекте используется разный набор вентблоков. Дублировать файл, чтобы перебить на свои, тоже не имеет смысла, т. к. в случае глобальных корректировок, дополнения или детализирования - нужно будет повторить всю работу.

Решение: В исходном файле, основном, в котором собраны все - типы не индексируем, а подгружаем его как связь в мод юнитов самого проекта. Маркировку будем обозначать и снимать с ID. Назначаем ID через "ID связи"(Master ID)

Схема:

Spoiler

Тянущая привязка

Ссылка на файлы с примером реализации

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

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

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

Минусы: Мы больше не можем использовать линию привязки как объективный параметр (напр. "длина линии привязки")

Схема:

Spoiler

Лосины

Ссылка на файлы с примером реализации

Натягивание на ральеф - набор последовательных действий для быстрого эскизного отстроения благоустройства (дорожек, площадок) по рельефу.

Задача: Быстро (не для Р), концептуально, но красиво отстроить все дороги, дорожки, площадки на рельефе. Вылепливать вершинами 3д сетки - долго.

Решение: В плане отмоделиваем все элементы генплана, которые нужно натянуть на рельеф. Назначяем им всем низ - ниже, чем самая низкая точка на рельефе (можно 1м, но лучше брать с запасом около 5м), высота - выше, чем самая верхняя точка на рельефе. Заходим в "операции твердотельного моделирования", все элементы благоустройства определяем как "целевые элементы", рельеф как "элементы оператора", Если рельеф имеет толщину (тело), то в операциях твердотельного моделирования выбираем параметр "пересечение", иначе параметр "вычитание с выталкиванием вверх", жмем "Выполнить", преобразовываем элементы в морф. Далее у нас есть 2 варианта. 1- поднимаем морфы на 20+мм над рельефом. 2- с помощью того же инстурмента вычитаем морфы из земли. Элементы благоустройства получаются как бы натянуты тонким слоем ровно по рельефу.

Примечание: Заметно только с ближних статичных ракурсов. Люмион и твинмоушен может некорректно понимать, что есть верх в такой натянутой дороге и машины/люди могут пойти по самому рельефу, как бы проваливаясь на несколько сантиметров в текстуры.

Spoiler

Единственный экземпляр

Ссылка на файлы с примером реализации

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

Задача: Отстроить типовые элементы колонн/пилонов, диафрагм жесткости, в которых нету проемов в многоэтажном ЖК (18+ этажей). Традиционный способ не очень эффективен с точки зрения использования ресурсов компа - колонна в высоту этажа и поехали по 10+ этажей тиражировать одинаковые модули.

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

Spoiler

Наблюдатель

Ссылка на файлы с примером реализации

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

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

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

Spoiler

Главный файл

Ссылка на файлы с примером реализации

Главный файл - основной файл, в котором собирается бим модель, пригоден для выпуска, и с которого возвращается как подложки PMK

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

Решение: выделяем в структуре проекта главный файл в котором будет собираться конечная модель из модели с планами + модели с фасадами. Для обратной связи выгружаем из главного файла PMK и затягиваем как подложки в модели планов и фасадов. Таким же образом главным файлом может быть объявлен файл модели планов или фасадов

Spoiler

Фантом

Ссылка на файлы с примером реализации

Фантом - способ координации двух моделей, при котором подложенные модели не существуют на тех этажах, на которых отображаются.

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

Решение: Отстраиваем модель фасада с параметрами отображение элементов "все релевантные этажи". Отстраиваем модель планов этажей с отображением элементов "все релевантные этажи". В одном файле (напр с фасадами) ниже этажей основной модели +несколько этажей для отступа набиваем структуру этажей идентичную основной модели, подгружаем на доп этажи все планы и вручную в 3д стягиваем на отметки в область основной модели. В другом файле проворачиваем то же самое с фасадами, но на этажах выше основной модели + несколько этажей для отступа.

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

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

Spoiler

MODный вариант

Ссылка на файлы с примером реализации

MODный вариант - способ создания вариантов путем вычленения изменяемой геометрии в отдельные .mod файлы, а затем подгрузки как связь.

Задача: В процессе разработки стадии П или ПП вам подкидывают идею/задание: "а давай это место попробуем сделать вот так". Получается, надо локально и быстро сделать другой вариант, при этом не запороть собранную модель и не перелопачивать всю структуру проекта.

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

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

Минусы: На переключение между вариантами уходит время

Spoiler

Вариант через фильтр реконструкции

Ссылка на файлы с примером реализации

Вариант в фильтре реконструкции - способ создания вариантов путем прикрепления элементов к конкретному фильтру реконструкции и отображения только в нем.

Задача: Такая же как в предыдущем. В процессе разработки стадии П или ПП вам подкидывают идею/задание "а давай это место попробуем сделать вот так". Получается надо локально и быстро сделать другой вариант, при этом не запороть собранную модель и не перелопачивать всю структуру проекта.

Решение: создаем фильтр реконстуркции "исходный вариант" и "вариант №…", скидываем все элементы, которые надо заменить на фильтр реконструкции "исходный вариант" или базовый, в котором разрабатывается основная модель. Для этого дела нам может пригодиться панель "Фильтры реконструкции". Варианты делаем с привязкой к фильтру конструкции "вариант №…."

Плюсы: быстрое переключение между вариантами; всё в одной модели

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

Spoiler

Ссылка на папку со всеми файлами с примерами на всякий случай

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 4

    0
    Архитектура как отрасль очень сильно отстает от IT в плане инстурментов и методов разработки проектов.

    Это точно. Недавно познакомился с одним архитектором (который дома проектирует, а не ПО), и перед встречей прям предвкушал, как узнаю у него, до каких вершин развился язык паттернов, выявленный Кристофером Александером в современной архитектурной отрасли (краткая справка: его работы явились побудительным мотивом для создания софтверных паттернов GoF), но с удивлением узнал, что ни о каких паттернах и ни о каком Кристофере Александере в их бюро и не слыхивали.
      0

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

        +1
        Вот так бы могло (у них даже обучающие матерьялы свои есть, которые показывают как фичей пользоаваться), но именно в «Архетиктурном BIM-CAD» я пока такого не встречал.
          0
          на данный момент ни одна из программ не предоставляет такой возможности, да и специфика командной работы немного другая. Максимум информации который пока доступен и только при работе в TeamWork через BimCloud — это логи о том кто, когда и на сколько кб произвел изменений. Но в том же TeamWork можно настраивать роли и права на редактирование

        Only users with full accounts can post comments. Log in, please.