上一篇，架构设计的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模型与代码是软件系统本体的两个观点(或面向)。两者没有先后顺序关系，而是并存和兼具于同一个人的脑海里。

这就像两仅仅眼睛看到的景象并存于一个人的脑海里一般。如此才干看到更真实的世界。也能做出更完美的软件系统来。