系统架构师（二）案例题

目录

一、软件结构设计

（一）软件质量属性

（二）风险，敏感点，权衡点

二、结构化软件系统建模

（一）流程图和数据流图

（二）实体和类的区别

（三）Essential Use Cases和Real Use Cases

（四）状态图和活动图

（五）用例建模

三、软件系统架构选择

（一）能写的架构风格-论文

（二）什么是软件架构风格，面向对象和控制环路两种架构各自风格的特点

（三）主程序-子程序 和 管道-过滤器 这两种架构风格的特点

（四）面向对象和基于规则

（五）管道过滤器和数据仓库

四、信息系统安全性

（一）信息系统面临的安全威胁

（二）安全认证

（三）授权侵犯

五、软件设计模式

（一）MVC

（二）Web系统架构设计

（三）什么是面向服务架构（SOA）以及ESB（企业服务总线）在SOA中的作用与特点

（四）系统安全保证措施

六、系统设计与开发工具集成

（一）ESB企业服务总线【2012之前】

（二）根据需求分析应该采用何种具体的集成方式或架构风格最为合适【2012之前】

（三）架构设计中的非功能需求

七、信息系统可靠性

（一）可靠度和失效率

（二）动态冗余和N版程序设计技术

（三）检错技术的优缺点，及其常见的实现方式和处理方式

八、Web应用系统架构设计

（一）什么是REST，并指出在REST中将哪三种关注点进行分离

（二）什么是响应式设计

（三）主从复制

（四）胖客户端和瘦客户端（相对概念）

（五）应用服务器

九、数据库

（一）分布式数据库缓存

（二）Memcache和Redis

（三）关系数据库和文件系统

（四）关系数据库和内存数据库

（五）持久层

（六）数据库程序在线访问.Net和ORM方式的优缺点

（七）什么是SQL注入，以及抵御SQL注入的方式？

（八）什么是数据库建模中的反规范化技术，优点和可能带来的问题

（九）常见的反规范化技术有哪些

十、设计模式

（一）工厂模式的优点和应用场景

（二）实现工具之间数据格式的灵活转换时，通常采用的设计模式是什么？

（二）Scrum敏捷开发过程

---

一、软件结构设计

（一）软件质量属性

1. 性能：系统响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理事件的个数
   1. 查询过程中涉及到的桥梁与公路的实时状态视频传输必须保证画面具有1024x768的分辨率，40帧/秒的速率;
2. 可用性：系统能够正常运行的时间比例
3. 可靠性：软件系统在应用或错误面前，在意外或者错误使用的情况下维持软件系统功能特性的基本能力
4. 健壮性：在处理或环境中，系统能够承受压力或变更的能力
5. 安全性：系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力
6. 可修改性：能够快速地以较高的性能价格比对系统进行变更的能力
   1. 系统要扩容时，应保证在10人·月内完成所有的部署与测试工作
   2. 更改系统的Web界面接口必须在4人周内完成
   3. 支持用户通过配置界面依据自己的喜好修改界面风格，包括颜色、布局、代码高亮方式等，配置完成后无需重启环境
7. 可变性：系统结构经扩充或变更成为新体系结构的能力
8. 易用性：衡量用户使用一个软件产品完成指定任务的难易程度
   1. 友好的用户界面
9. 可测试性：软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提条件下，进行测试设计、测试执行的能力
   1. 集成开发环境具有模块化结构，支持以模块为单位进行调试、测试与发布
10. 功能性：系统所能完成所期望工作的能力
11. 互操作性：系统与外界或系统与系统之间的相互作用能力

架构设计策略

1. 性能：增加计算资源、改善资源需求（减少计算复杂度等）、资源管理（并发、数据复制等）和资源调度（先进先出队列、优先级队列等）
2. 安全性：抵御攻击（授权、认证和访问限制等）、攻击检测（入侵检测等）、从攻击中恢复（部分可用性策略）和信息审计等
3. 可用性：Ping/Echo、心跳、异常和主动冗余等
4. 可修改性：软件模型泛化、限制模块之间通信、使用中介和延迟绑定等

（二）风险，敏感点，权衡点

• 风险：架构设计中潜在的、存在问题的架构决策所带来的隐患。
  • eg：如果“养护报告生成”业务逻辑的描述尚未达成共识，可能导致部分业务功能模块规则的矛盾，影响系统的可修改性
• 敏感点：为了实现某种特定的质量属性，一个或多个构件所具有的特性。
  • eg：对查询请求处理时间的要求（性能）将影响系统的数据传输协议和处理过程的设计；
• 权衡点：影响多个质量属性的特性，是多个质量属性的敏感点。
  • eg：更改系统加密的级别将对安全性和性能产生影响；

二、结构化软件系统建模

（一）流程图和数据流图

含义及其区别

数据流图：一种图形化工具，用来说明业务处理过程、系统边界内所包含的功能和系统中的数据流。

• 数据流:数据流是数据在系统内传播的路径，因此由一组成分固定的数据组成。
• 外部实体:代表系统之外的实体，可以是人、物或其他软件系统。
• 加工(处理) :加工是对数据进行处理的单元，它接收一定的数据输入， 对其进行处理，并产生输出。
• 数据存储:表示信息的静态存储，可以是文件、文件的一部分、数据库的元素等。

流程图：图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程，描述处理过程的控制流。

两者的区别主要包括：

1. 数据流图中的处理过程可并行；流程图在某个时间点只能处于一个处理过程
2. 数据流图展现系统的数据流；流程图展现系统的控制流
3. 数据流图展现全局的处理过程，过程之间遵循不同的计时标准；流程图中处理过程遵循一致的计时标准
4. 数据流图适用于系统分析中的逻辑建模阶段；流程图适用于系统设计中的物理建模阶段

数据流图存在的错误

1. “分类训练”加工：只有输入没有输出，产生数据黑洞
2. “分类处理"加工：有输出没有输入，无中生有
3. “规则文件"数据流：外部实体没有经过加工处理，直接到数据存储
4. “配置信息”数据流：外部实体之间没有加工处理，存在直接数据流

解析：数据流图中常见的错误分为两种类型：一类是语法错误 ，包括外部实体之间、数据存储之间或外部实体与数据存储之间不经过加工而存在直接数据流；另一类是逻辑错误，包括数据黑洞(只有输入没有产生输出)、灰洞 (输入不足以产生输出)和无输入。

以上的为0层和1层数据流图，画出0层数据流图

设计高质量的数据流图应考虑的三个原则

1. 复杂性最小化原则。DFD分层结构就是把信息划分为小的且相对独立的一大批子集例子，这样就可以单独考查每一个DFD。如果要了解某个过程更加详细的信息，可以跳转到该过程的下一层；如果要知道一个DFD如何与其他DFD相关联，可以跳转到上一层的DFD进行考查
2. 接口最小化原则。是复杂性最小化的一种具体规则。在设计模式时，应使得模型中各个元素之间的接数或连接数最小化
3. 数据流一致性原则。 一个过程和它的过程分解在数据流内容中是否有差别？是否存在有数据流出但没有相应的数据流入的加工？是否存在有数据流入但没有相应的数据流出的加工?

（二）实体和类的区别

实体用于数据建模，而类用于面向对象建模。实体只有属性，而类有属性和操作。

（三）Essential Use Cases和Real Use Cases

Essential Use Cases 可翻译为抽象用例，Real Use Cases 可翻译为基础用例。

他们是区别在于：

1. Essential Use Cases 用于分析阶段，Real Use Cases 用于设计阶段。
2. Essential Use Cases 描述用例的本质属性，它与如何实现这个用例无关，独立于实现该用例的软硬件技术。
3. Real Use Cases 描述的是用例的实现方式，表达了设计和实现该用例时所采用的方法和技术。

（四）状态图和活动图

状态图：描述一个对象在其生存期间的动态行为，表现一个对象所经历的状态序列，引起状态转移的事件（event），以及因状态转移而伴随的动作（action）。

活动图：描述系统的工作流程和并发行为，可看作状态图的特殊形式，活动图中一个活动结束后将立即进入下一个活动（在状态图中状态的转移可能需要事件的触发）。

两者最大的区别是：状态图侧重于描述行为的结果，而活动图侧重描述行为的动作。其次活动图可描述并发行为，而状态图不能。

（五）用例建模

用例参与者

指系统以外的，需要使用系统或与系统交互的事物，包括:人或组织、设备、外部系统等

如：每个月到了月底系统会通过打印机打印学生的考勤信息。参与者有：时间、打印机

用例之间的关系：包含、扩展、泛化

类之间的关系：关联、聚合、组合、依赖、泛化（继承）、实现（类与接口）

关联和依赖：一个类A用到了另一个类B，关联比比依赖关系强，必然的，长期的，强烈的

聚合和组合：整体和部分，聚合整体和部分可分离，组合整体和部分不可分离

三、软件系统架构选择

（一）能写的架构风格-论文

面向对象的架构风格：显式调用。构件是对象，对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和它们的相应操作被封装起来，对象的行为体现在其接受和请求的动作。连接件即是对象间交互的方式，对象是通过函数和过程的调用来交互的

层次结构风格（C/S，B/S，MVC）：构件组织成一个层次结构，连接件通过决定层间如何交互的协议来定义。每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。通过层次结构，可以将大的问题分解为若干个渐进的小问题逐步解决，可以隐藏问题的复杂度。修改某一层，最多影响其相邻的两层(通常只能影响上层)

进程通信：独立构件。构件是独立的过程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程(方法)调用等

事件驱动系统（消息中间件）：隐式调用。构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用来实现的。主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便；其缺点是构件放弃了对系统计算的控制

（二）什么是软件架构风格，面向对象和控制环路两种架构各自风格的特点

软件架构风格是描述某一类特定应用领域中软件系统组织方式的惯用方式。

面向对象架构风格：将数据表示和基本操作封装在对象中。这种模式的构件是对象，对象维护自身表示的完整性，对象之间通过消息机制进行通信，对象交互时需要知道彼此的标识，通过对象之间的协作完成计算过程。

控制环路架构风格：将过程输出的指定属性维护在一个特定的参考值 (设定点) 。控制环路风格包括过程变量、被控变量、 输入变量、操纵变量和设定点等构件，通过收集实际和理想的过程状态信息，并能调整过程变量使得实际状态趋于理想状态。

面向对象系统比较适合事件驱动的场景，特别是离散突发事件的处理；控制环路则适合连续事件的处理，比如恒定车速等

（三）主程序-子程序 和 管道-过滤器 这两种架构风格的特点

主程序-子程序架构风格中，所有的计算构件作为子程序协作工作，并由一个主程序顺序地调用这些子程序，构件通过共享存储区交换数据。

管道-过滤器架构风格中，每个构件都有一组输入和输出， 构件接受数据输入，经过内部处理，然后产生数据输出。这里的构件称为过滤器，构件之间的连接件称为数据流传输的管道。

	共享数据的主-子程序	管道-过滤器
算法变更	-	+
功能变更	-	+
数据表示变更	-	-
性能	+，程序处于紧耦合的状态	-

（四）面向对象和基于规则

	灵活性	可扩展性	性能
面向对象	将用户级别，折扣规则等封装为对象，在系统启动时加载	（2）加入新的用户级别和折扣规则时需要重新定义新的对象，并需要重启系统	（3）用户级别和折扣规则已经在系统内编码，可直接运行，性能较好。
基于规则