.前言
谈到面向对象技术的分析和设计,自然就离不开UML。对于UML这个概念,很多程序员朋友耳熟能详,也有在用,但在工作中,一些朋友其实并不擅长使用UML甚至对UML这个东西模棱两可,也包括我自己。因此我希望可以结合自己的经验和实践,写一篇UML的入门文章,帮助做面向对象的程序员朋友能更好的利用它,从而顺利完成自己的编程设计工作。
.从一个示例开始先举个现实世界的例子。我们上大学的时候,作为学生,每人都有一张学生证,会归属到一个班级,上学时可能会用到自行车。很多同学还会考驾照,挑放假时间练车,车可能是轿车也可能是皮卡。
如果想通过在线的方式记录以上的信息和行为,在软件世界中如何表达呢?
相信很多朋友的操作是,找到这段话里的主语和宾语,也就找到了这个例子中涉及的角色,然后通过动词来判断各个角色之间的关系和能力,最后用代码的方式来表达,产出可执行的程序。
像下图这样,识别出关键的实体和它们之间的关系。
用软件工程的方式,解决现实中的问题,是信息时代最明显的特点,这让我们的生活和工作变得更加便利。
但现实世界错综复杂,灵活多变,每个人的理解可能会有不同,从现实世界到软件世界的映射,就变得困难重重,一团乱麻。
如何让现实世界到软件世界映射变的简单容易,这就是UML要解决的问题。
.什么是UMLUML全称是UnifiedModelingLanguage(统一建模语言),它以图形的方式来描述软件的概念。
.为什么称UML为语言先说语言,为什么UML被称为语言?
名称的落脚点是语言。既然是语言,那么它就会具备语言的特性,比如结构上它由词汇和语法构成,功能上它能解决沟通问题。
你熟知的语言里比较多的应该是汉语和英语,如果从事软件行业,C语言和Java语言你应该也不会陌生。英语和Java语言明显都是语言,却常常不被放在一起讨论,为什么?因为它们是不同维度的语言。英语是解决现实世界中人与人之间沟通问题的人类语言,Java是解决软件世界中程序员与计算机之间沟通问题的计算机语言。
人类语言本质上是事实和观点的表达,计算机语言本质上是0和的表达。前者的表达形式是难以确定的,而且可能会产生歧义,所以才会有「被误解是表达者的宿命」这样的观点,但后者就是确定性无歧义的0表达。
这么看来,UML的目标是通过一定结构的表达,来解决现实世界到软件世界的沟通问题。
.什么是建模再说建模,模是什么,需要怎么建?
建模简单讲,是指通过抽象的方式解决某个领域的问题。各个抽象角度共同组成了一个问题领域。
对于传统模型而言,建造它是为了证明这个问题领域下某件事物能否工作。当然它有前提,即建造模型的成本远远低于建造实物的成本。比如造飞机或造高楼。
对于软件模型而言,建造它是为了与他人沟通,也为了保存这个问题领域下软件设计的最终成果。当然它也有前提,就是模型比代码更说明问题。
比如购物这个问题,甲可以在淘宝上买衣服,乙可以在亚马逊上买书,丙可以在京东上买手机。
谁买东西?是甲、乙和丙,他们都能抽象成人。
买什么东西?有衣服、书和手机,它们都能抽象成货。
在哪里买?在淘宝,亚马逊和京东,它们都能抽象成场。
整体抽象一下就是人到场里买货。所以购物这个场景所抽象出来的人货场,就用来解决零售领域的问题。当然还可能会有些规则,比如成为注册会员才能发生交易。
我们会发现,一个特定的事件(比如购物)里,会有特定的人的行为(比如甲乙丙要上电商网站),会有特定的物(比如货),有特定的规则(比如注册会员),共同完成购物这件事。
特定的事=特定的人的行为+特定的物+特定的规则在人货场这个抽象角度里,就会涉及到很多特定的事,包括会员注册,会员下单,会员支付,商家发货,快递公司邮寄等等。
模简单讲,就是人、事、物和规则。
人是一切的中心,人要做事,做事就会使用一些物并产生另一些物,同时做事需要遵循一定的规则。
人驱动系统,事体现过程,物记录结果,规则是控制。
建立模型的关键就是弄明白有什么人,什么人做什么事,什么事产生什么物,中间有什么规则,再把人、事、物之间的关系定义出来,一个模型也就基本成型了。
.统一的意义在哪里统一的普遍意义是形成标准。所谓标准,就是所有人都明白的表述,所有人都遵从的格式。标准可以让信息在人群中无障碍地流通,即使这些信息来自不同地域、不同文化、不同社会或不同组织。
比如美元作为国际统一使用的货币方便了全球的经济贸易,我们国家普及普通话方便了不同地区的交流沟通。
在软件世界,任何一种组件化开发模式背后都有一个标准在规范和指导,比如Java的JSR标准。有了标准,编程就容易组件化,协作效率也会提升很多。对UML来说,这就是统一的意义。
.为什么需要UML一个软件项目要经历业务调研、立项、需求采集、架构设计、编码开发和测试验证等多个环节。
每个环节可能角色并不相同,同样的文档同样的话语越向后传递就越容易失真。因此就容易出现最终交付的产品不是客户真正想要的这种情况。
如何避免角色间信息传递的失真,保证信息能被准确的传达和准确的理解?一种好的办法就是大家使用标准化的语言。
统一建模语言(UML)就试图用标准化的语言来覆盖整个软件过程,让不同团队不同角色可以用相同的语言顺畅的沟通。
在信息传播方面,图形相对于文字,人脑的接受能力显然更强。因此,UML采用了「可视化」的图形方式来定义语言。
5.UML的适用场景UML既可以描述某个问题领域,也可以表达构思中的软件设计,还可以描述已经完成的软件实现。
它适用于面向对象分析设计的整个过程。这个过程可以分为三个阶段,如下图。
第一个阶段是通过建模将现实世界转为业务模型。业务模型真实映射了参与者(业务活动的驱动者)在现实世界的行为。
从图里可以看到,现实世界映射到业务模型后,是使用参与者和用例这两个UML的核心元素表达的。参与者作为一个特定事件的驱动者,用例则描述了这个驱动者的业务目标。文章后边也会提到这两个元素。
第二个阶段是对业务模型概念化,建立适合计算机理解和实现的模型,也就是概念模型,或者叫分析模型。分析模型向上映射了原始需求,向下为计算机实现规定了一种高层次的抽象,是一种过渡模型。
现实世界千差万别的业务,都用边界、控制和实体这几个核心元素来描述,同时也引入了包、组件这些与现实世界毫不相干的概念做包装。
第三个阶段是对概念模型实例化,得到相对详细的设计模型。
在设计模型中,概念模型中的边界类可以被转化为操作界面或者系统接口;控制类可以被转化为计算程序或控制程序,例如工作流、算法体等;实体类可以转化为数据库表、XML文档或者其他带有持久化特征的类。
同样的概念模型会因为选择不同而得到不同的设计模型。比如技术选型上使用不同的编程语言,不同的中间件就会得到不同的设计。
为什么需要这一道转换呢?
因为“边界”、“控制”、“实体”这些对象化的概念,虽然是计算机可以理解的,但它并不是真正的对象实例,也就是说它们并不是可执行代码,概念模型只是纸上谈兵。真正的对象世界行为是由Java类、C++类、JSP等这些可执行代码构成的。
换句话说,设计模型是概念模型在特定环境和条件下的实例化,实例化后的对象行为执行了概念模型描述的那些信息。
以下是面向对象分析设计的完整过程,它表达了现实世界是怎么通过UML映射到对象世界的。
6.UML的组成结构前面花了比较大的篇幅分析了UML的定位和适用场景,目的是帮助读者建立对UML整体系统性的认知,而不是过早的陷入UML的使用细节里。我们要应用一项技术或工具,不能单纯的因为它的酷炫或者说业界都在用所以我们要用,而应该结合自己的使用场景以及技术或工具的特点,来确认这项技术或工具究竟是不是我们需要的。
在读者了解UML在面向对象分析设计领域优秀的特性之后,我们再来看看UML的一些细节。
凡是语言,都会存在基本词汇和语法。
那么对应到UML里,基本词汇就是核心元素,语法就是核心视图。
UML的组成结构如下图:
6.核心元素我们先介绍核心元素。
6..版型版型:也称「类型」或「构造型」。是对UML元素基础定义的扩展,在元素基础定义的基础上赋予特别的含义,使得这个元素适用于特定的场合。
比如,我们前边提到的「边界类」、「实体类」、「控制类」都是类的版型。
6..参与者参与者定位:事件的第一驱动者,也是系统的服务方。比如你在电商网站购物,你就是参与者。
6..用例用例定位:系统执行的一系列操作,并生成参与者可以观察的值。比如你在电商网站交易,会生成在线订单,用户下单就是一个用例。
用例版型:
业务用例:用于需求阶段业务领域建模。与计算机系统建模无关,比如下单可以不依赖在线服务,而只是线下签署协议。业务建模的目标是让需求人员和客户能够达成共识;业务用例实现:业务用例的一种实现方式,一个业务用例可以有多种实现方式。比如下单后的支付,可以用现金,也可以银行卡转账,还可以第三方支付。概念用例:用于获取业务模型中的关键概念,分析出核心业务结构。业务架构就是概念建模阶段产生,同时为系统建模阶段提供重要指导。比如用户下单这个用例,可以从实现过程中获得一些核心业务,并把它们展现出来。系统用例:用于定义系统范围、获取功能性需求。也就是我们常挂在嘴边的用例。像业务用例中提到的线下签约的方式,就不会纳入到系统用例中,但如果是电子签约的话,就可以成为系统用例了;系统用例实现:系统用例的一种实现方式,一个系统用例可以有多种实现方式。比如下单后的支付,可以接入