ГОСТ Архитектура. Национальный стандарт российской федерации системная и программная инженерия описание архитектуры
 Скачать 260.27 Kb.
|
|
Пример 1 - Рассматривает два представления системы S: представление аппаратных средств HW (S) и представление компонента программных средств SC (S). Учитывая, что SC (S) включает элементы программных средств, e1, ..., e6, и HW (S) включает платформы аппаратных средств. Рисунок A.1 - Пример связи Пример 1 отвечает требованию 5.7.2: есть уникальное имя (ExecutesOn - "Выполняется на"), определяются участвующие элементы (обозначаемые ei и pj) и дополнительное правило связи (R1). Правило связи выражает ограничение для применения к связи. Пример 2 представляет простое правило связи. Пример 2 - Рассматривает две точки зрения: аппаратные средства и компоненты программного средства. Правило связи, связывающее эти точки зрения: R1 - Каждый элемент программных средств ei, как определено компонентами программного средства, должен выполняться на одной или более платформах pj, как определено для аппаратных средств. Связь ExecutesOn ("Выполняется на") из примера 1 нарушает правило R1 для примера 2, потому что некоторым элементам программных средств SC (S) (e5 и e6) не предписано выполнение на какой-либо платформе. Большинство связей будет выражено в терминах элементов участвующих моделей, но этого не требуется. Примеры 3 и 4 показывают другие формы связей. Пример 3 - Рассматривается следующее правило связи: Задачи - Взаимодействия: у каждого случая вида модели "Задачи" должно быть уточнение к случаю вида модели "Взаимодействия". Это правило связи моделей может быть выполнено с помощью связи, показанной на рисунке A.2, где есть Пользователи, Операторы и Аудиторы. Каждая модель Задачи (иллюстрированная в виде треугольника), уточняется в модели Взаимодействия (иллюстрированные как пятиугольники). Рисунок A.2 - Пример связи, удовлетворяющей правилу "Задачи - Взаимодействия" В примере 3 участники связи являются не элементами моделей, а непосредственно моделями. Связь может связать любые элементы описания архитектуры (см. 4.2.5 и 5.7.2); пользователи настоящего стандарта могут ввести другие типы элементов описания архитектуры, подходящих для достижения их целей. Многие из связей будут бинарными, что не является обязательным. Связь может установить отношение произвольного числа элементов описания архитектуры. Пример 4 иллюстрирует n-арное правило связи. Пример 4 - Рассмотрим следующее правило связи моделей: Представление - Версии: показатель Версии каждого представления должен быть более, чем в 1,5 раза выше, нежели до публикации. Термин "связь" был выбран для гармонизации с эталонной моделью открытой распределенной обработки (RM-ODP). Механизм связи спроектирован для совместимости с представлением связи в эталонной модели открытой распределенной обработки (RM-ODP) [ИСО/МЭК 19793]; однако существует ряд отличий. Выявленные отличия состоят в следующем: 1) В настоящем стандарте использован термин "связь", а не "связь представления". В эталонной модели открытой распределенной обработки (RM-ODP) каждое представление однородно - единственный язык точки зрения используется через спецификацию точки зрения. Настоящий стандарт разрешает однородные представления: каждое представление составлено из одной или более архитектурных моделей, где каждая модель использует различные языки моделирования (см. 5.6). Полезна возможность установления связи между моделями на различных языках моделирования, а не только между представлениями. Поэтому "связь представления" является специальным случаем того, что необходимо в настоящем стандарте, и в этом, более общем, случае данный термин оказывается в некотором смысле термином, вводящим в заблуждение. 2) Связи представления эталонной модели открытой распределенной обработки (RM-ODP) - это бинарные отношения, тогда как связи модели в этом стандарте - это n-арные отношения. 3) Связи представления эталонной модели открытой распределенной обработки (RM-ODP) определены на элементах спецификаций точки зрения, тогда как связи модели в настоящем стандарте требуют ссылок не к индивидуальным элементам моделей, а к произвольным элементам описания архитектуры. 4) Связи и правила связи могут использоваться для того, чтобы выразить отношения через описания архитектуры. Математически связь является n-арным отношением. Правило связи является содержательным определением n-арного отношения. Отношения включают картографию 1-1 (изоморфизмы) и функции как специальные случаи, и то, и другое являются слишком ограничительными для многих применений связей. У отношений имеются полезные свойства, которые разрешают композицию и обоснования и позволяют эффективное изображение и манипуляцию (см. [28]). Пример 5 показывает некоторые из вышеупомянутых примеров, выраженных как отношения во множественных нотациях. Пример 5 - ExecutesOn (R1) = {(e1, p1), (e1, p4), (e2, p2), (e2, p3), (e3, p3), (e4, p4)}. Пользователи (Задачи - Взаимодействия) = {(Оператор Задачи, Оператор Взаимодействия), (Заказчик Задачи, Заказчик Взаимодействия), (Аудитор Задачи, Аудитор Взаимодействия)}. Последняя версия (Представление - -Версия) = {(Представление1, Версия v2.0), (Представление2, Версия v2.0), (Представление3, Версия v2.0), (Представление4, Версия v2.0), (Представление5, Версия v2.0)}. A.7 Структуры архитектуры и языки описания архитектуры В системной и программной инженерии понятие структуры архитектуры относится к 1970-м годам [6], [44]. Мотивацией для определения этого термина (см. 3.6) и его спецификаций (см. 6.1) в настоящем стандарте является выражение средств определения существующих и будущих структур архитектуры единообразным способом с тем, чтобы продвинуть обмен информацией о системах, архитектурах и методиках описания архитектуры. При этом ожидается взаимодействие, которое позволит улучшить понимание и способность к интероперабельности между сообществами архитектуры, использующими различные концептуальные основы. Единообразное определение точек зрения архитектуры и скоординированные наборы таких точек зрения могут продвинуть повторное использование инструментариев и методик к сообществам, использующим эти структуры. Спецификация структуры архитектуры предназначена для установления отношения между структурой архитектуры и другими понятиями, определенными в настоящем стандарте (см. рисунки 2 и 4). Структуры архитектуры часто включают дополнительное содержание, предписания и отношения, например такие, как требования процесса, связи жизненного цикла и форматы документации, не определенные в настоящем стандарте, но потенциальные для будущих областей стандартизации. Термин "язык описания архитектуры" (ЯОА) использовался с 1990-х годов в программных средствах, системах и сообществах архитектуры предприятия. В пределах концептуальной модели согласно настоящему стандарту язык описания архитектуры - это любой язык для использования в описании архитектуры. Поэтому ЯОА может использоваться одной или более точками зрения для структуризации определенных интересов системы в пределах описания архитектуры. Ранние ЯОА рассматривались в [25] и [43]. ЯОА сосредоточивались на структурных интересах: крупномасштабная организация системы, выраженная в терминах компонентов, соединителей и конфигураций и изменяющая поддержку структуризации поведенческих интересов. Позже широкий спектр ЯОА был разработан с поддержкой более широкого диапазона интересов. Они включают языки анализа и описания архитектуры (ЯАОА) [37], язык моделирования систем [31] и язык ArchiMate [40]. Примеры 1 и 2, представленные ниже, описывают два современных ЯОА со ссылкой на их соотношение с концептуальной моделью, определенной в настоящем стандарте. Примеры 1 ArchiMate упорядочивает описания архитектур в несколько слоев интересов (бизнес, приложения и технология (или инфраструктура)), несколько аспектов интересов в пределах каждого из тех слоев (структурные, поведенческие и информационные аспекты) и определяет восемнадцать основных точек зрения для них. Каждая точка зрения определяется через ее собственную метамодель, связывая эту точку зрения с другими, и задаются заинтересованные стороны, интересы, цель, слои и аспекты. 2 Язык моделирования систем (SysML) создал унифицированный язык моделирования (UML). Язык моделирования систем определяет несколько типов диаграмм: деятельность, последовательность, машину состояний, случай использования, определение блока, внутренний блок, пакет, параметрические диаграммы и диаграммы требования. В терминах, приведенных в настоящем стандарте, каждый тип диаграммы - это вид модели. Язык моделирования систем обеспечивает важнейшие конструкции для заинтересованных сторон, интересов, представлений и точек зрения таким образом, чтобы пользователи могли создать новые точки зрения в соответствии с настоящим стандартом. Подобно структуре архитектуры ЯОА структурирует определенное множество интересов для аудитории заинтересованных сторон, определяя один или более видов модели вместе с любыми связанными методами анализа или инструментариями. Подобно структуре архитектуры или точке зрения на архитектуру ЯОА является ресурсом многократного использования - он не ограничивает использования применительно к индивидуальной системе или описанию архитектуры. Приложение B (справочное) РУКОВОДСТВО К ТОЧКАМ ЗРЕНИЯ НА АРХИТЕКТУРУ B.1 Введение В настоящем приложении приведен шаблон документирования точек зрения на архитектуру и аннотируемое руководство к образцу настоящих доступных точек зрения. B.2 Шаблон для документирования точек зрения на архитектуру B.2.1 Обзор шаблона Представлен шаблон для точек зрения на архитектуру. Точка зрения на архитектуру, которая документируется в эту форму, удовлетворяет требованиям, указанным в разделе 7. Шаблон состоит из ряда разделов или информационных объектов (см. B.2.2 - B.2.11). Каждый раздел определен наименованием (см. B.2.X - Наименование раздела), сопровождаемым кратким описанием его намеченного содержания, руководства для разработки содержания и в некоторых случаях подраздела. Не каждый раздел необходим для документирования каждой точки зрения. Этот шаблон основан на образце, предложенном в [9]. B.2.2 Наименование точки зрения Наименование для точки зрения. Если существуют синонимы или другие общие наименования, которые известны для этой точки зрения, следует записать их. B.2.3 Обзор точки зрения Резюме или краткий обзор точки зрения и ее главных особенностей. B.2.4 Интересы и "противоположные интересы" Перечисление связанных с архитектурой интересов, которые будут структурированы этой точкой зрения, приведено в разделе 7, перечисление a). Для архитектора это является критичной информацией, т.к. она помогает решать, будет ли данная точка зрения полезна для рассматриваемой системы. Может оказаться полезным зарегистрировать виды источников, для которых точка зрения не является приемлемой. Формулирование противоположных интересов может оказаться хорошим противодействием для определенных чрезмерно используемых моделей и нотаций. B.2.5 Типичные заинтересованные стороны Перечисление заинтересованных сторон системы, ожидаемых в качестве пользователей или публики для подготовленных представлений, использующих эту точку зрения, приведено в разделе 7, перечисление b). Примечание - После того, как точка зрения выбрана для использования и применена в описании архитектуры, это описание архитектуры требуется задокументировать ассоциацией фактических заинтересованных сторон системы с интересами, структурированными с помощью каждой точки зрения (в 5.3). B.2.6 Виды моделей B.2.6.1 Введение Определяется каждый вид модели, заданный точкой зрения в перечислении c) раздела 7. Для каждого используемого вида модели описываются его соглашения, язык или методики моделирования. Они являются основными ресурсами моделирования, которые точка зрения делает доступными, и определяют словари для конструирования представления. Они включают операции на моделях конкретного вида моделей согласно B.2.6.5. Настоящий стандарт не определяет какой-либо один стиль для документирования видов моделей. Вид модели может быть зарегистрирован многими способами, включая: 1) задание метамодели, которая определяет его основные конструкции; 2) обеспечение шаблона модели для заполнения пользователями; 3) через языковое определение или с помощью ссылки к существующему языку моделирования; 4) некоторую комбинацию этих методов. Руководство для методов 1) - 3) представлено ниже. B.2.6.2 Вид модели: метамодель Метамодель представляет собой элементы описания архитектуры, которые включают в себя словарь вида моделей. Существуют различные способы представления метамодели. Метамодель следует представлять как: - сущности (объекты): Каковы главные типы элементов, которые присутствуют в моделях этого вида? - атрибуты: Какие свойства реализуют сущностные (объектовые) процессы в моделях этого вида? - отношения: Какие отношения определены среди сущностей (объектов) в моделях этого вида? - ограничения: Какие виды ограничений существуют для сущностей (объектов), атрибутов и/или отношений в моделях этого вида? Сущности (объекты), атрибуты, отношения и ограничения - это все элементы описания архитектуры, определенные в 3.4 (также см. 4.2.5 и 5.7). Примечание - Когда точка зрения определяет множественные виды моделей, полезно найти единственную точку зрения метамодели, унифицирующую определения видов моделей. Кроме того, часто бывает полезным использовать единственную метамодель, чтобы выразить множественные, связанные точки зрения (например такой, когда определяется структура архитектуры). B.2.6.3 Вид модели: шаблон Обеспечивается шаблон или форма, определяющие формат и/или содержание моделей этого вида моделей. B.2.6.4 Вид модели: языки Определяется существующая нотация или язык модели так, чтобы они могли использоваться для моделей этого вида. Описывается, если это необходимо, их синтаксис, семантика, поддерживающие инструментарии. B.2.6.5 Вид модели: операции Определяются операции, доступные на моделях этого вида. Содержание операций на представлениях изложено в B.2.8. B.2.7 Правила связи Документируются любые правила связи, определенные конкретной точкой зрения или ее видами моделей. Обычно эти правила будут "пересекающейся моделью" или "пересекающимся представлением", так как ограничения в пределах вида моделей будут определены как часть соглашений этого вида моделей. B.2.8 Операции на представлениях Операции определяют собой методы, которые применяются в представлениях или их моделях. Операции могут быть разделены на категории: - методы создания - это средства, с помощью которых представления подготовлены с использованием этой точки зрения. Они могут быть представлены в форме руководства процесса (как начать, что делать в дальнейшем); руководства для рабочих продуктов (шаблоны для представлений этого типа); эвристики, стилей, образцов или других выражений; - интерпретирующие методы - это средства, с помощью которых представления становятся понятными заинтересованным сторонам системы и читателям; - методы анализа - используются для того, чтобы проверять, рассуждать, преобразовывать, прогнозировать, применять и оценивать архитектурные результаты из конкретного представления; - методы проектирования и реализации - используются для того, чтобы реализовывать или конструировать системы, применяя информацию из конкретного представления. B.2.9 Примеры Этот раздел содержит примеры. B.2.10 Примечания Любая дополнительная информация, в которой пользователи этой точки зрения могут нуждаться или находят ее полезной. B.2.11 Источники Определяются источники конкретной точки зрения, если таковые имеются, включая автора, историю, литературные ссылки, предшествующие наработки [см. перечисление e) раздела 7]. B.3 Аннотируемое руководство к точкам зрения на архитектуру Ниже представлены некоторые ссылки для зарекомендовавших себя архитектурных точек зрения. Не все они задокументированы в соответствии с требованиями настоящего стандарта, но могут быть использованы в описании архитектуры или включены соответствующим способом в структуру архитектуры: - Callo-Arias, America, Avgeriou "Определение точек зрения для большой и сложной программной системы" ("Defining execution viewpoints for a large and complex software-intensive system") [4]. Документирует "каталог выполнения точки зрения" для того, чтобы понять выполнение сложных программных систем. Представлены четыре точки зрения: профиль выполнения, развертывание выполнения, использование ресурсов и параллелизм выполнения. Также включены правила связи между точками зрения; - Clements и др., Документирование архитектур программных средств: представления и более (Documenting Software Architectures: views and beyond) [5]. Обеспечивает расширенные ресурсы для определения трех категорий точек зрения. Этими категориями, названными типами представлений в соответствии с A.4, являются модуль, компонент, соединитель и типы распределения представления. В пределах каждого типа представлений определен ряд стилей; - Eeles и Cripps, Процесс архитектуризации программных средств (The Process of Software Architecting) [8]. Определяет процесс архитектуризации программных средств, используя в качестве основы модель ИИЭР 1471:2000. Обеспечивает шаблон точки зрения и каталог точек зрения, включая: требования, функционал, развертывание, валидацию, применение, инфраструктуру, управление системами, пригодность, функционирование, безопасность, а также для каждого - "рабочие продукты" (то есть виды моделей); |