I have to indicate for the Employee class that each employee can be clearly identified by his personal number. I do not know if I think too complicated, because I have no real idea.
Attributes:
final int personelNumber
...
You don't even need an OCL constraint to express that in UML.
There is a property isID on the Property metaclass that ensures this:
From UML 2.5 specification ยง 9.5.3 (p. 111)
A Property may be marked, via the property isID, as being (part of)
the identifier (if any) for Classifiers of which it is a member. The
interpretation of this is left open but this could be mapped to
implementations such as primary keys for relational database tables or
ID attributes in XML. If multiple Properties are marked as isID
(possibly in generalizing Classifiers) then it is the combination of
the (Property, value) tuples that will logically provide the
uniqueness for any instance. Hence there is no need for any
specification of order and it is possible for some of the Property
values to be empty. If the Property is multivalued then all values are
included.
The notation for this property is similar to that of other constraints
using
{id} after the name and type of the attribute
You don't provide your metamodel, and clearly wrt to each Employee their personelNumber is single valued and so necessarily unique. Presumably it is within some scope such as a Company that the personelNumber should be unique, so the answer is often something like.
context Company
inv UniquePersonelNumber: employees->isUnique(personelNumber)
Two alternative OCL expressions can be found in the following question:
Why allInstance not for isUnique?
In your case, it would be:
context Employee
inv personalNumberUnique : Employee.allInstances() -> isUnique(personalNumber)
Related
For example, let's say I have a situation like this
Can I write an OCL expression that counts how many students a school has, such as:
School.students->count()
?
Or would it be incorrect? And in that case, how would I count the number of students?
Yes, the dot is the correct OCL syntax, here.
This is explained in the OCL specifications, section 7.4.10 on navigation operators:
The "." navigation operator supports navigation from an object using a property or operation.
The "->" navigation operator supports navigation from a collection using a property, operation or iteration.
Furthermore, section 7.5.3 on navigation of properties explain that:
Starting from a specific object, we can navigate an association on the class diagram to refer to other objects and their properties. To do so, we navigate the association by using the opposite association-end:
object.associationEndName
The value of this expression is the set of objects on the other side of the associationEndName association.
There is just one issue here: students is not formally defined. In principle you should use the role name indicated at the association end (next to the *), and if no such role is given in the class diagram, you should use the class name instead, so student.
Not related: count() is used with an argument regarding the objects that have to be counted in the set. If you mean the number of students associated with a given school, you should use ->size()
In an UML class diagram:
a) Do you have to state attributes that are aggregated? Or is it enough with the arrows indicating aggregation?
b) Do I have to add "id" as an attribute or is it a given?
Thanks.
You are using a shared aggregation in the picture. That does not have any defined semantics as per UML 2.5 (see p. 110). If you need a composite aggregation the diamond must be filled. In that case the aggregated object will be deleted along with the aggregating one (the latter must assure that constraint). In your model it makes no sense. No employee aggregates a department. Even vice versa I would have doubts or at least reason for discussion.
An id is only needed if it has a business purpose (e.g. an article number). If you transform your model to a database you introduce an artificial id for technical reasons. But on an abstract business level they are not modeled.
Your models only differ in the use of attributes for associated classes. The B variant is preferred. But you need to place the attributes as role names towards the associated classes (as -department and -branch). What you have placed in the middle of the connectors is rather the association name. Badly chosen with the + in front. Naming associations is rarely needed. So get rid of that. Role names shall be placed near the class that takes the role. Also it's a good idea to use the dot-notation to show that the roles represent owned properties. Just place a small black dot near the left hand side of both (near where the role names should go).
As for the dot-notation UML 2.5 states on p. 18:
Dot notation is used to denote association end ownership, where the dot shows that the Class at the other end of the line owns the Property whose type is the Class touched by the dot. See 11.5.4 for details of Association notation and 11.5.5 for examples.
Also as JimL. commented the A-version uses associations plus attributes which introduces redundancy. This is not illegal but likely not intended and at least leads to confusion.
I have a User class that can "measure" some parameters associated to a date and input them in an application. So 1 User -> many parameters of many types associated to many dates (many measurements). The parameters types are fixed and can be both numeric or strings, e.g: weight, height, calories intake, some strings... which are represented as an enumeration.
Now my main problem is: does the fact that the parameters can be of different datatypes (numbers or strings) mean that the general parameter type has to have specialisations for the two subgroups of parameters? Or is the datatype for each type of parameter implied in the type itself? (e.g. a "weight" implies it should be a number)
How can the "Parameter" class be represented in a correct way considering that:
it can be both numerical or a string
there is also a superuser class that can add parameters for a specific user
the parameters the superuser can input are some of the ones the normal user can PLUS some other parameters exclusive to the superuser (say: fat body mass) so there is not a 1-1 correspondence
the numerical parameters have other additional attributes that can be modified by the superuser (for example: limit weight)
the superuser supposedly should be able to add "notes" for some parameters
My confusion stems from the fact that I have no background in OOP programming and i can't find any similar examples online. I just need an input towards the right direction to go to. Is the pictured diagram correct? And why it most likely isn't? The problem as of now would be how to implement the fact that the superuser can also add notes to some parameters.
Do I:
create a single parameter class with the enumeration type as attribute which automatically implies the datatype of the input e.g weight = number?
create two subclasses for each User, e.g. UserParameters and SuperUserParameters, although some parameters overlap?
leave it as is with some adjustments?
other better approach?
I'd like to propose using an improved terminology. Since your app is about (health) property measurements, I'll replace your class name "Parameter" with Measurement.
The following model should satisfy all of your requirements (except the one discussed below):
Notice that the two subclasses UserProperty and SpecialProperty simply define a partitioning of Property. They can be eliminated by adding an enumeration attribute propertyCategory to the Property class, having USER_PPROPERTY and SPECIAL_PPROPERTY as its enum literals.
The only requirement, which is not yet covered, is
the numerical parameters have other additional attributes that can be
modified by the superuser (for example: limit weight)
This needs further carification. If these "other additional attributes" form a fixed set, then they can be modeled as further attributes of the Property class.
I don't think you should do that on UML level at all. You are going into memory management/overlays. And those are implementation details you should not take care of. Rather you are dealing with HeartRate and Weight as distinct objects. They will not have a common "value", which is just some memory allocation. They are what they are and whether you need a string or a number is some property of the distinct business objects.
Through searching I found that in UML, aggregation(assuming that it's used properly) can be used to represent attributes in a class.
For example,
(Assume column can stand alone)
Then, using such example, if I want to replace the attribute: Column[] with map to represent the column's name, would it be correct to use an association class just like below? (In case, I'm not willing to put the column name in Column class as an attribute)
Association classes are used with simple associations. They have m-1-1-n multiplicity. The shared aggregation (as you used) has no defined semantics (and I recommend to simply not use it unless you have a domain specific and documented use for it). It's simply better to put the intended multiplicity on either side of an association.
An association class connects two classes, adding attributes and/or operations. Your example is "unconventional" since Table/Column have a simple relation which would not need an association class. A general example is the Student/Lecture relation where you can put an association class in between to record exam results, times etc.
Yes, I think that is a valid way of modelling the fact that you have some sort of key string that can be used to identify a Column of this Table.
Using a Map is one if the many possible implementations, so it's not a real equal to.
The advantage of modelling using the Association Class is that your model remains at the more abstract functional level and leaves out implementation details.
BTW. I would use a composition instead of an aggregation for the association between Table and Column, as there is an obvious strong ownership relation and life-cycle dependency between the two.
If you want to replace the attribute Column[] with map to represent the column's name and you are not willing to put the column name in Column class as an attribute and assuming that you want to follow UML specification precisely then you'll produce the model shown below:
Map<Key, Value> is usually understood as an associative container that contains key-value pairs Map.Entry<Key, Value> with unique keys. The container is modeled by the directional aggregation from Map<Key, Value> to Map.Entry<Key, Value>.
Map<Key, Value> and Map.Entry<Key, Value> are templates. Clause 7.3.3.1 of UML specification says that:
A template cannot be used in the same manner as a non-template Element of the same kind. The template Element can only be used to generate bound Elements or as part of the specification of another template.
According to clause 7.3.3.3:
A TemplateBinding is a relationship between a TemplateableElement and a template that specifies the substitutions of actual ParameterableElements for the formal TemplateParameters of the template.
Thus we have two bound elements that have TemplateBinding (marked by <> keyword) relationships with their templates:
ColumnNames which essentially is the name for Map<String, Column>
ColumnName which essentially is the name for Map.Entry<String, Column
According to clause 11.5.1 of the UML specification:
An Association classifies a set of tuples representing links between typed instances. An AssociationClass is both an Association and a Class.
ColumnName is AssociationClass representing the link between instances of String and Column classes. We use notation from clause 11.5.5, figure 11.35 to express that.
Finally, the directional composition association between Table and ColumnNames classes tells us that each instance of Table owns an instance of ColumnNames, i.e. set of column names.
Note that while ColumnNames and ColumName classes are usually hidden from the end-user by an implementation, they nevertheless exist.
I used BoUML to draw the diagram.
Entities should not have equality comparison (https://www.youtube.com/watch?v=xRCOKKUSp9s).
Value objects should have equality comparison (https://www.youtube.com/watch?v=xRCOKKUSp9s)
Value objects can reference entities (Domain-Driven Design book)
Value objects are equal if all (or some?) of their attributes are equal (this one is not so explicitly stated, but it seems natural, https://martinfowler.com/bliki/ValueObject.html,http://enterprisecraftsmanship.com/2016/01/11/entity-vs-value-object-the-ultimate-list-of-differences/, https://projectlombok.org/features/Value). There might be rare exceptions (for example, (1, min) == (60, seconds)).
So if a value object has a reference to an entity, how should we include entity in that equals() comparison if we cannot call equals() on entity? Where is the flaw?
For me it is natural to implement Entity.equals() (usually based on type and ID). It is strange that I encountered that video (1).
Value objects are equal if all of their attributes are equal. Now let's see how is it for value objects that refer to entities. Entities needs to have a unique identifier (id) and that id is allowing the value object to refer to the entity. In other words the value object will have an attribute which have the entity id (userID for example) and in the vo.equal() you just include that attribute.
I don't think there is any need to implement Entity.equals(). Entities are designed to be unique even if they have all the same attributes and that's why we use ID to differentiate them. There might be the need to ask "is these two VOs referring to the same entity?" (same example in first video second 0:33) but other than that I don't see any need to compare Entities.