Apabila berkaitan dengan reka bentuk OO yang baik, tetap mudah

Seorang bekas pelajar saya pernah melontarkan pernyataan tidak masuk akal, "Saya tidak mungkin membuat reka bentuk berorientasikan objek (OO); Saya tidak mempunyai wang!" Bertanya lebih jauh, ternyata, dalam fikirannya, reka bentuk OO memerlukan produk bernama Rational Rose, yang pada waktu itu harganya sekitar 500,00 per tempat duduk. Dalam fikirannya, tanpa Rational Rose, reka bentuk tidak mungkin dilakukan. Malangnya, jenis balderdash ini meluas; terlalu banyak orang berpendapat OO adalah proses berteknologi tinggi yang memerlukan alat berteknologi tinggi. Dalam praktiknya, alat dengan harga yang terlalu tinggi duduk tidak terpakai di rak (atau sangat tidak digunakan).

Oleh itu, dalam artikel ini saya membincangkan pelbagai alat reka bentuk OO, bagaimana ia berfungsi, dan mengapa saya fikir ia tidak berguna. Saya juga menerangkan bagaimana saya bekerja, dan apa yang terbukti berguna (sekurang-kurangnya bagi saya; anda dipersilakan untuk tidak bersetuju).

Alat tidak membimbing anda melalui prosesnya

Setiap reka bentuk OO yang berjaya saya hasilkan telah mengikuti proses yang hampir sama:

  • Ketahui mengenai domain masalah (perakaunan, perancangan pelajaran, dll.)
  • Kembangkan, dalam perundingan rapat dengan pengguna langsung, pernyataan masalah yang menjelaskan secara terperinci masalah pengguna, serta penyelesaian peringkat domain apa pun. Dokumen ini tidak menerangkan program komputer.
  • Lakukan analisis kes penggunaan formal , di mana saya menentukan tugas yang diperlukan untuk menyelesaikan masalah pengguna, sekali lagi, bekerjasama rapat dengan pengguna akhir yang sebenar. Biasanya saya membuat rajah aktiviti UML (Unified Modeling Language) untuk setiap kes penggunaan yang tidak biasa. (UML adalah representasi simbolik perisian sebagai gambar.)
  • Mulailah membangun model dinamik yang menunjukkan objek-objek dalam sistem, dan pesan-pesan yang dikirimkan oleh objek-objek tersebut kepada satu sama lain, sementara kasus penggunaan tertentu sedang dilakukan. Saya menggunakan rajah urutan UML untuk tujuan ini.
  • Saya serentak menangkap maklumat berguna pada gambar rajah model statik . Catatan: Saya tidak pernah membuat model statik (gambarajah kelas) terlebih dahulu. Saya telah membuang terlalu banyak model statik yang ternyata tidak berguna ketika saya mula melakukan model dinamik. Saya tidak lagi sanggup membuang masa yang diperlukan untuk melakukan model statik dalam keadaan hampa.
  • Langkah-langkah yang disebutkan di atas biasanya menghasilkan dua atau tiga kes penggunaan, setelah itu saya mula membuat pengekodan, memperbaiki model jika perlu.
  • Terakhir, saya mengusahakan kes penggunaan lain seperti yang dijelaskan, mengubah semula reka bentuk dan kod yang diperlukan untuk menampung kes baru.

Tidak ada alat reka bentuk masa kini yang membimbing anda melalui proses ini. Sebahagian besarnya, mereka adalah program menggambar dengan harga tinggi yang tidak berfungsi dengan baik, bahkan sebagai alat melukis. (Rational Rose, yang saya anggap sebagai salah satu yang paling mampu, bahkan tidak menyokong semua UML.)

Kejuruteraan pergi dan balik adalah proses yang asasnya cacat

Alat-alat ini tidak hanya berfungsi dengan baik, satu muslihat yang dilakukan oleh alat ini - menghasilkan kod - tidak bernilai. Hampir semua alat reka bentuk OO mengikuti konsep teknik perjalanan pergi balik di mana anda memulakan alat reka bentuk dengan menentukan reka bentuk anda di UML. Anda membuat dua set rajah penting: model statik yang menunjukkan kelas dalam reka bentuk, hubungan mereka antara satu sama lain, dan kaedah yang terdapat di dalamnya; dan model dinamik, yang merupakan susunan gambar rajah yang menunjukkan objek dalam sistem melakukan pelbagai tugas pada waktu runtime.

Setelah melengkapkan model, anda menekan butang ajaib, dan alat itu menghasilkan kod. Walau bagaimanapun, kod yang dihasilkan alat tidak begitu baik kerana dua sebab: Pertama, dalam banyak alat, kerangka untuk definisi kelas dibuat, tetapi kaedahnya hanyalah rongga kosong - model dinamik diabaikan. Kedua, tidak ada alat yang menyokong UML sepenuhnya, terutamanya kerana tidak ada yang dapat. UML adalah bahasa dengan sendirinya, yang mendorong improvisasi, dan banyak kandungan reka bentuk sebenarnya dinyatakan dalam komen yang biasanya diabaikan oleh alat reka bentuk.

Akibatnya, anda menggodam kod yang dihasilkan (kebanyakan kedai benar-benar menggodamnya). Dalam beberapa minggu, kod tersebut biasanya tidak ada kaitan dengan reka bentuk asalnya. Sebenarnya, anda dengan berkesan membuang reka bentuk anda dan kembali ke sindrom WHISKEY (Mengapa seseorang belum "koding"?). Bertahun-tahun program yang gagal membuktikan kepada saya bahawa pengekodan tanpa reka bentuk meningkatkan keseluruhan masa pembangunan sekurang-kurangnya tiga faktor, dan menghasilkan banyak kod yang lebih buruk.

Sekarang tiba proses perjalanan pergi balik: Anda membuka alat anda, menekan butang ajaib, dan mengimport kodnya, secara teorinya membina semula reka bentuk sehingga mencerminkan keadaan sebenar kod tersebut. Kejuruteraan terbalik seperti itu tidak berfungsi. Alat biasanya membuat gambarajah kelas baru, tetapi tidak pernah mengemas kini model dinamik. Oleh kerana model dinamik menjadi tumpuan prosesnya, reka bentuk anda sekarang tidak akan berguna melainkan anda kembali dan mengemas kini dengan tangan sendiri, sesuatu yang jarang dilakukan.

Dengan risiko mengulangi diri saya sendiri, proses perjalanan pergi balik mendorong pengaturcara untuk mengabaikan reka bentuk sepenuhnya dan hanya kod, kemudian mengubah kodnya menjadi gambar setiap kali. Dalam situasi ini, bagaimanapun, pengaturcara tidak merancang; mereka menggodam kod, kemudian membuat gambar kekacauan yang dihasilkan. Peretasan tidak sama dengan reka bentuk.

Walaupun reka bentuk memang merupakan proses berulang (reka bentuk berubah ketika kodnya dikembangkan), anda harus memulakan lelaran dengan mengubah reka bentuk terlebih dahulu, kemudian mengubah semula kod untuk mencerminkan reka bentuk baru. Untuk melakukan ini, anda harus dapat menentukan keseluruhan produk perisian di dalam alat (semasa anda menekan butang ajaib, program yang berfungsi sepenuhnya akan dikeluarkan) dan prosesnya akan sehala tanpa teknik terbalik mekanisme.

Alat CASE

Alat CASE (kejuruteraan perisian berbantukan komputer) seperti Rational Rose biasanya meletakkan kejuruteraan pergi dan balik pada teras produk. Walau bagaimanapun, kerana kejuruteraan pergi dan balik tidak melakukan apa-apa yang berguna, banyak pemaju menggunakan alat tersebut sebagai program lukisan yang mahal. Daripada alat yang ada, saya rasa tiga yang perlu dipertimbangkan (walaupun saya tidak menggunakannya):

  • Alat ArgoUML sumber terbuka percuma, yang ditulis di Java, berfungsi dengan baik dalam membuat diagram UML. Versi terbaru bahkan cuba membimbing anda melalui proses (dengan kejayaan kecil setakat ini, tetapi ini adalah permulaan yang baik).
  • GDPro Embarcadero, yang sebelumnya diedarkan oleh Advanced Software, menawarkan sokongan yang baik untuk kumpulan yang mengerjakan satu reka bentuk perisian, tetapi juga mempunyai kekurangan di jabatan ini. Sebagai contoh, seorang pereka tidak dapat melihat gambarajah model dinamik sambil mengunci kelas yang berkaitan dengan objek pada model dinamik secara automatik.
  • TogetherSoft's Together ControlCenter mengesampingkan masalah perjalanan balik dengan tidak melakukannya. Kod dan reka bentuk muncul di layar secara serentak, dan ketika Anda mengubahnya, yang lain akan berubah secara automatik. Bersama-sama ControlCenter tidak menyokong kumpulan pengaturcara dengan baik.
  • Saya juga harus menyebut Microsoft Visio secara ringkas. Visio adalah program menggambar yang menyokong UML mengikut fesyen, tetapi sokongannya meniru UI Rational Rose yang menyedihkan. Pelbagai templat lukisan untuk bentuk UML di Visio berfungsi lebih baik daripada sokongan UML yang ada, termasuk satu di bahagian "Goodies" di Laman Web saya.

Oleh itu, jika saya kurang memikirkan alat ini, apa yang perlu saya gunakan? Sejauh ini alat reka bentuk OO yang paling produktif adalah papan putih (bilik dengan papan putih dari dinding ke dinding, papan putih dari lantai ke langit-langit sangat sesuai) dan bantalan pasca-berukuran flip-chart, kepingan yang boleh anda lepaskan dan melekat di dinding. Saya telah menggunakan ini untuk merancang projek-projek penting dengan kejayaan besar. Lebih-lebih lagi, bekerja di papan putih memakan masa yang jauh lebih sedikit daripada bergelut dengan alat OO CASE.

Satu-satunya kesukaran dengan pendekatan papan tulis adalah menangkap maklumat di papan tulis. Papan putih yang dicetak memang ada, tetapi harganya mahal, tidak sedap dan terlalu kecil. Satu produk perkakasan yang rapi yang mengesan pergerakan pen di papan putih dan menangkap gegaran pen di komputer. Papan putih yang lain berfungsi seperti tablet digitizer gergasi. Walau bagaimanapun, penyelesaian ini terbukti terlalu terhad; reka bentuk berlaku secara serentak di papan putih di beberapa pejabat, pada serbet, pada sekeping kertas, dan sebagainya. Anda tidak boleh membawa papan putih percetakan 300 paun ke kafe tempatan.

Jadi apa yang berkesan

Jadi apa yang perlu dilakukan oleh ibu? Bagaimana anda menangkap artifak ini untuk mengarkibkannya di dalam komputer sehingga mereka akan membuat dokumentasi yang wajar seperti yang ada, tanpa perlu memindahkannya ke program menggambar?

Penyelesaian:

  1. Kamera digital
  2. Produk perisian yang luar biasa bernama Whiteboard Photo dari Pixid

Foto digital, malangnya, sering menghasilkan gambar yang tidak memuaskan untuk didokumentasikan. Sebagai ganti rugi, Papan Tulis Foto mengubah gambar digital menjadi sesuatu yang berguna. Gambar benar-benar bernilai seribu perkataan, di sini. Gambar 1 menunjukkan gambar digital khas papan putih.

Rajah 2 menggambarkan contoh lain.

Gambar 3 menunjukkan bagaimana Foto Papan Tulis mengubah Rajah 1.

Dan inilah cara Gambar 2 melihat Whiteboard Photo melakukan keajaibannya.

Seperti yang ditunjukkan oleh gambar, perbezaannya sangat mengagumkan. Untuk mengubah imej asal ke versi yang dibersihkan, saya tekan Ctrl-L. Perisian secara automatik menemui batas papan putih, diperbaiki untuk penyelewengan yang disebabkan oleh mengambil gambar dari sudut (perlu untuk mengelakkan silau dari lampu kilat), memilih garis reka bentuk, dan menariknya. Semua produk yang diperlukan untuk mencapai kesempurnaan adalah pengecaman tulisan tangan, tetapi saya berwarna merah jambu dengannya. Saya sekarang dapat menghasilkan gambar berkualiti dokumentasi terus dari papan putih asal, tanpa membuang masa memasukkan gambar menjadi alasan yang lemah bagi alat CASE.

Pastikan ia sederhana

Menurut pengalaman saya, berkaitan dengan reka bentuk OO, alat berteknologi rendah berfungsi dengan baik. Memang, mereka lebih pantas, lebih mudah digunakan, dan berkinerja baik dalam persekitaran kolaboratif. Setakat ini, saya dapati bahawa gabungan papan putih, kamera digital, dan Foto Papan Tulis menawarkan kaedah terbaik untuk memasukkan reka bentuk program ke dalam mesin.

Allen Holub menyediakan perkhidmatan perundingan, latihan, dan mentoring dalam reka bentuk OO, proses OO, dan pemrograman Java. Dia kerap mengadakan bengkel reka bentuk OO intensif untuk mereka yang berminat mengembangkan kemahiran OO mereka dengan cepat. (Cari lebih banyak maklumat di //www.holub.com.) Allen telah bekerja di industri komputer sejak tahun 1979, terakhir sebagai ketua pegawai teknologi di NetReliance, Inc. Dia banyak diterbitkan di majalah (Dr. Dobb's Journal, Programmers Journal, Byte, dan MSJ, antara lain). Allen mempunyai lapan buah buku, yang terbaru - Taming Java Threads (APpress, 2000; ISBN: 1893115100) - merangkumi perangkap dan perangkap Java threading. Dia mengajar reka bentuk OO dan Java untuk University of California, Berkeley Extension (sejak tahun 1982).

Ketahui lebih lanjut mengenai topik ini

  • Untuk alat reka bentuk ArgoUML sumber terbuka percuma, pergi ke

    //argouml.tigris.org/

  • Embarcadero's GDPro boleh didapati di

    //www.embarcadero.com

  • Anda akan mendapat lebih banyak maklumat mengenai TogetherSoft's Together ControlCenter di

    //www.togethersoft.com

  • Halaman utama Microsoft Visio

    //www.microsoft.com/office/visio/default.htm

  • Pergi ke halaman produk Foto Papan Tulis Pixid untuk maklumat lebih lanjut mengenai alat menarik ini

    //www.pixid.com/home.html

  • Laman web Allen Holub menampilkan halaman "Goodies" miliknya, di mana anda akan mendapat petua reka bentuk OO, peraturan pengaturcaraan, dan nota dari beberapa perbincangan Allen

    //www.holub.com/goodies/goodies.html

  • JavaWorld 's Object-Oriented Design dan Programming Indeks mempunyai banyak rencana menangani reka bentuk

    //www.javaworld.com/channel_content/jw-oop-index.shtml

  • Anda akan mencari ulasan produk yang lebih besar dalam JavaWorld 's Indeks produk Ulasan

    //www.javaworld.com/news-reviews/jw-nr-product-reviews.shtml

  • Baca lebih lanjut komentar dalam JavaWorld 's Indeks Commentary

    //www.javaworld.com/news-reviews/jw-nr-commentary.shtml

  • Untuk petua dan tutorial yang merangkumi corak reka bentuk, alat pengembangan, penyesuaian prestasi, keselamatan, pengujian, dan banyak lagi, daftarlah ke buletin Java Terapan kami

    //www.javaworld.com/subscribe

  • Ceritakan dalam perbincangan Teori & Amalan Pengaturcaraan kami

    //forums.idg.net/[email protected]@.ee6b806

  • Anda akan mendapat banyak artikel berkaitan IT dari penerbitan saudara kami di .net

Kisah ini, "Bila berkaitan dengan reka bentuk OO yang baik, tetap sederhana" pada asalnya diterbitkan oleh JavaWorld.