KONSEP OOP DIAGRAM UML

PEMROGRAMAN LANJUT
Sistem Informasi FILKOM UB
Semester Genap 2016/2017
KONSEP OOP
DIAGRAM UML
Dr.Eng.HermanTolle
FakultasIlmuKomputer,UniversitasBrawijaya
Materi Pemrograman Lanjut
1.
2.
3.
4.
5.
6.
7.
8.
Review Pemrograman Dasar
Konsep OOP,
Class dan object,
UML Class Diagram
Fungsi overloading dan konstruktor,
Enkapsulasi,
Inheritance/pewarisan,
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
• 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,makaasosiasiataurelationship
diantarakeduanyadisebutComposition (Komposisi).
• Jikasuatuobjekmemiliki objeklainmakainidisebut
Aggregation(Agregasi).
• Aggregation(many-to-onerelationships)
•
•
•
•
Whole– Part(à Composition)
Containership
Collection
Group
Composition
• KomposisiadalahbentukkhususdariAgregasi(disebutjuga“death
relationship”).ChildObject(Objekyangdigunakandalamobjek
induknya)tidakmemilikilifecycle.Jikaobjekinduknyadihapusmaka
objekanaknyajugaakanterhapus.
• Misalnya:
• House -----<filled> Rooms
• Housecancontainmultipleroomsthereisnoindependentlifeof
roomandanyroomcannotbelongtotwodifferenthouses.Ifwe
deletethehouse- roomwillautomaticallybedeleted.
• Questions -----<filled> options.Singlequestionscanhavemultiple
optionsandoptioncannotbelongtomultiplequestions.Ifwedelete
questionsoptionswillautomaticallybedeleted.
Object Composition
Compositionisactuallyaspecialcaseoftheaggregation
relationship.
Aggregationmodelshas-a relationshipsandrepresentsan
ownershiprelationshipbetweentwoobjects.Theownerobjectis
calledanaggregatingobject anditsclassanaggregatingclass.The
subjectobjectiscalledanaggregatedobject anditsclassan
aggregatedclass.
10
ClassRepresentation
Anaggregationrelationshipisusuallyrepresentedasa
datafieldintheaggregatingclass.Forexample,the
relationshipinFigure10.6canberepresentedasfollows:
public class Name {
public class Student {
...
private Name name;
private Address address;
}
public class Address {
...
}
...
}
Aggregated class
Aggregating class
11
Aggregated class
AggregationorComposition
• Sinceaggregationandcompositionrelationships
arerepresentedusingclassesinsimilarways,many
textsdon’tdifferentiatethemandcallboth
compositions.
• Relasi Aggregasi atau komposisi karena
direpresentasi dengan classdengan cara yang
mirip/sama,maka kadang disebut dengan
komposisi saja
12
Relasi
• Relasi 1to1(onetoone):satu objek Ahanya
memiliki pasangan 1objek B
• Relasi 1toNatau 1..*(onetomany) :satu objek
Abisa memiliki minimal1atau banyak objek B
• Relasi 0toNatau 0..*(zerotomany):satu objek A
bisa memiliki banyak objek Batau tidak ada sama
sekali
• Relasi MtoMatau N..N(manytomany): objek A
dan 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
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
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
Student
Submit
Grade
Students
Grades
Students
Student/Grades
Print
Transcript
Student
Register( )
Submit Score( )
Print Transcript( )
Score
Name
0..* Value
Addition of a New Student Type
Register
Student
Student
Submit
Students/
Pass Fail Students
Grade
Name
0..* Value
Grades/PF
Students
Student/Grades/PF
Print
Transcript
Register( )
Submit Score( )
Print Transcript( )
Score
Impact
Areas
PassFail Student
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
Student
Submit
Student
Score
Grade
Students
Grades
Students
Impact
Areas
Register( )
Submit Score( )
Print Transcript( )
Print Report Card(
0..*
Name
Value
Student/Grades/PF
Student/Grades/PF
Print
Transcript
Print
Report
Card
PassFail Student
Print Transcript( )
Print Report 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
0..1
Transcript
Student
Print( )
Score
Name
0..* Value
Register( )
Submit
Score( )
Print( )
0..1
Student
Register( )
Submit Score( )
Determine Grade( )
0..*
Transcript
Print( )
Report Card
0..1
0..1
Student
Register( )
Submit Score( )
Determine Grade( )
0..*
Score
Name
Value
PassFail Student
Determine Grade( )
Print( )
PassFail Student
Determine Grade( )
• Data dependent behavior handled by derived classes
• New functionality handled by new associated classes
("wrappers", "adapters", "views")
Score
Name
Value
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 softwareintensive 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
29
Fig. 8.24 | Class diagram with visibility markers.
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
2
public class Withdrawal
3
{
4
// no-argument constructor
5
public Withdrawal()
6
{
7
} // end no-argument Withdrawal
8
} // end class Withdrawal
Class for
Withdrawal
Empty no-argument
constructor
constructor
33
Outline
•
withdrawal.ja
va
Fig. 8.24 | Class diagram with visibility markers.
34
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
// no-argument constructor
9
public Withdrawal()
10
{
11
} // end no-argument Withdrawal constructor
12 } // end class Withdrawal
Outline
•
withdrawal.ja
va
7
8
35
Declare instance
variables
Fig. 8.25 | Class diagram with navigability arrows.
36
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
37
Outline
•
withdrawal.ja
va
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
Declare references to other
objects
Fig. 8.24 | Class diagram with visibility markers.
38
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
Declare shell of a method with
return type void
39
Outline
•
withdrawal.ja
va