概念模型

概念模型是對真實世界中問題域內的事物的描述，不是對軟體設計的描述。概念的描述包括：記號、內涵、外延，其中記號和內涵（視圖）是其最具實際意義的。

基本介紹

• 中文名：概念模型
• 外文名：CONCEPTUAL MODEL
• 領域：數學
• 包括：記號等
• 性質：數據模型

定義

概念模型表征了待解釋的系統的學科共享知識。為了把現實世界中的具體事物抽象、組織為某一資料庫管理系統支持的數據模型，人們常常首先將現實世界抽象為信息世界，然後將信息世界轉換為機器世界。也就是說，首先把現實世界中的客觀對象抽象為某一種信息結構，這種信息結構並不依賴於具體的計算機系統，不是某一個資料庫管理系統（DBMS）支持的數據模型，而是概念級的模型，稱為概念模型。

簡介

概念數據模型是面向用戶、面向現實世界的數據模型，是與DBMS無關的。它主要用來描述一個單位的概念化結構。採用概念數據模型，資料庫設計人員可以在設計的開始階段，把主要精力用於了解和描述現實世界上，而把涉及DBMS的一些技術性的問題推遲到設計階段去考慮。

讓讀者更易理解，讀時有個參考的東西。

由於概念模型用於信息世界的建模型，是現實世界到信息世界的第一層抽象，是用戶與資料庫設計人員之間進行交流的語言，因此概念模型一方面應該具有較強的語義表達能力，能夠方便、直接地表達套用中的各種語義知識，另一方面它還應該簡單、清晰、易於用戶理解。由於概念模型在此次的疊代過程非常簡單，所以本來計畫PASS掉其中的具體分析，不過概念模型的確非常之重要，他是OOD的一個基石。除了用例，應該說概念模型是OO開發過程中另一個充滿主觀色彩的工件。

然而不同的人對同一個場景進行研究，可能提煉出來的概念模型都不一樣，所以說這是頗受主觀認識影響的一個過程。然而，概念模型的質量對整個系統的影響至關緊要，因為，所謂的面向對象，就是從這裡開始。

一般來說，構建概念模型的過程與程式設計師的關係並不大。最適合進行這項活動的人，應該是那些有較深資歷的領域專家，極端一點，甚至可以就是最為熟悉自身業務流程的客戶代表。只要稍稍學習簡單的建模知識，他們就可以勝任了。技術出身的人要做好這個工作，在開始之前他可能首先需要做的就是:忘掉VB，忘掉JAVA，忘掉.Net, 忘掉C++ 。。。

不過，作為開發人員，我比較認可一個思維跳出技術的條框，學習真正從“映射現實世界”的角度考慮問題的好辦法，就是——假想一下，自己正在通過某部電影的故事來製作一個RPG遊戲，電影裡的橋段與遊戲中的場景相對應，然後思考,其中需要表達哪些不同概念。好吧，試著弄一個簡單的例子，這裡，我用《無間道》來試試（不要笑我eld啊）。

構建模型

構建概念模型，需要從場景中提取各種“對系統目標有用”的概念。通常的方法是通過識別主要的領域辭彙，或者通過已有的概念目錄檢查表來查找。由於時間關係，我已經預先想好了一些。看過的朋友知道，像“臥底”、“警察”、“黑社會”、“情報”等等，都是《無間道》這部電影裡的一些核心概念。很自然地，開始時我會傾向於發展這樣一個模型：(見右圖)

這樣看起來比較直觀。“警察”和“黑幫成員”是兩個較大的概念，下面分別有較小的兩個子概念。像黃Sir和韓琛這樣的角色，是可以很直接地歸入到“正規警察”和“普通黑幫成員”的範圍中去的，而陳永仁和劉健明都分別屬於不同的臥底角色。但這樣出現了一個問題，就是陳和劉都是同時具有警察、黑幫的雙重身份（儘管一個在明，一個在暗）的人，他們都有可能同時擁有警察和黑幫的某些行為。比如陳永仁在擁有黑幫“劈友”，“收數”的行為時，也有可能執行警察“逮捕”，“救死扶傷”這樣的責任，劉健明表面上是警察，暗中也有進行黑幫“洗錢”的行為。兩個人的行為相似，但本質立場不同，怎樣在模型中表達出這樣的概念呢？

用例的概念模型

曾經也想過將“臥底”同時作為“警察”和“黑幫成員”的子概念，但覺得這樣比較複雜且僵硬，實現起來也不容易（對不起，我又想到實現了）。後來覺得可以試試將“身份”和“行為”概念提取出來，於是建立下面這樣的一個模型(見右圖)：在這個模型中，每個人物可以機動地擁有1個以上的身份，多個行為。每個行為也可以與特定的身份掛鈎。這樣的話，對表達不同角色的複雜身份就可以比較靈活了。對陳、劉之間的本性問題，又引入“價值觀”這樣的概念描述。但可以看到，改變後的模型複雜度提高了，尤其當人物的“行為”很多的時候，就可能會在其下面出現比較大的概念群了。

用例的概念模型

系統的靈活性和複雜度的矛盾，是在提煉概念模型時必須慎重思考的問題。

可想而知，如果真的要做成RPG的話，更多的概念需要被提取出來。譬如“情感”、“人際關係”、“情報”、“武器”、“女朋友”。。。。。。由於時間關係，就不在這裡亂唱了。這次做的這個粗陋的模型，就權當拋磚引玉吧。

找出模型

最好是能夠儘量充分地使用細粒度的概念來描述模型，而避免粗略描述。

這是書中推薦的一條指導原則，我沒有從正面理解也沒有找到論據去推翻他，這是讓我困惑的地方。其他一些指導性的原則包括：不能簡單地因為需求說明中沒有明顯的要求保留某個概念的信息或是概念中沒有屬性，就去掉概念，在問題領域中，那些只擔當純行為的概念也是存在的。其後便是一個用於搜尋概念的‘黑名單’，這讓我更覺得不可思議，為什麼是這樣一個長長的黑名單而不是幾條簡潔的依據。最後我還是決心把他抄一遍：

概念類目	舉例
物理的或實在的對象	銷售點終端、飛機
規格說明、設計或者事物的描述	產品規格說明、航班描述
地點	商店、機場
事務	銷售、支付、預定
線上事務處理項	線上銷售項
人的角色	出納員、飛行員
包含其他事物的包容器	商店、銀行識別號、飛機
被包含在包容器內的事物	銷售商品項、乘客
系統外部的其他計算機系統或機械電子設備	信用卡授權系統、空中交通控制系統
抽象的名詞性概念	飢餓的人、恐高症
組織	銷售部、對象航線
事件	銷售、搶劫、會議、出航、墜機、著陸
過程（通常不用概念來表達，但有時也會用概念來表達過程）	出售一個產品的過程、預定一個座位的過程
規則和策略	退貨政策、取消政策
目錄	產品目錄、零件目錄
財政收支、工作情況、契約等的記錄	收據、分類帳目、僱傭契約、維護日誌
金融工具和服務機構	信用卡、股票
手冊、書籍	雇員手冊、修理手冊

抄完了一遍，沒有找出一個通用性的指導原則，書中接下來給出的是根據名詞性短語找出概念，這讓我想起了某一期的程式設計師中有關於建模的文章，其中的概念模型的建立就是說根據名詞來找，想來這是一種極其幼稚的做法了，其中還有這樣一種情況，某些名詞只作為對象的屬性。

建模過程

1，運用概念目錄列表或名詞性短語找出問題領域中的後選概念

2，繪製概念到概念模型圖中

3，為概念添加關聯關係

4，為概念添加屬性

模型設計

概念模型設計

概念模型不依賴於具體的計算機系統，他是純粹反映信息需求的概念結構。

建模是在需求分析結果的基礎上展開，常常要對數據進行抽象處理。常用的數據抽象方法是‘聚集’和‘概括’。

E-R方法是設計概念模型時常用的方法。用設計好的ER圖再附以相應的說明書可作為階段成果

概念模型設計可分三步完成：

局部模型

① 確定局部概念模型的範圍

② 定義實體

③ 定義联系

④ 確定屬性

⑤ 逐一畫出所有的局部ER圖，並附以相應的說明檔案

全局模型

建立全局E-R圖的步驟如下：

① 確定公共實體類型

② 合併局部E-R圖

③ 消除不一致因素

④ 最佳化全局E-R圖

⑤ 畫出全局E-R圖，並附以相應的說明檔案。

模型評審

概念模型的評審分兩部分進行：

第一部分是用戶評審。

第二部分是開發人員評審。