|
|
|
**Sources:** http://www.omg.org/spec/UML/2.5 (Starting at PDF page 192)
|
|
|
|
|
|
|
|
# Usage Scenarios
|
|
|
|
|
|
|
|
The **class diagram** is used to describe central classes within a software system (or at least a part of it) and their relationship among each other. This kind of diagram can be greatly used to get a detailed overview of employed objects and their relationships within the overall system.
|
|
|
|
For example, you can use it in the early design phase of a new software system to model the essential classes, attributes, and their relations.
|
|
|
|
|
|
|
|
# Obligations for the lectures and the final exam in "Softwaretechnik" (Tips for Modeling)
|
|
|
|
* When creating a **class diagram**, remember that it must contain all necessary information (attributes, methods, visibility, relationships). Otherwise a class diagram is useless and can be thrown away.
|
|
|
|
* Especially for relationships (associations) it is important to specify the cardinality (e.g., 1, 0..\*, 1..\*) and the name of it (e.g., "provides", "contains", "has")
|
|
|
|
|
|
|
|
- When creating a **class diagram**, remember that it must contain all necessary information (attributes, methods, visibility, relationships). Otherwise a class diagram is useless and can be thrown away.
|
|
|
|
- Especially for relationships (associations) it is important to specify the cardinality (e.g., 1, 0..\*, 1..\*) and the name of it (e.g., "provides", "contains", "has")
|
|
|
|
An example class diagram is shown in [Example Class Diagram](#an-example-class-diagram-for-the-given-scenario).
|
|
|
|
* The navigability for the association determines the visibility of classes among each other. Thus, an instance of a class may interact with other instances, depending on the notation (cross=no or arrow=yes).
|
|
|
|
- The navigability for the association determines the visibility of classes among each other. Thus, an instance of a class may interact with other instances, depending on the notation (cross=no or arrow=yes).
|
|
|
|
|
|
|
|
# What is a Class?
|
|
|
|
|
|
|
|
Consider a class as a blueprint for creating an object during runtime of an application.
|
|
|
|
|
|
|
|
# Example Scenario
|
|
|
|
|
|
|
|
Assume that your customer wants you to develop a web application called "StudentData" which is similar to the StudiDB. This application must be accessible by students, lecturers, and administrators. All of these users must be able to register and to login. For this purpose, an external authentication service is used. Students can join lectures and view their exams taken so far. Furthermore, they are able to upload multiple attachments (e.g., external grades) simultaneously. Lecturers can assign grades to students and print reports with statistics about their lectures. Administrators can add users and lectures.
|
|
|
|
|
|
|
|
## An Example Class Diagram for the given Scenario
|
|
|
|
|
|
|
|
The following figure shows an example UML class diagram, which reflects the requirements mentioned in [Example Scenario](#example-scenario):
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Explanation
|
|
|
|
We model the most important classes in order to represent the central objects within our web application *StudentData*. We identify five classes, which are essential within our scenario (*Student*, *Lecturer*, *Administrator*, *Lecture*, and *Exam*). As the first three classes represent some kind of role within our software system, we model an abstract parent class *Person*, which contains attributes and methods, which every role needs and therefore inherits. Additionally the class *Person* implements the interface *Role*, in order to use the provided operations getUsername() and getPassword(). An *Administrator* creates user accounts and lectures. The related association shows an arrow on the *Student's* side, therefore indicating that instances of *Administrator* can interact with instances of *Students*. Note that the opposite direction is crossed, since an instance of *Student* must not know about the *Administrator*. A *Lecturer* can give Lectures and conducts Exams (at a specific date), alone or in collaboration with a second Lecturer, which he can perform via his same-named method. Furthermore, he is able to print reports. A *Student* gets examined and receives a grade for this exam. He is able to drink coffee, view his grades of completed exams, and isable to join lectures. Each *Exam* is assigned to a single student, there is no grade for a student group or anything similar. The most interesting part within our diagram is the relation / association between *Student* and *Lecture*. If we take a look on the cardinalities, we see that a Lecture needs at least five students to be held. (as represented by 5..\*), but a Student can visit as many Lectures he likes (0..\*).
|
|
|
|
|
|
|
|
We model the most important classes in order to represent the central objects within our web application _StudentData_. We identify five classes, which are essential within our scenario (_Student_, _Lecturer_, _Administrator_, _Lecture_, and _Exam_). As the first three classes represent some kind of role within our software system, we model an abstract parent class _Person_, which contains attributes and methods, which every role needs and therefore inherits. Additionally the class _Person_ implements the interface _Role_, in order to use the provided operations getUsername() and getPassword(). An _Administrator_ creates user accounts and lectures. The related association shows an arrow on the _Student's_ side, therefore indicating that instances of _Administrator_ can interact with instances of _Students_. Note that the opposite direction is crossed, since an instance of _Student_ must not know about the _Administrator_. A _Lecturer_ can give Lectures and conducts Exams (at a specific date), alone or in collaboration with a second Lecturer, which he can perform via his same-named method. Furthermore, he is able to print reports. A _Student_ gets examined and receives a grade for this exam. He is able to drink coffee, view his grades of completed exams, and isable to join lectures. Each _Exam_ is assigned to a single student, there is no grade for a student group or anything similar. The most interesting part within our diagram is the relation / association between _Student_ and _Lecture_. If we take a look on the cardinalities, we see that a Lecture needs at least five students to be held. (as represented by 5..\*), but a Student can visit as many Lectures he likes (0..\*).
|
|
|
|
|
|
|
|
# Visual Paradigm Settings
|
|
|
|
* Always show crosses and arrows (navigability) on associations
|
|
|
|
|
|
|
|
- Always show crosses and arrows (navigability) on associations
|
|
|
|
|
|
|
|
1. Right click white space in class diagram editor to open popup menu
|
|
|
|
2. Presentation Options
|
|
|
|
3. Association Display Options
|
|
|
|
4. Show Navigation Arrows
|
|
|
|
5. Show All Arrows and Crosses
|
|
|
|
|
|
|
|
* Always show direction (black arrows) on associations
|
|
|
|
- Always show direction (black arrows) on associations
|
|
|
|
1. Right click white space in class diagram editor to open popup menu
|
|
|
|
2. Presentation Options
|
|
|
|
3. Association Display Options
|
| ... | ... | |
