Download - COP 3503 FALL 2012 Shayan Javed Lecture 9
1 / 55
COP 3503 FALL 2012SHAYAN JAVED
LECTURE 9
Programming Fundamentals using Java
1
2 / 55
UML Diagrams
3 / 55
UML
Unified Modeling Language
4 / 55
UML
Unified Modeling Language Goal:
Common language for creating models of Object-Oriented software
5 / 55
UML
Unified Modeling Language Goal:
Common language for creating models of Object-Oriented software
Two aspects: Class Diagrams (Static design): Classes, Attributes,
Relationships
6 / 55
UML
Unified Modeling Language Goal:
Common language for creating models of Object-Oriented software
Two aspects: Class Diagrams (Static design): Classes, Attributes,
Relationships Dynamic design: Objects, messages, finite state
machines [Sequence/Activity/State Machine diagrams]
7 / 55
Class Diagrams
Depict classes within a model
8 / 55
Class Diagrams
Depict classes within a model Classes have:
Attributes (Properties/Member Variables)
9 / 55
Class Diagrams
Depict classes within a model Classes have:
Attributes (Properties/Member Variables) Operations (Functions/Methods)
10 / 55
Class Diagrams
Depict classes within a model Classes have:
Attributes (Properties/Member Variables) Operations (Functions/Methods) Relationships with other classes
11 / 55
Class Diagrams
Class
Properties
Methods()
12 / 55
Class Diagrams
GeometricObject
color : Stringname : Stringarea : double
GeometricObject()GeometricObject(String, String)get() : String/doubleset(..) : void
13 / 55
Class Diagrams
Properties
name : type
14 / 55
Class Diagrams
Properties
name : type
Ex.: area : double
15 / 55
Class Diagrams
Methods:
name(parameters) : return type
16 / 55
Class Diagrams
Methods:
name(parameters) : return type
Ex.: getArea( ) : double
17 / 55
Class Diagrams
Methods:
name(parameters) : return type
Ex.: getArea( ) : double setColor(color : String) : void
18 / 55
Class Diagrams
Properties/Methods can be public/private/protected/static
19 / 55
Class Diagrams
Properties/Methods can be public/private/protected/static
Need a way to indicate that somehow
20 / 55
Class Diagrams
Properties/Methods can be public/private/protected/static
Need a way to indicate that somehow Add a sign next to the property/method:
Public (+)
21 / 55
Class Diagrams
Properties/Methods can be public/private/protected/static
Need a way to indicate that somehow Add a sign next to the property/method:
Public (+) Private (-)
22 / 55
Class Diagrams
Properties/Methods can be public/private/protected/static
Need a way to indicate that somehow Add a sign next to the property/method:
Public (+) Private (-) Protected(#)
23 / 55
Class Diagrams
Properties/Methods can be public/private/protected/static
Need a way to indicate that somehow Add a sign next to the property/method:
Public (+) Private (-) Protected(#)
To indicate a static property/method, underline it
24 / 55
Class Diagrams
Final (constant) properties are declared by writing them in ALL_CAPS (Math.PI for example)
25 / 55
Class Diagrams
GeometricObject
# Color : String# name : String# area : double
+ GeometricObject()+ GeometricObject(String, String)+ get() : String/double+ set(..) : void
26 / 55
Class Diagrams
But GeometricObject is abstract
27 / 55
Class Diagrams
But GeometricObject is abstract
How do you differentiate between an abstract and non-abstract class/method?
28 / 55
Class Diagrams
But GeometricObject is abstract
How do you differentiate between an abstract and non-abstract class/method?
Italicize it
29 / 55
Class Diagrams
GeometricObject
# Color : String# name : String# area : double
+ GeometricObject()+ GeometricObject(String, String)+ get() : String/double+ set(..) : void+ getArea() : double
30 / 55
Class Diagrams
But can’t italicize when writing...
31 / 55
Class Diagrams
But can’t italicize when writing...
So to indicate abstract methods/classes on paper write {abstract} in brackets
32 / 55
Class Diagrams
GeometricObject {abstract}
# Color : String# name : String# area : double
+ GeometricObject()+ GeometricObject(String, String)+ get() : String/double+ set(..) : void+ getArea() : double {abstract}
33 / 55
Class Diagrams
Relationships between classes: Generalization (Inheritance = “is a”)
34 / 55
Class Diagrams
Relationships between classes: Generalization (Inheritance = “is a”) Aggregation (“has a”)
35 / 55
Class Diagrams
Relationships between classes: Generalization (Inheritance = “is a”) Aggregation (“has a”) Composition (“owns a”)
36 / 55
Class Diagrams
Generalization (Inheritance - “is a”):
Circle
- radius : double
+ Circle (...)+ getRadius( ) : double+ getArea( ) : double+ setRadius(radius : double) : void
37 / 55
Class Diagrams
Generalization (Inheritance - “is a”):
Circle
GeometricObject
38 / 55
Class Diagrams
Generalization (Inheritance - “is a”):
Used to indicate inheritance relationship
39 / 55
Class Diagrams
Generalization (Inheritance - “is a”):
Circle
GeometricObject
Rectangle
40 / 55
Class Diagrams
Aggregation (“has a”):
41 / 55
Class Diagrams
Aggregation (“has a”):
Class1 has a number of Class2
42 / 55
Class Diagrams
Aggregation (“has a”):
Class1 has a number of Class2
Course has a number of Students Course has many Students
43 / 55
Class Diagrams
Aggregation (“has a”):
public Course {Student[] students = new Student[capacity];
}
44 / 55
Class Diagrams
Aggregation (“has a”):
public Course {Student[] students = new Student[capacity];
}
Student Course0..capacitystudents
45 / 55
Class Diagrams
Aggregation (“has a”):
0...capacity = number of students in the Course
“students” = the variable
46 / 55
Class Diagrams
Aggregation (“has a”):
0...capacity = number of students in the Course
“students” = the variable
So aggregation indicated by empty diamond
47 / 55
Class Diagrams
Composition (“owns a”):
48 / 55
Class Diagrams
Composition (“owns a”):
Similar to Aggregation – but one class completely depends on the other.
49 / 55
Class Diagrams
Composition (“owns a”):
Similar to Aggregation – but one class completely depends on the other. Destroying one also destroys the dependent class
50 / 55
Class Diagrams
Composition (“owns a”):
Wheels Car4wheels
51 / 55
Class Diagrams
Composition (“owns a”):
Deleting a Car object also deletes the Wheel objects
Wheels Car4wheels
52 / 55
Class Diagrams
Composition (“owns a”):
Aggregation (“has a”):
53 / 55
Class Diagrams
Interfaces: Need to show interfaces being implemented
54 / 55
Class Diagrams
Interfaces:
Circle
<<interface>>Comparable
+ compareTo (Object) : int
r
55 / 55
Summary
UML Diagrams = used for creating models of Object-Oriented Software
Class diagrams = Depict classes Properties Methods Relationships
Relationships: Generalization (Inheritance = “is a”) Aggregation (“has a”) Composition (“owns a”)