Коллеги, доброго времени суток.
В результате плодотворной договорной работы с собственной жабой купил я себе на премию EA 12 Corporate ed., ибо интересно.
Не было заботы....
Напомню суть топика.
Неторопливо изучаю UML посредством перевода имеющейся проектной документации в единый стандарт. Выхода на генерацию программного кода не планирую и вряд ли до этого вообще дойду. Максимальная цель - сопровождаемое документирование проекта.
Короче …
После недолгого самодовольного хрюканья на тему проявившихся возможностей, появились и вопросы. Как ни странно, не совсем по UML. Ну или совсем не по UML. Возможно, перееду с этими вопросами в топик "Спаркса", по пока что побуду здесь.
Нужна рекомендация опытных товарищей.
Имеем …
Есть набор состояний системы.
Есть скрипты, вызывающие переходы состояний.
Есть реперные точки, означающие, что переход завершен успешно.
Есть выходы по успеху и сбою.
С этим всё понятно, нужные виды диаграмм UML выбраны, изучены, мышкой поюзаны, в программе валидированы и даже в пробной документации распечатаны. Красота.
Есть набор готовых классификаторов – системы, таблицы, пользователи, роли … потихонечку завел.
Теперь о том, во что въехать не могу.
Есть набор статических и динамических настроек, от которых собственно и зависит - успешен ли переход из одного состояния в другое. Список этот непрерывно расширяется.
Для простоты - избитый кейс. Заказ через интернет.
Есть:
- Покупатель
- Оператор
- Сайт
- ERP
- Склад
- Транспортная компания
Покупатель утверждает заказ на сайте.
Сайт передает утвержденный заказ в ERP
Оператор связывается с покупателем .. пошли вилки "Заказ подтвержден / нет"
Оператор подтверждает заказ на сайте.
Сайт передает подтвержденный заказ в ERP
ERP меняет статус и отправляет заказ на сбоку на склад
…..
Склад передает собранный заказ Транспортной компании
.....
Покупатель получает товар от Транспортной компании ... пошли вилки кейса на брак/не брак, отказы по размеру ….
....
Покупатель может изменить или отменить заказ на сайте. ОП !!!! Нельзя изменить заказ в статусе "Передан в ТК" - он уже уехал.
Да короче ничего тут нового никем не изобретено.
Набор статусов заказа естественно есть. Матрица допустимых переходов статуса (см. «ОП») - тоже.
Собственно, вопросы.
1. По нотации UML вообще.
Не выходит сходу применить какой-то объект (артефакт) для отображения хранилища подобных настроечных таблиц. Не хватает ни опыта, ни фантазии. В BPMN (простите за сравнение) для этого ставится связь с внешней БД и на ее атрибутах всё оформляется. После чего отлично попадает в распечатки документации. В UML же (для данного кейса, я так понимаю, используем Диаграмму Состояний, точнее набор этих диаграмм под каждый юз-кейс), судя по прочитанной литературе, подобные вещи просто выносятся в описания связей. В этом случае я упираюсь в сопровождение созданных моделей. При вводе каждого нового настроечного параметра или статуса нужно будет пересматривать и актуализировать ВСЕ схемы. Это война и всех вешать сразу.
2. По Спарксу конкретно
Как-то глаза еще разбегаются во все стороны и приходится себя одергивать от попыток построить диаграмму Ганта или написать таки за ночь очередной Тетрис или Прогноз Погоды для Андроид.
При этом найти собственно вариант хранилища упомянутых настроек (фактически, системный реестр или MAIN.INI всей модели) чтобы бросать на него ссылки с диаграмм не получается.
Буду признателен за подсказку.