CASE STUDY Masalah yang akan kita pecahkan adalah masalah perpustakaan universitas. Aplikasi yang ingin dikembangkan harus dapat mendukung pencarian bahan-bahan pustaka yang meliputi: buku, video dan CD ROM. Users akan memasukan Identitas (ID) anggota perpustakaan untuk menggunakan sistem pencarian melalui katalog pustaka. Persyaratan Setiap peminjaman dibatasi maksimum 5 item dimana waktu peminjamannya buku 14 hari, video 2 hari dan CD ROM 7 hari. Jika terlambat dikenakan denda untuk buku $0,5/hari, video $1,5/hari dan CD ROM $2,5/hari. Denda maksimum adalah $25 (tidak boleh pinjam lagi yang baru kalau belum dilunasi).
Spesifikasi Masalah Perpustakaan universitas minta dibuatkan sistem yang mendukung kegiatan perpustakaan. Pustakawan memperbolehkan mahasiswa meminjam beberapa bahan pustaka, mengembalikan bahan pustaka yang dipinjam, dan membayar denda. Jenis Denda per hari Lama peminjaman Buku: $ 0.50 14 hari Video: $ 1.5 2 hari CD Roms $ 2.50 7 hari Tanggal peminjaman dimulai ketika bahan pustaka yang dipinjam dikeluarkan. Mahasiswa yang sudah meminjam 5 jenis bahan pustaka atau denda lebih dari 25.00 tidak diperkenankan mendapat pinjaman bahan pustaka yang baru.
Identifikasi Kelas-kelas Abstraksi kunci dari pelaku-pelaku (obyek) yang memberikan model solusi adalah: Librarian (Pustakawan) User (Pemakai/Mahasiswa) Book (Buku) Video (Video) CD Rom 5 bahan pustaka
Diagram Kelas Diagram kelas memperlihatkan keberadaan dari kelas-kelas dan hubungan diantara mereka dalam pandangan logis dari sistem. Pertama mengidentifikasi kelompok awal dari kelas-kelas: pemakai (user), pustakawan (librarian), koleksi (collection), peminjam (borrower) , bahan pustaka (lendable), buku (book), video, CD ROM, dan tanggal (date). Kita dapat menarik garis-garis antara kelas untuk menggambarkan suatu hubungan. Dua kelas yang terhubung dapat memanggil suatu metoda atau menukar pesan-pesan.
Diagram Kelas Mula-mula
Inheritance Hierarchy lendable is the abstract class never instantiated concrete classes inheritance
Kenapa tidak satu kelas saja? Beberapa perilaku (persyaratan) berbeda: Perhitungan lama peminjaman Perhitungan denda keterlambatan Data berbeda Buku memiliki ISBN Video dapat diberi identifikasi studio Dapat dihimpun dalam kelas abstrak bahan pustaka (lendable)
Panah ditarik dari subkelas ke super kelas. Panah dari tiga kelas-kelas bahan pustaka ke kelas lendable menunjukkan inheritance dalam notasi blooch, artinya buku, video dan CD ROM adalah obyek-obyek untuk dipinjamkan. Pada gambar berikutnya titik hitam pada akhir garis menunjukkan adanya hubungan dimana kelas dengan titik hitam menunjukkan sisi pemilik (owner) atau pengguna fasilitas.
Diagram Kelas Pass Kedua
Diagram Obyek Diagram obyek tujuannya untuk memperlihatkan keberadaan obyek-obyek, hubungan antara obyek dalam pandangan logis dari sistem, dan bagaimana mereka melaksanakan suatu skenario tertentu atau kasus. Dalam suatu skenario, kita mengidentifikasi setiap tugas (task) yang harus ditangani sistem dan memberikan tugas tersebut ke kelas yang menangani ini. Metode Blooch kadang kala mengacu pada suatu teknik perancangan disebut metoda responsibility-driven design.
Diagram skenario obyek untuk memeriksa keluarnya suatu buku
Gambar Hubungan-hubungan
CRH Card untuk abstract class
Diagram Modul Diagram modul memperlihatkan alokasi dari kelas-kelas dan obyek-obyek ke modul-modul dalam tampilan fisik suatu sistem.
Menrancang C++ Class Definitions class lendable { // first draft public: // ... bool isOverdue(); bool isAvailable(); void checkSelfIn(); void checkSelfOut(string borrowersID); private: // TBA };
Contoh class book : public lendable { public: //--constructor book(string initID, string initAuthor, string initTitle); //--virtual functions that must be implemented Date computeDueDate() const; double computeLateFee() const; //--additional accessors string author(); string title(); private: string my_author; // Additional data members string my_title; };
UML Diagrams Modeling Diagrams Use case Interaction Class Sequence Collaboration Class State Transition Component Deployment Use Case Relationship Actor Object State Deployment Component Component Use case diagrams are created to visualize the relationships between actors and use cases A sequence diagram displays object interactions arranged in a time sequence A collaboration diagram displays object interactions organized around objects and their links to one another A class diagram shows the existence of classes and their relationships in the logical view of a system A class is a collection of objects with common structure, common behavior, common relationships and common semantics A state transition diagram shows The life history of a given class The events that cause a transition from one state to another The actions that result from a state change Component diagrams illustrate the organizations and dependencies among software components The deployment diagram shows the configuration of run-time processing elements and the software processes living on them Class