Is it possible for a use case to have more than one actor?
And if it is, do you know of a good reference where I can find that information (book, webpage) because I am having a problem with a diagram I made for a test.
Thanks.
Although the UML spec allows to use multiple actors an despite the fact that I have used primary and secondary actor(s) in use cases in the past I have come to the conclusion that a use case shall have only a single actor. When you go down to that paradigm you will find that the use case cut is much easier and clearer than when using multiple actors. Please see the following slides that explain this in more detail: http://de.slideshare.net/putchavn/usecase-case-is-a-dialog-not-a-process
Yes, a use case can have associations to multiple actors
The only true source for this information is the UML specification on uml.org
From UML 2.5 beta2 -> 18.2 Classifier Descriptions -> Actor -> Constraints
associations
An Actor can only have Associations to UseCases, Components, and
Classes. Furthermore these Associations must be binary.
inv: Association.allInstances()->forAll( a |
a.memberEnd->collect(type)->includes(self) implies
(
a.memberEnd->size() = 2 and
let actorEnd : Property = a.memberEnd->any(type = self) in
actorEnd.opposite.class.oclIsKindOf(UseCase) or
( actorEnd.opposite.class.oclIsKindOf(Class) and not
actorEnd.opposite.class.oclIsKindOf(Behavior))
)
)
There are no constraints relative to the relation to the actor on the side of the use case
Related
Let's say I have class A with associations to classes X, Y, and Z, respectively. I need to indicate that only one of these associations may be instantiated for any given instance of class A (so, an xor constraint). I know how to do this if the constraint is just across two associations. Obviously I can just make three seperate xor constraints (X-Y, X-Z, Y-Z) but I'm wondering if there is a better/cleaner/proper way to do it?
edit: The multiplicity constraints on the respective associations are not the same. Using an abstract class or interface will not work. Furthermore, a note is insufficient. I need to use some sort of formalized structure, preferably something standardized (e.g. by OMG) to express this because I am programmatically processing the model elements (i.e. it isn't just a picture). I understand how the underlying model for UML provides for this facility. It also specifies (though slightly vaguely) how it should be notated. I guess my main issue is, in fact, with finding a tool that allows me to make that notation. I don't think MagicDraw does so. I should have stated these things earlier.
FWIW, I'm using MagicDraw. It would be a nice bonus if the I could do this in a way that MagicDraw actually understood. I can live with it if that isn't possible.
The xor constraint is just a stylized and rather under-specified constraint for the 2-way case.
You can define an explicit constraint (in Complete OCL) as:
context A
inv OnlyAorBorC: A->size() + B->Size() + C->size() <= 1
MagicDraw may allow you to specify a similar contextual Constraint on A.
If "X", "Y" and/or "Z" can be somehow generalized (I mean, if you not doing this puraly for a conditional flow control), you can make an interface (or and abstract class) "I" for example, and make "X", "Y" and "Z" implement this interface. Then, you put an association with multiplicity 1 between A and the interface I.
See the diagram below:
Edit: The example above doesn't work in the case of A having different cardinalities between X, Y and Z. For this case, the only way that I can see is use an UML Constraint to restrict those relationships. You can define a Constraint in UML putting some OCL expression between curly braces. E. g.
Here, account owner is either Person or Corporation and this {xor} is predefined UML constraint.
I'm not sure about the details of your cardinalities requirements but, a combination between this {xor} and the interface example that I gave might be enough. At least it gives you a little bit more of options, like:
If you need to know more about the UML constraints subject, I got this example from uml-diagrams.org: http://www.uml-diagrams.org/constraint.html
I have a use case diagram, which has three Actors: User, Librarian and Staff.
The Staff and Librarian actors are specializations of the User actor, and in the Use Case diagram they each have some extended use cases associated only to them.
In the sequence diagram, how do I show that the Librarian actor is a specialization of the User actor?
Can the specialized actors (Librarian and Staff) have their own timelines in the Sequence diagram?
Do I have to show a timeline for the generalized actor, even if it has no extra uses cases or actions over its specializations?
Is it OK to re-arrange the Timelines of a sequence diagram once it has been extracted out into its own diagram, using an Interaction Use box in the main sequence diagram?
In the sequence diagram, how do I show that the Librarian actor is a specialization of the User actor?
There's no way (as far as I know). You can show this relationship in UML Use Case Diagram and even better in UML Class Diagram
Can the specialized actors (Librarian and Staff) have their own timelines in the Sequence diagram?
Yes, assuming they both play a role and interact in the scenario which the Sequence Diagram captures
Do I have to show a timeline for the generalized actor, even if it has no extra uses cases or actions over its specializations?
No, you don't have to show formally correct but otherwise useless artifacts in your diagrams, unless a followup code generation (or MDA) tool forces you to do so
Is it OK to re-arrange the Timelines of a sequence diagram once it has been extracted out into its own diagram, using an Interaction Use box in the main sequence diagram?
I'm not sure, but probably yes, if you keep binding of inputs and outputs and information identifying the lifeline clear and valid. Some articles where the correct answer might be hidden:
Source: uml-diagrams.org: UML Sequence Diagrams → Interaction Use
...One constraint imposed by UML specification that is sometimes difficult to follow is that the interaction use must cover all involved lifelines represented on the enclosing interaction. This means that all those lifelines should be somehow located near each other. If we have another interaction use on the same diagram it could be very tricky to rearrange all involved lifelines as required by UML
Source: www.omg.org/spec/UML/2.5/Beta2
17.7 Interaction Uses → Semantics → Part Decompositions
Decomposition of a lifeline within one Interaction by an Interaction (owned by the type of the Lifeline’s associated ConnectableElement), is interpreted exactly as an InteractionUse. The messages that go into (or go out from) the decomposed lifeline are interpreted as actual gates that are matched by corresponding formal gates on the decomposition.
As the decomposed Lifeline is interpreted as an InteractionUse, the semantics of a PartDecomposition is the semantics of the Interaction referenced by the decomposition where the gates and parameters have been matched...
17.7 Interaction Uses → Notation → PartDecomposition
PartDecomposition is designated by a referencing clause in the head of the Lifeline as can be seen in the notation sub clause 17.3.4 (Lifeline) (see also Figure 17.21).
If the part decomposition is denoted inline under the decomposed lifeline and the decomposition clause is “strict,” this indicates that the constructs on all sub lifelines within the inline decomposition are ordered in strict sequence (see 17.6.4 (Strict interactionOperator)...
Figure 17.21 PartDecomposition - the decomposed part
...
Let's say I have class Foo that has an association to some thing(s) that fulfill(s) a role. This role could be fulfilled by either (strictly) one Bar xor any number of Baz. Similarly, the role might be fulfilled by either any number or Bar xor any number of Baz (but a mixed collection is intolerable). Are there reasonable ways to represent these in a class diagram using only associations, classes, and interfaces? I would (really) like to avoid using OCL or constraint elements.
(The reason I would like to avoid these is because we are generating code from our UML. We have already implemented generation that handles associations, classes, and interfaces. Dealing with OCL would be quite the task. Constraint elements wouldn't be so bad but still quite a lot of work.)
I would start with the picture below and create several different versions before deciding which one generates best code (junior-40).
The yellow blocks represent necessary "glue code" needed to straighten your example against your other requirements
Consider creating an abstract class Thing and derive Bar and Baz from it. It abstract the whole role, can contain some own atts and methods if needed and is quite flexible and extendible.
Now Account has an association only with AccountOwner (role "role", as Jim L. has explained in his comment, a role name must be unique in this context).
Note that this does not eliminate the need of some additional restrictions. For example, all linked "roles" should be of the same type. Sometimes is not easy (or even possible) to remove all restrictions. Otherwise we would make complete systems out of class diagram. I agree though, that as much information as possible should be contained in classes, their taxonomies and features (atts, assocs and methods).
EXAMPLE:
EXAMPLE 2 (after comments):
This version overcomes the need to use OCL ant yet keeps the simplicity and flexibility:
Multiplicities are now also derived and refined for each concrete "role". No OCL needed. :)
You add a constraint on the class in OCL:
(self.role->exists(r|r.oclIsType(Bar)) and self.role->notexists(r|r.oclIsType(Baz)) ) or
(self.role->exists(r|r.oclIsType(Baz)) and self.role->notexists(r|r.oclIsType(Bar)))
You can try this out with MDriven Designer.
The reason for introducing OCL (object constraint language) in the UML specification was just this; ability to add constraint not possible or practical to convey with simple cardinality and type information
Could this image help you ? It is extracted from the norm.
Are you thinking of something like the following:
(source: uml-diagrams.org)
Where Account is your Foo, Person is your Bar, and Corporation is your Baz.
You can then specify multiplicity on each of the two associations: [1] for Bar (Person) and [1..*] for Baz (Corporation).
I have a parent use case. I don't want to let the user use the parent use case. I only want the user to have access to child use cases. Think of it as an abstract class in Java. You can never instantiate an abstract class. Do use case diagrams allow such behavior?
Yes, there can be "parent" or "child" use-cases. The connector that is used to model this relationship is called a generalization. See here: Use case generalization versus extension An example including diagrams is also given there.
Please note: If you model a generalization to a use case, then that's something else (!) than to <<extend>> one.
You can add remarks on invocation constraints in your textual use case description.
#observer's answer is almost perfect (i've +1'd it :)), except that he does not fully answers your question.
What you might do in your case is as follows:
Actor0 will manage to Pay bill, either with Pay with
credit card or Pay with PayPal.
In the other hand, Actor1 will only be able to Pay with credit card.
Which means:
Use generalisation to model the relationshipt between your "parent" use case and its "children".
Let the actor that you want to "access" only one child, to be associated to only THAT Use Case.
Yes! (and final too, since UseCase is a specialization of Classifier).
Quoting the Unified Modeling Language (OMG UML),Superstructure:
Generalizations
UseCase (from UseCases) specializes BehavioredClassifier (from BasicBehaviors, Communications).
BehavioredClassifier specializes Classifier (from Kernel, Dependencies, PowerTypes, Interfaces).
Attributes: Classifier has the following attributes:
isAbstract: Boolean (if true, the Classifier does not provide a complete declaration and can typically not be instantiated).
isFinalSpecialization: Boolean (if true, the Classifier cannot be specialized by generalization).
Constraints: a classifier may only specialize classifiers of a valid type.
self.parents()->forAll(c | self.maySpecializeType(c))
Additional operations
The query maySpecializeType() determines whether this classifier may have a generalization relationship to classifiers of the specified type. By default a classifier may specialize classifiers of the same or a more general type.
Classifier::maySpecializeType(c : Classifier) : Boolean;
maySpecializeType = self.oclIsKindOf(c.oclType)
And last, but not least, even though it says that maySpecializeType() "is intended to be redefined by classifiers that have different specialization constraints"... there is no redefinition of maySpecializeType() for UseCase or BehavioredClassifier.
Source: Unified Modeling Language (OMG UML),Superstructure, Version 2.4.1.
Your terminology is a bit off but in general the answer is yes.
There is no such term as "parent" or "child" use-case. Normally a use-case is a behavior triggered by user. What you seem to be needing is described by the include relationship between a base and included use-case. It's used to extract the common functional blocks to be reused by different use-cases. For example:
See some more info here: What's is the difference between include and extend in use case diagram?
Is it legal to draw up an include relationship between two use cases that are each associated with a different actor?
Yes this is legal, but I think it should not interpreted as #vainolo suggested.
Suppose this scenario
In this case Actor X has direct access to Use Case A and because Use Case B is included by Use case A Actor X also executed the behavior described in Use CAse B
But only Actor Y has direct access Use Case B.
Actor A only has indirect access through Use Case A
At least that is how I interpret it. The UML specs will only tell you this is a valid UML syntax but will not say much about the meaning of such a scenario.
It's completely legal. What this means is that if the including use case calls the included use case, the actor that is connected to this use case is required.