Modeling of Actors taking on roles in SysML[ch8207]

[Brian Selvy]

On my project, I have a need to define a set of actors that can also play particular roles in various Use Cases. We're structuring our Actors library in a way where at the lowest leaf node level we're defining actors that represent specific job descriptions (and we're using abstraction via generalization relationships as needed).  

On certain use cases, we really want to show that any of a predefined subset of actors taking on a particular role can initiate a Use Case.

To be a little more concrete, here's an example:  We've defined 4 individual actors and show them on a BDD.  We show a generalization relationship from each of them to a higher level abstraction actor so that they can all inherit common attributes.

Now, we have certain Use Cases that can be initiated by someone that takes on a type of role that can be fulfilled by any one of the 4 specific actors described earlier, but it can only be one of them at any given time.  

What is the proper way to show that any one of a defined set of actors can take on a particular role?  My initial thinking was that the UML/SysML concept of Class-Object/Block-Part makes sense here.  However, I've read in SysML Distilled, section 3.8 that, "An actor cannot have parts".  However, I see in the SysML 1.3 specification in section 8.2.2 Internal Block Diagram, Table 8.3, they define something called an "ActorPart".  These two items seems to be contradictory.  Which is correct?

The way we've modeled this for now is to show "reference associations" on a BDD between the specific subset of actors and another actor describing the role with a note stating that the roll actor  can be filled by any one of the above individual actors.  I've also thought about perhaps using "open diamond"/shared associations to show this with somehow using multiplicity but I'm not sure how to properly use multiplicity to show what I want.

Have others run into this problem as well?  Is there a proper SysML way of doing this within the syntax or do others have suggestions on ways they've implemented this?

[qwerty]

I'm not sure I'm getting what you described. Is it that if one actors starts a use case then no other actor can start it the same time?

q.

[Brian Selvy]

No, qwerty, that's not what I wrote.

[KP]

So you have one (possibly abstract) Actor that generalizes the 4 concrete Actors, and you have an Association from the general Actor to the Use Case. If you want to show that there can only be one Actor associated with the Use Case, you can set the multiplicity of the Association end at the general Actor to "1".

Alternatively, you can have Associations between the 4 concrete Actors and the Use Case, and attach an "XOR" constraint to all 4 Associations.

[Brian Selvy]

KP,

Thank you for the response.  That was very helpful.  Regarding the constraint with the "XOR", do you mean to drop a constraint element onto the Use Case diagram and put in "XOR" in the "Constraint" field?  Or do you mean something else?  What does it get connected to?

[Brian Selvy]

KP - nevermind regarding my follow up questions in my previous post.  I found an online example of using a constraint element with the Invariant stereotype. This is great and will be very helpful to us in specific instances!  I really appreciate the response.