1

Системный Анализ и Требования / Диаграмма состояний

« : 23 Апреля 2021, 07:47:01 »

Коллеги,

прошу указать на ошибки в диаграмме состояний и помочь разобраться со следующими вопросами:
1. Как корректно отобразить для состояния «Сформировано», что Exit/заблокировать на редактирование произойдет только при переходе в статус «Отправлено»?
2. При переходе из статуса «Отправлено» в статус «Возвращено» для переходов «[подтвердить формирование РПРО]» и «[отклонить формирование РПРО]» нужно ли каким-либо образом указывать, что такие переходы возможны только если уведомление №14. Если нужно, то как это возможно отобразить?

См. https://drive.google.com/file/d/1nWpscVUFWoQpNQ4RzAX8XWokCmRf8L8m/view?usp=sharing
Пояснения к диаграмме:
1. При сохранении уведомления о наличии налоговой задолженности (уведомление) система проверяет наличие ошибок
2. Инспектор может сохранить уведомление с ошибками (статус Ошибочное) или без ошибок (статус Сформировано)
3. Инспектор может отредактировать уведомление в любом из вышеперечисленных статусов и сохранить его, опять же система проверит наличие ошибок и уведомление возможно будет сохранить с ошибками либо без ошибок
4. Инспектор может удалить уведомление в обоих статусах Ошибочное либо Сформировано
5. Инспектор отправляет уведомление со статусом «Сформировано» налогоплательщику одним из трех способов: заказной почтой, нарочно или по электронному каналу (ЭК) (статус Отправлено).
6. Если уведомление было направлено по ЭК информационную систему (ВИС), т.е. параллельно направляет запросы в две системы ПЭП и КНП и ждет получение ответа о доставке хотя бы от одной из них.
7. При получении ответа о доставке от ВИС присваивает уведомлению статус в зависимости от того из какой системы первым получен ответ о доставке (статус Доставлено в КНП или статус «Доставлено в ПЭП»).
8. Система ожидает получение сообщения об ознакомлении (в установленные сроки) от ВИС, из которой был получен первый ответ о доставке. При истечении установленного времени и получении или НЕ получении сообщения об ознакомлении от ВИС , а также, если инспектор в период ожидания получения сообщения об ознакомлении отмечает доставку уведомления система присваивает уведомлению статус «Доставлено»
9. В процессе доставки в ВИС уведомление в любом статусе может быть отменено (статус Отменено) 
10. Для доставленного уведомления (статус Доставлено) инспектор может сделать отметку об исполнении (статус «Исполнено») либо отметку о неисполнении (статус Не исполнено)
11. Для уведомления в статусе «Отправлено» инспектор может выполнить одно из следующих действий: [подтвердить формирование РПРО], [отметить возврат уведомления], [отклонить формирование РПРО], что приведет к смене статуса уведомления на «Возвращено»

2

Методологии / Re: Обзор методологий

« : 08 Апреля 2015, 12:04:55 »

Предлагай артефакт. С описанием его содержания или ссылкой на оное.

Предлагаю начать с области знания Enterprise Analysis артефакт: Business need https://drive.google.com/file/d/0B6-Yeg85Oh9jMWRSMlJhT2pTZms/view?usp=sharing стр. 81

3

Методологии / Re: Обзор методологий

« : 08 Апреля 2015, 06:16:28 »

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

Леонид, конечно делись. А там посмотрим поможет или нет 

4

Методологии / Re: Обзор методологий

« : 08 Апреля 2015, 06:11:38 »

greesha, касательно Вигерса и ГОСТа твое мнение понятно хоть и требует обсуждения, но мы уже глубоко в детали проваливаемся, т.е пытаемся некую часть маппинга сделать. На мой взгляд, формат форума для такой работы не очень подходит, можно, но не очень удобно. Да и цели такой не было, но никто не мешает нам ее поставить и организовать совместную работу над данной инициативой. А пример я привела, чтобы  попытаться пояснить, что хотелось бы получить на выходе.

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

А ни кто и не говорил, что это легко 

Проблема в том, что эти объяснения либо проигнорируют, либо неправильно поймут.

Откуда такой скепсис?

А если ты об этом ещё и расскажешь на ЛАФ, то будет вообще чрезвычайно круто!

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

5

Методологии / Re: Обзор методологий

« : 07 Апреля 2015, 13:34:53 »

greesha, твое мнение понятно и статья очень интересная. От части то, о чем ты пишешь... ловушки, терминология, уровни абстракции требований и  побудило сделать этакое нечто, что помогло бы тем, кто не так долго работает в области бизнес анализа или тем, кто имеет опыт работы только в одной, двух методологии (ях)/стандарте, разобраться пусть не во всех, но многих хитросплетениях различных подходов. Я не надеялась смаппить артефакты 1х1. Мне бы хотелось, чтобы говоря в терминах BABOK ассоциативно возникало понимание в какой из артефактов ГОСТ/RUP это включается или НЕ включается (отсутствует) и каким термином оно в ГОСТе/RUP обозначется. В свое время Юрий Булуй делился своей презентацией под названием "Классификация требований к ПО и ее представление в стандартах и методологиях", в рамках которой, не смотря на то, что упор в ней делается больше на требования, я нашла любопытные для себя материалы. Приведу вырезку (см. вложение). Вот что то подобное хотелось бы сделать.

6

Методологии / Re: Обзор методологий

« : 07 Апреля 2015, 10:30:53 »

Добрый день.

Думала в какую бы тему написать, остановилась на этой.

В разных темах форума и в разные периоды обсуждались отличия различных методологий разработки ПО, в том числе и в разрабатываемых артефактах. Возникла необходимость смаппить артефакты RUP и ГОСТ на артефакты нашумевшего BABOK. Виталий как то высказывался по поводу того, что: " в RUP уже все есть и даже больше". К сожалению, не смогла найти такого целостного анализа в открытом доступе. Возможно, кто-то нечто подобное уже делал и может поделиться материалыми или ссылками на источники. Была бы очень благодарна

7

UML SysML и пр. / Re: Помогите пожалуйста посторить диаграмму состояний

« : 23 Апреля 2013, 08:28:35 »

Хм... Здесь есть интересный момент. Дело в том, что Заявка может 1. поступить из внешней системы и 2. может быть зарегистрирована сотрудником, принявшем ее на бумажном носителе (далее варианты возникновения Заявки в системе). Вы приводите в пример второй вариант.

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

Если рассматривать второй случай, то пользователь предварительно может создать заявку в состоянии "Черновика", а вот потом нажать кнопку SUBMIT для того, чтобы отправить заявку на регистрацию. Здесь в качестве события вижу "Отправить на регистрацию" и переход в состояние "Ожидает регистрации".

Я попыталась унифицировать статусы Заявки для обоих вариантов, может быть поэтому сейчас есть непонимание или некорректности?

Что касается вопроса:

Далее
Поступает из внешней системы сообщение с результатом обработки и заявка из В работе переходит в Исполнено - это кажется нормальным, но почему из Исполнено по тому же самому событию (как оно вообще возникнет в этом случае) переход в Ожидает выдаче, а еще дальше по тому же событию + еще иному в Закрыта - это не понятно

Действительно... Немного подправила заданный автомат (см. вложение).
В качестве пояснения:
Есть заявки, по которым результат обработки не должен быть выдан нарочно. Для таких заявок переход из состояния «Исполнена» в состояние «Закрыта» будет осуществляться без перехода в состояние «Ожидает выдачи».
Для заявок, результат обработки которых требует выдачи нарочно из состояния «Исполнена» заявка переходит в состояние «Ожидает выдачи» (по событию «Получения сообщения с подтверждением о получении результата обработки заявки» из внешней системы), а по событию «Ввод даты фактической выдачи» переводит заявку из состояния «»Ожидает выдачи» в состояние «Закрыта».

8

UML SysML и пр. / Re: Помогите пожалуйста посторить диаграмму состояний

« : 22 Апреля 2013, 16:23:11 »

Попыталась по рекомендации Galogen задать автомат для объекта Заявка (см. вложение). Что то меня в нем смущает. В правильном ли направлении я двигаюсь?

9

UML SysML и пр. / Re: Помогите пожалуйста посторить диаграмму состояний

« : 18 Апреля 2013, 13:45:18 »

А почему результат обработки заявки рассматривается как отдельный объект?

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

Состояние - это набор значений и связей объекта (набор значений атрибутов иными словами). Пусть у вашей заявки есть атрибут Статус = каким то статусам, и вдруг есть еще флаг = логический. Ясно, что сочетание этих значений и определяет отдельное состояние.

Как это отражается на диаграмме состояний?

Но заявку можно рассматривать по-разному.
Скажем если для заявки важны
Не просрочена
и Просрочена - то мы имеем два состояния. Нахождение в 1 начинается при создании заявки и прохождению по ее ЖЦ, пока не возникнет событие времени after(установленный срок). При наступлении этого событие каждая заявка из состояния Не просрочена перейдет в Просрочена с каким то важным результатом

Говорит ли это о том, что в этом случае для объекта Заявка должны быть разработаны две диаграммы состояний? Одна для статусов Черновик... Зарегистрирована... и вторая со статусами Просрочена, Не просрочена?

Правда не понятно зачем нужно состояние Не просрочена, достаточно иметь состояние Просрочена.

Для того, чтобы отразить начальное состояние для отсчета срока обработки заявки. Т.е. есть правило, что заявка должна быть обработана в течение 10 дней. Отсчет срока начинается после того, как она будет зарегистрирована. Здесь я ввожу подсостояние "Не просрочена". Если это не верно, то прошу подсказать как надо?

Однако вопрос - а что у вас происходит с просроченной заявкой? Она продолжает выполняться?

Она продолжает выполняться. Однако исполнителю сыпятся уведомления о необходимости ее обработать.

10

Обучение / Re: Требуются задачи на моделирование конечных автоматов или диаграмм состояний

« : 17 Апреля 2013, 12:44:03 »

Почему я хотела отобразить это на одной диаграмме, именно для того, чтобы показать зависимость между статусом "Зарегистрирована" и возникновением подстатуса "Не просрочена". Если это можно показать иначе, то как? Действительно подстатус "Просрочена / не просрочена" будет вестись в отдельном поле и будет использоваться для формирования отчетности типа: Общее количество заявок принятых за период, из них n выполнены в срок, m выполнены с просрочкой, а так же как способ контроля за сроками исполнения заявок.

11

Обучение / Re: Требуются задачи на моделирование конечных автоматов или диаграмм состояний

« : 17 Апреля 2013, 07:08:55 »

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

12

UML SysML и пр. / Re: Помогите пожалуйста посторить диаграмму состояний

« : 16 Апреля 2013, 07:38:21 »

Коллеги, добрый день.

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

Мне необходимо:
1. Показать как изменяется состояние "Заявки" в зависимости от изменения состояния "Результата обработки заявки" 
2. Показать подсостояния для Заявки: "Непросрочена" и "Просрочена" при условии того, что состояние "Непросрочена" возникает после состояния заявки "Зарегистрирована", а статус "Просрочена" будет возникать только по событию истечения установленного срока обработки заявки при этом состояние Заявки "Закрыта" должна зафиксировать статус "Непросрочена" в случае если Заявка перешла в состояние "Закрыта" и при этом срок обработки заявки не истек.

13

Обучение / Re: Требуются задачи на моделирование конечных автоматов или диаграмм состояний

« : 15 Апреля 2013, 16:19:54 »

Коллеги, добрый день.

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

Мне необходимо:
1. Показать как изменяется состояние "Заявки" в зависимости от изменения состояния "Результата обработки заявки" 
2. Показать подсостояния для Заявки: "Непросрочена" и "Просрочена" при условии того, что состояние "Непросрочена" возникает после состояния заявки "Зарегистрирована", а статус "Просрочена" будет возникать только по событию истечения установленного срока обработки заявки при этом состояние Заявки "Закрыта" должна зафиксировать статус "Непросрочена" в случае если Заявка перешла в состояние "Закрыта" и при этом срок обработки заявки не истек.

14

Примеры / Re: Помогите построить диаграмму sequence

« : 08 Июля 2011, 11:58:14 »

Виктор, спасибо за информацию, начало проясняться. 

15

Примеры / Re: Помогите построить диаграмму sequence

« : 08 Июля 2011, 11:40:03 »

Всем спасибо за ответы.

Galogen, попытаюсь объяснить подробней, что я хочу отобразить...
Существует очередь сообщений, из которой производится отправка сообщений в бизнес логику BizTalk. Отправка осуществляется ReceivePort, это один из компонентов продукта BizTalk, который берет сообщения из очереди (не сам напрямую, так не совсем верно, а посредством хранимой процедуры, поэтому я отобразила отдельный объект на диаграмме), так вот, сообщения должны отправляться не просто по порядку, как они лежат в очереди, а по определенному алгоритму, который я пытаюсь отобразить. После того как определено какое сообщение должно быть отправлено, ReceivePort посредством все той же хранимой процедуры производит его отправку в бизнес логику BizTalk.

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

Вы написали: "Если то, что вы написали - есть вариант использования, то что-то в нем явно не так". Подскажите, что не так если я пытаюсь описать именно вариант использования?