1. 程式人生 > >業務模型;UML類圖;資料模型;概念模型;面向物件模型

業務模型;UML類圖;資料模型;概念模型;面向物件模型

因為欣賞所以轉載,原文地址 http://blog.csdn.net/sunleap/article/details/4976993

開發的流程有以下幾步:

image

               物件圖 • 組織檢視:組織結構的靜態模型。包括:層次組織結構的人員(people not human)資源,生產資源(比如,裝置,運輸等)以及計算機、通訊網路結構等。 
• 資料檢視:業務資訊的靜態模型。包括:資料模型,知識結構,資訊載體,技術術語和資料庫模型等。 
• 功能檢視:業務流程任務的靜態模型。包括:功能層次,業務物件,支援系統和應用軟體等。 
• 控制(業務)檢視:動態模型,展示流程運轉情況,並能夠將業務流程與流程相關的資源、資料以及功能等聯絡起來。包括:事件驅動過程鏈、資訊流、物流、通訊圖、產品定義、價值增值圖等。

業務模型的畫法可以用任何編輯工具如Visio、word完成,當然目前PowerDesigner、Erwin等專業工具也支援業務模型。
資料模型是對企業或資訊系統種的資料特徵的抽象,隨著資料庫技術的大量使用,主要指資料庫模型。
  資料模型所描述的內容包括三個部分:資料結構、作用於資料上的操作、資料約束。
  1)資料結構:資料模型中的資料結構主要描述資料的型別、內容、性質以及資料間的聯絡等。資料結構是資料模型的基礎,資料操作和約束都建立在資料結構上。不同的資料結構具有不同的操作和約束。
  2)資料操作:資料模型中資料操作主要描述在相應的資料結構上的操作型別和操作方式。
  3)資料約束:資料模型中的資料約束主要描述資料結構內資料間的語法、詞義聯絡、他們之間的制約和依存關係,以及資料動態變化的規則,以保證資料的正確、有效和相容。

  資料模型按不同的應用層次分成三種類型:分別是概念資料模型、邏輯資料模型、物理資料模型。
  1)概念資料模型(Conceptual Data Model):簡稱概念模型,主要用來描述世界的概念化結構,與具體的資料庫系統無關。概念資料模型必須換成邏輯或物理資料模型,才能在資料庫系統中實現。概念資料模型中最常用的是E-R模型。
  2)邏輯資料模型(Logical Data Model):簡稱資料模型,這是從資料庫所看到的模型,是具體的資料庫管理系統所支援的資料模型,如網狀資料模型(Network Data Model)、層次資料模型(Hierarchical Data Model)等等。此模型既要面向使用者,又要面向系統。

  3)物理資料模型(Physical Data Model):簡稱物理模型,是面向計算機物理表示的模型,描述了資料在儲存介質上的組織結構。物理資料模型的設計要考慮資料管理的效能問題,它不但與具體的資料庫系統有關,而且還與作業系統和硬體有關。每一種邏輯資料模型在實現時都有起對應的物理資料模型。
可以利用PowerDesigner、Erwin、Oracle Data builder、Infosphere Data Architect、Rose等建模工具建立資料模型。
這個應該是軟體開發者喜歡的模型,使用面向物件分析(OOA)和麵向物件設計(OOD)過程中所建立模型,包括類圖、物件圖、狀態圖以及與之相關的活動圖、順序圖、元件圖等,可以利用UML建模工具,如Rose、Infosphere DataArchitect等工具以及軟體
整合開發工具(Eclipse、Netbeans)建立面向物件模型。當然有些資料建模工具也支援面向物件模型。
資料探勘模型的概念雖然重要,但沒有比較權威的解釋,我說一下自己的理解,使用資料探勘演算法建立的,描述資料之間的關係模型就叫資料探勘模型。
資料探勘模型的表現形式多種多樣,跟資料探勘演算法有關,也跟我們要進行的後續操作有關。比如表現學生身高體重關係的函式(可以是直線、曲線、二次函式、多項式函式)是一個數據挖掘模型;表現超市商品關聯關係的關聯規則集合也是一個數據挖掘模型;表現銀行客戶分類情況的決策樹也是一個數據挖掘模型。

各個階段的UML圖

(1)需求階段是:用例圖

(2)分析階段是:類圖、序列圖

(3)設計階段:類圖、序列圖與平臺結合

業務建模工作步驟:

(1)選定業務單元

(2)識別業務執行者

(3)識別業務用例

(4)詳述業務用例

(5)建立業務物件模型

    類圖(Class Diagram)應該是使用的最多的一種UML圖。其語法並不複雜,可能只需要幾天時間就能掌握,但是其背後的面向物件(OO)思想卻是需要日積月累才能深刻理解。

1、OOA(Object-Oriented Analysis 面向物件分析)

2、OOD(Object-Oriented Design 面向物件設計)

3、OOP(Object-Oriented Programming 面向物件程式設計)

4、OOT(Object-Oriented Technology 面向物件技術)

PS:無論是開發人員還是分析人員,這幾種思想是必須要掌握的,作為開發人員來說,OO的思想,其深度和延伸內容可謂博大精深,值得花時間去學習。

    類可以視作一現實事物抽象出的統一的、相似的模型。

    物件可以看做是類的具體化,就像模具匯出的產品一樣。

    類圖就是描述類與類之間關係的圖。

案例:

1、識別出類。

2、識別出類的主要屬性。

3、畫出類之間的關係。

4、對各類進行分析、抽象、整理。

    兩個類之間有關係,但又不確定是什麼關係,可以用關聯關係表達。


PS:關聯關係如果出現數量上的對應可以寫上數字表示數量,可以用角色關係表示兩類分別處於什麼角色,單向關聯關係表示關聯是單向的,只能由關聯方找到被關聯方。在寫程式碼時,可以將其視作關聯類包含了被關聯類的一個引用。

    包含關係表示一個類包含另一個類。

PS:包含關係分為兩種,一種是弱包含關係,叫做聚合,為空心菱形,一種是強包含關係,叫做組合,為實心菱形。一開始可以將所有包含關係視作弱包含,當發現某些關係可以用強包含表示時,才轉為強包含關係。

    當一個類是另一個類的子類時,可以使用泛化關係。

PS:泛化關係通常也被稱作繼承關係,根據類的發現先後關係,如果是由父類匯出子類,這樣就可以說子類繼承父類,如果是由子類匯出父類,這樣就可以說父類泛化子類。

    當一個類可以實現某個抽象類時,可以使用實現關係。

PS:標識介面與類之間的關係用的比較多。

    當一個類需要另一個類協助時,可以用依賴關係表示。

    當某類使用或者包含自己時,可以使用遞迴關係。

    當發現兩個類之間的關係不能用一般關係來表示,這時候可以用關聯類來表示關係,這也就是三角關係。

PS:可以通過思考屬性是否恰當來識別出關聯類關係,列出兩類的關鍵屬性之後,思考這些屬性的屬性值是不是由該類本身就可以確定,如果不能兩類之間就可能有關聯類關係。

    如果說類圖代表了一類事物,那麼物件圖就代表著某個具體的事物。

現實世界被業務模型對映並且記錄下來,但 這只是原始需求資訊,距離可執行的程式碼還很遙遠,必須把這些內容再換成一種可以指導開發的表達方式。UML 通過稱之為概念化的過程( Conceptual)來 建立適合計算機理解和實現的模型,這 個模型稱為分析模型( Analysis Model)。分析模型介於原始需求和計算機實現之間,是一種過渡模型。分析模型向上映射了原始需求,計算機的可執行程式碼可以通過分析模型追溯到原始需求;同時,分析模型向下為計算機實現規定了一種高層次的抽象,這種抽象是一種指導,也是一種約束,計算機實現過程非常容易遵循這種指導和約束來完成可執行程式碼的設計工作。

事實上分析模型在整個分析設計過程中承擔了很大的職責,起到了非常重要的作用。繪製分析模型最主要的元模型有:

邊界類(boundary) 。邊界是面向物件分析的一個非常重要的觀點。從狹義上說,邊界就是大家熟悉的介面,所有對計算機的操作都要通過介面進行。從廣義上說,任何一件事物都分為裡面和外面,外面的事物與裡面的事物之間的任何互動都需要有一個邊界。比如參與者與系統的互動,系統與系統之間的互動,模組與模組之間的互動等。只要是兩個不同職責的簇之間的互動都需要有一個邊界,換句話說,邊界決定了外面能對裡面做什麼“事”。 在後續的章節中,讀者會感受到邊界的重要性,邊界能夠決定整個分析設計的結果。

實體類(entity) 。原始需求中領域模型中的業務實體映射了現實世界中參與者完成業務目標時所涉及的事物,UML 採用實體類來重新表達業務實體。實體類可以採用計算機觀點在不丟失業務實體資訊的條件下重新歸納和組織資訊,建立邏輯關聯,新增那些實際業務中不會使用到,但是執行計算機邏輯時需要的控制資訊等。這些實體類可以看作是業務實體的例項化結果。

控制類(control) 。邊界和實體都是靜態的,本身並不會動作。UML 採用控制類來表述原始需求中的動態資訊,即業務或用例場景中的步驟和活動。從UML 的觀點看來,邊界類和實體類之間,邊界類和邊界類之間,實體類和實體類之間不能夠直接相互訪問,它們需要通過控制類來代理訪問要求。這樣就把動作和物體分開了。考慮一下,實際上在現實世界中,動作和物體也是分開描述的。

讀者或許在小時候都玩過一個遊戲,每個同學發四張小紙條,在第一張紙條上寫上XXX 的名字,在 第二張紙條上寫上在什麼地方,在 第三張紙條上寫上一個動作,在 第四張紙條上寫一個物體,然後將這些字條分開放在四個箱子裡,再隨意地從這四個箱子裡各取一張紙條,就能組成很多非常搞笑的句子,例如張XX 在公園裡跳圓規之類的奇怪語句,一個班的同學常常笑得前仰後合。

遊戲雖然是遊戲,但說明了一個道理,只要有人、事、物和規則(定語),就能構成一個有意義的結果,無非是是否合理而已。分析類也是應用這個道理來把業務模型概念化的。由於所有的操作都通過邊界類來進行,能做什麼不能做什麼由邊界決定,所以邊界類實際上代表了原始需求中的“事”; 實體類則由業務模型中的領域模型轉化而來,它代表了現實世界中的“物”; 控制類則體現了現實世界中的“ 規則”, 也 就是定語;再 加上由參與者轉化而來的系統的“ 使用者”, 這 樣一來,“ 人”也有了。有了人、事、物、規則,我們就可以像那個遊戲一樣把它們組合成各種各樣的語句,只不過不是為了搞笑,所以不能隨意組合,而是要依據業務模型中已經描繪出來的用例場景來組合這些元素,讓它們表達特定的業務含義。

(1)業務模型:也稱企業模型,它為企業提供一個框架結構,以確保企業的應用系統與企業經常改進的業務流程緊密匹配。可以說,也就是說業務建模主要是從業務的角度而非技術角度對企業進行建模。典型的建模方法包括Zachman框架、ARIS HOUSE模型等,業務模型一般包括下面一些檢視:

(2)資料模型

(3)面向物件模型

(4)資料探勘模型

相關推薦

業務模型UML資料模型概念模型面向物件模型

因為欣賞所以轉載,原文地址 http://blog.csdn.net/sunleap/article/details/4976993 開發的流程有以下幾步:                物件圖 • 組織檢視:組織結構的靜態模型。包括:層次組織結構的人員(peop

uml和er中主外鍵的表示區別

合同 數據 引用 cnblogs nbsp 單獨 .cn .com 圖表 在er圖也就是數據庫中,無論是mysql/oracle都是從表引用主表的pk作為外鍵。 而在uml類圖表示法中,他們的順序則剛好相反,從主對象導向到子對象,如下: 主體是資金借款方,征信信息和資金借

UML學習

耗時 什麽 col 重要 employee 需求 好的 程序 相互 UML類圖學習 類 類(Class)封裝了數據和行為,是面向對象的重要組成部分,它是具有相同屬性、操作、關系的對象集合的總稱。在系統中,每個類都具有一定的職責,職責指的是類要完成什麽樣的功能

UML中的幾種關系總結

技術分享 name dos track text ive implement fonts 結構 UML類圖,描寫敘述對象和類之間相互關系的方式包含:依賴(Dependency)、關聯(Association)、聚合(Aggregation)、組合(Com

UML的關系詳解--轉

position 好的 -a erp 生命 靜態 pan 雙向 單選 http://www.uml.org.cn/oobject/201104212.asp 原文地址 UML類圖與類的關系詳解 2011-04-21 來源:網絡

深入淺出UML

功能 選擇 multipl 如何 成員 技術 eal 運行時 entity 在UML 2.0的13種圖形中,類圖是使用頻率最高的UML圖之一。Martin Fowler在其著作《UML Distilled: A Brief Guide to the Standard Obj

UML

ket tco protected col eject enter cts 關鍵字 attr 類圖用於描述系統中所包含的類以及它們之間的相互關系,幫助人們簡化對系統的理解,它是系統分析和設計階段的重要產物,也是系統編碼和測試的重要模型依據。 1. 類 類(Class)封

UML的關系詳解

enc pla 分享 包含關系 影響 基礎 rem 建模 基本組件 UML類圖與類的關系詳解 在畫類圖的時候,理清類和類之間的關系是重點。類的關系有泛化(Generalization)、實現(Realizati

用MyEclipse將java文件轉換成UML

lan 網上 uml b2c water 的人 通用 其他 gravity 用MyEclipse將java文件轉換成UML類圖 參考: 用MyEclipse將java文件轉換成UML類圖 - 君臨天下的博客 - CSDN博客 http://blog.csdn.net/da

設計模式之UML

es2017 mar log right 技術 style .cn images uml 設計模式之UML類圖

UML關系(泛化 、繼承、實現、依賴、關聯、聚合、組合)-轉

定位 雙向 圖關系 bst 操作 att one 一般來說 eal 繼承、實現、依賴、關聯、聚合、組合的聯系與區別 分別介紹這幾種關系: 繼承 指的是一個類(稱為子類、子接口)繼承另外的一個類(稱為父類、父接口)的功能,並可以增加它自己的新功能的能力,繼承是類與類或者

visio畫uml添加自定義數據

otg tor sao 數據類型 cso pat mfc big arc tj35jh辜夢妒苑鄖肇http://www.docin.com/dour993jbllm0掣智彜苯狹克http://tushu.docin.com/sina_58492473393j9l2y坎譚蝕浪

UML中的三種關系----關聯、聚合和泛化

ron 內存 gre 區別 分享 聚合 兩個 說明 鍵盤 一、關聯association 1、解釋說明:   表示兩種類實例間的關系。如果一個類的實例必須要用另一個類的實例才能完成工作時就要用關聯。關聯關系時在類中是使用實例變量來定義實現的。 2、在圖中,關聯用兩個類之間的

UML 說明

bsp 實現接口 protected cte 類圖關系 style 三角形 關聯 uml /*UML 類圖關系: *三角形 虛線 :實現接口 *箭頭 虛線 :依賴關系 *箭頭 實線:關聯關系 *空心菱形 實線 箭頭 :聚合(A 包含 B,但B不是A 的一部分)

UML詳解_關聯關系_多對多

col c++代碼 一個 image 技術 pub 每一個 push_back cnblogs 在關聯關系中,很多情況下我們的多重性並不是多對一或者一對多的,而是多對多的。 不過因為我們要考慮裏面的導航性,如果直接搞的話就是需要去維護兩群對象之間多對多的互指鏈接,這就

UML詳解_聚合關系

聚合 分享 產生 .com 特殊 begin blank .html 表達 結合UML關系,以看臺和基金來介紹聚合關系 aggregation,是一種特殊的關聯關系,既有關聯關系的特質,還獨有“整體 —— 部分(whole &md

UML概述、設計模式

占用 對象的訪問 關聯關系 參數類型 復雜度 可用 局部變量 工作 做出 深入淺出UML類圖(http://blog.csdn.net/lovelion/article/details/7843308) 類(Class)封裝了數據和行為,是面向對象的重要組成部分,它是具有

(轉)面向對象——UML設計

ges interface 變化 protect 兩個類 dep 規律 學習 另一個 背景:一直以來,對UMl類圖的畫法不甚理解,但是隨著學習的深入,發現熟練掌握UML類圖,能夠更好理解代碼間的邏輯性,而這也是程序設計的基礎所在,所以很有必要把UML好好掌握。 UML類圖

UML關系

.com 依賴關系 碼農 align jpg splay 接口 play 2-2   在UML類圖中,常見的有以下幾種關系: 泛化(Generalization),實現(Realization),關聯(Association),聚合(Aggregation),組合(Comp

UML關系總結

部門 子類 方法 屬性和方法 方法的參數 接口 com 生命周期 spa 在UML類圖中,常見的有以下幾種關系: 泛化(Generalization), 實現(Realization),關聯(Association),聚合(Aggregation),組合(Composit