例1:
答案:C
例2:
答案:C
A:选项
B:选项这里的测试并不是真正的在代码中运行而是使用实例进行验证
C:选项,架构复审人员需要外部人员参与(用户人员和领域专家)
D:选项
例3:
答案:C(运行到断点的时候,相应事件触发)
例4:
答案:A(闭环控制结构不适合复杂任务)
例5:
答案:D
A:选项是一种软件架构评估方法
B:选项ATAM不需要评估软件的需求是否准确,只需要评估是否能够完成该需求
C:ATAM不需要对软件系统进行测试
D:ATAM针对场景进行评估,有主观成分和客观成分所以并不是一种精确的评估工具
例6:
答案:C,D(这里的部署视图对应下图的物理视图)
例7:
答案:A(对不到最佳的软件架构)
例8:
答案:B,C
例9:
答案:,A,C(优先选择惯用法,没有则选择设计模式)
例10:
答案:B(多种组合…)
例11:
答案:A,B
例12:
答案:C(没有使用中间件之前应用程序之间的关系类似于网状,使用中间件之后类似于变成了星型,这种方式降低了复杂度)
例13:
答案:D(非功能性需求)
例14:
答案:B,A,C,B,B,C
质量属性 | 设计策略 |
---|---|
性能 | 优先级队列,队列调度,资源调度,增加计算资源,减少计算开销,引入并发机制 |
可用性 | 冗余,心跳线,Ping/Echo,选举 |
安全性 | 追踪审计,限制访问 |
可修改性 | 信息隐藏,运行时注册,接口-实现分离,抽象 |
可靠性 | 冗余,心跳线 |
可测试性 | 记录/回放 |
例15:
答案:C
例16:
答案:A(规则系统就是虚拟机风格)
例17:
答案:C( 定义清洁任务,自定义环境,虚拟机风格 )
例18:
答案:C(语音识别系统是黑板的典型应用)
例19:
答案:C,D,B
例1:
答案:A(架构文档应该从使用者的角度进行编写)
例2:
答案:C,A
例3:
A,B,B
例4:
答案:B
例5:
答案:C( 实现这些构件不是软件架构设计阶段考虑的问题,而是构件实现过程需要考虑的问题 )
例6:
答案:C(该架构是数据流架构中的管道过滤器,数据流架构最大的问题就是和用户的交互问题 )
例7:
答案:A,D,C
例8:
答案:D
选项A:不需要对代码级别进行评估
选项B:架构评估不是去看这个需求是否正确
选项C:评估阶段不需要进行集成测试
选项D:根据相关质量属性,根据不同的偏重性进行选择
例9:
答案:A,C,D,B(随时保证…),C
例10:
答案:C(架构设计去实现需求,但是不会用来捕获或者验证需求 )
例11:
答案:B,C
例12:
答案:B,C
架构风格定义了用于描述系统的术语表和一组指导构建系统的规则, 反映了领域中众多系统所共有的结构和语义特性
,并指导如何将各个构件有效地组织成一个完整的系统。
例13:
答案:C,C,A,B,D,A
质量属性 | 设计策略 |
---|---|
性能 | 优先级队列,队列调度,资源调度 |
可用性 | 冗余,心跳线,Ping/Echo |
安全性 | 追踪审计,限制访问 |
可修改性 | 信息隐藏,运行时注册,接口-实现分离 |
可靠性 | 冗余,心跳线 |
可测试性 | 记录/回放 |
例14:
答案:D(系统的 性能
和 安全
产生影响,性能和安全这一对是一个平衡点),B
例15:
答案:C( 增加层次无法提高性能 )
例16:
答案:C
例17:
答案:B
例18:
答案:D
例19:
答案:B