Rational Unified Proses

RUP (Rational Unified Process)

A.   Sejarah

RUP yang dikembangkan oleh Rational software adalah hasil kerjasama antara Grady Booch, James Rumbaugh, dan Ivar Jacobson dalam menyusun suatu metodologi yang digunakan untuk membangun software. RUP sendiri merupakan suatu metodologi pembangunan software..

RUP menyediakan suatu pendekatan untuk menangani pekerjaan dan tanggung jawab dalam pengembanganan. RUP bertujuan untuk  menghasilkan suatu software yang sesuai dengan kebutuhan dari end-user nya, pada jangka waktu dan biaya yang terukur.

B. Konsep

     RUP merupakan metodologi pengembangan software yang berasal dari pengalaman empiris pengembangan software skala besar. Maka wajar apabila RUP memiliki rangkaian penyusun yang sangat komprehensif.

     RUP merupakan metodologi yang  general, artinya RUP membutuhkan suatu penyesuaian apabila akan diimplementasikan pada suatu proyek pengembangan software.  RUP memiliki  core values  yang terdiri dari :

·         Use case driven design

·          Process Tailoring

·         Tools Support

      RUP menjadikan use case sebagai dasar bagi proses pengmbangan  software  dari tahap ke tahap. Ada beberapa practical work  yang digunakan dalam  RUP yaitu :

·         Pengembangan iteratif

·         Manajemen kebutuhan (Requirement Management)

·         Arsitektur  component-based

·         Pemodelan visual

·         Perbaikan kualitas software secara berkesinambungan

·         Manajemen perubahan (Change management)

RUP memiliki empat elemen pemodelan yang utama yaitu :

·         Roles—who doing what?

·         Artifacts—what is produced

·         Activities—how the work is conducted

·         Workflow—when the task is conducted

RUP memiliki setidaknya 40 roles dan 80 artefak.  Dengan metodologi yang omprehensif dan kompleks itu RUP tepat digunakan untuk metodologi pembangunan software yang berskala besar. RUP dikatakan sebagai metodologi yang cukup berat untuk digunakan.

RUP dikatakan sebagai metodologi yang bukan agile modelling meskipun terdapat plugin RUP untuk agile modelling. RUP juga merupakan metodologi yang menganut paham top-down solution

Secara historis RUP lahir dari suatu proyek besar yang kompleks. RUP lebih mendasarkan metodologinya pada suatu perspektif teknik. Dari filosofi itulah jelas bahwa RUP merupakan suatu metodologi yang  lengkap untuk suatu proyek pengembangan software. RUP sangat kompleks dan besar sehingga penggunaannya lebih diarahkan kepada proyek pembangunan software skala besar. Sedangakan proyek yang tergolong skala kecil dan menengah akan sangat memakan resource.

RUP di lihat secara teknis, financial,dan sosial:

1. Teknis

           RUP merupakan suatu kumpulan proses, artefak dan roles yang digunakan  untuk panduan mengembangkan software. RUP menyediakan tools dan standar dokumentasi yang terorganisasi dengan baik untuk  proyek software skala besar. Untuk kebutuhan proses, artefak, dokumentasi dan sebagianya RUP menggunakan tools dalam penerapannya. RUP menggunakan dokumentasi untuk komunikasi antar sub-team pada proyeknya. Seperti telah disebutkan sebelumnya, RUP merupakan suatu metodologi yang berat, besar dan kompleks. Selain itu RUP juga merupakan metodologi yang sangat general. Untuk menerapkan RUP dalam suatu proyek, developer perlu menyesuaikan RUP sesuai dengan kebutuhan proyek. 

2. Finansial

RUP yang dikembangkan oleh Rational Software dan sekarang dimiliki oleh IBM merupakan produk yang komersial. Mengenai metodologi yang ditawarkan RUP bisa didapatkan melalui buku dan  tools untuk RUP dikomersialkan oleh Rational Software. RUP yang dimaintain secara berkala, sehingga apabila terjadi update pada metodologi ataupun toolsnya, hal itu ditangani oleh Rational Software.  Dengan dukungan finansial yang baik dan reputasi IBM, RUP menjadi metodologi yang cukup  meyakinkan.

3. Sosial

Perbedaan efek sosial  kedua metodologi ini masih dipengaruhi oleh sisi finansial. RUP yang sifatnya komersil dan berlisensi lebih dipercaya karena reputasi IBM dan kekuatan finansialnya. Software developer skala besar mengaku lebih yakin dengan membeli metodologi yang berlisensi.

Jangka waktu yang digunakan untuk pembangunan software dengan RUP biasanya dalam ukuran minggu atau bulan. Untuk suatu tahap dalam RUP biasanya dibutuhkan waktu mingguan atau bulanan. RUP merupakan metodologi yang besar dam komunikasi yang digunakan menggunakan dokumentasi sehingga pada fase-fase awal dan tahap permulaan pembangunan software, kinerja tim dikerahkan untuk pembuatan dokumen-dokumen analisa dan desain yang akan digunakan untuk pengembangan pada tahap selanjutnya.

Dalam penerapannya, RUP fleksibilitas yang tinggi. RUP dapat disesuaikan dengan kondisi dari proyek yang akan dibangun. RUP akan menyesuaikan dengan kebutuhan dan konteks yang berbeda,

      Proyek software dengan RUP mendasarkan pengembangannya pada use case. RUP tetap beranggapan bahwa proses planning pada pembangunan software tidak dapat dilakukan secara detail sehingga untuk RUP planning dikembangkan secara terus menerus RUP tetap melibatkan customer dalam pengembangan  software. Dalam RUP, customer  tidak terlibat dalam tim dan hanya sebagai source dari requirements dan customer pun tidak perlu person tapi bisa suatu institusi. Sedangkan untuk releasenya, RUP menganggap versi produk yang stabil dan executable dianggap sebagai release.

      Anggota tim dalam pengembagan software dengan RUP dibagi-bagi menjadi subteam-subteam yang memiliki tugas dan tanggung jawab sendiri-sendiri dimana antara subteam tersebut komunikasi dilakukan dengan dokumentasi.  Setiap sub tim dipandu oleh manajemen dalam pekerjaannya dan mereka harus dapat menyiapkan dan menjaga artefak dari software.

RUP menggunakan konsep object oriented, dengan aktifitas yang berfokus pada pengembangan model dengan menggunakan Unified Model Language (UML). Melalui gambar dibawah dapat dilihat bahwa RUP memiliki, yaitu:

·         Dimensi pertama digambarkan secara horizontal. Dimensi ini mewakili aspek-aspek dinamis dari pengembangan perangkat lunak. Aspek ini dijabarkan dalam tahapan pengembangan atau fase. Setiap fase akan memiliki suatu major milestone yang menandakan akhir dari awal dari phase selanjutnya. Setiap phase dapat berdiri dari satu beberapa iterasi.  Dimensi ini terdiri atas Inception,Elaboration, Construction, dan Transition.

·         Dimensi kedua digambarkan secara vertikal. Dimensi ini mewakili aspek-aspek statis dari proses pengembangan perangkat lunak yang dikelompokkan ke dalam beberapa disiplin. Proses pengembangan perangkat lunak yang dijelaskan kedalam beberapa disiplin terdiri dari empat elemen penting, yakni who is doing,what, how dan when. Dimensi ini terdiri atas

Business Modeling, Requirement, Analysis and Design, Implementation, Test, Deployment, Configuration dan Change Manegement, Project Management, Environtment.

Gambar  Arsitektur Rational Unified Process

Pada penggunaan kedua standard tersebut diatas yang berorientasi obyek (object orinted) memiliki manfaat yakni:

• Improve productivity

Standard ini dapat memanfaatkan kembali komponen-komponen yang telah tersedia/dibuat sehingga dapat meningkatkan produktifitas

• Deliver high quality system

Kualitas sistem informasi dapat ditingkatkan sebagai sistem yang dibuat pada komponen­komponen yang telah teruji (well-tested dan well-proven) sehingga dapat mempercepat delivery sistem informasi yang dibuat dengan kualitas yang tinggi.

• Lower maintenance cost

Standard ini dapat membantu untuk menyakinkan dampak perubahan yang terlokalisasi dan masalah dapat dengan mudah terdeteksi sehingga hasilnya biaya pemeliharaan dapat dioptimalkan atau lebih rendah dengan pengembangan informasi tanpa standard yang jelas.

• Facilitate reuse

Standard ini memiliki kemampuan yang mengembangkan komponen-komponen yang dapat digunakan kembali untuk pengembangan aplikasi yang lainnya.

• Manage complexity

Standard ini mudah untuk mengatur dan memonitor semua proses dari semua tahapan yang ada sehingga suatu pengembangan sistem informasi yang amat kompleks dapat dilakukan dengan aman dan sesuai dengan harapan semua manajer proyek IT/IS yaknideliver good quality software within cost and schedule time and the users accepted.

Empat Fasa Siklus Proyek RUP

Pada RUP didefinisikan terdapat empat fasa siklus proyek. Fasa-fasa ini memungkinkan untuk disajikan dalam bentuk umum mirip dengan pendekatan air terjun, walaupun esensi kunci dari proses terdapat dalam iterasi dalam setiap fasenya. Setiap fase memiliki sebuah objektif kunci dan titik pencapaian akhir yang menandakan ketercapaian objektif. Visualisasi dari fase RUP berikut dengan sumbu waktu dinamakan sebagai grafik RUP hump.

Fasa Insepsi

Objektif primer adalah untuk membatasi sistem dengan cukup sebagai dasar untuk memvalidasi biaya awal dan penganggaran. Pada fasa ini, ditentukan kasus bisnis yaitu: konteks bisnis, faktor sukses (perkiraan pendapatan, pengenalan ke pasar, dll.), dan perkiraan finansial. Sebagai pelengkap kasus bisnis adalah model penggunaan, perencaan proyek, penilaian risiko tahap awal, dan deskripsi proyek disusun.

Fasa Elaborasi

Objektif primer adalah untuk memitigasi risiko kunci yang diidentifikasi dari analisis hingga akhir fase. Fasa elaborasi merupakan fase saat proyek mulai terlihat bentuknya. Pada fase ini, masalah analisis domain dibuat dan arsitektur proyek mulai mendapatkan bentuk dasarnya.

Fasa Konstruksi

Objektif primer adalah untuk membangun sistem perangkat lunak. Fase ini fokus pada pengembangan komponen dan fitur lain dari sistem. Pada fase inilah saat banyak dilakukan pengkodean. Pada proyek yang lebih besar, beberapa iterasi konstruksi dikembangkan sebagai usaha untuk memecah kasus penggunaan menjadi segmen terkelola yang menunjukkan purwarupa.

Fasa Transisi

Objektif primer adalah sebagai perantara sistem dari pengembangan ke produksi, yang tersedia untuk pengguna akhir. Aktivitas dalam fase ini termasuk pelatihan kepada pengguna akhir dan pengelola sistem dan pengujian beta untuk memvalidasi terhadap harapan pengguna akhir.

sumber: METODE RUP : wina Fatimah

                                           taryana suyana  

                                           margaret rouse   

Analisis berorientasi objek dan desain

Analisis berorientasi objek dan desain: Sebuah pendekatan baru untuk pengembangan sistem

Analisis berorientasi objek dan desain (OOAD) adalah sebuah pendekatan alternatif untuk memecahkan masalah dalam pengembangan sistem. Tidak seperti kedua pendekatan klasik dan terstruktur yang berfokus pada proses pembangunan, analisis berorientasi obyek dan metode desain menekankan definisi, struktur, dan penggunaan data. Konsentrasi pada benda, atau entitas data, dan serangkaian prosedur dan fungsi yang mendefinisikan operasi yang berarti pada benda tersebut. Metode OOAD yang didasarkan pada 3 konstruksi dasar: 1. definisi objek, 2. konsep kelas, dan 3. konsep warisan. Keuntungan dari pendekatan ini dapat diringkas sebagai: 1. baik pengguna / komunikasi analis dan dengan demikian lebih mudah pemodelan, 2. reuseability kode, 3. meningkatkan fleksibilitas, dan 4. peningkatan produktivitas dan keandalan yang lebih baik. Teknik OOAD telah terbukti sukses dan interface komputer-aided design dan aplikasi rekayasa. Hal ini menunjukkan bahwa pertimbangan manfaat OOAD sebagai sistem yang dikembangkan dalam metode lain mulai diganti.

Kedua klasik dan terstruktur pendekatan untuk fokus pengembangan sistem pada proses. Analisis berorientasi objek dan desain mendefinisikan obyek sistem yang ditindaklanjuti. Artikel ini mendefinisikan konstruksi yang mendasari pendekatan berorientasi objek, alat dan teknik.

Meskipun sistem bisnis pertama komputerisasi yang mulai digunakan hampir empat puluh tahun yang lalu, pengembangan dan pemeliharaan sistem dan perangkat lunak mereka masih tetap merupakan proses yang lambat dan tidak tepat. Hal ini terjadi, sebagian, karena proses pembangunan padat karya dan hingga saat ini telah membuat penggunaan alat-alat relatif sedikit untuk meningkatkan produktivitas. Sistem analisis, desain dan implementasi lebih rumit oleh kebutuhan untuk menerapkan teknologi informasi untuk bisnis dan masalah organisasi dan dengan demikian mengharuskan sistem profesional dan bisnis "pengguna" bekerja sama. Karena kedua kelompok sering memiliki tujuan yang saling bertentangan dan perspektif, dan latar belakang pendidikan yang berbeda, mereka bisa tidak memiliki dasar umum untuk komunikasi yang efisien dan prestasi bersama.

Banyak penelitian dan diskusi telah dikhususkan untuk proses pengembangan sistem. Awalnya, perhatian terfokus pada memperbaiki kegiatan siklus pengembangan sistem kehidupan klasik dengan fase tradisional analisis, desain, implementasi, operasi konversi, dan pemeliharaan. Alat tradisional termasuk diagram alur, narasi, tabel keputusan dan serangkaian semakin "prosedur-berorientasi" bahasa yang dirancang untuk meringankan beban pemrograman.

Sementara pendekatan klasik membantu untuk meningkatkan efisiensi proses pembangunan, itu tidak mengatasi beberapa masalah yang paling dasar. Pengembangan sistem dasarnya tetap tugas yang keberhasilan atau kegagalan itu bergantung pada kemampuan individu dengan sedikit proses "sistematisasi." Ini juga gagal untuk menyediakan analis dan pengguna dengan alat untuk memodelkan masalah atau untuk berkomunikasi dengan satu sama lain dalam "bahasa yang umum."

BERUBAH PERSPEKTIF ANALISIS SISTEM DAN TEKNIK DESAIN

Pengenalan analisis terstruktur dan desain teknik (SADT), dimulai pada akhir 1960-an dan terus ke 1970-an, mengubah proses pengembangan sistem dengan mencoba untuk mengatasi kelemahan. Pendekatan terstruktur berusaha untuk memperkenalkan metodologi standar dan definisi / alat dokumentasi. Metode ini ditujukan masalah komunikasi dengan memperkenalkan alat-alat yang dapat dengan mudah dikembangkan dan dipahami oleh kedua analis / desainer dan pengguna.

Metodologi yang digunakan dalam pengembangan terstruktur menekankan sifat perubahan kebutuhan pengguna. Sementara pendekatan klasik "membeku" spesifikasi sekali implementasi telah dimulai, desainer menggunakan metode terstruktur dipahami bahwa persyaratan bisa muncul selama proses pembangunan. Dengan membagi sistem menjadi modul dengan interface yang telah ditetapkan, menjadi mungkin untuk membuat perubahan dalam setiap modul satu tanpa mempengaruhi seluruh sistem. Dengan demikian, metode terstruktur yang cukup fleksibel untuk memungkinkan beberapa modifikasi seluruh pembangunan.

Namun, perubahan yang paling signifikan terhadap proses pembangunan datang dengan pengenalan pendekatan "top down" dengan definisi masalah dan desain sistem. Setelah batas-batas sistem yang didefinisikan, masalah bisa diurai sampai dibagi menjadi potongan-potongan terpisah dengan masing-masing bagian melakukan satu dan hanya satu fungsi dan hubungan dengan "dunia luar" yang diminimalkan. Ini pengenalan waktu "modularitas" berkurang dihabiskan dalam pembangunan dan kemudian dalam pemeliharaan.

Meskipun analisis terstruktur dan desain teknik telah meningkatkan proses pembangunan, kegagalan proyek besar masih terus terjadi. Pengalaman menunjukkan bahwa masalah mendasar timbul karena analisis terstruktur dan metode desain tetap berorientasi proses. Alat analisis terstruktur, seperti diagram aliran data, yang berguna ketika mendokumentasikan "bagaimana" tugas dilakukan, tetapi mereka tidak mengatasi "apa" yang sedang ditindaklanjuti.

Selang ini telah menghasilkan kegagalan berulang dari pengguna dan analis untuk berkomunikasi. Ketika pengguna dan analis memulai pada proses definisi masalah dengan menggunakan teknik terstruktur, masing-masing memberikan kontribusi keahlian untuk proses pembangunan - analis dalam pemahaman tentang metode pengembangan dan alat-alat dan pengguna dalam pengetahuan pakar kegiatan usaha. Namun, pengguna dan analis mungkin tidak dapat berkomunikasi karena mereka tidak "berbicara bahasa masing-masing."

Tantangan bagi analis adalah untuk model kerangka konseptual pengguna menggunakan alat yang tersedia, seperti diagram aliran data, tabel keputusan, dan Inggris terstruktur. Jika pengguna belum dilatih untuk memahami alat-alat desain, dia / dia tidak akan mampu memahami atau memverifikasi "model."Sebelum proses pemodelan sistem dapat dimulai, analis harus memahami kosakata pengguna. Dalam kebanyakan kasus, masalah bisnis cukup kompleks sehingga ini tidak dapat dilakukan dengan menggunakan proses informal. Alat terstruktur menentukan tindakan atau "bagaimana" dari proses, tetapi mereka gagal memberikan pemahaman lengkap dari kosakata dengan mengabaikan untuk menentukan objek yang ditindaklanjuti atau "apa" dari proses.

PENDAHULUAN DARI OBJEK-BERORIENTASI ANALISIS DAN DESAIN

Sejak pertengahan tahun 1980-an ada telah berkembang minat kalangan peneliti sistem pendekatan alternatif untuk pengembangan sistem yang disebut berorientasi objek analisis dan desain (OOAD). Meskipun analisis terstruktur dan pendekatan desain teknik telah menerima penerimaan luas, beberapa profesional sistem mengkritik kegagalan mereka untuk menempatkan penekanan yang cukup pada definisi dan pemahaman data. Sebaliknya, berorientasi objek analisis dan desain metode menekankan definisi, struktur dan penggunaan data. Konsentrasi pada "benda" atau entitas data dan serangkaian prosedur dan fungsi yang mendefinisikan operasi yang berarti pada benda tersebut.

Definisi obyek merangkum kedua negara dan perilaku. Metode berorientasi objek analisis dan desain menggunakan teknik grafis yang banyak untuk mendefinisikan sistem. Sedangkan data flow diagram yang digunakan dalam analisis terstruktur dan desain untuk menentukan transformasi data, informasi model dan model negara yang digunakan dalam analisis berorientasi objek dan desain untuk menentukan pertama unit konseptual yang analis akan bekerja dengan dan kemudian negara-negara masing-masing unit mungkin diperlukan pada waktu tertentu.

Apapun teknik pengembangan yang dipilih, terstruktur atau berorientasi objek, mereka berbagi gol. Ini adalah untuk menciptakan suatu lingkungan di mana profesional sistem dan pengguna sistem informasi dapat bertemu pada "landasan bersama" dan memahami satu sama lain karena mereka bertukar informasi tentang sistem yang ada dan harapan mereka untuk pengembangan sistem baru. Salah satu metode desain terstruktur, upaya untuk mencapainya melalui proses analisis pertama, yang lain, desain berorientasi obyek, dengan menganalisis data. Pilihan tergantung pada penilaian pengguna terhadap efektivitas dan efisiensi, pertama dalam pemodelan masalah, dan kemudian dalam merancang dan menerapkan sebuah sistem yang akan menyelesaikannya.

Karena banyak pengguna yang sudah memiliki pengalaman dengan teknik terstruktur, hanya review singkat dari metodologi ini disajikan. Namun, pendekatan berorientasi objek baru dibahas panjang lebar dan potensi manfaat bagi pengguna manajemen yang disorot.

AN OVERVIEW ANALISIS TERSTRUKTUR DAN DESAIN

Analisis terstruktur dan desain teknik yang dikembangkan sebagai perbaikan / penggantian untuk pendekatan desain klasik dan siklus sistem tradisional hidup pengembangan. Dalam analisis terstruktur dan desain, sistem ini dibagi menjadi modul proses, antarmuka data (hubungan) antara modul diidentifikasi dan kemudian transformasi (kegiatan atau prosedur) yang terjadi di dalam modul secara hati-hati didefinisikan. Diagram aliran data, diagram struktur data, deskripsi transformasi dan "bahasa terstruktur" adalah alat dasar dari pendekatan ini. Analisis terstruktur dan desain mewujudkan konsep hirarki pengolahan. Analisis dan desain hasil dalam iterative dari definisi umum tentang apa yang harus dilakukan, dengan spesifikasi semakin rinci modul yang mencapai fungsi masing-masing dalam apa yang biasanya disebut sebagai hubungan "top-down".

Analisis terstruktur dimulai dengan dokumentasi aliran data saat ini fisik. Definisi awal ii dinyatakan dalam "yang melakukan tugas" dan didokumentasikan dengan menggunakan diagram aliran data. Setelah definisi awal selesai, itu kemudian disajikan kembali. Referensi untuk "siapa yang melakukan tugas" diganti dengan deskripsi dari "apa yang sedang dilakukan." Proses ini disebut "logicalizing." Setelah "logicalizing" aliran data saat dilakukan, analis dan pengguna dapat fokus pada fungsi tanpa mempertimbangkan apa prosedur atau teknologi yang saat ini digunakan untuk mencapainya. Para analis dan pengguna sekarang dapat menentukan bagaimana proses logis dapat diubah untuk meringankan masalah operasi saat ini. Data flow diagram logis dari lingkungan saat ini kemudian digambar ulang untuk mencerminkan perubahan ini. Setelah lingkungan baru telah dijelaskan secara logis, analis alamat "yang akan melakukan tugas di lingkungan baru?" Kemudian, data fisik flow diagram menggambarkan proses masa depan dikembangkan.

Deskripsi logis dan fisik lingkungan baru yang digunakan dalam desain dan tahapan pelaksanaan. Spesifikasi ini terstruktur merupakan seperangkat alat yang terintegrasi, khusus, diagram alur data, menunjukkan fungsi utama dan interface mereka, kamus data, mendokumentasikan isi arus data dan menyimpan data (file / database), dan terstruktur English tabel keputusan, dan keputusan pohon, semua fungsi pemrosesan mendefinisikan.

KONSEP OBJEK-BERORIENTASI DESIGN

Analisis berorientasi objek dan (OOAD) desain teknik memberikan pendekatan alternatif untuk masalah sistem. Sementara teknik klasik dan terstruktur memerlukan analis / desainer untuk memahami sistem dalam hal proses yang mengubah input tetap menjadi output diprediksi, pendekatan berorientasi objek memungkinkan analis / desainer untuk mendefinisikan sistem sebagai koleksi benda yang berinteraksi dan berdasarkan ini interaksi berubah.

Metode analisis berorientasi objek dan desain yang didasarkan pada tiga konstruksi dasar: definisi dari objek, konsep kelas dan konsep warisan. Sebuah objek adalah sebuah entitas atau fungsi yang dapat didefinisikan dengan menggunakan seperangkat aturan tertentu. Dalam terminologi OOAD, itu adalah "abstraksi dari dunia nyata sehingga semua contoh itu sesuai dengan aturan yang sama." Definisi objek meliputi baik deskripsi objek dan dan berbagai negara mungkin berasumsi. "Kendaraan" adalah contoh dari objek, contoh nya mungkin "gerobak" "truk" dan "mobil". Obyek dapat mengidentifikasi hal-hal yang nyata (anjing, kuda dan rekening), peran yang dimainkan oleh seorang individu (guru, penjual, pembeli), insiden (kinerja, event), interaksi, menunjukkan hubungan antara objek (kelas, pembelian), dan spesifikasi yang memiliki kualitas standar atau definisi (model mobil, jenis kebijakan). Atribut menggambarkan karakteristik dari segala sesuatu yang telah disarikan sebagai objek. Sebagai contoh, atribut dari suatu obyek "akun" mungkin "nomor rekening, nama akun," "alamat," dan sebagainya.

Obyek dapat mengasumsikan berbagai negara. Perubahan di negara-negara yang disebabkan oleh peristiwa. Sebagai contoh, "karyawan" objek mungkin memiliki sejumlah negara. Pertama, ketika karyawan adalah "pemohon" untuk posisi, kemudian, ketika karyawan yang dipekerjakan dan menjadi "trainee", kemudian karyawan menjadi "permanen" karyawan, mungkin "manajemen" dan akhirnya "pensiunan".

Kelas lain membangun di mana pendekatan berorientasi objek didasarkan. Kelas A adalah satu set objek yang mungkin ada dalam hierarki atau jaringan. Objek dalam karakteristik kelas saham biasa dan tanggapan. Hubungan mendefinisikan hubungan antara objek dalam kelas. "Mamalia" adalah contoh dari kelas, semua "mamalia" berbagi karakteristik tertentu biologis dasar. Dalam kelas "mamalia" lainnya ada, seperti ", kucing" anjing "" dan "gajah." Mereka berbagi karakteristik dari semua "mamalia," tetapi di samping kelas masing-masing memiliki karakteristik umum tertentu yang membuat kelas.

Melekat dalam definisi kelas adalah konsep warisan. Konsep pewarisan memungkinkan anggota kelas untuk berbagi karakteristik nenek moyangnya. Jika hirarki digunakan untuk mendefinisikan hubungan objek dalam kelas, objek dapat mewarisi karakteristik dari nenek moyang tunggal. Dalam jaringan, sebuah objek dapat mewarisi karakteristik dari nenek moyang beberapa. Pentingnya warisan, bagaimanapun, adalah bahwa hal itu menyederhanakan tugas mendefinisikan data dan memperkenalkan konsistensi ke dalam definisi "terkait" objek.

ALAT DAN TEKNIK DARI OOAD

Menggunakan konsep dijelaskan di atas analis dapat mengembangkan pemahaman tentang masalah bisnis dan sistem. Salah satu alat pertama yang digunakan dalam proses OOAD adalah diagram struktur informasi. Diagram struktur informasi mendefinisikan hubungan objek dalam kelas. Sebuah contoh dari diagram struktur informasi ditampilkan dalam pameran II. (Bukti II dihilangkan) Notasi sederhana. Blok ini digunakan untuk mendefinisikan objek. Nama benda tersebut ditempatkan di blok dengan atribut. Garis yang digunakan untuk menggambarkan hubungan antara objek. Garis dijelaskan dengan nama hubungan dari sudut pandang dari kedua benda yang berpartisipasi. Panah digunakan untuk menunjukkan sifat dari hubungan dan sifat warisan. Dokumen narasi lainnya dapat menemani diagram struktur informasi. Ini dapat menggambarkan obyek didefinisikan dalam diagram struktur informasi dan hubungan mereka satu sama lain dalam bentuk narasi.

Pengembangan diagram struktur informasi adalah langkah pertama yang diambil oleh analis ketika konseptual mendefinisikan masalah pengguna. Setelah model ini (yang sama-sama "dipahami oleh pengguna dan analis) telah dibangun, analis harus menyadari bahwa itu tidak statis, tetapi benda-benda yang masuk melalui semacam siklus hidup Sebagai contoh, mempertimbangkan." Mahasiswa "objek. Awalnya , para "mahasiswa" dapat dianggap oleh perguruan tinggi atau universitas sebagai prospek Setelah "mahasiswa" telah selesai dan dikirim dalam aplikasi, ia / dia adalah pemohon.. Setelah diterima, status siswa dapat berubah untuk "masuk mahasiswa baru atau transfer "mahasiswa. Setelah mendaftar di kelas, siswa menjadi" matriculated. "Akhirnya, ketika semua persyaratan kelulusan telah selesai," mahasiswa "adalah alumnus sebuah. Informasi diagram struktur menentukan hubungan objek tanpa referensi untuk siklus hidup obyek atau perubahan keadaan yang mungkin terjadi Definisi dari berbagai negara dari suatu obyek tunggal dan peristiwa yang menimbulkan mereka yang diformalkan dalam model negara.. Sebuah representasi grafis dari model negara disajikan dalam diagram transisi negara ditampilkan dalam pameran III (pameran III dihilangkan).

Sebuah diagram transisi negara menggambarkan semua negara yang dapat diasumsikan oleh satu objek. Pada diagram setiap kotak persegi panjang mewakili keadaan objek pada suatu titik waktu tertentu. Panah yang ditampilkan dalam diagram adalah transisi yang terjadi ketika sebuah perubahan di negara terjadi. Samping panah masing-masing ditulis peristiwa yang menyebabkan perubahan di negara. Komponen akhir dari diagram adalah tindakan, tercantum di bawah setiap blok. Ini adalah efek dari perubahan di negara bagian obyek. Negara diagram transisi melengkapi definisi objek.

THE KEUNTUNGAN OBJEK-BERORIENTASI ANALISIS DAN DESAIN

Ketergantungan berorientasi obyek analisis dan desain pada definisi objek, dan hubungan mereka dan interaksi dengan satu sama lain dapat membuat pemodelan dan pembangunan sistem lebih mudah. Keuntungan dari pendekatan ini dapat diringkas sebagai: pengguna yang lebih baik / analis komunikasi dan pemodelan sehingga lebih mudah, usabilitas kode, peningkatan fleksibilitas, peningkatan produktivitas dan keandalan yang lebih baik.

Analisis berorientasi objek dan de-tanda mendefinisikan sistem sebagai koleksi benda-benda yang berinteraksi dengan satu sama lain. Identitas benda tidak berubah, meskipun peristiwa dapat menyebabkan negara mereka harus diubah. Ini metafora desain erat mencerminkan banyak dunia nyata proses. Dalam pendekatan analisis klasik dan terstruktur, proses analis didefinisikan pertama atau transformasi, tetapi sering diabaikan untuk menentukan sifat data dan berbagai negara tersebut.Dalam analisis berorientasi objek dan desain, definisi obyek yang terpenting. Definisi ini didokumentasikan dalam diagram struktur informasi. Definisi berbagai negara obyek dan proses atau kejadian yang menimbulkan mereka didokumentasikan dalam diagram transisi negara. Bersama-sama, struktur informasi diagram dan diagram transisi negara, merangkum definisi data dan proses yang mempengaruhi data atau objek.

Enkapsulasi proses dan data dalam definisi objek meningkatkan reuseability kode. Dengan berorientasi objek analisis dan desain, data dan proses yang memodifikasinya diperlakukan sebagai suatu entitas (yaitu perhitungan gross to net sebagai satu objek,. Perhitungan upah kotor sebagai obyek lain, dan distribusi tenaga kerja sebagai sepertiga) Jika sistem baru sedang dipasang dan perubahan terjadi dalam metode untuk menangkap jam bekerja, hanya obyek kedua perlu perubahan, dua lainnya bisa "kembali." Kode yang dihasilkan dari desain berorientasi obyek mengikat bersama-sama proses dan data ke dalam blok bangunan umum. Seperti Edward Yourdan (advokat awal analisis terstruktur dan metode desain dan sekarang menjadi pendukung berorientasi objek analisis dan desain) menunjukkan orang yang menggunakan metode terstruktur sebagai paradigma pembangunan mereka cenderung memperlakukan setiap proyek baru sebagai latihan intelektual yang belum pernah dipikirkan; analisis dan desain harfiah dimulai dengan selembar kertas kosong. Orang yang menggunakan berorientasi obyek metode praktek 'desain dengan ekstensi.' Artinya, mereka menganggap bahwa sistem baru yang mereka telah diminta untuk mengembangkan hanyalah perpanjangan atau penyempurnaan dari sesuatu yang telah dibangun .... "(1) Kemampuan untuk menggunakan blok bangunan standar dari rak membantu pengembangan tim menghindari replikasi dari kedua desain dan coding.

Pengikatan proses dan data dalam blok bangunan kohesif yang mewarisi karakteristik orang tua mereka dalam hirarki atau jaringan meningkatkan fleksibilitas proses pemodelan. Dengan berorientasi obyek desain dan analisis, objek baru dapat terhubung ke jaringan atau hirarki tanpa mengganggu model yang sudah ada sebelumnya. Benda dimasukkan ke dalam hierarki atau jaringan secara otomatis mewarisi semua atribut dari orang tua mereka dan pada gilirannya melalukan perbanyakan karakteristik baru yang diwarisi oleh anak-anak mereka. Model OOAD bersifat dinamis dan mengakomodasi pengetahuan baru dan perubahan dengan mudah.

Modularitas benda dan reuseability mereka meningkatkan keandalan kode. Dengan pendekatan berorientasi objek, elemen kode digunakan kembali. Karena kode berorientasi obyek yang sama dapat dikerahkan ke berbagai lokasi di berbagai sistem, kemungkinan kesalahan coding terdeteksi dan dikoreksi berkurang secara signifikan. Demikian pula, milik pusaka dalam berorientasi obyek jaringan dan hirarki menyebabkan efek perubahan riak melalui seluruh sistem. Masalah yang terkait dengan kegagalan untuk membuat perubahan terkait di semua bidang sistem utilitizing objek yang hampir dihilangkan.

Intinya adalah meningkatkan produktivitas dan mengurangi biaya. Sifat-sifat reuseability, fleksibilitas dan keandalan secara dramatis dapat meningkatkan produktivitas, baik pembangunan dan pemeliharaan analis / programmer. Dalam banyak sistem, hanya 20-30% dari model baru. Jika berorientasi obyek teknik yang digunakan, banyak komponen yang sudah ditetapkan dan tersedia dari rak (yaitu reusable). Proses perkembangan menjadi salah satu sebagian dari reorganisasi komponen umum untuk membentuk suatu model sistem baru. Jika kegiatan pembangunan yang terbatas pada desain, definisi dan pengkodean hanya model objek baru waktu dan penghematan biaya dapat terjadi. Pemeliharaan tuntutan, mengingat properti warisan juga berkurang. Perubahan yang diperlukan seluruh sistem hanya harus dilakukan sekali. Properti warisan memungkinkan efek yang akan dirasakan di seluruh sistem.

NEGARA SENI

Berorientasi objek analisis dan desain teknik telah mengalami kesuksesan dalam desain dan pengembangan beberapa aplikasi, khusus, antarmuka pengguna grafis dan komputer-aided design dan aplikasi rekayasa. Ini adalah area aplikasi yang relatif baru di mana tidak ada sejarah panjang yang sebelumnya dikembangkan, sistem yang ada dan pendekatan desain. Keberhasilan OOAD di daerah ini menunjukkan bahwa itu adalah pendekatan yang desgin manfaat pertimbangan sebagai sistem yang dikembangkan dalam metode lain mulai diganti.

Berorientasi objek analisis dan desain teknik yang didukung oleh pertumbuhan perpustakaan berorientasi obyek bahasa pemrograman. Terutama di antara bahasa-bahasa adalah C + + dan Smalltalk. Keduanya menggabungkan konsep kelas, objek dan warisan dalam desain mereka. Namun, masuknya konstruksi ini meningkatkan beban pengolahan bahwa bahasa harus berasumsi. Oleh karena itu, bahasa berorientasi objek biasanya memiliki kebutuhan hardware yang signifikan dalam bentuk persyaratan memori dan pengolahan. Overhead dan memori persyaratan dalam bahasa berorientasi objek dapat dikurangi dengan menghilangkan beberapa fitur mereka. ADA adalah bahasa berorientasi objek yang tidak mendukung definisi kelas atau warisan, dan dengan demikian mengurangi kebutuhan untuk kapasitas hardware. Beberapa upaya juga telah dilakukan untuk membuat bahasa generasi ketiga, seperti COBOL, FORTRAN dan PL / 1 lebih object-seperti. Ini dilakukan oleh grafting fungsi objek untuk bahasa. Pendekatan ini kurang efisien, tetapi memungkinkan perusahaan untuk mempertahankan bahasa di mana mereka memiliki investasi besar dalam kode yang ada dan personil terlatih.

Analisis berorientasi objek dan metodologi desain mulai membuat penampilan mereka di pasar komersial. Dua pendekatan yang diambil - satu adalah evolusi, yang lain adalah revolusioner. Pendekatan evolusi mencoba untuk mengintegrasikan berorientasi objek konstruksi dengan metode analisis terstruktur dan desain. Diagram struktur informasi dan diagram keadaan transisi digunakan selain untuk diagram aliran data untuk model lingkungan sistem. Kelompok revolusioner, di sisi lain, berpendapat bahwa metodologi tidak dapat didamaikan dan pendekatan terstruktur harus dibuang.

Sampai saat ini, pendekatan evolusioner telah memperoleh penerimaan yang lebih besar dan telah lebih produktif. Pandangan evolusi jelas dalam karya Shlaer dan Mellor dari Proyek Teknologi, dan Smith, Tockey dan Hoza Services Boeing Computer. Kedua kelompok telah terintegrasi berorientasi obyek teknik dengan teknik terstruktur untuk lebih mengonsep masalah sistem yang kompleks. Mereka menggabungkan informasi dan negara-perilaku model dengan tradisional berorientasi proses model yang digunakan dengan analisis terstruktur dan desain. Hal ini dilakukan tanpa mempertimbangkan bagaimana sistem akhirnya akan diimplementasikan - baik menggunakan bahasa generasi ketiga seperti COBOL atau salah satu bahasa berorientasi objek baru seperti C + +.

APAKAH KITA SIAP UNTUK PERUBAHAN?

Peneliti dan profesional sistem pada cutting edge teknologi ini telah melaporkan bahwa penggunaan teknologi berorientasi objek dapat meningkatkan komunikasi antara analis dan pengguna, mendukung pemodelan lebih mudah dari masalah, meningkatkan reuseability, fleksibilitas dan keandalan kode, dan menghasilkan keuntungan produktivitas keseluruhan . Sementara keuntungan produktivitas telah mengesankan, mereka hanya telah diwujudkan dalam konteks penelitian dan dalam pengembangan perangkat lunak sistem. The pengalihan ini keuntungan untuk lingkungan sistem bisnis masih harus dievaluasi.

Ekonomi drive keputusan untuk berinvestasi dalam teknologi baru. Manfaat dari perubahan harus melebihi biaya. Tradisional IS manajer pertama harus mempertimbangkan apakah manfaat yang telah dikaitkan dengan teknologi berorientasi objek dapat diwujudkan dalam lingkungan bisnis sistem.

Sebuah isu, yang harus ditangani sebelum teknologi object-oriented diadopsi, adalah kurva belajar. Sebuah langkah ke objek-berorientasi teknologi akan memerlukan investasi yang signifikan berpotensi dalam pelatihan kembali analis prosedural berorientasi dan programer. Objects, kelas dan warisan, yang merupakan dasar dari pendekatan berorientasi objek, berbeda dari teknik tradisional dan konstruksi dari baik desain klasik atau terstruktur.

Pendukung berorientasi obyek klaim teknologi yang investasi awal dalam pelatihan akan lebih dari diimbangi oleh peningkatan produktivitas. Banyak dari keuntungan diberikan ke reuseability kode. Apakah keuntungan ini akan terwujud atau tidak, tergantung pada kemampuan untuk menciptakan "reuseable" kode dan kemauan pemrogram / analis 's untuk menggunakannya. Sering, beberapa programmer yang berpengalaman akan merasa bahwa menulis ulang kode lebih cepat daripada mencari kode yang benar di perpustakaan program dan bahwa kode mereka adalah baik lebih fleksibel dan dapat diandalkan daripada yang dapat ditemukan dalam program perpustakaan. Sikap budaya terhadap menggunakan kembali pra-paket kode harus berubah seiring dengan perkembangan keterampilan OOAD sebelum manfaat penuh dari teknologi berorientasi objek dapat benar-benar direalisasikan.

Besar kemungkinan bahwa adopsi berorientasi obyek teknik akan terjadi secara bertahap, menggunakan dua pendekatan. Satu akan selektif untuk mengintegrasikan berorientasi objek konstruksi ke dalam pendekatan terstruktur lebih akrab. Struktur Informasi diagram dan diagram transisi negara yang mirip dengan diagram entitas data yang sudah digunakan oleh banyak desainer dan analis untuk database model. Adopsi alat, seperti ini, tidak memerlukan investasi yang signifikan dalam pelatihan kembali staf, dan dapat meningkatkan analis / pengguna komunikasi dan proses pemodelan, menghasilkan beberapa manfaat. Pendekatan lain adalah dengan menggunakan berorientasi obyek teknik sebagai sistem baru dikembangkan, sebagai modul yang ditambahkan ke sistem yang ada dan sebagai modul yang ada diperbarui atau diubah. Pendekatan konversi bertahap dapat meringankan transfer ke teknologi baru, sementara memungkinkan organisasi untuk menilai kelebihan dan kekurangan dari pendekatan baru.

OBYEK-BERORIENTASI TEKNIK BEKERJA DI Aerospace BRITISH

Informasi British Aerospace sistem masalah desain adalah refleksi dari perusahaan: besar, bervariasi dan kompleks. Colin Birtwistle, seorang insinyur pengembangan untuk pemasok di seluruh dunia pesawat komersial dan militer dan komponen, memiliki tugas mengembangkan sistem, termasuk database untuk mendukung desain dan pembuatan listrik pesawat. Saat ini ia mengelola database proyek pengembangan integrasi untuk kelompok di British Aerospace untuk desain dan produksi memanfaatkan kabel listrik untuk pesawat militer, termasuk pesawat multi-Peran Tornado. Ini proyek integrasi data sedang diimplementasikan dengan menggunakan teknik desain berorientasi objek dan teknologi object-oriented, khususnya DB ONTOS dari ONTOS, Inc Burlington, Mass

Birwistle menggambarkan situasi di, "jalan:" Kami menemukan satu bagian dari harness kawat pesawat, konektor, disimpan di lebih dari 10 sistem yang berbeda. Jika kita ingin mengganti konektor ini, atau menggantinya dengan bagian yang berbeda, kami harus memperbarui data dalam semua sistem tersebut. Atau, jika lead time untuk konektor dari produsen berubah dari enam sampai sembilan bulan, itu akan mengambil banyak waktu untuk memastikan bahwa perubahan tercermin di mana-mana "penggunaan British Aerospace berorientasi obyek teknik dan teknologi. Telah dikurangi ini dan banyak masalah terkait.

Menggunakan berorientasi obyek sistem database ONTOS ', British Aerospace telah menciptakan satu database dan sekitar database yang menambahkan alat dan fungsi. Ini database umum menyimpan setiap informasi sebagai objek, dari jenis kawat untuk tagihan bahan. Dengan model ini semua sistem - desain, rekayasa, manufaktur dan manajemen - dapat menggunakan dan mengakses data. Birtwistle menyatakan:. "Dengan sistem ini, kami berusaha untuk memberikan orang-orang kami yang akurat, informasi umum untuk bertindak atas Karena informasi yang dimasukkan ke dalam database hanya sekali, perubahan selanjutnya dibuat hanya sekali ini berarti mereka sekarang memiliki akses ke informasi dan. alat terbaik untuk bereaksi terhadap informasi ini. "

Menggunakan pendekatan berorientasi objek, British Aerospace telah menunjukkan peningkatan produktivitas di sejumlah daerah. Prototipe awal untuk sistem ini mengambil hanya sekitar 3 bulan untuk menyelesaikan. Birtwistle memperkirakan bahwa itu akan diambil beberapa bulan lebih dengan jenis lain dari teknologi. Juga, pemodelan database prototipe jauh lebih mudah. Karena objek database menyimpan informasi lebih efisien dengan duplikasi tidak, ukuran penyimpanan data yang berkurang hingga 90 persen, membuat penghematan yang signifikan dalam pengelolaan data dan pemeliharaan. Selain itu, tim proyek menemukan bahwa baris kode perangkat lunak dapat dikurangi sebesar 60 sampai 65 persen karena kemampuan warisan. Warisan memberikan benda kemampuan untuk memperoleh atribut dan perilaku dari benda-benda lain, yang memungkinkan pengembang aplikasi untuk model atribut umum dan perilaku hanya sekali. Ini adalah keuntungan besar dalam perangkat lunak dan pemeliharaan aplikasi. Sebagai salah satu software engineer ditugaskan untuk tim proyek mengatakan "aku pasti penggemar orientasi objek saya digunakan untuk menggeliat ketika saya mendengar tentang pemodelan dunia nyata sebagai objek Memang benar -.. Anda sekarang dapat berpikir tentang masalah dalam hal dari masalah itu sendiri, bukan database atau bahasa pemrograman. Dan, pada akhirnya, itu berarti Anda dapat berkomunikasi dengan orang lain lebih mudah dan mendapatkan pekerjaan yang dilakukan lebih cepat. "

REFERENSI

1.       Yourdon, Edward. "Auld Lang Syne." Byte, Oktober 1990, 257-263.

2.       Linda R.ph.D. busines administration jan 1993

Booch G. (1991), Object-Oriented Design With Applications, Benjamin/Cummings