modul praktikum analisis dan perancangan sistem · modul praktikum analisis dan perancangan sistem...

Modul Praktikum Analisis dan Perancangan Sistem Halaman 1 dari 58


Praktikum Analisis dan Perancangan REKAYASA KEBUTUHAN

1.1. TUJUAN PRAKTIKUM :

a) Mahasiswa mampu memahami konsep rekayasa kebutuhan

b) Mahasiswa mampu memahami proses-proses dalam rekayasa kebutuhan

c) Mahasiswa mampu menerapkan teori-teori elisitasi kebutuhan

d) Mahasiswa mampu menyusun kebutuhan perangkat lunak

e) Mampu melakukan verifikasi kebutuhan sesuai dengan parameter

1.2. DASAR TEORI

Konsep Rekayasa Kebutuhan

Kebutuhan adalah kondisi atau kemampuan yang dibutuhkan oleh user

untuk mengatasi suatu masalah atau untuk mencapai tujuan tertentu. Kondisi

atau kemampuan yang harus dimiliki oleh sistem untuk memenuhi sebuah kontrak,

standar, spesifikasi atau dokumen resmi yang ditetapkan. Kata rekayasa

(engineering) sendiri memiliki arti yaitu proses atau serangkaian kegiatan yang

terstruktur untuk mengelola serangkaian sumber daya sehingga membentuk

suatu sistem yang memiliki nilai bagi penggunanya.

Sommervile (2007) mengartikan bahwa rekayasa kebutuhan (software

engineering) sebagai suatu proses mewujudkan serangkaian layanan yang

dibutuhkan oleh pelanggan atas suatu sistem dan batasan-batasan yang harus

dipenuhi ketika dibangun maupun dioperasikan. Kebutuhan dikategorikan

menjadi 3 jenis :

1) Kebutuhan Fungsional

2) Kebutuhan Non Fungsional

3) Usability


Proses rekayasa kebutuhan perangkat lunak terdiri dari beberapa aktifitas

yaitu:

a) Elisitasi dan analisis kebutuhan

b) Spesifikasi kebutuhan

c) Validasi dan verifikasi kebutuhan

d) Manajemen kebutuhan

Elisitasi dan Analisis Kebutuhan

Elisitasi atau pengumpulan kebutuhan merupakan aktifitas awal dalam proses

rekayasa kebutuhan. Proses elisitasi kebutuhan dilakukan sebelum kebutuhan

dapat dianalisis, dimodelkan, atau ditetapkan. Elisitasi kebutuhan adalah

sekumpulan aktifitas yang ditujukan untuk menemukan kebutuhan suatu sistem

melalui komunikasi dengan pelanggan, pengguna sistem dan pihak lain yang

memiliki kepentingan dalam pengembangan sistem (Sommervile and Sawyer,

1997).

Pada aktivitas ini berbagai kebutuhan dari para pemangku kepentingan

dikumpulkan. Pemangku kepentingan (stakeholder) setiap adalah pihak yang

memiliki kepentingan terhadap proyek pengembangan perangkat lunak.

Pemangku kepentingan dapat diklasifikasikan sebagai berikut: pelanggan, pemilik

modal, pemilik sistem, pengguna, regulator, penyelia, pengembang, analis sistem,

dan programmer.

Berikut ini merupakan langkah-langkah untuk elisitasi kebutuhan (Sommervile

and Sawyer, 1997):

1) Identifikasi orang-orang yang akan membantu menentukan kebutuhan

dan memahami organisasi. Menilai kelayakan bisnis dan teknis untuk

sistem yang di usulkan.

2) Menentukan lingkungan teknis (misalnya, komputasi arsitektur, sistem

operasi, kebutuhan telekomunikasi) kemana sistem atau produk akan

ditempatkan.

3) Identifikasi ranah permasalahan, yaitu karakteristik lingkungan bisnis

yang spesifik ke ranah aplikasi


4) Menentukan satu atau lebih metode elisitasi kebutuhan misalnya

wawancara, discussion group, dan pertemuan tim.

5) Meminta partisipasi dari banyak orang sehingga dapat mereduksi

dampak dari kebutuhan yang bias yang bisa muncul dari sudut pandang

yang berbeda dari pemangku kepentingan.

6) Mengidentifikasi kebutuhan yang ambigu dan menyelesaikannya.

7) Membuat skenario penggunaan untuk membantu pelanggan/

pengguna mengidentifikasi kebutuhan utama.

Contoh:

Deskripsikan pemangku kepentingan dari sistem layanan ATM suatu bank.

Jawab:

1) Nasabah Bank: yaitu orang yang menerima layanan sistem

2) Representatif dari bank lain: bank yang melakukan perjanjian timbal

balik penggunaan ATM untuk para nasabah

3) Manajer Bank: orang yang memperoleh informasi manajemen dari

sistem

4) Administrator Basis data: orang yang bertanggung jawab untuk

menggabungkan sistem dengan basis data nasabah.

Dalam melakukan elisitasi terdapat beberapa teknik yang dapat membantu

analis:

1) Wawancara, pada saat wawancara analis sistem memberikan

beberapa pertanyaan kepada pemangku kepentingan tentang sistem

yang digunakan (existing) dan sistem yang akan dikembangkan.

Beberapa panduan yang perlu diperhatikan pada saat wawancara

adalah: pemilihan narasumber (interviewer) yang potensial, membuat

perjanjian dengan narasumber potensial, menyiapkan struktur

pertanyaan yang lengkap dan jelas, dan memilih orang yang

diwawancarai secara pribadi dan merekamnya.

2) Kuisioner, didesain dengan menggunakan standar kuisioner, kuisioner

dikirim ke lingkungan kerja end-user, dan struktur respon diringkas

dalam statistik distribusi.


3) Observasi, kegiatan ini dilakukan dengan mengunjungi lokasi

pengamatan dan merekam kejadian dalam lokasi pengamatan

termasuk volume dan pengolahan lembar kerja.

4) Prototyping, adalah versi awal dari sistem perangkat lunak yang

digunakan untuk mendemonstrasikan konsep, mencoba pilihan

rancangan, dan secara umum, mencari lebih jauh tentang kesalahan

dan solusi yang dimungkinkan.

Spesifikasi Kebutuhan

Spesifikasi kebutuhan adalah proses untuk menjelaskan kebutuhan PL yang

telah didefinisikan sebelumnya secara lebih detil dan tepat yang akan menjadi

dasar bagi perancangan dan implementasi.

Contoh :

Definisi kebutuhan (requirement definition) :

1. PL harus mampu menyediakan sarana untuk menampilkan dan mengakses

file-file yang dibuat oleh tool yang lain. (SRS_PRJ_100)

Spesifikasi kebutuhan (requirement specification) :

1.1 Pengguna harus disediakan fasilitas untuk mendefinisikan tipe file.

(SRS_PRJ_101)

1.2 Setiap tipe file direpresentasikan dengan ikon tertentu pada layar

pengguna. (SRS_PRJ_102)

Panduan penyusunan kebutuhan (SMART)

Dalam konteks penyusunan hendaklah menspesifikasi kebutuhan yang SMART.

Tujuannya bukanlah untuk membuktikan bahwa spesifikasi kebutuhan yang telah

ditetapkan sudah benar secara teknis (yaitu bahwa kebutuhan yang dinyatakan

adalah benar-benar yang dibutuhkan, tapi lebih kepada agar spesifikasi kebutuhan

tersebut dapat dicek dan diverifikasi kebenarannya dari aspek ekspresi (bukan isi)

1) Specific (spesifik)

Setiap kebutuhan harus menyebutkan tepat seperti yang dibutuhkan.

Hindari penggunaan asumsi dalam menginterpretasikan arti sebuah

kalimat kebutuhan.


2) Measureable (terukur)

Suatu kebutuhan akan diuji nanti ketika selesai dibangun, sehingga

penting untuk menyusun kalimat kebutuhan yang terukur sehingga

memudahkan dalam melakukan pengujian.

3) Attainable (dapat dicapai)

Memastikan bahwa kebutuhan yang didefinisikan dapat dicapai sesuai

dengan batas-batas kekuatan dan pengetahuan manusia.

4) Realizable (dapat direalisasikan)

Suatu kebutuhan haruslah dapat direalisasikan dengan

mempertimbangkan sumber daya yang dimiliki.

5) Traceable/bounded (memiliki dimensi waktu/dapat dilacak)

Suatu kebutuhan hendaklah dapat diselesaikan atau direalisasikan

dalam waktu yang telah ditentukan. Dalam hal ini adalah sesuai dengan

rencana proyek (project plan). Selain itu kebutuhan juga perlu suatu

mekanisme untuk menjustifikasi alasan keberadannya. Kebutuhan

mungkin muncul karena ada kebutuhan lainnya.

Validasi dan verifikasi kebutuhan

Proses ini dilakukan untuk memastikan bahwa seluruh kebutuhan yang telah

didapatkan telah didefinisikan dan dispesifikasikan adalah benar, akurat dan

lengkap. Parameter validasi:

1) Validity, apakah sistem menyediakan semua fungsi yang mendukung

semua yang dibutuhkan oleh customer?

2) Consistency, apakah ada kebutuhan yang konflik?

3) Comprehensibility, apakah semua fungsi yang diinginkan customer

sudah tercakup didalamya? (kelengkapan)

Parameter verifikasi:

1) Readability

2) Testability

3) Completeness

4) Identifiability

5) Ambiguity


Manajemen kebutuhan

Aktifitas untuk melakukan kontrol terhadap kebutuhan yang sedang maupun

telah didefinisikan dan dispesifikasikan :

1) Identifikasi, bagaimana setiap kebutuhan dapat diidentifikasi dengan

mudah (Cont. : SRS_PRJ_XXX, IRS_PRJ_XXX)

2) Manajemen perubahan, bagaimana mekanisme untuk menangani

perubahan kebutuhan yang terjadi

3) Dokumentasi, SRS dan IRS sebagai deliverable, ECP, PCR

4) Tracking, penelusuran informasi yang berhubungan dengan sebuah

kebutuhan (sumber/asal, alokasi ke perancangan)

1.3. SOAL-SOAL LATIHAN STUDI KASUS :

Vario Advertising merupakan perusahaan biro iklan yang terletak di Jalan

Soekarno Hatta Malang. Vario didirikan pada tahun 2000. Awalnya perusahaan ini

berkonsentrasi pada periklanan untuk industri motor indonesia, yang sebagian

besar pemasarannya di daerah Jawa dan Bali. Namun seiring berjalannya waktu,

perusahaan diperluas menuju skala internasional dan memiliki klien di berbagai

industri manufaktur dan jasa. Strategi perusahaan bertujuan untuk terus tumbuh

perlahan-lahan dan mengembangkan ke pasar internasional.

Dalam menjalankan bisnisnya Vario Advertising bekerjasama dengan

perusahaan lain yang bisa disebut juga sebagai klien. Setiap kerjasama yang

dilakukan oleh Vario terdapat dokumentasi yang selalu dibuat dan disimpan

secara baik. Disamping itu dalam melakukan kerjasama biasanya dari pihak klien

akan mengirimkan beberapa perwakilannya untuk melakukan komunikasi dan

koordinasi dengan Vario. Begitu juga dengan Vario, mengirimkan wakilnya untuk

melakukan koordinasi dengan klien. Perwakilan dari vario memungkinkan

bertanggung jawab pada klien yang berbeda dalam pekerjaan yang berbeda pula.

Tentunya hal seperti ini perlu dikelola secara benar agar tiak overlap, baik target

kerja, pengelolaan dana, dan penjadwalan kerja.


Untuk mendukung skala bisnis internasional, perusahaan memiliki strategi

dengan berfokus dalam membangun suatu sistem informasi guna membantu

aktifitas proses bisnis yang berjalan diperusahaan tersebut. Beberapa aktifitas dan

kebutuhan yang perlu didefinisikan dalam sistem tersebut terangkum sebagai

berikut

Sistem mampu merekam detail informasi klien termasuk order layanan

kampanye iklan. Dalam perekaman informasi setiap klien, data terkait nama,

alamat, kontak klien harus masuk didalamnya. Selain itu dalam pencatatan

informasi layanan order kampanye iklan, harus terekam terkait judul kampanye,

tanggal mulai dan selesai pelaksanaan kampanye, estimasi biaya, biaya riil, dan

tanggal pembayaran. Selanjutnya setelah perekaman telah dilakukan maka sistem

mampu menyediakan suatu fungsi mencetak invoice bagi klien yang dapat

dieksekusi oleh lebih dari satu akun staf yang tersedia di sistem tersebut.

Demikian pula dengan proses pembayaran yang dilakukan oleh klien juga dapat

dilayani oleh beberapa akun yang tersedia di sistem dan terekam secara baik. Pada

kebutuhan ini sistem nantinya juga perlu untuk merekam informasi tentang staf

yang ditugaskan untuk terlibat dalam proses produksi iklan beserta kampanye

iklan untuk tiap klien termasuk mencatat manager proyek yang terlibat dalam

kampanye. Selanjutnya sistem juga dapat mekakukan pengecekan status

kampanye, baik proses produksi hingga akhir pelaksaaan kampanye dan

kesesuaian dengan biaya yang tersedia.

Sistem mampu menyediakan fungsi bagi staf kreatif untuk merekam rincian

proses produksi iklan termasuk proses pengembangan konsep kampanye iklan.

Rincian proses produksi iklan yang dimaksud adalah kemampuan sistem untuk

merekam catatan ide detail untuk kampanye dan konsep iklan yang bisa diakses

atau dilihat oleh staf lain termasuk didalamnya informasi progress produksi hingga

penjadwalan kampanye iklan dimulai hingga selesai.

Sistem mampu menyediakan fungsi merekam detail informasi seluruh staf

perusahaan bagi staf. Detail informasi staf yang direkam antara lain pengelolaan

data staf kreatif dan staf administratif. Disamping itu juga sistem harus mampu

untuk menyediakan fungsi bagi staf keuangan dan manajer proyek untuk

memberikan grade nilai kepada staf dan mengakomodir proses pembayaran staf


berdasarkan grade nilai tersebut dan terekam dalam sistem. Selain itu sistem juga

perlu mengakomodir fungsi untuk menghitung bonus tahunan dari setiap staf

berdasarkan kinerja .

Dalam sistem yang dibangun, perusahaan menginginkan data terkait dengan

klien, kampanye, iklan dan staf dapat diakses antar kantor yang berbeda dan untuk

kemudahan pengoperasian, sistem diharapkan dapat diakses menggunakan

beberapa bahasa yang berbeda pula.

1. Tentukanlah domain permasalahan yang mungkin ditemukan di lapangan

terkait dengan studi kasus tersebut!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

2. Tentukanlah pemangku kepentingan beserta dengan deskripsinya!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

3. Susunlah pertanyaan-pertanyaan untuk melakukan elisitasi kebutuhan.

Pertanyaan-pertanyaan tersebut dikelompokan berdasarkan pemangku

kepentingan yang terkait. Selain itu tentukan juga metode apa yang cocok

untuk melakukan elisitasi!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________


4. Susunlah pernyataan kebutuhan sesuai dengan konsep SMART. Kelompokan

berdasarkan kategorinya: Kebutuhan Fungsional, Kebutuhan Non Fungsional,

dan Usability.

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

5. Perhatikan dan analisis kebutuhan berikut ini:

1) “Sistem dapat melayani permintaan peminjaman ruang rapat secara

bersamaan dengan cepat.”

2) “Ketika modul X memanggil modul Z, berkas catatan pesannya

diperbaharui.”

3) “Sistem tentunya dapat menyimpan dokumentasi rapat dalam format

bervariasi, seperti misalnya: JPG, TIF, BMP, dsb.”

Apakah kebutuhan tersebut telah memenuhi aspek Spesific (S) pada konsep

SMART? Jelaskan jawaban Anda kemudian perbaiki kebutuhan tersebut

apabila belum memenuhi aspek Specific (S).

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________


1) “Sistem dapat memproses data permohonan rapat dengan cepat dan

akurat.”

2) “Besaran berkas yang diunggah pada dokumen notulensi rapat tidak

terlalu besar ukurannya.”


Apakah kebutuhan tersebut telah memenuhi aspek Measureable (M) pada

konsep SMART? Jelaskan jawaban Anda kemudian perbaiki kebutuhan

tersebut apabila belum memenuhi aspek Measureable (M).

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________


1) “Sistem memiliki tingkat ketersediaan 100% dan dapat dihandalkan

100%.”

2) “Sistem akan bekerja 24 jam / hari serta 365 hari/ tahun tanpa

berhenti.”

3) “Sistem dapat mengirimkan data maksimal 10 TB per detik.”

Apakah kebutuhan tersebut telah memenuhi aspek Attainable (A) pada


tersebut apabila belum memenuhi aspek Attainable (A).

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________


1) “Sistem akan memiliki ketersediaan ruang rapat 97%.”

Apakah kebutuhan tersebut telah memenuhi aspek Realizeable (R) pada


tersebut apabila belum memenuhi aspek Realizeable (R).

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________


_______________________________________________________________

_______________________________________________________________

9. Berdasarkan kebutuhan yang telah didefinisikan pada studi kasus: Sistem

Informasi Manajemen Ruangan dan Notulensi Rapat, lakukan proses validasi

dan verifikasi kebutuhan berdasarkan parameter-parameter yang telah

ditentukan.

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________


Praktikum Analisis dan Perancangan PEMODELAN KEBUTUHAN TERSTRUKTUR


a) Mahasiswa mampu memahami konsep-konsep pemodelan dalam rekayasa

kebutuhan.

b) Mahasiswa mampu memahami konsep pendekatan terstruktur dalam

pemodelan kebutuhan.

c) Mahasiswa mampu memahami konsep pendekatan berorientasi obyek dalam

pemodelan kebutuhan.

1.2. DASAR TEORI A. Konsep Pemodelan Kebutuhan

Pemodelan dalam pengembangan perangkat lunak bermaksud untuk

menggambarkan sistem dalam bentuk yang lebih mudah dipahami. Kebutuhan

adalah suatu hal dalam pengembangan perangkat lunak yang perlu dimodelkan.

Tujuan dari pemodelan kebutuhan antara lain adalah:

Menjelaskan apa saja kebutuhan dari pengguna,

Menjadi dasar dari pengembangan perangkat lunak,

Menjadi referensi dalam proses validasi kebutuhan.

Pemodelan kebutuhan terdapat dua pendekatan, yaitu pendekatan

Terstruktur dan Berorientasi Objek. Terdapat beberapa prinsip dalam

memodelkan kebutuhan, antara lain adalah:

Model kebutuhan yang dibuat harus sesuai dengan kebutuhan pada domain

permasalahan, what bukan how.

Model kebutuhan harus bisa dilacak pada model perancangan yang dihasilkan

pada fase perancangan.

Model kebutuhan disajikan dengan lengkap dan mampu memperjelas

pemahaman secara utuh tentang domain permasalahan, fungsionalitas dan

perilaku sistem.


Model kebutuhan hendaknya dapat mengurangi tingkat keterkaitan antar

modul/klas (kopling).

Model kebutuhan harus dapat memberikan nilai manfaat bagi seluruh

stakeholder

Model kebutuhan direpresentasikan dalam notasi yang sederhana dan

meniadakan duplikasi, sehingga dapat dengan mudah dipahami oleh

stakeholder.

Tipe-tipe model kebutuhan antara lain adalah:

Scenario-based Models

Model kebutuhan yang menggambarkan sistem dari sudut pandang aktor.

Data Models

Model kebutuhan yang menggabarkan model data atau informasi dari domain

permasalahan.

Class-oriented Models

Model kebutuhan yang menggambarkan model klas yang relevan dengan

domain permasalahan.

Flow-oriented Models

Model kebutuhan yang menggambarkan suatu aliran yang terjadi di dalam

sistem. Aliran data dan proses dapat digambarkan menggunakan model flow-

oriented model.

Behavioral Models

Model perilaku dari sistem dalam menanggapi even-even dari luar sistem.

B. Pemodelan Terstruktur

Konsep perancangan sistem dengan pendekatan terstruktur (Structural

Analysis) pertama kali diperkenalkan oleh Tom DeMarco pada tahun 1979. Tom

DeMarco menuliskan penjelasannya tentang pendekatan terstruktur pada

bukunya yang berjudul “Structured Analysis and System Specification”. Dalam

buku tersebut penekanan utamanya adalah pada proses spesifikasi struktur

domain masalah.


Terdapat tiga hal yang diperhatikan dalam pemodelan kebutuhan dengan

pendekatan terstruktur, yaitu, pemodelan data, proses dan perilaku dari sistem.

Penggambaran data menggunakan Entity Relationship Diagram (ERD),

penggambaran proses menggunakan Data Flow Diagram/ Control Flow Diagram

(DFD/CFD), dan penggambaran perilaku menggunakan State Transition Diagram

(STD). Terdapat juga beberapa model yang melengkapi penjelasan ketiga model

terdahulu seperti, Data Dictionary (kamus data), PSPEC (Process Specification),

dan CSPEC (Control Specification). Gambar 2.1 menunjukkan elemen-elemen

pemodelan kebutuhan dengan pendekatan terstruktur.

Gambar 2.1. Elemen-Elemen dalam Pemodelan Kebutuhan

Data Dictionary

Kamus data atau systems data dictionary adalah katalog fakta tentang data

dan kebutuhan-kebutuhan informasi dari suatu sistem informasi. Dengan Data

Dictionary analis sistem dapat mendefinisikan data yang mengalir di sistem

dengan lengkap.

Entity Relationship Diagram (ERD)

Terdapat beberapa pertanyaan yang dapat mempermudah dalam

perancangan model data, antara lain adalah:


Apa objek data utama yang diproses oleh sistem?

Bagaimana komposisi masing-masing objek data dan apa saja atributnya?

Di mana objek-objek data tersebut saat ini berada?

Apa hubungan antara masing-masing objek?

Apa hubungan antara obyek dan proses yang mengubah mereka?

Komponen-komponen yang harus ada pada pemodelan data adalah entitas,

atribut, relasi, kardinalitas dan modalitas. Gambar 2.2 menggambarkan contoh

gambaran entitas dan relasinya.

Gambar 2.2. Entity Relationship Diagram

Data Flow Diagram/ Control Flow Diagram (DFD/ CFD)

Data Flow Diagram/ Control Flow Diagram dapat digunakan untuk

menggambarkan dekomposisi proses dari sistem yang ada dalam rangka

pengembangan sistem yang baru. DFD/ CFD fokus pada peredaran data dari

entitas ke proses, proses ke proses, dan proses ke data store. Selain itu CFD juga

dapat menggambarkan perilaku proses yang terjadi pada sistem. DFD/ CFD

memiliki beberapa level detail. Model yang paling tinggi disebut sebagai Diagram

Kontek (Context Diagram). Elemen-elemen model DFD/ CFD adalah sebagai

berikut:

1. Terminator/ External Entity

Representasi entitas eksternal

Notasi: persegi panjang

Tidak memproses data

2. Data Flow

Representasi aliran data

Notasi: anak panah penuh

Umumnya satu arah

Hubungkan terminator, process dan storage

External Entity


3. Control Flow

Representasi aliran kontrol proses

Notasi: anak panah putus2

Hubungkan terminator, process dan control bar

4. Process

Representasi aktifitas sistem

Notasi: lingkaran

Memproses data

5. Storage

Representasi tempat penyimpanan data

Notasi: dua garis paralel

Data flow in = diubah, data flow out = dibaca

6. Control Bar

Representasi spesifikasi kontrol

Notasi: garis tegak

Beberapa hal yang harus diperhatikan dalam menyusun DFD/ CFD adalah sebagai

berikut:

Jumlah proses dalam satu diagram DFD : 4 + 2

Maks. 4 level dekomposisi (DFD/CFD)

Dekomposisi fungsional (DFD) :

◦ fungsi-fungsi yang saling berhubungan dikelompokkan

◦ fungsi-fungsi yang tidak berhubungan dipisahkan

◦ setiap fungsi dispesifikasi hanya sekali

Data flow membawa informasi yg diperlukan oleh sebuah proses untuk

transformasi, control flow membawa informasi yang harus

diinterpretasikan untuk merubah perilaku sistem dan/ aktifasi proses

Proses pemodelan DFD/CFD adalah proses iterasi, tidak sekali jadi

Penjenjangan CFD harus sesuai dengan DFD

1

Prosess A


DFD/ CFD merupakan model yang memiliki beberapa level detail. Mulai dari level

konteks, level 1 dan seterusnya. Semakin kebawah semakin khusus. Diagram pada

level bawah menjelaskan satu proses pada level atasnya. Gambar 2.3

memperlihatkan gambaran level yang ada pada DFD/ CFD.

Gambar 2.3. Gambaran Level pada DFD/ CFD

State Transition Diagram (STD)

State Transition Diagram adalah model yang menggambarkan tentang

perilaku sistem. STD menjelaskan perilaku sistem yang terkait dengan perubahan

state yang terjadi pada sistem. State adalah sebuah kondisi yang terlihat oleh

pengguna atau user. Dalam pembuatan STD, terdapat beberapa hal yang harus

didefinisikan, antara lain adalah State, Event, dan Action. Gambar 2.4

menunjukkan gambaran notasi STD.

Gambar 2.4. Contoh STD

Untuk mempermudah dalam pembuatan STD, terdapat beberapa langkah:

1. Buatlah daftar state dari sistem yang terlihat oleh pengguna.

2. Tunjukkan bagaimana sistem melakukan transisi dari satu state ke state yang

lain.


3. Definisikan event sebagai suatu kejadian yang memicu transisi antar state.

4. Definisikan action (aksi) yang dilakukan sistem.

5. Gambarlah STD.

1.3. SOAL-SOAL LATIHAN

1. Buatlah Data Flow Diagram untuk kasus studi Vario Advertising pada Modul

Praktikum Rekayasa Kebutuhan.

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

2. Buatlah process specification (P-Spec) dari DFD yang telah dibuat sebelumnya!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

3. Buatlah control specification (C-Spec) dari DFD yang telah dibuat sebelumnya!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

4. Buatlah data dictionary dari DFD yang telah dibuat sebelumnya!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________


5. Perhatikan diagram berikut ini: ER

a) Menurut Anda, apakah ERD diatas sudah benar? Jelaskan jawaban Anda!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

b) Jika terdapat kesalahan, lakukan analisis terhadap kesalahan yang terjadi pada

ERD tersebut dan gambarkan ulang hasil perbaikannya!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________


c) Setelah diperbaiki, amati dan jelaskan makna ERD tersebut dalam bahasa Anda

sendiri!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

6. Perhatikan deskripsi sistem dan context diagram berikut ini :

Sistem reservasi hotel adalah sistem yang berfungsi untuk membantu para

calon tamu dalam memesan kamar hotel. Tamu dapat mengisi formulir data

diri, menentukan tipe kamar dan dapat memberikan permintaan khusus.

Permintaan khusus ini menentukan ada atau tidaknya dan bagaimana

tambahan fasilitas kamar yang disediakan oleh pihak hotel. Kemudian sistem

dapat memberikan informasi harga kamar dari hotel kepada calon tamu.

Setelah pemesanan dilakukan maka tamu akan mendapatkan bukti

pemesanan kamar hotel. Kemudian dari sisi pihak hotel, pihal hotel akan

mendapatkan detail data pemesanan kamar dan data diri tamu. Pihak hotel

dapat mempublikasikan informasi tentang kondisi kamar yang dapat dipesan.

Pihak hotel memiliki informasi tentang ketersediaan kamar yang menentukan

pemesanan dapat dilakukan atau tidak.


a) Menurut Anda, apakah context diagram di atas sudah benar secara aturan

sintaks dan apakah sudah sesuai dengan deskripsi sistem yang sudah

dijelaskan? Jelaskan jawaban Anda!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

b) Jika terdapat kesalahan, lakukan analisis terhadap kesalahan yang terjadi pada

context diagram tersebut dan gambarkan ulang hasil perbaikannya!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

7. TPL airline adalah maskapai penerbangan terbaik di Indonesia. TPL airline

dapat melayani pelanggannya dengan baik, sehingga setiap tahun jumlah

pelanggannya semakin bertambah. Pada tahun 2007, pada saat pertama kali

TPL airline terbentuk, TPL airline telah memiliki 1000 pelanggan pada tahun

pertama. Hingga pada tahun 2017 ini, pelanggan TPL airline telah mencapai

lebih dari 5000 pelanggan. Untuk meningkatkan jumlah pelanggan, TPL airline

membuat sistem reservasi tiket pesawat online sehingga pelanggan yang ingin

menggunakan jasa TPL airline dapat memesan dan mendapatkan tiket tanpa

harus datang ke loket TPL airline. Selain hal tersebut, TPL airline juga

memberikan promo khusus berupa diskon 20% bagi pelanggan yang membeli

tiket lebih dari lima.

a) Buatlah ERD dari kasus yang terdapat pada ilustrasi tersebut!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________


_______________________________________________________________

_______________________________________________________________

b) Buatlah Context Diagram dan Data Flow Diagram Level 1 dari kasus yang

terdapat pada ilustrasi tersebut!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

c) Buatlah State Transition Diagram dari kasus yang terdapat pada ilustrasi

tersebut!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________


Praktikum Analisis dan Perancangan PEMODELAN KEBUTUHAN BERORIENTASI OBJEK

1.1. TUJUAN PRAKTIKUM: Memahami konsep pendekatan berorientasi objek dalam pemodelan kebutuhan

1.2. DASAR TEORI Pendekatan berorientasi objek merupakan suatu teknik atau cara pendekatan

baru dalam melihat permasalahan dari sistem (sistem perangkat lunak, sistem

informasi, atau sistem lainnya). Pendekatan berorientasi objek dipopulerkan pada

akhir tahun 1980an – 1990an oleh Booch, Rumbaugh-OMT, Jacobson-OOSE, Coad

dan Yourdon, Wirfs-Brock.

Pendekatan berorientasi objek akan memandang sistem yang akan

dikembangkan sebagai suatu kumpulan objek yang berkorespondensi dengan

objek-objek dunia nyata. Ada banyak cara untuk mengabstraksikan dan

memodelkan objek-objek tersebut, mulai dari abstraksi objek, kelas, hubungan

antar kelas sampai abstraksi sistem. Saat mengabstraksikan dan memodelkan

objek ini, data dan proses-proses yang dipunyai oleh objek akan dienkapsulasi

(dibungkus) menjadi satu kesatuan.

Hal-hal yang perlu dilakukan dalam memodelkan berorientasi objek meliputi:

Elisitasi kebutuhan customer

Identifikasi skenario / use-case (use-case diagram)

Identifikasi klas berdasarkan kebutuhan customer

Identifikasi atribut dan operasi setiap klas

Definisi struktur klas (class diagram)

Definisi model relasi antar klas (collaboration/sequence diagram)

Definisi perpindahan status sistem (statechart diagram)

Pada tahun 1996, bahasa yang digunakan untuk pemodelan berorientasi objek

dibuatlah UML (Unified Modeling Language). UML dibuat oleh Grady Booch,

James Rumbaugh dan Ivar Jacobson.


Kelebihan dari pemodelan berorientasi objek meliputi:

Sangat natural, sesuai dengan cara berpikir manusia

Dapat meningkatkan interaksi antara ahli domain masalah dengan

analis

Meningkatkan konsistensi hasil analisis

Hal ini dikarenakan dengan pemodelan berorientasi objek, mampu

mengabstraksikan atribut hingga operasi dalam sebuah objek

Konsep penurunan klas memberikan kemudahan dalam generalisasi

objek

Kemudahan dalam perubahan

Terjaganya konsistensi model antara analisis dan perancangan

Konsep reusability

KOMPONEN PADA PEMODELAN OO

Object

Menurut Rumbaugh definisi objek adalah sebuah konsep, abstraksi, atau

sesuatu yang memiliki batasan dan masalah utama serta bersifat tangible dan

intangible (sesuatu yang bisa diraba atau tidak). Karakteristik dari sebuah objek

adalah memiliki identity (identitas-pembeda), state (sekumpulan atribut) &

behaviour (sekumpulan operasi, aksi, servis).

Contoh dari objek pada sistem akademik adalah: Andi, Eko, Susi.

Notasi dari objek:

Gambar 3.1 Notasi Objek

Class

Menurut Yourdon, class (klas) adalah sebuah deskripsi dari satu atau lebih

objek yang memiliki kesatuan dari atribut dan layanan/operasi yang sama

termasuk bagaimana membuat objek baru dalam klas.

Nma Objek

Atribut2

Operasi2


Fungsi dari sebuah klas adalah sebagai gambaran umum (template, blue-print)

yang menjelaskan sekumpulan objek yang memiliki kesamaan karakteristik

(atribut dan operasi) dan cetakan dari objek. Dimana sebuah kelas akan

mempunyai sifat (atribut), kelakuan (operasi), hubungan (relationship) dan arti.

Dan suatu klas dapat diturunkan dari kelas yang lain, dimana atribut dari kelas

semula dapat diwariskan ke kelas yang baru. Klas juga digunakan untuk

menginstansiasi objek yang memiliki identitas yang berbeda.

Contoh 1: Klas Mahasiswa objek Andi, Eko, Susi

Klas memiliki bentuk abstract dan concrete. Dimana klas abstrak adalah klas

yang berasal dari sesuatu yang bersifat abstrak.

Contoh 2:

Gambar 3.2 Kelas Abstrak

Pemodelan berorientasi objek juga berfungsi untuk menemukan domain

masalah. Langkah-langkah dalam menentukan objek dan klas adalah:

Observasi langsung ke dunia industri atau lapangan (Observe first-hand)

Secara aktif menggali permasalahan dengan pertanyaan apa, siapa,

bagaimana, kapan mengapa

Selalu melihat hasil dari analisis berorientasi objek sebelumnya

Melakukan perbandingan dengan sistem yang lain

Sering membaca untuk mendapatkan informasi

Yang harus diperhatikan dalam menentukan objek dan klas adalah dengan

memperhatikan kata benda yang muncul pada domain masalah seperti:


Struktur

Perhatikan relasi antar objek termasuk ke dalam jenis generalisasi atau

agregasi

Sistem lainnya

Perlu diperhatikan juga sistem lain yang berinteraksi dengan sistem

yang akan dibangun

Sesuatu hal atau kejadian yang disimpan

Data, status atau kejadian yang harus disimpan dalam sistem

Role played

Identifikasi peran manusia dalam sistem apakah berinteraksi langsung

atau tidak berinteraksi tetapi informasinya disimpan dalam sistem

Lapangan

Informasi lokasi/posisi yang harus diingat oleh sistem

Identifikasi Atribut

Beberapa data (informasi data) yang dimiliki oleh setiap objek yang ada dalam

klas objek (Yourdan).

Langkah dalam menentukan atribut:

Identifikasi atribut umum (adjectives, possessives)

Identifikasi atribut yang relevan dengan domain masalah

Identifikasi atribut yang relevan dengan peran atau tanggung jawab

dalam sistem

Restrukturisasi atribut sehingga atomic yang bisa memunculkan

kemudahan

Reposisi atribut yang sesuai dengan hirarki klas nya yang menyebabkan

terjadinya pewarisan klas

Spesifikasi atribut seperti presisi, nilai default, batasan, dll.

Identifikasi Operasi/Layanan

Kegiatan spesifik/tertentu yang dilakukan oleh sebuah objek sendiri [Yourdon]

Langkah-langkah dalam mengidentifikasi operasi/layanan:

Identifikasi tanggung jawab umum sebuah klas (verbs)

Identifikasi operasi yang spesifik untuk domain masalah


Identifikasi operasi yang relevan dengan peran atau tanggung jawab

dalam sistem

Spesifikasi operasi yang berasal dari argumen, batasan/aturan,

logika/algoritma

DIAGRAM UML

UML adalah salah satu standar bahasa yang banyak digunakan di dunia industri

untuk mendefinisikan requirement, membuat analisis dan desain serta

menggambarkan arsitektur dalam pemrograman berorientasi objek. UML

berfungsi untuk melakukan pemodelan.

Use Case Diagram

Use Case merupakan pemodelan untuk kelakuan sistem informasi yang akan

dibuat. Use Case menjelaskan perilaku sistem dari tampak luar dan menyediakan

fungsi-fungsi yang harus dipenuhi sistem sesuai dengan aktornya. Elemen-elemen

yang ada pada use case adalah actor dan use case. Actor adalah orang, proses atau

sistem lain yang berinteraksi dengan sistem informasi. Sedangkan use case

merupakan fungsionalitas yang disediakan sistem sebagai unit-unit yang saling

bertukar pesan antar unit atau aktor.

Langkah-langkah dalam membuat use case:

Identifikasi aktor

Identifikasi use-case per aktor

Simbol-simbol yang digunakan pada use case adalah:

Tabel 1. Simbol Use Case

No Simbol (Nama) Deskripsi

1 use case

fungsionalitas yang disediakan sistem sebagai unit-unit yang saling bertukar pesan antar unit/aktor. Biasanya dinyatakan dengan menggunakan kata kerja awal di awal frase nama use case.

2 aktor

orang, proses atau sistem lain yang berinteraksi dengan sistem informasi yang akan dibuat.

3 asosiasi

komunikasi antar aktor/ use case yang berpartisipasi pada use case atau use case memiliki interaksi dengan aktor.

Nama use case


4 ekstensi/ extend <<extend>>

relasi use case tambahan ke sebuah use case dimana use case yang ditambahkan dapat berdiri sendiri walau tanpa use case tambahan itu

5 generalisasi

hubungan generalisasi antara dua buah use case dimana fungsi yang satu adalah fungsi yang lebih umum dari lainnya

6 include <<include>>

relasi use case tambahan ke sebuah use case dimana use case yang ditambahkan memerlukan use case ini untuk menjalankan fungsinya atau sebagai syarat dijalankan use case ini

Setiap use case yang dibuat, dilengkapi dengan skenario. Skenario use case

adalah alur jalannya proses use case dari sisi aktor dan sistem. Bentuk skenario use

case bisa dilihat pada gambar di bawah ini:

Tabel 2. Usecase Scenario

Flow of events for the Select product use-case

Objective Allow customer to select a certain product to dispense

Actors Customer

Pre-condition Coin detected and valid

Main flow

The customer selects a button product. The system displays an entry prompt of number of product to order.

Alternative flows If the selected product is not available, the system will display a message “Your selected product is not available”. If the selected product is available but there isn’t enough number to order, the system will display a message “The number isn’t enough, max. x”. X is the existing number of the product.

Post-condition The selected product dispensed as the number needed


Pada use case asosiasi, terdapat include dan extend seperti yang ditunjukkan

pada tabel 1. Include digunakan pada saat sebuah use case menggunakan use case

lainnya (functional decomposition). Penggunaan include sebagai sebuah fungsi

yang berada pada pernyataan masalah utama yang sangat rumit untuk

diselesaikan sesegera mungkin. Sehingga include wajib ada jika dibutuhkan

sebuah fungsi agregasi untuk sebuah fungsi yang lebih sederhana. Extend

digunakan pada saat ada use case yang ditambahkan dapat berdiri sendiri. Fungsi

dari sebuah pernyataan permasalahan utama perlu dilakukan sebuah

perpanjangan. Sehingga bisa disimpulkan bahwa extend menghubungkan use

case untuk memiliki peran sebagai use case opsional.

Actor-Generalization

Dua atau lebih sub-aktor digeneralisikan dari super aktor. Sehingga sub-aktor

tersebut memiliki behavior/operasi/layanan dan atribut yang dimiliki oleh super

aktor. Super aktor harus berinteraksi dengan use case ketika semua sub-aktor

berinteraksi dengan cara yang sama. Sub-aktor harus berinteraksi dengan use case

ketika interaksi use case berbeda dengan super aktor. Class Diagram (Diagram Klas)

Diagram klas atau class diagram menggambarkan struktur sistem dari segi

pendefinisian klas-klas yang akan dibuat untuk membangun sistem. Class yang ada

pada struktur sistem harus dapat melakukan fungsi-fungsi sesuai dengan

kebutuhan sistem.

Class Diagram (Diagram Klas)

Diagram klas atau class diagram menggambarkan struktur sistem dari segi

pendefinisian klas-klas yang akan dibuat untuk membangun sistem. Class yang ada

pada struktur sistem harus dapat melakukan fungsi-fungsi sesuai dengan

kebutuhan sistem. Class diagram memiliki node/klas dan relasi. Jenis relasi pada

class diagram meliputi:


Tabel 3. Notasi Diagram Klas

No Simbol/Nama Deskripsi 1 Klas

nama_klas +atribut() +operasi()

klas pada struktur sistem

2 interface

sama dengan konsep interface dalam pemrograman berorientasi objek

3 asosiasi

relasi antar klas dengan makna umum

4 asosiasi berarah

relasi antar klas dengan makna klas yang satu digunakan oleh klas yang lain

5 generalisasi

relasi antar klas dengan makna generalisasi-spesialisasi (umum-khusus)

6 agregasi

relasi antar klas dengan makna semua bagian

7 kebergantungan/dependency

relasi antar klas dengan makna kebergantungan antar klas

Class Stereotype

Dalam sebuah diagram klas, dibutuhkan sebuah template agar diagram klas

yang dibuat sesuai dengan sistem yang akan dibangun. Berikut merupakan

komponen yang harus ada pada sebuah diagram klas:

Boundary class

Boundary class merupakan sebuah model dalam sistem yang menunjukkan

bagaimana sistem berinteraksi dan berkomunikasi antara sistem komputer


dengan aktor, tetapi tidak secara langsung menggambarkan implementasi dari

antarmuka objek secara spesifik. Boundary class berfungsi untuk mengidentifikasi

antarmuka logis utama antara user dengan sistem lain seperti perangkat lunak lain

atau printer. Tugas utama dari boundary class adalah untuk menterjemahkan

informasi antar batasan sistem. Boundary class merupakan bagian dari sistem

dimana sebuah antarmuka akan dipisahkan dengan Business logic.

Entity class

Entity class digunakan untuk memodelkan data dan behavior/operasi/layanan

dari konsep sistem sesungguhnya atau entitas. Seperti member, bank account,

order, employee. Bagian ini akan membutuhkan penyimpanan lebih untuk sebuah

informasi. Sebagai contoh detail dari mahasiswa yang akan disimpan sebagai

record mahasiswa.

Control class

Control class berfungsi untuk menggambarkan koordinasi, urutan, transaksi

dan kontrol dari objek lain. Seperti halnya sebuah keterikatan antara elemen

boundary dan elemen entitas, yang bisa menggambarkan kebutuhan logis untuk

mengatur berbagai macam elemen dan interaksinya. Dibutuhkan minimal satu

Control class untuk setiap use case.

Contoh dari stereotype class dapat dilihat pada gambar di bawah ini:

Gambar 3.3 Stereotype Klas

Sequence Diagram

Diagram sekuen menggambarkan perilaku objek pada use case dengan

mendeskripsikan waktu hidup objek dan message yang dikirimkan dan diterima

antar objek. Oleh karena itu harus diketahui objek-objek yang terlibat dalam

sebuah use case beserta metode-metode yang dimiliki klas yang diinstansiasi

objek tersebut.

Actor 1 <<boundary>

>

<<control>>

<<boundary>>

<<entity>> <<entity>>

Actor 2


Diagram sekuen yang dibuat minimal sebanyak pendefinisian use case yang

memiliki proses sendiri atau interaksi jalannya pesan sudah diidentifikasi. Elemen-

elemen yang ada pada diagram sekuen adalah objek, garis putus-putus dan pesan.

Fungsi dari tiap elemen dari diagram sekuen:

Objek: menggambarkan objek yang berinteraksi pesan. Wujud dari elemen ini

adalah kotak.

Dashed line atau garis putus-putus: menyatakan kehidupan sebuah objek dan

disebut sebagai lifeline.

Message/pesan: digambarkan dalam bentuk panah dengan garis horizontal

yang berfungsi melewatkan pesan dari objek ke objek yang lain sebagai tanda

bahwa objek tersebut melewati jalur hidupnya.


1. Berdasarkan studi kasus : Vario Advertising, lakukan identifikasi aktor yang

terlibat dalam sistem dan buat pula daftar spesifikasi kebutuhan yang mampu

menghubungkan peran actor terhadap kebutuhan sistem!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

2. Berdasarkan studi kasus : Vario Advertising, buatlah usecase diagram

berdasarkan peran actor dan usecase scenario berdasarkan pandangan

setelah membaca soal cerita di atas!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

boundary entity control


_______________________________________________________________

_______________________________________________________________

3. Berdasarkan soal cerita diatas, lakukan analisis sequence diagram termasuk

identifikasi objek-objek yang saling berinteraksi satu dengan yang lain

berdasarkan kebutuhan yang telah di definisikan sebelumnya !

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

4. Berdasarkan soal cerita diatas, lakukan analisis class diagram termasuk

identifikasi objek-objek yang perlu didefinisikan dalam sistem yang akan

dibangun

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________


5. Berdasarkan usecase lakukan analisis diagram tersebut dari sisi semantik dan

sintaksis


Praktikum Analisis dan Perancangan PEMODELAN PERANCANGAN TERSTRUKTUR

1.1. TUJUAN PRAKTIKUM

a) Mahasiswa mampu memahami konsep pemodelan perancangan terstruktur

b) Mahasiswa mampu menerapkan langkah-langkah perancangan terstruktur

c) Mahasiswa mampu menyusun perancangan yang memenuhi parameter

kualitas perancangan

d) Mahasiswa mampu menyusun algoritma dalam perancangan

1.2. DASAR TEORI

Konsep Perancangan

Pemodelan perancangan terstruktur adalah metode untuk memodelkan suatu

rancangan yang dibangun dengan pendekatan terstruktur. Pemodelan ini

menggunakan model DFD (Data Flow Diagram) sebagai dasar dalam

mentransformasi (Transform Mapping).

Langkah-langkah dalam melakukan Transform Mapping adalah sebagai berikut.

1. Review dan refine DFD sampai ke level paling bawah.

Pada proses ini, DFD pada level terbawah kemudian digabung menjadi satu

perspektif. Sebagai contoh DFD berikut.

6.2*Assess Against

Setup

ConfigurationInformation

6.3*Format for

display

6.5*Dial Phone

6.4*Generate Alarm

Signal

6.1Read Sensor

Configuration data

Sensor ID, type

Sensor status

Sensor ID, type,location

Alarm data

Telephonenumber

TelephoneNumber tones

Alarm type

Sensor information

Gambar 4.1 DFD level 2: Monitor sensors


Pada gambar satu terdapat lima proses dimana proses enam poin dua, tiga,

dan lima merupakan proses-proses yang harus didekomposisi. Sedangkan proses

enam poin 1 dan 4 tidak perlu didekomposisi, sehingga hasil dekomposisinya

menjadi seperti gambar berikut.

1Read Sensor

2Acquire response

info3

EstablishAlarm

condition 4Select phone

number5

Set up conn. To phone net

Configuration information

6Format display

9Generate Display

7Generate alarm

signal

8Generate pulses

to line

Sensor Status

Sensor ID,Type

Alarm cond code,Sensor ID,

timing informationList of

numberTelephone

numberTone ready

Telephone number

Telephone tones

Alarm data

Alarm typeSensor ID, type,location

Format ID, type,location Sensor

Information

Configuration data

DekomposisiProses 6.2



Gambar 4.2 DFD level 3: Monitor sensors

2. Tentukan apakah DFD tsb. memiliki karakteristik tipe transform flow atau

transaction flow.

Untuk dapat menentukan karakteristik DFD memiliki tipe transform flow atau

transaction flow maka dapat kita lihat contoh DFD berikut.

Gambar 2.3 Contoh DFD memiliki tipe transform flow


Pada gambar tiga merupakan DFD yang bertipe transform flow. Pada DFD ini

terdapat tiga bagian yaitu:

Incoming flow : aliran/ jalur informasi eksternal masuk ke sistem untuk

ditransformasikan menjadi informasi internal,

Transform center : pusat transformasi di dalam sistem yang akan me-

trigger informasi keluar dari sistem,

Outgoing flow: aliran/ jalur informasi internal keluar dari sistem

menjadi informasi eksternal.

Gambar 4.4 Contoh DFD memiliki transaction flow

Pada gambar tiga merupakan DFD yang bertipe transaction flow. Pada DFD ini

terdapat tiga bagian yaitu:

Transaction: data tunggal yang me-trigger satu atau beberapa aliran

data,

Transaction center: penghubung antara aliran-aliran data hasil pen-

trigger-an dengan data trigger-nya,

Action path: aliran/ jalur informasi hasil trigger.

Perbedaan mendasar dari kedua jenis DFD di atas adalah jika pada Transform

Flow, informasi dari incoming flow akan dirubah menjadi informasi internal dan

akan diproses oleh transform center untuk kemudian digunakan oleh outgoing

flow. Sementara jika pada transaction flow adalah informasi atau transaction akan

menentukan action path mana yang akan dilewati.

Jadi jika ada informasi kemudian berubah menjadi informasi lain maka kita bisa

gunakan transform flow. Sementara jika ada informasi yang sifatnya semacam


kondisi yang dapat mengaktifkan proses yang berbeda-beda maka sebaiknya kita

pilih transaction flow.

3. Tentukan batas antara incoming flow, transform center dan outgoing flow

atau incoming path/transaction, transaction center dan action path.

Untuk menentukan batas tentunya harus memahami proses dan informasi

yang dibuat. Jika sudah dapat menentukan jenis DFD yang dibuat selanjutnya

dapat menentukan batasnya. Sebagai contoh adalah gambar berikut.

1Read Sensor

2Acquire response

info3

EstablishAlarm

condition 4Select phone

number5

Set up conn. To phone net


6Format display

9Generate Display

7Generate alarm

signal

8Generate pulses

to line

Sensor Status

Sensor ID,Type

Alarm cond code,Sensor ID,

timing informationList of

numberTelephone

numberTone ready

Telephone number

Telephone tones

Alarm data

Alarm typeSensor ID, type,location

Format ID, type,location Sensor

Information

Configuration data

INCOMING FLOW

TRANSFORM CENTRE

OUTGOING FLOW

Gambar 4.5 Penentuan Incoming, transform center, outgoing flow.

4. Bangun first level factoring.

DFD yang sudah dipetakan pada gambar lima kemudian di transformasi

menjadi arsitektur modul (lihat gambar 5). Incoming Flow dibuat ke dalam modul

sensor input controller. Transform Center dibuat kedalam modul alarm conditions

controller. Outgoing Flow dibuat ke dalam modul alarm output controller.


1

2

3

45

Configuration information 6 9

7

8

Monitor Sensor Executive

Sensor Input Controller

Alarm ConditionController

Alarm Output Controller

Gambar 4.6 First Level Factoring : Monitor Sensor.

Untuk gambar enam kemudian juga dilakukan first level factoring menjadi

arsitektur modul yang tergambar pada gambar berikut.

Read user command

Invoke command processing

Read System data

Build configuration file

Activate/deactivesystem

Read Password

Compare password with

fileProduce

invalid message

Display messages and status


UserCommand

Commandtype

Configure

Start/stop

Password

Password

Four Digits

Invalid Password

Try Again message

Valid Password

Configurationdata

Raw Configuration

data

System parametersand data

FormattedConfiguration

data

Configuration data

A/D Data

Display information

Gambar 4.7 First Level Factoring: Transaction Flow User Interaction.


5. Bangun second level factoring.

Second level factoring adalah proses untuk memetakan proses-proses yang

ada pada masing-masing incoming flow, transform center, outgoing flow ke dalam

bagian-bagian pada modul yang sudah ada pada first level factoring. Sebagai

contoh adalah gambar berikut.



Alarm ConditionController











Gambar 4.8 Second Level Factoring: Monitor Sensor.

Proses Second Level Factoring untuk contoh transaction flow (gambar 8)

kemudian menjadi bentuk gambar berikut.


System configuration controller

Activate/deactive system

Password processing controller

Read user command

User interaction interactive

Build configuration controller

Ready system data

Display message and status

Password output controller

Compare password with file

Read Password

Produce invalid message

Gambar 4.9 Second Level Factoring: User Interaction.


6. Refine first iteration.

Proses selanjutnya adalah refine first iteration yaitu proses untuk membuat

desain menjadi sederhana, memiliki kohesifitas yang tinggi, tingkat kopling yang

rendah dan memiliki struktur yang mudah untuk diimplementasikan. Hasil dari

first level factoring kemudian diubah menjadi bentuk lebih sederhana pada

gambar berikut.



Establish alarm condition


Read Sensor Produce DisplayAlarm Output

ControllerSet up conn to phone

net

Generate pulse to line

Gambar 4.10 Hasil Refine First Iteration: Monitor Sensor.

Incoming controller dihapus: data input tunggal, cukup sederhana.

Transform controller dihapus dan digabung dalam satu modul: ada

penurunan tingkat kohesifitas.

Format display dan generate display digabung: sederhana.

Hasil first level factoring untuk gambar 10 menjadi bentuk yang lebih

sederhana tampak pada gambar berikut.



System Configurationcontroller



Read user command

User Interaction Executive






Gambar 4.11 Hasil Refine First Iteration: User Interaction.

Setelah semua tahap dilalui, kemudian langkah terakhir adalah menggabung

keseluruhan arsitektur modul kedalam satu rangkaian arsitektur modul. Hasil

penggabungan arsitektur Software Safehome Security dapat dilihat pada gambar

berikut.


System Configuration

controller



Read user command

User Interaction Executive


controller


controller


controller


controller


controller

Monitor Sensor

Executive


Establish alarm

condition

Alarm Output

Controller

Read SensorProduce Display

Alarm Output

Controller

Set up conn to phone net

Generate pulse to line

Safe home security

Gambar 4.12 Arsitektur Modul SafeHome Security.

Masing-masing modul kemudian berisi algoritma yang didapatkan dari

P-SPEC, C-SPEC pada masing-masing proses yang ada pada DFD.


Pseudocode

Pseudocode adalah metode penulisan bahasa inggris sederhana yang

merepresentasikan lojik algoritma pemrograman. Pseudo berarti tiruan,

sedangkan Code adalah kode program sehingga pseudocode bisa disebut sebagai

kode tiruan dari program sebenarnya yang dituliskan dalam standar bahasa inggris

untuk mendekatkan dengan perintah-perintah yang terdapat pada bahasa

pemrograman. Setiap Pseudocode akan selalu terdiri dari tiga bagian yaitu :

Judul (Header) {Berisi Judul Algoritma/ method}

Kamus ( Deklarasi ) {Berisi Deklarasi Variabel atau Konstantan}

Algoritma ( Deskripsi ) {Berisi Inti Algoritma}

Gambar 4.13 contoh pseudocode


1. Berdasarkan DFD yang telah dibuat untuk studi kasus: Vario Advertising

tentukan karakteristik DFD tersebut.

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________


2. Gambarkan batas-batas pada DFD tersebut sesuai dengan karakteristiknya!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

3. Lakukan First Level Factoring

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

4. Lakukan Second level factoring.

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

5. Lakukan Refine First level factoring.

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________


Praktikum Analisis dan Perancangan PEMODELAN PERANCANGAN BERORIENTASI OBJEK


a) Memahami konsep OOD.

b) Mahasiswa mampu mentransformasikan model kebutuhan kedalam model

perancangan OO dengan UML.

c) Menjelaskan proses normalisasi dari class diagram yang telah ada di dalam

dokumen kebutuhan.

d) Mahasiswa dapat menentukan object-object dinamis dari suatu class dan

mengambarkan state diagram dari object-object tersebut.

e) Mahasiswa mampu menyusun dan merancang komponen (algoritma).

1.2. DASAR TEORI

Sequence Diagram

Sequence diagram menggambarkan interaksi antar objek di dalam dan di

sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message

yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal

(waktu) dan dimensi horizontal (objek-objek yang terkait). Sequence diagram

biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah

yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output

tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan

perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan.

Masing-masing objek, termasuk aktor, memiliki lifeline vertikal. Message

digambarkan sebagai garis berpanah dari satu objek ke objek lainnya.

Pada fase desain berikutnya, message akan dipetakan menjadi operasi/

metoda dari class yang akan dijelaskan pada sub bab berikutnya. Activation bar

menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan

diterimanya sebuah message. Untuk objek-objek yang memiliki sifat khusus,

standar UML mendefinisikan ikon khusus untuk objek boundary, controller dan


persistent entity. Penjelasan dapat dilihat pada Gambar 1. Contoh sequence

diagram dapat dilihat pada Gambar 2.

Gambar 5.1 Notasi squence diagram

Gambar 5.2 Contoh squence diagram


Class diagram

Objek adalah gambaran dari entity, baik dunia nyata atau konsep dengan

batasan batasan dan pengertian yang tepat. Objek bisa mewakili sesuatu yang

nyata seperti komputer, mobil atau dapat berupa konsep seperti proses kimia,

transaksi bank, permintaan pembelian, dll. Setiap objek dalam sistem memiliki tiga

karakteristik yaitu State (status), Behaviour (sifat) dan Indentity (identitas).

Cara mengidentifikasi objek:

1. pengelompokan berdasarkan kata/frase benda pada skenario.

2. berdasarkan daftar kategori object, antara lain:

objek fisik, contoh:pesawat telepon

spesifikasi/rancangan/deskripsi, contoh: deskripsi pesawat

tempat, contoh:gudang

transaksi, contoh: penjualan

butir yang terlibat pada transaksi, contoh: barang jualan

peran, contoh :pelanggan

wadah, contoh : pesawat terbang

piranti, contoh:PABX

kata benda abstrak, contoh: kecanduan

kejadian, contoh:pendaratan

aturan atau kebijakan, contoh:aturan diskon

catalog atau rujukan, contoh: daftar pelanggan

Klas adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan

sebuah objek atau dengan kata lain Klas merupakan template untuk membentuk

object. Klas merupakan inti dari pengembangan dan desain berorientasi objek.

Klas menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus

menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/ fungsi).

Class diagram menggambarkan struktur dan deskripsi class, package dan

objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi,

dan lain-lain.


Class memiliki tiga area pokok :

1. Nama (dan stereotype)

2. Atribut 3. Metoda/operasi

Penamaan class menggunakan kata benda tunggal yang merupakan abstraksi

yang terbaik. Atribut dan metoda dapat memiliki salah satu sifat berikut :

Private (-) , tidak dapat dipanggil dari luar class yang bersangkutan

Protected (#) , hanya dapat dipanggil oleh class yang bersangkutan dan anak

anak yang mewarisinya

Public (+) , dapat dipanggil oleh siapa saja

Gambar 5.3 Contoh Class Diagram

Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak

yang hanya memiliki metoda. Interface tidak dapat langsung diinstansiasikan,

tetapi harus diimplementasikan dahulu menjadi sebuah class. Dengan demikian

interface mendukung resolusi metoda pada saat run-time. Sesuai dengan

perkembangan class model, class dapat dikelompokkan menjadi package. Kita

juga dapat membuat diagram yang terdiri atas package.

Hubungan Antar Class

Dalam Obyek Oriented Design, klas-klas yang terbentuk dapat memiliki

hubungan satu dengan yang lainnya, sesuai dengan kondisi dari klas-klas yang

bersangkutan. Secara umum, hubungan antar kelas dapat dibedakan menjadi

Asosiasi, agregasi, komposisi, dependency, inheritance, realization.

- names

- address

+ CreditRating():String


Gambar 5.4 Notasi relasi antar klas

Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class

yang memiliki atribut berupa class lain, atau class yang harus mengetahui

eksistensi class lain. Panah navigability menunjukkan arah query antar class.

Contoh :

Klas diagram dalam kasus “Dosen Mengajar Mahasiswa”. 1 Dosen dapat

mengajar banyak Mahasiswa. Dalam hubungan asosiasi, di dalam Klas Dosen ada

link atribut nim mahasiswa yg diperoleh dari Klas Mahasiswa.

Gambar 5.5 contoh Asosiasi

Agregasi, yaitu hubungan yang menyatakan suatu klas adalah bagian (“terdiri

atas kumpulan”) dari klas yg lain, namun kedua klas ini bisa berdiri sendiri.

Merupakan hubungan yang lebih kuat dari hubungan asosiasi.

Contoh :

Klas Jurusan menyimpan nilai atribut dari mahasiswa dengan tipe data

Klas bentukan “Mahasiswa”.

Mahasiswa dapat memiliki objek sendiri

Jurusan dapat memiliki objek sendiri

Mahasiswa menjadi bagian dari jurusannya.

1 jurusan bisa memiliki banyak mahasiswa.


Gambar 5.6 contoh Agregasi

Komposisi, merupakan bentuk khusus dari Agregasi di mana kelas yang

menjadi part (bagian) baru dapat diciptakan setelah kelas yang menjadi whole

(seluruhnya) dibuat dan ketika kelas yang menjadi whole dimusnahkan, maka

kelas yang menjadi part ikut musnah.

Contoh :

Hubungan komposisi antara sebuah laptop dengan komponennya.

Contoh objek:

Laptop Asus A43S memiliki CPU intel core i7; VGA Nvidia 2GB;

Laptop Toshiba S006 memiliki CPU intel core i5; VGA Nvidia 2GB;

Nilai CPU dan VGA tidak bisa didapat jika tidak melalui nilai objek Laptop. Ada

ketergantungan penuh dari class CPU & VGA ke Laptop, dengan Kata lain jika

Laptop tidak ada maka CPU dan VGA juga tidak ada.

Gambar 5.7 contoh Komposisi

Dependency, yaitu hubungan dimana satu klas tergantung/menggunakan klas

yang lain secara langsung.

Contoh :


Klas Car menggunakan attribut atau method yang ada di Klas Wheel secara

langsung tanpa instansiasi objek Wheel.

Gambar 5.8 contoh Dependency

Pewarisan (inheritance), yaitu hubungan hirarkis antar class. Class dapat

diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya

dan menambahkan fungsionalitas baru, sehingga ia disebut anak (subclass) dari

class yang diwarisinya (superclass). Operasi pada superclass dapat di-override oleh

subclass (konsep polymorphism). Kebalikan dari pewarisan adalah generalisasi.

Contoh :

Klas Shape adalah super class dari Klas Square dan Circle, sehingga atribut dan

method Klas Shape diwarisi oleh Klas Square dan Circle namun Klas Square dan

Circle bisa memiliki atribut maupun method yg spesifik.

Gambar 5.9 contoh Inheritance

Realization, Hubungan antara Interface dan Klas, di mana suatu Klas (klien)

mengimplement perilaku dari interface namun secara spesifik menentukan

perilaku di dalam Klas.

Interface adalah prototype klas yang berisi definisi konstanta dan deklarasi

perilaku/method (hanya nama method tanpa definisi kode programnya).


Ciri sebuah interface:

Semua atribut adalah public dan final (semua atribut bertindak sebagai

konstanta). Dapat juga menambahkan modifier static.

Semua method adalah abstract dan public

Tidak boleh ada deklarasi konstruktor.

Contoh :

Gambar 5.10 contoh Realization

State Transiton Diagram

Use case dan skenario menyediakan cara untuk menggambarkan kelakuan

sistem yakni interaksi antara object-object di dalam sistem. Kadang-kadang

diperlukan untuk melihat kelakuan di dalam object. State transition diagram

menunjukkan state-state dari object tunggal, event-event atau pesan yang

menyebabkan transisi dari satu state ke state yang lain, dan action yang

merupakan hasil dari perubahan sebuah state. State transition diagram tidak akan

dibuat untuk setiap class di sistem. State transition diagram hanya dibuat untuk

class yang berkelakuan dinamis.

State adalah sebuah kondisi selama kehidupan sebuah object ketika object

memenuhi beberapa kondisi, melakukan beberapa action, atau menunggu sebuah

event. State dari sebuah object dapat dikarakteristikkan oleh nilai dari satu atau

lebih atribut- atribut dari class. State-state dari sebuah object ditemukan dengan


pengujian/pemeriksaan atribut- atribut dan hubungan-hubungan dari object.

State transition diagram meliputi seluruh pesan dari object yang dapat mengirim

dan menerima. Skenario merepresentasikan satu jalur yang melewati sebuah state

transition diagram. Jarak waktu antara dua pesan yang dikirim oleh sebuah object

merepresentasikan sebuah state. Masing- masing diagram harus mempunyai satu

dan hanya satu start state ketika object mulai dibuat namun sebuah object boleh

mempunyai banyak stop state.

Gambar 5.11 Notasi untuk State

Event

Perubahan (transition) dari sebuah state ke state lainnya diakibatkan oleh

sebuah event digambarkan oleh state transition. Event yang menyebabkan

perubahan tersebut dituliskan di atas garis panah.

Pseudocode

Pseudocode adalah metode penulisan bahasa inggris sederhana yang

merepresentasikan lojik algoritma pemrograman. Pseudo berarti tiruan,

sedangkan Code adalah kode program sehingga pseudocode bisa disebut sebagai

kode tiruan dari program sebenarnya yang dituliskan dalam standar bahasa inggris

untuk mendekatkan dengan perintah-perintah yang terdapat pada bahasa

pemrograman. Setiap Pseudocode akan selalu terdiri dari tiga bagian yaitu :

Judul (Header) {Berisi Judul Algoritma/ method}

Kamus ( Deklarasi ) {Berisi Deklarasi Variabel atau Konstantan}

Algoritma ( Deskripsi ) {Berisi Inti Algoritma}

State


Gambar 5.12 contoh pseudocode


1. Berdasarkan analisis klas modul pemodelan kebutuhan OO, buatlah klas

perancangan yang siap untuk di implementasikan

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

2. Sesuaikan diagram sekuens sesuai dengan level perancangan.

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

3. Untuk setiap method pada klas yang telah diidentifikasi dalam soal No.1, buat

pseudocode-nya sesuai dengan kasus yang telah diuraikan!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________


STUDI KASUS : DESAIN KLAS

Pabrik perakitan mobil tersebut berkeinginan untuk membuat program

aplikasi berbasis Web atau Desktop dengan kasus penggunaan sebagai berikut:

a. Simulasi perakitan mobil dilakukan oleh seorang Operator

b. Simulasi yang dapat dilakukan adalah simulasi pembuatan, pemasangan, dan

operasi yang dapat dilakukan oleh seluruh komponen Mobil

c. Proses simulasi sistem yang dilakukan oleh hanya dapat dilakukan setelah

seorang Manajer mengaktifkan program simulasi

d. Visualisasi proses simulasi yang dilakukan ditampilkan dalam dua antarmuka,

satu untuk Operator dan satu untuk Manajer.

e. Operator dapat melakukan seluruh operasi simulasi dan melihat tampilan

simulasi secara visual.

f. Selain dapat mengaktifkan dan menonaktifkan program simulasi, seorang

Manajer dapat melihat seluruh rangkaian proses simulasi.

Jawablah beberapa soal berikut dengan tepat, jelas, dan spesifik!

1. Lakukan analisis fungsionalitas dan penggunaan sistem lengkap dan lakukan

pemodelan dengan menggunakan Model Use Case (Use Case Diagram dan Use

Case Specification) berdasarkan kasus penggunaan program yang telah

diuraikan!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

2. Gambarkan aktivitas skenario penggunaan program/ sistem dalam Activity

Diagram.

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________


_______________________________________________________________

_______________________________________________________________

3. Lakukan analisis Boundary, Control, dan Entity dalam untuk setiap aktivitas

yang tergambar dalam skenario penggunan/use case scenario dan wujudkan

dalam Sequence Diagram.

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

4. Gambarkan objek yang telah diidentifikasi dalam soal No.3 dan lengkapi

dengan jenis relasi, kardinalitas, dan modalitas antar class dalam Class

Diagram!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

5. Gambarkan Class Diagram lengkap beserta atribut, method, visibility, relasi,

kardinalitas, dan modularitas relasi antar objek yang diperoleh dari hasil

analisis class dan analisis Boundary, Control, dan Entity sehingga siap untuk

diimplementasikan!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________


6. Lakukan analisis State yang mungkin untuk kasus penggunaan yang telah

diuraikan dan gambarkan dalam State Transition Diagram!

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

_______________________________________________________________

modul praktikum analisis dan perancangan sistem · modul praktikum analisis dan perancangan sistem...

Documents