Seberapa dalam seharusnya seorang programmer mengembangkan pemahamannya tentang Unified Process dan UML? [Tutup]

Saya tahu banyak tempat menggunakan UML dan proses terpadu sebagai model pengembangan mereka ... tapi kemudian ada banyak yang tidak. Apakah penting untuk memiliki lebih dari sekadar pemahaman dasar dan fungsional dari mata pelajaran ini atau lebih baik fokus pada pengembangan keterampilan pemrograman di bidang lain (mis. Pengembangan bahasa, IDE, dll)?

Kecuali jika Anda berpikir menonton cat kering sementara selokan sedalam leher adalah saat yang menyenangkan, abaikan Proses Terpadu. Tunggu, mengabaikannya tidak cukup. Takut itu. Sejauh yang saya tahu, ini hanya digunakan hari ini oleh tempat-tempat besar yang melampaui semua harapan efisiensi, kualitas, atau kewarasan.

UML, di sisi lain, dapat menjadi notasi berguna untuk konsep pemrograman penting. Dapatkan Distilasi UML Martin Fowler , berikan skim, dan latih diagram sketsa sambil memikirkan desain. Ini adalah keterampilan yang saya gunakan secara teratur dan saya senang saya memilikinya.

Ketahuilah bahwa orang-orang mencoba menggunakan UML secara berlebihan. Papan tulis UML sambil mendiskusikan berbagai hal itu luar biasa. Diagram sesekali dalam dokumentasi yang diterbitkan dapat menjadi hal yang bagus. Tetapi upaya untuk mendokumentasikan seluruh basis kode Anda di UML tidak ada gunanya dan boros. Dan keinginan untuk "memprogram di UML" bodoh. Jika Anda menemukan orang seperti itu, lari. Tapi pertama-tama, beri nama dahi mereka dengan diagram urutan, sehingga kita semua diperingatkan dengan benar.

Jangan terlalu banyak menghabiskan waktu di UML. Di tim saya, saya satu-satunya yang mengenal UML dengan sangat baik dan karenanya membuat use case, komponen, state, deployment, dan diagram lainnya. Anggota tim yang lain lebih baik daripada saya untuk membuat kode tetapi tidak sebaik diagram UML.

Trik yang kami gunakan adalah untuk fokus pada diagram kelas di tingkat pemodelan untuk menentukan struktur aplikasi dan juga membiarkan pengembang / arsitek untuk kode yang mereka inginkan. Kami kemudian menggabungkan model dengan kode baru dan memperbarui model di setiap iterasi. Sangat mudah dan sangat efisien. Kami berkembang di Jawa dengan Omondo EclipseUML.

Saya akan merekomendasikan untuk tidak menggunakan MDD yang bagi saya adalah omong kosong nyata !! Pemodel akan mencoba untuk mengambil lebih banyak daya di dalam proses pengembangan tetapi ini tidak akan membuat nilai apa pun jika mereka mencoba untuk menghasilkan semua kode dari model. Kode ini milik pengembang / arsitek tetapi bukan milik pemodel. UML seharusnya hanya berupa tampilan persyaratan proyek (mis. Usecase, urutan, dll ....) proses (misalnya diagram keadaan atau aktivitas), penyebaran (penyebaran, diagram komponen). Diagram kelas harus berupa tampilan kode dan diagram kelas UML hanya boleh digunakan sebagai penampil kode. Pengkodean Java harus menghormati pendekatan objek dan UML yang juga merupakan bahasa objek sangat membantu untuk menghindari omong kosong dan kode bodoh.

Yang paling penting adalah iterasi diagram kelas antara model ke kode dan kode ke model. Maksud saya sebenarnya bukan sinkronisasi langsung, tetapi untuk dapat menggabungkan kode dan model pada setiap iterasi. Saya menggunakan Omondo EclipseUML dan berpikir mereka adalah satu-satunya yang memiliki java, entitas database dan ID model. ID penggabungan benar-benar konsep yang kuat dan sangat cocok untuk proyek tangkas kami.

Rekomendasi saya adalah jangan membeli buku apa pun. Anda harus memiliki pendekatan objek dan menggunakan bahasa diagram kelas untuk memvisualisasikan objek Anda untuk membuat arsitektur yang lebih baik. Jika salah satu anggota tim tahu UML maka gunakan diagram lain, jika tidak diagram kelas akan cukup.

Unified Process dan UML adalah seperangkat alat berpikir dan komunikasi terstruktur. Alat-alat ini membantu dalam beberapa cara; baik dengan mendefinisikan cara berbicara tentang desain, dan dengan membantu kami bekerja melalui detail dan aspek desain kami.

Meningkatkan pemikiran Anda sendiri sangat penting untuk menyelesaikan detail desain dan untuk menemukan jalan Anda ke produk yang waras dan koheren. Disiplin pribadi membantu Anda fokus, melacak detail, memikirkan ujung-ujungnya, dan mengingat apa yang Anda pikirkan berbulan-bulan kemudian.

Meningkatkan bagaimana desain dibicarakan dan ditingkatkan sangat penting untuk membuat sekelompok desainer menjadi lebih jauh, lebih cepat. Disiplin kelompok membantu mendapatkan lebih banyak dari kelompok.

Namun ingat tat UML dan Proses Terpadu hanyalah satu dari banyak alat berpikir. Mereka masuk akal, tetapi mereka mungkin cocok atau tidak cocok dengan Anda atau grup Anda (yang sama pentingnya dengan faktor lain).

Dalam pikiran saya sekarang ada jalan di sekitar UML. Dapatkan buku dan pelajari. Anda membutuhkannya untuk:

• baca buku teknis yang menggunakan UML (ada banyak)
• gunakan itu sebagai alat sketsa untuk mendiskusikan ide / solusi dengan perguruan tinggi.
• beri diri Anda cara cepat untuk memvisualisasikan solusi yang Anda pikirkan dan alasan tentang itu.
• baca / alasan tentang desain teknis / fungsional di perusahaan tertentu

Proses terpadu yang saya pikir adalah cerita yang berbeda, itu tergantung pada atasan Anda. Saya akan membaca buku paling tidak untuk mengetahui apa itu dan kapan saatnya Anda benar-benar membutuhkannya untuk mempelajarinya.

Semoga ini membantu.

Saya tidak berpikir bahwa Anda memerlukan pengetahuan yang sangat mendalam tentang UML tetapi Anda harus dapat melihat diagram dan dapat mengetahui apa yang terjadi. Apa yang HARUS Anda coba untuk dapatkan pengetahuan yang mendalam adalah pola desain yang berbeda (beli buku). Saat Anda membuat desain sendiri, itu akan membantu Anda mengetahui pola desain dan pola UML bahkan jika Anda tidak benar-benar menariknya. Ini juga membantu Anda dalam memahami diagram UML ketika Anda melihatnya, karena Anda mungkin mengerti sedikit lebih baik mengapa UML terlihat seperti itu.

Saya sudah berada di biz ini sejak 1987 dan satu-satunya saat saya berurusan dengan UML dan Proses Terpadu adalah beberapa kali ketika beberapa konsultan yang keliru mendapat bayaran sejumlah uang sangat besar untuk memaksa memberi makan staf dengan semua hal-hal kecil dari overhyped ini, metodologi berlebihan, dan tendensius. Sebagai buntut dari setiap upaya untuk menerapkan omong kosong yang tidak tercemar ini, kami akhirnya menghasilkan dokumentasi yang hampir segera usang untuk mengisi Perpustakaan Kongres sampai meluap dan terus meluap, sambil secara bersamaan memperlambat desain dan pengembangan proyek-proyek kami tanpa pertimbangan.

Jika produk bisnis Anda diukur dalam pound kertas dan / atau ukuran dokumentasi, tidak akan pernah dibaca lebih dari sekali (jika banyak), dan selamanya akan menjadi usang, dan itu akan menjadi dasar di mana Anda dibayar, maka dengan segala cara, pergi seluruh babi dengan omong kosong ini.

Jika sebaliknya, jalankan teriakan untuk bukit saat penyebutan pertama UML dan UP. Atau lebih baik, kalahkan orang pertama yang mengucapkannya menjadi bubur.

Anda dapat menyebutkan bahwa Anda dapat menggunakan UML TANPA Proses Terpadu. Saya menggunakan banyak UML pada saat yang sama dari pemrograman, tetapi, bagi saya penting untuk secara praktis, tidak hanya menggunakannya karena "itu alat baru yang mengkilap".

Diagram kelas, kasus penggunaan dan diagram berurutan adalah favorit saya. Saya tidak perlu menggunakan diagram jenis lain sesering ini.

Banyak perusahaan tidak menggunakan Proses Bersatu / Rasional.