目录
5.3.6 IPO图（input/process/output）
真题：
名词解释：回归测试；MVC模式
简答：瀑布模型特点
瀑布模型当今时代还有意义吗？自己观点
5.1 软件和软件工程
5.1.1概念
软件 = 程序+数据+相关文档（是计算机系统中与硬件相互依存的另一部分）
程序：按事先设计的功能和性能要求执行的指令序列
数据：使程序能政策操纵信息的数据结构
文档：与程序开发、维护、使用有关的图文材料
特点：
发展：
软件工程：是指导计算机软件开发和维护的工程学科
是从管理和技术两方面来研究如何更好开发和维护计算机软件。
三要素：工具（工作环境）、方法（怎么做）、过程（框架，工作步骤）
5.1.2 软件危机
定义：计算机软件的开发和维护过程中所遇到的一系列严重问题
表现：开发成本和进度估计不准
用户对已支付软件不满意
质量靠不住
可维护性差
没有适当文档资料
产生原因：软硬件生产力发展不平衡；软件本身的特点；软件开发和维护方法不正确
解决办法：正确认识“软件”；认识“软件开发”；研究软件开发的技术手段；研究软件开发的管理办法
根本途径：解放和发展软件生产力；
节俭工业化模式，不断重用，提升技术水平；
提高过程管理能力，逐步解决软件危机
5.1.3 软件生存周期
定义：软件从产生、发展、到成熟，直至衰亡
生命周期方法学：
5.1.4 软件过程模型
- 瀑布模型
特征：顺序性、依赖性；推迟实现观点；质量保证观点。
优点：适用于用户需求明确、完整、无重大变化的软件开发项目
缺点：“文档驱动”：难以按顺序、难以清楚给出所有需求、要有耐心
缺乏灵活性、无法解决需求不明确问题、用户不经过实践、提出完整准确需求不切实际
例子：医疗保健软件：医疗保健软件的开发同样需要遵循瀑布模型，以确保软件的精度和安全性。例如，某些用于病人诊断、治疗或健康管理的软件，就需要通过瀑布模型来确保其在处理敏感数据时的安全性和准确性。
- 快速原型模型
快速建立用户主要需求的原型模型，取代形式的、僵硬的、大量的规格说明，反复由用户评价修正需求，开发出最终产品。
原型：是使用样机，使用户可以通过实践获得对未来系统的概念，可以更准确提出要求。
优点：确定需求优于瀑布（要和用户交互）；学习性，开发和用户了解系统；适用于需求不明确、开发人员无法确定算法、交互等很多问题的时候
缺点：为了使原型模型尽快工作，没有考虑软件总体质量和长期的可维护性；为了演示，可能用不合适的系统、语言、算法；开发过程不便管理
有效使用原型模型的方式：建造原型仅用于定义需求，实际软件在充分考虑质量和可维护性后才被开发。
- 增量模型
每个线性序列产生软件的一个可发布的增量版本，后一个版本是对前一版本的修改和补充。
区别：瀑布模型和快速原型模型一次性满足所有需求提交给用户；增量模型分批提交产品。
优点：短时间向用户提交可完成有用工作产品；用户有充裕时间学习适应产品 ；软件结构必须开放，方便添加新构建
缺点：并行开发构建可能不能集成，软件必须有开放式体系结构
其灵活性容易退化成边做边改模型，从而使软件开发的过程控制失去整体性
适用范围：已有产品升级或者新版本开发
对于完成期限严格要求
对开发的领域比较熟悉而且已有原型模型
- 螺旋模型：瀑布模型+增量模型，加入风险分析，常指导大型软件
基本思想：降低风险
优点 ：对可选方案和约束条件的强调有利于已有软件的重用；减少过多测试或测试不足；维护和开发没有本质区别。
缺点：需要风险评估经验；主要适用于内部开发的大规模软件项目；迭代增加，工作量和成本增加。
- 喷泉模型
迭代：各开发活动常常重复工作多次，相关的功能在每次迭代中，不断加入演进的内容。
无间隙：开发活动之间不存在明显的边界。
5.1.5 软件设计
评判标准：分层构架；模块化；抽象；高内聚，低耦合；简单借口；可复用
模块：数据说明、可执行语句等程序对象的集合
模块作用域：受该模块内一个判定影响的所有模块的集合
模块控制域：这个模块本身和所有直接或间接从属它的模块的集合
5.2 可行性研究
目的：用最小的代价在尽可能短的时间内确定问题能否解决。
技术可行性：技术能否满足需求，新技术能否获得（风险、资源】技术）
经济可行性：成本和效益（经济效益、社会效益）
纯收入：整个生命周期内，系统的累计经济效益（折合成现在值）与投资额之差
操作可行性：用户使用、时间进度、组织和文化
5.3 需求分析
5.3.1需求分析技术 和 方法
需求工程（传统需求分析）：获取需求、需求分析与建模、确认需求、进化需求
获取需求技术：面谈、问卷调查、需求专题讨论会、观察用户的工作流程、原型化方法、基于用例的方法
需求分析与建模：需求分析、需求建模、需求规格说明
需求分析技术：分解、抽象、多视点
验证软件需求的正确性：一致性、现实性；完整性、有效性（用户参与，原型系统）
需求分析方法：
功能分解方法：人工完成，无法对描述的准确度进行验证，难以适应需求变化。
结构化分析方法（SA）：面向数据流。功能分解原则；自顶向下，逐步求精。由于用户功能经常改变，系统框架结构不稳，设计回溯到需求困难。
信息建模法（ER图）：从数据角度实现现实世界建立系统 的信息模型。实体、属性、关系
面向对象的分析方法（OOA）:识别问题域内的对象，分析他们之间的关系，建立起三类模型。
问题分析法（PAD）：从目标系统输入、输出数据结构入手，导出基本处理框，分析处理之间的先后关系；再an先后关系逐步综合处理矿，直到整个PAD图
用户使用软件的三种倾向：软件运行；软件修改；软件转移
5.3.2 结构化分析方法：SA
SA：分解化简问题，物理与逻辑表示分开，进行数据和逻辑的抽象
描述方法：分层DFD图、数据字典、描述加工逻辑的结构化语言、判定表和判定树
模型核心：数据字典DD
数据模型：ER图
功能模型：分层DFD数据流图
行为模型：状态转换图
5.3.3 DFD & DD数据流图和数据字典
数据流图：用符号描绘信息在系统中流动的情况。描绘系统的逻辑模型，图中没有具体的物理元素。
通过功能分解完成数据流图的细化
作用：便于用后表达功能需求和数据需求及其联系
便于两类人员共同理解现行系统和规划系统的框架
清晰表达数据流情况
利于系统建模
原则：数据守恒与数据封闭：每个加工既有输入又有输出，整个系统也是
加工分解：每个加工每次分解最多不超过7个子加工，分解到基本加工位置
子图、父图平衡：两者加工的输入输出应相同
合理使用文件：文件作为加工之间的交界面时必须画出来
数据字典DD & 加工说明
定义：存放所有数据的定义，即对所有数据结构的描述。是关于数据信息的集合
作用：确保开发使用统一的数据定义
分阶段的工具。结构化分析中，DD是给数据流图上每个成分以定义和说明
条目：数据流、数据项、文件、加工（4个）
加工：至少包含一个输入输出流去
*
加工说明：
三种描述方法：
结构化语言：外层（顺序、选择IF-THEN-ELSE | CASE-OF-ENDCASE、循环WHILE-DO、REPEAT-UNTIL）+内层
判定表：条件框、操作框、条件条目、操作条目
判定树：
5.3.4 状态转换图（状态机
5.3.5 层次方框图
5.3.6 IPO图（input/process/output）
5.4 软件设计基础
5.4.1 软件体系结构
软件设计是软件需求和软件实现之间的桥梁。这个阶段的主要任务是：1）软件体系结构设计；2）数据结构设计；3）用户界面设计；4）算法设计
设计任务也可分为总体设计和详细设计。
结构设计和模块过程设计。
两个阶段：系统设计：确定系统具体实现方案
结构设计：确定软件结构
模块独立性：模块具有独立功能且和其他模块没有过多作用
两条理由：1、容易分工合作2、容易测试和维护、修改工作量小，传播错误小，扩充功能更容易
两个定性标准：内聚性：模块内数据关系越紧密越好
耦合性：模块间数据关系越松散越好
软件设计评判标准：分层构架；模块化；抽象；高内聚，低耦合；简单借口；可复用（6个）
总体设计的基本原则（6条）：模块化；抽象；逐步求精；信息隐藏；局部化；模块独立。
目标：高内聚低耦合的软件模型。
内聚：模块内元素彼此紧密结合程度
类型：功能内聚：各部分功能是某功能必不可少的部分
顺序内聚：模块内处理元素同某功能密切相关，顺序执行
通信内聚：
过程内聚：模块内处理元素相关，特定顺序执行
时间内聚：多功能模块，要求所有功能同时进行
逻辑内聚：一模块完成功能在逻辑上属于一类
偶然内聚：模块内各部分没联系，或很松散
耦合：不同模块间互联程度的度量
耦合原则：尽量使用数据耦合，少用控制耦合，限制公共环境耦合，完全不用内容耦合
类型：非直接耦合：两个模块可以独立工作，不需要另一模块
数据耦合：模块间通过参数交换数据信息
控制耦合：模块间通过参数交换控制信息，相对紧密
公共环境耦合：两个或多个模块通过一个公共环境作用（一送一取；两个既送又取）
内容耦合：一模块访问另一模块内部信息；一模块不通过正常接口转入另一模块；部分代码重叠（汇编程序）；一模块多个入口
软件体系结构：确定系统的组织结构和拓扑结构，显示系统需求和构成元素之间逻辑关系，提供设计决策的基本原理
过程：系统分解、控制建模、模块分解
设计元素：构件：基本功能部件
连接件：组件间链接和交互关系
约束：组件的元素应满足的条件和组件经由连接件组装时应满足的条件
常见软件体系结构：仓库模式、客户机/服务及、分布式对象结构、抽象机模型
- 仓库模型（容器模型）
特点：集中式。子系统可以直接访问中央数据仓库存储的共享数据，子系统间紧密耦合。子系统有自己的数据，子系统间通过消息传递实现数据交换。
优点：共享大数据量；子系统不用关系其他子系统如何使用它产生的数据；易于新子系统集成。
缺点：必须有一致的数据视图，会影响整个系统的性能；子系统改变使产生的数据结构也可能改变；统一数据库结构影响子系统效率。
- 客户机/服务器模型C/S
特点：分布式。发请求、得结果的模式。包含3个相对独立的逻辑组成部分
两层模型：数据表示和处理逻辑分开，但应用逻辑和两端之一是紧密耦合的，不适宜多用户、多数据库，是非安全的网络环境。
三级/多级模型：
- 分布式对象结构
软件总线的中间件是对象请求代理（ORB）。分布式对象结构有很好的的开放性和透明性，用户可以很方便的在总线上添加、更新、删除组件对象
优良特性：可在系统部署完成后在考虑服务的分布和如何提供服务的问题。
有开放式结构，提供了很好的灵活性和可伸缩性。
可动态分配。
- 抽象机模型（分层模型）
用于建立子系统的接口模型，每层提供一组服务，定义一个抽象机。
5.4.2 结构化分析方法SD
结构化分析方法（SD）：与结构化分析（SA）和SP前后衔接，是结构化开发的核心
阶段：
总体设计：分解模块，确定模块功能和系统模块的层次结构。模块结构图和模块功能说明。
详细分析：对每个模型过程描述。伪代码、流程图、N-S图、PAD图等
步骤：
-
-
- 从DFD数据流图导出初始的模块结构图（SC）。
-
深度：控制的层数
宽度：同一层的个数
中心变换型-变换分析
抓住“逻辑输入”、“变换中心”、“逻辑输出”。
-
-
-
- 设计上层模块，抓住主加工和它的一个输入与一个输出
-
-
-
-
-
- 二级分解，自顶向下，逐步细化。为第一层的输入、输出、处理设计他们的从属模块，展开
-
-
事务处理型-事务分析
-
-
- 按照SD法设计总则，改进模块结构图
-
尽可能建立功能模块（满足信息屏蔽的强内聚模块）；
消除重复功能；
模块的作用范围和控制范围；
模块大小适当；
模块扇入扇出数不易太多；
5.4.3 详细设计
详细设计：开发一个可以直接转换为程序的软件表示，对系统每个模块内部过程进行设计和描述。任务是算法设计。
以结构程序设计为基础。
常用工具：程序流程图、结构化流程图（N-S）、PAD问题分析图、PDL过程设计语言（伪码）、判定树/表等
5.4.4 程序流程图
循环标准符号 注解符
多选择判断
5.4.5 NS盒图（结构化流程图）
5.4.6 PAD问题分析图
5.4.7 过程设计语言PDL伪码
用正文形式表示数据和处理过程设计工具。
是一种用于描述模块算法设计和处理细节的语言。
外层：顺序（避免复合语句）、选择IF-THEN-ELSE-ENDIF | CASE-OF-ENDCASE、循环WHILE-DO、REPEAT-UNTIL：
内层：灵活
5.4.8 程序控制流图
过程设计语言：伪码（PDL）用正文形式表示数据和处理过程设计工具
根据过程设计结果画相应流图，描述程序控制流
5.4.9 判定表 & 判定树
判定表：表的右上部分中T表示它左边那个条件成立，F表示条件不成立，空白表示这个条件成立与否并不影响对动作的选择。判定表右下部分中画X表示做它左边的那项动作，空白表示不做这项动作。
判定树：是判定表的变种，也能清晰地表示复杂的条件组合与应做的动作之间的对应关系。
5.5 程序设计语言和编码
编码阶段：善于积累编程经验，使编出的程序清晰易懂，易于测试与维护，从而提高软件质量。
5.5.1 结构化程序设计SP
基本思想：自顶向下、逐步求精。
基本原则：功能的分解和抽象
主要特点：
自顶向下、逐步求精：符合人类解决复杂问题的普遍规律，从而显著提高软件开发的效率。先全局后局部，先抽象后具体，层次清晰，易读易懂易验证，提高程序质量。
单入口和单出口的控制结构：由顺序、选择、循环三种基本控制结构组成，保证了程序结构清晰，提高代码可重用性。
5.5.2 算法和程序效率
影响程序效率的因素：
算法对效率的影响：算法的时间复杂度
存储效率：操作系统的存储管理方式
输入输出效率：提高输入输出速度，减少出错率
5.6 软件测试
5.6.1 软件测试概述
目的：
开发工作前期不可避免会引入错误，测试的目的是为了发现和改正错误，对某些涉及人的生命安全或重要军事、经济目标的项目显得尤为重要。
原则：
-
- 第三方测试原则
- 注重测试用例选择：输入数据的组成（输入数据、预期输出）；既有合理输入也有不合理输入；既能检查应完成的任务也能检查不应完成的任务；长期保存测试用例
- 注意群集现象（80%的缺陷集中在20%的模块中）
步骤：
方法：静态：人工的、非形式化的方法对程序进行分析和测试。
桌前检查；代码会审；步行检查：调用图、数据流分析图；
调用图：
数据流分析图：
动态：通过选择适当的测试用例，执行程序。
白盒法：分析程序的内部逻辑结构，注意选择适当的覆盖标准，设计测试用例，对主要路径进行尽可能多的测试。
黑盒法：不考虑程序的内部结构与特性，只根据程序功能或程序的外部特性设计测试用例。
5.5.2 白盒法
定义：
详情见PPT
5.5.3 黑盒法
定义：
等价分类法：
基本思想：根据程序的I/O特性，将程序的定义域划分为有限个等价区段 —“等价类”，从等价类中选择出的用例，具有“代表性”。
等价类：
有效等价类：对于程序的规格说明，是合理的、有意义的输入数据构成的集合。
无效等价类：对于程序的规格说明，是不合理的、没有意义的输入数据构成的集合。
例如：
再例如，黑盒测试：
黑盒和白盒的区别：
黑盒不清楚系统内部，白盒清楚
黑盒测试系统功能，白盒测试系统程序接口与结构
黑盒穷举输入进行测试，白盒穷举路径进行测试
5.5.4 测试策略
单元测试（模块测试）：检验每个模块是否实现了规定的功能，保证其能正常工作（白盒）
内容：模块接口、局部数据结构、重要执行路径、出错处理通路、边界条件
集成测试：已测试过的模块组装起来，对与设计相关的软件体系结构进行测试（白盒+黑盒）
形式：
*渐增集成：把下一个要测试的模块和已经测试好的模块结合起来进行测试，每次增加一个模块。
孤立的策略：孤立的单元测试策略不考虑每个模块与其他模块之间的关系，为每个模块设计桩模块和驱动模块，每个模块进行独立的单元测试。
桩模块：替代被测试模块的模块，返回给测试模块所需要的信息
驱动模块：模拟被测试模块的上级，接受被测试模块的测试结构并输出
自顶向下：可以尽早发现系统主控方面问题；无法验证桩模块是否完全模拟了下属模块功能
自底向上：驱动模块容易编写装模块，能尽早查出底层设计较复杂的算法和实际IO模块的错误；最后才看到系统主控方面
非渐增式集成：分别测试每个模块，再把所有模块按照设计要求结合成所要的程序。
回归测试（重新执行已测试过的某子集，确保变化没带来非预期副作用）
测试重点：连接各个模块，接口的数据是否会丢失
单独一个子模块的功能是否会对另一个子模块产生不利影响
各个子模块组合能否达到预期要求
全局数据结构是否有问题
单个模块误差累计是否放大到不可接受
（白盒+黑盒）
确认测试：又称为有效性测试或功能测试。其任务是验证系统的功能、性能等特性是否符合需求规格说明。
α测试：是在开发机构的监督下，由个别用户在确认测试阶段后期对软件进行测试，受控环境下，目的是评价软件的FLURPS（功能、局域化、可使用性、可靠性、性能和支持），注重界面和特色。
β测试：由支持软件预发行的客户对FLURPS进行测试，主要目的是测试系统的可支持性。
5.7 软件维护
定义：系统的可维护性是衡量一个系统可修复性和可改进性的难易程度。
提升方法：建立明确软件质量目标
利用先进的软件开发工具和技术
建立明确的质量保证工作
选择可维护的程序设计语言
改进程序文档
四种维护类型：
完善性维护：扩充原有系统的功能，提高原有系统的性能，满足用户需要。
纠错性维护：对测试阶段没发现、投入使用后才暴露的错误的测试、诊断、定位、纠错和验证、修改的回归测试的过程。
适应性维护：使运行的软件能适应运行环境的变动而修改软件的过程。
预防性维护：为进一步改善软件的 可靠性或易维护性，或为将来的维护奠定更好的基础而对软件进行的修改。
软件维护技术：
面向维护的技术：在软件开发阶段用来减少错误，提高软件可维护性（可测试、可理解、可修改）。设计软件开发所有阶段。
软件支援技术：在软件维护阶段用来提高维护工作的效率和质量的金丝狐。主要用到测试阶段的技术。（信息收集、错误原因分析、软件分析与理解、维护方案评价、代码与文档的修改、修改后的确认）
5.8 面向对象的设计方法
5.8.1 基本概念
面向对象：强调面向客观世界和问题域中的事务，用人类普遍的思维方法，直观、自然描述客观世界的有关实物。
以数据为主线，把数据和处理相结合的方法。把对象作为由数据和可以试驾在这些数据上的操作所构成的统一体。
面向对象技术的特点：一致性（所有阶段综合考虑）；连续性（使用的方法、技术连续，符合人类思维）；稳定性（OOA、OOD、OOP有机结合）；可重用性（对象具有封装性和信息隐蔽）。
基本特征：抽象性、封装性、继承性、多态性
面向对象 = 对象(object) + 分类(classification) + 继承(inheritance) + 通过消息的通信(communication with messages)
对象 = 属性+操作->封装；特性是封装性和继承性
类：相同属性和相同操作的对象的合集；
消息：向对象发出的服务请求。消息=消息名+接收对象标识+服务标识+消息和方法+输入信息+回答信息
封装：把客观事物封装成抽象的类，并且类可以把自己的方法和数据，只让可信的类或对象操作，对不可信的类信息隐藏。
继承：使用现存类的所有功能，在无需重新编写原来的类的情况下对这些功能进行扩展。单重继承、多重继承
使代码具有可重用性和可扩展性。
多态：允许将子类类型的指针赋值给父类累心的指针。相同的操作或函数作用不同对象有不同结果。
实现接口的可重用性。
5.8.2 OOA/D 面向对象分析 & 设计
OOA：
目标：是完成所求问题的分析，确定系统“做什么”，并建立系统的模型
特点：利于对问题和系统责任的理解
利于人员之间的交流
需求变化的适应性较强
支持软件复用
基本任务：
步骤：获取需求
整理需求
建立模型
（书写需求规格说明书复审）
（抽取用户需求建立问题域精确模型）
模型：功能模型：“做什么”用例图
对象模型：静态结构，定义实体，类图、对象图
动态模型：交互过程，状态图、顺序图
层次：主题层
类与对象层
结构层
属性层
服务层
优点：加强对问题域和系统责任的理解
改进与分析有关各类人员之间的 交流
对需求的变化有较强的适应性
支持软件复用
贯穿软件生命周期全过程的一致性
实用性
有利于用户参与
OOD：OOA创建的分析模型转为设计模型，解决“如何做”的问题
定义：是面向对象方法在软件设计阶段应用和扩展的结果
基本任务：系统设计：将分析模型划分为若干子系统（分层/分块）
对象设计：为每个类的属性和操作进行详细设计
消息设计：设计连接类与它的协作者之间的消息规约
优化与复审：高效率和建立良好的继承结构
5.8.3 Coda方法
5.8.4 Booch方法
Booch方法：静态模型（逻辑模型、物理模型）、动态模型（状态图、时序图）
5.8.5 OMT方法
面向对象的建模技术OMT：对象模型、动态模型、功能模型
- 对象模型
静态结构；基本元素是对象（类）、它们之间的关系
- 动态模型
逻辑结构；某时刻对象及其联系的改变；包括状态图和事件追综图。
- 功能模型
系统内部数据的传递与处理；“做什么”；表明值之间的依赖关系及其相关功能；分层数据流图、用况图
5.8.6 UML统一建模语言
（对象技术、模型、OOA/D的关键理论和技术、最佳实践）
UML是一种面向对象的建模语言，是图示化、说明、构造一个软件系统并生成其文档的标准语言。
是在Booch、OMT、OOSE等面向对象的方法及其它许多方法与资料的基础上发展起来的。UML表示法集中了不同的图形表示方法，剔除了其中容易引起的混淆、冗余或者很少使用的符号，同时添加了一些新的符号。
特点：统一标准、面向对象、可视化、表达能力强
UML模型：功能模型：用户角度展示系统功能。用例图（用况图）
对象模型：对象、属性、关联、操作等，展示系统结构和基础。类别图、对象图
动态模型：系统内部行为。时序图、活动图、状态图
视图：
用例视图：定义系统的外部行为，是最终用户、分析人员和测试人员所关心的。定义系统的需求，因此约束了描述系统设计和构造某些方面的其他所有视图。
设计视图：描述支持用例视图中规定的功能需求的逻辑结构。由程序组件的定义，主要是类、类包含的数据、类的行为和类之间交互的说明组成。
实现视图：描述构造系统的物理组件，包括可执行文件、数据库、代码库等内容。包含信息与配置管理和系统集成这类活动有关。
进程视图：包括形成并发和同步机制的进程和线程。
部署视图：描述物理组件如何在系统运行的实际环境（如计算机网路）中分布。
UML开发过程：
初启：发起人确定主要目标和范围，可行性分析和经济效益分析
细化：初步需求分析（用例图、领域模型类图、活动图）；初步高层设计（包图）；部分详细设计（交互图、精化类图）；部分原型构建（详尽交互图，明确属性和操作定义）
构造：用例和用例图；类图；交互图；状态图；活动图；包图；构件图；部署图。
移交：实际环境的试运行，根据用户修改意见少量调整
5.9 UML的模式应用
5.9.1 用例图
定义：从系统外部用户的观点看系统应具有的功能，描述角色和角色与用例之间的连接关系。
主要用于对系统、子系统、类的行为进行建模。只说明系统“做什么”，说明是谁使用系统，他们用系统可以做什么。
参与者：小人 用例（用况）：椭圆
5.9.2 类图
定义：描述系统的类，和各个类之间的关系的静态视图。
表示类、接口和他们之间的协作关系，是一种静态模型关系。
关系：泛化=实现》组合（复合）》聚合》关联》以来
5.9.3 对象图
对象：是一个类的实例，是具有具体属性值的一个具体事物。
对象图：是类图的实例，显示类的多个对象实例，描述对象之间的关系。
类图的变形，在对象下面加下划线，其他基本相同。
5.9.4 时序图（顺序图）
时序图是对象之间消息的传递
定义：描述基于时间的动态交互，重点在消息序列上，强调消息是如何在对象之间发送和接收的。
四个元素：对象、生命线、消息、激活
5.9.5 活动图
活动图是工作流中动作的顺序
定义：描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。
通过一系列操作将业务流程或软件进程以工作流的形式显示出来。这些操作可以由人、软件组件或计算机来执行。
5.9.6 状态图
定义：描述类的对象所有可能的状态，以及事件发生时状态的转移条件。
圆角矩形描述状态，还有初始状态和终止状态。
5.9.7 协作图（合作图）
一种交互图，强调的是发送和接收消息的对象之间的组织结构。显示了一系列的对象和在这些对象之间的联系以及对象间发送和接收的消息。说明系统的动态情况。
协作图和时序图的语义相通，可以相互转换。
5.9.8 组件图（构件图）& 配置图（部署图）
组件（构件图）和配置图（部署图）是面向对象系统的物理建模时使用的两种图。
2416
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
