3.3 软件需求:面对对象分析模型
面对对象分析模型
- 1、对象
- 2、面对对象的软件开发模型
- 3、用例图建模基础
- 3.1 用例图基本符号
- 参与者
- 用例
- 系统
- 执行关联
- 3.2 用例建模过程
- 3.3 用例图初步
- 3.4 用例图进阶
- 关联Association
- 泛化Inheritance
- 包含Include
- 扩展Extend
- 示例
1、对象
在现实世界中有意义的,与所要解决的问题有关系的任何事物都可以作为对象,包括具体的物理实体的抽象、人为的概念、任何有明确边界和意义的东西。如:一名职工、一本图书、贷款、生产计划、一场演出等。
一个对象通常由 对象名、属性和方法(操作) 三部分组成。
几种著名的面对对象方法:UML
- Booch方法(1991)
- Coad- Yourdon 方法(1991)
- Rumbaugh方法(简称 OMT)(object Modeling Technology1991 )
- Jacobson 方法(简称 OOSE,1992)
- 由 Rumbaugh、 Booch、Jacobson 提出的统一建模语言(简称UML)( Unify Modeling Language ,1994 ):一种可视化建模语言,能描述开发需要的各种视图,并以此为基础组建系统。
- 消息。对象之间进行通信的一种构造叫做消息。消息响应
- 类。一组大体相似的对象。一个类所包含的方法和数据描述了一组对象的共同行为和属性。类是对象之上的抽象,对象是类的具体化,是类的实例。
- 继承。继承是父类和子类之间共享数据和方法的机制。一个父类可以有多个子类,一个子类也可以有多个父类。
- 多态。对象收到消息时,要予以响应。不同对象收到同一消息可以进行不同的响应,产生完全不同的结果,这种现象叫做多态。
- 动态绑定。当一个对象发送消息请求服务时,要根据接受对象的具体情况将请求的操作与实现的方法进行结合叫做动态绑定。
- 面对对象原则
- 单一责任原则。让一个类只做一种类型责任
- 开关原则。可修改,不封闭
- 里氏替换原则。在任何父类可以出现的地方,都可以用子类的实例来赋值给父类型的引用。
- 依赖倒置原则。高层模块不应该依赖于低层模块,二者都应该依赖于抽象;抽象不应该依赖于细节,细节应该依赖于抽象。
- 接口分离原则。依赖于抽象,不要依赖于具体,同时在抽象级别不应该有对于细节的依赖。这样做的好处就在于可以最大限度地应对可能的变化,即使用多个专门的接口比使用单一的总接口总要好。
2、面对对象的软件开发模型
- 数据模型(对象模型):描述系统数据结构的对象模型。
- 行为模型(动态模型):描述系统控制结构。
- 功能模型:描述系统功能。
一个典型的软件系统使用数据结构(对象模型),执行操作(动态模型),并且完成数据值的变化(功能模型)。
3、用例图建模基础
3.1 用例图基本符号
用例建模用于描述系统需求,把系统当作黑盒,从用户的角度,描述系统的场景。主要图形元素有:
参与者
外部用户或外部实体在系统中扮演的角色,需要使用系统或与系统交互的东西,可以是一个人、一个计算机子系统、硬件设备或者时间等角色。
-
如何确定参与者?
在获取用例前首先要确定系统的参与者,开发人员可以通过回答以下的问题来寻找系统的参与者。- 谁将使用该系统的主要功能?
- 谁将需要该系统的支持以完成其工作?
- 谁将需要维护、管理该系统,以及保持该系统处于工作状态?
- 系统需要处理哪些硬件设备?
- 与该系统交互的是什么系统?
- 谁或什么系统对本系统产生的结果感兴趣?
-
示例:饮料自动售卖系统
每一个参与者都有自己的执行关联。
用例
-
定义:对一组动作序列的描述,系统通过执行这一组动作序列为参与者产生一个可观察的结果。用例名往往用动宾结构命名。
-
特征:
- 说明了系统具有的一种行为模式;
- 说明了一个参与者与系统执行的一个相关的事件序列;
- 提供了一种获取系统需求的方法;
- 提供了一种与最终的用户和领域专家进行沟通的方法;
- 提供了一种测试系统的方法。
-
图形表示:用椭圆形表示
-
怎样使用用例?
- 参与者希望用户执行什么任务?
- 参与者在系统中访问哪些信息(创建、存储、修改、删除等)?
- 需要将哪些外界信息提供给系统
- 需要将系统的什么事情告诉参与者
- 如何维护系统
系统
用于界定系统功能范围,描述该系统功能的用例都置于其中,而描述外部实体的参数者都置于其外。用大矩形表示。
执行关联
参与者(Actor)执行用例(Use Case)之间的关系。
连接参与者和用例,表示参与者所代表的系统外部实体与该用例所描述的系统需求有关。用直线表示。
3.2 用例建模过程
建立用例模型的顺序:
- 确定谁会直接使用该系统。这些都是参与者(Actor)。
- 选取其中一个参与者。
- 定义该参与者希望系统做什么,参与者希望系统做的每件事成为一个用例
- 对每件事来说,何时参与者会使用系统,通常会发生什么,这就是用例的基本过程。
- 描述该用例的基本过程
- 考虑一些可变情况,把他们创建为扩展用例,
- 复审不同用例的描述,找出其中的相同点,抽出相同点作为共同的用例。
- 重复步骤2~7找出每一个用例。
3.3 用例图初步
自动售卖系统
3.4 用例图进阶
用例之间关系:关联、泛化、包含、扩展
关联Association
表示参与者与用例之间的通信,任何一方都可发送或接受信息。
泛化Inheritance
就是通常理解的继承关系,子用例和父用例相似,但表现出更特别的行为;子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为,也可以重载它。父用例通常是抽象的。
用例之间的is a kind of关系,表示用例之间的场景共享;Actor之间的 is a kind of关系,一般描述责任共享。
包含Include
包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。一个用例可以包含另外一个用例。
扩展Extend
扩展关系是指用例功能的延伸,相当于为基础用例提供一个附加功能。由一个用例的扩展点可以扩展出另外一个用例。
扩展关系中,一个基本用例执行时可以不执行扩展部分,但是在包含关系中,一定会执行包含用例部分。
- 关联、泛化、包含和扩展的区别
示例
自动售卖系统
图书借阅系统用例图: