【系统分析师之路】第七章 系统设计（软件架构设计）记忆敲出

1. 软件架构的概念

• 软件架构是连接软件需求和软件设计的桥梁，通过软件的结构就可以有效的把软件的各个需求通过设计分配到软件的各个模块中。

2. 五种软件架构的风格：

1. 数据流风格：批处理风格和管道过滤器风格
2. 虚拟机风格：解释器，基于规则的系统
3. 独立构件风格：事件系统，进程通信
4. 调用返回风格：面向对象风格，主程序子程序风格，层级架构风格
5. 仓库风格：黑板系统，超文本系统，数据库系统

3. 数据流风格的概念

• 批处理风格和管道过滤器风格是数据流风格的两个典型的代表。
• 批处理风格和管道过滤器相同之处是两者在处理过程中都是没有和用户有交互的，
• 批处理风格和管道过滤器不同之处是批处理风格更加强调一个完整地处理完了之后才可以进行下一个环节的处理。
• 编译器有词法分析，语法分析，语义分析等几个步骤，往往是一个步骤完了之后才可以执行下一个步骤，这个就是数据流风格的一个应用，当然编译器可能不光光使用批处理风格，虚拟器风格里面有解释器风格也可以应用于编译器之中。
• DOS里面的指令也是数据流风格的一个应用。
• 数据流风格相比于其他的架构风格，它更加强调的是处理的是按部就班的处理数据流，一个处理部件的输入是下一个处理部件的输出；在结构化图形中的数据流图比较适合描述数据流风格。

4. 独立构件风格概念

• 独立构件风格包括了进行通信和事件驱动系统两个。
• 独立构件风格不同于调用返回风格的显示调用，它是通过消息通信的方式完成信息的交换。进程之间的消息通信，远程过程调用，套接字异步消息通信等方式都属于独立构件的风格。因为独立构件是基于消息通信的，所以它是隐式调用。
• 事件驱动系统中，按一个按钮会触发什么事件往往是不明确的，但是一个事件的触发就导致了另一个模块中的过程调用。
• 独立构件最大的优点就是构件的维护和演化变得更加的方便了。构件之间的耦合度低，所以基于构件的开发模型就能够更好的运用。独立构件的缺点是构件放弃了对系统计算的控制。
• 独立构件风格和基于服务的架构SOA和EJB，WebServices应该有千丝万缕的联系。

5. 主程序子程序风格的概念

1. 面向对象架构风格
   这种风格的构件是对象。对象是抽象数据类型的实例。连接件即是对象间交互的方式。面向服务的开发模型是基于面向对象思想的，在我看来把面向对象解耦，功能封装之后，并改变原来对象之间直接的调用关系，于是就可以形成独立构建的架构。
2. 主程序/子程序架构风格
   不同于独立构件风格的隐式调用，主程序子程序都是显示的调用。它把问题划分为若干处理步骤进行。比如调用LIB或者动态链接库的IF函数的完成某一个功能的时候，这就是主程序子程序的一个应用场景。
3. 层次化架构风格
   层次结构的优点就是可以把一个大问题化繁为简地分解成一个个的小问题，然后逐步解决，这样在层次架构中就隐藏了问题的复杂性；在层次化的结构中，每一个层都是为了在自己之上的层次服务，如果修改了该层次的模块，也只会影响直接上下调用的其他模块。影响很小。层次化的优点就是化繁为简把大问题进行了有效的分解；
   但是在层次化的架构中，到底分几层才合适没有一个统一的定论和标准，分得层次越多效率越低。
   OSI七层模型，TCPIP协议簇四层模型，物联网三层模型，BS架构，CS架构都是层次化架构的应用。

6. 4+1架构风格

• 场景：用例视图
• 动态视图：逻辑视图和开发视图；
• 逻辑视图一般给最终用户看，确认系统的需求情况，记录系统中有哪些功能，在架构中也是逻辑视图
• 开发视图记录系统之间信息的交互过程，在架构中是实现视图。
• 静态模型：进程视图和物理视图；
• 进程视图描述系统的非功能需求，性能等内容，所以系统集成管理人员比较关心；在架构中也叫进程视图。
• 物理视图描述系统部署情况，比如网络拓扑，安装，所以系统工程人员比较关心；在架构中叫部署视图。

7. 架构的评估方法

• 信息系统主要的评估方式有三种：基于问卷调查和检查表的评估，基于场景的评估和基于度量的评估

1. 基于调查问卷或检查表的方式
   这种方式很大程度上依赖于评估人员的主观判断，尽管主管但却是目前使用率最高的方式，
   而检查表会比调查问卷问更加具体的问题，而且这种方式往往依赖于专家判断。
2. 基于场景的方式
   包括了ATAM架构权衡分析法和SAAM软件架构分析法,CBAM成本效益分析法三种方式。
   在体系结构中一般采用刺激（stimulus），环境（environment）和响应（response）三个方面来对场景进行描述。
3. 基于度量的方式
   代码的行数，构件个数，调用层次数等
4. 评估方式的特点比较
   从通用性方面看，问卷调查和度量比较通用
   只有度量的方式，需要在了解架构的前提之下才可以实施，也是最客观的架构评估方式，
   基于场景的评估方式也是比较主观的评估方式。

8. 虚拟机风格

• 构件一个平台，让其他功能能够运行在虚拟机之上。虚拟机屏蔽的操作系统的不同的内容，构件了一个让程序执行的统一的平台，也为跨平台的实现提供了技术支撑。在PC机上完FC游戏，玩GBA游戏都是虚拟平台的很好的应用。
• 解析器和基于规则的系统就是虚拟机风格的典型应用。J2EE和.NET框架中都采用了虚拟机风格。

9. 仓库风格

• 仓库系统的典型代表就是数据库系统，它是以数据为中心的架构风格。黑板系统也是和仓库系统有关系，它包括三部分：知识源，黑板和控制。黑板系统还可以解决编译器优化的问题（通过一个集成的编译平台），黑板系统是以知识源为核心。

10. C/S架构

• 分为两层CS架构和三层CS架构，传统的两层CS架构分为数据层和表示层。数据层是服务器，表示层是客户端。两层CS架构是一种重客户端轻服务器的框架，因为它主要的业务逻辑和功能表示都在客户端完成，这样带来的一个问题就是更新变得困难，客户端需要更新时，往往所有的安装的客户端都同步需要更新才可以，而且有的客户端在Mac，有的在Windows的话，都需要分别的更新，成本高那是肯定的了。除去不同客户端表示差异的问题，随着客户端的升级，客户端会越来越重，越来越复杂和不易维护。两层CS架构还有新技术不容易使用和导入等缺点。正因为两层结构有这样那样的缺点，所以3层CS架构呼之欲出。
• 三层CS架构在两层的基础上多出了一个功能层，简单可以理解为它将两层CS架构中的客户端，独立出其中的业务逻辑，也就是说是功能层，仅仅只将页面表示放在客户端。所以三层CS架构也叫做瘦客户端架构。三层架构使各层逻辑之间相对的独立，提高了整个系统的可扩展性可维护性和可靠性，而且各层可以使用不同的开发语言增加了灵活性。各层之间职责相互的独立，各司其职，也为安全性设计提供了有效的前提条件。
• 三层架构中，数据层也就是服务器部署在一台PC中，业务逻辑功能层和表示层可以部署在一台应用服务器中，也可以分开部署。三层架构中各个层次之间通信效率肯定不如两层CS架构。但是三层CS架构没有得到很好的应用，因为三层CS架构生不逢时，在它出来后不久就有了三层BS的架构。

11. 三层B/S架构

• 这个架构最大的特点也是最大的优点就是零客户端，也就是不需要安装客户端。这样在部署升级系统的时候就变得更加简单了。CS架构的不足之处也得到了很好的解决。BS架构有一个Web服务器来处理功能和实现页面表示，和CS架构一样的是都有数据层。当然BS架构的缺陷也是十分突出。首先它的交互性不如CS架构，所以后来才有了Ajax异步传输技术的补充和发展，它的安全性不高，所以需要https协议的配合；页面的动态表现力不如CS架构，什么Flash很难实现；由于BS架构大多数计算处理都集中到了Web服务器，而CS架构在客户端可以处理，所以BS架构的速度不如CS架构快（响应速度）那也是合情合理的；哪怕是局部变动，提交页面也往往是一整个页面，交互性不好。

12. 混合架构

• 正因B/S架构和C/S架构各有优缺点，于是就有了混合架构的概念。混合架构就是综合了两个架构之间的优点。他有两个应用，一个是内外有别，一个是查改有别。
• 内外有别就是对内网使用CS架构，对外使用BS架构，这样对外网用户就不用更新安装下载客户端了，对内使用CS架构，维护升级查询处理都比BS架构好一个数量级。
• 还有一种查改有别就是简单的交互比如查找信息使用BS架构，而复杂的交互使用CS架构保证速度，这两个混合模式都是两个架构取长补短的应用。

13. 富互联网技术

• 他最大的特点就是弥补了B/S架构中交互性不强的问题，它里面包括了Ajax技术和Flex技术。Ajax是异步的javascript和xml，比如我们输入用户名的时候，在没有刷新页面的前提下就提示我们该用户名已经注册了，这就是阿贾克斯技术的一个应用；而Flex技术更多的应用在网络游戏中，在网游中炫酷的画面就是富互联网的应用。提高了人机界面交互的能力，这个知识点可以和人机界面设计结合在一起。RIA技术已经可以将数据缓存在客户端了，这样就减少了数据往返的次数。

14. SOA基于服务的架构

• SOA最大的特点有三个：高度标准化的接口，松散耦合，粗粒度；从小到大分别是对象，构件和服务。可以看到构件是对一系列对象的封装与整合，像VB.NET语言中的控件库就是构件技术的应用；再对一系列的这种控件有机结合在一起，就构成了服务。构件的标准是多种多样的，有COM，EJB，有COM+。正因为构件的多样化，才有了服务存在的价值。
• 服务都是基于XML，相关协议也是基于XML发展而来的。服务是把所有使用到的东西高度标准化的过程。
  ESB和WebServices是基于服务的架构最为经典的应用。

15. Webservice

• 在Webservice中有三个角色：服务请求者，服务提供者，服务注册中心。它是SOA的实现方式。三者当中，服务注册中心是可有可无的，他记录了服务请求者和提供者之间的映射关系。服务请求者和提供者之间有一个绑定的过程，而绑定又可以分为静态和动态两种。静态绑定就不需要使用到注册中心了，而动态绑定需要先通过查找找到服务的提供者，再与服务的提供者建立绑定关系。

16. ESB

• 企业应用总线在我的理解中，更像是企业应用集成中的逻辑集成。更像是一个超级中间件，它将各个封装的服务进行集成，以提供给Web应用和MIS应用。使用了ESB，我们就可以忽略每个子系统的物理位置，它还支持多种数据之间的格式转换，在企业总线上布下日志功能，就能监控总线上所有通信内容，提高了安全性。在企业中建立ESB，可以有效解决信息孤岛的问题。
• ESB和Webservice有什么不同，他们的应用场景不同，Webservice是把服务在因特网中封装成一个个高度标准统一的服务，而ESB更加侧重于企业的应用，将企业的子系统以服务的形式一个个挂接到服务器上，把各个服务给连接起来。

17. 中间件

• 中间件是一种独立的软件或服务程序，它可以应用在分布式系统中，在各个不同的技术软件之间共享资源，中间件可以理解为SOA架构中的构件，在企业应用集成中，有逻辑集成，使用中间件在不同的子系统之间实现通信，将原本信息孤岛的系统连接起来，这个就是中间件的一个应用。中间件也可以简单理解为翻译者，使用中间件就可以实现遗留系统的可重用。
• 中间件有消息中间件，有数据库中间件，还有远程过程调用中间件，还有业务型的中间件。
• 在负载均衡技术中，有使用软件实现负载均衡算法的应用，这个也是中间件技术的一个应用。
• 中间件技术的实现依赖于构件之间的通信，中间件可以实现分部在两台不同PC上的机器可以相互的进行消息转化后的通信，也核实中间件技术最重要的优势。
• 企业应用总线ESB中的总线可以理解为一个中间件，各种层次架构（比如CS架构等）的分布式实现也需要通过中间件技术实现。在虚拟机风格中跨平台的实现，也是中间件的一种应用。

18 .NET和J2EE

• 它的最底层是通用语言运行环境，通用语言运行环境说白了就是一个虚拟机风格。他借鉴了J2EE架构。它可以支持多个开发语言，这些开发语言会被翻译成通用语言规范。通用语言运行规范运行在CLR之上。.NET体系中其实就有虚拟机了，CLR就是.NET平台的虚拟机。虚拟机包括有ASP.NET它是用在Windows应用中，ADO.NET是用来做数据库操作的。.NET中的基础类库是一种复用的机制。
• NET架构虽然支持的开发语言多，但它的移植性不如J2EE，因为NET是微软公司的产品，所以NET平台目前只能应用在微软的操作系统之上。在其他场合J2EE和.NET框架是大同小异的。
• 而J2EE分为四个层次，最底层是企业信息层，其次是业务逻辑层，上两层是Web层和应用层。JVM是J2EE下的虚拟机，企业Bean和会话Bean等都是运行在业务层。
• EJB (Enterprise Java Beans) 是基于分布式事务处理的企业级应用程序的组件。
  EJB容器可以接受三类EJB：实体Bean（Entity Beans），会话Beans（Session Beans），消息驱动Bean（Message Driven Beans ，MDBs）。而会话Beans又可以分为两种：一种是无状态会话Bean（Stateless Session Beans），另一种是有状态会话Bean（Stateful Session Beans）。

19 .MVC和MVP

• MVC是一种设计模式也是一种架构模式，MVC是Model-View-Control的缩写。MVC模式其实类似于之前的分层模式，
• 它将业务逻辑分成了三个层次，每个层次分别执行不同的分工，Model偏向数据处理层，View偏向页面表示。
  MVC模式呢也可以分为两种，一种是主动MVC,另一种是被动MVC，主动MVC种加入了观察者模式，View会定期确认Model的情况；如果发现数据有更新了，那么就更新表示，比如常用的股市软件就是主动MVC模式的应用；而被动MVC则正好相反，被动MVC只有在Model更新了之后，不通知视图View让视图手动去Model中取内容。
• 在MVC模式之后，出现了MVP模式。MVP模式是在MVC模式的基础上进行了优化和改良，MVP最大的改进就是进一步把Model-View之间进行了解耦，Model-View之间没有了直接的消息通信与联系，所有的消息通信都需要经过P层，P就是Presenter的缩写，Presenter在MVP模型中更像是业务逻辑层，所有的Model-View直接的通信都需要经过Presenter层。
• MVP解耦更加地彻底，也就更容易实施单体测试；MVP中的V要处理界面事件，业务逻辑在P中，MVC模型中界面事件由C处理。Presenter中既有业务逻辑也有同步逻辑。同步逻辑保证Model-View之间的信息可以同步更新。
• MVP有什么缺点呢？因为在MVP的Presenter中，除了业务逻辑以外，还有很多View-Model的通信逻辑和同步逻辑，所以在有解耦易测试的优点的同时，Presenter层会变得比较庞大和沉重。

20 .质量属性

• 质量属性包括了：性能，可靠性，可用性，安全性，可修改（维护）性，互操作性，功能性，可变性等一系列属性所组成。

1. 性能：比如吞吐量，页面响应速度就是性能属性。
2. 可靠性和可用性：在软件架构中一般我们只提可用性而不是可靠性，在系统性能与评价章节中，可用性是指系统可以正常使用时间和出现故障不可以使用时间的比率，可靠性突出的是在某段时间内出现故障的次数。
3. 安全性：安全性方面信息系统可以分为完整性，不可抵赖性，保密性和可控性四个方面。
4. 可修改性：信息系统需要修改，需要维护的时候，容易不容易维护就是修改性的体现，在这里与其说是可修改性，倒不如说是可维护性来得切合实际把。
5. 互操作性：信息系统往往难以独善其身，它与其他系统之间如何进行交互
6. 功能性：信息系统能够完成期望功能的程度。
7. 可变性：它比可修改性高一个层次，精确的说，可变性应该理解为系统的可扩展性。在软件产品线中，可变性十分之重要，因为在软件产品线。

21 .ATAM和SAAM架构评估方法

• 架构权衡分析法（ATAM），软件架构分析法（SAAM），成本效益分析法（CBAM）都是基于场景的架构评估方法。说到场景，它出现在4+1视图的中间位置，它使用用例视图来展现，场景是系统重要的活动的抽象。
• SAAM软件架构评估方法：这种方法相比ATAM方法来得简单的多，这种方法类似于软件的测试，软件测试一般先实施单个模块的测试，再实施集成模块的测试；在SAAM中，首先要建立场景，然后描述信息系统的架构，建立好的场景先实施优先级的分级，先是单个评估，然后组合在一起实施评估，最后形成对于总体的评价。
• SAAM的特点就是比较简单，花在培训上的成本比较少。
• ATAM架构权衡分析法：ATAM不仅仅是开发人员，用户方代表，首席架构师都要参与其中，ATAM方法还有投票环节。如果有15票，你可以将票分别投给你认为重要的各个场景，也可以将所有的票都投给一个场景。