There is a need of some standard approach to cover the entire spectrum or requirements analysis, modeling, design, implementation, and deployment of databases and their applications. One approach that is receiving wide attention and that is also proposed as a standard by the object Management Groups is the Unified Modeling Language (UML).
Object-oriented data models are typically represented using UML. As the term suggest, this is essentially an OO system modeling notation. It does not only focus on data requirements but also on process modeling. It was accepted in 1997 as a standard by the OMG and approved as ISO standard in 2005. The most recent version was introduced in 2015 and is known as UML 2.5. To model both the data and process, UML foresees multiple diagrams such as use case diagrams, sequence diagrams, package diagrams, deployment diagrams, etc. from a database modeling perspective, the class diagram is the most important as it allows to visualize both class and their associations.
Recap of object-orientation:
The two important building blocks are:
- Classes: blue print building definition for a set of objects. A class in OO corresponds to an entity type in ER. Ex: Student
- Object: instance of a class. An object corresponds to an entity. Ex: Student Ysaline. Each object is characterized by both variables (name, gender, birth date) and methods (calcAge(), isBirthday(), etc.).
Information hiding states that the variables of an object can only be accessed through either getter or setter methods. Getter methods allow retrieving the value of a variable whereas the setter method allows setting it. The idea is to provide protective shields to make sure that values are always correctly retrieved or modified.
Inheritance is here also supported. Therefore, a superclass can have one or more subclasses which inherit both the variables and methods from the superclass. Ex: student and professor can be a subclass of the person superclass.
In OO, method overloading is supported which means that methods in the same class can have the same name, but a different number or type of input arguments.
Ex: Class: SUPPLIER. A class is represented as a rectangle with three sections. In the upper part, the name of the class is mentioned, in the middle part the variables and in the bottom part, the methods. UML also allows defining access modifiers for each of the variables and methods. This access modifier specifies who can have access to the variable or method.
- Private: variable and methods can only be accessed by the class itself.
- Public: in case variables and methods can be accessed by any other class.
- Protect: variable and methods can be accessed by both the class and sub-class.
To enforce the concept of information hiding, it is recommend declaring all the variables as private and accessing those using getter and setter methods.
Classes can be related using association types. Multiple associations can be defined between the same classes. Besides, also unary or reflexive associations are possible where class engages in a relationship with itself. Associations can be further augmented with directions reading arrows which specify the direction of querying and navigating through it. In a unidirectional association, there is only one way of navigating as indicated by the arrow whereas in the binary association, both directions are possible and hence, there is no arrow.
The asterisk is introduced to denote a maximum cardinality of n.
A qualified association is a special type of association. More specifically, he uses a qualifier to further refine the association. The qualifier specifies 1 or more variable those are used as index key for navigating from the qualified class to the target class. It allows reducing the multiplicity of the association because of this extra key.
2 classes : team and player. They are connected using a 1:n relationship type since a team can have 0:N player and a player is always related to exactly one team. This can be represented using a qualified association by including the position variable as the index key or qualifier. A team at a given position has 0 to N player and a player always belongs to one team.
Qualified associations can be used to represent weak entity types.
Similar to the EER model, the UML model also allows to model specialization or generalization relationships.
We start from our earlier example with artists who can be singers and actors. The hollow triangle represents a specialization in UML. The specialization characteristics such as total, partial, disjoint and overlap can be added next to the triangle. Besides, it is important to mention that UML also supports multiple inheritances.
Two types of aggregations are possible in UML :
Shared aggregation: the part object can simultaneously belong to the multiple composite objects. In other words, the maximum multiplicity at composite side is undetermined. The part object can also occur without belonging to a composite object. The shared aggregation does represent a rather loose coupling between both classes.
The shared aggregation is indicated by a hollow diamond. Shared aggregation between company and consultant. A consultant can work for many companies. When a company is removed, any consultant that worked for it remains in the database.
Composite aggregation: the part object can only belong to one composite. The maximum multiplicity at composite side is 1 and the part object will be automatically removed when the composite object is removed.
The composite aggregation is indicated by a filled diamond. Composite aggregation between bank and account.
When a bank is removed, all connected account objects disappear as well.
UML offers various advanced modeling concepts which allow furthering a semantic store data model. The changeability property specifies the type of operations which are allowed on either variable values or links.
· Default: allows any type of edit.
· {addOnly}: only allows additional values or links to be added. So no deletions. Ex: for a purchase order, can only be added and not removed for a given supplier.
· {Frozen}: allows no further changes once the value or link is established. Once a value has been assigned, it can no longer change.
The object constraints language or OCL which is also part of the UML standard, allows to specify various types of constraints. The OCL constraints are defined in a declarative way. They specified what should be true but not how this should be accomplished. In other words, no control flow is provided. They can be used for various purposes: specify invariants for classes specify pre- and post- conditions for methods, used as a navigation language, define constraints on operations.
A class invariant is a constraint which holds for all objects of a class. Ex: constraint specifying that a Supplier status should be bigger than 100.
Pre and post-conditions on methods must be true when a method either begins or ends. Ex: before the method withdraw has been executed, the balance must be positive. After it has been executed, the balance must still be positive.
OCL also allows defining more complex constraints. It is a powerful language which allows adding a lot of semantics to the model.
Dependency is using relationship that states that a change in the specification of a thing may affect another thing that uses it. It is denoted by a dashed line in the UML diagram. Ex: when an object of one class uses an object of another class in its methods but the referred object is not stored in any variables.
Here, we have 2 classes: EMPLOYEE and COURSE. An employee can follow courses as part of a company education program. The employee class includes a method to course to see if an employee follows a particular course. Hence, an employee object makes use of course object in one of its methods. This explains the dependency between both classes.
