sisteminformasifilkom ub semester …€¢aggregation (many-to-one relationships) •whole –part...

PEMROGRAMAN LANJUT

FakultasIlmuKomputer,UniversitasBrawijaya

KONSEP OOPDIAGRAM UML

Dr.Eng.HermanTolle

Sistem Informasi FILKOM UBSemester Genap 2016/2017

Materi Pemrograman Lanjut

1. Review Pemrograman Dasar2. Konsep OOP, 3. Class dan object, 4. UML Class Diagram5. Fungsi overloading dan konstruktor,6. Enkapsulasi, 7. Inheritance/pewarisan, 8. Polymorphism Pemrograman

Berorientasi 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 / Generalisasi4. Realization

Association

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

Aggregation

• IntransportationsystemsCar has manyPassenger,relationshipbetweenthemisAggregation.

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

CompositionvsAggregation

• Jikasuatuobjekadalahbagiandari(part-of)objeklain,misalnyaEngineispartofCar,makaasosiasiataurelationshipdiantarakeduanyadisebutComposition (Komposisi).

• Jikasuatuobjekmemiliki objeklainmakainidisebutAggregation(Agregasi).

• Aggregation(many-to-onerelationships)• Whole– Part(à Composition)• Containership• Collection• Group

Composition

• KomposisiadalahbentukkhususdariAgregasi(disebutjuga“deathrelationship”).ChildObject(Objekyangdigunakandalamobjekinduknya)tidakmemilikilifecycle.Jikaobjekinduknyadihapusmakaobjekanaknyajugaakanterhapus.

• Misalnya:• House -----<filled> Rooms• Housecancontainmultipleroomsthereisnoindependentlifeofroomandanyroomcannotbelongtotwodifferenthouses.Ifwedeletethehouse- roomwillautomaticallybedeleted.

• Questions -----<filled> options.Singlequestionscanhavemultipleoptionsandoptioncannotbelongtomultiplequestions.Ifwedeletequestionsoptionswillautomaticallybedeleted.

10

Object Composition

Compositionisactuallyaspecialcaseoftheaggregationrelationship.Aggregationmodelshas-a relationshipsandrepresentsanownershiprelationshipbetweentwoobjects.Theownerobjectiscalledanaggregatingobject anditsclassanaggregatingclass.Thesubjectobjectiscalledanaggregatedobject anditsclassanaggregatedclass.

11

ClassRepresentation

Anaggregationrelationshipisusuallyrepresentedasadatafieldintheaggregatingclass.Forexample,therelationshipinFigure10.6canberepresentedasfollows:

public class Name {

...

}

public class Student {

private Name name;

private Address address;

...

}

public class Address {

...

}

Aggregated class Aggregating class Aggregated class

12

AggregationorComposition

•Sinceaggregationandcompositionrelationshipsarerepresentedusingclassesinsimilarways,manytextsdon’tdifferentiatethemandcallbothcompositions.

•Relasi Aggregasi atau komposisi karenadirepresentasi dengan classdengan cara yangmirip/sama,maka kadang disebut dengankomposisi saja

Relasi

•Relasi 1to1(onetoone):satu objek Ahanyamemiliki pasangan 1objek B

•Relasi 1toNatau 1..*(onetomany) :satu objekAbisa memiliki minimal1atau banyak objek B

•Relasi 0toNatau 0..*(zerotomany):satu objek Abisa memiliki banyak objek Batau tidak ada samasekali

•Relasi MtoMatau N..N(manytomany): objek Adan objek Bbisa 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

CommunitySchoolsBusinessesResidents

SchoolFacultyStudentsAdministratorsClassrooms

ClassroomTablesChairsStudentsInstructor

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

18

• 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

• vis = visibility (+ for public, - for private)• attribute = data member (aka field)• operation = method (or constructor)

• The arg list is a list of parameter types (e.g., int, double, String); • Parameter names are not included in the UML class diagram • Methods that don't return a value (i.e. void methods) should give a

return type of void• Class (i.e. static) methods and fields are indicated by underlining • Constant (i.e. final) fields are indicated via naming convention:

constants should be in ALL_CAPS

ClassName

vis attribute : type

vis operation(arg list) : return type

public class Employee {

private String name;private double payRate;private final int EMPLOYEE_ID; private static int nextID = 1000;public static final double STARTING_PAY_RATE = 7.75;

public Employee(String name) {this.name = name;EMPLOYEE_ID = getNextID();payRate = STARTING_PAY_RATE;

}

public Employee(String name, double startingPay) {this.name = name;EMPLOYEE_ID = getNextID();payRate = startingPay;

}

public String getName() { return name; } public int getEmployeeID() { return EMPLOYEE_ID; }public double getPayRate() { return payRate; }public void changeName(String newName) { name = newName; }public void changePayRate(double newRate) { payRate = newRate; } public static int getNextID() {

int id = nextID; nextID++;return id;

}}

Contoh Class Diagram

Comparison of Functional vs. OO Views

RegisterStudent

Print Transcript

SubmitGrade

Students

Students Grades

Student/Grades

Student

Register( )Submit Score( )Print Transcript( )

0..*

ScoreNameValue0..*

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

RegisterStudent

Print Transcript

SubmitGrade

Students

Students/Pass Fail Students Grades/PF

Student/Grades/PF

ImpactAreas

Student

Register( )Submit Score( )Print Transcript( )

0..*

ScoreNameValue0..*

PassFail Student

Print Transcript( ) function override

PassFail Student

Print Transcript( )Print Report Card(

Student

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

0..*

ScoreNameValue0..*

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

SubmitGrade

Students

Students Grades

Student/Grades/PF

RegisterStudent

PrintReport Card

Student/Grades/PF

ImpactAreas

Re-organization of OO Abstractions

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

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

0..*

ScoreNameValue

Student

Register( )Submit Score( )

0..*

0..1Transcript

Print( )0..1

PassFail Student

Determine Grade( )

0..*

ScoreNameValue

0..1Transcript

Print( ) Student

Register( )Submit Score( )Determine Grade( )

0..*

0..1

PassFail Student

Determine Grade( )

0..*

ScoreNameValue

0..1Transcript

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

29Fig. 8.24 | Class diagram with visibility markers.

Case Study: ATM System

30

Fig. 8.25 | Class diagram with navigability arrows.

31

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

32

Fig. 8.24 | Class diagram with visibility markers.

33Outline•

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

34

Fig. 8.24 | Class diagram with visibility markers.

35Outline•

1 // Class Withdrawal represents an ATM withdrawal transaction

2 public class Withdrawal

3 {

4 // attributes

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

6 private double amount; // amount to withdraw

7

8 // no-argument constructor

9 public Withdrawal()

10 {

11 } // end no-argument Withdrawal constructor

12 } // end class Withdrawal

withdrawal.java

Declare instance variables

36

Fig. 8.25 | Class diagram with navigability arrows.

37Outline•

1 // Class Withdrawal represents an ATM withdrawal transaction 2 public class Withdrawal

3 {

4 // attributes 5 private int accountNumber; // account to withdraw funds from 6 private double amount; // amount to withdraw 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 15 public Withdrawal() 16 { 17 } // end no-argument Withdrawal constructor 18 } // end class Withdrawal

withdrawal.java

Declare references to other objects

38

Fig. 8.24 | Class diagram with visibility markers.

39Outline•

1 // Class Withdrawal represents an ATM withdrawal transaction

2 public class Withdrawal

3 {

4 // attributes

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

6 private double amount; // amount to withdraw

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 15 public Withdrawal() 16 { 17 } // end no-argument Withdrawal constructor 18 19 // operations 20 public void execute() 21 { 22 } // end method execute 23 } // end class Withdrawal

withdrawal.java

Declare shell of a method with return type void