軟件架構風格：
是指描述特定領域軟件的組織方式和慣用模式。
集成開發環境與用戶的交互方式、集成開發環境的擴展性、集成開發環境的數據管理闡述
組織方式：描述了系統組成構件和這些構件組織的方式
慣用模式：則反映了衆多系統共有的結構和語義
從集成開發環境與用戶交互方式看，用戶通常採用交互的方式對腳本進行編輯、解釋執行與調試。
在這種情況下，採用以數據存儲爲中心的軟件架構風格能夠很好地支持交互式數據處理，而管道-過濾器風格則對用戶的交互式數據處理支持有限。
從集成開發環境的擴展性來看，系統核心需求要求實現各種編輯、語法檢查、解釋執行等多種功能的靈活組織、配置與置換。
在這種情況下，採用以數據爲中心的架構風格、以數據格式解耦各種功能之間的依賴關係，並可以靈活定義功能之間的邏輯順序
管道-過濾器架構風格同樣以數據格式解耦數據處理過程之間的依賴關係，但其在數據處理邏輯關係的靈活定義方面較差。
從集成開發環境的數據管理來看，集成開發環境需要支持腳本語言、語法樹（用於檢查語法錯誤）、可視化模型、調試信息等多種
數據模型，並需要支持數據格式的轉換。
以數據存儲爲中心的架構將數據在統一的中心存儲器中，中心存儲器能夠表示多種數據格式，並能夠爲數據格式轉換提供各種支持。、
管道-過濾器架構風格通常只能支持有限度的數據格式並在數據格式轉換方面靈活性較差。
軟件架構設計的核心問題是能否使用重複的軟件架構模式，能否達到架構級別的軟件重用。
軟件架構風格：
描述某一特定應用領域中系統組織方式的慣用模式（Idiomatic paradigm）。
架構風格定義了一個系統家族，一個架構定義一個詞彙表和一組約束。
詞彙表中包含一些構件和連接件類型，組約束指出系統如何將這些構件和連接件組合起來。
架構風格反映了領域中衆多系統所共有的結構和語義特性，指導如何將各個模塊和子系統有效地組織成一個完整的系統。
按照這種方式理解，軟件架構風格定義了用於描述系統的術語表和一組指導構建系統的規則。
討論架構風格時要回答的問題是：
數據流風格
批處理的風格的每一步處理都是獨立的，並且每一步都是順序執行的，只有當前一步處理完，後一步處理才能開始。
數據傳輸在步與步之間作爲一個整體。（組件爲一些列固定順序的計算單元，組件間通過數據傳遞交互。每個處理步驟是一個獨立的程序，
每一步必須在前一步結束後才能開始）數據必須是完整的，以整體的方式傳遞
-----應用 1.經典數據處理，2.程序開發，3windows下的BAT程序就是這種應用的典型實例。
管道-過濾器
在管道-過濾器風格的軟件架構中，每個構件都有一組輸入和輸出，構件讀輸入的數據流，經過內部處理，然後產生輸出流。這個過程通常通過對輸入流的變換及增量計算來完成，
所以在輸入被完全消費之前，輸出便產生了。這裏的構件被稱爲過濾器，這種風格的連接件就像是數據流傳輸的管道，將一個過濾的輸出傳到另一個過濾器的輸入。
此風格的特別重要的過濾器必須是獨立
2）集成開發環境需要提供一組可視化的編程界面，用戶通過對界面元素拖拽和代碼填充的方式就可以完成功能插件核心業務流程的編寫與組織。
3）在代碼調試功能方面，集成開發環境需要實現在腳本語言編輯界面中的代碼自動定位功能。具體來說，早調試過程中，編輯界面需要想用調試斷點命中事件，並自動跳轉到當前斷點處所對應的代碼。
1.
面向對象架構風格的特徵是將數據表示和基本操作封裝在對象中。這種模式的構件是對象，對象維護自身表示的完整性，
對象之間通過消息機制進行通信，對象交互時需要知道彼此的標識，對象之間的協作完成計算過程。
控制環路架構風格是將過程輸出的指定屬性維護在一個特定的參考價值（設定點）。控制環路風格包括過程變量、被控變量、輸入變量、操縱變量、和設定點等構件。
通過收集實際和理想的過程狀態信息，並能調整過程變量使得實際狀態趨於理想狀態。
2.對於系統的增減速功能面採用面向對象風格的巡航控制系統首先會定義司機、油門、時鐘、速度和車輪等構件。
整個計算過程：
①司機進行增/減速操作設置期望速度，該期望速度以消息的形式傳遞給速度計。
②速度計通過向車輪和時鐘發送消息獲取消息獲取車輪轉速和時鐘值得到當前速度。
③速度計用來計算當前速度和期望速度的速度差值
④該差值以消息的形式發送給油門，油門通過速度差值調節自身狀態。
⑤整個過程在時鐘的控制下定期向速度計發送消息，重複執行2-4
控制環路的架構風格以控制器爲核心，期望速度，車輪脈衝、時鐘和油門等作爲構件
①司機進行增/減速操作設置期望速度值
②將設定值置爲期望速度值
③
④
⑤
需求跟蹤包括編制每個需求與系統元素之間的聯繫文檔，這些元素跟包括別的需求、體系結構、其他設計部件、
源代碼模塊、測試、幫助文件和文檔等、跟蹤能力信息使變更影響分析十分便利，有利於確認和
評估實現某個建議的需求變更所必須的工作。
利用需求跟蹤能力鏈，可以跟蹤一個需求使用的全過程，也就是從初始需求到實現的前後生存期。跟蹤能力是優秀需求規格說明書的一個特徵，
爲了實現跟蹤能力必須統一地表示出每一個需求，以便能明確地進行查閱。
客戶需求向前追溯到軟件需求。這樣就能區分開發過程中或者開發結束後，由於客戶需求變更受到影響的軟件需求，
這也就可以確保軟件需求規格說明包括了所有客戶需求。從軟件需求回溯到客戶需求。這也就是確認每個軟件需求的源頭，
如果使用實例的形式來描述客戶需求，那麼客戶需求與軟件需求之間的跟蹤情況就是使用實例和功能性需求。
從軟件需求向前追溯到下一集工作產品。由於開發過程中系統需求轉變爲軟件需求、設計、編碼等，
所以通過定義單個需求和特定的產品元素之間的（聯繫）鏈，可以從需求向前追溯到下一級工作產品、
這種聯繫鏈告訴我們每個需求對應的產品部件，從而確保產品部件滿足每個需求。
從產品部件追溯到軟件需求。說明了每個部件存在的原因。如果不能把設計元素，代碼段或測試回溯到一個需求，可能存在"多餘"
的程序，這些孤立的元素表明了一個正當的功能，則說明需求規格說明書漏掉了一項需求
客戶需求---------------->軟件需求----------->下一集工作產品
兩種常用的需求定義方法：嚴格定義方法和原型方法
嚴格定義方法（預先定義），需求的嚴格定義建立在以下基本假設之上：
1、所有需求都能夠背預先定義，這意味着在沒有實際系統運行經驗的情況下，全部的系統需求均可通過邏輯判斷得到。
但這種假設在許多場合是不能成立
2.開發人員在用戶之間能夠準去而清晰地交流
3.採用圖形（或文字）可以充分體現最終系統。在使用嚴格定義需求的開發過程中，開發人員與用戶之間交流與溝通的
主要工具是定義報告，包括文字、圖形、邏輯規則和數據字典等技術工具。
原型化的需求定義過程是一個開發人員與用戶通力合作的反覆過程。從一個能滿足用戶基本需求的原型系統開始，允許在
開發過程中提出更好的需求，根據用戶的需求不斷地對系統進行完善，它實質上是一種迭代的循環型的開發方式。
採用原型方法時的原則：
1.並非所有的需求都能在系統開發前被準去說明
2.項目干係人之間通常存在交流上的困難
3.需要實際的、可供用戶參與的系統模型
4.有合適的系統開發環境
5.反覆是完全需要和值得提倡的。需求一旦確定，就應該遵從嚴格定義的方法。
軟件需求工程是包括創建和維護軟件需求文檔鎖必須的一切活動的過程，可以分爲需求開發和需求管理兩大工作。
需求開發包括需求獲取、需求分析、編寫需求規格說明書（需求定義）和需求驗證4個階段。在需求開發階段需要確定軟件所期望的用戶類型，
獲取各種用戶類型的需求，瞭解實際的用戶任務和目標，以及這些任務所支持的業務需求。
需求管理是一個對系統需求變更、瞭解和控制的過程，通常包括定義需求基線、處理需求變更和需求跟蹤方面的工作。
需求管理強調：控制對需求基線的變動；保持項目計劃與需求的一致。控制單個需求和需求文檔的版本情況；
需求管理和聯繫鏈，或者管理單個需求和其他項目可交付產品之間的依賴關係。跟蹤基線中的需求狀態。
需求開發與需求管理是相輔相成的，需求開發是主線、目標；需求管理是支持、保障。
變更控制
可以定義變更請求的數據項
可以定義變更請求生存期的狀態轉換圖
可以加強狀態轉換圖，是經授權的用戶，僅能做出允許的狀態變更
記錄每一種狀態變更的數據，確認作出變更的人員
可以定義在提交新請求或請求狀態被更新後應自動通知的設計人員
可以根據需要生成標準的或定製的報告和圖標
過程能力成熟度模型()在軟件開發機構中廣泛用來知道軟件過程改進。該模型描述了軟件過程能力的5個成熟度級別，
每一級包含若干關鍵過程域（KPA）
CMM的第二級爲可重複級，它包括了6個關鍵過程域，分別是：需求管理，軟件項目計劃‘軟件項目跟蹤和監督
軟件分包合同管理、軟件質量保證和軟件配置管理。
需求管理的目標是微軟件需求建立一個基線，提供給軟件工程和管理使用：軟件計劃、產品和活動與軟件需求保持一致。
需求變更策略：
1.所有需求變更必須遵循變更控制過程
2.對於未獲得批准的變更，不應該做設計和實現工作
3.變更應該由項目變更控制委員會決定實現那些變更
4.項目風險承擔者應該能夠了解變更數據庫的內容
5.決不能從數據庫中刪除或者修改變更請求的原始文檔
6.每一個集成的需求變更能跟蹤到一個核準的變更請求。
需求管理：是一個對系統需求變更、瞭解和控制的過程。需求管理過程與需求開發過程相互關聯，當初始需求導出同時就啓動了
需求管理計劃，一旦形成了需求文檔的初稿，需求管理活動就開始了。
需求管理過程域內的原則和策略
1.需求管理的關鍵過程領域不涉及收集和分析項目需求，而是假定已收集了軟件需求，或者已由更高一級的系統給定了需求
2.開發人員在客戶以及有關部門承諾某些需求之前，應該確認需求和約束條件、風險、偶然因素、假定條件
3.關鍵處理領域建議通過版本控制和變更控制來管理需求文檔
軟件需求的基礎知識
1完整性、
每一項需求都必須完整地描述即將交付使用的功能
2.正確性
每一項需求都必須正確正確地描述將要開發的功能
3.可行性
需求必須能夠在系統及其運行環境的已知能力和約束條件內實現
4.必要性
每一項需求記錄的功能都必須使用戶的真正需要
5.無歧義
每一項需求聲明對所有讀者應該只有一種一致的解釋
6.可驗證性
如果某項需求不可驗證，那麼判定其實現的正確與否就成了主觀臆斷
--------------------------------------測試試題--------------------------------------
軟件集成測試將已通過單元測試模塊集成在一起，
組裝策略可分爲：一次性組裝和增量式組裝
集成測試計劃通常是在軟件概要設計階段完成，集成測試一般採用黑盒測試方法
軟件測試分類：單元測試、集成測試、配置項測試、系統測試、驗收測試、迴歸測試
單元測試（模塊測試），測試的對象是可獨立編譯或彙編的程序模塊、軟件構件或面向對象軟件中的類
（統稱爲模塊），目的是檢查每個模塊能否正確地事先設計說明中的功能、性能、接口和其他涉及約束等條件
發現模塊內可能存在各種差錯。
單元測試的技術依據是軟件詳細設計說明書。
集成測試的目的是檢查模塊之間，以及模塊和已集成的軟件之間的接口關係，並驗證已集成的軟件是否符合設計要求
集成測試的技術依據是軟件概要設計文檔
系統測試的對象是完整的，集成的計算機系統、系統測試的目標是在真實系統環境下，驗證完整的軟件配置項能否和系統
正確連接，並滿足系統/子系統設計文檔和軟件開發合同規定 的要求。
系統測試的技術依據是用戶需求和開發合同
配置項測試的對象是軟件配置項，配置項測試的目的是檢驗軟件配置項與軟件需求規格說明的一致性
驗收測試是針對軟件需求規格說明，在交付前以用戶爲主進行的測試。
迴歸測試的目的是測試軟件變更之後，變更部分的正確性和對變更需求的複合型，以及對軟件原有的、正確的功能、
性能和其他規定的要求的不損害性。
靜態測試方法知識點
靜態測試知識被測試測試程序不在機器上運行，而採用人工檢測和計算機輔助靜態分析手段對程序進行檢測。
靜態測試包括對文檔的靜態測試和對代碼的靜態測試。
對代碼的靜態測試包括：控制流分析，數據流分析，接口分析和表達式分析
1.控制流分析.控制流分析是指使用控制流程圖檢查，被測程序控制結構的過程。
例如，可檢查被測程序是否存在沒有使用的語句或子程序，是否待用並不存在的子程序，以及是否存在無法達到的語句等
2.數據流分析：數據流分析是指使用控制流程圖分析數據各種異常情況的過程。包括數據初始化，數值或引用過程中的異常、
3.接口分析：接口分析主要包括模塊之間接口的一致性分析、模塊與外部數據庫及其其他軟件配置之間的一致性分析、子程序和
函數之間的接口一致性分析。例如可以檢查函數形參與實現的數量、順序、類型使用的一致性。
4.表達式分析。表達式分析用於檢查程序代碼的表達式錯誤。例如括號不配對、數組引用越界、除數爲零、浮點數變量比較時誤差等錯誤。
軟件測試與調試之間的區別
軟件測試在將軟件交付給客戶之間所必須完成的重要步驟。軟件調試（排錯）與成功的測試形影相隨。
測試成功的標誌是發現錯誤，根據錯誤跡象確定錯誤的原因和準確位置，並加以改正，主要依靠軟件調試技術
軟件調試與軟件測試區別：
1.測試的目的是找出存在的錯誤，而調試的目的是定位錯誤修改程序以修正錯誤
2.調試是測試之後的活動，測試和調試在目標、方法和思路上都有所不同
3.測試從一個已知的條件開始，使用預先定義的過程，有預知的結果，調試從一個未知的條件開始，結束的過程不可預知。
4.測試過程可以實現設計，進度可以實現確定，而調試不能描述過程或持續時間。
單元測試的基本概念：
單元測試也是（模塊測試），測試對象是可獨立編程或彙編的程序模塊，軟件構件或面向對象軟件中的類（統稱爲模塊），
其目的是檢查每個模塊能否爭取地實現設計說明中的功能，性能，接口和其他設計約束等條件，發現模塊內存可能存在的各種差錯
單元測試的技術一居室軟件詳細設計說明書
測試一個模塊時，可能需要爲該模塊編寫一個驅動模塊和若干個模塊。
驅動模塊用來調用北側模塊，他接受測試者提供的測試數據，併發這些數據傳送給北側模塊，然後從被測模塊接收測試結果
並以某種可見的方式將測試結果返回給測試人員
樁模塊用模擬測試被測模塊所調用的子模塊，它接受北側模塊的調用，檢驗調用參數，並以町能簡單的操作模擬被調用的
子程序模塊功能，把結果送回被測模塊
頂層模塊測試時不需要驅動模塊，底層模塊測試時不要樁模塊。
單元測試策略主要包括自頂向下的單元測試，自底向上的單元測試、孤立測試和綜合測試策略。
1.自頂向下的單元測試先測試上層模塊，在測試下層模塊。測試下層模塊時由於它的上層模塊臆測試過，
所以不必另外編寫驅動模塊
2、自底向上的單元測試。自底向上的單元測試先測試下層模塊，在測試上層模塊。測試上層模塊由於它的下層模塊已經測試過了，所以不必另外編寫樁模塊
3、孤立測試不需要考慮每個模塊與其他模塊之間的關係，逐一完成所有模塊的測試由於各模塊之間不存在依賴性，單元測試可以並行進行，
但因爲需要爲每個模塊單獨設計驅動模塊和樁模塊，增加了額外的測試成本
4.綜合測試
上述三種測試策略各有利弊，實際測試時可以根據軟件特點和進度安排情況，將集中測試方法混合使用。
白盒測試:結構測試，主要用於軟件單元測試階段，測試人員按照程序內部邏輯結構設計測試用例，檢測程序中的主要執行通路
是否都能按預定要求正確訂做。百合測試方法主要有控制流測試，數據流測試和程序變異測試。
控制流測試根據程序的內部邏輯結構設計測試用例，常用的技術是邏輯覆蓋。主要的覆蓋標準語句覆蓋、判定覆蓋、條件覆蓋、條件/判定覆蓋、條件組合覆蓋、修正的條件/判定覆蓋和路徑覆蓋
語句覆蓋是指選擇足夠多的測試用例，使得運行這些測試用例時，被測試程序的每個語句至少執行一次。
判定覆蓋也稱爲分支覆蓋，它是指不僅每個語句至少執行一次，而且每個判定的每種可能的結果（分支）都至少執行一次。
條件覆蓋是指不僅每個語句至少執行一次，而且是判定表達式中的每個條件都取得各種可能的結果。
條件/判定覆蓋同時滿足判定覆蓋和條件覆蓋
它的含義是選取足夠的測試用例，使得判定表達式中每個條件的所有可能結果至少出現一次，而且每個判定本身所有可能結果也至少出現一次
條件組合覆蓋是指選取足夠的測試用例，使得每個判定表達式中條件結果的所有可能組合至少出現一次
修正的條件/判定覆蓋。需要足夠的測試用例來確定各個條件能夠影響到包含的判斷結果。
路徑覆蓋是指選取足夠的測試用例，使得程序的每條都可能執行到的路都至少經過一次（如果程序中有環路，
則要求每條環路路徑至少經過一次）
黑盒測試（功能測試）主要用於集成測試、確認測試和系統測試階段。黑盒測試根據軟件需求規格說明所規定的功能來設計用例，
一般包括功能呢個分析、等價類劃分、邊界值分析、判定表、因果圖、狀態圖、隨即測試、錯誤推斷和正交試驗
在設計測試用例是，等價類劃分是用得最多的一種黑盒測試方法。所謂等價類就是某個輸入域的集合，對每一個輸入條件確定若干
有效等價類和若干無效等價類，分別設計覆蓋有效等價類和無效等價類的測試用例。
無效等價類是用來測試非正常的輸入數據的，所以要爲每個無效等價類設計一個測試用例。
邊界值分析通過選擇等價類邊界作爲測試用例，不僅重視輸入條件邊界而且也必須考慮輸出域邊界。在實際測試工作中，
將等價類劃分方法和邊界值分析結合使用能有效地發現軟件中的錯誤
因果圖方法是從自然語言書寫的程序規格說明的描述中找出（輸入條件）因果（輸出或程序狀態的改變）可以通過因果圖轉換爲判定表
正交實驗設計方法，就是使用已經造好了的正交表格來安排試驗並進行數據分析的一種方法，目的是用最少的測試用例達到最高的測試覆蓋率
靜態分析包括五個階段：控制流分析階段找出並突出顯示那些帶有多重出口或入口的循環以及不可達的代碼段；數據使用分析
階段突出程序中變量的使用情況；
接口分析階段檢查子程序和過程聲明及他們使用的一致性；信息流分析階段找出輸入變量和輸出變量之間的依賴關係；路徑分析階段
找出程序中所有肯能的路徑並畫出再次路徑中執行的語句
確認測試：1.內部確認測試 2.α測試（用戶在開發環境下進行測試），β測試（用戶在實際使用的環境下進行測試）
3.待驗收測試。驗收測試是指針對軟件愛你需求規格說明書，在交付前以用戶爲主進行的測試。
測試對象的完整、集成的計算機系統。驗收測試的目的是，在真實的用戶工作環境下，檢驗軟件愛你係統是否滿足開發技術
合同或軟件需求規格說明書。驗收測試的結論是用戶確定是否接收該軟件的主要依據。
系統測試的目的是在真實系統工作環境下，驗證完整的軟件配置項能否和系統正確連接，並滿足系統/子系統設計文檔和軟件開發
合同規定要求。
系統測試的主要內容包括功能測試、健壯性測試、性能測試、用戶界面測試、安全性測試、安裝與反安裝測試。其中
性能測試包括負載測試、壓力測試、可靠性測試和併發測試。
系統測試根據系統方案說明書來設計測試用例，常見的系統測試主要由恢復測試、安全測試、壓力測試、性能測試
可靠性測試、可用性測試、可維護性測試和安裝測試
基準測試：運行一個標準程序對多種計算機系統進行檢驗，以比較和評價他們的性能。
確認測試稱爲有限性測試：軟件功能、性能及其它特性是否與用戶需體一致。分類：內部測試、Alpha、Beta和驗收測試
實際上Java IDL 即idl to java 編譯器就是一個ORB，可以用來在Java語言中定義，實現和訪問Corba對象，Java IDL支持的
是一個瞬間的Corba對象，即在對象服務器處理過程中有效。
實際上，Java IDL的ORB 是一個類庫而已，並不是一個完整的平臺軟件，但是它對Java IDL 應用系統和其他CORBA應用系統
之間提供了很好的底層通信支持實現了OMG定義的ORB基本功能。
--------------------------------------------------------系統運行與維護--------------------------------------------------------------------
1.改正性維護，爲了識別和糾正軟件錯誤，改正軟件性能上的缺陷、排除實施中的誤使用，應當進行的診斷和改正錯誤的國策和那個爲改正性維護。
2.適應性維護，在使用過程中，外部環境（新的硬軟件配置）、數據環境【數據庫、數據格式、數據輸入/輸出方法、數據存儲介質】可能發生變化。
爲使軟件適應這種變化而修改軟件的過程稱爲（軟硬件升級）
3.完善性維護：在軟件的使用過程中，用戶往往會對軟件提出新的功能與性能要求，爲了滿足這些要求，需要修改或再開發軟件，以擴充軟件功能，增強
軟件性能、改進加工效率、提高軟件的可維護性。
4.預防性維護。 指預先提高軟件的可維護性、可靠性等爲以後進一步改進軟件打下良好基礎。採用先進的軟件工程方法對需要維護的軟件或軟件中
的某一部分（重新）進行設計、編碼和測試。
---------------------------------------------------------信息化方面的基礎值---------------------------------------------------------------
ERP 是信息化三流:信息流，資金流，物流
ERP系統中，庫存管理（Inventory management） 模塊主要是對企業無聊的進、出、存、進行管理。
供應鏈中的信息流覆蓋了從供應商、製造商到分銷商、再到零售商等供應鏈中的所有環節，其信息流分爲需求信息流供應信息流
需求信息流【客戶訂單、生產計劃、採購合同】從需求方向供方流動時，便引發物流。
供應信息（入庫單、完工報告單、庫存記錄、可供銷售量和提貨發運單）同物料一起沿着供應鏈從供方向需方流動。