uml/class-diagram.md

@@ -7,8 +7,10 @@ The **class diagram** is used to describe central classes within a software syst
 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).
 
 # What is a Class?
 Consider a class as a blueprint for creating an object during runtime of an application.
@@ -22,4 +24,18 @@ The following figure shows an example UML class diagram, which reflects the requ
 ![Class Diagram](https://git.informatik.uni-kiel.de/ag-se/teaching-public/wikis/uml-sources/img/class-diagram.svg)
 
 ### 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. 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
+  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
+  1. Right click white space in class diagram editor to open popup menu
+  2. Presentation Options
+  3. Association Display Options
+  4. Show Direction
\ No newline at end of file