Sejarah Singkat UML

Unified Modelling Language (UML) adalah sebuah "bahasa" yang telah menjadi standar
dalam industri untuk menentukan, visualisasi, merancang dan mendokumentasikan artifact dari
sistem software, untuk memodelkan bisnis dan sistem non software lainnya. UML merupakan suatu
kumpulan teknik terbaik yang telah terbukti sukses dalam memodelkan sistem yang besar dan
kompleks.
Dengan menggunakan UML kita dapat membuat model untuk semua jenis aplikasi piranti
lunak, dimana aplikasi tersebut dapat berjalan pada piranti keras, sistem operasi dan jaringan
apapun, serta ditulis dalam bahasa pemrograman apapun. Tetapi karena UML juga menggunakan
class dan operation dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak
dalam bahasa-bahasa berorientasi objek seperti C++, Java, VB.NET. Walaupun demikian, UML
tetap dapat digunakan untuk modeling aplikasi prosedural dalam VB atau C.
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 bentukbentuk 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, metodologi Coad , metodologi OOSE, metodologi OMT, metodologi ShlaerMellor, metodologi Wirfs-Brock, dan sebagainya. 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 bekerja
sama dengan group/perusahaan lain yang menggunakan metodologi yang berlainan.

Dimulai pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson, yang merupakan tiga
tokoh yang boleh dikatakan 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). Tahun 1997 UML versi 1.1 muncul, dan saat ini versi terbaru
adalah versi 1.5 yang dirilis bulan Maret 2003. Booch, Rumbaugh dan Jacobson menyusun tiga
buku serial tentang UML pada tahun 1999. Sejak saat itulah UML telah menjelma menjadi standar
bahasa pemodelan untuk aplikasi berorientasi objek.
Object Management Group, Inc. (OMG) adalah sebuah organisasi international yang dibentuk pada
1989, didukung lebih dari 800 anggota, terdiri dari perusahaan sistem informasi, software
developer, dan pada user system komputer. organisasi ini salah satunya bertugas membuat
spesifikasi manajemen objek untuk menetapkan kerangka bersama dalam rekayasa software.
Sasaran OMG adalah membantu perkembangan object-oriented technology dan mengarahkannya
dengan mendirikan Object Management Architecture (OMA). OMA menentukan infrastruktur
konseptual yang didasarkan pada seluruh spesifikasi yang dikeluarkan OMG. OMG kemudian
mengeluarkan UML, dimana dengan adanya UML ini diharapkan dapat mengurangi kekacauan
dalam bahasa pemodelan yang selama ini terjadi dalam lingkungan industri. UML diharapkan juga
dapat menjawab masalah penotasian dan mekanisme tukar menukar model yang terjadi selama ini.
Pengertian UML
Unified Modeling Language ( UML ) adalah suatu bahasa yang telah menjadi standar
dalam industri untuk merancang, visualisasi dan mendokumentasikan sistem perangkat lunak[1].
Dalam pengertian lain UML merupakan graphical language untuk specifying, visualizing,

construction, dan documenting hal-hal yang ada dalam sistem perangkat lunak. UML diaplikasikan
untuk penyelesaian masalah dengan menggunakan konsep object oriented. Siapapun yang akan
mempelajari UML harus mengenal prinsip-prinsip yang digunakan dalam penyelesaian masalah
object oriented, dimana semuanya dimulai dengan pembuatan model. Sebuah model adalah
abstraksi dari sebuah masalah. Domain merupakan lingkungan nyata dimana sebuah masalah
datang. Model terdiri dari objek-objek yang berinteraksi dengan mengirim message satu sama lain.
Objek memiliki hal-hal yang mereka ketahui (attrribute) dan hal-hal yang dapat mereka lakukan
(behavior atau operation). Nilai dari atribut-atribut sebuah objek digambarkan dalam bentuk state.
Class merupakan blueprints dari objek. Class membungkus atribut-atribut (data) dan behavior
(method dan fungsi) dalam sebuah entiti tunggal yang jelas.
Tujuan UML :
a. Memberikan model yang siap pakai, bahasa pemodelan visual yang ekspresif untuk
mengembangkan dan saling menukar model dengan mudah dan dimengerti secara umum.
b. Memberikan bahasa pemodelan yang bebas dari berbagai bahasa pemrograman dan proses
rekayasa.
c. Menyatukan praktik-praktik terbaik yang terdapat dalam pemodelan.
Artifak UML
UML menyediakan beberapa notasi dan artifact standar yang bisa digunakan sebagai alat
komunikasi bagi para pelaku dalam proses analisis dan desain. Artifact didalam UML didefinisikan
sebagai informasi dalam bentuk yang digunakan atau dihasilkan dalam proses pengembangan
perangkat. Contohnya adalah source code yang dihasilkan oleh proses pemrograman.
Yang harus diperhatikan untuk menjaga konsistensi antar artifact selama proses analisis dan
desain adalah bahwa setiap perubahan yang terjadi pada satu artifact harus juga dilakukan pada
atifact sebelumnya.
Untuk membuat suatu model, UML memiliki diagram grafis sebagai berikut :
use case diagram
Use-case diagram merupakan suatu bentuk diagram yang menggambarkan fungsi-fungsi
yang diharapkan dari sebuah sistem yang dirancang. Dalam Use-case diagram penekanannya
adalah apa yag diperbuat oleh sistem, dan bukan bagaimana. Sebuah use-case akan
merepresentasikan sebuah interaksi antara pelaku atau actor dengan sistem. Use-case diagram
yang digunakan dalam merancang suatu sistem dapat sangat membantu pada saat kita
menyusun requirement sebuah sistem, mengomunikasikannya dengan klien, dan merancang

pengujian untuk semua fitur yang terdapat dalam sistem. Dalam suatu sistem aplikasi
database, use-case diagram sangat membantu requierement apa saja yang diperlukan.
Use case(s) diagram menjelaskan manfaat sistem jika dilihat menurut pandangan orang
yang berada di luar sistem (actor). Diagram ini menunjukkan fungsionalitas suatu sistem atau
kelas dan bagaimana sistem berinteraksi dengan dunia luar. Pada tahap analisa, Use case(s)
Diagram sangat berperan untuk menemukan requirement-requirement sistem dan untuk
memahami bagaimana sistem seharusnya bekerja. Dalam sebuah model mungkin terdapat satu
atau beberapa use case(s) diagram.Sebuah use case(s) diagram melukiskan :
a. Actor
Aktor merupakan istilah yang digunakan untuk menggambarkan pengguna aplikasi. Aktor
bisa berupa orang, hardware, atau sistem informasi lai yang berinteraksi dengan use.

Gambar 2.8. Simbol Actor

b. Use case
Use case menggambarkan perilaku software aplikasi, termasuk didalamnya interaksi antara
aktor dengan software aplikasi.Use case dibuat berdasarkan proses-proses yang dilakukan
untuk kepentingan aktor untuk menggambarkan apa yang dikerjakan oleh aplikasi, bukan
bagaimana aplikasi mengerjakannya (logical)

Gambar 2.9. Simbol Use Case

c. Association
Asosiasi merupakan komunikasi antara aktor dengan use case, digambarkan sebagai sebuah
garis lurus tanpa putus antara aktor dan use case. Gambar di bawah melukiskan asosiasi
(hubungan) antara aktor admin dalam melakukan proses setup (usecase setup)

Gambar 2.10. Simbol Asosiasi Biasa

d. Extend
Extend digunakan untuk menggambarkan hubungan antar use case yang menunjukkan
bahwa satu use case merupakan fungsionalitas dari use case yang lain jika kondisi atau
syarat tertentu dipenuhi.

Gambar 2.11. Asosiasi Extend

e. Include
Hubungan includemenggambarkan bahwa satu use case seluruhnya meliputi fungsionalitas
dari use case lainnya.

Gambar 2.12. Asosiasi Include

Setiap use case pada use case diagram dijelaskan secara detail di use case specification
dengan format:
1. Nama use case : Nama use case untuk setiap simbol elips yang ada.
2. Aktor yg terlibat : Aktor yang terlibat di dalam use case.
3. Purpose : Tujuan use case
4. Description : Deskripsi singkat use case
5. Type : Tipe use case
6. Pre-condition : Kondisi atau syarat awal sebelum use case dilakukan.

7. Post condition : Kondisi setelah use case dilakukan.

8. Typical course of event : Penjelasan interaksi aktor dan sistem dalam use case.
Contoh use case diagram :

class diagram
Sebuah Class Diagram menunjukkan struktur yang statis dari beberapa class dalam suatu
sistem. Class-class merepresentasikan suatu keadaan (atribut/properti) dan yang akan
dikerjakan oleh sistem (metoda/fungsi)

Class memiliki tiga area pokok :

1. Nama (dan stereotype)
2. Atribut
3. Metoda
Atribut dan metoda dalam class diagram dapat memiliki salah satu sifat seperti berikut di
bawah ini :
Private, hanya dapat diakses oleh class itu sendiri.
Protected, hanya dapat diakses oleh class itu sendiri dan turunan dari class tersebut.

 Public, dapat diakses oleh class selain dari class yang bersangkutan.
Class dapat direpresentasikan dalam sebuah interface atau sebaliknya merupakan
implementasi dari sebuah interface yang berupa class abstrak yang hanya tidak memiliki
attribute dan hanya memiliki metoda.
Berikut merupakan bentuk class diagram secara umum :

Class diagram digunakan untuk memvisualisasikan struktur kelas-kelas dari suatu sistem.
tiga jenis relasi penting yang menghubungkan obyek, yaitu:
1. Association
Association merupakan suatu relationship antar dua atau lebih classifier yang menyangkut
hubungan antar instance. Jenis hubungan association digambarkan pada gambar di bawah
ini.

Gambar 2.13. Asosiasi Class

2. Agregation
Agregation merupakan bentuk lain dari association yang menerangkan hubungan wholepart antara agregate class (whole) dan component part. Jenis hubungan agregation
digambarkan pada di bawah ini.

Gambar 2.14. Agregasi Class

3. Generalization
Generalization merupakan sebuah taxonomic relationship antara class yang lebih umum
dengan class yang lebih khusus. Jenis hubungan generalization digambarkan pada gambar

di bawah ini.

behavior diagram
statechart diagram
State Diagram mengambarkan seluruh state yang memungkinkan yang mana
obyek-obyek dalam class dapat dimiliki dan kejadian-kejadian yang menyebabkan state
berubah. Perubahan dalam suatu state disebut juga transisi (transition). Suatu transisi
juga dapat memiliki sebuah aksi yang dihubungkan pada state, lebih spesifik apa yang
harus dilakukan dalam hubungannya dengan transisi state.

activity diagram
Diagram ini memodelkan alur kerja (workflow)sebuah proses bisnis dan urutan
aktivitas dalam suatu proses untuk dapat memahami proses secara keseluruhan. Activity

diagram juga sangat berguna ketika ingin menggambarkan perilaku pararel atau
menjelaskan bagaimana prilaku dalam berbagai use case berinteraksi.
Sebuah Activity Diagram menunjukkan suatu alur kegiatan secara berurutan. Activity
Diagram digunakan untuk mendiskripsikan kegiatan-kegiatan dalam sebuah operasi
meskipun juga dapat digunakan untuk mendeskripsikan alur kegiatan yang lainnya
seperti use case atau suatu interaksi.
Contoh Activity Diagram

interaction diagram
o sequence diagram
Sequence Diagram merupakan diagram yang mengambarkan kolaborasi yang
dinamis antara obyek satu dengan yang lain. Kolaborasi

ditunjukkan dengan adanya interaksi antar obyek di dalam dan di sekitar sistem yang berupa pesan
atau instruksi yang berurutan.
Sequence diagram umumnya digunakan untuk menggambarkan suatu skenario atau urutan
langkah-langkah yang dilakukan baik oleh actor maupun sistem yang merupakan respon dari
sebuah kejadian untuk mendapatkan hasil atau output.
Sebuah sequence diagram merupakan gambaran secara grafis dari sebuah skenario yang
menunjukkan interaksi obyek dalam sebuah urutan waktu apa yang terjadi pertama kali dan

apa yang terjadi berikutnya. Diagram ini secara khusus berasosiasi dengan use case. Sequence
diagram memperlihatkan tahap demi tahap apa yang seharusnya dilakukan untuk menghasilkan
sesuatu di dalam use case. Diagram ini sangat diperlukan pada tahap analisis atau tahap awal
desain sistem.
Berikut adalah gambaran simbol dan notasi yang digunakan dalam sequence diagram:

Contoh Sequence diagram

o collaboration diagram
Sebuah collaboration diagram menunjukkan kolaborasi yang dinamis yang mirip dengan
sequence diagram. Collaboration diagram digambarkan sebagai sebuah obiject diagram
dimana sejumlah obyek ditunjukkan disekitarnya dengan hubungan-hubungannya.
Contoh Collaboration Diagram

 implementation diagram
component diagram
Component Diagram menunjukkan struktur dan hubungan antar komponen software termasuk
ketergantungan (dependency) diantara komponen-komponen tersebut.

Komponen pada piranti lunak adalah berupa modul-modul yang berisikan code, baik library
maupun executable. Umumnya komponen yang terbentuk dari beberapa class dan/atau
package, atau juga dapat dari komponen-komponen yang lebih kecil.
Contoh Component Diagram

 deployment diagram
Deployment Diagram menunjukkan arsitektur fisik pada hardware dan software pada suatu
sistem yang dirancang. Deployment diagram juga dapat menunjukkan perngkat-perangkat dan
nodes diantara hubungan yang dimilikinya antar komponen.

Contoh Deployment Diagram

Diagram-diagram tersebut diberi nama berdasarkan sudut pandang yang berbeda-beda

terhadap sistem dalam proses analisis atau rekayasa.

Dibuatnya berbagai jenis diagram diatas karena :

Setiap sistem yang kompleks selalu paling baik jika didekati melalui himpunan berbagai sudut
pandang yang kecil yang satu sama lain hampir saling bebas (independent). Sudut pandang
tunggal senantiasa tidak mencukupi untuk melihat sistem yang besar dan kompleks.
Diagram yang berbeda-beda tersebut dapat menyatakan tingkatan yang berbeda-beda dalam proses
rekayasa.
Diagram-diagram tersebut dibuat agar model yang dibuat semakin mendekati realitas.
2.2.4 Semantik Dalam UML
OMG telah menetapkan semantik (makna istilah) semua notasi UML dalam model struktural
dan model behavior. Model struktural (model statis), menekankan stuktur obyek dalam sebuah
sistem, menyangkut kelas-kelas, interface, atribut dan hubungan antar komponen. Model behavioral
(model dinamis), menekankan perilaku obyek dalam sebuah sistem, termasuk metode, interaksi,
kolaborasi dan state history.
2.2.5 Cakupan UML
Pertama, UML menggabungkan konsep Booch, OMT dan OOSE, sehingga UML
merupakan suatu bahasa pemodelan tunggal yang umum dan digunakan secara luas oleh para user
ketiga metode tersebut dan bahkan para user metode lainnya.
Kedua, UML menekankan pada apa yang dapat dikerjakan dengan metode-meode tersebut.
Ketiga, UML berfokus pada suatu bahasa pemodelan standar, bahkan pada proses standar.
Meskipun UML harus diaplikasikan dalam konteks sebuah proses, dari pengalaman, bahwa
organisasi dan masalah yang berbeda juga memerlukan proses yang berbeda pula.
UML tidak mencakup :
Bahasa Pemrograman UML adalah bahasa pemodelan visual, bukan dimaksudkan untuk
menjadi suatu bahasa pemrograman visual, tetapi UML memberikan arah untuk bergerak kearah
kode.
Tool (software aplikasi) pemodelan
Membuat standar sebuah bahasa diperlukan oleh tool-tool dan proses. UML mendefinisikan
semantik dan notasi, bukan sebuah tool. Contoh tool yang menggunakan UML sebagai
bahasanya adalah Rational Rose dan Architect.
Proses rekayasa
UML digunakan sebagai bahasa dalam proyek dengan proses yang berbeda-beda. UML bebas
dari proses dan mendefinisikan sebuah proses standar bukan tujuan UML atau RFP dari OMG.
Dalam pembahasan ini kita akan menggunakan sebuah proses yang dikeluarkan Rational
Software, yaitu Rational Unified Process (RUP)
Notasi Dalam UML
Actor

Actor menggambarkan segala pengguna software aplikasi (user). Actor memberikan suatu
gambaran jelas tentang apa yang harus dikerjakan software aplikasi. Sebagai contoh sebuah actor
dapat memberikan input kedalam dan menerima informasi dari software aplikasi, perlu dicatat
bahwa sebuah actor berinteraksi dengan use case, tetapi tidak memiliki kontrol atas use case.
Sebuah actor mungkin seorang manusia, satu device, hardware atau sistem informasi lainnya.
Use Case

Use case menjelaskan urutan kegiatan yang dilakukan actor dan sistem untuk mencapai
suatu tujuan tertentu. Walaupun menjelaskan kegiatan, namun use case hanya menjelaskan apa yang
dilakukan oleh actor dan sistem bukan bagaimana actor dan sistem melakukan kegiatan tersebut.
Use-case Konkret adalah use case yang dibuat langsung karena keperluan actor. Actor dapat melihat
dan berinisiatif terhadapnya
Use-case Abstrak adalah use case yang tidak pernah berdiri sendiri. Use case abstrak
senantiasa termasuk didalam (include), diperluas dari (extend) atau memperumum (generalize) use
case lainnya. Untuk menggambarkannya dalam use case model biasanya digunakan association
relationship yang memiliki stereotype include, extend atau generalization relationship. Hubungan
include menggambarkan bahwa suatu use case seluruhnya meliputi fungsionalitas dari use case
lainnya. Hubungan extend antar use case berarti bahwa satu use case merupakan tambahan
fungsionalitas dari use case yang lain jika kondisi atau syarat tertentu terpenuhi.
Class

Class merupakan pembentuk utama dari sistem berorientasi obyek, karena class
menunjukkan kumpulan obyek yang memiliki atribut dan operasi yang sama. Class digunakan
untuk mengimplementasikan interface.
Class digunakan untuk mengabstraksikan elemen-elemen dari sistem yang sedang dibangun.
Class bisa merepresentasikan baik perangkat lunak maupun perangkat keras, baik konsep maupun
benda nyata.
Notasi class berbentuk persegi panjang berisi 3 bagian: persegi panjang paling atas untuk
nama class, persegi panjang paling bawah untuk operasi, dan persegi panjang ditengah untuk
atribut.
Atribut digunakan untuk menyimpan informasi. Nama atribut menggunakan kata benda yang
bisa dengan jelas merepresentasikan informasi yang tersimpan didalamnya. Operasi menunjukkan

sesuatu yang bisa dilakukan oleh obyek dan menggunakan kata kerja.
Interface

Interface merupakan kumpulan operasi tanpa implementasi dari suatu class. Implementasi
operasi dalam interface dijabarkan oleh operasi didalam class. Oleh karena itu keberadaan interface
selalu disertai oleh class yang mengimplementasikan operasinya. Interface ini merupakan salah satu
cara mewujudkan prinsip enkapsulasi dalam obyek.
Interaction

Interaction digunakan untuk menunjukkan baik aliran pesan atau informasi antar obyek
maupun hubungan antar obyek. Biasanya interaction ini dilengkapi juga dengan teks bernama
operation signature yang tersusun dari nama operasi, parameter yang dikirim dan tipe parameter
yang dikembalikan.
Note

Note digunakan untuk memberikan keterangan atau komentar tambahan dari suatu elemen
sehingga bisa langsung terlampir dalam model. Note ini bisa disertakan ke semua elemen notasi
yang lain.
Dependency

Dependency merupakan relasi yang menunjukan bahwa perubahan pada salah satu elemen
memberi pengaruh pada elemen lain. Elemen yang ada di
bagian tanda panah adalah elemen yang tergantung pada elemen yang ada dibagian tanpa
tanda panah.
Terdapat 2 stereotype dari dependency, yaitu include dan extend. Include menunjukkan
bahwa suatu bagian dari elemen (yang ada digaris tanpa panah) memicu eksekusi bagian dari
elemen lain (yang ada di garis dengan panah).
Extend menunjukkan bahwa suatu bagian dari elemen di garis tanpa panah bisa disisipkan
kedalam elemen yang ada di garis dengan panah.
Association

Association menggambarkan navigasi antar class (navigation), berapa banyak obyek lain
yang bisa berhubungan dengan satu obyek (multiplicity antar class) dan apakah suatu class menjadi
bagian dari class lainnya (aggregation).
Navigation dilambangkan dengan penambahan tanda panah di akhir garis. Bidirectional
navigation menunjukkan bahwa dengan mengetahui salah satu class bisa didapatkan informasi dari
class lainnya. Sementara UniDirectional navigation hanya dengan mengetahui class diujung garis
association tanpa panah kita bisa mendapatkan informasi dari class di ujung dengan panah, tetapi
tidak sebaliknya.
Aggregation mengacu pada hubungan has-a, yaitu bahwa suatu class memiliki class lain,
misalnya Rumah memiliki class Kamar.
Generalization

Generalization menunjukkan hubungan antara elemen yang lebih umum ke elemen yang
lebih spesifik. Dengan generalization, class yang lebih spesifik (subclass) akan menurunkan atribut
dan operasi dari class yang lebih umum (superclass) atau subclass is superclass. Dengan
menggunakan notasi generalization ini, konsep inheritance dari prinsip hirarki dapat dimodelkan.
Realization

Realization menunjukkan hubungan bahwa elemen yang ada di bagian tanpa panah akan
merealisasikan apa yang dinyatakan oleh elemen yang ada di bagian dengan panah. Misalnya class
merealisasikan package, component merealisasikan class atau interface.
Peran UML
UML adalah bahasa untuk
Visualisasi
Menggambarkan ide dalam notasi dan semantic yang lebih mudah dipahami oleh siapapun
Spesifikasi
spesifikasi dari semua keputusan penting analisa, perancangan, dan penerapan yang harus
diambil dalam pengembangan dan deployment sistem PL
Konstruksi
UML bukan bahasa pemrograman visual
Model UML dapat dihubungkan secara langsung dengan beberapa bahasa pemrograman
Forward engineering: menghasilkan kode dari model
Reverse engineering: membangun model dari kode
Dokumentasi

 UML mencakup dokumentasi arsitektur sistem dan rincinya

Sebagai suatu bahasa untuk menyatakan kebutuhan dan pengujian.
UML menyediakan bahasa untuk aktifitas perencanaan proyek dan manajemen release
Tool Pendukung UML
Tool-tool pendukung UML Saat ini banyak sekali tool-tool pendukung UML untuk mendesain
model suatu sistem, baik tool yang bersifat komersial maupun open source. Berikut dibawah
ini adalah beberapa diantaranya tool-tool yang sering digunakan dalam UML :
Rational Rose
Together
Object Domain
Jvision

Objecteering
MagicDraw
Visual ObjectModeller
Pengenalan Dasar Tool Rational Rose 2000
Rational Rose merupakan salah satu tool yang digunakan membangun model suatu sistem
secara visual yang memiliki banyak kemampuan untuk pembentukan sistem berorientasi
obyek yang menggunakan UML.
Dalam UML terdapat beberapa istilah yang sering digunakan seperti : views, diagram dan
elemen model.
1. View
Rational Rose memiliki empat view yaitu : Use Case View, Logical View, Componen View
dan Deployment View.
2. Diagram
Rational Rose 2000 memiliki delapan diagram yaitu : Use case diagram, Sequence
diagram, Collaboration diagram, Activity diagram, Class diagram, State diagram,
Component diagram dan Deployment diagram.
3. Elemen Model
Konsep-konsep yang digunakan dalam diagram merupakan elemen-elemen model yang
menyatakan konsep berorientasi obyek secara umum, seperti class, object dan message,
serta hubungan antar konsep termasuk association, dependency dan generalization
Study case ;
STUDIKASUS
ANALISASISTEMBERJALAN

Posedersistemberjalan
Perusahan bina sara indonesia adalah perusahaan dagang yang bergerak di bidang
distributorpenjualanelektronik(TV,Kulkas,Kipasangin,radiodanlainlain),perusahaan
inimenjualbarangelektronikkepadacustomersecaratunaidengannilaitransaksi Rp.
50.0000.0000, ( lima puluh juta rupiah ). Customer adalah badan usaha atau toko
pengecer yangmenjualproduknyakepedapelanggansecaraperorangan.Padaprosedur
sistemberjalanini,customerpadasaatmemesanbarangdiharuskanmelampiridokumen
POterlebihdahulu,danPOpalinglamasatumingguuntukdikonfirmasipadacustomer.
Makauntuklebihjelasnyaprosedurdarisistemberjalanadalahsebagaiberikut:
a.Prosedurorderpenjualan
Setiapcostemerdapatmemesanbarangdatanglangsungataumelaluifaxsimiledengan
menertakan dokumen PO yang diterima oleh bagian penjualan. Kemudian bagian
penjualanberdasarkanPO,memeriksapesanabarangdenganmenggunakankartustock,
apabila stock barang ada maka di nilai penjualan dihitung dan dicatat kedalam faktur
penjualandibuatrangkap4(empat)yangdidistribusikankekasir.
b.Prosedurpembayarantunai
Setelah customer mendapat konfirmasi tentang pesanan pembelian disetujui, maka
customer melakukan transaksi pembayaran melalui trasfer uang ke bank yang telah
ditunjukdenganbuktisetoran.Berdasarkanbuktisetoran,kasirmembukaarsippenjualan
yang dicocokkan dengan bukti setoran. Apabila sesuai dengan nilai penjualan maka
dibuatkan kwitansi lunas, dan merekap nilai penjualan harian. Distribusi dokumen
dokumenberdasarkannilaitransaksipenjualanpenjualansebagaiberikut:untukkwitansi
dan faktur penjualan di berikan kepada customer. Gudang mendapatkan tembusan
pengeluaranbarangdarikasirsesuaibarangyangdipesan,dancopyfakturdiberikanke
bagianpenjualan.
c.Prosedurpenyiapanbarangkirim
Gudangsetelahmenerimatembusanpengeluaranbarang,makamenyiapkanbarangyang
akan dikirim dengan mencatat barang keluar ke kartu gudang dan membuat dokumen
suratkeluarbarangyangditembuskankebagianpenjualan.
d.Prosedurpengirimanbarang
Bagian penjualan berdasarkan surat keluar barang, selanjutnya membuka arsip faktur
penjualanuntukmencatatbarangyangakandikirimdandicatatkedokumen suratjalan
untuk selanjutnya diserahkan kebagian pengiriman yang bertugas menirim barang ke
customer.
e.Prosedurpembuatanlaporan
Setiap akhir priode bagian penjualan membuat laporan penjualan bulanan berdasarkan
rekappenjualanhariandanfakturpenjualan.Danlaporanstockbarangkeluarberdasarkan
kartu stock. Kedua laporan tersebut diberikan kepada manajer penjualan untuk proses
evaluasipenjualanselamasatubulan.
PURCHASE
ORDER
PT. SUMBER
JAYA
Jl. Sutopo 01
Tangerang

Kepada Yth :
PT. BINA SARANA
INDONESIA

Jl. Ciledug Raya No108

cipulir
jakarta selatan.
No. PO

: 20-01-234

Tgl. PO

: 27/01/06

Harap Sdr
Kirim, Status
Kondisi
Barang :
[ Biasa/segera/
mendesak ]
No
1

Nama Barang
Kipas Angin

Merk
Miyako

Mesin Cuci

Denpo

Kulkas 1 Pintu

Panasonic

Kulkas 2 Pintu

Panasonic

TV 21` inc

LG

TV 14` inc

Polytron

Jumlah Pesan Harga Satuan Total Bayar

35
Rp. 150000 Rp. 5.250,000
Rp.
25
Rp. 1350000 33.750,000
Rp.
10
Rp. 1250000 12.500,000
Rp.
18
Rp. 1850000 33.300,000
Rp.
20
Rp. 1870000 37.400,000
Rp.
15
Rp. 750000
11.250,000
Syadza...

Nomer PO
harap
" Saudara
Cantumkan
dalam Faktur
dan Surat
Pengiriman."

Bag.
Pembelian

KamusDataDokumenMasukBarangFormulirPermintaanPesanan
NamaArusData:PurchaseOrder
Alias:PO
BentukData:CetakanManual
ArusData:CustomerProses0.0
Proses0.0ArsipPO
Penjelasan:UntukPesananPenjualanBarang

Periode:SetiapTerjadiPesananPenjualan
Volume:Ratarataperhari20PesananPenjualan
StrukturData:Header+isi
Header:No_PO+Tgl_PO+Nama_Customer+
Alamat_Customer+Status_kondisi_Barang
No_PO:*Terdiridari9digit*
Tgl_PO:Tgl+Bulan+Tahun
Status_Kond_Brg:[BiasalSegeralMendesak]
Isi:1{Nama_Brg+Merk+Jumlah_Pesan+
Harga_Satuan+Total_Bayar}20