Analisis Kebutuhan 1

 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.
Sebuah Jembatan 2

system
description

analysis
model

design
model
 Aturan-Aturan 3

 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.
 Analisis Domain 4

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
 Analisis Domain 5

 Tentukan domain yang ingin diinvestigasi.

 Kumpulkan contoh representatif aplikasi pada domain tersebut.
 Analisis setiap aplikasi pada contoh.
 Kembangkan model analisis untuk objek.
Pemodelan Data 6

 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
 7
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
 8
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)
Objek Data dan Atribut 9

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
 Apakah Relationship? 10

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
Notasi ERD 11

Satu bentuk umum:

(0, m)
object 1 relationship object 2
(1, 1)

attribute
Bentuk Umum yang lain:

object 1 relationship
object 2
(0, m) (1, 1)
ERD: sebuah contoh 12

request
Customer places
(1,1) (1,m) for service
(1,1)
standard generates (1,n) work
task table order
(1,1) (1,1) (1,1)
selected work (1,w) consists
from (1,w) tasks of

(1,i)
materials lists
Konsep Object-Oriented 13

 Harus dipahami untuk menerapkan elemen berbasis class pada model

analisis
 Konsep-konsep kunci:
 Classes dan objects
 Attributes dan operations
 Encapsulation dan instantiation
 Inheritance
 Class 14
• 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
 Membangun Class 15
class name

attributes:

operations

attributes:
operations:
 Apakah Class? 16
occurrences roles
things organizational units
places
external entities
structures

class name
attributes:

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

method
method #3
#6

method method
#5 #4

Achieves “information hiding”

 Hierarki Class 18
PieceOfFurniture (superclass)

Table Chair Desk ”Chable"

subclasses of the

instances of Chair
 Method 19
(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
Model berbasis Scenario 20

“[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?
 Use-Cases 21

 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
 Mengembangkan Use-Case 22
 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?
Use-Case Diagram
23
Saf e Ho m e

Acce s s cam e ra
s u rve illan ce via t h e cam e ras
Int e rn e t

Co n fig u re Safe Hom e

s ys t e m param e t e rs

h o m e o wn e r

Se t alarm
 Activity Diagram
24
Melengkapi use-case dengan menyediakan representasi diagram
dari aliran prosedural.

e n t e r p a ssw ord
a n d u se r ID

valid pas s wor ds / ID invalid pas s wor ds / ID

se le c t ma jo r func t ion prompt fo r re e n t ry

ot her f unct ions
m ay als o be
s elect ed
input t r ies r em ain
se le c t su rve illa n c e
no input
t r ies r em ain

t hum bnail views s elect a s pecif ic cam er a

se le c t sp e c ific
se le c t c a me ra ic o n
c a me ra - t hu mb n a ils

vie w c a me ra o ut pu t
in la be lle d win do w

p ro mp t for
a n ot h e r vie w

exit t his f unct ion s ee anot her cam er a

 Swimlane Diagrams
25
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
home owne r c a m e ra i n t e rf a c e

e n t e r pa s s wo rd
a nd u s e r ID

valid p as s wo r d s/ ID
in valid
p as s wo r d s / ID
s e le c t m a jo r fu n c t ion

o t h er f u n ct io n s pro m p t fo r re e n t ry
m ay als o b e
s elect ed

in p u t t r ies
s e le c t s urv e illa nc e r em ain

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

t h u m b n ail views s elect a s p ecif ic cam er a

s e le c t s pe c ific
s e le c t c a m e ra ic on
c a m e ra - t h um b na ils

g e n e ra t e v ide o
ou t p ut

v ie w c a m e ra ou t put p ro m p t fo r
in la b e lle d wind ow a no t h e r vie w

exit t h is
f u n ct io n

see
an o t h er
cam er a
 26
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.
Model Aliran 27

Setiap sistem berbasis komputer

Adalah sebuah transformasi informasi

computer
input based output
system
Notasi Model Aliran 28

Entitas Eksternal

proses

Aliran data

Penyimpanan data
Entitas Eksternal 29

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
Proses 30

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
Aliran Data 31

Data mengalir melalui sebuah sistem dimulai

Sebagai input dan ditransformasi menjadi
output
base
compute
area
triangle
height area
Menyimpan Data 32

Data disimpan untuk digunakan lagi.

sensor #
sensor #, type,
look-up location, age
sensor
report required data
type,
location, age
sensor number

sensor data
Petunjuk menggambar DFD 33

 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
Membangun sebuah DFD—I 34

 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
Contoh Level 0 DFD 35

processing
user request requested
video
digital signal
video monitor
processor
video
source NTSC
video signal
Membangun DFD—II 36

 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)
Hierarki Aliran Datang 37

a b
x P y level 0

a c p2
p1
f

d p4 5 b
p3 e g
level 1
Catatan untuk DFD 38

 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)
Spesifikasi Proses (PSPEC) 39
Lingkaran

PSPEC
naratif
pseudocode (PDL)
persamaan
tabel
Diagram dan atau grafik
Setelah DFD? 40

analysis model
Maps into
design model
 Control Flow Diagram 41

 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.
Model Kendali 42

• 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
 Control Flow Diagram 43
copies done
beeper on/off full
read
operator
input problem
manage
start copying light

empty
reload create
process user
displays

perform
problem
diagnosis

display panel enabled

jammed
Control Specification (CSPEC) 44

CSPEC dapat berupa:

state diagram
(sequential spec)

state transition table

combinatorial spec
decision tables

activation tables
Panduan Membangun CSPEC 45
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?"
Pemodelan berbasis Class 46

 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
 Class Analisis 47
 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
Kriteria memilih class 48

Menyimpan informasi
Layanan yang dibutuhkan
Beberapa atribut
Atribut umum
Operasi umum
Kebutuhan esensial
 Class Diagram 49
Class name
System
systemID
verificationPhoneNumber
systemStatus attributes
delayTime
telephoneNumber
masterPassword
temporaryPassword
numberTries

program()
display()
reset()
query() operations
modify()
call()
Class Diagram
50
Flo o rPlan
type
name
outs ideDimensions

determineType ( )
pos itionFloorplan
s cale( )
change color( )

is pla c e d wit hin

is pa rt of

Ca m e ra Wa ll

t yp e t yp e
ID wa llDim e n s io ns
lo c a t io n
fie ld Vie w
p a n An gle
Zo o m Se t t in g
determineType ( )
d e t e rm in e Ty p e ()
computeDimensions ( )
t ra n s la t e Lo c a t io n ()
d is p la y ID()
d is p la y Vie w()
d is p la y Zoo m ()
is us e d t o build is us e d t o build

is us e d t o build

Wa llSe gm e nt Window Door

type type t y pe
s t a rt Co o rd in a t e s s t a rt Coo rd in a t e s s t a rt Co ordina t e s
s t o p Co ord in a t e s s t o pCoo rd ina t e s s t op Co ordin a t e s
n e xt Wa llSe m e nt n e x t Win do w ne xt Do or

determineType ( ) determineType ( ) determineType ( )

draw( ) draw( ) draw( )
 Pemodelan CRC 51

 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.
 Pemodelan CRC 52

Class:
Class:
Description:
Class:
Description:
Class: FloorPlan
Description:
Responsibility:
Description: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
defines floor plan name/type
manages floor plan positioning
scales floor plan for display
scales floor plan for display
incorporates walls, doors and windows Wall
shows position of video cameras Camera
 Tipe-tipe Class
53
 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.
 Responsibilities 54

 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.
 Kolaborasi 55

 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
Composite Aggregate Class 56

Player

PlayerHead PlayerBody PlayerArms PlayerLegs

 Review model CRC
57
 Semua peserta dalam review (model CRC) diberikan sebuah subset dari kartu index model CRC.
 Kartu yang berkolaborasi harus terpisah (tidak boleh ada reviewer yang memiliki dua kartu yang
berkolaborasi).
 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.
 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.
Asosiasi dan Dependensi 58

 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
 Multiplicity
59

Wa ll

1 1 1

is used to build is used to build

1..* 0..* is used to build 0..*

Wa llSe g m e n t Win d o w Do o r
Dependencies 60

DisplayWindow Camera

<<access>>

{password}
 Analisis Paket 61

 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.
Analysis Packages
62
p ackag e n ame

En viro nm e n t
+Tree
+Landscape
+Road
+Wall
+Bridge
+Building Rule s OfThe Gam e
+VisualEffect
+Scene +RulesOfMovement
+ConstraintsOnAction

Charact e rs

+Player
+Protagonist
+Antagonist
+SupportingRole
 Pemodelan Perilaku 63

 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
 Representasi Keadaan 64

 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.
State Diagram for the ControlPanel Class
65
t ime r < lo cke d Time

t ime r > lo cke d Time lo cke d

p as s wo rd = in co rre ct
& n u mb e rOfTrie s < maxTrie s

re ad in g co mp arin g n u mb e rOfTrie s > maxTrie s

ke y h it
p as s wo rd
e n t e re d do: va lida t e Pa s s w ord
p as s wo rd = co rre ct

s e le ct in g

act iv at io n s u cce s s fu l
Keadaan-Keadaan Sistem 66

 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
Sequence Diagram
67

h o meo w n er co n t ro l p an el s ys t em ssen
enssoors
rs

read in g
s ys t em A
read y
p as s w o rd en t ered

req u es t lo o ku p
co mp arin g

res u lt

p a s s wo rd = c orre c t
n um b e rOfTrie s > m a x Trie s req u es t act ivat io n
lo cked

t imer > lo cked Time

A

s elect in g

act ivat io n s u cces s fu l act ivat io n s u cces s fu l

Figure 8 .2 7 Se que nc e dia gra m (pa rt ia l) for Saf e Hom e s e c urit y func t ion