制作一个网站步骤国外 优秀网站设计

当前位置： 首页 > news >正文

制作一个网站步骤,国外 优秀网站设计,最新新闻热点事件2022年9月,网站备案流程实名认证1 软件架构的概念 一个程序和计算系统软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件#xff0c;构件 的外部可见属性以及它们之间的相互关系。 体系结构并非可运行软件。确切地说#xff0c;它是一种表达#xff0c;使软件工程师能够#xff1a; (1)分…1 软件架构的概念 一个程序和计算系统软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件构件 的外部可见属性以及它们之间的相互关系。 体系结构并非可运行软件。确切地说它是一种表达使软件工程师能够 (1)分析设计在满足所规定的需求方面的有效性 (2)在设计变更相对容易的阶段考虑体系结构可能的选择方案 (3)降低与软件构造相关联的风险。 上面的定义强调在任意体系结构的表述中“软件构件”的角色。软件构件简单到可以是程序模块或者面向对象的类也可以扩充到包含数据库和能够完成客户与服务器网络配置的“中间件”。 软件体系结构的设计两个层次数据设计和体系结构设计。 数据设计‌主要关注于系统中数据的组织和存储方式包括数据库、数据文件和全局数据结构的定义。数据设计体现传统系统中体系结构的数据构件和面向对象系统中类的定义(封装了属性和操作)。数据设计是软件体系结构设计中非常重要的一部分因为它直接影响到系统的数据处理能力和效率体系结构设计则主要关注软件构件的结构、属性和交互作用。确定各子系统模块间的数据传递与调用关系以及模块间、系统与外部系统的接口关系。体系结构设计是软件架构的核心它决定了软件系统的整体结构和行为对系统的性能、可靠性、安全性和易维护性等方面有着直接的影响 软件架构设计与生命周期
1.需求分析阶段。 需求分析和SA设计(系统设计)面临的是不同的对象一个是问题空间另一个是解空间。 从软件需求模型向SA模型的转换主要关注两个问题如何根据需求模型 构建SA模型 。如何保证模型转换的 可追踪性 。 2.设计阶段。 是SA 研究关注的最早和最多的阶段这一阶段的SA研究主要包括 SA 模型的描述、SA 模型的设计与分析方法以及对 SA设计经验的总结与复用等。 有关SA 模型描述的研究分为3个层次 SA的基本概念(构件和连接子)——-这一层次主要涉及SA模型由哪些元素组成以及这些组成元素之间按照何种原则组织。SA模型的基本构成元素包括构件和连接子这些元素是构建系统架构的基础。体系结构描述语言ADL——-ADL是一种支持构件、连接子及其配置的描述语言。它提供了标准化和形式化的方式来描述系统架构使得不同背景的开发者能够更容易地理解和交流。常见的ADL包括UniCon、Rapide、Darwin、Wright、C2 SADL、Acme、xADL、XYZ/ADL和ABC/ADL等SA模型的多视图表示——-从不同的视角描述特定系统的体系结构从而得到多个视角并将这些视图组织起来用来描述整体的SA模型。这种多视图表示方法能够全面地反映系统的各个方面确保在设计过程中不会遗漏任何重要的信息或功能 3.实现阶段。 最初 SA 研究往往只关注较高层次的系统设计、描述和验证。为了有效实现 SA设计向实现的转换实现阶段的体系结构研究表现在以下几个方面。 (1)研究基于SA 的开发过程支持如项目组织结构、配置管理等。 (2)寻求从 SA 向实现过渡的途径如将程序设计语言元素引入 SA 阶段、模型映射、构件组装、复用中间件平台等。(3)研究基于 SA 的测试技术。
4.构件组装阶段。 在SA设计模型的指导下可复用构件的组装可以在较高层次上实现系统并能够提高系统实现的效率。在构件组装的过程中SA 设计模型起到了系统蓝图的作用。研究内容包括如下两个方面。 (1)如何支持可复用构件的互联即对 SA 设计模型中规约的连接子的实现提供支持。 (2)在组装过程中如何检测并消除体系结构失配问题。 在构件组装阶段的失配问题主要包括 由构件引起的失配、由连接子引起的失配、由于系统成分对全局体系结构的假设存在冲突引起的失配等。 5.部署阶段。 SA 对软件部署作用如下。 (1)提供高层的体系结构视图来描述部署阶段的软硬件模型。 (2)基于SA 模型可以分析部署方案的质量属性从而选择合理的部署方案。 6.后开发阶段。 是指软件部署安装之后的阶段。这一阶段的 SA 研究主要围绕维护、演化、复用等方面来进行。典型的研究方向包括动态软件体系结构、体系结构恢复与重建等。 (1)动态软件体系结构。现实中的软件具有动态性体系结构会在运行时发生改变。 运行时变化包括两类软件内部执行所导致的体系结构改变软件系统外部的请求对软件进行的 重配置。 包括两个部分的研究体系结构设计阶段的支持、运行时刻基础设施的支持。   (2)体系结构恢复与重建。对于现有系统在开发时候没有考虑 SA的情况从这些系统中恢复或重购体系结构。从已有的系统中获取体系结构的重建方法分为4类手工体系结构重建、工具支持的手工重建、通过查询语言来自动建立聚集、使用其他技术(如数据挖掘等)。   架构设计概述 从需求分析到软件设计之间的过渡过程称为软件架构 。只要软件架构设计好了整个软件就不会出现坍塌性的错误即不会崩溃。   架构设计就是需求分配将满足需求的职责分配到组件上 。   软件架构为软件系统提供了一个 结构、行为和属性的高级抽象 由 构件 的 描述 、构件的 相互作用 (连接件)、指导构件 集成的模式 以及这些模式的 约束 组成。   软件架构不仅指定了系统的 组织结构和拓扑结构 并且显示了系统 需求和构件 之间的 对应关系 提供了一些 设计决策的基本原理 。   解决好软件的复用、质量和维护问题是研究软件架构的根本目的。   软件架构设计包括 提出 架构 模型 产生 架构 设计 和进行 设计评审 等活动是一个迭代的过程。架构设计主要关注软件组件的结构、属性和交互作用并通过多种视图全面描述特定系统的架构。 补充 迭代和‌演化的定义‌‌ ‌迭代‌是一种软件开发过程它通过一系列的迭代周期来逐步构建软件。每个迭代周期包括需求分析、设计、实现、测试和集成等阶段通过反馈和调整来不断完善软件。‌演化‌模型也是一种全局的软件生存周期模型属于迭代开发方法的一种。它通过快速分析构造出软件的初始版本根据用户反馈进行改进最终得到满意的软件产品。 ‌迭代和演化的区别‌ 迭代和演化在软件开发过程中有所不同。迭代更注重每个阶段的逐步完善通过多次迭代来达到最终目标。而演化则更注重从用户反馈中不断改进通过快速原型构建和使用反馈来逐步完善软件。 ‌实例说明‌ 例如在一个软件开发项目中如果需求不明确可以使用‌演化模型来快速构建原型通过用户反馈来逐步明确需求并进行调整。如果需求已经明确但需要逐步完善功能则可以使用迭代模型通过多次迭代来逐步实现每个功能模块。 迭代和‌递归是两种常见的解决问题的方法它们在实现和思维方式上有一些区别。以下是迭代和递归的主要区别 ‌定义和结构‌ ‌迭代‌通过循环结构重复执行一段代码每次迭代的结果会作为下一次迭代的初始值直到满足结束条件。迭代是环结构从初始状态开始每次迭代都遍历这个环并更新状态多次迭代直到到达结束状态。‌‌递归‌函数直接或间接调用函数自身直到满足终止条件再逐层回归。递归是树结构从字面可以理解为重复“递推”和“回归”的过程当“递推”到达底部时就会开始“回归”其过程相当于树的深度优先遍历。‌ ‌时间复杂度‌ ‌迭代‌迭代的时间复杂度可以通过查找循环内重复的周期数来发现。在实际应用中迭代的效率通常高于递归尤其是在循环次数较大时。‌‌递归‌递归的时间复杂度可以通过根据前面的调用查找第n个递归调用的值来查找。递归的时间复杂度可能会呈指数级增长尤其是在有大量递归调用时。‌ ‌效率‌ ‌迭代‌通常在循环次数较大时迭代的效率明显高于递归因为递归涉及函数调用的开销。‌‌递归‌虽然代码长度较小但由于函数调用的开销当递归调用次数较多时效率较低。 ‌应用场景‌ ‌迭代‌适用于当问题可以通过简单的循环结构解决的情况如数组遍历、累加等。‌递归‌适用于问题可以分解为多个相似子问题的情况如树的遍历、图的搜索等。 ‌无限重复的后果‌ ‌迭代‌如果终止条件设置不当可能导致无限循环。‌递归‌如果基本情况设置不当可能导致无限递归调用最终可能导致系统崩溃。 综上所述选择迭代还是递归取决于具体问题的性质和需求。迭代通常适用于简单的循环任务而递归适用于可以分解为多个相似子问题的任务。在实际应用中应根据问题的特点和需求来选择合适的方法    架构设计作用 软件架构能够在设计变更相对容易的阶段考虑系统结构的可选方案便于技术人员与非技术人员就软件设计进行交互能够展现软件的结构、属性与内部交互关系。   软件架构是项目干系人进行交流的手段明确了对系统实现的约束条件决定了开发和维护组织的组织结构制约着系统的质量属性。   软件架构使推理和控制的更改更加简单有助于循序渐进的原型设计可以作为培训的基础。   软件架构是可传递和可复用的模型通过研究软件架构可能预测软件的质量。 构件 构件是一个独立可交付的功能单元外界通过接口访问其提供的服务。   构件由一组通常需要同时部署的原子构件组成。一个原子构件是一个模块和一组资源。原子构件是部署、版本控制和替换的基本单位。原子构件通常成组地部署但是它也能够被单独部署。   构件和原子构件之间的区别在于大多数原子构件永远都不会被单独部署尽管它们可以被单独部署。相反大多数原子构件都属于一个构件家族一次部署往往涉及整个家族。   一个模块是不带单独资源的原子构件(在这个严格定义下Java 包不是模块——在 Java 中部署的原子单元是类文件。一个单独的包被编译成多个单独的类文件——每个公共类都有一个)。 模块是一组类和可能的非面向对象的结构体比如过程或者函数。    构件和对象 构件的特性是 (1)独立部署单元(2)作为第三方的组装单元(3)没有(外部的)可见状态。一个构件可以包含多个类元素但是一个类元素只能属于一个构件。将一个类拆分进行部署通常没什么意义。   对象的特性是 (1)一个实例单元具有唯一的标志。(2)可能具有状态此状态外部可见。 (3)封装了自己的状态和行为。 构件接口 接口标准化是对接口中消息的格式、模式和协议的标准化。它不是要将接口格式化为参数化操作的 集合而是关注输入输出的消息的标准化它强调当机器在网络中互连时标准的消息模式、格式、协议的重要性。 面向构件的编程(COP) 关注于如何支持建立面向构件的解决方案。面向构件的编程需要下列基本的支持 ——多态性(可替代性); ——模块封装性(高层次信息的隐藏); ——后期的绑定和装载(部署独立性); ——安全性(类型和模块安全性)。 2 基于架构的软件开发方法 ABSD 方法是架构驱动强调由业务、质量和功能需求的组合驱动架构设计。它强调采用视角和 视图来描述软件架构采用用例和质量属性场景来描述需求。进一步来说用例描述的是功能需求质量属性场景描述的是质量需求(或侧重于非功能需求)。 总结 – ABSD就叫基于架构的软件开发方法当然是架构驱动的架构设计呢在这里又是由业务、质量和功能需求的组合来驱动的。 – 用视角和视图来描述软件的架构用用例和质量属性场景来描述需求。 – 用例描述功能质量属性场景描述质量。 使用 ABSD方法设计活动可以从项目总体功能框架明确就开始这意味着需求获取和分析还没 有完成就开始了软件设计。– 意味着需求分析还没完成就可以开始了提前到需求分析了。 ABSD 方法有三个基础。 第一个基础是功能的分解使用已有的基于模块的内聚和耦合技术第二个基础是通过选择架构风格来实现质量和业务需求第三个基础是软件模板的使用软件模板利用了一些软件系统的结构。 ABSD的实现需要由3个基础/前提 使用内聚和耦合技术进行功能的分解功能模块化选择合适的架构风格要照顾到业务(功能)需求和质量(性能)需求利用一些现成的软件模板里面有现成的系统的结构可利用。 ABSD 方法是 递归的且迭代的每一个步骤都是清晰定义的 。因此 不管设计是否完成架构总 是清晰的 有助于降低架构设计的随意性。 开发过程 架构设计是在需求分析之后概要设计之前是为了解决需求分析和软件设计之间的鸿沟问题。 基于架构的软件开发过程可分为下列六步 基于ABSD的开发过程 需求是第一步获取、整理、分析需求得把需求确定了第二步是设计提出模型设计各功能模块(构件)及相互联系(连接件)等等第三步是文档化前面的设计的功能模块(构件、连接件)毕竟不是真正实现的代码只是文档上的内容所以要把这些东西以及架构相关的所有信息文档化第四步复审文档化后还要拉一群人来开会一起讨论这些设计是否合理和存在不足等等。复审不合格的打回去重新设计修改文档再复审直到大家意见一致。第五步实现复审都通过那就着手实现吧根据文档来分析设计构件以及他们之间的调用关系有现成的就用没现成的就开发测试。第六步演化上一步已经实现了并测试完成了但是后期需要维护的比如提出新需求环境变化业务改变这就需要演化来满足这些变化。演化是从需求开始重新走一遍。 架构需求重在掌握标识构件的三步如下左图。 架构需求过程详细步骤 1.获取需求从库里获取还是用户获取都可以整理合并分类、形成文档(SRS)。 ———————————————标识构件过程——————————————————— 2.生成类图根据整理后的需求文档用一些CASE工具生成类图ABSD使用类图来描述系统结构。 3.对类进行分组生成了类图根据耦合和内聚程度还需要把类分组这样简化类图结构使其更加清晰可读。 4.把类打包成构件把类簇打包成构件这些构件可以分组合并。这一过程实现了构件级的重用构件和构件又可以打包成更大的构件。 ———————————————标识构件过程——————————————————— 5.需求评审需求也是要拉一批人开会讨论需求是否合理有效的不符合打回去重新获取再走一遍。 架构设计将需求阶段的标识构件映射成构件进行分析如下右图。 架构设计过程详细步骤 1.提出架构模型选择一个合适的架构风格(没有就自己造)该模型为将来的实现和演化建立了目标。 2.映射构件把已标识的构件映射到架构中将产生一个中间结构它只包含适合架构模型的构件。 3.分析构件相互作用研究构件之间的交互方式确保它们能够正确地协同工作满足系统的功能和性能要求。 4.产生架构当决定了关键构件之间的相互作用后就可以在中间结构的基础上进行精化得到软件架构 5.设计评审拉一人开会讨论产生的这个架构是否有不合理的地方有就打回去重新选择构件映射再走一遍直到大家意见一致。 架构(体系结构)文档化 主要产出两种文档即 架构(体系结构)规格说明 测试架构(体系结构)需求的质量设计说明书 。文档是至关重要的是所有人员通信的手段关系开发的成败。 文档的完整性和质量是软件架构成功的关键因素。 关于文档的三大注意事项 1文档要从使用者的角度进行编写。 2必须分发给所有与系统有关的开发人员 。 3且必须保证开发者手上的文档是最新的。 架构复审 由外部人员(独立于开发组织之外的人如用户代表和领域专家等)参加的复审复审架构是否满足需求质量问题构件划分合理性等。若复审不过则返回架构设计阶段进行重新设计、文档化再复审。 架构复审【架构评估】的目的是 标识潜在的风险及早发现架构设计中的缺陷和错。 架构实现用实体来显示出架构。实现构件构件组装成系统如下左图 架构实现过程 1.分析与设计根据文档(架构规格说明、测试架构需求的质量设计说明数)来实现 在架构说明书中已经定义了系统中构件与构件之间的关系构件接口约束对外唯一代表了构件所以可以从构件库中直接查找符合接口约束的构件。 2.构件实现必要时开发新的满足要求的构件。   3.构件组装按照设计文档的要求进行组装形成系统的基本结构   4.系统测试包括单个构件的功能性测试和被组装应用的整体功能和性能测试。 架构演化对架构进行改变按需求增删构件使架构可复用如下右图 架构演化详细过程   1.需求变化归类既然是演化那么肯定是需求发生了变化或者提出了新的那么这些需求首先要分类比如有些需求修改构件就行有些需要需要重新开发构件有些需要删除构件等等。 2.演化计划演化的是一个完整的实现了架构的系统了甚至在使用当中这就需要做一个计划来操作演化不能盲目的进行。 3.构件变动修改增加或删除构件要对修改和增加的构件进行功能性测试。 4.更新构件间相互作用构件变化了受影响的构件及它们间作用也跟着修改比如调用关系的改变顺序调整新增删除等等。 5.构件组装与测试对修改后的构件进行重新组装并进行测试以确保系统的功能和性能满足要求。 6.技术评审检查架构演化后的系统是否满足所有需求以及是否存在潜在的问题或缺陷。 如果哟问题打回去重新修改演化计划再走一遍。 7.得到演化后架构。 3 软件架构风格 软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型而这组约束指 出系统是如何将这些构件和连接件组合起来的。 架构风格反映了领域中众多系统所共有的结构和语义特性并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用一些经过实践证实的解 决方案也可以可靠地用于解决新的问题。 架构设计的一个核心问题是能否达到架构级的软件复用。 架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。 3.1 基本架构风格 数据流风格面向数据流按照一定的顺序从前向后执行程序代表的风格有 批处理序列、管道-过滤器。调用/返回风格构件之间存在互相调用的关系一般是显式的调用代表的风格有 主程序/子程序、面向对象、层次结构(C/s 架构风格本质属于层次风格)。 独立构件风格构件之间是互相独立的不存在显式的调用关系而是通过某个事件触发、异步的方式来执行代表的风格有 进程通信、事件驱动系统(隐式调用)。虚拟机风格自定义了一套规则供使用者使用使用者基于这个规则来开发构件能够跨平台适配代表的风格有 解释器、基于规则的系统。仓库风格以数据位中心所有的操作都是围绕建立的数据中心进行的代表的风格有数据库系统、超文本系统、黑板系统。 数据流风格 批处理序列构件为一系列固定顺序的计算单元构件之间只通过数据传递交互。每个处理步骤是一个独立的程序每一步必须在其前一步结束后才能开始数据必须是完整的以整体的方式传递。 管道-过滤器每个构件都有一组输入和输出构件读取输入的数据流经过内部处理产生输出数据流。前一个构件的输出作为后一个构件的输入前后数据流关联。过滤器就是构件连接件就是管道。 早期编译器就是采用的这种架构要一步一步处理的均可考虑此架构风格。   二者区别 在于批处理前后构件不一定有关联并且是作为整体传递即必须前一个执行完才能执行下一个。管道-过滤器是前一个输出作为后一个输入前面执行到部分可以开始下一个的执行。   调用/返回风格 主程序/子程序单线程控制把问题划分为若干个处理步骤构件即为主程序和子程序子程序通常可合成为模块。过程调用作为交互机制充当连接件的绝色。调用关系具有层次性其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性。   面向对象构件是对象对象是抽象数据类型的实例。在抽象数据类型中数据的表示和它们的相应操作被封装起来对象的行为体现在其接受和请求的动作。连接件即使对象间交互的方式对象是通过函数和过程的调用来交互的。   层次结构构件组成一个层次结构连接件通过决定层间如何交互的协议来定义。每层为上一层 提供服务使用下一层的服务只能见到与自己邻接的层。通过层次结构可以将大的问题分解为若干个渐进的小问题逐步解决可以隐藏问题的复杂度。修改某一层最多影响其相邻的两层(通常只能影响上层)。 层次结构优点 支持基于可增加抽象层的设计允许将一个复杂问题分解成一个增量步骤序列的实现。 不同的层次处于不同的抽象级别越靠近底层抽象级别越高越靠近顶层抽象级别越低。 由于每一层最多只影响两层同时只要给相邻层提供相同的接口允许每层用不同的方法实现同样为软件复用提供了强大的支持。 缺点 并不是每个系统都可以很容易的划分为分层的模式。 很难找到一个合适的、正确的层次抽象方法。 独立构件风格 进程通信构件是独立的进程连接件是消息传递。构件通常是命名过程消息传递的方式可以是点对点、异步或同步方式以及远程过程(方法)调用等。    事件驱动系统(隐式调用):构件不直接调用一个过程而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册当某个事件被触发时系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程它们之间交互的连接件往往是以过程之间的隐式调用来实现的。   主要优点是为软件复用提供了强大的支持为构件的维护和演化带来了方便缺点是构件放弃了 对系统计算的控制。   虚拟机风格 解释器通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机可以仿真硬件的执行过程和一些关键应用缺点是执行效率低。 解释器风格的一般组成 解释引擎解释工作存储区存要解析代码数据结构记录解释引擎当前工作状态数据结构记录代码被解释执行的进度    基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存一般用在人工智能 领域和 DSS、专家系统中。 基于规则风格的一般组成 规则集可多个规则的集合规则解释器负责解析和执行这些规则确保系统能够根据预定义的规则进行操作。规则/数据选择器扮演着关键角色它决定了哪些数据应该被应用到哪些规则上。工作内存用来存储当前状态和中间结果的地方。   仓库风格(数据共享风格以数据为中心) 数据库系统构件主要有两大类一类是中央共享数据源 保存当前系统的数据状态 另一类是多个独立处理单元处理单元 对数据元素进行操作 。  个人理解这两大类构件一个是数据库服务端另一个是类似客户端连接件就是它们之间的互联的方式、协议等等这些。    黑板系统包括知识源、黑板和控制三部分。知识源包括若干独立计算的不同单元提供解决问题的知识。知识源响应黑板的变化也只修改黑板黑板是一个全局数据库包含问题域解空间的全部状态是知识源相互作用的唯一媒介知识源响应式通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中(信号处理、问题规划和编译器优化等)。 黑板系统 知识源包含若干独立计算的不同单元以及独立的、与应用程序相关的知识知识源之间不直接进行通讯它们之间的交互只通过黑板来完成。–独立计算单元和知识。黑板全局数据库包含问题域解空间的全部状态按照与应用程序相关的层次来组织并解决问题的数据知识源通过不断地改变黑板数据来解决问题。– 全局数据库问题域和解空间全部状态根据与应用程序相关的层次来解决问题。控制完全由黑板的状态驱动黑板状态的改变决定了需要使用的特定知识。–黑板状态驱动 与数据库系统相比黑板相当于中央共享数据源服务端中央数据结构知识源相当于独立处理单元客户端独立构件    超文本系统构件以网状链接方式相互连接用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。是一种非线性的网状信息组织方法它以节点为基本单位链作为节点之间的联想式关联。通常应用在互联网领域。    现代编译器的集成开发环境一般采用数据仓储(即以数据为中心的架构风格)架构风格进行开发 其中心数据就是程序的语法树。   闭环控制架构(过程控制) 当软件被用来操作一个物理系统时软件与硬件之间可以粗略的表示为一个反馈循环这个反馈 循环通过接受一定的输入确定一系列的输出最终使环境达到一个新的状态适合于嵌入式系统涉及连续的动作与状态。    C2 架构风格 C2 体系结构风格可以概括为通过连接件绑定在一起的按照一组规则运作的并行构件网络。 C2风格中的系统组织规则如下 (1)系统中的构件和连接件都有一个顶部和一个底部 (2)构件的顶部应连接到某连接件的底部构件的底部则应连接到某连接件的顶部而构件与构件之 间的直接连接是不允许的(3)一个连接件可以和任意数目的其它构件和连接件连接(4)当两个连接件进行直接连接时必须由其中一个的底部到另一个的顶部。 必背 3.2 层次结构风格 两层C/S 架构 客户端和服务器都有处理功能相比较于传统的集中式软件架构还是有不少优点的但是现在已经不常用原因有开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一、软件移植困难、软件维护和升级困难、新技术不能轻易应用、安全性问题、服务器端压力大难以复用。 三层 C/S 架构 将处理功能独立出来表示层和数据层都变得简单。表示层在客户机上功能层在应用服务器上数据层在数据库服务器上。即将两层 C/S 架构中的数据从服务器中独立出来了。其优点下面四点 各层在逻辑上保持相对独立整个系统的逻辑结构更为清晰能提高系统和软件的可维护性和可扩展性允许灵活有效的选用相应的平台和硬件系统具有良好的可升级性和开放性 各层可以并行开发各层也可以选择各自最适合的开发语言 功能层有效的隔离表示层与数据层为严格的安全管理奠定了坚实的基础整个系统的管理层次也更加合理和可控制。 三层 C/S 架构设计的关键在于各层之间的通信效率要慎重考虑三层间的通信方法、通信频度和 数据量否则即使分配给各层的硬件能力很强性能也不高。 三层 B/S 架构 是三层C/S 架构的变种将客户端变为用户客户端上的浏览器将应用服务器变为网络上的 WEB服务器又称为0客户端架构虽然不用开发客户端但有很多缺点主要是数据处理能力差 B/S架构缺乏对动态页面的支持能力没有集成有效的数据库处理功能 安全性难以控制 在数据查询等响应速度上要远远低于C/S 架构 数据提交一般以页面为单位数据的动态交互性不强不利于 OLTP应用。 混合架构风格 内外有别模型企业内部使用C/S,外部人员访问使用 B/S。 查改有别模型采用 B/S 查询采用 C/s修改。 混合架构实现困难且成本高。 富互联网应用 RIA 弥补三层 B/S架构存在的问题RIA是一种用户接口比用HTML实现的接口更加健壮且有可 视化内容本质还是网站模式其优点如下 RIA结合了C/S 架构反应速度快、交互性强的优点与 B/S 架构传播范围广及容易传播的特性 RIA 简化并改进了B/S架构的用户交互 数据能够被缓存在客户端从而可以实现一个比基于 HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。 本质还是0客户端借助于高速网速实现必要插件在本地的快速缓存增强页面对动态页面的支 持能力典型的如小程序。— 其实是利用高速的网络在现搭建一个客户端。 MVC 用户操作-View(负责接收用户的输入操作)-Controller(业务逻辑处理)-Model(数据持久化)-View(将结果反馈给View)。经典 MVC架构如下图所示 MVP MVP是把 MVC中的 Controller换成了 Presenter(呈现),目的就是为了完全切断 View跟Model 之间的联系由 Presenter 充当桥梁做到 View-Model之间通信的完全隔离。 MVVM 如果说MVP是对 MVC的进一步改进那么 MVVM 则是思想的完全变革。它是将“数据模型数据双向绑定”的思想作为核心因此在 View和 Model之间没有联系通过ViewModel 进行交互而且 Model 和 ViewModel 之间的交互是双向的因此视图的数据的变化会同时修改数据源而数据源数据的变化也会立即反应到View上。– View和Model之间不直接联系通过ViewModel来交互ViewModel和Model双向交互。 3.3 面向服务的架构 SOA 概念 SOA是一种粗粒度、松耦合服务架构 服务之间通过简单、精确定义接口进行通信不涉及底层编程接口和通信模型。 在 SOA 中服务是一种为了满足某项业务需求的操作、规则等的逻辑组合它包含一系列有序活动的交互为实现用户目标提供支持。 SOA并不仅仅是一种开发方法还具有管理上的优点管理员可直接管理开发人员所构建的相同 服务。多个服务通过企业服务总线提出服务请求由应用管理来进行处理如下 实施 SOA的关键目标是实现企业IT资产重用的最大化。 在实施 SOA过程中要牢记以下特征 可从企业外部访问、随时可用(服务请求能被及时响应)、粗粒度接口(粗粒度提供一项特定的业务功能而细粒度服务代表了技术构件方法)、服务分级、松散耦合(服务提供者和服务使用者分离)、可重用的服务及服务接口设计管理、标准化的接口(WSDL、SOAP、XML是核心)、支持各种消息模式、 精确定义的服务接口。 总结 外部访问、可用及时、粗粒度、服务分级、松耦合(提/使)、可重用、标准化、消息模式多接口精确定义 XML是一种描述语言WSDL是基于XML的描述服务的SOAP是简单对象访问协议用于交换数据的 从基于对象到基于构件再到基于服务架构越来越松散耦合粒度越来越粗接口越来越标准。 基于服务的构件与传统构件的区别有四点 服务构件粗粒度传统构件细粒度居多 服务构件的接口时标准的主要是WSDL接口而传统构件常以具体 API形式出现 服务构件的实现与语言是无关的而传统构件常绑定某种特定的语言 服务构件可以通过构件容器提供QoS的服务而传统构件完全由程序代码直接控制。 总结 服务构件粗粒度传统细粒度服务构件接口标准传统API服务构件实现语言无关传统正相反服务构件有容器QoS传统代码保证。 关键技术 SOA 中应用的关键技术如下表。 发现服务 UDDI:用于 Web服务注册和服务查找描述了服务的概念定义了编程的接口供其他企业来 调用。 DISCO:发现公开服务的功能及交互协议。 描述服务 WSDL(WEB服务描述语言)协议用于描述 Web服务的接口和操作功能描述网络服务。 消息格式层 SOAP为建立 Web服务和服务请求之间的通信提供支持。 REST (Representational State Transfer,表述性状态转移)是一种只使用HTTP和 XML进行基于 Web 通信的技术可以降低开发的复杂性提高系统的可伸缩性。 编码格式层 扩展标记语言(Extensible Markup Language, XML),用于标记电子文件使其具有结构性的标记语言可以用来标记数据、定义数据类型是一种允许用户对自己的标记语言进行定义的源语言。 SOA的实现方式 WEB Service 服务提供者、服务注册中心(中介提供交易平台可有可无)、服务请求者。服务提供者将服务描述发布到服务注册中心供服务请求者查找查找到后服务请求者将绑定查找结果。如下图 分为六层 底层传输层负责底层消息的传输采用HTTP、JMS、SMTP协议服务通信协议层描述并定义服务间通信的技术标准采用 SOAP和 REST协议服务描述层采用WSDL协议服务层对企业应用系统进行包装通过WSDL定义的标准进行调用业务流程层支持服务发现服务调用和点到点的服务调用采用WSDPEL标准服务注册层采用UDDI协议 补充 JMS是Java消息服务Java中面向消息中间件API 底层是传输层消息传输模块通信层用一些SOAP和REST协议来封装一下底层消息描述层采用WSDL协议描述服务服务层是包装各系统并采用WSDL标准调用业务流程层来提供发现、调用的方式、标准注册层用UDDI协议用于注册。 服务注册表 服务注册应用开发者(服务提供者)在注册表中公布服务的功能。 服务位置服务使用者(服务应用开发者),帮助他们查询注册服务寻找符合自身要求的服务。 服务绑定服务使用者利用检索到的服务接口来编写代码所编写的代码将与注册的服务绑定调用注册的服务以及与它们实现互动。 本质与WEB Service类似只是使用一个注册表来代替服务注册中心。 企业服务总线 ESB 客户端(服务请求者)、基础架构服务(中间件)、核心集成服务(提供服务)。本质也是通过网络有下列六点功能 提供位置透明性的消息路由和寻址服务 提供服务注册和命名的管理功能 支持多种的消息传递范型 支持多种可以广泛使用的传输协议 支持多种数据格式及其相互转换 提供日志和监控功能。 4 软件架构复用 软件产品线是指一组软件密集型系统它们共享一个公共的、可管理的特性集满足某个特定市场或任务的具体需要是以规定的方式用公共的核心资产集成开发出来的。即围绕核心资产库进行管理、复用、集成新的系统。 软件架构复用的类型包括机会复用和系统复用。机会复用是指开发过程中只要发现有可复用的资产就对其进行复用。系统复用是指在开发之前就要进行规划以决定哪些需要复用。    可复用的资产包括需求、架构设计、元素、建模与分析、测试、项目规划、过程方法和工具、人员、样本系统、缺陷消除。    复用的基本过程主要包括3个阶段首先构造/获取可复用的软件资产其次管理这些资产(构件库),最后针对特定的需求从这些资产中选择可复用的部分以开发满足需求的应用系统。 5 特定领域软件架构 DSSA DSSA 就是专用于一类特定类型的任务(领域)的、在整个领域中能有效地使用的、为成功构造应用 系统限定了标准的组合结构的软件构件的集合。 – 它是一个构件集合只是这个集合的构件都是适应于特定的领域在这个领域中比较通用或者比较标准。 DSSA 就是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考架构等组成的开发基础其目标就是支持在一个特定领域中多个应用的生成。 垂直域在一个特定领域中的通用的软件架构是一个完整的架构。 水平域在多个不同的特定领域之间的相同的部分的小工具(如购物和教育都有收费系统收费 系统即是水平域)。 DSSA的三个基本活动 领域分析这个阶段的主要目标是获得领域模型(领域需求)。识别信息源即整个领域工程过程中信息的来源可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等在此基础上就可以分析领域中系统的需求确定哪些需求是领域中的系统广泛共享的从而建立领域模型。 领域设计这个阶段的目标是获得 DSSA。DSSA描述在领域模型中表示的需求的解决方案它不是单个系统的表示而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后就可以派生出满足这些被建模的领域需求 DSSA。 领域实现这个阶段的主要目标是依据领域模型和 DSSA开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到也可能需要通过新的开发得到。 以上过程是一个反复的、逐渐求精的过程。在实施领域工程的每个阶段中都可能返回到以前的步骤对以前的步骤得到的结果进行修改和完善再回到当前步骤在新的基础上进行本阶段的活动。 参与 DSSA的四种角色人员 领域专家包括该领域中系统的有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。提供关于领域中系统的需求规约和实现的知识帮助组织规范的、一致的领域字典帮助选择样本系统作为领域工程的依据复审领域模型、DSSA 等领域工程产品等等。 领域分析人员由具有知识工程背景的有经验的系统分析员来担任。控制整个领域分析过程进行知识获取将获取的知识组织到领域模型中。 领域设计人员由有经验的软件设计人员来担任。根据领域模型和现有系统开发出DSSA,并对DSSA的准确性和一致性进行验证。    领域实现人员由有经验的程序设计人员来担任。根据领域模型和 DSSA,开发构件。    建立 DSSA的过程 (1)定义领域范围领域中的应用要满足用户一系列的需求。 (2)定义领域特定的元素建立领域的字典归纳领域中的术语识别出领域中相同和不相同的元素。 (3)定义领域特定的设计和实现需求的约束识别领域中的所有约束这些约束对领域的设计和实现会造成什么后果。 (4)定义领域模型和架构产生一般的架构并描述其构件说明。 (5)产生、搜集可复用的产品单元为 DSSA增加复用构件使可用于新的系统。    以上过程是并发的、递归的、反复的、螺旋型的。该过程的目的是将用户的需求映射为基于实现限制集合的软件需求这些需求定义了 DSSA。 定范围–定元素–识别约束–产生架构–产生构件。  这些过程并发、递归、反复、螺旋的    DSSA的三层次系统模型 领域开发环境领域架构师决定核心架构产出参考结构、参考需求、架构、领域模型、开发工具。   领域特定的应用开发环境应用工程师根据具体环境来将核心架构实例化。   应用执行环境操作员实现实例化后的架构。 ​​​​​​​    6 系统质量属性与架构评估 6.1 软件系统质量属性 软件系统的质量就是“软件系统与明确地和隐含地定义的需求相一致的程度”。 – 明确提出的(SRS)以及隐含的期望这些都是需求软件系统表现与这些需求一致的程度就用软件系统的质量来表达。 可以将软件系统的质量属性分为开发期质量属性和运行期质量属性2个部分。 1.开发期质量属性主要指在软件开发阶段所关注的质量属性主要包含6个方面。 (1)易理解性指设计被开发人员理解的难易程度。 (2)可扩展性软件因适应新需求或需求变化而增加新功能的能力也称为灵活性。 (3)可重用性指重用软件系统或某一部分的难易程度。 (4)可测试性对软件测试以证明其满足需求规范的难易程度。 (5)可维护性当需要修改缺陷、增加功能、提高质量属性时识别修改点并实施修改的难易程度。(6)可移植性将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。 ​​​​​​​理解、扩展、重用、测试、维护、移植的难易程度。 2.运行期质量属性主要指在软件运行阶段所关注的质量属性主要包含7个方面。 (1)性能性能是指软件系统及时提供相应服务的能力如速度、吞吐量和容量等的要求。 (2)安全性指软件系统同时兼顾向合法用户提供服务以及阻止非授权使用的能力。 (3)可伸缩性指当用户数和数据量增加时软件系统维持高服务质量的能力。例如通过增加服务器来提高能力。(4)互操作性指本软件系统与其他系统交换数据和相互调用服务的难易程度。 (5)可靠性软件系统在一定的时间内持续无故障运行的能力。 (6)可用性指系统在一定时间内正常工作的时间所占的比例。可用性会受到系统错误恶意攻击高负载等问题的影响。(7)鲁棒性是指软件系统在非正常情况(如用户进行了非法操作、相关的软硬件系统发生了故障等)下仍能够正常运行的能力也称健壮性或容错性。 性能、安全、伸缩、互操作、可靠、可用、鲁棒   伸缩能屈能伸用户量访问量上来能及时调整资源保持系统运行快速质量不打折扣。 互操作跟其他系统或人、设备打交道的难易程度 可靠尽量长时间运行不发生故障 可用不发生故障运行所占比例(要尽量高)   –  可用可靠都出现首选可用 鲁棒健壮容错比如发生非法操作意外故障能容错甚至恢复(比如云服务就有容错机制)这样更健壮。 面向架构评估的质量属性 1、性能指系统的响应能力即要经过多长时间才能对某个事件做出响应或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。 设计策略优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。   2、可靠性是软件系统在应用或系统错误面前在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如 MTTF、MTBF。 设计策略心跳、Ping/Echo、冗余、选举。包括容错和健壮性。   3、可用性是系统能够正常运行的时间比例经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间。 设计策略心跳、Ping/Echo、冗余、选举。   4、安全性是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。 设计策略入侵检测、用户认证、用户授权、追踪审计。   5、可修改性指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准通过考察这些变更的代价衡量。包括可维护性、可扩展性、结构重组、可移植性。 设计策略接口-实现分类、抽象、信息隐藏。   6、功能性是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。   7、可变性指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时可变性是很重要的。   8、互操作性作为系统组成部分的软件不是独立存在的经常与其他系统或自身环境相互作用。 为了支持互操作性软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题也影响应用的软件体系结构。   前面的开发期属性和运行期属性综合一下针对架构进行评估的质量属性提炼就是这些 性能、可靠、可用、安全、可修改、功能、可变、互操作。   重点记忆钱5个及设计策略。 针对每个质量属性构造质量属性场景来衡量这个属性对架构的影响程度就是以下质量属性场景的应用。 质量属性场景是一种面向特定质量属性的需求。它由6 部分组成 · 刺激源(Source):这是某个生成该刺激的实体(人、计算机系统或者任何其他刺激器)。   · 刺激(Stimulus):该刺激是当刺激到达系统时需要考虑的条件。   ·环境(Environment):该刺激在某些条件内发生。当激励发生时系统可能处于过载、运行或者其他情况。   · 制品(Artifact):某个制品被激励。这可能是整个系统也可能是系统的一部分。   · 响应(Response):该响应是在激励到达后所采取的行动。   · 响应度量(Measurement):当响应发生时应当能够以某种方式对其进行度量以对需求进行测试。     可修改性质量属性场景描述实例 6.2 系统架构评估 系统架构评估是在对架构分析、评估的基础上对架构策略的选取进行决策。– 系统架构评估是在架构分析和架构评估基础上(可理解为分析之后内部评估分析结果)再对架构选取的策略评估。 软件架构评估在架构设计之后系统设计之前因此与设计、实现、测试都没有关系。评估的目的是为了评估所采用的架构是否能解决软件系统需求但不是单纯的确定是否满足需求。 三种常用的评估方式 基于调查问卷(检查表)的方式类似于需求获取中的问卷调查方式只不过是架构方面的问卷要求评估人员对领域熟悉。 基于度量的方式制定一些定量来度量架构如代码行数等。要制定质量属性和度量结果之间的映射要求评估人员对架构熟悉。涉及3个基本活动首先需要建立质量属性和度量之间的映射原则然后从软件架构文档中获取度量信息最后根据映射原则分析推导出系统的质量属性。    基于场景的方式主要方法。首先要确定应用领域的功能和软件架构的结构之间的映射然后要设计用于体现待评估质量属性的场景(即 41视图中的场景),最后分析软件架构对场景的支持程度。 要求评估人员即对领域熟悉也对架构熟悉。    三种评估方式的比较 由上表可知场景最不通用度量要求对构架精确了解调查问卷实施阶段最早度量最客观。 其中基于场景的方式是主流。 架构评估中的重要概念 敏感点是指为了实现某种特定的质量属性一个或多个构件所具有的特性。   权衡点是影响多个质量属性的特性是多个质量属性的敏感点。   风险点与非风险点不是以标准专业术语形式出现的只是一个常规概念即可能引起风险的因素 可称为风险点。某个做法如果有隐患有可能导致一些问题则为风险点而如果某件事是可行的 可接受的则为非风险点。    从三个方面对场景进行设计 刺激(事件)环境(事件发生的环境)响应(架构响应刺激的过程)。    6.3 基于场景的评估方法 基于场景的架构分析方法SAAM SAAM是 一种非功能质量属性的架构分析方法 是最早形成文档并得到广泛应用的软件架构分析方法。 特定目标。SAAM的 目标 是对描述应用程序属性的文档验证基本的架构假设和原则。 质量属性。这一方法的 基本特点 是把任何形式的质量属性都具体化为场景但可修改性是 SAAM 分析的主要质量属性。 架构描述。SAAM用于架构的最后版本但早于详细设计。架构的描述形式应当被所有参与者理解。 ​​​​​​​  功能、结构和分配被定义为描述架构的3个主要方面 。 方法活动。SAAM的 主要输入 是问题描述、需求说明和架构描述。下图描绘了SAAM分析活动的相关输入及评估过程。 包括5个步骤即场景开发、架构描述、单个场景评估、场景交互和总体评估。 开发场景架构描述先单个场景然后多个场景交互最后总体评估。   架构权衡分析法 ATAM 让架构师明确如何权衡多个质量目标参与者有评估小组、项目决策者和其他项目相关人。    ATAM被分为四个主要的活动领域分别是场景和需求收集、体系结构视图和场景实现、属性模 型构造和分析、折中。整个评估过程强调以属性作为架构评估的核心概念。主要针对性能、可用性、安全性和可修改性在系统开发之前对这些质量属性进行评价和折中。    ATAM方法采用效用树(Utility tree)这一工具来对质量属性进行分类和优先级排序。效用树的结构包括树根-质量属性-属性分类-质量属性场景(叶子节点)。需要注意的是ATAM/主要关注 4 类质量属性性能、安全性、可修改性和可用性这是因为这4个质量属性是利益相关者最为关心的。   ATAM方法架构评估实践 注意这个内容选择案例不会考。但是可用于写论文的步骤建议写这个主题论文的重点看 一下第二版教材第8.3节第289 页书上给出了胡佛事件架构、银行事件架构这两个具体架构的详细描述可作为大家写论文时的素材参考不过书上写的比较多比较复杂大家也要有选择性的参考。当然也可以直接听文老师论文直播里这块的讲解来构思。 成本效益分析法 CBAM 用来对架构建立的成本来进行设计和建模让决策者根据投资收益率来选择合适的架构可以看 做对 ATAM的补充在 ATAM确定质量合理的基础上再对效益进行分析。有下列步骤 (1)整理场景(确定场景并确定优先级选择三分之一优先级最高的场景进行分析); (2)对场景进行细化(对每个场景详细分析确定最好、最坏的情况); (3)确定场景的优先级(项目干系人对场景投票根据投票结果确定优先级); (4)分配效用(对场景响应级别确定效用表建立策略、场景、响应级别的表格); (5)形成“策略-场景-响应级别的对应关系”; (6)确定期望的质量属性响应级别的效用(根据效用表确定所对应的具体场景的效用表); (7)计算各架构策略的总收益 (8)根据受成本限制影响的投资报酬率选择架构策略(估算成本用上一步的收益减去成本得出收益并选择收益最高的架构策略)。 其他评估方法(仅了解) 1.SAEM 方法。将软件架构看作一个最终产品以及设计过程中的一个中间产品从外部质量属性 和内部质量属性两个角度来阐述它的评估模型旨在为软件架构的质量评估创建一个基础框架。 外部属性指用户定义的质量属性而内部属性指开发者决定的质量属性。该软件架构评估模型包 含以下几个流程。 (1)对待评估的质量属性进行规约建模。 (2)为外部和内部的质量属性创建度量准则先从评估目的(如软件架构比较、最终产品的质量预测),评估角度(如开发者、用户、维护者),评估环境(架构作为最终产品或设计中间产品)出发来定义架构评估的目标再根据目标相关的属性来提出问题然后回答每个问题并提出相应的度量准则。 (3)评估质量属性包括数据收集、度量和结果分析3个活动。 2.SAABNet方法。是一种用来表达和使用定性知识以辅助架构的定性评估。该方法来源于人工智 能允许不确定、不完整知识的推理。该方法使用 BBN 来表示和使用开发过程中的知识包含定性和定量的描述其中定性的描述是所有结点的图定量的描述是每个结点状态相关的条件概率。 其中的变量可分为3 类即架构质量属性变量(如可维护性、灵活性等)、质量属性的度量准则 变量(如容错性、响应性等)和架构特征变量(如继承深度、编程语言等),高层抽象的质量属性变 量分解为低层抽象的度量准则变量度量准则变量则分解为更低层抽象的架构特征变量。 3.SACMM方法。是一种软件架构修改的度量方法。 4.SASAM方法。通过对预期架构(架构设计阶段的相关描述材料)和实际架构(源代码中执行的 架构)进行映射和比较来静态地评估软件架构。 5.ALRRA方法。是一种软件架构可靠性风险评估方法该方法使用动态复杂度准则和动态耦合度 准则来定义组件和连接件的复杂性因素其中动态复杂度准则在某个场景的执行中分析组件的动态行为来度量组件的复杂性动态耦合度准则在某个场景的执行中分析连接件的消息传递协议来度量连接件的复杂性。利用失效模式和影响分析(FMEA)技术。 6.AHP(层次分析法)方法。是对定性问题进行定量分析的一种简便、灵活而又实用的多准则决 策方法。AHP方法的特点是把复杂问题中的各种因素通过划分为相联系的有序层次使之条理化并在一般情况下通过两两对比根据一定客观现实的主观判断结构把专家意见和分析者的客观判断结果直接、有效地结合起来将一定层次上元素的某些重要性进行定量描述之后利用数学方法计算反映每一层次元素的相对重要性次序的权值井最后通过所有层次之间的总排序计算所有元素的相对权重及对权重进行排序。 7.COSMICUML方法。基于度量模型来评估软件架构可维护性的方法。针对不同表达方式的软件 架构采用统一的软件度量 COSMIC 方法来进行度量和评估。该方法主要是为了辅助分析软件架构的演化方案是否可行并在开源软件 DCMMS 的软件架构 UML 组件图上得以验证。 7 中间件技术 中间件是一种独立的系统软件或服务程序可以帮助分布式应用软件在不同的技术之间共享资源。 中间件特点 负责客户机与服务器之间的连接和通信以及客户机与应用层之间的高效率通信机制。 提供应用层不同服务之间的互操作机制以及应用层与数据库之间的连接和控制机制。 提供多层架构的应用开发和运行的平台以及应用开发框架支持模块化的应用开发。 屏蔽硬件、操作系统、网络和数据库的差异。 提供应用的负载均衡和高可用性、安全机制与管理功能以及交易管理机制保证交易的一致性。 提供一组通用的服务去执行不同的功能避免重复的工作和使应用之间可以协作。 按照中间件在分布式系统中承担的职责不同可以划分以下几类中间件产品。 1)通信处理(消息)中间件 在分布式系统中要建网和制定出通信协议以保证系统能在不同平台之间通信实现分布式系统中可靠的、高效的、实时的跨平台数据传输这类中间件称为消息中间件也是市面上销售额最大的中间件产品。 2)事务处理(交易)中间件 在分布式事务处理系统中经常要处理大量事务特别是OLTP 中每项事务常常要多台服务器上的程序按顺序协调完成一旦中间发生某种故障不但要完成恢复工作而且要自动切换系统保证系统永不停机实现高可靠性运行。要使大量事务在多台应用服务器上能实时并发运行并进行负载平衡的调度实现与昂贵的可靠性机和大型计算机系统的同等功能为了实现这个目标要求中间件系统具有监视和调度整个系统的功能。 3)数据存取管理中间件 在分布式系统中重要的数据都集中存放在数据服务器中它们可以是关系型的、复合文档型、具有各种存放格式的多媒体型或者是经过加密或压缩存放的该中间件将为在网络上虚拟缓冲存取、格式转换、解压等带来方便。 4) Web 服务器中间件 浏览器图形用户界面己成为公认规范然而它的会话能力差不擅长做数据的写入任务受HTTP 协议的限制多等就必须对其进行修改和扩充因此出现了Web 服务器中间件。 5)安全中间件 一些军事、政府和商务部门上网的最大障碍是安全保密问题而且不能使用国外提供的安全措施(如防火墙、加密和认证等),必须用国产产品。产生不安全因素是由操作系统引起的但必须要用中间件去解决以适应灵活多变的要求。 6)跨平台和架构的中间件 当前开发大型应用软件通常采用基于架构和构件技术在分布式系统中还需要集成各结点上的不同系统平台上的构件或新老版本的构件由此产生了架构中间件。功能最强的是CORBA ,可以跨 任意平台但是其过于庞大 JavaBeans 较灵活简单很适合用于浏览器但运行效率有待改善COM十模型主要适合Windows 平台已在桌面系统广泛使用。由于国内新建系统多基于 UNIX(包括 Linux)和 Windows ,因此针对这两个平台建立相应的中间件市场相对要大得多。   7)专用平台中间件 专用平台中间件为特定应用领域设计领域参考模式建立相应架构配置相应的构件库和中间件为应用服务器开发和运行特定领域的关键任务(如电子商务、网站等)。   8)网络中间件 它包括网管、接入、网络测试、虚拟社区和虚拟缓冲等也是当前最热门的研发项目。 软件构件 软件构件构件又称为组件是一个自包容、可复用的程序集。构件是一个程序集或者说是一组程序的集合。构件的两个最重要的特性是自包容与可重用。 构件组装模型的一般开发过程设计构件组装、建立构件库、构建应用软件、测试与发布。 商用构件标准规范-CORBA(公共对象请求代理体系结构) 公共对象请求代理架构(CORBA)主要分为3 个层次对象请求代理、公共对象服务和公共设施。 最底层的对象请求代理(ORB)规定了分布对象的定义(接口)和语言映射实现对象间的通信和互操作是分布对象系统中的“软总线”; 在 ORB 之上定义了很多公共服务可以提供诸如并发服务、名字服务、事务(交易)服务、安全服务等各种各样的服务 最上层的公共设施则定义了构件框架提供可直接为业务对象使用的服务规定业务对象有效协作所需的协定规则。 COREA CCM 构件模型是OMG 组织制定的一个用于开发和配置分布式应用的服务器端构件模型规范它主要包括如下3 项内容。 (1)抽象构件模型用以描述服务器端构件结构及构件间互操作的结构。 (2)构件容器结构用以提供通用的构件运行和管理环境并支持对安全、事务、持久状态等系统服务的集成。 (3)构件的配置和打包规范CCM 使用打包技术来管理构件的二进制、多语言版本的可执行代码和配置信息井制定了构件包的具体内容和文档内容标准。 对象管理组织(OMG)基于 CORBA基础设施定义了四种构件标准。 实体(Entity)构件需要长期持久化并主要用于事务性行为由容器管理其持久化。 加工(Process)构件同样需要容器管理其持久化但没有客户端可访问的主键。 会话(Session)构件不需要容器管理其持久化其状态信息必须由构件自己管理。 服务(Service)构件是无状态的。 CORBA对象可看作是一个具有对象标识、对象接口及对象实现的抽象实体。之所以称为抽象的 是因为并没有硬性规定 CORBA 对象的实现机制一个 CORBA 对象的引用又称可互操作的对象引用 (Interoperable Object Reference)。从客户程序的角度看IOR 中包含了对象的标识、接口类型及其他信息以查找对象实现。 对象标识(Object ID)是一个用于在POA中标识一个CORBA对象的字符串。它既可由程序员指派也可由对象适配器自动分配这两种方式都要求对象标识在创建它的对象适配器中必须具有唯一 性。 POA(便携式对象适配器)是对象实现与 ORB其它组件之间的中介支持由 Object Id 标识的对象的名称空间它将客户请求传送到伺服对象按需创建子 POA,提供管理伺服对象的策略。 伺服对象(servant)是指具体程序设计语言的对象或实体通常存在于一个服务程序进程之中。 客户程序通过对象引用发出的请求经过 ORB 担当中介角色转换为对特定的伺服对象的调用。在一个 CORBA 对象的生命期中它可能与多个伺服对象相关联因而对该对象的请求可能被发送到不同的伺服对象。 7.1 典型的应用架构-J2EE 分布式多层应用程序 客户层(客户应用或 WEB浏览器动态网页)对应客户机 WEB层(可省略是WEB浏览器)和业务层(业务处理逻辑包括会话 Bean,实体 Bean和消息驱动 Bean)对应J2EE 服务器 企业信息系统层对应数据存储服务器。 JAVA企业应用框架 Structs 框架是一个基于 J2EE 平台的 MVC(模型、视图、控制器)框架采用 Servelet和 JSP技术实现。M 由实现业务逻辑的 javaBean构成C由 ActionServlet和 Action来实现V由一组JSP文件构成。 Spring 框架通过RMI或 Web Servic远程访问业务逻辑允许自由选择和组装各部分功能还提供和其他软件集成的接口。Spring 本身是个容器管理构件的生命周期、构件的组态、依赖注入等并可以控制构件在创建时是以原型或单例模式来创建。 Hibernate 框架是一个对象关系映射框架提供了java 对象到数据库表之间的直接映射它对JDBC 进行了非常轻量级的对象封装使得 java 程序员可以使用对象编程思维来操作数据库。在 Hibernate 中ORM机制的核心是一个XML文件该文件描述了数据库模式是怎么与一组 java类绑定在一起的。 表示层由 Structs 实现管理用户请求业务层由 Spring实现处理业务逻辑中的业务处理情况提供一个控制器的代码数据库层由 Hibernate 实现通过面向对象的查询语言 HQL来实现数据的增删改查。这样组合可以搭建一个轻量级的J2EE 架构。 重量级与轻量级之争 重量级与轻量级之争重量级框架占用资源过多在开发的过程中效率很低大部分时间花在配置、运行的过程上修改复杂单元测试也比较麻烦。但在大量运行过程中会表现出优异的效果也即开发麻烦运行性能高。 轻量级框架提高了开发的速度立即可以看到结果做单元测试非常简单大量线程可供参考的开源代码。开发简单但运行性能低。 7.2 典型的应用架构-.NET .NET框架处于操作系统和.NET应用语言之间只适用于微软系统而J2EE 支持跨平台任何安 装了JVM的平台。 .NET和J2EE 之争 JVM(将所有 JAVA代码都编译为字节码由 JVM 解释执行)和 CLR(.NET 核心技术类似于JVM,生成中间代码 CLR,编译执行)。 对多层分布式应用的支持二者都支持多层分布式应用程序的开发在表示层的平台支持上 J2EE 客户端支持多个平台.NET 只能在微软系统上运行也正是因此.NET 会对微软系统上的应用进行优化在业务层J2EE 占优势因为有许多开源的项目和代码供参考开发就变得简单在数据层二者都支持多种数据库都非常优秀。 安全性由于 JAVA在.NET之后出来借鉴了.NET优点JAVA在运行时动态验证.NET是静态全面验证二者都非常优秀不分上下。 应用程序的部署J2EE 的部署相对来说较复杂针对不同的系统要特别布置。 可移植性显然 J2EE 占优势一次开发到处运行。 外部支持J2EE 占优势得到了很多厂家的支持.NET只是微软一家。