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

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. Отношение обобщения между актерами

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

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

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

34. Понятие эктора и отношения между экторами

Что ж, у нас есть пример диаграммы. Итак, какие же элементы мы на ней видим? Первое, что бросается в глаза, — большой прямоугольник, внутри которого размещаются эллипсы, обозначающие, как мы уже поняли, прецеденты. В верхней части прямоугольника указано название моделируемой системы, а называют его рамками системы (system boundary, subject boundary), контекстом или просто системой. Этот элемент диаграммы показывает границу между тем, что вы как аналитик показали в виде прецедентов (внутри этих рамок), и тем, что вы изобразили как действующие лица (вне их). Чаще всего таким прямоугольником показывают границы самой моделируемой системы. То есть внутри границы находятся прецеденты — тот функционал, который реализует система (и в этом смысле прецеденты могут рассматриваться как представления подсистем и классов модели), а снаружи — действующие лица: пользователи и другие внешние сущности, взаимодействующие с моделируемой системой.

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

Кроме рамок системы или ее контекста на диаграмме мы видим еще два вида связанных с ней сущностей — это действующие лица (экторы, actors) и прецеденты. Начнем с экторов. Довольно часто в русскоязычной литературе по UML для обозначения действующих лиц можно встретить термин «актер». В принципе, смысл его более-менее понятен и оригинальному английскому термину он созвучен. Более того, есть еще одна причина такого перевода. Какое слово первым приходит к вам в голову, когда вы слышите слово «актер»? Да, конечно же — слово «роль»! Именно о ролях мы вскоре и поговорим, когда будем пытаться разобраться, что скрывается за понятием «действующее лицо». А пока, да простит нас читатель, далее мы все же будем пользоваться словом «эктор» — транскрипцией оригинального термина. Помнится, мы уже как-то писали о нашем отношении к буквальному переводу терминологии.

Итак, какой же смысл вкладывают в понятие эктора? Эктор — это набор ролей, которые исполняет пользователь в ходе взаимодействия с некоторой сущностью (системой, подсистемой, классом). Эктор может быть человеком, другой системой, подсистемой или классом, которые представляют нечто за пределами рассматриваемой сущности. Экторы «общаются» с системой путем обмена сообщениями. Четко выделив экторов, вы тем самым ясно определяете границу между тем, что внутри системы, и тем, что снаружи, — рамки системы.

Возможно, слова «роли, исполняемые пользователем» в определении эктора звучат не очень понятно. Очень забавно это понятие объясняется в Zicom Mentor:

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

Действительно, наденьте шляпу пирата — и вы капитан Джек Воробей, а наденьте цилиндр и вы — Джек-потрошитель! Шутка. «Физический» пользователь может играть роль одного или даже нескольких экторов, выполняя их функции в ходе взаимодействия с системой. И наоборот, роль одного и того же эктора может выполняться несколькими пользователями.

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

Несмотря на «человеческий» вид этого обозначения, не следует забывать, что экторы — это не обязательно люди. Эктором, как мы уже говорили ранее, может быть внешняя система, подсистема, класс и т. д. Кстати, человечек («stick-person») — это не единственное обозначение эктора, используемое в UML. На диаграммах прецедентов обычно применяется именно «человекоподобная» форма эктора, но на других диаграммах, и особенно в случаях, когда эктор имеет атрибуты, которые важно показать, используется изображение эктора как класса со стереотипом > (рис. 6.5):

С системой экторы, как мы уже сказали, общаются через сообщения, но если говорить на более высоком уровне абстракции, в терминах модели прецедентов, то взаимодействуют они с системой через прецеденты. Один и тот же эктор может быть связан с несколькими прецедентами, и наоборот, один прецедент может быть связан с несколькими разными экторами. Ассоциации между эктором и прецедентом всегда бинарные — т. е. представляют отношения типа «один к одному», использование кратности недопустимо. Это не противоречит сказанному выше: действительно, один эктор может быть связан с несколькими прецедентами, но только с помощью отдельных ассоциаций — по одной на каждый прецедент. Мы видели это в нашем примере. Кстати, там мы видели ассоциации, изображенные не просто в виде линий, а стрелками. Думаем, смысл этого обозначения вполне понятен: это направленная ассоциация и стрелка (как и на других диаграммах) всегда направлена в сторону той сущности, от которой что-то требуют, чьим сервисом пользуются и т. д.

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

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

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

В этом примере пассажир может купить в сервисной кассе билет на некоторый вид транспорта. Покупка билета — это название сценария, по которому эктор (пассажир) может взаимодействовать с системой (кассой). Заметьте, это не описание сценария, а именно название — оно говорит нам, что делает эктор в процессе взаимодействия, но не говорит, как именно! И еще — прецеденты определяют непересекающиеся сценарии поведения. Выполнение одного прецедента не может быть прервано в результате работы другого прецедента. Другими словами, выполнение одного прецедента не может быть прервано в результате событий или действий, вызванных выполнением другого прецедента. Прецеденты выступают как атомарные транзакции, выполнение которых не может быть прервано.

Внимательный читатель, возможно, отметил то, как незаметно мы ввели в употребление слово «сценарий«. Что же такое сценарий и как понятие сценария связано с понятием прецедента? На первый вопрос хорошо отвечают классики (Г. Буч):

Сценарий — это конкретная последовательность действий, иллюстрирующая поведение.

Сценарий — это повествовательный рассказ о совершаемых эктором действиях, история, эпизод, происходящий в данных временных рамках и данном контексте взаимодействия. Сценарии (в различных формах представления) широко применяются в процессе разработки программного обеспечения. Как мы уже только что отметили, написание сценария напоминает написание художественного рассказа, и этим объясняется тот факт, что использование сценариев широко распространено среди аналитиков, которые часто обладают художественными или литературными способностями. Несмотря на непрерывный повествовательный характер, сценарии можно рассматривать как последовательности действий (делать раскадровку). При разработке пользовательского интерфейса сценарии описывают взаимодействие между пользователем (или категорией пользователей, например, администраторами системы, конечными пользователями) и системой. Такой сценарий состоит из последовательного описания комбинаций отдельных действий и задач (например, нажатий клавиш, щелчков по элементам управления, ввода данных в соответствующие поля и т. д.). Вспомните, к примеру, описания последовательностей действий пользователя (предназначенных для достижения определенных результатов, решения определенных задач), которые вы находите в справке к малознакомой программе. То же самое можно сказать о модных сейчас «how-to videos», в которых такие последовательности отображаются визуально, на конкретных примерах. В любом случае, цель подобных справочных материалов — предоставить описание типичных сценариев использования системы, сценариев взаимодействия между пользователем и системой.

Сценарии также иногда можно увидеть на диаграмме прецедентов. Иногда их изображают в виде «листа бумаги», на котором написано имя файла, — прямоугольника с загнутым нижним левым уголком. В этом случае указанный файл содержит в себе описание данного сценария. А иногда сценарий записывается в комментарий. Как вы, наверное, помните, комментарии (ноутсы, notes) изображаются прямоугольниками с загнутым верхним правым углом и соединяются с элементом, который они поясняют, пунктирной линией (рис. 6.7).

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

Вот пример простого (неформализованного) текстового описания сценария.

Пользователь вводит логин, пароль, адрес электронной почты и код подтверждения и нажимает кнопку «Далее». Система запрашивает ввод проверочного кода. Пользователь вводит код и нажимает кнопку «Далее». Система проверяет соответствие кода изображенному на картинке.

Не правда ли, знакомая процедура? Да, это описание регистрации пользователя на некотором сайте. Правда, не совсем полное: не рассмотрены случаи, когда выбранный пользователем логин уже занят, адрес электронной почты введен неправильно, пароль не удовлетворяет требованиям или код не соответствует изображенному на картинке. О таких случаях — альтернативных сценариях — мы поговорим чуть позже.

А вот тот же сценарий в табличном представлении:

Действия пользователя

Реакция системы

Ввод логина, пароля, адреса электронной почты и нажатие кнопки «Далее»

Запрос ввода проверочного кода

Ввод проверочного кода и нажатие кнопки «Далее»

Проверка кода на соответствие изображенному на картинке

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

А пока попробуем ответить на второй вопрос, а именно: как связаны понятия сценария и прецедента. Прецеденты, как мы уже говорили, рождаются из требований к системе. Но говорят они о том, что делает система. Как система это делает, говорят сценарии. Таким образом, прецедент можно специфицировать путем описания потока действий или событий в текстовой форме — в виде, понятном для «постороннего» (не занятого в непосредственной разработке системы) читателя. А ведь такое описание — это и есть сценарий! Таким образом, сценарии специфицируют прецеденты. И еще. Поскольку сценарии — это, по сути, рассказы, они являются весьма эффективным средством извлечения информации из бесед с заказчиком и предоставляют превосходное, понятное непрофессионалу описание создаваемого приложения. Сценарии, да и вообще диаграммы прецедентов (дополненные сценариями) являются отличным средством общения между разработчиками и заказчиком, причем, в силу простоты нотации, — средством, понятным обеим сторонам. В конечном итоге, взаимосвязь между требованиями, прецедентами и сценариями можно изобразить такой «псевдодиаграммой» (рис. 6.8).

• Как видите, для каждой ассоциации на диаграмме проставлена кратность и ее смысл вполне понятен, но все же о кратности следует поговорить отдельно. Один прецедент определяет несколько сценариев, каждый из которых представляет один из возможных вариантов определяемого прецедентом потока событий. Сценарии так же соотносятся с прецедентами, как экземпляры класса, т.е. сценарий — это экземпляр прецедента, как объект — экземпляр класса. Система может содержать, например, несколько десятков прецедентов, каждый из которых, в свою очередь, может разворачиваться в десятки сценариев. Как правило, прецедент описывает не одну последовательность действий, а множество, и выразить все детали рассматриваемого прецедента с помощью одной последовательности действий обычно не получается. Практически для любого прецедента можно выделить основной сценарий, описывающий «нормальную» последовательность действия, и вспомогательные, описывающие альтернативные последовательности, которые инициируются в случае возникновения определенных условий.

Please verify you are a human

Access to this page has been denied because we believe you are using automation tools to browse the website.

This may happen as a result of the following:

• Javascript is disabled or blocked by an extension (ad blockers for example)
• Your browser does not support cookies

Please make sure that Javascript and cookies are enabled on your browser and that you are not blocking them from loading.

Reference ID: #5a0ed139-ae58-11ee-9ba4-fa9985c8e370

Powered by PerimeterX , Inc.

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 — производные отношения.

Применение

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

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

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

Ссылки

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