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”)