Добрый день!

    Учусь в университете. Преподавать поставил нетривиальную как для новичков задачу: спроектировать систему (у каждого своя) в соответствии с нотацией UML. Вроде бы трудностей не возникало до последнее момента, пока очередь не подошла моделировать диаграмму состояний.
   Я не знаю как отразить множество объектов и их состояния на одной диаграмме. Изначально я построил диаграмму состояния для одного ключевого класса, думал, этого будет достаточно, но преподаватель поставил задачу создать одну диаграмму состояния для всей системы. Вот тут и начались трудности...

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

     Прилагаю диаграмму классов, чтобы было легче что-то порекомендовать.
 

Да, не позавидуешь!

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

Другое дело, что полная система, как объект, может иметь собственные состояния, которые определяют, что система может делать в каждом состоянии. Может быть, это имелось ввиду?

Рисовать на одной диаграмме состояний множество объектов - элементов системы - нонсенс.

Другое дело, что полная система, как объект, может иметь собственные состояния, которые определяют, что система может делать в каждом состоянии. Может быть, это имелось ввиду?

  Да, возможно, я некорректно выразился.  В любом случае это не облегчает задание. Я не знаю с чего начать. И в каких состояниях моя автоматизированная система сервис-центра может пребывать для меня тоже вопрос. Как отобразить классы на ней? В общем, придется поломать мозг.
   
      Может быт у Вас есть несколько примеров? Буду очень благодарен.   
     

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

Ion, смотри все просто.

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

Если рассматривать так - ну глупо, потому нужно посмотреть, на конркетные классы и найти жертву.
В принципе каждый класс может быть жертвой, но в реальности не все.

Вообще нужно смотреть на такой класс, вернее объект класса, у которого есть ИЗМЕНЯЕМЫЕ во времени значения атрибутов.
В твоем случае, например может быть ЗАКАЗ. Я там не присматривался, но заказ может быть
-- предложен, размещен, новый
-- одобрен, взят в разработку, в работе, выполняется, оценивается и т.п.
-- выполнен
-- отклонен
-- оплачен
и т.п.

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

Далее нужно описать из какого состояния куда можно попасть, и что может происходить при этом.

Поищи на uml-diagrams.org ну и google тебе в поиск

     Galogen, спасибо! 

  У меня появилась идея. Изначально я описал объект класса, который имеет решающее значение для моей системы, указал состояния, которые ему присущи, как они изменяются во времени.

  Это был хороший комментарий относительно того, что система в простом случаем может быть включена или выключена.       

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

Спасибо за ресурс. Очень информативный. 
     
        Приатачилл диаграмму состояний для моего объекта класса. На ее основе буду строить диаграмму для всей системы.       
     
           
               

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

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

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

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

1. Показать как изменяется состояние "Заявки" в зависимости от изменения состояния "Результата обработки заявки" 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все это РАЗНЫЕ объекты. КАк состояние талона (и какие они могут быть?) влияет на состояние заявки?

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

это и есть само состояние - фиксированный набор значений атрибутов и связей объекта

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

Это зависит от целей моделирования и специфицирования. Но я не вижу оснований для противопоставления одной группы состояний другой.

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

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

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

Ну и что.
смотрите Запланирована - (бла бла) - Выполняется -- прошло 10 дней) - Просрочена (слать нотификацию пока ...) - Выполнена
Или Запланирована - (прошло 10 дней) -  Просрочена (слать нотификацию пока ...) - Выполнена
или Запланирована - (прошло 10 дней) -  Просрочена (слать нотификацию пока ...) - Отменена
чем плохо?

А как было бы всем проще, если бы, невыёживаясь, сначала построили таблицу переходов по состояниям: )

А как было бы всем проще, если бы, невыёживаясь, сначала построили таблицу переходов по состояниям: )

Так я девушке это предлагал. Но ...

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

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

И неслучайно.

У вас события и состояния перемешаны.

Пример: Принято от заявителя - это событие, а состояние в котором она будет висеть Ожидает регистрации, т.е.

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

Для того, чтобы понять это
1. задайте, те параметры которые у вас определяют состояние. Совокупность этих параметров одна для конкретного автомата. Статус - не очень хороший параметр, поскольку его значение и есть состояние,
2 для каждого вашего состояния - их ведь немного, задайте значения этих параметров

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