Software Engineering - 2018 SE18_Lec 08_UML Class Diagram Faculty of Engineering - Helwan University

1. 1
‫ر‬َ‫ـد‬ْ‫ق‬‫ِـ‬‫ن‬،،،‫لما‬‫اننا‬ ‫نصدق‬ْْ‫ق‬ِ‫ن‬‫ر‬َ‫د‬
Faculty of Engineering - Helwan University

2. 2
 An object is a run-time entity that occupies memory at some
specific point in time
 Has behavior (methods)
 Has data (attributes)
 A class is a design-time specification that defines the
structure and behavior for a set of objects to be created at
run-time.
 Specifies behavior implementation (methods)
 Specifies data (attributes)
 An interface is a design time concept that specifies the
messages a class receives (“provided”) or uses (“required”)
 Specifies behavior only (operation implementation)
 May have virtual attributes (no implementation)
 May have a protocol state machine (no actions)

3. 3
 The class diagram is a static model that shows the
classes and the relationships among classes in the
system.
 Class diagrams illustrates classes, interfaces, and their
associations. They are used for static object modeling.
 A Class diagram gives an overview of a system by
showing its classes and the relationships among them.
 Class diagrams display what interacts but not what
happens when they do interact

4. 4
 The main building block of a class diagram is the class,
which stores and manages information in the system.
 A blueprint that an object made from.
 The class contains two major parts:
• Attributes “data members”.
• Operations “method members”.

5. 5

6. 6

7. 7

8. 8

9. 9
No arrows; info can
flow in both directions
Aggregation – Order class
contains OrderDetail classes.
Could be composition?

10. 10
 Class diagrams are great for:
 discovering related data and attributes
 getting a quick picture of the important entities in a system
 seeing whether you have too few/many classes
 seeing whether the relationships between objects are too
complex, too many in number, simple enough, etc.
 spotting dependencies between one class/object and another
 Not so great for:
 discovering algorithmic (not data-driven) behavior
 finding the flow of steps for objects to solve a given problem
 understanding the app's overall control flow (event-driven? web-
based? sequential? etc.)

11. 11

12. 12
 Draw a class diagram for a information modeling system
for a school.
 School has one or more Departments.
 Department offers one or more Subjects.
 A particular subject will be offered by only one
department.
 Department has instructors and instructors can work
for one or more departments.
 Student can enrol in upto 5 subjects in a School.
 Instructors can teach upto 3 subjects.
 The same subject can be taught by different
instructors.
 Students can be enrolled in more than one school.

13. 13
 School has one or more Departments.
School Department
has1 1..*
 Department offers one or more Subjects.
 A particular subject will be offered by only one department.
Department Subject
offers1 1..*

14. 14
 Department has Instructors and instructors can work
for one or more departments.
assigned to1..*
Instructor Department
1..*
 Student can enrol in upto 5 Subjects.
Student Subject
takes* 0..5

15. 15
 Instructors can teach up to 3 subjects.
 The same subject can be taught by different
instructors.
Instructor Subjects
teaches
1..*
1..3

16. 16
 Students can be enrolled in more than one school.
Student School
member
*
1..*

17. 17
School Department
Student Subject Instructor
1…*
*
member
* 1..5
attends
1..3 1..*
teaches
1..*
1
1 1..*
has
1..*
1..*
assignedTo
offeres

18. 18
 Object Diagram shows the relationship between objects.
 Unlike classes objects have a state.

19. 19
c1: Company
d2: Departmentd1: Department
name=“Sales” name=”CSSE”
p1: Persont
name=“Rao”
p2: Person
name=“Raj”
manager employee
c1: Company
name=“UniMelb”

20. 20

21. 21

22. 22

23. 23

24. 24

25. 25

26. 26

27. 27

28. 28

29. 29

30. 30