I'm working on a design of a workout follow up program.I have the following relational diagram and I want to create a class diagram with it.
In this case I should create an associative table as follow:
To explain the relation: a muscle may be targeted by many different exercises and an exercise may target many muscle.
Is the following representation correct? Can we improve it?
If it is not correct, can any one suggest the best way to represent it in a class diagram?
Your diagram is almost correct. You should replace all the occurrences of List<...> with association-end properties. To do this, you will need two associations. Here's an example:
I took the liberty of changing the multiplicity for the primaries. I think each direction has at least one. This shows why using associations is more expressive--with a List<...>, you cannot express min and max cardinalities.
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
I know that I can build a Class diagram from a database E-R Diagram (tables become classes, tables properties are the classes properties...)
But I'm looking for informations (or step by step like) to create a class diagram from a use case description (or even a sequence diagram).
(All I found now is that the sequence diagram objects becomes classes and the stimuli messages methodes)
Any idea ?
I used to TA in software engineering, and both create a class diagram from a textual definition as well as create a class diagram from a sequence diagram were regular exam questions.
Creating class diagrams from a specification should be covered in your lectures since its one of the most important things to learn. This site explains the workflow quite well in my opinion.
It is important to note, that in software engineering there never is just one solution. You can tackle problems in multiple ways each with their own benefits and problems. The most important step to learning is doing it yourself, just looking at solutions won't help you.
For creating class diagrams from a sequence diagram:
Objects are instance of classes, in most sequence diagrams there is only one instance of any given class. Therefore "objects become classes" is not technically correct but the right intention.
Messages represent method calls on the receiving object, ergo you need to add these methods to the class of the receiving object.
Any communicating classes need to be associated, else they could not call their methods.
We put focus on only modelling the information you can derive from the sequence diagram, e.g. in most cases you do not know multiplicities of associations.
Please can anyone suggest any improvements or corrections in the attached sequence diagram. The diagram is regarding student registration and search book.
You should not think on classes creation being in sequence diagram. Make a class diagram, maybe an object diagram, and after that make your sequence diagram with instances of created classes as timelines. Add a class diagram here, without it it is impossible to answer your questions.
As is, you are working with elements of use case diagram (agents), not classes. It is acceptable, too. But then you should create a component diagram and use components as timelines.
So, your problem is that you have minimally one diagram less than you should. A whole diagram, not a block in one.
So, for this task you can use the following sets of diagrams:
The fullest one: Use Case + State + Component + Communication + Sequence + Class + Object + Composite Structure
The wide refactoring of your diagram: Component + Sequence + Class + Object
The minimalistic refactoring: Sequence + Class
Of course, you can make more than one diagram of any kind mentioned. Also, some diagrams if they are small, can be combined in one - UC+State, for example.
The normal process is creation one diagram after another, returning to the previous ones. Behaviour/structure diagrams of the same level can be created simultaneously. If you have problems with some thought on one diagram, try to express it on another one.
Yes, you can do a sequence diagram for every action of use case or even of Activity/communication diagram. But if your seniors won't make you to do it, it is enough to create only these diagrams that are needed for better understanding of the process.
Sequence diagrams, in the context you're using them, should be modeling a single path through a use case. Think of it this way: a use case diagram models the different things that a system does and who interacts with it. An activity diagram models out the behavior of a single use case. A sequence diagram models out a single path through a use case (in other words, a single path through an activity diagram that models a use case).
In the case of your above sequence diagrams, it looks like you have two use cases: "Login" and "Create Account". Create account extends login. I would suggest that you first document in detail what each use case does (google "Use case narrative" for more information). Use an activity diagram if it helps clarify the narrative. Then look at the individual paths through the use case (google "use case scenario" for more information), using sequence diagrams to help clarify the scenarios as necessary.
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've had this discussion with my professor at college about UML diagrams .
He believes that sequence diagrams should be drawn before getting to class diagrams, but I think the opposite . I think after finishing the usecase diagram , the next diagram should be class diagram and after that we should get to sequence diagram.
Rational rose requires us to use the classes in sequence diagram, which are already in class diagram.
Can anyone help me with this?
I think you're both wrong. They should be drawn at the same time. As you're drawing your sequence diagram, you will undoubtedly come up with properties that you will need to keep track of the state, or that you hadn't thought of if you do the class diagram in a vacuum.
Of course, this is highly subjective and personal, but years of real-world experience (as opposed to academic theory) have taught me to work on both at the same time. MAYBE starting with the class diagram, but the class diagram invariably changes when you start going through process flows.
Well it depends a lot on how you plan to do things. I think it's a subjective matter. If you rather explain the actions performed for your usecases and after this has been done write the classes based on what you need to perform the sequences your professor is right.
But if you prefer to determine what the structure of your classes are and then adapt the action sequence to this then you would do the class diagram first and later the sequence.
In my experience I do them concurrently. I put the fundamental attributes to the class diagram but not the actions, and while I do the sequence diagram I add the methods and attributes that I need to the class diagram.
There is no one standard answer. There are several opinions, approaches and methods. In Unified Process I believe you first identify use case and then make realizations for them, e.g. sequence diagrams. As in use cases, there are actors and the systems and/or its parts interacting ina sequence. Actually this interactions should help you decompose your design and get to classes. Once you have classes on the analysis level, you can go further to design classess and design interactions. However these are quite a lot to draw in a diagram, most of the times code is the best documentation on this level, even generated diagrams are too large and more difficult to understand then code itself.
To prepare sequence diagram you need classes not the class diagram
You can prepare empty classes on the fly while in process of preparing sequence diagram....
Identification class objects in be part of preparing sequence or you can try to identify your objects before hand....
sequence is logical process while class diagram is end output
I don't think there is an order for creating diagrams since both are two different views of a system: class diagram structural (static) and sequence is behavioral (dynamic). I would start with sequence diagrams since you will discover more classes to create as you go through sequences. Do whatever makes sense for you at the time. If your doing more object oriented programming, I would consider doing classes before sequences.
Structural and behavioural models for all but the very simplest systems are naturally created simultaneously and iteratively, refining both over time.
You may have some method of "object discovery" such as CRC cards, which will yield a set of initial classes, with collaborations (the classes they interact with) and responsibilities, which informs both the methods they will need, and internal behaviour/state/activity.
You may then want to explore the use cases and scenarios using sequence or communication diagrams, this will expose the details of the required object communication and therefore inform the generation of public methods and relationships to refine the class diagram while at the same exploring the system behaviour which may yield further objects and classes to be created.
You may also want to explore the internal behaviour of classes, especially if they have stateful and/or active behaviour; activity ans state-machine diagrams are useful for this.
Either way I doubt that the use of Rational Rose is really the determinant of diagram creation order. Rational may require the classes on a sequence diagram to exist, but I imagine that they need not actually appear on a class diagram; they can probably equally be created on the sequence diagram and then later placed on a class diagram, or even created in the project explorer or whatever the equivalent is in that tool. Even if the only method of creating a class is to place it on a class diagram, that does not require you to refine and complete the class or its relationships before exploring interactions on a sequence diagram.
You need to buy some clothes, how you will proceed. You start choosing clothes first or you will decide first where to go? At the same time, will you go to shoe store if you want to buy shirt.
So both are iterative, but definitely first step is sequence on very high (component) level then drill down to class level sequence
You should first decide your application flow,means you should first draw a sequence diagram. It will show the flow of your application after this you should go for class diagram.