Какие типы связей отношений допускаются между экторами

Типы отношений на диаграмме прецедентов

Для построения диаграммы прецедентов могут быть использованы следующие типы отношений:

· ассоциации (association),

· обобщения (generalization),

· расширения (extend),

· включения (include).

Рассмотрим некоторые отношения. Отношение ассоциации устанавливает, какую конкретную роль играет актёр в системе, определяет спецификацию актёра. Отношение ассоциации может иметь дополнительные характеристики: кратность (multiplicity) и имя. Этот вид отношений изображается прямой линией и может быть использован между прецедентами, между актерами, между прецедентом и актёром (рис. 2.1).

Актёры могут наследовать свойства друг друга. Для изображения связи наследования между родительским и дочерним прецедентом используют отношение обобщения (рис. 2.2). На диаграммах UML отношение обобщение изображается прямой линией с не закрашенным треугольником, указывающим на родителя. Постоянный клиент авиакомпании наследует все свойства Клиента авиакомпании и может иметь свои собственные, например, пользоваться скидкой при покупке билета. Отношение обобщения также может быть использовано для отображения связи наследования между прецедентами (рис. 2.3).

Рис. 2.2. Пример отношения обобщения между двумя актёрами на диаграмме прецедентов.

Рис. 2.3. Пример отношения обобщения между двумя прецедентами на диаграмме прецедентов.

Для группировки элементов UML используют пакеты. Пакеты позволяют структурировать и систематизировать информационную составляющую модели, повысить ее наглядность.

Вопросы:

1. Какой актёр является абстрактным?

2. Какие из приведенных выше отношений могут быть использованы для связи между прецедентами, между актёрами, между атером и прецедентом? Приведите примеры.

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

4. Какие могут быть использованы типы отношений между интерфейсом и прецедентом на диаграмме прецедентов. Приведите примеры.

5. Что показывает кратность отношения ассоциации?

Воспользуйтесь поиском по сайту:

studopedia.org — Студопедия.Орг — 2014-2023 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.006 с) .

Четыре Типа Отношений В Диаграмме Вариантов Использования

• В UML отношения — это связи между элементами модели. Варианты использования также связаны друг с другом в различных отношениях. Отношения между двумя вариантами использования в основном моделируют зависимости между двумя вариантами использования. Благодаря повторному использованию существующих вариантов использования с использованием различных типов отношений общие усилия, необходимые для разработки системы, сокращаются. На диаграммах вариантов использования показаны варианты использования, действующие лица и отношения между ними. Например, связь между субъектом и вариантом использования показывает, что субъект может использовать определенные функции бизнес-системы. Отношения ассоциацииАссоциация — это связь между двумя классификаторами, такими как действующее лицо и варианты использования, которая описывает причину связи и управляющие ею правила. Ассоциация — это отношение между субъектом и бизнес-вариантом использования. Это указывает на то, что субъект может использовать функциональные возможности бизнес-системы.

Отношения обобщения

Отношение обобщения — это отношение, в котором один элемент модели (дочерний) основан на другом элементе модели (родительском). Отношения обобщения используются в диаграммах классов, диаграммах компонентов, диаграммах развертывания и диаграммах вариантов использования, чтобы указать, что дочерний элемент принимает все атрибуты, операции и отношения, определенные в родительском элементе.

Включить отношения

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

Расширение отношений

В моделировании UML можно использовать отношение расширения , чтобы указать, что один вариант использования (расширение) расширяет поведение другого варианта использования (базового). Этот тип связи раскрывает сведения о системе или приложении, которые обычно скрыты в варианте использования. Дополнительные примеры использования Диаграмма вариантов использования системы вещания ИЗМЕНИТЬ ЭТУ ДИАГРАММУ Пример схемы вариантов использования банкомата ИЗМЕНИТЬ ЭТУ ДИАГРАММУ Диаграмма варианта использования: несколько проектов с системными границами ИЗМЕНИТЬ ЭТУ ДИАГРАММУ Диаграмма вариантов использования: система онлайн-экзаменов ИЗМЕНИТЬ ЭТУ ДИАГРАММУ Пример диаграммы варианта использования: обслуживание пассажиров ИЗМЕНИТЬ ЭТУ ДИАГРАММУ Пример диаграммы варианта использования: разработка программного обеспечения ИЗМЕНИТЬ ЭТУ ДИАГРАММУ Пример диаграммы варианта использования: система парковки ИЗМЕНИТЬ ЭТУ ДИАГРАММУ Диаграмма вариантов использования UML: система обработки заказов ИЗМЕНИТЬ ЭТУ ДИАГРАММУ Включить и расширить диаграмму вариантов использования ИЗМЕНИТЬ ЭТУ ДИАГРАММУ Пример диаграммы варианта использования: веб-сайт (расширить и включить вариант использования) ИЗМЕНИТЬ ЭТУ ДИАГРАММУ Пример диаграммы прецедентов: внешняя система в качестве действующего лица ИЗМЕНИТЬ ЭТУ ДИАГРАММУ Пример диаграммы варианта использования: банкомат банка ИЗМЕНИТЬ ЭТУ ДИАГРАММУ Пример диаграммы варианта использования: аэропорт ИЗМЕНИТЬ ЭТУ ДИАГРАММУ

4.1 Актер в прецедентах UML, Отношения между прецедентами и актерами кратко

Привет, сегодня поговорим про отношения между прецедентами и актерами, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое отношения между прецедентами и актерами , настоятельно рекомендую прочитать все из категории Технологии компьютерного проектирования. Связи и взаимоотношения, существующие между элементами модели, в UML описываются с помощью отношений, изображаемых на диаграммах. Отношение (relationship) — это семантическая связь между отдельными элементами модели. Между актерами и прецедентами диаграммы вариантов использования могут существовать разного рода отношения, показывающие, что экземпляры действующих лиц и вариантов использования взаимодействуют друг с другом. Действующие лица могут взаимодействовать с несколькими прецедентами и между собой, равно как и прецеденты могут быть связаны между собой особого типа отношениями. При этом актером (актером) / актором (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В основном на диаграммах прецедентов используются следующие типы отношений:

• ассоциации (association relationship);
• включения (include relationship);
• расширения (extend relationship);
• обобщения (generalization relationship).

Ассоциация – это структурное отношение, показывающее, что объект неким образом связан с другим объектом.

Отношение этого типа используется не только на диаграммах прецедентов, но и на других диаграммах. Если между элементами модели показано отношение ассоциации, то это означает, что между ними существует семантическая связь. Ассоциативное отношение может быть направленным. Об этом говорит сайт https://intellect.icu . В этом случае направление связи показывает, кто является инициатором. Если отношение направленно от актера к прецеденту, то это означает, что актер инициирует выполнение прецедента.

Пример. Покупатель в системе заказов магазина «Style» инициирует выполнение прецедента Заказ товаров (см. рис. 10).

Рисунок 10. Отношение ассоциации между актером и прецедентом

Между прецедентами также возможны взаимоотношения, которые описываются отношениями двух типов: включения и расширения (дополнения).

Включение (include) говорит о том, что исходный прецедент явным образом включает в себя поведение целевого .

Другими словами, включение создается, когда один прецедент использует другой. При этом исполнение базового прецедента невозможно без исполнения используемого. Изображается включение в виде пунктирной стрелки с надписью <>, которая направлена от базового элемента к используемому.

Пример. В системе заказов магазина «Style» невозможен заказ товаров без оплаты. На диаграмме прецедентов это можно отразить так, как это показано на рисунке 11.

Рисунок 12. Отношение расширения между прецедентами

Обозначения отношений <> и <> есть не что иное, как обозначения стереотипов, которые широко используются в UML для создания новых элементов модели путем расширения функциональности базовых элементов.

Стереотип (Stereotype) – это механизм, позволяющий категоризировать элементы модели.

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

В UML мы можем создавать собственные стереотипы на основе уже имеющихся типов, но также существуют и стандартные, заранее определенные стереотипы нотации UML. Так, отношение зависимости (о котором мы еще будем говорить) расширяется для прецедентов и актеров с помощью двух стереотипов <> и <>.

Ассоциация – это коммуникативное отношение, которое соответствует стереотипу <>, который, впрочем, всегда опускается.

Два и более актера могут иметь общие свойства, т.е. взаимодействовать с одним и тем же множеством вариантов использования одинаковым образом. Такая общность свойств и поведения представляется в виде отношения обобщения с другим, возможно, абстрактным актером, который моделирует соответствующую общность ролей.

Обобщение (Generalization) – это отношение между общей сущностью и ее конкретным воплощением .

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

Пример. Для изменения статуса заказов в магазине «Style» с проектируемой системой будут работать сотрудник отдела продаж и кладовщик. На диаграмме мы можем показать с помощью отношения обобщения взаимосвязь между актером Сотрудник и актерами Сотрудник отдела продаж и Кладовщик (рис. 13).

Рисунок 13. Отношение обобщения между актерами

Актеры, прецеденты и отношения – это основные элементы нотации диаграмм вариантов использования. Диаграмма вариантов использования помогает отобразить основные требования к моделируемой системе и обеспечить взаимопонимание функциональности системы между разработчиком и заказчиком. Можно построить одну, главную диаграмму прецедентов, на которой будут отражены границы системы (актеры) и ее основная функциональность (прецеденты). Для более подробного представления системы допускается построение вспомогательных диаграмм прецедентов.

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

Из статьи мы узнали кратко, но содержательно про отношения между прецедентами и актерами

ArchiMate

ArchiMate — язык архитектурного описания корпоративных и инженерных систем (моделирования архитектуры предприятия). ArchiMate предназначен для высокоуровневого моделирования и анализа различных областей предприятия и взаимосвязей между ними. Он не фокусируется на деталях реализации и не заменяет UML, BPMN или ERD, а дополняет их. В Archimate меньше возможностей по детализации, чем в этих языках моделирования, но он позволяет связать описания различных областей и разработать интегрированное представление организации.

Архимейт предлагает следующие механизмы:

1. Механизм типов подразумевает задание главным образом одного простого вопроса, чтобы подобрать тип Архимейта. Ответ на этот вопрос может оказаться очень нетривиальным, а получение этого ответа заставит задать десятки других вопросов.
2. Предписанное именование. Если у вас практика — то это отглагольное существительное, например, «полевой инжиниринг». Процессы — это глагол (например «инжинирить в поле»).
3. Формализм: следование диаграмм логическим правилам. Формальное можно проверить на непротиворечивость, а потом сравнить результат с жизнью: если в жизни обнаруживается противоречие там, где его нет на диаграмме, то нужно искать причины этого противоречия.

Основные понятия

• Enterprise architecture — архитектура предприятия.
• Domain — предметная область, которой занимается предприятие.
• Aspect — аспект (исполнители, работа, объекты).

Уровни ArchiMate

Архимейт имеет три уровня работ, на каждом из которых уменьшается человеческое начало:

1. Уровень деятельности (business) содержательный. Люди за информацией видят те объекты окружающего мира, которые эта информация изображает. У людей есть цели, полномочия и ответственность. Целенаправленная деятельность есть только на этом уровне.
2. Уровень программного обеспечения (application) — это обработка информации, заключенной в данных. Из одних данных программы делают другие данные, отличающиеся как форматом, так и содержанием. Никто никому ничего не обещает и не даёт поручений, не преследует никаких целей. Главная задача уровня — чтобы нужным способом обработанные данные оказались в нужный момент у нужных людей.
3. Уровень аппаратного обеспечения (technology) — мир, в котором никакой обработки данных уже нет, а есть только хранение и пересылка данных. Конечно, на уровне оборудования тоже есть программы, но они уже другого рода — тут уже никто не знает, что означают эти данные в реальном мире. Задача уровня — хранить адресуемые как-то байты, не вдаваясь в их смысл, пересылать эти байты по запросам программ, а также хранить сами программы и давать им возможность выполняться.

Архимейт ценен тем, что предлагает для описания работы предприятия ограниченное количество типов элементов каждого уровня, а также типов отношений между элементами.

Типы элементов

Для изменения архитектуры предприятия в реальной жизни также есть:

• 7 типов элементов для целеполагания и обоснования изменений в организации,
• 4 типа элементов для проектирования перехода к новой архитектуре.

Типы элементов уровня деятельности

1. Business actor — ответственный. В Архимейте это элемент оргструктуры: от одного человека до всей толпы холдинга, включая подразделения, клиентов и прочих человеков группами и поодиночке. Не путать с конкретным человеком или группой людей (архитектура «в типах», в ней нет конкретных объектов): это именно место в оргструктуре. Именуется существительным.
2. Business role — роль. Тип намеренно промежуточный между «работами» и «выполнителями», правильно понимать как temporal part of actor (временнУю часть ответственного) во время занятий ответственного какой-то работой. Один ответственный может быть назначен на несколько ролей и несколько ответственных могут играть какую-то роль, но только одна роль может быть назначена какой-то работе
3. Business collaboration — коллегиальная роль. Имя существительное, ибо роль (не ловитесь на «коллаборацию»!). Типовые примеры — коллективные «совещание», «заседание», «комиссия», «рабочая группа» и т.д..
4. Business interface — канал взаимодействия (имеется ввиду то самое «окошко», из «концепции одного окошка» — место, где доступны сервисы деятельности. Прилавок, веб-форма на сайте, колл-центр и т.д.). Имя существительное.
5. Business object — объект (деятельности, business — это ведь «дело», «деловой»). Подробнее см. http://ailev.livejournal.com/955954.html
6. Business process — процесс (в том числе одна операция). Я бы опускал слово «деятельности», ибо других операций/процессов в Архимейте нет, а с application function мы выкрутились «функционалом» (программы). Имя — глагол в неопределенной форме, чтобы лучше понималась кооперативная (последовательная) цепочка операций, каждая из которых выполняется какой-то ролью людей: «процесс получить страховой полис — включает операции получить запрос, обработать заявку, принять платёж».
7. Business function — практика. Это группировка (потенциальных) работ по иным признакам, нежели «результат: как входы преобразуются в выходы»: по предметной области, общности используемых ресурсов, общности регулирования и т.д.. Имя — отглагольное существительное (в отличие от процесса/операций, где даются глаголы в их последовательности). Обратите внимание, что практика — это потенциальная работа, «обычно выполняемые работы», поэтому «организационная функция = департамент» к ней неприменимо. С другой стороны, практиками могут быть выполняемые департаментом (людьми) в разных его ролях работы. Практика вполне может включать в себя какие-то операции из их цепочек, рассортированные по критериям попадания в эту практику. Наоборот уже не так: практики не укладываются в связанные отношениями запуска (trigger) цепочки операций/процессы — наряду с «ролью» они промежуточные между «работами» и «выполнителями» единицы. Это особо оговорено в http://www.opengroup.org/archimate/doc/ts_archimate/chap3.html — running somewhat ahead of the later conceptual discussions, (business) functions and (business) roles serve as intermediary concepts between “purely behavioral” concepts and “purely structural” concepts. Тем не менее, Архимейт таки обращается с ними как с работами, и позволит показать и последовательность практикования, и предачу информации из практики в практику.
8. Business interaction — коллегиальный процесс. Имя — глагол. Обычно используется для разных работ (мероприятий, дел), выполняемых коллективом деятелей: «совещаться», «провести переговоры», «принять решение комиссии». На выполнение коллегиального процесса назначается коллегиальная роль: так, «рабочая группа» назначается на «принять решение о выпуске».
9. Business event — событие. Слово «деятельностное» опускаем, других не бывает. Это точка во времени, событиями обычно начинается и заканчивается цепочка процессов. Имя должно включать глагол совершенного вида прошедшего времени: «заявка получена», «проект сдан».
10. Business service — оргсервис. Имя — отглагольное существительное. Никаких «услуги» или «служба», это очень специфическое понятие, это видимые «извне» работы (при этом учитываем, что в Архимейте это «извне» не определяется, но активно используется — системный подход есть, но понятия системы и явной границы системы нет). Орг — потому как есть и другие сервисы, «софта» и «железа», и этот нужно отличать.
11. Representation — рабочий продукт, ибо объект это альфа — буквально из OMG Essence. Имя существительное.
12. Meaning — значение, смысл.
13. Value — внешняя польза (внешняя! хотя допускается и внутренняя, это оговорено как «редко»). Определяется для сервиса или продукта (продукт в Архимейте — это набор сервисов и контракт!). Свободные текстовые выражения, включая суммы экономии, доступность предметов и т.д.. Если польза функциональна, то рекомендуется описывать состояния или действия, которые сможет осуществить клиент, если он воспользуется данным сервисом (сервис «сервис наливания кофе» ассоциирован с пользой «немедленное и длительное счастье клиента, как это показывают в телерекламе любого кофе»).
14. Product — оргсервис-продукт. Думать прежде всего о «банковском продукте», «страховом продукте» и прочих нефизических не-объектах, сводящихся к работам для клиента. Продукт в Архимейте — это набор сервисов и привязанный к ним контракт (обычно — SLA, service-level agreement: соглашение об уровне сервиса, предусматривающие жесткие санкции за недоступность сервиса). Сервисы в продукте — это доступное по запросу по каналу взаимодействия или интерфейсу предоставление работы — выполнение внутренних процессов и практик. Имя продукта — традиционное для общения с пользователями или клиентами (внутренними и внешними).
15. Contract — соглашение об уровне сервиса. Соглашение SLA, договор, контракт. Имя — существительное.

Типы элементов уровня программного обеспечения

1. Application component — программа. Имя — существительное. «Учет», «начисление» (выполнитель учёта, выполнитель начисления). Не компонента, а модуль!
2. Application collaboration — связка программ (аналог коллегиальной роли из уровня людей). Имя — существительное. Ведет себя так же, как программная компонента, только назначается на функционал связки программ или кооперативные процессы.
3. Application interface — программный интерфейс. Обычно именуется по тем данным, что через этот интерфейс проходят (существительное), например «обмен данными транзакции». Программные компоненты (буквально: отношение состава) из их интерфейсов, на эти интерфейсы назначаются сервисы (а программы назначаются на их функционалы). Очень часто интерфейс понимается как «канал передачи с его протоколом» (http), часто также это «место предоставления сервиса» (электронная почта, экранные формы).
4. Data object — данные (и так понятно, что «объект», чтобы еще и с объектом деятельности людей не путать, когда будут сокращать до «объект»).
5. Application function — программный функционал. Отглагольные существительные — «ведение учета», «начисление».
6. Application interaction — функционал связки программ. На него назначается связка программ. Имя, ( в отличие от «отглагольносуществительных» функционалов) — глагол.
7. Application service — программный сервис. Отглагольное существительное, часто содержит слово «сервис». «Сервис ведения учёта», «сервис начисления».

Типы элементов уровня аппаратного обеспечения

1. Node — «железо». «Рабочие места», «сервера приложений», «сервера баз данных» и т.д. Внутри «железа» — устройства и системный софт, поддерживающий работу с информобъектами. Имя существительное.
2. Device — устройство. Существительное, ссылающееся на тип устройства: «большой экран», «рэк-сервер», «IBM мейнфрейм серии Z».
3. Infrastructure interface — интерфейс «железа». Существительное. Не хочется умножать число сущностей: «инфраструктура» ведь бывает разной, а не только айтишной. Кроме того, я сознательно уменьшаю предмет (scope) IT до «железа», сетей связи и системного софта. Ибо есть хоть какая-то надежда, что программами будут заниматься не только «чистые айтишники», но и какие-то разбирающиеся в предмете деятельности (domain) люди.
4. Network — сеть. Поскольку физическая сеть, то именуется обычно своими характеристиками (1гигабит Ethernet).
5. Communication path — логический канал связи. Физически связь реализуется сетью, поэтому именуется по функции, которая по каналу идёт: «постановка сообщений в очередь».
6. Infrastructure service — сервис «железа». Отглагольное существительное, часто включающее слово «сервис» — «сервис бэкапирование пользовательских файлов».
7. System software — системный софт. Намеренно сленгово, чтобы максимально далеко от уровня людей и работы с предметной областью, это чистое перемалывание байтов без вникания в их смысл. Вотчина сисадминов. Существительное, ссылающееся на тип: «JBOSS сервер», «Oracle 11».
8. Artifact — информобъект.

Типы отношений

1. Aggregation — объединение.
2. Assignment — назначение.
3. Realization — реализация (воплощение).
4. Used by — использование.
5. Access — доступ.
6. Association — связь.
7. Triggering — запуск.
8. Flow — передача (чаще всего информации, но в версии 2.0 и влияния). «Поток» в русском для дискретных объектов обычно трудно воспринимаем, см. второй абзац http://ailev.livejournal.com/413837.html.
9. Grouping — группировка.
10. Junction — развилка.
11. Specialization — специализация.
12. Derived relationships — производные отношения.

Применение

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

• для банков и страховых компаний;
• штаб-квартир (из которых реальных цехов не видно);
• проектных бюро (где тяжёлые балки есть только в компьютерных моделях и бумажных распечатках);
• штабов строек (где занимаются раздачей поручений и учётом сделанного, но сами руками ничего не делают).

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

Ссылки

• Описание стандарта
• Свободный моделер
• Лучшая книжка
• Архимейт по-русски: метод описания информационной структуры
• Русский перевод терминологии