I have recently been studying UML and drawing simple diagrams with ordinary plain arrows between classes, but I know it's not enough. There are plenty of other arrows: generalization, realisation and etc. which have meaning to the diagram reader.
Is there a nice resource which could explain each arrow (ordinary, plain, dotted, diamond-filled, diamond)?
It would be the best if it will have some code examples for them.
Here's some explanations from the Visual Studio 2015 docs:
UML Class Diagrams: Reference: https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2015/modeling/uml-class-diagrams-reference
5: Association: A relationship between the members of two classifiers.
5a: Aggregation: An association representing a shared ownership relationship. The
Aggregation property of the owner role is set to Shared.
5b: Composition: An association representing a whole-part relationship. The Aggregation
property of the owner role is set to Composite.
9: 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.
13: Import: A relationship between packages, indicating that one
package includes all the definitions of another.
14: Dependency: The definition or implementation of the dependent classifier might change if
the classifier at the arrowhead end is changed.
15: Realization: The class implements the operations and attributes defined by the interface.
Use the Inheritance tool to create a realization between a class and an interface.
16: Realization: An alternative presentation of the same relationship. The label on the
lollipop symbol identifies the interface.
UML Class Diagrams: Guidelines: http://msdn.microsoft.com/library/dd409416%28VS.140%29.aspx
Properties of an Association
Aggregation: This appears as a diamond shape at one end of the connector. You can use it to
indicate that instances at the aggregating role own or contain instances of the other.
Is Navigable: If true for only one role, an arrow appears in the navigable direction. You can use
this to indicate navigability of links and database relations in the software.
Generalization: Generalization means that the specializing or derived type inherits attributes,
operations, and associations of the general or base type. The general type appears at the arrowhead
end of the relationship.
Realization: Realization means that a class implements the attributes and operations specified by
the interface. The interface is at the arrow end of the connector.
Let me know if you have more questions.
I think these pictures are understandable.
A nice cheat sheet (http://loufranco.com/wp-content/uploads/2012/11/cheatsheet.pdf):
It covers:
Class Diagram
Sequence Diagram
Package Diagram
Object Diagram
Use Case Diagram
And provides a few samples.
My favourite UML "cheat sheet" is UML Distilled, by Martin Fowler. It's the only one of his books that I've read that I do recommend.
For quick reference along with clear concise examples, Allen Holub's UML Quick Reference is excellent:
http://www.holub.com/goodies/uml/
(There are quite a few specific examples of arrows and pointers in the first column of a table, with descriptions in the second column.)
The accepted answer being said, It is missing some explanations.
For example, what is the difference between a uni-directional and a bi-directional association? In the provided example, both do exist. ( Both '5's in the arrows)
If looking for a more complete answer and have more time, here is a thorough explanation.
A very easy to understand description is the documentation of yuml, with examples for class diagrams, use cases, and activities.
Aggregations and compositions are a little bit confusing. However, think like compositions are a stronger version of aggregation. What does that mean?
Let's take an example:
(Aggregation)
1. Take a classroom and students:
In this case, we try to analyze the relationship between them. A classroom has a relationship with students. That means classroom comprises of one or many students. Even if we remove the Classroom class, the Students class does not need to destroy, which means we can use Student class independently.
(Composition)
2. Take a look at pages and Book Class.
In this case, pages is a book, which means collections of pages makes the book. If we remove the book class, the whole Page class will be destroyed. That means we cannot use the class of the page independently.
If you are still unclear about this topic, watch out this short wonderful video, which has explained the aggregation more clearly.
https://www.youtube.com/watch?v=d5ecYmyFZW0
If you are more of a MOOC person, one free course that I'd recommend that teaches you all the in and outs of most UML diagrams is this one from Udacity: https://www.udacity.com/course/software-architecture-design--ud821
Related
I want to understand a class diagram more fully and I am finding lots of conflicting information.
My first question is, what is the difference between class diagram and ERD? Not necessarily in look, but in classification. e.g. I have read that a class diagram is a type of ERD and I have read that a class diagram and an ERD are two different things.
My second question is around how the class diagram should look, I was given a basic tutorial on how to create a class diagram and I was taught that each class should be connected with a single line, with an arrow that looks like a 'Play' symbol (example 1 in the attached image)
But since doing some research into it, I am finding lots of examples where different connectors are used to denote association, aggregation, composition, inheritance etc. (example 2 in the attached image)
As mine is more simplistic, just showing the relationship and the multiplicities, does that mean that I have just learned a more basic version of class diagram and the extra connectors are an advanced step?
Or are they both something different?
Thanks for your help
Holly
First of all, welcome to Stack Overflow!
A class diagram is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among objects. Wiki link
An entity relationship diagram (ERD) shows the relationships of entity sets stored in a database. Link
Therefore the answer to your question of "what is the difference between class diagram and ERD"?
The class diagram has nothing to do with fact how the classes are persisted in the data layer. It shows only the logical relationship between classes and the properties of the classes. While the ERD diagram illustrates the logical structure of database; what the database tables, table-column, primary keys, foreign keys, etc. are, and last but not least the relationships between database tables.
As for the question "Is this just a more advanced version of class diagram? Or a more updated version?":
There are cases when the ERD diagram can look similar to the corresponding class diagram, but the persistence data model can be way different from the class (domain) model. Furthermore a class diagram has no any information about how a class is persisted in the database - as I've already mentioned -, therefore an ERD has other kind of information than a class diagram.
As for the notations you linked:
A proper class diagram contains notations like in the second link. An example is the following diagram:
For more info what those arrows mean, click here for the corresponding SO answer.
What you are taught about how to make a class diagram (like at the first link you shown), can also be useful but it is a customized class diagram rather than an proper class diagram following the UML standards and notations because:
I find it strange that the arrow is not on the line itself
There is a shared ownership relationship (aggregation) between Customer and Vehicle. It means that a Customer can have (own) a Vehicle but the Vehicle can still exist as its own, without a Customer. This relationship can be represented with the aggregation notation. (See arrow 5a, or the class diagram below)
I find it also strange that a vehicle can have multiple Customers, as you notated with "0..*". But of course it is possible, since I do not know what kind of domain you try to model with the diagram...I made an UML diagram with proper signs, check this out:
Summing up, it is wise to follow the UML standards and conventions, since it is widely accepted and known so the information can be exchanged as efficient as possible, without misunderstanding.
In the below UML diagram, Account has an aggregation of Orders. Based on most online resources, this would typically mean Account class has something similar to a List as an instance.
But in reality, for a real world web app with persistent storage, that is not usually how the Account Class would be. It won't have a list of orders as instance. Instead some other controller class will just query a datastore asking for all Orders belonging to an Account. So in a UML class diagram for such an app, is this still the right way to represent relations? The cardinality and maybe the concept of aggregation looks right from a database entity perspective. Just that the diamond makes no sense from a Class perspective.
Or should it show a DataStore/DataManager with a getOrdersForAccount() method and connect it to Account class and Orders class through a dependency relation (dotted line with arrow) ?
This depends on what you want to represent.
The class model you have already would be sufficient as a logical domain model, expressing the logical relationships between entities in your domain. This might not be how you implement your software in code precisely, but it will guide you (and others) in understanding the entities and their relationships without getting bogged down in that implementation detail. At this level, your diagram may have a few design choices (strong aggregation for example is arguably a design choice, but it may not be, as is the use of enumerations and keys) but not that many and nothing that really detracts from the underlying logic. If anything, you could loose some design choices here and improve the expression of logic.
What you may also want is to provide a representation of how the OO code is implemented physically as well. This would be an additional class diagram that shows more precisely the implementation detail. You will have far more design choices in this diagram -- whether to use a collection or not for orders (e.g. a list or some other collection type class), what your data access patterns are (Adapters, Managers, ORMs etc.). At this level you will most likely loose the strong aggregate notation, as at this level we are talking about classes referencing each other which is most simply denoted using basic associations. You might want to use arrows and/or dot-notation to indicate end ownership and reference directions so that it's more clear what the relationships between classes are.
So, I think your question is a classic question about levels of abstraction in models and analysis vs design. Thanks for asking it!
The aggregation just means: "if you delete the account you need to delete the orders as well".
I also recommend to just leave the aggregation away (for most cases) since it only adds little extra semantics to your model. In this case it seems obvious to delete the order when the account is deleted. The only thing the aggregation added here is (as in most cases) some confusion or some futile discussions about the worth of that diamond.
If you have a domain where the filled diamond is used it should be documented in the modeling rules. When using the shared aggregation the documentation is even mandatory since there is no semantics per se in the specs (see box on p. 110 of UML 2.5).
It depends on how deep you want to go with UML design.
If you target code generation from UML then you probably need to add the class you mentioned.
It would look a lot like Registry Pattern:
UML Diagram
You can add abstraction so you can change implementation of your DataManager (if your DataManager is third-party then just call the API from DataManagerImplementation).
After that, depending on your implementation, once you have the list, if you need to keep it then add the association Account -> Order, if you can live with the list on the stack then you are good to go.
C++ instanciation example:
DataManagerImplementation *db = new DataManagerImplementation();
// Dependency injection
Account *acc = new Account(db);
Then in 'Account' class:
Account::Account(DataManager *db)
{
// Fetch list at creation
// Here 'orders' could be a member
m_db = db;
vector<Order*> *orders = m_db->GetOrders(this);
}
PS: I also recommend to put arrow (direction) on association/aggregation, otherwise it implies that the association is bi-directional and so that account has a pointer to an order list, and every order also has a pointer to an account, and I am not sure this is needed.
To edit PlantUML: http://www.plantuml.com/plantuml/png/SoWkIImgAStDuN99B4dqJSnBJ4yjyimjo4dDJSqhIIp9pCzJqDMjiLFmBqf9BK9ImuKk05Hcfw2afGHHYIbjfL2McboINsG3bj6oKz1oJoq1iuir79EJyqlpIZIve0m5a566IfYMEgJcfG0T2m00
Composition: A class can have references to objects of other classes as members. This is called composition and is sometimes referred to as a has-a relationship.
By Deitel P.J., Deitel H.M. - Java How to Program 9th Edition.
This viewpoint is discussed in this topic:
Prefer composition over inheritance?
Composition: Composite aggregation (composition) is a "strong" form of aggregation with the following characteristics:
*it is binary association,
*it is a whole/part relationship,
*a part could be included in at most one composite (whole) at a time, and
*if a composite (whole) is deleted, all of its composite parts are "normally" deleted with it.
Found on http://www.uml-diagrams.org/composition.html
(actually, Deitel presents UML examples following this idea, in the same book, but did not bother to explain the difference).
This viewpoint is discussed in this topic:
What is the difference between association, aggregation and composition?
Fine, BOTH ARE CORRECT. And this introduces the problem of homonym concepts.
For instance: don't draw a UML model with composition arrows to exemplify the first definition: In UML, any association is a composition by Deitels' the first definition.
Here are some aspects of my question that may help in the correct answer:
How I can say (and know) which composition are we talking about?
Where we draw the line between the two definitions (in contextual terms)?
Can I say that the first is object oriented programming and the second is software engineering/modeling?
Is the UML composition a model-only concept/jargon?
Is the UML composition an UML exclusive thing? or is also applied in the programming field?
How to avoid miscommunication of "what composition are we talking about" in a team?
Please, answer with references, evidences, it is not a philosophical/opinion problem, it is a "scope" problem that I´m trying to address.
And it is not "what is composition" question.
Edit: I´m thinking if the distinction is verb x adjective: "to compose" a class (first def.) and "a composite relation" (second def.).
I found it hard to explain the difference between UML association and implementation references without explaining at least a little bit what UML associations actually are, and what they can do, so here we go.
Association & Link
Lets start by looking at what a UML Association and a link (Association's instance) are.
[11.5.3.1] An Association specifies a semantic relationship that can occur between typed instances.
[11.8.1.1] A link is a tuple of values that refer to typed objects. An Association classifies a set of links, each of which is an instance of the Association. Each value in the link refers to an instance of the type of the corresponding end of the Association.
So the following is a valid implementation of a limited association.
class Brain { }
class Head { }
a = new Brain;
b = new Head;
link = (new Array).add(a).add(b);
Ownership
[9.5.3] When a Property is owned by a Classifier other than an Association via ownedAttribute, then it represents an attribute of the Classifier.
(Note: Class is a subclass of a Classifier.)
Navigability
[11.5.3.1] An end Property of an Association that is owned by an end Class or that is a navigableOwnedEnd of the Association indicates that the Association is navigable from the opposite ends; otherwise, the Association is not navigable from the opposite ends. Navigability means that instances participating in links at runtime (instances of an Association) can be accessed efficiently from instances at the other ends of the Association. The precise mechanism by which such efficient access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient.
Why are those concepts relevant? Imagine the following example.
We see that brain is an attribute of Head class (the black dot signifies ownership by the opposite Class), and that it is navigable (the arrow).
We also see that head is NOT an attribute of Brain (no black dot ⇒ not owned by the Brain class ⇒ not an attribute of Brain), however it is still navigable. This means that in UML the head Property is held by the association itself.
The implementation could, for example, look like this (the association itself is represented by a tuple of two references (see link description earlier)).
class Head {
public Brain brain;
}
class Brain {
}
h = new Head;
b = new Brain;
h.brain = b;
link = (new Array).add(h).add(b);
So as you hopefully start to see, UML association is not such a simple concept as a has-a relationship.
Composition
Lets add another piece, composition.
[11.5.3.1] A binary Association may represent a composite aggregation (i.e., a whole/part relationship). Composition is represented by the isComposite attribute
[9.9.17] The value of isComposite is true only if aggregation is composite.
With the aggregation being
none - Indicates that the Property has no aggregation semantics.
shared - Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
composite -- Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects
Again we see, that a UML association is explicitly specifying concepts that are hard to perceive from implementation (e.g. who is responsible for object management/destruction).
Model Composition vs Object Implementation Composition
So from the description above we can construct a more precise description of what an implementation composition (has-a relationship) would be.
[Deteils] Composition: A class can have references to objects of other classes as members. This is called composition and is sometimes referred to as a has-a relationship.
McConnell [Code Complete 2, 6.3] also refers to has-a relationship as a Containment.
Neither of them however talk about HOW the objects (container-contained, composer-composite) are related to one another, who is responsible for lifecycles, or whether the contained element knows about the container.
So just by saying that objects have a has-a relationship (and call it composition), you could actually mean any of these (and several more)
So if you call something composition in programming, you can mean pretty much any relationship/reference (or rather not an inheritance), so the word by itself is not very useful.
In UML on the other hand you are trying to capture all such information about how the objects are related to one another. Therefore there's a focus on giving terms a more precise meaning. So when you call something composition in UML you have in mind a very specific has-a relationship, where the container is responsible for the lifecycle of the contained items.
Implementation of UML associations
All those extra concepts information mean that there is really no precise way how to even implement associations. This makes sense as the implementation would depend on the target programming language or environment (e.g. executable models, where the UML concepts are used as the final product).
As an example I can recommend a paper describing UML association implementation in Java with enforced concepts such as multiplicity, navigability, and visibility Implementing UML Associations in Java.
More subquestions
How I can say (and know) which composition are we talking about?
By context, or you can just ask (which is always a good thing to do when unsure). Personally I've heard the use of composition as "has-a relationship" only when differentiating from inheritance; and in the rest in terms of UML. But then again I am in academia, so my view is biased.
Where we draw the line between the two definitions (in contextual terms)?
As the "programming" term composition doesn't actually mean anything (only that it is has-a), I'd recommend drawing the line yourself and pushing others to use more precise terminology.
Can I say that the first is object oriented programming and the second is software engineering/modeling?
More or less, with all the nuances mentioned in this answer.
Is the UML composition a model-only concept/jargon?
Is the UML composition an UML exclusive thing? or is also applied in the programming field?
No, you can use it in programming to mean the same thing as it means in UML, but you might need to state it more obviously. E.g. "This class is a composite for those classes, because it manages their lifecycle.".
The point is to teach people to differentiate between regular-old has-a relationships, and relationships that have more precise semantics.
How to avoid miscommunication of "what composition are we talking about" in a team?
This is a very broad question that you could apply to any term to which you want attach special meaning (what even is software engineering?), and there is no best way. Have a team-shared vocabulary (you are probably already having a lots of specific terms in your domain), and guide people to use more precise terminology.
numbered quotes refers to sections in UML 2.5 Specifications.
To cite the UML 2.5 specification on page 110:
Sometimes a Property is used to model circumstances in which one instance is used to group together a set of instances; this is called aggregation. To represent such circumstances, a Property has an aggregation property, of type AggregationKind; the instance representing the whole group is classified by the owner of the Property, and the instances representing the grouped individuals are classified by the type of the Property. AggregationKind is an enumeration with the following literal values:
none: Indicates that the Property has no aggregation semantics.
shared: Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
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).
Personally I see it the way that notion of a composite aggregation is about object lifetime, not about static relation. A composite aggregation kills aggregate members when their parent dies. None leaves this open. And shared aggregation is a bastard that OMG should not have introduced at all since it's semantics is domain dependent.
How can I associate messages(operation calls) in a sequence diagram to its implementation(method)as an activity diagram?
I am using Papyrus for modelling.
There is an indirect relationship possible in this case.
A method is typically defined in a class from a class diagram.
The same method is specified using an activity diagram.
The invocation of the method can be shown on a sequence diagram.
Class diagram gives kind of a structural back-up the the rest of the diagrams, and is highely recommendable to make one (if you don't have it already).
The messaging in a sequence diagram are meant to become method invocations upon classes of objects. Activity diagrams are meant to be like a flow chart of the business processes. The former will be very specific and detailed; the latter will be more generic and not so specific.
While they can be coincidentally related if you choose to model that way, since they are not by UML standards to be that directly related I don't think you'll find tooling that will do this for you.
You can read more here:
UML Activity Diagram tutorial
UML Sequence Diagram tutorial
I'm doing an UML diagrams for a project but I have a doubt...
I use an example to explain:
public class Book{...}
public class Library{
private ArrayList<Book> books;
public void insert(Book b){...}
public Book get(Book b){...}
}
In this case between Book and Library there's an aggregation but also a dependency, right?
Aggregation is a relation in which the "parent" class contains the "child" class, instead the dependency is the case in which a class use another class by parameter or return type.
Now, if a class A contains object of another class B mean that the B's object has been passed in some way at the object of class A, the only way is using a method(or a constructor), so the aggregation involves the dependency?
P.S.: sorry for my poor english
With all due respect to your professor, I disagree. You do have aggregation in your diagram, since Library contains Books (both semantically and syntactically).
A UML dependency relation means that "some UML element or a set of elements requires, needs or depends on other model elements for specification or implementation" (from my favorite UML reference site: uml-diagrams.org). When you put an aggregation link between two elements, it is already stated that one depends on the other, therefore adding a dependency relation between them is redundant.
I am no UML expert, but one thing I've really liked in "UML in a Nutshell" was a sentence saying that UML is useful only when it's intuitive for everybody.
Having said that, I'd suggest not over-complicating your diagrams. Not everything can nor has to be presented in a diagram. In your case the Library has some Books, a case of aggregation/composition (depending on other details not mentioned in your description). You dont have to state a dependency between these two classes, because the aggregation implies it. In my understanding a "dependency" is useful when you want to state an indirect relationship, a runtime dependency for instance.