软件建模与分析

软件建模与分析

一、绪论

模型是指用一个较为简单的东西来代表另一个 东西，是从一个特定视点对系统进行的抽象

二、面向对象方法

对象：对象是要研究的任何事物。从一本书到图书馆， 单个整数到庞大的数据库、极其复杂的自动化工厂、 航天飞机都可看作对象，它不仅能表示有形的实体， 也能表示无形的（抽象的）规则、计划或事件。对象 由数据（描述事物的属性）和作用于数据的操作（体 现事物的行为）构成一独立整体。

类：类是对象的模板。即类是对一组有相同数据和相同操 作的对象的定义，一个类所包含的方法和数据描述一组对 象的共同属性和行为。类是在对象之上的抽象，对象则是 类的具体化，是类的实例。类可有其子类，也可有其父类， 形成类层次结构。

消息：消息是对象之间进行通信的一种规格说明。一般它 由三部分组成：接收消息的对象、消息名及实际变元

三、UML统一建模语言

1.建模语言的三个类别

非形式化、半形式化、形式化

UML是一种半形式化的建模语言，是系统建模的标准。

2.软件建模原则

准确、标准规范、子系统划分、分层

3.UML的特点

(1) 统一了Booch、OMT和OOSE等基本概念。

(2) UML还吸取了面向对象技术的优点，当然也有非面 向对象的影响。

(3) UML还提出了许多新说法。增加了模板、职责、扩 展机制、线程、过程、分布式、并发、模式、合作、 活动等概念，并清晰地区分类型、类和实例、细化、 接口和组件等概念。

4.UML组成结构

5.UML基本元素

5.1 结构元素

结构元素定义了业务或软件系统中的某个物理 元素，描述了事物的静态特征。结构元 素常 用名词表示。结构元素有七种，分别是： 类和对象、接口、主动类、用例、协作、组件、 节点。

**协作 **协作是指有意义的交互，即一组对象为了完成 某个任务相互间进行的交互。

用例的实现：实现某个用例的一组对象之间的 交互，即把一个用例表示为多个对象间的交互 （协作）。从本质上说，协作就是用例的实现。

组件也称构件，是系统设计中一个相对独立的软件部 件，它把功能实现部分隐藏在内部， 对外声明了一组 接口（包括供给接口和需求接口）。因此，两个具有 相同接口的组件可以相互替换。

5.2 行为元素

行为元素是用来描述业务系统或软件系统中事 物之间的交互或事物的状态变化。行为元素描述了事物的动态特征，用动词表示。包括交互和状态机

5.3 分组元素

5.4 注释元素

5.5 关系元素

UML中共定义了24种关系。这24种关系在 建模表示时可以归为关联关系、实现关系、泛化关系、扩展关系和 依赖关系

6. 常见的9中UML图

6.1 用例图

用例的层次关系：泛化（generalization)、包含 (include)和扩展 （extend)

扩展关系是指将扩展用例的事件流在一定的条件 下按照相应的扩展点插入基础用例中。

6.2 类图

类名的书写要规范：正体字类是实例化的，斜体 字类是抽象化。

类之间的关系

关联关系 泛化关系 实现关系 依赖关系

泛化关系（generalization)是一种特殊与一般关系，是一 般事物 (父类）和该事物较为特殊的种类（子类）之间的 关系，子类继承父类的属性和操作，除此之外，子类通常 还添加新的属性和操作。

6.3 对象图

对象反映了一个类的实例。对象图表示系统在某个特 定时刻各个类可能的具体内容，帮助对类图的理解。

6.4 状态图

状态图是一个类对象可能经历的所有历程的模型图。状态 图由对象的各个状态和连接这些状态的转换事件组成。

在状态图中定义的状态主要有初态（初始状态)、终态（最终 状态）和中间状态。在一张状态图中只能有一个初态，而终 态则可以有0至多个。初态是动作的虚拟开始，终态是动作 的虚拟结束。

6.5 活动图

活动图是状态图的一个变体，用来描述工作流程和功能中 涉及的活动。状态图把焦点集中在过程中的对象身上，而 活动图则集中在一个单独过程动作流程。活动图显示活动 之间的依赖关系。

活动代表一个工作流步骤或一个操作的执行。活动图描述 了一组顺序的或并发的活动。

6.6 顺序图

顺序图可以用来表示一个场景说明，即一个事务的历史过 程。顺序图将交互关系表示为一个二维图。纵向是时间轴，时 间沿竖线向下延伸；横向轴代表在协作中各独立对象角色。 对象角色用生命线表示，当对象存在时，角色用一条虚线 表示:当对象的过程处于激活状态时，生命线是一条双道线。

6.7 协作图

协作图对在一次交互中有意义的对象和对象间的链建模。协作图用几何排列来表示交互作用中的各角色。 附在类目角色上的箭头代表消息。消息的发生顺序用消息 箭头处的编号来说明。

协作图也是互动的图表。它像顺序图一样也传递相同的信 息，但它不关心消息什么时候被传递，只关心对象的角色

6.8 组件图

组件图是物理视图对应用自身的实现结构建模

实现视图用组件 图来表现。组件是代码模块。组件图是类图的物理实现。

6.9 部署图

部署视图描述位于节点实例上的运行组件实例的安排。节点是 一组运行资源，如计算机、设备或存储器。这个视图允许评估 分配结果和资源分配。

四、RUP统一过程

1. 软件开发模型

线性的: 瀑布模型、原型模型

迭代的: 螺旋模型、喷泉模型、进化树模型和 迭代增量模型

2. RUP的特点

统一软件过程(RUP)就是迭代的模型。

①软件开发是一个迭代过程；

②软件开发是由用例驱动的；

③软件开发是以架构设计为中心的。

优点

(1) 降低了在一个增量上的开支风险。

(2) 降低了产品无法按照既定进度进入市场的风险。

(3) 加快了整个开发工作的进度。

3. 基于统一过程的UML系统建模

RUP是一个流程定义平台，是一个流程框架。可以针对 RUP所规定的流程进行客户化定制，制定适合自己组织的 实用的软件流程。

RUP可使用UML来建立软件系统所需的各种模型。

4. RUP开发过程

5. RUP核心工作流

RUP中有九个核心工作流，分为六个核心过程工作流和三 个核心支持工作流。

（1）商业建模工作流描述了如何为新的目标组织开发 一个构想，并基于这个构想在商业用例模型和商 业对象模型中定义组织的过程、角色和责任。

（2）需求工作流的目标是描述系统应该做什么，并使 开发人员和用户就这一描述达成共识。

（3）分析与设计工作流将需求转化成未来系统的设计，为系统开发一个健 壮的结构并调整设计，使其与实现环境相匹配，优化其性能。

（4）实现工作流的目的包括以层次化的子系统形式定 义代码的组织结构；以组件的形式（源文件、二 进制文件、可执行文件）实现类和对象；将开发 的组件作为单元进行测试，以及集成由单个开发 者（或小组）所产生的结果，使其成为可执行的 系统。

（5） 测试工作流要验证对象间的交互作用，验证软件中所有组 件的正确集成，检验所有的需求己被正确实现，识别并确 认缺陷在软件部署之前被提出并处理。

（6）部署工作流的目的是成功地生成版本并将软件分 发给最终用户。部署工作流描述了那些与确保软 件产品对最终用户具有可用性相关的活动，包括 软件打包、生成软件本身以外的产品、安装软件、 为用户提供帮助。

（7）配置和变更管理工作流描绘了如何在多个成员组成的项目 中控制大量的产物。提供了准则来管理演化系统中的多 个变体，跟踪软件创建过程中的版本。

（8）软件项目管理平衡各种可能产生冲突的目标，管理风险， 克服各种约束并成功交付使用户满意的产品。

（9）环境工作流的目的是向软件幵发组织提供软件开 发环境，包括过程和工具。

6. RUP的要素和经验

RUP十大要素包括：开发前景、达成计划、标识 和减小风险、分配和跟踪任务、检查商业理由、 设计组件构架、对产品进行增量式的构建和测试、 验证和评价结果、管理和控制变化、提供用户支 持。

RUP六大经验：迭代式开发 管理需求 体系结构 可视化建模 验证软件质量 控制软件变更

五、软件建模工具

1. PowerDesigner

百度网盘：PowerDesigner165.rar_免费高速下载|百度网盘-分享无限制 (baidu.com)

提取码：b9mc

2. IBM RSA

百度网盘：RSA_9.0_Setup.rar_免费高速下载|百度网盘-分享无限制 (baidu.com)

提取码：fut0

六、需求获取

1. 软件需求的三个层次

业务需求（business requirement）描述组织或客户的高层次 目标（即宏观目标）。

用户需求(user requirement) 描述组织或客户的微观目标，即 描述了用户使用产品必须要完成的任务，这在用例（use case） 文档中予以说明

功能需求(functional requirement)定义了开发人员必须实现的 软件功能，使得用户能完成他们的任务，从而满足了业务需求 （即满足需求的软件功能）。

2. 需求工程过程

需求获取、 需求分析、需求描述和需求验证。

3. 需求获取方法

现场调查 网络调查 复杂网络和数据挖掘

4. 复杂系统的复杂网络需求获取方法

1. 基于情景实例的方法
2. 基于知识的方法
3. 基于原型的方法
4. 基于观点的方法
5. 复杂网络的特性获取方法

七、需求分析

1. 三种分析模型

​ 功能模型：把用户的功能性需求转化为开发人员和用户都能理解 的一种表达方式，其结果就是形成用例模型。

​ 对象模型： 通过对用例模型的分析，把系统分解成互相协作的分 析类。一般情况下，通过类图和对象图来描述系统中 的所有对象、对象的属性及对象之间的相互关系。

​ 动态模型： 描述系统的动态行为。一般通过顺序图和通信图来描 述系统中对象之间的交互关系，以揭示所有对象如何 通过分工协作来实现每个具体用例：通过状态机图来 描述系统中单个对象的状态变化情况，以揭示单个对 象的动态行为。通过活动图得到事件流的执行情况描 述。

2. UML的视图

（1）用例视图强调从系统的外部参与者看到的或需要的系 统功能。

（2）逻辑视图从系统的静态结构和动态行为角度显示如何 实现系统的功能。它主要是为设计和开发人员准备的， 主要关注系统内部的具体实现。

（3）组件视图显示代码组件的组织结构。

（4）并发视图显示系统的并发性，解决在并 发系统中存在的通信和同步问题

（5）配置视图显示系统的具体部署。

3. 需求分析方法

3.1 面向对象分析方法

(1) 确定系统的逻辑模型。①确定对象和类。②确定结构。

(2) 确定系统的过程模型：状态机图、活动图、顺序图、 通信图。

3.2 类图的建模分析步骤如下

(1) 寻找出需求中的名词（候选对象)。

(2) 合并含义相同的名词，排除范围以外的名 词，并寻找隐含的名词。

(3) 去掉只能作为类属性的名词。

(4) 剩下的名词就是要找的分析类（候选类)。

(5) 根据常识、问题域、系统责任确定该类有哪些 属性。

(6) 补充该类的动态属性，如状态、对象间联系 （如聚合、关联）等属性。

(7) 补充每个类的分析文档，为类的进一步设计打 下基础。

3.3 建立系统的对象模型结构

（1）标识和确定类

​ 从需求说明中选取相关的名词确 定一些类，然后对这些类进行分析，过滤掉不符合条件的 类。

（2）准备数据字典

​ 数据字典应当准确描述各个类的精确含义，描述 当前问题中类的范围，包括对类的成员、用法方 面的假设或限制等。

（3）确定关联

​ 关联是指两个或多个类之间的相互依赖。一种依赖表示一 种关联，可用各种方式来实现关联。

（4）确定属性

​ 只考虑与具体应 用直接相关的属性，不要考虑那些超出问题域的属性。

（5）使用继承来细化类

​ 使用继承来共享公共属性，以此来对类进行组织

（6）完善对象模型

​

3.4 建立过程模型

(1) 准备场景

(2) 确定事件

(3) 准备事件跟踪表

(4) 构造状态机图、活动图、顺序图、通信图

3.5 状态机图的建模分析步骤

(1) 确定进行系统控制的对象，也可以从顺序图中寻找

(2) 确定对象的起始状态和结束状态。

(3) 在对象的整个生命周期寻找有意义的控制状态。

(4) 寻找状态之间的转换。

(5) 补充引起转换的事件。

(6) 用UML建模工具画状态机图。  (7) 补充必要的文档。

3.6 活动图的建模分析步骤

(1) 在采集的原始需求中选择重点流程。

(2) 确定要设计的活动图是针对业务流程还是用例的。

(3) 设计活动过程的起点和终点。

(4) 确定活动图的所有执行对象。

(5) 确定活动节点，并根据执行对象进行活动分组：①如 果对用例创建活动图，则把角 色所发出的每一个动作变 为活动节点；②如果对业务流程创建活动图，则把每一个 流程步骤 (或片段）变为活动节点。

(6) 确定活动节点之间的转移。

(7) 处理在活动节点之间的分支和合并。

(8) 处理在活动节点之间的分叉和汇合。

(9) 用UML建模工具进行活动图建模。

(10) 编写必要的补充文档。

3.7 顺序图的建模分析步骤

(1) 完成用例图的细致分析。

(2) 对每个用例，识别出参与基本事件流的对象（包括接 口、子系统、角色等)。

(3) 识别这些对象是主动对象还是被动对象。

(4) 识别这些对象发出的消息是同步消息还是异步消息。

(5) 从主动对象开始向接收对象发送消息。

(6) 接收对象调用自己的服务为主动对象返回结果。

(7) 如果接收对象需要调用其他对象的服务，则需要向其 他对象再发送消息。

(8) 如此反复，最后返回给主动对象有意义的结果。

(9) 用UML建模工具绘出顺序图。

(10) 给顺序图补充必要的说明文档。

3.8 通信图的建模分析步骤

(1) 完成用例图的细致分析。

(2) 对每个用例，识别出参与基本事件流的对象（包括接 口、子系统、角色等)。

(3) 识别对象间的连接关系

(4) 识别这些对象发出的消息顺序

(5) 从主动对象开始向接收对象发送消息。

(6) 接收对象调用自己的服务为主动对象返回结果。

(7) 如果接收对象需要调用其他对象的服务，则需要向其 他对象再发送消息。

(8) 如此反复，最后返回给主动对象有意义的结果。

(9) 用UML建模工具绘出通信图。

(10) 给顺序图补充必要的说明文档。

4.需求分析路线图

(1) 类抽取：

①进一步细化分析系统的功能模型（即用例的场景分析）

②画出类图、对 象图

③画出动态模型（用状态机图或活动图表示）。

(2) 细化和实现用例，画出顺序图或通信图。

八、设计

1. 概述

从软件需求规格说明书出发，形成软件的具体设计方案

2. 面向对象设计

面向对象设计是把分析阶段得到的需求转变成符合成本和质 量要求的、抽象的系统实现方案的过程。从面向对象分析到 面向对象设计是一个逐渐扩充模型的过程。

3. 面向对象设计的准则

（1）模块化

（2）抽象：不仅支持过程抽象，而且支持数据抽象

（3）信息隐藏：信息隐藏通过对象的封装性来实现

（4）低耦合 减少类间的耦合（关联/聚集/依赖），使一个类的修改对 其它类的影响范围有所降低，从而系统变得更容易维护

耦合主要指不同对象之间相互关联的紧密程度

（5）高内聚 提高类的通用性，并控制类的复杂程度，努力分解类使得 类具有独立的责任

4. 设计模式

**创建型模式：**单例模式、抽象工厂模式、建造者模式、工厂 模式、原型模式。

**结构型模式：**适配器模式、桥接模式、装饰模式、组合模式、 外观模式、享元模式、代理模式。

**行为型模式：**模板方法模式、命令模式、迭代器模式、观察 者模式、中介者模式、备忘录模式、解释器模式、状态模式、 策略模式、职责链模式、访问者模式。

5. 设计模式的六大原则

（1）开闭原则 对扩展开放，对修改关闭

（2）里氏代换原则（LSP） 任何基类可以出现的地方，子类一定可以出现。

（3）依赖倒转原则 针对接口编 程，依赖于抽象而不依赖于具体

（4）接口隔离原则 使用多个隔离的接口比使用单个 接口要好。

（5）迪米特法则 一个实体应当尽量少地与其他实体之间 发生相互作用，使得系统功能模块相对 独立

（6）合成复用原则 尽量使用合成/聚合的方式，而不使用 继承

6. 设计路线图

（1） 结构设计 细化类的属性格式、操作及关系约束。

（2）数据库设计 根据类图得到E-R图，并进一步细化设计数据库的表。

（3）组件和部署设计 在大中型系统中，还要完成系统的部署设计，画出组件图和部署图。

（4）详细设计 根据用例图及活动图细化类操作中的相关算法。

九、设计模式

1. 模式的四个基本要素

（1）模式名称

（2）问题 描述了应该在何时使用模式

（3）解决方案 描述了设计的组成成分，它们之间的相互关系及 各自的职责和协作方式。

（4）效果 描述了模式应用的效果及使用模式应权衡的问题

2. Observer(观察者)模式

将对象分离，使得一个对象的改 变能够影响另一些对象，而这个对象并不知 道那些被影响的对象的细节

3. Composite模式（组合模式）

将一些对象 划为一组，并将该组对象当作一个对象来使 用

4. Strategy模式（策略模式）

要实现不同的响应策略只要用不同种类 的Controller实例替换即可

5. Proxy模式（代理模式）

为其他对象提供一个代理以 控制对这个对象的访问。