Seberapa sering Anda menggunakan UML Formal?


33

Saya menggunakan MUML ad-hoc (bahasa pemodelan buatan) untuk merancang dan menjelaskan sistem dengan cukup sering. Itu terlihat mirip dengan UML dan cenderung cukup dipahami.

Namun, saya sudah memiliki satu atau dua profesor yang mendukung penggunaan UML formal yang ketat, sedekat mungkin dengan spesifikasi. Saya selalu curiga bahwa UML yang ketat tidak terlalu umum seperti yang mereka klaim. Jadi, bagaimana dengan itu - seberapa sering Anda benar-benar menggambar diagram lengkap yang menggunakan semua akhiran garis yang tepat, multiplisitas, simbol tipe anggota, dll?


9
Pertanyaan bagus Sikap profesor Anda mungkin merupakan gejala dari keterputusan saat ini antara beberapa keterampilan yang dipelajari di kampus & keterampilan yang diperlukan di dunia "nyata".
Paddyslacker

@ Paddy, tujuan pendidikan (terutama di tempat-tempat di mana "profesor" mengajar) bukan hanya menggunakan keterampilan yang dibutuhkan oleh dunia nyata.
P Shved

3
Pada prinsipnya Anda benar @Pavel, tetapi dengan risiko keluar topik, saya ingin memperjelas poin saya. Saya tidak berpikir ada orang dengan gelar di bidang akuntansi yang tidak dapat menghitung, tetapi ada orang dengan gelar Ilmu Komputer yang tidak dapat kode. Ada beberapa pertanyaan tentang Stack Overflow mengenai hal ini. Benar atau salah, sering ada keterputusan antara keahlian yang diharapkan oleh majikan yang mempekerjakan lulusan dan apa yang diketahui oleh lulusan perguruan tinggi.
Paddyslacker

1
@ Paddy Ilmu Komputer! = Rekayasa Perangkat Lunak Meskipun, saya menyesalkan sejumlah besar lulusan CS yang tidak dapat kode, pemrograman tidak harus menjadi fokus Ilmu Komputer.
George Marian

5
@ George Marian: Mitos. Pemrograman dan pengembangan perangkat lunak diajarkan dalam kursus CS. Mengatakan "cs! = Se" adalah alasan setengah-setengah untuk tidak mengajarkannya dengan benar.
Steven Evers

Jawaban:


45

Tak pernah.

Heck, sudah bertahun-tahun sejak terakhir saya buat setiap UML. Diagram garis pada papan tulis dan memo kertas tidak masuk hitungan.

Faktanya, kami hanya menghapus satu-satunya pertanyaan UML dari panduan yang kami gunakan selama wawancara, karena tidak ada di antara kami yang benar-benar peduli dengan jawabannya.


+1 Saya sepenuhnya setuju. Saya menyadari bahwa saya mungkin jinxing sendiri dan klien saya berikutnya akan menuntut UML formal dalam dokumentasi!
Paddyslacker

2
Saya pikir selama UML informal dipahami oleh semua orang di ruangan itu, tidak masalah simbol apa yang Anda gunakan.
Richard

4
+1 Setuju. Saya tidak dapat mengingat kapan terakhir kali kami menggunakan UML apa pun. Terlalu banyak waktu yang dibutuhkan dan terlalu sedikit pengembalian, tanpa ROI.
Walter

3
UML tampaknya akan menempuh jalur untuk menjadi bahasa pemrogramannya sendiri (karena Anda dapat menghasilkan kode jelek dari diagram dengan beberapa sistem). Orang yang menginjili biasanya arsitek astronot yang menghabiskan seluruh waktu mereka dalam teori dan sedikit pada aplikasi. Secara pribadi, saya lebih suka menulis kode karena lebih cepat dan tidak terlalu membosankan.
Evan Plaice

1
@Van: masalahnya akhirnya adalah bahwa jumlah detail yang diperlukan untuk model yang cukup akurat untuk benar-benar menghasilkan sistem menyebabkannya mendekati kompleksitas sistem itu sendiri - menjadikannya tidak praktis . Tentu saja selalu ada orang, seperti astronot Anda, yang lebih suka tinggal di simulacrum mereka daripada di dunia yang diwakilinya.
Shog9

14

Saya menggunakan cukup UML (dalam hal jenis diagram dan isi informasi dalam diagram) untuk menyampaikan maksud saya agar saya atau orang lain dapat mengimplementasikan sistem atau subsistem. Dan satu-satunya alasan saya menggunakan UML adalah karena seperangkat simbol yang dikenal luas yang masing-masing berarti sesuatu yang sangat spesifik, sehingga tidak ada ambiguitas - setiap insinyur perangkat lunak harus dapat melihat diagram dan memahami apa yang saya coba katakan tentang sistem.


11

Ironisnya, UML seharusnya fleksibel.

Dalam dunia nyata, itu tidak seharusnya menjadi latihan bertele-tele dalam melakukannya satu cara yang benar. Ini adalah tentang berkomunikasi secara efektif dan mendokumentasikan sistem / proses / ide.

Untuk menjawab pertanyaan Anda, saya bersama yang lain. Saya tidak pernah sepenuhnya menggunakan UML formal sepenuhnya.


6

Saya menggunakan UML dengan sangat teratur selama sekitar empat tahun untuk produk yang menghasilkan semua (sebagian besar) kerangka kode dari Rational Rose.

Lima tahun terakhir telah ada lebih banyak "kotak dan panah" yang sebagian besar ditemukan di tempat dan biasanya cukup untuk menyampaikan gagasan umum. UML yang benar secara formal hanya beberapa kali selama ini.


sangat??! orang benar-benar menggunakan fitur itu?
ozz

2
"bekas". Waktu lampau.
FeatureCreep

4

Namun, saya sudah memiliki satu atau dua profesor yang mendukung penggunaan UML formal yang ketat, sedekat mungkin dengan spesifikasi.

Tanyakan profesor Anda kapan terakhir kali ia menggunakan pendekatan itu pada sistem nyata. Serius.

Saya mencoba seformal mungkin dengan UML, tetapi hanya jika / ketika masuk akal. Orang-orang Zelot di kedua sisi spektrum (dari koboi hingga formalis yang tegang) gagal memahami hal itu.

Ada konteks di mana pendekatan yang kurang kaku (seperti yang Anda gunakan secara pribadi) adalah pendekatan terbaik untuk diikuti. Contoh yang baik adalah untuk sistem atau perubahan kecil, di mana persyaratannya kecil dan tidak sepenuhnya ditentukan; kelompok yang bertanggung jawab adalah efisien dan efektif; lebih penting untuk mengeluarkannya daripada membuatnya sempurna. Ini dilakukan berulang dan beberapa kekurangan dapat diterima.

Atau mungkin Anda berada di tahap di mana Anda melakukan guestimation dan membuat sketsa sebagai lawan fase pemodelan formal penuh. Itu adalah contoh yang akan muncul di pikiran.

Di lain waktu, Anda memerlukan pendekatan UML formal yang kaku. Misalnya, Anda mungkin terikat kontrak; Anda memiliki sejumlah besar pengembang di banyak tim (mungkin didistribusikan); ruang lingkup proyek mungkin dalam beberapa tahun; ini adalah sistem yang sangat besar (termasuk komponen perangkat lunak dan perangkat keras); biaya kegagalan tinggi, dll.

Di lain waktu , Anda harus menggunakan sesuatu yang lain sebagai gantinya / selain UML (model formal matematika aktual seperti petri nets, CSP, atau temporal logic). Contohnya adalah sistem waktu-nyata, sistem di mana kegagalan merupakan bencana besar (peralatan medis) atau di mana Anda terikat kontrak (mis. seperti di Eropa ketika mengembangkan sistem transportasi.)

Itu semua tergantung pada keadaan dan apa yang kita harapkan dari setiap pendekatan. Seorang profesor yang berpegang teguh pada formalitas hanyalah menjadi fanatik buta. Dunia teknik bukanlah dikotomi hitam-putih, benar / salah. Ini adalah dunia pertukaran yang cerdas.

Jika Anda cukup cerdas untuk menggunakan model kasual dan informal dengan cara yang efektif dan sesuai untuk menyelesaikan pekerjaan, maka lakukanlah. Dengan cara yang sama, Anda diharapkan mengenali kapan TIDAK menggunakan pendekatan informal dan / atau TIDAK menggunakan pendekatan formal.

Karena itu, Anda harus memainkannya dengan para profesor. Beri mereka tulang sehingga mereka memberi Anda nilai, dan jika itu berarti akhirnya tunduk pada mantra fanatik mereka, tidak apa-apa. Anda tahu apa yang cocok untuk Anda, dan mudah-mudahan, Anda akan tahu kapan harus menggunakan apa dan bagaimana di dunia nyata.


3

Sebagai bagian dari penelitian PhD saya, saya mempelajari bagaimana desainer berpengalaman menggunakan UML dalam kolaborasi desain (Meskipun dalam pengaturan buatan).

Temuan saya adalah bahwa metafora dan notasi UML dipinjam, tetapi ada sedikit kepatuhan pada ketatnya alat.

Kemudian, beberapa model mungkin secara iteratif diubah menjadi UML yang lebih ketat, sering kali ketika alat CASE yang menuntut terlibat untuk tujuan pembuatan kode.

Peringatan biasa dari penelitian akademis berlaku, tentu saja :)

Tautan ke abstrak kertas dan kertas itu sendiri (jika Anda tidak memiliki akses ACM) .

Selain itu, saya sangat merekomendasikan "Agile Modelling" Ambler.


1

Kami menggunakan UML formal untuk pembuatan kode ORM hibernasi. Kebanyakan hal lain adalah papan tulis informal atau putih. Ini hanya penting bagi kita dengan pembuatan kode karena kurangnya formalitas akan merusaknya.


1

Tergantung pada industri di mana Anda berada. Jika Anda bekerja untuk pelanggan yang sering memerlukan tinjauan teknis (mis. PDR, CDR dll.) Maka mereka lebih suka semacam standardisasi daripada sistem notasi ad-hoc. Khususnya pekerjaan pemerintah. Ini mencegah miskomunikasi dan penjelasan awal 15 menit dari notasi yang Anda temukan.

Juga, hanya karena Anda menggunakan UML tidak berarti Anda harus menandai setiap i dan melewati setiap t sesuai dengan standar. Itu hanya jika Anda ingin melakukan semacam pembuatan / eksekusi kode otomatis. Saya tidak tahu siapa pun yang telah melakukan itu selama lebih dari 1 proyek.

Di sisi lain, jika Anda hanya bekerja untuk perusahaan Anda dengan tim pengembang Anda sendiri, lalu siapa yang peduli notasi apa yang Anda gunakan. Meskipun, jika Anda memilih alat yang tepat maka itu bisa menjadi penghemat waktu nyata.

Dengan semua itu, Anda akan kesulitan bertahan di beberapa industri tanpa bisa mendesain menggunakan UML. Di industri lain, Anda tidak akan pernah melihatnya.

Selain itu, saya pikir Anda juga akan menemukan korelasi antara industri-industri yang memerlukan desain yang tepat karena biaya koreksi yang tinggi sebagai pengguna berat UML; versus industri yang biaya koreksi desain sedikit lebih dari perubahan dokumentasi / kode sebagai tempat yang UML mungkin tidak pernah digunakan.

Sehubungan dengan pertanyaan awal. Sebagian besar perguruan tinggi cenderung untuk melatih siswa mereka untuk perusahaan yang paling sering merekrut siswa mereka. Jika profesor Anda berpikir bahwa UML itu penting maka tidak akan mengejutkan saya bahwa banyak bisnis yang merekrut dari sekolah Anda menggunakan UML. Jadi, Anda harus belajar menggunakannya.


0

Ketika saya membaca tentang UML saya mencoba ini pada semua masalah yang harus saya selesaikan dalam kursus C ++ saya. Untungnya salah satu contoh pertama yang saya coba adalah menggambarkan daftar tertaut.
Tidak bekerja
Konon, ditambah dengan proses pemodelan yang baik, UML berguna. Hanya karena itu untuk standar yang lebih baik atau lebih buruk.
Saya akan senang melihat deskripsi bahasa pemrograman meta template. Saya pikir itu akan banyak membantu dalam memahami apa yang terjadi di <<<>> -land


0

UML menyakitkan jika Anda juga mencoba pengembangan Model Driven. Maksud saya, UML adalah notasi grafis yang sangat berguna saja dan yang lainnya tidak berguna. Saya tidak menghabiskan untuk pemodelan tetapi menggunakan UML setiap hari untuk membuat struktur proyek saya. Apa yang saya lakukan adalah menggambar diagram usecase dasar dengan cepat pada tingkat kebutuhan, lalu segera beralih ke diagram kelas. Saya menambahkan keterlacakan persyaratan antara usecase dan diagram kelas. Diagram kelas saya juga membuat kode karena disinkronkan secara langsung. Tidak ada tag dalam kode semua model disimpan dalam model UML yang dipetakan ke proyek Java.

Saya membuat kerangka aplikasi saya dengan beberapa diagram kelas, lalu beralih ke kode. Setelah saya selesai kode saya menggabungkannya dengan model. Ini adalah semacam iterasi antara kode dan model tempat kode menjalankan model. Jadi diagram kelas saya memberi saya tingkat abstraksi dan kode saya yang lebih tinggi sementara kode saya memberi saya implementasi logika bisnis saya (misalnya metode).

Pemodelan UML membutuhkan kurang dari 10 menit per hari, yang dilakukan ketika saya perlu waktu untuk memikirkan apa yang perlu saya kembangkan dan bagaimana caranya.

UML hebat, fantastis, dan sangat berguna tetapi pengembangan model tidak berguna !!


Saya tidak setuju bahwa MDD tidak berguna. Saya telah bekerja di beberapa proyek di mana itu berhasil. Dibutuhkan konteks kerja tertentu untuk membuatnya berfungsi. Kami masih belum cukup tahu tentang rekayasa perangkat lunak untuk menerapkannya secara efektif dalam semua situasi.
luis.espinal

0

Jika saya mendokumentasikan sistem yang telah kami terapkan, maka saya mencoba meletakkannya dengan UML formal lengkap. Tetapi sisa waktu, saya hanya menggunakan sebanyak yang diperlukan untuk mendapatkan ide. Saya juga menemukan diri saya menggunakan lebih banyak DFD daripada UML, karena tampaknya lebih cocok untuk sistem yang kami rancang akhir-akhir ini.


0

Saya baru saja keluar dari perguruan tinggi saya yang seharusnya (paling tidak untuk sementara) karena desakan mereka yang keras pada aktivitas pemodelan visual yang terlalu banyak memakan waktu, tugas-tugas forum, hal-hal soft skill berlebihan berlebihan yang dimiliki siapa pun yang tumbuh di sekitar komputer atau pernah melirik secara serius menuju antarmuka pengguna akan menjadi cukup baik sehingga pikiran untuk berutang terlalu banyak akan membuat orang ingin memecahkan banyak hal dengan frustrasi.

Saya harus memilih antara mempelajari apa yang saya lihat menuntut pekerjaan entry-level dan junior-level dan apa yang harus dilakukan CES untuk akreditasi ABET universitas, yang menyebabkan para pembuat keputusan menjadi bodoh ketika ada masalah mencolok dengan kendala waktu dan harapan yang tidak realistis yang penilaian PERT akan mengungkapkan. Universitas tidak mempraktekkan apa yang diajarkannya.

Menurut pendapat saya, Proses Terpadu memiliki banyak manfaat, tetapi seluruh praktik mencetak artefak visual, apa pun bahasa pemodelannya agak konyol. Dokumen yang disempurnakan secara iteratif yang berisi daftar seri, seperti yang mungkin dihasilkan dengan Word, Workflowy, Evernote, OpenOffice, atau nama pengolah kata sangat mampu mendokumentasikan apa yang diperlukan oleh Proses Terpadu. Sesuatu yang biasa-biasa saja ini dapat dengan mudah dikerjakan oleh banyak pengguna, dikendalikan versi, dan jika seseorang memilih alat yang tepat untuk melakukannya, sebuah tim bahkan dapat mengerjakannya pada saat yang sama. Ini jauh lebih mudah dilakukan daripada ketika UML tampak seperti mode yang diperlukan untuk menyatukan gerombolan.


posting ini agak sulit dibaca (dinding teks). Maukah Anda mengeditnya menjadi bentuk yang lebih baik?
nyamuk

1
Iya nih. Dinding teks. Cukup adil.
JLG
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.