Комментарии 21
За plantuml отдельный плюс! Хотя судя по первым диаграммам - неплохо бы его обновить. Там дефолтная схема стала поприятнее, да и вообще появились некоторые плюшки.
Спасибо)
Что касается PlantUML, то делал в онлайн-версии. В ней схема по умолчанию выглядит совсем невзрачно. Поэтому пришлось немного поколдовать, задав стили:
skinparam state {
BorderColor FireBrick
BackgroundColor LemonChiffon
}
skinparam arrow {
Color FireBrick
}А далее уже по необходимости переопределял цвет фона:
...
state Created as "Договор создан" #PaleGreen
...
Выглядит сложновато. Этому вебинар посвящать надо
Соглашусь, что это не самое лёгкое чтиво. И, чтобы не было ложных ожиданий, я и маркировал статью "средним" уровнем. Помимо маркировки я надеялся донести мысли до аудитории и поэтому в тексте воспроизводил порядок событий, которые происходили на проектах, чтобы не было резких переходов от "было" до "стало", а также проиллюстрировал основные тезисы и соображения. Надеюсь, получилось.
Что же касается вебинара, то мысль интересная. Возможно, созрею до этого формата:) Хорошего дня!
Вот только начал смотреть и сразу бросилось в глаза:
Первый же статус сущности "Заявка" - Принята. А где создание объекта, как это сделано для Договора?
Где финальный статус Заявки в положительном сценарии? Ну ведь не Доставлена, да?
В единой диаграмме, если появится финальный статус Заявки, то он и "Договор создан" обязаны быть не последовательными между сущностями, а одновременными. Нельзя иметь закрытую Заявку, но ещё не созданный Договор. Хотя в данном случае можно сначала создать Договор, и по факту успеха создания уже закрыть Заявку.
В некоторых процессах статусы взаимозависимых объектов должны меняться одновременно.
Я чего так волнуюсь за статью :) - у меня сейчас в работе очень похожая ситуация. Только сущностей - 4 штуки, сейчас только у одной выделены статусы, и есть сложные обратные ветвления процессов с рождением ещё "вспомогательных" объектов одной сущности; мозг уже 2-й месяц взрывается.
Логика статьи подхода к проектированию правильная.
Тоже вижу, что фомальное следование нотациям может иметь близкую к нулю ценность.
Например, в качестве промежуточной схемы между вариантами поведения и бизнес-процессами (БП) пару раз омогало сначала накидывать движение управления процессами прямо внутри вариантов поведения, а потом уже, поглядывая на полученного ежа с ужом, спокойно отрисовывать БП
Первый же статус сущности "Заявка" - Принята. А где создание объекта, как это сделано для Договора?
Здесь "Принята", по сути, и означает факт создания заявки. Заявка порождалась, когда поступала из фронт-энда. Это можно читать как "мы приняли заявку из фронта".
Где финальный статус Заявки в положительном сценарии? Ну ведь не Доставлена, да?
Конкретно в этом случае была некоторая недосказанность в статусной модели мастер-системы для заявок. Разработчики этой системы исходили из того, что отправили заявку в систему 2-й компании, получили успешный ответ о доставке (грубо говоря, не сломались, не было тайм-аута и хорошо), значит заявка переходит в состояние «Заявка доставлена». Это и было финальным состояние.
Создан был договор или нет, по факту 1-я система не знала, об этом я и писал выше: «Более того, состояние «Заявка доставлена» вообще не гарантирует того, что сущность «Договор» была создана (вторая компания могла принять запрос на открытие договора, но по какому-то трагическому стечению обстоятельств так этого и не сделала).».
Но вот «Заявка отклонена» — это было состояние на всякий непредвиденный случай. Случай, когда во 2-й системе (там, где должны были породить сущность «Договор») эксперт принял бы решение, что договор завести никак нельзя, выявлена какое-то неустранимое препятствие. Для такого кейса был предусмотрен вызов 1-й системы из 2-й, в таком случае 1-я система бы получила сведение, что конкретно эту заявку забраковали. И тогда 1-я система переводила заявку, которую считала до того уже в финальном статусе, в новое состояние (ещё более финальное, если так вообще можно сказать:)).
В единой диаграмме, если появится финальный статус Заявки, то он и "Договор создан" обязаны быть не последовательными между сущностями, а одновременными. Нельзя иметь закрытую Заявку, но ещё не созданный Договор. Хотя в данном случае можно сначала создать Договор, и по факту успеха создания уже закрыть Заявку.
В некоторых процессах статусы взаимозависимых объектов должны меняться одновременно.
Чуть выше я описал, что договор создавался уже после того, как заявка доставлена. Это были не одномоментные события в картине мира этих 2-х компаний. Да, если бы 2-я компания по факту приёма информации о заявке сразу создавала договор, то эти 2 статуса были бы одновременными, но в описанном мною случае эти этапы разрывались. Задачи править реализации обеих компаний не было, поэтому работали с тем, что есть.
Ну и, естественно, если бы финальный статус заявки означал начальный статус договора, то в единой статусной модели процесса был бы представлен только 1 статус (2 статуса «схлопнулись» бы в рамках созданной сущности «Процесс»).
Спасибо за развёрнутый ответ
Здесь "Принята", по сути, и означает факт создания заявки. Заявка порождалась, когда поступала из фронт-энда.
Не, так не пойдёт )). "Подразумевается", "можно считать, что" и т.п.- страшные вещи!
1. "Принята" - значит, принят, получен объект. Никак не создан.
Создание - это создание объекта, никак не его передача/получение.
Или заявка как объект создан на фронте (один из признаков этого события - присваивается уникальный идентификатор), или бэк получает запрос на создание объекта (заявки), валидирует запрос и создаёт объект. Хоть убейте, но другого варианта пока не вижу.
была некоторая недосказанность в статусной модели мастер-системы
Вот именно, я про это.
Задайте вопрос - кто владелец объекта, кто заинтересованные в этом объекте акторы.
К кому будет ходить фронт (пользователь) за статусом заявки? А как информационная система (не бэк) вообще понимает, что происходит с этой заявкой? Где связь заявки с договором?
Если команда отвечает только за один компонент (бэк, обрабатывающий заявку), то, я так считаю, у команды должна быть полная статусная модель объекта, даже если управление объектом отдаётся в другие сервисы, ИС. Хотя бы потому, что полная модель позволяет:
понимать границы ответственности каждого компонента/сервиса за объект;
трассировать входящие, исходящие и внутренние требования по работе с объектом;
заранее понимать возможные требования к обработке объекта - заранее подстелить соломку в нужных местах проектирования логики
А так вы пилите ногу слона и не знаете, или она должна ходить в составе слона, или её на мясо, или её пришьют не к слону, или...
был предусмотрен вызов 1-й системы из 2-й
Это продолжение предыдущего, на самом деле.
Вот интересно, а что мешает 2-й системе сделать то же самое для основного сценария, чтобы бэк, как владелец объекта, со спокойной совестью завершил жизнь объекта? Почему только для неуспеха?
Могу сказать, что это совсем не праздные вопросы. В продукте моего проекта предыдущие команды разработки предусмотрели ответ только принят/не принят на техническом уровне, прямо как тут. И кто б сомневался, что в итоге передающей системе надо знать и решение принимающей стороны по переданному объекту! Теперь это с такой кровью пытаются сделать
1. "Принята" - значит, принят, получен объект. Никак не создан.Создание - это создание объекта, никак не его передача/получение.
"Принята" это в терминах бэковой системы. Они заявку приняли. То, что приём предполагает создание записи в соответствующей табличке БД,— это уже технические детали. Даже не понимаю, как можно не соглашаться с тем, кто как назвал в своей системе состояния. Это факт.
Или заявка как объект создан на фронте (один из признаков этого события - присваивается уникальный идентификатор), или бэк получает запрос на создание объекта (заявки), валидирует запрос и создаёт объект. Хоть убейте, но другого варианта пока не вижу.
Формируется базово на фронте, но там оперируют понятием операции (безликая сущность с генерализованным названием) и, коль скоро для решаемой задачи этот сегмент процесса был признан несущественным, то приклеивать 3-ю сущность ("операцию") не понадобилось. Схема стала формироваться, начиная с 1-го бэка, а там термин "Заявка" в ней был основным.
Это продолжение предыдущего, на самом деле.Вот интересно, а что мешает 2-й системе сделать то же самое для основного сценария, чтобы бэк, как владелец объекта, со спокойной совестью завершил жизнь объекта? Почему только для неуспеха?
А вот тут мы приходим к 2-м тезисам.
Во-первых, это частично и приводило к сложностям обслуживания. Но решать это выстраиванием петель обратной связи и сшиванием статусных моделей 2-х разных компаний посчитали не лучшей затеей. Да и системе мониторинга, которая живёт отдельно, это никак не помогает.
Во-вторых, владельцы систем и жили в парадигме границ: одна система отвечает за заявки, другая уже занимается договорами. И это обусловлено тем, что это 2 разные компании, которые жили каждая своей счастливой жизнью, но при выстраивании сквозного процесса (чтобы 1-я компания могла продавать через себя продукты 2-й) пришлось "подружить" системы.
И кто б сомневался, что в итоге передающей системе надо знать и решение принимающей стороны по переданному объекту! Теперь это с такой кровью пытаются сделать
Безусловно, такое тоже может иметь место. Даже допускаю, что статус "Заявка отклонена" и появился в ходе проработки подобной потребности (был один конечный статус, а бизнес пришёл и сказал, что желает знать об отказах). Но надо понимать, что задачи переделать системы и/или их взаимодействие не было (на это были свои резоны). Мне тоже не всё в имеющемся процессе нравилось, но это жизнь.
Просто я за то, чтобы глагол определял именно то значение, которое он имеет в своём действии. Повторюсь, под "принять" подразумевать "создать" - очень плохая практика.
Ещё раз повторюсь, объект или есть, или его нет. Что такое "безликая сущность с генерализованным названием"? Это или запрос (объект!) на создание объекта-заявки, или сама заявка. Посередине не бывает. В принципе, как в ИС возможно существование "безликой сущности"?
Что такое "безликая сущность с генерализованным названием"?
Там фигурирует сущность "Операция". Поэтому и говорю, что безликая. Через эту сущность (фактически транспортный объект) в бэк передаётся всё что угодно: запрос какой-то информации, передача чего-то. Через эту сущность попадает, среди прочего, и заявка, просто "Заявка" как сущность создаётся именно в бэке, когда внутрянку проанализировали и поняли, что речь в данном конкретном объекте типа "Операция" идёт о необходимости открыть договор.
Такое ощущение, что вы пытаетсь меня убедить пойти и переписать системы, исходя из своего понимания прекрасного:)
Только сущностей - 4 штуки, сейчас только у одной выделены статусы, и есть сложные обратные ветвления процессов с рождением ещё "вспомогательных" объектов одной сущности; мозг уже 2-й месяц взрывается.
Вот это звучит действительно серьёзно. Из опыта могу посоветовать посмотреть на всю эту красоту сверху и попытаться выстроить целевую статусную модель только с критически важными состояниями исходных процессов. Если не пытаться переносить все состояния на целевую схему, то внезапно может оказаться, что картинка сильно упростится за счёт того, что «схлопнутся» некоторые состояния с переходами между ними. Опять же, если это подходит под решаемую вами задачу, а если нет, то могу только пожелать терпения:)
Отличные идеи, креативно
1. Actor Time(r) для UC Diagram - хоть и аналог события из BPMN, но в UCD не встречал
2. Границы ПодСистем в UCD, вместо стандартного "границы системы"
3. States Machine - два взаимосвязанных состояния на одной диаграмме, здорово
спасибо
Спасибо за комментарий.
Добавлю несколько ремарок.
Если выполнение сценария инициируется по расписанию, введите в рассмотрение эктора Time (время), тогда жизнь сильно упрощается. Как я отметил в статье, это не моё изобретение, но это довольно слабо применяемая практика. Вот, например здесь ещё в 2009 году задавались вопросом, а правда ли так можно, и ответом было «да» со ссылкой на эту страницу.
Что касается границ системы, то тут был фокус как раз в применении системного подхода (почему-то большинство системных аналитиков его не изучало, но это тема для отдельной статьи:)). Так вот, собственно, системы входят в системы более высокого уровня (суперсистемы, надсистемы) и делятся на системы более низкого уровня (подсистемы). Системы любого уровня — это всё равно системы. А раз так, то можно не решать задачу в лоб, а обыграть это на синтаксисе UML.
Здесь у меня была логика, чем-то сходная с п.2. Если можно создать свою сущность, тогда формально ты не нарушаешь ничего. В конце концов, любая сущность при проектировании (та же «Заявка» и «Договор») — это не более чем модель, объект-заменитель, а значит изначально содержит определённый уровень условностей и допущений. А раз так, мы тоже можем создать свою сущность, которая тоже будет отражать в некотором приближении понятие реального мира, и уже её смоделировать доступными средствами.
Опять я несогласный.
введите в рассмотрение эктора Time (время)
Пока не соглашусь, что время - это актор. Это что-то из внематериального и эзотерического. Ну как время (что это за субъект такой - время?!) может на что-то воздействовать? Чем оно воздействует?
Во всех примерах вместо Time очень чётко встаёт конкретная система.
Выгрузку сделок в хранилище делают именно Торговая система А и Торговая система Б. Можно выделить конкретный модуль/компонент/сервис, если требуется - так будет нагляднее, что внутри объекта "Торговая система" есть актор-модуль, являющийся в данном процессе субъектом
Эктором может быть что угодно, чьё поведение выступает триггером для функциональности. Это может быть конечный пользователь систем (самый очевидный вариант), другая система или время.
Вот пример из другой сферы. Раз в год компания формирует некоторую отчётность и отправляет её в регулирующие органы. Формирование отчётов можно представить как вариант использования, а человека признать эктором. Но тут вопрос: человек разве по своему разумению отправляет отчёты? Нет. Он не просыпается утром с мыслью: "Вот сегодня задам жару, отправлю отчёт". Тут обстоятельства, бизнес-правила, расписание вынуждают его это сделать. В такой конфигурации время будет наиболее логичным вариантом эктора. Ну и надо понимать, что не обязательно отчёт в данном случае формируется системой автоматически, тот самый человек вполне может требоваться, чтобы войти в систему, ввести параметры и нажать большую красную кнопку. Руками человека исполняется логика иного уровня.
Во всех примерах вместо Time очень чётко встаёт конкретная система.Выгрузку сделок в хранилище делают именно Торговая система А и Торговая система Б.
Выгружают действительно Торговые системы А и Б, это и показано в форме эллипсов (варианты использования). Но они выполняют внешнюю логику, как описал двумя абзацами выше.
Да, это не так просто принять, поэтому практика применения эктора Time в диаграммах вариантов использования и в диаграммах последовательности не так распространена. Но тем не менее она есть и имеет свой смысл.
Эктором может быть что угодно, чьё поведение выступает триггером для функциональности
Триггер - это какое-то событие.
Актор - это субъект, что-то выполняющий.
Триггер - это объект-событие, порождаемое субъектом (актором).
Не вижу в этом место времени как актору. В лучшем случае, актор может использовать время для чего-то. Время - ничего использовать не может. Это измерение, физическая величина. Актором может быть длина? Температура?
В примере, к сожалению, много чего напутано.
Надо отделять артефакты физического мира и артефакты смоделированной ИС.
Мы работаем с моделью. Актор в ИС - это не человек во всём его многообразии. Это субъект со строго определёнными свойствами. ИС ждёт от актора строго определённый набор воздействий.
Всё остальное - какие у реального человека обстоятельства, какие у него там бумажки с какими-то хоть дважды бизнес-правилами - это не входит в ИС.
Хотите учесть бизнес-правила? Смоделируйте компонент в ИС или внешнюю ИС, где они реализованы. На самом деле они всегда есть в ИС. Но не надо путать реализованное в ИС и артефакт внешнего мира. Учесть "обстоятельства"? Аналогично.
Я заговорился )). В примере опять не вижу никакого места времени. Только актор-человек, только актор-система, только хардкор.
Актор-человек задал правила формирования объекта (от полноценной установки параметров до вырожденного в триггер правила - нажатия кнопки) - актор система понеслась выполнять действия с объектом.
Если актор-человек здесь действует как объект других акторов ("обстоятельств") - нарисуйте этого актора-обстоятельство. Если это, конечно, полезно для проектирования/использования ИС. Но тут поаккуратнее, включение в модель ИС большого количества акторов сильно усложняет проектирование и поведение ИС. Идеальная модель должна включать весь физический мир вокруг нас :)).
Тема границ модели, кстати, тоже важна, но это отдельный большой раздел проектирования ИС.
Осмысленная визуализация при анализе и проектировании в действии