青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

C++ Programmer's Cookbook

{C++ 基礎} {C++ 高級} {C#界面,C++核心算法} {設計模式} {C#基礎}

怎樣成為優秀的軟件模型設計者?(轉)

?
我們期待自己成為一個優秀的軟件模型設計者,但是,要怎樣做,又從哪里開始呢?

將下列原則應用到你的軟件工程中,你會獲得立桿見影的成果。

1. 人遠比技術重要

你開發軟件是為了供別人使用,沒有人使用的軟件只是沒有意義的數據的集合而已。許多在軟件方面很有成就的行家在他們事業的初期卻表現平平,因為他們那時侯將主要精力都集中在技術上。顯然,構件( components ), EJB Enterprise Java Beans )和代理( agent )是很有趣的東西。但是對于用戶來說,如果你設計的軟件很難使用或者不能滿足他們的需求,后臺用再好的技術也于事無補。多花點時間到軟件需求和設計一個使用戶能很容易理解的界面上。

2. 理解你要實現的東西

好的軟件設計人員把大多數時間花費在建立系統模型上,偶爾寫一些源代碼,但那只不過是為了驗證設計過程中所遇到的問題。這將使他們的設計方案更加可行。

3. 謙虛是必須的品格

你不可能知道一切,你甚至要很努力才能獲得足夠用的知識。軟件開發是一項復雜而艱巨的工作,因為軟件開發所用到的工具和技術是在不斷更新的。而且,一個人也不可能了解軟件開發的所有過程。在日常生活中你每天接觸到的新鮮事物可能不會太多。但是對于從事軟件開發的人來說,每天可以學習很多新東西(如果愿意的話)。

4. 需求就是需求

如果你沒有任何需求,你就不要動手開發任何軟件。成功的軟件取決于時間(在用戶要求的時間內完成)、預算和是否滿足用戶的需求。如果你不能確切知道用戶需要的是什么,或者軟件的需求定義,那么你的工程注定會失敗。

5. 需求其實很少改變,改變的是你對需求的理解

Object ToolSmiths 公司( www.objecttoolsmiths.com )的 Doug Smith 常喜歡說: 分析是一門科學,設計是一門藝術 。他的意思是說在眾多的 正確 分析模型中只存在一個最 正確 分析模型可以完全滿足解決某個具體問題的需要(我理解的意思是需求分析需要一絲不茍、精確的完成 , 而設計的時候反而可以發揮創造力和想象力 - 譯者注)。

如果需求經常改動,很可能是你沒有作好需求分析,并不是需求真的改變了。

你可以抱怨用戶不能告訴你他們想得到什么,但是不要忘記,收集需求信息是你工作。

你可以說是新來的開發人員把事情搞得一團糟,但是,你應該確定在工程的第一天就告訴他們應該做什么和怎樣去做。

如果你覺得公司不讓你與用戶充分接觸,那只能說明公司的管理層并不是真正支持你的項目。

你可以抱怨公司有關軟件工程的管理制度不合理,但你必須了解大多同行公司是怎么做的。

你可以借口說你們的競爭對手的成功是因為他們有了一個新的理念,但是為什么你沒先想到呢?

需求真正改變的情況很少,但是沒有做好需求分析工作的理由卻很多。

6. 經常閱讀

在這個每日都在發生變化的產業中,你不可能在已取得的成就上陶醉太久。

每個月至少讀 2 3 本專業雜志或者 1 本專業書籍。保持不落伍需要付出很多的時間和金錢,但會使你成為一個很有實力的競爭者。

7. 降低軟件模塊間的耦合度

高耦合度的系統是很難維護的。一處的修改引起另一處甚至更多處的變動。

你可以通過以下方法降低程序的耦合度:隱藏實現細節,強制構件接口定義,不使用公用數據結構,不讓應用程序直接操作數據庫(我的經驗法則是:當應用程序員在寫 SQL 代碼的時候,你的程序的耦合度就已經很高了)。

耦合度低的軟件可以很容易被重用、維護和擴充。

8. 提高軟件的內聚性

如果一個軟件的模塊只實現一個功能,那么該模塊具有高內聚性。高內聚性的軟件更容易維護和改進。

判斷一個模塊是否有高的內聚性,看一看你是否能夠用一個簡單的句子描述它的功能就行了。如果你用了一段話或者你需要使用類似 等連詞,則說明你需要將該模塊細化。

只有高內聚性的模塊才可能被重用。

9. 考慮軟件的移植性

移植是軟件開發中一項具體而又實際的工作,不要相信某些軟件工具的廣告宣傳(比如 java 的宣傳口號 write once run many ? 譯者注)。

即使僅僅對軟件進行常規升級,也要把這看得和向另一個操作系統或數據庫移植一樣重要。

記得從 16 Windows 移植到 32 windows 樂趣 ?當你使用了某個操作系統的特性,如它的進程間通信 (IPC) 策略,或用某數據庫專有語言寫了存儲過程。你的軟件和那個特定的產品結合度就已經很高了。

好的軟件設計者把那些特有的實現細節打包隱藏起來,所以,當那些特性該變的時候,你的僅僅需要更新那個包就可以了。

10. 接受變化

這是一句老話了:唯一不變的只有變化。

你應該將所有系統將可能發生的變化以及潛在需求記錄下來 , 以便將來能夠實現(參見 “Architecting for Change” Thinking Objectively, May 1999

通過在建模期間考慮這些假設的情況,你就有可能開發出足夠強壯且容易維護的軟件。設計強壯的軟件是你最基本的目標。

11. 不要低估對軟件規模的需求

Internet 帶給我們的最大的教訓是你必須在軟件開發的最初階段就考慮軟件規模的可擴充性。

今天只有 100 人的部門使用的應用程序,明天可能會被有好幾萬人的組織使用,下月,通過因特網可能會有幾百萬人使用它。

在軟件設計的初期,根據在用例模型中定義的必須支持的基本事務處理,確定軟件的基本功能。然后,在建造系統的時候再逐步加入比較常用的功能。

在設計的開始考慮軟件的規模需求,避免在用戶群突然增大的情況下,重寫軟件。

12. 性能僅僅是很多設計因素之一

關注軟件設計中的一個重要因素 -- 性能,這好象也是用戶最關心的事情。一個性能不佳的軟件將不可避免被重寫。

但是你的設計還必須具有可靠性,可用性,便攜性和可擴展性。你應該在工程開始就應該定義并區分好這些因素,以便在工作中恰當使用。性能可以是,也可以不是優先級最高的因素,我的觀點是,給每個設計因素應有的考慮。

13. 管理接口

“UML User Guide” Grady Booch Ivar Jacobson Jim Rumbaugh ,Addison Wesley, 1999 )中指出,你應該在開發階段的早期就定義軟件模塊之間的接口。

這有助于你的開發人員全面理解軟件的設計結構并取得一致意見,讓各模塊開發小組相對獨立的工作。一旦模塊的接口確定之后,模塊怎樣實現就不是很重要了。

從根本上說,如果你不能夠定義你的模塊 從外部看上去會是什么樣子 ,你肯定也不清楚模塊內要實現什么。

14. 走近路需要更長的時間

在軟件開發中沒有捷徑可以走。

縮短你的在需求分析上花的時間,結果只能是開發出來的軟件不能滿足用戶的需求,必須被重寫。

在軟件建模上每節省一周,在將來的編碼階段可能會多花幾周時間,因為你在全面思考之前就動手寫程序。

你為了節省一天的測試時間而漏掉了一個 bug ,在將來的維護階段,可能需要花幾周甚至幾個月的時間去修復。與其如此,還不如重新安排一下項目計劃。

避免走捷徑,只做一次但要做對( do it once by doing it right )。

15. 別信賴任何人

產品和服務銷售公司不是你的朋友,你的大部分員工和高層管理人員也不是。

大部分產品供應商希望把你牢牢綁在他們的產品上,可能是操作系統,數據庫或者某個開發工具。

大部分的顧問和承包商只關心你的錢并不是你的工程(停止向他們付款,看一看他們會在周圍呆多長時間)。

大部分程序員認為他們自己比其他人更優秀,他們可能拋棄你設計的模型而用自己認為更好的。

只有良好的溝通才能解決這些問題。

要明確的是,不要只依靠一家產品或服務提供商,即使你的公司(或組織)已經在建模、文檔和過程等方面向那個公司投入了很多錢。

16. 證明你的設計在實踐中可行

在設計的時候應當先建立一個技術原型, 或者稱為 端到端 原型。以證明你的設計是能夠工作的。

你應該在開發工作的早期做這些事情,因為,如果軟件的設計方案是不可行的,在編碼實現階段無論采取什么措施都于事無補。技術原型將證明你的設計的可行性,從而,你的設計將更容易獲得支持。

17. 應用已知的模式

目前,我們有大量現成的分析和設計模式以及問題的解決方案可以使用。

一般來說,好的模型設計和開發人員,都會避免重新設計已經成熟的并被廣泛應用的東西。
http://www.ambysoft.com/processPatternsPage.html
收藏了許多開發模式的信息。

18. 研究每個模型的長處和弱點

目前有很多種類的模型可以使用 , 如下圖所示。用例捕獲的是系統行為需求,數據模型則描述支持一個系統運行所需要的數據構成。你可能會試圖在用例中加入實際數據描述,但是,這對開發者不是非常有用。同樣,數據模型對描述軟件需求來說是無用的。每個模型在你建模過程中有其相應的位置,但是,你需要明白在什么地方,什么時候使用它們。

19. 在現有任務中應用多個模型

當你收集需求的時候,考慮使用用例模型,用戶界面模型和領域級的類模型。

當你設計軟件的時候,應該考慮制作類模型,順序圖、狀態圖、協作圖和最終的軟件實際物理模型。

程序設計人員應該慢慢意識到,僅僅使用一個模型而實現的軟件要么不能夠很好地滿足用戶的需求,要么很難擴展。

20. 教育你的聽眾

你花了很大力氣建立一個很成熟的系統模型,而你的聽眾卻不能理解它們,甚至更糟-連為什么要先建立模型都不知道。那么你的工作是毫無意義的。

教給你開發人員基本的建模知識;否則,他們會只看看你畫的漂亮圖表,然后繼續編寫不規范的程序。

另外, 你還需要告訴你的用戶一些需求建模的基礎知識。給他們解釋你的用例 (uses case) 和用戶界面模型,以使他們能夠明白你要表達地東西。當每個人都能使用一個通用的設計語言的時候(比如 UML- 譯者注),你的團隊才能實現真正的合作。

21. 帶工具的傻瓜還是傻瓜

你給我 CAD/CAM 工具,請我設計一座橋。但是,如果那座橋建成的話,我肯定不想當第一個從橋上過的人,因為我對建筑一竅不通。

使用一個很優秀的 CASE 工具并不能使你成為一個建模專家,只能使你成為一個優秀 CASE 工具的使用者。成為一個優秀的建模專家需要多年的積累,不會是一周針對某個價值幾千美元工具的培訓。一個優秀的 CASE 工具是很重要,但你必須學習使用它,并能夠使用它設計它支持的模型。

22. 理解完整的過程

好的設計人員應該理解整個軟件過程,盡管他們可能不是精通全部實現細節。

軟件開發是一個很復雜的過程,還記得《 object-oriented software process 》第 36 頁的內容嗎?除了編程、建模、測試等你擅長工作外,還有很多工作要做。

好的設計者需要考慮全局。必須從長遠考慮如何使軟件滿足用戶需要,如何提供維護和技術支持等。

23. 常做測試,早做測試

如果測試對你的軟件來說是無所謂的,那么你的軟件多半也沒什么必要被開發出來。

建立一個技術原型供技術評審使用,以檢驗你的軟件模型。

在軟件生命周期中,越晚發現的錯誤越難修改,修改成本越昂貴。盡可能早的做測試是很值得的。

24. 把你的工作歸檔

不值得歸檔的工作往往也不值得做。歸檔你的設想,以及根據設想做出的決定;歸檔軟件模型中很重要但不很明顯的部分。 給每個模型一些概要描述以使別人很快明白模型所表達的內容。

25. 技術會變,基本原理不會

如果有人說 使用某種開發語言、某個工具或某某技術,我們就不需要再做需求分析,建模,編碼或測試 。不要相信,這只說明他還缺乏經驗。拋開技術和人的因素,實際上軟件開發的基本原理自 20 世紀 70 年代以來就沒有改變過。你必須還定義需求,建模,編碼,測試,配置,面對風險,發布產品,管理工作人員等等。

軟件建模技術是需要多年的實際工作才能完全掌握的。好在你可以從我的建議開始,完善你們自己的軟件開發經驗。

以雞湯開始,加入自己的蔬菜。然后,開始享受你自己的豐盛晚餐吧。

posted on 2006-05-09 08:50 夢在天涯 閱讀(678) 評論(0)  編輯 收藏 引用 所屬分類: software engine

公告

EMail:itech001#126.com

導航

統計

  • 隨筆 - 461
  • 文章 - 4
  • 評論 - 746
  • 引用 - 0

常用鏈接

隨筆分類

隨筆檔案

收藏夾

Blogs

c#(csharp)

C++(cpp)

Enlish

Forums(bbs)

My self

Often go

Useful Webs

Xml/Uml/html

搜索

  •  

積分與排名

  • 積分 - 1812196
  • 排名 - 5

最新評論

閱讀排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
      <noscript id="pjuwb"></noscript>
            <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
              <dd id="pjuwb"></dd>
              <abbr id="pjuwb"></abbr>
              欧美成人蜜桃| 香蕉免费一区二区三区在线观看| 亚洲专区国产精品| 国产精品日韩在线播放| 日韩网站在线| 午夜在线一区| 一区二区三区在线观看视频| 欧美丰满少妇xxxbbb| 欧美福利在线观看| 亚洲欧美另类国产| 久久久久综合网| 一二三四社区欧美黄| 午夜精品免费在线| 亚洲区第一页| 亚洲尤物精选| 亚洲国产精品va在看黑人| 99v久久综合狠狠综合久久| 国产精品卡一卡二| 欧美成人a视频| 国产精品国产三级国产专播精品人| 久久国产主播| 欧美日韩综合在线| 久久最新视频| 国产精品日韩一区二区| 亚洲高清成人| 国产一区二区黄| 中国日韩欧美久久久久久久久| 国产一区二区电影在线观看| 99av国产精品欲麻豆| 在线播放亚洲一区| 亚洲一区二区在线看| 亚洲精品国产精品久久清纯直播| 亚洲主播在线播放| 一区二区日韩免费看| 老牛国产精品一区的观看方式| 亚洲欧美久久久| 欧美第一黄色网| 久久亚洲欧洲| 国产日韩av在线播放| 日韩性生活视频| 亚洲欧洲午夜| 久久亚洲高清| 老司机凹凸av亚洲导航| 国产精品亚洲综合久久| 亚洲最新在线| 99re66热这里只有精品4| 久久嫩草精品久久久久| 久久久精品久久久久| 国产精品久久久久久久久久久久久久| 欧美福利一区| 在线欧美亚洲| 久久久久久一区二区| 久久亚洲精品伦理| 国产综合久久| 久久精品女人的天堂av| 久久精品国产清高在天天线| 国产毛片久久| 欧美一区二区三区免费看| 久久国产天堂福利天堂| 国产日本欧美在线观看| 欧美一区二区精品久久911| 久久精品国产精品亚洲精品| 国产日韩免费| 久久国内精品视频| 久久综合伊人77777蜜臀| 一区二区在线视频| 久久人人超碰| 亚洲国产精品热久久| 亚洲欧洲综合另类在线| 欧美日韩第一区| 一区二区三区欧美日韩| 欧美巨乳在线| 久久久水蜜桃av免费网站| 国产精品专区第二| 久久99伊人| 免费不卡在线观看| 最近中文字幕mv在线一区二区三区四区 | 亚洲视频一二区| 亚洲尤物在线视频观看| 国产精品一区二区视频 | 亚洲精品一区二区三区av| 一本久道久久综合婷婷鲸鱼| 国产精品videosex极品| 欧美一区在线看| 亚洲国产黄色片| 中文欧美在线视频| 国产一级精品aaaaa看| 蜜臀久久99精品久久久久久9 | 99国内精品久久| 亚洲一卡二卡三卡四卡五卡| 国产手机视频一区二区| 久久夜色精品国产| 一本大道久久a久久精品综合| 亚洲欧美日韩在线综合| 亚洲国产精品精华液2区45| 国产精品theporn88| 久久久99精品免费观看不卡| 亚洲精品永久免费| 六月丁香综合| 亚洲制服少妇| 亚洲三级免费| 国产日韩一区二区| 欧美精品在线视频| 久久免费午夜影院| 亚洲影视在线| 日韩午夜免费| 欧美高清在线视频观看不卡| 欧美一区二区视频在线观看2020| 亚洲国产美女精品久久久久∴| 国产精品欧美日韩| 欧美日韩1080p| 久久婷婷色综合| 香蕉乱码成人久久天堂爱免费| 亚洲精品一品区二品区三品区| 久久久午夜电影| 亚洲欧美在线磁力| 亚洲无限av看| 亚洲第一在线| 一区一区视频| 国产一区二区无遮挡| 欧美午夜一区二区三区免费大片 | 蜜桃av一区二区三区| 性感少妇一区| 小嫩嫩精品导航| 亚洲香蕉网站| 中国成人在线视频| 日韩午夜在线电影| 亚洲精品中文字幕有码专区| 亚洲第一偷拍| 欧美成人三级在线| 欧美v亚洲v综合ⅴ国产v| 久久久久国产精品一区三寸| 欧美一区二区三区在线| 亚洲欧美日韩电影| 午夜宅男久久久| 午夜精品一区二区三区在线视| 亚洲一区二区三区免费在线观看| 亚洲美女视频在线观看| 理论片一区二区在线| 午夜精品久久久99热福利| 亚洲线精品一区二区三区八戒| 在线综合亚洲| 亚洲一区二区三区成人在线视频精品| 99在线精品视频| 一区二区三欧美| 亚洲伊人一本大道中文字幕| 亚洲欧美日韩精品久久| 欧美一级视频| 开心色5月久久精品| 亚洲成人在线网站| 一区二区日韩欧美| 夜夜精品视频| 亚洲欧美日韩精品| 亚洲精品人人| 亚洲日本国产| 在线视频亚洲一区| 久久国产福利| 欧美风情在线观看| 欧美激情视频一区二区三区免费| 美女爽到呻吟久久久久| 亚洲电影在线看| 一本综合精品| 久久国产夜色精品鲁鲁99| 免费高清在线视频一区·| 欧美日韩八区| 国产日韩欧美在线播放不卡| 精品盗摄一区二区三区| 亚洲另类视频| 亚洲欧美在线一区| 欧美www视频| 一区二区三区www| 久久精品国产69国产精品亚洲| 狂野欧美激情性xxxx| 欧美日韩一本到| 国产专区综合网| 亚洲深夜福利| 免费在线看一区| 亚洲天堂成人| 欧美sm重口味系列视频在线观看| 欧美日韩在线直播| 加勒比av一区二区| 亚洲综合国产| 亚洲第一区色| 午夜精品久久久久久久久| 欧美激情亚洲另类| 黄色国产精品| 亚洲专区一区| 亚洲国产欧美一区| 欧美一区二区三区在线免费观看| 欧美激情第4页| 国产真实久久| 性做久久久久久久久| 亚洲人成精品久久久久| 久久青草欧美一区二区三区| 国产精品日本| 亚洲女性裸体视频| 亚洲三级影片| 欧美成年人视频| 亚洲盗摄视频| 久久一区二区三区四区|