《大象:thinking in uml 》(第二版) 11章 系统分析 3-4节 用例实现、软件架构和框架

只供参考,喜欢请支持正版图书

一个用例可能有多个用例实现,每个用例实现都是设想的一种实现方式。虽然实现方式和过程不同,但目的是相同的,同样要达到用例所规定的系统目标。为了表示出用例实现与它所实现的用例之间的关系,我们可以用图11.13来表示。这幅图表明了实现到需求之间的追溯关系
在这里插入图片描述

11.3.2 现在行动:实现用例

在5.6.3分析模型的意义一节中作者介绍过,分析模型是采用MVC模式,将用例场景中描述的业务分解为边界(操作界面和展示界面)、控制(业务逻辑)和实体(业务数据),用这三个元素建立实现用例场景的对象模型。于是边界类对象、控制类对象和实体类对象就成为我们用来实现用例的关键对象

要为用例实现建模,我们需要经过以下三个步骤

第一步,我们需要在用例场景当中发现和定义实体对象。这些实体对象代表了我们将要操作的业务数据。发现和定义实体对象的方法很简单,在这个用例场景当中,每一个活动都是由动词+名词构成的,这些名词就是我们要寻找的实体。

第二步,我们需要用控制对象来操作和处理实体对象中的数据。在初步实现用例的时候,我们可以简单地为每一个实体对象加上一个控制对象。每个控制对象操作一个实体对象,它默认地包含所有对该实体对象的处理逻辑。

第三步,我们需要用边界对象来构建接收外部指令的界面。边界对象负责接收来自系统外部的指令,并将指令传达给控制对象,控制对象根据指令执行相应的逻辑程序,然后将结果返回给边界对象。最后再由边界对象将结果展示给外部。
在这里插入图片描述在这里插入图片描述在这里插入图片描述图11.16 批量申请登记用例实现场景
在这里插入图片描述图11.17 sur_批量申请登记用例实现

至此,两个用例实现场景绘制完毕。在绘制过程中,我们得到了一些关键对象以及这些关键对象的方法。接下来我们把这些关键对象集中在一个图里,定义它们的关系,就得到了分析类图,如图11.18所示
在这里插入图片描述图11.18 申请登记分析类图

11.3.3 进一步讨论

为什么用分析类而不是设计类来实现用例场景

分析类是从业务需求向系统设计转化过程中最为主要的元素,它们在高层次抽象出系统实现业务需求的原型,业务需求通过分析类被逻辑化,成为可以被计算机理解的语义。分析类的抽象层次高于设计实现,高于语言实现,也高于实现方式

可以看到,由于分析类的抽象层次较高,基本上停留在“概念”阶段,相对于设计实现、语言实现、实现方式这些较低抽象层次的工作来说,需要考虑的信息量要少得多,而能够让分析工作专注在实现需求上。相对于设计模式、编程风格这些因素来说,忠实地实现需求才是第一位的。另外,也由于分析类的抽象层次较高,概括能力就很强,也就比设计和实现要稳定。在一个演进式的软件生命周期里,维护稳定的分析类比维护易变的设计类要投入更少的精力,更容易获得一个稳定架构来指导整个软件的开发

11.4 软件架构和框架

11.4.2 什么是软件架构

软件架构是一种思想,一个系统蓝图,对软件结构组成的规划和职责设定

11.4.3 什么是软件框架

软件框架是软件架构的一种实现,是一个半成品

11.4.4 软件架构的基本构成

在这里插入图片描述在这里插入图片描述在这里插入图片描述在这里插入图片描述

只供参考,喜欢请支持正版图书
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值