Selasa, 29 Maret 2011

Pengenalan UML

Pengenalan UML suatu bahasa pemodelan umum untuk pengembangan sistem PT Rackindo Setara Perkasa

agus sarizal
hape(087890762025)
0 8 PAY


Abstrak

Unified Modeling Language (UML) adalah bahasa pemodelan umum yang digunakan untuk melakukan spesifikasi, visualisasi, konstruksi dan dokumentasi artifak dari software system. UML bukanlah sebuah standar proses pengembangan dalam metode pengembangan sistem tertentu, namun pada umumnya UML dipakai dalam memodelkan sistem yang dibangun berbasiskan objek. Pemodelan (modeling) adalah proses merancang piranti lunak sebelum melakukan pengkodean (coding). Model piranti lunak dapat dianalogikan seperti pembuatan blueprint pada pembangunan gedung. Membuat model dari sebuah sistem yang kompleks sangatlah penting karena kita tidak dapat memahami sistem semacam itu secara menyeluruh. Semakin komplek sebuah sistem, semakin penting pula penggunaan teknik pemodelan yang baik.

Kata kunci: UML, modeling, software system .

PENDAHULUAN

Latar Belakang
Saat ini piranti lunak semakin luas dan besar lingkupnya, sehingga tidak bisa lagi dibuat asal-asalan. Piranti lunak saat ini seharusnya dirancang dengan memperhatikan hal-hal seperti scalability, security, dan eksekusi yang robust walaupun dalam kondisi yang sulit. Selain itu arsitekturnya harus didefinisikan dengan jelas, agar bug mudah ditemukan dan diperbaiki, bahkan oleh orang lain selain programmer aslinya. Keuntungan lain dari perencanaan arsitektur yang matang adalah dimungkinkannya penggunaan kembali modul atau komponen untuk aplikasi piranti lunak lain yang membutuhkan fungsionalitas yang sama.
Pemodelan (modeling) adalah proses merancang piranti lunak sebelum melakukan pengkodean (coding). Model piranti lunak dapat dianalogikan seperti pembuatan blueprint pada pembangunan gedung. Membuat model dari sebuah sistem yang kompleks sangatlah penting karena kita tidak dapat memahami sistem semacam itu secara menyeluruh. Semakin komplek sebuah sistem, semakin penting pula penggunaan teknik pemodelan yang baik.
Dengan menggunakan model, diharapkan pengembangan piranti lunak dapat memenuhi semua kebutuhan pengguna dengan lengkap dan tepat, termasuk faktor-faktor seperti scalability, robustness, security, dan sebagainya.
Kesuksesan suatu pemodelan piranti lunak ditentukan oleh tiga unsur, yang kemudian terkenal dengan sebuan segitiga sukses (the triangle for success). Ketiga unsur tersebut adalah metode pemodelan (notation), proses (process) dan tool yang digunakan.


Gambar 1 The triangle of success

Memahami notasi pemodelan tanpa mengetahui cara pemakaian yang sebenarnya (proses) akan membuat proyek gagal. Dan pemahaman terhadap metode pemodelan dan proses disempurnakan dengan penggunaan tool yang tepat.

Sejarah UML sendiri cukup panjang. Sampai era tahun 1990 seperti kita ketahui puluhan metodologi pemodelan berorientasi objek telah bermunculan di dunia. Diantaranya adalah: metodologi booch [1], metodologi coad [2], metodologi OOSE [3], metodologi OMT [4], metodologi shlaer-mellor [5], metodologi wirfs-brock [6], dsb. Masa itu terkenal dengan masa perang metodologi (method war) dalam pendesainan berorientasi objek. Masing-masing metodologi membawa notasi sendiri-sendiri, yang mengakibatkan timbul masalah baru apabila kita bekerjasama dengan group/perusahaan lain yang menggunakan metodologi yang berlainan. Dimulai pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson, yang merupakan tiga tokoh yang boleh dikata metodologinya banyak digunakan mempelopori usaha untuk penyatuan metodologi pendesainan berorientasi objek. Pada tahun 1995 direlease draft pertama dari UML (versi 0.8). Sejak tahun 1996 pengembangan tersebut dikoordinasikan oleh Object Management Group. Tahun 1997 UML versi 1.1 muncul, dan saat ini versi terbaru adalah versi 1.5 yang dirilis bulan Maret 2003. Booch, Rumbaugh dan Jacobson menyusun tiga buku serial tentang UML pada tahun 1999 [7] [8] [9]. Sejak saat itulah UML telah menjelma menjadi standar bahasa pemodelan untuk aplikasi berorientasi objek.

Gambar 2 Asal usul UML

Ruang Lingkup
Ruang lingkup dari pembahasan ini berkaitan dengan pengenalan UML serta membahas tentang berbagai macam diagram yang ada dalam UML. Dimana diagram tersebut merupakan sebuah artifak dalam pengembangan sistem, jumlah diagram tersebut ada 8 buah, yaitu Class diagram / Object diagram, Statechart diagram, Component diagram, Deployment diagram, Use case diagram, Sequence diagram, Collaboration diagram, Activity diagram.

Tujuan dan Manfaat
Tujuan
Tujuan dari penulisan paper ini adalah untuk menjelaskan UML sebagai suatu bahasa permodelan modern pengembangan piranti lunak yang sering dikaitkan erat dengan OOAD. Serta menjelaskan tujuan dari UML itu sendiri bagi pembaca paper ini.

Manfaat
Manfaat yang didapat dari penulisan paper ini adalah sebagai berikut :
• Mengetahui latar belakang dan sejarah pengembangan UML sampai menjadi sebuah bahasa permodelan modern yang paling populer.
• Membantu para pembaca untuk mengetahui secara detil baik deskripsi sampai ke notasi dari berbagai diagram yang ada dalam UML.
• Serta memberikan gambaran sederhana atas bahasa permodelan pengembangan piranti lunak, yang dapat menjadi acuan untuk melakukan pengembangan piranti lunak.

Metodologi Penulisan
Metodologi penulisan yang digunakan didalam penulisan paper ini yaitu:
• Metode pengumpulan data
Metode yang digunakan untuk mengumpulkan data untuk penulisan paper adalah studi pustaka. Studi pustaka ini dilakukan dengan cara membaca dan meringkas literatur yang ada dan mengumpulkan informasi yang berhubungan dengan topik paper ini melalui internet.

LANDASAN TEORI
Unified Modeling Language (UML) adalah keluarga notasi grafis yang didukung oleh meta-model tunggal, yang membantu pendeskripsian dan desain sistem perangkat lunak, khususnya sistem yang dibangun menggunakan pemrograman berorientasi objek (OO). Definisi ini merupakan definisi yang sederhana. Pada kenyataannya, pendapat orang – orang tentang UML berbeda satu sama lain. Hal ini dikarenakan oleh sejarahnya sendiri dan oleh perbedaan persepsi tentang apa yang membuat sebuah proses rancang – bangun perangkat lunak efektif. Fowler (2004,p1)

Unified Modeling Language (UML) merupakan strandar yang relatif terbuka yang dikontrol oleh Object Management Group (OMG), sebuah konsorsium terbuka yang terdiri dari banyak perusahaan. OMG dibentuk untuk membuat standar – standar yang mendukung interoperabilitas, khusunya interoperabilitas sistem berorientasi objek. OMG mungkin lebih dikenal dengan standar – standar COBRA (Common Object Request Broker Architecture). Fowler (2004,p1-2)

UML lahir dari penggabungan banyak bahasa permodelan grafis berorientasi objek yang berkembang pesat pada akhir 1980-an dan awal 1990-an. Sejak kehadirannya pada tahun 1997, UML menghancurkan menara Babel tersebut menjadi sejarah. Fowler (2004,p2)

PEMBAHASAN

Langkah-langkah penggunaan UML
Berikut ini adalah tips pengembangan piranti lunak dengan menggunakan UML:
1. Buatlah daftar business process dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul.
2. Petakan use case untuk tiap business process untuk mendefinisikan dengan tepat fungsionalitas yang harus disediakan oleh sistem. Kemudian perhalus use case diagram dan lengkapi dengan requirement, constraints dan catatan-catatan lain.
3. Buatlah deployment diagram secara kasar untuk mendefinisikan arsitektur fisik sistem.
4. Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus disediakan oleh sistem.
5. Berdasarkan use case diagram, mulailah membuat activity diagram.
6. Definisikan objek-objek level atas (package atau domain) dan buatlah sequence dan/atau collaboration diagram untuk tiap alir pekerjaan. Jika sebuah use case memiliki kemungkinan alir normal dan error, buatlah satu diagram untuk masing-masing alir.
7. Buatlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk menjalankan skenario use case.
8. Berdasarkan model-model yang sudah ada, buatlah class diagram. Setiap package atau domain dipecah menjadi hirarki class lengkap dengan atribut dan metodanya. Akan lebih baik jika untuk setiap class dibuat unit test untuk menguji fungsionalitas class dan interaksi dengan class lain.
9. Setelah class diagram dibuat, kita dapat melihat kemungkinan pengelompokan class menjadi komponen-komponen. Karena itu buatlah component diagram pada tahap ini. Juga, definisikan tes integrasi untuk setiap komponen meyakinkan ia berinteraksi dengan baik.

10. Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan dan requirement piranti lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node.
11. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan :
• Pendekatan use case, dengan meng-assign setiap use case kepada tim pengembang tertentu untuk mengembangkan unit code yang lengkap dengan tes.
• Pendekatan komponen, yaitu meng-assign setiap komponen kepada tim pengembang tertentu.
12. Lakukan uji modul dan uji integrasi serta perbaiki model berserta codenya. Model harus selalu sesuai dengan code yang aktual.
13. Piranti lunak siap dirilis.

Tools yang mendukung UML
Saat ini banyak sekali tool pendesainan yang mendukung UML, baik itu tool komersial maupun opensource. Beberapa diantaranya adalah:
• Rational Rose (www.rational.com)
• Together (www.togethersoft.com)
• Object Domain (www.objectdomain.com)
• Jvision (www.object-insight.com)
• Objecteering (www.objecteering.com)
• MagicDraw (www.nomagic.com/magicdrawuml)
• Visual Object Modeller (www.visualobject.com)

UML terdiri dari diagram, notasi, konsep dan aturan yang digunakan dalam memodelkan sistem. Diagram UML terdiri dari 9 jenis diagram yang memiliki fungsi dan notasi masing-masing. Kesembilan diagram ini dapat dibagi menjadi 2 kategori, yaitu :
1. Diagram yang menggambarkan struktur yang statis dari sistem.
2. Diagram yang menggambarkan struktur yang dinamis dari system.

Diagram struktur statis dari sistem
Adalah diagram yang menggambarkan struktur hubungan statis dari elemen-elemen yang ada dalam sebuah model diantaranya class, package, dan relationship yang terjadi.

Class Diagram dan Object Diagram
Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain.
Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi).

Class memiliki tiga area pokok :
1. Nama (dan stereotype)
2. Atribut
3. Metoda

Atribut dan metoda dapat memiliki salah satu sifat berikut :
• Private, tidak dapat dipanggil dari luar class yang bersangkutan
• Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak- anak yang mewarisinya
• Public, dapat dipanggil oleh siapa saja.

Gambar 3 Notasi class

Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak yang hanya memiliki metoda. Interface tidak dapat langsung diinstansiasikan, tetapi harus diimplementasikan dahulu menjadi sebuah class. Dengan demikian interface mendukung resolusi metoda pada saat run-time.


Gambar 4 Notasi Interface class

Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi package. Kita juga dapat membuat diagram yang terdiri atas package.


Gambar 5 Package dari sebuah class


Pada object diagram digambarkan hubungan antar elemen dalam model, tapi dengan memakai objeknya, bukan class. Class ialah kumpulan dari objek-objek yang memiliki attribute, behaviour atau operation yang sama.
Class dan object di dalam tahapan design digambarkan dengan letak yang memiliki tiga bagian. Pada bagian atas diberi nama class atau object. Bagian tengah merupakan bagian yang berisi attribute yang dimiliki dan bagian bawah berisi operation.
Dalam class dan object diagram tersebut terdapat beberapa istilah-istilah, diantaranya yaitu :
• Association Link
Merupakan link yang mewakili hubungan antar dua objek. Association adalah hubungan antar class dan mewakili kelompok link.
• Multiplicity
Merupakan banyaknya hubungan yang mungkin terjadi antar class.
• Aggregation
Merupakan bentuk khusus dari association yang menggambarkan bahwa satu class merupakan bagian dari class lainnya, ”a part of”. Dalam beberapa kasus, satu class dapat terbagi menjadi beberapa class lagi.
• Generalization
Merupakan hubungan antara class induk (super class) dengan class anak (sub class). Hubungan yang terjadi adalah ”is a”. Pada hubungan generalisasi attribute dan behaviour yang terdapat pada super class akan diwarisi oleh sub class.

Berikut adalah contoh sebuah class diagram :

Gambar 6 Contoh Class diagram

Component Diagram
Component Diagram merupakan gambaran aspek fisik sistem berbasis objek dengan menunjukkan hubungan dan ketergantungan dalam serangkaian komponen. Menggambarkan komponen fisik software termasuk source code, run time (binary) code, executable file, table, library, dan dokumen. Meliputi komponen, interface, dependency, generalization, association, realization, notes, constraint, packages, subsystem dari sebuah model.
Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run time. Umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil. Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.
Diagram ini digunakan untuk memodelkan implementasi sistem yang sifatnya statis sehingga dapat mendukung untuk mengatur konfigurasi dari bagian sistem.

Berikut ini adalah sebuah contoh dari component diagram :


Gambar 7 Contoh Component diagram

Deployment diagram
Deployment diagram menggambarkan sumber fisik dalam sistem, termasuk node, komponen dan koneksi (model implementasi sistem yang statistik). Dalam hal ini meliputi topologi hardware yang dipakai sistem.
Deployment/physical diagram menggambarkan detail bagaimana komponen di-deploy dalam infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal. Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk men-deploy komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini.
Berikut adalah contoh dari Deployment diagram :


Gambar 8 Contoh Deployment diagram

Statechart diagram
Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram).
Dalam UML, state digambarkan berbentuk segiempat dengan sudut membulat dan memiliki nama sesuai kondisinya saat itu. Transisi antar state umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan sebagai akibat dari event tertentu dituliskan dengan diawali garis miring.
Titik awal dan akhir digambarkan berbentuk lingkaran berwarna penuh dan berwarna setengah.
Berikut adalah contoh dari Statechart diagram :

Gambar 9 Contoh Statechart diagram

Diagram struktur dinamis dari sistem
Adalah kumpulan diagram yang menggambarkan hubungan dinamis antara class yang berada dalam komponen model.
Use case diagram
Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya.
Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan system untuk melakukan pekerjaan-pekerjaan tertentu. Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang ada pada sistem.
Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali use case yang meng-include dieksekusi secara normal. Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common.
Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya sendiri. Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan spesialisasi dari yang lain.
Use case merupakan salah satu metode dalam analisis dan desain sistem berorientasi objek (Object Oriented Analysis and Design). Use case juga merupakan bagian dari UML (Unified Modelling Language). Use case modelling digunakan untuk mendokumentasikan system behaviour dan subsystem pada saat pengembangan sistem, termasuk di dalamnya fungsi internal suatu sistem (use case), pengguna sistem (user) dan hubungan interaksi antara keduanya (use case diagram).
Use case diwujudkan dalam bentuk diagram dengan beberapa notasi baku yang ditujukan untuk memudahkan kita melihat keseluruhan behaviour dari sebuah sistem. Use case tidak hanya digambarkan dalam bentuk diagram saja, namun diwujudkan pula dalam bentuk teks, yang dikenal dengan narrative use case, dimana proses yang ada dalam use case digambarkan dengan kata-kata sehingga menjadi lebih jelas.
Terdapat 3 bagian utama dalam use case modeling sebagaimana dijelaskan berikut ini :
• Actor
Actor sebagai perwujudan dari pengguna sistem, proses dan segala sesuatu yang berinteraksi dalam sistem tersebut. Actor tidak termasuk dalam sistem, tetapi dapat menggambarkan interaksi dari external user dengan sistem tersebut. Setiap actor berinteraksi dengan satu atau lebih use case dengan pertukaran pesan atau informasi.
• Use Case
Use case merupakan bagian dari sebuah sistem yang menyediakan sebuah fungsi atau tugas tertentu dan terdiri dari serangkaian aksi, use case memperlihatkan external behaviour dari sebuah sistem yang dilihat dari segi pengguna eksternal. Use case tidak seperti operation karena sebuah use case dapat terus menerima input dari actor pada saat dijalankan, dan use case dapat diterapkan pada unit sistem yang lebih kecil seperti subsistem.
• System Boundary
System boundary menjelaskan batasan suatu sistem dengan lingkungannya, sehingga memberi batasan yang jelas sampai mana suatu sistem bekerja, termasuk membatasi sistem dengan actor yang berada di luar sistem. Di dalam system boundary terletak kumpulan use case dari sebuah sistem.

Berikut adalah contoh dari use case diagram :

Gambar 10 Contoh Use case diagram
Sequence diagram
Sequence diagram merupakan diagram yang menggambarkan pola hubungan diantara sekumpulan objek yang saling mempengaruhi menurut urutan waktu. Sebuah objek berinteraksi dengan objek lain melalui pengiriman pesan (messages). Sequence diagram biasanya digunakan untuk mengilustrasikan sebuah use case.
Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait). Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan.
Masing-masing objek, termasuk aktor, memiliki lifeline vertikal. Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase desain berikutnya, message akan dipetakan menjadi operasi/metoda dari class. Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan diterimanya sebuah message.

Berikut adalah contoh notasi dari Sequence diagram :

Gambar 11 Notasi Sequence diagram

Activity diagram
Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi.
Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum.
Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas.Sama seperti state, standar UML menggunakan segiempat dengan sudut membulat untuk menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi tertentu. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.

Berikut adalah contoh Activity diagram tanpa swimlane :

Gambar 12 Contoh Activity diagram-tanpa swimlane

Collaboration diagram
Collaboration diagram juga menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian message. Setiap message memiliki sequence number, di mana message dari level tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama.


Gambar 13 Contoh Collaboration diagram

Contoh kasus
Pada umumnya tidak semua diagram dalam UML harus digunakan untuk melakukan desain dan analisis, hal ini disesuaikan dengan kebutuhan saja. Berikut adalah contoh beberapa diagram pada kasus PT Rackindo Setara Perkasa dimana dibutuhkan sebuah sistem untuk dapat mendukung proses bisnisnya terutama dalam bagian manufakturnya. PT Rackindo Setara Perkasa menghasilkan berbagi macam jenis lemari diantaranya yaitu lemari pakaian, lemari pajangan dan sebagainya. Lemari pakaian yang diproduksi mempunyai berbagai macam merek Untuk mencapai kesuksesan dalam menghadapi persaingan, maka diperlukan penanganan yang baik mulai dari bahan baku datang ke pabrik sampai dengan penyampaian produk ke konsumen. Agar penanganan tersebut berjalan dengan baik kita harus memperhatikan proses produksi secara efisien. Salah satu kunci dalam melakukan proses produksi yang efisien terletak pada pengelolaan bahan baku. Oleh sebab itu untuk dapat membangun suatu sistem penanganan manufaktur ini akan dilakukan analisis dan desain digambarkanlah diagram – diagram UML yaitu class diagram , component diagram, dan deployment diagram.

a) Class diagram

Gambar 14 Class Diagram PT Rackindo Setara Perkasa


b) Component diagram




Gambar 15 Component diagram PT Rackindo Setara Perkasa
c) Deployment diagram




Gambar 15 Deployment diagram PT Rackindo Setara Perkasa


KESIMPULAN DAN SARAN

Kesimpulan
Unified Modeling Language (UML) adalah bahasa pemodelan umum yang digunakan untuk melakukan spesifikasi, visualisasi, konstruksi dan dokumentasi artifak dari software system. UML bukanlah sebuah standar proses pengembangan dalam metode pengembangan sistem tertentu, namun pada umumnya UML dipakai dalam memodelkan sistem yang dibangun berbasiskan objek.
Tujuan UML menurut Booch, Rumbaugh dan Jacobson :
• Memberikan model yang siap pakai, bahasa pemodelan visual yang ekspresif untuk mengembangkan dan saling menukar model dengan mudah dan dimengerti secara umum.
• Memberikan bahasa pemodelan yang bebas dari berbagai bahasa pemograman dan proses rekayasa.
• Menyatukan praktek-praktek terbaik yang terdapat dalam pemodelan.

Dengan menggunakan UML kita dapat membuat model untuk semua jenis aplikasi piranti lunak, dimana aplikasi tersebut dapat berjalan pada piranti keras, sistem operasi dan jaringan apapun, serta ditulis dalam bahasa pemrograman apapun

UML mendefinisikan diagram-diagram sebagai berikut:
• usecase diagram
• class diagram
• statechart diagram
• activity diagram
• sequence diagram
• collaboration diagram
• component diagram
• deployment diagram

Saat ini banyak sekali tool pendesainan yang mendukung UML, baik itu tool komersial maupun opensource. Beberapa diantaranya adalah:
• Rational Rose (www.rational.com)
• Together (www.togethersoft.com)
• Object Domain (www.objectdomain.com)
• Jvision (www.object-insight.com)
• Objecteering (www.objecteering.com)
• MagicDraw (www.nomagic.com/magicdrawuml)
• Visual Object Modeller (www.visualobject.com)

Saran
UML adalah suatu bahasa perancangan modern yang paling umum dipakai pada saat ini, dimana UML ini sering dikaitkan dengan bahasa pengembangan piranti lunak berbasis objek. Dengan menggunakan UML sebagai bahasa perancangan maka kita dapat membuat suatu rancangan piranti lunak yang dimana bahasa tersebut menyatukan berbagai praktik-praktik terbaik dalam permodelan, sehingga hasil rancangan kita dapat dimengerti secara umum dan universal.
Dengan menggunakan UML, maka kita dapat berinteraksi lebih mudah dengan para perancang piranti lunak yang lain, karena kita memakai bahasa perancangan UML yang bersifat universal, dan diketahui oleh hampir semua perancang piranti lunak. Sehingga kita dapat saling bertukar pikiran atas rancangan yang kita buat dengan perancang lain, dan menghilangkan gap dalam perbedaan bahasa permodelan.

DAFTAR PUSTAKA

Anonymous 1.( 23 Mei,2008), Introduction to OMG UML, OMG.

Fowler, Martin. (2004). A brief Duide to the Standard Object Modeling Language. Penerbit ANDI, Yogyakarta.

http://www.omg.org/gettingstarted/what_is_uml.htm.

Rumbaught J, Jacobson I, Booch G. (1999). The Unified Modeling Language Reference Manual. Addison Wesley, New Jersey.

Suhendar,A. S. Si. dan Gunadi, Hariman S.Si., MT. (2002). Visual modeling menggunakan uml dan rational rose . Penerbit Informatika Bandung, Bandung.

DAFTAR RIWAYAT HIDUP


Nama : Erwin Harianto

Tempat, Tanggal Lahir : Jakarta, 30 Juni 1987

Jenis Kelamin : Laki-laki

Agama : Katolik

Alamat : Jl. Gerindo II, Kampung Duri, Duri Selatan –
Jakarta Barat. 11270


Riwayat Pendidikan :

Tahun 1993 - 1999 : SD Widuri Indah II, Jakarta Barat
Tahun 1999 - 2002 : SMP Permata Bunda,
Jakarta Barat
Tahun 2002 - 2005 : SMA Bunda Mulia,
Jakarta Barat
Tahun 2005 - sekarang : Binus University – Jakarta

Pengalaman Kerja :

Tahun 2008 – sekarang : Assistant Lab. Sistem Informasi
Binus University




Minggu, 27 Maret 2011

Bengkel IT

History of UML Sejarah UML
________________________________________
Previous | Home | Next Sebelumnya | Home | Next
Identifiable object-oriented modeling languages began to appear between mid-1970 and the late 1980s as various methodologists experimented with different approaches to object-oriented analysis and design. bahasa pemodelan berorientasi objek-diidentifikasi mulai muncul antara pertengahan 1970 dan akhir 1980-an sebagai berbagai methodologists bereksperimen dengan pendekatan yang berbeda untuk analisis berorientasi objek dan desain. The number of identified modeling languages increased from less than 10 to more than 50 during the period between 1989-1994. Jumlah bahasa pemodelan diidentifikasi meningkat dari kurang dari 10 sampai lebih dari 50 selama periode antara 1989-1994. Many users of OO methods had trouble finding complete satisfaction in any one modeling language, fueling the "method wars." Banyak pengguna metode OO mengalami kesulitan menemukan kepuasan lengkap dalam bahasa pemodelan satu, memicu "perang metode." By the mid-1990s, new iterations of these methods began to appear and these methods began to incorporate each other's techniques, and a few clearly prominent methods emerged. 1 Pada pertengahan 1990, iterasi baru dari metode ini mulai muncul dan metode ini mulai menggabungkan teknik lain masing-masing, dan beberapa metode jelas menonjol muncul. 1
The development of UML began in late 1994 when Grady Booch and Jim Rumbaugh of Rational Software Corporation began their work on unifying the Booch and OMT (Object Modeling Technique) methods. Pengembangan UML dimulai pada akhir tahun 1994 ketika Grady Booch dan Jim Rumbaugh Rasional Software Corporation mulai bekerja mereka mempersatukan Booch dan OMT (Object Modeling Technique) metode. In the Fall of 1995, Ivar Jacobson and his Objectory company joined Rational and this unification effort, merging in the OOSE (Object-Oriented Software Engineering) method. 1 Pada musim gugur tahun 1995, Ivar Jacobson dan perusahaan Objectory nya bergabung Rasional dan upaya unifikasi, penggabungan dalam OOSE (Object-Oriented Software Engineering) method. 1
As the primary authors of the Booch, OMT, and OOSE methods, Grady Booch, Jim Rumbaugh, and Ivar Jacobson were motivated to create a unified modeling language for three reasons. Sebagai penulis utama, OMT, dan OOSE metode Booch, Grady Booch, Jim Rumbaugh, dan Ivar Jacobson termotivasi untuk menciptakan bahasa pemodelan terpadu karena tiga alasan. First, these methods were already evolving toward each other independently. Pertama, metode ini sudah berkembang terhadap satu sama lain independen. It made sense to continue that evolution together rather than apart, eliminating the potential for any unnecessary and gratuitous differences that would further confuse users. Masuk akal untuk melanjutkan evolusinya yang bersama-sama, bukan terpisah, menghilangkan potensi perbedaan apapun dan serampangan yang tidak perlu yang lebih lanjut akan membingungkan pengguna. Second, by unifying the semantics and notation, they could bring some stability to the object-oriented marketplace, allowing projects to settle on one mature modeling language and letting tool builders focus on delivering more useful features. Kedua, dengan mempersatukan semantik dan notasi, mereka bisa membawa stabilitas beberapa ke pasar berorientasi objek, yang memungkinkan proyek untuk menetap di satu bahasa pemodelan matang dan alat pembangun membiarkan fokus pada memberikan fitur yang lebih bermanfaat. Third, they expected that their collaboration would yield improvements in all three earlier methods, helping them to capture lessons learned and to address problems that none of their methods previously handled well. 1 Ketiga, mereka mengharapkan bahwa kolaborasi mereka akan menghasilkan perbaikan dalam ketiga metode sebelumnya, membantu mereka untuk menangkap pelajaran dan untuk mengatasi masalah yang tidak ada metode mereka sebelumnya ditangani dengan baik. 1
The efforts of Booch, Rumbaugh, and Jacobson resulted in the release of the UML 0.9 and 0.91 documents in June and October of 1996. Upaya Booch, Rumbaugh, dan Jacobson mengakibatkan pelepasan UML 0,9 dan 0,91 dokumen pada bulan Juni dan Oktober 1996. During 1996, the UML authors invited and received feedback from the general community. Selama 1996, penulis UML mengundang dan menerima umpan balik dari masyarakat umum. They incorporated this feedback, but it was clear that additional focused attention was still required. 1 Mereka memasukkan umpan balik ini, tapi jelas bahwa fokus perhatian tambahan masih diperlukan. 1
While Rational was bringing UML together, efforts were being made on achieving the broader goal of an industry standard modeling language. Sementara Rasional adalah membawa UML bersama, upaya-upaya sedang dilakukan untuk mencapai tujuan yang lebih luas dari bahasa pemodelan standar industri. In early 1995, Ivar Jacobson (then Chief Technology Officer of Objectory) and Richard Soley (then Chief Technology Officer of OMG) decided to push harder to achieve standardization in the methods marketplace. Pada tahun 1995 awal, Ivar Jacobson (kemudian Chief Technology Officer Objectory) dan Richard Semata-mata (kemudian Chief Technology Officer OMG) memutuskan untuk mendorong lebih keras untuk mencapai standardisasi di pasar metode. In June 1995, an OMG-hosted meeting of all major methodologists (or their representatives) resulted in the first worldwide agreement to seek methodology standards, under the aegis of the OMG process. 1 Pada bulan Juni 1995, sebuah OMG-host pertemuan semua methodologists utama (atau wakil mereka) menghasilkan kesepakatan seluruh dunia pertama untuk mencari standar metodologi, di bawah naungan proses OMG. 1
During 1996, it became clear that several organizations saw UML as strategic to their business. Selama tahun 1996, menjadi jelas bahwa beberapa organisasi melihat UML sebagai strategis untuk bisnis mereka. A Request for Proposal (RFP) issued by the Object Management Group (OMG) provided the catalyst for these organizations to join forces around producing a joint RFP response. Sebuah Permintaan Proposal (RFP) yang dikeluarkan oleh Object Management Group (OMG) menyediakan katalisator bagi organisasi-organisasi ini untuk bergabung sekitar menghasilkan respons RFP bersama. Rational established the UML Partners consortium with several organizations willing to dedicate resources to work toward a strong UML 1.0 definition. Rasional mendirikan UML Mitra konsorsium dengan beberapa organisasi bersedia menyumbangkan sumber daya untuk bekerja menuju 1,0 definisi UML kuat. Those contributing most to the UML 1.0 definition included: Digital Equipment Corp., HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI, and Unisys. Mereka memberikan kontribusi paling definisi UML 1.0 termasuk: Digital Equipment Corp, HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI, dan Unisys. This collaboration produced UML 1.0, a modeling language that was well defined, expressive, powerful, and generally applicable. Kolaborasi diproduksi UML 1.0, sebuah bahasa pemodelan yang didefinisikan dengan baik, ekspresif, kuat, dan umumnya berlaku. This was submitted to the OMG in January 1997 as an initial RFP response. 1 Hal ini disampaikan kepada OMG pada bulan Januari 1997 sebagai respon RFP awal. 1
In January 1997 IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies and Softeam also submitted separate RFP responses to the OMG. Pada Januari 1997 IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies dan Softeam juga disampaikan RFP tanggapan terpisah untuk OMG tersebut. These companies joined the UML partners to contribute their ideas, and together the partners produced the revised UML 1.1 response. Perusahaan-perusahaan ini bergabung dengan mitra UML untuk menyumbangkan ide-ide mereka, dan bersama para mitra menghasilkan UML revisi 1.1 respon. The focus of the UML 1.1 release was to improve the clarity of the UML 1.0 semantics and to incorporate contributions from the new partners. Fokus dari rilis 1.1 UML adalah untuk meningkatkan kejelasan semantik UML 1.0 dan menggabungkan kontribusi dari mitra baru. It was submitted to the OMG for their consideration and adopted in the fall of 1997. 1 Hal itu disampaikan kepada OMG untuk pertimbangan dan diadopsi pada musim gugur tahun 1997. 1

Setiap diagram UML dirancang untuk membiarkan pengembang dan pelanggan melihat sistem perangkat lunak dari perspektif yang berbeda dan dalam berbagai tingkat abstraksi. UML diagrams commonly created in visual modeling tools include: 1 UML diagram umumnya dibuat dalam alat pemodelan visual meliputi: 1
Use Case Diagram displays the relationship among actors and use cases. 1 Gunakan Case Diagram menampilkan hubungan antara aktor dan use case. 1
Class Diagram models class structure and contents using design elements such as classes, packages and objects. Class Diagram model kelas struktur dan isi menggunakan elemen desain seperti kelas, paket dan objek. It also displays relationships such as containment, inheritance, associations and others. 1 Hal ini juga menampilkan hubungan seperti penahanan, warisan, asosiasi dan lain-lain. 1
Interaction Diagrams Diagram Interaksi
• Sequence Diagram Sequence Diagram displays the time sequence of the objects participating in the interaction. menampilkan urutan waktu obyek berpartisipasi dalam interaksi. This consists of the vertical dimension (time) and horizontal dimension (different objects). 1 Ini terdiri dari dimensi vertikal (waktu) dan dimensi horizontal (objek yang berbeda). 1
• Collaboration Diagram Kolaborasi Diagram displays an interaction organized around the objects and their links to one another. menampilkan interaksi terorganisir disekitar obyek dan hubungan mereka satu sama lain. Numbers are used to show the sequence of messages. 1 Nomor digunakan untuk menunjukkan urutan pesan. 1
State Diagram displays the sequences of states that an object of an interaction goes through during its life in response to received stimuli, together with its responses and actions. 1 Negara Diagram menampilkan urutan menyatakan bahwa objek interaksi berjalan melalui selama hidupnya sebagai respon terhadap rangsangan yang diterima, bersama-sama dengan tanggapan dan tindakan. 1
Activity Diagram Diagram Aktivitas displays a special state diagram where most of the states are action states and most of the transitions are triggered by completion of the actions in the source states. menampilkan diagram negara khusus di mana sebagian besar negara-negara adalah negara tindakan dan sebagian besar transisi yang dipicu oleh penyelesaian tindakan di negara-negara sumber. This diagram focuses on flows driven by internal processing. 1 Diagram ini berfokus pada arus didorong oleh proses internal. 1
Physical Diagrams Diagram Fisik
• Component Diagram displays the high level packaged structure of the code itself. Komponen Diagram menampilkan tingkat tinggi dikemas struktur kode itu sendiri. Dependencies among components are shown, including source code components, binary code components, and executable components. Ketergantungan antar komponen yang ditampilkan, termasuk komponen kode sumber, komponen kode biner, dan komponen dieksekusi. Some components exist at compile time, at link time, at run times well as at more than one time. 1 Beberapa komponen ada pada waktu kompilasi, pada waktu link, pada waktu berjalan dengan baik pada lebih dari satu waktu. 1
• Deployment Diagram Deployment Diagram displays the configuration of run-time processing elements and the software components, processes, and objects that live on them. menampilkan konfigurasi waktu proses elemen-lari dan komponen perangkat lunak, proses, dan objek yang hidup pada mereka. Software component instances represent run-time manifestations of code units. 1 contoh komponen perangkat lunak merupakan manifestasi waktu menjalankan unit kode. 1



Use Case Diagram
________________________________________
Previous | Home | Next Sebelumnya | Home | Next
A use case is a set of scenarios that describing an interaction between a user and a system. Sebuah use case adalah serangkaian skenario yang menggambarkan interaksi antara pengguna dan sistem. A use case diagram displays the relationship among actors and use cases. Sebuah diagram use case menampilkan hubungan antara aktor dan use case. The two main components of a use case diagram are use cases and actors. Dua komponen utama dari sebuah diagram use case yang menggunakan kasus dan aktor.

An actor is represents a user or another system that will interact with the system you are modeling. Seorang aktor adalah merupakan user atau sistem lain yang akan berinteraksi dengan sistem yang Anda pemodelan. A use case is an external view of the system that represents some action the user might perform in order to complete a task. Kasus yang digunakan adalah pandangan eksternal dari sistem yang mewakili beberapa tindakan pengguna mungkin tampil dalam rangka untuk menyelesaikan tugas.
When to Use: Use Cases Diagrams Kapan Menggunakan: Kasus Gunakan Diagram
Use cases are used in almost every project. kasus Gunakan digunakan di hampir setiap proyek. The are helpful in exposing requirements and planning the project. Yang sangat membantu dalam mengungkap persyaratan dan perencanaan proyek. During the initial stage of a project most use cases should be defined, but as the project continues more might become visible. Selama tahap awal yang paling menggunakan kasus proyek harus didefinisikan, tetapi sebagai proyek terus lebih mungkin menjadi terlihat.
How to Draw: Use Cases Diagrams Bagaimana Draw: Kasus Gunakan Diagram
Use cases are a relatively easy UML diagram to draw, but this is a very simplified example. kasus Gunakan adalah diagram UML yang relatif mudah untuk menarik, tapi ini adalah contoh yang sangat disederhanakan. This example is only meant as an introduction to the UML and use cases. Contoh ini hanya dimaksudkan sebagai pengantar dan menggunakan kasus UML. If you would like to learn more see the Resources page for more detailed resources on UML. Jika Anda ingin mempelajari lebih lanjut, lihat Sumberdaya halaman untuk sumber daya lebih rinci tentang UML.
Start by listing a sequence of steps a user might take in order to complete an action. Mulailah dengan daftar urutan langkah pengguna mungkin ambil untuk menyelesaikan tindakan. For example a user placing an order with a sales company might follow these steps. Misalnya pengguna menempatkan perintah dengan sebuah perusahaan penjualan mungkin mengikuti langkah-langkah ini.
1. Browse catalog and select items. Jelajahi katalog dan memilih item.
2. Call sales representative. Call perwakilan penjualan.
3. Supply shipping information. Supply pengiriman informasi.
4. Supply payment information. Penyediaan informasi pembayaran.
5. Receive conformation number from salesperson. Menerima nomor konformasi dari penjual.
These steps would generate this simple use case diagram: Langkah-langkah ini akan menghasilkan ini menggunakan diagram kasus sederhana:

This example shows the customer as a actor because the customer is using the ordering system. Contoh ini menunjukkan pelanggan sebagai aktor karena pelanggan menggunakan sistem pemesanan. The diagram takes the simple steps listed above and shows them as actions the customer might perform. Diagram mengambil langkah-langkah sederhana yang tercantum di atas dan menunjukkan mereka sebagai tindakan pelanggan mungkin tampil. The salesperson could also be included in this use case diagram because the salesperson is also interacting with the ordering system. tenaga penjualan juga dapat dimasukkan dalam diagram use case karena penjual juga berinteraksi dengan sistem pemesanan.
From this simple diagram the requirements of the ordering system can easily be derived. Dari diagram sederhana persyaratan dari sistem pemesanan dengan mudah dapat diturunkan. The system will need to be able to perform actions for all of the use cases listed. Sistem akan perlu untuk dapat melakukan tindakan untuk semua kasus penggunaan terdaftar. As the project progresses other use cases might appear. Karena proyek berlangsung kasus penggunaan lainnya mungkin muncul. The customer might have a need to add an item to an order that has already been placed. Pelanggan mungkin memiliki kebutuhan untuk menambahkan item ke perintah yang sudah ditempatkan. This diagram can easily be expanded until a complete description of the ordering system is derived capturing all of the requirements that the system will need to perform. Diagram ini dengan mudah dapat diperluas sampai deskripsi lengkap dari sistem pemesanan berasal menangkap seluruh persyaratan bahwa sistem perlu untuk melakukan.
Class Diagram
________________________________________
Previous | Home | Next Sebelumnya | Home | Next
Class diagrams are widely used to describe the types of objects in a system and their relationships. diagram Class secara luas digunakan untuk menggambarkan jenis objek dalam sistem dan hubungan mereka. Class diagrams model class structure and contents using design elements such as classes, packages and objects. 2 Class diagrams describe three different perspectives when designing a system, conceptual, specification, and implementation. 1 These perspectives become evident as the diagram is created and help solidify the design. Class diagram model kelas struktur dan isi menggunakan elemen desain seperti kelas, paket dan objek. 2 Kelas diagram menggambarkan tiga perspektif yang berbeda ketika merancang suatu sistem, konseptual, spesifikasi, dan pelaksanaan. 1 perspektif ini terbukti sebagai diagram dibuat dan membantu memantapkan desain. This example is only meant as an introduction to the UML and class diagrams. Contoh ini hanya dimaksudkan sebagai pengenalan UML dan diagram kelas. If you would like to learn more see the Resources page for more detailed resources on UML. Jika Anda ingin mempelajari lebih lanjut, lihat Sumberdaya halaman untuk sumber daya lebih rinci tentang UML.
Classes are composed of three things: a name, attributes, and operations. Kelas terdiri dari tiga hal: nama, atribut, dan operasi. Below is an example of a class. Berikut adalah contoh dari sebuah kelas.

Class diagrams also display relationships such as containment, inheritance, associations and others. 2 Below is an example of an associative relationship: Class diagram juga menampilkan hubungan seperti penahanan, warisan, asosiasi dan lain-lain. 2 Di bawah ini adalah contoh dari hubungan asosiatif:

The association relationship is the most common relationship in a class diagram. Hubungan asosiasi adalah hubungan yang paling umum dalam diagram kelas. The association shows the relationship between instances of classes. Asosiasi ini menunjukkan hubungan antara contoh kelas. For example, the class Order is associated with the class Customer. Sebagai contoh, Orde kelas dikaitkan dengan Pelanggan kelas. The multiplicity of the association denotes the number of objects that can participate in then relationship. 1 For example, an Order object can be associated to only one customer, but a customer can be associated to many orders. Banyaknya asosiasi menunjukkan jumlah objek yang dapat berpartisipasi dalam maka hubungan. 1 Sebagai contoh, suatu obyek Order dapat dikaitkan hanya satu pelanggan, tetapi pelanggan dapat dikaitkan ke banyak pesanan.
Another common relationship in class diagrams is a generalization. Hubungan lain yang umum dalam diagram kelas adalah generalisasi. A generalization is used when two classes are similar, but have some differences. Sebuah generalisasi digunakan ketika dua kelas yang sama, tetapi memiliki beberapa perbedaan. Look at the generalization below: Lihatlah generalisasi di bawah ini:

In this example the classes Corporate Customer and Personal Customer have some similarities such as name and address, but each class has some of its own attributes and operations. Dalam contoh ini kelas-kelas Pelanggan Korporasi dan Pribadi Nasabah memiliki beberapa kesamaan seperti nama dan alamat, tetapi setiap kelas memiliki beberapa atribut dan operasi sendiri. The class Customer is a general form of both the Corporate Customer and Personal Customer classes. 1 This allows the designers to just use the Customer class for modules and do not require in-depth representation of each type of customer. Nasabah kelas merupakan bentuk umum dari kedua Nasabah Korporasi dan kelas Pribadi Nasabah. 1 ini memungkinkan para desainer untuk hanya menggunakan class Nasabah untuk modul dan tidak memerlukan-kedalaman perwakilan di masing-masing jenis pelanggan.
When to Use: Class Diagrams Kapan Menggunakan: Diagram Kelas
Class diagrams are used in nearly all Object Oriented software designs. Class diagram digunakan dalam hampir semua perangkat lunak desain Berorientasi Objek. Use them to describe the Classes of the system and their relationships to each other. Gunakan mereka untuk menggambarkan Kelas dari sistem dan hubungan mereka satu sama lain.
How to Draw: Class Diagrams Bagaimana Draw: Diagram Kelas
Class diagrams are some of the most difficult UML diagrams to draw. Class diagram adalah beberapa diagram UML yang paling sulit untuk menggambar. To draw detailed and useful diagrams a person would have to study UML and Object Oriented principles for a long time. Untuk menarik dan bermanfaat diagram rinci seseorang harus belajar UML dan Berorientasi Objek prinsip untuk waktu yang lama. Therefore, this page will give a very high level overview of the process. Oleh karena itu, halaman ini akan memberikan gambaran tingkat yang sangat tinggi dari proses. To find list of where to find more information see the Resources page. Untuk mencari daftar dari mana menemukan informasi lebih lanjut, lihat Sumberdaya halaman.
Before drawing a class diagram consider the three different perspectives of the system the diagram will present; conceptual, specification, and implementation. Sebelum menggambar diagram kelas mempertimbangkan tiga perspektif yang berbeda dari sistem diagram akan hadir, konseptual, spesifikasi, dan implementasi. Try not to focus on one perspective and try see how they all work together. Cobalah untuk tidak fokus pada satu perspektif dan mencoba melihat bagaimana mereka bekerja bersama-sama.
When designing classes consider what attributes and operations it will have. Ketika kelas merancang mempertimbangkan apa atribut dan operasi itu akan memiliki. Then try to determine how instances of the classes will interact with each other. Kemudian cobalah untuk menentukan bagaimana kasus kelas akan berinteraksi satu sama lain. These are the very first steps of many in developing a class diagram. Ini adalah langkah pertama yang sangat banyak dalam mengembangkan diagram kelas. However, using just these basic techniques one can develop a complete view of the software system. Namun, dengan hanya menggunakan dasar teknik ini kita dapat membangun sebuah pandangan lengkap dari sistem software.

This example is only meant as an introduction to the UML and use cases. Contoh ini hanya dimaksudkan sebagai pengantar dan menggunakan kasus UML. If you would like to learn more see the Resources page for more detailed resources on UML. Jika Anda ingin mempelajari lebih lanjut, lihat Sumberdaya halaman untuk sumber daya lebih rinci tentang UML.

Diagram Interaksi
________________________________________
Previous | Home | Next Sebelumnya | Home | Next
Interaction diagrams model the behavior of use cases by describing the way groups of objects interact to complete the task. Interaksi diagram model perilaku kasus digunakan oleh kelompok menjelaskan cara objek berinteraksi untuk menyelesaikan tugas. The two kinds of interaction diagrams are sequence and collaboration diagrams. Kedua jenis diagram interaksi dan kolaborasi urutan diagram. This example is only meant as an introduction to the UML and interaction diagrams. Contoh ini hanya dimaksudkan sebagai pengantar dan interaksi diagram UML. If you would like to learn more see the Resources page for a list of more detailed resources on UML. Jika Anda ingin mempelajari lebih lanjut, lihat Sumberdaya halaman untuk daftar sumber daya lebih rinci pada UML.
When to Use: Interaction Diagrams Kapan Menggunakan: Diagram Interaksi
Interaction diagrams are used when you want to model the behavior of several objects in a use case. Interaksi diagram digunakan ketika Anda ingin model perilaku beberapa objek dalam kasus digunakan. They demonstrate how the objects collaborate for the behavior. Mereka menunjukkan bagaimana objek berkolaborasi untuk perilaku tersebut. Interaction diagrams do not give a in depth representation of the behavior. Interaksi diagram tidak memberikan kedalaman dalam representasi perilaku. If you want to see what a specific object is doing for several use cases use a state diagram . Jika Anda ingin melihat apa objek tertentu yang dilakukan untuk kasus-kasus menggunakan beberapa menggunakan diagram negara . To see a particular behavior over many use cases or threads use an activity diagrams . 1 Untuk melihat perilaku tertentu atas kasus-kasus banyak yang menggunakan atau benang menggunakan diagram aktivitas . 1
How to Draw: Interaction Diagrams Bagaimana Draw: Diagram Interaksi
Sequence diagrams, collaboration diagrams, or both diagrams can be used to demonstrate the interaction of objects in a use case. Sequence diagram, diagram kolaborasi, atau keduanya diagram dapat digunakan untuk menunjukkan interaksi objek dalam kasus digunakan. Sequence diagrams generally show the sequence of events that occur. Sequence diagram umum menunjukkan urutan peristiwa yang terjadi. Collaboration diagrams demonstrate how objects are statically connected. Kolaborasi diagram menunjukkan bagaimana objek yang statis tersambung. Both diagrams are relatively simple to draw and contain similar elements. 1 Kedua diagram relatif sederhana untuk menarik dan mengandung unsur-unsur serupa. 1
Sequence diagrams: Sequence diagram:
Sequence diagrams demonstrate the behavior of objects in a use case by describing the objects and the messages they pass. Sequence diagram menunjukkan perilaku objek dalam kasus digunakan dengan menggambarkan objek dan pesan mereka lulus. the diagrams are read left to right and descending. diagram yang dibaca dari kiri ke kanan dan turun. The example below shows an object of class 1 start the behavior by sending a message to an object of class 2. Contoh di bawah ini menunjukkan obyek dari kelas 1 memulai perilaku dengan mengirim pesan ke objek dari 2 kelas. Messages pass between the different objects until the object of class 1 receives the final message. Pesan lewat antara objek yang berbeda sampai obyek dari kelas 1 menerima pesan terakhir.

Below is a slightly more complex example. Di bawah ini adalah contoh yang lebih kompleks sedikit. The light blue vertical rectangles the objects activation while the green vertical dashed lines represent the life of the object. Biru persegi panjang vertikal cahaya aktivasi obyek sedangkan garis vertikal putus-putus hijau merupakan kehidupan objek. The green vertical rectangles represent when a particular object has control. Persegi panjang vertikal hijau mewakili jika benda tertentu memiliki kontrol. The The represents when the object is destroyed. mewakili ketika objek dihancurkan. This diagrams also shows conditions for messages to be sent to other object. Diagram ini juga menunjukkan kondisi untuk pesan yang akan dikirim ke objek lain. The condition is listed between brackets next to the message. Kondisi ini terdaftar antara tanda kurung di samping pesan. For example, a [condition] has to be met before the object of class 2 can send a message() to the object of class 3. Misalnya, [kondisi] harus dipenuhi sebelum obyek dari kelas 2 dapat mengirim pesan () untuk objek 3 kelas.

The next diagram shows the beginning of a sequence diagram for placing an order. Diagram berikut menunjukkan awal dari sebuah diagram urutan untuk menempatkan pesanan. The object an Order Entry Window is created and sends a message to an Order object to prepare the order. Objek Order Entry Window diciptakan dan mengirim pesan ke objek Order untuk menyiapkan pesanan. Notice the the names of the objects are followed by a colon. Perhatikan nama objek diikuti dengan titik dua. The names of the classes the objects belong to do not have to be listed. Nama kelas objek milik tidak harus terdaftar. However the colon is required to denote that it is the name of an object following the objectName:className naming system. Namun usus besar diperlukan untuk menunjukkan bahwa itu adalah nama obyek berikut objectName: sistem penamaan className.
Next the Order object checks to see if the item is in stock and if the [InStock] condition is met it sends a message to create an new Delivery Item object. Selanjutnya cek objek Order untuk melihat apakah item tersebut dalam stok dan jika [InStock] kondisi terpenuhi hal ini memberikan pesan untuk membuat obyek Pengiriman Item baru.

The next diagrams adds another conditional message to the Order object. Diagram berikutnya menambahkan pesan lain bersyarat untuk objek Order. If the item is [OutOfStock] it sends a message back to the Order Entry Window object stating that the object is out of stack. Jika item [OutOfStock] mengirimkan pesan kembali ke Orde Entry Window obyek yang menyatakan bahwa objek tersebut keluar dari stack.

This simple diagram shows the sequence that messages are passed between objects to complete a use case for ordering an item. Diagram sederhana ini menunjukkan urutan bahwa pesan yang dilewatkan antara obyek untuk menyelesaikan kasus gunakan untuk memesan item.
Collaboration diagrams: Kolaborasi diagram:
Collaboration diagrams are also relatively easy to draw. Kolaborasi diagram juga relatif mudah untuk menarik. They show the relationship between objects and the order of messages passed between them. Mereka menunjukkan hubungan antara obyek dan urutan pesan lewat di antara mereka. The objects are listed as icons and arrows indicate the messages being passed between them. Obyek terdaftar sebagai ikon dan panah menunjukkan pesan-pesan yang lewat di antara mereka. The numbers next to the messages are called sequence numbers. Nomor sebelah pesan disebut nomor urut. As the name suggests, they show the sequence of the messages as they are passed between the objects. Seperti namanya, mereka menunjukkan urutan pesan seperti yang lewat di antara objek. There are many acceptable sequence numbering schemes in UML. Ada banyak diterima urutan penomoran skema di UML. A simple 1, 2, 3... Sederhana 1, 2, 3 ... format can be used, as the example below shows, or for more detailed and complex diagrams a 1, 1.1 ,1.2, 1.2.1... format yang dapat digunakan, sebagai contoh di bawah ini menunjukkan, atau untuk diagram rinci dan kompleks lebih merupakan 1, 1.1 1.2,, 1.2.1 ... scheme can be used. skema dapat digunakan.

The example below shows a simple collaboration diagram for the placing an order use case. Contoh di bawah ini menunjukkan diagram kolaborasi sederhana untuk kasus penggunaan menempatkan pesanan. This time the names of the objects appear after the colon, such as :Order Entry Window following the objectName:className naming convention. Kali ini nama-nama benda muncul setelah tanda titik dua, seperti: Order Entry Window berikut objectName: konvensi penamaan className. This time the class name is shown to demonstrate that all of objects of that class will behave the same way. Kali ini nama kelas ditampilkan untuk menunjukkan bahwa semua objek dari kelas yang akan berperilaku dengan cara yang sama.
















State Diagram
________________________________________
Previous | Home | Next Sebelumnya | Home | Next
State diagrams are used to describe the behavior of a system. Negara diagram digunakan untuk menggambarkan perilaku dari suatu sistem. State diagrams describe all of the possible states of an object as events occur. Negara diagram menggambarkan semua keadaan yang mungkin dari suatu objek seperti peristiwa terjadi. Each diagram usually represents objects of a single class and track the different states of its objects through the system. Setiap diagram biasanya mewakili objek dari satu kelas dan melacak negara bagian yang berbeda dari objek melalui sistem.
When to Use: State Diagrams Kapan Menggunakan: Diagram Negara
Use state diagrams to demonstrate the behavior of an object through many use cases of the system. diagram negara Gunakan untuk menunjukkan perilaku objek melalui kasus-kasus menggunakan banyak sistem. Only use state diagrams for classes where it is necessary to understand the behavior of the object through the entire system. Hanya menggunakan diagram negara untuk kelas mana perlu memahami perilaku obyek melalui seluruh sistem. Not all classes will require a state diagram and state diagrams are not useful for describing the collaboration of all objects in a use case. Tidak semua kelas akan memerlukan diagram diagram negara dan negara tidak berguna untuk menggambarkan kolaborasi dari semua obyek di use case. State diagrams are other combined with other diagrams such as interaction diagrams and activity diagrams . 1 Negara diagram lainnya dikombinasikan dengan diagram lain seperti diagram interaksi dan diagram aktivitas . 1
How to Draw: State Diagrams Bagaimana Draw: State Diagram
State diagrams have very few elements. diagram Negara memiliki unsur yang sangat sedikit. The basic elements are rounded boxes representing the state of the object and arrows indicting the transition to the next state. Elemen dasar dibulatkan kotak yang mewakili keadaan objek dan panah mendakwa transisi ke keadaan berikutnya. The activity section of the state symbol depicts what activities the object will be doing while it is in that state. Bagian aktivitas lambang negara menggambarkan kegiatan apa objek akan melakukan ketika sedang dalam keadaan itu.

All state diagrams being with an initial state of the object. Semua diagram negara sedang dengan keadaan awal objek. This is the state of the object when it is created. Ini adalah keadaan objek ketika diciptakan. After the initial state the object begins changing states. Setelah keadaan awal objek mulai berubah negara. Conditions based on the activities can determine what the next state the object transitions to. Kondisi berdasarkan kegiatan dapat menentukan apa keadaan berikutnya transisi objek.

Below is an example of a state diagram might look like for an Order object. Di bawah ini adalah contoh diagram negara mungkin tampak seperti untuk objek Order. When the object enters the Checking state it performs the activity "check items." Ketika obyek memasuki negara Memeriksa ia melakukan kegiatan "item cek." After the activity is completed the object transitions to the next state based on the conditions [all items available] or [an item is not available]. Setelah aktivitas selesai transisi objek ke keadaan berikutnya berdasarkan kondisi [semua item yang tersedia] atau [item tidak tersedia]. If an item is not available the order is canceled. Jika item tidak tersedia pesanan dibatalkan. If all items are available then the order is dispatched. Jika semua item yang tersedia maka order dikirim. When the object transitions to the Dispatching state the activity "initiate delivery" is performed. Ketika transisi objek tersebut ke negara pengirim kegiatan "memulai pengiriman" dilakukan. After this activity is complete the object transitions again to the Delivered state. Setelah kegiatan ini selesai transisi objek lagi untuk negara Delivered.

State diagrams can also show a super-state for the object. Negara diagram juga dapat menunjukkan negara super untuk objek. A super-state is used when many transitions lead to the a certain state. Sebuah negara-super banyak digunakan ketika transisi mengarah pada suatu negara tertentu. Instead of showing all of the transitions from each state to the redundant state a super-state can be used to show that all of the states inside of the super-state can transition to the redundant state. Alih-alih menunjukkan semua transisi dari setiap negara kepada negara berlebihan negara-super dapat digunakan untuk menunjukkan bahwa semua negara dalam negara-super dapat transisi ke keadaan berlebihan. This helps make the state diagram easier to read. Hal ini membantu membuat diagram negara lebih mudah dibaca.
The diagram below shows a super-state. Diagram di bawah menunjukkan negara-super. Both the Checking and Dispatching states can transition into the Canceled state, so a transition is shown from a super-state named Active to the state Cancel. Baik Memeriksa dan negara-negara pengirim dapat transisi ke keadaan Dibatalkan, sehingga transisi ini terlihat dari negara-super bernama Aktif ke negara Batal. By contrast, the state Dispatching can only transition to the Delivered state, so we show an arrow only from the Dispatching state to the Delivered state. Sebaliknya, negara hanya bisa mengirim transisi ke keadaan Delivered, jadi kami menunjukkan panah hanya dari negara pengirim ke negara Delivered.









Diagram Aktivitas
________________________________________
Previous | Home | Next Sebelumnya | Home | Next
Activity diagrams describe the workflow behavior of a system. Kegiatan diagram menggambarkan perilaku alur kerja dari suatu sistem. Activity diagrams are similar to state diagrams because activities are the state of doing something. Aktivitas diagram mirip dengan diagram negara karena kegiatan negara melakukan sesuatu. The diagrams describe the state of activities by showing the sequence of activities performed. Diagram menggambarkan keadaan kegiatan dengan menunjukkan urutan kegiatan yang dilakukan. Activity diagrams can show activities that are conditional or parallel. Kegiatan diagram bisa menunjukkan aktivitas yang kondisional atau paralel.
When to Use: Activity Diagrams Kapan Menggunakan: Diagram Aktivitas
Activity diagrams should be used in conjunction with other modeling techniques such as interaction diagrams and state diagrams . Kegiatan diagram harus digunakan dalam hubungannya dengan teknik pemodelan lain seperti diagram interaksi dan diagram negara . The main reason to use activity diagrams is to model the workflow behind the system being designed. Alasan utama untuk menggunakan diagram aktivitas adalah model alur kerja di balik sistem yang akan dibuat. Activity Diagrams are also useful for: analyzing a use case by describing what actions need to take place and when they should occur; describing a complicated sequential algorithm; and modeling applications with parallel processes. 1 Diagram Aktivitas juga berguna untuk: menganalisis kasus penggunaan dengan menjelaskan tindakan apa yang perlu dilakukan dan kapan mereka harus terjadi; menjelaskan algoritma sekuensial rumit; dan aplikasi pemodelan dengan proses paralel. 1
However, activity diagrams should not take the place of interaction diagrams and state diagrams . Namun, diagram aktivitas tidak boleh mengambil tempat diagram interaksi dan diagram negara . Activity diagrams do not give detail about how objects behave or how objects collaborate. 1 Aktivitas diagram tidak memberikan detail tentang bagaimana benda berperilaku atau bagaimana objek berkolaborasi. 1
How to Draw: Activity Diagrams Bagaimana Draw: Diagram Aktivitas
Activity diagrams show the flow of activities through the system. Kegiatan diagram menunjukkan aliran kegiatan melalui sistem. Diagrams are read from top to bottom and have branches and forks to describe conditions and parallel activities. Diagram dibaca dari atas ke bawah dan memiliki cabang dan garpu untuk menggambarkan kondisi dan kegiatan paralel. A fork is used when multiple activities are occurring at the same time. Sebuah garpu digunakan ketika beberapa kegiatan yang terjadi pada saat yang sama. The diagram below shows a fork after activity1. Diagram di bawah menunjukkan garpu setelah activity1. This indicates that both activity2 and activity3 are occurring at the same time. Hal ini menunjukkan bahwa kedua activity2 dan activity3 yang terjadi pada waktu yang sama. After activity2 there is a branch. Setelah activity2 ada cabang. The branch describes what activities will take place based on a set of conditions. cabang menggambarkan kegiatan apa yang akan terjadi didasarkan pada seperangkat kondisi. All branches at some point are followed by a merge to indicate the end of the conditional behavior started by that branch. Semua cabang di beberapa titik diikuti oleh gabungan untuk menunjukkan akhir perilaku bersyarat dimulai oleh cabang itu. After the merge all of the parallel activities must be combined by a join before transitioning into the final activity state. Setelah menggabungkan semua kegiatan paralel harus dikombinasikan dengan bergabung sebelum transisi ke dalam negara aktivitas akhir.

Below is a possible activity diagram for processing an order. Berikut adalah diagram kegiatan yang mungkin untuk pemrosesan pesanan. The diagram shows the flow of actions in the system's workflow. Diagram menunjukkan aliran tindakan dalam sistem alur kerja. Once the order is received the activities split into two parallel sets of activities. Setelah pesanan diterima kegiatan dibagi menjadi dua set paralel kegiatan. One side fills and sends the order while the other handles the billing. Satu sisi mengisi dan mengirimkan pesanan sementara yang lain menangani penagihan. On the Fill Order side, the method of delivery is decided conditionally. Di sisi Orde Isi, metode pengiriman diputuskan kondisional. Depending on the condition either the Overnight Delivery activity or the Regular Delivery activity is performed. Tergantung pada kondisi baik kegiatan Pengiriman Bermalam atau kegiatan Pengiriman Reguler dilakukan. Finally the parallel activities combine to close the order. Akhirnya kegiatan paralel menggabungkan untuk menutup pesanan.
1








Diagram Fisik
________________________________________
Previous | Home | Next Sebelumnya | Home | Next
There are two types of physical diagrams: deployment diagrams and component diagrams. Deployment diagrams show the physical relationship between hardware and software in a system. Ada dua jenis diagram fisik: deployment diagram dan diagram komponen sistem Deployment. Diagram menunjukkan fisik hubungan antara hardware dan software dalam. Component diagrams show the software components of a system and how they are related to each other. Komponen menunjukkan diagram komponen perangkat lunak sistem dan bagaimana mereka berhubungan satu sama lain. These relationships are called dependencies. 1 Hubungan ini disebut dependensi. 1
When to Use: Physical Diagrams Kapan Menggunakan: Diagram Fisik
Physical diagrams are used when development of the system is complete. diagram fisik digunakan ketika pengembangan sistem selesai. Physical diagrams are used to give descriptions of the physical information about a system. diagram fisik yang digunakan untuk memberikan deskripsi dari informasi fisik tentang suatu sistem.
How to Draw: Physical Diagrams Bagaimana Draw: Diagram Fisik
Many times the deployment and component diagrams are combined into one physical diagram. Banyak kali dan komponen diagram penyebaran digabungkan menjadi satu diagram fisik. A combined deployment and component diagram combines the features of both diagrams into one diagram. Sebuah penyebaran gabungan dan diagram komponen mengkombinasikan fitur kedua diagram ke dalam satu diagram.
The deployment diagram contains nodes and connections. Diagram penyebaran berisi node dan koneksi. A node usually represents a piece of hardware in the system. node biasanya merupakan bagian dari perangkat keras dalam sistem. A connection depicts the communication path used by the hardware to communicate and usually indicates a method such as TCP/IP. Sambungan menggambarkan jalur komunikasi yang digunakan oleh hardware untuk berkomunikasi dan biasanya menunjukkan metode seperti TCP / IP.

The component diagram contains components and dependencies. Diagram komponen berisi komponen dan dependensi. Components represent the physical packaging of a module of code. Komponen merupakan kemasan fisik dari sebuah modul kode. The dependencies between the components show how changes made to one component may affect the other components in the system. Dependensi antara komponen menunjukkan bagaimana perubahan yang dibuat terhadap salah satu komponen dapat mempengaruhi komponen lain dalam sistem. Dependencies in a component diagram are represented by a dashed line between two or more components. Dependensi dalam diagram komponen yang diwakili oleh garis putus-putus antara dua atau lebih komponen. Component diagrams can also show the interfaces used by the components to communicate to each other. 1 Komponen diagram juga dapat menampilkan interface yang digunakan oleh komponen untuk berkomunikasi satu sama lain. 1
The combined deployment and component diagram below gives a high level physical description of the completed system. Penyebaran gabungan dan diagram komponen di bawah ini memberikan deskripsi fisik tingkat tinggi dari sistem selesai. The diagram shows two nodes which represent two machines communicating through TCP/IP. Diagram menunjukkan dua node yang mewakili dua mesin berkomunikasi melalui TCP / IP. Component2 is dependant on component1, so changes to component 2 could affect component1. Component2 tergantung pada component1, sehingga perubahan terhadap komponen 2 dapat mempengaruhi component1. The diagram also depicts component3 interfacing with component1. Diagram juga menggambarkan component3 berinteraksi dengan component1. This diagram gives the reader a quick overall view of the entire system. Diagram ini memberikan pembaca pandangan keseluruhan cepat seluruh sistem.

Sejarah Pembentukan BPUPKI

zil arsyi

pos---- The_ jail >>>> agus safrizal


Memasuki awal tahun 1944, kedudukan Jepang dalam perang Pasifik semakin terdesak. Angkatan Laut Amerika Serikat dipimpin Laksamana Nimitz berhasil menduduki posisi penting di Kepulauan Mariana seperti Saipan, Tidian dan Guan yang memberi kesempatan untuk Sekutu melakukan serangan langsung ke Kepulauan Jepang. Sementara posisi Angkatan Darat Amerika Serikat yang dipimpin oleh Jendral Douglas Mac Arthur melalui siasat loncat kataknya berhasil pantai Irian dan membangun markasnya di Holandia (Jayapura). Dari Holandia inilah Mac Arthur akan menyerang Filipina untuk memenuhi janjinya. Di sisi lain kekuatan Angkatan Laut Sekutu yang berpusat di Biak dan Morotai berhasil menghujani bom pada pusat pertahanan militer Jepang di Maluku, Sulawesi, Surabaya dan Semarang. Kondisi tersebut menyebabkan jatuhnya pusat pertahanan Jepang dan merosotnya semangat juang tentara Jepang. Kekuatan tentara Jepang yang semula ofensif (menyerang) berubah menjadi defensif (bertahan). Kepada bangsa Indonesia, pemerintah militer Jepang masih tetap menggembar gemborkan (meyakinkan) bahwa Jepang akan menang dalam perang Pasifik.


Pada tanggal 18 Juli 1944, Perdana Menteri Hideki Tojo terpaksa mengundurkan diri dan diganti oleh Perdana Menteri Koiso Kuniaki. Dalam rangka menarik simpati bangsa Indonesia agar lebih meningkatkan bantuannya baik moril maupun materiil, maka dalam sidang istimewa ke-85 Parlemen Jepang (Teikoku Ginkai) pada tanggal 7 September 1944 (ada yang menyebutkan 19 September 1944), Perdana Menteri Koiso mengumumkan bahwa Negara-negara yang ada di bawah kekuasaan Jepang diperkenankan merdeka “kelak di kemudian hari”. Janji kemerdekaan ini sering disebut dengan istilah Deklarasi Kaiso. Pada saat itu, Koiso dianggap menciptakan perdamaian dengan Sekutu, namun ia tak bisa menemukan solusi yang akan menenteramkan militer Jepang atau Amerika.
Sejak saat itu pemerintah Jepang memberi kesempatan pada bangsa Indonesia untuk mengibarkan bendera merah putih berdampingan dengan Hinomaru (bendera Jepang), begitu pula lagu kebangsaan Indonesia Raya boleh dinyanyikan setelah lagu Kimigayo. Di satu sisi ada sedikit kebebasan, namun di sisi lain pemerintah Jepang semakin meningkatkan jumlah tenga pemuda untuk pertahanan. Selain dari organisasi pertahanan yang sudah ada ditambah lagi dengan organisasi lainnya seperti: Barisan Pelajar (Suishintai), Barisan Berani Mati (Jikakutai) beranggotakan 50.000 orang yang diilhami oleh pasukan Kamikaze Jepang yang jumlahnya 50.000 orang (pasukan berani mati pada saat penyerangan ke Pearl Harbour).
Pada akhir 1944, posisi Jepang semakin terjepit dalam Perang Asia Timur Raya dimana Sekutu berhasil menduduki wilayah-wilayah kekuasaan Jepang, seperti Papua Nugini, Kepulauan Solomon, Kepulauan Marshall, bahkan Kepulauan Saipan yang letaknya sudah sangat dekat dengan Jepang berhasil diduduki oleh Amerika pada bulan Juli 1944. Sekutu kemudian menyerang Ambon, Makasar, Manado, Tarakan, Balikpapan, dan Surabaya.
Menghadapi situasi yang kritis itu, maka pada tanggal 1 Maret 1945 pemerintah pendudukan Jepang di Jawa yang dipimpin oleh Panglima tentara ke-16 Letnan Jenderal Kumakici Harada mengumumkan pembentukan Dokuritsu Junbi Cosakai atau Badan Penyelidik Usaha-usaha Persiapan Kemerdekaan Indonesia (BPUPKI). Tujuan pembentukan badan tersebut adalah menyelidiki dan mengumpulkan bahan-bahan penting tentang ekonomi, politik dan tata pemerintahan sebagai persiapan untuk kemerdekaan Indonesia.
Walaupun dalam penyusunan keanggotaan berlangsung lama karena terjadi tawar menawar antara pihak Indonesia dan Jepang, namun akhirnya BPUPKI berhasil dilantik 28 Mei 1945 bertepatan dengan hari kelahiran Kaisar Jepang, yaitu Kaisar Hirohito. Adapun keanggotaan yang terbentuk berjumlah 67 orang dengan ketua Dr. K.R.T. Radjiman Widiodiningrat dan R. Suroso dan seorang Jepang sebagai wakilnya Ichi Bangase ditambah 7 anggota Jepang yang tidak memiliki suara. Ir. Soekarno yang pada waktu itu juga dicalonkan menjadi ketua, menolak pencalonannya karena ingin memperoleh kebebasan yang lebih besar dalam perdebatan, karena biasanya peranan ketua sebagai moderator atau pihak yang menegahi dalam memberi keputusan tidak mutlak.

Pada tanggal 28 Mei 1945 dilangsungkanlah upacara peresmian BPUPKI bertempat di Gedung Cuo Sangi In, Jalan Pejambon Jakarta, dihadiri oleh Panglima Tentara Jepang Wilayah Ketujuh Jenderal Itagaki dan Panglima Tentara Keenam Belas di Jawa Letnan Jenderal Nagano. BPUPKI mulai melaksanakan tugasnya dengan melakukan persidangan untuk merumuskan undang-undang dasar bagi Indonesia kelak. Hal utama yang dibahas adalah dasar negara bagi negara Indonesia merdeka.
Selama masa tugasnya BPUPKI hanya mengadakan sidang dua kali. Sidang pertama dilakukan pada tanggal 29 Mei sampai 1 Juni 1945 di gedung Chou Sang In di Jalan Pejambon 6 Jakarta yang sekarang dikenal dengan sebutan Gedung Pancasila. Pada sidang pertama, Dr. KRT. Rajiman Widyodiningrat selaku ketua dalam pidato pembukaannya menyampaikan masalah pokok menyangkut dasar negara Indonesia yang ingin dibentuk pada tanggal 29 Mei 1945.

Selasa, 22 Maret 2011

Cara Membobol akses jaringan Hotspot

 >>>>>> pOs awak ni mEn......>>>>>>>Agus Safrizal


Untuk tulisan ini ilmu belajar komputer bukannya mau memberikan saran yah, tapi hanya sebagai pelajaran aja yaitu Cara membobol hotspot warnet dan jaringan wireles internet yang dapat kamu tangkap keberadaannya OK.

Trik ini juga bisa digunkan untuk mencari pasword yang digunakan oleh seseorang dalam mengakses hotspot yang bisanya menggunakan kartu prepaid atau member dari suatu warnet Lho! perhatikan baik-baik ya!

Alat yang dipersiapkan sih simple aja :

- Seperangkat Laptop
: Pc yang kena wireless juga boleh, asal jaringan hotspotnya nyampek.

- Charger laptop
: karena pasti memakan banyak daya batre saat keranjingan internet gratisNgakakNgakak.

Software yang diperlukan :

1. AngryIP Scanner (108 kb): ini software untuk scanning ip dan mencari mac address korban. Softwarenya search aja di google kecil kok ukurannya. Tinggal pakai alias gak perlu instalasi.

2. Mac Addres Chager (312 kb): software ini dipergunkan untuk mengganti mac addres kita. Mac Address ? gak perlu dijelasin yang penting bisa makeknya, tak pasti ngeti sambil jalan. (asal jalan gak jauh-jauh “^_^”). Silakan search di google.

Langsung aja sekarang ke caranya :

1. Cari lokasi penyedia layanan hotspot, tentunya di daerah yang terjangkau jaringan hotspot tersebut.

2. Hidupkan laptop anda, dan hidupkan pula wireless network anda dan lihat di sistem tray icon wireless network, kemudian klik kanan dan pilih view avalible wireless network, dan tentunya setelah itu anda harus connect ke wireless hotspot tujuan anda.

3. Setelah connect, klik kanan sistem tray dan pilih status >pilih tab detail > kelihatan disana ip yang diberikan kepada kita. Catat ip tersebut.

4. Buka Program AngryIP Scanner dan isikan ip range yang akan kita scan (pakai data ip kita tadi) pada bagian atas. Misalnya : IP yang kita dapat xxx.xxx.x.xx kemuadian masukkan pada kolom range pertama ip kita sesuai dengan ip yang tadi namun ganti angka di bagian akhir dengan 1 menjadi xxx.xxx.x.1 dan pada kolom kedua tuliskan sama namun angka satu diakhir itu ganti dengan 255 menjadi xxx.xxx.x.255. hasilnya xxx.xxx.x.1 to xxx.xxx.x.255 dan klik start (tombol merah).

5. Setelah melakukan scanning maka kita akan mendapatkan data ip yang hidup yang terkoneksi dengan hotspot tersebut. setelah scanning selesai maka lihat ip yang hidup (alive host) warna biru klik kanan pada ip yang hidup Klik kanan pada ip yang warna biru tadi klik kanan > show > mac address dan akan ada kode mac addres (terkadang ada mac addressnya tidak tampil, pilih saja ip yang lainnya). Catat mac address yang kita dapatkan.

6. Buka Program Mac Address Changer yang telah kita persiapkan. Disana ada field mac address. nah sekarang tinggal ganti mac address tersebut dengan yang kita dapatkan tadi dan tekan change mac id.

7. Tunggu karena mac kita aan diganti dan koneksi sementara terputus dan konek lagi otomatis sendiri.

8. Masuk web browser firefox atau apa saja boleh. Nikmati Internet Gratis…

Satu hal yang perlu diingat adalah kita sistemnya numpang data transfer pada account yang kita hack tadi (yang punya ip tadi, maaf…). Kalau Saya sih biasanya untuk mengakalinya adalah dengan masuk halaman status login hotspot tersebut (untuk dapat account). misalnya idonbiu.hotspot.net/status dan begitu masuk disana kan terlihat nomor sandi prepaid card dan kita catat saja, lalu logout, dan masuk kembali ke halaman login hotspot itu cepat-cepat masukkan sandi tadi. Hal ini akan membuat kita secara langsung dapat mengakses internet tanpa menumpang lagi (soalnya yang make prepaid card code kan kita) jadi kalau ada yang mau login pakai kartu itu (yang punya code) saat kita login pakai kartu itu tentunya dia tidak akan bisa masuk karena kartu prepaid cardnya “already login”.

Bagaiamana, menarik bukan ?

Tapi saya sarankan, seperti yang saya lakukan adalah dengan menumpang saja, karena saya tidak mau berbuat terlalu jauh, seperti cara yang saya beritau untuk me log off dan log in lagi tentunya akan membuat sang pemilik tidak bisa log in. Kasian kan ?

Jadi mumpung sudah dikasi gratisan, kenapa gak numpang saja ya, itung-itung cuman ikutan ngakses bareng kan tidak terlalu merugikan. Minta ijin langsung juga kemungkinan yang punya gak nolak, asal kepentingannya memang mendesak.

Untuk Sacanning Ip saya juga bisa gunakan aplikasi the dude untuk mengetahui kondisi koneksi komputer-komputer ke hotspot. Bisa dicoba juga ya.

Sekali lagi, semua ini hanya untuk pembelajaran saja, selama kita masih mampu kenapa gak pakai yang legal aja. Dan ini juga bisa dimanfaatkan oleh pemilik hotspot, kalau cara ini masih bisa digunakan untuk membobol. Jadi perlu keamanan yang lebihTongueTop…

PENGERTIAN TENTANG UML

>>>>>>>>>>>Agus Safrizal
sedikit pengetahuan tentang UML....
selamat membaca pong.......,




UML (Unified Modeling Language) adalah sebuah bahasa untuk menetukan, visutifact (bagian dari informasi yang digunakan ataualisasi, kontruksi, dan mendokumentasikan ar dihasilkan dalam suatu proses pembuatan perangkat lunak. Artifact dapat berupa model, deskripsi atau perangkat lunak) dari system perangkat lunak, seperti pada pemodelan bisnis dan system non perangkat lunak lainnya.

UML merupakan suatu kumpulan teknik terbaik yang telah terbukti sukses dalam memodelkan system yang besar dan kompleks. UML tidak hanya digunakan dalam proses pemodelan perangkat lunak, namun hampir dalam semua bidang yang membutuhkan pemodelan.

BAGIAN-BAGIAN UML

Bagian-bagian utama dari UML adalah view, diagram, model element, dan general mechanism.

a. View

View digunakan untuk melihat sistem yang dimodelkan dari beberapa aspek yang berbeda. View bukan melihat grafik, tapi merupakan suatu abstraksi yang berisi sejumlah diagram.

Beberapa jenis view dalam UML antara lain: use case view, logical view, component view, concurrency view,dan deployment view.

b. Use case view

Mendeskripsikan fungsionalitas sistem yang seharusnya dilakukan sesuai yang diinginkan external actors. Actor yang berinteraksi dengan sistem dapat berupa user atau sistem lainnya.

View ini digambarkan dalam use case diagramsdan kadang-kadang dengan activity diagrams. Viewini digunakan terutama untuk pelanggan, perancang (designer), pengembang (developer), dan penguji sistem (tester).

c. Logical view

Mendeskripsikan bagaimana fungsionalitas dari sistem, struktur statis (class, object,danrelationship ) dan kolaborasi dinamis yang terjadi ketika object mengirim pesan ke object lain dalam suatu fungsi tertentu.

View ini digambarkan dalam class diagrams untuk struktur statis dan dalam state, sequence, collaboration, dan activity diagram untuk model dinamisnya. View ini digunakan untuk perancang (designer) dan pengembang (developer).

d. Component view

Mendeskripsikan implementasi dan ketergantungan modul. Komponen yang merupakan tipe lainnya dari code module diperlihatkan dengan struktur dan ketergantungannya juga alokasi sumber daya komponen dan informasi administrative lainnya.

View ini digambarkan dalam component view dan digunakan untuk pengembang (developer).

e. Concurrency view

Membagi sistem ke dalam proses dan prosesor.View ini digambarkan dalam diagram dinamis (state, sequence, collaboration, dan activity diagrams) dan diagram implementasi (component dan deployment diagrams) serta digunakan untuk pengembang (developer), pengintegrasi (integrator), dan penguji (tester).

f. Deployment view

Mendeskripsikan fisik dari sistem seperti komputer dan perangkat (nodes) dan bagaimana hubungannya dengan lainnya.

View ini digambarkan dalam deployment diagramsdan digunakan untuk pengembang (developer), pengintegrasi (integrator), dan penguji (tester).

g. Diagram

Diagram berbentuk grafik yang menunjukkan simbol elemen model yang disusun untuk mengilustrasikan bagian atau aspek tertentu dari sistem. Sebuah diagram merupakan bagian dari suatu view tertentu dan ketika digambarkan biasanya dialokasikan untuk view tertentu. Adapun jenis diagram antara lain :

1. Use Case Diagram

Use case adalah abstraksi dari interaksi antara system dan actor. Use case bekerja dengan cara mendeskripsikan tipe interaksi antara user sebuah system dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah system dipakai. Use casemerupakan konstruksi untuk mendeskripsikan bagaimana system akan terlihat di mata user. Sedangkan use case diagram memfasilitasi komunikasi diantara analis dan pengguna serta antara analis dan client.

2. Class Diagram

Class adalah dekripsi kelompok obyek-obyek dengan property, perilaku (operasi) dan relasi yang sama. Sehingga dengan adanya class diagram dapat memberikan pandangan global atas sebuah system. Hal tersebut tercermin dari class- class yang ada dan relasinya satu dengan yang lainnya. Sebuah sistem biasanya mempunyai beberapa class diagram. Class diagram sangat membantu dalam visualisasi struktur kelas dari suatu system.

3. Component Diagram

Component software merupakan bagian fisik dari sebuah system, karena menetap di komputer tidak berada di benak para analis. Komponent merupakan implementasi software dari sebuah atau lebih class. Komponent dapat berupa source code, komponent biner, atau executable component. Sebuah komponent berisi informasi tentang logic class atau class yang diimplementasikan sehingga membuat pemetaan dari logical view ke component view.Sehingga component diagram merepresentasikan dunia riil yaitu component software yang mengandung component, interface dan relationship.

4. Deployment Diagram

Menggambarkan tata letak sebuah system secara fisik, menampakkan bagian-bagian software yang berjalan pada bagian-bagian hardware, menunjukkan hubungan komputer dengan perangkat (nodes) satu sama lain dan jenis hubungannya. Di dalam nodes,executeable component dan object yang dialokasikan untuk memperlihatkan unit perangkat lunak yang dieksekusi oleh node tertentu dan ketergantungan komponen.

5. State Diagram

Menggambarkan semua state (kondisi) yang dimiliki oleh suatu object dari suatu class dan keadaan yang menyebabkan state berubah. Kejadian dapat berupa object lain yang mengirim pesan. State class tidak digambarkan untuk semua class, hanya yang mempunyai sejumlah state yang terdefinisi dengan baik dan kondisi class berubah oleh stateyang berbeda.

6. Sequence Diagram

Sequence Diagram digunakan untuk menggambarkan perilaku pada sebuah scenario. Kegunaannya untuk menunjukkan rangkaian pesan yang dikirim antara object juga interaksi antaraobject, sesuatu yang terjadi pada titik tertentu dalam eksekusi sistem.

7. Collaboration Diagram

Menggambarkan kolaborasi dinamis sepertisequence diagrams. Dalam menunjukkan pertukaran pesan, collaboration diagrams menggambarkan objectdan hubungannya (mengacu ke konteks). Jika penekannya pada waktu atau urutan gunakansequencediagrams, tapi jika penekanannya pada konteks gunakan collaboration diagram.

8. Activity Diagram

Menggambarkan rangkaian aliran dari aktivitas, digunakan untuk mendeskripsikan aktifitas yang dibentuk dalam suatu operasi sehingga dapat juga digunakan untuk aktifitas lainnya seperti use caseatau interaksi.

Tujuan Penggunaan UML

1. Memberikan bahasa pemodelan yang bebas dari berbagai bahas pemrograman dan proses rekayasa.
2. Menyatukan praktek-praktek terbaik yang terdapat dalam pemodelan.
3. Memberikan model yang siap pakai, bahsa pemodelan visual yang ekspresif untuk mengembangkan dan saling menukar model dengan mudah dan dimengerti secara umum.
4. UML bisa juga berfungsi sebagai sebuah (blue print) cetak biru karena sangat lengkap dan detail. Dengan cetak biru ini maka akan bias diketahui informasi secara detail tentang coding program atau bahkan membaca program dan menginterpretasikan kembali ke dalam bentuk diagram (reserve enginering).

Perangkat lunak yang mendukung pembuatan diagaram UML

1. StarUML (http://staruml.sourceforge.net/en/)

StarUML adalah sebuah proyek open source untuk mengembangkan cepat, fleksibel, extensible, featureful, dan bebas-tersedia UML / platform MDA berjalan pada platform Win32.Tujuan dari proyek StarUML adalah untuk membangun sebuah alat pemodelan perangkat lunak dan juga platform yang menarik adalah pengganti alat UML komersial seperti Rational Rose, Bersama dan sebagainya

2. Acceleo (http://www.acceleo.org/pages/home/en)

Acceleo adalah generator kode yang mengubah model menjadi kode. Acceleo mudah digunakan dan menyediakan “dari rak” generator (Jee,. Bersih, Php …) dan template editor untuk Eclipse.

3. ArgoUML (http://argouml.tigris.org/)

ArgoUML adalah open source UML modeling tool terkemuka dan termasuk dukungan untuk semua diagram UML standar 1,4. Ini berjalan pada setiap platform Java dan tersedia dalam bahasa sepuluh. ArgoUML ditulis seluruhnya di Jawa dan menggunakan Java Kelas Foundation.Hal ini memungkinkan ArgoUML untuk berjalan di hampir semua platform