Форум Сообщества Аналитиков
Общий раздел => Примеры => Задачи студентов => Тема начата: bas от 27 Января 2012, 19:18:48
-
Нашел интересную задачу, которую в том числе можно дать аналитику на собеседовании:
Есть два лифта рядом в здании (пусть будет 5 этажей), у них один механизм управления.
Нужно нарисовать с помощью диаграмм активности или сосстояний работу этого механизма управления.
Кто хочет потренироваться, может прикреплять картинки Д здесь, бум обсуждать.
-
Условие слишком кратко. Например, неясно имеют ли вызовы лифтов направление (вниз/вверх); реагируют ли лифты на попутные вызовы; принимает ли лифт более одного назначения из кабины.
-
Задача, как я понимаю, в том, чтобы разработать эффективную систему управления двумя лифтами и построить модель с использованием языка UML?
Виктор, думаю. Вы уже присоединились к задаче. Начинаете задавать вопросы для снятия неопределенности: типичная задача для аналитика.
-
Условие слишком кратко. Например, неясно имеют ли вызовы лифтов направление (вниз/вверх); реагируют ли лифты на попутные вызовы; принимает ли лифт более одного назначения из кабины.
Я поставил задачу, как ее ставит Заказчик, уточняйте, велкам )
Отвечаю:
1. неясно имеют ли вызовы лифтов направление (вниз/вверх)
вызовы вверх/вниз есть
2. реагируют ли лифты на попутные вызовы
конечно, нужно оптимально загружать лифты и должно быть оптимальным их движение
3. принимает ли лифт более одного назначения из кабины
да, принимают, т.е. люди в кабине могут поехать на несколько этажей сразу
-
Условие слишком кратко. Например, неясно имеют ли вызовы лифтов направление (вниз/вверх); реагируют ли лифты на попутные вызовы; принимает ли лифт более одного назначения из кабины.
Лифтами все пользуются, думаю поэтому каждый может выступить в роли Заказчика.
-
Я поставил задачу, как ее ставит Заказчик, уточняйте, велкам )
Благодарю. Второе уточнение хотелось бы получить относительно того, в каких терминах ведётся управление, т. е. каковы действия и события (на диаграмме состояний)? От этого будет зависеть сложность решения.
P. S. Cудя по первым уточнениям задача выглядит достаточно сложной. Не смотря на то, что в условии "один механизм управления", стоит разбить его на две части: "стратегическую" -- ловящую вызовы и распределяющую их по лифтам; "тактическую" -- управляющую дверьми, мотором одного (каждого) из лифтов.
P. P. S. Подобная задача рассматривалась в книге Йордана "ООАиП систем" [в предыдущем переводе "Структурные модели в ООАиП"].
-
Довольно не простая задачка, тем более для собеседования :)
Есть такая работа ОО проект: Компьютерная модель высотного лифта (во вложении).
Там больше конечно про написание кода, но как основа может пригодиться.
-
Виктор, ну зачем же сразу говорить, где можно взять решение?! Я хотел, чтобы народ сам подумал (
Что-то какая-то хилая Д в ОО проекте:
Рассмотрим диаграмму состояний для программы моделирования лифтов. С целью упрощения задачи,
будем считать, что в здании находится только один человек и имеется только один лифт. Таким об-
разом, в один момент времени может быть только один запрос c этажа и один этаж назначения. Лифту
не нужно следить за другими. Диаграмма состояний представлена на рис. 5.
З.Ы. На счет данной задачи на собеседовании: понятно, что за 15 минут кандидат не нарисует правильной Д, но мне важнее на собеседовании услышать ход его мыслей и послушать его вопросы...
-
может начать с ДВИ? ;D
-
может начать с ДВИ? ;D
Мдя, Остапа понесло (с)
-
может начать с ДВИ? ;D
Розовый цвет мне очень понравился...гламурненько :)
-
Вот поэтому опытный аналитик и отличается от новичка, тем, что опытный сразу зрит в корень, в действительности диаграмма активностей и состояний, скорее всего заказчику не нужна, а нужны контрмеры для борьбы с описанными RuZzz'ом дви...
Есть предложение сразу начать проектирование лазерных лучей, которые в случае обнаружения нарушителя будут выезжать, и осуществлять справедливое наказание, как например, было в Обители зла, в коридоре по пути к «Красной королеве». Само собой с увеличением числа лучей в геометрической прогрессии, в случае если нарушителя первый луч не покарал...
ЗЫ
дви зачотная! (ц) 8)
-
ЗЫ
дви зачотная! (ц) 8)
и в чем зачетность? Имхо, это просто прикол, никакого отношение к данности задачи, не имеющий. Даже варианты имхо ошибочны. Причем тут к примеру контекст системы лифтов?
-
Коллеги, давайте флуд оставим для другого форума.
Далее оффтоп будет удаляться.
-
Решил прислушаться к критике и немного исправил диаграмму. Первая диаграмма это попытка нарисовать ДБО
lift.docx сценарии ВИ сгенерированные в VP, поэтому там не всё хорошо.
Решил отказаться от следующих ВИ
Лифтёр - Получить тревожный сигнал
Связаться с лифтёром вынес в другую систему, чтобы сразу всё не накрылось.
Да и мало общего у системы связи с лифтом.
После того как закончу с этими диаграммами, нарисую классы, состояния и алгоритм.
-
Виктор, ну зачем же сразу говорить, где можно взять решение?! Я хотел, чтобы народ сам подумал (
Я не помню точно, но кажется, в книге были в основном диаграммы классов и взаимодействия. В первом издании на русском -- даже без UML-нотации. Книгу вспомнил потому, что там предлагалось строить управление по сигналам о прибытии кабин на этажи. Для этого были придуманы спец. датчики. Это один из ответов на вопрос, как узнать, мимо какого этажа какая кабина движется.
-
Решил прислушаться к критике и немного исправил диаграмму. Первая диаграмма это попытка нарисовать ДБО
lift.docx сценарии ВИ сгенерированные в VP, поэтому там не всё хорошо.
Проблема с ВИ "Переместиться на другой этаж" в том, что его длинный сценарий зависит от многих условий. То есть, с момента, когда пассажир нажимает на кнопку вызова лифта, до момента, когда он окажется на нужном ему этаже, может произойти очень много всего (при тех условиях задачи, которые нам даны).
Один из путей выхода -- бить сценарии (и ВИ) на небольшие относительно независимые части. Пассажир жмёт на вызов -- система принимает вызов и делает лишь тот минимум, что необходим. Лифт подъезжает к какому-либо этажу -- система по сигналу датчика решает, следует ли ему остановиться и принять/выпустить пассажиров или продолжить движение. И т. п.
-
То есть, с момента, когда пассажир нажимает на кнопку вызова лифта, до момента, когда он окажется на нужном ему этаже, может произойти очень много всего (при тех условиях задачи, которые нам даны).
Так в моих ВИ есть же секция - Расширения. Их я и хочу выявить мозговым штурмом форумчан.
Например, после нажатия оба лифта застряли (наверно не важно по каким причинам). Система должна сообщить что лифты не приедут.
-
Так в моих ВИ есть же секция - Расширения. Их я и хочу выявить мозговым штурмом форумчан.
Как, например, представить расширением, что за время поездки первого пассажира в лифте можно подобрать попутного пассажира, который доедет до своего этажа раньше, чем первый пассажир.
P. S. Мне кажется, что применение ВИ к этой задаче не совсем удачно.
-
Хотелось бы уточнить.
1. 1-й лифт (1Л) на первом, 2Л - на пятом. Вызов лифта с третьего на спуск.
Реакция системы:
а) Едет случайный лифт.
б) Едет лифт, которому тоже надо спускаться.
в) Едет лифт, которому нужно подниматься.
г) Едут оба лифта.
д) Оба лифта стоят :)
2. 1Л на четвертом, 2Л - на первом. Вызов лифта с третьего на спуск.
Реакция системы:
а) Едет случайный лифт.
б) Едет лифт, которому тоже надо опускаться.
в) Едет лифт, которому нужно подниматься.
г) Едут оба лифта.
д) Едет ближайший лифт.
3. 1Л на четвертом, 2Л - на первом. Вызов лифта со второго на спуск.
Реакция системы:
а) Едет случайный лифт.
б) Едет лифт, которому тоже надо опускаться.
в) Едет лифт, которому нужно подниматься.
г) Едут оба лифта.
д) Едет ближайший лифт.
4. 1-й лифт (1Л) на первом, 2Л - на пятом. Вызов лифта с третьего на спуск и на подъем.
Реакция системы:
а) Едет случайный лифт.
б) Едут оба лифта.
5. 1-й лифт (1Л) на четвертом, 2Л - на пятом. Вызов лифта с третьего на спуск и на подъем.
Реакция системы:
а) Едет случайный лифт.
б) Едут оба лифта.
6. 1Л на первом, 2Л - занят. Вызов лифта с пятого. В момент движения 1Л, освобождается 2Л и происходит вызов лифта с третьего на подъем.
Реакция системы:
а) 1Л подбирает пассажира на третьем этаже и продолжает движение вверх.
б) 2Л спускается на третий этаж.
7. 1Л на первом, 2Л - занят. Вызов лифта с пятого. В момент движения 1Л, освобождается 2Л и происходит вызов лифта с третьего на спуск.
Реакция системы:
а) 1Л подбирает пассажира на третьем этаже и продолжает движение вверх.
б) 1Л подбирает пассажира на третьем этаже и начинает движение вниз.
в) 2Л спускается на третий этаж.
8. 1Л на первом, 2Л - занят. Вызов лифта с пятого. В момент движения 1Л происходит вызов лифта с третьего на спуск.
Реакция системы:
а) 1Л подбирает пассажира на третьем этаже и продолжает движение вверх.
б) 1Л подбирает пассажира на третьем этаже и начинает движение вниз.
в) 1Л проезжает третий этаж без остановки.
-
1. По моему однозначно "б" - потратиться меньше энергии на спуск.
А если ближе нижний лифт, то однозначно нужно подтягивать тот который быстрее приедет. (думаю надо рассчитывать время)
остальное проще нарисовать на состояниях и активности.
-
P. S. Мне кажется, что применение ВИ к этой задаче не совсем удачно.
Согласен с Виктором. Если помнить, что есть ВИ, то неизбежно все рассуждения сведутся к использованию лифта для перемещения по этажам. Да побочно можно указать вариации: если лифт остановился - нажми кнопку звонок, и т.п.
Однако мы ведь рассуждаем о системе управления лифтами, а не сам лифт. Сам лифт - это объект управления.
Задачу имеет смысл описывать через список возможных событий, а систему управления как конечный автомат. Лифт тоже можно рассматривать как автомат. Тогда вся система (управления и лифты) и будут сложноподчиненным автоматом.
-
Ну в этом плане плане я решил немного отвлечься от темы топика, причина следующая.
В книжке Дейтела есть задачка про моделирование работы лифта на C++. Чтобы написать такую программку мне хотелось собрать некоторые требования. А тут захожу на форум и вы лифт обсуждаете :) Вот и решил не создавать новую тему, а прямо тут описать некоторые требования и обсудить.
Неужели эти требования не повлияют на автомат и на диаграмму активности главного цикла программы?
-
По поводу вопроса от Ilgr
Хотелось бы уточнить.
Это вопросы или Из них надо выбрать 1 верный?
Теперь по задаче. 2 лифта, 1 механизм управления.
Как мне видится - получается есть контроллер , который на основании данных о состоянии лифта (-ов) "принимает решение", точнее действует по заданному алгоритму.
Теперь состояния (еще надо понять, что учитывать?)
1. Лифт 1
- едет вверх
- едет вниз
- стоит
2. Лифт 2
- едет вверх
- едет вниз
- стоит
3. Назовем - расширения:
- когда едет вверх вызвали лифт
- когда едет вниз вызвали лифт
-
Да это вопросы.
1. При такой комбинации событий -1-й лифт (1Л) на первом, 2Л - на пятом. Вызов лифта с третьего на спуск.
Что произойдет? - Реакция системы:
а) Едет случайный лифт.
или
б) Едет лифт, которому тоже надо спускаться.
или
в) Едет лифт, которому нужно подниматься.
или
г) Едут оба лифта.
или
д) Оба лифта стоят
Это собственно для меня не определенные моменты в поведении системы. Вариантов, конечно, значительно больше, но остальные вроде как, понятны.
-
ответ (б.)
-
А на остальные 7 вопросов? :)
-
2. - б
3. - б
4. - б
5. - б
6.-8. - что такое лифт занят?
-
6.-8. - что такое лифт занят?
Любитель выпить достигает своей цели :D
а вот ещё такой вопрос. Сэкономим ли мы хоть сколько нибудь энергии, если будем ночью опускать лифт на первый этаж, чтоб он не висел на верхних этажах?
-
Уточняю вопрос.
6. 1Л на первом, 2Л - не доступен для реализации вызова (например произошла выгрузка пассажиров, но двери пока не закрыты). Вызов лифта с пятого. В момент движения 1Л, освобождается 2Л - становится доступен для реализации вызова и происходит вызов лифта с третьего на подъем.
Реакция системы:
а) 1Л подбирает пассажира на третьем этаже и продолжает движение вверх.
б) 2Л спускается на третий этаж.
7. 1Л на первом, 2Л - не доступен для реализации вызова (например произошла выгрузка пассажиров, но двери пока не закрыты). Вызов лифта с пятого. В момент движения 1Л, освобождается 2Л - становится доступен для реализации вызова и происходит вызов лифта с третьего на спуск.
Реакция системы:
а) 1Л подбирает пассажира на третьем этаже и продолжает движение вверх.
б) 1Л подбирает пассажира на третьем этаже и начинает движение вниз.
в) 2Л спускается на третий этаж.
8. 1Л на первом, 2Л - не доступен для реализации вызова (например произошла выгрузка пассажиров, но двери пока не закрыты). Вызов лифта с пятого. В момент движения 1Л и не доступости для реализации вызова 2Л происходит вызов лифта с третьего на спуск.
Реакция системы:
а) 1Л подбирает пассажира на третьем этаже и продолжает движение вверх.
б) 1Л подбирает пассажира на третьем этаже и начинает движение вниз.
в) 1Л проезжает третий этаж без остановки.
-
Получается у каждого лифта по одному блоку вызова на этаже? (с кнопками - вверх, вниз.)
А в чём разница между двумя системами с отдельными лифтами и одной системой с двумя лифтами?
Всё равно же в реализации мы создадим два экземпляра класса "лифт", и у каждого будут свои состояния, и эти экземпляры будут обмениваться сообщениями о своих состояниях.
Получается добавится только количество событий, а состояний будет два (пока остановился на двух, а дальше посмотрим) : остановка, движение.
Или вы хотите сказать 2 состояния непременно приведут к 4: два основных и два подсостояния для "движения": вверх - вниз? и состояния вверх -остановка -вниз являются минимизированными максимально?
-
Ну почему два блока управления.
Может быть и один на два лифта.
Такое реально встречается.
-
Хотя действительно две панели вызова нужны только в случае когда, на этаже слишком много людей для одного лифта, которые хотят вниз. Но они просто могут отправить дополнительный сигнал вниз когда сядет первая партия. Тем самым подтвердить свои намерения.
Что скажет заказчик?
Или нужен конечный автомат без памяти?
-
Немного отошел от задачи, считаю, что надежней сделать работу лифтов максимально независимыми, без выделенного управленца.
Принцип функционирования лифта заключается в выполнении поставленных задач которые можно задавать как из кабинки, так и с этажа. На этаже можно нажать кнопку ВВЕРХ, кнопку ВНИЗ. Лифт едет и собирает по-пути пассажиров: если лифт едет вверх и на этаже нажата кнопка ВВЕРХ останавливается, ежели лифт едет вверх, а на этаже нажата кнопка ВНИЗ едет дальше, а остановится на обратном пути. Это реализуется двумя списками задач, для одного направления и для обратного, когда задачи из одного направления заканчиваются лифт переходит к выполнению задач обратного направления и т.д.
Работа двух лифтов аналогична, НО у лифта есть список индивидуальных задач (те которые были заданы из лифта), и общих задач (которые были заданы с этажа). Задачи выполняются последовательно от этажа к этажу, тот лифт который быстрей выполнит общую задачу исключает ее из списка задач обоих лифтов, таким образом Лифты работают асинхронно и у каждого свой алгоритм управления.
Примечание: чтоб лифты не стартовали к одному этажу (не приступали к выполнению одной задачи), кто первый приступает к выполнению задачи ставит метку «выполняемая», после обслуживания удаляет из списка задач. Если лифт сделавший пометку «выполняемая» ломается он снимает метку.
Момент старта (когда лифты никого не обслуживают) решается вопрос кому первому обслуживать задачу (кто ближе к этажу назначению, если равноудалёно то в случайном порядке).
-
Тут малость помоделировал в свободное от основной работы время.
-
я еще студент и тема для тренировок мне очень актуальна)))
может я не прав...
а не правильнее ли перед построением диаграмм активности обозреть систему в целом и решить что будет делать управляющий модуль а что нет?..
и уже исходя из требований по функциональности модуля управления согласуя их с "заказчиком" уже построить диаграммы...
набросал навскидку что получилось с потребностями потенциальных взаимодействий извне, но мог что то упустить
-
У вас на диаграмме не ясен контекст системы.
-
У вас на диаграмме не ясен контекст системы.
на предыдущей диаграмме я пытался выявить максимально-возможное количество заинтересованных лиц и их потребностей по отношению к лифтам в целом.
например учитывать автоматизированную систему безопасности как контр меры аварийных ситуаций таких как пожар или отключение энергии или разрыв троса... могут повлиять на диаграмму состояний
а мне кажется что безопасность имеет первостепенную роль даже если в шахте каких то 5 этажей)))
не учитывать ее в построении диаграмм активности или состояний работы данного механизма мне кажется еще более неверным чем неумение "рисовать" эти самые диаграммы...
на этой диаграмме попытался описать контекст системы управления механизмом
ps если есть желание и возможности - ругайте пожалуйста сильнее. а то вторая в жизни Д на uml..
-
на предыдущей диаграмме я пытался выявить максимально-возможное количество заинтересованных лиц и их потребностей по отношению к лифтам в целом.
Я имел в виду контекст на диаграмме. Или границы системы, она же boundary. Что это? Лифт, Система управления лифтом. Отсюда будет более ясно, кто и зачем взаимодействует с системой.
При этом Система безопасности может быть частью Системы управления лифтом (тами), а может быть чем-то независимым.
не учитывать ее в построении диаграмм активности или состояний работы данного механизма мне кажется еще более неверным чем неумение "рисовать" эти самые диаграммы...
пока мы рассуждали о модели использования
на этой диаграмме попытался описать контекст системы управления механизмом
ps если есть желание и возможности - ругайте пожалуйста сильнее. а то вторая в жизни Д на uml..
1. зачем выделяется такая сущность как Пассажир и описываются его операции? Разве вы сможете им управлять?
2. не понял семантику реализации интерфейсов КНОПОК зданием и лифтом.
-
Я имел в виду контекст на диаграмме. Или границы системы, она же boundary. Что это? Лифт, Система управления лифтом. Отсюда будет более ясно, кто и зачем взаимодействует с системой.
границу системы я видел ограничивающую акторами... не встречал в сети диаграмм где за границей boundary могут быть другие преценденты...
так надеюсь правильнее?..
При этом Система безопасности может быть частью Системы управления лифтом (тами), а может быть чем-то независимым.
естественно. именно поэтому я ее обозначил как актор, то есть как внешнее к системе отношение...
то есть актор тоже может быть внутри системы?..
пока мы рассуждали о модели использования
1. зачем выделяется такая сущность как Пассажир и описываются его операции? Разве вы сможете им управлять?
2. не понял семантику реализации интерфейсов КНОПОК зданием и лифтом.
1.непосредственно пассажиром нет... я хотел показать чем может управлять пассажир и какие у него возможности взаимодействия. то есть этот класс совсем не нужен?..
2. а)эм... в каждом лифте есть блок управления (эти самые кнопки с 1го по 5й этажи, например)
б)в здании на каждом этаже есть кнопки вызова "вниз" и "вверх"
я именно это хотел показать на диаграмме интерфейсами...
-
границу системы я видел ограничивающую акторами... не встречал в сети диаграмм где за границей boundary могут быть другие преценденты...
так надеюсь правильнее?..
и правильно не встречали, так как что же это за вариант использования, если его некуда приложить? Вот и ваша диаграмма стала сразу малопонятной. Вот выделили вы boundary и назвали его System, понятней не стало, что за System?
естественно. именно поэтому я ее обозначил как актор, то есть как внешнее к системе отношение...
Актор - нечто внешнее по отношении к системе, обладающее поведением. Да в вашем случае система безопасности может быть внешней по отношении к рассматриваемой системе. Это вы показали и сейчас это стало ясно, но все равно не до конца.
то есть актор тоже может быть внутри системы?
с точки зрения синтаксиса и семантики нет, актор внутри системы быть не может.
..1.непосредственно пассажиром нет... я хотел показать чем может управлять пассажир и какие у него возможности взаимодействия. то есть этот класс совсем не нужен?..
Для отображения взаимодействия существуют другие средства, например, диаграмма коммуникации.
2. а)эм... в каждом лифте есть блок управления (эти самые кнопки с 1го по 5й этажи, например)
есть
б)в здании на каждом этаже есть кнопки вызова "вниз" и "вверх"
встречаются, но не всегда
я именно это хотел показать на диаграмме интерфейсами...
На мой взгляд сомнительно.
Скажите, на кого рассчитана эта модель? На какие вопросы она должна ответить? И какой ответ и кто получит, увидев кружочек с надписью "кнопки"?
-
и правильно не встречали, так как что же это за вариант использования, если его некуда приложить? Вот и ваша диаграмма стала сразу малопонятной. Вот выделили вы boundary и назвали его System, понятней не стало, что за System?
я его не называл систем оно само))) а поменять не нашел где...
про границы не понял... какой смысл от квадратика который ограничивает все прецеденты на диаграмме если и так понятно что акторы - внешние объекты системы?..
Скажите, на кого рассчитана эта модель? На какие вопросы она должна ответить? И какой ответ и кто получит, увидев кружочек с надписью "кнопки"?
1 на человека имеющего опыт построения uml диаграмм классов, который ее увидит на этом форуме
2 а)что в диаграмме не правильно?
б) на что можно указать автору диаграммы что бы он понял свои ошибки в построении?
в)как можно ее исправить что бы она приняла адекватный вид и смогла помочь в построении диаграмм активности
механизма управления двумя кабинами лифтов?
3 не знаю я пытался отобразить как раз взаимодействие
зы. спасибо за содержательное обсуждение
-
про границы не понял... какой смысл от квадратика который ограничивает все прецеденты на диаграмме если и так понятно что акторы - внешние объекты системы?
просто boundary может быть несколько раз, во вторых именованная boundary сразу создает контекст обсуждения. Вот в первом вашем случае было не понятно к чему вы применяете свои ВИ, к какой системе? Каждый может интерпретировать сам. Например я отношу к лифту, другой к системе управления, для которой лифт реально - просто набор датчиков и т.п. Важна точность и однозначность.
2 а)что в диаграмме не правильно?
б) на что можно указать автору диаграммы что бы он понял свои ошибки в построении?
в)как можно ее исправить что бы она приняла адекватный вид и смогла помочь в построении диаграмм активности
механизма управления двумя кабинами лифтов?
1. это диаграмма объектов предметной области (иначе сущностей, классов предметной области), а не диаграмма программных классов, на ней не отображают поведение, а лишь структурные информационные связи
2. понять что за диаграмму делаете, попробуйте построить несколько диаграмм объектов
3. а зачем это нужно делать? одно другому не мешает имхо.
3 не знаю я пытался отобразить как раз взаимодействие
ДК не предназначена для отражения взаимодействия. поведение изображается на диаграмма состояний, деятельности и взаимодействия(последовательности и коммуникации).
-
спасибо ошибку понял, не учел кол-во сторон интерпретации.
по второй диаграмме я понимаю что это явно не ДК я пытался описать эту Д как Д простой кооперации.
поэтому посчитал что позволительно было наградить Д так же и интерфейсами. но тут я понимаю что все не правильно и как правильно мне еще не дано знать...
("system" так и не нашел как изменить)
упростил систему, акцентировав внимание на самом механизме.
ПО которое управляет передвижением кабины лифта зависит от взаимодействия с этим лифтом внешних ЗЛ(небольшое число)которых я постарался обозначить посредством ДВИ приложенной к этому посту.
постараюсь выявить классы ПО которое необходимо смоделировать.
1.для перемещения кабины необходимо 2 мотора(основной и мотор открытия дверей)
которые были выделены в один суперКласс "привод"- имеющий операции "посадка" и "движение на n этаж"
2.этаж-имеющее такие параметры как "номер этажа"
3.лифт-имеющий идентификатор и состояния...
4.так же думаю необходимо добавить класс "траектория движения"...
в общем с классами и ДК- в частности - беда. изучаю...
большое спасибо за ответ.
-
Я думаю, вам тут нужно определиться.
1. Описываете ли вы просто систему управления лифтами.
2. Или вы пытаетесь построить симулятор лифтовой системы.
Результат может быть различный, когда вы перейдете к выявлению классов ПО.
Но что вы теряете, делайте свои варианты и не волнуйтесь слишком:)
-
что касается определенности... она изначально определена в
первом и 4м сообщении в теме...
вроде все понятно и конкретно.
решил идти как мне кажется более простым методом и вначале описать дви.. затем ДК и уже отталкиваясь от последней прийти к конечному результату задания.
по моему разумению считаю что диаграмма активности может быть с упущениями(читай - в корне не верной) если не брать в расчет аварийную остановку и некоторые другие ситуации, по сравнению с диаграммами на которых будет отражено только перемещение по этажам, открытие дверей и оптимальность передвижения.
на дви я хотел отобразить максимальное взаимодействие окружающих объектов с лифтами.
а далее уже начиная с ДК акцентировать внимание на самой задаче- непосредственно на работе механизма управления
потерять я могу Ваше и свое время.
-
что касается определенности... она изначально определена в
первом и 4м сообщении в теме...
Да ваша правда.
Только мне кажется вполне достаточно будет диаграмм состояния. Даже активности возможно не потребуется.
Описание ВИ вполне обосновано. Там ваши аварийные ситуации наверняка вылезут.
Диаграмма состояний будет тесно связана с сигналами, сигналами обмениваются части системы, чьи автоматы вы будете рисовать - отсюда волей не волей должна формироваться ДК. Мне так кажется.
-
Диаграмма состояний будет тесно связана с сигналами, сигналами обмениваются части системы, чьи автоматы вы будете рисовать - отсюда волей не волей должна формироваться ДК. Мне так кажется.
я правильно понимаю что формируя(не знаю какое лучше слово употребить) Диаграмму состояний, необходимо иметь ДК? ...не обязательно ее перед этим составлять, но хотя бы представляя ее очертания в голове?..
-
я правильно понимаю что формируя(не знаю какое лучше слово употребить) Диаграмму состояний, необходимо иметь ДК? ...не обязательно ее перед этим составлять, но хотя бы представляя ее очертания в голове?..
Я говорю о прежде всего о нашей задачи. В нашей задача много разных объектов: лифт, мотор, кнопки, система управления и т.п. Потому наша диаграмма автоматов - составная. Т.е. каждый объект будет иметь свою диаграмму автоматов, состояния будут меняться параллельно по различным событиям.
В любом случае неважно что первично, а что вторично. Что вам больше известно и понятно с того и начинайте.
-
[некробурения приступ]
Задача про лифт имеет длинную славную историю. Её решение из книги Йордана 1994-5гг. имеет много общего с магистерским диссером (https://apps.dtic.mil/dtic/tr/fulltext/u2/a215351.pdf) некоего капитана Стивена Марша из US Air Force Academy, защищённым в 1989м. Тема диссера "An Object-Oriented Analysis Method for Ada and Embedded Systems". [Через моего марсианского инет-провайдера этот диссер удалось скачать только через проксик, если что.]
US Air Force Academy является альма-матерью Гради Буча. Он туда поступил, вернувшись с вьетнамской войны. Выпустился в числе топ12 выпускников. Дослужился до капитана (программируя для наземного обеспечения пусков шаттлов). Затем Буч вернулся в альма-матерь для преподавания языка Ада. Там он встретил своих однокурсников, с которыми выпускался вместе — Пола Леви и Майка Девлина. Втроём они организовали компанию Rational [Machines Incorporated]. Rational удалось привлечь к работе Джима Рамбо и Ивара Якобсона. И завертелось...
Писанины много, извините. Общая идея -- хорошие учебные задачи (и их учебные решения) живут долго. Стивен Марш (как и Йордан ?по его следам?) не используют ВИ. Их решение оформлено в терминах событий и реакций на них.
-
Стивен Марш (как и Йордан ?по его следам?) не используют ВИ. Их решение оформлено в терминах событий и реакций на них.
Если несильно придираться, все-таки много общего. На Linkedin в группе по UseCases один индийский профессор Путча долго со всем обсуждали, что ВИ - это диалог: список событий и реакций на них:)
-
Могу попытаться пояснить, что в решениях Марша и Йордана нет _списков_ событий_, нет _потоков_событий_, нет сценариев. Они представляют собой что-то вроде конечных автоматов.
Если пытаться перекладывать такие решения в терминах ВИ, то мы получим что-то очень далёкое от целей пользователей лифта: "Обработать нажатие кнопки вызова", "Обработать сигнал датчика о прибытии на этаж". Проблематично составить сценарий "Переместиться с этажа N на этаж M" из набора таких псевдоВИ уровня "моллюска".