Форум Сообщества Аналитиков

×


Требуется вводный пинок в моделирование на UML.(Прочитано 27239 раз)
Речь о подобном?
http://www.sparxsystems.com/enterprise_architect_user_guide/12.0/modeling_basics/connect_to_element_feature.html

Да, спасибо.

Я выше упоминал, что смотрел триальную версию Спаркса, кое-что порадовало, но он для меня чуть дороговат. Бюджет - личный на данный момент, а по текущему курсу он тянет на 12 тысяч за corporate edition + что-то около 22 тысяч за курс в "Интерфейсе" (либо нужен внятный мануал, Tutorial на сайте не особо впечатлил).

Не то, чтобы не потяну, но ... думаю пока что короче.
« Последнее редактирование: 07 Мая 2015, 11:18:14 от Андрей Сенченко »



Коллеги, доброго времени суток.
В результате плодотворной договорной работы с собственной жабой купил я себе на премию EA 12 Corporate ed., ибо интересно.
Не было заботы....   
Напомню суть топика.
Неторопливо изучаю UML посредством перевода имеющейся проектной документации в единый стандарт. Выхода на генерацию программного кода не планирую и вряд ли до этого вообще дойду. Максимальная цель - сопровождаемое документирование проекта.

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

Имеем …
Есть набор состояний системы.
Есть скрипты, вызывающие переходы состояний.
Есть реперные точки, означающие, что переход завершен успешно.
Есть выходы по успеху и сбою.
С этим всё понятно, нужные виды диаграмм UML выбраны, изучены, мышкой поюзаны, в программе валидированы и даже в пробной документации распечатаны. Красота.
Есть набор готовых классификаторов – системы, таблицы, пользователи, роли …  потихонечку завел.

Теперь о том, во что въехать не могу.
Есть набор статических и динамических настроек, от которых собственно и зависит - успешен ли переход из одного состояния в другое. Список этот непрерывно расширяется.

Для простоты - избитый кейс. Заказ через интернет.

Есть:
- Покупатель
- Оператор
- Сайт
- ERP
- Склад
- Транспортная компания

Покупатель утверждает заказ на сайте.
Сайт передает утвержденный заказ в ERP
Оператор связывается с покупателем .. пошли вилки "Заказ подтвержден / нет"
Оператор подтверждает заказ на сайте.
Сайт передает подтвержденный заказ в ERP
ERP меняет статус и отправляет заказ на сбоку на склад
…..
Склад передает собранный заказ Транспортной компании
.....
Покупатель получает товар от Транспортной компании ... пошли вилки кейса на брак/не брак, отказы по размеру ….
....
Покупатель может изменить или отменить заказ на сайте. ОП !!!! Нельзя изменить заказ в статусе "Передан в ТК" - он уже уехал.

Да короче ничего тут нового никем не изобретено.
Набор статусов заказа естественно есть. Матрица допустимых переходов статуса (см. «ОП») - тоже.

Собственно, вопросы.
1.   По нотации UML вообще.
Не выходит сходу применить какой-то объект (артефакт) для отображения хранилища подобных настроечных таблиц. Не хватает ни опыта, ни фантазии. В BPMN (простите за сравнение) для этого ставится связь с внешней БД и на ее атрибутах всё оформляется. После чего отлично попадает в распечатки документации. В UML же (для данного кейса, я так понимаю, используем Диаграмму Состояний, точнее набор этих диаграмм под каждый юз-кейс), судя по прочитанной литературе, подобные вещи просто выносятся в описания связей. В этом случае я упираюсь в сопровождение созданных моделей. При вводе каждого нового настроечного параметра или статуса нужно будет пересматривать и актуализировать ВСЕ схемы. Это война и всех вешать сразу.
2.   По Спарксу конкретно
Как-то глаза еще разбегаются во все стороны и приходится себя одергивать от попыток построить диаграмму Ганта или написать таки за ночь очередной Тетрис или Прогноз Погоды для Андроид.
При этом найти собственно вариант хранилища упомянутых настроек (фактически, системный реестр или MAIN.INI всей модели) чтобы бросать на него ссылки с диаграмм не получается.
Буду признателен за подсказку.



Очень большая задача, для глубокого мотивированного погружения. Если бы Вы их разделили на более мелкие и обособленные и описание -вопрос для каждой сформулировали отдельно, было бы 100 крат лучше.

Если честно я задачу не понял, но что едва понял, скорее всего может решаться множеством способов, но лучший из них (возможно задачу то я не понял, лишь как-то интуитивно допетрил) возможно создание UML профиля (смотрим в сторону MDG технологии). Либо это тегированные значения.

Я бы мог поучаствовать в эксперименте. Обладатель ЕА с 2008 (или даже 2007) года. Особенно если бы Вы прислали бы свой проект, ну или просто выложили его в общей шаре на гугль диске или яндексдиске или энифинг элз.



Привет. Мы хотим дворец. Но бюджет у нас только на гараж.
Звучит примерно так ))

Если предметно: Enterprise Architect либо MagicDraw, uml 2.0. ОО моделирование и разработка

Все остальное либо тяжелое, либо поверхностное, либо неудобное.



Если честно я задачу не понял, но что едва понял, скорее всего может решаться множеством способов, но лучший из них (возможно задачу то я не понял, лишь как-то интуитивно допетрил) возможно создание UML профиля (смотрим в сторону MDG технологии). Либо это тегированные значения.

Ну да.
Правильный вопрос содержит 90% ответа.

В скрепке - на скорую руку набросанная BPM схема в Bizagi


На объекте "Хранилище данных" введен расширенный атрибут типа "Таблица".
В этой таблице лежат собственно правила, на которые опирается задача "Проверить возможность изменения" для выдачи "Да" или "Нет" на гейт "Разрешено ?"
Таблица полностью соответствует реальной настроечной таблице приложения.

Чем всё это мне полезно.
Реальные настройки хранятся не только в боевой базе, но и на модели. В явном виде. И могут быть использованы в разных схемах.
В случае добавления новых правил в эту таблицу - они сразу будут доступны для всех схем. Нужно будет только перепечатать документацию при необходимости. А если все остальные атрибуты модели заполнены - то и для прогона.
Ну и поиск связанных процессов упрощается. В плане "Где аукнется изменение".

В общем я тут по дороге почитал EAUserGuide12, нашел работу с бизнес-правилами.
Также нашел, что они есть только в ultimate версии.
« Последнее редактирование: 17 Сентября 2015, 12:37:25 от Андрей Сенченко »



Мотивация очень проста.
Я хочу  знать возможности и инструментарий смежных со своей отраслей народного хозяйства.
Чтобы не соскребать с ушей лапшу вида "невозможно" на месте "не умеем" или "не хотим"
Ну и понимать нормировки рабочего времени

Лучший на мой взгляд способ - сделать что-то самому.
А для этого лучше брать не вымышленные модели, а реальные задачи.
« Последнее редактирование: 17 Сентября 2015, 12:28:48 от Андрей Сенченко »



Я хочу  знать возможности и инструментарий смежных со своей отраслей народного хозяйства.
Чтобы не соскребать с ушей лапшу вида "невозможно" на месте "не умеем" или "не хотим"
Ну и понимать нормировки рабочего времени
Это все в нашей отрасли хотят )))
Невротическая потребность в контроле за всем и вся - следствие недоверия к миру, а недоверие к миру - следствие недоверия к себе. Поэтому неврот пожизненно разбирается в избранной области и ему все время кажется, что он еще не все знает или чего-то недопонял - и очень много говорит на эту тему))
Куда как приятнее работать с психопатами и истериками.



Андрей, ЕА поддерживает BPMN.Если Вы об этом, Вы вполне можете транслировать подобие туда. Изучив возможности инструмента в этом аспекте.

Если же Вы пытаетесь, то, что возможно в BPMN переложить на UML, то скорее всего Вас постигнет разочарование. НО ... внимание, я все равно не догоняю, что нужно.

Почему Вы полагаете, что БП Вам помогут?



2 Андрей Сенченко
У меня мало опыта, но может Object Constraint Language (OCL) поможет ?
Констрейны в модели можно собирать в отдельный отчет, что и будет вашим MAIN.INI

 
« Последнее редактирование: 18 Сентября 2015, 18:39:25 от anton morozov »
Skype: m0roz0v




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19