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

户外旅游网站排名wordpress logy

news 2026/4/8 18:19:05

户外旅游网站排名,wordpress logy,免费咨询医生回答在线男科,毕设做购物网站容易吗个人总结#xff0c;仅供参考#xff0c;欢迎加好友一起讨论文章目录架构 - 软件架构设计#xff1c;新版#xff1e;考点摘要概念架构的 4 1 视图架构描述语言ADL基于架构的软件开发方法ABSDABSD的开发模型ABSDMABSD#xff08;ABSDM模型#xff09;的开发过程软件架… 个人总结仅供参考欢迎加好友一起讨论文章目录架构 - 软件架构设计新版考点摘要概念架构的 4 1 视图架构描述语言ADL基于架构的软件开发方法ABSDABSD的开发模型ABSDMABSDABSDM模型的开发过程软件架构风格经典五大架构风格数据流风格调用/返回风格独立构件风格虚拟机风格仓库风格闭环控制架构过程控制C2架构风格软件架构风格 - 风格判断题目层次架构风格二层C/S架构三层C/S架构B/S架构混合架构风格其它架构风格富互联网RIA架构MVC架构风格MVP架构风格MVVM架构风格模型驱动MDA特定领域软件架构DSSA基本活动领域分析机制建立过程三层次模型软件架构评估软件架构质量属性性能可用性安全性可修改性易用性可测试性敏感点与权衡点评估方法基于场景的架构评估方法软件架构分析法SAAM架构权衡分析法ATAM评估参与者评估步骤质量属性效用树成本效益分析法CBAM其它评估方法软件产品线过程模型 - 双生命周期模型过程模型 - 三生命周期模型过程模型 - SEI模型建立方式组织结构构件定义构件的复用构件的组装构件的标准中间件6个基本功能类型和分类应用服务器架构 - 软件架构设计新版考点摘要软件架构的概念★★★基于架构的软件开发★★★★软件架构风格★★★★★特定领域软件架构★★★软件质量属性★★★★★软件架构评估★★★★★软件产品线★★★构件与中间件技术★★★★MDA数据驱动模型★★★架构描述语言ADL★★★Web架构设计★★★★ 第二版教材对应第78两章是整个架构考试里最重要的章节其内容不仅在选择题占大头案例论文也是每年都考。本章节选择题除了教材上有的架构基本概念、架构风格、DSSA、ABSD、质量属性和架构评估外还涉及到了很多教材上没有的内容如构件和连接件、中间件、构件开发等这些内容在老版教材是有单独的章节但是第二版教材已经都删除了个人认为出题的概率还是很大的。概念架构设计就是需求分配即将满足需求的职责分配到构件/组件上。软件架构为软件系统提供了一个结构、行为和属性的高级抽象由构件的描述、构件的相互作用连接件、指导构件集成的模式以及这些模式的约束组成。软件架构不仅指定了系统的组织结构和拓扑结构并且显示了系统需求和构件之间的对应关系提供了一些设计决策的基本原理。解决好软件的复用、质量和维护问题是研究软件架构的根本目的。架构的本质软件架构为软件系统提供了一个结构、行为和属性的高级抽象。软件架构风格是特定应用领域的惯用模式架构定义一个词汇表和一组约束。架构的作用软件架构是项目干系人进行交流的手段。软件架构是可传递和可复用的模型通过研究软件架构可能预测软件的质量。软件架构使推理和控制的更改更加简单有助于循序渐进的原型设计可以作为培训的基础。软件架构与用户对系统的功能性需求没有直接的对应关系反应非功能性需求。架构的 4 1 视图 Kruchten在1995年提出了一个“41”的视图模型。“41”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件架构。每一个视图只关心系统的一个侧面5个视图结合在一起才能反映系统的软件架构的全部内容。逻辑视图主要支持系统的功能需求即系统提供给最终用户的服务。逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统且描述对象模型和对象之间的关系。开发视图也称为模块视图主要侧重于软件模块的组织和管理。开发视图通过系统输入输出关系的模型图和子系统图来描述。可以在确定了软件包含的所有元素之后描述完整的开发角度也可以在确定每个元素之前列出开发视图原则。进程视图也称为过程视图。侧重于系统的运行特性主要关注一些非功能性的需求例如系统的性能和可用性。进程视图强调并发性、分布性、系统集成性和容错能力以及逻辑视图中的主要抽象的进程结构。进程视图可以描述成多层抽象每个级别分别关注不同的方面。物理视图主要考虑如何把软件映射到硬件上它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。场景可以看作是那些重要系统活动的抽象它使四个视图有机地联系起来从某种意义上说场景是最重要的需求抽象。在开发架构时它可以帮助设计者找到架构的构件和它们之间的作用关系。同时也可以用场景来分析一个特定的视图或描述不同视图构件间是如何相互作用的。场景可以用文本表示也可以用图形表示。逻辑视图和开发视图描述系统的静态结构而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说侧重的角度也有所不同。例如对于管理信息系统来说比较侧重于从逻辑视图和开发视图来描述系统而对于实时控制系统来说则比较注重于从进程视图和物理视图来描述系统。架构描述语言ADL ADLArchitecture Description Language是一种形式化语言它在底层语义模型的支持下为软件系统的概念体系结构建模提供了具体化语法和概念框架。如 Aesop、MetaH、C2、Rapide、SADL、Unicon等。 ADL三个基本元素构件也称为组件包括组件和组件接口。计算或数据存储单元包括构件和相应的构件接口连接件用于构件之间交互建模的体系结构构造块及其支配这些交互的规则架构配置描述体系结构的构件和连接件的连接图 ADL是建模用的是一些伪代码基于架构的软件开发方法ABSD 基于架构的软件设计ABSDArchitecture-Based Software Design是一种架构驱动方法架构驱动也就是说架构先行需求获取和分析还没有完成就开始架构设计需求获取和分析与架构设计并行例如产品线系统和长期运行的系统我们不可能开始就能决定所有的需求。 ABSD强调由业务【商业】、质量和功能需求的组合驱动架构设计强调采用视角和视图来描述软件架构采用用例描述功能需求和质量场景描述质量需求来描述需求。 ABSD方法有三个基础第一个基础是功能的分解。在功能分解中ABSD方法使用已有的基于模块的内聚和耦合技术。第二个基础是通过选择架构风格来实现质量和业务需求。第三个基础是软件模板的使用。再次强调视角与视图从不同的视角来检查所以会有不同的视图。用例用来捕获功能需求、特定场景【刺激、环境、响应】用来捕获质量需求。另外 ABSD方法是一个自顶向下递归细化的方法软件系统的体系结构通过该方法得到细化直到能产生软件构件和类。ABSD能很好的【支持软件重用】。软件系统的体系结构通过该方法得到细化直到能产生软件构件和类。 ABSD的开发模型ABSDM 传统的软件开发过程包括问题定义需求分析软件设计实现测试。 ABSD把整个软件过程分成六个部分架构需求设计文档化复审实现演化六个步骤。 ABSDABSDM模型的开发过程软件架构风格架构风格反映了领域中众多系统所共有的结构和语义特性并指导如何将各个构件有效地组织成一个完整的系统。架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。经典五大架构风格五大架构风格子风格数据流风格Data Flow批处理Batch Sequential管道-过滤器Pipes and Filters调用/返回风格Call/Return主程序/子程序MainProgram and Subroutine面向对象Object-oriented层次结构Layered System独立构件风格Independent Components进程通信Communicating Processes事件驱动系统(隐式调用)Event System虚拟机风格Virtual Machine解释器interpreter规则系统Rule-based System仓库风格以数据中心Data-centered数据库系统Database System黑板系统Blackboard System超文本系统Hypertext System 五大架构风格常考关键字汇总架构风格简介关键字与示例数据流 - 批处理一个接一个以整体为单位某种方式处理数据修改后用别的形式写回数据。日志分析、计费、数据仓库数据流 - 管道过滤器一个接一个前一个输出是后一个的输入每个阶段都有输入和输出读输入经过处理产生输出。传统编译器是管道过滤器风格UNIX管道调用/返回 - 主程序/子程序显示调用主程序直接调用子程序开发语言主动调用程序调用/返回 - 面向对象对象是构件通过对象调用封装的方法和属性面向对象的开发语言具有封装性一个对象改变不会影响其它对象调用/返回 - 层次结构分层每层最多影响其上下两层有调用关系为上层提供服务使用下层的服务只能见到自己邻近的层上层知道下层身份不能调整层次之间的顺序如TCP/IP协议独立构件 - 进程通信进程间独立的消息传递点对点、同步或异步、远程方法调用构件之间不直接交互通过网络、管道、信号直接通信投递消息或者通过共享内存、消息队列、发布订阅模式间接通信独立构件 - 事件驱动隐式调用不直接调用通过事件驱动事件触发推动动作。构件不直接调用一个过程触发或者广播一个或多个事件。如程序语言的语法高亮、语法错误提示、断点调试、新闻公众号订阅虚拟机 - 解释器解释自定义的规则解释引擎、存储区、数据结构等执行效率较低JVM自定义游戏自定义地图自定义流程、灵活定义虚拟机 - 规则系统规则库、规则集、规则解释器、选择器和工作内存常用于DSS和人工智能机器人人工智能DSS引入规则库按照规则引擎仓库 - 数据库数据共享、共享数据源独立的处理单元、中央共享数据主动提供数据共享现代IDE集成开发环境以数据为中心也称数据共享风格剪切板、仓库风格、注册表/共享仓库仓库 - 黑板知识源、黑板(共享数据)和控制三部分全局数据库。。被动提供数据且不确定顺序的更新共享数据存储区语音识别、知识推理、图像处理、模式识别等仓库 - 超文本网状链接多用于互联网静态网页、任意跳转数据流风格批处理序列批处理风格的每一步处理都是独立的并且每一步是顺序执行的。数据必须是完整的以整体的方式传递。管道/过滤器在管道/过滤器风格的软件架构中每个构件都有一组输入和输出构件读输入的数据流经过内部处理然后产生输出数据流。调用/返回风格主程序/子程序主程序/子程序风格是结构化开发时期的经典架构风格。这种风格一般采用单线程控制把问题划分为若干处理步骤构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制即充当连接件。面向对象风格这种风格的构件是对象或者说是抽象数据类型的实例。对象是一种被称作管理者的构件它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。层次结构风格层次系统组织成一个层次结构每一层为上层服务并作为下层客户。在一些层次系统中除了一些精心挑选的输出函数外内部的层只对相邻的层可见独立构件风格进程通信构件是独立的过程连接件是消息传递构件通常是命名过程消息传递的方式可以是点对点异步或者同步的方式以及远程过程方法调用等。事件驱动的系统构件不直接调用一个过程而是触发或广播一个或多个事件。这种风格中的构件是匿名的过程它们之间交互的连接件往往是以过程之间的隐式调用implicit invocation来实现的。基于事件的隐式调用风格的主要优点是为软件复用提供了强大的支持为构件的维护和演化带来了方便其缺点是构件放弃了对系统计算的控制。虚拟机风格解释器解释器通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机可以仿真硬件的执行过程和一些关键应用其缺点是执行效率比较低。基于规则的系统基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存一般用在人工智能领域和DSS中。仓库风格数据库系统数据库系统是仓库风格最常见的形式。在数据库系统中构件主要有两大类一类是中央共享数据源保存当前系统的数据状态另一类是多个独立处理单元处理单元对数据元素进行操作。黑板系统黑板系统包括知识源、黑板和控制三个部分。知识源包括若干独立计算的不同单元提供解决问题的知识。知识源响应黑板的变化也只修改黑板黑板是一个全局数据库包含问题域解空间的全部状态是知识源相互作用的唯一媒介知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中例如信号处理、问题规划和编译器优化等。超文本系统超文本系统中出现的构件以网状链接方式相互连接用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。超文本是一种非线性的网状信息组织方法它以结点为基本单位链作为结点之间的联想式关联。超文本系统通常应用在互联网领域。闭环控制架构过程控制 C2架构风格软件架构风格 - 风格判断题目题目给大类选大类给小类选小类问Java程序可以做到“一次编写到处运行”从架构风格上看符合风格的特点。答虚拟机风格问在网络通信中进行包的解析一般先进行包头的分离然后进行报文解析及后续处理根据这一特点选用风格最合适。答解析数据分层逐次操作数据流风格问某公司欲开发一个基于图形用户界面的集成调试器。该调试器的编辑器和变量监视器可以设置调试断点。当调试器在断点处暂停运行时编辑程序可以自动卷屏到断点变量监视器刷新变量数值。针对这样的功能描述采用的架构风格最为合适。答集成调试器调试器中有多个部件强调可设置断点断点处都触发操作独立构件风格中的事件驱动。问某游戏公司欲开发一个大型多人即时战略游戏游戏设计的目标之一是能够支持玩家自行创建战役地图定义游戏对象的行为和之间的关系。针对该目标公司应该采用架构风格最为合适。四选一管道-过滤器、隐式调用、主程序-子程序、解释器答支持自行创建自定义规则虚拟机风格的解释器问某公司承接了一个开发家用空调自动调温器的任务调温器测量外部空气温度根据设定的期望温度控制空调的开关。根据该需求公司应采用架构风格最为合适。四选一解释器、过程控制、分层、管道-过滤器答过程控制/闭环控制架构风格问某公司欲开发一个语音识别系统语音识别的主要过程包括分割原始语音信号、识别音素、产生候选词、判定语法片断、提供语义解释等。每个过程都需要进行基于先验知识的条件判断并进行相应的识别动作。针对该系统的特点采用架构风格最为合适。四选一解释器、面向对象、黑板、隐式调用答语音识别仓库风格中的黑板系统问某公司欲开发一个漫步者机器人用来完成火星探测任务。机器人的控制者首先定义探测任务和任务之间的时序依赖性机器人接受任务后需要根据自身状态和外界环境进行动态调整最终自动完成任务。针对这些需求该机器人应该采用架构风格最为合适。四选一解释器、主程序-子程序、隐式调用、管道-过滤器答有自定义的情况虚拟机风格的解释器。另外其中隐式调用其实就是事件驱动对应的显示调用调用/返回风格问某公司拟开发一个扫地机器人。机器人的控制者首先定义清洁流程和流程中任务之间的关系机器人接受任务后需要响应外界环境中触发的一些突发事件根据自身状态进行动态调整最终自动完成任务。针对上述需求该机器人应该采用架构风格最为合适。四选一面向对象、主程序-子程序、规则系统、管道-过滤器答有自定义的情况虚拟机风格的解释器。如果没有解释器风格就选择大类虚拟机风格或者是虚拟机风格下的规则系统问Windows操作系统在图形用户界面处理方面采用的核心架构风格是风格。答图形用户界面独立构件风格中的事件驱动例题解析第一空字眼“程序源代码作为整体依次在不同模块中进行传递”符合“顺序批处理”的特点。第二空字眼“支持代码的增量修改与处理”又有“IDE”集成开发环境符合仓库风格仓库风格是以数据为中心的所以这里选择“数据共享”。第三空字眼“触发”符合独立构件风格中的事件驱动也就是“隐式调用”。第四空设计模式的考察设计模式和架构设计是相辅相成的字眼“适应性改造”选择“适配”。第五空字眼“模拟新操作系统”符合“虚拟机”特点。层次架构风格二层C/S架构客户机/服务器Client/ServerC/S架构是基于资源不对等且为实现共享而提出来的是20世纪90年代成熟起来的技术C/S架构定义了工作站客户应用程序如何与服务器相连以实现数据和应用分布到多台计算机上。服务器负责有效地管理系统的资源其主要任务集中于对DBMS的管理和控制以及数据的备份与恢复客户应用程序的主要任务是提供用户与数据库交互的界面向服务器提交用户请求并接收来自服务器的信息对存在于客户端的数据执行应用逻辑要求。这是一种“胖客户机fat client、瘦服务器thin server”的架构其处理流程如下图其主要特点开发成本较高客户端程序设计复杂信息内容和形式单一用户界面风格不一软件移植困难软件维护和升级困难新技术不能轻易应用其缺点服务器的负荷太重难以管理大量的客户机系统的性能容易变坏。数据安全性不好。因为客户端程序可以直接访问数据库服务器那么在客户端计算机上的其他程序也可想办法访问数据库服务器从而使数据库的安全性受到威胁。三层C/S架构与二层C/S架构相比在三层C/S架构中增加了一个应用服务器。可以将整个应用逻辑驻留在应用服务器上而只有表示层存在于客户机上。这种客户机称为瘦客户机thin client。三层C/S架构将应用系统分成表示层、功能层和数据层三个部分如下图表示层表示层是系统的用户接口部分担负着用户与系统之间的对话功能。它用于检查用户从键盘等输入的数据显示输出的数据。功能层功能层也称为业务逻辑层是将具体的业务处理逻辑编入程序中。例如在制作订购合同时要计算合同金额、按照预定的格式配置数据、打印订购合同而处理所需的数据则要从表示层或数据层取得。数据层数据层相当于二层C/S架构中的服务器负责对DBMS的管理和控制。与传统的二层架构相比三层C/S架构具有以下优点允许合理地划分三层的功能使之在逻辑上保持相对独立性从而使整个系统的逻辑结构更为清晰能提高系统的可维护性和可扩展性。允许更灵活、有效地选用相应的平台和硬件系统使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层并且这些平台和各个组成部分可以具有良好的可升级性和开放性。系统的各层可以并行开发各层也可以选择各自最适合的开发语言使之能并行且高效地进行开发达到较高的性能价格比。对每一层的处理逻辑的开发和维护也会更容易些。利用功能层可以有效地隔离表示层与数据层未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层这就为严格的安全管理奠定了坚实的基础。 B/S架构在B/S架构中除了数据库服务器外应用程序以网页形式存放于Web服务器上用户运行某个应用程序时只须在客户端的浏览器中键入相应的网址调用Web服务器上的应用程序并对数据库进行操作完成相应的数据处理工作最后将结果通过浏览器显示给用户。基于B/S架构的软件系统安装、修改和维护全在服务器端解决。用户在使用系统时仅仅需要一个浏览器就可运行全部的模块真正达到了“零客户端”的功能很容易在运行时自动升级。另外B/S架构也有一些缺点存在 B/S架构缺乏对动态页面的支持能力没有集成有效的数据库处理功能B/S架构的安全性难以控制采用B/S架构的应用系统在数据查询等响应速度上要远远低于C/S架构B/S架构的数据提交一般以页面为单位数据的动态交互性不强,不利于OLTP应用混合架构风格实现困难成本较高。其它架构风格富互联网RIA架构为了弥补B/S架构存在的一些不足提高用户体验富互联网应用Rich Internet ApplicationRIA技术应运而生。富互联网架构的特点 RIA结合了C/S架构反应速度快、交互性强的优点以及B/S架构传播范围广及容易传播的特性RIA简化并改进了B/S架构的用户交互数据能够被缓存在客户端从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面本质上还是零客户端借助于高速网速实现必要插件在本地的快速缓存增强页面对动态页面的支持能力如小程序等 MVC架构风格 MVC架构既是架构模式也是设计模式。 MVC分为主动和被动两种MVC模型。主动MVC有对模型的观察机制会把数据主动返回到View。主动MVC能推送数据给视图但被动模型是没有的。主动MVC就是引入了观察者模式来实现了向视图的推送信息。如下 Model(模型是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。View(视图是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。Controller(控制器是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据控制用户输入并向模型发送数据。 MVP架构风格 MVP的所有的操作都要经过Presenter。MVC中的C主要做事件的分发并不做事件业务的处理。而P层可以处理业务逻辑。MVP比MVC更加容易进行工程化测试。 MVC和MVP的一个最大的区别就是View和Model是否有交互。所以MVP在耦合程度上是更加有优势的。 MVP是MVC的变种模型与视图完全分离可以修改视图而不影响模型。 MVP实现了V与M之间的解耦V不直接使用M修改V不会影响M。 MVP更好的支持单元测试业务逻辑在P中可以脱离V来测试这些逻辑可以将一个P用于多个V而不需要改变P的逻辑。 MVP中V要处理界面事件业务逻辑在P中MVC中界面事件由C处理。 MVVM架构风格模型驱动MDA MDA是Model Driven Architecture 的缩写也叫模型驱动架构。起源于分离系统规约和平台实现的思想MDA的主要目标是Portability可移植性Interoperability互通性Reusability可重用性。其中M为Model客观事物的抽象表示Model-Driven使用模型完成软件的分析、设计、构建、部署、维护等各开发活动A是Architecture 构成系统的部件、连接件及其约束的规约。 MDA的3种核心模型平台独立模型PIM)【平台无关模型】具有高抽象层次、独立于任何实现技术的模型。平台相关模型PSM)【平台相关模型】为某种特定实现技术量身定做让你用这种技术中可用的实现构造来描述系统的模型。PIM会被变换成一个或多个PSM。代码Code用源代码对系统的描述规约。每个PSM都将被变换成代码。 MDA是模型驱动架构由OMG定义的一个软件开发框架基于UML及其他工业标准。MDA把建模语言用作一种编程语言而不仅仅是设计语言模型在软件开发中扮演了非常重要的角色。特定领域软件架构DSSA DSSADomain Specific Software Architecture特定领域软件架构可以看做开发产品线的一个方法或理论目标就是支持一个特定领域中多应用的生成。 DSSA以一个特定问题领域为对象形成由领域参考模型、参考需求、参考架构等组成的开发基础架构支持一个特定领域中多个应用的生成。基本活动建立领域模型一个严格定义的问题域或解决域。其中垂直域是在相同领域中深入水平域是在不同领域中平移。具有普遍性使其可以用于领域中某个特定应用的开发。对整个领域的合适程序的抽象。具备该领域固定的、典型的在开发过程中的。可复用元素。领域分析机制建立过程三层次模型软件架构评估架构评估的基准是架构质量属性软件架构质量属性性能性能performance是指系统的响应能力即要经过多长时间才能对某个事件做出响应或者在某段时间内系统所能处理的事件的个数。例如同时支持1000并发响应时间小于1s显示分辨率达到4K 可用性可用性availability是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。例如主服务器故障1分钟内切换至备用服务器系统故障1小时内修复系统支持7×24小时工作安全性安全性security是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性【信息不泄露给未授权的用户】、完整性【防止信息被篡改】、不可否认性【不可抵赖】及可控性【对信息的传播及内容具有控制的能力】等特性。例如可抵御SQL注入攻击对计算机的操作都有完整记录日志审计追踪用户信息数据库授权必须保证99.9%可用可修改性可修改性modifiability是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准通过考察这些变更的代价衡量可修改性。例如更改系统报表模块必须在2人周内完成对Web界面风格进行修改修改必须在4人月内完成易用性易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类。例如界面友好新用户学习使用系统时间不超过2小时可测试性软件v可测试性是指通过测试揭示软件缺陷的容易程度。例如提供远程调试接口支持远程调试敏感点与权衡点敏感点是一个或多个构件和/或构件之间的关系的特性。权衡点是影响多个质量属性的特性是多个质量属性的敏感点。风险点是指架构设计中潜在的、存在问题的架构决策所带来的隐患。非风险点是指不会带来隐患一般以“XXX要求是可以实现或接受的”方式表达。例如对交易请求处理时间的要求将影响系统的数据传输协议和处理过程的设计敏感点假设每秒中用户交易请求的数量是10个处理请求的时间为30毫秒则“在1秒内完成用户的交易请求”这一要求是可以实现的非风险点目前对系统信用卡支付业务逻辑的描述尚未达成共识这可能导致部分业务功能模块的重复影响系统的可修改性风险点更改加密的级别将对安全性和性能产生影响权衡点评估方法软件架构评估有三种方式基于调查问卷检查表基于度量基于场景。基于调查问卷检查表是指组织相关人员进行评估这种方式最简单易行但是主观性强。基于度量强调量化指标最客观但是这种方式实施难度大因为需要评估者对系统非常熟悉不然很难量化清楚各项指标。基于场景筛选出系统的关键场景根据系统在不同场景中的表现进行评估这种方式客观程度介于2者之间这也是目前较为流行的结构评估方法。基于场景的架构评估方法场景是从风险承担者的角度与系统交互的简短描述。质量场景的6个组成部分刺激源谁造成的刺激刺激一个响应系统的情况制品系统被刺激的部分环境刺激发生时系统所处的状态响应刺激所产生的结果响应度量指标如何评估响应基于场景的方法主要有三种前2种方式用得比较多软件架构分析法SAAMSoftware Architecture Analysis Method架构权衡分析法ATAMArchitecture Tradeoff Analysis Method成本效益分析法CBAMCost Benefit Analysis Method 软件架构分析法SAAM SAAM最初用于分析架构可修改性后扩展到其它质量属性例如可移植性、可扩充性。 SAAM的主要输入是问题描述、需求说明和架构描述其分析过程主要包括场景开发、架构描述、单个场景评估、场景交互和总体评估。软件架构分析法分为6个步骤形成场景描述架构对场景进行分类和确定优先级对场景进行单个评估评估场景的相互作用形成总体评价架构权衡分析法ATAM 架构权衡分析法ATAMArchitecture Tradeoff Analysis Method是在SAAM上发展而来。核心是结合质量属性效用树对系统进行评价确定风险点、敏感点、权衡点并对系统架构做出决策和折中。整个评估过程强调以质量属性作为评估核心主要针对性能、实用性、安全性和可修改性在系统开发之前对这些质量属性进行评价和折中。 ATAM分成4个阶段如下图场景和需求收集架构视图和场景实现质量模型构造和分析质量模型折中评估参与者评估小组组织内部或外部的、扮演特定的角色项目决策者项目管理人员、重要客户代表、架构师项目干系人模块开发人员、测试人员、用户评估步骤描述ATAM方法评估小组负责人向参加会议的项目干系人介绍ATAM评估方法。描述业务动机/商业目标项目决策者从业务的角度介绍系统的概况。该描述应该包括系统最重要的功能、技术/管理/经济和政治方面的任何相关限制、与该项目相关的业务目标和上下文、主要的项目干系人以及架构的驱动因素等。描述架构/体系结构包括技术约束例如操作系统、硬件和中间件等、将与本系统进行交互的其他系统、用以满足质量属性要求的架构方法等。确定架构方法/标识体系结构通过理解架构方法来分析架构在这一步由架构设计师确定架构方法。生成质量属性效用树评估小组、设计小组、管理人员和客户代表一起确定系统最重要的质量属性目标并对这些质量目标设置优先级和细化。分析架构方法/分析体系结构这一步的主要结果是一个架构方法或风格的列表与之相关的一些问题以及设计师对这些问题的回答。通常产生一个风险列表、敏感点和权衡点列表。讨论场景和对场景分级/评论质量需求的次序项目干系人进行两项相关的活动分别是集体讨论用例场景和改变场景。用例场景是场景的一种在用例场景中项目干系人是一个终端用户使用系统执行的一些功能。一旦收集了若干个场景后必须设置优先级。评估人员通过投票表决的方式来完成。分析架构方法/分析体系结构在收集并分析了场景之后设计师就可把最高级别的场景映射到所描述的架构中并对相关的架构如何有助于该场景的实现做出解释。在这一步中评估小组要重复第6步中的工作把新得到的最高优先级场景与尚未得到的架构工作产品对应起来。在第7步中如果未产生任何在以前的分析步骤中都没有发现的高优先级场景则在第8步就是测试步骤。描述评估结果最后要把ATAM分析中所得到的各种信息进行归纳并反馈给项目干系人。ATAM的评估结果包括一个简洁的架构描述、表达清楚的业务目标、用场景集合捕获的质量属性、所确定的敏感点和权衡点的集合、有风险决策和无风险决策、风险主题的集合。图例参考质量属性效用树质量属性效用树识别质量属性并排序主要包含性能、可用性、可修改性、安全性四个方面。性能性能延时将用户数据库存储延迟到了最小值300ms提供了实时的视频图像交易吞吐量使认证服务器的平均吞吐量最大化。可修改性新增产品目录商业产品修改已小于20人月的工作量添加CORBA中间件以小于4人周的工作量更改web界面。可用性硬件故障若站点A断电要求在3秒内将任务重定向到站点B若磁盘出现故障要求在5分钟内重新启动要在1-5分钟之内检测并恢复网络故障商业软件故障。安全性数据机密性信用卡交易在99.999%的时间内是安全的客户数据库z认证在99.999%的时间内能正常工作数据完整性。质量属性效用树示例图如下成本效益分析法CBAM CBAM用来对架构设计决策的成本和收益进行建模它的基本思想是架构策略影响系统的质量属性反过来这些质量属性又会为系统的项目干系人带来一些收益称为“效用”CBAM协助项目干系人根据其投资收益率选择架构策略。CBAM可以看作是ATAM的补充在ATAM评估结果的基础上对架构的经济性进行评估。其它评估方法 SAEM方法SAABNet方法、SACMM方法、SASAM方法、ALRRA方法、AHP方法、COSMICUML方法等。软件产品线软件产品线主要由两部分组成分别是核心资源和产品集合。核心资源是领域工程的所有结果的集合是产品线中产品构造的基础。软件产品线开发有4个基本技术特点即过程驱动、特定领域、技术支持和架构为中心。与其它软件开发方法相比组织选择软件产品线的宏观上的原因有对产品线及其实现所需的专家知识领域的清楚界定对产品线的长期远景进行了战略性规划。组织选择软件产品线的原因对产品线及其实现所需要的知识领域的清楚界定。对产品线的长期远景进行了战略性规划。过程模型 - 双生命周期模型双生命周期模型分成两个重叠的生命周期领域工程和应用工程。领域工程使用DSSA主要任务有领域分析领域设计领域实现。领域工程主要任务领域分析利用现有系统的设计、架构和需求建立领域模型。领域设计用领域模型确定领域/产品线的共性和可变性为产品线设计架构。领域实现基于领域架构开发领域可重用资源构件、文档、代码生成器。应用工程领域需求分析系统设计系统实现。应用工程在领域工程结果基础上构造新产品需求分析划分领域公共需求和独特需求得出系统说明书。系统设计在领域架构基础上结合系统独特需求设计应用的软件架构。系统实现按应用架构用领域可重用资源实现领域公共需求用定制开发的构件满足系统独特需求构件新的系统。过程模型 - 三生命周期模型三生命周期模型为有多个产品线的大型企业增加企业工程流程以便在企业范围内对所有资源的创建、设计和重用提供合理规划。过程模型 - SEI模型 SEI模型基本活动分为三部分分别是核心资源开发即领域工程、产品开发即应用工程和管理。 SEI模型的主要特点循环重复是产品开发过程的特征也是核心资源开发、产品线开发以及核心资源和产品之间协作的特征。核心资源开发和产品开发没有先后之分。管理活动协调整个产品线开发过程的各个活动、对产品线的成败负责。核心资源开发和产品开发是两个互动的过程三个活动和整个产品线开发之间也是双向互动的。核心资源开发活动的目标是建立产品线的生产能力。根据输入端的产品约束、框架、生产约束、生产策略和遗留资产清单核心资产开发活动产出三项输出产品线范围。产品线范围是关于构成产品线的产品或产品线所能包括的产品的描述该描述列举了所有产品的共性和他们之间彼此的差异包括产品所提供的特征或操作、产品所表现出的性能和其他产品属性等。核心资产是产品线中产品生产的基础。这些资产包括产品共享的架构以及为贯穿产品线进行系统化重用所开发的产品组件。提供了将纳入资产库的组件接口规范。生产计划描述了如何从核心资产中生产产品。建立方式划分依据用演化方式和革命方式引入产品线开发过程基于现有产品还是开发全新的产品线。四种方式的基本特征如下演化方式革命方式基于现有产品基于现有产品架构设计产品线的架构经演化现有构件,开发产品线构件核心资源的开发基于现有产品集的需求和可预测的、将来需求的超集全新产品线产品线核心资源随产品新成员的需求而演化开发满足所有预期产品线成员的需求的核心资源将现有产品演化为产品线用软件产品线替代现有产品集全新软件产品线的演化全新软件产品线的开发组织结构软件产品线开发过程分为领域工程和应用工程相应的软件开发组织结构也应该有两个基本组成部分即负责核心资源的小组和负责产品的小组。这也是产品线开发与独立系统开发的主要区别。组织模型开发部门、商务部门、领域工程部门和层次领域工程部门。动态的组织结构根据产品线的建立方式和发展阶段、成熟程度的变化有一种组织结构向另一种组织结构演变。组织结构类型设立独立的核心资源小组不设立独立的核心资源小组动态的组织结构要成功实施产品线主要取决于以下因素对该领域具备长期和深厚的经验一个用于构建产品的好的核心资源库好的产品线架构好的管理软件资源、人员组织、过程支持构件定义定义1软件构件是一种组装单元它具有规范的接口规约和显式的语境依赖。软件构件可以被独立地部署并由第三方任意地组装。定义2构件是某系统中有价值的、几乎独立的并可替换的一个部分它在良好定义的体系结构语境内满足某清晰的功能。定义3构件是一个独立发布的功能部分可以通过其接口访问它的服务。构件系统架构特性构件系统体系结构由一组平台决策、一组构件框架和构件框架之间的互操作设计组成。构件框架是一种专用的体系结构通常围绕一些关键的机制)同时也是一组固定地作用于构件层次机制的策略。概念框架的互操作设计包括系统体系结构连接的所有框架间的互操作的规则。构件是一组通常需要同时部署的原子构件。构件和原子构件之间的区别在于大多数原子构件永远都不会被单独部署尽管它们可以被单独部署。一个原子构件是一个模块和一组资源。模块是一组类和可能的非面向对象的结构体比如过程或者函数。资源是一个类型化的项的固定集合。资源这个概念可以包含代码资源进而包含模块。问题在于除了编译器编译一个模块或包生成的资源外还可能存在其他的资源。在“纯对象”的方法中资源是外部化的不可改变的对象-―不可改变是因为构件没有持久化的标志而且复制不能被区分。构件的复用软件复用软件重用是使用已有的软件产品如设计、代码和文档等来开发新的软件系统的过程。复用的发展过程复用的维度水平复用复用不同应用领域中的软件元素如标准函数库垂直复用是在一类具有较多公共性的应用领域之间重用软件构件构件的组装第一步检索与提取构件基于关键字的检索特点树形或有向无回路图结构。刻面检索法特点利用Facet描述构件执行的功能、被操作的数据、构件应用的语境或任意其他特征。例如分多个刻面1 应用领域、2 使用环境、3 功能超文本检索法特点按照人类的联想思维方式任意跳转到包含相关概念或构件的文档。第二步理解与评价构件要复用构件准确地理解构件至关重要。特别是对构件修改使用时。为达到目的,必须要求构件的开发过程遵循公共标准。一般构件库的文档中全面而准确地说明以下内容构件的功能与行为、相关的领域知识、可适应性约束条件与例外情形、可以预见的修改部分及修改方法。第三步修改构件理想状态是直接复用构件库中现成的构件但大多数情况下必须对构件进行或多或少的修改以应对新需求。为了减少构件修改的工作量要求开发人员尽量使构件的功能、行为和接口设计更为抽象化、通用化和参数化。这样复用者即可通过对实参的选取来调整构件的功能或行为。如果这种调整仍不足以使构件适用于新系统复用者就必须借助设计信息和文档来修改构件。构件库中若无可修改使用的构件则按新需求开发构件并存入构件库。第四步组装构件组装的三种方式基于功能的组装采用子程序调用和参数传递的方式将构件组装起来。基于数据的组装仍然是传统的子程序调用与参数传递。但它所依赖的软件设计方法不再是功能分解,而是面向数据的设计方法例如Jackson系统开发方法。面向对象的组装如果从类库中检索出来的基类能够完全满足新系统的需求则可以直接应用。否则,必须以基类为父类,生成相应的子类以满足新系统的需求。构件组装失配问题由构件引起的失配包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配。由连接子引起的失配包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配。由于系统成分对全局体系结构的假设存在冲突引起的失配等。要解决失配问题首先需要检测出失配问题并在此基础上通过适当的手段消除检测出的失配问题。构件的标准构件标准规范包括OMG的CORBA、Sun的EJB/J2EE和微软的COM/DCOM/COM。 COBRA CORBA体系的主要内容包括以下几部分对象请求代理(Object Request BrokerORB)。负责对象在分布环境中透明地收发请求和响应它是构建分布对象应用、在异构或同构环境下实现应用间互操作的基础。对象服务(Object Services)。为使用和实现对象而提供的基本对象集合这些服务应独立于应用领域。公共设施(Common Facilitites)。向终端用户提供一组共享服务接口例如系统管理、组合文档和电子邮件等。应用接口 (Application Interfaces)。由销售商提供的可控制其接口的产品相应于传统的应用层表示,处于参考模型的最高层。领域接口(Domain Interfaces)。为应用领域服务而提供的接口如OMG组织为PDM系统制定的规范。四种构件实体Entity 构件需要长期持久化并主要用于事务性行为由容器管理其持久化。加工Process 构件同样需要容器管理其持久化但没有客户端可访问的主键。会话Session 构件不需要容器管理其持久化其状态信息必须由构件自己管理。负责完成服务端和客户端的交互。服务Service 构件是无状态的。构件模型伺服对象ServantCORBA对象的真正实现负责完成客户端请求。对象适配器Object Adapter用于屏蔽ORB内核的实现细节为服务器对象的实现者提供抽象接口以便他们使用ORB内部的某些功能。对象请求代理Object Request Broker解释调用并负责查找实现该请求的对象将参数传给找到的对象并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。 EJB/J2EE EJB是Sun的JavaEE服务器端组件模型设计目标与核心应用是部署分布式应用程序。EJB (Enterprise JavaBean)是J2EE(javaEE)的一部分定义了一个用于开发基于组件的企业多重应用程序的标准。EJB 构件用于封装业务逻辑使开发人员无须再担心数据访问、事务处理支持、安全性、高速缓存和迸发等琐碎任务的编程。支持的5种构件模型Applet、Servlet、JSP、EJB、Application Client。其中EJB中的BEAN分三种会话bean实现业务逻辑负责完成服务端与客户端的交互负责维护一个短暂的会话。实体bean实现O/M映射简化数据库开发工作负责维护一行稳固持久的数据。消息驱动处理并发与异常访问异步接受消息。 COM/DCOM/COM COM ⊇ DCOM ⊇ COM 参考https://blog.csdn.net/lili40342/article/details/128586533 中间件中间件是一类构件中间件是一类系统软件。中间件简化结构、屏蔽差异、利于复用。采用中间件技术的优点面向需求。即设计师集中精力于业务逻辑本身。业务的分隔和包容性。应用开发人员可以按照不同的业务进行功能的划分体现为不同的接口或交互模式。设计与实现隔离。构件对外发生作用或构件间的交互都是通过接口进行的构件使用者只需要知道构件的接口而不必关心其内部实现这是设计与实现分离的关键。隔离复杂的系统资源。架构很重要的一个功能就是将系统资源与应用构件隔离这是保证构件可复用甚至“即插即用”的基础与中间件的意图也是一致的。符合标准的交互模型。中间件则实现了架构的模型实现了标准的协议。软件复用。中间件提供了构件封装、交互规则、与环境的隔离等机制这些都为软件复用提供了方便的解决方案。提供对应用构件的管理。基于中间件的软件可以方便地进行管理因为构件总可以通过标识机制进行划分。中间件是一种独立的系统软件或服务程序分布式应用软件借助这种软件在不同的技术之间共享资源中间件位于操作系统之上管理计算资源和网络通信实现应用之间的互操作。 6个基本功能负责客户机与服务器之间的连接和通信以及客户机与应用层之间的高效率通信机制。提供应用层不同服务之间的互操作机制以及应用层与数据库之间的连接和控制机制。提供一个多层架构的应用开发和运行的平台以及一个应用开发框架支持模块化的应用开发。屏蔽硬件、操作系统、网络和数据库的差异。提供应用的负载均衡和高可用性、安全机制与管理功能以及交易管理机制保证交易的一致性。提供一组通用的服务去执行不同的功能避免重复的工作和使应用之间可以协作。类型和分类通信处理消息中间件。在分布式系统中人们要建网和制定出通信协议以保证系统能在不同平台之间通信实现分布式系统中可靠的、高效的、实时的跨平台数据传输这类中间件称为消息中间件也是市面上销售额最大的中间件产品。目前主要产品有BEA的eLink、IBM的MQSeries、TongLINK等。实际上一般的网络操作系统如Windows已包含了其部分功能。事务处理交易中间件。在分布式事务处理系统中经常要处理大量事务特别是OLTP中每项事务常常要多台服务器上的程序按顺序协调完成一旦中间发生某种故障不但要完成恢复工作而且要自动切换系统达到系统永不停机实现高可靠性运行。要使大量事务在多台应用服务器上能实时并发运行并进行负载平衡的调度实现与昂贵的可靠性机和大型计算机系统同等的功能为了实现这个目标要求中间件系统具有监视和调度整个系统的功能。BEA的Tuxedo由此而著名它成为增长率最高的厂商。数据存取管理中间件。在分布式系统中重要的数据都集中存放在数据服务器中它们可以是关系型的、复合文档型、具有各种存放格式的多媒体型或者是经过加密或压缩存放的该中间件将为在网络上虚拟缓冲存取、格式转换、解压等带来方便。Web服务器中间件。浏览器图形用户界面已成为公认规范然而它的会话能力差、不擅长做数据写入、受HTTP协议的限制等就必须进行修改和扩充形成了Web服务器中间件如SilverStream公司的产品。安全中间件。一些军事、政府和商务部门上网的最大障碍是安全保密问题而且不能使用国外提供的安全措施如防火墙、加密、认证等必须用国产产品。产生不安全因素是由操作系统引起的但必须要用中间件去解决以适应灵活多变的要求。跨平台和架构的中间件。当前开发大型应用软件通常采用基于架构和构件技术在分布式系统中还需要集成各节点上的不同系统平台上的构件或新老版本的构件由此产生了架构中间件。功能最强的是CORBA可以跨任意平台但是过于庞大JavaBeans较灵活简单很适合于做浏览器但运行效率有待改善COM模型主要适合Windows平台在桌面系统已广泛使用。由于国内新建系统多基于UNIX包括Linux和Windows因此针对这两个平台建立相应的中间件市场相对要大得多。专用平台中间件。为特定应用领域设计领域参考模式建立相应架构配置相应的构件库和中间件为应用服务器开发和运行特定领域的关键任务如电子商务、网站等。网络中间件。它包括网管、接入、网络测试、虚拟社区、虚拟缓冲等。应用服务器目前应用服务器已经成为电子商务应用中一种非常关键的中间件技术。通过它能将一个企业的商务活动安全有效地实施到Internet上实现电子商务。它并非一种传统意义上的软件而是一个可以提供通过Internet来实施电子商务的平台。在分布式、多层结构及基于构件和服务器端程序设计的企业级应用开发中它提供的是一个开发、部署、运行和管理、维护的平台。它可以提供软件“集群” 的功能因而可以让多个不同的、异构服务器协同工作、相互备份以满足企业级应用所需要的可用性、高性能、可靠性和可伸缩性等。故而从某种意义上说应用服务器提供了一个“企业级应用的操作系统”。实现 J2EE规范的应用服务器称为 J2EE 应用服务器。

查看全文

http://www.w-s-a.com/news/506540/