2. Prototipe-prototipe RAD dapat dengan mudah memecahkan yang
salah karena analisis masalah disingkat atau diabaikan.
3. Prototipe berbasis RAD mungkin membuat para analis minder
untuk mempertimbangkan alternatif-alternatif teknis lain yang lebih bernilai.
4. Kadang-kadang lebih baik membuang sebuah prototipe, tapi para
stakeholder enggan melakukannya karena menganggapnya sebagai hilangnya waktu dan usaha dalam produk saat ini.
5. Penekanan pada kecepatan dapat berdampak terhadap kualitas yang
disebabkan jalan-jalan pintas yang disarankan dengan buruk melalui metodologi tersebut.
2.7 Object Oriented Analysis OOA
OOA adalah pendekatan yang digunakan untuk mempelajari objek yang sudah ada untuk mengetahui apakah mereka dapat digunakan kembali atau
diadopsi untuk pemakaian baru. Atau menentukan satu objek baru atau yang dimodifikasi yang akan digabung dengan objek yang sudah ada ke dalam suatu
aplikasi komputasi bisnis yang sangat berharga Whitten, 2004.
OOA adalah suatu pendekatan yang digunakan untuk mempelajari objek- objek yang sudah ada untuk digunakan kembali dan disesuaikan untuk
penggunaannya yang baru. Selain itu, OOA juga dapat digunakan untuk membuat objek baru atau bisa juga untuk merubah objek yang sudah ada untuk dipadukan
dengan objek-objek lainnya sehingga membentuk suatu aplikasi bisnis yang berdaya guna tinggi Whitten, 2004.
2.8 Object Oriented Design OOD
Object Oriented Design OOD adalah suatu pendekatan yang digunakan untuk menentukan solusi terbaik bagi piranti lunak dalam hal perpaduan objek
objects, atribut attributes dan method methods. Perancangan suatu piranti lunak berorientasi objek membutuhkan penggunaan arsitektur piranti lunak
berlapis multilayered software architecture, juga membutuhkan spesifikasi dari subsistem yang menyediakan fungsi- fungsi functions yang dibutuhkan. Selain
itu, gambaran tentang penggunaan objek yang membentuk sistem dan gambaran mekanisme komunikasi yang memungkinkan aliran data mengalir melalui lapisan
layers, subsistem dan objek juga dibutuhkan. Semua itu dilakukan dan diselesaikan dengan menggunakan pendekatan OOD Whitten, 2004.
OOAD merupakan sekumpulan petunjuk umum yang mengarahkan kepada aktivitas analisis dan perancangan. Untuk membuat metode kita menjadi
lebih berguna, kita merancangnya hingga terdapat penyesuaian, perkembangan, dan substitusi bagian dapat dengan mudah diimplementasikan Mathiassen, 2000.
Terdapat 4 aktivitas utama yang digunakan dalam menggunakan metode Unified Software Deployment untuk OOAD Object Oriented Analysis and
Design Mathiassen, 2000. Yaitu :
1. Problem Domain Analysis
Dalam tahapan ini sistem dirancang sesuai dengan kebutuhan informasi dari pengguna, tahapan ini menentukan hasil dari keseluruhan aktivitas analisis
dan perancangan. Tahapan dari Problem Domain Analysis ini adalah : a Menentukan Class yang ada dalam sistem dengan melakukan proses
identifikasi dari definisi sistem yang telah dikembangkan. b Menganalisa dan mengembangkan struktur hubungan dari class – class yang
ada. c Menganalisa Behavior dari class – class tersebut.untuk menentukan state
dari setiap class yang termasuk dalam sistem ini. Hasil laporan perancangan yang dihasilkan dari tahapan ini adalah :
a System Definition : mendefinisikan seluruh sistem sebagai sebuah model yang akan dilihat user saat sistem jadi.
b Class Diagram : untuk menggambarkan hubungan antara class-class dalam sebuah sistem.
c State Diagram : untuk menggambarkan bagaimana state dari daur hidup kelas yang ada di dalam sistem ini.
Dapat dilihat dari tahap ini telah dapat dilihat model aplikasi secara keseluruhan bagaimana aplikasi tersebut akan terbentuk.
2. Application Domain Analysis
Tahapan ini berfokus pada bagaimana sistem akan digunakan oleh pengguna. Tahap ini dan tahap sebelumnya dapat dimulai secara bergantian,
tergantung pada kondisi pengguna. Terdapat 3 tahapan yang akan dilakukan dalam Application Domain Analysis Mathiassen, 2000, yaitu:
a Menentukan usage, yaitu menentukan Aktor dan use case yang terlibat dan interaksinya.
b Menentukan fungsi sistem untuk memproses informasi dan membuat daftar fungsi.
c Menentukan interface pengguna dan sistem, untuk interaksi sesungguhnya dari pengguna dan sistem informasi yang dirancang.
Laporan yang akan dihasilkan dari tahapan ini adalah : a Use Case Diagram, yang menggambarkan interaksi pengguna sebagai aktor
dengan sistem informasi. b Function List, yaitu kemampuan yang harus dimiliki sistem sebagai
kebutuhan dasar dari user. c User Interface Navigation Diagram, yaitu diagram untuk menggambarkan
tampilan layar yang akan dirancang untuk memenuhi kebutuhan user.
3. Architectural Design
Dalam tahap ini dirancang arsitektur hubungan antara client dan server yang memadai untuk sistem agar dapat berjalan baik. Perancangan tahap ini
menentukan bagaimana struktur sistem fisik akan dibuat dan bagaimana distribusi sistem informasi pada rancangan fisik tersebut. Laporan yang dihasilkan adalah
Deployment Diagram.
4 .
Component Design
Tahap terakhir dalam Unified Software Deployment sebelum melakukan programming. Sistem akan dimodelkan secara lengkap dalam diagram yang
disebut programming. Sistem akan dimodelkan secara lengkap dalam diagram
yang disebut sebagai Component Diagram. Di tahap ini terlihat bagaimana sistem bekerja dan interaksi yang terjadi antara sistem dan pengguna.
2.9 Konsep Dasar UML
Unified Modelling Language 2.9.1
Definisi dan Sejarah UML Unified Modelling Language 2.9.2
UML Unified Modeling Language
UMLUnified Modelling Language adalah salah satu alat bantu yang handal di dunia pengembangan sistem yang berorientasi obyek. Hal
ini disebabkan karena UML menyediakan bahasa pemodelan visual yang memungkinkan bagi pengembangan sistem untuk membuat cetak biru atas
visi mereka dalam bentuk yang baku, mudah dimengerti serta dilengkapi dengan mekanisme yang efektif untuk berbagi sharing dan
mengkomunikasikan rancangan mereka dengan yang lain Munawar,
2005.
UML merupakan kesatuan dari bahasa pemodelan yang dikembangkan oleh Grady Booch, OMT Object Modelling Technique
dan OOSE Object-Oriented Software Engineering. Metode Grady Booch dari Rational Software Co. sangat terkenal dengan nama metode Design
Object-Oriented. Metode Booch ini menjadikan proses analisis dan design ke dalam tahapan iterative, yaitu: identifikasi kelas-kelas dan
objek-objek, identifikasi semantik dari hubungan objek dan kelas tersebut, perincian interface dan implementasi. Keunggulan metode Booch adalah
pada detil dan kayanya dengan notasi dan elemen.
Pemodelan OMT yang dikembangkan oleh James Rumbaugh General Electric didasarkan pada analisis terstruktur dan pemodelan entity
relationship. Tahapan utama dalam metodologi ini adalah analisis, desain sistem, desain objek dan implementasi. Keunggulan metode ini adalah
dalam penotasian yang mendukung semua konsep OO.
Metode OOSE dari Jacobson lebih memberi penekanan pada Use Case. OOSE memiliki tiga tahapan yaitu membuat model requirement dan
analisis, design dan implementasi dan model pengujian test model. Keunggulan metode ini adalah mudah dipelajari karena memiliki notasi
yang sederhana namun mencakup seluruh tahapan dalam rekayasa
perangkat lunak Munawar, 2005.
Pendekatan Analisis perancangan dengan menggunakan model OO mulai diperkenalkan sekitar pertengahan 1970 hingga akhir 1980
dikarenakan pada saat itu aplikasi software sudah meningkat dan mulai kompleks. Jumlah yang menggunakaan metode OO mulai diuji cobakan
dan diaplikasikan antara 1989 hingga 1994.
Kelemahan saat itu disadari oleh Booch maupun Rumbaugh adalah tidak adanya standar penggunaan model yang berbasis OO, ketika mereka
bertemu ditemani rekan lainnya Ivar Jacobson dari Objectory mulai mendiskusikan untuk mengadopsi masing-masing pendekatan metode OO
untuk membuat suatu model bahasa yang uniformseragam yang disebut UML Unified Modeling Language dan dapat digunakan oleh seluruh
dunia.
Secara resmi bahasa UML dimulai pada bulan Oktober 1994, ketika Rumbaugh bergabung Booch untuk membuat sebuah proyek
pendekatan metode yang uniformseragam dari masing-masing metode mereka. Saat itu baru dikembangkan draft metoda UML version 0.8 dan
diselesaikan serta di release pada bulan Oktober 1995. Bersamaan dengan saat itu, Jacobson bergabung dan UML tersebut diperkaya ruang
lingkupnya dengan metode OOSE sehingga muncul release version 0.9 pada bulan Juni 1996. Hingga saat ini sejak Juni 1998 UML version 1.3
telah diperkaya dan direspon oleh OMG Object Management Group, Anderson Consulting, Ericsson, Platinum Technology, ObjectTime
Limited, dll serta dipelihara oleh OMG yang dipimpin oleh Cris Kobryn.
UML adalah hasil kerja dari konsorsium berbagai organisasi yang berhasil dijadikan sebagai standar baku dalam OOAD Object Oriented
Analysis Design. Kontribusi untuk UML telah dihasilkan dari banyak
perusahaan-perusahaan ternama
Diantaranya Digital Equipment Corp, Hewlet-Packard Company, i- Logic, Intellicorp, IBM, Icon Computing, Electric Data Service
Corporation, MCI Systen House, Microsoft, Oracle, Rational Software, TI, Sterling Software, Taskon AS, Unisys Platinum Technologies, Ptech,
Taskon Reich Technologies dan Softeam.
Sebagai sebuah notasi grafis yang relatif sudah dibakukan open standard dan dikontrol oleh OMGObject Management Group – Mungkin
lebih dikenal sebagai badan yang berhasil membakukan CORBA – Comon
Object Request Broker Architecture, UML menawarkan banyak keistimewaan. UML tidak hanya dominan dalam penotasian di lingkungan
OO tetapi juga populer di luar lingkungan OO. Paling tdak ada tiga karakter penting yang melekat di UML yaitu sketsa, cetak biru dan bahasa
pemrograman. Sebagai sebuah sketsa, UML bisa berfungsi sebagai jembatan dalam mengkomunikasikan beberapa aspek dari sistem. Dengan
demikian semua anggota tim akan mempunyai gambaran yang sama tentang suatu sistem. UML bisa juga berfungsi sebagai sebuah cetak biru
karena sangat lengkap dan detil. Dengan cetak biru ini maka akan bisa diketahui informasi detil tentang coding program forward engineering
atau bahkan membaca program dan menginterpretasikannya kembali ke dalam diagram reverse engineering. Reverse engineering sangat berguna
pada situasi dimana kode program yang tidak terdokumentasi akan dimodifikasidipelihara. Hal ini bisa terjadi ketika dokumentasi asli hilang
atau bahkan belum dibuat sama sekali. Sebagai bahasa pemograman, UML dapat menterjemahkan diagram yang ada di UML, menjadi kode program
yang siap untuk dijalankan.
2.9.3 Diagram UML
Unified Modeling Language
UML menawarkan diagram yang dikelompokkan menjadi lima perspektif berbeda untuk memodelkan suatu sistem. Diagram UML
menyajikan perspektif yang berbeda mengenai sistem informasi. Bagian berikut menjelaskan berbagai diagram UML beserta pengertiannya
Whitten, 2004.
a Use Case Diagram
Use case diagram adalah diagram yang menggambarkan interaksi antara sistem dengan sistem eksternal dan pengguna. Dengan kata lain,
secara grafis menggambarkan siapa yang akan menggunakan sistem dan dengan cara apa pengguna mengharapkan untuk berinteraksi dengan
sistem Whitten, 2004.
UseCase1 UseCase2
UseCase3 Actor1
Actor2 Actor3
System
Gambar 2.4 Contoh Diagram Model Use Case
Sumber : Whitten, 2004
Sebuah use case diagram melukiskan:
1. Actor
Actor merupakan istilah yang digunakan untuk menggambarkan pengguna aplikasi atau apapun yang berinteraksi dengan sistem
untuk mengolah informasi. Actor bisa berupa orang, hardware, atau sistem informasi lain yang berinteraksi dengan use case.
2. Use case
Use case menggambarkan fungsi sistem dari perspektif user eksternal dengan cara yang mereka pahami. Use case dibuat
berdasarkan proses-proses yang dilakukan untuk kepentingan actor untuk menggambarkan apa yang dikerjakan oleh aplikasi, bukan
bagaimana aplikasi mengerjakannya logical.
3. Relationship
Relationship dilukiskan sebagai garis lurus antara dua simbol pada use-case diagram. Makna dari relationship berbeda, tergantung
pada bagaimana garis lurus digambarkan dan apa jenis simbol yang dihubungkan. Berikut ini adalah perbedaan relationship pada use-
case diagram:
a. Association
Association merupakan relationship antara actor dengan use case, digambarkan sebagai sebuah garis lurus tanpa putus
antara actor dan use case.
b. Extends
Extends digunakan untuk menggambarkan hubungan antar use case yang menunjukkan bahwa satu use case merupakan
fungsionalitas dari use case yang lain jika kondisi atau syarat tertentu dipenuhi.
c. Uses includes
Hubungan uses menggambarkan bahwa satu use case seluruhnya meliputi fungsionalitas dari use case lainnya.
d. Depends on
Hubungan depends on sangat membantu untuk mengetahui use case mana yang memiliki ketergantungan pada use case
lainnya yang bertujuan untuk menentukan urutan dalam pengembangan use case.
e. Inheritance
Hubungan inheritance terjadi ketika dua atau lebih actor menggunakan use case yang sama.
Setiap use case pada use case diagram dijelaskan secara detail pada documenting abstract and extension use-case narratives. Whitten, 2004.
b Use Case Narrative
Deskripsi tekstual kegiatan bisnis dan bagaimana pengguna akan berinteraksi dengan sistem dalam menyelesaikan suatu tugas.
Berbeda dengan use case diagram, use case desain sistem menggunakan sebuah narasi dari pandangan pengguna sistem, use
case desain sistem lebih bersifat percakapan dialog.
c Activity Diagram
Secara grafis digunakan untuk menggambarkan rangkaian aliran aktivitas baik proses bisnis atau use case. Diagram ini juga dapat
digunakan untuk memodelkan action yang akan dilakukan saat sebuah operasi di eksekusi, dan memodelkan hasil dari action
tersebut,
d Class Diagram
Diagram ini menunjukkan kelas objek yang menyusun sistem juga hubungan antara kelas tersebut. Class diagram mendeskripsikan
jenis-jenis objek dalam sistem dan berbagai macam hubungan dan
interaksi diantara mereka. Berikut ini adalah gambar simbol dari class diagram :
e Sequence Diagram
Secara grafis menggambarkan bagaimana objek berinteraksi dengan satu sama lain melalui pesan pada eksekusi sebuah use case
atau operasi. Diagram ini mengilustrasikan bagaimana pesan terkirim dan diterima diantara objek.
f Statechart Diagram
Digunakan untuk memodelkan behaviour objek khusus yang dinamis. Diagram ini mengilustrasikan siklus hidup objek, berbagai
keadaan yang dapat diasumsikan oleh objek, dan event-event yang menyebabkan objek beralih dari satu state ke state lain.
2.10 Database dan
Kategori