Модель захмана на примере школы

Обновлено: 08.07.2024

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

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

Основные правила заполнения таблицы следующие:

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

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

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

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

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

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

Теперь детализировано рассмотрим каждый столбец.

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

Колонка функций (ответ на вопрос "КАК?") предназначена для последовательной детализации описания того, как миссия предприятия реализуется на уровне отдельных операций. В частности, на первом уровне достаточным будет простое перечисление процессов. Второй уровень будет содержать модель процессов, которая впоследствии детализируется в операции над данными и архитектуру приложений (уровень 3), методы классов (уровень 4), программный код (уровень 5) и, наконец, исполняемые модули. При этом, начиная с 4-го уровня, рассмотрение ведется уже не в рамках предприятия в целом, а по отдельным подсистемам или приложениям.

Следующая колонка (вопрос "ГДЕ?") определяет пространственное распределение компонент системы и сетевую организацию. На уровне планирования бизнеса здесь достаточно определить расположение всех производственных объектов. На следующем уровне эти объекты объединяются в модель со связями, характеризующими взаимодействие между собой. На третьем уровне системной архитектуры осуществляется привязка компонент информационной системы к узлам сети. Четвертый уровень служит для определения физической реализации в терминах аппаратных платформ, системного программного обеспечения, а также средств промежуточного уровня, используемых для интеграции различных компонент информационной системы между собой. На пятом уровне определяются используемые протоколы и спецификации каналов связи. Последний уровень описывает функционирование реализованной сети.

Колонка таблицы, отвечающая на вопрос "КТО?", определяет участников процесса. На уровне планирования бизнеса здесь представлен список подразделений предприятия и выполняемые ими функции. На следующем уровне приводится полная организационная диаграмма, а также должны быть определены общие требования к информационной безопасности. Далее последовательно определяются участники бизнес-процессов и их роли, требования к интерфейсам пользователя и правила доступа к отдельным объектам, физическая их реализация на уровне кода или операторов определения доступа к таблицам в СУБД. Последний уровень описывает обученных пользователей системы.

Последняя колонка ("ПОЧЕМУ?" или "ЗАЧЕМ?") служит для определения мотивации и задает порядок перехода от задач бизнеса к требованиям и элементам информационных систем. Исходной точкой является бизнес-стратегия, которая затем последовательно транслируется в бизнес-план, затем в правила и ограничения для реализации бизнес-процессов, а на уровне 4 — в соответствующие приложения, необходимые для включения в состав информационных систем и, в дальнейшем, в их физическую реализацию. Такая модель описания полезна для идентификации возможных ограничений. Эти ограничения могут распространяться как от верхних уровней к нижним (например, указание руководства компании о выборе тех или иных средств, продуктов или принципов работы), так и в обратном направлении (например, возможности существующих технологий беспроводной связи в значительной степени определяют спектр предлагаемых услуг и организацию бизнес-процессов у провайдеров этих услуг).

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

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

Значительный вклад в развитие концепции архитектуры предприятия был сделан Дж. Захманом (John A. Zachman). С момента публикации "модель Захмана для описания архитектуры предприятия" прошла определенную эволюцию в своем развитии и стала основой, на базе которой многие организации создавали свои собственные методики описания информационной инфраструктуры предприятия. С 1987 года, когда была предложена первая версия этой модели, расширенная впоследствии в работах 1992-96 гг., она была использована достаточно большим количеством крупных компаний, входящих в список 2000 крупнейших корпораций мира, такими, например, как General Motors, Bank of America и др. Модель Захмана также послужила основой для создания целого ряда других методик и моделей описания архитектуры предприятия, таких как Федеральная Архитектура США (FEAF – Federal Enterprise Architecture Framework), Методика описания архитектуры Open Group (TOGAF – The Open Group Architecture Framework), Методика описания архитектуры министерства обороны США (DoDAF – Department of Defence Architecture Framework). Отметим, что в данном случае в исторически сложившемся переводе названия на русский язык используется именно термин "модель", отражающий прежде всего четкую формальную структуру предложенной Захманом конструкции, хотя по глубине подхода и значимости, скорее, должен был быть применен перевод оригинала "framework" как "методики".

Модель Захмана основана на дисциплине классической архитектуры и обеспечивает общий словарь и набор перспектив, или структур (framework), для описания современных сложных корпоративных систем. По большому счету, наше приведенное выше в "Архитектура предприятия: основные определения" , "Интегрированная концепция и уровни абстракции" описание Архитектуры предприятия следовало, как будет видно далее, принципам, заложенным в модели Захмана. Мы построили некоторую "матрицу" со строками в виде различных уровней абстракции (перспективами) и набором столбцов в виде представлений (областей) архитектуры (см. рис. 4.4), которая в какой-то степени является частью более сложной матрицы, используемой для описания архитектуры в Модели Захмана.

Итак, в своей работе [5.3] Дж. Захман определил Архитектуру предприятия как "набор описательных представлений (моделей), которые применимы для описания Предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)". Термин " архитектура " здесь не случаен, он подчеркивает существующую аналогию между внутренней структурой абстрактного объекта – предприятия и сложного искусственного объекта, такого как здание или орбитальная международная космическая станция (МКС).

Для удобства описания Захман предложил так называемую Модель архитектуры предприятия (Zachman Framework for Enterprise Architecture ). Модель преследует две основные цели – с одной стороны, логически разбить все описание Архитектуры на отдельные разделы для упрощения их формирования и восприятия, с другой – обеспечить возможность рассмотрения целостной Архитектуры с выделенных точек зрения или соответствующих уровней абстракции.

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

Исторически модель Захмана впервые была создана именно для ИТ-систем [5.4]. Этот подход в последующей работе [5.3] был обобщен для рассмотрения не только ИТ-систем, но и для описания предприятия в целом, так что предложенная модель, вообще говоря, может использоваться как средство для описания архитектур сложных производственных систем любого типа.

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

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

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

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

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

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

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

Сам Захман в своем интервью он-лайновому журналу " Enterprise Architect Online " без ложной скромности сравнил свою модель с периодической таблицей элементов Менделеева и назвал ее "периодической таблицей описательных представлений предприятия или двумерной системой, схемой классификации" [5.5]. Это действительно ко многому обязывающее сравнение, но Захман привел следующие аргументы в его пользу: "Вопросы что, как, где, кто, когда и зачем существуют тысячи лет. И они будут существовать еще тысячи лет. Требования к системам, процесс проектирования, производства или концептуальный, логический и физический уровень описания также существуют в течение тысяч лет и будут существовать еще тысячи лет. Логическая структура классификации, схема – неизменны".

В конце концов, как отмечает Захман, коммерческие предприятия и государственные организации должны понимать, что путь к эффективным информационным системам требует систематических подходов в проектировании ( engineering ). Если вы, например, занимаетесь большими проектами, связанными с интеграцией государственных информационных систем, то ". назначить одного ответственного человека – это еще не решение проблемы. Никакого чуда просто так не произойдет. В какой-то момент вы поймете, что настоящий процесс проектирования должен быть реализован для того, чтобы интегрировать эти объекты".

Although information systems architecture is related to strategy, both information strategy and business strategy, this paper deliberately limits itself to architecture and should not be construed as presenting a strategic planning methodology

Впрочем, считать матрицу Захмана инструментом системной архитектуры будет не вполне корректно, так как предметом работы, во-первых, являются информационные системы созданные и используемые в интересах производственной деятельности предприятия, а решаемой проблемой – разобщенность и несогласованность данных, возникающая при интеграции корпоративных систем или их отдельных модулей – во-вторых. Речь скорее идет о том, что мы сегодня называем архитектурой ИТ-решений (Solution Architecture). Просто во времена ранних работ Захмана количество информационных систем в ИТ-ландшафте организаций было не так велико, как сейчас и задача согласования данных и спрямления взаимодействий между ними не выглядела столь утопичной как сегодня.

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

Architect’s drawings
Architect’s plans
Contractor’s plans
Shop plans
Buildings

Речь, как нетрудно заметить, в этом списке идет об этапах работ при строительстве загородного дома. Сначала архитектор обсуждает с заказчиком что необходимо построить. Пузырьковая диаграмма (в оригинальном тексте слово bubble часто используется в кавычках, т.е. речь идет не о традиционной пузырьковой диаграмме). При этом он рисует на салфетке квадратики и кружочки, напоминающие функциональные или ландшафтные карты, о которых так много написано в этом блоге (см., например: Вебинар: визуализация постановки задачи или Карта ИТ-ландшафта). В результате первой беседы получается такая зарисовка(картинка взята из первой статьи Захмана).

Впрочем, я же чуть не забыл рассказать про столбцы. Здесь все еще проще. При строительстве дома они называются: Material, Function и Location. Конечно, в таком виде для описания информационных систем использовать их нельзя. По крайней мере для первого столбца необходимо придумать другое название. Пусть речь идет об информации. И если вещество определяется у нас структурой своих молекул, то информация будет характеризоваться структурой данных (это уже отсебятина). В общем все становится логично и просто и остается для каждой из пятнадцати клеток придумать рекомендации по содержанию моделей и используемой нотации. В итоге имеем:

Не продолжая дальнейший детальный разбор строк и не объясняя отброшенные в начале три правых столбца, хочу обратить ваше внимание на несколько моментов. Последовательность работ, приведенные в матрице в строках, в последующих реинкарнациях архитектурного фреймворка, таких как TAFIM и TOGAF свернется в известное нам кольцо этапов architecture development method. Три столбца первоначальной модели еще встретятся нам в виде столбцов нотации Archimate, как впрочем и идея связи между элементами моделей из разных клеточек, о которой мы сегодня не поговорили. Ну а другие идеи статьи прямиком попадут в IEEE-1471, который преобразуется уже в 2000-ые годы в ISO-42010, а в наши времена и подвергнется переводу на русский язык в виде ГОСТ Р 57100-2016

Является ли полезной модель Захмана? Да, безусловно! По крайней мере до тех пор, пока мы не начинаем её обобщать до инструмента описания галактик и вселенной, а используем по непосредственному назначению – для анализа и проектирования корпоративных информационных систем.

Презентация по теме "Модель Захмана" для студентов 3 курса.

Архитектура предприятия Матрица Захмана

Элементы архитектуры предприятия

Определение

Архитектура предприятия определяет

общую структуру;

функции систем;

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

Контекст разработки архитектуры предприятия

Матрица Захмана

Принцип матрицы

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

- используемые данные (что?);
- процессы и функции (как?);
- места выполнения этих процессов (где?);
- организации и персоналии–участники (кто?);
- управляющие события (когда?);
- цели и ограничения, определяющие работу системы (зачем?).

Принцип матрицы

Первая строка - уровень планирования бизнеса в целом ( бизнес-модель ). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес.

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

Третий уровень ( логическая модель ) соответствует рассмотрению с точки зрения Системного Архитектора.

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

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

4 Zachman Framework

4.1 Хронология рамочных табличек Захмана

Подборка табличек Захмана то ли для архитектуры предприятия, то ли лишь для ИТ-архитектуры (обращаем внимание на названия табличек и названия статей).

Июнь 1984, Zachman84

1984, Zachman84v2

THE ZACHMAN FRAMEWORK EVOLUTION BY JOHN P ZACHMAN

1987, Zachman87 (5х3)

Первая статья Захмана: Zachman J. A. A Framework for Information System Architecture // IBM System Journal. 1987. Vol. 26, No. 3.

Как видим все три таблицы ZF фактически идентичны.

1992, Zachman92 (5х6)

Zachman2k

Иногда вместо матрицы 5х6 упоминают 6х6, т.е. не 30 ячеек Захмана, а 36, что не принципиально, т.к. одни считают последнюю строку за значимую, другие нет, так же, как и не считают нулевую строку (шапку таблицы).

4.2 Что? Где? Когда?

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

Форма Zachman Framework является матрицей 5х6 (6x6), где каждая ячейка содержит набор диаграмм. Матрица выполнена как отчет, позволяющий визуализировать, какая информация доступна на каком уровне (в каком разрезе) на конкретном предприятии.

Структура таблички (фреймворк) Захмана позиционируется как одна из Enterprise Ontology: “учение о сущем” (инструмент мышления), определяющая фундаментальные принципы устройства предприятия, сущностные формы, ключевые элементы и свойства.

Лекция 8: Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF (ссылка на ИНТУИТ удалена по требованию модератора)
или тут
или здесь

4.3 ISA vs EA

Фундаментальная структура
Институт Захмана (ZIFA) утверждает: «есть реальные доказательства того, что наша структура является фундаментальной структурой для архитектуры предприятия.
Таким образом, он дает полный набор описательных представлений, применимых для описания предприятия".
Не видел таких доказательств, где они, где примеры Zachman Framework example?

Framework for household architecture
Для описания своей НА не обязательно пользоваться каркасной табличкой Захмана, она приведена лишь как один из примеров, прежде всего потому, что это первое что приходит в голову для формализации НА.
Есть сомнение, что и другие фреймворки и методологии окажутся более эффективными, в первую очередь потому, что они не ЕА, а лишь ISA (но упорно выдаваемые за ЕА). Есть ли фреймворки, ориентированные на предприятие, а не на его ИТ? Вопрос открытый.

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

5 Введение в объект домохозяйство

5.1 Household

5.2 Основы учета

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

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

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

5.3 Артефакты и ментальные заменители

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

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

5.4 Учет бизнес-процессов

5.5 Продукты

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

6 Некоторые особенности Архитектурики ЕА

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

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

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

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

Заключение

Девиз: Отключи алхимию, включи сознание и нарисуй архитектуру своего домохозяйства!

Читайте также: