I have a class diagram for my application which consists of several compositions and aggregations.
Now I want to have diagram based on the class diagram which shows class instances. A snapshot if you will. I need this because it would help discussing some functional requirements.
Class diagram:
-------- 1 * -------
| Parent |----------------------| Child |
-------- -------
"Instance" diagram:
-------- ---------
| Parent |----------------------| Child 1 |
-------- | ---------
|
| ---------
+-----------| Child 2 |
| ---------
|
| ---------
+-----------| Child 3 |
---------
Is there a diagram type for this? (Currently I'm mis-using a class diagram, where all my instances are separate classes)
Use Object diagram or
Use keyword <<instance>> or
Underline class name
An "instance" diagram in UML is called an Object Diagram.
You can use the "Object Diagram" as Peter G. McDonald said.
See the wiki :Object Diagram Wiki
In UML if what you want doesn't exist you can adapt classic Diagram for what you want
something just like you did but with comment block to explain your choices
Documentation is as important as diagrams.
If you want to describe the life cycle of yours instances you can use
"State machine diagram".
Related
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.
I've been asked to document a piece of code using UML diagrams. The code models a situation like the following: a driver can be assigned to one or more routes. Each route has an upstream and a downstream direction. For each route the driver can drive in the upstream direction and/or in the downstream direction.
A simplified pseudo-code is for the Driver class is the following:
class Driver:
HashMap<Route, Direction> upstream;
HashMap<Route, Direction> downstream;
HashMap<Route, Direction> assignedTo;
where the assignedTo map is actually a property returning a hashmap composed of the routes where the driver is assigned to both the upstream and downstream directions (think of it as a view on the other two hashmaps)
So far I've come up the the following UML representation.
----------- ---------
| CLASS | (assignedTo) | CLASS |
| DRIVER |----------------------------| ROUTE |
----------- * | * ---------
|
-------------
| CLASS |
| DIRECTION |
-------------
^ ^
| |
------------ --------------
| CLASS | | CLASS |
| UPSTREAM | | DOWNSTREAM |
------------ --------------
However, I'm a little puzzled by the fact that in the UML I;m using inheritance while the code uses no inheritance. What do you think?
I've changed a little but this is another sample of mine. I am not sure if I understand the shown pseudo-code correctly, but the case when assigned to both directions, it could be a problem. In my personal opinion, my sample diagram would be easier for implementation too.
Regarding the inheritance, the answer would be different what this UML is for.. to represent how to implement or to explain the concepts. If the latter, there would be no problem using inheritance.
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 am reading "UML distilled" by Martin Fowler, and during reading about association classes I got this quote:
What benefit do you gain with the association class to offset the
extra notation you have to
remember? The association class adds an extra constraint, in that
there can be only one instance of
the association class between any two participating objects.
Then there was an example, but I want to make sure I got this right, if for example I got:
--------- ---------
| |* *| |
| CLASS A |----------| CLASS B |
| | | | |
--------- | ---------
|
______|______
| |
| |
| CLASS C |
| |
|_____________|
then, for every distinct pair (instance of A,instance of B) there exists only one instance of class C.
So if I would take A1,A2,B1,B2-instances then for (A1,B1) (A1,B2) (A2,B1) (A2,B2) I would get 4 instances of C, nothing less, nothing more?
From the UML 2.5 specification:
Note that when one or more ends of the AssociationClass have
isUnique=false, it is possible to have several instances associating
the same set of instances of the end Classes.
Mr. Fowler may have gotten the facts wrong. There is no extra constraint, just the ability to store additional property values.
When isUnique=false, extra properties allow one to model multiple visits to the same doctor on different dates, or multiple purchases of the same products on different dates, for example.
That'd be correct, without any intention to mix concepts here but it's similar to Tables in a database where:
A 1-* C
B 1-* C
Where C can be seen as the result of breaking a many to many relationship between A and B.
For each row on B can only exist 1 and only 1 Row C and That Particular row (on C) can only me related to 1 row on A.
Hence, for each Pair of unique rows on A and B can only exist 1 row on C or none, because the * indicates 0 or more.
Your reasoning is correct: if an association class does not have one or both association ends annotated with {nonunique}, then it implies the constraint that there can be only one link between the same objects (as explained by Martin Fowler).
Notice, however, that the option of non-unique association ends has only been added in UML 2 (in 2005), and Martin Fowler's book (from 2003) refers to UML 1.x.
Some examples may help. For instance, the association LandPurchase between Person and PieceOfLand could be modeld as a UML association class (with default unique association ends), since there can be only one purchase link between a person and a piece of land. The association ProductPurchase between Person and Product can only be modeld as an association class if the association end at the Product side is annotated as {nonunique} since there can be more than one purchase link between the same person and the same product (as a type). For instance, I can buy more than one Tesla Model S cars (if I would have the money).
Similarly, in the case of Appointment between Person and Doctor, since the same person can have more than one appointment with the same doctor, the association end at the Doctor side has to be annotated as {nonunique}.
Association in UML represented (have) logical sens (UML is not tool for database modeling!). Association describe possible logical fact. E.g. Two person A and B could be married, we can draw this as association, it is representing meaning like a "we know that exist an logical connection between person A and person B". If we know what that is, we draw class association [marriage cerificate] as materialised fact.
Is it valid to have an Interface as part of a sequence diagram. For instance, is the following UML valid? The purpose of the interfaces is to show extensibility and testability points in the design. You could extend by providing a different implementation for each interface and better test by replacing the interfaces with mocks. However, I don't know if this violates the rules of UML. Thanks in advance.
GameService:IGameService GameRepository:IGameRepository
| |
| |
|--------------------------->|
| |
| |
| |
P.S.: Sorry for the poor's man diagram.
Yes, this is possible. Both classes and interfaces are subclasses of Classifier in the UML metamodel. Classifiers are the ones linked to the elements in the sequence diagram
Of course a lifeline in a sequence diagram can represent an (instance of an) interface. From the perspective of the diagram, it doesn't matter much---there are no restrictions on where the operations/messages on the events should come from.
If you want to indicate that the operations have to come e.g. from the signature of the target (IGameRepository), you have to document/encode this separately, e.g. in OCL.