UML

Artikel P.S.B.O : UML (Unified Modelling Language)

Pengertian dan Sejarah UML (Unified Modelling Language)

UML (Unified Modeling Language) adalah sebuah bahasa untuk menetukan, visualisasi, kontruksi, dan mendokumentasikan artifact (bagian dari informasi yang digunakan atau dihasilkan dalam suatu proses pembuatan perangkat lunak. Artifact dapat berupa model, deskripsi atau perangkat lunak) dari system perangkat lunak, seperti pada pemodelan bisnis dan system non perangkat lunak lainnya.

UML (Unified Modeling Language) merupakan pengganti dari metode analisis berorientasi object dan design berorientasi object (OOA&D) yang dimunculkansekitar akhir tahun 80-an dan awal tahun 90-an.UML merupakan gabungan dari metode Booch, Rumbaugh (OMT) dan Jacobson. Tetapi UML ini akan mencakup lebih luas daripada OOA&D. Pada pertengahan pengembangan UML dilakukan standarisasi proses dengan OMG (Object Management Group) dengan harapan UML akan menjadi bahasa standar pemodelan pada  masa  yang  akan  datang. UML disebut sebagai bahasa pemodelan bukan metode. Kebanyakan metode terdiri paling sedikit prinsip, bahasa pemodelan dan proses. Bahasa pemodelan (sebagian besar grafik) merupakan notasi dari metode yang digunakan untuk mendesain secara cepat.

Bahasa pemodelan merupakan bagian terpenting dari metode. Ini merupakan bagian kunci tertentu untuk komunikasi. Jika anda ingin berdiskusi tentang desain dengan seseorang, maka Anda hanya membutuhkan bahasa pemodelan bukan proses yang digunakan untuk mendapatkan desain. 

Bagian-bagian utama dari UML adalah view, diagram, model element, dan general mechanism.

a. View

View digunakan untuk melihat sistem yang dimodelkan dari beberapa aspek yang berbeda. View bukan melihat grafik, tapi merupakan suatu abstraksi yang berisi sejumlah diagram.

Beberapa jenis view dalam UML antara lain: use case view, logical view, component view, concurrency view,dan deployment view.

b. Use case view

Mendeskripsikan fungsionalitas sistem yang seharusnya dilakukan sesuai yang diinginkan external actors. Actor yang berinteraksi dengan sistem dapat berupa user atau sistem lainnya.

View ini digambarkan dalam use case diagramsdan kadang-kadang dengan activity diagrams. Viewini digunakan terutama untuk pelanggan, perancang (designer), pengembang (developer), dan penguji sistem (tester).

c. Logical view

Mendeskripsikan bagaimana fungsionalitas dari sistem, struktur statis (class, object,dan relationship ) dan kolaborasi dinamis yang terjadi ketika object mengirim pesan ke object lain dalam suatu fungsi tertentu.

View ini digambarkan dalam class diagrams untuk struktur statis dan dalam state, sequence, collaboration, dan activity diagram untuk model dinamisnya. View ini digunakan untuk perancang (designer) dan pengembang (developer).

d. Component view

Mendeskripsikan implementasi dan ketergantungan modul. 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).

e. Concurrency view

Membagi sistem ke dalam proses dan prosesor.View ini digambarkan dalam diagram dinamis (state, sequence, collaboration, dan activity diagrams) dan diagram implementasi (component dan deployment diagrams) serta digunakan untuk pengembang (developer), pengintegrasi (integrator), dan penguji (tester).

g. Diagram

Diagram berbentuk grafik yang menunjukkan simbol elemen model yang disusun untuk mengilustrasikan bagian atau aspek tertentu dari sistem. 

        1. Use Case Diagram

Use case adalah abstraksi dari interaksi antara system dan actor. Use case bekerja dengan cara mendeskripsikan tipe interaksi antara user sebuah system dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah system dipakai. 

        2. Class Diagram
Class adalah dekripsi kelompok obyek-obyek dengan property, perilaku (operasi) dan relasi yang sama. Sehingga dengan adanya class diagram dapat memberikan pandangan global atas sebuah system.

        3. Component Diagram
Component software merupakan bagian fisik dari sebuah system, karena menetap di komputer tidak berada di benak para analis. Komponent merupakan implementasi software dari sebuah atau lebih class. Komponent dapat berupa source code, komponent biner, atau executable component.

        4. Deployment Diagram

Menggambarkan tata letak sebuah system secara fisik, menampakkan bagian-bagian software yang berjalan pada bagian-bagian hardware, menunjukkan hubungan komputer dengan perangkat (nodes) satu sama lain dan jenis hubungannya. Di dalam nodes,executeable component dan object yang dialokasikan untuk memperlihatkan unit perangkat lunak yang dieksekusi oleh node tertentu dan ketergantungan komponen.

     

        5. State Diagram

Menggambarkan semua state (kondisi) yang dimiliki oleh suatu object dari suatu class dan keadaan yang menyebabkan state berubah. Kejadian dapat berupa object lain yang mengirim pesan. State class tidak digambarkan untuk semua class, hanya yang mempunyai sejumlah state yang terdefinisi dengan baik dan kondisi class berubah oleh stateyang berbeda.

        6. Sequence Diagram

Sequence Diagram digunakan untuk menggambarkan perilaku pada sebuah scenario. Kegunaannya untuk menunjukkan rangkaian pesan yang dikirim antara object juga interaksi antara object, sesuatu yang terjadi pada titik tertentu dalam eksekusi sistem.

        7. Collaboration Diagram

Menggambarkan kolaborasi dinamis sepertisequence diagrams. Dalam menunjukkan pertukaran pesan, collaboration diagrams menggambarkan objectdan hubungannya (mengacu ke konteks). Jika penekannya pada waktu atau urutan gunakan sequence diagrams, tapi jika penekanannya pada konteks gunakan collaboration diagram.

         8. Activity Diagram

Menggambarkan rangkaian aliran dari aktivitas, digunakan untuk mendeskripsikan aktifitas yang dibentuk dalam suatu operasi sehingga dapat juga digunakan untuk aktifitas lainnya seperti use caseatau interaksi.

Tujuan Penggunaan UML

1. Memberikan bahasa pemodelan yang bebas dari berbagai bahas pemrograman dan proses rekayasa.
2. Menyatukan praktek-praktek terbaik yang terdapat dalam pemodelan.
3. Memberikan model yang siap pakai, bahsa pemodelan visual yang ekspresif untuk mengembangkan dan saling menukar model dengan mudah dan dimengerti secara umum.
4. UML bisa juga berfungsi sebagai sebuah (blue print) cetak biru karena sangat lengkap dan detail. 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).

Perangkat lunak yang mendukung pembuatan diagram UML

1. StarUML (http://staruml.sourceforge.net/en/)

StarUML adalah sebuah proyek open source untuk mengembangkan cepat, fleksibel, extensible, featureful, dan bebas-tersedia UML / platform MDA berjalan pada platform Win32.Tujuan dari proyek StarUML adalah untuk membangun sebuah alat pemodelan perangkat lunak dan juga platform yang menarik adalah pengganti alat UML komersial seperti Rational Rose, Bersama dan sebagainya.

2. Acceleo (http://www.acceleo.org/pages/home/en)

Acceleo adalah generator kode yang mengubah model menjadi kode. Acceleo mudah digunakan dan menyediakan “dari rak” generator (Jee,. Bersih, Php …) dan template editor untuk Eclipse.

3. ArgoUML (http://argouml.tigris.org/)

ArgoUML adalah open source UML modeling tool terkemuka dan termasuk dukungan untuk semua diagram UML standar 1,4. Ini berjalan pada setiap platform Java dan tersedia dalam bahasa sepuluh. ArgoUML ditulis seluruhnya di Jawa dan menggunakan Java Kelas Foundation.Hal ini memungkinkan ArgoUML untuk berjalan di hampir semua platform.

Sejarah UML

UML dimulai secara resmi pada oktober 1994, ketika Rumbaugh bergabung dengan Booch pada Relational Software Corporation. Proyek ini memfokuskan pada penyatuan metode Booch dan OMT. UML versi 0.8 merupakan metode penyatuanyang dirilis pada bulan Oktober 1995. Dalam waktu yang sama, Jacobson bergabung dengan Relational dan cakupan dari UML semakin luas sampai diluar perusahaan OOSE. Dokumentasi UML versi 0.9 akhirnya dirilis pada bulan Juni 1996. Meskipun pada  tahun 1996 ini  melihat dan  menerima feedback dari  komunitas Software Engineering.

Dalam waktu tersebut, menjadi lebih jelas bahwa beberapa organisasi perangkat lunak melihat UML sebagai strategi dari bisnisnya. Kemudian dibangunla hUML Consortium dengan beberapa organisasi yang akan menyumbangkan sumber dayanya untuk bekerja, mengembangkan, dan melengkapi UML. Di sini beberapa partner yang berkontribusi pada UML 1.0, diantaranya Digita lEquipment Corporation, Hewlett-Packard, I-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Relational, Texas Instruments dan Unisys. Dari kolaborasi ini dihasilkan UML 1.0 yang merupakan bahasa pemodelan yang ditetapkan secara baik,expressive, kuat, dan cocok untuk lingkungan masalahyang luas. UML 1.0 ditawarkan menjadi standarisasi dari Object Management Group (OMG). Dan pada Januari 1997 dijadikan sebagai standar bahasa pemodelan.

Antara Januari–Juli 1997 gabungan group tersebut memperluas kontribusinya sebagai hasil respon dari OMG dengan memasukkan Adersen Consulting, Ericsson, Object Time Limeted, Platinum Technology, Ptech, Reich Technologies, Softeam,Sterling Software dan Taskon. Revisi dari versi UML (versi 1.1) ditawarkan kepada OMG sebagai standarisasi pada bulan Juli 1997. Dan pada bulan September 1997,versi ini dierima oleh OMG Analysis dan Design Task Force (ADTF) dan OMG Architecture Board. Dan Akhirnya pada Juli 1997 UML versi 1.1 menjadi standarisasi.

Pemeliharaan UML terus dipegang oleh OMG Revision Task Force (RTF) yang dipimpin oleh Cris Kobryn. RTP merilis editorial dari UML 1.2 pada Juni 1998. Danpada tahun 1998 RTF juga merilis UML 1.3 disertai dengan user guidedan memberikan technical cleanup.

Artikel Ini Dibuat Untuk Memenuhi Tugas Pemodelan Sistem Berbasis Objek Komputerisasi Akuntansi BSI Pada Dosen SDK

  

         

        

        

Activity Diagram

Artikel P.S.B.O : Activity Diagram

Activity Diagram (UML)

Activity Diagram merupakan teknik untuk menjelaskan bussines process, procedural logic, dan work flow bisa dipakai untuk menjelaskan use case text dalam notasi grafis.

        Langkah pertama yang harus dilakukan untuk memodelkan perangkat lunak adalah dengan membuat model proses bisnis. Proses bisnis yang dimaksudkan disini adalah proses yang terkait dengan urutan langkah, cara kerja atau bagaimana kita melakukan pekerjaan tertentu. Urutan langkah atau cara kerja inilah yang akan dibangun pada perangkat lunak. Pemodelan proses bisnis dapat dibagai menjadi dua bagian. Bagian pertama disebut identifikasi problem domain. bagian ini, tim pengembang bekerja sama dengan stakeholders berusaha untuk menemukan setiap permasalahan yang ada dalam proses bisnis.
Proses ini dapat dilakukan dengan melalui wawancara, menyebarkan kuesioner ataupun melakukan diskusi. Setelah dilakukan identifikasi problem domain, maka dilanjutkan dengan menyimpulkan kebutuhan user/stakeholders terkait dengan perangkat lunak yang akan dibangun.  Pada tahap ini, penting sekali untuk disepakati bersama kebutuhan-kebutuhan apa yang akan diselesaikan oleh perangkat lunak. Bagian kedua pemodelan proses bisnis adalah identifikasi solution domain. Solution domain dimulai dengan mengidentifikasi features (berdasarkan needs yang ada) yang harus dibangun pada perangkat lunak. Berdasarkan features ini kemudian ditentukanlah software specification requirements yang akan dibangun. Jika akan menggunakan UML maka kakas pemodelan yang bisa digunakan dalam pemodelan proses bisnis ini adalah Activity Diagram, Business Use-case Model, Business Object Model (BOM) dan Use-case Diagram.

Activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu Notasi dalam Activity Diagram. 

Cara menggambarkan activity diagram:

•       .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.
• .      Untuk dapat menggambarkan activity diagram dengan baik, disarankan agar membuat daftar sejumlah aktivitas beserta dengan kondisinya. Tools FDD dapat menjadi sangat berguna untuk mengecek proses-proses serta jalur aktivitas, baik dari level atas maupun level rincinya. 

Tambahan tentang Activity Diagram: 

             

             Sebuah Activity diagram dalam business use-case menggambarkan workflow (aliran kerja) sebuah business use-case. Workflow dari sebuah business use-case menggambarkan apa yang harus dikerjakan bisnis tersebut untuk menghasilkan nilai tertentu untuk business actor yang bersangkutan.

Artikel Ini Dibuat Untuk Memenuhi Tugas Pemodelan Sistem Berbasis Objek Komputerisasi Akuntansi BSI Pada Dosen SDK

  

 

OOP

Artikel P.S.B.O : OOP

Pengertian Object Oriented Programing

Object Oriented Programing adalah sebuah paradigma pemrograman, yang beranggapan bahwa semua komponen dalam sebuah aplikasi adalah sebuah objek. Dengan paradigma seperti ini, diharapkan aplikasi bisa lebih modular. Konsep Object-Oriented-Programing Sebagaimana dinyatakan di atas, pemrograman berorientasi obyek adalah gaya pemrograman yang memungkinkan developer untuk membagi kelompok program yang sejenis ke dalam sebuah kelas.Hal ini membantu menjaga kode agar “don’t repeat yourself”

 (DRY) dan mudah dalam maintenance.

Tehnik Pemodelan Object

Teknik pemodelan objek menggunakan tiga macam model untuk

menggambarkan sistem :

A. Model Objek

􀂾 Model objek menggambarkan struktur statis dari suatu

objek dalam sistem dan relasinya

􀂾 Model objek berisi diagram objek. Diagram objek adalah

graph dimana nodenya adalah kelas yang mempunyai

relasi antar kelas.

B. Model Dinamik

􀂾 Model dinamik menggambarkan aspek dari sistem yang

berubah setiap saat.

􀂾 Model dinamik dipergunakan untuk menyatakan aspek kontrol

dari sistem.

􀂾 Model dinamik berisi state diagram. State diagram adalah

graph dimana nodenya adalah state dan arc adalah transisi

antara state yang disebabkan oleh event.

C. Model Fungsional

􀂾 Model fungsional menggambarkan transformasi nilai

data di dalam sistem.

􀂾 Model fungsional berisi data flow diagram. DFD

adalah suatu graph dimana nodenya menyatakan

proses dan arcnya adalah aliran data.

Manfaat dan Penerapan Object Oriented Programing

Salah satu manfaat utama dari pemrograman dengan konsep DRY di atas adalah bahwa, jika ada perubahan informasi dalam sebuah program, developer biasanya hanya perlu melakukan satu perubahan yang diperlukan untuk memperbarui kode. Salah satu mimpi buruk terbesar bagi pengembang adalah memaintenance kode aplikasi dimana banyak data yang redundant, yang berarti bahwa perubahan sekecil apapun pada sebuah program menjadi sebuah permainan yang lebih membuat frustasi daripada memikirkan negara kita tercinta ini. 

Kesimpulan Object Oriented Programing

mengintimidasi banyak developer karena memperkenalkan sebuah sintaks baru dan, dengan polosnya, muncul menjadi jauh lebih kompleks daripada kode prosedural sederhana, atau inline. 

Namun, jika kita pelajari dengan seksama, OOP sebenarnya adalah sebuah pendekatan 

Artikel Ini Dibuat Untuk Memenuhi Tugas Pemodelan Sistem Berbasis Objek Komputerisasi Akuntansi BSI Pada Dosen SDK

  

Use Case Diagram

Artikel P.S.B.O : Use Case Diagram

USE CASE DIAGRAM

          Use case diagram adalah gambaran graphical dari beberapa atau semua actor, use case, dan interaksi diantara komponen-komponen tersebut yang memperkenalkan suatu sistem yang akan dibangun. Use case diagram menjelaskan manfaat suatu sistem jika dilihat menurut pandangan orang yang berada di luar sistem. 
         Diagram ini menunjukkan fungsionalitas suatu sistem atau kelas dan bagaimana sistem tersebut berinteraksi dengan dunia luar. Biasanya dibuat pada awal pengembangan. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem. 

- Actor

        Use case diagram dapat digunakan selama proses analisis untuk menangkap requirements sistem dan untuk memahami bagaimana sistem seharusnya bekerja. Selama tahap desain, use case diagram berperan untuk menetapkan perilaku (behavior) sistem saat diimplementasikan. Kebutuhan atau requirements sistem adalah fungsionalitas apa yang harus disediakan oleh sistem kemudian didokumentasikan pada model use case yang menggambarkan fungsi sistem yang diharapkan (use case), dan yang mengelilinginya (actor), serta hubungan antara actor dengan use case (use case diagram) itu sendiri. 

       Actor menggambarkan orang, sistem atau entitas luar yang menyediakan informasi atau menerima informasi dari sistem. Actor menggambarkan sebuah tugas/peran dan bukannya posisi sebuah jabatan. Actor biasanya menggunakan Kata benda. 

-Use Case

      Use case menggambarkan perilaku, termasuk didalamnya interaksi antara actor dengan sistem. Use case dibuat berdasarkan keperluan actor, merupakan “apa” yang dikerjakan sistem bukan “bagaimana” sistem mengerjakannya. setiap use case harus diberi nama yang menyatakan apa hal yang dicapai dari hasil interaksinya dengan actor.

• Association antara actor dan use case

Ujung panah pada association antara actor dan use case mengindikasikan siapa/apa yang meminta interaksi dan bukannya mengindikasikan aliran data Sebaiknya gunakan Garis tanpa panah untuk association antara actor dan use case

association antara actor dan use case yang menggunakan panah terbuka untuk mengindikasikan bila actor berinteraksi secara pasif dengan system kita

didalam use case lain (required) / (diharuskan) Pemanggilan use case oleh use case lain, contohnya adalah pemanggilan sebuah fungsi program Tanda panah terbuka harus terarah ke sub use case Gambarkan association include secara horizontal.

                            Contoh :

• Generalization / Inheritance antara Use Case

Generalization dipakai ketika ada sebuah perilaku khusus (single condition) dan merupakan pola hubungan base – parent use case. Digambarkan dengan generalization / inheritance antar use case secara vertical dengan inheriting use case dibawah base / parent use case.

• Generalization / Inheritance antara Actors

Digambarkan generalization / Inheritance antara Actors secara vertical dengan inheriting actor dibawah base / parents use case.

Artikel Ini Dibuat Untuk Memenuhi Tugas Pemodelan Sistem Berbasis Objek Komputerisasi Akuntansi BSI Pada Dosen SDK

 

Class Diagram

Artikel P.S.B.O : Class Diagram

Pengertian Class Diagram

Class diagram digunakan untuk menampilkan kelas-kelas dan paket-paket di dalam system. Class diagram memberikan gambaran system secara statis dan relasi antar mereka. Biasanya, dibua beberapa class diagram untuk system tunggal. Beberapa diagram akan menampilkan subset dari kelas-kelas dan relasinya. Dapat dibuat beberapa diagram sesuai dengan yang diinginkan untuk mendapatkan gambaran lengkap terhadap system yang dibangun.

Class diagram adalah alat perancangan terbaik untuk tim pengembang. Diagram tersebut membantu pengembang mendapatkan struktur system sebelum kode ditulis, dan membantu untuk memastikan bahwa system adalah desain terbaik.

-          Kelas

Kelas adalah sesuatu yang membungkus informasi dan perilaku. Secara tradisional, system dibangun dengan ide dasar bahwa akan menyimpan informasi pada sisi baris data dan data perilaku pengolahnya pada sisi aplikasi. Salah satu perbedaan terstruktur dengan pendekatan berorientasi obyek adalah

pada berorientasi obyek menggabungkan informasi dan perilaku pengolah informasi dan menyembunyikan semua kedalam sesuatu yang disebut kelas. Dalam UML, kelas ditunjukkan menggunakan notasi sebagai berikut.

Bagian paling atas pada notasi Class digunakan sebagai nama kelas, dan secara opsional juga digunakan stereotype-nya. Bagian tengah digunakan untuk menyimpan atribut, dan bagian paling bawah digunakan menyimpan operasi.

-          Menentukan kelas

Cara yang baik untuk menemukan kelas-kelas adalah mulai dari memperhatikan aliran kejadian (flow of event) dari suatu use case. Perhatikan kata benda didalam aliran kejadian, mungkin merupakan salah satu dari empat hal berikut :

1.      Actor

2.      Kelas

3.      Atribut dari kelas

4.      Ekspresi, bukan actor, bukan kelas, dan bukan atribut.

Dengan melakukan seleksi kata benda dalam aliran kejadian, dapat ditemukan kelas-kelas dalam system. Alternative lainnya, dapat di uji obyek-obyek dalam sequence diagram dan collaboration diagram.

Ada dua cara yang biasa dilakukan berkaitan dengan urutan pendefinisian antar kelas-kelas dalam class diagram dan sequence diagram atau collaboration diagram. Yang pertama, dengan membuat sequence diagram atau collaboration diagram lebih dulu. Kemudian melanjutkannya dengan membuat class diagram. Sebaliknya, yang kedua, yaitu dengan menemukan kelas-kelas dan membuat class diagram terlebih dahulu, kemudian menggunakan kelas-kelas terebut sebagai “Kamus” obyek-obyek dan relasinya untuk membuat sequence diagram atau collaboration diagram.

-          Stereotype pada kelas

Stereotype adalah sebuah mekanisme yang digunakan untuk mengkategorikan kelas-kelas. Misalnya, dapat dibuat stereotype form lebih dulu, kemudian menentukan kelas-kelas dilangkah selanjutnya. Fitur ini membantu untuk lebih memahami tanggung jawab terhadap masing-masing kelas dalam model. Kelas-kelas dengan stereotype ‘form’ bertanggung jawab menampilkan dan menerima informasi dari pemakai.

Stereotype juga membantu dalam proses pembangkitan kode. Ketika proses pembangkitan kode, stereotype kelas menentukan tipe kelas yang akan dibawa kebahasa pemrograman, beberapa Stereotype dapat digunakan sejak pada tahap proses analisis

Ketika analisis, kelas-kelas dapat dikategorikan menurut fungsi yang mereka lakukan. Ada 3 tipe Stereotype kelas dalam UML yang digunakan pada analisis, yaitu : pembatas (boundry), entitas(entity) dan control.

a.       Kelas-kelas pembatas

Kelas-kelas pembatas adalah kelas-kelas yang terletak antara system dengan dunia sekililingnya. Semua form, laporan-laporan, antarmuka(interface) keperangkat lunak seperti Printer atau scanner, dan antar muka (interface) ke system lainnya adalah termasuk dalam kategori ini.

Untuk menemukan dan mengidentifikasi kelas-kelas pembatas dapat dilakukan dengan menguji diagram use case. 

b.      Kelas-kelas entitas

Kelas-kelas entitas menangani informasi yang disimpan dalam penyimpanan tetap. Kelas entitas biasanya ditemukan dalam aliran kejadian (flow of event) pada diagram interaksi. Kelas entitas biasanya ditemukan dalam aliran kejadian (flow of event) pada diagram interaksi.

c.       Kelas-kelas Kontrol

Kelas kontrol bertanggung jawab untuk mengkoordinasikan kegiatan-kegiatan terhadap kelas lainnya. Kelas ini bersifat opsional, tetapi jika kelas Kontrol ini digunakan, maka secara tropical satu kelas control untuk satu use case tersebut.

-          Penamaan kelas

Masing-masing kelas harus mempunyai nama yang unik. Sebagian besar organisasi mempunyai konvensi penamaan sendiri untuk menamakan kelas-kelas yang dibuatnya. 

-          Visibilitas kelas

Pilihan visibilitas menentukan dapat tidaknya sebuah kelas dilihat dari luar paket. Ada 3 pilihan visibilitas untuk sebuah kelas yaitu :

1.      Public

2.      Menyatakan bahwa sebuah kelas dapat dilihat dari kelas-kelas lainnya dalam system.

3.      Protected atau private.

Artikel Ini Dibuat Untuk Memenuhi Tugas Pemodelan Sistem Berbasis Objek Komputerisasi Akuntansi BSI Pada Dosen SDK

  

-