2.5 Sistem Informasi
2.5.3 Pengembangan Sistem Berorientasi Objek
2.5.3.1 Pendekatan Berorientasi Objek
Menurut Satzinger, Burd dan Jackson (2004, p60), pendekatan berorientasi objek adalah pendekatan dalam pengembangan sistem yang menggambarkan sistem informasi sebagai kumpulan objek – objek yang
saling berinteraksi dan bekerja sama untuk menyelesaikan suatu tugas. Secara konsep, tidak ada proses yang terpisah dengan proses, dan tidak ada entitas data yang terpisah dengan arsip data.
Menurut Whitten & Bentley (2007, p163), pendekatan berorientasi objek adalah sebuah teknik model-driven yang mengintegrasikan kebutuhan data dan proses dalam sebuah konstruksi yang dinamakan objek. Model objek merupakan gambar yang mengilustrasikan objek dari berbagai perspektif seperti struktur, perilaku dan interaksi dari objek.
Jadi dapat disimpulkan bahwa pendekatan berorientasi objek adalah suatu pendekatan pengembangan sistem yang mengintegrasikan sistem informasi dari berbagai perspektif dalam kumpulan objek – objek yang saling terintegrasi.
2.5.3.2 UML (Unified Modeling Language)
Menurut Satzinger, Burd dan Jackson (2004, p48), UML adalah serangkaian standar konstruksi dan notasi yang dikembangkan secara khusus untuk pengembangan berorientasi objek. UML dikembangkan oleh Grady
Booch, James Rumbaugh, dan Ivar Jacobson dari Rational Software
(sekarang telah menjadi bagian dari IBM). Dengan menggunakan UML, analis/pengamat dan pengguna akhir dapat memahami dan mengerti diagram khusus yang digunakan dalam pengembangan sistem. Sebelum adanya UML, tidak ada standarisasi dalam pengembangan sistem, oleh karena itu diagramnya bisa sangat membingungkan, dan akibatnya para analis sering salah mengartikan diagram, sehingga sering terjadi error.
34
2.5.3.3 Event
Menurut Satzinger, Burd, dan Jackson (2004, p167) event merupakan peristiwa yang terjadi di suatu waktu dan tempat yang bisa dijelaskan, dan layak untuk diingat. Event terdiri dari 3, yaitu:
• External Event, yaitu peristiwa yang terjadi di luar sistem, yang
biasanya dilakukan oleh agen eksternal atau actor.
• Temporal Event, yaitu peristiwa yang terjadi pada saat atau waktu
tertentu.
• State Event, yaitu peristiwa yang terjadi ketika sesuatu terjadi di
dalam sistem yang memicu kegiatan pengolahan data.
2.5.3.4 Event Table
Menurut Satzinger, Burd dan Jackson (2004, p174), event table terdiri dari baris dan kolom, dan merupakan katalog dari use case yang mendaftarkan peristiwa dalam baris, dan informasi kunci mengenai peristiwa tersebut dalam kolom.
Gambar 2.5 Event Table
Sumber: Satzinger, Burd dan Jackson (2004, p175)
Event table terdiri dari 5 kolom, yaitu:
• Event, yaitu peristiwa yang menyebabkan sistem untuk melakukan
sesuatu.
• Trigger, yaitu bagaimana sistem mengetahui bahwa peristiwa tersebut
sedang terjadi. Untuk external event, pemicunya adalah data yang masuk ke sistem. Untuk temporal event, ini merupakan definisi dari waktu dimana peristiwa tersebut akan dilaksanakan oleh sistem.
• Source, yaitu agen eksternal yang merupakan sumber dari data yang
akan masuk ke sistem.
• Use Case, yaitu apa yang dilakukan sistem ketika peristiwa ini terjadi.
• Response, yaitu apa hasil yang dikeluarkan sistem.
• Destination, yaitu agen eksternal apa yang mendapatkan hasil yang
36
2.5.3.5 Activity Diagram
Menurut Satzinger, Jackson, dan Burd (2004, p144), activity diagram adalah tipe dari workflow diagram yang mendeskripsikan kegiatan user dan alur uturan mereka. Gambar 2.6 merupakan notasi yang digunakan dalam
activity diagram.
Gambar 2.6 Notasi dalam Activity Diagram
Sumber: Satzinger, Burd dan Jackson (2004, p145)
2.5.3.6 Class Diagram
Menurut Satzinger, Burd dan Jackson (2004, p184), class diagram merupakan model grafis dalam pendekatan berorientasi objek yang digunakan untuk menunjukkan kelas dari objek dalam sistem.
Gambar 2.7 Contoh Class Diagram
Sumber: Satzinger, Burd dan Jackson (2010, p60)
2.5.3.7 Domain Model Class Diagram
Menurut Satzinger, Burd dan Jackson (2004, p184), domain model
class diagram adalah UML Class Diagram yang menggambarkan beberapa
hal yang penting di dalam pekerjaan user, yaitu Problem Domain Classes, asosiasinya, dan atributnya.
38
Gambar 2.8 UML Domain Class Diagram
Sumber: Satzinger, Burd dan Jackson (2010, p188)
Gambar 2.9 Simple Domain Model Class Diagram
Sumber: Satzinger, Burd dan Jackson (2010, p188)
2.5.3.8 First-Cut Design Class Diagram
Menurut Satzinger, Burd dan Jackson (2010, p413), first-cut class
diagram merupakan perkembangan dari domain model class diagram, dengan
(1) menguraikan atribut dengan jenis dan informasi awal , dan (2) menambahkan navigasi dengan menggunakan garis panah.
Gambar 2.10 Contoh First-cut Class Diagram
Sumber: Satzinger, Burd, dan Jackson (2010, p416)
2.5.3.9 Updated Design Class Diagram
Menurut Satzinger, Burd , dan Jackson (2010, p457), updated design
class diagram merupakan perkembangan dari first-cut class diagram, dan
dibuat dengan menambahkan method sebelum memberikan garis panah.
Method tersebut dapat berupa constructor method, data get and set method,
40
menciptakan objek baru. Get and set method digunakan untuk mengambil dan menggantikan nilai atribut. Use case spesific method digunakan jika method tersebut ada di class diagram.
Gambar 2.11 Contoh Updated Design Class Diagram
Sumber: Satzinger, Burd, dan Jackson (2010, p458)
2.5.3.10 Use Case Diagram
Menurut Satzinger, Burd dan Jackson (2004, p213), use case diagram adalah diagram yang menggambarkan berbagai peran dari user dan bagaimana user tersebut berinteraksi dengan sistem.
Menurut Cadle, Paul, dan Turner (2010, p205), use case adalah unit fungsional dalam sistem atau sesuatu yang pengguna ingin lakukan dengan sistem mereka. Secara umum hal ini mengacu pada sistem IT, tetapi use case dapat dikembangkan dalam tingkat bisnis dimana mereka mendefinisikan suatu sistem bisnis yang perlu dilakukan dalam bisnis. Use Case Diagram
menyediakan representasi visual sederhana dari interaksi antara aktor dengan sistem informasi. Gambar 2.11 menunjukkan Use Case Diagram beserta elemen-elemen dasar yang ada didalamnya.
Gambar 2.12 Elemen dasar dari Use Case Diagram
Sumber: Cadle, Paul & Turner (2010, p206)
Penjelasan elemen dasar tersebut adalah:
• System Boundary, sebuah kotak yang menunjukkan batasan dari
sistem yang kita definisikan.
• System name, menunjukkan sistem yang kita definisikan.
• Actor, adalah seseorang (atau sesuatu) yang berinteraksi langsung
42
definisikan sebagai user; contonya seperti manager proyek. Namun aktor juga bisa berupa sistem lain, dan waktu juga dapat menjadi aktor.
• Use case, merupakan fungsi atau fitur sistem yang digunakan oleh
aktor.
• Association, merupakan garis antar aktor dan use case yang
menunjukkan kalau aktor tersebut memiliki interaksi dengan use case tersebut. Pada gambar 2.11, garis asosiasi tidak memiliki kepala panah di ujung karena tidak menunjukkan aliran data, tetapi hanya bahwa aktor berinteraksi dengan sistem melalui use case.
Jadi dapat disimpulkan bahwa use case diagram adalah sebuah diagram yang menggambarkan fungsional dalam sistem berserta dengan aktor atau user yang berinteraksi dengan sistem.
2.5.3.11 Use Case Description
Menurut Satzinger, Burd dan Jackson (2004, p171), use case
description adalah sebuah deskripsi yang mendaftarkan rincian dari
Gambar 2.13 Use Case Description
Sumber: Satzinger, Burd, Jackson (2010, p174)
2.5.3.12 System Sequence Diagram
Menurut Satzinger, Burd dan Jackson (2004, p213), system sequence
diagram adalah diagram yang menggambarkan urutan dari pesan yang
44
ini digunakan untuk mendefinisikan input secara berurutan hingga akhirnya mencapai output. Gambar 2.12 menggambarkan notasi dalam System
Sequence Diagram.
Gambar 2.14 Notasi System Sequence Diagram
Sumber: Satzinger, Burd, Jackson (2010, p253)
2.5.3.13 Three-layer Sequence Diagram
Menurut Satzinger, Burd dan Jackson (2010, p434), multilayer sequence diagram merupakan perkembangan dari system sequence diagram, yang mengilustrasikan desain versi detail dari use case dengan three-layer
designs yang meliputi view layer classes, business layer classes dan data access layer class.
Gambar 2.15 Three-layer Sequence Diagram
Sumber: Satzinger, Burd, dan Jackson (2010, p435)
2.5.3.14 Package Diagram
Menurut Satzinger, Burd dan Jackson (2010, p259), package diagram
adalah diagram tingkat tinggi yang memungkinkan desainer untuk
mengasosiasikan class dari grup yang terkait. Package diagram digunakan untuk membagi class diagram ke dalam fungsi yang terkait dan memberikan informasi mengenai susunan class yang dapat ditambahkan ke tampilan arsitektur sistem.
46
Gambar 2.16 Contoh Package Diagram
Sumber: Satzinger, Burd dan Jackson (2010, p459)
2.5.3.15 User Interface
Menurut Satzinger, Burd dan Jackson (2004, p442), user interface adalah bagian dari sistem informasi yang memerlukan interaksi langsung dari user untuk memberikan masukan (input) dan keluaran (output).
Menurut Galitz (2002, p4), user interface adalah bagian dari komputer dan perangkat lunaknya yang dapat dilihat, didengar atau disentuh oleh seseorang. User interface pada dasarnya terdiri dari 2 komponen yaitu input dan output. Input adalah bagaimana seseorang mengkomunikasikan keinginannya kepada komputer. Output adalah bagaimana komputer menyampaikan hasil perhitungan dan persyaratan kepada pengguna.
Jadi dapat disimpulkan bahwa user interface adalah bagian dari komputer dimana pengguna dapat melakukan input untuk berkomunikasi dengan komputer dan komputer tersebut akan mengeluarkan output berupa hasil perhitungan atau persyaratan untuk pengguna.
2.5.3.16 Rich Picture
Menurut Mathiassen et al (2000, p26), rich picture adalah sebuah gambaran informal yang digunakan oleh pengembang sistem untuk menyatakan pemahaman mereka terhadap situasi dari sistem yang sedang berlangsung. Rich picture berfokus pada aspek – aspek penting dari sistem
tersebut, dengan mengunjungi perusahaan untuk melihat bagaimana
perusahaan beroperasi, berbicara dengan banyak orang untuk mengetahui apa yang harus terjadi atau seharusnya terjadi, dan mungkin melakukan beberapa wawancara formal.
48