Hallo, saya mau say hay lagi tentang Sistem Informasi nih, sekarang tema yang kita pilih

adalah DFD, (Data Flow Diagram. kalian tau gak apaitu DFD? Data Flow Diagram (DFD) adalah suatu diagram yang menggunakan notasi-notasi untuk menggambarkan arus dari data sistem, yang penggunaannya sangat membantu untuk memahami sistem secara logika, tersruktur dan jelas. DFD merupakan alat bantu dalam menggambarkan atau menjelaskan sistem yang sedang berjalan logis.

gambar di atas adalah Simbol dan Keterangan untuk membuat DFD,

igambar di atas menunjukan DFD Level 1.

Rabu, 09 Maret 2011

DFD Sistem Informasi Priwisata

Soal! Dibutuhkan sebuah perangkat lunak yang dapat digunakan oleh setiap turis/ calon turis untuk mendapatkan berbagai informasi serta melakukan beberapa transaksi on-line. Informasi yang harus didapat setiap turis adalah :(aplikasi berbasis web).

informasi tempat wisata, hotel, alat transportasi. Perangkat lunak yang harus menyediakan sarana bagi turis untuk melakukan Pemesanan hotel dan penyewaan mobil ke sistem lain. (mis. SI hotel dan SI rental). Informasi yang dikelola perangkat lunak ini dikelola oleh seorang admin sehingga info tersebut selalu up date.

Buatlah data flow diagram-nya dari diagram level konteks di bawah ini !

Berdasarkan level konteks diatas Kita dapat membuat DFD sepeti pada gambar dibawah ini.

Pada postingan kali ini saya akan membahas kembali mengenai model data, tetapi dalam pendekatan Rekayasa perangkat lunak, seperti pada pendekatan Analisi sistem informasi bahwa, model data merupakan sekumpulan konsep untuk menjelaskan data yang tersimpan dalam basis data, hubungan-hubungan antara data satu dengan yang lain dan juga batasan yang terkordinasi dalam suatu organisasi, yang tujuannya untuk membuat data lebih mudah dimodifikasi dan dimegerti. Selanjutnya saya akan membahas mengenai Entitas Relationship Diagram atau yang lebih dikenal sebagai ERD. Dosen saya mengambarkan sebuah himpunan A dan B , dan mengatakan kalau himpunan itu juga merupakan suatu relasi antara entitas A dan entitas B, dimana entitas A dapat memiliki satu atau banyak relasi terhadap entitas B, dan itu merupakan contoh kecil dari sebuah relasi Entitas Relationship Diagram sendiri merupakan diagram dimana data dibuat, digunakan dan disimpan dalam sistem. dalam ERD terdapat relasi relasi, yang pertama ada Kardinalitas ( mengacu pada berapa kali suatu entitas dapat berelasi degan entitas lain, satu ke satu, satu kebanyak, dan banyak ke banyak), ada juga Modalitas ( apakah suatu entitas turunan dapat ada tanpa suatu relasi dari entitas induk dimana jika dinyatakan Not null : harus ada relasi dan jika Null artinya tidak perlu ada relasi). Dalam membuat ERD kita harus mengetahi terlebih dahulu mengena blueprint (kerangka kerja/ arsitektur sebagai

landasan dalam pembuatan kebijakan yang meliputi penetapan tujuan dan sasaran, penyusunan strategi, pelaksanaan program dan fokus kegiatan serta langkah-langkah atau implementasi yang harus dilaksanakan). Dari penjelasan mengenai di atas pembuatan ERD harus mengacu pada blueprint ( arsitektur ) di bawah ini

Physical : Merupakan tahapan pemikiran mengenai bentuk fisik dari sebuag ERD Logical : Merupakan tahapan model data itu dibuat ( pembuatan ERD ) dimana menyangkut entitas , relasi , dan atribut View : Merupakan output dari hubungan antara entitas yg berada pada level logical. (view bukan entitas) Kelompok saya ditugaskan untuk membuat ERD mengenai service HP , berikut gambar ERD service hp,

Dari ERD di atas kita bisa mendapatkan beberapa view, misalnya , kerusakan yang terjadi, daftar customer, dan masih banyak lagi.

Sekarang penulis akan membahas mengenai ERD (Entity Relational Diagram) nih, teman2. Jadi pada chapter ini, penulis tidak hanya akan membahas mengenai seluk-beluk dari ERD, namun juga akan menjelaskan bagaimana cara membuat ERD dalam database.

Jadi penulis akan membahas mengenai : 1. Entity Relationship Diagram 2. Entity Relationship Model Sebelum kita membuat ERD ada baiknya kita berkenalan dulu lah dengan segala sesuatu yang berhubungan dengan ERD.

Ok, lets get started to watch and learn about ERD!!!

Entity Relationship Diagram (as known as ERD) ialah pemodelan data utama dan akan membantu mengorganisasikan data dalam suatu proyek ke dalam entitas-entitas dan menentukan hubungan antar entitas beserta attribut-attributnya.

Berikut penjelasannya, gan :

Entitas (Entity) Suatu yang nyata dimana kita akan menyimpan data. Jadi contohnya ialah seperti misalnya ERD mengenai Rumah Sakit, nah Entitas nya yaitu entitas penjaga, entitas perawat, entitas dokter dll. Ada 2 tipe Entitas : 1. Entitas Kuat, merupakan entitas yang tidak memiliki ketergantungan dengan entitas lain. 2. Entitas Lemah, merupakan entitas yang kemunculannya tergantung pada keberandaan entitas lain pada suatu relasi.

Attribut (Attribute) Suatu tempat atau objek yang berguna untuk menyimpan data-data. Contohnya kalau dari ERD Rumah Sakit itu seperti misal Entitas nya ialah entitas Dokter, nah attribut nya dapat berupa NoID_Dokter, Nama_Dokter, Spesialis_Dokter, dll. Jenis-jenis atribut : 1. Atribut komposit = Atribut yang tidak bisa dipecah lagi menjadi atribut yang lebih kecil 2. Atribut atomic = Atribut yang terdiri atas satu komponen tunggal dan tidak bisa diuraikan lg 3. Single-valued attribute = Atribut yang hanya punya satu nilai untuk suatu entitas. 4. Multi-valued attribute = Atribut yang dapat teridir dari sekumpulan nilai untuk entitas. 5. Atribut Derivatif = Atribut yang dihasilkan dari atribut lain yang tidak berasal dari 1 entitas.

Relasi (Relationship) Hubungan yang terjadi antara satu atau lebih entitas, jadi istilahnya itu hubungan anatar entitas.

Misalnya ni ya, ambil contoh dari ERD Rumah Sakit, kita ambil Entitas Dokter dengan Entitas Pasien. Nah, entitas dokter itu memiliki relasi dengan entitas pasien sebagai "Merawat/Memeriksa/Menyembuhkan", yang artinya Dokter memeriksa/menyembuhkan Pasien, atau Pasien diperiksa/disembuhkan oleh Dokter. Jadi di dalam relasi, harus ada hubungan yang pasti pada antar entitas yang berelasi. Begitu, kawan, mudah bukan? Derajat relasi atau kardinalitas : 1. One to One (Satu ke satu) = Setiap anggota entitas E1 hanya boleh berhubungan dengan 1 anggota entitas E2, begitu pula sebaliknya. 2. One to Many (Satu ke Banyak) = Setiap anggota entitas E1 boleh berhubungan lebih dari satu dari anggota entitas E2, begitu pula sebaliknya. 3. Many to Many (Banyak ke Banyak) = Setiap entitas E1 boleh berhubungan dengan banyak anggota entitas E1, demikian juga sebaliknya.

Berikut simbol-simbol yang dapat dipakai dalam pembuatan ERD beserta keterangannya :

Guys, dalam membuat suatu ERD, ada 10 langkah yang harus kita lewati. Berikut langkahlangkah dalam pembuatan ERD, beserta penjelasannya, check it out:

Studi kasus: Skema Kerja Hotel Spesifikasi database : Attribut dari PEGAWAI : Nama,NIP,Jabatan,Telpon,Alamat,Tahun_Masuk. Attribut dari TAMU : Nama, Id_Tamu, Alamat, Telpon, Lama_inap Attribut dari KAMAR : No_Kamar, Id_kamar Attribut dari FASILITAS : Id_tipekamar, Jumlah_kamar, Jenis_tipekamar, Other_fasilitas Attribut dari HARGA : Id_harga, Weekdays, Weekend Attribut dari TRANSAKSI_MASUK : Id_Transaksi, Reservasi, Tgl_Checkin Attribut dari TRANSAKSI_KELUAR: Id_Transaksikeluar,Tgl_Checkout Step by step pembuatan Enrity Relationship Diagram Skema Kerja Hotel Menentukan attribut dari setiap entity :

Menentukan Primary Key dari setiap entity :

Menentukan Relationship antar entity :

Menentukan Cardinality Rasio :

Hasil dari ER Diagram :

Diposkan oleh Andy Setyaputra Udinus di 08.04 1 komentar: Kirimkan Ini lewat EmailBlogThis!Berbagi ke TwitterBerbagi ke Facebook

Selasa, 17 April 2012 DESAIN DATABASE

Buat para Database designer atau Database Administrator (DBA) mendesain database ialah hal yang sudah biasa mereka lakukan, namun bagaimana buat kita-kita yang baru saja mempelajari database, atau belum pernah sekalipn mendesain database? Maka disini saya ingin sharing bagaimana langkah-langkah mendesain sebuah database. Langkah-langkah mendesain sebuah database; 1. Pengumpulan data dan analisis. Langkah pertama dalam mendesain sebuah aplikasi database ialah memahami dan mengetahui data yang harus disimpan di dalam database, aplikasi apa yang harus dibangun diatasnya, dan jenis operasi apa yang lebih banyak digunakan, dan subjek untuk melakukan persyaratan yang ada. Untuk menspesifikasikan kebutuhan, yang pertama dilakukan ialaha mengidentifikasi bagian lain di dalam sistem informasi yang berinteraksi dengan sistem database. Termasuk pengguna yang baru atu yang sudah lama beserta aplikasinya, kebutuhankebutuhan tersebut dikumpulkan dan dianalisa. Aktifitas-aktifitas pengumpulan data dan analisa : 1. Menentukan kelompok pemakai dan bidang-bidang aplikasinya. 2. Peninjauan dokumentasi yang ada. 3. Analisa lingkungan operasi dan pemrosesan data. 4. Daftar pertanyaan dan wawancara.

Teknik yang digunakan dalam penspesifikasian kebutuhan secara formal : 1. OOA (Object Oriented Analysis) 2. DFD (Data Flow Diagram) 3. HIPO (Hierarchical Input Process Output) 4. SADT (Structured Analysis & Design) 2. Perancangan database secara konseptual Tujuan dari tahap ini adalah untuk menghasilkan skema konseptual untuk database yang tidak tergantung pada sistem manajemen database/DBMS yang spesifik. Penggunaan model data tingkat tinggi seperti ER/ER sering digunakan di dalam tahap ini. Untuk menciptakan gambaran yang sederhana tentang data yang mirip dengan pemikiran pengguna dan pengembang mengenai data tersebut. Di dalam skema konseptual dilakukan perincian aplikasi-aplikasi database dan transaksi-transaksi yang diketahui. Ada dua kegiatan di dalam perancangan database secara konseptual : 1. Perancangan Skema Konseptual Pada tahap ini kegiatn yang dilakukan mengecek tentang kebutuhan-kebutuhan data yang dihasilkan dari tahap 1, dimana tujuan dari proses perancangan skema konseptual ialah Menyatukan pemahaman struktur database, pengertian semantik, keterhubungan antar entitas dan attribut serta batasan-batasan. Dengan membuat sebuah skema database konseptual dengan menggunakan model data ER/EER tanpa tergantung dengan sistem manajemen database. Ada 4 strategi dalam perancangan skema konseptual : 1. Top Down 2. Bottom Up 3. Inside Out 4. Mixed Skema ini dapat dihasilkan dengan menggabungkan bermacam-macam kebutuhan user dan secara langsung membuat skema database atau dengan merancang skemaskema yang terpisah dari kebutuhan tiap-tiap user dan kemudian menggabungkan skema-skema tsb. Model data yang digunakan pada perancangan skema konseptual ialaha DBMSindependent, dan langkah selanjutnya adalah memilih sebuah DBMS untuk melaksanakan rancangan tsb. 2. Perancangan Transaksi Kegunaan tahap ini ialah Merancang karakteristik dari transaksi-transaksi yang akan di implementasikan tanpa tergantung dengan DBMS yang telah dipilih. Transaksitransaksi ini digunakan untuk memanipulasi database sewaktu diimplementasikan. Pada tahap ini diidentifikasikan input,output dan fungsional. Transaksi ini antara lain : Retrieval, Update, Delete, Select dll. 3.

Pemilihan Sistem Manajemen Database / DBMS

Langkah dalam memilih DBMS: a. Define Terms of Reference of Study

b. Shorlist 2 or 3 product Dengan memperhatikan budget yang tersedia, dukungan vendor, kompatible software. c. Evaluate product - Data definition - Physical definition (Struktur file, indexing, data compression, enkripsi). - Accessbility (Bahasa query, multi user, security) Pemilihan sistem manajemen database ditentukan oleh beberapa faktor, antara lain: 1. Faktor Teknik - Tipe model data - Struktur penyimpanan dan jalur pengaksesan yang didukung DBMS. - Tipe interface dan programmer - Tipe bahasa Querry 2. Faktor Ekonomi - Biaya penyediaan hardware dan software - Biaya konversi pembuatan database - Biaya personalia - Biaya pelatihan - Biaya pengoperasian - Biaya pemeliharaan 3. Faktor Organisasi - Struktur data - Personal yang terbiasa dengan sistem yang terdahulu - Ketersediaan dari service vendor

Perancangan database secara logika (Transformasi model data)

4. Fase selanjutnya dari perancangan database ialah membuat sebuah skema konseptual dan skema eksternal pada model data dari DBMS yang terpilih, Fase ini dilakukan oleh pemetaan skema konseptual dan skema eksternal yang dihasilkan pada fase 2. Fase ini, skema konseptualnya ditransformasikan dari model data tingkat tinggi yang digunakan pada fase 2 ke dalam model data dari DBMS yang dipilih pada fase 3. Teknik untuk mengevaluasi dari perancangan ini digunakan normalisasi. Proses ini akan menjamin bahwa data yang dihasilkan sudah tidak memiliki data yang rangkap, yang mengakibatkan anomali update pada saat implementasi. Ada 2 proses yaitu : 1. Transformasi yang tidak tergantung pada sistem. 2. Penyesuaian skema ke sistem manajemen database yang spesifik. Hasil dari fase ini memakai perintah-perintah DDL dalam bahasa DBMS yang dipilih yang menentukan tingkat skema konseptual dan eksternal dari sistem database. Tapi jika perintah DDL tersebut termasuk dalam parameter-parameter perancangan fisik, maka perintah-perintah DDL yang lengkap harus menunggu sampai tahap perancangan database secara fisik telah lengkap.

5. Perancangan database secara fisik Merupakan proses pemilihan struktur penyimpanan yang spesifik dan pengaksesan filefile database untuk mencapai kinerja yang terbaik di bermacam-macam aplikasi. Kriteria pemilihan perancangan fisik : 1. Waktu Respon (Response Time) Waktu transaksi database selama eksekusi untuk menerima respon. 2. Penggunaan ruang penyimpanan (Space Utility) Jumlah ruang penyimpanan yang digunakan oleh basis data file. 3. Terobosan yang dilakukan file transaksi (Transaction Throughput). Rata-rata jumlah transaksi yang dapat diproses per menit oleh sistem database. Denormalisasi merupakan proses yang dilakukan pada database yang sudah dinormalisasi, dengan cara memodifikasi struktur tabel dan mengabaikan kerangkapan data (yang terkontrol) untuk meningkatkan kinerja database. 6. Implementasi Sistem Database Setelah perancangan secara logika dan fisik lengkap, kita dapat melaksanakan sistem database. Perintah-perintah dalam DDL dan SDL (storage definition language) dari DBMS yang dipilih, dihimpun dan digunakan untuk membuat skema database dan filefile database (yang kosong). Lalu database tsb dimuat dengan datanya. Realisasi fisik database dan desain aplikasi : Program aplikasi untuk transaksi database dengan mengimplementasikan DML yang di embeded pada host programming (Cth Visual Basic, C++, Java, COBOL). Kontrol security dan integritas, dengan menggunakan SDL atau menggunakan utilities dari DBMS. Tujuan perancangan database : Untuk memenuhi kebutuhan akan informasi dari pengguna dan aplikasi. Menyediakan stuktur informasi yang natural dan mudah dimengerti oleh pengguna Mendukung kebutuhan pemrosesan dan beberapa obyek kinerja dari suatu sistem database.

Secara khusus proses perancangan berisikan 2 aktifitas paralel. Aktifitas yang pertama melibatkan perancangan dari is data dan struktur database, sedangkan aktifitas kedua mengenai perancangan pemrosesan database dan aplikasi-aplikasi perangkat lunak. Dua aktifitas ini saling berkaitan, misalnya mengidentifikasikan data sistem yang akan disimpan dalam database dengan cara menganalisa aplikasi-aplikasi database. Dan juga saling mempengaruhi satu sama lain. Contohnya tahap perancangan database secara fisik, pada saat memilih struktur penyimpandan dan jalur akses dari file suatu database dimana bergantung dengan aplikasi-aplikasi yang akan menggunakan file tersebut. Ke-enam tahap yang telah disebutkan sebelumnya dapat diproses secara tidak berurutan. Dalam beberapa hal, dapat dilakukan modifikasi perancangan kembali ke tahap yang pertama (feedback loop) setelah melakukan tahap selanjutnya.

Rich Picture dan Diagram Aktivitas

Rich Picture Menceritakan proses bisnis dengan menggunakan gambar Sangat baik untuk menjelaskan proses yang sedang berlangsung Wakilkan 1 kegiatan dengan 1 gambar Agar lebih jelas urutannya, berikan panah dari kegiatan ke kegiatan berikutnya Contoh Rich Picture, Adm Akademik

Proses Sablon

Service Barang

ACTIVITY

DIAGRAM

Menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses Dipakai pada business modeling untuk memperlihatkan urutan aktifitas proses bisnis Struktur diagram ini mirip flowchart atau Data Flow Diagram pada perancangan terstruktur Sangat bermanfaat apabila kita membuat diagram ini terlebih dahulu dalam memodelkan sebuah proses untuk membantu memahami proses secara keseluruhan Simbol Activity Diagram

CONTOH ACTIVITY Penarikan Uang dari Account Bank Melalui ATM

DIAGRAM

CONTOH

ACTIVITY

DIAGRAM

Activity Diagram Penjualan Kacamata

Activity Diagram Perjanjian Dokter Gigi

Activity Diagram Registrasi Mahasiswa Semester

STUDI

KASUS

ACTIVITY

DIAGRAM

Koperasi Budi Luhur adalah sebuah koperasi yang mengelola simpan pinjam bagi para anggotanya, berikut ini adalah kegiatan yang dilakukan oleh bagian Kredit dalam menangani pemberian pinjaman bagi para anggotanya. Setiap kali bagian kredit akan memberikan pinjaman kepada Anggota maka Anggota diharuskan mengisi Formulir Permohonan Pinjaman yang berisi Nomor FPP, Tanggal Permohonan, Nomor Anggota, Nama Anggota, Jumlah Permohonan dan Keperluan. Yang kemudian oleh Bagian Kredit dicatat dan disimpan kedalam Arsip FPP. Berdasarkan Arsip FPP tersebut Bagian Kredit membuat Bukti Peminjaman yang diberikan kepada Anggota yang berisi No. BP, tgl BP, Nomor Anggota, Nama Anggota, Jumlah Realisasi, Lama Angsuran, Jumlah Angsuran dan Bunga. Setiap Bulan Anggota diharuskan membayar Angsuran sejumlah Angsuran yang disepakati pada saat Peminjaman yang kemudian oleh bagian Kredit dicatat dan direkam kedalam Arsip Angsuran. Berdasarkan Arsip Angsuran tersebut bagian Kredit membuat Bukti Angsuran yang diberikan kepada Anggota yang berisi No. BA, Tanggal BA, No. BP, Jumlah Angsur dan Bunga Pada akhir bulan Bagian Kredit selalu membuat Laporan Peminjaman dan Laporan Angsuran yang diberikan Kepada Ketua Kope Latihan Activity Diagram ! PT. Nusantara adalah sebuah perusahaan yang bergerak dibidang penjualan Tunai barang-barang elektronik. Semua transaksi di perusahaan masih dilakukan secara manual. Berikut ini adalah kegiatan kegiatan yang dilakukan oleh bagian Penjualan dalam melaksanakan transaksi penjualan Barang di dalam perusahaan. 1. Pemesanan barang Setiap kali Bagian penjualan akan menjual barang ia selalu menerima surat pesanan dari pelanggan. Berdasarkan Surat pesanan tersebut bagian penjualan kemudian mencatat dan merekamnya kedalam Arsip Surat Pesanan. Berdasarkan Arsip surat pesanan tersebut, bagian penjualan membuatkan Faktur dan Surat Jalan yang dikirimkan kepada Pelanggan sebagai bukti bahwa barang yang dipesan sudah terealisasi dan rangkapnya disimpan sebagai Arsip Faktur dan Arsip Surat Jalan.

2. Pembuatan Kwitansi Apabila Faktur dan Surat Jalan sudah sampai ditempat pelanggan, maka pelanggan megirimkan Pembayaran yang kemudian oleh bagian penjualan dibuatkan Kwitansi yang dibuat berdasarkan Arsip Faktur yang kemudian diserahkan kepada pelanggan sebagai bukti pembayaran dan rangkapnya disimpan kedalam Arsip Kwitansi 3. Pembuatan Laporan Setiap akhir bulan Bagian Penjualan selalu membuat Laporan Penjualan berdasarkan Arsip Faktur dan Laporan Pesanan berdasarkan Arsip Pesanan dan Laporan Pengiriman berdasarkan Arsip Surat Jalan yang ditujukan kepada Kepala Bagian Penjualan Diminta : Buatlah Activity diagram dari data diatas !

Koperasi Budi Luhur

PT. Nusantara

Activity Diagram Entry KRS

Activitu Diagram

Activity diagram merupakan suatu bentuk flow diagram yang memodelkan alur kerja ( workflow ) sebuah proses bisnis dan urutan aktivitas sebuah proses. Diagram ini sangat mirip dengan sebuah flowchart karena kita dapat memodelkan sebuah alur kerja dari suatu aktifitas ke aktifitas lainnya atau dari suatu aktifitas kedalam keadaan sesaat. Activity diagram akan lebih bermanfaat apabila terlebih dahulu kita memodelkan sebuah proses untuk membantu kita memahami proses secara keseluruhan. Activity diagram juga sangat berguna ketika kita ingin menggambarkan perilaku parallel atau menjelaskan bagaimana perilaku dalam berbagai use case berinteraksi.

Dalam tugas kuliah ini saya akan mencoba membuat sebuah activity diagram yang ada di mesin ATM (Automatic Teller Machine).

1.

Activity Diagram Login Activity diagram login adalah proses awal yang dilakukan oleh nasabah sebelum melakukan proses transaksi.

2. 2. Activity Diagram Logout

Activity diagram logout adalah proses terakhir yang dilakukan oleh nasa bah dalam mengakses sistem mesin ATM. Proses ini juga akan dilakukan secara otomatis oleh sistem jika terjadi kesalaha-kesalahan seperti pin invalid tiga kali, koneksi ke sistem database terputus

3. Activity Diagram Cek Saldo

Activity diagram cek saldo adalah proses untuk mengecek atau menampilkan saldo terakhir.

4. Activity Diagram Penarikan Uang Tunai

Menggambar UML Use-case Diagram Use-case diagram merupakan model diagram UML yang digunakan untuk menggambarkan requirement fungsional yang diharapkan dari sebuah system. Use-case diagram menekankan pada siapa melakukan apa dalam lingkungan system perangkat lunak akan dibangun. Use-case diagram sebenarnya terdiri dari dua bagian besar; yang pertama adalah use case diagram (termasuk gambar use case dependencies) dan use case description. Berikut adalah Gambar Notasi Use Case Berikut adalah cara menggambar use-case diagram: Catatan: Sebaiknya membuat use-case diagram, diawali dengan membuat FDD terlebih dahulu. Hal ini sekedar untuk membantu mengidentifikasi proses-proses dalam sistem. 1) Mulai dengan mendaftarkan aktor yang berhubungan dengan Use-case, baik sebagai sender maupun receiver. 2) Komponen dalam use-case diagram adalah Nama Use-case, Deskripsi Use-case dan Pelaku yang berpartisipasi dan perannya. 3) Temukan dependency yang mendemonstrasikan hubungan semantik antara dua Use-case. Jika Use-case A berubah dapat mengakibatkan Use-case B akan berubah pula. Ada 2 macam dependency yang perlu diperhatikan yaitu include dan extend. Dependency include: Sebuah Use-case dapat meng-include fungsionalitas Use-case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa Use-case yang di-include akan

dipanggil setiap kali Use-case yang meng-include dieksekusi secara normal. Sebuah Use-case dapat di-include oleh lebih dari satu Use-case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common. Contoh Use-case (include) Ket: Pasien harus membuat temu janji sebelum diberikan perawatan yang diperlukan untuk mengobati penyakit yang dideritanya. Use-case Make Appointment meng-include fungsionalitas dari Use-case Get Treatment sebagai bagian dari proses saat dieksekusi. Dependency extend: Sebuah Use-case juga dapat meng-extend Use-case lain dengan behaviour-nya sendiri. Sementara hubungan generalisasi antar Use-case menunjukkan bahwa Use-case yang satu merupakan spesialisasi dari yang lain. Contoh Use-case (extend): Ket: Setelah pasien membuat temu janji dengan dokter, pasien ini tiba-tiba mendapat halangan sehingga tidak dapat memenuhi janjinya. Oleh karena itu, pasien ini membatalkan janji yang sudah dibuat. Ini merupakan contoh dari kasus extend dimana Make Appointment adalah base Use -case dan Cancel Appointment merupakan extended Use-case. Gambar Contoh Interaksi Antara Aktor dan Sistem (Use-case) Berikut adalah Contoh Use-case description Keterangan Normal course: Rangkaian kejadian yang terjadi sesuai harapan Alternate course: Mendokumentasikan kelakuan Use-case jika terjadi exception Pre-condition: Kondisi yang harus dipenuhi sebelum Use-case ini dijalankan. Hal ini dapat dilakukan dengan memberikan penjelasan singkat atau dapat pula berupa nama Use-case. Post-condition: Batasan pada keadaan sistem setelah Use-case ini diesksekusi dengan baik. Dapat berupa nama Use-case. Source at: http://kepenakwae.blogspot.com/2013/01/use-case-diagram-uml.html Copyright kepenakwae.blogspot.com Under Common Share Alike Atribution