7 BAB 2 LANDASAN TEORI 2.1. Rekayasa Perangkat Lunak (RPL) Pada bagian ini, akan dijelaskan definisi perangkat lunak (software), definisi rekayasa perangkat lunak, proses rekayasa perangkat lunak, OOAD dan UML. 2.1.1. Pengertian Perangkat Lunak Menurut Pressman (2001,p6), yang dimaksud dengan perangkat lunak adalah: a. Kumpulan instruksi (program komputer) yang jika dieksekusi akan menyediakan fungsi dan dayaguna yang diinginkan (instructions of computer programs that when excuted provide desired function and perfomance). b. Kumpulan struktur data yang memungkinkan program untuk memanipulasi informasi secukupnya (data stuctures that enable the programs to adequately manipulate information). c. Kumpulan dokumen yang menggambarkan operasi dan penggunaan program (documents that describe the operation and use of the programs). Sommerville (2001,p5) mendefinisikan perangkat lunak tidak hanya berupa program tetapi juga semua dokumen yang berhubungan dan data konfigurasi yang
33
Embed
BAB 2 LANDASAN TEORI 2.1. Rekayasa Perangkat Lunak (RPL ...
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
7
BAB 2
LANDASAN TEORI
2.1. Rekayasa Perangkat Lunak (RPL)
Pada bagian ini, akan dijelaskan definisi perangkat lunak (software),
definisi rekayasa perangkat lunak, proses rekayasa perangkat lunak, OOAD dan
UML.
2.1.1. Pengertian Perangkat Lunak
Menurut Pressman (2001,p6), yang dimaksud dengan perangkat lunak
adalah:
a. Kumpulan instruksi (program komputer) yang jika dieksekusi akan menyediakan
fungsi dan dayaguna yang diinginkan (instructions of computer programs that
when excuted provide desired function and perfomance).
b. Kumpulan struktur data yang memungkinkan program untuk memanipulasi
informasi secukupnya (data stuctures that enable the programs to adequately
manipulate information).
c. Kumpulan dokumen yang menggambarkan operasi dan penggunaan program
(documents that describe the operation and use of the programs).
Sommerville (2001,p5) mendefinisikan perangkat lunak tidak hanya berupa
program tetapi juga semua dokumen yang berhubungan dan data konfigurasi yang
8
just the program but also all associated document and configuration data which is
needed to make these programs operate correctly).
2.1.2. Pengertian Rekayasa Perangkat Lunak
Definisi rekayasa perangkat lunak menurut Pressman (2001,p20) adalah
pembuatan dan penggunaan prinsip-prinsip keahlian teknik untuk mendapatkan
perangkat lunak yang ekonomis, handal dan bekerja secara efisien pada mesin yang
sesungguhnya (software engineering is the establishment and the use of sound
engineering principles in order to obtain economically software that is reliable and
works efficiently on real machines).
Menurut Sommerville (2001,p6), rekayasa perangkat lunak adalah sebuah
prinsip tentang perekayasaan yang berhubungan dengan semua aspek dari
pembuatan perangkat lunak dari tahap awal spesifikasi sistem sampai perawatan
sistem setelah memasuki tahap penggunaan (an engineering discipline which is
concerned with all aspect of software productions from the early stage of system
specification to maintaning the system after it has gone into use ).
9
2.1.3. Lapisan dalam RPL
Menurut Pressman (2001, p23-24), secara umum Rekayasa Perangkat
Lunak dapat dibagi menjadi tiga layer dan seperti terlihat pada Gambar 2.1, antara
lain :
a. Process Model adalah fondasi dari RPL yang mendefinisikan sebuah framework
untuk sekumpulan key process area yang harus dibangun demi keefektifan
penyampaian teknologi pengembangan RPL.
b. Methods menyediakan secara teknis bagaimana untuk membangun suatu
perangkat lunak.
c. Tools menyediakan dukungan otomatis dan semi otomatis untuk process model
dan methods.
d. Quality focus merupakan batu landasan yang menopang tools, methods dan
process dalam RPL.
Gambar 2.1 Lapisan Rekayasa Perangkat Lunak
10
2.1.4. Model Proses Software
Menurut Pressman (2001, p29-47), ada beberapa model proses software
yang umum digunakan, salah satunya adalah Model Sekuensial Linear Model.
Sekuensial Linear ini juga dikenal dengan nama “Classic Life Cycle” atau
“Waterfall Model”. Model ini melingkupi aktivitas-aktivitas seperti ditunjukkan
pada Gambar 2.2.
Gambar 2.2 Waterfall Model
a. Rekayasa dan Pemodelan Sistem Informasi
Rekayasa dan pemodelan sistem informasi diperlukan karena perangkat lunak
selalu merupakan bagian dari sebuah sistem yang lebih besar, kerja dimulai
dengan membangun syarat dari semua elemen sistem dan mengalokasikan
beberapa subset dari kebutuhan ke perangkat lunak tersebut. Perangkat lunak
System Engineering
Analysis
Design
Coding
Testing
Maintenance / Operation
11
harus berhubungan dengan elemen-elemen yang lain seperti perangkat lunak,
manusia, dan database.
b. Analisis kebutuhan perangkat lunak
Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khususnya pada
perangkat lunak. Untuk memahami sifat program yang dibangun, seorang
perancang perangkat lunak harus memahami kebutuhan informasi, fungsi-fungsi,
unjuk kerja, dan interface yang diperlukan.
c. Perancangan
Design perangkat lunak sebenarnya adalah proses multi langkah yang berfokus
pada empat attribute sebuah program yang berbeda : struktur data, arsitektur
perangkat lunak, representasi interface dan detail (algoritma).
d. Pengkodean
Design harus diterjemahkan menjadi bentuk yang dapat dibaca atau dimengerti
oleh komputer, biasanya dalam bentuk bahasa pemrograman.
e. Pengujian
Sekali kode dibuat, pengujian program juga dimulai. Proses pengujian berfokus
pada logika internal perangkat lunak, memastikan bahwa semua pernyataan
sudah diuji, dan pada eksternal fungsional yaitu mengarahkan pengujian untuk
menemukan kesalahan-kesalahan dan memastikan bahwa input yang dibatasi
akan memberikan hasil aktual yang sesuai dengan hasil yang dibutuhkan.
12
f. Pemeliharaan
Perangkat lunak akan mengalami perubahan setelah disampaikan kepada
pelanggan. Perubahan akan terjadi karena kesalahan-kesalahan ditentukan,
karena perangkat lunak harus disesuaikan untuk mengakomodasikan perubahan-
perubahan di dalam lingkungan eksternalnya, atau pelanggan membutuhkan
perkembangan fungsional atau unjuk kerja. Pemeliharaan perangkat lunak
mengaplikasi lagi setiap fase sebelumnya, lalu memperbaiki program
sebelumnya dan tidak membuat yang baru lagi.
2.1.5. Analisis dan Perancangan Berorientasi Objek (Object-Oriented Analysis
and Design / OOAD)
Paradigma berorientasi objek (object-oriented) (Lethbridge dan Laganiere,
2002, p29) adalah sebuah pendekatan pada solusi dari masalah-masalah yang
pekerjaannya dilakukan dalam konteks objek (the object-oriented paradigm is an
approach to the solution of problems in which all computations are performed in the
context of object).
Analisis dan perancangan berorientasi objek mengaplikasikan teknik
pemodelan objek untuk menganalisis kebutuhan pada sebuah konteks, seperti sebuah
sistem, kumpulan modul pada sistem, sebuah organisasi atau unit bisnis, dan
mendesain solusinya (Anonim, 2006).
13
a. Analisis Berorientasi Objek (Object-Oriented Analysis / OOA)
Analisis berorientasi objek (Whitten et. al., 2004, p190) adalah teknik model-
driven yang mengintegrasikan data dan proses menjadi sebuah konsep yang disebut
objek (a model-driven technique that integrates data and process concerns into
construct called objects). OOA adalah gambaran yang mengilustrasikan objek
sistem dari berbagai perspektif, seperti struktur, fungsi, dan interaksi antar objek.
Analisis berorientasi objek (Booch et. al., 2005, p39) adalah sebuah metode
analisis yang memeriksa persyaratan dari sudut pandang kelas dan objek yang
ditemukan pada kosakata dari masalah yang utama (object-oriented analysis is a
method of analysis that examines requirements from the perspective of the classes
and objects found in the vocabulary of the problem domain).
Proses OOA terdiri dari (Bahrami, 1999, p80) :
1. Mengidentifikasi aktor
2. Membuat sebuah model proses bisnis yang sederhana menggunakan UML
Activity Diagram
3. Membuat Use case
4. Membuat interaction diagram
5. Mengidentifikasi kelas
14
b. Perancangan Berorientasi Objek (Object-Oriented Design / OOD)
Perancangan berorientasi objek (Whitten et. al., 2004, p686) adalah sebuah
pendekatan yang digunakan untuk menentukan perangkat lunak solusi dalam
kaitannya dengan pemakaian objek, atribut (attribute) dan fungsinya secara
bersamaan (an approach used to specify the software solution in terms of
collaborating objects, their attributes and their methods).
Perancangan berorientasi objek (Bootch et. al., 2005, p39) adalah sebuah
metode desain yang meliputi proses pemecahan berbasis objek dan sebuah notasi
untuk menggambarkan model logikal dan fisikal maupun statis dan dinamis dari
sistem yang didesain (object-oriented design is a method of design encompassing
the process of objects oriented decomposition and a notation for depicting both
logical and physical as well as static and dynamic models of the system under
design).
Proses OOD terdiri dari (Bahrami, 1999, p80):
1. Mendesain kelas, atributnya, fungsinya, hubungan asosiasi, struktur dan
protokol, mengaplikasikan istilah desain.
2. Mendesain access layer.
3. Mendesain dan membuat prototipe dari rancangan antarmuka untuk pengguna.
4. Menguji tingkat kepuasan dan kegunaan bagi pengguna berdasarkan use case.
5. Mengulang dan memperbaiki desain.
15
2.1.6. Unified Modelling Language (UML)
UML (Whitten et. al., 2004, p430) adalah sekumpulan pemodelan konvensi
yang digunakan untuk menentukan atau menggambarkan sebuah sistem perangkat
lunak dalam kaitannya dengan objek (a set of modeling conventions that is used to
specify or describe a software system in terms of objects).
UML (Lethbridge and Laganiere, 2002, p151) dapat juga diartikan sebuah
bahasa grafik standar yang digunakan untuk memodelkan perangkat lunak berbasis
objek (a standard graphical languange for modeling object-oriented software).
UML pertama kali dikembangkan pada pertengahan 1990-an dengan kerjasama
antara James Rumbaugh, Grady Booch dan Ivar Jacobson, yang masing-masingnya
telah mengembangkan notasi mereka sendiri diawal 1990-an.
UML terdiri dari berbagai tipe diagram, antara lain :
a. Class Diagram
Kelas (Schmuller, 1999, p8), adalah sebuah kategori atau pengelompokan
dari hal-hal yang mempunyai atribut dan fungsi yang sama (a class is a category or
group of things that have similar attributes and common behaviors).
Class diagram (Rumbaugh et. al., 1999, p190) adalah sebuah grafik
presentasi dari gambaran statis yang menunjukan sekumpulan model elemen yang
terdeklarasi (statis), seperti kelas, tipe dan isinya serta hubungannya (a class
diagram is a graphic presentation of the static view that shows a collection of
16
declarative (static)model elements, such as classes, types and their contents and
relationships).
Sebuah kelas diagram terdiri dari sejumlah kelas yang dihubungkan dengan
garis yang menunjukkan hubungan antarkelas, seperti ditunjukkan pada Gambar 2.3.
<Nama Class>
<attributes1>
<attributes2>
<Operation>()
Gambar 2.3 Class Diagram
b. Object Diagram
Sebuah objek adalah instance dari sebuah kelas, sesuatu yang mempunyai
nilai atribut dan fungsi yang spesifik (Schmuller, 1999, p9). Sebuah object diagram
menunjukkan objek-objek dan hubungannya satu sama lain (Schmuller, 1999,
p120), seperti ditunjukkan pada Gambar 2.4.
<Nama Object> : <Nama Class>
<Attributes1>
<Attributes2>
Gambar 2.4 Object Diagram
17
c. Use Case Diagram
Use case (Schmuller, 1999, p10), adalah sebuah gambaran dari fungsi sistem
yang dipandang dari sudut pandang pemakai (a use case is a description of a
system’s behavior from a user’s standpoint). Contoh use case diagram dapat dilihat
pada Gambar 2.5.
Gambar 2.5 Use Case Diagram
d. Statechart Diagram
Sebuah state diagram (Lethbridge and Laganiere, 2002, p276), merupakan
cara lain untuk mengekspresikan informasi dinamis tentang sebuah sistem, diagram
ini digunakan untuk menggambarkan fungsi eksternal yang terlihat dari sebuah
sistem atau dari sebuah objek secara individu (a state diagram is another way of
expressing dynamic information about a system; it is used to describe the externally
visible behavior of a system or of an individual object). Contoh statechart diagram
dapat dilihat pada Gambar 2.6.
18
Gambar 2.6 Statechart Diagram
e. Activity Diagram
Sebuah Activity Diagram (Lethbridge and Laganiere, 2002, p284), digunakan
untuk mengetahui aliran kerja yang dilakukan oleh sebuah objek atau komponen (an
activity diagram is used to understand the flow of work that an object or component
perform). Contoh activity diagram dapat dilihat pada Gambar 2.7.
Soaking
Washing
Rinsing
Spinning
19
Gambar 2.7 Activity Diagram
f. Sequence Diagram
Sebuah sequence diagram (Lethbrige and Laganiere, 2002, p270),
menunjukkan urutan pertukaran pesan yang dilakukan oleh sekumpulan objek atau
aktor yang mengerjakan perkerjaan tertentu (a sequence diagram shows the
sequence of messages exchanged by the set of objects (and optionally an actor)
20
performing a certain task). Contoh sequence diagram dapat dilihat pada Gambar
2.8.
Gambar 2.8 Sequence Diagram
g. Collaboration Diagram
Sebuah Collaboration Diagram (Lethbridge and Laganiere, 2002, p273),
menunjukkan beberapa objek yang bekerja bersama. Diagram ini merupakan grafik
dengan sekumpulan objek dan aktor sebagai pusatnya (a collaboratiobn diagram
shows several objects working together. It appears as a graph with a set of objects
and actors as the vertices). Contoh collaboration diagram dapat dilihat pada
Gambar 2.9.
21
1.Stop
2.rotate back and forth
Gambar 2.9 Collaboration Diagram
h. Component Diagram
Component diagram menggambarkan kumpulan komponen–komponen dan
hubungan antar komponen tersebut (Booch et al, 2005, p107). Component diagram
digunakan untuk mengambarkan implementasi statis dari suatu sistem. Pada Gambar
2.10 terlihat contoh dari component diagram. Notasi yang digunakan dalam
component diagram dapat dilihat Tabel 2.1 (Booch, 2005).
Gambar 2.10 Component Diagram
Internal Timer
Drum Water Pipe
22
Notasi yang digunakan dalam component diagram:
Notasi Keterangan
Component1
Component
Sebuah bagian fisik dan yang dapat tergantikan dari