設計實踐
1.迭代
打你你在備選的設計方案之中迴圈並且嘗試一些不同的做法時，你將同時從高層和低層的不同視角去審視問題。你從高層視角中得到的大範圍途徑會有助於你把相關的低層細節納入考慮。你從低層視角中所獲得的細節也會為你的高層決策奠定基礎。這種高低層面之間的互動被認為是一種良性的原動力，它所建立的結構要遠遠穩定與單純自上而下或自下而上建立的結構。
當你首次嘗試得出了乙個看上去足夠好的設計方案後，請不要停下來！第二個嘗試幾乎肯定會好於第乙個，而你也會從每次的嘗試中都有所收穫，這有助於改善整體設計。
2.分而治之
沒有人的頭腦能夠裝得下乙個複雜程式的全部細節，這對設計也同樣有效。把程式分解為不同的關注區域，然後分別處理每乙個區域。如果你在某個區域裡碰到了死胡同，那麼就跌代。
增量式地改進是一種管理複雜度的強大工具。正如 polya 在數學問題求解中所建議的那樣——理解問題、形成計畫、執行計畫，然後再回顧你的做法。
3. 自上而下和自下而上的設計方法
自上而下的設計從某個很高的抽象層次開始。你定義出基類或者其他不怎麼特殊的設計元素。在開發這一設計的過程中，你逐漸增加細節的層次，找出派生類、合作類以及其他更細節的設計元素。自下而上的設計始於細節，向一般延伸。這種設計通常是從尋找具體物件開始，最後從細節之中生成物件以及基類。
4. 建立試驗性原則
有些時候，除非你更好地了解了一些實現細節，否則很難判斷一種設計方法是否奏效。比如說，在知道它能滿足效能需求之前，你很難判斷某種資料庫的組織結構是否適用。在選定系統使用的圖形介面（gui）程式之前，你也很可能判斷不出某一特定子系統的設計是否到位。這些都是軟體設計中本質性「險惡」的例子——除非你部分的解決了某一設計問題，否則你無法完整地定義出該設計問題。
有一種技術能夠低成本地解決這個問題，那就是建立試驗性原型。「建立原型」一詞對不同人來說具有不同的含義。在這裡，建立原型指的是「寫出用於回答特定設計問題的、量最少且能夠隨時扔掉的**」。
如果開發人員沒有把握住用最少**回答圖問題的原則，那麼原型方法的功效可能就會大打折扣。假如說，設計問題是「我們選定的資料庫框架能否支撐所需的交易量？」你不需要為了這一問題而編寫任何產品**，你也不需要去了解資料庫的詳情。你只需要了解能估計出問題範圍的最少資訊——有多少張表、表中有多少條記錄，等等。接下來你就可以用table1、table2、column1、column2等名字寫出最簡單的原型**，往表裡隨意填入些資料，然後做你所需要的效能測試。
當有關設計的問題不夠特殊的時候，原型同樣也會失效。諸如「這樣的資料庫框架能否工作？」的設計問題並沒有為建議原型提供多少指導。而像「這個資料庫框架能不能在x、y和z的前提下支援每秒1000次交易？」這樣的問題則能為建立原型提供更堅實的基礎。
最後乙個可能會給原型帶來風險的做法是，開發人員不把原型**當做可拋棄的**。我發現，如果開發人員相信某段**將被 用在最終產品裡，那麼他根本不可能寫出最少數量的**來。這樣做做種其實是在實現整個系統，而不是在開發原型。相反，如果你建立了這樣的概念，那就是一旦回答了所提出的問題，這段**就可以被扔掉，那麼你就可以把上述風險減到最小。避免產生這一問題的一種做法就是用於產品**不同的技術來開發原型。你可以用python來為j**a設計做原型，或者用 office ppt 來模擬使用者介面。如果你必須要用同一種技術來開發原型，那麼可採納乙個非常實用的標準：在原型中的類或者包的名稱之前加上 prototype 字首。這樣至少能保證程式設計師在試圖拓展原型**之前能夠三思。
一旦依照上述原則加以應用，那麼原型就會成為設計者手中用來出庫險惡設計問題的有力工具。如果不遵照上述原則，那麼原型就會給設計再平添許多風險。
5. 合作設計
在設計過程中，三個臭皮匠頂得上乙個諸葛亮，而不論組織形成的正式與否。合作可以以下面的任意一種方式展開。
6. 要做多少設計才夠
有些時候,編碼之前只制定出系統架構的乙個最小梗概.而在另一些時候,開發團隊會把設計做的非常詳細,是編碼變成了一種近乎機械的工作。
如果設計層次的問題是留給程式設計師個人去解決的話，那麼，當設計下降到你曾經完成過的某項任務的層次，或者變成了對這樣一想任務的簡單修改或者擴充的時候，你很可能就會停止設計而馬上開始編碼。
如果在編碼之前我還判斷不了應該再做多深的設計，那麼我寧願去做更詳細的設計。最大的設計失誤來自於我誤認為自己已經做得很充分，可時候卻發現還是做得不夠，沒能發現其他一些設計挑戰。換句話說，最大的設計問題通常不是來自於那些我認為是很困難的，並且在其中做出了不好的設計的區域；而是來自於那些我認為很簡單的，而沒有做出任何設計的區域。我幾乎沒有遇到過因為做了太多設計而受損傷的專案。
另一方面，我偶爾會看到一些專案因太過於專注對設計進行文件化而導致失敗。gresham 法則是這樣說的，「程式化的活動容易把非程式化的活動驅逐出去」。過早的去潤色設計方案就是這一法則所描述的例子。我寧願看到有80%的設計精力用於建立和探索大量的備選設計方案，而20%的精力用於建立並不很精美的文件，也不願看到把20%的精力花在建立平庸的設計方案上，而把80%的精力用於對不兩個設計進行拋光潤色。
7. 記錄你的設計成果
傳統的記錄設計成果的方法是把它寫成正式的設計文件。然而，你還可以用很多種方法來記錄這一成果，而這些方法對於那些小型的、非正式的專案或者只需要輕量級的記錄設計成果的方式的專案而言效果都很不錯。
8. 對流行的設計方法的評價
你怎樣擦能判斷出需要多少設計才夠呢？這是乙個主觀判斷，沒有人能完美地回答它。不過，在你沒有足夠的信心去判斷最佳設計量的時候，請記住有兩種情況一定是不對的：設計所有細節和不做任何設計。這兩個由位於立場兩端的極端主義者所倡導的做法，恰恰被證明是僅有的兩個永遠是錯誤的做法。
正如 p.j. plauger所言，「你在應用某種設計方法時越教條化，你所能解決的現實問題就會越少」。請把設計看成是乙個險惡的、雜亂的和啟發式的過程。不要停留於你所想到的第一套解決方案，而是去尋求合作，探索簡潔性，在需要的時候做出原型，迭代，並進一步迭代。你將對自己的設計成果感到滿意。
《軟體構架實踐》閱讀筆記05
系統的構架取決於對構架的需求，因此構架的文件也取決於對文件的需求 也就是說，我們希望如何使用該文件。構架文件不僅是說明性的，而且是描述性的，也就是說，對於某些觀眾來說，它通過對要指定的決策做出限制，來說明哪些內容是真實的。我們需要對檢視進行編檔 對行為進行編檔 對介面進行編檔 對介面進行編檔的模板。...
《軟體需求最佳實踐》閱讀筆記05
軟體需求最佳實踐 閱讀筆記05 軟體需求定義為 業務知識 問題列表 其他因素。需求的三個層次劃分為 業務需求 使用者需求 軟體需求。這種劃分很大程度上體現了需求工作的不同階段。1.業務需求是反映企業 組織對軟體系統的高層次目標要求，換句話說，就是軟體系統的建設目標，而這種目標通常體現在兩個方面 問題...
PowerDesigner設計實踐
一 資料模型 1 概念資料模型 cdm 1 cdm表現資料庫的全部邏輯的結構,與任何的軟體或資料儲藏結構無關。乙個概念模型經常包括在物理資料庫中仍然不實現的資料物件。它給執行計畫或業務活動的資料乙個正式表現方式。不考慮物理實現細節，只考慮實體之間的關係。2 概念資料模型的內容包括重要的實體及實體之間...