ВРЕМЯ актер в случае использования? - PullRequest
10 голосов
/ 13 мая 2009

Хорошо, на истинный ложный вопрос:

a) Актеры системы представлены только людьми или другими программными компонентами.

Я сказал ИСТИНА, и учитель пометил это как неправильное не потому, что считал, что я пропустил аппаратные компоненты (что, я думаю, я бы частично уступил), а потому, что, по его словам:

«ВРЕМЯ тоже актер».

Как в диаграмме вариантов использования ВРЕМЯ рассматривается как актер?

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

Ответы [ 10 ]

9 голосов
/ 13 мая 2009

Руководство по диаграммам вариантов использования UML 2 здесь ...

http://www.agilemodeling.com/style/useCaseDiagram.htm

... показать, как можно изобразить время.

Я подозреваю, что вам следует попросить своего Учителя объяснить, как Time является актером и как оно представлено на диаграмме вариантов использования, потому что, в конце концов, они будут отмечать ваше следующее задание, и поэтому их интерпретация превосходит все остальные: )

О, и Википедия говорит, что Время - Актер, поэтому это должно быть правдой:

http://en.wikipedia.org/wiki/Use_case

4 голосов
/ 23 марта 2011

Я не согласен, что время - это актер. Что вы действительно должны думать, так это о том, кто получит выгоду от действия и вставит функциональное описание, определяющее создание и выполнение расписания. Взгляните на эту статью:

Dr. Вариант использования

3 голосов
/ 13 мая 2009

Актер может рассматриваться как кто-то или что-то, что начинает сценарий использования. Запланированные задания запускаются по «времени». В этом смысле «время» является актером, потому что оно запускает вариант использования.

Пример:

Отчет должен генерироваться каждые 6 часов. Таким образом, время «6 часов» должно быть активным, поскольку задача генерации будет запускаться каждые 6 часов.

1 голос
/ 26 января 2016

В моем ответе на подобный вопрос я сказал, что способ моделирования действий, которые должны быть выполнены в данный момент времени, заключается в создании актера под названием «Планировщик», который больше заполнителя и не упоминает технологию. Идея заключается в том, что должен быть какой-то человек или компонент, который должен следить за временем и затем инициировать конкретный вариант использования. Сценарий использования говорит: «Этот вариант использования начинается в момент X» в зависимости от потребностей варианта использования. Да, время - это фактор, который можно смоделировать, но то, как работает инструктор, кажется мне растянутым, потому что само время не заботится о том, что происходит, когда оно просто есть. Он слишком обобщает, пытаясь вписать все типы сценариев использования в свою концепцию моделирования.

В положенной дискуссии с инструктором я бы спросил: «Является ли само время - никакой другой механизм, человек или программное обеспечение - сущностью, действующей на систему?» Очевидный ответ - «нет», но идея в том, что МОЖЕТ БЫТЬ произвольный субъект, который а) может измерять время и б) знает, что определенные варианты использования чувствительны ко времени.

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

Актеры обычно представлены каким-то существительным, поэтому, возможно, компромиссом является использование часов в качестве актера вместо заглавной буквы «T». Как и другие постеры, я согласен, что вы вряд ли убедите учителя, но стоит обсудить его, потому что это помогает понять, как он думает о моделировании в целом.

Хотя я понимаю, что уже слишком поздно для класса, породившего этот вопрос, я публикую этот ответ в надежде помочь другим, кто столкнулся с проблемой моделирования времени в случае использования, или встретиться с профессором, у которого есть их собственное мнение о том, как моделировать с использованием сценариев использования UML.

1 голос
/ 04 июня 2014

Я также согласен с тем, что Время не является основным действующим лицом в этом контексте. Я хотел бы добавить несколько объяснений, чтобы поддержать идею о том, что «Время как актер» очень часто не очень хорошая идея.
(1) Давайте назовем вещь другим именем и работоспособным определением . Время можно измерить. Но это очень сложная научная проблема, чтобы точно определить понятие как таковое. Поэтому для повседневного использования нет смысла описывать взаимодействие с ним. Описание и название для роли, которая подходит мне больше всего, - это то, что измеряет время и способно уведомить об этом, например. TimeService.
(2) Мы можем измерять время везде. Время не только снаружи в окружающей среде . Только когда пользователь требует, чтобы наш поставщик времени не был частью системы для построения, мы должны описать взаимодействие с вторичным субъектом TimeService и интерфейс для него. Но в основном TimeService будет одним из классов или компонентов, которые реализуют / реализуют сценарии использования и отсутствуют как субъект на диаграмме UC.
Для более подробной информации: это короткий текст, который я написал об этом.

1 голос
/ 10 июня 2011

Да ВРЕМЯ может быть актером в случае использования. Но не должен быть основным действующим лицом. Так как это действительно нарушает определение действующего лица в случае использования.

Primary actor is someone/thing which has a goal for interacting with the system.

Какую цель преследует Время?

Time ------> RunPayroll

Кто выигрывает от начисления заработной платы? Может быть, актер Тайма скрывает настоящего актера.

Payroll Administrator (primary actor) ---> RunPayroll  --> Time (Supporting actor)

Но что дает представление о том, что запуск варианта использования зарплаты, запускаемый вручную администратором расчета заработной платы? В конце концов, мы разрабатываем систему автоматизации?

Но имейте в виду, что если мы используем Администратор заработной платы в качестве основного Актер, тогда мы можем захватить все системные функции, которые окружают бег заработной платы. Это включает функции, позволяющие начислять заработную плату Администратор, чтобы установить расписание для расчета заработной платы и для обработки расхождения, ручное вмешательство, и праздники. [Уважаемый доктор, пример использования: часы - актер]

Вы можете получить эту хорошую статью Ibm от Уважаемый доктор. Пример использования: Часы - актер?

1 голос
/ 13 мая 2009

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

0 голосов
/ 31 октября 2013

Пока я не узнаю лучше, время актера немного сбивает с толку, особенно потому, что актеры действуют , а время связано с тем, что все меняется : Земля вращается вокруг Солнца кристаллы пульсируют. Мы преобразуем агрегированный побочный эффект этих изменений с помощью преобразователя времени инструментов (т.е. часов!) В искусственную шкалу , которую мы называем: время.

0 голосов
/ 16 октября 2012

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

0 голосов
/ 13 мая 2009

Время взаимодействует с системой. Например. время идет, и система должна что-то делать, основываясь на этом "действии".

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...