11.4 系統分析
需求確定之後需要對系統進行整體分析和設計。這包括系統功能的描述、對功能模組的劃分和對系統流程的分析。下面首先對系統功能進行描述。
11.4.1 系統功能模組劃分
模組分析是描述系統需求的乙個過程，需要將需求分析中的感性描述進行抽象，提取出要實現的功能，這是整個系統開發的乙個關鍵過程。分析的根本目的是在開發者和提出需求的人之間建立一種理解和溝通的機制。因此，這個網上訂購子系統的需求分析也應該由開發人員和使用者或者客戶一起完成。由於這裡的例子只用於幫助讀者學習系統開發的過程及方法，所以對於將要開發實現的網上訂購子系統實際上並沒有真正的使用者或客戶，在開發過程中假定筆者就是系統的使用者，並由此提出具體需求。需求分析的第一步是描述系統的功能，以此確定系統的功能需求。
根據以上的使用者操作需求，將系統劃分如下，並對其模組的劃分和功能進行描述。
使用者個人資訊的顯示
註冊使用者的類別顯示
註冊使用者的電子貨幣資訊顯示
註冊使用者的訂單顯示
註冊使用者的消費記錄顯示
註冊使用者的充值記錄顯示
使用者個人資訊的查詢
註冊使用者的訂單查詢
註冊使用者的消費查詢
註冊使用者的充值查詢
整個系統的模組結構如圖11.6所示。
圖11.6 系統模組結構圖
高內聚、底耦合
注意介面的設計
系統就是問題域，系統劃分過程就是對問題分解過程。
所以明確需求而且對問題域研究透才能劃分得好。
最大程度的減少耦合
按業務分類
根據團隊成員的實力分配任務
業務和功能距陣
一般是根據功能和應用來劃分，也有按技術層面來劃分的。
先根據需求劃分技術實現的不同層，然後在每個層上面根據功能來劃分。層與功能。
這個沒有標準，我覺得一般都是按使用軟體的部門，或者是軟體流程從組來分
一般是根據功能和應用來劃分，也有按技術層面來劃分的。
如果使用物件導向的方法，應該根據資料劃分模組，高內聚原則，乙個模組實現對一組相關資料的所有操作。先給資料分類，相關的資料分為一類，然後每個類別用乙個模組來處理。 （按功能，按資料）
實際設計中經常根據業務分類的劃分模組，比如客戶有很多個部門，每個部門用的功能放在乙個模組中，這樣設計的好處是容易理解，但資料一致性維護會有麻煩。（按角度）
專案的模組劃分(feature)
劃分讓測試來分還是讓開發來分，結果可能完全不一樣的。從測試角度更多地是從介面來劃分，從開發角度，更多地從功能性和函式來劃分。介面劃分和功能性劃分在一定程度上是矛盾的。乙個介面可能擁有很多功能，乙個功能或函式在很多地方都會用到。如果只從介面上考慮，可能會存在乙個介面上的功能太多而失去了模組劃分的意義。如果只從功能或函式上劃分，有可能會存在劃分太細或者介面上無法體現的情況。
從以上情況來看，存在2個問題：第
一、模組大小的問題；第
二、介面上是否體現有些功能。只要我們解決這兩個問題，那麼測試和開發對劃分的模組也就不存在著矛盾了。
模組劃分必須遵循以下原則：
一、以介面為基準樹狀結構
二、大小控制在10md左右，不得在3—15md以外。如果乙個模組少於3md，那麼可以合併；如果乙個模組大於15md，那麼必須再按功能細分。
三、補充隱藏性功能和函式
以上提到樹狀結構的模組劃分。模組劃分要逐步細分，部分模組會相互牽連。上級模組和下級模組肯定相牽連，其中任何乙個模組變動，所有相牽連的模組都要重新測試。
軟體模組劃分原理
在軟體高層設計中，如何分解模組是首要考慮的問題。目前業界公認模組劃分要按照 高內聚，低耦合 的原則來進行，那麼如何劃分才能滿足 高內聚，低耦合 呢？下面來對模組分解原理方面進行一些探索，有考慮不周和不成熟之處還請大家不吝指正。模組是按功能來分解的嗎？許多人可能有過經驗，面對一堆功能性需求，多個不同的...
如何劃分vlan
本次實驗的目標是為 pc1 pc3劃分為vlan2 pc2 pc4劃分為vlan3 使pc1能夠和pc3通訊但是不能和pc2 pc4通訊 pc2能和pc4通訊 但是不能和pc1 pc3通訊 1.如圖所示 為pc1到pc4分配同網段ip位址 然後進入sw1 system view進入系統檢視 vlan...
模組中層次劃分
設計良好的模組，應該是層次化的。例如，模組b擴充套件了模組a，同時被模組c擴充套件。這樣就形成了a b c三個層次。img 如圖模組的層次 如圖所示，層次之間有如下的關係 上層定義規則，下層定義細節 上層 下層也可稱為內層 外層 上層是抽象的，下層是具體的 越上層，越穩定 越少改變 越下層，越易變。...