Pemodelan Rekayasa Kebutuhan

Pemodelan Rekayasa Kebutuhan REKAYASA PERANGKAT LUNAK Semester Ganjil 2015/2016

ADAM HENDRA BRATA

Tujuan & Agenda Perkuliahan  Tujuan  Memahami konsep pemodelan dalam rekayasa kebutuhan  Memahami konsep pendekatan terstruktur dan berorientasi objek dalam pemodelan kebutuhan

Pemodelan Rekayasa Kebutuhan

 Agenda  Konsep pemodelan kebutuhan  Pemodelan terstruktur  Pemodelan berorientasi objek

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)

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

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 Pemodelan Rekayasa Kebutuhan

 Flow-oriented models  Merepresentasikan proses dan data dari sistem

 Behavioral models  Merepresentasikan perilaku sistem berdasar event


Pemodelan Terstruktur

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

Elemen – Elemen Pemodelan

Data Object Description Data Flow Diagram (DFD)


ER Diagram

Data Dictionary

State Transition Diagram (STD)

Control Specification (CSPEC)

Process Specification (PSPEC)

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

Data Model : ER Diagram  Entitas (atribut dan nilai atribut)  Modalitas : tingkat mandatory (minimal)  Kardinalitas : tingkat relasi (maksimal)  Bentuk relasi


Manufacturer

Builds

Car

Data Model : ER Diagram


 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

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

Process Model : Elemen – Elemen DFD  Terminator  Representasi entitas eksternal  Notasi: persegi panjang  Tidak memproses data

Customer


 Data flow    

Representasi aliran data data Notasi: anak panah penuh Umumnya satu arah Hubungkan terminator, process dan storage

 Control flow  Representasi aliran kontrol proses control  Notasi: anak panah putus2  Hubungkan terminator, process dan control bar

Process Model : Elemen – Elemen DFD  Process  Representasi aktifitas sistem  Notasi: lingkaran  Memproses data

1 Proses A

 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

data X

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

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

Process Model : DFD/CFD Leveling


 Must be consistent

Data / Control Context Diagram (DCD/CCD)

object 0*


Customer

customer selection

slug

coin return request

returned coins

Vend product

Customer product

product available

Data / Control Flow Diagram (DCD/CCD Level 1)

object slug


coin detected

coin return request

coins 1* Get customer payment

price table

2p Get product price

5* Dispense change

payment sufficient payment price

returned coins

change due 3p Validate payment

valid selection customer selection

product product available

4p Get valid selection

6p Dispense product

product dispensed

valid selection product available

products

Data / Control Flow Diagram (DCD/CCD Level 2)  DFD/CFD level 2 : Dispense change

coin return request product available


change due 5.1p Get change coin

returned coins

change coins

coins payment

5.2p Get payment coin

payment coins

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

Behavior Model  State Transition Diagram (STD) initial accept new coin


Waiting for a coin

product dispensed accept new coin

payment returned accept new coin

coin detected coin return accept request customer return payment request Returning Waiting for payment selection product sufficient available=FALSE payment dispense return payment product Dispensing product

Behavior Model


 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


Pemodelan Berorientasi Objek

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

Diagram UML  Use-case diagram (statis)  scenario-based models

 Class diagram (statis)  class models

 Collaboration/sequence diagram (dinamis)  behavioral models

 Statechart diagram (dinamis) Pemodelan Rekayasa Kebutuhan

 behavioral models

Keuntungan UML  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

Object & Class


 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) Nama Objek

Atribut2 Operasi2

Object & Class


 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

Object & Class Mahasiswa - NIM - Nama


Instansiasi : penciptaan objek

- Buat skripsi

- Ujian

Mahasiswa : Andi

Mahasiswa : Eko

Mahasiswa : Susi

Mahasiswa

Mahasiswa

Mahasiswa

- NIM : 001

- NIM : 002

- NIM : 003

- Nama : Andi

- Nama : Eko

- Nama : Susi

- Buat skripsi

- Buat skripsi

- Buat skripsi

- Ujian

- Ujian

- Ujian

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

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

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.

Identifikasi Operasi / Servis


 A specific behavior that an object is responsible for exhibiting [Yourdon]  Langkah-langkahIdentifikasi 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

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

Use Case Diagram


Enter object

Customer

Select product

Get return coins

Use Case Scenario Flow of events for the Select product use-case Allow customer to select a certain product to dispense

Actors

Customer

Pre-condition

Coin detected and valid

Main flow

1. The customer selects a button product. 2. The system displays an entry prompt of number of product to order.


Objective

Alternative flows

1. If the selected product is not available, the system will display a message “Your selected product is not available”. 2. 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

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) Pemodelan Rekayasa Kebutuhan

 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 usecase


Use Case Association


Actor Generalization  Two/more sub-actors generalized into a superactor  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


Actor Generalization

Class Diagram  Menggambarkan struktur statis dari sistem  Terdiri dari node (klas) dan relasi  Jenis relasi


   

Generalization (‘is a’ – inheritance) Association Aggregation (‘part-of’) Composition

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?


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


Class Relationships

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

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 Pemodelan Rekayasa Kebutuhan

 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

Class Stereotypes <>


Actor 1

<>

<> Actor 2

<<entity>>

<<entity>>

Model interaction between the system and its environment boundary

entity

control

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

Sequence Diagram

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

Statechart Diagram

initial accept new coin


Waiting for a coin

product dispensed accept new coin

payment returned accept new coin

coin detected coin return accept request customer return payment request Returning Waiting for payment selection product sufficient available=FALSE payment dispense return payment product Dispensing product


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


Terimakasih v^^

Pemodelan Rekayasa Kebutuhan

Recommend Documents