Beginer in UML, I have the followings rules for an Aikido club management:
R1: Every member should participate to the training practices.
R2: The trainees can come from other clubs in the same city or country as well as abroad.
I identify 2 classes:
To take into account the second rule:
Member (1) and Trainee (0..1)
Trainee(1.. *) and Training (1.. *)
Is there a correct way in what I am doing?
Your diagram is a beginning. The diagram as proposed by Thomas Killian is more complete. However, in both of these diagrams there is no notion of constraints or rules. It is simply not what class diagrams are used for. What you can express (with your diagram) is that one or more members can participate in a training and that a training is frequented by at least one member.
To express that every member must participate in training courses, you could need to express that, for all the instances of your class diagram, all members are covered with at least one association towards training. To do so you will need to formulate constraints, possibly using OCL, the Object Constraint Language designed to supplement UML and address the specific shortcomings you are facing now.
Basically this is ok. But the m-n relation between Member and Training should better be modeled as association class:
In this case you are able to add individual properties of members per training. When implementing this you will likely feel the need to introduce some glue (like a table in a database) between both.
I have also added a Club class assuming that a member is bound to just a single club. If you want to model multi-club relations you would probably again use an association class.
Related
I am making a class diagram. I have a Person class and an Address class. I am thinking there is a 'Has-A' relation between the Person class and Address class (Aggregation):
Am I right in marking the relationship as association?
Does it depend on us how we want the model the relationship?
For example, if I have two classes, Book and Library, I could say that Books shall not exist without a Library (composition) or I could say that Books may exist independent of library(Aggregation).
There is no one correct answer. There are many valid ways to model a scenario. In this case you could either mark the relationship between Person and Address as an association (more specifically aggregation), or you could mark it as a complex attribute.
Yes, details like that should be discussed with stakeholders / people who understand the domain you are modelling.
Is the association right?
Yes, you are right: a simple association expresses perfectly that a Person has an Address. Nobody could claim on the base of your narrative that your model would be wrong.
But modeling is a form of communication: You may well chose a different notation to add nuance in what you express, and you may decide for different semantics to tell how you see things in view of your needs.
Does it depend on us? Notation
In our example, you may want to clarify what you mean with the association by giving it a name:
Or you may prefer to clarify the role of the address in the association:
Or in complex diagrams you may prefer the shorter but equivalent property notation, nevertheless keeping in mind that "A useful convention for general modeling scenarios is that a Property whose type is a kind of Class is an Association end, while a property whose type is a kind of DataType is not":
Does it depend on us? Semantics
You could go for aggregation, but I'd strongly discourage it since UML does not define any semantic for it. So there's no benefit compared to a simple association.
You could consider composition. It might in general not be the best choice, as addresses exist independently of the persons. But in an application that creates separate Address objects for each Person, it could reveal how you intend to manage addresses.
Or you may want some richer semantics, for example with an association class to tell that people could have plenty of addresses of different kinds:
I am trying to create a system for managing vaccines against covid.
The system supports 3 different vaccines but each citizen can only get one and the system has to differentiate between the citizens who are older than 65, the AstraZeneca vaccine cannot be given to people older than that age.
Below I tried to create a basic UML class diagram. However I'm pretty sure I'm missing something since the vaccine should be also connected to the AstraZeneca class?
The diagram is confusing, since it only shows associations, but regrouping them in an unexpected manner. It looks more like a decision tree than a real class diagram.
First improvements you need to consider:
Pfizer BioNTech, Moderna and AstraZeneca are each a Vaccine: you should show this with a generalization from the specific vaccine to the general vaccine.
age 65+ seems not a good candidate for a class: in most OO languanges an object of a class keeps the class during its whole life. But citizen do not change class at 65. Age is a (derived) property of Citizen. The wording "astrazeneca vaccine cannot be given to people older than 65" moreover is an expression of a constraint.
Finally, if you manage vaccines, you need to manage also shots. When you write "citizen can only get one" you probably mean "one kind": the vaccines that you mention do in principle require 2 shots. And in most countries around the world, the two shots have to be of the same vaccine, which is another contraint. The remaining question is then if 65+ constraint applies to the first shot or the second?
This would lead us to a diagram that looks as follows:
Additional thoughts:
You could manage the shots by making the association Vaccination an association class.
There is an issue in the regarding the open/closed principle: if you'd add new vaccines, you might have to add different constraints on some. Alternatives:
Make Vaccine an abstract class (or an interface), with some more operations that need to be implemented by the concrete classes: getRequiredMinAge(), getRecommendedMinAge(), getRecommendedMaxAge(), getrequiredMaxAge(), instead of hard-coding the constraint.
Use a method Vaccine::checkCompatibility(c: Citizen) transfering the constraint verification to the Vaccine class
One could wonder if subclassing the vaccines is really required.
I'm studying for a reexam in OOAD and doing some old exam questions. I'm trying to develop an analysis class model that may be used to manage a restaurant's menus. Here are the requirements:
Several different menus (breakfast,lunch,dinner)
Dishes may exists in several different menus
The restaurant also provides catering
Dishes should keep information which is relevant for guests with special requests (vegetarian,allergies etc..) Special menus may be created using this information as search criteria.
How I should model the catering? Should there be a Menu class and then breakfast,lunch,dinner and special as specialization classes or should I just have one Menu class? Should there be specialization classes for vegetarian,gluten free..etc dishes?
Then I have this question which confuses me a bit..
"What are 4 tasks that must be addressed when you transform this analysis class model into a design model?"
What is meant by this? Are there 4 general tasks/steps that always should be done when translating an analysis model into a design model or is it 4 specific tasks specifically for this analysis class model?
I've looked thorugh the presentations and the book (OOAD with applications) and the only thing I found related to these 4 steps/tasks was in a case study:
■ Identify the architectural elements at the given level of abstraction to further establish the problem boundaries and begin the object-oriented decomposition.
■ Identify the semantics of the elements, that is, establish their behavior and attributes.
■ Identify the relationships among the elements to solidify their boundaries and collaborators.
■ Specify the interface of the elements and then their refinement in preparation for analysis at the next level of abstraction.
Regards
How I should model the catering? Should there be a Menu class and then breakfast,lunch,dinner and special as specialization classes or should I just have one Menu class? Should there be specialization classes for vegetarian,gluten free..etc dishes?
You should be modeling your business requirements. In your case, the requirements you have are from your exam task only. So you will have to decide what you include in your model. Only include in your business domain model what you think you will need to hold a state, or perform an operation on.
Should there be specialization classes for vegetarian,gluten free..etc dishes?
Should be possible to save that in a simple boolean flag in the meal class, don't you think?
The "4 tasks" question is open for interpretation and is probably best answered when you have the documents from your studies available. At least I'd consider the 4 tasks you list a reasonable answer to the question.
Welcome to StackOverflow.
If you post your modeling attempts as a image file, you may receive more detailed help. You may use a service like dropbox to reference graphics until you have enough reputation for uploads to SO.
Class diagram by myself,for reference.
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.
What is the difference between a domain model and a data model?
A datamodel is a design model that only describes data and it's relations. The model contains entities, but they are described in terms of what data they own not how they act on this data or what their responsibilities are.
An domain model on the other hand, is a conceptual model used in analysis of a problem domain. It describes the domain in terms of entities that have relations, data and behaviour. It describes the responsibilities of those entities as relevant for understanding the problem domain.
BTW an excelent and very short introduction to UML is:
UML Distilled: A Brief Guide to the Standard Object Modeling Language
A data model is focused on the DB schema definition, including tables, columns, and relationships.
A domain model is focused on the business domain, including concepts (classes of objects), behavior (methods/logic), and relationships.
In both cases, the cardinality is used for relationships (e.g. 1:1, 1:Many, 0:Many, ...).
That said, you would ideally like the data model and domain model to be closely related, i.e. a Person with name, ... and a MailingAddress, ... relates to a PERSON table with a NAME column and a FK to a MAILING_ADDR table entry. You have to decide where logic is hosted - in the objects in the software system vs. in the DB via procedures, triggers, and such.
I think it's important to provide some clarity here for posterity.
A data model is a design for how to structure and represent information. By structure, I mean concerns like "fifth normal form". By representation, I mean choosing a computer serialization, such as integer, floating point, or string.
The term domain model actually has two conflated meanings.
A model of essential characteristics of real or imaginary things in the world. In this kind of model, classes represent human conceptualizations and instances are things in the world. For example, a "Person" class would have instances including you and me, and an essential characteristic might be that every Person has a mother. This kind of model is often called an conceptual ontology or concept model and is intended to provide meaning.
A model of required information about things in the world, usually with some system in mind. In this kind of model, classes represent information that must be stored about things in the world. For example, a "Person" class would have instances representing required information about you and me, such as first name, last name, date of birth, current height, and current weight. This information often does not include all essential characteristics, such as our mothers, because, for the purposes of a particular system, that information is not required. This kind of model is often called an information model, conceptual data model, or operational ontology.
Both the UML and OWL languages can be used to represent either kind of domain model. Both can be considered analysis models, as they are used to analyze a domain. One is used to understand things in a domain, the other is used to gather requirements to build a particular software or database system for things in a domain. Both are necessary, and, unfortunately, they are usually conflated such that people building an analysis model are themselves confused about what they are modeling!
I think that domain model and data model are now pretty much the same with new top down modelling technologies. I mean that you can model in a class diagram and only add database stereotypes in your diagram. If you use the tool that I use then your ejb3 annotation would be immediately synchronized with your code. The next step is only to use a mapper to create your database. This technology only works with Java