《软件系统分析与设计》期末复习知识点总结

第一篇：《软件系统分析与设计》期末复习知识点总结

一、方法论模型。

1、BOOCH、OMT、OOSE、Coad-Yourdon（前三者组成UML）

2、UML包括9种图，分别为用例图、静态图（包图、类图、对象图）、实现图（构件图、部署图）、行为图（活动图、状态图、交互图(顺序图、协作图)）基本规范，泛化关联，包含关联，扩展关联

3、基本模型——类图、需求模型——用例图、辅助模型——其他各种图

4、两大工具：Rose、PowerDesigner

5、方法三要素：模型、工具和过程

6、结构化分析三视图模型E-R、DFD、STD

7、OMT方法的三大模型：对象模型、功能模型、动态模型

8、Coad/Yourdon方法的五大层次：对象-类、结构、主题、属性、服务

二、基本建模（类图与对象图）

1、类之间的关系：关联关系、依赖关系、泛化关系。

2、抽象类与接口：抽象类有些方法可以提供实现代码，接口所有的方法都没有提供实现代码。抽象类只能被继承，接口只能被实现。

3、类的版型：实体类（数据库、文件等）、边界类（如窗体、对话框）、控制类（协调交互）

三、需求建模（用例图）

1、参与者指系统以外的、需要使用系统或与系统交互的外部实体。可以分为：人、外部设备、外部系统。

2、参与者之间的关系：泛化关系，参与者与用例之间的关系：关联关系。用例之间的关系：泛化关系，包含关系，扩展关系。包含关系和扩展关系都是依赖关系的特例。

3、用例是对一个参与者使用系统的一项功能时所进行的交互过程的一个文字描述序列。是参与者可以感受到的系统服务或功能单元。

4、用例描述是一个关于参与者与系统如何交互的规范说明（包含用例用例名称、用例描述、基本事件流、参与者、前置后置条件等）

5、用例的进一步描述：活动图、顺序图（通信图）

四、行为建模（状态图与活动图）

1、行为模型包括：状态模型（状态图，单对象）、活动模型（活动图，多对象）、交互模型（顺序图，多对象）。

2、调用事件表示的是对操作的调用，变化事件一个布尔表达式变量的值发生变化。时间事件满足某一时间表达式的情况的出现。信号事件就是由一个对象异步地发送、并由另一个对象（即状态图所对应的对象）接收的已命名的实体。调用事件状态图内对象和外部对象都能发起，信号事件只能由外部发起。

3、对象处于不同的状态，导致后续要执行不同的操作。这些操作可能归属于不同的用例。一个用例的执行对应一个顺序图。顺序图刻画了多个对象之间的消息发送关系。需要多个用例的顺序图，来融合地描述一个对象的完整状态图。

4、活动表示的是某流程中的任务的执行，它可以表示某算法过程中语句的执行。

5、分叉表示的是一个控制流被两个或多个控制流代替，经过分叉后，这些控制流是并发进行的。汇合正好与分叉相反，表示两个或多个控制流被一个控制流代替。

6、泳道（swimlane）是活动图中的区域划分，根据每个活动的职责对所有活动进行划分，每个泳道代表一个责任区。关心的是其所代表的职责。

7、活动图用途：对业务过程进行建模。对某个方法具体过程建模。

8、状态与活动的区别：状态是一个对象所处的境况。通常是执行了一个（或多个）活动后的结局。活动是一段程序代码的执行，对应于若干个步骤的集成。不同的状态会导致不同的功能（对应于若干个活动）的执行。一个方法可能需要多个（也可以是一个）活动来完成。一个活动只能属于一个方法。一个用例对应于若干个活动。

五、交互建模（顺序图和协作图）

1、静态结构使用类图，动态结构使用顺序图、协作图、状态图、活动图。

2、对象：同类图中的对象，是类的实例

生命线：从对象图标向下延伸的一条虚线，表示对象存在的生命期 控制焦点（激活期）：对象执行一个动作的时间段 消息：对象间的一次通信

调用消息的发送者把控制传递给消息的接收者，然后停止活动，等待消息接收者放弃或返回控制。调用消息可以用来表示同步的意义。

3、顺序图一般对应一个用例。一个类中的职责对应该对象执行一个动作。

4、对象：同类图中的对象，是类的实例 ；链：对象之间的连接关系；消息：对象间的一次通信；对象生命周期：对象名称之后标以{new}约束表示创建对象，标以{destroy}约束表示销毁对象

5、协作图的建模同顺序图的建模，或者：可以从顺序图直接变换过来，或者：根据类图，画出对应的对象图。在链上附着消息。

6、顺序图和协作图的联系：都用于描述系统中对象之间的交互协作完成一项功能，彼此可以相互转换。区别：顺序图强调的是消息的时间顺序；协作图强调的是对象的空间位置关系。顺序图中有对象生命线和控制焦点；协作图中有路径，消息必须要有消息顺序号。顺序图可以表示生命线的分叉；协作图可以表示多对象、主动对象。

第二篇：软件系统分析与设计

第1章

软件工程基础知识 1.1软件工程知识体系

 软件需求（Software Requirements） 软件设计（Software Design）

 软件构造（Software Construction） 软件测试（Software Testing） 软件维护（Software Maintenance）

 软件配置管理（Software Configuration Management） 软件工程管理（Software Engineering Management） 软件工程过程（Software Engineering Process）

 软件工程工具和方法（Software Engineering Tools and Methods） 软件质量（Software Quality）

1.2软件生存周期与软件开发模型

 1.2.1 软件生存周期

 Boehm定义的软件生存周期模型

 GB 8566-1988定义的软件生存周期模型

 GB/T 8566-1995定义的软件生存周期过程模型  GB/T 8566-2001定义的软件生存周期过程模型  UP定义的软件生存周期模型

 1.2.2 软件开发模型

 瀑布模型（waterfall model）

 快速原型模型（rapid prototype model） 演化模型（evolutionary model） 增量模型（incremental model） 螺旋模型（spiral model）

 喷泉模型（water fountain model）

1.3软件质量模型与软件质量管理

 1.3.1 软件质量模型

 软件产品的内部质量、外部质量和使用质量  质量特性、质量子特性和度量

 功能性：适宜性、准确性、互用性、依从性、安全性  可靠性：成熟性、容错性、可恢复性  可用性：可理解性、易学性、可操作性  效率：时间特性、资源特性

 可维护性：可分析性、可修改性、稳定性、可测试性  可移植性：适应性、易安装性、一致性、可替换性

 1.3.2 软件质量管理

 质量需求分析  质量计划  质量保证  质量控制  质量改进

 软件质量管理体系

         

 

            

  

1.4软件配置管理

 1.4.1 软件配置项与基线

计算机软件配置项（CSCI）基线（baseline）

功能基线（functional baseline）指派基线（allocated baseline）产品基线（product baseline）

 1.4.2 软件配置管理过程

对象标识 版本控制 变化控制 配置审计 配置报告

1.5软件过程管理

 1.5.1 软件能力成熟度模型（CMM）

CMM的5个等级：初始级、可重复级、已定义级、已管理级、优化级 CMM的关键过程域（KPA）：需求管理、软件项目计划、软件项目跟踪和监控、软件子合同管理、软件质量保证、软件配置管理、组织级过程焦点、组织级过程定义、培训大纲、集成软件管理、软件产品工程、组间协调、同行评审、定量过程管理、软件质量管理、缺陷预防、技术变更管理、过程变更管理

 1.5.2 软件过程与软件能力成熟度评估

第一步，建立评估组 第二步，填写提问单 第三步，响应分析 第四步，现场考察

第五步，提出调查发现清单

第六步，制作关键过程域（KPA）剖面图

 1.5.3 软件过程改进

第一步，比较“目标状态”与“目前状态”，找出所有差距 第二步，确定改进目标 第三步，制定改进计划 第四步，执行改进计划

第五步，总结本轮改进经验，开始下一轮改进

1.6

小节

软件工程学是研究如何有效地组织和管理软件开发的工程学科。

软件产品所要经历的计划、分析、设计、编程、测试、维护直至被淘汰这样一个全过程被称为软件生存周期。用不同的方式将软件生命周期中的所有开发活动组织起来，可以形成不同的软件开发模型。

软件质量就是软件与明确地和隐含地定义的需求相一致的程度。软件质量管理是指软件开发机构为保证软件项目满足客户需求所要实施的质量活动。软件配置管理是在软件的整个生命期内管理变化的一组活动，目标是使变化更正确且更容易被适应。

软件过程是指人们用于开发和维护软件及其相关产品的一系列活动，包括软件工程过程和软件管理过程。软件过程管理的目的就是提升软件组织的提高软件开发能力。

 1. 1.    

                       

第2章

项目管理基础知识 2.1项目与项目管理  2.1.1 项目

项目是在特定条件下、具有特定目标的一次性任务，是在一定时间内、满足一系列特定目标的多项相关工作的总和。项目的临时性 项目的独特性 项目的渐进性

2.1.2 项目管理

项目管理就是将各种知识、技能、工具和技术应用于项目之中，以达到项目的要求。项目范围 项目时间 项目成本 项目质量

2.2项目管理过程与过程组  2.2.1 过程与过程组

过程就是一组为了完成一系列事先指定的产品、服务或成果而需执行的互相联系的行动和活动。软件项目管理过程可归纳为五个过程组。启动过程组（initiating process group）规划过程组（planning process group）实施过程组（executing process group）

监控过程组（monitoring and controlling process group）收尾过程组（closing process group）

 2.2.2 项目管理过程的交互作用

项目管理过程并不是互不相干的一次性事件

项目管理过程组之间是一种前后衔接、承前启后的关系

项目管理过程组之间有时又是一种时间交错、空间并行的关系 项目管理过程组之间还是一种信息收集、存储、处理和传递的关系 某些过程组的关联具有重复迭代性

规划过程组、执行过程组和监控过程组之间形成一种闭环的关系 过程组的交互作用往往还会跨越项目阶段 项目阶段和过程之间有相互联系

 2.2.3 项目管理过程的裁剪

不同类型的软件项目应选用不同的项目管理过程 不同阶段的软件项目应选用不同的项目管理过程 不同软件项目的管理过程会有不同的具体过程 不同软件项目的管理过程会有不同的具体过程顺序 不同软件项目的管理过程会有不同的条件与约束 不同软件项目的管理过程会有不同的简化程度 不同软件项目的管理过程需要不同的集成程度 项目变更会使项目管理过程随之变化

2.3项目管理知识体系

项目综合管理 项目范围管理

          项目时间管理 项目成本管理 项目质量管理 项目人力资源管理 项目沟通管理 项目风险管理 项目采购管理

2.4小节

项目管理就是将项目管理知识、技能、工具和技术应用于项目活动之中，可以将软件项目管理活动视做一系列相互联系的过程。

项目管理过程可归纳为5个过程组：启动过程组、规划过程组、实施过程组、监控过程组与收尾过程组。

项目管理包括9个知识领域：项目综合管理、项目范围管理、项目时间管理、项目成本管理、项目质量管理、项目人力资源管理、项目沟通管理、项目风险管理与项目采购管理。

第3章

软件开发技术 3.1软件开发平台

 3.1.1 Microsoft.NET平台

Microsoft.NET Framework：.NET CLR（通用语言运行环境）；.NET BCL（基础类库）；ASP.NET；ADO.NET。

Microsoft Visual Studio.NET：ADO.NET组件；XML数据组件；Windows表单组件；ASP.NET应用服务；ASP.NET Web表单；Web服务支持。

 3.1.2 J2EE平台

组件-容器：搭建体系架构平台标准服务 多层应用模型

3.1.3 Microsoft.NET与J2EE的异同

类似的平台基础构造 相同的三层/多层体系 不同的移植、性能和扩展 在Web支持方面的比较 第三方厂商的支持 潜在的市场

3.2中间件技术  3.2.1 中间件简介

终端仿真/屏幕转换中间件 数据访问中间件 远程过程调用中间件 消息中间件 交易中间件 对象中间件

Web服务器中间件 安全中间件

 3.2.2 消息代理中间件  

     1.  1.       

        

              



 构件化的结构

可恢复性、易于管理、灵活性 具有数据转换设施。可靠高效的通信 多样的管理能力 丰富的应用开发环境

 3.2.3 面向数据库的中间件

ODBC JDBC 数据库网关

3.3构件技术  3.3.1 构件库

构件的存储

构件的分类与检索机制 构件库的编目

构件库的管理和维护

 3.3.2 构件模型

3C模型

刻面（Facet）模型 青鸟模型

 3.3.3 构件的属性与特点

构件是可独立配置的单元，构件必须自包容。

构件强调与环境和其他构件的分离，因此构件的实现是严格封装的，外界没机会或没必要知道构件内部的实现细节。

构件可以在适当的环境中被复合使用，因此构件需要提供清楚的接口规范，可以与环境交互。

构件没有个体特有的属性，最多仅有特定构件的一份副本。

 3.3.4 构件与中间件

中间件，本质上是对分布式应用的抽象，中间件与系统架构实际上是从两种不同的角度看待软件的中间层次。

中间件促进了构件化软件，基于中间件开发的应用系统是构件化的，中间件提供了构件的体系结构，极大提高了构件化软件开发的效率和质量。构件化的软件设计思想在中间件发展中起到了重要的作用。

3.4小节

Microsoft.NET平台和J2EE平台是目前最常用的两大软件开发平台。作为彼此竞争的应用平台，Microsoft.NET平台和J2EE平台在目标和体系结构上极其相似，但在实现上又完全不同。二者总的关系是：异中有同，同中有异。中间件是处于操作系统和应用程序之间的软件。中间件保持了平台的透明性，抽象了典型的应用模式。应用软件开发者可以基于标准的中间件进行再开发，而不必再考虑操作系统的问题。

构件是可复用的软件成份，可被用来构造其他软件。中间件促进了构件化软件，应用系统在中间件提供的环境中可以更好地集中于业务逻辑上，并以构件的形式存在。构件思想也反过来推动了中间件的发展。

第4章

软件项目规划

4.1项目策划

 1. 1.从政策导向中寻找项目机会 从市场需求中寻找项目机会 从技术发展中寻找项目机会 从特定事件中寻找项目机会

4.2项目可行性分析 4.2.1 技术可行性分析

     1.         项目的必要性分析

软件组织水平与能力分析 项目技术来源分析 与项目相关的专利分析

项目负责人及技术骨干的资质分析 项目总体技术方案分析 项目创新点分析 项目技术风险分析 项目技术成熟性分析

 4.2.2 项目投资及效益分析

项目投资预算分析 项目投资来源分析

市场需求与产品销售额分析

产品成本、利润与盈亏平衡点分析 投资回收期、投资收益率分析 社会效益分析

4.3项目论证、评估与立项

 4.3.1 项目论证与评估的基本概念

项目论证是指对拟实施项目技术上的先进性、成熟性、适用性，经济上的合理性、盈利性，实施上的可能性、风险性进行全面科学的综合分析，为项目决策提供客观依据的一种技术经济研究活动。

项目评估指在项目可行性研究的基础上，项目投资者或项目主管部门或其委托的第三方权威机构根据国家颁布的政策、法律、法规、标准和技术规范，对拟开发项目的市场需求、技术先进性和成熟性、预期经济效益和社会效益等进行评价、分析和论证，进而判断其是否可行的过程。

项目论证与评估的内容、程序和依据大同小异，只是侧重点稍有不同，有时不加区分或合并进行。

 4.3.2 项目可行性报告的真实性评估

项目申请单位的资质真实性评估 项目申请单位的财务真实性评估 项目申请单位的技术真实性评估 其他事项的真实性评估

 4.3.3 项目可行性报告的客观性评估

技术创新点的客观性评估

技术先进性与成熟性的客观性评估 





     

    信息安全措施的客观性评估

采用标准、规范的先进性、合理性评估 项目风险及应对方案的客观性评估 其他事项的客观性评估

 4.3.4 评估报告

 项目概况  评估目标  评估依据  评估内容

 评估机构与评估专家  评估过程

 详细评估意见

 存在或遗漏的重大问题  潜在的风险  评估结论

 进一步的建议

 4.3.5 项目立项

项目立项的决定应当由项目团队之外的、适当级别的、并为项目出资的项目发起人或投资人作出，通常以项目立项决定（通知）书、项目批文、项目许可证书和项目任务书等形式发布。

4.4项目开发计划

 1．引言  2．引用文件  3．项目最终成果  4．需求与约束

 5．系统开发总体计划  6．项目开发详细计划  7．进度表与活动网络图  8．项目组织与资源  9．培训

 10．项目估算  11．风险管理  12．支持条件  13．注解  14．附录

4.5小节

 软件项目规划的任务主要包括项目策划、可行性研究、论证、评估、立项与项目开发计划的制订工作。

 项目策划，也称项目机会研究，其目的是选择投资机会、鉴别投资方向。

 项目可行性分析的目的是确定以下问题：项目有无必要？能否完成？是否值得去做？  项目论证与评估的目的是审查项目可行性研究的可靠性、真实性和客观性，为项目主管部门或投资机构的立项决策提供科学依据。

 项目开发计划是项目规划阶段的重要成果，编写软件项目开发计划时可依据《GB/T 8567-2006 计算机软件文档编制规范》中的软件开发计划模版。

 

    









        

第5章

系统分析方法学 5.1系统需求分析与软件需求

系统需求：系统总体功能和业务结构；硬件系统需求；软件系统需求；硬件系统和软件系统之间的接口需求。软件需求：软件能力需求；软件外部接口需求；软件内部接口需求；软件内部数据需求；适应性需求；安全性需求；保密性和私密性需求；软件环境需求；计算机资源需求；软件质量需求；设计和实现的约束；数据需求；操作需求；故障处理需求；算法需求；相关人员需求；相关培训需求；相关后勤需求；包装需求；其他需求。

5.2结构化分析

结构化分析（SA）方法是一种面向数据流的需求分析方法，基本思想是自顶向下逐层分解。

数据流图（DFD）和数据字典（DD）是结构化分析最常用的工具。数据流图用来描述数据流从输入到输出的变换流程。

数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。

数据流图和数据字典共同构成系统的逻辑模型。

5.3原型化方法

 5.3.1 原型化方法与结构化方法的比较

结构化方法的假设：所有的需求都能被预先定义；修改定义不完备的系统代价昂贵且实施困难；项目参加者之间能够清晰进行准确的通信；静态描述或图形模型对应用系统的反映是充分的；结构化方法的生命周期的各阶段都是固有正确的。

原型化方法的假设：并非所有的需求在系统开发以前都能准确地说明；有快速的系统建造工具；项目参加者之间通常都存在通信上的障碍；需要实际的、可供用户参与的系统模型；需求一旦确定，就可以遵从严格的方法；大量的反复是不可避免的、必要的，应该加以鼓励。

 5.3.2 原型生命周期及其策略

原型生命周期划分：选择开发方法；识别基本需求；开发工作模型；模型验证；修正和改进；判定原型完成；差别细部说明；严格说明细部；判定原型效果；整理原型和提供文档。

原型化的策略：建立数据模型；利用组合工程；剪裁和粘贴；用系统举例；字典驱动；文档的自动化；小的原型化队伍；交互式开发平台；陈述性规格说明；终端用户报表生成器；专业原型化人员；开发人员参加原型化。

5.4面向对象的分析

 5.4.1 面向对象方法学概述

对象与封装 类

继承与多态性 消息通信

面向对象方法学的优点

 5.4.2 面向对象的分析方法

OMT方法简介 建立对象模型 建立动态模型 建立功能模型





  

       1.  1.    

     

5.5小节

系统分析涉及系统需求的获取、分析、规格说明和确认。系统需求可分为以下几个方面：系统总体功能和业务结构、硬件系统需求、软件系统需求、硬件系统和软件系统之间的接口需求。

常用的系统分析方法包括结构化分析、原型化方法和面向对象的分析。

第7章

系统分析文档

7.1系统/子系统需求规格说明

引言 引用文件

需求：要求的状态和方式；需求概述；系统能力需求；系统外部接口需求；系统内部接口需求；系统内部数据需求；适应性需求；安全性需求；保密性和私密性需求；操作需求；可使用性、可维护性、可移植性、可靠性和安全性需求；故障处理需求；系统环境需求；计算机资源需求；系统质量需求；设计和构造的约束；相关人员需求；相关培训需求；相关后勤需求；包装需求；其他需求；需求的优先次序和关键程度 合格性规定 需求可追踪性 非技术性需求 尚未解决的问题 注解 附录

7.2接口需求规格说明

引言 引用文件 需求

合格性规定 需求可追踪性 注解 附录

7.3软件需求规格说明

引言 引用文件

软件需求：要求的状态和方式；需求概述；需求规格；软件能力需求；软件外部接口需求；软件内部接口需求；软件内部数据需求；适应性需求；安全性需求；保密性和私密性需求；软件环境需求；计算机资源需求；软件质量需求；设计和实现的约束；数据需求；操作需求；故障处理需求；算法需求；相关人员需求；相关培训需求；相关后勤需求；包装需求；其他需求；需求的优先次序和关键程度 合格性规定 需求可追踪性 尚未解决的问题 注解 附录

7.4小节

根据《GB/T 8567-2006 计算机软件文档编制规范》（Specification for computer

  

 

     

    



 software documentation），系统分析文档主要包括系统/子系统需求规格说明（SSS）、接口需求规格说明（IRS）和软件需求规格说明（SRS）。系统/子系统需求规格说明（SSS）为一个系统或子系统指定需求以及保证每个需求得到确认所使用的方法。

接口需求规格说明（IRS）描述为实现一个或多个系统、子系统、硬件配置项（HWCI）、计算机软件配置项（CSCI）、用户

软件需求规格说明（SRS）描述对计算机软件的需求以及确保每个需求得到确认所使用的方法。

第8章

系统设计基础 8.1系统设计概述

 8.1.1 系统级设计决策

系统级设计决策，是指系统行为的设计决策（忽略其内部实现，从用户角度出发，描述系统将怎样运转以满足需求）和其他对系统部件的选择和设计产生影响的的决策。系统级设计决策内容：有关系统接收的输入和产生的输出的设计决策；对每个输入或条件进行响应的系统行为的设计决策；系统数据库/数据文件如何呈现给用户的设计决策；为满足安全性、保密性和私密性需求所选用的方法；硬件或硬软件系统的设计和构造选择；为了响应需求而作出的其他系统级设计决策。

 8.1.2 系统架构设计

总体设计

系统部件设计 动态交互设计 接口设计

 8.1.3 运行设计

系统初始化——说明本系统的初始化过程。

运行控制——说明对系统施加不同的外界运行控制时所引起的各种不同的运行组件组合、每种运行所经历的内部组件和支持软件、每一种外界运行控制的方式方法和操作步骤、每种运行组件组合将占用各种资源的情况以及系统运行时的安全控制。运行结束——说明本系统运行的结束过程。

 8.1.4 系统出错处理设计

出错信息——包括出错信息表、故障处理技术等。补救措施——说明故障出现后可能采取的补救措施。

 8.1.5 系统维护设计

检测点的设计——说明在系统中专门安排用于系统检查与维护的检测点。

检测专用组件的设计——说明在系统中专门安排用于系统检查与维护的专用组件。

8.2软件设计概述

 8.2.1 软件级设计决策

软件级设计决策是指软件行为的设计决策（忽略其内部实现，从用户角度出发，描述软件将怎样运转以满足需求）和其他影响组成该软件的软件配置项的选择与设计的决策。

软件级设计决策内容：有关软件接收的输入和产生的输出的设计决策；对每个输入或条件进行响应的软件行为的设计决策；有关数据库/数据文件如何呈现给用户的设计决策；为满足安全性、保密性和私密性需求所选用的方法；为响应需求而作出的其他软件级设计决策。

 8.2.2 软件架构设计

           程序结构设计

全局数据结构设计 软件配置项设计 动态交互设计 接口设计

 8.2.3 软件详细设计

软件配置项设计决策

软件配置项设计中的约束、限制或非常规特征 软件配置项使用的编程语言考虑 软件配置项使用的过程式命令选取

软件配置项的局部数据与软件配置项的输入或输出数据设计 软件配置项的逻辑设计

8.3设计原则  8.3.1 组件化

组件的可分解性 组件的可组装性 组件的可理解性 组件的连续性 组件的保护性

 8.3.2 抽象

抽象就是抽出事物的本质特性而暂时忽略其细节，使得不同的事物可以当作相同的事务来处理。

软件工程过程的每一步都是对软件解法的抽象层次的一次精化。

软件设计中的抽象机制主要包括类、模板、过程抽象、数据抽象和控制抽象。

 8.3.3 内聚与耦合

内聚是指一个组件内各个元素彼此结合的紧密程度 内聚种类（由低到高排列）：偶然内聚；逻辑内聚；瞬时内聚；过程内聚；通信内聚；顺序内聚；功能内聚

耦合是指一个软件结构内不同组件之间的互连程度 耦合种类（由高到低排列）：内容耦合；公共耦合；外部耦合；控制耦合；标记耦合；数据耦合；非直接耦合

组件的高内聚、低耦合原则称为组件独立原则

 8.3.4 封装与信息隐蔽

第一，组件是其全部属性和全部服务紧密结合而形成的一个不可分割的整体。

第二，组件是一个不透明的黑盒子，表示组件状态的数据和实现操作的代码都被封装在黑盒子里面。使用一个组件的时候，只需知道它向外界提供的接口形式，无须知道它的数据结构细节和实现操作的算法。

 8.3.5 启发式规则

深度、宽度、扇出与扇入 作用域和控制域 功能的可预测性

8.4设计视图

 8.4.1 架构视图（静态视图）

架构描述语言（ADL）              

  



                  

  类图与对象图 组件图

协作责任卡（CRC）部署图

实体-联系图（E-R图）接口描述语言（IDL）结构图

Jackson结构图

 8.4.2 行为视图（动态视图）

活动图 协作图 顺序图 数据流图

决策表和决策图

流程图和结构化流程图 状态图

形式化描述语言 伪码

8.5小节

系统设计是定义一个系统或软件的架构、组件、接口和其它特征的过程。包括系统级设计决策、系统架构设计、运行设计、系统出错处理设计和系统维护设计。

软件设计主要包括软件级设计决策、软件架构设计（概要设计）与详细设计。软件架构设计的主要任务是程序结构设计、全局数据结构设计、软件配置项设计、动态交互设计和接口设计。软件详细设计是指每一个软件配置项的具体设计。

组件化、抽象、高内聚与低耦和、封装与信息隐蔽是软件设计的基本原则。软件设计视图通常可分为架构视图（静态视图）和行为视图（动态视图）两类。第9章

系统设计方法 9.1结构化设计

 9.1.1 结构化设计方法概述

分析系统的总体需求，并将需求逐步分解为基本、具体的功能。确定每个功能应当记录的数据。

列出系统中应提供的各项基本功能，并分析各项基本功能之间的耦合关系，根据高内聚、低耦和的原则分配到系统中适当的模块中。

 9.1.2 系统结构图

模块 调用 数据 控制 转接符号

 9.1.3 系统结构图分类

变换流与事务流 变换型系统结构图 事务型系统结构图   

       

 混合型系统结构图

9.2面向数据结构的设计

 9.2.1 面向数据结构的设计概述

分析并建立适合系统的数据结构；

根据数据结构在相应的层次建立程序结构；

罗列出程序中用到的各种基本操作，并将这些基本操作分配到程序结构中合适的模块中。

 9.2.2 Jackson图

顺序结构 选择结构 重复结构

改进的Jackson图

 9.2.3 Jackson方法

分析并确定输入和输出数据的逻辑结构，并利用Jackson 找出输入和输出数据结构中存在对应关系的数据单元。从描绘数据结构的Jackson图导出描绘程序结构的Jackson

列出所有操作和条件(包括分支条件和循环结束条件)，并且把它们安排到程序结构图的适当位置。用伪代码表示。

9.3面向对象的设计

 9.3.1 面向对象的设计概述

面向对象设计的基本思想是通过建立和客观实际相对应的对象，并通过这些对象的组合来创建具体的应用。

面向对象设计具有基于抽象、信息隐藏、功能独立和模块性构造系统的能力。

对于面向对象的系统，可以定义一个四个层次的设计金字塔：子系统层；类及对象层；消息层；责任层。

 9.3.2 面向对象设计技术

 Coad/Yourdon方法  Booch方法  OMT方法  

 9.3.3 面向对象设计过程

系统设计过程：将分析模型划分为子系统；子系统分配及与问题的并发性；任务管理；数据管理；资源管理；人机界面；子系统间通信

对象设计过程：对象描述；算法与数据结构设计；接口设计与模块化

9.4设计模式

 9.4.1 设计模式概述

设计模式就是将面向对象软件的设计经验记录下，可供设计者能够复用的设计方案。设计模式极大提高了面向对象软件开发的效率，降低了软件的复杂度。

在软件设计中使用设计模式，将使用开发出来的软件更容易理解、更容易维护、更容易扩展，使用设计模式同时也能够提高开发团队和个人的开发能力。

 9.4.2 设计模式基本组成

模式名称：惟一标识一个设计模式。问题：描述应该在何时使用该模式。  

        

  

  

 

 解决方案：描述设计的组成要素，以及它们之间的相互关系及各自的职责与相互之间协作的方式。

 效果：描述应用设计模式的效果，以及使用设计模式必须考虑的限制和约束因素。

 9.4.3 设计模式分类

 面向对象模式  代码模式

 框架应用模式

 创建型模式、结构型模式与行为型模式  类模式与对象模式

 9.4.4 如何使用设计模式

 针对接口编程，而不是针对实现编程  优先使用对象组合，而不是类继承  找出变化并封装

9.5小节

 系统设计是一系列迭代的过程，主要任务包括数据结构、体系结构、接口及过程细节的设计等，而设计方法是软件设计活动中实现设计模型的方法。 系统设计方法主要包括面向过程的结构化设计方法、面向数据结构的设计，以及面向对象的设计方法与设计模式。

第10章

数据库设计 10.1数据建模

 10.1.1 数据模型分类

 概念数据模型  结构数据模型  物理数据模型

 10.1.2 实体-联系（E-R）模型

 实体  属性  联系  实体型  实体集  键  域

 10.1.3 数据模型

 层次数据模型（hierarchical model） 网状数据模型（network model） 关系数据模型（relational model）

 面向对象模型（object oriented model）

10.2数据规范化

 10.2.1 数据规范化的基本概念

 函数依赖

 非平凡函数依赖  完全函数依赖  部分函数依赖

 传递函数依赖  键

 10.2.2 范式

    第一范式（1NF）第二范式（2NF）第三范式（3NF）BC范式（BCNF）

10.3数据库设计过程  10.3.1 数据库需求分析

                     数据边界的确定 数据环境的确定 数据内部关系 数据字典

数据性能需求

数据需求分析说明书

 10.3.2 数据库概念设计

概念设计与概念模型 概念设计的主要方法 分解与抽象 局部概念模式 全局概念模式

 10.3.3 数据库逻辑设计

初始模式的形成 子模式设计

应用程序概要设计 模式评审 修正模式

 10.3.4 数据库物理设计

存储记录结构设计 确定数据存放位置 存取方法设计

完整性和安全考虑 程序设计

10.4小节

 数据库系统普遍采取数据模型表示和处理客观事物的数据特征与信息。数据模型主要由数据结构、数据操作和完整性约束三部分组成，从抽象层次上描述和模拟了系统的静态特征、动态行为和约束条件。

 关系数据库中的关系必须满足一定的要求，即满足不同的范式。目前关系数据库中常用的范式包括：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）和BCNF。 数据库设计主要包括需求分析、概念设计、逻辑设计和物理设计等几个阶段。

第11章

用户界面设计

11.1基本概念

  

         

     

           

 11.1.1 界面设计目标

可用性目标：可行性、有效性、易学性、易记性、安全性、通用性

用户体验目标：令人满意、令人愉快、引人入胜、富有启发、激发创造„„

可用性目标主要从客观角度来评价系统界面，而用户体验目标则是从用户主观感受的角度来评价系统界面。

 11.1.2 界面设计原则

可视性：将系统功能呈现得一目了然。

反馈性：返回与活动相关的信息，以便用户能够继续这个活动。限制性：将用户的行为限制在一定的范围内。

对应性：明确系统某个控制与其控制效果之间的对应关系。一致性：用相似的元素表现相似的操作或相似的任务。启示性：界面元素应给予用户某种提示。

 11.1.3 界面设计过程

标识出用户的真实需要并建立需求模型 设计出候选方案

构建或实现设计的原型版本 对界面设计进行评估

11.2界面设计技术

 11.2.1 界面设计分析技术

GOMS模型及GOMS击键层模型 Hick律 Fitts律

 11.2.2 界面设计方法

原型设计方法

以用户为中心的设计方法 用户界面设计的支持工具

11.3界面设计评估

 11.3.1 构造性评估与总结性评估

构造性评估：在设计过程中对所设计的系统或产品界面进行评估以确保其满足用户需求。

总结性评估：对已经完成的产品或系统界面进行评估。

 11.3.2 评估范型

快速评估 可用性测试 实地研究 预测性评估

 11.3.3 评估方法与技术

观察用户

征求用户意见 征求专家意见 用户测试

用户执行情况的分析模型

 11.3.4 评估框架

明确（Determine）

        

发掘（Explore）选择（Choose）标识（Identify）决定（Decide）评估（Evalute）

11.5小节

用户界面体现了用户利用系统完成任务的方式以及系统对用户行为的响应方式，一个没有良好的用户界面设计的系统很可能会成为一个没有用户的系统。可用性目标与用户体验目标。

界面设计的量化模型：GOMS模型及其子模型-击键层模型，Hick律和Fitts律。构造性评估与总结性评估。

第12章

系统设计文档

12.1系统/子系统（结构）设计说明

                         引言 引用文件

系统级设计决策

系统体系结构设计：总体设计；系统部件设计；动态交互设计；接口设计 运行设计

系统出错处理设计 系统维护设计 尚未解决的问题 需求的可追踪性 注解 附录

12.2

接口设计说明

引言 引用文件 接口设计

需求的可追踪性 注解 附录

12.3

软件（结构）设计说明

引言 引用文件

软件级设计决策

软件体系结构设计：程序结构设计；全局数据结构设计；软件配置项设计；动态交互设计；接口设计 软件详细设计 需求的可追踪性 注解 附录

12.4数据库设计说明

        

    

引言 引用文件

数据库级设计决策 数据库详细设计

用于数据库操纵或访问的软件配置项的详细设计 需求的可追踪性 注解 附录

12.5

小节

根据《GB/T 8567-2006 计算机软件文档编制规范》，系统设计文档主要包括系统/子系统设计（结构设计）说明（SSDD）、接口设计说明（IDD）、软件（结构）设计说明（SDD）和数据库设计说明（DBDD）。

系统/子系统设计（结构设计）说明（SSDD）描述了系统（或子系统）的系统级（或子系统级）设计决策与体系结构设计。

接口设计说明（IDD）描述了一个或多个系统、子系统、硬件配置项（HWCI）、计算机软件配置项（CSCI）、用户或其他系统部件的接口特性。

软件（结构）设计说明（SDD）描述了计算机软件系统的软件级设计决策、软件体系结构设计（概要设计）与详细设计。

数据库（顶层）设计说明（DBDD）描述了数据库的设计。系统设计文档可以使用自然语言，可以使用形式化语言，也可以根据具体的系统设计方法使用各种图形工具，还可以根据实际情况混合使用多种表现形式。

第三篇：软件测试期末复习知识点总结

1.软件测试：是由“验证（verrificatione）”和“有效性确认（validation）”活动构成的整体： “验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。验证过程提供证据表明软件相关产品与所有生命周期活动的要求（如正确性、完整性、一致性、准确性等）相一致。相当于以软件产品设计规格说明书为标准进行软件测试的活动。

“有效性确认”是确认所开发的软件是否满足用户真正需求的活动。一切从客户出发，理解客户的需求，对软件需求定义、设计的怀疑，发现需求定义和产品设计中的问题。这主要通过各种软件评审活动来实现，包括让客户参加评审、测试活动。

软件测试过程：（1）测试组织和管理（2）测试计划（3）测试用例实际（4）测试实施（5）测试结果分析（6）测试评审与报告 软件测试方法：白盒测试方法、黑盒测试方法、静态测试与动态测试、主动测试与被动测试、形式化测试方法、基于风险的测试、模糊测试方法、ALAC测试和随机测试方法

2.单元测试：是对软件基本组成单元进行的测试，而且软件单元是在与程序的其他部分相隔离的情况下进行独立的测试。

静态测试就是静态分析，对模块的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和仿真运行。

动态测试是通过真正运行程序发现错误，通过观察代码运行过程，来获取系统行为、变量实时结果、内存、堆栈、线程以及测试覆盖度等各方面的信息，来判断系统是否存在问题，或者通过有效的测试用例，对于的输入输出关系来分析被测程序的运行情况，来发现缺陷。静态测试、动态测试的区别：1.静态测试用于预防，动态测试用于矫正；2.多次的静态测试比动态测试的效率高；3，静态测试综合测试程序代码；4.在相当短的时间里，测试的覆盖率能达到100%，而动态测试经常只能达到50%测试左右；5.动态测试比静态测试更花时间； 6.静态测试比动态测试更能发现bug；7.静态测试的执行可以在程序编码编译前，动态是中能在编译后才能执行。

3.功能测试：一般须在完成集成测试后进行，而且是针对应用系统进行测试是根据产品规格说明书，来检验被测试的系统是否满足各方面功能的使用要求。

集成测试：也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试，其主要目的是检查软件单位之间的接口是否正确。集成测试包括非增量测试和增量测试两种方式，集成测试的策略主要有自顶向下和自底向上两种。

功能测试、集成测试区别：

4.回归测试：目的是在程序有修改的情况下，保证原有功能正常的一种测试策略和方法。程序在发现严重软件缺陷要进行修改或版本升级要新增功能，这时需要对软件进行修改，修改后的程序要进行测试，这时要检验软件所进行的修改是否正确，保证改动不会带来新的严重错误。

5.桩程序（Stub），也称桩模块：用以模拟被测模块工作过程中所调用的下层模块。桩模块由被测模块调用，它们一般只进行很少的数据处理,例如打印入口和返回，以便于检验被测模块与其下级模块的接口。驱动程序（Driver），也称驱动模块：用以模拟被测模块的上级模块，能够调用被测模块。在测试过程中，驱动模块接受测试数据，调用被测模块并把相关的数据传送给被测模块。

软件缺陷：软件缺陷是指计算机系统或者程序中存在的任何一种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷、瑕疵，其结果会导致软件产品在某种程度上不能满足用户的需求。标准定义，从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。

软件测试步骤： 即单元测试、集成测试、确认测试和系统测试。

1.开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。2.集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。3.确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。4.系统测试把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。

软件测试流程：需求分析和定义、系统设计、详细功能设计、编码、单元测试、功能测试、系统测试、验收测试

软件测试涉及的关键问题：1.测试过程和开发过程是同时开始，同时结束的，两者保持同步的关系；2.测试过程是对开发过程中阶段性成果和最终产品进行验证的过程，所以两者相互依赖；3.测试过程中的工作重点和开发工作的重点可能不一样，两者有各自的特点

黑盒测试的特点：1.不基于对系统内部的设计和实现。2.用例设计基于功能的定义和需求说明书。3.关注于测试数据的选择和测试结果的分析。

测试方法有：等价类划分、边界值分析法、判定表方法、因果图法、正交实验法、功能图法、错误推测法

黑盒测试缺点：1.对用例设计人员的经验要求较高，包括数据的选择，对潜在错误的敏感性；2.对于内部实现的bug不容易发现；3.不能提供直观的测试覆盖率。

白盒测试的特点：1.需要了解系统的整体设计和实现；2.对源代码进行审查；3.在单元测试阶段发现大量的缺陷；4.关注于系统的控制流和数据流；

测试方法有：语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖、路径覆盖、基本路径测试法

白盒测试缺点：1.不能确保系统是否完全符合需求说明书；2.白盒测试的代价会大于黑盒测试；3.需要源代码首先完成才能进行测试；

集成测试中自顶向下和自底向上方法

自顶向下法：从主控模块（主程序）开始，沿着软件的控制层次向下移动，从而逐渐把各个模块结合起来。具体步骤是：1.对主控模块进行测试，测试时用桩程序代替所有直接附属于主控模块的模块；2.根据选定的结合策略，每次用一个实际模块代替一个桩程序；3.在结合下一个模块的同时进行测试；4.为了保证加入模块没有引进新的错误，可能需要进行回归测试。优点：不需要测试驱动程序，能够在测试阶段的早期实现并验证系统的主要功能，而且能在早期发现上层模块的接口错误。缺点：需要桩程序，可能遇到与此相联系的测试困难，低层关键模块中的错误发现较晚，而且用这种方法在早期不能充分展开人力

自底向上法：从“原子”模块（即在软件结构最底层的模块）开始集成以进行测试，具体策略是：1.把底层模块组合成实现某个特定的软件子功能的族；2.写一个驱动程序，协调测试数据的输入输出；3.对由模块组成的子功能族进行测试；4.去掉驱动程序，沿软件结构自下向上移动，把子功能族组合起来形成更大的子功能族。优缺点：刚好和自顶向上相反

简述增量式集成测试的自顶向下和自底向上两种测试方法：自顶向下增量式测试的主要优点在于它可以自然地做到逐步求精，一开始便能让测试者看到系统的框架。它的主要缺点是

需要提供被调用模拟子模块，被调用模拟子模块可能不能反映真实情况，因此测试有可能不充分。自底向上测试的优点在于，由于驱动模块模拟了所有调用参数，即使数据流并未构成有向的非环状图，生成测试数据也没有困难。它的缺点在于，直到最后一个模块被加入进去之后才能看到整个程序（系统）的框架

集成测试自底向上和自顶向下集成方法优缺点是什么？

自底向上集成方法尽早的对底层实用历程进行测试，可以避免编写众多的桩模块，使得系统底层的众多问题及早得到解决。缺点是在一些顶层构件非常重要的情况下，却将其放到了最后集成。

自顶向下集成方法则尽早进行了顶层控制模块的测试和集成，使得系统整体上得到验证，但却将底层实用历程的测试放到了最后。某些具有关键性能或作用的底层模块的问题将在最后才可能被发现。

简述系统测试过程的主要步骤及每个步骤的测试依据。

功能测试：测试依据是系统功能需求；

性能测试：测试依据是其他软件需求；

验收测试：测试依据是客户需求规格说明书；

安装测试：测试依据是用户环境

第四篇：系统分析与设计复习总结

第一章

系统分析员：使用信息技术的商业专业人员，利用分析与设计技术解决商业问题。需要具备的基本知识与技能：1.技术知识与技能

2.商业知识与技能

3.人的知识与技能

4.诚实与道德

系统分析员在系统开发中的职责范围：程序分析员、商业系统分析员、系统联络员、最终用户分析员、商业顾问、系统顾问、系统支持分析员、系统设计师、软件工程师、系统结构设计师。

第二章

系统开发生命周期的阶段划分：项目计划阶段、分析阶段、设计阶段、实施阶段、支持阶段。项目计划阶段、分析阶段、设计阶段的主要活动

1.项目计划阶段：定义问题、确认项目的可行性、制定项目的进度表、为项目安排人员、启动项目

2.分析阶段：收集信息、确定系统需求、建立需求发现的原型、划分需求的优先级、产生并评估可替换方案、与管理人员一起审查建议

3.设计阶段：设计并集成网络、设计应用程序结构、设计用户界面、设计系统界面、设计并集成数据库、设计细节的原型化、设计并集成系统控制 项目开发队伍的人员组成（图2-4 系统开发项目的参加人员）

在项目计划阶段，项目组仅由少数人员组成，基本上包括一个项目经理和一两个有经验的系统分析员。

分析阶段要求项目组成员有良好的分析技能和扎实的问题域知识。设计是较专业化的活动，需要补充有专业技术的人员。在实施阶段，通常增加许多编程人员和质量控制人员，项目组在实施阶段通常是最大的。项目可行性分析的要素：

1.经济可行性

2.组织上和文化上的可行性 3.技术可行性 4.进度表可行性 5.资源可行性

PERT/CPM：基于单个任务或活动对项目进行规划的一种方法。

图 2-15 客户支持项目的部分PERT图

甘特（Gantt）图：以条形图代表项目进度表的任务和活动。

图2-16 客户支持项目的甘特图

第三章：方法、技术、模型、工具以及它们之间的相互关系

系统开发方法：提供完成系统开发生命周期每一步的详细指导，包括具体的模型、工具和技术。

技术：帮助分析员完成系统开发活动或任务的一组方法。模型：现实世界某些重要方面的表示。

工具：帮助生成项目中所需模型或其他组建的软件支持。相互关系：图3-4 方法中个组件之间的关系 结构化方法与面向对象方法的比较

图3-5 结构化编程的三种结构：顺序结构、选择结构、循环结构。

第四章

需求调查的对象：

用户，即每天实际使用系统的人； 客户，即支付和拥有系统的人；

技术人员，即确保系统在组织的计算机环境下运行的人。需求调查的方法：

向系统相关者分发和收集调查表 复查现有的报表、表格和过程描述 主持与用户的面谈和讨论 观察商业过程和工作流 建立原型

主持联合应用程序社街（JAD）会议 需求调查的结果

系统需求：系统所提供功能的详细定义。

功能需求：描述系统必须支持的功能和过程的系统需求。技术需求：描述操作系统环境和性能目标的系统需求。通常把系统需求分为两类：功能需求和技术需求。功能需求用于说明新系统必须支持的基本商业功能，而技术需求则包括系统性能目标、操作环境以及其他非功能性问题。

第五 – 七章：系统分析

模型的分类：包括数学模型、描述模型和原图模型。

数学模型：描述系统技术方面的一系列公式，用来表示系统精确的方面，这些部分最适合用公式或数学符号表示。

描述模型：描述系统某一方面的描述性的备忘录，报表或列表。图形模型：图表和系统某些方面的示意性表示。图形模型有助于理解那些很难用语言来描述的复杂关系。

事件的分类：外部事件，临时事件和状态事件。

外部事件：系统之外发生的事件，通常都是由外部实体或动作参与者触发的。临时事件：由于到达某一时刻所发生的事件。

状态事件：当系统内部发生了需要处理的情况时所引发的事件。事件表：以各个事件为行，各个事件的关键信息为列。图5-15 事物之间的关联关系：只能一个（强制）、0或多个（可选）、1或多个（强制）0或1个（可选）

图 5-21 图5-22 关系的基数符号

实体-联系图：传统的系统开发方法都把重点集中在新系统的数据存储需求上。数据存储需求包括数据实体、数据实体的属性以及它们之间的关系。用来定义数据存储需求的模型被称为实体-联系图（ERD）。

图 5-21 一个简单的实体-联系图

图 5-22 关系的基数符号

图 5-23 显示了属性的扩展ERD图

图 5-25 大学课程注册ERD图（含有多对多关系）图 5-26 细化的大学课程注册ERD图（包含关联实体）

图 5-27 RMO客户支持系统的实体-联系图（ERD）（图中未显示有关属性）图 5-31 类图符号 图 5-32 银行账目类图

图 5-33 落基山运动用品商店类图 数据流程图：是一种图形化的系统模型，它在一张图中展示信息系统的主要需求，即：输入、输出、过程和数据存储。

外部实体：在系统边界之外的个人或组织，它提供数据输入或接受数据输出。过程：在DFD中的一个符号，它代表从数据输入转换到数据输出的算法或程序。数据流：在DFD中的箭头，它表示在过程、数据存储和外部实体之间的数据移动。数据存储：保存数据的地方，以便将来由一个或多个过程来访问这些数据。图6-2 数据流程图的符号

关联图：是指描述系统最高层结构的DFD。

图 6-5 大学课程注册系统的关联图

DFD片段：用一个过程符号表示系统响应一个时间的DFD。

图 6-7 课程注册系统的DFD片段

决策表：一种处理逻辑的表格表示方法，其中包括决策变量、决策变量值、参与者或公式。

图 6-22 计算运输费用决策表

决策树：使用像树枝一样的线条对过程逻辑进行图形化的描述。

图 6-23 计算运输费用决策树

数据流定义：数据流内容和内部结构的文本描述。

数据流是数据元素的集合，所以数据流定义将列出所有的数据元素。

第七章 面向对象的需求描述

类图、用例图、顺序图、协作图、状态图

当我们讨论系统开发的时候，通常把系对新系统的描述分成两部分：结构化信息和行为化信息。系统的组成部分我们称之为结构，而这些组成部分的执行逻辑我们称之为行为。

类图提供了对系统组成部分的定义，而其它图，即用例图、顺序图、协作图和状态图，这些图的重点都集中在系统所完成的活动上。换句话说，它们描述的是新系统的行为方面。

因此，类图说明系统的组成部分是什么，而其他图说明这些组成部分干什么。类图：

用例图：一种用以显示不同的用户角色和这些用户角色如何来使用系统的图。

用例图的目的是识别新系统的“使用”，或用例，换句话说，就是识别如何使用系统。用例图本质上是事件表的延伸。用例图是一个记录系统必须支持功能的简便方法。顺序图：一种用以显示用例对象之间消息顺序的图。

顺序图更详细地显示了协作图中所表达的信息，只是显示方式有些差异。顺序图以图形化的方式强调消息间的顺序，而非协作对象。画顺序图的目的是用过在页面上标出位置来图形化地表示消息的顺序。执行次序从上到下执行。

协作图：一种用以显示对象如何被协调在一起以执行用例的图。

消息：用例内部的对象之间的通信。

协作图的目的是识别协作完成给定业务功能的对象。比如说，一个RMO的系统的商业用途之一是“记录客户订单”，那么协作表将会识别所有涉及到的对象。为了记录客户订单需要一个客户对象，一些库存对象和一个新订单对象等。一个独立的协作图用以识别对象，并展示这些对象的相互作用及对象之间发送的用于执行功能的消息。

交互图：显示对象之间交互的图，它或者是一个协作图，或者是一个顺序图。

协作图和顺序图统称交互图。

状态图：一种用以现实对象在各个阶段中的生命和转换的情况的图。

最后一种被用来描述应用需求的图称状态图。一个状态图表（或简单地称之为状态图）描述了每个对象的状态和行为。每一个对象类都含有一个状态图表。在状态图的内部是动作描述，这些动作描述在最终的系统中都变成了逻辑。每个类中的逻辑组件称为方法。

OO需求=事件表+类图+用例图+顺序图+协作图+状态图表。7.4 系统行为：面向对象的用例/场景视图

用例：由系统为使用给系统的用户完成的一个单一用途或功能。参与者：系统用户扮演的一个角色。

图 7-2 有一个参与者的简单用例

场景：在用例中活动的一个特定顺序；一个用例有可能有多个不同的场景。

图 7-4 带系统边界的用例图

图 7-5 客户支持系统用例图举例（通过子系统）图 7-6 与客户相关的所有用例 图 7-7 《包含》用例的一个例子 7.5 对象交互：顺序图与协作图

协作图和顺序图包含有相同的信息，但它们的侧重点稍有不同。协作图强调对象交织在一起以支持一个用例，而顺序图把重点放在消息本身的细节上。

顺序图展示对象之间的交互顺序，这些交互是指在场景或用例的事件流中发生的。在顺序图中共有四个基本符号：

1.参与者符号，由一个小人图形表示；

2.对象符号，由一个名字带下划线的方框表示；

3.生命线符号，由虚线或狭窄的竖直方框表示；

4.消息符号，由带消息描述的方向箭头表示。

图7-9 顺序图的符号 图7-10 对象和类名

生命线：在顺序图中的一个对象下面的竖线，用以显示这个对象的时间阶段。激活生命线：在顺序图中的垂直窄长方框，用以强调一个对象只有在一个场景的部分中处于活动状态。消息：由于面向对象系统通过每个对象向其他对象发送消息来工作，因此在一个场景内由事件流定义的内部事件就变成了在对象和参与者或其他对象之间的消息。

消息符号由两部分组成：方向箭头和消息描述器。消息描述器的语法如下：

[true/false条件] 返回值：= 消息名（参数列表）

True/false条件用于验证这个消息是否可以发送。它象一个决定点或程序余亚种的if语句。如果这个条件计算后返回true，则发送这个消息，否则不发送。

消息是从一个参与者或对象向另一个参与者或对象的需求。开发顺序图的一个有效方法及其步骤如下：

1.识别出所有与场景有关的对象和参与者。只使用在用例图中表示过的参与者，只适用在类图中标识过的对象。

2.基于活动流，识别出每一个需要用于完成场景的消息。同时标识消息的源对象或参与者和目的对象或参与者。

3.下一步决定每一个消息是总发送还是有条件的发送。

4.正确地为这些消息排序并给它们加上合适的参与者或对象生命线。5.给消息加上形式化的语法以描述条件、消息名和要传递的参数。6.如果你愿意，加上响应消息和通信以使顺序图完整。图 7-12 “查询可用项目”的顺序图

图 7-13 “创建新订单”用例的电话订购场景顺序图 协作图：

协作图主要应用是快速浏览相互协作、用来支持一个特定场景的所有对象。协作图的参与者、对象和消息都使用了顺序图中的符号。生命线的符号没有使用，但是，也使用了一个不同的符号：链接符号。

图7-14在一个典型的协作图中显示了这四种符号。

协作图信息描述符的语法如下：用数字顺序标号来显示每一个消息的顺序。[true/false条件] 顺序编号：返回值：= 消息名（参数列表）在对象之间或在参与者与对象之间的连线表示链接。

在一个协作图中，链接表示两个对象共享一个消息——一个发送消息一个接收消息。图7-15 “查询可用项目”的协作图

图7-16 “创建新订单”电话订购场景的协作图 7.6 对象行为：状态、状态转换和状态图表

在开发功能需求时，最后一类需要的信息是每个对象的内部逻辑。这些信息是对对象本身执行动作的描述。

顺序图给出了对象行为的一个客观的分析。它标识了对象发送和接收的消息。状态图的目标是描述对象的内部工作。图7-17 OO模型中的关系。

状态图是从类图和顺序图中的信息开发出来的。状态：一个对象存在的条件；状态图的一部分。

一个黑圆圈表示初始状态，它仅仅表明进入状态图的入口点。初始状态也叫做伪状态，因为入口点也许会比对象自身的创建更早。

在内部涂黑的同心圆表示结束状态，这个状态表示从状态图中退出，通常表示从系统删除一个对象。

动作：在一个特定状态下对象执行的行为。

并行或并发状态：在状态图中同时处于多于一个状态的条件。

复合状态：嵌套了其他状态的高层状态。一个对象进入复合状态后，它就从一个黑点开始一条路径。

对象转换：状态图中的一个组成部分，它标示从一个状态到另一个状态的移动。目的状态：一个转换的目的，它连接着转换符号的箭头。原状态：一个转换的起源，它连接转换符号的尾部。

消息时间：转换的触发器，这个转换由一个有事件属性的消息组成。

图7-23 状态图的转换名称和消息名称。图7-25 订单的状态图。

完成转换：原状态结束行动时发生的没有触发事件的转换。

决策伪状态：在状态图中的一个菱形块，它代表在路径上的一个决策点。

第八章 C/S结构，三层/多层结构

客户机-服务器结构： 客户机-服务器结构是当前分布式信息系统资源的主要结构模式。客户机-服务器结构将信息系统过程分成两个等级：客户机和服务器。服务器计算机管理一个或多个的系统资源并通过确定的通信结构提供对那些资源的访问；客户机计算机用这个通讯结构来请求资源，而服务器则响应那些请求。实现通信结构的软件通常称为中间件。

服务器计算机或服务器：在网络中为其他计算机提供服务的计算机。客户机计算机：向网络中的其他计算机请求服务的计算机。

中间件：在网络中实现通信协议和帮助不同的系统进行通行的计算机软件。三层结构：包含用户层、业务逻辑层、数据层三层的一种客户机-服务器结构。

图8-4 三层结构。

第九章、系统设计

结构化方法

– 系统流程图，结构图，结果质量评价

面向对象方法

– 包图，类图

图9-3 结构化和面向对象模型

系统流程图：描述一个系统内计算机程序之间所有控制流的图。

系统流程图标识了每一个程序及其所存取的数据。系统流程图也表明了不同程序、子系统、相关文件和数据库之间的关系。记录了整个系统的体系结构。

图9-5 带自动化系统边界的数据流程图 图 9-6 系统流程图的常用符号 图9-7 工资系统的系统流程图样例 图 9-8 RMO的系统流程图

结构图：用来展示一个计算机程序模块间关系的层次图。

结构图的层次描述了系统各部分的功能和子功能。

结构图的基本组成部分是模块，模块用来标识一个功能。图 9-9 一个计算工资总额的简单结构图 图9-11 完整计算工资系统的结构图 评价结构图的质量：

模块耦合和模块内聚是检测质量的两个标准。一般来说，我们期望设计出高度内聚和松散耦合的模块来。

模块耦合：模块间相互联系的方式，较好的方式是数据耦合。模块内聚：模块内部的凝聚程度。9.2.4 模块算法设计：伪码

包图：是一个高层图，用以标识系统中的主要部件。

包图的目标是用于标识一个完整系统的主要部分。在一个大的系统中，通常要把系统分成许多子系统，每个子系统的功能相互之间都是独立的，虽然子系统间经常会交换信息并频繁的共享同一数据库。

图 9-26 包括RMO设计类的图。

设计类图：设计类图是带某些符号的类图，这些符号在类中描述了设计部件。

第十章、数据库设计

 关系数据库的设计

 从ERD到关系模型的转换  从类图到关系模型的转换  面向对象数据库的设计

 从类图到面向对象数据模型的转换

关系数据库管理系统：在表中存储数据的数据库管理系统。

表：包括行和列的二维数据结构，也叫关系。

行：表的一部分，包含描述一个实体、关系或对象的数据，也叫元组或记录。字段：关系数据库表的一列，也叫属性。

字段值：存储在关系数据库表的一个单元中的数值，也叫属性值或数据元素。关键字：关系数据库表中每一行都含有一个唯一值的字段。主键：可以唯一标识关系数据库中表的某一行的关键字。（字段不唯一）外部码：存储在一个关系数据库表中的字段值，同时这个字段值也是另一个关系数据库表的主键值。

关系数据库设计可以从一个ERD或一个类图开始。这一节介绍如何根据一个ERD来生成数据库模式。基于类图的模式建立将在本章的后面讨论。从ERD建立一个关系数据库模式，可以采取一下步骤：

1.为每个实体类型建立一张表

2.为每个表选择一个主键（如何需要，可以定义一个）3.增加外部码以表示一对多关系 4.建立一个新表来表示多对多关系 5.定义参照完整性约束

6.评价模式质量，并进行必要的改进

7.为每个字段选择适当的数据类型和取值范围（如果需要）图10-5 RMO的实体-联系图

图 10-6 表示ERD中实体的初始表的集合 图 10-7 带主键（用黑体标识）的实体表 图 10-8 图 10-9 参照完整性：一个一致的关系数据库状态，其中每个外部码的值也作为一个主键的值存在。

第11章

Eight Golden Rules for Interactive Interface Design From Strive for Consistency（尽量保持一致性）

Enable Frequent Users to Use Shortcuts（提供快捷键）Offer Informative Feedback（有效反馈）

Design Dialogs to Yield Closure（设计完整的对话过程）Offer Simple Error Handling（简单的错误处理机制）Permit Easy Reversal of Actions（允许撤销动作）Support Internal Locus of Control（控制的内部监控）Reduce Short-Term Memory Load（减轻短期记忆负担）

概要

1.系统开发生命周期的阶段划分：项目计划阶段、分析阶段、设计阶段、实施阶段、支持阶段。

2.对获取的需求信息进行类别划分，主要的需求类别有:系统需求，功能需求,技术需求 4.用于定义系统需求的两个关键概念分别是事件和事物 5.事件的分类：外部事件，临时事件和状态事件。

6.生命线：在顺序图中的一个对象下面的竖线，用以显示这个对象的时间阶段。

激活生命线：在顺序图中的垂直窄长方框，用以强调一个对象只有在狭长垂直矩形框的描述期间处于活动状态。

7.顺序图消息符号由两部分组成：方向箭头和消息描述器。消息描述器的语法如下：

[true/false条件] 返回值：= 消息名（参数列表）

True/false条件用于验证这个消息是否可以发送

8.协作图消息用数字顺序标号来显示每一个消息的顺序。

[true/false条件] 顺序编号：返回值：= 消息名（参数列表）

在对象之间或在参与者与对象之间的连线表示链接。

在一个协作图中，链接表示两个对象共享一个消息——一个发送消息一个接收消息。9.模块耦合和模块内聚是检测质量的两个标准。一般来说，我们期望设计出高度内聚和松散耦合的模块来。

10.在关系数据库的设计过程中，提高关系数据库模式质量的有效方法是进行关系数据库的规范化设计。

11.计划阶段的模型：甘特图

分析阶段的模型：活动图，关联图，实体联系图，用例图，数据流图，协作图

设计阶段的模型：包图，系统流程图

12.传统的结构化方法：数据流图，结构图，系统流程图，面向对象方法：类图、用例图、顺序图、协作图、状态图，13.关系数据库中，元组与元组之间的关联关系是通过外键来表示的

面向对象数据库中，对象与对象之间的关联关系则是通过对象标识来表示的 四种报表类型：详细报表、汇总报表、异常报表、决策报表

Drill down(下钻)：将汇总字段设计成一个链接，允许点击它以查看更为详细的资料 完整性控制：应用系统内部用来保护系统内信息的机制和程序。

三种完整性控制：输入完整性控制、数据库完整性控制、输出完整性控制。（防诈骗）输入完整性控制：字段组合控制、限值控制、完全性控制、数据有效性控制。三种用户：未授权、注册用户、特权 用户界面的特征：物理特征、感知、概念 以用户为中心的原则： 及早关注用户及其工作

多次评价系统设计以保证其可用性 使用迭代开发方法

HIC的三种隐喻：直接操作隐喻（直接与显示屏上的对象交互——桌面隐喻）、文档隐喻、对话隐喻

界面设计指导原则： 可视性：有反馈 可供性：体现功能 事件列表

|事件| 触发器 | 源

活动

|

响应

|目的地| 事物列表

|确定的名词| 将该名词作为事物存储的一些注释|

第五篇：系统分析与设计复习要点

1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.可行性研究报告一般涉及哪些内容？ 用例图的要素有哪些？ 顺序图的特点？ 简单介绍总体设计、详细设计涉及的主要工作。方案建议书一般涉及哪些内容？ 黑盒测试和白盒测试各自的特点是什么？ 什么是HIPO图，它的作用什么？ 简单介绍总体设计、详细设计涉及的主要工作 在结构化系统分析中数据字典的作用是什么？ 软件生命周期的瀑布模型包含哪些阶段？ 系统开发生命周期中“系统分析与设计”的重要性。什么是UML？三种表示形式是什么？ 类图中定义了四种关系？ 在结构化分析方法中，使用的主要工具有哪些？ 封装是面向对象方法的一个重要原则，封装有两个含义是什么？ 电子商务应用软件三层是哪些层？ 项目管理过程中安排项目进度常用的工具有哪些图？ 系统规划阶段的成果主要有哪些？ 系统开发生命周期将系统开发过程分为5个阶段，分别是是什么？ 交互图可分为哪两种，其特点是什么？ 画出客户使用ATM的用例图。

每个银行用户都拥有自己的账户，而账户又分为人民币账户和美元账户，请画出以上提到的“账户”、“人民币账户”和“美元账户”的类图，并标出三者之间的关系。其中，“账户”的属性包括：1）账号：string；2）余额：double；3）身份证号：string。其中“账号”和“余额”为Private，“身份证号”为Public。

22.首次购买基金的描述，画出相应的活动图。

客户来到银行，柜员首先判断该客户是否有该行的“综存账户”；

如果没有“综存账户”，则由用户提出申请，然后柜员协助办理“综存账户”，“综存账户”开通后需要往账户中存入一定额度的现金，接下来需要该客户填写“风险容忍度测试表”，在客户填写该表的过程中，理财专员帮助客户“申办基金账户”；

如果客户本来就有“综存账户”，则该客户直接填写“风险容忍度测试表”，在客户填写该表的过程中，理财专员帮助客户“申办基金账户”；

主管审核，通过审核则该段流程结束，否则返回给理财专员。

A.对于并行的流程可以采用分叉与汇合表示?B.利用泳道区分不同的对象?

23.根据下列描述画出该用例图

某电子商务网站的用户要“查询订单状态”，在查询之前必须进行“用户合法性检查”，“用户合法性检查”有两种途径，一种是“通过密码验证”，另一种是“通过手机短信验证”； 用户如果想“下订单”也必须先进行“用户合法性检查”；

“下订单”还包括一种特殊情况，即“下加急订单”。

24.大雁是群居动物，每只大雁都属于一个“雁群”，一个“雁群”可以有多只“大雁”，用类图表示“大雁”和“雁群”这两个类的关系。“雁群”这个类的属性包括“大雁数量：int”和“过冬地点：string”，类的方法有“V字形飞行”和“一字形飞行”。“大雁”这个类的属性包括“大雁体重：float”和“大雁性别：bit”，类的方法有“下蛋”和“飞行”。