Resume Analisa Perancangan Berorientasi Objek (APBO) P3 part 2

Business Use Case

Pemodelan bisnis adalah representasi dari struktur dan perilaku
dari sebuah organisasi bisnis untuk tujuan memahami bisnis itu sendiri.
Struktur bisnis didefinisikan dalam istilah entitas dan hubungan
di antara mereka, perilaku bisnis didefinisikan dalam hal proses, peristiwa dan
penting untuk pemenuhan tujuan organisasi aturan. Bisnis
pendekatan pemodelan karena itu harus menyediakan teknik untuk mendefinisikan elemen
penting untuk baik struktur dan perilaku organisasi.
Pemodelan bisnis yang paling mendekati tempat penekanan pada dinamika
aspek bisnis. Bisnis dapat dilihat sebagai penyedia jasa.
Layanan adalah sebuah konsep yang sulit dipahami yang dapat didefinisikan dalam berbagai cara (misalnya,
[Johns, 1999]). Dalam konteks makalah ini, layanan didefinisikan sebagai suatu tindakan atau
kinerja yang diberikan oleh satu pihak kepada pihak lain Lovelock [dan Vandermerwe,
1996] dan dicapai melalui pelaksanaan proses bisnis. Bisnis
proses yang dimulai sebagai respons terhadap suatu peristiwa (misalnya, permintaan pelanggan). Sebuah
proses bisnis didefinisikan dalam hal elemen proses yang gabungan
perilaku memungkinkan menyediakan layanan tertentu. Eksternal kepada pihak-pihak
organisasi bidang studi (misalnya, orang, perusahaan lain, internal lainnya
unit organisasi, dan badan-badan pemerintah) adalah penerima manfaat dari
jasa; maka pemahaman tentang bisnis ini harus terintegrasi dengan
definisi pihak-pihak eksternal ke daerah studi dan organisasi
berinteraksi dengan itu.
Sebuah model berorientasi-layanan dari suatu organisasi adalah berlaku bahkan untuk
bisnis yang tujuan utamanya adalah produksi dan penjualan barang. Para
pembagian tradisional antara barang dan jasa yang panjang usang [Gummesson,
[Gummesson, 1994]. Konsumen membeli suatu korban yang nilainya dapat terdiri dari
banyak komponen, beberapa dari mereka kegiatan yang dan beberapa hal. Sebagai contoh,
ketika membeli barang apa yang ditawarkan pada kenyataannya bukan barang itu sendiri, namun
milik yang baik. Dengan cara bisnis menyediakan pelayanan
mentransfer milik baik ketika membuat penjualan. Akibatnya penjualan
produk juga membutuhkan pengiriman layanan.
Studi tentang proses bisnis merupakan sarana yang berguna untuk mengidentifikasi dan
mendefinisikan entitas atau sumber daya bisnis. Proses menggunakan, memanipulasi dan / atau
mengubah entitas ini. Oleh karena itu, definisi perilaku bisnis terintegrasi
dengan identifikasi entitas bisnis. Selain itu, analisis bisnis
proses juga memungkinkan modeler untuk mendefinisikan arsitektur bisnis dengan
pengelompokan dan fungsi yang berkaitan dengan lingkup yang sama. Proses bisnis model
dapat mewakili organisasi seperti saat ini berperilaku (deskriptif 'sebagai-adalah') atau seperti
dapat berperilaku jika perubahan dalam proses bisnis yang diperlukan (preskriptif 'tobe').
Sementara bentuk model yang gratis, tampilan preskriptif adalah
instrumental untuk strategi seperti rekayasa ulang proses bisnis (BPR)
[Hammer dan Champy, 1993] dan perbaikan (BPI) [Davenport, 1993].
Banyak teknik yang diterapkan untuk pemodelan proses bisnis, masing-masing
Teknik berfokus pada aspek tertentu atau seperangkat aspek bisnis untuk
model. Kettlinger, Teng et al. [Kettlinger et al, 1997.], Dalam sebuah studi tentang
metodologi, teknik dan alat untuk BPR, mengidentifikasi beberapa teknik, yang paling
yang (misalnya, flowchart dan diagram aliran data) berasal dari perangkat lunak
pemodelan domain. Penerapan teknik perangkat lunak untuk pemodelan bisnis
dipertanyakan mengingat bahwa mereka tidak n dikembangkan dalam terang yang spesifik
kebutuhan, masalah, konsep, dan semantik dari organisasi bisnis. Untuk lebih
memahami ciri-ciri bahwa teknik pemodelan bisnis
harus memiliki, hal ini berguna untuk memperjelas tujuan pemodelan bisnis. Pemodelan bisnis yang di tujukan untuk menentukan dan mewakili sistem sosial.
(Yaitu, organisasi bisnis). Lebih khusus, model bisnis dapat melayani
berikut tujuan [Penker dan Eriksson, 2000]:

• Untuk meningkatkan pemahaman tentang elemen kunci dari ada
bisnis, dinamika. dan struktur yang mendasari.
• Untuk bertindak sebagai dasar untuk menciptakan sistem informasi yang sesuai yang
mendukung bisnis.
• Untuk bertindak sebagai dasar untuk memperbaiki struktur bisnis saat ini dan
operasi dengan mengidentifikasi area masalah dan potensi perbaikan.
• Untuk menunjukkan struktur dari sebuah bisnis inovasi.
• Untuk bereksperimen dengan konsep bisnis baru atau untuk menyalin atau studi
konsep yang digunakan oleh perusahaan yang kompetitif.
• Untuk mengidentifikasi peluang outsourcing.
Representasi organisasi, untuk setiap tujuan yang tercantum,
melibatkan komunikasi dengan dan partisipasi para stakeholder bisnis.
Komunikasi dan partisipasi adalah penting untuk mendapatkan diterima
pemahaman tentang perilaku organisasi dan struktur. Produk ini
komunikasi harus didokumentasikan dengan cara yang memungkinkan bisnis
pemangku kepentingan untuk memahami model bisnis yang jelas. Pada gilirannya, comprehensibility
dan kejelasan dari model peningkatan partisipasi stakeholder aktif. Sebuah bisnis
model yang menyediakan representasi yang adil dan akurat dari daerah organisasi
studi menyediakan pengembang dengan titik acuan untuk digunakan di seluruh
proses pembangunan. Bisnis kasus penggunaan dapat diterapkan sebagai alat untuk
mencapai tujuan tersebut.

BISNIS KASUS PENGGUNAAN
Menggunakan pemodelan kasus merupakan teknik yang paling drive masa kini
pengembangan berorientasi objek metode. Dalam Unified Process [Jacobson et al.,
1999] kasus penggunaan dipekerjakan untuk keperluan bisnis dan pemodelan sistem. Para
rute melalui mantan yang kedua adalah melalui diagram kolaborasi. Pilih
Perspektif [Allen dan Frost, 1998, Apperly et al, 2003.], Di sisi lain, adalah
contoh metode berorientasi objek di mana kasus penggunaan dipekerjakan hanya untuk
pemodelan sistem. Pemodelan bisnis dilakukan dengan teknik diagram
(Hirarki diagram dan diagram proses benang) tidak terkait langsung dengan
kasus bisnis digunakan, tetapi dipetakan ke kasus menggunakan sistem dalam fase berikutnya.
Aplikasi kasus digunakan untuk pemodelan bisnis, kasus bisnis digunakan yaitu, adalah
masih belum matang. Meskipun penerapan kasus penggunaan berkembang biak dalam konteks
sistem perangkat lunak pengembangan, implementasi mereka dalam pemodelan bisnis tidak
sebagai luas. Konsep kasus bisnis gunakan tidak hal yang baru [Jacobson et al.,
1995], tetapi hanya baru-baru melakukannya mulai kembali beredar di literatur [Jacobson et
al, 1999.] dan di alat kasus (misalnya, Rational Rose).
Sebuah kasus penggunaan bisnis adalah deskripsi fungsi yang memberikan
layanan untuk seorang aktor, dengan fungsi yang dijelaskan dalam hal bisnis
proses. Sebuah kasus penggunaan bisnis juga mendefinisikan sifat-sifat lainnya seperti memicu
acara, kondisi pra dan pasca, dan stakeholder. Dalam kasus penggunaan bisnis
pemodelan, sistem dimodelkan berhubungan dengan organisasi atau salah satu sub-unit.
Sebagai konsekuensinya aktor eksternal ke daerah studi organisasi.
Contoh pelaku usaha adalah pelanggan, pemasok, dan organisasi
unit. Sebaliknya, pekerja internal (misalnya, karyawan dari bisnis) terletak dalam
batas sistem dan karena itu tidak dapat didefinisikan sebagai aktor dalam hal ini.
Pekerja biasanya akan dianggap aktor dalam kasus penggunaan sistem.
Pelaku usaha biasanya pihak diidentifikasi baik sebagai orang atau
kelompok orang (misalnya perusahaan). Dalam beberapa kasus mungkin tampak bahwa aktor
dari kasus penggunaan bisnis bukanlah manusia, misalnya, ketika komputer bank
sistem secara otomatis permintaan kredit cek ke perusahaan credit scoring.
Namun, sistem komputer bank bertindak atas nama bank. Dalam nonautomated
sistem karyawan bisa meneruskan permintaan pemeriksaan kredit. Dalam kedua
kasus, untuk perusahaan penilaian kredit, bank (dan bukan komputer bank
sistem atau karyawan) adalah partai dengan siapa interaksi bisnis adalah mengambil
tempat. Dalam kedua kasus bank selalu aktor Permintaan 'hipotetis
skor kredit 'bisnis menggunakan kasus. Pada tingkat sistem baik mungkin diperlukan untuk
mendefinisikan sistem komputer bank sebagai aktor sistem.
Deskripsi proses bisnis terutama tekstual, namun dapat
dikombinasikan dengan bentuk-bentuk representasi grafis. Kombinasi
representasi memungkinkan modeler untuk mendekati definisi bisnis
fungsionalitas melalui transisi bertahap dari kurang terstruktur / diformalkan
representasi ke yang lebih terstruktur / formal. Salah satu isu kunci dalam
persyaratan pengumpulan adalah mengadopsi bentuk dokumentasi yang jelas
dipahami oleh para pemangku kepentingan bisnis. Bahasa alami ini biasanya
sarana untuk mengekspresikan persyaratan pada tahap awal. Namun, karena alam
bahasa cocok untuk ambiguitas dan inkonsistensi (tidak membuat ideal untuk
tujuan pengembang perangkat lunak), perbaikan dalam bentuk lain yang
dianjurkan, misalnya, lebih terstruktur dan / atau representasi grafis
dapat digunakan untuk menyempurnakan deskripsi tekstual use case itu. Sekarang umum untuk
menggunakan diagram kegiatan atau interaksi untuk tujuan ini. Negara diagram juga dapat
digunakan ketika menggunakan kasus melibatkan manipulasi / transformasi dari satu
jenis objek. Namun, representasi grafis harus disimpan sebagai sederhana seperti
mungkin untuk menyediakan pengguna bisnis dengan pemahaman yang jelas dari model.
Bentuk-bentuk representasi yang berbeda merupakan cara yang berbeda dan alternatif
mewakili deskripsi tekstual use case ini. Mereka membentuk bagian integral dari
menggunakan kasus. Dari perspektif ini sebuah use case dapat dilihat sebagai fundamental
paket perilaku encapsulating semua diagram dimaksudkan untuk menggambarkan nya
fungsi dalam hal 'apa' (layanan) yang diberikan kepada aktor dan 'bagaimana' yang
layanan direalisasikan (proses).
Oleh karena itu, bisnis menggunakan pemodelan kasus melayani tujuan-tujuan berikut:
• Untuk menangkap kebutuhan fungsional dari suatu organisasi atau suatu
Unit organisasi.
• Untuk memfasilitasi komunikasi diantara para bisnis dan
pemodel.
• Untuk meletakkan dasar-dasar arsitektur bisnis.
• Untuk memungkinkan transisi bertahap dan lebih mulus menuju model sistem informasi

Resume Analisa Perancangan Berorientasi Objek (APBO) P3

Use Case Diagram

Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang

ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case

merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah

pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya.

Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem

untuk melakukan pekerjaan-pekerjaan tertentu.

Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah sistem,

mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang

ada pada sistem.

Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam

dirinya. Secara umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali use

case yang meng-include dieksekusi secara normal.

Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas

dapat dihindari dengan cara menarik keluar fungsionalitas yang common.

Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya sendiri.

Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan

spesialisasi dari yang lain.

 Contoh use case diagram :

Class Diagram

Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan

merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan

(atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut

(metoda/fungsi).

Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan

satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain.

Class memiliki tiga area pokok :

1. Nama (dan stereotype)

2. Atribut

3. Metoda

Atribut dan metoda dapat memiliki salah satu sifat berikut :

• Private, tidak dapat dipanggil dari luar class yang bersangkutan

• Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang

mewarisinya

• Public, dapat dipanggil oleh siapa saja

Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak yang hanya memiliki

metoda. Interface tidak dapat langsung diinstansiasikan, tetapi harus diimplementasikan dahulu

menjadi sebuah class. Dengan demikian interface mendukung resolusi metoda pada saat run-time.

Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi package. Kita juga

dapat membuat diagram yang terdiri atas package.

Hubungan Antar Class

1. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki

atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah

navigability menunjukkan arah query antar class.

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.

Contoh class diagram :

Statechart Diagram

Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya)

suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart

diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart

diagram).

Dalam UML, state digambarkan berbentuk segiempat dengan sudut membulat dan memiliki nama

sesuai kondisinya saat itu. Transisi antar state umumnya memiliki kondisi guard yang merupakan

syarat terjadinya transisi yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan

sebagai akibat dari event tertentu dituliskan dengan diawali garis miring.

Titik awal dan akhir digambarkan berbentuk lingkaran berwarna penuh dan berwarna setengah.

Activity Diagram

Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang,

bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka

berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada

beberapa eksekusi.

Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan

sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh

karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi

antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas

dari level atas secara umum.

Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses

yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk

melakukan aktivitas.

Sama seperti state, standar UML menggunakan segiempat dengan sudut membulat untuk

menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi

tertentu. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi

yang dapat berupa titik, garis horizontal atau vertikal.

Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana

yang bertanggung jawab untuk aktivitas tertentu.

Contoh activity diagram tanpa swimlane:

Sequence Diagram

Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk

pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence

diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait).

Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah

yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari

apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal

dan output apa yang dihasilkan.

Masing-masing objek, termasuk aktor, memiliki lifeline vertikal.

Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase desain

berikutnya, message akan dipetakan menjadi operasi/metoda dari class.

Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan diterimanya

sebuah message.

Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan icon khusus untuk

objek boundary, controller dan persistent entity.

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.

Contoh component diagram:

Resume Analisa Perancangan Berorientasi Objek (APBO) P2

NIM/Nama     : 09 41011 0021 / Sukirno

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 bahasabahasa

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.

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

Langkah-Langkah Penggunaan UML

Berikut ini adalah tips pengembangan piranti lunak dengan menggunakan UML:

1. Buatlah daftar business process dari level tertinggi untuk mendefinisikan aktivitas dan

proses yang mungkin muncul.

2. Petakan use case untuk tiap business process untuk mendefinisikan dengan tepat

fungsionalitas yang harus disediakan oleh sistem. Kemudian perhalus use case diagram dan

lengkapi dengan requirement, constraints dan catatan-catatan lain.

3. Buatlah deployment diagram secara kasar untuk mendefinisikan arsitektur fisik sistem.

4. Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus

disediakan oleh sistem.

5. Berdasarkan use case diagram, mulailah membuat activity diagram.

6. Definisikan objek-objek level atas (package atau domain) dan buatlah sequence dan/atau

collaboration diagram untuk tiap alir pekerjaan. Jika sebuah use case memiliki

kemungkinan alir normal dan error, buatlah satu diagram untuk masing-masing alir.

7. Buarlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk

menjalankan skenario use case.

8. Berdasarkan model-model yang sudah ada, buatlah class diagram. Setiap package atau

domain dipecah menjadi hirarki class lengkap dengan atribut dan metodanya. Akan lebih

baik jika untuk setiap class dibuat unit test untuk menguji fungsionalitas class dan interaksi

dengan class lain.

9. Setelah class diagram dibuat, kita dapat melihat kemungkinan pengelompokan class

menjadi komponen-komponen. Karena itu buatlah component diagram pada tahap ini. Juga,

definisikan tes integrasi untuk setiap komponen meyakinkan ia berinteraksi dengan baik.

10. Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan dan requirement

piranti lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node.

11. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan :

• Pendekatan use case, dengan meng-assign setiap use case kepada tim pengembang

tertentu untuk mengembangkan unit code yang lengkap dengan tes.

• Pendekatan komponen, yaitu meng-assign setiap komponen kepada tim

pengembang tertentu.

12. Lakukan uji modul dan uji integrasi serta perbaiki model berserta codenya. Model harus

selalu sesuai dengan code yang aktual.

13. Piranti lunak siap dirilis.