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 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, metodologi Coad , metodologi OOSE, metodologi OMT, metodologi Shlaer-Mellor, 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 whole-part 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 ;

STUDI KASUS

ANALISA SISTEM BERJALAN

Poseder sistem berjalan

Perusahan bina sara indonesia adalah perusahaan dagang yang bergerak di bidang distributor penjualan elektronik ( TV, Kulkas, Kipas angin, radio dan lain-lain ), perusahaan ini menjual barang elektronik kepada customer secara tunai dengan nilai transaksi Rp. 50.0000.0000,- ( lima puluh juta rupiah ). Customer adalah badan usaha atau toko pengecer yang menjual produknya kepeda pelanggan secara perorangan. Pada prosedur sistem berjalan ini, customer pada saat memesan barang diharuskan melampiri dokumen PO terlebih dahulu, dan PO paling lama satu minggu untuk di konfirmasi pada customer. Maka untuk lebih jelasnya prosedur dari sistem berjalan adalah sebagai berikut:

a.Prosedur order penjualan

Setiap costemer dapat memesan barang datang langsung atau melalui faxsimile dengan menertakan dokumen PO yang diterima oleh bagian penjualan. Kemudian bagian penjualan berdasarkan PO, memeriksa pesana barang dengan menggunakan kartu stock, apabila stock barang ada maka di nilai penjualan dihitung dan dicatat kedalam faktur penjualan dibuat rangkap 4 ( empat ) yang di distribusikan ke kasir.

b.Prosedur pembayaran tunai

Setelah customer mendapat konfirmasi tentang pesanan pembelian disetujui, maka customer melakukan transaksi pembayaran melalui trasfer uang ke bank yang telah ditunjuk dengan bukti setoran. Berdasarkan bukti setoran, kasir membuka arsip penjualan yang dicocokkan dengan bukti setoran. Apabila sesuai dengan nilai penjualan maka dibuatkan kwitansi lunas, dan merekap nilai penjualan harian. Distribusi dokumen-dokumen berdasarkan nilai transaksi penjualan penjualan sebagai berikut : untuk kwitansi dan faktur penjualan di berikan kepada customer. Gudang mendapatkan tembusan pengeluaran barang dari kasir sesuai barang yang di pesan, dan copy faktur diberikan ke bagian penjualan.

c.Prosedur penyiapan barang kirim

Gudang setelah menerima tembusan pengeluaran barang, maka menyiapkan barang yang akan dikirim dengan mencatat barang keluar ke kartu gudang dan membuat dokumen surat keluar barang yang ditembuskan ke bagian penjualan.

d.Prosedur pengiriman barang

Bagian penjualan berdasarkan surat keluar barang, selanjutnya membuka arsip faktur penjualan untuk mencatat barang yang akan dikirim dan dicatat ke dokumen surat jalan untuk selanjutnya diserahkan kebagian pengiriman yang bertugas menirim barang ke customer.

e.Prosedur pembuatan laporan

Setiap akhir priode bagian penjualan membuat laporan penjualan bulanan berdasarkan rekap penjualan harian dan faktur penjualan. Dan laporan stock barang keluar berdasarkan kartu stock. Kedua laporan tersebut diberikan kepada manajer penjualan untuk proses evaluasi penjualan selama satu bulan.

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

Nama Barang

Merk

Jumlah Pesan

Harga Satuan

Total Bayar

1

Kipas Angin

Miyako

35

Rp. 150000

Rp. 5.250,000

2

Mesin Cuci

Denpo

25

Rp. 1350000

Rp. 33.750,000

3

Kulkas 1 Pintu

Panasonic

10

Rp. 1250000

Rp. 12.500,000

4

Kulkas 2 Pintu

Panasonic

18

Rp. 1850000

Rp. 33.300,000

5

TV 21` inc

LG

20

Rp. 1870000

Rp. 37.400,000

6

TV 14` inc

Polytron

15

Rp. 750000

Rp. 11.250,000

Syadza...

Nomer PO harap

" Saudara Cantumkan dalam Faktur dan Surat

Bag. Pembelian

Pengiriman."

Kamus Data Dokumen Masuk Barang Formulir Permintaan Pesanan

Nama Arus Data: Purchase Order

Alias: PO

Bentuk Data: Cetakan Manual

Arus Data: Customer Proses 0.0

Proses 0.0 Arsip PO

Penjelasan: Untuk Pesanan Penjualan Barang

Periode: Setiap Terjadi Pesanan Penjualan

Volume: Rata-rata perhari 20 Pesanan Penjualan

Struktur Data: Header + isi

Header: No_PO + Tgl_PO + Nama_Customer +

Alamat_Customer + Status_kondisi_Barang

No_PO: *Terdiri dari 9 digit*

Tgl_PO: Tgl + Bulan + Tahun

Status_Kond_Brg: [Biasa l Segera l Mendesak]

Isi: 1{Nama_Brg + Merk + Jumlah_Pesan +

Harga_Satuan + Total_Bayar}20