Модель представления или структура точек зрения в системной инженерии , разработке программного обеспечения и проектировании предприятия — это структура, которая определяет последовательный набор представлений , которые будут использоваться при построении архитектуры системы , архитектуры программного обеспечения или архитектуры предприятия . Представление — это представление всей системы с точки зрения связанного набора задач. [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 — это модель представления, разработанная Филиппом Крухтеном в 1995 году для описания архитектуры программно-интенсивных систем, основанная на использовании нескольких параллельных представлений. [17] Представления используются для описания системы с точки зрения различных заинтересованных сторон, таких как конечные пользователи, разработчики и менеджеры проектов. Четыре представления модели: логическое представление, представление развития, процесс и физическое представление:
Четыре представления модели касаются:
Кроме того, для иллюстрации архитектуры используются выбранные варианты использования или сценарии. Следовательно, модель содержит 4+1 представление. [17]
Структура архитектуры предприятия определяет, как организовать структуру и представления, связанные с архитектурой предприятия . Поскольку дисциплина «Архитектура и проектирование предприятия» настолько широка, а предприятия могут быть большими и сложными, модели, связанные с этой дисциплиной, также имеют тенденцию быть большими и сложными. Чтобы управлять таким масштабом и сложностью, архитектурная платформа предоставляет инструменты и методы, которые могут сфокусировать задачу и позволить создавать ценные артефакты, когда они больше всего необходимы.
Архитектурные рамки обычно используются в информационных технологиях и управлении информационными системами . Организация может пожелать потребовать, чтобы определенные модели были созданы до утверждения проекта системы . Аналогичным образом, они могут пожелать указать, что определенные представления будут использоваться в документации по закупаемым системам — Министерство обороны США требует, чтобы конкретные представления DoDAF предоставлялись поставщиками оборудования для капитального проекта, превышающего определенную стоимость.
Zachman Framework , первоначально задуманная Джоном Захманом из IBM в 1987 году, представляет собой основу для архитектуры предприятия, которая обеспечивает формальный и высокоструктурированный способ просмотра и определения предприятия.
Платформа используется для организации архитектурных «артефактов» таким образом, чтобы учитывать как то, на кого нацелен артефакт (например, владелец бизнеса и строитель), так и какая конкретная проблема (например, данные и функциональность) решается. Эти артефакты могут включать проектную документацию, спецификации и модели. [19]
На Zachman Framework часто ссылаются как на стандартный подход для выражения основных элементов архитектуры предприятия . Концепция Захмана была признана федеральным правительством США как «…полученная во всем мире как интегрированная основа для управления изменениями на предприятиях и в системах, которые их поддерживают». [20]
Эталонная модель открытой распределенной обработки ( RM-ODP ) Международной организации по стандартизации (ISO) [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]
Эта статья включает общедоступные материалы Национального института стандартов и технологий.
СМИ, связанные с моделями просмотра, на Викискладе?