Waduh! Merekayasa perangkat lunak ternyata jauh lebih sulit dari yang pernah saya bayangkan sebelumnya! Apakah nasib menempatkan sebagian besar ‘tukang_komputer’ mentok sebagai programmer doank? Gak nahan lah…
Mungkin ini bukan jawaban yang benar-benar bisa dijadikan senjata utama, tapi, dari banyak masukan (terutama dosen lah…!!!), Object-oriented Analysis and Design (OOAD) serasa memberikan angin segar. Sedikit refreshing tentang OOAD, sebuah pendekatan merekayasa perangkat lunak (software engineering)yang memodelkan sebuah sistem sebagai sebuah kelompok obecjt-object yang saling berinteraksi (that’s why we call it object oriented lah…!!!). Setiap object merepresentasikan beberapa entity dari ketertarikan pada sistem yang sedang dimodelkan, dan dikarakterisasi oleh class-nya, dan state-nya (data elements) dan behaviour-nya. Kalau menurut forum organisasi OOAD sih, In simple terms, OOAD is the art of designing and building programs for an extended lifetime. Wooo…
Well, however, banyak sekali notasi-notasi untuk model ini, seperti yang akan kita bahas disini: UML.
Sebenarnya, merancang bangun perangkat lunak (untuk selanjutnya saya pakai saja kata ‘software’ daripada ‘perangkat lunak’) tidak begitu jauh dengan pekerjaan arsitektur: perpaduan teknik dan seni. Bedanya, perkembangan teknologi software berakselerasi jauh lebih cepat daripada ilmu membangun jembatan. Seriously, tanpa meremehkan para arsitek, software engineering relatif lebih kompleks. However, cara kerja arsitek yang merancang desainnya di sebuah papan besar atau computer aided design (CAD) mungkin bisa dianologikan dalam merancang bangun sistem. Disinilah kita merunut kepada UML.
UML diterjemahkan sebagai bahasa spesifikasi standar untuk mendokumentasikan, menspesifikasikan, dan membangun sistem perangkat lunak. UML tidak berdasarkan pada bahasa pemrograman tertentu. Standar spesifikasi UML dijadikan standar defacto oleh OMG (Object Management Group) pada tahun 1997.UML yang berorientasikan object mempunyai beberapa notasi standar.
