2022年系统架构设设计师历年论文知识点总结

系统架构设设计师论文知识点总结2021年一、A0P技术开发的具体步骤所谓方面就是将那些与业务无关的，却为业务模块所共同调用的逻辑或责任都封装起来,以减少系统的重复代码，降低模块间的耦合度，并有利于未来的可操作性和可维护性。A0P代表的是一个横向的关系，如果说对象是一个空心的圆柱体，其中封装的是对象的属性和行为；那么面向方面的编程就是一把利刃，将这些空心圆柱体剖开，以获得其内部的消息。而剖开的切面就是所谓的方面了。然后它又以巧夺天工的妙手将这些剖开的切面复原，不留痕迹。使用"横切”技术，A0P把软件系统分为两个部分：核心关注点和横切关注点。业务处理的主要流程是核心关注点，与之关系不大的部分是横切关注点。横切关注点的一个特点是，他们经常发生在核心关注点的多处，而各处都基本相似，比如权限认证、日志、事务处理。A0P的作用在于分离系统中的各种关注点，将核心关注点和横切关注点分离开来。A0P应用程序包括以下三个主要的开发步骤：1、 区分横切关注点将系统需求进行功能性分解，区分出普通关注点以及横切关注点，确定哪些功能是组件语言必须实现的，哪些功能可以以aspect的形式动态加入到系统组件中。2、 构造出系统的切面单独完成每一个关注点的编码和实现，构造系统组件和系统aspecto这里的系统组件，是实现该系统的基本模块，对OOP语言，这些组件可以是类，对于过程化程序设计语言，这些组件可是各种函数和API。系统aspect是指用AOP语言实现的将横切关注点封装成的独立的模块单元。3、 组件代码与切面代码结合形成系统用联接器指定的重组规则，将组件代码和aspect代码进行组合，形成最终系统。为达到此目的，应用程序需要利用或创造一种专门指定规则的语言，用它来组合不同应用程序片断。这种用来指定联结规则的语言可以是一种已有编程语言的扩展，也可以是一种完全不同的全新语言。二、 详细论述安全架构设计中鉴别框架和访问控制框架设计的内容，并论述鉴别和访问控制所面临的主要威胁，并说明其危害。鉴别（Authentication）的基本目的就是防止其他实体占用和独立操作被鉴别实体的身份。鉴别提供了实体声称其身份的保证。鉴别的两种重要的关系背景：一是实体由申请者来代表，申请者与验证者之间存在着特定的通信关系（如实体鉴别）；二是实体为验证者提供数据项来源。鉴别的方式主要有以下的几种：已知的，如一个秘密的口令拥有的，如IC卡，令牌等不改变的特征，如生物特征相信可靠的第三方建立的鉴别（递推）环境（如主机地址等）。访问控制（AccessControl）决定开放系统环境中允许使用哪些资源，在什么地方适合阻止未授权的访问的过程。在访问控制实例中，访问可以是对一个系统（即对一个系统通信部分的一个实体）或对一个系统内部进行的。三、 给出至少4种企业集成平台应具有的基本功能，并对这4种功能内涵进行筒述。集成平台是支持企业集成的支撑环境，包括硬件软件，软件工具和系统，通过集成各种企业应用软件的多样性，企业信息系统的功能和环境都非常复杂，因此为了能够较好地满足企业的应用需求，作为企业应用集成支持环境的集成平台，应该具有以下的基本功能。1） 通信服务它提供分布环境下透明的同步异步通信服务功能，使用户和应用程序无需关心具体的操作系统和应用程序所处的网络物理位置，而以透明的函数调用或对象服务方式完成它们所需的通信服务要求。2） 信息集成服务它为应用提供透明的信息访问服务，通过实现异种数据库系统之间的数据的交换，互操作，分布数据管理和共享信息模型定义（或共享信息数据库的建立），使集成平台上运行的应用，服务或用户端能够以一致的语义和接口实现对数据（数据库，数据文件，应用交互信息）的访问与控制。3） 应用集成服务它通过高层应用编程接口来实现对相应应用程序的访问，这些高层应用编程接口包含在不同的应用程序。这些接口以函数或对象服务的方式向平台的组件模型提供信息，使用户在无需对原有系统进行修改的情况下，只要在原有系统上加上访问的接口就可以将现有的，用不同的技术实现的系统互联起来，通过为应用系统提供数据交换和访问操作，使各种不同的系统能够相互协作。4） 二次开发工具二次开发工具是集成平台提供的一组帮助用户开发特定应用程序（如实现数据转换的适配器或应用封装服务等）的支持工具，其目的是简化用户在企业集成平台实施过程中（特定应用程序接口）的开发工作。5） 平台运行管理工具它是企业集成平台的运行管理和控制模块，负责企业集成平台系统的静态和动态配置，集成平台应用运行管理和维护，事件管理和出错管理等，通过命名服务，目录服务，平台的动态和静态配置，以及其中的关键数据的定期备份等功能来维护整个服务平台的系统配置及稳定运行。四、筒要描述微服务优点。1） 技术异构性在微服务架构中，每个服务都是一个相对独立的个体，每个服务都可以选择合适于自身的技术来实现。如要开发一个社交平台，此时我们可能使用文档型数据库来存储帖子的内容，使用图数据来存储朋友圈的这些关系，可以将每一块的性能都充分发挥出来。同时在应用新技术时，微服务架构也提供了更好的平台。因为对于单块的系统而言，采用一个新的语言，数据库或者框架都会对整个系统产生非常巨大的影响，这样就导致我们在尝试新技术的时候望而却步。但是微服务不同，我们完全可以只在一个微服务中采用新技术,然后等成熟之后再推广到其他的服务当中。2） 弹性系统中的一部分如果出现了故障会引起多大问题。在单块系统中一个部分出现问题，可能导致整个系统的问题。而微服务架构中，每个服务可以内置可用性的解决方案与功能降级方案，所以比单块系统强大。3） 扩展在单块的系统中我们如果要对系统进行扩展的话，必须是整体的进行扩展，而使用微服务的架构中，可以针对单个服务进行扩展。4） 筒化部署对于大型单块的系统，哪怕是修改了一行代码，都要对其进行重新的整体的部署。这种部署影响很大，风险高因此不敢轻易重新部署。而在微服务中，每个服务都是独立部署的，而且还可以实现自动化的部署，这样就可以更快的对特定部分的代码进行部署。5） 与组织结构相匹配对于传统的单块系统来说，系统越大代码库越大，则越难管理，而且还会出现一系列管理方面的问题。体会团队是分布式（虚拟团队）的时候，那么管理的复杂度将会更高。而微服务的出现就很好的解决了这个问题。微服务架构可以将架构与组织结构相匹配，避免的了出现过大的代码库，从而获得理想团队大小和生产力。服务的所有权也可以在团队之间迁移，从而避免异地团队的出现。6） 可组合性在微服务架构中，系统会开放很多的接口供外部使用。当情况发生改变时，可以使用不同的方式构建应用，而整体化应用程序只能提供一个非常粗粒度的接口供外部使用。7） 对可替代性的优化在单块系统中如果删除系统中的上百行代码，也许不知道会发生什么，引起什么样的问题，因为单块系统中关联性很强。但在微服务架构中，我们可以在需要时轻易的重写服务，或者删除不再使用的服务。2020年一、Hash分片、一致性Hash分片和按照数据范围分片是三种常用的数据分片方式。常用的关系型数据库都存在性能瓶颈，即在数据达到一定的量级之后，数据库的性能会显著下降，数据库的读写操作都会随之受到影响。所以就需要对数据库进行优化处理。比如缓存技术，读写分离技术和数据分片技术都可以起到提高性能，缓解单个物理节点的压力。缓存工作中比较常用的如Redis用来缓解数据库的压力。将热点数据预热到缓冲中，避免大量的访问压力直接给到数据库上面，给数据库减轻负担。读写分离配置实现主从数据库，将请求分为读/写两种类型，读请求走从库（slave）,写类型请求走主库（master）0比如MySQL自身提供的主从数据同步方案。主从库之存在较低（可接受范围）的数据同步延迟。数据分片如果单表/单库存在数据保存的性能问题，可使用分片将保存的数据分散到多个库表中,其中分为水平分片和垂直分片。水平分片统一类型的数据，分别放到不同的库/表中。每个分片包含了整体的数据集合的一部分。虽然可减轻单节点的访问压力，又迎来了分布式事务的问题。垂直分片存在一个宽表(即包含过多字段的表)，其中某几个字段属于热点数据，客户端请求某一条记录，大部分情况下都是要获取这条记录中的某几个热点字段。这个时候，将这张表拆分为主表和从表两张表，热点数据单独成表(从表)，这样数据访问/更新会避免在宽表上的大量操作。提前合计好对应的主从表。按照不同的业务模块拆分数据库，这样可以适当的减少单个服务器的压力。三种数据分片方式:hash方式，一致性哈希(consistenthash),按照数据范围(rangebased)哈希分片概念：按照数据的某一特征来计算哈希值，并将哈希值与系统中的节点建立映射关系。优点：简单易于实现缺点：很难解决数据不均衡问题，再增加一个机器，每个机器对应的一个hash值的区域就发生改变。补充：假设这里面是按员工的薪水进行计算hash值，实际人群中，可能处于平均薪水10k左右的人比较多，高薪水的人比较少这导致某些机器上的数据很大，导致大量的数据集中到一个物理节点上。一致性哈希概念：一致性hash相当与一个环。所有的数据都在这个环上，每个机器相当于环的一截，相比于上述的hash方式，一致性hash方式需要维护的元数据额外包含了节点在环上的位置。优点：简单易于实现，在增删数据的时候只会影响到hash环上相邻的节点，不会发生大规模的数据迁移。缺点：增加节点的时候，只能分摊一个已存在节点的压力补充：在实际工程中，一般会引入虚拟节点(virtualnode)的概念。即不是将物理节点映射在hash换上，而是将虚拟节点映射到hash环上。虚拟节点的数目远大于物理节点，因此一个物理节点需要负责多个虚拟节点的真实存储。操作数据的时候，先通过hash环找到对应的虚拟节点，再通过虚拟节点与物理节点的映射关系找到对应的物理节点。按照数据范围概念：就是按照关键值划分成不同的区间，每个物理节点负责一个或者多个区间。其实这种方式跟一致性hash有点像，可以理解为物理节点在hash环上的位置是动态变化的。优点：当达到这个阈值之后就会分裂成两个块。这样做的目的在于当有节点加入的时候，可以快速达到均衡的目的缺点：在数据可修改的情况下，如果块进行分裂，那么元数据中的区间信息也需要同步修改。补充：rangebased这种数据分片方式应用非常广泛，比如MongoDB,PostgreSQL,HDFS比校如果一个节点负责的数据只有一个区间，rangebased与没有虚拟节点概念的一致性hash很类似；如果一个节点负责多个区间，rangebased与有虚拟节点概念的一致性hash很类似。分片方式映射难度元数据节点增删数据动态均衡哈希方式简单、非常简单几乎不用修改需要迁移的数据比较多不支持一致性哈希简单比较简单，取决于节点规模几乎不用修改增刪节点的时候只影响hash环上相邻节点，但不能使所有节点都参与数据迁移过程不支持一致性哈希（虛中等稍微复杂很少修改需要迁移的数弱支持（修改虚拟节点）一些主要取决于虚拟节点规模据比较少，且所有节点都能贡献部分数据拟节点与物理节点映射关系）范围分片较为复杂取决于每个块的大小一般来说规模较大，且修改频率较高需要迁移的数据比较少，且所有节点都能贡献部分数据支持比较容易数据分片需要按照一定的规则，不同的分布式应用有不同的规则，但都遵循同样的原则：按照最主要、最频繁使用的访问方式来分片。具体如何划分原始数据集当原问题的规模变大的时候，能否通过增加节点来动态适应当某个节点故障的时候，能否将该节点上的任务均衡的分摊到其他节点对于可修改的数据（比如数据库数据），如果某节点数据量变大，能否以及如何将部分数据迁移到其他负载较小的节点，及达到动态均衡的效果元数据的管理（即数据与物理节点的对应关系）规模元数据更新的频率以及复杂度二、 服务化、强刼性、可观测性和自动化是云原生架构重复的四类设计原则，请简要对这四类设计原则的内涵进行阐述。云原生架构以微服务和容器技术为代表，有服务化、强韧性、可观测性和自动化四类设计原则。通过服务化的设计原则，应用被分解为多个服务，可分别选择不同的技术，单个服务模块很容易开发、理解和维护，无需协调其他服务对本服务的影响；通过强韧性的设计原则，微服务可以分布式云化部署，负载均衡管理请求的分发，避免单机失败对整体服务的影响，以及弹性调整资源容量；通过可观测性的设计原则，能够对系统进行健康检查、指标监控、日志管理和链路追踪，提高系统运维、管理和排错能力；通过自动化的设计原则，可实现系统的自动化部署、自动化扩展伸缩、自动化运维、持续交付和集成，有效减少人工操作的工作量。三、 详细论述常见的缺陷种类及级别，论述缺陷管理和基本流程软件缺陷的定义软件缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷的标准定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。导致软件缺陷产生的原因也是多种多样的，软件工程过程中的人、过程、工具都有可能导致产生软件缺陷，过程中的每一个环节都有可能产生缺陷软件缺陷的分类功能没有实现或与需求规格说明不一致；界面、消息、提示、帮助不够准确或误导用户；屏幕显示、打印结果不正确；软件无故退出或没有反应；边界条件未做处理，输入错误数据没有提示和说明；运行速度慢或占用资源过多；与常用的交互软件不兼容；缺陷管理的目的是：对各个阶段测试发现的缺陷进行跟踪管理，以保证各级缺陷的修复率达到标准，主要实现以下目标：（1） 保证信息的一致性；（2） 保证缺陷得到有效的跟踪，缩短沟通时间，解决问题更高效；（3） 收集缺陷数据并进行数据分析，作为缺陷度量的依据。参与缺陷管理的角色测试工程师：发现和回归BUG测试经理：判断BUG的有效性开发经理：分配BUG开发工程师：修改BUG缺陷来源Requirement：由于需求的问题引起的缺陷（需求不完全或逻辑错误）Architecture：由于檢架的问题引起的缺陷（登录session失效）Design：由于设计的问题引起的缺陷（图片大小，页面元素显示问题等Code：由于编码的问题引起的缺陷Test：由于刘试的问题引起的缺陷（软件测试的设计与实施发生错误。特别是系统级的功能测试）Integration：由于集衣的问题引起的缺陷缺陷严重性和优先级缺陷严重性和优先级缺陷的严重性说明0级（致命）最严重等级，缺陷导致系统任何一个主要功能完全丧失、用户数据受到破坏、系统崩溃、悬挂、死机等1级（严重）系统的主要功能部分丧失、数据不能完全保存，系统的次要功能完全丧失，系统所提供的功能或服务收到明显影响2级（一般）系统的次要功能没有完全实现，但不影响用户的正常使用。例如，提示信息不太准确；或用户界面差、操做时间稍长等问题3级（微小）操作者不方便或遇到麻烦，但不影响功能的操做和执行，如字体不美观、按钮大小不很合适、字体排列不对齐等一些小问题缺陷的优先级说明立即解决（pl级）缺陷导致系统几乎不能完全运行、使用，或严重妨碍测试的执行，需立即修正、尽快修正高优先级（p2级）缺陷严重，影响测试，需要优先考虑修正，如不超过24小时修正正常排队（p3级）缺陷需要修正，但可以正常排队等待修正低优先级（p4级）缺陷可以在开发人员有时间的时候被修正，如果没时间可以不修正缺陷管理基本流程：（1）提交：测试人员发现缺陷后，将缺陷提交给测试组长。（2） 分配：测试负责人收到测试人员提交的缺陷后，交给开发人员。（3） 确认：开发者收到转移的缺陷后，会与团队甚至测试人员讨论确定该缺陷是否为缺陷。（4） 拒绝/延期：如果经协商，该缺陷不是真正的缺陷，则拒绝处理并关闭该缺陷；如果经过协商确定是真正的缺陷，可以根据缺陷的严重程度或优先级等选择立即处理或推迟处理。处理：显影剂修正缺陷。重新测试：开发者修正缺陷后，测试者重新测试，检查缺陷是否确实被修改了。如果没有正确修改，请重新提交缺陷。关闭：测试人员重新测试后，如果缺陷已被正确纠正，则关闭缺陷，完成整个缺陷处理。四、详细说明三类企业集成架构设计技术分别要解决的问題及其含义，并阐述每种技术具体包含了哪些集成架构。企业信息化集成主要由界面集成、应用集成、数据集成等方式。界面集成，通过UI将不同业务模块或系统的界面进行集成整合，使用户查看或使用系统时，不需要打开N多个系统进行操作。应用集成，一般指功能或API集成，它可以使不同厂家开发的系统通过接口整合后，实现互联互通的目的，使得原本不相容的两个或多个系统，可以互相协同工作。数据集成是以数据共享的方式对不同系统中模块中的数据进行整合，使之整合成一个完整的数据信息，供不同系统时实现数据共享。2019年一、详细阐述有哪些不同的软件设计方法，并说明每种方法的适用场景。软件设计方法包括有：模型驱动设计，面向对象设计，结构化设计，快速应用开发，原型设计，信息工程法。模型驱动设计模型驱动设计是一种系统设计方法，强调通过绘制图形化系统模型描述系统的挖术称莫现。通常从模型驱动分析中开发的逻辑模型导出系统设计模型，最终系统设计模型将作为构造和实现新系统的蓝图。结构化设计它是一种面向过程的系统设计技术，它将系统过程分解成一个容易实现和维护的计算机程序模块。把一个程序设计成一个自顶向下的模块层次，一个模块就是一组指令：一个程序片段，程序块，子程序或者子过程，这些模块自顶向下按照各种设计规则和设计指南进行开发，模块需要满足高内聚松散耦合的特征。信息工程法信息工程是一种用来计划，分析和设计信息系统的模型驱动的，以数据为中心的但对过程敏感的技术。信息工程模型是一些说明和同步系统的数据和过程的图形。信息工程的主要工具就是数据模型图(物理实体关系图)。4） 原型设计原型法是一种反复迭代过程，它需要设计人员和用户之间保持紧密的工作关系，通过构造一个预期系统的小规模的，不完整的但可以工作的示例来与用户交互设计的结果。原型设计方法鼓励并要求最终用户主动参与，这增加了最终用户对项目的信心和支持。更好地适应用户总是想改变想法的自然情况。原型是主动的模型，最终用户可以看到并与之交互。5） 面向对象设计是一种新的设计策略，用于精炼早期面向对象分析阶段确定的对象需求定义，并定义新的与设计相关的对象。面向对象设计是面向对象分析的延伸，有利于消除数据和过程的分离。（写作参考：在我们惯常的项目开发中，经常会使用各种设计工具来做系统分析，制作各种设计图并以之为基础和客户进行讨论，经过确认达成一致后作为系统分析的产物。然而一旦进入到开发阶段，开发人员根本不会按照之前的设计来实现，很多时候代码只是实现了功能，大部分实现都经过重新设计，而分析模型则直接被扔在了一边。导致这样做的一个根本原因，是我们缺乏一套建模范式。它可以采用统一的方式，并可以非常方便的将模型转化为代码设计并可以保持模型与设计之间的映射关系。面向对象设计（Object-OrientedDesign）是目前为止公认的可以实现该要求的建模范式。后续文章则将在关注在如何使用面向对象设计来实现领域驱动的相关问题上。抽象出关键的领域知识（名词定义）并支持有效的实现（设计范式），是模型驱动设计的核心二要素。开发人员要意识到代码和模型是整个系统的一体两面，改变代码即意味着改变模型。如果忽略了这一点，到最后模型则将失去指导作用，并逐渐变得不可用。同时，建模人员也应花时间去了解代码。双方通过使用统一领域语言保持模型和实现的一致性。）6） 快速应用开发是一种系统设计方法，是各种结构化技术（特别是数据驱动的信息工程）与原型化技术和联合应用开发技术的结合，用以加速系统的开发。快速应用开发要求反复的使用结构化技术和原型技术来定义用户的需求并设计最终系统。二、详细阐述有哪些不同的软件系统架构评估方法，并从评估目标、质量属性和评估活动等方面论述其区别。常见的系统体系架构分析方法有SAAM和ATAMoSAAM（Scenarios-basedArchitectureAnalysisMethod）是一种非功能质量属性的体系架构分析方法。最初用于比较不同的体系架构，分析架构的可修改性，后来也用于其他的质量属性，如可移植性、可扩充性等。1） 特定目标对描述应用程序属性的文档，验证基本体系结构假设和原则。SAAM不仅能够评估体系结构对于特定系统需求的适用能力，也能被用来比较不同的体系结构。2） 评估活动SAAM的过程包括了五个步骤：即场景开发，体系结构描述，单个场景评估，场景交互，总体评估。ATAM（ArchitectureTradeoffAnalysisMethod）是在SAAM的基础上发展起来的，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。（1） 特定目标：在考虑多个相互影响的质量属性的情况下，从原则上提供一种理解软件体系结构的能力的方法，使用该方法确定在多个质量属性之间折中的必要性。（2） 评估活动：分为四个主要的活动领域，分别是场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中。三、详细阐述数据湖技术，并从主要数据来源、数据模式（（Schema））转换时机、数据存储成本、数据质量、面对用户和主要支撑应用类型等5个方面详细论述数据湖技术与数据仓库技术的差异。数据仓库是一个优化的数据库，用于分析来自事务系统和业务线应用程序的关系数据。数据仓库技术需要事先定义数据结构和数据模式（Schema）以优化快速SQL查询，其中结果通常用于操作报告和分析。数据经过了清理、丰富和转换，因此可以充当用户可信任的“单一信息源”。与数据仓库不同，数据湖能够同时存储来自业务线应用程序的关系数据，以及来自移动应用程序、物联网设备和社交媒体的非关系数据。在进行数据捕获时，无须定义数据结构或数据模式（Schema）。数据湖支持用户对数据使用不同类型的分析（如SQL查询、大数据分析、全文搜索、实时分析和机器学习等），为企业智能决策提供支撑。下面从主要数据来源、数据模式转换时机、数据存储成本、数据质量、面对用户和主要支撑应用类型等六个方面对数据湖技术和数据仓库技术进行比较：特征主要数据来源数据模式转换时机数据存储成本数据质量面对用户主要支撑应用类型数来自物联网设备，数据进入数通常基于原始的，未业务分析机器学习，据互联网，移动应用据湖时不进非关系型经处理的师应用分析湖程序，社交媒体和企业应用程序的结构化，半结构化和非结构化数据行相应的模式转换，在进行实际数据分析时才进行模式转换数据库，数据存储成本相对较低数据数据仓库来自事务系统，运营数据库和业务线应用程序的结构化数据在进入数据仓库之前（需要提前设计数据仓库的Schema）通常基于关系型数据库，数据存储成本较高可作为重要事实依据的高质量数据应用开发人员和数据科学家业务分析师数据发现和分析批处理报告，商业智能四、详细阐述常见的三种负载均衡算法，说明算法的基本原理。现有的负载均衡算法主要分为静态和动态两类。静态负载均衡算法以固定的概率分配任务，不考虑服务器的状态信息，如轮转算法和随机法等；动态负载算法以服务器的实时负载状态信息来决定任务的分配，如最小连接法等。轮询法轮询法就是将用户的请求轮流分配给服务器，就像是挨个数数，轮流分配。这种算法比较简单，具有绝对均衡的优点，但是也正是因为绝对均衡，它必须付出很大的代价，例如它无法保证分配任务的合理性，也无法根据服务器的承受能力来分配任务。随机法就是随机选择一台服务器来分配任务。它保证了请求的分散性达到了均衡的目的。同时它是没有状态的，不需要维持上次的选择状态和均衡因子。但是随着任务量的增大，它的效果趋向轮询后也会有轮询法的部分缺点。最小连接法最小连接法将任务分配给此时具有最小连接数的节点，因此它是动态负载均衡算法。一个节点收到-个任务之后连接数就会加1,当节点发生故障时就将结点的权值设置为0,也就是不再给结点分配任务。该算法适用于各个节点的运算处理性能相似的情形。任务分发单元会将任务平滑分配给服务器。但当服务器性能差距较大的时候，就无法达到预期的效果。因此此时连接数并不能准确表明处理能力，连接数小而自身性能很差的服务器可能不及连接数大而自身性能极好的服务器。所以在这个时候就会导致任务无法准确地分配到剩余处理能力强的机器上。2018年一、详细论述软件开发过程产品RUP所包含的4个阶段以及RUP的基本特征。RUP中的软件过程在时间上被分解为四个顺序的阶段，分别是初始阶段，细化阶段，构件阶段，交付阶段。每个阶段结束时都要安排一次技术评审，以确定这个阶段的目标是否已经满足。如果评审结果令人满意，就可以允许项目进入下一个阶段。四个阶段的核心任务分别为初始阶段明确地说明项目规模。这涉及了解环境及最重要的需求和约束，以便于可以得出最终产品的验收标准。计划和准备商业理由。评估风险管理，人员配备，项目计划和成本/进度/收益率折衷的备选方案。综合考虑备选构架，评估设计和自制外购复用方面的折中，从而估算出成本，进度和资源。此处的目标在于通过对一些概念的证实来证明可行性。该证明可采用可模拟需求的模型形式或用于探索被认为高风险区域的初始原型。初始阶段的原型设计工作应该限制在确信解决方案可行就可以了。该解决方案在细化和构建阶段实现。准备项目的环境，评估项目和组织，选择工具，决定流程中要改进的部分细化阶段快速确定构架，确认构架并为构架建立基线。根据此阶段获得的新信息改进前景，对推动架构和计划决策的最关键用例建立可靠的了解。为构建阶段创建详细的迭代计划并为其建立基线。改进开发案例，定位开发环境，包括流程和支持构件团队所需的工具和自动化支持。改进构架并选择构件。评估潜在构件，充分了解自制外购复用决策，以便有把握地确定构建阶段的成本和进度。集成了所选构架构件，并按主要场景进行了评估。通过这些活动得到的经验有可能导致重新设计构架，考虑替代设计或重新考虑需求。构建阶段资源管理，控制和流程优化。完成构件开发并根据已经定义的评估标准进行测试。根据前景的验收标准对产品发布版进行评估。提交阶段执行部署计划对最终用户支持材料定稿在开发现场测试可交付产品制作产品发布版。获得用户的反馈基于反馈调整产品使最终用户可以使用产品RUP最核心的3个特征是：用例驱动、以架构为中心的、迭代和增量。制品（Artifact） what的问题：制品是活动生成、创建或修改的一段信息。也可译为产品、工件等，和制品的意思差不多。工作流（Workflow） when的问题：工作流描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。二、软件体系结构的演化是便用系统演化步骤去修改系统，以满足新的需求。筒要论述系统演化的6个步骤。求设文立文字即直相实标裘演）毂矣分包审（曲英的分包进行许审） •射用产审（用求设文立文字即直相实标裘演）毂矣分包审（曲英的分包进行许审） •射用产审（用＞3产料婷子给你授損讹11了）0「 J1 架构@比图t9«FS!构的软件开发復5!- 歸求5©………1………1 H出舉屹脸牛®gm1:1♦10「 J1 架构@比图t9«FS!构的软件开发復5!- 歸求5©………1………1 H出舉屹脸牛®gm1:1♦1:标识J? ON；把类啥4梅件1;1j构11-_IV車评0I 设计畑图6U0架构需求过程ffi6-llSE构设计过程分析设计实現组¥«1试图&12ON腐球受化運）|@?恂件的相M作用H球受化呛女岸恂件ift计软件1«板約束需康■化后的聚梅图&13架构演化过世图6-8ABSDH法与生命爛期软件体系结构演化实际上指的是ABSD方法（基于架构的软件设计方法）中的最后一个阶段。体系结构演化是使用系统演化步骤去修改应用，以满足新的需求。主要包括以下六个步骤。番求变动归类首先必须对用户需求的变化进行归类，使变化的需求与已有构件对应。对找不到的构件的变动，也要做好标记，在后续工作中，将创建新的构件，以对应这部分变化的需求。制定体系结构演化计划在改变原有结构之前，开发组织必须制订一个周密的体系结构演化计划，作为后续演化开发工作的指南。修改增加或删除构件（构件变动）在演化计划的基础上，开发人员可根据在第1步得到的需求变动的归类情况，决定是否修改或删除存在的构件、增加新构件。最后，对修改和增加的构件进行功能性测试。更新构件的相互作用随着构件的增加、刪除和修改，构件之间的控制流必须得到更新构件组装与测试通过组装支持工具把这些构件的实现体组装起来，完成整个软件系统的连接与合成，形成新的体系结构。然后对组装后的系统整体功能和性能进行测试。技术评审对以上步骤进行确认，进行技术评审。评审组装后的体系结构式否反映需求变动，符合用户需求。如果不符合，则需要在第2到第6步之间进行迭代。三、说明面向服务架构的主要技术和标准，详细阐述每种技术和标准的具体内容。面向服务架构的主要技术有Web服务、ESBo涉及到的标准有：UDDI协议UDDI（统一描述、发现和集成协议）计划是一个广泛的、开放的行业计划，它使得商业实体能够（1）彼此发现，（2）定义他们怎样在Internet±互相作用，并在一个全球的注册体系架构中共享信息。UDDI是这样一种基础的系统构筑模块，它使商业实体能够快速、方便地使用他们自身的企业应用软件来发现合适的商业对等实体，并与其实施电子化的商业贸易。UDDI同时也是Web服务集成的一个体系框架。它包含了服务描述与发现的标准规范。UDDI规范利用了W3C和Internet工程任务组织（IETF）的很多标准作为其实现基础，比如扩展标注语言（XML）、HTTP和域名服务（DNS）等协议。另外，在跨平台的设计特性中，UDDI主要采用了已经被提议给W3C的SOAPCSimpleObjectAccessProtocol,简单对象访问协议）规范的早期版本。WSDL规范WSDL是WebServicesDescriptionLanguage（Web服务描述语言）的缩写，是一个用来描述Web服务和说明如何与Web服务通信的XML语言。它是Web服务的接口定义语言，由Ariba、Intel、IBM、MS等共同提出，通过WSDL,可描述Web服务的三个基本属性：1、 服务做些什么一一服务所提供的操作（方法）；2、 如何访问服务一一和服务交互的数据格式以及必要协议；3、 服务位于何处——协议相关的地址，如URL。WSDL文档以端口集合的形式来描述Web服务，WSDL服务描述包含对一组操作和消息的一个抽象定义，绑定到这些操作和消息的一个具体协议，和这个绑定的一个网络端点规范。SOAP协议SOAP(SimpleObjectAccessProtocol)简单对象访问协议是在分散或分布式的环境中交换信息的简单的协议，是一个基于XML的协议。它包括四个部分：SOAP封装(Envelop),封装定义了一个描述消息中的内容是什么，是谁发送的，谁应当接受并处理它，以及如何处理它们的框架；SOAP编码规则(Encodi阴Rules),用于表示应用程序需要使用的数据类型的实例；SOAPRPC表示(RPCRepresentation),表示远程过程调用和应答的协定；SOAP绑定(Binding),使用底层协议交换信息。四、详细论述常见的NoSQL数据库技术及其所包含的主要内容，并说明NoSQL数据库的主要适用场景。NoSQL的主要优势避免不必要的复杂性高呑吐量高水平扩展能力和低端硬件集群避免了昂贵的关系对象映射N0SQL的缺点数据模型和查询语言没有经过数学验证不支持ACID特征功能简单没有统一的查询模型NoSQL的分类键值(Key-Value)存储数据库这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。但是如果DBA只对部分值进行查询或更新的时候，Key/value就显得效率低下了。例如：TokyoCabinet/Tyrant,Redis,Voldemort.OracleBDB.适应场景：会话、配置文件、参数、购物车等等。这些信息一般都和ID(键)挂钩，这种情景下键值数据库是个很好的选择。不适应场景：1)取代通过键查询，而是通过值来查询。Key-Value数据库中根本没有通过值查询的途径。2)需要储存数据之间的关系。在Key-Value数据库中不能通过两个或以上的键来关联数据。3）事务的支持。在Key-Value数据库中故障产生时不可以进"亍回滚。列存储数据库这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。HBase：FIBase是一个分布式的、面向列的开源数据库，该技术来源于FayChang所撰写的Google论文"Bigtable：—个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统（F订eSystem）所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。列存储数据库将数据储存在列族（columnfamily）中，一个列族存储经常被一起查询的相关数据。举个例子，如果我们有一个Person类，我们通常会一起查询他们的姓名和年龄而不是薪资。这种情况下，姓名和年龄就会被放入一个列族中，而薪资则在另一个列族中。产品：CassandraHBase适用的场景1） 日志。因为我们可以将数据储存在不同的列中，每个应用程序可以将信息写入自己的列族中。2） 潯客平台。我们储存每个信息到不同的列族中。举个例子，标签可以储存在一个，类别可以在一个，而文章则在另一个。不适用场景1） 如果我们需要ACID事务。Vassandra就不支持事务。2） 原型设计。如果我们分析Cassandra的数据结构，我们就会发现结构是基于我们期望的数据查询方式而定。在模型设计之初，我们根本不可能去预测它的查询方式，而一旦查询方式改变，我们就必须重新设计列族。文档型数据库面向文档数据库会将数据以文档的形式储存。每个文档都是自包含的数据单元，是一系列数据项的集合。每个数据项都有一个名称与对应的值，值既可以是简单的数据类型，如字符串、数字和日期等；也可以是复杂的类型，如有序列表和关联对象。数据存储的最小单位是文档，同一个表中存储的文档属性可以是不同的，数据可以使用XML、JSON或者JSONB等多种形式存储。文档型数据库的灵感是来自于LotusNotes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如：CouchDB,MongoDB.国内也有文档型数据库SequoiaDB,已经开源。MongoDB：MongoDB是目前在IT行业非常流行的一种非关系型数据库（NoSql）,其灵活的数据存储方式备受当前IT从业人员的青睐。MongoDB很好的实现了面向对象的思想（00思想），在MongoDB中每一条记录都是一个Document对象。MongoDB最大的优势在于所有的数据持久操作都无需开发人员手动编写SQL语句，直接调用方法就可以轻松的实现CRUD操作。SequoiaDB：SequoiaDB是一款分布式非关系型文档数据库，可以被用来存取海量非关系型的数据，其底层主要基于分布式，高可用，高性能与动态数据类型设计SequoiaDB可以独立作为一款高性能可扩展的NoSQL数据库使用，也可与当前主流分布式计算框架Hadoop紧密集成。产品：MongoDB、CouchDB、RavenDB适用的场景1） 日志:>企业环境下，每个应用程序都有不同的日志信息。Document-Oriented数据库并没有固定的模式，所以我们可以使用它储存不同的信息。2） 分析。鉴于它的弱模式结构，不改变模式下就可以储存不同的度量方法及添加新的度量。不适用场景在不同的文档上添加事务。Document-Oriented数据库并不支持文档间的事务，如果对这方面有需求则不应该选用这个解决方案。图形（Graph）数据库图形结构的数据库同其他行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语言（SQL）,因此进行数据库查询需要制定数据模型。许多NoSQL数据库都有REST式的数据接口或者查询API。如：Neo4J,InfoGrid,InfiniteGraph.图数据库允许我们将数据以图的方式储存。实体会被作为顶点，而实体之间的关系则会被作为边。比如我们有三个实体，SteveJobs、Apple和Next,则会有两个"Foundedby"的边将Apple和Next连接到SteveJobso产品：Meo4J、InfiniteGraph,OrientDB适用的场景1） 在一些关系性强的数据中2） 推荐引擎。如果我们将数据以图的形式表现，那么将会非常有益于推荐的制定不适用场景不适合的数据模型。图数据库的适用范围很小，因为很少有操作涉及到整个图。2017年一、说明软件系统开发中常用的建模方法有哪几类？阐述每种方法的特点及其适用范围。软件设计方法包括有：模型驱动设计，面向对象设计，结构化设计，快速应用开发，原型设计，信息工程法。1） 模型驱动设计模型驱动设计是一种系统设计方法，强调通过绘制图形化系统模型描述系统的攬术称共现。通常从模型驱动分析中开发的逻辑模型导出系统设计模型，最终系统设计模型将作为构造和实现新系统的蓝图。2） 结构化设计它是一种面向过程的系统设计技术，它将系统过程分解成一个容易实现和维护的计算机程序模块。把一个程序设计成一个自顶向下的模块层次，一个模块就是一组指令：一个程序片段，程序块，子程序或者子过程，这些模块自顶向下按照各种设计规则和设计指南进行开发，模块需要满足高内聚松散耦合的特征。3） 宿息工程法信息工程是一种用来计划，分析和设计信息系统的模型驱动的，以数据为中心的但对过程敏感的技术。信息工程模型是一些说明和同步系统的数据和过程的图形。信息工程的主要工具就是数据模型图（物理实体关系图）。4） 原型设计原型法是一种反复迭代过程，它需要设计人员和用户之间保持紧密的工作关系，通过构造一个预期系统的小规模的，不完整的但可以工作的示例来与用户交互设计的结果。原型设计方法鼓励并要求最终用户主动参与，这增加了最终用户对项目的信心和支持。更好地适应用户总是想改变想法的自然情况。原型是主动的模型，最终用户可以看到并与之交互。5） 面向对象设计是一种新的设计策略，用于精炼早期面向对象分析阶段确定的对象需求定义，并定义新的与设计相关的对象。面向对象设计是面向对象分析的延伸，有利于消除数据和过程的分离。（写作参考：在我们惯常的项目开发中，经常会使用各种设计工具来做系统分析，制作各种设计图并以之为基础和客户进行讨论，经过确认达成一致后作为系统分析的产物。然而一旦进入到开发阶段，开发人员根本不会按照之前的设计来实现，很多时候代码只是实现了功能，大部分实现都经过重新设计，而分析模型则直接被扔在了一边。导致这样做的一个根本原因，是我们缺乏一套建模范式。它可以采用统一的方式，并可以非常方便的将模型转化为代码设计并可以保持模型与设计之间的映射关系。面向对象设计（Object-OrientedDesign）是目前为止公认的可以实现该要求的建模范式。后续文章则将在关注在如何使用面向对象设计来实现领域驱动的相关问题上。抽象出关键的领域知识（名词定义）并支持有效的实现（设计范式），是模型驱动设计的核心二要素。开发人员要意识到代码和模型是整个系统的一体两面，改变代码即意味着改变模型。如果忽略了这一点，到最后模型则将失去指导作用，并逐渐变得不可用。同时，建模人员也应花时间去了解代码。双方通过使用统一领域语言保持模型和实现的一致性。）6） 快速应用开发是一种系统设计方法，是各种结构化技术（特别是数据驱动的信息工程）与原型化技术和联合应用开发技术的结合，用以加速系统的开发。快速应用开发要求反复的使用结构化技术和原型技术来定义用户的需求并设计最终系统。二、软件系统开发中常用的软件架构风格有哪些？详细阐述每种风格的具体含义。软件架构风格分为五大类，数据流风格、调用/返回风格、独立构件风格、虚拟机风格和仓库风格。其中：1） 数据流风格包括了批处理序列架构风格和管道过滤器架构风格2） 调用返回风格包括主程序和子程序架构风格，数据抽象和面向对象架构风格和层次结构架构风格。3） 独立构件风格包括进程通信架构风格和事件驱动架构风格4） 虚拟机风格包括了解释器风格和基于规则的系统5） 仓库风格包括了数据库风格和超文本架构风格，黑板架构风格。其他还有特定领域软件架构，状态转移等以及分布式处理等。其中分布式架构风格中有客户机/服务器风格，浏览器/服务器风格，CORBA,DCOM,EJB。每一种具体的软件结构风格的模型如下：批处理序列架构风格组件为一系列固定顺序的计算单元，组件间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在前一步结束后才能开始，数据必须是完整的，以整体的方式传递。管道过滤器架构风格每个构件都有一组输入和输出。构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常通过计算和增加信息丰富数据，通过浓缩和刪除精炼数据，通过改变记录方式转化数据，递增地转化数据等。在输入被完全消费之前，输出便产生了。这里的构件被称为过滤器，连接件就是数据流传输的管道，将一个过滤器的输出传到另一个过滤器的输入。主程序/子程序架构风格单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制，即充当连接件。调用关系具有层次性，其语义逻辑表现为子程序的正确性取决于它调用的子程序的正确性面向对象架构风格数据抽象和面向对象架构风格。这种风格的构件是对象。对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和它们的相应操作被封装起来。对象的行为体现在其接受和请求的动作。连接件即是对象间交互的方式，对象是通过函数和过程的调用来交互的。对象具有封装性，一个对象的改变不会影响其他对象。对象拥有状态和操作，也有责任维护状态。这种结构风格中包含有封装、交互、多态、集成、重用等特征。层次结构架构风格层次系统组织成一个层次结构。构件在一些层实现了虚拟机。连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束。这个风格的特点是每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。大的问题分解为若干个渐进的小问题，逐步解决，隐藏了很多复杂度。修改一层，最多影响两层，而通常只能影响上层。上层必须知道下层的身份，不能调整层次之间的顺序。进程通宿架构风格构件是独立的过程，连接件是消息传递。这种风格的特点是构件通常是命名过程，消息传递的方式可以是点对点、异步和同步方式、以及远过程调用等。寧件驱动的架构风格构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程的调用。这种风格中的构件是非命名的过程，它们之间交互的连接件往往是以过程之间的隐式调用(Implicitlnvocation)来实现的。基于事件的隐式调用风格的主要优点是为软件重用提供了强大的支持，为构件的维护和演化带来了方便，其缺点是构件放弃了对系统计算的控制。解释器架构风格一个解释器通常包括完成解释工作的解释引擎，一个包含将被解释的代码的存储区，一个记录解释引繁当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用。其缺点是执行效率较低。基于规则的系统基于规则的系统包括规则集、规则解释器、规则/数据选择器以及工作内存数据库架构风格数据库架构是库风格最常见的形式。构件主要有两大类，一个是中央共享数据源，保存当前系统的数据状态，另一个是多个独立处理元素，处理元素对数据元素进行操作。黑板架构风格黑板架构包括知识源、黑板、控制三部分。知识源包括若千独立计算的不同单元，提供解决问题的知识，知识源响应黑板上的变化，也只修改黑板。黑板是一个全局数据库，包含解域的全部状态，是知识源互相作用的唯一媒介。知识源响应是通过黑板状态的变化来控制。黑板通常应用在对于解决问题没有确定性算法的系统中，例如信号处理、问题规划、编译器优化等软件系统的设计中客户/服务器风格C/S体系结构有三个主要组成部分：数据库服务器、客户应用程序和网络。二层C/S结构是单一服务器且以局域网为中心的，所以难以扩展至大型企业广域网或Internet软、硬件的组合及集成能力有限，客户机的负荷太重，难以管理大量的客户机，系统的性能容易变坏，数据安全性不好。三层C/S体系结构是讲应用功能分成表示层、功能层和数据层三个部分，削弱二层C/S结构的局限性。浏览器/服务器风格浏览器/服务器风格就是三层C/S结构的一种实现方式，具体结构为浏览器/Web服务器/数据库服务器。C2风格C2体系结构风格可以概括为，通过连接件绑定在一起按照一组规则运作的并行构件网络。C2架构风格是一种常见的层次体系架构风格。该架构风格概括而言，是由连接件绑定的按一定规则运行的并行构件网络，在该架构风格中，各构件之间不能直接连接，只能通过连接件的异步通信机制进行交互，使得构件的替换或更新不影响架构，这种方式体现了高内聚，松耦合的设计思想。C2风格中的系统组织规则如下：系统中的构件和连接件都有一个顶部和一个底部；构件的顶部应连接到某连接件的底部,构件的底部则应连接到某连接件的顶部；构件与构件之间的直接连接是不允许的；一个连接件可以和任意数目的其他构件和连接件连接；当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。C2架构的缺点：效率低，若业务处理涉及多个构件层次，在系统执行过程中将存在性能损耗。层次不清：难以划分出合适的，正确的层次结构，有时由于需求，需要跨层交互，增加复杂性。三、与传统的企业应用系统相比校，基于无服务器架构的应用系统具有哪些特点，请列举至少3个特点，并进行解释。从功能角度看，基于无服务器架构的应用系统只需要关注业务逻辑实现代码，无须关心承载这些代码的应用服务器如何部署。代码的部署和运维由第三方基础设施管理平台完成。从开发角度看，基于无服务器架构的应用系统不需要考虑特定框架或开发库，从编程语言和环境的角度看更像是一个普通应用。基础设施管理平台负责解释和运行各种语言编写的代码，提供各种异构的运行环境。从部署的角度看，基于无服务器架构的应用系统无须考虑如何部署业务代码，仅需要上传业务代码至基础设施管理平台，由管理平台自动进行服务器选择与代码部署。从运行和扩展的角度看，基于无服务器架构的应用系统业务逻辑运行在无状态的容器中，能够实现弹性、自动的水平扩展。系统开发者仅需要提供基本的并发业务处理功能，当系统面临大量应用请求时，会由基础设施管理平台识别并通过自动提供所需要的无状态、容器化计算环境，并在运行完成后自动释放。从应用模式角度看，基于无服务器架构的应用系统通常采用基于消息机制的事件触发策略，并通过隐式调用模式完成事件响应。首先值得说明的是无服务器架构并不是不再需要服务器，只是开发人员不再需要担心基础设施，因为一切都由云提供商负责。使用这种方法，开发人员只需部署适当的代码，其他一切由云提供商自动管理。在传统的Web应用程序架构中，你必须管理基础架构，并确保其满足可扩展性和安全性需求。例如，客户端在一边，服务器在另一边。客户端发送一个请求，服务器回复响应。但是如果无法满足应用程序需求，则很快就要扩展服务器端了。无服务器模型提供了完全不同的方法。与传统架构不同，无服务器架构在无状态计算容器中运行，这些容器是事件触发的，短暂的（只能持续一次调用），并由第三方完全管理。就像一个黑盒子，这个服务你只需上传代码并实时自动处理。当一个请求进来时，就会运行你的Lambda功能的容器。在成本方面，使用无服务器模型，通常仅支付服务请求和运行代码所需的计算时间。计费以100毫秒为单位进行计量，使其具有成本效益，并且易于自动从每天几个请求到每秒数千次都可以。无服务器架构的优点包括：降低运营成本无服务器架构本质上是一个外包解决方案。基础设施不会消失。然而与常规云服务相比，事实上只需要根据流量规模和形式支付需要的计算量，这可能会大大节省运营成本，特别是对于具有不同变化的早期和动态应用负载要求。可扩展性强可扩展性强在云服务领域并不新鲜，但无服务架构将其提升到一个全新的水平。无服务架构的缩放功能不仅可以降低计算成本，还可以减少运行管理，因为缩放是自动的。使用无服务器，无需明确添加和刪除实例到服务器阵列，并让供应商为你扩展应用程序。由于云计算提供商根据每个请求执行扩展，所以甚至不需要考虑在内存不足之前可以处理多少并发请求问题。分离问题无服务器几乎迫使你实施关注模型的分离，通过该分离将应用程序分成不同的部分，以使每个部分都解决一个单独的问题。隔离进程在无服务器环境中，每个Lambda函数都完全隔离。如果其中一个功能关闭，它不影响其他功能，它不会导致服务器崩溃。无服务器架构的缺点包括：缺乏控制权通过任何外包策略，你都可以将某些系统的控制权给第三方供应商。由于系统停机，意外的限制，成本的变化，功能的丧失，强制的API升级等，这种缺乏控制可能会显现出来。此外，如果需要专门的服务器进行专门的流程，那么必须自己运行这个专门的服务器。一个无服务器架构，在大多数情况下，提供商业化的基础设施，将以广义的方式运行你的流程。长时间运行流程的高成本如果你的进程持续运行很长时间，则可能会需要运行自己的服务器。因为这不仅涉及到成本，还涉及到拥有的技能或者想要投入运行自己的服务器的专注；在评估这些解决方案时,请考虑所有这些方面供应商锁定将基础架构管理完全外包给无服务器提供商，无疑将自己锁定到该供应商每个供应商都有自己的标准和编程框架，不容易改变。在几乎每一种情况下，无论从供应商使用的无服务器功能，将由另一个供应商进行不同的实现。如果要切换供应商，几乎肯定需要更新操作工具（部署，监控等），可能还需要更改代码。四、详细论述软件质量保证中常见的活动有哪些？阐述每个活动的主要内容。软件质量保证活动包含有计划、监督、记录、分析及报告的软件质量保证活动，这些活动往往由一个独立的SQA小组执行。制订SQA计划SQA计划在制定项目计划时制定，它规定了软件开发小组和质量保证小组需要执行的质量保证活动参与开发该软件项目的软件过程描述软件开发小组为将要开展的工作选择软件过程，SQA小组则要评审过程说明，以保证该过程与企业政策、内部的软件标准、外界所制定的标准以及项目开发计划的其他部分相符。评审评审各项软件工程活动，核实其是否符合已定义的软件过程。SQA小组识别、记录和跟踪所有偏离过程的偏差，核实其是否已经改正。审计审计指定的软件工作产品，核实其是否符合已定义的软件过程的相应部分。SQA小组对选出的产品进行评审，识别、记录和跟踪出现的偏差，核实其是否己经改正，定期向项目负责人报告结果。记录并处理偏差确保软件工作及工作产品中的偏差已被记录在案，并根据预定规程进行处理。偏差可能出现在项目计划、过程描述、采用的标准或技术工作产品中报告记录所有不符部分，并向上级管理部门报告。跟踪不符合的部分直到问题得到解决。除了进行上述活动外，SQA小组还需要协调变更的控制与管理，并帮助收集和分析软件度量的信息。2016年一、分析软件系统架构评估中所普遍关注的质量属性有哪些？详细阐述每种质量属性的具体含义。架构所关注的质量属性主要包括：性能、可用性、可修改性、安全性。性能性能是指系统的响应能力，即需要多长时间，才能对某个事件作出响应，或者在某段事件内系统所能处理的事件个数。通常用单位时间内所处理事务的数量或系统完成某个事物处理所需的时间来对性能进行定量表示。可靠性是软件系统在应用或者系统错误面前，在意外或者错误使用的情况下维持软件系统的功能特征的基本能力。可用性可用性是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。安全性安全性是指系统向合法用户提供服务的同时，能够阻止非授权用户使用的企图或拒绝服务的能力。可修改性是指能够快速地以较高的性能价格比对系统进行变更的能力，包括可维护性，可扩展性，结构重构，可移植性。功能性是系统所能完成所期望的工作的能力。一项任务的完成需要系统中，许多或大多数构件的相互协作。可变性是指体系结构经扩充或变更而成为新体系结构的能力。互操作性互操作性是指作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。如程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题现软件评估中的主要评估方法包括SAAM(Scenarios-basedArchitectureAnalysisMethod)和ATAM(ArchitectureTradeoffAnalysisMethod,体系结构权衡分析方法)。SAAM评估方法SAAM的分析和评估目的、评估参与者、评估活动或过程以及评估结果说明如下。评估目的SAAM(Scenario-basedArchitectureAnalysisMethod)目的是验证基本的体系结构假设和原则，评估体系结构固有的风险。SAAM指导对体系结构的检查，使其主要关注潜在的问题点，如需求冲突。SAAM不仅能够评估体系结构对于特定系统需求的使用能力，也能被用来比较不同的体系结构。评估参与者风险承担者、记录人员、软件体系结构设计师。评估活动或过程SAAM分析评估体系结构的过程包括六个步骤，即形成场景、描述体系结构、场景的分类和优先级确定、间接场景的单个评估、场景相互作用的评估、总体评估。评估结果SAAM评估的主要有形输出包括：1） 把代表了未来可能做的更改的场景与构架对应起来，显现出构架中未来可能会表现出较高复杂性的地方，并对每个这样的更改的预期工作量做出评估。2） 理解系统的功能，对多个构架所支持的功能和数量进行比较。如果所评估的是一个框架，SAAM评估将指明框架中未能满足其修改性需求的地方，有时还会指出一种效果更好的设计。SAAM评估也能对两个或者三个备选构架进行比较，明确其中那一个能够较好地满足质量属性需求，而且做的更改较少、不会在未来导致太多的复杂的问题。ATAM评估方法ATAM的分析和评估目的、评估参与者、评估活动或过程以及评估结果说明如下。（1） 评估目的ATAM（ArchitectureTradeoffAnalysisMethod）,即构架权衡分析方法的评估目的是依据系统质量属性和商业需求评估设计决策的结果。ATAM希望揭示出构架满足特定质量目标的情况，使我们更清楚地认识到质量目标之间的联系，即如何权衡多个质量目标。（2） 评估参与者评估小组。该小组是所评估构架项目外部的小组，通常由3、5人组成。该小组的每个成员都要扮演大量的特定角色。他们可能是开发组织内部的，也可能是外部的。项目决策者，对开发项目具有发言权，并有权要求进行某些改变，他们包括项目管理人员，重要的客户代表，构架设计师等。构架涉众（stakeholders）。包括关键模块开发人员、测试人员、用户等。（3） 评估活动或过程整个ATAM评估过程包括九个步骤，按其编号顺序分别是描述ATAM方法、描述商业动机、描述体系结构、确定体系结构方法、生成质量属性效用树、分析体系结构方法、讨论和分级场景、描述评估结果。三、说明常用的软件设计模式有哪几类？阐述每种类型特点及其所包含的设计模式。设计模式分为三种类型：创建型设计模式（4种：工厂模式（工厂模式、抽象工厂模式）、单例模式、原型模式（Prototype）.建造者模式（Bulider））主要用户创建对象；创建模式创对象。工厂模式要抽象；单例只有一个类；原型挎贝创对象；建造复杂的对象。结构型设计模式(8种：代理模式(Proxy)、外观模式(Facade).装饰器模式(Decorator)、享元模式(Flyweight)、组合模式(Composite).适配器模式(Adapter)、桥接模式(Bridge)、过滤器(Criteria))主要关注类和对象的组合；结构型：结构组合类对象。代理外观装饰器；享元组合适配器；桥接不能过滤器。行为型设计模式(11种：模板模式(Template)、策略模式(Strategy)、迭代器模式(Iterator)、中介模式(Mediator)、备忘录模式(Memento)、解释器模式(Interpreter),观察者模式(Observer).访问者模式(Visitor)s状态模式(State)、责任链模式(ChainofResponsibility),命令模式(Command))主要关注对象间通信的问题。父类与子类：策略模式、模板方法模式两个类之间：观察者模式、迭代子模式、职责链模式、命令模式类的状态：备忘录模式、状态模式通过中间类：访问者模式、中介者模式，解释器模式行为对象间通宿。模板策略迭代器，中介备忘解释器，观察访问有状态，责任命令要常记。三、详细论述常见的数据访问层设计技术及其所包含的主要内容。在线访问该模式是基本的数据访问模式，在软件系统中不存在专门的数据访问层，由业务程序直接读取数据，与后台数据源进行交互。DataAccessObject(DAO)DAO模式是标准J2EE设计模式之一，该模式将底层数据访问操作与高层业务逻辑分离开。具体的DAO类包含访问特定数据源数据的逻辑。DataTransferObject(DT0)DTO是经典EJB设计模式之一。DTO本身是一组对象或是数据的容器，它需要跨越不同进程或者网络的边界来传输数据。这类对象通常本身不包括具体的业务逻辑，对象内部仅进行一些诸如内部一致性检查和基本验证之类的方法。离线数据模型是以数据为中心，数据从数据源获取后，将按照某种预定义的结构(如IBMSDO的Data图表结构或ADO.NET中的关系结构)存放在系统中，成为应用的中心。其特点是：离线，数据操作独立于后台数据源；与XML集成，数据可以方便地与XML格式文档相互转换。对象/关系映射(Object/RelationMapping)ORM是一种工具、中间件或平台，它能够帮助将应用程序中的数据转换成关系数据库中的记录；或者是将关系数据库中的记录转换成应用程序中代码便于操作的对象，使得程序员在开发过程中仅仅面对一个对象的概念，降低了对程序员数据库知识的要求，简化了数据库相关的开发工作。数据访问层的技术主要在于数据映射的问题如Hibemate或iBATIS的应用。Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，它将POJO与数据库表建立映射关系，是一个全自动的ORM框架，hibernate可以自动生成SQL语句，自动执行，使得Ja眩程序员可以随心所欲的使用对象编程思维来操纵数据库。Hibernate可以应用在任何使用JDBC的场合，既可以在Java的客户端程序使用，也可以在Servlet/JSP的Web应用中使用，最具革命意义的是，Hibernate可以在应用EJB的J2EE架构中取代CMP,完成数据持久化的重任。iBATIS—词来源于"internet"和"abatis"的组合，是一个由ClintonBegin在2002年发起的开放源代码项目。于2010年6月16号被谷歌托管，改名为MyBatiso是一个基于SQL映射支持Java和.NET的持久层框架Hibernate的调优方案：制定合理的圾存策略；采用合理的Session管理机制；使用批量抓取，设定合理的批处理参数(batch_size)；进行合理的0/R映射设计。尽量使用延迟加载特性；Mybatis调优方案：MyBatis在Session方面和Hibernate的Session生命周期是一致的，同样需要合理的Session管理机制。MyBatis同样具有二级缓存机制。MyBatis可以进行详细的SQL优化设计。四、与单块架构相比较，微服务架构有哪些特点？请列举至少4个特点并进行说明。微服务架构具有如下的特点通过服务实现组件化单个微服务实现简单，能够聚焦一个指定的业务功能或业务需求。功能明确，易于理解微服务能够被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果，并降低沟通成本。围绕业务功能构建开发团队采用微服务架构，可以围绕业务功能构建开发团队，这样更符合企业的分工与组织结构，便于管理。支持多种开发语言与多种平台不同的微服务能使用不同的语言开发，运行在不同的操作系统平台上，通过标准的协议和数据格式进行交互与协作。离散化数据管理在微服务架构中，无法创建或维护统一的数据模型或结构，全局数据模型将在不同的系统之间有所区别，需要进行数据模型的离散化管理。基础设施自动化微服务强调以灵活的方式集成自动部署，通过持续集成工具实现基础设施自动化。微服务的特点追加说明微服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些就应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台使部署、管理和服务功能交付变得更加简单。微服务是利用组织的服务投资组合，然后基于业务领域功能分解它们，在看到服务投资组合之前，它还是一个业务领域。微服务这一概念出现于2012年，是因软件作者MartinFowler而流行，它承认这并没有精确地定义出这一架构形式，虽然围绕业务能力、自动化部署、终端智能以及语言和数据的分散控制有一些常见的特性。开源工作流平台“Imixs-Workflow”发布了一款新的微服务架构，作为工作流来管理解决方案。Imixs的微服务(Imixs-Microservice)提供了一个工作流封装成微服务架构。这一服务可以独立于其背后的技术，绑定到任何业务应用中去。这允许业务应用改变业务逻辑时，不用更改任何代码。这业务目标可以通过工作流模型控制。Imixs的微服务是基于Imixs的工作流引擎(Imixs-WorkflowEngine)的复杂功能构建的，它可以以多种不同的方法来控制业务数据。Imixs的微服务可以发送电子邮件推送消息、日志业务交换，还可以确保所有类型业务数据的安全。Imixs的工作流模型可以给业务处理模型(Imixs-WorkflowModeller)中的每种状态单独的设计一个ACL。这许可了高度复杂的业务应用程序，并在每个流程实例周围驻起了安全层。2015年一、 论述并分析应用服务器在软件设计、开发、部署、运行和管理阶段，应该提供哪些核心功能？应用服务器是应用设计、开发、部署、运行、管理、维护的平台。应用服务器既是应用开发的平台，包括表示层、应用层和数据层的设计模式和编程环境；同时又是多层结构应用的部署、运行平台，对多层结构应用进行配置、启动、监控、调整，并在开发的不同阶段提供不同的功能设计阶段应用服务器完成底层通信、服务，并屏蔽掉复杂的底层技术细节，向用户提供结构简单、功能完善的编程接口，让用户可以专心于商务逻辑的设计。.开发阶段应用服务器提供了完全开放的编程语言和应用接口，同时也提供快速开发的工具和手段,帮助用户提高开发效率。.部署阶段应用服务器提供了对多种网络环境的支持，帮助用户在复杂的网络环境中配置系统参数,发挥系统最大性能。运行阶段应用服务器基于开发技术标准，提供了系统的运行环境，提供了系统的名字解析、路由选择、负载平衡、事务控制等服务，并提供系统容错、修正、迁移、升级扩展等功能。管理阶段应用服务器提供图形化界面来管理整个系统的资源，而且系统在运行期间也能动态监控和管理。二、 分析软件系统开发中常用的软件系统架构风格有哪些？详细阐述每种风格的具体含义。（注意本