Посмотреть модель - View model

Для использования в других целях см. Посмотреть модель (значения).
В ЧАЙФ Матрица взглядов и перспектив.

А просмотреть модель или же рамки точек зрения в системная инженерия, программная инженерия, и предприятие инжиниринг это структура, которая определяет согласованный набор взгляды будет использоваться при строительстве Архитектура системы, программная архитектура, или же архитектура предприятия. А Посмотреть представляет собой представление всей системы с точки зрения связанного набора проблем.[1][2]

С начала 1990-х годов был предпринят ряд попыток предписать подходы к описанию и анализу системных архитектур. Эти недавние усилия определяют набор взглядов (или точек зрения). Иногда их называют каркасы архитектуры или же каркасы архитектуры предприятия, но обычно их называют «моделями просмотра».

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

Обзор

Цель взглядов и точек зрения - дать людям возможность понять очень сложные системы, чтобы организовать элементы проблемы и решения вокруг областей экспертиза и чтобы отдельные проблемы. в инженерное дело Для физически интенсивных систем точки зрения часто соответствуют возможностям и обязанностям внутри инженерной организации.[3]

Спецификации самых сложных систем настолько обширны, что ни один человек не может полностью понять все аспекты спецификаций. Более того, у всех нас разные интересы в данной системе и разные причины для изучения система с технические характеристики. А бизнес Руководитель будет задавать другие вопросы о структуре системы, чем разработчик системы. Таким образом, концепция структуры точек зрения состоит в том, чтобы предоставить отдельные точки зрения на спецификацию данной сложной системы, чтобы облегчить общение с заинтересованными сторонами. Каждая точка зрения удовлетворяет аудиторию с интересом к определенному набору аспектов системы. Каждая точка зрения может использовать определенную язык точки зрения это оптимизирует словарный запас и представление аудитории этой точки зрения. Моделирование точек обзора стало эффективным подходом к решению неотъемлемой сложности больших распределенных систем.

Практики описания архитектуры, как описано в IEEE Std 1471-2000, используйте несколько представлений для решения нескольких проблемных областей, каждое из которых сосредоточено на определенном аспекте системы. Примеры каркасы архитектуры использование нескольких представлений, включая Крюхтена Модель "4 + 1", то Фреймворк Захмана, TOGAF, DoDAF, и RM-ODP.

История

В 1970-х годах в разработке программного обеспечения начали появляться методы моделирования с несколькими представлениями. Дуглас Т. Росс и К. Шоман в 1977 году представил контекст конструкций, точку зрения и точку обзора для организации процесса моделирования при определении системных требований.[4] Согласно Россу и Шоману, точка зрения «проясняет, какие аспекты считаются важными для достижения ... общей цели [модели]» и определяет Как мы смотрим на [моделируемый объект]?

В качестве примеров точек зрения в документе предлагаются: техническая, операционная и экономическая точки зрения. В 1992 г. Энтони Финкельштейн и другие опубликовали очень важную статью о точках зрения.[5] В этой работе: «Точка зрения может рассматриваться как комбинация идеи« актера »,« источника знаний »,« роли »или« агента »в процессе разработки и идеи« взгляда »или« перспективы ». «Который утверждает актер». Важная идея в этой статье заключалась в том, чтобы выделить " стиль представления, схема и обозначения, с помощью которых точка зрения выражает то, что она может видеть "и" Технические характеристики, высказывания, выраженные в стиле точки зрения, описывающей определенные области ". Последующие работы, такие как IEEE 1471, сохранили это различие, используя два отдельных термина: точка зрения и точка зрения соответственно.

С начала 1990-х годов был предпринят ряд попыток кодифицировать подходы к описанию и анализу системных архитектур. Их часто называют каркасы архитектуры или иногда наборы точек зрения. Многие из них были профинансированы Министерство обороны США, но некоторые из них возникли в результате международных или национальных усилий в ISO или IEEE. Среди них Рекомендуемая практика IEEE для архитектурного описания программно-интенсивных систем (IEEE Std 1471-2000 ) установил полезные определения точки зрения, точки зрения, заинтересованного лица и озабоченности, а также руководящие принципы документирования Архитектура системы за счет использования нескольких представлений путем применения точек обзора для решения озабоченность заинтересованных сторон.[6] Преимущество множественных представлений заключается в том, что скрытые требования и разногласия заинтересованных сторон могут быть легче обнаружены. Однако исследования показывают, что на практике дополнительная сложность согласования нескольких точек зрения может подорвать это преимущество.[7]

IEEE 1471 (сейчас же ISO / IEC / IEEE 42010: 2011, Системная и программная инженерия - Описание архитектуры) предписывает содержание описаний архитектуры и описывает их создание и использование в ряде сценариев, включая предшествующий и беспрецедентный дизайн, эволюционный дизайн и захват проекта существующих систем. Во всех этих сценариях общий процесс одинаков: идентифицировать заинтересованные стороны, выявить проблемы, определить набор точек зрения, которые будут использоваться, а затем применить эти спецификации точек зрения для разработки набора точек зрения, относящихся к интересующей системе. Вместо того, чтобы определять конкретный набор точек зрения, стандарт предоставляет единые механизмы и требования для архитекторов и организаций по определению их собственных точек зрения. В 1996 году Эталонная модель ISO для открытой распределенной обработки (RM-ODP ) был опубликован, чтобы предоставить полезную основу для описания архитектуры и проектирования крупномасштабных распределенных систем.

Посмотреть темы моделей

Вид

Вид на систему - это представление системы с точки зрения точки зрения. Эта точка зрения на систему включает перспективу, фокусирующуюся на конкретных проблемах, связанных с системой, которая подавляет детали, чтобы предоставить упрощенную модель, имеющую только те элементы, которые связаны с проблемами точки обзора. Например, точка зрения безопасности фокусируется на проблемах безопасности, а модель точки зрения безопасности содержит те элементы, которые связаны с безопасностью из более общей модели системы.[8]

А Посмотреть позволяет пользователю изучить часть конкретной области интересов. Например, информационное представление может представлять все функции, организации, технологии и т. Д., Которые используют определенную часть информации, в то время как организационное представление может представлять все функции, технологии и информацию, представляющую интерес для конкретной организации. в Фреймворк Захмана Представления включают группу рабочих продуктов, разработка которых требует определенных аналитических и технических знаний, поскольку они сосредоточены на том, «что», «как», «кто», «где», «когда» или «почему» предприятия. Например, рабочие продукты Functional View отвечают на вопрос «как выполняется миссия?» Их легче всего разработать специалистами в функциональная декомпозиция с использованием моделирования процессов и деятельности. Они показывают предприятие с точки зрения функций. Они также могут отображать организационные и информационные компоненты, но только в том смысле, в котором они связаны с функциями.[9]

Точки обзора

В системной инженерии точка зрения - это разделение или ограничение проблем в системе. Принятие точки зрения полезно, так что вопросы в этих аспектах можно решать отдельно. Хороший выбор точек зрения также разделяет дизайн системы на конкретные области знаний.[3]

Точки обзора предоставляют соглашения, правила и языки для построения, представления и анализа представлений. В ISO / IEC 42010: 2007 (IEEE-Std-1471-2000 ) точка зрения - это спецификация для индивидуальной точки зрения. Вид - это представление всей системы с точки зрения точки зрения. Представление может состоять из одного или нескольких архитектурные модели.[10] Каждая такая архитектурная модель разрабатывается с использованием методов, установленных соответствующей архитектурной системой, а также для системы в целом.[6]

Перспективы моделирования

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

В информационные системы, традиционный способ разделения перспектив моделирования состоит в том, чтобы различать структурные, функциональные и поведенческие / процессуальные перспективы. Это вместе с перспективами правил, объектов, коммуникаций, акторов и ролей является одним из способов классификации подходов к моделированию. [11]

Модель точки обзора

В любой заданной точке обзора можно создать модель системы, которая содержит только те объекты, которые видны с этой точки обзора, но также фиксирует все объекты, отношения и ограничения, которые присутствуют в системе и относятся к этой точке обзора. Такая модель называется моделью точки зрения или взглядом на систему с этой точки зрения.[3]

Данное представление - это спецификация системы на определенном уровне абстракции с данной точки зрения. Различные уровни абстракции содержат разные уровни детализации. Представления более высокого уровня позволяют инженеру формировать и понимать всю конструкцию, а также выявлять и решать проблемы в целом. Представления нижнего уровня позволяют инженеру сосредоточиться на части проекта и разработать подробные спецификации.[3]

Иллюстрация представлений, продуктов и данных в Architecture Framework.

Однако в самой системе все спецификации, появляющиеся в различных моделях точек зрения, должны быть учтены в реализованных компонентах системы. И спецификации для любого данного компонента могут быть составлены с разных точек зрения. С другой стороны, спецификации, вызванные распределением функций по конкретным компонентам и взаимодействиями компонентов, обычно будут отражать иное разделение проблем, чем то, которое отражено в исходных точках зрения. Таким образом, дополнительные точки зрения, решающие проблемы отдельных компонентов и восходящий синтез системы, также могут быть полезны.[3]

Описание архитектуры

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

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

Типы моделей представления системы

Подход с тремя схемами

Понятие модели с тремя схемами было впервые введено в 1977 г. Трехуровневая архитектура ANSI / X3 / SPARC, который определил три уровня для моделирования данных.[12]

В Подход с тремя схемами для моделирования данных, представленного в 1977 году, можно считать одной из первых моделей представления. Это подход к построению информационных систем и системного управления информацией, который способствует концептуальная модель как ключ к достижению интеграция данных.[13] Подход с тремя схемами определяет три схемы и представления:

  • Внешняя схема для пользовательских представлений
  • Концептуальная схема интегрирует внешние схемы
  • Внутренняя схема, определяющая физические структуры хранения

В центре концептуальная схема определяет онтология из концепции как пользователи думайте о них и говорите о них. Физическая схема описывает внутренние форматы данные хранится в база данных, а внешняя схема определяет представление данных, представленных в прикладные программы.[14] Платформа попыталась разрешить использование нескольких моделей данных для внешних схем.[15]

С годами навыки и интерес к созданию информационных систем сильно выросли. Однако по большей части традиционный подход к построению систем сосредоточен только на определении данные из двух разных точек зрения: «пользовательский» и «компьютерный». С точки зрения пользователя, которая будет называться «внешней схемой», определение данных происходит в контексте отчетов и экранов, предназначенных для помощи людям в выполнении их конкретной работы. Требуемая структура данных из представления использования изменяется в зависимости от бизнес-среды и индивидуальных предпочтений пользователя. С компьютерной точки зрения, которая будет называться «внутренней схемой», данные определяются в терминах файловых структур для хранения и поиска. Требуемая структура данных для компьютерное хранилище зависит от конкретной используемой компьютерной технологии и потребности в эффективной обработке данных.[16]

4 + 1 видовая модель архитектуры

Иллюстрация 4+1 просмотреть модель или архитектуру.

4+1 это модель представления, разработанная Филипп Крюхтен в 1995 году для описания архитектуры программно-интенсивных систем, основанной на использовании нескольких одновременных представлений.[17] Представления используются для описания системы с точки зрения различных заинтересованных сторон, таких как конечные пользователи, разработчики и менеджеры проектов. Четыре вида модели: логическая, разработка, процесс и физическая.

Четыре вида модели касаются:

  • Логический взгляд: касается функциональности, которую система предоставляет конечным пользователям.
  • Вид развития: иллюстрирует систему с точки зрения программиста и касается управления программным обеспечением.
  • Просмотр процесса: имеет дело с динамическим аспектом системы, объясняет системные процессы и то, как они взаимодействуют, и сосредотачивается на поведении системы во время выполнения.
  • Физический вид: изображает систему с точки зрения системного инженера. Он касается топологии программных компонентов на физическом уровне, а также связи между этими компонентами.

Дополнительно выбрано сценарии использования или сценарии используются для иллюстрации архитектуры. Следовательно, модель содержит 4 + 1 просмотров.[17]

Типы представлений архитектуры предприятия

Каркас архитектуры предприятия определяет, как организовать структуру и представления, связанные с архитектура предприятия. Поскольку дисциплина Enterprise Architecture and Engineering очень широка, а предприятия могут быть большими и сложными, модели, связанные с этой дисциплиной, также имеют тенденцию быть большими и сложными. Чтобы управлять этим масштабом и сложностью, Архитектура Framework предоставляет инструменты и методы, которые могут сосредоточить задачу и позволить создавать ценные артефакты, когда они больше всего нужны.

Архитектурные рамки обычно используются в Информационные технологии и Информационная система управление. Организация может пожелать потребовать, чтобы определенные модели были произведены до Системный дизайн может быть одобрен. Точно так же они могут пожелать указать определенные представления, которые будут использоваться в документации закупаемых систем - Министерство обороны США предусматривает, что конкретные мнения DoDAF должны быть предоставлены поставщиками оборудования для капитального проекта выше определенной стоимости.

Фреймворк Захмана

Упрощенная иллюстрация Фреймворк Захмана с объяснением строк.[18] Исходный фреймворк более продвинутый, см. Пример здесь.

В Фреймворк Захмана, первоначально задуманный Джон Захман в IBM в 1987 году - это структура для архитектуры предприятия, которая обеспечивает формальный и хорошо структурированный способ просмотра и определения предприятия.

Платформа используется для организации архитектурных «артефактов» таким образом, чтобы учитывать как цель артефакта (например, владелец бизнеса и строитель), так и конкретная проблема (например, данные и функциональность), которые решаются. Эти артефакты могут включать проектную документацию, спецификации и модели.[19]

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

RM-ODP просмотров

В RM-ODP модель представления, которая предоставляет пять общих и дополнительных точек зрения на систему и ее среду.

Эталонная модель открытой распределенной обработки Международной организации по стандартизации (ISO) (RM-ODP ) [21] определяет набор точек зрения для разделения проекта распределенной программно-аппаратной системы. Поскольку большинство проблем интеграции возникает при разработке таких систем или в очень аналогичных ситуациях, эти точки зрения могут оказаться полезными при разделении проблем интеграции. Точки зрения RMODP:[3]

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

RMODP дополнительно определяет требование к проекту, чтобы он содержал спецификации согласованности между точками зрения, включая:[3]

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

Просмотры DoDAF

В Структура архитектуры Министерства обороны (DoDAF) определяет стандартный способ организации архитектура предприятия (EA) или системная архитектура на дополнительные и последовательные взгляды. Он особенно подходит для больших систем со сложными проблемами интеграции и взаимодействия и, по-видимому, уникален тем, что использует "оперативные обзоры «подробное описание рабочей области внешнего клиента, в которой будет работать разрабатываемая система.

DoDAF связи между представлениями.[22]

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

  • Общий вид (AV),
  • Оперативный вид (OV),
  • Системный обзор (SV) и
  • Просмотр технических стандартов (ТВ).

Каждый вид отображает определенные перспективы архитектуры, как описано ниже. Для каждой разработки системы обычно создается только подмножество полного набора представлений DoDAF. На рисунке представлена ​​информация, которая связывает оперативный вид, представление систем и услуг и представление технических стандартов. Три представления и их взаимосвязь, определяемая элементами данных общей архитектуры, обеспечивают основу для определения таких показателей, как функциональная совместимость или производительность, а также для измерения влияния значений этих показателей на операционную миссию и эффективность задач.[22]

Представления архитектуры федерального предприятия

В США Архитектура федерального предприятия Архитектура предприятия, сегмента и решения обеспечивает различные перспективы бизнеса, варьируя уровень детализации и решая связанные, но разные проблемы. Подобно тому, как предприятия сами по себе иерархически организованы, каждый тип архитектуры обеспечивает различные представления. В Федеральном руководстве по архитектуре предприятия (2006 г.) определены три типа архитектуры:[23]

Архитектура федерального предприятия уровни и атрибуты[23]
  • Архитектура предприятия,
  • Сегментная архитектура и
  • Архитектура решения.

По определению, архитектура предприятия (EA) в основном занимается выявлением общих или общих активов - будь то стратегии, бизнес-процессы, инвестиции, данные, системы или технологии. Советник руководствуется стратегией; он помогает агентству определить, соответствуют ли его ресурсы миссии и стратегическим целям и задачам агентства. С инвестиционной точки зрения EA используется для принятия решений об инвестиционном портфеле ИТ в целом. Следовательно, основными заинтересованными сторонами EA являются старшие менеджеры и руководители, которым поручено обеспечить максимально эффективное и действенное выполнение агентством своей миссии.[23]

Напротив, сегментная архитектура определяет простую дорожную карту для основной области миссии, бизнес-услуги или корпоративной услуги. Сегментная архитектура определяется управлением бизнесом и предоставляет продукты, улучшающие предоставление услуг гражданам и персоналу агентства. С точки зрения инвестиций, сегментная архитектура определяет решения для бизнес-кейса или группы бизнес-кейсов, поддерживающих основную область миссии или общие или общие услуги. Основными заинтересованными сторонами архитектуры сегмента являются владельцы и менеджеры бизнеса. Архитектура сегмента связана с EA тремя принципами: структура, повторное использование и согласование. Во-первых, сегментная архитектура наследует структуру, используемую EA, хотя она может быть расширена и специализирована для удовлетворения конкретных потребностей основной области миссии или общей или совместно используемой службы. Во-вторых, архитектура сегмента повторно использует важные активы, определенные на уровне предприятия, включая: данные; общие бизнес-процессы и инвестиции; и приложения и технологии. В-третьих, архитектура сегмента согласуется с элементами, определенными на уровне предприятия, такими как бизнес-стратегии, требования, стандарты и показатели эффективности.[23]

Номинальный набор просмотров

В поисках «Структуры моделирования архитектур космических систем» Питер Шеймс и Джозеф Скиппер (2006) определили «номинальный набор представлений»,[6] На основе CCSDS RASDS, RM-ODP, ISO 10746 и в соответствии с IEEE 1471.

Иллюстрация из «Номинального набора просмотров».[24]

Этот «набор представлений», как описано ниже, представляет собой список возможных точек зрения моделирования. Не все эти представления могут использоваться для какого-либо одного проекта, при необходимости могут быть определены другие представления. Обратите внимание, что для некоторых анализов элементы из нескольких точек обзора могут быть объединены в новое представление, возможно, с использованием многоуровневого представления.

В последней презентации этот номинальный набор представлений был представлен как производная расширенной семантической информационной модели RASDS.[24] Таким образом, RASDS расшифровывается как Reference Architecture for Space Data Systems. см. второе изображение.

Enterprise Viewpoint[6]
  • Представление организации - включает организационная элементы, их структуры и отношения. Может включать соглашения, контракты, политики и организационные взаимодействия.
  • Представление требований - описывает требования, цели и задачи, которые управляют системой. Говорит, что система должна уметь.
  • Вид сценария - описывает способ, которым система предназначена для использования, см. планирование сценария. Включает просмотры пользователей и описания ожидаемого поведения системы.
Информационная точка зрения[6]
  • Представление метамодели - абстрактное представление, определяющее информационная модель элементы, их структуры и отношения. Определяет классы данных, которые создаются и управляются системой и архитектурой данных.
  • Информационное представление - описывает фактическое данные и Информация как это реализовано и которым управляют в системе. Элементы данных определяются представлением метамодели, и на них ссылаются функциональные объекты в других представлениях.
Эталонная архитектура для систем космических данных.[24]
Функциональная точка зрения[6]
  • Функциональное представление потока данных - абстрактное представление, описывающее функциональные элементы в системе, их взаимодействия, поведение, предоставляемые услуги, ограничения и потоки данных между ними. Определяет, какие функции способна выполнять система, независимо от того, как эти функции фактически реализованы.
  • Представление функционального управления - описывает потоки управления и взаимодействия между функциональными элементами внутри системы. Включает в себя общие взаимодействия системы управления, взаимодействия между элементами управления и сенсорными / исполнительными элементами, а также взаимодействия управления.
Физическая точка зрения[6]
  • Представление системы данных - описывает инструменты, компьютеры и компоненты хранилища данных, их атрибуты системы данных и соединители связи (шины, сети, связи точка-точка), которые используются в системе.
  • Представление Telecomm - описывает компоненты телекоммуникации (антенна, приемопередатчик), их атрибуты и их разъемы (RF или оптические каналы).
  • Представление навигации - описывает движение основных элементов в системе (траектория, путь, орбита), включая их взаимодействие с внешними элементами и силами, которые находятся вне контроля системы, но которые должны быть смоделированы с ее помощью, чтобы понять поведение системы. (планеты, астероиды, солнечное давление, гравитация)
  • Структурный вид - описывает структурные компоненты в системе (шина п / к, стойки, панели, сочленение), их физические характеристики и соединители, а также соответствующие структурные аспекты других компонентов (масса, жесткость, крепление).
  • Тепловой вид - описывает активные и пассивные тепловые компоненты в системе (радиаторы, охладители, вентиляционные отверстия) и их разъемы (физическое излучение и излучение в свободном пространстве) и атрибуты, а также тепловые свойства других компонентов (например, антенна как солнцезащитный козырек).
  • Power view - описывает активные и пассивные силовые компоненты в системе (солнечные панели, батареи, RTG) внутри системы и их разъемы, а также энергетические характеристики других компонентов (системы данных и силовые элементы в качестве источников питания и структурные панели в качестве заземления. самолет)
  • Вид силовой установки - описывает активные и пассивные двигательные компоненты в системе (подруливающие устройства, гироскопы, двигатели, колеса) внутри системы и их соединители, а также пропульсивные свойства других компонентов.
Онтология верхнего уровня MBED основана на Номинальном наборе представлений.[6]
Инженерная точка зрения[6]
  • Представление распределения - описывает распределение функциональных объектов по спроектированным физическим и вычислительным компонентам внутри системы, позволяет анализировать производительность и используется для проверки соответствия требованиям.
  • Представление программного обеспечения - описывает аспекты программной инженерии системы, дизайн программного обеспечения и реализацию функциональных возможностей в рамках программных компонентов, выбирает языки и библиотеки, которые будут использоваться, определяет API, выполняет проектирование абстрактных функциональных объектов в материальные элементы программного обеспечения. Некоторые функциональные элементы, описываемые на программном языке, могут быть реализованы как аппаратное обеспечение (FPGA, ASIC).
  • Аппаратные виды - описывают аппаратные аспекты системы, дизайн аппаратного обеспечения, выбор и реализацию всех физических компонентов, которые должны быть собраны в систему. Таких представлений может быть множество, каждое из которых относится к разной инженерной дисциплине.
  • Представление «Протокол связи» - описывает сквозное проектирование протоколов связи и связанных служб передачи данных и управления данными, показывает стеки протоколов по мере их реализации на каждом из физических компонентов системы.
  • Представление рисков - описывает риски, связанные с проектированием системы, процессами и технологиями, присваивает дополнительные атрибуты оценки рисков другим элементам, описанным в архитектуре.
  • Представление Control Engineering - анализирует систему с точки зрения ее управляемости, распределения элементов в системе под контролем и системой управления.
  • Представление «Интеграция и тестирование» - рассматривает систему с точки зрения того, что необходимо сделать для сборки, интеграции и тестирования системы, подсистем и сборок. Включает проверку надлежащей функциональности на основе сценариев в соответствии с требованиями.
  • Взгляд IV&V - независимая проверка и проверка функциональности и правильности работы системы в соответствии с требованиями. Достигает ли система, разработанная и разработанная, целям и задачам.
Точка зрения технологии[6]
  • Представление стандартов - определяет стандарты, которые должны быть приняты при проектировании системы (например, протоколы связи, радиационная стойкость, пайка). По сути, это ограничения на процессы проектирования и реализации.
  • Представление инфраструктуры - определяет элементы инфраструктуры, которые должны поддерживать процесс проектирования, проектирования и изготовления. Может включать элементы системы данных (проектные репозитории, фреймворки, инструменты, сети) и элементы оборудования (изготовление микросхем, термовакуумная установка, механический цех, лаборатория радиочастотных испытаний)
  • Представление «Разработка и оценка технологий» - включает описание программ разработки технологий, предназначенных для создания алгоритмов или компонентов, которые могут быть включены в проект разработки системы. Включает оценку свойств выбранных аппаратных и программных компонентов, чтобы определить, находятся ли они в достаточном состоянии зрелости, чтобы быть принятыми для разрабатываемой миссии.

В отличие от перечисленных ранее моделей представлений, этот «номинальный набор представлений» перечисляет весь диапазон представлений, позволяющих разработать мощные и расширяемые подходы для описания общего класса программно-интенсивных системных архитектур.[6]

Смотрите также

Рекомендации

  1. ^ ISO / IEC / IEEE 42010: 2011, Системная и программная инженерия - Описание архитектуры
  2. ^ ISO / IEC 10746-1, Информационные технологии. Открытая распределенная обработка. Эталонная модель: Обзор.
  3. ^ а б c d е ж грамм Эдвард Дж. Баркмейер и др. (2003). Концепции автоматизации системной интеграции NIST 2003.
  4. ^ Дуглас Т. Росс и К. Шоман младший "Структурированный анализ для определения требований". IEEE Transactions по разработке программного обеспечения, SE-3 (1), январь 1977 г.
  5. ^ А. Финкельштейн, Дж. Крамер, Б. Нусейбе, Л. Финкельштейн и М. Гедике. "Точки зрения: структура для интеграции нескольких точек зрения в разработку системы.." Международный журнал программной инженерии и инженерии знаний, 2(1):31-58, 1992.
  6. ^ а б c d е ж грамм час я j k Питер Шеймс, Джозеф Скиппер. «К основе моделирования архитектур космических систем» В архиве 2009-02-27 на Wayback Machine. НАСА, Лаборатория реактивного движения.
  7. ^ Истербрук, S .; Yu, E .; Aranda, J .; Юньтянь Фань; Horkoff, J .; Leica, M .; Кадир, Р.А. (2005). «Приводят ли точки зрения к лучшим концептуальным моделям? Исследовательский пример». 13-я Международная конференция IEEE по разработке требований (RE'05). С. 199–208. CiteSeerX  10.1.1.78.4594. Дои:10.1109 / RE.2005.23. ISBN  978-0-7695-2425-2.
  8. ^ Синан Си Альхир (2003). "Понимание архитектуры, управляемой моделями (MDA) ". В: Методы и инструменты. Осень 2003 г.
  9. ^ Совет директоров по информационным технологиям Министерства финансов США (2000 г.). Структура архитектуры предприятия казначейства. Версия 1, июль 2000 г. В архиве 18 марта 2009 г. Wayback Machine
  10. ^ IEEE-1471-2000
  11. ^ Джон Крогсти, (2003). Концептуальное моделирование, В архиве 16 марта 2007 г. Wayback Machine
  12. ^ Мэтью Уэст и Джулиан Фаулер (1999). Разработка высококачественных моделей данных В архиве 21 декабря 2008 г. Wayback Machine. Технический представитель по связям с общественностью STEP в Европе, занимающийся перерабатывающей промышленностью (EPISTLE).
  13. ^ РЕМЕНЬ РАЗДЕЛ 2 ПОДХОД. Проверено 30 сентября 2008 года.
  14. ^ Джон Ф. Сова (2004). [«Вызов супа знаний»]. опубликовано в: Тенденции исследований в области естественных наук, технологий и математического образования. Под редакцией Дж. Рамадаса и С. Чунавалы, Центр Хоми Бхабха, Мумбаи, 2006 г.
  15. ^ Гэд Ариав и Джеймс Клиффорд (1986). Новые направления для систем баз данных: исправленные версии статей. Высшая школа делового администрирования Нью-Йоркского университета. Центр исследований информационных систем, 1986.
  16. ^ itl.nist.gov (1993) Определение интеграции для информационного моделирования (IDEFIX) В архиве 2013-12-03 в Wayback Machine. 21 декабря 1993 г.
  17. ^ а б Крухтен, Филипп (1995, ноябрь). Архитектурные чертежи - модель архитектуры программного обеспечения «4 + 1». Программное обеспечение IEEE 12 (6), стр. 42-50.
  18. ^ Департамент США по делам ветеранов (2008 г.) Учебное пособие по архитектуре Zachman Architecture Framework В архиве 13 июля 2007 г. Wayback Machine. По состоянию на 06 декабря 2008 г.
  19. ^ Сравнение четырех лучших методологий архитектуры предприятия В архиве 2008-04-09 на Wayback Machine, Роджер Сешнс, Центр сетевой архитектуры разработчиков Microsoft,
  20. ^ Федеральная структура архитектуры предприятия В архиве 16 сентября 2008 г. Wayback Machine
  21. ^ ISO / IEC 10746-1: 1998 Информационные технологии - Открытая распределенная обработка: Эталонная модель - Часть 1: Обзор, Международная организация по стандартизации, Женева, Швейцария, 1998.
  22. ^ а б МО (2007) DoD Architecture Framework, версия 1.5 . 23 апреля 2007 г. В архиве 11 марта 2005 г. Wayback Machine
  23. ^ а б c d Управление Федеральной программы архитектуры предприятия (2006). Практическое руководство FEA[мертвая ссылка ].
  24. ^ а б c Питер Шеймс и Джозеф Скиппер (2006). К основе моделирования архитектур космических систем В архиве 2010-05-27 на Wayback Machine. 25 мая 2006 г.
Атрибуция

Эта статья включаетматериалы общественного достояния от Национальный институт стандартов и технологий интернет сайт https://www.nist.gov.

внешняя ссылка