How do you show specialization in a UML diagram when two specialized entities could also be each other. For example:
[Personel]
^
/_\
|
------------
| |
[Employee] [Manager]
Typically, I'd use the empty arrow to show specialization, but how do i show that an employee or manager could also have the other role in some instance? Do I just need to use a line to connect them?
In the most common form Generalization is mutually exclusive. You are either one subclass or the other, but never the two at the same time.
For the example you used you better use the Party-PartyRole pattern.
Employee or Manager are Roles a person can play. With this pattern you can be both Manager and Employee at the same time.
Related
I have two classes Person and Department with two associations between them
works and
manages,
and between these two associations there is a {subset} (manages associations are subset of works association).
What should I infer about the object diagram?
Each Person which is a manager has two links to his department (one for works and the second for manages), or
each Person which is manager has only one link to his department?
By the way, besides {subset}, {nand}, {and} and {xor}, is there any other constraint notation which you can put in a class diagram?
Since you have defined two associations the objects will have two links. Simple as that. You might add a note that works is redundant in case manages has a non-zero multiplicity (since it will have one of 0..1).
You can place any constraint you like between associations - as long as they make sense.
Superstructures 2.5 states on p.111:
<prop-modifier> indicates a modifier that applies to the Property.
<prop-modifier> ::= ‘readOnly’ | ‘union’ | ‘subsets’ <property-name> |
‘redefines’ <property-name> | ‘ordered’ | ‘unordered’ | ‘unique’ | ‘nonunique’ | ‘seq’ | ‘sequence’ | ‘id’ | <prop-constraint>
Notice that a subsets constraint can be defined between association ends (reference properies), but not between associations. So, your question should be better stated as follows. Given a class Person with the two reference properies managedDepartment and department, representing corresponding functional associations between Person and Department, the constraint
managedDepartment subsets department
implies that for any person object p, the set of departments managed by p is a subset of or eqal to the set of departments p works for. This formalizes the business rule that a person can only be the manager of a department at which (s)he works. Symbolically,
p.managedDepartment subseteq p.department
Alternatively, one could define that the manages association specializes the worksAt association, which would imply that for any manages link there is a corresponding worksAt link.
This is the best question I've seen in a while! To answer your two questions directly:
Yes, by using Person manages {subsets works for} Department, each Person who is a manager will have two links to Department: one for works for and one for manages.
Another useful constraint you can use on a property in a class diagram is {redefines}.
Redefining a property allows you to change a property's name and tighten constraints within the context of its owning class (and within the context of subclasses). For example, you can say the following things:
In general, Deck contains 0..52 Cards
A subclass of Deck called Monster Deck only contains {redefines contains} 0..10 Monster Cards
Another subclass of Deck called Player Deck only contains {redefines contains} 0..10 Player Cards
And so on..
This is very handy for expressing requirements and business rules.
I'd like to express (visually) in UML that class Foo returns class Bar. The Bar object is created in one of Foo's methods and returned as a result.
I don't know whether to use a dependency or association relationship for this. Any suggestions?
EDIT
I should clarify that the UML diagram I'm working on doesn't contain any class attributes or operations. It's just intended as an overview that shows relationships between classes. Descriptions of attributes and operations are already generated from the source code (via Doxygen).
EDIT 2
I should further clarify that I want to show this relationship from a class diagram. I apologize for not being clear from the start.
EDIT 3
Upon further digging around, looking at examples, I realized that it's more important to document that Foo creates Bar. The fact that one of Foo's methods returns Bar is an implementation detail that I can leave out of my class diagram. So now, my question is: what's the best way to show a "Foo creates Bar" relationship in a class diagram?
As I've mentioned in my third edit, I realized it was more important to document the relationship that Foo creates Bar. The fact that some of Foo's methods return Bar is a detail better left to the Doxygen documentation (in my situation anyway).
As mentioned by others, the fact that Foo returns Bar can also be represented in the operations compartment of the Foo class, or in behavioral diagrams. But in my question, I've constrained myself to only class diagrams without listing attributes and operations.
I've done some digging around, and have discovered that UML has the <<create>> predefined stereotype for a usage dependency, illustrated here as
+------------+ +------------+
| | <<create>> | |
| Datasource +-- -- -- -- -->+ Connection |
| | | |
+------------+ +------------+
The <<create>> stereotype is described in the UML 2.4.1 Superstructure specification, page 704 as:
A usage dependency denoting that the client classifier
creates instances of the supplier classifier.
A usage dependency is (UML 2.4.1 Superstructure, page 139)
a relationship in which one element requires another element (or set
of elements) for its full implementation or operation.
Furthermore:
The usage dependency does not specify how the client uses the supplier
other than the fact that the supplier is used by the definition or
implementation of the client.
The UML spec also has the <<instantiate>> predefined stereotype, defined as:
A usage dependency among classifiers indicating that operations on the
client create instances of the supplier.
There seems to be some overlap between the <<create>> and <<instantiate>> stereotypes.
Return types from methods are expressed in the method definition within the class. Most tools can turn on/off attribute and method visibility. If class Foo creates or operates on class Bar, you can use a directional association from Foo to Bar. It doesn't sound like a dependency.
This is embarrassing, I apologize for not including the diagram image ( I thought I included it, but I should be more careful and verify it in the post )
I know almost nothing about UML, but to my knowledge an arrow with hollow head represents inheritance relationship ( ie ANDSpecification class inherits from CompositeSpecification class ), while the other type of arrow tells us we can navigate from ANDSpecification to CompositeSpecification?
a) But why does the diagram connecting ANDSpecification and CompositeSpecification contain both types of arrows? Perhaps because in addition to ANDSpecification inheriting from CompositeSpecification, it also has a property of type CompositeSpecification?
b) What is the meaning of numbers next to arrows?
First of all, could you please provide the source of your class diagram implementation, your inputs are not clear enough to determine the realtionships between the classes.
(A) There are two types of arrows, the arrow with a rectangular head describes "Generalization".
The specific classifier inherits part of its definition from the
general classifier. The general classifier is at the arrow end of the
connector. Attributes, associations, and operations are inherited by
the specific classifier. Use the Inheritance tool to create a
generalization between two classifiers.
The second type of arrows describes "Association"
A relationship between the members of two classifiers. There are two
types of it, Aggregation and Composition.
(B) The numbers beside arrows simply describes "Multiplicity"
Multiplicity of an association end is the number of possible instances
of the class associated with a single instance of the other end.
┬─────────────────────────┬───────────────────────────────────────────────────────┬
│ Multiplicities | Explanation |
│ | |
├─────────────────────────┼───────────────────────────────────────────────────────┼
|0..1 | zero or one instance. |
├─────────────────────────┼───────────────────────────────────────────────────────┼
|0..* or * | no limit on the number of instances (including none) |
├─────────────────────────┼───────────────────────────────────────────────────────┼
|1 | exactly one instance |
├─────────────────────────┼───────────────────────────────────────────────────────┼
|1..* | at least one instance |
├─────────────────────────┼───────────────────────────────────────────────────────┼
You can find helpful examples in the links below.
Explanation of the UML arrows
http://msdn.microsoft.com/en-us/library/dd409437%28VS.100%29.aspx
http://edutechwiki.unige.ch/en/UML_class_diagram
I have a use case that is associated with two actors in a system. This use case extends another use case, but only one of the actors can use the extended use case.
Is there some way to represent the conditional nature of the extension of the first use case? Or, do I need to specify in the use case documentation that the initial use case can only possibly be extended for one kind of actor?
Thanks.
If I understand the question, it sounds like you need two kinds of actor. You (possibly) need to make one actor type a generalisation by abstraction. To put it another way, you need to create a specialised actor who inherits permissions of the more general actor.
( Please excuse my horrible ascii people and generalisation arrow!)
O __________________
--- / \
| -----------| Use Case 1 |
/ \ |__________________|
| extension points |
User | if Super User |
^ \__________________/
/ \ /\
/___\ | <<extend>>
| | (if Super User)
| |
| |
O _________________
--- / \
| -----------| Use Case 2 |
/ \ \_________________/
Super User
This specialised actor (Super User) can then engage in both use cases, but the normal user only the first one (the non-extending use case).
Note that a Super User may or may not be able to initiate directly use case two. It depends on the use case and the problem domain as to whether that makes sense or not.
You then probably want to use an extension point (something like "Super User" or "if Super User") in the extended use case which creates a decision point to the extending use case.
Here's an example of a more legible diagram.
Also here's the definition of extension point from The UML Reference Manual (2nd Edition) (p358):
A named marker that identifies a location or set of locations within the behavioural sequence for a use case, at which additional behaviour can be inserted.
The name of the extension point name can be whatever you want. Whatever makes sense to you. There are no syntactic rules. Whatever you put on the diagram should appear somewhere in a textual use case description (i.e., the steps of the use case).
If I had a class Airplane and a class Wing, if there was a composition relationship between the two, does Airplane have a member variable of type Wing in the class diagram, shown in the Airplane box?
ASCII art!
+-------------+ 1 1..* +----------+
| Airplane |<*>------------| Wing |
+-------------+ +----------+
where <*> represents a filled diamond, indicating composition. I used multiplicity 1..*, since it's possible to have aircraft that are essentially a single wing (such as the B-2), and although nobody builds them anymore AFAIK, you have biplanes (2 or 3 wings, depending on how you're counting), triplanes, etc.
No. Compositions and aggregations are kinds of associations and are shown like associations, i.e., with lines between classes (with solid and hollow diamonds, respectively, on the containing side). As a general rule, if you have an attribute whose type is a class, your model is wrong.
Implementation is a completely separate matter from analysis/design. You may implement associations in a variety of ways, including using member variables e.g. in C++.
I'm not sure at 100%, but as far I remember no. Is just implicit that u will'have a variable of type Wing.
No, it doesn't. But that doesn't mean that you can't have an attribute that is of class type. You just can't have both. It's a choice about what you want to emphasise.