Tentang use case,aktor dan relasi

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 :

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

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.

Apakah Rational Rose dan Notasi UML ?

Apakah Rational Rose dan Notasi UML ?

Rational rose

Rational Rose adalah tools pemodelan visual untuk pengembangan system berbasis objek yang handal untuk digunakan sebagai bantuan bagi para pengembang dalam melakukan analisis dan perancangan system. Rational rosemendukung permodelan bisnis yang membantu para pengembang memahami system secara komprehensif. Ia juga membantu analisis system dengan cara pengembang membuat diagram use case untuk melihat fungsionalitas system secara keseluruhan sesuai dengan harapan dan keinginan pengguna. Kemudian, ia juga menuntut pengembang untuk mengambangkan Interaction Diagram untuk melihat bagaimana objek-objek saling bekerjasama dalam menyediakan fungsionalitas yang diperlukan.

Dalam Rational rose, pemodelan adalah cara melihat system dari berbagai sudut pandang. Ia mencakup semua diagram yang dikenal dalam UML, actor-aktor yang terlibat dalam system, use-case, objek-objek, kelas-kelas, komponen-komponen, serta simpul-simpul penyebaran. Model juga mendeskripsikan rincian yang diperlukan system dan bagaimana ia akan bekerja, sehingga para pengembang dapat menggunakan model itu sebagai blue print untuk system yang akan dikembangkan.

UML

UML (Unified Modelling Language) adalah sebuah bahasa yang menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan system piranti lunak.

Seperti bahasa-bahasa lainnya,  UML mendefinisikan notasi dan  syntax/semantik. Notasi UML merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti lunak. Setiap bentuk memiliki makna tertentu, dan UML syntax mendefinisikan bagaimana bentuk-bentuk tersebut dapat dikombinasikan. Notasi UML terutama diturunkan dari 3 notasi yang telah ada sebelumnya: Grady Booch OOD (Object-Oriented Design), Jim Rumbaugh OMT (Object Modeling Technique), dan Ivar Jacobson OOSE (Object-Oriented Software Engineering).

Sejarah UML sendiri cukup panjang. Sampai era tahun 1990 seperti kita ketahui puluhan metodologi pemodelan berorientasi objek telah bermunculan di dunia. Diantaranya adalah: metodologi booch [1],  metodologi coad [2], metodologi OOSE [3], metodologi OMT [4], metodologi shlaer-mellor [5], metodologi wirfs-brock [6], 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 group/perusahaan lain yang menggunakan metodologi yang berlainan.

Posisi UML

Tahapan pembangunan aplikasi berorientasi objek pada umunya bersifat iterative dan incremental. Proses pembangunan aplikasi dibagi menjadi beberapa siklus. Setiap kali satu situs selesai dilakukan, dilakukan evaluasi sebagai bahan untuk memulai siklus berikutnya. Beberapa siklus biasanya terdiri atas:

Tahap analisa permintaan

Tahap analisa desain

Tahap desain

Tahap Pengkodean.

Tahap implementasi

UML digunakan pada tahap analisa dan desain. Desain yang dihasilkan berupa diagram-diagram UML yang akan diterjemahkan menjadi kode program pada tahap pengkodean.

Konsep Dasar UML

Abstraksi konsep dasar UML yang terdiri dari structural classification, dynamic behavior, dan model management, bisa kita pahami dengan mudah apabila kita melihat gambar diatas dari Diagrams. Main concepts bisa kita pandang sebagai term yang akan muncul pada saat kita membuat diagram. Dan view adalah kategori dari diagaram tersebut.

Lalu darimana kita mulai ? Untuk menguasai UML, sebenarnya cukup dua hal yang harus kita

perhatikan:

1.  Menguasai pembuatan diagram UML

2.  Menguasai langkah-langkah dalam analisa dan pengembangan dengan UML

Tulisan ini pada intinya akan mengupas kedua hal tersebut.

Seperti juga tercantum pada gambar diatas UML mendefinisikan diagram-diagram sebagai berikut:

use case diagram

class diagram

statechart diagram

activity diagram

sequence diagram

collaboration diagram

component diagram

deployment diagram

Diagram UML

UML menyediakan 10 macam Dalam UML merupakan salah satu alat Bantu yang sangat handal dalam mengembangkan system berorientasi objek. Ada 9 jenis diagram yang ditangani oleh UML, yakni:

1. Diagram Use Case

Use case adalah deskripsi fungsi dari sebuah dari sudut pandang pengguna. Use case bekerja dengan cara mendeskripsikan tipikal interkasi antar user (pengguna) sebuah system dengan system itu sendiri dan menjelaskan bagaimana system itu bekerja.

2. Diagram Class

Class diagram adalah sebuah spesifikasi yang jika diinstansiasi maka akan menghasilkan objek yang merupakan inti dari pengembangan dan desain berorientasi objek. Kelas menggambarkan atribut atau properti dari sebuah system sekaligus menawarkan layanan apa saja yang bisa dilakukan dengan objek tersebut (method/fungsi). Jadi, kelas memiliki 3 pokok penting yaitu: nama, atribut dan method.

3. Diagram Statechart

Statechart diagram menunjukkan transisi dan perubahan keadaan suatu objek pada system sebagai akibat dari stimulasi yang diterima. Dalam UML, state digambarkan berbentuk segi empat dengan sudut tumpul dan memiliki nama sesuai dengan kondisi saat itu.

4. Diagram Activity

Actifity diagram menggambarkan berbagai alir aktifitas dalam system yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses parallel yang mungkin erjadi pada beberapa eksekusi.

5. Diagram Sequence

Sequence diagram digunakan untuk menggambarkan perilaku pada sebuah sekenario. Diagram ini menunjukkan sejumlah contoh objek dan message (pesan) yang diletakkan di antara objek-objek ini di dalam use case.

6. Diagram Collaboration

Collaboration diagram adalah perluasan dari objek diagram. Objek diagram menunjukkan objek-objek dan hubungannya dengan yang lain. Collaboration diagram menunjukkan message-message objek yang dikirim satu sama lain,

7. Diagram Component

Component Diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan di antaranya.

8. Diagram Deployment.

Deplaoyment diagram menggambarkan detail bagaimana komponen di-deploy dalam infrastruktur system, dimana komponen akan diletakkan (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server dan hal-hal lain yang bersifat fisikal.

Tool Pembuatan UML

Banyak sekali tool-tool yang didesain untuk mendukung UML,mulai dari yang gratis maupun komersial. Di antaranya yaitu:

Komersial:

Rational Rose

Object Domain

Magic Draw

Visio

Argo UML: Tool sederhana ini dapat membuat membantu kita untuk merancang perangkat lunak yang akan dibangun. Tool ini cocok untuk bagi yang baru belajar UML, karena fitur-fiturnya sangat terbatas.

FrameUML: Menurut saya tool ini agak kurang userfriendly karena sangat sederhana dan tidak meng-cover semua kebutuhan yang diperlukan dalam pembuatan UML.

Net Beans: Tool ini sangat kompleks, karena tidak hanya UML yang ada didalamnya, tapi BaseIDE, JavaME, JavaSE, SOAP, Ruby,C++ termasuk webserver Apache Tomcat. Maka dari itu tool ini sangat berat dan memakan memori yang cukup banyak.