Sei sulla pagina 1di 40

PEMROGRAMAN LANJUT

Sistem Informasi FILKOM UB


Semester Genap 2016/2017

KONSEP OOP
DIAGRAM UML

Dr. Eng. Herman Tolle


Fakultas Ilmu Komputer, Universitas Brawijaya
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
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 / Generalisasi
4. Realization
Association

• Association A---->B
Composition A-----<filled>B
Aggregation 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.
Object Composition

Composition is actually a special case of the aggregation


relationship.
Aggregation models has-a relationships and represents an
ownership relationship between two objects. The owner object is
called an aggregating object and its class an aggregating class. The
subject object is called an aggregated object and its class an
aggregated class.

10
Class Representation

An aggregation relationship is usually represented as a


data field in the aggregating class. For example, the
relationship in Figure 10.6 can be represented as follows:

public class Name { public class Student { public class Address {


... private Name name; ...
} private Address address; }

...
}

Aggregated class Aggregating class Aggregated class

11
Aggregation or Composition

• Since aggregation and composition relationships


are represented using classes in similar ways, many
texts don’t differentiate them and call both
compositions.
• Relasi Aggregasi atau komposisi karena
direpresentasi dengan class dengan cara yang
mirip/sama, maka kadang disebut dengan
komposisi saja

12
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
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 School Classroom


Schools Faculty Tables
Businesses Students Chairs
Residents Administrators Students
Classrooms 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 Student
· Name · Name
· Attendence
· Current
Grade
Class Diagram
• 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

18
ClassName

vis attribute : type

vis operation(arg list) : return type

• 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
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
Register Submit
Student
Grade
Student
Students Grades Score

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

Print
Transcript
Addition of a New Student Type
Student
Register Score
Submit
Student Register( ) Name
Grade Submit Score( ) 0..* Value
Print Transcript( )
Students/
Pass Fail Students Grades/PF

Students Impact
Student/Grades/PF Areas
PassFail Student
Print
Transcript Print Transcript( ) function override

• Changes in data types cause significant impact to


functional approaches
• OO approaches allow new object types to re-define
functionality
Addition of New Report Type

Register Submit Student


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

Areas
Students
Student/Grades/PF
Student/Grades/PF
PassFail Student
Print Print
Transcript Report Print Transcript( )
Print Report Card(
Card

• Changes in functionality based on stable data causes


significant impact across objects
• Functional approaches allow new functions to augment
functionality
Re-organization of OO
Abstractions
Transcript Transcript
0..1 Student
Score 0..1
Print( ) Print( ) Student
Name Score
Register( )
Submit 0..* Value Register( )
Name
Score( ) 0..* Value
Submit Score( )
Determine Grade( )

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

PassFail Student

Determine Grade( )

• Data dependent behavior handled by derived classes


• New functionality handled by new associated classes
("wrappers", "adapters", "views")
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
Case Study: ATM System

Fig. 8.24 | Class diagram with visibility markers.


29
Fig. 8.25 | Class diagram with navigability arrows.

30
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

31
Fig. 8.24 | Class diagram with visibility markers.

32
1 // Class Withdrawal represents an ATM withdrawal transaction 33
2
3
public class Withdrawal
{
Class for
Outline
4 // no-argument constructor
Withdrawal
5 public Withdrawal() •
Empty no-argument withdrawal.ja
6 {
constructor va
7 } // end no-argument Withdrawal constructor
8 } // end class Withdrawal
Fig. 8.24 | Class diagram with visibility markers.

34
1 // Class Withdrawal represents an ATM withdrawal transaction 35
2
3
public class Withdrawal
{
Outline
4 // attributes
5 private int accountNumber; // account to withdraw funds from

6 private double amount; // amount to withdraw withdrawal.ja
7 va
8 // no-argument constructor
9 public Withdrawal() Declare instance
10 { variables
11 } // end no-argument Withdrawal constructor
12 } // end class Withdrawal
Fig. 8.25 | Class diagram with navigability arrows.

36
1 // Class Withdrawal represents an ATM withdrawal transaction 37
2
3
public class Withdrawal
{
Outline
4 // attributes
5 private int accountNumber; // account to withdraw funds from
6 private double amount; // amount to withdraw •
withdrawal.ja
7
8 // references to associated objects
va
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 Declare references to other
18 } // end class Withdrawal objects
Fig. 8.24 | Class diagram with visibility markers.

38
1 // Class Withdrawal represents an ATM withdrawal transaction 39
2
3
public class Withdrawal
{
Outline
4 // attributes
5 private int accountNumber; // account to withdraw funds from
6 private double amount; // amount to withdraw •
7
withdrawal.ja
8 // references to associated objects va
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 Declare shell of a method with
return type void

Potrebbero piacerti anche