Merancang Sistem Dengan UML: Mulai Dari Mana?
19 Februari 2013 58 Komentar
Salah satu pertanyaan yang paling sering saya temukan dari para mahasiswa adalah apa saja step-step yang harus ditempuh dalam merancang sistem berbasis UML? Saya biasanya akan memperbaiki pertanyaan ini karena UML pada dasarnya hanya kumpulan diagram atau teknik visualisasi; UML tidak mendikte langkah-langkah pengembangan sistem! Lalu apa yang harus dilakukan dalam merancang sebuah sistem?
Saya yakin para mahasiswa telah memperoleh mata kuliah pengembangan sistem informasi sebelumnya, tapi kenapa mereka bertanya demikian disaat mereka harus merancang sistem yang nyata (misalnya untuk skripsi)? Salah satu penyebabnya adalah analisa & perancangan terlalu teoritis sehingga tidak mendukung implementasi/pembuatan kode program.
Dari beberapa buku analisa & perancangan yang saya baca, buku Use Case Driven Object Modeling with UML: Theory and Practice adalah salah satu buku yang spesial dan sangat membantu. Bukan hanya dilengkapi dengan humor, tetapi buku ini memberikan metode analisa & perancangan yang sangant berguna saat diterapkan dalam pembuatan kode program! Buku yang memakai metode ICONIX Process ini ditulis oleh analyst yang memiliki latar belakang programmer.
Saya tahu bahwa sangat sulit merangkum sebuah buku 438 halaman dalam sebuah artikel blog, tapi saya ingin menunjukkan bahwa diagram UML hasil analisa & perancangan bukanlah sekedar basa basi yang dihasilkan analyst. Dengan metode yang salah, analyst kerap terlihat tidak berguna di mata developer. Metode yang salah juga menyebabkan mahasiswa lebih senang membuat kode program terlebih dahulu, baru melakukan reverse engineering untuk menghasilkan diagram UML. Dengan kata lain, sistem dibuat tanpa analisas & perancangan, sementara diagram UML hanya produk sampingan yang menambah ketebalan skripsi tanpa fungsi yang sangat berarti.
Gambar berikut ini memperlihat proses analisa & perancangan sistem informasi dengan ICONIX process:
Proses analisa & perancangan sistem yang saya rangkum dari buku Use Case Driven Object Modeling With UML: Theory and Practice adalah sebagai berikut ini:
1. Membuat Functional Requirement
Gunakan Microsoft Word untuk menuliskan functional requirement (apa yang dapat dilakukan oleh sistem?). Tahap ini melibatkan business analyst, pelanggan, end user, dan project stakeholders lainnya. Functional requirement bersifat tidak terstruktur dan tidak dapat dipakai dalam perancangan secara langsung.
Berikut ini adalah contoh potongan dari function requirement untuk sebuah sistem bengkel motor yang sederhana:
Sistem harus dapat memproses work order untuk motor mulai dari antri, sedang dikerjakan oleh seorang mekanik, selesai di-servis, dan proses pembayaran. Sebuah work order memiliki informasi jenis pekerjaan dan sparepart yang dijual. Harga ongkos servis berdasarkan jenis pekerjaan dan tipe motor.
2. Membuat Domain Model (sederhana)
Salah satu fungsi domain model adalah menyamakan istilah yang akan pakai diproses selanjutnya. Misalnya, apakah saya akan memakai istilah ‘work order’ atau ‘pekerjaan servis’? Apa saya akan memakai sebutan ‘sparepart‘ atau ‘suku cadang‘? Walau terlihat sepele, perbedaan istilah seringkali menimbulkan salah paham dalam komunikasi tim.
Pada tahap ini, domain model adalah class diagram yang hanya memakai relasi pewarisan (is-a/adalah sebuah) dan agregasi (has-a/memiliki sebuah). Class diagram ini belum memiliki atribut dan operasi. Nantinya, di proses selanjutnya, domain model akan diperbaiki dan dikembangkan menjadi lebih detail.
Gambar berikut ini memperlihatkan contoh domain model untuk functional requirement di langkah 1:
3. Membuat Use Case
Use case mendefinisikan behavioral requirements berdasarkan functional requirement (dan sumber lainnya). Berbeda dengan anjuran dari buku analisis sisfo lain, buku ini menyarankan untuk membuat use case dengan maksimal 2 paragraf! Tidak perlu mengikuti template yang detail! Sebuah use case yang panjang & detail malah akan memperlambat kita. Tim yang membuat use case bisa jadi akhirnya hanya mengisi form yang kosong tanpa banyak berpikir panjang (misalnya sekedar copy paste) sehingga proses membuat use case hanya sekedar ritual tanpa analisa mendalam.
Kalimat yang dipakai dalam use case harus berupa kalimat aktif, misalnya “pengguna men-klik tombol Login”. Kalimat pasif seperti “Sistem menyediakan tombol Login” adalah ciri-ciri functional requirement dan bukan bagian dari use case.
Use case harus mengandung nama di domain model. Dengan demikian, saya bisa menghubungkan class-class yang akan dirancang dengan use case. Setiap halaman/layar yang direferensikan di dalam use case sebaiknya diberi nama yang konsisten, misalnya Halaman Tambah Sparepart atau Screen TambahSparepart.
Sebuah use case hampir mirip seperti dokumentasi sistem. Kita perlu menspesifikasikan seperti apa cara pakai sistem (termasuk respon sistem) sebelum sebuah sistem dibuat. Berikut ini adalah contoh use case diagram berdasarkan functional requirement di langkah 1 dan memakai domain model dari langkah 2:
Sebuah use case selain memiliki sunny-day scenario, sebaiknya juga memiliki rainy-day scenario (apa yang akan terjadi bila sesuatu salah?) atau alternatif. Sebagai contoh, berikut ini contoh use case scenario untuk use case diagram di atas:
Membuat WorkOrder baru Basic Scenario Front Desk memilih Motor di Screen ListMotor dan men-klik tombol untuk membuat WorkOrder. Sistem akan membuat sebuah WorkOrder baru dengan status sedang antri. Alternate Scenario Motor belum terdaftar - Front Desk terlebih dahulu menambah Motor baru dengan men-klik tombol untuk menambah Motor baru sebelum mengerjakan langkah yang ada di Basic Scenario. Motor sudah memiliki WorkOrder yang sedang antri - Sistem akan menampilkan pesan kesalahan. [Catatan: pada saat membuat use case ini, terlihat bahwa dibutuhkan use case menambah Motor. Agar ringkas, use case tersebut akan diabaikan.] Mengubah Status WorkOrder menjadi sedang dikerjakan oleh Mekanik Basic Scenario Front Desk memilih sebuah WorkOrder di Screen ListWorkOrder dan memilih menu untuk menandakan bahwa Workorder tersebut sedang dikerjakan. Sistem akan menampilkan Screen PengerjaanWorkOrder. Front Desk memilih nama Mekanik yang mengerjakan WorkOrder dan men-klik tombol untuk menyimpan perubahan. Sistem akan mengubah status WorkOrder menjadi sedang dikerjakan serta mencatat tanggal & jam mulai dikerjakan. Alternate Scenario Status WorkOrder yang dipilih bukan sedang antri - Sistem akan menampilkan pesan kesalahan. Menambah Sparepart yang dipakai selama pengerjaan WorkOrder Basic Scenario Front Desk memilih sebuah WorkOrder di Screen ListWorkOrder dan memilih menu untuk menambah Sparepart di WorkOrder. Sistem akan menampilkan Screen TambahSparepart yang berisi daftar Sparepart untuk WorkOrder yang dipilih. Disini Front Desk akan mengisi data ItemSparepart dengan memilih Sparepart, memasukkan jumlah Sparepart, lalu men-klik tombol Tambah ItemSparepart. Sistem akan memperbaharui daftar ItemSparepart di layar. Front Desk men-klik tombol Simpan untuk selesai. Sistem akan menyimpan perubahan Sparepart pada WorkOrder terpilih. Alternate Scenario Terdapat lebih dari satu jenis Sparepart yang perlu ditambahkan - Front Desk kembali menambah data ItemSparepart. Setelah semua ItemSparepart selesai dimasukkan, Front Desk men-klik tombol Simpan di Screen TambahSparepart. Sistem akan menyimpan perubahan. Status WorkOrder yang dipilih bukan sedang dikerjakan - Sistem akan menampilkan pesan kesalahan. [Catatan: pada saat membuat use case ini, terlihat bahwa ada yang kurang pada domain model, yaitu ItemSparepart. Segera update domain model! Terlihat juga bahwa dibutuhkan sebuah metode untuk menghapus Sparepart dan meng-edit jumlah Sparepart terpakai. Agar ringkas, use case tersebut akan diabaikan.] Mengubah status WorkOrder menjadi selesai dikerjakan Basic Scenario Front Desk memilih sebuah WorkOrder di Screen ListWorkOrder, lalu memilih menu untuk mengubah status WorkOrder menjadi selesai dikerjakan. Sistem akan menampilkan dialog konfirmasi. Bila kasir menkonfirmasi, Sistem akan mengubah status WorkOrder tersebut menjadi selesai dikerjakan dan mencatat jam selesai dikerjakan. Front Desk kemudian mengerjakan use case "Mencetak rincian WorkOrder termasuk biaya". Alternate Scenario Status WorkOrder bukan sedang dikerjakan - Sistem akan menampilkan pesan kesalahan. Mencetak rincian WorkOrder termasuk biaya Basic Scenario Front Desk memilih tombol untuk mencetak. Sistem kemudian mencetak detail WorkOrder ke printer. Detail WorkOrder yang dicetak meliputi tanggal, plat nomor motor, jam mulai dikerjakan, jam selesai dikerjakan, nama mekanik yang mengerjakan, rincian seluruh Sparepart yang dipakai (jumlah & harga eceran tertinggi Sparepart), ongkos servis dan total yang harus dibayar. Alternate Scenario Status WorkOrder bukan selesai dikerjakan - Sistem akan menampilkan pesan kesalahan. [Catatan: use case ini dipisahkan dari use case "Mengubah status WorkOrder menjadi selesai dikerjakan" karena dianggap nanti akan ada use case lain yang dapat mencetak rincian WorkOrder tetapi tidak ditampilkan disini.]
4. Requirements Review
Pada saat melakukan analisa dalam membuat use case, saya menemukan hal yang masih kurang. Misalnya, saya perlu menambahkan class ItemSparepart
pada domain model. Selain itu, pada beberapa situasi, saya bahkan bisa menemukan ada use case yang masih kurang, misalnya use case “Tambah Motor baru“.
Pada langkah ini, saya kembali memastikan bahwa use case & domain model telah dibuat dengan baik. Pelanggan juga perlu dilibatkan untuk memastikan bahwa use case (behavioral requirement) & functional requirement sesuai dengan yang diharapkan. Ingatlah selalu bahwa bagian terpenting dari sebuah sistem bukanlah seberapa keren design pattern yang diterapkan di class diagram, tetapi sejauh mana sistem tersebut memberikan profit bagi penggunanya (memenuhi requirements).
5. Melakukan Robustness Analysis
Analisis adalah memikirkan “apa” (what), sementara perancangan adalah memikirkan “bagaimana” (how). Salah satu alasan mahasiswa sering mengabaikan UML dan langsung terjun ke coding adalah celah yang cukup jauh antara analisis dan perancangan sehingga mereka memilih merancang secara eksperimental dengan langsung coding. Umumnya mereka berakhir dalam jebakan siklus perubahan “coding” terus menerus (guna memperbaiki rancangan). Padahal, perubahan “coding” adalah sesuatu yang sangat memakan waktu dan upaya bila dibandingkan dengan mengubah diagram UML.
Robustness analysis dipakai untuk menjembatani analisis dan perancangan. Robustness analysis harus diterapkan pada setiap use case yang ada. Pada Enterprise Architect, robustness analysis dapat digambarkan dengan menggunakan Analysis Diagrams (terdapat di kategori Extended).
Berikut ini adalah contoh hasil robustness analysis untuk use case yang ada:
Semakin detail robustness analysis, maka semakin banyak hal yang kurang dari use case dan domain model yang akan ditemukan. Yup! Pada awalnya saya ragu kenapa saya harus menambah control “mengisi jumlah”, “mengisi nama”, dsb untuk setiap field yang ada. Tapi saya cukup terkejut saat menemukan dari hal sepele tersebut, saya menemukan beberapa alternate scenario yang kurang.
Sebagai contoh, saya menemukan bahwa saya lupa menambahkan alternate scenario “jumlah Sparepart tidak mencukupi” saat melakukan analisa robustness pada use case “Menambah Sparepart yang dipakai selama pengerjaan WorkOrder”. Semakin cepat saya menyadari ada yang kurang, semakin baik! Idealnya adalah sebelum coding dilakukan. Robustness analysis adalah salah satu senjata yang ampuh untuk itu.
Saya juga menemukan bahwa pada use case “Mengubah Status WorkOrder menjadi sedang dikerjakan oleh Mekanik”, saya lupa menuliskan bahwa Front Desk officer juga perlu memilih JenisPekerjaan
. Saya perlu segera mengubah teks use case tersebut.
Selain itu, terkadang saya juga dapat menemukan ada class yang kurang pada domain model. Misalnya, dari hasil robutsness analysis, terlihat bahwa saya perlu menambahkan class Mekanik
di domain model.
Pada tahap ini, saya juga perlu mengisi domain model dengan atribut, seperti yang terlihat pada gambar berikut ini:
6. Preliminary Design Review
Kembali lagi seluruh tim melakukan review dan memastikan bahwa semua yang telah dibuat sesuai dengan requirement. Ini adalah langkah terakhir dimana pelanggan (stackholder) terlibat! Hal ini karena langkah berikutnya melibatkan proses techincal. Akan berbahaya bila membiarkan pelanggan yang non-technical atau semi-technical mengambil keputusan untuk hal-hal yang bersifat teknis (misalnya framework atau database yang dipakai). Walaupun demikian, pelanggan boleh memberikan komentar mengenai tampilan.
Setelah langkah ini, tidak ada lagi perubahan requirement. Lalu bagaimana bila pelanggan ingin menambah requirement? Buat sebuah rilis atau milestone baru dengan kembali lagi ke langkah pertama di atas.
7. Menentukan Technical Architecture
Tentukan framework apa yang akan dipakai. Sebagai contoh, saya akan membuat sebuah aplikasi desktop dengan Griffon. Pola arsitektur yang dipakai menyerupai Model View ViewModel (MVVM) dimana terdapat perbedaan antara domain model dan view model. Saya juga mengasumsikan penggunaan sebuah plugin fiktif yang dirujuk sebagai simple-jpa. Gambar berikut ini memperlihatkan contoh arsitektur yang dipakai:
8. Membuat Sequence Diagram
Object oriented pada dasarnya adalah menggabungkan antara data dan operasi ke dalam sebuah entitas. Saat ini, domain model baru berisi data. Oleh sebab itu, dibutuhkan sebuah upaya untuk menemukan operasi untuk domain model. Caranya adalah dengan memakai sequence diagram.
Saat membuat sequence diagram, sertakan juga elemen dalam arsitektur teknis/framework. Misalnya penggunaan MVC akan menyebabkan ada class baru seperti controller. Yup! Penggunaan MVC akan membuat operasi tersebar ke controller. Hal ini sering dikritik karena bukan pendekatan OOP melainkan kembali ke zaman prosedural. Baca buku Object Design: Roles, Responsibilities, and Collaborations untuk pendekatan yang OOP, akan tetapi jangan lupa kalau kita dibatasi oleh framework yang dipakai (ehem, seharusnya bukan framework yang membatasi kita, melainkan kita yang tegas dalam memilih framework).
Selama membuat sequence diagram, ingatlah selalu bahwa tujuannya adalah menemukan operasi (behavior) untuk setiap class yang ada, bukan menunjukkan step-by-step operasi secara detail! Untuk menjaga agar tidak tersesat menjadi membuat flow-chart yang detail, jangan memikirkan focus of control (matikan saja fitur tersebut!).
Sequence diagram dibuat untuk setiap use case yang ada, berdasarkan hasil robustness anaylsis. Gambar berikut ini memperlihat contoh sequence diagram yang dihasilkan (agar sederhana, operasi penyimpanan data oleh simple-jpa tidak ditampilkan):
Proses analisa yang berulang kali lagi-lagi membantu saya menemukan kekurangan. Saya selama ini ternyata lupa bahwa pada use case “Menambah Sparepart yang dipakai selaman pengerjaan WorkOrder”, sistem harus mengurangi jumlah stok Sparepart
bila pengguna men-klik tombol simpan. Oleh sebab itu, saya segera memperbaharui teks use case.
Selain itu, saya juga menemukan sebuah kesalahan yang saya buat dari awal dan tidak terdeteksi hingga sekarang, yang berhubungan dengan class OngkosServis
. Gambar berikut ini memperlihatkan perancangan awal class tersebut:
Bila membuat ERD atau design tabel, ini adalah sesuatu yang dapat diterima (ongkos disimpan dalam tabel yang mewakili hubungan one-to-many dari JenisPekerjaan
ke TipeMotor
). Tetapi, bila diterapkan ke dalam domain model, maka akan terjadi kejanggalan saat saya memakai domain model tersebut di sequence diagram. Untuk memperoleh ongkos servis, apa saya harus membuat instance objek OngkosServis
baru? Bila diterapkan ke coding, maka ini berarti untuk memperoleh ongkos servis, saya harus selalu melakukan query JPQL yang kira-kira terlihat seperti berikut ini:
TipeMotor tipeMotor = model.selectedTipeMotor JenisPekerjaan jenisPekerjaan = model.selectedJenisPekerjaan Query query = em.createQuery("SELECT o.harga FROM OngkosServis o WHERE " + "o.tipeMotor = :tipeMotor AND o.jenisPekerjaan = :jenisPekerjaan") query.setParameter("tipeMotor", tipeMotor) query.setParameter("jenisPekerjaan", jenisPekerjaan) Long ongkos = query.getSingleResult()
Terlihat ada yang tidak beres! Bukankah OOP harus intuitive & bisa dipakai dengan mudah? Kenapa tiba2 harus melakukan query secara eksplisit untuk memperoleh sebuah ongkos servis? Selain itu, class OngkosServis
tidak pernah dipakai secara langsung di kode program, hanya dipakai di query saja!
Oleh sebab itu, saya memperbaikinya dengan membuang class OngkosServis
, dan menambahkan atribut ongkosServis
di class JenisPekerjaan
dengan tipe data berupa Map<TipeMotor,Long>
. Dengan demikian, saya bisa memakainya seperti berikut ini:
TipeMotor tipeMotor = model.selectedTipeMotor JenisPekerjaan jenisPekerjaan = model.selectedJenisPekerjaan Long ongkos = jenisPekerjaan.getOngkosServis(tipeMotor)
Cara di-atas jauh lebih intuitive dan mudah dipahami. Query database tetap terjadi, tetapi kali ini secara implisit (secara otomatis) oleh Hibernate tanpa campur tangan developer.
Ini adalah alasan kenapa saya selalu memberikan pesan pada mahasiswa agar tidak memikirkan proses penyimpanan data saat membuat domain model. Jangan menyamakan domain model dan ERD. Pada saat merancang domain model, pikirkan bagaimana class-class yang ada akan saling berinteraksi dan dipakai oleh developer. Bahkan bila tidak memakai ORM seperti Hibernate, tetap jangan memikirkan bagaimana penyimpanan data di domain model, melainkan buat ERD terpisah untuk dipakai oleh persistence layer (DAO).
9. Critical Design Review
Kembali melakukan review untuk memastikan bahwa tidak ada yang kurang pada sequence diagram. Pastikan bahwa setiap class yang ada telah memiliki atribut dan operasi yang didefinisikan secara lengkap (memiliki nama, tipe data, parameter, dsb).
Berikut ini adalah contoh hasil domain model yang telah dilengkapi dengan operasi dan multiplicity:
Getter dan setter tidak perlu ditampilkan karena hanya akan membuat class diagram terlihat ‘penuh’.
Versi bidirectional-nya akan terlihat seperti pada gambar berikut ini:
Selain domain model, saya juga menemukan terdapat class-class lain yang dihasilkan yang berkaitan dengan penggunaan framework, yang terlihat seperti pada gambar berikut ini:
10. Coding
Disini developer berperan mengubah rancangan (design) menjadi kode program. Karena semua telah direncanakan dan dipikirkan sebelumnya, maka proses coding dapat dianggap sebagai sebuah pembuktian (test) bahwa rancangan yang dibuat sudah benar. Terkadang terdapat beberapa hal yang lolos dari perancangan dan baru terungkap saat coding; pada kasus tersebut, perubahan pada rancangan harus segera dilakukan sehingga kode program dan rancangan bisa tetap sinkron.
Bila pembuatan kode program tiba-tiba menjadi tidak terkendali (pada kasus skripsi, mahasiswa tiba-tiba merasa seolah otaknya hendak meledak dan jadi malas coding), maka ada beberapa kemungkinan:
- Hasil rancangan tidak bagus.
- Programmer tidak mengikuti hasil rancangan yang bagus dan mengerjakannya sesuka hatinya.
- Programmer tidak diikutsertakan dalam proses perancangan
- Mahasiswa tidak mau pikir panjang/hanya copy paste di bab analisa & perancangan, dalam pikirannya mau segera fokus ke bab implementasi dan kode program;
- Mahasiswa hanya memikirkan bab analisa & perancangan, tidak mau peduli dampaknya pada saat membuat kode program nanti.
Ping-balik: Membuat Aplikasi CRUD MySQL Dalam 10 Menit Dengan Griffon | The Solid Snake
Saya masih kurang begitu mengerti mengenai UML ini, gimana ya caranya biar gampang mengertinya ya mas?
Caranya adalah dengan mempraktekkannya. Dengan membuat implementasi dari rancangan, kita menjadi semakin mengerti ‘kenapa begini‘ dan ‘kenapa begitu‘. Membaca buku yang disebutkan di artikel ini juga akan membantu.
keren mas penjelasannya.. lebih mengena daripada teori yang d buku thx..
mas, cara buat robustness analysis nya gimana? saya buat use case nya pake starUML.
Coba pakai Enterprise Architect, buat sebuah analysis diagram baru: http://www.sparxsystems.com/enterprise_architect_user_guide/10/domain_based_models/analysisdiagram.html
Enterprise Architect adalah salah satu tools yang mendukung ICONIX process: http://www.sparxsystems.com/enterprise_architect_user_guide/10/software_engineering/iconix_process.html
mantap sekali gan 😀
ane mahasiswa juga bingung kalo cuman dapet teori formal, ga dijelasin langkahnya, tujuannya, harus mulai darimana …
sangat membantu sekali,,, perbedaan antara UML booch sama use case driven itu apa gan???
Graddy Booch adalah salah satu pencipta UML. UML adalah notasi grafis multi-fungsi untuk keperluan pengembangan software. UML hanya menyediakan visualisasi. Use case driven development adalah salah satu panduan dalam pengembangan software.
Analogi: Bila UML adalah Adobe Photoshop, maka use case driven development adalah panduan mencari inspirasi gambar. Seorang designer dapat memakai Adobe Photoshop dalam berbagai cara karena memang Adobe Photoshop tidak mengatur step-by-step dalam menggambar.
kesimpulannya jadi use case driven tidak terlalu banyak membahas pada analisa, design maupun implementasi programnya tapi lebih melihat kepada kebutuhan pengguna serta menyederhanakan proses tersebut,
terima kasih gan atas jawabannya 😀
maaf mas, kalau misalnya kita eksekusi ke coding, gimana ya cara implemtasinya. soalnya saya juga ada kerjaan seperti ini, cuman setelah ke coding jadi bingung lagi 😦
Untuk implementasi ke kode program, serahkan pada programmer. Tunjukkan hasil rancangan dan beri tahu apa yang harus mereka buat! Mereka akan senang karena mereka sudah tahu apa yang harus mereka lakukan.
Sekedar fakta dan tips agar sukses…
Domain expert adalah orang paling alih di bidang yang hendak dikomputerisasikan. Analyst dan developer tidak akan pernah bisa menyaingi pengalaman domain expert.
Domain expert bisa jadi adalah client, atau bisa juga pihak ketiga yang berpengalaman di bidang tersebut.
Domain expert tidak bisa membuat sistem informasi dan melakukan pemograman karena bukan bidangnya.
Analyst bertugas menerjemahkan kebutuhan domain expert dan melihatnya dari sisi sistem informasi.
Analyst bukan menggambarkan diagram yang mewakili proses bisnis semata wayang karena domain expert bisa melakukan ini sendiri tanpa adanya analyst!
Diagram yang dihasilkan analyst adalah kebutuhan domain expert yang sudah disesuaikan dengan kelebihan dan kekurangan teknologi yang dipakai seperti framework, web, desktop.
Pada saat merancang sistem berbasis web, analyst memperhatikan skalabilitas, dampak penggunaan session dan cookie, dan bagaimana mudahnya implementasi nanti.
Pada saat memakai ORM seperti Hibernate atau Doctrine + Symfony, analyst memperhatikan keterbatasan class yang ada karena tidak semua jenis class dapat diimplementasikan. Misalnya, analyst menghindari relasi many-to-many dan one-to-many unidirectional di class diagram. Bukan karena tidak boleh, tapi karena frameworknya terbatas!
Programmer hanya perlu coding karena analyst sudah memperhatikan kebutuhan programmer pada saat merancang.
Analyst memperhatikan kebutuhan domain expert dan kebutuhan programmer dalam menghasilkan rancangan.
Terimakasih gan artikelnya sangat membantu, tp saya ada sedikit pertanyaan untuk domain model yang telah lengkap versi Bidirectional kenapa <> JenisPekerjaan jadi hilang ?
Itu adalah sebuah kesalahan di diagram tersebut. Harusnya class tersebut tetap ada dan tidak hilang dengan posisi sama seperti sebelumnya.
Terima kasih gan, sangat membantu..
penjelasannya bagus banget gan. thanks gan
Terima kasih penjelasannya sangat membantu, Saya biasanya pakai power designer, tapi untuk robustness diagramnya susah, skrang sya mulai berusaha pakai EA, tapi tutorialnya kurang, apalagi untuk iconix, mas bisa minta referensi untuk tutorialnya?
bang, ane lagi belajar bikin class diagram, tolong dikoreksi dan komentarin bisa g bang? ane kirimin ke emailnya kalo bisa, mohon bales ye bang, email ane : somesoul.m@gmail.com
Diagram yang dihasilkan berdasarkan sebuah sudut pandang atas domain yang disepakati bersama oleh tim. Saya belum tentu memahami domain permasalahan (inventory, banking, healthcare, dsb) yang kamu hadapi. Selain itu, walaupun domainnya sama, setiap arsitek bisa punya point of view-nya masing-masing. Beberapa demi alasan waktu dan infrastruktur yang tidak memadai, merancang class tanpa banyak operasi seperti layaknya tabel yang hanya berisi data. Ada juga yang menghasilkan rich domain classes yang sudah mencakup operasi dan interaksi.
Untuk mengoreksi diagram-mu, lakukan intropeksi berikut ini:
1. Apakah seluruh anggota tim dapat memahami diagram tersebut, termasuk domain expert?
2. Apakah kamu dapat mengimplementasikan diagram tersebut dalam jangka waktu yang wajar dengan teknologi atau skill yang dimiliki?
Mas info dong Software yang Open Source atau Trial yg recommended untuk Point yang Use case Dan Robustness Activity
Saya memakai Enterprise Architect. Software ini tidak gratis tetapi versi trial-nya dapat di-download secara bebas.
terimakasih mas
mas, maaf nih masih newbie, kalo metode ICONIX Process itu bagaimana ya? apakah termasuk metode pengembangan sistem..? sy lg buat rancangan dengan rational rose, apa sesuai dengan metode itu, atau tidak ada hubunganya (artinya, bisa saja digambarkan dengan tool apapun)
ICONIX adalah salah satu metodologi pengembangan software yang tidak agile (sama halnya seperti Scrum, Agile, Extreme Programming, Cowboy Coding, dsb).
Tidak ada hubungannya dengan jenis dan tipe diagram yang dihasilkan. Metode pengembangan software yang beragam biasanya dapat memakai diagram yang umum dipakai seperti UML Diagram.
ICONIX hanya mengatur seperti kapan kamu membuat diagram dan sejenisnya (seperti yang ditunjukkan oleh step by step pada artikel ini). Pada metode lain, misalnya RAD yang populer dipakai oleh programmer VB dan Delphi, tidak ada perencanaan intensif sehingga pengembangan langsung pada membuat UI selaku prototype yang dikembangkan bertahap.
Metode pengembangan juga menentukan apa yang kamu anggap penting dalam proyek. Bila memakai ICONIX, proses dan interaksi yang mewakili bisnis adalah hal yang paling utama. Ini tidak selalu benar pada metode lainnya. Sebagai contoh, pada RAD, hasil rancangan GUI adalah hal utama yang diperhatikan. GUI, pada RAD, biasanya adalah indikator utama dalam melihat perkembangan proyek.
Mahasiswa pemula biasanya cenderung memakai metode “code and fix” dimana mereka langsung membuat kode program tanpa rancangan terlebih dahulu. Mereka akan memperbaikinya pada saat-saat tertentu. Ini umumnya menghasilkan “code monkey” yang meniru dan melakukan hal repetitif seolah-olah pemograman adalah hal sederhana tanpa memahami kompleksitas yang ada.
gan bisa buat postingan tentang perbedaan extend sama include gak? lebih sederhana dan terperinci. mksh gan
Gw anggap yang dimaksud dengan
include
adalah composition. Pada composition, superclass dimasukkan ke dalam subclass sebagai sebuah variabel sehingga method yang ada di superclass dapat di-reuse atau dipanggil ulang.Inheritance (melalui
extends
) bukan saja menawarkan reuse seperti pada composition tapi juga subtyping. Sebagai contoh, methodproses(Manusia m)
mengharapkan parameter berupaManusia
. Bila terdapatMahasiswa
danDosen
yang diturunkan dariManusia
, maka mereka valid untuk disertakan sebagai argumen padaproses(Manusia m)
tersebut.Secara sederhana, composition adalah hubungan has-a (memiliki) sementara inheritance adalah hubungan is-a (adalah sebuah).
nice info gan, terima kasih ilmunya, bagus juga nih sebagai tambahan ilmu buat ngerjain skripsi. Mohon izin share linknya ya. terima kasih
Ping-balik: Cari referensi di internet tentang UML, ketemu artikel bagus nih, Banyak membantu dalam penyusunan skripsi saya | Rahmad Ikhsan Blog
Pak, pada bagian “Kesalahan Rancangan Domain Model Akibat Berfokus Pada Penyimpanan Data”.
Itu artinya kita harus fokus pada data yang terihat secara visual bagi end user, sedangkan data yang bersifat coding disembunyikan dari diagram, begitu pak?
Justru sebaliknya, domain model bukan mewakili apa yang terlihat secara visual (model yang mewakili apa yang terlihat secara visual disebut view model). Domain model juga bukan mewakili apa yang akan disimpan ke database.
Domain model harus mewakili permasalahan yang dihadapi dan logic untuk menyelesaikannya. Semua solusi untuk permasalahan tersebut harus ada di domain model, misalnya dalam bentuk method atau pola.
Sebagai contoh, bila merancang model yang hanya berisi data, coba tanya: ‘Apa saja operasi yang perlu dilakukan untuk menyimpan data ini? Apa saya yang perlu dihitung sebelum disimpan atau ditampilkan?’ Biasanya letak operasi ini tersebar di kode program UI. Pindahkan kode program sebagai method/operasi di class yang bersangkutan.
Jujur saya sewaktu kuliah dulu masih belum diajarkan mengenai pembuatan UML ini, tapi didunia kerja seperti untuk project kolaborasi penting sekali.
Ditempat kerja, saya hanya pakai usecase,flowcart dan ERD saja.
Kemudian, setiap saya baca panduan pembuatan UML, baik itu buku atau skripsi orang, mengapa selalu tampak TAK ADA YANG SAMA konsep dan simbol nya, berbeda dengan dengan Flowcart yang konsep dan tampilannya sama?
Saya kira, mungkin saya harus baca pembuatan UML yang lebih sedehana dulu, misalya inputan data barang dulu, sebelum membahas mengenai operasi trangsaksi.
Flowchart dipakai untuk menggambarkan eksekusi program secara berurut. Ini adalah sesuatu yang ketat. UML Class Diagram dipakai untuk mengklasifikasikan masalah. Masing-masing perancang bisa memiliki sudut pandang mereka dalam melakukan klasifikasi. Tapi yang pasti, notasi UML selalu memiliki makna yang sama (seperti class, association, composition, dsb). UML dapat di-customize dengan memakai stereotype, tp notasi dasar-nya tetap memiliki makna yang sama.
Untuk contoh perbedaan flowchart dan class diagram, coba baca https://thesolidsnake.wordpress.com/2014/09/25/belajar-menerapkan-object-oriented-programming-oop/. Semoga bisa membantu dalam memahami OOP.
waduh terimakasih banyak pak. saya lagi coba cari2 bahan tentang UML dan ini sangat membantu saya. terimaksih ya pak, karena penjelasannya sangat sederhana utk dipahami. thks
bang, mau tanya nih, bisa ndak ERD diagram dirubah ke Class Diagram? Terus dalam kondisi ama ERD diagram dirumbah ke Class Diagram dan bagaimana caranya?
ERD dan Class Diagram memiliki tujuan dan fungsi yang sangat berbeda.
Class Diagram dipakai untuk menggambarkan klasifikasi kode program. Diagram ini menjawab pertanyaan seperti: “Bila saya ingin menambah fitur X, dimana saya harus melakukan perubahan kode program?”
ERD dipakai untuk menggambarkan aspek penyimpanan data, biasanya dalam bentuk tabel di database. Pada development modern yang memakai ORM seperti JPA, penyimpanan data berlangsung secara transparan dari object ke tabel. Dengan demikian, ERD akan sangat mubazir bila sudah ada Class Diagram dan penyimpanan data ditangani oleh teknologi seperti ORM dan OGM.
Pak kalo untuk persentasi ke si client menjelaskan sistem yg kita buat itu yg cocok pake diagram apa,
Saya belajar uml, flow dokumen,dfd , masi bingung cara implementasinya
Diagram seperti UML diagrams lebih ditujukan untuk kebutuhan anggota tim pengembangan software guna menyamakan visi dan misi.
Bila klien adalah product owner (bukan hal bagus!) yang memacu arah pengembangan software, maka klien wajib mengerti hal teknis sehingga komunikasi dapat dilakukan dengan berbagai diagram yang kamu pelajari.
Bila klien adalah stakeholder (sponsor atau pemberi dana), maka presentasi yang lebih efektif adalah penyampaian seperti apa saja peningkatan nilai bisnis yang dicapai setelah penggunaan software. Tampilan screenshoot mungkin akan sedikit membantu.
Di tmpat saya kuliah semester 6 ada mata kuliah opsi, saya masi bingung mau pilih opsi RPL atau sistem informasi, keduanya sepertinya saling membutuhkan,
Saya ingin menjadi developer sekaligus analyst, mohon pencerahannya pak,
Pada metode tradisional, analyst (tepatnya system analyst) adalah seorang yang hanya memiliki spesialisasi di sistem informasi. Peran tunggal seperti ini kini dianggap tidak efektif seiring dengan ditinggalkannya waterfall.
Pada metode agile secara umum, setiap developer harus bersedia melakukan analisa. Dengan demikian, istilah analyst disini lebih merujuk kepada senior developer (berpengalaman) yang berperan menentukan arah pengembangan secara jangka panjang. Secara spesifiknya, bila kita melihat beberapa metode modern: DDD mewajibkan semua anggota tim memahami bisnis, tetapi SCRUM memberi kemungkinan bagi business analyst untuk mengambil peran sebagai product owner. Walaupun demikian, baik product owner maupun scrum master bukan ‘pemimpin’ yang memberikan perintah (melainkan lebih ke arah ‘hakim’ yang menegakkan aturan) karena SCRUM tidak mengenal peran project manager.
Berdasarkan pandangan di atas, seandainya saya mencari SDM untuk proyek agile, maka saya akan mencari developer (sekaligus system analyst) yang kuliah di bidang computer science. Sementara itu, saya akan cenderung memilih business analyst lulusan sekolah bisnis (misalnya yang mememiliki gelar Master of Business Administration / MBA).
Untuk penjurusan yang hendak kamu ambil, silahkan konsultasikan lebih lanjut dengan dosen pembimbing atau ketua jurusan di kampusmu untuk memperoleh informasi yang lebih detail.
Terima kasih banyak atas penjelasannya pak, sangat detail dan juga mudah saya mengerti. dengan bapak memberikan contoh atau kasus yang sekarang menjadi trend.
dengan memahami dunia kerja itu di era modern ini seperti apa dalam bidang yang sedang kita geluti saya jadi tau harus bagaimana. 🙂
pak boleh tidak saya minta contoh implementasi model proses yang saat ini sedang bapak gunakan dengan tim ?
Reblogged this on Hariyadi Teguh.
Pak, saya mau bertanya beberapa hal.
Yang pertama, langkah-langkah yang tertulis di atas merupakan contoh perancangan sistem dengan menggunakan metode ICONIX process. Di kampus saya saat ini kami cuma diajarkan metode pengembangan Waterfall saja. Apakah langkah-langkah untuk menggunakan UML di atas bisa diterapkan pada metodologi Waterfall, atau ada yang harus diubah ?
Yang kedua, pada diagram yang pertama, terlihat bahwa sebelum membuat Domain model dan Use case model, sebelumnya harus dibuat GUI prototype dulu. Pertanyaan saya, apakah harus dibuat GUI prototype dulu atau bisa langsung membuat domain model ?
Terima kasih
Iya, UML tetap bisa digunakan sebagai artifact yang dihasilkan pada tahap analisa dan perancangan di waterfall.
Bila jumlah tim tidak banyak dan semuanya sudah terbiasa dengan sistem yang hendak dibangun, GUI prototype boleh dilewatkan dengan asumsi semua anggota tim punya bayangan yang sama seperti apa UI yang diharapkan. Secara pribadi, karena saya memakai generator dari domain class menjadi UI (dengan simple-jpa), saya langsung mulai dengan membuat domain model sederhana.
tanya pak. intinya adalah “bagaimana menulis use case yang efisien”
bagaimana menulis use case yang mempunyai lebih dari 1 aktor. misalnya seperti “Use Case Login”. Nha biasanya yang berhak untuk menggunakan Use Case Login ini kan, kalo gak Aktor Member ada juga Aktor Administrator. saya bingungnya disitu pak. kalo saya tulis satu-satu dari segi pengguna, sepertinya itu kurang efisien.
saya punya kasus gini pak. misal saya mempunyai use case “member mengisi biodata diri”. nha ketika member mengisi biodata diri kan, member ini mengisi beberapa field yang diperlukan, seperti nama, provinsi, kota, dll. nha sebernya use case “member mengisi biodata diri” ini kan juga membutuhkan use case “provinsi” dan use case “kota”. selain itu use case “provinsi” ini juga membutuhkan use case “tambah provinsi”, “edit provinsi”, dan “hapus provinsi”, begiti juga dengan use case “kota”. kalo misalnya ini saya buat, kayaknya juga agak berlebihan. tapi kalo use case – use case tersebut gak saya buat, saya bingung nulis hal tersebut pada makalah saya. ini saya lagi ngerjain tugas kuliah pak. sebelumnya terimakasih pak.
Maaf pak, itu ada 2 pertanyaan. udah saya kasih nomor, cuma gak tau kenapa, nomornya gak muncul.
pake sofware apa ya untuk bikin use case diagram, activity diagram & sequence diagram
ini baru tulisan mantab yang blm pernah terdengar gosipnya di bangku kuliah, btw sangat mengena sekali, selama ini bikin analisa kecil langsung koding, ini saya mau bikin skripsi udah jdi programnya, bingung mau bikin UML nya, untuk kelengkapan skripsi, terharu sekali stelah melihat membaca tulisan anda. hik hisk, ajarin dong bang tekniknya, pake tool apa yang bisa membantu, program saya presensi karyawan. deal harga fb: oktakurnaiwan@yahoo.com trims
Ping-balik: Object Oriented vs Structure Design - Irfan Darmawan's blogIrfan Darmawan's blog
tutorial bermanfaat
mas gimana buat sequence digram yang menggunakan MVC sama penggunaan include yang benar itu gimana? soalnya saya menggunakan include masih disalahkan
trims banyak atas sharing ilmunya…
Masih bingung dalam pembuatan robustnes diagram , jadi robustnest diagram itu apakah sama fungsinya dengan flow chart, activity diagram, terus perbedaannya dengan sequence diagram itu apa ?
terima kasih penjelasannya….
Permisi, mau tanya nih. Apa di domain model harus ada relasi generalisasi (is-a)?
Makasihh
Tanya Mas..
apakah UML hanya menggambarkan sistim dari sebuah aplikasi? apakah UML bisa menggambarkan sebuah rutinitas sebuah pekerjaan? terimakasih
Ping-balik: Domain Analysis Adalah
bagaimana langkah-langkah pengembangan software menggunakan UML