Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Архимейт по-русски: словарик

UPDATE 31 июля 2015 -- внесены правки в соответствии с версией русификации 1.1 (http://ailev.livejournal.com/1205591.html).

Тут я собрал словарик для основных типов элементов Архимейта. Упор я делал на понимание не столько айтишниками (им понятнее всего были бы транслитерации), сколько деятелями (инженерами, клерками, менеджерами). Мои принципы перевода-понятизации я когда-то изложил в http://ailev.livejournal.com/631742.html, а пример использования этой технологии (обкатанный потом на многих организациях) -- http://ailev.livejournal.com/567097.html.

Предполагается, что пользователь этого словарика уже прочёл всю англоязычную документацию, тексты "Архимейт по-русски: метод описания информационной структуры" (http://ailev.livejournal.com/955954.html) и пример архитектурной диаграммы из http://ailev.livejournal.com/956191.html -- он уже помнит графические обозначения, но затрудняется с разговором по-русски про application function, когда беседа идёт не с друзьями-айтишниками. Тут-то и пригодится словарик. Словарик -- мэппинг одного языка на другой (соотнесение терминов двух языков). Глоссарий -- это содержащий толкования, а у меня тут толкований нет -- разве кое-где не удержался.

0. ArchiMate -- Архимейт

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

Domain -- предметная область, которой занимается предприятие.

Aspect -- аспект (выполнители, работа, объекты)


1. Business layer -- уровень деятельности (инженерная, финансовая, исследовательская и т.д. деятельность)
[было "уровень людей"]

Business actor -- ответственный. В Архимейте это элемент оргструктуры: от одного человека до всей толпы холдинга, включая подразделения, клиентов и прочих человеков группами и поодиночке. Не путать с конкретным человеком или группой людей (архитектура "в типах", в ней нет конкретных объектов): это именно место в оргструктуре. Именуется существительным. [было "люди"]

Business role -- роль. Тип намеренно промежуточный между "работами" и "выполнителями", правильно понимать как temporal part of actor (временнУю часть ответственного) во время занятий ответственного какой-то работой. Один ответственный может быть назначен на несколько ролей и несколько ответственных могут играть какую-то роль, но только одна роль может быть назначена какой-то работе [было "роль людей в работах"]

Business collaboration -- коллегиальная роль. Имя существительное, ибо роль (не ловитесь на "коллаборацию"!). Типовые примеры -- коллективные "совещание", "заседание", "комиссия", "рабочая группа" и т.д..

Business interface -- канал взаимодействия (имеется ввиду то самое "окошко", из "концепции одного окошка" -- место, где доступны сервисы деятельности. Прилавок, веб-форма на сайте, колл-центр и т.д.). Имя существительное.

Business object -- объект (деятельности, business -- это ведь "дело", "деловой"). Подробнее см. http://ailev.livejournal.com/955954.html

Business process -- процесс (в том числе одна операция). Я бы опускал слово "деятельности", ибо других операций/процессов в Архимейте нет, а с application function мы выкрутились "функционалом" (программы). Имя -- глагол в неопределенной форме, чтобы лучше понималась кооперативная (последовательная) цепочка операций, каждая из которых выполняется какой-то ролью людей: "процесс получить страховой полис -- включает операции получить запрос, обработать заявку, принять платёж".

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. Тем не менее, Архимейт таки обращается с ними как с работами, и позволит показать и последовательность практикования, и предачу информации из практики в практику.

Business interaction -- коллегиальный процесс. Имя -- глагол. Обычно используется для разных работ (мероприятий, дел), выполняемых коллективом деятелей: "совещаться", "провести переговоры", "принять решение комиссии". На выполнение коллегиального процесса назначается коллегиальная роль: так, "рабочая группа" назначается на "принять решение о выпуске".

Business event -- событие. Слово "деятельностное" опускаем, других не бывает. Это точка во времени, событиями обычно начинается и заканчивается цепочка процессов. Имя должно включать глагол совершенного вида прошедшего времени: "заявка получена", "проект сдан".

Business service -- оргсервис. Имя -- отглагольное существительное. Никаких "услуги" или "служба", это очень специфическое понятие, это видимые "извне" работы (при этом учитываем, что в Архимейте это "извне" не определяется, но активно используется -- системный подход есть, но понятия системы и явной границы системы нет). Орг -- потому как есть и другие сервисы, "софта" и "железа", и этот нужно отличать.

Representation -- рабочий продукт, ибо объект это альфа -- буквально из OMG Express. Имя существительное. [было "представление". Подробнее см. в http://ailev.livejournal.com/955954.html]

Meaning -- значение. (хотя я до сих пор сомневаюсь, не лучше ли тут передать как "смысл" -- авторы поминают тут DEMO, ситуацию и прагматику. Значит -- смысл, но авторы Архимейта нещадно путают значение и смысл, так что непонятно). Подробнее -- http://ailev.livejournal.com/955954.html

Value -- внешняя польза (внешняя! хотя допускается и внутренняя, это оговорено как "редко"). Определяется для сервиса или продукта (продукт в Архимейте -- это набор сервисов и контракт!). Свободные текстовые выражения, включая суммы экономии, доступность предметов и т.д.. Если польза функциональна, то рекомендуется описывать состояния или действия, которые сможет осуществить клиент, если он воспользуется данным сервисом (сервис "сервис наливания кофе" ассоциирован с пользой "немедленное и длительное счастье клиента, как это показывают в телерекламе любого кофе"). [слово "внешнее" было опущено]

Product -- оргсервис-продукт. Думать прежде всего о "банковском продукте", "страховом продукте" и прочих нефизических не-объектах, сводящихся к работам для клиента. Продукт в Архимейте -- это набор сервисов и привязанный к ним контракт (обычно -- SLA, service-level agreement: соглашение об уровне сервиса, предусматривающие жесткие санкции за недоступность сервиса). Сервисы в продукте -- это доступное по запросу по каналу взаимодействия или интерфейсу предоставление работы -- выполнение внутренних процессов и практик. Имя продукта -- традиционное для общения с пользователями или клиентами (внутренними и внешними). [было "продукт", и все путали с "объектом" -- тут же работы, сервис]

Contract -- соглашение об уровне сервиса. Соглашение SLA, договор, контракт. Имя -- существительное. [было "контракт"]


2. Application layer -- уровень "софта"

Application component -- программа. Имя -- существительное. "Учет", "начисление" (выполнитель учёта, выполнитель начисления). [было "программная компонента", но имеется ввиду именно модуль!]

Application collaboration -- связка программ (аналог коллегиальной роли из уровня людей). Имя -- существительное. Ведет себя так же, как программная компонента, только назначается на функционал связки программ или кооперативные процессы.

Application interface -- программный интерфейс. Обычно именуется по тем данным, что через этот интерфейс проходят (существительное), например "обмен данными транзакции". Программные компоненты (буквально: отношение состава) из их интерфейсов, на эти интерфейсы назначаются сервисы (а программы назначаются на их функционалы). Очень часто интерфейс понимается как "канал передачи с его протоколом" (http), часто также это "место предоставления сервиса" (электронная почта, экранные формы). [было интерфейс программы]

Data object -- данные (и так понятно, что "объект", чтобы еще и с объектом деятельности людей не путать, когда будут сокращать до "объект").

Application function -- программный функционал. Отглагольные существительные -- "ведение учета", "начисление".

Application interaction -- функционал связки программ. На него назначается связка программ. Имя, ( в отличие от "отглагольносуществительных" функционалов) -- глагол.

Application service -- программный сервис. Отглагольное существительное, часто содержит слово "сервис". "Сервис ведения учёта", "сервис начисления". [было "сервис программ"]


3. Technology layer -- уровень "железа"
[было "уровень оборудования" -- нещадно путали с машиностроительным оборудованием]

Node -- "железо". "Рабочие места", "сервера приложений", "сервера баз данных" и т.д. Внутри "железа" -- устройства и системный софт, поддерживающий работу с информобъектами. Имя существительное.

Device -- устройство. Существительное, ссылающееся на тип устройства: "большой экран", "рэк-сервер", "IBM мейнфрейм серии Z".

Infrastructure interface -- интерфейс "железа". Существительное. Не хочется умножать число сущностей: "инфраструктура" ведь бывает разной, а не только айтишной. Кроме того, я сознательно уменьшаю предмет (scope) IT до "железа", сетей связи и системного софта. Ибо есть хоть какая-то надежда, что программами будут заниматься не только "чистые айтишники", но и какие-то разбирающиеся в предмете деятельности (domain) люди. [было "интерфейс оборудования"]

Network -- сеть. Поскольку физическая сеть, то именуется обычно своими характеристиками (1гигабит Ethernet).

Communication path -- логический канал связи. Физически связь реализуется сетью, поэтому именуется по функции, которая по каналу идёт: "постановка сообщений в очередь".

Infrastructure service -- сервис "железа". Отглагольное существительное, часто включающее слово "сервис" -- "сервис бэкапирование пользовательских файлов". [было "сервис оборудования"]

System software -- системный софт. Намеренно сленгово, чтобы максимально далеко от уровня людей и работы с предметной областью, это чистое перемалывание байтов без вникания в их смысл. Вотчина сисадминов. Существительное, ссылающееся на тип: "JBOSS сервер", "Oracle 11".

Artifact -- информобъект. Подробнее -- http://ailev.livejournal.com/955954.html


4. Relationships -- отношения

Aggregation -- объединение.

Assignment -- назначение.

Realization -- реализация (воплощение).

Used by -- использование.

Access -- доступ.

Association -- связь.

Triggering -- запуск.

Flow -- передача (чаще всего информации, но в версии 2.0 и влияния). "Поток" в русском для дискретных объектов обычно трудно воспринимаем, см. второй абзац http://ailev.livejournal.com/413837.html.

Grouping -- группировка.

Junction -- развилка.

Specialization -- специализация.

Derived relationships -- производные отношения.
* * *
UPDATED для новой версии русскоязычной терминологии -- http://ailev.livejournal.com/988360.html (и там ссылки на остальные тексты "Архимейт по-русски").
UPDATED для версии 1.1 -- http://ailev.livejournal.com/1205591.html
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 30 comments
бизнес деятель = делец.
Вы еще найдите "бизнес-деятеля" в моделируемых организациях :-)
думаю, что все, у кого есть свои интересы, кроме тех, что моделируются, могут считаться business actor.
Анатолий, не могу найти трёх определений. Вы их пропустили.
Я конечно могу сам перевести, но сомневаюсь что правельно по смыслу.

Business Activity - Бизнес деятельность?
Application Interface – интерфейс данных?
Composition Relation – состав отношения?

Поправте, пожалуйста.
Business activity -- такого в спецификации нет (хотя и было в Архимейте давным-давно, пока не отдали в OMG на стандартизацию). Поэтому и переводить не нужно. Хотя мы переводим business как "деятельностный" (определение для пассивной и активной структур), а activity как "деятельность" (поведение) -- то есть "деятельностная деятельность", масло масляное. Так что хорошо, что не встречается :-) Вообще-то общий родовой термин, который мы используем для процессов, практик и всего деятельностного поведения (в том числе проектов и т.д.) -- "работа".

Application interface в постинге есть.

Composition relation -- отношение композиции (я тут бы не заморачивался с переводом -- это будет "составной части", в отличие от "совокупности" для aggregation. Но по-русски всё одно можно по-разному протрактовать, поэтому я бы оставил транслитерации для обоих отношний).
Анатолий, Вы меня удивляете.
Как же нет Business activity? Вот оно в последней 2 версии.
Я что-то пропустил? Последняя версия -- 1.0 (http://www.opengroup.org/archimate/doc/ts_archimate/), вторая версия пока обсуждается в закрытом режиме.

netolstoy

5 years ago

ailev

5 years ago

Подскажите, пожалуйста, в чем принципиальная разница между отношениями назначения и реализации. Не могу уловить тонкой грани в различии между ними:
- конструкция предназначается для выполнения функции (конструкция реализует функцию)
- функция реализуется посредством конструкции (функция определяет назначение конструкции)

Документация говорит скорее о типах Архимейта, которые возможно связывать тем или другим из этих отношений. Например, "A business process, business function, or business interaction may realize a business service. A business interface or application interface may be assigned to a business service". Причем Business service допускает даже одновременное использование и назначения и реализации, например для Application component или Business collaboration.

PS: Business Activity есть в документации http://www.opengroup.org/archimate/doc/ts_archimate/apdxb.html
Тут важно, активная или пассивная структура. Обычно назначается активная структура (приказом, чтобы не ослушалась) -- и после этого начинает выполнять назначенное поведение. Обращу также внимание, что роль и практика в предисловии указаны как "переходные между активной и пассивной структурой", между ними как раз назначение.

Реализация -- по линии либо поведения, либо по линии пассивной структуры, и означает переходы по линии конкретности (абстрактности), то есть используется главным образом для показа отношений между уровнями. Внутри одного уровня, ежели там появляются подуровни, будут большие сложности, например Архимейт не даст показать реализацию между двумя деятельностными объектами, один из которых как-то определяет другой. Это придется показывать, реифицируя отношения реализации реализующими процессами (то есть уже не отношениями реализации).

P.S. Приведенное в стандарте приложение во многих местах не соответствует текстовому описанию. Так, в этом приложении еще и access может быть только однонаправленным от поведения к пассивной структуре, а в тексте четко прописано, что направление стрелки соответствует основному направлению передачи (чтение, запись). В Archi выкрутились из этого тем, что "автоматом" дают возможность протягивания стрелки только в одну сторону (по таблице спецификации), но затем в свойствах стрелки дают возможность поменять направление (по тексту спецификации).
Благодарю, стало понятнее.
Получается, что кратко - "функция реализуется посредством конструкции", а "структура назначается на поведение".

Судя по документации, отношение реализации применяется не только для связи уровней, но и внутри уровней для отражения воплощения сервиса.
Дык сервис -- это как раз то, что видно (через интерфейсы) другому уровню. Это как раз и есть ответственный за связь уровней тип.

Deleted comment

добрый день! пытаюсь разобраться.

Application level, Application Function. Я правильно понимаю, что "фича" feature приложения (типа, для примера, "поиск документов по ключевым словам, присутствующим в названии" или "возможность загрузить выборку документов одним архивом") попадают именно в тип Application Function?
Ну да, это "функционал" -- application function. Почему отдельно? Функционал "поиск документов по ключевым словам, присутствующим в названии" вы можете делать разными приложениями, и вам нужно назначить функционал на софтинку (так, этот поиск документов я могу делать даже у себя в компьютере либо встроенной искалкой Виндов, либо всякими дополнительными поисковиками типа искалки в окошке Downloads моей Мозиллы, что я часто делаю для выгруженных из Сети документов). Если у вас "управление документами" делает на заводе и Documentum, и какой-то PLM и еще пара других систем, то вам нужно будет выбирать, какой функционал какой софтинкой вы выполняете.
Спасибо. Почему функционал отдельно от приложения -- это я понимаю вполне. (Я пытаюсь описать архитектуру конкретного приложения, и мне проще всего плясать от фич: с одной стороны, для чего/кого они нужны, с другой -- как реализованы.)
"Архитектуру отдельного приложния" -- дык это "программная архитектура", для этого Архимейт не предназначен. Он предназначен для выражения архитектуры предприятия. Так что нарисуйте-ка сначала уровень деятельности, а затем только приложения -- и сразу будет интересней и правильней.
Пардон, я вчера суетился и выражался неточно. Я на самом деле хочу отмоделировать (описать) проект, над которым работаю. Главным фокусом проекта является разработка приложения для внешнего заказчика, которым пользуются клиенты заказчика и за которое платят заказчику деньги. И я ищу способ и подходящий язык, чтобы описать этот проект от уровня деятельности (как его понимает Архимейт) до уровня технического в подробностях. (Иногда мой фокус внимания уходит в техническую часть, но это не значит, что он только там.) 

Я с большим удивлением увидел в ваших постах, что Архимейт в большой степени как-раз про то, про что я уже давно думаю и пытаюсь сделать в этой задаче. Поэтому решил попробовать его. Но я прошу прощения, что начал задавать вам вопросы не прочитав ещё спецификацию. (Но прочитав ваши посты по теме.)

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

Начал описывать уровень данных. И тут выяснились некоторые существенные различия в том, как о некоторых вещах думаю я, и как предлагает думать Архимейт.

Например, приложения и функционал (фичи). В моей голове приложение — это (с одной стороны) букет фич, то есть "приложение состоит из фич", отношение композиции. С другой стороны, приложение это пучок компонент, со своими зависимостями. И тут тоже получается композиция, а значит я не прав. Выходит надо разделить эти букет и пучок, и описать отношение между ними (и/или между конкретными стебельками). Мне хочется связать их отношением реализации. Фича X реализуется компонентой Y. Похоже, что фичи можно объединить в интерфейс(ы) или в сервисы на языке Архимейта. А компоненты?

Собственно, собираюсь читать спецификацию ещё, и может быть перечитывать ваши заметки, и разбираться. Но за помощь буду очень благодарен.
> Приложения состоят (буквально: отношение композиции) из их
> интерфейсов, на интерфейсы назначаются сервисы (а на сами
> приложения -- функционалы)

может здесь вы имели в виду: "а на сами СЕРВИСЫ -- функционалы"?
На приложения (софтинки) -- функционалы. Ибо функционал -- это то, что от приложений нужно. Но один и тот же функционал может быть у разных приложений, особенно если вы купили много корпоративного софта, каждый из которых может делать всё, что угодно. Вот вы сначала пишете потребный вам функционал на диаграмме, а потом поручаете его выполнять какому-то софту.

"Назначить" -- это именно административное отношение, поручение/приказ/распоряжение выполнить что-то нужное.
Ммм, да, тут я недопонимал, вы правы. Спасибо!
И ещё один вопрос в той же теме. Application interface -- это может быть и пользовательский интерфейс (например, GUI), и программный интерфейс (API)? Или сюда только пользовательский?
Архимейт не специфицирует, какой интерфейс: межмодульный, программный, протокол, шина или даже пользовательский интерфейс (но как вы будете показывать пользователя на уровне обработке данных?). Всё зависит от вашей ситуации, каждый случай нужно обсуждать конкретно.
ага, ясно, спасибо. (и действительно, пользователя на уровне обработки данных не покажешь. занчит интерфейс уже не пользователь-приложение, а пользователь-экранная форма, например. А уж экранная форма предоставляет ф-ционал, и обеспечивается приложением. Кажется так.)
> экранная форма предоставляет ф-ционал

предоставляет здесь неверное отношение. реализует? реализовывается через ф-ционал? подумаю.

wesel

October 7 2013, 07:31:48 UTC 3 years ago Edited:  October 7 2013, 07:35:54 UTC

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

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

Вот и хотела спросить, когда вы строите диаграммы, придерживаетесь ли рекомендации этого поста - называть процессы глаголом в неопределенной форме - или нет?

PS. Пожалуй, смущает в большей степени вот что - если мы моделируем процесс приемной кампании, то этап в рамках нее - это не "принять заявление" (1 штука), а "принять заявления" - много штуков. Соответственно, во втором случае мне опять же более уместным названием кажется "прием заявлений". Хотя во множественном числе уже неплохо. С другой стороны, интересно, как тогда должны быть на диаграмме связаны процессы "принять заявления (все, сколько принесут, и перестать принимать в установленную дату)" и "принять заявление (одно, у конкретного абитуриента, выполнив все шаги по порядку)".
Там ведь Архимейте критерий: если ваше "принять заявление" в цепочке (последовательность действий), то процесс налицо и это глагол. А если критерий сортировки другой (например, важно, что "приём заявлений" в каком-то конкретном подразделении, или финансирование его идёт отдельной строкой и т.д.), то это практика.

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

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