analisis dan desain sistem informasi filebidang akademik & pengembangan. politeknik telkom...

Analisis dan DesainSistem Informasi

POLITEKNIK TELKOMBANDUNG

2008

Politeknik Telkom Analisis dan Desain Sistem Informasi

ii

Penulis :M. Shalahuddin

Rosa A. S.

Editor :Dahliar Ananda

Dilarang menerbitkan kembali, menyebarluaskan atau menyimpan baiksebagian maupun seluruh isi buku dalam bentuk dan dengan cara apapuntanpa izin tertulis dari Politeknik Telkom.

Hak cipta dilindungi undang-undang @ Politeknik Telkom 2008

No part of this document may be copied, reproduced, printed, distributed,modified, removed and amended in any form by any means without prior writtenauthorization of Telkom Polytechnic.

Copyright @ 2008 Telkom Polytechnic. All rights reserved


iii

KATA PENGANTAR

Assalamu’alaikum Wr. Wb.

Segala puji bagi Allah SWT karena dengan karunia-Nya courseware ini dapatdiselesaikan.

Atas nama Politeknik Telkom, kami sangat menghargai dan inginmenyampaikan terima kasih kepada penulis, penerjemah dan penyuntingatas kontribusi yang telah diberikan sehingga courseware ini dapat tersusun.

Kami mendorong para pengajar & mahasiswa untuk memberikan masukanyang positif. Saran mereka akan menjadi bahan pertimbangan yang seriusdan banyak yang akan dimasukkan sebagai bahan perbaikan di edisiberikutnya. Kami akan sangat mengahargai apabila semua pihak dapatmenyampaikan pendapatnya melalui [email protected].

Semoga courseware ini dapat memberikan manfaat bagi seluruh CivitasAkademika Politeknik Telkom dalam memahami materi perkuliahan diPoliteknik Telkom.Amin.

Wassalamu’alaikum Wr. Wb.

Bandung, Desember 2008

Christanto TriwibisonoWakil Direktur IBidang Akademik & Pengembangan


iv

Daftar Isi

Kata Pengantar ................................................Error! Bookmark not defined.Daftar Isi ........................................................................................................................ iv1 Pendahuluan.................................................................................................... 1-1

1.1 Perkembangan Sistem Informasi..................................................... 1-21.2 Pengembangan Sistem Informasi .................................................... 1-41.3 Tim Pengembangan Sistem Informasi ............................................ 1-51.4 Penjadwalan Proyek........................................................................... 1-6

2 Perencanaan Sistem ...................................................................................... 2-12.1 Definisi Perencanaan Sistem............................................................ 2-22.2 Pendefinisian Proyek.......................................................................... 2-22.3 Pemodelan Proyek ............................................................................. 2-32.4 Perkiraan dan Penjadwalan Proyek................................................ 2-42.5 Penyeimbangkan Rencana ................................................................ 2-62.6 Persetujuan Rencana ......................................................................... 2-6

3 Analisis Sistem................................................................................................ 3-13.1 Definisi Analisis Sistem ..................................................................... 3-13.2 Teknik Pengumpulan Data ............................................................... 3-2

3.1.1 Teknik Wawancara................................................................. 3-33.1.2 Teknik Observasi .................................................................... 3-43.1.3 Teknik Kuisioner ..................................................................... 3-4

3.3 Jenis Kebutuhan .................................................................................. 3-54 Desain Sistem................................................................................................. 4-1

4.1 Definisi Desain Sistem....................................................................... 4-24.2 Konsep Dasar Pendekatan Berorientasi Objek.......................... 4-24.3 Metodologi Berorientasi Objek...................................................... 4-34.4 Pengertian Objek dan Kelas ............................................................ 4-54.5 Enkapsulasi ........................................................................................... 4-64.6 Atribut................................................................................................... 4-64.7 Operasi atau Metode (Method) ..................................................... 4-74.8 Pengertian Package ............................................................................ 4-74.9 Pengertian Antarmuka (Interface).................................................. 4-84.10 Sekilas Pendekatan terstruktur....................................................... 4-84.11 Perbandingan Pendekatan OO dan Terstruktur ......................4-10

5 Pemodelan dan UML .................................................................................... 5-15.1 Kompleksitas Pengembangan Perangkat Lunak .......................... 5-25.2 Pemodelan............................................................................................ 5-3


v

5.3 Unified Modeling Language (UML)................................................. 5-45.3.1 Pengenalan UML...................................................................... 5-45.3.2 Sejarah Singkat UML............................................................... 5-55.3.3 View dan Diagram UML ........................................................ 5-75.3.4 Langkah-langkah pembuatan UML ...................................... 5-9

6 Use case ............................................................................................................ 6-16.1 Pengertian Use case........................................................................... 6-26.2 Simbol-simbol pada Use case .......................................................... 6-26.3 Studi Kasus........................................................................................... 6-5

6.3.1 Definisi Aktor........................................................................... 6-66.3.2 Definisi Use case ...................................................................... 6-7

6.4 Skenario ................................................................................................ 6-96.5 Diagram Use case.............................................................................6-20

7 Desain Basis Data.......................................................................................... 7-17.1 Pengertian Basis Data........................................................................ 7-27.2 Database Life Cycle ........................................................................... 7-27.3 Entity Relationship Diagram (ERD) ............................................... 7-37.4 Studi kasus ERD.................................................................................. 7-4

7.4.1 Definisi Entitas dan atribut.................................................... 7-47.4.2 Definisi Relasi ........................................................................... 7-67.4.3 Diagram ER............................................................................... 7-7

7.5 Conceptual Data Model (CDM)..................................................... 7-77.6 Studi kasus CDM................................................................................ 7-87.7 Physical Data Model (PDM)...........................................................7-107.8 Studi Kasus PDM..............................................................................7-11

8 Diagram Kelas dan Diagram Objek .......................................................... 8-18.1 Pengertian Diagram Kelas ................................................................ 8-28.2 Pendefinisian Kelas pada Diagram Kelas....................................... 8-38.3 Studi Kasus Diagram Kelas .............................................................. 8-48.4 Pengertian Diagram Objek .............................................................. 8-78.5 Studi Kasus Diagram Objek............................................................. 8-8

9 Diagram Interaksi .......................................................................................... 9-19.1 Pengertian Diagram Interaksi .......................................................... 9-29.2 Pengertian Diagram Sekuen............................................................. 9-29.3 Studi Kasus Diagram Sekuen........................................................... 9-49.4 Pengertian Diagram Kolaborasi ....................................................9-149.5 Studi Kasus Diagram Kolaborasi ..................................................9-15

10 Diagram Status .......................................................................................10-110.1 Pengertian Diagram Status.............................................................10-210.2 Studi Kasus Diagram Status ...........................................................10-3


vi

11 Diagram Aktivitas ..................................................................................11-111.1 Pengertian Diagram Aktivitas ........................................................11-211.2 Studi Kasus Diagram Aktivitas ......................................................11-4

12 Diagram Komponen..............................................................................12-112.1 Pengertian Diagram Komponen ...................................................12-212.2 Studi Kasus Diagram Komponen .................................................12-4

13 Diagram Deployment..............................................................................13-113.1 Pengertian Diagram Deployment.................................................13-213.2 Studi Kasus Diagram Deployment ...............................................13-3

Daftar Pustaka ............................................................................................................... v


Pendahuluan 1-1

1 Pendahuluan

Overview

Bab ini merupakan pendahuluan sebelum menjelaskan inti materi buku initerkait dengan analisis dan desain sistem informasi. Bab ini berisi mengenaisejarah perkembangan sistem informasi, tahapan pengembangan sisteminformasi, siapa saja yang terlibat dalam pengembangan sistem informasi,serta penjadwalan pengembangan sistem informasi.

Tujuan

1. Mahasiswa mengetahui sejarah perkembangan sistem informasi2. Mahasiswa mempunyai gambaran umum mengenai tahap-tahap yang

biasanya dilalui dalam pengembangan sistem informasi.3. Mahasiswa telah mempunyai gambaran umum mengenai analisis dan

desain sistem informasi.


1-2

1.1 Perkembangan Sistem Informasi

Ilustrasi mengenai sebuah sistem dapat dilihat pada gambar di bawah.Sebuah sistem menerima masukan, memprosesnya, dan kemudianmenghasilkan suatu keluaran. Sistem tersebut mampu bekerja karenakomponen-komponen di dalamnya saling berinteraksi untuk menghasilkankeluaran. Dalam melakukan prosesnya, kinerja sistem sangat dipengaruhioleh kondisi lingkungan di sekitarnya.

Gambar 1 Ilustrasi Sistem

Sistem informasi adalah suatu kumpulan dari komponen-komponen yangsaling berinteraksi untuk mengelola informasi pada suatu organisasi untukmendukung kegiatan bisnis organisasi.

Pada awalnya sistem informasi tidak harus dikaitkan dengan teknologiinformasi, namun seiring perkembangan jaman, saat ini suatu sisteminformasi tidak dapat lepas dari penggunaan teknologi informasi.

Penggunaan teknologi informasi pada suatu sistem informasi mulaiberkembang sekitar tahun 1960an. Pada periode tersebut, sistem informasiyang digunakan masih sangat terbatas. Hal ini disebabkan teknologiperangkat keras maupun perangkat lunak masih sangat jauh jikadibandingkan dengan kondisi sekarang. Tujuan utama sistem informasi padasaat itu adalah untuk melakukan otomatisasi proses bisnis yang berjalanpada organisasi.


Pendahuluan 1-3

Pada periode sekitar tahun 1970an, sistem informasi sudah lebihberkembang. Perkembangan sistem informasi saat itu didominasi dari sudutpandang data. Teknologi basis data saat itu berkembang cukup pesat. Jadi,fokus utama sistem informasi saat itu adalah penyimpanan dan pengaksesandata. Pada saat itu sistem informasi biasanya masih digunakan pada suatubagian organisasi, khususnya bagian keuangan. Oleh karena itu, kitasekarang sering kali melihat pada suatu organisasi, departemen / bagiansistem informasi (kadang juga disebut bagian teknologi informasi) berada dibawah departemen keuangan.

Pada periode tahun 1980an, sistem informasi berkembang lebih ke arahCSCW (Computer Support Cooperative Work). CSCW adalah aplikasi yangmendukung kerjasama dalam organisasi, misalnya pemanfaatan email,dokumen editor, dan lain-lain. Pada periode ini, sistem informasi mulaimengarah ke bentuk client server. Selain itu, pada periode ini pemanfaatansistem informasi sudah mulai bertambah luas. Sistem informasi sudahdimanfaatkan pada bermacam-macam bagian organisasi, misalnya bagiankeuangan, sumber daya manusia, pemasaran, dan lain-lain.

Pada tahun 1990an, internet berkembang sangat cepat. Perkembangantersebut juga mendorong perkembangan sistem informasi. Sistem informasimulai dimanfaatkan teknologi internet maupun teknologi web. Pada saat ituusaha untuk membuat suatu sistem informasi yang terintegrasi untukseluruh organisasi sudah mulai dilakukan. Perusahaan-perusahaan perangkatlunak besar di dunia juga mulai mengembangkan sistem informasi yangdisesuaikan dengan best practice yang ada, misalnya aplikasi ERP (EnterpriseResource Planning), CRM (Customer Relationship Management), SCM (SupplyChain Management), dan lain-lain.

Pada tahun 2000an, sistem informasi berkembang semakin pesat.Perkembangan ini didorong dengan semakin berkembangan teknologiinternet, dengan kapasitas semakin besar dan harga yang semakin murah.Sudah banyak organisasi yang telah mengintegrasikan sistem informasimereka dengan sistem informasi organisasi lain untuk mendukung kegiatanorganisasi tersebut.

Pada masa mendatang, sistem informasi akan semakin berkembang lagi.Perkembangan teknologi dan perubahan dunia usaha yang sangat cepat,mendorong organisasi untuk mengembangkan suatu sistem informasi yangmampu beradaptasi dengan cepat menghadapi perubahan tersebut. Sistem


1-4

informasi tersebut juga harus dapat diintegrasikan dengan bermacam-macam sistem yang lain agar kinerja organisasi menjadi lebih efisien.

1.2 Pengembangan Sistem Informasi

Pengembangan sistem informasi adalah analisis, desain, dan implementasisistem informasi untuk mendukung kegiatan bisnis organisasi.Pengembangan sistem informasi dapat berupa pembuatan suatu sistem barumaupun penambahan atau perubahan modul pada sistem yang sudah ada.Secara umum, alur pengembangan suatu sistem informasi mempunyaibeberapa tahapan. Tahapan pengembangan sistem informasi sering kalidisebut juga sebagai System Development Life Cycle (SDLC). Tahap-tahappengembangan sistem informasi adalah sebagai berikut.

Feasibility yaitu kegiatan perencanaan proyek. Kegiatan ini antaralain berisi mengenai analisis resiko untuk memperhitungkanapakah proyek pengembangan sistem informasi layak untukdikerjakan atau tidak. Analisis tersebut biasanya terkait dengananalisis terhadap waktu, biaya, teknologi, dan ketersediaan sumberdaya yang dimiliki. Penjelasan lebih lanjut mengenai feasibility dapatdilihat pada Bab 2 Perencanaan Sistem.

Analysis yaitu analisis sistem yang akan dikembangkan. Penjelasanlebih lanjut dapat dilihat pada Bab 3 Analisis BeriorientasiObjek.

Design yaitu pembuatan rancangan sistem. Penjelasan lebih lanjutdapat dilihat pada Bab 4 Perancangan Berorientasi Objek.

Development yaitu pengembangan sistem. Quality Assurance yaitu pengujian terhadap sistem yang telah

dikembangkan untuk meminimalisir kesalahan. Pengujian tersebutbisa dilakukan secara otomatis dengan menggunakan tools maupunsecara manual. Berikut ini adalah beberapa tahapan pengujian yangpaling umum dilakukan.

o Unit Test. Pengujian ini dilakukan untuk suatu unit / bagian/ modul pada sistem informasi. Pengujian ini digunakanuntuk menentukan apakah modul tersebut sudah berjalanbaik atau tidak.

o System Test. Pengujian ini dilakukan setelah sisteminformasi selesai dibuat dan setiap modul-modulnya telahdiintegrasikan. Pengujian ini dilakukan untuk menentukan


Pendahuluan 1-5

apakah sistem informasi tersebut sudah dapat berjalandengan baik dengan resiko kesalahan seminimal mungkin.

o User Acceptance Test. Pengujian ini dilakukan oleh useryang membeli sistem aplikasi sebelum sistem informasitersebut diterima oleh user.

Implementation yaitu penerapan sistem informasi yang telahdikembangkan. Tahap implementation sering juga disebut tahapmaintenance. Hal ini disebabkan pada saat sistem informasi telahditerapkan maka kegiatan perawatan perangkat lunak jugadilakukan secara bersama-sama.

Dalam pengembangan sistem informasi, ada 2 hal utama yang harusdiperhatikan.

Produk. Produk adalah produk yang harus dihasilkan pada setiaptahap pengembangan sistem informasi. Kesalahan dalampembuatan produk dalam setiap tahap akan menyebabkankesalahan yang semakin besar pada produk akhir.

Proses. Proses adalah proses pengembangan sistem informasi.Proses ini meliputi tahapan pengembangan mulai dari tahapfeasibility sampai implementation. Jika proses tersebut tidakdilaksanakan sesuai dengan jadwal maka kemungkinan kegagalanproyek menjadi semakin besar.

1.3 Tim Pengembangan Sistem Informasi

Suatu proyek pengembangan sistem informasi biasanya dikembangkan olehsebuah tim. Tim tersebut biasanya terdiri dari beberapa posisi sebagaiberikut.

Project Leader yaitu penanggung jawab utama proyekpengembangan sistem informasi. Seorang project leader harusmampu mengatur waktu dan sumber daya agar sistem informasidapat diselesaikan sesuai dengan target yang telah ditetapkan.Dalam sebuah proyek pengembangan sistem informasi, seorangproject leader sebaiknya tidak merangkap jabatan lain untukmenghindari adanya konflik kepentingan.

System Analyst yaitu orang yang bertugas untuk melakukan analisisterhadap kebutuhan user dan kemudian mendokumentasikankebutuhan user tersebut dalam suatu dokumen teknis yang mudah


1-6

dipahami oleh anggota tim pengembangan sistem informasi.Seorang system analyst yang baik sebaiknya mempunyaipengetahuan dibidang sistem informasi dan pengembanganperangkat lunak sehingga dia mampu merepresentasikankebutuhan user dengan baik dalam suatu dokumen. Selain itu,system analyst juga dituntut untuk mempunyai pengetahuan umumyang luas agar mempermudah dalam memahami kebutuhan user.

System Designer yaitu orang yang bertugas untuk mendesain sistemberdasarkan dokumen kebutuhan user.

Programmer yaitu orang yang bertugas untukmengimplementasikan desain tersebut menjadi kode program.

Software Quality Assurance (SQA) yaitu orang yang bertugas untukmemastikan semua proses pengembangan sistem informasiberjalan dengan baik dan memastikan produk yang dihasilkansesuai yang diharapkan.

1.4 Penjadwalan Proyek

Dalam pengembangan sistem informasi, penjadwalan proses merupakan halyang harus diperhatikan dengan serius. Jika sejak awal kita telah gagal dalammembuat jadwal yang baik, maka dapat dipastikan proyek tersebut akankacau sehingga mengakibatkan molornya waktu proyek danmembengkaknya biaya.

Ketika dilihat sekilas, penjadwalan seperti Gambar 2 di bawah terlihatcukup baik. Tetapi jika diperhatikan lebih lanjut, Gambar 2 menunjukkansebuah penjadwalan yang tidak realistis. Gambar 3 menunjukkanpenjadwalan yang lebih realistis. Berikut ini adalah beberapa penyebabGambar 2 tidak realistis.

Kegiatan feasibility hanya dilakukan pada saat awal proyek dankegiatan analysis belum dikerjakan sama sekali. Feasibility sebaiknyadilakukan kembali setelah melakukan analysis agar analisis resikomenjadi lebih akurat.

Hasil design khususnya desain antarmuka dan desain interaksisebaiknya diajukan ke user karena tidak mungkin hanya dengansatu kali proses analisis, tanpa memberikan prototype, akanmenghasilkan sesuai dengan keinginan user.


Pendahuluan 1-7

Setelah proses quality assurance tidak ada lagi proses development.Hal ini tidak mungkin karena setiap aplikasi pasti terdapatkesalahan-kesalahan yang harus diperbaiki. Dan tujuan kegiatanquality assurance adalah menemukan kesalahan-kesalahan tersebutuntuk kemudian diperbaiki sebelum masuk ke tahapimplementation.

Aktivitas Maret April Mei Juni Juli AgustusFeasibilityAnalysisDesignDevelopmentQuality AssuranceImplementationGambar 2 Penjadwalan Tidak Realistis

Aktivitas Maret April Mei Juni Juli AgustusFeasibilityAnalysisDesignDevelopmentQuality AssuranceImplementationGambar 3 Penjadwalan Realistis


1-8

Latihan

1. Basic (Pertanyaan yang jawabannya ada pada isi buku ini)a. Apakah definisi sistem, sistem informasi, dan teknologi

informasi?b. Apa perbedaan sistem informasi dan teknologi informasi?

Gambarkan keterhubungan antara sistem informasi danteknologi informasi!

c. Jelaskan mengenai sejarah perkembangan sisteminformasi!

d. Sebutkan faktor-faktor yang mempengaruhiperkembangan sistem informasi!

e. Sebutkan tahap-tahap pengembangan sistem informasi!2. Advanced (Pertanyaan terkait bab ini yang jawabannya harus dicari

di luar buku ini)a. Apakah yang dimaksud dengan ERP, CRM, dan SCM?

Jelaskan dan berikan contohnya!b. Faktor apa saja yang mempengaruhi penjadwalan proyek

pengembangan sistem informasi?


Perencanaan Sistem 2-1

2 Perencanaan Sistem

Overview

Perencanaan sistem merupakan tahap paling awal sebelum melakukanpengembangan sistem informasi. Tahap ini digunakan untuk menentukanapakah pengembangan sistem informasi akan dilakukan atau tidak. Pada babini dijabarkan mengenai urutan kegiatan yang dilakukan pada saatperencanaan sistem.

Tujuan

1. Mahasiswa mempunyai gambaran mengenai hal-hal yang biasanyadilakukan sebelum melakukan pengembangan sistem informasi.

2. Mahasiswa mampu melakukan perencanaan sistem khususnya sistem-sistem yang sederhana.

3. Mahasiswa mampu membuat dokumentasi perencanaan sistem.


2-2

2.1 Definisi Perencanaan Sistem

Perencanaan sistem atau feasibility adalah tahap pertama yang harusdilakukan sebelum mulai melakukan pengembangan sistem informasi. Adabeberapa hal yang sebaiknya dilakukan pada tahap ini, antara lain sebagaiberikut.

Mendefinisikan proyek Memodelkan proyek Membuat perkiraan anggaran dan penjadwalan proyek Menyeimbangkan rencana proyek Menyetujui rencana proyek

2.2 Pendefinisian Proyek

Sebelum pelaksanaan proyek pengembangan sistem informasi dimulai, makaproyek tersebut harus mendapatkan persetujuan dari pengambil keputusan.Pengambil keputusan pada suatu organisasi, biasanya adalah manajementingkat atas (executive). Namun, kadang-kadang manajemen akan memintapendapat bawahannya, manajer level menengah (middle manager) maupuncalon pengguna aplikasi (functional user), dalam melakukan pengambilankeputusan pelaksanaan proyek.

Oleh karena itu, dalam melakukan pendefinisian proyek, anda harusmemahami karakteristik kebutuhan para pengambil keputusan. Berikut iniadalah karakteristik umum mengenai orang-orang yang terlibat pengambilankeputusan tersebut.

Executive (manajemen tingkat atas)Prioritas utama executive adalah ROI (Return On Invesment). Jadiagar proyek dapat disetujui, maka anda harus mampu meyakinkanmereka bahwa proyek tersebut dapat meningkatkan ROI.

Middle manager (manajer level menengah)Prioritas utama middle manager biasanya adalah bagaimanameningkatkan produktivitas kerja. Jadi sistem informasi yang akandikembangkan tersebut harus mampu menunjukkan seberapabesar produktivitas kerja akan meningkat dengan adanya sistembaru tersebut.



Functional user (pengguna aplikasi langsung)Kebutuhan utama functional user adalah suatu aplikasi yang akanmempermudah pekerjaan mereka. Jadi jika functional user dilibatkandalam pengambilan keputusan, maka anda harus mampumenunjukkan kemudahan-kemudahan apa yang akan diperolehfunctional user dengan adanya sistem informasi yang akandikembangkan tersebut.

Pada tahap ini, dokumen yang dihasilkan adalah dokumen proposal proyek.Sebuah dokumen proposal proyek tersebut minimal terdiri dari hal-halsebagai berikut.

Keuntungan yang akan diperoleh calon pengguna dengan adanyasistem informasi yang akan dikembangkan tersebut. Andasebaiknya mengetahui siapa yang mengambil keputusan pengadaansistem baru dan tunjukkan kelebihan sistem baru tersebut sesuaidengan karakteristik kebutuhannya.

Rencana biaya yang dibutuhkan untuk pengembangan, jika andamenjual sistem informasi tersebut ke pihak lain, berarti rencanabiaya pengembangan di sini diganti dengan harga sistem informasiyang anda jual.

Waktu yang dibutuhkan untuk pengembangan sistem.

2.3 Pemodelan Proyek

Pemodelan proyek mempunyai fokus pada pembuatan simulasi mengenaiusaha yang dibutuhkan untuk mencapai tujuan proyek. Pemodelan inimenghasilkan sebuah WBS (Work Breakdown Structure) yang digunakanuntuk menentukan semua usaha yang dibutuhkan untuk menyelesaikanproyek dengan sukses. WBS adalah daftar semua pekerjaan yang harusdilakukan untuk menghasilkan produk yang diinginkan.

Dalam sebuah proyek, ada banyak pekerjaan yang harus dilakukan. Sebuahpekerjaan yang kompleks, sebaiknya dipecah lagi menjadi beberapa sub-pekerjaan. Dan beberapa pekerjaan yang terlalu kecil dan detail sebaiknyadigabungkan menjadi sebuah pekerjaan. Dalam menentukan pekerjaan apasaja yang harus dilakukan dalam sebuah proyek, agar tidak ada yang terlalukompleks maupun terlalu detail, sangat tergantung dari pengalamanseseorang dan besar atau kecilnya proyek.


2-4

Pembuatan WBS membutuhkan kontribusi dari anggota tim yang akanterlibat dalam proyek tersebut. Sebuah metode yang efektif dalampembuatan WBS adalah membuat sebuah sesi diskusi yang melibatkansemua anggota tim dan memberikan kesempatan bagi mereka untukmemberikan ide-ide yang mereka miliki.

Setelah WBS selesai dibuat, tim tersebut kemudian harus menggambarkanketerhubungan antara setiap tugas pekerjaan, menentukan tugas apa yangharus sudah selesai sebelum tugas lain dilakukan. Keterhubungan antarpekerjaan ini nanti dibutuhkan dalam melakukan proses penjadwalan.

2.4 Perkiraan dan Penjadwalan Proyek

Perkiraan dan penjadwalan proyek ini fokus kepada penentuan waktu, biaya,dan sumber daya yang dibutuhkan dalam pelaksanaan proyek. Kebanyakanorang yang melakukan estimasi, biasanya mulai melakukan estimasi dengancara menentukan seberapa besar man-hours atau man-days yang dibutuhkanuntuk menyelesaikan pekerjaan. Angka ini nanti juga dibutuhkan dalammenentukan waktu dan biaya yang dibutuhkan. Berikut ini adalah tujuhtahapan proses estimasi.

Langkah 1: Membuat estimasi pekerjaanEstimasi pekerjaan seharusnya melibatkan anggota tim yangmenjalankan pekerjaan tersebut. Sehingga estimasi tersebut akanrealistis dan anggota tim akan punya komitmen dan termotivasiuntuk mencapai estimasi tersebut. Estimasi ini kemudian dapatdimodifikasi untuk menyesuaikan dengan jadwal dan sumber dayayang ada.

Langkah 2: Membuat perencanaan awalPerencanaan awal proyek berisi sebuah jadwal yang dibuatberdasarkan ketergantungan antar pekerjaan (task) dan estimasipekerjaan tersebut. Jadwal tersebut berisi kapan pekerjaandimulai, berapa lama, dan kapan pekerjaan tersebut harus sudahselesai. Biaya dapat dihitung dari pekerjaan apa saja yang harusdilakukan dan biaya untuk pembelian barang.

Langkah 3: Membandingkan perencanaan awal dengan tujuanTahap selanjutnya adalah pembandingkan antara tujuan awalproyek dengan estimasi rencana jadwal dan biaya yang sudah



dilakukan. Tujuan awal proyek biasanya merupakan hal yangkonstan dan telah disetujui oleh executive. Negosiasi ini tidakdiperlukan jika tujuan awal telah sesuai dengan rencana jadwal danbiaya yang dilakukan. Tetapi jika tidak sesuai, maka langkah 4, 5, 6harus dilakukan.

Langkah 4 : Negosiasi perubahan untuk estimasiAnda melakukan perubahan estimasi mengenai rencana waktu dananggaran agar sesuai dengan tujuan awal. Langkah ini mengandungsangat besar apabila anda melakukannya tanpa persetujuan anggotatim yang lain, maka anda akan kehilangan komitmen dan motivasianggota tim. Anggota tim akan beranggapan jadwal dananggarannya tidak realistis, sehingga kemungkinan proyek gagalmenjadi sangat besar.

Langkah 5 : Negosiasi perubahan untuk tujuan proyekLangkah ini adalah melakukan negosiasi dengan executive karenadengan perubahan estimasi yang telah anda lakukan, rencana awaltersebut tidak realistis. Perubahan rencana tersebut dapat berupapenambahan waktu dan anggaran maupun pengurangankompleksitas sistem. Usahakan agar sebisa mungkin rencana yanganda lakukan telah disetujui oleh anda, anggota tim anda, danexecutive.

Langkah 6 : Membuat keputusan terus / berhentiSetelah melakukan langkah 4 dan 5, anda harus mengambilkeputusan apakah akan meneruskan proyek tersebut maupuntidak.

Langkah 7 : Mempersiapkan jadwal dan anggaranRencana awal pengembangan sistem informasi telah siap. Rencanaini terdiri dari tiga hal, yaitu jadwal kegiatan (waktu mulai, durasi,dan waktu selesai), alokasi sumber daya manusia terhadapkegiatan, dan rencana anggaran.


2-6

2.5 Penyeimbangkan Rencana

Setelah rencana anggaran dan jadwal selesai dibuat, hal yang harus dilakukanselanjutnya adalah menyeimbangkan rencana proyek tersebut dengankondisi organisasi. Biasanya sebuah organisasi akan menjalankan beberapaproyek. Dan dalam organisasi tersebut uang dan sumber daya manusiamerupakan hal yang terbatas. Jadi hal yang harus dilakukan adalah mengaturjadwal dan anggaran agar semua proyek yang sedang dikerjakan dapatberjalan dengan baik.

Ada bermacam-macam perangkat lunak yang dapat digunakan untukmembantu mengelola sumber daya tersebut. Dengan pengelolaan yang baik,maka sumber daya uang dan manusia dapat tersedia pada saat dibutuhkan.

2.6 Persetujuan Rencana

Pada tahap ini, dokumen terkait rencana target (target tanggal selesai,target biaya, target rencana penggunaan sumber daya). Dokumen inimerupakan dokumen persetujuan antara project leader, executive, dan clientyang akan digunakan sebagai acuan jika selama proyek berlangsung terjadiperubahan ruang lingkup proyek dan juga digunakan sebagai acuanmengukur performa tim.



Latihan

1. Basica. Apa akibatnya jika pengembangan sistem informasi tidak

melalui tahap perencanaan sistem?b. Sebutkan langkah-langkah perencanaan sistem!c. Apakah yang dimaksud dengan WBS?

2. Advanceda. Apakah yang dimaksud dengan ROI (Return On Investment)

dan mengapa banyak executive sangat memperhatikanROI?

b. Buatlah sebuah proposal proyek pengembangan sisteminformasi sebuah apotek!

c. Buatlah WBS untuk proyek pengembangan sisteminformasi sebuah apotek!


Desain Sistem 3-1

3 Analisis Sistem

Overview

Bab ini menjelaskan mengenai kegiatan analisis sistem. Batasan mengenaihal-hal apa saja yang dilakukan pada tahap analisis berbeda-beda tergantungliteratur yang digunakan. Pada bab ini yang dimaksud analisis sistem adalahmendefinisikan kebutuhan terkait sistem yang akan dikembangkan. Jadi hasilakhir dari tahap analisis di sini adalah sebuah dokumen yang menjelaskanmengenai spesifikasi kebutuhan sistem informasi atau SRS (SoftwareRequirement Specification)

Tujuan

1. Mahasiswa memahami mengenai kegiatan apa saja yang dilakukanselama tahap analisis sistem

2. Mahasiswa mengetahui teknik apa saja yang digunakan untuk melakukananalisis sistem

3. Mahasiswa mampu melakukan analisis sistem menggunakan teknik yangberbeda-beda

4. Mahasiswa mampu membuat sebuah dokumen spesifikasi kebutuhansistem informasi dengan baik.


3-2

3.1 Definisi Analisis Sistem

Kegiatan analisis sistem adalah kegiatan untuk melihat sistem yang sudahberjalan, melihat bagian mana yang bagus dan tidak bagus, dan kemudianmendokumentasikan kebutuhan yang akan dipenuhi dalam sistem yang baru.Hal tersebut terlihat sederhana, namun sebenarnya tidak. Banyak hambatanyang akan ditemui dalam proses tersebut.

Pada banyak proyek sistem informasi, proses analisis dan desain sering kaliberjalan bersama-sama. Jadi selama kegiatan analisis, kegiatan desain jugadilakukan. Hal ini dilakukan karena pada banyak kasus, user sering kesulitanuntuk mendefinisikan kebutuhan mereka. Jadi mereka akan lebih mudahmendefinisikan kebutuhan, jika mereka telah melihat gambar rancangansistem yang baru, khususnya rancangan antarmuka.

Oleh karena itu, sering kali batasan mengenai bagian mana yang dianggapsebagai analisis dan bagian mana yang dianggap sebagai desain banyak terjadiperbedaan. Misalnya ada yang mengatakan bahwa use case, analysis class, dansequence diagram merupakan bagian dari analisis. Namun ada juga pihak lainyang menyatakan bahwa use case dan sequence diagram merupakan bagiandari desain, dan analysis class tidak ada karena sudah ada design class.

Pada buku ini yang dibahas pada bagian analisis adalah bagaimana metodepengumpulan data dan bagaimana mendokumentasikannya. Sedangkan usecase, class diagram, dan sequence diagram dianggap merupakan bagian daridesain sistem dan akan dibahas pada bab yang terkait dengan UML.

3.2 Teknik Pengumpulan Data

Hal pertama yang dilakukan dalam analisis sistem adalah melakukanpengumpulan data. Ada beberapa teknik pengumpulan data yang seringdilakukan yaitu sebagai berikut.

Teknik Wawancara Teknik Observasi Teknik Kuisioner


Desain Sistem 3-3

3.1.1 Teknik Wawancara

Pengumpulan data dengan menggunakan wawancara mempunyai beberapakeuntungan sebagai berikut.

Lebih mudah dalam menggali bagian sistem mana yang dianggapbaik dan bagian mana yang dianggap kurang baik

Jika ada bagian tertentu yang menurut anda perlu untuk digalilebih dalam, anda dapat langsung menanyakan kepada narasumber

Dapat menggali kebutuhan user secara lebih bebas User dapat mengungkapkan kebutuhannya secara lebih bebas.

Selain mempunyai beberapa kelebihan tersebut, teknik wawancara jugamempunyai beberapa kelemahan. Berikut ini adalah beberapa kelemahandari teknik wawancara.

Wawancara akan sulit dilakukan jika narasumber kurang dapatmengungkapkan kebutuhannya

Pertanyaan dapat menjadi tidak terarah, terlalu fokus pada hal-haltertentu dan mengabaikan bagian lainnya

Berikut ini adalah beberapa panduan dalam melakukan kegiatan wawancaraagar memperoleh data yang diharapkan.

Buatlah jadwal wawancara dengan narasumber dan beritahukanmaksud dan tujuan wawancara

Buatlah panduan wawancara yang akan anda jadikan arahan agarpertanyaan dapat fokus kepada hal-hal yang dibutuhkan

Gunakan pertanyaan yang jelas dan mudah dipahami Cobalah untuk menggali mengenai kelebihan dan kekurangan

sistem yang telah berjalan sebelumnya Anda boleh berimprovisasi dengan mencoba menggali bagian-

bagian tertentu yang menurut anda penting Catat hasil wawancara tersebut


3-4

3.1.2 Teknik Observasi

Pengumpulan data dengan menggunakan observasi mempunyai keuntunganyaitu

Analis dapat melihat langsung bagaimana sistem lama berjalan Mampu menghasilkan gambaran lebih baik jika dibanding dengan

teknik lainnya

Sedangkan kelemahan dengan menggunakan teknik observasi adalah Membutuhkan waktu cukup lama karena jika observasi waktunya

sangat terbatas maka gambaran sistem secara keseluruhan akansulit untuk diperoleh

Orang-orang yang sedang diamati biasanya perilakunya akanberbeda dengan perilaku sehari-hari (cenderung berusaha terlihatbaik). Hal ini akan menyebabkan gambaran yang diperoleh selamaobservasi akan berbeda dengan perilaku sehari-hari

Dapat mengganggu pekerjaan orang-orang pada bagian yangsedang diamati

Berikut ini adalah beberapa petunjuk untuk melakukan observasi Tentukan hal-hal apa saja yang akan diobservasi agar kegiatan

observasi menghasilkan sesuai dengan yang diharapkan Mintalah ijin kepada orang yang berwenang pada bagian yang akan

diobservasi Berusaha sesedikit mungkin agar tidak menganggu pekerjaan

orang lain Jika ada yang anda tidak mengerti, cobalah bertanya. Jangan

membuat asumsi sendiri

3.1.3 Teknik Kuisioner

Pengumpulan data dengan menggunakan kuisioner mempunyai keuntunganyaitu

Hasilnya lebih objektif, karena kuisioner dapat dilakukan kepadabanyak orang sekaligus

Waktunya lebih singkat


Desain Sistem 3-5

Sedangkan kelemahan pengumpulan data dengan menggunakan kuisioneradalah sebagai berikut

Responden cenderung malas untuk mengisi kuisioner Sulit untuk membuat pertanyaan yang singkat, jelas, dan mudah

dipahami

Berikut ini adalah beberapa cara yang dapat dilakukan untuk membuatteknik kuisioner menghasilkan data yang baik

Hindari pertanyaan isian, lebih baik pilihan ganda, karenaresponden biasanya malas untuk menulis banyak, dan jikaresponden menuliskan sesuatu sering kali susah untuk dipahami.Dan juga dengan pertanyaan pilihan ganda, akan memudahkananda untuk melakukan rekapitulasi data hasil kuisoner

Buatlah pertanyaan yang tidak terlalu banyak Buatlah pertanyaan yang singkat, padat, dan jelas

3.3 Jenis Kebutuhan

Kebutuhan (requirement) yang dikumpulkan dengan menggunakanwawancara, observasi, kuisioner, atau gabungan dari ketiga hal tersebutdapat dikelompokkan menjadi beberapa kategori sebagai berikut (tidaksemua kebutuhan ini harus ada).

Functional requirement. Kebutuhan yang terkait dengan fungsiproduk, misalnya sistem informasi harus mampu mencetaklaporan, sistem informasi harus mampu menampilkan grafik, danlain-lain.

Development requirement. Kebutuhan yang terkait tools untukpengembangan sistem informasi baik perangkat keras maupunperangkat lunak, misalnya sistem informasi dikembangkan denganmenggunakan alat bantu Eclipse untuk pengembangan dan StarUMLuntuk pemodelan.

Deployment requirement. Kebutuhan terkait dengan lingkungan dimana sistem informasi akan digunakan baik perangkat lunakmaupun perangkat keras. Contoh kebutuhan ini misalnya sisteminformasi harus mampu berjalan pada server dengan spesifikasiperangkat keras memory 1 GB, processor Pentium 4 2 GB, danspesifikasi sistem operasi Ubuntu 7.4.


3-6

Performance requirement. Kebutuhan yang terkait dengan ukurankualitas maupun kuantitas, khususnya terkait dengan kecepatan,skalabilitas, dan kapasitas. Misalnya sistem informasi tersebut harusmampu diakses oleh minimal 1000 orang pada waktu yangbersamaan.

Documentation requirement. Kebutuhan ini terkait dengan dokumenapa saja yang akan disertakan pada produk akhir. Dokumen yangbiasanya dihasilkan pada tahap akhir pengembangan sisteminformasi antara lain dokumen teknis (mulai dari dokumenperencanaan proyek, analisis, desain, sampai pengujian), usermanual, dan dokumen pelatihan.

Support requirement. Kebutuhan yang terkait dukungan yangdiberikan setelah sistem informasi digunakan. Dukungan teknistersebut misalnya adanya pelatihan bagi calon pengguna.

Miscellaneous requirement. Kebutuhan ini adalah kebutuhan-kebutuhan tambahan lainnya yang belum tercakup pada beberapakategori kebutuhan yang telah terdefinisi di atas.


Desain Sistem 3-7

Latihan

1. Basica. Apakah yang dimaksud dengan analisis sistem?b. Kegiatan apa saja yang dilakukan pada saat analisis sistem?c. Sebutkan dan jelaskan macam-macam teknik pengumpulan

data!d. Sebutkan jenis-jenis kebutuhan pengembangan sistem

informasi!e. Apakah yang dimaksud dengan dokumen SRS?f. Apa saja isi dokumen SRS?

2. Advanceda. Buatlah sebuah dokumen SRS untuk pengembangan

sistem informasi apotek!


Desain Sistem 4-1

4 Desain Sistem

Overview

Desain sistem informasi merupakan tahapan yang harus dilakukanberikutnya setelah analisis desain. Bab desain sistem ini berisi konsep dasaruntuk melakukan perancangan sistem dengan menggunakan pendekatanberorientasi objek. Selain itu, pada bab ini juga ada perbandingan metodedesain sistem berorientasi objek dengan pendekatan terstruktur.

Tujuan

1. Mahasiswa memahami apa yang dilakukan dalam tahap desain sistem.2. Mahasiswa memahami desain sistem dengan pendekatan berorientasi

objek.3. Mahasiswa mampu membuat desain sistem dengan pendekatan

berorientasi objek.4. Mahasiswa mengerti perbandingan antara pendekatan berorientasi

objek dengan pendekatan terstruktur


4-2

4.1 Definisi Desain Sistem

Desain atau perancangan dalam pembangunan perangkat lunak merupakanupaya untuk mengonstruksi sebuah sistem yang memberikan kepuasan(mungkin informal) akan spesifikasi kebutuhan fungsional, memenuhi target,memenuhi kebutuhan secara implisit atau eksplisit dari segi performansimaupun penggunaan sumber daya, kepuasan batasan pada proses desaindari segi biaya, waktu, dan perangkat. Kualitas perangkat lunak biasanyadinilai dari segi kepuasan pengguna perangkat lunak terhadap perangkatlunak yang digunakan.

4.2 Konsep Dasar Pendekatan Berorientasi Objek

Pendekatan berorientasi objek merupakan suatu teknik atau carapendekatan dalam melihat permasalahan dan sistem (sistem perangkatlunak. sistem informasi, atau sistem lainnva). Pendekatan berorientasi objekakan memandang sistem yang akan dikembangkan sebagai suatu kumpulanobjek yang berkorespondensi dengan objek-objek dunia nvata. Ada banvakcara untuk mengabstraksikan dan memodelkan objek-objek tersebut, mulaidan abstraksi objek, kelas, hubungan antar kelas sampai abstraksi sistem.Saat mengabstraksikan dan memodelkan objek mi, data dan proses-prosesyang dipunyai oleh objek akan dienkapsulasi (dibungkus) menjadi satukesatuan.

Dalam rekayasa perangkat lunak, konsep pendekatan berorientasi objekdapat diterapkan pada tahap analisis, perancangan, pemrograman, danpengujian perangkat lunak. Ada berbagai teknik yang dapat digunakan padamasing-masing tahap tersebut, dengan aturan dan alat bantu pemodelantertentu.

Sistem berorientasi objek merupakan sebuah sistem yang dibangun denganberdasarkan metode berorientasi objek adalah sebuah sistem yangkomponennva dibungkus (dienkapsulasi) menjadi kelompok data dan fungsi.Setiap komponen dalam sistem tersebut dapat mewarisi atribut dan sifatdan komponen lainnya. dan dapat berinteraksi satu sama lain.


Desain Sistem 4-3

Karakteristik atau sifat-sifat yang dipunyai sebuah sistem berorientasi objekadalah sebagai berikut:

Abstraksiprinsip untuk merepresentasikan dunia nyata yang kompleksmenjadi satu bentuk model yang sederhana dengan mengabaikanaspek-aspek lain yang tidak sesuai dengan permasalahan

Enkapsulasipembungkusan atribut data dan layanan (operasi-operasi) yangdipunyai objek. untuk menyembunyikan implementasi dan objeksehingga objek lain tidak mengetahui cara kerja-nya

Pewarisan (inheritance)mekanisme yang memungkinkan satu objek mewarisi sebagian atauseluruh definisi dan objek lain sebagai bagian dan dirinya

Reusabililypemanfaatan kembali objek yang sudah didefinisikan untuk suatupermasalahan pada permasalahan lainnya yang melibatkan objektersebut

Generalisasi dan Spesialisasimenunjukkan hubungan antara kelas dan objek yang umum dengankelas dan objek yang khusus

Komunikasi Antar Objekkomunikasi antar objek dilakukan lewat pesan (message) yangdikirim dan satu objek ke objek lainnya

Polymorphismkemampuan suatu objek untuk digunakan di banyak tujuan yangberbeda dengan nama yang sama sehingga menghemat barisprogram.

4.3 Metodologi Berorientasi Objek

Metodologi berorientasi objek adalah suatu strategi pembangunanperangkat lunak yang mengorganisasikan perangkat lunak sebagai kumpulanobjek yang berisi data dan operasi yang diberlakukan terhadapnva.Metodologi berorientasi objek merupakan suatu cara bagaimana sistemperangkat lunak dibangun melalui pendekatan objek secara sistematis.Metode berorientasi objek didasarkan pada penerapan prinsip-prinsippengelolaan kompleksitas. Metode berorientasi objek meliputi rangkaian


4-4

aktivitas analisis berorientasi objek. perancangan berorientasi objek,pemrograman berorientasi objek. dan pengujian berorientasi objek.

Pada saat ini, metode berorientasi objek banyak dipilih karena metodologilama banyak menimbulkan masalah seperti adanya kesulitan pada saatmentransformasi hasil dari satu tahap pengembangan ke tahap berikutnya,misalnya pada metode pendekatan terstruktur, jenis aplikasi yangdikembangkan saat ini berbeda dengan masa lalu. Aplikasi yangdikembangkan pada saat ini sangat beragam (aplikasi bisnis. real-time, utility,dan sebagainva) dengan platform yang berbeda-beda, sehingga menimbulkantuntutan kebutuhan metodologi pengembangan yang dapat mengakomodasike semua jenis aplikasi tersebut.

Keuntungan menggunakan metodologi berorientasi objek adalah sebagaiberikut:

meningkatkan produktivitaskarena kelas dan objek yang ditemukan dalam suatu masalah masihdapat dipakai ulang untuk masalah lainnva yang melibatkan objektersebut (reusable)

kecepatan pengembangankarena sistem yang dibangun dengan baik dan benar pada saatanalisis dan perancangan akan menyebabkan berkurangnvakesalahan pada saat pengkodean

kemudahan pemeliharaankarena dengan model objek, pola-pola yang cenderung tetap danstabil dapat dipisahkan dan pola-pola yang mungkin sering berubah-ubah

adanya konsistensikarena sifat pewarisan dan penggunaan notasi yang sama pada saatanalisis, perancangan maupun pengkodean.

meningkatkan kualitas perangkat lunakkarena pendekatan pengembangan lebih dekat dengan dunia nyatadan adanya konsistensi pada saat pengembangannva, perangkatlunak yang dihasilkan akan mampu memenuhi kebutuhan pemakaiserta mempunyai sedikit kesalahan.


Desain Sistem 4-5

4.4 Pengertian Objek dan Kelas

Kelas adalah kumpulan dan objek-objek dengan karakteristik yang sama.Kelas merupakan definisi statik dan himpunan objek yang sama yangmungkin lahir atau diciptakan dan kelas tersebut. Sebuah kelas akanmempunvai sifat (atribut). kelakuan (operasi/metode), hubungan(relationship) dan arti. Suatu kelas dapat diturunkan dan kelas yang lain,dimana atribut dan kelas semula dapat diwariskan ke kelas yang baru.

Secara teknis, kelas adalah sebuah struktur tertentu dalam pembuatanperangkat lunak. Kelas merupakan bentuk struktur pada kode programyang menggunakan metodologi berorientasi objek. Ilustrasi dari sebuahkelas dapat dilihat pada gambar berikut.

Gambar 4 Ilustrasi Kelas

Sebuah kelas lebih fleksibel untuk digunakan oleh kelas lain.

Objek adalah abstraksi dan sesuatu yang mewakili dunia nyata sepertibenda, manusia, satuan organisasi, tempat, kejadian, struktur, status, atauhal-hal lain yang bersifat abstrak. Objek merupakan suatu entitas yangmampu menyimpan informasi (status) dan mempunvai operasi (kelakuan)ang dapat diterapkan atau dapat berpengaruh pada status objeknya. Objekmempunyai siklus hidup yaitu diciptakan, dimanipulasi, dan dihancurkan.

Secara teknis, sebuah kelas saat program dieksekusi maka akan dibuatsebuah objek. Objek dilihat dari segi teknis adalah elemen pada saatruntime yang akan diciptakan, dimanipulasi, dan dihancurkan saat eksekusi


4-6

sehingga sebuah objek hanya ada saat sebuah program dieksekusi, jika masihdalam bentuk kode, disebut sebagai kelas jadi pada saat runtime (saat sebuahprogram dieksekusi), yang kita punya adalah objek, di dalam teks programyang kita lihat hanyalah kelas. Ilustrasi kelas dan objek dapat dilihat padagambar berikut.

Gambar 5 Ilustrasi Kelas dan Objek

4.5 Enkapsulasi

Enkapsulasi dapat dianggap sebagai sebuah bungkusan. Enkapsulasi inilahyang diimplementasikan dalam sebuah kelas dimana di dalam sebuah kelasterdiri dari atribut dan metode yang dibungkus dalam suatu kelas.Enkapsulasi pada sebuah kelas bertujuan untuk melindungi atribut danmetode-metode yang ada di dalam kelas agar tidak sembarangan diaksesoleh kelas lain.

4.6 Atribut

Atribut dari sebuah kelas adalah variabel global yang dimiliki sebuah kelas.Atribut dapat berupa nilai atau elemen-elemen data yang dimiliki oleh objekdalam kelas objek. Atribut dipunyai secara individual oleh sebuah objek,misalnya berat, jenis, nama, dan sebagainya.


Desain Sistem 4-7

4.7 Operasi atau Metode (Method)

Operasi atau metode atau method pada sebuah kelas hampir sama denganfungsi atau prosedur pada metodologi struktural. Sebuah kelas bolehmemiliki lebih dari satu metode atau operasi. metode atau operasi yangberfungsi untuk memanipulasi objek itu sendiri. Operasi atau metodemerupakan fungsi atau transformasi yang dapat dilakukan terhadap objekatau dilakukan oleh objek. Metode atau operasi dapat berasal dari

event aktivitas atau aksi keadaan fungsi kelakuan dunia nyata

Contoh metode atau operasi misalnya Read, Write, Move. Copy. dansebagainya.

4.8 Pengertian Package

Package adalah sebuah kontainer atau kemasan yang dapat digunakan untukmengelompokkan kelas-kelas sehingga memungkinkan beberapa kelas yangbernama sama disimpan dalam package yang berbeda. Ilustrasi dari sebuahpackage dapat dilihat pada gambar berikut.

Gambar 6 Package


4-8

4.9 Pengertian Antarmuka (Interface)

Antarmuka atau interface sangat mirip dengan kelas, tapi tanpa atribut kelasdan memiliki metode yang dideklarasikan tanpa isi. Deklarasi metode padasebuah interface dapat diimplementasikan oleh kelas lain. Sebuah kelasdapat mengimplementasikan lebih dari satu antarmuka dimana kelas ini akanmendeklarasikan metode pada antarmuka yang dibutuhkan oleh kelas itusekaligus mendefinisikan isinya pada kode program kelas itu. Metode padaantarmuka yang diimplementasikan pada suatu kelas harus sama persisdengan yang ada pada antarmuka, misalnya pada antarmuka terdapatdeklarasi metode printAnimal() maka pada kelas yang mengimplementasikanmetode itu harus ditulis sama. Antarmuka atau interface biasanya digunakanagar kelas yang lain tidak mengakses langsung ke suatu kelas, mengaksesantarmukanya.

4.10 Sekilas Pendekatan terstruktur

Teknik terstruktur, merupakan pendekatan formal untuk memecahkanmasalah-masalah dalam aktivitas bisnis menjadi bagian-bagian kecil yangdapat diatur dan berhubungan untuk kemudian dapat disatukan kembalimenjadi satu kesatuan yang dapat dipergunakan untuk memecahkanmasalah.

Dalam hubungannya dengan pengembangan sistem informasi dan softwareaplikasi sistem informasi, pemrograman terstruktur adalah proses yangberorientasi kepada teknik yang digunakan untuk merancang dan menulisprogram secara jelas dan konsisten. Desain terstruktur merupakan salahsatu proses yang berorientasi teknik yang digunakan untuk memilah-milahprogram besar ke dalam hirarki modul-modul yang menghasilkan programkomputer yang lebih kecil agar mudah untuk diimplementasikan dandipelihara (diubah). Analisis Terstruktur Modern merupakan teknik yangberorientasi kepada proses yang paling populer dan banyak digunakandewasa ini. Pemodelan data merupakan suatu teknik yang berorientasikepada data dengan menunjukkan sistem hanya datanya saja terlepas daribagaimana data tersebut akan diproses atau digunakan untuk menghasilkaninformasi. Rekayasa Informasi merupakan perpaduan dari pemodelan datadan proses, juga memberikan penekanan baru terhadap pentingnyaperencanaan sistem informasi.


Desain Sistem 4-9

Ciri-ciri utama teknik terstruktur adalah sebagai berikut: merancang berdasar modul

modularisasi adalah proses yang membagi suatu sistem menjadibeberapa modul yang dapat beroperasi secara independen

bekerja dengan pendekatan top-downdimulai dari level atas (secara global) kemudian diuraikan sampaike tingkat modul (rinci)

dilakukan secara iterasidengan iterasi akan didapat hasil yang lebih baik, terlalu banyakiterasi juga akan menurunkan hasilnya dan menunjukkan bahwatahap sebelumnya tidak dilakukan dengan baik

kegiatan dilakukan secara paralelpengembangan subsistem-subsistem dapat dilakukan secara paralel,sehingga akan memperpendek waktu pengembangan sistem

Secara teknis berikut adalah gambar ilustrasi teknik terstruktur di dalamprogram:

Gambar 7 Ilustrasi Teknik Terstruktur


4-10

4.11 Perbandingan Pendekatan OO dan Terstruktur

Perbedaan yang paling dasar dari pendekatan terstruktur dan pendekatanOO (Object Oriented) atau berorientasi objek adalah pada metodeberorientasi fungsi atau aliran data (Data Flow Diagram (DFD)) (pendekatanterstruktur), dekomposisi permasalahan dilakukan berdasarkan fungsi atauproses secara hirarki, mulai dan konteks sampai proses-proses yang palingkecil, sementara pada metode berorientasi objek. dekomposisipermasalahan dilakukan berdasarkan objek-objek yang ada dalam sistem.Ilustrasi perbandingan pendekatan berorientasi objek dengan pendekatanterstruktur dapat dilihat pada gambar berikut:

Gambar 8 Ilustrasi Perbandingan OO vs Terstruktur


Desain Sistem 4-11

Latihan

1. Basica. Apakah yang dimaksud dengan desain sistem?b. Hal apa saja yang dilakukan pada tahap desain sistem?c. Sebutkan dan jelaskan karakteristik apa saja yang terdapat

pada sistem berorientasi objek!d. Mengapa berkembang metodologi berorientasi objek?e. Apa yang dimaksud dengan kelas dan objek? Gambarkan

keterhubungan antara kelas dan objek!f. Apa yang dimaksud dengan pendekatan terstruktur?g. Apa perbedaan pendekatan terstruktur dengan

pendekatan berorientasi objek?2. Advanced

a. Sebutkan minimal 2 metodologi lain (selain pendekatanterstruktur dan pendekatan berorientasi objek). Sebutkankarakteristiknya dan kemudian carilah kelebihan dankekurangannya jika dibandingkan dengan pendekatanterstruktur dan pendekatan berorientasi objek!


Pemodelan dan UML 5-1

5 Pemodelan dan UML

Overview

Bab ini berisi penjelasan mengenai pemodelan dan UML. Pemodelandigunakan untuk menggambarkan desain sistem. Salah satu bentukpemodelan adalah UML. UML terdiri dari bermacam-macam diagram. Padasaat melakukan desain sistem, tidak harus semua diagram pada UMLdiimplementasikan.

Tujuan

1. Mahasiswa mampu memahami fungsi pemodelan yang digunakan untukdesain sistem.

2. Mahasiswa mengenal apa itu UML.3. Mahasiswa mampu memahami fungsi UML.


5-2

5.1 Kompleksitas Pengembangan Perangkat Lunak

Mengelola pengambangan perangkat lunak bukanlah hal yang mudah. Secaralogika sama dengan mengelola banyak kepala yang memiliki tingkatpemahaman dan pemikiran yang berbeda untuk membuat sebuah benda.Semakin banyak kepala yang harus disatukan maka semakin sulitmengelolanya.

Kompleksitas sebuah perangkat lunak dapat dilihat dari hal-hal berikut: Kompleksitas domain atau permasalahan perangkat lunak

Pendefinisian fungsi-fungsi pada perangkat dan pendefinisianpenanganan kasus-kasus yang mungkin di dalam sebuah fungsibukanlah hal yang mudah. Sering permasalahan yang belumdidefinisikan pada spesifikasi muncul begitu sebuah perangkat lunaksudah masuk ke tahap implementasi atau pengkodean. Hal sepertiini dapat menyebabkan proses kembali ke tahap analisis atau seringlangsung diputuskan pada saat implementasi tanpa memperbaikidokumen analisis perangkat lunak, secara konsep hal ini dapatmenyebabkan ketidakkonsistenan antara dokumen dan perangkatlunak. Belum lagi permasalahan perbedaan interpretasi pemahamanspesifikasi oleh orang yang mengembangkan aplikasi yang terkadangtidak ditanyakan, tapi membuat asumsi sendiri.

Kesulitan mengelola proses pengembangan perangkat lunakPengembangan perangkat lunak biasa dilakukan secara tim. Olehkarena itu diperlukan koordinasi yang cukup tinggi diantaraanggota tim. Jika koordinasi kurang maka kesalahpahamaninterpretasi akan banyak terjadi sehingga bisa jadi perangkat lunakyang dibangun tidak pernah selesai.

Kemungkinan fleksibilitas perubahan perangkat lunakSering kasus pada dunia nyata bahwa tim yang mengerjakanbukanlah orang yang memiliki kepentingan terhadap aplikasi.Sehingga tercipta hubungan klien dan developer dimana klien akanmelakukan permintaan aplikasi dengan fungsi-fungsi yang diabutuhkan dan developer berkewajiban membuat aplikasi yangdiminta oleh klien. Semakin terbatasnya pengetahuan klienmengenai teknologi informasi dan semakin banyaknya klien yangperlu dimintai pertimbangan mengenai kebutuhan aplikasi makaakan semakin tinggi kemungkinan perubahan spesifikasi di tengahproses pengembangan jika tidak ada perjanjian spesifikasi yang



mengikat. Hal inilah yang sering menyebabkan pengembanganaplikasi mengalami kemoloran waktu.

Permasalahan karakteristik bagian-bagian perangkat lunak secaradiskritDalam pembangunan perangkat lunak sering dilakukan denganbeberapa orang atau tim. Maka perangkat lunak akan dibagi-bagimenjadi bagian-bagian yang harus dikerjakan orang-orang di dalamtim. Jika permasalahan bagian-bagian perangkat lunak secara diskrittidak terdefinisi dengan benar atau dipahami berbeda oleh setiaporang yang ada di dalam tim, maka kemungkinan saat bagian-bagianini digabungkan akan terjadi banyak kesalahan atau error. Maka dariitu koordinasi dan komunikasi yang baik di dalam sebuah timsangat dibutuhkan.

Karena berbagai masalah dan resiko yang mungkin timbul di dalampengembangan perangkat lunak maka perlu adanya perencanaan danpemodelan perangkat lunak.

5.2 Pemodelan

Pemodelan adalah gambaran dari realita yang simpel dan dituangkan dalambentuk pemetaan dengan aturan tertentu. Pemodelan dapat menggunakanbentuk yang sama dengan realitas misalnya jika seorang arsitek inginmemodelkan sebuah gedung yang akan dibangun maka dia akanmemodelkannya dengan membuat sebuah maket (tiruan) arsitektur gedungyang akan dibangun dimana maket itu akan dibuat semirip mungkin dengandesain gedung yang akan dibangun agar arsitektur gedung yang diinginkandapat terlihat. Seperti yang kita ketahui bahwa manusia akan lebihmemahami suatu hal dengan menggunakan visual agar sekelompok manusiayang berkepentingan dapat mengerti bagaimanakah ide yang akandikerjakan. Pemodelan juga banyak digunakan untuk merencanakan suatuhal agar kegagalan dan resiko yang yang mungkin terjadi dapat diminimalisir.

Pada dunia pembangunan perangkat lunak sistem informasi juga diperlukanpemodelan. Pemodelan perangkat lunak digunakan untuk mempermudahlangkah berikutnya dari pengembangan sebuah sistem informasi sehinggalebih terencana. Seperti halnya maket, pemodelan pada pembangunanperangkat lunak digunakan untuk memvisualkan perangkat lunak yang akandibuat.


5-4

Pemodelan perangkat lunak memiliki beberapa abstraksi, misalnya sebagaiberikut:

petunjuk yang terfokus pada proses yang dimiliki oleh sistem spesifikasi struktur secara abstrak dari sebuah sistem (belum

detail) spesifikasi lengkap dari sebuah sistem yang sudah final spesifikasi umum atau khusus sistem bagian penuh atau parsial dari sebuah sistem

Perangkat pemodelan adalah suatu model yang digunakan untukmenguraikan sistem menjadi bagian-bagian yang dapat diatur danmengkomunikasikan ciri konseptual dan fungsional kepada pengamat. Peranperangkat pemodelan:

Komunikasio Perangkat pemodelan dapat digunakan sebagai alat

komunikasi antara pemakai dengan analis sistem maupundeveloper dalam pengembangan sistem.

Eksperimentasio Pengembangan sistem yang bersifat “trial and error”

Prediksio Model meramalkan bagaimana suatu sistem akan bekerja

Salah satu perangkat pemodelan adalah Unified Modeling Language (UML).

5.3 Unified Modeling Language (UML)

5.3.1 Pengenalan UML

Pada perkembangan teknologi perangkat lunak, diperlukan adanya bahasayang digunakan untuk memodelkan perangkat lunak yang akan dibuat danperlu adanya standarisasi agar orang di berbagai negara dapat mengertipemodelan perangkat lunak. Seperti yang kita ketahui bahwa menyatukanbanyak kepala untuk menceritakan sebuah ide dengan tujuan untukmemahami hal yang sama tidaklah mudah, oleh karena itu diperlukan sebuahbahasa pemodelan perangkat lunak yang dapat dimengerti oleh banyakorang.

Banyak orang yang telah membuat bahasa pemodelan pembangunanperangkat lunak sesuai dengan teknologi pemrograman yang berkembang



pada saat itu, misalnya yang sempat berkembang dan digunakan oleh banyakpihak adalah Data Flow Diagram (DFD) untuk memodelkan perangkat lunakyang menggunakan pemrogramana prosedural atau struktural, kemudianjuga ada State Transition Diagram (STD) yang digunakan untuk memodelkansistem real time (waktu nyata).

Pada perkembangan teknik pemrograman berorientasi objek, muncullahsebuah standarisasi bahasa pemodelan untuk pembangunan perangkat lunakyang dibangun dengan menggunakan teknik pemrograman berorientasiobjek, yaitu Unified Modeling Language (UML). UML muncul karena adanyakebutuhan pemodelan visual untuk menspesifikasikan, menggambarkan,membangun, dan dokumentasi dari sistem perangkat lunak. UMLmerupakan bahasa visual untuk pemodelan dan komunikasi mengenaisebuah sistem dengan menggunakan diagram dan teks-teks pendukung.

Seperti yang kita ketahui bahwa banyak hal di dunia sistem informasi yangtidak dapat dibakukan, semua tergantung kebutuhan, lingkungan dankonteksnya. Begitu juga dengan perkembangan penggunaan UMLbergantung pada level abstraksi penggunaannya. Jadi belum tentu pandanganyang berbeda dalam penggunaan UML adalah suatu yang salah, tapi perluditelaah dimanakah UML digunakan dan hal apa yang ingin divisualkan.Secara analogi jika dengan bahasa yang kita gunakan sehari-hari, belum tentupenyampaian bahasa dengan puisi adalah hal yang salah. Sistem informasibukanlah ilmu pasti, maka jika ada banyak perbedaan dan interpretasi didalam bidang sistem informasi merupakan hal yang sangat wajar.

5.3.2 Sejarah Singkat UML

Bahasa pemrograman berorientasi objek yang pertama dikembangkandikenal dengan nama Simula-67 yang dikembangkan pada tahun 1967.Bahasa pemrograman ini kurang berkembang dan dikembangkan lebihlanjut, namun dengan kemunculannya telah memberikan sumbangan yangbesar pada developer pengembang bahasa pemrograman berorientasi objekselanjutnya.

Perkembangan aktif dari pemrograman berorientasi objek mulai menggeliatketika berkembangnya bahasa pemrograman Smalltalk pada awal 1980-anyang kemudian diikuti dengan perkembangan bahasa pemrograman


5-6

beorientasi objek yang lainnya seperti C objek, C++, Eiffel, dan CLOS.Secara aktual, penggunaan bahasa pemrograman berorientasi objek padasaat itu masih terbatas, namun telah banyak menarik perhatian di saat itu.Sekitar lima tahun setelah Smalltalk berkembang, maka berkembang pulametode pengembangan berorientasi objek. Metode yang pertamadiperkenalkan oleh Sally Shlaer dan Stephen Mellor (Shlaer-Mellor, 1988)dan Peter Coad dan Edward Yourdon (Coad-Yourdon, 1991), diikuti olehGrady Booch (Booch, 1991), James R. Rumbaugh, Michael R. Blaha, WilliamLorensen, Frederick Eddy, William Premerlani (Rumbaugh-Blaha-Premerlani-Eddy-Lorensen, 1991), dan masih banyak lagi. Buku terkenalyang juga berkembang selanjutnya adalah karangan Ivar Jacobson (Jacobson,1992) yang menerangkan perbedaan pendekatan yang fokus pada use casedan proses pengembangan. Sekitar lima tahun kemudian muncul buku yangmembahas mengenai metodologi berorientasi objek yang diikuti denganbuku-buku yang lainnya. Di dalamnya juga membahas mengenai konsep,definisi, notasi, terminologi, dan proses mengenai metodologi berorientasiobjek.

Karena banyaknya metodologi-metodologi yang berkembang pesat saat itu,maka muncullah ide untuk membuat sebuah bahasa yang dapat dimengertisemua orang. Usaha penyatuan ini banyak mengambil dari metodologi-metodologi yang berkembang saat itu. Maka dibuat bahasa yang merupakangabungan dari beberapa konsep seperti konsep Object Modelling Technique(OMT) dari Rumbaugh dan Booch (1991), konsep The Classes,Responsibilities, Collaborators (CRC) dari Rebecca Wirfs-Brock (1990),konsep pemikiran Ivar Jacobson, dan beberapa konsep lainnya dimana JamesR. Rumbaigh, Grady Booch, dan Ivar Jacobson bergabung dalam sebuahperusahaan yang bernama Rational Software Corporation menghasilkanbahasa yang disebut dengan Unified Modeling Language (UML). Pada 1996,Object Management Group (OMG) mengajukan proposal agar adanyastandardisasi pemodelan berorientasi objek dan pada bulan September1997 UML diakomodasi oleh OMG sehingga sampai saat ini UML telahmemberikan kontribusinya yang cukup besar di dalam metodologiberorientasi objek dan hal-hal yang terkait di dalamnya.



5.3.3 View dan Diagram UML

Tidak ada batasan yang jelas antara aneka ragam konsep dan kosntruksi didalam UML, tapi untuk pemahaman yang lebih mudah, UML dibagi menjadibeberapa view atau pandangan. View atau pandangan adalah bagian yangsimpel dari konstruksi pemodelan UML yang merepresentasikan aspek darisebuah sistem. Pembagian menjadi view atau pandangan yang berbedabukanlah sesuatu yang baku tergantung dari kebutuhan, tapi diharapkandengan adanya view akan memudahkan kosntruksi UML. Satu atau lebihdiagram merepresentasikan konsep notasi visual pada setiap view ataupadangan.

Pada level atas, view atau pandangan dapat dibagi menjadi tiga area: klasifikasi struktural (structural clasification)

mendeskripsikan hubungan segala hal yang ada di dalam sistem kelakuan dinamik (dynamic behavior)

mendeskripsikan kelakuan sistem, atau urutan perubahan yangdialami sistem

pengelolaan model (model management).mendeskripsikan keterkaitan organisasi dengan hirarki unit yangada di dalam sistem

Berikut adalah keterkaitan antara view dan diagram di dalam UML:

Area Mayor View Diagramstruktural static view

view ataupandangan yangtidak bergantungpada waktu

diagram kelas

use case view

view ataupandangan dari segifungsionalitassistem

diagram use case

implementation view diagram komponen


5-8

Area Mayor View Diagram

view ataupandangan dari segikomponenimplementasisistemdeployment view

view ataupandangan dari seginode tempatkomponen di-deploy

diagram deployment

dinamik state machine view

view ataupandangan dari segistatus yang dialamisistem berdasarkanobjek-objek sistem

diagram status

activity view

view ataupandangan dari segiaktivitas yangdilakukan olehsistem

diagram aktivitas

Diagram interaksi diagram sekuendiagram kolaborasi

pengelolaan model (model-management)

model-managementview

view ataupandangan dari segipengelolaan modelsistem

diagram kelas



5.3.4 Langkah-langkah pembuatan UML

UML merupakan diagram yang saling terkait oleh karena itu perlu adanyakekonsistenan rancangan diagram yang satu dengan lainnya, bukan asalmenggambar.

Berikut adalah keterkaitan diagram-diagram pada UML beserta urutanpembuatannya.

Gambar 9 Keterkaitan Diagram UMLKeterangan:

terkait dengan diagram sebelumnya

Urutan dan keterkaitan antar diagram akan dibahas pada bab-babselanjutnya beserta cara penggambaran diagram-diagram UML.


5-10

Latihan

1. Basica. Apakah yang dimaksud dengan pemodelan?b. Apakah kegunaan pemodelan dalam pengembangan sistem

informasi?c. Apakah yang dimaksud dengan UML?d. Apa kaitan UML dengan analisis dan desain sistem

informasi?e. Sebutkan sejarah perkembangan UML!f. Gambarkan dan jelaskan keterkaitan setiap diagram UML!

2. Advanceda. Sebutkan dan jelaskan semua diagram yang ada pada UML

(termasuk juga diagram yang belum disebutkan di bukuini)!


Use Case 6-1

6 Use case

Overview

Pada bab ini, dijelaskan mengenai bagaimana melakukan desain sistemdengan menggunakan use case. Untuk memudahkan dalam pemahaman padabab ini, penjelasan mengenai use case menggunakan studi kasus perancangansistem informasi perpustakaan.

Tujuan

1. Mahasiswa memahami fungsi use case.2. Mahasiswa mampu melakukan perancangan sistem informasi dengan

menggunakan use case.


6-2

6.1 Pengertian Use case

Use case atau diagram use case merupakan pemodelan untuk kelakukan(behavior) sistem informasi yang akan dibuat. Use case mendeskripsikansebuah interaksi antara satu atau lebih aktor dengan sistem informasi yangakan dibuat. Secara kasar, use case digunakan untuk mengetahui fungsi apasaja yang ada di dalam sebuah sistem informasi dan siapa saja yang berhakmenggunakan fungsi-fungsi itu.

Syarat penamaan pada use case adalah nama didefinisikan sesimpel mungkindan dapat dipahami. Ada dua hal utama pada use case yaitu pendefinisian apayang disebut aktor dan use case.

Aktor merupakan orang, proses, atau sistem lain yang berinteraksidengan sistem informasi yang akan dibuat di luar sistem informasiyang akan dibuat itu sendiri, jadi walaupun simbol dari aktor adalahgambar orang, tapi aktor belum tentu merupakan orang.

Use case merupakan fungsionalitas yang disediakan sistem sebagaiunit-unit yang saling bertukar pesan antar unit atau aktor.

6.2 Simbol-simbol pada Use case

Berikut adalah simbol-simbol yang ada pada diagram use case:

Simbol DeskripsiUse case

nama use case

fungsionalitas yang disediakan sistemsebagai unit-unit yang saling bertukar pesanantar unit atau aktor; biasanya dinyatakandengan menggunakan kata kerja di awal diawal frase nama use case

Aktor / actor orang, proses, atau sistem lain yangberinteraksi dengan sistem informasi yangakan dibuat di luar sistem informasi yangakan dibuat itu sendiri, jadi walaupunsimbol dari aktor adalah gambar orang, tapi


Use Case 6-3

Simbol Deskripsi

nama aktor

aktor belum tentu merupakan orang;biasanya dinyatakan menggunakan katabenda di awal frase nama aktor

Asosiasi / association komunikasi antara aktor dan use case yangberpartisipasi pada use case atau use casememiliki interaksi dengan aktor

Ekstensi / extend

<<extend>>

relasi use case tambahan ke sebuah use casedimana use case yang ditambahkan dapatberdiri sendiri walau tanpa use casetambahan itu; mirip dengan prinsipinheritance pada pemrograman berorientasiobjek; biasanya use case tambahan memilikinama depan yang sama dengan use caseyang ditambahkan, misal

validasi user

validasi sidik jari

validasi username

<<extend>>

<<extend>>

arah panah mengarah pada use case yangditambahkan

Generalisasi / generalization Hubungan generalisasi dan spesialisasi(umum - khusus) antara dua buah use case


6-4

Simbol Deskripsidimana fungsi yang satu adalah fungsi yanglebih umum dari lainnya, misalnya:

mengelola data

hapus data

ubah data

arah panah mengarah pada use case yangmenjadi generalisasinya (umum)

Menggunakan / include / uses

<<include>>

relasi use case tambahan ke sebuah use casedimana use case yang ditambahkanmemerlukan use case ini untuk menjalankanfungsinya atau sebagai syarat dijalankan usecase ini

ada dua sudut pandang yang cukup besarmengenai include di use case:

include berarti use case yangditambahkan akan selalu dipanggilsaat use case tambahan dijalankan,misal pada kasus berikut:

login

validasi username

<<include>>


Use Case 6-5

Simbol Deskripsi include berarti use case yang

tambahan akan selalu melakukanpengecekan apakah use case yangditambahkan telah dijalankansebelum use case tambahandijalankan, misal pada kasusberikut:

ubah data

validasi user

<<include>>

Kedua interpretasi di atas dapat dianutsalah satu atau keduanya tergantungpada pertimbangan dan interpretasiyang dibutuhkan.

arah panah include mengarah pada use caseyang dipakai

Arah panah relasi pada use case mengarah pada usecase yang lebih besar kontrolnya atau yang dipakai.

6.3 Studi Kasus

Nama aplikasi: Sistem Informasi Manajemen Perpustakaan

Deskripsi:Sistem informasi manajemen perpustakaan merupakan sebuah sisteminformasi untuk mengelola informasi yang diperlukan dalam suatuperpustakaan yang meliputi pendaftaran pustaka, anggota, dan proses


6-6

peminjaman pustaka. Aturan perpustakaan yang harus diatasi pada sisteminformasi manajemen perpustakaan yang akan dimodelkan adalah sebagaiberikut:

1. Pustaka dapat memiliki lebih dari satu pengarang2. Anggota dapat memiliki lebih dari satu nomor telepon3. Seorang anggota dapat melakukan sebuah peminjaman dalam satu

waktu dan boleh lebih dari satu pustaka4. Seorang anggota dapat mengembalikan pustaka yang dipinjam tidak

dalam waktu yang bersamaan walaupun pustaka-pustaka itudipinjam pada waktu yang sama.

5. Pengunjung yang bukan anggota tidak diperbolehkan meminjampustaka.

6. Proses pendaftaran pustaka, anggota, dan peminjaman dilakukanoleh petugas perpustakaan.

7. Anggota dan pengunjung dapat melakukan pencarian pustaka.

Sistem informasi yang akan dibuat adalah aplikasi berbasis web. Manajemenperpustakaan meliputi fungsi-fungsi sebagai berikut:

1. Login2. Mengelola data pustaka, meliputi:

a. Memasukkan data pustakab. Mengubah data pustakac. Menghapus data pustaka

3. Mengelola data anggota, meliputi:a. Memasukkan data anggotab. Mengubah data anggotac. Menghapus data anggota

4. Mengelola data peminjaman, meliputi:a. Memasukkan data peminjamanb. Mengubah data peminjaman (mekanisme pengembalian

pustaka)5. Mencari pustaka

6.3.1 Definisi AktorBerikut adalah deskripsi pendefinisian aktor pada sistem informasimenajemen perpustakaan:


Use Case 6-7

No Aktor Deskripsi1. Petugas perpustakaan orang yang bertugas dan memiliki hak

akses untuk melakukan operasipengelolaan data pustaka, anggota, danproses pemiinjaman pustaka

2. Anggota/pengunjungperpustakaan

anggota adalah orang yangdiperbolehkan meminjam pustakasesuai dengan hak aksesnya,sedangkan pengunjung hanya memilikihak akses melihat pustaka danmembaca di perpustakaan tanpamemiliki hak untuk meminjam pustaka.

6.3.2 Definisi Use caseBerikut adalah deskripsi pendefinisian use case pada sistem informasimenajemen perpustakaan:

No Use case Deskripsi1. Login merupakan proses pengecekan hak akses

siapa yang berhak mengakses prosespengelolaan data perpustakaan yangdalam kasus ini ada petugas perpustakaan,login wajib untuk fungsi-fungsi yangberkaitan dengan akses pengubahan kebasis data, oleh karena itu fungsi-fungsiyang melakukan perubahan basis dataharus mengecek validasi user yangmengakses fungsi-fungsi ini

2. Mengelola data pustaka mengelola data pustaka merupakanproses generalisasi yang meliputi tigabuah proses pengelolaan data pustakayaitu memasukkan data pustaka,mengubah data pustaka, dan menghapusdata pustaka.


6-8

No Use case Deskripsi

3. Memasukkan datapustaka

merupakan proses memasukkan datapustaka ke dalam basis data

4. Mengubah datapustaka

merupakan proses mengubah datapustaka yang ada di basis data

5. Menghapus datapustaka

merupakan proses menghapus datapustaka yang ada di basis data

6. Mengelola dataanggota

mengelola data anggota merupakanproses generalisasi yang meliputi tigabuah proses pengelolaan data anggotayaitu memasukkan data anggota,mengubah data anggota, dan menghapusdata anggota

7. Memasukkan dataanggota

merupakan proses memasukkan dataanggota ke dalam basis data

8. Mengubah dataanggota

merupakan proses mengubah dataanggota yang ada di basis data

9. Menghapus dataanggota

merupakan proses menghapus dataanggota yang ada di basis data

10. Mengelola datapeminjaman

mengelola data peminjaman merupakanproses generalisasi yang meliputi duabuah proses pengelolaan data anggotayaitu memasukkan data peminjaman danmengubah data peminjaman

11. Memasukkan datapeminjaman

merupakan proses memasukkan datapeminjaman ketika ada anggota yangmeminjam pustaka

12. Mengubah datapeminjaman

merupakan proses mengubah datapeminjaman yang dapat dilakukan untuk


Use Case 6-9

No Use case Deskripsimengubah status peminjaman begitupustaka dikembalikan

13. Mencari pustaka mencari pustaka berdasarkan judul, namapengarang, jenis, dan kode pustakadimana akan menampilkan data pustakayang dicari

6.4 Skenario

Berikut adalah skenario jalannya masing-masing use case yang telahdidefinisikan sebelumnya:

Nama Use case: LoginSkenario:

Aksi Aktor Reaksi SistemSkenario Normal

1. Memasukkan id danpassword

2. Mengecek valid tidaknyadata masukan

3. Masuk ke aplikasipengelolaan dataperpustakaan

Skenario Alternatif1. Memasukkan id dan

password2. Mengecek valid tidaknya

data masukan3. Menampilkan pesan login

tidak valid4. Memasukkan id dan

password yang valid5. Mengecek valid tidaknya

data masukan6. Masuk ke aplikasi


6-10

Aksi Aktor Reaksi Sistempengelolaan dataperpustakaan

Nama Use case: Memasukkan data pustakaSkenario:


1. Memasukkan data pustakasesuai kolom yang ada


3. Menyimpan data pustaka kebasis data

4. Menampilkan pesan suksesdisimpan

Skenario Alternatif1. Memasukkan data pustaka

sesuai kolom yang ada2. Mengecek valid tidaknya

data masukan3. Mengeluarkan pesan bahwa

data masukan tidak valid4. Memperbaiki data masukan

yang tidak valid5. Mengecek valid tidaknya

data masukan6. Menyimpan data pustaka ke

basis data7. Menampilkan pesan sukses

disimpan

Nama Use case: Mengubah data pustakaSkenario:


1. Memasukkan kode ataujudul pustaka

2. Mencari data pustaka yang


Use Case 6-11

Aksi Aktor Reaksi Sistemakan diubah

3. Menampilkan data pustakayang dicari (belum semuakolom data pustakaditampilkan dan bisa banyakdata pustaka yangmemenuhi data pencarian)

4. Memilih data pustaka yangakan diubah

5. Menampilkan semua kolomdata pustaka yang akandiubah

6. Mengubah data pustaka7. Mengecek valid tidaknya

data masukan8. Menyimpan data yang telah

diubah ke basis data9. Menampilkan pesan bahwa

data sukses disimpanSkenario Alternatif


2. Mencari data pustaka yangakan diubah


4. Memilih data pustaka yangakan diubah

5. Menampilkan semua kolomdata pustaka yang akandiubah

6. Mengubah data pustaka7. Mengecek valid tidaknya

data masukan


6-12

Aksi Aktor Reaksi Sistem8. Menampilkan pesan bahwa


yang diubah dan tidak valid10. Mengecek valid tidaknya



data sukses disimpan

Nama Use case: Menghapus data pustakaSkenario:



2. Mencari data pustaka yangakan dihapus


4. Memilih data pustaka yangakan dihapus

5. Menampilkan pesankonfirmasi apakah dataakan benar-benar dihapus

6. Mengeklik pilihan setujudata dihapus

7. Menghapus data pustakadari basis data

8. Menampilkan pesan bahwadata sukses dihapus

Skenario Alternatif1. Memasukkan kode atau


Use Case 6-13

Aksi Aktor Reaksi Sistemjudul pustaka

2. Mencari data pustaka yangakan dihapus


4. Memilih data pustaka yangakan dihapus


6. Mengeklik pilihan tidaksetuju data dihapus

7. Kembali ke form pencarianpustaka

Nama Use case: Memasukkan data anggotaSkenario:


1. Memasukkan data anggotasesuai kolom yang ada


3. Menyimpan data anggota kebasis data


Skenario Alternatif1. Memasukkan data anggota

sesuai kolom yang ada2. Mengecek valid tidaknya

data masukan3. Mengeluarkan pesan bahwa

data masukan tidak valid


6-14

Aksi Aktor Reaksi Sistem4. Memperbaiki data masukan

yang tidak valid5. Mengecek valid tidaknya

data masukan6. Menyimpan data anggota ke

basis data7. Menampilkan pesan sukses

disimpan

Nama Use case: Mengubah data anggotaSkenario:


1. Memasukkan id atau namaanggota

2. Mencari data anggota yangakan diubah

3. Menampilkan data anggotayang dicari (belum semuakolom data anggotaditampilkan dan bisa banyakdata anggota yangmemenuhi data pencarian)

4. Memilih data anggota yangakan diubah

5. Menampilkan semua kolomdata anggota yang akandiubah

6. Mengubah data anggota7. Mengecek valid tidaknya



data sukses disimpanSkenario Alternatif



Use Case 6-15

Aksi Aktor Reaksi Sistem2. Mencari data anggota yang

akan diubah3. Menampilkan data anggota

yang dicari (belum semuakolom data anggotaditampilkan dan bisa banyakdata anggota yangmemenuhi data pencarian)

4. Memilih data anggota yangakan diubah

5. Menampilkan semua kolomdata anggota yang akandiubah

6. Mengubah data anggota7. Mengecek valid tidaknya

data masukan8. Menampilkan pesan bahwa






Nama Use case: Menghapus data anggotaSkenario:



2. Mencari data anggota yangakan dihapus

3. Menampilkan data anggotayang dicari (belum semuakolom data anggota


6-16

Aksi Aktor Reaksi Sistemditampilkan dan bisa banyakdata anggota yangmemenuhi data pencarian)

4. Memilih data anggota yangakan dihapus


6. Mengeklik pilihan setujudata dihapus

7. Menghapus data pustakadari basis data

8. Menampilkan pesan bahwadata sukses dihapus

Skenario Alternatif1. Memasukkan id atau nama

anggota2. Mencari data anggota yang

akan dihapus3. Menampilkan data anggota

yang dicari (belum semuakolom data anggotaditampilkan dan bisa banyakdata anggota yangmemenuhi data pencarian)

4. Memilih data anggota yangakan dihapus


6. Mengeklik pilihan tidaksetuju data dihapus

7. Kembali ke form pencariananggota


Use Case 6-17

Nama Use case: Memasukkan data peminjamanSkenario:


1. Memasukkan datapeminjaman sesuai kolomyang ada


3. Menyimpan datapeminjaman ke basis data


Skenario Alternatif1. Memasukkan data

peminjaman sesuai kolomyang ada


3. Mengeluarkan pesan bahwadata masukan tidak valid

4. Memperbaiki data masukanyang tidak valid


6. Menyimpan datapeminjaman ke basis data



6-18

Nama Use case: Mengubah data peminjamanSkenario:


1. Memasukkan id anggota2. Mencari data peminjaman

yang akan diubah3. Menampilkan data

peminjaman yang dicari4. Mengubah data peminjaman


6. Menyimpan data yang telahdiubah ke basis data

7. Menampilkan pesan bahwadata sukses disimpan

Skenario Alternatif1. Memasukkan id anggota

2. Mencari data peminjamanyang akan diubah

3. Menampilkan datapeminjaman yang dicari

4. Mengubah data peminjaman5. Mengecek valid tidaknya

data masukan6. Menampilkan pesan bahwa







Use Case 6-19

Nama Use case: Mencari pustakaSkenario:


1. Memasukkan judul,pengarang, jenis, atau kodepustaka

2. Mencari data pustaka yangakan dicari


4. Memilih pustaka yang dicari5. Menampilkan data pustaka

(semua kolom) dari pustakayang dipilih

Skenario Alternatif1. Memasukkan judul,

pengarang, jenis, atau kodepustaka


3. Menampilkan pesan datapustaka tidak ada

4. Memasukkan judul,pengarang, jenis, atau kodepustaka



7. Memilih pustaka yang dicari


6-20

Aksi Aktor Reaksi Sistem8. Menampilkan data pustaka

(semua kolom) dari pustakayang dipilih

6.5 Diagram Use case

Berikut adalah diagram use case dari sistem informasi manajemenperpustakaan:

Petugas Perpustakaan

Anggota/Pengunjung Perpustakaan

Mengelola data pustaka

Mengelola data anggota

Memasukkan data peminjaman

Mengubah data peminjaman

Mencari pustaka

Memasukkan data pustaka

Mengubah data pustaka

Menghapus data pustaka

Memasukkan data anggota

Mengubah data anggota

Menghapus data anggota

Login

<<include>>

<<include>>

<<include>>

Mengelola data peminjaman

Gambar 10 Diagram Use case Perpustakaan


Use Case 6-21

Latihan

1. Basica. Apakah yang dimaksud dengan use case?b. Apa kegunaan use case?c. Apakah yang dimaksud dengan <<include>> dan

<<extend>> pada use case?2. Advanced

a. Buatlah diagram use case termasuk juga use case scenariopada sistem informasi apotek!


Desain Basis Data 7-1

7 Desain Basis Data

Overview

Pada bab ini, berisi penjelasan umum mengenai basis data dan tahap-tahapyang dilakukan untuk membuat desain basis data yang digunakan padasistem informasi.

Tujuan

1. Mahasiswa memahami pengertian basis data.2. Mahasiswa mengerti cara yang harus dilakukan untuk membuat desain

basis data.3. Mahasiswa mampu membuat desain basis data yang digunakan pada

sistem informasi


7-2

7.1 Pengertian Basis Data

Sistem basis data adalah sistem terkomputerisasi yang tujuan utamanyaadalah memelihara data yang sudah diolah atau informasi dan membuatinformasi tersedia saat dibutuhkan. Pada intinya basis data adalah mediauntuk menyimpan data agar dapat diakses dengan mudah dan cepat. Padabuku ini menggunakan basis data relasional yang diimplementasikan dengantabel-tabel yang saling memiliki relasi seperti pada gambar berikut.

Gambar 11 Ilustrasi Basis Data

Sistem informasi tidak dapat dipisahkan dengan kebutuhan akan basis dataapapun bentuknya, entah berupa file teks ataupun Database ManagementSystem (DBMS). Kebutuhan basis data dalam sistem informasi meliputi:

memasukkan, menyimpan, dan mengambil data membuat laporan berdasarkan data yang telah disimpan

7.2 Database Life Cycle

Tidak hanya perangkat lunak yang memiliki alur hidup, dalam membuatperencanaan basis data juga memiliki alur hidup atau Database Life Cycle(DBLC). Fase-fase DBLC antara lain:

Analisis kebutuhan /requirement analysis



Hal-hal yang harus dilakukan pada tahap ini adalah:o Didefinisikan dengan mewawancarai produsen dan

pemakai datao Membuat kontrak spesifikasi basis datao Entity Relationship Diagram (ERD)

Desain lojik basis data / logical database designPada tahap ini harus dibuat rancangan lojik basis data. Biasanyapada tahap ini dibuat Conceptual Data Model (CDM).

Desain fisik basis data / physical database designPada tahap ini harus dibuat rancangan fisik basis data. Biasanyapada tahap ini dibuat Physical Data Model (PDM).

Implementasio Membuat Query SQLo Aplikasi ke DBMS atau file

7.3 Entity Relationship Diagram (ERD)

Pemodelan awal basis data yang paling banyak digunakan adalahmenggunakan Entity Relationship Diagram (ERD). Berikut adalah simbol-simbol yang digunakan pada ERD:

Simbol DeskripsiEntitas / entity Entitas merupakan data inti yang

akan disimpan; bakal tabel pada basisdata

Atribut Field atau kolom data yang butuhdisimpan dalam suatu entitas

Atribut kunci primer Field atau kolom data yang butuhdisimpan dalam suatu entitas dandigunakan sebagai kunci akses recordyang diinginkan; biasanya berupa id


7-4

Simbol DeskripsiAtribut multinilai / multivalue Field atau kolom data yang butuh

disimpan dalam suatu entitas yangdapat memiliki nilai lebih dari satu

Relasi

nama_relasi

Relasi yang menghubungkan antarentitas; biasanya diawali dengan katakerja

Asosiasi / association Penghubung antara relasi dan entitasdimana di kedua ujungnya memilikimultiplicity kemungkinan jumlahpemakaian

7.4 Studi kasus ERD

Studi kasus untuk membuat ERD menggunakan sistem informasi manajemenperpustakaan dengan deskripsi seperti yang ada pada bab sebelumnya.

7.4.1 Definisi Entitas dan atribut

Berikut adalah definisi entitas dan atribut dari sistem informasi manajemenperpustakaan:

No Entitas Atribut1. TPustaka

Entitas yang menyimpan datapustaka

idatribut yang menjadi identitaspustaka

judulatribut judul pustaka



No Entitas Atribut

jenisatribut jenis pustaka

jumlahatribut jumlah pustaka

tahunatribut tahun pustaka

pengarangatribut pengarang pustaka (bisalebih dari satu)

2. TAnggotaEntitas yang menyimpan dataanggota

idatribut yang menjadi identitasanggota

namaatribut nama anggota

alamatatribut alamat rumah anggota

emailatribut alamat email anggota

teleponatribut nomor telepon anggota(bisa lebih dari satu)

3. TPeminjamanEntitas yang menyimpan dataanggota

idatribut yang menjadi identitasrecord peminjaman

tgl_peminjamanatribut tanggal peminjamanpustaka


7-6

No Entitas Atribut

tgl_kembaliatribut tanggal kembali pustaka

7.4.2 Definisi Relasi

Berikut adalah definisi relasi dari sistem informasi manajemen perpustakaan:

No Relasi Deskripsi1. Dipinjam anggota merupakan relasi antara entitas TPustaka

dan entitas TPeminjaman dimana memilikimakna bahwa pustaka dipinjam olehanggota dan disimpan pada entitasTPeminjaman

2. Melakukan peminjaman merupakan relasi antara entitas TAnggotadan entitas TPeminjaman dimana memilikimakna bahwa anggota melakukanpeminjaman pustaka dan disimpan padaentitas TPeminjaman



7.4.3 Diagram ER

Gambar 12 Diagram ER Studi Kasus

7.5 Conceptual Data Model (CDM)

CDM atau model konsep data merupakan konsep yang berkaitan denganpandangan pemakai terhadap data yang disimpan dalam basis data. CDMdibuat sudah dalam bentuk tabel-tabel tanpa tipe data yang menggambarkanrelasi antar tabel untuk keperluan implementasi ke basis data.

Berikut adalah simbol-simbol yang ada pada CDM:Simbol Deskripsi

Entitas / tabel entitas atau tabel yang menyimpandata dalam basis data


7-8

Simbol DeskripsiRelasi relasi antar tabel yang terdiri atas

nama relasi dan multiplicity

7.6 Studi kasus CDM

Berikut adalah CDM dari studi kasus sistem informasi manajemenperpustakaan seperti pada studi kasus bab sebelumnya:



Gambar 13 CDM Studi Kasus

Tabel-tabel di atas merupakan hasil pertanggungjawaban dari diagram ERyang telah dibuat dengan rincian sebagai berikut:

CDM ERDTabel TPengarang atribut multivalue pengarang dari

entitas TPustakaTabel TPustaka entitas TPustakaTabel TAnggota entitas TAnggotaTabel TTelepon atribut multivalue telepon dari

entitas TAnggotaTabel TPustakaPinjam relasi dipinjam anggota dan


7-10

CDM ERDmelakukan peminjaman

Tabel TPeminjaman entitas TPeminjaman

7.7 Physical Data Model (PDM)

Model Relasional atau Physical Data Model (PDM) model yang menggunakansejumlah tabel untuk menggambarkan data serta hubungan antara data-datatersebut. Setiap tabel mempunyai sejumlah kolom di mana setiap kolommemiliki nama yang unik beserta tipe datanya. PDM merupakan konsepyang menerangkan detail dari bagaimana data di simpan di dalam basis data.

Berikut adalah simbol-simbol yang ada pada PDM:

Simbol DeskripsiTabel

nama_tabel

tabel yang menyimpan data dalambasis data

Relasi relasi antar tabel yang terdiri daripersamaan antara primary key (kunciprimer) tabel yang diacu dengankunci yang menjadi referensi acuandi tabel lain.



7.8 Studi Kasus PDM

Berikut adalah PDM dari studi kasus sistem informasi manajemenperpustakaan seperti pada studi kasus bab sebelumnya:

id = id_pustaka

id = id_anggota

id = id_peminjaman

id = id_anggota

id = id_pustaka

TPustaka

idjuduljenisjumlahtahun

varchar(10)varchar(255)varchar(20)intint

<pk>

TPengarang

id_pustakapengarang

varchar(10)varchar(255)

<pk,fk><pk>

TAnggota

idnamaalamatemail

varchar(10)varchar(50)varchar(255)varchar(50)

<pk>

TTelepon

id_anggotatelepon

varchar(10)varchar(20)

<pk,fk><pk>

TPeminjaman

idid_anggotatgl_pinjam

varchar(10)varchar(10)date

<pk,fk>

TPustakaPinjam

id_peminjamanid_pustakatgl_kembali

varchar(10)varchar(10)date

<pk,fk1><pk,fk2><pk>

Gambar 14 PDM Studi Kasus


7-12

Latihan

1. Basica. Apakah yang dimaksud dengan basis data?b. Apakah fungsi basis data pada suatu sistem informasi?c. Apakah yang dimaksud dengan DBMS dan apa fungsinya?d. Apa yang dimaksud dengan entitas, relasi, dan atribut

pada ERD?e. Apakah perbedaan antara CDM dan PDM?

2. Advanceda. Sebutkan dan jelaskan beberapa basis data non-relasional!

Apa kelebihan dan kekurangan basis data tersebut jikadibandingkan dengan basis data relasional?

b. Buatlah desain basis data untuk sistem informasi apotek!


Diagram Kelas dan Diagram Objek 8-1

8 Diagram Kelas dan Diagram Objek

Overview

Pada bab ini berisi penjelasan mengenai diagram kelas dan desain objek.Diagram tersebut digunakan untuk menggambarkan kelas-kelas yang akandigunakan pada sistem informasi. Pada bab ini, studi kasus yang digunakansama seperti bab sebelumnya yaitu sistem informasi perpustakaan. Studikasus tersebut juga akan digunakan pada bab-bab selanjutnya untukmemberikan gambaran menyeluruh mengenai desain sistem informasidengan pemodelan menggunakan UML.

Tujuan

1. Mahasiswa memahami tujuan penggunaan desain kelas dan desainobjek.

2. Mahasiswa memahami bagaimana membuat desain kelas yang baik.3. Mahasiswa mampu membuat desain kelas untuk sebuah sistem

informasi yang sederhana.


8-2

8.1 Pengertian Diagram Kelas

Diagram kelas atau class diagram menggambarkan struktur sistem dari segipendefinisian kelas-kelas yang akan dibuat untuk membangun sistem. Kelasmemiliki apa yang disebut atribut dan metode atau operasi.

atribut merupakan variabel-variabel yang dimiliki oleh suatu kelas operasi atau metode adalah fungsi-fungsi yang dimiliki oleh suatu

kelas

Berikut adalah simbol-simbol yang ada pada diagram kelas:

Simbol Deskripsipackage

package

package merupakan sebuahbungkusan dari satu atau lebih kelas

kelas

nama_kelas

+atribut

+operasi()

kelas pada struktur sistem

antarmuka / interface

nama_interface

sama dengan konsep interface dalampemrograman berorientasi objek

asosiasi / association relasi antar kelas dengan maknaumum, asosiasi biasanya juga disertaidengan multiplicity

asosiasi berarah / directed association relasi antar kelas dengan maknakelas yang satu digunakan oleh kelasyang lain, asosiasi biasanya jugadisertai dengan multiplicity



Simbol Deskripsigeneralisasi relasi antar kelas dengan makna

generalisasi-spesialisasi (umumkhusus)

kebergantungan / dependency relasi antar kelas dengan maknakebergantungan antar kelas

agregasi / aggregation relasi antar kelas dengan maknasemua-bagian (whole-part)

Arah panah relasi pada diagram kelas mengarahpada diagram kelas yang lebih besar kontrolnya atauyang dipakai.

8.2 Pendefinisian Kelas pada Diagram Kelas

Kelas-kelas yang ada pada struktur sistem harus dapat melakukan fungsi-fungsi sesuai dengan kebutuhan sistem. Susunan struktur kelas yang baikpada diagram kelas sebaiknya memiliki jenis-jenis kelas berikut:

Kelas mainKelas yang memiliki fungsi awal dieksekusi ketika sistem dijalankan.

Kelas yang menangani tampilan sistemKelas yang mendefinisikan dan mengatur tampilan ke pemakai

Kelas yang diambil dari pendefinisian use caseKelas yang menangani fungsi-fungsi yang harus ada diambil daripendefinisian use case

Kelas yang diambil dari pendefinisian dataKelas yang digunakan untuk memegang atau membungkus datamenjadi sebuah kesatuan yang diambil maupun akan disimpan kebasis data.

Jenis-jenis kelas di atas juga dapat digabungkan satu sama lain sesuai denganpertimbangan yang dianggap baik asalkan fungsi-fungsi yang sebaiknya ada


8-4

pada struktur kelas tetap ada. Susunan kelas juga dapat ditambahkan kelasutilitas seperti Koneksi ke basis data, membaca file teks, dan lain sebagainyasesuai kebutuhan.

Dalam mendefinisikan metode yang ada di dalam kelas perlumemperhatikan apa yang disebut dengan cohesion dan coupling. Cohesionadalah ukuran seberapa dekat keterkaitan instruksi di dalam sebuah metodeterkait satu sama lain sedangkan coupling adalah ukuran seberapa dekatketerkaitan instruksi antara metode yang satu dengan metode yang laindalam sebuah kelas. Sebagai aturan secara umum maka sebuah metode yangdibuat harus memiliki kadar cohesion yang kuat dan kadar coupling yanglemah.

8.3 Studi Kasus Diagram Kelas

Studi kasus diambil dari sistem informasi manajemen perpustakaan sepertipada bab-bab sebelumnya. Berikut adalah diagram kelas dari sisteminformasi manajemen perpustakaan:



TPustaka

+id+judul+jenis+jumlah+tahun+pengarang

+setId()+getId()+setJudul()+getJudul()+setJenis()+getJenis()+setJumlah()+getJumlah()+setTahun()+getTahun()+setPengarang()+getPengarang()

TPeminjaman

+id+tgl_peminjaman+id_anggota+id_pustaka+tgl_kembali

+setId()+getId()+setTglPeminjaman()+getTglPeminjaman()+setIdAnggota()+getIdAnggota()+setIdPustaka()+getIdPustaka()+setTglKembali()+getTglKembali()

TAnggota

+id+nama+alamat+telepon

+setId()+getId()+setNama()+getNama()+setAlamat()+getAlamat()+setTelepon()+getTelepon()

Login

+validasiLogin()+logout()

MengelolaAnggota

+cariAnggotaByNama()+cariAnggotaById()+memasukkanAnggota()+mengubahAnggota()+menghapusAnggota()

MengelolaPeminjaman

+memasukkanPeminjaman()+mencariPeminjaman()+ubahPeminjaman()

MengelolaPustaka

+cariPustakaById()+cariPustakaByJudul()+cariPustakaByJenis()+cariPustakaByPengarang()+memasukkanPustaka()+ubahPustaka()+hapusPustaka()

KoneksiBasisData

+host+database+username+password

+membukaKoneksi()+eksekusiQuerySelect()+eksekusiQueryUpdate()+tutupKoneksi()

1..*1

1..*1

1..*1

1..*

1

1..*

1

Main

+main()+uiLogin()+uiMenu()+uiMengelolaPustaka()+uiMengelolaAnggota()+uiMengelolaPeminjaman()

1

1 11

1

1

1..*1

1..*1

1..*

11

1

1

11

1

Gambar 15 Diagram Kelas Studi Kasus


8-6

Keterangan:

Nama Kelas KeteranganMain merupakan kelas main yang juga

merangkap sebagai kelas yangmenangangi tampilan

Login merupakan kelas proses yangdiambil dari pendefinisian use caseLogin

MengelolaPustaka merupakan kelas proses yangdiambil dari pendefinisian use caseMengelola Pustaka yang di dalamnyaharus juga menangani prosesmemasukkan data pustaka,mengubah data pustaka, danmenghapus data pustaka

MengelolaAnggota merupakan kelas proses yangdiambil dari pendefinisian use caseMengelola Anggota yang di dalamnyaharus juga menangani prosesmemasukkan data anggota,mengubah data anggota, danmenghapus data anggota

MengelolaPeminjaman merupakan kelas proses yangdiambil dari pendefinisian use caseMengelola Peminjaman yang didalamnya harus juga menanganiproses memasukkan datapeminjaman dan mengubah datapeminjaman

TPustaka merupakan kelas data yangdigunakan untuk membungkus hasildata dari tabel TPustaka danTPengarang

TAnggota merupakan kelas data yangdigunakan untuk membungkus hasildata dari tabel TAnggota danTTelepon

TPeminjaman merupakan kelas data yang



Nama Kelas Keterangandigunakan untuk membungkus hasildata dari tabel TPustakaPinjam danTPeminjaman

KoneksiBasisData merupakan kelas utilitas untukkoneksi ke basis data dan melakukanquery

8.4 Pengertian Diagram Objek

Diagram objek menggambarkan struktur sistem dari segi penamaan objekdan jalannya objek dalam sistem. Pada diagram objek harus dipastikansemua kelas yang sudah didefinisikan pada diagram kelas harus dipakaiobjeknya, karena jika tidak, pendefinisian kelas itu tidak dapatdipertanggungjawabkan.

Untuk apa mendefinisikan sebuah kelas sedangkan pada jalannya sistem,objeknya tidak pernah dipakai. Hubungan link pada diagram objekmerupakan hubungan memakai dan dipakai dimana dua buah objek akandihubungkan oleh link jika ada objek yang dipakai oleh objek lainnya.

Berikut adalah simbol-simbol yang ada pada diagram objek:

Simbol DeskripsiObjek

nama_objek : nama_kelas

atribut = nilai

objek dari kelas yang berjalan saatsistem dijalankan

Link relasi antar objek


8-8

8.5 Studi Kasus Diagram Objek

Studi kasus diambil dari sistem informasi manajemen perpustakaan sepertipada bab-bab sebelumnya. Berikut adalah diagram objek dari sisteminformasi manajemen perpustakaan:

main : Main

login : Login

db : KoneksiBasisData

host = "localhost"database = "perpustakaan"username = "root"password = "root"

mp : MengelolaPustaka

ma : MengelolaAnggota

mpinjam : MengelolaPeminjaman

p : TPustaka

id = "000000001"judul = "Rekayasa Perangkat Lunak"jenis = "Buku Teks"jumlah = 3tahun = 1999pengarang = {"Burhanudin S.", "Paparozi"}

a : TAnggota

id = "000000001"nama = "Tina"alamat = "Jl. Teladan no. 13 Bandung"email = "[email protected]"telepon = {"0812001356", "02256789"}

pinjam : TPeminjaman

id = "0000000001"tgl_peminjaman = "2008-07-13"id_anggota = "000000001"id_pustaka = {"000000001", "0000000002"}tgl_kembali = {"1900-01-01", "2008-07-20"}

Gambar 16 Diagram Objek Studi Kasus



Latihan

1. Basica. Apakah kegunaan diagram kelas dan diagram objek pada

analisis dan desain sistem informasi?b. Apakah yang dimaksud dengan dependency, aggregation,

dan association pada diagram kelas?c. Jenis kelas apa saja yang sebaiknya ada pada suatu sistem

informasi?2. Advanced

a. Buatlah diagram kelas untuk sistem informasi apotek!


Diagram Interaksi 9-1

9 Diagram Interaksi

Overview

Bab ini berisi mengenai cara untuk membuat diagram interaksi pada sebuahsistem informasi. Diagram interaksi digunakan untuk memodelkan interaksiantar objek dalam sebuah use case.

Tujuan

1. Mahasiswa memahami tujuan penggunaan diagram interaksi.2. Mahasiswa mengetahui bagaimana cara untuk membuat diagram

interaksi suatu sistem informasi.3. Mahasiswa mampu membuat diagram interaksi untuk sebuah sistem



9-2

9.1 Pengertian Diagram Interaksi

Diagram interaksi atau interaction diagram digunakan untuk memodelkaninteraksi objek di dalam sebuah use case (proses). Diagram interaksi terdiridari dua buah diagram, yaitu diagram sekuen (sequence diagram) dandiagram kolaborasi (collaboration diagram). Diagram sekuen menggambarkanurutan even yang terjadi antar objek dalam sebuah use case, sedangkandiagram kolaborasi menggambarkan bagaimana objek terkoneksi secarastatik (tetap).

9.2 Pengertian Diagram Sekuen

Diagram sekuen menggambarkan kelakuan objek pada use case denganmendeskripsikan waktu hidup objek dan message yang dikirimkan danditerima antar objek. Oleh karena itu untuk menggambar diagram sekuenmaka harus diketahui objek-objek yang terlibat dalam sebuah use casebeserta metode-metode yang dimiliki kelas yang diinstansiasi menjadi objekitu.

Banyaknya diagram sekuen yang harus digambar adalah sebanyakpendefinisian use case yang memiliki proses sendiri atau yang penting semuause case yang telah didefinisikan interaksi jalannya pesan sudah dicakup padadiagram sekuen sehingga semakin banyak use case yang didefinisikan makadiagram sekuen yang harus dibuat juga semakin banyak.

Berikut adalah simbol-simbol yang ada pada diagram sekuen:

Simbol DeskripsiAktor

nama aktor

atau

orang, proses, atau sistem lain yangberinteraksi dengan sistem informasiyang akan dibuat di luar sisteminformasi yang akan dibuat itusendiri, jadi walaupun simbol dariaktor adalah gambar orang, tapiaktor belum tentu merupakanorang; biasanya dinyatakanmenggunakan kata benda di awalfrase nama aktor



Simbol Deskripsi

tanpa waktu aktif

Garis hidup / lifeline menyatakan kehidupan suatu objek

Objek menyatakan objek yang berinteraksipesan

Waktu aktif menyatakan objek dalam keadaanaktif dan berinteraksi pesan

Pesan tipe create menyatakan suatu objek membuatobjek yang lain, arah panahmengarah pada objek yang dibuat

Pesan tipe call menyatakan suatu objek memanggiloperasi/metode yang ada pada objeklain atau dirinya sendiri,


9-4

Simbol Deskripsiarah panah mengarah pada objekyang memiliki operasi/metode,karena ini memanggiloperasi/metode makaoperasi/metode yang dipanggil harusada pada diagram kelas sesuaidengan kelas objek yang berinteraksi

Pesan tipe send menyatakan bahwa suatu objekmengirimkan data/masukan/informasi ke objek lainnya, arahpanah mengarah pada objek yangdikirimi

Pesan tipe return menyatakan bahwa suatu objek yangtelah menjalankan suatu operasiatau metode menghasilkan suatukembalian ke objek tertentu, arahpanah mengarah pada objek yangmenerima kembalian

Pesan tipe destroy menyatakan suatu objek mengakhirihidup objek yang lain, arah panahmengarah pada objek yang diakhiri,sebaiknya jika ada create maka adadestroy

Penomoran pesan berdasarkan urutan interaksi pesan. Penggambaran letakpesan harus berurutan, pesan yang lebih atas dari lainnya adalah pesan yangberjalan terlebih dahulu.

9.3 Studi Kasus Diagram Sekuen

Studi kasus diambil dari sistem informasi manajemen perpustakaan sepertipada bab-bab sebelumnya. Berikut adalah diagram sekuen dari sisteminformasi manajemen perpustakaan:



Use case: Login

Petugas Perpustakaan main : Main login : Login

1<<create>>

2 : username dan password3 : validasiLogin()

4 : true / false validasi5 : pesan tidak valid jika tidak valid

Use case: Memasukkan data pustaka

Petugas Perpustakaan main : Main mp : MengelolaPustaka


p : TPustaka1 : data pustaka

2 : memasukkanPustaka()

3<<create>>

4 <<create>>

5 : membukaKoneksi()

6 : eksekusiQueryUpdate()

7 : tutupKoneksi()

8<<destroy>>

9<<destroy>>


9-6

Use case: Mengubah data pustaka

Petugas Perpustakaan main : Mainmp : MengelolaPustaka

p : TPustaka


1 : id / judul/ jenis/ pengarang

2 : cariPustakaById()

3 : cariPustakaByJudul()

4 : cariPustakaByPengarang()

5<<create>>


7 : eksekusiQuerySelect()

8 : hasil query

9<<create>>

10 : setId()

11 : setJudul()

12 : setJenis()

13 : setJumlah()

14 : setTahun()

15 : setPengarang()

16 : data pustaka17 : data yang diubah

18 : ubahPustaka() 19 : eksekusiQueryUpdate()

20 : tutupKoneksi()

21<<destroy>>

22<<destroy>>

23 : pesan data telah diubah



Use case: Menghapus data pustaka

Petugas Perpustakaan main : Main mp : MengelolaPustaka

p : TPustaka


1 : id/ jenis/ judul/ pengarang


3 : cariPustakaByJenis()



6<<create>>



9 : hasil query

10<<create>>

11 : setId()

12 : setJudul()

13 : setJenis()

14 : setJumlah()

15 : setTahun()

16 : setPengarang()

17 : data pustaka18 : konf irmasi hapus

19 : hapusPustaka()


21 : tutupKoneksi()

22<<destroy>>

23<<destroy>>

24 : pesan data telah dihapus


9-8

Use case: Memasukkan data anggota

Petugas Perpustakaan main : Main ma : MengelolaAnggota


a : TAnggota1 : data anggota

2 : memasukkanAnggota()

3<<create>>

4 <<create>>



7 : tutupKoneksi()

8<<destroy>>

9<<destroy>>



Use case: Mengubah data anggota

Petugas Perpustakaan main : Ma in ma : MengelolaAnggota

a : TAnggota


1 : id/ nama

2 : cariAnggotaBy Id()

3 : cariAnggotaByNama()

4<<create>>


6 : eksekusiQuerySe lect()

7 : hasil query

8<<create>>

9 : setId()

10 : setNama()

11 : setA lamat()

12 : setEmail()

13 : setTe lepon()

14 : data anggota

15 : data yang diubah

16 : mengubahAnggota()


18 : tutupKoneksi()

19<<destroy>>

20<<destroy>>

21 : pesan data te lah diubah


9-10

Use case: Menghapus data anggota

Petugas Perpustakaan main : Main


a : TAnggota


1 : id/ nama

2 : cariAnggotaById()

3 : cariAnggotaByNama()

4<<create>>



7 : hasil query

8<<create>>

9 : setId()

10 : setNama()

11 : setA lamat()

12 : setEmail()

13 : setTelepon()

14 : data anggota15 : konf irmasi hapus

16 : menghapusAnggota()17 : eksekusiQueryUpdate()

18 : tutupKoneksi()

19<<destroy>>

20<<destroy>>

21 : pesan data te lah dihapus



Use case: Memasukkan data peminjaman

Petugas Perpustakaan main : Main mpinjam : MengelolaPeminjaman


pinjam : TPeminjaman1 : data peminjaman

2 : memasukkanPeminjaman()

3<<create>>

4 <<create>>



7 : tutupKoneksi()

8<<destroy>>

9<<destroy>>


9-12

Use case: Mengubah data peminjaman

Petugas Perpustakaan

main : Main mpinjam : MengelolaPeminjaman



1 : id_anggota2 : mencariPeminjaman()

3<<create>>



6 : hasil query

7<<create>>

8 : setId()

9 : setTglPeminjaman()

10 : setIdAnggota()

11 : setIdPustaka()

12 : setTglKembali()

13 : data peminjaman14 : data yang diubah

15 : ubahPeminjaman()16 : eksekusiQueryUpdate()

17 : tutupKoneksi()

18<<destroy>>

19<<destroy>>

20 : pesan data telah diubah



Use case: Mencari pustaka

Petugas/ anggota/ pengunjung Perpustakaan main : Main mp : MengelolaPustaka

p : TPustaka


1 : id/ jenis/ judul/ pengarang


3 : cariPustakaByJenis()



6<<create>>



9 : hasil query

10<<create>>

11 : setId()

12 : setJudul()

13 : setJenis()

14 : setJumlah()

15 : setTahun()

16 : setPengarang()

17 : data pustaka 18<<destroy>>

19<<destroy>>


9-14

9.4 Pengertian Diagram Kolaborasi

Diagram kolaborasi mengelompokkan message pada kumpulan diagramsekuen menjadi sebuah diagram. Dalam diagram kolaborasi yang dituliskanadalah operasi/metode yang dijalankan antara objek yang satu dan objeklainnya secara keseluruhan, oleh karena itu dapat diambil dari jalannyainteraksi pada semua diagram sekuen. Penomororan metode dapatdilakukan berdasarkan urutan dijalankannnya metode/operasi diantara objekyang satu dengan objek lainnya atau objek itu sendiri.

Berikut adalah simbol-simbol yang ada pada diagram kolaborasi:Simbol Deskripsi

Objek


objek yang melakukan interaksipesan

Link relasi antar objek yangmenghubungkan objek satu denganlainnya atau dengan dirinya sendiri


Arah pesan / stimulus arah pesan yang terjadi, jika padasuatu link ada dua arah pesan yangberbeda maka arah jugadigambarkan dua arah pada dua sisilink



9.5 Studi Kasus Diagram Kolaborasi

Studi kasus diambil dari sistem informasi manajemen perpustakaan sepertipada bab-bab sebelumnya. Berikut adalah diagram kolaborasi dari sisteminformasi manajemen perpustakaan:

main : Main

login : Login


mp : MengelolaPustaka


mpinjam : MengelolaPeminjaman

p : TPustaka

a : TAnggota


1 : validasiLogin()

2 : memasukkanPustaka()3 : cariPustakaById()4 : cariPustakaByJudul()5 : cariPustakaByJenis()6 : cariPustakaByPengarang()7 : ubahPustaka()8 : hapusPustaka()

9 : memasukkanAnggota()10 : cariAnggotaById()11 : cariAnggotaByNama()12 : mengubahAnggota()13 : menghapusAnggota()

14 : memasukkanPeminjaman()15 : mencariPeminjaman()16 : ubahPeminjaman()

17 : setId()18 : setJudul()19 : setJenis()20 : setJumlah()21 : setTahun()22 : setPengarang()

23 : setId()24 : setNama()25 : setAlamat()26 : setEmail()27 : setTelepon()

28 : setId()29 : setTglPeminjaman()30 : setIdAnggota()31 : setIdPustaka()32 : setTglKembali()

33 : membukaKoneksi()34 : eksekusiQuerySelect()35 : eksekusiQueryUpdate()36 : tutupKoneksi()



Gambar 17 Diagram Kolaborasi Studi Kasus


9-16

Latihan

1. Basica. Apakah yang dimaksud dengan diagram interaksi?b. Apakah kegunaan diagram interaksi dalam analisis dan

desain sistem informasi?c. Apakah yang dimaksud dengan sequence diagram dan

collaboration diagram, apa perbedaan dan persamaandiantara keduanya?

d. Apakah resiko yang dihadapi jika analisis dan desain sisteminformasi tidak melakukan pemodelan dengan diagraminteraksi?

e. Apakah keterkaitan antara diagram interaksi dengan usecase dan diagram kelas?

2. Advanceda. Buatlah sequence diagram untuk sistem informasi apotek!b. Buatlah collaboration diagram untuk sistem informasi

apotek!


Diagram Status 10-1

10 Diagram Status

Overview

Bab ini berisi bagaimana membuat diagram status untuk suatu sisteminformasi. Diagram status digunakan untuk menyatakan kondisi (status)sebuah objek pada saat sistem informasi berjalan.

Tujuan

1. Mahasiswa memahami tujuan penggunaan diagram status.2. Mahasiswa mengetahui bagaimana cara untuk membuat diagram status.3. Mahasiswa mampu membuat diagram status untuk sebuah sistem



10-2

10.1 Pengertian Diagram Status

Diagram status atau state diagram atau statechart diagram menunjukkankondisi yang dapat dialami atau terjadi pada sebuah objek sehingga setiapobjek memiliki sebuah diagram status. Diagram status diadopsi daripenggambaran kondisi mesin status (state machine) yang menggambarkanstatus apa saja yang dialami oleh mesin, misalnya mesin pembelian kopidengan uang koin.

Simbol-simbol yang ada pada diagram status adalah sebagai berikut:

Simbol Deskripsistatus awal / kondisi awal status awal alur sebuah objek,

sebuah diagram status memilikisebuah status awal

status

status

status yang dialami objek selamahidupnya

status akhir / kondisi akhir kondisi akhir alur hidup objek,sebuah diagram status memilikisebuah status akhir

transisi garis transisi antar status pada alurhidup objek, transisi biasanya diberinama pesan yang ada pada diagramsekuen sehingga pesan pada diagramsekuen menjadi transisi bukansebagai status, status merupakankondisi yang dialami objek, bukanmerupakan pesan (message), transisijuga bisa memutar pada sebuahstatus


Diagram Status 10-3

10.2 Studi Kasus Diagram Status

Studi kasus diambil dari sistem informasi manajemen perpustakaan sepertipada bab-bab sebelumnya. Berikut adalah diagram status dari setiap objekpada diagram objek sistem informasi manajemen perpustakaan:

Objek: login dari kelas Login

menunggu masukan username dan password

menerima masukan username dan password

username dan password

validasiLogin()

Objek: main dari kelas Main

menunggu masukan/even dari user

memulai proses yang diminta

uiLogin()

uiMenu()

uiMengelolaPustaka()/ uiMengelolaAnggota()/ uiMengelolaPeminjaman()


10-4

Objek: mp dari kelas MengelolaPustaka

menunggu masukan

menampilkan pesan dan menunggu even

cariPustakaById()/ cariPustakaByJudul()/ cariPustakaByJenis()/ cariPustakaByPengarang()

ubahPustaka() / hapusPustaka()

memasukkanPustaka()/ cariPustakaById()/ cariPustakaByJudul()/ cariPustakaByJenis()/ cariPustakaByPengarang()

Objek: ma dari kelas MengelolaAnggota

menunggu masukan


cariAnggotaById() / cariAnggotaByNama()

mengubahAnggota() / menghapusAnggota()memasukkanAnggota() / cariAnggotaById() / cariAnggotaByNama()


Diagram Status 10-5

Objek: mpinjam dari kelas MengelolaPeminjaman

menunggu masukan


mencariPeminjaman()

ubahPeminjaman()memasukkanPeminjaman() / mencariPeminjaman()

Objek: db dari kelas KoneksiBasisData

menunggu

eksekusi selesai

membukaKoneksi()

eksekusiQuerySelect() / eksekusiQueryUpdate()

tutupKoneksi()


10-6

Objek: p dari kelas TPustaka, a dari kelas TAnggota, pinjam dari kelasTPeminjaman

menunggumetode get dan set atribut

\


Diagram Status 10-7

Latihan

1. Basica. Apakah yang dimaksud dengan state diagram?b. Apa kegunaan state diagram?

2. Advanceda. Kapan (dalam kondisi seperti apa) state diagram sebaiknya

digunakan?a. Buatlah state diagram untuk sistem informasi apotek!


Diagram Aktivitas 11-1

11 Diagram Aktivitas

Overview

Bab ini berisi cara untuk membuat diagram aktivitas. Diagram aktivitasdigunakan untuk menggambarkan proses bisnis (alur kerja) suatu sisteminformasi

Tujuan

1. Mahasiswa memahami tujuan penggunaan diagram aktivitas.2. Mahasiswa mengetahui bagaimana cara untuk membuat diagram

aktivitas sebuah sistem informasi.3. Mahasiswa mampu membuat diagram aktivitas sebuah sistem informasi

yang sederhana.


11-2

11.1 Pengertian Diagram Aktivitas

Diagram aktivitas atau activity diagram menggambarkan workflow (alirankerja) atau aktivitas dari sebuah sistem atau proses bisnis. Yang perludiperhatikan disini adalah bahwa diagram aktivitas menggambarkan aktivitassistem bukan apa yang dilakukan aktor, jadi aktivitas yang dapat dilakukanoleh sistem.

Diagram aktivitas juga banyak digunakan untuk mendefinisikan hal-halberikut:

rancangan proses bisnis dimana setiap urutan aktivitas yangdigambarkan merupakan proses bisnis sistem yang didefinisikan

urutan atau pengelompokan tampilan dari sistem / user interfacedimana setiap aktivitas dianggap memiliki sebuah rancanganantarmuka tampilan

rancangan pengujian dimana setiap aktivitas dianggap memerlukansebuah pengujian yang perlu didefinisikan kasus ujinya

Berikut adalah simbol-simbol yang ada pada diagram aktivitas:

Simbol Deskripsistatus awal status awal aktivitas sistem,

sebuah diagram aktivitasmemiliki sebuah status awal

aktivitas

aktivitas

aktivitas yang dilakukan sistem,aktivitas biasanya diawali dengankata kerja

percabangan / decision asosiasi percabangan dimana jikaada pilihan aktivitas lebih darisatu

penggabungan / join asosiasi penggabungan dimana



Simbol Deskripsilebih dari satu aktivitasdigabungkan menjadi satu

status akhir status akhir yang dilakukansistem, sebuah diagram aktivitasmemiliki sebuah status akhir

swimlane

atau

memisahkan organisasi bisnisyang bertanggung jawabterhadap aktivitas yang terjadi


11-4

11.2 Studi Kasus Diagram Aktivitas

Studi kasus diambil dari sistem informasi manajemen perpustakaan sepertipada bab-bab sebelumnya. Berikut adalah diagram aktivitas dari sisteminformasi manajemen perpustakaan:

Login

Menampilkan Menu

Mengelola Pustaka Mengelola Anggota Mengelola Peminjaman

Mencari Pustaka

Gambar 18 Diagram Interaksi Studi Kasus



Jika digambar dengan menggunakan swimlane maka akan menjadi sebagaiberikut:

Petugas Perpustakaan Pengunjung / Anggota Perpustakaan

Login

Menampilkan Menu

Mengelola Pustaka Mengelola Anggota Mengelola Peminjaman

Mencari Pustaka

Gambar 19 Diagram Aktivitas dengan Swimlane


11-6

Latihan

1. Basica. Apakah yang dimaksud dengan activity diagram?b. Apa kegunaan activity diagram?c. Apakah yang dimaksud dengan swimlane pada activity

diagram?2. Advanced

a. Kapan (dalam kondisi seperti apa) activity diagramsebaiknya digunakan?

b. Buatlah activity diagram untuk sistem informasi apotek!


Diagram Komponen 12-1

12 Diagram Komponen

Overview

Bab ini berisi mengenai cara untuk membuat diagram komponen padasistem informasi. Diagram komponen digunakan untuk menggambarkankomponen-komponen yang ada pada sistem informasi.

Tujuan

1. Mahasiswa memahami tujuan penggunaan diagram komponen.2. Mahasiswa mengetahui bagaimana cara untuk membuat diagram

komponen.3. Mahasiswa mampu merancang diagram komponen untuk sebuah sistem



12-2

12.1 Pengertian Diagram Komponen

Diagram komponen atau component diagram dibuat untuk menunjukkanorganisasi dan ketergantungan diantara kumpulan komponen dalam sebuahsistem. Diagram komponen fokus pada komponen sistem yang dibutuhkandan ada di dalam sistem. Diagram komponen juga dapat digunakan untukmemodelkan hal-hal berikut:

source code program perangkat lunak komponen executable yang dilepas ke user basis data secara fisik sistem yang harus beradaptasi dengan sistem lain framework sistem, framework pada perangkat lunak merupakan

kerangka kerja yang dibuat untuk memudahkan pengembangan danpemeliharaan aplikasi, contohnya seperti Struts dari Apache yangmenggunakan prinsip desain Model-View-Controller (MVC)dimana source code program dikelompokkan berdasarkan fungsinyaseperti pada gambar berikut:

server

Controller

View

Model

client

aplikasi client

Gambar 20 Ilustrasi Framework

Dimana controller berisi source code yang menangani request danvalidasi, model berisi source code yang menangani manipulasi datadan business logic, dan view berisi source code yang menanganitampilan.



Komponen dasar yang biasanya ada dalam suatu sistem adalah sebagaiberikut:

Komponen user interface yang menangani tampilan Komponen bussiness procesiing yang menangani fungsi-fungsi proses

bisnis Komponen data yang menangani manipulasi data Komponen security yang menangani keamanan sistem

Komponen lebih terfokus pada penggolongan secara umum fungsi-fungsiyang diperlukan.

Berikut adalah simbol-simbol yang ada pada diagram komponen:

Simbol DeskripsiPackage

package

package merupakan sebuahbungkusan dari satu atau lebihkomponen

Komponen

nama_komponen

Komponen sistem

Kebergantungan / dependency Kebergantungan antar komponen,arah panah mengarah padakomponen yang dipakai

Antarmuka / interface

nama_interface

sama dengan konsep interface padapemrograman berorientasi objek,yaitu sebagai antarmuka komponenagar tidak mengakses langsungkomponen

Link relasi antar komponen


12-4

12.2 Studi Kasus Diagram Komponen

Studi kasus diambil dari sistem informasi manajemen perpustakaan sepertipada bab-bab sebelumnya. Berikut adalah diagram komponen dari sisteminformasi manajemen perpustakaan:

server

data

user interface

business processing security

Gambar 21 Diagram Komponen Studi Kasus



Latihan

1. Basica. Apakah yang dimaksud dengan component diagram?b. Apa kegunaan component diagram?c. Apakah yang dimaksud dengan MVC dan apa fungsinya?

2. Advanceda. Kapan (dalam kondisi seperti apa) component diagram

sebaiknya digunakan?b. Buatlah component diagram untuk sistem informasi

apotek!


Diagram Deployment 13-1

13 Diagram Deployment

Overview

Bab ini berisi mengenai cara membuat diagram deployment. Diagramdeployment digunakan untuk menggambarkan konfigurasi komponen padasaat instalasi sistem informasi.

Tujuan

1. Mahasiswa memahami tujuan penggunaan diagram deployment.2. Mahasiswa mengetahui cara untuk membuat digram deployment pada

suatu sistem informasi.3. Mahasiswa mampu merancang diagram deployment untuk sebuah sistem



13-2

13.1 Pengertian Diagram Deployment

Diagram deployment atau deployment diagram menunjukkan konfigurasikomponen dalam proses eksekusi aplikasi. Diagram deployment juga dapatdigunakan untuk memodelkan hal-hal berikut:

sistem tambahan (embedded system) yang menggambarkanrancangan device, node, dan hardware.

sistem client/server misalnya seperti gambar berikut:

server

php server

business processcomponents

printer

client

browser

Gambar 22 Diagram Deployment Sistem Client / Server

sistem terdistribusi murni rekayasa ulang aplikasi

Berikut adalah simbol-simbol yang ada pada diagram deployment:

Simbol DeskripsiPackage

package

package merupakan sebuahbungkusan dari satu atau lebih node

Node

nama_node

biasanya mengacu pada perangkatkeras (hardware), perangkat lunakyang tidak dibuat sendiri (software),jika di dalam node disertakankomponen untuk mengkonsistenkanrancangan maka komponen yangdiikutsertakan harus sesuai dengan


Diagram Deployment 13-3

Simbol Deskripsikomponen yang telah didefinisikansebelumnya pada diagramkomponen

Kebergantungan / dependency Kebergantungan antar node, arahpanah mengarah pada node yangdipakai

Link relasi antar node

13.2 Studi Kasus Diagram Deployment

Studi kasus diambil dari sistem informasi manajemen perpustakaan sepertipada bab-bab sebelumnya. Berikut adalah diagram deployment dari sisteminformasi manajemen perpustakaan:

Server

php server

user interfacebusiness processingsecurity

components

MySQL

datacomponents

Gambar 23 Diagram Deployment Studi Kasus

Aplikasi di-deploy pada sebuah komputer server dimana di dalamnya sudahterdapat php server dan MySQL sebagai DBMS.


13-4

Latihan

1. Basica. Apakah yang dimaksud dengan deployment diagram?b. Apa kegunaan deployment diagram?c. Apakah perbedaan antara component diagram dengan

deployment diagram?2. Advanced

a. Kapan (dalam kondisi seperti apa) deployment diagramsebaiknya digunakan?

b. Buatlah deployment diagram untuk sistem informasiapotek!


Daftar Pustaka

Booch, Grady. 1998. Object-oriented analysis and design with applications2nd edition. Addison Wesley.

Bowman, Kevin. 2004. System Analysis: A Beginner’s Guide. PalgraveMacmillan.

Knudson, Joan dan Ira Bitz. 1991. Project Management. Amacom.Langer, Arthur M. 2008. Analysis and Design of Information Systems 3rd

edition. Springer.Pressman, Roger S. 2001. Software Engineering: A Practitioner’s Approach

fifth edition. Mc Graw Hill.Rumbaugh, James dkk. 1999. The Unified Modeling Language Reference

Manual. Addison-Wesley.Shalahuddin, Muhammad dan Rosa Ariani S. 2007. Belajar Pemrograman

dengan Bahasa Pemrograman C++ dan Java: Dari Nol Menjadi Handal.Penerbit Informatika.

analisis dan desain sistem informasi filebidang akademik & pengembangan. politeknik telkom...

Documents