UML(Unifiled Modeling Langguage)


BAB 1
PENDAHULUAN

A.   Latar Belakang
                  
                   Objek adalah kombinasi antara struktur data dan perilaku dalam satu entitas       dan mempunyai nilai tertentu yang membedakan entitas tersebut. Pengertian         berorientasi objek berarti pengorganisasian perangkat lunak sebagai kumpulan dari        objek tertentu yang memiliki struktur data dan perilakunya. Konsep fundamental   dalam analisis sistem berorientasi objek adalah objek itu sendiri.
                        UML (Unified Modeling Language) adalah metode pemodelan (tools / model)      secara visual sebagai sarana untuk merancang dan atau membuat software       berorientasi objek dan memberikan standar penulisan sebuah sistem untuk           pengembangan sebuah software yang dapat menyampaikan beberapa informasi         untuk proses implementasi pengembangan software.
                        Karena berorientasi objek makasemua elemen dan diagram berbasiskan pada     paradigma object oriented, oleh karena itu UML dapat secara langsung dihubungkan            ke berbagai bahasa pemograman atau bahkan dihubungkan secara langsung ke       dalam sebuah object – oriented database.

B.   Tujuan
         
          Tujuan dari pembuatan makalah ini adalah :
1.      Menjelaskan tentang sistem berorientasi objek
2.      Menjelaskan tentang UML (Unified Modeling Language)
3.      Hubungan sistem berorientasi objek dengan UML (Unified Modeling Language)
     
                  






BAB II
PEMBAHASAN

A.    Sistem Berorientasi Objek     

          Pemrograman berorientasi objek (Inggris: object-oriented programming disingkat OOP) merupakan paradigma pemrograman yang 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 dari Pemrograman Berorientasi Objek Pemrograman orientasi-objek menekankan konsep berikut:

1.      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.
2.      Objek - membungkus data dan fungsi bersama menjadi suatu unit dalam sebuah program komputer; objek merupakan dasar dari modularitas dan struktur dalam sebuah program komputer berorientasi objek.
3.      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.
4.      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 interface yang 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 pesan 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 dengan bahasa 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.

Bahasa pemrograman yang mendukung OOP antara lain:
Visual Foxpro
Java
C++
Pascal (bahasa pemrograman)
Visual Basic.NET
SIMULA
Smalltalk
Ruby
Python
PHP
C#
Delphi
Eiffel
Perl
Adobe Flash AS 3.0     

B.   UML (Unified Modeling Language)

          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 (OMG – http://www.omg.org).
            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.

            Use Case Diagram


                                Use case diagram menggambarkan fungsionalitas yang diharapkan dari   sebuah sistem. Yang             ditekankan adalah “apa” yang diperbuat sistem, dan bukan            “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor    dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke     sistem, meng-create sebuah daftar belanja, dan sebagainya.
                        Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang     berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu.
                        Use case diagram dapat sangat membantu bila kita sedang menyusun      requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang       ada pada sistem.
                        Sebuah use case dapat meng-include fungsionalitas use case lain sebagai             bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case             yang di-include akan dipanggil setiap kali use case yang meng-include dieksekusi   secara normal.
                        Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga        duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas             yang common.
                        Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya      sendiri.
                        Sementara hubungan generalisasi antar use case menunjukkan bahwa use           case yang satu merupakan spesialisasi dari yang lain.


            Contoh use case diagram :

Use case diagram

            Class Diagram


                        Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek.            Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus      menawarkan layanan untuk memanipulasi keadaan            tersebut (metoda/fungsi).
                        Class diagram menggambarkan struktur dan deskripsi class, package dan             objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan     lain-lain.
            Class memiliki tiga area pokok :
1.      Nama (dan stereotype)
2.      Atribut
3.      Metoda

            Atribut dan metoda dapat memiliki salah satu sifat berikut :
Private, tidak dapat dipanggil dari luar class yang bersangkutan
Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya
Public, dapat dipanggil oleh siapa saja


                        Class dapat merupakan implementasi dari sebuah interface, yaitu class     abstrak yang hanya             memiliki metoda. Interface tidak dapat langsung     diinstansiasikan, tetapi harus diimplementasikan dahulu menjadi sebuah class.             Dengan demikian interface mendukung resolusi metoda pada saat run-time.


                        Sesuai dengan perkembangan class model, class dapat dikelompokkan      menjadi package. Kita juga dapat membuat diagram yang terdiri atas package.



            Hubungan Antar Class

  1. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah navigability menunjukkan arah query antar class.

  1. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”).

  1. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi.

4.      Hubungan dinamis, yaitu rangkaian pesan (message) yang di-passing dari satu class kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram yang akan dijelaskan kemudian.

            Contoh class diagram :

Class diagram


            Statechart Diagram


                        Statechart diagram menggambarkan transisi dan perubahan keadaan (dari          satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu            class dapat memiliki lebih dari satu statechart diagram).
                        Dalam UML, state digambarkan berbentuk segiempat dengan sudut          membulat dan memiliki nama sesuai kondisinya saat itu. Transisi antar state            umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi yang           bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan             sebagai            akibat dari event tertentu dituliskan dengan diawali garis miring.
                        Titik awal dan akhir digambarkan berbentuk lingkaran berwarna penuh dan         berwarna setengah.
            Contoh statechart diagram :




            Activity Diagram


                        Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang       sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin    terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat   menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi.
                        Activity diagram merupakan state diagram khusus, di mana sebagian besar          state adalah action dan sebagian besar transisi di-trigger oleh selesainya state             sebelumnya (internal processing). Oleh karena itu activity diagram tidak       menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem)             secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari     level atas secara umum.
                        Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas         menggambarkan proses yang berjalan, sementara use case menggambarkan           bagaimana aktor menggunakan sistem untuk melakukan aktivitas.
                        Sama seperti state, standar UML menggunakan segiempat dengan sudut membulat untuk             menggambarkan aktivitas. Decision digunakan untuk          menggambarkan behaviour pada kondisi tertentu. Untuk mengilustrasikan proses-      proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik,    garis horizontal atau vertikal.
                        Activity diagram dapat dibagi menjadi beberapa object swimlane untuk    menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.
            Contoh activity diagram tanpa swimlane:



            Sequence Diagram


                        Sequence diagram menggambarkan interaksi antar objek di dalam dan di            sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang        digambarkan terhadap waktu. Sequence             diagram terdiri atar dimensi vertikal            (waktu) dan dimensi horizontal (objek-objek yang terkait).
                        Sequence diagram biasa digunakan untuk menggambarkan skenario atau             rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk             menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut,          proses dan perubahan apa saja yang terjadi             secara internal dan output apa yang             dihasilkan.

            Masing-masing objek, termasuk aktor, memiliki lifeline vertikal.
                        Message digambarkan sebagai garis berpanah dari satu objek ke objek     lainnya. Pada fase desain berikutnya, message akan dipetakan menjadi           operasi/metoda dari class.
                        Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya     diawali dengan diterimanya sebuah message.
                        Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan          icon khusus untuk objek boundary, controller dan persistent entity.

            Contoh sequence diagram :



            Collaboration Diagram


                        Collaboration diagram juga menggambarkan interaksi antar objek seperti            sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan      bukan pada waktu penyampaian message.
                        Setiap message memiliki sequence number, di mana message dari level   tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama.

Collaboration diagram


            Component Diagram


                        Component diagram menggambarkan struktur dan hubungan antar           komponen piranti lunak,             termasuk ketergantungan (dependency) di antaranya.
                        Komponen piranti lunak adalah modul berisi code, baik berisi source code            maupun binary code,   baik library maupun executable, baik yang muncul pada     compile time, link time, maupun run time. Umumnya komponen terbentuk dari             beberapa class dan/atau package, tapi dapat juga dari        komponen-komponen       yang lebih kecil.
                        Komponen dapat juga berupa interface, yaitu kumpulan layanan yang       disediakan sebuah komponen untuk komponen lain.
            Contoh component diagram:


            Deployment Diagram


                        Deployment/physical diagram menggambarkan detail bagaimana komponen       di-deploy dalam             infrastruktur sistem, di mana komponen akan terletak (pada          mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi           tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal
                        Sebuah node adalah server, workstation, atau piranti keras lain yang         digunakan untuk men-deploy             komponen dalam lingkungan sebenarnya.    Hubungan antar node (misalnya TCP/IP) dan             requirement dapat juga         didefinisikan dalam diagram ini.






            Contoh deployment diagram :


            Langkah-Langkah Penggunaan UML


            Berikut ini adalah tips pengembangan piranti lunak dengan menggunakan UML:
  1. Buatlah daftar business process dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul.
  2. Petakan use case untuk tiap business process untuk mendefinisikan dengan tepat fungsionalitas yang harus disediakan oleh sistem. Kemudian perhalus use case diagram dan lengkapi dengan requirement, constraints dan catatan-catatan lain.
  3. Buatlah deployment diagram secara kasar untuk mendefinisikan arsitektur fisik sistem.
  4. Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus disediakan oleh sistem.
  5. Berdasarkan use case diagram, mulailah membuat activity diagram.
  6. Definisikan objek-objek level atas (package atau domain) dan buatlah sequence dan/atau collaboration diagram untuk tiap alir pekerjaan. Jika sebuah use case memiliki kemungkinan alir normal dan error, buatlah satu diagram untuk masing-masing alir.
  7. Buarlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk menjalankan skenario use case.
  8. Berdasarkan model-model yang sudah ada, buatlah class diagram. Setiap package atau domain dipecah menjadi hirarki class lengkap dengan atribut dan metodanya. Akan lebih baik jika untuk setiap class dibuat unit test untuk menguji fungsionalitas class dan interaksi dengan class lain.
  9. Setelah class diagram dibuat, kita dapat melihat kemungkinan pengelompokan class menjadi komponen-komponen. Karena itu buatlah component diagram pada tahap ini. Juga, definisikan tes integrasi untuk setiap komponen meyakinkan ia berinteraksi dengan baik.
  10. Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan dan requirement piranti lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node.
  11. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan :
    • Pendekatan use case, dengan meng-assign setiap use case kepada tim pengembang tertentu untuk mengembangkan unit code yang lengkap dengan tes.
    • Pendekatan komponen, yaitu meng-assign setiap komponen kepada tim pengembang tertentu.
  12. Lakukan uji modul dan uji integrasi serta perbaiki model berserta codenya. Model harus selalu sesuai dengan code yang aktual.
  13. Piranti lunak siap dirilis.

            Tool Yang Mendukung UML

                        Saat ini banyak sekali tool pendesainan yang mendukung UML, baik itu tool          komersial maupun             opensource. Beberapa diantaranya adalah:
·           Rational Rose (www.rational.com)
·           Together (www.togethersoft.com)
·           Object Domain (www.objectdomain.com)
·           Jvision (www.object-insight.com)
·           Objecteering (www.objecteering.com)
·           MagicDraw (www.nomagic.com/magicdrawuml)
·           Visual Object Modeller (www.visualobject.com)



                  



BAB III
PENUTUP

A.  Kesimpulan
                   UML adalah tools untuk merancang atau membuat software          berorientasi objek. Dengan 10 macam diagram untuk memodelkan aplikasi            berorientasi objek dengan fungsi yang berbeda.
         




DAFTAR PUSTAKA


0 komentar:

Poskan Komentar

Kaidar Billy Yachsie. Diberdayakan oleh Blogger.