Уважаемые аналитики, проектировщики. Обращаюсь за помощью и вариантами.

Нужно придумать хорошую диаграмму изменения состояний заявки в ходе ее жизненного цикла.

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

Далее пользователь берет одну из заявок в работу, т.е. переводит ее в состояние На экспертизе. При этом заявка доступна только этому пользователю для изменения. В состоянии Предложена и На экспертизе заявка не должна находится больше месяца, т.е. в течение месяца заявка должна быть Принята или Отклонена(отправлена на доработку)

При переводе заявки в состояние На экспертизу система может проверять а нет ли у данного пользователя других работ не прошедших экспертизу (т.е. в состоянии На экспертизу) или в состоянии Предложена, но дата регистрации которых раньше чем вот эта заявка.

После проведения экспертизы, т.е. выставлена оценка, определены доп параметры, пользователь переводит заявку в состояние Принята или Прошла экспертизу либо Отклонена или На доработку.

При переводе в состояние Прошла экспертизу опубликовать результаты на сайте. После публикации заявка переход в состояние Опубликована на сйте и предлагает сгенерировать ответ Автору. Если по какой-то причине публикация на сайте не состоялась заявка сохраняется с сотоянием Прошла экспертизу, но опевещает затем пользователя о том что заявка неопубликована и по ней нет ответа автору

Если переводим в состояние Отклонена - генерируется запрос на создание ответа автору. Если ответ сделан заявка переходт в состояние Отправлен ответ, если нет остается в состоянии Отклонена и потом оповещает, что ответа автору не было

Если заявка находится в состоянии Опубликована на сайте а ответа автору нет, идет оповещение пользователя до тех пор пока ответ не будет создан. После ответа автору заявка переход в состояние Отправлен ответ - изненный цикл завершен.

После доработки заявки из состояния Отклонена с доп состоянием Отправлен ответ, заявка можно перевести в состояние предложена но уже с новой датой регистрации.

У какого какие предложения и варианты? На все доп вопросы отвечу и с удовольствием...

Попробуй нарисовать в виде Д Состояний.

Нужно придумать хорошую диаграмму изменения состояний заявки в ходе ее жизненного цикла.

Диаграмму автомата

Сначала вопросы и комментарии

При этом заявка доступна только этому пользователю для изменения.

В чистом виде это нельзя показать на диаграмме автомата. Только в примечании

В состоянии Предложена и На экспертизе заявка не должна находится больше месяца, т.е. в течение месяца заявка должна быть Принята или Отклонена(отправлена на доработку)

Что произойдет через месяц, если заявка не будет принята или отклонена?

При переводе заявки в состояние На экспертизу система может проверять а нет ли у данного пользователя других работ не прошедших экспертизу (т.е. в состоянии На экспертизу) или в состоянии Предложена, но дата регистрации которых раньше чем вот эта заявка.

И что в этом случае будет с заявкой?

... в состояние Принята или Прошла экспертизу

Это два варианта одного названия?

... либо Отклонена или На доработку.

Это два варианта одного названия?

После ответа автору заявка переход в состояние Отправлен ответ - изненный цикл завершен.

Зачем надо такое состояние?


В приложении пересказ того что ты написал в виде диаграммы автомата. Обрати внимание на красные стрелки. Это то, что не определено.

Денис спасибо. У меня был иной вариант. Но обдумывая его я почти пришел к твоему варианту. Но меня смущало, то что приходится вводит две машины состояний с почти одинаковыми состояниями. А также тот факт, что как я понимаю неважен путь попадания в состояние.

В чистом виде это нельзя показать на диаграмме автомата. Только в примечании

Согласен, я на это и не настаивал.
Хотя это мог бы быть некий атрибут состояния, вернее знчение данного атрибута, который проверяется?

Цитата: Galogen от Февраля 04, 2009, 06:49:03 pm
В состоянии Предложена и На экспертизе заявка не должна находится больше месяца, т.е. в течение месяца заявка должна быть Принята или Отклонена(отправлена на доработку)
Что произойдет через месяц, если заявка не будет принята или отклонена?

в моей ситуации в общем ничего, кроме того, что система должна будет оповещать пользователя о том, что работы не сделаны. Хотя предполагается избегать ситуации с просроченными работами. Это означает не исполнения своих обязаностей. Единственное что можно предусмотреть возможность перераспределения работы между экспертами-пользователями
Если работа отклонена - то она ждет своей очереди. Тут лучше говорить не об Отклонена, а отправлена на Доработку. Вознобновление работы будет приводить к смене даты регистрации такой отклонненой работы
Судьбу отклонненых работы пользователь может решать сам - например просто удалить в последствии

И что в этом случае будет с заявкой?

Ну ничего особенного заявка останется в исходном состоянии. Т.е. система спрашивает вас - вы уверены то хотите начать экспертизу этой работы, а не той которая уже на экспертизе? Можно придумать следующий момент - имеющаяся на экспертизе работа переходит в состояние Ожидания, а новая работа передается в состояние На экспертизе, после проведения экспертизе, та старая работа автоматом переходит в состояние На экспертизе

Это два варианта одного названия?

Принята думаю не удачно - лучше просто Прошла экспертизу, Оценена. Принята неоднознано интерпертируется

Это два варианта одного названия?

Да это варианты - наверное На доработку лучше. поскольку наша цель не просто оценить работу, но и обеспечить, чтобы каждая работа была доведена до конца и с приемлемым качеством

Зачем надо такое состояние?

Поясню. По правилам игры эксперт обязан ответить автору о результатах экспертизы. Причем как показывает практика именно этот процесс занимает чаще всего наибольшее время. Однако эксперт неявляется освобожденной ролью, он совмещает свои обязанности. Возможна ситуация когда эксперт проверли заявку и оценил ее, но не успел ответить, или ответу помешали технические условия. Чтобы не забыть о том, то данному автору не ответили и нужна напоминалка.
Сейчас я полагаю, что возможно опубликовано на сайте и оправлен ответ = суть не состояния но некие атрибуты состояния?

В приложении пересказ того что ты написал в виде диаграммы автомата. Обрати внимание на красные стрелки. Это то, что не определено.

Да вижу.

Хорошая диаграмма. А интересно, моя задача - это протокольный или поведенческий автомат?
Мне думается нужно для состояния Предложена обеспечить на входе выставление даты = текущей даты.
 Тут вот моя начальная диаграмма без прекрас и доработок

Да вот формы реализации заявки.

Тут еще есть что обдумать: например запрет смены рег номера и типа, если уже добавлены файлы. Так как файлы закачиваются в репозиторий и хранятся под рег номером, потому следует сначала удалить саму папку с файлами прежде чем менять рег номер коли в этом появится потребность

... Но меня смущало, то что приходится вводит две машины состояний с почти одинаковыми состояниями.

Состояние - не классификатор и поэтому не может иметь экземпяры или участвовать в отношении обобщения. Однако в UML есть прием, позволяющий до некоторой степени решить эту проблему. Можно расширять уже существующее составное состояние, но в данном контексте это не работает.

Хотя это мог бы быть некий атрибут состояния, вернее знчение данного атрибута, который проверяется?

Проблема в том, что диаграмма состояний относится к заявке, а ты хочешь припутать сюда еще и пользователя.
Можно сделать диаграмму автомата для двух сущностей (заявки и пользователя). Это будет одно составое состояния в котором параллельно будут жить эти две сущности (каждая со своим жизненным циклом) и некоторым образом синхронизируются.

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

Тут несоответствие. Мы же рисуем диаграмму состояний заявки. А ты говоришь о системе. Через 1 месяц простоя с заявкой должно что-то произойти, т.е. она должна менить состояние или остаться в прежнем.

Ну ничего особенного заявка останется в исходном состоянии. Т.е. система спрашивает вас - вы уверены то хотите начать экспертизу этой работы, а не той которая уже на экспертизе? Можно придумать следующий момент - имеющаяся на экспертизе работа переходит в состояние Ожидания, а новая работа передается в состояние На экспертизе, после проведения экспертизе, та старая работа автоматом переходит в состояние На экспертизе

Тут очень сильно мешает алгоритм, который ты описываешь. Может надо все-таки рисовать диаграмму деятельности и на ней уже указать при каких событиях в какие состояния переходит заявка? Это возможно сделать.
Т.е. за основу взять не диаграмму автомата как сейчас, а диаграмму деятельности.
Кстати заметь, что деятельность - это частный случай состояния. Деятельность - это по сути простое (не составное) состояние, с переходом по завершении, т.е. по сути то что у нас на диаграмме и есть.

А интересно, моя задача - это протокольный или поведенческий автомат?

Чем протокольный автомат отличается от поведенческого? Чисто внешне различие такое. На переходах ты можешь указывать пред- и пост-условия. Если ты можешь это сделать - это протокольный автомат. Иначе - поведенческий.

Такие задачи решают в таких языках имитационных моделирований как в РДО, GPSS и т.д. Рекомендую наш форум: http://rdo.rk9.bmstu.ru/forum/

Если верить стандарту UML (в текущей версии), то:
Class
A
|
Behavior
A
|
StateMachine
Если верить в принцип Барбары Лизковы, то StateMachine-ы можно соединять обобщениями (и ассоциациями). Возможно, что авторы нотации расширяемых StateMachine не верят в ПрБЛ или в стандарт и потому изобрели свой велосипед.
Выше верно отмечено, что State не может участвовать в обобщениях. Но у некоторых State может быть вложенная StateMachine. А вот она-то может участвовать в обобщениях и её потомок может рассматриваться как сама вложенная StateMachine. От открывающихся перспектив по построению конструкций, которые затруднительно будет осмыслить, у меня захватывает дух. Поэтому умолкаю.
Ещё один повод замолчать в том, что ни один из участников ветки так ничего и не нарисовал. Уверено, что расширяемые состояния для моделирования не потребовались бы.
Дальше немного трындежа:
+ Пользователь, которого надо чекать, может передаваться как параметр в сообщении. Сторожевое условие -- проверка параметра сообщения на равенство со ссылкой на пользователя из самой заявки -- вполне себе всё моделирует.
+ Так как на диаграмме можно предусмотреть событие относительного времени и переход по нему, то можно отлавливать истечение месяца и реакцию на это.
+ Протокольный автомат ломается, если что-то пошло не так. Поведенческий просто игнорит не предусмотренные события и продолжает жить припеваючи.