Закрыть

Правила выполнения проектной документации архитектурных решений: ГОСТ 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)

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

Краткое наименование страны по МК (ИСО 3166) 004-97

Код страны по МК (ИСО 3166) 004-97

Сокращенное наименование национального органа государственного управления строительством

Азербайджан

AZ

Госстрой

Армения

AM

Министерство градостроительства

Казахстан

KZ

Агентство по делам строительства и жилищно-коммунального хозяйства

Кыргызстан

KG

Госстрой

Молдова

MD

Министерство строительства и регионального развития

Российская Федерация

RU

Департамент архитектуры, строительства и градостроительной политики Министерства регионального развития

Таджикистан

TJ

Агентство по строительству и архитектуре при Правительстве

Узбекистан

UZ

Госархитектстрой

Украина

UA

Министерство регионального развития, строительства и ЖКХ

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)

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

Краткое наименование страны по МК (ИСО 3166) 004-97

Код страны по МК (ИСО 3166) 004-97

Сокращенное наименование национального органа государственного управления строительством

Азербайджан

AZ

Госстрой

Армения

AM

Министерство градостроительства

Казахстан

KZ

Агентство по делам строительства и жилищно-коммунального хозяйства

Кыргызстан

KG

Госстрой

Молдова

MD

Министерство строительства и регионального развития

Российская Федерация

RU

Департамент архитектуры, строительства и градостроительной политики Министерства регионального развития

Таджикистан

TJ

Агентство по строительству и архитектуре при Правительстве

Узбекистан

UZ

Госархитектстрой

Украина

UA

Министерство регионального развития, строительства и ЖКХ

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-П)

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

Краткое наименование страны
по МК (ИСО 3166) 004-97

Код страны
по МК (ИСО 3166) 004-97

Сокращенное наименование национального органа по стандартизации

Армения

AM

Минэкономики Республики Армения

Беларусь

BY

Госстандарт Республики Беларусь

Киргизия

KG

Кыргызстандарт

Россия

RU

Росстандарт

Узбекистан

UZ

Узстандарт

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

___________________________________________________________________
Текст Сравнения ГОСТ Р 21.101-2020 с ГОСТ 21.1101-2013 см. по ссылке;
Текст Сравнения ГОСТ Р 21.1101-2013 с ГОСТ 21.1101-2009 см. по ссылке.
- Примечание изготовителя базы данных.
____________________________________________________________________




ОКС 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

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

[ГОСТ 21.110-95, раздел 3]

3.1.6

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

[ГОСТ 21.114-95, статья 3.1]

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

3.1.8

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

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

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

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

Название на англ.:System of design documents for construction. Rules for execution of the working documentation of architectural and construction solutions
Тип документа:стандарт
Статус документа:действующий
Число страниц:46
Дата актуализации текста:01.08.2013
Дата актуализации описания:01.08.2013
Дата издания:10.06.2013
Дата введения в действие:01.05.2013
Дата последнего изменения:15.07.2013
Взамен:ГОСТ 21.501-93

ГОСТ 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

Стандарт TOGAF, версия 9.2 - Архитектурные артефакты

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

Содержание главы 31.1 Основные понятия | 31.2 Разработка архитектурных представлений в ADM | 31.3 Представления, инструменты и языки | 31.4 Архитектура и точки зрения на архитектуру | 31.5 Выводы | 31.6 Архитектурные артефакты по фазе ADM

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 31-1: Основные архитектурные концепции

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

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

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

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

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

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

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

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

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

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

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

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

Архитектура

Элемент точки обзора

Описание

Заинтересованные стороны

Правление, Генеральный директор

Проблемы

Покажите отношения верхнего уровня между географическими сайтами США и Великобритании и бизнес-функциями.

Техника моделирования

Схема вложенных ящиков.
Внешние коробки = места; внутренние блоки = бизнес-функции.
Семантика вложенности = функции, выполняемые в локациях.

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

Рисунок 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 показаны артефакты, связанные с основным контентом. метамодель и каждое из расширений контента.

Рисунок 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

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

В этой статье

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Слои

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

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

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

Примечание

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

Приложения с традиционной "N-уровневой" архитектурой

Наиболее распространенная организация логики приложения по уровням показана на рисунке 5-2.

Рисунок 5-2. Типичные прикладные слои.

Эти уровни часто сокращенно обозначают как UI, BLL (уровень бизнес-логики) и DAL (уровень доступа к данным). Используя эту архитектуру, пользователи отправляют запросы через слой пользовательского интерфейса, который взаимодействует только с BLL.BLL, в свою очередь, может вызывать DAL для запросов доступа к данным. Уровень пользовательского интерфейса не должен делать какие-либо запросы к DAL напрямую, а также не должен напрямую взаимодействовать с персистентностью через другие средства. Точно так же BLL должен взаимодействовать с постоянством только через DAL. Таким образом, каждый уровень несет свою известную ответственность.

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

На рис. 5-3 показан пример решения, в котором приложение разбито на три проекта по ответственности (или уровням).

Рисунок 5-3. Простое монолитное приложение с тремя проектами.

Хотя это приложение использует несколько проектов для организационных целей, оно по-прежнему развертывается как единое целое, и его клиенты будут взаимодействовать с ним как с единым веб-приложением. Это позволяет упростить процесс развертывания. На рис. 5-4 показано, как такое приложение можно разместить с помощью Azure.

Рисунок 5-4. Простое развертывание веб-приложения Azure

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

Рисунок 5-5. Развертывание веб-приложения в службе приложений Azure

Внутренняя организация этого проекта на несколько проектов на основе ответственности улучшает ремонтопригодность приложения.

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

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

Рисунок 5-6. Масштабирование плана службы приложений в Azure.

Чистая архитектура

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

Эталонное приложение eShopOnWeb использует подход чистой архитектуры для организации своего кода в проекты. Вы можете найти шаблон решения, который вы можете использовать в качестве отправной точки для своего собственного ASP.NET Core, в репозитории ardalis / cleanarchitecture GitHub.

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

Рисунок 5-7. Чистая архитектура; лук вид

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

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

Рисунок 5-8. Чистая архитектура; горизонтальный вид слоя

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

На рис. 5-9 показано более подробное представление архитектуры приложения ASP.NET Core, построенного в соответствии с этими рекомендациями.

Рисунок 5-9. Схема архитектуры ASP.NET Core в соответствии с чистой архитектурой.

Поскольку ядро ​​приложения не зависит от инфраструктуры, очень легко написать автоматизированные модульные тесты для этого уровня.На рисунках 5-10 и 5-11 показано, как тесты вписываются в эту архитектуру.

Рисунок 5-10. Модульное тестирование ядра приложения изолированно.

Рисунок 5-11. Интеграционное тестирование Реализации инфраструктуры с внешними зависимостями.

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

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

Рисунок 5-12. Пример архитектуры времени выполнения приложения ASP.NET Core.

Организационный код в чистой архитектуре

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

Ядро приложения

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

Типы ядер приложений
  • Сущности (классы бизнес-модели, которые сохраняются)
  • Интерфейсы
  • Услуги
  • DTO
Инфраструктура

Проект инфраструктуры обычно включает реализации доступа к данным. В типичном веб-приложении ASP.NET Core эти реализации включают DbContext Entity Framework (EF), любые определенные объекты EF Core Migration и классы реализации доступа к данным.Наиболее распространенный способ абстрагирования кода реализации доступа к данным - использование шаблона проектирования репозитория.

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

Типы инфраструктуры
  • Типы ядра EF ( DbContext , Migration )
  • Типы реализации доступа к данным (репозитории)
  • Сервисы, специфичные для инфраструктуры (например, FileLogger или SmtpNotifier )
Уровень пользовательского интерфейса

Уровень пользовательского интерфейса в ASP.NET Core MVC - это точка входа для приложения. Этот проект должен ссылаться на проект Application Core, а его типы должны взаимодействовать с инфраструктурой строго через интерфейсы, определенные в Application Core. На уровне пользовательского интерфейса не должно быть разрешено прямое создание экземпляров или статические вызовы типов уровня инфраструктуры.

Типы слоев пользовательского интерфейса
  • Контроллеры
  • Фильтры
  • Просмотры
  • Модель
  • ViewModels
  • Запуск

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

Примечание

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

Монолитные приложения и контейнеры

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

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

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

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

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

В дополнение к проблеме «масштабирования всего», изменения в одном компоненте требуют полного повторного тестирования всего приложения и полного повторного развертывания всех экземпляров.

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

Развертывание монолитных приложений в Microsoft Azure может быть достигнуто с помощью выделенных виртуальных машин для каждого экземпляра. Используя масштабируемые наборы виртуальных машин Azure, вы можете легко масштабировать виртуальные машины. Службы приложений Azure могут запускать монолитные приложения и легко масштабировать экземпляры без необходимости управлять виртуальными машинами. Службы приложений Azure также могут запускать отдельные экземпляры контейнеров Docker, что упрощает развертывание. Используя Docker, вы можете развернуть одну виртуальную машину в качестве хоста Docker и запустить несколько экземпляров.Используя балансировщик Azure, как показано на рис. 5-14, вы можете управлять масштабированием.

Развертыванием на различные хосты можно управлять с помощью традиционных методов развертывания. Хостами Docker можно управлять с помощью таких команд, как docker run , выполняемых вручную, или посредством автоматизации, такой как конвейеры непрерывной доставки (CD).

Монолитное приложение, развернутое как контейнер

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

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

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

Вы можете использовать контейнеры Docker для монолитного развертывания более простых веб-приложений. Этот подход улучшает конвейеры непрерывной интеграции и непрерывного развертывания и помогает добиться успеха от развертывания к производственной среде. Больше никаких «Это работает на моей машине, почему не работает в производстве?»

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

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

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

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

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

Намного более простое эталонное приложение eShopOnWeb поддерживает использование монолитного контейнера с одним контейнером. Приложение включает в себя одно веб-приложение, которое включает традиционные представления MVC, веб-API и страницы Razor.Это приложение можно запустить из корня решения с помощью команд docker-compose build и docker-compose up . Эта команда настраивает контейнер для веб-экземпляра, используя Dockerfile , найденный в корне веб-проекта, и запускает контейнер на указанном порту. Вы можете загрузить исходный код этого приложения с GitHub и запустить его локально. Даже это монолитное приложение выигрывает от развертывания в контейнерной среде.

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

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

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

Поддержка докеров

Проект eShopOnWeb работает на .NET. Следовательно, он может работать в контейнерах на базе Linux или Windows. Обратите внимание, что для развертывания Docker вы хотите использовать тот же тип хоста для SQL Server. Контейнеры на базе Linux занимают меньше места и являются предпочтительными.

Вы можете использовать Visual Studio 2017 или более поздней версии, чтобы добавить поддержку Docker в существующее приложение, щелкнув правой кнопкой мыши проект в Solution Explorer и выбрав Добавить > Поддержка Docker . На этом шаге добавляются необходимые файлы и модифицируется проект для их использования. В текущем образце eShopOnWeb эти файлы уже есть.

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

  версия: '3'

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

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

Файл docker-compose.yml ссылается на Dockerfile в проекте Web . Dockerfile используется для указания, какой базовый контейнер будет использоваться и как приложение будет настроено на нем. Web ' Dockerfile :

  ИЗ 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"]
  

Устранение неполадок Docker

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

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

Если вы хотите добавить поддержку Docker в свое приложение с помощью Visual Studio, убедитесь, что Docker Desktop запущен, когда вы это делаете. Мастер не будет работать правильно, если Docker Desktop не запущен при запуске мастера. Кроме того, мастер проверяет ваш текущий выбор контейнера, чтобы добавить правильную поддержку Docker.Если вы хотите добавить поддержку контейнеров Windows, вам необходимо запустить мастер, когда у вас есть рабочий стол Docker с настроенными контейнерами Windows. Если вы хотите добавить поддержку контейнеров Linux, запустите мастер, пока Docker работает с настроенными контейнерами Linux.

Ссылки - Общие веб-архитектуры

РАЗРАБОТКА ДИЗАЙНА В РОССИИ

а. Какова была основная цель специальной комиссии?

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

г. Каков был принцип развития дизайна после 1920 года?

По специальному заказу Совнаркома 25.12.1920 г. было основано несколько Высших художественно-технических мастерских (ВХУТЕМАС). Каждый из них должен был быть учреждением, обучающим искусствам, связанным с промышленностью. Многие архитекторы считали, что они должны разрушить прежнее понимание культуры и только на его руинах они могут построить новую культуру общества. В конце 30-х годов дизайн начал проникать в область обычных товаров: несколько квалифицированных художников были приглашены к участию в создании первого советского телефона, радиоприемника и мебели; позже распространение дизайна коснулось судостроения и автомобилестроения.

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

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

VII. Прочтите Текст III, будьте готовы к аннотации.

ТЕКСТ III

ПЛАНИРОВАНИЕ

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

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *