Pertemuan ke 11

Contoh  Terdapat class dengan nama Segiempat yang akan menerima sebuah nilai untuk sisi dari segiempat, validasi nilai, perhitungan dan display area dari segiempat tsb. Segiempat ini mempunyai sebuah child, yaitu class Kubus yang akan menggunaan method dari induknya untuk menerima dan validasi sisi dari Kubus dan membuat method baru untuk menghitung dan men-display volume dari Kubus tsb.

1. Identifiasi Class & Atribut,responsibilities & Operasi ClassAtributResponsibilitiesOperasi SegiempatSisiMenerima sebuah nilai dari sisi Validasi nilai Perhitungan dan display area KubusPehitungan dan display volume ClassAtributResponsibilitiesOperasi SegiempatSisiMenerima sebuah nilai dari sisi Validasi nilai Perhitungan dan display area +SetSisi() +ValidasiSisi() +PerhitunganAreaSEmpat() KubusPehitungan dan display volume +PerhitunganVolumeKubus()

2. Menentukan Relasi antara Objek-objek dengan Class Segiempat - Sisi +SetSisi() +ValidasiSisi() +PerhitunganAreaSEmpat() Kubus +PerhitunganVolumeKubus()

A. SEGIEMPAT SetSisi(PanjangSisi) sisi=PanjangSisi END ValidasiSisi(validInput) validIput=true IF sisi NOT numeric THEN validInput=false ELSE IF sisi < 0 THEN validInput=false ENDIF END 3. Disain algoritma untuk operasi menggunaan disain struktur PerhitunganAreaSEmpat() ValidasiSisi(validInput) IF validInput AreaSEmpat=sisi*sisi Display ‘Area segiempat dengan sisi’, sisi,’ adalah’,AreaSEmpat ELSE Display ‘inputan salah!’, sisi ENDIF END

B. KUBUS PerhitunganVolumeKubus() ValidasiSisi(validInput) IF validInput VolumeKubus=sisi*sisi*sisi Display ‘Volume Kubus dengan sisi’, sisi,’ adalah’,VolumeKubus ELSE Display ‘inputan salah!’, sisi ENDIF END

TestSegiempatKubus() Create segiempat1 as new Segiempat() Create kubus1 as new Kubus() PanjagSisi=5 segiempat1.setsisi(panjangsisi) segiempat1. PerhitunganAreaSEmpat() kubus1. setsisi(panjangsisi) kubus1. perhitunganVolumeKubus() END 4. Testing OUTPUT Area segiempat dengan sisi 5 adalah 25 Volume Kubus dengan sisi 5 adalah 125

Latihan  Disain sebuah class induk dengan nama Pegawai, yang dapat menghitung upah per-minggu untuk pegawai fulltime. Pada class ini menerima data pegawai (No.pegawai, nama dan upah per jam), validasi upah (harus numerik dan kurang dari atau sama dengan $30/jam), dan perhitungan upah pegawai per minggu. Asumsi: semua pegawai bekerja 38 jam per minggu. Disain juga child class dengan nama pegawai Part-Time yang akan menggunakan atribut dan method yang ada pada class induk Pegawai.Class Pegawai part-time akan menerima data pegawai (jam kerja), validasi (jam kerja harus sah dan kurang dari 38) dan menghitung upah pegawai per minggu. Kedua class tersebut akan menampilan(dislay) no.pegawai, nama dan upah mingguan.

Pertemuan ke 11

Perkembangan Metode Analisis dan Desain Sistem  Metode Tradisional  Metode Terstruktur  Metode berorientasi objek (Object Oriented)

Metode Tradisional  Berkembang dari pemrograman tradisional  Kontrol Alur (urutan, keputusan, loop)  Sistem Flow Chart  Hampir selalu dimulai dengan pemikiran tentang file secara fisik  Tidak berorientasi pada kebutuhan informasi

Metode Terstruktur  Dimulai pada tahun 1977  Dimulai dengan mencoba melihat sistem dari sudut pandang logical  Melihat data sebagai sumber proses Metode DFD (control flow, State Transistion diagram) E-R Diagram

Metode Terstruktur Invoice Invoice_no Cust_name Date_Purchase Item_no Description Unit_Price Quantity Total Total_amount Invoice Invoice_no Cust_no Date_Purchas e Total_amount Customer Cust_no Cust_name Cust_address Balance Inv_detail Invoice_no Item_no Unit_Price Quantity Total Inventory Item_no Item name Unit_price Qty_on_hand Qty_purchased Amnt_purchased Qty_sold Amnt_sold

Activity Breakdown by Size Mengapa perlu membuat rencana gambar yang jelas dalam pembuatan software ?

Systems Analysis Requirements Elicitation: Interview, Questionnaire, Document review, Form review, Observation Requirements Analysis: Modelling, Completeness & Consistency Checking

A Typical Waterfall Life Cycle Preliminary Analysis Design Program- ming Testing Conversion

Metode Object Oriented  Mulanya dari OOP (Object Oriented Programming) yang berkembang menjadi OOD (Object Oriented Design) dan akhirnya menjadi OOA (Object Oriented Analysis)  Berhubungan erat dengan E-R Model  Keuntungannya dari analisa, design sampai ke implementasi menggunakan notasi yang sama  Makin banyak organisasi yang mengimplementasikan metoda OO

Sejarah Singkat Perkembangan OO mid 70 – end of 80Pendekatan dengan analisa & rancangan dengan menggunakan metode OO mulai diperkenalkan Karena saat itu aplikasi software mulai meningkat dan komplek maka metoda OO mulai diuji cobakan & diaplikasikan Seperti : Grady Booch dari Rational Software Co. dengan (OOSE - Object Oriented Software Engineering). James Rumbaugh dari General Electric dengan (OMT – Object Modeling Technique). Ivar Jacobson dari Objectory

OMG (Object Management Group) Badan yang bertugas mengeluarkan standar-standar teknologi object oriented dan software component.

Traditional, top-down approach

Use-case driven, architecture- centric, and incremental approach

Konsep Object  Encapsulation  Polymorphism  Inheritance

ENCAPSULATION (Pembungkusan) Menyembunyikan komplekitas dari luar dan hanya membuka operasi-operasi yang diperlukan saja terhadap objek-objek lain.

ENCAPSULATION (Pembungkusan) Membaca Kartu - NoKartu +TerimaKartu() + KartuKeluar() + BacaKartu() Layar ATM + Isian() + TerimaMasukan() Account -NoAccount -Pin -Saldo +Buka() +TarikDana() +PotongDana() +VerifikasiDana() DispenserTunai - SaldoTunai +SediakanTunai() +SediakaTandaBukti()

POLYMORPHISM Melakukan metoda yang sama dengan algoritma yang berbeda. Contoh: Perintah gambar dapat dilakukan dengan memangi fungsi Drawme() untuk setiap objek  garis, elips, lingkaran, dsb Function draw) { Shape.drawMe(); }

Inheritance (Pewarisan)  Objek anak mewarisi segala sesuatu dari objek induk

Keuntungan dari OO  Merupakan konsep yang umum yang dapat digunakan untuk memodel hampir semua phenomena dan dapat dinyatakan dalam bahasa umum (natural language)  Kata Benda / Nouns menjadi object atau class  Kata Kerja / Verbs menjadi behaviour  Kata Keterangan / Adjectives menjadi attributes  Memberikan informasi yang jelas tentang context dari system  Mengurangi biaya maintenance  Memudahkan untuk mencari hal yang akan diubah  Membuat perubahan menjadi local, tidak bepengaruh pada modul yang lainnya

TINGKAH LAKU SISTEM  Behavior sistem didokumentasi di dalam suatu model use case yang meng-ilustrasi-kan fungsi-fungsi diharapkan dari sistem (use cases), disekelilingnya (actors), dan hubungan antara use cases dan actors (diagram use cases).  Peranan terpenting dari suatu model use case adalah untuk mengkomunikasikan fungsionalitas sistem dan behaviornya kepada pelanggan atau end user.  Model use case dimulai dalam tahap permulaan (Inception) dengan mengindentifikasi actors dan use cases utama dari sistem. Model kemudian dimatangkan dalam tahap elaborasi.

ACTOR  Actor bukan bagian dari sistem, actor merepresentasikan siapa saja atau apa saja yang harus berinteraksi dengan sistem. Model use case merupakan suatu dialog antara suatu actor dengan sistem.  3 jenis actor: -Para pengguna sistem/perangkat lunak - Sistem/perangkat lunak lain yang berinteraksi dengan sistem/perangkat lunak -Waktu -> memicu event-2 tertentu bagi sistem/pl

Pertanyaan-pertanyaan berikut dapat digunakan mengidentifikasi aktor dari suatu sistem:  Siapa yang interest pada requirement tertentu.  Di organisasi mana sistem itu digunakan  Siapa yang diuntungkan dari kegunaan sistem  Siapa yang akan men-supplay informasi, menggunakannya, dan menghapus data dalam sistem  Siapa yang akan mendukung dan memelihara sistem.  Apakah sistem menggunakan sumber daya external  Apakah satu orang memainkan beberapa peranan yang berbeda  Apakah beberapa orang memainkan rule yang sama  Apakah sistem berinteraksi dengan legacy sistem

Actors dalam ESU Course Registration System 1. Student ingin register mata kuliah 2. Professor ingin memilih mata kuliah yang akan diajarnya 3. Registrar harus membuat curriculum dan generate sebuah katalog untuk semester ini. 4. Registrar harus melakukan maintenance semua informasi tentang course, professor dan student. 5. Billing sistem harus menerima informasi pembayaran dari sistem.

Actors dalam ESU Course Registration System

USE CASE  Model use case adalah dialog antara actor dengan sistem. Ia mempresentasikan fungsionality yang disediakan oleh sistem  Sebuah use case adalah suatu fungsionalitas tingkat tinggi yang disediakan sistem. Dengan kata lain use case menggambarkan bagaimana seseorang memungkinkan menggunakan sistem.

Pertanyaan-pertanyaan berikut mungkin membantu mengidentifikasikan use case sistem  Apa yang dikerjakan oleh masing-masing aktor  Apa yang akan dibuat, disimpan, dirubah, dihapus dan informasi yang dibaca dari sistem oleh actor.  Apa yang akan actor buat, simpan, rubah, hapus atau baca dalam sistem.  Apakah ada actor yang menginformasikan kepada sistem kajadian tiba-tiba, perubahan external.  Apakah beberapa actor menginformasikan kejadian-kejadian tertentu pada sistem.  Use case apa yang akan mendukung dan memelihara sistem.  Dapatkah semua keperluan fungsional dilakukan oleh use case yang ada.

Use case pada ESU Course Registration System  Actor mahasiswa memerlukan menggunakan sistem untuk registrasi mata kuliah  Setelah proses pemilihan mata kuliah dilengkapai, Billing sistem harus disupplay oleh informasi ini.  Actor professor perlu menggunakan sistem untuk memilih mata kuliah yang akan diajarnya. Dan harus mampu menerima daftar mata kuliah dari sistem.  Registrar membuat catalog untuk satu semester, dan memelihara semua informasi tentang curriculum, mahasiswa, dan professor.

Use case pada ESU Course Registration System  Register for course  Select course to teach  Request course roster  Maintenance course information  Maintenance professor information  Maintenance student information  Create course catalog

Use case pada ESU Course Registration System

USE CASE RELATIONSHIP  Suatu hubungan asosiasi mungkin ada antara seorang actor dan sebuah use case.  Asosiasi seperti ini sering menjadi rujukan sebagai suatu comunicates association.  Suatu asosiasi dapat terjadi dalam dua arah (actor ke use case dan use case ke actor).  Arah suatu asosiasi merepresentasikan siapa yang mengawali komunikasi.  Suatu asosiasi direpresentasikan sebagai suatu garis yang menghubungkan elemen-elemen yang terhubung.  Arah asosiasi digambarkan dengan menambah suatu kepala panah pada garis asosiasi.

Relationship > in Use Cases  Asosiasi  Include  Extend  Generalization

Asosiasi  Relasi yang biasa terjadi antara actor dengan use case Customer Browse book catalog

Include relationship Include Relationship memungkinkan suatu use case untuk menggunakan fungsionalitas yang disediakan oleh use case yang lainnya.

Include relationship Relasi ini digunakan dalam salah satu kasus berikut:  Jika 2 atau lebih use case memiliki sejumlah besar fungsi yang identik  Jika suatu use case memiliki sejumlah besar fungsionalitas Pembelian tiket Memeriksa Kredit >

Extend relationship  Extend Relationship memungkinkan suatu use case memiliki kemungkinan untuk memperluas fungsionalitas yang disediakan use case yang lainnya  Mirip dengan include relationship, namun pada extend relationship tidak harus terjadi apa yang diharapkan. Mengubah Pemesanan Memeriksa Kredit >

Generalization relationship  Untuk memperlihatkan bahwa beberapa actor atau use case memiliki sesuatu hal yang bersifat umum Perusahaan PribadiPemerintahan Penumpang Perusahaan Penumpang Pribadi Penumpang

USE CASE Diagram  Use case diagram adalah pandangan secara grafik dari semua actor, use case, dan interaksinya dalam sistem

Use Case diagram dalam ESU Course Registration System