Catatan Kuliah Rekayasa Perangkat Lunak (Software Engineering) Bagian 2

Catatan Kuliah

Rekayasa Perangkat Lunak (Software Engineering) Bagian 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 R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

1

Software Engineering: A Practitioner’s Approach, 6/e

Chapter 8 Pemodelan Analisis copyright © 1996, 2001, 2005

R.S. Pressman & Associates, Inc. M. Idham Ananta Timur, S.T., M.Kom For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.


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

Sebuah Jembatan syste m de scription

analysis mode l

de sign mode l


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 rangkaian melalui sistem. Pastikan model analisis menyediakan nilai untuk semua stakeholder. Jaga model sesederhana mungkin.


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 Donald Firesmith


6

Analisis Domain 



 

Tentukan domain yang ingin diinvestigasi. Kumpulkan contoh representatif aplikasi pada domain tersebut. Analisis setiap aplikasi pada contoh. Kembangkan model analisis untuk objek.


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 berhubungan satu dengan yang lain


8

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 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

9

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) struktur (employee record)


10

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


11

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


12

Notasi ERD Satu bentuk umum: object1

(0, m)

relationship

(1, 1)

object 2 attribute

Bentuk Umum yang lain: relationship

object1 (0, m)

(1, 1)

object 2


13

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 menyediakan informasi yang lebih mendalam


14

ERD: sebuah contoh Customer

(1,1)

places

(1,m)

request for service (1,1)

standard task table

generates

(1,1) selected from

work (1,w) tasks materials

(1,w) (1,i)

(1,n)

work order

(1,1)

(1,1)

consists of

lists


15

Konsep Object-Oriented 



Harus dipahami untuk menerapkan elemen berbasis class pada model analisis Konsep-konsep kunci:    

Classes dan objects Attributes dan operations Encapsulation dan instantiation Inheritance


16

Class •

Pemikiran object-oriented dimulai dengan sebuah class, sering didefinisi sebagai : – – –

•

•

template deskripsi umum ―blueprint‖ ... Menggambarkan sekelompok item yang mirip

sebuah metaclass (sering disebut superclass)yang membangun hierarki semua class yang ada Sekali sebuah class item ditentukan, instance spesifik dari class tersebut dapat diidentifikasi


17

Membangun Class


18

Apakah Class? occurrences

roles organizational units

things

places structures

external entities

class name attributes:

operations:


19

Enkapuslasi/Penyembunyian Objek mengenkapsulasi Baik data dan prosedur Logis yang dibutuhkan method Untuk manipulasi #1 data

method #2 data

method #3

method #6

method #5

method #4

Achieves ―information hiding‖ These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

20

Hierarki Class PieceOfFurniture (superclass)

Table

Chair

Desk

”Chable"

subclasses of the

instances of Chair These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

21

Method (Operasi, Layanan) Prosedur yang terenkapsulasi pada sebuah class dan didesain untuk beroperasi pada satu atau lebih atribut data yang ditentukan sebagai bagian dari class. Method dipanggil melalui pesan


22

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 ? (4) Bagaimana kita mengatur deskripsi?


23

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 sebuah skenario yang ditentukan


24

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 yang tidak tersangka?


25

Use-Case Diagram Saf eHome

Access camera surveillance via t he Int ernet

cameras

Conf igure Saf eHome syst em paramet ers homeowner

Set alarm


26

Activity Diagram Melengkapi use-case dengan menyediakan representasi diagram dari aliran prosedural. ent er password and user ID

valid passwor ds/ ID

invalid passwor ds/ ID

selec t major f unct ion

prompt f or reent ry

ot her f unct ions m ay also be select ed input t r ies r em ain

select surv eillanc e no input t r ies r em ain

t hum bnail views

select a specif ic cam er a

selec t specif ic c amera - t humbnails

select c amera ic on

v iew camera out put in labelled window

prompt f or anot her v iew

exit t his f unct ion

see anot her cam er a


27

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 homeowner

c a m e ra

i n t e rf a c e

ent er password and user ID

valid p asswo r d s/ ID in valid p asswo r d s/ ID

select m ajor f unct ion o t h er f u n ct io n s m ay also b e select ed

prom pt f or reent ry

in p u t t r ies r em ain

select surveillance n o in p u t t r ies r em ain

t h u m b n ail views

select a sp ecif ic cam er a

select spec if ic cam era - t hum bnails

select cam era icon

generat e video out put view cam era out put in labelled window

prom pt f or anot her view

exit t h is f u n ct io n see an o t h er cam er a


28

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.


29

Model Aliran Setiap sistem berbasis komputer Adalah sebuah transformasi informasi

input

computer based system

output


30

Notasi Model Aliran Entitas Eksternal

proses Aliran data

Penyimpanan data These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

31

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


32

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


33

Aliran Data Data mengalir melalui sebuah sistem dimulai Sebagai input dan ditransformasi menjadi output base

height

compute triangle area

area


34

Menyimpan Data Data disimpan untuk digunakan lagi. sensor #

report required

look-up sensor data sensor number

sensor #, type, location, age

type, location, age sensor data


35

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 Jangan menampilkan prosedur logika


36

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) Membuat level 0 DFD


37

Contoh Level 0 DFD user

processing request

digital video processor video source

requested video signal

monitor

NTSC video signal


38

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 Gunakan rasio 1:5 (perkiraan)


39

Hierarki Aliran Datang x

a

a

b

P

c

p2

level 1

p4 p3

level 0

f

p1

d

y

e

g

5

b


40

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)


41

Spesifikasi Proses (PSPEC) Lingkaran

PSPEC naratif pseudocode (PDL) persamaan tabel Diagram dan atau grafik


42

Setelah DFD?

analysis model

Maps into

design model


43

Control Flow Diagram 



Menggambarkan ―events‖ dan proses yang mengelola event Sebuah ―event‖ adalah kondisi boolean yang dipastikan dengan :    



Mendaftar semua sensor yang dibaca oleh software. Mendaftar semua kondisi interupsi. Mendaftar semua "switches" yang dipicu oleh sebuah operator. Mendaftar semua kondisi data. Memanggil kembali parser kata benda/kerja yang diaplikasikan pada narasi proses, mereview semua ―item kendali‖ sebagai input/output CSPEC.


44

Model Kendali •

• • • • •

•

control flow diagram berada ―di atas‖ DFD dan menunjukkan event yang mengendalikan proses-proses yang terdapat pada DFD Aliran kendali—event dan item kendali– ditandai dengan panah putus-putus Sebuah tiang vertikal menggambarkan input menuju atau output dari sebuah control spec (CSPEC) — spesifikasi terpisah yang menggambarkan bagaimana kendali ditangani Sebuah panah putus-putus memasuki tiang vertikal adalah input menuju CSPEC Sebuah panah putus-putus meninggalkan proses menggambarkan kondisi data Sebuah panah putus-patas memasuki sebuah proses menggambarkan sebuah kendali input yang dibaca langsung oleh proses Aliran kendali tidak secara fisik mengaktifkan/menonaktifkan proses, hal ini dilakukan melalui CSPEC


45

Control Flow Diagram copies done beeper on/off read operator input

start

empty

problem light

manage copying

reload process

full

create user displays

perform problem diagnosis

display panel enabled jammed These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

46

Control Specification (CSPEC) CSPEC dapat berupa: state diagram (sequential spec) state transition table

combinatorial spec

decision tables activation tables


47

Panduan Membangun CSPEC Lihat semua sensor yang ―dibaca‖ oleh PL Lihat semua kondisi interupsi Lihat semua "switches" yang diaktifkan oleh operator Lihat semua kondisi data

Melihat parsing kata benda/kerja yang diterapkan pada Statemen software atau lingkupnya, mereview semua item kendali Sebagai input/output CSPEC yang mungkin Menggambarkan perilaku sebuah sistem dengan identifikasi Keadaan; menentukan bagaimana setiap keadaan mencapai dan Menentukan transisi antar keadaan

Fokus pada kemungkinan kehilangan/tidak tercantum... Kesalahan umum dalam menentukan kendali, misalnya "Is there any other way I can get to this state or exit from it?" These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

48

Pemodelan berbasis Class 



 

Tentukan analisis class dengan memeriksa pernyataan masalah(problem statement) Gunakan parsing gramatikal untuk memilah class potensial Kenali atribut tiap class Kenali operasi yang memanipulasi atribut-atribut tersebut


49

Class Analisis 

    



Entitias external (contoh : sistem lain, piranti, orang) yang menghasilkan atau menggunakan informasi yang digunakan oleh sistem berbasis komputer. Benda (contoh : laporan, display, surat, sinyal) yang merupakan bagian dari domain informasi untuk masalah. Kejadian atau event (contoh : transfer properti atau pelengkapan urutan gerakan robot) yang terjadi di dalam konteks sistem operasi. Peran (contoh : manajer, insinyur, sales) yang diperankan orang yang berinteraksi dengan sistem. Unit Organisasi (contoh : divisi, kelompok, tim) yang relevan terhadap aplikasi. Tempat (contoh : lantai pabrik, pelabuhan muatan) yang membangun konteks masalah dan fungsi keseluruhan sistem. Struktur (contoh : sensor, kendaraan 4WD, komputer) yang terdiri dari beberapa objek class atau objek-objek class yang terkait


50

Kriteria memilih class Menyimpan informasi Layanan yang dibutuhkan Beberapa atribut

Atribut umum Operasi umum

Kebutuhan esensial


51

Class Diagram Class name System sy stemID verificationPhoneNumber sy stemStatus dela yTime telephoneNumber masterPassw ord temporaryPass word numberTrie s

program() displa y() reset() query() modif y() call()

attributes

operations


52

Class Diagram FloorPlan type name outsideDimensions

determineType ( ) positionFloorplan scale( ) change color( )

is placed wit hin is part of

Cam era

Wall

t ype ID loc at ion f ieldV iew panA ngle Zoom Set t ing

t y pe wallDim ens ions

determineType ( ) computeDimensions ( )

det erm ineType () t rans lat eLocat ion () dis playID() dis playV iew() dis playZoom ()

is used t o build

is used t o build is used t o build

WallSegm ent t ype s t art Coordinat es s t opCoordinat es nex t WallSem ent

determineType ( ) draw( )

Window

Door

t ype st art Coordinat es st opCoordinat es next Window

t y pe st art Coordinat es st opCoordinat es next Door




53

Pemodelan CRC 

Class-class analisis memiliki ―tanggung-jawab‖ 



Tanggungjawab adalah atribut-atribut dan operasi-operasi yang terenkapsulasi oleh class

Class-class analisis berkolaborasi satu dengan yang lain 



Collaborators adalah class-class yang dibutuhkan untuk menyediakan sebuah class dengan informasi yang dibutuhkan untuk memenuhi tanggung jawabnya. Secara umum, sebuah kolaborasi berakibat permintaan informasi atau permintaan beberapa aksi/operasi.


54

Pemodelan CRC Clas s: Clas s: Description: Clas s: Description: Clas s:FloorPlan Description: Re sponsibility: Description: Re sponsibility: Re sponsibility: Re sponsibility:

Collaborator: Collaborator: Collaborator: Collaborator:

defines floor plan name/type manages floor plan positioning scales f loor plan for display scales f loor plan for display incorporates w alls, doors and w indow s

Wall

show s position of video cameras

Camera


55

Tipe-tipe Class 

Class entitas, sering disebut class model atau bisnis, yang diekstrak langsung dari statemen permasalahan (contoh : Sensor).



Class perbatasan digunakan untuk membuat interface (contoh : layar interaktif, atau laporan cetak) dimana user melihat dan berinteraksi dengannya selama PL digunakan. Class kendali mengelola “unit kerja [UML03] dari awal sampai akhir. Class kendali dapat didesain mengelola :



   

Pembuatan atau update objek entitas; Inisiasi objek perbatasan sebagaimana mereka mendapatkan informasi dari objek entitas; Komunikasi kompleks antara sekumpulan objek; Validasi data yang dikomunikasikan antara user dan aplikasi.


56

Responsibilities    



System intelligence should be distributed across classes to best address the needs of the problem Each responsibility should be stated as generally as possible Information and the behavior related to it should reside within the same class Information about one thing should be localized with a single class, not distributed across multiple classes. Responsibilities should be shared among related classes, when appropriate.


57

Kolaborasi 

Class memenuhi tanggung jawabnya dengan satu diantara dua cara :  



 

Sebuah class dapat menggunakan operasinya sendiri untuk memanipulasi atributnya masing-masing atau Sebuah class dapat berkolaborasi dengan class lainnya.

Kolaborasi membuat relasi antara class Kolaborasi dapat diidentifikasi dengan menentukan apakah sebuah class dapat memenuhi tanggung jawabnya masing-masing Tiga relasi umum yang berbeda antar class [WIR90]:   

is-part-of relationship has-knowledge-of relationship depends-upon relationship


58

Composite Aggregate Class Player

PlayerHea d

PlayerBod y

PlayerArms

PlayerLe gs


59

Review model CRC 

Semua peserta dalam review (model CRC) diberikan sebuah subset dari kartu index model CRC. 

 

Semua skenario use-case (dan diagram use case terkait) harus diorganisasi dalam kategori-kategori. Pemimpin review membaca use-case secara hati-hati. 



Ketika pemimpin review sampai pada objek, dia akan memberi tanda kepada person yang memegang kartu index class yang terkait.

Ketika tanda dikirimkan, pemilik kartu class diminta untuk menggambarkan tanggung jawab yang tertulis di kartu tersebut. 



Kartu yang berkolaborasi harus terpisah (tidak boleh ada reviewer yang memiliki dua kartu yang berkolaborasi).

Kelompok menentukan satu (atau lebih) tanggung jawab yang memenuhi kebutuhan use-case.

Jika tanggung jawab dan kolaborasi yang tertera pada kartu index tidak dapat mengakomodasi use-case, modifikasi dilakukan pada kartu tersebut. 

Hal ini termasuk definisi class baru (dan kartu index CRC) atau spesifikasi baru atau revisi mengenai tanggung jawab, atau kolaborasi kartu yang sudah ada.


60

Asosiasi dan Dependensi 

Dua class analisis sering berhubungan satu dengan yang lain dalam beberapa pola  



Dalam UML relasi ini sering disebut asosiasi Asosiasi dapat didapatkan dengan mengenali multiplicity (istilah cardinality digunaikan dalam pemodelan data

Dalam banyak instans, relasi client-server ada diantara dua class analisis. 

Dalam kasus ini, class client tergantung pada class server dalam suatu cara dan relasi dependensi terjadi


61

Multiplicity Wall

1

1

is used to build

is used to build

1..* WallSegm ent

1

0..* Window

is used to build

0..*

Door


62

Dependencies

Camera

Displa yWindow <> {passw ord}


63

Analisis Paket 





Beberapa model analisis (use-case, class analisis) dikategorisasi dalam sebuah pola yang mempaketkan mereka dalam kelompok Tanda plus di dalam nama class analisis dalam setiap paket menandakan bahwa class-class tersebut mempunyai visibilitas publik dan karena itu dapat diakses dari paket lain. Simbol lain dapat mendahului elemen di dalam paket. Tanda minus menandakan bahwa elemen disembunyikan dari semua paket, dan tanda # menandakan bahwa elemen hanya dapat diakses oleh paket yang berada di dalam paket tersebut.


64

Analysis Packages package name

Environment +Tree +Landscape +Road +Wall +Bridge +Building +VisualEffect +Scene

RulesOf TheGame +RulesOfMovement +ConstraintsOnAction

Charact ers +Player +Protagonist +Antagonist +SupportingRole


65

Pemodelan Perilaku 

Model perilaku menggambarkan bagaimana PL merespon event atau stimulan eksternal. Untuk model tersebut, analis harus melakukan langkah-langkah berikut : 



  

Evaluasi semua use-case untuk mendapatkan pemahaman menyeluruh tentang urutan interaksi di dalam sistem. Mengenali event yang mengendalikan urutan interaksi dan memahamibagaimana event mempunyai relasi terhadap objek spesifik. Membuat urutan untuk setiap use-case. Membangun state diagram untuk sistem. Review model behavioral untuk memverifikasi akurasi dan konsistensi


66

Representasi Keadaan 

Dalam konteks pemodelan perilaku, dua karakter keadaan harus diperhatikan :  



Keadaan setiap class ketika sistem menjalankan fungsinya, dan Keadaan sistem ketika diobservasi dari luar sebagaimana sistem menjalankan fungsinya.

Keadaan class mengambil baik karakter aktif maupun pasif [CHA93]. 



Sebuah keadaan pasif adalah status saat ini dari semua atribut objek. Keadaan aktif dari sebuah objek menggambarkan status saat ini pada objek tersebut ketika menjalankan transformasi atau proses.


67

State Diagram for the ControlPanel Class t imer < lockedTime

t imer > lockedTime

locked

password = incorrect & numberOfTries < maxTries comparing

reading

numberOfTries > maxTries

key hit password ent ered

do: validat ePassw ord

password = correct

select ing

act iv at ion successful


68

Keadaan-Keadaan Sistem 

 



state—sekumpulan keadaan terobservasi yang menggambarkan perilaku sistem pada satu waktu state transition—perubahan dari satu keadaan ke keadaan yang lain event—sebuah kejadian yang menyebabkan sistem melakukan perilaku yang sudah diprediksi sebelumnya action—proses yang terjadi sebagai konsekuensi membuat transisi


69

Pemodelan Perilaku  

Membuat daftar keadaan sistem yang berbeda (Bagaimana perilaku sistem ?) Menggambarkan bagaimana sistem membuat transisi dari satu keadaan ke keadaan yang lain.indicate how the system makes a transition from one state to another (Bagaimana sistem mengubah keadaan?) 





mengenali event Mengawali action

Menggambar sebuah state diagram atau sequence diagram


70

Sequence Diagram co n t ro l p an el

h o meo w n er

syst em read y

A

sen senso sors rs

syst em

read in g

p assw o rd en t ered req u est lo o ku p co mp arin g resu lt password = correct

req u est act ivat io n

num berOf Tries > m axTries

lo cked

A

t imer > lo cked Time

select in g act ivat io n su ccessfu l

Figure 8 .2 7 Sequence diagram (part ial) f or

act ivat io n su ccessfu l

Saf eHome securit y f unct ion


71

Menulis Spesifikasi PL Setiap orang harus tahu pasti apa yang harus dilakukan hingga seseorang menuliskannya !


72

Tugas 



Buatlah sebuah paper yang menjelaskan tentang UML beserta contoh kasusnya, minimal 15 halaman, spasi 1.5, kertas Quarto, sampul mika biru tua. Kriteria penilaian :   

Validitas/kebenaran Kelengkapan Kompleksitas kasus


73

Panduan Spesifikasi use a layered format that provides increasing detail as the "layers" deepen use consistent graphical notation and apply textual terms consistently (stay away from aliases) be sure to define all acronyms be sure to include a table of contents; ideally, include an index and/or a glossary write in a simple, unambiguous style (see "editing suggestions" on the following pages) always put yourself in the reader's position, "W ould I be able to understand this if I wasn't intimately familiar with the system?" These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

74

Panduan Spesifikasi Be on the lookout for persuasive connectors, ask why? keys: certainly, therefore, clearly, obviously, it follows that ... Watch out for vague terms keys: some, sometimes, often, usually,ordinarily, most, mostly ... When lists are given, but not completed, be sure all items are understood keys: etc., and so forth, and so on, such as Be sure stated ranges don't contain unstated assumptions e.g., Valid codes range from 10 to 100. Integer? Real? Hex? Beware of vague verbs such as handled, rejected, processed, ... Beware "passive voice" statements e.g., The parameters are initialized. By what? Beware "dangling" pronouns e.g., The I/O module communicated with the data validation module and its contol flag is set. Whose control flag?


75

Panduan Spesifikasi When a term is explicitly defined in one place, try substituting the definition forother occurrences of the term When a structure is described in words, draw a picture When a structure is described with a picture, try to redraw the picture to emphasize different elements of the structure When symbolic equations are used, try expressing their meaning in words When a calculation is specified, work at least two examples Look for statements that imply certainty, then ask for proof keys; always, every, all, none, never Search behind certainty statements—be sure restrictions or limitations are realistic These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

76

Catatan Kuliah Rekayasa Perangkat Lunak (Software Engineering) Bagian 2

Recommend Documents