sisteminformasifilkom ub semester …€¢aggregation (many-to-one relationships) •whole –part...
TRANSCRIPT
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