The document discusses different types of UML diagrams used for object-oriented analysis and design. It focuses on class diagrams and describes the notation used to represent classes, attributes, operations, relationships between classes like association, aggregation, composition, generalization, and realization. Key class diagram elements like class visibility, parameter directionality, and multiplicity are also explained through examples.
1 of 39
Downloaded 49 times
More Related Content
IT1206- Object Oriented Analysis and Design- L10
1. Object Oriented
Analysis and
Design L10
IT1206
IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
1
Sameera
Gunathilaka
Lead Software
Engineer
ERP Technical
Consultant
2. Types of UML
Diagrams
(Modelling Types)
Structural UML
diagrams
Package diagram
Object diagram
Component diagram
Composite structure
diagram
Deployment diagram
Behavioural UML
diagrams
Activity diagram
Sequence diagram
Use case diagram
State diagram
Communication diagram
Interaction overview
diagram
Timing diagram
3. Recap: What is a Class?
A Class is a blueprint(template) for an
object
We use classes to create objects
Classes describe the type of objects,
while objects are usable instances of
classes
Objects have states and behaviours
IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD 3
4. Example
A dog has - color,
name, breed as well
as behaviors -
wagging, barking,
eating. An object is
an instance of a class.
IT1206 - Institute of Technology, University of Moratuwa Sameera Gunathilaka -
OOAD 4
5. UML Class
Notation
Class encapsulates: attributes (state) and operations (behaviour)
attribute has a type
operation has a signature
IT1206 - Institute of Technology, University of Moratuwa Sameera Gunathilaka -
OOAD 5
7. Class Visibility
+ denotes public attributes or operations
- denotes private attributes or operations
# denotes protected attributes or operations
IT1206 - Institute of Technology, University of Moratuwa Sameera Gunathilaka -
OOAD 7
8. Parameter
Directionality
Direction: OUT or INOUT or IN
It specifies its direction with respect to the caller
IT1206 - Institute of Technology, University of Moratuwa Sameera Gunathilaka -
OOAD 8
12. Strength of
Relationships Most weakest relationship: Dependency
Most Strongest relationship: Inheritance
12
IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
13. Dependency
13
A uses B
Changing B will affect the A
IT1206 - Institute of Technology, University of Moratuwa Sameera Gunathilaka - OOAD
14. Dependency
example
Cart class depend on the Product class
Cart uses Products
Changing the Product will affect the Cart
Cart class depends on the Product class
IT1206 - Institute of Technology, University of Moratuwa Sameera Gunathilaka -
OOAD 14
15. Associations
15
Connects one instance of a class
with an instance of another class
Stronger relationship than
Dependency
An Employee works for a Company
16. Direction of Association
Unary Association vs Binary Association
IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
16
17. Unary Associations
Class A knows Class B
Class B knows nothing about Class A
IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
17
18. Unary Association
IT1206 - Institute of Technology, University of Moratuwa Sameera Gunathilaka -
OOAD 18
19. IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
19
20. Binary Associations
Class C knows about Class D
Class D knows about Class C
No arrow
IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
20
21. IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
21
23. IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
23
24. Reflective Association
Objects in the same class can be associated
IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
24
25. Association Class
This places the responsibility for maintaining information pertaining to
the association with the Ownership class.
IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
25
28. Association Class -Activity
Each Student can take multiple units
A unit can be taken by many students
Students who follow units can take exam multiple times if they fail
We need to manage their marks for each attempt in the system
IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
28
30. Aggregation - Association
Whole-part relationship( Part of Relationship)
Removing Class B will not affect to the Class A
IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
30
31. IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
31
32. IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
32
33. Composition - Association
part depends on the whole
Parts are destroyed when the whole is destroyed
IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
33
34. IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
34
35. IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
35
36. Inheritance (or
Generalization)
Represents an "is-a"
relationship.
An abstract class name is
shown in italics.
SubClass1 and SubClass2
are specializations of
SuperClass.
IT1206 - Institute of Technology, University of Moratuwa Sameera Gunathilaka -
OOAD 36
37. Realization
Source class support all the
operations of the target
element
Relationship between the
interface and the
implementing class
Realization is a relationship
between the blueprint class
and the object containing its
respective implementation
level details.
IT1206 - Institute of Technology, University of Moratuwa Sameera Gunathilaka -
OOAD 37
38. IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
38
39. Thank you
IT1206 - Institute of Technology, University of Moratuwa
Sameera Gunathilaka - OOAD
39
Editor's Notes
#3: We are learning mainly those highlighted diagrams
#10: Conceptual: represents the concepts in the domain
Specification: focus is on the interfaces of Abstract Data Type (ADTs) in the software
Implementation: describes how classes will implement their interfaces
#15: Cart class depends on the Product class correct
Product class has a dependency on Cart - wrong
#17: One way or two way
One directional vs Bi-directional
#21: Customer can own accounts
Account is belonged to a Customer
#24: Hose has one Kitchen, one or many bathroom, one or many bedrooms
Kitechn, Bath,Bed rooms are rooms
House has a one mail box
House can have a mortgage one time or not
#25: Company has Employees
A single manager responsible for up to 10 workers
#31: Belt is a part of me now, but belt can exist without me
Watch is a part of me, but it exists without me
#33: Hose has one Kitchen, one or many bathroom, one or many bedrooms
Kitechn, Bath,Bed rooms are rooms
House has a one mail box
House can have a mortgage one time or not
#34: Class B live or die with Class B
Hand is a part of me, but hand cannot exist without me. But I can exist without hand
#35: Department is a part of Company.
Department cannot exist without Company.
But Company can exist without department.
#36: Hose has one Kitchen, one or many bathroom, one or many bedrooms
Kitechn, Bath,Bed rooms are rooms
House has a one mail box
House can have a mortgage one time or not