my dog learned polymorphism*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Use Case Actors Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Use Case Actors" Watch "Use Case Actors" New topic
Author

Use Case Actors

Philip Pomario
Ranch Hand

Joined: Oct 03, 2003
Posts: 113
Guys,

The specs for Part II describe two actors: TA and C. Even though both can purchase items on the system, in practical terms they could be doing it to another person, say his/her daughter or colleague. My questions would be: did you create a third actor called user that was a generalization of TA and C? Could I do that wrt the specs? How did you solve this issue?

Your thoughts are much appreciated.

Regards,
Filipe
Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

Originally posted by Filipe Pomar:
... in practical terms they could be doing it to another person, say his/her daughter or colleague.



If you can explain the scenario outside of the context of the assignment, you could probably elaborate on this topic enough so that this might make more sense to those of us that don't share the same assignment. Are you saying that someone could buy an item for someone else or that a person could serve as a middleman between the customer and the system?

I'm having trouble picturing this. It sounds as though you are asking about a generalization of actors, which I suppose could make sense but would still in most cases be clearer not to do so.


A good workman is known by his tools.
Philip Pomario
Ranch Hand

Joined: Oct 03, 2003
Posts: 113
Good idea!

Let's then say that the assignment defines Use Cases for an online system of a medical clinic. There are two actors: one is Secretary and the other is Patient. It's not said but I, as the architect, would imagine that a mother could use the clinic's website to make an appointment to her daughter (the real patient), or that the Secretary could make appointments for other patients.

My questions: should I go as far as defining a third actor called User to solve this issue? Is there an alternative to creating this new actor? Since it would be required to tweak a bit the provided Analysis, would it be too much of a risky move?

I would appreciate your comments.

Regards,
Filipe
Deepak Bala
Bartender

Joined: Feb 24, 2006
Posts: 6662
    
    5

Originally posted by Filipe Pomar:
Good idea!

Let's then say that the assignment defines Use Cases for an online system of a medical clinic. There are two actors: one is Secretary and the other is Patient. It's not said but I, as the architect, would imagine that a mother could use the clinic's website to make an appointment to her daughter (the real patient), or that the Secretary could make appointments for other patients.

My questions: should I go as far as defining a third actor called User to solve this issue? Is there an alternative to creating this new actor? Since it would be required to tweak a bit the provided Analysis, would it be too much of a risky move?

I would appreciate your comments.

Regards,
Filipe


Perhaps you could assume that the mother uses her daughter's ID to login and fix an appointment ? You need not save or represent information about who actually made the appointment. What is important is who the appointment is for. Many assumptions and solutions are possible for this kind of thing each with their pros and cons.

You have an assignment for a online medical system or were you just giving an example ? (I am asking out of curiosity )


SCJP 6 articles - SCJP 5/6 mock exams - More SCJP Mocks
Bojan Knezovic
Ranch Hand

Joined: Nov 20, 2003
Posts: 90
Originally posted by Filipe Pomar:
Guys,

The specs for Part II describe two actors: TA and C. Even though both can purchase items on the system, in practical terms they could be doing it to another person, say his/her daughter or colleague. My questions would be: did you create a third actor called user that was a generalization of TA and C? Could I do that wrt the specs? How did you solve this issue?

Your thoughts are much appreciated.

Regards,
Filipe



I was always recommended to model only direct interaction with the system - it doesn't matter if the reservation is for daughter or colleague. You are modeling a system and users that use that system directly.

Regarding generalization, it's almost always possible to generalize actors and it depends on the situation but, again AFAIK, it's not a recommendable practice.

HTH,
Bojan
Philip Pomario
Ranch Hand

Joined: Oct 03, 2003
Posts: 113
I agree with you're all saying. Though, the problem persists: how would it be possible to the Secretary make appointments for other people if we model each actor making appointments for his/her own?

P.S.: This is not from the real exam, just an analogy.
Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

For use case diagrams, the important thing to clarify is the actor's role. I think this would be clearer if you were designing a system that gives different types of people different privileges: Administrator, Manager, Clerk, etc.

But let's say we're dealing with a system like the one you are mentioning... but for filing taxes. Let's say that an individual can file their taxes to the system or they can talk to an agent from a specific office who has the rights to log into the system on the individual's behalf and file for them. In this scenario, the agent has no extra system functionality available aside from the ability to log in as other people.

Now this is a case where you might want to have the Agent role be a generalization of Taxpayer, with the extra use case of "Login as any Taxpayer".

I think that even in this case I could understand lumping "Taxpayer,Agent" into a single actor in the diagram and not mentioning a use case of "Login as any Taxpayer".

Craig Larman's Applying UML and Patterns says that use cases should be limited to things that add business value. He argues that logging in is not a use case because it does not pass a simple test: imagine your boss asking what work someone accomplished using the system and that your response can use just the one use case. "I logged in 42 times today, boss!" Larman recommends to simply make logging in be a prerequisite to the use cases that require it.

Really it comes down to doing what you believe will be the clearest way to communicate your ideas. Sometimes when you feel conflicted about which of 2 ways to represent something, sketch them both and decide which of the two would appear less confusing to the person who will need to read it.
Henrique Ordine
Ranch Hand

Joined: Sep 03, 2004
Posts: 127
Hi Filipe,

I wouldn't add another Actor to the use case. I would add an extra step in the use case saying that the logged in user, either Secretary or Patient, chooses the actual patient for whom the appointment is being made.


J2EE Architect/Developer
Philip Pomario
Ranch Hand

Joined: Oct 03, 2003
Posts: 113
Henrique,
I believe that your solution would be the best fitted to solve this problem, BUT I cannot do that. Sun's spec. doesn't allow me to change the system's requirements - which are, btw, "written on stone".
Henrique Ordine
Ranch Hand

Joined: Sep 03, 2004
Posts: 127
Right, but I have read some posts here about an Assumptions file which you can send with your assignment. Maybe you could list that step as an assumption. Don't take my word for it, though. I'm not completely sure about this file.
Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

Originally posted by Filipe Pomar:
Henrique,
I believe that your solution would be the best fitted to solve this problem, BUT I cannot do that. Sun's spec. doesn't allow me to change the system's requirements - which are, btw, "written on stone".

Right, use cases typically are written by a BA and not an Architect. I don't think the issue being discussed really would apply to an assignment's deliverables. Mentioning that you don't agree with something, unless it directly effects one of your deliverables, isn't appropriate for the assumptions list.

A sequence diagram made by the architect could, however, include a note explaining context about the initiating actor.
Philip Pomario
Ranch Hand

Joined: Oct 03, 2003
Posts: 113
Very interesting insights, thanks everyone for your comments!

So far the most appropriate solution I could find to the "Medical Clinic" problem is: a Patient can only make appointments for him/herself. So if a mother wanted to make an appointment for her daughter, she would have to login as her daughter or call the Secretary. The Secretary would need to have some special rights (not defined in the specs.) that could allow her to impersonate the "daughter" and make the appointment. I'm not sure if I could enhance the system's requirements as described in the Secretary case .

Let me know what you think.

Kind regards,
Filipe
Deepak Bala
Bartender

Joined: Feb 24, 2006
Posts: 6662
    
    5

Originally posted by Filipe Pomar:
Very interesting insights, thanks everyone for your comments!

So far the most appropriate solution I could find to the "Medical Clinic" problem is: a Patient can only make appointments for him/herself. So if a mother wanted to make an appointment for her daughter, she would have to login as her daughter or call the Secretary. The Secretary would need to have some special rights (not defined in the specs.) that could allow her to impersonate the "daughter" and make the appointment. I'm not sure if I could enhance the system's requirements as described in the Secretary case .

Let me know what you think.

Kind regards,
Filipe


That is precisely what was on my mind. [Assume] The secretary can always choose from a drop down list the patient for whom the appointment is to be made. I think approaching it this way makes sense. Good luck with your approach
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Use Case Actors