TEKNIK – TEKNIK ANALISA DESAIN MENGGUNAKAN UML PADA PERANCANGAN PROGRAM BERBASISKAN OBJECT
How to Do OOAD
How to Do OOAD OO Technology
OO Prog. Languages (Smalltalk, C++)
OO Design
Process Perspective just program!
(Booch)
design then program
OO Analysis
Analyze (use case) first, then design, T then program
(Rumbaugh, Jacobson)
3
Review Basic Principles of Object Orientation Abstraksi
(Abstraction) Pembungkusan (Encapsulation) Pewarisan (Inheritance) Banyak Bentuk (Polymorphism) Pengiriman Pesan (Message Sending)
4
Hmmm…
5
Animal
Lounge Chair
Led Zepplin
«SitsInA»
«DrinksA» Dog
«GroovesTo»
Martini
«SmokesA» Cigar
{WayLoud}
6
UML Unified Modelling Language Memvisualisasikan dan mendokumentasikan hasil analisa dan desain. Unified karena … Mengkombinasikan metode OO yg sudah ada sebelumnya (Booch
by Grady Booch, OMT by Jim Rumbaugh and OOSE by Ivar Jacobson)
Modelling karena… Digunakan terutama untuk memodelkan sistem secara visual
Language karena … Berisi sintak yang digunakan untuk memodelkan pengetahuan
What UML can do for you Help you to: Memudahkan berpikir dan mendokumentasikan sistem
sebelum mengimplemntasikannya “meramalkan” sistem Menurunkan biaya pembangunan Merencanakan dan menganalisa logika sistem(perilaku) Membuat keputusan yang benar sedini mungkin (sebelum melangkah ke coding) Men-deploy sistem lebih baik, karena ada perencanaan penggunaan memori dan prosesor yang efisien. Lebih mudah memodifikasi/mengelola sistem yang terdokumentasi dengan baik. Biaya perawatan yang rendah Membuat suatu bentuk komunikasi yang standar
ARTIFACT UML (BAGAN YANG TERDAPAT PADA UML) Class Diagram
Use-Case Diagram
State Diagram add file
Writing
add file [ numberOffile==MAX ] / flag OFF
Openning
Use Case 1
close file
Actor A
Actor B close file Reading
Use Case 2
Domain Expert
Closing
<<entity>> Customer name addr receive() withdraw() fetch() send()
Use Case 3
Deployment Diagram
UI
Class
MFC
DocumentApp ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨ - À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ® - À©µµ¿ì NT: ÀÀ¿ë¼-¹ö - À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼-¹ö ¹× µ¥ÀÌŸ ¼-¹ö, Åë½Å ¼-¹ö - IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼-¹ö, Åë½Å ¼-¹ö
RogueWave
Repository
Persistence
9: sortByName ( )
DocumentList
Windows95
W indow95
Windows95
global ¹®¼-°ü¸® Ŭ¶óÀ̾ðÆ®.EXE
FileManager
¹®¼-°ü¸® ¾ÖÇø´
mainWnd : MainWnd 1: Doc view request ( )
W indows NT
L
2: fetchDoc( )
gFile : GrpFile
4: create ( ) 8: fillFile ( )
user : »ç¿ëÀÚ
User Interface Definition
Package Diagram
Document
Solaris
¹®¼-°ü¸® ¿£Áø.EXE
Alpha UNIX ÀÀ¿ë¼-¹ö.EXE Windows NT
GraphicFile
fileMgr : FileMgr 3: create ( )
File
IBM Mainframe
FileList
6: fillDocument ( ) µ¥ÀÌŸº£À̽º¼-¹ö
7: readFile ( ) 5: readDoc ( )
document : Document repository : Repository
Collaboration Diagram mainWnd user
ƯÁ¤¹®¼-¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.
fileMgr : FileMgr
document : Document
gFile
repository
1: Doc view request ( )
Forward Engineering(Code Generation) and ComponentReverse Engineering
Diagram
Source Code edit, compile, debug, link
2: fetchDoc( )
3: create ( )
4: create ( )
5: readDoc ( )
È-ÀÏ°ü¸®ÀÚ´Â Àоî¿Â ¹®¼-ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼°´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.
6: fillDocument ( )
7: readFile ( )
8: fillFile ( )
È-¸é °´Ã¼´Â ÀоîµéÀÎ °´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È-¸é¿¡ º¸¿©ÁØ´Ù.
9: sortByName ( )
Sequence Diagram
Executable System
Use-Cases Use case menggambarkan proses system (kebutuhan
system dari sudut pandang user) actors mewakili peran orang atau piranti yang dimainkan ketika sistem berfungsi Secara umum use case adalah: Pola perilaku system Urutan transaksi yang berhubungan yang dilakukan oleh satu actor Use case diagram terdiri dari Use case Actors Relationship System boundary boxes (optional) Packages (optional)
LAMBANG USE CASE Aktor
Usecase
Relasi Aktif Catatan
Relasi Pasif Generalisasi <
>
Include
<<extend>>
extend
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. Use case diagram tidak terpengaruh urutan waktu, meskipun demikian supaya mudah dibaca perlu penyusunan use case Beli Barang
Konsumen
Bayar
Jual Barang
Beli Barang
Kasir
Kasir
Terima Bayaran
Konsumen
Kasir Bayar
Konsumen
USE CASE DIAGRAM Buka Rekening
Simpan Uang
Nasabah
Simpan uang harus diatas Rp. 200.000,-
Ambil Uang Tutup Rekening
Tutup Rekening Simpan Uang Buka Rekening Nasabah Ambil Uang
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 Tidak boleh ada komunikasi langsung antar actor Indikasi <<system>> untuk sebuah actor yang merupakan sebuah system Adanya actor bernama “Time” yang mengindikasikan scheduled events (suatu kejadian yang terjadi secara periodik/bulanan)
Kasir
Konsumen
<<System Keuangan>>
Time
ACTOR-USE CASE DIAGRAM Letakkan actor utama anda pada pojok kiri atas dari diagram (in western
culture people read from left to right, top to bottom) Actor jangan digambarkan ditengah-tengah use cases (actors are placed to the outside of the diagram, and not the middle of it) Buka Rekening
Buka Rekening
Nabung
Nasabah
Ambil
Teller Nasabah
Tutup Rekening
Nabung
Use-Case Diagram Saf eHome
Access camera surveillance via t he Int ernet
cameras
Conf igure Saf eHome syst em paramet ers homeowner
Set alarm
16
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 Beli Barang association antara actor dan use case Konsumen
Kasir
Bayar
association antara actor dan use case yang
menggunakan panah terbuka untuk mengindikasikan bila actor berinteraksi secara pasif dengan system anda Beli Barang Konsumen
Bayar
Kasir
Association - Use Case Diagram <>
termasuk didalam use case lain (required) / (diharuskan) Pemanggilan use case oleh use case lain contohnya adalah Pemanggilan sebuah fungsi program Gambarkan association <> secara horizontal Tanda panah terbuka harus terarah ke sub use case Tidak boleh actor dihubungkan pada use case <> Buka Rekening
Buka Rekening
<>
catat data pribadi
Buka Rekening
<> Nasabah catat data pribadi
Buka Rekening
Nasabah Nasabah
<>
catat data pribadi
Buka Rekening
Nasabah Nasabah
<>
catat data pribadi
<>
catat data pribadi
Association antara use case (Lanjut) <<extend>> 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 Tidak boleh actor dihubungkan pada use case <<extend>> Buka Rekening
Buka Rekening
<<extend>> Nasabah
Nasabah
Buka Deposito
Buka Rekening
<<extend>>
Buka Rekening
Buka Deposito
<<extend>> Nasabah
Nasabah
Buka Deposito
<<extend>> 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
UCD Case Study (1/3) Vending Machine
After client interview the following system
scenarios were identified:
A customer buys a product The supplier restocks the machine The supplier collects money from the machine
On the basis of these scenarios, the following
three actors can be identified:
Customer; Supplier; Collector
UCD Case Study (2/3)
UCD Case Study (3/3) Introducing annotations (notes) and constraints.
CONTOH
Now ask me what I think about tools…..
29
30
