real-time-systems-design-and-analysis-4th-edition 2[217-240].en.id

202
METODOLOGI TEKNIK PERSYARATAN
tidak dapat sepenuhnya ditransliterasikan ke dalam notasi matematika yang ketat dan aturan terkait. Spesifikasi informal yang
belum sempurna, seperti bagan alur, memiliki sedikit atau tidak ada struktur matematika / logis yang mendasarinya, dan
karenanya mereka tidak dapat sama sekali dianalisis. Dalam kasus bagan alur, struktur topologi secara matematis ketat - baik
urutan atau cabang - tetapi semantik dalam proses dan blok keputusan, biasanya dinyatakan menggunakan bahasa alami,
tidak. Semua yang dapat dilakukan dengan spesi fi kasi informal adalah menemukan contoh tandingan di mana sistem gagal
memenuhi persyaratan atau di mana ada konflik. Ini sama sekali tidak memadai untuk sebagian besar sistem waktu nyata, di
mana pembuktian formal dari karakteristik kinerja persyaratan diperlukan. Pendekatan terhadap persyaratan spesifikasi yang
menentang klasifikasi baik formal maupun informal disebut semiformal. Pendekatan semiformal, meskipun tidak tampak
sepenuhnya keras, mungkin. Sebagai contoh, beberapa berpendapat bahwa bahasa pemodelan terpadu (UML) adalah
semiformal, karena statechart bersifat formal sedangkan teknik metamodeling lain yang digunakannya memiliki dasar
pseudomathematical. Namun, yang lain berpendapat bahwa UML bahkan tidak semiformal, karena memiliki lubang dan
inkonsistensi yang serius - kritik berat ini hanya berlaku untuk UML 1.x saja. UML 2.x yang direvisi secara menyeluruh
mengandung komponen formal tambahan, dan ada niat serius untuk meresmikannya lebih jauh (Miles dan Hamilton, 2006).
Dalam kasus apa pun, UML sebagian besar menikmati keuntungan dari teknik informal dan formal dan secara luas digunakan
dalam spesifikasi dan desain sistem waktu nyata, karena mendukung transisi yang sedang berlangsung dari bahasa
pemrograman prosedural ke bahasa berorientasi objek. karena memiliki lubang dan inkonsistensi serius - kritik berat ini hanya
berlaku untuk UML 1.x. UML 2.x yang direvisi secara menyeluruh mengandung komponen formal tambahan, dan ada niat
serius untuk meresmikannya lebih jauh (Miles dan Hamilton, 2006). Dalam kasus apa pun, UML sebagian besar menikmati
keuntungan dari teknik formal dan informal dan banyak digunakan dalam spesifikasi dan desain sistem waktu nyata, karena
mendukung transisi yang sedang berlangsung dari bahasa pemrograman prosedural ke bahasa berorientasi objek. karena
memiliki lubang dan inkonsistensi serius - kritik berat ini hanya berlaku untuk UML 1.x. UML 2.x yang direvisi secara
menyeluruh mengandung komponen formal tambahan, dan ada niat serius untuk meresmikannya lebih jauh (Miles dan
Hamilton, 2006). Dalam kasus apa pun, UML sebagian besar menikmati keuntungan dari teknik formal dan informal dan banyak digunakan dalam s
5.2 METODE FORMAL DALAM SPESIFIKASI SISTEM
Metode formal berkontribusi secara signifikan terhadap perumusan persyaratan dan validasi dengan
menggunakan dan memperluas teknik matematika yang efektif (Liu,
2010). Dan praktik ini menjadi semakin layak dengan meningkatnya ketersediaan alat pendukung.
Teknik-teknik dan alat-alat terkait menggunakan beberapa kombinasi aljabar abstrak, matematika
diskrit, λ - kalkulus, teori bilangan, kalkulus predikat, semantik bahasa pemrograman, teori fungsi rekursif,
dan sebagainya. Salah satu manfaat utama dari metode formal adalah bahwa mereka memberikan
perspektif ilmiah yang tepat untuk spesifikasi sistem dan desain perangkat lunak. Persyaratan formal
menawarkan peluang untuk menemukan kesalahan pada tahap awal pengembangan, ketika kesalahan
dapat diperbaiki dengan lebih mudah dan dengan biaya yang lebih rendah. Di lain pihak, spesifikasi
informal mungkin tidak mendukung tujuan ini, karena meskipun dapat digunakan untuk menyangkal
persyaratan tertentu dengan contoh-contoh tandingan, contoh-contoh tandingan semacam itu mungkin
sulit dibuat.
Sesuai sifatnya, spesifikasi untuk sistem waktu-nyata biasanya berisi formalisme dalam
ekspresi matematis interaksi dengan lingkungan operasi atau dalam sistem di mana mereka
tertanam. Meskipun ini tidak membenarkan klaim bahwa setiap spesifikasi sistem waktu nyata
sepenuhnya
www.it-ebooks.info
METODE FORMAL DALAM SPESIFIKASI SISTEM
203
dapat diformalkan, hal itu mengarah pada optimisme tertentu bahwa sebagian besar sistem real-time cocok untuk,
setidaknya, formalisasi parsial.
Namun demikian, metode formal pada umumnya dianggap sulit untuk digunakan oleh bahkan
insinyur yang terlatih, dan mungkin rentan kesalahan jika digunakan tanpa alat berbasis komputer
yang tepat. Karena alasan ini, dan karena mereka sering diyakini meningkatkan biaya siklus awal dan
bahkan menunda proyek, metode formal, sayangnya, terlalu sering dihindari.
Namun harus dipahami bahwa metode formal tidak dimaksudkan untuk mengambil peran menyeluruh
dalam spesifikasi dan desain perangkat lunak waktu nyata. Sebaliknya, teknik yang dipilih dengan cermat
dapat digunakan dalam satu atau dua tahap proses pengembangan. Ada tiga kegunaan khas untuk
metode formal di antara insinyur perangkat lunak:
1. Pemeriksaan Konsistensi. Di sinilah kebutuhan sistem perilaku
KASIH dijelaskan menggunakan notasi matematika - berasal.
2. Memeriksa Model. Mesin negara hingga atau ekstensi mereka digunakan untuk
memverifikasi apakah properti yang diberikan terpenuhi dalam semua kondisi.
3. Teorema Membuktikan. Di sini, aksioma perilaku sistem digunakan untuk memperoleh a
bukti bahwa suatu sistem akan berperilaku dengan cara tertentu.
Selain itu, metode formal menawarkan peluang unik untuk menggunakan kembali persyaratan. Sistem
tertanam sering dikembangkan sebagai keluarga produk serupa, atau sebagai desain ulang tambahan produk
yang sudah ada. Untuk situasi pertama, metode formal dapat membantu mengidentifikasi serangkaian
persyaratan inti dan abstraksi yang konsisten untuk mengurangi upaya rekayasa rangkap dua. Untuk
mendesain ulang, memiliki spesifikasi formal untuk sistem yang ada memberikan referensi yang jelas untuk
perilaku dasar dan cara yang mudah untuk menganalisis perubahan yang diusulkan (Bowen dan Hinchey,
1995).
Contoh: Bukti Konsistensi Persyaratan
Pertimbangkan kutipan berikut dari spesifikasi persyaratan perangkat lunak:
R1. Jika interupsi A tiba, maka tugas B berhenti dijalankan.
R2. Tugas A mulai dijalankan pada saat kedatangan interupsi A.
R3. Entah Tugas A mengeksekusi dan Tugas B tidak, atau Tugas B mengeksekusi
dan Tugas A tidak, atau keduanya tidak menjalankan.
Persyaratan tekstual ini dapat diformalkan dengan menulis ulang masing-masing dalam hal proposisi
komponen mereka, yaitu:
p: Interrupt A tiba.
q: Tugas B sedang dieksekusi.
r: Tugas A sedang dieksekusi.
www.it-ebooks.info
204
METODOLOGI TEKNIK PERSYARATAN
Kemudian menulis ulang persyaratan menggunakan proposisi ini dan hasil penghubung logis standar
menghasilkan:
R1. hal ⇒ ¬ q R2. hal ⇒ r R3. (r ∧ ¬ q ) ∨ ( q ∧ ¬ r ) ∨ ( ¬ q ∧ ¬ r )
Perhatikan kesulitan yang jelas dalam berurusan dengan artikulasi perilaku temporal. Misalnya,
dalam persyaratan R2, Tugas A mulai dijalankan setelah kedatangan interrupt A; tetapi untuk
berapa lama itu terus dieksekusi? Hubungan ini perlu diklarifikasi menggunakan beberapa
metodologi lain.
Dalam kasus apa pun, konsistensi persyaratan ini dapat dibuktikan dengan menunjukkan bahwa ada setidaknya
satu set nilai kebenaran yang membuat semua persyaratan menjadi kenyataan secara bersamaan . Ini
dapat diverifikasi secara eksplisit dengan membuat tabel kebenaran yang sesuai (lihat Tabel 5.1). Melihat
meja, baris 3,
6, 7, dan 8 dalam kolom 6, 7, dan 8, sesuai dengan persyaratan R1, R2, dan R3, semuanya benar,
dan oleh karena itu rangkaian persyaratan ini konsisten.
Pemeriksaan konsistensi, yang mengarah ke bukti formal, sangat berguna ketika ada sejumlah besar
persyaratan rumit. Jika alat otomatis dengan antarmuka pengguna yang mudah tersedia untuk
melakukan proses pengecekan, bahkan spesifikasi besar pun dapat diperiksa dengan cara ini.
Namun, selain dari kesulitan dalam memformalkan notasi, menemukan satu set nilai kebenaran
individu yang menghasilkan nilai kebenaran gabungan untuk set proposisi, pada kenyataannya,
masalah kepuasan satelit Boolean, yang merupakan masalah NP-complete ( untuk dibahas dalam
Bab 7).
TABEL 5.1. Tabel Kebenaran Digunakan untuk Memverifikasi Konsistensi dari Contoh Set Persyaratan (T =
Benar dan F = Salah)
1
2
3
hal
q
r
4
5
6
7
¬q ¬ r P ⇒ ¬qp ⇒ r
8
( r ∧ ¬q ) ∨ ( q ∧ ¬r ) ∨ ( ¬ q ∧ ¬ r
)
1 T TTF
2 T TF
F
F
T
F
F
T
F
F
T
F
T
T
T
T
T
T
F
T
F
T
T
F
F
T
T
T
T
F
T
T
T
T
T
T
T
T
3 T FTT
4 T FF
5 F TTF
6 F TF
7 F FTT
8 F FF
www.it-ebooks.info
205
METODE FORMAL DALAM SPESIFIKASI SISTEM
5.2.1 Keterbatasan Metode Formal
Metode formal memiliki dua batasan utama yang menjadi perhatian khusus bagi pengembang sistem
waktu nyata. Pertama, meskipun formalisme sering digunakan untuk mencapai kebenaran dan
keamanan absolut, pada akhirnya tidak ada jaminan. Dan, kedua, teknik formal tidak menawarkan cara
yang efisien atau intuitif untuk beralasan tentang arsitektur atau desain alternatif.
Kebenaran dan keamanan adalah dua faktor pendorong asli yang mendorong adopsi metode
formal. Dirgantara, otomotif, pertahanan, lift, transportasi massal, dan regulasi nuklir di beberapa
negara mengamanatkan (atau sangat menyarankan) penggunaan metode formal untuk menentukan
subsistem yang kritis terhadap keselamatan. Selain itu, beberapa peneliti akademis menekankan sifat
"kebenaran" dari pendekatan matematika tertentu, tanpa mengklarifikasi bahwa kebenaran
matematika di satu bagian dari proses pengembangan mungkin tidak diterjemahkan ke dalam
kebenaran yang diterapkan di seluruh sistem.
Namun demikian, spesifikasi yang harus diproduksi dan dibuktikan pada tahap ini - bukan produk perangkat
lunak itu sendiri. Spesifikasi perangkat lunak formal perlu dikonversi ke desain, dan kemudian dikodekan
menggunakan beberapa bahasa pemrograman. Proses penerjemahan tunduk pada potensi jebakan dari setiap
upaya pemrograman. Untuk alasan ini, pengujian sama pentingnya ketika menggunakan metode teknik
persyaratan formal seperti ketika menggunakan metode informal atau semiformal, meskipun upaya pengujian
dapat dikurangi dengan menggunakan metode formal. Verifikasi formal juga tunduk pada banyak keterbatasan
yang sama dengan pengujian tradisional, yaitu, bahwa pengujian tidak dapat membuktikan tidak adanya
kesalahan, hanya kehadiran mereka.
Evolusi notasi adalah proses yang lambat namun berkelanjutan dalam komunitas metode formal. Ini bisa
memakan waktu bertahun-tahun sejak notasi baru diperkenalkan sampai diadopsi secara universal.
Tantangan utama dalam menerapkan metode formal ke sistem tertanam waktu nyata adalah memilih teknik
yang tepat untuk mencocokkan masalah yang dihadapi. Namun, untuk membuat model formal benar-benar
dapat digunakan untuk spektrum orang yang luas, dokumen persyaratan juga harus menggunakan notasi
non-matematis yang saling melengkapi, seperti bahasa alami, teks terstruktur, atau beberapa bentuk diagram
grafis.
5.2.2 Mesin Hingga Hingga
Mesin negara terbatas (FSM), robot keadaan terbatas (FSA), atau diagram transisi keadaan (STD)
adalah model matematika formal yang digunakan dalam spesifikasi dan desain perangkat lunak
waktu-nyata (Wagner et al., 2006). Dari ketiga istilah yang setara itu, kami menggunakan "mesin
keadaan terbatas" di seluruh teks ini. Secara intuitif, mesin keadaan terbatas bergantung pada fakta
bahwa banyak sistem dapat diwakili oleh sejumlah kondisi unik dan transisi tertentu di antara mereka.
Sistem dapat mengubah kondisinya tergantung pada waktu (jam waktu sebenarnya) atau terjadinya
peristiwa tertentu. Secara formal, mesin state terbatas dapat diwakili oleh lima tuple:
MS =i T
{ , ,
, Σ ,δ
www.it-ebooks.info
},
(5.1)
206
METODOLOGI TEKNIK PERSYARATAN
dimana S adalah seperangkat negara tak terbatas dan tak terbatas; saya adalah kondisi awal ( saya ∈ S ); T adalah
set terakhir status terminal ( T ⊆ S ); Σ adalah alfabet simbol atau peristiwa yang digunakan untuk menandai
transisi antar negara; dan δ adalah fungsi transisi yang menggambarkan keadaan FSM selanjutnya yang
diberikan keadaan saat ini dan simbol dari alfabet. Itu adalah, δ: S × Σ → S . Mesin state finite dapat
diekspresikan dalam representasi diagram, matrik, dan set - theoretik, tetapi kami lebih memilih dua yang
pertama dalam teks ini. Sementara diagram grafis mudah dibuat dan dipahami oleh para insinyur, matriks
adalah input yang sesuai untuk generator kode otomatis.
Contoh: Representasi Mesin Praktis Hingga Hingga
Untuk mengilustrasikan representasi diagram dan matriks, misalkan diinginkan untuk
memodelkan subsistem kontrol pintu dari pengontrol elevator. Subsistem keamanan-kritis ini
memiliki tujuh status berikut:
Tutup : Pintunya tertutup sepenuhnya.
Pembukaan: Pintu terbuka karena perintah terbuka awal atau lambat
buka kembali perintah.
Buka : Pintunya terbuka penuh.
Penutup: Pintunya tertutup secara normal.
Sikut: Pintu ditutup dengan kecepatan merayap dan dengan kekuatan yang berkurang
setelah beberapa pembukaan kembali.
Kesalahan C: Pintu tidak dapat ditutup sepenuhnya karena beberapa kegagalan.
Kesalahan O: Pintu tidak dapat sepenuhnya terbuka karena beberapa kegagalan.
Lima negara bagian pertama (Ditutup, Dibuka, Dibuka, Ditutup, dan Ditekan) dikunjungi secara
teratur dalam pengoperasian normal lift, tetapi dua yang terakhir (Kesalahan C dan Kesalahan O)
menunjukkan kondisi gangguan serius ketika lift harus ditutup turun karena pintu tidak dapat ditutup
atau dibuka karena beberapa (biasanya) kerusakan mekanis. Pada kondisi terminal yang tidak
normal tersebut, prosedur pemulihan kesalahan dimulai, seringkali mengarah pada kunjungan
servis oleh teknisi elevator. Secara umum diketahui bahwa pintu yang rusak menyebabkan
sebagian besar lift mati.
Subsistem kontrol pintu bereaksi terhadap berbagai peristiwa yang dihasilkan oleh pengontrol lift itu
sendiri, kontak pintu dan sensor keselamatan, tombol-tombol di dalam mobil, serta penghitung waktu habis
yang berbeda. Acara-acara ini tercantum di bawah ini:
CC: Perintah dari pengontrol lift untuk menutup pintu.
OC: Perintah dari pengontrol lift untuk membuka pintu.
DC: Kontak tertutup pintu (pintu tertutup sepenuhnya).
LAKUKAN: Kontak buka pintu (pintu terbuka sepenuhnya).
CB: Tombol pintu - tutup.
www.it-ebooks.info
207
METODE FORMAL DALAM SPESIFIKASI SISTEM
OB: Tombol buka pintu.
SE: Keamanan tepi untuk merasakan penumpang (atau hambatan) antara penutupan
pisau pintu.
PC: Photocell (s) untuk merasakan penumpang (atau hambatan) antara
bilah pintu penutup.
T1: Waktu tunggu untuk menunjukkan pintu tidak bisa ditutup dalam waktu yang cukup lama
waktu karena beberapa pembukaan kembali.
T2: Batas waktu untuk menunjukkan pintu tidak dapat ditutup dalam waktu yang terlalu lama
waktu karena kemungkinan gagal.
T3: Batas waktu untuk menunjukkan pintu tidak dapat dibuka dalam nominal (plus
beberapa margin) waktu karena kemungkinan kegagalan.
Transisi yang mungkin dari negara ke negara yang dipicu oleh peristiwa tertentu diilustrasikan pada
Gambar 5.2. Diasumsikan bahwa "Tertutup" adalah keadaan awal.
FSM ini dapat diekspresikan menggunakan lima tuple dari Persamaan 5.1 sebagai berikut:
S = { Tertutup Membuka
,
Buka
, Menutup, Kesalahan, Sikut C Kesalahan
,
O
,
}
i = Tutup
T={
Kesalahan C, Kesalahan O}
}
Σ = { CC OC
, DC, MELAKUKAN
,
,
CB
, OB ,SE PC
, TTT
, 1, 2 3 ,
Fungsi transisi, δ , diwujudkan dalam diagram itu sendiri, dan nyaman untuk diwakili dengan matriks
transisi, seperti yang ditunjukkan pada Tabel 5.2.
Lain
Buka
OB,
MELAKUKAN
Lain
Kesalahan C
CC, CB
SE, PC
T2
Penutupan
T1
Lain
Pembukaan
CB
Lain
Sikut
OC, OB DC
DC
T3
Tutup
Kesalahan O
Lain
Gambar 5.2. Representasi diagram mesin negara terbatas untuk subsistem kontrol pintu elevator.
www.it-ebooks.info
208
www.it-ebooks.info
Tutup Pembukaan Tutup
OC
Tutup
PC
Tutup
T1
Penutupan Buka
Buka
Buka
Kesalahan C Kesalahan C Kesalahan C Kesalahan C Kesalahan C Kesalahan C Kesalahan C Kesalahan C Kesalahan C Kesalahan C Kesalahan C
Kesalahan O Kesalahan O Kesalahan O Kesalahan O Kesalahan O Kesalahan O Kesalahan O Kesalahan O Kesalahan O Kesalahan O Kesalahan O Kesalahan O
Buka
Penutupan Pembukaan Pembukaan Pembukaan Pembukaan Kesalahan O
SE
Sikut Nudging Nudging Nudging Nudging Kesalahan C Sikut
Buka
OB
Tutup Pembukaan Tutup
CB
Sikut Sikut Sikut Tutup
Buka
Tutup
MELAKUKAN
Penutupan Penutupan Membuka Membuka Membuka Sikut Penutupan
Penutupan Buka
DC
Penutupan Penutupan Penutupan Tutup
Buka
Pembukaan Pembukaan Pembukaan Pembukaan Buka
Tutup
CC
TABEL 5.2. Representasi Matriks Transisi untuk Mesin Status Hingga pada Gambar 5.2
Buka
Tutup
T2
Kesalahan C
Penutupan
Buka
Tutup
T3
209
METODE FORMAL DALAM SPESIFIKASI SISTEM
Mesin state terbatas yang tidak menggambarkan output apa pun selama transisi state disebut a
Moore mesin, di mana semua output tergantung pada kondisi saja. Sejauh ini, kami hanya
mempertimbangkan mesin Moore dalam diskusi ini. Namun, output selama transisi dapat
digambarkan oleh perpanjangan dari mesin Moore yang disebut a Bertepung mesin. Mesin Mealy
dapat dijelaskan sesuai dengan enam - tuple:
MS =i T
{ , ,
, Σ ,Γδ ,
}
(5.2)
di mana lima elemen pertama sama dengan untuk mesin Moore dari Equation 5.1, sedangkan
elemen keenam, Γ , mewakili sekumpulan output yang mungkin. Namun, fungsi transisi / output, δ , di
sini agak berbeda dari fungsi transisi murni FSM Moore, karena menggambarkan keadaan
selanjutnya dan keluaran terkait yang diberikan keadaan saat ini dan simbol input dari alfabet.
Oleh karena itu, dapat dinyatakan sebagai δ: S × Σ → S × Γ . Mesin Mealy generik untuk sistem
dengan tiga status, tiga input, dan tiga output diilustrasikan dalam Gambar 5.3. Matriks transisi
yang sesuai diberikan pada Tabel 5.3. Secara umum diketahui bahwa jumlah negara yang
diperlukan dalam Mealy FSM kurang dari atau sama dengan jumlah negara dalam mesin Moore
yang sesuai.
Mesin keadaan terbatas mudah untuk dibangun, dan kode program dapat dengan mudah
(atau bahkan secara otomatis) dihasilkan menggunakan matriks untuk menentukan transisi antar
negara. FSM juga tidak ambigu, karena mereka dapat diwakili dengan deskripsi matematika
formal. Selain itu, konkurensi
/ O2
S2 E2
E2 / O2
E2 / O2
E1 / O1
E1 / O1
S1
E3 / O3
E3 / O3
E1 / O1
S3
E3 / O3
Gambar 5.3. FSM Mealy yang sepenuhnya terhubung dengan status S1, S2, dan S3, input E1, E2, dan E3, dan output O1,
O2, dan O3.
www.it-ebooks.info
210
METODOLOGI TEKNIK PERSYARATAN
TABEL 5.3. Representasi Matriks Transisi untuk Mesin Status
Hingga pada Gambar 5.3
E1
E2
E3
S1
S1 / O1
S2 / O2
S3 / O3
S2
S1 / O1
S2 / O2
S3 / O3
S3
S1 / O1
S2 / O2
S3 / O3
dalam sistem waktu nyata dapat digambarkan dengan menggunakan beberapa mesin negara terbatas. Ketika
membangun mesin keadaan terbatas, perhatian khusus harus diberikan pada masalah berikut (Yourdon,
1989):
•
Sudahkah Anda mendefinisikan semua kondisi yang diperlukan?
•
Bisakah semua negara bagian tercapai?
•
Bisakah semua negara, kecuali yang terminal, keluar?
Karena teknik matematika yang ketat untuk mengurangi jumlah negara ada, kode program
berdasarkan FSMs dapat dioptimalkan secara formal. Optimalisasi semacam itu bahkan bisa
otomatis. Sebuah teori yang kaya mengelilingi mesin negara yang terbatas, dan ini dapat
dieksploitasi dalam pengembangan spesifikasi sistem. Di sisi lain, kelemahan utama FSM
adalah bahwa aspek internal modul tidak dapat digambarkan. Artinya, tidak ada cara untuk
menunjukkan bagaimana fungsi (negara) dapat dipecah menjadi subfungsi (substate). Selain
itu, komunikasi intertask antara beberapa FSM sulit untuk digambarkan. Akhirnya, tergantung
pada sistem dan alfabet tertentu yang digunakan, jumlah negara kadang-kadang bisa tumbuh
sangat besar. Kedua masalah ini, bagaimanapun, dapat diatasi melalui penggunaan statechart
yang akan diperkenalkan segera. Selanjutnya,
5.2.3 Lembar Data
Statecharts - atau awalnya statecharts Harel (Harel, 2009) - berakar pada industri avionik, dan mereka
memberikan "formalisme diagram / visual" untuk insinyur sistem dan perangkat lunak. Mereka
menggabungkan keramahan pengguna mesin negara yang terbatas dengan diagram aliran data dan
fitur yang disebut komunikasi siaran, dengan cara yang dapat menggambarkan operasi sinkron maupun
asinkron. Statecharts dapat didefinisikan secara informal sebagai:
Statechart FSM
= Kedalaman
+
Komunikasi
+
Siaran Orthogonality
+
.
Di sini, FSM adalah mesin keadaan terbatas, kedalaman mewakili tingkat hierarki detail,
ortogonalitas mewakili keberadaan keadaan paralel, dan komunikasi siaran adalah metode untuk
memungkinkan berbagai keadaan ortogonal bereaksi
www.it-ebooks.info
211
METODE FORMAL DALAM SPESIFIKASI SISTEM
ke acara yang sama. Sebenarnya, hierarki dan ortogonalitas adalah dua gagasan utama di balik
statechart, dan mereka dapat diperparah secara fleksibel. Nilai hierarki dan ortogonalitas terutama ada
di dalamnya kenyamanan dan kealamian . Pada prinsipnya, hierarki selalu dapat ditingkatkan dan
ortogonalitas dapat dihilangkan. Namun, "kenyamanan" adalah apa yang para insinyur menghargai
ketika menggunakan metodologi apa pun.
Statechart adalah perpanjangan dari mesin negara terbatas, di mana setiap negara dapat berisi
FSM sendiri yang lebih lanjut menggambarkan perilakunya. Komponen dasar statechart diperkenalkan
di bawah ini (lihat juga Gambar 5.4 - 5.7):
x (e, ... e) / ny
SEBUAH
1
B
Gambar 5.4. Format Statechart di mana A dan B adalah negara, x adalah peristiwa yang menyebabkan transisi yang
ditandai oleh panah, y adalah acara opsional yang dipicu oleh x , dan e 1 , . . . e n adalah kondisi opsional yang memenuhi syarat
untuk acara utama; diadaptasi dari Laplante (2003).
A
B
A1
B1
e/f
a1
a2
b2
b1
A2
B2
Gambar 5.5. Statechart yang menggambarkan insideness; diadaptasi dari Laplante (2003).
40 ms
5 ms
Navigasi
Interrupt
Latar Belakang
Tugas
ms
Baca dan
Interrupt
Data Gyro 40 ms
Kompensasikan
Baca dan
Kompensasikan
Accelerometer
mentah
Pulsa 5
Mengimbangi
Semua data
1 s Interrupt
1s
Perbarui Tampilan
Gambar 5.6. Subsistem navigasi berisi empat tugas ortogonal.
www.it-ebooks.info
212
METODOLOGI TEKNIK PERSYARATAN
C
SEBUAH
e/f
B
E
g
f/g
D
F
Gambar 5.7. Statechart yang menggambarkan reaksi berantai; diadaptasi dari Laplante (2003).
•
FSM diwakili dengan cara yang biasa, dengan huruf kapital atau frasa deskriptif yang digunakan untuk
memberi label negara.
•
Kedalaman atau hierarki diwakili oleh insideness negara.
•
Orthogonality diwakili oleh garis putus-putus yang memisahkan keadaan paralel (atau tugas dalam
sistem multitasking).
•
Komunikasi siaran diwakili oleh panah berlabel, sama seperti transisi dalam FSM.
•
Simbol Sebuah , b , . . . z mewakili peristiwa yang memicu transisi, dengan cara yang sama transisi
diwakili dalam FSM.
•
Huruf kecil dalam tanda kurung berarti kondisi yang harus benar untuk terjadinya transisi
terkait.
Karakteristik penting dari statechart adalah dorongan eksplisit dari desain top-down modul atau
semacamnya. Sebagai contoh, untuk modul apa pun (direpresentasikan seperti keadaan dalam FSM),
peningkatan detail digambarkan sebagai substate internal. Pada Gambar 5.5, sistem ini terdiri dari dua
keadaan primer, A dan B, yang digambarkan sebagai persegi panjang bulat. Masing-masing, pada
gilirannya, telah didekomposisi menjadi substrat Al dan A2, dan B1 dan B2, masing-masing, yang
mungkin mewakili modul program individual. Keadaan internal itu juga dapat diuraikan, dan sebagainya.
Untuk programmer menggunakan beberapa bahasa prosedural, masing-masing substrat bersarang
dalam suatu negara merupakan prosedur dalam prosedur lain.
Orthogonality menggambarkan konkurensi dalam sistem untuk negara yang berjalan secara terpisah, yang
disebut DAN menyatakan. Orthogonality diwakili dengan memisahkan komponen ortogonal dengan garis
putus-putus. Misalnya, jika suatu negara S terdiri dari DAN
komponen P dan Q, S disebut produk ortogonal P dan Q. Jika S dimasukkan dari luar tanpa
informasi kondisional, maka negara P dan Q dimasukkan secara bersamaan. Komunikasi
antara DAN keadaan dapat dicapai dengan nyaman melalui penggunaan kehati-hatian memori
global, sedangkan sinkronisasi dapat dicapai melalui fitur statecharts yang disebut komunikasi
siaran. Gambar 5.6 mengilustrasikan statechart untuk subsistem navigasi pesawat yang
dibahas sebelumnya dalam teks yang berisi empat ortogonal
www.it-ebooks.info
METODE FORMAL DALAM SPESIFIKASI SISTEM
213
tugas dan enam keadaan internal atau substrat. Deskripsi visual yang sangat ringkas dari seluruh
subsistem memberikan gambaran yang jelas tentang fungsionalitas multitasking. Namun, perlu untuk
memahami algoritma dan kendala yang mendasari sebelum dimungkinkan untuk membuat statechart
tersebut.
Komunikasi siaran digambarkan oleh transisi kondisi ortogonal berdasarkan peristiwa yang
sama, dan itu adalah cara sederhana untuk mengoordinasikan komponen statechart ortogonal.
Misalnya, jika sistem pengukuran inersia beralih dari mode "siaga" ke mode "siap", peristiwa yang
ditunjukkan oleh interupsi dapat menyebabkan perubahan status simultan dalam beberapa tugas
(atau bahkan subsistem). Aspek berharga lain dari komunikasi siaran adalah konsep reaksi
berantai ; yaitu, peristiwa yang memicu peristiwa lain secara berurutan. Implementasinya
mengikuti dari pengamatan bahwa statecharts dapat dilihat sebagai perpanjangan dari mesin
state tipe terbatas Mealy, dan output event dapat dilampirkan ke event triggering. Berbeda
dengan mesin Mealy standar, bagaimanapun, output tidak terlihat oleh dunia luar; sebaliknya, itu
hanya mempengaruhi perilaku komponen ortogonal saja. Sebagai contoh, pada Gambar 5.7
anggaplah ada transisi berlabel e / f , dan jika acara e terjadi, lalu acara f segera diaktifkan.
Selanjutnya acara f dapat memicu transisi lain, seperti f / g . Panjang reaksi berantai adalah jumlah
transisi yang dipicu oleh peristiwa pertama. Reaksi berantai seperti itu diasumsikan terjadi secara
instan, walaupun dalam implementasi uniprocessor yang praktis, ini tidak mungkin dilakukan
dengan tepat. Dalam sistem Gambar 5.7, reaksi berantai panjang dua akan terjadi ketika e / f transisi
pertama terjadi.
Statechart sangat baik untuk mewakili sistem waktu nyata karena dapat menggambarkan
konkurensi sambil mempertahankan modularitas. Selain itu, konsep komunikasi siaran
memungkinkan intertask mudah - representasi komunikasi. Sebagai contoh dunia nyata, Gambar
5.A5 ditemukan dalam studi kasus Bagian
5.7 mengilustrasikan statechart yang berkaitan dengan sistem kontrol lampu lalu lintas yang canggih.
Singkatnya, statechart menggabungkan diagram aliran data terbaik dan mesin state terbatas.
Produk komersial memungkinkan seorang insinyur untuk mendefinisikan sistem waktu nyata
menggunakan grafik, melakukan analisis simulasi komprehensif, dan bahkan menghasilkan kode
program secara otomatis. Selain itu, statechart dapat digunakan bersama dengan metode
terstruktur dan berorientasi objek. Statechart banyak digunakan saat ini, karena varian
berorientasi objek telah menjadi bagian standar dari UML (Samek, 2009).
5.2.4 Petri Nets
Petri nets adalah kelas lain dari metode formal yang digunakan untuk menentukan dan menganalisis operasi
bersamaan dalam sistem waktu nyata (Mazzeo et al., 1997). Alat Petri net yang tersedia secara komersial dapat
menghasilkan spesifikasi yang dapat dieksekusi dan sangat cocok untuk memodelkan sinkronisasi di antara
tugas-tugas yang tidak sinkron. Sementara jaring Petri memiliki dasar matematika yang ketat, mereka masih dapat
digambarkan secara grafis sebagai interkoneksi dari hanya dua entitas dasar. Satu set lingkaran yang disebut
www.it-ebooks.info
214
METODOLOGI TEKNIK PERSYARATAN
"Tempat" digunakan untuk mewakili penyimpanan data atau kondisi. Kotak persegi panjang, di sisi lain,
mewakili transisi atau peristiwa. Setiap tempat (P ) dan transisi
( T ) masing-masing ditandai dengan jumlah data dan fungsi transisi, dan keduanya dihubungkan
oleh panah searah. Jaring Petri kadang-kadang disebut Jaring Tempat / Transisi mengacu pada
peran sentral tempat dan transisi. Selain itu, mesin negara terbatas dapat diartikan sebagai
subkelas dari jaring Petri, tetapi ekspresifnya jelas lebih lemah.
Grafik Petri net awal diberi label dengan a menandai diberikan oleh m 0 , yang mewakili jumlah
data awal di semua tempat. Tanda selanjutnya, m saya ,
saya ∈ { 1, 2, 3,. . . }, adalah hasil dari tembak transisi, di mana setiap cincin adalah operasi atom pada dasarnya.
Sebuah api transisi jika memiliki input data sebanyak yang diperlukan untuk menghasilkan output terkait. Dalam
jaring Petri, topologi grafik tidak berubah seiring waktu; hanya penandaan atau penghitungan data tempat yang
dilakukan. Sistem waktu nyata yang dimodelkan dapat juga bergerak maju secara deterministik (yaitu, ada lebih
dari satu keadaan selanjutnya yang mungkin) sebagai api transisi. Untuk mengilustrasikan gagasan ring,
pertimbangkan Petri net sederhana yang diberikan pada Gambar 5.8 dan tabel ring yang sesuai yang disediakan
pada Tabel 5.4.
Sebagai contoh lain, perhatikan Petri net pada Gambar 5.9. Bergerak dari atas ke bawah dan
ke kiri ke kanan menunjukkan tahap-tahap berurutan di jaring. Tabel 5.5 menggambarkan tabel
cincin yang sesuai. Ketika jumlah panah keluar lebih rendah dari panah masuk, transisi tertentu
disebut a konsumen; dan ketika transisi memiliki lebih banyak panah keluar daripada yang masuk,
itu adalah a produsen ( Bucci et al., 1995).
P1
T1
P2
m0
P1
T1
P2
m1
Gambar 5.8. Jaring Petri sederhana sebelumnya ( m 0 ) dan kemudian ( m 1 ) tembak; diadaptasi dari Laplante (2003).
TABEL 5.4. Firing Table untuk Petri Net Yang Ditampilkan pada Gambar
5.8; Diadaptasi dari (Laplante, 2003)
m0
m1
P1
P2
1
0
0
1
www.it-ebooks.info
215
METODE FORMAL DALAM SPESIFIKASI SISTEM
P1
P6
P4
P3
m0
P2
P5
P1
P4
P7
P6
P3
m1
P2
P5
P1
P4
P7
P6
P3
m2
P2
P5
P1
P4
P7
P6
P3
m3
P2
P5
P7
Gambar 5.9. Perilaku berurutan dari Petri net dengan transisi "konsumen" dan "produsen".
TABEL 5.5. Firing Table untuk Petri Net Yang Ditampilkan pada
Gambar 5.9
m0
m1
m2
m3
P1
P2
P3
P4
P5
P6
P7
1
1
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
1
1
0
0
0
0
0
0
0
1
1
www.it-ebooks.info
216
METODOLOGI TEKNIK PERSYARATAN
Petri nets dapat digunakan untuk memodelkan (bagian dari) sistem waktu nyata dan untuk mencari
kemungkinan konflik waktu, serta kondisi lomba. Mereka sangat baik untuk mewakili sistem terdistribusi
dan event-driven, seperti protokol komunikasi dan sistem manufaktur diskrit. Karena jaring Petri murni
bersifat matematis, teknik yang ketat untuk optimasi sistem dan pembuktian program dapat digunakan.
Namun, jaring Petri bisa berlebihan jika sistem yang akan dimodelkan sangat sederhana. Demikian
pula, jika sistem ini sangat kompleks, perilaku pengaturan waktu keseluruhan dapat dengan mudah
menjadi kabur.
Petri net adalah alat yang ampuh yang sering digunakan untuk analisis
ras - kondisi dan untuk jalan buntu identifikasi. Sebagai contoh, misalkan spesifikasi persyaratan berisi subnet yang
menyerupai Gambar 5.10. Jelas, tidak mungkin untuk mengatakan yang mana dari dua transisi (diberi label dengan
tanda tanya) yang akan terbakar, meskipun dalam kasus apa pun, hanya satu dari mereka yang akan terbakar.
Selain itu, jaring Petri dapat digunakan secara efektif untuk mengidentifikasi siklus yang mengindikasikan kebuntuan
potensial. Sebagai contoh, misalkan satu set persyaratan dapat dimodelkan seperti pada Gambar
5.11, yang merupakan replika formal dari Gambar 3.13 yang melibatkan dua tugas paralel dan dua sumber daya
bersama. Jelas, skenario ini merupakan jalan buntu yang tak terhindarkan. Dan meskipun tidak mungkin bahwa
situasi konflik seperti itu akan dibuat dengan sengaja, Petrinet juga dapat digunakan untuk mengidentifikasi
keadaan yang tidak dapat dijangkau, yang akan diwakili oleh tanda yang tidak pernah dapat dijangkau. Analisis
Petri net dengan alat simulasi yang tepat dapat digunakan untuk mengidentifikasi nonobvious
T1
P1
P3
P2
?
T2
Gambar 5.10. Identifikasi kondisi ras dengan jaring Petri.
P1
T1
T2
P2
Gambar 5.11. Deadlock pada Gambar 3.13 diilustrasikan menggunakan Petri net.
www.it-ebooks.info
METODE SEMIFORMAL DALAM SPESIFIKASI SISTEM
217
siklus yang muncul sebagai subnet dalam diagram kompleks. Situasi seperti ini secara singkat
dibahas dalam sketsa berikut oleh Ovaska.
Vignette: Simulasi Petri Net Membantu Mengidentifikasi Kebuntuan
Protokol komunikasi dikembangkan untuk sistem kontrol elevator pada Gambar 3.17. Protokol
diimplementasikan dan diuji, dan semuanya tampak berfungsi dengan baik. Namun, komunikasi
kritis antara dispatcher grup dan hingga delapan pengontrol elevator dapat memasuki kondisi
menemui jalan buntu secara sporadis. Situasi ini jarang terjadi, setiap beberapa hari sekali. Oleh
karena itu, sulit untuk mengidentifikasi alasan kegagalan dramatis tersebut. Untuk beberapa waktu,
diasumsikan kebuntuan adalah perangkat keras berasal dan disebabkan oleh gangguan
elektromagnetik. Tetapi tidak ada bukti untuk masalah hipotesis seperti itu yang ditemukan.
Insinyur perangkat lunak yang bertanggung jawab berorientasi pada praktik dan tidak memiliki
kepercayaan pada metode formal untuk spesifikasi sistem. Namun, dua mahasiswa ilmu komputer
diundang untuk membuat model protokol komunikasi Petri net yang terperinci sebagai tugas
khusus mereka. Mereka melakukan simulasi sistematis dengan model formal dan segera
mengidentifikasi kondisi kesalahan langka yang menyebabkan kebuntuan yang diburu. Bug
diperbaiki dan protokol komunikasi berfungsi dengan baik sejak itu. Setelah pengalaman yang
mengguncang ini, insinyur itu menyingkirkan jaring Petri dari daftar subyektif “yang harus dihindari.
”
Model dasar Petri net yang diuraikan dalam bagian ini hanyalah salah satu dari berbagai model yang
tersedia. Misalnya, ada jaring Petri berwaktu, yang memungkinkan sinkronisasi jaring, jaring Petri
berwarna, yang memungkinkan data berlabel untuk merambat melalui jaring, dan jaring Petri berwarna
berwaktu, yang mencakup kedua fitur.
5.3 METODE SEMIFORMAL DALAM SPESIFIKASI SISTEM
Metode semiformal digunakan secara luas dalam menentukan sistem waktu-nyata karena
keserbagunaannya yang khas - beberapa metode tersebut bahkan dianggap dapat memajukan
orang-orang yang sulit. proses spesifikasi sistem diri. Dalam diskusi berikut, kami merenungkan dua
pendekatan luas untuk menentukan perangkat lunak waktu nyata: analisis terstruktur dan metode
desain terstruktur (SA / SD) dan bahasa pemodelan terpadu (UML). Sementara penggunaan UML
berkembang pesat dengan transisi yang sedang berlangsung dari bahasa pemrograman prosedural
ke bahasa berorientasi objek dalam aplikasi waktu nyata (lihat Gambar 4.1), SA / SD masih memiliki
posisi yang kuat dengan pengguna bahasa prosedural dalam sistem embedded. Selain itu, metode
SA / SD yang mudah dipelajari sangat nyaman ketika memperkenalkan topik spesifikasi sistem untuk
mahasiswa sarjana atau pendatang baru di bidang rekayasa perangkat lunak.
www.it-ebooks.info
218
METODOLOGI TEKNIK PERSYARATAN
5.3.1 Analisis Terstruktur dan Desain Terstruktur
Selama masa lalu, selama lebih dari tiga dekade, metode untuk SA / SD telah berevolusi secara
bertahap dari definisi awal De Marco (1978) ke ekstensi terbaru Yourdon (2006), dan digunakan
secara luas dalam beragam aplikasi real-time di seluruh dunia. Salah satu alasan di balik
popularitas yang luar biasa dari SA / SD adalah bahwa teknik-teknik itu terkait erat dengan
bahasa pemrograman prosedural yang dengannya mereka berkembang bersama (seperti bahasa
C) dan di mana banyak sistem waktu-nyata ditulis. Alasan lain jelas ketersediaan global alat-alat
teknik SA / SD didirikan. Meskipun metode terstruktur muncul dalam banyak bentuk, standar de
facto tidak diragukan lagi adalah milik Yourdon Analisis Terstruktur Modern ( Yourdon, 1989).
Beberapa ekstensi untuk analisis terstruktur asli (SA) telah muncul pada 1980-an untuk
memperhitungkan, misalnya, dinamika sistem dan penggunaan SA untuk spesifikasi sistem tertanam.
Khususnya, Ward dan Mellor memperluas diagram aliran data dengan menambahkan cara untuk
memodelkan aliran kontrol (seperti interupsi), serta mesin keadaan terbatas (atau diagram transisi
negara), untuk menentukan proses kontrol (Ward dan Mellor, 1985). Ekstensi waktu nyata lainnya
termasuk Doma Gomaa (pendekatan desain untuk sistem waktu nyata) (Gomaa, 1988), misalnya.
Analisis terstruktur untuk sistem waktu nyata masih didasarkan pada gagasan dasar aliran data antara
transformasi data berturut-turut, dan itu memberikan sangat sedikit dukungan untuk mengidentifikasi
konkurensi. Oleh karena itu, tergantung pada detail fase analisis, biasanya ada sesuatu yang
sewenang-wenang dalam mengidentifikasi serangkaian proses yang sesuai. Ini dapat mengakibatkan
implementasi proses yang tidak perlu (menyebabkan overhead penjadwalan tambahan) dan
kemungkinan bahwa beberapa proses memerlukan konkurensi secara internal (menyebabkan
kompleksitas implementasi tambahan) (Bucci et al., 1995). Untuk mencegah inefisiensi ini, sangat
penting untuk menggunakan metode SA / SD secara iteratif - pendekatan multi-lulus seperti ini didukung
oleh alat-alat teknik SA / SD.
Milik Yourdon Analisis Terstruktur Modern memiliki tiga model pelengkap (atau sudut pandang) untuk
menggambarkan sistem waktu nyata:
M1. Model lingkungan
M2. Model perilaku
M3. Model implementasi
Elemen-elemen dari masing-masing model ditunjukkan pada Gambar 5.12. Model lingkungan
mewujudkan analisis aspek SA / SD dan terdiri dari diagram konteks dan daftar acara terkait. Tujuan
dari model lingkungan adalah untuk memodelkan sistem pada abstraksi tingkat tinggi. Di sisi lain,
model perilaku mewujudkan rancangan aspek SA / SD sebagai rangkaian diagram aliran data dan
diagram alur kendali, diagram hubungan entitas, spesifikasi proses dan kontrol, diagram transisi
keadaan, dan kamus data. Menggunakan kombinasi elemen-elemen ini yang sesuai, perancang
memodelkan sistem waktu-nyata secara terperinci.
www.it-ebooks.info
METODE SEMIFORMAL DALAM SPESIFIKASI SISTEM
219
Model Lingkungan
Diagram Konteks
Daftar Acara Bahasa
Alami
Model Perilaku
Data Flow Diagram Diagram Aliran
Kontrol Entitas Hubungan Diagram
Proses Spesifikasi Kontrol
Spesifikasi State Transition
Diagram Kamus Data Bahasa
Alami
Model Implementasi
Struktur Bagan
Pseudocode Temporal
Logic Bahasa Alam
Gambar 5.12. Model dan elemen analisis terstruktur dan desain terstruktur.
Disarankan, bagaimanapun, aliran data dan analisis aliran kontrol harus dilakukan secara terpisah
- tidak bersamaan. Akhirnya, dalam model implementasi, pengembang menggunakan pilihan
bagan struktur, pseudocode, dan logika temporal untuk menggambarkan sistem ke tingkat yang
dapat segera diterjemahkan ke beberapa bahasa pemrograman prosedural. Selain itu, semua
model M1 - M3 juga dapat berisi beberapa deskripsi bahasa alami. Kehadiran deskripsi bahasa
alami biasanya merupakan indikasi bahwa diagram tidak cukup jelas bagi pelanggan atau
pengembang, dan klarifikasi tekstual diperlukan untuk melengkapi pemodelan visual.
Analisis terstruktur adalah cara yang sangat potensial untuk mengatasi masalah analisis
klasik dengan menggunakan alat grafis dan metode dekomposisi fungsional top-down untuk
mendefinisikan persyaratan sistem. SA hanya membahas aspek-aspek analisis yang dapat
disusun: spesifikasi fungsional dan
lingkungan Hidup / antarmuka pengguna . Selain itu, analisis terstruktur digunakan untuk memodelkan sistem konteks
( dari mana input berasal dan ke mana output pergi), proses
(fungsi apa yang dilakukan sistem, bagaimana fungsi berinteraksi, dan bagaimana input ditransformasikan
menjadi keluaran), dan kandungan ( data yang dibutuhkan sistem untuk menjalankan fungsinya). Analisis
terstruktur berupaya untuk mengatasi tantangan heterogen yang melekat dalam analisis sistem melalui:
•
Pemeliharaan dokumen target yang mudah.
•
Penggunaan grafik ilustrasi.
•
Pengurangan ambiguitas dan redundansi yang efektif.
www.it-ebooks.info
220
METODOLOGI TEKNIK PERSYARATAN
•
Memberikan metode yang mendukung untuk partisi fungsional.
•
Membangun model logis dari sistem sebelum implementasi.
Dokumen target untuk SA disebut spesifikasi terstruktur . Ini terdiri dari diagram konteks sistem,
seperangkat diagram aliran data hierarkis yang menunjukkan dekomposisi dan interkonektivitas
berbagai komponen, dan daftar peristiwa untuk mewakili serangkaian peristiwa eksternal yang
menggerakkan sistem.
Untuk menggambarkan penggunaan teknik analisis terstruktur, perhatikan contoh berikut dari
sistem kontrol elevator yang diperkenalkan pada Bagian 3.3.8. Beberapa kebebasan telah diambil
dengan notasi, tetapi ini umum, karena masing-masing organisasi cenderung memiliki "gaya
rumah," yaitu, konvensi yang bergantung baik pada alat rekayasa perangkat lunak (CASE) yang
digunakan komputer atau preferensi individu .
Contoh: Diagram Konteks Sistem Tertanam
Diagram konteks pada Gambar 5.13 mendefinisikan lingkungan operasi elevator control
system (ECS). Untuk membuatnya lebih mudah untuk memahami diagram dari sudut
pandang aplikasi, perlu untuk memberikan pengantar singkat tentang tujuan dan
pengoperasian enam terminator (kotak persegi panjang) yang terhubung ke transformasi data
(gelembung):
1. Unit Kontrol Gerakan ( MCU ) . Mengemudikan mobil lift dengan aman, lancar,
dan tepatnya dari satu lantai ke lantai lainnya; memberikan informasi posisi mobil dan
status operasional.
2. Operator Pintu ( MELAKUKAN ) . Membuka dan menutup bilah pintu dengan cepat tetapi
dengan aman (lihat mesin kondisi terbatas pada Gambar 5.2); menyediakan sensor operasional
serta keselamatan dan informasi status tombol buka / tutup.
3. Panel Operasi Mobil ( POLISI ) . Menunjukkan mobil - posisi dan putaran lainnya -
informasi spesifik kepada penumpang; menyediakan informasi status operasional dan
antarmuka ke tombol panggilan mobil.
4. Panel Operasi Hall ( MELOMPAT ) . Menunjukkan informasi posisi mobil
penumpang yang menunggu; mengendalikan "lentera" dan "gong," yang menunjukkan
arah lari lift yang datang / berangkat; memberikan informasi status operasional.
5. Group Dispatcher ( GD ) . Tetapkan panggilan aula terdaftar untuk yang sesuai
lift di bank lift menggunakan beberapa strategi alokasi panggilan yang optimal.
6. Alat Layanan (ST). Menyediakan antarmuka pengguna yang dilindungi kata sandi untuk
petugas servis untuk memberikan perintah khusus, memantau lift secara detail, dan
mengakses statistik operasional.
Di sini, transformasi data tunggal dari diagram konteks memodelkan seluruh sistem kontrol
elevator. Komunikasi antara ECS dan
www.it-ebooks.info
221
METODE SEMIFORMAL DALAM SPESIFIKASI SISTEM
ST
Perintah Khusus
MCU
Data yang Diminta
Status Gerak
Ditugaskan
GD
Status Lift Panggilan
Jalankan / Hentikan Perintah
ECS
Perintah Pintu
MELAKUKAN
Posisi dan Arah Mobil
Status Indikator
Status Pintu
Informasi Khusus Jalankan
MELOMPAT
Panggilan Mobil dan Status Operasional
POLISI
Gambar 5.13. Diagram konteks untuk sistem kontrol elevator.
semua terminator (perangkat eksternal atau subsistem) adalah dua arah seperti yang ditunjukkan oleh
aliran data, dan data yang ditransfer diidentifikasi oleh label deskriptif. Perlu dicatat bahwa aliran data
yang muncul dalam diagram konteks harus memiliki tingkat abstraksi yang sama dengan diagram
konteks itu sendiri. Untuk menyimpulkan, diagram konteks pada Gambar 5.13 membentuk titik awal
yang baik untuk proses SA / SD yang tersisa.
Sementara maksud dalam contoh di atas bukan untuk menyajikan desain sistem yang lengkap yang berarti ada beberapa penyederhanaan - hal yang harus dibuat adalah bahwa fungsionalitas
yang hilang lebih mudah dikenali selama proses elisitasi persyaratan jika suatu bentuk bantuan
grafis, seperti diagram konteks SA, tersedia.
5.3.2 Analisis Berorientasi Objek dan Bahasa Pemodelan yang Terpadu
Sebagai alternatif yang layak untuk pendekatan analisis terstruktur untuk mengembangkan spesifikasi
kebutuhan perangkat lunak, kami selanjutnya mempertimbangkan menggunakan pendekatan berorientasi objek
(H ø ydalsvik dan Sindre, 1993). Berbeda dengan pemrograman prosedural, yang menggunakan prosedur
algoritmik, pemrograman berorientasi objek menggunakan struktur objek yang berkolaborasi, di mana setiap
bagian melakukan pemrosesan khusus dengan bereaksi terhadap input dari tetangga terdekatnya. Ada
berbagai "lantai" dari analisis berorientasi objek (OOA), masing-masing menggunakan alat sendiri. Dalam
pendekatan mendominasi yang dibahas di bawah ini, spesifikasi sistem
www.it-ebooks.info
222
METODOLOGI TEKNIK PERSYARATAN
fase dimulai dengan representasi fungsionalitas yang dapat diakses secara eksternal sebagai
gunakan kasing dari UML. Di antara praktisi, OOA didefinisikan secara informal sebagai "operasi analitis
yang menggunakan diagram UML" (Gelbard et al., 2010).
Pendekatan UML, secara keseluruhan, jelas lebih memakan waktu untuk belajar dan lebih rumit
untuk digunakan daripada metode SA / SD, karena itu (UML 2.2) memiliki 14 jenis diagram sebagian
berlebihan yang dibagi menjadi kategori struktural dan perilaku (Miles dan Hamilton, 2006):
1. Struktural
•
Diagram kelas
•
Diagram komponen
•
Diagram struktur komposit
•
Diagram penempatan
•
Diagram objek
•
Diagram paket
•
Diagram profil
2. Perilaku
2.1. Umum
•
Diagram aktivitas
•
State - machine diagram
•
Gunakan diagram kasus
2.2. Interaksi
•
Diagram komunikasi
•
Diagram ikhtisar interaksi
•
Diagram urutan
•
Diagram waktu
Semua tipe diagram ini akan diperkenalkan pada Bab 6, sementara dalam diskusi ini, kami
hanya berkonsentrasi pada diagram yang paling relevan dalam fase rekayasa persyaratan
proyek perangkat lunak real-time.
Kasus penggunaan adalah artefak penting dalam analisis dan desain berorientasi objek dan
dijelaskan secara grafis menggunakan salah satu dari beberapa teknik. Diagram use-case dapat
dianggap analog dengan diagram konteks dalam analisis terstruktur yang menggambarkan interaksi
aplikasi perangkat lunak dengan lingkungan eksternalnya. Dalam spesifikasi sistem tertanam, ini juga
di mana kendala waktu keseluruhan, laju pengambilan sampel, dan tenggat waktu sering ditentukan.
Deskripsi tekstual digunakan secara umum untuk melengkapi diagram use-case. Diskusi pragmatis
tentang membuat kasus penggunaan yang tepat tersedia di Cockburn, (2001).
Use case direpresentasikan secara grafis sebagai elips, dengan aktor yang terlibat diwakili oleh tongkat,
seperti yang dapat dilihat pada Gambar 5.14. Dalam ilustrasi itu, kasus penggunaan sesuai dengan struktur
tugas lima tingkat yang diusulkan dalam Bagian
3.3.8. Secara umum, seringkali frustasi untuk memutuskan tingkat detail
www.it-ebooks.info
223
METODE SEMIFORMAL DALAM SPESIFIKASI SISTEM
ECS
Berkomunikasi dengan
Dispatcher Grup
COP
GD
Daftarkan Panggilan Mobil dan
Tentukan Tujuan
Lakukan Operasi
Berjalan dan Pintu
MCU
LAKUKAN
Melakukan Pengawasan dan
Diagnostik Mandiri
Menangani Layanan-Alat
Fungsi
ST
MELOMPAT
Gambar 5.14. Diagram use case untuk sistem kontrol elevator.
untuk use case atau mencoba memahami apa yang terdiri dari use case tertentu (Agarwal dan
Sinha, 2003). Garis yang ditarik dari aktor ke use case mewakili komunikasi di antara mereka.
Setiap use case sebenarnya adalah dokumen yang menggambarkan skenario operasi sistem
yang sedang dipertimbangkan, serta kemungkinan pra dan pasca kondisi dan pengecualian.
Dalam proses pengembangan berulang, use case ini akan menjadi semakin didefinisikan dan
dirinci seiring dengan perkembangan pekerjaan analisis dan desain. Selanjutnya, diagram
interaksi dibuat untuk menggambarkan perilaku yang ditentukan oleh setiap use case. Dalam
iterasi pertama, diagram ini menggambarkan seluruh sistem sebagai kotak hitam, tetapi begitu
pemodelan domain telah selesai, kotak hitam diubah menjadi kolaborasi beberapa objek.
Sebagai contoh, Gambar 5.A3 dalam studi kasus di Bagian 5.
Selain itu, diagram kelas analisis menyajikan struktur statis sistem, abstraksi sistem, dan
hubungannya. Ini berisi kelas yang mewakili entitas dengan karakteristik umum, termasuk
atribut, operasi, dan asosiasi yang mewakili hubungan antar kelas. Kelas-kelas digambarkan
oleh persegi panjang, dan jalur koneksi mewakili hubungan antara kelas-kelas. Kelas
membutuhkan nama dalam persegi panjang, sedangkan asosiasi mungkin tidak memiliki nama
yang dilampirkan. Selain itu, lampiran berlian merupakan hubungan agregasi. Jika berlian diisi,
itu adalah agregasi dependen; jika tidak independen, yaitu, objek yang teragregasi dapat eksis
secara terpisah. Gambar 5.A4 dalam studi kasus pada Bagian 5.7 menggambarkan diagram
kelas analisis untuk sistem kontrol trafik - cahaya.
www.it-ebooks.info
224
METODOLOGI TEKNIK PERSYARATAN
Penggunaan pendekatan berorientasi objek dalam pemodelan sistem waktu nyata menyediakan banyak
karakteristik yang diinginkan:
•
Distribusi dan konkurensi
•
Pengelolaan kompleksitas yang efektif
•
Dapat digunakan kembali yang disempurnakan
•
Keterlacakan yang luar biasa
•
Meningkatkan pemahaman dan pemeliharaan
•
Ekstensibilitas yang meningkat
•
Modularitas desain
Namun demikian, ada kelemahan potensial saat menggunakan pendekatan berorientasi objek dengan waktu
kritis embedded system, seperti yang dibahas di Bagian 4.4.3.
Pandangan kritis tentang OOA dan diskusi tentang kelemahan spesifik menggunakan UML di analisis
fase tersedia dalam Gelbard et al. (2010). Kritik mereka yang dibenarkan berkonsentrasi pada
pengamatan bahwa “representasi UML belum efektif dalam proyek skala besar untuk konteks dan
komunikasi. "Mereka juga berpendapat bahwa" metodologi OOA kurang memiliki kejelasan dan
kelengkapan. "Namun, secara luas diakui bahwa pendekatan berorientasi objek sangat mendukung rancangan
dan penerapan fase pengembangan perangkat lunak (waktu nyata) (Agarwal dan Sinha, 2003).
5.3.3 Rekomendasi tentang Pendekatan Spesifik
Diskusi sebelumnya menggambarkan tantangan khas yang dihadapi oleh insinyur perangkat lunak yang
menetapkan sistem waktu nyata:
•
Menggabungkan fungsionalitas perangkat keras tingkat rendah dan fungsi perangkat lunak dan sistem tingkat
yang lebih tinggi pada tingkat hierarki yang sama.
•
Pencampuran spesifikasi deskriptif dan operasional.
•
Kelalaian informasi waktu.
Di sini tidak praktis untuk meresepkan teknik tunggal yang disukai, karena diketahui bahwa tidak ada
"peluru perak" dalam hal spesifikasi perangkat lunak dan desain sistem tertentu. Oleh karena itu, setiap
pendekatan harus dipertimbangkan sebagai kasus per kasus berdasarkan kelebihannya. Kegunaan dari
setiap teknik memiliki peran penting dalam penerimaan awal dan kesuksesan seumur hidup. Namun,
terlepas dari pendekatan yang dipilih, pemodelan sistem waktu nyata harus memasukkan praktik terbaik
berikut:
•
Gunakan teknik pemodelan yang seragam di seluruh spesifikasi, misalnya, dekomposisi
top-down bersama dengan analisis terstruktur atau pendekatan berorientasi objek.
•
Pisahkan spesifikasi operasional dari perilaku deskriptif.
www.it-ebooks.info
225
PERSYARATAN DOKUMEN
•
Gunakan level abstraksi yang konsisten dalam model dan kesesuaian antara level
perbaikan antar model.
•
Model persyaratan nonfungsional sebagai bagian dari model spesi fi kasi, khususnya, sifat
waktu.
•
Menghilangkan perangkat keras - partisi perangkat lunak dalam fase spesifikasi (yang merupakan
aspek desain daripada analisis; spesifikasi menjelaskan hanya apa
sistem waktu nyata harus dilakukan, bukan bagaimana hal itu dilakukan).
Akhirnya, perlu dicatat bahwa batas antara analisis dan desain biasanya kabur. Hal yang sama
berlaku untuk batas lainnya antara desain dan implementasi, juga. Dan setiap organisasi dapat
dengan bebas menyesuaikan garis batas itu sesuai dengan kebutuhan dan preferensi.
5.4 DOKUMEN PERSYARATAN
Ada banyak cara untuk mengatur spesifikasi kebutuhan perangkat lunak (SRS), tetapi IEEE Std
830 - 1998 menyediakan templat suara tentang seperti apa tampilan SRS (IEEE, 1998). SRS
dapat dilihat sebagai kontrak yang mengikat antara desainer , programmer , penguji , dan
pelanggan , dan itu mencakup banyak paradigma atau pandangan untuk desain sistem.
Tampilan desain yang disarankan mencakup kombinasi dekomposisi, ketergantungan,
antarmuka, dan deskripsi detail. Bersama dengan materi depan boilerplate, ini membentuk
template standar untuk spesifikasi kebutuhan perangkat lunak, yang ditunjukkan pada Gambar
5.15. Bagian 1 dan 2 jelas; mereka menyediakan materi utama dan pengantar untuk SRS. Inti
SRS adalah, bagaimanapun, di bagian deskripsi, dan judulnya dapat dirinci lebih lanjut
menggunakan, misalnya, analisis terstruktur.
1.
pengantar
Tujuan
1.1
1.2 Lingkup
2.
1.3
Definisi dan Akronim
1.4
Referensi
1.5
Gambaran
Deskripsi keseluruhan
2.1
3.
Perspektif Produk
2.2
Fungsi Produk
2.3
Karakteristik Pengguna
2.4
Kendala
2.5
Asumsi dan Ketergantungan
Indeks Apendiks
Persyaratan Khusus
Gambar 5.15. Daftar isi yang disarankan untuk SRS dari IEEE Std 830 - 1998 (IEEE, 1998).
www.it-ebooks.info