第一章作业6、简要叙述软件设计在软件工程中所处的位置和重要性。

答：所处的位置：软件需求分析→需求规格说明→软件设计→设计文档→软件编码。

重要性：（1）是对软件需求的直接体现；（2）为软件实现提供直接依据；（3）将综合考虑软件系统的各种约束条件并给出相应方案；（4）软件设计的质量将决定最终软件系统的质量；（5）及早发现软件设计中存在的错误将极大减少软件修复和维护所需的成本。

7、软件设计应该包含哪些要素？答：软件设计应该包含：目标描述、设计约束、产品描述、设计原理、开发规划、使用描述。

8、软件体系结构与软件设计有何关系？软件体系结构的出现有何必然性和重要意义？答：软件体系结构与软件设计的关系：软件体系结构设计作为软件设计过程中的活动之一，能在较为抽象的级别上描述整个软件系统的结构，成为大规模、复杂软件系统设计中必不可少的步骤。

软件体系结构的意义：软件体系结构将构件以及构件之间的连接作为软件体系结构的基本组成部分。

软件体系结构使软件复用从代码复用发展到设计复用和过程复用，为不同的人提供了共同的语言，体现了系统早期的设计决策，并作为系统设计的抽象，为实现框架和构件的共享与复用，基于体系结构的软件开发提供了有力的支持。

第二章作业1、简述UML的特点和用途。

答：UML的发起者在最初制定UML时，充分考虑了各种需求、方法和语言的特点使UML在表达能力、对新技术的包容能力和扩张性等方面具有显著的优势：（1）为使用者提供了统一的、表达能力强大的可视化建模语言，以描述应用问题的需求模型、设计模型和实现模型。

（2）提供对核心概念的扩展机制，用户可加入核心概念中没有的概念和符号，可为特定应用领域提出具体的概念、符号表示和约束。

（3）独立于实现语言和方法学，但支持所有的方法学，覆盖了面向对象分析和设计的相关概念和方法学。

（4）独立于任何开发过程，但支持软件开发全过程。

（5）提供对建模语言进行理解的形式化基础，用元素型描述基本语义，OCL描述良定义规则，自然语言描述动态语义。

（6）增强面向对象工具之间的互操作性，便于不同系统间的集成。

UML的目标是以面向对象方式描述任何类型的系统，具有广泛的应用领域。

UML最常用于建立软件系统的模型，但它同样可以用于描述非软件领域的系统，如机械系统、企业机构或业务过程、处理复杂数据的信息系统、具有实时要求的工业系统或工业过程、甚至数字电路等。

2、在面向对象开发方法中，对象、类、继承、聚集、多态、消息等概念分别指什么？答：（1）对象。

对象是现实世界中个体或事物的抽象表示，是其属性和相关操作的封装。

属性表示对象的性质，属性值规定了对象所有可能的状态。

对象的操作是指该对象可以展现的外部服务。

（2）类。

类是某些对象的共同特征（属性和操作）的表示。

对象是类的实例，类是对象创建的模板。

（3）继承。

类之间的继承关系是实现现实世界中遗传关系的直接模拟，它表示类之间的内在联系以及对属性和操作的共享，即子类可以沿用父类（被继承类）的某些特征。

子类也可以具有自己独有的属性和操作。

（4）聚集。

除遗传关系外，现实世界中还普遍存在着部分整体关系。

这种关系在面向对象方法学中表示为类之间的聚集关系。

在聚集关系下，部分类的对象是整体类对象的一个组成部分。

（5）多态。

多态指父类及其子类中，对外接口的定义形式相同，却可以对应多种接口的实现形态。

（6）消息。

消息传递是对象与其外部世界相互关联的唯一途径。

4、UML结构建模和行为建模有何区别？答：结构建模被称为静态建模，主要用来描述系统中包含的元素以及元素之间的关系；行为模型被称为动态模型，主要用来刻画系统中的动态行为、过程和步骤。

5、简要叙述类图在UML中的意义和重要性，以及类图和对象图有何联系与区别。

答：（1）意义：类图用来刻画软件中类等元素的静态结构和关系。

（2）重要性：面向对象软件的最终实现体现为多个类的实现和组织，因此类图与面向对象软件实现之间的映射最为直观，对软件结构的设计至关重要，是软件实现要遵循的主要规格说明。

（3）类图和对象图的联系：对象是类的实例，对象图也可以看做类图的实例，对象之间的连接是类之间的关联关系的实例。

对象图描述在特定时刻和特定环境下，类图中类的具体实例以及这些实例之间的具体连接关系，能帮助人们理解一个比较复杂的类图。

（4）类图和对象图的区别：对象的名字下面要加下划线，对象名称后可以注明所属的类。

在一个对象图中可以同时出现一个类的多个实例。

第三章作业2、简述模块化与信息隐藏在软件设计中的意义。

答：软件系统的模块化是指整个软件被划分成若干单独命名和可编址的部分，称之为模块，这些模块可以被组装起来满足整个问题的需求。

在软件设计中实现了功能划分把复杂的大的功能划分成简单的小的模块结构，尽量降低每个模块的成本，减少接口，确保软件总成本最低。

模块化使开活动更加简单的一个重要因素是模块的信息隐藏，即一个模块的开发者不必看到模块的内部，只需要知道其接口即可，使开发者的复杂性降低，不仅支持模块的并行开发，而且还可以减少测试和后期维护的工作量。

3、内聚度、耦合度分别指什么？为什么软件设计要追求高内聚、低耦合？答：内聚度是一个模块内部各成分之间关联程度的度量；耦合度是对模块间关联程度的度量。

软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准。

划分摸块的一个准则就是高内聚低耦合。

模块间的耦合度是指模块之间的依赖关系，包括控制关系、调用关系、数据传递关系。

模块间联系越多，其耦合性越强，同时表明其独立性越差。

降低模块间的耦合度能减少模块间的影响，防止对某一模块修改所引起的“牵一发动全身”的水波效应，同时每一个类完成特定的独立的功能，实现高内聚，保证系统设计顺利进行。

内聚和耦合密切相关，同其它模块存在强耦合关系的模块常意味这弱内聚，强内聚常意味着弱耦合。

5、为什么软件设计过程常常是一个不断迭代的过程？答：设计者一般不可能一次就能完成一个完整的设计，软件设计可能是一个反复的过程，在设计过程中需要不断添加设计元素和设计细节，并对先前的设计方案进行修正。

所以，软件设计一般都可以被看做是迭代的过程。

8、是总结本章列举的软件体系结构设计方法各有何特点。

结合自己的开发经验，讨论如何选择合适的软件体系结构设计方法。

答：特点如下：（1）软件体系结构的多视图建模通过逻辑视图，开发视图、进程视图、物理视图、进程来描述的软件体系结构。

（2）基于评估与转换的软件体系结构设计通过迭代的开发方式，直至满足客户的需求。

（3）模式驱动的软件体系结构设计通过总结、记录、复用来实现的体系结构设计（4）领域特定的软件体系结构设计借鉴领域中已经成熟的软件体系结构来实现解决方案在某个领域内的复用。

（5）软件产品线方法软件复用发展的一个更高阶段，它并不仅仅局限于以前人们在软件复用中考虑的对函数、模块、类、体系结构甚至子系统的复用。

（6）其于目标推理的软件体系结构设计方法功能需求和非功能需求皆被表达为要达到的目标。

（7）其于属性的软件体系结构设计方法基于目标图推理的体系结构设计方法、基于属性的体系结构设计方法。

开发心得：在这些具有系统化过程的软件开发方法中，体系结构设计师一个不可避免的过程，它们也都有自己的一些设计方式。

但这并不排斥前面讲到的软件体系结构设计方法，反之，如果能把这些体系结构设计方法与开发方法学结合起来，将能起到更好的效果。

12、嵌入式软件有何特点？嵌入式软件设计可分为哪几类？答：特点：(1)一般用于单一任务；(2)有多种类型的处理器体系结构支持；(3)资源约束更加严格；(4)需要更高的可靠性和安全性；(5)对反应性和实时性要求很高；(6)通常固化存储。

通常分为以下两类：（1）无操作系统的嵌入式软件：前后台系统、中断驱动系统、巡回服务系统、基于定时器的巡回服务系统。

（2）有操作系统的嵌入式软件：分时系统、实时系统。

13、什么是软件设计规格说明？它在软件开发中有何重要用途？答：软件设计规格说明：软件设计过程中各个活动的结果最终应该文档化，形成正式的软件设计规格说明书，作为软件设计的输出，例如对系统的目标、范围、约束的定义，对软件结构、接数据等方面的设计等。

重要用途：形成软件设计规格说明被评审，并作为后续软件实现活动的依据。

14、软件设计评审的目标是什么？设计评审中需要关注哪几方面？答：目标：确保设计规格说明书能够实现所有的软件需求，及早发现设计中的缺陷和错误，并确保设计模型已经精化到合格的软件实现工程师能够构造出符合软件设计者期望的目标软件系统。

一、注意对需求规格说明的正确性进行评审1 是否有需求与其他需求相互冲突或者重复？2 是否清晰、简洁、无二义地表达了每个需求？3 是否每个需求都通过了演示、测试、评审，分析是否得到了验证？4 是否每个需求都在项目的范围内？5 是否每个需求都没有内容和语法上的错误？6 在现有的资源内，是否能实现所有的需求？7 每一条特定的错误信息，是否都是唯一的和具有含义的？二、注意对需求规格说明的实践性进行评审三、注意对需求规格说明的完整性进行评审1 编写的所有需求，其详细程度是否一致和合适？2 需求是否能为设计提供足够的基础？3 所有对其他需求的内部引用是否正确？4 是否包含了每个需求的实现优先级？5 是否定义了功能说明的内在算法？6 是否包含了所有已知的客户需求或系统需求？7 是否遗漏了必要的信息？如果有遗漏的话，把他们标记为待确定的问题？8 是否对所有预期的错误条件所产生的系统行为都编制了文档？四、注意对需求方案的可行性和成本预算进行评审五、注意对需求的质量属性进行评审六、注意对需求的可实施性进行评审七、注意对需求包含的用例文档进行评审1 用例的目标或价值度量是否明确？2 用例是否是独立的分散任务？3 是否明确说明可用用例会给哪些参与者带来用处？4 编写用例的详细程度是否恰当？是否有不必要的设计和实现细节？5 所有预期的分支过程是否都编写了文档说明？6 所有预估的异常过程是否都编写了文档说明？7 是否存在一些普通的动作序列可以分解成独立的用例？8 每个路径的步骤是否都清晰明了，无歧义而且完整？9 用例中的每个参与者和步骤是否都与所执行的任务有关？10 用例中定义的每个可选路径是否都可行和可验证？11用例的前置条件和后置条件是否合理？八、注意需求评审会的过程和结束标准1 审查期间评审员们提出的所有问题都已经解决。

2 相关文档中的所有更改都已经正确完成。

3 修订过的文档进行了拼写检查。

4 所有标识为TBD（待确定）的问题已经全部解决，或者已经对每个TBD的问题的解决过程、计划解决的目标日期和责任解决人等编制了文档。

5 需求文档正式进入了配置库。

第四章作业2、用例分析与设计在设计过程中起到什么作用？答：理解业务领域和初步需求描述文档，更准确地使用用例图描述系统需求，作为后续分析和设计活动的依据。