Посмотреть модель
Модель представления или структура точек зрения в системной инженерии , разработке программного обеспечения и проектировании предприятия — это структура, которая определяет последовательный набор представлений , которые будут использоваться при построении архитектуры системы , архитектуры программного обеспечения или архитектуры предприятия . Представление — это представление всей системы с точки зрения связанного набора задач. [1] [2]
С начала 1990-х годов был предпринят ряд попыток предписать подходы к описанию и анализу системных архитектур. Результатом этих усилий стало определение набора взглядов (или точек зрения). Их иногда называют архитектурными платформами или структурами архитектуры предприятия , но обычно их называют «моделями представления».
Обычно представление — это рабочий продукт, который представляет конкретные данные об архитектуре данной системы. Однако тот же термин иногда используется для обозначения определения представления , включая конкретную точку зрения и соответствующее руководство, определяющее каждое конкретное представление. Термин « модель представления» связан с определениями представлений.
Обзор [ править ]
Цель взглядов и точек зрения состоит в том, чтобы позволить людям понять очень сложные системы , организовать элементы проблемы и решения по областям знаний и разделить проблемы . При проектировании физически интенсивных систем точки зрения часто соответствуют возможностям и обязанностям инженерной организации. [3]
Спецификации наиболее сложных систем настолько обширны, что ни один человек не может полностью понять все аспекты спецификаций. Более того, у всех нас разные интересы к той или иной системе и разные причины для ее характеристик изучения . Руководитель предприятия будет задавать другие вопросы о составе системы, чем специалист по ее внедрению. Таким образом, концепция структуры точек зрения заключается в том, чтобы представить отдельные точки зрения в спецификации данной сложной системы, чтобы облегчить общение с заинтересованными сторонами. Каждая точка зрения удовлетворяет аудиторию, интересующуюся определенным набором аспектов системы. Каждая точка зрения может использовать определенный язык точки зрения , который оптимизирует словарный запас и представление для аудитории этой точки зрения. Моделирование точек зрения стало эффективным подходом к решению проблемы, присущей большим распределенным системам, сложной сложности.
Практика описания архитектуры, описанная в стандарте IEEE Std 1471-2000 , использует несколько представлений для решения нескольких проблемных областей, каждое из которых сосредоточено на определенном аспекте системы. Примеры архитектурных фреймворков Крухтена , использующих несколько представлений, включают модель представления «4+1» , Zachman Framework , 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]
Представление . позволяет пользователю исследовать часть определенной области интересов Например, в информационном представлении могут быть представлены все функции, организации, технологии и т. д., которые используют конкретную часть информации, тогда как в организационном представлении могут быть представлены все функции, технологии и информация, представляющие интерес для конкретной организации. В рамках Захмана взгляды включают группу рабочих продуктов, разработка которых требует особых аналитических и технических знаний, поскольку они фокусируются либо на «что», «как», «кто», «где», «когда» или «почему». предприятия. Например, рабочие продукты функционального представления отвечают на вопрос «как выполняется миссия?» Их легче всего разработать специалистам по функциональной декомпозиции с использованием моделирования процессов и действий. Они показывают предприятие с точки зрения функций. Они также могут отображать организационные и информационные компоненты, но только в той мере, в какой они связаны с функциями. [9]
Точки зрения [ править ]
В системной инженерии точка зрения — это разделение или ограничение задач в системе. Принятие точки зрения полезно для того, чтобы проблемы в этих аспектах можно было решать отдельно. Хороший выбор точек зрения также разделяет проектирование системы на конкретные области знаний. [3]
Точки обзора предоставляют соглашения, правила и языки для построения, представления и анализа представлений. В ISO/IEC 42010:2007 ( IEEE-Std-1471-2000 ) точка зрения — это спецификация отдельного представления. Представление — это представление всей системы с точки зрения точки зрения. Представление может состоять из одной или нескольких архитектурных моделей . [10] Каждая такая архитектурная модель разрабатывается с использованием методов, установленных для связанной с ней архитектурной системы, а также для системы в целом. [6]
Моделирование перспектив [ править ]
Моделирование перспектив — это набор различных способов представления заранее выбранных аспектов системы. Каждая точка зрения имеет разную направленность, концептуализацию, посвящение и визуализацию того, что модель представляет собой .
В информационных системах традиционным способом разделения перспектив моделирования является выделение структурной, функциональной и поведенческой/процессуальной точек зрения. Это вместе с правилами, объектами, коммуникациями, актерами и ролями является одним из способов классификации подходов к моделированию. [11]
Модель точки обзора [ править ]
С любой точки зрения можно создать модель системы, которая будет содержать только объекты, видимые с этой точки зрения, но также захватит все объекты, отношения и ограничения, которые присутствуют в системе и имеют отношение к этой точке зрения. Такая модель называется моделью точки зрения или представлением системы с этой точки зрения. [3]
Данное представление — это спецификация системы на определенном уровне абстракции с заданной точки зрения. Различные уровни абстракции содержат разные уровни детализации. Представления более высокого уровня позволяют инженеру моделировать и понимать всю конструкцию, а также выявлять и решать проблемы в целом. Представления нижнего уровня позволяют инженеру сконцентрироваться на части проекта и разработать подробные спецификации. [3]
Однако в самой системе все характеристики, представленные в различных моделях точек зрения, должны быть отражены в реализованных компонентах системы. И спецификации для любого конкретного компонента могут быть составлены с самых разных точек зрения. С другой стороны, спецификации, вызванные распределением функций по конкретным компонентам и взаимодействиями компонентов, обычно отражают иное разделение задач, чем то, что отражено в первоначальных точках зрения. Таким образом, дополнительные точки зрения, учитывающие проблемы отдельных компонентов и восходящий синтез системы, также могут быть полезны. [3]
Описание архитектуры [ править ]
Описание архитектуры — это представление архитектуры системы в любой момент времени с точки зрения ее составных частей, того, как эти части функционируют, правил и ограничений, в соответствии с которыми эти части функционируют, и того, как эти части связаны друг с другом и с окружающей средой. В описании архитектуры данные об архитектуре используются несколькими представлениями и продуктами.
На уровне данных находятся элементы данных архитектуры и их определяющие атрибуты и отношения. На уровне представления находятся продукты и представления, которые поддерживают визуальные средства для передачи и понимания цели архитектуры, того, что она описывает, а также различных выполняемых архитектурных анализов. Продукты предоставляют возможность визуализации архитектурных данных в виде графических, табличных или текстовых представлений. Представления предоставляют возможность визуализировать архитектурные данные, относящиеся к различным продуктам, логически организуя данные для конкретной или целостной точки зрения на архитектуру.
Типы моделей представления системы [ править ]
Трехсхемный подход [ править ]
Трехсхемный подход к моделированию данных, представленный в 1977 году, можно считать одной из первых моделей представления. Это подход к построению информационных систем и системному управлению информацией, который продвигает концептуальную модель как ключ к достижению интеграции данных . [13] Подход «Три схемы» определяет три схемы и представления:
- Внешняя схема для пользовательских представлений
- Концептуальная схема объединяет внешние схемы.
- Внутренняя схема, определяющая физические структуры хранения.
В центре концептуальная схема определяет онтологию концепций , когда пользователи думают о них и говорят о них. Физическая схема описывает внутренние форматы данных, хранящихся в базе данных , а внешняя схема определяет представление данных, представляемых прикладным программам . [14] Платформа попыталась разрешить использование нескольких моделей данных для внешних схем. [15]
За прошедшие годы навыки и интерес к созданию информационных систем значительно выросли. Однако по большей части традиционный подход к построению систем фокусируется только на определении данных из двух различных представлений: «представления пользователя» и «представления компьютера». С точки зрения пользователя, которая будет называться «внешней схемой», определение данных происходит в контексте отчетов и экранов, предназначенных для помощи людям в выполнении их конкретной работы. Требуемая структура данных с точки зрения использования меняется в зависимости от бизнес-среды и индивидуальных предпочтений пользователя. С компьютерной точки зрения, которая будет называться «внутренней схемой», данные определяются с точки зрения файловых структур для хранения и извлечения. Требуемая структура данных для компьютерного хранения зависит от конкретной используемой компьютерной технологии и необходимости эффективной обработки данных. [16]
4+1 обзорная модель архитектуры [ править ]
4+1 — это модель представления, разработанная Филиппом Крухтеном в 1995 году для описания архитектуры программно-интенсивных систем, основанная на использовании нескольких параллельных представлений. [17] Представления используются для описания системы с точки зрения различных заинтересованных сторон, таких как конечные пользователи, разработчики и менеджеры проектов. Четыре представления модели: логическое представление, представление развития, процесс и физическое представление:
Четыре представления модели касаются:
- Логическое представление : связано с функциональностью, которую система предоставляет конечным пользователям.
- Представление разработки : иллюстрирует систему с точки зрения программиста и касается управления программным обеспечением.
- Представление процесса : рассматривает динамический аспект системы, объясняет системные процессы и то, как они взаимодействуют, а также фокусируется на поведении системы во время выполнения.
- Физический вид : изображает систему с точки зрения системного инженера. Он касается топологии программных компонентов на физическом уровне, а также связи между этими компонентами.
Кроме того, выбранные варианты использования для иллюстрации архитектуры используются или сценарии. Следовательно, модель содержит 4+1 представление. [17]
Типы представлений об архитектуре предприятия [ править ]
Структура архитектуры предприятия определяет, как организовать структуру и представления, связанные с архитектурой предприятия . Поскольку дисциплина «Архитектура и проектирование предприятия» настолько широка, а предприятия могут быть большими и сложными, модели, связанные с этой дисциплиной, также имеют тенденцию быть большими и сложными. Чтобы управлять таким масштабом и сложностью, архитектурная платформа предоставляет инструменты и методы, которые могут сфокусировать задачу и позволить создавать ценные артефакты, когда они больше всего необходимы.
Архитектурные рамки обычно используются в информационных технологиях и информационными системами управлении . Организация может пожелать потребовать производства определенных моделей до проекта системы утверждения . Аналогичным образом, они могут пожелать указать определенные представления, которые будут использоваться в документации по закупаемым системам - Министерство обороны США требует, чтобы конкретные представления DoDAF предоставлялись поставщиками оборудования для капитального проекта, превышающего определенную стоимость.
Захман Фреймворк [ править ]
, Zachman Framework первоначально задуманная Джоном Захманом из IBM в 1987 году, представляет собой основу для архитектуры предприятия, которая обеспечивает формальный и высокоструктурированный способ просмотра и определения предприятия.
Платформа используется для организации архитектурных «артефактов» таким образом, чтобы учитывать как то, на кого нацелен артефакт (например, владелец бизнеса и строитель), так и какая конкретная проблема (например, данные и функциональность) решается. Эти артефакты могут включать проектную документацию, спецификации и модели. [19]
На Zachman Framework часто ссылаются как на стандартный подход для выражения основных элементов архитектуры предприятия . Концепция Захмана была признана федеральным правительством США как «…полученная во всем мире как интегрированная основа для управления изменениями на предприятиях и в системах, которые их поддерживают». [20]
Просмотры RM-ODP [ править ]
Эталонная модель открытой распределенной обработки ( RM-ODP ) Международной организации по стандартизации (ISO). [21] определяет набор точек зрения для разделения проекта распределенной программно-аппаратной системы. Поскольку большинство проблем интеграции возникает при разработке таких систем или в очень аналогичных ситуациях, эти точки зрения могут оказаться полезными при разделении проблем интеграции. Точки зрения RMODP: [3]
- , точка зрения предприятия которая связана с назначением и поведением системы в связи с бизнес-целью и бизнес-процессами организации.
- информационная точка зрения , которая касается характера информации, обрабатываемой системой, и ограничений на использование и интерпретацию этой информации.
- вычислительная точка зрения , которая связана с функциональной декомпозицией системы на набор компонентов, которые демонстрируют определенное поведение и взаимодействуют на интерфейсах.
- инженерная точка зрения , которая касается механизмов и функций, необходимых для поддержки взаимодействия вычислительных компонентов.
- технологическая точка зрения , которая касается явного выбора технологий для реализации системы и, в частности, для связи между компонентами.
RMODP далее определяет требование к дизайну, чтобы оно содержало спецификации согласованности между точками зрения, в том числе: [3]
- использование корпоративных объектов и процессов при определении информационных единиц
- использование корпоративных объектов и поведения при определении поведения вычислительных компонентов, а также использование информационных единиц при определении вычислительных интерфейсов.
- связь инженерных решений с вычислительными интерфейсами и требованиями к поведению
- удовлетворение информационных, вычислительных и инженерных требований в выбранных технологиях
Просмотры DoDAF [ править ]
Структура архитектуры Министерства обороны (DoDAF) определяет стандартный способ организации архитектуры предприятия (EA) или архитектуры системы в виде взаимодополняющих и согласованных представлений. Он особенно подходит для больших систем со сложными проблемами интеграции и взаимодействия и, по-видимому, уникален тем, что использует « операционные представления », подробно описывающие операционный домен внешнего заказчика, в котором будет работать разрабатываемая система.
DoDAF определяет набор продуктов, которые действуют как механизмы визуализации, понимания, и усвоение широкого объема и сложности описания архитектуры с помощью графики, табличными или текстовыми средствами. Эти продукты организованы в четырех представлениях:
- Общий вид (AV),
- Оперативный обзор (ОВ),
- Системное представление (SV) и
- Просмотр технических стандартов (ТВ).
Каждый вид отображает определенные аспекты архитектуры, как описано ниже. Для каждой разработки системы обычно создается только подмножество полного набора представлений DoDAF. На рисунке представлена информация, которая связывает эксплуатационный взгляд , взгляд на системы и услуги и взгляд на технические стандарты. Три представления и их взаимосвязи, основанные на элементах данных общей архитектуры, обеспечивают основу для получения таких показателей, как совместимость или производительность, а также для измерения влияния значений этих показателей на эффективность оперативной миссии и задач. [22]
предприятия Представления об архитектуре федерального
США В федеральной корпоративной архитектуре архитектура предприятия, сегмента и решения обеспечивает различные перспективы бизнеса, варьируя уровень детализации и решая связанные, но разные проблемы. Точно так же, как предприятия сами по себе иерархически организованы, так и разные представления, предоставляемые каждым типом архитектуры. В Федеральном практическом руководстве по архитектуре предприятий (2006 г.) определены три типа архитектуры: [23]
- Архитектура предприятия,
- Сегментная архитектура и
- Архитектура решения.
По определению, архитектура предприятия (EA) в основном связана с выявлением общих или общих активов – будь то стратегии, бизнес-процессы, инвестиции, данные, системы или технологии. EA руководствуется стратегией; это помогает агентству определить, соответствуют ли его ресурсы миссии агентства, стратегическим целям и задачам. С инвестиционной точки зрения EA используется для принятия решений относительно инвестиционного портфеля ИТ в целом. Следовательно, основными заинтересованными сторонами EA являются старшие менеджеры и руководители, которым поручено обеспечить максимально эффективное и результативное выполнение агентством своей миссии. [23]
Напротив, архитектура сегментов определяет простую дорожную карту для основной области миссии, бизнес-услуг или корпоративных услуг. Архитектура сегментов определяется управлением бизнесом и предоставляет продукты, которые улучшают предоставление услуг гражданам и сотрудникам агентств. С инвестиционной точки зрения архитектура сегмента определяет решения для бизнес-кейса или группы бизнес-кейсов, поддерживающих основную область миссии или общую или совместно используемую услугу. Основными заинтересованными сторонами в сегментной архитектуре являются владельцы и менеджеры бизнеса. Архитектура сегментов связана с EA тремя принципами: структура, повторное использование и согласованность. Во-первых, архитектура сегмента наследует структуру, используемую EA, хотя она может быть расширена и специализирована для удовлетворения конкретных потребностей основной области миссии или общего или совместного обслуживания. Во-вторых, архитектура сегментов повторно использует важные активы, определенные на уровне предприятия, включая: данные; общие бизнес-процессы и инвестиции; а также приложения и технологии. В-третьих, архитектура сегмента согласуется с элементами, определенными на уровне предприятия, такими как бизнес-стратегии, мандаты, стандарты и показатели эффективности. [23]
Номинальный набор просмотров [ править ]
В поисках «Структуры моделирования архитектуры космических систем» Питер Шеймс и Джозеф Скиппер (2006) определили «номинальный набор представлений», [6] Получено на основе CCSDS RASDS, RM-ODP, ISO 10746 и соответствует стандарту IEEE 1471 .
Этот «набор представлений», как описано ниже, представляет собой список возможных точек зрения моделирования. Не все из этих представлений могут использоваться для какого-либо одного проекта, и при необходимости могут быть определены другие представления. Обратите внимание, что для некоторых анализов элементы с нескольких точек зрения могут быть объединены в новое представление, возможно, с использованием многоуровневого представления.
В последней презентации этот номинальный набор представлений был представлен как вывод расширенной семантической информационной модели RASDS. [24] Настоящим RASDS означает «Эталонная архитектура для систем космических данных». см. второе изображение.
- Точка зрения предприятия [6]
- Представление организации. Включает организационные элементы, их структуры и отношения. Может включать соглашения, контракты, политику и организационное взаимодействие.
- Представление требований — описывает требования , цели и задачи, которые управляют системой. Говорит, что должна уметь делать система.
- Представление сценария — описывает способ использования системы, см. планирование сценария . Включает мнения пользователей и описания ожидаемого поведения системы.
- Информационная точка зрения [6]
- Представление метамодели — абстрактное представление, определяющее элементы информационной модели , их структуры и отношения. Определяет классы данных, которые создаются и управляются системой, а также архитектуру данных.
- Представление информации. Описывает фактические данные и информацию в том виде, в котором они реализуются и обрабатываются в системе. Элементы данных определяются представлением метамодели, и на них ссылаются функциональные объекты в других представлениях.
- Функциональная точка зрения [6]
- Представление функционального потока данных — абстрактное представление, описывающее функциональные элементы системы, их взаимодействия, поведение, предоставляемые услуги, ограничения и потоки данных между ними. Определяет, какие функции способна выполнять система, независимо от того, как эти функции фактически реализованы.
- Представление «Функциональное управление» — описывает потоки управления и взаимодействия между функциональными элементами внутри системы. Включает в себя общие взаимодействия по управлению системой, взаимодействия между элементами управления и сенсорными/эффекторными элементами, а также взаимодействия по управлению.
- Физическая точка зрения [6]
- Представление «Система данных» — описывает инструменты, компьютеры и компоненты хранения данных, их атрибуты системы данных и коммуникационные разъемы (шины, сети, каналы связи «точка-точка»), которые используются в системе.
- Представление телекоммуникаций – описывает компоненты телекоммуникаций (антенна, приемопередатчик), их атрибуты и разъемы (РЧ или оптические каналы).
- Представление навигации. Описывает движение основных элементов внутри системы (траектория, путь, орбита), включая их взаимодействие с внешними элементами и силами, которые находятся вне контроля системы, но которые необходимо моделировать с их помощью, чтобы понять поведение системы. (планеты, астероиды, солнечное давление, гравитация)
- Структурный вид – описывает структурные компоненты системы (шина ПК, стойки, панели, шарниры), их физические атрибуты и разъемы, а также соответствующие структурные аспекты других компонентов (масса, жесткость, крепление).
- Тепловой вид — описывает активные и пассивные тепловые компоненты в системе (радиаторы, охладители, вентиляционные отверстия) и их разъемы (физическое излучение и излучение в свободном пространстве) и атрибуты, а также тепловые свойства других компонентов (например, антенны в качестве солнцезащитного козырька).
- Представление о мощности – описывает активные и пассивные силовые компоненты системы (солнечные панели, батареи, РИТЭГи) внутри системы и их разъемы, а также силовые свойства других компонентов (система обработки данных и силовые элементы в качестве потребителей энергии и структурные панели в качестве заземления). самолет)
- Вид двигательной установки — описывает активные и пассивные компоненты двигательной установки в системе (двигатели, гироскопы, двигатели, колеса) внутри системы и их разъемы, а также движущие свойства других компонентов.
- Инженерная точка зрения [6]
- Представление распределения — описывает распределение функциональных объектов по спроектированным физическим и вычислительным компонентам внутри системы, позволяет анализировать производительность и используется для проверки удовлетворения требований.
- Представление программного обеспечения. Описывает аспекты разработки программного обеспечения системы, проектирование программного обеспечения и реализацию функций в компонентах программного обеспечения, выбор языков и библиотек, которые будут использоваться, определение API-интерфейсов, преобразование абстрактных функциональных объектов в материальные элементы программного обеспечения. Некоторые функциональные элементы, описанные с помощью языка программного обеспечения, на самом деле могут быть реализованы как аппаратные средства (FPGA, ASIC).
- Представления об аппаратном обеспечении – описывают аспекты разработки аппаратного обеспечения системы, проектирование аппаратного обеспечения, выбор и внедрение всех физических компонентов, которые будут собраны в систему. Таких взглядов может быть много, каждый из которых специфичен для отдельной инженерной дисциплины.
- Представление протокола связи — описывает комплексную конструкцию протоколов связи и связанных с ними служб передачи данных и управления данными, показывает стеки протоколов в том виде, в котором они реализованы на каждом из физических компонентов системы.
- Представление рисков. Описывает риски, связанные с конструкцией системы, процессами и технологиями, назначает дополнительные атрибуты оценки рисков другим элементам, описанным в архитектуре.
- Представление Control Engineering - анализирует систему с точки зрения ее управляемости, распределения элементов в управляемую систему и систему управления.
- Представление «Интеграция и тестирование» — рассматривает систему с точки зрения того, что необходимо сделать для сборки, интеграции и тестирования системы, подсистем и сборок. Включает проверку правильности функциональности на основе сценариев и удовлетворения требований.
- Представление IV&V – независимая проверка и проверка функциональности и правильности работы системы в соответствии с требованиями. Соответствует ли система в том виде, в каком она спроектирована и разработана, целям и задачам?
- Технологическая точка зрения [6]
- Представление «Стандарты» — определяет стандарты, которые должны быть приняты при проектировании системы (например, протоколы связи, радиационная устойчивость, пайка). По сути, это ограничения на процессы проектирования и реализации.
- Представление инфраструктуры. Определяет элементы инфраструктуры, которые должны поддерживать процесс проектирования, проектирования и изготовления. Могут включать элементы системы данных (хранилища проектов, структуры, инструменты, сети) и элементы аппаратного обеспечения (производство чипов, термовакуумная установка, механический цех, лаборатория радиочастотных испытаний).
- Представление «Разработка и оценка технологий» — включает описание программ разработки технологий, предназначенных для создания алгоритмов или компонентов, которые могут быть включены в проект разработки системы. Включает оценку свойств выбранных аппаратных и программных компонентов, чтобы определить, находятся ли они на достаточной стадии зрелости, чтобы их можно было использовать для разрабатываемой миссии.
В отличие от предыдущих перечисленных моделей представлений, этот «номинальный набор представлений» перечисляет целый ряд представлений, позволяющих разработать мощные и расширяемые подходы для описания общего класса системных архитектур с интенсивным использованием программного обеспечения. [6]
См. также [ править ]
- Структура архитектуры предприятия
- Организационная архитектура
- Методология разработки программного обеспечения
- Структура архитектуры казначейского предприятия
- ТОГАФ
- Захман Фреймворк
- Онтология (информатика)
- Приобретение знаний
Ссылки [ править ]
- ^ ISO/IEC/IEEE 42010:2011, Системы и т. д. Описание архитектуры.
- ^ ИСО/МЭК 10746-1, Информационные технологии. Открытая распределенная обработка. Эталонная модель: обзор.
- ^ Перейти обратно: а б с д Это ж г Эдвард Дж. Баркмейер и др. (2003). Концепции автоматизации системной интеграции NIST 2003.
- ^ Дуглас Т. Росс и К. Э. Шоман-младший «Структурированный анализ определения требований». Транзакции IEEE по разработке программного обеспечения, SE-3 (1), январь 1977 г.
- ^ А. Финкельштейн , Дж. Крамер, Б. Нусейбе, Л. Финкельштейн и М. Гедике. « Точки зрения: основа для интеграции нескольких точек зрения при разработке системы ». Международный журнал программной инженерии и инженерии знаний, 2 (1): 31–58, 1992.
- ^ Перейти обратно: а б с д Это ж г час я дж к Питер Шеймс, Джозеф Скиппер. «На пути к моделированию архитектуры космических систем». Архивировано 27 февраля 2009 г. в Wayback Machine . НАСА, Лаборатория реактивного движения.
- ^ Истербрук, С.; Ю, Э.; Аранда, Дж.; Юньтянь Фан; Хоркофф, Дж.; Лейка, М.; Кадир, РА (2005). «Приводят ли точки зрения к созданию лучших концептуальных моделей? Предварительный практический пример». 13-я Международная конференция IEEE по разработке требований (RE'05) . стр. 199–208. CiteSeerX 10.1.1.78.4594 . дои : 10.1109/RE.2005.23 . ISBN 978-0-7695-2425-2 .
- ^ Синан Си Альхир (2003). « Понимание архитектуры, управляемой моделью (MDA) ». В: Методы и инструменты . Осень 2003 года.
- ^ Совет директоров по информационным технологиям Министерства финансов США (2000). Структура архитектуры казначейского предприятия . Версия 1, июль 2000 г. Архивировано 18 марта 2009 г. в Wayback Machine.
- ^ IEEE-1471-2000
- ^ Джон Крогсти , (2003). Концептуальное моделирование . Архивировано 16 марта 2007 г., в Wayback Machine.
- ^ Мэтью Уэст и Джулиан Фаулер (1999). Разработка моделей данных высокого качества. Архивировано 21 декабря 2008 г. в Wayback Machine . Руководитель технического взаимодействия STEP в европейских перерабатывающих отраслях (EPISTLE).
- ^ ПОДХОД К РАЗДЕЛУ 2 РЕМЕНЬЯ . Проверено 30 сентября 2008 г.
- ^ Джон Ф. Сова (2004). [ «Вызов знаний»]. опубликовано в: Тенденции исследований в области науки, технологий и математического образования . Под редакцией Дж. Рамадаса и С. Чунавалы, Центр Хоми Бхабха, Мумбаи, 2006 г.
- ^ Гад Ариав и Джеймс Клиффорд (1986). Новые направления для систем баз данных: пересмотренные версии статей . Высшая школа делового администрирования Нью-Йоркского университета. Центр исследований информационных систем, 1986.
- ^ itl.nist.gov (1993) Определение интеграции для информационного моделирования (IDEFIX). Архивировано 3 декабря 2013 г. в Wayback Machine . 21 декабря 1993 г.
- ^ Перейти обратно: а б Крухтен, Филипп (1995, ноябрь). Архитектурные чертежи — модель архитектуры программного обеспечения «4+1». Программное обеспечение IEEE 12 (6), стр. 42–50.
- ^ Министерство по делам ветеранов США (2008 г.) Учебное пособие по архитектуре Захмана. Архивировано 13 июля 2007 г. в Wayback Machine . По состоянию на 6 декабря 2008 г.
- ^ Сравнение четырех лучших методологий архитектуры предприятия, заархивировано 9 апреля 2008 г. в Wayback Machine , Роджер Сешнс, Центр сетевой архитектуры разработчиков Microsoft,
- ^ Структура федеральной архитектуры предприятия. Архивировано 16 сентября 2008 г., в Wayback Machine.
- ^ ISO / IEC 10746-1: 1998 Информационные технологии. Открытая распределенная обработка: эталонная модель. Часть 1: обзор, Международная организация по стандартизации, Женева, Швейцария, 1998.
- ^ Перейти обратно: а б DoD (2007) Структура архитектуры DoD, версия 1.5 . 23 апреля 2007 г. Архивировано 11 марта 2005 г. в Wayback Machine.
- ^ Перейти обратно: а б с д Управление управления федеральной программой архитектуры предприятия (2006 г.). Практическое руководство ВЭД [ мертвая ссылка ] .
- ^ Перейти обратно: а б с Питер Шеймс и Джозеф Скиппер (2006). На пути к моделированию архитектуры космических систем. Архивировано 27 мая 2010 г. в Wayback Machine . 25 мая 2006 г.
- Атрибуция
Эта статья включает общедоступные материалы Национального института стандартов и технологий.
Внешние ссылки [ править ]
СМИ, связанные с моделями просмотра, на Викискладе?
