KONSEP OOP DIAGRAM UML

(1)

PEMROGRAMAN LANJUT

Program Teknologi Informasi & Ilmu Komputer, Universitas Brawijaya

KONSEP OOP

DIAGRAM UML

Dr. Eng. Herman Tolle

Sistem Informasi PTIIK UB Semester Genap 2014/2015

(2)

Materi Pemrograman Lanjut

1. Review Pemrograman Dasar

2. Konsep OOP,

3. Class dan object,

4. UML Class Diagram

5. Fungsi overloading dan konstruktor,

6. Enkapsulasi,

7. Inheritance/pewarisan,

8. Polymorphism

Pemrograman

(3)

Relasi Antar Kelas

• Suatu class dapat dibangun dari ataupun

memiliki keterkaitan dengan kelas yang lain

• Secara umum relasi antar class adalah:

– Depedensi

(“uses-a”); (relasi menggunakan)

– Agregasi

(“has-a”); (relasi mempunyai )

(4)

Relasi antar Kelas

1. Asosiasi

– Multiplicity

– Directed Assosiation

– Reflexive Association

2. Aggregasi

– Komposisi

3. Inheritance / Generalisasi

4. Realization

(5)

Association

• Association A---->B

Composition A---<filled>B Aggregation A---<>B

(6)

Aggregation

• In transportation systems Car has many Passenger, relationship between them is Aggregation.

public class Car

{

private Person[] Penumpang; }

public class Person

{

private String name; }

(7)

Composition

• Composition : Since Engine is part-of Car, relationship between them is Composition.

public class Car

{

private final Engine engine;

public Car() {

engine = new Engine(); }

}

class Engine

(8)

Composition vs Aggregation

• Jika suatu objek adalah bagian dari (part-of) objek lain,

misalnya Engine is part of Car, maka asosiasi atau relationship diantara keduanya disebut Composition (Komposisi).

• Jika suatu objek memiliki objek lain maka ini disebut

Aggregation (Agregasi).

• Aggregation (many-to-one relationships) • Whole – Part ( Composition)

• Containership • Collection • Group

(9)

Composition

• Komposisi adalah bentuk khusus dari Agregasi (disebut juga “death

relationship”). Child Object (Objek yang digunakan dalam objek

induknya) tidak memiliki lifecycle. Jika objek induknya dihapus maka objek anaknya juga akan terhapus.

• Misalnya:

• House ---<filled> Rooms

• House can contain multiple rooms there is no independent life of room and any room can not belong to two different houses. If we delete the house - room will automatically be deleted.

• Questions ---<filled> options. Single questions can have multiple options and option can not belong to multiple questions. If we delete questions options will automatically be deleted.

(10)

(11)

Relasi

• Relasi 1 to 1 (one to one): satu objek A hanya

memiliki pasangan 1 objek B

**• Relasi 1 to N atau 1.. * (one to many) : satu objek**

A bisa memiliki minimal 1 atau banyak objek B

**• Relasi 0 to N atau 0..* (zero to many): satu objek A**

bisa memiliki banyak objek B atau tidak ada sama

sekali

• Relasi M to M atau N.. N (many to many): objek A

dan objek B bisa muncul lebih dari 1x

(12)

(13)

Aggregation Hierarchy

• "weak has-A" - where there is more of a peer-to-peer

relationship between abstractions (association)

– ex: Instructor has students, Students have instructor

Community Schools Businesses Residents School Faculty Students Administrators Classrooms Classroom Tables Chairs Students Instructor

(14)

Inheritance Hierarchy

• an "is-A" relationship

• Inheritance

– for type - a re-use of common interface

– for class - a re-use of common interface and

implementation

Person · Name Student · Name · Attendence · Current Grade

(15)

15

• Visibility

– Attributes normally should be private, methods invoked by clients should be public

– Visibility markers in UML

• A plus sign (+) indicates public visibility • A minus sign (-) indicates private visibility • A sharp sign (#) indicates protected visibility

• Navigability

– Navigability arrows indicate in which direction an association can be traversed

– Bidirectional navigability

• Associations with navigability arrows at both ends or no navigability arrows at all can be traversed in either direction

(16)

(17)

Comparison of

Functional vs. OO Views

Register Student Print Transcript Submit Grade Students Students Grades Student/Grades Student Register( ) Submit Score( ) Print Transcript( ) 0..* Score Name Value 0..*

(18)

Addition of a New Student Type

• Changes in data types cause significant impact to functional approaches

• OO approaches allow new object types to re-define functionality Register Student Print Transcript Submit Grade Students Students/

Pass Fail Students Grades/PF Student/Grades/PF Impact Areas Student Register( ) Submit Score( ) Print Transcript( ) 0..* Score Name Value 0..* PassFail Student

(19)

PassFail Student Print Transcript( ) Print Report Card( Student

Register( ) Submit Score( ) Print Transcript( ) Print Report Card(

0..*

Score Name Value 0..*

Addition of New Report Type

• Changes in functionality based on stable data causes significant impact across objects

• Functional approaches allow new functions to augment functionality Print Transcript Submit Grade Students Students Grades Student/Grades/PF Register Student Print Report Card Student/Grades/PF Impact Areas

(20)

Re-organization of OO

Abstractions

• Data dependent behavior handled by derived classes • New functionality handled by new associated classes

("wrappers", "adapters", "views")

0..* Score Name Value Student Register( ) Submit Score( ) 0..* 0..1 Transcript Print( ) 0..1 PassFail Student Determine Grade( ) 0..* Score Name Value 0..1 Transcript Print( ) Student Register( ) Submit Score( ) Determine Grade( ) 0..* 0..1 PassFail Student Determine Grade( ) 0..* Score Name Value 0..1 Transcript Print( ) 0..1 Report Card Print( ) Student Register( ) Submit Score( ) Determine Grade( ) 0..* 0..1 0..1

(21)

Diagram UML

• The Unified Modeling Language (UML) is a

general-purpose modeling language in the field of

software engineering.

• Provides a set of graphic notation techniques to

create visual models of object-oriented

software-intensive systems.

• Developed by Grady Booch, Ivar Jacobson and

(22)

SYSTEM MODELS (in UML notation)

• Functional Model – use case diagrams (synthesized from ‘scenarios’ – from phenomena and concepts)

• Object Model – class diagrams (representing object structures as objects, attributes, associations, and operations)

• Dynamic Model – sequence diagrams, statechart diagrams

and activity diagrams (describe the internal behavior or finite state machine of the system). SD are inter-object messaging and interactions, while SC-diagrams depict the finite state machine description of an object’s behavior

(23)

(24)

24 Fig. 8.24 | Class diagram with visibility markers.

(25)

25

(26)

26

Starting to Program the Classes of the ATM System

• Implementing the ATM system from its UML design

(for each class)

– Declare a public class with the name in the first

compartment and an empty no-argument constructor – Declare instance variables based on attributes in the

second compartment

– Declare references to other objects based on associations described in the class diagram

– Declare the shells of the methods based on the operations in the third compartment

(27)

27

(28)

28

Outline

•

1 // Class Withdrawal represents an ATM withdrawal transaction

2 public class Withdrawal

3 {

4 // no-argument constructor

5 public Withdrawal()

6 {

7 } // end no-argument Withdrawal constructor

8 } // end class Withdrawal

withdrawal.ja va Class for Withdrawal Empty no-argument constructor

(29)

29

(30)

30

Outline

•

3 {

4 // attributes

5 private int accountNumber; // account to withdraw funds from

6 private double amount; // amount to withdraw

7

10 {

withdrawal.ja va

Declare instance variables

(31)

31

(32)

32

Outline

•

3 {

4 // attributes

7

8 // references to associated objects

9 private Screen screen; // ATM’s screen

10 private Keypad keypad; // ATM’s keypad

11 private CashDispenser cashDispenser; // ATM’s cash dispenser

12 private BankDatabase bankDatabase; // account info database

13

16 {

withdrawal.ja va

Declare references to other objects

(33)

33

(34)

34

Outline

•

1 // Class Withdrawal represents an ATM withdrawal transaction

3 {

4 // attributes

7

8 // references to associated objects

9 private Screen screen; // ATM’s screen

10 private Keypad keypad; // ATM’s keypad

11 private CashDispenser cashDispenser; // ATM’s cash dispenser

12 private BankDatabase bankDatabase; // account info database

13

14 // no-argument constructor

16 {

18

19 // operations

20 public void execute()

21 {

22 } // end method execute

withdrawal.ja va

Declare shell of a method with return type void

(35)

(36)

Studi Kasus: Sistem Penggajian Pegawai

Employee -fullName: string; - birthDate: date; -hireDate: date; -salary: Salary;

-numberOfEmployee: int static +employee(name, birth) +getName(): string +getBirthdate(); date -day: int; - month: int; - year int; + date(d,m,y); + setDate(d, m, y); Salary - gajiPokok + hitungGaji()

(37)