软件设计期末复习重点文档格式.docx

软件设计期末复习重点文档格式.docx

《软件设计期末复习重点文档格式.docx》由会员分享，可在线阅读，更多相关《软件设计期末复习重点文档格式.docx（20页珍藏版）》请在冰豆网上搜索。

依赖关系：

两个类之间存在依赖关系，表明一个类使用或需要知道另一个类中包含的信息。

关联关系：

两个类之间存在关联关系，表明这两个类的实例之间存在语义上的联系。

+Employee+Employee

*1

聚集关系：

聚集关系表明两个类的实例之间存在一种拥有或属于关系，可以看做是一种比较弱的整体的一部分关系，或是一种逻辑上的隶属关系。

（图上菱形是空的）

2.4UML2.0行为建模

2.4.1顺序图：

（给出用例画出顺序图）

【课本41页】

2.4.7用例图：

（作用，参与者，用例）

【课本50页】

⏹作用：

用例图通常被用来描述系统的需求，从用户的角度对系统的功能视点进行建模。

⏹用例：

一个用例代表系统执行的一组动作，这些动作完成特定的任务，并产生对用户或外部实体可观察的结果。

用例用来描述系统对外可见的需求或功能。

⏹参与者：

参与者是与用例发生交互的系统外部角色，必须是被开发的系统范围之外的角色（不必在本开发系统中实现），它们只与系统发生某种形式的交互。

第三章软件设计基础

3.1软件设计的基本概念

3.1.1抽象与逐步求精（概念）

【课本55页】

⏹抽象：

“抽象”是一个心理学概念，它要求人们将注意力集中在某一层次上考虑问题，而忽略那些低层次的细节。

是管理、控制复杂性的基本策略。

⏹逐步求精：

“逐步求精”可视为一种早期的自顶向下设计策略，其主要思想是，针对某个功能的宏观描述用逐步求精的方法不断地分解，逐步确立过程细节，直至该功能用程序语言描述的算法实现为止。

3.1.2模块化与信息隐藏（概念、好处）

【课本57页】

模块化：

即把软件划分为可独立命名和访问的部件，每个部件称为一个模块，当把所有模块组装到一起时则获得满足问题需要的一个解。

信息隐藏：

即一个模块的开发者不必看到其它模块的内部，只需知道其接口即可，这使得每个模块的开发人员所要处理的复杂性显著降低。

未来达到信息隐藏的目的，模板应该被设计为其所含信息（过程和数据）对于那些不必要的信息模块不可访问。

3.1.3内聚与耦合（不同内聚概念、判断、举例）

【课本58页】

1.内聚

⏹偶然性内聚：

一个模块内各成分为完成一组功能而组合在一起，它们相互之间即使有关系，也很松散（内聚程度最低）

例1：

一个程序员写完一个程序后发现有一组语句多处出现，于是为了节省内存便将这组语句单独组成一个模块。

例2：

工具模块

⏹逻辑性内聚：

模块完成的诸任务逻辑上相关

⏹时序内聚：

一个模块包含的任务必须在同一时间内执行

例：

系统的初始化

⏹过程性内聚：

模块内成分彼此相关，并且必须按特定的次序执行

⏹通信内聚：

模块中各成分都将对数据结构的同一区域进行操作

例如：

从同一磁带上读取不相干的数据——可能破坏独立性。

⏹顺序性内聚：

各成分均与同一功能相关，且处理按序执行

⏹功能性内聚：

所有成分形成一个整体，完成单个功能（内聚程度最高）

2.耦合

⏹非直接耦合：

两个模块中的任一个都不依赖对方能独立工作。

（耦合度最低）

A访问C的内部数据或不通过正常入口而转入C的内部。

部分代码重叠（常出现在汇编程序中）

例3：

一个模块有多个入口（功能）

⏹数据耦合：

两模块间通过参数交换信息，数据仅限于数据。

⏹控制耦合：

模块间传递的信息含有控制信息。

⏹特征耦合：

介于数据耦合和控制耦合之间。

⏹外部耦合：

若干模块均与同一外部环境关联。

⏹公共耦合：

若干模块通过全局的数据环境相互作用。

⏹内容耦合：

一个模块使用另一模块内部的数据或控制信息，或一个模块直接转移到另一模块内部。

（最高耦合度）

1.

2.

3.3软件设计的质量

1.结构良好2.充分性3.可行性4.简单性5.实用性6.灵活性7.健壮性8.可移植性9.可复用性10.标准化

灵活性（如何提高灵活性，可靠性）

【课本67页】

举例：

网站成员注册

classWebsite

{

Member[]members;

//ormaybe:

vectormembers;

voidregister（MemberaMember）{...}}

怎样才能使设计更灵活以注册新类型的成员？

解决方案：

引入一个基类，将基类抽象化，根据需要产生继承类

我们之所以进行灵活的设计，因为变化和重用是经常出现的

2.健壮性

1.防止错误输入

o用户输入

o不是用户的输入

•数据通信

•其他应用方法调用

2.防止开发错误

Ø

错误的设计

错误的实现

⏹检查输入

在继续进行处理之前，可以检查应用程序的所有输入的方法。

检查类型（例如：

整形）;

检查与前置条件和不变式的输入

⏹为提高健壮性而初始化

提供静态方法，用来为类产生标准的默认值

⏹提高健壮性的参数传递技术

保证方法正确调用

引入一个捕获参数的类并将约束条件合并

⏹强化意图

通过防止设计和实现中的错误来提高健壮性

强化计划，按计划使用相应功能

3.4软件体系结构设计【课本68页】

“4+1”模型：

每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容。

1.逻辑视图：

主要支持系统的功能需求，即系统提供给最终用户的服务。

在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。

2.进程视图：

该视图捕获设计中关于并发和同步的内容，重视一些非功能性需求。

3.开发视图：

该视图主要描述软件在开发环境中的静态结构，该视图的构建和连接件分别映射到子系统或模块，关注于在软件开发环境中软件模块的组织。

软件可以被打包为子系统，并按层次进行组织。

4.物理视图：

该视图描述软件到硬件的映射关系，反应了软件的分布特征。

把不同的软件元素，例如进程和任务等，映射到不同的物理节点上，并关注物理环境的拓扑结构以及节点间的通信。

5.场景：

场景通常是最重要的需求，一方面作为设计中发现体系结构元素的驱动器，另一方面在设计完成后，充当确认和验证的证据。

3.5高可信软件设计

在等待外部信号的程序段中，不允许无限制地等待。

正确的做法应是，或采用循环等待次数控制，或使用定时器，使得规定时间内（无论成功或失败）必须保证退出等待外部信号的程序段。

不允许的设计方法建议采用的设计方法

握手标志置写不上的可能

可靠的设计方法

3.5.2容错设计

⏹1.避错：

避错设计是使软件产品在设计过程中，不发生错误或少发生错误的一种设计方法。

避错的设计原则是控制和减少程序的复杂性。

从开发方法、工具等多处着手

⏹避免需求错误

⏹深入研究用户的需求（用户申明的和未申明的）

⏹用户早期介入，如采用原型技术

⏹选择好的开发方法

⏹结构化方法：

包括分析、设计、实现

⏹面向对象的方法：

⏹基于部件的开发方法（COMPONENTBASED）

⏹快速原型法

⏹2.查错：

软件查错设计是指在设计中赋予程序某些特殊的功能，使程序在运行中自动查找存在错误的一种设计方法。

被动式错误检测

在程序的若干部位设置检测点，等待错误征兆的出现

主动式错误检测

对程序状态主动进行检查

⏹检测原则

相互怀疑原则：

在设计任何一个单元、模块时，假设其它单元、模块存在着错误；

立即检测原则：

当错误征兆出现后，要尽快查明，以限制错误的损害并降低排错的难度。

⏹负效应

所设置的“接收判据”不可能与预期的正确结果完全吻合，导致错判或漏判；

软件增加了冗余可能降低可靠性

⏹3.改错：

改错设计是指在设计中，赋予程序自我改正错误、减少错误危害程度的能力的一种设计方法。

⏹改正错误的前提是已经准确地找出软件错误的起因和部位（故障检测与故障定位合称故障诊断），程序又有能力修改、剔除有错误的语句。

⏹现阶段仅限于减少软件错误造成的有害影响，或将有害影响限制在一个较小的范围。

常采用故障隔离技术。

第四章

4.2用例分析与设计

4.2.3用例设计描述【课本105页】

⏹案例：

银行ATM自动柜员机的需求简述（本案例将要开发的ATM系统能够为顾客提供以下基本服务，它们统一称为交易）：

取款服务。

顾客可以用银行卡从对应的账户中支取现金，现金必须是100元的整数倍，且每次取款不能超过2000元。

存款服务。

顾客可以把现金存入与银行卡对应的账户中。

转帐服务。

顾客可以把一个银行卡对应的账户中的款项转帐到另一个银行账户中。

查询服务。

顾客能够查询一个银行卡对应的账户中的余额。

⏹该ATM系统包括以下组成部分：

读卡器

交互的控制台，键盘及显示器

送出现金的装置，取款器

存款的插槽，存款器

打印机

启动和关闭ATM系统的开关键盘

ATM系统与银行服务通过特定的网络连接进行通信

⏹ATM系统在提供以上服务的过程中，必须满足以下要求

一个顾客可以在最终确认前放弃一项交易

ATM在执行交易过程中将与银行系统进行通信，对是否允许交易进行验证

ATM为每次成功的交易提供一个打印回执

ATM需要维护一个内部日志，对每次交易进行记录

参与者：

与系统交互的人、设备、其他系统

⏹“顾客”（Customer）

⏹“操作管理人员”（Operator）

⏹“银行服务器”（BankSystem）

⏹“读卡器”（CardReader）

⏹“存款器”（CashAcceptor）

⏹“取款器”（CashDispenser）

⏹“打印机”（Printer）

用例描述：

⏹用例名称：

Withdrawal

Customer，BankSystem，CardReader，CashDispenser，Printer

⏹前置条件：

顾客已插入银行卡，密码验证正确，顾客按下“取款”按钮

⏹主事件流：

（★）

顾客输入取款金额，并确认。

系统认可取款金额，并发送指令给取款器。

取款器把相应金额的现金送出。

打印机打印回执。

⏹辅事件流：

如果取款金额不是100的整数倍，则显示信息“输入金额必须是100的整数倍，请重新输入”，并返回主事件流中步骤

（1）。

如果取款金额超过2000元，则显示信息“输入金额不能超过2000元，请重新输入”，并返回主事件流中步骤

（1）。

如果账户余额小于取款金额，则显示信息“账户余额不足，请重新输入”，并返回主事件流中步骤

（1）。

顾客在确认取款金额前可以选择取消交易。

⏹后置条件：

如果取款成功，系统从账户余额中减去相应数额，并返回等待状态；

如果顾客取消交易，则返回等待状态。

4.3概念模型和顶层架构设计（★）

4.3.1概念模型设计

从分析类所负责的主要功能需求看，系统可以包含三种分析类：

1.边界类：

负责目标软件系统与参与者之间的交互，构造型为<

<

boundary>

>

。

通常情况下，参与者与用例之间的一种通信连接对应一个边界类。

其职责包括：

2.控制类：

作为完成用例任务的责任承担者，负责协调、控制其它类共同完成用例规定的功能或行为。

构造型为<

control>

用例通常对应控制类。

3.实体类：

负责保存目标软件系统中具有持久意义的信息项并向其它类提供读、写信息项内容的必要操作接口，一般不涉及业务逻辑处理。

entity>

。

4.3.2顶层架构设计（目的）

顶层架构的主要目的是为后续的分析和设计活动建立一种结构和划分，以便开发人员在不同的开发阶段，以及同一开发阶段的不同开发人员，能够聚焦于系统的不同部分。

4.6.2调整软件构成类

对类进行调整和优化主要包括：

1.增加辅助类；

2.合并相互通信频繁的类；

3.分拆规模过大的类；

第五章面向数据流的软件设计方法

5.2实体关系图

数据对象有属性描述，通常，属性包括：

1.命名性属性：

对数据对象的实例命名，其中必含有一个或一组关键属性，以便唯一地标识数据对象的实例。

2.描述性属性：

对数据对象实例的性质进行描述。

3.引用性属性：

将自身与其他数据对象的实例关联起来。

规范化规则：

1.数据对象的任何实例对每个属性必须有且仅有一个属性值；

2.属性是原子数据项，不能包含内部数据结构；

3.如果数据对象的关键属性多于一个，那么其他非关键属性必须表示整个数据对象而不是部.分关键属性的特征；

5.所有的非关键属性必须表示整个对象而不是部分属性的特征。

5.4面向数据流的设计过程（★）

5.4.1变换流与事务流

面向数据流的方法能方便地将数据流图转换为软件结构，其过程分为五部：

1.确定信息流的类型；

2.划分流界；

3.将数据流图映射为程序结构；

4.提取层次控制结构；

5.通过设计复审和使用启发式策略进一步精化所得到的机构。

5.4.2变换分析

步骤1：

复审基本系统模型

步骤2：

复审和精化软件数据流图

步骤3：

确定数据流图的特性，判定它为变换流还是事务流

步骤4：

通过划定输入流和输出流的边界来孤立变换中心，即把DFD划分成逻辑输入、主加工和逻辑输出三个部分。

步骤5：

执行“一级分解”

步骤6：

执行“二级分解”，即设计中下层模块

步骤7：

采用启发式设计策略，精化所得程序结构雏形，以求改良软件质量

5.4.3事务分析

步骤一：

步骤二：

复审并精化软件数据流图

步骤三：

确定数据流图的特性，判定它为变换流还是事务流

步骤四：

指出事务中心，确定由事务中心发出的每一动作路径的数据流特性

步骤五：

把数据流图映射为事务处理型的程序结构

步骤六：

分解并精化事务结构以及每条动作路径所对应的结构

步骤七：

使用启发式设计策略，精化所得程序结构雏形，改良软件质量

例：

针对图所示的DFD，采用事务分析法导出程序结构，因其主体数据流为事务流（c为事务中心）。

显然，区域Ⅰ为变换流；

区域Ⅱ为事务流，但其各个子流为变换流；

区域Ⅲ为变换流。

在你所设计的程序结构中，除了每个变换对应一个模块外，可能还需增加若干控制模块。

组合得程序结构的雏形，精化雏形，如下图：

针对如下的DFD图，导出程序结构图。

其中n为事务中心。

针对如下的DFD图，分步骤导出程序结构图。

其中d为事务中心。

第六章用户界面设计

6.1界面设计的基本原则

原则

描述

用户熟悉程度

界面应该采用经常使用系统的用户所熟悉的术语和概念

一致性

界面必须一致，在任何可能的情况下相同的操作应该以同样的方式被激活

使惊讶最小化

尽量避免使用户对系统的行为感到惊讶

可恢复性

界面应该为用户提供错误恢复机制

用户帮助

界面应该在错误发生时提供有意义的反馈，并且提供上下文敏感的用户帮助系统

用户多样性

界面应该为不同类型的用户提供恰当的交互方式

6.2设计良好界面的主要途径

用户界面设计中有三条“黄金规则”（如何理解）

1.使系统处于用户控制之中

2.减少用户记忆负担

3.保持界面一致性

6.3.2界面分析和设计模型

在用户界面的分析和设计过程中，有四种模型能够起作用：

1.用户模型

2.设计模型3.心智模型或系统感知模型4.实现模型

6.4用户界面分析

用户分析技术：

任务分析用户采访和问卷调查群体文化学

6.5.2界面设计需考虑的问题

1.响应时间

系统响应时间有两个重要特征：

长度和变化性；

变化方式是指与平均响应时间的偏差；

2.用户帮助

消息措辞中的设计因素

第七章软件体系结构风格和设计模式

7.1基本概念

软件设计模式：

可解决一类问题并能重复使用的解决方案

软件体系结构风格：

它是软件设计人员在长期的软件设计过程中总结出来的一些规律性的东西，经过提炼总结而成。

7.2.1WrightADL

调用实例的Wright体系结构描述

调用实例的GADL体系结构描述—构件图

调用实例的GADL体系结构描述—类图

实例剖析：

统计a.txt中单词的个数并打印出来：

shell命令：

“cata.txt|wc-w|lpr”

1、cat命令输出a.txt的内容2、通过管道传给命令wc，统计输入流中单词的个数并输出3、输出的单词数通过管道传给命令lpr，lpr将其打印出来

一个“管道/过滤”系统实例：

系统功能：

读取一个字符流，并输出把每隔一个的字符转换成大写字母的字符流。

1.管道/过滤器风格

特征：

系统中构件之间通过数据流松散耦合。

也就是说，构件之间的依赖仅仅是数据流，而不是通常的接口函数调用或消息传递。

2.分层风格

从向外提供服务的构件出发，沿着连接关系递次搜索各构件和连接件，如果形成的拓扑结构是一个有向无圈图（典型情况下是一个线性结构），那么这个系统的体系结构风格就是层次式的。

这种设计风格便于将复杂的系统进行分解；

同时也便于构件替换：

只要保持接口一致，就可以将某一层的软件替换掉，而不会影响到系统的其他部分。

7.4设计模式

设计模式，并将它们分为三种类型：

创建型设计模式、结构型设计模式和行为型设计模式。

1.FactoryMethod例：

“龙珠”游戏-设计1

适用场合：

有一些实体（各种魔力管道），它们的结构和行为是相似的，且都包含一些相似的更小实体（各类球），但一个大实体内部的这些小实体都是同一类的（一种魔力管道内只有一种球）。

核心思想归纳：

在父类中，将创建对象的操作包装为一个虚函数，在描述公共行为的过程中调用该函数；

在子类中重定义该虚函数来定制创建的对象，从而间接定制公共行为。

利用虚函数的多态机制，FactoryMethod模式使得父类可集中描述公共行为，而将特别行为（不同对象的创建）抽放于子类。

2．AbstractFactory例：

魔力管道。

当需要创建一组多种风格的小实体、且具体创建方式又要灵活可调整时，可使用AbstractFactory模式，将公共的创建行为描述为一个抽象类，而将具体的创建方式用该抽象类的子类来描述。

为了提供灵活性，将需要创建的同一风格的一组小实体的一般特征提取出来，用一组抽象产品类来描述，同时将创建行为封装为一个抽象工厂类，提供通用的创建接口，而将各种具体的产品和具体的创建行为用抽象产品类和抽象工厂类的子类来描述。

从而使得BigEntity和具体的产品特性和具体的创建行为隔离开来，既降低了耦合度，也使得灵活调整创建行为成为可能。

3.Composite例：

幻灯片制作软件。

当需要描述的对象具有“递归组合”特征、且希望用户忽略基本对象与组合对象的区别时，适用本模式。

为基本对象和组合对象提供一个公共的抽象父类，以表示所有对象，并建立起从该抽象父类到组合对象类的聚集关联，从而间接建立起“递归组合”特性。

第八章基于分布构件的体系结构

8.1EJB构件框架

EJB构件框架将分布构件分布成三种：

会话Bean（SessionBean）、消息驱动Bean（Message-DriveBean）和实体Bean（EntityBean）。

第九章软件体系结构评估

评估时机：

早评估和迟评估；

如果一个软件体系结构满足以下两个标准，那么就认为它是适宜的：

1.系统的结果满足质量目标。

2.系统能够使用现有的资源来开发，现有资源包括：

人员、预算、任何遗留系统以及交付之前分配的时间。

ATAM方法基本过程（4组）介绍、调查和分析、测试、报告

效果树：