Из ГОСТ Р 57100-2016 Системная и программная инженерия. Описание архитектуры

ГОСТ Р 57100–2016 Системная и программная инженерия. Описание архитектуры. Systems and software engineering. Architecture description. УДК 004.4:006.354 ОКС 35.080. Редакция от 12.12.2023.

6.1 Структуры архитектуры ГОСТ Р 57100-2016

Структура архитектуры должна включать:

a) информацию, определяющую структуру архитектуры;

b) определение одного или более интересов (см. 5.3);

c) определение одной или более заинтересованных сторон, имеющих эти интересы (см. 5.3);

d) одну или более точек зрения на архитектуру, которые структурируют эти интересы (см. раздел 7);

e) любые правила связи (см. 5.7).

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

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

Примеры — Примерами являются следующие условия применимости:

  • описание архитектуры, использующее структуру архитектуры AF1, должно определять заинтересованные стороны А, М и Р, когда рассматриваемая система работает в пределах юрисдикции J;
  • описание архитектуры, использующее структуру архитектуры AF2, разрешает пропустить точку зрения V1, если не определено никаких интересов системы реального времени;
  • когда используется структура архитектуры AF3, для точки зрения V2 может быть пропущен вид модели МК, если S является некоторой определенной заинтересованной стороной.

Структура архитектуры должна установить свою согласованность с условиями концептуальной модели согласно 4.2.

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

[из 6.1 Структуры архитектуры ГОСТ Р 57100–2016]

    6.2 Соблюдение описания архитектуры относительно структуры ГОСТ Р 57100-2016

    Описание архитектуры придерживается структуры архитектуры, когда:

    • каждая применимая заинтересованная сторона, определенная в структуре архитектуры, учтена и определена в описании архитектуры (см. 5.3);
    • каждый применимый интерес, определенный в структуре архитектуры, учтен и определен в описании архитектуры (см. 5.3);
    • каждая применимая точка зрения, заданная структурой архитектуры (см. 6.1), включена (см. 5.4) в описание архитектуры;
    • каждое применимое правило связи, заданное структурой архитектуры, включено в описание архитектуры (в 5.7.3);
    • описание архитектуры соответствует требованиям раздела 5.

    Термин «применимый» означает, что условия применимости (см. 6.1) соблюдены.

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

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

    [из 6.2 Соблюдение описания архитектуры относительно структуры ГОСТ Р 57100–2016]

      6.3 Языки описания архитектуры ГОСТ Р 57100-2016

      Язык описания архитектуры (ЯОА) должен задавать:

      a) определение одного или более интересов, которые будут выражены ЯОА (см. 5.3);

      b) определение одной или более заинтересованных сторон, имеющих эти интересы (см. 5.3);

      c) виды моделей, реализованные ЯОА, которые структурируют эти интересы [см. раздел 7, перечисление d)];

      d) любые точки зрения на архитектуру согласно разделу 7.

      Примечание — ЯОА не должен выражать точки зрения архитектуры; это может определить один или более видов модели для использования в точках зрения архитектуры, определенных в другом месте;

      e) правила связи (см. 5.7), связь ее видов модели согласно перечислению с).

      [из 6.3 Языки описания архитектуры ГОСТ Р 57100–2016]

        7 Точки зрения на архитектуру ГОСТ Р 57100-2016

        Точка зрения на архитектуру должна задавать:

        a) один или более интересов, структурируемых этой точкой зрения (см. 5.3);

        b) характерные заинтересованные стороны для интересов, структурируемых этой точкой зрения (см. 5.3);

        c) один или более видов модели, используемых в этой точке зрения;

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

        e) ссылки на источники.

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

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

        • правила связи, критерии и методы для проверки согласованности (см. 5.7.1) и полноты [см. 5.5, перечисление d)];
        • методы оценки или анализа;
        • методы, эвристики, показатели, образцы, правила проектирования или руководящие принципы, лучшие практики и примеры для достижения целей в представлениях создания и синтеза.

        Точку зрения на архитектуру следует определять как часть описания архитектуры (см. раздел 5), часть структуры архитектуры (см. раздел 6) или индивидуальное использование требований этого раздела. Библиотечная точка зрения – это точка зрения на архитектуру, созданная за пределами контекста единственного описания архитектуры таким образом, что может быть использована во многих описаниях архитектуры.

        Примечания

        1. Настоящий стандарт не требует использования каких–либо особенных точек зрения.
        2. Приложение В дает представление об определении точек зрения. В приложении С приведены примеры точек зрения на архитектуру.

        [из 7 Точки зрения на архитектуру ГОСТ Р 57100–2016]

          А.1 Введение ГОСТ Р 57100-2016

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

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

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

          Настоящий стандарт использует несколько терминов: «архитектура», «интерес», «модель», «представление» и «точка зрения», которые широко используются с несколькими различными значениями. Приложение А позволяет обсудить эти термины, мотивацию для их определений в настоящем стандарте и сопоставляет эти определения с другими их применениями [из А.1 Введение ГОСТ Р 57100–2016]

            А.2 Системы и архитектура ГОСТ Р 57100-2016

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

            Термин «понятия или свойства» используется в определении (см. 3.2), чтобы позволить двум отличающимся основным положениям применять настоящий стандарт без предубеждений. Эти два основных положения: Архитектура как Понятие, где архитектура (системы) является пониманием системы в ее представлении; и Архитектура как Свойство, где архитектура (системы) является свойством системы.

            Эмпирические исследования обнаружили четыре модельных представления архитектуры в организациях [39]:

            • архитектура как проект;
            • архитектура как литература;
            • архитектура как язык;
            • архитектура как решение.

            Концептуальные основы настоящего стандарта не предполагают ни одного из этих модельных представлений; стандарт оптимально работает с любым из них. Существование этих множественных модельных представлений поддерживает центральный проектный принцип настоящего стандарта: архитектура неотъемлемо основана на множественных заинтересованных сторонах с множественными интересами в системе [из А.2 Системы и архитектура ГОСТ Р 57100–2016]

              А.4 Архитектурное представление и точки зрения на архитектуру ГОСТ Р 57100-2016

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

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

              Точка зрения – это способ взгляда на систему; представление – это результат применения точки зрения к конкретной рассматриваемой системе.

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

              Наиболее ранние работы над важнейшими точками зрения проявились в структурном анализе (в методологии структурного анализа и проектирования SADT) в 1977 г. [35]. В инженерии требований точки зрения рассмотрены как важнейшие сущности со связанными атрибутами и операциями [29]. Эти работы способствовали формированию точек зрения на архитектуру так, как это определено в разделе 7. Термин «точка зрения» был также выбран для совместимости с эталонной моделью открытой распределенной обработки (RM–ODP), которая использует этот термин следующим образом:

              • точка зрения (на систему) является абстракцией, которая приводит к какой–то спецификации целой системы, связанной с конкретным множеством интересов. [ИСО/МЭК 10746–1:1998, пункт 6.2.2];
              • точка зрения (на систему) – форма абстракции, достигнутой с использованием отобранного множества архитектурных конструкций и структурирования правил в порядке сосредоточения на конкретных интересах в пределах системы [ИСО/МЭК 10746–2:2009, пункт 3.2.7].

              Однако там, где настоящий стандарт использует термин «архитектурное представление» для ссылки на применение точки зрения к конкретной системе, эталонная модель открытой распределенной обработки (RM–ODP) использует термин «спецификации точки зрения».

              Отношения между точкой зрения и представлением предлагают следующее модельное представление:

              представление : точка зрения :: программа : язык программирования2)

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

              Другое модельное представление для понимания различий между представлением и точкой зрения может быть таким:

              представление : точка зрения :: карта (связи): надпись.

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

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

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

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

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

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

              Из [38] известно, что:

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

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

              В приложениях В и С приведена дополнительная информация и ссылки, имеющие отношение к точкам зрения на архитектуру [из А.4 Архитектурное представление и точки зрения на архитектуру ГОСТ Р 57100–2016]

                А.5 Модели, рабочие продукты и архитектурные модели ГОСТ Р 57100-2016

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

                М является моделью S, если М может использоваться для ответа на вопросы о S3.

                У этого утверждения есть два важных следствия:

                1) У каждой модели есть объект.

                2) Модель может:

                i) понятием «ментальная модель»;

                N) рабочим продуктом.

                В настоящем стандарте термин «модель» использован двумя способами. Во–первых, в его обычном языковом смысле, как это объяснено выше. Во–вторых, в специальном смысле для определения основной части процесса архитектуризации, воплощенной в термине «архитектурная модель» (см. 5.6).

                В первом смысле термина существует несколько видов моделей, связанных с процессом архитектуризации, которые описаны в настоящем стандарте. Различие между 2i) и 2ii) крайне важно для понимания в настоящем стандарте разницы между архитектурой и описанием архитектуры. В смысле 2i) архитектура – это концепция системы (т. е. ментальная модель), полезная для ответов на некоторые вопросы об этой системе. В смысле 2ii) существует три вида моделей, определенных в настоящем стандарте, реализуемых как рабочие продукты:

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

                Рабочий продукт понимается в настоящем стандарте как «артефакт, связанный с выполнением процесса» [ИСО/МЭК 15504–1:2004, пункт 3.55] [из А.5 Модели, рабочие продукты и архитектурные модели ГОСТ Р 57100–2016]

                  А.6 Связи ГОСТ Р 57100-2016

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

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

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

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

                  Пример 1 – Рассматривает два представления системы S: представление аппаратных средств HW (S) и представление компонента программных средств SC (S). Учитывая, что SC (S) включает элементы программных средств, е1,... еб, и HW(S) включает платформы аппаратных средств.

                  - Пример связи

                  Рисунок А.1 – Пример связи

                  Пример 1 отвечает требованию 5.7.2: есть уникальное имя (ExecutesOn – «Выполняется на»), определяются участвующие элементы (обозначаемые е и pj) и дополнительное правило связи (R1).

                  Правило связи выражает ограничение для применения к связи. Пример 2 представляет простое правило связи.

                  Пример 2 – Рассматривает две точки зрения: аппаратные средства и компоненты программного средства. Правило связи, связывающее эти точки зрения:

                  R1 – Каждый элемент программных средств ei, как определено компонентами программного средства, должен выполняться на одной или более платформах pj, как определено для аппаратных средств.

                  Связь ExecutesOn («Выполняется на») из примера 1 нарушает правило R1 для примера 2, потому что некоторым элементам программных средств SC (S) (е5 и еб) не предписано выполнение на какой–либо платформе.

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

                  Пример 3 – Рассматривается следующее правило связи:

                  Задачи – Взаимодействия; у каждого случая вида модели «Задачи» должно быть уточнение к случаю вида модели «Взаимодействия».

                  Это правило связи моделей может быть выполнено с помощью связи, показанной на рисунке А.2, где есть Пользователи, Операторы и Аудиторы. Каждая модель Задачи (иллюстрированная в виде треугольника), уточняется в модели Взаимодействия (иллюстрированные как пятиугольники).

                  - Пример связи, удовлетворяющей правилу «Задачи - Взаимодействия»

                  Рисунок А.2 – Пример связи, удовлетворяющей правилу «Задачи – Взаимодействия»

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

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

                  Пример 4 – Рассмотрим следующее правило связи моделей:

                  Представление – Версии: показатель Версии каждого представления должен быть более, чем в 1,5 раза выше, нежели до публикации.

                  Термин «связь» выбран для гармонизации с эталонной моделью открытой распределенной обработки (RM–ODP). Механизм связи спроектирован для совместимости с представлением связи в эталонной модели открытой распределенной обработки (RM–ODP) [ИСО/МЭК 19793]; однако существует ряд отличий. Выявленные отличия состоят в следующем:

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

                  2) Связи представления эталонной модели открытой распределенной обработки (RM–ODP) – это бинарные отношения, тогда как связи модели в этом стандарте – это /7–арные отношения.

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

                  4) Связи и правила связи могут использоваться для того, чтобы выразить отношения через описания архитектуры.

                  Математически связь является л–арным отношением. Правило связи является содержательным определением л–арного отношения. Отношения включают картографию 1–1 (изоморфизмы) и функции как специальные случаи, и то, и другое являются слишком ограничительным и для многих применений связей. У отношений имеются полезные свойства, которые разрешают композицию и обоснования и позволяют эффективное изображение и манипуляцию (см. [28]). Пример 5 показывает некоторые из вышеупомянутых примеров, выраженных как отношения во множественных нотациях.

                  Пример 5 – ExecutesOn (R1) = {(е1, р1), (е1, р4), (е2, р2), (е2, рЗ), (еЗ, рЗ), (е4, р4)}.

                  Пользователи (Задачи – Взаимодействия) = {(Оператор Задачи, Оператор Взаимодействия), (Заказчик Задачи, Заказчик Взаимодействия), (Аудитор Задачи, Аудитор Взаимодействия)}.

                  Последняя версия (Представление – Версия) = {(Представление1, Версия v2.0), (Представление2, Версия v2.0), (ПредставлениеЗ, Версия v2.0), (Представление4, Версия v2.0), (Представление6, Версия V2.0)} [из А.6 Связи ГОСТ Р 57100–2016]

                    Страницы

                    Подписка на Из ГОСТ Р 57100-2016 Системная и программная инженерия. Описание архитектуры