Является ли время актером в прецеденте?
хорошо, на истинный ложный вопрос:
a)участники системы представлены только людьми или другими программными компонентами.
Я сказал правду, и Учитель отметил это как неправильное, не потому, что он считал, что я пропустил аппаратные компоненты (которые, я думаю, я бы частично признал), а потому, что на его словах:
"время тоже актер."
как диаграмма прецедентов будет рассматривать время как актера??
см. любой библиографии, которая считает время актером. Я не нашел ни одного, и честно говоря, я не думаю, что это имеет смысл. Время не действует само по себе, это либо система, либо человек, который работает по расписанию.
10 ответов
ОМЛ 2 варианта использования диаграмм правила...
http://www.agilemodeling.com/style/useCaseDiagram.htm
... покажите, как можно представить время.
Я подозреваю, что вы должны попросить своего учителя объяснить, как время является актером и как оно представлено на диаграмме прецедента, потому что, в конце концов, они будут отмечать ваше следующее задание, и поэтому их интерпретация превосходит все остальные :-)
О, и Википедия говорит Время является актер, так что это должно быть так:
Я не согласен, что время является актером. Что вам действительно нужно подумать, так это кто выиграет от действия и поместит в функциональное описание настройку создания и выполнения расписания. Взгляните на эту статью:
актер может рассматриваться как кто-то или что-то, что начинает прецедент. Запланированные задачи запускаются по "времени". В этом смысле "время" - это актер, потому что оно запускает прецедент.
пример:
отчет должен создаваться каждые 6 часов. Таким образом, время "6 часов" должно быть актером, потому что задача генерации будет запускаться каждые 6 часов.
Я согласен с тем время как актер. Если прецедент в системе запускается в определенный момент времени, я бы моделировал время как актера и соотносил его с этим прецедентом. Время можно считать внешней сущностью (и, следовательно, актором) в этих сценариях
Да время может быть актером в случае использования. Но не должен быть основным действующим лицом.Поскольку это действительно нарушает определение актора в случае использования.
Primary actor is someone/thing which has a goal for interacting with the system.
какую цель имеет время?
Time ------> RunPayroll
кто имеет выгоду от запуска заработной платы? Может быть, актер времени прячет настоящего актера.
Payroll Administrator (primary actor) ---> RunPayroll --> Time (Supporting actor)
но это дает impresion, который запускает случай использования заработной платы, вызванный вручную администратором заработной платы? Ведь мы разрабатываем автоматизацию sytstem?
но имейте в виду, что, если мы используем Администратор заработной платы в качестве основного Актер, тогда мы сможем захватить все характеристики системы, которые окружают управление платежными ведомостями. Это включает особенности, которые позволяют зарплату Администратор для установки расписания для запуска заработной платы и обработки расхождения, ручное вмешательство, и каникулы. [Дорогой доктор Use Case: является ли часы актером]
вы можете получить эту хорошую статью Ibm от Дорогой доктор Use Case: часы актер?
Я также согласен с тем, что время не является основным действующим лицом в этом контексте. Я хотел бы добавить несколько пояснений в поддержку идеи о том, что "время как актер" очень часто не является хорошей идеей.
(1) давайте дадим вещи другое имя и работоспособное определение. Время можно измерить. Но определение понятия как такового - очень сложная научная проблема. Поэтому для ежедневного использования нет смысла описывать взаимодействие с ним. Описание и имя роли мне больше подходит то, что измеряет время и может уведомлять об этом, например TimeService.
(2) мы можем измерить время везде. времени не только снаружи, в окружающей среде. Только когда пользователь требует, чтобы наш поставщик времени не был частью системы для построения, мы должны описать взаимодействие со вторичным актором TimeService и интерфейсом для него. Но в основном TimeService будет одним из классов или компонентов, которые реализуют / реализуют варианты использования и отсутствуйте как актер в диаграмме UC.
для более подробной информации: это короткий текст, который я написал об этом.
на мой ответ: до аналогичный вопрос, Я сказал, что они моделируют действия, которые должны выполняться в данный момент, чтобы создать актер под названием "планировщик", который является более заполнителем и не упоминает технологию. Идея в том, что должен быть какой-то человек или компонент, чья обязанность-следить за временем, а затем инициировать конкретный вариант использования. Прецедент говорит :" этот прецедент начинается во время X " в зависимости от потребностей прецедента. Да, время-это фактор, который можно смоделировать, но то, как инструктор идет об этом, кажется мне растяжкой, потому что само время не заботится о том, что происходит, когда, оно просто есть. Он слишком обобщает, пытаясь вписать все типы прецедентов в свою концепцию моделирования.
Мне нравится статья в @ Igor's answer поскольку он действительно охватывает большую часть проблемы с тем, чтобы сделать время основным актором.
актеры обычно представлены каким-то существительным, поэтому, возможно, компромисс заключается в использовании часов в качестве актера вместо капитала-T "время". Как и другие плакаты, Я согласен, что вы вряд ли убедите учителя, но это стоит обсудить, потому что это помогает понять, как он думает о моделировании в целом.
хотя я понимаю, что слишком поздно для класса, который сгенерировал этот вопрос, я публикую этот ответ в надежде помочь другим, кто столкнулся с проблемой моделирования времени в случае использования, или, встретив профессора, у которого есть свое мнение о том, как моделировать с помощью UML use cases.
время взаимодействует с системой. Е. Г. время идет мимо, и система должна делать что-то на основе этого "действия".
Я согласен с @Novalis время может быть актором, но не основным актором, потому что каждый участник является актором, и время может нести ответственность за выгоду или потерю любого участника, поэтому его можно рассматривать как вторичного актора или любое имя, которое вы хотите дать.
пока я не знаю лучше, я нахожу время быть актером немного запутанным, особенно потому, что актеры act и время связано с тем, что все меняется: Земля вращается вокруг Солнца, кристаллы пульсировать. Мы преобразуем агрегированный побочный эффект этих изменений с помощью изменить-для-конвертер времени инструменты (т. е. часы!) в техногенные шкалы мы называем-время.