Introduchvbhvbtion To Um L

Del Polytechnic of Informatics
Introduction to UML A. UML

UML (Unified Modeling Language) merupakan pengganti dari metode analisis berorientasi objek dan design berorientasi objek(OOA&D) yang dimunculkan sekitar akhir tahun 80-an dan awal tahun 90-an. UML merupakan gabungan dari metode Booch, Rumbaugh(OMT) dan Jacobson. Tetapi UML ini akan mencakup lebih luas daripada OOA&D. Pada pertengahan pengembangan UML dilakukan standarisasi proses dengan OMG(Object Management Group) dengan harapan UML akan menjadi bahasa standar pemodelan pada masa yang akan datang. UML disebut sebagai bahasa pemodelan, bukan metode. Karena kebanyakan metode sedikitnya terdiri dari prinsip, bahasa pemodelan dan proses. Bahasa pemodelan (pada umumnya) merupakan bagian dan notasi dari metode yang digunakan untuk mendesain secara cepat. Bahasa pemodelan merupakan bagian terpenting dari metode dan merupakan bagian kunci tertentu untuk komunikasi. Dalam tahap awal untuk melakukan proses desain, maka anda hanya membutuhkan bahasa pemodelan bukan proses yang digunakan untuk mendapatkan desain. UML merupakan bahasa standar untuk penulisan blueprint software yang digunakan untuk visualisasi, spesifikasi, pembentukan dan pendokumentasian alat-alat dari sistem software.
a. Sejarah Singkat UML

Bahasa pemodelan berorientasi objek muncul antara sekitar pertengahan tahun 1970-an dan akhir tahun 1980-an yang dikenal dengan bahasa pemograman berorientasi objek dan aplikasi komplek yang berkembang, yang dimulai untuk eksperimen dengan pendekatan alternatif untuk analisis dan desain. Sejumlah metode berorientasi objek bertambah dari kurang lebih 10 sampai lebih dari 50 selama periode 1989 dan 1994. Beberapa user pengguna metode ini menemukan permasalahan dalam bahasa pemodelan ini yang dibutuhkan mereka untuk kelengkapan, sehingga timbul yang dinamakan perang metode. Belajar dari pengalaman, metode generasi baru mulai muncul dengan metode yang terkemuka,
RNS/IntroductionToUML
11/12/2009 07:09:39
Page - 1 - of 48
seperti Booch, Jacobsons OOSE(Object Oriented Software Engineering) dan Rumbaughs OMT(Object Modelling Technique). Metode penting lainya seperti Fusion, Shler_mellor dan Coad-Yourdan. Setiap metode ini merupakan metode yang lengkap, meskipun setiap metode diakui memiliki kelebihan dan kekurangan. Dalam waktu yang singkat metode Booch paling terasa dalam mendesain dan membangun tahapam project,OOSE memberikan dukungan yang baik untuk use cases seperti cara untuk menjalankan permintaan, analisis dan desain level tinggi, dan OMT-2 sangat berguna untuk analisis dan sistem informasi data intensif. Banyak ide-ide yang kritis dimulai dari pertengahan tahun 1990-an ketika Grady Booch(Relational Software Corporation), Ivar Jacobson(Objectory) dan James Rumbaugh(General Electric) mulai mengadopsi ide-ide dari metode lainnya yang dikumpulkan yang akhirnya diakui sebagai Metode Object Oriented yang mudah diseluruh dunia. Kemudian mereka termotivasi untuk membangun UML(Unified Modelling Language). Ada tiga tujuan dibangunnya penyatuan metode tersebut yaitu : 1. Untuk memodelkan sistem, dari konsep ke bentuk yang cocok dengan menggunakan teknik berorientasi objek. 2. Untuk menunjukkan skala persoalan yang komplek. 3. Untuk membangun bahasa pemodelan yang berguna bagi manusia dan mesin. Perencanaan bahasa untuk digunakan pada analisa dan desain yang berorientasi objek tidak seperti mendesain bahasa pemograman. Pertama, kita harus mengetahui masalah seperti dapatkah bahasa mencakup spesikasi permintaan? Dapatkah bahasa penting untuk pemograman visual? Kedua, kita harus menemukan keseimbangan antara komplek dan kesederhanaan. Bahasa yang terlalu sederhana akan terbatas untuk problem yang luas yang akan dipecahkan. Sedangkan untuk bahasa yang komplek akan berakibat terlalu pengembang pada sistem yang sederhana. UML dimulai secara resmi pada oktober 1994, ketika Rumbaugh bergabung dengan Booch pada Relational Software Coorporation. Proyek ini memfokuskan pada penyatuan metode Booch dan OMT. Versi 0.8 merupakan metode penyatuan yang direlease pada bulan oktober 1995. Dalam waktu yang sama Jacobson bergabung dengan Ralational dan cakupan dari UML semakin luas sampai diluar perusahaan OOSE. Dokumentasi UML versi 0.9 akhirnya direlease pada bulan Juni 1996. Meskipun pada tahun 1996 ini melihat dan menerima feedback dari komunitas Software Engineering. Dalam waktu tersebut menjadi lebih jelas bahwa beberapa
RNS/IntroductionToUML 11/12/2009 07:09:39 Page - 2 - of 48
organisasi software melihat kalau UML merupakan strategi dari bisnisnya. Kemudian dibangunlah UML. Disini beberapa patner yang berkontribusi pada UML 1.0 diantaranya Digital Equipment Corporation, Hewlett-packard, I-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Relational, Texas Instruments dan Unisys. Dari Colaboration ini dihasilkan UML 1.0 yang merupakan bahasa pemodelan yang ditetapkan secara baik, ekspesif, kuat dan cocok untuk lingkungan masalah yang luas. UML 1.0 ditawarkan menjadi standarisasi dari Object Management Group(OMG). Dan pada januari 1997 sebagai standar bahasa pemodelan. Antara Januari Juli 1997 Gabungan group tersebut memperluas kontribusinya sebagai hasil respon dari OMG dengan memasukkan Adersen Consulting, Ericsson, ObjectTimeLimeted, Platinum Technology,Ptech, Reich Technologies, Softeam, Sterling Software dan Taskon. Revisi dari versi UML(versi 1.1) ditawarkan kepada OMG sebagai standarisasi pada bulan juli 1997. Dan pada bulan September 1997 versi ini dierima oleh OMG Analysis dan Design Task Force(ADTF) dan OMG ArchitectureBoard. Dan Akhirnya pada Juli 1997 UML versi 1.1 menjadi standarisasi. Pemeliharaan UML terus dipegang oleh OMG Revision Task Force(RTF) yang dipimpin oleh Cris Kobryn. RTP merilis editorial dari UML 1.2 pada Juni 1998. Dan pada tahun 1998 RTF juga merilis UML 3.1 dengan disertai dengan user guide dan memberikan technical cleanup. UML Consortium dengan beberapa organisasi yang akan menyumbangkan sumber dayanya untuk bekerja mengembangkan dan melengkapi
b. Gambaran dari UML

UML sebagai Bahasa Pemodelan UML merupakan Bahasa pemodelan yang memiliki pembendaharaan kata dan cara untuk mempresentasikan secara fokus pada konseptual dan fisik dari suatu sistem. Contoh untuk sistem software yang intensive membutuhkan bahasa yang menunjukkan pandangan yang berbeda dari arsitektur sistem, ini sama seperti menyusun/mengembangkan software development life cycle. Dengan UML akan memberitahukan kita bagaimana untuk membuat dan membaca bentuk model yang baik, tetapi UML tidak dapat memberitahukan model apa yang akan
11/12/2009 07:09:39
Page - 3 - of 48
dibangun dan kapan akan membangun model tersebut. Ini merupakan aturan dalam software development process. UML sebagai bahasa untuk Menggambarkan Sistem(Visualizing) UML tidak hanya merupakan rangkaian simbol grafikal, cukup dengan tiap simbol pada notasi UML merupakan penetapan simantik yang baik. Dengan cara ini, satu pengembang dapat menulis model UML dan pengembang lain atau perangkat yang sama lainnya dapat mengartikan bahwa model tersebut tidak ambigu. Hal ini akan mengurangi error yang terjadi karena perbedaan bahasa dalam komunikasi model konseptual dengan model lainnya. UML menggambarkan model yang dapat dimengerti dan dipresentasikan ke dalam model tekstual bahasa pemograman. Contohnya kita dapat menduga suatu model dari sistem yang berbasis web tetapi tidak secara langsung dipegang dengan mempelajari code dari sistem. Dengan model UML maka kita dapat memodelkan suatu sistem web tersebut dan dipresentasikan ke bahasa pemogranan. UML merupakan suatu model ekaplisit yang menggambarkan komunikasi informasi pada sistem. Sehingga kita tidak kehilangan informasi code implementasi yang hilang dikarenakan developer memotong coding dari implementasi. UML sebagai bahasa untuk Menspesifikasikan Sistem (Specifying) Maksudnya membangun model yang sesuai, tidak ambigu dan lengkap. Pada faktanya UML menunjukan semua spesifikasi keputusan analisis, desain dan implementasi yang penting yang harus dibuat pada saat pengembangan dan penyebaran dari sistem software intensif. UML sebagai bahasa untuk Membangun Sistem(Constructing) UML bukan bahasa pemograman visual, tetapi model UML dapat dikoneksikan secara langsung pada bahasa pemograman visual. Maksudnya membangun model yang dapat dimapping ke bahasa pemograman seperti java, C++, VB atau tabel pada database relational atau penyimpanan tetap pada database berorientasi objek. UML sebagai bahasa untuk Pendokumentasian Sistem (Documenting) Maksudnya UML menunjukan dokumentasi dari arsitektur sistem dan detail dari semuanya. UML hanya memberikan bahasa untuk memperlihatkan
permintaan dan untuk tes. UML menyediakan bahasa untuk memodelkan aktifitas dari perencanaan project dan menejemen pelepasan (release management).
c. Area Penggunaan UML

UML digunakan paling efektif pada domain seperti : Sistem Informasi Perusahaan Sistem Perbankan dan Perekonomian Bidang Telekomunikasi Bidang Transportasi Bidang Penerbangan Bidang Perdagangan Bidang Pelayanan Elekronik Bidang Pengetahuan Bidang Pelayanan Berbasis Web Terdistribusi
Namun UML tidak terbatas untuk pemodelan software. Pada faktanya UML banyak untuk memodelkan sistem nonsoftware seperti : Aliran kerja pada sistem perundangan. Struktur dan Kelakuan dari sistem Kepedulian Kesehatan Pasien Desain Hardware dll.
Tujuan penggunaan UML : 1. Memodelkan suatu sistem (bukan hanya perangkat lunak) yang menggunakan konsep berorientasi objek. 2. Menciptakan suatu bahasa pemodelan yang dapat digunakan baik oleh manusia maupun mesin.
d. Diagram dalam UML

Diagram berbentuk grafik yang menunjukan simbol elemen model yang disusun utuk mengilustrasikan bagian atau aspek tertentu dari sistem. Sebuah model sistem biasanya mempunyai beberapa diagram untuk setiap jenisnya.
11/12/2009 07:09:39
Page - 5 - of 48
Adapun jenis jenis diagram antara lain : Use Case Diagram Menggambarkan sejumlah eksternal actor dan hubungannya ke Use Case yang diberikan oleh sistem. Use Case digambarkan hanya yang dilihat dari luar oleh actor (keadaan lingkungan sistem yang dilihat user) dan bagaimana fungsi yang ada didalam sistem. Class Diagram Menggambarkan struktur statis class dalam sistem. Class merepresentasikan sesuatu yang ditangani oleh sistem. Class dapat dihubungkan dengan lainnya melalui sejumlah cara : assosiated (terhubung satu dengan yang lain), dependent (satu class tergantung / menggunakan class yang lainnya), specialiized (satu class merupakan spesialisasi dari class lainnya), atau packaged (grup bersama sebagai suatu unit). Sequence Diagram Menggambarkan kolaborasi dinamis antar sejumlah object. Kegunaanya untuk menunjukkan rangkaian pesan yang dikirim antara objek juga interaksi antara object. Collaboration Diagram Menggambarkan kolaborasi dinamis seperti sequence diagram. Dalam menunjukkan pertukaran pesan, collaboration diagram menggambarkan object dan hubungannya (mengacu ke konteks). Jika penekanannya pada waktu atau urutan gunakan sequence diagram, tetapi jika penekanannya pada konteks gunakan collaboration diagram. State Chart Diagram Menggambarkan semua state (kondisi) yang dimiliki oleh suatu object dari suatu class dan kejadian yang menyebabkan state berubah secara dinamis. Activity Diagram Menggambarkan rangkaian aliran dari aktivitas, digunakkan untuk mendeskripsikan aktivitas yang dibentuk dalam suatu operasi sehingga dapat juga digunakan untuk aktivitas lainnya seperti use case atau interaksi. Component Diagram Menggambarkan struktur fisik kode dari komponen. Komponen dapat berupa source code, komponen biner, atau executable component. Sebuah
11/12/2009 07:09:39
Page - 6 - of 48
komponen berisi tenatang logic class atau class yang diimplementasikan sehingga membuat pemetaan dari logical view ke component view. Deployment Diagram Menggambarkan arsitektur fisik dari perangkat keras dan perangkat lunak sistem, menunjukkan hubungan komputer dengan perangkat (nodes) satu sama lain dan jenis hubungannya. Di dalam nodes, executable, component dan object yang dialokasikan untuk memperlihatkan unit perangkat lunak yang dieksekusi oleh node tertentu dan ketergantungan komponen.
e. Tool yang mendukung UML

Saat ini banyak sekali tool pendesainan yang mendukung UML, baik itu tool komersil 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)
B. RUP
RUP (Rational Unified Process) merupakan suatu Software engineering process hasil kerja awal dari Three Amigos Ivar Jacobson, Grady Booch, dan James Rumbaugh- yang bertujuan untuk memastikan kualitas yang terbaik pada suatu produksi software dengan memperkirakan jadwal dan biaya yang harus dikeluarkan. RUP merupakan process product dari Rational Software dengan konsep utamanya adalah tentang model, workflow dan workers, serta tentang phase dan iterasi. Aktifitas yang dilakukan oleh Rational Unified Process adalah membuat dan memelihara model. RUP juga meliputi pembahasan dari implementasi UML (Unified Modelling Language) secara luas dan memfokuskan dirinya pada software yang memiliki metodologi berorientasi objek. Sehingga dapat kita bedakan dengan UML bahwa RUP merupakan sebuah proses yang dilakukan dalam rekayasa perangkat lunak
11/12/2009 07:09:39
Page - 7 - of 48
sedangkan UML adalah bahasa standar yang digunakan untuk memvisualisasikan, mendeskripsikan, membangun, dan mendokumentasikan perangkat yang akan digunakan dalam membangun sebuah perangkat lunak. RUP dibutuhkan sebagai pedoman untuk menggunakan UML secara efektif. Sedangkan UML berfungsi sebagai standardisasi notasi yang berorientasi objek untuk mengkomunikasikan kebutuhan/requirement, architectures, dan desain secara jelas dengan user. Oleh karena itu, hubungan antara RUP dan UML sangatlah dekat. Aktifitas yang dilakukan dalam Software development merupakan sebuah pekerjaan team. Karena perubahan teknologi yang cepat sehingga memerlukan spesialisasi tertentu dalam pelaksanaannya. Produktivitas team ini dapat ditingkatkan dengan menggunakan RUP dalam mendukung pembangunan sebuah software. Mengapa? Karena setiap anggota team akan dibekali oleh pengetahuan dasar yang sama mengenai guidelines dan template dalam aktifitas software development, sehingga saat membangun sebuah sistem akan dijamin bahwa setiap anggota team akan menggunakan bahasa yang sama untuk merepresentasikan requirement yang diminta user. Jika telah ada standar yang digunakan dalam proses pembangunan sebuah software, diharapkan dapat mengoptimalkan hasil yang diperoleh. Sebelum kita membahas lebih dalam mengenai Rational Unified Process, kita perlu untuk mengetahui terlebih dahulu apa maksud dari proses itu sendiri. Proses merupakan suatu tahapan yang mendefinisikan siapa yang mengerjakan apa, kapan dan bagaimana meraih suatu tujuan yang pasti. RUP merepresentasikan empat elemen dasar untuk memodelkan pertanyaan yang muncul dari sebuah proses, yaitu workers, activities, artifacts, dan workflows. Worker mendefinisikan behavior/kelakuan dan responsibilities dari seseorang atau sebuah team. Dalam Unified Process, worker lebih diartikan sebagai bagaimana team/individual seharusnya bekerja. Sedangkan tanggung jawab bagi worker adalah melakukan serangkaian aktifitas sebagai pemilik dari sekumpulan artifact. Activity dari spesific worker adalah sebuah unit kerja yang dilakukan seorang individu. Tujuannya cukup jelas, yaitu membuat/meng-update artifact. Setiap activity diberikan kepada spesific worker dan harus dapat digunakan sebagai elemen dalam planning dan progress software development. Contoh activity diantaranya : merencanakan sebuah iteration untuk worker Project Manager, menemukan use case dan aktor untuk worker System Analyst, dan sebagainya.
11/12/2009 07:09:39
Page - 8 - of 48
Artifact merupakan sekumpulan informasi yang dihasilkan, diubah, dan dipakai dalam sebuah proses. Artifact digunakan sebagai input bagi worker untuk melakukan activity dan juga sebagai output dari activity. Dalam object-oriented design, activities adalah operasi yang dilakukan aktif object(worker) sedangkan artifact sebagai parameter dari activities tersebut. Contoh artifact yaitu: model (uses case model), document,source code,dan lain-lain. Workflow adalah serangkaian activities yang menghasilkan nilai hasil yang dapat terlihat. Dalam UML, workflow digambarkan dengan sequence diagram, collaboration diagram, atau activity diagram. Workflow tidak selalu dapat dipakai untuk merepresentasikan semua ketergantungan yang ada diantara activities. Karena, terkadang dua buah activities yang digambarkan dalam workflow sebenarnya sangat rapat jalinannya yang melibatkan worker yang sama padahal mungkin penggambarannya tidak terlalu tepat. Jadi, perlu ditetapkan tipe workflow yang paling dibutuhkan dalam process yang disebut Core Process. Core process workflows :
Process Workflows
Business Modeling Requirements Analysis & Design Implementation Test Deployment
Inception Elaboration
Construction
Transition
Supporting Workflows
Configuration Mgmt Project Mgt Environment
Preliminary Iteration(s) Iter. Iter. Iter. #n Iter. Iter. #n+1 #n+2 Iter. #m
Iter. #m+1
Iterations
Dari gambar diatas, terlihat ada sembilan core process workflow dalam RUP. Semuanya merepresentasikan pembagian worker dan activities ke dalam logical grouping. Ada dua bagian utama yaitu process workflows dan supporting workflows. Dalam
11/12/2009 07:09:39
Page - 9 - of 48
process workflows terdapat Bussiness modeling yang didalamnya dibuat dokumen bussiness process yang dipakai disebut bussiness use cases. Dokumen ini menjamin stakeholder memahami kebutuhan bisnis proses yang diperlukan. Tujuan dari requirement workflow adalah mendeskripsikan what/apa yang harus dikerjakan oleh sistem serta membolehkan developer dan costumer untuk menyetujui deskripsi itu. Analysis&Design workflows bertujuan untuk menunjukkan how/bagaimana merealisasikan sistem dalam tahap implementasi. Didalamnya kita akan menemukan problem domain juga solusi dari problem yang mungkin akan muncul dalam sistem. Hasil yang diberikan pada tahapan ini adalah design model sebagai blueprint dari source code yang akan dibuat dan juga analysis model (optional). Implementation workflow bertujuan untuk mengimplementasikan classes dan objects dalam hubungannya dengan component, mengetest component yang dihasilkan sebagai unit, dan untuk mengintegrasikan hasil yang dibuat oleh masing-masing implementer/teams ke dalam executable system. RUP menjelaskan bagaimana kita mereuse exiting complements atau me-implement new component sehingga membuat sistem mudah dibangun dan meningkatkan kemungkinan untuk me-reusenya. Test workflow bertujuan untuk memeriksa interaksi antar objek, penggabungan component dari software dengan tepat, dan memeriksa apakah semua kebutuhan sudah dipenuhi dengan tepat. Selain itu, test bertujuan untuk mengidentifikasikan dan meyakinkan bahwa kerusakan yang ada telah diatasi sebelum men-deploy software. RUP menawarkan pendekatan iterative yang memungkinkan kita mengetest keseluruhan project dengan menemukan kerusakan sejak dini sehingga mengurangi cost untuk memperbaikinya. Test menghasilkan tiga macam ukuran qualitas yaitu reliability, functionality, application dan system performance. Deployment workflow dilakukan untuk menghasilkan product release dengan sukses dan aktifitas mengantar software kepada end user seperti membuat external releases dari software, packing software, distributing software, installing software, serta membantu user memahami sistem. Aktifitas ini dilakukan pada fase transition. Dalam RUP, deployment workflow berisi paling sedikit detailnya daripada workflow yang lain. Project management menyediakan framework untuk mengatur software-intensive projects, panduan untuk planning, staffing, executing, dan monitoring projects, dan framework untuk mengatur resiko yang ada. Dikatakan sukses apabila produk tersebut dapat memenuhi kebutuhan user dan kebanyakan customer.
11/12/2009 07:09:39
Page - 10 - of 48
Configuration and change management menyediakan panduan untuk mengatur penyusunan software systems, mengatasi perubahan request management, dan dapat menjadi salah satu cara untuk melaporkan suatu kerusakan. Environment bertujuan menyediakan software development organization beserta software development environment, yang dibutuhkan untuk mendukung development team. Seperti yang kita tahu dalam software development, tujuan yang akan diraih adalah membangun/meningkatkan sebuah software sesuai dengan kebutuhan (Bussiness Process). Sedangkan sebuah proses disebut efektif jika menetapkan sebuah garis pedoman yang menjamin kualitas software yang dibangun, mengurangi resiko dan meningkatkan perkiraan kepada masalah yang mungkin muncul, serta menggunakan best practise. Rational Unified Process menawarkan dan menjelaskan penerapan six best practise yang efektif pada software development, diantaranya adalah : 1. Develop Software Iteratively Pendekatan secara iterative digunakan untuk mengurangi resiko yang dapat terjadi selama lifecycle. Setiap akhir iterasi akan diperoleh executable release yang memungkinkan keterlibatan end user dan feedback yang diberikan secara terus-menerus. Pendekatan ini juga mempermudah penyesuaian perubahan kebutuhan, features, maupun jadwalnya. 2. Manage Requirements Rational Unified Process mendeskripsikan bagaimana mendapatkan, mengorganisasikan, dan mendokumentasikan fungsionalitas dan batasan yang dibutuhkan. Sehingga akan memudahkan dalam memahami dan mengkomunikasikan kebutuhan bisnis. 3. Use Component-based Architecture RUP menggunakan pendekatan sistematis dalam mendefinisikan arsitektur yang menggunakan component. Karena memang proses yang dilakukan difokuskan pada awal pembangunan sebuah software. Dalam proses ini akan mendeskripsikan bagaimana menyusun arsitektur yang fleksibel, mudah dipahami, dan mengembangkan efektif software reuse. 4. Visually Model Software Proses yang dilakukan menunjukkan bagaimana memvisualisasikan model yang mencakup struktur dan kelakuan dari arsitektur dan komponen. 5. Verify Software Quality
Application performance dan kemampuan tahan uji yang buruk dapat menghalangi diterimanya sebuah aplikasi software. Sehingga diperlukan penelaahan lebih lanjut tentang kualitas software dengan mematuhi kebutuhan aplikasi berdasarkan kemampuan tahan uji, fungsionalitas, application performance, dan system performance. 6. Control Changes to Software Proses akan mendeskripsikan bagaimana mengontrol dan memonitor perubahan untuk kesuksesan iterative development. Selain itu, proses juga akan memandu kita bagaimana menyusun workspace yang aman bagi para developer dengan mengisolasi perubahan yang dilakukan di workspace lain dan dengan mengontrol perubahan pada seluruh software artifact. Sehingga membuat team bekerja sebagai unit tersendiri dengan mendeskripsikan bagaimana mengintegrasikan dan membangun management secara otomatis. RUP sebagai architecture-centric. Architeture ini merupakan fokus yang dibahas pada fase elaboration yang akan dibahas pada bagian lain makalah ini. Software architecture design merupakan artifact dasar yang diperoleh dari sebuah architecture. Artifact lain yang diperoleh dari sebuah architecture ini diantaranya dapat membuat garis pedoman desain yang dipakai, struktur produk, dan team structure. Dalam merepresentasikan sebuah architecture pada software development kita menggunakan yang disebut The 4+1 view model yang telah kita kenal saat mempelajari UML. View model itu terdiri dari : logical view (dipakai oleh analyst/designer), implementation view (dipakai oleh progammer), process view (dipakai oleh system integrator), dan deployment view (dipakai oleh system engineering), serta ditambah dengan use case view (dipakai oleh end user). Keuntungan dari architecture centric process diantaranya memperbolehkan kita untuk menambah dan menambah intellectual control sebuah proyek untuk mengatur kompleksitas dan membangun system integrity. Proses arsitektur ini memiliki lifecycle phase, yang terdiri dari inception phase, elaboration phase, construction phase, dan transition phase. Setiap fase yang ada dihubungkan dengan milestone, yaitu suatu point evaluasi dari suatu tahap fase yang sudah selesai dibuat, sebagai langkah menuju fase berikutnya. Apabila evaluasi ini gagal maka fase tersebut harus diperbaiki kembali.
11/12/2009 07:09:39
Page - 12 - of 48
Setiap phase memiliki tujuan tersendiri, yaitu sebagai berikut : 1. Inception Phase Merupakan fase yang pertama kali dijalankan, didalamnya akan membangun bussiness case dan batasan ruang lingkup project. Hasil dari fase ini adalah vision document (bayangan umum project), initial use-case model (sudah 10%-20% selesai), initial bussiness case, initial project glossary, initial risk assesment, project plan (phases dan iteration), bussiness model jika perlu, dan beberapa prototype. Milestone di akhir fase ini adalah lifecycle objective. Kriteria evaluasi untuk fase inception yaitu : ada persetujuan dari stakeholder terhadap definisi ruang lingkup dan biaya/jadwal yang diperkirakan; pemahaman terhadap kebutuhan sebagai petunjuk oleh primary uses case; kepercayaan dari perkiraan cost/schedule, prioritas, resiko, dan development process; kedalaman dan luasnya arsitektur prototype yang dibangun; perbandingan pengeluaran yang ada dengan yang direncanakan. 2. Elaboration Phase Tujuan fase ini adalah menganalisa masalah utama, menyusun pondasi arsitektur, membangun rencana project, dan menghilangkan resiko terburuk yang akan dialami project. Fase elaboration merupakan fase yang paling kritis karena tujuannya adalah untuk menganalisa masalah. Aktifitas yang dilakukan yaitu menjamin bahwa arsitektur, requirement, dan rencana yang dilakukan cukup stabil dan mengurangi resiko sehingga dapat memprediksikan cost dan schedule yang dibutuhkan. Hasil dari proses ini adalah : use case model (min.80% complete), software architecture description, executable architectural prototype, revisi daftar resiko dan bussiness case. Milestone yang dicapai di akhir fase ini adalah lifecycle architecture. Pada point ini, kita menguji ruang lingkup dan detail dari system secara objektif, pilihan arsitektur, dan pemecahan masalah utama. Kriteria evaluasi yang dapat dilakukan yaitu kestabilan arsitektur dan produk; apakah masalah utama yang muncul telah diatasi; apakah rencana untuk fase contruction telah akurat; dan apakah seluruh stakeholder menyetujui arsitektur yang dibuat.
11/12/2009 07:09:39
Page - 13 - of 48
3. Construction Phase Di fase ini semua component dan feature aplikasi dibangun dan disatukan ke dalam product serta akan diperiksa. Construction phase berupa sebuah proses manufacturing yang menekankan pada pengontrolan operasi untuk mengoptimalkan cost, schedule, dan kualitas. Keluaran dari fase ini adalah kesiapan produk untuk diserahkan kepada user yang meliputi : integritas produk pada platform mencukupi, user manual, dan deskripsi dari rilis berikutnya. Milestone yang dicapai di akhir fase ini adalah initial operation capability. Kriteria evaluasi pada fase ini : apakah produk yang dirilis sudah stabil dan matang untuk diberikan kepada user, apakah semua stakeholder siap untuk proses transition, apakah perbandingan pengeluaran resource dengan rencana semua masih dapat diterima. 4. Transition Phase Tujuannya yaitu untuk mentransisikan/menyerahkan funsionalitas sistem lengkap ke pengguna dan juga menyerahkan rilis produk. Fase ini meliputi : beta testing untuk memvalidasi sistem dengan perkiraan user, melakukan operasi paralel dengan sistem lama, mengkonversi operational database, melatih user dan maintaners, roll-out produk untuk pemasaran dan distribusi. Milestone yang dicapai di akhir fase ini adalah product release. Kriteria evaluasi yang dapat dilakukan : apakah user puas terhadap software yang kita bangun dan apakah perbandingan pengeluaran resource dengan rencana semua masih dapat diterima.
Beberapa Alat Bantu dalam RUP [WEI01] Beberapa alat bantu yang digunakan dalam RUP adalah : a. Tahap Business Engineering/Business Modelling Business Use Case Model Model ini digunakan untuk menggambarkan atau mendeskripsikan bagaimana proses bisnis dari sistem yang akan dikembangkan (existing system) dalam terminologi use case. Diagram yang digunakan dalam pemodelan ini adalah Business Use Case Diagram. Business Object Model
11/12/2009 07:09:39
Page - 14 - of 48
Model ini digunakan untuk menggambarkan bagaimana realisasi dari setiap business use case pada business use case diagram. Dari setiap business use case dibreakdown sehingga dapat diketahui entitas apa saja yang ada dalam business use case tersebut. Entitas-entitas ini akan menjadi kandidat kelas dalam Class Diagram. b. Tahap Requirement Analysis Use Case Model Model ini digunakan untuk menggambarkan kebutuhan-kebutuhan atau fitur-fitur yang harus dimiliki oleh sistem yang baru. Diagram yang digunakan dalam pemodelan ini adalah Use Case Diagram. c. Tahap Analysis and Design Design Model Model ini digunakan untuk menggambarkan bagaimana analisis dan desain sistem yang baru. Dari setiap use case pada use case diagram dibreakdown untuk mengetahui bagaimana realisasi dari use case tersebut. Realisasi use case dapat dimodelkan dengan beberapa diagram, yaitu Class Diagram (own by Use Case Realization) serta Interaction Diagram. Sedangkan desain sistem digambarkan dengan Class Diagram. d. Tahap Implementation Implementation Model Model ini digunakan untuk menggambarkan bagaimana implementasi terhadap desain dari sistem yang baru. Salah satu diagram yang digunakan dalam pemodelan ini adalah Database Diagram.
11/12/2009 07:09:39
Page - 15 - of 48
1 Use Case Diagram
1.1 Pengertian Use Case Diagram

Use case diagram adalah gambaran graphical dari beberapa atau semua actor, use case, dan interaksi diantara komponen-komponen tersebut yang memperkenalkan suatu sistem yang akan dibangun. Use case diagram menjelaskan manfaat suatu sistem jika dilihat menurut pandangan orang yang berada di luar sistem. Diagram ini menunjukkan fungsionalitas suatu sistem atau kelas dan bagaimana sistem tersebut berinteraksi dengan dunia luar. Use case diagram dapat digunakan selama proses analisis untuk menangkap requirements sistem dan untuk memahami bagaimana sistem seharusnya bekerja. Selama tahap desain, use case diagram berperan untuk menetapkan perilaku (behavior) sistem saat diimplementasikan. Dalam sebuah model mungkin terdapat satu atau beberapa use case diagram. Kebutuhan atau requirements sistem adalah fungsionalitas apa yang mesti disediakan oleh sistem kemudian didokumentasikan pada model use case yang menggambarkan fungsi sistem yang diharapkan (use case), dan yang mengelilinginya (actor), serta hubungan antara actor dengan use case (use case diagram) itu sendiri.
1.2 Komponen Pembentuk Use Case Diagram

1.2.1 Actor Pada dasarnya actor bukanlah bagian dari use case diagram, namun untuk dapat terciptanya suatu use case diagram diperlukan beberapa actor. Actor tersebut mempresentasikan seseorang atau sesuatu (seperti perangkat, sistem lain) yang berinteraksi dengan sistem. Sebuah actor mungkin hanya memberikan informasi inputan pada sistem, hanya menerima informasi dari sistem atau keduanya menerima, dan memberi informasi pada sistem. Actor hanya berinteraksi dengan use case, tetapi tidak memiliki kontrol atas use case. Actor digambarkan dengan stick man . Actor dapat digambarkan secara secara umum atau spesifik, dimana untuk membedakannya kita dapat menggunakan relationship.
11/12/2009 07:09:39
Page - 16 - of 48
Gambar 1.1 Actor Contoh : Ada beberapa kemungkinan yang menyebabkan actor tersebut terkait dengan sistem antara lain: Yang berkepentingan terhadap sistem dimana adanya arus informasi baik yang diterimanya maupun yang dia inputkan ke sistem. Orang ataupun pihak yang akan mengelola sistem tersebut. External resource yang digunakan oleh sistem. Sistem lain yang berinteraksi dengan sistem yang akan dibuat.
1.2.2 Use Case Use case adalah gambaran fungsionalitas dari suatu sistem, sehingga customer atau pengguna sistem paham dan mengerti mengenai kegunaan sistem yang akan dibangun. Catatan : Use case diagram adalah penggambaran sistem dari sudut pandang pengguna sistem tersebut (user), sehingga pembuatan use case lebih dititikberatkan pada fungsionalitas yang ada pada sistem, bukan berdasarkan alur atau urutan kejadian.
Cara menentukan Use Case dalam suatu sistem: a. Pola perilaku perangkat lunak aplikasi. b. Gambaran tugas dari sebuah actor. c. Sistem atau benda yang memberikan sesuatu yang bernilai kepada actor. d. Apa yang dikerjakan oleh suatu perangkat lunak (*bukan bagaimana cara mengerjakannya).
11/12/2009 07:09:39
Page - 17 - of 48
Gambar 1.2 Use Case
1.2.3 Relasi dalam Use Case Ada beberapa relasi yang terdapat pada use case diagram: 1. Association, menghubungkan link antar element. 2. Generalization, disebut juga inheritance (pewarisan), sebuah elemen dapat merupakan spesialisasi dari elemen lainnya. 3. Dependency, sebuah element bergantung dalam beberapa cara ke element lainnya. 4. Aggregation, bentuk assosiation dimana sebuah elemen berisi elemen lainnya. Tipe relasi/ stereotype yang mungkin terjadi pada use case diagram: 1. <<include>> , yaitu kelakuan yang harus terpenuhi agar sebuah event dapat terjadi, dimana pada kondisi ini sebuah use case adalah bagian dari use case lainnya. 2. <<extends>>, kelakuan yang hanya berjalan di bawah kondisi tertentu seperti menggerakkan alarm. 3. <<communicates>>, mungkin ditambahkan untuk asosiasi yang menunjukkan asosiasinya adalah communicates association . Ini merupakan pilihan selama asosiasi hanya tipe relationship yang dibolehkan antara actor dan use case.
1.3 Use Case Diagram Dalam UML

Dalam UML terdapat beberapa diagram yang digunakan dalam use case view, salah satunya adalah use case diagram. Use case view membantu kita untuk memahami dan menggunakan sistem yang kita modelkan. Seperti yang telah kita ketahui sebelumnya bahwa use case diagram merupakan penggambaran secara graphical dari suatu sistem yang akan kita bangun yang terbentuk dari actor, use case, dan interaksi diantaranya.
11/12/2009 07:09:39
Page - 18 - of 48
Catatan : actor dan use case dapat juga langsung diciptakan dalam sebuah use case diagram dengan menggunakan toolbar. Berikut ini adalah contoh dari sebuah studi kasus yang menangani Aplikasi pada sebuah Cash Register Supermarket dengan skenario sbb: 1. Mencatat (merekam) data transaksi penjualan yang diketik melalui keyboard. Data yang dimasukkan adalah kuantitas dan kode barang. 2. menampilkan informasi nama barang, harga, dan jumlah begitu data kuantitas dank kode barang selesai dimasukkan 3. mencatat (merekam) data transaksi pembayaran. Data yang dimasukkan adalah jumlah uamg yang dibayarkan dan dilakukan setelah data transaksi penjualan selesai dicatat. Ada informasi total jumlah dan jumlah kembalian yang harus ditampilkan saat proses pemasukkan data ini. 4. mencetak struk sebagai tanda bukti transaksi pembayaran.
Inisialisasi Cash Register

(from Use-Case Model )
Pencatatan Transaksi Penjualan

Kasir
Pencatatan Transaksi Pembayaran
Pencetakkan Struk
Gambar 1.3 Use Case diagram untuk Cash Register Untuk memudahkan kita dalam menganalisa skenario yang akan kita gunakan pada fase-fase selanjutnya, maka kita dapat melakukan pemilahan terhadap skenario tersebut, antara lain:
11/12/2009 07:09:39
Page - 19 - of 48
Skenario use case

Nomor Nama use case Actor Type Tujuan Deskripsi 1. 2. diopersikan Cash register mencatat data yang dimasukkan : HLUC-01 : Inisialisasi Cash Register : Kasir : Primary dan esensial : Menjelaskan proses inisialisasi cash register : register mulai Kasir memasukkan data nomor kas register dan identitas kasir saat cash
Actor 1. Kasir memasukkan nomor kas register dan identitas kasir
Sistem
2. Cash register mencatat data yang dimasukkan Nomor Nama use case Actors Type Tujuan Deskripsi 1. 2. 3. : pelanggan : HLUC-02 : Pencatatan Transaksi Penjualan : Kasir : Primary dan esensial : Menjelaskan proses pencatatan dan perekaman data penjualan Kasir memasukkan data kuantitas dan kode barang yang dibeli Cash register merekam data yang sudah dimasukkan Actor 1. Kasir memasukkan data kuantitas dan kode barang yang di beli 2. Cash register mencari data nama dan harga barang 3. Cash register menghitung jumlah dan menampilkan hasilnya 4. Simpan data penjualan Sistem
Cash register mencari data nama dan harga barang, menghitung jumlah, dan menampilkannya
11/12/2009 07:09:39
Page - 20 - of 48

Nomor Nama use case Actors Type Tujuan Deskripsi 1. 2. 3. 4. 5. : : HLUC-03 : Pencatatan Transaksi Pembayaran : Kasir : Primary dan esensial : Menjelaskan proses pencatatan dan perekaman data pembayaran Kasir mengakhiri proses pemasukan data penjualan Cash register menghitung total pembayaran dan menampilkan hasilnya Kasir memasukkan data jumlah pembayaran yang diterima dari pelanggan Cash register menghitung kembalian dan menampilkan hasilnya Cash register merekam data yang sudah dimasukkan
Actor 1. Kasir mengakhiri proses pemasukkan data penjualan dengan menekan enter
Sistem
2. Cash register menghitung total pembayaran dan menampilkan hasilnya 3. Kasir memasukkan data jumlah pembayaran yang diterima dari pelanggan 4. Cash register menghitung kembalian dan menampilkan hasilnya 5. Simpan data pembayaran
Nomor Nama use case Actors Type Tujuan Deskripsi 1. 2. 3. 4. 5. :
: HLUC-04 : Pencetakan Struk : Kasir : Primary dan esensial : Menjelaskan proses pencetakan struk Kasir mengakhiri proses pemasukan data pembayaran Cash register membaca data penjualan yang sudah direkam di tabel penjualan Cash register mencari data nama dan harga barang sebagai pelengkap data penjualan yang sudah dibaca Cash register menghitung jumlah Cash register mencetak struk
11/12/2009 07:09:39
Page - 21 - of 48
Actor 1. Kasir mengakhiri proses pemasukkan data pembayaran dengan menekan enter
Sistem
2. Load tabel penjualan 3. Cash registermencari data nama dan harga barang 3. Cash register menghitung jumlah 4. Cetak struk
11/12/2009 07:09:39
Page - 22 - of 48
2 Candidate Class dan Interaction Diagram

2.1 Class Diagram
Pada bagianl 1 kita sudah mempelajari tentang apa pengertian dari Use case, relasirelasi dalam use case dan pengimplementasiannya yaitu dengan pembuatan usecase diagram. Dalam pembuatan program dengan metode Object Oriented Programming, komponen yang penting adalah dalam pendefinisian class yang nantinya akan digunakan dalam pembangunan aplikasi dengan metode OOP. Setelah kita selesai membuat use case diagram seperti yang dijelaskan dalam bagian 1, biasanya kita akan mendapat candidat class yang nantinya diantaranya akan menjadi class. 2.2.1 Candidat Class Dari skenario pada bagian 1 untuk studi kasus pada Cash Register Supermarket, kita dapat mendefenisikan candidate class, dimana candidate class secara kasar dapat diambil dari kata benda yang ada.
Gambar 2.2 Candidate Class
2.2.2
Definisi Class Object adalah gambaran dari entity, baik dunia nyata atau konsep dengan batasan-batasan dan pengertian yang tepat. Object bisa mewakili sesuatu yang nyata seperti komputer, mobil, atau dapat berupa konsep seperti proses kimia, transaksi bank, permintaan pembelian, dll. Setiap object dalam sistem memiliki tiga karakteristik yaitu State (status), Behaviour (sifat) dan Indentity (identitas). Cara mengidentifikasi object:
11/12/2009 07:09:39
Page - 23 - of 48
1. pengelompokan berdasarkan kata/frase benda pada skenario. 2. berdasarkan daftar kategori object, antara lain: object fisik, contoh : pesawat telepon spesifikasi/rancangan/deskripsi, contoh : deskripsi pesawat tempat, contoh : gudang transaksi, contoh : penjualan butir yang terlibat pada transaksi, contoh : barang jualan peran, contoh : pelanggan wadah, contoh : pesawat terbang piranti, contoh : PABX kata benda abstrak, contoh : kecanduan kejadian, contoh : pendaratan aturan atau kebijakan, contoh : aturan diskon catalog atau rujukan, contoh : daftar pelanggan
Class adalah deskripsi sekelompok object dari property (atribut), sifat (operasi), relasi antar object dan sematik yang umum. Class merupakan template untuk membentuk object. Setiap object merupakan contoh dari beberapa class dan object tidak dapat menjadi contoh lebih dari satu class. Penamaan class menggunakan kata benda tunggal yang merupakan abstraksi yang terbaik. Pada UML, class digambarkan dengan segi empat yang dibagi. Bagian atas merupakan nama dari class. Bagian yang tengah merupakan struktur dari class (atribut) dan bagian bawah merupakan sifat dari class (operasi).
Gambar 2.1 Class
11/12/2009 07:09:39
Page - 24 - of 48
2.2 Interaction Diagram

2.2.1 Use Case Realization Fungsionalitas use case direpresentasikan dengan aliran peristiwa-peristiwa. Skenario digunakan sebagai untuk menggambarkan antara bagaimana use case-use case case direalisasikan interaksi object-object.
Use
realization
menggambarkan bagaimana realisasi dari setiap use case yang ada pada use case model. Untuk menggambarkan bagaimana realisasi dari suatu use case dapat menggunakan beberapa diagram, diantaranya adalah Class Diagram owned by Use Case Realization serta Interaction Diagram. Interaction Diagram merupakan model yang menjelaskan bagaimana sejumlah object bekerja sama dalam beberapa kelakuan. Interaction Diagram menerangkan kela kuan dari suatu use case. Diagram ini menggambarkan sejumlah object dan pesan yang dijalankan antara object dengan use case. Ketika kita memberikan pesan, aksi yang dihasilkan adalah sebuah pernyataan tereksekusi yang membentuk abstraksi dari prosedur komputasi. Sebuah aksi mungkin menghasilkan perubahan kondisi. Dalam UML, kita dapat memodelkan beberapa jenis aksi, yaitu: Call : memanggil operasi yang ada pada object, object mungkin mengirim ke dirinya sendiri, menghasilkan pemanggilan lokal dari operasi. Return : mengembalikan nilai dari caller Send : mengirimkan sinyal ke object Create : membuat sebuah object Destroy : mematikan sebuah object, object mungkin saja mematikan dirinya sendiri. Interaction diagram digunakan ketika kita ingin melihat kelakuan dari beberapa object dalam use case tunggal. Diagram ini baik saat menunjukkan kolaborasi diantara object-object, namun kurang baik dalam mendefinisikan behavior. Ada dua macam Interaction Diagram yaitu : Sequence Diagram dan Collaboration Diagram.
11/12/2009 07:09:39
Page - 25 - of 48
2.2.2
Sequence Diagram Sequence Diagram menggambarkan interaksi antara sejumlah object dalam urutan waktu. Kegunaannya untuk menunjukkan rangkaian pesan yang dikirim antara object juga interaksi antar object yang terjadi pada titik tertentu dalam eksekusi sistem. Dalam UML, object pada diagram sequence digambarkan dengan segi empat yang berisi nama dari object yang digarisbawahi. Pada object terdapat 3 cara untuk menamainya yaitu : nama object, nama object dan class serta nama class. Contoh :
Gambar 2.3 Penamaan object Dalam diagram sequence, setiap object hanya memiliki garis yang digambarkan garis putus-putus ke bawah. Pesan antar object digambarkan dengan anak panah dari object yang mengirimkan pesan ke object yang menerima pesan.
main()
:Cash Register
:Barang
Inisialisasi( ) InitTabel( )
Gambar 2.4 Sequence diagram untuk Inisialisasi cash register
11/12/2009 07:09:39
Page - 26 - of 48
main()
:Cash Register
:Barang
:Penjualan
EntryJual( )
ketem u=searchBarang( kode)
getNamaBarang( ) getHarga( ) SubTotal( ) getHarga( ) RekamJual(kode,qty)
Gambar 2.5 Sequence diagram untuk Pencatatan transaksi penjualan
main()
:CashRegister EntryBayar( )
:Barang
:Penjualan
:Pembayaran
totaljml=Total( )
ketem u=searchBarang(kode )
getHarga( ) EnterBayar(totaljml)
RekamJual(jumlah)
Gambar 2.6 Sequence diagram untuk Pencatatan transaksi pembayaran
11/12/2009 07:09:39
Page - 27 - of 48
main()
:CashRegister
:Barang
CetekStruk( )
ketemu=searchBarang( kode)
getNamaBarang( ) getHarga( )
Gambar 2.7 Sequence diagram untuk pencetakkan struk
1.2.3
Collaboration Diagram Collaboration Diagram merupakan cara alternatif untuk menggambarkan skenario dari sistem. Diagram ini menggambarkan interaksi object yang diatur object sekelilingnya dan hubungan antara setiap object dengan object yang lainnya. Collaboration diagram berisi : Object yang digambarkan dengan segiempat. Hubungan antara object yang digambarkan dengan garis penghubung. Pesan yang digambarkan dengan teks dan panah dari object yang mengirim pesan ke penerima pesan.
1: Inisialisasi ( )
main() : <Process Name>
:Cash Register : <Process Name>
2: InitT abel( )
:Barang : <Process Name>
Gambar 2.8 Collaboration diagram use case cash register
11/12/2009 07:09:39
Page - 28 - of 48
1: EntryJual( )
2: ketemu=searchBarang( kode) 3: getNamaBarang( ) 4: getHarga( )
main()
:Cash Register : <Process Name>
6: getHarga( )
5: SubT otal( ) 7: RekamJual(kode,qty)
:Penjualan : <Process Name>
Gambar 2.9 Collaboration diagram use case Pencatatan transaksi penjualan
1: EntryBayar( )
main()
:CashRegister : <Process Name>
2: totalj ml=Total( ) 5: EnterBayar(totalj ml)
3: ketemu=searchBarang(kode ) 4: getHarga( )
:Penjualan : <Process Name>

6: RekamJual(j umlah)
:Pembayaran : <Process Name>
Gambar 2.10 Collaboration diagram use case Pencatatan transaksi pembayaran
1: CetekStruk( )
main()
:CashRegister : <Process Name>

2: ketemu=searchBarang( kode) 3: getNamaBarang( ) 4: getHarga( )
Gambar 2.11 Collaboration diagram use case pencetakkan struk

1.2.4
Perbedaan Sequence Diagram dengan Collaboration Diagram Sequence Diagram memberikan cara untuk melihat skenario dari sistem berdasarkan waktu (apa yang terjadi pertama kali, apa yang terjadi selanjutnya). User akan lebih mudah membaca dan mengerti tipe diagram ini. Karenanya, sangat berguna pada fase analisis awal. Sedangkan Collaboration Diagram cenderung untuk memberikan gambaran besar dari skenario selama kolaborasi disusun dari object sekelilingnya dan hubungan antar object yang satu dengan lainnya. Diagram ini akan nampak digunakan pada pengembangan tahap desain ketika kita merancang implementasi dari hubungan.
11/12/2009 07:09:39
Page - 30 - of 48
3 Class Diagram
3.1 Definisi Object dan Class
Object adalah gambaran dari entity, baik dunia nyata atau konsep dengan batasanbatasan dan pengertian yang tepat. Objek bisa mewakili sesuatu yang nyata seperti komputer,mobil atau dapat berupa konsep seperti proses kimia, transaksi bank, permintaan pembelian, dll. Setiap objek dalam sistem memiliki tiga karakteristik yaitu State(Status), Behaviour(Sifat) dan Indentity(identitas). Class adalah deskripsi sekelompok objek dari property(atribut), sifat (operasi), relasi antar objek dan sematik yang umum. Class merupakan template untuk membentuk objek. Setiap objek merupakan contoh dari beberapa class dan objeck tidak dapat menjadi contoh lebih dari satu class. Penamaan Class menggunakan kata benda tunggal yang merupakan abstraksi yang terbaik. Pada UML Class digambarkan dengan segi empat yang dibagi. Bagian atas merupakan nama dari class. Bagian yang tengah merupakan struktur dari class(atribut) dan bagian bawah merupakan sifat dari class(operasi).
3.2 State, Behaviour dan Identify

Status (State) dari object adalah satu kondisi yang mungkin ada. Status dari object akan berubah setiap waktu dan ditentukan oleh sejumlah property (atribut) dengan nilai dari property, ditambah relasi object dengan object lainnya. Sifat (Behaviour) menentukan bagaimana object merespon permintaan dari object lain dan melambangkan setiap hal yang dapat dilakukan. Sifat ini diimplementasikan dengan sejumlah operasi untuk object. Identitas (Identify) artinya setiap object yang unik Pada UML. Object digambarkan dengan segiempat dan nama dari object diberi garis bawah. Contoh : <<entity>> Informasi Mahasiswa
Gambar 3.1 Class dengan stereotype

Rational Objectory Process menyarankan untuk menemukan class-class dalam sistem yang sedang dibangun dengan mencari class : boundary, control dan entity. Ketiga stereotypes ini menggambarkan sebuah sudut pandang model-view-controller sehingga membuat analis dapat membagi sistem dengan memisahkan sudut pandang dari domain dari control yang dibutuhkan oleh sistem. Karena proses analisa dan desain adalah iterasi, daftar class akan berubah sesuai waktu. Class awal mungkin tidak akan menjadi class yang akan diimplementasikan. Sehingga kandidat class sering digunakan untuk menggambarkan himpunan awal dari class yang ditemukan pada sistem. 1. Entity Class Entity class memodelkan informasi dan operasi yang biasanya berumur panjang/lama. Tipe class ini menggambarkan entitas dunia nyata atau entitas yang dibutuhkan untuk melakukan tugas internal sistem.Mereka biasanya tidak terikat oleh komunikasi antara sistem dengan lingkungannya. Kebanyakan, mereka tidak terikat oleh aplikasi, artinya mereka dapat digunakan lebih dari satu aplikasi. Entity class biasanya merupakan class yang dibutuhkan sistem untuk menyelesaikan beberapa kewajiban. Entity class biasanya ditemukan dalam phasa eloborasi. Entity class sering disebut domain class karena mereka berhubungan dengan dunia nyata. 2. Boundary Class Boundary class menangani komunikasi antara lingkungan sistem dan kedalam sistem. Mereka dapat menjamin interface ke pengguna atau sistem lain ( misalnya, interface ke actor ). Boundary class digunakan untuk memodelkan sistem interface. Setiap pasangan actor/skenario ( sebuah instance dari use case, ) diperiksa untuk menemukan boundary class. Boundary class yang ditemukan pada phasa elaboration biasanya pada high level. Sebagai contoh, anda sedang mendesign windows tetapi anda tidak memodelkan semua dialog box dan tombol. Anda hanya sedang mendokumentasikan kebutuhan antar muka, bukan mengimplementasikan antar mukanya. Pada saat design, class-class ini diperbaiki untuk dipertimbangkan memilih antar mukanya 3. Control Class Control class memodelkan urutan kelakukan ( behavior ) khusus untuk satu atau lebih use case. Pada awal phasa Elaboration, sebuah control class ditambahkan
untuk setiap pasangan actor atau use case. Control class bertanggung jawab untuk aliran kejadian-kejadian dalam use case. Penambahan control class per pasangan actor atau use case hanya merupakan initial cut, pada analisa dan design, control class mungkin dihilangkan, dipecah atau digabung. Untuk merancang class diagram, Rational Unified Process yang merupakan hasil pengembangan dari Rational Objectory Process menggunakan Use case realization yang menggambarkan bagaimana realisasi dari setiap use case yang ada pada use case model. Untuk menggambarkan bagaimana realisasi dari suatu use case dapat menggunakan beberapa diagram, diantaranya adalah Class Diagram owned by Use Case Realization serta Interaction Diagram. Untuk menggambarkan use case realization disini akan menggunakan class diagram owned by use case realization. Setiap use case yang ada dibreakdown sehingga akan dapat terlihat entitas-entitas apa saja yang terlibat dalam merealisasikan sebuah use case. Entitas-entitas ini akan menjadi kandidat kelas dalam Class Diagram.
3.3 Menambahkan Attribut dan Operasi pada Class

Sebuah class mempunyai sekumpulan kewajiban yang menentukan kelakukan object-object dalam class. Kewajiban ini diwujudkan dalam operasi-operasi yang didefinisikan untuk class tersebut. Struktur dari suatu class didefinisikan oleh atributatribut class tersebut. Setiap atribut adalah definisi data yang atribut dalam class 3.3.1 Attribut Attribut adalah salah satu property yang dimiliki oleh class yang menggambarkan batasan dari nilai yang dapat dimiliki oleh property tersebut. Sebuah class mungkin memiliki beberapa atribut atau tidak memilikinya sama sekali. Sebuah atribut merepresentasikan beberapa property dari sesuatu yang kita modelkan, yang dibagi dengan semua object dari semua class yang ada. Contohnya, setiap tembok memiliki tinggi, lebar dan ketebalan. Atribut dalam implementasinya akan digambarkan sebagai sebuah daftar (list) yang diletakkan pada kotak dibawah pada object dalam classnya. Object yang didefinisikan dalam class mempunyai sebuah nilai untuk setiap
11/12/2009 07:09:39
Page - 33 - of 48
nama class.Untuk penulisan nama class, biasanya huruf pertama dari tiap kata merupakan huruf kapital, terkecuali untuk huruf awal. Sebagai contohnya : birthDate.
Gambar 3.2 Contoh atribut dari class Untuk lebih lanjut kita pun bisa menspesifikasikan atribut beserta jenis data yang kita gunakan untuk atribut tersebut.
Gambar 3.3 Contoh lain dari atribut 3.3.2 Operasi Sebuah operasi adalah sebuah implementasi dari layanan yang dapat diminta dari beberapa object dari class, yang mempengaruhi behaviour. Dengan kata lain operasi adalah abstraksi dari segala sesuatu yang dapat kita lakukan pada sebuah object dan ia berlaku untuk semua object yang terdapat dalam class tersebut. Class mungkin memiliki beberapa operasi atau tanpa operasi sama sekali.contohnya adalah sebuah class kotak dapat dipindahkan, diperbesar atau diperkecil. Biasanya (namun tidak selalu), memanggil operasi pada sebuah object akan mengubah data atau kondisi dari object tersebut. Operasi ini dalam implementasinya digambarkan dibawah atribut dari sebuah class.
Gambar 3.4 Contoh dari operasi
11/12/2009 07:09:39
Page - 34 - of 48
Untuk lebih lanjut kita pun bisa menspesifikasikan semua parameter yang terlibat dalam operasi tersebut.
Gambar 3.5 Contoh lain dari operasi
3.3.3 Pengorganisasian attribut dan operasi. Ketika menggambarkan sebuah class kita tidak perlu menampilkan seluruh atribut atau operasi. Karena dalam sebagian besar kasus kita tidak dapat menampilkannya dalam sebuah gambar, karena telalu banyaknya atribut atau operasinya, bahkan terkadang tidak perlu karena kurang relevannya atribut atau operasi tersebut untuk ditampilkan. Sehingga kita dapat menampilkan hanya sebagian atau bahkan tidak sama sekali atribut dan operasinya. Kosongnya kotak tempat pengisian bukan berarti tidak ada. Karena itu kita dapat menambahkan tanda () pada akhir daftar yang menunjukkan bahwa masih ada atribut atau operasi yang lain.
3.4 Interaksi Antar Object 3.4.1 Object Relationships 3.4.1.1 Association Relationships Association adalah hubungan semantik bidirectional diantara class-class. Ini bukan aliran data sebagaimana pada pemodelan desain dan analisa terstruktur, data diperbolehkan mengalir dari kedua arah. Asosiasi diantara class-class artinya ada hubungan antara object-object pada class-class yang berhubungan. Banyaknya object yang terhubung tergantung dengan multiplicity pada asosiasi, yang akan dibahas nanti.
Gambar 3.6 Relasi asociation

3.4.1.2 Aggregation Relationships Aggregation relationships adalah bentuk khusus dari asosiasi dimana induk terhubung dengan bagian-bagiannya. Notasi UML untuk relasi agregasi adalah sebuah asosiasi dengan diamond putih melekat pada class yang menyatakan induk. Contoh, Company mungkin terdiri dari sejumlah Department.
Gambar 3.7 Relasi aggregation Pertanyaan-pertanyaan di bawah dapat digunakan untuk menentukan apakah asosiasi seharusnya menjadi agregasi: 1. Apakah klausa has-a ( bagian dari ) digunakan untuk menggambarkan relasi? 2. Apakah beberapa operasi di induk secara otomatis dapat dipakai pada bagian bagiannya? Sebagai contoh, delete sebuah Company, maka akan men-delete Department-nya.
Penamaan Relationship Sebuah asosiasi dapat diberi nama. Biasanya digunakan kata kerja aktif atau klausa kata kerja dengan cara pembacaan dari kiri ke kanan atau atas ke bawah. Agregasi tidak diberi nama karena agregasi menggunakan kata mempunyai atau terdiri.
Indikator Multiplicity Walaupun multiplicity ditentukan untuk class, multiplicity menentukan banyaknya object yang terlibat dalam relasi. Multiplicity menentukan banyaknya object yang terhubung satu dengan yang lainnya. Indikator multiplicity terdapat pada masing-masing akhir garis relasi, baik pada asosiasi maupun agregasi. Beberapa contoh multiplicity adalah : 1 0..* Tepat satu Nol atau lebih
11/12/2009 07:09:39
Page - 36 - of 48
1..* 0..1 5..8
Satu atau lebih Nol atau satu range 5 s.d. 8
4..6,9 range 4 s.d. 6 dan 9
Gambar 3.8 Multiplicity Sebuah object Nasabah berelasi dengan tepat satu object Bank, misal : Irma berelasi dengan Bank Dana. Sebuah object Bank berelasi dengan satu atau tak hingga nasabah. Misal : Bank Dana berelasi dengan Irma, Ilham, Norman, dsb.
3.4.1.3 Reflexive Relationships Multiple object pada class yang sama dapat saling berkomunikasi satu dengan yang lainnya. Hal ini ditunjukkan pada class diagram sebagai reflexive association atau aggregation. Penamaan role lebih disukai untuk digunakan pada reflexive relationships daripada penamaan association relationship.
Gambar 3.9 Relasi reflexive
11/12/2009 07:09:39
Page - 37 - of 48
Menemukan Relationships Untuk menemukan relationships class-class yang ada dapat dilakukan dengan memeriksa skenario dan pertukaran message diantara class-class yang ada. Pada tahap analisa, dua relationship yang ditemukan adalah asosiasi dan agregasi. Dikarenakan metode yang digunakan merupakan iterative maka relationship akan berubah seiring dengan fase analisis dan desain.
3.4.2 Inheritance Inheritance merupakan kemampuan untuk membuat hierarki yang terdiri atas classclass, dimana terdapat struktur dan atau behavior (kelakuan) diantara classclass. Istilah superclass digunakan oleh class yang menyimpan informasi umum. Keturunan dari superclass disebut subclass. Sebuah subclass mewarisi semua atribut, operasi dan relationship yang dipunyai oleh semua superclasssuperclassnya. Inheritance disebut juga hierarki is-a (adalah sebuah) atau kind -of (sejenis). Subclass dapat menggunakan atribut dan operasi tambahan yang hanya berlaku pada level hierarkinya. Karena inheritance relationship bukan sebuah relationship diantara object yang berbeda, maka relationship ini tidak pernah diberi nama, penamaan role juga tidak digunakan dan multiplicity tidak digunakan. Terdapat dua cara untuk menemukan inheritance, yaitu generalization dan specialization . 3.4.2.1 Generalization Generalization menjamin kemampuan untuk membuat superclass yang melingkupi struktur dan behaviour yang umum pada beberapa class dibawahnya (subclass).
11/12/2009 07:09:39
Page - 38 - of 48
Gambar 3.10 Contoh generalization
3.4.2.2 Specialization Specialization menjamin kemampuan untuk membuat subclass yang berfungsi untuk menambah atribut dan operasi superclass. Operasi pada superclass dapat di-override oleh subclass (konsep polymorphism). Tetapi, sebuah subclass seharusnya tidak boleh membatasi sebuah operasi yang didefinisikan dalam superclass-nya, dengan kata lain subclass seharsunya tidak boleh menyediakan lebih sedikit behaviour atau struktur daripada superclass-nya.
Gambar 3.11 Inheritance tree
11/12/2009 07:09:39
Page - 39 - of 48
Berikut ini adalah contoh class diagram yang telah jadi
CashRegister
NoCr IdKasir EntryJual() EntryBanyak() CetakStruk()
Penjualan
mencatat Banyak dilunasi-oleh
Pembayaran
Total
1..*
RekamJual ()
RekamBayar()
1
untuk
1..*
Barang
KodeBrg NamaBrg Harga InitTable() SearchBrg()
11/12/2009 07:09:39
Page - 40 - of 48
4 State Transition Diagram dan Activity Diagram

4.1 State Transition Diagram
4.1.1 Pengertian Use case dan skenario menyediakan cara untuk menggambarkan kelakuan sistem yakni interaksi antara object-object di dalam sistem. Kadang-kadang diperlukan untuk melihat kelakuan di dalam object. State transition diagram menunjukkan state-state dari object tunggal, event-event atau pesan yang menyebabkan transisi dari satu state ke state yang lain, dan action yang merupakan hasil dari perubahan sebuah state. State transition diagram tidak akan dibuat untuk setiap class di sistem. State transition diagram hanya dibuat untuk class yang berkelakuan dinamis. Interaction diagram dapat dipelajari untuk menentukan dynamic object di sis tem, yaitu object yang menerima dan mengirim beberapa pesan. State transition diagram juga sangat berguna untuk meneliti kelakuan dari sebuah kumpulan whole class dan control class.
4.1.2 Bagian-bagian State Transition Diagram 4.1.2.1 States State adalah sebuah kondisi selama kehidupan sebuah object ketika object memenuhi beberapa kondisi, melakukan beberapa action, atau menunggu sebuah event. State dari sebuah object dapat dikarakteristikkan oleh nilai dari satu atau lebih atributatribut dari class. State-state dari sebuah object ditemukan dengan pengujian/pemeriksaan atributatribut dan hubungan-hubungan dari object. Notasi UML untuk state adalah empat persegipanjang/bujur sangkar dengan ujung yang dibulatkan, seperti ditunjukkan pada gambar 8.1.
Gambar 4.1 Notasi UML untuk state
11/12/2009 07:09:39
Page - 41 - of 48
State transition diagram meliputi seluruh pesan dari object yang dapat mengirim dan menerima. Skenario merepresentasikan satu jalur yang melewati sebuah state transition diagram. Jarak waktu antara dua pesan yang dikirim oleh sebuah object merepresentasikan sebuah state . Oleh karena itu, sequence diagram ditentukan untuk menemukan state-state sebuah object (lihat pada ruang antara garis-garis yang merepresentasikan pesan-pesan diterima oleh object).
4.1.2.2 State Transitions State transition merepresentasikan sebuah perubahan dari state awal ke sebuah state berikutnya (yang mungkin dapat sama dengan state awal). Sebuah action dapat menyertai sebuah state transition. Ada dua cara untuk membuat transisi sebuah state otomatis dan tidak otomatis. State transition yang otomatis terjadi ketika activity dari state awal telah lengkap tidak ada event yang terasosiasi dengan state transition yang belum bernama. State transition yang tidak otomatis disebabkan oleh sebuah event ternama (salah satu dari object atau dari luar sistem). Kedua tipe dari state transition dipertimbangkan untuk membuat waktu nol dan tidak dapat diinterupsi. Sebuah state transition direpresentasikan oleh sebuah panah yang menunjuk dari state awal ke state berikutnya.
4.1.2.3 Special States Ada dua state khusus yang ditambahkan di state transition diagram. Pertama adalah start state. Masing-masing diagram harus mempunyai satu dan hanya satu start state ketika object mulai dibuat. Notasi UML untuk start state ditunjukkan gambar 8.2. khusus berikutnya adalah stop state. Sebuah object boleh mempunyai banyak stop state. Notasi UML untuk stop state ditunjukkan gambar 8.2.
11/12/2009 07:09:39
Page - 42 - of 48
Gambar 4.2 Notasi UML untuk start dan stop state
4.1.2.4 State Transition Details Sebuah state transition dapat mempunyai sebuah action dan/atau sebuah kondisi penjaga (guard condition) yang terasosiasi dengannnya, dan mungkin juga memunculkan sebuah event. Sebuah action adalah kelakuan yang terjadi ketika state transition terjadi. Sebuah event adalah pesan yang dikirim ke object lain di sistem. Kondisi penjaga adalah ekspresi boolean dari nilai atribut-atribut yang mengijinkan sebuah state transition hanya jika kondisinya benar. Kedua action dan penja ga adalah kelakuan dari object dan secara tipikal menjadi operasi. Seringkali operasi-operasi ini adalah tersendiri hal itu, mereka digunakan hanya oleh object dirinya sendiri. Notasi UML untuk state transition details ditunjukkan gambar 8.3.
Gambar 4.3 Notasi UML untuk state transition detail
11/12/2009 07:09:39
Page - 43 - of 48
4.1.2.5 State Details Action-action yang mengiringi seluruh state transition ke sebuah state mungkin ditempatkan sebagai sebuah entry action dalam state. Demikian juga, action-action yang mengiringi seluruh state transition keluar dari sebuah state mungkin ditempatkan sebagai sebuah aksi keluar dalam state. Kelakuan yang terjadi dalam state disebut activity. Sebuah activity memulai ketika state dimasukkan dan salah satu dari melengkapi atau diinterupsi oleh sebuah state transition yang keluar. Kelakuan mungkin sebuah action yang sederhana, atau kelakuan merupakan sebuah event yang terkirim ke object lain. Sesuai dengan action-action dan guard -guard, kelakuan ini secara tipikal dipetakan ke operasi-operasi dalam object. Notasi UML untuk state detailed information ditunjukkan gambar 8.4.
Gambar 4.4 State details
Start
Waiting for item code
Bacode scanning
Show data item
Counting Subtotal price
Enter item amount
Waiting for item amount
Counting total price
End
Gambar 4.5 State Diagram untuk Cash Register
11/12/2009 07:09:39
Page - 44 - of 48
4.2 Activity Diagram

Activity diagram memodelkan workflow proses bisnis dan urutan aktivitas dalam sebuah proses. Diagram ini sangat mirip dengan flowchart karena memodelkan workflow dari satu aktivitas ke aktivitas lainnya atau dari aktivitas ke status. Menguntungkan untuk membuat activity diagram pada awal pemodelan proses untuk membantu memahami keseluruhan proses. Activity diagram juga bermanfaat untuk menggambarkan parallel behaviour atau menggambarkan interaksi antara beberapa use case.
Elemen-eleman activity diagram : 1. Status start (mulai) dan end (akhir) 2. Aktifitas yang merepresentasikan sebuah langkah dalam workflow. 3. Transition menunjukkan terjadinya perubahan status aktivitas (Transitions show what state follows another). 4. Keputusan yang menunjukkan alternatif dalam workflow. 5. Synchronization bars yang menunjukkan subflow parallel. Synchronization bars dapat digunakan untuk menunjukkan concurent threads pada workflow proses bisnis. 6. Swimlanes yang merepresentasikan role bisnis yang bertanggung jawab pada aktivitas yang berjalan.
11/12/2009 07:09:39
Page - 45 - of 48
:Kasir
:CashRegister
:Barang
:Penj ualan
:Pembayaran
Entry ID dan Password
(id,password)
Baca Id dan Password
( user not validated )
verify ID and password ( user validated )
Display Form Penjualan SignalType=request kode item

Entry Kode Item
kode item
Baca Kode Item
kode item
verify kode item
SignalType=request kode item
Display error message
(unknown kode item)
(indentified kode item)

SignalType=request jumlah item Display Item Specification
Entry Jumlah
jumlah,kode item
Update Jumlah Barang
Hitung Subtotal Item
Display Subtotal and Total
Hitung Total Penjualan
subtotal,total
Entry Pembayaran
SignalType=request pembayaran Display Form Pembayaran
SaveTransaksi Penjualan
pembayaran
Baca Pembayaran
pembayaran
Hitung Kembalian
Save Pemasukan
Display Kembalian
Print Struk
Gambar 4.6 Activity diagram untuk Cash Register
11/12/2009 07:09:39
Page - 46 - of 48
5 Component Diagram dan Deployment Diagram
5.1 Component Diagram

Pengertian Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya. Komponen piranti lunak adalah modul berisi tables, files, documents, 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. Component dan Class mempunyai beberapa persamaan, diantaranya samasama mempunyai nama, bisa terdapat hubungan dependency, generalization, dan association, bisa mempunyai instances,dll.
Gambar 5.1 Component diagram Cash Register
11/12/2009 07:09:39
Page - 47 - of 48
5.2 Deployment Diagram

Pengertian
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.
Server
-TCP/IP
Network * *
POST
Gambar 5.2 Deployment diagram untuk Cash Register
11/12/2009 07:09:39
Page - 48 - of 48

Introduchvbhvbtion To Um L

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Introduchvbhvbtion To Um L

Diunggah oleh

Hak Cipta:

Format Tersedia

Del Polytechnic of Informatics

Introduction to UML A. UML

a. Sejarah Singkat UML

Del Polytechnic of Informatics

Del Polytechnic of Informatics

b. Gambaran dari UML

Del Polytechnic of Informatics

Del Polytechnic of Informatics

c. Area Penggunaan UML

d. Diagram dalam UML

Del Polytechnic of Informatics

Del Polytechnic of Informatics

e. Tool yang mendukung UML

Del Polytechnic of Informatics

Del Polytechnic of Informatics

Del Polytechnic of Informatics

Del Polytechnic of Informatics

Del Polytechnic of Informatics

Del Polytechnic of Informatics

Del Polytechnic of Informatics

Del Polytechnic of Informatics

Del Polytechnic of Informatics

1 Use Case Diagram

1.1 Pengertian Use Case Diagram

1.2 Komponen Pembentuk Use Case Diagram

Del Polytechnic of Informatics

Del Polytechnic of Informatics

Gambar 1.2 Use Case

1.3 Use Case Diagram Dalam UML

Del Polytechnic of Informatics

Inisialisasi Cash Register

Pencatatan Transaksi Penjualan

Pencatatan Transaksi Pembayaran

Del Polytechnic of Informatics

Skenario use case

Actor 1. Kasir memasukkan nomor kas register dan identitas kasir

Del Polytechnic of Informatics

Nomor Nama use case Actors Type Tujuan Deskripsi 1. 2. 3. 4. 5. :

Del Polytechnic of Informatics

Del Polytechnic of Informatics

2 Candidate Class dan Interaction Diagram

Gambar 2.2 Candidate Class

Del Polytechnic of Informatics

Gambar 2.1 Class

Del Polytechnic of Informatics

2.2 Interaction Diagram

Del Polytechnic of Informatics

Gambar 2.4 Sequence diagram untuk Inisialisasi cash register

Del Polytechnic of Informatics

getNamaBarang( ) getHarga( ) SubTotal( ) getHarga( ) RekamJual(kode,qty)

Gambar 2.5 Sequence diagram untuk Pencatatan transaksi penjualan

Gambar 2.6 Sequence diagram untuk Pencatatan transaksi pembayaran

Del Polytechnic of Informatics

Gambar 2.7 Sequence diagram untuk pencetakkan struk

main() : <Process Name>

:Cash Register : <Process Name>

:Barang : <Process Name>

Gambar 2.8 Collaboration diagram use case cash register

Del Polytechnic of Informatics

2: ketemu=searchBarang( kode) 3: getNamaBarang( ) 4: getHarga( )

:Cash Register : <Process Name>

:Barang : <Process Name>

5: SubT otal( ) 7: RekamJual(kode,qty)