Archive for September, 2011

UML

{ September 13, 2011 @ 7:42 pm } · { PSIBO, SEMESTER 5 }
{ Tinggalkan sebuah Komentar }

  • Visual Modelling

 

   Visual Modelling adalah proses menggambarkan cetak biru suatu sistem secara grafis, terdiri dari komponen-komponen, interfaces dan koneksi-koneksi yang ada dalam sistem tersebut, agar mudah dipahami dan dikomunikasikan.

Visual Modelling dapat membantu kita untuk menampilkan elemen-elemen yang penting secara detil dari suatu masalah yang kompleks dan menyaring untuk kemudian membuang elemen-elemen yang tidak penting.

Rational Rose menggunakan UML sebagai bahasa pemodelannya. Semua semantik dan notasi dalam UML dibuat untuk digunakan dalam visual modelling.

 

  • UML
  1. Sejarah

Tahun 1994, Grady Boch dan James Rumbaugh bergabung untuk menggunakan metode berorientasi objek. Ivan Jacobson bergabung pada tahun 1995, dan mereka bertiga fokus membuat suatu bahasa pemodelan objek standar sebagai ganti dari pendekatan atau metode objek standar. Berdasarkan kerja mereka dan hasil kerja lainnya pada industri, Unified Modeling Language (UML) versi 1.0 dirilis pada tahun 1997.

Unified Modeling Language (UML) tidak menentukan metode untuk sistem-sistem pengembangan, tetapi sudah diterima luas sebagai standar untuk pemodelan objek. Object Management Gorup/OMG, badan standar industri, mengadopsi UML pada bulan November 1997 dan terus bekerja sama untuk meningkatkannya berdasarkan kebutuhan industri. Pada saat ini, salah satu industri telah merilis sebuah sofware yang mendukung UML yaitu Visual Paradigm 6.4 Interprise edition. Berbagai industri juga bermunculan dan mendukung penggunaan UML dengan berbagai produk, diantaranya Rational Rose, SmartDraw, dan lain-lain.

 

  1. Definisi

Unified Modelling Language (UML) adalah sebuah “bahasa” yang telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan system piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem. Dengan menggunakan UML dapat dibuat 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 lebih cocok untuk penulisan piranti lunak dalam bahasa berorientasi objek seperti C++, Java, atau VB. NET.

 

  • UML DIAGRAM

Setiap sistem yang kompleks seharusnya bias dipandang dari sudut yang berbeda – beda sehingga bisa mendapatkan pemahaman secara menyeluruh  Untuk upaya tersebut UML menyediakan 9 jenis diagram yang dapat dikelompokkan berdasarkan sifatnya statis atau dinamis. Ke 9 diagram dalam UML itu adalah :

1. Bussines Use Case

Menggambarkan urutan tindakan yang dilakukan oleh suatu bisnis yang menghasilkan sebuah nilai yang dapat dilihat dan ditunjukan untuk suatu business actor tertentu

 

2. Activity

Diagram ini bersifat dinamis. Diagram ini adalah tipe khusus dari diagram state yang memperlihatkan aliran dari suatu aktifitas ke aktifitas lainnya dari suatu sistem. Diagram ini terutama penting dalam pemodelan fungsi – fungsi dalam suatu sistem dan memberi tekanan pada aliran kendali antar objek.

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.

3. Use Case

Diagram ini bersifat statis. Diagram ini memperlihatkan himpunan use case dan aktor-aktor (suatu jenis khusus dari kelas). Diagram ini terutama sangat penting untuk mengorganisasi dan memodelkan perilaku dari suatu sistem yang dibutuhkan serta diharapkan pengguna.

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.

4. Sequence

Diagram ini bersifat dinamis. Diagram sequence merupakan diagram interaksi yang menekankan pada pengiriman pesan (message) dalam suatu waktu tertentu.

 5. Collaboration

Diagram ini bersifat dinamis. Diagram kolaborasi adalah diagram interaksi yang menekankan organisasi struktural dariobjek – objek yang menerima serta mengirim pesan (message).

 6. Class Diagram

Diagram kelas bersifat statis. Diagram ini memperlihatkan himpunan kelas-kelas, antarmuka-antarmuka, kolaborasi-kolaborasi serta relasi.

 

Hubungan Antar Class

  • 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 menunjukkan arah query antar class.
  • Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”).
  • 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.
  • 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.

7. StateChart

Diagram ini bersifat dinamis. Diagram ini memperlihatkan state – state pada sistem, memuat state, transisi, event, serta aktifitas. Diagram ini terutama penting untuk memperlihatkan sifat dinamis dari antarmuka, kelas, kolaborasi dan terutama penting pada pemodelan sistem – system yang reaktif.

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. Dibawah ini adalah contoh gambar StateChart :

 8. Component Diagram

Diagram ini bersifat statis. Diagram ini memperlihatkan organisasi serta kebergantungan pada komponen – komponen yang telah ada sebelumnya. Diagram ini berhubungan dengan diagram kelas dimana komponen secara tipikal dipetakan ke dalam satu atau lebih kelas kelas, antarmuka – antarmuka serta kolaborasi – kolaborasi.

9. Deployment Diagram

Diagram ini bersifat statis. Diagram ini memperlihatkan konfigurasi saat aplikasi dijalankan (saat run time). Dengan ini memuat simpul – simpul (node) beserta komponen – komponen yang ada di dalamnya. Deployment diagram berhubungan erat dengan diagram komponen dimana deployment diagram memuat satu atau lebih komponen – komponen. Diagram ini sangat berguna saat aplikasi berlaku sebagai aplikasi yang dijalankan pada banyak mesin (distributed computing).

Ke 9 diagram ini tidak mutlak harus digunakan dalam pengembangan perangkat lunak, semua dibuat sesuai dengan kebutuhan.

 

 

REKAYASA PERANGKAT LUNAK (SOFTWARE ENGINEERING)

{ September 13, 2011 @ 7:29 pm } · { PSIBO }
{ Tinggalkan sebuah Komentar }

  • Sejarah Software Engineering

Istilah software engineering digunakan pertama kali pada akhir 1950-an dan awal 1960-an. Saat itu, masih terdapat perdebatan tajam mengenai aspek engineering dari pengembangan perangkat lunak. Pada tahun 1968 dan 1969, komite sains NATO mensponsori dua konferensi tentang rekayasa perangkat lunak, yang memberikan dampak kuat terhadap pengembangan rekayasa perangkat lunak. Banyak yang menganggap dua konferensi inilah yang menandai awal resmi profesi rekayasa perangkat lunak.

Pada tahun 1960-an hingga 1980-an, banyak masalah yang ditemukan para praktisi pengembangan perangkat lunak. Banyak project yang gagal, hingga masa ini disebut sebagai krisis perangkat lunak. Kasus kegagalan pengembangan perangkat lunak terjadi mulai dari project yang melebihi anggaran, hingga kasusu yang mengakibatkan kerusakan fisik dan kematian. Salah satu kasus yang terkenal antara lain meledaknya roket Ariane akibat kegagalan perangkat lunak. Selama bertahun-tahun, para peneliti memfokuskan usahanay untuk menemukan teknik jitu untuk memecahkan masalah krisi perangkat lunak. Berbagai teknik, metode, alat, proses diciptakan dan diklaim sebagai senjata pamungkas untuk memecahkan kasus ini. Mulai dari pemrograman terstruktur, pemrograman berorientasi objek, pernagkat pembantu pengembangan perangkat lunak (CASE tools), berbagai standar, UML hingga metode formal diagung-agungkan sebagai senjaat pamungkas untuk menghasilkan software yang benar, sesuai anggaran dan tepat waktu. Pada tahun 1987, Fred Brooks menulis artikel No Silver Bullet, yang berproposisi bahwa tidak ada satu teknologi atau praktek yang sanggup mencapai 10 kali lipat perbaikan dalam produktivitas pengembanan perngkat lunak dalam tempo 10 tahun.

Sebagian berpendapat, no silver bullet berarti profesi rekayasa perangkat lunak dianggap telah gagal. Namun sebagian yang lain justru beranggapan, hal ini menandakan bahwa bidang profesi rekayasa perangkat lunak telah cukup matang, karena dalam bidang profesi lainnya pun, tidak ada teknik pamungkas yang dapat digunakan dalam berbagai kondisi.

  • Pengertian Dasar

Istilah Reakayasa Perangkat Lunak (RPL) secara umum disepakati sebagai terjemahan dari istilah Software engineering. Istilah Software Engineering mulai dipopulerkan pada tahun 1968 pada software engineering Conference yang diselenggarakan oleh NATO. Sebagian orang mengartikan RPL hanya sebatas pada bagaimana membuat program komputer. Padahal ada perbedaan yang mendasar antara perangkat lunak (software) dan program komputer.

Perangkat lunak adalah seluruh perintah yang digunakan untuk memproses informasi. Perangkat lunak dapat berupa program atau prosedur. Program adalah kumpulan perintah yang dimengerti oleh komputer sedangkan prosedur adalah perintah yang dibutuhkan oleh pengguna dalam memproses informasi (O’Brien, 1999).

Pengertian RPL sendiri adalah suatu disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal yaitu analisa kebutuhan pengguna, menentukan spesifikasi dari kebutuhan pengguna, disain, pengkodean, pengujian sampai pemeliharaan sistem setelah digunakan. Dari pengertian ini jelaslah bahwa RPL tidak hanya berhubungan dengan cara pembuatan program komputer. Pernyataan ”semua aspek produksi” pada pengertian di atas, mempunyai arti semnua hal yang berhubungan dengan proses produksi seperti manajemen proyek, penentuan personil, anggaran biaya, metode, jadwal, kualitas sampai dengan pelatihan pengguna merupakan bagian dari RPL.

  • TUJUAN REKAYASA PERANGKAT LUNAK

Secara umum tujuan RPL tidak berbeda dengan bidang rekayasa yang lain. Hal ini dapat kita lihat pada Gambar di bawah ini.

Dari Gambar di atas dapat diartikan bahwa bidang rekayasa akan selalu berusaha menghasilkan output yang kinerjanya tinggi, biaya rendah dan waktu penyelesaian yang tepat. Secara leboih khusus kita dapat menyatakan tujuan RPL adalah:

  1. memperoleh biaya produksi perangkat lunak yang rendah
  2. menghasilkan pereangkat lunak yang kinerjanya tinggi, andal dan tepat waktu
  3. menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis platform
  4. menghasilkan perangkat lunak yang biaya perawatannya rendah

 

  • RUANG LINGKUP

Sesuai dengan definisi yang telah disampaikan sebelumnya, maka ruang lingkup RPL dapat digambarkan sebagai berikut:

–          software Requirements berhubungan dengan spesifikasi kebutuhan dan persyaratan perangkat lunak

–          software desain mencakup proses penampilan arsitektur, komponen, antar muka, dan karakteristik lain dari perangkat lunak

–          software construction berhubungan dengan detail pengembangan perangkat lunak, termasuk algoritma, pengkodean, pengujian dan pencarian kesalahan

–          software testing meliputi pengujian pada keseluruhan perilaku perangkat lunak

–          software maintenance mencakup upaya-upaya perawatan ketika perangkat lunak telah dioperasikan

–          software configuration management berhubungan dengan usaha perubahan konfigurasi perangkat lunak untuk memenuhi kebutuhan tertentu

–          software engineering management berkaitan dengan pengelolaan dan pengukuran RPL, termasuk perencanaan proyek perangkat lunak

–          software engineering tools and methods mencakup kajian teoritis tentang alat bantu dan metode RPL

–          software engineering process berhubungan dengan definisi, implementasi pengukuran, pengelolaan, perubahan dan perbaikan proses RPL

–          software quality menitik beratkan pada kualitas dan daur hidup perangkat lunak

  • PERKEMBANGAN REKAYASA PERANGKAT LUNAK

Meskipun baru dicetuskan pada tahun 1968, namun RPL telah memiliki sejarah yang cukup yang panjang. Dari sisi disiplin ilmu, RPL masih reklatif muda dan akan terus berkembang.

  • METODE REKAYASA PERANGKAT LUNAK

Pada rekayasa perangkat lunak, banyak model yang telah dikembangkan untuk membantu proses pengembangan perangkat lunak. Model-model ini pada umumnya mengacu pada model proses pengembangan sistem yang disebut System Development Life Cycle (SDLC) .

  • Kebutuhan terhadap definisi masalah yang jelas.  Input utama dari setiap model pengembangan perangkat lunak adalah pendefinisian masalah yang jelas.  Semakin jelas akan semakin baik karena akan memudahkan dalam penyelesaian masalah.  Oleh karena itu pemahaman masalah seperti dijelaskan pada Bab 1, merupakan bagian penting dari model pengembangan perangkat lunak.
  • Tahapan-tahapan pengembangan yang teratur.  Meskipun model-model pengembangan perangkat lunak memiliki pola yang berbeda-beda, biasanya model-model tersebut mengikuti pola umum  analysis – design – coding – testing – maintenance
  • Stakeholder berperan sangat penting dalam keseluruhan tahapan pengembangan.  Stakeholder dalam rekayasa perangkat lunak dapat berupa pengguna, pemilik, pengembang, pemrogram dan orang-orang yang terlibat dalam rekayasa perangkat lunak tersebut.
  • Dokumentasi merupakan bagian penting dari pengembangan perangkat lunak.  Masing-masing tahapan dalam model biasanya menghasilkan sejumlah tulisan, diagram, gambar atau bentuk-bentuk lain yang harus didokumentasi dan merupakan bagian tak terpisahkan dari perangkat lunak yang dihasilkan.
  • Keluaran dari proses pengembangan perangkat lunak harus bernilai ekonomis.  Nilai dari sebuah perangkat lunak sebenarnya agak susah di-rupiah-kan.  Namun efek dari penggunaan perangkat lunak yang telah dikembangkan haruslah memberi nilai tambah bagi organisasi. Hal ini dapat berupa penurunan biaya operasi,  efisiensi penggunaan sumberdaya, peningkatan keuntungan organisasi, peningkatan “image” organisasi dan lain-lain.
  • TAHAPAN REKAYASA PERANGKAT LUNAK

Meskipun dalam pendekatan berbeda-beda, namun model-model pendekatan memiliki kesamaan, yaitu menggunaka pola tahapan analysis – design – coding(construction) – testing – maintenance.

  1. Analisis sistem adalah sebuah teknik pemecahan masalah yang menguraikan sebuah sistem menjadi komponen-komponennya dengan tujuan mempelajari seberapa bagus komponen-komponen tersebut bekerja dan berinteraksi untuk meraih tujuan mereka. Analisis mungkin adalah bagian terpenting dari proses rekayasa perangkat lunak.  Karena semua proses lanjutan akan sangat bergantung pada baik tidaknya hasil analisis. Ada satu bagian penting yang biasanya dilakukan dalam tahapan analisis yaitu pemodelan proses bisnis.
  2. Model proses adalah model yang memfokuskan pada seluruh proses di dalam sistem  yang mentransformasikan data menjadi informasi (Harris, 2003).  Model proses juga menunjukkan aliran data yang masuk dan keluar pada suatu proses.  Biasanya model ini digambarkan dalam bentuk Diagram Arus Data (Data Flow Diagram / DFD).  DFD meyajikan gambaran apa yang manusia, proses dan prosedur lakukan untuk mentransformasi data menjadi informasi.
  3. Disain perangkat lunak  adalah tugas, tahapan atau aktivitas yang difokuskan pada spesifikasi detil dari solusi berbasis computer (Whitten et al, 2004).Disain perangkat lunak sering juga disebut sebagai physical design.  Jika tahapan analisis sistem menekankan pada masalah bisnis (business rule), maka sebaliknya disain perangkat lunak fokus pada sisi teknis dan implementasi sebuah perangkat lunak (Whitten et al, 2004).Output utama dari tahapan disain  perangkat lunak adalah spesifikasi disain.  Spesifikasi ini meliputi spesifikasi disain umum yang akan disampaikan kepada stakeholder sistem dan spesifikasi disain rinci yang akan digunakan pada tahap implementasi.  Spesifikasi disain umum hanya berisi gambaran umum agar stakeholder sistem mengerti akan seperti apa perangkat lunak yang akan dibangun.  Biasanya diagram USD tentang perangkat lunak yang baru merupakan point penting dibagian ini.   Spesifikasi disain rinci atau kadang disebut disain arsitektur rinci perangkat lunak diperlukan untuk merancang sistem sehingga memiliki konstruksi yang baik, proses pengolahan data yang tepat dan akurat, bernilai, memiliki aspek user friendly dan memiliki dasar-dasar untuk pengembangan selanjutnya.Desain arsitektur ini terdiri dari desain database, desain proses, desain user interface  yang mencakup desain  input,  output form dan report, desain hardware, software dan jaringan.  Desain proses merupakan kelanjutan dari pemodelan proses yang dilakukan pada tahapan analisis.
  4. Konstruksi adalah tahapan menerjemahkan hasil disain logis dan fisik ke dalam kode-kode program komputer.
  5. Pengujian sistem melibatkan semua  kelompok pengguna yang telah direncanakan pada tahap sebelumnya. Pengujian tingkat penerimaan terhadap perangkat lunak akan berakhir ketika dirasa semua kelompok pengguna menyatakan bisa menerima perangkat  lunak tersebut berdasarkan kriteria-kriteria yang telah ditetapkan.
  6. Perawatan dan Konfigurasi. Ketika sebuah perangkat lunak telah dianggap layak untuk dijalankan, maka tahapan baru menjadi muncul yaitu perawatan perangkat lunak.  Ada beberapa tipe perawatan yang biasa dikenal dalam dunia perangkat lunak  yaitu :
  • Tipe perawatan  corrective dilakukan jika terjadi kesalahan atau biasa dikenal sebagai bugs.  Perawatan  bisa dilakukan dengan memperbaiki kode program, menambah bagian  yang dirasa perlu atau malah menghilangkan bagian-bagian tertentu.
  • Tipe perawatan  routine biasa juga disebut preventive maintenance dilakukan secara rutin untuk melihat kinerja perangkat lunak ada atau tidak ada kesalahan.
  • Tipe perawatan  sistem upgrade dilakukan jika ada perubahan dari komponen-komponen yang terlibat  dalam perangkat lunak tersebut. Sebagai contoh perubahan platform sistem operasi dari versi lama ke versi baru menyebabkan perangkat lunak harus diupgrade.