首页 > 代码库 > UML应用:业务内涵的分析抽象&表达
UML应用:业务内涵的分析抽象&表达
上一篇,架构设计的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模型与代码是软件系统本体的两个观点(或面向),两者没有先后顺序关系,而是并存和兼具于同一个人的脑海里。这就像两只眼睛看到的景象并存于一个人的脑海里一般,如此才能看到更真实的世界,也能做出更完美的软件系统来。
UML应用:业务内涵的分析抽象&表达