架构设计师知识点笔记2018

软件架构风格描述某一特定领域中的系统组织方式和惯用模式，反映了领域中众多系统所共有的结构和语义特征。用户界面设计的基本原则是从实践中总结出来的一些设计规则。Theo Maiidel在他的界面设计著作中提出3条“黄金规则”： 让用户拥有控制权 减少用户的记忆负担 保持界面一致IETF集成服务（IntServ)工作组根据服务质量的不同，把Internet服务分成了三种类型：保证质量的服务（Guranteed Services)：对带宽、时延、抖动和丢包率提供定量的保证；负载受控的服务（Comrolled-load Services)：提供一种类似于网络欠载情况下的服务，这是一种定性的指标；尽力而为的服务（Best-Effort)：这是Internet提供的一般服务，基本上无任何质量保证。在大多数情况下，为测试新系统的性能，用户必须依靠评价程序来评价机器的性能。对于真实程序、核心程序、小型基准程序和合成基准程序来说，其评测程度依次递减。把应用程序中用的最多、最频繁的那部分核心程序作为评价计算机性能的标准程序，称为基准测试程序（Benchmark)（1）数据流风格：批处理序列；管道/过滤器。 （2）调用/返回风格：主程序/子程序；面向对象风格；层次结构。 （3）独立构件风格：进程通信；事件系统。 （4）虚拟机风格：解释器；基于规则的系统。 （5）仓库风格：数据库系统；超文本系统；黑板系统。二、设计模式的六大原则1.开闭原则（Open Close Principle）开闭原则就是说对扩展开放，对修改关闭。在程序需要进行扩展的时候，不能去修改原有代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会体会到这点2.里氏代换原则（Liskov Substitution Principle）LSP3.依赖倒转原则（Dependence Inversion Principle）4.接口隔离原则（Interface Segregation Principle）5.迪米特法则（最少知道原则）（Demeter Principle）6.合成复用原则（Composite Reuse Principle）原则是尽量使用合成、聚合的方式，而不是使用继承。UML的五种视图：5种视图分别描述系统的一个方面，5种视图组合成UML语言完整的模型。用例视图 用户 描述系统应具备的功能。逻辑视图 设计人员和开发人员 描述用例视图中提出的系统功能的实现。组件视图 开发人员 显示代码组件的组织结构。配置视图 开发人员、系统集成人员、测试人员 显示系统的具体部署。部署是指将系统配置到由计算机和设备组成的物理结构上。并发视图 开发人员、系统集成人员 显示系统的并发性，解决在并发系统中存在的通信和同步问题。UML的九种图：1.用例图（use case diagrams）2.静态图（1）类图（class diagrams）（2）对象图（object diagrams）3.交互图（1）序列图（顺序图）（2）协作图（Collaboration diagrams）4.行为图： 描述系统的动态模型和对象之间的交互关系。（1）状态图（Statechart diagrams）（2）活动图（Activity diagrams）5.实现图（1）构件图（Component diagrams）（2）部署图（Deployment diagrams）创建型模式，就是创建对象的模式，抽象了实例化的过程。它帮助一个系统独立于如何创建、组合和表示它的那些对象。关注的是对象的创建，创建型模式将创建对象的过程进行了抽象，也可以理解为将创建对象的过程进行了封装，作为客户程序仅仅需要去使用对象，而不再关心创建对象过程中的逻辑。结构型模式的作用是解决怎样组装现有的类，设计他们的交互方式，从而达到实现一定的功能的目的。结构型模式包含了对很多问题的解决。例如：扩展性(外观、组成、代理、装饰)封装性(适配器，桥接)。行为型模式涉及到算法和对象间职责的分配，行为模式描述了对象和类的模式，以及它们之间的通信模式，行为型模式刻画了在程序运行时难以跟踪的复杂的控制流。说明什么是数据库建模中的反规范化技术，指出采用反规范化技术能获得哪些益处，可能带来哪些问题。规范化设计后，数据库设计者希望牺牲部分规范化来提高性能，这种从规范化设计的回退方法称为反规范化技术。采用反规范化技术的益处：降低连接操作的需求、降低外码和索引的数目，还可能减少表的数目，能够提高查询效率。可能带来的问题：数据的重复存储，浪费了磁盘空间；可能出现数据的完整性问题，为了保障数据的一致性，增加了数据维护的复杂性，会降低修改速度。（1）增加冗余列：在多个表中保留相同的列，通过增加数据冗余减少或避免查询时的连接操作。（2）增加派生列：在表中增加可以由本表或其它表中数据计算生成的列，减少查询时的连接操作并避免计算或使用集合函数。（3）重新组表：如果许多用户需要查看两个表连接出来的结果数据，则把这两个表重新组成一个表来减少连接而提高性能。（4）水平分割表：根据一列或多列数据的值，把数据放到多个独立的表中，主要用于表数据规模很大、表中数据相对独立或数据需要存放到多个介质上时使用。（5）垂直分割表：对表进行分割，将主键与部分列放到一个表中，主键与其它列放到另一个表中，在查询时减少I/O次数。逻辑视图：主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。逻辑视图。逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。进程视图：侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。进程视图。进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。开发视图：也称为模块视图，主要侧重于软件模块的组织和管理。物理视图：主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。部署视图。部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。场景：可以看作是那些重要系统活动的抽象，它使四个视图有机地联系起来，从某种意义上说，场景是最重要的需求抽象。逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。实体类映射需求中的每个实体，实体类保存需要存储在永久存储体中的信息。控制类用于对一个或几个用例所特有的控制行为进行建模，控制对象通常控制其他对象，因此它们的行为具有协调性。边界类用于封装在用例内、外流动的信息或数据流。边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。结构化分析方法的基本思想是自顶向下，逐层分解，把一个大问题分解成若干个小问题，每个小问题再分解成若干个更小的问题。经过逐层分解，每个最低层的问题都是足够简单、容易解决的。结构化方法分析模型的核心是数据字典，围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型(也称为状态模型)。在实际工作中，一般使用E-R图表示数据模型，用DFD表示功能模型，用状态转换图表示行为模型。这三个模型有着密切的关系，它们的建立不具有严格的时序性，而是一个迭代的过程基于软件架构的开发(Architecture Based Software Development，ABSD)强调由商业、质量和功能需求的组合驱动软件架构设计。它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求面向对象的分析模型主要由顶层架构图、用例与用例图和领域概念模型构成设计模型则包含以包图表示的软件体系机构图、以交互图表示的用例实现图、完整精确的类图、描述复杂对象的状态图和用以描述流程化处理过程的活动图等状态图：用来描述一个特定对象的所有可能状态以及其引起状态转移的事件。活动图：用来描述操作的行为，也用于描述用例和对象内部的工作过程。两者有本质区别：状态图和活动图用于不同的目的，状态图着重描述一系列的状态及状态间的转移，状态间的变迁需要外部事件的触发。活动图用于捕获动作及动作的结果，活动图中一个活动结束将立即进入下一个活动，是内部处理驱动的流程。MVC架构风格最初是Smalltalk-80中用来构建用户界面时采用的架构设计风格。其中M代表模型(Model)，V代表视图(View)，C代表控制器(Controller)。在该风格中，模型表示待展示的对象，视图表示模型的展示，并能接收用户的输入数据，但是它不进行任何实际业务处理，控制器负责把用户的动作转成针对模型的操作。模型通过更新视图的数据来反映自身的变化。EJB中Bean分这三种类型：Session Bean, Entity Bean, Message-Driven Bean.Session Bean的职责：维护一个短暂会话，当客户端执行完成后，Session Bean和它的数据会消失。Entity Bean的职责：维护一行持久稳固的数据，如果客户端终止或者服务结束，底层的服务会负责entity Bean数据的存储。Message-Driven Bean的职责：结合了Session Bean 和JMS，允许异步接收消息。在EJB里面，会话Bean分为两种，一种是有状态的会话Bean，另一种是无状态的会话Bean，本节主要讲解一下两者之间的区别。对于有状态的会话Bean，这种情况属于，服务端与你单独开辟了一块空间与你进行交互。而客户端感觉服务端单独为他自己服务似的。而无状态的会话Bean，则服务端不提供了一个资源但是谁用都行，他不负责。所以客户端在使用的时候，则会感到这个服务 与其他人共享似的。1.有状态会话bean ：每个用户有自己特有的一个实例，在用户的生存期内，bean保持了用户的信息，即“有状态”；一旦用户灭亡（调用结束或实例结束），bean的生命期也告结束。即每个用户最初都会得到一个初始的bean。 2.无状态会话bean ：bean一旦实例化就被加进会话池中，各个用户都可以共用。即使用户已经消亡，bean 的生命期也不一定结束，它可能依然存在于会话池中，供其他用户调用。由于没有特定的用户，那么也就不能保持某一用户的状态，所以叫无状态bean。但无状态会话bean 并非没有状态，如果它有自己的属性（变量），那么这些变量就会受到所有调用它的用户的影响，这是在实际应用中必须注意的（1）概念模式。概念模式（模式、逻辑模式）是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。一个数据库只有一个概念模式 数据库系统概念模式通常还包含有访问控制、保密定义、完整性检查等方面的内容，以及概念/物理之间的映射。（2）外模式。外模式（子模式、用户模式）用以描述用户看到或使用的那部分数据的逻辑结构，用户根据外模式用数据操作语句或应用程序去操作数据库中的数据。外模式主要描述组成用户视图的各个记录的组成、相互关系、数据项的特征、数据的安全性和完整性约束条件。（3）内模式。内模式是数据物理结构和存储方式的描述，是数据在数据库内部的表示方式。一个数据库只有一个内模式。内模式定义的是存储记录的类型、存储域的表示以及存储记录的物理顺序，指引元、索引和存储路径等数据的存储组织。SOA 是一种应用程序架构，在这种架构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程。SOA 是一种 C/S 架构的软件设计方法，应用由服务和服务使用者组成，SOA 与大多数通用的 C/S 架构模型不同之处，在于它着重强调构件的松散耦合，并使用独立的标准接口。在 SOA 模型中，所有的功能都定义成了独立的服务。服务之间通过交互和协调完成业务的整体逻辑。所有的服务通过服务总线或流程管理器来连接。这种松散耦合的架构使得各服务在交互过程中无需考虑双方的内部实现细节，以及部署在什么平台上在采用 Web Service 作为 SOA 的实现技术时，应用系统大致可以分为六个层次，分别是底层传输层、服务通信协议层、服务描述层、 服务层、业务流程层和服务注册层。 （1）底层传输层。底层传输层主要负责消息的传输机制，HTTP、JMS（Java Messaging Service，Java 消息服务）和 SMTP 都可以作为服务的消息传输协议，其中 HTTP 使用最广。 （2）服务通信协议层。服务通信协议层的主要功能是描述并定义服务之间进行消息传递所需的技术标准，常用的标准是 SOAP 和 REST 协议。 （3）服务描述层。服务描述层主要以一种统一的方式描述服务的接口与消息交换方式，相关的标准是 WSDL。 （4）服务层。服务层的主要功能是将遗留系统进行包装，并通过发布的 WSDL 接口描述被定位和调用。 （5）业务流程层。业务流程层的主要功能是支持服务发现，服务调用和点到点的服务调用，并将业务流程从服务的底层调用抽象出来。（6）服务注册层的主要功能是使服务提供者能够通过 WSDL 发布服务定义，并支持服务请求者查找所需的服务信息。相关的标准是 UDDI。在一个复杂的企业计算环境中，如果服务提供者和服务请求者之间采用直接的端到端的交互，那么随着企业信息系统的增加和复杂度的提高，系统之间的关联会逐渐变得非常复杂，形成一个网状结构，这将带来昂贵的系统维护费用，同时也使得 IT 基础设施的复用变得困难重重。ESB 提供了一种基础设施，消除了服务请求者与服务提供者之间的直接连接，使得服务请求者与服务提供者之间进一步解耦。ESB 是由中间件技术实现并支持 SOA的一组基础架构，是传统中间件技术与 XML、 Web Service 等技术结合的产物，是在整个企业集成架构下的面向服务的企业应用集成机制。具体来说，ESB 具有以下功能： （1）支持异构环境中的服务、消息和基于事件的交互，并且具有适当的服务级别和可管理性。 （2）通过使用 ESB，可以在几乎不更改代码的情况下，以一种无缝的非侵入方式使现有系统具有全新的服务接口，并能够在部署环境中支持任何标准。 （3）充当缓冲器的 ESB（负责在诸多服务之间转换业务逻辑和数据格式）与服务逻辑相分离，从而使不同的系统可以同时使用同一个服务，不用在系统或数据发生变化时，改动服务代码。 （4）在更高的层次，ESB 还提供诸如服务代理和协议转换等功能。允许在多种形式下通过像 HTTP、SOAP 和 JMS 总线的多种传输方式，主要是以网络服务的形式，为发表、注册、发现和使用企业服务或界面提供基础设施。 （5）提供可配置的消息转换翻译机制和基于消息内容的消息路由服务，传输消息到不同的目的地。 （6）提供安全和拥有者机制，以保证消息和服务使用的认证、授权和完整性。系统架构风险是指架构设计中潜在的、存在问题的架构决策所带来的隐患。敏感点是为了实现某种特定质量属性，一个或多个系统组件所具有的特性。权衡点是影响多个质量属性，并对多个质量属性来说都是敏感点的系统属性。JRP是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发（JAD)的-部分。JRP的主要意图是收集需求，而不是对需求进行分析和验证。实施JRP时应把握以下主要原则：在JRP实施之前，应制定详细的议程，并严格遵照议程进行；按照既定的时间安排进行；尽量完整地记录会议期间的内容；在讨论期间尽量避免使用专业术语；充分运用解决冲突的技能；会议期间应设置充分的间歇时间；鼓励团队取得-致意见；保证参加JRP的所有人员能够遵守实现约定的规则。结构化分析方法的基本思想是自顶向下，逐层分解，把一个大问题分解成若干个小问题，每个小问题再分解成若干个更小的问题。经过逐层分解，每个最低层的问题都是足够简单、容易解决的。结构化方法分析模型的核心是数据字典，围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型（也称为状态模型）。在实际工作中，一般使用E-R图表示数据模型，用DFD表示功能模型，用状态转换图表示行为模型。这三个模型有着密切的关系，它们的建立不具有严格的时序性，而是一个迭代的过程。逻辑视图。逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。进程视图。进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模。部署视图。部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。 用例视图。用例视图是最基本的需求分析模型。软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。软件架构设计能够满足系统的性能、安全性、可维护性等品质；软件架构设计能够帮助项目干系人（Stakeholder)更好地理解软件结构：软件架构设计能够有效地管理系统的复杂性，并降低系统维护费用；软件架构设计对系统开发具有指导性：软件架构设计为系统复用奠定的基础；软件架构设计能够支持冲突分析。需要注意的是，软件架构设计与系统需求是直交的，两者并无必然联系。架构权衡分析方法是一种系统架构评估方法，主要在系统开发之前，针对性能、可用性、安全性和可修改性等质量属性进行评价和折中。ATAM可以分为4个主要的活动阶段，包括需求收集、架构视图描述、属性模型构造和分析、架构决策与折中，整个评估过程强调以属性作为架构评估的核心概念。题目中提到“某软件公司采用ATAM进行软件架构评估，在评估过程中识别出了多个关于质量属性的描述。其中，系统在进行文件保存操作时，应该与Windows系统的操作方式保持一致。”与用户所熟悉的操作方式，操作界面保持一致，这是一种减轻用户记忆负担，降低学习成本的做法，这有利于提高系统的易用性。“系统应该提供一个开放的API接口，支持远程对系统的行为进行控制与调试”，在此处，我们注意到描述的核心落在“支持远程对系统的行为进行控制与调试”上了，而调试是在测试之后精确定位系统错误的一种机制，所以这种做法有利于提高系统的可测试性。最后的两空也是考概念：在识别出上述描述后，通常采用效用树对质量属性的描述进行刻画与排序。在评估过程中，权衡点是一个会影响多个质量属性的架构设计决策。SAAMATAM特定目标通过程序文档验证体系结构，注重发现潜在问题，可用于评价单系统或进行多系统比较确定在多个质量属性之间折中的必要性评估技术场景技术场景技术、启发式分析方法质量属性可修改性是主要分析内容性能、可用性、安全性和可修改性风险承担者所有参与者场景和需求收集过程中，相关人体系结构描述围绕功能、结构和分配描述5个基本结构及其映射关系方法活动场景开发、体系结构描述、单个场景评估、场景交互和总体评估场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中知识库可复用性不涉及有基于属性的体系模型，可复用方法验证（应用领域）空中交通管制系统、嵌入式音频系统、修正控制系统仍处于研究中属性子属性作用及要点性能效率指标：处理任务所需时间或单位时间内的处理量可靠性容错出现错误后仍能保证系统争取运行，且自行修正错误健壮性错误不对系统产生影响，按既定程序忽略错误可用性正常运行的时间比例安全性系统向合法用户提供服务并阻止非法用户的能力可修改性可维护性局部修复使故障对架构的负面影响最小化可拓展性因松散耦合更易实现新特性/功能，不影响架构结构重组不影响主体进行的灵活配置可移植性适用于多样的环境（硬件平台、语言、操作系统等）功能性需求