konsep oop diagram uml - herman · pdf filekonsep oop diagram uml ... •the unified...

PEMROGRAMAN LANJUT

Program Teknologi Informasi & Ilmu Komputer, Universitas Brawijaya

KONSEP OOPDIAGRAM UML

Dr. Eng. Herman Tolle

Sistem Informasi PTIIK UBSemester Genap 2014/2015

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 PemrogramanBerorientasi Objek

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 )

– Inheritance (“is-a”); (relasi adalah)

Relasi antar Kelas

1. Asosiasi

– Multiplicity

– Directed Assosiation

– Reflexive Association

2. Aggregasi

– Komposisi

3. Inheritance / Generalisasi

4. Realization

Association

• Association A---->BComposition A-----<filled>BAggregation A-----<>B

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; }

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{ private String type; }

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

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.

Relasi

•Relasi 1 to 1 (one to one): satu objek A hanyamemiliki pasangan 1 objek B

•Relasi 1 to N atau 1.. * (one to many) : satu objekA 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 samasekali

•Relasi M to M atau N.. N (many to many): objek A dan objek B bisa muncul lebih dari 1x

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

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

• 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

Class Diagram

Contoh Class Diagram

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

NameValue

0..*

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

NameValue

0..*

PassFail Student

Print Transcript( ) function override

PassFail Student

Print Transcript( )Print Report Card(

Student

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

0..*

Score

NameValue

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

Re-organization of OO Abstractions

• Data dependent behavior handled by derived classes

• New functionality handled by new associated classes ("wrappers", "adapters", "views")

0..*

Score

NameValue

Student

Register( )Submit Score( )

0..*

0..1Transcript

Print( )

0..1

PassFail Student

Determine Grade( )

0..*

Score

NameValue

0..1

Transcript

Print( ) Student

Register( )Submit Score( )Determine Grade( )

0..*

0..1

PassFail Student

Determine Grade( )

0..*

Score

NameValue

0..1

Transcript

Print( )

0..1Report Card

Print( )

Student

Register( )Submit Score( )Determine Grade( )

0..*

0..1

0..1

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 James Rumbaugh at Rational Software in the 1990s

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

24Fig. 8.24 | Class diagram with visibility markers.

Case Study: ATM System

25

Fig. 8.25 | Class diagram with navigability arrows.

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

• Use the return type void if no return type has been specified

27

Fig. 8.24 | Class diagram with visibility markers.

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.java

Class for Withdrawal

Empty no-argument

constructor

29


30

Outline

•



3 {

4 // attributes

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

6 private double amount; // amount to withdraw

7



10 {



withdrawal.java

Declare instance

variables

31

Fig. 8.25 | Class diagram with navigability arrows.

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.java

Declare references to other

objects

33


34

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 {


18

19 // operations

20 public void execute()

21 {

22 } // end method execute


withdrawal.java

Declare shell of a method with

return type void

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

Tugas 3

Studi Kasus: Pegawai & Gaji Harian

• Pengembangan dari tugas sebelumnya, dengan menambahkan atribut baru (birthday , hiredate, salary)

• Rule baru:

1. Jika masa kerja > 3 bulan maka Gaji Pokok lebih besar z% atau x rupiah

2. Jika umur > y tahun maka dapat Tunjangan Lain-lain sebesar w rupiah

Laporan

• Soal (Kasus, Rules, Konstanta)

• Diagram Class beserta relasinya

• Buat implementasi class

• Buat program implementasi class (min 3 pegawai)

• Screenshot

• Deadline: 21 April 2014, Dikirim ke email dosen.

• Dicetak dan dikumpulkan tgl 22 April 2014

Modular Programming

• Memisahkan data dengan proses

• Contoh:

• menggunakan konstanta

– final static int gajiPokok = 5000;

– final static int minKerja = 3;

– final static double gajiNaik = 0.2;

• Rules:

– If (lamaKerja > minKerja) gajiPokokPegawai = gajiPokok * (1 + gajiNaik);

konsep oop diagram uml - herman · pdf filekonsep oop diagram uml ... •the unified...

Documents