Pertemuan 1 PENGENALAN REKAYASA PERANGKAT LUNAK Pokok Bahasan dalam RPL :
RPL sebagai produk dan sebagai produk Konsep manajemen proyek Proses pembangunan PL dan metrik proyek Perencanaan proyek PL Manajemen resiko dlm pelaksanaan proyek Penjadwalan dan penelusuran proyek pembangunan PL Jaminan kualitas PL Manajemen konfigurasi PL Rekayasa sistem ke arah CB
Pokok Bahasan dalam RPL (lanjutan)
Konsep dan prinsip analisis Pemodelan analisis Konsep dan prinsip desain Metode desain Implementasi pembangunan Teknik pengujian perangkat Strategi perancangan PL CASE tool pembangunan PL
Buku Referensi :
• Pressman, RS., 2008, Software Engineering: A Practitioner’s Approach, New York: McGraw-Hill • Sommerville, I, 2007, Software Engineering, Addsion Wesley
Rekayasa Perangkat Lunak
Perangkat Lunak? (Software??) Rekayasa Perangkat lunak-RPL? (Software engineering-SE??) Rekayasa sistem-RS? (system engineering-SyE??) Evolusi Perangkat Lunak Computer Science vs RPL RPL vs RS ?? Pelaku yang berhubungan dengan Rekayasa Perangkat Lunak Mitos yang ada berkembang Tantangan dalam Pengembangan Perangkat Lunak
Definisi Perangkat Lunak (PL) IEEE-Standar Glossary of Software Engineering Terminology, 1990: “Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.” Maksudnya : Perangkat lunak merupakan kumpulan dari program, prosedur, dan dokumen data lain yang saling berhubungan yang merepresentasikan masalah di dunia nyata yang dikonfigurasikan dalam sebuah bentuk aplikasi yang harus dikerjakan komputer Produk Perangkat Lunak Perangkat lunak tidak sama dengan produk perangkat keras Produk perangkat lunak dikembangkan (developed) atau direkayasa (engineered). Sebagian besar
dikembangkan atau dibangun berdasrkan pemesanan dan sebagian kecil dibuat secara paket. Tidak dipabrikkan seperti pabrik perangkat keras, misal komputer, mobil. Perangkat lunak secara pemakaian tidak pernah AUS layaknya perangkat keras
Produk Perangkat Lunak (2) 2 Bentuk produk perangkat lunak: 1. Produk Generik (Umum) Sistem stand-alone standar yang diproduksi oleh organisasi pengembang dan dijual ke pasar terbuka ke siapapun yg membelinya. Biasa disebut sebagai software shrink-wrapped. Contoh : word processor, Database. 2. Produk pesanan (yang disesuaikan) Sistem yang dipesan oleh pelanggan tertentu. Dikembangkan khusus bagi pelanggan oleh kontraktor perangkat lunak. Contoh : Sistem untuk mendukung proses bisnis tertentu dan sistem kontrol lalu lintas udara
Produk Perangkat Lunak (3) Perbedaan PENTING antara 2 bentuk perangkat lunak : Pada produk generik, mengembangkan perangkat spesifikasi perangkat lunak.
Pada produk pesanan, spesifikasi biasanya dikembangkan dan dikontrol oleh organisasi yang membeli perangkat lunak tersebut.
Produk Perangkat Lunak (4) Karakteristik perangkat lunak yang baik: Usability : Mempunyai daya guna yang tinggi be reliable : Mampu diandalkan maintenability : Mudah dirawat/diperbaiki Efficiency : perangkat perangkat lunak tidak boros dalam menggunakan sumber daya sistem seperti memory & processor eye cathcing user interface : Mempunyai antarmuka yg menarik long life time : Mempunyai siklus hidup yang cukup lama Mempunyai kinerja sesuai fungsi yang dibutuhkan pemakai
Jenis-jenis aplikasi Perangkat Lunak Perangkat Lunak Sistem (System software) Adalah sekumpulan program yang ditulis untuk melayani atau menunjang program lainnya. Misalnya : compiler, editor, komponen-komponen sistem operasi, driver dan prosesor telekomunikasi.
Perangkat lunak waktu nyata (Realtime Software) Perangkat lunak yang berfungsi untuk memonitor, menganalisis, mengontrol dan memberikan laporan tentang kejadian dunia nyata dan meresponnya dalam waktu kurang dari 1 menit. Misal: pengontrol arus udara, pengontrol keasaman tabung reaksi (pressman punya), pengontrol reaksi nuklir, dll
Jenis-jenis aplikasi Perangkat Lunak (2) Perangkat Lunak Teknik Dan (Scientific & Engineering Software)
Ilmu
Pengetahuan
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
Jenis-jenis aplikasi Perangkat Lunak (3) Perangkat Lunak Pengolah Data (Data Processing) Perangkat lunak yg khusus digunakan untuk mengolah data dan menghasilkan suatu keputusan tertentu. Misal: billing telepon, pengolah statistik Perangkat System)
Lunak Sistem Informasi (Information
Perangkat lunak yg mampu memberi informasi dari suatu sistem secara lebih detail. Misal: web site, perpustakaan digital, dll
Jenis-jenis aplikasi Perangkat Lunak (4) Perangkat Lunak Sensor Perangkat lunak yg mampu mengukur dan mengatur suatu keadaan khusus, kadang digolongkan dalam embedded system juga. Misal: pengatur cuaca, pengatur suhu ruangan, dll Perangkat Software)
Lunak Komunikasi (Communicaion
Perangkat lunak yg berfungsi untuk menghubungkan atau mengkomunikasikan suatu objek satu dengan lainnya. Misal: router, handphone, dll
Jenis-jenis aplikasi Perangkat Lunak (5) Perangkat Lunak Pengolah Grafis Perangkat lunak yang digunakan untuk melakukan perancangan grafis Misal: pembuatan film, pembuatan poster Perangkat Lunak Kecerdasan Perangkat lunak yg menggunakan algoritma no-numeris untuk memecahkan masalah kompleks yg tdk sesuai untuk perhitungan atau analisis secara langsung Misal: sistem pakar, pembuktian teorema, game strategi, jaringan saraf tiruan, dll
Evolusi Perangkat Lunak Perangkat lunak telah semakin berkembang sejak pertama kali
diciptakan tahun 1945 Fokus utama pembuatannya untuk mengembangkan praktik dan teknologi dalam meningkatkan produktivitas para praktisi pengembang PL dan kualitas aplikasi yg dapat digunakan oleh pemakai Evolusi dipicu adanya tuntutan bisnis dan lingkungan kerja yang berkembang sangat dinamis
Evolusi Perangkat Lunak (2) Era I (1945 – 1960): Munculnya teknologi perangkat keras di tahap awal Penggunaan perangkat lunak yg berorientasi batch Distribusi perangkat lunak masih terbatas Didominasi perangkat lunak model custome Munculnya istilah software engineering (akhir 1950an/awal 1960-an) Belum didefinisikan secara jelas tentang aspek– software engineering Evolusi Perangkat Lunak (3)
Era II (1960 – 1970) Disebut era krisis perangkat lunak (software crisis). Penggunaan perangkat lunak sudah meluas Telah hadir perusahaan yang membangun software (software house) Perangkat lunak sdh mengenal multiprogram, multiuser, real-time, dan penggunaan database. Evolusi Perangkat Lunak (4) Era II (Lanjutan) Banyak project PL yg gagal Over
budget/anggaran Berakibat rusak fisik dan kematian Meledaknya Roket Ariane , kesalahan perintah dlm PL Dua konferensi ttg software engineering: Disponsori Komite Sains NATO Tahun 1968 dan 1969 Profesi resmi bidang software engineering
Evolusi Perangkat Lunak (5) Era III (1975 – 1985) Pengembangan sistem mengarah ke konsep sistem terdistribusi. Penerapan sistem embeded intelligence Harga perangkat keras sudah jauh lebih murah sehingga pemakaian meluas Pemanfaatan jaringan global dan lokal serta sudah diperkenalkan komunikasi digital
Evolusi Perangkat Lunak (6) Era IV (1985 – 2000) Kemampuan PC sudah setara dengan komputer mainframe Penerapan teknologi yang berorientasi pada objek Implementasi sistem pakar Jaringan saraf tiruan Komputasi paralel Jaringan komputer sudah semakin canggih Evolusi Perangkat Lunak (7) Era V (2000 – sekarang) Penggunaan media digital Media web berkembang pesat Wireless sudah meluas Teknologi meluas hingga di mobile computing, mobile programming Perangkat keras sudah semakin kecil namun powerfull Dilakukan berbagai
Krisis Perangkat Lunak Masalah yang muncul: Estimasi jadwal dan biaya yang seringkali tidak tepat Produktivitas orang-orang software yang tidak dapat mengimbangi permintaan software Kualitas software yang kurang baik. Kurangnya pengetahuan tentang: Bagaimana
mengembangkan software Bagaimana memelihara software berkembang dalam jumlah besar yang
ada, yang
Bagaimana mengimbangi permintaan software yang makin besar.
Mitos Dalam Perangkat Lunak (Management) Mitos1: Kita tidak perlu mengubah pendekatan terhadap pengembangan software, karena jenis pemrograman yang kita lakukan sekarang ini sudah kita lakukan 10 tahun yang lalu. Realitasnya : Walau hasil program sama, produktivitas dan
kualitas software harus ditingkatkan dengan menggunakan pendekatan software developments Mitos Dalam Perangkat Lunak (Management) (2) Mitos2: Kita sudah mempunyai buku yang berisi standarisasi dan prosedur untuk pembentukan software. Realitasnya : Memang buku
tersebut ada, tetapi apakah buku tersebut sudah dibaca atau buku tersebut sudah ketinggalan jaman ( out of date ). Mitos3: Jika kita tertinggal dari jadwal yang ditetapkan, kita menambah beberapa programmer saja. Konsep ini sering disebut Mongolian harde concept.
Mitos dalam perangkat lunak (Customer) Mitos1: Pernyataan tujuan umum sudah cukup untuk memulai penulisan program. Penjelasan yang lebih rinci akan menyusul kemudian. Realitasnya : Definisi awal yang buruk adalah penyebab utama kegagalan terhadap usaha-usaha pem-bentukkan software. Penjelasan yang formal dan terinci tentang informasi fungsi performance interface, hambatan desain dan kriteria validasi adalah penting. Karakteristik di atas dapat ditentukan hanya setelah adanya komunikasi antara customer dan developer.
Mitos dalam perangkat lunak (Customer) Mitos2: Kebutuhan proyek yang terus menerus
berubah dapat dengan mudah diatasi karena software itu bersifat fleksibel. Realitasnya : memang benar bahwa kebutuhan software berubah, tetapi dampak dari peru-bahan berbeda dari waktu ke waktu.
Mitos Dalam Perangkat Lunak (Praktisi)
Mitos1: Tidak ada metode untuk analisis disain dan testing terhadap suatu pekerjaan, cukup menuju ke depan terminal dan mulai coding. Realitasnya : Metode untuk analisis desain dan testing
diperlukan dalam pengembangan software. Mitos2: Segera setelah software digunakan, pemeliharaan dapat diminimalisasikan dan diatasi dengan cara “CATCH AS CATCH CAM”. Realitasnya : Diperlukan budget yang besar dalam maintenance software. Pemeliharaan software harus diorganisir, direncanakan dan dikontrol seolah-olah sebagai suatu proyek besar dalam sebuah organisasi.
berubah dapat dengan mudah diatasi karena software itu bersifat fleksibel. Realitasnya : memang benar bahwa kebutuhan software berubah, tetapi dampak dari peru-bahan berbeda dari waktu ke waktu.
Definisi Rekayasa Perangkat Lunak (RPL) RPL atau Software Engineering (SE) Disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal spesifikasi sistem sampai pemeliharaan sistem setelah digunakan. Perangkat Lunak yang dibuat harus mampu: Tepat waktu Tepat anggaran Meningkatkan kinerja Mengoperasikan prosedur sistem dengan benar
Definisi Rekayasa Perangkat Lunak (Lanjutan) Ada 2 istilah kunci : 1. “disiplin rekayasa” Perekayasa membuat suatu alat bekerja. Menerapkan teori, metode, dan alat bantu yang sesuai, selain itu mereka menggunakannya dengan selektif dan selalu mencoba mencari solusi terhadap permasalahan. 2. “semua aspek produksi perangkat lunak” RPL tidak hanya berhubungan dengan proses teknis dari pengembangan perangkat lunak tetapi juga dengan kegiatan seperti Manajemen proyek PL dan pengembangan alat bantu, metode, dan teori untuk mendukung produksi PL.
Perbedaan RPL dengan Computer science
• 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
Perbedaan RPL dengan Rekayasa Sistem (RS)? Rekayasa Sistem (RS) berkaitan dengan semua aspek dalam pembangunan sistem berbasis komputer termasuk hardware, rekayasa PL dan proses. RPL adalah bagian dari rekayasa sistem yang meliputi pembangunan PL, infrasktruktur, kontrol, aplikasi dan database pada sistem.
Tantangan dalam Rekayasa Perangkat Lunak Tantangan warisan Dikembangkan bertahun-tahun dengan orang-orang yang berbeda-beda Tantangan heterogensis Dalam hal distribusi & teknologi Tantangan pengiriman Bagaimana mengirim sistem yang besar dan kompleks cepat dan dengan kualitas tetap terjaga.
Pelaku Dalam RPL 1. 2. 3. 4.
Manajer Manajer proyek Manajer konfigurasi Manajer penjamin kulitas PL Manajer bidang lainnya (sesuai kebutuhan
1. 2. 3. 4. 5.
Software Developer Analis sitem Desainer Programmer Inspektor PL Pengontrol perubahan Pelaku Dalam RPL (Lanjutan) 1. 2. 3. 4. 5.
Pendukung Staf administrasi Humas Pencatat teknis Administrator database Administrator jaringan Pertemuan 2 SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
POKOK BAHASAN Biaya PL Software Quality Attribute Standar kualitas Takaran Jaminan Kualitas CASE TOOLS Siklus Hidup Perangkat Lunak (SWDLC/Software Development Life Cycle)
BIAYA PERANGKAT LUNAK (SOFTWARE COST) Terkadang mendominasi biaya sistem secara keseluruhan Biaya terbesar untuk perangkat lunak terletak pada proses perawatan (maintenance) dibanding biaya pembuatannya (develop) Biaya pengadaan perangkat lunak yang di pasang pada PC sering lebih besar dibandingkan dengan harga perangkat kerasnya kec. Di negara-negara yang tidak menghargai HAKI Biaya perangkat lunak secara kasar sebesar 60% dari biaya untuk
pembangunan dan 40% untuk pengujian Secara umum besarnya biaya bervariasi tergantung pada tipe sistem yang dibangun dan kebutuhan sistem seperti kinerja dan kehandalan sistem Biaya distribusi tergantung pada model pembangunan yang digunakan
SOFTWARE QUALITY ATTRIBUTE (1) Ciri-ciri kualitas menurut lembaga penjamin mutu PL (ISO, ANSI, IEEE, dll): Correctness (kebenaran) Kesesuaian antara kode program dg spesifikasi Kebebasan aplikasi aktual pada sistem PL Reliability (tahan uji) Didasari pada (ketersediaannya) correctness
dan
availability
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.
SOFTWARE QUALITY ATTRIBUTE (2) User Friendliness (mudah digunakan) Adequacy
(kecukupan) Learnability (mudah dipelajari) Robustness (antisipasi kesalahan) Maintenatibility (mudah dirawat) Readability (mudah dibaca) Extensibility (mudah diperluas) Testability
(mudah untuk diuji/ditelusuri) Efficiency (efisiensi) Portability (mudah didistribusikan) UKURAN JAMINAN KUALITAS (1) Ukuran membangun (constructive measures) Aplikasi yg konsisten pada metode di seluruh fase proses pembangunan Penggunaan perlatan/ tools yang memadai Pembangunan PL pd basis kualitas yg tinggi di akhir tahapan Perawatan yang konsisten pada dokumenasi pengembangan Ukuran analitik (analytical measures) Analisis program yang statis Analisis program yang dinamis Pemeilihan test case yang sistematis Pencatatan yang konsisten pada analisis produk
UKURAN JAMINAN KUALITAS (2) Ukuran Organisasi (Organization Measures) Pengalaman pengembang (developer) dalam mempelajari strategi dan teknik yang tepat dalam membangun PL KRISIS PERANGKAT LUNAK Masalah yang muncul: Estimasi jadwal dan biaya yang seringkali tidak tepat Produktivitas orang-orang software yang tidak dapat mengimbangi permintaan software Kualitas software yang kurang baik. Kurangnya pengetahuan tentang: Bagaimana mengembangkan software Bagaimana memelihara software yang ada, yang berkembang dalam jumlah besar Bagaimana mengimbangi permintaan software yang makin besar.
KODE ETIK PROFESI Konfidensialitas (menghormati klien) Tidak boleh menerima pekerjaan di luar kompetensinya Hak kekayaan intelektual (HaKI) Penyalahgunaan komputer, hack, crack, KODE ETIK INTERNASIONAL Digagas oleh masyarakat profesional di Amerika (1999) yang tergabung dalam ACM/IEEE Makna yang terkandung: Prinsip-prinsip kesepakatan yang dihubungkan dengan tingkah laku dan keputusan yang dibuat oleh para ahli profesional
Masyarakat dan kepentingannya Klien dan atasan (pelayanan terbaik) Produk (jaminan mutu) Manajemen Profesi Kolega Diri sendiri (ada usaha untuk mengupdate ipteknya)
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)
CASE TOOLS (2) Penggunaan CASE tools: Graphical Editors Digunakan untuk membuat model sistem Data Dictionaries Digunakan untuk mengatur unit-unit proyek GUI Builders Digunakan untuk mengkonstruksi antarmuka pemakai Debugger Digunakan untuk mencari kesalahan yg mungkin terjadi Automated Translators Digunakan untuk pembangkitan source code program otomatis Compilator Integrated Digunakan membuat antarmuka, koding, hingga membentuk aplikasi yg bisa dijalankan Instalator Kit Digunakan untuk membuat file instalasi/setup
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) Proses Generik Spesifikasi Apa yang harus dilakukan oleh perangkat lunak dan batasan/kendala pengembangannya Pengembangan Proses memproduksi sistem perangkat lunak Validasi Pengujian perangkat lunak terhadap keinginan pengguna Evolusi Perubahan perangkat lunak berdasarkan perubahan keinginan.
MODEL PROSES RPL
Model Waterfall, Model Prototyping, Model Evolutionary Model Spiral Reuse Based Development WATERFALL MODEL Requirement Definitions
Pemodelan Sistem/ Informasi System and software design Implementation and unit testing Integr ation and system testing Operation and maintenance
WATERFALL MODEL (2) Requirements Analysis And Definition Pembentukan kebutuhan System And Software Design Mengubah kebutuhan-kebutuhan menjadi karakteristik yang dimerngerti perangkat lunak Implementation And Unit Testing Penulisan program Integration And System Testing Memeriksa program, mencari kesalahan Operation And Maintenance Pemeliharaan sistem, menambahkan fungsi
bentuk
WATERFALL MODEL (3) Problems Model Waterfall 1. Jarang sekali proyek yang prosesnya bisa dilakukan secara sequencial. 2. Sukar bagi customer untuk secara mengemukakan semua kebutuhannya.
explisit
3. Customer harus sabar. 4. Developer sering menunda pekerjaan. Anggota tim harus menunggu anggota lainnya 5. menyelesaikan tugasnya.
PROTOTYPE MODEL Membangun Konstruksi (prototipe) Mendengarkan Pelanggan
Uji Pelanggan (evaluasi)
PROTOTYPE MODEL (2) Prototype Paradigm dimulai dengan mengumpulkan kebutuhan-kebutuhan customer. Developer dan customer bertemu dan mendefinisikan obyektif software secara menyeluruh, mengidentifikasi kebutuhan-kebutuhan yang diketahui dari area pekerjaan. Setelah itu dibuat Quick Design. Quick Design difokuskan pada representasi aspek software yang bisa dilihat customer/user (misal: format input dan output). Quick Design cenderung ke pembuatan prototipe. Prototipe dievaluasi customer/user dan digunakan untuk menyempurnakan kebutuhan software yang akan dikembangkan.
PROTOTYPE MODEL (2) Sering terjadi customer menjabarkan objektif umum mengenai software yang diminta, tetapi tidak bisa mendefinisakan input, proses, output yang diminta secara detail. Disisi lain, developer menjadi tidak yakin terhadap efisiensi algoritma, kemampuan adaptasi terhadap sistem operasi, atau bentuk interaksi mesin dengan orang. Untuk mengatasi situasi tersebut, bisa digunakan pendekatan Prototype Paradigm.
PROTOTYPE MODEL (3) Problems Prototyping Model Customer melihat prototipe tersebut sebagai versi dari software. Pada saat produk tersebut harus dibangun ulang supaya level kualitas bisa terjamin, Customer akan mengeluh dan meminta sedikit perubahan saja supaya prototipe tersebut bisa berjalan. Development membuat implemetasi yang kompromitas dengan tujuan untuk
memperoleh prototipe pekerjaan secara cepat. Dampaknya adalah sistem operasi atau bahasa pemrograman yang dipergunakan tidak tepat, algoritma tidak efisien.
EVOLUTIONARY MODEL
EVOLUTIONARY MODEL INCREMENTAL (2) Penjelasan : 1. Kombinasikan elemet-element dari waterfall dengan sifat iterasi/perulangan. 2. Element-element dalam waterfall hasil berupa produk dengan
dikerjakan dengan
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.
EVOLUTIONARY MODEL INCREMENTAL (3) 5. Produk hasil increment pertama biasanya produk inti (core product), yaitu produk yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh pengguna atau menjalani review/ pengecekan detil. Hasil review tersebut menjadi bekal untuk pembangunan pada increment berikutnya. Hal ini terus dikerjakan sampai produk yang komplit dihasilkan. 6. Model ini cocok jika jumlah anggota tim pengembang/pembangun PL tidak cukup. 7. Mampu mengakomodasi perubahan secara fleksibel. 8. Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk yang sudah bisa berfungsi dengan spesifikasi dasar. EVOLUTIONARY MODEL INCREMENTAL (4) Kekurangan Incremental Model: Hanya cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding) Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masingmasing hasil increment EVOLUTIONARY MODEL SPIRAL
EVOLUTIONARY MODEL SPIRAL (2) Penjelasan : Customer Comunication Membangun
komunikasi yang baik dengan pelanggan Planning Mendefinisikan sumber, batas waktu, informasi-informasi lain seputar proyek Risk Analyst Identifikasi resiko management dan teknis
Engineering Pembangunan contoh-contoh aplikasi misalnya prototype Construction and release Pembangunan, test, install dan report Customer Evaluation Mendapatkan feedback dari pengguna berdasarkan evaluasi pada fase engineering dan fase instalasi
EVOLUTIONARY MODEL SPIRAL (3) Pada model spiral, resiko sangat dipertimbangkan. Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan. Model spiral merupakan pendekatan yang realistik untuk Perangkat Lunak berskala besar. Pengguna dan pembangun bisa memahami dengan baik software yang dibangun karena setiap kemajuan yang dicapai selama proses dapat diamati dengan baik. Namun demikian, waktu yang cukup panjang mungkin bukan pilihan bagi pengguna, karena waktu yang lama sama dengan biaya yang lebih besar.
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
REUSE BASED (2) Software Re-engineering (lanjutan) Mengapa? Mengurangi resiko SW yang baru dibangun membawa resiko yg tinggi Mengurangi biaya Biaya untuk re-engineering sering lebih kecil dibanding membangun SW baru.
REUSE BASED (3)
REUSE BASED (3) B. Reverse Engineering Analisis SW kembali dalam tahap pemahaman dlm desain dan spesifikasinya Bisa sebagian proses re-engineering atau sebagian spesifikasi sistem untuk diimplementasi ulang Membangun database dan bangkitkan program informasi dari proses ini Mengapa? Kode aslinya telah dalam keterbatasan dimana sudah terlalu lama, misal
kebutuhan memori, kinerja, dll Perawatan terbentur pada struktur dan program yang rusak sehingga membutuhkan kerja yg sangat keras Program secara otomatis distrukturisasi ulang untuk menghilangkan beberapa bagian yang tidak beres dalam kondisi yang sangat kompleks. Pertemuan 3 Manajemen Proyek Perangkat Lunak
Proses Dalam Manajemen PL Manajemen proyek merupakan lapisan pertama dalam proses rekayasa perangkat lunak skala besar. Untuk menuju pada proyek yang berhasil, perlu dimengerti tentang : Lingkup pekerjaan Resiko yang dapat ditimbulkan Sumber-sumber yang diperlukan Tugas yang harus dilaksanakan Patokan yang harus diikuti Usaha atau biaya yang dikeluarkan Dan
Penjadwalan
Langkah Awal dalam Manajemen Perangkat Lunak Untuk mengestimasi
biaya, pembagian tugas,
penjadwalan, sebelum sebuah proyek direncanakan : Memastikan tujuan dan ruang lingkup Memperhatikan alternatif-alternatif solusi Identifikasi batasan teknik dan manajerial dan
Fokus Manajemen Proyek Manajemen proyek terfokus pada 4P, yaitu : 1. People Elemen terpenting dalam keberhasilan suatu proyek 2. Product Perangkat lunak yang dihasilkan 3. Process Sekelompok aktivitas kerangka kerja dalam merekayasa perangkat lunak 4. Project Seluruh proses yang
dibutuhkan untuk menghasilkan suatu produk
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
Fokus Dalam RPL Analisa Resiko Estimasi Biaya Penjadwalan Manajemen proyek
Pengecekan Kualitas hasil terkait dengan kualitas yang diinginkan bersama Manajemen Sumber Daya Manusia
Pengukuran Perangkat Lunak Pengukuran dan satuan ukuran akan membantu untuk mengerti proses-proses dalam pengembangan dan produk itu sendiri. Proses dan produk diukur untuk meningkatkan kualitasnya.
usaha
Pengukuran Perangkat Lunak (2) 1. Pengukuran Langsung Terkait dengan biaya dan usaha yang diaplikasikan, misalnyayang menyangkut deretan kode program, kecepatan eksekusi, ukuran memori yang dibutuhkan dan cacat pada produk, yang dilaporkan pada sejumlah periode waktu 2. Pengukuran tidak Langsung Terkait dengan fungsionalitas, kualitas, kompleksitas, efisiensi, reabilitas, kemampuan pemeliharaan dan lainlain
Pengukuran Perangkat Lunak (3) Mengapa perangkat Lunak Harus Diukur?? 1. Untuk mengetahui karakteristik Perangkat Lunak 2. Proses evaluasi Perangkat Lunak 3. Prediksi kebutuhan Perangkat Lunak 4. Pengembangan Perangkat Lunak
Pengukuran Perangkat Lunak (4) Kualitas Pengukuran Perangkat Lunak : Correctness Sesuai dengan spesifikasi yang diinginkan Maintability Kemudahan pemeliharaan dan stabil Integrity Daya tahan terhadap serangan dari luar sistem Usability Kemudahan dalam penggunaan (user-friendly)
Estimasi Dalam aktifitas dilakukan: utama
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
Pengendalian Resiko (2) 2.
Manajemen Resiko Proaktif Kinerja analisis resiko secara formal Koreksi terorganisasi pada penyebab resiko Pengujian sumber resiko yang diantaranya adalah perangkat lunak Pengembangan kemampuan untuk mengatur perubahan
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
ketergantungan tugas 2. Money Anggaran Belanja, sumber daya 3. Scope Ruang lingkup pekerjaan
durasi,
Perencanaan Proyek (3) Strategi Perencanaan memilih dan menerapkannya Hasil tujuan Asumsi/anggapan Pembatasan Area/cakupan berhubungan dengan tugas dan pengiriman Tahapan perencaan Proyek Penentuan area/cakupan proyek Pendefinisian tugas-tugas, teknik/tools (WBS, project Network Diagram) Pendefinisian sumber daya Penjadwalan teknik/tools : PERT, CPM, Gantt Chart Penentuan Anggaran
Perencanaan Proyek (4) Tools dan Teknik Manajemen Proyek Work Breakdown Structure Project Network Diagram Critical Path Method (CPM) Program Evaluation and Review Technique
(PERT) Gantt Chart Precedence Diagramming Method (PDM)
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
Penelusuran dan Pengendalian Penelusuran dan
pengendalian dilakukan
setelah ada penjadwalan yang pasti, yaitu memeriksa apakah tugas telah dilaksanakan sesuai dengan jadwal.
Tujuan Pengukuran Perangkat Lunak Indikasi kualitas produk Perkiraan produktivitas menghasilkan produk
orang-orang yang
Perkiraan manfaat dari penerapan metode dan tools Membentuk dasar dari estimasi Menegaskan (Justify) permintaan tools baru dan pelatihan
Ukuran Kualitas Perangkat Lunak Kualitas perangkat lunak dihitung pada saat proses rekayasa perangkat lunak ataupun setelah diserahkan kepada pemakai. Satuan ukuran kualitas perangkat lunak pada saat proses rekayasa : 1. Kompleksitas program 2. Modularitas yang efektif 3. Besarnya program
Penyebab Kegagalan (PL) Penyebab kegagalan sebuah proyek PL : Batas waktu pengerjaan proyek yang tidak realistis Perubahan keinginan pelanggan Meremehkan pekerjaan Munculnya resiko yang dapat diperkirakan dan resiko yang diluar perkiraan Kesulitan secara teknis
Kesalahpahaman antara anggota tim proyek Kesalahan dalam manajemen proyek
penting dalam proyek Manager (Teknis) Proyek Merencanakan, memotivasi, mengorganisir mengontrol proyek sebuah produk / aplikasi
dan
Pelaksana Yang menyampaikan keterampilan teknik yang diperlukan untuk merekayasa sebuah produk / aplikasi
Komponen Dalam Proyek PL (2) Pelanggan Menentukan jenis kebutuhan akan perangkat lunak yang akan direkayasa Pemakai Akhir (end-user) Yang berinteraksi dengan perangkat lunak bila perangkat lunak telah dipublikasikan (release) untuk digunakan
Komponen Dalam Proyek PL (3) Faktor yang harus dipertimbangkan dalam menyeleksi tim
pelaksana proyek 1. Tingkat kesulitan dari masalah yang akan dikerjakan 2. Ukuran program yang dihasilkan yang terkait dengan jumlah fungsi yang digunakan 3. Waktu yang dibutuhkan oleh tim untuk bekerja secara bersama-sama 4. Tingkatan dimana masalah dapat dimodularisasi / dibuat dalam bentuk modul
Komponen Dalam Proyek PL (4) 5. Kualitas yang diperlukan serta keandalan sistem yang dibangun 6. Kepastian tanggal penyampaian ke pelanggan 7. Memiliki kemampuan sosialisasi (komunikasi) yang dibutuhkan dalam proyek
Definisi Masalah dalam RPL 1. Menetapkan Ruang Lingkup Permasalahan : Konteks Bagaimana software yang akan dibangun nantinya dapat memenuhi kebutuhan sistem serta batasan yang ditentukan oleh sistem Tujuan Informasi Menentukan objek data yang dihasilkan sebagai output dan object data yang diperlukan sebagai input Fungsi dan Unjuk Kerja Menentukan fungsi yang akan dilakukan untuk mentransformasi input data menjadi output serta ciri kerja khusus yang akan ditekankan
Definisi Masalah dalam RPL (2) 2. Dekomposisi masalah Menetapkan pembagian fungsi / aktivitas kerja pada 2 area utama, yaitu ; Fungsionalitas yang harus disampaikan Proses yang akan dipakai untuk menyampaikannya
ARTIFACT UML Use-Case Diagram Class Diagram
State Diagram
Document add( ) delete( )
name : int docid : int numField : int get( ) open( ) close( ) read( ) sortFileList( ) create( ) fillDocument( )
FileList Use Case 1
fList add( ) delete( ) Actor A
Writing
add file [ numberOffile==MAX ] / flag OFF read() fill the code..
Openning close file 1
Actor B close file Reading Closing
rep
Use Case 2 File
Repository (from Persistence) read( )
<> Customer name addr receive() withdraw() fetch() send() GrpFile name : char * = 0 Domain Expert add file DocumentList FileMgr fetchDoc( ) sortByName( ) read( ) open( ) create( ) fillFile( ) readDoc( ) readFile( )
Use Case 3
Deployment Diagram UI
MFC DocumentApp ºÐ»ê ȯ °æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬° á ¸ðµ¨ - À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ® À©µµ¿ì NT: ÀÀ¿ë¼¹ö À¯ ´Ð½º ¸Ó½Å: ÀÀ¿ë ¼¹ö ¹× µ¥ÀÌŸ ¼¹ö, Åë½Å ¼¹ö -IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼-¹ö, Åë½Å ¼-¹ö RogueWave Repository Persistence 9: sortByName ( ) DocumentList Windows95 Window95 Windows95 global ¹®¼-°ü¸® Ŭ¶óÀ̾ðÆ®.EXE FileManager ¹®¼-°ü¸® ¾ÖÇø´
mainWnd : MainWnd 1: Doc view request ( ) Windows NT L 2: fetchDoc( ) gFile : GrpFile 4: create ( ) 8: fillFile ( ) user : »ç¿ëÀÚ
User Interface Definition
fileMgr : FileMgr 3: create ( ) 6: fillDocument ( ) Package Diagram
Document Solaris
¹®¼-°ü¸® ¿£Áø.EXE
Alpha UNIX ÀÀ¿ë¼-¹ö.EXE Windows NT GraphicFile File
IBM Mainframe
FileList µ¥ÀÌŸº£À̽º¼-¹ö 7: readFile ( ) 5: readDoc ( )
document : Document repository : Repository Collaboration Diagram mainWnd user
Ư Á¤¹®¼-¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù. fileMgr : FileMgr document : Document gFile repository Component Diagram
Forward Engineering(Code Generation) and Reverse Engineering Source Code edit, compile, debug, link
1: Doc view request ( ) 2: fetchDoc( ) 3: create ( ) 4: create ( ) 5: readDoc ( ) È-ÀÏ°ü¸®ÀÚ´Â Àоî¿Â ¹®¼-ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼°´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù. 6: fillDocument ( ) 7: readFile ( ) 8: fillFile ( ) È-¸é °´Ã¼´Â ÀоîµéÀÎ °´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È-¸é¿¡ º¸¿©ÁØ´Ù.
9: sortByName ( )
Sequence Diagram Executable System DIAGRAM-DIAGRAM DI UML
Use Case Use Case Diagrams Activity Diagrams Diagrams Scenario Scenario Diagrams Sequence Diagrams Diagrams Scenario Scenario Diagrams Collaboration Diagrams Diagrams Use Case Use Case Diagrams Use Case Diagrams Diagrams State State Diagrams Class Diagrams Diagrams
Model
Deployment Diagram
State State Diagrams Object Diagrams Diagrams State State Diagrams State Diagrams Diagrams
Component Component Diagrams Component Diagrams Diagrams
USE CASE DIAGRAM • Menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. • Menggambarkan
kebutuhan system dari sudut pandang user • Mengfokuskan pada proses komputerisasi (automated processes) • Menggambarkan hubungan antara use case dan actor
• 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)
Deskripsi Use case Diagram Use case • Use case dibuat berdasar keperluan actor, merupakan “apa” yang dikerjakan system, bukan “bagaimana” system mengerjakannya • Use case diberi nama yang menyatakan apa hal yang dicapai dari hasil interaksinya dengan actor. • Use case dinotasikan dengan gambar (horizontal ellipse) • Use case biasanya menggunakan kata kerja • Nama use case boleh terdiri dari beberapa kata dan tidak boleh ada 2 use case yang memiliki nama yang sama Simbol use case
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
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
Association antara actor dan use case • Ujung panah pada association antara actor dan use case mengindikasikan siapa/apa yang meminta interaksi dan bukannya mengindikasikan aliran data • Sebaiknya gunakan Garis tanpa panah untuk association antara actor dan use case • association antara actor dan use case yang menggunakan panah terbuka untuk mengindikasikan bila actor berinteraksi secara pasif dengan system anda
Association antara use case • <> termasuk didalam use case lain (required) / (diharuskan) – Pemanggilan use case oleh use case lain, contohnya adalah pemanggilan sebuah fungsi program – Tanda panah terbuka harus terarah ke sub use case – Gambarkan association include secara horizontal <> Register for courses <> Logon validation
Maintain curriculum
Association antara use case (Lanjut) • <> perluasan dari use case lain jika kondisi atau syarat terpenuhi – Kurangi penggunaan association Extend ini, terlalu banyak pemakaian association ini membuat diagram sulit dipahami. – Tanda panah terbuka harus terarah ke parent/base use case – Gambarkan association extend secara vertical
Buka Rekening <> Nasabah Buka Deposito
Generalization/inheritance antara use case • Generalization/inheritance digambarkan dengan sebuah garis berpanah tertutup pada salah satu ujungnya yang menunjukkan lebih umum • Gambarkan generalization/inheritance antara use case secara vertical dengan inheriting use case dibawah base/parent use case • Generalization/inheritance dipakai ketika ada sebuah keadaan yang lain sendiri/perlakuan khusus (single condition) Buka Rekening
Nasabah Buka Deposito
Generalization/inheritance antara actor • Gambarkan generalization/inheritance antara actors secara vertical dengan inheriting actor dibawah base/parent use case
Use case System boundary boxes • Digambarkan dengan kotak disekitar use case, untuk
menggambarkan jangkauan system anda (scope of of your system). • Biasanya digunakan apabila memberikan beberapa alternative system yang dapat dijadikan pilihan • System boundary boxes dalam penggunaannya optional
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
CLASS DIAGRAM (LANJUTAN) • Atribut dan metoda dapat memiliki salah satu sifat berikut : – Private, tidak dapat dipanggil dari luar class yang bersangkutan – Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya – Public, dapat dipanggil oleh siapa saja – Package, hanya dapat dipanggil oleh instance sebuah class pada paket yang sama Nama Class Atribut Metode/operasi
HUBUNGAN ANTAR CLASS 1. Asosiasi, yaitu hubungan statis antar class. Umumnya
menggambarkan class yang memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah navigability menunjukkan arah query antar class. 2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”). 3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi. 4. Hubungan dinamis, yaitu rangkaian pesan
(message) yang di-passing dari satu class kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram yang akan dijelaskan kemudian.
CONTOH CLASS DIAGRAM
MULTIPLICITY • Unspecified • Exactly one • Zero or more (many, unlimited) 1 0..* *
• • • •
One or more Zero or one (optional scalar role) Specified range Multiple, disjoint ranges 1..* 0..1 2..4 2, 4..6
Class Diagram diperoleh berdasarkan dari database Contoh Kasus (Acknowledgments Evi Lutfi Muktar)
Contoh Kasus (Acknowledgments Toeko triyanto)
pelanggan_reg no int(5) nomor_pelanggan varchar(12) nama_lengkap varchar(20) username varchar(13) password varchar(13) email varchar(30)
1
i_01 nomor_agenda int(5) tgl_agenda varchar(15) nomor_pelanggan varchar(12) nama pelanggan varchar(20) alamat_pelanggan varchar (30) no_ktp varchar(19) no_telpon varchar(13) tarif_lama varchar(2) daya_lama varchar(6) n tarif_baru varchar(2) daya_baru varchar(6) peruntukan
varchar(20) gardu varchar(20) status varchar(1) 1
cari() simpan() batal() simpan() batal()
tunggakan nomor_pelanggan varchar(20) tanggal_rekening varchar(15) rupiah_ptl int(15)
tagihan_lain_lain int(15) ppn int(12) ppj int(15) materai int(7) total_tagihan int(15) tanggal_bayar varchar(15)
n 1 1 n
modul id_modul int(5) nama_modul varchar(50) link varchar(100) static_content text gambar varchar(100) publish enum('Y','N') status enum('user','admin','umum') aktif enum('Y','N') urutan int(5) simpan() batal()
1
user id_user varchar(50) password varchar(50) nama_lengkap varchar(100) email varchar(100) 1 bagian varchar(100) referensi varchar(100) level varchar(50)
master_tarif nomor int(5) peruntukan varchar(10) tarif varchar(2) daya varchar(10) bp int(10) ujl int(10) materai int(10)
simpan() batal()
keluhan_pelanggan id int(5) nomor_pelanggan varchar(12) nama_pelanggan varchar(20) email varchar(100) keluhan text kode_security varchar(6)
kwitansi n
n
master_pelanggan nomor_pelanggan varchar(12) nama_pelanggan varchar(20) penunjukan_alamat varchar (2) alamat_pelanggan varchar(18) nomor_bangunan varchar(3) nomor_rt int(3) nomor_rw int(2) golongan_tarif varchar(3) daya int(6) 1 nomor_meter varchar(6) nomor_ktp varchar(20) telpon varchar(13) gardu varchar(20)
nomor_kwitansi int(5) tgl_kwitansi varchar(15) nomor_agenda int(5) nomor_pelanggan varchar(12) bp int(10) ujl int(10) materai int(10) total int(10) status int(1) userid varchar(10)
simpan() n batal() tambahkwitansi() cari() 1 1 perintah_kerja nomor_pk int(5) tgl_pk varhcar(15) no_kwitansi int(5) tgl_kwitansi varchar(15) status int(1) cari() 1
1
1 mutasi nomor_mutasi int(5) tgl_mutasi varchar(15) nomor_pk int(5) tgl_pk varchar(15) status int(1) cari() 1
n
1 master_status nomor_status int(1) keterangan varchar(15) 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 Transition
Notasi State menggambarkan kondisi sebuahentitas, dan digambarkan dengan segiempat yang pinggirnya tumpul dengan nama state didalamnya
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 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 Final State
menggambarkan ketika objek berhenti memberi respon terhadap sebuah event. Final State digambarkan dengan lingkaran solid didalam sebuah lingkaran kosong.
Transition
• 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
State Machine Diagram (Statechart diagram in versi 1.x)
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
label on transition is in the format event [guard][/methode list()] • • • •
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.
Contoh State 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 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.
Contoh : Component Diagram Demo.html applet1.class applet1.java applet2.class applet2.java logo.gif
Contoh : Component & Deployment Diagram Contoh kasus (Acknowledgments Toeko triyanto) state chart diagram pendaftaran
pengisian data kirim
statechart diagram pengisian data kwitansi. isi ulang
pengisian data kirim
isi ulang
data masukan simpan
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
Simbol Activity Diagram Simbol
Keterangan Start Point End Point Activities Fork (Percabangan)
Join (Penggabungan) Decision
Swimlane
Sumber : Rational rose
Sebuah cara untuk mengelompokkan activity berdasarkan Actor (mengelompokkan activity dalam sebuah urutan yang sama)
CONTOH ACTIVITY DIAGRAM
Penarikan Uang dari Account Bank Melalui ATM CONTOH ACTIVITY DIAGRAM Bagian Gudang Memberi informasi data Barang yang akan dipesan Bagian Pembelian
Menerima informasi Buat SPP
Terima SPP
Kirim Barang disertai Faktur Terima Barang dan Faktur
Buat SPBJ Supplier Tandatangani SPBJ Melakukan pembayaran Terima SPBJ 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
Acivity Diagram Rekap Biodata Pegawai (RBP)
Activity Diagram Pembuatan Daftar Data pegawai dan Gaji (DDPG) Activity Diagram Proses Laporan
(Acknowledgments Toeko triyanto)
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
Activity diagram pendaftaran perubahan daya pelanggan
pelayanan pelanggan
memberikan fotocopy ktp dan rekening listrik menerima fotocopy ktp dan rekening listrik spv pelayanan
input pendaftaran pelanggan cetak formulir pendaftaran menerima formulir pendaftaran memberikan formulir pendaftaran menyetujui formulir pendaftaran memberikan formulir pendaftaran menerima formulir pendaftaran memberikan formulir pendaftaran menerima formulir pendaftaran
• 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. pelayanan pelanggan
memberikan formulir pendaftaran spv pelayanan
pelanggan
menerima formulir pendaftaran membuat surat persetujuan menyetujui surat persetujuan memberikan surat persetujuan menerima surat persetujuan
• 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. pelanggan
menerima surat persetujuan spv pelayanan
manager
membuat surat perjanjian jual beli tenaga listrik mencetak surat perjanjian jual beli tenaga listrik m emberikan surat perjanjian jual beli tenaga listrik menerima surat perjanjian jual beli tenaga listrik menyetujui surat perjanjian jual beli tenaga listrik menerima surat perjanjian jual beli tenaga listrik menerima surat perjanjian jual beli tenaga listrik memberikan surat perjanjian jual beli tenaga listrik menyetujui surat perjanjian jual beli tenaga listrik m emberikan surat perjanjian jual beli tenaga listrik m enerim a surat perjanjian jual beli tenaga listrik memberikan surat perjanjian jual beli tenaga listrik
• 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. pelanggan
melakukan pembayaran loket PTPLN
menerima pembayaran cetak bukti pembayaran menyetujui bukti pembayaran menerima bukti pembayaran memberikan bukti pembayaran
• 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. bagian penyam bungan
pelaksana pelanggan
cetak perintah kerja m enyetujui perintah kerja m elakukan penggantian MCB menerim a perintah kerja melakukan penggantian MCB memberikan perintah kerja m enerima perintah kerja menyetujui perintah kerja menerima perintah kerja menerim a perintah kerja memberikan perintah kerja memberikan perintah kerja
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.
Latihan Activity Diagram ! PT. Nusantara adalah sebuah perusahaan yang bergerak dibidang penjualan Tunai barang-barang elektronik. Semua transaksi di perusahaan masih dilakukan secara manual. Berikut ini adalah kegiatan kegiatan yang dilakukan oleh bagian Penjualan dalam
melaksanakan transaksi penjualan Barang di dalam perusahaan. 1. Pemesanan barang Setiap kali Bagian penjualan akan menjual barang ia selalu menerima surat pesanan dari pelanggan.
Berdasarkan Surat pesanan tersebut bagian penjualan kemudian mencatat dan merekamnya kedalam Arsip Surat Pesanan. Berdasarkan Arsip surat pesanan tersebut, bagian penjualan
membuatkan Faktur dan Surat Jalan yang dikirimkan kepada Pelanggan sebagai bukti bahwa barang yang dipesan sudah terealisasi dan rangkapnya disimpan sebagai Arsip Faktur dan Arsip Surat Jalan. 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
Simbol Sequence Diagram Contoh Sequence Diagram Contoh kasus Penggajian
(Acknowledgments Evi Lutfi Muktar)
SEQUENCE DIAGRAM INPUT DATA PENDIDIKAN SEQUENCE DIAGRAM INPUT DATA KELUARGA SEQUENCE DIAGRAM ABSEN MASUK
Contoh kasus PLN (Acknowledgments Toeko triyanto) : administrator
: formtambah manajemen user : control formtambah manajemen user open ( ) get username, password nama lengkap, email
display username, password nama lengkap, email simpan simpan
: pelanggan
: pelanggan open ( ) : formtambah pendaftaran
: controlform tambah pendaftaran : pelanggan1
get nomor_pelanggan peruntukan, tarif, daya
display nomor_pelanggan nama pelanggan alamat nomor ktp nomor telpon gardu daya tarif lama daya tarif baru peruntukan simpan simpan
display no, agenda, tgl, id_pelanggan nama, daya_lama daya_baru, status, aksi
• 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.
Contoh Collaboration Diagram
Berikut adalah sebuah contoh collaboration diagram yang mengilustrasikan sebuah sistem telepon genggam (handphone) :
Collaboration Diagram (Acknowledgments Toeko triyanto) : sim pan : tam bah data : cari
: pengunjung : register : index\home : pendaftaran : batal : sim pan : cetak
: sim pan : m em ber
: index\hom e : m anajemen kontrol : tambah modul : batal
: batal : login
: m anajem en modul : logout
: hapus
: batal : update
: login1 : edit : brow se : batal
: profile : sim pan : update : tam bah user : cetak
: cari
: m anajemen user : batal : tam bah data
: pendaftaran : hapus : sim pan : update : cari
: cari : batal
: edit : cetak dokum en : batal : cetak : login1
: tam bah kw itansi : index\hom e : batal
: cari : admin : cetak
: login : perintah kerja1 : batal : cetak : cari : sim pan
: guestbook1
: tam bah guestbook : data pelanggan1
: m anajem en kontrol1 : mutasi1 : perem ajaan : batal : edit : hapus : informasi tagihan1 : cari : batal : cari : cari : sim pan : batal
: cari
: cetak dokum en : tam bah kw itansi : sim pan
: kw itansi1 : batal : cetak : index\hom e : user
: cari : sim pan
: perintah kerja1 : tambah guestbook : guestbook1
: inform asi tagihan1 : cetak : m utasi1 : data pelanggan1 : cari : batal : cari : edit : hapus : cari : simpan : sim pan : kw itansi1 : batal : batal : peremajaan
PERTEMUAN 6 COMPONENT DIAGRAM 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 <>,kumpulan aplikasi system <>,component yang jalan di client <>, data file <> <>, technical component didalam system <> <>, source file <> <
