Отображение между 4 + 1 моделью архитектурного вида и UML

Я немного озадачен тем, как модель архитектурного представления 4 + 1 отображается в UML.

Википедия дает следующее отображение:

• Логическое представление: диаграмма классов, диаграмма связи, диаграмма последовательности.
• Вид разработки: Диаграмма компонентов, Диаграмма пакетов
• Представление процесса: Диаграмма действий
• Физический вид: диаграмма развертывания
• Сценарии: диаграмма варианта использования

В статье « Роль конструкций диаграмм последовательности UML в концепции жизненного цикла объекта» приведено следующее сопоставление:

• Логическое представление (диаграмма классов (CD), диаграмма объектов (OD), диаграмма последовательности (SD), диаграмма сотрудничества (COD), диаграмма диаграммы состояний (SCD), диаграмма активности (AD))
• Вид разработки (схема пакета, схема компонента),
• Представление процесса (диаграмма вариантов использования, CD, OD, SD, COD, SCD, AD),
• Физический вид (схема развертывания) и
• Вид использования (диаграмма вариантов использования, OD, SD, COD, SCD, AD), которая объединяет четыре упомянутых выше.

На веб-странице UML 4 + 1 View Materials представлено следующее отображение:

Наконец, в документе « Применение архитектуры представления 4 + 1 с UML 2» приводится еще одно сопоставление:

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

Я уверен, что дальнейший поиск покажет и другие сопоставления.

Хотя у разных людей разные взгляды, я не понимаю, почему это так. В частности, каждая диаграмма UML описывает систему с определенного аспекта. Так, например, почему «диаграмма последовательности» рассматривается как описание «логического представления» системы одним автором, а другой автор рассматривает ее как описание «представления процесса»?

Не могли бы вы помочь мне прояснить путаницу?

Хотя я в целом согласен с ответом Барта ван Ингена Шенау , я думаю, что некоторые моменты требуют дополнительной проработки.

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

Модель представления программного обеспечения 4 + 1 была описана в статье Филиппа Крухтена « Архитектурные чертежи - Модель представления программного обеспечения 4 + 1», которая была первоначально опубликована в программном обеспечении IEEE (ноябрь 1995 г.). Эта публикация не содержит конкретных ссылок на UML. Фактически, статья использует нотацию Буча для логического представления, расширения нотации Буча для представления процесса и представления разработки, призывает использовать «несколько форм» разработки физического представления и новую нотацию для сценариев.

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

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

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

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

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

Наконец, сценарии помогают собрать требования, чтобы все заинтересованные стороны понимали, как система предназначена для использования.

Как только вы поймете, что должно обеспечивать каждое представление, вы можете выбрать, какие нотации моделирования использовать и на каком уровне детализации требуется. Последний абзац Барта особенно верен - вы можете показать различные уровни детализации в ваших моделях UML, сосредоточившись на определенных элементах дизайна или комбинируя различные типы диаграмм в наборе. Кроме того, вы можете рассмотреть возможность перехода от UML к другим нотациям моделирования, чтобы лучше описать архитектуру вашей системы - SysML , Entity-Relation моделирование или IDEF .

Причина, по которой вы не можете найти однозначное соответствие между представлениями архитектурной модели 4 + 1 и различными диаграммами UML, заключается в том, что такого отображения не существует.

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

Кроме того, некоторые UML-диаграммы можно использовать по-разному, выделяя различные элементы на диаграмме, что делает их полезными для нескольких представлений. Но даже если один тип диаграммы UML можно использовать в нескольких представлениях, вы должны нарисовать разные диаграммы (или набор диаграмм) для каждого представления.

Хотя я согласен с подходом Томаса Оуэнса к ответам, чтобы удовлетворить потребности ваших конечных пользователей, одна вещь, которая не была упомянута, заключается в том, что причина, по которой первоначальное определение «4 + 1 View Model Architecture» Крухтена не дает Конкретные ссылки на UML объясняются тем, что статья была написана в 1995 году (как говорится в ответе), но UML не был принят в качестве стандарта до 1997 года .

Непрерывное использование обозначения Booch в статье предполагает, что целесообразно связывать каждое из представлений моделей с определенной диаграммой UML, поскольку Грэди Боуч был одним из тех, кто участвовал в разработке UML.

Именно из-за этого так много разных авторов считают, что разные UML-диаграммы применимы к каждому представлению, так как множественные UML-диаграммы могут рассматриваться в некотором количестве «абстракций» Носителей Буча, на которые опирается исходное определение модели 4 + 1. представлять каждый вид.

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

Вы все еще используете видеомагнитофон, который купили в 1995 году? 4 + 1 было применимо еще тогда, когда программное обеспечение находилось в зачаточном состоянии. Но даже тогда никто никогда не использовал более 2 или 3 «представлений». За последние 20 лет разработка программного обеспечения изменилась. В настоящее время объем / контекст и концептуальные, и логические, и физические, и ... все дифференцированы. Многие COTS-решения должны быть интегрированы и так далее. Сегодня мы говорим о ландшафтных картах, реализации сервисов и десятках других видов и точек зрения. Лучший способ взглянуть на это через простую структуру таксономии, такую ​​как Zachman: 6 представлений и 6 представлений. Пусть это будет вашей отправной точкой. 6 представлений: контекстуальная концептуальная или бизнес логическая или системная физическая или технологическая поставка или артефакты функционирующего предприятия

6 точек зрения: данные, или какая функция, или как сеть, или где люди, или кто, когда, или мотивация, или почему.

Давайте посмотрим пример. Если нас интересуют только данные, мы начнем с представления области и скажем: «Наша область действия - CRM». В концептуальном представлении данных мы предложим некоторую семантическую модель для CRM. Модель будет концептуальной, бизнес-информации, а не объектов данных. Далее в логическом представлении мы создадим логическую модель данных из нашей концептуальной модели CRM. Мы можем использовать методологию ER для создания логической модели данных. Затем в физическом представлении мы создадим физическую модель данных. Здесь мы определим конкретные типы данных для выбранной нами платформы db, индексов и т. Д. Наконец, в представлении доставки у нас будет наш сценарий DDL, в то время как в работающем корпоративном представлении у нас будет двоичный файл, развернутый на каком-либо сервере базы данных. и сопоставлены с внутренними структурами данных поставщика DBM. Мы повторяем это для каждой точки зрения или столбца. Кроме того, если есть более одного заинтересованного лица, мы создадим более одной модели для каждой комбинации точка обзора / вид. Теперь, когда у вас есть эта таксономия, вы можете определить свои собственные точки зрения и представления и согласовать их с этой таксономией. Например, для инициатив на уровне предприятия важны следующие точки зрения: взаимодействие между субъектом, поведение приложения, взаимодействие приложения, структура приложения, использование бизнес-функции, бизнес-процесс, бизнес-процесс, взаимодействие, внедрение и развертывание, информационная структура, инфраструктура, инфраструктура, инфраструктура, обзор ландшафта, многоуровневая реализация организационных услуг и т. Д. Теперь, когда у вас есть эта таксономия, вы можете определить свои собственные точки зрения и представления и согласовать их с этой таксономией. Например, для инициатив на уровне предприятия важны следующие точки зрения: взаимодействие между субъектом, поведение приложения, взаимодействие приложения, структура приложения, использование бизнес-функции, бизнес-процесс, бизнес-процесс, взаимодействие, внедрение и развертывание, информационная структура, инфраструктура, инфраструктура, инфраструктура, обзор ландшафта, многоуровневая реализация организационных услуг и т. Д. Теперь, когда у вас есть эта таксономия, вы можете определить свои собственные точки зрения и представления и согласовать их с этой таксономией. Например, для инициатив на уровне предприятия важны следующие точки зрения: взаимодействие между субъектом, поведение приложения, взаимодействие приложения, структура приложения, использование бизнес-функции, бизнес-процесс, бизнес-процесс, взаимодействие, внедрение и развертывание, информационная структура, инфраструктура, инфраструктура, инфраструктура, обзор ландшафта, многоуровневая реализация организационных услуг и т. Д.

Крутчен 4 + 1 не может удовлетворить все эти потребности