软件设计期末复习重点

《软件设计期末复习重点》由会员分享，可在线阅读，更多相关《软件设计期末复习重点（20页珍藏版）》请在装配图网上搜索。

1、爱第一章 软件工程与软件设计1.1软件工程软件分类：1. 系统软件2. 实时软件3 嵌入式软件4. 科学和工程计算软件5. 事务处理软件6. 人工智能软件7. 个人计算机软件软件工程由方法、工具和过程三个要素组成1.3软件开发过程模型131瀑布模型：是既自顶向下结构化开发模型需求说明书甲题定义定义做什么的问题结构 L可行性誚h , 设计如何做的体系结构I|；：心|维护阶段WWn 口| | 修改设计雇諾 |樹报告1.3.2快速原型模型快速原型棋型1.3.3螺旋模型由四部分组成:1. 需求定义2. 风险分析3. 工程实现4. 评审；特点:1. 瀑布模型+快速原型+风险分析2. 迭代过程制定计划 决

2、定目标. 方案和限制用户评估析提交线评审实施工程开发、验证 下一产品风险分析评价方案、 识別风险、 消除风险需求划幵发计划软件产 品设计可运行原樂详细设计单元谭码f 组装测试I 亠J验收打加 实现:测试:测贰II1.4软件设计软件设计的概念：对软件如何被开发出来的一种描述1.5软件体系结构软件体系结构的左义（较有影响力的泄义）：1. 软件体系结构是软件系统的结构，包括软件元素，软件元素外部可见的属性以及这些软 件元素之间的关系；2. 软件体系结构是软件系统的基本组织，包括构件，构件之间，构件与环境之间的关系， 以及相关的设计和演化原则。第二章2.1 UML概述2.1.3 UML2.0的建模机制

3、建模机制中包含的13种视图模型可以划分为结构视图和行为视图两种类型。建模机制包括：结构建模，行为建模结构建模包含：类图，包图，对象图，构件图，组合结构图，部署图行为建模包含：活动图，交互图（顺序图，通信图，交互概览图，时序图），状态图，用例 图2.2面向对象开发方法2.3 UML2.0结构建模2.3.1类图（作用）：类图是UML中最基本、也是最重要的一种视图，它用来刻画软件中类 等元素的静态机构关系。依赖关系：两个类之间存在依赖关系,表明一个类使用或需要知道另个类中包含的信息。Customer Productcatalog关联关系：两个类之间存在关联关系，表明这两个类的实例之间存在语义上的联系

4、。Person+Employee+EmployeeCompany*1聚集关系聚集关系表明两个类的实例之间存在一种拥有或属于关系，可以看做是一种比较 弱的整体的一部分关系，或是一种逻辑上的隶属关系。（图上菱形是空的）Pers on1 tPers on2.4 UML 2.0行为建模2.4.1 顺序图：（给出用例画出顺序图）【课本41页】2.4.7 用例图：（作用，参与者，用例）【课本50页】作用：用例图通常被用来描述系统的需求，从用户的角度对系统的功能视点进行建 模。用例：一个用例代表系统执行的一组动作，这些动作完成特左的任务，并产生对用 户或外部实体可观察的结果。用例用来描述系统对外可见的需求或

5、功能。参与者：参与者是与用例发生交互的系统外部角色，必须是被开发的系统范囤之外 的角色（不必在本开发系统中实现），它们只与系统发生某种形式的交互。第三章软件设计基础3.1软件设计的基本概念3丄1抽象与逐步求精（概念）【课本55页】抽象：抽象是一个心理学概念，它要求人们将注总力集中在某一层次上考虑问题, 而忽略那些低层次的细节。是管理、控制复杂性的基本策略。逐步求精：逐步求精可视为一种早期的自顶向下设汁策略，其主要思想是，针对 某个功能的宏观描述用逐步求精的方法不断地分解，逐步确立过程细肖，直至该功 能用程序语言描述的算法实现为止。3.1.2模块化与信息隐藏（概念、好处）【课本57页】模块化：即

6、把软件划分为可独立命名和访问的部件，每个部件称为一个模块，当把所有模块 组装到一起时则获得满足问题需要的一个解。信息隐藏：即一个模块的开发者不必看到其它模块的内部，只需知道其接口即可，这使得每 个模块的开发人员所要处理的复杂性显著降低。未来达到信息隐藏的目的，模板应该被设计 为其所含信息（过程和数据）对于那些不必要的信息模块不可访问。3.1.3内聚与耦合（不同内聚概念、判断、举例）【课本58页】1内聚偶然性内聚：一个模块内各成分为完成一组功能而组合在一起，它们相互之间即使 有关系，也很松散（内聚程度最低）例1: 一个程序员写完一个程序后发现有一组语句多处岀现，于是为了节省内存便 将这组语句单独

7、组成一个模块。例2：工具模块逻辑性内聚：模块完成的诸任务逻辑上相关时序内聚：一个模块包含的任务必须在同一时间内执行例：系统的初始化过程性内聚：模块内成分彼此相关，并且必须按特立的次序执行通信内聚；模块中各成分都将对数据结构的同一区域进行操作 例如：从同一磁带上读取不相干的数据一一可能破坏独立性。顺序性内聚：各成分均与同一功能相关，且处理按序执行功能性内聚：所有成分形成一个整体，完成单个功能（内聚程度最高）2.耦合非直接耦合：两个模块中的任一个都不依赖对方能独立工作。（耦合度最低）例1： A访问C的内部数据或不通过正常入口而转入C的内部。例2：部分代码重叠（常出现在汇编程序中）例3： 个模块有多

8、个入口（功能）数据耦合：两模块间通过参数交换信息，数据仅限于数据。控制耦合：模块间传递的信息含有控制信息。特征耦合：介于数据耦合和控制耦合之间。外部耦合：若干模块均与同一外部环境关联。公共耦合：若T模块通过全局的数据环境相互作用。内容耦合：一个模块使用列一模块内部的数据或控制信息，或一个模块直接转移到 另一模块内部。（最高耦合度）3. 3软件设计的质量1. 结构良好2. 充分性3. 可行性4. 简单性5. 实用性6. 灵活性7. 健壮性&可移植性9. 可复用性10. 标准化灵活性（如何提高灵活性，可靠性）【课本67页】举例：网站成员注册八 membersO.n O* MemberWebSite

9、 register()class WebsiteMembermembers;/ or maybe：vector members; void register(Member aMember) 怎样才能使设讣更灵活以注册新类型的成员？解决方案：引入一个基类，将基类抽象化，根据需要产生继承类 我们之所以进行灵活的设计，因为变化和重用是经常出现的2. 健壮性1. 防止错误输入0用户输入0不是用户的输入数据通信其他应用方法调用2. 防止开发错误错误的设计错误的实现检査输入在继续进行处理之前，可以检査应用程序的所有输入的方法。检查类型（例如：整形）；检查与前置条件和不变式的输入为提高健壮性而初始化提供静态

10、方法，用来为类产生标准的默认值提高健壮性的参数传递技术保证方法正确调用引入一个捕获参数的类并将约朿条件合并强化意图通过防I匕设汁和实现中的错误来提髙健壮性强化计划，按计划使用相应功能3. 4软件体系结构设计【课本68页】“4+1”模型：每一个视图只关心系统的一个侧而，5个视图结合在一起才能反映系统的软 件体系结构的全部内容。1. 逻辑视图：主要支持系统的功能需求，即系统提供给最终用户的服务。在面向对象技术中， 通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。2. 进程视图：该视图捕获设汁中关于并发和同步的内容，重视一些非功能性需求。3. 开发视图：该视图主要描述软件在

11、开发环境中的静态结构，该视图的构建和连接件分别映 射到子系统或模块，关注于在软件开发环境中软件模块的组织。软件可以被打包为子系统, 并按层次进行组织。4. 物理视图：该视图描述软件到硬件的映射关系，反应了软件的分布特征。把不同的软件元 素，例如进程和任务等，映射到不同的物理节点上，并关注物理环境的拓扑结构以及节点间 的通信。5. 场景：场景通常是最重要的需求，一方而作为设汁中发现体系结构元素的驱动器，列一方 而在设计完成后，充当确认和验证的证据。开发人员 软件管理集成人员 性能可扩展性最终用户 功能特性逻辑视图开发视图/f J 场最/ 1.进程视图物理视图系统工程师拓扑通借3.5髙可信软件设计

12、在等待外部信号的程序段中，不允许无限制地等待。正确的做法应是，或采用循环等待 次数控制，或使用定时器，使得规定时间内（无论成功或失败）必须保证退出等待外部信 号的程序段。A写flag可能写不上不允许的设计方法建议釆用的设计方法B負正左读出flagB扌可能写不上vKite data/ 、%read date/ 1vmte 1 to flag/T、B正左邃出flagB?write 0 to flag握手标志置写不上的可能read out flagwiitBdataBwrite 1 toftagreM out flag可靠的设计方法3. 5. 2容错设计 1避错：避错设计是使软件产品在设计过程中，不

13、发生错误或少发生错误的一种设 计方法。避错的设计原则是控制和减少程序的复杂性。从开发方法、工具等多处着手避免需求错误深入研究用户的需求(用户申明的和未申明的)用户早期介入，如采用原型技术选择好的开发方法结构化方法：包括分析、设计、实现面向对象的方法：包括分析、设计、实现 基于部件的开发方法(COMPONENT BASED)快速原型法 2.査错：软件査错设计是指在设计中赋予程序某些特殊的功能，使程序在运行中自 动査找存在错误的一种设计方法。被动式错误检测在程序的若干部位设置检测点，等待错误征兆的岀现主动式错误检测对程序状态主动进行检査检测原则相互怀疑原则：在设计任何一个单元、模块时，假设其它单元

14、、模块存在着 错误;立即检测原则：当错误征兆出现后，要尽快查明，以限制错误的损害并降低 排错的难度。负效应所设巻的“接收判据”不可能与预期的正确结果完全吻合，导致错判或漏 判；软件增加了冗余可能降低可靠性 3改错：改错设计是指在设汁中，赋予程序自我改正错误、减少错误危害程度的能 力的一种设计方法。改正错误的前提是已经准确地找出软件错误的起因和部位(故障检测与故障左位合 称故障诊断)，程序又有能力修改、剔除有错误的语句。现阶段仅限于减少软件错误造成的有害影响，或将有害影响限制在一个较小的范用。 常采用故障隔离技术。第四章4. 2用例分析与设计4.2.3用例设计描述【课本105页】案例：银行ATM

15、自动柜员机的需求简述(本案例将要开发的ATM系统能够为顾客提 供以下基本服务，它们统一称为交易)：取款服务。顾客可以用银行卡从对应的账户中支取现金，现金必须是100元 的整数倍，且每次取款不能超过2000元。存款服务。顾客可以把现金存入与银行卡对应的账户中。转帐服务。顾客可以把一个银行卡对应的账户中的款项转帐到另一个银行账 户中。査询服务。顾客能够查询一个银行卡对应的账户中的余额。 该ATM系统包括以下组成部分：读卡器交互的控制台，键盘及显示器送出现金的装巻，取款器存款的插槽，存款器打印机启动和关闭ATM系统的开关键盘 ATM系统与银行服务通过特圧的网络连接进行通信 ATM系统在提供以上服务的

16、过程中，必须满足以下要求 一个顾客可以在最终确认前放弃一项交易 ATM在执行交易过程中将与银行系统进行通信，对是否允许交易进行验证 ATM为每次成功的交易提供一个打印回执 ATM需要维护一个内部日志，对每次交易进行记录参与者：与系统交互的人、设备、其他系统顾客(Customer) “操作管理人员”(Operator) “银行服务器” (Bank System) 读卡器(Card Reader) 存款器(Cash Acceptor) 取款器” (Cash Dispenser) “打印机” (Printer)用例描述：用例夕I称:Withdrawal 参与者:Customer. Bank Syst

17、em. Card Reader, Cash Dispenser, Printer前置条件:顾客已插入银行卡，密码验证正确，顾客按下“取款”按钮主事件流:()顾客输入取款金额，并确认。系统认可取款金额，并发送指令给取款器。取款器把相应金额的现金送出。打印机打印回执。辅事件流:如果取款金额不是100的整数倍，则显示信息输入金额必须是100的整数 倍，请重新输入”，并返回主事件流中步骤（l）o如果取款金额超过2000元，则显示信息“输入金额不能超过2000元，请重 新输入”，并返回主事件流中步骤（l）o如果账户余额小于取款金额，则显示信息账户余额不足，请重新输入”， 并返回主事件流中步骤（1）。顾客

18、在确认取款金额前可以选择取消交易。后置条件:如果取款成功，系统从账户余额中减去相应数额，并返回等待状态：如 果顾客取消交易，则返回等待状态。4. 3概念模型和顶层架构设计（）4. 3.1概念模型设计从分析类所负责的主要功能需求看，系统可以包含三种分析类：1. 边界类：负责目标软件系统与参与者之间的交互，构造型为boundary。通常 情况下，参与者与用例之间的一种通信连接对应一个边界类。貝职责包括：2. 控制类：作为完成用例任务的责任承担者，负责协调、控制其它类共同完成用例 规泄的功能或行为。构造型为control。用例通常对应控制类。3. 实体类：负责保存目标软件系统中具有持久意义的信息项并

19、向其它类提供读、写 信息项内容的必要操作接口，一般不涉及业务逻借处理。构造型为entity。4. 3. 2顶层架构设计（目的）顶层架构的主要目的是为后续的分析和设计活动建立一种结构和划分，以便开发人员 在不同的开发阶段，以及同一开发阶段的不同开发人员，能够聚焦于系统的不同部分。4. 6. 2调整软件构成类对类进行调整和优化主要包括：1. 增加辅助类：2. 合并相互通信频繁的类：3. 分拆规模过大的类；第五章面向数据流的软件设计方法5.2实体关系图数据对象有属性描述，通常，属性包括：1. 命名性属性：对数据对象的实例命名，苴中必含有一个或一组关键属性，以便唯一地标 识数据对象的实例。2. 描述性

20、属性：对数据对象实例的性质进行描述。3. 引用性属性：将自身与其他数据对象的实例关联起来。规范化规则：1. 数据对象的任何实例对每个属性必须有且仅有一个属性值：2. 属性是原子数据项，不能包含内部数据结构；3. 如果数据对象的关键属性多于一个,那么其他非关键属性必须表示整个数据对象而不是部.分关键属性的特征：5. 所有的非关键属性必须表示整个对象而不是部分属性的特征。5.4面向数据流的设计过程（）5.4.1变换流与事务流而向数据流的方法能方便地将数据流图转换为软件结构，其过程分为五部：1. 确定信息流的类型：2. 划分流界：3. 将数据流图映射为程序结构：4. 提取层次控制结构：5. 通过设计

21、复审和使用启发式策略进一步精化所得到的机构。5.4. 2变换分析步骤1：复审基本系统模型步骤2：复审和精化软件数据流图步骤3：确定数据流图的特性，判定它为变换流还是事务流步骤4：通过划定输入流和输出流的边界来孤立变换中心，即把DFD划分成逻辑输入、主加 工和逻辑输出三个部分。步骤5：执行“一级分解”步骤6：执行“二级分解”，即设计中下层模块步骤7：采用启发式设计策略，精化所得程序结构雏形，以求改良软件质量5. 4. 3事务分析步骤一：复审基本系统模型步骤二：复审并精化软件数据流图步骤三：确泄数据流图的特性，判泄它为变换流还是事务流步骤四：指出事务中心，确定由事务中心发出的每一动作路径的数拯流特

22、性步骤五：把数据流图映射为事务处理型的程序结构步骤六：分解并精化事务结构以及每条动作路径所对应的结构步骤七：使用启发式设讣策略，精化所得程序结构雏形，改良软件质量例：针对图所示的DFD,采用事务分析法导出程序结构，因其主体数据流为事务流（c为事务中 心）。显然，区域I为变换流；区域II为事务流，但其各个子流为变换流：区域III为变换流。 在你所设计的程序结构中，除了每个变换对应一个模块外，可能还需增加若干控制模块。组合得程序结构的雏形，精化雏形，如下图:I n I I d IEOI SI B III 1 fgl h 控 11 El片2|I”3| 甲4| 向 nh 顾控31宙 filE 白 由m

23、rhrVirni区3囚回回 帀同 111 色E由吋由申四EK1 mCTIE1K由第六章用户界面设计6.1界面设计的基本原则原则描述用户熟悉程度界面应该采用经常使用系统的用户所熟悉的术语和概念一致性界面必须一致，在任何可能的情况下相同的操作应该以同样的方式被激活使惊讶最小化尽量避免使用户对系统的行为感到惊讶可恢复性界而应该为用户提供错误恢复机制用户帮助界而应该在错误发生时提供有意义的反馈.并且提供上下文敏感的用户帮 助系统用户多样性界而应该为不同类型的用戸提供恰当的交互方式6. 2设计良好界面的主要途径用户界而设汁中有三条“黄金规则”（如何理解）1使系统处于用户控制之中2. 减少用户记忆负担3.

24、 保持界而一致性6. 3. 2界面分析和设计模型在用户界面的分析和设计过程中，有四种模型能够起作用:1. 用户模型2. 设计模型3. 心智模型或系统感知模型4. 实现模型6. 4用户界面分析用户分析技术；任务分析用户采访和问卷调査群体文化学6. 5.2界面设计需考虑的问题1. 响应时间系统响应时间有两个重要特征：长度和变化性； 变化方式是指与平均响应时间的偏差：2用户帮助消息措辞中的设计因素闵素描述上下文用户指南系统应该能注意到用户为前在T什么，针对十耐上下文调機输出信 息经验因为用户逐渐变得对系统熟悉了，同时也会对兀过于详细的消息所激 怒。但初学者可能还嫌太短，问.题阐述得不够消遵。用户指南

25、系统应该提供两种 类型信息并允许用户控制消息的简明程度技能水半消息应该根据用户的技能和经验进行剪裁。消息应该根据不同类里的用户对 彖选择不同的农达方式和所用的术语风格消息应该足枳极的而不足消极的。应该以主动方式去表示出来而不足被动显 示。它们决不能足物理的或足滑梢怪诞的文化消息的设计诸应该尽可能地熟悉系统所销倒的国家的文化传统。在欧洲、亚 洲和关洲之间存在右L1大的文化差亓。条消息对一个地区是适合的而在另个 地区就可能是不可接受的第七章软件体系结构风格和设计模式7.1基本概念软件设计模式：可解决一类问题并能重复使用的解决方案软件体系结构风格:它是软件设汁人员在长期的软件设汁过程中总结岀来的一些

26、规律性的东 西，经过提炼总结而成。7. 2. IWright ADL构件连接件System ProcedureCail component Definer匚过程调用系统port provide ptwide protocol spec Definer protocol _ component Caller =port request requestprotocol spec Caller protocolcounecfor DOconnector =role de f iner = call 一 return 一 de finer role culler = call 一 ret - call

27、er n _ glue = raller.call dcfincr.call 、glue de finer, ret ttm caller yfwn. glue粘连規范实例Iiisfnncesd: Definerc: Caller de: D-C-connectorAftaclimcnts联接1.provide ns lc.definer;c.request as de.caller end ProccckircCall.调用实例的Wright体系结构描述调用实例的GADL体系结构描述一构件图调用实例的GADL体系结构描述一类图 实例剖析：统计a. txt中单词的个数并打印出来：shell命令

28、：cat a. txt | wc | lprK cat命令输出a. txt的内容2、通过管道传给命令wc,统计输入流中单词的个数并输出3、输出的单词数通过管道传给命令lpr, lpr将其打印出来一个“管道/过滤”系统实例:系统功能：读取一个字符流，并输出把每隔一个的字符转换成大写字母的字符流。1. 管道/过滤器风格特征：系统中构件之间通过数据流松散耦合。也就是说，构件之间的依赖仅仅是数据流，而 不是通常的接口函数调用或消息传递。2. 分层风格特征：从向外提供服务的构件岀发，沿着连接关系递次搜索各构件和连接件，如果形成的拓 扑结构是一个有向无圈图（典型情况下是一个线性结构），那么这个系统的体系结

29、构风格就 是层次式的。这种设讣风格便于将复杂的系统进行分解：同时也便于构件替换：只要保持接 口一致，就可以将某一层的软件替换掉，而不会影响到系统的英他部分。7.4设计模式设计模式，并将它们分为三种类型：创建型设讣模式、结构型设汁模式和行为型设汁模式。1. Factory Method 例：“龙珠”游戏-设计1适用场合：有一些实体（各种魔力管道），它们的结构和行为是相似的，且都包含一些相似 的更小实体（各类球），但一个大实体内部的这些小实体都是同一类的（一种魔力管道内只 有一种球）。核心思想归纳：在父类中，将创建对象的操作包装为一个虚函数，在描述公共行为的过程中 调用该函数：在子类中重泄义该虚函

30、数来定制创建的对象，从而间接左制公共行为。利用虚 函数的多态机制，Factory Method模式使得父类可集中描述公共行为，而将特别行为（不 同对象的创建）抽放于子类。2. Abstract Factory 例：魔力管道。适用场合：当需要创建一组多种风格的小实体、且具体创建方式又要灵活可调整时，可使用 Abstract Factory模式，将公共的创建行为描述为一个抽象类，而将具体的创建方式用该 抽彖类的子类来描述。核心思想归纳:为了提供灵活性，将需要创建的同一风格的一组小实体的一般特征提取出来, 用一组抽象产品类来描述，同时将创建行为封装为一个抽象工厂类，提供通用的创建接口， 而将各种具体

31、的产品和具体的创建行为用抽象产品类和抽象工厂类的子类来描述。从而使得 BigEntity和具体的产品特性和具体的创建行为隔离开来，既降低了耦合度，也使得灵活调 整创建行为成为可能。3. Composite例：幻灯片制作软件。适用场合：当需要描述的对象具有“递归组合”特征、且希望用户忽略基本对象与组合对象 的区別时，适用本模式。核心思想归纳为基本对象和组合对象提供一个公共的抽象父类.以表示所有对象，并建立 起从该抽象父类到组合对象类的聚集关联，从而间接建立起“递归组合”特性。第八章基于分布构件的体系结构& 1 EJB构件框架EJB构件框架将分布构件分布成三种：会话Bean (Session Be

32、an)、消息驱动 Bean (Message-Drive Bean)和实体 Bean (Entity Bean) o第九章软件体系结构评估评估时机：早评估和迟评估；如果一个软件体系结构满足以下两个标准.那么就认为它是适宜的：1. 系统的结果满足质量目标。2. 系统能够使用现有的资源来开发，现有资源包括：人员、预算、任何遗留系统以及交付 之前分配的时间。ATAM方法基本过程(4组)介绍、调査和分析、测试.报告 效果树:性能数据延迟-交易吞吐量把客户数据库的存储延迟 厂最小化到200奉秒I(H.M)实时磺供视频-(MAI)虽大化授权服务器的平均吞吐量L新添加产品种类一可变性修改COTS (L.H)在少于20人月的代价下加 ACORBA中间件I(HX)在少于4人周的代价下修改 Web用户界面效果一件失败 可用性OTS软件失败(L.H)由于站点1的动力故障而需要 把谙求转到站点3的时间要低于3秒 (MAI)磁盘失败后重新启动的时间要低于5分钟一 (H3D用于监测并恢复网络失败的 时间要少于15分钟数据保密性安全性数据完整性一 (LJI)信用卡和事务在99.999%的烈)内猗护麥据局的授权在 99.999%的时间内是安全的