I'm trying to make a UML class diagram for a very simple scenario. Consider the following code: List<Food> foods = {new Tomato(), new Pizza()}; as a field to class A. Clearly, class A has associations between Tomato and Pizza, but should it also have an association between Food?
Of course, Tomato and Pizza extend from Food :)
The use of generics such as List<Food> is always a challenge in UML, since the semantics of generics are not the same across the programming languages.
Here, the field foods of class A means that there is a navigable association from A to Food. And Tomato and Pizza are specializations of Food (based on your use of the term "extend"):
Additional remarks:
The association is with Food, because the type is List<Food> and there is no direct coupling between A and Tomato or Pizza.
Keep in mind that a class diagram shows the general picture and not a specific scenario with individual objects (that was the purpose of the former object diagram).
The use of a list tells that the association can be with be 0 or more Food. But we don't know if one Food object could be used by several A or not (several is theoretically possible if Food would be a reference type): therefore the multiplicity is unspecified on the A side.
Based on the semantics, you may consider making the association a composition or an aggregation. But a simple association is correct in any case.
Based on the what you want to highlight about your design in the A-to-Food association:
you may prefer the dot notation on the Food end, if you want to underline that the association (aka the list) is owned by A
you may just use navigability notation as in my diagram, if care less for the current implementation and just want to express that accessing Food from an A should be easy.
you may show none of the above, if you want to keep these topics open.
I would say your ClassA has a structural relation (association) to Food.
Because it also calls the constructors of Tomato and Pizza it has a dependency to those classes.
Without seeing more details it's difficult.
Your food is a 0..n multiplicity association.
Both Tomato and Pizza do not have an explicit assocation in that code. So that's just a dependency.
An association is a stronger form of a dependency (sloppy definition that is). Actually you can create an association. It depends on the yet unknown details. If your focus is on the list and you want any subclassed food in it, you would not draw associations to each of these subclasses but only to the parent class Food.
As said: it all depends and as a design template the details from the template need to be more beefy.
Related
I'm having a difficulty figuring out where to put the Level attribute. I want the employee to have a variety of skills which have different levels. For that purpose I made a many to many relationship which is implemented as an EmployeeSkill association class.
An example of said class is as follows: An employee named Jack might have a skill of Java which is level beginner, while he could also have a skill of C# which is advanced level. Should the level be saved in the EmployeeSkill association class or in the Skill class? I suspect it should be on the association class.
A property of the association class?
Your narrative with the Employee instance "Jack" being associated with Skill instance "Java" with a level of "beginner" shows that the skill is independent of the level, and the level is related to the combination of a given employee and a given skill.
To model accurately the semantic of this narrative, level should indeed be the property of the association class EmployeeSkill.
Could it be a property of the skills?
It would not be wrong to move level as a property of Skill. But the model would have a different semantic, since every Employee associated with a Skill would share the same level. This means that "Jack" being associated to a skill like "Java" but rather a skill like Elementary Java.
This alternative model makes it also less convenient to desperately search for all employees knowing about Neural network regardless of the level. And it would not be obvious for the system to see that elementary neural network is related to advanced neural network expertise and that Advanced java has little to do with Advanced javascript.
To have the same power of expression, the skills that are related but correspond to a different level would require an explicit association, which would make the model more cumbersome to use and fragile.
Remarks that are unrelated to your question
You seem to repeat the JobCategory's and the Country's attribute within Employee. This is confusing, as the associations already associate the class with another set of each of these attributes. Did you mean the redundant attributes to implement the associations and show the db table layout than the class? If so, you should disambiguate using some custom stereotypes. But I'd rather recommend to remove the redundant items and make a comment at the bottom of the diagram to explain that you implement associations.
I wonder if the multiplicities of the association between Skill and SkillCategory are not inverted (i.e. one category can have several skills and each skill is associated with only one category) ? Or that you meant a many-to-many association if skills can belong to several categories.
In the association class you use the prefix FK to highlight the foreign keys. Use <<FK>> to make it a custom stereotype (see may first remark about using stereotypes).
As qwerty_so pointed out in the comments, you use a nesting connector for the associations with enumerations. This is syntactically acceptable but does not mean what you think. This is meant to deal with namespaces. Just remove that circle-plus symbol to make it a normal association and it will mean what you think.
I have a hard time understanding the concept of association class as explained in UML 2.5 specification. The thing that confuses me the most is the following sentence taken from page 199:
NOTE. Even when all ends of the AssociationClass have isUnique=true, it is possible to have several instances associating the same set of instances of the end Classes.
As noted here: https://issues.omg.org/issues/UMLR-757 this single sentence seems to undermine the usefulness of the concept. At the same time, it makes pretty much every text explaining the concept written before 2.5 version of the UML spec obsolete – see for example the discussion here: UML association class - clarifying
But how can this actually work conceptually? Assuming all ends of the association class have isUnique=true, how can one have more than one instance of association class associating the same set of instances of the end classes, when isUnique property of member ends clearly forbids existence of such links?
I’ve always thought that an association class is just a regular association with extra attributes and/or operations. That interpretation seems to invalid now. So what exactly is association class? How can it have uniqueness independent from that of association member ends? There seem to be some unspoken multiplicity lurking somewhere (uniqueness is irrelevant property without maximum multiplicity higher than 1), but I can't figure out where.
In very short
Indeed, this is not super-clear and would deserve a better explanation. To make it short: it’s just a consequence of the lack of integration in the dual semantics defined for the association class.
Detailed explanation
What is uniqueness for an association
According to UML 2.5.1 section 11.5.3.1, page 197:
When one or more ends of the Association have isUnique=false, it is possible to have several links associating the same set of instances.
We can deduct using logical contraposition that:
If it is not possible to have several links associating the same set of instances, all ends of the association have isUnique=true.
So we'd expect this to apply to an assocation class as well, since the association class is also an association.
Association classes are two distinct things at the same time
According to UML 2.5.1 section 11.5.3.2:
An AssociationClass is both an Association and a Class, and preserves the static and dynamic semantics of both.
So, an association class is not just "an association with extra attributes". If it were that simple, the association class could perfectly be a generalization of an association: the specialized association would just inherit the extra attributes. But this is explicitly prohibited page 199:
An AssociationClass cannot be a generalization of an Association or a
Class.
because any specialization into a class would loose the association semantics, and any specialization into an association would loose the class semantics.
And this duality, is the cause of our issue.
Impact of this duality on instances
According to UML section 11.5.3.2, page 199 (formatting from me):
An instance of an AssociationClass has the characteristics both of a link representing an instantiation of the AssociationClass as a kind of Association, AND of an object representing an instantiation of the AssociationClass as a kind of Class.
If isUnique=true for all association ends, the instances of the association are guaranteed to be unique. Remind however that the association is only about tuples made out of the association ends:
An Association declares that there can be links between instances whose types conform to or implement the associated types. A link is a tuple with one value for each memberEnd of the Association, where each value is an instance whose type conforms to or implements the type at the end.
However, nothing in the specs requires that the class instantiation (object) representing the association instantiation needs to be unique.
Imagine for example, that we have an association class between class A and class B, and a and b are instances of these classes. Imagine that the association ends have isUnique=true. This means that there can be only one tuple (a,b) since the association is guaranteed to be unique.
Let P be a property of the association class, and let (a,b,p1) and (a,b,p2) be two instances of the class in the association-class. The class knows no association-ends: from the point of view of the class, there is no unicity requirement. And from the point of view of the association, we have only one tuple (a,b) , so it's ok as well.
The NOTE just explains that this (unfortunate and ambiguous) situation is possible.
Are there contradictions or inconsistencies?
Formally, there is no contradiction. This is the result of the way the association class is defined: a class and an association at the same time, without further defining the relationship between the respective instances.
But this creates some issues in regard of the semantics of associations having non-unique ends:
When one or more ends of the Association have isUnique=false, it is possible to have several links associating the same set of instances. In such a case, links carry an additional identifier apart from their end values.
More precisely, this makes the the association-class with unique ends useless, since the same result can be achieved with non-unique ends:
for a simple association with non-unique ends, you can have duplicates, i.e. several links associating the same instances of the association ends that are distinguished with an additional identifier.
for association classes with unique ends, according to the note you can have duplicates, i.e. several objects (class instances) corresponding to a link made of unique association ends (association instances).
for an association-class with non-unique ends, you could have duplicates, i.e. several object instances correspond to the same set of member ends. It makes no difference if you interpret this as several links associating the same instances of the association ends, each associated with a single object, or, if you interpret this as one link associating a unique set of instances of the association end, that would be each be associated to mutliple object instances.
IMHO, this is unfortunate:
it does not match our mental model in which an association class with all association ends having isUnique=true should have a unique object instance of the class for a unique combination association ends. This clearly goes against the principle of least astonishment: I started with deny and it took me a while to accept this, since it was so terribly different from the traditional ways to implement association classes.
two different models, one with unique association ends, and one without could in fact express the same situation.
A simple solution to this issue would be to require a unique class instance (object corresponding to the association class) to correspond to a link that uniquely associates association ends. In that way, unique association ends would imply unique association object, without requiring other changes to the UML specs.
I'm drawing a class UML for a JAVA software design. I don't really understand what is a stereotype. The formal definition:
The stereotype is a profile class which defines how an existing metaclass may be extended as part of a profile. It enables the use of a platform or domain specific terminology or notation in place of, or in addition to, the ones used for the extended metaclass
Is that mean the stereotype should be the name of the parent class? But why there are some superclasses also has a stereotype?
So for example, I have a superclass Animal and a class dog which extends the Animal class, what could be the stereotype of both classes? Also, why there are some classes without stereotype.
What is a stereotype and what are its purpose?
A stereotype extends UML by allowing to categorize some elements in a more detailed way than foreseen natively by UML. It helps to make the model more expressive.
A typical example are the Entity, Control, and Boundary stereotypes. They are used in a use-case driven design: in a class diagram, you can immediately find-out which classes represents the use-case logic (marked as «control» stereotype), which classes represents user-interface with actors («boundary» stereotype), and which classes represents business/domain objects (marked as «entity»).
Another use of stereotypes is to indicate the way a class is supposed to be implemented, for example to mark as «table» classes that correspond to database tables that are related to in-memory objects, or to indicate among the objects which ones are «persistent». An even more common use is to show some concepts that are language specific and have no equivalent in UML. I think in particular to C# «struct» which have a value semantic wheres C# classes have a reference semantic, or C# «property» (which is a stereotype at attribute level).
How are stereotypes defined?
Sterotypes are defined in a profile. You can see a stereotype as a class in a profile diagram.
But it's not an ordinary class that you could relate to other classes in your model. So there is no inheritance at play here. You would never indicate a superclass as stereotype.
A stereotype is a class related to the "metamodel", which means the UML standard elements defined in the UML standard. So it's a class of classes (or a class of associations, or of any other UML element).
To elaborate on your example, with an abstract superclass Animal and concrete sub-classes Cat and Dog:
you could affect them all an «entity» profile, because they all belong to the domain model.
if you would want to store the objects in an RDBMS using the concrete table inheritance, you may use a stereotype «persistent» for Cat and Dog (since concrete table inheritance pattern does not implement persistence for the abstract classes)
This was the scenario given and we had to create a class diagram of it:
"Rhonda University has one Vice Chancellor who is in charge of the whole university. There is a Students Registrar who solely looks after the interests of the students. The Students Registrar uses a system called Student Records to maintain the students’ details.There are a number of faculties and each faculty has many departments. Each department has lecturers that are employed by the University. A lecturer can teach in many departments."
How I understand "inheritance" is it adds new functionality to the class, so in my class diagram the Vice Chancellor has inheritance with the university because it adds the "management" part to it, this applies to the students registrar and faculties because they add new functionalities to the university class right?
Your use of inheritance is completely incorrect. For example, you claim that a Lecturer is a kind of1 Department. That is obviously untrue.
To begin to understand why, think of subclasses as subsets of instances, and superclasses as supersets of instances2. For example, a set of Dog instances is a subset of a set of Animal instances. Everything that is true about an Animal instance must be true about a Dog instance.
1 The proper way to read a generalization arrow aloud is "is a kind of", as in "A Dog is a kind of Animal".
2 Technically, classes are instance factories, as well as types that specify the intension of sets of instances, but that probably just makes the idea harder to grasp.
Why and how are dependency relationships used?
I've come across a PiggyBank example where the Analysis Model consists of a class diagram with dependency relationships.
They use two relationships "use" and "instantiate" to describe the relationships between the classes.
I don't agree with the relationship that the boundary class TransferMoneyForm has a "use" to the TranferMoneControl. I believe it should be the other way around.
Can someone exaplain to me how these two relationships should be used. Thank you in advance.
The diagram shown there is not a correct and full UML class diagram. In such all the associations and generalizations should be defined, and what is abstract, what is public or not. To show what descends from what, what is hidden, what will be never instantiated and what fields of one class has types of other classes. Here we see only information about the
functions.
And it is logical. If you'll look at the previous chapter, there is written: "A control class represents a self-contained process..." So, they are talking on processes, not classes, instances and fields.
It is NOT a class diagram. And nowhere is said that it is. It is named "Transfer Money Participants diagram". They do use the elements of the class diagram, but not to the fullest and so create something more common. It is some approximate undefined diagram on some classes, something between class, communication or component diagrams. Maybe, it is the old style of IBM? Experts (What's the best UML diagramming tool?, 1st answer) say, "IBM Rational Software Architect did not implement UML 2.0". )
As for the question, who uses whom... According to Sparx VP UML, a "usage dependency" is a "relationship in which one element requires another element ... for its full functionality". According to wiki, "The client element somehow "uses" the supplier". Here the form hasn't sense without the controlling class, and vice versa. So, I'd say, the use goes in both sides. But more honest would be to create a normal communication or component diagram. The class diagram has NOT an element to say about sending and accepting the messages. And the "use" is definitely not for it. And when they have decided not to use logic, they can put there virtually anything.
If you are making a class diagram and one your class uses function(s) of another one, that is the case to draw a use dependency connection.