Как начать разбираться в архитектуре
The Village продолжает пропагандировать эффективное самообразование. На этой неделе мы вместе с экспертами разбираемся, какие книги и журналы читать, что смотреть и где учиться, чтобы самостоятельно подкрепить свои сведения об архитектурных направлениях или подготовиться к получению соответствующего образования.
Александр Острогорский
преподаватель МАРШ, руководитель отдела образовательных программ Музея Москвы, архитектурный журналист
Архитектура вообще, как вообще музыка или вообще наука — слишком большое поле для интереса, чтобы указать только один подход к нему. Если только вашим первым шагом не становится именно это — изучение пространства архитектуры и поиск в нём своего интереса, своего любимого сюжета. Архитекторы и критики уже несколько сотен лет подряд начинают делать это с формулы, выдуманной римским архитектором Витрувием, который в I веке до н. э. написал свои «10 книг об архитектуре», в которых указал на три главных свойства архитектуры — пользу, прочность и красоту.
Хотя с тех пор прошло уже больше 2 тысяч лет, кажется, что лучшего определения не было придумано. Эти три критерия — и способ оценить любое здание, и направления для совершенствования собственной способности понимать архитектуру. То есть видеть, как одни здания одновременно и полезны, и прочны, и красивы (одно вытекает из другого), а другие здания — нет (впрочем, это не всегда однозначно плохо).
Мне пришлось встречаться с несколькими, возможно универсальными, мотивами, которые побуждают человека интересоваться архитектурой, — хотя, конечно, это только мой опыт. Но предпочту отталкиваться скорее от общечеловеческих представлений о том, что даёт архитектура или почему она важна, чем от порой очень разных взглядов самих архитекторов, структуры архитектурного образования или представлений критиков. Говорю об этом, чтобы заранее попросить прощения у тех читателей, чьи интересы окажутся вне схемы, которой я собираюсь воспользоваться, или же тех, у кого уже есть собственная или привычная для него схема, которая ему или ей кажется идеальной (а моя покажется еретической).
Итак, по отношению к архитектуре всех людей можно разделить на тех, кому…
…нравятся красивые вещи. Красота — наверное, самая сложная категория для архитектуры. Во-первых, архитектура — не миметическое искусство, то есть здания ничего не изображают (исключения встречаются, хотя и нечасто), так что «удовольствие от узнавания», которое Аристотель считал основой эстетического удовольствия, здесь не возникает. Как и в музыке, красота в архитектуре — это ритм, пропорции, отношения форм, цвета и материала.
Знаменитый немецко-английский историк архитектуры и критик Николас Певснер как-то сказал: «Навес для велосипедов — это строение, Линкольнский собор — архитектура». Иначе говоря, всякая архитектура — здание, но не всякое здание — архитектура. Сейчас уже найдётся немало охотников поспорить с этим утверждением, но некоторая доля правды в этой мысли есть: архитектура начинается там, где создатели здания — будь то известный архитектор или безымянные каменщики — попытались пойти дальше, чем решение практических задач.
Вопрос в том, куда именно они захотели пойти, почему и что придумали. На эти вопросы более или менее отвечает история и теория архитектуры. Каждая эпоха, каждая страна и традиция предлагала свои программы и наборы инструментов. Далеко не всё нам кажется интуитивно «красивым» сегодня — мы судим о египетских пирамидах совсем не так, как о памятниках Возрождения, а современная архитектура многим кажется однообразной и безликой.
Велик соблазн определить ценность зданий из одних эпох по отношению к зданиям из совсем других, особенно если они стоят рядом, как это бывает в городе. Что ж, вкус — дело каждого, одним нравятся колонны классических фасадов, другим — ленточные окна конструктивистских. Но нельзя забывать о том, что они являются результатом разных ситуаций, и мерить их одной меркой не совсем верно. Удивительно и другое (впрочем, так и с любым другим искусством) — чем больше узнаёшь о том, как думали и к чему стремились зодчие разных эпох, тем шире становится коридор индивидуальных вкусовых предпочтений.
…нравится история. Архитектура в большей степени, чем любое другое искусство, является живым свидетелем истории. Каждое здание — продукт своего времени, пересечение социальных, политических, культурных и технологических явлений. Расшифровать здание как послание в будущее, как запись в летописи — значит решить увлекательный ребус. Как ни странно, здесь предложенная Певснером формула работает скорее наоборот — невзрачные, утилитарные объекты говорят иногда о своём времени больше, чем шедевры архитектуры. Сравните хрущёвку и, например, Дворец пионеров на Воробьёвых горах — только вместе они могут дать правильное впечатление о советской культуре и жизни в 60-х. Чудом сохранившийся на Варварке Старый английский двор — по сути, палаты зажиточного горожанина XV века — лучше иллюстрирует московскую жизнь того времени, чем находящаяся совсем рядом Грановитая палата, построенная примерно в это же время для Ивана III итальянскими архитекторами.
…нравятся технологии.
Каждое здание — это ещё и решение инженерной, строительной задачки с большим количеством переменных: потребности человека, сила притяжения, свойства материалов, цена, навыки строителей и так далее. Иногда архитектор находит такое решение, которое не мешает эстетике, иногда — приходится бороться с технологией за художественный образ. Что лучше — красивое, но не слишком прочное или достаточно прочное, но не радующее глаз? Бывает и то и другое. Упомянутые выше хрущёвки, как и большая часть советского индустриального домостроения, — результат почти полной победы экономических и строительных технологий над эстетикой. Восхищающие многих выдающимися инженерными решениями проекты Сантьяго Калатравы постоянно упрекают в том, что они не так хорошо работают, как прекрасно выглядят, к тому же обходятся в астрономические суммы. Так или иначе, с конца прошлого века технологии и их возможности стали одной из главных тем архитектуры. Будь то строительство самых высоких зданий (таких как Бурдж-Халифа) или самых экологичных — сегодня для самых крупных архитектурных проектов в мире чаще всего именно технологии становятся основой эстетической программы.
…хочется понять, как устроен мир. Если архитектура помогает узнать о прошлом, то и о настоящем она говорит не меньше. Зачем нужны небоскрёбы? Кто позволяет сносить старые красивые здания и строить на их месте новые, уродливые? Почему одни живут в шикарных особняках, а другие — в трущобах? Все эти вопросы и многие другие, как ни странно, люди часто адресуют именно архитекторам, включая и вечное «кто придумал, скажи, эти пробки». При этом архитекторы имеют совсем не такое большое влияние на развитие города. Архитектура и конкретные здания — это иллюстрации, симптомы и указания на многие проблемы современного мира, а также лаборатория по поиску ответов на них. Если бы существовала клятва Витрувия (как клятва Гиппократа у врачей), то в ней непременно было бы записано, что архитектор обязан быть немножко врачом, учителем, психотерапевтом («разговаривайте с клиентом о его детях» — это совет немецкого архитектора-модерниста Миса ван дер Роэ), полицейским, политиком, экономистом и, конечно же, художником, инженером, строителем и так далее.
Что читать
Джейн ДЖекобс
«Смерть и жизнь больших американских городов»
Книга не об архитектуре, но о специфике городского планирования, немыслимого без учёта повседневных требований горожан. Написанный в 1961 году основной труд теоретика градопланирования Джейн Джекобс — классика жанра для будущих урбанистов и архитекторов.
Дэниел Брук
«История городов будущего»
Журналист Дэниел Брук посвятил книгу четырём относительно молодым городам, ставшим новаторскими для своих стран, четырём своеобразным «окнам в Европу» — Петербургу, Шанхаю, Мумбаю и Дубаю. На их примере он объясняет, как восточная культура движется на Запад.
Майкл Соркин
«Двадцать минут на Манхэттене»
Архитектор и критик Майкл Соркин препарирует урбанистическое пространство Нью-Йорка через свой ежедневный маршрут от дома до офиса, или, если быть точнее, от Гринвич-Виллидж до студии в Трайбеке.
Что интересно, он не только делится мыслями о переменах, случившихся на Манхэттене за 15 лет, но и описывает местных жителей и малоизвестные улицы.
Рем Колхас
«Мусорное пространство»
Одно из важнейших эссе именитого голландского архитектора, критикующего современную тенденцию наращивания масштабов зданий бизнес-центров в ущерб индивидуальному городскому ландшафту.
Роберт Вентури, Дениз Скотт Браун, Стивен Айзенур
«Уроки Лас-Вегаса. Забытый символизм архитектурной формы»
Одна из поворотных книг в истории западной архитектуры, как свидетельствуют опросы самих архитекторов. Три профессора Йельского университета в 1968 году вместе со студентами отправляются в Лас-Вегас — образец дурного градостроительного вкуса и китча. На ошибках Лас-Вегаса и родилась книга, ставшая манифестом постмодернизма.
Архитектура «1С:Предприятия» как продукт инженерной мысли
Сегодня практически каждый второй продукт человеческой деятельности, предлагаемый покупателю, имеет отношение к высоким технологиям.
А это значит, что он не только удовлетворяет конкретные потребности человека, но и является воплощением научной и инженерной мысли. Очевидно, что в некоторых случаях заложенные в продукт идеи и достижения, полностью определяют его сущность и потребительскую ценность.
В этой статье мы решили сконцентрироваться не на описании возможностей продукта «1С:Предприятия», а именно на технологических инновациях, которые в совокупности определили ряд совершенно новых технологий разработки бизнес-приложений и новых качеств самих этих приложений.
Сначала сделаем небольшое замечание по терминологии. Эта статья не ориентирована исключительно на тех, кто имеет дело с системой программ «1С:Предприятие». Как нам кажется, она может быть интересна многим специалистам, интересующимся развитием технологий экономических и корпоративных приложений, независимо от того с какими продуктами они работают. Поэтому в данной статье мы постараемся лишь в минимальном объеме использовать терминологию, специфическую для «1С:Предприятия».
Небольшое уточнение требуется по самому названию продукта. «1С:Предприятие» это система программ, включающая платформу и набор построенных на ее основе бизнес-приложений (прикладных решений), предназначенных для множества отраслей и предприятий разного масштаба. В данной статье мы будем говорить в основном о платформе, на которой строятся бизнес-приложения:
За что боремся
В начале хочется кратко определиться с тем, что считать основной целью создания таких технологий как платформа «1С:Предприятие». Если посмотреть на историю развития компьютеров и программирования, то можно заметить, что, наряду с повышением производительности, увеличением объемов обрабатываемой информации, повышением эргономичности и т. д. прослеживается достаточно четкое стремление к повышению уровня абстракции программных систем. Эта тенденция является в какой-то степени уникальным свойством, присущим именно компьютингу, тогда как в других областях человеческой деятельности стратегические цели развития носят более утилитарный характер.
Платформа и бизнес-приложения
Пожалуй, наиболее концептуальными в архитектуре «1С:Предприятия» являются само наличие платформы и понятие бизнес-приложения.
Разумеется, любая фирма-разработчик бизнес-софта имеет достаточно мощный инструментарий и набор технологий, с помощью которых строит свои решения. Однако, при разработке «1С:Предприятия» мы изначально ориентировались на создание полнофункциональной, целостной платформы, которая будет использоваться для построения самых разнообразных бизнес-приложений не только самой фирмой «1С», но и множеством других компаний-разработчиков, знакомых со спецификой тех или иных отраслей. Вот почему платформа изначально создавалась как тиражируемый продукт, включающий как все необходимые технологии для эксплуатации бизнес-приложений, так и инструменты для их разработки и модификации.
В «1С:Предприятии» было введено четкое разделение на платформу и бизнес-приложение. Платформа представляет собой так называемый framework, в котором функционирует бизнес-приложение. Мы не смогли найти точного перевода этого слова на русский язык. С одной стороны framework можно считать фундаментом для построения приложений, а с другой — средой исполнения.
Заметим, что понятие платформы и платформенно-ориентированного построения приложений сейчас является общепринятым и трактуется гораздо шире, чем просто способность работать в определенной операционной системе. Под платформой понимается среда исполнения и набор технологий, используемые в качестве основы для построения определенного круга приложений. Фактически, приложения базируются на нескольких платформах, образующих многослойный пирог. При этом важно, что платформа предоставляет разработчику определенную модель, как правило, изолирующую его от понятий и подробностей более низкоуровневых технологий и платформ. Такова и платформа «1С:Предприятие», позволяющая использовать самые разные технологии более низкого уровня, не меняя кода бизнес-приложений.
Например, она предлагает разработчику собственную модель работы с данными и изолирует его от особенностей конкретного хранилища данных, а это позволяет, не изменяя бизнес-приложение использовать в нем различные хранилища. К примеру, в качестве БД при решении задач небольшого масштаба может применяться собственный файловый движок, а для работы в масштабе предприятия — MS SQL Server.
Ключевым качеством платформы «1С:Предприятие», пожалуй, является достаточность ее средств для решения задач, стоящих перед бизнес-приложениями. Это позволяет обеспечить очень хорошую согласованность всех технологий и инструментов, которыми пользуется разработчик. Ведь часто именно наличие «швов» между различными технологиями становится причиной самых серьезных проблем. Простейший пример — система типов. В платформе «1С:Предприятие» разработчик использует одну систему типов данных и для взаимодействия с БД, и для реализации бизнес-логики, и для построения интерфейсных решений:
Поэтому у него нет проблем, связанных с преобразованием типов при переходах между разными уровнями прикладной системы.
Другим очень важным моментом является стандартизация. Наличие единой платформы для большого количества прикладных решений способствует формированию общего «культурного слоя», включающего и людей (программистов, аналитиков, пользователей) и методологию (типовые структуры данных, алгоритмы, пользовательские интерфейсы). Опираясь на этот «культурный слой», разработчик тратит минимум усилий на поиск необходимого решения, практически, в любой ситуации, начиная от включения в проект нового специалиста и кончая реализацией какой-либо подсистемы бизнес-приложения по типовой методологии.
Одним из существенных преимуществ четкого разграничения между платформой и бизнес-приложением является высокий уровень адаптируемости решений под требования клиента.
Следует заметить, что именно для экономических задач особо важна возможность эффективного изменения готового решения разработчиком, не участвовавшим в его создании. В индустрии разработки бизнес-приложений, в отличие от многих других областей, существенная часть разработчиков не создает программы «с чистого листа», а дорабатывает и развивает типовые решения.
Это обстоятельство определяет особые требования к обеспечению наглядности и простоте понимания разработчиком существующих решений и максимально учитывается во всех механизмах платформы.
Инструментальные средства «1С:Предприятия» представляют собой не некий дополнительный «toolkit», а являются неотъемлемой составляющей платформы. Они ориентированы в равной степени, как на разработку решений, так и на их адаптацию при внедрении на конкретном предприятии. Эти средства поставляются с каждым комплектом 1С:Предприятия и применяются как для внесения небольших изменений, например, в макет печатной формы, так и для существенной доработки прикладного решения включая структуры данных и бизнес логику. Возможности эффективного внесения изменений в приложение при его внедрении заложены в самих этих инструментах, а, кроме того, этому способствует и архитектура построения прикладного решения. В следующих разделах статьи мы постараемся проиллюстрировать данный тезис.
Выделение бизнес-приложения как самостоятельного элемента, фактически, позволило нам сформировать целую индустрию создания, распространения и поддержки разнообразных прикладных систем, концентрирующую свои усилия на специфике этого класса задач и не требующую глубокого понимания большей части технологических деталей и подробностей.
Метаданные — способ описания бизнес-приложения
В «1С:Предприятии» прикладное решение не пишется в прямом смысле на языке программирования. Язык программирования, конечно, используется, но только там где это действительно необходимо.
В основе бизнес-приложения лежат метаданные. Они представляют собой структурированное декларативное его описание. Метаданные образуют иерархию объектов, из которых формируются все составные части прикладной системы и которые определяют все аспекты ее поведения. Фактически, при работе бизнес-приложения платформа «проигрывает» (интерпретирует) метаданные, обеспечивая всю необходимую функциональность.
Метаданными описываются структуры данных, состав типов, связи между объектами, особенности их поведения и визуального представления, система разграничения прав доступа, пользовательский интерфейс и т.
д. В метаданных, фактически, сосредоточены сведения не только о том, «что хранить в базе данных», но и о том, «зачем» хранится та или иная информация, какова ее роль в системе и как связаны между собой информационные массивы. Использование языка программирования ограничено в основном решением тех задач, которые действительно требуют алгоритмического описания, например, расчета налогов, проверки корректности введенных данных и т. д.
Что дает такой подход к построению бизнес-приложения? Во-первых, при описании метаданных широко используется визуальное редактирование. Это позволяет свести существенную часть разработки к визуальному проектированию, не требующему кропотливого написания кода. Однако у данного подхода есть и другие не менее важные преимущества. Описывая прикладное решение в терминах метаданных, разработчик «сообщает» платформе много очень полезной информации, которую та может эффективно использовать в самых различных целях. На основе метаданных система автоматически «выстраивает» большую часть механизмов и объектов, обеспечивающих функционирование прикладного решения.
Например, описания метаданных платформе достаточно для того, чтобы автоматически сформировать пользовательский интерфейс системы, обеспечивающий ввод и редактирование взаимосвязанной информации. Другой пример — возможность построения даже конечным пользователем, не имеющим навыков программирования, достаточно сложных отчетов.
Идеология использования метаданных в самых общих словах сводится к простому тезису: «Давайте не будет программировать все функции разрабатываемого решения. Расскажем платформе о составе, структуре, особенностях и взаимосвязи различных его частей, и пусть остальное она сделает сама».
Эта идеология (Metadata Driven) сегодня находит все большее применение во многих перспективных разработках.
Построение приложения на основе модели
В «1С:Предприятии» изначально заложена строгая ориентация на построение прикладного решения на основе определенной модели.
Этот подход является весьма перспективным и по нашей оценке будет доминирующим в обозримом будущем в современных средствах разработки.
Идеи построения бизнес-приложений на основе модели, например, нашли воплощение в архитектуре MDA (Model Driven Architecture) консорциума OMG.
Под моделью понимается вся идеология построения прикладного решения. Сюда относятся способы построения структур данных, типы связей между данными, принципы манипулирования данными, формы описания бизнес-логики, способы связи данных с интерфейсными объектами, разделение функциональности по уровням системы и многое другое.
Важно, что все бизнес-приложения неукоснительно следуют принятой модели и этим обеспечивается единообразие и предсказуемость их поведения. Фактически, разработчик, желающий отразить в прикладном решении специфику той или иной предметной области, имеет вполне определенный набор способов решения этой задачи средствами, заложенными в платформу. С одной стороны, такой подход ограничивает (вполне осмысленно) свободу разработчика, но с другой — защищает его от множества ошибок и позволяет в сжатые сроки получать работоспособное решение, которое сможет в дальнейшем развиваться и поддерживаться как им самим, так и, при необходимости, другим специалистом.
Очевидным следствием этого подхода является изоляция разработчика бизнес-приложения от деталей технологий хранения информации, организации трехуровневой архитектуры и т. д. Например, как уже отмечалось выше, все прикладные решения, базирующиеся на «1С:Предприятии», без каких-либо изменений работают как с собственным файловым движком БД, так и с сервером БД. При этом необходимые структуры данных создаются и изменяются системой автоматически на основе описания метаданных, и разработчику не приходится вникать в детали форматов хранения конкретных СУБД. Манипулирование данными в приложении также описывается в высокоуровневой модели и автоматически исполняется с учетом особенностей используемого хранилища.
По нашей оценке, предоставление разработчику определенной модели, абстрагированной от конкретных используемых средств, будет доминирующим в обозримом будущем в современных средствах разработки.
Наличие единой модели ключевым образом сказывается и на простоте освоения системы. Вся разработка ведется в рамках одной сквозной системы понятий и в едином пространстве типов данных. У разработчика не возникает необходимости осваивать несколько моделей представления и тратить усилия на реализацию переходов между ними на разных уровнях.
Например, описание в метаданных тех или иных объектов (сущностей) сразу определяет и соответствующие типы встроенного языка программирования и необходимые для их хранения структуры БД. Все последующие манипуляции этими объектами, как в памяти, так и в БД выполняются единообразно, не требуя преодоления «барьеров» между различными нотациями, принятыми при работе с СУБД и с универсальными языками программирования.
Управление данными
Одним из ключевых отличий бизнес-приложений от программ иного назначения является парадигма, используемая в них для манипулирования данными.
Очевидно, что для экономических задач работа с данными является основным содержанием с одной стороны и наиболее проблемным вопросом с другой.
Это можно объяснить тем, что если во многих областях создания программных систем уже достигнут уровень, при котором программные продукты «близки к совершенству» (например, в текстовых процессорах), то в области экономического софта до этого, мягко говоря, далеко.
Экономические прикладные системы постоянно находятся «под гнетом» противоречивых требований. С одной стороны необходимо обрабатывать большие объемы данных, а с другой — обеспечивать широкую функциональность и высокую производительность. Объемы обрабатываемых данных растут, растут требования к разнообразию решаемых задач, и повышаются требования к масштабируемости. Не следует забывать и о повышении удобства разработки, эргономичности систем, возможностях их обновления и доработки и т. д. В современной мировой практике существует несколько парадигм манипулирования данными, которые используются в средствах разработки бизнес-приложений в различных комбинациях. При этом до идеала еще далеко — все имеющиеся и создаваемые технологии являются компромиссными решениями, нацеленными на улучшение показателей систем по нескольким указанным критериям.
Разумеется, эти противоречия касаются всех аспектов системы, но на способах манипулирования данными они проявляются наиболее ярко.
В современной мировой практике существует несколько парадигм, которые используются в средствах разработки бизнес-приложений в различных комбинациях.
В «1С:Предприятии» используется смешанный подход, который с одной стороны имеет много общего с подходами, заложенными в перспективных разработках других фирм, но с другой стороны обладает и существенными отличиями.
Для всех операций модификации данных (создания, изменения и удаления) в «1С:Предприятии» применяется исключительно объектная техника. Это означает, что разработчик взаимодействует с БД не на уровне записей, а с помощью объектов, соответствующих хранимым в БД сущностям. Для изменения хранимых данных, ему не нужно писать сложные запросы и преобразовывать результаты их обработки в объекты языка программирования. Достаточно получить объект из базы данных, изменить его свойства и снова сохранить.
Разработчик имеет при этом возможность написать обработчики событий, связанных с изменением данных, выполняя с их помощью различные проверки и изменяя при необходимости другие данные. Система обеспечивает эффективную технологическую поддержку объектного подхода, осуществляя, например, кэширование объектов, контроль объектной и ссылочной целостности и т. д. Для чтения данных может использоваться как объектная техника, так и декларативный язык запросов, который основывается на классическом SQL, но имеет ряд существенных расширений. Расширения направлены с одной стороны на поддержку работы с объектами, хранящимися в базе данных, а с другой — на эффективное решение экономических задач. Ниже мы рассмотрим язык запросов более подробно:
Одним из ключевых преимуществ объектно-реляционной парадигмы управления данными является наглядность и простота разработки приложений. Объектная техника, используемая в основном для модификации данных, обеспечивает очень хорошую читаемость алгоритмов бизнес-логики, существенно уменьшает количество ошибок при разработке, а также обеспечивает высокий уровень целостности данных.
Кроме того, важной особенностью объектной техники является то, что она, благодаря строгой гранулярности манипулирования данными, упрощает переход к распределенным и интегрированным системам.
Декларативное описание запросов, в свою очередь, позволяет получать сколь угодно сложные выборки данных и предоставляет мощные возможности агрегирования, необходимые для решения аналитических задач.
По нашему мнению такая смешанная техника в том или ином виде начнет в обозримом будущем достаточно широко использоваться в перспективных разработках экономических систем.
Здесь, немного забегая вперед, следует сказать, что в модели «1С:Предприятия» реализована наиболее современная концепция работы с информацией, сочетающая три способа представления данных — хранение сущностей в базе данных, их представление в языке программирования в виде объектов и отображение в формате XML. Фактически любая информация может в зависимости от текущего режима работы представляться одним из этих трех способов.
Долговременное хранение сущностей (persistence) осуществляется в БД, что обеспечивает надежность и эффективную обработку больших объемов информации. Для внесения изменений, данные предварительно преобразуются в объекты встроенного языка. При внутреннем обмене в распределенной БД или взаимодействии с другими информационными системами данные переносятся в формате XML:
Заметим, что все три способа представления опираются на единую систему понятий и от разработчика не требуется усилий для трансформации данных из одного способа представления к другому.
Такой подход позволяет органично вписывать «1С:Предприятие» в будущие гетерогенные решения, которые по нашей оценке (и она совпадает с оценкой многих экспертов) получат со временем самое широкое распространение.
Одной из отличительных особенностей модели «1С:Предприятия», не имеющей, как нам кажется, прямых аналогов в других подобных системах является деление всех прикладных данных на те, что имеют объектную природу и не имеющие таковой.
Заметим, что для манипулирования и теми и другими используется объектная техника.
Такое деление, соответствует реальной природе данных. В предметной области всегда есть сущности, имеющие объектную природу, например, «клиенты», «физические лица», «товары». Здесь объект имеет определенную «самодостаточность» не зависящую от данных, которые его описывают. Например, у человека может поменяться фамилия, имя и номер паспорта, но нам важно знать, что это именно то же самое физическое лицо (уникальный объект). С другой стороны есть сущности, не имеющие объектной природы. Например, запись о приходе некоторого товара на некоторый склад является лишь информацией о движении товара и не имеет никакого другого содержания, кроме того, что зафиксировано в записи. Если заменить в такой записи один товар на другой, смысл записи о товародвижении полностью изменится. Иными словами, для такой сущности запись без указания конкретных значений полей не имеет никакого смысла.
В результате такого смыслового разделения сущностей платформа «1С:Предприятие» фактически предлагает разработчику готовую методологию для наиболее естественного решения различных задач манипулирования данными в соответствии с природой этих сущностей.
Работа с объектными сущностями поддерживается представлением сущностей базы данных в виде объектов встроенного языка программирования, а также специальными типами данных, служащими для представления объектных ссылок (ссылок на объекты базы данных). При этом, зная объект, легко получить его ссылку, а, зная ссылку, извлечь из БД объект. Такая техника обеспечивает наглядный и естественный способ описания в исходном коде алгоритмов бизнес-логики, манипулирующих объектами, а, кроме того, гарантирует логическую целостность данных при любых операциях. Она напоминает написание приложений объектных БД, с той лишь разницей, что сохранение данных происходит в таблицах реляционной СУБД. При этом в модулях, написанных на встроенном языке, может одновременно присутствовать несколько объектов, представляющих одну сущность БД.
Механизмы платформы обеспечивают поддержку уникальных объектных идентификаторов (ссылок), контроль версий объектов, пессимистическую и оптимистическую их блокировку.
Оптимистическая блокировка гарантирует логическую целостность изменения объектов, а пессимистическая позволяет организовывать одновременное редактирование пользователями одних и тех же объектов в интерфейсе «1С:Предприятия». Платформа оптимизирует операции считывания объектов за счет использования механизма их кэширования как внутри транзакций, так и вне их. При модификации объектов реализована технология «умной записи»: система следит за их изменениями и реально записывает на диск только модифицированные данные, обеспечивая, тем не менее, целостность данной операции.
Работа с необъектными сущностями осуществляется с помощью наборов записей, представляющих собой по сути коллекции записей. Такие наборы поддерживают чтение и модификацию данных с требуемой для прикладной логики гранулярностью.
Важно, что оба указанных подхода позволяют придерживаться простого и естественного стиля написания алгоритмов бизнес-логики. Разработчик, которому необходимо модифицировать имеющуюся в приложении бизнес-логику, читая такой алгоритм, быстро понимает суть дела и может легко производить отладку и корректировку исходного кода.
Теперь для взаимодействия с базой данных разработчику не приходится самому программировать сложные преобразования информации из объектных структур в реляционные, что заметно повышает эффективность создания и отладки ПО.
Еще одной важной особенностью объектной техники, принятой в платформе «1С:Предприятие», является то, что те же объекты, которые присутствуют в модулях на встроенном языке (как для объектных, так и для не объектных сущностей) используются и для отображения данных в интерфейсе. Элементы управления форм непосредственно связываются с нужными объектами, и обеспечивают их отображение и редактирование пользователем без какой-либо помощи со стороны разработчика.
Для объектных сущностей платформа «1С:Предприятия» поддерживает механизм представлений. Он отвечает за отображение в интерфейсе значений, заданных ссылками на сущности базы данных. При необходимости отобразить ссылочное значение система автоматически формирует представление на основании свойств метаданных, оптимизируя, по возможности, получение информации из БД с помощью кэширования и других механизмов.
В процессоре обработки запросов и построения отчетов также широко используются представления. Это позволяет универсальным образом получать представления ссылочных полей, если запрос формируется для отображения данных в пользовательском интерфейсе, и автоматически включать отображения представлений в отчеты для полей, содержащих ссылочные значения. Важно, что механизм представлений дает возможность разработчику просто и естественно манипулировать объектными ссылками, минимизируя в то же время число обращений к БД.
Наряду с описанными выше методами манипулирования данными и формирования запросов, система предлагает еще один способ доступа к данным — динамические выборки. Этот механизм позволяет обращаться к очень большим объемам данных, обеспечивая считывание информации порциями. При этом разработчик, только указывает, какие данные необходимо получать, а система автоматически выполняет обращения к БД с необходимой гранулярностью. Важно, что для решения этой задачи не используются какие-либо специфические средства динамического считывания конкретной СУБД, требующие удержания в памяти открытой выборки, а осуществляется автоматическое формирование запросов, последовательно выбирающих блоки записей.
Еще одним важным решением в части работы с данными в «1С:Предприятии» является поддержка в полях таблиц составных типов данных. Эта возможность, насколько нам известно, не имеет близких аналогов в других системах. При описании типа поля какого-либо объекта можно выбрать не только один из доступных типов, но и практически любую (с некоторыми ограничениями) их комбинацию. Например, в поле «Плательщик» в документе, отражающем операцию с банком, допускается хранение ссылки на юридическое или физическое лицо в зависимости от конкретной операции. Хотя приведенный пример является достаточно простым, возможность работы с составными типами позволяет решать такие задачи, как хранение произвольных характеристик товаров, ведение аналитического учета на бухгалтерских счетах по любому составу аналитических разрезов, настраиваемых пользователем и т. д. Важно, что система не просто предоставляет возможность хранения в одном поле разнородных значений, а делает это прозрачным для разработчика способом.
Прежде всего, необходимо отметить полную поддержку работы с полями составных типов «движка» базы данных и языка запросов. Для этих полей поддерживается весь набор стандартных операций (сравнение, агрегирование и т. д.). Другим важным моментом является поддержка составных типов в интерфейсных механизмах системы. Например, поле ввода, связанное с данными такого составного типа, предоставляет весь набор возможностей редактирования (выбор типа; редактирование значений всех типов, входящих в указанное поле; ограничение выбираемых типов).
Отдельного внимания заслуживают также средства формирования запросов «1С:Предприятия». Мы уже упомянули, что они основаны на конструкциях стандартного языка SQL, но имеют ряд существенных расширений.
Прежде всего, следует отметить поддержку в языке запросов объектов, хранящихся в БД. Все операторы языка запросов обеспечивают работу со ссылочными типами (полями, хранящими ссылки на объекты БД). Например, поддерживается обращение к полям в нотации «через точку» без ограничения количества уровней.
Можно указать в запросе выборку такого поля, как «Товар.Производитель.Страна.Наименование». Для объектов базы данных допускается обращение к вложенным таблицам и как к отдельным таблицам, и как к обычным полям объекта, содержащим коллекции записей.
Другим важным качеством является штатная реализация функции формирования многомерных итогов с произвольным порядком обхода измерений. При этом доступны такие возможности, как сочетание многомерного обхода измерений и многоуровневого обхода иерархии значений каждого измерения (например, многоуровневой структуры подразделений или многоуровневой группировки товаров). Поддерживается также ряд специальных режимов обработки итогов.
Механизм запросов способен на основании свойств прикладных объектов, определенных в метаданных, упорядочивать выборки автоматически. Это позволяет разработчику при создании запроса, предназначенного для получения отчета или визуализации данных, не указывать, по каким полям производить упорядочивание, а, включив автоматический режим, получить стандартную для выбираемых данных сортировку.
Еще одним мощным средством механизма запросов являются виртуальные таблицы. Они обеспечивают доступ к производным данным, предоставляемым различными прикладными подсистемами, не требуя для этого написания сложных запросов. Например, можно обратиться к виртуальной таблице для получения распределения остатков и оборотов товаров по складам и номенклатуре, а также по календарным периодам. Следует отметить, что работа с виртуальными таблицами не является аналогом простого хранения типовых запросов (view). При использовании виртуальных таблиц разработчик указывает набор параметров, описывающих необходимую выборку, беря в их качестве не только конкретные значения, но и, например, сложные условия. Разработчик прикладного решения работает с виртуальной таблицей, практически, так же как и с обычной, но система формирует запрос к БД таким образом, чтобы обеспечить максимальную эффективность. В частности, при обращении к данным, обрабатываемым учетными механизмами, могут использоваться хранимые ими промежуточные итоги.
Стандартные прототипы прикладных объектов
Если говорить о различиях моделей бизнес-приложений и средств их разработки то, пожалуй, наиболее существенным окажется то, в каких понятиях (можно даже сказать «в какой парадигме») описывается приложение. Разумеется, в каждом средстве разработки может использоваться несколько способов описания, но какой-то один набор понятий всегда является основополагающим.
В качестве примеров существующих подходов можно привести описания в терминах реляционных таблиц, классов объектного языка программирования, сохраняемых сущностей (Entity Persistent) и т. д.
В модели разработки «1С:Предприятия» используется подход, которому мы не нашли явного аналога в других системах. Здесь все прикладное решение описывается метаданными в виде совокупности прикладных объектов, выбираемых из жестко определенного набора прототипов (классов). Можно было бы назвать создаваемые объекты бизнес-компонентами, а их прототипы шаблонами (patterns).
Каждый такой прототип отвечает за отражение вприкладном решении определенной совокупности объектов или процессов предметной области, имеющих схожие поведенческие характеристики и сходную роль в общей картине решения.
Примерами таких прототипов в «1С:Предприятии» являются «Справочники», «Документы», «Регистры накопления». Каждый прототип имеет некоторую базовую реализацию, которая определяет особенности функционирования, создаваемых на основе данного прототипа объектов: структуру хранимых сущностей вместе с некоторыми предопределенными полями, набор типов языка программирования, методы, свойства и события, а также типовые для решаемой задачи операции, способы отображения и редактирования, методы регулирования прав доступа и т. д.
Если в ходе разработки необходимо создать объект, отражающий особенности предметной области, программист выбирает подходящий прототип и создает на его основе объект метаданных. Далее он может задать различные свойства, определяющие особенности поведения объекта, основанного на этом прототипе, дополнить при необходимости структуру данных объекта, реализовать необходимый набор методов, определить обработчики событий, уточнить способы отображения объекта в интерфейсе и т.
д.
Для простых объектов такое доопределение может не потребоваться совсем, и вся процедура создания объекта будет сведена к указанию его имени в свойствах метаданных. В более сложных случаях разработчик имеет возможность достаточно подробно определять и структуры данных, и алгоритмы бизнес-логики, но при этом стандартная функциональностьреализуется автоматически без каких-либо усилий с его стороны.
Важно, что количество таких прототипов в платформе не велико, около двух десятков: их легко изучить, с тем, чтобы впоследствии эффективно применять для решения любых задач предметной области.
Таким образом, структура метаданных «1С:Предприятия» является не просто набором описаний объектов в определенных унифицированных терминах. Все прикладное решение, фактически, состоит из объектов, четко разделенных по тем ролям, которые они играют в бизнес-приложении. Такой подход существенно усиливает эффект и от описания системы в терминах метаданных, и от построения приложения на основе модели.
Наличие у объектов, описанных метаданными, стандартной функциональности и предопределенной роли позволяет системе автоматически решать гораздо более широкий круг задач, возлагаемых как непосредственно на эти объекты, так и на общие механизмы, работающие с ними. Фактически, зная о назначении (роли в прикладном решении) того или иного объекта, платформа сама, без какого-либо участия программиста, обеспечивает для него в любой ситуации соответствующий «индивидуальный подход». Например, механизм форм «знает», как лучше редактировать те или иные данные, а стандартный механизм отчетов может автоматически «подстроиться» с тем, чтобы проводить анализ информации наиболее эффективно.
Использование предопределенных прототипов обеспечивает стандартизацию модели построения прикладных решений. Такая стандартизация, возможно, не очень существенна для одного отдельно взятого бизнес-приложения, но она имеет огромное значение при создании индустрии разработки и поддержки множества прикладных решений.
Стандартизация позволяет существенно упростить задачи проектирования и в несколько раз снижает сложность и трудоемкость сопровождения. Например, если необходимо подключить к проекту еще одного специалиста или передать другому сотруднику поддержку и развитие решения, новый разработчик может после беглого просмотра структуры метаданных буквально за несколько минут составить общее представление о строении и основной функциональности прикладного решения, так как в структуре метаданных все прикладные объекты сгруппированы по принятым в модели «1С:Предприятия» функциональным ролям. В дальнейшем он сможет также быстро разбираться в устройстве и бизнес-логике отдельных подсистем. По опыту эти показатели существенно отличаются от тех, которые достигаются при использовании других подходов к описанию приложения.
Прикладные объекты и механизмы
Выше мы описали только принцип построения прикладного решения, основанный на использовании стандартных прототипов прикладных объектов.
Разумеется, здесь не место для подробного описания всех имеющиеся прототипов.
Но ниже, чтобы продемонстрировать те идеи, которые заложены в имеющуюся модель построения бизнес-приложения, мы дадим краткий обзор прототипов и предоставляемых ими возможностей.
Сначала мы приведем примеры достаточно простых прототипов — справочников и документов. Справочники описывают каталоги, содержимое которых более или менее постоянно. Это может быть перечень выпускаемой продукции, список клиентов компании, перечень валют и т. д. Справочники обеспечивают поддержку иерархических структур, позволяют относить данные к к отдельным объектам и их группам, предоставляют ряд других сервисных возможностей.
Документы отражают в системе события, происходящие в жизни предприятия: поступление материалов, перечисление денег через банк, прием сотрудника на работу и т. д. Этот прототип обеспечивает их отражение в различных учетных механизмах, поддерживает контроль последовательности обработки событий, реализует сквозную нумерацию объектов разного типа и т. д.
Остановимся немного подробнее на некоторых возможностях этих двух прототипов.
Известно, что классическая реляционная модель не имеет готовых средств для поддержки иерархии данных и ее реализация всегда требует кропотливой работы. Справочники (а также некоторые другие прототипы прикладных объектов «1С:Предприятия»), поддерживают многоуровневую иерархию изначально. Включается этот механизм простой активизацией соответствующего свойства в метаданных. При этом поддержка иерархии распространяется сразу на все аспекты использования прикладного объекта. Например, прототип обеспечивает поддержку необходимых свойств и методов в объектной модели манипулирования данными (определение уровня объекта, контроль зацикливания иерархии и т. д.). В интерфейсных механизмах реализуется представление данных в виде иерархического списка или дерева с навигацией по уровням и интерактивным изменением иерархии. В механизмах отчетов обеспечивается формирование иерархических документов такого рода и получение многоуровневой иерархии итогов в любых отчетах, в которых объекты этого типа, выступают, в качестве параметров для группировки.
Другим примером штатных возможностей прототипов является поддержка механизма проведения документов. Этот механизм предлагает разработчику стандартную модель организации связи между информацией о событиях, происходящих на предприятии, и различными учетными механизмами. Любая вводимая пользователем в виде документов информация может отражаться в любых учетных механизмах (планировании, управленческом учете, бухгалтерском учете и т. д.). Разработчик должен только указать в свойствах метаданных связь между документами и учетными механизмами, а также описать алгоритм проведения документа. Все необходимые действия по проведению и отмене проведения система будет выполнять автоматически. При этом системой предоставляются дополнительные возможности, такие как поддержка отражения событий в реальном времени, поддержка восстановления последовательности отражения событий, происходящих на предприятии, при изменении их задним числом и т. д. В результате предоставляется единая модель связи исходных данных и учетных механизмов, которая не просто облегчает разработку, но и обеспечивает единообразноепредсказуемое поведение всех прикладных решений, что существенно облегчает их освоение и поддержку.
Весьма интересными являются прототипы объектов «1С:Предприятия», применяемые в механизме сложных периодических расчетов. Этот механизм можно рассматривать как универсальный инструмент для решения задач расчета зарплаты любой сложности. На самом деле, расчет зарплаты является наиболее типичным применением данного механизма, но сам механизм не имеет ориентации именно на эту задачу и успешно используется для решения других задач, требующих описания периодических расчетов со сложными взаимосвязями, например, расчета дивидендов, стоимости коммунальных услуг и т. д. Он содержит набор типовых стратегий, примером которых может служить вытеснение одних видов расчетов другими при их пересечении на шкале времени. Применительно к задаче расчета зарплаты эта возможность решает весь комплекс проблем, связанных с пересекающимися по времени начислениями и удержаниями, для которых определены сложные правила взаимного исключения. Другим примером является возможность установки взаимосвязи между различными видами начислений и удержаний по периоду действия.
Таким образом, механизм представляет определенную математическую модель, устанавливающую связи между различными видами расчетов и предоставляет разработчику действующие на основе этой модели механизмы обработки информации.
Не углубляясь далее в подробности этого механизма, стоит отметить, что он позволяет полностью описать схему расчета зарплаты на основании предоставляемых прототипов прикладных объектов и заложенных в них возможностей. На примере данного механизма можно достаточно наглядно продемонстрировать эффект от использования предлагаемого подхода. Мы не имеем на данный момент информации о наличии в каком-либо средстве разработки экономического софта подобного механизма. Во всех известных нам случаях модуль расчета зарплаты (Payroll) реализуется ценой достаточно больших затрат и на проектирование и на реализацию. Причем этот модуль приходится существенно или полностью переписывать для каждой страны, так как он сильно привязан к местному законодательству. Применение механизма сложных периодических расчетов в «1С:Предприятии» позволяет перевести разработку такого модуля от проектирования «с чистого листа» к реализации по стандартной схеме.
По нашей оценке это сокращает затраты на порядок, но самое главное, существенно упрощается внесение изменений в процессе поддержки системы.
Еще одним характерным примером служит механизм характеристик, предназначенный для решения задач, которые плохо согласуются с классической реляционной моделью базы данных. Одной из таких задач, является построение структуры для отражения разнообразных свойств (характеристик) номенклатуры товаров или изделий. Если создается решение для одной организации с четкой ориентацией на определенную группу товаров, то все необходимые реквизиты можно заложить непосредственно в структуру каталога товаров. Например, для дилерской фирмы по продаже автомобилей ими будут цвет, объем двигателя и т. д. Однако если создается тиражное бизнес-приложение, или решение для организации, занимающейся производством или продажей разнообразной номенклатуры, этот вариант не подходит, так как очевидно, что состав характеристик должен зависеть от конкретной группы номенклатуры и добавление каждой новой группы не должно сопровождаться доработкой прикладного решения.
Очевидно, что реализация такого решения плохо ложится в реляционную структуру и требует особого подхода. Реализованный в «1С:Предприятии» механизм характеристик предоставляет разработчику типовое средство решения подобных задач. Специализированный прототип предназначен для организации хранения списка видов характеристик. При этом каждому такому виду приписывается свой тип данных. Например, объем двигателя будет задаваться числом, а цвет выбираться из справочника. Важно, что конкретные виды характеристик могут не только определяться в самом приложении, но и добавляться пользователем в процессе эксплуатации системы без изменения прикладного решения. При этом разработчик может задействовать данный механизм в самых различных ситуациях, например, для хранения логически связанных комбинаций характеристик номенклатуры и расчета себестоимости в разрезе имеющихся комбинаций.
Еще одним интересным решением является механизм бизнес-процессов (work-flow), позволяющий разработчику организовать совместную работу пользователей при выполнении типовых последовательностей деловых операций.
Во многих существующих информационных системах для решения задач work-flow используются специализированные продукты, которые приходится интегрировать с приложениями, решающими экономические задачи. В платформе «1С:Предприятие» механизм бизнес-процессов полностью интегрирован в систему таким образом, что ни разработчик ни пользователь не видят «швов» разделяющих этот механизм и другую функциональность. Этот механизм включает средства для описания в прикладном решении схем бизнес-процессов, и их ролевой маршрутизации, для формирования заданий, выполняющихся в каждой точке маршрута, для управления бизнес-процессом и организации его связи с другими функциями прикладного решения.Данный механизм предоставляет разработчику гибкие возможности управления ветвлением процесса и формирования задач. Например, кроме обычного условного ветвления разработчик может визуально описать параллельное прохождение нескольких веток маршрута, и указать точку их слияния. Допускается направление одного задания группе потенциальных исполнителей, например, если выписать счет должен один из менеджеров отдела.
И наоборот, в некоторой точке маршрута можно инициировать несколько заданий, например, если финансовые отчеты должны представить все руководители отделов. Ролевая маршрутизация позволяет формировать задачу не только непосредственно конкретному сотруднику, но и распределять задачи по ролям, подразделениям и другим критериям, которые может описать разработчик прикладного решения. При осуществлении ролевой маршрутизации разрешается указывать текущее распределение обязанностей сотрудников с учетом временных замещений, совмещений нескольких должностей и т. д. Важно отметить, что данный механизм предлагает готовую стратегию автоматизации совместной деятельности работников предприятия. Для описания простейших бизнес-процессов достаточно визуального задания схемы маршрута и указания условий ветвления в их узловых точках. Все остальные действия выполняются системой автоматически. При реализации сложных бизнес-процессов усилия разработчика требуются в основном для тесной их увязки с функциями прикладного решения.
На приведенных примерах мы продемонстрировали, что каждый из прототипов прикладных объектов и объединяющих их механизмов закрывает определенную область задач предметной области существенно снижая затраты на разработку и, что очень важно, обеспечивая стандартизацию прикладных решений.
Чтобы дать представление о спектре инструментов предоставляемых разработчику, ниже мы кратко опишем еще несколько механизмов.
Так, для решения задач, связанных с учетом наличия и движения средств (материальных и денежных), предлагается механизм регистров накопления.
Он поддерживает многомерную систему учета с произвольным составом измерений и ресурсов и обеспечивает оптимизацию получения итогов на различные моменты времени, тем самым позволяя эффективно решать задачи материального учета, производственного и финансового планирования, расчета с контрагентами и т. д.
Механизм бухгалтерского учета представляет собой универсальный «движок» для решения задач автоматизации бухгалтерского учета в различных моделях счетоводства.
Он может использоваться в различных странах и имеет большой запас гибкости для дополнительной настройки. В его основе лежит принцип двойной записи, причем допускается работа с финансовыми транзакциями (операциями), включающими как простые корреспонденции (один дебет и один кредит), принятые в российском учете и в моделях учета некоторых других стран, так и сложные, применяемые в большинстве западных стран (несколько дебетов и несколько кредитов).
Механизм поддерживает многомерную систему учета с произвольным составом измерений и ресурсов. Уникальным его свойством является возможность настройки состава дополнительных измерений независимо для каждого счета. При этом допускается формирование состава измерений как разработчиком при создании прикладного решения, так и пользователем в процессе работы с системой. Многоуровневые и многомерные итоги в разрезе периодов, перекрестных корреспонденций и т. д. генерируются автоматически.
Механизм сведений предназначен для решения задач, связанных с хранением разнообразной информации об объектах в различных разрезах.
Например, данные о ценах на товары могут храниться в разрезе их номенклатуры, категорий клиентов и т. д. При необходимости может поддерживаться хранение истории внесенных изменений, что позволяет получать наряду с актуальными данными, еще и их значения на любой прошедший момент времени. Механизм обеспечивает всю логику работы с хранимыми сведениями, начиная от манипулирования данными до их автоматического контекстного отображения в пользовательском интерфейсе.
Еще раз подчеркнем, что в модели «1С:Предприятия» прикладные механизмы и лежащие в их основе прототипы — это не просто набор шаблонов, которые разработчик может использовать «по мере надобности». Всё прикладное решение с необходимостью основывается на использовании предлагаемого набора прототипов.
Этого, достаточно компактного, набора вполне хватает, чтобы закрыть все потребности предметной области. Имеющимся набором прототипов система фактически навязывает разработчику стандартную модель проектирования, и это позволяет, по нашей оценке, существенно снизить затраты на построение и поддержку прикладных решений.
Высокоуровневая модель интерфейса
Очевидно, что для бизнес-приложения вопрос организации пользовательского интерфейса имеет особое значение. Во-первых, потому, что для существенной части пользователей эти приложения являются основным инструментом, и такие пользователи работают с ним большую часть дня, не являясь зачастую профессиональными пользователями компьютера. Во-вторых, интерфейс бизнес-приложений обычно очень «объемный». В отличие от многих других классов систем бизнес-приложения, как правило, содержат от нескольких сотен, до нескольких тысяч форм. Кроме того, эти формы могут периодически меняться, например, в ходе развития системы или при необходимости изменения бизнес-логики. Соответственно, затраты на разработку интерфейса прикладного решения весьма высоки. Именно поэтому в платформу «1С:Предприятие» включен целый ряд механизмов, ориентированных на быструю разработку эргономичного пользовательского интерфейса. В них реализована собственная оконная модель, система форм, набор элементов управления и т. д.
Основной идеей построения интерфейса, реализованной в «1С:Предприятии», является максимальное использование информации из метаданных, а также объектов манипулирования данными с тем, чтобы вся конструкция не требовала детальной настройки со стороны разработчика и функционировала по большей части автоматически. Мы уже говорили выше, что объекты встроенного языка, используемые для манипулирования данными, применяются и для их отображения в интерфейсе. Разработчику достаточно связать такой объект с элементом управления и механизм интерфейса полностью возьмет на себя организацию просмотра и модификации данных. Однако, наибольший эффект достигается за счет установления связи между объектом манипулирования данных и самой формой, а не с отдельными элементами управления. В таком случае вся функциональность формы, относящаяся к просмотру и редактированию данных, а также ее связь с другими формами, обеспечивается системой автоматически. Для этого в «1С:Предприятии» реализован механизм расширений форм и расширений элементов управления. Расширения автоматически «включаются в работу» с учетом типа данных, с которыми связан элемент управления или форма.
Например, поле ввода обеспечивает все необходимые действия по редактированию ссылочных значений (выбор из специальных форм, множественный подбор, очистку, подсветку и автоматический выбор незаполненных значений, переход к формам редактирования выбранных объектови т. д.). Очень эффективен так называемый ввод по строке, который позволяет в несколько раз ускорить массовый ввод информации, исключая необходимость выбора значений из форм списков. Для его реализации в свойствах метаданных задается перечень полей, по которым пользователи могут быстро находить нужные объекты, например, код, артикул, наименование. При наборе в поле ввода нескольких символов система автоматически подставляет то значение, одно из указанных в метаданных полей которого начинается с тех же символов. Если таких значений найдено несколько, пользователю предлагается осуществить выбориз списка. От разработчика при этом не требуется никаких усилий, так как интерфейсный механизм опирается на свойства метаданных.
Другим интересным примером является табличное поле. Этот элемент управления представляет собой мощный механизм визуализации и редактирования данных, предоставляющий пользователю возможность просмотра и редактирования больших списков, за счет динамического считывания. Мы уже говорили выше о механизме динамического считывания, как одном из средств манипулирования данными. В механизме интерфейса «1С:Предприятия» он позволяет просматривать массивы данных практически неограниченного размера без считывания их в память целиком. При этом с точки зрения пользователя навигация по списку практически не отличается от просмотра данных, находящихся в памяти компьютера. Данный механизм поддерживает гибкие возможности поиска и фильтрации, просмотра иерархических структур, редактирование данных в списке и в отдельных формах, настройку состава колонок и их сортировки, печать списков и их экспорт в различные форматы и т. д.
Для форм, списков и других элементов система автоматически формирует командный интерфейс (кнопки, меню и целые панели управления), обеспечивающий все действия по просмотру и редактированию, а также связи с другими формами и сервисные функции.
Описав объект метаданных в прикладном решении, разработчик может вообще не строить для него форму, все необходимые формы будут создаваться автоматически в процессе работы системы. Если же он создает форму, чтобы задать ей специфические свойства, то конструктор генерирует стандартную форму, которая не содержит изначально никакого кода на встроенном языке., так как расширения элементов управления и формы обеспечивают всю необходимую функциональность. Разумеется, разработчик может и без конструктора вставить в любую форму элементы управления, связать их с данными и получить полностью работающую конструкцию, не написав ни строчки кода. Дописывать что-то ему придется лишь тогда, когда он захочет переопределить или расширить стандартную функциональность.
Важно что, интерфейс «1С:Предприятия» обеспечивает работу не просто отдельных форм и элементов управления. Штатная механика управления формами прикладных объектов обеспечивает различные варианты связей между форами используемые при выборе значений, множественном подборе, детализации информации и т. д. Фактически, платформа «1С:Предприятия» предлагает разработчику готовую стратегию организации всего интерфейса бизнес-приложения имеющую способы реализации практически всех необходимых сценариев работы пользователей.
За счет использования хранящихся в метаданных знаний о связях между различными объектами, поддерживается автоматическая генерация команд перехода между логически связанными формами. Так пользователь, работая с некоторым документом, может без каких-либо усилий со стороны программиста получить доступ к записям, отражающим этот документ в различных учетных механизмах. Кроме связей определяемых в метаданных бизнес-логикой прикладного решения, разработчик может определить (в виде критериев отбора) и дополнительные связи для перехода между объектами, которые так же автоматически будут представляться в командном интерфейсе форм.
Другим стандартным интерфейсным решением является так называемый механизм «ввода на основании». Он позволяет при вводе данных по одному объекту, заполнять автоматически целый ряд полей, извлекая их значения из из данных других объектов. Например, выписав счет, пользователь может нажатием одной кнопки сформировать на основании этого счета накладную: для этого достаточно установить в метаданных связь между упомянутыми объектами и описать правила заполнения полей.
Разработчик прикладного решения предоставляется стандартное средство реализации «сменного» командного интерфейса. В прикладных решениях, имеющих большой объем функциональности, это дает пользователю возможность переключаться на другой режим работы с полной или частичной сменой командного интерфейса, не выходя из системы.
Механизм форм обеспечивает стратегию смысловой идентификации форм, позволяющую не открывать повторно уже открытые формы, а активизировать отрытые ранее формы при обращении пользователя к той или иной информации.
Таким образом, с помощью расширений форм и других механизмов автоматически поддерживается целостная стратегия пользовательского интерфейса, включающая различные варианты взаимодействия между формами, автоматическое формирование командного интерфейса для навигации по различным режимам и функциям системы, а так же всевозможные сервисные режимы, обеспечивающие комфортную работу пользователя.
Мы уже отмечали, что в интерфейсе «1С:Предприятия» реализовано много специальных элементов, не использующих стандартные средства операционной системы. Это сделано для того, чтобы можно было строить интерфейс, максимально отвечающий специфике деловых приложений.
В частности, в «1С:Предприятии» реализована собственная модель оконной системы, ориентированная. на работу с большим количеством разнородной информации. Например, максимизация окна управляется пользователем для каждой формы отдельно, а не как единый режим для всего приложения (как это принято в стандартных MDI приложениях). Кроме традиционных видов окон, в ней используются прикрепленные и прячущиеся окна. В интерфейсе «1С:Предприятия» из модального окна разрешается вызов немодальных окон, благодаря чему, фактически, образуется несколько слоев многооконного интерфейса. Разработчик может открывать модально любые формы, не изменяя логики их работы.
Поддерживается автоматический режим корректировки размеров элементов управления при изменении размера формы и при перемещении разделителей внутри нее. Таким образом, пользователь может установить желаемыйе размеры для каждой формы и отдельных ее частей, а формы автоматически используют все предоставленное пространство для эффективного отображения информации. Важно, что этот механизм не требует какой-либо настройки со стороны разработчика, но допускает, разумеется, и более тонкий тюнинг.
Формы и элементы управления имеют дизайн, ориентированный с одной стороны на отображение максимального количества информации, а с другой стороны на снижение утомляемости при длительной работе пользователя. Для этого используется «плоский» дизайн интерфейса приближенный к Web-дизайну. Для управления дизайном интерфейса предусмотрен механизм стилей, позволяющий централизовано изменять общий вид прикладного решения. Практически каждый элемент управления «оснащен» функциональностью, ориентированной на специфику экономических задач. Кроме того, предусмотрен ряд элементов управления непосредственно нацеленных на аналитические задачи, например, это диаграмма, диаграмма Ганта и т. д.
В интерфейсных механизмах «1С:Предприятия» имеется еще много интересных элементов, выше мы перечислили только некоторые решения. Важно, что весь набор интерфейсных механизмов предоставлен разработчику в достаточно высокоуровневых понятиях. Как уже говорилось, важным качеством концепции разработки в «1С:Предприятии» является изолирование прикладного решения от различного рода технических деталей. Например, разработчик не имеет доступа к управлению движениями мыши или детальной отрисовке элементов управления. Даже достаточно сложные механизмы предоставляются разработчику в таком виде, чтобы с одной стороны они могли бы функционировать вообще без какой-либо настройки, а с другой стороны — обеспечивали бы возможность настройки в простых высокоуровневых категориях, не требующих специальных знаний. Благодаря этому в прикладных решениях поддерживается современный полнофункциональный интерфейс, и в то же время, только незначительная доля исходного кода относится к его визуальной части, а большая часть реализует собственно бизнес-логику интерфейса прикладного решения.
Следует упомянуть и о Web-расширении — механизме, позволяющем реализовывать Web-интерфейс к прикладным решениям «1С:Предприятия». Мы не будем рассказывать о деталях технологического устройстве этого механизма. Наиболее интересным в его реализации, на наш взгляд является то, что он также как и основной (rich) интерфейс максимально использует для автоматического формирования Web-форм информацию из метаданных, а также знания о назначении и устройстве прототипов прикладных объектов. Форма для редактирования любого объекта или просмотра списка объектов создается Web-расширением автоматически или может быть определена разработчиком вручную в проекте. Если разработчик описывает форму самостоятельно, то в его распоряжении специализированные элементы управления, которые не только позволяют организовать связь с теми или иными данными, но и предоставляют всю необходимую функциональность по просмотру и редактированию. Например, в полях ввода поддерживается выбор из форм-списков и подбор по первым буквам, в списках поддерживается иерархический просмотр, настройка пользователем фильтрации и сортировки. Система предоставляет большой набор стандартных действий по «обслуживанию» данных и самостоятельно организует связь между формами приложения. Таким образом обеспечивается единообразие двух вариантов пользовательского интерфейса (разумеется, с поправкой на особенности среды Web), а также максимальная автоматизация их разработки, основанная на использовании информации из метаданных.
Одним из наиболее важных, на наш взгляд, следствий построения пользовательского интерфейса на основе стандартных средств предоставляемых платформой является то, что интерфейс всех прикладных решений «1С:Предприятия» построен единообразно. Это позволяет пользователям максимально применять накопленный ранее опыт. Освоив приемы работы с интерфейсом одного бизнес-приложения, пользователь легко начнет работать с любым другим прикладным решением «1С:Предприятия».
Интеллектуальные механизмы подготовки отчетов
В любом бизнес-приложении имеются два основных механизма, обеспечивающих взаимодействие пользователя с системой. Это интерфейс, предназначенный для ввода информации, и средства подготовки отчетов. Поскольку механизмы получения отчетов отвечают, прежде всего, за представление пользователю информации, необходимой для принятия управленческих решений, естественно, что в «1С:Предприятии» им уделено особое внимание.
Технология подготовки отчетов, примененная в «1С:Предприятии», содержит, по нашему мнению, целый ряд уникальных решений, не имеющих прямых аналогов в других продуктах. Прежде всего, следует отметить, что в платформе «1С:Предприятие» нет традиционного для большинства систем отдельного средства «генератор отчетов». Для подготовки отчетов разработчику предлагается целый ряд механизмов, которые могут использоваться в различных комбинациях и в сочетании с другими механизмами. Благодаря этому в «1С:Предприятии» отчеты органично вписываются в общий интерфейс приложения. Фактически, пользователь в процессе работы не видит грани между общим интерфейсом и механизмом отчетности. По нашему мнению, в современной экономической прикладной системе и не должно быть иначе: ведь аналитическая информация может использоваться во всех режимах и формах, а отчеты формируются по большей части уже не для вывода их на печать, а для интерактивного анализа. Поэтому в «1С:Предприятии» средства подготовки отчетности тесно интегрированы с другими механизмами и имеют мощные возможности для интерактивной работы.
Одним из наиболее интересных механизмов такого рода, предоставляемых платформой, является построитель отчетов, предоставляющий возможность с минимальными усилиями получить отчет с развитой функциональностью.
Нам хотелось добиться того, чтобы разработчик или пользователь кратко описывал, какую информацию необходимо проанализировать, а все остальное для получения полнофункционального управляемого отчета построитель делал бы самостоятельно.
Выборка исходной информации осуществляется на основе описаний, выполненных с помощью языка запросов «1С:Предприятия». Поскольку при этом активно используются готовые виртуальные таблицы учетных механизмов, текст запроса для достаточно сложного отчета будет занимать всего несколько строчек. Его вовсе не обязательно писать вручную. В большинстве случаев запрос формируется средствами визуального конструктора и зачастую вся процедура сводится к выбору источника данных и указанию полей итогов. Данный инструмент позволяет визуально формировать логические конструкции практически неограниченной сложности, включая объединения запросов и вложенные запросы, а также способен «поднимать» для редактирования текст запроса, расположенный в любом месте модуля.
На основании всестороннего анализа текста запроса построитель самостоятельно формирует всю инфраструктуру необходимую не только для генерации отчета, но и для тонкой его настройки пользователем, а также для навигации между отчетами. В результате создается форма, содержащая как собственно отчет, так и разнообразные средства для управления им — выбора включаемых в отчет полей, фильтрации информации по сложным критериям, группировки по строкам и колонкам, настройки упорядочивания данных и т. д. Отображаться отчет может в виде таблицы с многоуровневой иерархией строк и колонок, диаграммы, сводной диаграммы или сводной таблицы.
Заметим, что интерактивная настройка фильтрации обеспечивает такие возможности, как установка отбора по полям связанных таблиц (полученных «через точку»), указание в качестве критерия отбора множества значений или групп объектов, в иерархии которых нужно отбирать информацию. Например, пользователь может настроить отчет по закупкам товаров таким образом, чтобы в него вошли только накладные, содержащие товары, производители которых относятся к группам «Отечественные» и «Зарубежные». При этом построитель позволяет сохранять текущие пользовательские настройки отчета для последующей работы.
Кроме того, построитель автоматически включает в сформированный отчет всю информацию, необходимую для расшифровки отдельных ячеек отчета (drill-down). Эта расшифровка выполняется в интерактивном режиме- буквально одним щелчком мыши по выбранной ячейке отчета может быть автоматически сформирован более детальный отчет на основании данных этой ячейки и информации, содержащейся в исходном отчете:
Очень важно, что все эти возможности, представляемые разработчику в готовом виде, могут использоваться им в различных комбинациях. В результате он может гибко определять для каждого создаваемого отчета, какие «степени свободы» предоставить пользователю, указывая это в тексте запроса. Так, например, можно указать, по каким полям пользователь может устанавливать фильтрацию, упорядочивание, группировки и т. д. Сами элементы управления отчетом включаются в форму также по усмотрению разработчика. Поскольку все составляющие данного механизма могут использоваться независимо, разработчик может применять построитель не только для подготовки отчетов, но и для решения многих других задач. Например, он может создать процедуру группового изменения данных, в которой для управления выборкой данных будут задействованы все механизмы построителя, но затем полученная выборка будет не отображена в отчете, а пройдет заданную обработку, например, для выбранной группы товаров будут скорректированы цены.
Так же весьма важным эффектом использования этого механизма мы считаем то, что на его основе в прикладных решениях «1С:Предприятия» реализуются инструменты, в которых «продвинутые» пользователи действительно могут самостоятельно создавать достаточно сложные отчеты. На основе этого механизма построена специальная консоль отчетов, используемая в большинстве прикладных решений и предоставляющая пользователю возможность проектировать собственные отчеты, тут же их формировать, настраивать и даже создавать систему связанных, детализирующих друг друга отчетов.
Не были забыты и вопросы эффективности изобразительных средств. В «1С:Предприятии» для визуализации и печати отчетов используется прежде всего метафора табличного документа (без средств вычислений). Основной идеей данного решения является использование модели электронной таблицы (spreadsheet) в качестве средства оформления отчетных документов, без использования ее как средства вычисления.
В отличие от большинства электронных таблиц табличный документ «1С:Предприятия» может содержать таблицы, имеющие очень большие размеры, как по вертикали, так и по горизонтали. У него богатый набор изобразительных возможностей, позволяющий с одной стороны создавать хорошо оформленные аналитические отчеты, а с другой — подготавливать регламентированные бланки с точной привязкой содержащихся в них объектов к локальным координатам. В отличие от стандартных электронных таблиц здесь разрешается описывать строки с различными настройками ширины колонок. Это необходимо для создания сложных отчетов включающих несколько разноформатных таблиц.
В большинстве случаев заполнение отчета выполняется на основании макета. Для этого в табличном документе предусмотрена гибкая система именования областей и описания параметров. Разработчик визуально проектирует макет, определяющий внешний вида отчета, выделяя в нем различные области, которые должны заполняться данными, и описывая их параметры. При формировании отчета происходит совмещение областей с данными и таким образом содержательная часть отчета объединяется с его внешним оформлением. Следует заметить, что макет отчета может как формироваться построителем автоматически, так и создаваться разработчиком. . Допускается использование готовых стилей оформления отчетов и проектирование собственных.
Важно, что средство генерации табличных документов служит не только для получения статических печатных форм. В нем имеется мощный интерактивный механизм для управления многоуровневыми группировками, расшифровки ячеек отчета (drill-down), автонастройки ширины колонок и т. д. Допускается сохранение отчета в различных форматах (html, xls, txt). Кроме того, для интерактивного анализа многомерной информации в табличном документе может использоваться сводная таблица, которая позволяет непосредственно управлять группировкой информации и составом отображаемых данных, не обновляя отчета.
Чрезвычайно важным качеством табличного документа является возможность использования его в качестве полнофункционального механизма ввода и редактирования информации. Такой документ может содержать любые элементы управления, используемые в формах «1С:Предприятия», как в самих ячейках и рисунках, так и поверх ячеек. Это особенно полезно в тех случаях, когда одна и та же форма должна представлять собой и отчет, и инструмент для редактирования информации. Примером может служить отчет о плановых показателях, которые разрешается корректировать.
Для визуального представления аналитической информации разработчику предлагается набор различного вида диаграмм, а также диаграмма Ганта, сводная диаграмма и дендрограмма. Причем эти элементы могут включаться как в формы, наравне с другими элементами управления, так и в табличные документы для получения комплексных аналитических отчетов.
Весьма полезен также механизм интеллектуального анализа данных (data mining), с помощью которого прикладное решение можно с минимальными затратами оснастить такими аналитическими инструментами, как кластерный анализ, дерево решений и т. д.
Важная особенность платформы «1С:Предприятие» состоит в том, что для формирования отчетов любой сложности разработчику не придется подключать дополнительные внешние механизмы. При этом все внутренние инструменты хорошо интегрированы, базируются на единой системе понятий и максимально используют возможности друг друга. Например, сводная таблица, располагаемая в табличном документе, для того чтобы автоматически модифицировать запрос к базе данных по мере того, как пользователь визуально указывает новые уровни группировки, обращается к функциям построителя отчетов. Разумеется, в системе присутствует и конструктор отчетов, который позволяет проектировать их интерактивно, однако важно, что конструктор только «собирает» отчет из имеющихся механизмов («кубиков»), применяемых и для решения множества других задач. Как показала практика, при таком подходе на разработку достаточно сложного отчета уходит не более нескольких минут.
Построение распределенных и интегрированных информационных систем
Еще одной «козырной картой» платформы «1С:Предприятие» являются механизмы обмена данными.
Изначально решение о создании механизма обмена данными, предназначенного для территориально распределенных информационных баз и не требующего постоянного соединения, было обусловлено в большей степени отсутствием в распоряжении отечественных предприятий качественных высокоскоростных телекоммуникационных каналов. Однако некоторое время спустя стало очевидно, что разработка таких механизмов лежит в русле одного из наиболее перспективных направлений мировой инженерной мысли.
Сегодня в распоряжении разработчика приложений имеется мощный набор механизмов обмена, способный решать самые разнообразные задачи. Кроме традиционной поддержки территориально распределенных информационных систем, с его помощью осуществляется интеграция с другими прикладными программами, а также строятся сложные гетерогенные информационные системы, включающие наряду с решениями на платформе «1С:Предприятие» еще и внешние приложения.
Использование технологий обмена для решения столь широкого спектра задач объясняется тем, что в распоряжении разработчика не монолитное решение, а набор механизмов, которые могут применяться как по отдельности, так и совместно, в любых сочетаниях. Эти механизмы поддерживают работу с XML документами, XML-сериализацию данных, инфраструктуру сообщений, службу регистрации изменений, планы обмена, управление распределенной информационной базой:
Практически уникальным, по нашему мнению, качеством данного набора механизмов является то, что он обеспечивает очень высокий уровень готовности системы к работе в распределенной среде — организация обмена практически не требует дополнительных затрат на разработку. Нужно просто задать в интерактивном режиме состав данных, участвующих в обмене, а механизм обеспечит формирование сообщений и их загрузку. При этом система автоматически организует обмен только измененной информацией, отслеживает получение сообщений, определяет необходимость повторной отправки данных, разрешает коллизии и проверяет целостность загружаемой информации. Гибкие возможности настройки позволяют сформировать практически любую топологию схемы узлов обмена (звезда, снежинка, схемы без центрального узла). Состав данных, участвующих в обмене, и правила разрешения коллизий могут задаваться произвольно. При этом механизмы обмена с одной стороны минимизируют объем передаваемых данных (пересылаются только измененные данные), а с другой — гарантируют устойчивость к потере сообщений. Иными словами, система способна функционировать как в условиях гарантированной доставки сообщений, так и без таковой.
Наличие в платформе эффективных, не требующих сложной настройки механизмов обмена обязано, прежде всего, общей архитектуре построения прикладных решений, реализованной в платформе «1С:Предприятие». Мы уже говорили, о том, что органичный переход к распределенным и интегрированным системам обеспечивается объектной техникой манипулирования данными, используемой в «1С:Предприятии». Система соответствующих объектов обеспечивает штатные возможности сохранения (persistence) любых прикладных данных в формате XML. Кроме того, благодаря наличию стандартных прототипов прикладных объектов платформа способна автоматически задавать для каждого объекта необходимую гранулярность передачи изменений и стратегию обмена в соответствии с его назначением. Основной проблемой большинства известных систем обмена и репликации является то, что в заложенной в них семантике описания данных не содержится сведений о том, какими порциями выполнять обмен, как разрешать коллизии, как обеспечивать логическую целостность и непротиворечивость данных. Из-за этого разработчику при использовании подобных механизмов обычно приходится детально описывать процедуры обмена для каждого информационного массива.
Механизмы обмена «1С:Предприятия» функционируют на уровне стандартных прототипов прикладных объектов и поэтому имеют в своем распоряжении всю необходимую информацию такого рода изначально. Разработчику необходимо только указать, что в обмене участвуют объекты определенного вида. Далее все действия, по регистрации изменений, формированию сообщений, загрузке данных и разрешению коллизий будут выполняться автоматически. Разработчик, конечно, имеет возможность вручную выполнить «тонкую настройку», но она потребуется только в отдельных случаях.
Другая важная особенность механизмов обмена «1С:Предприятия» — их соответствие передовым мировым концепциям интеграции информационных систем. Мы прекрасно понимаем, что сегодня ни один разработчик экономического софта не может считать себя «царем горы», которому нет необходимости заботиться о тесном взаимодействии с системами других вендоров. В данном контексте взаимодействие — не просто умение вызвать какую-то функцию из другой программы или экспортировать в нее какие-либо данные. Речь идет о построении сложных гетерогенных систем, в которых несколько разнородных прикладных решений образуют слаженно действующий ансамбль. Очевидно, что эта тенденция станет в обозримом будущем одной из доминирующих на рынке экономических систем. Механизмы обмена «1С:Предприятия» имеют высокую готовность к работе в гетерогенных системах сегодняшнего и завтрашнего дня не только за счет того, что весь обмен производится на формате XML, но, что еще более важно, в силу идеологического соответствия реализованных решений указанной тенденции. Уже сегодня механизмы обмена «1С:Предприятия» позволяют осуществлять взаимодействие не только с отдельными приложениями, но и с перспективными интеграционными платформами.
Поставка и обновление прикладных решений
Практически все производители прикладных программ предусматривают в них механизмы для обновления версий. Однако для таких систем как «1С:Предприятие» подобные задачи представляют особую сложность. Это объясняется, во-первых, тем, что экономические системы обновляются гораздо чаще, чем другие, а во-вторых, тем, что достаточно часто практикуется изменение прикладных решений «1С:Предприятия» «на местах» с целью адаптации тиражного продукта к потребностям конкретного клиента. Последняя особенность представляет особую сложность, так как при выпуске разработчиком любого обновления прикладного решения возникает необходимость синхронизации сделанных им изменений с теми, что были внесены в процессе внедрения у заказчика.
Для решения этих и множества других задач, связанных с поставкой и обновлением прикладных решений, в «1С:Предприятии» реализован целый комплекс механизмов ориентированных как на разработчиков, так и на пользователей. Они охватывают весь технологический процесс поставки и поддержки: подготовку дистрибутивных файлов, инкрементных обновлений и установочных комплектов поставки, публикацию обновлений в Интернете, автоматический их поиск и выполнение, управление составом поддержки на уровне объектов конфигурации и т. д.:
Одним из наиболее существенных элементов технологии обновления является механизм, обеспечивающий синхронизацию изменений, сделанных поставщиком прикладного решения с изменениями, внесенными при внедрении на конкретном предприятии. Он предоставляет мощные функции сравнения и анализа изменений, а также средства управления их синхронизацией. Администратор или разработчик может детально настроить синхронизацию обновлений вплоть до отдельных объектов, отдельных свойств и отдельных процедур модулей. Например, если специалист, отвечающий за сопровождение прикладного решения на предприятии, отметит объекты, которые намерен поддерживать самостоятельно, они не будут в дальнейшем обновляться при установке очередного обновления от поставщика. Если объекты необходимо объединить, то для упрощения синхронизации изменений можно настроить приоритеты такого объединения.
Механизмы обновления позволяют построить сложную многоуровневую систему сопровождения. Поставщики специализированных вертикальных решений могут находиться на поддержке у разработчиков универсальных приложений, и обеспечивать в свою очередь поддержку собственных клиентов. Пользователь при этом будет эксплуатировать прикладное решение, отдельные части которого сопровождаются разными фирмами.
Поскольку механизм обновления в значительной мере основан на том, что все прикладное решение описывается с помощью метаданных, а бизнес-логика приложения строится на стандартных прототипах прикладных объектов, система способна поддерживать стратегию обновления с учетом специфики архитектуры прикладного решения, контролировать его логическую целостность и предоставлять пользователю информацию об изменениях в наглядной форме.
А также…
Допускается реализация всего интерфейса прикладного решения на нескольких языках. Каждый пользователь может работать с одним из заложенных в него языков. При этом не нужно выносить все строки в отдельные файлы. Элементы интерфейса редактируются на нескольких языках «по месту» — в формах, макетах печатных документов, в меню и т. д. Разработчик может в любой момент переключиться и редактировать интерфейс форм на другом языке. Допускается также поочередное редактирование конкретной надписи на всех поддерживаемых языках. Если необходимо расширить языковую базу, можно собрать все текстовые элементы в общий список с тем, чтобы перевод одинаковых надписей отражался сразу во всех компонентах интерфейса. Общая стратегия интернационализации включает также перевод системного интерфейса, хранение всех строк в кодировке UNICODE, форматирование дат и чисел в соответствии с особенностями различных стран и языков, построение правил сортировки с учетом национальных стандартов и т. д.
Выполнение алгоритмов бизнес-логики разработчик может по своему усмотрению переносить на сервер «1С:Предприятия». Это позволяет ему управлять распределением нагрузки между клиентом и сервером. При этом от разработчика не требуется специальных навыков построения трехуровневых архитектур, знания сетевых протоколов и т. д. Все технологические детали система берет на себя и обеспечивает рациональное использование серверных ресурсов за счет поддержки stateless-модели, кэширования и разделения системных ресурсов и т. д.
В системе защиты прав доступа «1С:Предприятия» реализована возможность настройки ограничений на уровне отдельных записей, а также полей таблиц. Это позволяет, например, предоставить пользователю доступ к именам сотрудников только в пределах своего департамента, а к данным по окладу и семейному положению — только для своих непосредственных подчиненных. Настройка таких ограничений требует лишь задания формального условия, после чего система контролирует все действия пользователей автоматически, разработчику не нужно учитывать эти ограничения в явном виде при реализации различных интерфейсных режимов и алгоритмов бизнес-логики.
Обеспечиваются две стратегии проверки прав доступа. В зависимости от решаемой задачи, система контроля прав доступа может как отвергнуть обращение пользователя к закрытым для него данным, так и просто исключить недоступные записи из выборки, предоставив пользователю только доступную информацию.
Одним из мощных инструментов разработчика в «1С:Предприятии» является механизм сравнения и объединения прикладных решений. Мы уже упоминали о нем, когда говорили о возможностях поддержки, однако этот механизм может весьма эффективно использоваться и в процессе разработки. Данный инструмент может использоваться как для анализа различий, так и для переноса части функций из одного приложения в другое. Он обеспечивает удобное визуальное представление различий между прикладными решениями и имеет гибкие возможности настройки логики сравнения. При сравнении родственных конфигураций данный механизм автоматически сопоставляет даже переименованные объекты, используя для этого внутреннюю идентификацию метаданных. Соответствие сравниваемых объектов независимо от совпадения их имен можно настроить и вручную, после чего оно будет учтено и во всех ссылках на такие объекты, имеющихся в других объектах прикладного решения. Кроме того, механизм сравнения содержит средства для визуального представления отличий форм интерфейса и макетов печатных документов. Благодаря использованию структуры метаданных и средств визуального сравнения интерфейсных объектов, с помощью нашей платформы удается решать гораздо больше задач, чем в тех системах, где механизмы сравнения базируются на сопоставлении файлов исходных кодов программ.
В «1С:Предприятии» поддерживается протоколирование действий пользователей в журнале регистрации. Система имеет несколько уровней протоколирования, которые могут функционировать автоматически, не требуя дополнительных усилий со стороны разработчика. Прежде всего, разумеется, фиксируются начало и окончание сеансов работы пользователей, административные операции с информационной базой, а также регистрируемые ошибки. За счет того, что все изменения в БД выполняются исключительно в объектной технике (через объекты, отвечающие за манипулирование данными), система может автоматически регистрировать их в журнале, причем будет делать это независимо от того, как они выполнялись (интерактивно или программно). Разработчик может также реализовать внесение в журнал любых других записей, которые система не способна фиксировать автоматически, например, информацию об отправке факса или формировании отчета. Важно заметить, что журнал регистрации реализован как отдельный системный механизм. Он не использует для хранения информации базу данных «1С:Предприятия», а, следовательно, его ведение не создает существенной дополнительной нагрузки на систему и не замедляет работу пользователей.
Итак…
В этой статье мы попытались перечислить наиболее интересные технологические новшества платформы «1С:Предприятие». При этом мы старались показать, что все реализованные в ней решения основаны на использовании единой модели и единой архитектуры.
Важно и то, что все механизмы платформы в той или иной степени используют возможности других механизмов. Например, почти все они опираются на структуру метаданных и наличие системы прототипов прикладных объектов. Таким образом, хотя каждая из возможностей «1С:Предприятия» может быть достаточно ценна сама по себе, наибольший интерес представляет рассмотрение всей их совокупности в рамках целостной модели.
Сформулируем еще раз несколько общих принципов, лежащих в основе модели «1С:Предприятия»:
- Архитектура платформы и ее инструментальные средства реализованы таким образом, чтобы разработчик бизнес-приложения мог максимально абстрагируясь от низкоуровневых технологий, сосредоточиться на решении прикладных задач своей предметной области.
- Вся разработка от построения структур данных, до проектирования элементов интерфейса и подключения средств интеграции ведется в одной системе понятий, что существенно ускоряет обучение специалистов и повышает производительность их труда.
- Платформа содержит готовые ответы практически на все вопросы, возникающие у разработчика прикладного решения, начиная от того, как отражать в информационной базе данные предметной области и кончая процедурами поставки, поддержки и администрирования. Соответственно, разработчику не требуется осваивать разнородные технологии и решать вопросы их совместного использования.
Наличие единой, сквозной высокоуровневой модели и реализующих ее технологий позволяет, по нашей оценке, на порядок сократить затраты на создание и поддержку прикладных решений.
Начиная в 1996 г. работы в этом направлении, и даже выпустив первую версию платформы, мы, конечно, не были абсолютно уверены в правильности выбранного пути. За пошедшее с тех пор время концепция системы успешно развивалась, и сегодня она воплощена в платформе «1С:Предприятие 8». Строго говоря, в мире не так уж много специализированных технологий, ориентированных именно на быстрое создание бизнес-приложений. Однако становится все более очевидным, что данный путь лежит на стратегическом направлении развития бизнес-софта.
По оценкам многих специалистов, с которыми нам приходилось общаться, ситуация в России и в странах бывшего СССР, где сложилась целая индустрия разработки и поддержки бизнес-решений, основанная на специализированной технологической платформе, по мировым меркам является уникальной. По нашим наблюдениям, не существует аналогичной специализированной платформы, на которой различными фирмами создавалось бы такое количество разнообразных массовых бизнес-приложений, покрывающих потребности существенной части рынка какого-либо региона. Соответственно, для многих специалистов наши подходы и решения представляют особый интерес, так как реальный эффект от их реализации хорошо заметен на практике.
Разумеется, все изложенные выше соображения (включая и анализ современных тенденций) являются только нашей позицией и результатом наших исследований. Мы ни в коем случае не претендуем на абсолютную истину, которой в этих вопросах, по-видимому, и не существует. Наверняка, у многих читателей есть своя, отличная от нашей, точка зрения на проблемы, затронутые в статье. Мы будем признательны за отзывы (в том числе критические) по данной статье.
Статья опубликована в газете PC Week/Russian Edition (издается по лицензии международного издательского дома Ziff-Davis Media Inc.), NN 46 , 47 и 48 за 2004 г. Перед публикацией на сайте v8.1c.ru в статью был внесен ряд дополнений, по техническим причинам не вошедших в газетный вариант, а также добавлены иллюстрации.
Фирма «1С» благодарит редакцию PC Week/RE за сотрудничество и помощь при подготовке статьи к публикации.
Чистая архитектура с MVVM | Блог о программировании
Для лучшего понимания чистой архитектуры давайте создадим примерный проект. Это приложение, на первой странице которого показывается список персонажей из мультсериала «Рик и Морти» с данными. Нажимая на каждого персонаж, на следующей странице можно увидеть серии, в которых эти персонажи появляются.
Поэтому у нас два типа сущностей: персонаж и серия.
Итак, прежде всего разберёмся, почему нам надо использовать чистую архитектуру?
- Разделение обязанностей — разделение кода на части или различные модули, которые имеют определённые обязанности, облегчает его сопровождение и дальнейшие изменения.
- Слабая связанность — в гибкий код можно легко вносить изменения, не меняя всей системы.
- Лёгкость тестирования.
В проекте у нас три слоя: приложение (представление), данные и предметная область.
Данные: в этом слое есть абстрактное определение различных источников данных и как их следует использовать. Мапперы выполняют отображение ответа сервера на модели баз данных. Модели представляют собой модель ответа сервера. Репозиторий существует для реализации вызовов API. Операции с базами данных — для реализации интерфейса «Dao», а пакет API — для определения методов API-вызовов с сервера. В обычном приложении мы, как правило, храним репозиторий и интерфейс репозитория в одном пакете. И можем делать это локально, чтобы везде иметь прямой доступ. Но в этом случае слой данных ни в коем разе не должен знать о других слоях.
Предметная область: этот слой известен как бизнес-логика. Это правила вашего бизнеса. Здесь находится пакет model, содержащий модели баз данных. А также репозиторий, являющийся лишь интерфейсом, и прецеденты. А что такое прецедент? Как известно, прецеденты выполняют единственную задачу. И в случае с персонажами, когда надо получить данные из базы данных, мы пишем прецедент с этой самой задачей получения данных из базы данных.
Приложение: этот слой взаимодействует только с UI (пользовательским интерфейсом) и содержит фрагменты, activity (т. е. визуальный интерфейс с отдельным экраном для одного действия пользователя), ViewModel и Di. Под Di подразумевается модуль, предназначенный для этого фрагмента или activity.
На этом рисунке показано, как слои взаимодействуют друг с другом:
Но закончим уже с текстом и перейдём скорее к коду.
Итак, в проекте мы используем:
RxJava
Hilt
databinding
Retrofit
Room
Kotlin
Зависимости:
```java
//retrofit
implementation 'com.squareup.retrofit2:retrofit:2.9.0'
implementation 'com.squareup.retrofit2:converter-gson:2.5.0'
implementation 'com.squareup.okhttp3:logging-interceptor:4.9.0'
implementation "com.jakewharton.retrofit:retrofit2-rxjava2-adapter:1.0.0"
implementation group: 'com.squareup.retrofit2', name: 'converter-jackson', version: '2.4.0'
//implementation "com.fasterxml.jackson.module:jackson-module-kotlin:2.8.6"
//rx
implementation 'io.reactivex.rxjava2:rxjava:2.2.19'
implementation "io.reactivex.rxjava2:rxandroid:2.1.1"
//jackson
implementation 'com.fasterxml.jackson.core:jackson-core:2.10.1'
implementation 'com.fasterxml.jackson.core:jackson-annotations:2.10.1'
implementation 'com.fasterxml.jackson.core:jackson-databind:2.10.1'
//Hilt
implementation "com.google.dagger:hilt-android:$hilt_version"
kapt "com.google.dagger:hilt-android-compiler:$hilt_version"
implementation 'androidx.hilt:hilt-lifecycle-viewmodel:1.0.0-alpha02'
kapt 'androidx.hilt:hilt-compiler:1.0.0-alpha02'
//Room
implementation 'androidx.room:room-runtime:2.2.5'
implementation "android.arch.persistence.room:rxjava2:2.2.4"
implementation "androidx.room:room-rxjava2:2.2.5"
kapt "androidx.room:room-compiler:2.2.5"
```Для этого проекта в базе мы создаём три пакета: Episode («Серия»), Character («Персонаж») и utils.
Что такое utils? Это пакет, содержащий базовые и общие классы, которые используются более чем в двух классах.
Episode («Серия») и Character («Персонаж») содержат данные, предметную область (бизнес-логику) и представление:
Эти пакеты будут выглядеть так:
Пакет API содержит интерфейс «CharacterApi», который является лишь методом взаимодействия с сервером, и «CharacterApiImpl» для реализации этого взаимодействия.
```java
interface CharacterApi {
@GET("api/character")
fun getCharacters(): Single<ResponseCharacter>
}
```Пакет базы данных содержит интерфейс «Dao»:
```java
@Dao
interface CharacterDao {
@Insert(onConflict = OnConflictStrategy.REPLACE)
fun insertCharacter(characters: CharactersData): Maybe<Long>
@Insert(onConflict = OnConflictStrategy.REPLACE)
fun insertCharacters(characters: List<CharactersData>): Maybe<List<Long>>
}
```В «CharacterRepositoryImpl» вызываем только те методы, которые нам нужны. Здесь нет бизнес-логики.
```java
class CharactersRepositoryImpl @Inject constructor(
private val charactersApi: CharactersApiImpl,
private val characterDao: CharacterDao
) : CharactersRepository {
override fun getCharacters(): Single<ResponseCharacter> {
return charactersApi.getCharacters()
}
}
```В предметной области мы определяем модель, которую надо сохранить в базе данных:
```java
@Entity(tableName = "Characters")
@TypeConverters(StringConverter::class)
data class CharactersData(
@PrimaryKey(autoGenerate = true)
val characterId: Int? = 0,
var image: String? = null,
val gender: String? = null,
val url: String? = null,
@SuppressWarnings(RoomWarnings.DEFAULT_CONSTRUCTOR)
@Embedded(prefix = "org")
var origin: Origin? = null,
var name: String? = null,
@SuppressWarnings(RoomWarnings.DEFAULT_CONSTRUCTOR)
@Embedded(prefix = "loc")
var location: Location? = null,
var status: String? = null,
val episodes : List<String?>? = null
)
```Репозиторий — это интерфейс, реализуемый в приведённом выше классе.
```java
interface CharactersRepository {
fun getCharacters(): Single<ResponseCharacter>
}
```Прецедент, подобный упомянутому ранее, выполняет только одну задачу. Например, получение данных с сервера с сохранением их в базе данных.
```java
class GetCharactersUseCase @Inject constructor(private val charactersRepository: CharactersRepository) {
sealed class Result {
object Loading : Result()
data class Success(val responseCharacter: List<CharactersData>) : Result()
data class Failure(val throwable: Throwable) : Result()
}
fun getCharacters(hasNetwork: Boolean): Observable<Result> {
return if (!hasNetwork) {
return charactersRepository.getCharactersFromDb()
.toObservable()
.map {
Success(it) as Result
}
.onErrorReturn { Failure(it) }
.startWith(Result.Loading)
} else {
charactersRepository.deleteAllCharacters()
charactersRepository.getCharacters().toObservable().map {
val data = CharacterToDbMapper().reverseMap(it.results)
Success(data) as Result
}
.onErrorReturn { Failure(it) }
.startWith(Result.Loading)
}
}
}
```Мы используем запечатанный класс для передачи данных и наблюдения за ними во ViewModel. И передаём прецедент конструктору для взаимодействия между этими двумя классами.
Для внедрения зависимостей используем hilt, поэтому пакета di нет в Episode («Серии») и Character («Персонаже»), но в util мы определяем «NetworkModule»:
```java
@InstallIn(ApplicationComponent::class)
@Module
class NetworkModule {
@Provides
@Singleton
fun provideCharacterApiService(retrofit: Retrofit): CharacterApi =
retrofit.create(CharacterApi::class.java)
@Provides
@Singleton
fun provideEpisodeApiService(retrofit: Retrofit): EpisodeApi =
retrofit.create(EpisodeApi::class.java)
@Provides
@Singleton
fun provideGsonRetrofit(
httpClient: OkHttpClient.Builder,
convertFactory: GsonConverterFactory
): Retrofit =
Retrofit.Builder()
.baseUrl("https://rickandmortyapi.com")
.client(httpClient.build())
.addConverterFactory(convertFactory)
.addCallAdapterFactory(RxJava2CallAdapterFactory.create())
.build()
@Provides
@Singleton
fun provideOkHttpClient(httpLoggingInterceptor: HttpLoggingInterceptor): OkHttpClient.Builder {
val httpClient = OkHttpClient.Builder()
if (BuildConfig.DEBUG) {
httpClient.addInterceptor(httpLoggingInterceptor)
}
httpClient.retryOnConnectionFailure(true)
return httpClient
}
@Provides
@Singleton
fun provideHttpLoggingInterceptor(): HttpLoggingInterceptor=
HttpLoggingInterceptor().setLevel(HttpLoggingInterceptor.Level.BODY)
@Provides
@Singleton
fun provideJacksonConverterFactory(): JacksonConverterFactory =
JacksonConverterFactory.create()
@Provides
@Singleton
fun provideGsonConverterFactory(): GsonConverterFactory =
GsonConverterFactory.create()
}
```И определяем «AppModule» в utils следующим образом:
```java
@InstallIn(ApplicationComponent::class)
@Module
class DatabaseModule {
@Singleton
@Provides
fun provideDatabase(@ApplicationContext context: Context): AppDatabase {
return Room.databaseBuilder(
context,
AppDatabase::class.java,
"CHARACTERS-DATA.db"
).allowMainThreadQueries()
.build()
}
@Provides
fun provideCharacterDao(database: AppDatabase): CharacterDao {
return database.charactersDao()
}
@Provides
fun provideEpisodeDao(database: AppDatabase): EpisodeDao {
return database.episodesDao()
}
@Provides
fun provideCharacterEpisodeDao(database: AppDatabase): CharacterEpisodeDao {
return database.characterEpisodesDao()
}
```А в пакете репозитория в utils определяем модуль репозитория:
```java
@InstallIn(ApplicationComponent::class)
@Module
class RepositoryModule {
@Provides
fun provideEpisodeRepository(repo: EpisodeRepositoryImpl): EpisodeRepository = repo
@Provides
fun provideCharacterEpisodeRepository(repo: CharacterEpisodeRepositoryImpl): CharacterEpisodeRepository =
repo
@Provides
fun provideCharactersRepository(repo: CharactersRepositoryImpl): CharactersRepository = repo
}
```Заключение
Итак, мы узнали, как это здорово — разрабатывать свой проект с чистой архитектурой для обеспечения лучшей тестопригодности с возможностью повторного использования. Кроме того, мы теперь можем изменить код, не беспокоясь о том, что станет с остальной частью проекта.
Надеюсь, статья была полезной. Проект с чистой архитектурой загружен на GitHub.
Создание модульной и масштабируемой архитектуры виртуальной сети с помощью Amazon VPC
Развертывание этого быстрого запуска с параметрами по умолчанию создает следующую виртуальную сетевую среду в облаке AWS.
* Обратите внимание, что IP-адреса не включают пять адресов из каждой подсети, которые зарезервированы. и недоступен для использования.
Рисунок 1. Модульная архитектура Amazon VPC на AWS (полноэкранный режим)
Шаблон AWS CloudFormation настраивает виртуальную сеть и создает сетевые Ресурсы.
Шаблон создает инфраструктуру VPC с несколькими зонами доступности и несколькими подсетями с управляемым NAT. шлюзы в публичной подсети для каждой зоны доступности.Вы также можете создать дополнительные приватные подсети со специальными настраиваемыми списками управления доступом к сети (ACL). Если вы развернете Quick Начать в регион, который не поддерживает шлюзы NAT, вместо них развертываются экземпляры NAT. По умолчанию подсеть размеры основаны на типичном развертывании, но могут быть переконфигурированы, как обсуждается в Раздел «Размер подсети».
Quick Start также включает конечные точки VPC, которые обеспечивают безопасное и надежное соединение. к Amazon S3 без использования интернет-шлюза, устройства NAT или виртуального частного шлюз. С участием эти конечные точки, вы можете получить доступ к ресурсам S3 из VPC, созданного Quick Начало.Эти конечные точки действительны только для того региона AWS, в котором вы запускаете Quick Start.
Quick Start использует политику конечных точек по умолчанию, которая дает любому пользователю или службе в пределах Полный доступ VPC к ресурсам Amazon S3. Эта политика дополняет любые пользовательские политики IAM. или ковш S3 политики, которые у вас могут быть.
Quick Start также включает разрешение системы доменных имен (DNS) в VPC. Для большего информацию о конечных точках VPC см. в AWS документация.
Сервисы AWS
Основные компоненты AWS, используемые в этом кратком руководстве, включают следующие сервисы AWS.(Если вы новичок в AWS, см. раздел «Начало работы» в Документация AWS.)
Amazon VPC — виртуальное частное облако Amazon (Amazon VPC) позволяет выделить частный изолированный раздел облака AWS. где ты может запускать сервисы AWS и другие ресурсы в виртуальной сети, которую вы определяете.У вас есть полный контроль над виртуальной сетевой средой, включая выбор IP диапазон адресов, создание подсетей и настройка таблиц маршрутов и сети шлюзы.
Amazon EC2 — облако Amazon Elastic Compute (Amazon EC2) позволяет запускать экземпляры виртуальных машин с различными из операционные системы.Вы можете выбрать один из существующих образов машин Amazon (AMI) или импортировать ваши собственные образы виртуальных машин.
Amazon EBS — Amazon Elastic Block Store (Amazon EBS) предоставляет постоянные тома хранилища на уровне блоков для использования с инстансами Amazon EC2 в AWS Облако.Каждый том Amazon EBS автоматически реплицируется в пределах его доступности. Зона к защитить вас от отказа компонентов, обеспечивая высокую доступность и надежность. Amazon EBS тома обеспечивают стабильную производительность с малой задержкой, необходимую для работы вашего рабочие нагрузки.
NAT Шлюз — шлюзы NAT — это устройства преобразования сетевых адресов (NAT), которые обеспечивают исходящий доступ в Интернет экземплярам в частных подсетях, но предотвращают то Интернет от доступа к этим экземплярам.Шлюзы NAT обеспечивают лучшую доступность и пропускная способность, чем у экземпляров NAT. Служба шлюза NAT — это управляемая служба, которая требует уход администрирования шлюзов NAT. Шлюзы NAT поддерживаются не во всех регионах AWS. В этом кратком руководстве инстансы NAT развертываются в регионах, где шлюзы NAT недоступны.
Лучшие Лрактики
Архитектура, созданная с помощью этого краткого руководства, поддерживает лучшие практики AWS для доступность и безопасность.Быстрый старт обеспечивает:
До четырех зон доступности для обеспечения высокой доступности и аварийного восстановления.(AWS рекомендует максимально использовать зоны доступности, чтобы изолировать сбой в центре обработки данных.) Зоны доступности географически распределены в пределах региона и лучше всего разнесены. изоляция и устойчивость в случае стихийного бедствия.
Отдельные подсети для уникальных требований к маршрутизации.AWS рекомендует использовать общедоступные подсети для внешних ресурсов и частных подсетей для внутренних ресурсов. Для каждого Зона доступности, это краткое руководство предусматривает одну общедоступную подсеть и одну частную подсеть. по по умолчанию. (Если вам нужны только общедоступные подсети, вы можете отключить создание частных подсети.) Стратегии определения размера подсети см. В следующем разделе.
Дополнительный уровень безопасности. AWS рекомендует использовать сетевые ACL в качестве брандмауэров для контролировать входящий и исходящий трафик на уровне подсети.В этом кратком руководстве ан возможность создания подсети с защитой сетевого ACL в каждой зоне доступности. Эти сети ACL предоставляют отдельные элементы управления, которые вы можете настроить в качестве второго уровня защита.
Мы рекомендуем вам экономно использовать сетевые ACL по следующим причинам: они могут быть сложными в управлении, они не имеют состояния, каждый IP-адрес должен быть явно открыт в каждое направление (входящее / исходящее), и они влияют на всю подсеть.Мы рекомендуем тот вы используете группы безопасности чаще, чем сетевые ACL, и создаете и применяете их на основе на схема, которая работает для вашей организации. Некоторые примеры — роли сервера и приложение. роли. Дополнительные сведения о группах безопасности и сетевых списках контроля доступа см. В разделе «Безопасность» далее в этом руководстве.
Независимые таблицы маршрутизации, настроенные для каждой частной подсети для управления потоком из трафик внутри и за пределами Amazon VPC. Общедоступные подсети используют единую маршрутизацию стол, потому что все они используют один и тот же интернет-шлюз в качестве единственного маршрута для связи с то Интернет.
Высокодоступные шлюзы NAT, если они поддерживаются, вместо экземпляров NAT. Шлюзы NAT предлагают основные преимущества с точки зрения развертывания, доступности и обслуживания. За Больше информацию см. сравнение, приведенное в документации Amazon VPC.
Резервная емкость для дополнительных подсетей для поддержки вашей среды по мере ее роста или меняется со временем.
Дополнительные сведения об этих передовых методах см. В следующих документация:
Размер подсети
В этом Кратком руководстве размер блоков CIDR, используемых в подсетях, основан на типичном развертывание, где частные подсети имели бы примерно вдвое больше экземпляров найти в публичные подсети.Однако во время развертывания вы можете использовать параметры блока CIDR изменить размер возможности CIDR для удовлетворения ваших архитектурных потребностей.
При выделении подсети по умолчанию VPC делится на типы подсетей, а затем сегментированы по зонам доступности, как показано на рисунке 1. Быстрый запуск предоставляет следующие размеры блока CIDR по умолчанию для максимального увеличения емкости:
| VPC | 10.0,0.0 / 16 | |
|---|---|---|
| Частные подсети A | 10.0.0.0/17 | |
| Зона доступности 1 | 10.0,0.0 / 19 | |
| Зона доступности 2 | 10.0.32.0/19 | |
| Зона доступности 3 | 10.0,64,0 / 19 | |
| Зона доступности 4 | 10.0.96.0/19 | |
| Общедоступные подсети | 10.0,128,0 / 18 | |
| Зона доступности 1 | 10.0.128.0/20 | |
| Зона доступности 2 | 10.0,144,0 / 20 | |
| Зона доступности 3 | 10.0.160.0/20 | |
| Зона доступности 4 | 10.0,176,0 / 20 | |
| Частные подсети B с выделенными настраиваемая сеть ACL | 10.0.192.0/19 | |
| Зона доступности 1 | 10.0,192,0 / 21 | |
| Зона доступности 2 | 10.0.200.0/21 | |
| Зона доступности 3 | 10.0.208.0 / 21 | |
| Зона доступности 4 | 10.0.216.0/21 | |
| Емкость резервной подсети | 10.0,224,0 / 19 | |
| Зона доступности 1 | 10.0.224.0/21 | |
| Зона доступности 2 | 10.0,232,0 / 21 | |
| Зона доступности 3 | 10.0.240.0/21 | |
| Зона доступности 4 | 10.0,248,0 / 21 | |
В качестве альтернативы могут возникнуть ситуации, когда вы захотите разделить области CIDR по разделение VPC на зоны доступности, а затем на типы подсетей. Рекомендуемый CIDR блоки для максимизации емкости для этого сценария следующие:
| VPC | 10.0,0.0 / 16 | |
|---|---|---|
| Зона доступности 1 | 10.0.0.0/18 | |
| Частная подсеть A | 10.0,0.0 / 19 | |
| Публичная подсеть | 10.0.32.0/20 | |
| Частная подсеть B | 10.0,48,0 / 21 | |
| Запасная подсеть вместимость | 10.0.56.0/21 | |
| Зона доступности 2 | 10.0,64,0 / 18 | |
| Частная подсеть A | 10.0.64.0/19 | |
| Публичная подсеть | 10.0,96,0 / 20 | |
| Частная подсеть B | 10.0.112.0/21 | |
| Емкость резервной подсети | 10.0,120,0 / 21 | |
| Зона доступности 3 | 10.0.128.0/18 | |
| Частная подсеть A | 10.0,128,0 / 19 | |
| Публичная подсеть | 10.0.160.0/20 | |
| Частная подсеть B | 10.0,176,0 / 21 | |
| Емкость резервной подсети | 10.0.184.0/21 | |
| Зона доступности 4 | 10.0,192,0 / 18 | |
| Частная подсеть A | 10.0.192.0/19 | |
| Публичная подсеть | 10.0,224,0 / 20 | |
| Частная подсеть B | 10.0.240.0/21 | |
| Емкость резервной подсети | 10.0,248,0 / 21 | |
Для настройки диапазонов CIDR для этого сценария или для реализации собственной сегментации стратегии вы можете настроить параметры быстрого запуска, описанные в шаге 2. Дополнительные сведения о VPC и размере подсети см. В документации AWS.
Архитектура, этапы проектирования, Fontan Architecture
Есть 5 этапов проектирования архитектурных услуг. Это (по порядку) схематический дизайн, разработка дизайна, строительная документация, торги и управление строительством. Эти этапы представляют собой разбивку того, как архитекторы определяют свои дизайнерские услуги. Это этапы роли архитектора в дизайне.
В этой статье мы обсудим этапы проектирования, определенные Американским институтом архитекторов. Пять этапов проектирования позволяют архитекторам разделить выполняемую работу на категории. Чтобы все было легко понять. Этапы проектирования представляют собой схему процесса проектирования.
Предварительное проектирование и 5 этапов проектирования
Есть пять этапов проектирования. В целях данного обсуждения мы не будем рассматривать предварительное проектирование или технико-экономическое обоснование как один из этапов.Хотя мы предоставим краткое описание предпроектирования. Приведенные ниже проценты показывают, какая часть гонорара архитектора будет выделена на данный этап. Например, схематический дизайн составляет примерно 15% работы архитектора.
Процент архитектурных сборов может варьироваться, указанные основаны на нашем опыте работы с типичным проектом. Разбивка архитектурных сборов — это общее руководство по распределению ресурсов архитектора в рамках данного проекта. Этапы проектирования —
- Схематическое проектирование 15% архитектурных сборов — может варьироваться от 10% до 25%
- Разработка проекта 20% архитектурных сборов — может варьироваться от 10% до 25%
- Строительная документация 40% архитектурных сборов — может варьироваться от 35% до 50%
- Торги 5% сборов за архитектуру — может немного отличаться от 5%
- Управление строительства 20% сборов за архитектуру — может варьироваться от 20% до 30%
Разбивка платы за архитектуру будет зависеть от конкретных потребностей и типа проекта.Например, если клиент запрашивает несколько вариантов дизайна, физическую модель и 3D-рендеринг, этап схемы может быть немного выше, чем обычно. Кроме того, разные архитектурные бюро могут предложить различную разбивку платы на этапах архитектурного проектирования.
Этапы проектирования Видео Объяснение
Ниже находится видео на Youtube о этапах проектирования, которое я сделал, а также письменное описание.
Предпроектная фаза / ТЭО
Предпроектные архитектурные услуги
Предварительное проектирование — это общий термин для обозначения того, что мы делаем перед тем, как приступить к проектированию здания.Это будет включать предварительное исследование со стороны владельца недвижимости и архитектора. Заказчики не всегда нанимают архитектора на эту часть. В нашей фирме мы довольно часто оказываем предпроектные архитектурные услуги. Это может включать в себя помощь застройщикам в принятии решения о покупке недвижимости. Мы часто проводим анализ зонирования на этапе предварительного проектирования, чтобы определить, что мы можем построить. Кроме того, в предварительном проектировании проводятся геодезия и анализ участка. Клиент получает обследование собственности лицензированным землемером, а не архитектором.
Разработчик может захотеть установить бюджет проекта на этапе предварительного проектирования архитектуры. Чтобы узнать больше о предварительном дизайне, ознакомьтесь с другим постом, который мы написали на Pre Design Architecture . По сути, предварительный дизайн будет определять информацию, необходимую для начала проектирования. Вот несколько факторов, которые следует учитывать:
- Анализ участка
- Геодезические, геотехнические, финансовые и т. Д.
- Если мы имеем дело с существующим зданием: тестирование асбеста, тестирование свинца или исследование других опасных материалов.
- Анализ зонирования / Анализ кода
- Определите, что вы можете построить, в зависимости от использования и размера.
- Конкретные проблемы кода, которые могут повлиять на проект.
- Объем проекта
- Заказчик должен максимально точно определить объем работ по проекту.
- Цели проекта
- Строительная программа
- Строительная программа — это список предлагаемых вариантов использования.
- Составление бюджета проекта
- График проекта
- Иногда это может быть слишком предварительным для установления.
- Выбор проектной группы
Схема (SD)
Схема проектирования — это первая фаза проектирования. На его долю будет приходиться примерно 15% работы архитектора, а значит, и гонорары за весь проект. Конечно, проценты могут колебаться.В схематическом дизайне архитектор и владелец обсуждают проект и любые требования, предоставленные владельцем. Архитектор проводит предварительное исследование и анализ собственности. Анализ будет включать вопросы зонирования и строительного кода, которые могут повлиять на разработку, а также на анализ участка. Программирование — это часть схематического дизайна. Программирование — это когда клиент предоставляет архитектору список того, какие помещения входят в здание. Архитектор устанавливает размер, расположение и отношения между всеми пространствами.
Основная цель схематического проектирования — разработать форму и размер здания с помощью некоторого базового проекта. В Схематике мы разрабатываем генплан и базовый дизайн экстерьера. На этапе схематического проектирования мы более или менее выясняем, как здание будет выглядеть и работать. На этапе разработки схемы много набросков, много встреч с клиентами и базовый дизайн. В целом это самое интересное для клиентов. Схема — это то, где вы действительно делаете общий дизайн, но не вникаете в подробности.
Как только базовый проект зафиксирован и архитектор предоставит клиенту чертежи, архитектор и владелец согласны перейти к следующему этапу проектирования. Развитие дизайна.
Схематическое изображение плана расположения
Этап разработки проекта (DD)
Фаза разработки дизайна будет составлять примерно 20% работы архитекторов и гонораров. При разработке дизайна архитектор и владелец будут работать вместе, чтобы выбрать материалы, включая внутреннюю отделку и такие изделия, как окна.двери, приспособления, бытовая техника и т. д. Архитектор будет пересматривать чертежи с большей конкретностью и детализацией, чем в схематическом дизайне. Начнется проектирование конструкции, водопровода, электричества, систем отопления / вентиляции, анализа энергии и любых других систем для конкретного проекта. В конце разработки дизайна следует продолжить выбор продукта и системного проектирования. Этот этап завершается, когда дизайн интерьера и экстерьера здания согласовывается владельцем и архитектором.Ниже представлен 3D-рендеринг дома после завершения разработки дизайна. На следующем изображении представлена схема дома, на которой показаны некоторые из имеющихся систем и материалов.
Разработка дизайна Визуализация
Чертежи архитектора Разработка проекта
Строительная документация (CD)
Этап строительной документации является самым крупным из всех этапов для архитектора и составляет около 40% работы архитектора и сборов.Хотя процент может немного отличаться от проекта к проекту или от различных архитектурных фирм. На этапе строительной документации архитектор и инженеры завершают весь технический дизайн и проектирование, включая проектирование конструкций и детализацию, системы отопления, кондиционирования и вентиляции, водопроводные, электрические, газовые, энергетические расчеты, а также выбираются и планируются все продукты и материалы.
Архитектор создает несколько наборов чертежей, включая набор документов для утверждения в Департаменте строительства и отдельный набор строительных чертежей.Вам не нужно отправлять полный комплект компакт-дисков в Департамент строительства. Например, DOB не заботится о том, какой тип плитки или шкафов для ванной вы собираетесь использовать. В нашей архитектурной фирме мы обычно составляем строительную документацию, создавая отдельные чертежи, адаптированные для каждого типа работы. Например, электрик получает свои собственные чертежи, на которых показаны только электромонтажные работы, а подрядчик по бетону получает чертежи только для фундаментов и бетонных работ. Это уменьшает путаницу на сайтах вакансий и позволяет каждому оценить работу и точно знать, за что они несут ответственность.Ниже представлен лист из нашей строительной документации с деталями конструкции внешней стены.
Строительная документация архитектора
Торги
Торги не требуют пояснений. В это время владелец готовится выбрать подрядчика для работы и подписать контракты на продолжение строительства. Обычно это отнимает у архитекторов 5% времени и гонораров. Несколько подрядчиков подают заявки на выполнение работ, или клиент может напрямую нанять подрядчика, не получая конкурентных предложений. Роль архитектора здесь будет заключаться в оказании помощи клиенту.Ответим на вопросы подрядчика, предоставим дополнительную документацию по запросу подрядчика. Этот этап можно начать в самом начале проекта. Вам не нужно ждать завершения всех строительных документов, но в этом случае цена будет более точной.
Если в начале процесса у вас есть точный бюджет, мы можем порекомендовать вам заранее нанять подрядчика для консультации. Генеральный директор может с самого начала просмотреть схематический дизайн, разработку проекта и строительные чертежи, чтобы гарантировать, что проект находится в рамках указанного бюджета.Только подрядчик может гарантировать цену на строительство. Архитекторы и сметчики, предоставившие бюджеты, не могут гарантировать эти цены, но могут предоставить и обосновать бюджетные цены.
Строительное управление (CA)
Этап архитектурных услуг Строительной администрацией является заключительным этапом. CA и в большинстве случаев составляет не более 20% рабочего времени и гонораров архитекторов. Хотя этот этап является самым продолжительным, он обычно не включает в себя большую часть работы архитекторов.В типовых проектах архитектор НЕ курирует строительство. Архитектор будет периодически посещать стройплощадку, чтобы увидеть, как идет работа, и убедиться, что подрядчик следует планам. При необходимости архитектор может просматривать ежемесячные счета подрядчика, чтобы подтвердить завершение работ. Архитектор будет готов ответить на вопросы и предоставить дополнительную информацию по возникающим проблемам. На этом этапе нередко возникают некоторые дополнительные услуги для архитектора из-за заказов на изменение.
В Нью-Йорке Департамент строительства (DOB) требует от архитекторов проведения многократных проверок хода работ и специальных проверок.Архитектор и инженеры должны подавать в DOB технические отчеты. Инспекции прогресса проводит архитектор. Для специальных проверок может потребоваться стороннее инспекционное агентство со специальной лицензией.
Архитектор остается на проекте, пока здание не будет завершено. Заключительные проверки завершены, и владелец получает свидетельство о занятости.
Строительное управление
Этапы проектирования
Приведенная выше информация представляет собой базовую разбивку по этапам проектирования Architect. Процент предоставленной стоимости будет колебаться от проекта к проекту и между различными архитектурными бюро. Эти этапы общепризнаны большинством архитекторов США. Архитектор должен быть в состоянии дать вам подробное объяснение своей структуры оплаты. Если вы хотите узнать больше, вы можете увидеть другой пост, который мы написали на Architectural Fees .
Как я буду настойчиво напоминать людям, если вы планируете нанять архитектора, всегда не забудьте нанять зарегистрированных архитекторов , которые имеют лицензию и застрахованы в вашем штате!
Этапы процесса архитектурного проектирования
Как архитектор изучаю архитектурный процесс.В этой статье мы рассмотрели некоторые из основных концепций, относящихся к 5 этапам проектирования. Этот пост не предполагает охватить все возможные проблемы или условия, но дает общий обзор темы.
Спасибо, что прочитали нашу запись в блоге об этапах архитектурного проектирования.
Если у вас есть какие-либо вопросы или комментарии, не стесняйтесь оставлять их в разделе комментариев ниже.
Связаться с Fontan Architecture
Хорхе Фонтан
Этот пост написал Хорхе Фонтан, AIA, зарегистрированный архитектор и владелец нью-йоркской архитектурной фирмы Fontan Architecture.Хорхе Фонтан получил 3 степени в области изучения архитектуры, в том числе две степени Городского университета Нью-Йорка и степень магистра в области передового архитектурного дизайна Колумбийского университета. Хорхе имеет опыт строительства и занимается архитектурой в течение 15 лет, где он проектировал реконструкцию и новые разработки для различных типов зданий.
Архитектура
Переключить навигацию- Релизы
- Сообщество
- Поддержка
- Поддержка сообщества
- Коммерческая поддержка
- Обучение
- Бюллетени по безопасности
- Сообщить о проблеме безопасности
- Блог
- GitHub
- Предприятие
- Бесплатное обучение
- Около
- Установить Calico
- Сети
- Безопасность
- Операции
- Справка
- Примечания к выпуску
- Калико Энтерпрайз
Около
Калико Сети Сеть Kubernetes Сетевая политика Сервисы Kubernetes Kubernetes Ingress Kubernetes Egress eBPFУстановить Calico
Kubernetes Быстрый старт Управляемое публичное облако Сервис Amazon Elastic Kubernetes (EKS) Google Kubernetes Engine (GKE) Служба IBM Cloud Kubernetes (IKS) Служба Microsoft Azure Kubernetes (AKS) Самоуправляемое публичное облако Самоуправляемый Kubernetes в AWS Самоуправляемый Kubernetes в GCE Самоуправляемый Kubernetes в Azure Самоуправляемый Kubernetes в DigitalOcean Самоуправляемый локальный Установите Calico для локальных развертываний Настроить манифесты OpenShift Системные Требования Установка Фланель Установите Calico для политики и фланель для сети Перенос кластера из фланелевой сети в сеть Calico Calico для Windows Ограничения и известные проблемы Быстрый старт Демо базовой политики Kubernetes Требования Установите Calico для Windows Установите Calico для Windows на Rancher RKE OpenShift Установите Calico для Windows на OpenShift Создайте kubeconfig для узлов Windows Запуск и остановка служб Calico для Windows Устранение неполадок Calico для Windows K3s Быстрый старт Установка с несколькими узлами MicroK8s Minikube Калико трудный путь Введение Поднимите Kubernetes Хранилище данных Calico Настроить пулы IP Установите плагин CNI Установить Typha Установить бязь / узел Настроить пиринг BGP Тестовая сеть Проверить сетевую политику Конечный пользователь RBAC Интеграция Istio Системные Требования OpenStack Обзор Системные Требования Установка Обзор Ubuntu Red Hat Enterprise Linux DevStack Проверьте свое развертывание Некластерные хосты О некластерных хостах Системные Требования Установка Установка контейнера Бинарная установка с менеджером пакетов Бинарная установка без диспетчера пакетов бязь Установить calicoctl Настроить calicoctl Обзор Настройте calicoctl для подключения к хранилищу данных etcd Настройте calicoctl для подключения к хранилищу данных Kubernetes API.Сети
Определите лучший вариант сети Настроить сеть Настроить пиринг BGP Настроить оверлейную сеть Рекламируйте IP-адреса службы Kubernetes Настройте MTU для максимальной производительности сети Настроить исходящий NAT Использовать IPVS kube-proxy Повышение производительности сети Istio Настроить управление IP-адресами Начните с управления IP-адресами Настроить автоопределение IP Настроить двойной стек или только IPv6 Настройте плоскость управления Kubernetes для работы через IPv6 Добавить плавающий IP-адрес в модуль Использовать определенный IP-адрес для модуля Назначение IP-адресов на основе топологии Переход с одного пула IP на другой Изменить размер блока пула IP Ограничить модуль на использование IP-адреса в определенном диапазоне Сеть Calico для OpenStack Настроить машину для разработки Подготовьте гостевую ОС ВМ для IPv6 IP-адресация и подключение Метки конечных точек и политика оператора Настроить системы для использования с Calico Подробная семантика Плавающие IP-адреса Сервисные IP-адреса Маршруты хоста Несколько регионов Курыр Интерпретация Calico вызовов Neutron API Калико Энтерпрайз Видимость сети Федерация Консоль пользователяБезопасность
Принять модель сети с нулевым доверием для обеспечения безопасности Начните с политики Калико политика Начать работу с сетевой политикой Calico Начните работу с сетевой политикой Calico для OpenStack Руководство по политике Calico Политика Kubernetes Начать работу с сетевой политикой Kubernetes Политика Kubernetes, демонстрация Политика Kubernetes, базовое руководство Политика Kubernetes, расширенное руководство Включить запретить по умолчанию Правила политики Основные правила Правила пространства имен Правила сервисных аккаунтов Правила для внешних IP-адресов или сетей Правила ICMP / ping Политика для хостов Защитить хосты Защитите ноды Kubernetes Руководство по защите хоста Применить политику к хосту перенаправленного трафика Политика в отношении услуг Применение политики к портам узла Kubernetes Применение политики к сервисам, предоставляемым извне как IP-адреса кластера Политика Istio Применение сетевой политики для Istio Использовать методы и пути HTTP в правилах политики Применение сетевой политики с помощью учебника Istio Политика в отношении экстремального трафика Включение рабочих нагрузок с экстремально высоким числом подключений Защита от DoS-атак Шифровать трафик модуля внутри кластера Безопасная связь компонентов Calico Настроить шифрование и аутентификацию Расписание Typha на известные узлы Защитите конечные точки Calico Prometheus Безопасные сеансы BGP Калико Энтерпрайз Видимость сети Расширенный контроль доступа на выходе Расширенный контроль соответствия Федерация Защита от угроз Консоль пользователя Рабочий процесс политикиОперации
Обновить Kubernetes OpenShift OpenStack Перенести хранилище данных из etcd в Kubernetes Планета данных eBPF Включение плоскости данных eBPF eBPF на EKS Поиск проблемы Монитор Мониторинг показателей компонентов Визуализировать показатели компонентов Удалить узлы из кластера Устранение неполадок Устранение неполадок Журналы компонентов eBPF DataplaneСправка
Установка бязь Обзор Создайте заменить применять удалять получить патч метка конвертировать ipam Обзор выпуск Показать настроить узел Обзор бежать положение дел диагнозы система проверки хранилище данных Обзор Мигрировать Обзор экспорт импорт замок разблокировать версия Определения ресурсов Обзор Конфигурация BGP Одноранговый узел BGP Конфигурация Феликса Политика глобальной сети Набор глобальной сети Конечная точка хоста Пул IP Конфигурация контроллеров Kubernetes Сетевая политика Сетевой набор Узел Профиль Конечная точка рабочей нагрузки Настройка etcd RBAC Обзор Создание сертификатов Создание пользователей и ролей Сегментирование etcd на Kubernetes (базовое) Сегментирование etcd на Kubernetes (продвинутый) Калико-ключ и префиксы пути бязь / узелЧто я могу сделать со степенью архитектора?
Диплом архитектора дает вам визуальные, плановые и технические навыки, означающие, что вы будете настроены на творческую карьеру, основанную на дизайне
Варианты работы
Вакансии, непосредственно связанные с вашей степенью, включают:
Рабочие места, где ваша степень будет Полезные включают:
Помните, что многие работодатели принимают заявки от выпускников любой степени, так что не ограничивайте свое мышление работами, перечисленными здесь.
Потратьте несколько минут, чтобы ответить на викторину о подборе вакансий и узнать, какая карьера вам подойдет.
Попробуйте подобрать вакансию
Опыт работы
Получение опыта работы или места на производстве будет полезным. Эти типы возможностей помогут вам развить понимание архитектурных практик и отрасли изнутри. Вы установите важные контакты и укрепите свою уверенность, а также свои навыки. Получение опыта работы также демонстрирует потенциальным работодателям, что вы трудолюбивы, надежны и мотивированы.
Если вы собираетесь получить квалификацию архитектора, обращайтесь к практике непосредственно в поисках опыта работы. Попробуйте архитектурные, дизайнерские или строительные фирмы. Многие предлагают стажировку в течение лета.
Смежные области, такие как ландшафтный дизайн, искусственная среда и другие методы проектирования, также предоставляют хорошие возможности для развития вашего опыта. Практикуйте свои навыки рисования и изготовления моделей и будьте в курсе текущих тенденций в отрасли.
Узнайте больше об опыте работы и стажировках.
Типичные работодатели
Архитекторы работают в различных учреждениях. Выпускников могут нанимать небольшие фирмы с числом сотрудников менее десяти или более крупные практики, которые включают другие области, такие как планирование, градостроительство или строительство.
Работодатели государственного сектора, такие как местные органы власти и жилищные ассоциации, используют значительную часть специалистов в своих отделах планирования, в то время как некоторые крупные организации, такие как банки и супермаркеты, могут иметь собственные архитектурные группы.
Найдите информацию о работодателях в сфере недвижимости и строительства, машиностроения и производства, а также в других сферах занятости.
Работодатели нанимают выпускников архитектуры сейчас
Выпускник по коммерции
- Berkeley Group
- Различные местоположения
- £ 24 501–27 000 фунтов стерлингов
Выпускник строительства
- Berkeley Group
- Различные местоположения
- £ 24 501- 27 000 фунтов стерлингов
- Berkeley Group
- Различные местоположения
- £ 24 501–27 000 фунтов стерлингов
- математику, дизайн и рисование
- ИТ-навыки, e.г. автоматизированное проектирование (САПР)
- навыки управления проектами
- способность решать проблемы аналитически, логически
- способность работать в команде
- письменное и устное общение в различных условиях
- исследовательские навыки
- способность принимать решения
- адаптируемость и гибкость для решения непредвиденных ситуаций, когда это необходимо
- способность отражать и улучшать вашу профессиональную деятельность.
Технический выпускник
Навыки для вашего CV
Изучая архитектуру, вы разовьете определенные навыки, а также ряд переносимых основных навыки, которые включают:
Дальнейшее обучение
Большинство выпускников архитектуры в конечном итоге переходят на завершающие этапы квалификаций, признанных RIBA и Регистрационным советом архитекторов (ARB), чтобы продвигаться к получению квалификации и практике в качестве зарегистрированных архитекторов.
Помимо получения дополнительной квалификации в области архитектуры, вы можете выбрать аспирантуру по другим техническим предметам, таким как инженерия, дизайн или информатика, или по предметам, выходящим за рамки технических и строительных областей.
Чтобы получить дополнительную информацию о дальнейшем обучении и найти интересующий вас курс, см. Степени магистра и выполните поиск по курсам для аспирантов.
Чем занимаются выпускники архитектуры?
Более половины выпускников архитектуры (54%) работают техниками по архитектуре и градостроительству через шесть месяцев после выпуска, еще 7% работают дипломированными архитектурными технологами, а 4% — архитекторами.
| Место назначения | Процент |
|---|---|
| Занятые | 69.9 |
| Дальнейшее обучение | 10,7 |
| Работа и учеба | 8,5 |
| Безработные | 5 |
| Прочие | 5,9 |