Эктором может быть что угодно, чьё поведение выступает триггером для функциональности
Триггер - это какое-то событие. Актор - это субъект, что-то выполняющий. Триггер - это объект-событие, порождаемое субъектом (актором).
Не вижу в этом место времени как актору. В лучшем случае, актор может использовать время для чего-то. Время - ничего использовать не может. Это измерение, физическая величина. Актором может быть длина? Температура?
В примере, к сожалению, много чего напутано. Надо отделять артефакты физического мира и артефакты смоделированной ИС. Мы работаем с моделью. Актор в ИС - это не человек во всём его многообразии. Это субъект со строго определёнными свойствами. ИС ждёт от актора строго определённый набор воздействий. Всё остальное - какие у реального человека обстоятельства, какие у него там бумажки с какими-то хоть дважды бизнес-правилами - это не входит в ИС. Хотите учесть бизнес-правила? Смоделируйте компонент в ИС или внешнюю ИС, где они реализованы. На самом деле они всегда есть в ИС. Но не надо путать реализованное в ИС и артефакт внешнего мира. Учесть "обстоятельства"? Аналогично.
Я заговорился )). В примере опять не вижу никакого места времени. Только актор-человек, только актор-система, только хардкор. Актор-человек задал правила формирования объекта (от полноценной установки параметров до вырожденного в триггер правила - нажатия кнопки) - актор система понеслась выполнять действия с объектом. Если актор-человек здесь действует как объект других акторов ("обстоятельств") - нарисуйте этого актора-обстоятельство. Если это, конечно, полезно для проектирования/использования ИС. Но тут поаккуратнее, включение в модель ИС большого количества акторов сильно усложняет проектирование и поведение ИС. Идеальная модель должна включать весь физический мир вокруг нас :)). Тема границ модели, кстати, тоже важна, но это отдельный большой раздел проектирования ИС.
Пока не соглашусь, что время - это актор. Это что-то из внематериального и эзотерического. Ну как время (что это за субъект такой - время?!) может на что-то воздействовать? Чем оно воздействует?
Во всех примерах вместо Time очень чётко встаёт конкретная система. Выгрузку сделок в хранилище делают именно Торговая система А и Торговая система Б. Можно выделить конкретный модуль/компонент/сервис, если требуется - так будет нагляднее, что внутри объекта "Торговая система" есть актор-модуль, являющийся в данном процессе субъектом
Здесь "Принята", по сути, и означает факт создания заявки. Заявка порождалась, когда поступала из фронт-энда.
Не, так не пойдёт )). "Подразумевается", "можно считать, что" и т.п.- страшные вещи! 1. "Принята" - значит, принят, получен объект. Никак не создан. Создание - это создание объекта, никак не его передача/получение. Или заявка как объект создан на фронте (один из признаков этого события - присваивается уникальный идентификатор), или бэк получает запросна создание объекта (заявки), валидирует запрос и создаёт объект. Хоть убейте, но другого варианта пока не вижу.
была некоторая недосказанность в статусной модели мастер-системы
Вот именно, я про это. Задайте вопрос - кто владелец объекта, кто заинтересованные в этом объекте акторы. К кому будет ходить фронт (пользователь) за статусом заявки? А как информационная система (не бэк) вообще понимает, что происходит с этой заявкой? Где связь заявки с договором? Если команда отвечает только за один компонент (бэк, обрабатывающий заявку), то, я так считаю, у команды должна быть полная статусная модель объекта, даже если управление объектом отдаётся в другие сервисы, ИС. Хотя бы потому, что полная модель позволяет:
понимать границы ответственности каждого компонента/сервиса за объект;
трассировать входящие, исходящие и внутренние требования по работе с объектом;
заранее понимать возможные требования к обработке объекта - заранее подстелить соломку в нужных местах проектирования логики
А так вы пилите ногу слона и не знаете, или она должна ходить в составе слона, или её на мясо, или её пришьют не к слону, или...
был предусмотрен вызов 1-й системы из 2-й
Это продолжение предыдущего, на самом деле. Вот интересно, а что мешает 2-й системе сделать то же самое для основного сценария, чтобы бэк, как владелец объекта, со спокойной совестью завершил жизнь объекта? Почему только для неуспеха? Могу сказать, что это совсем не праздные вопросы. В продукте моего проекта предыдущие команды разработки предусмотрели ответ только принят/не принят на техническом уровне, прямо как тут. И кто б сомневался, что в итоге передающей системе надо знать и решение принимающей стороны по переданному объекту! Теперь это с такой кровью пытаются сделать
Вот только начал смотреть и сразу бросилось в глаза:
Первый же статус сущности "Заявка" - Принята. А где создание объекта, как это сделано для Договора?
Где финальный статус Заявки в положительном сценарии? Ну ведь не Доставлена, да?
В единой диаграмме, если появится финальный статус Заявки, то он и "Договор создан" обязаны быть не последовательными между сущностями, а одновременными. Нельзя иметь закрытую Заявку, но ещё не созданный Договор. Хотя в данном случае можно сначала создать Договор, и по факту успеха создания уже закрыть Заявку. В некоторых процессах статусы взаимозависимых объектов должны меняться одновременно.
Я чего так волнуюсь за статью :) - у меня сейчас в работе очень похожая ситуация. Только сущностей - 4 штуки, сейчас только у одной выделены статусы, и есть сложные обратные ветвления процессов с рождением ещё "вспомогательных" объектов одной сущности; мозг уже 2-й месяц взрывается.
Логика статьи подхода к проектированию правильная. Тоже вижу, что фомальное следование нотациям может иметь близкую к нулю ценность. Например, в качестве промежуточной схемы между вариантами поведения и бизнес-процессами (БП) пару раз омогало сначала накидывать движение управления процессами прямо внутри вариантов поведения, а потом уже, поглядывая на полученного ежа с ужом, спокойно отрисовывать БП
Два раза перечитал и всё никак не мог врубиться, почему команда стала частью схемы. Пока не посмотрел на схему. Я понимаю, конечно, что на англ. это просто "command". Но надо же учитывать контекст. "Командой" часто называют актора процесса (team). Было бы чуть лучше сказать "управляющая команда"
Спасибо за ответ. Именно так, можно по-разному выгребать бэклог, но в любом случае это должен быть постоянный рабочий процесс. А не набеги в стиле "ой, мальчики, давайте поиграем стильно-модно-молодёжно (а то у меня скиллов не хватает - сделайте что-нибудь)"
Полностью поддерживаю предыдущих ораторов, вплоть до профпригодности. После прочтения заголовка "Шаг 1. Посмотреть бэклог и выбрать подходящие для мероприятия баги по определенным требованиям" хочется спросить - народ в этой ваше Ламоде, а что вам раньше мешало сделать то же самое, но в нормальном рабочем процессе? И вы вообще понимаете, что такое "...отон"? Что этот ваш сотрудник, написавший статью и не затруднивший себя даже представить, хладнокровно решил свои проблемы вашим ловким манипулированием?
Прошу прощения, пока всё не осилил, но прямо с самого начала, про терминологию. Не понял, почему все ссылки на CBOK (к своему стыду, даже не припомню, чтобы слышал о нём), и не используется BABOK? Моделированием, изучением бизнес-процессов занимается бизнес-анализ. В т.ч. и терминологически. В BABOK, насколько помню, разделены бизнес-процессы и бизнес-функции. Есть бизнес-правила (не надо, пож-та, "административных регламентов", это другое). Используя BABOK, часть затронутых тут проблем была бы решена естественным путём
Предположу, что не взлетело потому что не было осязаемых (измеряемых) целей. Надо ж понять, сколько стоит держать в этой системе актуальное инфо, и сколько стоит не держать, а обходится текущими (или ещё какими-то другими) процессами в компании.
Второй момент. Если прикинули и сказали "да", то дальше надо соблюдать соглашение о новых процессах. Это не просто дисциплина и регламенты. Это такая же часть работы, как и всё остальное, что далеко не все понимают ("не царское это дело - доки заполнять...").
Повторюсь, важен конечный результат, а не то, что сеньоры-помидоры ломаются от n% времени на процедуры
Сначала была связь "один ко многим", где у одной машины был один владелец, и у одного владельца много машин. Но со временем эксплуатации системы в продакшн оказалось нормальной ситуацией, что иногда два человека приезжают обслуживать одну машину
Какое отношение имеет сколько человек приехало обслуживать машину к количеству владельцев машины? Я не понял
Возможно, пропустил при чтении, но так и понял, где в статье таблетка для исключения фейлов из примеров? Только знание, в т.ч. с помощью стейкхолдеров/консультантов, домена знаний. Ещё немного может помочь здравый смысл. Как тут можно другим, волшебным образом "сделать модель БД гибкой" под эти примеры, тоже не понял. Вся модель БД - это ровно то, что предусмотрел аналитик после выявления всех (вымерших, текущих и будущих) сущностей и их зависимостей. Откуда тут какая-то другая "гибкость"?
Извините, но такая интерпретация неверна. Не имеет значения, что там хотел сказать автор (какую скорость он показывает: физического интерфейса, передачи файла или любую другую). Он численно описывает один параметр двумя способами. Без вариантов
Мне кажется, ответ уже заложен в слове "идеал". В этом и состоит вся польза руководителя, чтобы он настраиваил и управлял процессами так, чтобы было как можно ближе к принципиально недостижимому идеалу
Судя по описанию, компонент в системе - это микросервис, стало чуть понятнее. Не ушло главное моё непонимание. Вы проектирует якобы для одного компонента только на том основании, что в нём будут проходить большинство процессов. При этом затронуты другие компоненты - это очевидно из приведённых US/UC.
Т.е., вместо того, чтобы описать пользовательскую функциональность как взаимодействие всех компонентов между собой, вы описываете как взаимодействие одного компонента со всеми остальными. Полное понимание процессов по конкретной пользовательской функциональности теперь только внутри одного компонента. Получаем, что все описания почти рандомно размазаны по компонентам. Каждый компонент теперь не понимает, что и зачем вот этот API в нём делает - надо идти к потребителю. А потребителей может быть более одного. То же самое, зачем компонент внезапно использует какой-то метод другого компонента. Теперь надо бегать по всей системе, искать "ответственный" компонент, чтобы сложить пазл.
Если это так, то это полный кошмар для аналитика. Зачем вкладыватьверхнеуровневые (бизнес) артефакты в компоненты - не понимаю. В компонентах должен содержаться исключительно системный анализ. Описание логики, данных, API - всё то, что касается работы исключительно данного компонента
Ларчик просто открывается. Невозможно полностью проанализировать предметную область (я про реальные области/системы) так, чтобы спроектировать для неё идеальную логическую структуру. Элементарное доказательство - невозможно предсказать завтрашние изменения предметной области. И даже вчерашние изменения, потому что вы сегодня просто не имеете знаний о том, что было вчера. В реальном мире невозможно учесть всё.
Кстати, для меня тоже пару лет назад стало неприятным откровением, что не получится легко и непринуждённо использовать СНИЛС как идентификатор человека
Не совсем понял. Какая последовательность действий СА? Сначала текстовое описание методов, затем контракт OpenAPI или наоборот? Если наоборот, откуда СА будет брать инфо в процессе описания контракта - держать в голове?
Триггер - это какое-то событие.
Актор - это субъект, что-то выполняющий.
Триггер - это объект-событие, порождаемое субъектом (актором).
Не вижу в этом место времени как актору. В лучшем случае, актор может использовать время для чего-то. Время - ничего использовать не может. Это измерение, физическая величина. Актором может быть длина? Температура?
В примере, к сожалению, много чего напутано.
Надо отделять артефакты физического мира и артефакты смоделированной ИС.
Мы работаем с моделью. Актор в ИС - это не человек во всём его многообразии. Это субъект со строго определёнными свойствами. ИС ждёт от актора строго определённый набор воздействий.
Всё остальное - какие у реального человека обстоятельства, какие у него там бумажки с какими-то хоть дважды бизнес-правилами - это не входит в ИС.
Хотите учесть бизнес-правила? Смоделируйте компонент в ИС или внешнюю ИС, где они реализованы. На самом деле они всегда есть в ИС. Но не надо путать реализованное в ИС и артефакт внешнего мира. Учесть "обстоятельства"? Аналогично.
Я заговорился )). В примере опять не вижу никакого места времени. Только актор-человек, только актор-система
, только хардкор.Актор-человек задал правила формирования объекта (от полноценной установки параметров до вырожденного в триггер правила - нажатия кнопки) - актор система понеслась выполнять действия с объектом.
Если актор-человек здесь действует как объект других акторов ("обстоятельств") - нарисуйте этого актора-обстоятельство. Если это, конечно, полезно для проектирования/использования ИС. Но тут поаккуратнее, включение в модель ИС большого количества акторов сильно усложняет проектирование и поведение ИС. Идеальная модель должна включать весь физический мир вокруг нас :)).
Тема границ модели, кстати, тоже важна, но это отдельный большой раздел проектирования ИС.
Опять я несогласный.
Пока не соглашусь, что время - это актор. Это что-то из внематериального и эзотерического. Ну как время (что это за субъект такой - время?!) может на что-то воздействовать? Чем оно воздействует?
Во всех примерах вместо Time очень чётко встаёт конкретная система.
Выгрузку сделок в хранилище делают именно Торговая система А и Торговая система Б. Можно выделить конкретный модуль/компонент/сервис, если требуется - так будет нагляднее, что внутри объекта "Торговая система" есть актор-модуль, являющийся в данном процессе субъектом
Спасибо за развёрнутый ответ
Не, так не пойдёт )). "Подразумевается", "можно считать, что" и т.п.- страшные вещи!
1. "Принята" - значит, принят, получен объект. Никак не создан.
Создание - это создание объекта, никак не его передача/получение.
Или заявка как объект создан на фронте (один из признаков этого события - присваивается уникальный идентификатор), или бэк получает запрос на создание объекта (заявки), валидирует запрос и создаёт объект. Хоть убейте, но другого варианта пока не вижу.
Вот именно, я про это.
Задайте вопрос - кто владелец объекта, кто заинтересованные в этом объекте акторы.
К кому будет ходить фронт (пользователь) за статусом заявки? А как информационная система (не бэк) вообще понимает, что происходит с этой заявкой? Где связь заявки с договором?
Если команда отвечает только за один компонент (бэк, обрабатывающий заявку), то, я так считаю, у команды должна быть полная статусная модель объекта, даже если управление объектом отдаётся в другие сервисы, ИС. Хотя бы потому, что полная модель позволяет:
понимать границы ответственности каждого компонента/сервиса за объект;
трассировать входящие, исходящие и внутренние требования по работе с объектом;
заранее понимать возможные требования к обработке объекта - заранее подстелить соломку в нужных местах проектирования логики
А так вы пилите ногу слона и не знаете, или она должна ходить в составе слона, или её на мясо, или её пришьют не к слону, или...
Это продолжение предыдущего, на самом деле.
Вот интересно, а что мешает 2-й системе сделать то же самое для основного сценария, чтобы бэк, как владелец объекта, со спокойной совестью завершил жизнь объекта? Почему только для неуспеха?
Могу сказать, что это совсем не праздные вопросы. В продукте моего проекта предыдущие команды разработки предусмотрели ответ только принят/не принят на техническом уровне, прямо как тут. И кто б сомневался, что в итоге передающей системе надо знать и решение принимающей стороны по переданному объекту! Теперь это с такой кровью пытаются сделать
Вот только начал смотреть и сразу бросилось в глаза:
Первый же статус сущности "Заявка" - Принята. А где создание объекта, как это сделано для Договора?
Где финальный статус Заявки в положительном сценарии? Ну ведь не Доставлена, да?
В единой диаграмме, если появится финальный статус Заявки, то он и "Договор создан" обязаны быть не последовательными между сущностями, а одновременными. Нельзя иметь закрытую Заявку, но ещё не созданный Договор. Хотя в данном случае можно сначала создать Договор, и по факту успеха создания уже закрыть Заявку.
В некоторых процессах статусы взаимозависимых объектов должны меняться одновременно.
Я чего так волнуюсь за статью :) - у меня сейчас в работе очень похожая ситуация. Только сущностей - 4 штуки, сейчас только у одной выделены статусы, и есть сложные обратные ветвления процессов с рождением ещё "вспомогательных" объектов одной сущности; мозг уже 2-й месяц взрывается.
Логика статьи подхода к проектированию правильная.
Тоже вижу, что фомальное следование нотациям может иметь близкую к нулю ценность.
Например, в качестве промежуточной схемы между вариантами поведения и бизнес-процессами (БП) пару раз омогало сначала накидывать движение управления процессами прямо внутри вариантов поведения, а потом уже, поглядывая на полученного ежа с ужом, спокойно отрисовывать БП
Два раза перечитал и всё никак не мог врубиться, почему команда стала частью схемы. Пока не посмотрел на схему.
Я понимаю, конечно, что на англ. это просто "command". Но надо же учитывать контекст. "Командой" часто называют актора процесса (team).
Было бы чуть лучше сказать "управляющая команда"
Спасибо за ответ. Именно так, можно по-разному выгребать бэклог, но в любом случае это должен быть постоянный рабочий процесс. А не набеги в стиле "ой, мальчики, давайте поиграем стильно-модно-молодёжно (а то у меня скиллов не хватает - сделайте что-нибудь)"
Полностью поддерживаю предыдущих ораторов, вплоть до профпригодности.
После прочтения заголовка
"Шаг 1. Посмотреть бэклог и выбрать подходящие для мероприятия баги по определенным требованиям"
хочется спросить - народ в этой ваше Ламоде, а что вам раньше мешало сделать то же самое, но в нормальном рабочем процессе? И вы вообще понимаете, что такое "...отон"? Что этот ваш сотрудник, написавший статью и не затруднивший себя даже представить, хладнокровно решил свои проблемы вашим ловким манипулированием?
Много пересечений содержания и фото этого поста с https://dubikvit.livejournal.com/180556.html
Там, пожалуй, будет поболее
Прошу прощения, пока всё не осилил, но прямо с самого начала, про терминологию.
Не понял, почему все ссылки на CBOK (к своему стыду, даже не припомню, чтобы слышал о нём), и не используется BABOK? Моделированием, изучением бизнес-процессов занимается бизнес-анализ. В т.ч. и терминологически. В BABOK, насколько помню, разделены бизнес-процессы и бизнес-функции. Есть бизнес-правила (не надо, пож-та, "административных регламентов", это другое).
Используя BABOK, часть затронутых тут проблем была бы решена естественным путём
Предположу, что не взлетело потому что не было осязаемых (измеряемых) целей.
Надо ж понять, сколько стоит держать в этой системе актуальное инфо, и сколько стоит не держать, а обходится текущими (или ещё какими-то другими) процессами в компании.
Второй момент. Если прикинули и сказали "да", то дальше надо соблюдать соглашение о новых процессах.
Это не просто дисциплина и регламенты. Это такая же часть работы, как и всё остальное, что далеко не все понимают ("не царское это дело - доки заполнять...").
Повторюсь, важен конечный результат, а не то, что сеньоры-помидоры ломаются от n% времени на процедуры
Какое отношение имеет сколько человек приехало обслуживать машину к количеству владельцев машины? Я не понял
Возможно, пропустил при чтении, но так и понял, где в статье таблетка для исключения фейлов из примеров?
Только знание, в т.ч. с помощью стейкхолдеров/консультантов, домена знаний. Ещё немного может помочь здравый смысл.
Как тут можно другим, волшебным образом "сделать модель БД гибкой" под эти примеры, тоже не понял. Вся модель БД - это ровно то, что предусмотрел аналитик после выявления всех (вымерших, текущих и будущих) сущностей и их зависимостей. Откуда тут какая-то другая "гибкость"?
Извините, но такая интерпретация неверна.
Не имеет значения, что там хотел сказать автор (какую скорость он показывает: физического интерфейса, передачи файла или любую другую). Он численно описывает один параметр двумя способами. Без вариантов
Это по какой системе исчисления?
Нет.
В какую функцию какого компонента входит US "Поставить диагноз, получить рекомендации от ИИ"?
Мне кажется, ответ уже заложен в слове "идеал".
В этом и состоит вся польза руководителя, чтобы он настраиваил и управлял процессами так, чтобы было как можно ближе к принципиально недостижимому идеалу
Судя по описанию, компонент в системе - это микросервис, стало чуть понятнее.
Не ушло главное моё непонимание. Вы проектирует якобы для одного компонента только на том основании, что в нём будут проходить большинство процессов. При этом затронуты другие компоненты - это очевидно из приведённых US/UC.
Т.е., вместо того, чтобы описать пользовательскую функциональность как взаимодействие всех компонентов между собой, вы описываете как взаимодействие одного компонента со всеми остальными. Полное понимание процессов по конкретной пользовательской функциональности теперь только внутри одного компонента. Получаем, что все описания почти рандомно размазаны по компонентам. Каждый компонент теперь не понимает, что и зачем вот этот API в нём делает - надо идти к потребителю. А потребителей может быть более одного. То же самое, зачем компонент внезапно использует какой-то метод другого компонента. Теперь надо бегать по всей системе, искать "ответственный" компонент, чтобы сложить пазл.
Если это так, то это полный кошмар для аналитика.
Зачем вкладыватьверхнеуровневые (бизнес) артефакты в компоненты - не понимаю.
В компонентах должен содержаться исключительно системный анализ. Описание логики, данных, API - всё то, что касается работы исключительно данного компонента
Пользовательская функциональность затрагивает, как правило, несколько компонентов архитектуры. У вас эпики - компоненты.
Где вы формулируете US, UC для этой функциональности, если у вас самый верхний уровень - компонент?
Как внутри одного компонента можно делать US, если она обычно затрагивает несколько компонентов?
Как можно внутри компонента описывать БА, если он охватывает весь продукт (несколько компонентов)
Ларчик просто открывается. Невозможно полностью проанализировать предметную область (я про реальные области/системы) так, чтобы спроектировать для неё идеальную логическую структуру.
Элементарное доказательство - невозможно предсказать завтрашние изменения предметной области. И даже вчерашние изменения, потому что вы сегодня просто не имеете знаний о том, что было вчера. В реальном мире невозможно учесть всё.
Кстати, для меня тоже пару лет назад стало неприятным откровением, что не получится легко и непринуждённо использовать СНИЛС как идентификатор человека
Не совсем понял. Какая последовательность действий СА?
Сначала текстовое описание методов, затем контракт OpenAPI или наоборот?
Если наоборот, откуда СА будет брать инфо в процессе описания контракта - держать в голове?
Тогда что там делает союз "и" в предложении и множественное число "показатели"?
В общем, я ещё не разучился читать по-русски