This is my WorldMe Just Being MeUML Analisis Perancangan BerorientasiObjek1. PengertianUML adalahbahasa grafisyang dipergunakan untuk menangkapartefakdaripengembanganperangkat lunak.Bahasa ini memberikanmodelnotasi grafis.UML merupakansatu satunyabahasa yang dipergunakan secara luas oleh industry.Bahasa ini sangat kaya dan memiliki banyak aspek daripraktek terbaikrekayasa perangkat lunak.Meskipun begitu, UML sendirihanyalahsebuah sintaks, sebuahalat, sebuah bahasa yang dapat dipergunakan untuk membangun perangkat lunak. Akan tetapi untuk membangun sebuah sistem yang kokoh (robust) dan mudah dirawatbergantungpadaprinsipprinsipperancangan(bukan UML) yang didapat dari pengalaman.UMLmenggunakanproses pembangunan perangkat lunak IIF (Iterative, Incremental Framework) dengan 4 tahapan : Inception, Elaboration, Construction, dan Transition. Tahapan construction terdiri dari 4 bagian, yaitu : analisis, perancangan, implementasi, pengujian.2. Ciri ciri UMLUML bersifat generik:UML tidak mengandung hal hal yang berhubungan dengan proses. Sebuah proses untuk perusahaan A mungkin sangat berbeda dengan proses pada perusahaan B.3. Komponen UMLUMLmemilikiberbagai jenisdiagram(model) yangberhubungandenganstake holderpada sebuah pembangunan perangkat lunak. Stake holder tersebut adalah : Analis Disainer Koder Tester QA Pelanggan Penulis teknisBerbagaijenisdiagram UML tersebut adalah : Use case diagramHow will our system interact with the outside world?Mendeskripsikan kelakuan sistem dari sudut pandang pengguna, berguna untuk membantu memahami kebutuhan. Use case adalah dasar dari diagram lain. Class DiagramWhat objects do we need? How will they be related?Dapat dipergunakan pada tingkatan analisis maupun perancangan.Diagram kelas pada tingkatan analisis disebut model konseptual. Collaboration DiagramHow will the objects interact?Diagram kolaborasi (Collaboration Diagram) menggambarkan kolaborasi (kerja sama) yang dilakukan oleh kelas kelas pada sistem. Sequence DiagramHow will the objects interact?Sequence Diagrammenggambarkan bagaimana objek objek di dalam sistem berinteraksi seiring dengan waktu. Ia menampilkan informasi yang sama dengan Diagram Kolaborasi (Collaboration Diagram), hanya dengan bentuk yang berbeda. State DiagramWhat states should our objects be in?Menggambarkan keadaan objek pada suatu waktu di dalam sistem kita. Package DiagramHow are we going to modularize our development?Package Diagrammembagi sistem ke dalam bagan yang lebih kecil dan lebih mudah dimengerti. Component DiagramHow will our software components be related?ComponentDiagrammiripdenganPackageDiagram, ia menotasikan pembagian sistem dan hubungan antar modul. Akan tetapi,ComponentDiagramlebih menekankan komponen perangkat lunak (file, header, link libraries, executeable, package) daripada pembagian logika seperti padaPackage Diagram. Deployment DiagramHow will the software be deployed?Memberikan gambaran terhadap bagaimana rencana untuk melakukan deploy dari perangkat lunak yang telah dibangun.1. TahapanInceptionPada tahapan inception,UML tidak digunakan.Aktivitas utamadari tahapan ini adalah : Menentukan tujuan dari product Membuatbusiness case Mendefinisikan jangkauan dari proyek Menentukan biaya keseluruhan dari proyekSalah satu contohhasil dari tahapan ini adalahbusiness plan.1. TahapanElaborationPada tahapan ini,permasalahanyang diutamakan adalahpendetilanmasalah(bukan pendetilan implementasi), memahamikebutuhanpelanggandan bisnisnya, sertamengembangkanrencanake tingkatan yang lebih lanjut.Aktivitasutamapada tahapan ini adalahmenanggulangiresiko. Semakin cepat sebuah resiko diketahui dan ditanggulangi, semakin kecil akibat yang diakibatkannya terhadap proyek.Melakukan pemodelan terhadap area yang sulit atau bermasalah dari proyek memberikan bantuan yang besar terhadap penanggulangan resiko.UML pada Tahap ElaborationAda2 modelUML yangdipergunakanpadatahapaniniuntuk membantu memahami masalah secara keseluruhan, yaitu :Use Case ModeldanDiagram Class(ConceptualModel).

Gambar 1 dua model UML pada tahap Elaboration1. Short Use CaseDiagramUse Case Modelberfungsi untuk mendeskripsikan interaksi antara user dan sistem. Tujuan dari tahapanelaborationmenemukan sebanyak mugkin use case yang ada tanpa perlu memberikan detil penuh terhadap setiap use case. Use case tersebut akan dikembangkan lebih lanjut pada tahapanconstruction.Untuk use case yang memiliki resiko, adalah hal yang baik untuk melakukan pendetilan terhadapnya dan melakukan penanggulangan resiko.Finding Use CaseAdabeberapapendekatanyang dapat dilakukan untukmenemukanuse case. Salah satunya adalah dengan melakukanwawancaraterhadap pengguna potensial dari sistem. Ini adalahtugasyangsangatsulit. Dari 2 orang yang berbeda mungkin saja didapatkan pandangan yang benar benar berbeda dengan apa yang harus dilakukan oleh sistem (bahkan jika mereka bekerja di bawah organisasi yang sama).Pendekatanlain yang lebihpopularadalahworkshop. Pendekatan ini disebutJoint Requirements Plannin Workshops(JRP).Workshopini mengumpulkan sekumpulan orang yang tertarik pada sistem yang sedang dikembangkan (disebut jugastakeholder) untuk mencari tahu pandangan mereka tentang apa yang perlu dilakukan oleh sistem.Kunci kesuksesanterletak padafasilitator. Mereka memimpin kelompok tersebut untuk memastikan bahwa diskusi tetap berjalan sesuai dengan topiknya dan semuastakeholdermemberikan tanggapannya.Seorangjuru tulisjuga diperlukan untukmencatat dokumentasitentang jalannyaworkshop.Use Caseberperan penting disini,kesederhanaannyamemberikan kemampuan kepadastakeholderyang sekalipun gagap teknologi, dapatmenangkapkonsepdari diagram dengan mudah.Suatumetodeyangsederhanauntuk menyukseskanworkshopadalah : Brainstormsemua actor yang memungkinkan terlebih dahulu. Brainstormsemua use case yang memungkinkan. Selesai brainstorming, lakukanjustifikasiterhadap use case dengan menggunakan grup.Deskripsikansetiap use case dengan 1baris/paragrafsederhana. Jika use casetidak dapatdideskripsikan, besar kemungkinan iabukanlahuse case. Tuangkandalam bentuk model.NB : Jangan memaksakan diri untuk menemukan semua use case dan actor. Adalah hal yang lumrah untuk menambahkan use case dan actor kemudian.NB : Setiap langkah tidak harus benar 100%!Sebuah formulauntuk menentukanjumlahuse case: Apa yangmasukkedalamsistemadalah jumlah darikeseluruhanuse case.Komponen Use CaseAda2 komponenUse CaseModel, yaitu :Use CasedanActor.1. Use Case

Gambar 2 Notasi Use CaseCiri ciri : Use Case dideskripsikan menggunakankombinasikata kerja dan kata benda. Use Case tidak dapat di-inisiasi oleh dirinyya sendiri.1. Actor

Gambar 3 Notasi ActorCiri ciri : Actor dideskripsikan menggunakan kata benda. Dapat(bukan harus) melakukan inisiasi terhadap use case. Actor tidak harus orang, dapat saja sistem, atau entitas yang berhubungan dengan sistem tetapi berasal dari luar sistem. 1 Actor dapat berinteraksi dengan beberapa use case.Tujuan dari Use Case ModelMeskiUseCaseterlihatsederhanaakan tetapi ia merupakankomponenyangpentingdi dalam UML. Berikut adalahkegunaandari Use Case : Mendefinisikanjangkauandari sistem. Memberikanfokusyang lebih baik kepadakebutuhan(requirement) sistem (sebab biasanya kebutuhan sistem cenderung kabur, membingungkan, ambigu, dan ditulis dengan buruk). Gabungandari seluruh Use Case adalahsistemsecarakeseluruhan. Memungkinkankomunikasiantarapelanggandanpengembang. Menuntuntim pengembang melaluiprosespengembangan. Use Case adalahBackbone. Memberikan sebuahmetodeuntukmerencanakankerja pengembangan dan memungkinkanestimasimengenai lama pengembangan. Memberikanbasisuntuk melakukanpengujiansistem. Membantupembuatanuser guide.Use Case GranularityGranularityberbicara tentangsebesarapakah isi dari sebuah use case? Apakahsetiapinteraksipengguna ke sistemharusdituangkan ke dalamsebuahuse caseatauseluruhinteraksitersebut dibungkus di dalamsebuahuse case?Kesalahanutamadi dalam use case adalah seringkali pengembang membuatsejumlah besaruse case kecil dan tidak relevan. Pada sistem yang besar, mungkin sajaberakhirdengan jumlah use case yangtidaklogisdan menyebabkankompleksitasmeningkatpesat.Ada hal yang harus diingat mengenai pembuatan use case : Sebuah use case harus memenuhitujuan akhirdari actor.Contoh : pada kasus mesin ATM, apakah tujuan akhir dari user adalah memasukkan kartu/pin, atau mengambil receipt? Tidak, sehingga tidak perlu membuat use case untuk hal tersebut. Hal yang diperlukan oleh user adalah mengambil uang. Sehingga cukup menggunakan sebuah use case itu saja, meski di dalamnya ada aktivitas seperti memasukkan kartu/pin, dsb.Use Case DescriptionSetiapuse casememilikisekumpulan penuhpenjelasandetil tertulis mengenaiinteraksidanskenariodi dalamnya. Berikut adalahtemplateyang digunakan untuk men-spesifikasi-kanstrukturdanisidari dokumenuse case description:

Gambar 4Use Case Description TemplateUntukShort use case, bagian yangharusdiisiadalah : nama use case, deskripsi singkat, actor (dapat ditambahkanpada template di atas), dan requirement yang dipenuhinya (dapat ditambahkanpada template di atas).Ranking Use CasePada saat melakukan tahapan construction,use caseyang telah dibuat disini akanmengalamiiterasiberulang kali. Untukmembagiuse caseke dalampekerjaaniterasiyang ada,use casedialokasikanmenggunakantingkatan (rank). Secara mudah, tingkatan adalah angka yangmenunjukkanuse caseyang akan dikembangkan.Pengalamanyang akanmenentukanuse casemanakah yang akanmemilikitingkatan lebih tinggi. Ada6 jenis tingkatansecara umum : Risky use cases Major Architechtural Use cases Use cases exercising large areas of system functionality Use Cases requiring extensive research, or new technologies. Quick wins Large Payoffs for the customerSebuah use case mungkin saja mengalami beberapa kali proses iterasi, pecah use case tersebut ke dalam beberapa versi.Pada akhir setiap iterasi, use case tersebutmasih dapatmelakukan sesuatu tetapihanya padasuatu batasan tertentu.1. Diagram Class (Conceptual Model)Conceptual Modeling(disebut jugaDomain Modeling) adalah aktivitas untukmenemukan konsepyang penting untuk sistem. Proses ini membantu untukmemahamimasalahlebih lanjut, danmengembangkanpemahamanlebihmendalamtentang keperluan pelanggan. Untuk melakukan hal ini (menemukan konsep), dipergunakan sintaks UML yaituclass diagram.Catatan pada tahap ini adalah : jangan melakukan perancangan sistem, tahapan yang dilakukan masih analisis.Class Diagramyang telah dihasilkan pada tahapan initidakberhubungandengan tahapanconstruction(Tidak melakukan perancangan sistem). Oleh karenanya,class diagrampada tahapan ini lebih sering disebutconceptual modeluntuk memberikanperbedaandenganclass diagramsesungguhnyapada tahapan construction. Mulai saat iniclass diagrampada tahapan ini akan disebut sebagaiconceptual model.Conceptual model tidak boleh berhubungan dengan perancangan (design), seperti : database, daemon process, form, trigger, event, dsb.If the customer doesnt understand the concept, it probably isnt concept at all.Finding ConceptSalah satucaraterbaikuntukmenemukankonsepadalah denganmelakukanhal yangsamapada saatmencariuse case, yaitu workshop dan brainstorming.Cara lainadalah denganmencarikonsepmelaluidokumenkebutuhan (requirement). Beberapakandidatkonsepyang mungkin dapat diambil darirequirementadalah : Objek fisik atau nyata. Tempat Transaksi Tugas (pelanggan, sales, dll) Containeruntuk konsep lain. Sistem lain (eksternal) Kata benda abstrak Organisasi Kejadian Aturan CatatanCara keduauntuk mencari konsep dari dokumenrequirementadalah denganmencarikata bendadi dalam dokumen tersebut. Meskipun cara untuk mencari konsep dari dokumenrequirement ini cukup sering dipakai, tetapi input dari pelanggan adalahpenting!.Conceptual ModelAda2 komponendi dalamconceptual Model, yaitu :Concept BoxdanAssociation.1. Concept Box

Gambar 5 Concept Box (Similar to Class)Conceptditampilkan pada sebuah kotak sederhana denganjuduldari konsep (dalam huruf besar secara konvensi) pada baristeratas kotak. Di dalam kotak yang besar terdapat 2 kotak yang lebih kecil.Kotak pertama(yang berada di tengah) digunakan untukatributdari konsep.Kotak kedua(yang berada di bawah) digunakan untukkelakuandari konsep.NB :Padaconceptual modelkelakuantidak diisi (belum didefinisikan).Kelakuanbaru didefinisikan padatahapan constructionsaat membuatclass diagram.Finding AttributeHal yangseringkalidipermasalahkan adalah apakah sebuahatributseharusnya adalahkonsep? Sebuahsaranyang cukup baik untukmasalahini adalah :jika ragu,jadikanlahatribut tersebut sebagaikonsep, waktu akan menyelesaikannya nanti.Adabeberapahal yang dapatmembantuuntuk menentukan atribut : Nilai tunggal(string atau angka) biasanya adalah atribut Jika sebuah property dari konseptidak dapat melakukan apapun, kemungkinan ia adalah atribut.1. AssociationAsosiasi berfungsi untukmendeskripsikanbagaimana 2 buahkonsepberhubungan. Di dalam setiap hubungan tersebut ada yang disebut sebagaikardinalitas. Kardinalitas memberitahu berapabanyakinstansyangdiijinkanuntuksetiapkonsep.

Gambar 6 Contoh KardinalitasNotasi* berartibanyak. Ada sedikitperbedaanpada * dan 1..*. Yang pertamamengartikanbanyak secarakabur,mungkinbanyakkonsepyangdiijinkanataupunbelumdibuat keputusan yangpantas. Yang terakhirmengartikanbanyak yang lebihkonkret, satu atau lebih dari satudiijinkan.Untuksetiapasosiasi yang telahdibuat, diberikannamadi atas garis (yang menyatakan asosiasi tersebut). Nama tersebut sesuai denganartidarirelasitersebut.Building the complete modelSetelahsesi brainstorming selesai, akan didapatsekumpulanconceptdenganatribut. Untukmenemukanrelasiantara 2 konsep hal terbaik adalah denganmenanyakanapakah kedua konsep tersebut salingberhubunganatau tidak.Kesalahanyang mungkin terjadi pada tahap ini biasanya adalah : Pemutusanbahwa 2 konsep berhubungan Pembuatangaris diagram dantidakadanama yang diberikanSaatmembangun modeladalahpentinguntukmengingatbahwa asosiasitidak lebih pentingdaripada atribut. Setiap asosiasi yangkurangdapatdenganmudahditambahkan kemudian, tetapi adalahjauhlebihsusahuntukmencariatributyang hilang.Pada akhirnya, sebuah diagramharus masuk akalketika pelanggan membaca kembali diagram tersebut dalamkalimat biasa.1. TahapanConstructionPadatahapanconstruction,produk dibangun, sistem dibawa pada keadaan dimana ia siap diantarkan kepada komunitas pengguna.Strategipada tahapan ini adalah sekumpulan proseswaterfallpendek, dengansekumpulan keciluse caseyang dikembangkan pada setiap iterasi. Secara ideal, pada akhir iterasi diharapkan sebuah sistem yang dapat berjalan meski terbatas.Setiap tahapan iterasiwaterfallakan memiliki sekumpulan dokumen UML : Pada analisis, akan dihasilkan beberapause case(yang penuh ataupun diperluas) Pada perancangan, akan dihasilkanclass diagram,interaction models, danstate diagrams. Pada pengkodean, akan dihasilkan kode yang telah diuji dan dijalankan.Fase AnalisisPadatahapanini, meski telah berada tahapanconstruction, akan tetapi kitamasihberada padatahapan analisis. Yang harus kita perhatikanbukanlahsolusi,melainkanmasalah.Tujuan utamadari fase ini adalahmemahami masalahdengan lebih mendalam.Short use caseyang telah dibuat padatahapanelaborationakandikembangkankembali di tahapan ini untuk diberikandetilsecara penuh.

Gambar 7 Use Case Description TemplatePadabagian ini,short use casetelahmemberikan detilterhadapbagian use case dan short description (serta dengan tambahan actor dan requirement jika diperlukan).5 bagian lainbelum diisi. Berikut adalah keterangan untuk kelima bagian tersebut. Pre-ConditionsBagian inimenjelaskankondisiyangharus dipenuhisebelumuse casedapat berjalan. Bagianpre conditionsharusbukan sebuah proses yang termasuk di dalamuse case. Contoh : jika ada sebuahpre condition: usertelah berhasil login, artinyaproses validasiusertidak termasuk di dalamuse casetersebut. Post-ConditionsBagian inimenjelaskankondisisistem pada akhiruse case.Harus ada prosesdi dalamuse caseyangmemberikanhasil ini. Kondisi akhir inidapat menggunakansyarat perbandingan if-then(jika maka). The Use Case FlowAda 3Flowutamadari use case,Flowdimulaidarimain flowdanberpindahkeflowlainjika diperlukan.Perpindahankealternate flowditandaidengan [An]dengann adalahnomor urutAlternateFlow.Perpindahankeexceptionflowditandai dengan[En] dengan n adalahnomor urutExceptionFlow.

Gambar 8Full Use Case DescriptionBerikut adalahpenjelasan aliranprosespada sebuahUse Case: Main FlowAliran inimenjelaskan prosesuse casejikatidak terjadihal hal di luar dugaan. Pada aliran proses ini,userdianggap memberikanmasukan(input)sesuaidenganharapan(kondisi ideal).Interaksiantara user dengan sistem dijelaskan secara mendetil disini.Kondisi akhirdarimain flowadalah post condition. Alternate Flow(s)Alternate flowadalahaliran prosesyang akandijalankan(dibangkitkan) jikaterjadihal hal di luar dugaanpadamain flow. Padaalternate flow,mungkinterjadi perubahanpost condition.Perubahan padapost condition, ditandai dengan :Post Conditions(Post Condition baru). Exception Flow(s)Exception Flowadalahaliran prosesyang akan dijalankan (dibangkitkan) jikaterjadihal hal yangtidak diinginkanataupun hal hal yangtidak didugasebelumnya. Padakodeprogram, bagian ini dipetakan ke bagianpenangananexception(seperti pada C++, Java, Ada, Delphi, dan bahasa pemrograman lainnya). Biasanya akanmengakhiri prosesuse caseseketika.Pada saat menulis proses dari aliran proses sebuahuse case,seringkaliterjadipencampuranantara analisis dan perancangan (disain).Contohnya: di dalam aliran proses seringkali disebutkan bagaimana sistem mengakses dan memodifikasi database, pemindahan data data di dalam sebuah array, dsb (yangseharusnyatidak boleh). Hal ini mungkin terjadi akibatsulitnya menemukankata kata yang tepat untukmenggambarkankeadaanyang diinginkan oleh pengembang saat menuliskan aliran proses. Untuk menanggulangi masalah ini dapat digunakansequence diagramuntuk membantu(bukanmenggantikan) menjelaskan aliran proses dariuse case..Sequence diagramdapatdipergunakan padatahapananalisis maupun perancangan (disain). Untuk tahap analisis,sistemdianggapsebagaisebuah kotak hitam (black box).Sequence Diagramdapat dipergunakanhanyauntukmain flow,tidak perlumenggambarkansequence diagramuntukalternate flowdanexception flowkecuali jika benar benar kompleks atau menarik. Ada4 komponendari sequence diagram yang akan dipergunakan pada tahapan analisis : Actor

Gambar 9 ActorActorberada pada sisi kiri dari diagram. Nama dariactorberada di bagian bawah dari gambaractor. System Box

Gambar 10 System BoxSystem boxberada pada sisi kanan dari diagram.Keseluruhansistemdirepresentasikan sebagai sebuah kotak dan diberi nama sistem (ataupun nama dari sistem). Timelines

Gambar 11 TimelineSebuah garis lurus vertikal ditambahkandi bawahactordansystemboxuntukmenggambarkanaliranwaktu. Interactions

Gambar 12 InteractionInteraksiantarauserdengan sistemdigambarkandengan garis dan panahantarauserdengan sistem.Kotakyang tergambar digaristimelinemenyatakanwaktuyangdihabiskanolehsatu sekuendari proses. Nama dari interaksi yang terjadi di tulis diatas garis dan mendeskripsikan jenis interaksi yang terjadi.Berikut adalah contoh dari sequence diagram :

Gambar 13 Contoh Sequence DiagramFase PerancanganPada fase iniseharusnyapermasalahan telah dapat dimengerti sepenuhnya (untuk iterasi ini). Perancangan akanmemulaipembuatan solusi untuk masalah. Pada tahapan ini ada3 halyang harus diperhatikan : Objek apa sajayang diperlukan oleh sistem Objek yang manayang bertanggung jawab untuk memenuhi kebutuhan WaktuuntukobjekberinteraksiUntuk menggambarkan interaksi antar objek, digunakanInteraksi diagram. Interaksi diagramterdiriatas2 jenisdiagram yangsalingberelasi, yaitu :sequencediagramdancollaborationdiagram. Setelah objek objek yang diperlukan telah dimiliki, sebuahclassdiagramdipergunakan untukmenangkap informasibagaimana kelas kelassaling berelasi. Akhirnya, sebuahmodel laindipergunakan untuk memberikanpenjelasantentangstatedarisetiap objekyang disebut denganstate diagramataustate model.Karena pada tahapan ini telah memulaipembuatan solusimaka pada tahapan ini akanmulai dibicarakantentang pemrograman (pseudo-code,code), basisdata, struktur data, dan berbagai hal lain yangberhubungandenganperangkat lunak.Pada fase perancangan ini, ada 3 tipe model yang akan dihasilkan :interaction diagram, class diagram,danstate diagram.Interaction DiagramCollaboration DiagramUse caseyang telah didapatkan padatahapan sebelumnya,tugasnyaakandijelaskandenganmenggunakankolaborasi dari objek yang berbeda.Collaboration Diagramdipergunakan untukmenjelaskankolaborasidariobjek objekyang ada untukmemenuhisebuahuse case.Collaboration Diagrammemilikisintaksberikut : ClassKelas di dalamcollaboration diagrammemiliki notasi seperti berikut :

Gambar 14 Notasi Kelas ObjekAda2 jenisobjekyang dimodelkan dicollaborationdiagram, yaitu : objek biasa(instan dari sebuah kelas) dan objekdenganpenamaan(nama dari objek) atau objek bernama.

Gambar 15 Notasi Objek Biasa

Gambar 16 Notasi Objek BernamaDi dalamcollaboration diagramkumpulan (stack) objek dimodelkan dengan notasi berikut :

Gambar 17 Notasi Kumpulan (Stack) Objek ObjekCommunicationUntukmenggambarkankomunikasiantar 2 objek, dinotasikan sebagai berikut : Gambar 18 Notasi Komunikasi Objek Message Passing and NumberingAntara 2 objek yangberkomunikasi, komunikasi tersebut terjadi denganmelakukanpertukaran pesan(message passing). Ada3 jenis pesanyang dapat dikirimkan ketika 2 objekberkomunikasi, yaitu : pesan biasa, pesan dengan parameter, pesan dengan nilai kembalian.

Gambar 19 Notasi Pesan Biasa

Gambar 20 Notasi Pesan dengan Parameter

Gambar 21 Notasi Pesan dengan nilai kembalianAngkayang beradadisampingpesanyang dikirimkanmenyatakanurutanpesan tersebutdieksekusiuntukmemenuhiuse case. Setiappenambahanpesan,nilaidi samping pesan akandinaikkan1 (increment). LoopingUntukmenggambarkanterjadinyaloop, dipergunakan notasi berikut :

Gambar 22 Notasi Looping (Perulangan)Tanda asterisk(*) pada pesan (message)menandakanbahwapesantersebutdiulang. Creating new objectUntukmembuat objekbaru, dipergunakan notasi berikut :

Gambar 23 Notasi Create ObjekMeskipun notasi inimemiliki sedikit keanehan, pesan dikirimkan kepada objek yang bahkan belum ada (belum di-create).Berikut adalahcontohdari sebuahcollaboration diagram:

Gambar 24 ContohCollaboration DiagramDarimanakah objek objek yang dipergunakan di dalamcollaboration diagramdi atas berasal?Beberapa objek di atas adalah objek baru yang belum pernah dilihat, akan tetapi kebanyakan objek yang berada di dalamcollaboration diagramadalah objek yang berasal dariconceptual modelyang telah dibuat pada tahapelaboration.Terkadang pada saat membuatcollaboration diagramakan disadari bahwa adaassociationyang belum ditemukan (dibuat) pada tahap pembuatanconceptual model. Hal ini terkadang dapat mengganggu kebutuhan (requirement) dari pelanggan. Jika hal ini terjadi,tanyakan pada pelanggan terlebih dahulu.Dengan membuatcollaboration diagram,codeyang akan diimplementasikan menjadi sistem tidak terpetakan dengan baik. Ada beberapa masalah yang belum terselesaikan melaluicollaboration diagram, yaitu : Inputdanoutput(interface) antara user dengan sistem belum terdefinisi Basis datadanjaringanbelum terdefinisi disini Keputusanyang dibuat mengenai sebuahkelasbelum terdefinisi dengan jelas.Di dalam membuatcollaboration diagramada 4 hal yang harus dicatat : Buat diagram sesederhana mungkin. Jika sebuah diagram menjadi sangat kompleks, cobalah untuk membuat diagram terpisah untuk setiap interaksi dengan user. Jangan berusaha untuk menjelaskan setiap scenario yangmungkinada.Alternativeflowadalah sesuatu yang jarang terjadi, tidak perlu disertakan di dalam diagram. Jangan membuat kelas dengan namacontroller,handler,manager,ataudriver. Hal ini membuat desain menjadi tidakberorientasi objekmelainkanberorientasi aksi(action oriented). Hindarikelas dewa. Kelas dewa adalah sebuah kelas yang mengerjakan berbagai hal dantidak banyakberkolaborasi dengan objek lain. Sebuah solusiOOyang baik adalah kelas kelas kecil yang saling bekerja sama untuk mencapai tujuannya.Sequence DiagramSequence Diagrammemberikan informasi yang sama denganCollaboration Diagram. PembuatanSequence Diagrampada tahapan ini sama dengansequence diagrampadatahapan analisisyang dipergunakan saat menjelaskanaliran prosesuse case. Perbedaannya adalah pada bagian ini, sistem diperluas dengan objek objek yang sama seperti padacollaboration diagram. (NB :Hanyaberbeda susunan bukanurutan, ditambah dengan penambahantimelineuntuk mempermudah pembacaan diagram).Class DiagramClass Diagramyang dipergunakan disini memiliki notasi yang sama denganconceptual modelpadatahapan elaboration. Perbedaanclass diagrampada tahapan ini denganconceptual model(class diagrampadatahapan elaboration) adalah padaconceptual modeltidak ada deskripsi kelakuan(fungsidanprosedur) di dalamnya, semuanya hanya berpusat pada masalah pelanggan.Conceptual Modelyang telah dibuat sebelumnya akan dikembangkan lebih lanjut pada tahapan ini untuk menjadidesign class diagramyang sebenarnya. Dengan kata lain, sebuah diagram dimana dapat di-kode-kan.Pembuatanclass diagramdidasarkan padaconceptualmodeldancollaborationdiagram.Perubahan ini cukup terstruktur dan mekanis, perubahan iniharusnyatidak terlalu susah.langkah langkahpembuatannya adalah sebagai berikut : Penambahanoperasi(kelakuan) Penambahannavigasipesan(navigability) Perbaikanatribut PemutusanVisibilitas PembuatanagregasiNB : Jika agregasi sudah ditemukan padatahapanconceptual model, boleh ditambahkan. PembuatankomposisiNB : Jika komposisi sudah ditemukan padatahapanconceptual model, boleh ditambahkan.NB : praktisi berpedapat bahwaagregasi dan komposisibukanlah suatu hal yang baik. Relasi ini bersifatredundan(berulang ulang) danharus dihilangkan. Meskipun begitu, agregasi tetaplah sebuah konsepOO. Ia tetaplegaluntuk dipergunakan. Agregasi dan komposisidapatdimodelkansebagai sebuahasosiasidengan nama is composed from.State DiagramStateDiagramberfungsi untuk memodelkankeadaan keadaanyang mungkin dimiliki olehsebuah objek. Model ini memungkinkan untuk menangkap kejadian kejadian (event) yang penting dan efeknya setelah kejadian (event) tersebut.Sintaks dari diagram ini adalah sebagai berikut : Start stateStart Stateini menggambarkan keadaan objek diawal pembuatannya.

Gambar 25 Notasi Start End stateEnd Stateini menggambarkan keadaan objekdihancurkan.

Gambar 26 Notasi End State DescriberState describerdipergunakan untukmenuliskankeadaandari objek.

Gambar 27 State Describer State TransitionSebuah eventdapatmenyebabkan sebuah objekberubah stateatautetap pada state-nya.Perubahan(transition) dari sebuahstatekestatelainnyadiakibatkanoleh sebuah event digambarkan olehstate transition.Eventyang menyebabkan perubahan tersebut dituliskan di atas garis panah.Stateyang dihasilkan digambarkan di kotakevent describer.

Gambar 28 State Transition Sub/Superstate (Nesting States)Terkadang diperlukanpenggambaran statedi dalam sebuah state. Sebuah state yang lebih umum dipergunakan untuk menggambarkan komponen komponen state yang lebih kecil. State yang lebihumumdisebutsuperstate. State yang lebihkhusus(bagian darisuperstate) disebutsubstate.

Gambar 29 Nesting StateTerkadang sebuahsuperstatedapat mengalamiinterupsi. Adalah memungkinkanuntukmenggambarkan keadaan dimanasaatsebuahsuperstatemelanjutkanstate-nya akandimulaidari saatstateterakhirsebelum diinterupsi.Superstateyang seperti itudisebuthistory state. Notasinya adalahhurufH di dalamlingkaran.

Gambar 30 History State Entry/Exit EventDi dalam sebuahstatedapat ditambahkan keterangan mengenai keadaan awal dan akhir dari state. Keadaan awal (disebutentry) menggambarkankeadaanyang diperlukan ketika sebuahstateberubah(bertransisi) menjadistateyangmemilikiketeranganentry. Keadaan akhir (disebutexit) menggambarkankeadaanyang dimiliki olehstateketikastateberakhir.

Gambar 31 Entry/Exit EventUntuk menggambarkan keadaan dimana sebuah state harusmengirimkanpesanke objek lain, dipergunakan notasi seperti berikut :^object.method (parameters)

Gambar 32 Entry berparameter Guarduntuk menggambarkan bahwa sebuahkondisiharusdipenuhisupaya terjadistate transition(bukansupayastate transitionberhasil seperti padaentry event).

Gambar 33 GuardContoh dari state diagram :

Gambar 34 Contoh State DiagramBagian ini dipergunakan pada tahapan construction (desain) untuk dapat melakukan sebuah perancangan yang BAIK.Konsep OOPatternSebuahpatternadalah sebuahsolusiyangdipergunakandenganbaikdan sangatumumuntukmasalah masalahyang cukup seringterjadi. Ada banyakpatternyang dapat dikenal oleh seorang perancang.Patternyang akan dibahas pada bagian ini disebutGRASP (General Responsibility Assignment Software Patterns). GRASPmembantu untuk menentukankelakuandari setiapkelasdengancarayang palingeleganyangdimungkinkan.Pola(Pattern) tersebut dinamakan :Expert, Creator, High Cohersion, Low Coupling,danController.Penggunaandari kelima polaGRASPakan membuatperancanganOOmenjadi lebihdapat dimengerti,mudah diubah, dankokoh(robust).ExpertIni adalah sebuahpolayang sangatsederhananamun juga seringkalidilanggar. Pola ini harus yang palingutamaada di dalampikiranseorang perancang saatmembangundiagram kolaborasi ataumerancangclass diagram.Pola ini membantualokasikelakuan (behavior) ke dalam kelas. Alokasi yangbaikdari sebuah kelakuan memiliki nilai : Mudah dimengerti Dapat di-extendsecara mudah Dapat dipergunakan kembali (reusable) Lebih kokoh (robust)Pola ini memiliki aturan : Hanya kelas yangexpertterhadap suatubehaviorsaja baru bolehmemilikibehaviortersebut.CreatorPolaini adalah penggunaanspesifikdariExpert Pattern. Pola ini menjawab pertanyaan : Kelas manakah yang harusbertanggung jawabuntukpembuatan instansdari suatu kelas tertentu..KelasA harus bertanggung jawab untukpembuatankelas B, jika : Amengandung objekB Amenggunakan objekBsecara dekat Amemiliki inisialisasi data yang akan digunakan olehBHigh CohesionSebuahperancanganOOyangbaikmemiliki tandasetiap kelashanya memilikisejumlah kecilmethod. Merupakan hal yangsangat pentinguntuk memastikan bahwa setiap kelas memilikitanggung jawabyang terfokus.Aturan utamadaripembangunansebuah kelas adalah setiapkelas harus memilikihanyasatukunciabstraksi(menggambarkan sebuah benda dari dunia nyata)Low CouplingCouplingadalah sebuah ukuran untuk menentukan seberapatergantungnyasebuah kelasterhadapkelas lain.Couplingyang tinggi dapat menyebabkancodeyang sulit diubah atau dirawat sebuah perubahan kecil dapat menyebabkanombakperubahan terhadap sistem.Untuk mengurangicouplingsalah satu cara terbaik adalah denganmengikutimodelconceptual. Pesan yang dikirimkan hanya jika ada asosiasi yang telah didefinisikan padatahapanconceptual modeling.Aturan utamadisini adalah : Jagacouplingseminimum mungkin conceptual modeladalah sumber yang sempurna sebagai ukuran mengenai jumlahcouplingminimum. Menaikkanleveldaricouplingbukanlahsebuah masalahjika telah dipikirkan dengan baikkonsekuensinya!The Law of DemeterHukum ini, dikenal juga sebagai : Dont Talk to Strangers, adalah sebuah metode yang efektif untuk memerangicoupling. Hukum ini menyatakan bahwa setiap objek hanya boleh memanggilmethodyang dimiliki oleh : Dirinya sendiri Parameter yang dikirimkan kepadamethod Setiap objek yang dibentuk Setiap yang memegang objek secara langsung.Beberapahal yang harus dipertimbangkan mengenaicoupling: Jangan pernahmembuat atribut dari kelas bersifatpublic. SEbuah atributpublicmembuka kesempatan penyalahgunaan sebuah kelas (pengecualianhanya diberikan kepadaconstantsdari kelas). Berikangetdansethanya pada saat diperlukan. Berikanantarmukapublicyang paling minimum. Janganbiarkan data mengalir di dalam sistem (minimalisasipemindahan data). Janganhanyamempertimbangkancoupling IngatmengenaiHigh cohesiondanexpert! Sebuah kelas yang tidak memilikicouplingsama sekali akan memiliki kelas yangmengambangdanmemilikiterlalu banyakpekerjaan. Biasanya berakhir dengan sistem yangmemilikisedikit objek aktif yangtidak berkomunikasi.ControllerSecara umumpenambahaninformasimengenai GUI (Graphical User Interface), basis data, atau objek fisik lainnyake dalamkelas merupakansebuahperancangan yang buruk. Kelas kelas dariconceptual modeladalah kelas bisnis yang harus dibiarkan tetapmurni(tanpa GUI,database,dll). Untukmenghubungkankelas bisnis danactordiperkenalkansebuahkelas baru yang dinamakancontroller. Nama daricontrollermemilikikonvensisebagai berikut : Handler.InheritanceSeringkali di dalam perancangan, beberapa kelasmemilikikarakteristikyangsama.Karakteristikyangsamaini dapatdigabungkanke dalam sebuah kelas (untukmengurangipengulangan/redundan kode). Kelas ini kemudian dapat di-waris-kan (inherit) kekelaslain yang lebihkhususdanmenambahkanatributsertamethodkepada kelas yang lebih khusus tersebut.

Gambar 35 dua kelas dengan karakteristik mirip

Gambar 36 Penggunaan InheritanceProsespengelompokankarakteristiksebuah kelas yang sama daribeberapakelaske dalam sebuahkelasyang lebihumumdisebut prosesgeneralisasi.Kelas yang lebih umum disebutbase class(atausuperclass). Kelas yang lebih khusus disebutderived class(atausubclass). Sebuah base class dapat diturunkan (inherit) ke base class lain yang lebih khusus.Permasalahanyang seringkali muncul berhubungan denganinheritanceadalahpenggunaaninheritancesecara berlebihan. Hal inidapatmenimbulkan permasalahan padaperawatan. Hal ini disebabkan kelas turunan (derived class)memilikicouplingyang sangat erat terhadap kelas basis (base class).Perubahanpada kelasbasisakan menyebabkanperubahanpada kelasturunan.Penggunaan kelas turunanmewajibkanperancang untukmengetahuikemampuandari kelasbasis. Hal ini berarti harus diadakan eksplorasi terhadap hierarki kelas yang besar. Masalah ini dikenal juga dengan namaproliferation of classes. Hal ini disebabkan karenainheritancedipergunakan ketika ia tidak seharusnya dipergunakan.Aturanutama di dalam penggunaaninheritanceadalah : Gunakaninheritancehanya sebagai alat (mekanisme)generalisasi tidak selalu harus menggunakaninheritance.Dalam melakukaninheritanceada2aturanyang harus diikuti, yaitu : aturan is a kind dan aturan 100 %.Aturan100 %Aturanini berisi : Semuadefinisi yangdimilikioleh kelasbasisharusdiaplikasikansecarapenuholeh kelasturunan.Pengabaianterhadap aturan ini dapatmenyebabkan masalahterhadap perawatan.SubstitutabilitySebuahmethodtidak dapat dihapus di dalam hierarkiinheritance.Aturanis a kindAturan ini berfungsi untuk melakukan pengujian apakah hierarkiinheritanceyang dimilikivalid. Aturan ini mengatakan bahwa sebuah frase dengan format : is a harus masuk akal.Aggregation vs InheritanceJika sebuah kelas sepertinyadapat diturunkandari sebuah kelas lain (base class) tetapi tidak memenuhi aturan100%dan aturanis-a-kindmaka cobalahmempertimbangkanagregasi untuk menggantikaninheritanceyanghendakdilakukan.Permasalahan dengan InheritanceMeskipuninheritanceterlihat seperti sebuah alat yangpowerfuluntuk memaksimalkankonsepreuse, Ia harus dipergunakan dengan hati hati.Inheritancedapat menyebabkan hierarki kelas yang kompleks dan sulit dimengerti (profileration of classes). Karenanya pergunakanlahinheritancedengan hati hati dan yakinkan aturan100%danis-a-kindditerapkan dengan baik.Sebagai tambahan,Inheritanceadalahwhite-box-reuse. Enkapsulasi antara kelasbasisdan kelasturunancukup lemah secaraumum,perubahan terhadap kelasbasisdapatmenyebabkanperubahan kelasturunanmanapun. Hal ini menyebabkanpenggunakelas harusmengetahuihubungan antaraparent class(superclass,kelas basis) dengan kelas yang sedang dikerjakan (child class, subclass,kelas turunan).Protected VisibilityAtribut dalam setiap kelas memilikikarakteristikvisibility. Secaradefault,visibilitydari sebuah atribut pada kelas adalahprivate. Hal ini berarti apapun (kelas manapun) selain dari kelas yangmemilikiatribut tersebuttidak dapatmelihat nilai dari atribut tersebut.Visibilitydengan nilaipublicartinya apapun (kelas manapun) dapat melihat nilai dari atribut tersebut. OO menyediakan suatuVisibilityatribut dengan nilaiprotected, yang artinyakelas turunandari kelas tersebut dapatmelihatnilai dariatribut-nyatetapikelas lain tidak.Penggambaranprotected visibilitydigambarkan dengantandapagar(#) di samping atribut yang bersifatprotected.

Gambar 37 Protected VisibilityPolymorphismKelas turunan dapat mendefinisikan kembali implementasi darimethod. Hal ini biasanya disebabkan karena dua buah kelas turunan yang memilikimethodturunan dari sebuah kelas basis melakukan implementasi yang berbeda terhadap method tersebut.

Gambar 38 PolymorphismThe principle of substitutabilityberhubunganerat denganpolymorphism. Prinsip ini mengatakan bahwa jikamethodyang adadiharapkandapat bekerja pada sebuahkelas tertentu, ia dapatbekerjadenganbaikpadakelas turunannyayang manapun.Prinsipini tidak mengijinkan kelas turunanuntuk menghapusmethod darisuperclass-nya. Hal ini supaya tidak terjadi kesalahan akibat keteledoran di dalam penggunaan kelas.Contoh kasus :

Methodaccelerate di atas bekerja dengan menggunakan parameter dengan tipe Transport, dan melakukan percepatan dengan menggunakanmethodmove().Methodini dapat dipanggil dengan aman dan memberikan sebuah objek Car kepadanya (karena Car adalahsubclassdari Transport) ataupun sebuah objek Boat.Jika suatu saat nanti, ada sebuah kelas turunan baru dari Transport dengan nama Aeroplane, kelas Aeroplane ini dapat diterima dengan baik tanpa modifikasi terhadapmethodAccelerate!Oleh karena alasan inilah sebuah kelas turunantidak dapatmenghapusmethoddarisuperclass-nya. Jika diijinkan, mungkin sajakelas turunanAeroplane dapatmenghapusmethodmove() dan semuakelebihan yang didapatdiatas menjadihilang.Abstract ClassesSeringkali di dalam perancangan, diperlukan untukmeninggalkansebuah method tanpa di-implementasikandan membiarkan implementasidilakukanoleh kelas yang berada di bagianbawahpohon hierarki inheritance.Notasi penulisanmethoddengan sifat seperti itu dilakukan denganmemiringkan(italic) nama dari method dan kelas. Kelas yang memilikimethodseperti itudisebutabstract class. Notasi lain yang dipergunakan untuk menggambarkanabstract classadalah dengan menambahkan di bawah nama kelas. Notasi ini diperkenalkan karena seringkalihuruf miring(italic) sulit untuk dikenali pada sebuah diagram kelas. Pemberian atribut tambahan disebutstereotyping( adalahstereotype).

Gambar 39 Abstract Class

Gambar 40 Abstract Class (Stereotype)System ArchitechtureAdabeberapa masalahyang dihadapi oleh pengembang perangkat lunak ketika menghadapipengembangan sistemyangbersifat besardanlebih kompleks. Untuk menjawab permasalahan itu, UML memberikan beberapa tools yang dapat berguna di dalam pengembangan.Package DiagramSemuaartefakUMLdapat disusun ke dalam UML Packages.Packagesecara mendasar adalah sebuahkontainerlogikauntuk elemen elemen yang salingberhubungan. Sebuahpackagedapat berisipackagelain sehingga pada akhirnya akan membentuk hierarki.Di dalam UML, dapat juga digambarkan sekumpulanpackagesdimana ada hubungan beberapapackagetersebut.Gambar 41 Relasi antar packageContoh di atas adalah model klasik dari three tier model di dalam pengembangan perangkat lunak. Benda yang berada di dalampackagePresentation bergantung pada benda yang berada di dalampackageBusiness.Meskipunsemuaartefak UML dapat ditaruh di dalampackage, penggunaanpackageyang paling umum adalah untuk menaruhsekelompokkelas yangsalingberhubungan. Penamaan kelas dari setiappackageharusunik. Namun penamaan kelas daripackageyangberbedatidak bermasalahmeskipunmemiliki nama kelas yangsama.Keuntungandari melakukanpackagingadalah : Pengelompokansistem yang besar ke dalam subsistem yang lebih mudahdikelola. Memungkinkaniterativepengembangan secaraparallel.Keuntungan lain daripackagingadalah jika desain dari sebuahpackagedilakukandenganbaikdanpackagetersebutmemilikiantarmuka yang jelas untukdigunakanantarpackage, konsepcode reusedapat dimaksimalkan.Class reuse(penggunaan ulang kelas) adalah sesuatu yang sulit untuk dilakukan dikarenakankelasmemiliki jangkauan yang sempit dan sulit untuk digunakan kembali (dengan kata lainabstraksi kelasrendah). Berbeda denganpackage, denganperancanganyangbaiksebuahpackagedapat menjadisoliddan menjadi sebuah komponen perangkat lunak yangdapat digunakan kembali(memilikiabstraksiyang tinggi).Ada3 halheuristikdariGRASPyang dapat diaplikasikan kepadapackaging: Expert:packagemanakah sebuah kelas harus ditaruh? High Cohesion: sebuahpackagetidak boleh melakukan terlalu banyak hal Loose Coupling: ketergantungan antarpackageharusseminimalmungkin.Package CommunicationKomunikasi antara 2packagedapat dilakukan sesuai dengan polafaade(faade pattern). Pola ini memberikansebuahkelas diantara 2 buahpackageyang hendak berkomunikasi, sehingga keduapackageyang akan berkomunikasiharusmelalui kelas ini (yang disebutkelasfaade).

Gambar 42 Komunikasi tanpa kelasfacade

Gambar 43 Komunikasi dengan kelasfacadeArchitechture Centric DevelopmentProses pembangunanperangkat lunakRUP(Rational Unified Process)menyarankankonsep pengembangan denganarsitektur terpusat. Dengan kata lain, sistemdirancangsebagaikumpulandarisubsistemmulai dari tahapan yang sangatawaldaripengembangan.Dengan membuat sekumpulan kecil subsistem yang mudah dikelola, sebuah tim pengembang yang terdiri dari 3 4 orang dapat dialokasikan terhadap setiap subsistem.Subsistemtersebut dapat dikerjakanparalleltanpa bergantung satu sama lain.Timarchitectureakan melakukan pengelolaan terhadap antarmuka (faade) di antara subsistem. Meskipun pada saat pengembangan proyek nanti diperlukanperubahanpadafaade, yang akan melakukanmodifikasiadalah timarchitecturalbukan tim pengembang yangbekerjapadasubsistem individual.Dikarenakan timarchitecturemengelola pandangan tingkat tinggi dari sistem, mereka harusmemahamiakibat darimodifikasiantarinterfaceyangdimilikiolehsubsistem.Menangani Use Case BesarSalah satu permasalahan yang muncul dari pengembangan dengan skala besar adalahuse caseyang pertama sekalidibuatbiasanyaterlampaubesar untuk dikembangkan dalam satu kali iterasi. Solusi yang diberikanbukanlahmembuatmasaiterasi lebihpanjang, melainkan memecahuse casemenjadi sekumpulanversiyang lebihkecildan mudah di-kelola.Untuk setiap iterasi, tim terpisah dapat mengerjakan subsistem terpisah secara paralel. Pada akhir dari iterasi, tahapan integrasi akan dilakukan, dan pengujian terhadap antarmuka subsistem akan dilakukan.Kesimpulan:Rational Corp memberikan sebuah pendekatan terbaik untuk pendekatan secara arsitektur terpusat (architecture centric approach), yaitu : Definisikan subsistem daritahap awal Jagakompleksitas supaya tetap dapat diatur Iterasi secara parallel tetapijangan hackinterface TunjuksebuahtimarsitekturalFase PengkodeanSalah satu masalah kunci dari perancangan dan koding adalah untukmenjagamodel tetapkonsistendengan kode. Untuk melakukan hal ini, salah satu pendekatan yang dapatdilakukanadalah dengan menambahkan sebuahtahapan tambahanpada iterasi, yaitu tahapan sinkronisasi. Tahapan ini berfungsi untuk melakukan sinkronisasi artefak. Disini modeldiubahuntukmenggambarkankeputusan perancangan yang telah dibuat saatmelakukankoding di iterasisebelumnya.

Gambar 44 Tahapan perancanganPemetaanperancangan ke kode[Class Diagram] Class to CodeDefinisi kelasyang dikodekan akanditurunkandarikelas diagram perancangan.Definisimethodakan berasal daricollaboration diagram, bantuan lainnya berasal dariuse case description(detil tambahan, khususnya padaexception/alternate flows)danstate chart(menangkapkondisierror).Pemetaan 1 : Class ModelClass

Gambar 45 Class Model

Gambar 46 Class CodeLangkah Pemetaan: Tambahkan constructor untuk setiap kelas yang dibuat Petakan atribut danmethodyang ada di dalamclass diagramPemetaan 2 : Contain Relationship

Gambar 47 Contain Relationship

Gambar 48 CodePemetaan 3 : PendefinisianMethod

Gambar 49 Method (Message Passing)

Gambar 50 Code Method

Gambar 51 Code Method[Package] Package to CodeJavaJavamemilikidukungan langsungterhadappackage. Baris pertama darideklarasikelaspada java harusmengatakanpadaJavadipackagemanakahkelas tersebutberada. (Jika tidak ada, Java akan menganggap kelas berada padapackagedefault).Java juga memiliki fiturpackage protection. Kelas (bersama denganmethoddan atributnya) hanya dapat dilihat oleh kelas yang berada padapackageyang sama. Ini memberikan dukungan yang sempurna untuk enkapsulasi di dalampackage. Dengan membuat semua kelas hanya dapat dilihat oleh kelas di dalam satupackage(kecuali kelasfaade), subsistem (ataupackage) dapat dikembangkan secara bebas (independent). Meskipun sintaks yang dimiliki java untuk fitur ini tidak terlalu baik, yaitu hanya melakukandeklarasikelas tanpa kata kuncipublic, protected,atauprivatedi depan kata kunci kelas.C++

C++ti dakmemiliki dukungan langsung terhadappackage, tetapi C++memilikikonsep yang disebut sebagainamespace. Ini memungkinkan kelas untukditaruhpadapartisi logikaterpisah, untukmenghindaritubrukan nama kelas di antara namespaces.Meski ia memberikan beberapa dukungan daripackages, sayangnya ia tidak memberikanperlindungandarivisibilities. Kelas yang berasal dari sebuahnamespacesdapat mengakses seluruh kelaspublikyangterdapatdinamespaceslain.Component ModelUML menyediakan sebuah notasi yang dapat dipergunakan untuk memodelkan komponen perangkat lunak yang bersifat fisik dan keras (bukan kode, cth : file). Notasi ini menggunakannotasi yang samadenganpackage diagram. Ia memodelkan ketergantungan antara entitas fisik perangkat lunak seperti :executeable file,dynamic link library,object file,source file, dll).

Gambar 52 Notasi UML untuk Component Model1. TahapanTransitionSetelah melewati tahapan construction, maka berakhirlah tugas UML. Setelah mencapai tahapan ini, sebuah sistem yang berjalan sesuai dengan spesifikasi telah didapatkan.Tahaptransitionberkaitan dengan prosedur prosedur yang diperlukan untuk melakukan deliverable dari sistem yang telah dihasilkan.http://eraindrop.wordpress.com/2009/09/23/uml--analisis-perancangan-berorientasi-objek/RelatedAnalisis dan Perancangan Berorientasi ObjekIn "OOP"Analis sistem RPLIn "Kuliah"Makan, Parfum, dan UangRupiahPosted on 29/03/2013 by Dhienzz This entry was posted in OOP. Bookmark the permalink. Hujan jangan kaureda1 Batang korek cukup menghagatkan, tapi akan lebih hangat jika semakin banyak ygmenyalakan.

Analisa dan Perancangan BerbasisObjekObject Oriented analaysisadalah metode analisis yang memeriksarequirements(syarat/keperluan yang harus dipenuhi suatu sistem) dari sudut pandang kelas-kelas dan objek-objek yang ditemui dalam ruang lingkup permasalahan.Object Oriented Designadalah metode untuk mengarahkan arsitektur software yang didasarkan pada manipulasi objek-objek sistem atau subsistem.Konsep Dasar OOAD (Object Oriented Analysis and Design)OOAD mencakup analisis dan desain sebuah sistem dengan pendekatan objek, yaiut analisis berorientasi objek (OOA) dan desain berorientasi objek (OOD). OOA adalah metode analisis yang memerika requirement (syarat/keperluan) yang harus dipenuhi sebuah sistem) dari sudut pandang kelas-kelas dan objek-objek yang ditemui dalam ruang lingkup perusahaan. Sedangkan OOD adalah metode untuk mengarahkan arsitektur software yang didasarkan pada manipulasi objek-objek sistem atau subsistem.Terdapat beberapa konsep dalam OOAD, yaitu :- Objek (object) Objek adalah benda secara fisik dan konseptual yang ada di sekitar kita. Sebuah objek memiliki keadaan sesaat yang disebut state. State dari sebuah objek adalah kondisi dari objek atau himpunan keadaan yang menggambarkan objek tersebut. State dinyatakan dengan nilai dari atribut objeknya. Atribut adalah nilai internal suatu objek yang mencerminkan karakteristik objek, kondisi sesaat, koneksi dengan objek lain dan identitas. Behaviour (perilaku objek) mendefinisikan bagaimana sebuah objek bertindak dan memberi reaksi. Behaviour ditentukan oleh himpunan semua atau beberapa operasi yang dapat dilakukan oleh objek tersebut, yang dicerminkan oleh interface, service, dan method dari objek tersebut. Interface adalah pintu untuk mengakses service dari objek Service adalah fungsi yang dapat dikerjakan oleh sebuah objek Method adalah mekanisme internal objek yang mencerminkan perilaku objek tersebut- Kelas (class)Class adalah himpunan objek yang sejenis yaitu mempunyai sifat (atribut), perilaku umum (operasi), relasi umum dengan objek lain dan semantik umum. Class adalah abstraksi dari objek dalam dunia nyata. Class menetapkan spesifikasi perilaku dan atribut dari objek tersebut.- Kotak Hitam (black boxes)Sebuah objek adalah kotak hitam. Konsep ini menjadi dasar implementasi objek. Dalam operasi OO hanya developer yang dapat memahami detail proses yang ada didalam kotak tersebut, sedangkan user tidak perlu mengetahui apa yang dilakukan yang penting mereka dapat menggunakan objek untuk memproses kebutuhan mereka. Kotak hitam berisi kode dan data. Encapsulation, yaitu proses menyembunyikan detail implementasi sebuah objek. Untuk mengakses data objek tersebut adalah melalui interface. Untuk berkomunikasi dengan objek digunakan message. Message adalah permintaan agar objek menerima untuk membawa metode yang ditunjukkan oleh perilaku dan mengembalikan result dari aksi tersebut kepada objek pengirim (sender)-Asosiasi dan Agregasi Asosiasi adalah hubungan yang mempunyai makna antara sejumlah objek. Asosiasi digambarkan dengan sebuah garis penghubung diantara objeknya. Contohnya : Asosiasi karyawan dengan unit kerja. Setiap karyawan bekerja di satu unit kerja, sedangkan unit kerja dapat memiliki beberapa karyawan. Agregasi adalah bentuk khusus sebuah asosiasi yang menggambarkan seluruh bagian pada suatu objek merupakan bagian dari objek yang lain. Contohnya : Kopling dan piston adalah bagian dari mesin, sedangkan mesin, roda, body merupakan bagian dari sebuah mobil.Kelebihan Dibandingkan dengan metode SSAD, OOAD lebih mudah digunakan dalam pembangunan sistem Dibandingkan dengan SSAD, waktu pengembangan, level organisasi, ketangguhan,dan penggunaan kembali (reuse) kode program lebih tinggi dibandingkan dengan metode OOAD (Sommerville, 2000). Tidak ada pemisahan antara fase desain dan analisis, sehingga meningkatkan komunikasi antara user dan developer dari awal hingga akhir pembangunan sistem. Analis dan programmer tidak dibatasi dengan batasan implementasi sistem, jadi desain dapat diformliasikan yang dapat dikonfirmasi dengan berbagai lingkungan eksekusi. Relasi obyek dengan entitas (thing) umumnya dapat di mapping dengan baik seperti kondisi pada dunia nyata dan keterkaitan dalam sistem. Hal ini memudahkan dalam mehami desain (Sommerville, 2000). Memungkinkan adanya perubahan dan kepercayaan diri yang tinggi terhadap kebernaran software yang membantu untuk mengurangi resiko pada pembangunan sistem yang kompleks (Booch, 2007). Encapsliation data dan method, memungkinkan penggunaan kembali pada proyek lain, hal ini akan memperingan proses desain, pemrograman dan reduksi harga. OOAD memungkinkan adanya standarisasi obyek yang akan memudahkan memahami desain dan mengurangi resiko pelaksanaan proyek. Dekomposisi obyek, memungkinkan seorang analis untuk memcah masalah menjadi pecahan-pecahan masalah dan bagian-bagian yang dimanage secara terpisah. Kode program dapat dikerjakan bersama-sama. Metode ini memungkinkan pembangunan software dengan cepat, sehingga dapat segera masuk ke pasaran dan kompetitif. Sistem yang dihasilkan sangat fleksibel dan mudah dalam memelihara.Kekurangan Pada awal desain OOAD, sistem mungkin akan sangat simple. Pada OOAD lebih fockus pada coding dibandingkan dengan SSAD. Pada OOAD tidak menekankan pada kinerja team seperti pada SSAD. Pada OOAD tidak mudah untuk mendefinisikan class dan obyek yang dibutuhkan sistem. Sering kali pemrogramam berorientasi obyek digunakan untuk melakukan anlisisis terhadap fungsional siste, sementara metode OOAD tidak berbasis pada fungsional sistem. OOAD merupakan jenis manajemen proyek yang tergolong baru, yang berbeda dengan metode analisis dengan metode terstruktur. Konsekuensinya adalah, team developer butuh waktu yang lebih lama untuk berpindah ke OOAD, karena mereka sudah menggunakan SSAD dalam waktu yang lama ( Hantos, 2005). Metodologi pengembangan sistem dengan OOAD menggunakan konsep reuse. Reuse merupakan salah satu keuntungan utama yang menjadi alasan digunakannya OOAD. Namun demikian, tanpa prosedur yang emplisit terhadap reuse, akan sangat sliit untuk menerapkan konsep ini pada skala besar (Hantos, 2005).Perancangan Terstruktur (Structured Analisys and Design / SSAD)Metode ini diperkenalkan pada tahun 1970, yang merupakan hasil turunan dari pemrograman terstruktur. Metode pengembangan dengan metode terstruktur ini terus diperbaiki sampai akhirnya dapat digunakan dalam dunia nyata.Perancangan ini bertujuan untuk membuat modelSOLUSIterhadapPROBLEMyang sudah dimodelkan secara lengkap pada tahap analisis terstruktur. Ada empat kegiatan perancangan yang harus dilakukan, yaitu:1. Perancangan arsitektural; kita merancang struktur modul P/L dengam mengacu pada model analisis yang sesuai (DFD). Langkahnya adalah: mengidentifikasi jenis aliran (transform flowatautransaction flow), menemukan batas-batas aliran (incoming flowdanoutgoing flow), kemudian memetakannya menjadi striktur hirarki modul. Selanjutnya, kita alokasikan fungsi-fungsi yang harus ada pada modul-modul yang tepat.2. Perancangan data; kita merancang struktur data yang dibutuhkan, serta merancang skema basisdata dengan mengacu pada model analisis yang sesuai (ERD).3. Perancangan antarmuka; kita merancang antarmuka P/L dengan pengguna, antarmuka dengan sistem lain, dan antarmuka antar-modul.4. Perancangan prosedural; kita merancang detil dari setiap fungsi pada modul. Notasi yang digunakan bisa berupaflow chart, algoritma, dan lain-lainPastikan bahwa model perancangan yang dibuat sudah mengakomodasi kebutuhan non fungsional.Berikut ini merupakan kelebihan dan kekurangan metode perancangan terstruktur :Kelebihan Milestone diperlihatkan dengan jelas yang memudahkan dalam manajemen proyek SSAD merupakan pendekatan visual, ini membuat metode ini mudah dimengerti oleh pengguna atau programmer. Penggunaan analisis grafis dan tool seperti DFD menjadikan SSAD menjadikan bagus untuk digunakan. SSAD merupakan metode yang diketahui secara umum pada berbagai industry. SSAD sudah diterapkan begitu lama sehingga metode ini sudah matang dan layak untuk digunakan. SSAD memungkinkan untuk melakukan validasi antara berbagai kebutuhan SSAD relatif simpel dan mudah dimengerti.Kekurangan SSAD berorientasi utama pada proses, sehingga mengabaikan kebutuhan non-fungsional. Sedikit sekali manajemen langsung terkait dengan SSAD Prinsip dasar SSAD merupakan pengembangan non-iterative (waterfall), akan tetapi kebutuhan akan berubah pada setiap proses. Interaksi antara analisis atau pengguna tidak komprehensif, karena sistem telah didefinisikan dari awal, sehingga tidak adaptif terhadap perubahan (kebutuhan-kebutuhan baru). Selain dengan menggunakan desain logic dan DFD, tidak cukup tool yang digunakan untuk mengkomunikasikan dengan pengguna, sehingga sangat sulit bagi pengguna untuk melakukan evaluasi. Pada SAAD sulit sekali untuk memutuskan ketika ingin menghentikan dekomposisi dan mliai membuat sistem. SSAD tidak selalu memenuhi kebutuhan pengguna. SSAD tidak dapat memenuhi kebutuhan terkait bahasa pemrograman berorientasi obyek, karena metode ini memang didesain untuk mendukung bahasa pemrograman terstruktur, tidak berorientasi pada obyek (Jadalowen, 2002).Perbedaan Analisa Berbasis Objek dan Yang Terstruktur Perancangan Terstruktur : Modul merupakan unit dari kode software yang menjalankan fungsi. Perancangan Berorientasi Objek : Modul objek yang mengenkapsulasi atribut dan kode program untuk berjalan.Inspired By Source :http://aribimoprihartanto.blogspot.com/2011/11/perbedaan-perancangan-terstruktur-dan.htmlhttp://saiiamilla.wordpress.com/2010/06/04/ooad-object-oriented-analysis-dan-design/http://eziekim.wordpress.com/2011/11/08/perbedaan-antara-perancangan-terstruktur-dan-berorientasi-objek/http://andri503.blogspot.com/2012/06/analisa-dan-perancangan-berbasis-objek.html