Analisis Model Perangkat Lunak

(1)

Analisis Model

Perangkat Lunak

(2)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by

2 Analisis Kebutuhan



Analisis Kebutuhan



Menentukan karakteristik operasional PL



Menunjukkan antarmuka PL dengan elemen sistem yang lain



Membuat batasan yang harus dipenuhi PL



Analisis Kebutuhan memungkinkan Software Engineer (disebut

analis atau modeler) untuk :



Memperinci kebutuhan dasar yang dibuat kapda rekayasa kebutuhan

sebelumnya



Membangun model yang dapat menggambarkan skenario user, aktivitas

fungsional, class masalah dan relasinya, sistem dan perilaku class, dan aliran

data ketika ditransformasikan.

(3)

3 Sebuah Jembatan

system

description

analysis

model

design

model

(4)

4 Aturan-Aturan



Model harus fokus pada masalah atau domain bisnis.

Tingkat abstraksinya relatif harus lebih tinggi.



Setiap elemen model analisis sebaiknya memberikan

tambahan pada pemahaman keseluruhan kebutuhan PL

dan menyediakan wawasan pada domain informasi, fungsi

dan perilaku sistem.



Tunda semua konsideran infrastruktur dan model non

fungsional hingga fase desain.



Minimalisasi coupling melalui sistem.



Pastikan model analisis menyediakan nilai untuk semua

stakeholder.

(5)

5 Analisis Domain

Analisis domain PL adalah identifikasi, analisis, dan

spesifikasi kebutuhan umum dari domain aplikasi

tertentu, yang biasanya digunakan kembali pada

project lain di dalam domain aplikasi yang sama

[Analisis domain berorientasi objek adalah] identifikasi,

analisis dan spesifikasi kemampuan umum,

kemampuan digunakan kembali dalam domain tertentu

dalam istilah-istilah objek, class, subassemblies dan

framework umum

(6)

6 Analisis Domain



Tentukan domain yang ingin diinvestigasi.



Kumpulkan contoh representatif aplikasi pada

domain tersebut.



_{Analisis setiap aplikasi pada contoh.}

(7)

7 Pemodelan Data



Memeriksa objek data secara

independen terhadap proses



Fokus perhatikan pada domain data



Membuat sebuah model pada abstraksi

level konsumen



Mengindikasikan bagaimana objek data

(8)

(9)

9 Model berbasis Scenario

“[Use-cases] adalah bantuan untuk mendefinisikan apa

yang ada pada sistem (aktor) dan apa yang harus

dilakukan sistem (use-cases).” Ivar Jacobson

(1) Apa yang harus ditulis?

(2) Berapa banyak kita harus menulisnya?

(3) Sedetail apa gambaran kita ?

(10)

10 Use-Cases



Sebuah skenario yang menggambarkan rangkaian

kegunaan pada sistem



actors

mewakili peran orang atau piranti yang dimaikan

ketika sistem berfungsi



users

dapat berperan sebagai lebih dari satu peran dalam

(11)

11 Mengembangkan Use-Case



Apa tugas atau fungsi utama yang harus dilakukan aktor ?



Sistem Informasi seperti apa yang diperlukan, dihasilkan

atau diubah oleh aktor ?



Apakah aktor harus menginformasikan sistem tentang

perubahan dalam lingkungan eksternal?



_{Informasi apa yang diharapkan aktor dari sistem?}



_{Apakah aktor menginginkan diberitahu tentang perubahan}

(12)

(13)

13

(14)

14 Activity Diagram

Melengkapi use-case dengan menyediakan representasi diagram

dari aliran prosedural.

(15)

15 Swimlane Diagrams

Memungkinkan untuk menampilkan aliran aktivitas yang digambarkan oleh use-case, dan di

saat yang sama mengindikasikan aktor yang mana, atau class analisis yang mempunyai

tanggungjawab terhadap tindakan yang digambarkan oleh kotak aktivitas

(16)

16 What is a Data Object?

Object

—something that is described by a set

of attributes (data items) and that will be

manipulated within the software (system)

each instance of an object (e.g., a book)

can be identified uniquely (e.g., ISBN #)

each plays a necessary role in the system

i.e., the system could not function without

access to instances of the object

each is described by attributes that are

themselves data items

(17)

17 Objek-Objek Umum

Entitas eksternal

(printer, user, sensor)

Sesuatu

(laporan, display, sinyal)

Kejadian atau event

(interupsi, alarm)

orang

(manager, engineer, salesperson)

Unit organisasi

(divisi, tim)

tempat

(lantai pabrik)

(18)

18 Objek Data dan Atribut

Sebuah objek data terdiri dari sekumpulan

atribut yang bertindak sebagai aspek,

kualitas, karakteristik, atau penjelas objek

object: automobile

attributes:

make

model

body type

price

options code

(19)

19 Apakah Relationship?

Relationship – menandakan kaitan, sebuah fakta yang

harus diingat oleh sistem, tidak dikomputasi atau

diturunkan secara mekanis



several instances of a relationship can exist



objects can be related in many different ways

(20)

20 Notasi ERD

(0, m)

(1, 1)

object

relationship

_object

1

2 Satu bentuk umum:

(0, m)

(1, 1)

object

₁

relationship

_object

₂

Bentuk Umum yang lain:

(21)

21 Membangun Sebuah ERD



Level 1—modelkan semua objek data (entitas) dan

koneksinya dengan yang lain



Level 2—modelkan semua entitas dan relasi



Level 3—modelkan semua entitas, relasi, dan atribut yang

(22)

22 ERD: sebuah contoh

(1,1)

places

_(1,m)

Customer

request

for service

generates

(1,n)

(1,1)

work

order

work

tasks

materials

consists

of

lists

(1,1)

(1,w)

(1,1)

(1,i)

selected

from

standard

task table

(1,w)

(1,1)

(23)

23 Pemodelan berorientasi aliran

Menampilkan bagaimana objek data ditransformasi ketika

mereka bergerak di dalam sistem

Sebuah

data flow diagram (DFD)

merupakan bentuk

diagram yang digunakan

Walaupun dianggap pendekatan kuno, pemodelan

berorientasi aliran menyediakan pandangan unik

terhadap suatu sistem. Dia tetap layak digunakan untuk

mendukung analisis elemen model lainnya.

(24)

24 Model Aliran

Setiap sistem berbasis komputer

Adalah sebuah transformasi informasi

computer

based

system

(25)

25 Notasi Model Aliran

Entitas Eksternal

proses

Aliran data

(26)

26 Entitas Eksternal

Produsen atau konsumen sebuah data

Contoh : seseorang, piranti, sensor

Contoh lain : sistem berbasis komputer

Data harus selalu berawal dari suatu tempat dan

Harus selalu dikirim pada sesuatu

(27)

27 Proses

Sebuah transformer data

(mengubah input menjadi output)

Contoh: menghitung pajak, menentukan luas,

Memformat laporan, menampilkan grafik

Data harus selalu diproses dalam bentuk tertentu

Untuk menerima fungsi sistem

(28)

28 Aliran Data

Data mengalir melalui sebuah sistem dimulai

Sebagai input dan ditransformasi menjadi

output

compute

triangle

area

base

height

area

(29)

29 Menyimpan Data

Data disimpan untuk digunakan lagi.

look-up

sensor

data

sensor #

report required

sensor #, type,

location, age

sensor data

sensor number

type,

location, age

(30)

30 Petunjuk menggambar DFD



Semua icon harus diberi nama yang bermakna

jelas



DFD berkembang dalam beberapa tingkatan



Selalu dimulai dengan sebuah context level

diagram (level 0)



Selalu menunjukkan entitas eksternal pada level 0



Selalu berinama panah aliran data

(31)

31 Membangun sebuah DFD—I



Mereview model data untuk mengisolasi objek data dan

gunakan parsing gramatikal untuk menentukan “Operasi”



_{Menentukan entitas eksternal (produsen dan konsumen}

data)

(32)

32 Contoh Level 0 DFD

user

processing

request

video

source

_{video signal}

NTSC

digital

video

processor

requested

video

signal

monitor

(33)

33 Membangun DFD—II



Tulis sebuah narasi yang menggambarkan

transformasi



Parsing untuk menentukan transformasi tingkat

berikutnya



“seimbangkan” aliran untuk menjaga aliran data



Bangun level 1 DFD

(34)

34 Hierarki Aliran Datang

P

a

b

x

y

p1

p2

p3

p4

₅

a

b

c

d

e

f

g

level 0

level 1

(35)

35 Catatan untuk DFD



Setiap lingkaran harus dipecah hingga dia hanya

melakukan hanya SATU hal



Rasio ekspansi menurun sesuai dengan jumlah

level yang meningkat



Kebanyakan sistem membutuhkan antara 3

hingga level 7 untuk model aliran yang cukup.



_{Sebuah item aliran data (panah) dapat}

dikembangkan seiring dengan meningkatnya

level (data dictionary menyediakan informasi ini)

(36)

36 Spesifikasi Proses (PSPEC)

PSPEC

naratif

pseudocode (PDL)

persamaan

tabel

Diagram dan atau grafik

(37)

37

Maps into

Setelah DFD?

analysis model

(38)

(39)

(40)

(41)