系統分析師UML項目實戰書籍閱讀總結

jopen 9年前發布 | 16K 次閱讀 UML

1. UML項目現場

只有平庸的人,才會提出復雜的解決方案

UML建模順序: 流程建模 -> 用例建模 ->領域建模

活動圖,用例圖,類圖的圖標名稱介紹.

2. 業務流程建模

業務流程定義:

  1. 特定的客戶

  2. 特定的目標

  3. 特定的服務
    4. </ol>

    對于不重要的工作,不做活動圖

    表2-1 活動圖用于表示業務流程或系統流程

    </tr> </thead>

    </tr>

    </tr>

    </tr>

    </tr>

    </tr>

    </tr>

    </tr> </tbody> </table>

    表2-2 于系統設計時間的活動圖和順序圖

    項目\活動圖 業務流程 系統流程
    主要作用 表示企業組織的未來流程 表示系統內部的系統流程
    人工操作 可能出現人工操作 不會出現人工操作
    生成機時 需求分析階段 系統設計時間
    相關文件 收錄在系統需求的規格書(SRS) 收錄在系統設計規格書(SDS)
    繪制者 系統分析師 系統設計師
    觀看者 客戶/用戶(系統設計師也會參考使用) 程序設計師
    粒度 一張活動圖對應多個用例(即將用例視為黑箱) 一張活動圖對應一個用例(即將用例視為白盒)

    </tr> </thead>

    </tr>

    </tr>

    </tr>

    </tr>

    </tr>

    </tr>

    </tr>

    </tr> </tbody> </table>

    活動圖圖標:

    1. 起始節點: 實心小圓 (建議一個活動圖 一個起始節點)

    2. 活動終點: 雙圓,內實外空

    3. 判斷節點: 空心菱形

    4. 動作: 圓角矩形 動作粒度要與用例粒度相近

      4.1 第一行: (一個動作負責人)

      4.2 第二行: 動作名稱,動詞開頭

      </li>

    5. 合并節點: 空心菱形

    6. 活動: 圓角矩形,右下角三叉圖標 (活動可拆分外令一個活動圖 )

    7. 分叉與會合: 粗線段 (等所有條件具備進行下一階段 建議分叉與會合成對出現)

    8. 對象節點: 矩形 (代表流入/流出的數據項)
      9. </ol>

      3. 用例建模

      用例來源:

      1. 業務流程

      2. 功能流程

      3. 其他用例
        4. </ol>

        建議同時生成用例圖和功能架構圖.

        用例圖作用:

        1. 規范一套動作

        2. 明確結果

        3. 表明參與者 (參與者包括主要參與者(啟動者)和次要參與者)
          4. </ol>

          業務流程導出初版用例

          1. 查看動作,動作負責人即為參與者,動作即為用例

          2. 查看判斷節點,判斷判斷節點是否需要其他用例支持
            3. </ol>

            功能劃分->業務流程->初版用例->功能架構->用例圖->用例描述

            用例描述:

            1. 前置條件: 執行流程前必須要滿足的條件

            2. 主要流程: 一般正常的流程 (主要詳細分為參與者輸入,系統處理過程,及輸出,要求非常詳細!)

            3. 替換流程: 特殊情況 (替換流程的編號,緊跟發生特殊情況的主要流程編號)

            4. 后置條件: 必須要完成的結果
              5. </ol>

              包含關系與擴展關系

              1. 包含關系: <<include>> 虛線箭頭指向被包含 被包含可視為前置條件

                1.1 被包含的小用例無法脫離基礎用例而單獨存在

                1.2 基礎用例一定執行被包含的小用例

                1.3 兩者加起來是一條流程

                </li>

              2. 擴展關系: <<extends>> 虛線箭頭直線被擴展 擴展可不執行 ,可視為替換流程

                2.1 拓展的小用例無法脫離基礎用例而單獨存在

                2.2 基礎用例不一定執行拓展的小用例

                2.3 兩者加起來是兩條流程,其一是單獨的基礎用例,其二是基礎用例外加拓展用例

                </li> </ol>

                4. 領域建模

                領域模型:

                1. 一種概念模型,呈現問題領域中的重要概念

                2. 描述問題領域中的實體,實體屬性,操作,角色,關系和限制.

                3. 對于用例所描述的互動過程,領域模型可以為用例起支持結構作用.

                4. 通常用類圖描述領域模型.

                5. 領域模式可用于出代碼
                  6. </ol>

                  類圖:

                  1. 類用矩形表示,第一行為名稱,第二行為屬性,第三行為操作

                  2. 屬性 屬性名稱:數據類型=初始值

                  3. 操作 操作名稱(參數,數據類型):返回值數據類型

                  4. 結合關系: 實線 表示兩個領域存在重要且需要永久保存的靜態關系

                    4.1 單向結合 無法從目標端找回來源端

                    4.2 雙向結合

                    4.3 聚合關系 空心菱形 指向聚合類 整體-部分

                    4.4 組合關系 實心菱形 組合關系具有聚合關系的所有特性另加部分對象只會鏈接到一個整體對象,不允許數個整體對象共用一個部分對象,部分對象跟隨整體對象的存活.

                    4.3 個體數目 下限..上限 表明關系:一對一,一對多,多對多.多對一.

                    </li> </ol>

                    用例描述推導領域模型

                    1. 查看用例描述,把其中的數據項歸到領域中.

                    2. 類代表領域,數據項代表屬性

                    3. 查看概念之間的關系

                    4. 根據關系在兩端添加數量
                      5. </ol>

                      領域模型呈現業務規則

                      1. 通過結合關系和個體數目來表達關系靜態結構的業務規則

                      2. 通過操作來表達計算公司以及一些需要查驗或檢核的業務規則
                        3. </ol>

                        5. 模型走讀

                        作用:檢測模型質量

                        走讀功能架構圖與用例圖

                        1. 是否可以從功能架構圖追溯到用例圖 (最好情況: 直接采用用例作為功能架構圖中的功能)

                        2. 檢測功能架構圖中的系統,功能模塊,用例名稱是否和用例圖一致

                        3. 若功能模塊和底下的功能模塊與客戶的征求建議書(RFP)不一致,則需請求客戶同意,看功能模塊的切割、名稱、地下的功能歸屬是否恰當.
                          4. </ol>

                          走讀中遇到的問題及其解決方案:

                          1. 出現多個用例參與一個用例入口 解決:用例圖中參與者第二行標明{or }
                            2. </ol>

                            走讀用例圖和用例描述

                            1. 檢測參與者是否擺在系統方框之外,在系統方框和功能模塊方框最上方要用標注<\<系統>>或<\<功能模塊>>

                            2. 用例描述每一個步驟都以參與者或系統開頭
                              3. </ol>

                              界面雛形工具: Pencil

                              走讀用例描述與領域模型

                              1. 主要查看是否遺漏數據項(屬性)、業務規則和重要操作
                                2. </ol>

                                善用對象圖

                                對象圖是系統的快照,可表示某一時刻或某一場景系統內有哪些重要對象,屬性的數值以及他們之間的關系.

                                在繪制對象圖,想好場景,一邊套場景,一邊通過對象圖走讀領域模型

                                用對象圖發現用例描述某一動作不能執行, 解決方案 增加用例輔助完成.

                                領域模式描述:

                                領域模式主要通過文字記錄類別、屬性、結合、限制的定義或解釋、操作

                                6. 繼續走讀

                                走讀中做了幾個調整.

                                1.整合應整合用例(自動匯整集錦交易與自動申購基金)

                                非功能性需求可以添加到用例描述中或建立單獨一個表格供整個系統參考.

                                走讀領域,可搭配情景對象圖.這個很重要,其實在做系統測試時候,完全可以按照這個來.

                                7. 基金系統范例

                                以功能模塊拆分用例圖.

                                主要把前面章節的圖 匯總在一起.

                                總結

                                第四章的結合實例來說領域模型很精彩

                                重復地方很多,有利有弊.

                                對于整個系統流程來說,算是不錯的體驗.能夠讓讀者大概明白UML的大概過程,每一步應該做什么.然后循環迭代.這和敏捷開發的思想很像.

                                來自：http://mzkmzk.github.io/blog/2015/10/01/uml_project_book

                                 本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
                                 轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
                                 本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！
                                  本文地址：http://www.baiduhome.net/news/view/147504e

                                相關資訊

                                相關經驗

                                相關文檔

    項目/圖類型 活動圖(系統流程) 順序圖(對象互動)
    主要作用 表示系統內部的系統流程 表示系統內部的對象互動
    主要特色 凸顯流程與控制節點 凸顯對象依序調用方法或函數
    生成時機 高級的系統設計時間 細部的系統設計時間
    相關文件 收錄在系統設計規格書(SDS) 同左
    實作情況 無法直接對應程序代碼 可以直接對應程序代碼(有些UML工具可以自動產碼)
    繪制者 系統設計師 同左
    觀看者 程序設計師 同左
    粒度 一張活動圖對應一個用例(即將用例視為白箱) 同左