RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
35/55
Diagram UML
Use-case diagram (statis) scenario-based models
Class diagram (statis) class models
Collaboration/sequence diagram (dinamis) behavioral models
Statechart diagram (dinamis) behavioral models
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
64/55
Statechart diagram – example
Waiting for a coin
Waiting for selection
Dispensing product
Returning payment
initial
accept new coin
payment returned
accept new coin
coin detected
accept customer request
product dispensed
accept new coin
sufficient payment
dispense product
product available=FALSE
return payment
coin return request
return payment
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
63/55
Statechart diagram
A statechart diagram shows the behavior of classes in response to external stimuli
This diagram models the dynamic flow of control from state to state within a system
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
62/54
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
61/54
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
60/55
Sequence diagram – example
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
59/55
Sequence diagram
An interaction diagram that emphasizes the time ordering of messages
Shows a set of objects and the messages sent and received by those objects
Elements
Object represented in a box
Dashed line called the object lifeline, and it represents the existence of an object over a period of time
Message rendered as horizontal arrows being passed from object to object as time advances down the object lifelines
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
58/55
Class stereotypes
Model interaction between the system and its environment
Actor 1
<>
<>
<>
<>
<>
Actor 2
boundary
entity
control
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
57/55
Class stereotypes
Entity classes
used to model data and behavior of some real life system concept or entity e.g. member, bank account, order, employee
these will sometimes require more persistent storage of information e.g. a student's details are ultimately stored as a student record
Control classes
represent coordination, sequencing, transactions and control of other objects
glue between boundary elements and entity elements, describing the logic required to manage the various elements and their interactions
roughly one per use case
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
65/55
Penutup
Pemodelan kebutuhan diperlukan untuk meningkatkan pemahaman terhadap kebutuhan yang sedang dianalisis
Pemodelan terstruktur meliputi pemodelan data models, process models dan behavioral models dari sistem yang sedang dikembangkan
Pemodelan berorientasi objek mencakup scenario-based models, class models dan behavioral models dari sistem yang sedang dikembangkan
Alat bantu yang digunakan dalam pemodelan terstruktur dan berorientasi objek terdapat perbedaan
2 – Pemodelan Berorientasi Objek
Tugas kelompok
Berikan contoh studi kasus aplikasi yang menggunakan permodelan terstruktur sesuai dengan topik praktikum
Buat ERD, DFD, STD dari contoh kasus tersebut
Kumpulkan hari Selasa sebelum jam 12 siang via email.
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
32/54
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
25/55
Behavior model
State Transition Diagram (STD)
Waiting for a coin
Waiting for selection
Dispensing product
Returning payment
initial
accept new coin
payment returned
accept new coin
coin detected
accept customer request
product dispensed
accept new coin
sufficient payment
dispense product
product available=FALSE
return payment
coin return request
return payment
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
27/54
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
26/55
Behavior model (1)
CSPEC – Dispense change : Process Activation Table
coin return request
product available
get change coin
get payment coin
TRUE
TRUE
1
0
D/C
FALSE
0
1
DFD -0
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
28/54
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
29/54
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
30/54
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
31/54
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
56/55
Class stereotypes
Boundary classes
model the interaction and manage communication between the computer system and its actors, but don't directly represent the specific interface object in the implementation
used to identify the main logical interfaces with users and other systems (including e.g. other software packages, printers)
main task is to translate information across system boundaries
partition the system so that interface is kept separate from business logic
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
55/55
Class relationships – examples
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
54/54
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
43/55
Identifikasi operasi/servis
A specific behavior that an object is responsible for exhibiting [Yourdon]
Langkah-langkah:
Identifikasi tanggung jawab umum sebuah klas (verbs)
Identifikasi operasi yang spesifik untuk domain masalah
Identifikasi operasi yang relevan dg peran atau tanggung jawab dalam sistem
Spesifikasi operasi argumen, batasan/aturan, logika/algoritma
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
42/55
Identifikasi atribut
Some data (state information) for which each object in a class has its own value [Yourdon]
Langkah-langkah:
Identifikasi atribut umum (adjectives, possessives)
Identifikasi atribut yang relevan dg domain masalah
Identifikasi atribut yang relevan dg peran atau tanggung jawab dalam sistem
Restrukturisasi atribut sehingga atomic kemudahan
Reposisi atribut yang sesuai dengan hirarki klas nya pewarisan klas
Spesifikasi atribut presisi, nilai default, batasan, dll.
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
41/55
What to look for ? Nouns
Structures
Relasi antar objek generalisasi, agregasi
Other systems
Sistem lain yang berinteraksi dg proposed system
Things or events remembered
Data, status, kejadian yang harus disimpan
Roles played
Identifikasi peran manusia dalam sistem berinteraksi langsung, tidak berinteraksi tetapi informasinya disimpan sistem
Sites
Informasi lokasi/posisi yang harus diingat oleh sistem
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
40/55
Where to look ?
Investigasi domain masalah
Langkah-langkah:
Observe first-hand observasi langsung ke lap.
Actively listen to problem domain experts what, who, why, when and how
Check previous OOA results
Check other systems comparison
Read, read, read getting some more information
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
38/55
Object, Class – Apa Itu ?
Klas (Class) :
A description of one or more objects with a uniform set of attributes and services, including a description of how to create new objects in the class [Yourdon]
Gambaran umum (template, blue-print) yang menjelaskan sekumpulan objek yang memiliki kesamaan karakteristik (atribut dan operasi)
Merupakan cetakan dari objek
Digunakan untuk menginstansiasi objek yang memiliki identitas yang berbeda
Contoh : Klas Mahasiswa objek Andi, Eko, Susi
Abstract & concrete class
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
39/55
Object, Class – Apa Itu ?
Mahasiswa
NIM
Nama
Buat skripsi
Ujian
Mahasiswa
NIM : 001
Nama : Andi
Buat skripsi
Ujian
Mahasiswa : Andi
Mahasiswa
NIM : 002
Nama : Eko
Buat skripsi
Ujian
Mahasiswa : Eko
Mahasiswa
NIM : 003
Nama : Susi
Buat skripsi
Ujian
Mahasiswa : Susi
Instansiasi : penciptaan objek
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
37/55
Object, Class – Apa Itu ?
Objek (Object) :
A concept, abstraction, or thing with crisp boundaries and meaning for the problem at hand [Rumbaugh]
Benda (tangible & intangible thing)
Contoh : Andi, Eko, Susi (sistem akademik)
Sebuah objek memiliki karakteristik : identity (identitas-pembeda), state (sekumpulan atribut) & behavior (sekumpulan operasi, aksi, servis)
Notasi :
Nama Objek
Atribut2
Operasi2
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
36/55
Keuntungan
Sangat natural, sesuai dengan cara berpikir manusia improve analyst and problem domain expert interaction
Meningkatkan konsistensi hasil analisis abstraksi atribut-operasi dalam sebuah objek
Konsep penurunan klas memberikan kemudahan dalam generalisasi objek
Kemudahan dalam perubahan
Terjaganya konsistensi model antara analisis dan perancangan
Konsep reusability
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
44/55
Use-case diagram
Menjelaskan perilaku sistem dari tampak luar
Menyediakan fungsi-fungsi yg harus dipenuhi sistem sesuai dengan aktornya
Elemen: actor (orang, sistem lain) dan use-case
Setiap use-case dilengkapi dengan skenario (deskripsi)
Langkah-langkah:
Identifikasi aktor
Identifikasi use-case per aktor
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
45/55
Use-case diagram
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
53/55
Aggregation – composition
Aggregation represents a part-whole or part-of relationship
Aggregation can occur when a class is a collection or container of other classes, but where the contained classes do not have a strong life cycle dependency on the container – essentially, if the container is destroyed, its contents are not
Composition is more specific than aggregation
Composition usually has a strong life cycle dependency between instances of the container class and instances of the contained class(es) if the container is destroyed, normally every instance that it contains is destroyed as well
Aggregation
Denpendency
Composition
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
46/55
Use-case scenario
Flow of events for the Select product use-case
Objective
Allow customer to select a certain product to dispense
Actors
Customer
Pre-condition
Coin detected and valid
Main flow
The customer selects a button product.
The system displays an entry prompt of number of product to order.
Alternative flows
If the selected product is not available, the system will display a message "Your selected product is not available".
If the selected product is available but there isn't enough number to order, the system will display a message "The number isn't enough, max. x". X is the existing number of the product.
Post-condition
The selected product dispensed as the number needed
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
52/55
Association
For "real-world objects" is there an association between classes?
Classes A and B are associated if:
An object of class A sends a message to an object of B
An object of class A creates an instance of class B
An object of class A has an attribute of type B or collections of objects of type B
An object of class A receives a message with an argument that is an instance of B (maybe…) will it "use" that argument?
Does an object of class A need to know about some object of class B?
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
51/55
Class diagram
Menggambarkan struktur statis dari sistem
Terdiri dari node (klas) dan relasi
Jenis relasi
Generalization ('is a' – inheritance)
Association
Aggregation ('part-of')
Composition
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
50/55
Actor-generalization
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
49/55
Actor-generalization
Two/more sub-actors generalized into a super-actor
Have both behavior and attributes in common – described under the super-actor
Super-actor should interact with use cases when ALL of its sub-actors interact in the same way
Sub-actors should interact with use cases when their individual interactions differ from that of the super-actor
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
48/55
<> and <>
ViewMap
OpenIncident
AllocateResources
<>
<>
Base Use
Case
Supplier
Use Case
ReportEmergency
Help
<>
A
B
Base Use
Case
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
47/55
Use-case association
Include
A use case uses another use case (functional decomposition) reuse
A function in the original problem statement is too complex to be solvable immediately describe the function as the aggregation of a set of simpler functions (mandatory)
Extend
A use case extends another use case
The functionality in the original problem statement needs to be extended
The extended use-case plays an optional use-case
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
34/55
Object Oriented Approach
Mulai populer akhir '80an – '90an (Booch, Rumbaugh-OMT, Jacobson-OOSE, Coad+Yourdon, Wirfs-Brock) :
Elisitasi kebutuhan customer
Identifikasi skenario / use-case (use-case diagram)
Identifikasi klas berdasarkan kebutuhan customer
Identifikasi atribut dan operasi setiap klas
Definisi struktur klas (class diagram)
Definisi model relasi antar klas (collaboration/sequence diagram)
Definisi perpindahan status sistem (statechart diagram)
1996 : UML (Unified Modeling Language) – Grady Booch+James Rumbaugh+Ivar Jacobson
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
24/55
Process model – Process specification
PSPEC – Validate payment (Process 3)
Inputs : payment (data in)
price (data in)
Outputs : change due (data out)
sufficient payment (control out)
Body :
IF payment >= price THEN
change due = payment – price
sufficient payment = TRUE
ELSE
change due = 0
sufficient payment = FALSE
END IF
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
22/55
Data/Control Flow Diagram (DFD/CFD level 1)
1*
Get customer payment
2p
Get product price
3p
Validate payment
4p
Get valid selection
5*
Dispense change
6p
Dispense product
price table
coins
products
returned coins
product
object
customer selection
slug
coin return request
payment
price
valid selection
change due
valid selection
coin detected
sufficient payment
product dispensed
product available
product available
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
9/55
Elemen-elemen pemodelan
Data Dictionary
Data Flow Diagram (DFD)
ER Diagram
State Transition Diagram (STD)
Process Specification (PSPEC)
Data Object Description
Control Specification (CSPEC)
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
8/55
Konsep
Pertama kali dipopulerkan oleh T. DeMarco (1979) Structured Analysis and System Specification
Perluasan notasi untuk kebutuhan real-time systems oleh Hatley dan Pirbhai (1987) – SA/RT Strategies for Real-Time System Specification
Processes
Data
Behavior
1 – Pemodelan Terstruktur
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
6/55
Tipe-tipe model kebutuhan
Scenario-based models
Berdasarkan sudut pandang aktor
Data models
Menjelaskan domain informasi dari masalah
Class-oriented models
Merepresentasikan klas-klas yang relevan dengan kebutuhan PL
Flow-oriented models
Merepresentasikan proses dan data dari sistem
Behavioral models
Merepresentasikan perilaku sistem berdasar event
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
5/55
Prinsip pemodelan kebutuhan
Model yang dibuat harus fokus pada kebutuhan yang relevan dengan domain permasalahan WHAT
Setiap model kebutuhan harus bisa dilacak ke model perancangan traceability
Setiap elemen dalam model kebutuhan harus mampu memperjelas pemahaman secara utuh terhadap kebutuhan PL domain masalah, fungsionalitas dan perilaku sistem
Minimalisasi kopling antar klas
Memastikan bahwa model kebutuhan memiliki nilai manfaat untuk seluruh stakeholders
Model dibuat sesederhana mungkin notasi yang sederhana, non duplikasi informasi
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
4/55
Konsep pemodelan kebutuhan
Model kebutuhan menjembatani antara deskripsi sistem secara umum dengan model perancangan
Tujuan utama model kebutuhan:
Menjelaskan apa yang dibutuhkan oleh customer
Menjadi dasar bagi perancangan PL
Menjadi referensi dalam melakukan validasi kebutuhan
Metode: terstruktur (structured analysis – SA) & berorientasi objek (object oriented analysis – OOA)
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
3/55
Agenda
Konsep pemodelan kebutuhan
Pemodelan terstruktur
Pemodelan berorientasi objek
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
23/55
Data/Control Flow Diagram (DFD/CFD level 2)
DFD/CFD level 2 : Dispense change
5.1p
Get change coin
coin return request
5.2p
Get payment coin
product available
change due
coins
payment
payment coins
change coins
returned coins
REKAYASA PERANGKAT LUNAK (RPL)
Rekayasa Kebutuhan – Pemodelan
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
10/55
Data dictionary
Representasi Simbol :
= : composed of + : and
{ } : iterations of […."…] : selection / or
( ) : optional " " : literal
* * : comment/description
Vend product (partly) :
Name Element Type
object [coin " slug](product) data
product [ice cream " coffee " candy] data
coins 0{[quarter " nickel " dime]}8 data
product available [TRUE " FALSE] control
["YES" " "NO"]
quarter *25 cents US currency*
coin return request [TRUE " FALSE] control
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
2/55
Tujuan perkuliahan
Memahami konsep pemodelan dalam rekayasa kebutuhan
Memahami konsep pendekatan terstruktur dan berorientasi objek dalam pemodelan kebutuhan
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
12/54
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
21/55
Data/Control Context Diagram (DCD/CCD)
Vend
product
Customer
returned coins
0*
Customer
product
object
customer selection
slug
coin return request
product available
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
20/55
Process model – DFD/CFD leveling
Must be consistent
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
19/55
Data – control identification
Identify data first rather than control to know what you are controlling first
Continuous signals, and processes that act on them, are always categorized as data
Discrete signals, and processes that act on them, are usually categorized as control
Terms like activate, turn on, engage and execute are usually associated with control requirements
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
18/55
Process model – Panduan DFD
Jumlah proses dalam satu diagram DFD : 4 + 2
Maks. 4 level dekomposisi (DFD/CFD)
Dekomposisi fungsional (DFD) :
fungsi-fungsi yang saling berhubungan dikelompokkan
fungsi-fungsi yang tidak berhubungan dipisahkan
setiap fungsi dispesifikasi hanya sekali
Data flow membawa informasi yg diperlukan oleh sebuah proses untuk transformasi, control flow membawa informasi yang harus diinterpretasikan untuk merubah perilaku sistem dan/ aktifasi proses
Proses pemodelan DFD/CFD adalah proses iterasi, tidak sekali jadi
Penjenjangan CFD harus sesuai dengan DFD
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
11/55
Data model – ER diagram
Entitas (atribut dan nilai atribut)
Modalitas : tingkat mandatory (minimal)
Kardinalitas : tingkat relasi (maksimal)
Bentuk relasi
Manufacturer
Car
Builds
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
16/55
Process model – Elemen2 DFD
Terminator
Representasi entitas eksternal
Notasi: persegi panjang
Tidak memproses data
Data flow
Representasi aliran data
Notasi: anak panah penuh
Umumnya satu arah
Hubungkan terminator, process dan storage
Control flow
Representasi aliran kontrol proses
Notasi: anak panah putus2
Hubungkan terminator, process dan control bar
Customer
data
control
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
13/54
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
17/55
Process model – Elemen2 DFD (1)
Process
Representasi aktifitas sistem
Notasi: lingkaran
Memproses data
Storage
Representasi tempat penyimpanan data
Notasi: dua garis paralel
Data flow in = diubah, data flow out = dibaca
Control bar
Representasi spesifikasi kontrol
Notasi: garis tegak
1
Proses A
data X
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
15/55
Process model – DFD
Useful for analyzing existing as well as proposed systems process decomposition
Focus on the movement of data between external entities and processes, and between processes and data stores
A relatively simple technique to learn and use
Model elements: terminator, process, data flow, control flow, storage, control bar
The highest level (0) Context diagram
Single process
Terminators
Data flows, control flows
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
14/55
Data model – data object description
Data object
represents a composite information
consists of a number of different attributes or properties
encapsulates data only no operation applied to its data
can be external entity, thing, occurrence/event, role, organizational unit, structure, etc.
e.g. dimensions (height, weight, depth), cars (make, model, ID, body type, color, owner)
can be represented in a tabular representation
Click to edit Master title style
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
# /54
- Generalisasi berarti target dari hubungannya ke kelas yang lebih general (umum). Sebagai contoh jika kita memiliki kelas bernama Cat dan kelas bernama Dog, kita dapat membuat generalisasi dari keduanya dengan nama Animal. Generalisasi biasanya dibaca "… adalah …" dimulai dari kelas yeng lebih spesifik menuju kelas yang lebih umum (general class). Jadi dapat dikatakan "suatu Cat adalah suatu Animal".
- Association Terkadang hubungan antara dua elemen tidak sederhana. Misalnya, suatu tim pemain bola (football player) berasosiasi dengan liga (league) lewat suatu regu. Jika hubungannya terlalu rumit, bisa dibuatkan hubungan asosiasi antar kelas. Yang perlu diperhatikan dari gambar diatas adalah FootballPlayer tidak memiliki referensi langsung kepada FootballLeague tapi memiliki referensi terhadap FootballTeam. footballTeam akan memiliki referensi terhadap FootballLeague.
Composit : Misalnya, jika Window yang kita buat harus memeliki Titlebar maka kita dapat merepresentasikan suatu kelas bernama Titlebar yang merupakan "bagian dari" kelas Window.
Agregasi adalah versi kuat dari asosiasi. Tidak seperti asosiasi, agregasi mengimplikasikan kepemilikansuatu kelas. Agregasi bisa dibaca " … memilik … ".
51
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
# /54
Click to edit Master title style
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
Click to edit Master text styles
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
# /54
Click to edit Master title style
Click to edit Master text styles
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
# /54
Click to edit Master title style
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
# /54
Click to edit Master title style
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
# /54
Composition: Jika sebuah class tidak bisa berdiri sendiri dan harus merupakan bagian dari class yang lain, maka class tersebut memiliki relasi Composition terhadap class tempat dia bergantung tersebut. Sebuah relationship composition digambarkan sebagai garis dengan ujung berbentuk jajaran genjang berisi/solid.
53
Click to edit Master title style
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
# /54
Association : Sebuah asosiasi merupakan sebuah relationship paling umum antara 2 class dan dilambangkan oleh sebuah garis yang menghubungkan antara 2 class. Garis ini bisa melambangkan tipe-tipe relationship dan juga dapat menampilkan hukum-hukum multiplisitas pada sebuah relationship.(Contoh: One-to-one, one-to-many,many-to-many).
52
Boundary class menangani komunikasi antara lingkungan sistem dan kedalam sistem. Mereka dapat menjamin interface ke pengguna atau sistem lain ( misalnya, interface ke actor ). Boundary class digunakan untuk memodelkan sistem interface.
56
Actor merepresentasikan entitas yang berada di luar system. Mereka bisa berupa manusia, perangkat keras atau system lain.
General life line Merepresentasikan entitas tunggal dalam sequence diagram, digambarkan dengan kotak. Entitas ini memiliki nama, stereotype atau berupa instance (menggunakan instance:class)
59
Click to edit Master title style
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
# /54
Click to edit Master title style
Click to edit Master subtitle style
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
# /43
- Entity class memodelkan informasi dan operasi yang biasanya berumur panjang/lama. Tipe class ini menggambarkan entitas dunia nyata atau entitas yang dibutuhkan untuk melakukan tugas internal sistem.
- Control class memodelkan urutan kelakukan ( behavior ) khusus untuk satu atau lebih use case. Pada awal phasa Elaboration, sebuah control class ditambahkan untuk setiap pasangan actor atau use case. Control class bertanggung jawab untuk aliran kejadian-kejadian dalam use case.
57
Click to edit Master title style
Click to edit Master text styles
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
# /54
Click to edit Master title style
Click to edit Master text styles
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
Click to edit Master text styles
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
# /54
Click to edit Master title style
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
# /54
Click to edit Master title style
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
# /54
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
#