Форум Сообщества Аналитиков
Дисциплины => Обучение => Тема начата: Galogen от 26 Сентября 2007, 17:12:52
-
В течение ряда лет я преподаю дисциплину по кодовым названием Моделирование систем.
В рамках оной мы изучаем различные математические модели в соответствии с учебником Советова с такми же названием. Моделирование моделей производится в хорошо известной среде MatLab. В первую очередь мы используем среду визуального моделирования Simulink.
Среди развитых инструментов Simulink имеется расширение StateFlow, представляющее собой графическую среду моделирования конечных автоматов, основанную на карта Харела - прямой аналог диаграмм состояний в UML. Думаю, диаграммы состояний были реализованы на основе карт Харела.
У меня есть несколько задач на использование концепции StateFlow для изучения детерминированного и вероятностного конечных автоматов.
Поскольку изучение этого предмета происходит раньше или параллельно с изучением ООП, мне вдруг пришла в голову идея как-то связать изучение конечных автоматов и диаграмм состояния вместе.
Диаграммы состояний в UML применяются для описания поведения объекта или системы в целом. Таким образом, можно связать формирование диаграмм состояний с их имитационным моделированием в StateFlow.
Но что-то не придумывается как это сделать.
Конечно мы можем описать работу скажем автомата выдачи билета в нотациях UML - перенсти диаграмму состояний в SateFlow и задав рабочую нагрузку промоделировать ситуацию. Но хотелось бы ближе к реалиям программирования и информационных систем.
Есть какие-то идеи? Задачки ? Прошу публиковать здесь. Их реализацию будут пытаться сделать и публиковать результаты.
-
И тишина! Хоть бы критику что ли навели, а то просто игнорируем. Это не в традициях нашего форума
-
Эд, я бы с удовольствием, но как в начале разбора темы про МУ, я по этому тексту не очень понимаю, чего ты хочешь.
Если задач из жизни на конечные автоматы, это я понимаю, постараюсь прикинуть, а если что-то еще, то я не видела ни карт Харела, ни Simulink. Дык чего изволите?
-
Как работать с Simulink и StateFlow я знаю, и по этому уровню ничего не спрашиваю.
Карты Харела почти тождествены диаграммам состояний.
Simulink и StateFlow позволяют оживить картинку.
У меня что-то пока фантазии не хватает, как это связать с диаграммами состояний предметной области или приложения.
Т.е. я могу описать скажем работу банкомата, смоделировав его состояния и получения тех или иных сообщений (от клиента - вставка карты, набор пинкода, набор действия, набор суммы; от банковской системы - подтверждения или отказ) - это интересно, но вопрос для чего? Скажем для проверки работоспособности, выявления узких мест (моделируя всякие внешние воздействия и изучая внутреннюю логику)
Аналогично хотелось бы перейти к моделированию состояний объектов приложений и даже взиамодействия между ними.
Например смоделировать именно через диаграмму состояний - как модель некоторого менеджера соединения - работу этого самого менеджера, логику его работы. Поскольку в simulinke можно сделать некий GUI из него обращаться к модели этого самого менеджера, и соединение к БД, что матлаб тоже позволяет.
Может у меня бредовая фантазия - так прощу сообщество защитить меня от собственных бредовых идей :D
-
Идея весьма полезная. Думаю, что визуализация работы некоторых паттернов (шаблонов) проектирования, их расширений и комбинаций - была бы хорошим подспорьем в их изучении и использовании.
-
Идея весьма полезная. Думаю, что визуализация работы некоторых паттернов (шаблонов) проектирования, их расширений и комбинаций - была бы хорошим подспорьем в их изучении и использовании.
может объединим голову и руки?
-
Лучше студентов заставить.
Я начинал было рисовать анимацию паттерна 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, то, мне кажется, взлетит. Потянут ли студенты? Не знаю.
-
Краш-курс Самека ("A Crash Course in UML State Machines") реально хорош. Если перевести его на русский, стандартный UML и Simulink, то, мне кажется, взлетит. Потянут ли студенты? Не знаю.
А можно ссылку? А какие проблемы с Симулинком? Я его активно использовал до открытия для себя UML. Сам Симулинк на самом деле тут не очень, скорее Stateflow и Simevents
-
https://sourceforge.net/projects/qpc/files/doc/PSiCC2.pdf/download
Проблем нет. Самек делает примеры под свои инструменты, так что, может быть необходимым допиливание, портирование.