BAB II DASAR TEORI
2.1
Sistem Informasi Akademik
2.1.1 Sistem Sebuah sistem adalah seperangkat komponen yang saling berhubungan dan bekerja sama untuk mencapai suatu tujuan (sommervile,2003). 2.1.2 Sistem informasi Sistem informasi adalah suatu kumpulan dari komponen-komponen yang saling berinteraksi untuk mengelola informasi pada suaru organisasi untuk mendukung kegiatan bisnis organisasi (Shalahudin dan Rosa, 2008). 2.1.3 Akademik Akademik adalah kegiatan yang berhubungan dengan penyelenggaraan pendidikan di tingkat jurusan. 2.1.4 Sistem informasi Akademik Sistem informasi Akademik adalah sebuah sistem khusus
untuk keperluan
pengelolaan data-data Akademik dengan penerapan teknologi komputer baik hardware maupun software. 2.1.5 SMS Gateway Sms Gateway merupakan suatu platform yang menyediakan mekanisme untuk EUA (aplikasi yang membutuhkan SMS) menghantar dan menerima SMS dari peralatan Mobile (HP, PDA Phone, dll) melalui sms gateway’s shortcode.
7
8
2.2 Paradigma berorientasi object Paradigma berorientasi object adalah cara yang berbeda dalam memandang dalam memandang aplikasi-aplikasi. Dengan pendekatan berorientasi object, para pengembang membagi.aplikasi-aplikasi besar menjadi object-object, yang mandiri satu terhadap yang lainya.pengembang kemudian mengembangka aplikasi dengan membuat object-object saling mengirim pesan (message) dan bekerja sama (adi nugroho,2005).
2.3 Pemrograman berorientasi object Pemrograman berorientasi object memandang aplikasi perangkat lunak sebagai kumpulan object yang saling berinteraksi di dalam suatu sistem (Farid Aziz, 2005) Beberapa konsep dasar pemrograman berorientasi object 2.3.1 Abstraksi Abstraksi adalah teknik untuk menentukan ciri, sifat atau informasi penting dari suatu object, mana yang akan di tampilkan dan mana yang akan disembunyikan (Farid Aziz, 2005). 2.3.2 Object Object merupakan abstraksi sesuatu dalam dunia nyata. Sesuatu ini dapat berupa apap saja: sebuah benda, aktifivitas, manusia, bussiness system, atau workflow (Farid Aziz, 2005).
2.3.3 Class Class adalah kumpulan object-object yang memiliki karakteristik yang sama (Farid Aziz, 2005).
9
2.3.3.1 Encapsulation (pembungkusan) Dalam sistem berorientasi object kita menggabungkan potongan-potongan informasi dan perilaku-perilaku spesifik yang bekerja pada informasi tersebut, kemudian kita mengemasnya menjadi apa yang disebut sebagai object. Ini dirujuk dengan kata encapsulation (adi nugroho,2005). 2.3.3.2 Pewarisan (inheritence) Iinheritence adalah mekanisme yang memungkinkan kita menciptakan object-object baru berdasarkan object lain yang sudah ada: object anak mewarisi segala sesuatunya dari object induk (adi nugroho,2005). Keuntungan penggunaan inheritence adalah (Farid Aziz, 2005): 1. Didalam sub class dapat didefinisikan method yang lebih spesifik berdasar pada method yang ada di superclass. Hal ini memungkinkan penggunaan berulang (reuse) dari kode program. 2. dapat dibuat super class yang bersifat generik yang disebut abstrak class. Abstract class ini berisikan method-method “kosong”. Method-method ini kemudian “diisi” sesuai spesifikasi dari sub class. 2.3.3.3 Polymorphism Polymorphism adalah suatu fungsionalitas yang diimplementasikan dengan berbagi cara yang berbeda (adi nugroho,2005). Polymorphism berarti suatu object dapat memiliki berbagai bentuk , yaitu sebagai object dari class sendiri ataupun sebagai object dari super class (Farid Aziz, 2005): Dua macam bentuk polymorphism (Farid Aziz, 2005)::
10
1. Overloading adalah penggunaan satu nama untuk beberapa method yang berbeda dalam suatu class. Method-method yang namanya sama ini dibedakan satu dengan lainnya berdasarkan parameter yang disediakan masing-masing method. 2. Overriding adalah mendeklarasikan sebuah method dengan nama dan parameter yang sama dengan method suatu method dari super class-nya. Method yang di deklarasikan di-sub class akan meng-override method dari super class-nya . 2.4 Unified Modeling Language (UML) UML disebut sebagai bahasa pemodelan, bukan metode. Sebagian besar metode terdiri dari, setidaknya dua prinsip yaitu bahasa pemodelan dan proses. Bahasa pemodelan adalah notasi (terutama grafis) bahwa metode digunakan untuk mengekspresikan desain. Proses ini adalah tentang apa langkah yang harus diambil dalam melakukan desain (Fowler dan Scott, 1999). UML muncul karena adanya kebutuhan pemodelan visual untuk menspesifikasikan, menggambarkan, membangun, dan dokumentasi perangkat lunak. UML merupakan bahasa visual untuk pemodelan dan komunikasi mengenai sebuah sistem dengan mengguanakan diagram dan teks pendukung (Shalahudin dan Rosa, 2008). Notasi adalah hal grafis yang anda lihat dalam model, ini adalah sintaks dari bahasa pemodelan. Sebagai contoh, notasi class diagram mendefinisikan bagaimana item dan konsep-konsep seperti class, asosiasi, dan multiplisitas terwakili (Fowler dan Scott, 1999). Berikut adalah diagram-diagram yang ada pada UML: 2.4.1 Use case Diagram Diagram use case memperliharkan pada kita hubungan-hubungan yang terjadi antara aktor-aktor dengan use case-use case dalam sistem (adi nugroho,2005).
11
Use case diagram digunakan untuk memodelkan bisnis proses berdasarkan perspektif pengguna sistem (Farid Aziz, 2005). Use case diagram terdiri atas diagram untuk use case dan actor (Farid Aziz, 2005): 2.4.1.1 Aktor Beberapa definisi aktor adalah sebagai berikut: 1. Aktor adalah seseorang atau sesuatu yang berinteraksi dengan sisten yang sedang kita kembangkan. Aktor berada diluar lingkup sistem/perangkat lunak yang sedang kita kembangkan ; bersifat ekternal (adi nugroho,2005). 2. Aktor mempresentasikan orang yang mengoprasikan atau orang yang berinteraksi dengan sitem aplikasi (Farid Aziz, 2005). Adapun gambar aktor terlihat seperti gambar 2.1:
Gambar 2.1 Aktor 2.4.1.2 Use case Use case adalah peringkat tertinggi dari fungsionalitas yang dimiliki system. Dengan
kata
lain,
use
case
menggambarkan
bagaimana
seseorang
akan
menggunakan/memanfaatkan system (adi nugroho,2005). Use case mempresentasikan operasi yang dilakukan oleh aktor (Farid Aziz, 2005). Adapun gambar use case telihat seperti gambar 2.2:
12
Gambar 2.2 Use case 2.4.1.3 Relasi Use case dan actor masing masing tidak berdiri sendiri, mereka saling terhubung dengan apa yang dinamakan relasi (adi nugroho,2005). Adapun relasi tersebut adalah: 2.4.1.3.1 Relasi asosiasi Relasi yang terjadi antara actor dengan use case biasanya berupa asosiasi. Dalam UML asosiasi digambarkan dengan garis lurus dengan kepala panah di salah satu ujungnya (adi nugroho,2005). 2.4.1.3.2 Relasi cakupan (include relationship) Relasi cakupan (include relationship) memungkinkan suatu use case untuk menggunakan fungsionalitas yang disediakan oleh use case lainnya (adi nugroho,2005). 2.4.1.3.3 Relasi perluasan (extends Relationship) Extends relationship memungkinkan suatu use case memiliki kemungkinan untuk memperluas fungsionalitas yang disediakan usecase lainnya. Ini agak mirip dengan include relationship, namun pada extends relationship tidak harus terjadi apa yang diharapkan (adi nugroho,2005). 2.4.1.3.4 Generalisasi Relasi generalisasi digunakan untuk memperlihatkan bahwa beberapa actor atau use case memiliki sesuatu hal yang bersifat umum (adi nugroho,2005).
13
2.4.2 Activity diagram Activity diagram adalah salah satu cara untuk memodelkan event-event yang terjadi dalam suatu use case. Diagram ini juga dapat diganti dengan sejumlah teks. Namun, penggunaan teks kadang terlalu sulit dan dipahami, terutama jika aliran event berbelitbelit dan memiliki banyak alternatif (adi nugroho,2005). Activity diagram digunakan untuk memodelkan aspek dinamis dari sistem. Activity diagram secara esensial mirip diagram alir (flowchart), memperlihatkan aliran kendali dari suatu aktifitas ke aktifitas lainnya (adi nugroho,2005). 2.4.2.1 Action dan activity state Pada aliran kendali yang dimodelkan dengan activity diagram, segala sesuatu aspek dapat terjadi. Kita barangkali mengevaluasi beberapa ekspresi yang mengubah nilai suatu atribut atau mengembalikan
suatu nilai tertentu. Alternatifnya, barangkali memanggil
operasi yang terjadi pada sebuah object, mengirim sinyal (signal) pada object, atau sekedar menciptakan atu menghancurkan suatu object. Langkah-langkah ini dinamakan action state karena mereka adalah state dari sistem dimana setiap state mencerminkan eksekusi dari suatu aksi (adi nugroho,2005). Pada activity diagram state adalah aksi (ekspresi) yang terjadi pada suatu object. Action state pada umumnya atomik; ia tidak dapat di dekomposisi lebih lanjut. Lebih lanjut action state adalah atomik yang berarti event-event mungkin terjadi, tetapi pekerjaan suatu action state tidak akan terinterupsi. Terakhir, pekerjaan dari suatu action state secara umum di pertimbangkan mengambil waktu eksekusi yang tidak signifikan di banding waktu kerja sistem secara keseluruhan (adi nugroho,2005).
14
2.4.2.2 Transition Ketika aksi atau aktifitas dari suatu state diselesaikan, aksi berikutnya, kita dapat mensfesifikasi aliran ini dengan menggunakan transisi-transisi untuk memperlihatkan lintasan dari satu aksi atau aktifitas ke aksi atau aktifitas berikutnya (adi nugroho,2005). Secara semantik, transisi seperi ini dinamakan pemicuan (fired atau trigger) karena control dilewatkan dengan segera setelah suatu pekerjaan di selesaikan. Setelah suatu state diselesaikan, kita dapat mengeksekusi aksi keluar (exit action); jika ada selanjutnya, dan tanpa penundaan control mengikuti transisi dan di lewatkan ke aksi atau aktifitas berikutnya (adi nugroho,2005).. 2.4.2.3 Percabangan (branching) Transisi berurutan adalah umum, tetapi transisi tidak selalu terjadi secara berurutan. Seperti pada diagram alur (flowchart), kita juga dapat melibatkan percabangan. Percabangan dilukiskan dengan bentuk jajaran genjang. Pada tramsisi berjalan kita dapat menempatkan eksprei boolean tertentu, yang dievaluasi sekali saat memasuki percabangan. Kalimat penentu (guard) juga dapat dilibatkan untuk menentukan cabang mana yang akan dimasuki. Percabangan (adi nugroho,2005). 2.4.2.4 Forking and joining Forking adalah satu aliran yang pada tahap tertentu berubah jadi beberapa aliran, sedangkan joining adalah beberapa aliran sekaligus yang secara bersamaan masuk ke satu titik (adi nugroho,2005). Urutan sederhana serta percabangan adalah bentuk yang umum yang kita jumpai pada activity diagram. Lebih jauh terutama jika kita melakukan pemodelan aliran kerja dari suatu proses bisnis. Kita seringkali menemukan aliran-aliran yang konkuren. Dalam
15
UML, kita menggunakan garis singkronisasi untuk menspesifikasi forking serta joining. Garis sinkronisasi di gambarkan dengan garis horizontal tebal (adi nugroho,2005). 2.4.3 Sequence diagram Sequence diagram menunjukkan urutan interaksi antara object (O’Docherty,2005). Sequence
diagram
menggambarkan
kelakuan
object
pada
use
case
dengan
mendeskripsikan waktu hidup object dan message yang dikirimkan dan diterima antar object (shalahudin dan rosa,2008). Banyaknya diagram sequence yang harus di gambar adalah sebanyak pendefinisian use case yang memiliki proses sendiri atau yang penting semua use case yang telah di definisikan interaksi jalannya pesan sudah di cakup pada sequence diagram sehingga makin banyak use case yang di definisikan maka sequence diagram yang harus dibuat juga semakin banyak (shalahudin dan rosa,2008). 2.4.3.1 Object entitas Object-object jenis ini memelihara informasi di dalamnya. Mereka kelak seringkali dipetakan sebagai field-field di basis data. Kebanyakan kata-kata benda pada aliran eventevent adalah object entitas. 2.4.3.2 Object pembatas Object-object jenis ini berada pada pembatas antara sistem dengan dunia luar. Dengan kata lain, mereka adalah form-form dan jendela-jendela (windows) aplikasi dan antarmuka-antarmuka (interface) ke aplikasi-aplikasi lain dan/atau sistem lain. 2.4.3.3 Object kendali Mereka adalah object-object optional yang mengendalikan aliran-aliran dalam suatu use
case.
Mereka
tidak
memiliki
fungsionalitas-fungsionalitas
tetapi
mereka
16
mengkordinasi object-object yang lain dan mengendalikan aliran logika secara keseluruhan. 2.4.4 Class diagram Class diagram adalah diagram yang digunakan untuk menampilan beberapa class serta paket-paket yang ada di dalam sistem/perangkat lunak yang sedang kita kembangkan. Class diagram memberi kita gambaran/diagram statis tentang sistem/perangkat lunak dan relasi-relasi yang ada didalamnya (adi nugroho,2005). 2.4.4.1 Class Class adalah sesuatu yang membungkus (encapsulate) informasi (atribut) dan perilaku(operasi/method) (adi nugroho,2005). Identifikasi class Berikut adalah cara-cara mengidentifikasi class: 1. Class-class dapat kita temukan saat kita meninjau scenario-skenario, baik alternatif maupun primer, untuk suatu use case. Class-class dapat ditemukan dalam bentuk kata-kata benda dalam skenario-skenario use case (adi nugroho,2005). 2. Cara lain yang dapat digunakan
untuk menemukan class-class adalah dengan
memeriksa object-object yang ada di sequence diagram dan colaboration diagram. Untuk menemukan class berusahalah menemukan segala sesuatu yang bersifat umum dari object-object, sebab kita tahu bahwa sesungguhnya class adalah blue print bagi object-object didalamnya. Setiap object yang kita temukan dalam sequence diagram dan collaboration diagram sesungguhnya harus dipetakan kedalam bentuk class-class. (adi nugroho,2005).
17
2.4.4.2 Relasi Ada lima jenis relasi yang dapat kita modelkan. Kelima jenis relasi beserta ralsinya adalah sebagai berikut (adi nugroho,2005): 2.4.4.2.1 Relasi asosiasi Asosiasi adalah koneksi semantik antara satu class dengan dengan class yang lain. Asosiasi digambarkan dengan garis tunggal yang menghubungkan class-class. Saat asosiasi terhubung antara dua class, setaiap class dapat mengirim pesannya kearah class yang lainnya pada interaction diagram. Dalam notasi uml mengenal asosiasi dua arah (bidirectional) atau satu arah (undirectional). Dalam UML asosiasi dua arah digambarkan dengan dengan garis dua tanda panah di kedua sisinya maupun dengan garis tanpa tanda panah. Asosiasi satu arah mengandung satu kepala panah yang menunjukan dari arah pemberian pesan (adi nugroho,2005). 2.4.4.2.2 Depedencies Depedencies juga menghubungkan dua class, tetapi memiliki perbedaan dengan asosiasi. Dependency selalu bersifat satu arah (undirectional) dan memperlihatkan bahwa, meski suatu class tidak menginstansiasi yang lainnya, ia tidak perlu mengirim pesan ke class yang lainnya. Dengan kata lain, meski object A tidak terinstansiasi dan memiliki object B, ia perlu mengirim pesan ke object B. Depedency juga dibutuhkan saat suatu class digunakan sebagai parameter atau tipe kembalian untuk operasi suatu class (adi nugroho,2005). 2.4.4.2.3 Agregasi Agregasi merupakan bentuk yang lebih kuat dari asosiasi. Agregasi adalah relasi antara suatu keseluruhan ke bagian-bagiannya (adi nugroho,2005). Realisasi (realizes relationship)
18
Relasi realisasi digunakan untuk memperlihatkan relasi antara suatu class dengan interfacenya, antara komponen dengan interfacenya, atau antara use case dengan relalisasi use case yang bersangkutan. Dengan kata lain relasi ini memisahkan antarmuka (interface) dengan implementasinya (adi nugroho,2005). 2.4.4.2.4 Generalisasi Generalisasi
diperlukan
untuk
memperlihatkan
relasi/hubungan
pewarisan
(inheritance) antar unsur dalam class diagram (adi nugroho,2005). Identifikasi relasi 1. Untuk
menemukan
relasi-relasi
dengan
pertolongan
interaction
diagram,
lakukanlah langkah-langkah berikut ini (adi nugroho,2005): 2. Mulailah dengan memeriksa sequence diagram dan collaboration diagram. Jika class A mengirim pesan ke class B pada diagram-diagram tadi maka harus ada relasi antara class A dan class B tadi, biasanya relasi-relasi yang kita temukan dengan metoda ini adalah asosiasi atau dependency. 3. Uji class-class dan cari relasi-relasi dari suatu bagian ke keseluruhan. Dengan cara ini, kita akan menemukan relasi agregasi. 4. Uji clas-class untuk mencari relasi generalisasi. Cobalah untuk menemukan setiap class yang memiliki tipe-tipe yang berbeda. 2.4.5 Deployment diagram Deployment diagram memperlihatkan setiap simpul (node) dalam jaringan, hubunganhubungan antar simpul itu sendiri, serta proses-proses yang akan berjalan di masingmasing simpul (adi nugroho,2005).
19
2.5 Rational Unified Process (RUP) RUP adalah kerangka proses rekayasa perangkat lunak. RUP memberikan praktek terbaik dan bimbingan untuk pengembangan perangkat lunak yang sukses dan disiplin pendekatan tugas dan tanggung jawab menetapkan dalam pengembangan organisasi. Tujuannya adalah untuk memastikan produksi perangkat lunak berkualitas tinggi yang memenuhi
kebutuhan
penggunanya
termasuk
prediksi
jadwal
dan
anggaran
(Péraire,2007). Gambar 2.3. menggambarkan keseluruhan arsitektur RUP
Gambar 2.3 Arsitektur RUP 2.5.1 Dimensi RUP RUP memiliki dua diomensi yaitu: 1. Sumbu horizontal merupakan waktu dan menunjukkan aspek siklus hidup dari proses seperti terbentang. siklus ini dibagi dalam empat tahap: awal, elaborasi, konstruksi, dan transisi. Tiap tahap dibagi menjadi satu atau lebih iterasi. Sebagai contoh, pada Gambar 2.3, insepsi memiliki satu iterasi, elaborasi memiliki dua iterasi, konstruksi telah iterasi n, dan transisi memiliki dua iterasi. Jumlah yang tepat dari iterasi per fase bervariasi dari proyek untuk proyek (Péraire,2007).
20
2. Sumbu vertikal mewakili disiplin ilmu, seperti kebutuhan, analisis, dan desain, atau pelaksanaan (Péraire,2007). 2.5.2 Tahapan Tahapan RUP Empat tahapan Metodologi RUP adalah sebagai berikut (Kruchten,2003) 1. Insepsi: Melakukan pengumpulan data, menetapkan ruang lingkup, serta analisis dan desain awal. 2. Elaborasi: Melakukan penjabaran analisa kebutuhan dan menetapkan arsitektur serta kerangka aplikasi. Analisa dan desain sistem mulai dilakukan. 3. Konstruksi: Melakukan analisa dan desain teknis diikuti dengan pengkodean ke dalam kode sumber aplikasi. 4. Transisi: Melakukan transisi dari pengembangan dan testing menuju penggunaan sesungguhnya, meliputi pemaketan, instalasi, uji coba oleh pengguna, pelatihan, konversi data, dan konfigurasi akhir. 2.5.3 Artifak RUP Untuk megetahui artifak RUP perhatikan tabel 2.1 di bawah ini: Tabel 2.1 sample devlopment RUP , S= start, R= refine (Larman,2005)
DISIPLIN
ARTTIFACT
INCEP.
ELAB. CONST.
TRAN S.
I1 Bisnis
Domain model
E1..En S
modeling Requitment
Use case model
S
R
(analisis
Vision
S
R
C1..Cn
T1..T2
21
kebutuhan)
Supplementary
S
R
Glossary
S
R
Business rules
S
R
spesifikasi
Desain
Desain model
S
Software/hardware
S
R
architecture Data model
S
R
2.5.3.1 Vision Dokumen ini berfungsi untuk mengumpulkan, menganalisa dan mendefinisikan kebutuhan serta fitur serta mendokumentasikan berbagai pihak yang berkepentingan (stakeholder) dan pengguna (user) dari sistem ini. Fokus pada kapabilitas kebutuhan dari stakeholder dan target user (Larman, 2005). 2.5.3.2 Glosary Secara umum dokumen ini berisi gambaran tentang profil stakeholder dan user yang berkepentingan terhadap pengembangan sistem ini termasuk permasalahan yang dihadapi oleh mereka serta solusi untuk mengatasi permasalahan tersebut. Untuk lebih memahami apa yang menjadi keinginan dan kebutuhan mereka maka bagian berikut akan dijelaskan profil setiap stakeholder dan user modul ini (Larman,.2005). 2.5.3.3 Supplementary spesifikasi Dokumen ini bertujuan untuk mengumpulkan, menganalisa, dan menghasilkan kebutuhan non fungsional dari. Yang termasuk dalam kebutuhan tersebut diantaranya:
22
system performance, security, reliability, usability, dan system environment (Larman, 2005). 2.5.4 Simple RUP Pada prinsipnya RUP secara simple (short) rediri dari usecase diagram, domain model, interaction diagram, dan class diagram (Larman,2005) Perhatikan gambar 2.4 dibawah ini:
Gambar 2.4 Simple RUP 2.5.5 analisis dan desain UML pada RUP Analisis UML pada RUP meliputi (Fowler, 2004) 1. Usecase diagram 2. Class diagram level analisis (domain model) 3. activity diagram 4. State diagram Desain UML pada RUP meliputi (Fowler, 2004) 1. Class diagrams 2. Sequence diagram 3. Package diagram 4. State diagram 5. Deployment diagram
23
2.6 Pengujian Black-Box Pengujian Black-Box terfokus pada spesifikasi fungsional dari perangkat lunak (Roger S. Pressman, Ph.D.). Penguji dapat mendefinisikan kumpulan kondisi input dan melakukan pengetesan pada spesifikasi fungsional program. Pengujian Black-Box bukanlah solusi alternatif dari pengujian White-Box tapi lebih merupakan pelengkap untuk menguji hal-hal yang tidak dicakup oleh pengujian White-Box. Pengujian Black-Box cenderung untuk menemukan kesaahan-kesalahan kategori dibawah ini (Roger S. Pressman, Ph.D.): 1. Fungsi yang tidak benar atau tidak ada 2. Kesalahan antarmuka (interface errors) 3. Kesalahan pada struktur data dan akses basis data 4. Kesalahan performansi (performance errors) 5. Kesalahan inisialisasi dan terminasi. Pengujian didesain untuk menjawab pertanyaan-pertanyaan berikut (Roger S. Pressman, Ph.D.): 1. Bagaimana fungsi-fungsi diuji agar dapat dinyatakan valid? 2. Input seperti apa yang dapat menjadi bahan kasus uji yang baik? 3. Apakah sistem sensitif pada input-input tertentu? 4. Bagaimana sekumpulan data dapat diisolasi? 5. Berapa banyak rata-rata data dan jumlah data yang dapat ditangani sistem? 6. Efek apa yang dapat membuat kombinasi data ditangani spesifik pada operasi sistem?
