上一篇，架构设计的UML图形思考 ，简单介绍了图形思考设计，表达设计对于架构师的重要意义，以及简单介绍了使用统一建模语言UML描述类以及类之间的继承关系，这种描述还停留在写代码，表达的可是说是如何写出类代码来，接下来我们要学习用UML表示业务的内涵，分析业务的内涵，加以抽象，将细节隐藏起来，用UML图象表现出来。
大多数情况下，一看到系统分析这个字眼，我们经常迷失于其字面的意义，以为分析的对象是「系统」，这是一种常见的迷失！其实，分析的对象是系统所处的「业务领域知识」(Domain Knowledge)才是正确的。就如同计算机专家James Martin所说：
「OOA不是要去分析实际的系统；而是用来分析人们对系统的专业认知和做法---- 从收集到的领域概念来分析出业务内涵。」
(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.)
所以系统分析的主要对象并非「系统」本身，而是分析专家们如何以其专业知识来叙述系统，亦即，专家心中的「业务(领域)知识」才是系统分析的主要对象。所以焦点是业务知识(Domain Knowledge) ，而不是系统。
业务(领域)知识 = 业务内涵：
分析系统的内涵，抽象，表达，让开发者懂得业务的内涵
依据专业知识找到相应的类，相应的对象，用UML表达出来
业务(领域)概念
知识的组成要素是「概念」(Concepts)。
◎ 领域知识(Domain Knowledge)的组成要素是领域概念(Domain Concepts)。
◎ 概念有它的属性(Attribute)，概念之间有其关系(Relationship)。
◎ 系统分析(或OOA)就是要分析领域知识里的概念，并以UML的类别(Class)等示来表示之。
概念(Concept)是抽象的，代表一群实体，是沟通的重要媒介。
「概念是人人互相分享的。概念提供了能让人人互相了解的共通词汇。」
(Concepts are shared by others. Concepts provide the common vocabulary for communication.)
例如：「请买杯咖啡」，咖啡是个概念，具有这种概念的人，都会了解这句话的意思。他会凭其经验而想到真实的咖啡。
◎ 概念代表一个群体---- 「类别」(Class)，人们藉由天赋的能力运用经验去想到其所代表的实际东西---- 「对象」(Object)。
例如您听到「买一只吉他」，这「吉他」概念让您想到经验中的吉他，而去乐器行买一只「真实的吉他」回家。
找出领域知识里的概念，就是找出软件系统的对象和类别。
◎ 例如麦当劳企业有汉堡、薯条、玩具、特餐、点餐、订购玩具、顾客、员工、玩具商、分店等等的概念，将对应到软件系统的类别，所以在麦当劳的软件系统里就会有汉堡、薯条、玩具、特餐、点餐、订购玩具、顾客、员工、玩具商、分店等等的类别。
『后羿从西王母处请来不死之药，嫦娥偷吃了这颗灵药，成仙了，身不由主飘飘然地飞往月宫之中，在那荒芜的月宫之中度着无边的寂寞岁月。』
虽然嫦娥可能是传说虚构的，并非事实(Reality)，但是确确实实是我们心中的清晰概念，传说中的主角，所以是个重要的类别，表示如下：
跟「嫦娥」具有密切关联的概念是：月亮
和仙丹，常表达如下：
不仅上述的名词概念而已，其攸关的动作也常是重要概念。动词常常代表一项事件(Event)的发生，而人们常从人、事、时、地、物等去描述一个事件的发生情境。
◎ 譬如，吃仙丹就有动作(吃)的对象---仙丹，动作的主角---嫦娥，当然还有地点、时间，甚至仙丹来源等等。
在传统观点里，大多先绘制UML模型图，然后才开始构思程序码的撰写，使得UML建模成为撰写程序码的前置工作，因此许多程序员将UML建模视为多余的负担。为了节省开发成本，就将省略掉UML建模的工作了。在新潮的观点里，UML模型与代码是软件系统本体的两个观点(或面向)，两者没有先后顺序关系，而是并存和兼具于同一个人的脑海里。这就像两只眼睛看到的景象并存于一个人的脑海里一般，如此才能看到更真实的世界，也能做出更完美的软件系统来。
原文地址：http://blog.csdn.net/yanfeivip8/article/details/39828347
