• Tidak ada hasil yang ditemukan

Bagian ini memuat kesimpulan dari penelitian yang telah dilakukan serta saran untuk penelitian selanjutnya.

1.7 Tinjauan Pustaka

Penelitian terdahulu yang relevan dengan penelitian ini yaitu penelitian yang dilakukan oleh Peniarsih (2012) yang berjudul “Analisis dan Perancangan Sistem Informasi Akademik Universitas Suryadarma Jakarta”. Dalam penelitian ini, penulis bertujuan untuk membuat analisis dan perancangan sistem informasi akademik yang dapat menggantikan sistem konvensional yang hanya menggunakan Microsoft Excel dalam proses pengolahan data, selain itu agar proses pengolahan data-data nilai mahasiswa menjadi lebih baik dan mampu disajikan menjadi suatu informasi yang berguna bagi pengguna, serta mampu memberikan pelayanan yang lebih baik kepada mahasiswa. Pada penelitian ini, sistem dirancang dan diimplementasikan dalam bentuk prototype. Dengan adanya perancangan dalam bentuk prototype ini, diharapkan akan dapat memberikan kemudahan dalam perekayasaan pengembangan aplikasi kedepannya. Pada penelitian ini disimpulkan bahwa dengan penerapan dan pemanfaatan sistem informasi akademik bisa menjadi solusi alternatif pelaksaan pekerjaan sesuai tugas pokok dan fungsi bagi pengguna sistem.

Penelitian lainnya yang dilakukan oleh Jupriyanto dan Ramadlan Agus Triono (2013) yang berjudul “Pembangunan Sistem Informasi Kartu Rencana Studi (KRS) dan Kartu Hasil Studi (KHS) On Line pada Sekolah Tinggi Ilmu Tarbiyah Nahdlatul Ulama (STITNU) Pacitan”. Pada penelitian ini, penulis bertujuan untuk menghasilkan sistem informasi KRS dan KHS online yang dibangun dengan menggunakan bahasa pemrograman PHP dan menggunakan pengolahan database MySql. Serta untuk menerapkan Sistem Informasi Akademik online dan meningkatkan pelayanan pada Sekolah Tinggi Ilmu Tarbiyah Nahdlatul Ulama (STITNU) Pacitan. Metode yang dilakukan oleh penulis dalam menyusun penelitian yaitu, studi kepustakaan, observasi survey langsung di tempat penelitian dan menganalisa permasalahan, wawancara, analisis sistem, perancangan sistem, pembangunan sistem, uji coba, dan

implementasi sistem. Hasil dari penelitian ini adalah Sistem Informasi akademik online mampu meningkatkan pelayanan akademik di STITINU pacitan dan mempermudah pengelolaan data KRS dan KHS. Selain itu, Dengan sistem informasi akademik ini, mahasiswa akan mendapatkan kemudahan dalam mengakses KRS, KHS dan Transkrip secara online.

Penelitian lainnya yang dilakukan André Vasconcelos, Miguel Mira da Silva, António Fernandes, dan José Tribolet (2004) yang berjudul “An Information System Architectural Framework for Enterprise Application Integration”. Pada tahap awal penelitian ini, disajikan gambaran arsitektur sistem informasi dan kemudian dilanjutkan dengan pengenalan singkat ke berbagai model integrasi yang ada dan berusaha mengungkapkan gagasan bahwa semua masalah integrasi dapat diselesaikan dengan Web Service. Pada penelitian ini, disajikan studi kasus untuk menggambarkan masalah integrasi antara sistem informasi. Secara khusus, pada penelitian ini mengusulkan bahwa integrasi harus memiliki sejumlah karakteristik (misalnya manual atau otomatis) dan tidak terbatas hanya pada layanan sinkronisasi saja.

Berdasarkan penelitian yang yang telah dipaparkan sebelumnya, pada penelitian ini akan dibuat Sistem Informasi Akademik yang dapat mempermudah proses pengolahan data akademik dan mampu memberikan hasil pengolahan data dalam bentuk pelaporan-pelaporan dan grafik. Serta memiliki integrasi dengan sistem lain yang berhubungan dengan Sistem Informasi Akademik seperti Sistem Informasi Kepegawaian dan Sistem Informasi Alumni.

8

BAB II

LANDASAN TEORI

2.1 Sistem Informasi Akademik

Sistem Informasi Akademik (Siakad) merupakan sistem yang secara khusus dirancang untuk memenuhi kebutuhan perguruan tinggi yang menginginkan layanan yang terkomputerisasi untuk meningkatkan kinerja, kualitas pelayanan, daya saing dan kualitas sumber daya manusia yang dihasilkannya (Rahmawati, 2012).

Sistem Informasi Akademik (Siakad) merupakan sumber daya terhadap segala sesuatu dalam bentuk informasi yang ada kaitannya dengan masalah – masalah akademik di kampus (Fedi Rahadi Noviandi, 2012).

Berdasarkan kedua pengertian yang telah dipaparkan sebelumnya, maka dapat disimpulkan bahwa Sistem Informasi Akademik (Siakad) merupakan sistem informasi yang secara khusus dirancang untuk memenuhi kebutuhan akademik dalam sebuah instansi pendidikan, dimana sistem tersebut kaya akan data akademik dan hanya dapat digunakan oleh pihak yang memiliki hak akses ke dalam sistem informasi tersebut.

Adapun manfaat diimplementasikannya Siakad dalam sebuah instansi pendidikan adalah sebagai berikut :

1. Manfaat untuk dosen

a) Proses memasukan dan pengumuman nilai mahasiswa dapat dilakukan di luar lingkungan kampus.

b) Siakad dapat melakukan validasi terhadap data yang akan direkamnya sehingga data yang masuk ke dalam basis data teratur.

c) Siakad dapat membantu dosen pembimbing akademik dalam memantau nilai mahasiswa. Hal tersebut secara tidak langsung dapat membantu dosen dalam membuat keputusan, seperti pemberian SKS, beasiswa, pengambilan mata kuliah bersyarat dan lain sebagainya.

d) Secara tidak langsung Siakad dapat meningkatkan kualitas sumber daya manusia yang menggunakannya.

2. Manfaat untuk staf akademik

a) Memudahkan staf dalam mendata dan memantau keadaan akademik mahasiswa.

b) Membantu staf dalam mengambil keputusan, seperti pemberian beasiswa, pemberian SKS, pengambilan mata kuliah bersyarat dan lain sebagainya.

c) Memudahkan staf dalam membuat pelaporan, seperti absen mahasiswa per mata kuliah, jadwal kuliah, pembuatan KHS dan lain sebagainya. d) Siakad dapat diakses walaupun staf sedang berada di luar lingkungan

kampus.

e) Menekan biaya operasional.

3. Manfaat untuk mahasiswa

a) Siakad dapat diakses walaupun mahasiswa sedang berada di luar kampus.

b) Mahasiswa dapat melihat pengumuman nilai dan mengambil transkrip atau KHS walaupun berada di luar lingkungan kampus.

c) Mahasiswa dapat melakukan penawaran mata kuliah dan mencetak KRS meskipun berada di luar lingkungan kampus.

d) Mahasiswa dapat memantau keadaan akademiknya sendiri.

2.2 Evaluasi Program Studi Berbasiskan Evaluasi Diri (EPSBED)

Evaluasi Program Studi Berbasiskan Evaluasi Diri (EPSBED) merupakan laporan wajib yang dilaporkan kepada DIKTI dan Kopertis setiap pergantian tahun akademik. Pada semester genap batas penyetoran laporan EPSBED jatuh pada 15 April dan semester ganjil pada 15 Oktober. Laporan EPSBED disetorkan melalui halaman http://evaluasi.or.id.

Adapun hal – hal yang mendasari penyetoran laporan EPSBED kepada DIKTI dan Kopertis setiap pergantian tahun akademik adalah sebagai berikut :

1. Evaluasi dilakukan dalam rangka pengendalian mutu pendidikan secara nasional sebagai bentuk akuntabilitas penyelenggara pendidikan kepada pihak-pihak yang berkepentingan (UU No.20/2003).

2. Setiap perguruan tinggi wajib melaporkan kegiatan proses belajar mengajar setiap akhir semester kepada Diretorat Jenderal Pendidikan Tinggi dan Kopertis (Kepmendiknas 184/ 2001).

3. Setiap perguruan tinggi wajib melaporkan proses belajar mengajar selambat – lambatnya satu bulan terhitung sejak akhir semester kepada Direktorat Jenderal Pendidikan Tinggi dan Kopertis dengan menggunakan format sebagaimana dalam lampiran keputusan ini disertai kalender akademik (SK Dirjen Dikti No. 08/ 2002).

4. Sebagai pelaksanaan dari Pasal 5 Kepmendiknas No. 184/ 2001, maka perguruan tinggi wajib melaporkan proses belajar mengajar setiap progeam studinya selambat – lambatnya satu bulan terhitung sejak akhir semester kepada Dirjen DIKTI dan bagi PTS melalui Kopertis sesuai dengan Pedoman Evaluasi Kelayakan Penyelenggaraan Program Studi Atas Dasar Evaluasi Diri sebagaimana dalam lampiran Keputusan ini dengan menggunakan perangkat media data penyimpanan elektronik tanpa lampiran (SK DIKTI No. 34/ 2002).

Adapun manfaat dari dilakukannya pembuatan dan pelaporan data EPSBED kepada DIKTI dan Kopertis adalah sebagai berikut :

1. EPSBED dapat digunakan sebagai bahan evaluasi internal untuk masing – masing perguruan tinggi dan masing – masing program studinya.

2. EPSBED merupakan data pendukung untuk akreditasi BAN – PT. 3. EPSBED dapat digunakan oleh BAN – PT sebagai data komparasi

4. EPSBED juga digunakan sebagai persyaratan hal – hal berikut : a) Izin Penyelenggaraan Program Studi

b) Laporan kinerja dosen

c) Pengajuan Nomor Induk Dosen Nasional (NIDN) d) Mutasi mahasiswa

e) Pelaksanaan wisuda

f) Pencarian data alumni oleh pengguna (tracer study) g) Borang Akreditasi

Komponen dari laporan EPSBED adalah sebagai berikut :

a) Identitas program studi, perguruan tinggi dan Badan Hukum Penyelenggara.

b) Kurikulum Program Studi.

c) Identitas dosen dan penugasannya setiap semester. d) Jumlah penelitian dosen.

e) Identitas mahasiswa, beban belajar setiap semester dan raihan prestasinya.

f) Fasilitas perpustakaan dan laboratorium.

2.3 Pemrograman Berorientasi Objek

Metodologi berorientasi objek adalah suatu strategi pembangunan perangkat lunak yang mengorganisasikn perangkat lunak sebagai kumpulan objek yang berisi data dan operasi yang diberlakukan terhadapnya. Secara sederhana, didalam teknik pemrograman berorientasi objek, pemogram mendefinisikan data yang akan diproses dalam program sebagai objek – objek. Beberapa bahasa pemrograman yang mendukung konsep berorientasi objek adalah bahasa pemrograman Smalltalk, Eiffel, C++, PHP dan Java.

Komponen dari sebuah program yang dibangun dengan konsep berorientasi objek adalah sebagai berikut :

a. Kelas (class)

Kelas adalah kumpulan objek – objek dengan karakteristik yang sama. Sebuah kelas akan mempunyai sifat (atribut), kelakukan (operasi/ metode), hubungan dan arti.

b. Objek (object)

Objek merupakan suatu entitas yang mampu menyimpan informasi (status) dan mempunyai operasi (kelakuan) yang dapat diterapkan atau dapat berpengaruh pada status objeknya. Objek mempunyai siklus hidup yaitu diciptakan, dimanipulasi dan dihancurkan. Secara sederhana, jika masih dalam bentuk kode maka disebut sebagai kelas sedangkan apabila dieksekusi, maka kelas tersebut akan menjadi objek.

c. Metode (method)

Operasi atau metode pada sebuah kelas hampir sama dengan fungsi atau prosedur pada pemrograman terstruktur. Sebuah kelas boleh memiliki lebih dari satu metode atau operasi. Metode atau operasi berfungsi untuk memanipulasi objek itu sendiri. Operasi atau metode merupakan fungsi atau transformasi yang dapat dilakukan terhadap objek atau dilakukan oleh objek.

d. Atribut (attribute)

Atribut dari sebuah kelas adalah variabel global yang dimiliki oleh sebuah kelas. Atribut dapat berupa nilai atau elemen – elemen data yang dimiliki oleh objek dalam kelas objek. Atribut dipunyai secara individual oleh sebuah objek, misalnya berat, jenis, nama dan sebagainya. Atribut sebaiknya bersifat privat untuk menjaga konsep enkapsulasi.

e. Abstraksi (abstraction)

Abstraksi merupakan prinsip untuk merepresentasikan dunia nyata yang kompleks menjadi satu model yang sederhana dengan mengabaikan aspek – aspek lain yang tidak sesuai dengan permasalahan.

f. Enkapsulasi (encapsulation)

Enkapsulasi merupakan pembungkusan atribut data dan layanan (operasi – operasi) yang dipunyai objek untuk menyembunyikan implementasi dan objek sehingga objek lain tidak mengetahui cara kerjanya.

g. Pewarisan (inheritance)

Mekanisme yang memungkinkan satu objek mewarisi sebagian atau seluruh definisi dan objek lain sebagai bagian dari dirinya.

h. Antarmuka (interface)

Antarmuka atau interface sangat mirip dengan kelas, tapi tanpa atribut kelas dan memiliki metode yang dideklarasikan tanpa isi.

i. Reusability

Pemanfaatan kembali objek yang sudah didefinisikan untuk suatu permasalahan pada permasalahan lainnya yang melibatkan objek tersebut.

j. Generalisasi dan speliasasi

Menunjukan hubungan antara kelas dan objek yang umum dengan kelas dan objek yang khusus.

k. Komunikasi antar objek

Komunikasi antar objek dilakukan lewat pesan yang dikirim dari satu objek ke objek lainnya.

l. Polimorfisme (polymorphism)

Kemampuan suatu objek untuk digunakan di banyak tujuan yang berbeda dengan nama yang sama sehingga menghemat baris program. m. Package

Package adalah sebuah kontainer atau kemasan yang dapat digunakan untuk mengelompokan kelas – kelas sehingga memungkinkan beberapa kelas yang bernama sama disimpan dalam package yang berbeda.

Keuntungan menggunakan pemrograman berorientasi objek adalah sebagai berikut :

1. Meningkatkan produktivitas

Bekerja dengan pemrograman berorientasi objek dapat meningkatkan produktivitas karena objek dapat digunakan ulang (reusability).

2. Kecepatan pengembangan

Sistem yang dibangun dengan baik dan benar pada saat analisis dan perancangan akan menyebabkan berkurangnya kesalahan saat pengkodean.

3. Kemudahan pemeliharaan

Bekerja dengan objek membuat pola – pola yang cenderung cepat dan stabil dapat dipisahkan dengan pola – pola yang mungkin sering berubah – ubah.

4. Adanya konsistensi

Konsistensi dapat dicapai karena adanya sifat pewarisan dan penggunaan notasi yang sama pada saat analisis, perancangan maupun pengkodean.

5. Meningkatkan kualitas perangkat lunak

Hal ini dapat dicapai karena perangkat lunak yang dihasilkan akan mampu memenuhi kebutuhan pemakai serta mempunyai sedikit kesalahan.

2.4 Rational Unified Process

Rational Unified Process (RUP) adalah tahapan pengembangan sistem secara iteratif khusus untuk pemrograman berorientasi objek. RUP menyediakan pendefinisian struktur hidup yang baik untuk alur hidup proyek perangkat lunak. RUP adalah sebuah produk proses perangkat lunak yang dikembangkan oleh Rational Software yang diakusisi oleh IBM di bulan Februari 2003 (Rosa A. S. dan M. Shalahuddin, 2013).

RUP memiliki empat buah tahap atau fase yang dapat dilakukan pula secara iteratif. Berikut ini penjelasan untuk setiap fase pada RUP (Rosa A. S. dan M. Shalahuddin, 2013).

1. Permulaan (Inception)

Tahap ini lebih pada memodelkan proses bisnis yang dibutuhkan dan mendefinisikan kebutuhan akan sistem yang akan dibuat. Berikut adalah tahap yang dibutuhkan :

a) Memahami ruang lingkup dari proyek (termasuk pada biaya, waktu, kebutuhan, resiko dan sebagainya).

b) Membangun kasus bisnis yang dibutuhkan.

Hasil yang diharapkan dari tahap ini adalah memenuhi batas/ tonggak objektif dari siklus dengan kriteria berikut :

a) Umpan balik dari pendefinisian runag lingkup, perkiraan biaya dan perkiraan jadwal.

b) Kebutuhan dimengerti dengan pasti (dapat dibuktikan) dan sejalan dengan kasus primer yang dibutuhkan.

c) Kredibilitas dari perkiraan biaya, perkiraan jadwal, penentuan skala prioritas, resiko dan proses pengembangan.

d) Ruang lingkup purwarupa yang akan dikembangkan.

e) Membangun garis dasar dengan membandingkan perencanaan aktual dengan perencanaan yang direncanakan.

Jika pada akhir tahap ini target yang diinginkan tidak dicapai maka dapat dibatalkan atau diulang kembali setelah dirancang ulang agar kriteria yang diinginkan dapat dicapai. Batas/ tonggak objektif digunakan untuk mendeteksi apakah sebuah kebutuhan akan sistem dapat diimplementasikan atau tidak.

2. Perluasan/ Perencanaan (Elaboration)

Tahap ini lebih difokuskan pada perencanaan arsitektur sistem. Tahap ini juga dapat mendeteksi apakah arsitektur sistem yang diinginkan dapat dibuat atau tidak. Tahap ini lebih pada analisis dan desain sistem serta implementasi sistem yang fokus pada purwarupa sistem. Hasil yang diharapkan dari tahap ini adalah memenuhi batas/ tonggak arsitektur dari siklus dengan kriteria berikut :

a) Model kasus yang digunakan (use case) dimana kasus dan aktor yang terlibat telah diidentifikasikan dan sebagian besar kasus harus dikembangkan. Model use case harus 80% lengkap dibuat.

b) Deksripsi dari arsitektur perangkat lunak dari proses pengembangan sistem perangkat lunak telah dibuat.

c) Rancangan arsitektur yang dapat diimplementasikan dan mengimplementasikan use case.

d) Kasus bisnis atau proses bisnis dan daftar risiko yang sudah mengalami perbaiki (revisi) telah dibuat.

e) Rencana pengembangan untuk seluruh proyek telah dibuat.

f) Purwarupa yang dapat didemonstrasikan untuk mengurangi setiap resiko teknik yang diidentifikasi.

Jika pada akhir tahap ini target yang diinginkan tidak dicapai maka dapat dibatalkan atau diulang kembali.

3. Konstruksi (Construction)

Tahap ini fokus pada pengembangan komponen dan fitur – fitur sistem. Tahap ini lebih pada implementasi dan pengujian sistem yang fokus pada implementasi perangkat lunak pada kode program. Tahap ini menghasilkan produk perangkat lunak dimana menjadi syarat dari batas/ tonggak kemampuan operasional awal.

4. Transisi (Transition)

Tahap ini lebih pada instalasi sistem agar dapat dimengerti oleh pengguna. Tahap ini menghasilkan produk perangkat lunak dimana menjadi syarat dari batas/ tonggak kemampuan operasional awal. Aktifitas pada tahap ini termasuk pada pelatihan pengguna, pemeliharaan dan pengujian sistem apakah sudah memenuhi harapan pengguna.

Akhir dari keempat fase ini adalah produk perangkat lunak yang sudah lengkap. Keempat fase pada RUP dijalankan secara berurutan dan iteratif dimana setiap iterasi dapat digunakan untuk memperbaiki iterasi berikutnya.

2.5 Unified Modeling Language

Unified Modeling Language (UML) adalah salah satu standar bahasa yang banyak digunakan di dunia industri untuk mendefinisikan kebutuhan, membuat analisis dan desain, serta menggambarkan arsitektur dalam pemrograman beorientasi objek (Rosa A. S. dan M. Shalahudin, 2013). UML muncul karena adanya kebutuhan pemodelan visual untuk menspesifikasikan, menggambarkan, membangun dan dokumentasi dari sistem perangkat lunak.

Dalam terapannya, UML digambarkan dalam bentuk diagram. Diagram dalam UML terbagi atas tiga kategori, yaitu sebagai berikut :

1. Structure diagrams yaitu kumpulan diagram yang digunakan untuk menggambarkan suatu struktur statis dari sistem yang dimodelkan. Salah satu diagram yang menjadi bagian dari structure diagrams adalah diagram kelas.

2. Behaviour diagrams yaitu kumpulan diagram yang digunakan untuk menggambarkan kelakuan sistem atau rangkaian perubahan yang terjadi pada sebuah sistem. Adapun diagram yang menjadi bagian dari behaviour diagrams adalah diagram use case dan diagram aktivitas. 3. Interaction diagrams yaitu kumpulan diagram yang digunakan untuk

antar subsistem pada suatu sistem. Adapun diagram yang menjadi bagian dari interaction diagrams adalah diagram sekuens.

2.5.1 Diagram Use Case

Diagram use case merupakan pemodelan untuk kelakuan (behavior) sistem informasi yang akan dibuat. Use case digunakan untuk mengetahui fungsi apa saja yang ada di dalam sebuah sistem informasi dan siapa saja yang berhak menggunakan fungsi – fungsi itu. Syarat penamaan pada use case adalah nama didefinisikan dengan sederhana dan mudah dipahami.

Ada dua hal utama pada use case yaitu pendefinisian apa yang disebut aktor dan use case. Adapun uraian dari aktor dan use case adalah sebagai berikut :

a) Aktor merupakan orang, proses atau sistem lain yang berinteraksi dengan sistem informasi yang akan dibuat di luar sistem informasi yang akan dibuat itu sendiri, jadi walaupun simbol dari aktor adalah gambar orang, tapi aktor belum tentu merupakan orang.

b) Use case merupakan fungsionalitas yang disediakan sistem sebagai unit – unit yang saling bertukar pesan antar unit atau aktor.

Adapun simbol – simbol yang digunakan dalam diagram use case adalah sebagai berikut :

Tabel 2.1 Simbol diagram use case

Simbol Nama Deskripsi

Use Case Fungsionalitas yang disediakan sistem sebagai unit – unit yang saling bertukar pesan antar unit atau aktor; biasanya dinyatakan dengan menggunakan kata kerja di awal frase nama use case.

Aktor Orang, proses, atau sistem lain yang berinteraksi dengan sistem informasi yang akan dibuat di luar sistem informasi yang akan dibuat itu sendiri, jadi walaupun simbol dari aktor adalah gambar orang, tapi belum tentu merupakan orang; biasanya dinyatakan menggunakan kata benda di awal frase nama aktor.

Asosiasi Komunikasi antara aktor dan use case yang berpartisipasi pada use case atau use case memiliki interaksi dengan aktor.

Ekstensi (extend)

Relasi use case tambahan ke sebuah use case dimana use case yang ditambahkan dapat berdiri sendiri walau tanpa use case tambahan itu; mirip dengan prinsip pewarisan pada pemrograman berorientasi objek; biasanya use case tambahan memiliki nama depan yang sama dengan nama use case yang ditambahkan; biasanya use case yang menjadi ekstensinya merupakan jenis yang sama dengan use case yang menjadi induknya. Generalisasi Hubungan generalisasi dan spesialisasi

(umum – khusus) antara dua buah use case dimana fungsi yang satu adalah fungsi yang lebih umum dari yang lainnya.

Menggunakan (include)

Relasi use case tambahan ke sebuah use case dimana use case yang ditambahkan memerlukan use case ini untuk menjalankan fungsinya atau sebagai syarat dijalankan use case ini.

20

2.5.2 Diagram Kelas

Diagram kelas menggambarkan struktur sistem dari segi pendefinisian kelas yang akan dibuat untuk membangun sistem. Kelas memiliki atribut dan metode atau operasi. Atribut merupakan variabel – variabel yang dimiliki suatu kelas. Operasi atau metode adalah fungsi – fungsi yang dimiliki oleh suatu kelas. Susunan struktur kelas yang baik pada diagram kelas sebaiknya memiliki jenis – jenis kelas berikut : a) Kelas main

Kelas yang memiliki fungsi awal dieksekusi ketika sistem dijalankan.

b) Kelas yang menangani tampilan sistem (view)

Kelas yang mendefinisikan dan mengatur tampilan ke pemakai. c) Kelas yang diambil dari pendefinisian use case (controller)

Kelas yang menangani fungsi – fungsi yang harus ada diambil dari pendefinisian use case, kelas ini biasanya disebut dengan kelas proses yang menangani proses bisnis pada perangkat lunak.

d) Kelas yang diambil dari pendefinisian data (model)

Kelas yang digunakan untuk memegang atau membungkus data menjadi sebuah kesatuan yang diambil maupun akan disimpan ke basis data.

Adapun simbol – simbol yang digunakan dalam diagram kelas adalah sebagai berikut :

Tabel 2.2 Simbol diagram kelas

Simbol Nama Deskripsi

Kelas Kelas pada stuktur pada sistem.

Antarmuka (interface)

Sama dengan konsep antarmuka dalam pemrograman berorientasi objek.

Asosiasi Relasi antar kelas dengan makna umum, asosiasi biasanya juga disertai dengan multipicity.

Asosiasi Berarah (directed association)

Relasi antar kelas dengan makna kelas yang satu digunakan oleh kelas yang lain, asosiasi biasanya juga disertai dengan multiplicity.

Generalisasi Relasi antar kelas dengan makna generalisasi – spesialisasi (umum khusus).

Kebergantungan (dependency)

Relasi antar kelas dengan makna kebergantungan antar kelas.

Agregasi (aggreggation)

Relasi antar kelas dengan makna semua bagian (whole part).

2.5.3 Diagram Aktivitas

Diagram aktivitas menggambarkan aliran kerja (workflow) atau aktivitas dari sebuah sistem atau proses bisnis atau menu yang ada pada perangkat lunak. Diagram aktivitas menggambarkan aktivitas sistem bukan apa yang dilakukan aktor.

Diagram aktivitas juga banyak digunakan untuk mendefinisikan hal – hal berikut :

e) Rancangan proses bisnis dimana setiap urutan aktivitas yang digambarkan merupakan proses bisnis sistem yang didefinisikan. f) Urutan atau pengelompokan tampilan dari sistem atau antarmuka

dimana setiap aktivitas dianggap memiliki sebuah rancangan antarmuka tampilan.

g) Rancangan pengujian dimana setiap aktivitas dianggap memerlukan sebuah pengujian yang perlu didefinisikan kasus ujinya.

Adapun simbol – simbol yang digunakan dalam diagram kelas adalah sebagai berikut :

Tabel 2.3 Simbol diagram aktivitas

Simbol Nama Deskripsi

Status Awal Status awal aktivitas sistem, sebuah diagram aktivitas memiliki sebuah status awal

Aktivitas Aktivitas yang dilakukan sistem, aktivitas biasanya diawali dengan kata kerja.

Percabangan (decision)

Asosiasi percabangan dimana jika ada

Dokumen terkait