结构化分析与设计方法是一种面向数据流的需求分析和设计方法。

它适用于分析和设计大型数据处理系统，是一种简单、实用的方法。

一、结构化分析

结构化分析方法的基本思想史自顶向下逐层分解。
分解和抽象是控制问题复杂性的两种基本手段。
把一个大问题分解成若干个小问题，每个小问题在分解成更小的问题，让每个最底层的问题都足够简单、容易解决，这个过程就是分解过程。

结构化分析与面向对象分析方法之间最大的差别是：
面向对象方法把系统看成一个相互影响的对象集。
结构化分析方法把系统看作一个过程的集合体，包括人完成的和电脑完成的。特点是利用数据流图帮助人们理解问题，对问题进行分析。
结构化分析一般包括以下工具：

1
2
3
4
5

数据流图（Data Flow Diagram，DFD）
数据字段（Data Dictionary，DD）
结构化语言
判定表
判定树

1、结构化分析的工作步骤

（1）研究“物质环境”

首先应该画出当前系统的数据流图，说明系统的输入、输出数据流，说明系统的数据流情况，经历了那些处理过程。

（2）简历系统逻辑模型

在物理模型建立完成之后，接下来就是画出相对于真实系统的等价逻辑数据流图。
在前一步简历的数据流图的基础上，将所有自然数据流都转成等价的逻辑流。
比如将现实世界中的“送往总经理办公室”改成“报送表格”。

（3）划清人机界限

确定在系统逻辑模型中，哪些通过系统自动化完成，哪些手工操作。

2、数据流图DFD

DFD是一种图形化的系统模型，主要在图中展示主要需求，包括输入、输出、处理、数据存储等过程。
DFD包括以下几个基础元素：

1
2
3
4
5

过程：也称为加工，一步步地执行指令，完成输入到输出的转换。
外部实体：也称为源/宿，系统之外的数据源或目的。
数据存储：也称为文件，存放数据的地方，一般是文件、数据库。
数据流：从一处到另一处的数据流向。
实时链接：当过程执行时，外部实体与过程之间的来回通信。

(1)数据流图的层次

结构化的思路是依赖于数据流图自顶向下分析。
因为系统通常比较复杂，很难在一张图上将所有的数据流和加工描述清楚。
因此数据流图分为高层次和低层次的图，由高层次逐步分解。

（2）Context图

系统上下文范围关系图。是系统最高层结构的DFD图。
特点是将待开发的系统表示成一个过程，将所有外部实体和进出系统的数据流都花在一张图中。

（3）逐级分解

保持输入、输出不变，由于是对过程0分解进行分解，所以叫DFD0层图。
对DFD1层图进行分解，其编号就是1.1，1.2……

（4）如何画DFD。

1
2
3
4

画系统的输入和输出
画数据流图的内部
为每个数据流命名
为加工命名

3、细化记录DFD部件

数据字典是很适用和有效的细化手段。他对所有和系统相关的数据元素进行明确的定义。
数据字典的每一个条目中包括：

1
2
3
4

名称
何处使用/如何使用
内容描述
补充信息

内容描述的符号包括

1
2
3
4
5
6

= 由xxx组成
+ 和，表示顺序链接
[|] 或
{}* n次重复
() 可选的数据项
*...* 特定限制

实例：

1
2
3
4

客户信息=客户编号+客户名称+身份证号+手机
客户编号={0...9}8
客户名称={字}4
身份证号=[{0...9}15|{0...9}18]

二、结构化设计

结构化设计包括架构设计、接口设计、数据设计、过程设计等。
是面向数据流的设计，自顶向下、逐步求精、模块化的过程。

1、概要设计与详细设计的主要任务

概要设计

概要设计阶段的主要任务是设计软件的结构、确定系统由哪些模块组成，每个模块之间的关系。
整个过程包括：

1
2
3
4
5

复查基本系统模型
复查并精化数据流图
确定数据流图的信息流类型
根据刘类型分别实施变换分析或事务分析
根据软件设计原则对得到的软件结构图进一步细化

详细设计

详细设计阶段的主要任务是确定应该如何具体地实现所要求的的系统，得出对目标系统的精确描述。
采用自顶向下、逐步求精的设计方式，单入口单出口的控制结构。
常用工具包括：

1
2
3
4

流程图
盒图
问题分析图PAD
程序设计语言PDL

2、结构图

结构图包括模块、调用、和数据

结构图是在数据流图的基础上进一步设计，将DFD中的信息流分成交换流和事务流。

交换流

信息沿着输入通路进入系统，将其转换为内部表示，然后通过交换中心（加工）的处理，再验证输出转换为外部形式离开系统。

事务流

信息沿着输入通道进入系统，事务中心根据输入信息的类型在若干活动流选择一个执行。

3、流程图和盒图

流程图和盒图都是描述程序的细节逻辑。
流程图的特点是简单、直观、医学，缺点是由于其随意性使画出来的流程图容易变成费及饿哦固化的流程图。
盒图是为了解决这一问题设计的。
盒图的主要特点是功能域明确、无法任意转移控制、容易确定全局数据和局部数据的作用域、容易表示嵌套关系、可以表示模块的层次结构。
盒图的缺点是修改相对比较困难。

4、PAD和PDL

问题分析图PAD，能够方便的转换成程序语言的源程序代码。
语言描述工具PDL，伪代码，形式化语言，其控制结构和描述是确定的，但内部的描述语言是不确定的。

三、模块设计

在模块化方法中，将软件分解成若干小的模块，每个模块可独立开发、测试。
模块设计时，最重要的原则是实现信息隐蔽和模块独立。

1、信息隐蔽原则

将难的决策、可能修改的决策、数据结构的内部链接以及对他所做的操作细节、内部特征码、与计算机硬件有关的细节隐藏起来。
可以提高软件的可修改性、可测试性和可移植性。

2、模块独立性原则

每个模块完成一个相对独立的特定子功能，并与其他模块之间的联系最简单。
设计的目标是高内聚、低耦合。

从高到低对7种内聚类型排序：

从低到高7种耦合类型排序：

系统设计时，除了保持信息隐蔽和模块独立性之外，还需要考虑：

1
2
3
4
5
6
7

保持模块大小适中
尽可能减少调用深度
直接调用该模块的个数应该尽量大
调用其他模块的个数不宜过大
保证模块是单入口、单出口
模块的作用于应该在控制域之内
功能应该是可预测的

如果同时运行两个系统，会给客户造成多大的开销;
如果直接运行新系统，客户面对的风险有多大;
对新系统试运行时的查错和纠错，以及出现严重错误而导致停止运行时的应急措施;
客户运行新系统将面临的不利因素有哪些;
人员的培训。

1.直接过渡

这是一种快速的系统过渡方式，当新系统运行时，立即关闭原来的系统。这种过渡方式非常简单，没有后勤保障的问题，也不要消耗很多资源。同时，它也意味着大风险，目标系统的特性决定了风险的大小。设计者主要要权衡当新系统失败时，系统停止运行或者勉强运行给客户带来的损失有多大。由于这种过渡方式简单而费用低廉，对于可以容忍停机一段时间的系统的实践者，可以采用这种方式。

2.并行过渡

设计者采用并行过渡方式，让新系统和旧系统在一段时间里同时运行，通过这样的旧系统作为新系统的备份，可以大大降低系统过渡的风险。可是并行过渡显然比直接过渡要消耗更多的资源:现有的硬件资源必须保证能同时跑两套系统，这常常意味着增加服务器和额外的存储空间，需要增加人员来同时使用两套系统，或者增加现有员工的工作量，让他们同时操作两套系统。这种方式同时也增加了管理和后勤保障的复杂度。

有些系统无法使用并行过渡的方式，主要是客户没有足够的资源来维持两个系统同时运行，另外一种情况是新、旧系统差别太大，旧系统的数据无法为新系统采用。当客户无法使用并行过渡，又想尽可能地减少风险，设计者可以使用部分并行过渡的策略，使并行的开销减少到客户能够接受的范围内。

3.阶段过渡

通常在系统非常复杂、过于庞大以至于无法一次性进行过渡时采用，也适用于分阶段开发的系统。设计者需要设计一系列步骤和过程来完成整个系统的过渡，这种过渡方式和系统的复杂程度相关，随着系统的不同往往有很大的不同。和并行过渡一样，阶段过渡也能够减少风险，显然局部的失败要比全体的失败更容易接受，带来的损失更小。阶段过渡也带来了复杂性，有时候比并行过渡更加复杂。

接口设计主要包括三个方面的内容:一是设计软件构件间的接口;二是设计模块和其他非人的信息生产者和消费者(如外部实体)的接口;三是人(如用户)和计算机间界面设计。

一、用户界面设计的原则

用户界面设计必须考虑软件使用者的体力和脑力，设计时必须遵从三个黄金法则。

1、置用户于控制之下

1
2
3
4
5
6

以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式
提供灵活的交互
允许用户交互可以被中断和撤销
当技能级别增长时可以使交互流水化并允许定制交互
使用户隔离内部技术细节
设计应允许用户和出现在屏幕上的对象直接交互

2、减少用户的记忆负担

1
2
3
4
5

减少对短期记忆的要求
建立有意义的默认
定义直觉性的捷径
界面的视觉布局应该基于对真实世界的隐喻
以不断进展的方式提示信息

3、保持界面的一致

1
2

允许用户将当前任务放入有意义的语境
在应用系列内保持一致性，如果过去的交互模型已经建立了用户期望，除非有不得已的理由，否则不要改变它

除此之外，还应该考虑表所示的设计原则。

二、用户界面设计过程

(1)用户、任务和环境分析

着重于分析将和系统交互的用户的特点。记录下技术级别、业务理解及对新系统的一般感悟，并定义不同的用户类别。然后对用户将要完成什么样的任务进行详细的标识和描述。最后对用户的物理工作环境进行了解与分析。

(2)界面设计

主要包括建立任务的目标和意图，为每个目标或意图制定特定的动作序列，按在界面上执行的方式对动作序列进行规约，指明系统状态，定义控制机制，指明控制机制如何影响系统状态，指明用户如何通过界面上的信息来解释系统状态。

(3)实现

就是根据界面设计进行实现，前期可以通过原型工具来快速实现，减少返工的工作量。

(4)界面确认

界面实现后就可以进行一些定性和定量的数据收集，以进行界面的评估，以调整界面的设计。

在设计一个新的系统时，设计者必须考虑目标系统的运行环境问题。软件的运行环境是指系统运行的设备、操作系统和网络配置。

1.集中式系统

所有的操作都集中于一台主机中。

集中式系统常见于银行、保险、证券行业，它们含有大规模的处理应用。

在现代的系统中，集中式系统通常是某个分布式系统的一个环节。

集中式系统由以下几个部分组成。

1
2
3

(1)单计算机结构:这种结构简单、容易维护，但是处理能力受到限制。 
(2)集群结构:由多个计算机组成，这些计算机具有类似的硬件平台、操作系统等。通常采用负载均衡、资源共享等方式实现更大的处理能力和容量。 
(3)多计算机结构:由多个计算机组成，这些计算机之间操作环境可能不同。适用于当系统可以分解成多个不同的子系统时。

2.分布式系统

分布式系统由于网络的普遍延伸，费用的不断降低而越来越成为大型系统的首选环境。分布式系统必须基于网络，这个网络可以是在一个地域内的局域网，也可以是跨越不同城市乃至国家的广域网。对比集中式的计算机环境，分布式系统有着多种多样的形式。这也给设计者在确定系统运行环境时带来一定的烦恼。

3.C/S 结构

由提供服务的服务器和发起请求、接受结果的客户机构成。

4.多层结构

C/S 结构的扩展。

典型的分为由存储数据的数据库服务器作为数据层、实现商业规则的程序作为逻辑层、管理用户输入输出的视图层所组成的三层结构。

多层结构形式复杂，功能多样。实现多层结构常常需要来实现不同层次间通信的专门程序——管件，也称为中间件。中间件大多数实现远程程序调用、对象请求调度等功能。

5.Internet、Intranet 和 Extranet

Internet 是全球的网络集合，使用通用的 TCP/IP 协议来相互连接。Internet 提供电子邮件、文件传输、远程登录等服务。

Intranet 是私有网络，只限于内部使用，也使用 TCP/IP 协议。

Extranet 是一个扩展的 Intranet。它包括企业之外的和企业密切相关合作的其他企业。 Extranet 允许分离的组织交换信息并进行合作，这样就形成了一个虚拟组织。

现在的 VPN 技术允许在公用网络上架构只对组织内部开发服务。

Web 同样基于 C/S 结构，实际上 Web 接口是一个通用的接口，不是只能使用浏览器 的协议，它同样能够在普通的程序中使用。

Internet 和 Web 已经给设计者提供了一个非常富有吸引力的选择方案。它的优势在于:它们已经成为网络的事实上的标准，支持它们的软件已经广泛地存在于全世界的计算机中，而且通信费用已经下降到很有竞争力的水平。

采用 Internet 时，必须考虑其不利的一面。 Internet 的安全性过去、现在、以后都是设计者头痛的问题。其他诸如可靠性、系统吞吐量、不断发展的技术和标准都是影响系统选择它们作为运行环境的不利因素。

现实中的流程存在大量的不确定性。

一、工作流设计概述

工作流是一类能够完全或者部分自动执行的经营过程，根据一系列过程规则、文档、信息或任务在不同的执行者之间 传递、执行。

(1)工作流

工作流是现实中的具体工作从开始到结束过程的抽象和概括。这个过程包括了众多因素:任务顺序、路线规则、时间时限约束等。

(2)流程定义

流程定义是指对业务过程的形式化表示，它定义了过程运行中的活动和所涉及的各种信息。这些信息包括

1
2
3
4
5
6

过程的开始和完成条件
构成过程的活动及进行活动间导航的规则
用户所需要完成的任务
可能被调用的应用
工作流间的引用关系
工作流数据的定义

(3)流程实例

也称为工作，是一个流程定义的运行实例。

(4)工作流管理系统

1
2
3

存储流程的定义
按照所使用的流程定义来触发流程状态的改变
推动流程的运转

这个推动的依据常常称为工作流引擎。

(5)流程定义工具

使用流程定义工具来完成流程定义的工作

(6)参与者

可以是具体的人或者角色(企业内部有特别共同作用的多个人)，也可以是自动化系统，甚至是其他系统。

(7)活动

活动是流程定义中的一个元素，一次活动可能改变流程处理数据的内容、流程的状态，并可能将流程推动到其他活动中去。活动可以由人来完成，也可以是系统自动的处理过程。

(8)活动所有者

决定该活动是否结束

(9)工作所有者

有权整体控制流程实例执行过程的参与者

(10)工作项

流程实例中活动的参与者将要执行的工作

二、工作流管理系统

在工作流形式化表示的驱动下，通过软件的执行而完成工作流定义、管理及执行的系统。
主要目标是对业务过程中各活动发生的先后次序及与活动相关的相应人力或信息资源的调用进行管理，而实现业务过程的自动化。

工作流管理系统的6个最基本组成：

(1)流程定义工具

提供图形化或者其他方式的界面给设计者。由设计者将实际工作流程进行抽象，并将设计者提交的流程定义转换为形式化语言描述，提供给计算机工作流执行服务进行流程实例处理的依据。

(2)工作流执行服务

1、使用一种或者多种数据流引擎，对流程定义进行解释，激活有效的流程实例，推动流程实例在不同的活动中运转。
2、和客户应用程序、其他工作流服务执行程序及其他应用程序进行交互，从而完成流程实例的创建、执行和管理工作。
3、为每个用户维护一个活动列表，告诉用户当前必须处理的任务。
4、通过电子邮件甚至是短消息的形式提醒用户任务的到达。

(3)其他工作流执行服务

大型的企业工作流应用，往往包括多个工作流管理系统。这就需要这些工作流管理系统之间进行有效的交互，避免画地为牢、信息孤岛的现象出现。

(4)客户应用程序

最终用户的界面，用户通过使用这部分软件对工作流的数据进行必要的处理，如果用户是当前活动的拥有者，还可通过客户应用程序改变流程实例的活动，将流程实例推动到另外一个活动中。

(5)被调用应用程序

对工作流所携带数据的处理程序。

(6)管理和监控工具

对流程实例的状态查询、挂起、恢复、销毁等操作，同时提供系统参数、系统运行情况统计等数据。

面向对象方法以客观世界中的对象为中心，其分析和设计思想符合人们的思维方式，分析和设计的结构与客观世界的实际比较接近。

面向对象方法中，分析和设计的界面并不明显，他们采用的相同的符号表示，能方便的从分析阶段平滑过渡到设计阶段。

在显示生活中，用户的需求经常会发生变化，但是客观世界的对象集对象间的关系比较稳定，因此用面向对象方法分析和设计的结构也相对比较稳定。

一、面向对象的基本概念

1、对象和类

对象是描述客观事物的实体，由对象标识（名称）、属性（状态、数据、成员变量）和服务（操作、行为、方法）是3个要素组成，封装成一个整体，以接口的形式对外提供服务。
类是具有相同属性和服务的一个或一组对象的抽象。
类与对象是抽象描述和具体实例的关系。一个具体的对象被称为类的一个实例。

类可以分为实体类、边界类、控制类。

（1）实体类

实体类映射需求中的每个实体，实体类保存需要存储在永久存储体重的信息。
实体类一定有属性，不一定有操作。

（2）控制类

控制类是用于控制用力工作的类，一般由动宾结构的短语转化来的名称，例如身份验证。
控制类没有属性，但是有方法。

（3）边界类

边界类用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交界处，包括所有窗体、报表、打印机和扫描仪等硬件接口，以及与其他系统的接口。
边界类通常既有属性也要方法。

2、继承与泛化

用来说明特殊类（子类）与一般类（父类）的关系。

3、多态与重载

一般类中定义的属性或服务被特殊类集成后，可以具有不同的数据类型或表现出不同的行为。
通常用重载和改写实现。
重载是编译时制定的，改写是运行时选择的。

4、模板类

也称为类属类，用来实现参数多态机制。
一个类属类是一组类的一个特性抽象。

5、消息和消息通信

消息是想对象发出的服务请求。 为对象间提供唯一合法的动态联系的途径。

二、面向对象分析

对象技术的流行，演化出数十种不同的OOA方法，其中比较流行的包括OMT、OOA、OOSE、Booch等。OMT、OOSE、Booch最后统一成为UML。

1、OOA/OOD方法

面向对象分析（OOA），面向对象设计（OOD）。
OOA模型包括主题、对象类、结构、属性和服务5个层次。需要经过标识对象类、标识结构与关联、划分主题、定义属性、定义服务5个步骤完成整个分析工作。
OOD贯穿OOA的5个层次和5个活动，由人机交互部件、问题域部件、任务管理部件、数据管理部件4个部分组成。

（1）设计问题域部分

OOA的结果是OOD的问题域部件，分析的结果在OOD中可以被改动或增补，但基于问题域的总体组织架构是长时间稳定的。

（2）设计人机交互部件

在上述结果中加入人机交互的设计和交互细节。

（3）设计任务管理部分

识别事件驱动任务、识别时钟驱动任务、识别优先任务和关键任务、识别协调者、审查每个任务并定义每个任务。

（4）设计数据管理部分

数据管理部分提供了在数据管理系统中存储和紧缩对象的基本结构，其目的是隔离数据管理方法对其他部分的影响。

2、Booch方法

Booch认为软件开发是螺旋上升的过程，每个周期包括 标识类和对象、确定类和对象的含义、标识关系、说明每个类的接口和实现 4个步骤。

Booch方法的开发过程是一个迭代的渐进式的系统开发过程，分为宏过程和微过程梁两类。
宏过程用于控制微过程，5个主要活动包括：

1
2
3
4
5

建立核心需求的概念化
建立模型的分析
建立架构的设计
形成实现的进化
管理软件交付使用的维护

微过程基本上代表开发人团的日常活动，4个重要、没有顺序的步骤包括：

1
2
3
4

在给定的抽象层次上识别出类和对象
识别出这些类和对象的语义
识别出类间和对象间的关系
实现类和对象

3、OMT方法

对象建模技术（OMT）主要用于分析、系统设计和对象设计。
包括对象模型、动态模型、功能模型。

4、OOSE方法

面向对象软件工程（OOSE）在OMT的基础上对功能模型进行了补充，提出了“用例”的概念，最终取代数据流图进行需求分析和建立功能模型。

三、统一建模语言

统一建模语言（UML）

1、UML是什么

是一种用于详细描述的可视化语言。
是一种构造语言，虽然不是一种可视化的编程语言，但与编程语言直接相连，有较好的映射关系。允许正向工程、逆向工程。
是一种文档化语言。

2、UML的结构

UML由构造块、公共机制和架构三部分组成。

（1）构造块

构造块也就是基本的UML建模元素、关系和图。
建模元素：包括构造事物（类、接口、协作、用例、活动类、组件、节点等）、行为事物（交互、状态机）、分组事物（包）、注释事物。
关系：包括关联关系、依赖关系、泛化关系、实现关系。
图：UML2.0包括14种不同的图，分为表示系统静态结构的静态模型（包括类图、对象图、包图、构件图、部署图、制品图），以及表示系统动态结构的动态模型（包括对象图、用例图、顺序图、通信图、定时图、状态图、活动图、我交互概览图）。

（2）公共机制

指达到特定目标的公共UML方法，包括规格说明、修饰、公共分类和扩展机制4种。
规格说明：是元素语义的文本描述。
修饰：通过修饰给模型元素表达更多的信息。
公共分类：包括类元和实体、接口和实现两组公共分类。
扩展机制：包括约束、构造型、标记值。

（3）架构

架构是系统的组织结构，包括系统分解的组成部分、他们的关联性、交互、机制和指导原则。

具体来说，就是5个系统视图。

逻辑视图：以问题域的语汇组成的类和对象集合。
进程视图：可执行线程和进程作为活动类的建模，他是逻辑视图的一次执行实例。
实现视图：对组成基于系统的物理代码的文件和组件进行建模。
部署视图：把组件物理的部署到一组物理的可计算的节点上。
用例视图：最基本的需求分析模型。

3、用例图基础

外部参与者所理解的系统功能。

包括参与者、用例、包含和扩展。

4、类图和对象图基础

类图技术是OO方法的核心。

（1）类和对象

类是对一类具有相同特征的对象的描述。
对象是类的实例。
类的属性的语法为: “可见性 属性名:类型 = 默认值 {约束特性}”。
可见性包括 Public、Private 和 Protected，分别用+、-、#号表示。
类的操作的语法为: “可见性:操作名(参数表):返回类型 {约束特性}”。

（2）类之间的关系

①依赖关系。使用带箭头的虚线表示依赖关系。
②泛化关系。继承关系是泛化关系的反关系，也就是说子类是从父类中继承的，而父类则是子类的泛化。使用带空心箭头的实线表示，箭头指向父类。
③关联关系。用一条实线来表示关联关系。
聚合关系:聚合是一种特殊形式的关联。聚合表示类之间的关系是整体与部分的关系。例如 一辆轿车包含四个车轮、一个方向盘、一个发动机和一个底盘，就是聚合的一个例子。在 UML 中，用一个带空心菱形的实线表示，空心菱形指向的是代表“整体”的类。
组合关系:如果聚合关系中的表示“部分”的类的存在，与表示“整体”的类有着紧密的关系，例如“公司”与“部门”之间的关系，那么就应该使用“组合”关系来表示。在 UML 中， 用带有实心菱形的实线表示，菱形指向的是代表“整体”的类。
④实现关系。用一个带空心箭头的虚线表示。

（3）多重性问题

多重性是用来说明关联的两个类之间的数量关系的。
0…1;0…;1…1;1…;*

（4）类图

对于软件系统，其类模型和对象模型类图描述类和类之间的静态关系。与数据模型不同，它不仅显示了信息的结构，同时还描述了系统的行为。类图是定义其他图的基础。

（5）对象图

UML 中对象图与类图具有相同的表示形式。对象图可以看作是类图的一个实例。

5、交互图基础

交互图是表示各组对象如何按某种行为进行协作的模型。通常可以使用一个交互图来表示和说明一个用例的行为。

（1）顺序图

顺序图用来描述对象之间动态的交互关系，着重体现对象间消息传递的时间顺序。顺序图允许直观地表示出对象的生存期，在生存期内，对象可以对输入消息做出响应，并且可以发送信息。

（2）通信图

通信图用于描述相互合作的对象间的交互关系和链接关系。虽然顺序图和通信图都用来描述对象间的交互关系，但侧重点不一样。顺序图着重体现交互的时间顺序，通信图则着重体现交互对象间的静态链接关系。

（3）定时图

定时图是一种特殊形式的顺序图。

6、状态图基础

状态图用来描述一个特定对象的所有可能状态及其引起状态转移的事件。

7、活动图基础

活动图的应用非常广泛，它既可用来描述操作(类的方法)的行为，也可以描述用例和对象内部的工作过程。
活动图是由状态图变化而来的，它们各自用于不同的目的。活动图依据对象状态的变化来捕获动作(将要执行的工作或活动)与动作的结果。活动图中一个活动结束后将立即进入下一个活动(在状态图中状态的变迁可能需要事件的触发)。

(1)基本活动图。

判定:用菱形表示。
分支与组合:用粗线来表示分支和组合。

(2)带泳道的活动图。

(3)对象流。

在活动图中可以出现对象。对象可以作为活动的输入或输出，对象与活 动间的输入/输出关系由虚线箭头来表示。如果仅表示对象受到某一活动的影响，则可用不带箭头的虚线来连接对象与活动。

(4)信号。

在活动图中可以表示信号的发送与接收，分别用发送和接收标识来表示。 发送和接收标识也可与对象相连，用于表示消息的发送者和接收者。

8、构件图基础

构件图是面向对象系统的物理方面进行建模要用的两种图之一。它可以有效地显示一组构件，以及它们之间的关系。构件图中通常包括构件、接口及各种关系。

通常构件指的是源代码文件、二进制代码文件和可执行文件等。而构件图就是用来显示编译、链接或执行时构件之间的依赖关系的。

对源代码进行建模

这样可以清晰地表示出各个不同源程序文件之间的关系。

对物理数据库建模

用来表示各种类型的数据库、表之间的关系。

对可调整的系统建模

例如对应用了负载均衡、故障恢复等系统的建模。

在绘制构件图时，应该注意侧重于描述系统的静态实现视图的一个方面，图形不要过于简化，应该为构件图取一个直观的名称，在绘制时避免产生线的交叉。

9、部署图基础

部署图，也称为实施图，它和构件图一样，是面向对象系统的物理方面建模的两种图之一。构件图是说明构件之间的逻辑关系，而部署图则是在此基础上更进一步地描述系统硬件的物理拓扑结构及在此结构上执行的软件。部署图可以显示计算结点的拓扑结构和通信路径、结点上运行的软件构件，常用于帮助理解分布式系统。

(1)节点和连接。

节点代表一个物理设备及其上运行的软件系统，如一台 UNIX 主机、一个 PC 终端、一台打印机、一个传感器等。
节点之间的连线表示系统之间进行交互的通信路径，在 UML 中被称为连接。
通信类型则放在连接旁边的“《》”之间，表示所用的通信协议或网络类型。

(2)构件和接口。

在部署图中，构件代表可执行的物理代码模块，如一个可执行程序。

在面向对象方法中，类和构件等元素并不是所有的属性和操作都对外可见。它们对外提供了可见操作和属性，称之为类和构件的接口。界面可以表示为一头是小圆圈的直线。

软件系统的目的是为了解决问题。
定义问题的过程包括：

1
2

1、理解真实世界中的问题和用户的需要。
2、提出满足这些需要的解决方案的过程。

一、问题分析

1、在问题定义上达成共识

用标准化的格式将问题写出来。

2、理解问题的本质

通常用因果鱼骨图和帕累托图两种方式。

（1）因果鱼骨图

1
2
3

将问题简明扼要的写在右侧方框中。
确定问题潜在原因的主要类别，将他们连在鱼的脊骨上。
用头脑风暴法寻找原因并归类。

（2）帕累托图

采用直方图的形式，将问题的相对频率或大小从高到低排列，聚焦重要的问题。

1
2
3
4
5
6

明确问题。
找到问题的各种可能原因。
选择评价标准和考察期限，最常用的标准是频率和费用。
收集各种原因发生的频率和费用数据。
将原因按发生的频率或费用从大到小排列。
将原因排在横轴，频率或费用排在纵轴。

3、确认项目干系人和用户

1
2
3
4
5
6

系统的用户是谁？
系统的客户是谁？
那些人收到系统输出的影响？
系统完成收入使用后谁对她进行评估？
其他系统内部或外部的客户？
系统将来谁维护？

4、定义系统的边界

解决方案系统和现实世界之间的边界。在系统边界中，信息以输入和输出的形式流入系统，并由系统流向系统外的用户。

（1）上下文范围图

数据流图中的顶层图，它反映领域信息，能够清晰的显示出系统和相邻系统的职责，能够从宏观层面了解系统。

（2）用例模型

以参与者的角度描述“和系统进行交互的事物”。

1
2
3
4
5
6
7

谁会对系统提供信息？
谁会在系统中使用信息？
谁会从系统中删除信息？
谁将操作系统？
系统将会在哪里使用？
系统从那里得到信息？
哪些外部系统要和系统进行交互？

5、确定系统实现的约束

从约束源开始考虑。
进度、投资收益、人员、设备预算、环境、操作系统、数据库、主机和客户机系统、技术问题、行政问题、已有软件、公司总体战略和程序、工具和语言的选择、人员和其他资源限制等。

二、问题定义

1、目标

1
2
3
4
5

优势：目标不仅仅是解决问题，还要提供业务上的优势。
度量：度量优势的标准
合理性：获得的业务优势要大于工作量成本，才是合理的解决方案。
可行性：要探寻能够满足度量标准的解决方案。
可达成性：是否具备需要的技能，建设完成后是否能够操作它。

2、功能需求

系统必须做的事，功能需求源于业务需求。

3、非功能需求

系统必须具备的属性。
功能需求通常以动词为特征，非功能需求以副词为特征。
非功能需求主要包括：

1
2
3
4
5
6
7
8

观感需求
易用性需求
性能需求
可操作性需求
可维护性和可移植性需求
安全性需求
文化和政策需求
法律需求

需求分析阶段的主要任务是通过开发人员与用户之间的广泛交流，不断澄清模糊的概念，最终形成一个完整的、清晰的、一直的需求说明。（做什么）

在需求明确之后，下一步就是对软件系统进行设计。（怎么做）

一、需求分析的任务与过程

需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。
需求分析的步骤包括：

1
2
3

获取当前系统的物理模型
抽象出当前系统的逻辑模型
建立目标系统的逻辑模型

需求分析工作的4个方面

1
2
3
4

问题识别：用于发现需求、描述需求
分析与综合：对问题进行分析，并给出解决方案
编制需求分析的文档：输出《需求规格说明书》
需求分析与评审：主要对功能的正确性、完整性和清晰性等给与评价。

1、需求的分类

软件需求包括功能需求、非功能需求、设计约束三方面。

1
2
3

功能需求：系统必须完成的事，为了向用户提供有用的功能，产品必须执行的动作。
非功能需求：产品必须具备的属性或者品质，如性能、响应时间、可靠性、容错性、扩展性等。
设计约束：也叫限制条件、补充规约，比如必须采用国内自主知识版权的数据库等。

除了上面三种需求之外，在其他维度，还有业务需求、用户需求、系统需求。

1
2
3

业务需求：客户对系统、产品高层次的目标要求。
用户需求：用户使用产品必须要完成上面任务，通过访谈、调查，从用户角度出发的需求。
系统需求：从系统角度的需求，包括用特性说明的功能需求、质量属性、非功能需求及设计约束。

2、需求工程

创建和维护系统需求文档的所有活动，包括需求开发和需求管理两大工作。

（1）需求开发

包括需求捕获、需求分析、编写规格说明书和需求验证四个阶段。
需求开发是目标，是主线，是努力掌握客户对系统的需求。

（2）需求管理

包括需求基线、处理需求变更、需求跟踪等。
需求管理是支持，是保障，是对需求的变化进行管理的过程。

2、需求分析方法

根据分析方法发展的历史，分为

1
2
3
4

结构化分析方法
软系统方法
面向对象分析方法
面向问题域的分析

二、如何进行系统设计

系统设计与其说是在设计，不如说是在选择和妥协。
妥协，就是在各个系统目标之间找到一个平衡点。系统目标包括但不限于功能、性能、健壮性、开发周期、交付日期等，但这些目标往往都是矛盾的。
没有一个设计者会完全重新开始设计一个系统，他们总参考多个与目标系统相类似的系统，再从中进行甄别、取舍和补充来作为新系统的设计。
要成为优秀的设计者，了解、掌握、消化、总结前人和自己以前的设计成果是最好的、也是唯一的方法。

优秀的系统设计一般在以下几个方面都很出色：

1
2
3

组建的独立性。做到高内聚、低耦合。
例外的识别和处理。
防错和容错。

也有一些技术能够改进系统设计，这些方法包括：

1
2
3
4

降低复杂性
通过合约进行设计
原型化设计
错误树分析等

三、软件设计的任务与活动

软件设计时把软件需求变成软件表示的过程。
软件表示先是总体框架，然后在进一步细化，并在框架中填入细节。
1、从工程管理角度，软件设计可以分为两个步骤：
（1）概要设计：也称为高层设计
将软件需求转化为数据结构和软件的系统结构。
（2）详细设计：也称为底层设计
对结构表示进行细化，得到详细的数据结构与算法。
2、主要的设计方法比较
结构化设计的时代，主要设计方法包括Jackson方法和Parnas方法。结构化方法侧重于“模块相对独立且功能单一，使模块间联系弱、模块内联系强”；
Jackson方法是从数据结构导出模块结构。
Parnas方法是将可能引起变化的因素隐藏在有关模块内部，是这些因素变化时的影响范围受到限制。
近年来，对象技术凭借数据的高效封装和良好的消息机制，实现了高内聚、低耦合，成为现代软件设计的主流方法。

软件重用是一种重要的开发方法，虽然还不成熟，但现在已经有一些重用技术（中间件、应用服务器）改变了开发过程。

软件重用

软件产品是抽象的，可以无限复制的，因此重复利用可以节约人力物力，提高开发效率、降低成本、缩短开发周期、提高软件质量。
软件重用可以是软件产品、源程序、文档、设计思想甚至是领域知识。

常见的软件重用形式包括：

1
2
3
4
5
6
7

源代码重用
架构重用
应用框架重用
业务建模重用
文件及过程重用
软构件重用
软件服务重用

构件技术

构件又称为组件，是自包容、可复用的程序集。构件整体向外提供统一的访问接口，外部只能访问接口，不能直接操作构件内部。

自包容是指构件本身是一个功能完整地独立体，构建内部与外部界限明确，可独立配置和使用。

基于架构的软件设计ABSD

三个基础

1
2
3

功能分解，ABSD使用已有的基于模块的内聚和耦合技术。
通过选择架构风格来实现质量和业务需求。
软件模板的使用

ABSD方法的输入

1
2
3
4
5
6

抽象功能需求：对功能需求进行抽象，在获取需求的时候，需要考虑到所有最终用户。
用例：用例是对功能需求的具体化。在架构设计阶段，对用例进行分组，设置优先级，重要的用例才有用。
抽象的质量和业务需求：
架构选项：对于每个质量和业务需求，我们都要列举能够满足该需求的所有可能得架构。
质量场景：质量场景是质量需求的具体化。同样，需要对质量场景进行分组、设置优先级，验证最重要的质量场景。
约束：

基于架构的软件开发模型ABSDM

ABSDM把基于架构的软件过程划分为架构需求、架构设计、架构文档化、架构复审、架构实现、架构演化等六个子过程。

一、架构需求

需求是用户对软件系统在功能、行为、性能、设计约束等方面的期望，架构需求受技术环境和架构设计师的惊艳影像。

获取需求

架构需求一般来自于 系统的质量目标、系统的业务目标、系统开发人员的业务目标。获取架构需求的目的是为了让开发出来的软件能够满足用户业务上的功能需求。

标识构件

标识构件的目的是为了生成系统的初始逻辑结构。

1
2
3

生成类图
对类进行分组
把类打包成构件

需求评审

评审的主要内容是需求是否是真实需求、类的分组是否合理、构件是否合理。

二、架构设计

架构设计是一个迭代的过程。

提出架构模型

在架构初期，最重要的是确定架构风格，即使这个模型是理想化的，但该模型为将来实现和演化过程建立了目标。

把已标识的构建映射到软件架构中

分析构件之间的相互作用

产生软件架构

设计评审

三、架构文档化

大多数架构都是抽象的，是由一些概念上的构件组成。
文档是在系统演化的每一个阶段、系统设计和开发人员的通信媒介，视为验证架构设计和提炼或修改这些设计的基础。
架构文档化的主要输出结果是《架构需求规格说明书》和《测试架构需求的质量设计说明书》两个文档。

四、架构复审

目的是标识潜在风险，及早发现架构设计中的缺陷和错误。包括架构是否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构建划分是否合理、文档表达是否明确、goUI结案设计师够满足功能和性能的需求等。

五、架构实现

六、架构演化

由于最终用户的需求可能变化、移植时需求产生变化等情况，就必须对架构进行修改，以适应新的软件需求。

需求变化归类

让变化的需求与已有构建对应，对应不到的变动，做好记录，在后续创建新的构件应该这部分变化的需求

架构演化计划

在改变原有架构之前，必须制定一个周密的架构演化计划，为后续演化开发工作做指南。

构件变动

在演化计划的基础上新增、修改或者删除构件，根据需求变化归类决定对构件新增修改或删除。最后对构件进行功能性测试。

更新构件的相互作用

更新构建之间的控制流程

构建组装与测试

通过工具把构建的实现体组装起来，完成真个软件系统的连接与合成。最后进行整体功能和性能测试。

技术评审

评审是否符合用户需求，如果不符合，则在2-6步进行迭代。

演化后的架构

将演化后的架构在原来系统上所做的所有修改必须集成到原来的架构中，完成一次演化过程。