Войти
Матрица видов и перспектив TEAF. A Модель просмотра или точки обзора framework в системная инженерия, программная инженерия и корпоративная инженерия - это структура, которая определяет согласованный набор представлений, который будет использоваться при построении архитектура системы, архитектура программного обеспечения или архитектура предприятия. Представление - это представление всей системы с точки зрения связанного набора проблем.
С начала 1990-х годов был предпринят ряд попыток предписать подходы к описанию и анализу системных архитектур. Эти недавние усилия определяют набор взглядов (или точек зрения). Иногда их называют структурами архитектуры или структурами архитектуры предприятия, но обычно их называют «моделями представления».
Обычно представление - это рабочий продукт, который представляет определенные архитектурные данные для данной системы. Однако этот же термин иногда используется для обозначения определения вида, включая конкретную точку обзора и соответствующее руководство, которое определяет каждое конкретное представление. Термин «модель представления» связан с определениями представлений.
цель взглядов и точек зрения - дать людям возможность понять очень сложные системы, организовать элементы проблемы и решения вокруг областей опыта и разделить проблемы. В проектировании физически интенсивных систем точки зрения часто соответствуют возможностям и обязанностям внутри инженерной организации.
Наиболее сложные системные спецификации настолько обширны, что ни один человек не может полностью понять все аспекты технические характеристики. Более того, у всех нас разные интересы в данной системе и разные причины для изучения спецификаций системы . Руководитель компании задаст другие вопросы о структуре системы, чем разработчик системы. Таким образом, концепция структуры точек зрения заключается в предоставлении отдельных точек зрения на спецификацию данной сложной системы, чтобы облегчить общение с заинтересованными сторонами. Каждая точка зрения удовлетворяет аудиторию с интересом к определенному набору аспектов системы. Каждая точка зрения может использовать определенный язык точки зрения, который оптимизирует словарный запас и представление этой точки зрения для аудитории. Моделирование точек обзора стало эффективным подходом к решению сложностей, присущих большим распределенным системам.
Практики описания архитектуры, как описано в IEEE Std 1471-2000, используют несколько представлений для решения нескольких проблемных областей, каждая из которых фокусируется на конкретном аспекте системы. Примеры архитектурных структур, использующих несколько представлений, включают модель представления "4 + 1" Крюхтена, Zachman Framework, TOGAF, DoDAF и RM-ODP.
В 1970-х годах в разработке программного обеспечения начали появляться методы для моделирования с несколькими представлениями. Дуглас Т. Росс и К.Э. Шоман в 1977 году представил контекст конструкций, точку зрения и точку обзора для организации процесса моделирования при определении требований к системе. Согласно Россу и Шоману, точка зрения «проясняет, какие аспекты считаются важными для достижения... общей цели [модели]» и определяет, как мы смотрим на [моделируемый объект]?
В качестве примеров точек зрения в статье предлагаются: техническая, операционная и экономическая точки зрения. В 1992 году Энтони Финкельштейн и другие опубликовали очень важную статью о точках зрения. В этой работе: «Точка зрения может рассматриваться как комбинация идеи« актера »,« источника знаний »,« роли »или« агента »в процессе разработки и идеи« взгляда »или« перспективы ». «Который утверждает актер». Важная идея в этой статье заключалась в том, чтобы различать «стиль представления, схему и обозначения, с помощью которых точка зрения выражает то, что она может видеть» и «спецификацию, утверждения, выраженные в стиле точки зрения, описывающие определенные области». Последующие работы, такие как IEEE 1471, сохранили это различие за счет использования двух отдельных терминов: точка зрения и точка зрения соответственно.
С начала 1990-х был предпринят ряд попыток систематизировать подходы к описанию и анализу системных архитектур. Их часто называют архитектурными структурами или иногда наборами точек зрения. Многие из них были профинансированы Министерством обороны США, но некоторые возникли в результате международных или национальных усилий по ISO или IEEE. Среди них Рекомендуемая практика IEEE для архитектурного описания программно-интенсивных систем (IEEE Std 1471-2000 ) содержит полезные определения точки зрения, точки зрения, заинтересованных сторон и проблем, а также рекомендации по документированию архитектуры системы за счет использования нескольких точек зрения путем применения точек зрения для решения проблем заинтересованных сторон. Преимущество множественных представлений заключается в том, что скрытые требования и разногласия заинтересованных сторон могут быть легче обнаружены. Однако исследования показывают, что на практике дополнительная сложность согласования нескольких представлений может подорвать это преимущество.
IEEE 1471 (теперь ISO / IEC / IEEE 42010: 2011, Разработка систем и программного обеспечения - Описание архитектуры) предписывает содержание описаний архитектуры и описывает их создание и использование в ряде сценариев, включая предшествующий и беспрецедентный дизайн, эволюционный дизайн и захват проекта существующих систем. Во всех этих сценариях общий процесс один и тот же: выявление заинтересованных сторон, выявление проблем, определение набора точек зрения, которые будут использоваться, а затем применение этих спецификаций точек зрения для разработки набора точек зрения, относящихся к системе интерес. Вместо того, чтобы определять конкретный набор точек зрения, стандарт предоставляет единые механизмы и требования для архитекторов и организаций по определению их собственных точек зрения. В 1996 году была опубликована Эталонная модель ISO для открытой распределенной обработки (RM-ODP ), чтобы предоставить полезную основу для описания архитектуры и проектирования крупномасштабных распределенных систем.
Вид системы - это представление системы с точки зрения точки обзора. Эта точка зрения на систему включает в себя перспективу, фокусирующуюся на конкретных проблемах, связанных с системой, которая скрывает детали, чтобы предоставить упрощенную модель, имеющую только те элементы, которые связаны с проблемами точки обзора. Например, точка зрения безопасности фокусируется на проблемах безопасности, а модель точки зрения безопасности содержит те элементы, которые связаны с безопасностью из более общей модели системы.
A view позволяет пользователю изучить часть, представляющую особый интерес площадь. Например, информационное представление может представлять все функции, организации, технологии и т. Д., Которые используют определенную часть информации, в то время как организационное представление может представлять все функции, технологии и информацию, представляющую интерес для конкретной организации. В Zachman Framework представления включают группу рабочих продуктов, разработка которых требует определенных аналитических и технических знаний, поскольку они сосредоточены либо на «что», «как», «кто», «где», «когда»., »Или« почему »предприятия. Например, рабочие продукты Functional View отвечают на вопрос «как выполняется миссия?» Их легче всего разработать специалистам по функциональной декомпозиции с использованием моделирования процессов и действий. Они показывают предприятие с точки зрения функций. Они также могут отображать организационные и информационные компоненты, но только тогда, когда они относятся к функциям.
В системном проектировании точка зрения - это разделение или ограничение проблем в системе. Принятие точки зрения полезно, так что вопросы в этих аспектах можно решать отдельно. Хороший выбор точек обзора также разделяет дизайн системы на определенные области знаний.
Точки обзора предоставляют соглашения, правила и языки для построения, представления и анализа представлений. В ISO / IEC 42010: 2007 (IEEE-Std-1471-2000 ) точка обзора - это спецификация для отдельного обзора. Вид - это представление всей системы с точки зрения точки зрения. Вид может состоять из одной или нескольких архитектурных моделей. Каждая такая архитектурная модель разрабатывается с использованием методов, установленных для соответствующей архитектурной системы, а также для системы в целом.
Перспективы моделирования - это набор различных способов представления предварительно выбранных аспектов системы. Каждая перспектива имеет разную направленность, концептуализацию, приверженность и визуализацию того, что представляет модель.
В информационных системах традиционный способ разделения перспектив моделирования заключается в разделении структурных, функциональных и поведенческих / процессуальных перспектив. Это вместе с перспективами правил, объектов, коммуникаций и субъектов и ролей является одним из способов классификации подходов к моделированию
С любой данной точки зрения можно создать модель системы, которая содержит только те объекты, которые видны с этой точки обзора, но также фиксирует все объекты, отношения и ограничения, которые присутствуют в системе и относятся к этой точке обзора. Такая модель называется моделью точки зрения или представлением системы с этой точки зрения.
Данное представление представляет собой спецификацию системы на определенном уровне абстракции с данной точки зрения. Различные уровни абстракции содержат разные уровни детализации. Представления более высокого уровня позволяют инженеру формировать и понимать всю конструкцию, а также выявлять и решать проблемы в целом. Представления нижнего уровня позволяют инженеру сконцентрироваться на части проекта и разработать подробные спецификации.
Иллюстрация представлений, продуктов и данных в архитектуре Framework. Однако в самой системе все спецификации появляющиеся в различных моделях точек зрения должны быть рассмотрены в реализованных компонентах системы. И спецификации для любого данного компонента могут быть составлены с разных точек зрения. С другой стороны, спецификации, вызванные распределением функций по конкретным компонентам и взаимодействиям компонентов, обычно отражают иное разделение проблем, чем то, которое отражено в исходных точках зрения. Таким образом, могут быть полезны дополнительные точки зрения, касающиеся проблем отдельных компонентов и восходящего синтеза системы.
Описание архитектуры представление архитектуры системы в любое время с точки зрения ее составных частей, того, как эти части функционируют, правил и ограничений, в соответствии с которыми эти части функционируют, и как эти части связаны друг с другом и с окружающей средой. В описании архитектуры данные об архитектуре разделяются между несколькими представлениями и продуктами.
На уровне данных находятся элементы данных архитектуры и их определяющие атрибуты и отношения. На уровне представления находятся продукты и представления, которые поддерживают визуальные средства связи и понимания цели архитектуры, того, что она описывает, и различных выполненных архитектурных анализов. Продукты предоставляют способ визуализации данных архитектуры в виде графического, табличного или текстового представления. Представления предоставляют возможность визуализировать данные об архитектуре, относящиеся к продуктам, логически упорядочивая данные для конкретной или целостной перспективы архитектуры.
Понятие модели с тремя схемами было впервые введено в 1977 г. на трехуровневой модели ANSI / X3 / SPARC. архитектура, которая определила три уровня для моделирования данных. Подход с тремя схемами для моделирования данных, представленный в 1977 году, можно считать одной из первых моделей представления. Это подход к построению информационных систем и системного управления информацией, который продвигает концептуальную модель как ключ к достижению интеграции данных. Подход с использованием трех схем определяет три схемы и представления:
В центре концептуальная схема определяет онтологию из концептов, поскольку пользователи думают о них и говорят о них. Физическая схема описывает внутренние форматы данных , хранящихся в базе данных, а внешняя схема определяет представление данных, представленных в прикладных программах. Фреймворк попытался разрешить использование нескольких моделей данных для внешних схем.
С годами навыки и интерес к созданию информационных систем значительно выросли. Однако по большей части традиционный подход к построению систем сосредоточен только на определении данных из двух различных представлений, «пользовательского представления» и «компьютерного представления». С точки зрения пользователя, которую мы будем называть «внешней схемой», определение данных происходит в контексте отчетов и экранов, предназначенных для помощи людям в выполнении их конкретных задач. Требуемая структура данных из представления использования изменяется в зависимости от бизнес-среды и индивидуальных предпочтений пользователя. С компьютерной точки зрения, которую мы будем называть «внутренней схемой», данные определяются в терминах файловых структур для хранения и поиска. Требуемая структура данных для компьютерного хранилища зависит от конкретной используемой компьютерной технологии и потребности в эффективной обработке данных.
Иллюстрация 4 + 1 модель или архитектура представления. 4 + 1 - модель представления, разработанная Филиппом Крухтеном в 1995 году для описания архитектуры программно-интенсивных систем на основе использование нескольких одновременных просмотров. Представления используются для описания системы с точки зрения различных заинтересованных сторон, таких как конечные пользователи, разработчики и менеджеры проектов. Четыре представления модели - это логическое, развитие, процесс и физическое представление:
Четыре представления модели связаны с:
Кроме того, для иллюстрации архитектуры используются выбранные варианты использования или сценарии. Следовательно, модель содержит представления 4 + 1.
Структура архитектуры предприятия определяет, как организовать структуру и представления, связанные с архитектурой предприятия. Поскольку дисциплина Enterprise Architecture and Engineering очень широка, а предприятия могут быть большими и сложными, модели, связанные с этой дисциплиной, также имеют тенденцию быть большими и сложными. Чтобы управлять этим масштабом и сложностью, Архитектура Framework предоставляет инструменты и методы, которые могут сосредоточить задачу и позволить создавать ценные артефакты, когда они больше всего нужны.
Архитектурные основы обычно используются в информационных технологиях и управлении информационными системами. Организация может потребовать, чтобы определенные модели были произведены до утверждения проекта системы . Точно так же они могут пожелать указать определенные представления, которые будут использоваться в документации закупаемых систем - США. Министерство обороны требует, чтобы поставщики оборудования предоставляли конкретные обзоры DoDAF для капитальных проектов стоимостью выше определенной.
Упрощенная иллюстрация Zachman Framework с пояснением строк. Исходная структура является более продвинутой, см. Пример здесь.Zachman Framework, первоначально задуманная Джоном Закманом в IBM в 1987 году, представляет собой структуру для архитектуры предприятия., который обеспечивает формальный и хорошо структурированный способ просмотра и определения предприятия.
Framework используется для организации архитектурных «артефактов» таким образом, чтобы принимать во внимание как цель артефакта (например, владелец бизнеса и строитель), так и конкретная проблема (например, данные и функциональность). адресуется. Эти артефакты могут включать проектную документацию, спецификации и модели.
Фреймворк Захмана часто упоминается как стандартный подход для выражения основных элементов архитектуры предприятия. Структура Захмана была признана Федеральным правительством США как «... получившая всемирное признание как интегрированная структура для управления изменениями на предприятиях и в системах, которые их поддерживают».
Модель представления RM-ODP, которая обеспечивает пять общих и дополнительных точек зрения на систему и ее среду. Эталонная модель Международной организации по стандартизации (ISO) для открытой распределенной обработки (RM- ODP ) определяет набор точек зрения для разделения проекта распределенной программно-аппаратной системы. Поскольку большинство проблем интеграции возникает при разработке таких систем или в очень аналогичных ситуациях, эти точки зрения могут оказаться полезными при разделении проблем интеграции. Точки зрения RMODP:
RMODP дополнительно определяет требование к проекту, чтобы он содержал спецификации согласованности между точками зрения, в том числе:
Структура архитектуры Министерства обороны (DoDAF) определяет стандартный способ организации архитектуры предприятия (EA) или архитектуры системы в дополнительных и согласованных представлениях. Он особенно подходит для больших систем со сложными проблемами интеграции и взаимодействия и, по-видимому, уникален тем, что использует «операционных представлений », детализирующих операционную область внешнего заказчика, в которой будет работать разрабатываемая система.
DoDAF связи между представлениями. DoDAF определяет набор продуктов, которые действуют как механизмы для визуализации, понимания и усвоения широкого объема и сложности описания архитектуры с помощью графических, табличных или текстовых средств. Эти продукты разделены на четыре вида:
Каждое представление отображает определенные перспективы архитектуры, как описано ниже. Для каждой разработки системы обычно создается только подмножество полного набора представлений DoDAF. На рисунке представлена информация, которая связывает рабочее представление, представление систем и служб и представление технических стандартов. Три представления и их взаимосвязь, управляемая элементами данных общей архитектуры, обеспечивают основу для получения таких показателей, как функциональная совместимость или производительность, и для измерения влияния значений этих показателей на операционную миссию и эффективность задач.
В США архитектура федерального предприятия архитектура предприятия, сегмента и решения обеспечивает разные бизнес-перспективы, варьируя уровень детализации и решая связанные, но разные проблемы. Подобно тому, как предприятия сами по себе иерархически организованы, каждый тип архитектуры обеспечивает различные представления. Практическое руководство по архитектуре федерального предприятия (2006 г.) определяет три типа архитектуры:
архитектура федерального предприятия, уровни и атрибуты, По определению, Архитектура предприятия (EA) в основном занимается выявлением общих или совместно используемых активов - будь то стратегии, бизнес-процессы, инвестиции, данные, системы или технологии. Советник руководствуется стратегией; он помогает агентству определить, соответствуют ли его ресурсы миссии и стратегическим целям и задачам агентства. С инвестиционной точки зрения EA используется для принятия решений об инвестиционном портфеле ИТ в целом. Следовательно, основными заинтересованными сторонами EA являются старшие менеджеры и руководители, которым поручено обеспечить максимально эффективное и действенное выполнение агентством своей миссии.
Напротив, сегментная архитектура определяет простую дорожную карту для основной области миссии, бизнес-сервис или корпоративный сервис. Сегментная архитектура определяется управлением бизнесом и предоставляет продукты, улучшающие предоставление услуг гражданам и персоналу агентства. С точки зрения инвестиций, сегментная архитектура определяет решения для бизнес-кейса или группы бизнес-кейсов, поддерживающих основную область миссии или общую или разделяемую услугу. Основными заинтересованными сторонами архитектуры сегмента являются владельцы и менеджеры бизнеса. Архитектура сегмента связана с EA тремя принципами: структура, повторное использование и согласование. Во-первых, архитектура сегмента наследует структуру, используемую EA, хотя она может быть расширена и специализирована для удовлетворения конкретных потребностей основной области миссии или общей или совместно используемой службы. Во-вторых, архитектура сегмента повторно использует важные активы, определенные на уровне предприятия, включая: данные; общие бизнес-процессы и инвестиции; и приложения и технологии. В-третьих, архитектура сегмента согласуется с элементами, определенными на уровне предприятия, такими как бизнес-стратегии, требования, стандарты и показатели производительности.
В поисках "основы для моделирования пространства" Системные архитектуры "Питер Шеймс и Джозеф Скиппер (2006) определили" номинальный набор представлений ", полученный из CCSDS RASDS, RM-ODP, ISO 10746 и соответствующий IEEE 1471.
Иллюстрация" Номинального набора представлений " ". Этот" набор видов ", как описано ниже, представляет собой список возможных точек обзора моделирования. Не все из этих представлений могут использоваться для какого-либо одного проекта, при необходимости могут быть определены другие представления. Обратите внимание, что для некоторых анализов элементы из нескольких точек обзора могут быть объединены в новое представление, возможно, с использованием многоуровневого представления.
В последнем представлении этот номинальный набор представлений был представлен как Расширенное производное семантической информационной модели RASDS. Таким образом, RASDS означает эталонную архитектуру для систем космических данных. см. второе изображение.
Эталонная архитектура для систем космических данных. 
Онтология верхнего уровня MBED, основанная на номинальном наборе представлений. В отличие от предыдущих перечисленных моделей представлений, этот "номинальный набор представлений" перечисляет целый ряд представлений, позволяющий разработать мощные и расширяемые подходы для описания общего класса программно-интенсивных системных архитектур.
Эта статья включает материалы, являющиеся общественным достоянием с веб-сайта Национального института стандартов и технологий https://www.nist.gov.
СМИ, связанные с Просмотреть модели на Wikimedia Commons