Модель представления
Для других целей см. раздел просмотр модели (disambiguation) .
Модель представления или фреймворк точек зрения в системной инженерии, программной инженерии и инженерии предприятия-это фреймворк , который определяет согласованный набор представлений , используемых при построении архитектуры системы, архитектуры программного обеспечения или архитектуры предприятия . Представление-это представление всей системы с точки зрения соответствующего набора проблем.[1][2]
С начала 1990-х годов предпринимается ряд усилий по разработке подходов к описанию и анализу системной архитектуры. Эти последние усилия определяют набор взглядов (или точек зрения). Их иногда называют архитектурными фреймворками или корпоративными архитектурными фреймворками, но обычно называют "моделями представления".
Обычно представление-это рабочий продукт, который представляет определенные данные архитектуры для данной системы. Однако тот же термин иногда используется для обозначения определения вида , включая определенную точку зрения и соответствующее руководство, которое определяет каждое конкретное представление. Модель представления терминов связана с определениями представлений.
Обзор[править]
Цель взглядов и точек зрения состоит в том , чтобы дать людям возможность понять очень сложные системы, организовать элементы проблемы и решения вокруг областей знаний и разделить проблемы . При проектировании физически интенсивных систем точки зрения часто соответствуют возможностям и обязанностям инженерной организации.[3]
Большинство спецификаций сложных систем настолько обширны, что ни один человек не может полностью понять все аспекты спецификаций. Кроме того, у всех нас разные интересы в данной системе и разные причины для изучения спецификаций системы . Бизнес руководитель будет задавать различные вопросы о составе системы, чем это сделал бы разработчик системы. Таким образом, концепция структуры точек зрения заключается в том, чтобы включить отдельные точки зрения в спецификацию данной сложной системы для облегчения связи с заинтересованными сторонами. Каждая точка зрения удовлетворяет интерес аудитории к определенному набору аспектов системы. Каждая точка зрения может использовать определенный язык точки зрения это оптимизирует словарный запас и презентацию для аудитории этой точки зрения. Моделирование точек зрения стало эффективным подходом к решению проблем, связанных со сложностью больших распределенных систем.
Методы описания архитектуры, описанные в IEEE Std 1471-2000, используют несколько представлений для решения нескольких проблемных областей, каждая из которых фокусируется на конкретном аспекте системы. Примеры архитектурных фреймворков, использующих несколько представлений, включают модель представления Кручтена "4+1", фреймворк Захмана , TOGAF , DoDAF , RM-ODP и модель представления Хамдаки" 5+1".
История[править]
В 1970-х годах в программной инженерии стали появляться методы моделирования с несколькими представлениями. Дуглас т. Росс и К. Э. Шоман в 1977 году вводят контекст, точку зрения и точку зрения для организации процесса моделирования в определении системных требований.[5] Согласно Россу и Шоману, точка зрения "проясняет, какие аспекты считаются релевантными для достижения ... общая цель [модели] " и определяет, как мы смотрим на [моделируемый субъект]?
В качестве примеров точек зрения предлагаются: технические, эксплуатационные и экономические точки зрения. В 1992 году Энтони Финкельштейн и другие опубликовали очень важный документ о взглядах."Точка зрения может рассматриваться как комбинация идеи" субъекта”, “источника знаний”, “роли” или “агента” в процессе развития и идеи “точки зрения” или "перспективы", которую поддерживает субъект."Важной идеей в этой статье было различать" стиль представления, схему и нотацию, с помощью которой точка зрения выражает то, что она может видеть " и " спецификацию, высказывания, выраженные в стиле точки зрения, описывающей определенные области". Последующие работы , такие как IEEE 1471, сохранили это различие, используя два отдельных термина: viewpoint и view, соответственно.
С начала 1990-х годов предпринимается ряд усилий по кодификации подходов к описанию и анализу системной архитектуры. Они часто называются архитектурными фреймворками или наборами точек зрения . Многие из них были профинансированы Министерством обороны Соединенных Штатов , но некоторые возникли в результате международных или национальных усилий в ISO или IEEE . Среди них, рекомендуемая практика IEEE для архитектурного описания программно-интенсивных систем (IEEE Std 1471-2000 ) установила полезные определения точки зрения, точки зрения, заинтересованных сторон и интересов и руководящие принципы для документирования архитектура системы за счет использования нескольких представлений путем применения точек зрения для решения проблем заинтересованных сторон .[7] преимущество множественных мнений заключается в том, что скрытые требования и разногласия заинтересованных сторон могут быть обнаружены более легко. Однако исследования показывают, что на практике дополнительная сложность согласования нескольких мнений может подорвать это преимущество.[8]
IEEE 1471 (в настоящее время ISO/IEC/IEEE 42010:2011 , Systems and software engineering — описание архитектуры ) предписывает содержание описаний архитектуры и описывает их создание и использование в ряде сценариев, включая прецедентное и беспрецедентное проектирование, эволюционное проектирование и захват проектирования существующих систем. Во всех этих сценариях общий процесс одинаков: определение заинтересованных сторон, выявлять проблемы, определять набор используемых точек зрения, а затем применять эти спецификации точек зрения для разработки набора представлений, относящихся к системе интересов. Вместо того чтобы определять определенный набор точек зрения, стандарт предусматривает единообразные механизмы и требования к архитекторам и организациям, определяющим свои собственные точки зрения. В 1996 году была опубликована справочная модель ISO для открытой распределенной обработки ( RM-ODP), которая представляет собой полезную основу для описания архитектуры и проектирования крупномасштабных распределенных систем.
Просмотр тем моделей[править]
Посмотреть[править]
Представление системы - это представление системы с точки зрения точки зрения. Эта точка зрения на систему включает в себя перспективу, сосредоточенную на конкретных проблемах, касающихся системы, которая подавляет детали, чтобы обеспечить упрощенную модель, содержащую только те элементы, которые связаны с проблемами точки зрения. Например, точка зрения безопасности фокусируется на проблемах безопасности, а модель точки зрения безопасности содержит те элементы, которые связаны с безопасностью из более общей модели системы.[9]
Представление позволяет пользователю исследовать часть определенной области интереса. Например, в информационном представлении могут быть представлены все функции, организации,технологии и т.д. которые используют определенную часть информации, в то время как организационное представление может представлять все функции, технологии и информацию, представляющие интерес для конкретной организации. В рамках Zachman мнения составляют группу продуктов работы, разработка которых требует особой аналитической и технической экспертизы, поскольку они фокусируются на “что”, “как”, “кто”, “где”, “когда” или “почему” предприятия. Например, функциональное представление продуктов работы отвечает на вопрос “как выполняется миссия?"Они наиболее легко разрабатываются специалистами по функциональной декомпозиции с использованием моделирования процессов и деятельности. Они показывают предприятие с точки зрения функций. Они также могут отображать организационные и информационные компоненты, но только в том виде, в каком они связаны с функциями.
Точки обзора[править]
В системной инженерии точка зрения является разделением или ограничением проблем в системе. Принятие точки зрения является полезным, так что вопросы в этих аспектах могут быть рассмотрены отдельно. Хороший выбор точек зрения также разбивает дизайн системы на конкретные области знаний.[3]
Точки зрения обеспечивают соглашения, правила и языки для построения, представления и анализа представлений. В ISO/IEC 42010:2007 ( IEEE-Std-1471-2000 ) точка зрения является спецификацией для отдельного представления. Представление-это представление всей системы с точки зрения точки зрения. Вид может состоять из одной или нескольких архитектурных моделей .[11] каждая такая архитектурная модель разрабатывается с использованием методов, установленных ассоциированной с ней архитектурной системой, а также для системы в целом.
Перспективы моделирования[править]
Перспективы моделирования-это набор различных способов представления заранее выбранных аспектов системы. Каждая перспектива имеет свой фокус, концептуализацию, посвящение и визуализацию того, что представляет модель.
В информационных системах традиционный способ разделения перспектив моделирования заключается в различении структурной, функциональной и поведенческой/процессной перспектив. Это вместе с правилами, объектами, коммуникациями и акторно-ролевыми перспективами является одним из способов классификации подходов моделирования.
Модель точки зрения[править]
В любой данной точке зрения можно сделать модель системы, которая содержит только объекты, видимые с этой точки зрения, но также захватывает все объекты, отношения и ограничения, которые присутствуют в системе и имеют отношение к этой точке зрения. Такая модель называется моделью точки зрения или взглядом на систему с этой точки зрения.[3]
Данный вид-это спецификация системы на определенном уровне абстракции с заданной точки зрения. Различные уровни абстракции содержат различные уровни детализации. Высокоуровневые взгляды позволяют инженеру фасонировать и постигать всю конструкцию и определять и разрешать проблемы в большом. Виды нижнего уровня позволяют инженеру сосредоточиться на части проекта и разработать подробные спецификации.[3] Иллюстрация представлений, продуктов и данных в архитектуре Framework.
В самой системе, однако, все спецификации, появляющиеся в различных моделях точек зрения, должны быть рассмотрены в реализованных компонентах системы. И спецификации для любого заданного компонента могут быть нарисованы от много различных точек зрения. С другой стороны, спецификации, индуцированные распределением функций по конкретным компонентам и взаимодействиям компонентов, как правило, отражают иное распределение проблем, чем это отражено в исходных точках зрения. Таким образом, могут быть также полезны дополнительные точки зрения, учитывающие интересы отдельных компонентов и восходящий синтез системы.
Описание архитектуры[править]
Описание архитектуры - это представление архитектуры системы в любое время в терминах ее составных частей, как эти части функционируют, правила и ограничения, в соответствии с которыми эти части функционируют, и как эти части связаны друг с другом и с окружающей средой. В описании архитектуры данные архитектуры являются общими для нескольких представлений и продуктов.
На уровне данных находятся элементы архитектуры данных и их определяющие атрибуты и отношения. На уровне представления находятся продукты и представления, которые поддерживают визуальные средства для передачи и понимания назначения архитектуры, того, что она описывает, и различных выполняемых архитектурных анализов. Продукты предоставляют способ визуализации данных архитектуры в виде графических, табличных или текстовых представлений. Представления предоставляют возможность визуализировать данные архитектуры, связанные с различными продуктами, логически организуя данные для определенной или целостной перспективы архитектуры.
Типы моделей системного представления[править]
Подход с тремя схемами[править]
Трехсхемный подход к моделированию данных, введенный в 1977 году, можно считать одной из первых моделей представления. Это подход к построению информационных систем и систем управления информацией, который продвигает концептуальную модель как ключ к достижению интеграции данных . подход с тремя схемами определяет три схемы и представления:
- Внешняя схема для представлений пользователей
- Концептуальная схема интегрирует внешние схемы
- Внутренняя схема, определяющая физические структуры хранения
В центре концептуальная схема определяет онтологию понятий, как пользователи думают о них и говорят о них. Физическая схема описывает внутренние форматы данных, хранящихся в базе данных, а внешняя схема определяет представление данных, представленных прикладным программам .[15] платформа попыталась разрешить использование нескольких моделей данных для внешних схем.[16]
За эти годы мастерство и интерес к созданию информационных систем значительно возросли. Однако, по большей части, традиционный подход к построению систем был сосредоточен только на определении данных из двух различных представлений "представление пользователя"и" представление компьютера". С точки зрения пользователя, которая будет называться “внешней схемой”, определение данных находится в контексте отчетов и экранов, предназначенных для оказания помощи людям в выполнении их конкретной работы. Требуемая структура данных из представления использования изменяется в зависимости от бизнес-среды и индивидуальных предпочтений пользователя. В представлении компьютер, которое будет называться “внутренняя схема”, данные определяются в терминах файловых структур для хранения и извлечения. Требуемая структура данных для хранения на компьютере зависит от используемой компьютерной технологии и необходимости эффективной обработки данных.
4+1 просмотр модели архитектуры[править]
4+1-это модель представления, разработанная Филиппом Кручтеном в 1995 году для описания архитектуры программно-интенсивных систем, основанных на использовании нескольких параллельных представлений.[18] представления используются для описания системы с точки зрения различных заинтересованных сторон, таких как конечные пользователи, разработчики и руководители проектов. Четыре представления модели: логическое, развитие, процесс и физическое представление:
Четыре вида модели связаны с :
- Логическое представление: связано с функциональностью, которую система предоставляет конечным пользователям.
- Представление разработки: иллюстрирует систему с точки зрения программистов и занимается управлением программным обеспечением.
- Представление процесса: имеет дело с динамическим аспектом системы, объясняет системные процессы и то, как они взаимодействуют, и фокусируется на поведении во время выполнения системы.
- Физический вид: отображает систему с точки зрения системного инженера. Это касается топологии программных компонентов на физическом уровне, а также связи между этими компонентами.
Кроме того, выбранные варианты использования или сценарии используются для иллюстрации архитектуры. Таким образом, модель содержит 4+1 представления.
Типы представлений архитектуры предприятия[править]
Enterprise architecture framework определяет, как организовать структуру и представления, связанные с корпоративной архитектурой . Поскольку дисциплина "архитектура и проектирование предприятий" настолько широка и поскольку предприятия могут быть большими и сложными, модели, связанные с этой дисциплиной, также имеют тенденцию быть большими и сложными. Для управления этим масштабом и сложностью Архитектурная среда предоставляет инструменты и методы, которые могут сфокусировать задачу и позволить создавать ценные артефакты, когда они наиболее необходимы.
Архитектурные фреймворки широко используются в информационных технологиях и управлении информационными системами. Организация может пожелать поручить, чтобы определенные модели были подготовлены до утверждения проекта системы. Кроме того, они могут пожелать указать определенные мнения, которые будут использоваться в документации закупаемых систем - Министерство обороны США предусматривает, что конкретные мнения Додаф будут предоставляться поставщиками оборудования для капитального проекта выше определенной стоимости.
Zachman Framework[править]
Платформа Zachman, первоначально задуманная Джоном Закманом в IBM в 1987 году, представляет собой платформу для архитектуры предприятия, которая обеспечивает формальный и структурированный способ просмотра и определения предприятия.
Платформа используется для организации архитектурных "артефактов" таким образом, чтобы учитывать, на кого нацелен артефакт (например, владелец бизнеса и строитель) и какая конкретная проблема (например, данные и функциональность) решается. Эти артефакты могут включать проектные документы, спецификации и модели.[20]
Структура Zachman часто упоминается как стандартный подход для выражения основных элементов архитектуры предприятия . Система Захмана была признана федеральным правительством США"... получил всемирное признание в качестве комплексной основы для управления изменениями на предприятиях и поддерживающих их систем."
Представления RM-ODP[править]
Эталонная модель открытой распределенной обработки (RM-ODP) Международной Организации по стандартизации ( ISO ) [22] определяет набор точек зрения для секционирования проектирования распределенной программно-аппаратной системы. Поскольку большинство проблем интеграции возникают при проектировании таких систем или в аналогичных ситуациях, эти точки зрения могут оказаться полезными при разделении проблем интеграции. Точки зрения RMODP: [3]
- корпоративная точка зрения, которая связана с целью и поведением системы, поскольку она относится к бизнес-цели и бизнес-процессам организации
- информационная точка зрения, которая касается характера информации, обрабатываемой системой, и ограничений на использование и интерпретацию этой информации
- вычислительная точка зрения, которая связана с функциональной декомпозицией системы на набор компонентов, которые проявляют определенное поведение и взаимодействуют на интерфейсах
- инженерная точка зрения, которая касается механизмов и функций, необходимых для поддержки взаимодействия вычислительных компонентов
- технологическая точка зрения, которая связана с явным выбором технологий для реализации системы, и в частности для связи между компонентами
RMODP далее определяет требование к дизайну, чтобы содержать спецификации согласованности между точками зрения, в том числе:
- использование корпоративных объектов и процессов в определении информационных единиц
- использование корпоративных объектов и моделей поведения при определении моделей поведения вычислительных компонентов и использование информационных блоков при определении вычислительных интерфейсов
- связь инженерных решений с вычислительными интерфейсами и требованиями к поведению
- удовлетворение информационных, вычислительных и инженерных потребностей в выбранных технологиях/
Представления DoDAF[править]
Структура архитектуры Министерства обороны (DoDAF) определяет стандартный способ организации корпоративной архитектуры (EA) или архитектуры систем в взаимодополняющие и согласованные представления. Он особенно подходит для больших систем со сложными проблемами интеграции и взаимодействия и, по-видимому, уникален в использовании "операционных представлений", детализирующих операционную область внешнего клиента, в которой будет работать разрабатываемая система.
DoDAF определяет набор продуктов, которые действуют как механизмы для визуализации, понимания, и усваивание широкого объема и сложностей описания архитектуры через графику, табличные или текстовые средства. Эти продукты организованы под 4 взглядами:
- Общий вид (AV),
- Рабочий вид (OV),
- Представление систем (SV) и
- Технические стандарты View (TV).
Каждое представление отображает определенные перспективы архитектуры, как описано ниже. Для каждой разработки системы обычно создается только подмножество полного набора представлений DoDAF. На рисунке представлена информация, которая связывает рабочее представление, представление систем и служб и представление технических стандартов. Эти три представления и их взаимосвязи, обусловленные общими элементами данных архитектуры, обеспечивают основу для получения таких показателей, как оперативная совместимость или производительность, и для измерения влияния значений этих показателей на эффективность оперативной деятельности и выполнения задач/
Представления архитектуры федерального предприятия[править]
В архитектуре федерального предприятия США архитектура предприятия, сегмента и решения обеспечивают различные перспективы бизнеса путем изменения уровня детализации и решения связанных, но различных проблем. Как предприятия сами по себе иерархически организованы, так и различные представления, предоставляемые каждым типом архитектуры. Федеральное руководство по архитектуре предприятий (2006) определило три типа архитектуры:
- Архитектура предприятия,
- Архитектура сегмента, и
- Архитектура решения.
По определению, архитектура предприятия (EA) в основном связана с определением общих или общих активов – будь то стратегии, бизнес-процессы, инвестиции, данные, системы или технологии. EA руководствуется стратегией; она помогает агентству определить, соответствуют ли его ресурсы миссии агентства и стратегическим целям и задачам. С инвестиционной точки зрения EA используется для принятия решений о инвестиционном портфеле ИТ в целом. Следовательно, основными заинтересованными сторонами ЕА являются топ-менеджеры и руководители, перед которыми поставлена задача обеспечить максимально эффективное и результативное выполнение агентством своей миссии.
В отличие от этого, сегментная архитектура определяет простую дорожную карту для основной области миссии, бизнес-службы или службы предприятия. Архитектура сегмента управляется управлением бизнесом и предоставляет продукты, которые улучшают предоставление услуг гражданам и сотрудникам агентства. С точки зрения инвестиций сегментная архитектура определяет решения для бизнес-кейса или группы бизнес-кейсов, поддерживающих основную область миссии или общую или общую службу. Основными заинтересованными сторонами в сегментной архитектуре являются владельцы и менеджеры бизнеса. Архитектура сегмента связана с EA тремя принципами: структурирование, повторное использование и выравнивание. Во-первых, сегментная архитектура наследует структуру, используемую советником, хотя она может быть расширена и специализирована для удовлетворения конкретных потребностей основной области миссии или общей или общей службы. Во-вторых, сегментная архитектура повторно использует важные активы, определенные на уровне предприятия, включая: данные; общие бизнес-процессы и инвестиции; и приложения и технологии. В-третьих, сегментная архитектура согласуется с элементами, определенными на уровне предприятия, такими как бизнес-стратегии, мандаты, стандарты и показатели эффективности.
Номинальный набор представлений[править]
В поисках "основы для моделирования архитектур космических систем" Питер Шеймс и Джозеф Скиппер (2006) определили "номинальный набор представлений" [7], полученных из CCSDS RASDS, RM-ODP, ISO 10746 и совместимых с IEEE 1471 .
Этот "набор представлений", как описано ниже, представляет собой список возможных точек зрения моделирования. Не все эти представления могут использоваться для одного проекта, а другие представления могут быть определены по мере необходимости. Обратите внимание, что для некоторых анализов элементы с нескольких точек зрения могут быть объединены в новое представление, возможно, с помощью многоуровневого представления.
В последней презентации этот номинальный набор представлений был представлен в виде расширенной семантической информационной модели RASDS.[25] настоящим RASDS означает справочную архитектуру для систем космических данных. см. второе изображение.
Enterprise Viewpoint[править]
- Организационное представление-включает организационные элементы, их структуры и связи. Может включать соглашения, контракты, политику и организационные взаимодействия.
- Представление требований-описывает требования, цели и задачи, которые управляют системой. Говорит, что система должна быть в состоянии сделать.
- Представление сценария-описание способа использования системы см. В разделе планирование сценария . Включает представления пользователей и описания поведения системы.
Информационная точка зрения[править]
Представление метамодели-абстрактное представление, определяющее элементы информационной модели, их структуры и связи. Определяет классы данных, которые создаются и управляются системой и архитектурой данных. Представление информации-описание фактических данных и информации, которые реализуются и обрабатываются в системе. Элементы данных определяются представлением metamodel и на них ссылаются функциональные объекты в других представлениях.
Функциональная точка зрения[править]
- Функциональное представление потока данных-абстрактное представление, описывающее функциональные элементы в системе, их взаимодействия, поведение, предоставляемые услуги, ограничения и потоки данных между ними. Определяет, какие функции система способна выполнять, независимо от того, как эти функции фактически реализованы.
- Представление функционального управления-описывает потоки управления и взаимодействия между функциональными элементами в системе. Включает в себя общие взаимодействия управления системой, взаимодействия между элементами управления и элементами датчика / эффектора и взаимодействия Управления.
Физическая точка зрения[править]
- Представление системы данных-описывает инструменты, компьютеры и компоненты хранения данных, их атрибуты системы данных и коммуникационные соединители (шины, сети, связи точка-точка), которые используются в системе.
- Telecomm view-описывает компоненты telecomm (антенна, приемопередатчик), их атрибуты и их разъемы (RF или оптические связи).
- Навигационный вид-описывает движение основных элементов внутри системы (траектория, траектория, орбита), включая их взаимодействие с внешними элементами и силами, которые находятся вне контроля системы, но которые должны быть смоделированы с ним, чтобы понять поведение системы (планеты, астероиды, солнечное давление, гравитация)
- Структурный взгляд-описывает структурные компоненты в системе (шина с/к, распорки, панели, сочленение), их физические атрибуты и соединители, вместе с уместными структурными аспектами других компонентов( массы, жесткости, приложения)
- Тепловой вид-описывает активные и пассивные тепловые компоненты в системе (радиаторы, охладители, вентиляционные отверстия) и их соединители (физическое и свободное космическое излучение) и атрибуты, наряду с тепловыми свойствами других компонентов (т. е. антенна как солнцезащитный козырек)
- Power view-описывает активные и пассивные силовые компоненты в системе (солнечные батареи, батареи, Ртги) в системе и их разъемы, а также силовые свойства других компонентов (системы данных и двигательных элементов в качестве поглотителей энергии и конструктивных панелей в качестве заземления плоскости)
- Propulsion view-описывает активные и пассивные компоненты движения в системе (двигатели, гироскопы, двигатели, колеса) внутри системы и их соединители, а также пропульсивные свойства других компонентов/
Инженерная точка зрения[править]
- Представление распределения-описывает распределение функциональных объектов по проектируемым физическим и вычислительным компонентам в Системе, позволяет анализировать производительность и использовать для проверки соответствия требованиям
- Представление программного обеспечения-описывает аспекты программной инженерии системы, проектирование программного обеспечения и реализацию функциональных возможностей в рамках программных компонентов, выбор языков и библиотек, которые будут использоваться, определение API, проектирование абстрактных функциональных объектов в осязаемые программные элементы. Некоторые функциональные элементы, описанные с помощью программного языка, фактически могут быть реализованы в виде аппаратных средств (FPGA, ASIC)
- Аппаратные представления-описывает аппаратные инженерные аспекты системы, аппаратное проектирование, выбор и реализацию всех физических компонентов, которые будут собраны в систему. Таких взглядов может быть много, и каждая из них специфична для той или иной инженерной дисциплины.
- Представление протокола связи-описание сквозного проектирования протоколов связи и связанных с ними служб транспорта и управления данными, отображение стеков протоколов по мере их реализации на каждом из физических компонентов системы.
- Представление рисков-описывает риски, связанные с проектированием системы, процессами и технологиями, присваивает дополнительные атрибуты оценки рисков другим элементам, описанным в архитектуре
- Взгляд инженера управления-анализирует систему с точки зрения ее управляемости, выделения элементов в систему управления и систему управления
- Представление интеграции и тестирования – рассматривает систему с точки зрения того, что должно быть сделано для сборки, интеграции и тестирования системы и подсистем и сборок. Включает в себя проверку правильной функциональности, управляемой сценариями, в соответствии с требованиями.
- IV&V view-независимая валидация и проверка функциональности и правильной работы системы на соответствие требованиям. Соответствует ли разработанная и разработанная система целям и задачам.
Технологическая точка зрения[править]
- Представление "стандарты" - определяет стандарты, которые должны быть приняты при проектировании системы (например, протоколы связи, допуск излучения, пайка). Это, по сути, ограничения на процессы проектирования и реализации.
- Представление инфраструктуры-определяет элементы инфраструктуры, которые должны поддерживать проектирование, проектирование и изготовление. Может включать в себя элементы системы данных( конструкторские хранилища, каркасы, инструменты, сети) и аппаратные элементы (изготовление микросхем, тепловакуумная установка, механический цех, лаборатория радиочастотного тестирования)
- Представление "разработка и оценка технологий" - включает описание программ разработки технологий, предназначенных для создания алгоритмов или компонентов, которые могут быть включены в проект разработки системы. Включает в себя оценку свойств выбранных аппаратных и программных компонентов, чтобы определить, находятся ли они на достаточном уровне зрелости, чтобы быть принятыми для проектируемой миссии.
В отличие от предыдущих перечисленных моделей представления, этот "номинальный набор представлений" перечисляет целый ряд представлений, позволяющих разработать мощные и расширяемые подходы для описания общего класса программно-интенсивных системных архитектур.