宁国做网站,制作网站要求,网站版面设计,wordpress加js1、软件架构演化
软件架构的演化和维护的目的是为了使软件能够适应环境的变化而进行的纠错性修改和完善性修改。软件架构的演化和维护过程是一个不断迭代的过程#xff0c;通过演化和维护#xff0c;软件架构逐步得到完善#xff0c;以满足用户需求。软件架构的演化就是软件…1、软件架构演化
软件架构的演化和维护的目的是为了使软件能够适应环境的变化而进行的纠错性修改和完善性修改。软件架构的演化和维护过程是一个不断迭代的过程通过演化和维护软件架构逐步得到完善以满足用户需求。软件架构的演化就是软件整体结构的演化演化过程涵盖软件架构的全生命周期包括软件架构需求的获取、软件架构建模、软件架构文档、软件架构实现以及软件架构维护等阶段。所以人们通常说软件架构是演化来的而不是设计来的。
软件架构定义是SA{组件连接件约束}这类软件架构演化主要关注的就是组件、连接件和约束的添加、修改与删除等。
组件是软件架构的基本要素和结构单元表示系统中主要的计算元素、数据存储以及一些重要模块当需要消除软件架构存在的缺陷、新增功能、适应新的环境时都涉及组件的演化。组件的演化体现在组件中模块的增加、删除或修改。连接件是组件间的交互关系多数情况下组件的演化牵涉到连接件的演化。连接件的演化体现在组件交互消息的增加、删除或改变。约束是组件和连接件之间的拓扑关系和配置它为组件和连接件提供额外数据支撑可以是架构的约束数据或架构的参数。
软件架构演化典型的分类方法:
(1)按照软件架构的实现方式和实施粒度分类基于过程和函数的演化、面向对象的演化、基于组件的演化和基于架构的演化。
(2)按照研究方法将软件架构演化方式分为4类第1类是对演化的支持如代码模块化的准则、可维护性的支持(如内聚和耦合)、代码重构等第2类是版本和工程的管理工具如CVS 和COCOMO第3类是架构变换的形式方法包括系统结构和行为变换的模型以及架构演化的重现风格等第4类是架构演化的成本收益分析决定如何增加系统的弹性。
(3)针对软件架构的演化过程是否处于系统运行时期将软架构演化分为静态演化和动态演化 。
静态演化发生在软件架构的设计、实现和维护过程中软件系统还未运行或者处在运行停止状态。动态演化发生在软件系统运行过程中
软件架构演化时期 1.设计时演化 设计时演化是指发生在体系结构模型和与之相关的代码编译之前的软件架构演化。 2.运行前演化 运行前演化是指发生在编译之后、执行之前的软件架构演化这时由于应用程序并未执行修改时不用考虑应用程序的状态但需要考虑系统的体系结构且系统需要具有添加和删除组件的机制。 3.有限制运行时演化 有限制运行时演化是指系统在设计时就规定了演化的具体条件将系统置于“安全”模式下演化只发生在某些特定约束满足时可以进行一些规定好的演化操作。 4.运行时演化 运行时演化是指系统的体系结构在运行时不能满足要求时发生的软件架构演化包括添加组件、删除组件、升级替换组件、改变体系结构的拓扑结构等。此时的演化是最难实现的。
软件架构静态演化 1.静态演化需求 软件架构静态演化的需求是广泛存在的可归结为两个方面。 (1)设计时演化需求。在架构开发和实现过程中对原有架构进行调整保证软件实现与架构的一致性以及软件开发过程的顺利进行。 (2)运行前演化需求。软件发布之后由于运行环境的变化需要对软件进行修改升级在此期间软件的架构同样要进行演化。
2.静态演化的一般过程 软件静态演化是系统停止运行期间的修改和更新即一般意义上的软件修复和升级。与此时相对应的维护方法有三类更正性维 护、适应性维护、完善性维护。
软件的静态演化包括如下 5 个步骤
软件理解查阅软件文档分析软件架构识别系统组成元素及其之间的相互关系提取系统的抽象表示形式。需求变更分析静态演化往往是由于用户需求变化、系统运行出错和运行环境发生改变等原因所引起的需要找出新的软件需求与原有的差异。演化计划分析原系统确定演化范围和成本选择合适的演化计划。系统重构根据演化计划对系统进行重构使之适应当前的需求。系统测试对演化后的系统进行测试查找其中的错误和不足。
软件架构动态演化 动态演化是在系统运行期间的演化在不停止系统功能的情况下完成演化较之静态演化更加困难。具体发生在有限制的运行时演化和运行时演化阶段。
1.动态演化的类型 1)软件动态性的等级 软件的动态性分为3 个级别
交互动态性要求数据在固定的结构下动态交互。结构动态性允许对结构进行修改通常形式是组件和连接件实例的添加和删除这种动态性是研究和应用的主流。架构动态性允许软件架构的基本构造变动即结构可以被重定义如新的组件类型的定义。
2)动态演化的内容 根据所修改的内容不同软件的动态演化包括以下 4 个方面
属性改名目前所有的ADL都支持对非功能属性的分析和规约而在运行过程中用户可能会对这些指标进行重新定义(如服务响应时间)。行为变化在运行过程中用户需求变化或系统自身服务质量的调节都将引发软件行为的变化。如为了提高安全级别而更换加密算法将HTTP协议改为HTTPS协议。拓扑结构改变如增删组件增删连接件改变组件与连接件之间的关联关系等。风格变化一般软件演化后其架构风格应当保持不变如果非要改变软件的架构风格也只能将架构风格变为衍生风格。如将两层C/S结构调整为三层C/S结构等。
2、软件架构演化原则
架构演化原则 列举 18 种软件架构可持续演化原则并针对每个原则设计了相应的度量方案。每个方案都能紧抓该原则的本质做到从架构方面提供有价值的信息帮助对架构进行有效观察。
1.演化成本控制原则
原则名称演化成本控制 (ECC)原则。原则解释演化成本要控制在预期的范围之内也就是演化成本要明显小于重新开发成本。原则用途用于判断架构演化的成本是否在可控范围内以及用户是否可接受。度量方案CoECoRD。方案说明CoE为演化成本CoRD为重新开发成本CoE远小于CoRD最佳。
2.进度可控原则
原则名称进度可控原则。原则解释架构演化要在预期时间内完成也就是时间可控。原则用途根据该原则可以规划每个演化过程的任务量体现一种迭代、递增(持续演化)的演化思想。度量方案:ttask|Ttask-T’task|。方案说明某个演化任务的实际完成时间 (Ttask) 和预期完成时间 (T’task)的时间差ttask越小越好。
3.风险可控原则
原则名称风险可控原则。原则解释架构演化过程中的经济风险、时间风险、人力风险、技术风险和环境风险等必须在可控范围内。原则用途用于判断架构演化过程中各种风险是否易于控制。度量方案分别检验。方案说明时间风险、经济风险、人力风险、技术风险都不存在。
4.主体维持原则
原则名称主体维持原则原则解释对称稳定增长(AIG)原则所有其他因素须与软件演化协调开发人员、销售人员、用户必须熟悉软件演化的内容从而达到令人满意的演化。因此软件演化的平均增量的增长须保持平稳保证软件系统主体行为稳定。原则用途用于判断架构演化是否导致系统主体行为不稳定。度量方案计算AIG即可AIG主体规模的变更量/主体的规模。方案说明根据度量动态变更信息(类型、总量、范围) 来计算。
5.系统总体结构优化原则
原则名称系统总体结构优化原则。原则解释架构演化要遵循系统总体结构优化原则使得演化之后的软件系统整体结构(布局)更加合理。原则用途用于判断系统整体结构是否合理是否最优。度量方案检查系统的整体可靠性和性能指标。方案说明判断整体结构优劣的主要指标是系统的可靠性和性能。
6.平滑演化原则
原则名称平滑演化(IWR)原则原则解释在软件系统的生命周期里软件的演化速率趋于稳定如相邻版本的更新率相对固定。原则用途用于判断是否存在剧烈架构演化。度量方案计算IWR即可IWR变更总量/项目规模。方案说明根据度量动态变更信息 (类型、总量、范围等) 来计算。
7.目标一致原则
原则名称目标一致原则原则解释架构演化的阶段目标和最终目标要一致。原则用途用于判断每个演化过程是否达到阶段目标所有演化过程结束是否能达到最终目标。度量方案otask|Otask-O’task|。方案说明阶段目标的实际达成情况 (Otask) 和预期目标(O’task)的差otask越小越好。
8.模块独立演化原则
原则名称模块独立演化原则或修改局部化原则。原则解释软件中各模块(相同制品的模块如Java的某个类或包)自身的演化最好相互独立或者至少保证对其他模块的影响比较小或影响范围比较小。原则用途用于判断每个模块自身的演化是否相互独立。度量方案检查模块的修改是否是局部的。方案说明可以通过计算修改的影响范围来进行度量。
9.影响可控原则
原则名称影响可控原则。原则解释软件中一个模块如果发生变更其给其他模块带来的影响要在可控范围内也就是影响范围可预测。原则用途用于判断是否存在对某个模块的修改导致大量其他修改的情况。度量方案检查影响的范围是否可控。方案说明通过计算修改的影响范围来进行度量。
10.复杂性可控原则
原则名称复杂性可控(CC)原则。原则解释架构演化必须要控制架构的复杂性从而进一步保障软件的复杂性在可控范围内。原则用途用于判断演化之后的架构是否易维护、易扩展、易分析、易测试等。度量方案CC小于某个阈值。方案说明CC增长可控。
11.有利于重构原则
原则名称有利于重构原则。原则解释架构演化要遵循有利于重构原则使得演化之后的软件架构更方便重构。原则用途用于判断架构易重构性是否得到提高。度量方案检查系统的复杂度指标。方案说明系统越复杂越不容易重构。
12.有利于重用原则
原则名称有利于重用原则。原则解释架构演化最好能维持甚至提高整体架构的可重用性。原则用途用于判断整体架构可重用性是否遭到破坏。度量方案检查模块自身的内聚度、模块之间的耦合度。方案说明模块的内聚度越高该模块与其他模块之间的耦合度越低越容易重用。
13.设计原则遵从性原则
原则名称设计原则遵从性原则。原则解释架构演化最好不能与架构设计原则冲突。原则用途用于判断架构设计原则是否遭到破坏(架构设计原则是好的设计经验总结要保障其得到充分使用)。度量方案RCP|CDP| / |DP|。方案说明冲突的设计原则集合 (CDP) 和总的设计原则集合(DP)的比较RCP越小越好。
14.适应新技术原则
原则名称适应新技术(TI) 原则。原则解释软件要独立于特定的技术手段这样才能够让软件运行于不同平台。原则用途用于判断架构演化是否存在对某种技术依赖过强的情况。度量方案TI1-DDTDDT|依赖的技术集合|/|用到的技术合集|。方案说明根据演化系统对关键技术的依赖程度进行度量。
15.环境适应性原则
原则名称环境适应性原则。原则解释架构演化后的软件版本能够比较容易适应新的硬件环境与软件环境。原则用途用于判断架构在不同环境下是否仍然可使用或者容易进行环境配置。度量方案硬件/软件兼容性。方案说明结合软件质量中兼容性指标进行度量。
16.标准依从性原则
原则名称标准依从性原则。原则解释架构演化不会违背相关质量标准(国际标准、国家标准、行业标准、企业标准等)。原则用途用于判断架构演化是否具有规范性是否有章可循而不是胡乱或随意地演化。度量方案需要人工判定。
17.质量向好原则
原则名称质量向好(QI)原则。原则解释通过演化使得所关注的某个质量指标或某些质量指标的综合效果变得更好或者更满意例如可靠性提高了。原则用途用于判断架构演化是否导致某些质量指标变得很差。度量方案EQISQ。方案说明演化之后的质量(EQI) 比原来的质量(SQ) 要好。
18.适应新需求原则
原则名称适应新需求原则。原则解释架构演化要容易适应新的需求变更架构演化不能降低原有架构适应新需求的能力架构演化最好可以提高适应新需求的能力。原则用途用于判断演化之后的架构是否降低了架构适应新需求的能力。度量方案RNR|ANR|/|NR|。方案说明适应的新需求集合 (ANR) 和实际新需求集合 (NR)的比较RNR越小越好。
3、软件架构演化评估方法
根据演化过程是否已知可将评估过程分为:
演化过程已知的评估演化过程未知的评估
演化过程已知的评估 演化过程已知的评估其目的在于通过对架构演化过程进行度量比较架构内部结构上的差异以及由此导致的外部质量属性上的变化对该演化过程中相关质量属性进行评估。涉及评估流程以及具体的相关指标的计算方法。
1.评估流程 架构演化评估的基本思路是将架构度量应用到演化过程中通过对演化前后的不同版本的架构分别进行度量得到度量结果的差值及其变化趋势并计算架构间质量属性距离进而对相关质量属性进行评估。
2.架构演化中间版本度量 对于不同类型的质量属性其度量方法不同度量结果的类型也不同。本章主要度量的是架构的可维护性和可靠性。
对于可靠性度量结果是一个实数值。对于可维护性它包含圈复杂度、扇入扇出度、模块间耦合度、模块的响应、紧内聚度、松内聚度等 6个子度量指标。通过比较原子演化前后架构质量属性 Qi-1和Qi间的变化可以分析该类演化对评估系统的外部质量属性的影响进而找出架构内部结构变化和外部质量属性变化间的关联。
演化过程未知的评估 演化过程未知时我们无法像演化过程已知时那样追踪架构在演化过程中的每一步变化只能根据架构演化前后的度量结果逆向推测出架构发生了哪些改变并分析这些改变与架构相关质量属性的关联关系。
大型网站系统架构演化实例
第一阶段: 单体架构 小型网站最开始没有太多人访问只需要一台服务器就绰绰有余这时网站的应用程序、数据库、文件等所有资源都在一台服务器上。
第二阶段: 垂直架构 将应用和数据分离整个网站使用 3 台服务器的应用服务器、文件服务器和数据库服务器。
应用服务器处理大量的业务逻辑因此需要更快更强大的处理器速度。数据库服务器需要快速磁盘检索和数据缓存因此需要更快的磁盘和更大的内存。文件服务器需要存储大量用户上传的文件因此需要更大容量的硬盘。
第三阶段: 使用缓存改善网站性能 把经常访问的小部分数据缓存在内存中可以减少数据库的访问压力提高整个网站的数据访问速度改善数据库的写入性能。 网站使用的缓存可分为两种
缓存在应用服务器上的本地缓存缓存在专门的分布式缓存服务器上的远程缓存
使用缓存后数据访问压力得到有效缓解但是单一应用服务器能够处理的请求连接有限在网站访问高峰期应用服务器成为整个网站的瓶颈。
第四阶段: 使用服务集群改善网站并发处理能力 通过增加服务器的方式改善负载压力、提高系统性能从而实现系统的可伸缩性。应用服务器集群是网站可伸缩架构设计中较为简单成熟的一种。
第五阶段: 数据库读写分离 在网站的用户达到一定规模后数据库因为负载压力过高而成为网站的瓶颈。目前的主流数据库提供主从热备功能通过配置两台数据库主从关系可以将一台数据库服务器的数据更新同步另一台服务器上。网站利用数据库的这一功能实现数据库读写分离从而改善数据库负载压力。 应用服务器在写数据的时候访问主数据库主数据库通过主从复制(同步)机制将数据更新同步到从数据库这样当应用服务器读数据的时候就可以通过从数据库获得数据。
第六阶段: 使用反向代理和 CDN 加速网站响应 随着网站业务不断发展用户规模越来越大由于区域的差别使得网络环境异常复杂不同地区的用户访问网站时速度差别也 极大。为了更好的用户体验网站需要加速网站访问速度。主要手段有使用CDN 和反向代理。CDN和反向代理的基本原理都是缓存。
CDN部署在网络提供商的机房使用户在请求网站服务时可以从距离自己最近的网络提供商机房获取数据。反向代理部署在网站的中心机房当用户请求到达中心机房后首先访问的服务器是反向代理服务器如果反向代理服务器中缓存着用户请求的资源就将其直接返回给用户。
第七阶段: 使用分布式文件系统和分布式数据库系统 任何强大的单一服务器都满足不了大型网站持续增长的业务需求。数据库经过读写分离后一台服务器拆分成两台服务器但是随着网站业务的发展依然不能满足需求这时需要使用分布式数据库。文件系统也一样需要使用分布式文件系统。分布式数据库是网站数据库拆分最后手段只有在单表数据规模非常庞大的时候才使用。不到不得已时网站更常用的数据库拆分手段是业务分库将不同业务的数据部署在不同的物理服务器上。
第八阶段: 使用NoSQL和搜索引擎 随着网站业务越来越复杂对数据存储和检索的需求也越来越复杂网站需要采用一些非关系数据库技术如 NoSQL 和非数据库查询技术如搜索引擎。NoSQL 和搜索引擎都是源自互联网的技术手段对可伸缩的分布式特性具有更好的支持。应用服务器则通过一个统一数据访问模块访问各种数据减轻应用程序管理诸多数据源的麻烦。
第九阶段: 业务拆分 大型网站为了应对日益复杂的业务场景通过使用分而治之的手段将整个网站业务分成不同的产品线。如电商网站都会将首页、商铺、订单、买家、卖家等拆分成不同的产品线分归不同的业务团队负责。具体到技术上也会根据产品线划分将一个网站拆分成许多不同的应用每个应用独立部署。应用之间可以通过一个超链接建立关系也可以通过消息队列进行数据分发当然最多的还是通过访问同一个数据存储系统来构成一个完整系统。
第十阶段: 分布式服务 随着业务拆分越来越小存储系统越来越庞大应用系统的整体复杂度呈指数级增加部署维护越来越困难。由于所有应用要和所有数据库系统连接在数万台服务器规模的网站中这些连接的数目是服务器规模的平方导致数据库连接资源不足拒绝服务。既然每一个应用系统都需要执行许多相同的业务操作比如用户管理、商品管理等那么可以将这些共用的业务提取出来独立部署。由这些可复用的业务连接数据库提供共用业务服务而应用系统只需要管理用户界面通过分布式服务调用共用业务服务完成具体业务操作。
4、软件架构维护
软件架构是软件开发和维护过程中的一个重点制品是软件需求和设计、实现之间的桥梁。软件架构的维护与演化密不可分维护需要对软件架构的演化过程进行追踪和控制以保障软件架构的演化过程能够满足需求(亦有说法将架构维护作为架构演化的一部分)。 由于软件架构维护过程一般涉及架构知识管理、架构修改管理和架构版本管理等内容下面分别对它们进行介绍。
软件架构知识管理 软件架构知识管理是对架构设计中所隐含的决策来源进行文档化表示进而在架构维护过程中帮助维护人员对架构的修改进行完善的考虑并能够为其他软件架构的相关活动提供参考。
1.架构知识的定义 架构知识 架构设计 架构设计决策。
2.架构知识管理的含义 架构知识管理侧重于软件开发和实现过程所涉及的架构静态演化从架构文档等信息来源中捕捉架构知识进而提供架构的质量属性及其设计依据以进行记录和评价
软件架构修改管理 在软件架构修改管理中一个主要的做法就是建立一个隔离区域保障该区域中任何修改对其他部分的影响比较小甚至没有影响。为此需要明确修改规则、修改类型以及可能的影响范围和副作用等。
软件架构版本管理 软件架构版本管理为软件架构演化的版本演化控制、使用和评价等提供了可靠的依据并为架构演化量化度量奠定了基础。
软件架构可维护性度量实践 架构可维护性的六个子度量指标
1.圈复杂度(CCN)2.扇入扇出度(FFC)3.模块间耦合度(CBO)4.模块的响应(RFC)5.紧内聚度TCC6.松内聚度LCC
1.圈复杂度(CCN) 由于在组件图中组件是独立的每个组件代表一个系统或子系统中的封装单位封装了完整的事务处理行为组件图能够通过组件之间的控制依赖关系来体现整个系统的组成结构。对架构的组件图进行圈复杂度的度量可以对整个系统的复杂程度做出初步评估在设计早期发现问题和做出调整并预测待评估系统的测试复杂度及早规避风险提高软件质量。实践表明程序规模以 CCN≤10为宜。
2.扇入扇出度(FFC) 扇入是指直接调用该模块的上级模块的个数扇出指该模块直接调用的下级模块的个数。用扇入扇出度综合评估组件主动调用以及被调用的频率。扇入扇出度越大表明该组件与其他组件间的接口关联或依赖关联越多。
3.模块间耦合度(CBO) 模块间耦合度CBO度量模块与其他模块交互的频繁程度。组件与其他组件的依赖关系及接口越多该组件的耦合度越大。CBO 越大的模块越容易受到其他模块修改和错误的影响因而可维护性越差风险越高。
4.模块的响应(RFC) RFC度量组件执行所需的功能的数量包括接口提供的功能、依赖的其他模块提供的功能以及子模块提供的功能。
5.模块间内聚度–紧内聚度TCC和松内聚度LCC 内聚度是模块内部各成份之间的联系紧密程度联系越紧其内聚度越大。好的架构设计应该遵循高内聚-低耦合原则提高模块的独立性降低模块间接口调用的复杂性。 公式如下
todo 对公式进行解释
