В течение ряда лет я преподаю дисциплину по кодовым названием Моделирование систем.

В рамках оной мы изучаем различные математические модели в соответствии с учебником Советова с такми же названием. Моделирование моделей производится в хорошо известной среде MatLab. В первую очередь  мы используем среду визуального моделирования Simulink.

Среди развитых инструментов Simulink имеется расширение StateFlow, представляющее собой графическую среду моделирования конечных автоматов, основанную на карта Харела - прямой аналог диаграмм состояний в UML. Думаю, диаграммы состояний были реализованы на основе карт Харела.

У меня есть несколько задач на использование концепции StateFlow для изучения детерминированного и вероятностного конечных автоматов.

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

Диаграммы состояний в UML применяются для описания поведения объекта или системы в целом. Таким образом, можно связать формирование диаграмм состояний с их имитационным моделированием в StateFlow.

Но что-то не придумывается как это сделать.

Конечно мы можем описать работу скажем автомата выдачи билета в нотациях UML - перенсти диаграмму состояний в SateFlow и задав рабочую нагрузку промоделировать ситуацию. Но хотелось бы ближе к реалиям программирования и информационных систем.

Есть какие-то идеи? Задачки ? Прошу публиковать здесь. Их реализацию будут пытаться сделать и публиковать результаты.

И тишина! Хоть бы критику что ли навели, а то просто игнорируем. Это не в традициях нашего форума

Эд, я бы с удовольствием, но как в начале разбора темы про МУ, я по этому тексту не очень понимаю, чего ты хочешь.
Если задач из жизни на конечные автоматы, это я понимаю, постараюсь прикинуть, а если что-то еще, то я не видела ни карт Харела, ни Simulink. Дык чего изволите?

Как работать с Simulink и StateFlow я знаю, и по этому уровню ничего не спрашиваю.

Карты Харела почти тождествены диаграммам состояний.

Simulink и StateFlow позволяют оживить картинку.

У меня что-то пока фантазии не хватает, как это связать с диаграммами состояний предметной области или приложения.

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

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

Например смоделировать именно через диаграмму состояний - как модель некоторого менеджера соединения - работу этого самого менеджера, логику его работы. Поскольку в simulinke можно сделать некий GUI из него обращаться к модели этого самого менеджера, и соединение к БД, что матлаб тоже позволяет.

Может у меня бредовая фантазия - так прощу сообщество защитить меня от собственных бредовых идей 

Идея весьма полезная. Думаю, что визуализация работы некоторых паттернов (шаблонов) проектирования, их расширений и комбинаций - была бы хорошим подспорьем в их изучении и использовании.

Идея весьма полезная. Думаю, что визуализация работы некоторых паттернов (шаблонов) проектирования, их расширений и комбинаций - была бы хорошим подспорьем в их изучении и использовании.

может объединим голову и руки?

Лучше студентов заставить.
Я начинал было рисовать анимацию паттерна Command в PowerPoint, но энтузиазм быстро закончился.
А ведь этот паттерн можно расписать с добавлением менеджера команд, и с поддержкой отмены выполнения, да и много чего ещё.

Лучше студентов заставить.

Да наверное в стиле научной работы или аспирантуры:-) Мне вдруг показалось "нельзя объять необъятное" (с)

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

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

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

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

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

Это учебная задача, или по этой диаграмме планируется реализация?

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

Это учебная задача, или по этой диаграмме планируется реализация?

А зачем смешивать два разных статуса на одной диаграмме? Подстатус "Просрочена / не просрочена" будет вестись в отдельном поле и, наверное, участвовать в каких-то особых процессах (контроля?).

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

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

Как-то не очень понятно Статусы заявки и результатов. Имхо
Отдельно Заявка
Отдельно Результат

Также есть и другие синтаксические ошибки, на переходах, что указано?

Т.е. я бы разделил эти две диаграммы автоматов.
Тщательно продумал состояния и события переходов из одного состояния в другое

Математически это означает задать автомат:
1 задать состояния
2 задать множество входов - событий
3 задать множество выходов - тут у вас просто у вас модель мура - то есть выход = состоянию заявки
4 задать функции перехода (т.е. сопоставить какое событие из какого состояния в какое переводит) это рисуется так - матрица по вертикале список состояний - и по горизонтале список состояний - в пересечение пишется событие - если пусто то перехода нет
5 ну еще есть матрица выходов - результатов - но наверное вам она не нужна

Ну и матчасть http://uml3.ru/library/uml_for_developers/05.Behaviour_modeling.pdf

Краш-курс Самека ("A Crash Course in UML State Machines") реально хорош. Если перевести его на русский, стандартный UML и Simulink, то, мне кажется, взлетит. Потянут ли студенты? Не знаю.