ГОСТ Архитектура. Национальный стандарт российской федерации системная и программная инженерия описание архитектуры
 Скачать 260.27 Kb.
|
|
Пример - Связи и правила связи используются для того, чтобы выразить и провести в жизнь отношения архитектуры, например такие, как состав, уточнение, согласованность, прослеживаемость, зависимость, ограничение и обязательство. Примечание - Требования при использовании связей и правил связи определены в 5.7. Примеры их использования приведены в A.6 (приложение A). 4.2.7 Архитектурные решения и обоснование Обоснование архитектуры регистрирует разъяснения, оправдания или рассуждения о причинах в принятых решениях архитектуры. Обоснование для решения может включать методологические основы для решения, альтернативы и учет рассматриваемых компромиссов, потенциальные последствия решения и цитирование источников дополнительной информации. Рисунок 3 - Концептуальная модель элементов и связей описания архитектуры Решения относятся к системным интересам, однако между двумя интересами часто не бывает простых связанных решений. Решения могут воздействовать на архитектуру несколькими способами. Они могут быть отражены в описании архитектуры следующим образом: - формулированием требований существования элементов описания архитектуры; - изменением свойств элементов описания архитектуры; - подключением анализа компромиссов для некоторых элементов описания архитектуры, включая иные решения и интересы, в которых имеют (могут иметь) место изменения; - порождением новых интересов. На рисунке 4 отображены понятия, имеющие отношение к решениям архитектуры и их обоснованию. Примечание - Рисунок использует условности для класса диаграмм, определенные в ИСО/МЭК 19501. Рисунок 4 - Концептуальная модель решений архитектуры и обоснование Примечание - Требования, необходимые для того, чтобы охватить решения и обоснование в пределах описания архитектуры, определены в 5.8. 4.3. Процесс архитектуризации в жизненном цикле Процесс архитектуризации способствует разработке, функционированию и сопровождению системы от стадии изначального замысла до выведения ее из эксплуатации при использовании и прекращении применения. Процесс архитектуризации имеет место в пределах контекста проекта и/или организации. Процесс архитектуризации выполняется в пределах всего жизненного цикла системы, а не только в пределах одной стадии жизненного цикла. Поэтому архитектура системы потенциально влияет на процессы в пределах всего жизненного цикла системы. Описание архитектуры - это рабочий продукт, получающийся после выполнения процесса архитектуризации действий в пределах жизненного цикла рассматриваемой системы. Жизненный цикл предписывает стадии и способы, с помощью которых должно быть определено содержание соответствующего описания архитектуры. В случае, когда описание архитектуры получено из единственной деятельности жизненного цикла, ее содержание обычно является результатом многочисленных действий. Описание архитектуры, как альтернатива, может быть осуществлено переработкой информации от других рабочих продуктов, разработанных с помощью действий жизненного цикла. Настоящий стандарт не зависит, не предполагает и не предписывает какого-либо особенного жизненного цикла. Примечание - Приложение C демонстрирует, как настоящий стандарт может использоваться при применении процессов жизненного цикла, определенных в ИСО/МЭК 12207 и ИСО/МЭК 15288. ИСО/МЭК 12207 и ИСО/МЭК 15288 предоставляют различные процессы жизненного цикла для проектирования архитектуры. Это не противоречит понятию того, что архитектуризация выполняется по всему жизненному циклу, по двум причинам: 1) любой процесс из ИСО/МЭК 12207 или ИСО/МЭК 15288 может быть расценен как выполнение по всему жизненному циклу; 2) использование "архитектурного проектирования" в ИСО/МЭК 12207 и ИСО/МЭК 15288 является более узким, чем понятие "архитектуризация" в настоящем стандарте. 4.4. Применения описаний архитектуры У описаний архитектуры существует много применений со стороны различных заинтересованных сторон по всему жизненному циклу системы. Описания архитектуры применяются, но не ограничиваются этим: - в качестве основы системного проекта системы и действий по разработке; - в качестве основы анализа и оценки альтернативных реализаций архитектуры; - в качестве документации в разработке и сопровождении; - для обеспечения документирования существенных аспектов системы, например таких, как: - намеченное использование и окружающая среда; - принципы, предположения и ограничения для проведения будущих изменений; - моменты для обеспечения гибкости или ограничений системы относительно будущих изменений; - решения архитектуры, их обоснования и последствия; - в качестве входов к автоматизированным инструментариям для моделирования, системной имитации и анализа; - для определения группы систем, разделяющих общие свойства (таких, как архитектурные стили, эталонные архитектуры и архитектуры линейки продуктов); - для обеспечения связи между сторонами, вовлеченными в разработку, производство, развертывание, функционирование и сопровождение системы; - в качестве основы для подготовки документов приобретения (например таких, как запросы о предложении и описание работы); - для обеспечения связи между заказчиками, приобретающими сторонами, поставщиками и разработчиками как части контрактных переговоров; - для обеспечения документирования характеристик, свойств и проекта системы для потенциальных заказчиков, приобретающих сторон, собственников, операторов и интеграторов; - при планировании передачи от устаревшей архитектуры к новой; - в качестве руководства к эксплуатационной и инфраструктурной поддержке и управлению конфигурацией; - для поддержки системного планирования и действий, связанных со сроками и бюджетом; - для установления критериев при сертификации реализаций на соответствие архитектуре; - в качестве механизма согласования с внешней и проектной политикой и/или внутренней политикой организации (например, юридические основания, перекрывающие архитектурные принципы); - в качестве основы для ревизий, анализа и оценки системы в ее жизненном цикле; - в качестве основы анализа и оценки альтернативных архитектур; - при распространении изученных уроков и повторном использовании архитектурного знания через точки зрения, образцы и стили; - для обучения и образования заинтересованных сторон и других сторон лучшим методам в процессе архитектуризации и при развитии системы. Примечание - В приложении C рассмотрено использование описаний архитектуры в контексте других стандартов. 4.5. Структуры архитектуры и языки описания архитектуры Структуры архитектуры и языки описания архитектуры являются двумя механизмами, широко используемыми в процессе архитектуризации. Структуры архитектуры и языки описания архитектуры определяются на основании понятий описания архитектуры, представленных в настоящем стандарте. Структура архитектуры устанавливает обычную практику для создания, интерпретации, анализа и применения описания архитектуры в пределах определенной области применения или сообщества заинтересованных сторон. Применение структур архитектуры включает (но не ограничивается этим): создание описаний архитектуры; разработку инструментариев моделирования архитектуры и методов процесса архитектуризации; установление процессов для содействия связи, обязательствам и межсистемному функционированию через множественные проекты и/или организации. Примечание - Структуры архитектуры часто охватывают условия для описания архитектуры и дополнительные практики процесса архитектуризации. Примеры - Примерами структуры архитектуры в терминах настоящего стандарта являются: структура архитектуры Захмана для информационных систем [44], структура архитектуры британского Министерства обороны [27], структура архитектуры открытых групп (TOGAF) [41], модель представления Крухтена "4 + 1" [23], четыре метода представлений Сименса [10], эталонная модель для открытой распределенной обработки (RM-ODP) [ИСО/МЭК 10746] и обобщенная эталонная архитектура предприятия (GERA) [ISO 15704]. На рисунке 5 отображено содержание структуры архитектуры. Примечание - Рисунок использует нотации для класса диаграмм, определенные в ИСО/МЭК 19501. Рисунок 5 - Концептуальная модель структуры архитектуры Примечание - Требования к структурам архитектуры определены в 6.1. Язык описания архитектуры является некоторой формой выражения для применения в описаниях архитектуры. Язык описания архитектуры обеспечивает один или несколько видов модели в качестве средства структуризации некоторых интересов для представителей заинтересованных сторон. Язык описания архитектуры может быть узко ориентированным, определяющим единственный вид модели, или широко ориентированным, предназначенным для обеспечения нескольких видов модели, специально организованных для представления точки зрения. Часто язык описания архитектуры поддерживается автоматизированными инструментариями для сопровождения создания, использования и анализа его моделей. Примеры - Примерами языка описания архитектуры в терминах настоящего стандарта являются Rapide [25], Wright [43], SysML [31], ArchiMate [40] и точка зрения на языки со стороны эталонной модели открытой распределенной обработки (RM-ODP) [ИСО/МЭК 10746]. На рисунке 6 отображено содержание языка описания архитектуры. Примечание - Рисунок использует нотации для класса диаграмм, определенные в ИСО/МЭК 19501. Рисунок 6 - Концептуальная модель языка описания архитектуры Примечание - Требования к языку описания архитектуры определены в 6.3. 5. Описания архитектуры 5.1. Введение Во введении определены характеристики описаний архитектуры, которые позволяют осуществлять применения, перечисленные в 4.4. Описания архитектуры включают следующее: - определение описания архитектуры и обзорную информацию (см. 5.2); - определение заинтересованных сторон системы и их интересов (см. 5.3); - определение каждой точки зрения на архитектуру, используемой в описании архитектуры (см. 5.4); - представления архитектуры и архитектурных моделей для каждой используемой точки зрения на архитектуру (см. 5.5 и 5.6); - применимые правила связей в описании архитектуры, связи и регистрацию известных несогласованностей в требуемом содержании описаний архитектуры (см. 5.7); - выполненные обоснования для решений архитектуры (см. 5.8). Глагол включать, используемый в разделе 5, указывает на то, что в описании архитектуры информация либо присутствует, либо представлена ссылка на эту информацию. Примечания 1 Настоящий стандарт не определяет формат для описаний архитектуры. 2 Чтобы многократно описать различные архитектуры или альтернативные выражения той же архитектуры, пользователю для каждого описания архитектуры следует применять условия настоящего раздела. Результаты могут быть объединены или отдельно представлены некоторым способом, не определяемым в настоящем стандарте. 5.2. Определение и обзор описания архитектуры Описание архитектуры должно идентифицировать (определять) рассматриваемую систему и включать дополнительную информацию, как определено проектом и/или организацией. Детальное содержание идентификации и дополнительных информационных объектов должно быть задано организацией и/или проектом. Примечание - Примерами идентификации и дополнительной информации в описании архитектуры являются дата выпуска и статус; авторы, рецензенты, утверждающие стороны, выпускающая организация; история изменений; резюме; область применения; контекст; глоссарий; информация контроля за версией; информация по управлению конфигурацией и ссылки. (См. [ИСО/МЭК 15289] или технический отчет [ИСО/МЭК 15504-6:2008, B.1]). Должны быть включены результаты любых оценок архитектуры или ее описания. 5.3. Определение заинтересованных сторон и интересов Описание архитектуры должно определять заинтересованные стороны системы, имеющие учитываемые интересы, важные для архитектуры рассматриваемой системы. В описании архитектуры должны быть учтены и, если применимо, определены следующие заинтересованные стороны: - пользователи системы; - операторы системы; - приобретающие стороны системы; - владельцы системы; - поставщики системы; - разработчики системы; - строители системы; - сопровождающие стороны системы. Описание архитектуры должно определять интересы, учитываемые как основные для архитектуры рассматриваемой системы. В описании архитектуры должны быть учтены и, если применимо, определены следующие интересы: - цели системы; - приемлемость архитектуры для достижения целей системы; - выполнимость конструирования и развертывания системы; - потенциальные риски и воздействия системы на ее заинтересованные стороны на всем ее жизненном цикле; - сопровождаемость и развиваемость системы. Описание архитектуры должно увязывать каждый интерес с определенными заинтересованными сторонами, имеющими такой интерес. Примечания 1 В общем случае взаимоувязывание интересов с заинтересованными сторонами представляет собой соотношение "многие ко многим". 2 Настоящий стандарт не предписывает степени детализации интересов, каким образом интересы находятся во взаимосвязи с другими интересами или как интересы соотносятся с другими утверждениями о системе, такими, например, как потребности заинтересованных сторон, цели системы или требования. Эти интересы представляют собой аспекты для определенных структур архитектуры, методов архитектуризации или других практик. 5.4. Точки зрения на архитектуру Описание архитектуры должно включать каждую используемую точку зрения на архитектуру. Каждая учтенная точка зрения на архитектуру должна быть определена в соответствии с условиями раздела 7. Каждый интерес, определенный в соответствии с 5.3, должен быть структурирован по крайней мере одной точкой зрения. Примечания 1 Настоящий стандарт не требует использования каких-либо особенных точек зрения. 2 Приложения B и C содержат дополнительную информацию, имеющую отношение к точкам зрения на архитектуру. 5.5. Архитектурные представления Описание архитектуры должно включать только одно архитектурное представление для каждой используемой точки зрения на архитектуру. Каждое архитектурное представление должно придерживаться соглашений его главной точки зрения на архитектуру. Каждое архитектурное представление должно включать: a) определение и дополнительную информацию, заданную организацией и/или проектом; b) определение главной точки зрения; c) архитектурные модели, которые обращаются ко всем интересам, структурируемых главной точкой зрения, и охватывают с той точки зрения систему в целом; d) регистрацию любых известных источников в пределах представления относительно его главной точки зрения. Примечания 1 См. 5.2 для примеров определения и дополнительную информацию в перечислении a). 2 В перечислении c) требование того, что каждое архитектурное представление охватывает целую систему относительно интересов, структурируемых ее главной точкой зрения, является существенным к полному распределению интересов в пределах описания архитектуры. В пределах представления может быть использована одна или более архитектурных моделей, чтобы выборочно представить части системы для выдвижения сути интересов на первый план, не нарушая самого требования (см. 5.6). 3 В перечислении d) "известные источники" включают нерешенные проблемы, исключения и отклонения от соглашений. Открытые источники могут привести к принятию решений. Исключения и отклонения могут быть зарегистрированы как результаты решения и его обоснование в 5.8. Описание архитектуры может включать информацию, не являющуюся частью любого архитектурного представления. Пример - Примером информации, не являющейся частью какого-либо представления, могут быть краткие обзоры системы, связи моделей и обоснование архитектуры. 5.6. Архитектурные модели Архитектурное представление должно быть составлено из одной или нескольких архитектурных моделей. Каждая архитектурная модель должна включать идентификацию версии, как это задается организацией и/или проектом. Каждая архитектурная модель должна определить свой основной вид модели и придерживаться соглашений этого вида (см. 5.4). Архитектурная модель может быть частью более чем одного архитектурного представления. Примечания 1 Распределение архитектурных моделей между представлениями архитектуры разрешает описанию архитектуры структурировать различные связанные интересы без избыточности или повторения той же самой информации во множественных представлениях и уменьшает возможности для несогласованности. Распределение архитектурных моделей также разрешает объектно-ориентированный стиль описания архитектуры: архитектурные модели, распределенные по архитектурному представлению, могут использоваться для выражения архитектурных перспектив (см. [36]); архитектурные модели, распределенные в пределах архитектурного представления, могут использоваться для выражения архитектурных структур (см. [34]). Архитектурные модели могут использоваться как "контейнеры" для применения архитектурных образцов (см. [4]) или стилей архитектуры, чтобы выражать основные схемы (например, послойные, трехъярусные, децентрализованные схемы, схема "модель - представление - контроллер") в пределах представлений архитектуры. 2 Настоящий стандарт не предписывает то, как создаются архитектурные модели. Они могут быть построены индивидуально, получены из других моделей или основаны на других моделях. 5.7. Архитектурные отношения 5.7.1 Согласованность в пределах описания архитектуры Описание архитектуры должно содержать регистрацию любых известных несогласованностей через архитектурные модели и представления. Примечание - При отдании предпочтения согласованности описания архитектуры, при решении по устранению несогласованности должны быть учтены неосуществимость или непрактичность по причинам времени, усилий или недостаточности информации. В таких ситуациях выявленные несогласованности должны быть зарегистрированы. В описание архитектуры следует включать анализ согласованности архитектурных моделей и представлений. Связи и правила связи, как определено в 5.7.2 и 5.7.3, могут быть использованы для того, чтобы выразить, осуществить регистрацию, провести в жизнь и проанализировать согласованность между моделями, представлениями и другими элементами в пределах описания архитектуры. 5.7.2 Связи КонсультантПлюс: примечание. Текст дан в соответствии с официальным текстом документа. Каждая связь в описании архитектуры должна быть определена и описать участие элементов описания архитектуры. Элементы описания архитектуры могут быть любыми конструкциями, установленными в 4.2 (заинтересованные стороны, интересы системы, точки зрения архитектуры, архитектурные представления, виды моделей, архитектурные модели, архитектурные решения и обоснования). Дополнительные виды элементов описания архитектуры могут быть введены после того, как определены точки зрения и виды моделей. Каждая связь в описании архитектуры должна определить любые руководящие правила связи (см. 5.7.3). Примечание - Нет необходимости в том, чтобы в связях элементы описания архитектуры были различными. Связь может быть определена между описаниями архитектуры, элемента и непосредственно между элементами. 5.7.3 Правила связи Описание архитектуры должно включать относящееся к нему правило связи. Примечание - Правило связи, применимое к описанию архитектуры, может появляться в описании архитектуры, в точке зрения (см. раздел 7) или в структуре архитектуры, или языке описания архитектуры (см. раздел 6). Для каждого определенного правила связи описание архитектуры следует зарегистрировать, если оно сохраняется, а при изменении провести регистрацию всех выявленных нарушений. Правило связи сохраняется, если соответствующая связь может быть продемонстрирована для выполнения этого правила. Правило связи нарушается, если соответствующая связь не может быть продемонстрирована для выполнения этого правила или когда не существует никакой соответствующей связи. Примечания 1 Связи в настоящем стандарте разработаны таким образом, чтобы быть совместимыми со связями из представления в эталонной модели открытой распределенной обработки (RM-ODP) [ИСО/МЭК 10746 и ИСО/МЭК 19793] в соответствии с A.6 (приложение A). 2 Связи и правила связи могут быть применены к множественным описаниям архитектуры, чтобы выразить отношения, касающиеся множественных архитектур или систем. Обобщая элемент описания архитектуры к другим информационным объектам, проект и/или организация могут применить связи, как определено здесь, между описаниями архитектуры и другими рабочими продуктами (например такими, как спецификации требований), чтобы выразить другие отношения архитектурного интереса (например такие, как прослеживаемость элементов описания архитектуры к требованиям). 5.8. Обоснование архитектуры 5.8.1 Регистрация обоснования Описание архитектуры должно содержать обоснование для каждой точки зрения на архитектуру, включенной для применения в соответствии с 5.4, в терминах заинтересованных сторон, с учетом их интересов, видов моделей, нотаций и методов. Описание архитектуры должно включать обоснование для каждого решения, которое было рассмотрено применительно к основному решению архитектуры (см. 5.8.2). В описание архитектуры следует включать свидетельство рассмотрения альтернатив и обоснования для сделанного выбора. 5.8.2 Регистрация решения Для описания архитектуры следует осуществлять регистрацию решений архитектуры, которые рассматривались применительно к основному решению архитектуры системы. Регистрация каждого архитектурного решения относительно системы не является практичной. Зарегистрированное решение и соответствующую стратегию следует применять организации и/или проекту для установления критерия выбора основных решений, которые будут зарегистрированы и поддержаны обоснованием в описании архитектуры. Рассматриваемыми критериями являются: - решения относительно архитектурно существенных требований; - решения, требующие больших инвестиционных усилий или времени для их формирования, реализации или внедрения; - решения, воздействующие на основные заинтересованные стороны или множество заинтересованных сторон; - решения, требующие сложного или неочевидного умозаключения; - решения, которые очень чувствительны к изменениям; - решения, которые могут быть дорогостоящими к изменениям; - решения, которые формируют основу для планирования и управления проектом (например, создание структуры разделения работ, прослеживание качества прохождения решений); - решения, которые приводят к капиталовложениям или косвенным затратам. При регистрации решений следует учитывать следующее: - решение является уникальным; - решение утверждается; - решение связывается с интересами системы, к которым оно имеет отношение; - для решения определяется владелец; - решение связывается с элементами описания архитектуры, воздействующими на решение; - делается обоснование, связанное с решением в соответствии с 5.8.1; - определяются ограничения и предположения, которые влияют на решение; - регистрируются альтернативы, которые были рассмотрены, и их потенциальные последствия; - регистрируются последствия решения (касающиеся других решений); - регистрируются временные отметки, когда решение было принято, когда было одобрено и когда было изменено; - предоставляются цитаты по источникам дополнительной информации. Примечания 1 Может быть полезным провести регистрацию отклоненных альтернатив и обоснования решений для этих отклонений. В будущем может оказаться, что приведенные причины более не актуальны и решение должно быть пересмотрено. 2 Может оказаться полезным провести регистрацию взаимосвязей между решениями архитектуры. Примеры типов отношений: ограничения, воздействия, разрешения, инициации, усилия, категорирование, уточнения, "рассогласования с" и "совместимость с" (см. [23], [44]). 6. Структуры архитектуры и языки описания архитектуры 6.1. Структуры архитектуры Структура архитектуры должна включать: a) информацию, определяющую структуру архитектуры; b) определение одного или более интересов (см. 5.3); c) определение одной или более заинтересованных сторон, имеющих эти интересы (см. 5.3); d) одну или более точек зрения на архитектуру, которые структурируют эти интересы (см. раздел 7); e) любые правила связи (см. 5.7). Глагол "включать", используемый в разделе 6, указывает на то, что в структуре архитектуры информация либо присутствует, либо представлена ссылка на эту информацию. В структуру архитектуры следует включать условия применимости. |