P. 1
Ada Apa Dengan UML

Ada Apa Dengan UML

|Views: 376|Likes:
Published by juwitadpr

More info:

Published by: juwitadpr on May 25, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

06/29/2013

pdf

text

original

Ada apa dengan UML?

Kebanyakan orang salah, UML bukanlah Universal Modelling Language, dimana UML tidak diperuntukkan agar bisa membuat model bagi apa saja (contoh, UML tidak terlalu baik untuk memodelkan persediaan pasar).UML juga bukanlah Unified Marxist-Leninists, suatu partai politik di Nepal. UML adalah Unified Modelling Language. lebih penting adalah, UML merupakan standardized modelling language yang terdiri dari kumpulan-kumpulan diagram, dikembangkan untuk membantu para pengembang sistem dan software agar bisa menyelesaikan tugas-tugas seperti: ‡ Spesifikasi ‡ Visualisasi ‡ Desain Arsitektur ‡ Konstruksi ‡ Simulasi dan testing ‡ Dokumentasi UML dikembangkan sebagai ide dasar untuk mempromosikan hubungan dan produktifitas antara para pengembang dari object-oriented system. UML memuaskan kebutuhan yang penting dalam pengembangan software dan sistem. Pemodelan (modeling) memungkinkan para pengembang bisa berkonsentrasi pada gambaran yang luas. UML membantu kita melihat dan menyelesaikan masalah-masalah yang sering terjadi. Ketika kita membuat model, kita membuat suatu abstraksi dari sistem nyata yang sudah ada, yang memungkinkan kita bisa bertanya tentang model tersebut dan akan kita dapatkan jawaban yang memuaskan. Setelah kita puas dengan hasil kerja kita, kita bisa menggunakan model kita bersama dengan orang lain. Kita bisa menggunakan model kita untuk meminta bantuan dari orang lain yang akan meningkatkan kerja kita, dan juga dapat saling membantu dengan mengajari orang lain. Abstracting Teknik dalam membuat model dari ide kita atau dunia nyata adalah dengan menggunakan abstraction. Sebagai contoh, map merupakan model dunia ± bukanlah miniatur dunia. Setiap diagram UML yang kita gambar memiliki keterkaitan dengan dunia nyata. Abstraction dikembangkan sebagai ketentuan untuk dipelajari dan sering digunakan. Jika kita berpikir UML sebagai map dari dunia yang kita lihat, hampir mendekati. Analogi yang lebih mendekati adalah merupakan kumpulan dari blueprint yang menampilkan detail yang cukup dari suatu bangunan untuk memastikan tentang apa sebenarnya bangunan tersebut. Abstraction model dan diagram juga berguna karena akan menjelaskan lebih rinci detail-detail yang dibutuhkan (kita tidak perlu mengambar pohon dan mobil dan orang dalam map kita, karena map kita akan menjadi susah alias tidak praktis untuk dipakai). Kategori diagram UML ‡ Structural Diagram: kita menggunakan structural diagram untuk menampilkan blok bangunanan dari sistem kita ± merupakan fitur yang tidak berubah bersama waktu. Diagram ini menjawab pertanyaan, ada apa disana? ‡ Behavioral Diagram: kita menggunakan behavioral diagram untuk menampilkan bagaimana sistem kita merespon permintaan atau apa saja seiring waktu. ‡ Interaction diagram: merupakan tipe dari behavioral diagram. Kita menggunakan interaction diagram untuk melukiskan perubahan dari pesan-pesan dalam suatu kolaborasi (kumpulan dari object-object yang sama) sehingga tujuan bisa tercapai.

‡ Structural diagram (Class diagram) : Digunakan untuk menampilkan entiti dunia nyata, elemen dari analisa dan desain, atau implementasi class dan relasinya. ‡ Structural diagram (Object diagram) : Digunakan untuk menampilkan suatu contoh spesifik atau ilustrasi dari suatu object serta link nya. Sering digunakan untuk mengindikasikan kondisi dari suatu even, seperti percobaan atau operasi pemanggilan. ‡ Structural diagram (Composite structure diagram) : Digunakan untuk menampilkan bagaimana sesuatu itu dibuat. ‡ Structural diagram (Deployment diagram) : Digunakan untuk menampilkan arsitektur run-time dari suatu sistem, kerangka hardware, ruang lingkup software, dan sebagainya. ‡ Structural diagram (Component diagram) : Digunakan untuk menampilkan organisasi dan hubungan antar sistem. ‡ Structural diagram (Package diagram) : Digunakan untuk mengorganisir elemen model dan menampilkan ketergantungan antara mereka. ‡ Behavioral diagram (Activity diagram) : Digunakan untuk menampilkan arus data dari kebiasaan antar object. ‡ Behavioral diagram (Use case diagram) : Digunakan untuk menampilkan layanan yang bisa diminta oleh actor dari sistem kita. ‡ Behavioral diagram (State machine diagram / Protocol state machine diagram) : Digunakan untuk menampilkan urutan proses dari suatu object dan kondisinya saat ini. ‡ Interaction diagram (Overview diagram) : Digunakan untuk menampilkan banyak skenario interaksi (urutan dari kebiasaan) bagi suatu kolaborasi (kumpulan elemen yang sama dan saling bekerja agar tercapai tujuan yang diinginkan). ‡ Interaction diagram (Sequence diagram) : Digunakan untuk fokus pada perubahan pesan antara grup dari suatu object dan urutan pesan tersebut. ‡ Interaction diagram (Communication diagram) : Digunakan untuk fokus pada perubahan pesan antara grup dari suatu object dan relasi dari object-object tersebut. ‡ Interaction diagram (Timing diagram) : Digunakan untuk menampilkan perubahan dan hubungan terhadap waktu nyata atau terhadap proses sistem. Karena UML sangatlah fleksibel, kita akan menjumpai berbagai cara dalam meng-kategorikan diagram kita. Pohon kategori di bawah ini cukup terkenal: ‡ Static diagram: Menampilkan fitur statis dari sistem. Kategori ini hampir sama dengan structural diagram. ‡ Dynamic diagram: Menampilkan bagaimana proses perubahan yang terjadi dalam sistem sepanjang waktu. Kategori ini mencakup UML state-machine diagram dan timing diagram. ‡ Functional diagram: Menampilkan detail dari proses dan algoritma. Kategori ini mencakup use case, interaction, dan activity diagram. Kita bisa mengembangkan diagram UML untuk menampilkan informasi yang berbeda pada waktu yang berbeda atau untuk tujuan yang berbeda. Ada banyak kerangka modelling, seperti Zachman atau DODAF. Berikut pertanyaan standar tentang sistem : ‡ Siapa yang menggunakan sistem? Menampilkan actor (pengguna sistem) dalam diagram use case(menampilkan tujuan sistem) ‡ Dari mana sistem dibuat? Menggambarkan diagram Class untuk menampilkan struktur logis dan component diagram agar bisa menampilkan struktur fisik. ‡ Dimana lokasi komponen dalam suatu sistem? Mengindikasikan rencana kita untuk menentukan lokasi suatu komponen. ‡ Kapan kejadian penting terjadi? Menampilkan apa yang menyebabkan object kita bisa bereaksi

dan mulai melakukan kerjanya dengan state diagram dan interaction diagram. ‡ Bagaimana sistem ini bekerja? Menampilkan bagian struktur diagram dan menggunakan communication diagram untuk menampilkkan interaksi. Siapa yang memerlukan UML? Para pengguna UML dibagi dalam kategori: ‡ Modeler: Modeler mencoba menjelaskan dunia nyata seperti bagaimana mereka melihatnya. ‡ Designer: Designer mencoba mencari solusi yang memungkinkan, untuk dibandingkan atau menentukan proses pada aspek yang berbeda. ‡ Implementer: Implementer membangun solusi menggunakan UML sebagai bagian dari tujuan implementasi. Kebanyakan program UML sekarang sudah bisa membuat sendiri definisi dari suatu Class atau Database, seperti kode aplikasi atau user interface. (**) UML itu cuma Gambar ? Benarkah ? Well, pertanyaan yang saya pakai mungkin terlalu extreme. Bukan. Maksud saya bukannya UML itu tidak penting. Tapi ada hal yang lebih penting yaitu OOAD itu sendiri. UML ³hanyalah´ gambar yang digunakan sebagai ³alat komunikasi´ untuk menggambarkan suatu ide yang abstrak untuk dapat diimplementasikan. Selain sebagai alat komunikasi, UML juga dapat berfungsi sebagai dokumentsasi dari suatu design. Jika architect, designer atau developer datang dan pergi dalam suatu project, UML diagrams dapat dipakai sebagai learning aid untuk memahami suatu system software yang kompleks. UML dipilih karena kita butuh standard. Komunikasi bisa lancar kalau semua orang bicara dalam bahasa yang sama. Demikian halnya UML yang merupakan bahasa dalam bentuk gambar. Misal, jika kita menggunakan UML class diagram, semua orang yang memahami UML class diagram dapat mengerti mana attribute, mana responsibility, mana yang public, mana yang protected, class yang mana implement interface, class mana merupakan generalisasi class lainnya, dan sebagainya. Celakanya, orang banyak yang tersesat dalam menggunakan UML ini. Banyak yang membuat UML menjadi ³the real thing´. Padahal, UML itu cuma model dari system yang sebenarnya. Dan definisi model adalah: ³Cheaper imitations of the real thing!´. Jadi, jangan menghabiskan terlalu banyak waktu ³menggambar´ UML. Fokuslah pada OOAD. Pada domain objects anda, kolaborasi antar object, responsibility tiap object, grouping object dan semacamnya. UML itu Cuma ³cheaper model´ dari hal-hal tadi. Dari sini, bagaimana menggunakan UML dapat dibedakan menjadi 3: 1. UML as sketch 2. UML as Blueprint 3. UML as Programming Language UML as sketch Dari seluruh hal yang ada pada UML, hanya 20% saja yang akan terpakai dalam 80% effort analysis, design dan development. Kuncinya adalah selektivitas. Pilih notasi / diagram UML yang anda butuhkan saja. Gambarkan juga UML untuk hal yang menjadi fokus perhatian pada suatu saat tertentu. Tidak perlu semuanya. Dengan demikian, UML dapat anda gambar dengan pensil diatas kertas. Dengan spidol pada whiteboard. Gambarkan diagram UML di whiteboard, diskusikan bersama team development, begitu ide development di dapat, langsung coding. Intinya, UML digunakan sebagai media komunikasi pada saat brainstorming ide design. UML tadi bisa disimpan, tapi bisa juga dibuang. Terserah anda. Jika anda memakai drawing

Dia belum layak disebut sebagai CASE tool.NET. anda dapat menyimpan UML tadi sebagai dokumen. Tentu saja. UML as Blueprint Jika anda membangun gedung pencakar langit atau jembatan. Sekarang ini saya pakai Visio Enterprise Architect 2003. Visio men-support forward engineering. Visio yang ada sekarang menggunakan UML versi 1. CASE tool yang harus men-support Round-trip Engineering. Intinya. Dengan CASE tool. anda tidak dapat melakukan update terhadap UML design ini dan mengharapkan code anda tadi juga terupdate. Yang paling terkenal adalah dari Rational (sekarang IBM Rational). Ada banyak CASE tool di pasaran. anda dapat menggunakan the code as the documentation of the system. selengkaplengkapnya. design dilempar ke kuli bangunan yang akan diawasi para mandor. Kita bisa membuat skeleton code dari UML design kita. UML as blueprint is the way to go. Visio masih termasuk kategori Drawing tool untuk menggambar UML. Interesting. pasti ada arsitek dan insinyur sipil yang akan menggambar dan mengkalkulasikan semua design.tools seperti Visio. anda mendapatkan model UML baru (bukan yang pertama anda pakai tadi). jika code harus berubah. logikanya.4. UML yang digunakan harus sedetail-detailnya. Architect/senior devs membuat UML-nya. pada skala project yang besar. Jika anda tidak punya CASE tool. lalu developer menulis code berdasarkan design tersebut. Nah. Saya adalah penganut aliran UML as sketch ini. UMLdapat digunakan sebagai blueprint seperti halnya design bangunan atau jembatan. pada banyak kasus. Code hasil generate dari Visio. kadang-kadang pakai Visio juga. Lalu dari model yang baru anda dapat ini. design bisa berubah mengikuti kebutuhan bisnis. Microsoft support untuk UML Sebagai permulaan. Saya pernah punya sedikit pengalaman dengan Rational XDE for Microsoft . pada skeleton code inilah developer menambah baris-baris code untuk melengkapi skeleton code tadi. Tapi« harganya tidak ada yang murah. Bikin capek! Syukur kalau ada waktu untuk melakukannya. Sayangnya. saya akan bicara tool Microsoft untuk UML yaitu Visio. Tapi. O ya. OMG (yang bertugas memaintain UML) merilis UML versi 2. Visio tidak bisa Round-trip engineering.0. dengan development team yang terpisah. Jika anda ingin menggunakan UML versi 2. blueprint juga harus berubah. Sebaliknya. Problemnya. Yeah. Setelah design jadi. Tetapi. Konsekuensinya. jika anda tidak punya barang-barang mewah seperti CASE tool ini. pada project skala besar anda pasti menggunakan CASE tool (Computer Aided Software Engineering). tetapi memilih menggunakan UML as blueprint« you just dig your own grave!!! UML as Programming Language Yang satu ini menggunakan UML lebih jauh lagi. UML tool favorit saya adalah spidol dan whiteboards. selama masa development. anda perlu CASE tool yang canggih. Visio Enterprise Architect bisa melakukan Reverse Engineer dari code anda. Yang lebih menarik. jangan sekali-sekali menggunakan UML sebagai blueprint apalagi programming language. Memaintain blueprint ini bukanlah pekerjaan ringan. lalu kita reverse engineer. kita bisa mendapatkan UML (class diagram) dari code kita dengan fasilitas reverse engineering. CASE tool juga tampaknya tidak terlalu sukses di pasar. lalu dengan UML tadi di-generate skeleton code secara automatis. Nah. Baru-baru ini. Visio tidak mensupport round-trip engineering.0 . Untuk melakukan ini. jika kita update. O ya. maintenance blueprint ini akan lebih ringan. Design dilakukan dengan UML (tentu saja dengan CASE tool). UML berfungsi sebagai suatu programming language. Dari kenyataan ini. Disini. Jadi.

dsb..html Tentang UML sendiri.. Sangat menarik untuk kita ikuti perkembangannya.phruby. ada stencil untuk Visio yang bisa anda download di :http://www. kita stick dulu di UML. Microsoft melihatnya bahwa UML bukan satu-satunya modeling language. Microsoft sedang memulai inisiatif DSL (Domain Specific Language).he.dan sebagainya« Kembali ke alinea pertama« ada yang lebih penting dari UML atau apapun juga modeling language lainnya« OOAD! UML itu Cuma gambar. Dan sebagainya. bisa kita pakai di production). . Apakah DSL bisa diterima komunitas development. maksudnya.com/stencildownload.. Lalu ada lagi inisiatif Software Factories. Tetapi sebelum semua ini jadi kenyataan (he. Kita juga lihat apakah DSL ini akan bisa ³menggantikan´ UML.ini.

dan makna yang sama. Dua objek dapat berbeda walaupun bila semua nilai atributnya identik. Objek dapat kongkrit. Macam-macam Objek 2. y y y Suatu kegiatan mengumpulkan data (atribut) dan perilaku (operasi) yang mempunyai struktur data sama ke dalam satu grup. Karakteristik dari Objek 1. Dapat digunakan untuk menciptakan Objek. Objek y y y Objek adalah benda secara fisik dan konseptual yang ada di sekitar kita. metode. Kelas Objek merupakan wadah bagi Objek. Objek mewakili fakta/keterangan dari sebuah kelas. seperti halnya arsip dalam sistem. Sebuah objek memiliki keadaan sesaat yang disebut state. atau konseptual seperti kebijakan penjadwalan dalam multiprocessing pada sistem operasi. Pengertian dan Konsep OOAD A. hubungan. 11 April 2010 I. operasi. .Konsep OOAD Diposkan oleh Hendra Divayana on Minggu. Gambar 1. Kelas Objek Kelas merupakan gambaran sekumpulan Objek yang terbagi dalam atribut.

. kecuali prosedur yang berada dalam objek itu sendiri. Encapsulation (Pengkapsulan) y y y Encapsulation merupakan dasar untuk pembatasan ruang lingkup program terhadap data yang diproses. Inheritance mempunyai arti bahwa atribut dan operasi yang dimiliki bersama di anatara kelas yang mempunyai hubungan secara hirarki. Data terlindung dari prosedur atau objek lain. sehingga prosedur atau fungsi lain dari luar tidak dapat mengaksesnya. Suatu kelas dapat ditentukan secara umum. Data dan prosedur atau fungsi dikemas bersama-sama dalam suatu objek. Atribut dan metode dari objek dari objek induk diturunkan kepada anak objek. demikian seterusnya. Karakteritik Metodologi Berorientasi Objek Metodologi pengembangan sistem berorientasi objek mempunyai tiga karakteristik utama : 1. dan ditambah dengan sifat unik yang dimilikinya. 3. 2. Polymorphism (Polimorfisme) y Polimorfisme yaitu konsep yang menyatakan bahwa seuatu yang sama dapat mempunyai bentuk dan perilaku berbeda. Kelas dan Objek B.Gambar 2. Inheritance menggambarkan generalisasi sebuah kelas. Inheritance (Pewarisan) y y y y y y Inheritance adalah teknik yang menyatakan bahwa anak dari objek akan mewarisi data/atribut dan metode dari induknya langsung. kemudian ditentukan spesifik menjadi subkelas. Setiap subkelas mempunyai hubungan atau mewarisi semua sifat yang dimiliki oleh kelas induknya. Kelas Objek dapat didefinisikan atribut dan service dari kelas Objek lainnya.

proses adalah objek. Contoh : Orang. Pemodelan Berorientasi Objek B. perilaku umum (operasi). dan mungkin pekerjaan. Seleksi dari metode yang sesuai bergantung pada kelas yang seharusnya menciptakan Objek. prioritas. > Kelas y y y y Suatu object class menggambarkan kumpulan dari objek yang mempunyai sifat (atribut). dan dilengkapi dengan penyajian grafis dari sistem yang sangat bermanfaat untuk komunikasi dengan user dan pembuatan dokumentasi struktur dari sistem. binatang. dan object class untuk menunjukkan satu grup dari barang yang sama. Objek dan object class sering sama sebagai benda dalam deskripsi masalah. Setiap proses mempunyai pemilik. II. tetapi merupakan dua orang yang berbeda. Kadang-kadang objek berarti suatu barang. Contohnya : kembar identik. abstraksi atau benda dengan batasan dan arti untuk suatu masalah. Model berorientasi objek lebih mendekati keadaan nyata. perusahaan . Model Berorientasi Objek Sebuah model objek menangkap struktur statis dari sistem dengan menggambarkan objek dalam sistem. Objek dan Kelas > Objek y y y y y Objek didefinisikan sebagai konsep. Semua objek mempunyai identitas yang berbeda dengan lainnya. list dari sumber daya yang dibutuhkan. Kemampuan objek-objek yang berbeda untuk melakukan metode yang pantas dalam merespon message yang sama. Istilah identitas berarti bahwa objek dibedakan oleh sifat yang melekat dan bukan dengan uraian sifat yang dimilikinya. walaupun mereka nampak seperti sama. Diagram Objek . IQ. 1. serta atribut dan operasi yang merupakan karakteristik setiap kelas dan objek. relasi umum dengan objek lain dan semantik umum. 2. Setiap orang mempunyai umur. hubungan antara objek.y y y Polimorfisme mempunyai arti bahwa operasi yang sama mungkin mempunyai perbedaan dalam kelas yang berbeda. maka digunakan istilah object instance.

Nama dari kelas-&-objek harus dapat menjelaskan objek tunggal dari suatu kelas. y Whole-Part Structure memperlihatkan hirarki dari suatu kelas sebagai komponen dari kelas lain yang disebut juga sub objek. Part n. Gambar 3. atau kata sifat dan kata benda. Notasi untuk kelas dan kelas-&-objek > Struktur Objek dan Hirarki Kelas . > Kelas dan Objek Konsep fundamental dalam analisis berorientasi objek adalah objek itu sendiri. merupakan Part1. Part 2. . dan lain-lain. Nama kelas adalah kata benda tunggal. Diagram objek bermanfaat untuk pemodelan abstrak dan membuat perancangan program. yaitu Whole-Part Structure dan Gen-Spec Structure. Kelas merupakan satu atau lebih objek dengan persamaan atribut dan metode. kelas Mobil adalah Whole dan komponennya Mesin. Sebuah objek adalah sebuah entitas yang mencakup data dan metode. kelas dan relasinya dengan yang lain. sedangkan kelas&-objek adalah kelas dengan satu atau lebih objek di dalamnya. . Rangka. Contohnya.Struktur kelas dibagi dua macam.Diagram objek melengkapi notasi grafik untuk pemodelan objek.

Truk. dan lain-lain merupakan Specizlization1. Superclass atau Topclass. Specialization2. Minibus. Gambar 5. Notasi untuk gen-spec structure Contohnya.Atribut . sedangkan kelas yang mempunyai sifat khusus disebut Specialization. . . Kelas yang mempunyai sifat umum disebut Generalization.Gambar 4. sedangkan Sedan. Notasi untuk whole-part structure y Gen-Spec Structure memperlihatkan kelas sebagai spesialisasi dari kelas di atasnya. Specialization n. yaitu kelas yang mempunyai sifat khusus. kelas Mobil adalah Generalization.

Notasi untuk metode Pesan (Message) Message merupakan cara untuk berhubungan antara satu objek dengan objek lain. Gambar 6. Notasi untuk atribut .Metode Metode (method) disebut juga service atau operator adalah prosedur atau fungsi seperti yang terdapat dalam bahasa Pascal pada umumnya. Metode dipergunakan untuk pengaksesan terhadap data yang terdapat dalam objek tersebut. Metode adalah subprogram yang tergabung dalam objek bersama-sama dengan atribut. Gambar 7. Suatu pesan dikirimkan oleh suatu objek kepada objek tertentu dapat digambarkan dengan anak panah.Atribut menggambarkan data yang dapat memberikan informasi mengenai kelas atau objek dimana atribut tersebut berada. . tetapi cara kerjanya agak berlainan.

Diantaranya adalah: metodologi booch. dsb. metodologi wirfs-brock. UML menawarkan sebuah standar untuk merancang model sebuah sistem. yang mengakibatkan timbul masalah baru apabila kita bekerjasama dengan group/perusahaan lain yang menggunakan metodologi yang berlainan. dan Ivar Jacobson OOSE (Object-Oriented Software Engineering). Dengan menggunakan UML kita dapat membuat model untuk semua jenis aplikasi piranti lunak. Sampai era tahun 1990 seperti kita ketahui puluhan metodologi pemodelan berorientasi objek telah bermunculan di dunia. Masing-masing metodologi membawa notasi sendiri-sendiri.Gambar 8. 2010 admin 1 comment . Walaupun demikian. Jim Rumbaugh OMT (Object Modeling Technique).NET. dan UML syntax mendefinisikan bagaimana bentuk-bentuk tersebut dapat dikombinasikan. merancang dan mendokumentasikan sistem piranti lunak. maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa bahasa berorientasi objek seperti C++. Notasi untuk message III. UML (Unified Modelling Language) Unified Modelling Language (UML) adalah sebuah ³bahasa´ yg telah menjadi standar dalam industri untuk visualisasi. metodologi OMT. UML mendefinisikan notasi dan syntax /semantik. Notasi UML merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti lunak. Notasi UML terutama diturunkan dari 3 notasi yang telah ada sebelumnya: Grady Booch OOD (Object-Oriented Design). metodologi coad. serta ditulis dalam bahasa pemrograman apapun. Masa itu terkenal dengan masa perang metodologi (method war) dalam pendesainan berorientasi objek. sistem operasi dan jaringan apapun. C# atau VB. Setiap bentuk memiliki makna tertentu. metodologi OOSE. UML tetap dapat digunakan untuk modeling aplikasi prosedural dalam VB atau C. Tetapi karena UML juga menggunakan class dan operation dalam konsep dasarnya. metodologi shlaer-mellor. Java. Sejarah UML sendiri cukup panjang. Apa itu UML mas Arief? April 21. Seperti bahasa-bahasa lainnya. dimana aplikasi tersebut dapat berjalan pada piranti keras.

Use case view Mendeskripsikan fungsionalitas sistem yang seharusnya dilakukan sesuai yang diinginkan external actors. View ini digunakan untuk perancang (designer) dan pengembang (developer).View ini digambarkan dalam diagram dinamis (state. d. View bukan melihat grafik. sequence. model element. object. dan activity diagrams) dan diagram implementasi . View ini digambarkan dalam component view dan digunakan untuk pengembang (developer). b. Actor yang berinteraksi dengan sistem dapat berupa user atau sistem lainnya. c. collaboration. diagram. View View digunakan untuk melihat sistem yang dimodelkan dari beberapa aspek yang berbeda. struktur statis (class. perancang (designer).danrelationship ) dan kolaborasi dinamis yang terjadi ketika object mengirim pesan ke object lain dalam suatu fungsi tertentu. Component view Mendeskripsikan implementasi dan ketergantungan modul. concurrency view. dan general mechanism. component view. tapi merupakan suatu abstraksi yang berisi sejumlah diagram. collaboration. pengembang (developer). Logical view Mendeskripsikan bagaimana fungsionalitas dari sistem. sequence. Viewini digunakan terutama untuk pelanggan. a. dan activity diagram untuk model dinamisnya. View ini digambarkan dalam use case diagramsdan kadang-kadang dengan activity diagrams.dan deployment view. Concurrency view Membagi sistem ke dalam proses dan prosesor. e. dan penguji sistem (tester). View ini digambarkan dalam class diagrams untuk struktur statis dan dalam state.BAGIAN-BAGIAN UML Bagian-bagian utama dari UML adalah view. Komponen yang merupakan tipe lainnya dari code module diperlihatkan dengan struktur dan ketergantungannya juga alokasi sumber daya komponen dan informasi administrative lainnya. Beberapa jenis view dalam UML antara lain: use case view. logical view.

Class diagram sangat membantu dalam visualisasi struktur kelas dari suatu system. g. Sebuah komponent berisi informasi tentang logic class atau class yang diimplementasikan sehingga membuat pemetaan dari logical view ke component view. Use Case Diagram Use case adalah abstraksi dari interaksi antara system dan actor.class yang ada dan relasinya satu dengan yang lainnya. Deployment view Mendeskripsikan fisik dari sistem seperti komputer dan perangkat (nodes) dan bagaimana hubungannya dengan lainnya. karena menetap di komputer tidak berada di benak para analis.Sehingga component diagram merepresentasikan dunia riil yaitu component software yang mengandung component. perilaku (operasi) dan relasi yang sama. pengintegrasi (integrator). Sebuah sistem biasanya mempunyai beberapa class diagram. komponent biner. Sedangkan use case diagram memfasilitasi komunikasi diantara analis dan pengguna serta antara analis dan client. f. Sebuah diagram merupakan bagian dari suatu view tertentu dan ketika digambarkan biasanya dialokasikan untuk view tertentu. dan penguji (tester). interface dan relationship. dan penguji (tester). Diagram Diagram berbentuk grafik yang menunjukkan simbol elemen model yang disusun untuk mengilustrasikan bagian atau aspek tertentu dari sistem. 3. atau executable component. View ini digambarkan dalam deployment diagramsdan (developer). 4. Hal tersebut tercermin dari class. Component Diagram Component software merupakan bagian fisik dari sebuah system. Adapun jenis diagram antara lain : 1. Use casemerupakan konstruksi untuk mendeskripsikan bagaimana system akan terlihat di mata user. 2. Deployment Diagram digunakan untuk pengembang . Sehingga dengan adanya class diagram dapat memberikan pandangan global atas sebuah system. Use case bekerja dengan cara mendeskripsikan tipe interaksi antara user sebuah system dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah system dipakai. Komponent merupakan implementasi software dari sebuah atau lebih class. pengintegrasi (integrator).(component dan deployment diagrams) serta digunakan untuk pengembang (developer). Class Diagram Class adalah dekripsi kelompok obyek-obyek dengan property. Komponent dapat berupa source code.

Memberikan bahasa pemodelan yang bebas dari berbagai bahas pemrograman dan proses rekayasa. Kejadian dapat berupa object lain yang mengirim pesan. 8. tapi jika penekanannya pada konteks gunakan collaboration diagram.Menggambarkan tata letak sebuah system secara fisik. State class tidak digambarkan untuk semua class. Dengan cetak biru ini maka akan bias diketahui informasi secara detail tentang coding program atau bahkan membaca program dan menginterpretasikan kembali ke dalam bentuk diagram (reserve enginering). UML bisa juga berfungsi sebagai sebuah (blue print) cetak biru karena sangat lengkap dan detail. Kegunaannya untuk menunjukkan rangkaian pesan yang dikirim antara object juga interaksi antaraobject. State Diagram Menggambarkan semua state (kondisi) yang dimiliki oleh suatu object dari suatu class dan keadaan yang menyebabkan state berubah. Sequence Diagram Sequence Diagram digunakan untuk menggambarkan perilaku pada sebuah scenario. Jika penekannya pada waktu atau urutan gunakansequencediagrams. Di dalam nodes. 5. 7. Menyatukan praktek-praktek terbaik yang terdapat dalam pemodelan. bahsa pemodelan visual yang ekspresif untuk mengembangkan dan saling menukar model dengan mudah dan dimengerti secara umum. digunakan untuk mendeskripsikan aktifitas yang dibentuk dalam suatu operasi sehingga dapat juga digunakan untuk aktifitas lainnya seperti use caseatau interaksi. 4. menunjukkan hubungan komputer dengan perangkat (nodes) satu sama lain dan jenis hubungannya. Activity Diagram Menggambarkan rangkaian aliran dari aktivitas. 3. collaboration diagrams menggambarkan objectdan hubungannya (mengacu ke konteks). sesuatu yang terjadi pada titik tertentu dalam eksekusi sistem. Collaboration Diagram Menggambarkan kolaborasi dinamis sepertisequence diagrams. Tujuan Penggunaan UML 1. Memberikan model yang siap pakai. Dalam menunjukkan pertukaran pesan. . menampakkan bagian-bagian software yang berjalan pada bagian-bagian hardware. 2. 6. hanya yang mempunyai sejumlah state yang terdefinisi dengan baik dan kondisi class berubah oleh stateyang berbeda.executeable component dan object yang dialokasikan untuk memperlihatkan unit perangkat lunak yang dieksekusi oleh node tertentu dan ketergantungan komponen.

termasuk faktor-faktor seperti scalability. Dengan menggunakan model. metodologi shlaer-mellor [5]. agar bug mudah ditemukan dan diperbaiki. Sampai era tahun 1990 seperti kita ketahui puluhan metodologi pemodelan berorientasi objek telah bermunculan di dunia. robustness. UML tetap dapat digunakan untuk modeling aplikasi prosedural dalam VB atau C. Tetapi karena UML juga menggunakan class dan operation dalam konsep dasarnya. sehingga tidak bisa lagi dibuat asalasalan. Seperti bahasa-bahasa lainnya. Notasi UML terutama diturunkan dari 3 notasi yang telah ada sebelumnya: Grady Booch OOD (Object-Oriented Design). Notasi UML merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti lunak. Jim Rumbaugh OMT (Object Modeling Technique). metodologi OOSE [3]. UML mendefinisikan notasi dan syntax /semantik. Membuat model dari sebuah sistem yang kompleks sangatlah penting karena kita tidak dapat memahami sistem semacam itu secara menyeluruh. Piranti lunak saat ini seharusnya dirancang dengan memperhatikan hal-hal seperti scalability . metodologi wirfs- . Sejarah UML sendiri cukup panjang. Ketiga unsur tersebut adalah metode pemodelan ( notation ). Walaupun demikian. merancang dan mendokumentasikan sistem piranti lunak. security .NET. Apa itu UML Unified Modelling Language (UML) adalah sebuah ³bahasa´ yg telah menjadi standar dalam industri untuk visualisasi. serta ditulis dalam bahasa pemrograman apapun. Java. Kesuksesan suatu pemodelan piranti lunak ditentukan oleh tiga unsur. Memahami notasi pemodelan tanpa mengetahui cara pemakaian yang sebenarnya (proses) akan membuat proyek gagal. diharapkan pengembangan piranti lunak dapat memenuhi semua kebutuhan pengguna dengan lengkap dan tepat. metodologi OMT [4]. maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa bahasa berorientasi objek seperti C++. bahkan oleh orang lain selain programmer aslinya. Diantaranya adalah: metodologi booch [1]. sistem operasi dan jaringan apapun. dimana aplikasi tersebut dapat berjalan pada piranti keras. Setiap bentuk memiliki makna tertentu. semakin penting pula penggunaan teknik pemodelan yang baik. dan eksekusi yang robust walaupun dalam kondisi yang sulit. dan sebagainya. UML menawarkan sebuah standar untuk merancang model sebuah sistem. security . proses ( process ) dan tool yang digunakan. metodologi coad [2]. Model piranti lunak dapat dianalogikan seperti pembuatan blueprint pada pembangunan gedung. Pemodelan ( modeling ) adalah proses merancang piranti lunak sebelum melakukan pengkodean ( coding ). Keuntungan lain dari perencanaan arsitektur yang matang adalah dimungkinkannya penggunaan kembali modul atau komponen untuk aplikasi piranti lunak lain yang membutuhkan fungsionalitas yang sama. Dan pemahaman terhadap metode pemodelan dan proses disempurnakan dengan penggunaan tool yang tepat. dan UML syntax mendefinisikan bagaimana bentuk-bentuk tersebut dapat dikombinasikan.Pengantar Unified Modelliing Language (UML) Pendahuluan Saat ini piranti lunak semakin luas dan besar lingkupnya. dan Ivar Jacobson OOSE (Object-Oriented Software Engineering). Selain itu arsitekturnya harus didefinisikan dengan jelas. C# atau VB. yang kemudian terkenal dengan sebuan segitiga sukses ( the triangle for success ). Semakin komplek sebuah sistem. Dengan menggunakan UML kita dapat membuat model untuk semua jenis aplikasi piranti lunak.

realization. generalization. join interaction. sequence diagram activation interaction view colaborating collaborating.8). dynamic behavior . Masing-masing metodologi membawa notasi sendiri-sendiri. stereotype. Rumbaugh dan Jacobson menyusun tiga buku serial tentang UML pada tahun 1999 [7] [8] [9]. Masa itu terkenal dengan masa perang metodologi ( method war ) dalam pendesainan berorientasi objek. Rumbaugh dan Jacobson. Sebenarnya konsepsi dasar UML bisa kita rangkumkan dalam gambar dibawah. dsb. Main concepts bisa kita pandang sebagai term yang akan muncul pada saat kita Major Area View static view Diagrams class diagram . fork.1 muncul. structural dependency. interface.org). action state. view diagram dependency. Sejak tahun 1996 pengembangan tersebut dikoordinasikan oleh Object Management Group (OMG ± http://www. completion actifity view activity diagram transition. actor. interface use case view use case diagram use case. transition. Booch. include. diagram collaboration rule. use case generalization implementation component component. tagged values extensibility all all Abstraksi konsep dasar UML yang terdiri dari structural classification . extend. dan model management .brock [6].5 yang dirilis bulan Maret 2003. realization dynamic statechart diagram state machine view state. interaction. event. message model model management management view class diagram package. bisa kita pahami dengan mudah apabila kita melihat gambar diatas dari Diagrams . Dimulai pada bulan Oktober 1994 Booch. Tahun 1997 UML versi 1. association. Sejak saat itulah UML telah menjelma menjadi standar bahasa pemodelan untuk aplikasi berorientasi objek. Main Concepts class. yang mengakibatkan timbul masalah baru apabila kita bekerjasama dengan group/perusahaan lain yang menggunakan metodologi yang berlainan. model constraint. message. activity. yang merupakan tiga tokoh yang boleh dikata metodologinya banyak digunakan mempelopori usaha untuk penyatuan metodologi pendesainan berorientasi objek. Pada tahun 1995 direlease draft pertama dari UML (versi 0. Konsepsi Dasar UML Dari berbagai penjelasan rumit yang terdapat di dokumen dan buku-buku UML. subsystem. object. dan saat ini versi terbaru adalah versi 1. association.omg.

. sebenarnya cukup dua hal yang harus kita perhatikan: 1. Lalu darimana kita mulai ? Untuk menguasai UML.membuat diagram. Menguasai langkah-langkah dalam analisa dan pengembangan dengan UML Tulisan ini pada intinya akan mengupas kedua hal tersebut. Dan view adalah kategori dari diagaram tersebut. Menguasai pembuatan diagram UML 2.

Kebanyakan orang salah. UML juga bukanlah Unified Marxist-Leninists. yang memungkinkan kita bisa bertanya tentang model tersebut dan akan kita dapatkan jawaban yang memuaskan. suatu partai politik di Nepal. Pemodelan (modelling) memungkinkan para pengembang bisa berkonsentrasi pada gambaran yang luas. dimana UML tidak diperuntukkan agar bisa membuat model bagi apa saja (contoh. UML adalah Unified Modelling Language. UML membantu kita melihat dan menyelesaikan masalah-masalah yang sering terjadi. UML merupakan standardized modelling language yang terdiri dari kumpulan-kumpulan diagram. dan juga dapat saling membantu dengan mengajari orang lain. UML bukanlah Universal Modelling Language. UML tidak terlalu baik untuk memodelkan persediaan pasar). Ketika kita membuat model. Hal pertama yang perlu kita ketahui adalah apa sebenarnya UML?. Yang lebih penting adalah. Kita bisa menggunakan model kita untuk meminta bantuan dari orang lain yang akan meningkatkan kerja kita. . Di atas mungkin bukanlah bagian terpenting yang perlu diketahui.UML adalahDitulis Oleh : Grenalio Kristian PerdanaApa itu UML? Intoducing UML. dikembangkan untuk membantu para pengembang sistem dan software agar bisa menyelesaikan tugastugas seperti: Spesifikasi Visualisasi Desain Arsitektur Konstruksi Simulasi dan testing Dokumentasi UML dikembangkan sebagai ide dasar untuk mempromosikan hubungan dan produktifitas antara para pengembang dari object-oriented system. kita bisa menggunakan model kita bersama dengan orang lain. kita membuat suatu abstraksi dari sistem nyata yang sudah ada. Setelah kita puas dengan hasil kerja kita. Memahami kemampuan UML UML memuaskan kebutuhan yang penting dalam pengembangan software dan sistem.

ada apa disana? Behavioral Diagram: kita menggunakan behavioral diagram untuk menampilkan bagaimana sistem kita merespon permintaan atau apa saja seiring waktu. Setiap diagram UML yang kita gambar memiliki keterkaitan dengan dunia nyata. Diagram ini menjawab pertanyaan.Abstracting Teknik dalam membuat model dari ide kita atau dunia nyata adalah dengan menggunakan abstraction. 2. Abstraction model dan diagram juga berguna karena akan menjelaskan lebih rinci detail-detail yang dibutuhkan (kita tidak perlu mengambar pohon dan mobil dan orang dalam map kita. Structural diagram (Class diagram) : Digunakan untuk menampilkan entiti dunia nyata. elemen dari analisa dan desain. Abstraction dikembangkan sebagai ketentuan untuk dipelajari dan sering digunakan. Sebagai contoh. Jika kita berpikir UML sebagai map dari dunia yang kita lihat. 1. atau implementasi class dan relasinya. karena map kita akan menjadi susah alias tidak praktis untuk dipakai). Structural diagram (Deployment diagram) : Digunakan untuk menampilkan arsitektur run-time dari . Sering digunakan untuk mengindikasikan kondisi dari suatu even. hampir mendekati. Structural diagram (Composite structure diagram) : Digunakan untuk menampilkan bagaimana sesuatu itu dibuat. Kita menggunakan interaction diagram untuk melukiskan perubahan dari pesan-pesan dalam suatu kolaborasi (kumpulan dari object-object yang sama) sehingga tujuan bisa tercapai. Kategori diagram UML Structural Diagram: kita menggunakan structural diagram untuk menampilkan blok bangunanan dari sistem kita merupakan fitur yang tidak berubah bersama waktu. Analogi yang lebih mendekati adalah merupakan kumpulan dari blueprint yang menampilkan detail yang cukup dari suatu bangunan untuk memastikan tentang apa sebenarnya bangunan tersebut. Structural diagram (Object diagram) : Digunakan untuk menampilkan suatu contoh spesifik atau ilustrasi dari suatu object serta link nya. 3. Interaction diagram: merupakan tipe dari behavioral diagram. seperti percobaan atau operasi pemanggilan. map merupakan model dunia bukanlah miniatur dunia.

Karena UML sangatlah fleksibel. 6. Structural diagram (Package diagram) : Digunakan untuk mengorganisir elemen model dan menampilkan ketergantungan antara mereka. kerangka hardware. Kategori ini hampir sama dengan structural diagram. . 10. 5. Pohon kategori di bawah ini cukup terkenal: Static diagram: Menampilkan fitur statis dari sistem. 11. Behavioral diagram (Use case diagram) : Digunakan untuk menampilkan layanan yang bisa diminta oleh actor dari sistem kita. 8. Structural diagram (Component diagram) : Digunakan untuk menampilkan organisasi dan hubungan antar sistem. Behavioral diagram (Activity diagram) : Digunakan untuk menampilkan arus data dari kebiasaan antar object.suatu sistem. ruang lingkup software. Dynamic diagram: Menampilkan bagaimana proses perubahan yang terjadi dalam sistem sepanjang waktu. dan sebagainya. kita akan menjumpai berbagai cara dalam meng-kategorikan diagram kita. Interaction diagram (Communication diagram) : Digunakan untuk fokus pada perubahan pesan antara grup dari suatu object dan relasi dari object-object tersebut. 4. Behavioral diagram (State machine diagram / Protocol state machine diagram) : Digunakan untuk menampilkan urutan proses dari suatu object dan kondisinya saat ini. 12. Interaction diagram (Overview diagram) : Digunakan untuk menampilkan banyak skenario interaksi (urutan dari kebiasaan) bagi suatu kolaborasi (kumpulan elemen yang sama dan saling bekerja agar tercapai tujuan yang diinginkan). Interaction diagram (Timing diagram) : Digunakan untuk menampilkan perubahan dan hubungan terhadap waktu nyata atau terhadap proses sistem. Kategori ini mencakup UML state-machine diagram dan timing diagram. Interaction diagram (Sequence diagram) : Digunakan untuk fokus pada perubahan pesan antara grup dari suatu object dan urutan pesan tersebut. 9. 7.

Designer: Designer mencoba mencari solusi yang memungkinkan. Implementer: Implementer membangun solusi menggunakan UML sebagai bagian dari tujuan implementasi. Ada banyak kerangka modelling. seperti kode aplikasi atau user interface. Siapa yang memerlukan UML? Para pengguna UML dibagi dalam kategori: Modeler: Modeler mencoba menjelaskan dunia nyata seperti bagaimana mereka melihatnya. Kategori ini mencakup use case. Dimana lokasi komponen dalam suatu sistem? Mengindikasikan rencana kita untuk menentukan lokasi suatu komponen. Kapan kejadian penting terjadi? Menampilkan apa yang menyebabkan object kita bisa bereaksi dan mulai melakukan kerjanya dengan state diagram dan interaction diagram. untuk dibandingkan atau menentukan proses pada aspek yang berbeda. . dan activity diagram. Berikut pertanyaan standar tentang sistem : Siapa yang menggunakan sistem? Menampilkan actor (pengguna sistem) dalam diagram use case(menampilkan tujuan sistem) Dari mana sistem dibuat? Menggambarkan diagram Class untuk menampilkan struktur logis dan component diagram agar bisa menampilkan struktur fisik. interaction. Kebanyakan program UML sekarang sudah bisa membuat sendiri definisi dari suatu Class atau Database. seperti Zachman atau DODAF. Bagaimana sistem ini bekerja? Menampilkan bagian struktur diagram dan menggunakan communication diagram untuk menampilkkan interaksi. Kita bisa mengembangkan diagram UML untuk menampilkan informasi yang berbeda pada waktu yang berbeda atau untuk tujuan yang berbeda.Functional diagram: Menampilkan detail dari proses dan algoritma.

Lagi-lagi software ini juga harus merogoh kocek agak dalam. bagi yang hanya ingin mencoba With Class menyediakan versi Trial. kalau ini spesialis UML di sistem operasi LINUX. DIA Nah. Hal yang mungkin kurang saya gemari adalah Relational Rose memberikan patokan runtutan dalam menganalisa.Software Apa yang Nyaman Untuk UML. Berbagai pengembang software berlomba membuat sebuah tool yang dapat merancang permodelan sistem dengan UML. Cara pandangnya yang berorientasi objek menjadikan UML sebagai sebuah permodelan sistem yang sesuai dengan era pemrograman komputer saat ini. DIA merupakan software untuk menggambar diagram. Umbrello Nah. Umbrello juga lengkap untuk membuat permodelan diagram-diagram UML. yang termasuk diantaranya adalah UML Plugin. Ehm«. So. Walaupun bukan spesialis UML. mungkin karena kemudahannya dan berjalan di Microsoft Windows sehingga tool ini menjadi favourite. Eh« jadi paten dech« nggak bisa ngembangin kreatifitas. Selain ringan dalam pemakaian. Dari yang bersifat gratis sampai yang harus membayar segudang rupiah telah ada menanti kita. tapi berat banget loadingnya«. tetapi DIA telah menyediakan plugin UML yang dapat kita gunakan free. seperti biasa tinggal kita sendiri yang menentukan software mana yang mau kita jadikan tool favourite untuk UML. Apalagi runningnya yang tergolong ringan patut untuk kita perhitungkan sebagai tool permodelan dengan UML. Emmmmm« bagus sich. Lumayan kalau jatah analisa kita 1 bulan kan pas«! UML Plugin di NetBeans IDE Seperti biasa NetBeans IDE yang didukung oleh Sun Microsystem mempunyai banyak sekali plugin. kalau ini biasanya jalan di sistem operasi LINUX. Em« walaupun . Relational Rose telah memiliki banyak sekali fitur untuk permodelan UML yang terkandang malah membingungkan pengguna. Namun. selain itu kemudahannya untuk dimengerti oleh kalangan yang belum mengenal analisa dan perancangan sistem juga menjadikan UML sebagai sebuah terobosan baru.? UML saat ini lagi ngetren digunakan untuk analisa maupun rekayasa perangkat lunak. Cara pandangnya yang tidak harus pakem seperti pada permodelan pemrograman terstruktur menjadikan UML turut lebih diminati. With Class Walaupun namanya tidak sepopuler Relational Rose namun With Class juga merupakan software permodelan UML yang menarik.. apalagi kalau dipasang pada komputer pas-pasan « minta ampun dech« Tapi lumayan powerfull karena selain include dengan NetBeans yang so pasti dekat dengan JAVA. UML memberikan kemudahan dalam melakukan analisa suatu sistem. Dari beberapa software untuk melakukan permodelan diantaranya adalah : Relational Rose Mungkin tool ini yang sangat sering kita dengan sebagai software untuk perancangan dengan model UML.

namun Umbrello dapat menjadi pilihan yang tepat.belum selengkap Relational Rose. . Apalagi kita ndak lagi dikekang harus dengan metode seperti apa dalam merancang sebuah sistem.

USE CASE sendiri mendeskripsikan sistem. Perilaku sistem ini dicapture di dalam USE CASE. sebuah use case digambarkan dengan sebuah ellips dengan garis penuh. Perilaku ini merupakan aktifitas sistem yang bisa dilihat dari luar dan bisa diuji. yang akan secara bersama-sama. memproduksi hasil yang dibutuhkan oleh pengguna sistem. Defenisi Use Case y Deskripsi dari sekumpulan aksi sekuensial yang ditampilkan sistem yang menghasilkan yang tampak dari nilai ke actor khusus. Use case direalisasikan dengan sebuah collaboration. Setiap skenario digambarkan dari sudut pandang ³aktor´. Sekelompok skenario pengguna yang menggambarkan alur penggunaan sistem. lingkungan sistem. Contoh sederhana: Konsumen pesan tiket pesawat .Pengertian USE CASE Deskripsi singkat tentang USE CASE y y Perilaku sistem adalah bagaimana sistem beraksi dan bereaksi. Secara gambar. Use Case mendefinisikan alur proses sepanjang sistem berbasis pada kegunaan sebagaimana yang biasa dilakukan (secara manual). seseorang atau piranti yang berinteraksi dengan perangkat lunak dalam berbagai cara. Use Case digunakan untuk menyusun behavioral things dalam sebuah model. biasanya termasuk hanya namanya. serta hubungan antara sistem dengan lingkungannya. Suatu Use Case adalah suatu sekuensial aksi yang dilakukan oleh sistem. seperti gambar berikut : y y y y Representasi atau model yang digunakan dalam Rekayasa Perangkat Lunak untuk menggambarkan fungsional requirement suatu sistem.

Include Keterhubungan secara include antar use case menunjukkan bahwa use case asal secara eksplisit . memvalidasikan arsitektur sistem. menggambarkan kebutuhan sistem.Contoh lebih lengkap: Use Case pada Sistem Rumah Sakit Kegunaan Use Case adalah untuk menspesifikasikan konteks sistem. menjalankan implementasi dan meng-generate test case.

Hubungan perluasan digunakan untuk memodelkan bagian dari use case yang dapat dilihat oleh user sebagai perilaku yang dapat dipilih dari sistem. Manfaat Model Use Case y y y Digunakan untuk berkomunikasi dengan end user dan domain expert o Menyediakan buy-in pada tahap awal pengembangan sistem.sekumpulan dari tanggung jawab sebuah sistem diambil dan ditangkap di dalam satu tempat (included use case) .memasukkan perilaku dari use case lain yang ditunjuk oleh use case tersebut.kemudian bagian lainnya dari sistem (use case yang lain) memasukkan kumpulan tanggung jawab yang baru setiap saat mereka memerlukan fungsi-fungsi use case tersebut. o Memastikan pemahaman yang tepat tentang requirement / kebutuhan sistem. Macam-macam Use Case y y y Narative Form Bentuk teks bebas dalam format paragraph. . Included use case tidak pernah berdiri sendiri. tetapi hanya merupakan bagian dari beberapa use case yang lebih besar yang diikutinya. Keterhubungan use case secara include pada dasarnya merupakan sebuah contoh dari pendelegasian . Digunakan untuk ferifikasi o Semua requirement yang telah dicapture. Conversation Form Dialog antara actor dan sistem yang menunjukkan interaksi antar keduanya. tetapi untuk kondisi tertentu perilaku use case tersebut dapat diperluas oleh perilaku dari use case lain. o Tim pengembang memahami requirement. hubungan perluasan use case untuk memodelkan beberapa aliran yang dapat dimasukkan dalam titik tertentu. Extend Keterhubungan use case secara extend menunjukkan bahwa use case yang ditunjuk merupakan perluasan perilaku dari use case asal. Pada akhirnya. Hubungan perluasan juga dapat digunakan untuk memodelkan sub aliran yang terpisah-pisah yang hanya dapat dijalankan dalam kondisi tertentu. Use case asal dapat berdiri sendiri. o Interface yang harus dimiliki sistem. Digunakan untuk mengidentifikasi o Siapa yang berinteraksi dengan sistem dan apa yang harus dilakukan sistem. Scenerio Form Penjelasan penulisan use case dari sudut pandang actor.

Flow of events. dimana bagian lain yang telah tersedia dapat digunakan oleh use case. maka pembuatan test cases dapat dilakukan secara langsung. Postconditions. Postconditions mengidentifikasi hasil yang dapat diobservasi dan status akhir dari sistem setelah use case telah komplit. mendefinisikan kondisi-kondisi dimana use cases berakhir. yang mendefinisikan aksi pengguna dan respon sistem terhadap aksi yang dilakukan.Perbandingan Bentuk Use Case Format Penulisan Use Case Tiap Use Case memiliki: y y y y Precoditions. Jika use case tidak dalam kondisi yang baik. yang harus dipertemukan agar use cases dapat bekerja dengan sukses. yaitu: y y Jika use case dari sistem komplit. yang mendefinisikan tingkah laku umum dari sistem untuk use case. Modul Use Case Mulai dengan kondisi atau kejadian normal biasa: . Flow of events merupakan kompresi dari skenario normal. akurat dan jelas. dan cabang-cabang alternatif. Use Case dan Test Cases akan bekerja dengan baik dalam dua cara. maka pembuata test cases akan membantu dalam melakukan debug terhadap test cases.

.y y y Acuhkan pengecualian. alternatif. Menunjukkan deskripsi tujuan dari use case dan defenisi fungsionalitas tingkat tinggi. Use case harus dinamai dan perspektif pengguna sebagai kata kerja aktif. dll.

atau sistim yang lain Use Case y Types yang mewakili: behaviour. batasan apa yang akan diharapkan dari sistim o Pengertian users => types of activities performed by external entity o Sekumpulan individu dapat dianggap sebagai satu user (same role) y Actors: manusia. external hardware.Model Use Case y Model untuk melengkapi system requirements y Tahapan awal "system development": o Requirement: sistim belum terinci o Representasi: user perspektif "What the system will/should do ?" y Starting point: OO analysis & design activities y Garis besar terdiri dari: "actors" dan "use cases" Actors y Types yang mewakili: users yang berinteraksi dengan sistim y Users: di luar dari sistim. sifat / karakteristik dan fungsi sistim y Dikembangkan sesuai dengan keinginan "actor" y Dapat diterjemahkan sebagai bentuk eksekusi pemakaian sistim o Interaksi dan fungsi yang diharapkan dari sistim o Flow events response dari sistim .

Contoh : ATM Cashier Application y y Actor: Klien Bank Bagaimana interaksi dengan aplikasi di ATM ? Fasilitas apa saja yang dapat diberikan oleh Bank kepada Klien Bank y User cases: o Tarikan Uang o Deposit Uang o Transfer Antar Rekening y y Actor: apa saja yang berinteraksi (memberikan dan menerima data atau events) dengan sistim o Actor dapat mewakili sekelompok klien bank (yang mempunyai karut ATM) o Satu klien dapat menggunakan ATM tersebut untuk berbagai keperluan => berbagai actors yang berbeda o Peranan actor ditentukan use case mana saja yang digunakan oleh actor tersebut Interaksi ? tidak lain mengirim dan menerima messages (data. events) o Hubungan antara actor dan use case: <<communication>> associations Use Case: Transactions y Definisi: use case adalah urutan transaksi/proses yang dilakukan oleh sistim. dimana menghasilkan sesuatu yang dapat dilihat/diamati oleh actor tertentu Problem: bagaimana memilih use case yang tepat (terdapat banyak kejadian interaksi antar actor dan system) ? o Definisi di atas => "instance" kejadian yang penting dan dapat dipilah sangat relevan dengan kegiatan actors y .

karena hasil use case harus berhubungan dengan actor tersebut. keputusan.Pilih use case type yang mewakili instance tersebut Dari definisi "menghasilkan sesuatu yang dapat dilihat oleh actor" => use case harus cukup besar karena berhubungan dengan kegiatan actor o Transaksi: sekumpulan aksi. Reuse Use Case : <<extends>> y Sering use case dapat dikembangkan (ditambahkan) dari use case yang telah ada y Penambahan ini untuk memberikan spesialisasi atau inheritance y Jadi jika disebut use case A "extends" use case B : maka instance tersebut mengikuti use case A dan pada satu saat akan mengikuti use case B. . dan messages yang diberikan kepada actors secara konsisten o Actor tertentu: peranan utama. Transfer Keuangan use case memberikan deskripsi cara debit dan kredit dari berbagai account yang berbeda. Sistim memberikan persetujuan dan mengijinkan berapa banyak uang yang dapat diambil Sistim mengeluarkan uang tersebut dan mengurangi jumlah uang tersebut dari rekening Reuse Use Case : <<uses>> y Untuk sistim yang besar: terdapat use case yang sifatnya sama y Kelompok use case ini dapat dibuat : "generalizations" yang mewakili kelompok tsb. setelah mengikuti B dapat kembali ke use case A. berhubungan dengan task tertentu o o Contoh Use case: Tarikan Uang y y y Klien Bank memberikan identifikasi dirinya Klien Bank memilih atau memberikan input berapa banyak uang yang akan diambil dari rekening. o Dapat dianggap sebagai "inheritance" o Digunakan simbol: <<uses>> y Contoh: <<uses>> use case A menggunakan use case B berarti instance A dapat melakukan semua sifat dari instance B o Sebagai contoh: semua transaksi ATM berhubungan dengan pemindahan uang dari satu rekening ke rekening lain. y Dapat menggunakan use case yang telah ada: Transfer Keuangan sebagai "abstract" use case.

Untuk kasus dimana Klien Bank mengambil overdraft maka terdapat sifat khusus use case yang harus ditangani oleh "Manajemen Overdraft" Atau dapat disebut: use case Manajemen Overdarft merupakan "extends" dari use case Tarikan Uang.y Contoh: Klien Bank dapat diberikan fasilitas untuk mengambil uang dalam bentuk overdraft. Contoh Lain: .

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->