Pengantar Manajemen

lfflhjlh

DFD Versus UML

DFD (Data Flow Diagram) / DAD (Diagram Arus Data) ?

DAD (Diagram Arus Data) adalah suatu modeling tool yang memungkinkan sistem analis menggambarkan suatu sistem sebagai suatu jaringan kerja proses dan fungsi yang dihubungkan satu sama lain oleh penghubung yang disbut alur data.

Fungsi DAD :

1. DAD membantu para analis sitem meringkas informas tentang sistem, mengetahui hubungan antar sub-sub sistem, membantu perkembangan aplikasi secara efektif.

3. DAD dapat menggambarkan sejumlah batasan otomasi untuk pengembangan alternative sistem fisik.

Komponen-komponen DAD

Ada beberapa simbol yang digunakan dalam DFD yang merupakan karakteristik dari suatu sistem, yaitu :

1. Terminator (External Entity)

Terminator disimbolkan dalam bentuk persegi panjang, yang mewakili entity luar dimana sistem berkomunikasi. Biasanya notasi ini melambangkan orang atau kelompok orang misalnya organisasi diluar sistem, grup, departemen, perusahaan pemerintah, dan berada di luar kontrol sistem yang dimodelkan. Pada sejumlah kasus dapat merupakan sistem lain, sebagai contoh : sistem komputer yang berkomunikasi dengan sistem yang dimodelkan.

1. Proses

Proses disimbolkan dalam bentuk lingkaran. Melambangkan suatu proses dari data yang dimasukkan ke dalam sistem yang mengubah input menjadi output. Pemberian nama pada proses dengan menggunakan kata kerja transistif (membutuhkan objek).

1. Penyimpanan Data (Data Store)

Data store disimbolkan dengan garis sejajar, yang digunakan untuk memodelkan kumpulan data atau paket data. Penyimpanan kadangkala didefinisikan sebagai suatu mekanisme diantara dua proses yang dibatasi oleh jangka waktu tertentu.Data store dapat berupa fie/database yang tersimpan dlm disket, harddisk, dll.

1. Alur data (Data Flow)

Data Flow disimbolkan dengan tanda anak panah, alur ini mengalir diantara proses, data store, dan terminator. Alur data menunjukkan arus data yang dapat berupa masukkan untuk sistem atau hasil proses sistem.

Ada beberapa konsep alur data yang perlu diperhatikan, yaitu : (Jogiyanto,1999)

§ konsep paket dari data (packed of data)

Bila dua atau lebih data mengalir dari suatu sumber yang sama ketujuan yang sama, maka harus digambarkan sebagai suatu alur data tunggal.

§ Konsep alur data menyebar (diverging data flow)

Alur data menyebar menunjukkan sejumlah tembusan dari alur data yang sama dari sumber yang sama ketujuan yang berbeda.

§ Konsep alur data mengumpul (converging data flow)

Alur data yang mengumpul menunjukkan beberapa alur data yang berbeda dari sumber data yang berbeda bergabung bersama-sama menuju tujuan yang sama.

Panah yang bergerak dari penyimpanan berarti : penggunaan data paket tunggal, paket kelompok dan lain-lain. Sedangkan panah yang bergerak ke penyimpanan mendeskripsikan penulisan, perubahan atau penghapusan satu atau lebih paket yang dimasukkan ke penyimpanan sebagai bagian dari paket lama, atau merupakan paket baru, atau satu atau lebih paket dihapus, atau dipindahkan dari penyimpanan, atau merupakan satu atau lebih paket dimodifikasi atau berubah.

Tingkatan DAD

1. Diagram Konteks

Dimulai dengan diagram konteks yang merupakan level tertinggi (top level), diagram yang menggambarkan hubungan antar system dengan entitas diluar system, merupakan system secara keseluruhan.

1. Diagram Nol (Zero)

Merupakan proses-proses yang ada didalam system berupa pecahan dari diagram konteks, diagram nol (zero) merupakan rincian dari diagram konteks.

1. Diagram Rinci/detail/primitive

Menggambarkan rincian tiap proses yang terdapat pada diagram nol, dimana proses rinci ini dapat dipecahkan sampai pada proses yang paling rinci.

UML (Unified Modeling Language) ?

Unified Modeling Language (UML) adalah penerus dari object-oriented analysis and design (OOA&D) methods yang muncul pada akhir ’80 an dan awal ’90 an. UML secara langsung menggabungkan methods dari Booch, Rumbaugh (OMT), dan Jacobson, tetapi menjadi lebih berkembang daripada itu semua. UML berkembang melalui sebuah proses standarisasi yang dilakukan oleh OMG (Object Management Group) dan sekarang memakai standar dari OMG.

UML disebut sebagai bahasa untuk permodelan, bukan sebuah method. Hampir semua methods mengandung, paling tidak dalam beberapa prinsip, dua dari sebuah bahasa permodelan dan sebuah proses. Bahasa permodelan tersebut (terutama yang berbasis grafis) adalah sebuah notasi yang menggunakan methods untuk mengekspresikan sebuah rancangan. Proses tersebut adalah tuntunan yang mereka lakukan dalam setiap langkah untuk merancang sesuatu.

Bagian daripada proses untuk UML dari beberapa buku hanyalah bersifat sketsa saja. Lebih jauh lagi beberapa orang menyatakan kalau mereka menggunakan sebuah method pada kenyataannya mereka menggunakan UML, tetapi tidak benar-benar mengikuti proses yang terjadi. Jadi dalam berbagai cara, UML merupakan bagian yang paling penting dari method. Itu merupakan kunci utama dari komunikasi yang ada. Ketika kita akan membahas design kita pada seseorang, UML dapat kita gunakan untuk menjelaskan design kita kepada seseorang tersebut, bukan proses yang kita gunakan.

Ada tiga orang yang juga mengembangkan sebuah unified process, mereka menyebutnya Rational Unified Process (RUP). Kita tidak harus menggunakan Rational Unified Process dalam rangka menggunakan UML mereka benar-benar terpisah. Dalam artikel ini, walau bagaimanapun kita membicarakan sedikit mengenai proses teknik-teknik yang digunakan oleh bahasa permodelan dalam pelaksanaannya. Masih dalam artikel ini kita juga menggunakan langkah-langkah dasar dan istilah-istilah dari RUP, tetapi artikel ini bukanlah membahas RUP.

Sekitar era ’80 an, konsep-konsep mengenai object sudah mulai dipublikasikan dan digunakan dalam applikasi nyata. Smalltalk sudah mulai digunakan untuk mengaplikasikan konsep mengenai object tersebut dan lahirlah C++.

Seperti pada banyak pengembangan dalam software, konsep object tersebut digerakkan oleh bahasa-bahasa pemrograman. Banyak orang mencari-cari bagaimana sebuah method design dapat diaplikasikan menurut konsep object-oriented. Design methods menjadi sesuatu yang sangat populer pada industri pengembangan software pada ’70 an dan ’80 an. Beberapa merasa kalau teknik-teknik yang membantu dalam analisa dan design yang baik juga sangat berguna dalam pengembangan berdasarkan object-oriented.

Buku-buku yang berpengaruh pada object-oriented analysis dan design methods muncul antara tahun 1988 dan 1992 :

• Sally Shlaer dan Steve Mellor menulis sepasang buku (1989 dan 1991) pada analysis dan design; materi dalam buku-buku itu telah berevolusi dalam pendekatan Recursive Design mereka (1997).

• Peter Coad dan Ed Yourdon juga menulis sepasang buku yang mengembangkan Coad’s lightweight dan pendekatan prototype-oriented untuk methods. Lihat Coad dan Yourdon (1991a dan 1991b), Coad dan Nicola (1993), dan Coad dan lain-lain (1995)

• Komuniti smalltalk di Portland, Oregon, menghasilkan Responsibility-Driven Design (Wirfs-Brocket 1990) dan Class-Responsibility-Collaboration (CRC) cards (Beck dan Cunningham 1989).

• Grady Booch telah bekerja keras dalam mengembangkan Rational Software yang disebut Ada systems. Buku karangannya menampilkan beberapa contoh (dan ilustrasi karton terbaik dalam dunia buku-buku tentang methods). Lihat Booch (1994 dan 1996).

• Jim Rumbaugh memimpin sebuah team pada lab penelitian di General Electric, yang mana menghasilkan sebuah buku yang sangat terkenal mengenai sebuah method yang disebut Object Modeling Technique (OMT). Lihat Rumbaugh (1991) dan Rumbaugh (1996).

• Jim Odell berdasarkan dari buku-bukunya (yang ditulis bersama dengan James Martin) menggambarkan perjalanan karirnya dalam business information systems dan Information Engineering. Hasilnya adalah sebuah konsep yang matang dalam buku-buku tersebut. Lihat Martin dan Odell (1994).

• Ivar Jacobson membuat bukunya berdasarkan pengalamannya pada telephone switches dari Ericsson dan memperkenalkan konsep penggunaan kasus-kasus pada saat pertama kali. Lihat Jacobson (1992 dan 1995).

Cara kerja UML adalah dengan mendefinisikan notasi dan sebuah meta-model.

Notasi tersebut adalah model-model yang direpresentasikan dalam bentuk grafis, ini adalah syntax untuk bahasa permodelan. Untuk contohnya, notasi class diagram mendefinisikan bagaimana item-item dan konsep-konsep seperti class, association, dan multiplicity direpresentasikan.

Tentu saja, ini semua mengarah kepada pertanyaan apakah sebenarnya yang dimaksud dengan sebuah association atau multiplicity atau bahkan sebuah class. Para pengguna umumnya menyarankan beberapa definisi-definisi informal, tetapi banyak orang menginginkan informasi yang lebih daripada itu semua.

Ide dari bahasa spesifikasi dan design yang tepat adalah sangat relevan dalam bidang sebuah formal method. Didalam sebuah teknik, design, dan specifications telah direpresentasikan dengan menggunakan turunan dari predicate kalkulus. Definisi tersebut telah dimatematikakan dengan tepat dan tidak ada duanya. Walau bagaimanapun nilai dari definisi ini bukanlah merupakan sesuatu yang universal. Walaupun kita dapat membuktikan bahwa program tersebut dapat membuktikan sebuah spesifikasi matematika yang benar, tidak mungkin ada sebuah cara untuk membuktikan kalau spesifikasi matematika itu dapat memenuhi syarat yang dibutuhkan sebuah system.

Design adalah tentang menemukan masalah-masalah kunci yang dihadapi pada development. Formal methods sering kali membuat putus asa dengan cara banyak memberikan detil-detil yang tidak penting. Juga formal methods sangat sulit untuk dipelajari dan dimanipulasi, juga lebih sulit dihadapi daripada bahasa pemrograman. Dan kita juga tidak dapat menjalankannya.

Kebanyakan methods object-oriented mempunyai sedikit kekakuan, notasi mereka lebih berdasarkan intuisi daripada definisi yang formal. Dalam keseluruhannya, ini semua tampak tidak menimbulkan kerusakan. Methods ini mungkin informal, beberapa orang menemukan kalau semua ini masih berguna dan kegunaannya itulah yang diperhitungkan.

Walau bagaimanapun, orang-orang yang menggunakan methods OO selalu mencari jalan untuk meningkatkan methods yang kaku tersebut tanpa mengurangi kegunaannya. Salah satu cara untuk melakukannya adalah dengan mendefinisikan meta-model : sebuah diagram, yang biasanya adalah sebuah diagram class, yang mendefinisikan notasi tersebut. (**)

A. Hasil konsorsium berbagai organisasi yang dijadikan standar baku dalam OOAD –Object Oriented Analysis & Design – adalah UML.

B. Notasi grafis yang dibakukan –open standart—dikontrol oleh OMT –Object Management Group—sebuah badan yang telah membakukan CORBA –Commont Object Request Broker Architecture.

C. Kontribusi UML dalam perusahaan-perusahaan :

· Digital Equioment Corp.

· Hawlet Packard Company

· I-Logic

· Intell Corp.

· IBM

· Icon Computing

· Microsoft

· Rational Software

· Dll…

D. Karakter UML:

· Sketsa

Jembatan dalam mengkomunikasikan system sehingga akan memiliki gambaran yang sama tentang system

· Cetak Biru (Blueprint)

Mengetahui informasi detail tentang coding program –forward engineering—dan membaca program serta menginterpretasikan kembali ke dalam diagram –reserve engineering.

Fungsi Reserve Engineering: Apabila terjadi situasi dimana code program yang tidak terdokumentasikan –karena dokumentasi hilang atau belum dibuat sama sekali– membutuhkan modifikasi (pemeliharaan)

· Bahasa Pemrograman

UML dapat menterjemahkan diagram menjadi code program yang siap untuk dijalankan.

E. UML dibangun atas model 4+1 view:

[1]. Use Case View:

* Mendefinisikan perilaku eksternal system

** Mengemudikan proses pengembangan perangkat lunak

*** Mendefinisikan kebutuhan system karena mengandung semua view yang lain yang medeskripsikan aspek-aspek tertentu dari rancangan system.

“Informasi yang terkandung menjadi daya tarik bagi end-user, analist dan tester.”

[2]. Design View:

* Mendeskripsikan Struktur Logika yang mendukung fungsi-fungsi yang dibutuhkan Use Case.

Komponen:

- Definisi komponen program

- Class-class utama bersama spesifikasi data, perilaku dan interaksinya.

“Informasi yang terkandung menjadi perhatian programmer karena menjelaskan secara detil fungsionalitas system akan diimplementasikan”

[3]. Implementation View:

* Menjelaskan komponen-komponen fisik dari system yang akan dibangun

Komponen: - Termasuk disini diantaranya file exe, library, & database.

“Informasi yang terkandung relevan dengan aktifitas-aktifitas seperti manajemen, konfigurasi dan integrasi sistem”

[4]. Process View:

* Berhubungan dengan hal-hal yang berkaitan dengan concurrency di dalam sistem.

[5]. Deployment View:

* Menjelaskan tentang komponen-komponen fisik yang didistribusikan ke lingkungan fisik.

Contoh: Seperti Jaringan Komputer tempat sistem akan dijalankan.

“Process & Deployment View menunjukan kebutuhan non fungsional langsung dari sistem. Seperti: kesalahan dan hal-hal yang berhubungan dengan kinerja.”

Keterangan:

1. Use case view memegang peranan khusus untuk mengintegrasikan konten ke view yang lain.

2. Kelima view tidak berhubungan dengan diagram yang dideskripsikan di UML.

3. Setiap view berhubungan dengan perspektif tertentu system akan diuji. (**)

Saya kira perusahaan-perusahaan besar pada umumnya mempunyai standar proses pengembangan software yang secara umum biasanya disebut SDLC (Software Development Life Cycle). Di beberapa perusahaan yang manajemen TI nya sudah mapan, SDLC tersebut biasanya diterapkan secara konsisten baik untuk pengembangan software oleh pihak internal, maupun pengembangan software yang melibatkan pihak eksternal (outsourcing). SDLC yang diterapkan secara ketat secara tidak langsung akan meningkatkan kualitas software yang dihasilkan. Bagian dari SDLC juga mensyaratkan adanya dokumentasi software yang baik.

Apakah SDLC saja serta keberadaan dokumentasi software sudah cukup? Jawabannya biasanya baru diketahui setelah ada masalah-masalah berkaitan dengan software aplikasi yang sudah pernah dibuat. Beberapa permasalahan tipikal diantaranya adalah sebagai berikut:

1. Dokumentasi software ternyata tidak lengkap, ada bagian penting dari software yang tidak dijelaskan dengan cukup, sehingga sulit untuk memahaminya.
2. Format dan struktur dokumen berbeda-beda
3. Cara pemodelan berbeda-beda. Mungkin ada yang masih menggunakan flowchart + ER Diagram saja, ada yang menambahkan Data Flow Diagram (DFD), ada yang mencampur adukan UML dengan DFD, atau ada yang secara penuh sudah menerapkan UML.

Permasalahan-permasalahan tersebut di atas akan menghambat tujuan-tujuan sebagai berikut:

1. Melakukan modifikasi software menjadi sulit dilakukan. Kadang perusahaan ingin melakukan modifikasi kecil dari software yang sudah dibuat dan sudah diluar masa garansi. Tapi sulit dilakukan karena hambatan dokumentasi.
2. Melakukan pengembangan lebih lanjut menggunakan vendor lain. Dokumentasi yang buruk, yang hanya dimengerti oleh pembuatnya saja, menyulitkan dipahami oleh pihak lain yang akan meneruskan pekerjaan tersebut.
3. Melakukan integrasi dengan aplikasi lain. Ketika sistem berkembang dan ada tuntutan integrasi, dokumentasi yang buruk mungkin akan menyulitkan untuk memahami struktur data, cara berkomunikasi data, apalagi kalau ada keperluan modifikasi algoritma untuk mencapai tujuan integrasi.

Bagaimana solusinya? Sederhana!

Buatlah standar (template) dokumentasi pengembangan software aplikasi di perusahaan anda. Standar dokumentasi berbeda dengan standar proses pengembangan (SDLC).

Semua pengembangan software, baik yang dilakukan oleh pihak internal maupun cara outsource harus membuat dokumentasi sesuai standar tersebut. Hal yang harus diingat adalah:

Jangan membuat standar dokumentasi yang bentuknya tidak biasa. Saya sarankan untuk mengadopsi dari suatu standar, lalu lakukan penyesuaian minor. Untuk pemodelannya, saya menganjurkan untuk menggunakan UML secara penuh.

Nah, kalau ini sudah tercapai, anda buka dokumen software manapun selalu sama bentuknya dan kelengkapannya cenderung lebih terjamin karena mengikuti template yang sudah ada. (*)

<Sumber:http://jalaludinweb.wordpress.com,kupalima.wordpresom, jogjagenit.wordpress.com, www.ristinet.com>

Semoga bermanfaat.

UML

Pengantar Unified Modelliing Language (UML)

Pendahuluan

Saat ini piranti lunak semakin luas dan besar lingkupnya, sehingga tidak bisa lagi dibuat asal-asalan. Piranti lunak saat ini seharusnya dirancang dengan memperhatikan hal-hal seperti scalability , security , dan eksekusi yang robust walaupun dalam kondisi yang sulit. Selain itu arsitekturnya harus didefinisikan dengan jelas, agar bug mudah ditemukan dan diperbaiki, bahkan oleh orang lain selain programmer aslinya. Keuntungan lain dari perencanaan arsitektur yang matang adalah dimungkinkannya penggunaan kembali modul atau komponen untuk aplikasi piranti lunak lain yang membutuhkan fungsionalitas yang sama. Pemodelan ( modeling ) adalah proses merancang piranti lunak sebelum melakukan pengkodean ( coding ). Model piranti lunak dapat dianalogikan seperti pembuatan blueprint pada pembangunan gedung. Membuat model dari sebuah sistem yang kompleks sangatlah penting karena kita tidak dapat memahami sistem semacam itu secara menyeluruh. Semakin komplek sebuah sistem, semakin penting pula penggunaan teknik pemodelan yang baik. Dengan menggunakan model, diharapkan pengembangan piranti lunak dapat memenuhi semua kebutuhan pengguna dengan lengkap dan tepat, termasuk faktor-faktor seperti scalability, robustness, security , dan sebagainya. Kesuksesan suatu pemodelan piranti lunak ditentukan oleh tiga unsur, yang kemudian terkenal dengan sebuan segitiga sukses ( the triangle for success ). Ketiga unsur tersebut adalah metode pemodelan ( notation ), proses ( process ) dan tool yang digunakan.

Memahami notasi pemodelan tanpa mengetahui cara pemakaian yang sebenarnya (proses) akan membuat proyek gagal. Dan pemahaman terhadap metode pemodelan dan proses disempurnakan dengan penggunaan tool yang tepat.

Apa itu UML

Unified Modelling Language (UML) adalah sebuah “bahasa” yg telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem. 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, C# atau 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 [1], metodologi coad [2], metodologi OOSE [3], metodologi OMT [4], metodologi shlaer-mellor [5], metodologi wirfs-brock [6], dsb. Masa itu terkenal dengan masa perang metodologi ( method war ) dalam pendesainan berorientasi objek. Masing-masing metodologi membawa notasi sendiri-sendiri, yang mengakibatkan timbul masalah baru apabila kita bekerjasama dengan group/perusahaan lain yang menggunakan metodologi yang berlainan.

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). 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 [7] [8] [9]. Sejak saat itulah UML telah menjelma menjadi standar bahasa pemodelan untuk aplikasi berorientasi objek.

Konsepsi Dasar UML

Dari berbagai penjelasan rumit yang terdapat di dokumen dan buku-buku UML. Sebenarnya konsepsi dasar UML bisa kita rangkumkan dalam gambar dibawah.

Major Area	View	Diagrams	Main Concepts
structural	static view	class diagram	class, association, generalization, dependency, realization, interface
	use case view	use case diagram	use case, actor, association, extend, include, use case generalization
	implementation view	component diagram	component, interface, dependency, realization
dynamic	state machine view	statechart diagram	state, event, transition, action
	actifity view	activity diagram	state, activity, completion transition, fork, join
	interaction view	sequence diagram	interaction, object, message, activation
		colaborating diagram	collaborating, interaction, collaboration rule, message
model management	model management view	class diagram	package, subsystem, model
extensibility	all	all	constraint, stereotype, tagged values

Abstraksi konsep dasar UML yang terdiri dari structural classification , dynamic behavior , dan model management , bisa kita pahami dengan mudah apabila kita melihat gambar diatas dari Diagrams . Main concepts bisa kita pandang sebagai term yang akan muncul pada saat kita membuat diagram. Dan view adalah kategori dari diagaram tersebut. Lalu darimana kita mulai ? Untuk menguasai UML, sebenarnya cukup dua hal yang harus kita perhatikan:

1. Menguasai pembuatan diagram UML

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

Tulisan ini pada intinya akan mengupas kedua hal tersebut.

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

• use case diagram

• class diagram

• statechart diagram

• activity diagram

• sequence diagram

• collaboration diagram

• component diagram

• deployment diagram

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.

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 m enunjukkan arah query antar class .
2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”).
3. 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.

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.

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.

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 .

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.

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.

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.

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 d ipecah 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.

• Lakukan uji modul dan uji integrasi serta perbaiki model berserta code nya. Model harus selalu sesuai dengan code yang aktual.

• 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)

Data seluruh tool yang mendukung UML, lengkap beserta harganya (dalam US dolar) bisa dipelajari di situs http://www.objectsbydesign.com/tools/umltools_byCompany.html . Disamping itu, daftar tool UML berikut fungsi dan perbangingan kemampuannya juga dapat dilihat di http://www.jeckle.de/umltools.htm .

Pointer Penting UML

Sebagai referensi dalam mempelajari dan menggunakan UML, situs-situs yang merupakan pointer penting adalah:

• http://www.cetus-links.org/oo_uml.html
• http://www.omg.org
• http://www.omg.org/technology/uml/
• http://www.rational.com/uml
• http://www.uml.org/

Dan juga buku-buku yang terdapat di daftar pustaka.

Daftar Pustaka

1. Grady Booch, Object-Oriented Analysis and Design with Application, Benjamin/Cummings, 1991.
2. Peter Coad and Edward Yourdon, Object-Oriented Analysis, Yourdon Press, 1991.
3. Ivar Jacobson, Magnus Christerson, Patrik Jonson, and Gunnar Overgaard, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992.
4. James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorenson, Object-Oriented Modeling and Design, Prentice Hall, 1991.
5. Sally Shlaer and Stephen J. Mellor, Object-Oriented System Analysis: Modeling the World in Data, Yourdon Press, 1988.
6. Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener, Designing Object-Oriented Software, Prentice Hall, 1990.
7. Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide, Addison-Wesley, 1999.
8. Ivar Jacobson, Grady Booch, and James Rumbaugh, The Unified Software Development Process, Addison-Wesley, 1999.
9. James Rumbaugh, Ivar Jacobson, and Grady Booch, The Unified Modeling Language Reference Manual, Addison-Wesley, 1999.
10. Unified Modeling Language Specification, Object Management Group, www.omg.org, 1999.
11. Introduction to OMG UML [http://www.omg.org/gettingstarted/what_is_uml.htm]
12. UML Tutorial [http://www.sparxsystems.com.au/UML_Tutorial.htm]
13. Embarcadero Tech Support [http://www.embarcadero.com/support/uml_central.asp]
14. Practical UML A Hands-On Introduction for Developers, http://www.togethersoft.com/services/practical_guides/umlonlinecourse/index.html]
15. Architecture and Design: Unified Modeling Language (UML), [http://www.cetuslinks. org/oo_uml.html]