ASI BARU

Gambar 1.0

Gambar Diatas Merupakan ASI BARU dari pembuatan rapor siswa.

Materi Konsep dan Prinsip Analisis

1. Teknik komunikasi

Komunikasi adalah proses penyampaian suatu pesan oleh seseorang kepada orang lain untuk memberi tahu atau untuk mengubah sikap, pendapat, atau perilaku, baik langsung secara lisan, maupun tak langsung melalui media.

TEKNIK KOMUNIKASI

• Mengawali Proses

Gause dan Weinberg [GAU89] menyarankan agar analis memulainya dengan mengajukan pertanyaan bebas konteks, dimana pertanyaan tersebut berfokus pada pelanggan, tujuan keseluruhan, dan keuntungan.

Contoh:   

• Siapa di balik permintaan untuk pekerjaan ini?  
• Apa keuntungan ekonomi dari pemecahan yang berhasil?
• Rangkaian pertanyaan berikutnya memungkinakan analis mendapatkan pemahaman yang lebih baik mengenai masalah dan pelanggan, untuk menyatakan persepsinya terhadap suatu pemecahan.

Contoh:   

• Masalah apakah yang akan diselesaikan oleh pemecahan ini?
• Dapatkah anda memperlihatkan kepada saya atau menjelaskan lingkungan dimana pemecahan tersebut akan digunakan?

Rangkaian pertanyaan berikutnya berfokus pada efektifitas pertemuan. [GAU89] memberikan contohnya sebagai berikut:

• Apakah ada orang lain yang dapat memberikan informasi tambahan?
• Apakah ada hal lain yang harus saya tanyakan kepada anda?

Pertanayan-pertanyaan tersebut akan membantu anda mengawali komunikasi yang perlu untuk berhasilnya analisis. Pada dasarnya sesi tanya jawab seharusnya digunakan pada pertemuan pertama dan kemudian diganti dengan format yang mengkombinasikan  lemen-elemen pemecahan masalah, negosiasi, dan spesifikasi

• Teknik Spesifikasi Aplikasi yang Terfasilitasi

Adanya teknik pendekatan spesifikasi aplikasi yang teratasi / facilitated aplication spesification techniques (FAST) dapat mendorong munculnya tim gabungan antara pengembang dan pelanggan yang bekerjasama untuk mengidentifikasimasalah, mengusulkan elemen pemecahan, menegosiasi pendekatan yang berbeda, dan mengkhususkan rangkaian pemecahan awal [ZAH90].Banyak pendekatan yang berbeda terhadap FAST telah diusulkan. Masing-masing pendekatan menggunakan skenario yang sangat berbeda, tetapi semuanya menerapkan beberapa variasi tuntutan dasar seperti:  Pertemuan dilakukan di sisi netral dan dihadiri baik oleh pengembang maupun pelanggan.  Aturan main untuk persiapan dan partisipasi dibuat.

          Sebuah mekanisme definisi (dapat merupakan sebuah lembar kerja, diagram flip, stiker dinding, atau papan tembok) digunakan. FAST bukanlah obat bagi masalah yang dihadapi dalam pengumpulan awal berbagai persyaratan, tetapi pendekatan tim memberikan keuntungan dari banyak sudut pandang, diskusi sesaat, dan penyaringan, serta merupakan langkah maju konkrit ke arah pengembangan spesifikasi.

• Penyebaran Fungsi Kualitas

Disebut juga Quality function deployment (QFD) adalah teknik manajemen kualitas yang menerjemahkan kebutuhan pelanggan ke dalam persyaratan teknis bagi perangkat lunak.

QFD mengidentifikasi 3 persyaratan [ZUL92] yaitu:   

• Persyaratan normal:
• Sasaran dan
• tujuan dinyatakan bagi sebuah produk atau sistem selama pertemuan dengan pelanggan.

Bila persyaratan ini ada, maka pelanggan akan menjadi puas.

Contoh : tipe tampilan grafis yang diminta, dan tingkat kerja yang didefinisikan.   Persyaratan yang diharapkan: Persyaratan ini implisit terhadap produk atau sistem dan sangat fundamental sehingga pelanggan tidak menyatakannya secara eksplisit. Ketidakhadirannya menyebabkan ketidakpuasan.

Contoh: Mudahnya instalasi perangkat lunak.

Exciting requirment: Persyaratan ini sangat diharapkan oleh pelanggan dan terbukti sangat memuaskan bila ada. Misalnya, perangkat lunak pengolah kata diharapkan dengan fitur standar. Produk yang disampaikan berisi sejumlah kemampuan layout halaman yang sangat menyenangkan dan tidak terduga. Dalam kenyataan, QFD mencakup seluruh proses rekayasa [AKA90]. Tetapi banyak konsep QFD dapat diaplikasikan ke dalam masalah komunikasi pelanggan yang dihadapi oleh perekayasa perangkat lunak selama tahap awal analisis

persyaratan. 

2. Prinsip Analisis

Masing-masing metode analisis memiliki titik pandang yang unik. Tetapi semua metode analisis dihubungkan oleh serangkaian prinsip operasional:

1. Domain informasi dari suatu masalah harus direpresentasikan dan dipahami.
2. Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan.
3. Tingkah laku perangkat lunak (sebagai suatu urutan kejadian eksternal) harus diwakilkan.
4. Model-model yang menggambarkan informasi, fungsi, dan tingkah laku harus dipecah-pecah dalam suatu cara yang membongkar suatu detail dalam bentuk lapisan.
5. Proses analisis harus bergerak dari informasi dasar ke detail implementasi.

Dengan mengaplikasikan prinsip-prinsip tersebut, analis mendekati suatu masalah secara sistematis. Domain informasi diuji sehingga fungsi itu dapat dipahami secara lebih lengkap. Model-model digunakan sehingga karakteristik fungsi dan tingkah laku dapat dikomunikasikan dengan cara yang rapi. Pembagian diterapkan untuk mengurangi keruwetan. Pandangan esensial dan implementasi dari perangkat lunak diperlukan untuk mengakomodasi batasan logis yang dibebankan oleh persyaratan pemrosesan dan batasan fisik yang dibebankan oleh elemen sistem yang lain. Perekayasa perangkat lunak yang mempercayai prinsip tersebut akan dapat lebih mengembangkan spesifikasi perangkat lunak yang kemudian akan menjadi dasar yang kuat bagi desain.

Model dalam perangkat lunak harus dapat memodelkan informasi yang ditransformasikan oleh perangkat lunak, fungsi (dan subfungsi) yang memungkinkan transformasi terjadi, dan tingkah laku sistem pada saat transformasi terjadi. Dalam beberapa kasus, model yang kita buat menggunakan notasi grafis yang menggambarkan informasi, pemrosesan, tingkah laku sistem, dan karakteristik lain sebagai simbol yang berbeda dan dapat dikenali. Informasi deskriptif dapat diberikan dengan menggunakan bahasa natural atau bahasa khusus untuk menggambarkan persyaratannya.

Prinsip analisis operasional mengharuskan kita membangun model fungsi dan tingkah laku.

 • Model fungsional: Perangkat lunak mentransformasi informasi, dan untuk melakukannya, perangkat lunak harus melakukan paling tidak tiga fungsi genetik: input, pemrosesan, dan output. Pada saat model fungsional dari suatu aplikasi dibuat, perekayasa perangkat lunak memfokuskan diri pada fungsi-fungsi masalah khusus. Model fungsi dimulai dengan sebuah model tingkat konteks tunggal (yakni nama perangkat lunak yang akan dibuat). Dengan serangkaian iterasi, maka lebih banyak lagi detail fungsionaldiberikan, sampai seluruh rancangan dari semua fungsionalitas sistem terwakili.

• Model tingkah laku: Sebagian besar perangkat lunak merespon kejadiankejadian dari dunia luar. Karakteristik stimulus-respon ini membentuk dasar dari model tingkah laku. Model tingkah laku menciptakan representasi pernyataan-pernyataan perangkat lunak dan event-event yang menyebabkan perangkat lunak mengubah pernyataan.

Model yang diciptakan selama analisis persyaratan melayani sejumlah peran penting:

-        Model membantu analis dalam memahami informasi, fungsi, dan tingkah laku suatu sistem, sehingga membuat tugas analisis persyaratan menjadi lebih mudah dan lebih sistematis.

-        Model menjadi titik fokus bagi kajian sehingga merupakan kunci bagipenentuan kelengkapan, konsistensi, dan akurasi dari spesifikasi.

-        Model menjadi dasar bagi pengerjaan desain, memberi perancang suatu representasi esensial dari perangkat lunak yang dapat diterjemahkan ke dalam suatu konteks implementasi.

Meskipun metode pemodelan yang digunakan sering menjadi masalah preferensi personal atau organisasional, aktivitas pemodelan adalah dasar bagi kerja analisis yang baik.

3. Prototyping Perangkat Lunak

 Prototyping perangkat lunak adalah salah satu metode siklus hidup sistem yang didasarkan pada konsep working model. Yang bertujuan untuk mengembangkan model menjadi sistem final. Artinya sistem akan dikembangkan lebih cepat daripada metode sebelumnya dan biayanya akan menjadi lebih rendah. Ada banyak cara untuk memprotoyping, begitu pula dengan penggunaannya. Ciri khas dari metodologi ini adalah pengembang sistem (system developer), klien, dan pengguna dapat melihat dan melakukan eksperimen dengan bagian dari sistem komputer dari sejak awal proses pengembangan.

 Protoyping juga membantu dalam hal menemukan kebutuhan di tahap awal pengembangan, terutama jika klien tidak yakin dimana masalah berasal. Selain itu protoyping juga berguna sebagai alat untuk mendesain dan memperbaiki user interface – bagaimana sistem akan terlihat oleh orang-orang yang menggunakannya.

4. Spesifikasi yang dibutuhkan dalam prinsip analilis

          Analisa kebutuhan merupakan langkah awal untuk menentukan perangkat lunak seperti apa yang akan dihasilkan, ketika kita melaksanakan sebuah proyek pembuatan perangkat lunak. Perangkat lunak yang baik dan sesuai dengan kebutuhan pengguna sangat bergantung kepada keberhasilan dalam melakukan analisa kebutuhan. Tidak peduli bagaimana hebatnya seseorang dalam menulis kode perangkat lunak, atau membuat antar muka yang menawan, jika terjadi kesalahan dalam analisa kebutuhan, itu artinya perangkat lunak yang dibuat menjadi tak berguna.

Analisa kebutuhan adalah sebuah proses untuk mendapatkan informasi, model, spesifikasi tentang perangkat lunak yang diinginkan klien/pengguna. Kedua belah pihak, yaitu klien dan pembuat perangkat lunak terlibat aktif dalam tahap ini. Informasi yang diperoleh dari klien/pengguna inilah yang menjadi acuan untuk melakukan desain perangkat lunak.

Ada 3 faktor yang harus dipenuhi ketika melakukan analisa kebutuhan ini yaitu : lengkap, detail, dan benar. Lengkap artinya semua yang diharapkan oleh klien telah didapatkan oleh pihak yang melakukan analisa. Sedangkan detail maksudnya adalah berhasil mengumpulkan informasi yang rinci sampai hal-hal yang kecil. Semua data dari analisa kebutuhan ini haruslah benar, sesuai apa yang dimaksud oleh klien, bukan benar menurut apa yang difikirkan oleh pihak yang melakukan analisa. Sebuah kutipan anonim yang sering disampaikan mengenai hal ini adalah : “Saya percaya anda sangat mengerti dengan apa yang saya katakan, namun saya tidak yakin bahwa apa yang anda dengar adalah sama dengan apa yang saya maksud”. 

5. Kajian Spesifikasi dalam Konsep dan Prinsip Analils

Metode spesifikasi sama dengan pemecahan masalah. Pereka PL yang dipaksa bekerja dengan spesifikasi yang tidak lengkap,tidak konsisten,atau salah akan mengalami frustasi atau keraguan.akibatnya, kualitas ,ketepatan waktu dan kelengkapan perangkat lunak menjadi korban.

Prinsip spesifikasi

Spesifikasi, tanpa mempedulikan mode dimana kita melakukannya, dapat dilihat sebagai sebuah proses representasi. Persyaratan diwakilkan dengan suatu cara yg membawa ke arah implementasi yang berhasil. Berikut ini sejumlah prinsip spesifikasi yang diadaptasi dari kerja Blazer dan Goldman[BLA 86].

1. Memisahkan fungsional dari implementasi
2. Mengembangkan suatu model dari system yang diperlukan yg meliputiData dan respon fungsional dari suatu system terhadap berbagai stimulus dari lingkungan.
3. Membangun konteks dimana PL beroperasi dengan menentukan cara dimana komponen system yg lain berinteraksi dengan PL.
4. Menentukan lingkungan dimana system beroperasi dan menunjukan bagaimana “ sekumpulan agen yang sangat terjalin bereaksi terhadap stimulus dalam lingkungan.
5. Menciptakan sebuah model yg kognitif daripada model desain atau implementasi.Model kognitif menggambarkan sebuah system sebagaimana dirasakan oleh komunitas pemakainya.
6. mengenali spesifikasi harus toleran terhadap ketidak lengkapan dan dapat di tambah.
7. Membangun muatan dan struktur spesifikasi dengan suatu cara yang akan memungkinkan spesifikasi dapat ditambah agar dapat berubah.

Representasi

Kita mengetahui bahwa persyaratan PL dapat ditentukan dalam berbagai cara. Akan tetapi, bila persyaratan itu dimasukan pada kertas atau media presentasi electronic, maka diperoleh panduan sederhana:

-Format dan muatan representasi harus relevan dengan masalah.

-Informasi yang di isikan kedalm spesifikasi harus disarangkan.

Spesifikasi persyaratan PL

Spesifikasi persyaratan PL dibuat pada puncak tugas analisis. Fungsi dan kinerja yang dialokasikan pada PL sebagai bagian dari rekayasa system, diperhalus dengan membangun sebuah diskripsi informasi lengkap,diskripsi tingkah laku dan fungsional lengkap,indikasi persyaaratan kinerja dan batasan desain, criteria validasi yang sesuai, dan data lain yang berkenaan dengan persyaratan. The Nation Bureau of Standards, IEE( standard no. 830- 1984) dan Departement Pertahanan AS mengusulkan format calon untuk spesifikasi persyaratan perangkatan perangkat lunak. Berikut merupakan kerangka kerj untuk spesifikasi.

a. Pendahuluan

- Refrensi system

- Deskripsi keseluruhan

- Batasan proyek PL

b.Deskripsi informsi

- Representasi isi informasi

- Representasi aliran informasi

- aliran data

- aliran kontrol

c.Deskripsi fungsional

- Pembagian fungsional

- deskripsi fungsional

- gambaran pemrosesan

- retriksi / keterbatasan

- persyaratan kinerja

- batasan desain

- diagram pendukung

- diskripsi control

- spesifikasi control

- batasan desain

d.Diskripsi prilaku

- peryataan system

- event dan tindakan

e.Validasi dan kreteria

- batas kinerja

- kelas- kelas pengujian

- respon PL

- pertimbangan khusus

f.Bibliografi

g.Lampiran

~ Kajian spesifikasi

Kajian dari suatu spesifikasi persyaratan perangkat lunak dilakukan baik oleh pelanggan atau pengembang PL. Karena spesifikasi membentuk dasar bagi desain dan aktivitas rekayasa selanjutnya, maka kajian harus dilakukan dengan hati- hati. Kajian dilakukan pertama kali pada tingkat makroskopik.pada tingkat ini pengkaji akan memastikan bahwa spesifikasi sudah lengkap, konsisten, dan, akurat

Pertanyaan - pertayan berikut dapat di ajukan contohnya

Apakah tujun dan sasaran yang diyatakan bagi perangkat lunak tetap konsisten dengan tujuan dan sasaran system?

• Apakah interface penting kesemua element system sudah digambarkan?
• Apakah fungsi mayor tetap ada pada ruang lingkup, dan sudah digambarkan dengan lengkap dn tepat?
• Apakah tingkah laku PL konsisten dengan informasi yang harus diproses dan fungsi harus dilakukannya?
• Apakah batasan desain realistis?
• Apakah resiko teknologis pengembang sudah dipertimbangkan?

Pengkaji dapat mengembangkan pertayaan diatas dengan :

Mencari konektor persuasive

• Bila suatu daftar yang diberikan tidak lengkap,pastikan jenisnya sudah dipahami.
• Pastikan jangkauan yg dinyatakan tidak berisi asumsi yg tidak dinyatakan.
• Hati hatilah pada kata kerja yang kabur
• Hati hati terhadap kata ganti yang ambiguitas
• Cari pertanyaan yang mengimplimentasikan kepastian Bila kajian lengkap spesifikasi persyaratan PL diakhiri oleh pelanggan atau pengembang.

Perubahan yang diminta setelah spesifikasi itu di akhiri tidak akan dieleminasi, tetapi pelanggan harus mencatat bahwa masing – masing perubahan setelah pengakhiran spesifikasi merupakan ekstensi dari ruang lingkup PL yang demikian dapat menambah biaya dan atau dapat memperpanjang jadwal proyek.Bahkan dengan prosedur kajian terbaikpun, tetap ada sejumlah masalah spesifikasi. Spesifikasi sulit di uji dalam berbagai cara yang berarti sehingga inkonsistensi dan penghilangan dapat berlangsung tanpa terlihat. Selama kajian , perubahan terhadap terhadap spesifikasi dapat disetujui.Sangat sulit untuk menili pengaruh global dari suatu perubahan ; yaitu bagaimana suatu perubahan dalam suatu fungsi mempengaruhi persyaratan bagi fungsi- fungsi yang lain.

 referensi : 

http://tekomunikasi.blogspot.com/

http://id.wikipedia.org/wiki/Protoyping_perangkat_lunak

http://suryainformation.wordpress.com/2010/05/23/analisis-kebutuhan-dalam-

rekayasa-perangkat-lunak/

http://lokomediasi.blogspot.com/2009/08/prinsip-konsep-analisa-kebutuhan.html

http://iiaahhdudul.blogspot.com/2011/10/konsep-dan-prinsip-analisis.html

 

Bentuk Realisasi Use Case

Contoh Use Case :
Diagram use case diatas, menggambarkan sistem informasi perindustrian. Use case tersebut terdiri dari dua macam interaksi antara entitas luar dengan sistem. Kedua interaksi tersebut dapat dijelaskan sebagai berikut.
1. User melakukan pencarian data industri
User bisa melakukan pencarian informasi terkait dengan data industri tertentu.
2. Admin melakukan pemasukan data industri
Admin melakukan pemasukan data industri baru ke dalam database.
Realiasasi dari use case di atas dapat digambarkan dalam bentuk sequence diagram sebagai berikut :
Sequence Diagram
a) Sequence Diagram untuk Use Case “search industri”
b) Sequence diagram untuk Use Case “Input Industri”

Realisasi Sequence Diagram
Use Case Search Industri
1) Realisasi UI “search”
2) Realisasi control “SearchIndustriControl”
/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/
package vervalpl;
import com.mysql.jdbc.Connection;
import vervalpl.koneksi;
import com.mysql.jdbc.ResultSet;
import java.sql.SQLException;
/**
*
* @author Yudhi Dwi Cahyono
*/
public class SearchIndustriControl {
koneksi conn;
public SearchIndustriControl(){
conn = new koneksi();
}
public ResultSet searchDataIndustri(String keyword) throws SQLException{
ResultSet rs = null;
String query = “”;
if(conn.getKoneksi()){
query = “select * from industri where nama_industri = ‘”+keyword+”‘”;
rs = (ResultSet) conn.executeSelect(query);
}
return rs;
}
}
3) Realisasi Database -> Tabel Industri
CREATE TABLE `verval`.`industri` (
`id_industri` CHAR( 5 ) NOT NULL ,
`nama_industri` VARCHAR( 100 ) NOT NULL ,
`alamat` VARCHAR( 200 ) NOT NULL ,
PRIMARY KEY ( `id_industri` )
) ENGINE = MYISAM

INSERT INTO `verval`.`industri` (
`id_industri` ,
`nama_industri` ,
`alamat`
)
VALUES (
’001′, ‘PT. Astres Int. Tbk.’, ‘Keputih Gang 1D’
), (
’002′, ‘PT. Butik Batik’, ‘Kertajaya No. 51′
);
Use Case Input Industri
1) Realisasi UI “inputIndustri”

2) Realisasi control “InputIndustriControl”
/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/

package vervalpl;

import java.sql.SQLException;
import vervalpl.koneksi;
/**
*
* @author Yudhi Dwi Cahyono
*/
public class InputIndustriControl {
private koneksi kon;

public InputIndustriControl(){
kon = new koneksi();
}
public int inputDataIndustri(String nomor, String nama, String alamat) throws SQLException{
int X = 0;
if(!nomor.isEmpty() && !nama.isEmpty() && !alamat.isEmpty()){
if(kon.getKoneksi()){
String query = “insert into industri (id_industri, nama_industri, alamat) ” +
“values (‘”+nomor+”‘, ‘”+nama+”‘, ‘”+alamat+”‘)”;
X = kon.executeUpdate(query);
}
}
return X;
}
}
3) Realisasi Database -> Tabel Industri
Di dalam use case Input Industri, sasaran tabelnya sama dengan use case search industri. Yaitu, tabel industri.
CREATE TABLE `verval`.`industri` (
`id_industri` CHAR( 5 ) NOT NULL ,
`nama_industri` VARCHAR( 100 ) NOT NULL ,
`alamat` VARCHAR( 200 ) NOT NULL ,
PRIMARY KEY ( `id_industri` )
) ENGINE = MYISAM

INSERT INTO `verval`.`industri` (
`id_industri` ,
`nama_industri` ,
`alamat`
)
VALUES (
’001′, ‘PT. Astres Int. Tbk.’, ‘Keputih Gang 1D’
), (
’002′, ‘PT. Butik Batik’, ‘Kertajaya No. 51′
);

Generate Test Case Dari Use Case – Verifikasi dan Validasi Perangkat Lunak

•Maret 25, 2010 • Tinggalkan sebuah Komentar Kelompok :

1. Wirsal Djamaluddin (5106100013)
2. Yudhi Dwi Cahyono (5106100019)

USE CASE

Diagram use case di atas, menggambarkan sistem informasi perindustrian. Use case tersebut terdiri dari dua macam interaksi antara entitas luar dengan sistem. Kedua interaksi tersebut dapat dijelaskan sebagai berikut.
1)        User melakukan pencarian data industri.
User bisa melakukan pencarian informasi terkait dengan data industri tertentu.
2)        Admin melakukan pemasukan data industri.
Admin, melakukan pemasukan data industri baru ke dalam database.
1. USE CASE SEARCH INDUSTRI
Textual Description

Basic Flow

Alternate Flow

USE CASE SCENARIOS

GENERATING TEST CASES

• Langkah Pertama – Generate Scenarios

• Langkah Kedua – Identify Test Cases

• Langkah Ketiga – Identify Data Values to Test

2. USE CASE INPUT INDUSTRI
Textual Description

Basic Flow

Alternate Flow

USE CASE SCENARIOS

GENERATING TEST CASES

• Langkah Pertama – Generate Scenarios

• Langkah Kedua – Identify Test Case

• Langkah Ketiga – Identifty Data Values to Test

Diagram Use Case

Diagram use case menggambarkan kelakuan sistem, subsistem atau suatu class sebagaimana   dengan   yang   terlihat   oleh   pengguna   dari   luar. Diagram use case juga menggambarkan fungsionalitas yang diharapkan dari sebuah sistem, yang ditekankan adalahb”apa” yang diperbuat oleh sistem, dan bukan “bagaimana”. Diagram ini akan memperihatkan hubungan interaksi antara himpunan use case dan aktor-aktor (suatu jenis khusus dari kelas). Diagram ini terutama sangat penting untuk mengorganisasi dan memodelkan perilaku dari suatu sistem yang dibutuhkan serta diharapkan pengguna.
Diagram use case terdiri dari beberapa  komponen, yaitu:
-  Actor
Actor adalah perwakilan dari orang luar, proses atau hal yang berinteraksi dengan  sistem,  subsistem  ataupun  class.  Tiap  actor  berpartisipasi  dengan satu   atau   lebih   use-case.   Actor   berpartisipasi dengan use-case  dengan pertukaran pesan. Actor dapat digambarkan seperti Gbr 1.

-  Use Case

Use-case merupakan  lingkupan  sistem  yang mengidentifikasikan hal-hal yang seharusnya dilakukan oleh sistem.  Use-case berguna untuk menggambarkan suatu kelakuan dari sistem tanpa mengungkapkan struktur internal dari sistem tersebut. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dll.

-  Realationship
Relatioship berguna untuk menggambarkan hubungan antar aktor dan use- case dalam sistem. Di dalam diagram use case ada beberapa bentuk relationship, yaitu:
*   Association, berfungsi sebagai jalur komunikasi  antar  actor dengan use case yang saling berpartisipasi. Association dapat dinotasikan dengan gambar garis lurus, seperti berikut ini:
*  External, berfungsi untuk menambahkan kelakuan tambahan ke dalam use case dasar  yang tidak tahu menahu tentang hal tersebut. Relationship dapat digambarkan dengan notasi berikut:
*  Use case Generalization, menggambarkan hubungan antara use case umum dengan use case yang lebih spesifik yang mewarisi dan menambah fitur terhadapnya. Relationship jenis akan digambarkan dalam bentuk notasi seperti berikut ini:
*  Include. Ini merupakan penambahan  kelakuan tambahan ke dalam use case dasar yang secara eksplisit menjelaskan penambahannya.

<  extend   >

Gbr6.  Notasi extend

Diagram Use Case berguna dalam tiga hal :
• Menjelaskan fasilitas yang ada (requirements). Use Case baru selalu menghasilkan fasilitas baru ketika sistem di analisa, dan design menjadi lebih jelas.
• Komunikasi dengan klien. Penggunaan notasi dan simbol dalam diagram Use Case membuat pengembang lebih mudah berkomunikasi dengan klienkliennya.
• Membuat test dari kasus-kasus secara umum. Kumpulan dari kejadian-kejadian untuk Use Case bisa dilakukan test kasus layak untuk kejadian-kejadian tersebut.
Contoh Diagram Use Case:

Gbr7. Diagram Use Case pada penjualan DVD

Pada contoh diagram use case di atas, ada terdapat 3 aktor, yaitu: penjaga toko, petugas stok, dan petugas keuangan. Sedangkan, use case-nya ada terdapat 5 buah yaitu: entry permintaan, hitung stok barang, buat laporan, view permintaan, dan hitung penjualan.
Penjaga toko akan melihat dan mencatat berapa banyak permintaan VCD dan membuat laporannya. Petugas Stok akan menghitung jumlah stok barang VCD) yang masih ada dan membuat laporannya. Sedangkan petugas keuangan akan menghitung berapa hasil penjualan dari VCD dan membuat laporan hasil penjualan tersebut.

Model Use Cae

Model Use Case

• Model untuk melengkapi system requirements
• Tahapan awal "system development":
  • Requirement: sistim belum terinci
  • Representasi: user perspektif
    "What the system will/should do ?"
• Starting point: OO analysis & design activities
• Garis besar terdiri dari: "actors" dan "use cases"
  
  
  Actors
• Types yang mewakili: users yang berinteraksi dengan sistim
• Users: di luar dari sistim, batasan apa yang akan diharapkan dari sistim
  • Pengertian users => types of activities performed by external entity
  • Sekumpulan individu  dapat dianggap sebagai satu user (same role)
• Actors: manusia, external hardware, atau sistim yang lain
  
  
  
  

  Use Case

• Types yang mewakili: behaviour, sifat / karakteristik dan fungsi sistim
• Dikembangkan sesuai dengan keinginan "actor"
• Dapat diterjemahkan sebagai bentuk eksekusi pemakaian sistim
  • Interaksi dan fungsi yang diharapkan dari sistim
  • Flow events response dari sistim

Contoh : ATM Cashier Application

• Actor: Klien Bank
• Bagaimana interaksi dengan aplikasi di ATM ?
  Fasilitas apa saja yang dapat diberikan oleh Bank kepada Klien Bank

• User cases:
  • Tarikan Uang
  • Deposit Uang
  • Transfer Antar Rekening

• Actor: apa saja yang berinteraksi (memberikan dan menerima data atau events) dengan sistim
  • Actor dapat mewakili sekelompok klien bank (yang mempunyai karut ATM)
  • Satu klien dapat menggunakan ATM tersebut untuk berbagai keperluan => berbagai actors yang berbeda
  • Peranan actor ditentukan use case mana saja yang digunakan oleh actor tersebut
• Interaksi ? tidak lain mengirim dan menerima messages (data, events)
  • Hubungan antara actor dan use case: <<communication>> associations                                                                                                                                                                                        

    Use Case: Transactions

  • Definisi: use case adalah urutan transaksi/proses yang dilakukan oleh sistim, dimana menghasilkan sesuatu yang dapat dilihat/diamati oleh actor tertentu
  
  
• Problem: bagaimana memilih use case yang tepat (terdapat banyak kejadian interaksi antar actor dan system) ?
  • Definisi di atas => "instance" kejadian yang penting dan dapat dipilah sangat relevan dengan kegiatan actors
  • Pilih use case type yang mewakili instance tersebut
  • Dari definisi "menghasilkan sesuatu yang dapat dilihat oleh actor" => use case harus cukup besar karena berhubungan dengan kegiatan actor
  • Transaksi: sekumpulan aksi, keputusan, dan messages yang diberikan kepada actors secara konsisten
  • Actor tertentu: peranan utama, karena hasil use case harus berhubungan dengan actor tersebut, berhubungan dengan task tertentu

Contoh

Use case: Tarikan Uang

• Klien Bank memberikan identifikasi dirinya
• Klien Bank memilih atau memberikan input berapa banyak uang yang akan diambil dari rekening.  Sistim memberikan persetujuan dan mengijinkan berapa banyak uang yang dapat diambil
• Sistim mengeluarkan uang tersebut dan mengurangi jumlah uang tersebut dari rekening

Reuse Use Case : <<uses>>

• Untuk sistim yang besar: terdapat use case yang sifatnya sama
• Kelompok use case ini dapat  dibuat : "generalizations" yang mewakili kelompok tsb.
  • Dapat dianggap sebagai "inheritance" 
  • Digunakan simbol: <<uses>>

 

• Contoh: <<uses>> use case A menggunakan use case B berarti instance A dapat melakukan semua sifat dari instance B
  • Sebagai contoh: semua transaksi ATM berhubungan dengan pemindahan uang dari satu rekening ke rekening lain.

• Dapat menggunakan use case yang telah ada: Transfer Keuangan sebagai "abstract" use case.

Transfer Keuangan use case memberikan deskripsi cara debit dan kredit dari berbagai account yang berbeda.

Reuse Use Case : <<extends>>

• Sering use case dapat dikembangkan (ditambahkan) dari use case yang telah ada
• Penambahan ini untuk memberikan spesialisasi atau inheritance
• Jadi jika disebut use case A "extends" use case B : maka instance tersebut mengikuti use case A dan pada satu saat akan mengikuti use case B, setelah mengikuti B dapat kembali ke use case A.
• Contoh: Klien Bank dapat diberikan fasilitas untuk mengambil uang dalam bentuk overdraft.
  
  Untuk kasus dimana Klien Bank mengambil overdraft maka terdapat sifat khusus use case yang harus ditangani oleh "Manajemen Overdraft"
  
  Atau dapat disebut: use case Manajemen Overdarft merupakan "extends" dari use case Tarikan Uang.

Contoh Lain: 

Pengertian Use Case

Diagram Use Case adalah diagram yang menunjukkan fungsionalitas suatu sistem atau kelas dan bagaimana sistem tersebut berinteraksi dengan dunia luar dan menjelaskan sistem secara fungsional yang terlihat user. Biasanya use case dibuat pada awal pengembangan. Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem.

 Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya.

 Deskripsi singkat tentang USE CASE

• Perilaku sistem adalah bagaimana sistem beraksi dan bereaksi. Perilaku ini merupakan aktifitas sistem yang bisa dilihat dari luar dan bisa diuji.
• Perilaku sistem ini dicapture di dalam USE CASE. USE CASE sendiri mendeskripsikan sistem, lingkungan sistem, serta hubungan antara sistem dengan lingkungannya.

Defenisi Use Case

• Deskripsi dari sekumpulan aksi sekuensial yang ditampilkan sistem yang menghasilkan yang tampak dari nilai ke actor khusus. Use Case digunakan untuk menyusun behavioral things dalam sebuah model. Use case direalisasikan dengan sebuah collaboration. Secara gambar, sebuah use case digambarkan dengan sebuah ellips dengan garis penuh, biasanya termasuk hanya namanya, seperti gambar berikut :

• Representasi atau model yang digunakan dalam Rekayasa Perangkat Lunak untuk menggambarkan fungsional requirement suatu sistem.
• Sekelompok skenario pengguna yang menggambarkan alur penggunaan sistem.
• Setiap skenario digambarkan dari sudut pandang “aktor”, seseorang atau piranti yang berinteraksi dengan perangkat lunak dalam berbagai cara.
• Suatu Use Case adalah suatu sekuensial aksi yang dilakukan oleh sistem, yang akan secara bersama-sama, memproduksi hasil yang dibutuhkan oleh pengguna sistem. Use Case mendefinisikan alur proses sepanjang sistem berbasis pada kegunaan sebagaimana yang biasa dilakukan (secara manual).

Contoh sederhana:
Konsumen pesan tiket pesawat

Contoh lebih lengkap:
Use Case pada Sistem Rumah Sakit

Kegunaan Use Case adalah untuk menspesifikasikan konteks sistem, menggambarkan kebutuhan sistem, memvalidasikan arsitektur sistem, menjalankan implementasi dan meng-generate test case.

Include
Keterhubungan secara include antar use case menunjukkan bahwa use case asal secara eksplisit memasukkan perilaku dari use case lain yang ditunjuk oleh use case tersebut. Included use case tidak pernah berdiri sendiri, tetapi hanya merupakan bagian dari beberapa use case yang lebih besar yang diikutinya. Keterhubungan use case secara include pada dasarnya merupakan sebuah contoh dari pendelegasian - sekumpulan dari tanggung jawab sebuah sistem diambil dan ditangkap di dalam satu tempat (included use case) - kemudian bagian lainnya dari sistem (use case yang lain) memasukkan kumpulan tanggung jawab yang baru setiap saat mereka memerlukan fungsi-fungsi use case tersebut.

Extend
Keterhubungan use case secara extend menunjukkan bahwa use case yang ditunjuk merupakan perluasan perilaku dari use case asal. Use case asal dapat berdiri sendiri, tetapi untuk kondisi tertentu perilaku use case tersebut dapat diperluas oleh perilaku dari use case lain. Hubungan perluasan digunakan untuk memodelkan bagian dari use case yang dapat dilihat oleh user sebagai perilaku yang dapat dipilih dari sistem. Hubungan perluasan juga dapat digunakan untuk memodelkan sub aliran yang terpisah-pisah yang hanya dapat dijalankan dalam kondisi tertentu. Pada akhirnya, hubungan perluasan use case untuk memodelkan beberapa aliran yang dapat dimasukkan dalam titik tertentu.
Manfaat Model Use Case

• Digunakan untuk berkomunikasi dengan end user dan domain expert
  • Menyediakan buy-in pada tahap awal pengembangan sistem.
  • Memastikan pemahaman yang tepat tentang requirement / kebutuhan sistem.
• Digunakan untuk mengidentifikasi
  • Siapa yang berinteraksi dengan sistem dan apa yang harus dilakukan sistem.
  • Interface yang harus dimiliki sistem.
• Digunakan untuk ferifikasi
  • Semua requirement yang telah dicapture.
  • Tim pengembang memahami requirement.

Macam-macam Use Case

• Narative Form
  Bentuk teks bebas dalam format paragraph.
• Scenerio Form
  Penjelasan penulisan use case dari sudut pandang actor.
• Conversation Form
  Dialog antara actor dan sistem yang menunjukkan interaksi antar keduanya.

Perbandingan Bentuk Use Case

Format Penulisan Use Case
Tiap Use Case memiliki:

• Precoditions, yang harus dipertemukan agar use cases dapat bekerja dengan sukses.
• Postconditions, mendefinisikan kondisi-kondisi dimana use cases berakhir.
• Postconditions mengidentifikasi hasil yang dapat diobservasi dan status akhir dari sistem setelah use case telah komplit.
• Flow of events, yang mendefinisikan aksi pengguna dan respon sistem terhadap aksi yang dilakukan. Flow of events merupakan kompresi dari skenario normal, yang mendefinisikan tingkah laku umum dari sistem untuk use case, dan cabang-cabang alternatif, dimana bagian lain yang telah tersedia dapat digunakan oleh use case.

Use Case dan Test Cases akan bekerja dengan baik dalam dua cara, yaitu:

• Jika use case dari sistem komplit, akurat dan jelas, maka pembuatan test cases dapat dilakukan secara langsung.
• Jika use case tidak dalam kondisi yang baik, maka pembuata test cases akan membantu dalam melakukan debug terhadap test cases.

Modul Use Case
Mulai dengan kondisi atau kejadian normal biasa:

• Acuhkan pengecualian, alternatif, dll.
• Use case harus dinamai dan perspektif pengguna sebagai kata kerja aktif.
• Menunjukkan deskripsi tujuan dari use case dan defenisi fungsionalitas tingkat
  tinggi.