How do you translate this ER relation to UML:
This is my attempt:
Is this the correct way of doing it? I feel a bit lost.
In an ERD diagram with Chen’s notation:
the rectangles are entities, which in UML would be translated into classes;
the diamonds are relations between entities, which in UML would translate to associations;
(the elipses are attributed, which in UML would be represented either as properties or as association with another class);
the cardinalities would translate to multiplicities that you would show on the end of an association.
So in UML you’d have a book, and a reflexive association line labeled “sequel” and with a 1 near both ends. Much simpler that what you showed.
For more explanations about the mapping and the subtle differences, as well as transforming the one into the other, you may have a look at this other SO answer.
Finally, I am not sure that your 1:1 relation in Chen’s ERD notation is completely equivalent to your tabular notation: the association table that you use corresponds to a many to many association (since the same book can appear in several “records”). Additional code would be needed to retrict its use to 1:1. But btw I’m not sure that the sequel association would be a one to one either (i.e one book has only one other book as sequel and vice versa).
Related
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
Please Look at the following example:
1) The chairs are made of wood .
2) Paper is made from trees .
3) Biogas is produced by the fermentation of waste.
4) Asphalt is produced through the refining of petroleum.
Should these be Composition or Dependency?
In general
You can exclude UML composition: composition implies an exclusive ownership. But chairs are not the only products made of wood.
Dependency is either too much (once the biogas is made, there is no dependency to waste anymore) or not enough (the wood of the chair is part of the chair; it's a stronger relationship than a need-to-know-about).
Moreover it is not clear if you want the Chair to be a class on its own or an instance of a class product.
Specific cases
"Made of" expresses a relationship with parts that make a product. A typical pattern here is the bill of material. The relation is a simple association. Some people tend to use UML aggregation, but UML specifications do not define precisely the semantics, so leave it out to avoid ambiguity.
Here a (very simplified) diagram:
"Made from" expresses a transformation process, where some of the original products disappear in the process and others are created. Paper is made from cellulose which is extracted from trees. But the original tree is not in the sheet of paper.
Typically in process industries, like chemicals, this is represented by a "recipe", which is a sequence of inputs (waste) and operation to obtain products (biogas) and co-products (fermented residual waste). In other industries, this is represented by a "routing" that is a sequence of operations performed on a BOM (in this case, the BOM would not only contain components as previously shown, but also raw products that are transformed by the operations in the routing).
I will not show a diagram because this is quickly very complex, but again, it'll use simple associations.
In the end, "made of" and "made from" would both be represented in UML with associations. But only the semantic that you attach to it will change.
I don't think that any "made of" is represented by some static relation. To make a wooden chair it just Depends on wood. There is no other relation here because you have some complicated process to turn wood into a chair. Or a tree into paper. Or anything else of your choices. In order to describe the relation you would need to describe the process. This is possible using activities. You could as well descibe physical components with UML. But that would take us too far apart from your question...
You might search for answers on composition here. But even these can be looked at controversial. Modeling reality yields a model. Which is not reality.
Your question highlights the difference between an ontology and an information model or application design. For example, in a conceptual ontology (which accounts for necessary and possible situations in the world rather than for data formats of observations and measurements), every person has a mother. In a particular database or application, that knowledge is usually irrelevant. What stuff is made of and how it is produced belongs more to a conceptual ontology, for which UML is not quite expressive enough. This is why languages such as First Order Logic (FOL) and OWL are used instead, and why some tools (such as my company’s) plug holes in UML. (One example of a hole in UML is the inability to express exactly the intersection of two classes.)
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I have a project which requires me to create a UML Class Diagram. What I have from the previous tasks in the same project is an ERD using UML notation. Also worth noting, this project is related to database and does not have much coding in it, so creating a class diagram based on other coding is probably not the main objective here.
I tried Googling "how to convert erd to class diagram" but all the search result only shows how to convert ERD using Crow's Feet notation into UML Class Diagram.
I also Googled about UML notation ERD, and found this site which said,
In UML notation, entities are modeled as a “class” with an Entity stereotype.
Does that mean that ERD using UML notation is the same with UML Class Diagram? If not, what are the differences?
Note: I know there are already questions regarding difference between ERD and Class Diagram, but I am asking specifically about ERD using UML notation.
In Chen's original ERD notation attributes are ovals connected to their entity which is represented with rectangles, which can have relationships represented with losanges. This resulted in very large and complex diagrams, due to the many attributes.
Crow's Feet notation became therefore more popular since it allowed to express the same models in a more compact way, grouping attributes together with their entity in the rectangles, and using an intuitive visual representation of cardinality. But now that UML is the Lingua Franca of modellers, it's tempting to look at other alternatives.
Your linked source suggests a very natural mapping of the core ERD concepts of entity, attribute, relationships, into the UML class, properties and associations:
(...) entities are modeled as a “class” with an Entity stereotype.
(...) attributes can be arranged in a box style (...)
Relationships are shown as a single solid line connecting the two entities. The minimum and maximum cardinalities are shown along the line and verb phrases can be added to completely characterize the nature of the relationship.
And indeed, the most suitable notation for an ERD diagram in UML would be a class diagram.
Beware however of the subtle semantic differences. For example:
in UML any property (what your mapping relates to attribute) could be modelled either within the box (as what you call an attribute) or as a related associated class (as what you call an entity) with an owned association end.
UML classes are expected to have behavior (it's because of the underlying OOP concepts). Having classes without behavior can be misunderstood by UML reader as a bad design (anaemic domain model). The «Entity» stereotype is not sufficient to disambiguate, since it's in general associated in the UML context with the Entity-Control-Boundary paradigm, which also expects entities to have behavior. Maybe you define an UML profile using a less ambiguous stereotype such as «Data-Entity»
Your linked source is misleading about Crow's feet transposition in UML: you can add a verb phrase on an association in UML, but in the middle oc the association and with and with an arrow head next to the text to show the direction of the reading. In UML, the text at an association end is something completely different: it's called "role". The equivalent in an ERD diagram would be to include an attribute with the role name in the entity at the other end (and which would correspond the the primary key identifying the other entity).
A better source about how to note ERD concepts in different notations can be found in the side-bar of the Wikipedia article on ERD.
Edit: A mapping algorithm is proposed in a more general article "A framework for transforming structured analysis and design artifacts to UML": it mentions that in addition, ERD diagrams sub-type relations should be transformed in UML generalization under the condition that it's an IsA relation.
In a UML diagram where one class is comprised by another class, is there an implicit association table, or does it need to be shown?
For example, if I have Chapters that are composition of Paragraphs, is this alone enough:
Or does the association class to be explicitly shown like so:
I've never seen it done like that latter example, so I'm assuming it's implied. Or maybe I haven't normalized the data properly (considering chapter both appears in the Chapter class and the Paragraph class).
Simply, there is no implication. If you need an association class, you need to define it. However, UML is not about diagraming, it's about modeling. You can omit your association class in a diagram if you want to. The association class will still exist in your model, though.
No, it is not implied.
The reason why you haven't seen this is that in most cases it simply doesn't make sense. In the association class the class part additionally describes the properties of the association. In your example you create an artificial object that actually brings little or nothing. This kind of approach can be useful for many-to-many relationships which are impossible for composition (each part can have at most one whole). Even if you wanted to show Foreign Key it would simply be on one of the classes. But that's implied by the association itself. According to UML specification an inline attribute is equivalent to an association.
Moreover on UML you can depict many to many relationship simply but applying appropriate multiplicities on association ends. You may want to show the class depicting that only when modelling on the code level.
No, it is not implied.
UML is not about tables, but about classes. The author of the class diagram should tell the audience how a class should be interpreted. Some UML diagrams model the real world, others model a piece of application functionality and yet others depict a physical implementation.
Apparently, reading your question, you are modeling a relational database, where a class is a physical table. In that case, I would expect that every table is explicitly modeled as a UML class.
The UML standard does not demand this.
By the way, the notation (PK) and (FK) is not in accordance with the UML standard.
I found a definition for association in UML as below.
An "association" in UML is defined as a kind of relationship between
classes,which represents the semantic relationship between two or more classes that
involves connections (links) among their instances .
I am not clear what is semantic relationship. Can anyone explain it with example with comparing it with non semantic relationship?
Associations in plain text
An association is a semantic relationship. The UML clause means that there is a structural relationship between instances of the associated classes independently of any specific implementation. "Semantic" underlines that the relationship is between the instances themselves, and not just "accidentally" for an operation:
Use associations primarily where there are structural relationships among objects. Do not use them to show transient relationships such as parameters or local variables of procedures.- Booch, Rumbaugh & Jacobson in Unified Modeling Language User Guide, 2nd edition
More arguments
What is "semantic"?
The term "semantic" is borrowed from linguistics and refers to the meanings behind the words. Linguists and map words (e.g. "Car", "Driver") to their meaning (e.g. a real car, a real person), and analyze the relation between words with a view of this mapping:
So, applying this to UML (modelling language) if you'd have the classes Car and Driver, you CAN model the semantic relationship as an association between the two classes.
What is not semantic?
Not all relationships are of semantic nature. You can have dependencies, which can express a technical relationship:
a transient relationship during an operation: with a factory pattern for example, a DriverFactory would «create» a Driver instance. Both instances the factory and the driver are related only at the exact moment of the creation operation. But the two instances are completely independent the nanosecond after.The same applies if the implementation of an operation needs to create a local instance of another class. Both classes are not associated, since we could imagine another implementation that works without such an instance.
a structural dependency: Maybe an operation require some other classes as parameter. Since the parameters themselves are transient, there is no association. But nevertheless, teh class needs to know about the other class.
For the records, I'm grateful to this public domain contributor for the nice car and driver and to 18f for advice on inclusive communication.
The subject of Semantics is sense. If one thing has something that is connected by sense to another thing, it is the semantic relationship. That definition is terribly wide. And, applied to UML relationship, incorrect. It is incorrect for two reasons.
First, UML covers not only Class-Instance languages, such as Java or C++, but pure object languages with heredity created by Prototypes as well. And this second variant is not covered by your definition at all.
Second, in UML you can have class A connected to class B through some complex AssociationClass, that is shown by a box with arrows, not arrow only. And it still will be named an association and it IS a semantic relationship, too. But a the semantic relationship goes from A to B through two classes, it is still a semantic relationship, but it is not an association in UML.
If you are trying to be deep in subject, better read the UML documentation: "An Association classifies a set of tuples representing links between typed instances." (UML 2.5, pharagraph 11.5.1). Notice: ANY link between two instances can be shown as an association. Maybe the book you are reading is wholely not so bad, but in the very place that you have cited the author merely tries to use pretty words not understanding their meaning and not even trying to be understandable to readers and to be CORRECT.
A model says something about the things being modeled. This is its semantics. Almost all elements of UML have semantics, defined in the sections titled "semantics". One exception is the comment. Adding a comment to a model doesn't influence its meaning.
Then why does the UML say this explicitely about associations? The reason is, that an association may or may not say something about the structure. If it doesn't, it is purely semantic.
For example it could tell us, that a Car can have at most one Driver. It doesn't necessarily mean that the car has an attribute of type Driver.
If we want to model that the two associated classes own attributes typed by the other end of the association, the notation will show this by small dots on its ends. Many people are not familiar with this notation and interpret associations without a dot in the same way. However, without the dots attributes are owned by the association itself and the structure of the classes is not influenced.
By the way, a class being the type of a parameter of an operation or having a dependency also means a semantic relationship.