In this beginners guide to Dependency Injection I noticed that the UML diagram distinguishes between "uses" and "depends upon".
Since both require some form of a reference in the class that "uses" or "depends upon", I wonder: What is really the difference between the two?
Check out the blockquotes about relationship types taken from IBM Rational Software Architect documentation.
"depends upon" means the following:
A dependency relationship indicates
that changes to one model element (the
supplier or independent model element)
can cause changes in another model
element (the client or dependent model
element). The supplier model element
is independent because a change in the
client does not affect it. The client
model element depends on the supplier
because a change to the supplier
affects the client.
"uses" means the following:
A usage relationship is a dependency
relationship in which one model
element requires the presence of
another model element (or set of model
elements) for its full implementation
or operation. The model element that
requires the presence of another model
element is the client, and the model
element whose presence is required is
the supplier. Although a usage
relationship indicates an ongoing
requirement, it also indicates that
the connection between the two model
elements is not always meaningful or
present.
As I read it "usage" is a less strict "dependency".
"Uses" is where one Class refers to another Class for some of it's operations.
"Depends on" is where a Class A uses another Class B within it's implementation (e.g. as a parameter to a method). In this case changing Class B may necessitate a change to class A.
Note I've said Class, but it applies equally to Interfaces.
Wikipedia has a good article on this: http://en.wikipedia.org/wiki/Dependency_%28UML%29
So for example you could have a Uses relationship between a Class Driver and an Interface IVehicle which exposes a method called Drive(). Changes to the implementation of Drive do not require any changes to Driver, so you say Driver uses IVehicle.
However Class Driver has a Dependency on Class Hand, since Driver has two properties: Hand LeftHand and Hand RightHand. If the implementation of these changed, one would need to consider if Driver needed updating accordingly.
Related
The above statement is taken from www.uml-diagrams.org section Assocation ends from the rather beginning.
Is there a real-world example for this?
What exactly means owned by association itself?
What is association class or how is it implement in code?
Here's my attempt. I also was unsure about the nature of an association in the past and until not so long ago where I sort of grasped it. For the full pain you have to go through pp. 197 of UML 2.5 (11.5 Associations)
What is an association?
When you have a number of classes (we may call them A, B, etc. here for brevity. They are designed to be somewhat self-consistent. So you have properties and operations which work with the latter. If our A is some mathematical class you may have a well working black box. Fine.
Now, when any class is in need of another (e.g. the B class needs objects of type A to have that math toolbox handy) you create some reference. In a programming language that will be some variable holding a reference to an instance of the needed class. That's the moment where you have an association.
In UML you can denote such an association as a property typed with the other class. Or (!) you draw a line for an association between both class boxes and place the role name towards the referenced class (telling the name of the variable the programmer shall use). This being quite simple got me some headaches since I saw notations with both property and role notation. I have not fosteres the UML spec as tho what this would mean, but I established a rule I was also teaching that this is not allowed. Tools like EA do not support roles in a correct way which forces you to manually maintain your diagrams. That is, if you have an association role from B to A and the diagram does not contain A then you should show the role as property (see my note about dot notation below). But once you place A on that diagram you should see the assocation line with the role name, but not the property (pretty confusing I admit).
Note: Dot notation
Since UML 2.5 (or was it 2.1?; but see p. 200 of UML 2.5) the OMG guys introduced the so called dot notation. That is, you have a little dot at the association line end along where the role name is. This dot indicates that the role name is actually the property of the referencing class. Pretty much what I was talking about above. And what I thought was the intention. So, I have no idea what a not-owned property would be in any case. May be a good question to be asked.
Associaton class
Assume you have class C which reflects some kind of relation between A and B (and eventually D, E, etc.). Doing that makes it an association class. It's doing that by exactly the same technique as above, just for multiple classes. (If a class has multiple relations to other classes it's not necessarily an association class, but only if it's main purpose is to set these into some relation. YMMV)
So here you have the case where an association owns the role since you have a real object. The association explained above exists only as a reference in the programming world, not a complex storage structure like an association class.
First of all, you should understand that, as opposed to the explanation of #qwerty_so, in data/information modeling, relations between two objects (called "links" in UML) are a first-class citizen. Logically/conceptually, they exist next to objects. In terms of OO implementation, they may exist either within one or both of the two participating objects in the form of object references, or outside of the two participating objects in the form of another object representing the "link".
Likewise, in data/information modeling, an Assocation, which classifies "links", is a first-class citizen that logically/conceptually exists next to the involved Classes. A binary Assocation is implementated either within one or both of the two (Java/C#/JS/etc.) classes involved in the form of a reference property (or possibly two mutually inverse reference properties), or outside of the two classes in the form of another class representing the Assocation.
In the case where a binary association has one ownership dot at one of its ends, it is unidirectional and implemented as a reference property in the corresponding class, while in the case where it has ownership dots at both of its ends, it is bidirectional and implemented as two mutually inverse reference properties, one in each of the involved classes.
What exactly means owned by association itself?
An Assocation End of a binary Assocation can be owned either by the Class on the opposite side or by the Assocation itself. In the former (more common) case, the Assocation End corresponds to a reference property of the (Java/C#/JS/etc.) class on the opposite side. In the former (less common) case, the Assocation End corresponds to a reference property of the (Java/C#/JS/etc.) class that represents the Assocation.
In principle, there could be an OOP language that supports Assocations as first-class citizens, having a keyword "assocation", in addition to "class".
What is association class or how is it implement in code?
The need for an Association Class arises when the "links" of an Association have to be characterized with the help of attributes, or when they have to be processed with the help of special operations. In such a case, an Association Class allows defining these attributes or operations. An Association Class is implemented in the form of a (Java/C#/JS/etc.) class that has corresponding reference properties for each of the Association's ends.
I am modeling a movie tickets system in UML. I need to use MVC so I must have a Model; which controls the available tickets in data base, a View; which asks the customer for some data and a Controller; which controls everything and is the path between Model and View. The thing is, I model this system like this:
but my teacher said that I can't use a Composition relationship between the Controller and the View and Model. But I don't understand why because if I initialized the Model and the View inside the Controller (so it can control everything), when the Controller dies, both (Model and View) will not exist anymore. My teacher said I must use an Association relationship. Can you tell me what is the right relationship and why?
The Controller in the MVC pattern manages the interaction between the Model and View, which are both independent things that can exist on their own, therefore it references them (association) they are not composite parts of it (composition).
I would also note in your UML class model example that the terms Model, View and Contoller are solution constructs in a design pattern, rather than specific types that you must have in your design or implementation. The "Model" in your scenario is probably in fact the Ticket business entity, and probably a bunch of other entities as well. The "View" is probably a "TicketDetailsView" or "ListTicketsView" and the "Controller" would be a "TicketController". In the original MVC pattern that was embedded in SmallTalk a View read the Model directly, and the Controller manipulated the Model, whereas there are now many variants of the MVC pattern in which the associations are not quite the same (MVP, MVVM, MVPC, Page Controller, and so on).
For reference I would highly recommend reading Fowler (https://martinfowler.com/eaaDev/uiArchs.html).
The UML specs on p. 110 says:
composite - Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).
Composite aggregation is a strong form of aggregation that requires a part object be included in at most one composite object at a time. If a composite object is deleted, all of its part instances that are objects are deleted with it.
So that makes clear that the controller can not compose the Model because thats what permanently stores data. A composition would mean: if the controllers dies, the model shall die too.
About the shared aggregation you use (same box on p. 110):
shared - Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
So you need to specify what you actually mean when using it. Or (even better) just leave that diamond away!
Is there a must that in the UML class diagram, if two classes are not linked, then there cannot have a connection between those classes's lifeline? For example if I have a void function public void sample(actor a) since it's just a parameter so there is no link between two classes, but is it possible that in sequence diagram that that is a link between two to perform certain actions?
I think it can be and I actually found some images to prove it(not too sure if I have misunderstood the images) but my tutor says I'm wrong that there is no link between two lifelines if there is no link between two classes. So I'm not too sure about the answers.
Assuming that by "link" you actually mean "message" (solid arrow), you need an association. A message is equal to an invocation of a class' operation. To be able to do that, the caller must have a reference to the called class - an association.
No , is is not necessary to have association or any other relationship defined explicitly between classes which instances communicate in class diagrams. If you need to depict that instances of specific classes are connected in interaction (communicates) , you can use Collaboration element and connectors. Connector defines communication relationship, but does not define how it is physically implemented. In some cases it can by realized by link of course.
Message between lifelines implicitly defines communication relationship between lifeline's types.
I am designing a class diagram for an assignment. In this design, I use a separate class called Currency, to define currency values and their functionality. there are at least four other classes have to use this Currency class.
How can I show it in the class diagram ? I mean, do I need to draw relationships (connecting lines) from the Currency class to all the others ?
Is there a better way ?
What am I doing wrong here ?
There is nothing wrong and a reusability of a class is valuable. Actually that's a standard situation.
If you use this class in another class as an attribute you have two options to depict that:
draw an association relationship (line) from the class using to the class that is used.
put the attribute in a proper compartment of a class that is using and as a type of an attribute (after a colon) put the name of the used class.
The benefit of the first approach is that you immediately see the dependency between the classes.
If you use a class but not directly as an attribute type you use other relationship types that suit best to the situation you want to describe.
As I imagine one of your concerns is that you'll have a lot of relationships pointing to your class (in your case Currency). Don't worry about that. You don't have to put everything in a single diagram. Put a full specification of your class on one diagram with those relationships where it uses something else and then put only the class box with a name (without any compartment) on diagrams defining those elements that use your class. It will make your model readable. And with a support of some CASE tool you will be able to see all relationship and dependencies of this class anyway. By the way that's how the UML specification is written. Look for example how Namespace is used in the diagrams there (and many others as well).
Of course I'm not suggesting creating one diagram per one element to define it. No. Collect them in logical Packages (hey - that's exactly what Packages are for!) and make a class diagram per Package. If the Package becomes too large - you might need to split it into smaller subpackages.
For Currency your Package would be probably something like Utils. It can also contain other elements like Date, Address etc. Note - these are typical examples, probably every analyst/designer/programmer sooner or later has to cope with those elements. If you build them well, you'll be really able to reuse them in future applications as well.
One last thought. While you build "package based" Class diagram you might also need a diagram that shows just specific parts coming from several Packages to clarify some bit of your system/business/whatsoever. This is also absolutely fine. Again a benefit of CASE tool here is that it keeps consistency in your model.
What is the best UML diagram type to use when trying to show how a class' behavior flows from one method to another?
I am trying to diagram existing code and the behavior I am looking at primarily involves private method calls, with a few calls to static objects outside the class. I don't feel that a sequence diagram would give the best detail in this case since the class in question doesn't interact with any other classes except for the very few static calls mentioned earlier.
What would fit best in this situation?
According to the UML Superstructure (http://www.omg.org/spec/UML), in the UML two kind of behaviors exist: emergent behaviors and executing behaviors.
An executing behavior is performed by an object (its host) and is the description of the behavior of this object.
An executing behavior is directly caused by the invocation of a behavioral feature of that object or by its creation. In either case, it is a consequence of the execution of an action by some related object. A behavior has access to the structural features of its host object. Objects that may host behaviors are specified by the concrete subtypes of the BehavioredClassifier metaclass.
Emergent behavior results from the interaction of one or more participant objects. If the participating objects are parts of a larger composite object, an emerging behavior can be seen as indirectly describing the behavior of the container object also. Nevertheless, an emergent behavior can result from the executing behaviors of the participant objects.
You can model behaviors by means of Activities or Interactions (actually you may also use state machines and use cases). Activities are more adapt to model executing behaviors while Interactions to model emergent behaviors.
Now if your class has many parts and its behavior you want to model consists in a "complex" interaction of its parts then probably an interaction diagram (sequence) may be the right choice. Otherwise, if the behavior you need to model, consists of a sequence of atomic actions an activity may be better. Consider in UML there is a specific actions to represent the invokation of a method (CallOperationAction) which takes as input pin the object reference you can retrieve by means of a dedicated action (ReadSelfAction). There is also an action to read an object attribute (ReadStructuralFeatureAction).
Also check the Foundational for Executable UML Models (FUML) http://www.omg.org/spec/FUML
While all of the previous answers are correct, I would like to add the option of using a State-Machine to define the behavior of the class. State machines allow you to show what is the current state of the class and how the state of the class changes as methods are called or events are received. Since you state that you are mostly modeling one class, I think the most important thing to show is what can be done (what method calls can be called) depending on the current state and how these method calls affect the state of the class. One think I really like about state machines is that they have relatively well defined semantics and also have ways to show information at different levels using composite and orthogonal states.
Broadly you have 2 choices (per #Silli's answer): sequence or activity diagram. I would probably have suggested sequence diag as first choice, however you say you don't think that's appropriate. Could you elaborate why?
Perhaps it's conditional logic? If so an activity diagram may be the better choice. It has more intuitive syntax for showing control flow than a sequence diagram. You could also show the static objects in separate swimlanes - so clearly differentiating calls to external objects. You can also illustrate parallel behaviour if that's relevant to you. Some good examples here if it helps.
hth.
I would recommend collaboration diagram (UML 1.x) renamed to Communication diagram (UML 2.x).
This may be better than sequence diagram, better because it may be more readable in your case.
A Communication diagram models the interactions between objects or parts in terms of sequenced messages. Communication diagrams represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system.
http://en.wikipedia.org/wiki/Communication_diagram