I am doing a UML model based on my ERD generated with MySQL workbench. But now i have a doubt about the primary and foreign keys representation in a class diagram.
In the traditional UML diagram we should include the primary keys as atributes of each class? For example, the id_user or the id_list ? And about the foreign keys ? These ones are ignored as attribute but reflected as associations?
thanks
First off: why do you want to draw it in UML? If you already have an ERD, what additional/alternate property do you want to illustrate with a UML class diagram that the ERD doesn't give you?
Why? Because UML is a tool. On the assumption the diagram is for human consumption only (i.e. you're not code generating from it) then you should use UML to expose the information you're trying to communicate.
As a general standard UML says nothing about how you formalise identity (PK/FK). UML follows the OO idiom that every object has implicit identity - therefore you don't need to specify it explicitly. So in the simplest case, you could:
list PK attributes as normal attributes;
ignore FK attributes altogether.
If that meets your modelling needs then you're done.
As a second refinement, you could tag the PK attributes with an ocl isUnique() constraint, again ignoring the FKs.
Another option would be to use the rules of Executable UML. It denotes both PKs ('Identifiers'} and FKs ('referential attributes'} directly on the class diagram. So it's closest to capturing everything in the ERD.
So in summary: there is no UML-imposed right answer. It all depends on what you want to communicate with the diagram.
You can use/create a "database profile" to annotate your UML model with this information. Without a profile you could use OCL to specify uniqueness constraints while normal associations should be enough to represent what would be transformed into foreign keys at the database level
You can use EclipseUML Omondo trial and reverse your database.
You will get the information you need and you can then copy it in a free or open source tool.
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
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 am trying to find a way of specifying how a given class attribute is persisted to an existing database model that I cannot modify at the moment. What i need to convey in a UML class diagram is how a class attribute is mapped to a given table column. Should I use stereotypes for this as illustrated below or is there a better way?
No, you should definitely not use stereotypes.
A stereotype denotes a meta-class that is an extension of a UML meta-class.
«table» is a commonly used stereotype used as an extension of the UML Class to indicate that this object is to be interpreted as a table rather then a generic Class.
Stereotypes can also define properties who will manifest in the model as tagged values. As such you could imagine a «column» stereotype that has a property mapping in which you can add a reference to the class attribute(s).
Some UML tools also have some sort of feature to link attributes to other attributes. UML doesn't really specify how this should be represented in a diagram, so the tools each have their own notation.
Enterprise Architect for example uses this notation:
(from the user manual)
If I create a conceptual class diagram such that each class captures 'name' and 'attributes' but not 'operations', have I not basically created what would be otherwise considered an ERD? I'm trying to gain an understanding of what the differences are between creating a conceptual class diagram as I have described versus calling it a ERD? If these are still two different animals, can somebody please explain what the differences are?
The class diagram contains just the classes in your object model with eventual links/relationships connecting diagram elements. However those links don't necessarily correspond to physical relationships like in an ERD diagram, but instead they represent logical connections.
The class diagram is just the object model of your application and does not contain any persistence-specific information. When you think about the class diagram forget about the database or any other storage you may use.
The ERD diagram on the other side, is a persistence-specific diagram which display the entities (tables) existing in a (most often) relational database. It also displays the physical relations (and cardinalities) between those tables and all other database-specific information. The ERD diagram can sometimes look similar to the class diagram, but that doesn't mean is the same as a class diagram.
There´s little difference in the expressiveness of both (if we just focus on the attributes, classes and associations part) if you use Extended Entity Relationship diagrams (the most common case nowadays)
True, they look very different at the graphical level since they use different symbols for the elements but the "semantics" are quite similar. They both allow inheritance (again, I´m talking about EER), n-ary associations, association classes, ...
The ER diagrams I've seen (most frequently ERWin IE notation) have focused on the design for a database. They are concerned with primary keys, foreign keys, have unnamed relationships, and usually have no generalization / specialization.
A good UML conceptual class diagram, on the other hand, is not concerned with keys, reflects the problem domain, and has association-end properties that at least hint at the semantics of why things are related. This helps communicate the domain down to more junior developers so they don't have to guess.
It depends on the situation where you may not like to do the ER-D. But imagine if you have a seperate data layer where the data logic is handled. In this case many details of data shall not be shared with the application layer. And you class diagram shall not go beyond the application layer. I must stress that both the diagrams are not equal. And there are situations where you need to do both, mainly in multi-tier architecture, and there are situations where you may be able to just use class diagram; e.g. single-tier application.
I strongly advocate the view that class diagram doesn't abrogate the E-R diagram.
Design class diagrams are made from conceptual model and collaboration diagrams.
Design class diagrams include:
Classes, associations and attributes
Methods
Types of attributes
Navigability
Dependencies
IMO In Simple terms
Class diagram depicts the details of how will the system work.
ER diagram depicts how the system persists 'state' as a blue print.
Goal:
Detail out state and behavior of the components(classes) of the system.
Design 'efficient', flexile system(less coupling and more cohesion) using Solid principles.
Goal:
Design a blue print of how to 'efficiently' persist the state of the system.
Consider what kind of queries will be made (read vs write), are there any joins required
consequently figure out the columns for indexing
Use Normalization, ACID properties.
PS: notice the both the diagram tries to efficiently do thing in their on respect.
I have read several tutorials on what a UML model should contain and what not. As a developer I always think in terms of a relational data model where you could never have a many to many relationship between tables. Now with a UML class model, I've read that if they don't provide added value, you could just skip the linktables.
However I've also read a tutorial where examples where given using data inside tables and was strongly suggesting to picture each class as a simple table while modeling your class model.
I am confused, what is it now?!
The "relational link table" is an implementation technique for a Many-to-Many relationship.
The relationship exists irrespective of how it's implemented.
In an object model, you have many choices for how to implement many-to-many, which may (or may not) involve an additional persistent table. It could be done lots of different ways.
The point of UML is to be able to describe the essential features of what the model really is.
You can also describe the implementation. They're separate diagrams with separate purposes. You can easily show the relational implementation with the link table. You can also show the essential model without the link table.
Here's the essential relationship
Here's the implementation of the relationship
Both are valid UML. The real question is "what do you need to show other people?" Essential truth or one particular implementation?
Model it as an M:N relationship. Same as in a relationship model there will be an associate class (or link class) of some kind in code. No need to put that on the diagram unless it has attributes on top of the join attributes (much like you would generally omit a join entity from an ERD unless it had attributes that weren't foreign keys in the related entities). The link class is typically drawn as a class connected to the relationship by a dashed line.
The Enrolment join entity is a good example of this in UML 2 Class Diagrams.