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

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

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

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

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

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

kelas Mobil adalah Whole dan komponennya Mesin. Contohnya. Sebuah objek adalah sebuah entitas yang mencakup data dan metode. Part 2.Struktur kelas dibagi dua macam. sedangkan kelas&-objek adalah kelas dengan satu atau lebih objek di dalamnya. kelas dan relasinya dengan yang lain.Diagram objek melengkapi notasi grafik untuk pemodelan objek. atau kata sifat dan kata benda. Nama kelas adalah kata benda tunggal. Kelas merupakan satu atau lebih objek dengan persamaan atribut dan metode. dan lain-lain. Part n. > Kelas dan Objek Konsep fundamental dalam analisis berorientasi objek adalah objek itu sendiri. Diagram objek bermanfaat untuk pemodelan abstrak dan membuat perancangan program. 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. merupakan Part1. Notasi untuk kelas dan kelas-&-objek > Struktur Objek dan Hirarki Kelas . . . Rangka. yaitu Whole-Part Structure dan Gen-Spec Structure. Gambar 3.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. 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. atau sistim yang lain Use Case y Types yang mewakili: behaviour. external hardware. 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 .

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 . 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.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.

y Dapat menggunakan use case yang telah ada: Transfer Keuangan sebagai "abstract" use case.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. Transfer Keuangan use case memberikan deskripsi cara debit dan kredit dari berbagai account yang berbeda. 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. dan messages yang diberikan kepada actors secara konsisten o Actor tertentu: peranan utama. . setelah mengikuti B dapat kembali ke use case A. keputusan. karena hasil use case harus berhubungan dengan actor tersebut. 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. 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.

y Contoh: Klien Bank dapat diberikan fasilitas untuk mengambil uang dalam bentuk overdraft. 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. Contoh Lain: .

Sign up to vote on this title
UsefulNot useful