Коллеги, нужна помощь по архимейт. Пытаюсь промоделировать систему и очень не хватает отношения (relationship), которое описывало бы взаимодействие в общем виде: "использует", "обращается", "посылает сообщения". Моя система - это система обработки ордеров (order management system, OMS). Упрощенно говоря трейдеры создают ордера через торговые терминалы. Торговые терминалы посылают эти ордера в мою систему (order management system), а она, в свою очередь, отправляет их (ордера) на биржу/к брокеру. По хорошему, я хочу отобразить три Application component'a (в натации архимейт): терминал, OMS, биржа, но у меня нет подходящей связи для этого. Приходится добавлять функции приложения (application function) - order management function, market communication function и две связи - одна service (например между торговым терминалом и order management function), a вторая - assignment или realization (например OMS реализует order management function)

Мне кажется, что это добавляет ненужную сложность. Было бы достаточно отношения "взаимодействует", без уточнения характера взаимодействия

Association?

А так почему не подходит?

может с направлением стрелок напутал :)

хм, по идее подходит, только в Archi она почему-то без стрелок

А, увидел - там можно directed поставить. Спасибо - то что нужно

Кстати, у вас на картинке serving relation, а это не совсем то, что нужно. Association - вроде более уместно

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

она просто "используется", так что association, видимо, будет подходящей связью

Здравствуйте, коллеги! А кто знает, можно ли на схеме в EA  показать один и тот же объект? Это сразу порождает другой вопрос - как показать на схеме жизненный цикл объекта в разных состояниях?

На какой схеме?

которое описывало бы взаимодействие в общем виде: "использует"

От сюда: https://pubs.opengroup.org/architecture/archimate3-doc/chap05.html
The serving relationship represents that an element provides its functionality to another element.
Так что для "использует" подходит

которое описывало бы взаимодействие в общем виде: "использует"

Да, согласен, спасибо за уточнение

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

Как опция, где об этом можно почитать?

так они в каждой компании свои, надо понимать что нужно. Как пример требования по доступности, времени отклика, сложности интерефеса. Или вопрос как отличить функциональные от нефункциональных?

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

Похоже на пятый модуль вот тут https://systems.education/tz-online

тут было https://www.luxoft-training.ru/kurs/klyuchevye_praktiki_arhitektora_po.html