MAKALAH ANALISIS DAN DESAIN BERORIENTASI OBJEK PENGENALAN UNIFIED MODELING LANGUAGE (UML)
Di Susun Oleh Rika Lestari : 2006173
Kelas : E
JURUSAN ILMU KOMPUTER
PROGRAM STUDI TEKNIK INFORMATIKA INSTITUT TEKNOLOGI GARUT
2022
KATA PENGANTAR
Segala puji dan syukur tidak henti-hentinya kita panjatkan kehadirat Allah Swt yang telah memberikan rahmat, nikmat dan anugerah-Nya sehingga Makalah Praktikum Analisis dan Desain Berorientasi Objek ini dapat terselesaikan tepat waktu.
Saya mengucapkan terima kasih kepada semua pihak yang telah membantu dan terlihat dalam proses pembuatan Makalah Analisis dan Desain Berorientasi Objek ini, terkhusus kepada: Bapak Ridwan Setiawan, S.Kom.,M.Kom selaku dosen pengampu mata kuliah Praktikum Jaringan Analisis desain Berorientasi Objek .Kepada segenap asisten dosen Praktikum Analisis Desain Berorientasi Objek yang tetap sabar untuk membimbing saya selama berlangsungnya praktikum.
Dan kepada para orangtua yang tak pernah putus mendoakan agar kuliah kami berjalan dengan baik.
Demikianlah Makalah Analisis dan Desain Berorientasi Objek ini saya buat dengan sepenuh hati. Menyadari Makalah ini masih belum sempurna maka mohon kritik dan saran harapan agar makalah ini dapat menjadi lebih baik lagi.Semoga makalah ini bisa bermanfaat bagi semua dan terkhusus bagi selaku penulis. Saya ucapkan Terima Kasih.
Garut, Oktober 2022 Penyusun
Rika Lestari
1 DAFTAR ISI
KATA PENGANTAR ... i
DAFTAR ISI ... 1
DAFTAR GAMBAR ... 2
BAB I PENDAHULUAN ... 3
1.1 Latar Belakang... 3
1.2 Rumusan Masalah ... 4
1.3 Tujuan Penulisan ... 4
BAB II LANDASAN TEORI ... 5
2.1 Keselarasan Arsitektur... 5
2.2 Semantik UML ... 6
2.2.1 Model UML ... 6
2.2.2 Area Semantik ... 7
2.3 Format Diagram UML ... 8
BAB III HASIL DAN PEMBAHASAN... 10
3.1 Diagram UseCase ... 10
3.1.1 Sintak Abstrak Diagram USeCase ... 10
3.2 Deployment Diagram ... 13
3.2.1 Abstrak Sintak ... 13
3.2.2 Notasi ... 14
3.3 Package Diagram ... 15
3.3.1 Abstrak Sintak ... 15
3.3.2 Package Merge ... 16
3.3.3 General Package Merge Rules ... 16
3.3.4 Package Rules ... 18
3.3.5 Notasi ... 19
BAB IV KESIMPULAN... 21
2
DAFTAR PUSTAKA ... 20
DAFTAR GAMBAR Gambar 3. 1 Sintak Abstrak Diagram UseCase ... 10
Gambar 3. 2 Abstrak Sintak Deployment Diagram ... 13
Gambar 3. 3 Abstrak Sintak Package Diagram ... 15
Gambar 3. 4 Ilustrasi Arti Package Merge ... 16
3 BAB I PENDAHULUAN 1.1 Latar Belakang
Tujuan dari UML adalah untuk menyediakan arsitek sistem, insinyur perangkat lunak, dan pengembang perangkat lunak dengan alat untuk analisis, desain, dan implementasi sistem berbasis perangkat lunak serta untuk pemodelan bisnis dan proses serupa.
Versi awal UML (UML 1) berasal dari tiga metode berorientasi objek terkemuka (Booch, OMT, dan OOSE), dan menggabungkan sejumlah praktik terbaik dari desain Bahasa pemodelan, pemrograman berorientasi objek, dan bahasa deskripsi arsitektur. Dibandingkan dengan UML 1, revisi UML ini telah ditingkatkan secara signifikan definisi yang lebih tepat dari aturan sintaksis abstrak dan semantiknya, struktur bahasa yang lebih modular, dan peningkatan kemampuan untuk pemodelan sistem skala besar.
Salah satu tujuan utama UML adalah untuk memajukan keadaan industri dengan mengaktifkan alat pemodelan visual objek interoperabilitas. Namun, untuk memungkinkan pertukaran informasi model yang bermakna antar alat, kesepakatan tentang semantic dan sintaks diperlukan. UML memenuhi persyaratan berikut:
1. Definisi formal dari metamodel umum berbasis MOF yang menentukan sintaks abstrak UML. Itu sintaks abstrak mendefinisikan kumpulan konsep pemodelan UML, atributnya dan hubungannya, serta aturan untuk menggabungkan konsep-konsep ini untuk membangun model UML parsial atau lengkap.
2. Penjelasan rinci tentang semantik dari setiap konsep pemodelan UML.
Semantik mendefinisikan, dalam teknologi-independen, bagaimana konsep UML direalisasikan oleh komputer.
3. Spesifikasi elemen notasi yang dapat dibaca manusia untuk mewakili pemodelan UML individu konsep serta aturan untuk menggabungkannya ke dalam berbagai jenis diagram yang berbeda sesuai dengan aspek yang berbeda dari sistem yang dimodelkan.
4 1.2 Rumusan Masalah
1. Apa itu UML?
2. Bagaimana struktur UML?
3. Apa saja diagram yang ada pada UML ? 1.3 Tujuan Penulisan
Mengenal apa itu unified modeling language (UML).
5 BAB II LANDASAN TEORI 2.1 Keselarasan Arsitektur
Inisiatif Model Driven Architecture (MDA) OMG adalah arsitektur konseptual untuk serangkaian industri-lebar spesifikasi teknologi yang mendukung pendekatan model-driven untuk pengembangan perangkat lunak. Meskipun MDA itu sendiri bukan spesifikasi teknologi, itu merupakan pendekatan penting dan rencana untuk mencapai satu set kohesif model-driven spesifikasi teknologi. UML, MOF, dan spesifikasi terkait memainkan peran penting dalam MDA dengan menyediakan bahasa untuk membuat dan mengubah model.
Sintaks abstrak UML ditentukan menggunakan model UML yang disebut metamodel UML. Metamodel ini menggunakan konstruksi dari subset UML terbatas yang diidentifikasi dalam spesifikasi MOF 2 dan digunakan untuk konstruksi metamodel. Kelas dalam metamodel disebut metaclasses. Jadi, misalnya, Elemen metaclass UML adalah abstrak kelas dalam metamodel UML:
yang juga berarti dapat dilihat dari perspektif MOF sebagai turunan dari kelas metaclass, yang properti isAbstractnya memiliki nilai true. Contoh lain seperti itu adalah Komentar metaclass UML, yang memiliki atribut bernama body, yang pada gilirannya dapat dilihat dari perspektif MOF sebagai turunan dari metaclass Property yang namanya property memiliki nilai “body”.
Fakta bahwa UML didefinisikan menggunakan dirinya sendiri tidak lebih mengejutkan daripada fakta bahwa banyak bahasa pemrograman memiliki compiler yang ditulis dalam bahasa itu sendiri, atau bahwa fungsi rekursif (seperti fungsi faktorial) dapat didefinisikan menggunakan diri. Kondisi tertentu diperlukan untuk memastikan bahwa definisi yang dihasilkan terbentuk dengan baik dan unik; tidak ada bukti formal bahwa UML memenuhi kondisi ini, tetapi adanya banyak implementasi UML yang dapat dioperasikan menawarkan keyakinan substansial bahwa itu tidak.
Mendefinisikan UML menggunakan subset terbatas ini sendiri memastikan bahwa model UML dapat disimpan dalam repositori MOF 2 di mana mereka dapat
6
dimanipulasi menggunakan fitur MOF, dan dipertukarkan menggunakan XMI sesuai dengan MOF 2 XMI Spesifikasi Pemetaan.
Sejak versi 2.4.1 metamodel MOF 2.x, termasuk metamodel UML 2.x, adalah model UML 2.x yang valid. Ini adalah penyederhanaan dan penyelarasan yang substansial dibandingkan dengan versi sebelumnya. Diharapkan bahwa versi MOF mendatang dan UML akan terus diselaraskan dengan cara ini.
2.2 Semantik UML 2.2.1 Model UML
Model selalu menjadi model dari sesuatu. Hal yang dimodelkan secara umum dapat dianggap sebagai sistem dalam beberapa domain wacana. Model kemudian membuat beberapa pernyataan menarik tentang sistem itu, mengabstraksi dari semua rincian sistem yang mungkin dapat digambarkan, dari sudut pandang tertentu dan untuk tujuan tertentu. Untuk sebuah sistem yang ada, model dapat mewakili analisis sifat dan perilaku sistem. Untuk yang direncanakan sistem, model dapat mewakili spesifikasi tentang bagaimana sistem akan dibangun dan berperilaku.
Model UML terdiri dari tiga kategori utama elemen model, yang masing- masing dapat digunakan untuk membuat pernyataan tentang berbagai jenis hal individu dalam sistem yang dimodelkan (disebut hanya "individu"
dalammengikuti). Kategori ini adalah:
a. Pengklasifikasi. Sebuah classifier menggambarkan satu set objek. Objek adalah individu dengan keadaan dan hubungan dengan objek lain. Keadaan suatu objek mengidentifikasi nilai-nilai untuk objek itu dari properti pengklasifikasi obyek.
b. Acara. Suatu peristiwa menggambarkan serangkaian kemungkinan kejadian. Kejadian adalah sesuatu yang terjadi yang memiliki beberapa konsekuensi yang berkaitan dengan sistem.
c. Perilaku. Sebuah perilaku menggambarkan satu set kemungkinan eksekusi.
Eksekusi adalah kinerja dari serangkaian Tindakan (berpotensi selama
7
beberapa periode waktu) yang dapat menghasilkan dan merespons terjadinya peristiwa, termasuk mengakses dan mengubah keadaan objek.
Model UML tidak berisi objek, kejadian, atau eksekusi, karena individu tersebut adalah bagian dari domain yang sedang dimodelkan, bukan isi dari model itu sendiri. UML memang memiliki konstruksi pemodelan untuk pemodelan langsung individu: spesifikasi instance, spesifikasi kejadian, dan spesifikasi eksekusi untuk objek pemodelan, kejadian, dan eksekusi, masing-masing, dalam konteks tertentu. Namun, ini sekali lagi hanya elemen model, membuat pernyataan tentang individu yang dimodelkan. Adapun model apa pun, pernyataan seperti itu bisa tidak lengkap, tidak tepat, dan abstrak, sesuai dengan tujuan model, dan mungkin salah (atau bahkan dinyatakan sebagai kontrafaktual). Individu yang dimodelkan, di sisi lain, selalu lengkap, tepat, dan konkret dalam domain mereka.
2.2.2 Area Semantik
Klausul 2 membedakan kesesuaian alat dengan sintaks UML (konkret dan abstrak) dari kesesuaian dengan semantiknya.
Sintaks UML berkaitan dengan bagaimana model UML dapat dibangun, diwakili, dan dipertukarkan. UML spesifikasi mendefinisikan sintaks UML, baik secara abstrak maupun konkret. Namun, sintaks UML ditentukan dalam kerangka MOF, dan arti model sintaksis untuk tujuan kesesuaian alat diberikan dalam spesifikasi MOF Core dan spesifikasi XMI dan Diagram Interchange terkait.
Sebaliknya, semantik UML itu sendiri berkaitan dengan makna standar dari pernyataan yang dibuat oleh model UML tentang sistem yang dimodelkan. Ini kadang-kadang disebut sebagai semantik "run-time" UML, terutama di konteks model UML dari perangkat lunak yang dapat dieksekusi atau proses lain yang dapat dijalankan. Namun, tidak semua model UML adalah dapat dieksekusi dalam pengertian ini dan tidak semua semantik UML berhubungan dengan perangkat lunak yang "berjalan" atau proses lainnya.
8
Sebagai gantinya, pertimbangkan pembagian umum konstruksi pemodelan UML menjadi dua kategori semantik:
a. Semantik Struktural mendefinisikan makna elemen model struktural UML tentang individu dalam domain dimodelkan, yang mungkin benar pada beberapa titik waktu tertentu. (Perhatikan bahwa kategori ini kadang- kadang disebut “semantik statis”. Namun, dalam definisi bahasa pemrograman, istilah "semantik statis" umumnya digunakan berarti resolusi nama yang peka konteks dan batasan tipe di luar sintaks bebas konteks dasar dari bahasa, yang sesuai dengan batasan yang terbentuk dengan baik dalam spesifikasi sintaksis abstrak UML. Dalam urutan untuk menghindari kebingungan, istilah "semantik struktural" digunakan di sini sebagai gantinya.)
b. Semantik Perilaku mendefinisikan makna elemen model perilaku UML yang membuat pernyataan tentang bagaimana individu dalam domain yang dimodelkan berubah dari waktu ke waktu. (Ini kadang-kadang juga disebut
"dinamis"semantik.").
2.3 Format Diagram UML
Konvensi berikut diadopsi untuk semua diagram metamodel di seluruh spesifikasi ini.
1. Metaclass mungkin muncul pada banyak diagram, tetapi hanya berperan utama pada satu diagram, yaitu diagram berdekatan dengan tempat semantik metaclass dijelaskan. Metaclass dalam peran utama ditampilkan dengan kompartemen atribut diperluas; metaclass dalam peran sekunder ditampilkan hanya sebagai persegi panjang headernya.
2. Notasi titik digunakan untuk menunjukkan kepemilikan akhir asosiasi, di mana titik menunjukkan bahwa Kelas di ujung lainnya line memiliki Properti yang tipenya adalah Kelas yang disentuh oleh titik.
3. Notasi panah digunakan untuk menunjukkan kemampuan navigasi akhir asosiasi. Menurut definisi, semua ujung asosiasi milik kelas adalah dinavigasi. Dengan konvensi, semua ujung yang dimiliki asosiasi dalam metamodel tidak dapat dinavigasi.
9
4. Asosiasi tanpa ujung yang ditandai dengan panah navigasi berarti bahwa asosiasi tersebut dapat dinavigasi di keduanya arah.
5. Spesialisasi dan redefinisi asosiasi ditunjukkan oleh batasan yang sesuai yang terletak di dekat asosiasi berakhir di mana mereka berlaku. Dengan demikian:
a. Batasan {subsets endA} berarti bahwa ujung asosiasi tempat batasan ini diterapkan adalah subset akhir asosiasiA.
b. Batasan {redefines endA} berarti akhir asosiasi yang diterapkan batasan ini mendefinisikan kembali akhir asosiasi endA.
6. Jika tidak ada multiplisitas yang ditunjukkan pada ujung asosiasi, ini menyiratkan multiplisitas tepat 1.
7. Jika ujung asosiasi tidak berlabel, nama default untuk ujung itu adalah nama kelas tempat ujung itu berada dilampirkan, diubah sedemikian rupa sehingga huruf pertama menjadi huruf kecil. Perhatikan bahwa, menurut konvensi, asosiasi yang tidak dapat dinavigasi ujung sering dibiarkan tanpa label meskipun semua ujung asosiasi memiliki nama yang didokumentasikan dalam Asosiasi Bagian deskripsi setiap klausa.
8. Asosiasi yang tidak disebutkan namanya secara eksplisit, diberikan nama yang dibangun sesuai dengan berikut aturan produksi:
"A_" <nama-akhir-asosiasi1> "_" <nama-akhir-asosiasi2>
di mana <association-end-name1> adalah nama akhir asosiasi pertama dan
<association-end-name2> adalah Namanya dari akhir asosiasi kedua.
10 BAB III
HASIL DAN PEMBAHASAN 3.1 Diagram UseCase
UseCase adalah sarana untuk menangkap persyaratan sistem, yaitu, sistem apa yang seharusnya dilakukan. Konsep kunci ditentukan dalam klausa ini adalah Aktor, UseCase, dan subjek. Setiap subjek UseCase mewakili sistem di bawah pertimbangan yang UseCase berlaku. Pengguna dan sistem lain yang dapat berinteraksi dengan subjek diwakili sebagai Aktor.
UseCase adalah spesifikasi perilaku. Sebuah instance dari UseCase mengacu pada kemunculan perilaku yang muncul yang sesuai dengan UseCase yang sesuai. Contoh seperti itu sering dijelaskan oleh Interaksi.
3.1.1 Sintak Abstrak Diagram USeCase
a. Aktor
Aktor memodelkan jenis peran yang dimainkan oleh entitas yang berinteraksi dengan subjek UseCase yang terkait (misalnya, dengan bertukar sinyal dan data).
Aktor dapat mewakili peran yang dimainkan oleh pengguna manusia, perangkat keras eksternal, atau sistem lain.
Gambar 3. 1 Sintak Abstrak Diagram UseCase
11
Seorang Aktor tidak harus mewakili entitas fisik tertentu melainkan peran tertentu dari beberapa entitas yang relevan dengan spesifikasi UseCase terkait.
Dengan demikian, satu contoh fisik dapat memainkan peran beberapa Aktor yang berbeda dan, sebaliknya, Aktor tertentu dapat dimainkan oleh beberapa contoh yang berbeda.
Istilah "peran" digunakan secara informal di sini dan tidak menyiratkan definisi teknis apa pun dari istilah yang ditemukan tempat lain dalam spesifikasi ini.
Ketika seorang Aktor memiliki asosiasi ke UseCase dengan multiplisitas yang lebih besar dari satu di ujung UseCase, itu berarti bahwa Aktor tertentu dapat terlibat dalam beberapa UseCase jenis itu. Sifat spesifik dari keterlibatan ganda ini tergantung pada kasus yang ada dan tidak ditentukan dalam spesifikasi ini. Dengan demikian, Aktor dapat memulai beberapa UseCase dalam paralel (bersamaan) atau pada titik waktu yang berbeda.
b. Extends
Extend adalah hubungan dari UseCase yang diperluas (ekstensi) ke UseCase yang diperluas (extendedCase) yang menentukan bagaimana dan kapan perilaku yang didefinisikan dalam UseCase yang diperluas dapat dimasukkan ke dalam perilaku yang didefinisikan dalam UseCase diperpanjang. Ekstensi terjadi pada satu atau lebih titik ekstensi spesifik yang ditentukan dalam UseCase yang diperluas.
Extend dimaksudkan untuk digunakan ketika ada beberapa perilaku tambahan yang harus ditambahkan, mungkin secara kondisional, untuk perilaku yang didefinisikan dalam satu atau lebih UseCase.
c. Include
Include adalah Directed Relationship antara dua UseCase, yang menunjukkan bahwa perilaku UseCase yang disertakan tambahan dimasukkan ke dalam perilaku termasuk UseCase (termasukCase). Itu juga semacam NamedElement jadi bahwa ia dapat memiliki nama dalam konteks UseCase yang dimilikinya (termasukCase).
UseCase yang disertakan mungkin bergantung pada perubahan yang dihasilkan
12
dengan menjalankan UseCase yang disertakan. UseCase yang disertakan harus tersedia untuk perilaku termasuk UseCase untuk dijelaskan sepenuhnya.
Hubungan Include dimaksudkan untuk digunakan ketika ada bagian umum dari perilaku dua atau lebih UseCase. Bagian umum ini kemudian diekstraksi ke UseCase terpisah, untuk dimasukkan oleh semua UseCase dasar yang memiliki bagian ini umum. Karena penggunaan utama dari hubungan Sertakan adalah untuk penggunaan kembali bagian umum, yang tersisa di UseCase dasar adalah biasanya tidak lengkap dengan sendirinya tetapi tergantung pada bagian-bagian yang disertakan untuk menjadi bermakna. Hal ini tercermin dalam arah hubungan, menunjukkan bahwa UseCase dasar bergantung pada penambahan tetapi tidak sebaliknya.
Semua perilaku UseCase yang disertakan dieksekusi di satu lokasi dalam UseCase yang disertakan sebelum eksekusi termasuk UseCase dilanjutkan.
Hubungan Include memungkinkan komposisi hierarkis UseCase serta penggunaan kembali UseCase.
d. Notasi
UseCase ditampilkan sebagai elips, baik berisi nama UseCase atau dengan nama UseCase ditempatkan di bawah elips. Kata kunci stereotip opsional dapat ditempatkan di atas nama.
Subjek untuk satu set UseCase (kadang-kadang disebut batas sistem) dapat ditampilkan sebagai persegi panjang dengan namanya di pojok kiri atas, dengan elips UseCase terletak secara visual di dalam persegi panjang ini. UseCase dengan model yang sama mungkin digambarkan secara visual sebagai elips terpisah dalam beberapa persegi panjang subjek. Dimana subjek adalah Classifier dengan standar stereotip, kata kunci untuk stereotip harus ditampilkan dalam guillemet di atas nama subjek. Dalam kasus di mana metaclass dari suatu subjek ambigu, kata kunci. sesuai dengan notasi untuk metaclass dari Classifier harus ditunjukkan dalam guillemet di atas nama. Jika beberapa kata kunci dan/atau nama stereotip berlaku, opsi notasi yang ditentukan oleh 9.2.4 akan berlaku.
13 3.2 Deployment Diagram
Paket Deployments menentukan konstruksi yang dapat digunakan untuk mendefinisikan arsitektur eksekusi sistem dan penugasan artefak perangkat lunak ke elemen sistem. Model penyebaran yang efisien, cukup untuk sebagian besar aplikasi modern, disediakan. Di mana model penyebaran yang lebih rumit diperlukan, paket dapat diperpanjang melalui profil atau metamodel untuk mewakili lingkungan perangkat keras dan/atau perangkat lunak tertentu.
Deployment menangkap hubungan antara elemen logis dan/atau fisik dari sistem dan teknologi informasi aset yang diberikan kepada mereka.
3.2.1 Abstrak Sintak
Deployment menangkap hubungan antara elemen konseptual atau fisik tertentu dari sistem yang dimodelkan dan aset informasi yang ditugaskan padanya.
Elemen sistem direpresentasikan sebagai DeployedTargets, dan aset informasi, sebagai Dikerahkan Artefak. DeploymentTargets dan DeploymentArtifacts adalah kelas abstrak yang tidak dapat secara langsung dipakai. Namun, mereka diuraikan sebagai kelas konkret seperti yang dijelaskan dalam subklausa Artefak dan Node yang mengikuti.
Hubungan Deployment Individual dapat disesuaikan untuk penggunaan tertentu dengan menambahkan DeploymentSpecifications yang mengandung:
informasi konfigurasi dan/atau parametrik dan dapat diperluas dalam profil komponen tertentu. Sebagai contoh, stereotip standar non-normatif yang mungkin ditambahkan oleh profil ke DeploymentSpecification termasuk
Gambar 3. 2 Abstrak Sintak Deployment Diagram
14
«concurrencyMode», dengan tag nilai {thread, process, none}, dan
«transactionMode», dengan tag nilai {transaction, transaksi bersarang, tidak ada}.
Informasi Deployment Specification menjadi input waktu eksekusi untuk komponen yang terkait dengan DeploymentTargets melalui tautan deployElements mereka. Menggunakan tautan ini, DeploymentSpecifications dapat ditargetkan pada wadah tertentu jenis, selama wadah adalah jenis Komponen. Seperti yang ditunjukkan pada Gambar 19.1, DeploymentSpecifications dapat: ditangkap sebagai elemen hubungan Deployment karena mereka adalah Artefak (dijelaskan dalam subklausa berikut). Selanjutnya, DeploymentSpecifications hanya dapat dikaitkan dengan DeploymentTargets yang ExecutionEnvironments (dijelaskan dalam subklausa Nodes, di bawah).
3.2.2 Notasi
Deployed Targets ditampilkan sebagai tampilan perspektif kubus berlabel nama DeployedTarget yang ditampilkan diawali dengan tanda titik dua. Elemen sistem yang di-deploy pada DeployedTarget, dan Deployment yang menghubungkannya, mungkin digambar di dalam kubus perspektif. Sebagai alternatif, elemen sistem yang digunakan dapat ditampilkan sebagai daftar elemen tekstual nama.
Deployment digambarkan menggunakan notasi garis putus-putus yang sama dengan Dependensi. Ketika hubungan Deployment adalah ditampilkan dalam grafik DeploymentTarget, pelabelan tidak diperlukan. Sebagai alternatif, hubungan Deployment dapat menjadi didekorasi dengan kata kunci «deploy» jika tidak ada di dalam grafik DeployedTarget. Panah penyebaran adalah umumnya ditarik dari DeployedArtifacts ke DeployedTargets.
DeploymentSpesifikasi secara grafis ditampilkan sebagai persegi panjang classifier dan dapat didekorasi dengan «deployment spesifikasi» kata kunci.
Mereka mungkin dilampirkan ke komponen yang disebarkan pada wadah menggunakan panah ketergantungan biasa.
15 3.3 Package Diagram
Package menyediakan struktur generik utama dan kemampuan pengorganisasian UML. Ada spesialisasi untuk Model dan untuk Profil yang mengatur ekstensi ke UML.
3.3.1 Abstrak Sintak
Package adalah ruang nama untuk anggotanya, yang terdiri dari elemen- elemen yang terkait melalui PackageElement (yaitu dikatakan dimiliki atau ditampung), dan yang diimpor.
Definisi Package dapat memperluas konten Paket lain melalui penggabungan elemen yang terkandung.
Package dapat didefinisikan sebagai template dan terikat dengan template lain:
lihat sub klausa 7.3, Template, untuk lebih lanjut informasi.
URI dapat ditentukan untuk memberikan pengidentifikasi unik untuk suatu Paket. Dalam UML tidak ada penggunaan yang telah ditentukan sebelumnya untuk ini, dengan pengecualian profil Ini dapat, misalnya, digunakan oleh fasilitas manajemen model untuk identifikasi model. URI karenanya harus unik dan tidak berubah setelah ditetapkan. Tidak ada persyaratan bahwa URI dapat direferensikan (meskipun ini tentu saja diizinkan).
Gambar 3. 3 Abstrak Sintak Package Diagram
16 3.3.2 Package Merge
PackageMerge adalah hubungan terarah antara dua Paket yang menunjukkan bahwa isi dari target mergedPackage digabungkan ke dalam sumber yang menerimaPackage sesuai dengan seperangkat aturan yang ditentukan di bawah ini. Ini sangat mirip ke Generalisasi dalam arti bahwa elemen sumber secara konseptual menambahkan karakteristik elemen target ke dalamnya karakteristik sendiri sehingga menghasilkan suatu unsur yang menggabungkan karakteristik keduanya. Sama seperti subclass tidak biasanya digambarkan dengan fitur bawaannya, Paket penerima biasanya tidak digambarkan dengan elemen gabungan darinya paket yang digabungkan. Dalam hal semantik model, tidak ada perbedaan antara model dengan PackageMerges eksplisit, dan model di mana semua penggabungan telah dilakukan. Demikian juga file XMI yang berisi PackageMerge secara semantic setara dengan file XMI yang sama dengan PackageMerges yang diperluas.
3.3.3 General Package Merge Rules
Elemen gabungan dan elemen penerima cocok jika memenuhi aturan pencocokan untuk metatipenya.
KENDALA:
1. Tidak boleh ada siklus dalam grafik berarah «gabungkan».
2. Paket tidak dapat menggabungkan Paket yang berisi (melalui owningPackage – langsung atau tidak langsung).
3. Paket tidak dapat menggabungkan Paket yang dikandungnya (melalui PackageElement – langsung atau tidak langsung).
4. Elemen gabungan yang metatipenya bukan jenis Paket, Kelas, Tipe Data, Properti, Asosiasi, Operation, Constraint, Enumeration, atau EnumerationLiteral tidak dapat memiliki elemen penerima dengan elemen
Gambar 3. 4 Ilustrasi Arti Package Merge
17
yang sama nama dan metatipe kecuali elemen penerima itu adalah salinan persis dari elemen yang digabungkan (yaitu, mereka adalah sama).
5. PackageMerge valid jika dan hanya jika semua kendala (dalam klausa ini) yang diperlukan untuk melakukan penggabungan adalah: puas.
6. Elemen yang diketik yang cocok (mis., Properti, Parameter) harus memiliki tipe yang sesuai. Untuk tipe yang merupakan Kelas atau Tipe Data, tipe yang sesuai adalah tipe yang sama atau tipe super umum. Untuk semua kasus lainnya, Kesesuaian berarti jenisnya harus sama.
7. Elemen penerima tidak dapat memiliki referensi eksplisit ke elemen gabungan apa pun.
8. Setiap redefinisi yang terkait dengan RedefinableElements yang cocok tidak boleh bertentangan.
TRANSFORMASI :
1. (Aturan default) Menggabungkan atau menerima elemen yang tidak ada elemen yang cocok akan disalin ke dalam paket yang dihasilkan.
2. Hasil penggabungan dua elemen dengan nama dan metatipe yang cocok yang merupakan salinan persis satu sama lain adalah elemen penerima.
3. Elemen yang cocok digabungkan sesuai dengan aturan transformasi khusus untuk metatipe dan hasil termasuk dalam Paket yang dihasilkan.
4. Semua referensi tipe ke elemen yang diketik yang berakhir di paket yang dihasilkan diubah menjadi referensi ke TypedElements yang dihasilkan sesuai (yaitu, bukan untuk kenaikan masing-masing).
5. Untuk semua elemen yang cocok: jika kedua elemen yang cocok memiliki visibilitas pribadi, elemen yang dihasilkan akan memiliki visibilitas pribadi;
jika tidak, elemen yang dihasilkan akan memiliki visibilitas publik.
6. Untuk semua elemen Classifier yang cocok: jika kedua elemen yang cocok memiliki isAbstract = true, elemen yang dihasilkan memiliki isAbstract = true; jika tidak, elemen yang dihasilkan memiliki isAbstract = false.
7. Untuk semua elemen Classifier yang cocok: jika kedua elemen yang cocok memiliki isFinalSpecialization = true, hasilnya elemen memiliki
18
isFinalSpecialization = true; jika tidak, elemen yang dihasilkan memiliki isFinalSpecialization = false.
8. Untuk semua elemen yang cocok: jika kedua elemen yang cocok tidak diturunkan, elemen yang dihasilkan juga tidak diturunkan; jika tidak, elemen yang dihasilkan diturunkan.
9. Untuk semua MultiplicityElements yang cocok: batas bawah dari elemen yang dihasilkan adalah yang lebih kecil dari batas bawah dari elemen yang cocok.
10. Untuk semua MultiplicityElements yang cocok: batas atas dari elemen yang dihasilkan adalah yang lebih besar dari atas batas elemen yang cocok.
11. Setiap stereotip yang diterapkan pada elemen model baik dalam elemen gabungan atau elemen penerima juga diterapkan pada elemen hasil yang sesuai.
12. Untuk pencocokan RedefinableElements: redefinisi berbeda dari pencocokan RedefinableElements semua diterapkan ke elemen yang dihasilkan.
13. Untuk pencocokan RedefinableElements: jika kedua elemen yang cocok memiliki isLeaf = true, elemen yang dihasilkan juga memiliki isLeaf = true;
jika tidak, elemen yang dihasilkan memiliki isLeaf = false.
3.3.4 Package Rules
Elemen yang merupakan jenis Paket yang cocok dengan nama dan metatipe
KENDALA:
1. Semua Pengklasifikasi dalam Paket yang digabungkan harus memiliki Nama yang memenuhi syarat yang tidak kosong dan memiliki isDistinguishableFrom() = benar dalam Paket yang digabungkan.
2. Semua Pengklasifikasi dalam Paket penerima harus memiliki Nama yang memenuhi syarat yang tidak kosong dan memiliki isDistinguishableFrom()
= benar dalam menerima Paket.
19 TRANSFORMASI:
1. Paket bersarang dari Paket gabungan diubah menjadi Paket bersarang dengan nama dan konten yang sama dalam Paket yang dihasilkan, kecuali Paket penerima sudah berisi Paket bersarang yang cocok. Dalam kasus terakhir, nestedPackage yang digabungkan digabungkan secara rekursif dengan nestedPackage penerima yang cocok.
2. ElementImport yang merupakan elementImport dari Paket penerima diubah menjadi yang sesuai ElementImport dalam Paket yang dihasilkan. Elemen yang diimpor tidak digabung (kecuali ada juga PackageMerge ke Paket yang memiliki elemen yang diimpor).
3.3.5 Notasi
Paket ditampilkan sebagai persegi panjang besar dengan persegi panjang kecil ("tab") yang melekat pada sisi kiri atas paket besar persegi panjang: secara kolektif ini mewakili 'ikon folder.' Anggota Paket dapat ditampilkan dalam besar persegi panjang. Anggota juga dapat ditunjukkan dengan garis bercabang ke elemen anggota, yang digambar di luar paket.
Sebuah tanda plus (+) di dalam lingkaran digambar di ujung yang menempel pada Paket.
Alat yang sesuai dapat membatasi penggunaan notasi ini untuk PackageElements. Secara opsional, elemen yang menjadi tersedia untuk digunakan dalam Paket pengimporan melalui PackageImport atau ElementImport mungkin memiliki warna yang berbeda atau diredupkan untuk menunjukkan bahwa mereka bukan packageElements.
• Jika anggota Paket tidak ditampilkan dalam persegi panjang besar, maka nama Paket harus ditempatkan di dalam persegi panjang besar.
• Jika anggota Paket ditampilkan dalam persegi panjang besar, maka nama Paket harus ditempatkan di dalam tab.
Visibilitas dari PackageElement dapat ditunjukkan dengan mendahului nama dengan simbol visibilitas ('+' untuk publik dan '-' untuk pribadi). Paket mungkin tidak memiliki perlindungan atau visibilitas paket.
20
Alat dapat menunjukkan visibilitas dengan penanda grafis, seperti warna atau font. Alat juga dapat menunjukkan visibilitas dengan selektif menampilkan elemen-elemen yang memenuhi tingkat visibilitas tertentu (misalnya, hanya elemen publik).
Diagram yang menunjukkan Paket dengan anggota tidak perlu harus menunjukkan semua anggotanya; itu mungkin menunjukkan subset dari anggota menurut beberapa kriteria.
URI untuk sebuah Paket dapat ditunjukkan dengan teks {uri = <uri>}
setelah nama Paket.
PackageMerge ditampilkan menggunakan garis putus-putus dengan panah terbuka yang menunjuk dari penerimaPackage (sumber) ke Paket yang digabungkan (target). Selain itu, kata kunci «gabungkan» ditampilkan di dekat garis putus-putus.
21 BAB IV KESIMPULAN
Salah satu tujuan utama UML adalah untuk memajukan keadaan industri dengan mengaktifkan alat pemodelan visual objek interoperabilitas. Namun, untuk memungkinkan pertukaran informasi model yang bermakna antar alat, kesepakatan tentang semantic dan sintaks diperlukan. Beberapa diagram UML yang biasa digunakan adalah Usecase diagram, Deployment diagram, dan Package Diagram.
20
DAFTAR PUSTAKA
Group, O. M. (2017). Unified Modeling Language. Chicago: Object Management Group.
