By 高焕堂 2010/11/01
Android_OOAD分析&设计
领域(Domain)分析方法：表达专业领域知识
1. 领域知识分析
当您学习做系统分析(System Analysis)时候，常迷失于其字面上的意义，以为分析的对象是「系统」，这是一种常见的迷思! 其实，分析的对象是系统所处的「领域专业知识」(Doamin Knowledge)才是正确的。就如同计算机专家James Martin所说：
“Object-oriented analysis is not an approach that models reality. Instead, it models the way people understand and process reality ---- through the concepts they acquire. ” (OOA不是要去分析实际的系统；而是用来分析人们对系统的专业认知和做法---- 从收集到的领域概念来分析出专业知识。)
系统分析的目的是要表达特定应用领域(Application Domain)里的专业知识(Domain Knowledge)，然后将这专业知识转换为计算机可读之程序(Program)，就能顺利存入计算机中，此时计算机就拥有专业知识了，执行程序时，计算机就能展现出专业的行为，提供专业的服务了。所以系统分析的主要对象并非「系统」本身，而是分析专家们如何以其专业知识来叙述系统，亦即，专家心中的「专业知识」才是系统分析的主要对象。所以焦点是专业知识而不是系统。
知识的基本组成要素是「概念」(Concepts)。领域知识(Domain Knowledge)的组成要素是领域概念(Domain Concepts)。概念有它的属性(Attribute)，概念之间有其关系(Relationship)。在当今的面向对象计算机语言里，都有类别(Class)机制，类别有其属性，类别之间也有其连结关系。面向对象分析(OOA)就是要分析领域知识里的概念，并以计算机语言的类别机制来表示之，然后将之存入计算机中，让计算机拥有专业知识，提供专业的服务。
2. 何谓领域概念
什么是「概念」(Concept)呢？它是抽象的，代表一群实体，是沟通的重要媒介。例如：「请买杯咖啡」，咖啡是个概念，具有这种概念的人，都会了解这句话的意思。他会凭其经验而想到真实的咖啡。概念代表一个群体---- 「类别」(Class)，人们藉由天赋的能力运用经验去想到其所代表的实际东西---- 「对象」(Object)。例如您听到「买一只吉他」，这「吉它」概念让您想到经验中的吉他，而去乐器行买一只「真实的吉他」回家。一般而言，概念包括3个基本要素：
- 符号(Symbol) --- 代表它的文字、图形或影像。
- 涵意叙述(Intension) --- 它的明确定义。
- 代表的东西(Extension) --- 它所代表的群体。
例如，Sale是符号，大家都知道它的含意是：表示一个卖出商品的事件。大家也能想到实际的交易情况。所以Sale是一个概念。在不同的领域里，Sale的定义可能不同，代表一群不同的事物，为不同的概念。像Sale、Order、Purchase等代表一向交易事件(Event)，皆是重要的概念。至于像Receipt、Invoice、Ticket等皆为重要的概念。这些概念的符号，自然成为领域专家或知识工作者之间互相沟通的主要字汇(Vocabulary)。因此在叙述领域的相关文件里，常用字汇是此领域里的主要概念符号。找出领域知识里的概念，就是找出软件系统的对象和类别。找出软件系统的对象，就像寻找水的组成元素---- H与O。例如麦当劳企业有汉堡、薯条、玩具、特餐、点餐、订购玩具、顾客、员工、玩具商、分店等等的概念，将对应到软件系统的类别，所以在麦当劳的软件系统里就会有汉堡、薯条、玩具、特餐、点餐、订购玩具、顾客、员工、玩具商、分店等等的类别。
3. 举例之1：东方传说
『后羿从西王母处请来不死之药，嫦娥偷吃了这颗灵药，成仙了，身不由主飘飘然地飞往月宫之中，在那荒芜的月宫之中度着无边的寂寞岁月。』
虽然嫦娥可能是传说虚构的，并非事实(Reality)，但是确确实实是我们心中的清晰概念，传说中的主角，所以是个重要的类别，表示如下：
继续可发现与它有密切关联的概念：月亮和仙丹，就表达如下：
不仅上述的名词，其攸关的动作也是概念，例如：
所以人们是藉由心中的概念来认知领域中的事物，并传播给别人，与人分享；而OOAD和UML模式则表达人们心中的概念，也就是表达人们对领域中事物的认知。
4. 举例之2：西方童话
例如，童话『青蛙王子』的故事中，青蛙与公主约会是一个Use Case。其Use Case的叙述文件，如下：
|
用例编号： |
UC-Frog-10 |
|
|
系统用例名称： |
DateWithPrincess |
|
|
目的： |
Frog期待与Princess约会，并能娶到她 |
|
|
系统名称： |
青蛙王子童话故事 |
|
|
启动者： |
Frog |
|
|
程序1(主要程序Normal Scenario)： |
||
|
Frog的动作 |
Princess的反应 |
|
|
1. 青蛙要求与公主约会 |
2. 心情愉快的公主亲吻牠 |
|
|
3. 王子化身的青蛙立即变成英俊的王子，青蛙的心情很快乐 |
||
|
程序2(替代程序Alternative Scenario)： |
||
|
3a. 因为不是王子化身，所以青蛙仍然是青蛙，青蛙的心情不快乐。 |
||
|
程序3(替代程序)： |
||
|
2a. 心情不愉快的公主不愿意亲吻牠。 3a. 王子化身的青蛙很失望地离开了。 |
||
|
程序4(替代程序)： |
||
|
2a. 心情不愉快的公主不愿意亲吻牠。 3a. 青蛙很失望地离开了。 |
||
很明显地，故事的主角是：
牠希望公主亲牠，又找到两个概念：
如果青蛙变成王子，就又找的一个概念了：
上述的过程是有一定顺序的，先去了解领域专家(Domain Expert)脑海里的主要概念，也了解他们所代表的事物，并且以概念作为系统建模(Modeling)基础；分门别类之后，以UML的类别图示(Class Notation)表达概念，以类别图(Class Diagram)表达概念之间的涵义关系。
5. 举例之3：餐馆点餐
兹再看一个例子：『餐馆点餐』，其发展之步骤如下：
Step-1: 从最明显的重要事件出发。其实，概念存于许多地方，并且担任知识沟通的媒介。例如，餐厅人员与客人沟通的主要媒介是菜单如下：
Step-2: 联想到OrderLine和餐点：
Step-3: 从餐点联想到它可分为单点菜色，以及套餐两大分类：
Step-4: 从单点之菜色又分为牛排、色拉和饮料等不同之分类，如下：
Step-5: 还可以继续联想下去，例如「色拉」又可以细分为水果色拉、凯萨色拉等等，则整个UML类别图，就更加完整了。
刚才，我们将青蛙和王子视为两个不同的概念。然而在Real-time或Embedded领域，却常常采取不同之观点：将青蛙和王子视为「青蛙王子」的两种状态(State)。也就是说，青蛙王子兼具(继承)青蛙与王子之特性，而Frog和Prince则是牠的两个状态。在企业界也常见这两种不同观点，例如保险业里，可发现两种重要概念：「要保书」和「保单」。另一个观点是：两者是同一概念的两种状态，未签约成交者，称为要保书，其签约之后，就变成为保单了。这种状态变化之观点，是Real-time和Embedded领域专家所采用。[歡迎光臨 高煥堂 網頁： http://www.cnblogs.com/myEIT/ ]
事件的发生常导致某些对象的状态变化，例如爱人离开了，心情变差了。对象状态常引发某些行为，例如失恋心情下会吃香蕉皮。一样地，可以看看青蛙王子故事里有那些事件发生呢？首先找到了一个事件：公主亲吻恶心的青蛙，青蛙王子就从「青蛙」状态，转变为「王子」状态：
- Event: Princess kiss frog,
- 状态变化(反应): Frog 变成 Princess
兹以UML状态图表达如下：
这个状态变化，引发了新的事件：英俊王子呈现于公子面前。此事件又让公主从「恶心」状态转变为「愉快」状态：
- Event: 出现英俊王子
- 状态变化(反应): Princess 心情由恶心变成愉快
后来两人结婚，又是一个重要事件，它导致诞生新对象：家庭。然后三个对象会继续触发更多型态的事件，引发形形色色的状态变化。例如，结婚事件让两人从「甜蜜浪漫」状态逐渐转变为「幸福快乐」之状态：
- Event: 两人结婚
- 状态变化(反应): 幸福快乐
以上说明如何藉由UML来建立领域知识的模型。◆
[Go Back]
