tugas 3 ,STMIK eresha Tentang sofware engginering didalam perkantoran

selamat malam
lagi lagi tugas kuliah RPL (rekasa perangkat lunak)
kali ini membahas bagimana sofware engginering di implementasikan kedalam lingkup perkantoran
ok,,,, langsung saja

software engginering (rekayasa perangkat lunak) adalah sebuah disiplin rekayasa yang berkaitan dengan semua aspek produksi perangkat lunak.kita ambil contoh dalam kegiatan di kantor saya, para deplovment atau bahasa awamnya IT (tehnikal) sedang membuat sofware ringtone, sms gateway atau di satu divisi di kantor saya yang bernama TechM selalu memaintance service Axis ( yang sekarang berubah nama menjadi AMSIONG), para IT di divisi vas aplikasi sedang membuat tentang aplikasi  sebuah alert untuk memberitahukan kepada pengguna (consumen) secara otomatis tentang promo yang sedang/akan diadakan.

tujuan dari pembuatan aplikasi alert atau sms gateway ini tidak lain dan tidak bukan agar para pelanggan mendapatkan update tentang kabar dari Axis tentang promo2 yang akan atau sedang dijalankan.
saya rasa semua provider di indonesia khususnya para divisi VAs Aplikasi dituntut harus mendeploy program alert atau sms gateway. (kalo salah mohon dimaklumi masih newbie di bidang IT )

ini saya izin copas dari blog tetangga.
Menurut Pressman, Teknologi software engineering dibagi kedalam 4 layer pokok. Yang pertama adalah layer Tools (diidentifikasi alat-alat(Tools) apa saja yang harus digunakan dalam pemodelan system). Layer kedua adalah layer Methods (ditentukan metode-metode yang dipakai dalam melakukan pemodelan, pengembangan dan pendekatan yang dilakukan). Yang berikutnya adalah layer Process (identifikasi pembuatan sebuah softwere berdasarkan kebutuhan dari user). Layer yang terakhir adalah layer For Quality Focus (layer ini bergantung pada identifikasi-identifikasi sebelumnya di layer Tools, Methods maupun Process). Tujuan utama dari perancangan-perancangan sebelumnya ada di layer ini yaitu “High Quality Software”. Disinilah pentingnya Software Engineering.
Software Process
SW Process adalah framework untuk task atau pekejaan yang dibutuhkan untuk membangun sebuah “High Quality Software”. Proses framework sendiri dibagi menjadi dua aktivitas yaitu Framework Activities dan Umbrela Activities. Framework activities merupakan tahapan pokok dalam pembuatan sebuah software yang meliputi work task, work product, milestone (scheduling) & deliverable, serta Quality Checkpoint. Framework Activities sendiri terbagi dalam beberapa tahap yang harus diperhatikan. Tahapan itu adalah Communication & Planning, Modeling, dan Constructor & Deployment.
Tahap komunikasi adalah tahap untuk melakukan komunikasi dan kolaborasi dengan customer dengan tujuan mengumpulkan  informasi mengenai kebutuhan customer tehadap software yang diinginkan. Tahap Perencanaan mendeskripsikan task-task secara teknis , resiko yang akan dihadapi, hingga penjadwalan proses pengembangan software berdasarkan kebutuhan. Tahap pemodelan dilakukan kreasi model bagi pengembang sehingga customer bisa mendapatkan gambaran mengenai software. Secara detail, aktivitas pemodelan terbagi menjadi dua tahap yaitu menganalisa kebutuhan (Analisys Requirement) dan proses desain. Tahap Constructor & Deployment lebih cenderung pada pembangunan software menggunakan Tools-Tools tertentu.
Umbrella Activities merupakan kegiatan yang menaungi atau dengan kata lain “memayungi”  dari pengembangan software agar dapat menghasilkan software yang sesuai dengan kriteria. Yang termasuk ke dalam Umbrela Activities adalah software project management,formal technical reviews, software quality assurance,software configuration management,reusability management,  measurement, document preparation and production, risk management.
Fundamental Activities
Banyak jenis software proses yang berbeda-beda , namun secara umum Fundamental Activities disarikan ada 4 yaitu Software spesification(mendefinisikan software dan batasan-batasan constraint), Software design dan Implementation (untuk menemukan spesifikasi software untuk diproduksi), software validation (memvalidasi software yang telah dibuat) dan yang terakhir software evolution (tahap dimana software perlu di perbaiki maupun diperbarui untuk mengikuti perkembangan jaman, oleh karena itu pemilihan platform untuk pengembangan software sangat penting).
Pada Software specification, terdapat 4 fase penting yaitu Feasibility Study (studi kelayakan sebuah software dan Tools), Requirements Elicitation and analisys (untuk membantu memahami system secara spesifik) dan Requirement validation (memvalidasi requirements dari customer). Pada software desain and implementation dilakukan proses konversi dari spesifikasi sistem ke sistem yang benar-benar dapat di eksekusi. Mungkin juga dapat dilakukan penghalusan atau perbaikan spesifikasi pada tahap ini. Pada software validation termasuk didalamnya proses verifikasi, proses validasi dan proses testing (unit testing, modul testing, subsystem testing, system testing hingga acceptance testing yang dilakukan pada user). Sedangkan pada tahap proses evolution terdapat proses-proses tambahan dimana suatu software dapat berubah selama atau setelah system dikembangkan.


sumber
 http://natrisnaniar.wordpress.com/category/dari-bangku-kuliah/
atau bisa di download untuk bahan tugas
di http://library.binus.ac.id/eColls/eThesisdoc/Bab2/2012-1-00350-IF%20Bab2001.pdf

Proses Software

Pengertian.
Proses Software merupakan Sekumpulan aktifitas yang saling terkait untuk spesifikasi, desain, implementasi dan testing sistem software.
Proses Software terdiri dari :
1. Spesifikasi
2. Desain
3. Validasi
4. Evolusi

Model Proses Software 
Model proses software adalah representasi abstrak dari proses. Merupakan gambaran dari proses dari beberapa perspektif tertentu
Model Proses Software Generik antara lain :
1. Model waterfall
Membagi dan membedakan fase spesifikasi dan pengembangan.
Langkah-langkah pada model ini adalah :
- Analisa dan definisi kebutuhan
- Desain sistem dan software
- Implementasi dan unit testing
- Integrasi dan testing sistem
- Operasi dan maintenance
Kekurangan dari model waterfall adalah kesulitan untuk mengakomodasi perubahan setelah proses berjalan.
Masalah yang sering dihadapi pada model ini, antara lain :
1. Tidak fleksibel dalam pembagian proyek ke dalam tingkat yang berbeda
2. Sulit untuk merespon perubahan kebutuhan konsumen, sehingga model ini hanya cocok jika kebutuhan sudah dimengerti dengan baik

2. Pengembangan Evolusioner
Spesifikasi dan pengembangan yang terpisah
ada 2 methode dalam Pengembangan Evolusioner, yaitu :* Pengembangan Exploratory
bekerja dengan konsumen dan melibatkan sistem akhir dari spesifikasi skema inisial. Dimulai dengan kebutuhan yang dimengerti dengan baik
* Throw-away prototypingBerkonsentrasi pada eksperiment serta mengerti kebutuhan sistem. Dimulai dengan kebutuhan yang tidak dimengerti dengan baik
Permasalahan
- Tidak ada visibilitas proses
- Sistem biasanya tidak terstruktur dengan baik
- Kemampuan khusus (misalnya bahasa untuk prototipe cepat) kemungkinan diperlukan
Aplikasi
- Untuk sistem interaktif berukuran kecil atau tingkat medium.
- Untuk bagian dari sistem besar (misalnya user interface).
- Untuk sistem dengan daur hidup pendek.

3. Pengembangan sistem Formal
Model sistem matematis yang secara formal diterjemahkan ke dalam implementasi.
Pengembangan Sistem Formal Berbasis transformasi dari spesifikasi matematis melalui representasi yang berbeda untuk program yg dapat dieksekusi. Sedangkan transformasi merupakan ‘pemelihara kebenaran’ sehingga dapat menunjukkan program sesuai spesifikasinya.

Permasalahan
- Perlu kemampuan dan training khusus untuk mengaplikasikan teknik ini
- Secara formal sulit untuk menentukan beberapa aspek dari sistem seperti antarmuka user
Aplikasi
- Sistem kritis terutama dimana keselamatan dan keamanan harus dibuat sebelum sistem beroperasi

4. Pengembangan Reuse-based
Penembangan sistem ini Berbasis systematic reuse dimana sistem diintegrasikan dalam komponen yang sudah ada atau sistem COTS (Commercial-off-theshelf).
Tingkatan/ Level Proses pada pengembangan Reuse-based antara lain :
- Analisakomponen
- Modifikasi kebutuhan
- Desain sistem dengan reuse
- Pengembangan dan integrasi
Kebutuhan sistem selalu berkembang selama proyek berlangsung, sehingga iterasi proses dimana level sebelumnya dilakukan rework merupakan bagian dari proses untuk sistem yang besar.
pada proses ini ada 2 pendekatan yang dapat dilakukan, yaitu :
1. Pengembangan Incremental
Pelepasan sistem tidak dalam bentuk pelepasan tunggal, tetapi pengembangan dan pelepasan dibagi ke dalam ‘increment’ dimana setiap ‘increment’ melepaskan bagian dari fungsional yang
dibutuhkan. Kebutuhan user diprioritaskan dan kebutuhan prioritas tertinggi akan dimasukkan dalam ‘increment’ awal. Jika pengembangan ‘increment’ dimulai, kebutuhan dibekukan terlebih dahulu dan setelah itu kebutuhan untuk ‘increment’ selanjutnya dapat dilanjutkan.

Keuntungan Pengembangan Incremental:- Nilai konsumen dapat diserahkan pada setiap ‘increment’ sehingga fungsional sistem tersedia lebih dahulu.
- ‘increment’ awal berfungsi sebagai prototype untuk membantu memperoleh kebutuhan ‘increment’ selanjutnya.
- Resiko lebih rendah dari keseluruhan kegagalan proyek.
- Layanan sistem prioritas tertinggi cenderung menerima testing terbanyak

2. Pengembangan Spiral
Proses direpresentasikan sebagai spiral bukan sebagai urutan aktivitas dengan melihat sistem sebelumnya (backtracking). Setiap loop dalam spiral merepresentasikan fase dalam proses. Tidak ada fase yang tetap seperti spesifikasi atau desain- loop , dalam spiral dipilih tergantung pada apa yang dibutuhkan. Resiko ditaksir secara eksplisit dan penyelesaian sepanjang proses.

Tiap loop dalam Spiral terdiri dari beberapa Sektor, yaitu :
1. Setting Obyektif
yaitu : menentukan tujuan dari Fase yan telah ditentukan.
Batasan-batasan pada proses dan produk serta resiko telah diketahui. Alternatif strategi telah disiapkan berdasarkan resiko-resiko yang telah diketahui dan sudah direncanakan.
2. Penaksiran dan pengurangan resiko
Resiko ditaksir secara detail dan aktifitas didigunakan untuk mengurangi resiko.
3. Pengembangan dan Validasi
Model pengembangan untuk sistem dipilih yang berupa model generik.
4. Perencanaan
Proyek direview dan fase berikutnya dari spiral direncanakan.

Spesifikasi SoftwareDari proses yang sudah berjalan ditentukan layanan apa yang dibutuhkan dan batasan operasi dan pengembangan sistem.
Proses rekayasa kebutuhan terdiri dari :
- Studi kelayakan
- Perolehan dan analisa kebutuhan
- Spesifikasi kebutuhan
- Validasi kebutuhan
Implementasi dan Desain Software
Proses ini mengubah spesifikasi sistem menjadi sistem yang dijalankan.
pengertian Desain software yaitu : Mendesain struktur software yang didapatkan dari spesifikasi.Sedangkan Implementasi yaitu : Mengubah struktur software ke dalam program yang dieksekusi.
Aktifitas desain dan implementasi saling berhubungan dan mungkin terpisah
Aktifitas Proses Desain antara lain :
1. Desain arsitektur
2. Spesifikasi abstrak
3. Desain antar muka
4. Desain komponen
5. Desain struktur data.
6. Desain algoritma.

Metode Desain
Metode Desain merupakan Pendekatan sistematis untuk pengembangan desain software
Desain biasanya terdokumentasi sebagai kumpulan model grafis. Beberapan jenis model Desain yang biasa digunakan antara lain :

• Model data-flow
• Model entity-relation-attribute
• Model struktural
• Model obyek

Pemrograman dan Debugging
yaitu proses untuk Mengubah desain ke dalam program dan menghilangkan error dari program.
Pemrograman adalah aktifitas personal – tidak ada proses pemrograman generik. Seorang Programmer membawa beberapa program testing untuk menemukan kegagalan dalam program dan menghilangkan kegagalan dalam proses debugging.
Prosses dalam Debuging adalah sebagai berikut :
Mencari error ---> Desain perbaikan error ---->Perbaikan error --->Re-test program.

Validasi Software
Verifikasi dan validasi bertujuan untuk menunjukkan bahwa sistem sesuai spesifikasinya dan sesuai kebutuhan konsumen. Validasi Software melibatkan pengecekan dan review proses dan testing sistem. Sedangkan testing sistem melibatkan eksekusi sistem dengan test case yang diambil dari spesifikasi data riil untuk diproses oleh sistem
Tingkat Testing
1. Testing Unit : Dilakukan tes pada komponen individu
2. Testing Modul : Dilakukan tes pada kumpulan komponan yang berhubungan
3.Testing sub-system : Modul diintegrasikan ke dalam sub sistem dan dilakukan tes. Fokus pada testing antar muka
4. Testing sistem : Testing pada keseluruhan sistem. Tertingi terhadap properti penting.
5. Testing Penerimaan : Testing dengan data konsumen untuk memeriksa apakah dapat diterima.

Evolusi Software
Software bersifat fleksibel dan dapat berubah. Perubahan kebutuhan karena perubahan lingkungan bisnis, software yang mendukung bisnis juga harus terlibat dan berubah, Meskipun terdapat batas antara pengembangan
dan evolusi (pemeliharaan), peningkatan yang tidak berhubungan menyebabkan sistem sedikit demi sedikit menjadi sebuah sistem baru.

by suprono 

link sumber : http://sulistriyani.blogspot.com/2010/05/proses-software.html

                    http://mylifemywaymystory.wordpress.com/2012/12/26/software-engineering-the-process-process-model-and-agile-view/

http://feronicatansil.blogspot.com/2012/10/software-process-model.html

Rational Unified Process .. STMIK ERESHA suprono

Rational Unified Process adalah salah satu proses perekayasaan perangkat lunak yang mencakup keseluruhan siklus hidup pengembangan perangkat lunak dengan mengumpulkan berbagai latihan terbaik yang terdapat dalam pengembagan perangkat lunak. Rational Unified Process ini menyediakan cara pendekatan untuk membagi tugas dan tanggung jawab ke kelompok atau organisasi yang akan menangani pengembangan perangkat lunak. Tujuannya adalah memastikan menghasilkan suatu perangkat lunak yang berkualitas tinggi dan sesuai dengan kebutuhan pengguna/bohir serta tepat dihasilkan pada jadwal dan biaya yang telah disepakati. Rational Unified Process merupakan suatu produk proses yang membawa sangat banyak pengetahuan, selalu terbaru, dan dalam wujud “e-coach” atau pelatih elektronok. Rational Unified Process ini didasarkan pada suatu arsitektur proses padat, dan itu mengizinkan suatu organisasi pengembangan untuk mengatur sesuai dengan kebutuhannya. Rational Unified Process menangkap banyak dari latihan terbaik di pengembangan perangkat lunak pada bentuk yang cocok untuk suatu cakupan luas dari proyek dan organisasi.

Khususnya enam latihan terbaik dibawah ini :

• Kembangkan perangkat lunak yang iteraktif
• Atur kebutuhan
• Gunakan arsitektur component-based
• Modelkan perangkat lunak secara visual
• Verifikasikan kualitas perangkat keras secara terus menerus.
• Kontrol perubahan yang terjadi pada perangkat lunak.

Selain enam latihan terbaik tersebut, ada tiga feature yang penting pada Rational Unified Process yang tidak boleh diabaikan, antara lain :

• Peran dari use case dalam mengontrol aspek dalam pengembangan.
• Penggunaannya sebagai kerangka proses yang dapat dikhususkan dan diperluaskan oleh suatu organisasi yang mengadopsinya.
• Kebutuhan akan tools pengembangan perangkat lunak dalam mendukung proses.

Sebuah proses adalah siapa yang melakukan apa, kapan dan bagaimana mencapai tujuannya. Pada perekayasaan perangkat lunak tujuannya adalah membangun suatu perangkat lunak atau meningkat menjadi lebih dari satu.

Rational Unified Process juga merupakan sebuah petunjuk bagaimana secara efektif dalam penggunaan UML (Unified Modeling Language). Telah banyak organisasi yang lambat laun menjadi sadar bahwa begitu pentingnya perencanaan dan dokumentasi yang baik untuk proses pengembangan perangkat lunak demi keberhasilan proyek perangkat lunaknya. Mereka pun membagi pengetahuan dan membaginya kepada pengembangan. Menurut Lee Osterwei: proses perangkat lunak juga termasuk perangkat lunak. Rational Unified Process membagi banyak karakteristik dengan produk perangkat lunak, antara lain :

  Rational Software mengeluarkan upgrade regular

  Rational Sofware Process dikirimkan secara online, oleh karena itu sangat cepat untuk berada di tangan pengembang.

  Rational Unified Process bisa diperbaiki dan dikonfigurasi sesuai dengan kebutuhan organisasi pengembang.

  Ratioanan Unified Process bisa diintegrasikan dengan tools pengembang software sesuai dengan kebutuhan rasional sehingga pengembang dengan mudah dapat mengakses petunjuk proses sesuai dengan tools pengembang yang digunakannya.

Tahap-tahap yang dilakukan Rational Unified Process antara lain tahapan insepsi, elaborasi, konstruksi, transisi.

1.   Insepsi

o    Merupakan tahap awal dari proses Rational Unified Process

o    Menentukan ruang lingkup objek

o    Membuat “business case”

o    Menjawab pertanyaan “apakah yang dikerjakan dapat menciptakaan ‘good business sense’ sehingga proyek dapat dijalankan”

2.   Elaborasi

o    Merupakan tahapan kedua dalam perancangan perangkat lunak.

o    Menganalisa risiko dan berbagai persyaratan.

o    Menetapkan batasan-batasan pada perancangan perangkat lunak.

3.   Konstruksi

o    Tahap ketiga dalam pengimplementasian perancangan perangkat lunak.

o    Melakukan sederatan iterasi.

o    Pada setiap iterasi juga melibatkan proses-proses seperti analisa, desain, implementasi, coding.

4.   Transisi

o    Tahapan terakhir untuk instalasi, deployment, dan sosialisasi perangkat lunak.

o    Melaksanakan apa yang sudah dimodelkan menjadi suatu produk jadi.

o    Dalam tahap ini dilakukan fase seperti:

§  Performance testing

§  Membuat dokumentasi tambahan.

§  Membuat peluncuran produk ke komunitas pengguna.

the overall architecture of the Rational Unified Process.
Manfaat Rational Unified Process :

• Menyediakan petunjuk untuk pengefesian pengembangan dari kualitas perangkat lunak.
• Mengurangi risiko
• Menangkap dan menghasilkan latihan terbaik
• Mempromosilkan kultur dan visi umum.
• Menyediakan roadmap untuk penggunakan tools bantuan.
• Memiliki kemampuan yang mengembangkan komponen-komponen yang dapat digunakan kembali untuk pengembangan aplikasi lainnya. [Falitate Raute]
• Mengatur dan mengontrol semua proses dalam setiap tahapan yang ada sehingga suatu pengembangan perangkat lunak yang kompleks dapat dilakukan dengan aman sesuai dengan harapan pengguna [Manage Complexity]
• Perubahan yang teralokasi dan masalah dapat dengan mudah terdeteksi sehingga biaya pemeliharaan dapat ditekan sekecil mungkin [Lower Maintenece cost].
• Tentunya menghasilkan perangkat lunak yang berkualitas karena telah teruji.

Lebih dari ribuah perusahaan yang menggunakan Rational Unified Process sejak akhir tahun 1999. Ini menunjukan banyaknya manfaat dan kemampuan cocok yang luas dari Rational Unified Process. Contoh perusahaan yang menggunakan Rational Unified Process, antara lain :

• Bidang telekomunikasi:

Ericsson, Alcatel,MCI

• Bidang tranportasi, aorespace, pertahanan:

British Aorespace

• Manufaktur

Xerox, Volvo, Intel

• Keuangan

Visa, Schwab

• Dan lain-lain

Referensi by      http://blog.unsri.ac.id/aswin/ooad/rational-unified-process/mrdetail/161/

http://ladast.blogspot.com/2009/02/rational-unified-process.html

http://www.pakgaol.com/2013/03/rational-unified-process.html

OOAD (Objek Oriented Analisa desain)

stmik eresha

Objek Oriented analisa dan desain berbasis Objek

[Type the document subtitle]

the ono

[Pick the date]

Mata kuliah OOAD berbasis objek  by ono suprono

I. Pengertian dan Konsep OOAD

Analisis dan disain berorientasi objek adalah cara baru dalam memikirkan suatu masalah dengan menggunakan model yang dibuat menurut konsep sekitar dunia nyata. Dasar pembuatan adalah objek, yang merupakan kombinasi antara struktur data dan perilaku dalam satu entitas.

Pengertian “berorientasi objek” berarti bahwa kita mengorganisasi perangkat lunak sebagai kumpulan dari objek tertentu yang memiliki struktur data dan perilakunya.

Konsep OOAD mencakup analisis dan desain sebuah sistem dengan pendekatan objek, yaiut analisis berorientasi objek (OOA) dan desain berorientasi objek (OOD). OOA adalah metode analisis yang memerika requirement (syarat/keperluan) yang harus dipenuhi sebuah sistem) dari sudut pandang kelas-kelas dan objek-objek yang ditemui dalam ruang lingkup perusahaan. Sedangkan OOD adalah metode untuk mengarahkan arsitektur software yang didasarkan pada manipulasi objek-objek sistem atau subsistem.

OOA (Object Oriented Analysis)

OOA mempelajari permasalahan dengan menspesifikasikannya atau mengobservasi permasalahn tersebut dengan menggunakan metode berorientasi objek. Biasanya analisa sistem dimulai dengan adanya dokumen permintaan (requirement) yang diperoleh dari semua pihak yang berkepentingan. (Misal: klien,developer, pakar, dan lain-lain).

Dokumen permintaan memiliki 2 fungsi yaitu : memformulasikan kebutuhan klien dan membuat suatu daftar tugas. Analisis berorientasi obyek (OOA) melihat pada domain masalah, dengan tujuan untuk memproduksi sebuah model konseptual informasi yang ada di daerah yang sedang dianalisis. Model analisis tidak mempertimbangkan kendala-kendala pelaksanaan apapun yang mungkin ada, seperti konkurensi, distribusi, ketekunan, atau bagaimana sistem harus dibangun. Kendala pelaksanaan ditangani selama desain berorientasi objek (OOD).
Sumber-sumber untuk analisis dapat persyaratan tertulis pernyataan, dokumen visi yang formal, wawancara dengan stakeholder atau pihak yang berkepentingan lainnya. Sebuah sistem dapat dibagi menjadi beberapa domain, yang mewakili bisnis yang berbeda, teknologi, atau bidang yang diminati, masing-masing dianalisis secara terpisah.

Hasil analisis berorientasi objek adalah deskripsi dari apa sistem secara fungsional diperlukan untuk melakukan, dalam bentuk sebuah model konseptual. Itu biasanya akan disajikan sebagai seperangkat menggunakan kasus, satu atau lebih UML diagram kelas, dan sejumlah diagram interaksi. Tujuan dari analisis berorientasi objek adalah untuk mengembangkan model yang menggambarkan perangkat lunak komputer karena bekerja untuk memenuhi seperangkat persyaratan yang ditentukan pelanggan.

UML (Unified Modeling Language) adalah sebuah bahasa yang berdasarkan grafik/gambar untuk memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian dari sebuah sistem pengembangan software berbasis OO (Object-Oriented). UML sendiri juga memberikan standar penulisan sebuah sistem blue print, yang meliputi konsep bisnis proses, penulisan kelas-kelas dalam bahasa program yang spesifik, skema database, dan komponen-komponen yang diperlukan dalam sistem software. Unified Model Language (UML) adalah bahasa universal untuk :

• memvisualisasikan grafis model yang tepat.
• menetapkan model yang tepat, lengkap, dan tidak ambigu untuk mengampil semua keputusan penting dalam analisis, desain dan implementasi.
• membangun model yang dapat dihubungkan langsung dengan bahasa pemrograman.
• mendokumentasikan semua informasi yang dikumpulkan oleh tim sehingga memungkinkan untuk berbagi informasi.

OOD (Object Oriented Design)
OOD mengubah model konseptual yang dihasilkan dalam analisis berorientasi objek memperhitungkan kendala yang dipaksakan oleh arsitektur yang dipilih dan setiap non-fungsional – teknologi atau lingkungan – kendala, seperti transaksi throughput, response time, run – waktu platform, lingkungan pengembangan, atau bahasa pemrograman.

A. Karakteristik dari Objek
1. Objek

• Objek adalah benda secara fisik dan konseptual yang ada di sekitar kita. Sebuah objek memiliki keadaan sesaat yang disebut state.
• Objek dapat kongkrit, seperti halnya arsip dalam sistem, atau konseptual seperti kebijakan penjadwalan dalam multiprocessing pada sistem operasi.
• Dua objek dapat berbeda walaupun bila semua nilai atributnya identik.

Gambar 1. Macam-macam Objek

2. Kelas Objek

Kelas merupakan gambaran sekumpulan Objek yang terbagi dalam atribut, operasi, metode, hubungan, dan makna yang sama.

• Suatu kegiatan mengumpulkan data (atribut) dan perilaku (operasi) yang mempunyai struktur data sama ke dalam satu grup.
• Kelas Objek merupakan wadah bagi Objek. Dapat digunakan untuk menciptakan Objek.
• Objek mewakili fakta/keterangan dari sebuah kelas.

Gambar 2. Kelas dan Objek

Istilah-istilah Objek

• Atribut : Data item yang menegaskan Objek.
• Operasi : Fungsi di dalam kelas yang dikombinasikan ke bentuk tingkah laku kelas.
• Metode : Pelaksanaan prosedur (badan dari kode yang mengeksekusi respon terhadap permintaan objek lain di dalam sistem).

B. Karakteritik Metodologi Berorientasi Objek

Metodologi pengembangan sistem berorientasi objek mempunyai tiga karakteristik utama :

1. Encapsulation (Pengkapsulan)

• Encapsulation merupakan dasar untuk pembatasan ruang lingkup program terhadap data yang diproses.
• Data dan prosedur atau fungsi dikemas bersama-sama dalam suatu objek, sehingga prosedur atau fungsi lain dari luar tidak dapat mengaksesnya.
• Data terlindung dari prosedur atau objek lain, kecuali prosedur yang berada dalam objek itu sendiri.

2. Inheritance (Pewarisan)

• Inheritance adalah teknik yang menyatakan bahwa anak dari objek akan mewarisi data/atribut dan metode dari induknya langsung.
• Atribut dan metode dari objek dari objek induk diturunkan kepada anak objek, demikian seterusnya.
• Inheritance mempunyai arti bahwa atribut dan operasi yang dimiliki bersama di anatara kelas yang mempunyai hubungan secara hirarki.
• Suatu kelas dapat ditentukan secara umum, kemudian ditentukan spesifik menjadi subkelas. Setiap subkelas mempunyai hubungan atau mewarisi semua sifat yang dimiliki oleh kelas induknya, dan ditambah dengan sifat unik yang dimilikinya.
• Kelas Objek dapat didefinisikan atribut dan service dari kelas Objek lainnya.
• Inheritance menggambarkan generalisasi sebuah kelas.

3. Polymorphism (Polimorfisme)

• Polimorfisme yaitu konsep yang menyatakan bahwa seuatu yang sama dapat mempunyai bentuk dan perilaku berbeda.
• Polimorfisme mempunyai arti bahwa operasi yang sama mungkin mempunyai perbedaan dalam kelas yang berbeda.
• Kemampuan objek-objek yang berbeda untuk melakukan metode yang pantas dalam merespon message yang sama.
• Seleksi dari metode yang sesuai bergantung pada kelas yang seharusnya menciptakan Objek.

II. Pemodelan Berorientasi Objek

A. Pemodelan Sebagai Teknik Desain

Teknik pemodelan objek menggunakan tiga macam model untuk menggambarkan sistem, diantaranya adalah sebagai berikut :

1. Model Objek

• Model objek menggambarkan struktur statis dari suatu objek dalam sistem dan relasinya.
• Model objek berisi diagram objek. Diagram objek adalah graph dimana nodenya adalah kelas yang mempunyai relasi antar kelas.

2. Model Dinamik

• Model dinamik menggambarkan aspek dari sistem yang berubah setiap saat.
• Model dinamik dipergunakan untuk menyatakan aspek kontrol dari sistem.
• Model dinamik berisi state diagram. State diagram adalah graph dimana nodenya adalah state dan arc adalah tarnsisi antara state yang disebabkan oleh event.

3. Model Fungsional

• Model fungsional menggambrakan transformasi nilai data di dalam sistem.
• Model fungsional berisi data flow diagram. DFD adalah suatu graph dimana nodenya menyatakan proses dan arcnya adalah aliran data.

B. Model Berorientasi Objek

Sebuah model objek menangkap struktur statis dari sistem dengan menggambarkan objek dalam sistem, hubungan antara objek, serta atribut dan operasi yang merupakan karakteristik setiap kelas dan objek.

Model berorientasi objek lebih mendekati keadaan nyata, dan dilengkapi dengan penyajian grafis dari sistem yang sangat bermanfaat untuk komunikasi dengan user dan pembuatan dokumentasi struktur dari sistem.

1. Objek dan Kelas

> Objek

• Objek didefinisikan sebagai konsep, abstraksi atau benda dengan batasan dan arti untuk suatu masalah.
• Semua objek mempunyai identitas yang berbeda dengan lainnya.
• Istilah identitas berarti bahwa objek dibedakan oleh sifat yang melekat dan bukan dengan uraian sifat yang dimilikinya.
• Contohnya : kembar identik, walaupun mereka nampak seperti sama, tetapi merupakan dua orang yang berbeda.
• Kadang-kadang objek berarti suatu barang, maka digunakan istilah object instance, dan object class untuk menunjukkan satu grup dari barang yang sama.

> Kelas

• Suatu object class menggambarkan kumpulan dari objek yang mempunyai sifat (atribut), perilaku umum (operasi), relasi umum dengan objek lain dan semantik umum.
• Contoh : Orang, perusahaan , binatang, proses adalah objek.
• Setiap orang mempunyai umur, IQ, dan mungkin pekerjaan. Setiap proses mempunyai pemilik, prioritas, list dari sumber daya yang dibutuhkan.
• Objek dan object class sering sama sebagai benda dalam deskripsi masalah.

2. Diagram Objek

Diagram objek melengkapi notasi grafik untuk pemodelan objek, kelas dan relasinya dengan yang lain. Diagram objek bermanfaat untuk pemodelan abstrak dan membuat perancangan program.

> Kelas dan Objek

Konsep fundamental dalam analisis berorientasi objek adalah objek itu sendiri. Sebuah objek adalah sebuah entitas yang mencakup data dan metode.

Kelas merupakan satu atau lebih objek dengan persamaan atribut dan metode, sedangkan kelas-&-objek adalah kelas dengan satu atau lebih objek di dalamnya. Nama kelas adalah kata benda tunggal, atau kata sifat dan kata benda. Nama dari kelas-&-objek harus dapat menjelaskan objek tunggal dari suatu kelas.

Gambar 3. Notasi untuk kelas dan kelas-&-objek

> Struktur Objek dan Hirarki Kelas

- Struktur kelas dibagi dua macam, yaitu Whole-Part Structure dan Gen-Spec Structure.

• Whole-Part Structure memperlihatkan hirarki dari suatu kelas sebagai komponen dari kelas lain yang disebut juga sub objek. Contohnya, kelas Mobil adalah Whole dan komponennya Mesin, Rangka, dan lain-lain, merupakan Part1, Part 2, …, Part n.

Gambar 4. Notasi untuk whole-part structure

• Gen-Spec Structure memperlihatkan kelas sebagai spesialisasi dari kelas di atasnya. Kelas yang mempunyai sifat umum disebut Generalization, Superclass atau Topclass, sedangkan kelas yang mempunyai sifat khusus disebut Specialization.

Gambar 5. Notasi untuk gen-spec structure

Contohnya, kelas Mobil adalah Generalization, sedangkan Sedan, Truk, Minibus, dan lain-lain merupakan Specizlization1, Specialization2, …, Specialization n, yaitu kelas yang mempunyai sifat khusus.

- Atribut

Atribut menggambarkan data yang dapat memberikan informasi mengenai kelas atau objek dimana atribut tersebut berada.

Gambar 6. Notasi untuk atribut

- Metode

Metode (method) disebut juga service atau operator adalah prosedur atau fungsi seperti yang terdapat dalam bahasa Pascal pada umumnya, tetapi cara kerjanya agak berlainan. Metode adalah subprogram yang tergabung dalam objek bersama-sama dengan atribut. Metode dipergunakan untuk pengaksesan terhadap data yang terdapat dalam objek tersebut.

Gambar 7. Notasi untuk metode

- Pesan (Message)
Message merupakan cara untuk berhubungan antara satu objek dengan objek lain. Suatu pesan dikirimkan oleh suatu objek kepada objek tertentu dapat digambarkan dengan anak panah.

Gambar 8. Notasi untuk message

III. UML (Unified Modelling Language)

Unified Modelling Language (UML) adalah sebuah “bahasa” yg telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem. 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. Tetapi karena UML juga menggunakan class dan operation dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa bahasa berorientasi objek seperti C++, Java, C# atau VB.NET. Walaupun demikian, UML tetap dapat digunakan untuk modeling aplikasi prosedural dalam VB atau C. Seperti bahasa-bahasa lainnya, UML mendefinisikan notasi dan syntax /semantik. Notasi UML merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti lunak. Setiap bentuk memiliki makna tertentu, dan UML syntax mendefinisikan bagaimana bentuk-bentuk tersebut dapat dikombinasikan. Notasi UML terutama diturunkan dari 3 notasi yang telah ada sebelumnya: Grady Booch OOD (Object-Oriented Design), Jim Rumbaugh OMT (Object Modeling Technique), dan Ivar Jacobson OOSE (Object-Oriented Software Engineering). 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, metodologi coad, metodologi OOSE, metodologi OMT, metodologi shlaer-mellor, metodologi wirfs-brock, 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.

Jenis-jenis Diagram UML :

A. 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 sistem 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.

B. Class Diagram

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 diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment , pewarisan, asosiasi, dan lain-lain.

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

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 .

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

Hubungan Antar Class

1. Asosiasi, yaitu hubungan statis antar class . Umumnya menggambarkan class yang memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah navigability m enunjukkan arah query antar class .
2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”).
3. Pewarisan, yaitu hubungan hirarkis antar class . Class dapat diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi.
4. Hubungan dinamis, yaitu rangkaian pesan ( message ) yang di- passing dari satu class kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram yang akan dijelaskan kemudian.

C. 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.

D. 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.

E. Sequence Diagram

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.

Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan icon khusus untuk objek boundary, controller dan persistent entity .

F. 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.

G. Component Diagram

Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan ( dependency ) di antaranya. 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.

H. Deployment Diagram

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.

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. Buarlah 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 d ipecah 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.

Tool 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)
 

referensi 

http://peterdraw.wordpress.com/2011/10/30/konsep-ooad-object-oriented-analysis-design/

 

           http://dewa-hendra.blogspot.com/2010/04/i.html
           http://sa3o.net/ringkasan-tentang-ooad/