uml diagram narrative muh.hasbi 1129040229
DESCRIPTION
chscbjsbcjkbckjbsdcTRANSCRIPT
Pengertian Psikologi Menurut Para AhliPengertian Psikologi Menurut Para AhliDan Objek Kajian PsikologiDan Objek Kajian Psikologi
Disusun oleh
MUH. HASBI 1129040229
PTIK 06
Prodi Pendidikan Teknik Informatika dan KomputerFakultas Teknik
Universitas Negeri Makassar2014
Kata Pengantar
Kalau mahasiswa mendengar kata-kata “UML” atau Unified Modeling
Language, maka yang terbayang adalah suatu matakuliah killer. 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
Ucapan Terima Kasih Kepada ayahanda Suhartono, S.Kom, M.Kom yang tiada
hentinya memberikan dukungan dan semangat sehingga makalah ini dapat terselesaikan.
Mungkin masih banyak hal yang berada di luar pengamatan penulis. Oleh karena itu
kritik dan saran dari pembaca masih sangat diperlukan.
Makassar, Januari 2014
Penulis
1
Latar Belakang
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.
Gambar 1 The triangle of success
2
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.
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. 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.
Gambar 2 Asal usul UML
3
Ruang Lingkup
Ruang lingkup dari pembahasan ini berkaitan dengan pengenalan UML serta
membahas tentang berbagai macam diagram yang ada dalam UML. Dimana diagram
tersebut merupakan sebuah artifak dalam pengembangan sistem, jumlah diagram
tersebut ada 8 buah, yaitu Class diagram / Object diagram, Statechart diagram,
Component diagram, Deployment diagram, Use case diagram, Sequence diagram,
Collaboration diagram, Activity diagram.
Tujuan dan Manfaat
Tujuan
Tujuan dari penulisan paper ini adalah untuk menjelaskan UML sebagai
suatu bahasa permodelan modern pengembangan piranti lunak yang sering
dikaitkan erat dengan OOAD. Serta menjelaskan tujuan dari UML itu sendiri
bagi pembaca paper ini.
Manfaat
Manfaat yang didapat dari penulisan paper ini adalah sebagai berikut :
Mengetahui latar belakang dan sejarah pengembangan UML
sampai menjadi sebuah bahasa permodelan modern yang paling
populer.
Membantu para pembaca untuk mengetahui secara detil baik
deskripsi sampai ke notasi dari berbagai diagram yang ada dalam
UML.
Serta memberikan gambaran sederhana atas bahasa permodelan
pengembangan piranti lunak, yang dapat menjadi acuan untuk
melakukan pengembangan piranti lunak.
Metodologi Penulisan
Metodologi penulisan yang digunakan didalam penulisan paper ini yaitu:
Metode pengumpulan data
Metode yang digunakan untuk mengumpulkan data untuk penulisan paper
adalah studi pustaka. Studi pustaka ini dilakukan dengan cara membaca dan
4
meringkas literatur yang ada dan mengumpulkan informasi yang
berhubungan dengan topik paper ini melalui internet.
Unified Modeling Language (UML) adalah keluarga notasi grafis yang didukung
oleh meta-model tunggal, yang membantu pendeskripsian dan desain sistem perangkat
lunak, khususnya sistem yang dibangun menggunakan pemrograman berorientasi objek
(OO). Definisi ini merupakan definisi yang sederhana. Pada kenyataannya, pendapat
orang – orang tentang UML berbeda satu sama lain. Hal ini dikarenakan oleh sejarahnya
sendiri dan oleh perbedaan persepsi tentang apa yang membuat sebuah proses rancang –
bangun perangkat lunak efektif. Fowler (2004,p1)
Unified Modeling Language (UML) merupakan strandar yang relatif terbuka
yang dikontrol oleh Object Management Group (OMG), sebuah konsorsium terbuka
yang terdiri dari banyak perusahaan. OMG dibentuk untuk membuat standar – standar
yang mendukung interoperabilitas, khusunya interoperabilitas sistem berorientasi objek.
OMG mungkin lebih dikenal dengan standar – standar COBRA (Common Object
Request Broker Architecture). Fowler (2004,p1-2)
UML lahir dari penggabungan banyak bahasa permodelan grafis berorientasi
objek yang berkembang pesat pada akhir 1980-an dan awal 1990-an. Sejak
kehadirannya pada tahun 1997, UML menghancurkan menara Babel tersebut menjadi
sejarah. Fowler (2004,p2)
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.
5
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. Buatlah 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.
6
Tools 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)
UML terdiri dari diagram, notasi, konsep dan aturan yang digunakan dalam
memodelkan sistem. Diagram UML terdiri dari 9 jenis diagram yang memiliki fungsi
dan notasi masing-masing. Kesembilan diagram ini dapat dibagi menjadi 2 kategori,
yaitu :
1. Diagram yang menggambarkan struktur yang statis dari sistem.
2. Diagram yang menggambarkan struktur yang dinamis dari system.
Diagram struktur statis dari sistem
Adalah diagram yang menggambarkan struktur hubungan statis dari elemen-
elemen yang ada dalam sebuah model diantaranya class, package, dan relationship yang
terjadi.
Class Diagram dan Object Diagram
Class diagram menggambarkan struktur dan deskripsi class, package dan objek
beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain.
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).
7
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.
Gambar 3 Notasi class
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.
Gambar 4 Notasi Interface class
8
Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi
package. Kita juga dapat membuat diagram yang terdiri atas package.
Gambar 5 Package dari sebuah class
Pada object diagram digambarkan hubungan antar elemen dalam model, tapi
dengan memakai objeknya, bukan class. Class ialah kumpulan dari objek-objek yang
memiliki attribute, behaviour atau operation yang sama.
Class dan object di dalam tahapan design digambarkan dengan letak yang
memiliki tiga bagian. Pada bagian atas diberi nama class atau object. Bagian tengah
merupakan bagian yang berisi attribute yang dimiliki dan bagian bawah berisi
operation.
Dalam class dan object diagram tersebut terdapat beberapa istilah-istilah,
diantaranya yaitu :
Association Link
Merupakan link yang mewakili hubungan antar dua objek. Association
adalah hubungan antar class dan mewakili kelompok link.
Multiplicity
Merupakan banyaknya hubungan yang mungkin terjadi antar class.
Aggregation
Merupakan bentuk khusus dari association yang menggambarkan bahwa
satu class merupakan bagian dari class lainnya, ”a part of”. Dalam
beberapa kasus, satu class dapat terbagi menjadi beberapa class lagi.
Generalization
9
Merupakan hubungan antara class induk (super class) dengan class anak
(sub class). Hubungan yang terjadi adalah ”is a”. Pada hubungan
generalisasi attribute dan behaviour yang terdapat pada super class akan
diwarisi oleh sub class.
Berikut adalah contoh sebuah class diagram :
Gambar 6 Contoh Class diagram
Component Diagram
Component Diagram merupakan gambaran aspek fisik sistem berbasis objek
dengan menunjukkan hubungan dan ketergantungan dalam serangkaian komponen.
Menggambarkan komponen fisik software termasuk source code, run time (binary)
code, executable file, table, library, dan dokumen. Meliputi komponen, interface,
dependency, generalization, association, realization, notes, constraint, packages,
subsystem dari sebuah model.
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.
10
Diagram ini digunakan untuk memodelkan implementasi sistem yang sifatnya
statis sehingga dapat mendukung untuk mengatur konfigurasi dari bagian sistem.
Berikut ini adalah sebuah contoh dari component diagram :
Gambar 7 Contoh Component diagram
Deployment diagram
Deployment diagram menggambarkan sumber fisik dalam sistem, termasuk
node, komponen dan koneksi (model implementasi sistem yang statistik). Dalam hal ini
meliputi topologi hardware yang dipakai sistem.
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.
Berikut adalah contoh dari Deployment diagram :
11
Gambar 8 Contoh Deployment 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.
12
Titik awal dan akhir digambarkan berbentuk lingkaran berwarna penuh dan
berwarna setengah.
Berikut adalah contoh dari Statechart diagram :
Gambar 9 Contoh Statechart diagram
Diagram struktur dinamis dari sistem
Adalah kumpulan diagram yang menggambarkan hubungan dinamis antara class
yang berada dalam komponen model.
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 system 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
13
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.
Use case merupakan salah satu metode dalam analisis dan desain sistem
berorientasi objek (Object Oriented Analysis and Design). Use case juga
merupakan bagian dari UML (Unified Modelling Language). Use case
modelling digunakan untuk mendokumentasikan system behaviour dan
subsystem pada saat pengembangan sistem, termasuk di dalamnya fungsi
internal suatu sistem (use case), pengguna sistem (user) dan hubungan interaksi
antara keduanya (use case diagram).
Use case diwujudkan dalam bentuk diagram dengan beberapa notasi
baku yang ditujukan untuk memudahkan kita melihat keseluruhan behaviour
dari sebuah sistem. Use case tidak hanya digambarkan dalam bentuk diagram
saja, namun diwujudkan pula dalam bentuk teks, yang dikenal dengan narrative
use case, dimana proses yang ada dalam use case digambarkan dengan kata-kata
sehingga menjadi lebih jelas.
Use-Case Diagram Sistem yang sedang Berjalan
14
Menempatkan_Pengajar
Menempatkan_Binglas
Lihat_Jadwal_Bimbingan_Kelas
Lihat_Jadwal_Mata_PelajaranPengajar
(f rom Actors)
Binglas
(f rom Actors)
Menyetujui_Jadwal
Koordinator Bidang Studi
(f rom Actors)
Koordinator Sekretariat II
(f rom Actors)
Membuat_Jadwal_Kegiatan_BTA8
Gambar 1 : Use-Case Diagram Sistem yang Sedang Berjalan
Use-Case Narrative Sistem yang sedang Berjalan
15
USE CASE NAME: Lihat_Jadwal_Pelajaran USE CASE TYPEUSE CASE ID: Business RequirementsBusiness Requirements:: PRIORITY:
SOURCE:PRIMARY BUSINESS ACTOR:
Koordinator Bidang Studi Pengajar
OTHER PARTICIPATING ACTORS:OTHER INTERESTED STAKEHOLDERS:DESCRIPTION: Use-case ini berjalan saat Koordinator Bidang Studi atau pengajar hendak
melihat jadwal pelajaran yang telah dibuat.PRE-CONDITION: Jadwal pelajaran yang berlaku untuk satu semester ke depan telah
dibuat. TRIGGER: Use-case ini dijalankan saat Koordinator Bidang Studi atau pengajar
hendak menngetahui jadwal pelajaran yang berlaku.
TYPICAL COURSE Actor Action
System Response
OF EVENTS: Step 1: Koordinator Bidang Studi atau pengajar meminta jadwal pelajaran
Step 2: Sistem menampilkan jadwal pelajaran.
ALTERNATE COURSES:
CONCLUSION: Use-case ini selesai saat sistem menampilkan jadwal pelajaran.POST-CONDITION: Koordinator Bidang Studi dan Pengajar mengetahui jadwal pelajaranBUSINESS RULES Koordinator Bidang Studi dan pengajar akan menggunakan jadwal
pelajaran sebagai pedoman dalam bekerja.IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
Jadwal pelajaran yang dihasilkan berupa hasil cetak.
ASSUMPTIONS: Pembuatan jadwal pelajaran merupakan use-case yang terpisahOPEN ISSUES:
Tabel 1 : Use-Case Narrative untuk Lihat_Jadwal_Pelajaran
16
USE CASE NAME: Menempatkan_Pengajar USE CASE TYPEUSE CASE ID: Business RequirementsBusiness Requirements::
PRIORITY:
SOURCE:PRIMARY BUSINESS ACTOR:
Koordinator Bidang Studi
OTHER PARTICIPATING ACTORS:OTHER INTERESTED STAKEHOLDERS:DESCRIPTION: Use-case ini menjelaskan proses pembagian pengajar sesuai dengan
jadwal pelajaran yang telah disusun sebelumnya.PRE-CONDITION: Jadwal pelajaran telah selesai dibuat sebelumnyaTRIGGER: Kegiatan belajar-mengajar yang harus segera berjalan.
TYPICAL COURSE Actor Action
System Response
OF EVENTS: Step 1: Koordinator Bidang Studi melihat jadwal pelajaran yang akan diajarkan selama satu semester ke depan
Step 2: Sistem akan memberikan daftar nama pengajar mata pelajaran yang bersangkutan
Step 3: Koordinator akan memilih pengajar sesuai dengan jadwal mata pelajaran yang ada
Step 4: Sistem akan menyimpan jadwal pelajaran beserta pengajar
ALTERNATE COURSES:
CONCLUSION: Use-case ini selesai saat jadwal kegiatan belajar-mengajar selesai dibuat
POST-CONDITION: Koordinator Bidang Studi dan pengajar dapat mengetahui jadwal pelajaran untuk satu semester ke depan
BUSINESS RULES Jadwal pelajaran akan berlaku selama satu semesterIMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
Jadwal pelajaran dicetak dan dibagikan kepada seluruh pengajar.
ASSUMPTIONS: Para pengajar telah memberitahukan Koordinator Bidang Studi tentang jadwal kegiatan mereka selama satu semester ke depan
17
OPEN ISSUES: 1. Jadwal pelajaran yang dibuat oleh sistem berdasarkan jadwal kerja para pengajar.
2. Koordinator Bidang Studi hanya bertindak sebagai pengambil keputusan dalam penyusunan jadwal pelajaran.
Tabel 2 : Use-Case Narrative untuk Menempatkan_Pengajar
18
USE CASE NAME: Menyusun_Jadwal_Kegiatan_BTA8
USE CASE TYPE
USE CASE ID: Business RequirementsBusiness Requirements::
PRIORITY:
SOURCE:PRIMARY BUSINESS ACTOR:
Koordinator Bidang Studi Koordinator Sekretariat II
OTHER PARTICIPATING ACTORS:OTHER INTERESTED STAKEHOLDERS:DESCRIPTION: Use-case ini menjelaskan tentang proses pembuatan jadwal kegiatan
dari selama satu semester ke depan.PRE-CONDITION: Jadwal pelajaran dan jadwal bimbingan kelas telah selesaiTRIGGER: Use-case ini dijalankan untuk membuat jadwal kegiatan selama satu
semester ke depanTYPICAL COURSE Actor Action System ResponseOF EVENTS: Step 1: Para koordinator
membuat jadwal kegiatan Step 2: Sistem akan menggabungkan jadwal pelajaran dan jadwal bimbingan kelas yang telah ada.Step 3: Sistem akan mencetak jadwal kegiatan
ALTERNATE COURSES:
CONCLUSION: Use-case ini selesai saat jadwal kegiatan telah selesai dibuat.POST-CONDITION: Koordinator Bidang Studi dan Koordinator Sekretariat II dapat
mengatur kegiatan BTA SMA 8 selama satu semester ke depan.BUSINESS RULES Jadwal kegiatan yang dihasilkan akan dipergunakan oleh
koordinator Bidang Studi atau Koordinator Sekretariat II.IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
Sistem akan menggabungkan jadwal pelajaran dengan jadwal bimbingan kelas, kemudian dicetak dalam satu format.
ASSUMPTIONS: Proses pembuatan jadwal pelajaran dan jadwal bimbingan kelas merupakan proses yang terpisah.
OPEN ISSUES:
Tabel 3 : Use-Case Narrative untuk Menyusun_Jadwal_Kegiatan_BTA8
19
USE CASE NAME:
Menyetujui_Jadwal USE CASE TYPE
USE CASE ID: Business RequirementsBusiness Requirements::
PRIORITY:
SOURCE:PRIMARY BUSINESS ACTOR:
Pengajar Binglas
OTHER PARTICIPATING ACTORS:OTHER INTERESTED STAKEHOLDERS:DESCRIPTION: Use-case ini menjelaskan proses persetujuan dari pengajar dan
Binglas mengenai jadwal pelajaran dan pembagian Binglas yang telah selesai dibuat. Persetujuan dari pengajar dan Binglas ini dibutuhkan dalam menyusun jadwal kegiatan dari BTA SMA 8 untuk satu semester ke depan.
PRE-CONDITION:
Jadwal pelajaran telah selesai dibuat.Pembagian Binglas telah selesai dibuat.
TRIGGER: Use-case ini dijalankan saat ingin membuat jadwal kegiatan TYPICAL COURSE Actor Action System ResponseOF EVENTS: Step 1: Koordinator Bidang
Studi meminta persetujuan dari pengajar terhadap jadwal pelajaran.
Step 2: Sistem akan memproses persetujuan dari pengajar
Step 3: Koordinator Sekretariat II meminta persetujuan dari Binglas
Step 4: Sistem memproses persetujuan dari Binglas.
ALTERNATE COURSES:
CONCLUSION: Use-case ini selesai saat pengajar dan Binglas menyetujui jadwal dan pembagian yang telah dibuat.
POST-CONDITION: Jadwal kegiatan dapat dibuatBUSINESS RULES Persetujuan ini diperlukan untuk pembuatan jadwal kegiatan IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
Pengajar dan Binglas menanda tangani lembar persetujuan tentang jadwal yang telah dibuat sebelumnya.
Tabel 4 : Use-Case Narrative untuk Menyetujui_Jadwal
20
USE CASE NAME: Menempatkan_Binglas USE CASE TYPEUSE CASE ID: Business RequirementsBusiness Requirements::
PRIORITY:
SOURCE:PRIMARY BUSINESS ACTOR:
Koordinator Sekretariat II
OTHER PARTICIPATING ACTORS:OTHER INTERESTED STAKEHOLDERS:DESCRIPTION: Use-case ini menjelaskan proses pembagian Binglas ke semua kelas
yang ada di BTA SMA 8.PRE-CONDITION: Jadwal pelajaran telah selesai dibuat sebelumnyaTRIGGER: Kegiatan belajar-mengajar yang harus segera berjalan.
TYPICAL COURSE Actor Action System ResponseOF EVENTS: Step 1: Koordinator Bidang
Studi melihat jadwal pelajaran yang akan diajarkan selama satu semester ke depan
Step 2: Sistem akan memberikan daftar nama Binglas yang terdaftar.
Step 3: Koordinator akan memilih Binglas sesuai dengan jumlah kelas yang ada
Step 4: Sistem akan menyimpan penempatan Binglas
ALTERNATE COURSES:
CONCLUSION: Use-case ini selesai saat semua kelas yang ada di telah memiliki seorang Binglas.
POST-CONDITION: Koordinator Sekretariat II dan Binglas dapat mengetahui penempatan dalam kegiatan .
BUSINESS RULES Pembagian Binglas akan berlaku selama satu semesterIMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
Setiap kelas memiliki seorang Binglas
ASSUMPTIONS: Para Binglas telah memberitahukan Koordinator Sekretariat II tentang jadwal kegiatan mereka selama satu semester ke depan
OPEN ISSUES:
21
USE CASE NAME: Lihat_Jadwal_Binglas USE CASE TYPEUSE CASE ID: Business RequirementsBusiness Requirements::
PRIORITY:
SOURCE:PRIMARY BUSINESS ACTOR:
Koordinator Sekretariat II Binglas
OTHER PARTICIPATING ACTORS:OTHER INTERESTED STAKEHOLDERS:DESCRIPTION: Use-case ini menjelaskan proses untuk melihat jadwal Binglas yang
akan dilakukan oleh Koordinator Sekretariat II atau Binglas.PRE-CONDITION: Pembagian Binglas telah selesai dibuatTRIGGER: Use-case ini dijalankan saat ada permintaan untuk menampilkan
jadwal Binglas yang telah dibuat.TYPICAL COURSE Actor Action System ResponseOF EVENTS: Step 1: Koordinator
Sekretariat II atau Binglas meminta jadwal Binglas.
Step 2: : Sistem mencetak jadwal Binglas.
CONCLUSION: Use-case ini selesai saat sistem mencetak jadwal BinglasPOST-CONDITION: Koordinator Sekretariat II dan Binglas telah mengetahui jadwal
BinglasBUSINESS RULES Jadwal Binglas yang akan dijadikan pedoman bagi Binglas untuk
bekerja Koordinator Sekretariat II akan menggunakan jadwal Binglas
dalam evaluasi BinglasIMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
Jadwal Binglas langsung dicetak oleh sistem
ASSUMPTIONS: Pembuatan jadwal Binglas merupakan proses yang terpisah dari use-case ini.
OPEN ISSUES: 1. Jadwal Binglas dapat dikirimkan kepada pihak yang berkepentingan melalui teknologi e-mail.
Tabel 5 : Use-Case Narrative untuk Lihat_Jadwal_Binglas
Terdapat 3 bagian utama dalam use case modeling sebagaimana dijelaskan berikut ini :
22
Actor
Actor sebagai perwujudan dari pengguna sistem, proses dan segala
sesuatu yang berinteraksi dalam sistem tersebut. Actor tidak termasuk dalam
sistem, tetapi dapat menggambarkan interaksi dari external user dengan sistem
tersebut. Setiap actor berinteraksi dengan satu atau lebih use case dengan
pertukaran pesan atau informasi.
Use Case
Use case merupakan bagian dari sebuah sistem yang menyediakan
sebuah fungsi atau tugas tertentu dan terdiri dari serangkaian aksi, use case
memperlihatkan external behaviour dari sebuah sistem yang dilihat dari segi
pengguna eksternal. Use case tidak seperti operation karena sebuah use case
dapat terus menerima input dari actor pada saat dijalankan, dan use case dapat
diterapkan pada unit sistem yang lebih kecil seperti subsistem.
System Boundary
System boundary menjelaskan batasan suatu sistem dengan
lingkungannya, sehingga memberi batasan yang jelas sampai mana suatu sistem
bekerja, termasuk membatasi sistem dengan actor yang berada di luar sistem. Di
dalam system boundary terletak kumpulan use case dari sebuah sistem.
Berikut adalah contoh dari use case diagram :
23
Gambar 10 Contoh Use case diagram
Sequence diagram
Sequence diagram merupakan diagram yang menggambarkan pola
hubungan diantara sekumpulan objek yang saling mempengaruhi menurut
urutan waktu. Sebuah objek berinteraksi dengan objek lain melalui pengiriman
pesan (messages). Sequence diagram biasanya digunakan untuk
mengilustrasikan sebuah use case.
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.
24
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.
Berikut adalah contoh notasi dari Sequence diagram :
Gambar 11 Notasi Sequence diagram
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.
25
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.
Berikut adalah contoh Activity diagram tanpa swimlane :
Gambar 12 Contoh Activity diagram-tanpa swimlane
Collaboration diagram
26
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.
Gambar 13 Contoh Collaboration diagram
Contoh kasus
Pada umumnya tidak semua diagram dalam UML harus digunakan untuk
melakukan desain dan analisis, hal ini disesuaikan dengan kebutuhan saja. Berikut
adalah contoh beberapa diagram pada kasus PT Rackindo Setara Perkasa dimana
dibutuhkan sebuah sistem untuk dapat mendukung proses bisnisnya terutama dalam
bagian manufakturnya. PT Rackindo Setara Perkasa menghasilkan berbagi macam
jenis lemari diantaranya yaitu lemari pakaian, lemari pajangan dan sebagainya.
Lemari pakaian yang diproduksi mempunyai berbagai macam merek Untuk
mencapai kesuksesan dalam menghadapi persaingan, maka diperlukan penanganan
yang baik mulai dari bahan baku datang ke pabrik sampai dengan penyampaian
produk ke konsumen. Agar penanganan tersebut berjalan dengan baik kita harus
memperhatikan proses produksi secara efisien. Salah satu kunci dalam melakukan
proses produksi yang efisien terletak pada pengelolaan bahan baku. Oleh sebab itu
27
untuk dapat membangun suatu sistem penanganan manufaktur ini akan dilakukan
analisis dan desain digambarkanlah diagram – diagram UML yaitu class diagram ,
component diagram, dan deployment diagram.
a) Class diagram
Gambar 14 Class Diagram PT Rackindo Setara Perkasa
28
b) Component diagram
Gambar 15 Component diagram PT Rackindo Setara Perkasa
29
c) Deployment diagram
30
Gambar 15 Deployment diagram PT Rackindo Setara Perkasa
31
KESIMPULAN DAN SARAN
Kesimpulan
Unified Modeling Language (UML) adalah bahasa pemodelan umum yang
digunakan untuk melakukan spesifikasi, visualisasi, konstruksi dan dokumentasi artifak
dari software system. UML bukanlah sebuah standar proses pengembangan dalam
metode pengembangan sistem tertentu, namun pada umumnya UML dipakai dalam
memodelkan sistem yang dibangun berbasiskan objek.
Tujuan UML menurut Booch, Rumbaugh dan Jacobson :
Memberikan model yang siap pakai, bahasa pemodelan visual yang ekspresif
untuk mengembangkan dan saling menukar model dengan mudah dan
dimengerti secara umum.
Memberikan bahasa pemodelan yang bebas dari berbagai bahasa
pemograman dan proses rekayasa.
Menyatukan praktek-praktek terbaik yang terdapat dalam pemodelan.
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
UML mendefinisikan diagram-diagram sebagai berikut:
usecase diagram
class diagram
statechart diagram
activity diagram
sequence diagram
collaboration diagram
component diagram
deployment diagram
Saat ini banyak sekali tool pendesainan yang mendukung UML, baik itu tool
komersial maupun opensource. Beberapa diantaranya adalah:
32
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)
Saran
UML adalah suatu bahasa perancangan modern yang paling umum dipakai pada
saat ini, dimana UML ini sering dikaitkan dengan bahasa pengembangan piranti lunak
berbasis objek. Dengan menggunakan UML sebagai bahasa perancangan maka kita
dapat membuat suatu rancangan piranti lunak yang dimana bahasa tersebut menyatukan
berbagai praktik-praktik terbaik dalam permodelan, sehingga hasil rancangan kita dapat
dimengerti secara umum dan universal.
Dengan menggunakan UML, maka kita dapat berinteraksi lebih mudah dengan
para perancang piranti lunak yang lain, karena kita memakai bahasa perancangan UML
yang bersifat universal, dan diketahui oleh hampir semua perancang piranti lunak.
Sehingga kita dapat saling bertukar pikiran atas rancangan yang kita buat dengan
perancang lain, dan menghilangkan gap dalam perbedaan bahasa permodelan.
DAFTAR PUSTAKA
Anonymous 1.( 23 Mei,2008), Introduction to OMG UML, OMG.
Fowler, Martin. (2004). A brief Duide to the Standard Object Modeling Language. Penerbit ANDI, Yogyakarta.
http://www.omg.org/gettingstarted/what_is_uml.htm.
Rumbaught J, Jacobson I, Booch G. (1999). The Unified Modeling Language Reference Manual. Addison Wesley, New Jersey.
Suhendar,A. S. Si. dan Gunadi, Hariman S.Si., MT. (2002). Visual modeling menggunakan uml dan rational rose . Penerbit Informatika Bandung, Bandung.
33