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.
Related
I'm taking the Stanford edx course (Databases: Modeling and theory) and the lecturer mentioned this piece of information about association classes and what they imply in a diagram (in reference to an example of two classes "student" and "college" associated by a "applies to" association with the association class "appInfo" containing college application info):
Now what we're saying is that association is going to have affiliated with it a date and a decision. What we cannot describe in UML is the possibility of having more than one relationship or association between the same student and the same college.
So when we have an association, that assumes at most one relationship between two objects. So, for example, if we wanted to add the possibility that students could apply to the same college multiple times so maybe, you know, they wanted to apply for different majors, that would actually have to be captured quite differently. We'd have to add a separate class for the application information with separate relationships to the students and colleges.
but I didn't really get what she meant here, does having an association class create an automatic 1-1 coupling between two classes? or is it prohibited for two classes to have more than one relationship? or what exactly is being said here because it's a bit vague and I'm not experienced in UML data modeling.
The statement is either wrong or it’s taken out of a specific context that was not mentioned here. The reasons are:
there is no implicit one-to-one in an association; the multiplicities at both end of an association specifies if it’s a one to one, a one to many, a many to many association or anything in between.
the same applies to an association class, which is both: an association and a class at the same time.
in a many to many association, there can very well be several times a link between the same objects. In fact, in a one-to-many or many-to-many association, you need to add an explicit constraint if you want to avoid this.
More information:
in this other answer, there are some more explanation about the semantic of association classes
an here a question related to uniqueness. as you will see, it is not that obvious to avoid multiple occurrences
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 have homework and I'm supposed to draw a class diagram AND data model. I wrote the class diagram. I don't know what to do about the data model. What are the differences?
According to texts on the Internet they seems to me, ie: class diagrams and data models are the same thing.
What is the difference between class diagrams and data models.
Unified Modelling Language, as you may already know, is a means of describing systems with diagrams. They don't just relate to software, but can also relate to hardware, economics, everyday items, in fact anything, although they are more generally used with software systems.
A class diagram details how you have split your system into discrete objects, how those objects relate to each other and any know interfaces that they may have. Each class in a class diagram can hold both data and function.
For example a Car class has an Engine, a Steering Wheel class and multiple Wheel, Door, Seat and Pedal classes linked to it. In all of this a class diagram is static.
I'm not exactly sure what you mean by data model.
I've seen class diagrams used to model database tables, usually these are without any functional element and just show how the data tables relate to each other.
There are those that argue that there needs to be an addition to the UML standard for Data Diagrams, but as yet none have been ratified.
This is because persistence of data, key relationships and constraints between tables can be difficult to model with a standard class diagram and most UML tools implement tweaks to the standard in order to allow this.
Then there are dataflow diagrams which are really Activity diagrams, used to show the flow of data between processes within a system.
Now if we go back to class diagrams and assume that a data diagram is used to model a database then you'll notice that there a few differences that may be overlooked.
A class on a class diagram can have data properties (code variables etc) and functional properties (methods, procedures, functions etc.) but these elements of a class can also have access properties (private, public etc.). A class diagram can also show inheritence e.g. a Volkswagon is a Car, so is a Ford, both will inherit from Car and this can be shown.
A data diagram in the database sense will show data items (columns/fields in database tables) but the idea of access properties (public, private etc.) or the idea of inheritence has no meaning and thus can't be shown.
This is because it isn't modelling discrete objects that have both data and function but the data associated with those objects. For example a Car table may have a relational link to a Manufacturers table in which is stored the values Volkswagon and Ford. It may have a Wheels column, but this will only show the number of wheels. Stored procedures for the database exist at a level labstracted from the data - they utilise the data, but are not governed or owned by the data tables that they get the data from.
I've probably not explained myself very well, but I hope that I've helped.
Here's a useful site
And here's another and on that site data modelling specifically.
Generally data models define how the database is implemented. Those diagrams are entity diagrams. A class model is the functional relationships between objects in your system. A class has data but it isn't the data model. A design has both a class model and a data model. As a simple example, a data model exists for a customer. That data model was the design for our customer database. A class model design exists to implement how to process a customer order. The data model is what the database designer uses. The class model is what the software designer uses to implement a ordering business function. Both the data model and class model have diagrams. They use different symbols and rules. Class diagram vs Entity diagram. Two different kinds of diagrams.
Datamodeling is not UML which is focused on object approach.
Having said that you can model inside a class diagram at object level and create your database using Hibernate annotations in the Java code.
I mean that you create your code and add persistence annotation at the same time. This would create your database at deployment.
UML which is not supposed to be datamodeling can also create data at deployment level if you use the Omondo Persistence profile. It means that you can model at object level and also create your database. Very powerful approach because the data creation stage is now joined with the object
This is still an initiative but it could become a standard if bigger companies adopt this approach which is for me one of the best practices when codding in Java that I would recommend.
I have a Proffesor table in a database. I would like to create an UML diagram for the code-behind part.
The class structure would be:
- a Proffesor class that maps the information from the database table (id, first name, etc)
- a ProffesorDAL class which connects to the DB and queries it in order to add,remove,update Proffesor instances
- 3 forms which add/delete/update proffesors, by accesing the ProffesorDAL class
I thought that the forms-ProffesorDAL relationship is a composition relationship. Is this correct?
How about the ProffesorDAL-Proffesor relationship, could it be aggregation or is it just association? What's the best UML relationship for the forms-Proffesor relationship?
Thanks!
I'd start by assuming association and from there to analyse and design if there should be a stronger relation between the two.
My question goes "Does it own it". Example I'd say a Car owns 4 wheels (among a long list of other items).
In my standard design I have a BLL between my UI and DAL. I start by assuming a loose association between my three, later I reach the conclusion that the BLL and DAL are somewhat closely connected and could benefit from a strong tie.
As for the Professor class, I assume this to be a Model class. Model classes I only have a loose connection / knowledge to - meaning they appears only as parameters (association). My DALs do not have a strong connection with my Model classes (aggregation). They are but Message bringers, complex ints and bools.
The UML Aggregation relationship is almost worthless - it creates far more confusion than value. It has only one useful property, namely that if used in a recursive relationship, the resulting object structure is acyclic.
It's really not worth getting hung up about. My advice would be to use a simple binary association and concentrate on getting the cardinality right. That's a lot more useful and valuable.
hth.
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.