Tips Memakai Enterprise Architect Untuk Merancang Domain Model


Merancang UML class diagram boleh dibilang adalah sesuatu yang bersifat pribadi. Hasil rancangan setiap orang bisa berbeda-beda tergantung kreatifitas dan style masing-masing. Mungkin architect yang pernah memakai brush di Photoshop akan setuju dengan pendapat saya (apa hubungan Photoshop dan UML?!). Yup! Perbedaan yang ada sah-sah saja selama hasil rancangan dapat dipahami dan dipakai oleh anggota tim lainnya. Dan itu sebabnya mahasiswa yang membuat UML class diagram dengan tool reverse engineering guna sekedar mengisi halaman skripsi tidak akan mendapat manfaat dari UML (selain pujian dari dosen yang kagum melihat tumpukan class diagram tanpa makna🙂 ).

Pada artikel ini, saya akan menuliskan beberapa hal yang sering saya lakukan dalam merancang domain model dengan menggunakan Enterprise Architect (EA) dari Sparx Systems.

Struktur Proyek

Umumnya proyek pada Enterprise Architect terdiri atas satu atau lebih model package yang memiliki satu atau lebih view. Model package ditujukan untuk melihat (atau meng-analisa) sistem yang sama dari beberapa aspek yang berbeda seperti requirement, development, dan sebagainya. Sebagai contoh, saya bisa membuat struktur proyek di EA seperti berikut ini:

Tampilan project browser

Tampilan project browser

Sebuah view tidak terbatas pada satu diagram. Ia boleh saja memiliki banyak diagram berbeda. Sebagai contoh, pada sebuah proyek inventory, saya dapat memiliki beberapa UML class diagram berbeda seperti pada gambar berikut ini:

Beberapa diagram berbeda dalam sebuah view

Beberapa diagram berbeda dalam sebuah view

Saya lebih senang memisahkan sebuah class diagram besar ke dalam beberapa diagram terpisah. Hal ini akan memberikan fokus bagi saya selama merancang. Selain itu, saya (dan anggota tim lain) akan lebih mudah memahami diagram karena hanya perlu membaca diagram yang berkaitan dengan permasalahan yang sedang dihadapi (tanpa harus menelusuri seluruh elemen yang ada). Bukankah itu kelebihan OOP? Developer tidak perlu tahu flowchart mulai dari A sampai Z untuk bisa mulai coding; developer hanya perlu fokus pada class yang terlibat.

Lalu, apa patokan dalam memisahkan diagram ke dalam beberapa diagram yang lebih kecil? Bila memakai domain driven design seperti yang saya lakukan, maka patokan yang tepat adalah boundary context. Setiap boundary context diwakili oleh sebuah diagram. Komunikasi antar diagram yang berbeda diusahakan seminimal mungkin dan hanya melalui class penghubung atau event.

Sebagai contoh, yang menghubungkan diagram pembelian dan diagram penjualan dengan diagram inventory adalah class Produk. Diagram pembelian hanya mengakses Produk yang berada di inventory. Ia sama sekali tidak mengakses class lainnya di inventory seperti Gudang dan Satuan secara langsung. Developer yang mengembangkan pembelian hanya perlu memahami Produk tanpa perlu tahu banyak internal lainnya yang ada di diagram inventory. Ia mungkin akan memakai Gudang atau Satuan secara tidak langsung melalui method di Produk, tapi ia tidak perlu tahu tentang itu. Semakin sedikit yang harus diketahui oleh developer, maka permasalahan dalam benaknya menjadi semakin sederhana, sehingga ia bisa menghasilkan kode program secara lebih cepat dan berkualitas.

Agar lebih rapi, saya dapat mengelompokkan class pada UML package diagram sehingga saya bisa memiliki daftar seluruh class yang ada. Untuk keperluan itu, saya bisa memakai sebuah view yang terdiri atas sebuah UML package diagram dimana masing-masing package diwakili sebuah UML class diagram. Sebagai contoh, struktur proyek saya kini berubah menjadi seperti berikut ini:

Pengelompokan dengan UML package diagram

Pengelompokan dengan UML package diagram

Tampilan package diagram akan terlihat seperti pada gambar berikut ini:

Contoh tampilan UML package diagram

Contoh tampilan UML package diagram

Memperjelas Diagram Dengan Diagram Lainnya

Ada saatnya dimana saya merasa bahwa class diagram tidak cukup jelas untuk menggambarkan permasalahan yang sedang saya hadapi. Untuk itu, saya terkadang menambahkan diagram lain untuk memperjelas class diagram tersebut. Pada EA, saya dapat melakukan hal ini dengan men-klik kanan sebuah class dan memilih menu Add seperti yang terlihat pada gambar berikut ini:

Menambah diagram lain pada class diagram

Menambah diagram lain pada class diagram

Sebagai contoh, saya memperjelas class FakturBeli dengan sebuah UML state machine diagram sehingga struktur proyek terlihat seperti pada gambar berikut ini:

Tampilan di project browser

Tampilan di project browser

Saya bisa melihat state machine diagram tersebut secara terpisah dengan men-double click diagramnya:

Contoh UML state machine diagram

Contoh UML state machine diagram

Memperjelas Diagram Dengan Constraint Dan Note

Constraint dapat dipakai untuk mendeskripsikan business rule sehingga pembaca diagram menjadi semakin memahami asosiasi yang ada. Untuk menambahkan constraint, saya dapat men-double click sebuah asosiasi, lalu memilih Constraints seperti yang terlihat pada gambar berikut ini:

Menambah constraint pada asosiasi

Menambah constraint pada asosiasi

Constraint yang saya tulis akan ditampilkan oleh EA langsung pada diagram seperti yang terlihat pada gambar berikut ini:

Tampilan constraint

Tampilan constraint

Saya juga bisa memberikan keterangan untuk class atau diagram dengan menggunakan note. EA menyediakan elemen yang mewakili catatan yang dapat ditemui dalam bentuk:

Memilih note

Memilih note

Setelah elemen note dibuat, ia dapat diasosiasikan dengan sebuah class seperti yang terlihat pada gambar berikut ini:

Class diagram dengan note

Class diagram dengan note

Kreatif Dengan UML Stereotype

UML membolehkan penggunanya untuk menciptakan kosa kata baru melalui fasilitas stereotype. Hampir seluruh elemen yang ada seperti class, asosiasi, atribut, dan method dapat memiliki sterotype-nya sendiri. EA memungkinkan saya untuk memakai atau menambah stereotype yang sudah ada seperti yang terlihat pada gambar berikut ini:

Memakai stereotype di EA

Memakai stereotype di EA

Pada contoh di atas, saya memberi stereotype simple-jpa pada semua class yang harus memiliki dynamic finders simple-jpa. Dengan demikian, saya tahu bahwa class-class tersebut memiliki method tambahan walaupun saya tidak menampilkannya di diagram.

Selain itu, pada class yang memiliki banyak atribut atau method, saya dapat menggunakan stereotype untuk melakukan pemisahan seperti yang terlihat pada gambar berikut ini:

Memakai stereotype untuk mengkategorikan method

Memakai stereotype untuk mengkategorikan method

Terlalu banyak method pada sebuah class adalah sebuah smell code. Tapi hal ini tidak dapat dihindari pada aggregate root yang menerapkan composite pattern. Method seperti bayar() sebenarnya akan mendelegasikan tugasnya ke KewajibanPembayaran.bayar(). Cara terbaik yang bisa saya lakukan adalah melakukan kategorisasi melalui stereotype sehingga class tetap mudah dibaca.

Menyembunyikan Detail Yang Tidak Dibutuhkan

Saya memiliki class FakturJual yang diturunkan dari Faktur. Keduanya berada di diagram yang berbeda (faktur dan penjualan). Pada diagram penjualan, saya tidak perlu menyertakan Faktur karena saya hanya ingin berkonsentrasi pada FakturJual. Bila hanya menyertakan FakturJual tanpa Faktur, maka EA akan menampilkan struktur inheritance untuk class tersebut menjadi seperti pada gambar berikut ini:

Superclass tidak harus selalu ditampilkan

Superclass tidak harus selalu ditampilkan

Untuk menambahkan superclass yang berada di diagram lain, saya dapat men-klik kanan class dan memilih menu Advanced, Parent… seperti yang terlihat pada gambar berikut ini:

Menambah superclass

Menambah superclass

Bila saya harus memakai class dari diagram lain, saya dapat men-drag class dari diagram lain tersebut ke diagram yang sedang aktif. EA akan memberikan informasi bahwa class tersebut berada di package lain seperti yang terlihat pada gambar berikut ini:

Class dari diagram lain

Class dari diagram lain

Bila menyertakan class dari diagram lain seperti pada gambar di atas, biasanya saya tidak ingin menampilkan detail untuk class tersebut. Hal ini karena detail class tersebut termasuk asosiasinya bisa dilihat sendiri di diagram tempat ia dibuat. Untuk menyembunyikan atribute atau method dari sebuah class, saya dapat men-klik kanan class tersebut dan memilih menu Feature Visibility…. Pada dialog yang muncul, saya dapat menentukan apa saja yang perlu ditampilkan atau disembunyikan, seperti yang terlihat pada gambar berikut ini:

Menyembunyikan attribute dan method

Menyembunyikan attribute dan method

Saya juga dapat memilih Wrap Features atau Truncate Features agar class dengan nama atribut atau method yang panjang dapat diperkecil sehingga tidak memakan banyak tempat.

Perihal Solid Snake
I'm nothing...

One Response to Tips Memakai Enterprise Architect Untuk Merancang Domain Model

  1. Dimas Setya mengatakan:

    ada video tutorial bikin program menggunakan EA gak mas? trims

Apa komentar Anda?

Please log in using one of these methods to post your comment:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

%d blogger menyukai ini: