軟件設計和軟件工程

        任何事情都要先想清楚了才能作，軟件開發更是如此！軟件開發過程不可能一上來就開始盲目寫代碼，寫代碼以前必須搞清楚下面一些基本問題：
        · 要作什麼？
        · 作成什麼樣？
        · 怎麼去作？
        軟件設計: 把軟件開發想清楚的過程。
        軟件工程: 對軟件開發全過程進行建模和管理。 

1、模型與建模

        • 模型: 對問題的書面上的無歧義文字或圖形的描述.簡言之, 模型是對現實的簡化. 經過模型, 人們能夠了解所研究事物的本質。

        • 最傑出的模型: 地圖

        

        • 建模: 對現實系統進行適當的過濾, 用適當的表現規則描述出簡潔的模型。

        • 建模是一種深刻解決問題的方法。

        1.1 建模的原則

        (1) 選擇創建什麼樣的模型對如何發現和解決問題具備重要的影響。正確的模型有助於提升開發者的洞察力。

                

        (2) 每一個模型能夠有多種表達方式. 使用者的身份和使用的緣由是評判模型好壞的關鍵。
        (3) 最好的模型老是可以切合實際. 模型是現實的簡化，必須保證簡化過程不會掩蓋任何重要的細節。
        (4) 孤立的模型是不完整的。

        

 

        1.2 軟件建模的實現過程

        · 軟件建模的做用是把來源於現實世界的問題轉化爲計算機能夠理解和實現的問題。

        

        · 軟件建模的實現過程是從需求入手, 用模型表達分析設計過程, 最終將模型映射成軟件實現。

        

        1.3 United Modeling Language 統一建模語言

        · UML(United Modeling Language, 統一建模語言): 是一種基於面向對象的可視化建模語言.
        · UML 採用了一組形象化的圖形(如類圖)符號做爲建模語言, 使用這些符號能夠形象地描述系統的各個方面
        · UML 經過創建圖形之間的各類關係(如類與類之間的關係)來描述模型

        

        • UML 中的關係主要包括 4 種:

        - 關聯關係(association)
        - 依賴關係(dependency)
        - 泛化關係(generalization)
        - 實現關係(realization)

        1.4 用例圖

        用例圖(Use Case Diagram): 也稱爲用戶模型圖, 是從軟件需求分析到最終實現的第一步, 它是從客戶的角度來描述系統功能。
        用例圖包含 3 個基本組件: 參與者(Actor), 用例(Use Case), 關係:
        · 參與者(Actor): 與系統打交道的人或其餘系統即便用該系統的人或事物. 在 UML 中參與者用人形圖標表示

        
        · 用例(Use Case): 表明系統的某項完整的功能. 在 UML 中使用一個橢圓來表示

        
        · 關係: 定義用例之間的關係 ------ 泛化關係, 擴展關係, 包含關係

 

        1.5 用例之間的關係----泛化關係

        

 

        1.6 用例之間的關係----包含關係

        

 

        1.7 用例之間的關係----擴展關係

        

2、類圖

        類圖是面向對象系統建模中最經常使用的圖，是定義其餘圖的基礎。類圖主要是用來顯示系統中的類, 接口以及它們之間的關係。類圖包含的主要元素有類, 接口和關係，其中關係有關聯關係, 泛化關係, 依賴關係和實現關係，在類圖中也能夠包含註釋和約束。

        1.1 類的表示法

        

        1.2 接口的表示法

        

        1.3 類之間的關係 ---- 泛化關係

        

 

        1.4 類之間的關係 ---- 實現關係

        

        1.5 類之間的關係 ---- 依賴關係

        

        1.6 類之間的關係 ---- 關聯關係

        

        

        • 關聯關係的名稱: 關聯關係能夠有一個名稱, 用於描述該關係的性質.  此關聯名稱應該是動詞短語, 由於它代表源對象正在目標對象上執行動做.

        

        • 當一個類處於關聯的某一端時, 該類就在這個關係中扮演一個特定的角色. 具體來講, 角色就是關聯關係中一個類對另外一個類所表現的職責. 角色名稱是名詞或名稱短語.

        

        • 關聯關係的多重性是指有多少對象能夠參與該關聯, 多重性能夠用來表達一個取值範圍, 特定值, 無限定的範圍.

        

        • 聚合關聯是一種特殊的關聯. 它表示類間的關係是總體與部分的關係. 簡言之: 關聯關係中的一個類描述了一個較大的事物, 它由較小的事物組成.

        • 聚合關係描述了 「has a」 的關係, 即總體對象擁有部分對象

        • 總體和部分之間用空心菱形箭頭的連線鏈接, 箭頭指向總體

        • 組成關係是更強形式的聚合.

        • 組合關係中, 整件擁有部件的生命週期, 因此整件刪除時, 部件必定會跟着刪除. 並且, 多個整件不能夠同時共享同一個部件。

        • 聚合關係中, 整件不會擁有部件的生命週期, 因此整件刪除時, 部件不會被刪除. 再者, 多個整件能夠共享同一個部件.

        • UML 中組成關係用實心的菱形實線表示

        

    • 導航性表示可從源類的任何對象到目標類的一個或多個對象遍歷. 即: 給定源類的一個對象, 能夠獲得目標類的全部對象. 能夠在關聯關係上加上箭頭表示導航方向.

    • 只在一個方向上能夠導航的關聯稱爲單向關聯,用一個帶箭頭的方向表示; 在兩個方向上均可以導航的關聯稱爲雙向關聯, 用一條沒有箭頭的實線表示.

        

3、時序圖

        • 時序圖用於描述對象之間的傳遞消息的時間順序, 即用例中的行爲順序.

        • 當執行一個用例時, 時序圖中的每條消息對應了一個類操做或者引發轉換的觸發事件.

        • 在 UML 中, 時序圖表示爲一個二維的關係圖, 其中, 縱軸是時間軸, 時間延豎線向下延伸. 橫軸表明在協做中各個獨立的對象. 當對象存在時, 生命線用一條虛線表示, 消息用從一個對象的生命線到另外一個對象的生命線的箭頭表示. 箭頭以時間的順序在圖中上下排列.

 

        

        1.1   時序圖中的基本概念

    •    對象: 時序圖中對象使用矩形表示, 而且對象名稱下有下劃線. 將對象置於時序圖的頂部說明在交互開始時對象就已經存在了. 若是對象的位置不在頂部, 表示對象是在交互的過程當中被建立的.

    •    生命線:  生命線是一條垂直的虛線. 表示時序圖中的對象在一段生命週期內的存在. 每一個對象底部中心的位置都帶有生命線.

    • 消息: 兩個對象之間的單路通訊. 從發送方指向接收方. 在時序圖中不多使用返回消息.

    • 激活: 時序圖能夠描述對象的激活和鈍化. 激活表示該對象被佔用已完成某個任務. 鈍化指對象處於空閒狀態, 等待消息. 在 UML 中, 對象的激活時將對象的生命線拓寬爲矩形來表示的. 矩形稱爲計劃條或控制期. 對象就是在激活條的頂部被激活的. 對象在完成本身的工做後被鈍化.

    • 對象的建立和銷燬: 在時序圖中, 對象的默認位置是在圖的頂部. 這說明對象在交互開始以前就已經存在了. 若是對象是在交互過程當中建立的, 那麼就應該將對象放到中間部分. 若是要撤銷一個對象, 在其生命線終止點處放置 「 X」 符號.

4、活動圖

        在 UML 中, 活動圖本質上就是流程圖. 它用於描述系統的活動, 斷定點和分支等.

        

        1.1 活動圖中的基本概念

        • 動做狀態: 原子的, 不可中斷的動做, 並在此動做完成以後向另外一個動做轉變. 在 UML 中動做狀態用圓角矩形 表示, 動做狀態所表示的動做寫在圓角矩形內部.

        • 分支與合併:  分支在軟件系統中很常見. 通常用於表示對象類所具備的條件行爲. 用一個布爾型表達式的真假來斷定動做的流向. 條件行爲用分支和合並表達.在活動圖中, 分支用空心小菱形      表示. 分支包括一個入轉換和兩個待條件的出轉換, 出轉換的條件應該是互斥的, 須保證只有一條出轉換可以被觸發. 合併包含兩個帶條件的入轉換和一個出轉換.

        • 分叉與匯合: 分叉用來描述併發線程, 每一個分叉能夠有一個輸入轉換和兩個或多個輸出轉換. 每一個轉換均可以是獨立的控制流. 匯合表明兩個或多個併發控制流同步發生, 當全部的控制流都達到匯合點後, 控制才能繼續往下進行. 每一個匯合能夠有兩個或多個輸入轉換和一個輸出轉換. 在 UML 中分叉和匯合用一條粗直線表示

        • 泳道: 泳道將活動圖中的活動劃分爲若干組, 並將每一組指定給負責這組活動的業務組織. 泳道區分負責活動的對象, 明確地表示哪些活動是由哪些對象進行的. 每一個活動指定明確地屬於一個泳道. 在活動圖中, 泳道用垂直實線繪出, 垂直線分隔的區域即爲泳道

5、狀態圖

        狀態圖: 經過創建對象的生存週期模型來描述對象隨時間變化的動態行爲.

        

 

        1.1 狀態圖中的基本概念

        • 狀態: 用圓角矩形表示. 狀態名稱表示狀態的名字, 一般用字符串表示. 一個狀態的名稱在狀態圖所在的上下文中應該是惟一的.

        • 轉換: 用帶箭頭的直線表示. 一端連着源狀態, 一端連着目標狀態.

        • 初始狀態: 每一個狀態圖都有一個初始狀態. 此狀態表明狀態圖的起始位置. 初始狀態只能做爲轉換的源, 不能做爲轉換的目標, 而且在狀態圖中只能有一個. 初始狀態用一個實心圓表示.

        • 終止狀態: 模型元素的最後狀態, 是一個狀態圖的終止點. 終止狀態在一個狀態圖中能夠有多個.

6、協做圖

        協做圖(也叫合做圖)是一種交互圖。時序圖主要側重於對象間消息傳遞在時間上的前後關係, 而協做圖表達對象間的交互過程及對象間的關聯關係。

        

        

7、對象圖

        對象圖是類圖的一個實例, 用於顯示系統執行時的一個可能的快照. 即在某一個時間上系統可能出現的樣子. 對象圖用帶下劃線的對象名稱來表示對象.

        

8、 對象圖 

        • 包圖: 由包和包之間的關係組成. 包的圖標就如同一個帶標籤的文件夾.

        • 包提供了一種用於組織各類元素的分組機制. 在 UML 中, 包用來對元素進行分組, 併爲這些元素提供命名空間.　包所擁有的或者引用的全部元素稱爲包的內容, 包沒有實例.

        

 

9、組件圖

        組件圖用來創建系統中各組件之間的關係, 各組件經過功能組織在一塊兒。Javabean, ejb, jsp 都是組件。在UML中，組件使用在左側有兩個小矩形的大矩形來表示。組件圖能夠用來設計系統的總體構架。

        

10、部署圖

        • 部署圖用來幫助開發者瞭解軟件中的各個組件駐留在什麼硬件位置, 以及這些硬件之間的交互關係。

        • 節點: 用來表示一種硬件, 能夠是打印機, 計算機等.節點的標記符號是一個三維框，在框的左上方包含了節點的名稱。

        • 通訊關聯: 節點經過通訊關聯創建彼此的關係，採用從節點到節點繪製實線來表示關聯。

        

11、軟件的生命週期

        軟件生命週期: 軟件的產生直到報廢的生命週期。軟件生命週期內有問題定義, 可行性分析, 整體描述, 系統設計,編碼, 調試和測試, 驗收與運行, 維護升級到廢棄等階段。隨着新的面向對象的設計方法和技術的成熟, 軟件生命週期設計方法的指導意義正在逐步減小。

        1.1 軟件工程能夠分爲三個大的階段     

    • 軟件工程能夠分爲三個大的階段:需求; 設計; 測試與維護

        • 1. 需求:

            –開發目標

            –可行性分析

            –需求分析

        •2. 設計:

            –概要設計

            –詳細設計

            –編碼與單元測試

       •3. 測試與維護

            –綜合測試

            –維護 

        1.2 軟件的生命週期概念

一、問題的定義及規劃(可行性分析報告和軟件開發計劃): 此階段是軟件開發方與需求方共同討

   論，主要肯定軟件的開發目標及其可行性。

二、需求分析(需求分析說明書和初步的用戶手冊): 在肯定軟件開發可行的狀況下，對軟件須要

   實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，這一階段作得好，將爲

   整個軟件開發項目的成功打下良好的基礎。

三、軟件設計(概要設計、詳細設計): 此階段主要根據需求分析的結果，對整個軟件系統進行設

   計，如系統框架設計，數據庫設計等等。軟件設計通常分爲整體設計和詳細設計。

四、程序編碼(提交源程序及清單): 此階段是將軟件設計的結果轉換成計算機可運行的程序代碼。

   在程序編碼中必需要制定統一，符合標準的編寫規範。以保證程序的可讀性，易維護性，提

   高程序的運行效率。

五、軟件測試(提交軟件維護測試報告): 在軟件設計完成後要通過嚴密的測試，以發現軟件在整

   個設計過程當中存在的問題並加以糾正。整個測試過程分單元測試（白盒）、集成測試（黑

   盒，功能測試、強度性能測試）以及系統測試三個階段進行。測試的方法主要有白盒測試和

   黑盒測試兩種。在測試過程當中須要創建詳細的測試計劃並嚴格按照測試計劃進行測試，以減

   少測試的隨意性。

六、運行維護（提交軟件維護報告） : 軟件維護是軟件生命週期中持續時間最長的階段。在軟件

   開發完成並投入使後，因爲多方面的緣由，軟件不能繼續適應用戶的要求。要延續軟件的使

   用壽命，就必須對軟件進行維護。軟件的維護包括糾錯性維護和改進性維護兩個方面。

        1.3 軟件的生命週期 ---- 瀑布模型

        

        1.4 軟件的生命週期 ---- RUP

        • 統一軟件開發過程(Rational Unified Process,RUP): 一個通用的軟件流程框架, 以架構爲中心, 用例驅動的迭代化開發流程. RUP 是從幾千個軟件項目的實踐經驗中總結出來的, 對於實際的項目具備很強的指導意義.

        • RUP 用二維座標來描述. 橫軸經過時間來組織, 是過程展開的生命週期特徵, 體現開發過程的動態結構; 縱軸之內容來組織, 體現開發過程的靜態結構.

        

        1.5 RUP 中軟件生命週期的四個階段

        • 初始階段: 「得到項目的基礎」. 該階段的主要人員是項目經理和系統設計師. 所要完成的主要任務包括對系統的可行性分析; 建立基本的需求; 識別系統的關鍵任務.

        • 細化: 主要目標是建立可執行構件基線; 精化風險評估; 捕捉大部分的系統功能需求用例; 爲構造階段建立詳細需求. 該階段並非要建立可執行的系統, 而是展示用戶所指望的需求.

        • 構建: 完成全部的需求, 分析和設計. 該階段的製品將演化成最終系統

        • 交付: 將完整的系統部署到用戶所處的環境中.

        1.6 RUP 中的核心工做流

        • RUP中有9個核心工做流. 分爲6個核心過程工做流(Core Process Workflows) 和 3個核心支持工做流 (Core Supporting Workflows). 儘管6個核心過程工做流相似於傳統瀑布模型中的幾個階段, 但迭代過程當中的階段是徹底不一樣的, 這些工做流在整個生命週期中一次又一次被訪問. 9個核心工做流在項目中輪流被使用, 在每一次迭代中以不一樣的重點和強度重複.

        

        

 

 

 

 

 

 

 

本文爲博主原創文章，轉載請註明出處！

https://my.oschina.net/u/3375733/blog/