Правила выполнения проектной документации архитектурных решений: ГОСТ 21.501-2011 СПДС. Правила выполнения рабочей документации архитектурны…

ГОСТ 21.501-2011 СПДС. Правила выполнения рабочей документации архитектурны…

ГОСТ 21.501-2011

Группа Ж01

____________________________________________________________________
Текст Сравнения ГОСТ 21.501-2018 с ГОСТ 21.501-2011 см. по ссылке.
— Примечание изготовителя базы данных.
__________________________________________________________________

ОКС 01.100.30

Дата введения 2013-05-01

Цели, основные принципы и основной порядок проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0-92 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2-2009 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, применения, обновления и отмены»

Сведения о стандарте

1 РАЗРАБОТАН Открытым акционерным обществом «Центр методологии нормирования и стандартизации в строительстве» (ОАО «ЦНС»)

2 ВНЕСЕН Техническим комитетом ТК 465 «Строительство»

3 ПРИНЯТ Межгосударственной научно-технической комиссией по стандартизации, техническому нормированию и оценке соответствия в строительстве (МНТКС) (протокол от 8 декабря 2011 г. N 39)

За принятие проголосовали:

4 Приказом Федерального агентства по техническому регулированию и метрологии от 11 октября 2012 г. N 485-ст введен в действие в качестве национального стандарта Российской Федерации с 1 мая 2013 г.

5 ВЗАМЕН ГОСТ 21.501-93


Информация о введении в действие (прекращении действия) настоящего стандарта публикуется в ежемесячно издаваемом указателе «Национальные стандарты».

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

1 Область применения

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

Состав и правила оформления рабочей документации конструктивных решений металлических строительных конструкций установлены в ГОСТ 21.502.

2 Нормативные ссылки

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

ГОСТ 2.109-73 Единая система конструкторской документации. Основные требования к чертежам

ГОСТ 2.113-75 Единая система конструкторской документации. Групповые и базовые конструкторские документы

ГОСТ 2.306-68 Единая система конструкторской документации. Обозначения графические материалов и правила их нанесения на чертежах

ГОСТ 21.101-97* Система проектной документации для строительства. Основные требования к проектной и рабочей документации
_______________
* На территории Российской Федерации действует ГОСТ Р 21.1101-2009.


ГОСТ 21.110-95 Система проектной документации для строительства. Правила выполнения спецификации оборудования, изделий и материалов

ГОСТ 21.113-88 Система проектной документации для строительства. Обозначения характеристик точности

ГОСТ 21.201-2011 Система проектной документации для строительства. Условные изображения элементов зданий, сооружений и конструкций

ГОСТ 21.205-93 Система проектной документации для строительства. Условные обозначения элементов санитарно-технических систем

ГОСТ 21.502-2007 Система проектной документации для строительства. Правила выполнения проектной и рабочей документации металлических конструкций

ГОСТ 82-70 Прокат стальной горячекатаный широкополосный универсальный. Сортамент

ГОСТ 103-2006 Прокат сортовой горячекатаный полосовой. Сортамент

ГОСТ 5781-82 Сталь горячекатаная для армирования железобетонных конструкций. Технические условия

ГОСТ 6727-80 Проволока из низкоуглеродистой стали холоднотянутая для армирования железобетонных конструкций. Технические условия

ГОСТ 8510-86 Уголки стальные горячекатаные неравнополочные. Сортамент

ГОСТ 13015-2003 Изделия железобетонные и бетонные для строительства. Общие технические требования. Правила приемки, маркировки, транспортирования и хранения

ГОСТ 14098-91 Соединения сварные арматуры и закладных изделий железобетонных конструкций. Типы, конструкции и размеры

ГОСТ 21780-2006 Система обеспечения точности геометрических параметров в строительстве. Расчет точности

ГОСТ 23009-78 Конструкции и изделия бетонные и железобетонные сборные. Условные обозначения (марки)

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

3 Термины и определения

В настоящем стандарте пр

ГОСТ 21.501-2011 Система проектной документации для строительства (СПДС). Правила выполнения рабочей документации архитектурных и конструктивных решений

ГОСТ 21.501-2011

Группа Ж01

____________________________________________________________________
Текст Сравнения ГОСТ 21.501-2018 с ГОСТ 21.501-2011 см. по ссылке.
— Примечание изготовителя базы данных.
__________________________________________________________________

ОКС 01.100.30

Дата введения 2013-05-01

Цели, основные принципы и основной порядок проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0-92 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2-2009 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, применения, обновления и отмены»

1 РАЗРАБОТАН Открытым акционерным обществом «Центр методологии нормирования и стандартизации в строительстве» (ОАО «ЦНС»)

2 ВНЕСЕН Техническим комитетом ТК 465 «Строительство»

3 ПРИНЯТ Межгосударственной научно-технической комиссией по стандартизации, техническому нормированию и оценке соответствия в строительстве (МНТКС) (протокол от 8 декабря 2011 г. N 39)

За принятие проголосовали:

4 Приказом Федерального агентства по техническому регулированию и метрологии от 11 октября 2012 г. N 485-ст введен в действие в качестве национального стандарта Российской Федерации с 1 мая 2013 г.

5 ВЗАМЕН ГОСТ 21.501-93


Информация о введении в действие (прекращении действия) настоящего стандарта публикуется в ежемесячно издаваемом указателе «Национальные стандарты».

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

1 Область применения

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

Состав и правила оформления рабочей документации конструктивных решений металлических строительных конструкций установлены в ГОСТ 21.502.

2 Нормативные ссылки

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

ГОСТ 2.109-73 Единая система конструкторской документации. Основные требования к чертежам

ГОСТ 2.113-75 Единая система конструкторской документации. Групповые и базовые конструкторские документы

ГОСТ 2.306-68 Единая система конструкторской документации. Обозначения графические материалов и правила их нанесения на чертежах

ГОСТ 21.101-97* Система проектной документации для строительства. Основные требования к проектной и рабочей документации
_______________
* На территории Российской Федерации действует ГОСТ Р 21.1101-2009.


ГОСТ 21.110-95 Система проектной документации для строительства. Правила выполнения спецификации оборудования, изделий и материалов

ГОСТ 21.113-88 Система проектной документации для строительства. Обозначения характеристик точности

ГОСТ 21.201-2011 Система проектной документации для строительства. Условные изображения элементов зданий, сооружений и конструкций

ГОСТ 21.205-93 Система проектной документации для строительства. Условные обозначения элементов санитарно-технических систем

ГОСТ 21.502-2007 Система проектной документации для строительства. Правила выполнения проектной и рабочей документации металлических конструкций

ГОСТ 82-70 Прокат стальной горячекатаный широкополосный универсальный. Сортамент

ГОСТ 103-2006 Прокат сортовой горячекатаный полосовой. Сортамент

ГОСТ 5781-82 Сталь горячекатаная для армирования железобетонных конструкций. Технические условия

ГОСТ 6727-80 Проволока из низкоуглеродистой стали холоднотянутая для армирования железобетонных конструкций. Технические условия

ГОСТ 8510-86 Уголки стальные горячекатаные неравнополочные. Сортамент

ГОСТ 13015-2003 Изделия железобетонные и бетонные для строительства. Общие технические требования. Правила приемки, маркировки, транспортирования и хранения

ГОСТ 14098-91 Соединения сварные арматуры и закладных изделий железобетонных конструкций. Типы, конструкции и размеры

ГОСТ 21780-2006 Система обеспечения точности геометрических параметров в строительстве. Расчет точности

ГОСТ 23009-78 Конструкции и изделия бетонные и железобетонные сборные. Условные обозначения (марки)

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

ГОСТ 21.501-2018 Система проектной документации для строительства (СПДС). Правила выполнения рабочей документации архитектурных и конструктивных решений

ГОСТ 21.501-2018

____________________________________________________________________
Текст Сравнения ГОСТ 21.501-2018 с ГОСТ 21.501-2011 см. по ссылке.
— Примечание изготовителя базы данных.
__________________________________________________________________

МКС 01.100.30

Дата введения 2019-06-01

Предисловие

Цели, основные принципы и основной порядок проведения работ по межгосударственной стандартизации установлены в ГОСТ 1.0-2015 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2-2015 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены»

Сведения о стандарте

1 РАЗРАБОТАН Акционерным обществом «Центр технического и сметного нормирования в строительстве» (АО «ЦНС»)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 465 «Строительство»

3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 30 августа 2018 г. N 111-П)

За принятие проголосовали:

4 Приказом Федерального агентства по техническому регулированию и метрологии от 18 декабря 2018 г. N 1121-ст введен в действие межгосударственный стандарт ГОСТ 21.501-2018 в качестве национального стандарта Российской Федерации с 1 июня 2019 г.

5 ВЗАМЕН ГОСТ 21.501-2011

Информация об изменениях к настоящему стандарту публикуется в ежегодном информационном указателе «Национальные стандарты«, а текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты«. В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе «Национальные стандарты«. Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

1 Область применения

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

Состав и правила оформления рабочей документации конструктивных решений металлических строительных конструкций установлены в ГОСТ 21.502, деревянных конструкций — в ГОСТ 21.504.

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие межгосударственные стандарты:

ГОСТ 2.109-73 Единая система конструкторской документации. Основные требования к чертежам

ГОСТ 2.113-75 Единая система конструкторской документации. Групповые и базовые конструкторские документы

ГОСТ 2.306-68 Единая система конструкторской документации. Обозначения графические материалов и правила их нанесения на чертежах

ГОСТ 21.001-2013 Система проектной документации для строительства. Общие положения

ГОСТ 21.101-97* Система проектной документации для строительства. Основные требования к проектной и рабочей документации

________________

* В Российской Федерации действует ГОСТ Р 21.1101-2013.

ГОСТ 21.110-2013 Система проектной документации для строительства. Спецификация оборудования, изделий и материалов

ГОСТ 21.113-88 Система проектной документации для строительства. Обозначения характеристик точности

ГОСТ 21.201-2011 Система проектной документации для строительства. Условные графические изображения элементов зданий, сооружений и конструкций

ГОСТ 21.205-2016 Система проектной документации для строительства. Условные обозначения элементов трубопроводных систем зданий и сооружений

ГОСТ 21.302-2013 Система проектной документации для строительства. Условные графические обозначения в документации по инженерно-геологическим изысканиям

ГОСТ 21.502-2016 Система проектной документации для строительства. Правила выполнения рабочей документации металлических конструкций

ГОСТ 21.504-2016 Система проектной документации для строительства. Правила выполнения рабочей документации деревянных конструкций

ГОСТ 13015-2012 Изделия бетонные и железобетонные для строительства. Общие технические требования. Правила приемки, маркировки, транспортирования и хранения

ГОСТ 14098-2014 Соединения сварные арматуры и закладных изделий железобетонных конструкций. Типы, конструкции и размеры

ГОСТ 21780-2006 Система обеспечения точности геометрических параметров в строительстве. Расчет точности

ГОСТ 23009-2016 Конструкции и изделия бетонные и железобетонные сборные. Условные обозначения (марки)

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

3 Термины и определения

В настоящем стандарте применены термины по ГОСТ 21.001, а также следующие термины с соответствующими определениями:

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

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

3.3 план: Вид сверху или горизонтальный разрез здания или сооружения.

3.4 фасад: Ортогональная проекция наружной стены здания или сооружения на вертикальную плоскость.

Примечание — Различают фасады главный, боковой, дворовый и др.

3.5 строительная конструкция: Часть здания или сооружения, выполняющая определенные несущие, ограждающие и (или) эстетические функции.

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

3.7 элемент строительной конструкции: Составная часть сборной или монолитной конструкции.

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

4 Общие положения

ГОСТ Р 21.1101-2013 Система проектной документации для строительства (СПДС). Основные требования к проектной и рабочей документации (с Поправкой)

ГОСТ Р 21.1101-2013

Группа Ж01

___________________________________________________________________

ОКС 01.100.30

Дата введения 2014-01-01

Предисловие

1 РАЗРАБОТАН Открытым акционерным обществом «Центр методологии нормирования и стандартизации в строительстве» (ОАО «ЦНС»)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 465 «Строительство»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 11 июня 2013 г. N 156-ст

4 В настоящем стандарте реализованы нормы Градостроительного кодекса Российской Федерации от 29 декабря 2004 г. N 190-ФЗ [1]

5 ВЗАМЕН ГОСТ Р 21.1101-2009


Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru)


ВНЕСЕНА поправка, опубликованная в ИУС N 1, 2015 год

Поправка внесена изготовителем базы данных

1 Область применения

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

Примечание — В настоящем стандарте понятие «строительство» включает в себя новое строительство, реконструкцию, техническое перевооружение и капитальный ремонт объектов капитального строительства.


Общие правила выполнения и комплектования графической и текстовой документации, установленные в 4.1 и в разделах 5 и 8, и правила внесения изменений, установленные в разделе 7, распространяются также на отчетную техническую документацию по результатам инженерных изысканий для строительства.

2 Нормативные ссылки

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

ГОСТ Р 6.30-2003 Унифицированные системы документации. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов

ГОСТ Р 21.1001-2009 Система проектной документации для строительства. Общие положения

ГОСТ Р 21.1002-2008 Система проектной документации для строительства. Нормоконтроль проектной и рабочей документации

ГОСТ Р 21.1003-2009 Система проектной документации для строительства. Учет и хранение проектной документации

ГОСТ Р 21.1703-2000 Система проектной документации для строительства. Правила выполнения рабочей документации проводных средств связи

ГОСТ 2.004-88 Единая система конструкторской документации. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах вывода ЭВМ

ГОСТ 2.051-2006 Единая система конструкторской документации. Электронные документы. Общие положения

ГОСТ 2.052-2006 Единая система конструкторской документации. Электронная модель изделия. Общие положения

ГОСТ 2.101-68 Единая система конструкторской документации. Виды изделий

ГОСТ 2.102-68 Единая система конструкторской документации. Виды и комплектность конструкторских документов

ГОСТ 2.105-95 Единая система конструкторской документации. Общие требования к текстовым документам

ГОСТ 2.106-96 Единая система конструкторской документации. Текстовые документы

ГОСТ 2.109-73 Единая система конструкторской документации. Основные требования к чертежам

ГОСТ 2.113-75 Единая система конструкторской документации. Групповые и базовые конструкторские документы

ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия

ГОСТ 2.301-68 Единая система конструкторской документации. Форматы

ГОСТ 2.302-68 Единая система конструкторской документации. Масштабы

ГОСТ 2.303-68 Единая система конструкторской документации. Линии

ГОСТ 2.304-81 Единая система конструкторской документации. Шрифты чертежные

ГОСТ 2.305-2008 Единая система конструкторской документации. Изображения — виды, разрезы, сечения

ГОСТ 2.306-68 Единая система конструкторской документации. Обозначения графические материалов и правила их нанесения на чертежах

ГОСТ 2.307-2011 Единая система конструкторской документации. Нанесение размеров и предельных отклонений

ГОСТ 2.308-2011 Единая система конструкторской документации. Указания допусков формы и расположения поверхностей

ГОСТ 2.309-73 Единая система конструкторской документации. Обозначения шероховатости поверхностей

ГОСТ 2.310-68 Единая система конструкторской документации. Нанесение на чертежах обозначений покрытий, термической и других видов обработки

ГОСТ 2.311-68 Единая система конструкторской документации. Изображение резьбы

ГОСТ 2.312-72 Единая система конструкторской документации. Условные изображения и обозначения швов сварных соединений

ГОСТ 2.313-82 Единая система конструкторской документации. Условные изображения и обозначения неразъемных соединений

ГОСТ 2.314-68 Единая система конструкторской документации. Указания на чертежах о маркировании и клеймении изделий

ГОСТ 2.315-68 Единая система конструкторской документации. Изображения упрощенные и условные крепежных деталей

ГОСТ 2.316-2008 Единая система конструкторской документации. Правила нанесения надписей, технических требований и таблиц на графических документах. Общие положения

ГОСТ 2.317-2011 Единая система конструкторской документации. Аксонометрические проекции

ГОСТ 2.501-88 Единая система конструкторской документации. Правила учета и хранения

ГОСТ 2.511-2011 Единая система конструкторской документации. Правила передачи электронных конструкторских документов. Общие положения

ГОСТ 2.512-2011 Единая система конструкторской документации. Правила выполнения пакета данных для передачи электронных конструкторских документов. Общие положения

ГОСТ 21.110-95 Система проектной документации для строительства. Правила выполнения спецификации оборудования, изделий и материалов

ГОСТ 21.113-88 Система проектной документации для строительства. Обозначения характеристик точности

ГОСТ 21.114-95 Система проектной документации для строительства. Правила выполнения эскизных чертежей общих видов нетиповых изделий

ГОСТ 21.302-96 Система проектной документации для строительства. Условные графические обозначения в документации по инженерно-геологическим изысканиям

ГОСТ 21.408-93 Система проектной документации для строительства. Правила выполнения рабочей документации автоматизации технологических процессов

ГОСТ 21.501-2011 Система проектной документации для строительства. Правила выполнения рабочей документации архитектурных и конструктивных решений

ГОСТ 21.709-2011 Система проектной документации для строительства. Правила выполнения рабочей документации линейных сооружений гидромелиоративных систем

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

3 Термины, определения и сокращения

3.1 Термины и определения

В настоящем стандарте применены термины по [1], ГОСТ Р 21.1001, ГОСТ Р 21.1002, ГОСТ Р 21.1003, а также следующие термины с соответствующими определениями:

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

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

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

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

3.1.5

3.1.6

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

3.1.8

ГОСТ 21.501-2011. Система проектной документации для строительства. Правила выполнения рабочей документации архитектурных и конструктивных решений /

Общероссийский классификатор стандартов → ОБЩИЕ ПОЛОЖЕНИЯ. ТЕРМИНОЛОГИЯ. СТАНДАРТИЗАЦИЯ. ДОКУМЕНТАЦИЯ → Технические чертежи *Графические обозначения для технических чертежей см. 01.080.30 *Автоматизированное проектирование см. 35.240.10 → Строительные чертежи *Включая чертежи для гражданского строительства

ГОСТ 21.501-2011. Система проектной документации для строительства. Правила выполнения рабочей документации архитектурных и конструктивных решений

Настоящий стандарт устанавливает состав и правила оформления рабочей документации архитектурных и конструктивных решений зданий и сооружений различного назначения, а также рабочей документации на строительные изделия.
Состав и правила оформления рабочей документации конструктивных решений металлических строительных конструкций установлены в ГОСТ 21.502

ГОСТ 21.501-2011: Система проектной документации для строительства. Правила выполнения рабочей документации архитектурных и конструктивных решений

ГОСТ 21.501-2011: Система проектной документации для строительства. Правила выполнения рабочей документации архитектурных и конструктивных решений

Терминология ГОСТ 21.501-2011: Система проектной документации для строительства. Правила выполнения рабочей документации архитектурных и конструктивных решений оригинал документа:

3.3 строительная конструкция: Часть здания или сооружения, выполняющая определенные несущие, ограждающие и (или) эстетические функции.

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

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

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

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

3.5 элемент строительной конструкции: Составная часть сборной или монолитной конструкции.

Словарь-справочник терминов нормативно-технической документации. academic.ru. 2015.

• ГОСТ 17.4.2.01-81: Охрана природы. Почвы. Номенклатура показателей санитарного состояния
• ГОСТ 21.601-2011: Система проектной документации для строительства. Правила выполнения рабочей документации внутренних систем водоснабжения и канализации

Смотреть что такое «ГОСТ 21.501-2011: Система проектной документации для строительства. Правила выполнения рабочей документации архитектурных и конструктивных решений» в других словарях:

• ГОСТ Р 21.1101-2013: Система проектной документации для строительства. Основные требования к проектной и рабочей документации — Терминология ГОСТ Р 21.1101 2013: Система проектной документации для строительства. Основные требования к проектной и рабочей документации оригинал документа: атрибут документа: Идентифицированная (именованная) характеристика части реквизита.… …   Словарь-справочник терминов нормативно-технической документации

• ГОСТ 21.501-2011 — Действует с 01.05.2013 Система проектной документации для строительства. Правила выполнения рабочей документации архитектурных и конструктивных решений Взамен: ГОСТ 21.501 93 раздел 01.100.30 …   Указатель национальных стандартов 2013

• чертежи конструктивных решений — 3.2 чертежи конструктивных решений: Чертежи, отображающие в виде условных изображений строительные конструкции (железобетонные, каменные, металлические, деревянные, пластмассовые и т.п.), примененные в зданиях или сооружениях, и их взаимное… …   Словарь-справочник терминов нормативно-технической документации

• чертежи архитектурных решений — 3.1 чертежи архитектурных решений: Чертежи здания или сооружения, отображающие авторский замысел объекта с комплексным решением пространственных, планировочных, функциональных и эстетических требований к нему, зафиксированный в виде контурного… …   Словарь-справочник терминов нормативно-технической документации

• элемент — 02.01.14 элемент (знак символа или символ) [element <symbol character or symbol>]: Отдельный штрих или пробел в символе штрихового кода либо одиночная многоугольная или круглая ячейка в матричном символе, формирующие знак символа в… …   Словарь-справочник терминов нормативно-технической документации

• строительная конструкция — 3.2 строительная конструкция: Часть здания или другого строительного сооружения, выполняющая определенные несущие, ограждающие и (или) эстетические функции. Источник …   Словарь-справочник терминов нормативно-технической документации

• строительное изделие — 3.1 строительное изделие: Изделие, предназначенное для применения в качестве элемента строительных конструкций зданий и других сооружений. Источник …   Словарь-справочник терминов нормативно-технической документации

• элемент строительной конструкции — 3.5 элемент строительной конструкции: Составная часть сборной или монолитной конструкции. Источник …   Словарь-справочник терминов нормативно-технической документации

• строительный материал — 3.6 строительный материал: Материал, в том числе штучный, предназначенный для изготовления строительных изделий и возведения строительных конструкций зданий и сооружений. Источник …   Словарь-справочник терминов нормативно-технической документации

Стандарт TOGAF, версия 9.2

31. Архитектурные артефакты

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

31.1 Основные понятия

Архитектурные артефакты создаются для описания системы, решения или состояния предприятия. Обсуждаемые концепции в этом разделе были адаптированы более формальные определения, содержащиеся в ISO / IEC / IEEE 42010: 2011 и ISO / IEC / IEEE 15288: 2015. Они показаны на Рисунке 31-1.

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

«Система» — это комбинация взаимодействующих элементов, организованных для достижения одной или нескольких заявленных целей.

«Архитектура» системы — это фундаментальные концепции или свойства системы в ее среде, воплощенные в ее элементы, отношения, а также в принципах его построения и развития.

«Описание архитектуры» — это рабочий продукт, используемый для выражения архитектуры; коллекция архитектурных представлений и моделей которые вместе документируют архитектуру.

«Заинтересованные стороны» — это отдельные лица, группы, организации или их классы, заинтересованные в системе.

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

«Архитектурный взгляд» — это представление системы с точки зрения связанного набора проблем.Он состоит из одного или больше архитектурных моделей системы.

«Архитектурная модель» — это представление интересующего объекта. Модель обеспечивает меньший масштаб, упрощенную и / или абстрактное представление предмета.

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

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

«Тип модели» устанавливает соглашения для типа моделирования.

Точка зрения архитектуры ссылается на один или несколько типов моделей; представление архитектуры включает одну или несколько моделей.

«Библиотека точек обзора» — это набор спецификаций точек зрения на архитектуру, содержащихся в Справочной библиотеке. часть репозитория архитектуры.

• Вид архитектуры — это то, что вы видите; точка зрения на архитектуру — это то место, откуда вы смотрите — с точки зрения или перспектива, определяющая то, что вы видите
• Точки зрения на архитектуру являются общими и могут храниться в библиотеках для повторного использования; вид архитектуры всегда специфичен для архитектура для которой создается
• Каждое архитектурное представление имеет связанную архитектурную точку зрения, которая описывает его, по крайней мере, неявно.

  ISO / IEC / IEEE 42010: 2011 побуждает архитекторов явно определять точки зрения на архитектуру.Проводя различие между содержание и схема представления могут сначала показаться ненужными накладными расходами, но они предоставляют механизм для повторного использования архитектуры точки зрения на разные архитектуры.

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

Примечание:

Термины «озабоченность» и «требование» не являются синонимами. Обеспокоенность — это область интересов. Итак, надежность системы может быть озабоченность / область интереса для некоторых заинтересованных сторон. Причина, по которой архитекторам следует выявлять проблемы и связывать их с с точки зрения архитектуры, заключается в том, чтобы гарантировать, что эти проблемы будут решены каким-либо образом с помощью моделей архитектуры. За Например, если единственной точкой зрения архитектуры, выбранной архитектором, является точка зрения структурной архитектуры, то надежность проблемы почти наверняка не решаются, поскольку они не могут быть представлены в структурной модели.В рамках этой заботы у заинтересованных сторон может быть много разных требований: разные классы пользователей могут иметь очень разные требования к надежности для разные возможности системы.

Заботы — это корень процесса разложения на требования. Проблемы представлены в архитектуре этими требования. Требования должны быть SMART (например, конкретные показатели).

31.1.1 Простой пример архитектурной точки зрения и архитектурной точки зрения

Для многих архитектур полезной архитектурной точкой зрения является точка зрения на бизнес-области, что можно проиллюстрировать примером из Сама Open Group.

Точка зрения архитектуры определяется следующим образом:

Соответствующий вид архитектуры Open Group (в 2017 г.) показан на рис. 31-2. .

31.2 Разработка архитектурных представлений в ADM

31.2.1 Общие правила

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

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

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

Как объяснено в Части II: Метод разработки архитектуры (ADM), разработка Представления архитектуры — это итеративный процесс. Типичный переход от бизнеса к технологиям с использованием такой техники, как бизнес-сценарии (см. Руководство серии TOGAF®: Бизнес-сценарии) для правильного определения всех относящихся к делу проблем; и из от общего обзора до подробностей более низкого уровня, постоянно обращаясь к проблемам и требованиям заинтересованных сторон на протяжении всего процесса.

Более того, каждая из этих последовательностей должна выполняться для двух различных сред: существующей среды. (называемый базовым уровнем в ADM) и целевой средой. Архитектор должен разработать соответствующие архитектурные представления как базовая архитектура, так и целевая архитектура. Это обеспечивает контекст для анализа пробелов в конце Фазы B, C и D ADM, который устанавливает элементы базовой архитектуры, подлежащие переносу, и элементы, которые должны быть добавлено, удалено или заменено.

Весь этот процесс объясняется в Части III, 23. Пробел Анализ .

31.2.2 Процесс создания архитектурного представления

Как упоминалось выше, структура TOGAF поощряет, но не требует обязательного использования ISO / IEC / IEEE 42010: 2011. В Таким образом, следующее описание охватывает как ситуацию, когда ISO / IEC / IEEE 42010: 2011 был принят, так и ситуацию, в которой он не был принят.

ISO / IEC / IEEE 42010: 2011 сам по себе не требует какого-либо специального процесса для разработки точек зрения на архитектуру или создание просмотров из них.Если ISO / IEC / IEEE 42010: 2011 был принят и стал устоявшейся практикой в организации, часто можно создать необходимые представления для конкретной архитектуры, выполнив следующие шаги:

1. Обратитесь к существующей библиотеке точек зрения на архитектуру
2. Выберите подходящие точки зрения на архитектуру (на основе заинтересованных сторон и проблем, которые необходимо охватить просмотров)
3. Создание представлений системы с использованием выбранных точек зрения на архитектуру в качестве шаблонов

Ожидается, что этот подход принесет следующие преимущества:

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

Однако всегда могут возникнуть ситуации, в которых требуется архитектурное представление, для которого нет подходящей архитектуры. точка обзора была предопределена.Это также ситуация, конечно, когда организация еще не внедрила ISO / IEC / IEEE 42010: 2011 в свою архитектурную практику и создал библиотеку архитектурных точек зрения.

В каждом случае архитектор может выбрать новую точку зрения на архитектуру, которая будет охватывать выдающиеся необходимо, а затем сгенерировать из него архитектурное представление. (Это рекомендованная практика ISO / IEC / IEEE 42010: 2011.) В качестве альтернативы, более прагматический подход может быть столь же успешным: архитектор может создать специальное архитектурное представление для конкретной системы и позже рассмотрим, следует ли явно определять обобщенную форму точки зрения неявной архитектуры и сохранять в библиотека, чтобы ее можно было использовать повторно.(Это один из способов создания библиотеки точек зрения на архитектуру на начальном этапе.)

Независимо от контекста, архитектор должен знать, что каждое архитектурное представление имеет свою точку зрения на архитектуру. как минимум неявно, и что определение точки зрения на архитектуру систематическим способом (как рекомендовано ISO / IEC / IEEE 42010: 2011) будет помощь в оценке его эффективности; т.е. покрывает ли точка зрения архитектуры соответствующие проблемы заинтересованных сторон?

31,3 Представления, инструменты и языки

Необходимость архитектурных представлений и процесс их разработки после ADM объяснены выше.Этот Раздел описывает отношения между представлениями архитектуры, инструментами, используемыми для их разработки и анализа, и стандартным языком. обеспечение взаимодействия между инструментами.

31.3.1 Обзор

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

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

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

Вопросы, относящиеся к оценке инструментов для работы с архитектурой, подробно обсуждаются в Части V, 38. Инструменты для разработки архитектуры .

31.4 Архитектура и точки зрения на архитектуру

31.4.1 Пример архитектурных представлений и архитектурных точек зрения

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

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

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

Архитектурная точка зрения — это модель (или описание) информации, содержащейся в представлении. В нашем примере один точка зрения на архитектуру — это описание того, как пилот видит систему, а другая точка зрения на архитектуру — это то, как Контроллер видит систему.

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

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

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

Итак, по сути, каждая точка зрения на архитектуру — это абстрактная модель того, как все заинтересованные стороны определенного типа — все пилоты или все диспетчеры — просмотрите систему аэропорта.

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

Интерфейс для человека, использующего инструмент, обычно близок к модели и языку, связанному с точка зрения на архитектуру. Уникальные инструменты пилота — это указатели уровня топлива, высоты, скорости и местоположения. Главный инструмент контроллер радар. Обычный инструмент — радио.

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

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

31.4.2 Виды архитектуры и точки зрения на архитектуру в архитектуре предприятия

Теперь сопоставим этот пример с архитектурой предприятия. Рассмотрим двух заинтересованных сторон в новой небольшой вычислительной среде. система: пользователи и разработчики.

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

Архитектурная точка зрения пользователя состоит из всех способов, которыми пользователь взаимодействует с системой, не видя никаких деталей, таких как приложения или системы управления базами данных (СУБД).

Точка зрения разработчика на архитектуру — это производительность и инструменты, и не включает такие вещи, как актуальные данные в реальном времени и связи с потребителями.

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

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

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

31.4.3 Необходимость общего языка и совместимых инструментов для описания архитектуры

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

Вопросы, относящиеся к оценке инструментов для работы с архитектурой, подробно обсуждаются в Части В, 38.Инструменты для разработки архитектуры .

31,5 Выводы

В этом разделе делается попытка структурированного рассмотрения представлений, но это ни в коем случае не полный трактат по Просмотры.

В целом, структура TOGAF включает концепции и определения, представленные в ISO / IEC / IEEE 42010: 2011, в частности, концепции, которые помогают направлять разработку архитектурного представления и делают архитектурное представление действенным. Эти концепции можно резюмировать как:

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

31.6 архитектурных артефактов от ADM Phase

Каталог, матрица и концепция схем

Метамодель контента используется как метод упорядоченного структурирования архитектурной информации, чтобы она могут быть обработаны для удовлетворения потребностей заинтересованных сторон. Большинству заинтересованных сторон в архитектуре на самом деле не нужно знать, что Метамодель архитектуры касается и занимается только конкретными вопросами, такими как «какие функции поддерживает это приложение?», «на какие процессы повлияет этот проект?» и т. д.Чтобы удовлетворить потребности этих заинтересованных сторон, концепции TOGAF используются строительные блоки, каталоги, матрицы и диаграммы.

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

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

Матрицы — это сетки, которые показывают отношения между двумя или более объектами модели. Матрицы используются для представления отношения, которые основаны на списках, а не графически в их использовании (например, матрица CRUD, показывающая, какие приложения Создание, чтение, обновление и удаление данных определенного типа трудно представить визуально).

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

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

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

Взаимодействие между метамоделью, строительными блоками, диаграммами и заинтересованными сторонами показано на рисунке 31-3. На рисунке 31-4 показаны артефакты, связанные с основным контентом. метамодель и каждое из расширений контента.

Ниже приведены рекомендуемые артефакты для производства на каждом этапе ADM.

31.6.1 Предварительный этап

Ниже описаны каталоги, матрицы и диаграммы, которые могут быть созданы в рамках Предварительного этапа, как перечислен в части II, 5.4 выхода .

Каталог Принципов включает в себя принципы Бизнеса и Архитектуры, которые описывают, что такое «хорошее» решение или архитектура должны выглядеть. Принципы используются для оценки и согласования результатов для архитектурных решений. Принципы также используются в качестве инструмента для архитектурного управления инициативами изменений.

Каталог Принципов содержит следующие сущности метамоделей:

31.6.2 Этап A: Видение архитектуры

Ниже описаны каталоги, матрицы и диаграммы, которые могут быть созданы в рамках фазы A (архитектурное видение). как указано в 6.4 Выходы .

Матрица карт заинтересованных сторон

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

Понимание заинтересованных сторон и их требований позволяет архитектору сосредоточить усилия на областях, отвечающих потребностям. заинтересованных сторон (см. Часть III, 21.Управление заинтересованными сторонами ).

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

Схема производственно-сбытовой цепочки

Диаграмма цепочки создания стоимости дает общее представление о предприятии и о том, как оно взаимодействует с внешним миром. Мир. В отличие от более формальной диаграммы функциональной декомпозиции, разработанной на этапе B (бизнес-архитектура), значение Value Цепная диаграмма фокусируется на презентационном воздействии.

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

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

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

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

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

Карта бизнес-возможностей

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

Карта потока создания ценности

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

31.6.3 Этап B: Бизнес-архитектура

Ниже описаны каталоги, матрицы и диаграммы, которые могут быть созданы на этапе B (бизнес-архитектура). как указано в 7.4 Выходы .

Каталог актеров / организаций

Целью каталога Организации / Актера является составление окончательного списка всех участников, которые взаимодействуют с ИТ, включая пользователей и владельцев ИТ-систем.

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

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

Каталог организации / исполнителя содержит следующие сущности метамодели:

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

Каталог драйверов / целей / задач

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

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

Каталог Драйвер / Цель / Задача содержит следующие сущности метамодели:

• Организационное подразделение
• Драйвер
• Гол
• Объектив
• Размер (может быть включен)

Ролевой каталог

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

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

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

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

Каталог ролей содержит следующие сущности метамодели:

Каталог бизнес-услуг / функций

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

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

Каталог бизнес-услуг / функций содержит следующие сущности метамодели:

• Организационное подразделение
• Бизнес-функция
• Бизнес-сервис
• Служба информационной системы (может быть включена сюда по желанию)

Расположение Каталог

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

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

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

Каталог Location содержит следующие объекты метамодели:

Процесс / Событие / Управление / Каталог продукции

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

Например, каталог Процесс / Событие / Контроль / Продукт позволяет предприятию видеть отношения между процессами и подпроцессы, чтобы идентифицировать полную цепочку воздействий, возникающих в результате изменения процесса высокого уровня.

Каталог Процесс / Событие / Контроль / Продукт содержит следующие сущности метамодели:

• Процесс
• Событие
• Контроль
• Товар

Каталог договоров / мероприятий

Каталог «Контракты / меры» содержит список всех согласованных контрактов на оказание услуг и мер, связанных с ними. контракты.Он формирует основной список уровней обслуживания, согласованных на предприятии.

Каталог контрактов / мер содержит следующие сущности метамоделей:

• Бизнес-сервис
• Служба информационной системы (опционально)
• Контракт
• Размер

Каталог бизнес-возможностей

Полный перечень определенных способностей, которыми компания может обладать или которыми может обмениваться для достижения определенных цель.

Каталог потока создания ценности

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

Каталог этапов потока создания ценности

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

• Бизнес-возможности
• Поток создания ценности

Матрица бизнес-взаимодействия

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

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

Матрица бизнес-взаимодействия показывает следующие сущности и отношения метамодели:

• Организация
• Бизнес-функция
• Бизнес-сервис
• Business Service взаимодействует с Business Service Relations
• Business Service зависит от Business Service Relations

Матрица актеров / ролей

Цель этой матрицы — показать, какие участники и какие роли выполняют, поддерживая определение безопасности и требования к навыкам.

Понимание взаимоотношений между исполнителями и ролями — ключевой вспомогательный инструмент при определении потребностей в обучении и безопасности пользователей. настройки и управление организационными изменениями.

Матрица «Актер / Роль» показывает следующие сущности и отношения метамодели:

• Актер
• Роль
• Актер выполняет Ролевые отношения

Поток создания ценности / Матрица возможностей

Цель этой матрицы — показать возможности, необходимые для поддержки каждого этапа потока создания ценности.

Матрица стратегии / возможностей

Цель этой матрицы — показать возможности, необходимые для поддержки конкретных заявлений стратегии.

Матрица возможностей / организации

Цель этой матрицы — показать орган.

Общие архитектуры веб-приложений | Документы Microsoft

• 01.12.2020
• 19 минут для чтения

В этой статье

«Если вы думаете, что хорошая архитектура стоит дорого, попробуйте плохую архитектуру.» — Брайан Фут и Джозеф Йодер

Большинство традиционных приложений .NET развертываются как отдельные блоки, соответствующие исполняемому файлу или одному веб-приложению, работающему в одном домене приложений IIS. Этот подход является простейшей моделью развертывания и очень хорошо обслуживает множество внутренних и небольших общедоступных приложений. Однако даже с учетом этой единой единицы развертывания большинство нетривиальных бизнес-приложений выигрывают от некоторого логического разделения на несколько уровней.

Что такое монолитное приложение?

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

Универсальные приложения

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

Новый проект ASP.NET Core, независимо от того, создается он в Visual Studio или из командной строки, начинается как простой монолит «все в одном». Он содержит все поведение приложения, включая логику представления, бизнеса и доступа к данным. На рис. 5-1 показана файловая структура приложения для одного проекта.

Рисунок 5-1. Приложение ASP.NET Core для одного проекта.

В сценарии одного проекта разделение задач достигается за счет использования папок.Шаблон по умолчанию включает отдельные папки для обязанностей шаблона MVC для моделей, представлений и контроллеров, а также дополнительные папки для данных и служб. При таком расположении детали представления должны быть максимально ограничены папкой Views, а детали реализации доступа к данным должны быть ограничены классами, хранящимися в папке Data. Бизнес-логика должна находиться в сервисах и классах в папке Models.

Простое монолитное решение для одного проекта имеет ряд недостатков.По мере роста размера и сложности проекта количество файлов и папок также будет расти. Проблемы пользовательского интерфейса (UI) (модели, представления, контроллеры) находятся в нескольких папках, которые не сгруппированы по алфавиту. Эта проблема только усугубляется, когда дополнительные конструкции уровня пользовательского интерфейса, такие как фильтры или ModelBinders, добавляются в их собственные папки. Бизнес-логика разбросана между папками Models и Services, и нет четкого указания, какие классы, в каких папках должны зависеть от других.Такая неорганизованность на уровне проекта часто приводит к спагетти-коду.

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

Что такое слои?

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

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

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

  версия: '3'

Сервисы:
  eshopwebmvc:
    изображение: eshopwebmvc
    сборка:
      контекст:.
      dockerfile: src / Web / Dockerfile
    окружающая обстановка:
      - ASPNETCORE_ENVIRONMENT = Разработка
    порты:
      - «5106: 5106»

сети:
  по умолчанию:
    внешний:
      имя: нат
  

  ИЗ mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR / приложение

КОПИРОВАТЬ * .sln.
КОПИРОВАТЬ. .
WORKDIR / приложение / src / Интернет
RUN dotnet restore

RUN dotnet publish -c Release -o out

ИЗ mcr.microsoft.com/dotnet/aspnet:5.0 как среда выполнения
WORKDIR / приложение
КОПИРОВАТЬ --from = build / app / src / Web / out./

ENTRYPOINT ["dotnet", "Web.dll"]