grunge

Showing posts with label MBO. Show all posts

Terkadang kita bingung ketika akan memulai sesuatu dan membayangkan hasil akhir dari suatu pekerjaan yang sudah dimulai. Tidak jarang pula kita kebingungan di tengah jalan akibat kesalahan prediksi proses yang sedang dibangun di tengah jalan. Ketika kita sedang menulis sering pula kehilangan ‘flow ’cerita yang sedang kita buat hingga akhirnya selesai dengan tulisan yang kurang terarah pada hasil akhir yang sebelumnya dibayangkan.

Saya pernah membaca buku tentang System Thinking (lupa judul bukunya), pada buku tersebut dijelaskan bahwa penyelesaian suatu masalah dapat kita modelkan dalam suatu pemikiran sistemik. Seperti pada diagram blok di atas, kita dapat memodelkannya kedalam input, system, dan output.Input di sini adalah masalah sedangkan output -nya adalah penyelesaian masalah. Di dalam system kita memproses informasi dari input untuk kemudian disesuaikan agar diperoleh output yang diinginkan. Artinya sebelum memulai penyelesaian masalah harus didefinisikan terlebih dahulu input dan output-nya. Dengan demikian kita mempunyai gambaran jelas tentang permasalahannya dan bisa membayangkan hasil akhirnya. Barulah kemudian mendesain sebuah sistem untuk mencapai hasil akhir yang diinginkan.

Di dalam blok sistem sendiri, kita bisa membaginya kembali ke dalam beberapa blok yang saling terhubung satu sama lain membentuk sebuah proses yang saling terikat (seperti gambar di atas). Masing-masing blok itu pun terdiri dari input, output, dan blok system. Dengan kata lain ada sistem di dalam sistem, yang apabila blok di dalam sistem tersebut masih memiliki proses yang kompleks, dapat dipecah lagi menjadi beberapa blok sampai diperoleh urutan proses input –> system –> output yang lebih sederhana. Proses pemecahan ini terjadi secara rekursif dan tergantung kepada kompleksitas sistem yang dibuat.

Pemodelan sistem ini dalam dunia rekayasa bisa disetarakan dengan standar formal dari abstraction language dimana dewasa ini telah dikenal adanya UML (Unified Modelling Language) atau SDL (Specification Description Language). Abstraction Language tersebut adalah layer teratas ketika kita mengembangkan suatu sistem sebelum implementasi dengan bahasa pemrograman di layer yang lebih rendah. Selain itu pemahaman dan pendekatan sistem juga jauh lebih mudah dengan model definisi formal seperti itu.

Sejatinya konsep berpikir ini bisa digunakan secara luas diberbagai bidang ilmu, karena sistem berpikir secara sistemik seperti ini mampu mendifinisikan masalah dengan baik serta membantu untuk tetap fokus pada tujuan akhir yang ingin dicapai. Contohnya adalah ketika kita ingin membuat suatu tulisan, apabila kita menerapkan metode berpikir seperti ini langkah pertama yang kita lakukan adalah menetapkan langkah awal tulisan dan juga menetapkan hasil akhir dari tulisan yang kita buat. Apabila input dan output nya sudah jelas, maka dalam menulis kita bisa tetap menjaga flow tulisan sampai akhir. Selain mempermudah hal ini juga akan meningkatkan kualitas dari sistem apapun yang kita buat.

Unified Modeling Language (UML) adalah bahasa spesifikasi standar untuk mendokumentasikan, menspesifikasikan, dan membangun sistem perangkat lunak.

Pendahuluan

Unified Modeling Language (UML) adalah himpunan struktur dan teknik untuk pemodelan desain program berorientasi objek (OOP) serta aplikasinya. UML adalah metodologi untuk mengembangkan sistem OOP dan sekelompok perangkat tool untuk mendukung pengembangan sistem tersebut. UML mulai diperkenalkan oleh Object Management Group, sebuah organisasi yang telah mengembangkan model, teknologi, dan standar OOP sejak tahun 1980-an. Sekarang UML sudah mulai banyak digunakan oleh para praktisi OOP. UML merupakan dasar bagi perangkat (tool) desain berorientasi objek dari IBM.

UML adalah suatu bahasa yang digunakan untuk menentukan, memvisualisasikan, membangun, dan mendokumentasikan suatu sistem informasi. UML dikembangkan sebagai suatu alat untuk analisis dan desain berorientasi objek oleh Grady Booch, Jim Rumbaugh, dan Ivar Jacobson.Namun demikian UML dapat digunakan untuk memahami dan mendokumentasikan setiap sistem informasi. Penggunaan UML dalam industri terus meningkat. Ini merupakan standar terbuka yang menjadikannya sebagai bahasa pemodelan yang umum dalam industri peranti lunak dan pengembangan sistem.

UML

Sampai era tahun 1990 puluhan metodologi pemodelan berorientasi objek telah bermunculan di dunia.Diantaranya adalah: metodologi booch, metodologi coad, metodologi OOSE, metodologi OMT, metodologi shlaer-mellor, metodologi wirfs-brock, dsb. Masa itu terkenal dengan masa perang metodologi (method war) dalam pendesainan berorientasi objek. Masing-masing metodologi membawa notasi sendiri-sendiri, yang mengakibatkan timbul masalah baru apabila kita bekerjasama dengan kelompok/perusahaan lain yang menggunakan metodologi yang berlainan.

Dimulai pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson, 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.8). Sejak tahun 1996 pengembangan tersebut dikoordinasikan oleh Object Management Group

Diagram UML

UML menyediakan 10 macam diagram untuk memodelkan aplikasi berorientasi objek, yaitu:

Use Case Diagram untuk memodelkan proses bisnis.

Conceptual Diagram untuk memodelkan konsep-konsep yang ada di dalam aplikasi.

Sequence Diagram untuk memodelkan pengiriman pesan (message) antar objects.

Collaboration Diagram untuk memodelkan interaksi antar objects.

State Diagram untuk memodelkan perilaku objects di dalam sistem.

Activity Diagram untuk memodelkan perilaku Use Cases dan objects di dalam system.

Class Diagram untuk memodelkan struktur kelas.

Object Diagram untuk memodelkan struktur object.

Component Diagram untuk memodelkan komponen object.

Deployment Diagram untuk memodelkan distribusi aplikasi.

Berikut akan dijelaskan 4 macam diagram yang paling sering digunakan dalam pembangunan aplikasi berorientasi object, yaitu use case diagram, sequence diagram, collaboration diagram, dan class diagram.

Use Case Diagram

Use case diagram digunakan untuk memodelkan bisnis proses berdasarkan perspektif pengguna sistem. Use case diagram terdiri atas diagram untuk use case dan actor. Actor merepresentasikan orang yang akan mengoperasikan atau orang yang behhhrinteraksi dengan sistem aplikasi.

Use case merepresentasikan operasi-operasi yang dilakukan oleh actor. Use case digambarkan berbentuk elips dengan nama operasi dituliskan di dalamnya. Actor yang melakukan operasi dihubungkan dengan garis lurus ke use case.

Sequence Diagram

Sequence diagram menjelaskan secara detail urutan proses yang dilakukan dalam sistem untuk mencapai tujuan dari use case: interaksi yang terjadi antar class, operasi apa saja yang terlibat, urutan antar operasi, dan informasi yang diperlukan oleh masing-masing operasi.

Collaboration Diagram

Collaboration diagram dipakai untuk memodelkan interaksi antar object di dalam sistem. Berbeda dengan sequence diagram yang lebih menonjolkan kronologis dari operasi-operasi yang dilakukan, collaboration diagram lebih fokus pada pemahaman atas keseluruhan operasi yang dilakukan oleh object.

Class Diagram

Class diagram merupakan diagram yang selalu ada di permodelan sistem berorientasi objek.Class diagram menunjukkan hubungan antar class dalam sistem yang sedang dibangun dan bagaimana mereka saling berkolaborasi untuk mencapai suatu tujuan

Pemrograman berorientasi objek

Pemrograman berorientasi objek (Inggris: object-oriented programming disingkat OOP) merupakan paradigma pemrogramanyang berorientasikan kepada objek. Semua data dan fungsi di dalam paradigma ini dibungkus dalam kelas-kelas atau objek-objek. Bandingkan dengan logika pemrograman terstruktur. Setiap objek dapat menerima pesan, memproses data, dan mengirim pesan ke objek lainnya,

Model data berorientasi objek dikatakan dapat memberi fleksibilitas yang lebih, kemudahan mengubah program, dan digunakan luas dalam teknik piranti lunak skala besar. Lebih jauh lagi, pendukung OOP mengklaim bahwa OOP lebih mudah dipelajari bagi pemula dibanding dengan pendekatan sebelumnya, dan pendekatan OOP lebih mudah dikembangkan dan dirawat.

Konsep Dasar

· Kelas — kumpulan atas definisi data dan fungsi-fungsi dalam suatu unit untuk suatu tujuan tertentu. Sebagai contoh 'class of dog' adalah suatu unit yang terdiri atas definisi-definisi data dan fungsi-fungsi yang menunjuk pada berbagai macam perilaku/turunan dari anjing. Sebuah class adalah dasar dari modularitas dan struktur dalam pemrograman berorientasi object. Sebuah class secara tipikal sebaiknya dapat dikenali oleh seorang non-programmer sekalipun terkait dengan domain permasalahan yang ada, dan kode yang terdapat dalam sebuah class sebaiknya (relatif) bersifat mandiri dan independen (sebagaimana kode tersebut digunakan jika tidak menggunakan OOP). Dengan modularitas, struktur dari sebuah program akan terkait dengan aspek-aspek dalam masalah yang akan diselesaikan melalui program tersebut. Cara seperti ini akan menyederhanakan pemetaan dari masalah ke sebuah program ataupun sebaliknya.

· Objek - membungkus data dan fungsi bersama menjadi suatu unit dalam sebuah program komputer; objek merupakan dasar darimodularitas dan struktur dalam sebuah program komputer berorientasi objek.

· Abstraksi - Kemampuan sebuah program untuk melewati aspek informasi yang diproses olehnya, yaitu kemampuan untuk memfokus pada inti. Setiap objek dalam sistem melayani sebagai model dari "pelaku" abstrak yang dapat melakukan kerja, laporan dan perubahan keadaannya, dan berkomunikasi dengan objek lainnya dalam sistem, tanpa mengungkapkan bagaimana kelebihan ini diterapkan. Proses, fungsi atau metode dapat juga dibuat abstrak, dan beberapa teknik digunakan untuk mengembangkan sebuah pengabstrakan.

· Enkapsulasi - Memastikan pengguna sebuah objek tidak dapat mengganti keadaan dalam dari sebuah objek dengan cara yang tidak layak; hanya metode dalam objek tersebut yang diberi izin untuk mengakses keadaannya. Setiap objek mengakses interfaceyang menyebutkan bagaimana objek lainnya dapat berinteraksi dengannya. Objek lainnya tidak akan mengetahui dan tergantung kepada representasi dalam objek tersebut.

· Polimorfisme melalui pengiriman pesan. Tidak bergantung kepada pemanggilan subrutin, bahasa orientasi objek dapat mengirim pesan; metode tertentu yang berhubungan dengan sebuah pengiriman pesan tergantung kepada objek tertentu di mana pesa tersebut dikirim. Contohnya, bila sebuah burung menerima pesan "gerak cepat", dia akan menggerakan sayapnya dan terbang. Bila seekor singa menerima pesan yang sama, dia akan menggerakkan kakinya dan berlari. Keduanya menjawab sebuah pesan yang sama, namun yang sesuai dengan kemampuan hewan tersebut. Ini disebut polimorfisme karena sebuah variabel tungal dalam program dapat memegang berbagai jenis objek yang berbeda selagi program berjalan, dan teks program yang sama dapat memanggil beberapa metode yang berbeda di saat yang berbeda dalam pemanggilan yang sama. Hal ini berlawanan denganbahasa fungsional yang mencapai polimorfisme melalui penggunaan fungsi kelas-pertama.

· Dengan menggunakan OOP maka dalam melakukan pemecahan suatu masalah kita tidak melihat bagaimana cara menyelesaikan suatu masalah tersebut (terstruktur) tetapi objek-objek apa yang dapat melakukan pemecahan masalah tersebut. Sebagai contoh anggap kita memiliki sebuah departemen yang memiliki manager, sekretaris, petugas administrasi data dan lainnya. Misal manager tersebut ingin memperoleh data dari bag administrasi maka manager tersebut tidak harus mengambilnya langsung tetapi dapat menyuruh petugas bag administrasi untuk mengambilnya. Pada kasus tersebut seorang manager tidak harus mengetahui bagaimana cara mengambil data tersebut tetapi manager bisa mendapatkan data tersebut melalui objek petugas adminiistrasi. Jadi untuk menyelesaikan suatu masalah dengan kolaborasi antar objek-objek yang ada karena setiap objek memiliki deskripsi tugasnya sendiri.

Pengertian Sistem Orientasi Objek

Sebuah sistem operasi berorientasi obyek adalah sebuah sistem operasi yang internal menggunakan metodologi berorientasi objek . Sebuah sistem operasi berorientasi objek ini berbeda dengan objek-berorientasi user interface atau pemrograman kerangka kerja , yang dapat ditempatkan di atas sistem operasi non-object-oriented seperti DOS , Microsoft Windows atau Unix . Hal ini dapat berpendapat, bagaimanapun, bahwa sudah ada konsep berorientasi objek yang terlibat dalam desain sebuah sistem operasi yang lebih khas seperti Unix . Sementara bahasa yang lebih tradisional seperti C tidak mendukung orientasi objek sebagai lancar sebagai bahasa yang lebih baru, gagasan, misalnya, berkas , aliran , atau device driver (di Unix, masing-masing diwakili sebagai file descriptor ) dapat dianggap sebagai yang baik contoh dari orientasi objek: mereka, setelah semua, tipe data abstrak , dengan berbagai metode dalam bentuk panggilan sistem , yang perilakunya bervariasi berdasarkan jenis objek, yang pelaksanaannya rincian tersembunyi dari pemanggil, dan bahkan mungkin menggunakan warisan di mereka yang mendasari kode.

Contoh Sistem Orientasi Objek

•LISP

Lisp digunakan sebagai sistem operasi pada beberapa mesin awal. alias pada Mesin Lisp dan kemudian di Symbolics dengan marga (sistem operasi)

•Smalltalk

Smalltalk diciptakan di Xerox di 70-an. Sistem Smalltalk adalah sepenuhnya berorientasi objek dan kebutuhan sangat sedikit dukungan olehBIOS dan sistem run-time.

•Diri

Diri (programming_language) ditemukan di Sun.

•BM AS400

IBM menciptakan AS400 sekitar tahun 1978 OS AS400 memiliki pengenal unik 128bit untuk objek apapun.

•NeXTSTEP

Selama akhir 1980-an, Steve Jobs membentuk komputer perusahaan NeXT . Salah satu tugas pertama NeXT adalah untuk merancang sistem berorientasi obyek operasi, NeXTSTEP . Mereka melakukan ini dengan menambahkan suatu kerangka kerja berorientasi objek di atasMach dan BSD menggunakan Objective-C bahasa sebagai dasar. NeXTstep kemudian berkembang menjadi OPENSTEP dan Kakao (API) pada Mac OS X . OPENSTEP diberikan sebagai lapisan API atas banyak sistem operasi, yaitu NextStep, Windows, HP-UX , Solaris .

•Pilihan

Pilihan adalah berorientasi obyek sistem operasi yang dikembangkan di University of Illinois di Urbana-Champaign . Hal ini ditulis dalam C + + dan menggunakan objek untuk mewakili komponen inti kernel seperti CPU , proses dan sebagainya. Warisan digunakan untuk memisahkan kernel ke dalam kelas mesin portabel independen dan kecil non-portabel tergantung kelas. Pilihan telah porting ke dan berjalan pada SPARC , x86 , dan ARM .

•Athene

Athena adalah sebuah objek berbasis sistem operasi pertama kali dirilis pada tahun 2000 oleh Sistem Rocklyte . Lingkungan pengguna dibangun seluruhnya dari benda-benda yang dihubungkan bersama pada saat runtime. Aplikasi untuk Athene juga dapat dibuat menggunakan metodologi ini dan biasanya ditulis menggunakan objek bahasa scripting 'DML' ( Dinamis Markup Language ). Objek dapat dibagi antara proses dengan menciptakan mereka dalam memori bersama dan mengunci mereka seperti yang diperlukan untuk akses.Kerangka objek Athena adalah multi-platform, yang memungkinkan untuk digunakan dalam lingkungan Windows dan Linux untuk pengembangan program berorientasi objek.

•BeOS

Salah satu usaha untuk menciptakan sistem operasi yang benar-benar berorientasi obyek adalah BeOS dari pertengahan tahun 1990, yang digunakan obyek dan C + + bahasa untuk antarmuka pemrograman aplikasi (API). Tapi kernel itu sendiri ditulis dalam C dengan C + + bungkus di ruang pengguna. Sistem tidak menjadi mainstream meskipun bahkan hari ini telah penggemar dan manfaat dari pembangunan yang berkelanjutan.

•Sukukata

Suku membuat berat penggunaan C + + dan untuk alasan yang sering dibandingkan dengan BeOS

.berbasis Java sistem operasi

Mengingat bahwa Sun Microsystems ' Java saat ini salah satu bahasa berorientasi objek yang paling dominan, tidak mengherankan bahwa Java berbasis sistem operasi telah dicoba. Di daerah ini, idealnya, kernel akan terdiri dari minimal yang dibutuhkan untuk mendukung JVM .Ini adalah satu-satunya komponen suatu sistem operasi yang harus ditulis dalam bahasa lain selain Jawa. Dibangun di atas bahwa JVM dan dukungan hardware dasar, akan mungkin untuk menulis sisa dari sistem operasi di Jawa, bahkan bagian dari sistem yang lebih tradisional ditulis dalam bahasa tingkat rendah seperti C, misalnya driver perangkat , dapat ditulis di Jawa. Contoh upaya seperti sistem operasi termasuk JX , JNode dan JavaOS .

•Microsoft Singularity

Singularitas adalah Operating System eksperimen berdasarkan Microsoft NET Framework. . Hal ini sebanding dengan berbasis Java sistem operasi, tetapi menggunakan platform. NET bukan platform Java.

•Symbolics Genera

Genera dari Symbolics adalah sistem operasi untuk Mesin Lisp ditulis dalam ZetaLisp dan Symbolics Common Lisp . Ini membuat penggunaan berat Flavors (perpanjangan berorientasi obyek dini untuk Lisp) dan Sistem Common Lisp Object (CLOS) . Pembangunan dimulai pada pertengahan tahun 70-an di MIT.

Dalam bagian ini akan membahas tentang konsep dasar pemodelan use case meliputi : use case, actor, dan relasi. Jika sudah memahami pemodelan bisnis, ada kemiripan antara pemodelan bisnis dan pemodelan use case. Perbedaaan antara pemodelan bisnis dan pemodelan sistem :

Ítem	Pemodelan bisnis(Business Use Case)	Pemodelan sistem(Use Case)
Use case	Menjelaskan apa yang bisnis kerjakan	Menjelaskan apa yang sistem lakukan dibisnis
Aktor	Eksternal terhadap organisasi	Eksternal terhadap sistem
Pekerjaan bisnis	Internal terhadap organisasi	Tidak digunakan

1. Use case

Use Case adalah bagian tingkat tinggi dari fungsionalitas yang disediakan oleh sistem. Dengan kata lain, use case menggambarkan bagimana seseorang menggunakan sistem.

Untuk mengidentifikasi use case, kita menjawab pertanyaan “ apa yang sistem lakukan terhadap dunia sekililingnya? Dalam UML, Use cse dimodelkan dengan menggunakan ikon :

Use case adalah independen terhadap implementasinya dan pandangan tingkat tinggi apa yang pemakai harapkan dari sistem. Dengan penjelasan sebagai berikut :

a. Use case adalah independen terhadap implementasinya. Selama membuat use case, asumsikan bahwa anda sedang membangun sistem manual. Use case berkonsentrasi pada apa yang sistem kerjakan, bukan bagaimana sistem mengerjakan.

b. Use case adalah pandangan tingkat tinggi apa yang pemakai harapkan dari sistem. Use case yang sudah dikelompokkan memudahkan pelanggan memahaminya, pada level yang sangat tinggi dari suatu sistem.

c. Use case difokuskan pada apa yang pengguna dapatkan dari sistem. Masing-masing use case mempresentasikan transaksi lengkap antara pemakai dan sistem yang menghasilkan manfaat terhadap pemakai.

2. Actor

Actor adalah seseorang atau apa saja yang berhubungan dengan sistem yang sedang dibangun. Use case menggambarkan semua yang ada dalam ruang lingkup sistem. Actor merupakan semua yang ada diluar ruang lingkup sistem. Dalam UML, actor dimodelkan menggunakan ikon :

Ada 3 tipe actor, yaitu :

a. Pengguna sistem

Actor secara fisik atau seorang pengguna. Ini adalah gambaran actor secara umum, dan selalu ada pada setiap system. Untuk sistem sirkulasi perpustakaan, actornya adalah orang-orang yang secara langsung menggunkan system. Ketika menamakan actor, gunakan peranan dan jangan menggunakan nama posisi. Posisi dapat berubah, tetapi peranan dapat diganti oleh siapa saja dan relative tetap.

b. System lain yang berhubungan dengan system yang dibangun.

c. Waktu

Waktu dapat menjadi suatu actor ketika melalui sejumlah waktu tertentu memicu beberpa kejadian dalam system. Misalnya, bagian promosi memberikan kesempatan pada pelanggan untuk memenangkan tiket gratis. Stiap hari pada pukul 03.00 dini hari, system secara otomatis menenyeleksi secara acak pelanggan-pelanggan untuk mendapatkan tiket gratis tersebut. Sebab waktu adalah diluar kendali kita, maka ia dapat menjadi actor.

3. Relasi

Relasi asosiasi digunakan untuk menunjukkan relasi antar use case dan actor. Ada tiga tipe relasi antara use case : relasi include, relasi extend, dan relasi generalisasi. Sedangkan relasi antara actor hanya digunakan satu relasi yaitu generalisasi.

a. Relasi assosiasi

Relasi antar actor dan use case adalah relasi assosiasi. Dalam UML, relasi assosiasi digambarkan dengan menggunakan anak panah.

Dalam contoh, use case mengawali komunikasi dengan actor system kredit. Selama use case “Purchase Ticket” berjalan, system reservasi mengawali komunikasi dengan system kredit untuk mengecek kartu dan melengkapi transaksi. Meskipun aliran informasi terjadi dalam 2 arah, dari reservasi system kekartu kredit dan bolak-balik, arah panah mengidentifikasikan siapa yang mengawali komunikasi. Dengan mengecualikan use case dalam relasi include dan relasi extend, setiap use case harus diinisialisasikan oleh actor.

b. Relasi include

Relasi include memungkinkan satu use case menggunakan fungsionalitas yang disediakan oleh use case lainnya. Relasi ini dapat digunakan dengan alas an salah satu dari dua hal :

1. Jika dua atau lebih use case mempunyai bagian besar fungsionalitas yang identik, maka fungsionalitas ini dapat dipecah kedalam use case sendiri. Masing-masing use case kemudian menggunakan relasi include terhadap use case baru dibuat tersebut.

2. Relasi include bermanfaat untuk situasi jika sebuah use case mempunyai fungsionalitas besar yang tidak umum. Relasi include digunakan untuk memodelkan dua buah use case yang lebih kecil tersebut. Relasi include menyatakan bahwa satu use case selalu menggunakan fungsionalitas yang disediakan oleh use case lainnya.

c. Relasi extend

Relasi extend memungkinkn satu use case secara opsional menggunkan fungsionalitas yang disediakan oleh use case lainnya. Dalam UML, relasi extend digambarkan sebagai berikut :

UML USE CASE

Pengertian :

● Use case class digunakan untuk memodelkan dan menyatakan unit fungsi/layanan yang disediakan oleh sistem (atau bagian sistem: subsistem atau class) ke pemakai.

● Use case dapat dilingkupi dengan batasan sistem yang diberi label nama sistem.

● Use case adalah sesuatu yang menyediakan hasil yang dapat diukur ke pemakai atau sistem eksternal.

Karakteristik :

– Use cases adalah interaksi atau dialog antara sistem dan actor, termasuk pertukaran pesan dan tindakan yang dilakukan oleh sistem.

– Use cases diprakarsai oleh actor dan mungkin melibatkan peran actor lain. Use cases harus menyediakan nilai minimal kepada satu actor.

– Use cases bisa memiliki perluasan yang mendefinisikan tindakan khusus dalam interaksi atau use case lain mungkin disisipkan.

– Use case class memiliki objek use case yang disebut skenario. Skenario menyatakan urutan pesan dan tindakan tunggal.

Komponen Pembentuk Use Case Diagram :

1. Actor

Pada dasarnya actor bukanlah bagian dari use case diagram, namun untuk dapat terciptanya suatu use case diagram diperlukan beberapaactor. Actor tersebut mempresentasikan seseorang atau sesuatu (seperti perangkat, sistem lain) yang berinteraksi dengan sistem. Sebuah actor mungkin hanya memberikan informasi inputan pada sistem, hanya menerima informasi dari sistem atau keduanya menerima, dan memberi informasi pada sistem. Actor hanya berinteraksi dengan use case, tetapi tidak memiliki kontrol atas use case. Actor digambarkan dengan stick man . Actor dapat digambarkan secara secara umum atau spesifik, dimana untuk membedakannya kita dapat menggunakan relationship

Gambar Actor

2. Use Case

Use case adalah gambaran fungsionalitas dari suatu sistem, sehingga customeratau pengguna sistem paham dan mengerti mengenai kegunaan sistem yang akan dibangun.

Catatan : Use case diagram adalah penggambaran sistem dari sudut pandang pengguna sistem tersebut (user), sehingga pembuatan use case lebih dititikberatkan pada fungsionalitas yang ada pada sistem, bukan berdasarkan alur atau urutan kejadian.

Cara menentukan Use Case dalam suatu sistem:

a. Pola perilaku perangkat lunak aplikasi.

b. Gambaran tugas dari sebuah actor.

c. Sistem atau “benda” yang memberikan sesuatu yang bernilai kepadaactor.

d. Apa yang dikerjakan oleh suatu perangkat lunak (*bukan bagaimana cara mengerjakannya).

Gambar Use Case

Relasi dalam Use Case

Ada beberapa relasi yang terdapat pada use case diagram:

1. Association, menghubungkan link antar element.

2. Generalization, disebut juga inheritance (pewarisan), sebuah elemen dapat merupakan spesialisasi dari elemen lainnya.

3. Dependency, sebuah element bergantung dalam beberapa cara ke element lainnya.

4. Aggregation, bentuk assosiation dimana sebuah elemen berisi elemen lainnya.

Tipe relasi/ stereotype yang mungkin terjadi pada use case diagram:

1. <<include>> , yaitu kelakuan yang harus terpenuhi agar sebuah eventdapat terjadi, dimana pada kondisi ini sebuah use case adalah bagian dari use case lainnya.

2. <<extends>>, kelakuan yang hanya berjalan di bawah kondisi tertentu seperti menggerakkan alarm.

3. <<communicates>>, mungkin ditambahkan untuk asosiasi yang menunjukkan asosiasinya adalah communicates association . Ini merupakan pilihan selama asosiasi hanya tipe relationship yang dibolehkan antara actor dan use case.

3. Contoh Use Case Diagram