软件设计与体系结构总结

体系结构概要

1.软件开发知识的半衰期 为3年

2.支持软件工程的根基在于质量关注点

• 软件工程过程和实践的通用原则主要是：

– ① 为最终用户提供价值，

– ② 保持简洁，

– ③ 维护可见的东西（产品和计划），

– ④ 认识（必须理解别人将消费你所生产的产品），

– ⑤ 面向未来，

– ⑥ 计划复用，以及

⑦ 认真思考

3. 关于软件工程原则

指导实践的核心原则：（1）指导过程的原则、（2）指导实践的原则

指导框架活动的原则：沟通原则、策划原则、建模原则、构造原则、部署原则

建模原则：1.敏捷模型建模原则、2. 需求建模原则、3. 设计建模原则

4. 软件的三个设计层次：体系结构级，代码级，执行级

\5. 软件体系结构的定义

（1）Dewayne Perry和A1ex Wolf这样定义：软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组合连接起来。这一定义注重区分构件，这一方法在其他的定义和方法中基本上得到保持。

\6. 在体系结构的层次上，相关的系统级别的问题包括了容量、吞吐量、一致性、构件的兼容性等。

7.体系结构的设计原则： 1.抽象原则 2.分而治之 3.封装和信息隐蔽原则 4.模块化原则 5.高内聚低耦合 5.关注点分离 6.策略和实现分离策略 7.接口和实现分离原则

\8. 请解释需求工程

需求工程（Requirement Engineering，RE）是指致力于不断理解需求的大量任务和技术。从软件过程的角度来看，需求工程发生在与客户沟通活动和为一般的软件过程定义的建模活动过程中，其任务是为设计和构建活动建立一个可靠坚固的基础，它必须适应过程、项目、产品和人员工作的需要。需求工程在设计和构造之间建立起联系的桥梁。

9．需求工程过程通过执行七个不同的活动来实现：起始、导出、精化、协商、规格说明，确认和管理，其中起始、导出和精化属于项目的起始阶段

下面这组问题有助于理解为什么导出需求这么困难：

范围问题：理解问题：易变问题。

10. 软件需求规格说明（SRS）是在项目商业化之前必须建立详细描述软件各个方面的文档。

11. 质量功能部署（Quality Function Deployment，QFD）是一种将客户要求转化成软件技术需求的质量管理技术，其目的是“最大限度地让客户从软件工程过程中感到满意 ”。

12. QFD 确认三类需求：

正常需求。期望需求，令人兴奋的需求。

13. 需求建模活动产生以下一种或多种模型类型：场景 模型，数据模型，面向流程的模，行为模型，分析模型，软件域分析。

14. 类-职责-协作者（Class-Responsibility-Collaborator，CRC）建模提供了一个简单方法，可以识别和组织与系统或产品需求相关的类。

在结构化分析中，面向数据流建模仍然是当前使用最广泛的需求分析表达方式之一。

15. 需求模型由各种元素组成：基于场景（用例）、基于数据（数据模型）、基于类、基于流和行为。

16. 这些交互模型描述会话，这种交互模型由常用几种元素组成：① 用例；② 顺序图；③ 状态图；④ 用户界面原型。

17. 软件质量属性有哪些？

代表功能性（functionality）、易用性（usability）、可靠性（reliability）、性能（performance）、可支持性（supportability）

18. 软件设计中关注点有常用几种不同的信息分类：

1．功能性关注点 2. 服务质量关注点 3.政策 关注点 4.系统关注点 5.机构关注点

19．软件体系结构意指“软件的整体结构和这种结构为系统提供概念完整性的方式”。

20. 下面这组属性应该被指定为体系结构设计的一部分：

结构特性。体系结构设计表示定义了系统的构件（如模块、对象、过滤器）、构件被封装的方式以及构件之间相互作用的方式。例如，对象封装了数据和过程，过程操纵数据并通过方法调用进行交互。

外部功能特性。体系结构设计描述应当指出设计体系结构如何满足需求这些需求包括性能需求、能力需求、可靠性需求、安全性需求、可适应性需求以及其他系统特征需求。

相关系统族。体系结构应当能抽取出在一类相似系统开发中经常遇到的重复性模式。本质上，设计应当能够重用体系结构构件。

设计模式描述了在某个特定场景与可能影响模式应用和使用方式的“影响力”中解决某个特定的设计问题的设计结构。

信息隐蔽原则建议模块应该“具有的特征是：每个模块对其他所有模块都隐蔽自己的设计决策”。

功能独立的概念是关注点分离、模块化、抽象和信息隐蔽概念的直接产物。

内聚性显示了某个模块相关功能的强度，是信息隐蔽概念的自然扩展。

耦合性显示了模块间的相互依赖性，它表明软件结构中多个模块之间的相互连接性。

耦合性依赖于模块之间的接口复杂性、引用或进入模块所在的点以及什么数据通过接口进行传递。

通过连续精化过程细节层次来实现程序的开发，通过逐步分解功能的宏观陈述（过程抽象）直至形成程序设计语言的语句来进行层次开发。

抽象能够明确说明内部过程和数据，但对“外部使用者”隐藏了低层细节；精化有助于在设计过程中揭示低层细节。这两个概念均有助于设计人员在设计演化中构造出完整的设计模型。

重构是使用这样一种方式改变软件系统的过程：不改变代码（设计）的外部行为而是改进其内部结构。

21. 有五种不同类型的设计类，每一种都表示了设计体系结构的一个不同层次：

用户接口类：定义人-机交互（Human-Computer Interaction, HCI）所必需的所有抽象。在很多情况下，HCI出现在隐喻的环境（例如，支票簿、订单表格、传真机），而接口的设计类可能是这种隐喻元素的可视化表示。

业务域类：通常是早期定义的分析类的精化。这些类识别实现某些业务域元素所必需的属性和服务（方法）。

过程类：实现完整的管理业务域类所必需的低层业务抽象。

持久类：表示将在软件执行之外持续存在的数据存储（例如，数据库）。

系统类：实现软件管理和控制功能，使得系统能够运行，并在其计算环境内与外界通信。

22.组织良好的设计类具有4个基本特征： 完整性与充分性，关注于实现类的某一服务，高内聚，低耦合

23. 接口设计有3个重要的元素：① 用户界面（UI）；② 和其他系统、设备、网络或其他信息生成者或使用者的外部接口；③ 各种设计构件之间的内部接口。

24. 4种基础的体系结构视图是：

1）逻辑视图。显示了系统中对象和对象类的一些主要抽象。通过逻辑视图，可以将系统需求和实体关联起来。

2）进程视图。显示了在运行时系统是如何组织为一组交互的进程。这种视图对非功能系统特征的判断非常有效，比如性能和可用性。

3）开发视图。显示了软件是如何为了开发而被分解的，即将软件分解成可以由单独的开发人员或开发团队实现的组件。这种视图主要用于软件的管理者和程序员。

4）物理视图。显示了系统硬件和系统中软件组件是如何分布在处理器上的。这种视图对系统工程师规划系统部署非常有用。

25．5种典型的基本体系结构（构件、连接件和特性）是：

​ 1．功能结构 2.实现结构 3.并发结构 4.物理结构 5.开发结构

26. 应用较多的体系结构模式有：MVC（模型-视图-控制器）、批处理序列、管道-过滤器（数据流）、调用和返回、主程序和子程序、面向对象系统、多级分层、客户机-服务器、独立构件、通信进程、事件系统、虚拟机、解释器、基于规则系统、数据中心系统（知识库、黑板、容器）、数据库、超文本系统、过程控制。

27. 黑板模型通常由三个部分组成：

l）知识源：分离的，独立的，依赖于应用的知识包。知识源仅通过黑板进行交互。

2）黑板数据结构：问题求解状态数据，被组织成依赖于应用的层次结构。知识源不断修改黑板中的数据，直到问题得解。

3）控制器：完全由黑板的状态驱动。一旦黑板的状态使某个知识源可用，知识源就会适时地响应。

28. 应用框架（Application Framework）是整个或部分系统的可重用设计，表现为一组抽象构件的集合以及构件实例间交互的方法。

29. 事务处理系统（Transaction processing systems，TPS）是设计用来处理用户对数据库信息的查询或者对数据库的更新，允许数据库中的信息被很多远程用户访问和修改。

30. 语言处理系统用来将文本从一种语言翻译成另一种语言，例如把自然语言或人工语言翻译成该类语言的其他表示，对于编程语言可能会执行产生的代码，来执行输入语言所定义的指令。它们包括一个翻译器和一个执行生成的语言的抽象机。

31. 非功能性需求和软件体系结构的密切关系，我们为系统所选择的特殊的体系结构风格和结构应当依赖于哪些非功能性系统需求：

（1）性能。

（2）信息安全性。

（3）系统安全性。

（4）可用性。

（5）可维护性。

32. 原型（archetype）是体系结构设计的抽象构造块，是表示核心抽象的类或模式，该抽象对于目标系统体系结构的设计非常关键。

33. 在SafeHome住宅安全功能的例子中，可以定义完成下列功能的顶层构件集合：

外部通信管理——协调安全功能与外部实体（如基于因特网的系统与外部报警通知）的通信；

控制面板处理——管理所有的控制面板功能；

探测器管理——协调对系统所有探测器的访问；

警报处理——审核所有报警条件并执行相应动作。

34. 用UML进行设计通常需要如下两类设计模型：

（1）结构（静态）模型。通过系统对象类及其之间的关系来描述系统的静态结构。在这一阶段需要记录的重要关系有泛化（继承）关系、使用/被使用关系和组成关系。

（2）动态模型。描述系统的动态结构和系统对象之间的交互。需要记录的交互包括由对象发出的服务请求序列以及由这些对象交互触发的状态变化。

35. 在设计过程的早期阶段，有3个模型特别有助于为用例和体系结构模型增加细节，即：

​ 1.子系统模型 2.时序模型 3.状态机模型

36. 设计模式的4种主要元素是：

1）名字，是模式的一个有意义的指代。

2）问题域的描述，解释什么时候模式可以应用。

3）对部分设计的解决方案描述，描述设计方案的各个部分及其之间的关系和职责。模式可以用不同的方式实例化，通常以图形方式表达，示意出解决方案中对象及对象类间的关系。

4）结果陈述，说明应用该模式的结果和副作用。用来帮助设计者了解是否一个模式在特定环境条件下是有效的。

37 .软件复用的不通层次：

1. 抽象层次 2， 对象层次 3 . 组件层次 4.系统层次

38. 配置管理包含如下3个基本活动：

（1）版本管理，对软件组件不同版本的追踪提供支持。版木管理系统包括协调多个程序员开发的机制，可以防止一个程序员覆盖其他人提交到系统中的代码。

（2）系统集成，即提供支持帮助开发人员定义在创建每个系统版本时所用的组件版本。这些描述可以用于编译连接需要的组件以自动构建一个系统。

（3）问题追踪，即提供支持允许用户报告缺陷及其他问题，并允许开发人员查看谁在修复这些问题，以及何时完成的修复。

39. 传统构件也称为模块，作为软件体系结构的一部分，它承担如下3个重要角色之一：

① 控制构件，协调问题域中所有其他构件的调用；

② 问题域构件，实现客户需要的全部功能或部分功能；

③ 基础设施构件，负责完成问题域中所需支持处理的功能。

40. 构件级设计的基本设计原则，这些原则在使用面向对象软件工程方法时被广泛采用。

（1）开闭原则（The Open-Closed Principle, OCP）。

（2）Liskov替换原则（Liskov Substitution Principle, LSP）。“子类可以替换它们的基类”。

（3）依赖倒置原则（Dependency Inversion Principle, DIP）。“依赖于抽象，而非具体实现”。

4）接口分离原则（Interface Segregation Principle, ISP）。“多个客户专用接口比一个通用接口要好”。

41． 类聚的几个层次： 功能内聚 分层类聚 通信内聚

42. 基于构件的软件工程（Component-Based Software Engineering, CBSE）是一种强调使用可复用的软件构件来设计与构造计算机系统的过程。

43. CBSE把重点从编码转移到组装软件系统。考虑的焦点是“集成”而不再是“实现”

44. 领域工程包括3种主要活动：分析、构造和传播。

45. 构成可复用设计基础的一系列关键问题包括：

标准数据。应该仔细研究应用领域，并定义标准的全局数据结构（例如，文件结构或完整的数据库）。然后，所有的设计构件会被赋予使用这些标准数据结构的特性。

标准接口协议。应该建立3层接口协议：模块内部接口的基本属性，外部技术（非人）接口设计和人机接口设计。

程序模板。选取一种体系结构风格，可以作为新软件体系结构设计的模板。

可以用很多方式来描述可复用软件构件，但是理想的描述包括所谓的3C模型，即概念（concept）、内容（content）和环境（context）。

46. 有3种与面向对象设计相关的设计模式，即创建型模式、结构型模式及行为型模式。

1.设计模式比框架更抽象

2.设计模式是比框架跟小的体系结构元素

3.对设计模式比对框架要少

47. 为找到所需要的模式，主要取决于以下4个方面的有效交流，即模式要解决的问题，模式所在的环境，影响环境的因素及所提出的解决方案。

48. 根据粒度的级别，模式可以按下面的级别描述：

体系结构模式。这个抽象级别通常与定义WebApp总体结构的模式有关，表示不同构件或增量间的关系，为指定体系结构元素（网页、包、构件、子系统）间的关系定义规则。

设计模式。设计模式处理特定的设计元素（例如构件的聚合）来解决一些设计问题，网页上元素间的关系，或影响构件间通信的机制。例如，Broadsheet模式可用于WebApp主页的布局。

构件模式。这个抽象级别与WebApp的个别小规模元素有关。这方面的例子有：个别交互元素（例如，单选按钮），导航元素（例如，如何格式化链接）或功能性元素（例如特定算法）。

49 WebAPP质量需求树

.

50.根据WebApp性质的不同而适当地混合各种技术，用WebApp设计金字塔来各层技术关系。

\51. 嵌入式系统中激励有两类：

1）周期性激励。在每个可预测的时间时隔内发生。举例来说，系统可能每隔50ms检查一次传感器，根据传感器的值（激励）采取响应行动。

2）非周期性激励。这种激励是不规则地发生的，也是不可预测的。通常使用计算机的中断机制发送信号，中断指示输入/输出传输完成且数据已经在缓冲器中了。

52. 实时软件设计过程可能包含以下几步：

（1）平台选择。为系统选择一个执行平台，即要使用的硬件和实时操作系统。影响选择的因素包括系统的时序限制、可用电源的限制、开发团队的经验、交付系统的价格目标。

（2）激励/响应识别。包括识别系统必须处理的激励和对每种激励相应的一个或多个响应。

（3）时序分析。对于每种激励和相应的响应，找到应用于激励和响应处理的时序约束，用于在系统中为进程建立时限。

（4）进程设计。将激励和响应处理聚集到几个并发的进程中，然后优化进程体系结构，以反映出需要实现的特殊需求

（5）算法设计。对于每个激励和响应设计算法执行所需要的运算。算法设计需要在设计过程中相对早些进行，给出要求处理的数量的提示和完成处理所需要的时间的提示。这对于计算密集型任务（如信号处理）是相当重要的。

（6）数据设计。定义进程交换的信息以及协调信息交换的事件，并且设计相应的数据结构管理信息交换。几个并发进程可以共享这些数据结构。

（7）进程调度。设计调度系统确保进程及时开始，以满足它们的时限要求。

52. 3种经常使用的实时的体系结构模式如下。

（1）观察和反应。该模式用于当一组传感器周期性地监控和显示的时候。当传感器显示已经发生了某个事件时（如电话来电），作为反应系统会启动一个进程来处理此事件。

（2）环境控制。该模式用于某些系统，这些系统包括能提供环境信息的传感器和改变环境的执行器。根据传感器检测到的环境改变，控制信号被发送到系统的执行器。

（3）处理管道。该模式用于在数据被处理之前需要从一种表示变换到另一种表示的时候。变换实现为一系列可并行执行的处理步骤。由于单独的核或处理器可以执行每个变换，因此该模式允许非常快速的数据处理。

53．汽车刹车系统控制器中，设计的起始点是针对系统中的每种执行器类型给出一个模式实例。这里有4个执行器，每一个控制一个车轮上的制动。把单个传感器进程结合到一个监控所有车轮的车轮监控进程，该监控进程监视各个车轮上的传感器。传感器进程监控每个车轮状态，判断车轮是转动还是抱死。一个单独的进程监视驾驶员踩刹车踏板的压力。其防滑制动系统的控制系统体系结构。

54．当分析嵌入式实时系统的时序需求和设计系统满足这些需求的时候，要考虑3个主要因素：时限，频率，执行时间

55. 实时操作系统为实时系统管理进程和资源的分配。它启动和停止进程，使得能够处理激励并分配存储器和处理器资源给进程。实时操作系统的组件关系图。

56. 请描绘设计分布式系统中的中间件的组件关系图。

57. 两种不同类型的客户-服务器结构模型：

（1）瘦客户机模型。其表示层在客户机端实现，其他层（数据管理、应用处理和数据库）在服务器上实现。客户机软件可能是专门在客户机上编写的程序以处理表示。不过，更常见的情况是在客户机上使用Web浏览器来表示数据。

（2）胖客户机模型。一部分或者所有的应用处理都在客户机上执行。数据管理和数据库功能在服务器上实现。

58. 面向Web服务的体系结构的主要标准有：SOAP，WSDL，WS-BPDL

\59. 务接口设计有3个阶段：

（1）逻辑接口设计，找出与服务关联的操作、这些操作的输入和输出，以及与这些操作关联的异常。

（2）消息设计，设计由服务发送和接收的消息结构。

（3）WSDL开发，用WSDL语言将逻辑设计和消息设计翻译成抽象接口描述。

\60. 软件体系结构的评估方法主要有两种，即SAAM和ATAM。（软件架构分析，体系结构权衡分析）

61. 评估体系结构的整体复杂性，一种很有用的技术是考虑体系结构中构件间的依赖关系，这些依赖关系是由系统中的信息流或控制流驱动的。

三种类型的依赖是：1.共享依赖 2.流依赖 3.约束依赖