HackMD
UML Course.
Table of Contents:
Class Diagrams:
In a class diagram, both classes and their relationships are represented. Classes represent types of objects that share common characteristics and behaviors. These characteristics and behaviors are defined by attributes and methods, respectively. Associations in the class diagram represent the relationships between classes, such as composition, aggregation, and inheritance. In summary, a class diagram is an important tool for modeling the structure of an object-oriented system and the relationships between its components.
| Student |
|---|
Words are not separated by anything, only the first letter of each word is capitalized.
| UniversityStudent. |
|---|
Objects are specific representations of a class that have acquired values. Using an analogy of blueprints and houses, we can say that just as a blueprint can be used to construct multiple houses, a class can be used to create several objects. However, just as a blueprint is not a house, a class is not an object in itself. In object-oriented programming, objects are represented as variables that contain data and methods that enable them to perform specific actions.
| Student |
|---|
| - name: String |
| - DNI: Int |
| - birthdate: Date |
| g1: Student |
|---|
| name: "Pablo" |
| DNI: 23341223434343 |
| birthdate: 1/5/2000 |
A notation convention is used to differentiate between different types of data in a system. The "-" sign is used to denote data that is private, meaning it can only be accessed within the object. On the other hand, the "+" sign indicates that the data is public and can be accessed from anywhere in the program. Additionally, the "#" symbol is used to indicate that the data can only be viewed by the subclasses of the object in question. This notation helps maintain clarity and organization in system and object design.
Role
In an association, objects are placed at the ends and are explicitly assigned a role that clearly describes their function in the relationship.
Navigability in object-oriented programming refers to how instances of a class can access each other. To indicate the direction of navigability, an arrow is used to indicate the allowed direction. Instances that are at the end of the arrow can be accessed by instances at the start of the arrow, but not vice versa. In cases where the direction of the arrow is not specified, it is understood that the navigability is bidirectional, meaning that the instances can access each other.
Let's suppose we have two classes, Room and Conference, in which a course can be taught in one or several rooms. This relationship between the two classes is known as cardinality. In the abstraction we are working with, it makes sense to be able to access the rooms from instances of a conference, but not the other way around, as it would be less practical. Therefore, a unidirectional navigability has been established in the direction of the Room class.
Inheritance
Let's imagine that we have two classes: "Animal" and "Dog". The class "Animal" could have the following attributes and methods:
- Attributes: age, name, species
- Methods: eat(), sleep(), move()
The class "Dog" would inherit the attributes and methods from the "Animal" class, but it would also have its own specific attributes and methods, such as:
- Additional attributes: breed, color, size
- Additional methods: bark(), fetch ball(), bite()
We could represent this inheritance in UML through a class diagram, where "Dog" would be a subclass of "Animal". The graphical representation would be similar to this:
In this example, we can see that the class Dog inherits the attributes and methods from the class Animal and it also has its specific attributes and methods. This way, we can reuse the code from the Animal class and avoid having to rewrite the attributes and methods that already exist in the Animal class.
In general terms, in class inheritance, the following is true: firstly, subclasses acquire the attributes, associations, and methods of the superclass, which means that instances of the subclasses contain both their attributes and those of the superclass. Secondly, subclasses can add new attributes, associations, and methods, which translates into a specialization of the superclass by the subclass. Thirdly, subclasses have the ability to redefine or implement methods and attributes of the superclass within the subclass.
Abstract classes have as their main purpose to establish a hierarchical structure of concepts, allowing a systematic classification of them. For example, animals can be organized into categories such as vertebrates and invertebrates, or vehicles can be grouped by type, such as cars, airplanes, and boats. Similarly, geometric figures can be classified into ellipses, rectangles, and triangles, among other possible categories.
Associations
Composite associations denote aggregation relationships, where one class is the whole and the other class represents one of the parts of that whole. In other words, aggregation is an association between two classes where one contains parts that make up the whole. For example, a car has an engine, four wheels, and an electronic system, while a book has a preface, several chapters, and a bibliography.
When an association is formed between objects, a complete connection is established between all instances that represent the role of the class. In this context, the creation and deletion of such instances depends entirely on the objects to which they belong. That is, interdependence is created between the objects that make up the association, and their manipulation must be carefully managed to avoid problems in the system.
Cardinality
-
Our simplest cardinality is 1 to 1.
-
The next cardinality is 0 to 1.
-
The many cardinality is expressed with *.
Shared Associations
Shared associations are a type of relationship that refers to aggregation. Aggregation establishes a connection between two classes, one of which represents the whole, while the other represents a part of the whole, in other words, the parts that make up a whole. Compared to composite associations, shared associations in the UML specification have fewer limitations and restrictions.
Dependency Relationship
The dependency relationship between two classes occurs when one of them needs the other for its correct implementation, either semantically or structurally. This type of relationship is also known as client-provider, since one of the classes acts as a provider and supplies the necessary elements for the other class, the client, to carry out its task properly. Dependencies between classes are a fundamental part of system modeling, as they allow defining the interaction and flow of data between different components.
In this example, class A depends on class B for its implementation, which means that class A uses some element or method from class B. The dotted arrow indicates the direction of the dependency, which goes from the dependent class (Class A) to the providing class (Class B). This means that if class B changes, it can affect the implementation of class A.
Practical Case of the Foundation:
A complex class diagram is created based on the acquired knowledge, regarding the Foundation and social service.
In this case, we can see that there is an association between the Alumno class and the Servicio Social class, in which a Servicio Social can have 0 or several Alumnos, but an Alumno can only be in one Servicio Social. As for the RegistroAlumno and DecentralizedFoundation classes, there is a shared open association since, although the Alumno belongs to the Fundacion, they may not necessarily be solely part of it, as they may be pursuing their career while doing their service there. Additionally, the association is that Decentralized can have 0 or several Alumnos, and the Alumno can be in Decentralized entirely or can be, as previously mentioned, pursuing their career or other activity while being part of the Fundacion. We can see that there is an inheritance between the Revisores and the Alumno since the Revisores teach the courses or activities to the Alumnos. However, there is also an association between Revisores and DecentralizedFoundation since it provides the resources for them to carry out their functions, although it has its own properties such as the Revisor's name and position.
As mentioned, the association between Revisores and Decentralized is bidirectional since the Revisor may belong to Decentralized in this case, but Decentralized can have one or more Revisores. As for the association between Decentralized and Programa, we can see that it is a directional association since Decentralized feeds on Programa to have the material for the Revisores to teach the courses or activities. We can also see that it has a type of knowledge and has a relationship with an enumeration called Conocimientos, depending on the type of knowledge required. Depending on the task to be performed, whether it is an activity or training, we can see that it has a relationship with another enumeration. We can note that in this case, the relationship is composed since Programa depends entirely on Decentralized, and if Decentralized did not exist, Programa could not exist.
Next, the association between Servicio Social and Decentralized is a shared association since, although Decentralized is part of the whole Servicio Social, it is not necessarily entirely theirs since Decentralized may be looking for other social services and not just this one. Also, Servicio Social does not only provide social services at Decentralized but can provide them at other institutions or foundations.
Finally, we can see the inheritance of Decentralized with Comprobante and Plazo, which inherit the abstract of the superclass Decentralized to obtain both the validation of the social service and that the Plazo for the Fundacion was fulfilled.
LICENSE
References
Coursera, UML en español, Universidad de los Andes, UML course in Spanish
Author and Reviewer.
Work developed in collaboration with the Decentralized Climate Foundation.
Autor:
Revisor:
