ГОСТ Архитектура. Национальный стандарт российской федерации системная и программная инженерия описание архитектуры
 Скачать 260.27 Kb.
|
|
Примеры - Примерами являются следующие условия применимости: - описание архитектуры, использующее структуру архитектуры AF1, должно определять заинтересованные стороны A, M и P, когда рассматриваемая система работает в пределах юрисдикции J; - описание архитектуры, использующее структуру архитектуры AF2, разрешает пропустить точку зрения V1, если не определено никаких интересов системы реального времени; - когда используется структура архитектуры AF3, для точки зрения V2 может быть пропущен вид модели MK, если S является некоторой определенной заинтересованной стороной. Структура архитектуры должна установить свою согласованность с условиями концептуальной модели согласно 4.2. Примечание - Вышеупомянутое требование может быть удовлетворено через метамодель, связи конструкций структуры с моделью согласно 4.2, текстовое изложение или некоторым иным способом. 6.2. Соблюдение описания архитектуры относительно структуры Описание архитектуры придерживается структуры архитектуры, когда: - каждая применимая заинтересованная сторона, определенная в структуре архитектуры, учтена и определена в описании архитектуры (см. 5.3); - каждый применимый интерес, определенный в структуре архитектуры, учтен и определен в описании архитектуры (см. 5.3); - каждая применимая точка зрения, заданная структурой архитектуры (см. 6.1), включена (см. 5.4) в описание архитектуры; - каждое применимое правило связи, заданное структурой архитектуры, включено в описание архитектуры (в 5.7.3); - описание архитектуры соответствует требованиям раздела 5. Термин "применимый" означает, что условия применимости (см. 6.1) соблюдены. Структура архитектуры может установить дополнительные правила для того, чтобы описание архитектуры придерживалось структуры. Примечание - Описание архитектуры может придерживаться одной или более структур архитектуры или не придерживаться никаких структур. Чтобы придерживаться более одной структуры, описание архитектуры влечет за собой согласование структур между определенными заинтересованными сторонами, интересами, точками зрения, видами и правилами связи в пределах описания архитектуры. 6.3. Языки описания архитектуры Язык описания архитектуры (ЯОА) должен задавать: a) определение одного или более интересов, которые будут выражены ЯОА (см. 5.3); b) определение одной или более заинтересованных сторон, имеющих эти интересы (см. 5.3); c) виды моделей, реализованные ЯОА, которые структурируют эти интересы [см. раздел 7, перечисление d)]; d) любые точки зрения на архитектуру согласно разделу 7. Примечание - ЯОА не должен выражать точки зрения архитектуры; это может определить один или более видов модели для использования в точках зрения архитектуры, определенных в другом месте; e) правила связи (см. 5.7), связь видов модели согласно перечислению c). 7. Точки зрения на архитектуру Точка зрения на архитектуру должна задавать: a) один или более интересов, структурируемых этой точкой зрения (см. 5.3); b) характерные заинтересованные стороны для интересов, структурируемых этой точкой зрения (см. 5.3); c) один или более видов модели, используемых в этой точке зрения; d) для каждого вида модели, определенного в перечислении c), языки, нотации, соглашения, методики моделирования, аналитические методы и/или другие операции, которые будут использоваться на моделях этого вида; e) ссылки на источники. Примечание - Перечисления d) могут быть описаны с использованием метамодели для вида модели, который определяет структуру и соглашения для ее моделей. Перечисление e) может включать автора, дату, электронную ссылку (URL) и/или цитаты из других документов. Точка зрения на архитектуру должна включать информацию относительно методик процесса архитектуризации, используемых для создания, интерпретации или анализа представления, управляемого этой точкой зрения, например такую, как: - правила связи, критерии и методы для проверки согласованности (см. 5.7.1) и полноты [см. 5.5, перечисление d)]; - методы оценки или анализа; - методы, эвристики, показатели, образцы, правила проектирования или руководящие принципы, лучшие практики и примеры для достижения целей в представлениях создания и синтеза. Точку зрения на архитектуру следует определять как часть описания архитектуры (см. раздел 5), часть структуры архитектуры (см. раздел 6) или индивидуальное использование требований этого раздела. Библиотечная точка зрения - это точка зрения на архитектуру, созданная за пределами контекста единственного описания архитектуры таким образом, что может быть использована во многих описаниях архитектуры. Примечания 1 Настоящий стандарт не требует использования каких-либо особенных точек зрения. 2 Приложение B дает представление об определении точек зрения. В приложении C приведены примеры точек зрения на архитектуру. Приложение A (справочное) ПРИМЕЧАНИЯ К ТЕРМИНАМ И ПОНЯТИЯМ A.1 Введение Настоящее приложение содержит проектные принципы, понятия и термины, на которых базируется настоящий стандарт. Настоящий стандарт определяет минимальные требования для описаний архитектуры для того, чтобы поддержать область применения, установленную в разделе 1. Данный подход позволяет использовать максимальную гибкость организаций при применении настоящего стандарта, демонстрируя соответствие требованиям разделов 5, 6, 7. Учитывая мультидисциплинарную природу процесса архитектуризации, назначение настоящего стандарта состоит в том, чтобы удовлетворить потребности множественных заинтересованных сторон и предоставить различные способы описания системы. Внедрение описаний архитектуры в представления, использующие точки зрения, обеспечивает механизм для разделения интересов среди заинтересованных сторон, представляя систему в целом, что является основным для понятия архитектуры. Установление качества архитектуры, определяемой в соответствии с описанием архитектуры (действительно ли это хорошая архитектура?), или непосредственно качества описания архитектуры (это описание архитектуры полное?) являются факторами для оценки описания архитектуры. Настоящий стандарт не предполагает наложения условий, которые необходимы для учета качества. Требуется, чтобы результаты таких оценок были зарегистрированы (см. 5.2). Качественные оценки архитектуры и описаний архитектуры являются предметом для будущих усилий в области стандартизации. Настоящий стандарт использует несколько терминов: "архитектура", "интерес", "модель", "представление" и "точка зрения", которые широко используются с несколькими различными значениями. Приложение A позволяет обсудить эти термины, мотивацию для их определений в настоящем стандарте и сопоставляет эти определения с другими их применениями. A.2 Системы и архитектура В настоящем стандарте термин "архитектура" предназначен для того, чтобы передать суть или основные положения системы. Существует несколько основных аспектов определения архитектуры в настоящем стандарте (см. 3.2). Приведенное определение было выбрано для охвата различных вариаций предыдущих использований термина "архитектура" путем признания их основного общего содержания. Основной принцип - это потребность понять и управлять теми элементами рассматриваемой системы, которые влияют на ее полезность, стоимость, временные характеристики и риски в пределах ее окружающей среды. В некоторых случаях основными элементами являются физические или структурные компоненты системы и их отношения. Иногда основными элементами являются функциональные или логические элементы. В других случаях, если это является основным или существенным для понимания рассматриваемой системы, элементами могут быть ее всеобщие принципы или образцы. Определение архитектуры в настоящем стандарте предназначено для того, чтобы охватить эти различные, но связанные варианты применения, поощряя более строгие очертания того, что составляет архитектуру системы. Термин "понятия или свойства" используется в определении (см. 3.2), чтобы позволить двум отличающимся основным положениям применять настоящий стандарт без предубеждений. Эти два основных положения: Архитектура как Понятие, где архитектура (системы) является пониманием системы в ее представлении; и Архитектура как Свойство, где архитектура (системы) является свойством системы. Эмпирические исследования обнаружили четыре модельных представления архитектуры в организациях [39]: - архитектура как проект; - архитектура как литература; - архитектура как язык; - архитектура как решение. Концептуальные основы настоящего стандарта не предполагают ни одного из этих модельных представлений; стандарт оптимально работает с любым из них. Существование этих множественных модельных представлений поддерживает центральный проектный принцип настоящего стандарта: архитектура неотъемлемо основана на множественных заинтересованных сторонах с множественными интересами в системе. A.3 Интересы Настоящий стандарт использует термин "интерес" для того, чтобы обозначать любую тему интереса, имеющего отношение к системе. Заинтересованные стороны системы имеют различные интересы. Некоторые интересы влияют на архитектуру, и поэтому настоящий стандарт требует определять их как части описания этой архитектуры. Мотивация для применения этого термина произошла от словосочетания "разделение интересов" из программной и системной инженерии (Edsger W. Dijkstra, 1974): "Позвольте мне попытаться объяснить Вам, что по моему представлению характерно для всего интеллектуального мышления. Это то, что каждый желает глубоко изолированно изучить некоторый аспект предмета в интересах его собственной согласованности, все время осознавая, что он занимается лишь одним из аспектов. Мы знаем, что программа должна быть правильной, и можем изучить ее только с конкретной точки зрения; мы также знаем, что ей следует быть эффективной, и в другой раз мы можем изучить ее эффективность. В следующий раз мы можем спросить себя: "Почему программа востребована"? Но, занимаясь этими различными аспектами одновременно, ничего не получается - наоборот! Это именно то, что я иногда называл "разделением интересов", которое, даже если совершенно невозможно, все же является единственной приемлемой методикой для эффективного упорядочения намерений, о которых я знаю. Это то, что я подразумеваю под "сосредоточением внимания на некоторых аспектах", что не означает игнорирования других аспектов, а только оправдывает факт того, что с точки зрения этого аспекта другой является неактуальным. Это - одно- и многократное отслеживание, рассматриваемое одновременно" [7]. Как определено в настоящем стандарте, каждая точка зрения на архитектуру структурирует один или более интересов (см. 5.4) так, чтобы представление, соответствующее точке зрения, обращалось к определенным известным интересам рассматриваемой системы. Отделение обработки интересов с помощью представлений позволяет заинтересованным сторонам сосредоточиваться на нескольких вопросах одновременно и предлагает средство для управления сложностью (см. 5.5). Литература в области системной и программной инженерии отражает большой набор таких интересов. Примеры приведены в 4.2.3. Хотя интересы включают риски и опасности (см. 5.3), этот термин не следует понимать как синоним "рисков" или "беспокойств", он должен пониматься как обращение к "любой" теме интересов. A.4 Архитектурное представление и точки зрения на архитектуру Термины "архитектурное представление" и "точка зрения на архитектуру" являются центральными в настоящем стандарте. Хотя иногда они используются как синонимы, в настоящем стандарте эти термины обращаются к различным видам объектов. Целью настоящего стандарта является охват существующих практик описания архитектур, обеспечивающих общую терминологию и понятия. Многие существующие практики выражают архитектуру через подборку моделей. Как правило, эти модели далее интегрируются в связные группы, называемые "представлениями". Единство группы моделей определяется в соответствии с интересами, к которым обращается эта группа моделей. То, что упускалось в недавней практике, - это отличие термина для механизма формализации этих группирований от ссылки на соглашения, в соответствии с которыми сделаны эти модели. В настоящем стандарте точка зрения ссылается на соглашения для того, чтобы выразить архитектуру относительно ряда интересов: Точка зрения - это способ взгляда на систему; представление - это результат применения точки зрения к конкретной рассматриваемой системе. Использование множественных представлений для выражения какой-либо архитектуры является основной посылкой настоящего стандарта. Потребность во множественных представлениях в описаниях архитектуры широко признана. В то время как использование множественных представлений широко распространено, авторы расходятся в том, какие представления необходимы, и в соответствующих методах для того, чтобы выразить каждое представление. Из-за широкого диапазона мнений настоящий стандарт не требует предопределенного множества точек зрения; это поощряет практику определения или отбора точек зрения, соответствующих рассматриваемой системе, и оценку точек зрения как важнейших элементов описаний архитектуры. Наиболее ранние работы над важнейшими точками зрения проявились в структурном анализе (в методологии структурного анализа и проектирования SADT) в 1977 г. [35]. В инженерии требований точки зрения рассмотрены как важнейшие сущности со связанными атрибутами и операциями [29]. Эти работы способствовали формированию точек зрения на архитектуру так, как это определено в разделе 7. Термин "точка зрения" был также выбран для совместимости с эталонной моделью открытой распределенной обработки (RM-ODP), которая использует этот термин следующим образом: - точка зрения (на систему) является абстракцией, которая приводит к какой-то спецификации целой системы, связанной с конкретным множеством интересов. [ИСО/МЭК 10746-1:1998, пункт 6.2.2]; - точка зрения (на систему) - форма абстракции, достигнутой с использованием отобранного множества архитектурных конструкций и структурирования правил в порядке сосредоточения на конкретных интересах в пределах системы [ИСО/МЭК 10746-2:2009, пункт 3.2.7]. Однако там, где настоящий стандарт использует термин "архитектурное представление" для ссылки на применение точки зрения к конкретной системе, эталонная модель открытой распределенной обработки (RM-ODP) использует термин "спецификации точки зрения". Отношения между точкой зрения и представлением предлагают следующее модельное представление: представление : точка зрения :: программа : язык программирования <1>. -------------------------------- <1> Это должно быть прочитано так: "представление к точке зрения как программа к языку программирования". Точка зрения определяет соглашения (такие как нотации, языки и типы моделей) для того, чтобы конструировать определенный вид представления. Каждая точка зрения может быть применена ко многим системам. Каждое представление - это одно такое применение. Точно так же программа - это отдельный случай применения языка программирования к определенной ситуации или проблеме проекта. Другое модельное представление для понимания различий между представлением и точкой зрения может быть таким: представление : точка зрения :: карта (связи) : надпись. Надпись определяет соглашения, используемые в подготовке карты (такие, как ее масштаб, цвета и другие символы), чтобы помочь пользователям в интерпретации этой карты по предназначению. Так же как каждой карте следует иметь надпись, каждому архитектурному представлению следует иметь точку зрения на архитектуру, определяющую условности для интерпретации содержания этого представления. Другой термин "тип представления", введенный в [5], устанавливает категоризацию точек зрения в терминах настоящего стандарта. В указанной работе описаны три категории точек зрения: модуль, компонент и соединитель, а также распределение типов представления. В пределах индивидуального описания архитектуры настоящий стандарт требует, чтобы каждым представлением управляла единственная точка зрения. Это означает, что каждое представление соответствует одному множеству соглашений (возможны составные виды моделей). Это требование не исключает пользователей настоящего стандарта, объединяющих или составляющих точки зрения на архитектуры в определенных целях (способом, не определенным настоящим стандартом), пока требование не будет удовлетворено в пределах индивидуального описания архитектуры. В настоящем стандарте каждое архитектурное представление должно выражать целую систему из конкретной перспективы системных интересов, структурируемых с помощью главной точки зрения. Это отражает целостную природу архитектуры. Например, в эксплуатационном представлении сетевой системы следует учитывать, что задержки при передаче по сети (в одной модели) и время непосредственной обработки (в другой модели) производят целостное сквозное представление работы всей системы. Описание архитектуры может сосредоточиться на рассматриваемой системе в определенной точке времени (например, когда система поставляется заказчику) или на рассмотрении эволюции системы сверх многих временных рамок. Любое представление может быть составлено из серии моделей, каждая из которых представляет рассматриваемую систему в данный момент времени. Композиция таких моделей в пределах представления может описывать то, как долго эта система будет развиваться во времени, отвечая требованию целостности представления. Существуют два единых подхода к конструированию представлений: комплексный и проекционный подходы. В комплексном подходе архитектор строит представления рассматриваемой системы и объединяет эти представления в пределах описания архитектуры, используя модельные связи. В проекционном подходе архитектор получает каждое представление через небольшое количество шаблонов, возможно механических процедур извлечения из некоего основного репозитария. Настоящий стандарт может быть использован с любым из этих подходов к представлениям. Из [38] известно, что: "Шаблонный проект использует решения известных проблем на основе повторного применения больших частей предыдущих решений... Наилучшие инженерные дисциплины охватывают, организуют и разделяют проектные знания, чтобы сделать шаблонный проект более простым. Справочники и руководства являются часто проводниками этой упорядоченной информации". Природа "повторного применения" точек зрения архитектуры (и структур архитектуры как скоординированных множеств точек зрения) выдвигает на первый план их полезность как механизмов охватывания стратегических архитектурных знаний в пределах организации или в пределах большего архитектурного сообщества. Точки зрения систематизируют определенные прикладные, методические или организационные подходы и таким образом поддерживают рост и развитие архитектурных практик. В приложениях B и C приведена дополнительная информация и ссылки, имеющие отношение к точкам зрения на архитектуру. A.5 Модели, рабочие продукты и архитектурные модели Модели и моделирование лежат в основе многих системных и программных архитектур. Понятие модели является центральным для понимания настоящего стандарта. Различные сообщества используют модель по-разному. Поэтому важно понять сам термин и как он используется в настоящем стандарте: M является моделью S, если M может использоваться для ответа на вопросы о S <1>. -------------------------------- <1> Это определение возникло в лаборатории электроники Массачусетского технологического института в 1960-е годы. Определение появилось в работе D.T. Ross и M. Minsky, которые работали в этой лаборатории в тот период времени: "Для наблюдателя B объект A* является моделью объекта A до такой степени, что B может использовать A*, чтобы ответить на вопросы, которые интересуют его об объекте A". M. Minsky, Суть, мнение и модели, 1968. "M является моделью относительно множества вопросов Q, если и только если M может использоваться, чтобы ответить на вопросы об объекте A в Q в пределах приемлемости T". D.T. Ross, Технические основы характеризации, 1977. У этого утверждения есть два важных следствия: 1) У каждой модели есть объект. 2) Модель может быть: i) понятием "ментальная модель"; ii) рабочим продуктом. В настоящем стандарте термин "модель" использован двумя способами. Во-первых, в его обычном языковом смысле, как это объяснено выше. Во-вторых, в специальном смысле для определения основной части процесса архитектуризации, воплощенной в термине "архитектурная модель" (см. 5.6). В первом смысле термина существует несколько видов моделей, связанных с процессом архитектуризации, которые описаны в настоящем стандарте. Различие между 2i) и 2ii) крайне важно для понимания в настоящем стандарте разницы между архитектурой и описанием архитектуры. В смысле 2i) архитектура - это концепция системы (т.е. ментальная модель), полезная для ответов на некоторые вопросы об этой системе. В смысле 2ii) существует три вида моделей, определенных в настоящем стандарте, реализуемых как рабочие продукты: - описание архитектуры - это рабочий продукт, который моделирует архитектуру рассматриваемой системы; его объект, отражающий вопросы определенных заинтересованных сторон обо всех определенных интересах системы; - архитектурное представление - это рабочий продукт; его объект - это специальное множество интересов заинтересованной стороны, структурируемых главной точкой зрения; - архитектурная модель - это рабочий продукт; его объект определяется с помощью его вида модели. Рабочий продукт понимается в настоящем стандарте как "артефакт, связанный с выполнением процесса" [ИСО/МЭК 15504-1:2004, пункт 3.55]. A.6 Связи Всякий раз, когда множественные модели объекта разрабатываются, они могут оказаться несовместимыми. В описаниях архитектуры одним из последствий использования множественных представлений является потребность выражать и поддерживать согласованность между этими представлениями. В ИИРЭ 1471:2000 эта потребность анализируется в терминах требований, а выявленные несогласованности регистрируются через представления описаний архитектуры (см. 5.7.1). В то время не было никакой известной практики для систематизации согласно стандарту для выражения или предписания такой согласованности. Настоящий стандарт вводит связи для выражения отношений между элементами описания архитектуры. У связей имеется ряд применений. Они могут быть применены для выражения согласованности, прослеживаемости, композиции, уточнения и преобразования моделей или зависимости любого типа, охватывающего более чем один вид модели. В [2] приведен обзор применений отношений моделей совместно с таксономией и классификацией механизмов отношения. Связи могут использоваться для удовлетворения требованиям (см. 5.7.1) по регистрации согласованности и несогласованностей в представлении. В конце настоящего подраздела представлены примеры связей и правил связи. Рассмотрены характеристики механизма связи относительно подобных механизмов, описанных в литературе. Пример 1, приведенный ниже, представляет простую модельную связь. |