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.
Related
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
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
Is there a difference in the meaning of "class diagram" and "object graph"?
see this tutorial
http://www.cs.toronto.edu/~jm/340S/Slides6/ClassD.pdf
Object graph contains value of one instance of class see example View its a view of an object system at a particular point in time
while
class diagram as wiki
The class diagram is the main building block of object oriented modelling. It is used both for general conceptual modelling of the systematics of the application, and for detailed modelling translating the models into programming code. Class diagrams can also be used for data modeling.[1] The classes in a class diagram represent both the main objects and or interactions in the application and the objects to be programmed. In the class diagram these classes are represented with boxes which contain three parts: [2]
A class with three sections.
The upper part holds the name of the class
The middle part contains the attributes of the class
The bottom part gives the methods or operations the class can take or undertake
see further
I agree with the previous post but would like to add that a class diagram is based on UML which is an accredited language sponsored by the OMG and known by over 5 millions users. UML is therefore a standard based on a model from which you get views.
IN UML 2 the class diagram is fantastic if used with Java because it seems to me that the new specification has exactly the same structure as a java project. It include a project name, with packages including classifiers (e.g. Class, interface, enum) which includes attributes, methodes which includes properties.
If you have to use just one diagram I would say to use Class diagram. It is easy to create because you don't need to know UML and can reverse engineer your project into a model a get class diagram views. My class diagram is Just magic:-)
Class diagram represent class name,its attributes and behaviours whereas object diagram represent instance of class diagram,object diagram comes under class diagram
Allowing a store whether a product is available in the stock of another store partner, the latter may either accept or reject the request, in all cases the applicant is informed of réponse.
I want to implement a diagram class.
Now I have a class product, and a class list of collections of products.
I don't know how to represent a class of operation "request for product availability.
Is there a design pattern corresponding to this situation?
or a simple example of class diagram would be welcome.
I'm assuming that you are talking about representing your design in some suitable diagram, in which case you need to study some "Modeling Language" - probably the most widely used today being UML. This is a big topic, but you could start here.
Now diagrams such as these are really only useful when your design reaches some level of complexity. Here you are thinking about just a couple of classes and one method a diagram won't help much. So maybe you are doing this as a learning exercise?
You probably need both a Class diagram and a Sequence Diagram.
The major thing you seem to be confused about is how to represent Operations, they are just listed against the class. So your Store class would have an operation transferInventory().
So your class diagram is very simple only a couple of classes Store, Product. But the interesting thing is that your Sequence diagram will show that you have more than one instance of the Store class: StoreA, StoreB and the instances communicate with each other.
One thing you haven't talked about: how did StoreA know that StoreB exists? Why did it choose that Store to ask for a product. There's some additional classes here such as a registry of Stores. I would be much more interested in figuring out that than in drawing diagrams.
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