Re: [UML Forum] how to model a system where we dont know the actors but only the permissions in UML

39 views
Skip to first unread message

Remy Fannader

unread,
Mar 22, 2013, 12:56:17 AM3/22/13
to umlf...@googlegroups.com
Actors are not agents but roles, so you don't have to know them.
You matrix approach seems OK providing the outcome of the consolidation are not generic: actors are not classes so there is nothing to inherit.
http://caminao.wordpress.com/how-to-implement-symbolic-representations/patterns/functional-patterns/users/
http://caminao.wordpress.com/how-to-implement-symbolic-representations/patterns/functional-patterns/use-case-patterns/

On 21 March 2013 16:49, jamshaid ali <jamshai...@gmail.com> wrote:
i have a scenario where we are developing a product .In the end how many roles will be in the product and what permission each role will have is something that changes product by product.
How can i model actors.

1) Is making every right/permission an actor the way to go. (This gets complicated when i make sequence diagrammes)
2) Or should i make generic actors and use cases and define a relationship matrix later.  (this is i think the way to go)

I hope my choice is not misleading and would like an expert to tell me what is the standard way to go about this.
Hoping to hear from you all soon.

Thanks.


--
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to
umlforum+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en
 
---
You received this message because you are subscribed to the Google Groups "UML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umlforum+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Cedric Gava

unread,
Mar 22, 2013, 10:26:22 AM3/22/13
to umlf...@googlegroups.com
Hello

In the 2.5 UML spec for state machine (it's also true in 2.4), the semantic of resolving conflicting transition is very precise, and enforces à priority of inner transitions over outer (see 2012-10-24 p328).

In the aim of implementing a subset of UML SM in a HDL language, I would better have chosen the exact opposite : outer over inner :(

Does someone know why this priority has been chosen in the UML spec (the answer may need a bit of history of UML which miss) ?

Aside, my other question would be : is there a chance that proposing an evolution of the std to parameterize this priority in the state machine MetaElement could be accepted (if hard debates have already taken place on this subject, then no chance... if the semantic has just been fixed this way, just by convenience, then maybe It could change).

The objective is that, in some low-level non Object-Oriented implementation of the SM, the switch case construction is the best way to achieve the state machine behavior, BUT achieving the inner to outer priority semantics leads to less performant design.

Thank you for your answer on this topic.
Best regards
Cedric

H. S. Lahman

unread,
Mar 22, 2013, 11:37:05 AM3/22/13
to umlf...@googlegroups.com
Responding to ali...

> i have a scenario where we are developing a product .In the end how
> many roles will be in the product and what permission each role will
> have is something that changes product by product.
> How can i model actors.
>
> 1) Is making every right/permission an actor the way to go. (This gets
> complicated when i make sequence diagrammes)

Usually not. Actors are external entities that interact with the
software being designed. They can be users, other software, or even
hardware. Typically they are generic based on broad classes of entities
in the problem space. Thus the problem space may regard system
administrators as different than sales clerks and that distinction may
be important to the problem being solved by the software. But the
software doesn't care whether a particular sales clerk is Fred or Carol.

The notion of rights and permissions is orthogonal to entities. At best,
it is a characteristic of a particular entity, like a sales clerk.
Typically it is part of the login procedure for a particular user in the
actor class to identify characteristics of the actor in hand that are
important to the solution of the problem. That can be done by
registering the particular sales clerk or the sales clerk can supply the
information each time the entity logs in.

> 2) Or should i make generic actors and use cases and define a
> relationship matrix later. (this is i think the way to go)

This would usually be the case. But the push back is: what
relationships? Between agents? Between agents and requirements? Between
agents and the software? Between requirements?


--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

Imagine how much more difficult physics would be if electrons had feelings
-- Richard Feynman

Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.

H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
software book: Model Based Development, Addison-Wesley, 2011
geology book: The Evolution and Utilization of Marine Resources, MIT Press, 1972

Remy Fannader

unread,
Mar 24, 2013, 1:14:38 AM3/24/13
to umlf...@googlegroups.com
--
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to

For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en

--- You received this message because you are subscribed to the Google Groups "UML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umlforum+unsubscribe@googlegroups.com.

H. S. Lahman

unread,
Mar 24, 2013, 12:27:28 PM3/24/13
to umlf...@googlegroups.com
Responding to Fannader...

Actors are not external entities but roles played by external entities.

You are quibbling. Yes, Jacobson defined actors as classes that could be viewed as roles. But he was very clear that the members of those classes were concrete entities external to the software and those individual entities interacted with the software, which is what I said. He was also clear that an actor class could be viewed in other ways than roles, like job descriptions.

Remy Fannader

unread,
Mar 24, 2013, 3:41:30 PM3/24/13
to umlf...@googlegroups.com
Actors in use cases should not be confused with the classes that may or may not represent them. Those are two very different artifacts.
http://caminao.wordpress.com/how-to-implement-symbolic-representations/patterns/functional-patterns/users/
Remy.

--
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to

For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en
 
---
You received this message because you are subscribed to the Google Groups "UML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umlforum+u...@googlegroups.com.

H. S. Lahman

unread,
Mar 25, 2013, 11:26:17 AM3/25/13
to umlf...@googlegroups.com
Responding to Fannader...

> Actors in use cases should not be confused with the classes that may
> or may not represent them. Those are two very different artifacts.

Since Jacobson invented use cases and actors, I think I will stick with
his view.

Remy Fannader

unread,
Mar 31, 2013, 12:33:58 AM3/31/13
to umlf...@googlegroups.com
Perseverare diabolicum.

--
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to

For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en

--- You received this message because you are subscribed to the Google Groups "UML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umlforum+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages