Модель представления или структура точек зрения в системной инженерии , программной инженерии и корпоративной инженерии — это структура, которая определяет согласованный набор представлений , используемых при построении архитектуры системы , архитектуры программного обеспечения или корпоративной архитектуры . Представление — это представление всей системы с точки зрения связанного набора интересов. [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]
Представление позволяет пользователю изучать часть определенной области интересов. Например, информационное представление может представлять все функции, организации, технологии и т. д., которые используют определенную часть информации, в то время как организационное представление может представлять все функции, технологии и информацию, представляющие интерес для определенной организации. В структуре Захмана представления включают группу рабочих продуктов, разработка которых требует определенной аналитической и технической экспертизы, поскольку они фокусируются либо на «что», «как», «кто», «где», «когда» или «почему» предприятия. Например, рабочие продукты функционального представления отвечают на вопрос «как выполняется миссия?». Их легче всего разрабатывать экспертам по функциональной декомпозиции с использованием моделирования процессов и деятельности. Они показывают предприятие с точки зрения функций. Они также могут показывать организационные и информационные компоненты, но только в том виде, в котором они связаны с функциями. [9]
В системной инженерии точка зрения — это разделение или ограничение проблем в системе. Принятие точки зрения может быть использовано для того, чтобы проблемы в этих аспектах могли рассматриваться отдельно. Хороший выбор точек зрения также разделяет проект системы на конкретные области знаний. [3]
Точки зрения предоставляют соглашения, правила и языки для построения, представления и анализа представлений. В ISO/IEC 42010:2007 ( IEEE-Std-1471-2000 ) точка зрения — это спецификация для отдельного представления. Представление — это представление всей системы с точки зрения точки зрения. Представление может состоять из одной или нескольких архитектурных моделей . [10] Каждая такая архитектурная модель разрабатывается с использованием методов, установленных связанной с ней архитектурной системой, а также для системы в целом. [6]
Перспективы моделирования — это набор различных способов представления предварительно выбранных аспектов системы. Каждая перспектива имеет разный фокус, концептуализацию, посвящение и визуализацию того, что представляет модель .
В информационных системах традиционный способ разделения перспектив моделирования заключается в различении структурных, функциональных и поведенческих/процессуальных перспектив. Это вместе с перспективами правил, объектов, коммуникаций, а также актеров и ролей является одним из способов классификации подходов к моделированию [11]
В любой заданной точке зрения можно создать модель системы, которая содержит только объекты, видимые с этой точки зрения, но также охватывает все объекты, отношения и ограничения, которые присутствуют в системе и имеют отношение к этой точке зрения. Такая модель называется моделью точки зрения или видом системы с этой точки зрения. [3]
Заданное представление — это спецификация для системы на определенном уровне абстракции с заданной точки зрения. Различные уровни абстракции содержат различные уровни детализации. Представления более высокого уровня позволяют инженеру формировать и понимать весь проект, а также выявлять и решать проблемы в целом. Представления более низкого уровня позволяют инженеру сосредоточиться на части проекта и разрабатывать подробные спецификации. [3]
Однако в самой системе все спецификации, появляющиеся в различных моделях точек зрения, должны быть рассмотрены в реализованных компонентах системы. И спецификации для любого данного компонента могут быть получены с многих различных точек зрения. С другой стороны, спецификации, вызванные распределением функций по конкретным компонентам и взаимодействиями компонентов, как правило, будут отражать иное разделение интересов, чем то, которое отражено в исходных точках зрения. Таким образом, дополнительные точки зрения, рассматривающие интересы отдельных компонентов и синтез системы снизу вверх, также могут быть полезны. [3]
Описание архитектуры — это представление архитектуры системы в любой момент времени с точки зрения ее составных частей, того, как эти части функционируют, правил и ограничений, при которых эти части функционируют, и того, как эти части соотносятся друг с другом и с окружающей средой. В описании архитектуры данные архитектуры совместно используются несколькими представлениями и продуктами.
На уровне данных находятся элементы данных архитектуры и их определяющие атрибуты и отношения. На уровне представления находятся продукты и представления, которые поддерживают визуальные средства для общения и понимания цели архитектуры, того, что она описывает, и различных выполненных архитектурных анализов. Продукты предоставляют способ визуализации данных архитектуры в виде графических, табличных или текстовых представлений. Представления предоставляют возможность визуализировать данные архитектуры, которые вытекают из продуктов, логически организуя данные для определенной или целостной перспективы архитектуры.
Подход Three-schema для моделирования данных, представленный в 1977 году, можно считать одной из первых моделей представлений. Это подход к построению информационных систем и управлению системной информацией, который продвигает концептуальную модель как ключ к достижению интеграции данных . [13] Подход Three-schema определяет три схемы и представления:
В центре концептуальная схема определяет онтологию концепций , как пользователи думают о них и говорят о них. Физическая схема описывает внутренние форматы данных, хранящихся в базе данных , а внешняя схема определяет вид данных, представленных прикладным программам . [14] Фреймворк пытался разрешить использование нескольких моделей данных для внешних схем. [ 15]
За эти годы мастерство и интерес к построению информационных систем значительно выросли. Однако, по большей части, традиционный подход к построению систем был сосредоточен только на определении данных из двух различных представлений: «представление пользователя» и «представление компьютера». С точки зрения пользователя, которая будет называться «внешняя схема», определение данных находится в контексте отчетов и экранов, разработанных для помощи людям в выполнении их конкретной работы. Требуемая структура данных из представления использования меняется в зависимости от бизнес-среды и индивидуальных предпочтений пользователя. С точки зрения компьютера, которая будет называться «внутренняя схема», данные определяются в терминах файловых структур для хранения и извлечения. Требуемая структура данных для компьютерного хранения зависит от конкретной используемой компьютерной технологии и необходимости эффективной обработки данных. [16]
4+1 — это модель представления, разработанная Филиппом Крухтеном в 1995 году для описания архитектуры систем с большим количеством программного обеспечения, основанная на использовании нескольких параллельных представлений. [17] Представления используются для описания системы с точки зрения различных заинтересованных сторон, таких как конечные пользователи, разработчики и менеджеры проектов. Четыре представления модели — логическое, разработки, процесса и физическое:
Четыре представления модели касаются:
Кроме того, выбранные варианты использования или сценарии используются для иллюстрации архитектуры. Таким образом, модель содержит 4+1 представления. [17]
Структура архитектуры предприятия определяет, как организовать структуру и представления, связанные с архитектурой предприятия . Поскольку дисциплина архитектуры и проектирования предприятий настолько широка, а предприятия могут быть большими и сложными, модели, связанные с этой дисциплиной, также, как правило, большие и сложные. Чтобы управлять этим масштабом и сложностью, структура архитектуры предоставляет инструменты и методы, которые могут сфокусировать задачу и позволить создавать ценные артефакты, когда они больше всего нужны.
Архитектурные структуры обычно используются в информационных технологиях и управлении информационными системами . Организация может пожелать, чтобы определенные модели были созданы до утверждения проекта системы . Аналогичным образом, они могут пожелать указать определенные представления, которые будут использоваться в документации закупаемых систем - Министерство обороны США требует, чтобы поставщики оборудования предоставляли определенные представления DoDAF для капитальных проектов выше определенной стоимости.
Структура Захмана , первоначально разработанная Джоном Захманом в IBM в 1987 году, представляет собой структуру для корпоративной архитектуры, которая обеспечивает формальный и высокоструктурированный способ рассмотрения и определения предприятия.
Framework используется для организации архитектурных «артефактов» таким образом, чтобы учитывать как то, на кого нацелен артефакт (например, владелец бизнеса и строитель), так и то, какая конкретная проблема (например, данные и функциональность) решается. Эти артефакты могут включать проектные документы, спецификации и модели. [19]
Структура Захмана часто упоминается как стандартный подход для выражения основных элементов архитектуры предприятия . Структура Захмана была признана федеральным правительством США как «... получившая всемирное признание в качестве интегрированной структуры для управления изменениями на предприятиях и системах, которые их поддерживают». [20]
Справочная модель Международной организации по стандартизации (ISO) для открытой распределенной обработки ( RM-ODP ) [21] определяет набор точек зрения для разделения дизайна распределенной программно-аппаратной системы. Поскольку большинство проблем интеграции возникает при проектировании таких систем или в очень похожих ситуациях, эти точки зрения могут оказаться полезными для разделения проблем интеграции. Точки зрения RMODP следующие: [3]
RMODP дополнительно определяет требование к проекту, чтобы он содержал спецификации согласованности между точками зрения, включая: [3]
Архитектурная структура Министерства обороны ( DoDAF) определяет стандартный способ организации архитектуры предприятия (EA) или архитектуры систем в виде дополнительных и согласованных представлений. Она особенно подходит для больших систем со сложными проблемами интеграции и взаимодействия и, по-видимому, уникальна в использовании « операционных представлений », детализирующих операционную область внешнего клиента, в которой будет работать разрабатываемая система.
DoDAF определяет набор продуктов, которые действуют как механизмы для визуализации, понимания и усвоения широкого охвата и сложности описания архитектуры посредством графических, табличных или текстовых средств. Эти продукты организованы в четырех представлениях:
Каждое представление отображает определенные перспективы архитектуры, как описано ниже. Обычно для каждой разработки системы создается только подмножество полного представления 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]
В статье использованы материалы, являющиеся общественным достоянием Национального института стандартов и технологий.
Медиа, связанные с Просмотр моделей на Wikimedia Commons