Pertemuan 1

PENGENALANPENGENALANREKAYASA PERANGKAT

LUNAK

Pokok Bahasan dalam RPL : RPL sebagai produk dan sebagai produk Konsep manajemen proyek Proses pembangunan PL dan metrik proyek Perencanaan proyek PL 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 Metode desain Implementasi pembangunan Teknik pengujian perangkat Strategi perancangan PL CASE tool pembangunan PL

Pressman, RS., 2008, Software Engineering: APractitioners Approach, New York: McGraw-Hill

Buku Referensi :

Sommerville, I, 2007, Software Engineering, AddsionWesley

Rekayasa Perangkat Lunak Perangkat Lunak? (Software??) Rekayasa Perangkat lunak-RPL? (Software engineering-SE??) Rekayasa sistem-RS? (system engineering-SyE??) Evolusi Perangkat Lunak 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 EngineeringTerminology, 1990:Computer programs, procedures, and possibly associateddocumentation and data pertaining to the operation of acomputer system.computer system.Maksudnya :Perangkat lunak merupakan kumpulan dari program, prosedur,dan dokumen data lain yang saling berhubungan yangmerepresentasikan masalah di dunia nyata yangdikonfigurasikan dalam sebuah bentuk aplikasi yang harusdikerjakan komputer

Produk Perangkat Lunak Perangkat lunak tidak sama dengan produk perangkat

keras Produk perangkat lunak dikembangkan (developed)

atau direkayasa (engineered). Sebagian besaratau direkayasa (engineered). Sebagian besardikembangkan atau dibangun berdasrkan pemesanandan sebagian kecil dibuat secara paket.

Tidak dipabrikkan seperti pabrik perangkat keras, misalkomputer, mobil.

Perangkat lunak secara pemakaian tidak pernah AUSlayaknya perangkat keras

Produk Perangkat Lunak (2) 2 Bentuk produk perangkat lunak:1. Produk Generik (Umum)

Sistem stand-alone standar yang diproduksi olehorganisasi pengembang dan dijual ke pasar terbuka keorganisasi pengembang dan dijual ke pasar terbuka kesiapapun yg membelinya. Biasa disebut sebagai softwareshrink-wrapped. Contoh : word processor, Database.

2. Produk pesanan (yang disesuaikan)Sistem yang dipesan oleh pelanggan tertentu.Dikembangkan khusus bagi pelanggan oleh kontraktorperangkat lunak. Contoh : Sistem untuk mendukungproses bisnis tertentu dan sistem kontrol lalu lintas udara

Produk Perangkat Lunak (3) Perbedaan PENTING antara 2 bentuk perangkat lunak :

Pada produk generik, organisasi yangmengembangkan perangkat lunak mengontrolspesifikasi perangkat lunak.

Pada produk pesanan, spesifikasi biasanyadikembangkan dan dikontrol oleh organisasi yangmembeli 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 sepertidalam menggunakan sumber daya sistem sepertimemory & processor

eye cathcing user interface : Mempunyai antarmuka ygmenarik

long life time : Mempunyai siklus hidup yang cukuplama

Mempunyai kinerja sesuai fungsi yang dibutuhkanpemakai

Jenis-jenis aplikasi Perangkat Lunak Perangkat Lunak Sistem (System software)

Adalah sekumpulan program yang ditulis untuk melayaniatau menunjang program lainnya.Misalnya : compiler, editor, komponen-komponen sistemoperasi, driver dan prosesor telekomunikasi.

Perangkat lunak waktu nyata (Realtime Software)Perangkat lunak yang berfungsi untuk memonitor,menganalisis, mengontrol dan memberikan laporan tentangkejadian dunia nyata dan meresponnya dalam waktukurang dari 1 menit.Misal: pengontrol arus udara, pengontrol keasaman tabungreaksi (pressman punya), pengontrol reaksi nuklir, dll

Jenis-jenis aplikasi Perangkat Lunak (2) Perangkat Lunak Teknik Dan Ilmu Pengetahuan

(Scientific & Engineering Software)Perangkat lunak yg menangani bidang teknik dan ilmupengetahuan secara rinciMisal: simulasi astronomi, vulkanologi, analisis otomatif,dinamika orbit pesawat ruang angkasa, biologi molekuler,dinamika orbit pesawat ruang angkasa, biologi molekuler,otomasi pabrik, dll

Embeded SystemPerangkat lunak yg ditempelkan/dilekatkan pada perangkatlainnya (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 mengolahdata dan menghasilkan suatu keputusan tertentu.Misal: billing telepon, pengolah statistikMisal: billing telepon, pengolah statistik

Perangkat Lunak Sistem Informasi (InformationSystem)Perangkat lunak yg mampu memberi informasi dari suatusistem secara lebih detail.Misal: web site, perpustakaan digital, dll

Jenis-jenis aplikasi Perangkat Lunak (4) Perangkat Lunak Sensor

Perangkat lunak yg mampu mengukur dan mengatursuatu keadaan khusus, kadang digolongkan dalamembedded system juga.Misal: pengatur cuaca, pengatur suhu ruangan, dll

Perangkat Lunak Komunikasi (CommunicaionSoftware)Perangkat lunak yg berfungsi untuk menghubungkan ataumengkomunikasikan suatu objek satu dengan lainnya.Misal: router, handphone, dll

Jenis-jenis aplikasi Perangkat Lunak (5) Perangkat Lunak Pengolah Grafis

Perangkat lunak yang digunakan untuk melakukanperancangan grafisMisal: pembuatan film, pembuatan posterMisal: pembuatan film, pembuatan poster

Perangkat Lunak KecerdasanPerangkat lunak yg menggunakan algoritma no-numerisuntuk memecahkan masalah kompleks yg tdk sesuaiuntuk perhitungan atau analisis secara langsungMisal: 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 produktivitaspara praktisi pengembang PL dan kualitas aplikasi ygpara praktisi pengembang PL dan kualitas aplikasi ygdapat digunakan oleh pemakai

Evolusi dipicu adanya tuntutan bisnis dan lingkungankerja 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 Distribusi perangkat lunak masih terbatas Didominasi perangkat lunak model custome Munculnya istilah software engineering (akhir 1950-

an/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 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 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 sistemterdistribusi.

Penerapan sistem embeded intelligence 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 komputermainframe

Penerapan teknologi yang berorientasi pada objek 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 Wireless sudah meluas Teknologi meluas hingga di mobile computing, mobile

programming Perangkat keras sudah semakin kecil namun powerfull Dilakukan berbagai penelitian yang menghasilkan

model proses/paradigma pengembangan PL utkmengatasi krisis 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.

Mitos1: Kita tidak perlu mengubah pendekatan terhadap

pengembangan software, karena jenis pemrogramanyang kita lakukan sekarang ini sudah kita lakukan 10

Mitos Dalam Perangkat Lunak (Management)

yang kita lakukan sekarang ini sudah kita lakukan 10tahun yang lalu.

Realitasnya : Walau hasil program sama, produktivitasdan kualitas software harus ditingkatkan denganmenggunakan pendekatan software developments

Mitos2: Kita sudah mempunyai buku yang berisi standarisasi dan

prosedur untuk pembentukan software. Realitasnya : Memang buku tersebut ada, tetapi apakah

Mitos Dalam Perangkat Lunak (Management) (2)

Realitasnya : Memang buku tersebut ada, tetapi apakahbuku tersebut sudah dibaca atau buku tersebut sudahketinggalan jaman ( out of date ).

Mitos3: Jika kita tertinggal dari jadwal yang ditetapkan, kita

menambah beberapa programmer saja. Konsep ini seringdisebut Mongolian harde concept.

Mitos1: Pernyataan tujuan umum sudah cukup untuk memulai

penulisan program. Penjelasan yang lebih rinci akanmenyusul kemudian.

Mitos dalam perangkat lunak (Customer)

menyusul kemudian. Realitasnya : Definisi awal yang buruk adalah penyebab

utama kegagalan terhadap usaha-usaha pem-bentukkansoftware. Penjelasan yang formal dan terinci tentanginformasi fungsi performance interface, hambatan desaindan kriteria validasi adalah penting. Karakteristik di atasdapat ditentukan hanya setelah adanya komunikasi antaracustomer dan developer.

Mitos2: Kebutuhan proyek yang terus menerus berubah dapat

dengan mudah diatasi karena software itu bersifatfleksibel.

Mitos dalam perangkat lunak (Customer)

fleksibel. Realitasnya : memang benar bahwa kebutuhan software

berubah, tetapi dampak dari peru-bahan berbeda dariwaktu ke waktu.

Mitos1: Tidak ada metode untuk analisis disain dan testing terhadap

suatu pekerjaan, cukup menuju ke depan terminal dan mulaicoding.

Realitasnya : Metode untuk analisis desain dan testingdiperlukan dalam pengembangan software.

Mitos Dalam Perangkat Lunak (Praktisi)

diperlukan dalam pengembangan software. Mitos2: Segera setelah software digunakan, pemeliharaan dapat

diminimalisasikan dan diatasi dengan cara CATCH AS CATCHCAM.

Realitasnya : Diperlukan budget yang besar dalam maintenancesoftware. Pemeliharaan software harus diorganisir, direncanakandan dikontrol seolah-olah sebagai suatu proyek besar dalamsebuah organisasi.

Mitos2: Kebutuhan proyek yang terus menerus berubah dapat

dengan mudah diatasi karena software itu bersifatfleksibel.

Realitasnya : memang benar bahwa kebutuhan software

Mitos dalam perangkat lunak (Management)

Realitasnya : memang benar bahwa kebutuhan softwareberubah, tetapi dampak dari peru-bahan berbeda dariwaktu ke waktu.

Definisi Rekayasa Perangkat Lunak (RPL)RPL atau Software Engineering (SE) Disiplin ilmu yangmembahas semua aspek produksi perangkat lunak, mulaidari tahap awal spesifikasi sistem sampai pemeliharaansistem setelah digunakan. Perangkat Lunak yang dibuatharus mampu: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 yangsesuai, selain itu mereka menggunakannya denganselektif dan selalu mencoba mencari solusi terhadapselektif dan selalu mencoba mencari solusi terhadappermasalahan.

2. semua aspek produksi perangkat lunak RPL tidakhanya berhubungan dengan proses teknis daripengembangan perangkat lunak tetapi juga dengankegiatan seperti Manajemen proyek PL danpengembangan alat bantu, metode, dan teori untukmendukung produksi PL.

Computer science lebih memperhatikan teori

& metode komputerisasi, sedangkan software

engineering menyangkut masalah praktikal

pembuatan dan delivery perangkat lunak

Perbedaan RPL dengan Computer science

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 aspekdalam pembangunan sistem berbasis komputertermasuk hardware, rekayasa PL dan proses.

RPL adalah bagian dari rekayasa sistem yang meliputipembangunan PL, infrasktruktur, kontrol, aplikasi dandatabase pada sistem.

Tantangan warisanDikembangkan bertahun-tahun dengan orang-orangyang berbeda-beda

Tantangan heterogensisDalam hal distribusi & teknologi

Tantangan dalam Rekayasa Perangkat Lunak

Dalam hal distribusi & teknologi Tantangan pengiriman

Bagaimana mengirim sistem yang besar dan komplekscepat dan dengan kualitas tetap terjaga.

Pelaku Dalam RPL Manajer1. Manajer proyek2. Manajer konfigurasi3. Manajer penjamin kulitas PL4. Manajer bidang lainnya (sesuai kebutuhan

Software Developer1. Analis sitem2. Desainer3. Programmer4. Inspektor PL5. Pengontrol perubahan

Pendukung 1. Staf administrasi2. Humas3. Pencatat teknis4. Administrator database

Pelaku Dalam RPL (Lanjutan)

4. Administrator database5. Administrator jaringan

Pertemuan 2

SOFTWARE DEVELOPMENT SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

POKOK BAHASAN

Biaya PL

Software Quality Attribute

Standar kualitas

Takaran Jaminan 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 keseluruhanBiaya terbesar untuk perangkat lunak terletak pada proses

perawatan (maintenance) dibanding biaya pembuatannya(develop)

Biaya pengadaan perangkat lunak yang di pasang pada PCsering lebih besar dibandingkan dengan harga perangkatkerasnya kec. Di negara-negara yang tidak menghargai HAKIkerasnya kec. Di negara-negara yang tidak menghargai HAKI

Biaya perangkat lunak secara kasar sebesar 60% dari biayauntuk pembangunan dan 40% untuk pengujian

Secara umum besarnya biaya bervariasi tergantung pada tipesistem yang dibangun dan kebutuhan sistem seperti kinerja dankehandalan sistem

Biaya distribusi tergantung pada model pembangunan yangdigunakan

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 correctness dan availability

(ketersediaannya) Sebagai suatu kemungkinan bahwa sistem ini mampu

memenuhi suatu kegunaan (tergantung spesifikasinya)untuk sejumlah masukan percobaan di bawah kondisimasukan dan rentang waktu yang telah ditentukan.

User Friendliness (mudah digunakan) Adequacy (kecukupan) Learnability (mudah dipelajari) Robustness (antisipasi kesalahan)

Maintenatibility (mudah dirawat)

SOFTWARE QUALITY ATTRIBUTE (2)

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 faseproses 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 Organisasi (Organization Measures) Pengalaman pengembang (developer) dalam

mempelajari strategi dan teknik yang tepat dalammembangun PL

UKURAN JAMINAN KUALITAS (2)

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) 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 tingkahlaku dan keputusan yang dibuat oleh para ahli profesional

Masyarakat profesional: praktisi, pengajar, manajer, supervisor,pengambil kebijakan.

Yang diatur: 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 yangdigunakan untuk menyediakan pendukung otomatisdalam aktivitas pembangunan PL.

Tujuanmeningkatkan produktivitas dalam proses pembangunanPL secara signifikanPL secara signifikan

Dikelompokkan dalam 2 kategori:1. Upper-CASE

Mendukung aktivitas proses pembangunan tahap awal(tahap analisis kebutuhan dan desain)

2. Lower-CASEMendukung aktivitas pembangunan di tahap akhirprogramming, debuging, dan testing)

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

CASE TOOLS (2)

DebuggerDigunakan untuk mencari kesalahan yg mungkin terjadi

Automated TranslatorsDigunakan untuk pembangkitan source code program otomatis

Compilator IntegratedDigunakan membuat antarmuka, koding, hingga membentukaplikasi yg bisa dijalankan

Instalator KitDigunakan untuk membuat file instalasi/setup

SOFTWARE DEVELOPMENTLIFE CYCLE (SDLC)

Proses Generik Spesifikasi

Apa yang harus dilakukan oleh perangkat lunak danbatasan/kendala pengembangannya

PengembanganProses memproduksi sistem perangkat lunakProses memproduksi sistem perangkat lunak

ValidasiPengujian perangkat lunak terhadap keinginan pengguna

EvolusiPerubahan perangkat lunak berdasarkan perubahankeinginan.

MODEL PROSES RPL

Model Waterfall, Model Prototyping, Model Evolutionary Model Spiral Reuse Based Development Reuse Based Development

WATERFALL MODEL

Pemodelan

Sistem/

Informasi

Requirement Definitions

System andsoftware designsoftware design

Implementationand unit testing

Integr ation andsystem testing

Operation andmaintenance

Requirements Analysis And DefinitionPembentukan kebutuhan

System And Software DesignMengubah kebutuhan-kebutuhan menjadi bentukkarakteristik yang dimerngerti perangkat lunak

WATERFALL MODEL (2)

Implementation And Unit TestingPenulisan program

Integration And System TestingMemeriksa program, mencari kesalahan

Operation And MaintenancePemeliharaan sistem, menambahkan fungsi

WATERFALL MODEL (3)Problems Model Waterfall1. Jarang sekali proyek yang prosesnya bisa dilakukan

secara sequencial.2. Sukar bagi customer untuk secara explisit

mengemukakan semua kebutuhannya.mengemukakan semua kebutuhannya.3. Customer harus sabar.4. Developer sering menunda pekerjaan. Anggota tim

harus menunggu anggota lainnya5. menyelesaikan tugasnya.

PROTOTYPE MODEL

MendengarkanPelanggan

MembangunKonstruksi(prototipe)

Uji Pelanggan(evaluasi)

Prototype Paradigm dimulai dengan mengumpulkankebutuhan-kebutuhan customer.

Developer dan customer bertemu dan mendefinisikanobyektif software secara menyeluruh, mengidentifikasikebutuhan-kebutuhan yang diketahui dari area pekerjaan.

Setelah itu dibuat Quick Design.

PROTOTYPE MODEL (2)

Setelah itu dibuat Quick Design. Quick Design difokuskan pada representasi aspek software

yang bisa dilihat customer/user (misal: format input danoutput).

Quick Design cenderung ke pembuatan prototipe. Prototipe dievaluasi customer/user dan digunakan untuk

menyempurnakan kebutuhan software yang akandikembangkan.

PROTOTYPE MODEL (2)

Sering terjadi customer menjabarkan objektif umummengenai software yang diminta, tetapi tidak bisamendefinisakan input, proses, output yang dimintasecara detail.

Disisi lain, developer menjadi tidak yakin terhadapefisiensi algoritma, kemampuan adaptasi terhadapefisiensi algoritma, kemampuan adaptasi terhadapsistem operasi, atau bentuk interaksi mesin denganorang.

Untuk mengatasi situasi tersebut, bisa digunakanpendekatan 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 bisaperubahan saja supaya prototipe tersebut bisaberjalan.

Development membuat implemetasi yang kompromitasdengan tujuan untuk memperoleh prototipe pekerjaansecara cepat. Dampaknya adalah sistem operasi atau bahasa

pemrograman yang dipergunakan tidak tepat,algoritma tidak efisien.

EVOLUTIONARY MODEL

Penjelasan :1. Kombinasikan elemet-element dari waterfall dengan sifat

iterasi/perulangan.2. Element-element dalam waterfall dikerjakan dengan

hasil berupa produk dengan

EVOLUTIONARY MODEL INCREMENTAL (2)

3. Spesifikasi tertentu, kemudian proses dimulai dari fasepertama hingga akhir dan menghasilkan produk denganspesifikasi yang lebih lengkap dari yang sebelumnya.

4. Demikian seterusnya hingga semua spesifikasi memenuhikebutuhan yang ditetapkan oleh pengguna.

5. Produk hasil increment pertama biasanya produk inti(core product), yaitu produk yang memenuhi kebutuhandasar. Produk tersebut digunakan oleh pengguna ataumenjalani review/ pengecekan detil. Hasil reviewtersebut menjadi bekal untuk pembangunan padaincrement berikutnya. Hal ini terus dikerjakan sampaiproduk yang komplit dihasilkan.

EVOLUTIONARY MODEL INCREMENTAL (3)

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 bisaberfungsi dengan spesifikasi dasar.

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 masing-masing hasil increment

EVOLUTIONARY MODEL INCREMENTAL (4)

masing hasil increment

EVOLUTIONARY MODEL SPIRAL

Penjelasan : Customer Comunication

Membangun komunikasi yang baik dengan pelanggan Planning

Mendefinisikan sumber, batas waktu, informasi-informasi lain seputarproyek

Risk Analyst

EVOLUTIONARY MODEL SPIRAL (2)

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 faseengineering dan fase instalasi

Pada model spiral, resiko sangat dipertimbangkan.Resiko adalah sesuatu yang mungkin mengakibatkankesalahan.

Model spiral merupakan pendekatan yang realistikuntuk Perangkat Lunak berskala besar.

Pengguna dan pembangun bisa memahami dengan

EVOLUTIONARY MODEL SPIRAL (3)

Pengguna dan pembangun bisa memahami denganbaik software yang dibangun karena setiapkemajuan yang dicapai selama proses dapat diamatidengan baik. Namun demikian, waktu yang cukuppanjang mungkin bukan pilihan bagi pengguna, karenawaktu yang lama sama dengan biaya yang lebih besar.

REUSE BASEDA. Software Re-engineering

Apakah itu?Restrukturisasi atau menulis ulang sebagian ataukeseluruhan dari sistem yang telah ada tanpa merubahfungsionalitasnya.

Kapan? Kapan?Ketika sebagian tetapi tidak semua sub sistem yg besarmembutuhkan perawatan yg seringKetika HW dan SW sudah lama hampir tak berfungsi

Bagaimana?Sistem bisa di restrukturisasi dan didokumentasi ulanguntuk membuat menjadi mudah dalam perawatan

Software Re-engineering (lanjutan) Mengapa?

Mengurangi resikoSW yang baru dibangun membawa resiko ygtinggi

Mengurangi biaya

REUSE BASED (2)

Mengurangi biayaBiaya untuk re-engineering sering lebih kecildibanding membangun SW baru.

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

REUSE BASED (3)

proses ini Mengapa?

Kode aslinya telah dalam keterbatasan dimana sudah terlalulama, misal kebutuhan memori, kinerja, dll

Perawatan terbentur pada struktur dan program yang rusaksehingga membutuhkan kerja yg sangat keras

Program secara otomatis distrukturisasi ulang untukmenghilangkan beberapa bagian yang tidak beres dalamkondisi yang sangat kompleks.

Pertemuan 3

Manajemen ProyekPerangkat Lunak

Proses Dalam Manajemen PLManajemen proyek merupakan lapisan pertama dalam prosesrekayasa perangkat lunak skala besar. Untuk menuju padaproyek yang berhasil, perlu dimengerti tentang :

Lingkup pekerjaan Resiko yang dapat ditimbulkan Resiko yang dapat ditimbulkan Sumber-sumber yang diperlukan Tugas yang harus dilaksanakan Patokan yang harus diikuti Usaha atau biaya yang dikeluarkan Dan Penjadwalan

Untuk mengestimasi biaya, pembagian tugas, danpenjadwalan, sebelum sebuah proyek direncanakan :

Langkah Awal dalam Manajemen Perangkat Lunak

Memastikan tujuan dan ruang lingkupMemperhatikan alternatif-alternatif solusi

Identifikasi batasan teknik dan manajerial

Fokus Manajemen ProyekManajemen proyek terfokus pada 4P, yaitu :1. People

Elemen terpenting dalam keberhasilan suatu proyek2. Product

Perangkat lunak yang dihasilkanPerangkat lunak yang dihasilkan3. Process

Sekelompok aktivitas kerangka kerja dalammerekayasa perangkat lunak

4. ProjectSeluruh proses yang dibutuhkan untuk menghasilkansuatu produk

Faktor-faktor yang mempengaruhi hasil akhir proyekPerangkat Lunak Ukuran (size) Batas waktu pengiriman (Delivery Deadline) Pembiayaan dan anggaran (Budgets & Costs) Bidang aplikasi (Application Domain) 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 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 dan satuan ukuran akan membantu untukmengerti proses-proses dalam pengembangan danproduk itu sendiri. Proses dan produk diukur usaha

Pengukuran Perangkat Lunak

produk itu sendiri. Proses dan produk diukur usahauntuk meningkatkan kualitasnya.

1. Pengukuran LangsungTerkait dengan biaya dan usaha yang diaplikasikan,misalnyayang menyangkut deretan kode program,kecepatan eksekusi, ukuran memori yang dibutuhkandan cacat pada produk, yang dilaporkan pada sejumlah

Pengukuran Perangkat Lunak (2)

dan cacat pada produk, yang dilaporkan pada sejumlahperiode waktu

2. Pengukuran tidak LangsungTerkait dengan fungsionalitas, kualitas, kompleksitas,efisiensi, reabilitas, kemampuan pemeliharaan dan lain-lain

Mengapa perangkat Lunak Harus Diukur??1. Untuk mengetahui karakteristik Perangkat Lunak2. Proses evaluasi Perangkat Lunak3. Prediksi kebutuhan Perangkat Lunak

Pengukuran Perangkat Lunak (3)

3. Prediksi kebutuhan Perangkat Lunak4. Pengembangan Perangkat Lunak

Kualitas Pengukuran Perangkat Lunak : Correctness

Sesuai dengan spesifikasi yang diinginkan Maintability

Pengukuran Perangkat Lunak (4)

Kemudahan pemeliharaan dan stabil Integrity

Daya tahan terhadap serangan dari luar sistem Usability

Kemudahan dalam penggunaan (user-friendly)

EstimasiDalam aktifitas utama proyek yaitu perencanaan,dilakukan: Sumber daya manusia (ukuran orang/bulan) Jangka waktu kronologis (Ukuran waktu kalender) 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 Untuk mengontrol dan mendokumentasikan

pembiayaan proyekB. 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 denganmetode TCA

Terkonsentrasi pada biaya tidak langsung(tambahan)(tambahan)

Biaya selalu berhubungan dengan aktifitas Aktifitas selalu menggunakan sumber daya Mengkonversi biaya langsung menjadi tidak langsung

Analisis resiko merupakan serangkaian langkah untukmenyiasati resiko

Analisis resiko sangat penting dalam manajemen

Analisis Resiko

proyek perangkat lunak. Beberapa hal yang harusdiperhatikan berkaitan dengan resiko adalah: Masayang akan datang, Perubahan, Pilihan.

Identifikasi resikoMelihat semua resiko sesuai dengan kategori(secaramakro).

Perkiraan resikoMemperhitungkan lebih lanjut estimasi resiko.

Menyiasati Resiko

Memperhitungkan lebih lanjut estimasi resiko. Proyeksi resiko

Disebut juga estimasi resiko, adalah usaha untukmengukur setiap resiko.

Strategi manajemen resiko Putusan (Resolution) resiko Pemantauan resiko

Pengendalian ResikoStrategi Penanganan Resiko1. Manajemen Resiko Reaktif

Tim proyek beraksi pada resiko merekamenjumpainya

Pelonggaran rencana penambahan resourceantisipasi, misalnya kebakaranantisipasi, misalnya kebakaran

Perbaikan pada kesalahan, sumber daya yangditemukan & diterapkan ketika resiko sudahmenyerang

Manejemen krisis kesalahan tidak dapat diresponoleh sumber daya & menjadi ancaman bagikeberlangsungan proyek

2. Manajemen Resiko Proaktif Kinerja analisis resiko secara formal Koreksi terorganisasi pada penyebab resiko Pengujian sumber resiko yang diantaranya adalah

perangkat lunak

Pengendalian Resiko (2)

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 Memerlukan dokumen kebutuhan yang akan digunakan

untuk pengambilan keputusan menerimaproyek/menolaknya. Jika menerima maka langkahselanjutnya adalah membuat proposal

Segitiga proyek (Proyek Triangle)1. Time

Penjadwalan tugas, penentuan durasi,ketergantungan tugas

Perencanaan Proyek (2)

2. Money Anggaran Belanja, sumber daya

3. Scope Ruang lingkup pekerjaan

Strategi Perencanaan memilih dan menerapkannya Hasil tujuan Asumsi/anggapan Pembatasan Area/cakupan berhubungan dengan tugas dan

pengiriman

Perencanaan Proyek (3)

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

Tools dan Teknik Manajemen Proyek Work Breakdown Structure Project Network Diagram Critical Path Method (CPM)

Perencanaan Proyek (4)

Program Evaluation and Review Technique (PERT) Gantt Chart Precedence Diagramming Method (PDM)

PenjadwalanLangkah-langkah yang dilakukan dalam penjadwalan:1. Identifikasi sekumpulan tugas2. Pastikan keterkaitan antar tugas3. Estimasi usaha untuk tiap-tiap tugas4. Tentukan pekerja dan sumber-sumber lainnya4. Tentukan pekerja dan sumber-sumber lainnya5. Buat jaringan tugas6. Buat jadwal kerja berdasarkan waktu

Penelusuran dan pengendalian dilakukansetelah ada penjadwalan yang pasti, yaitumemeriksa apakah tugas telah dilaksanakan

Penelusuran dan Pengendalian

memeriksa apakah tugas telah dilaksanakansesuai dengan jadwal.

Indikasi kualitas produk Perkiraan produktivitas orang-orang yang

menghasilkan produk Perkiraan manfaat dari penerapan metode dan

tools

Tujuan Pengukuran Perangkat Lunak

tools Membentuk dasar dari estimasi Menegaskan (Justify) permintaan tools baru dan

pelatihan

Kualitas perangkat lunak dihitung pada saat prosesrekayasa perangkat lunak ataupun setelahdiserahkan kepada pemakai.

Satuan ukuran kualitas perangkat lunak pada saatproses rekayasa :

Ukuran Kualitas Perangkat Lunak

proses rekayasa :1. Kompleksitas program2. Modularitas yang efektif3. 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 Munculnya resiko yang dapat diperkirakan dan resiko

yang diluar perkiraan Kesulitan secara teknis Kesalahpahaman antara anggota tim proyek Kesalahan dalam manajemen proyek

Komponen Dalam Proyek PL Manager Senior

Menentukan isu-isu bisnis yang memiliki pengaruhpenting dalam proyek

Manager (Teknis) ProyekMerencanakan, memotivasi, mengorganisir danmengontrol proyek sebuah produk / aplikasi

PelaksanaYang menyampaikan keterampilan teknik yangdiperlukan untuk merekayasa sebuah produk / aplikasi

PelangganMenentukan jenis kebutuhan akan perangkat lunakyang akan direkayasa

Pemakai Akhir (end-user)

Komponen Dalam Proyek PL (2)

Pemakai Akhir (end-user)Yang berinteraksi dengan perangkat lunak bilaperangkat lunak telah dipublikasikan (release) untukdigunakan

Komponen Dalam Proyek PL (3)Faktor yang harus dipertimbangkan dalam menyeleksi tim

pelaksana proyek1. Tingkat kesulitan dari masalah yang akan dikerjakan2. Ukuran program yang dihasilkan yang terkait dengan2. Ukuran program yang dihasilkan yang terkait dengan

jumlah fungsi yang digunakan3. Waktu yang dibutuhkan oleh tim untuk bekerja secara

bersama-sama4. Tingkatan dimana masalah dapat dimodularisasi /

dibuat dalam bentuk modul

5. Kualitas yang diperlukan serta keandalan sistem yangdibangun

6. Kepastian tanggal penyampaian ke pelanggan7. Memiliki kemampuan sosialisasi (komunikasi) yang

Komponen Dalam Proyek PL (4)

dibutuhkan dalam proyek

Definisi Masalah dalam RPL1. Menetapkan Ruang Lingkup Permasalahan : Konteks

Bagaimana software yang akan dibangun nantinya dapatmemenuhi kebutuhan sistem serta batasan yangditentukan oleh sistemditentukan oleh sistem

Tujuan InformasiMenentukan objek data yang dihasilkan sebagai outputdan object data yang diperlukan sebagai input

Fungsi dan Unjuk KerjaMenentukan fungsi yang akan dilakukan untukmentransformasi input data menjadi output serta ciri kerjakhusus yang akan ditekankan

2. Dekomposisi masalahMenetapkan pembagian fungsi / aktivitas kerja pada 2area utama, yaitu ;

Fungsionalitas yang harus disampaikan Proses yang akan dipakai untuk menyampaikannya

Definisi Masalah dalam RPL (2)

Proses yang akan dipakai untuk menyampaikannya

ARTIFACT UML

Actor AUse Case 1

Use Case 2

Actor B

9: sortByName ( )

GrpFile

read( )open( )create( )fillFile( )

rep

Repository

name : char * = 0

readDoc( )readFile( )

(from Persistence)

FileMgr

fetchDoc( )sortByName( )

DocumentList

add( )delete( )

Document

name : intdocid : intnumField : int

get( )open( )close( )read( )sortFileList( )create( )fillDocument( )

fList

1

FileList

add( )delete( )

1

File

read( )

read() fill the code..

UI

MFC

RogueWave

DocumentApp

Persistence Window95

Windows95

Windows95

- 95 : - NT: - - : - -, - - IBM : -, -

Repository DocumentList

Customernameaddr

withdraw()fetch()send()receive()

Domain Expert

Openning

Writing

Reading Closing

add file [ numberOffile==MAX ] / flag OFF

add file

close file

close file

Use Case 3

Use-Case Diagram Class Diagram State Diagram

Deployment DiagramClass

user :

mainWnd : MainWnd

fileMgr : FileMgr

repository : Repositorydocument : Document

gFile : GrpFile

L1: Doc view request ( )

2: fetchDoc( )

5: readDoc ( )7: readFile ( )

3: create ( )6: fillDocument ( )

4: create ( )8: fillFile ( )

global

- .EXE

WindowsNT

- .EXE

WindowsNT

Solaris

-.EXE

AlphaUNIX

IBM Mainframe

-

-

Document

FileManager

GraphicFileFile FileList

user

mainWnd fileMgr : FileMgr

repositorydocument : Document

gFile

1: Doc view request ( )

2: fetchDoc( )

3: create ( )

4: create ( )

5: readDoc ( )

6: fillDocument ( )

7: readFile ( )

8: fillFile ( )

9: sortByName ( )

- .

- - - .

- - .

Forward Engineering(Code Generation)and

Reverse Engineering

Executable System

User InterfaceDefinition

Source Code edit, compile, debug, link

Collaboration Diagram

Sequence Diagram

Component Diagram

Package Diagram

DIAGRAM-DIAGRAM DI UML

Use CaseDiagramsUse CaseDiagramsUse CaseDiagrams

StateDiagramsStateDiagramsObjectDiagrams

Use CaseDiagramsUse CaseDiagramsActivityDiagrams

StateDiagramsStateDiagramsClassDiagrams

DeploymentDiagram

ScenarioDiagramsScenarioDiagramsSequenceDiagrams

StateDiagramsStateDiagramsStateDiagrams

ComponentDiagramsComponent

DiagramsComponentDiagrams

Model

ScenarioDiagramsScenarioDiagramsCollaborationDiagrams

USE CASE DIAGRAM

Menggambarkan fungsionalitas yang diharapkan darisebuah sistem. Yang ditekankan adalah apa yangdiperbuat sistem, dan bukan bagaimana.

Menggambarkan kebutuhan system dari sudutpandang user

Mengfokuskan pada proses komputerisasi Mengfokuskan pada proses komputerisasi(automated processes)

Menggambarkan hubungan antara use case danactor

Use case menggambarkan proses system (kebutuhansystem 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 Use case diagram terdiri dari

a. Use caseb. Actorsc. Relationshipd. System boundary boxes (optional)e. Packages (optional)

Deskripsi Use case Diagram

Use case dibuat berdasar keperluan actor, merupakanapa yang dikerjakan system, bukan bagaimana systemmengerjakannya

Use case diberi nama yang menyatakan apa hal yangdicapai dari hasil interaksinya dengan actor.

Use case

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 informasidari system

Actor menggambarkan sebuah tugas/peran dan bukannyaposisi sebuah jabatanposisi sebuah jabatan

Actor memberi input atau menerima informasi dari system Actor biasanya menggunakan Kata benda

Simbol actor

Tidak boleh ada komunikasi langsung antaractor

Indikasi untuk sebuah actor yangmerupakan sebuah system

Adanya actor bernama Time yangmengindikasikan scheduled events (suatumengindikasikan scheduled events (suatukejadian yang terjadi secara periodik/bulanan)

Letakkan actor utama anda pada pojok kiri atasdari diagram

Association

Associations bukan menggambarkan alirandata/informasi

Associations digunakan untuk menggambarkanbagaimana actor terlibat dalam use case

Ada 4 jenis relasi yang bisa timbul pada use case Ada 4 jenis relasi yang bisa timbul pada use casediagram

1. Association antara actor dan use case2. Association antara use case3. Generalization/Inheritance antara use case4. Generalization/Inheritance antara actors

Association antara actor dan use case

Ujung panah pada association antara actor dan use casemengindikasikan siapa/apa yang meminta interaksi danbukannya mengindikasikan aliran data

Sebaiknya gunakan Garis tanpa panah untuk associationantara actor dan use caseantara actor dan use case

association antara actor dan use case yang menggunakanpanah terbuka untuk mengindikasikan bila actorberinteraksi 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 Gambarkan association include secara horizontal

Register for courses

Logon validation

Maintain curriculum

perluasan dari use case lain jika kondisi atau syaratterpenuhi 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

Association antara use case (Lanjut)

BukaRekening

BukaDeposito

Nasabah

Generalization/inheritance antara use case Generalization/inheritance digambarkan dengan sebuah garis

berpanah tertutup pada salah satu ujungnya yang menunjukkanlebih umum

Gambarkan generalization/inheritance antara use case secaravertical dengan inheriting use case dibawah base/parent use case

Generalization/inheritance dipakai ketika ada sebuah keadaan yang Generalization/inheritance dipakai ketika ada sebuah keadaan yanglain sendiri/perlakuan khusus (single condition)

BukaRekening

Nasabah BukaDeposito

Generalization/inheritance antara actor

Gambarkan generalization/inheritance antara actorssecara vertical dengan inheriting actor dibawahbase/parent use case

Use case System boundary boxes

Digambarkan dengan kotak disekitar use case, untuk menggambarkanjangkauan system anda (scope of of your system).

Biasanya digunakan apabila memberikan beberapa alternative systemyang 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 daripengembangan dan desain berorientasi objek.

Class menggambarkan keadaan (atribut/properti) suatusistem, sekaligus menawarkan layanan untuk memanipulasikeadaan tersebut (metoda/fungsi).

Class diagram menggambarkan struktur dan deskripsi class,package dan objek beserta hubungan satu sama lain seperticontainment, pewarisan, asosiasi, dan lain-lain.containment, pewarisan, asosiasi, dan lain-lain.

Class memiliki tiga area pokok :1.Nama, merupakan nama dari sebuah kelas2. Atribut, merupakan peroperti dari sebuah kelas. Atribut melambangkan

batas nilai yangmungkin ada pada obyek dari class

3. Operasi, adalah sesuatu yang bisa dilakukan oleh sebuah class atauyang dapat dilakukan olehclass 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 samapada paket yang sama

Nama Class

Atribut

Metode/operasi

HUBUNGAN ANTAR CLASS

1. Asosiasi, yaitu hubungan statis antar class. Umumnyamenggambarkan class yang memiliki atribut berupa classlain, atau class yang harus mengetahui eksistensi class lain.Panah navigability menunjukkan arah query antar class.

2. Agregasi, yaitu hubungan yang menyatakan bagian (terdiriatas..).

3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapatditurunkan dari class lain dan mewarisi semua atribut danmetoda class asalnya dan menambahkan fungsionalitasbaru, sehingga ia disebut anak dari class yang diwarisinya.Kebalikan dari pewarisan adalah generalisasi.

4. Hubungan dinamis, yaitu rangkaian pesan (message) yangdi-passing dari satu class kepada class lain. Hubungandinamis dapat digambarkan dengan menggunakansequence diagram yang akan dijelaskan kemudian.

CONTOH CLASS DIAGRAM

MULTIPLICITY

1..*

0..*

1

*

Unspecified Exactly one Zero or more (many, unlimited)

One or more

2..4

0..1

1..* One or more Zero or one (optional scalar role) Specified range Multiple, disjoint ranges 2, 4..6

Class Diagram diperoleh berdasarkan dari database

Contoh Kasus (Acknowledgments Evi Lutfi Muktar)

pelanggan_regno int(5)nomor_pelanggan varchar(12)nama_lengkap varchar(20)username varchar(13)password varchar(13)email varchar(30)

cari()simpan()batal()

i_01nomor_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)tarif_baru varchar(2)daya_baru varchar(6)peruntukan varchar(20)gardu varchar(20)status varchar(1)

simpan()batal()

11 11

user

id_user varchar(50)password varchar(50)nama_lengkap varchar(100)email varchar(100)bagian varchar(100)referensi varchar(100)level varchar(50)

1n 1n

master_tarifnomor int(5)peruntukan varchar(10)tarif varchar(2)daya varchar(10)bp int(10)ujl int(10)materai int(10)

kwitansinomor_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()batal()tambahkwitansi()cari()

n1 n1

n

n

n

n

perintah_kerjanomor_pk int(5)tgl_pk varhcar(15)no_kwitansi int(5)

1

1

1

1keluhan_pelangganid int(5)nomor_pelanggan varchar(12)nama_pelanggan varchar(20)email varchar(100)keluhan textkode_security varchar(6)

Contoh Kasus (Acknowledgments Toeko triyanto)

no_kwitansi int(5)tgl_kwitansi varchar(15)status int(1)

cari()

mutasinomor_mutasi int(5)tgl_mutasi varchar(15)nomor_pk int(5)tgl_pk varchar(15)status int(1)

cari()

1

1

1

1

master_statusnomor_status int(1)keterangan varchar(15)

1

1

1

1

kode_security varchar(6)

simpan()batal()

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

modulid_modul int(5)nama_modul varchar(50)link varchar(100)static_content textgambar varchar(100)publish enum('Y','N')status enum('user','admin','umum')aktif enum('Y','N')urutan int(5)

simpan()batal()

master_pelanggannomor_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)nomor_meter varchar(6)nomor_ktp varchar(20)telpon varchar(13)gardu varchar(20)

11

11

n

1

n

1

n1

n1

n

n

n

n

Statechart Statechart Diagram.

Statechart diagram, atau yang biasa juga disebut statediagram digunakan untuk mendokumentasikan beragamkondisi/keadaan yang bisa terjadi terhadap sebuah class dankegiatan apa saja yang dapat merubah kondisi/keadaantersebut. Contohnya sebuah televisi yang dapat beradadalam kondisi menyala atau mati, jika tombol power ditekanmaka televisi akan menyala, begitu juga sebaliknya akanmaka televisi akan menyala, begitu juga sebaliknya akanmati jika tombol power ditekan kembali. Maka disini kitamempunyai sebuah kelas yaitu televisi, 2 state yaitu menyaladan mati dan 2 transition yaitu menyalakan TV danmematikan TV. Tidak seperti diagram-diagram behaviourallainnya yang memodelkan interaksi diantara beberapa class,state diagram justru biasanya hanya memodelkan transisiyang terjadi hanya pada sebuah class. Berikut adalah notasistate diagram :

State Notasi State menggambarkan kondisi sebuahentitas, dan digambarkan dengan segiempat yang pinggirnya tumpul dengan nama state didalamnya State1

Transition Sebuah Transition menggambarkan sebuahperubahan 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

sebuah kondisi awal sebuah

State1

Initial State sebuah kondisi awal sebuahobject sebelum ada perubahan keadaan. InitialState digambarkan dengan sebuah lingkaransolid. Hanya satu Initial State yang diizinkandalam sebuah diagram

Final State menggambarkan ketika objek berhentimemberi respon terhadap sebuah event. FinalState digambarkan dengan lingkaran soliddidalam sebuah lingkaran kosong.

Statechart diagram menggambarkan transisi dan perubahankeadaan (dari satu state ke state lainnya)

suatu objek pada sistem sebagai akibat dari stimuli yangditerima. Pada umumnya statechart

diagram menggambarkan class tertentu (satu class dapatmemiliki lebih dari satu statechart

diagram). Dalam UML, state digambarkan berbentuk segiempat dengan

sudut membulat dan memiliki nama 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 statesis state has transitions into it but none out

Miracle statesis state has transitions out of it but none into it

initial state / creation state dengan tandaUntuk memulai sebuah state machine diagram(in western culture people read from left to right, top to bottom, starting in thetop-left corner)

Final state dengan tandaUntuk mengakhiri sebuah state machine diagramLetakkan pada pojok kanan bawah(in western culture people read from left toright, top to bottom, starting in the top-left corner)

Simple StateSebuah State yang tidak mempunyai Sub States/region/submachines

State Machine Diagram (Statechart diagram in versi 1.x)

Submachine State Sejenis composite state

State 2

State 1

State 3

Composite State Kumpulan dari

beberapa states yang setidaknya dalam sebuah region

Orthogonal State, jenis composite state lebih dari 1 region

Digunakan untuk mendukung konsep encapsulation

Sebuah state tidak boleh mempunyai region dan submachine secara bersamaan

Nama state mempunyai sintaks : nama 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

referenced state machine

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

bersamaanbersamaan

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 formatevent [guard][/methode list()]

event biasa dituliskan dengan past tense event menyebabkan sebuah object berpindah dari satu state ke state lain 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: X0 konsistenX=0 tidak konsisten

Guards harus lengkap logikanyaContoh: X0 , 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 menjadisebuah transition

Fork, memecah sebuahtransition menjadi beberapatransition yang berkondisiAND (transition harusdilewati semuanya).

Junction, Menggabungkan

Dimungkinkan transition kesebuah state yang berisibeberapa state yangdisebut state list

State1, State1, State2State2

Junction, Menggabungkansebuah/beberapa transitiondan memecahnya menjadisebuah/beberapa transitionyang berkondisi AND(transition harus dilewatisemuanya).Digunakan tanda lingkaranhitam kecilContoh:

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 pointDilambangkan sebuah lingkarankecil yang ditaruh pada pinggiranstate(bisa juga didalam ataudiluar), dan berguna sebagaisubmachine state

Exit pointDilambangkan sebuah lingkarankecil bersilang yang ditaruh padapinggiran state (bisa juga didalamatau diluar), dan berguna sebagaisubmachine 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 danperubahan keadaan (dari satu state ke state lainnya)suatu objek pada sistem sebagai akibat dari stimuli yangditerima.

Pada umumnya statechart diagram menggambarkan classtertentu (satu class dapat memiliki lebih dari satustatechart diagram).

Dalam UML, state digambarkan berbentuk segi empat Dalam UML, state digambarkan berbentuk segi empatdengan sudut membulat dan memiliki nama sesuaikondisinya saat itu. Transisi antar state umumnya memilikikondisi guard yang merupakan syarat terjadinya transisiyang bersangkutan, dituliskan dalam kurung siku. Actionyang dilakukan sebagai akibat dari event tertentudituliskan dengan diawali garis miring.

Titik awal dan akhir digambarkan berbentuk lingkaranberwarna penuh dan berwarna setengah.

Contoh State Diagram

Deployment Diagram

Deployment/physical diagram menggambarkan detailbagaimana komponen di-deploy dalam infrastruktursistem, di mana komponen akan terletak (pada mesin,server atau piranti keras apa), bagaimana kemampuanjaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikalhal lain yang bersifat fisikal

Sebuah node adalah server, workstation, atau pirantikeras lain yang digunakan untuk men-deploy komponendalam lingkungan sebenarnya. Hubungan antar node(misalnya TCP/IP) dan requirement dapat jugadidefinisikan dalam diagram ini.

Component Diagram

Component diagram menggambarkan struktur danhubungan antar komponen piranti lunak, termasukketergantungan (dependency) di antaranya.

Komponen piranti lunak adalah modul berisi code, baikberisi source code maupun binary code, baik librarymaupun executable, baik yang muncul pada compile time,link time, maupun run time.link time, maupun run time.

Pada umumnya komponen terbentuk dari beberapa classdan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil.

Komponen dapat juga berupa interface, yaitu kumpulanlayanan yang disediakan sebuah komponen untukkomponen lain.

Contoh : Component Diagram

applet1.class

Demo.html applet2.class

applet1.java

applet2.javaDemo.html applet2.class

logo.gif

applet2.java

Contoh : Component & Deployment Diagram

Contoh kasus (Acknowledgments Toeko triyanto)

pengisian data

isi ulangkirim

data masukan

state chart diagram pendaftaran

pengisian data

isi ulangkirim

statechart diagram pengisian data kwitansi.

simpan

simpan

data masukan

ACTIVITY DIAGRAM

Menggambarkan proses bisnis dan urutan aktivitas dalamsebuah proses

Dipakai pada business modeling untuk memperlihatkanurutan aktifitas proses bisnis

Struktur diagram ini mirip flowchart atau Data FlowDiagram pada perancangan terstrukturDiagram pada perancangan terstruktur

Sangat bermanfaat apabila kita membuat diagram initerlebih dahulu dalam memodelkan sebuah proses untukmembantu memahami proses secara keseluruhan

Activity diagram dibuat berdasarkan sebuah ataubeberapa use case pada use case diagram

Simbol Activity DiagramSimbol Keterangan

Start Point

End Point

Activities

Fork (Percabangan)

Join (Penggabungan)

Decision

Swimlane

Sebuah cara untuk mengelompokkan

activity berdasarkan Actor (mengelompokkan activity dalam sebuah urutan yang sama)

Sumber : Rational rose

CONTOHACTIVITYDIAGRAM

Penarikan Uang dari Account Account

Bank Melalui ATM

CONTOH ACTIVITY DIAGRAMSupplierBagian PembelianBagian Gudang

Memberi informasi dataBarang yang akan dipesan

Menerimainformasi

BuatSPP

TerimaSPP

Kirim Barangdisertai Faktur

Terima Barangdan Faktur

BuatSPBJ

TandatanganiSPBJ

TerimaSPBJ

Konfirmasipembayaran

Melakukanpembayaran

Terimapembayaran

Terima

Kwitansi

Buat

kwitansi

Procedure Berjalan (Acknowledgments Evi Lutfi Muktar)

Proses pembuatan Daftar Data Pegawai dan Gaji pada SMPPGRI 1 Depok adalah sebagai berkut :1. Proses Absensi

Pegawai melakukan absensi harian melalui form daftarhadir pegawai. Berdasarkan form daftar hadir pegawai tersebutbagian Tata Usaha (TU) akan membuat Rekap Absen (RA)harian untuk diserahkan kepada Administrasi.harian untuk diserahkan kepada Administrasi.2. Proses Pemberian Rekap Biodata Pegawai (RBP)

Pegawai memberikan data pribadi pegawai, datapendidikan, data keluarga yang dijadikan satu menjadi datapegawai kepada bagian Tata Usaha yang kemudian diarsipkanmenjadi Rekap Biodata Pegawai (RBP). Lalu Rekap BiodataPegawai (RBP) diserahkan kepada bagian administrasi untukproses pengolahan Daftar Data Pegawai Dan Gaji (DDPG).

3. 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 untukdibuatkan menjadi Daftar Data Pegawai dan Gaji (DDPG) yangkemudian diserahkan kepada Kepala Sekolah untuk ditanda tanganiatau di Acc.

4. Proses Pembuatan Laporan4. Proses Pembuatan LaporanDaftar Data Pegawai dan Gaji (DDPG) yang sudah diterima dan

ditanda tangani oleh Kepala Sekolah akan diserahkan kembali kepadabagian Administrasi untuk dibuatkan Laporan Data Pegawai (LDP) danLaporan Gaji Pegawai (LGP).

Setelah bagian administrasi menerima Daftar Data Pegawai danGaji yang sudah di Acc akan membuatkan Laporan Data Pegawai (LDP)dan Laporan Gaji Pegawai (LGP) yang nantinya akan diserakan kepadaKepala Sekolah.selain itu bagian Administrasi akan membuatkan slipgaji 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 padaPT PLN adalah sebagai berikut :

Pendaftaran perubahan dayaKonsumen datang kekantor PT PLN(Persero) dengan

membawa fotocopy KTP dan kwitansi pembayaranrekening bulan terakhir kemudian diserahkan dibagianrekening bulan terakhir kemudian diserahkan dibagianpelayanan pelanggan. Pegawai pelayanan pelanggan akanmenginput berdasarkan data dari konsumen , setelahdiinput maka akan dicetak formulir pendaftaran perubahandaya untuk kemudian ditandatangani oleh pelanggan. Saturangkap untuk pelanggan sebagai tanda bukti. Lainnyadisimpan oleh bagian pelayanan pelanggan untukditeruskan ke supervisor untuk proses persetujuan

memberikan fotocopy ktp dan rekening listrik

menerima fotocopy ktp dan rekening listrik

input pendaftaran pelanggan

cetak formulir pendaftaran

spv pelayananpelayanan pelangganpelanggan

Activity diagram pendaftaran perubahan daya

menerima formulir pendaftaran

menyetujui formulir pendaftaran

memberikan formulir pendaftaran

memberikan formulir pendaftaran

menerima formulir pendaftaran

memberikan formulir pendaftaran

menerima formulir pendaftaran

Persetujuan perubahan dayaRangkap formulir pendaftaran yang disimpan oleh bagian

pelayanan pelanggan kemudian dibuatkan surat jawaban persetujuanyang kemudian ditandatangani oleh supervisor pelayanan pelanggandicetak menjadi dua rangkap, rangkap pertama diberikan kepadapelanggan , sedangkan rangkap yang kedua disimpan oleh bagianpelayanan pelangan sebagai arsip.

pelangganspv pelayananpelayanan pelanggan

memberikan formulir pendaftaran

menerima formulir pendaftaran

membuat surat persetujuan

menyetujui surat persetujuan

memberikan surat persetujuan

menerima surat persetujuan

Perjanjian jual beli tenaga listrikSetelah pelanggan menerima surat jawaban persetujuan dari PT.

PLN (Persero) maka sipelanggan akan datang ke kantor PT PLNuntuk menandatangani surat perjanjian jual beli tenaga listrik sesuaidengan daya listrik yang baru yang akan dipasang. Surat perjanjianjual beli tenaga listrik tersebut juga ditandatangani oleh manager.

menerima surat persetujuan

membuat surat perjanjian jual beli tenaga listrik

managerspv pelayananpelanggan

menerima surat perjanjian jual beli tenaga listrik

menyetujui surat perjanjian jual beli tenaga listrik

memberikan surat perjanjian jual beli tenaga listrik

mencetak surat perjanjian jual beli tenaga listrik

memberikan surat perjanjian jual beli tenaga listrik

menerima surat perjanjian jual beli tenaga listrik

memberikan surat perjanjian jual beli tenaga listrik

menerima surat perjanjian jual beli tenaga listrik

menerima surat perjanjian jual beli tenaga listrik

menyetujui surat perjanjian jual beli tenaga listrik

memberikan surat perjanjian jual beli tenaga listrik

PembayaranSetelah menandatangani surat perjanjian jual beli tenaga listrik

maka sipelanggan tinggal membayar sejumlah yang tertera padasurat perjanjian jual beli tenaga listrik ke loket pembayaranperubahan daya, pelanggan akan mendapatkan kwitansipembayaran sebagai bukti bahwa si pelanggan telah melaksanakankewajibannya.

loket PT PLNpelanggan

melakukan pembayaran

menerima bukti pembayaran

menerima pembayaran

cetak bukti pembayaran

menyetujui bukti pembayaran

memberikan bukti pembayaran

Perintah kerjaSaaat si pelanggan membayar kewajibannya maka perintah

kerja terbit dan siap untuk di cetak, untuk diberikan kepadapelaksana sebagai perintah kerja untuk pelanksanaanpenggantian MCB pelanggan.

cetak perintah kerja

menyetujui perintah kerja

pelangganpelaksanabagian penyambungan

perintah kerja

melakukan penggantian MCB

menerima perintah kerja

menerima perintah kerja

melakukan penggantian MCB

memberikan perintah kerja

menerima perintah kerja

memberikan perintah kerja

menerima perintah kerja

menyetujui perintah kerja

memberikan perintah kerja

Koperasi STMIK Nusa Mandiri adalah sebuah koperasiyang mengelola simpan pinjam bagi para anggotanya,berikut ini adalah kegiatan yang dilakukan oleh bagianKredit dalam menangani pemberian pinjaman bagi paraanggotanya.

Setiap kali bagian kredit akan memberikan pinjamankepada Anggota maka Anggota diharuskan mengisiFormulir Permohonan Pinjaman yang berisi Nomor FPP,

Latihan STUDI KASUS ACTIVITY DIAGRAM

Formulir Permohonan Pinjaman yang berisi Nomor FPP,Tanggal Permohonan, Nomor Anggota, Nama Anggota,Jumlah Permohonan dan Keperluan. Yang kemudian olehBagian Kredit dicatat dan disimpan kedalam Arsip FPP.Berdasarkan Arsip FPP tersebut Bagian Kredit membuatBukti Peminjaman yang diberikan kepada Anggota yangberisi No. BP, tgl BP, Nomor Anggota, Nama Anggota,Jumlah Realisasi, Lama Angsuran, Jumlah Angsuran danBunga.

Setiap Bulan Anggota diharuskan membayar Angsuransejumlah Angsuran yang disepakati pada saatPeminjaman yang kemudian oleh bagian Kredit dicatatdan direkam kedalam Arsip Angsuran. BerdasarkanArsip Angsuran tersebut bagian Kredit membuat BuktiAngsuran yang diberikan kepada Anggota yang berisiNo. BA, Tanggal BA, No. BP, Jumlah Angsur dan BungaNo. BA, Tanggal BA, No. BP, Jumlah Angsur dan Bunga

Pada akhir bulan Bagian Kredit selalu membuat LaporanPeminjaman dan Laporan Angsuran yang diberikanKepada Ketua Koperasi.

Latihan Activity Diagram !

PT. Nusantara adalah sebuah perusahaan yang bergerakdibidang penjualan Tunai barang-barang elektronik. Semuatransaksi di perusahaan masih dilakukan secara manual.Berikut ini adalah kegiatan kegiatan yang dilakukan olehbagian Penjualan dalam melaksanakan transaksi penjualanBarang di dalam perusahaan.

1. Pemesanan barang1. Pemesanan barangSetiap kali Bagian penjualan akan menjual barang ia selalu

menerima surat pesanan dari pelanggan. Berdasarkan Suratpesanan tersebut bagian penjualan kemudian mencatat danmerekamnya kedalam Arsip Surat Pesanan. BerdasarkanArsip surat pesanan tersebut, bagian penjualan membuatkanFaktur dan Surat Jalan yang dikirimkan kepada Pelanggansebagai bukti bahwa barang yang dipesan sudah terealisasidan rangkapnya disimpan sebagai Arsip Faktur dan ArsipSurat Jalan.

2. Pembuatan KwitansiApabila Faktur dan Surat Jalan sudah sampai ditempat

pelanggan, maka pelanggan megirimkan Pembayaranyang kemudian oleh bagian penjualan dibuatkanKwitansi yang dibuat berdasarkan Arsip Faktur yangkemudian diserahkan kepada pelanggan sebagai buktipembayaran dan rangkapnya disimpan kedalam ArsipKwitansi

3. Pembuatan Laporan3. Pembuatan LaporanSetiap akhir bulan Bagian Penjualan selalu membuat

Laporan Penjualan berdasarkan Arsip Faktur danLaporan Pesanan berdasarkan Arsip Pesanan danLaporan Pengiriman berdasarkan Arsip Surat Jalanyang ditujukan kepada Kepala Bagian Penjualan

Diminta : Buatlah Activity diagram dari data diatas !

Sequence Diagram

Sequence diagram menggambarkan interaksi antar objekdi dalam dan di sekitar sistem (termasuk pengguna,display, dan sebagainya) berupa message yangdigambarkan terhadap waktu. Sequence diagram terdiriatar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait).

Sequence diagram biasa digunakan untukmenggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuahevent untuk menghasilkan output tertentu. Diawali dariapa yang men-trigger aktivitas tersebut, proses danperubahan apa saja yang terjadi secara internal danoutput apa yang dihasilkan.

Diagram ini secara khusus berasosiasi dengan use case Diagram ini secara khusus berasosiasi dengan use casediagram

Memperlihatkan tahap demi tahap apa yang seharusnyaterjadi untuk menghasilkan sesuatu didalam use case

Simbol Sequence Diagram

Contoh Sequence Diagram

SEQUENCE DIAGRAM INPUT DATA PEGAWAI SEQUENCE DIAGRAM INPUT DATA PEGAWAI Contoh kasus Penggajian (Acknowledgments Evi Lutfi Muktar)

SEQUENCE DIAGRAM INPUT DATA PENDIDIKANSEQUENCE DIAGRAM INPUT DATA PENDIDIKAN

SEQUENCE DIAGRAM INPUT DATA KELUARGASEQUENCE DIAGRAM INPUT DATA KELUARGA

SEQUENCE DIAGRAM ABSEN MASUKSEQUENCE DIAGRAM ABSEN MASUK

: administrator : form tambah manajemen user : control form tambah

manajemen user : pelanggan

open ( )get username, passwordnama lengkap, email

display username, passwordnama lengkap, email

Contoh kasus PLN (Acknowledgments Toeko triyanto)

simpan simpan

: pelanggan : form tambah pendaftaran : controlform tambah

pendaftaran : pelanggan1

open ( ) get nomor_pelangganperuntukan, tarif, daya

display nomor_pelanggannama pelangganalamatnomor ktpnomor telpongardugardudaya tarif lamadaya tarif baruperuntukan

simpansimpan

display no, agenda,tgl, id_pelanggan

nama, daya_lamadaya_baru, status,aksi

Collaboration diagram juga menggambarkan interaksiantar objek seperti sequence diagram, tetapi lebihmenekankan pada peran masing-masing objek danbukan pada waktu Penyampaian message.

Setiap message memiliki sequence number, di manamessage dari level tertinggi memiliki nomor 1. Messagesmessage dari level tertinggi memiliki nomor 1. Messagesdari level yang sama memiliki prefiks yang sama.

Contoh Collaboration Diagram

Berikut adalah sebuah contoh collaboration diagram yang mengilustrasikan sebuahsistem telepon genggam (handphone) :

Collaboration Diagram (Acknowledgments Toeko triyanto)

: index\home : pengunjung

: info

: register

: login

: cari

: simpan

: batal

: login1 : batal

: index\home

: pendaftaran

: manajemen kontrol

: tambah data

: cetak

: simpan

: batal

: logout

: index\home : login1

: manajemen user

: edit

: hapus

: batal

: tambah user

: simpan

: update

: batal

: manajemen modul

: tambah modul

: edit

: hapus

: simpan

: batal

: update

: batal : profile

: browse

: update

: tambah data : pendaftaran

: cetak : cari

: simpan

: batal

: cetak dokumen

: cari

: cetak

: kwitansi1

: tambah kwitansi

: cetak

: cari

: simpan

: batal : cari

: member

: admin : login

: batal

: cetak

: perintah kerja1

: cari

: cetak

: mutasi1

: batal

: manajemen kontrol1

: cari

: cari

: peremajaan : data pelanggan1

: cari : informasi tagihan1

: cari

: guestbook1 : tambah guestbook

: batal

: simpan

: edit : hapus

: batal : simpan

: user : index\home

: cetak dokumen

: cari : cetak

: kwitansi1

: tambah kwitansi

: cetak

: cari

: simpan

: batal

: perintah kerja1

: cari

: cetak

: batal

: cari

: peremajaan

: mutasi1 : data pelanggan1

: cari

: informasi tagihan1

: cari

: guestbook1 : tambah guestbook

: batal

: simpan

: edit : hapus

: batal : simpan

PERTEMUAN 6

COMPONENT DIAGRAM

Component diagram menggambarkan struktur danhubungan antar komponen piranti lunak, termasukketergantungan (dependency) di antaranya.

Komponen piranti lunak adalah modul berisi code, baikberisi source code maupun binary code, baik librarymaupun executable, baik yang muncul pada compiletime, link time, maupun run time.

Umumnya komponen terbentuk dari beberapa class

Component Diagram

Umumnya komponen terbentuk dari beberapa classdan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil.

Komponen dapat juga berupa interface, yaitu kumpulanlayanan yang disediakan sebuah komponen untukkomponen 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, table data dalam sebuah database

, User interface (screen, pages, report)dll

Component DiagramDependencies dimodelkan dengan garis terputus dengan panah terbuka gambarkan dependencies dari kiri ke kanan

Contoh: Source Code bergantung pada MySQL

Dimungkinkan sebuah component dependencies pada interfaces component lainnyaContoh:

InheritanceInheritance inheriting/child component diletakkan dibawah parent component, dengan

arah panah menuju ke parent component dimodelkan dengan garis dengan panah tertutup Contoh:

Penjualan

Menu Utama

Pembelian

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 lollipopPada UML 1.* bisa juga digambarkan dengan garis terputus dengan panah tertutup

Required, digambarkan dengan bentuk socket Penggambaran

interfaces dapat juga dilakukan dengan menambah bagian component seperti contoh dibawah ini contoh dibawah ini

Bentuk grafik

Component Diagramport adalah bentuk object yang menjelaskan interaksi antara object dan

lingkungannya digambarkan sebagai kotak kecil di pinggiran componentAssembly connector Penghubung antara

2/lebih component dimana sebuah/beberapa component provides interfaces dan component lain required component lain required interfaces

Digambarkan dengan gabungan bentuk interfacescontoh:

Component Diagram (Acknowledgments Toeko triyanto)

Kirim

Simpan database server

Browsing

Isi data

Deployment Diagram

Deployment/physical diagram menggambarkan detailbagaimana komponen di-deploy dalam infrastruktur sistem, dimana komponen akan terletak (pada mesin, server atau pirantikeras apa), bagaimana kemampuan jaringan pada lokasitersebut, spesifikasi server, dan hal-hal lain yang bersifatfisikal

Sebuah node adalah server, workstation, atau piranti keraslain yang digunakan untuk men-deploy komponen dalam

Deployment Diagram

lain yang digunakan untuk men-deploy komponen dalamlingkungan sebenarnya. Hubungan antar node (misalnyaTCP/IP) dan requirement dapat juga didefinisikan dalamdiagram ini

Deployment diagram digunakan untuk melayani pemodelanhardware yang digunakan dalam implementasi sistem danasosiasinya antara komponen-komponen tersebut. Elemenyang digunakan dalam deployment diagram adalah nodes(ditunjukkan sebagai sebuah cube), komponen (ditunjukkansebagai sebuah kotak bujursangkar) dan juga asosiasi.

Deployment diagram ini menunjukkan hardware yang digunakan padajaringan kantor yang kecil. Application server (node) terhubung dengandatabase server (node) dan database client (component) sudahterinstall 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/MicrosoftOffice, dll), akan tetapi software component tersebut akan digambarkanketika 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 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: //code style sheet //javascript

Node - Deployment Diagram Adalah hardware seperti

computer/PDA ,lap top, handphone peralatan komunikasi data (router,hub,switch,modem) dll

Digambarkan dengan bentuk kotak 3 dimensi Nama Node Node dapat

digabungkan dengan component pada component diagram

Node dapat digambarkan dengan bentuk visual, 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 IstilahAsychronous Hubungan asynchronous HTTP HyperText Transport Protocol (internet protocol_JOBC Java Database Connectivity, a Java API for database access.ODBC Open Database Connectivity, a Microsoft API for database access.

Client Server* 1* 1

association dimungkinkan mempunyai multiplicity (0..1, 1..*, dll)

RMI Remote Method Invocation, a Java communication protocol.

RPC Communication via remote procedure callsSynchronous Komunikasi synchronous Web Services Komunikasi melalui Web Services protocols seperti as SOAP and UDDIEthernet Ethernet Card

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 untuk menggambarkan software yang terdapat pada sebuah hardware

faktur.asp dependencies terhadap order.asp

dimungkinkan sebuah node memiliki node yang lain

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

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

Sd = sequence diagram

sd

diagram yang lain Interaction Overview

Diagram menggunakan notasi yang dipakai pada Activity diagram dan Sequence Diagram

Interaction, dilambangkan dengan gambar dibawah ini

Interaction Overview DiagramContoh

Sequence diagram Interaction overview 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

Dipakai untuk mengeksplorasi sebuah/beberapa object melalui periode waktuketerangan gambar : object :seminar states proposed, scheduled, enrolling students,

Being Taught, Final Exams, Closed Lifeline

Timing Constrant | {Nov 1 .. Des 31} | {jan 1 .. July 31}

Robust notationTiming Diagram

ObjectObjectLifelineLifeline

StateState/condition/condition

LifelineLifeline

MessagMessagee

Menggambarkan stuktur internal dari pengelompokkan (class, component, use case), termasuk hubungan pengelompokkan ke bagian lain dari system

Collaboration Mendefinisikan struktur dari kerjasama element/role Ditampilkan dalam bentuk elipse dengan garis terputus, yang berisi nama

collaboration Digunakan untuk menjelaskan bagaimana system bekerja

Composite Structure Diagram

atauatau

Collaboration occurrence Sebuah collaboration dihubungkan ke sebuah methode atau object melalui

collaboration occurrence Digambarkan dengan sebuah elipse dengan garis terputus yang berisi nama

occurrence (kejadian/peristiwa), titik dua dan type collaboration Contoh: retail:sale

Composite Structure Diagram

Keterangan gambar : Collaboration sale menggambarkan

collaboration antara role buyer dan seller

Collaboration brokeredsale menggambarkan collaboration diantara 3 role yaitu producer, diantara 3 role yaitu producer, broker dan consumer

Collaboration brokeredsale terdiri dari 2 occurrence dari collaboration sale yaitu wholesale:sale dan retail:sale

Ocucurrence wholesale mengindikasikan collaboration sale dimana producer sebagai seller dan broker adalah buyer

Role Digambarkan dengan kotak

dengan berisi nama Role Broker

Composite Structure Diagram

Contoh Deploment Diagram (Acknowledgments Toeko triyanto)

Client Browser Client Browser

Client Browser

Sebuah bentuk pengelompokkan yang memungkinkan untukmengambil sebuah bentuk di UML dan mengelompokkanelemen-elemennya dalam tingkatan unit yang lebih tinggi.Kegunaan package yang paling umum adalah untukmengelompokkan class.

Package Diagram

Package DiagramPackage Diagram

Menggambarkan pengelompokan dari suatu class-class

guestbook

i_01

index/home

keluhan pelanggan kwitansi

master_pelangganperintah_kerja

tunggakan

Contoh package diagram (Acknowledgments Toeko tri