... | @@ -20,4 +20,4 @@ The following figure shows an example UML class diagram, which reflects the requ |
... | @@ -20,4 +20,4 @@ The following figure shows an example UML class diagram, which reflects the requ |
|
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. 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..\*). |