Draft Modul Adsi-1

MODUL PRAKTIKUM

PROGRAM STUDI TEKNIK

INFORMATIKA UPN

“VETERAN” AWA TIMUR

SURABAY

A201

5

MODUL PRAKTIKUM ANALISA DAN DESAIN SISTEM INFORMASILABORATORIUM DESAIN DAN BASIS DATA – PRODI TEKNIK INFORMATIKA

BAB I ANALISA

SISTEM

Tujuan Instruksional Khusus :- Praktikan mampu menjelaskan konsep analisis sistem dan menghubungkannya

dengan istilah fase definisi lingkup, analisis masalah, desain logis dan analisis keputusan metodologi pengembangan sistem.

- Praktikan mampu mendeskripsikan sejumlah pendekatan analisis sistem untuk memecahkan masalah-masalah sistem.

- Praktikan mampu mendeskripsikan fase definisi lingkup, analisis masalah, analisis persyaratan, desain logis dan analisis keputusan dalam artian tujuan, input, output, teknik dan langkah bahkan hingga artian blok-blok pembangun sistem.

1. 1. Analisis Sistem

Analisis sistem adalah sebuah tehnik pemecahan masalah yang menguraikan sebuah sistem menjadi bagian-bagian komponen dengan tujuan mempelajari seberapa bagus bagian- bagian komponen tersebut bekerja dan berinteraksi untuk meraih tujuan. Analisis sistem dikendalikan oleh kepedulian bisnis para pemilik sistem (system owners) dan pengguna sistem (system users). Sedangkan para analis sistem berperan sebagai fasilitator dalam analisis sistem. Terdapat lima fase dalam analisis sistem yang akan dibahas yaitu :- Fase Ruang Lingkup- Fase Analisis Masalah- Fase Analisis Kebutuhan- Fase Desain- Fase Analisis Keputusan

1. 1. 1. Fase Ruang Lingkup

Fase ruang lingkup bisa juga disebut dengan fase penyelidikan, fase studi awal atau fase perencanaan. Fase ruang lingkup menetapkan kelayakan, skala, strategi pengembangan, jadwal, sumber daya dan anggaran. Dalam fase ini terdiri dari beberapa pekerjaan lagi, antara lain :- Mengidentifikasi masalah-masalah dan kesempatan-kesempatan titik tolak.

Tugas ini menentukan titik tolak awal masalah-masalah, kesempatan-kesempatan dan atau perintah yang memicu proyek. Contohnya urgensi, visibilitas, keuntungan,prioritas atau solusi-solusi yang mungkin.

- Menegosiasikan lingkupMendefinisikan batasan-batasan proyek, aspek-aspek bisnis yang akan atau tidak

dimasukkan dalam proyek. Contohnya seperti tipe-tipe data, proses-proses bisnis atau bahkan antarmuka.

- Menilai kelayakan proyekMenentukan apakah proyek ini layak dikerjakan, memecahkan masalah,

mengeksploitasi kesempatan atau minimal bisa mengembalikan nilai yang dikeluarkan untuk proyek.

- Mengembangkan jadwal dan anggaran


Setelah dianggap layak, rencana proyek paling tidak harus terdiri dari rencana induk pendahuluan yang tediri dari jadwal penugasan sumber daya untuk keseluruhan dan rencana dan jadwal terinci untuk menyelesaikan fase selanjutnya yaitu fase analisis masalah.

- Mengkomunikasikan rencana proyekPerlu adanya seseorang atau bagian yang menyetujui dan memonitor proyek dan

pengembangan. Para manajer sistem informasi berperan untuk menjawab pertanyaan- pertanyaan dan mengkomunikasikan prioritas-prioritas kepada para pengembang dan manajer proyek.

1. 1. 2. Fase Analisis Masalah

Tujuan fase ini adalah mempelajari dan memahami bidang masalah dengan cukup baik untuk secara menyeluruh menganalisis masalah, kesempatan dan batasannya. Fase analisis masalah terdiri dari beberapa tugas, antara lain :- Memahami bidang masalah

Beberapa pendekatan yang dapat digunakan sebagai kerangka untuk mendaftardan mendefinisikan bidang sistem antara lain pengetahuan, proses dan komunikasi.

- Menganalisis masalah dan kesempatanPemahaman akan bidang masalah sangatlah krusial karena anggota tim

seharusnya tidak mencoba menganalisis masalah-masalah kecuali mereka memahami bidang tempat masalah-masalah tersebut muncul. Produk dari tugas ini dapat berupa pernyataan masalah dan analisis sebab-akibat yang diperbarui untuk tiap masalah dan kesempatan.

- Menganalisis proses bisnisTugas ini hanya cocok untuk proyek business process redesign / desain ulang

proses bisnis atau proyek pengembangan sistem yang dibangun pada atau membutuhkan desain ulang proses bisnis yang signifikan. Produk dari tugas ini adalah model proses dan analisis proses yang sedang berjalan, yang dapat secara signifikan dilengkapi dengan volume data yang mengalir selama proses, waktu respon tiap proses, dan penundaan/ hambatan yang muncul dalam sistem.

- Menentukan tujuan-tujuan perbaikan sistemTujuan dari tugas ini adalah menentukan kriteria dimana semua perbaikan pada

sistem akan diukur dan untuk mengidentifikasi semua batasan yang membatasi fleksibilitas semua perbaikan tersebut. Contoh dari perbaikan sistem yaitu “Kurangi pengurangan piutang sebesar 20% dengan cara mengenali sesegera mungkin jumlah penunggak”.

- Memperbarui atau mengasah proyekKemungkinan bahwa tidak semua sasaran dapat dipenuhi oleh sistem yang baru.

Tugas ini digerakkan oleh kelengkapan sasaran perbaikan sistem, rencana proyek dan rencana proyek yang sudah diperbarui.

- Mengkomunikasikan penemuan-penemuan dan rekomendasi-rekomendasiTugas ini dipicu oleh penyelesaian rencana proyek yang sudah diperbarui dan

input informasi yang meliputi analisis masalah, model sistem, sasaran peningkatansistem. Format dapat berupa sebuah laporan, presentasi verbal atau berupa pemeriksaan oleh auditor atau peer group.

1. 1. 3. Fase Analisis Persyaratan

Fase analisis persyaratan menentukan persyaratan bisnis bagi sistem yang baru. Sudut pandang yang digunakan dalam fase ini adalah beberapa alternatif solusi khususnya solusi teknis. Fase ini mencakup beberapa tugas, antara lain :


- Mengidentifikasi dan menyatakan persyaratan sistemMenerjemahkan sasaran-sasaran ke dalam functional requirement yaitu deskripsi

mengenai aktifitas dan layanan yang harus diberikan/ disediakan oleh sebuah sistem dan nonfunctional requirement yaitu deskripsi mengenai fitur, karakteristik dan batasan lainnya yang menentukan apakah sistem memuaskan atau tidak.

- Membuat prioritas persyaratan sistemSetelah persyaratan-persyaratan sistem dibuat maka perlu adanya sebuah

prioritas persyaratan yang difasilitasi menggunakan timeboxing yaitu sebuah teknikmenyampaikan fungsionalitas dan persyaratan sistem informasi melalui versi-versi. Tim pengembangan memilih subset terkecil dari sistem tersebut, yang jika diimplementasikansecara penuh akan memberikan nilai yang berguna bagi pemilik dan pengguna sistem. Subset tersebut dikembangkan idealnya dengan kerangka waktu 6 sampai 9 bulan atau kurang. Dengan demikian, versi yang bernilai tambah dari sistem juga dikembangkan dalam kerangka waktu yang sama.

- Memperbarui atau memperhalus rencana proyekTim harus mempertimbangkan kemungkinan bahwa sistem baru mungkin lebih

besar daripada yang semula diharapkan. Tugas ini dipicu oleh selesainya kelengkapan prioritas dan persyaratan dengan rencana proyek yang up-todate sebagai input kunci.

- Mengkomunikasikan pernyataan persyaratanPada tugas ini analis harus mengkomunikasikan persyaratan dan prioritas kepada

komunitas bisnis secara terus menerus. Ketrampilan antarpersonal, komunikasi dannegoisasi sangatlah penting dalam tugas ini.

1. 1. 4. Fase Desain Logis

Fase ini mendokumentasikan persyaratan bisnis dengan menggunakan model-model sistem yang menggambarkan struktur data, proses bisnis, aliran data dan antarmuka pengguna. Fase desain logis umumnya mencakup tugas-tugas lain, antara lain :- Menstruktur persyaratan fungsional

Menggambar atau memperbarui satu atau lebih model sistem untuk menggambarkan persyaratan fungsional yang mencakup kombinasi data, proses danmodel objek yang secara akurat menggambarkan persyaratan bisnis dan persyaratan pengguna.

- Prototipe persyaratan fungsionalDengan prototipe dapat memberikan sebuah alternatif untuk pemodelan sistem

sehingga dapat membantu pengguna jika mengalami kesulitan untuk menyatakan fakta- fakta yang diperlukan untuk menggambar model sistem yang tepat.

- Validasi persyaratan fungsionalModel sistem dan prototipe memerlukan validasi dalam hal kelengkapan

dan kebenarannya. Analis sistem memfasilitasi tugas penyusunan prioritas dengan secarainteraktif menyatukan pengguna sistem untuk mengidentifikasi kesalahan dan kelalaian atau untuk membuat klarifikasi.

- Menentukan penerimaan test caseTest case digunakan untuk menguji program dalam hal kebenarannya. Hal ini

dilakukan dengan memvalidasi antara analis sistem dengan pengguna sistem.

1. 1. 5. Fase Analisis Keputusan


Tujuan fase ini adalah untuk mengenali solusi kandidat, menganalisa solusi kandidat tersebut dan merekomendasikan sebuah sistem target yang akan dirancang, dibangun dan diimplementasikan. Hasil akhir dari fase ini adalah Proposal Sistem yang akan memenuhi


persyaratan bisnis yang telah diidentifikasi pada fase sebelumnya. Fase analisis keputusan umumnya mencakup tugas berikut :- Mengidentifikasi solusi kandidat

Solusi kandidat akan diketahui melalui ide-ide dan berbagai opini tentang perancangan dari pemilik sistem, pengguna sistem, desainer maupun konsultan teknis. Tugas ini hanya untuk menentukan solusi kandidat yang mungkin dapat dipertimbangkan.

- Menganalisa solusi kandidatAnalisis ini dapat dilakukan ketika masing-masing kandidat atau setelah semua

kandidat diidentifikasi. Analisis kelayakan seharusnya tidak terbatas biaya dan manfaat. Terdapat empat kriteria ketika mengevaluasi solusi, antara lain; technical feasibility, operational feasibility, economic feasibiliy dan schedule feasibility.

- Membandingkan solusi kandidatSetelah analisis kelayakan telah dilengkapi maka dapat dibandingkan kandidat

- kandidat dan memilih satu atau lebih solusi untuk merekomendasikannya kepada pemilik sistem dan pengguna sistem. Hasil akhir dari tugas ini adalah sebuah solusi yang direkomendasikan, namun jika terdapat lebih dari satu solusi maka prioritas tetap harus diterapkan.

- Memperbarui rencana proyekTugas ini dipicu oleh penyelesaian solusi untuk direkomendasikan. Jadwal proyek

dan penugasan sumber daya terbaru harus ditinjau kembali dan diperbarui dengan output kunci adalah rencana proyek yang diperbarui.

- Merekomendasikan solusi sistemDalam tugas ini tim merekomendasikan solusi sistem kepada komunitas bisnis.

Analis sistem harus mampu menuliskan laporan bisnis tertulis dan membuat sebuah presentasi bisnis tanpa harus masuk pada isu-isu teknis atau alternatif.

1. 2. Penemuan Fakta

Untuk mengembangkan sistem yang efektif diperlukan teknik untuk mengidentifikasi, menganalisis dan memahami persyaratan sistem yang disebut dengan requirement discovery yang menghasilkan system requirements yang menentukan apa yang seharusnya dikerjakan oleh sistem informasi atau properti serta kualitas apa yang harus dimiliki oleh sistem. System requirement harus memiliki beberapa kriteria antara lain; Konsisten, Komplet, Kelayakan, Dibutuhkan, Akurat, Dapat Dilacak dan Dapat Diuji. Setelah system requirement dibuat, selanjutnya perlu adanya sebuah model proses yang tidak dapat dibuat tanpa fakta dan informasi tepat yang dikirim oleh komunitas pengguna. Fakta tersebut dapat dikumpulkan melalui sejumlah teknik seperti sampling terhadap form dan file yang ada, riset terhadap sistem yang serupa, survei terhadap pengguna dan manajemen, wawancara pengguna dan manajemen. Terdapat juga metode tercepat dalam pengumpulan fakta dan informasi dan secara serempak membuat dan menguji model proses disebut joint requirements planning.

1. 3. Tugas 1

Lakukan proses analisis sistem terhadap studi kasus yang telah ditentukan, meliputi fase ruang lingkup, fase analisis masalah, dan fase analisis persyaratan. Lengkap juga dengan bisnis proses dan bisnis workflow.


BAB II

DATA FLOW DIAGRAM

Tujuan Instruksional Khusus :

Mahasiswa mampu mendesain dan memodelkan seluruh arsitektur aplikasi sistem informasi yang berfokus kepada model proses fisik dengan memanfaatkan diagram alir data fisik.

2. 1. Konsep Sistem untuk Pemodelan Proses

Sebagian besar teknik analisis sistem berasal dari aplikasi teori sistem formal dan konsep terhadap pemecahan persoalan sistem yang biasa dikenal dengan system thinking.

2. 1. 1. Konsep Proses

Proses sistem informasi merespons kejadian dan kondisi bisnis dan mentransformasi data menjadi informasi yang berguna.

» Sistem adalah prosesDalam analisis sistem, model digunakan untuk menampilkan dan menyajikan

sistem. Beberapa simbol model proses dapat dilihat pada Gambar 1. Proses adalah kerja yang dilakukan pada atau sebagai respons terhadap aliran data masuk atau kondisi.

Nama Proses Nama Proses Nama Proses

De Marco/ Yurdon Gane & Sarson(yang digunakan)

Gambar 1. Beberapa notasi proses

SSADM / IDEF (0)

Dekomposisi proses adalah kegiatan menguraikan sistem menjadi subsistem, proses dan subproses komponennya. Dengan dekomposisi memungkinkan mempartisi sistem menjadi subsistem logika dari proses untuk peningkatan komunikasi, analisis dan desain. Beberapa aturan dalam melakukan dekomposisi sistem, antara lain :» Tiap proses dalam diagram dekomposisi merupakan proses induk dan proses anak

atau keduanya.» Induk harus memiliki dua anak atau lebih – satu anak tunggal tidak masuk akal

karena tidak akan menunjukkan detail tambahan mengenai sistem tersebut.» Dalam sebagian besar standar pendiagraman dekomposisi satu anak dapat

hanya memiliki satu induk.» Anak dari satu induk dapat menjadi induk dari anak-anaknya sendiri

Selain itu terdapat batasan pada proses logika:» Hanya kata kerja perintah kuat yang dapat digunakan» Hanya nama yang telah didefinisikan dalam istilah proyek yang dapat digunakan» Rumusan harus dinyatakan secara jelas dengan menggunakan notasi matematis yang

tepat» Kata sifat dan kata keterangan yang tidak terdefinisikan tidak diperbolehkan,

kecuali jika didefinisikan secara jelas dalam istilah proyek» Jika mengalami keraguan, maka kemudahan baca bagi pengguna harus

diprioritaskan daripada preferensi programer


2. 1. 2. Aliran data

Aliran data adalah komunikasi antara proses dan lingkungan sistem yang menunjukkan input data ke proses atau output data dari proses. Disimbolkan seperti pada Gambar 2.

Nama aliran data

Gambar 2. Simbol Aliran DataTerdapat beberapa aturan mengenai aliran data baik itu dengan proses

maupun dengan data store, yang ditunjukkan seperti pada Tabel 1.

Tabel 1. Aliran Data IlegalAliran Data Ilegal Aliram Data Legal

P 1 P 1

P 1 Data Store

Data Store P 1

Data Store Data Store

Sebuah proses dibutuhkan untukP 1 mengubah aliran data P 1 di antara agen

eksternal

Sebuah proses

P 1 dibutuhkan untuk

Data Store menggunakan sebuah

data store

Sebuah proses

Data Store dibutuhkan untuk

P 1 menyajikan data dari

sebuah data store

Sebuah proses dibutuhkan untukData Store memindahkan data Data Store

dari data store ke data store lain

2. 1. 3. Agen Eksternal

Agen eksternal yang termasuk dalam lingkungan sistem membentuk batasan sistem dan mendefinisikan tempat di mana sistem berhadapan dengan lingkungannya. Hal ini bisa berupa orang, unit organisasi, sistem lain atau organisasi lain, yang berada di luar lingkup proyek tetapi berinteraksi dengan sistem yang sedang dikembangkan atau dipelajari. Contohnya adalah departemen, pengguna akhir atau sistem informasi lain. Gambar 3 adalah simbol dari agen eksternal.

Agen EksternalAgen Eksternal

AgenEksternal

Gambar 3. Simbol Agen EksternalAgen eksternal sebaiknya dinamai dengan kata benda tunggal yang deskriptif

seperti supplier, financial system atau pengguna.

2. 1. 4. Data Store

Data store digunakan sebagai penyimpanan data yang ditujukan untuk penggunaan selanjutnya. Simbol untuk data store dapat dilihat pada Gambar 4.


Data Store

Gambar 4. Simbol Data Store

2. 2. Model Proses

Analis sistem harus mempelajari bagaimana menggambarkan diagram dekomposisi dan aliran data untuk memodelkan persyaratan proses bisnis.

2. 2. 1. Diagram Aliran Data Konteks

Untuk membuat diagram aliran data konteks diperlukan adanya lingkup proyek yang mendefinisikan aspek bisnis yang harus didukung oleh sistem atau aplikasi dan bagaimana sistem yang dimodelkan berinteraksi dengan sistem lain dan bisnis lain secara keseluruhan. Selanjutnya, disarankan untuk tidak menunjukkan semua input dan output antara sistem dan bisnis dan dunia luar. Cukup dengan menunjukkan aliran data yang menyatakan tujuan utama atau input output yang paling penting dari sistem tersebut.

Terdapat beberapa strategi yang harus dipertimbangkan dalam membuat diagram aliran data konteks, yaitu :- Pikirkan sistem sebagai kontainer untuk dapat membedakan antara bagian dalam

dan bagian luarnya.- Tanyalah pengguna akhir sistem anda, transaksi bisnis seperti apa yang harus

direspon oleh sistem.- Tanyalah pengguna akhir anda, respons apa yang harus dihasilkan sistem.- Identifikasi tiap data store eksternal.- Gambar diagram konteks dari semua informasi sebelumnya.

2. 2. 2. Diagram Sistem

Diagram sistem menyajikan konteks yang berarti bagi pengguna untuk mensahkan akurasi tiap kejadian yang harus direspons sistem. Kejadian tersebut secara kolektif mendefinisikan sistem dan subsistem.

2. 3. Tugas 2

Buatlah model proses beserta aliran data (DFD / Data Flow Diagram) sedetail mungkin terhadap studi kasus sistem yang telah ditentukan dan sesuaikan dengan analisis yang telah dilakukan pada tugas sebelumnya.


MODUL 3DETAIL DATA FLOW DIAGRAM

Tujuan Instruksional Khusus :

1. Mahasiswa mengetahui konsep dasar Kamus Data dan Isi Kamus Data

2. Mahasiswa diharapkan dapat menggunakan masing-masing Kamus Data dan Struktur

Data sesuai dengan sistem yang sedang mereka kembangkan

3.1 Kamus Data

Kamus data (KD) atau data dictionary (DD) atau disebut juga dengan ist

ilah systems data dictionary adalah katalog fakta tentang data dan kebutuhan

kebutuhan informasi dari suatu sistem informasi. Dengan menggunakan KD, analis

sistem dapat mendefinisikan data yang mengalir di sistem dengan lengkap. KD

dibuat pada tahap analisis sistem dan digunakan baik pada tahap analisis

maupun pada tahap perancangan sistem. Pada tahap analisis, KD dapat digunakan

sebagai alat komunikasi antara analis sistem dengan pemakai sistem tentang data yang

mengalir di sistem, yaitu tentang data yang masuk ke sistem dan tentang

informasi yang dibutuhkan oleh pemakai sistem. Pada tahap perancangan sistem,

KD digunakan untuk merancang input, merancang laporan-laporan dan database. KD

dibuat berdasarkan arus data yang ada di DFD. Arus data di DFD sifatnya adalah

global, hanya ditunjukkan nama arus datanya saja. Keterangan lebih lanjut tentang

struktur dari suatu arus data di DFD secara lebih terinci dapat dilihat di KD. Kamus

data perlu ditambahkan pada data flow dan data store, untuk menjelaskan detail dari elemen

data agar semua stakeholder memiliki persepsi yang sama. Gambar 3.1 menunjukkan

hubungan antara DFD dengan KD. Serta contoh penambahan kamus data untuk data flow

(Gambar 3.2) dan data store (Gambar 3.3).

Data Dictionary (kamus data) untuk Data Flow meliputi

komponen: Nama : Nama dari Data Flow di DFD

Deskripsi : Penjelasan rinci (apa maksudnya)

Aliran : Sumber dan tujuan (darimana dan kemana)

Periode : Kapan terjadinya (waktu atau kejadian lain yang

memicu) Struktur : Komposisi data, contoh:

Pelanggan = nama_pel + alamat_pel

nama_pel = karakter huruf = [A-Z | a-z]

alamat_pel = nama_jalan + nomor_rumah + nama_kota + (kode_pos)

nama_jalan = karakter huruf = [A-Z | a-z]

nomor_rumah = karakter angka + (karakter huruf) = [0-9] + (A-Z)

nama_kota = karakter huruf = [A-Z | a-z]

kode_pos = 5 digit karakter angka


Gambar 3.1 Hubungan antara Data Flow Diagram dan Kamus Data

Gambar 3.2 Kamus data untuk data flow.


Data Dictionary untuk Data Store, meliputi komponen: Nama : Nama dari Data Store di DFD Deskripsi : Penjelasan rinci (apa maksudnya) Struktur : Komposisi Tabel pada DBMS, contoh:

Gambar 3.3 Contoh Kamus data untuk data store.

3.2 Spesifikasi Proses

Spesifikasi proses ditambahkan pada DFD level terendah. Spesifikasi proses digunakan untuk menjelaskan detail prosedur elemen proses pada DFD level terendah agar semua stakeholder memiliki persepsi yang sama. Selain itu, spesifikasi proses memudahkan Programmer untuk membuat kode-kode program sesuai dengan yang dimaksud oleh System

Analyst. Komponen spesifikasi proses antara lain: Nomor : Nomor ProsesNama : Nama ProsesDeskripsi : Penjelasan rinci (apa maksudnya)Input : Data Flow Input dan Asalnya Output : Data Flow Output dan Tujuannya Struktur : Algoritma / prosedur detail dari Proses


Bentuk spesifikasi proses:1. Common Style, bentuk umum / bebas yang mudah dipahami (bisa

menggunakan bahasa apapun).2. Pseudocode, bentuk yang mirip dengan kode program, menggunakan bahasa

inggris yang terstruktur (Structured English).3. Program Flowchart, bentuk diagram yang menggambarkan alur program (bagan alur).

Contoh spesifikasi proses bentuk common style

Mencatat Nama MahasiswaMencatat NRP Mahasiswa

Untuk setiap mata kuliah yang diambil Tampilkan nama dan sks mata kuliah Hitung total sks sampai saat ini

Tampilkan Total Sks

Jika total sks lebih besar dari 18Maka Tampilkan peringatan

SelainnyaTampilkan persetujuan

Contoh spesifikasi proses bentuk Pseudocode

Read Nama MahasiswaRead NRP MahasiswaFor each mata kuliah yang diambil

Print nama dan sks mata kuliah total_sks = total_sks + sks

Print total sks

If total sks > 18Then Print Peringatan

ElsePrint Persetujuan

Contoh spesifikasi proses dapat dilihat pada Gambar 3.4.

Gambar 3.4 Contoh spesifikasi proses dengan bentuk flowchart.


MODUL 4

USE CASE DIAGRAM

Use Case Diagram menyajikan interaksi antara use case dan aktor. Dimana aktor dapat berupa orang, peralatan atau sistem lain yang beinteraksi dengan sistem yang dibangun. Use case menggambarkan fungsionalitas sistem atau persyaratan-persyaratan yang harus dipenuhi sistem dari pandangan pemakai. Jika Business Use Case Diagram tidak memperhatikan apakah proses dilakukan secara otomasi terkomputerisasi, maka Use Case Diagram berfokus hanya pada proses otomatisasi saja.

Dalam bagian ini akan membahas tentang konsep dasar pemodelan use case meliputi:

use case, actor dan relasi. Jika sudah memahami pemodelan bisnis, ada kemiripan antara

pemodelan bisnis dan pemodelan use case. Perbedaanya adalah jika pada pemodelan bisnis memfokuskan pada organisasi, sedangkan pemodelan sistem berfokus pada sistem yang sedang dibangun. Perbedaan antara pemodelan bisnis dan pemodelan sistem :

Tabel 4.1. Perbedaan Pemodelan Bisnis dengan Pemodelan Sistem

ItemPemodelan Bisnis (Business

Use Case)Pemodelan Sistem (Use

Case)

Use CaseMenjelaskan apa yangbisnis kerjakan

Menjelaskan apa yangsistem lakukan di bisnis

AktorEksternal terhadap organisasi

Eksternal terhadap sistem(mungkin internal terhadapsistem)

Pekerja Bisnis Internal terhadap organisasi Tidak digunakan

4.1. Use CaseUse Case adalah bagian tingkat tinggi dari fungsionalitas yang disediakan oleh

sistem. Dengan kata lain, use case menggambarkan bagaimana seseoarang menggunakan sistem.

Untuk mengidentifikasi use case, kita menjawab pertanyaan : apa yang sistem lakukan terhadap dunia sekelilingnya?. Dalam UML, use case dimodelkan dengan menggunakanikon:

Gambar 4.1. Notasi Use Case

Use case adalah independen terhadap implementasinya dan pandangan tingkat tinggi apa yang pemakai harapkan dari sistem. Dengan penjelasan sebagai berikut :1. Use case adalah independen terhadap implementasinya. Selama membuat use case,

asumsikan bahwa anda sedang membangun sebuah sistem manual. Use case anada harus mampu dibangun dalam Java, Visual Basic, C++, atau kertas. Use case berkonsentrasi pada apa yang system harus kerjakan, bukan bagaimana sistem mengerjakannya.

2. Use case adalah pandangan tingkat tinggi apa yang pemakai harapkan dari sistem. Use case yang sudah dikelompokkan memudahkan pelanggan memahaminya, pada level yang sangat tinggi dari sustu sistem.

3. Use case difokuskan pada apa yang pengguna dapatkan dari sistem. Masing-masing usecase mempresentasikan transaksi lengkap antara pemakai dan sistem yang menghasilkan manfaat terhadap pemakai.


Use case diberikan nama dalam termoniologi pemakai, bukan terminologi teknikal, dan harus bermakna terhadap pelanggan. Nama sebuah use case adalah kata kerja atau frase kata


kerja dengan format ”<kata kerja><kata benda>” , dan menjelaskan apa yang pelangganperhatikan sebagai hasil akhir.

2.2. ActorActor adalah seseorang atau apa saja yang berhubungan dengan sistem yang

sedangdibangun. Use Case menggambarkan semua yang ada dalam ruang lingkup sistem. Actor merupakan semua yang ada di luar ruang lingkup sistem. Dalam UML, actor dimodelkan dengan menggunakan ikon :

Gambar 4.2. Notasi Actor

Ada 3 tipe actor, yaitu :1. Pengguna sistem

Actor secara fisik atau seotang pengguna. Ini adalah gambaran actor secara umum, dan selalu ada pada setiap sistem. Untuk sistem sirkulasi perpustakaan, actor-nya adalah orang-orang yang secara langsung menggunakan sistem. Ketika menamakan actor, gunakan nama peranan dan jangan gunakan nama posisi. Posisi dapat berubah, tetapi peranan dapat digantikan oleh siapa saja dan relatif tetap.

2. Sistem lain yang berhubungan dengan sistem yang dibangun3. Waktu

Waktu dapat menjadi suatu actor ketika melalui sejumlah waktu tertentu memicubeberapa kejadian dalam sistem. Misalnya, bagian promosi memberikan kesempatan pada pelanggan untuk memenangkan tiket gratis. Setiap hari pada pukul 03.00 dini hari, sistem secara otomatis menyeleksi secara acak pelanggan-pelanggan untuk mendapatkan tiket gratis tersebut. Sebab waktu adalah di luar kendali kita, maka ia dapat menjadi actor.

2.3. RelasiKita telah membahas use case dan actor, sekarang akan dibahas relasi antar use

case untuk mendapatkan sistem secara utuh.Relasi asosiasi digunakan untuk menunjukkan relasi antara use case dan actor. Ada

tiga tipe relasi antara use case : relasi include, relasi extend, dan relasi generalisasi. Sedangkanrelasi antara actor hanya digunakan satu relasi yaitu generalisasi.

Relasi AssosiasiRelasi antara actor dan use case adalah relasi assosiasi. Dalam UML, relasi

assosiasidigambarkan dengan menggunakan anak panah.



Gambar 4.3. Relasi Assosiasi

Dalam contoh, use case mengawali komunikasi dengan actor sistem kredit. Selama use case ”Purchase Ticket” berjalan, sistem reservasi mengawali komunikasi dengan sistem kredit untuk mengecek kartu dan melengkapi transaksi. Meskipun aliran informasi terjadi dalam dua arah, dari reservasi sistem ke kartu kredit dan bolak-balik, arah panah mengindikasikan siapa yang mengawali komunikasi. Dengan mengecualikan use case dalam relasi include dan relasi extend, setiap use case harus diinisialisasi oleh actor.

Gambar 4.4. Relasi assosiasi dua actor

Relasi IncludeRelasi include memungkinkan satu use case menggunakan fungsionalitas

yangdisediakan oleh use case lainnya. Relasi ini dapat digunakan dengan alasan salah satu dari dua hal, yaitu :1. Jika dua atau lebih use case mempunyai bagian besar fungsionalitas yang identik,

maka fungsionalitas ini dapat dipecah ke dalam use case tersendiri. Masing-masing use casekemudian menggunakan relasi include terhadap use case baru dibuat tersebut.

2. Relasi include bermanfaat untuk situasi jika sebuah use case mempunyai fungsionalitasbesar yang tidak umum. Relasi include digunakan untuk memodelkan dua buah use case yang lebih kecil tersebut.

Relasi include meyatakan bahwa satu use case selalu menggunakan fungsionalitas yang disediakan oleh use case lainnya.

Gambar 4.5. Relasi include

Relasi ExtendRelasi extend memungkinkan satu use case secara opsional menggunakan

fungsionalitas yang disediakan oleh use case lainnya. Dalam UML, relasi extend digambarkan sebagaiberikut :

Gambar 4.6. Relasi extend

Relasi ExtendRelasi generalisasi digunakan untuk menunjukkan bahwa beberapa actor atau use

casemempunyai beberapa persamaan. Sebagai contoh, ada dua tipe pelanggan : pelanggan perusahaan dan pelanggan individu. Hal ini dapat dimodelkan dengan relasi ini menggunakan notasi :


Gambar 4.7. Relasi generalisasi

T ut o r i a l U s e Ca s e Dia g r a m 1. Expand Use Case view. Double klik pada Main.

2. Gunakan toolbar untuk menambahkan Actor, Use Case ke dalam use case diagram.

3. Tambahkan relasi antara use case dan actor.


4. Untuk melihat Class Specification, double klik pada use case.

LATIHAN MODUL 41. Buatlah Business Use Case Diagram dari soal yang diberikan !


MODUL 5ACTIVITY DIAGRAM

Activity diagram adalah cara lainnya untuk memodelkan aliran kejadian. Menggunakan teks adalah bermanfaat, tetapi akan kesulitan membaca dan memahami jika logika aliran kejadian sudah komplek.

Activity diagram menunjukkan informasi yang sama sebagaimana dalam aliran kejadiandengan teks. Kita menggunakan Activity diagram dalam pemodelan bisnis untuk menggambarkan aliran kerja (workflow) yang ada dalam proses bisnis.

Beberapa simbol yang digunakan antara lain :Activity

Activity secara sederhana dapat diartikan sebagai langkah dalam proses. Dalam UML,activity digambarkan sebagai berikut :

Menampilkan FormPinj am Buku

Gambar 5.1. Activity

Kita dapat menambahkan langkah-langkah detil ke dalam activity dengan menggunakan aksi-aksi. Aksi-aksi adalah langkah-langkah lebih kecil dalam activity. Mereka mungkin salah satu dari empat hal berikut ini :

1. Saat sedang memasuki activity. Aksi Entry (entry action) terjadi segera saat activityini dimulai dan ditandai dengan kata ”entry”.

2. Ketika sedang meninggalkan activity. Aksi exit (exit action) terjadi pada saat

meninggalkan activity dan ditandai dengan kata ”exit”.3. Ketika sedang berada dalam sebuah activity. Aksi ini terjadi saat di dalam

activitydan selau terjadi hingga meninggalkan activity. Aksi ini ditandai dengan kata

”do”4. Kejadian spesifik (specific event). Aksi ini terjadi jika dan hanya jika

kejadianspesifik terjadi. Aksi ini ditandai dengan kata ”event”

Aksi-aksi tersebut opsional, tapi dapat memberikan informasi rinci yang akan membantu untuk melengkapi rancangan sistem di kegiatan berikutnya.Start dan End State

Start dan End state sebagaimana yang kita ketahui adalah untuk memulai dan

mengakhiri flow. Setiap activity diagram harus mempunyai start state dan diakhiri dengan end state. End state adalah opsional dan bisa lebih dari satu dalam satu Activity diagram. Dalam UML, digambarkan sebagai berikut :

Start state End state

Gambar 5.2. Notasi Start state dan End state

Obyek dan Aliran ObyekObyek adalah entitas yang digunakan dalam aliran. Obyek mungkin digunakan

ataudirubah oleh activity dalam aliran. Pada Activity diagram, kita dapat menampilkan obyek dan kondisinya, sehingga kita dapat memahami di mana dan bagaimana kondisi obyek tersebut berubah.

Obyek dihubungkan ke activity menggunakan aliran obyek (object flow). Aliran obyek


digambarkan dengan garis panah putus-putus. Jika garis panah mempunyai arah dari activity ke obyek berarti ia memperbarui nilai obyek tersebut, dan jika arah panah dari obyek ke activity berarti ia sedang menggunakan obyek.


TransisiTransisi menunjukkan bagaimana aliran kontrol bergerak dari satu activity ke activity

lainnya. Transisi digambarkan menggunakan anak panah dengan nama transisi menunjukkan nama kejadiannya.

Kejadian (event) memicu terjadinya transisi, kondisi (guard condition) mengontrol ada atau tidak ada transisi yang terjadi, sebuah kondisi harus benar agar transisi dapat terjadi.

SinkronisasiSinkronisasi adalah suatu cara untuk menunjukkan bahwa dua atau lebih cabang

dari aliran terjadi secara paralel.

Tutorial Activity diagram1. Untuk membuat activity diagram, ditempatkan pada Use Case View. Klik kanan pada Use

Case View folder, pilih yang New / Activity diagram.

2. Atau juga bisa melalui, klik kanan pada Use Case, pilih yang Sub Diagram / New Activity diagram.

3. Untuk menambahkan Guard Condition. Double klik pada Transisi, pilih tab detail dan inputkan kondisinya.


LATIHAN MODUL 51. Buatlah Activity Diagram dari soal yang diberikan !


MODUL 6SEQUENCE & COLLABORATION DIAGRAM

Dua tipe diagram interaksi yang akan dibahas dalam modul ini, yaitu sequence diagram dan collboration diagram. Kedua diagram tersebut menunjukkan patisipasi obyek-obyek dalam aliran yang melalui use case dan pesan tersebut akan dikirim antar obyek-obyek. Dua tipe diagram interaksi yang dikenal dengan nama sequence diagram dan collaboration diagram. Sequence diagram disusun berdasarkan urutan waktu, sedangkan collaboration diagram diorganisasikan seputar obyek itu sendiri.

Langkah-langkah yang dilakukan untuk membuat sequence diagram dan collaboration diagram adalah :a) Menemukan obyek-obyek b) Menemukan aktor

a. Menemukan obyek-obyekSebuah cara untuk menemukan obyek adalah dengan memeriksa kata benda

dalam aliran kejadian. Cara lainnya adalah dengan melihat dokumen skenario. Kebanyakan use casememiliki sejumlah sequence diagram atau collaboration diagram, satu untuk masing-masing skenario pada aliran kejadian. Diagram ini dapat dibangun dengan abstraksi level tinggi,untuk menampilkan bagaimana sistem berkomunikasi, atau pada level tinggi, untuk menampilkan bagaimana sistem berkomunikasi, atau pada level yang sangat rinci, untukmenunjukkan kelas-kelas apa saja yang berpartisipasi salam skenario tertentu.

Tidak semua obyek didapatkan dari aliran kejadian. Form misalnya, mungkin tidaknampak dalam aliran kejadian, tapi akan nampak dalam diagram yang memungkinkan aktor dapat memsukkan atau menampilkan informasi ke/dari sistem. Obyek lain yang mungkin tidak nampak dalam aliran kejadian adalah obyek-obyek kontrol. Obyek-obyek dapat dikategorikan sebgai berikut : Obyek Entitas. Ini adalah obyek yang menangani informasi.. Mereka

mungkin memetakan beberapa tabel dan field ke dalam basis data. Beberapa kata dalam aliran kejadian akan menjadi obyek entitas.

Obyek Pembatas (Boundary). Obyek yang terletak dalam sebuah pembatas antara sistem dan lingkungannya.

Obyek kontrol. Obyek opitonal yang mengontrol aliran dalam use case. Mereka mengkoordinasikan obyek-obyek dan kontrol keseluruhan logika aliran.

b. Menemukan aktorSatu aktor dalam diagram interaksi adalah sebuah pemicu luar yang memulai

aliran kerja untuk aliran kejadian. Kita dapat mengidentifikasi sebuah aktor dengan melihat padaaliran kejadian dan menentukan siapa atau apa yang memulai proses.

Sequence DiagramSequence diagram adalah diagram interaksi yang disusun berdasarkan urutan waktu.

Kita membaca Sequence diagram dari atas ke bawah. Setiap use case memiliki sebuah aliran alternafit. Setiap sequence diagram mepresentasikan satu aliran dari beberapa aliran di dalam use case.

Kita dapat membaca diagram ini dengan memperhatikan obyek-obyek dan pesan-pesanyang ada di diagram. Obyek yang terlibat dalam aliran ditunjukkan dengan bujur sangkar yang ada diatas diagram.

Collaboration Diagram


Sebagaimana Sequence diagram, collaboration diagram digunakan untuk menampilkan aliran skenario tertentu dalam use case. Jika Sequence diagram disusun berdasarkan waktu, collaboration diagram lebih konsentrasi pada hubungan antara obyek-obyek.

Untuk alasan tertentu, kita dapat membuat Sequence diagram dan collaboration diagram untuk sebuah skenario. Maskipun mereka mempunyai maksud dan menampilkan informasi yang sama, masing-masing memberikan sedikit perbedaan dalam penampilannya. Dalam tool Rational Rose, kedua diagram ini dapat saling dibangkitkan.

Tutorial Sequence Diagram1. Klik kanan pada Package pilih New / Sequence Diagram

Tutorial Collaboration diagram1. Untuk membuat collaboration diagram dapat secara otomatis dibuat jika sudah ada

Sequence diagram-nya. Klik Browse pada Menu kemudian Create collaboration diagramatau dengan menekan tombol F5 dari keyboard.

LATIHAN MODUL 61. Buatlah Sequence Diagram dari soal yang diberikan !


MODUL 7CLASS DIAGRAM

Class diagram digunakan untuk menampilkan kelas-kelas dan paket-paket di dalam sistem. Class diagram memberikan gambaran sistem secara statis dan relasi anatar mereka. Biasanya, dibuat beberapa class diagram untuk sistem tunggal. Beberapa diagram akan menampilkan subset dari kelas-kelas dan relasinya. Dpaat dibuat beberapa diagram sesuai dengan yang diinginkan untuk mendapatkan gambaran lengkap terhadap sistem yang dibangun.

Class diagram adalah alat perancangan terbaik untuk tim pengembang. Diagram tersebut membantu pengembang mendapatkan struktur sistem sebelum kode ditulis, membantu untuk memastikan bahwa sistem adalah desain terbaik.

KelasKelas adalah sesuatu yang membungkus informasi dan perilaku. Secara

tradisional,sistem dibangun dengan ide dasar bahwa akan meyimpan informasi pada sisi basis data dan data perilaku pengolahnya pada sisi aplikasi. Salah satu perbedaan terstruktur dengan pendekatan berorientasi obyek adalah pada berorientasi obyek menggabungkan informasi dan perilaku pengolah informasi dan menyembunyikan semuanya ke dalam sesuatu yang disebut kelas. Dalam UML, kelas ditunjukkan menggunakan notasi sebagai berikut :

Gambar 7.1. Notasi Class

Bagian paling atas pada notasi Class digunakan sebagai nama kelas, dan secara opsional juga digunakan stereotype-nya. Bagian tengah digunakan untuk menyimpan atribut, dan bagian paling bawah digunakan menyimpan operasi.

Menemukan KelasCara yang baik untuk menemukan kelas-kelas adalah dimulai dari

memperhatikan aliran kejadian (flow of event) dari suatu use case. Perhatikan kata benda di dalam alirankejadian, mungkin merupakan salah satu dari empat hal berikut: Aktor Kelas Attribut dari kelas Ekspresi, bukan aktor, bukan kelas, dan bukan attribut.

Dengan melakukan seleksi kata benda dalam aliran kejadian, dapat ditemukan kelas- kelas dalam sistem. Alternatif lainnya, dapat diuji obyek-obyek dalam sequence diagram ataucollaboration diagram.

Ada dua cara yang biasa dilakukan berkaitan dengan urutan pendefinisian antar kelas-

kelas dalam class diagram dan sequence diagram atau collaboration diagram. Yang pertama, dengan membuat sequence diagram atau collaboration diagram lebih dulu kemudian melanjutkannya dengan membuat class diagram. Sebaliknya, yang kedua, yaitu dengan menemukan kelas-kelas dan membuat class diagram terlebih dulu, kemudian menggunakan kelas-kelas tersebut sebagai ”kamus” obyek-obyek dan relasinya untuk membuat sequence diagram atau collaboration diagram.


Stereotype pada KelasStereotype adalah sebuah mekanisme yang digunakan untuk mengkategorikan

kelas- kelas. Misalnya, dapat dibuat stereotype form lebih dulu, kemudian menentukan kelas-kelasdi langkah selanjutnya. Fitur ini membantu untuk lebih memahami tanggung jawab terhadap masing-masing kelas dalam model. Kelas-kelas dengan stereotype ’form’ bertanggung jawabmenampilkan informasi ke pemakai dan menerima informasi dari pemakai.

Stereotype juga membantu dalam proses pembangkkitan kode. Ketika prosespembangkitan kode, stereotype kelas menentukan tipe kelas yang akan dibawa ke bahasa pemrograman.

Beberapa stereotype dapat digunakan sejak pada tahap proses analisis, pada saat belum ditentukan bahasa pemrograman tertentu untuk membangkitkan kode. Stereotype juga bisatergantung pada bahasa pemrograman yang dipilih dan digunakan pada tahap proses desain.

Ketika analisis, kelas-kelas dapat dikategorikan menurut fungsi yang mereka lakukan.Ada 3 tipe stereotype kelas dalam UML yang digunakan pada analisis, yaitu : pembatas(boundary), entitas (entity), dan kontrol.a. Kelas-kelas pembatas

Kelas-kelas pembatas adalah kelas-kelas yang teletak di antara sistem dengan duniasekelilingnya. Semua form, laporan-laporan, antar muka (interfaces) ke perangkat lunak seperti printer atau scanner, dan antar muka (interfaces) ke sistem lainnya adalah termasuk dalam kategori ini. UML mepresentasikan kelas pembatas sebagai berikut :

BoundaryCl ass

Gambar 7.2. Notasi Kelas Pembatas

Untuk menemukan dan mengidentifikasi kelas-kelas pembatas dapat dilakukan dengan menguji diagram use case. Minimal harus ada satu kelas pembatas untuk setiap interaksi antara actor-use case. Kelas pembatas adalah apa saja yang memungkinkan aktor berinteraksi dengan sistem.

Tidak perlu membuat kelas pembatas untuk setiap pasangan actor-use case. Sebagai contoh, bila mempunyai dua aktor yang sama-sama menginisialisasi use case yang sama untuk berkomunikasi dengan sistem.

b. Kelas-kelas entitasKelas-kelas entitas menangai informasi yang disimpan dalam peyimpanan

tetap.Kelas entitas biasanya ditemukan dalam aliran kejadian (flow of event) pada diagram interaksi. Mereka adalah kelas-kelas yang sebagian besar bermakna terhadap pemakai dan secara tipikal diberikan nama menggunakan termonologi domain bisnisnya.

Perhatikan kata benda dalam aliran kejadian. Beberapa kata benda akan menjadi

kelas entitas dalam sistem. Cara lainnya adalah dengan memperhatikan struktur basis data. Jika rancangan basis data telah dibuat, perhatikan nama-nama tabel. Tabel-tabel menangani beberapa record informasi secara permanen, sementara kelas entitas, menangani informasi di dalam memori komputer saat komputer sedang dihidupkan. Dalam UML, notasi kelas entitas digambarkan sebagai berikut :


Ent ity Clas s

Gambar 7.3. Notasi Kelas Entitas

Dari rancangan basis data, dapat ditelusuri balik beberapa field pada basis data ke kebutuhan sistem. Kebutuhan sistem menentukan aliran kejadian (flow of event), dan aliran kejadian menentukan obyek-obyek, kelas-kelas, dan attribut-attribut dalam kelas. Masing-masing attribut dalam kelas entitas mungkin akan menjadi field dalam basis data.

c. Kelas-kelas KontrolKelas kontrol bertanggung jawab untuk mengkoordinasikan kegiatan-kegiatan

terhadap kelas lainnya. Kelas ini bersifat opsional, tetapi jika kelas kontrol ini digunakan, maka secara tipikal satu kelas kontrol untuk satu use case tersebut. Ada kelas-kelas kontrol yang digunakan bersama oleh beberapa use case. Dalam UML, notasi kelas entitas digambarkan sebagai berikut :

ControlCl ass

Gambar 7.4. Notasi Kelas Konrtol

Penamaan KelasMasing-masing kelas harus mempunyai nama yang unik. Sebagian besar

organisasimempunyai konvensi penamaan sendiri untuk menamakan kelas-kelas yang dibuatnya.Umumnya, kelas-kelas dinamakan menggunakan kata benda tunggal.

Nama kelas tidak menggunakan spasi, ini dilakukan karena alasan praktis, dimana beberapa bahasa pemrograman tidak membolehkan adanya spasi. Hal lainnya yang perludiperhatikan adalah bahwa nama kelas hendaknya pendek, cukup untuk menjelaskan apa yang akan kelas lakukan.

Jadi penamaan kelas sangat tergantung pada organisasi kita. Jika kita mempunyai kelas yang digunakan dalam organisasi yang bersangkutan, tetapi yang jelas bahwa hal tersebutharus konsisten digunakan untuk keseluruhan kelas-kelas yang dibuatnya.

Visibilitas KelasPilihan visibilitas menentukan dapat tidaknya sebuah kelas dilihat dari luar paket. Ada

3pilihan visibilitas untuk sebuah kelas yaitu : Public

Menyatakan bahwa sebuah kelas dapat dilihat dari kelas-kelas lainnya dalam sistem. Protected atau Private

Menyatakan bahwa sebuah kelas dapat dilihat dari kelas-kelas majemuk (nested), friends,atau dari kelas itu sendiri.

Package atau Implementation


Menyatakan bahwa sebuah kelas dapat dilihat hanya oleh kelas yang lain dalam paket yang sama.


Multiplicity KelasMultiplicity memberikan gambaran sejumlah instan yang akan ditampung dalam keas.

Misalnya, dalam kelas Pegawai, kita mungkin mempunyai beberapa instan, satu untuk Ani, satu untuk Ina, satu untuk Nana, dan seterusnya. Sehingga multiplicity untuk kelas Pegawai diset n. Pada kelas kontrol, multiplicity diset 1 , karena pada saat aplikasi berjalan hanya satu kelas.

Beberapa jenis multiplicity kelas :Tabel 7.1. Notasi multiplicity untuk kelas

Multiplicity Artin (default) Banyak

0..0 Nol0..1 Nol atau satu0..n Nol atau banyak1..1 Tepat satu1. . n Satu atau banyak

Atau dapat digunakan format tertentu sebagai berikut :

Tabel 7.2. Notasi multiplicity menggunakan kustomisasiFormat Arti

<Number> Tepat<Number1>.. <Number2> Antara

<Numbern> .. Atau Nol

<Number1> , <Number2><Number1> , <Number2> ..<Number3>

Tepat <Number1> atau antara <Number2>dan <Number3>

<Number1>.. <Number2> ,<Number3>.. <Number4>

Antara <Number1> dan <Number2> atauantara <Number1> dan <Number2>

PaketPaket digunakan untuk mengelompokkan kelas-kelas yang mempunyai kesamaan.

Dalam UML, digambarkan sebagai berikut :

Package

Gambar 7.5. Notasi Paket

Ada beberapa cara mengelompokkan kelas-kelas dalam paket, tetapi bagaimanapun juga, kelas-kelas dapat dikelompokkan dalam paket yang sama tergantung dari keinginan kita sendiri. Salah satu pendekatan yang dapat digunakan adalah berdasarkan stereotype-nya. Dengan pendekatan ini, dapat dibuat satu paket untuk kelas-kelas entitas, dan satu kelas untuk kelas-kelas kontrol.

Pendekatan lainnya yang dapat digunakan adalah dengan fungsionalitasnya. Misalnya,

kita punya paket Security untuk kelas-kelas yang digunakan menangani keamanan sistem.


Akhirnya, dapat digunakan kombinasi dua pendekatan di atas. Paket dapat dibuat bersarang, dimana satu paket mengandung beberapa paket lainnya. Pada level tertinggi, dapat dikelompokkan berdasarkan fungsionalitasnya, kemudian diikuti dengan sub fungsionalitas lainnya atau dengan stereotype-nya.

Tutorial Membuat Class Diagram1. Expand pada Logical View, double klik pada Main. Lalu tambahkan notasi Class pada

toolbar, lalu tuliskan nama Class-nya

2. Untuk menambahkan attribute, klik kanan pada Class, lalu pilih New Attribute

3. Untuk menambahkan attribute , bisa juga dengan membuka Specification, dengan cara klik kanan, Open Specification lalu pilih tab Attributes. Pada tab Attributes, klik kanan, lalu pilih insert.


4. Untuk menambahkan Operation atau method, bisa dilakukan seperti menambahkanAttribute.

5. Untuk menambahkan tipe data dari attribute, double klik pada attribute lalu akan munculwindows Class Attribute Specification.

6. Cara lain untuk memberi tipe data pada attribute. Double klik pada Type pada tabAttributes.


7. Pada operasi atau method, kita juga bisa menambahkan parameter file. BukaSpecification untuk Circle, pada tab Operations double klik pada Return Value.

LATIHAN MODUL 71. Buatlah Class Diagram dari soal yang diberikan !

Documents

Draft Modul Adsi-1