体系结构（双语）期末复习题

软件体系结构（双语）概念题

原书：软件工程：实践者的研究方法（第七版）机械工业出版社

• _P175由需求模型：基于场景的元素、基于类的元素和行为元素 是确定设计任务的输出
  

• 使用设计表示法和设计方法的到数据或类的设计、体系结构设计、接口设计、构件设计

• _P178质量属性：FURPS：

  • 功能性（Functionality) /通过评估程序特征的能力、所提交功能的通用性以及整个系统的安全性来评估
  • 易用性(Usability) / 考虑人员因素、整体美感、一致性和文档来评估
  • 可靠性（Reliability)/测量故障的频率和严重性、输出结果的精确性、平均故障时间、故障恢复能力和程序的可预见性来评估
  • 性能（performance)/考虑处理速度、相应时间、资源消耗、吞吐量和效率来度量
  • 可支持性（supportability)/综合了扩展程序的能力（可扩展性）、适应性和耐用性这3方面的能力（这3个属性体现了一个更通用的术语：可维护性）此外还包括可测试性、兼容性、可配置型（组织和控制软件配置元素的能力）、系统安装的简易性和问题定位的容易醒。
  • 规则：软件设计时，每个质量属性权重并不一样，哪点强调，哪点就突出

• _P185 well-formed design class four ①完整性与充分性：设计类应该完整地封装所有可以合理预见的（根据类名的理解）存在于类中的属性和方法。②原始性： 和一个设计类相关的方法应该关注与实现类的某一个服务。 ③高类聚性： 一个内聚的设计类具有最小的、集中的自责集合、并且专注于使用属性和方法来实现那些自责。④低耦合性： 在设计模式内，设计类之间相互协作是必然的。

• _P185 设计类可以

  • 通过提供设计细节精化分析类。设计细节将促成类的实现

  • 实现支持业务解决方案的软件基础设施。

• _P195体系结构定义：程序或计算系统的软件体系结构是指系统的一个或多个结构，它包括软件构件、构件的外部可见属性以及他们之间的相互关系。

• 五种不同类型设计类：

  1. 用户接口类，定义人机交互（Human-Computer-Interaction，HCI）所必须的所有抽象，并且经常在隐喻的环境实施HCI；
  2. 业务域类：识别实现某类，实现完整某些业务域元素所必须的属性和服务（方法），通过一个域或更多的分析进行定义
  3. 过程类： 实现完整地管理业务域所必须的底层业务抽象
  4. 持久类： 用于表示将在软件执行之外持续存在的数据存储
  5. 系统类： 实现软件管理和控制功能，使得系统能够运行，并且其计算环境与外界通信。

• 体系结构类型（architectural genres） 人工智能、通信、设备、金融、游戏、工业、法律、医疗、军事、操作系统、运输、应用程序

• 体系结构风格分类：

  • 以数据为中心的体系结构
  • 数据流体系结构
  • 调用和返回体系结构
  • 面向对象体系结构
  • 层次体系结构

• 体系结构权衡分析法（Architecture Trade-off Analysis）迭代评估：iterative

  1. 收集场景
  2. 引出需求、约束和环境描述
  3. 描述已被选择用于解决场景和需求的体系结构风格或模式
  • 体系结构视图描述

  • 模块视图用于分析带有构建的工作任务以及信息隐蔽的程度

  • 过程视图用于分析系统性能

  • 数据流视图用于分析体系结构满足功能需求的程度

    4. 通过单独考虑某个属性来评估质量属性：Quality attributes for architecture design assessment include : reliability performance security maintainability flexibility testability portability re-usability interoperability

  • 5针对特定的体系结构风格确定质量属性对各种体系结构属性的敏感性

  • 6使用第五步进行的敏感性分析来鉴定候选体系结构

• 从信息流（DFD）到程序结构的转换步骤：

  1. 建立信息流类型
  2. 标准流的边界
  3. 将DFD映射到程序结构
  4. 定义控制层级
  5. 使用设计度量和程序范式精化产生的结构
  6. 求精并细化体系结构描述

• 面向对象系统：topical task set for component-level design seven step

  • 标示出所有与问题域相对应的设计类
  • 确定所有基础设施域相对应的设计类
  • 细化所不需要作为复用构建的设计类
    1. 为每个构建确定适当的接口
    2. 在类或构建协作时说明消息的细节
    3. 细化属性，并且定义实现属性所需要的数据类型和数据结构
    4. 详细描述每个操作中的处理流
  • 说明持久数据源（数据库和文件）并确定管理数据源所需要的类
  • 开发并细化类或构建的行为表示
  • 细化部署图以提供额外的实现细节
  • 考虑每个构建设计表示，并且时刻考虑其他可选方案

• domain analysis： 域分析：

  • 定义待研究的领域
  • 把从领域提取的项进行分类
  • 收集域中有代表性的应用系统样本
  • 分析样本中的每个应用系统，并定义分析类
  • 为这些类开发需求模型

  领域分析使用于任何软件工程范式（传统软件开发、面向对象的软件开发等）

• Golden Rules

  1. place the user in control

     允许用户操纵控制：

     • 以不强迫用户进入不必要或不希望的动作方式来定义交互模式
     • 提供灵活的交互
     • 允许用户交互被中断或撤销
     • 当技能级别增长时可以交互流线化并允许定制交互
     • 使用用户内部技术细节隔离开来
     • 设计应允许用户与出现在屏幕上的对象相互交互

  2. Reduce the user’s memory load

  3. make the interface consistent

• 任务分析和建模The goal of task analysis:

  • 在指定环境下用户将完成什么工作
  • 当用户工作时，将完成什么任务和子任务
  • 在工作中用户待处理什么特殊的问题域对象
  • 工作任务的顺序（工作流）如何？
  • 任务的层次关系如何？

  use case(用例) Task elaboration(细化) work flow analysis(工作流分析) Hierarchical representation（层次表示）

• 基于模式的体系结构评审(Patten-Based Architecture Review,PBAR)是涉及所有开发人者和其他有兴趣的利益相关者的面对面的审计会议。包含以下迭代过程：

1. 遍历相关的用例，以确定并讨论系统最重要的质量属性。
2. 结合需求讨论系统体系结构图。
3. 协助审评人员识别所使用的体系结构模式，并将系统结构与模式结构相匹配。
4. 使用现有的文档和过往用例，检查体系结构和质量属性，以确定每一种模式对系统质量属性的影响。
5. 识别并讨论由设计中使用的体系结构模式所引起的质量问题。
6. 针对会议上出现的问题做一个简短的汇总，并对可运行的系统骨架进行相应的修正。

• PBAR非常适用于小规模敏捷团队，只需要相对较少的额外项目时间和精力，只需要很短的准备及评审时间，PBAR就能够适应不断变更的需求和较短的建设周期，同时，也有助于团队理解系统体系结构。
• 四种适用于于构件级的基本设计原则
  • 开闭原则(The Open-Closed Principe,OCP)：对扩展开放，对修改关闭
  • 里氏替换原则(Liskov Substitution Principle,LSP)：子类可以替换他们的基类;
  • 依赖倒置原则(Dependency Inversion Principle,DIP)：针对接口编程，而不是针对实现编程
  • 接口分离原则(Interface Segregation Principle,ISP)：不要统一用一个大的接口，要用一些专一的接口同一类的事