CASE STUDY Masalah yang akan kita pecahkan adalah masalah perpustakaan universitas. Aplikasi yang ingin dikembangkan harus dapat mendukung pencarian bahan-bahan.

Presentasi berjudul: "CASE STUDY Masalah yang akan kita pecahkan adalah masalah perpustakaan universitas. Aplikasi yang ingin dikembangkan harus dapat mendukung pencarian bahan-bahan."— Transcript presentasi:

1 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).

2 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: $ hari Video: $ hari CD Roms $ hari Tanggal peminjaman dimulai ketika bahan pustaka yang dipinjam dikeluarkan. Mahasiswa yang sudah meminjam 5 jenis bahan pustaka atau denda lebih dari tidak diperkenankan mendapat pinjaman bahan pustaka yang baru.

3 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

4 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.

5 Diagram Kelas Mula-mula

6 Inheritance Hierarchy
lendable is the abstract class never instantiated concrete classes inheritance

7 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)

8 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.

9 Diagram Kelas Pass Kedua

10 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.

11 Diagram skenario obyek untuk memeriksa keluarnya suatu buku

12 Gambar Hubungan-hubungan

13 CRH Card untuk abstract class

14 Diagram Modul Diagram modul memperlihatkan alokasi dari kelas-kelas dan obyek-obyek ke modul-modul dalam tampilan fisik suatu sistem.

15 Menrancang C++ Class Definitions
class lendable { // first draft public: // ... bool isOverdue(); bool isAvailable(); void checkSelfIn(); void checkSelfOut(string borrowersID); private: // TBA };

16 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; };

17

18

19 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