Pemodelan Rekayasa Kebutuhan

(1)

Pemodelan

Rekayasa Kebutuhan

REKAYASA PERANGKAT LUNAK

(2)

Tujuan & Agenda Perkuliahan

 Tujuan

 Memahami konsep pemodelan dalam rekayasa kebutuhan

 Memahami konsep pendekatan terstruktur dan berorientasi objek dalam pemodelan kebutuhan

 Agenda

 Konsep pemodelan kebutuhan  Pemodelan terstruktur

 Pemodelan berorientasi objek

Ke

(3)

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) odelan kay asa Ke butuhan

(4)

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

Ke

(5)

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 odelan kay asa Ke butuhan

(6)

Ke

butuhan

(7)

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

odelan kay asa Ke butuhan Processes Data Behavior

(8)

Elemen – Elemen Pemodelan

Ke butuhan Data Dictionary Data Flow Diagram (DFD) ER Diagram State Transition Diagram (STD) Process Specification (PSPEC) Data Object Description

(9)

Data Dictionary

odelan kay asa Ke butuhan 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*

(10)

Data Model : ER Diagram

 Entitas (atribut dan nilai atribut)

 Modalitas : tingkat mandatory (minimal)

 Kardinalitas : tingkat relasi (maksimal)

 Bentuk relasi

Ke

butuhan

(11)

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

odelan

kay

asa

Ke

(12)

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

Ke

(13)

Process Model : Elemen – Elemen

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

odelan kay asa Ke butuhan

Customer

data control

(14)

Process Model : Elemen – Elemen

DFD

 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

Ke

butuhan

1 ProsesA

(15)

 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

odelan

kay

asa

Ke

butuhan

(16)

 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

Ke

butuhan

(17)

 Must be consistent

(18)

Ke

butuhan

Data / Control Context Diagram

(DCD/CCD)

Vend

product

Customer

returned coins 0*

Customer

product object customer selection slug coin return request product available

(19)

odelan

kay

asa

Ke

butuhan

Data / Control Flow Diagram

(DCD/CCD 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

(20)

Ke

butuhan

Data / Control Flow Diagram

(DCD/CCD Level 2)

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

(21)

odelan

kay

asa

Ke

butuhan

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

(22)

Ke

butuhan

 State Transition Diagram (STD)

Behavior Model

Waiting for a coin Waiting for selection Dispensing 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

(23)

odelan

kay

asa

Ke

butuhan

 CSPEC – Dispense change : Process Activation

Table

Behavior Model

coin return request product available get change coin get payment coin TRUE TRUE 1 0 D/C FALSE 0 1

(24)

Ke

butuhan

Pemodelan Berorientasi

Objek

(25)

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

odelan

kay

asa

Ke

(26)

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

Ke

(27)

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

(28)

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)

Ke

butuhan Nama Objek

(29)

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

odelan

kay

asa

Ke

(30)

Object & Class

Ke butuhan Mahasiswa - NIM - Nama - Buat skripsi - Ujian Mahasiswa - NIM : 001 - Nama : Andi Mahasiswa : Andi Mahasiswa - NIM : 002 - Nama : Eko Mahasiswa : Eko Mahasiswa - NIM : 003 - Nama : Susi Mahasiswa : Susi Instansiasi : penciptaan objek

(31)

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 odelan kay asa Ke butuhan

(32)

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

Ke

(33)

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. odelan kay asa Ke butuhan

(34)

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

Ke

(35)

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

odelan

kay

asa

Ke

(36)

Use Case Diagram

Ke

butuhan

Select product

Get return coins Customer

(37)

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 _{1. The customer selects a button product.}

2. The system displays an entry prompt of number of product to order.

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

(38)

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 case plays an optional use-case

Ke

(39)

Use Case Association

(40)

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

Ke

(41)

Actor Generalization

(42)

Class Diagram

 Menggambarkan struktur statis dari sistem

 Terdiri dari node (klas) dan relasi

 Jenis relasi

 Generalization (‘is a’ – inheritance)  Association

 Aggregation (‘part-of’)  Composition

Ke

(43)

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?

odelan

kay

asa

Ke

(44)

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)

Ke

(45)

Class Relationships

(46)

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

Ke

(47)

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

odelan

kay

asa

Ke

(48)

Class Stereotypes

Ke

butuhan

_{Model interaction between the system and its environment}

Actor 1 <<boundary>>

<<control>>

<<boundary>>

<<entity>> <<entity>>

(49)

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

odelan

kay

asa

Ke

(50)

(51)

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

odelan

kay

asa

Ke

(52)

Statechart Diagram

Ke butuhan Waiting for a coin Waiting for selection Dispensing 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