BAB II

PAGE 35

BAB IILANDASAN TEORI

2.1 Sistem Pendukung Pengambilan Keputusan (SPPK)

Pada dasarnya pengambilan keputusan adalah suatu pendekatan sistematis pada hakekat suatu masalah, pengumpulan fakta-fakta, penentuan yang matang dari alternatif yang dihadapi, dan pengambilan tindakan yang menurut perhitungan merupakan tindakan yang paling tepat.

2.1.1 Konsep Dasar Pengambilan Keputusan

Pada umumnya para ahli sependapat bahwa kata keputusan (decision) berarti pilihan (choice), yaitu pilihan dari dua atau lebih kemungkinan. Pengambilan keputusan hampir tidak merupakan pilihan antara yang benar dan yang salah tetapi yang sering terjadi ialah pilihan yang hampir benar dan yang mungkin salah. Keputusan yang diambil biasanya dilakukan berdasarkan pertimbangan situasional, bahwa keputusan tersebut adalah keputusan terbaik. Walaupun keputusan biasa dikatakan sama dengan pilihan, ada perbedaan penting diantara keduanya, Sementara pakar melihat bahwa keputusan adalah pilihan nyata karena pilihan diartikan sebagai pilihan tentang tujuan termasuk pilihan tentang cara untuk mencapai tujuan itu, baik pada tingkat perorangan atau pada tingkat kolektif.

Selain itu, keputusan dapat dilihat pada kaitannya dengan proses lebih dinamis yang diberi label pengambilan keputusan. Keputusan dipandang sebagai proses karena terdiri atas satu seri aktivitas yang berkaitan dan tidak hanya dianggap sebagai tindakan bijaksana. Dengan kata lain, keputusan merupakan sebuah kesimpulan yang sudah dicapai sesudah dilakukan pertimbangan, yang terjadi setelah salah satu kemungkinan dipilih, sementara yang lain dikesampingkan. Dalam hal ini, yang dimaksud dengan pertimbangan ialah menganalisis beberapa kemungkinan atau alternative satu diantaranya.

Dalam proses pengambilan keputusan terdapat model pengambilan yang diajukan Simon(1960) yang terdiri dari empat fase yaitu :

1. Penelusuran (Intellegence)

Tahap ini merupakan proses penelusuran dan pendeteksian dari lingkup problematika serta pengenalan masalah. Data masukan diperoleh, diproses dan diuji dalam rangka mengidentifikasikan masalah.

2. Perancangan (Design)

Tahap ini merupakan proses menemukan, mengembangkan, dan menganalisis alternative yang bisa dilakukan. Tahap ini meliputi proses untuk menganalisa masalah, menurunkan solusi dan menguji kelayakan solusi.

3. Pemilihan (Choice)

Dilakukan proses pemilihan diantara berbagai alternative tindakan yang mungkin dijalankan. Hasil pemilihan tersebut kemudian diimplementasikan dalam proses pengambilan keputusan.

4. Implementasi (Implementation)

Tahap ini sebenarnya adalah dari tiga tahap yang merupakan pelaksanaan dari keputusan yang diambil.

Gambar 2.1. Proses Pengambilan Keputusan2.1.2 Komponen-komponen SPPK

Suatu SPPK memiliki tiga subsistem utama yang menentukan kapabilitas teknis SPPK tersebut, yaitu :

1. Subsistem Data (data base)

Subsistem data merupakan komponen SPPK penyedia data bagi sistem. Data ini disimpan dalam data base yang diorganisasikan oleh DBMS. Data base dalam SPK berasal dari sumber internal dan eksternal.

Kemampuan yang dibutuhkan dari manajemen data base dapat diringkas sebagai berikut :

a. Kemampuan untuk mengkombinasikan berbagai variasi data melalui pengambilan dan ekstraksi data.

b. Kemampuan untuk menambahkan sumber data secara cepat dan mudah.

c. Kemampuan untuk menggambarkan struktur data logika sesuai dengan pengertian pemakai sehingga pemakai mengetahui apa yang tersedia dan dapat menentukan kebutuhan penambahan dan pengurangan.

d. Kemampuan untuk mengelola berbagai variasi data.

2. Subsistem Basis Model (model base)

Salah satu keunggulan SPK adalah kemampuan untuk mengintegrasikan akses data dan model-model keputusan. Hal ini dapat dilakukan dengan menambahkan model-model keputusan ke dalam sistem informasi yang menggunakan database sebagai mekanisme intebrasi dan komunikasi di antara model-model. Karakteristik ini menyatukan kekuatan pencarian dan pelaporan data dari pengembangan disiplin manajemen.

Model adalah abstraksi dari alam nyata. Model ini dikelola oleh model base.

3. Subsistem Dialog (user system interface)

Fleksibilitas dan kekuatan karakteristik SPK timbul dari kemampuan interaksi antara sistem dan pemakai, yang dinamakan subsistem dialog. Benner mendefinisikan pemakai, terminal, dan sistem perangkat lunak sebagai komponen-komponen dari sistem dialog. Ia membagi subsistem menjadi tiga bagian yaitu :

1) Bahasa aksi, meliputi apa yang dilakukan oleh pemakai dalam berkomunikasi dengan sistem. Hal ini meliputi pemilihan-pemilihan seperti papan ketik (key board), panel-panel sentuh, joystick, perintah suara dan sebagainya.

2) Bahasa tampilan, meliputi apa yang harus diketahui oleh pemakai. Bahasa tampilan meliputi pilihan-pilihan seperti printer, layar tampilan, grafik, warna, plotter, keluaran suara dan sebagainya.

3) Basis pengetahuan, meliputi apa yang harus diketahui oleh pemakai agar pemakaian sistem bisa efektif. Basis pengetahuan bisa berada dalam pikiran pemakai, pada kartu referensi atau petunjuk, dalam buku manual, dan sebagainya.

Melalui sistem dialog inilah sistem diartikulasikan dan diimplementasikan.

2.1.3 Pendekatan Pengembangan Sistem

Ada beberapa metode pendekatan pengembangan sistem diantaranya yaitu :

1. Pendekatan Bottom-upPendekatan Bottom-up adalah suatu pendekatan klasik yang dikembangkan pada tahun 1960-an dan tidak menggunakan struktur modern. Implementasi pendekatan ini menghasilkan modul-modul yang mula-mula berisi detailed-logic pada level terendah, dites secara terpisah, dan baru diintegrasikan dengan seluruh sistem yang ada (Kowal, 1988).

2. Pendekatan Top-DownPendekatan top-down merupakan kebalikan dari pendekatan bottom-up, Implementasi pendekatan ini, pertama-tama justru menghasilkan modul-modul pada tingkat tertinggi. Modul pada tingkat lebih tinggi ini akan diturunkan menjadi modul tingkat yang lebih rendah yang mampu memenuhi kebutuhan di tingkat bawah (Kowal, 1988)

3. Pendekatan Business System PlanningBSP merupakan suatu analisis dari kebutuhan informasi organisasi dengan cara melihat keseluruhan unit organisasi, fungsi, proses, dan elemen data.

4. Pendekatan Critical Succes F actor (CSF)

CSF merupakan hasil analisis manajemen terhadap tujuan tertentu, yang diajukan dalam bentuk penetapan elemen kritis dalam jumlah yang tidak banyak (umumnya antara 5 dan 8) agar tujuan tersebut dapat dicapai secara efektif.

5. Pendekatan Process/Procedure OrientedPendekatan berorientasi proses ini memusatkan perhatian pada sistem yang sedang dikembangkan, memanfaatkan kembali kode-kode yang ada, mengevaluasi keterkaitan proses, menilai produktifitas proses dan biaya, serta akhirnya membuat suatu proses standar.

6. Teknik Structured Specification sebagai Model Process-OrientedTeknik ini dikembangkan dengan berdasar pada analisis terstruktur untuk memecahkan masalah-masalah bisnis dan organisasi, diterapkan dengan memodelkan sistem yang ada, baik otomatis maupun manual, atas sistem yang diusulkan, dengan melakukan dekomposisi bertingkat.

7. Pendekatan Data / Object-Oriented

Pendekatan berorientasi-objek ini menciptakan modul-modul database sebagai dokumen analisis yang sama dengan batasan objek yang ada dalam sistem nyata. Dengan demikian, ada korespondensi satu-satu antara objek sistem dan komponen dokumen analisis ketika pendekatan berorientasi objek ini diterapkan.

2.1.4 Pengembangan Model

Secara umum model digunakan untuk memberikan gambaran (description), memberikan penjelasan (prescription), dan memberikan perkiraan (prediction) dari realitas yang diselidiki.

Gordon (1989) mengklasifikasikan model-model ke dalam bentu model-model sebagai berikut :

1. Model Fisik

Model-model fisik didasarkan pada beberapa analogi antara sistem-sistem seperti mesin dengan listrik atau listrik dengan hidrolika. Atribut-atribut model fisik direpresentasikan dengan pengukuran-pengukuran yang ditunjukan oleh jarum pada alat ukur. Aktivitas-aktivitas sistem dicerminkan oleh hukum-hukum fisika yang membangun model.

2. Model Matematika

Model-model matematika menggunakan notasi-notasi dan persamaan-persamaan matematika untuk merepresentasikan sistem. Atribut-atribut dinyatakan dengan variabel-variabel, dan aktivitas-aktivitas dinyatakan dengan fungsi matematika yang menjelaskan hubungan antar variabel-variabel tersebut.

3. Model Statis

Model-model dalam kategori statis, baik fisik atau matematika, memiliki nilai-nilai atribut yang berbeda dalam keadaan seimbang (balance). Jika keseimbangan diganggu dengan memberikan nilai baru pada salah satu atribut, sistem akan mencapai suatu keseimbangan baru, dengan nilai atribut yang baru pula.

4. Model Dinamis

Kebalikan model statis, model dinamis menunjukan perubahan setiap saat akibat aktivitas-aktivitasnya. Perubahan-perubahan yang terjadi dalam sistem dapat diturunkan sebagai fungsi waktu.

5. Model Analitis

Model analitis adalah model yang penyelesaiannya dilakukan dengan teknik analitis, artinya dilakukan dengan menggunakan deduksi teori-teori matematika. Solusi yang diberikan model-model jenis ini adalah langsung bersifat umum.

6. Mode Numerik

Model numerik adalah model yang diselesaikan dengan teknik numerik yang menghasilkan solusi melalui tahapan-tahapan perhitungan interaktif. Model ini mampu memberikan solusi yang bersifat khusus, yaitu pada keadaan-keadaan tertentu.

7. Model Simulasi

Emshoff (1970) mendefinisikan simulasi sebagai suatu model sistem yang komponen-komponennya direpresentasikan oleh proses-proses aritmatika dan logika yang ada pada komputer, untuk memperkirakan sifat-sifat dinamis sistem tersebut.

2.2 Analytical Hierarchy Process (AHP)

AHP adalah suatu metode yang memecah-mecah suatu situasi yang kompleks, tak terstruktur, ke dalam bagian-bagian komponennya; menata bagian atau variabel ini dalam susunan hierarkhi, memberi nilai numerik pada pertimbangan subjektif tentang relative pentingnya setiap variabel, dan mensintesis berbagai pertimbangan ini untuk menetapkan variabel mana yang memiliki prioritas paling tinggi dan bertindak untuk mempengaruhi hasil pada situasi tersebut.

Sedangkan Kelebihan AHP dibandingkan dengan yang lainnya adalah :

1. Struktur yang berhierarki, sebagai konsekuensi dari kriteria yang dipilih, sampai pada subkriteria yang paling dalam.

2. Memperhitungkan validitas sampai dengan batas toleransi inkonsistensi berbagai kriteria dan alternatif yang dipilih oleh para pengambil keputusan

3. Memperhitungkan daya tahan atau ketahanan output analisis sensitivitas pengambilan keputusan.

2.2.1 Elemen Pendukung Metode AHP

1. Definisi masalah dan pencarian solusi

2. Penggolongan hirarki, menyusun sistem yang kompleks ke dalam komponen-komponen pokok menurut sifat structural dan fungsionalnya.

3. Perbandingan berpasangan

Untuk menetapkan prioritas elemen-elemen dalam suatu persoalan keputusan adalah dengan perbandingan berpasangan antar elemen-elemen. Dalam membandingkan elemen-elemen digunakan pertanyaan : seberapa kuat suatu factor/subfaktor memiliki atau berkontribusi, mendominasi, mempengaruhi, memenuhi, atau menguntungkan terhadap sifat tersebut, dibandingkan dengan mana ia sedang dibandingkan.

2.3 Teknologi Obyek

Teknologi obyek menganalogikan sistem aplikasi seperti kehidupan nyata yang didominasi oleh obyek. Orang adalah obyek, computer adalah obyek, obyek memiliki atribut : orang memiliki nama, pekerjaan , memiliki rumah. Dan computer memiliki kecepatan, memiliki sistem oprasi. Obyek dapat beraksi dan bereaksi.

Keunggulan teknologi obyek dengan demikian adalah bahwa model yang dibuat akan sangat mendekati dunia nyata yang masalahnya akan dipecahkan oleh sistem yang dibangun. Model obyek, atribut dan kelakuan bisa langsung diambil dari obyek yang ada di dunia nyata.

Sistem yang dibangun dengan teknologi obyek memiliki fleksibilitas yang tinggi terhadap perubahan karena menggunakan konsep komponen yang bisa digunakan kembali. Di dalam dunia perangkat lunak, penggunaan berulang merupakan hal yang biasa. Contohnya, ide dan formula yang hampir sama digunakan berulang oleh programmer yang berbeda untuk mengembangkan aplikasi keuangan yang khusus diadaptasikan sesuai kebutuhan dan permintaan masing-masing klien. Oleh karena itu penggunaan berulang suatu obyek merupakan hal yang seharusnya bisa dilakukan. Suatu obyek bisa diambil untuk dimodifikasi berupa penambahan atau pengurangan untuk dimodifikasi berupa penambahan atau pengurangan untuk memecahkan suatu masalah yang baru.

2.3.1 Konsep ObjekObyek dalam software analysis & design adalah sesuatu berupa konsep (concept), benda (thing), dan sesuatu yang membedakannya dengan lingkungannya. Secara sederhana obyek adalah mobil, manusia, alarm dan lain-lainnya. Tapi obyek dapat pula merupakan sesuatu yang abstrak yang hidup didalam sistem seperti tabel, database, event, system messages.

Obyek dikenali dari keadaannya dan juga operasinya. Sebagai contoh sebuah mobil dikenali dari warnanya, bentuknya, sedangkan manusia dari suaranya. Ciri-ciri ini yang akan membedakan obyek tersebut dari obyek lainnya.

Alasan mengapa saat ini pendekatan dalam pengembangan software dengan object-oriented, pertama adalah scalability dimana obyek lebih mudah dipakai untuk menggambarkan sistem yang besar dan komplek. Kedua dynamic modeling, adalah dapat dipakai untuk permodelan sistem dinamis dan real time.

2.3.2 Prinsip Dasar dari Pemograman Berorientasi Obyek

Ada empat prinsip dasar pemograman berorientasi obyek yaitu :

1. Abstraksi

Abstraksi memfokuskan perhatian pada karakteristik obyek yang paling penting dan dominan yang bisa digunakan untuk membedakan obyek tersebut dari obyek lainnya.

2. Enkapsulasi

Enkapsulasi menyembunyikan banyak hal yang terdapat dalam obyek yang tidak perlu diketahui oleh obyek lain. Dalam praktek pemograman enkapsulasi diwujudkan dengan membuat suatu kelas interface yang dipanggil oleh obyek lain, sementara didalam obyek yang dipanggil terdapat kelas lain yang mengimplementasikan apa yang terdapat dalam kelas interface. Obyek lain hanya tahu dia perlu memanggil kelas interface tanpa perlu tahu proses apa saja yang dilakukan didalam kelas implementasinya dan untuk menuntaskan proses tersbut perlu berhubungan dengan obyek mana saja. Dengan demikian bila terjadi perubahan pada proses implementasi maka obyek pemanggil tidak akan terpengaruh secara langsung.

3. Modularitas

Modularitas membagi sistem yang rumit menjadi bagian-bagian yang lebih kecil yang bisa mempermudah developer memahami dan mengelola obyek tersebut. Contohnya adalah Sistem Akademis yang bisa dibagi menjadi kemahasiswaan, katalog mata kuliah, dan pembayaran kuliah.

4. Hirarki

Hirarki berhubungan dengan abstraksi dan modularitas, yaitu pembagian berdasarkan urutan dan pengelompokan tertentu. Misalnya untuk menentukan obyek mana yang berada pada kelompok yang sama, obyek mana yang merupakan komponen dari obyek yang memiliki hirarki lebih tinggi. Semakin rendah hirarki obyek berarti semakin jauh abstraksi dilakukan terhadap sesuatu obyek.

2.4 Unified Modelling Langguage

Dalam suatu proses pengembangan software, analisa dan rancangan telah merupakan terminologi yang sangat tua. Pada saat masalah ditelusuri dan spesifikasi dinegoisasikan, dapat dikatakan kita berada pada tahap rancangan. Merancang adalah menemukan suatu cara untuk menyelesaikan masalah, salah satu tool/model untuk merancang pengembangan software yang berbasis object oriented adalah UML (Unified Modeling Language).2.4.1 Sejarah Singkat UML

UML (Unified Modeling Language) adalah sebuah bahasa yang berdasarkan grafik/gambar untuk memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian dari sebuah sistem pengembangan software berbasis OO (Object-Oriented). UML sendiri juga memberikan standar penulisan sebuah sistem blue print, yang meliputi konsep bisnis proses, penulisan kelas-kelas dalam

Pendekatan analisa & rancangan 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 metoda OO mulai diuji cobakan dan diaplikasikan antara 1989 hingga 1994, seperti halnya oleh Grady Booch dari Rational Software Co., dikenal

dengan OOSE (Object-Oriented Software Engineering), serta James Rumbaugh dari General Electric, dikenal dengan OMT (Object Modelling Technique). 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 metoda OO untuk membuat suatu model bahasa yang uniform / seragam 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 project pendekatan metoda yang uniform/seragam dari masing-masing metoda 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 metoda OOSE sehingga muncul release version 0.9 pada bulan Juni 1996. Hingga saat ini sejak Juni 1998 UML version 1.3 telah diperkaya dan direspons oleh OMG (Object Management Group), Anderson Consulting, Ericsson, Platinum Technology, ObjectTime Limited, dll serta di pelihara oleh OMG yang dipimpin oleh Cris Kobryn.

UML adalah standar dunia yang dibuat oleh Object Management Group (OMG), sebuah badan yang bertugas mengeluarkan standar-standar teknologi objectoriente dan software component.

2.4.2 Pengenalan UML

Pemodelan (modeling) adalah proses merancang piranti lunak sebelum melakukan pengkodean (coding). Model piranti lunak dapat dianalogikan seperti pembuatan blue print pada pembangunan gedung. Membuat model dari sebuah sistem yang kompleks sangatlah penting karena kita tidak dapat memahami sistem semacam itu secara menyeluruh. Semakin komplek sebuah sistem, semakin penting pula penggunaan teknik pemodelan yang baik.Dengan menggunakan model, diharapkan pengembangan piranti lunak dapat memenuhi semua kebutuhan pengguna dengan lengkap dan tepat, termasuk faktor-faktor seperti scalability, robustness, security, dan sebagainya. Kesuksesan suatu pemodelan piranti lunak ditentukan oleh tiga unsur, yang kemudian terkenal dengan sebuan segitiga sukses (the triangle for success). Ketiga unsur tersebut adalah metode pemodelan (notation), proses (process) dan tool yang digunakan.

Memahami notasi pemodelan tanpa mengetahui cara pemakaian yang sebenarnya (proses) akan membuat proyek gagal. Dan pemahaman terhadap metode pemodelan dan proses disempurnakan dengan penggunaan tool yang tepat.

Gambar 2.5 Unsur pemodelan piranti lunak

Unified Modelling Language adalah bahasa standar yang digunakan untuk menjelaskan dan memvisualisasikan artifak dari proses analisis dan disain berorientasi objek. UML menyediakan standar pada notasi dan diagram yang bisa digunakan untuk memodelkan suatu sistem.

UML memungkinkan developer melakukan permodelan secara visual, yaitu penekanan pada penggambaran, bukan didominasi oleh narasi. Pemodelan visual membantu untuk menangkap struktur dan kelakuan dari obyek, mempermudah penggambaran interaksi antar elemen dalam sistem, dan mempertahankan konsistensi antara disain dan implementasi dalam pemograman.

Seperti bahasa-bahasa lainnya, UML mendefinisikan notasi dan syntax/semantik. Notasi UML merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti lunak. Setiap bentuk memiliki makna tertentu, dan UML syntax mendefinisikan bagaimana bentuk-bentuk tersebut dapat dikombinasikan. Notasi UML terutama diturunkan dari 3 notasi yang telah ada sebelumnya: Grady Booch OOD (Object-Oriented Design), Jim Rumbaugh OMT (Object Modeling Technique), dan Ivar Jacobson OOSE (Object-Oriented Software Engineering).

2.4.3 Notasi dalam Unified Modelling Language

UML menyediakan beberapa notasi dan artifak standar yang bisa digunakan sebagai alat komunikasi bagi para pelaku dalam proses analisis dan disain. Artifak di dalam UML didefinisikan sebagai informasi dalam berbagai bentuk yang digunakan atau dihasilkan dalam proses pengembangan perangkat lunak. Contohnya adalah source code yang dihasilkan oleh proses pemograman.

Yang perlu diperhatikan untuk menjaga konsistensi antar artifak selama proses analisis dan disain adalah bahwa setiap perubahan yang terjadi pada satu artifak harus juga dilakukan pada artifak sebelumnya. Misalnya ditemukan satu cara yang lebih efisien sewaktu membuat Sequence diagram, maka perbaikan tersebut perlu diverifikasi terhadap Use case diagram apakah perlu dilakukan perubahan juga dalam Use case specificationnya

1. actor actor adalah segala sesuatu yang berinteraksi dengan sistem aplikasi komputer. Jadi actor ini bisa berupa orang, perangkat keras, atau mungkin obyek lain dalam sistem yang sama. Biasanya yang dilakukan oleh actor adalah memberikan informasi pada sistem dan\atau memerintahkan sistem untuk melakukan sesuatu

Gambar 2.6 Notasi actor2. ClassClass merupakan pembentuk utama dari sistem berorientasi obyek karena class menunjukkan kumpulan obyek yang memiliki atribut dan operasi yang sama. Class digunakan untuk mengimplementasikan interface.

Class digunakan untuk mengabstraksikan elemen-elemen dari sistem yang sedang dibangun. Class bisa untuk merepresentasikan baik perangkat lunak maupun perangkat keras, baik konsep maupun benda nyata.

Notasi class berbentuk persegi panjang berisi 3 bagian : persegi paling atas untuk nama class, persegi panjang paling bawah untuk operasi, dan persegi panjang di tengah untuk atribut.

Atribut digunakan untuk menyimpan informasi. Nama atribut menggunakan kata benda yang bisa dengan jelas merepresentasikan informasi yang disimpan di dalamnya. Oprasi menunjukan sesuatu yang bisa dilakukan oleh obyek, dan menggunakan kata kerja.

Gambar 2.7 Notasi Class3. InterfaceInterface merupakan kumpulan operasi tanpa implementasi dari suatu class. Implementasi operasi dalam interface dijabarkan oleh operasi dalam class. Oleh karena itu keberadaan interface selalu disertai oleh class yang mengimplementasikan operasinya. Interface ini merupakan salah satu cara mewujudkan prinsip enkapsulasi dalam obyek.

Gambar 2.8 Notasi Interface

4. Use case

Use case menjelaskan urutan kegiatan yang dilakukan actor dan sistem untuk mencapai suatu tujuan tertentu. Walaupun menjelaskan kegiatan namun Use case hanya menjelaskan apa yang dilakukan oleh actor dan sistem, bukan bagaimana actor dan sistem melakukan kegiatan tersebut.

Gambar 2.9 Notasi Use Case

5. InteractionInteraction digunakan untuk menunjukan baik aliran pesan atau informasi antar obyek maupun hubungan antar obyek. Biasanya Interaction ini dilengkapi juga dengan teks bernama operation signature yang tersusun dari nama operasi, parameter yang dikirim dan tipe parameter yang dikembalikan.

Gambar 2.10 Notasi Interaction6. PackagePackage adalah kontainer atau wadah konseptual yang digunakan untuk mengelompokan elemen-elemen dari sistem yang sedang dibangun, sehingga bisa dibuat model yang lebih sederhana. Tujuannya adalah untuk mempermudah penglihatan (visibility) dari model yang sedang dibangun.

Gambar 2.11 Notasi Package

7. NoteNote digunakan untuk memberikan keterangan dan komentar tambahan dari suatu elemen sehingga bisa langsung terlampir dalam model. Note ini bisa ditempelkan ke semua elemen notasi yang lain.

Gambar 2.12 Notasi Note

8. DependencyDependency merupakan relasi yang menunjukan bahwa perubahan pada salah satu elemen memberi pengaruh pada elemen lain. Elemen yang ada di bagian tanda panah adalah elemen yang tergantung pada elemen yang ada di bagian tanpa tanda panah.

Terdapat 2 stereotype dari Dependency, yaitu Include dan Extend. Include menunjukan bahwa suatu bagian dari elemen (yang ada di garis tanpa panah) memicu eksekusi bagian dari elemen lain (yang ada digaris dengan panah),misalnya untuk notasi A -- > B operasi yang ada di class A memicu dieksekusinya operasi yang ada di clss B.

Extended menunjukan bahwa suatu bagian dari elemen di garis tanpa panah bisa disisipkan ke dalam elemen yang ada di garis dengan panah; misalnya untuk notasi A -- > B suatu pungsi dari Use case A bisa disisipkan ke dalam Use case B atau dengan kata lain A optional untuk B.

Kedua stereotype ini direpresentasikan dengan menambahkan text include atau extend di notasi Dependency.

Gambar 2.13 Notasi Dependency9. Boundary Class

Boundary class adalah class yang menghubungkan user dengan sistem. Oleh karena itu sering disebut juga sebagai user interface class.

Gambar 2.14 Boundary Class

10. Control Class

Control class adalah class yang mengkoordinasi aktivitas dalam sistem. Class ini menghubungkan boundary class dengan entity class.

Gambar 2.15 Control Class

11. Entity Class

Entity class adalah class yang berhubungan dengan data atau informasi yang digunakan oleh sistem. Entity class ini adalah class yang menyimpan dan mengelola data.

Gambar 2.16 Entity Class

2.4.4 Konsepsi Dasar UML

Abstraksi konsep dasar UML yang terdiri dari structural classification, dynamic behavior, dan model management, Diagrams. Main concepts bisa kita pandang sebagai term yang akan muncul pada saat kita membuat diagram. Dan view adalah kategori dari diagaram tersebut.

Unified Modelling Language (UML) mendefinisikan diagram-diagram sebagai berikut:

1. Use case Diagram

Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah apa yang diperbuat sistem, dan bukan bagaimana. Sebuah Use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya.

Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu.

2. Class Diagram

Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi).

Class diagram menggambarkan struktur dan deskripsi class, Package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain.

3. Statechart Diagram

Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram).

4. Activity Diagram

Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum.

Sebuah aktivitas dapat direalisasikan oleh satu Use case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara Use case menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas.

Sama seperti state, standar UML menggunakan segiempat dengan sudut membulat untuk menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi tertentu. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal.

5. Sequence Diagram

Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait).

6. Collaboration Diagram

Collaboration diagram juga menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian message.

Setiap message memiliki sequence number, di mana message dari level tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama.

7. Component Diagram

Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (Dependency) di antaranya.

Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run time. Umumnya komponen terbentuk dari beberapa class dan/atau Package, tapi dapat juga dari komponen-komponen yang lebih kecil.

Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.

8. Deployment Diagram

Deployment/physical diagram menggambarkan detail bagaimana komponen di-deploy dalam infrastruktur sistem.

2.5 Sejarah Borland Delphi

Borland Delphi mulai dikembangkan pada tahun 1995 oleh Inprise Corporation. Inprise Corporation merupakan perusahaan pembuat software yang sebelumnya bernama Borland. Borland Delphi adalah sebuah program aplikasi yang memanfaatkan keistimewaan konsep-konsep antar muka dalam grafik Microsoft Windows. Aplikasi yang dihasilkan Borland Delphi berkaitan erat dengan windows itu sendiri sehingga butuh pengetahuan bagaimana cara kerja windows bila dipandang dari kaca mata user. Dengan memahami windows maka pemrograman dapat mengahasilkan aplikasi yang lebih efektif.

Borland Delphi merupakan perangkat lunak yang digunakan untuk menyusun program aplikasi yang berdasarkan bahasa pemrograman Pascal dan bekerja dalam lingkungan sistem operasi Windows. Dalam merancang aplikasi Borland Delphi sangat mudah penggunaanya dikarenakan telah disediakan komponen-komponen yang siap pakai.

Borland Delphi menghasilkan fasilitas IDE atau Integrated Development Environment. Dengan IDE, fungsi-fungsi yang diperlukan selama penulisan program telah disediakan dalam suatu tampilan. Untuk menuliskan kode program misalnya, tinggal mengklik objek yang akan diprogram kemudian dituliskan program pada kode editor yang telah terbuka dan siap pakai bila diperlukan.

Didalam bahasa pemrograman pascal untuk membuat suatu windows sangatlah rumit karena harus menulis kode untuk menggambarkannya, tetapi Borland Delphi telah menyediakan objek form, kotak dialog dan perangkat kontrol lainnya. Jadi langkah pertama dalam pembuatan suatu program aplikasi menggunakan Borland Delphi adalah merancang tampilan masukan dan keluaran, setelah itu baru langkah terakhir menuliskan kode program.

Delphi memberikan kemudahan bagi pemakai dengan memberikan fasilitas yang cukup banyak sehingga pembuatan aplikasi menjadi sangat mudah dan efisien. Beberapa kelebihan dari bahasa Delphi adalah :

1. Delphi banyak memiliki operator untuk memanipulasi data.

2. Berbagai struktur data dan pengendalian proses disediakan dalam Delphi, sehingga memungkinkan untuk membuat program yang terstruktur.

3. Dibandingkan dengan bahasa mesin atau rakitan (assembly), Delphi lebih mudah dipahami dan pemrogram tidak perlu tahu detail mesin komputer. Sebab Delphi merupakan bahasa yang berorientasi pada permasalahan bukan berorientasi pada mesin.

4. Delphi memungkinkan memanipulasi data dalam bentuk bit maupun byte secara efisien. Disamping itu juga memungkinkan untuk memanipulasi alamat dari suatu data yang dinamakan pointer dan alamat memori.

5. Kecepatan eksekusi Delphi hampir sama dengan bahasa tingkat rendah.

Intelligence

(Penelusuran lingkup masalah)

Design

(Perancangan penyelesaian masalah)

Choice

(Pemilihan tindakan)

Implementation

(Pelaksanaan tindakan)

Metodologi Pemodelan

Proses

Tools

10