閱讀144 返回首頁    go 汽車大全


係統建模

結構化係統建模


1.數據流圖 DFD(Data Flow Diagram)

數據流圖由數據流(data flow),加工(process),文件(data store),源 / 宿(Source / Sink)四部分組成。
  • 數據流是有一組固定成分的數據組成,表示數據的流向,用箭頭表示。它可以從源、文件流向加工,也可以從加工流向文件和宿,還可以從一個加工流向另一個加工。
  • 加工描述了輸入數據留到輸出數據了之間的變換,也就是輸入數據流做了什麼處理後變成了輸出數據流,用圓或橢圓表示。每個加工有一個名字和一個編號。
  • 源/宿中,源是指係統所需數據的發源地,宿是指係統所產生的數據的歸宿地,用方框表示。源或宿均對應於外部實體。
  • 數據的存儲用雙杠表示。

實例:

Level-0 Diagram:


Level-1 Diagram:


數據流圖約束:

加工(Process):
  • 加工必須有數據流入,否則你加工的數據從何而來,在流圖中,隻有輸出的對象是源(Source)
  • 加工必須有數據流出,否則會產生數據黑洞(black hole). 在流圖中,隻有輸入的對象是宿(Sink)
  • 加工是一個動作,裏麵含有動詞
文件(Data Store):
  • 數據不能從一個文件直接流向另一個文件,必須通過加工處理
  • 數據不能從源(Source)直接流向文件,likewise,數據不能衝文件直接流向宿(Sink)
  • 文件是名詞表達式。
源 / 宿 (Source/Sink):
  • 數據不能從源直接流向宿,必須通過加工處理。
  • 源/宿 是外部實體,是名詞。
數據流 (Data Flow):
  • 數據流不能直接回到其剛離開的加工。
  • 數據流進入數據存儲(Data Store)意味著Create/Update
  • 數據流離開數據存儲意味著Retrive
  • 數據流是內部實體,也是名詞。

判定表

對於複雜邏輯可以使用判定表(Decision Table)。

定表通常有以下四個部分組成:
  1)條件樁(Condition Stub):列出了問題得所有條件。通常認為列出的條件的次序無關緊要。
  2)動作樁(Action Stub):列出了問題規定可能采取的操作。這些操作的排列順序沒有約束。
  3)條件項(Condition Entry):列出針對它左列條件的取值。在所有可能情況下的真假值。
  4)動作項(Action Entry):列出在條件項的各種取值情況下應該采取的動作。
實例:


實體聯係圖ER (Entity-Relationship)

對於DFD中名詞,也就是實體,描述這些實體之間的關係用ER圖,其實ER圖和UML的概念類圖(Conceptual / domain class diagram)有很多相似之處。


流程圖(Flow Chart)

A flowchart is a type of diagram thatrepresents an algorithmor process, showing the steps as boxes of various kinds, and their order by connecting these with arrows.

ž  Oval(橢圓形) – Start and end Symbols

ž  Rectangles(矩形) – Generic processing steps

ž  Diamonds – Conditional or decision

ž  Parallelogram(平行四邊形) – 輸入輸出 input/output

實例:



麵向對象係統建模


需求建模( Modeling Requirements) - Use case View

可以為用戶需求創建多種不同的視圖。 每個視圖都提供特定類型的信息。 當您創建這些視圖時,最好經常在各個視圖之間進行切換。 創建時,可以從任何視圖開始。


關係圖或文檔

需求模型中描述的內容

用例圖

誰使用係統以及使用係統執行什麼操作。

描述係統的使用方式

概念類圖

用於描述需求的類型的術語表;可在係統界麵看到的類型。

定義用於描述需求的術語

活動圖

由用戶與係統或其部件執行的活動之間的工作流和信息。

顯示用戶和係統之間的工作流

序列圖

用戶與係統或其部件之間的交互的序列。 活動圖的替代視圖。

顯示用戶和係統之間的交互

附加文檔或工作項

性能、安全性、可用性和可靠性條件。

描述服務質量要求

附加文檔或工作項

非特定於具體用例的約束和規則

顯示業務規則


當用於此目的時,UML 類圖的內容稱為“概念類圖“,也稱為域模型(Domain Model)

用例圖

用例之間的關係:
  • 泛化Generalization

  • 包含Include :   包含關係用來把一個較複雜用例所表示的功能分解成較小的步驟。指向分解出來的功能用例

  • 擴展extend:擴展關係是指用例功能的延伸,相當於為基礎用例提供一個附加功能。指向基礎用例

包含(include)、擴展(extend)、泛化(Inheritance) 的區別:

        條件性:泛化中的子用例和include中的被包含的用例會無條件發生,而extend中的延伸用例的發生是有條件的;

        直接性:泛化中的子用例和extend中的延伸用例為參與者提供直接服務,而include中被包含的用例為參與者提供間接服務。

        extend而言,延伸用例並不包含基礎用例的內容,基礎用例也不包含延伸用例的內容。

        Inheritance而言,子用例包含基礎用例的所有內容及其和其他用例或參與者之間的關係;


邏輯建模 (Modeling a System's Logical Structure)- Logical View

Class Diagram,Sequence Diagram, State machine Diagram

層關係圖可直觀顯示係統的高級邏輯架構:https://technet.microsoft.com/zh-cn/dd409462(v=vs.89)

一個Web應用的4層關係圖:


業務流程建模 (Modeling System Workflows)- Process View

活動圖(Activity Diagram)

何時使用活動圖

活動圖中的主要元素

  • 活動(Activity):如果活動隻包含一個動作,則此活動(Activity)是動作(Action)
    例如“付款”這個活動,可能包含“檢驗賬號餘款”,“選擇付款方式”,“確認付款”等動作。
  • 泳道(swimlane):根據每個活動的職責對所有活動進行劃分。
  • 對象流:類似於DFD中數據流,隻不過在OO中Entity叫對象。
  • 分支與合並(Decision and Merge Nodes)

  • 分叉與匯合(Folk  and Join Nodes)

案例


Reference:

1. 如何在Visio中畫活動圖:https://technet.microsoft.com/zh-cn/dd409465(v=vs.89)
2. https://www.cnblogs.com/ywqu/archive/2009/12/14/1624082.html

構建和部署 - Deployment View

Component, Package,  Deployment Diagrams


數據庫建模


數據庫基礎知識

超鍵(Super Key):能唯一確定一組屬性

候選鍵(Candidate Key):最小屬性集的超鍵,減少一個屬性,其就不是超鍵了,但增加一個屬性,其任然是超鍵,但不是候選鍵。

主鍵(Primary Key):從候選鍵中選擇一個即為主鍵。

子鍵(Subkey):Super key函數確定關係中所有屬性,這是好的函數依賴(FD),但如果有這樣的FD,其隻能函數確定關係中部分屬性,而不是全部屬性,那麼次局部Super key就是subkey。

如何消除子鍵(https://www.tomjewett.com/dbdesign/dbdesign.php?page=subkeys.php

無損連接分解(lossless join decomposition)

1.    把所有函數依賴子鍵的屬性移到一個新表

2.    將子鍵複製到新表中,並將其標識為新表中得主鍵。

3.    在老表中保留子鍵作為新表的外鍵(Foreign key),此時老表和新表滿足many-to-one的關係

數據庫規範化(Normalization)

當數據庫中得所有表都沒有子鍵,那麼此數據庫將滿足3NF的要求。

部分函數依賴:此時的subkey 是 primary key的一部分。

傳遞函數依賴:此時的subkey 不是 primary key的一部分。

數據庫設計步驟

  1. 需求分析:形成DFD 
  2. 概念結構分析:E-R圖
  3. 邏輯結構設計:將E-R圖轉換為指定的數據模型,數據庫規範化,確定完整性約束,確定用戶試圖。
  4. 物理結構設計:結合DBMS,優化存儲結構和數據存儲路徑
  5. 應用程序設計


最後更新:2017-04-02 15:15:05

  上一篇:go 一起來為存儲瘦身
  下一篇:go Android 4.1 - 將係統瀏覽器編譯成獨立應用