建站
咨詢
售后
建站咨詢
新聞中心
本節(jié)和大家討論一下UML實踐中的現(xiàn)狀和一些建議，主要從五個角度來介紹，相信通過本節(jié)的學(xué)習(xí)你一定會有所感悟。下面就是具體介紹。
創(chuàng)新互聯(lián)建站堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都做網(wǎng)站、成都網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的景縣網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！
UML實踐中的現(xiàn)狀和一些建議
UML在國內(nèi)不少地方獲得了應(yīng)用。這應(yīng)該說是個好事，然而背后我們也看到，這種應(yīng)用大多屬于不夠冷靜的炒作和跟風(fēng)，UML在很多時候已經(jīng)變成了一種形式主義的東西。實際上，UML本身所倡導(dǎo)的主旨是很好的，它保證了程序員之間的交流語言，RUP之類的工具也保證了軟件開發(fā)過程的規(guī)范性，嚴格保證了先設(shè)計后開發(fā)，設(shè)計階段有翔實的規(guī)范化的文檔等。接下來，我們要看看目前的UML熱潮是怎么產(chǎn)生的？為什么會存在形式主義？以及RUP之類的工具究竟存在哪些問題。
UML實踐中第一個問題是目前幾乎所有的UML工具都非常不好用，不美觀、不直觀、更不方便，在項目中進行同步維護也很困難。很多項目中用UML基本上可歸于形式主義的范疇。事實上，UML本身是一種規(guī)范，而規(guī)范本身的目的在于更好的交流溝通和更快更好的設(shè)計質(zhì)量，事實上現(xiàn)在UML的發(fā)展已經(jīng)背離了這些更基本的宗旨。我崇尚簡單就是美，最傳統(tǒng)的流程圖每個人都能看懂（甚至不是程序員也可以），現(xiàn)在的UML呢？太多不夠體貼和人性化的東西了，過于抽象化和公式化。我想未來會有新的更輕量級的類似的東西取代落后、冗腫和封閉的UML。我個人崇尚簡單就是美……
UML實踐中第二個問題是目前程序員的普遍素質(zhì)不夠。UML本身基本是于面向?qū)ο蟮能浖O(shè)計思想的，沒有足夠優(yōu)良的OO設(shè)計能力，很難有真正需要UML類別設(shè)計工具去表達自己設(shè)計意圖的必要。這個觀點不算夸張，其實有的人OO理論很強，但真正在實踐中往往過度設(shè)計，或者設(shè)計本身極度不平衡，把項目開發(fā)改成了科研實驗和上機實驗。另外更多的一些人對自己的動手能力很信任，往往忽視設(shè)計環(huán)節(jié)，基本上項目的設(shè)計一直處于反復(fù)和動蕩中。這些程序員不給他們一段時間學(xué)習(xí)和實踐，是很難成為成熟的設(shè)計師的，在基本成熟之前，UML對他們將是一個形式化的東西，不會有很強的意義。Andrei曾經(jīng)說程序員要到35歲才會成熟，而代碼員可能20多歲就可以了。這句話里大概也有“設(shè)計本身是個很需要經(jīng)驗的工作”的意思。
UML實踐中第三個問題是少數(shù)社會層面的宣傳誤導(dǎo)。印度海歸派、外企員工、IT譯書作者和出版社、職業(yè)培訓(xùn)機構(gòu)等處于各自的經(jīng)驗、目的和原因，大部分人完全背離現(xiàn)實的盲目鼓吹UML，甚至幾乎片面的認為UML就是軟件工程。外企應(yīng)用UML其實也并不很成功，不過他們有成熟的培訓(xùn)體系，所以一定程度的彌補了UML過于晦澀的弱點，作為已經(jīng)掌握他們的外企員工有一些可能會比較片面的歡迎UML。而印度海歸派的目的就不用多說了，至于培訓(xùn)和譯書的人很多都學(xué)者成分大于實戰(zhàn)成分，他們需要鼓吹UML，不過早晚他們會發(fā)現(xiàn)更好的東西而放棄對UML的鼓吹。事實上，現(xiàn)在已經(jīng)有人開始考慮這樣作了。
UML實踐中第四個問題是少數(shù)程序員非常依賴自動代碼框架生成，而這其實根本不是UML的關(guān)鍵問題。他們?yōu)榱耸褂媚承┕ぞ呱傻囊稽c也不符合中國人閱讀習(xí)慣的代碼，情愿放棄其他的一切。對他們來說UML只是一個代碼生成工具而已，所以他們作的UML大都沒有多大價值，比較形式化。
UML實踐中第五個問題是項目資源的問題。國內(nèi)大多數(shù)項目實際可支配的資源非常有限，如果給其他外國公司的開發(fā)人員看無論開發(fā)周期還是資金人力都基本是荒唐可笑的。UML實際上應(yīng)該貫穿始終，而不是只在最初的設(shè)計階段，也應(yīng)該貫穿整個項目組，包括設(shè)計、管理、開發(fā)、測試所有的人都應(yīng)該應(yīng)用它。
我想一般的公司如果沒有極大的把握不用太迷信UML/RUP，其實某些基于輕量級項目并不需要RUP或UML?，F(xiàn)在正打算學(xué)習(xí)UML的同行們，也盡可以先放下它，將來一定會有更優(yōu)秀的技術(shù)取代它，現(xiàn)在不如多花點時間學(xué)習(xí)和實踐一下OO設(shè)計等更基礎(chǔ)的東西。其實僅僅熟悉一下工具軟件和交流范式，將來對你來說只是幾天到個把月的事情，不用那么在意。而對于那些現(xiàn)在已經(jīng)決定了UML實踐中的項目，要想獲得成功，我的建議如下：
第一，項目周期至少延長通常計劃的50%至100%。你必須跟所有人解釋說，只有這樣才能讓UML本身有意義，才能切實提高項目的設(shè)計質(zhì)量。
第二，在項目開始集中提供一段時間的UML開發(fā)培訓(xùn)。貫穿項目始終，都要經(jīng)常進行全方位面向?qū)ο笤O(shè)計思想的交流（當(dāng)然是結(jié)合UML的），力圖通過交流提高設(shè)計質(zhì)量。
第三，頂住客戶和公司領(lǐng)導(dǎo)方面的壓力，堅持把盡可能多的設(shè)計問題在最初的設(shè)計階段解決，而不要被迫匆匆完成形式主義的UML設(shè)計，然后把設(shè)計丟在一邊，開始編碼。
第四，妥善處理部分“精英”程序員的抵觸情緒。能疏導(dǎo)就疏導(dǎo)，不能疏導(dǎo)應(yīng)考慮壓服甚至將他徹底排除在項目組外。UML量級的團隊開發(fā)并不鼓勵個人英雄主義，不下狠心將根本沒機會推進下去。
第五，對項目的期望不要太高。無論是面對急于驗收向上級邀功的政府客戶，還是公司里不懂技術(shù)只懂蠻干的領(lǐng)導(dǎo)，都要保持低調(diào)，把它當(dāng)做一個并不見得立竿見影的實驗……
【編輯推薦】
- UML實踐----UML活動圖、順序圖、狀態(tài)圖、協(xié)作圖
- UML實踐--UML用例圖和類圖解析
- UML組成及其全稱解析
- 解析UML類圖符號意義
- 經(jīng)驗總結(jié) UML實踐指南
網(wǎng)站標題：經(jīng)驗總結(jié) UML實踐中的現(xiàn)狀和一些建議
網(wǎng)站路徑：http://www.5511xx.com/article/dpgedpp.html
