七、架構權衡分析法：ATAM（Architecture Tradeoff Analysis Method）
評價軟體架構的一種綜合全面的方法。這種方法不僅可以揭示出構架滿足特定質量目標的情況，而且（因為它認識到了構架決策會影響多個質量屬性）可以使我們更清楚地認識到質量目標之間的聯絡——即如何權衡諸多質量目標。
1、ATAM參與人員
評估小組、專案決策者、構架涉眾
2、ATAM的結果
ATAM評估將產生至少如下結果：一個簡潔的構架表述；表述清楚的業務目標；用場景集合捕獲的質量需求；構架決策到質量需求的對映；所確定的敏感點和權衡點集合；有風險決策和無風險決策；風險主題的集合。
3、ATAM的目標
分析多個質量屬性間的關係，屬性間可能存在衝突，需要權衡取捨。按照質量屬性需求，評價體系結構設計。
4、ATAM的階段
關係和準備：參與人員為評估小組負責人和主要的專案決策者，根據要求進行，大概需要幾周的時間。
評估：參與人員為評估小組和專案決策者，一般需要1周，還有2~3周的中斷時間。包括以下步驟：ATAM方法的表述；商業動機的表述；構架的表述；對構架方法進行分類；生成質量屬性效用樹；分析構架方法。
評估（繼續）：參與人員為評估小組、專案決策者以及涉眾，一般需要2天。包括以下步驟：集體討論並確定場景的優先順序；分析構架方法；結果的表述；
後續工作：參與人員為評估小組和評估客戶，一般需要一週。
八、DSSA(Domain Specific Software Architecture)特定領域軟體架構
    特定領域軟體架構師在一個特定應用領域為一組應用提供組織結構參考的標準軟體架構。實施DSSA的過程包括一系列基本活動，其中領域設計活動的主要目的是獲得DSSA，該活動參與人員中，領域專家的主要任務是提供關於領域中系統的需求規約和實現的知識。
    DSSA與軟體體系結構風格是從不同角度出發研究問題的兩種結果，前者從問題域出發，後者從解決域出發。

    DSSA只對某個領域進行專家知識的提取、儲存、組織，但可以同時使用多種軟體體系結構風格；而在某個軟體體系結構風格中進行專家知識組織時，可以將提取的公共結構和設計方法擴充套件到多個應用領域。

    DSSA通常選用一個或多個適合所研究的領域的體系結構風格，並設計一個該領域專用的體系結構分析設計工具。但該方法提取的專家知識只能應用於一個較小的範圍－－所在領域。一個領域的

    DSSA及其工具在另一個領域中是不適應的，或不可以重用的。

    體系結構風格避免設計到特定的應用領域或背景，所提取的知識比DSSA提取的知識應用範圍要廣。但在一個特定領域中，正是由於體系結構風格對領域知識、領域背景的忽略，使其在一個具體領域的開發中的作用並不比DSSA要大。

    DSSA與體系結構風格是互為補充的兩種技術。

九、常見演算法
1、對稱演算法：DES（Data Encryption Standard，資料加密標準）、IDEA（International Data Encryption Algorithm國際資料加密演算法）
2、不對稱演算法：RSA、ECC
3、雜湊函式（摘要演算法）：MD5（Message Digest 5）
4、數字簽名：RSA、ElGamal、Fiat-Shamir、DSS/DSA、橢圓曲線
5、數字水印：空域演算法、變換域演算法、壓縮域演算法、NEC演算法、生理模型演算法等
6、安全協議：Ipsec（跨越網路邊界的通訊）、Secure Socket Layer：SL協議（計算機之間的整個會話進行加密）、RGP（Pretty Good Privacy 電子郵件在Internet上的通訊安全）
十、資料備份
1. 完全備份，所需時間最長，但恢復時間最短，操作最方便可靠。
2. 差異備份，備份上一次的完全備份後發生變化的所有檔案。備份時間較長，佔用空間較多，恢復時間
較短。
3. 增量備份，上一次備份後，所有發生變化的檔案。備份時間較短，佔用空間較少，恢復時間較長。
4. 按需備份。有很好的選擇性。
十一、測試方法
1、恢復測試：檢測系統的容錯能力。
2、安全性測試：檢測系統的安全機制。
3、強度測試：系統在異常情況下的承受能力的測試，是檢測系統在極限狀態下執行，效能下降的幅度是都在允許的範圍內。
4、效能測試：檢測系統是否滿足系統設計方案說明書對效能的要求。
5、可靠性測試：平均失效間隔時間（mean time between failures）是否超過了規定的時限、因故障而停機時間MTTR（mean time to repairs）在一年中不應超過多少時間。
6、安裝測試：檢測在安裝過程中是否有誤、是否容易操作。
7、確認測試：α測試（開發階段）和β測試（實際使用階段）
十二、ABSD（Architecture Based Sofaware Development）基於軟體架構的設計
強調由商業、質量和功能需求的組合驅動軟體架構設計。強調採用視角和試圖來描述軟體架構，採用用例和質量屬性場景來描述需求。
十三、RUP軟體開發
RUP軟體開發生命週期是一個二維的軟體開發模型，其中有9個核心工作流，分別是：業務建模、需求、分析與設計、實現、測試部署、配置與變更管理、專案管理以及環境。
RUP把軟體開發生存週期劃分為多個迴圈，每個迴圈生成產品的一個新的版本，每個迴圈依次由4個連續的階段組成，每個階段完成確定的任務。這4個階段分別為：
1、初始階段：定義最終產品試圖和業務結構，並確定系統範圍；
2、細化階段：設計及確定系統的體系結構，制定工作計劃及資源要求；
3、構造階段：構造產品並繼續演進需求、體系結構、計劃直至產品提交；
4、移交階段：把產品提交各使用者使用。
十四、資料流圖和流程圖
資料流圖作為一種圖形化工具，用來說明業務處理過程、系統邊界內所包含的功能和系統中的資料流。
流程圖以圖形化的方式展示應用程式從資料輸入開始到獲得輸出為止的邏輯過程，描述處理過程的控制流。
兩者的區別：
1、資料流圖中的處理過程可並行；流程圖在某個時間點只能處於一個處理過程。
2、資料流圖展示系統的資料流；流程圖展示系統的控制流；
3、資料流圖展現全域性的處理過程，過程之間遵循不同是計時標準；流程圖中處理過程遵循一直的計時標準；
4、資料流圖適用於系統分析中的邏輯建模階段；流程圖適用於系統設計中的物理建模階段。

高質量資料流圖設計時考慮的三個原則：
1、複雜性最小化原則。DFD分層結構就是把資訊劃分為小的且相對獨立的一大批子集例子，這樣就可以單獨考察每一個DFD。如果要了解某個過程更加詳細的資訊，可以跳轉到該過程的下一層；如果要知道一個DFD如何與其他DFD相關聯，可以跳轉到上一層的DFD記性考查。
2、介面最小化原則。介面最小化是複雜性最小化的一種具體規則，在設計模型時，應使得模型中各個元素之間的介面數或連線數最小化。
3、資料流一致性原則。一個過程和它的過程分解在資料流內容中是否有差別？是否存在有資料流出但沒有相應的資料流入的加工？是否存在有資料流入但沒有相應的資料流出的加工？