Buku Referensi :
Pressman, RS., 2008, Software Engineering: A Practitioners Approach, New York: McGraw-Hill Sommerville, I, 2007, Software Engineering, Addsion Wesley
Pada produk pesanan, spesifikasi biasanya dikembangkan dan dikontrol oleh organisasi yang membeli perangkat lunak tersebut.
Perangkat lunak yg menangani bidang teknik dan ilmu pengetahuan secara rinci Misal: simulasi astronomi, vulkanologi, analisis otomatif, dinamika orbit pesawat ruang angkasa, biologi molekuler, otomasi pabrik, dll Embeded System Perangkat lunak yg ditempelkan/dilekatkan pada perangkat lainnya (lunak/keras). Misal: pada kamera digital, GPS, automobil, microwave, kulkas cerdas, dll
Perangkat lunak yg mampu memberi informasi dari suatu sistem secara lebih detail. Misal: web site, perpustakaan digital, dll
Perangkat lunak yg berfungsi untuk menghubungkan atau mengkomunikasikan suatu objek satu dengan lainnya. Misal: router, handphone, dll
Computer science lebih memperhatikan teori & metode komputerisasi, sedangkan software engineering menyangkut masalah praktikal pembuatan dan delivery perangkat lunak Software engineering merupakan bagian dari system engineering, dimana sistem engineering memperhatikan semua aspek pembuatan sistem berbasis komputer termasuk perangkat keras, perangkat lunak & proses
1. 2. 3. 4. 5.
POKOK BAHASAN
Biaya PL Software Quality Attribute Standar kualitas Takaran Jaminan Kualitas CASE TOOLS Siklus Hidup Perangkat Lunak (SWDLC/Software Development Life Cycle)
Sebagai suatu kemungkinan bahwa sistem ini mampu memenuhi suatu kegunaan (tergantung spesifikasinya) untuk sejumlah masukan percobaan di bawah kondisi masukan dan rentang waktu yang telah ditentukan.
CASE TOOLS
CASE (Computer Aided Software Engineering) Suatu peralatan baik HW maupun SW komputer yang digunakan untuk menyediakan pendukung otomatis dalam aktivitas pembangunan PL. Tujuan meningkatkan produktivitas dalam proses pembangunan PL secara signifikan Dikelompokkan dalam 2 kategori: 1. Upper-CASE Mendukung aktivitas proses pembangunan tahap awal (tahap analisis kebutuhan dan desain) 2. Lower-CASE Mendukung aktivitas pembangunan di tahap akhir programming, debuging, dan testing)
WATERFALL MODEL
Requirement Definitions Pemodelan Sistem/ Informasi System and software design Implementation and unit testing Integr ation and system testing Operation and maintenance
PROTOTYPE MODEL
Mendengarkan Pelanggan Membangun Konstruksi (prototipe)
EVOLUTIONARY MODEL
3. Spesifikasi tertentu, kemudian proses dimulai dari fase pertama hingga akhir dan menghasilkan produk dengan spesifikasi yang lebih lengkap dari yang sebelumnya. 4. Demikian seterusnya hingga semua spesifikasi memenuhi kebutuhan yang ditetapkan oleh pengguna.
REUSE BASED
A. Software Re-engineering Apakah itu? Restrukturisasi atau menulis ulang sebagian atau keseluruhan dari sistem yang telah ada tanpa merubah fungsionalitasnya. Kapan? Ketika sebagian tetapi tidak semua sub sistem yg besar membutuhkan perawatan yg sering Ketika HW dan SW sudah lama hampir tak berfungsi Bagaimana? Sistem bisa di restrukturisasi dan didokumentasi ulang untuk membuat menjadi mudah dalam perawatan
Pertemuan 3
Manajemen Proyek Perangkat Lunak
penjadwalan, sebelum sebuah proyek direncanakan : Memastikan tujuan dan ruang lingkup Memperhatikan alternatif-alternatif solusi Identifikasi batasan teknik dan manajerial
Faktor-faktor yang mempengaruhi hasil akhir proyek Perangkat Lunak Ukuran (size) Batas waktu pengiriman (Delivery Deadline) Pembiayaan dan anggaran (Budgets & Costs) Bidang aplikasi (Application Domain) Implementasi Teknologi (Technology Can Be Implemented) Batasan-batasan sistem (System Constrains) Kebutuhan pengguna (User Requirements) Sumber daya yang tersedia (Available Resource)
Permasalahan Dalam Manajemen Proyek Bagaimana kualitas produk yang akan dihasilkan Perkiraan / beban resiko yang timbul Ukuran perangkat lunak Estimasi / perkiraaan dana Penjadwalan proyek Komunikasi dengan pelanggan Tim perancang Sumber daya lainnya Proses monitoring proyek
Estimasi
Dalam aktifitas dilakukan: utama proyek yaitu perencanaan,
Sumber daya manusia (ukuran orang/bulan) Jangka waktu kronologis (Ukuran waktu kalender) Biaya (Ukuran uang Rp)
Estimasi (2)
A. Tujuan Perencanaan Anggaran Proyek Untuk menjalankan apa yang telah ditentukan dalam tahap planning Memberikan arah/dukungan financial untuk membiayai proyek Untuk mengontrol dan mendokumentasikan pembiayaan proyek B. Metode Perencanaan Anggaran Metode perkiraan (intuisi) pimpinan dan tim Taksiran standar TCA(Traditional Cost Accounting) ABC (Activity Based Costing)
Estimasi (3)
Beberapa hal yang terkait dengan metode ABC : Konsistensi lebih akurat dibandingkan dengan metode TCA Terkonsentrasi pada biaya tidak langsung (tambahan) Biaya selalu berhubungan dengan aktifitas Aktifitas selalu menggunakan sumber daya Mengkonversi biaya langsung menjadi tidak langsung
Analisis Resiko
Analisis resiko merupakan serangkaian langkah untuk menyiasati resiko Analisis resiko sangat penting dalam manajemen proyek perangkat lunak. Beberapa hal yang harus diperhatikan berkaitan dengan resiko adalah: Masa yang akan datang, Perubahan, Pilihan.
Menyiasati Resiko
Identifikasi resiko Melihat semua resiko sesuai dengan kategori(secara makro). Perkiraan resiko Memperhitungkan lebih lanjut estimasi resiko. Proyeksi resiko Disebut juga estimasi resiko, adalah usaha untuk mengukur setiap resiko. Strategi manajemen resiko Putusan (Resolution) resiko Pemantauan resiko
Pengendalian Resiko
Strategi Penanganan Resiko 1. Manajemen Resiko Reaktif Tim proyek beraksi pada resiko mereka menjumpainya Pelonggaran rencana penambahan resource antisipasi, misalnya kebakaran Perbaikan pada kesalahan, sumber daya yang ditemukan & diterapkan ketika resiko sudah menyerang Manejemen krisis kesalahan tidak dapat direspon oleh sumber daya & menjadi ancaman bagi keberlangsungan proyek
Perencanaan Proyek
Memahami masalah yang akan di hadapi Menentukan cara-cara yang tepat untuk mendapatkan solusi yang tepat Pengoptimalan efisiensi dan keuntungan proyek Memerlukan dokumen kebutuhan yang akan digunakan untuk pengambilan keputusan menerima proyek/menolaknya. Jika menerima maka langkah selanjutnya adalah membuat proposal
durasi,
Penjadwalan
Langkah-langkah yang dilakukan dalam penjadwalan: 1. Identifikasi sekumpulan tugas 2. Pastikan keterkaitan antar tugas 3. Estimasi usaha untuk tiap-tiap tugas 4. Tentukan pekerja dan sumber-sumber lainnya 5. Buat jaringan tugas 6. Buat jadwal kerja berdasarkan waktu
setelah ada penjadwalan yang pasti, yaitu memeriksa apakah tugas telah dilaksanakan sesuai dengan jadwal.
Perkiraan manfaat dari penerapan metode dan tools Membentuk dasar dari estimasi Menegaskan (Justify) permintaan tools baru dan pelatihan
ARTIFACT UML
Use-Case Diagram
Use Case 1 Actor A Use Case 2 Actor B
close file Reading
rep Repository (from Persistence) name : char * = 0 File GrpFile
Class Diagram
DocumentList FileMgr add( ) delete( ) Document name : int docid : int numField : int get( ) open( ) close( ) read( ) sortFileList( ) create( ) fillDocument( ) read() fill the code.. fetchDoc( ) sortByName( ) FileList fList add( ) delete( ) 1
State Diagram
add file [ numberOffile==MAX ] / flag OFF Openning
add file
Writing
close file
Closing
read( )
Domain Expert
readDoc( ) readFile( )
Use Case 3
UI
Class
Repository DocumentList
Deployment Diagram
- 95 : - NT: - - : - -, - - IBM : -, - Windows95 Windows95
DocumentApp
RogueWave Persistence
Window95
9: sortByName ( )
global
FileManager
mainWnd : MainWnd
1: Doc view request ( )
L
- .EXE -
Windows NT
gFile : GrpFile
Package Diagram
Document
- .EXE
Solaris
GraphicFile File
IBM Mainframe
FileList
-
7: readFile ( ) 5: readDoc ( )
Collaboration Diagram
mainWnd user fileMgr : FileMgr document : Document gFile repository
- . 1: Doc view request ( ) 2: fetchDoc( ) 3: create ( )
Component Diagram
4: create ( )
- - .
6: fillDocument ( )
8: fillFile ( )
- - .
9: sortByName ( )
DIAGRAM-DIAGRAM DI UML
State State Diagrams Class Diagrams Diagrams
Model
Deployment Diagram
Diagrams
Use case menggambarkan proses system (kebutuhan system dari sudut pandang user) Secara umum use case adalah: Pola perilaku system Urutan transaksi yang berhubungan yang dilakukan oleh satu actor Use case diagram terdiri dari a. Use case b. Actors c. Relationship d. System boundary boxes (optional) e. Packages (optional)
ACTOR
Actor menggambarkan orang, system atau external entitas / stakeholder yang menyediakan atau menerima informasi dari system Actor menggambarkan sebuah tugas/peran dan bukannya posisi sebuah jabatan Actor memberi input atau menerima informasi dari system Actor biasanya menggunakan Kata benda Simbol actor
Tidak boleh ada komunikasi langsung antar actor Indikasi <<system>> untuk sebuah actor yang merupakan sebuah system Adanya actor bernama Time yang mengindikasikan scheduled events (suatu kejadian yang terjadi secara periodik/bulanan) Letakkan actor utama anda pada pojok kiri atas dari diagram
Association Associations bukan menggambarkan aliran data/informasi Associations digunakan untuk menggambarkan bagaimana actor terlibat dalam use case Ada 4 jenis relasi yang bisa timbul pada use case diagram 1. Association antara actor dan use case 2. Association antara use case 3. Generalization/Inheritance antara use case 4. Generalization/Inheritance antara actors
Maintain curriculum
Nasabah
Buka Deposito
Generalization/inheritance antara actor Gambarkan generalization/inheritance antara actors secara vertical dengan inheriting actor dibawah base/parent use case
CLASS DIAGRAM
Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi). Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain. Class memiliki tiga area pokok :
1.Nama, merupakan nama dari sebuah kelas 2. Atribut, merupakan peroperti dari sebuah kelas. Atribut melambangkan batas nilai yang mungkin ada pada obyek dari class 3. Operasi, adalah sesuatu yang bisa dilakukan oleh sebuah class atau yang dapat dilakukan oleh class lain terhadap sebuah class
MULTIPLICITY Unspecified Exactly one Zero or more (many, unlimited) One or more Zero or one (optional scalar role) Specified range Multiple, disjoint ranges
Class Diagram diperoleh berdasarkan dari database Contoh Kasus (Acknowledgments Evi Lutfi Muktar)
p e la n g g a n _ re g n o in t(5 ) n o m o r_ p e la n g g a nv a rch a r(1 2 ) n a m a _ le n g ka pv a rch a r(2 0 ) u se rn a m ev a rch a r(1 3 ) p a ssw o rd v a rch a r(1 3 ) e m a il v a rch a r(3 0 ) ca ri() sim p a n () b a ta l()
i_ 0 1 n o m o r_ a g e n d a in t(5 ) tg l_ a g e n d av a rch a r(1 5 ) n o m o r_ p e la n g g a nv a rch a r(1 2 ) n a m ap e la n g g a nv a rch a r(2 0 ) a la m a t_ p e la n g g a nv a rch a r (3 0 ) n o _ ktp v a rch a r(1 9 ) n o _ te lp o nv a rch a r(1 3 ) ta rif_ la m av a rch a r(2 ) d a ya _ la m av a rch a r(6 ) n ta rif_ b a ru v a rch a r(2 ) d a ya _ b a ru v a rch a r(6 ) p e ru n tu ka nv a rch a r(2 0 ) g a rd uv a rch a r(2 0 ) sta tu sv a rch a r(1 ) sim p a n () b a ta l()
kw ita n si n o m o r_ kw ita n si in t(5 ) tg l_ kw ita n si v a rch a r(1 5 ) n o m o r_ a g e n d a in t(5 ) n o m o r_ p e la n g g a nv a rch a r(1 2 ) b p in t(1 0 ) u jl in t(1 0 ) m a te ra i in t(1 0 ) to ta l in t(1 0 ) sta tu s in t(1 ) u se rid v a rch a r(1 0 )
u se r id _ u se rv a rch a r(5 0 ) p a ssw o rd v a rch a r(5 0 ) n a m a _ le n g ka pv a rch a r(1 0 0 ) e m a il v a rch a r(1 0 0 ) 1 b a g ia nv a rch a r(1 0 0 ) re fe re n si v a rch a r(1 0 0 ) le v e lv a rch a r(5 0 )
ke lu h a n _ p e la n g g a n id in t(5 ) n o m o r_ p e la n g g a nv a rch a r(1 2 ) n a m a _ p e la n g g a nv a rch a r(2 0 ) e m a il v a rch a r(1 0 0 ) ke lu h a n te xt ko d e _ se cu rity v a rch a r(6 ) sim p a n () b a ta l() n
m a ste r_ ta rif n o m o r in t(5 ) p e ru n tu ka nv a rch a r(1 0 ) ta rif v a rch a r(2 ) d a ya v a rch a r(1 0 ) b p in t(1 0 ) u jl in t(1 0 ) m a te ra i in t(1 0 )
sim p a n () n b a ta l() ta m b a h kw ita n si() ca ri() 1 1 p e rin ta h _ ke rja n o m o r_ p k in t(5 ) tg l_ p kv a rh ca r(1 5 ) n o _ kw ita n si in t(5 ) tg l_ kw ita n si v a rch a r(1 5 ) sta tu s in t(1 ) ca ri() 1 1 m u ta si n o m o r_ m u ta si in t(5 ) tg l_ m u ta si v a rch a r(1 5 ) n o m o r_ p k in t(5 ) tg l_ p kv a rch a r(1 5 ) sta tu s in t(1 ) ca ri() 1 1 m a ste r_ sta tu s n o m o r_ sta tu s in t(1 ) ke te ra n g a nv a rch a r(1 5 )
tu n g g a ka n n o m o r_ p e la n g g a nv a rch a r(2 0 ) ta n g g a l_ re ke n in gv a rch a r(1 5 ) ru p ia h _ p tl in t(1 5 ) ta g ih a n _ la in _ la in in t(1 5 ) p p n in t(1 2 ) p p j in t(1 5 ) m a te ra i in t(7 ) to ta l_ ta g ih a n in t(1 5 ) ta n g g a l_ b a ya rv a rch a r(1 5 )
1 n n
m a ste r_ p e la n g g a n n o m o r_ p e la n g g a nv a rch a r(1 2 ) n a m a _ p e la n g g a nv a rch a r(2 0 ) p e n u n ju ka n _ a la m a tv a rch a r (2 ) a la m a t_ p e la n g g a nv a rch a r(1 8 ) n o m o r_ b a n g u n a nv a rch a r(3 ) n o m o r_ rt in t(3 ) n o m o r_ rw in t(2 ) g o lo n g a n _ ta rif v a rch a r(3 ) d a ya in t(6 ) 1 n o m o r_ m e te rv a rch a r(6 ) n o m o r_ ktp v a rch a r(2 0 ) te lp o nv a rch a r(1 3 ) g a rd uv a rch a r(2 0 )
m o d u l id _ m o d u l in t(5 ) n a m a _ m o d u lv a rch a r(5 0 ) lin kv a rch a r(1 0 0 ) sta tic_ co n te n t te xt g a m b a rv a rch a r(1 0 0 ) p u b lish e n u m ('Y ','N ') sta tu se n u m ('u se r','a d m in ','u m u m ') a ktif e n u m ('Y ','N ') u ru ta n in t(5 ) sim p a n () b a ta l()
Statechart Diagram.
Statechart diagram, atau yang biasa juga disebut state diagram digunakan untuk mendokumentasikan beragam kondisi/keadaan yang bisa terjadi terhadap sebuah class dan kegiatan apa saja yang dapat merubah kondisi/keadaan tersebut. Contohnya sebuah televisi yang dapat berada dalam kondisi menyala atau mati, jika tombol power ditekan maka televisi akan menyala, begitu juga sebaliknya akan mati jika tombol power ditekan kembali. Maka disini kita mempunyai sebuah kelas yaitu televisi, 2 state yaitu menyala dan mati dan 2 transition yaitu menyalakan TV dan mematikan TV. Tidak seperti diagram-diagram behavioural lainnya yang memodelkan interaksi diantara beberapa class, state diagram justru biasanya hanya memodelkan transisi yang terjadi hanya pada sebuah class. Berikut adalah notasi state diagram :
State
Notasi State menggambarkan kondisi sebuahentitas, dan digambarkan dengan segiempat yang pinggirnya tumpul dengan nama state didalamnya
State1 State1
Transition
Sebuah Transition menggambarkan sebuah perubahan kondisi objek yang disebabkan oleh sebuah event. Transition digambarkan dengan sebuah anak panah dengan nama event yang ditulis diatasnya, dibawahnya atau sepanjang anak panah tersebut
Transition
Initial State
sebuah kondisi awal sebuah object sebelum ada perubahan keadaan. Initial State digambarkan dengan sebuah lingkaran solid. Hanya satu Initial State yang diizinkan dalam sebuah diagram menggambarkan ketika objek berhenti memberi respon terhadap sebuah event. Final State digambarkan dengan lingkaran solid didalam sebuah lingkaran kosong.
Final State
Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram). Dalam UML, state digambarkan berbentuk segiempat dengan sudut membulat dan memiliki nama sesuai kondisinya saat itu. Transisi antar state umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan sebagai akibat dari event tertentu dituliskan dengan diawali garis miring. Titik awal dan akhir digambarkan berbentuk lingkaran berwarna penuh dan berwarna setengah. Contoh statechart diagram :
State Machine Diagram (Statechart diagram in versi 1.x) Untuk memodelkan behavior/methode (lifecycle) sebuah kelas atau object Memperlihatkan urutan kejadian sesaat (state) yang dilalui sebuah object, transisi dari sebuah state ke state lainnya
State Machine Diagram (Statechart diagram in versi 1.x) Sebuah state machine diagram mempunyai : state (kejadian sesaat) are represented by the values of attributes of an object State digambarkan dengan bentukData Kosong atau Black Hole states is state has transitions into it but none out Miracle states is state has transitions out of it but none into it initial state / creation state dengan tanda Untuk memulai sebuah state machine diagram (in western culture people read from left to right, top to bottom, starting in the top-left corner) Final state dengan tanda Untuk mengakhiri sebuah state machine diagram Letakkan pada pojok kanan bawah(in western culture people read from left to right, top to bottom, starting in the top-left corner) Simple State Sebuah State yang tidak mempunyai Sub States/region/submachines
State Machine Diagram (Statechart diagram in versi 1.x) State 1 Composite State Digunakan untuk Kumpulan dari mendukung konsep beberapa states State 2 State 3 encapsulation yang setidaknya Sebuah state tidak boleh dalam sebuah mempunyai region dan region submachine secara Orthogonal State, bersamaan jenis composite Nama state mempunyai state lebih dari 1 sintaks : region nama submachine state : Submachine State referenced state machine Sejenis composite state yang isinya didefinisikan oleh state machine lain State Machine yang berisi submachine state disebut Containing state machine Sebuah state yang dihubungkan ke state machine lainnya Dihubungkan ke satu/lebih entry point dan satu/lebih exit point
State Machine Diagram (Statechart diagram in versi 1.x) Sub States Sebuah state yang ada dalam sebuah region Direct Substate, Sub state yang tidak berisi state lain Indirect Substate, Sub state yang berisi state lain Region (kelompok state) Dipisahkan dengan garis terputus, yang setiap region boleh mempunyai nama sebagai optional Sebuah state tidak boleh mempunyai region dan submachine secara bersamaan State terpisah menjadi 3 bagian yaitu Activity label bisa berupa Entry, Exit atau do Dimana Activity expression adalah penggunaan atribut
NIP Kosong Entry/isi NIP Exit/ Help/Tekan F1 Klik Double klik Nama State Internal Activity, kegiatan yang dilakukan dalam state sintaks : Activity label/activity expression Internal transition
Transition
digambarkan dengan tanda anak panah progressions from one state to another, will be triggered by an event Transition adalah hasil dari methode yang menyebabkan perubahan state, walaupun tidak semua methode menyebabkan perubahan state
event biasa dituliskan dengan past tense event menyebabkan sebuah object berpindah dari satu state ke state lain Guard, condition that must be true for the transition to be triggered Guard harus konsisten dan tidak overlap Contoh: X<0, X=0 dan X>0 konsisten X<=0 dan X>=0 tidak konsisten Guards harus lengkap logikanya Contoh: X<0 dan X>0 , bagaimana jika X=0 ? Methode dijalankan ketika object memasuki state diindkasikan dengan methode bernama entry( ) ketika object keluar state diindikasikan dengan methode bernama exit( ) Methode menyebabkan perubahan di sebuah state bisa juga tidak
State Machine Diagram (Statechart diagram in versi 1.x) Join, menggabungkan beberapa transition menjadi sebuah transition Fork, memecah sebuah transition menjadi beberapa transition yang berkondisi AND (transition harus dilewati semuanya). Junction, Menggabungkan sebuah/beberapa transition dan memecahnya menjadi sebuah/beberapa transition yang berkondisi AND (transition harus dilewati semuanya). Digunakan tanda lingkaran hitam kecil Contoh: Dimungkinkan transition ke sebuah state yang berisi beberapa state yang disebut state list
State1, State2
State Machine Diagram (Statechart diagram in versi 1.x) Choice, Mengkondisikan sebuah transition menjadi sebuah/beberapa transition, yang hanya dipilih salah satu transition(choice). Digunakan lambang diamond Operand dapat diletakkan didalam diamond atau pada transition Contoh:
Entry point Dilambangkan sebuah lingkaran kecil yang ditaruh pada pinggiran state(bisa juga didalam atau diluar), dan berguna sebagai submachine state
Exit point Dilambangkan sebuah lingkaran kecil bersilang yang ditaruh pada pinggiran state (bisa juga didalam atau diluar), dan berguna sebagai submachine state
State Machine Diagram (Statechart diagram in versi 1.x) State Machine Diagram ada 2 jenis Behavioral State Machines Merupakan state machine diagram umumnya Digunakan untuk mendefinisikan perilaku sebuah object Protocol State Machines Digunakan untuk penggunaan protocol pada sebuah system Dapat didefinisikan ke spesifik Protocol State Machines atau ke Behavioral State Machines Didefinisikan sebagai diagram context (global overview) Notasi yang digunakan sama dengan Behavioral State Machines dengan penambahan kata {protocol}
Tidak adanya internal activity seperti entry,exit,do Transition pada Protocol State Machines harus menggunakan Protocol Transition Protocol Transition Sintaks : [pre condition] event / [post condition] precondition atau postcondition adalah guard (Guard is condition that must be true for the transition to be triggered) Precondition, kondisi sebelum transition Postcondition, kondisi setelah transition
Statechart diagram
Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram). Dalam UML, state digambarkan berbentuk segi empat dengan sudut membulat dan memiliki nama sesuai kondisinya saat itu. Transisi antar state umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan sebagai akibat dari event tertentu dituliskan dengan diawali garis miring. Titik awal dan akhir digambarkan berbentuk lingkaran berwarna penuh dan berwarna setengah.
Deployment Diagram Deployment/physical diagram menggambarkan detail bagaimana komponen di-deploy dalam infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan halhal lain yang bersifat fisikal Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk men-deploy komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini.
Component Diagram Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya. Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run time. Pada umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponenkomponen yang lebih kecil. Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.
Demo.html
applet2.class
applet2.java
logo.gif
p e n g isia n d a ta
kirim
d a ta m a su ka n sim p a n
da ta m a su kan sim pa n
ACTIVITY DIAGRAM
Menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses Dipakai pada business modeling untuk memperlihatkan urutan aktifitas proses bisnis Struktur diagram ini mirip flowchart atau Data Flow Diagram pada perancangan terstruktur Sangat bermanfaat apabila kita membuat diagram ini terlebih dahulu dalam memodelkan sebuah proses untuk membantu memahami proses secara keseluruhan Activity diagram dibuat berdasarkan sebuah atau beberapa use case pada use case diagram
Fork (Percabangan)
Join (Penggabungan)
Decision
Swimlane
Sebuah cara untuk mengelompokkan activity berdasarkan Actor (mengelompokkan activity dalam sebuah urutan yang sama)
Menerima informasi
Buat SPP
Terima SPP
Buat SPBJ
Tandatangani SPBJ
Terima SPBJ
Melakukan pembayaran
Konfirmasi pembayaran
Terima pembayaran
Terima Kwitansi
Buat kwitansi
Procedure Berjalan (Acknowledgments Evi Lutfi Muktar) Proses pembuatan Daftar Data Pegawai dan Gaji pada SMP PGRI 1 Depok adalah sebagai berkut : 1. Proses Absensi Pegawai melakukan absensi harian melalui form daftar hadir pegawai. Berdasarkan form daftar hadir pegawai tersebut bagian Tata Usaha (TU) akan membuat Rekap Absen (RA) harian untuk diserahkan kepada Administrasi. 2. Proses Pemberian Rekap Biodata Pegawai (RBP) Pegawai memberikan data pribadi pegawai, data pendidikan, data keluarga yang dijadikan satu menjadi data pegawai kepada bagian Tata Usaha yang kemudian diarsipkan menjadi Rekap Biodata Pegawai (RBP). Lalu Rekap Biodata Pegawai (RBP) diserahkan kepada bagian administrasi untuk proses pengolahan Daftar Data Pegawai Dan Gaji (DDPG).
Proses Pengolahan Daftar Data Pegawai dan Gaji (DDPG) Setelah bagian administrasi menerima Rekap Biodata Pegawai (RBP) dan Rekap Absen (RA) akan mengolah kedua data tersebut untuk dibuatkan menjadi Daftar Data Pegawai dan Gaji (DDPG) yang kemudian diserahkan kepada Kepala Sekolah untuk ditanda tangani atau di Acc.
3.
4.
Proses Pembuatan Laporan Daftar Data Pegawai dan Gaji (DDPG) yang sudah diterima dan ditanda tangani oleh Kepala Sekolah akan diserahkan kembali kepada bagian Administrasi untuk dibuatkan Laporan Data Pegawai (LDP) dan Laporan Gaji Pegawai (LGP). Setelah bagian administrasi menerima Daftar Data Pegawai dan Gaji yang sudah di Acc akan membuatkan Laporan Data Pegawai (LDP) dan Laporan Gaji Pegawai (LGP) yang nantinya akan diserakan kepada Kepala Sekolah.selain itu bagian Administrasi akan membuatkan slip gaji untuk diserahkan kepada pegawai.
Proses Absensi
Proses bisnis pelayanan pelanggan perubahan daya pada PT PLN adalah sebagai berikut : Pendaftaran perubahan daya Konsumen datang kekantor PT PLN(Persero) dengan membawa fotocopy KTP dan kwitansi pembayaran rekening bulan terakhir kemudian diserahkan dibagian pelayanan pelanggan. Pegawai pelayanan pelanggan akan menginput berdasarkan data dari konsumen , setelah diinput maka akan dicetak formulir pendaftaran perubahan daya untuk kemudian ditandatangani oleh pelanggan. Satu rangkap untuk pelanggan sebagai tanda bukti. Lainnya disimpan oleh bagian pelayanan pelanggan untuk diteruskan ke supervisor untuk proses persetujuan
p elan g g an
p elay an an p elan g g a n
sp vp e lay an an
in p u tp e n d a fta ra n p e la n g g a n
ce ta k fo rm u lir p e n d a fta ra n
m e n ye tu ju i fo rm u lir p e n d a fta ra n
Persetujuan perubahan daya Rangkap formulir pendaftaran yang disimpan oleh bagian pelayanan pelanggan kemudian dibuatkan surat jawaban persetujuan yang kemudian ditandatangani oleh supervisor pelayanan pelanggan dicetak menjadi dua rangkap, rangkap pertama diberikan kepada pelanggan , sedangkan rangkap yang kedua disimpan oleh bagian pelayanan pelangan sebagai arsip.
p elay an an p e la n g g an sp vp e la y an a n p elan g g an
m e m b u a t su ra t p e r se tu ju a n
m e n ye tu ju is u ra t p e r se tu ju a n
m e m b e rika ns u ra t p e r se tu ju a n
m e n e rim a su r a t p e r se tu ju a n
Perjanjian jual beli tenaga listrik Setelah pelanggan menerima surat jawaban persetujuan dari PT. PLN (Persero) maka sipelanggan akan datang ke kantor PT PLN untuk menandatangani surat perjanjian jual beli tenaga listrik sesuai dengan daya listrik yang baru yang akan dipasang. Surat perjanjian jual beli tenaga listrik tersebut juga ditandatangani oleh manager.
p e la n g g a n s p v p e la y a n a n m a n a g e r
m e n e r im as u r a t p e r s e tu ju a n
m e m b u a t s u r a t p e r ja n jia n ju a l b e li te n a g a lis tr ik
m e n c e ta ks u r a t p e r ja n jia n ju a l b e li te n a g a lis tr ik
m e m b e r ik a ns u r a t p e r ja n jia n ju a l b e li te n a g a lis tr ik
m e n e r im as u r a t p e r ja n jia n ju a l b e li te n a g a lis tr ik
m e n y e tu ju is u r a t p e r ja n jia n ju a l b e li te n a g a lis tr ik
m e n e r im as u r a t p e r ja n jia n ju a l b e li te n a g a lis tr ik
m e m b e r ik a ns u r a t p e r ja n jia n ju a l b e li te n a g a lis tr ik
m e n e r im as u r a t p e r ja n jia n ju a l b e li te n a g a lis tr ik
m e m b e r ik a ns u r a t p e r ja n jia n ju a l b e li te n a g a lis tr ik
m e n y e tu ju is u r a t p e r ja n jia n ju a l b e li te n a g a lis tr ik
m e m b e r ik a ns u r a t p e r ja n jia n ju a l b e li te n a g a lis tr ik
m e n e r im as u r a t p e r ja n jia n ju a l b e li te n a g a lis tr ik
Pembayaran Setelah menandatangani surat perjanjian jual beli tenaga listrik maka sipelanggan tinggal membayar sejumlah yang tertera pada surat perjanjian jual beli tenaga listrik ke loket pembayaran perubahan daya, pelanggan akan mendapatkan kwitansi pembayaran sebagai bukti bahwa si pelanggan telah melaksanakan kewajibannya.
p elan g g an lo ket P TP L N
m e la k u ka n p e m b a ya r a n
m e n e r im a p e m b a ya r a n
ce ta kb u kti p e m b a ya r a n
m e n ye tu ju ib u kti p e m b a ya r a n
m e n e rim ab u kti p e m b a ya r a n
m e m b e r ika nb u kti p e m b a ya r a n
Perintah kerja Saaat si pelanggan membayar kewajibannya maka perintah kerja terbit dan siap untuk di cetak, untuk diberikan kepada pelaksana sebagai perintah kerja untuk pelanksanaan penggantian MCB pelanggan.
b a g ia np e n y a m b u n g a n p e la k s a n a p e la n g g a n
c e ta kp e r in ta h k e r ja
m e n y e tu ju i p e r in ta hk e r ja
m e la k u k a n p e n g g a n tia nM C B
m e n e r im a p e r in ta hk e r ja
m e la k u k a n p e n g g a n tia nM C B
m e m b e r ik a n p e r in ta hk e r ja
m e n e r im a p e r in ta hk e r ja
m e n y e tu ju i p e r in ta hk e r ja
m e n e r im a p e r in ta hk e r ja
m e m b e r ik a n p e r in ta hk e r ja
m e n e r im a p e r in ta hk e r ja
m e m b e r ik a n p e r in ta hk e r ja
Latihan STUDI KASUS ACTIVITY DIAGRAM Koperasi STMIK Nusa Mandiri adalah sebuah koperasi yang mengelola simpan pinjam bagi para anggotanya, berikut ini adalah kegiatan yang dilakukan oleh bagian Kredit dalam menangani pemberian pinjaman bagi para anggotanya. Setiap kali bagian kredit akan memberikan pinjaman kepada Anggota maka Anggota diharuskan mengisi Formulir Permohonan Pinjaman yang berisi Nomor FPP, Tanggal Permohonan, Nomor Anggota, Nama Anggota, Jumlah Permohonan dan Keperluan. Yang kemudian oleh Bagian Kredit dicatat dan disimpan kedalam Arsip FPP. Berdasarkan Arsip FPP tersebut Bagian Kredit membuat Bukti Peminjaman yang diberikan kepada Anggota yang berisi No. BP, tgl BP, Nomor Anggota, Nama Anggota, Jumlah Realisasi, Lama Angsuran, Jumlah Angsuran dan Bunga.
Setiap Bulan Anggota diharuskan membayar Angsuran sejumlah Angsuran yang disepakati pada saat Peminjaman yang kemudian oleh bagian Kredit dicatat dan direkam kedalam Arsip Angsuran. Berdasarkan Arsip Angsuran tersebut bagian Kredit membuat Bukti Angsuran yang diberikan kepada Anggota yang berisi No. BA, Tanggal BA, No. BP, Jumlah Angsur dan Bunga Pada akhir bulan Bagian Kredit selalu membuat Laporan Peminjaman dan Laporan Angsuran yang diberikan Kepada Ketua Koperasi.
2. Pembuatan Kwitansi Apabila Faktur dan Surat Jalan sudah sampai ditempat pelanggan, maka pelanggan megirimkan Pembayaran yang kemudian oleh bagian penjualan dibuatkan Kwitansi yang dibuat berdasarkan Arsip Faktur yang kemudian diserahkan kepada pelanggan sebagai bukti pembayaran dan rangkapnya disimpan kedalam Arsip Kwitansi 3. Pembuatan Laporan Setiap akhir bulan Bagian Penjualan selalu membuat Laporan Penjualan berdasarkan Arsip Faktur dan Laporan Pesanan berdasarkan Arsip Pesanan dan Laporan Pengiriman berdasarkan Arsip Surat Jalan yang ditujukan kepada Kepala Bagian Penjualan Diminta : Buatlah Activity diagram dari data diatas !
Sequence Diagram
Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objekobjek yang terkait).
Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkahlangkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan. Diagram ini secara khusus berasosiasi dengan use case diagram Memperlihatkan tahap demi tahap apa yang seharusnya terjadi untuk menghasilkan sesuatu didalam use case
: administrator open ( )
: formtambah manajemen user : control formtambah manajemen user get username, password nama lengkap, email
: pelanggan
: pelanggan open ( )
: pelanggan1
display n om or_pelangga n nam a pelanggan alam at nom or ktp nom or telpo n gardu daya tarif lam a daya tarif baru peruntukan sim p an sim pan
Collaboration diagram juga menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu Penyampaian message. Setiap message memiliki sequence number, di mana message dari level tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama.
Berikut adalah sebuah contoh collaboration diagram yang mengilustrasikan sebuah sistem telepon genggam (handphone) :
: p e n d a f ta r a n
: b a ta l
: p e n g u n ju n g
: in d e x \h o m e
: r e g is te r
: s im p a n : m e m b e r : in d e x \h o m e : m a n a je m e nk o n tr o l : b a ta l
: c e ta k
: s im p a n
: ta m b a hm o d u l : b a ta l
: lo g in
: lo g o u t : b a ta l : lo g in 1
: m a n a je m e nm o d u l
: h a p u s : u p d a te : e d it
: b r o w s e : b a ta l
: p r o f ile : s im p a n : u p d a te : ta m b a hu s e r : m a n a je m e nu s e r : b a ta l : c e ta k
: c a r i
: h a p u s
: p e n d a f ta r a n
: ta m b a hd a ta
: s im p a n
: u p d a te : c a r i : e d it : c e ta kd o k u m e n : b a ta l : c e ta k : ta m b a hk w ita n s i : b a ta l
: c a r i
: s im p a n
: lo g in 1
: in d e x \h o m e : c a r i
: k w ita n s i1 : b a ta l : c e ta k
: a d m in
: lo g in : p e r in ta hk e r ja 1 : b a ta l : c e ta k : c a r i
: s im p a n
: ta m b a hg u e s tb o o k
: g u e s tb o o k 1
: d a ta p e la n g g a n 1
: m a n a je m e nk o n tr o l1 : m u ta s i1 : p e r e m a ja a n
: b a ta l
: h a p u s
: e d it
: in f o r m a s i ta g ih a n 1
: c a r i : c a r i
: b a ta l
: c a r i : s im p a n : b a ta l
: c a r i
: c e ta k : c a r i
: c e ta kd o k u m e n : ta m b a hk w ita n s i : s im p a n
: k w ita n s i1 : b a ta l : c e ta k : u s e r : in d e x \h o m e
: c a r i : s im p a n : p e r in ta hk e r ja 1 : ta m b a hg u e s tb o o k : g u e s tb o o k 1
: in f o r m a s i ta g ih a n 1 : m u ta s i1 : d a ta p e la n g g a n 1 : c e ta k : c a r i
: b a ta l
: h a p u s
: e d it
: c a r i : c a r i : b a ta l : p e r e m a ja a n
: s im p a n
: b a ta l
Component Diagram
Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya. Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run time. Umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponenkomponen yang lebih kecil. Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain. Contoh component diagram:
Component Diagram Menggambarkan alokasi semua class dan object kedalam komponen dalam desain fisik system software, termasuk pengaturan dan kebergantungan antar komponen software Component dapat terdiri dari logical component, seperti business component, process component, dll Physical component (software arsitektur) , seperti Com+, dot NET,CORBA, dll Component digambarkan dengan bentuk pada UML versi 1.*: Pada UML versi 2 digambarkan dengan bentuk atau atau atau
Stereotypes yang dapat digambarkan pada bentuk component <<application>>,kumpulan aplikasi system <<executable>>,component yang jalan di client <<file>>, data file <<database>> <<infrastructure>>, technical component didalam system <<document>> <<source code>>, source file <<library>> <<table>>, table data dalam sebuah database <<web service>> <<XML DTD>> <<UI>>, User interface (screen, pages, report) dll
Component Diagram
Dependencies
dimodelkan dengan garis terputus dengan panah terbuka gambarkan dependencies dari kiri ke kanan Contoh: <<ASP>> Source Code bergantung pada <<database>> MySQL Dimungkinkan sebuah component dependencies pada interfaces component lainnya Contoh:
Inheritance
inheriting/child component diletakkan dibawah parent component, dengan arah panah menuju ke parent component dimodelkan dengan garis dengan panah tertutup Contoh:
Menu Utama <<UI>>
Penjualan <<application>>
Pembelian <<application>>
Interfaces - Component Diagram Interfaces adalah kumpulan >=1 methode dan >=0 attribute yang dapat dipakai pada class tanpa menjadi behavior suatu class. Jenis interface ada 2 macam yaitu : Provide, digambarkan dengan bentuk lollipop
Pada UML 1.* bisa juga digambarkan dengan garis terputus dengan panah tertutup
Bentuk grafik
Component Diagram
port
adalah bentuk object yang menjelaskan interaksi antara object dan lingkungannya digambarkan sebagai kotak kecil di pinggiran component
Assembly connector
Penghubung antara 2/lebih component dimana sebuah/beberapa component provides interfaces dan component lain required interfaces Digambarkan dengan gabungan bentuk interfaces contoh:
S im p a nd a ta b a se se rv e r
K irim
Isi d a ta
B ro w sin g
Deployment Diagram
Deployment Diagram Deployment/physical diagram menggambarkan detail bagaimana komponen di-deploy dalam infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk men-deploy komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini Deployment diagram digunakan untuk melayani pemodelan hardware yang digunakan dalam implementasi sistem dan asosiasinya antara komponen-komponen tersebut. Elemen yang digunakan dalam deployment diagram adalah nodes (ditunjukkan sebagai sebuah cube), komponen (ditunjukkan sebagai sebuah kotak bujursangkar) dan juga asosiasi.
Deployment diagram ini menunjukkan hardware yang digunakan pada jaringan kantor yang kecil. Application server (node) terhubung dengan database server (node) dan database client (component) sudah terinstall dalam application server. Workstation juga terhubung (association) dengan application server dan juga ke printer.
Deployment Diagram Menggambarkan arsitektur system Pemetaan software(component pada component diagram) yang jalan di sebuah hardware (node pada deployment diagram) Software component tidak selalu menggambarkan setiap software component yang ada pada sebuah Komputer(system operasi/Microsoft Office, dll), akan tetapi software component tersebut akan digambarkan ketika ada hubungan dengan pengimplementasian sebuah system Menggambarkan bagaimana s/w dan h/w bekerja sama Menggambarkan topologi jaringan Artifact Spesifikasi dari bentuk physic informasi yang digunakan atau dihasilkan Contoh : source file, script, executable file, table di database, document word/excel, e-mail, dll Digambarkan dengan bentuk Dapat dihubungkan dengan component pada component diagram Hanya digambarkan dalam sebuah node
perhatikan potongan program dibawah ini yang sesuai dengan artifact yang ada: <! order.ASp> <!-- #include file=buka.asp --> <!-- #include file=uler.txt --> <!-- #include file=data.css -->//code style sheet <script src="tgl.js"> //javascript </script>
Node - Deployment Diagram Adalah hardware seperti computer/PDA ,lap top, handphone peralatan komunikasi data (router,hub,switch,modem) dll Nama Node Digambarkan dengan bentuk kotak 3 dimensi Node dapat digabungkan dengan Node dapat digambarkan component pada dengan bentuk visual, component diagram ataupun gabungan antara node dan visual
Association (connection) - Deployment Diagram Digambarkan dengan sebuah garis yang menghubungkan antara node Setiap association mempunyai sebuah stereotypes seperti
Stereotypes Asychronous HTTP JOBC ODBC RMI RPC Synchronous Web Services Ethernet Istilah Hubungan asynchronous HyperText Transport Protocol (internet protocol_ Java Database Connectivity, a Java API for database access. Open Database Connectivity, a Microsoft API for database access. Remote Method Invocation, a Java communication protocol. Communication via remote procedure calls Komunikasi synchronous Komunikasi melalui Web Services protocols seperti as SOAP and UDDI Ethernet Card
Client
<<asynchronous>>
1 Server
Dependencies - Deployment Diagram Digambarkan dengan garis terputus yang berpanah terbuka deploy Sebuah garis terputus dengan ujung panah terbuka yang tertuju ke node dengan sebuah stereotypes <<deploy>> untuk menggambarkan software yang terdapat pada sebuah hardware dimungkinkan sebuah node memiliki node yang lain faktur.asp dependencies terhadap order.asp
cara diatas dapat digambarkan dengan memasukkan artifact/software ke dalam node/hardware
atau
Manifest - Deployment Diagram bentuk fisik dari artifact digambarkan dengan sebuah garis terputus dengan ujung panah terbuka yang tertuju ke component dengan sebuah stereotypes <<manifest>>
Interaction Overview Diagram Sebuah jenis activity Diagram yang memperlihatkan alur control dalam system atau business process. Setiap node/activity didalam diagram mewakili interaction diagram yang lain Interaction Overview Diagram menggunakan notasi yang dipakai pada Activity diagram dan Sequence Diagram Interaction, sd dilambangkan dengan gambar dibawah ini
Sd = sequence diagram
Timing Diagram Memperlihatkan interaksi ketika tujuan utama diagram adalah waktu Menggambarkan perubahan dalam state atau kondisi dari pengelompokkan instance atau tugas berlebihan Biasanya dipakai untuk memperlihatkan perubahan dalam state object berlebihan dalam merespon ke external events Dipakai untuk memperlihatkan perilaku dari sebuah/beberapa object melalui periode waktu Ada 2 jenis Timing diagram yaitu Concise/ simple notation
:seminar proposed, scheduled, enrolling students, Being Taught, Final Exams, Closed | {Nov 1 .. Des 31} | {jan 1 .. July 31}
State /condition
Object Lifeline
Messag e
atau
C lie nt B ro w se r
C lie n tB ro w ser
C lie n tB ro w se r
Package Diagram Sebuah bentuk pengelompokkan yang memungkinkan untuk mengambil sebuah bentuk di UML dan mengelompokkan elemen-elemennya dalam tingkatan unit yang lebih tinggi. Kegunaan package yang paling umum adalah untuk mengelompokkan class.
Package Diagram
Menggambarkan pengelompokan dari suatu class-class
tu nggakan
guestbook
keluhan pelanggan
kw itansi
i_01 m aster_pelangg an
pelanggan _reg
m aster_status
2.
Weak entity Type Suatu entity yang tidak punya key atribut keberadaannya tidak perlu berdiri sendiri / diluar system. Didalam weak dimungkinkan 1 weak memiliki banyak entity. Setidaknyatidaknya memiliki 1 relasi. Ex.
Karyawan Departemen
Salary
3.
Attribute Keterangan yang dimilikientity / sifat-sifat yang melekat pada entity yang perlu dicatat. Ex. Pegawai: Nopeg, Nama, Alamat, Jenis Kel, tgl. Masuk Key Attribute Bila didalam attribute terdapat nilai sama, maka kita perlu membuat Key attribute sehingga dipastikan tidak akan terjadi nilai/record sama. Ex. Pegawai : sebagai key adalah NoPeg NoPeg Nama Alamat P01 Bella Malang P02 Bella Batu
4.
5.
Multivalued Attribute Satu entity yang memiliki 2 attribute sama Ex. Departemen yang memiliki 2 lokasi pabrik Departemen
Departemen Lokasi
Hal ini bukan berarti bias untuk orang yang mempunyai 2 nama atau 2 alamat
6. Composite Attribute Attribute yang mempunyai nilai attribute lebih dari Satu Ex. Nama : Nama Depan Alamat : Jalan Nama Tengah Nomer Nama Belakang Kota
7.
Derived Attribute Merupakan kombinasi dari attribute-attribute dimana keberadaannya tidak perlu disimpan. Ex. Mata Kuliah MHS
E1
E2
8.
Identifying Relationship Type Bila entity mempunyai hubungan lebih dari satu entity lain.
E1
E2
9.
Relationship Type Menyatakan hubungan antar attribute sehingga terjadi pemetaan. Ex.
M Mahasiswa * * Range Domain
Bisa Ambi l
Hasil Dari Relasi : One To One (1:1) One To Many (1:N) Many To Many (1:M)
Derajat Relationship
UNARY RELATIONSHIP
BINARY RELATIONSHIP
N-ARY RELATIONSHIP
ENTITY-RELATIONSHIP DIAGRAM
PROYEK
KERJA
PEGAWAI
PROYEK PROYEK
PEGAWAI PEGAWAI
ENTITY-RELATIONSHIP DIAGRAM
PEGAWAI 1 1
PUNYA
JABATAN 1 1
PROYEK 1 1
KERJA
PEGAWAI M 1
MHSISWA 1 M
IKUT
MT-KULIAH M 1
ENTITY-RELATIONSHIP DIAGRAM
KERJA
KD-PROY NO-PEG
ENTITY-RELATIONSHIP DIAGRAM
JENIS ENTITY
PEGAWAI 1 ISI M ABSEN
STRONG ENTITY
WEAK ENTITY
ISI NO-PEG
ENTITY-RELATIONSHIP DIAGRAM
NO-PEG KD-BAG
PUNYA
PAKAI
N BARANG
KD-BAG NAMA-BAG
BAGIAN
a. Prosedur Order Penjualan Setiap costumer dapat memesan barang datang langsung atau melalui faximile dengan menyertakan dokumen PO yang diterima oleh bagian penjualan. Kemudian bagian penjualan berdasarkan PO, memeriksa pesanan barang dengan menggunakan kartu stock, apabila stock barang ada maka di hitung nilai penjualan dan dicatat kedalam faktur penjualan. Jika stock barang tidak ada, maka di catat ke dokumen Daftar Permintaan Stock Barang (DPSB), faktur penjualan rangkap 4 (empat), yang telah di buat didistribusikan ke Kasir
b. Prosedur Pembayaran Tunai Setelah customer mendapat konfirmasi tentang pesanan pembelian disetujui, maka customer melakukan transaksi pembayaran melalui transfer uang ke bank yang ditunjuk dengan bukti setoran. Berdasarkan bukti setoran, Kasir membuka arsip penjualan yang dicocokan dengan bukti setoran. Apabila sesuai dengan nilai penjualan maka dibuatkan kwitansi lunas, dan merekap nilai penjualan Harian/Daily Sales Report (DSR). Distribusi dokumendokumen berdasarkan nilai transaksi penjualan sebagai berikut : untuk Kwitansi dan faktur penjualan di berikan kepada customer. Gudang mendapat tembusan pengeluaran barang dari kasir sesuai barang yang di pesan, dan Copy faktur diberikan ke Bagian Penjualan.
c. Prosedur Pennyiapan Barang kirim Gudang Setelah menerima Tembusan pengeluaran barang, maka menyiapkan barang yang akan dikirim dengan mencatat barang keluar ke kartu gudang dan membuat dokumen surat keluar barang yang ditembuskan ke bagian Penjualan. d. Prosedur Pengiriman Barang Bagian Penjualan berdasarkan Surat keluar barang, selanjutnya membuka arsip faktur penjualan untuk mencatat barang yang akan dikirim ke dokumen Surat Jalan. Dokumen surat keluar barang didistribusikan ke Bagian Pengiriman beserta barang dan disampaikan ke Customer
e.Prosedur Pembuatan Laporan Setiap akhir periode di buat laporan penjualan bulanan, berdasarkan rekap penjualan harian dan faktur penjualan. Laporan stock barang keluar berdasarkan Kartu Stock dan Kartu Gudang. Ke-dua laporan tersebut diberikan kepada Manajer Penjualan untuk proses evaluasi penjualan selama satu bulan. PERTANYAAN : 1. Gambarkan DAD yang terdiri dari : - Diagram KONTEKS - Diagram NOL - Diagram DETAIL 2. Analisa beberapa permasalahan dari Prosedur Sistem Penjualan
B. Prosedur Pembayaran Tunai Setelah Customer mendapat konfirmasi tentang pesanan pembelian disetujui, maka Customer melakukan transaksi pembayaran melalui transfer uang ke bank yang ditunjuk dengan bukti setoran. Berdasarkan bukti setoran, Kasir membuka transaksi pembayaran dengan membuka database penjualan (file barang, file customer, file faktur, file Isi_faktur ). Kemudian data pembayaran disimpan kedalam file bayar. Berdasarkan file bayar maka dilakukan pencetakan kwitansi ( dua rangkap ). Semua dokumen penjualan didistribusikan oleh Kasir ke beberapa bagian, yaitu sebagai berikut :
Kwitansi Asli dan Faktur Penjualan Asli diberikan ke Customer. Copy kwitansi dan Copy Faktur Penjualan di berikan ke Bagian Akunting Copy Faktur didistribusikan ke Bagian Penjualan, Bagian Gudang (Tembusan Pengeluaran Barang).
C. Prosedur Jurnal Penjualan Bagian Akunting melakukan proses up-date transaksi jurnal penjualan berdasarkan file bayar dan file perkiraan yang disimpan ke file jurnal. D. Prosedur Pengiriman Barang Bagian Penjualan membuat dokumen Surat Jalan (SJ) dengan mengentry jumlah barang yang dijual berdasarkan database penjualan(fie barang,file customer, file faktur dan file Isi_faktur) yang disimpan dalam file SJ dan file Isi_SJ. Dokumen SJ di berikan ke bagian Pengiriman yang diantar ke Customer. Dokumen SJ didistribusikan ke Gudang untuk menyiapkan barang agar dikirimkan Ke Customer.
E. Prosedur Pembuatan Laporan Setiap akhir periode di buat laporan penjualan bulanan, berdasarkan rekap penjualan harian dan faktur penjualan. Laporan stock barang keluar berdasarkan Kartu Stock dan Kartu Gudang. Ke-dua laporan tersebut diberikan kepada Manajer Penjualan untuk proses evaluasi penjualan selama satu bulan. PERTANYAAN : 1. Gambarkan DAD Usulan yang terdiri dari : - Diagram KONTEKS - Diagram NOL - Diagram DETAIL 2. Gambarkan ERD dari kasus tersebut
Latihan
1. Suatu network yang menggambarkan suatu sistem automatic/ komputerisasi , manual dan gabungan dari keduanya dalam susunan berbentuk komponen sistem yang saling berhubungan sesuai dengan aturan mainnya a. DFD d. entity b. proses e. jaringan c. entitas 2. Simbol relationship pada ERD biasanya menggunakan keterangan berupa a. kata benda d. kata sifat b. kata kerja e. kata perintah c. kata pengganti
2. Simbol relationship pada ERD biasanya menggunakan keterangan berupa a. kata benda d. kata sifat b. kata kerja e. kata perintah c. kata pengganti 3. Dibawah ini adalah pernyataan yang benar dari aturan main DFD , kecuali a. Dlm DFD tidak boleh menghubungkan antara EXTERNAL ENTITY dgn EXTERNAL ENTITY secara langsung b. Dlm DFD tidak boleh menghubungkan antara DATA STORE dgn DATA STORE secara langsung c. Dlm DFD tidak boleh menghubungkan antara DATA STORE dgnEXTERNAL ENTITY secara langsung (atau sebaliknya) d. Setiap PROSES harus ada DATA FLOW yg masuk dan tidak ada DATA FLOW yg keluar. e. Salah semua
3. Dibawah ini adalah pernyataan yang benar dari aturan main DFD , kecuali a. Dlm DFD tidak boleh menghubungkan antara EXTERNAL ENTITY dgn EXTERNAL ENTITY secara langsung b. Dlm DFD tidak boleh menghubungkan antara DATA STORE dgn DATA STORE secara langsung c. Dlm DFD tidak boleh menghubungkan antara DATA STORE dgnEXTERNAL ENTITY secara langsung (atau sebaliknya) d. Setiap PROSES harus ada DATA FLOW yg masuk dan tidak ada DATA FLOW yg keluar. e. Salah semua 4. Tahapan proses pembuatan DFD yang menggambarkan sistem secara global a. Diagram konteks d. Diagram Nol b. Diagram Detail e. diagram Top Down c. Diagram Objek
4. Tahapan proses pembuatan DFD yang menggambarkan sistem secara global a. Diagram konteks d. Diagram Nol b. Diagram Detail e. diagram Top Down c. Diagram Objek
1. Suatu network yang menggambarkan suatu sistem automatic/ komputerisasi , manual dan gabungan dari keduanya dalam susunan berbentuk komponen sistem yang saling berhubungan sesuai dengan aturan mainnya a. DFD d. entity b. proses e. jaringan c. entitas
Pokok Bahasan dalam RPL : Desain PL dan Rekayasa PL Prinsip Desain Konsep Desain Desain Modular Afektif Model Desain Dokumentasi Desain
Buku Referensi :
Pressman, RS., 2008, Software Engineering: A Practitioners Approach, New York: McGraw-Hill Sommerville, I, 2007, Software Engineering, Addsion Wesley
PROSES DESAIN
Desain dan Kualitas Desain harus mengimplementasikan semua kebutuhan eksplisit yang ada dalam model analisis, dan dia harus mengakomodasi semua kebutuhan implisit yang diinginkan oleh konsumen. Desain harus dapat berupa panduan yang dapat dibaca dan dipahami oleh orang-orang yang akan membuat kode, dan mereka yang menguji serta nantinya mendukung PL tersebut. Desain harus menyediakan gambaran utuh dari PL, menggambarkan domain data, fungsional, dan perilaku dari perspektif implementasi.
Panduan Kualitas
Sebuah desain harus menampilkan arsitektur yang 1. Dibuat menggunakan pola atau style arsitektural yang sudah dikenal, 2. Terdiri dari komponen-komponen yang menunjukkan karakteristik desain yang baik dan 3. Dapat diimplementasi dalam bentul yang evolusioner. Untuk sistem yang lebih kecil, desain kadang dapat dikembangkan secara linear. Sebuah desain harus berbentuk modular; oleh karena itu PL harus secara logis dipartisi menjadi beberapa elemen subsistem Sebuah desain harus berisi representasi yang berbeda dari data ,arsitektur, antarmuka, dan komponen.
Evolusi Desain PL Karakteristik Umuj : 1. Mekanisme penerjemahan suatu model analisis ke dalam representasi desain. 2. Notasi untuk merepresentasikan komponen-komponen fungsional dan interfacenya. 3. Heuristik bagi penyaringan dan partisi. 4. Pedoman bagi penilaian kualitas.
PRINSIP DESAIN Menurut Davis : Proses desain tidak boleh berjalan dengan kacamata kuda Proses desain harus bisa dirujuk dari model analisis. Proses desain tidak boleh mengulang penemuanpenemuan dasar. Desain harus dapat meminimalkan jarak intelektual antara PL dan permasalah yang ada di dunia nyata. Desain harus menampakkan keseragaman dan integrasi.
PRINSIP DESAIN (lanjutan) Desain harus terstruktur untuk mengakomodasi perubahan. Desain harus terstruktur untuk turun secara bertahap, walaupun ketika data, event, atau kondisi operasi yang menyimpang ditemui. Desain bukan coding dan coding bukan desain. Desain harus dapat dipantau kualitasnya mulai dari dia dibuat, bukan setelah jadi. Desain harus direview untuk meminimalkan kesalahan semantik (konseptual).
Abstraksi Data
Abstraksi Prosedur
Penyaringan
Penyaringan Stepwise adalah strategi desain top down yang diusulkan ole Wiklaus Wirth. Penyaringan sebenarnya adalah proses elaborasi . Dimulai dengan suatu statemen fungsi pada suatu tingkat abstraksi tinggi. Statemen fungsi adalah statemen yang menggambarkan fungsi atau informasi secara konseptual. Penyaringan membantu desainer untuk mengungkapkan detail tingkat rendah ketika desain berjalan.
Modularitas
Meyer : 5 kriteria mengevaluasi metode desain 1. Dekomposabilitas Modular dekomposisi 2. Komposabilitas Modular 3. Kemampuan Pemahaman Modular 4. Kontinuitas Modular 5. Ptoreksi Modular
Arsitektur PL
Shaw dan Garlan : sekumpulan properti sebagai bagian dari desain arsitektural : 1. Properti Struktural spek representasi desain arsitektur ini menentukan komponen-komponen sebuah sistem (mis: modul, objek, filter), dan pola komponen-komponen tersebut dipaket dan berinteraksi satu dengan yang lain. Sebagai contoh: objek dipaket untuk enkapsulasi baik data dan proses yang memanipulasi data dan berinteraksi dengan invokasi method
Arsitektur PL (lanjutan)
2. Properti Ekstra Fungsional Deskripsi desain arsitektur harus menggambarkan bagaimana arsitektur mencapai kebutuhan kinerja, kapasitas, reliabilitas, keamanan, adaptabilitas, dan karakteristik sistem yang lain. 3. Keluarga dari sistem yang berhubungan Desain arsitektur harus dapat menggambar pola-pola yang diulang, yang secara umum ditemukan dalam disain keluarga atau sistem yang mirip. Esensinya, desain harus mempunyai kemampuan untuk menggunakan kembali blok-blok bangunan arsitektur.
Patern / Pola
Design Pattern Template Nama Patternmenggambarkan esensi pattern dalam nama yang singkat tapi ekspresif Intent/Tujuanmenjelaskan pattern dan apa yang dilakukan Juga dikenal sebagai/Also-known-asDaftar sinonim untuk pattern terkait Motivation/Motivasimenyediakan contoh masalah Aplikabilitasmenjelaskan situasi desain spesifik dimana pattern dapat diterapkan Strukturmenggambarkan class yang dibutuhkan untuk implementasi pattern Participantsmenggambarkan tanggungjawab class-class yang diperlukan untuk mengimplementasikan pattern Collaborationsmenggambarkan bagaimana participan berkolaborasi untuk memikul tanggung jwabanya. Konsekuensimenggambarkan pengaruh desain terhadap pattern dan potensi masalah yang harus diperhatikan ketika pattern diimplementasi. Related patternsrelasi referensi silang design patterns
Hierarki Kontrol
Disebut juga struktur program. Yang paling umum digunakan adalah diagram pohon Depth dan width mengindikasikan jumlah modul yang dikontrol dan rentang keseluruan kontrol Fan-out pengukuran jumlah modul yang dikontrol secara langsung oleh modul yang lain. Fan-in mengindikasikan berapa banyak modul yang secara langsung mengontrol sebuah modul yang diberikan. Hubnugan kontrol diantara kontrol : Superordinat (modul yang mengontrol modul lain). Subordinat (modul yang dikontrol modul lain Visibilitas (komponen program yang dapat dipakai sebagai data oleh komponen lainnya) Konektivitas (Komponen yang dipakai secara tidak langsung oleh sebuah modul yang ditetapkan)
Partisi Struktural
Partisi Vertikal
Didesain sehingga pengambilan keputusan dan pekerjaan distratifikasi Modul pengambilan keputusan tetap ada di puncak arsitektur
decisiondecision -makers
workers
function 2
Struktur Data
Struktur Data menentukan : Organisasi dan kompleksitas Item Skalar Metode akses Vektor Sekuensial
Modularitas
Berapakah jumlah modul yang pas untuk desainPL tertentu?
Penyembunyian Informasi
Langkah-langkah Refinement
Indepedensi Fungsi
Kohesi Suatu ekstensi natural dari konsep penyembunyian informasi Kohesif Koisidental Modul yang melakukan serangkaian tugas yang saling berhubungan secara lepas. Kohesif secara Logis Modul yang melakukan tugas-tugas yang berhubungan secara logis. Kohesif Temporal Modul berisi tugas-tugas yang berhubungan dengan kenyataan bahwa semua harus dieksekusi dalam jangkauan waktu yang sama.
Perangkaian
Perangkaian : Pengukuran interkoneksi diantara modul-modul pada sebuah struktur program Heuristik Desain 1. Evaluasi iterasi pertama dari struktur program untuk mengurangi perangkaian dan meningkatkan kohesi. 2. Usahakan meminimalkan struktur dengan fan-out yang tinggi ; usahakan untuk melakukan fan-in pada saat kedalaman bertambah. 3. Jaga lingkup efek dari suatu modul ada dalam lingkup kontrol dari modul itu. 4. Evaluasi interface modul untuk mengurangi kompleksitas dan redudansi dan meningkatkan konsistensi
Perangkaian (lanjutan)
5. Tetapkan modul-modul yang fungsinya dapat diprediksi, tetapi hindari modul yang terlalu restriktif. 6. Usahakan modulmodul entri terkontrol menghindari hubungan patologisdengan 7. Kemaslah PL berdasarkan batasan desain dan persyaratan.
MODEL DESAIN
Direpresentasikan sebagai sebuah piramid. Konsep Desain OO Desain Class Entity classes Boundary classes Controller classes Inheritancesemua tanggung jawab superclass akan diwarisi oleh semua subclassnya Messagesstimulasi beberapa perilaku yang dapat terjadi pada objek penerima pesan Polymorphismsebuah karakteristik yang mengurangi usaha yang dibutuhkan untuk memperluas desain
DESAIN CLASS
Analisis class disempurnakan dalam desain untuk menjadi class-class entitas Class-class boundary dikembangkan selama desain untuk membuat interface(mis. Layar interaktif atau laporan cetak) yang dilihat pengguna dan berinteraksi. - Class-class boundary didesain dengan tanggungjawab untuk mengelola cara objek entitas ditampilkan kepada user. Class-class control didesain untuk mengelola : - Pembuatan atau perubahan objek entitas; - nstansiasi object boundary dengan mengambil informasi dari objek entitas; - Komunikasi kompleks antara sekelompok objek; - Validasi data yang dikomunikasikan antar objek atau antar pengguna dan aplikasi.
Inheritance
Pilihan-pilihan desain : - Class dapat didesain dan dibangun dari nol. Jika demikian, inheritance tidak digunakan. - Hierarki class dapat dicari untuk mencari kemungkinan jika sebuah class yang lebih tinggi pada hierarki (superclass) memiliki atribut-atribut dan operasi-operasi yang paling banyak dibutuhkan. Class baru ini diturunkan dari superclass dan beberapa tambahan dapat diberikan jika dibutuhkan. - Hierarki class dapat di restrukturisasi sehingga atributatribut dan operasi-operasi yang dibutuhkan dan diturunkan oleh class baru tersebut. - Karakteristik dari class yang sudah ada dapat di override dan atribut-atribut dan operasi-operasi dengan versi berbeda dapat diimplementasikan untuk class baru tersebut.
Message
Polymorphism
Pendekatan konvensional case of graphtype: if graphtype = linegraph then DrawLineGraph (data); if graphtype = piechart then DrawPieChart (data); if graphtype = histogram then DrawHisto (data); if graphtype = kiviat then DrawKiviat (data); end case; Semua graphs menjadi subclass dari class umum yang disebut graph. Menggunakan konsep over loading, setiap subclass mendefinisikan operasi yang disebut draw. Sebuah object dapat mengirim pesan draw pada salah satu instansiasi objek dari salah satu subclassnya. Objek yang menerima message akan menjalankan operasi draw nya sendriri untuk membuat graph yang sesuai..
Model Desain
Elemen Interface
Elemen Komponen
Elemen Deployment
Design Pattern
Desainer terbaik di segala bidang tetap mempunyai keterbatasan untuk melihat pola yang mencirikan sebuah masalah dan menghubungkannya dengan pola yang dapat dikombinasikan untuk membuat solusi Sebuah deskripsi dari design pattern dapat juga dilihat sebagai sekumpulan design forces. Design forcesmenjelaskan kebutuhan non fungsional (misalkan : kemudahan perawatan, portabilitas) yang dihubungkan dengan PL dimana pattern akan diaplikasikan. Karakteristik pattern (class, tanggungjawab, dan kolaborasi) mengindikasikan atribut-atrobit desain yang harus diatur untuk memungkinkan pattern mengakomodasi permasalahan yang bervariasi
Frameworks
Sebuah framework bukan merupakan pattern arsitektur, namun lebih merupakan kerangka dengan sekumpulan plug points (yang juga disebut hooksdan slots) yang memungkinkannya untuk beradaptasi dengan domain permasalahan tertentu. Gamma et al mencatat bahwa: Design patterns lebih abstrak dari frameworks. Design patterns adalah elemen-elemen arsitektural yang lebih kecil daripada frameworks Design patterns lebih umum daripada frameworks
DOKUMENTASI DESAIN
Ruang lingkup a. sasaran sistem b. persyaratan utama PL c. batasan dan pembatasan desain Desain Data a. Obyek dan struktur data resultan b. Struktur file dan database 1. struktur file eksternal 2. data global a. struktur logis b. deskripsi record logis c. metode akses 3. file dan referensi lintas data
Pokok Bahasan dalam RPL : Desain Data Desain Arsitektur Proses Desain Arsitektur Pasca Pemrosesan Desain Optimasi Desain Arsitektur
Buku Referensi :
Pressman, RS., 2008, Software Engineering: A Practitioners Approach, New York: McGraw-Hill Sommerville, I, 2007, Software Engineering, Addsion Wesley
DESAIN DATA
1. 2. 3. 4. 5. 6. 7. Aktivitas pertama (dan beberapa sering mengatakan yang terpenting) dari 4 aktivitas desain yang dilakukan selama RPL. Prinsip-prinsip : Prinsip analisis sistematik yang diaplikasikan pada fungsi dan perilaku seharusnya diaplikasikan juga pada data. Semua struktur data dan operasi yang dilakukan pada masing-masing struktur data harus diidentifikasi. Kamus data harus dibangun dan digunakan untuk menentukan baik data maupun desain program. Keputusan desain data tingkat rendah harus ditunda sampai akhir proses desain. Representasi stuktur data hanya boleh diketahui oleh modul-modul yang harus menggunakan secara langsung data yang diisikan didalam struktur terseb ut. Pustaka struktur data dan operasi yang berguna yang dapat diaplikasikan pada struktur data tersebut harus dikembangan. Desain PL dan bahasa pemrograman harus mendukung spesifikasi dan realisasi dari tipe-tipe data absktrak.
DESAIN ARSITEKTUR
Untuk mengembangkan struktur program modular dan merepresentasikan hubungan kontrol antar modul. Membentuk struktur program dan struktur data dengan menentukan interface yang memungkinkan data mengalir melalui program. Kontributor Perintis desain PL yang didasarkan pada aliran data melalui sebuah sistem. Area Aplikasi luasnya aplikasi dimana aplikasi dapat diaplikasikan.
Karakteristik Aliran
PEMETAAN TRANSFORMASI
Serangkaian langkah desain yang mengijinkan sebuah DFD dengan karakteristik aliran transformasi untuk dipetakan ke dalam tempalte yang telah ditentukan untuk struktur program. Langkah-langkah : 1. Kaji model sistem fundamental. 2. Kaji dan saring diagram aliran data untuk PL. 3. Tentukan apakah DFD memiliki karakteristik aliran transformasi atau transaksi. 4. Isolasi pusat transformasi dengan mengkhususkan batas aliran masuk dan keluar. 5. Lakukan pemfaktoran tingkat pertama. 6. Lakukan pemfaktoran tingkat kedua. 7. Saringlah struktur program iterasi pertama dengan menggunakan heuristik desain bagi kualitas perangkat lunak yang telah ditingkatkan.
"Transform" mapping
PEMETAAN TRANSAKSI
Langkah-langkah desain : 1. Kaji model sistem fundamental. 2. Kaji dan saring diagram aliran data untuk PL. 3. Tentukan apakah DFD memiliki karakteristik aliran transformasi atau transaksi. 4. Identifikasi pusat transaksi dan karakteristik aliran sepanjang masing-masing jalur aksi. 5. Petakan DFD pada sebuah struktur program yang sesuai dengan pemrosesan transaksi. 6. Faktorkan dan saringkan struktur transaksi dan struktur masing-masing jalur aksi. 7. Saring struktur program iterasi pertama dengan menggunakan heuristik desian untuk kualitas PL yng dikembangkan.
Program Architecture
Pokok Bahasan dalam RPL : Desain Interface Desain Interface Manusia Mesin Desain Prosedural Coding
Buku Referensi :
Pressman, RS., 2008, Software Engineering: A Practitioners Approach, New York: McGraw-Hill Sommerville, I, 2007, Software Engineering, Addsion Wesley
DESAIN INTERFACE
Memfokuskan diri pada 3 area perhatian : 1. Desain interface antara modul-modul PL. 2. Desain interface antara PL dan prosedur dan konsumen informasi, bukan manusia lainnya (yakni entitas eksternal lainnya). 3. Desain interface antara seorang manusia (user) dan komputer. Desain interface pemakai internal (desain interface inter-modular) dikendalikan oleh data yang harus mengalir diantara modul-modul dan karakteristik bahasa pemrograman dimana PL akan diimplementasikan. Desain interface pemakai eksternal Dimulai dengan evaluasi terhadap masing-masing entitas eksternal yang direpresentasikan pada DFD model analisis. Desain Interface Pemakai Berkaitan dengan studi terhadap manusia juga terhadap isu-isu teknologi
Membuat Prototipe Interface #n Modifikasi desain dilakukan Evaluasi dipelajari oleh desainer
DESAIN PROSEDURAL
Terjadi setelah data, desain arsitektur dan interface dibangun. Pemrograman Terstruktur Urutan (langkah pemrosesan yang penting dalam spesifikasi sembarang algoritma). Kondisi (fasilitas bagi pemrosesan yang dipilih berdasarkan beberapa kejadian logis). Pengulangan (menyediakan looping)
CODING
Pertemuan 12
IMPLEMENTASI
POKOK BAHASAN
Makna & Tujuan Implementasi Perencanaan Implementasi Hal Penting Dalam Implementasi Persiapan Dokumentasi Pemasangan Atau Konversi Sistem Baru Ke Sistem Lama Evaluasi Sistem Baru Lingkungan Pemrograman Programming Style Prinsip Portability & Reusable (Kemudahan & Penggunaan Ulang Komponen) CASE Tools
Hal Penting Dalam Implementasi (7) Penjelasan Tanpa dokumentasi yang jelas dan akurat Pengembangan sistem
Konversi ini baik dilakukan jika : Sistem baru tidak menggantikan sistem lama Sistem lama sepenuhnya tidak bernilai Sistem baru bersifat kecil/sederhana Rancangan sistem baru sangat berbeda dari sistem lama
Memberikan derajat proteksi yang tinggi dari kegagalan sistem baru Biaya yang dibutuhkan cukup besar karena keduanya harus jalan bersama-sama
Sistem baru di implementasikan sedikit demi sedikit untuk menggantikan sistem lama Sistem harus disegmentasi Perlu biaya tambahan utk membangun interface temporer dg sistem lama Proses implementasi membutuhkan waktu yang panjang
Perlunya segmentasi organisasi Resiko lebih rendah dibandingkan metode konversi langsung Biaya lebih rendah dibanding metode paralel Cocok digunakan apabila adanya perubahan prosedur, HardWare, dan SoftWare
Tahapan Implementasi
Struktur dekomposisi, struktur data, dan identitas dipilih dan di kerjakan sampai prosedur desain mudah untuk ditata ulang dalam sebuah implementasi Level abstraksi pada desain, misal class, modul, algoritma, struktur data, dan tipe data harus diwujudkan dalam implementasi Antarmuka antara komponen sistem perangkat lunak harus diwujudkan secara jelas pada tahap implementasi Kode program tersebut harus dapat di cek konsistensinya pada setiap objek dan operasinya secara langsung menggunakan kompilator.
11. Ketersediaan Tool Pembangunan Semua peralatan terintegrasi dalam satu interface
Programming Style
Menulis sebuah program adalah seni dan merupakan proses yang kreatif Gaya pemrograman pada programmer mempengaruhi tingkat kemudahan pembacaan program yang dibuatnya Buku Code Complete Mengulas tuntas suatu gaya pemrograman bahkan di dalamnya diberkan contoh variasi yang cukup banyak. Gaya pemrograman yang baik sangat didukung dari tahap desain dan perencanaan implementasi yang baik
Strategi uji coba perangkat lunak dilakukan untuk memudahkan para perancang untuk menentukan keberhasilan system yang telah dikerjakan
Proses Testing
Unit Testing Module Testing Sub-system Testing System Testing Acceptance Testing
Component Testing
Integration Testing
User Testing
Proses Testing
Unit testing Pengujian masing-masing unit komponen program untuk meyakinkan bahwa sudah beroperasi secara benar Module Testing Pengujian terhadap koleksi unit-unit komponen yang saling berhubungan. Sub-system Testing Pengujian terhadap koleksi module-module membentuk suatu sub-system (aplikasi)
yang
Proses Testing
System Testing Pengujian terhadap integrasi sub-system, keterhubungan antar sub-system yaitu
Acceptance Testing Pengujian terakhirs sebelum sistem dipakai oleh user. Melibatkan pengujian dengan data dari pengguna sistem. Biasa dikenal sebagai alpha test (beta test untuk software komersial, dimana pengujian dilakukan oleh potensial customer)
5
Rencana Pengujian
Proses testing Deskripsi fase-fase utama dalam pengujian Pelacakan Kebutuhan Semua kebutuhan user diuji secara individu Item yg diuji Menspesifikasi komponen sistem yang diuji Jadual Testing Prosedur Pencatatan Hasil dan Prosedur Kebutuhan akan Hardware dan Software Kendala-kendala Mis: kekuranga staff, alat, waktu dll.
Prioritas Testing
Hanya test yang lengkap yang dapat meyakinkan sistem terbebas dari kesalahan, tetapi hal ini sangat sulit dilakukan. Prioritas dilakukan terhadap pengujian kemampuan sistem, bukan masing-masing komponennya. Pengujian untuk situasi yang tipikal lebih penting dibandingkan pengujian terhadap nilai batas.
Pengujian Unit
Berfokus pada inti terkecil dari desain perangkat lunak yaitu modul Uji coba unit selalu berorientasi pada white box testing Dapat dikerjakan paralel atau beruntun dengan modul lainnya.
Integration Testing
Pengujian keseluruhan system atau sub-system yang terdiri dari komponen yang terintegrasi. Test integrasi menggunakan black-box dengan test case ditentukan dari spesifikasi. Kesulitannya adalah menemukan/melokasikan Penggunaan Incremental integration testing dapat mengurangi masalah tersebut.
T1
T2
T3
T4
T5
Level 2
Level 2
Level 2
Level 3 stubs
Bottom Up Testing
Test drivers Level N Level N Level N Level N Level N Testing sequence
Test drivers
Level N1
Level N1
Level N1
Pendekatan Testing
Architectural Validation Top-down integration testing lebih baik digunakan dalam menemukan error dalam sistem arsitektur. System Demonstration Top-down integration testing hanya membatasi pengujian pada awal tahap pengembangan system. Test Implementation Seringkali lebih mudah dengan menggunakan bottomup integration testing
Interface Testing
Dilakukan kalau module-module dan sub-system terintegrasi dan membentuk sistem yang lebih besar Tujuannya untuk medeteksi fault terhadap kesalahan interface atau asumsi yang tidak valid tentang interface tersebut. Sangat penting untuk pengujian terhadap pengembangan sistem dengan menggunakan pendekatan object-oriented yang didefinisikan oleh object-objectnya
Pengujian Validasi
Kajian Konfigurasi (audit) Elemen dari proses validasi Memastikan apakah semua elemen konfigurasi perangkat lunak telah dikembangkan dengan tepat Pengujian Alpha dan Beta Pengujian Alpha Usability labs Usability factors checklist Pengujian Beta
Pengujian Sistem
Pengujian Perbaikan Pengujian Keamanan Pengujian Stress Pengujian Kinerja
Volume Testing
Menemukan kelemahan sistem selama melakukan pemrosesan data dalam jumlah yang besar dalam periode waktu yang singkat. Tujuan: meyakinkan bahwa sistem tetap melakukan pemrosesan data antar batasan fisik dan batasan logik. Contoh: Mengujikan proses antar server dan antar partisi hardisk pada satu server.
Stress Testing
Tujuan: mengetahui kemampuan sistem dalam melakukan transaksi selama periode waktu puncak proses. Contoh periode puncak: ketika penolakan proses login on-line setelah sistem down atau pada kasus batch, pengiriman batch proses dalam jumlah yang besar dilakukan setelah sistem down. Contoh: Melakukan login ke server ketika sejumlah besar workstation melakukan proses menjalankan perintah sql database.
Performance Testing
Dilakukan secara paralel dengan Volume dan Stress testing untuk mengetahui unjuk kerja sistem (waktu respon, throughput rate) pada beberapa kondisi proses dan konfigurasi. Dilakukan pada semua konfigurasi sistem perangkat keras dan lunak. Misal : pada aplikasi Client-Server diujikan pada kondisi korporate ataupun lingkungan sendiri (LAN vs. WAN, Laptop vs. Desktop) Menguji sistem dengan hubungannya ke sistem yang lain pada server yang sama. Load Balancing Monitor Network Monitor
Debugging
PERTEMUAN 14
TESTING
Pengujian perangkat lunak adalah proses menjalankan dan mengevaluasi sebuah perangkat lunak secara manual maupun otomatis untuk menguji apakah perangkat lunak sudah memenuhi persyaratan atau belum, atau untuk menentukan perbedaan antara hasil yang diharapkan dengan hasil sebenarnya. Pengujian merupakan suatu tahapan pengerjaan yang bertujuan mencari kesalahan program. Kesalahan yang terjadi selama proses pengembangan perangkat lunak akan mengakibatkan bertambahnya waktu untuk menyelesaikan pekerjaan tersebut. Pengujian hendaknya dilakukan pada setiap tahap pengembangan yaitu mulai dari tahap analisis kebutuhan sampai dengan tahap perawatan.
PRINSIP PENGUJIAN
Beberapa prinsip pengujian yang harus diperhatikan (diusulkan oleh Davis): 1. Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan. 2. Pengujian harus direncanakan lama sebelum pengujian itu dimulai. 3. Prinsip Pareto berlaku untuk pengujian PL. Prinsip Pareto mengimplikasikan 80% dari semua kesalahan yang ditemukan selama pengujian sepertinya akan dapat ditelusuri sampai 20% dari semua modul program.
SASARAN PENGUJIAN
Glen Mayers menyatakan sejumlah aturan yang dapat dipandang sebagai sasaran dari pengujian Pengujian perangkat lunak adalah suatu proses pengeksekusian program dengan tujuan menemukan kesalahan (error) Pengujian (Test case) yang baik adalah yang mempunyai probabilitas yang tinggi untuk menemukan error yang tak diketemukan Pengujian yang sukses adalah pengujian yang dapat menemukan kesalahan (error) yang tidak ditemukan sebelumnya
TUJUAN PENGUJIAN
Tujuan yang diinginkan dari pelaksanaan pengujian perangkat lunak adalah : Menilai apakah perangkat lunak yang dikembangkan telah memenuhi kebutuhan pemakai. Menilai apakah tahap pengembangan perangkat lunak telah sesuai dengan metodologi yang digunakan. Membuat dokumentasi hasil pengujian yang menginformasikan kesesuaian perangkat lunak yang diuji dengan spesifikasi yang telah ditentukan.
TEST ABILITAS
Testabilitas Perangkat Lunak adalah seberapa mudah sebuah program komputer dapat diuji. Karena pengujian sangat sulit, perlu diketahui apa yang dapat dilakukan untuk membuatnya menjadi mudah.
11
16
17
19
23
Lingkaran/node : Menggambarkan satu/lebih perintah prosedural. Urutan proses dan keputusan dapat dipetakan dalam satu node. Tanda panah/edge : Menggambarkan aliran kontrol. Setiap node harus mempunyai tujuan node Region : Adalah daerah yg dibatasi oleh edge dan node. Termasuk daerah diluar grafik alir.
8 5 9
Independent Paths
1, 2, 3, 8, 9 1, 2, 3, 4, 6, 7, 2 1, 2, 3, 4, 5, 7, 2 1, 2, 3, 4, 6, 7, 2, 8, 9 Test cases harus ditentukan sehingga semua path tersebut tereksekusi.
30
31
34