manajer kesalahan subsistem

Manajer Konfigurasi subsistem

subsistem Power Manager

Tautan Komunikasi

Gambar 7.4 Arsitektur tingkat tinggi stasiun cuaca

Subsistem Komunikasi

Pengumpulan Data subsistem

Instrumen subsistem

Anda mengidentifikasi komponen utama yang membentuk sistem dan interaksinya, dan kemudian dapat
mengatur komponen menggunakan pola arsitektur seperti model berlapis atau model client-server.
Namun, ini tidak penting pada tahap ini.

Desain arsitektur tingkat tinggi untuk perangkat lunak stasiun cuaca ditunjukkan pada Gambar 7.4.
Stasiun cuaca terdiri dari subsistem independen yang berkomunikasi dengan menyiarkan pesan pada
infrastruktur umum, ditunjukkan sebagai tautan Komunikasi pada Gambar 7.4. Setiap subsistem
mendengarkan pesan pada infrastruktur itu dan mengambil pesan yang dimaksudkan untuk mereka. Ini
adalah gaya arsitektur lain yang umum digunakan selain yang dijelaskan dalam Bab 6.

Sebagai contoh, ketika subsistem komunikasi menerima perintah kontrol, seperti shutdown, perintah
tersebut diambil oleh masing-masing subsistem lainnya, yang kemudian mematikan dirinya sendiri
dengan cara yang benar. Manfaat utama dari arsitektur ini adalah kemudahan untuk mendukung
konfigurasi subsistem yang berbeda karena pengirim pesan tidak perlu mengalamatkan pesan ke
subsistem tertentu.
Gambar 7.5 menunjukkan arsitektur dari subsistem pengumpulan data, yang disertakan pada Gambar
7.4. Objek Pemancar dan Penerima berurusan dengan pengelolaan komunikasi dan objek WeatherData
merangkum informasi yang dikumpulkan dari instrumen dan ditransmisikan ke sistem informasi cuaca.
Pengaturan ini mengikuti pola produsen-konsumen, yang dibahas pada Bab 20.

7.1.3 Identifikasi kelas objek

Pada tahap proses desain ini, Anda harus memiliki beberapa ide tentang objek penting dalam sistem
yang Anda desain. Saat pemahaman Anda tentang desain berkembang, Anda menyempurnakan ide-ide
ini tentang objek sistem. Deskripsi use case membantu mengidentifikasi objek dan operasi dalam sistem.
Dari uraian Laporan kasus penggunaan cuaca, jelas bahwa objek yang mewakili instrumen yang
mengumpulkan data cuaca akan diperlukan, begitu pula objek yang mewakili ringkasan data cuaca. Anda
juga biasanya membutuhkan level tinggi

Hal 182

Pengumpulan data

Pemancar

Penerima

ulang

Data Cuaca

objek sistem atau objek yang merangkum interaksi sistem yang didefinisikan dalam kasus penggunaan.
Dengan mengingat objek-objek ini, Anda dapat mulai mengidentifikasi kelas objek dalam sistem.

Ada berbagai proposal yang dibuat tentang cara mengidentifikasi kelas objek dalam sistem berorientasi
objek:

1. Gunakan analisis gramatikal dari deskripsi bahasa alami dari sistem yang akan dibuat
dibangun. Objek dan atribut adalah kata benda: operasi atau layanan adalah kata kerja (Abbott, 1983).
2. Gunakan entitas nyata (benda) dalam domain aplikasi seperti pesawat terbang, peran seperti manajer
atau dokter, acara seperti permintaan, interaksi seperti rapat, lokasi seperti kantor, unit organisasi
seperti perusahaan, dan

seterusnya (Coad dan Yourdon, 1990: Shlaer dan Mellor, 1988; Wirfs-Brock

et al., 1990).

3. Gunakan analisis berbasis skenario di mana berbagai skenario penggunaan sistem diidentifikasi dan
dianalisis secara bergantian. Saat setiap skenario dianalisis, tim yang bertanggung jawab untuk analisis
harus mengidentifikasi objek, atribut, dan operasi yang diperlukan (Beck dan Cunningham, 1989).

Dalam praktiknya, Anda harus menggunakan beberapa sumber pengetahuan untuk menemukan kelas
objek. Kelas objek, atribut, dan operasi yang awalnya diidentifikasi dari deskripsi sistem informal dapat
menjadi titik awal untuk desain. Informasi lebih lanjut dari pengetahuan domain aplikasi atau analisis
skenario kemudian dapat digunakan untuk menyempurnakan dan memperluas objek awal. Informasi ini
dapat dikumpulkan dari dokumen persyaratan, diskusi dengan pengguna, atau dari analisis sistem yang
ada.

Di stasiun cuaca hutan belantara, identifikasi objek didasarkan pada perangkat keras berwujud dalam
sistem. Saya tidak memiliki ruang untuk menyertakan semua objek sistem di sini, tetapi saya telah
menunjukkan lima kelas objek pada Gambar 7.6. Termometer tanah. Objek Anemometer, dan
Barometer adalah objek domain aplikasi, dan objek WeatherStation dan WeatherData telah
diidentifikasi dari deskripsi sistem dan deskripsi skenario (use case):

1. Kelas objek WeatherStation menyediakan antarmuka dasar stasiun cuaca dengan lingkungannya.
Operasinya mencerminkan interaksi yang ditampilkan di

Hal 183.

Stasiun cuaca

Data Cuaca

pengidentifikasi
suhu udara

groundTemperatures

laporanCuaca()

arah anginKecepatan angin

statuslaporan()

hemat daya (instrumen)

tekanan curah hujan

remoteControl (perintah) mengkonfigurasi ulang (perintah)

mengumpulkan()

meringkaskan()

restart (instrumen) shutdown (instrumen)

Termometer Tanah

suhu gt_Ident

sebuah Identitas
anginKecepatan anginArah

Alat pengukur jurusan angin

Barometer

tekanan bar_Ident

tinggi

dapatkan() tes()

dapatkan() tes()

dapatkan() tes()

Gambar 7.3. Dalam hal ini, saya menggunakan kelas objek tunggal untuk mengenkapsulasi semua
interaksi ini, tetapi dalam desain lain Anda dapat merancang antarmuka sistem sebagai beberapa kelas
yang berbeda.

2. Kelas objek WeatherData bertanggung jawab untuk memproses laporan cuaca

memerintah. Ini mengirimkan data ringkasan dari instrumen stasiun cuaca ke

sistem informasi cuaca.

3. Kelas objek Termometer tanah, Anemometer, dan Barometer berhubungan langsung dengan
instrumen dalam sistem. Mereka mencerminkan entitas perangkat keras yang nyata dalam sistem dan
operasi berkaitan dengan pengendalian perangkat keras itu. Objek ini beroperasi secara mandiri untuk
mengumpulkan data pada frekuensi yang ditentukan dan menyimpan data yang dikumpulkan secara
lokal. Data ini dikirimkan ke objek WeatherData berdasarkan permintaan.
Anda menggunakan pengetahuan domain aplikasi untuk mengidentifikasi objek, atribut, dan layanan
lainnya. Kita tahu bahwa stasiun cuaca seringkali berada di tempat terpencil dan menyertakan berbagai
instrumen yang terkadang salah. Kegagalan instrumen harus dilaporkan secara otomatis. Ini
menyiratkan bahwa Anda memerlukan atribut dan operasi untuk memeriksa fungsi instrumen yang
benar. Ada banyak stasiun cuaca terpencil sehingga setiap stasiun cuaca harus memiliki pengenalnya
sendiri.

Pada tahap ini dalam proses desain, Anda harus fokus pada objek itu sendiri, tanpa memikirkan
bagaimana implementasinya. Setelah Anda mengidentifikasi objek, Anda kemudian menyempurnakan
desain objek. Anda mencari fitur-fitur umum dan kemudian mendesain hierarki pewarisan untuk sistem.
Misalnya, Anda dapat mengidentifikasi superclass Instrumen, yang menentukan fitur umum semua
instrumen, seperti pengidentifikasi, serta operasi pengambilan dan pengujian. Anda juga dapat
menambahkan atribut dan operasi baru ke superclass, seperti atribut yang menjaga frekuensi
pengumpulan data.

Hal 184.

Model desain

Desain atau model sistem, seperti yang saya bahas di Bab 5, menunjukkan objek atau kelas objek dalam
sebuah sistem. Mereka juga menunjukkan asosiasi dan hubungan antara entitas ini. Model-model ini
adalah jembatan antara persyaratan sistem dan penerapan sistem. Mereka harus abstrak sehingga
detail yang tidak perlu tidak menyembunyikan hubungan antara mereka dan persyaratan sistem.
Namun, mereka juga harus menyertakan detail yang cukup bagi pemrogram untuk membuat keputusan
implementasi.

Umumnya, Anda menyiasati jenis konflik ini dengan mengembangkan model pada tingkat detail yang
berbeda. Dimana ada hubungan dekat antara kebutuhan insinyur, desainer, dan programmer, maka
model abstrak mungkin semua yang diperlukan. Keputusan desain khusus dapat dibuat saat sistem
diimplementasikan, dengan masalah diselesaikan melalui diskusi informal. Ketika hubungan antara
penentu sistem, perancang, dan pemrogram bersifat tidak langsung (misalnya sistem dirancang di satu
bagian organisasi tetapi diimplementasikan di tempat lain), maka model yang lebih rinci mungkin
diperlukan.

Oleh karena itu, langkah penting dalam proses desain adalah menentukan model desain yang Anda
butuhkan dan tingkat detail yang diperlukan dalam model ini. Hal ini tergantung pada jenis sistem yang
sedang dikembangkan. Anda merancang sistem pemrosesan data sekuensial dengan cara yang berbeda
dari sistem real-time tertanam, sehingga Anda memerlukan model desain yang berbeda. UML
mendukung 13 jenis model yang berbeda tetapi, seperti yang saya bahas di Bab 5, Anda jarang
menggunakan semua ini. Meminimalkan jumlah model yang diproduksi akan mengurangi biaya desain
dan waktu yang dibutuhkan untuk menyelesaikan proses desain.

Saat Anda menggunakan UML untuk mengembangkan desain, biasanya Anda akan mengembangkan dua
jenis model desain:

1. Model struktural, yang menggambarkan struktur statis sistem menggunakan kelas objek dan
hubungannya. Hubungan penting yang dapat didokumentasikan pada tahap ini adalah hubungan
generalisasi (pewarisan), hubungan penggunaan/penggunaan, dan hubungan komposisi.

2. Model dinamis, yang menggambarkan struktur dinamis dari sistem dan menunjukkan interaksi antar
objek sistem. Interaksi yang dapat didokumentasikan meliputi urutan permintaan layanan yang dibuat
oleh objek dan perubahan status yang dipicu oleh interaksi objek ini.

Pada tahap awal proses desain, menurut saya ada tiga model yang sangat berguna untuk menambahkan
detail pada use case dan model arsitektur:

1. Model subsistem, yang menunjukkan pengelompokan objek secara logis ke dalam subsistem yang
koheren. Ini direpresentasikan menggunakan bentuk diagram kelas dengan masing-masing subsistem
ditampilkan sebagai paket dengan objek tertutup. Model subsistem adalah model statis (struktural).

Hal 185.
Sistem Informasi Cuaca

: SatComm

Stasiun cuaca

: Tautan komunikasi

Data Cuaca

permintaan (laporan)

mengakui

laporanCuaca()

mengakui
dapatkan (ringkasan)

meringkaskan()

Kirim Laporan)

membalas (melaporkan)

mengakui

mengakui

Urutan

menggambarkan

tion

2. Model urutan, yang menunjukkan urutan interaksi objek. Ini diwakili menggunakan urutan UML atau
diagram kolaborasi. Model urutan adalah model dinamis.

3. Model mesin negara, yang menunjukkan bagaimana objek individu mengubah statusnya

respon terhadap peristiwa. Ini diwakili dalam UML menggunakan diagram negara.

Model mesin negara adalah model dinamis.

Model subsistem adalah model statis yang berguna karena menunjukkan bagaimana desain diatur ke
dalam kelompok objek yang terkait secara logis. Saya telah menunjukkan jenis model pada Gambar 7.4
untuk menunjukkan subsistem dalam sistem pemetaan cuaca. Serta model subsistem. Anda juga dapat
merancang model objek terperinci, menampilkan semua objek dalam sistem dan asosiasinya (pewarisan,
generalisasi, agregasi, dll.). Namun, ada bahaya dalam melakukan terlalu banyak pemodelan. Anda tidak
boleh membuat keputusan mendetail tentang implementasi yang benar-benar harus diserahkan kepada
pemrogram sistem.

Model urutan adalah model dinamis yang menggambarkan, untuk setiap mode interaksi. urutan
interaksi objek yang terjadi. Saat mendokumentasikan desain, Anda harus menghasilkan model urutan
untuk setiap interaksi yang signifikan. Jika Anda telah mengembangkan model use case maka harus ada
model urutan untuk setiap use case yang telah Anda identifikasi.

Gambar 7.7 adalah contoh model sekuens, yang ditampilkan sebagai diagram sekuens UML. Diagram ini
menunjukkan urutan interaksi yang terjadi ketika sistem eksternal meminta ringkasan data dari stasiun
cuaca. Anda membaca diagram urutan dari atas ke bawah:

1. Objek SatComms menerima permintaan dari sistem informasi cuaca

untuk mengumpulkan laporan cuaca dari stasiun cuaca. Itu mengakui penerimaan

hal 186.

permintaan ini. Panah tempel pada pesan terkirim menunjukkan bahwa sistem eksternal tidak
menunggu balasan tetapi dapat melanjutkan pemrosesan lainnya. 2. SatComms mengirimkan pesan ke
WeatherStation, melalui tautan satelit, untuk membuat a

Ringkasan data cuaca yang dikumpulkan. Sekali lagi, panah tongkat menunjukkan

bahwa SatComms tidak menangguhkan dirinya sendiri menunggu balasan.

3. WeatherStation mengirim pesan ke objek Commslink untuk meringkas

data cuaca. Dalam hal ini, gaya squared-off dari arrowhead menunjukkan bahwa turunan dari kelas
objek WeatherStation menunggu balasan. 4. Commslink memanggil metode ringkasan di objek
WeatherData dan menunggu
balasan. 5. Rangkuman data cuaca dihitung dan dikembalikan ke Weather Station melalui

objek tautan komunikasi.

6 Stasiun Cuaca kemudian memanggil objek SatComms untuk mengirimkan data yang dirangkum ke
sistem informasi cuaca, melalui sistem komunikasi satelit.

Objek SatComms dan WeatherStation dapat diimplementasikan sebagai proses bersamaan, yang
pelaksanaannya dapat ditangguhkan dan dilanjutkan. Contoh objek SatComms mendengarkan pesan
dari sistem eksternal, menerjemahkan pesan ini dan memulai operasi stasiun cuaca.

Diagram urutan digunakan untuk memodelkan perilaku gabungan dari sekelompok

objek tetapi Anda mungkin juga ingin meringkas perilaku objek atau subsistem

dalam menanggapi pesan dan peristiwa. Untuk melakukan ini, Anda dapat menggunakan model mesin
negara

yang menunjukkan bagaimana instance objek mengubah status tergantung pada pesan yang
dikirimkannya

menerima. UML mencakup diagram keadaan, yang awalnya ditemukan oleh Harel (1987).

menggambarkan model mesin negara. Gambar 7.8 adalah diagram keadaan untuk sistem stasiun cuaca
yang menunjukkan bagaimana responsnya terhadap permintaan berbagai layanan.

Anda dapat membaca diagram ini sebagai berikut:

1. Jika status sistem adalah Shutdown maka sistem dapat merespons restart(), reconfigure(). atau pesan
powerSave(). Panah tak berlabel dengan gumpalan hitam menunjukkan bahwa keadaan Shutdown
adalah keadaan awal. Pesan restart() menyebabkan transisi ke operasi normal. Baik pesan powerSave()
dan reconfigure() menyebabkan transisi ke keadaan di mana sistem mengonfigurasi ulang dirinya
sendiri. Diagram status menunjukkan bahwa rekonfigurasi hanya diperbolehkan jika sistem telah
dimatikan.

2. Dalam keadaan Berjalan, sistem mengharapkan pesan lebih lanjut. Jika pesan shutdown() diterima,
objek kembali ke status shutdown.

3. Jika pesan reportWeather() diterima, sistem berpindah ke status Meringkas. Saat ringkasan selesai,
sistem berpindah ke status Mengirimkan di mana informasi ditransmisikan ke sistem jarak jauh. Ini
kemudian kembali ke status Running.

Hal 187.

Terkendali

matikan()

Operasi
remoteControl()

Matikan

mengulang kembali()

Berlari

statuslaporan()

Pengujian

konfigurasi ulang() hemat daya()

konfigurasi selesai

dermaga

koleksi selesai

transmisi dilakukan

tes selesai

Mengkonfigurasi

Mengumpulkan

Mengirimkan
laporanCuaca ()

ringkasan cuaca selesai

Meringkas

Diagram te cuaca

4. Jika pesan report Status() diterima, sistem berpindah ke status Pengujian. lalu status Mengirimkan,
sebelum kembali ke status Berjalan.

5. Jika sinyal dari jam diterima, sistem berpindah ke status Mengumpulkan, di mana ia mengumpulkan
data dari instrumen. Setiap instrumen diinstruksikan secara bergiliran untuk mengumpulkan datanya
dari sensor terkait.

6. Jika pesan remoteControl() diterima, sistem berpindah ke keadaan terkendali yang akan merespons
serangkaian pesan berbeda dari ruang kendali jarak jauh. Ini tidak ditampilkan pada diagram ini.

State diagram adalah model tingkat tinggi yang berguna dari sistem atau operasi objek. Anda biasanya
tidak memerlukan diagram status untuk semua objek dalam sistem. Banyak objek dalam sistem relatif
sederhana dan model keadaan menambahkan detail yang tidak perlu pada desain.

7.1.5 Spesifikasi antarmuka

Bagian penting dari setiap proses desain adalah spesifikasi antarmuka antara komponen dalam desain.
Anda perlu menentukan antarmuka sehingga objek dan subsistem dapat dirancang secara paralel.
Setelah antarmuka ditentukan, pengembang objek lain dapat berasumsi bahwa antarmuka akan
diimplementasikan.

Desain antarmuka berkaitan dengan menentukan detail antarmuka ke sebuah

objek atau sekelompok objek. Ini berarti mendefinisikan tanda tangan dan semantik dari

hal 188.

Pelaporan sinterfaces

antarmuka Remote Control

weatherReport (WS-Ident): Laporan statusReport (WS-Ident): Laporan

startinstrument (instrumen): iStatus stopinstrument (instrumen): iStatus mengumpulkan Data

(instrumen): iStatus menyediakan Data (instrumen): string

layanan yang disediakan oleh objek atau sekelompok objek. Antarmuka dapat ditentukan dalam UML
menggunakan notasi yang sama dengan diagram kelas. Namun, tidak ada bagian atribut dan
"antarmuka" stereotip UML harus disertakan di bagian nama. Semantik antarmuka dapat ditentukan
menggunakan bahasa batasan objek (OCL). Saya menjelaskan hal ini di Bab 17, di mana saya membahas
rekayasa perangkat lunak berbasis komponen. Saya juga menunjukkan cara alternatif untuk
merepresentasikan antarmuka di UML.

Anda tidak boleh menyertakan detail representasi data dalam desain antarmuka, karena atribut tidak
ditentukan dalam spesifikasi antarmuka. Namun, Anda harus menyertakan operasi untuk mengakses
dan memperbarui data. Karena representasi data disembunyikan, itu dapat dengan mudah diubah tanpa
memengaruhi objek yang menggunakan data itu. Ini mengarah pada desain yang secara inheren lebih
dapat dipelihara. Misalnya, representasi array dari tumpukan dapat diubah menjadi representasi daftar
tanpa memengaruhi objek lain yang menggunakan tumpukan. Sebaliknya, seringkali masuk akal untuk
mengekspos atribut dalam model desain statis, karena ini adalah cara yang paling ringkas untuk
mengilustrasikan karakteristik penting dari objek.
Tidak ada hubungan 1:1 yang sederhana antara objek dan antarmuka. Objek yang sama mungkin
memiliki beberapa antarmuka, yang masing-masing merupakan sudut pandang metode yang
disediakannya. Ini didukung secara langsung di Java, di mana antarmuka dideklarasikan secara terpisah
dari objek dan antarmuka implementasi objek. Sama halnya, sekelompok objek semuanya dapat diakses
melalui satu antarmuka.

Gambar 7.9 menunjukkan dua interface yang dapat didefinisikan untuk stasiun cuaca. Antarmuka kiri
adalah antarmuka pelaporan yang menentukan nama operasi yang digunakan untuk menghasilkan
laporan cuaca dan status. Ini memetakan langsung ke operasi di objek WeatherStation. Antarmuka
kendali jarak jauh menyediakan empat operasi, yang memetakan ke satu metode di objek
WeatherStation. Dalam hal ini, masing-masing operasi dikodekan dalam string perintah yang terkait
dengan metode kendali jarak jauh, ditunjukkan pada Gambar 7.6.

7.2

Pola desain

Pola desain berasal dari ide-ide yang dikemukakan oleh Christopher Alexander (Alexander et al., 1977),
yang menyarankan bahwa ada pola umum tertentu dari desain bangunan yang secara inheren
menyenangkan dan efektif. Pola adalah gambaran dari masalah dan inti dari solusinya, sehingga solusi
tersebut dapat digunakan Kembali

Hal 189.