軟件的需求和設計文檔
軟件設計的總體思路
- 靈活性（Flexibility）
- 有效性（Efficiency）
- 可靠性（Reliability）
- 可理解性（Understandability）
- 維護性（Maintainability）
- 重用性（Reuse-ability）
- 適應性（Adaptability）
- 可移植性（Portability）
- 可追蹤性（Traceability）
- 互操作性（Interoperability）
通常來說，作為軟件項目，我們需要有這幾類文檔
- 需求說明文檔
- 功能設計文檔
- 系統架構說明書
- 模塊概要設計文檔
- 模塊詳細設計文檔
需求
需求的要點是從人開始。也就是從使用者的角度來看。而不是從實現的角度來看
需求文檔的輸入是用戶的述說，輸出給項目經理，項目經理，進行全面的評估，比如，查看范圍是否划的明確（這是最最重要的一點），能否實現，如果能實現，公司的資源，能否支撐，質量、進度、成本目標是否能夠達成？
然后下達給技術經理，進行設計。
如何寫需求
- 准備一下：寫寫前因后果，給系統起個名字，然后試圖划清邊界和規模。這個很難，但必須要做。
- 分清角色。
- 站在每個角色的視角，提出，有哪些需求。這一點，回顧一下上面的描述，就出來了，要站在人的角度，如果與人無關，就沒有需求，交給實現方就可以了。比如，用戶的需求，是把數據從A地傳到B地，我們可以選裝硬盤里用車拉過去，還是用TCP/IP協議傳過去，用戶是不在意的，這種情況，比如，“首先雇輛車，然后硬盤裝車，諸如此類的”，就不要寫了，這雖然也是與人打交道，但這人不是你的用戶；如果把TCP/IP協議棧當作人，自然更離題了。
- 然后是細化。每個動作的詳細的描述，包括：輸入（前置狀態或允許條件等），輸出，狀態的改變
————————————————
版權聲明：本文為CSDN博主「郝玉傑」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/haoyujie/java/article/details/80328862
需求說明需要明確以下幾點：
- 所需要開發的軟件系統邊界
- 系統所有的相關及使用人員角色
- 系統關鍵的使用場景
- 系統規模、性能要求以及部署方式等非功能性需求
設計文檔
是在需求明確的前提下，從設計的角度，來描述，如何實現的。
主要是層層分解。
每一層都要先描述出：
- 自己在上一層的位置
- 自己與同層的模塊或系統或子系統之半的關聯關系，這時，這些接口，已在上一層的接口描述中定義，只需要提一下即可。同層的模塊間的流程，也不要寫，因為在上層已寫過。
- 自己的內部構成，也就是模塊分解。每模塊功能簡要描述。
- 內部模塊間關聯關系和接口描述。
- 子系統的主要流程，主要說明每個流程，各內部子模塊之間的協作，主要是指信息流動，和各子系統的狀態變化。也就是輸入，動作，輸出。
————————————————
版權聲明：本文為CSDN博主「郝玉傑」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/haoyujie/java/article/details/80328862
內容大綱
層次結構,塊狀圖,交互圖
每一層（模塊）的責任，接口，，模塊分解
功能設計
功能設計與需求分析差不多同時在開展，在很多軟件項目中，對於功能設計不是特別重視。但對於某些軟件項目而言，這是一個相當重要的工作。對於主要是用戶界面的軟件項目來說，功能設計可以看作是畫出原型界面，描述使用場景，獲得用戶認可的過程。而對於沒有界面的軟件項目來說，則功能設計與需求分析的區分更為模糊。
參與的人員與需求分析的參與人員類似，架構師更側重於參與此類工作，並給與一些實現層面的判斷和取舍。
功能設計需要明確的核心是：
- 系統的行為
系統架構設計
系統架構設計是一個非常依賴於經驗的設計過程。需要根據軟件項目的特定功能需求和非功能性需求進行取舍，最終獲得一個滿足各方要求的系統架構。系統架構的不同，將很大程度上決定系統開發和維護是否能夠較為容易的適應需求變化，以及適應業務規模擴張。
架構設計工作中，用戶參與程度很低。軟件開發團隊中的需求人員參與程度很低，但團隊中的所有核心設計和開發人員都應該參與其中，並達成一致意見。
架構設計的主要成果，是將系統的不同視圖予以呈現，並使之落實到開發中：
- 系統開發視圖及技術路線選擇
- 系統邏輯視圖
- 系統部署視圖
- 系統模塊視圖
- 系統的領域模型
在軟件開發過程中，系統的架構不是一成不變的，隨着設計人員和開發人員對於系統的理解不斷深入，系統的架構也會發生演化。在軟件項目中，架構設計是開發團隊溝通的統一語言，設計文檔必須要隨着系統的變化進行更新，保障開發團隊對於系統的理解和溝通的一致性。
- 邏輯視圖（Logical View），設計的對象模型（使用面向對象的設計方法時）。
- 過程視圖（Process View），捕捉設計的並發和同步特征。
- 物理視圖（Physical View），描述了軟件到硬件的映射，反映了分布式特性。
- 開發視圖（Development View），描述了在開發環境中軟件的靜態組織結構。
邏輯結構
面向對象的分解
邏輯架構主要支持功能性需求――即在為用戶提供服務方面系統所應該提供的功能。系統分解為一系列的關鍵抽象，（大多數）來自於問題域，表現為對象或對象類的形式。它們采用抽象、封裝和繼承的原理。分解並不僅僅是為了功能分析，而且用來識別遍布系統各個部分的通用機制和設計元素。我們使用 Rational/Booch 方法來表示邏輯架構，借助於類圖和類模板的手段 4。類圖用來顯示一個類的集合和它們的邏輯關系：關聯、使用、組合、繼承等等。相似的類可以划分成類集合。類模板關注於單個類，它們強調主要的類操作，並且識別關鍵的對象特征。如果需要定義對象的內部行為，則使用狀態轉換圖或狀態圖來完成。公共機制或服務可以在類功能 （class utilities）中定義。對於數據驅動程度高的應用程序，可以使用其他形式的邏輯視圖，例如 E-R 圖，來代替面向對象的方法（OO approach）。
邏輯視圖的表示法
邏輯視圖的標記方法來自 Booch 標記法4。當僅考慮具有架構意義的條目時，這種表示法相當簡單。特別是在這種設計級別上，大量的修飾作用不大。我們使用 Rational Rose? 來支持邏輯架構的設計。
圖 2 － 邏輯藍圖的表示法
邏輯視圖的風格
邏輯視圖的風格采用面向對象的風格，其主要的設計准則是試圖在整個系統中保持單一的、一致的對象模型，避免就每個場合或過程產生草率的類和機制的技術說明。
邏輯結構藍圖的樣例
圖 3 顯示了 Télic PABX 架構中主要的類。
圖 3 － a. Télic PABX 的邏輯藍圖 b.空中交通系統的藍圖
PABX 建立終端間的通信連接。終端可以是電話設備、中繼線（例如，連接到中央辦公室）、連接線（PABX 專線到 PABX 線)、電話專線、數據線、ISDN 等等。不同的線路由不同的接口卡提供支持。線路 controller 對象的職責是在接口卡上對所有的信號進行解碼和注入，在特定於接口卡的信號與一致性的小型事件集合之間進行相互轉換：開始、停止、數字化等。controller 對象同時承載所有的實時約束。該類派生出許多子類以滿足不同的接口類型。terminal 對象的責任是維持終端的狀態，代表線路協調各項服務。例如，它使用 numbering plan 服務來解釋撥號。conversation 代表了會話中的一系列終端 。conversation 使用了Translation Service(目錄、邏輯物理映射、路由),以及建立終端之間語音路徑的Connection Service 。
對於一個包含了大量的具有架構重要意義的類的、更大的系統來說，圖 3 b 描述了空中交通管理系統的頂層類圖，包含 8 個類的種類（例如，類的分組）。
進程架構
過程分解
進程架構考慮一些非功能性的需求，如性能和可用性。它解決並發性、分布性、系統完整性、容錯性的問題，以及邏輯視圖的主要抽象如何與進程結構相配合在一起－即在哪個控制線程上，對象的操作被實際執行。
進程架構可以在幾種層次的抽象上進行描述，每個層次針對不同的問題。在最高的層次上，進程架構可以視為一組獨立執行的通信程序（叫作"processes"）的邏輯網絡，它們分布在整個一組硬件資源上，這些資源通過 LAN 或者 WAN 連接起來。多個邏輯網絡可能同時並存，共享相同的物理資源。例如，獨立的邏輯網絡可能用於支持離線系統與在線系統的分離，或者支持軟件的模擬版本和測試版本的共存。
進程是構成可執行單元任務的分組。進程代表了可以進行策略控制過程架構的層次（即：開始、恢復、重新配置及關閉）。另外，進程可以就處理負載的分布式增強或可用性的提高而不斷地被重復。
軟件被划分為一系列單獨的任務。任務是獨立的控制線程，可以在處理節點上單獨地被調度。
接着，我們可以區別主要任務、次要任務。主要任務是可以唯一處理的架構元素；次要任務是由於實施原因而引入的局部附加任務（周期性活動、緩沖、暫停等等）。它們可以作為 Ada Task 或輕量線程來實施。 主要任務的通訊途徑是良好定義的交互任務通信機制：基於消息的同步或異步通信服務、遠程過程調用、事件廣播等。次要任務則以會見或共享內存來通信。在同一過程或處理節點上，主要任務不應對它們的分配做出任何假定。
消息流、過程負載可以基於過程藍圖來進行評估，同樣可以使用啞負載來實現"中空"的進程架構，並測量在目標系統上的性能。正如 Filarey et al. 在他的 Eurocontrol 實驗中描述的那樣。
進程視圖的表示法
我們所使用的進程視圖的表示方法是從Booch最初為 Ada 任務推薦的表示方法擴展而來。同樣，用來所使用的表示法關注在架構上具有重要意義的元素。(圖 4)
圖 4 － 過程藍圖表示法
我們曾使用來自 TRW 的 Universal Network Architechure Services（UNAS0） 產品來構建並實施過程和任務集合（包擴它們的冗余），使它們融入過程的網絡中。UNAS 包含 Software Architect Lifecycle Environment(SALE)工具，它支持上述表示方法。SALE 允許以圖形的形式來描述進程架構，包括對可能的交互任務通信路徑的規格說明，正是從這些路徑中自動生成對應的 Ada 或 C++ 源代碼。使用該方法來指定和實施進程架構的優點是易於進行修改而不會對應用軟件造成太多的影響。
進程視圖的風格
許多風格可以適用於進程視圖。例如采用 Garlan 和 Shaw 的分類法1,我們可以得到管道和過濾器（Pipes and filters）,或客戶端/服務器，以及各種多個客戶端/單個服務器和多個客戶端/多個服務器的變體。對於更加復雜的系統,可以采用類似於 K.Birman 所描述的ISIS系統中進程組方法以及其它的標注方法和工具。
進程藍圖的例子
圖 5 － Télic PABX 的過程藍圖（部分）
所有的終端由單個的 Termal process 處理，其中 Termal process 由輸入隊列中的消息進行驅動。Controller 對象在組成控制過程三個任務之中的一項任務上執行：Low cycle rate task 掃描所有的非活動終端(200 ms)，將 High cycle rate task(10 ms)掃描清單中的終端激活，其中 High cycle rate task 檢測任何重要的狀態變化，將它們傳遞給 Main controller task，由它來對狀態的變更進行解釋,並通過向對應的終端發送消息來通信。這里 Controller 過程中的通信通過共享內存來實現。
開發架構
子系統分解
開發架構關注軟件開發環境下實際模塊的組織。軟件打包成小的程序塊（程序庫或子系統），它們可以由一位或幾位開發人員來開發。子系統可以組織成分層結構，每個層為上一層提供良好定義的接口。
系統的開發架構用模塊和子系統圖來表達，顯示了"輸出"和"輸入"關系。完整的開發架構只有當所有軟件元素被識別后才能加以描述。但是，可以列出控制開發架構的規則：分塊、分組和可見性。
大部分情況下，開發架構考慮的內部需求與以下幾項因素有關：開發難度、軟件管理、重用性和通用性及由工具集、編程語言所帶來的限制。開發架構視圖是各種活動的基礎，如：需求分配、團隊工作的分配（或團隊機構）、成本評估和計划、項目進度的監控、軟件重用性、移植性和安全性。它是建立產品線的基礎。
開發藍圖的表示方法
同樣，使用 Booch 方法的變形，僅考慮具有架構意義的項。
圖 5 － 開發藍圖表示方法
來自 Rational 的 Apex 開發環境支持開發架構的定義和實現、和前文描述的分層策略，以及設計規則的實施。Rational Rose 可以在模塊和子系統層次上繪制開發藍圖，並支持開發源代碼(Ada、C++）進程的正向和反向工程。
開發視圖的風格
我們推薦使用分層（layered）的風格，定義 4 到 6 個子系統層。每層均具有良好定義的職責。設計規則是某層子系統依賴同一層或低一層的子系統，從而最大程度地減少了具有復雜模塊依賴關系的網絡的開發量，得到層次式的簡單策略。
圖 6 － Hughes 空中交通系統（HATS）的 5 個層
開發架構的例子
圖 6 代表了加拿大的 Hughes Aircraft 開發的空中交通控制系統（Air Traffic Control system）產品線的 5 個分層開發組織結構。這是和圖 3 b 描述的邏輯架構相對應的開發架構。
第一層 和第二層組成了獨立於域的覆蓋整個產品線的分布式基礎設施，並保護其免受不同硬件平台、操作系統或市售產品（如數據庫管理系統）的影響。第三層為該基礎設施增加了 ATC 框架，形成一個特定領域的軟件架構（domain-specific software architecture）。使用該框架,可以在第四層上構建一個功能選擇板。層次 5 則非常依賴於客戶和產品,包含了大多數用戶接口和外部系統接口。72 個子系統分布於 5 個層次上，每層包含了 10 至 50 個模塊，並可以在其他藍圖上表示。
物理架構
軟件至硬件的映射
物理架構主要關注系統非功能性的需求，如可用性、可靠性（容錯性），性能（吞吐量）和可伸縮性。軟件在計算機網絡或處理節點上運行，被識別的各種元素（網絡、過程、任務和對象），需要被映射至不同的節點；我們希望使用不同的物理配置：一些用於開發和測試，另外一些則用於不同地點和不同客戶的部署。因此軟件至節點的映射需要高度的靈活性及對源代碼產生最小的影響。
物理藍圖的表示法
大型系統中的物理藍圖會變得非常混亂，所以它們可以采用多種形式，有或者沒有來自進程視圖的映射均可。
圖 7 － 物理藍圖的表示法
TRW 的 UNAS 提供了數據驅動方法將過程架構映射至物理架構，該方法允許大量的映射 的變更而無需修改源代碼。
物理藍圖的示例
圖 8 － PABX 的物理藍圖
圖 8 顯示了大型 PABX 可能的硬件配置,而圖 9 和圖 10 顯示了兩種不同物理架構上的進程映射，分別對應一個小型和一個大型 PABX。C、F 和 K 是三種不同容量的計算機，支持三種不同的運行要求。
圖 9 － 帶有過程分配的小型 PABX 物理架構
圖10－顯示了過程分配的大型PABX物理藍圖
場景
綜合所有的視圖
四種視圖的元素通過數量比較少的一組重要場景（更常見的是用例）進行無縫協同工作，我們為場景描述相應的腳本（對象之間和過程之間的交互序列）。正如 Rubin 和 Goldberg 所描述的那樣6。
在某種意義上場景是最重要的需求抽象，它們的設計使用對象場景圖和對象交互圖來表示4。
該視圖是其他視圖的冗余（因此"＋1"），但它起到了兩個作用：
- 作為一項驅動因素來發現架構設計過程中的架構元素，這一點將在下文中討論。
- 作為架構設計結束后的一項驗證和說明功能，既以視圖的角度來說明又作為架構原型測試的出發點。
場景的表示法
場景表示法與組件邏輯視圖非常相似（請對照圖 2），但它使用過程視圖的連接符來表示對象之間的交互（請對照圖 4），注意對象實例使用實線來表達。至於邏輯藍圖，我們使用 Rational Rose 來捕獲並管理對象場景。
場景的例子
圖 11 顯示了小型 PABX 的場景片段。相應的腳本是：
\1. Joe的電話控制器檢測和校驗摘機狀態的變換,並發送消息喚醒相應的終端對象。
\2. 終端分配一些資源，並要求控制器發出撥號音。
\3. 控制器接受撥號並傳遞給終端。
\4. 終端使用撥號方案來分析數字流。
\5. 有效的數字序列被鍵入,終端開始會話。
圖 11 － 本地呼叫的初期場景――階段選擇
視圖之間的對應性
各種視圖並不是完全是正交的或獨立的。視圖的元素根據某種設計規則和啟發式方法與其他視圖中的元素相關聯。
從邏輯視圖到過程視圖
我們發現邏輯視架構有幾項重要特性：
- 自主性：對象是主動的、被動的還是被保護的？
- 主動對象享有調用其他對象或其自身操作的主動權，並且當其他對象對其進行調用時，具有對其自身操作的完全控制權。
- 被動對象不能主動調用任何操作，對其他對象調用自身的操作沒有控制。
- 被保護對象不能主動調用任何操作。但對自身的操作有一定的控制功能。
- 持久化：對象是暫時的還是持久化的？它們是否會導致過程或處理器的終止？
- 依賴性：對象的存在或持久化是否依賴於另一個對象？
- 分布性：對象的狀態或操作是否能被物理架構中的許多節點所訪問？或是被進程架構中的幾個進程所訪問？
在邏輯視圖中，我們認為每個對象均是主動的，具有潛在的"並發性"，即與其他對象具有"平行的"行為，我們並不考慮所要達到的確切並發程度。因此，邏輯結構所考慮的僅是需求的功能性方面。
然而，當我們定義進程架構時，由於巨大的開銷，為每個對象實施各自的控制線程（例如，Unix 進程或 Ada 任務），在目前的技術狀況下是不現實的。此外，如果對象是並發的，那么必須以某種抽象形式來調用它們的操作。
另一方面，由於以下幾種原因需要多個控制線程。
- 為了快速響應某類外部觸發，包括與時間相關的事件。
- 為了在一個節點中利用多個 CPU，或者在一個分布式系統中利用多個節點。
- 為了提高 CPU 的利用率，在某些控制線程被掛起，等待其他活動結束的時候（例如，訪問外部對象其他活動對象時），為其他的活動分配 CPU。
- 為了划分活動的優先級（提高潛在的響應能力）。
- 為了支持系統的可伸縮性（借助於共享負載的其他過程）。
- 為了在軟件的不同領域分離關注點。
- 為了提高系統的可用性（通過 Backup 過程）。
我們同時使用兩種策略來決定並發的程度和定義所需的過程集合。考慮一系列潛在的物理目標架構。以下兩種形式我們可以任選其一：
-
從內至外:
由邏輯架構開始：定義代理任務，該任務將控制一個類的多個活動對象的單個線程進行多元化處理；同一代理任務還執行持久化處理那些依賴於一個主動對象的對象；需要相互進行操作的幾個類或僅需要少量處理的類共享單個代理。這種聚合會一直進行，直到我們將過程減少到合理的較少數量，而仍允許分布性和對物理資源的使用。
-
由外至內:
從物理結構開始：識別系統的外部觸發；定義處理觸發的客戶過程和僅提供服務（而非初始化它們）的服務器進程；使用數據完整性和問題的串行化（serialization）約束來定義正確的服務器設置，並且為客戶機與服務器代理分配對象；識別出必須分布哪些對象。
其結果是將類（和它們的對象）映射至一個任務集合和進程架構中的進程。通常，活動類具有代理任務，也存在一些變形：對於給定的類，使用多個代理以提高吞吐量，或者多個類映射至單個代理，因為它們的操作並不是頻繁地被調用，或者是為了保證執行序列。
注意這並不是產生最佳過程架構的線性的、決定性的進程；它需要若干個迭代來得到可接受的折衷。還存在許多其他方法，例如 Birman 等人5 或 Witt 等人7提出的方法。 確切的實施映射的方法不在本文的討論范圍，但我們以一個小的例子來說明一下。
圖 12 顯示了一個小的類集合如何從假想的空中交通控制系統映射至進程。
flight 類映射至一個 flight 代理集合：有許多航班等待處理，外部觸發的頻率很高，響應時間很關鍵，負載必須分布於多個 CPU。並且，航班處理的持久化和分布性方面都取決於 flight server，為了滿足可用性，還是使用 flight server 的一台備份服務器。
航班的 profile 和 clearance 總是從屬於某個航班,盡管它們是復雜的類,但它們共享 flight 類的進程。航班分布於若干其他進程，特別是對於顯示和外部接口。
sectorization 類，為 controller 的權限分配建立了空域划分。由於完整性約束，僅能被一個代理處理，但可以與 flight 類共享服務器過程：更新得並不頻繁。
location 和 arispace 及其他的靜態航空信息是受到保護的對象，在幾個類中共享，很少被更新；它們被映射至各自的服務器，分布於其他過程。
圖 12 － 從邏輯視圖到過程視圖的映射
從邏輯視圖到開發視圖
類通常作為一個模塊來實現，例如 Ada 包中可視部分的一個類型。密切相關的類（類的種類）的集合組合到子系統中。子系統的定義必須考慮額外的約束，如團隊組織、期望的代碼規模（通常每個子系統為 5 K 或 20 K SLOC）、可重用性和通用性的程度以及嚴格的分層依據（可視性問題），發布策略和配置管理。所以，通常最后得到的不是與邏輯視圖逐一對應的視圖。
邏輯視圖和開發視圖非常接近，但具有不同的關注點。我們發現項目規模越大，視圖間的差距也越大。例如，如果比較圖 3 b 和圖 6，則會發現並不存在逐一對應的類的不同種類到層的映射。而如果我們考慮類的種類的"外部接口"－網關種類時，它的實現遍布若干層：通訊協議在第 1 層或以下的層，通用網關機制在第 2 層，而特定的網關在第 5 層子系統。
從進程視圖到物理視圖
進程和進程組以不同的測試和部署配置映射至可用的物理硬件。Birman 在 ISIS 項目中描述了詳細的映射模式5。
場景主要以所使用類的形式與邏輯視圖相關聯；而與進程視圖的關聯則是考慮了一個或多個控制線程的、對象間的交互形式。
模型的剪裁
並不是所有的軟件架構都需要"4＋1"視圖。無用的視圖可以從架構描述中省略，比如： 只有一個處理器，則可以省略物理視圖；而如果僅有一個進程或程序，則可以省略過程視圖。 對於非常小型的系統，甚至可能邏輯視圖與開發視圖非常相似，而不需要分開的描述。場景對於所有的情況均適用。
迭代過程
Witt 等人為設計和架構指出了 4 個階段：勾畫草圖、組織、具體化和優化，分成了 12 個 步驟7。他們還指出需要某種程度的反向工程。而我們認為對於大型的項目，該方法太"線性 化"了。在 4 個階段的末尾，可用於驗證架構的內容太少。我們提倡一種更具有迭代性質的方法，即架構先被原形化、測試、估量、分析，然后在一系列的迭代過程中被細化。該方法除了減少與架構相關的風險之外，對於項目而言還有其他優點：團隊合作、培訓，加深對架構的理解，深入程序和工具等等（此處提及的是演進的原形，逐漸發展成為系統，而不是一次性的試驗性的原形）。這種迭代方法還能夠使需求被細化、成熟化並能夠被更好地理解。
場景驅動（scenario-driven）的方法
系統大多數關鍵的功能以場景（或 use cases）的形式被捕獲。關鍵意味着：最重要的功能，系統存在的理由，或使用頻率最高的功能，或體現了必須減輕的一些重要的技術風險。
開始階段:
- 基於風險和重要性為某次迭代選擇一些場景。場景可能被歸納為對若干用戶需求的抽象。
- 形成"稻草人式的架構"。然后對場景進行"描述"，以識別主要的抽象（類、機制、過程、子系統），如 Rubin 與 Goldberg6 所指出的 ―― 分解成為序列對（對象、操作）。
- 所發現的架構元素被分布到 4 個藍圖中：邏輯藍圖、進程藍圖、開發藍圖和物理藍圖。
- 然后實施、測試、度量該架構，這項分析可能檢測到一些缺點或潛在的增強要求。
- 捕獲經驗教訓。
循環階段:
下一個迭代過程開始進行：
- 重新評估風險，
- 擴展考慮的場景選擇板。
- 選擇能減輕風險或提高結構覆蓋的額外的少量場景，
然后:
- 試着在原先的架構中描述這些場景。
- 發現額外的架構元素，或有時還需要找出適應這些場景所需的重要架構變更。
- 更新4個主要視圖：邏輯視圖、進程視圖、開發視圖和物理視圖。
- 根據變更修訂現有的場景。
- 升級實現工具（架構原型）來支持新的、擴展了的場景集合。
- 測試。如果可能的話，在實際的目標環境和負載下進行測試。
- 然后評審這五個視圖來檢測簡潔性、可重用性和通用性的潛在問題。
- 更新設計准則和基本原理。
- 捕獲經驗教訓。
終止循環
為了實際的系統，初始的架構原型需要進行演進 。較好的情況是在經過 2 次或 3 次迭代之后，結構變得穩定：主要的抽象都已被找到。子系統和過程都已經完成，以及所有的接口都已經實現。接下來則是軟件設計的范疇，這個階段可能也會用到相似的方法和過程。
這些迭代過程的持續時間參差不齊，原因在於：所實施項目的規模，參與項目人員的數量、他們對本領域和方法的熟悉程度，以及該系統和開發組織的熟悉程度等等。因而較小的項目迭代過程可能持續 2-3 周（例如，10 K SLOC），而大型的項目可能為 6-9 個月（例如，700 K SLOC）。
架構的文檔化
架構設計中產生的文檔可以歸結為兩種：
-
軟件架構文檔，其結構遵循"4+1"視圖（請對照圖 13，一個典型的提綱）
-
軟件設計准則，捕獲了最重要的設計決策。這些決策必須被遵守，以保持系統架構的完整性。
圖 13 － 軟件架構文檔提綱
結束語
無論是否經過一次本地定制的和技術上的調整，"4＋1"視圖都能在許多大型項目中成功運用。事實上，它允許不同的"風險承擔人"找出他們就軟件架構所關心的問題。系統工程師首先接觸物理視圖，然后轉向進程視圖；最終用戶、顧客、數據分析專家從邏輯視圖入手；項目經理、軟件配置人員則從開發視圖來看待"4＋1"視圖。 在 Rational 和其他地方，提出並討論了其他系列視圖，例如 Meszaros(BNR)、Hofmeister。Nord 和 Soni(Siemenms)、Emery 和 Hilliard（Mitre），但我們發現其他視圖通常可以歸入我們所描述的 4 個視圖中的一個。例如 Cost&Schedule 視圖可以歸入開發視圖，將一個數據視圖歸入一個邏輯視圖，以及將一個執行視圖歸入進程視圖和物理視圖的組合。
表 1 － "4＋1"視圖模型一覽表
模塊/子系統概要設計
模塊/子系統的概要設計，由架構師參與，核心設計和開發人員負責的方式進行。
在概要設計工作中，我們需要在架構確定的開發路線的指導下，完成模塊功能實現的關鍵設計工作。在概要設計階段，需要關注於模塊的核心功能和難點進行設計。這個過程中更多推薦的采用UML來進行概要設計，需要進行：
- 模塊實現機制設計
- 模塊接口設計
- 關鍵類設計
- 畫出時序圖
- 交互圖等。
模塊詳細設計
在瀑布式開發模型中，模塊的詳細設計會要求比較嚴格，將所有類進行詳細設計。據我所知，除了一些對於系統健壯性要求非常嚴格的軟件項目，如國防項目，金融項目還要求有詳細設計文檔之外。其他的項目大多采用其他方式來處理這樣的工作，如自動化測試等。
綜上所述，軟件設計文檔作為軟件開發團隊的溝通、理解、知識共享的手段，具有非常重要的意義。而根據軟件團隊的規模，對於文檔上承載的信息詳細程度可以有不同程度的要求。我們軟件團隊對於如何使用設計文檔有一個統一的理解，並堅持更新設計文檔，這就是軟件設計的最佳實踐！
軟件設計所需要的知識與技能
- UML 統一建模語言
- 軟件工程
- 面向對象的編程 OOP
- 操作系統
- 數據庫原理
- 設計模式
- 溝通能力
論壇聊天
 |
4securityCoding 257 天前1.模塊圖 2.關鍵流程時序圖 3.接口文檔,導出 swagger json 文件,導入到 yapi 平台 4.排期 | |
|---|---|---|
ref
https://yq.aliyun.com/articles/9195
https://www.ibm.com/developerworks/cn/rational/r-4p1-view/index.html