软件建模与UML 第六章 逻辑模型
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第六章 逻辑模型
第一节 业务对象模型
第二节 分析模型
第三节 设计模型
第一节 业务对象模型
Rose把系统逻辑视图分成三个层次：业务对 象模型（Business Object Model）、分析模型 （Analysis Model）、设计模型（Design Model）。 业务对象模型和分析模型完成系统概要设计 任务；分析模型和设计模型完成系统逻辑设计任 务；设计模型和代码框架生成、编写代码完成系 统实现任务。
业务对象模型描述各业务部门业务参与者、 业务员工与业务实体类之间的关系，即业务对象 一级的类图，这种类图只与业务逻辑有关。 一个企业的部门是对象，每个部门的业务又 涉及自己的业务对象，每个部门的业务对象是从 所在部门业务的术语、名词中获得的，对象是类 的实体，由业务对象不难抽象出对应的业务实体 来。
1、业务对象模型概述
下图所示的是航标遥测遥控系统的业务对象模型图
2、业务对象建模的一些观点
1）业务对象模型的核心元素 2）如何命名业务参与者和业务实体 3）涉及业务用例的业务对象 4）业务对象模型和信息系统 5）在业务对象模型中明确建模的信息系统 6）好的业务对象模型的特征
3、业务对象模型分析
6、用例实现的通信图描述
设置了对象的初始值后，根据对象间的关系确定对 象间链接。一般先确定关联的链接；因为这是最主要的， 它代表了结构的链接。然后需要确定的是其他的链接， 用合适的路径构造型修饰它们，显示地说明这些对象间 是如何互相联系的。 从引起交互的消息开始，按消息的顺序，把随后的 消息附到适当的链接上，这描述了对象间的消息传递。 可以用带小数点的编号来表达嵌套。 如果需要说明时间或空间的约束，可以用适当的时 间或空间约束来修饰每个消息。 在建模中，如果想更详细的描述这个控制流，可以 为交互过程中的每个消息都附上前置条件和后置条件。
5、用例实现的顺序图描述
一个独立的顺序图只能显示一个控制 流，通常说来，一个完整的控制流肯定是 复杂的，所以将一个大的控制流分为几个 部分放在不同的图中是比较合适的。
5、用例实现的顺序图描述
Biblioteka Baidu
使用Rational Rose绘制顺序图过程如下： 1）创建顺序图 2）添加对象 3）添加消息 4）完成“更新销售信息”顺序图
用类图描述用例实现 ①在浏览器中Analysis Model下的“销售管理” 包下选择用例实现【更新销售信息】。右击, 在弹出菜单中选择【New】→【Class Diagram】。创建一个新的类图，命名为“更 新销售”。 ②双击【更新商品】，打开“更新销售”类 图。 ③将Analysis Model下“销售管理”包中的类： “销售管理窗体”、“商品信息控制”、“销 售表”拖到这个“更新商品”类图中。得到如 图6-11所示的“更新商品信息”用例实现的类 图。
1、分析模型概述
分析类代表了对系统设计中一个或几个类或 若干子系统的抽象。这种抽象由以下特征： 分析类侧重于处理功能性需求 分析类很少定义或提供任何接口 分析类定义的属性是较高层次的 分析类中的关系也是比较高层次的、概念性 的东西 分析类只包括三种版型（构造型）中的一种： 实体类(Entity Classes)，控制类(Control Classes)和边 界类(Boundary Classes)
1、分析模型概述
分析模型中分析类的三种构造型
1、分析模型概述
航标遥测遥控系统分析模型的一个实例
1、分析模型概述
类型 类名 职责
边界类 CommandWindow
负责接收用户输入的命令并向用户显示命令结果
LightInductorControl
负责与“航标灯器”感应器通讯，获取航标灯器当前数 据 负责与“雷达应答器”感应器通讯，获取雷达应答器当 前数据 负责与“GPS定位设备”感应器通讯，获取雷达应答器 当前位置 负责存储航标灯器状态数据 负责存储雷达应答器状态数据 负责GPS定位数据
5、创建系统动态模型-状态图
6、创建系统动态模型-活动图
1、设计模型概述
软件设计产生合理、健壮而稳定的软 件构架，创建实现模型的蓝图。
设计模型(Design Model)是描述用例的物理 实现的对象模型，受功能和非功能需求，以及与 实现环境有关的并最终影响系统的其它约束。
设计模型是系统实现的抽象，作为系 统实现活动的重要输入。
5、用例实现的顺序图描述
下图所示就是完成的更新销售信息顺序图
6、用例实现的通信图描述
通信图（Communication Diagram）是顺序 图之外的另一种表示交互的方法，通信图的一个 用途是表示类操作的实现。 通信图包含3元素：对象（Object）、链 （Line）和消息（Message）。 顺序图和通信图之间的语义是等价的，描述 的主要元素都是两个，即消息和对象。
1、设计模型概述
设计类是实现阶段的类，是规格说明已经 完成并且达到能够被实现程度的类。 设计类有两个来源： 其一是问题域中分析类的精化（一个分析 类可以变成零个、一个或多个设计类）； 其二是解域中的实用类库、中间件、GUI库、 可复用组件等。
1、设计模型概述
形式良好的设计类展现特定特征：
2、分析建模的一些观点
2）用例实现(Use-case Realizations)： 用例通过“用例实现”来完成相应用例的功 能。用例实现就是UML的协作(Cooperation)， 意思是通过对象(或类)的协作完成用例的实现。
3、建立分析类图
1）创建包
3、建立分析类图
2）创建类图 完成后的销售子系统分析模型类图示例
6、用例实现的通信图描述
使用Rational Rose绘制通信图过程如下： 1)创建通信图 2) 添加对象 3) 添加消息 4) 添加数据流
6、用例实现的通信图描述
下图就是更新销售信息的通信图
第三节 设计模型
1、设计模型概述
2、设计建模的一些观点
3、创建设计类
4、创建系统交互模型
4、创建用例实现
用例实现是类图的一种。创建用例实现，进 一步描述类的动态特征。 下面结合销售系统用例具体说明如何创建用 例实现。具体过程参见教材P158-159.
4、创建用例实现
4、创建用例实现
4、创建用例实现
用例实现可以从不同的角度去描述
可以通过类之间的协作(类图)来描述 可以通过类对象按时间顺序的消息交互（顺 序图）来描述 也可以通过类对象之间协作（通信图）来描 述。
4、创建用例实现
4、创建用例实现
用类图描述用例实现
图6-11 “更新销售信息”用例实现的类图
5、用例实现的顺序图描述
顺序图包含4个元素，分别是对象（Object）、生 命线（Lifeline）、消息（Message）和激活 （Activation）。
5、用例实现的顺序图描述
使用顺序图对系统建模时，可以遵循 如下策略：
1、分析模型概述
分析建模的经验法则： 分析模型总是使用业务语言。分析模型中的 抽象应该是业务领域词汇的部分。 关注于捕获大的场面。不要陷于系统将如何 工作的细节。 创建“讲故事”的模型。每幅产生的图都应 该阐明系统期望行为的一些重要部分。 对尽可能多的利益相关人有用。 尽可能保持模型简洁。
设置交互的语境，这些语境可以是系统、子系统、 操作、类、用例和协作的一个脚本。 通过识别对象在交互过程中扮演的参与者，根据对 象的重要性，将其从左向右的方向放在顺序图中。 设置每个对象的生命线。一般情况下，对象存在于 交互的整个过程，但它也可以在交互过程中创建和撤销。
5、用例实现的顺序图描述
4、业务对象模型的创建
1）创建包 2）创建子系统业务对象模型类图
下图是完成上述操作的销售管理业务对象模型类图。
第二节 分析模型
1、分析模型概述 2、分析建模的一些观点 3、建立分析类图 4、创建用例实现 5、用例实现的顺序图描述 6、用例实现的通信图描述
1、分析模型概述
分析模型必须实现三个主要目标：描述客户 需要什么；为软件设计奠定基础；定义可以被确 认的一组需求。 分析阶段的目的是： 分析产出更确切的需求说明。 分析模型用开发者的语言描述。 分析模型使需求结构化，便于理解、制作、 改变、重用。 分析模型可看作为设计模型的第一次分割。
6、用例实现的通信图描述
使用通信图对系统建模时，可以遵循如下策
略：
设置交互的语境。这里所指的语境可以是系统、子 系统、操作、类、用例或用例的脚本。 通过识别对象在交互过程中所扮演的参与者，开始 绘制通信图，把这些对象作为图的顶点放在通信图中。 其中较为重要的对象放在图的中央，与它邻近的对象放 在外围。 为每个对象设置初始特性。如果某对象的属性值、 标记值、状态或参与者在交互期发生变化，则在图中放 置一个复制对象，并用变化后的值更新它，然后通过构 造型《become》或《copy》的消息将这两者连接。
1、设计模型概述
2、分析建模的一些观点
实体类：业务实体的计算机描述（来源：词 汇表，业务领域；如销售表，商品档案表等） 边界类：位于系统和外界参与者的交界处， 实现业务参与者、业务员工与用例的交互（来源： “参与者--用例”。如窗体类、报表类或软件接 口。常用来接受参与者的交互信息） 控制类：主要用来协调边界类和实体类的工 作，也称管理类。用例将某项责任委托给控制类， 控制类自身并不完成任何服务功能，而是由控制 类发送消息，由别的类来实现需要的服务。
控制类
RadarResponderInductorControl
GPSDeviceControl
Lightstate 实体类 RadarResponderState GPSState
2、分析建模的一些观点
1）一个用例一般通过三种类协同实现其功
能 实体类、边界类和控制类。这三种类又称为 分析类变体（Analysis Class Stereotypes）。
从引发某个交互的信息开始，在生命线之间按从上 向下的顺序画出随后的消息。 设置对象的激活期，这可以可视化实际计算发生时 的时间点、可视化消息的嵌套。 如果需要设置时间或空间的约束，可以用时间标记 修饰每个消息，并附上合适的时间和空间约束。 如果需要形式化地说明某控制流，可以为每个消息 附上前置或后置条件流。
1、设计模型概述
设计模型和分析模型都是为系统同一个部 分建模，但是设计模型在接近代码的抽象层次上 描述系统。 分析模型和设计模型之间存在简单的 《trace》关系，设计模型是建立在分析模型的基 础之上，也可以看作是把实现技术加入分析模型 后对分析模型的精化和细化。
1、设计模型概述
设计模型和分析模型包含相同类型的物件， 但是所有的制品更加完整成型，并且必须包含实 现细节。 设计模型由设计子系统、设计类、接口、 用例实现（设计）和部署图组成。
第一节 业务对象模型
1、业务对象模型概述 2、业务对象建模的一些观点 3、业务对象模型分析 4、业务对象模型的创建
1、业务对象模型概述
业务对象模型描述现行的业务活动对象（部 门、业务实体、业务参与者）之间的关系，由业 务用例视图中的参与者、交互图等中的对象演化 而来，利用用户熟悉的业务对象描述现行系统， 通过对象的合作实现业务用例的功能。 业务对象模型（也叫领域模型）是描述业务 用例实现的对象模型。业务对象模型从业务参与 者内部的观点定义了业务用例。业务对象模型是 从面向对象的视角看待现实世界的结果，也就是 通过类图来描述现实世界中各种事物的关系。
类的公共操作定义它和类用户之间的契约。 完整性—类所包含的不能少于用户所有可能 的合理要求。 充分性—类所包含的不能多于用户所有可能 的合理要求。 原始性—服务应该是简单的、原始的和惟一 的。
1、设计模型概述
高内聚—每个类应当体现一个单一的、良好 定义的抽象概念；所有操作都应当支持类的目的。 低耦合—类应该仅与足够的其他类耦合，已 完成它的职责；只有在两个类之间存在真正语义 关系时才能将它们耦合；不要仅仅为复用代码而 耦合。 应当从类用户的角度去评估设计类。
第一节 业务对象模型
第二节 分析模型
第三节 设计模型
第一节 业务对象模型
Rose把系统逻辑视图分成三个层次：业务对 象模型（Business Object Model）、分析模型 （Analysis Model）、设计模型（Design Model）。 业务对象模型和分析模型完成系统概要设计 任务；分析模型和设计模型完成系统逻辑设计任 务；设计模型和代码框架生成、编写代码完成系 统实现任务。
业务对象模型描述各业务部门业务参与者、 业务员工与业务实体类之间的关系，即业务对象 一级的类图，这种类图只与业务逻辑有关。 一个企业的部门是对象，每个部门的业务又 涉及自己的业务对象，每个部门的业务对象是从 所在部门业务的术语、名词中获得的，对象是类 的实体，由业务对象不难抽象出对应的业务实体 来。
1、业务对象模型概述
下图所示的是航标遥测遥控系统的业务对象模型图
2、业务对象建模的一些观点
1）业务对象模型的核心元素 2）如何命名业务参与者和业务实体 3）涉及业务用例的业务对象 4）业务对象模型和信息系统 5）在业务对象模型中明确建模的信息系统 6）好的业务对象模型的特征
3、业务对象模型分析
6、用例实现的通信图描述
设置了对象的初始值后，根据对象间的关系确定对 象间链接。一般先确定关联的链接；因为这是最主要的， 它代表了结构的链接。然后需要确定的是其他的链接， 用合适的路径构造型修饰它们，显示地说明这些对象间 是如何互相联系的。 从引起交互的消息开始，按消息的顺序，把随后的 消息附到适当的链接上，这描述了对象间的消息传递。 可以用带小数点的编号来表达嵌套。 如果需要说明时间或空间的约束，可以用适当的时 间或空间约束来修饰每个消息。 在建模中，如果想更详细的描述这个控制流，可以 为交互过程中的每个消息都附上前置条件和后置条件。
5、用例实现的顺序图描述
一个独立的顺序图只能显示一个控制 流，通常说来，一个完整的控制流肯定是 复杂的，所以将一个大的控制流分为几个 部分放在不同的图中是比较合适的。
5、用例实现的顺序图描述
Biblioteka Baidu
使用Rational Rose绘制顺序图过程如下： 1）创建顺序图 2）添加对象 3）添加消息 4）完成“更新销售信息”顺序图
用类图描述用例实现 ①在浏览器中Analysis Model下的“销售管理” 包下选择用例实现【更新销售信息】。右击, 在弹出菜单中选择【New】→【Class Diagram】。创建一个新的类图，命名为“更 新销售”。 ②双击【更新商品】，打开“更新销售”类 图。 ③将Analysis Model下“销售管理”包中的类： “销售管理窗体”、“商品信息控制”、“销 售表”拖到这个“更新商品”类图中。得到如 图6-11所示的“更新商品信息”用例实现的类 图。
1、分析模型概述
分析类代表了对系统设计中一个或几个类或 若干子系统的抽象。这种抽象由以下特征： 分析类侧重于处理功能性需求 分析类很少定义或提供任何接口 分析类定义的属性是较高层次的 分析类中的关系也是比较高层次的、概念性 的东西 分析类只包括三种版型（构造型）中的一种： 实体类(Entity Classes)，控制类(Control Classes)和边 界类(Boundary Classes)
1、分析模型概述
分析模型中分析类的三种构造型
1、分析模型概述
航标遥测遥控系统分析模型的一个实例
1、分析模型概述
类型 类名 职责
边界类 CommandWindow
负责接收用户输入的命令并向用户显示命令结果
LightInductorControl
负责与“航标灯器”感应器通讯，获取航标灯器当前数 据 负责与“雷达应答器”感应器通讯，获取雷达应答器当 前数据 负责与“GPS定位设备”感应器通讯，获取雷达应答器 当前位置 负责存储航标灯器状态数据 负责存储雷达应答器状态数据 负责GPS定位数据
5、创建系统动态模型-状态图
6、创建系统动态模型-活动图
1、设计模型概述
软件设计产生合理、健壮而稳定的软 件构架，创建实现模型的蓝图。
设计模型(Design Model)是描述用例的物理 实现的对象模型，受功能和非功能需求，以及与 实现环境有关的并最终影响系统的其它约束。
设计模型是系统实现的抽象，作为系 统实现活动的重要输入。
5、用例实现的顺序图描述
下图所示就是完成的更新销售信息顺序图
6、用例实现的通信图描述
通信图（Communication Diagram）是顺序 图之外的另一种表示交互的方法，通信图的一个 用途是表示类操作的实现。 通信图包含3元素：对象（Object）、链 （Line）和消息（Message）。 顺序图和通信图之间的语义是等价的，描述 的主要元素都是两个，即消息和对象。
1、设计模型概述
设计类是实现阶段的类，是规格说明已经 完成并且达到能够被实现程度的类。 设计类有两个来源： 其一是问题域中分析类的精化（一个分析 类可以变成零个、一个或多个设计类）； 其二是解域中的实用类库、中间件、GUI库、 可复用组件等。
1、设计模型概述
形式良好的设计类展现特定特征：
2、分析建模的一些观点
2）用例实现(Use-case Realizations)： 用例通过“用例实现”来完成相应用例的功 能。用例实现就是UML的协作(Cooperation)， 意思是通过对象(或类)的协作完成用例的实现。
3、建立分析类图
1）创建包
3、建立分析类图
2）创建类图 完成后的销售子系统分析模型类图示例
6、用例实现的通信图描述
使用Rational Rose绘制通信图过程如下： 1)创建通信图 2) 添加对象 3) 添加消息 4) 添加数据流
6、用例实现的通信图描述
下图就是更新销售信息的通信图
第三节 设计模型
1、设计模型概述
2、设计建模的一些观点
3、创建设计类
4、创建系统交互模型
4、创建用例实现
用例实现是类图的一种。创建用例实现，进 一步描述类的动态特征。 下面结合销售系统用例具体说明如何创建用 例实现。具体过程参见教材P158-159.
4、创建用例实现
4、创建用例实现
4、创建用例实现
用例实现可以从不同的角度去描述
可以通过类之间的协作(类图)来描述 可以通过类对象按时间顺序的消息交互（顺 序图）来描述 也可以通过类对象之间协作（通信图）来描 述。
4、创建用例实现
4、创建用例实现
用类图描述用例实现
图6-11 “更新销售信息”用例实现的类图
5、用例实现的顺序图描述
顺序图包含4个元素，分别是对象（Object）、生 命线（Lifeline）、消息（Message）和激活 （Activation）。
5、用例实现的顺序图描述
使用顺序图对系统建模时，可以遵循 如下策略：
1、分析模型概述
分析建模的经验法则： 分析模型总是使用业务语言。分析模型中的 抽象应该是业务领域词汇的部分。 关注于捕获大的场面。不要陷于系统将如何 工作的细节。 创建“讲故事”的模型。每幅产生的图都应 该阐明系统期望行为的一些重要部分。 对尽可能多的利益相关人有用。 尽可能保持模型简洁。
设置交互的语境，这些语境可以是系统、子系统、 操作、类、用例和协作的一个脚本。 通过识别对象在交互过程中扮演的参与者，根据对 象的重要性，将其从左向右的方向放在顺序图中。 设置每个对象的生命线。一般情况下，对象存在于 交互的整个过程，但它也可以在交互过程中创建和撤销。
5、用例实现的顺序图描述
4、业务对象模型的创建
1）创建包 2）创建子系统业务对象模型类图
下图是完成上述操作的销售管理业务对象模型类图。
第二节 分析模型
1、分析模型概述 2、分析建模的一些观点 3、建立分析类图 4、创建用例实现 5、用例实现的顺序图描述 6、用例实现的通信图描述
1、分析模型概述
分析模型必须实现三个主要目标：描述客户 需要什么；为软件设计奠定基础；定义可以被确 认的一组需求。 分析阶段的目的是： 分析产出更确切的需求说明。 分析模型用开发者的语言描述。 分析模型使需求结构化，便于理解、制作、 改变、重用。 分析模型可看作为设计模型的第一次分割。
6、用例实现的通信图描述
使用通信图对系统建模时，可以遵循如下策
略：
设置交互的语境。这里所指的语境可以是系统、子 系统、操作、类、用例或用例的脚本。 通过识别对象在交互过程中所扮演的参与者，开始 绘制通信图，把这些对象作为图的顶点放在通信图中。 其中较为重要的对象放在图的中央，与它邻近的对象放 在外围。 为每个对象设置初始特性。如果某对象的属性值、 标记值、状态或参与者在交互期发生变化，则在图中放 置一个复制对象，并用变化后的值更新它，然后通过构 造型《become》或《copy》的消息将这两者连接。
1、设计模型概述
2、分析建模的一些观点
实体类：业务实体的计算机描述（来源：词 汇表，业务领域；如销售表，商品档案表等） 边界类：位于系统和外界参与者的交界处， 实现业务参与者、业务员工与用例的交互（来源： “参与者--用例”。如窗体类、报表类或软件接 口。常用来接受参与者的交互信息） 控制类：主要用来协调边界类和实体类的工 作，也称管理类。用例将某项责任委托给控制类， 控制类自身并不完成任何服务功能，而是由控制 类发送消息，由别的类来实现需要的服务。
控制类
RadarResponderInductorControl
GPSDeviceControl
Lightstate 实体类 RadarResponderState GPSState
2、分析建模的一些观点
1）一个用例一般通过三种类协同实现其功
能 实体类、边界类和控制类。这三种类又称为 分析类变体（Analysis Class Stereotypes）。
从引发某个交互的信息开始，在生命线之间按从上 向下的顺序画出随后的消息。 设置对象的激活期，这可以可视化实际计算发生时 的时间点、可视化消息的嵌套。 如果需要设置时间或空间的约束，可以用时间标记 修饰每个消息，并附上合适的时间和空间约束。 如果需要形式化地说明某控制流，可以为每个消息 附上前置或后置条件流。
1、设计模型概述
设计模型和分析模型都是为系统同一个部 分建模，但是设计模型在接近代码的抽象层次上 描述系统。 分析模型和设计模型之间存在简单的 《trace》关系，设计模型是建立在分析模型的基 础之上，也可以看作是把实现技术加入分析模型 后对分析模型的精化和细化。
1、设计模型概述
设计模型和分析模型包含相同类型的物件， 但是所有的制品更加完整成型，并且必须包含实 现细节。 设计模型由设计子系统、设计类、接口、 用例实现（设计）和部署图组成。
第一节 业务对象模型
1、业务对象模型概述 2、业务对象建模的一些观点 3、业务对象模型分析 4、业务对象模型的创建
1、业务对象模型概述
业务对象模型描述现行的业务活动对象（部 门、业务实体、业务参与者）之间的关系，由业 务用例视图中的参与者、交互图等中的对象演化 而来，利用用户熟悉的业务对象描述现行系统， 通过对象的合作实现业务用例的功能。 业务对象模型（也叫领域模型）是描述业务 用例实现的对象模型。业务对象模型从业务参与 者内部的观点定义了业务用例。业务对象模型是 从面向对象的视角看待现实世界的结果，也就是 通过类图来描述现实世界中各种事物的关系。
类的公共操作定义它和类用户之间的契约。 完整性—类所包含的不能少于用户所有可能 的合理要求。 充分性—类所包含的不能多于用户所有可能 的合理要求。 原始性—服务应该是简单的、原始的和惟一 的。
1、设计模型概述
高内聚—每个类应当体现一个单一的、良好 定义的抽象概念；所有操作都应当支持类的目的。 低耦合—类应该仅与足够的其他类耦合，已 完成它的职责；只有在两个类之间存在真正语义 关系时才能将它们耦合；不要仅仅为复用代码而 耦合。 应当从类用户的角度去评估设计类。