ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

软考笔记(八)高级系统架构师/分析师:系统架构

2021-07-08 11:00:08  阅读:212  来源: 互联网

标签:逻辑 服务 系统 软考 视图 架构 Bean 架构师


目录

软考官网 报名通道

软考架构师笔记(一):计算机系统基础

软考架构师笔记(二):计算机网络基础与信息安全

软考架构师笔记(三):操作系统基础

软考架构师笔记(四):企业信息化与系统规划

软考架构师笔记(五):系统需求工程 需求分析

软考架构师笔记(六):数据库

软考架构师笔记(七):系统分析 系统设计

软考架构师笔记(八):系统架构

软考架构师笔记(九):软件工程与项目管理

软考架构师笔记(十):系统测试 维护 稳定性

软件架构定义

软件架构为软件系统提供了一个结构、行为和属性的高级抽象,由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。

软件架构 连接需求分析 和软件设计

一般来说,架构可以分为表现层、中间层和持久层三个层次。
(1)表现层。表现层主要负责接收用户的请求,对用户的输入、输出进行检查与控制,处理客户端的一些动作,包括控制页面跳转等,并向用户呈现最终的结果信息。表现层主要采用MVC结构来实现。控制器负责接收用户的请求,并决定应该调用哪个模型来处理;然后,模型根据用户请求调用中间层进行相应的业务逻辑处理,并返回数据;最后,控制器调用相应的视图来格式化模型返回的数据,并通过视图呈现给用户。
(2)中间层。中间层主要包括业务逻辑层组件、业务逻辑层工作流、业务逻辑层实体和业务逻辑层框架四个方面。业务逻辑层组件分为接口和实现类两个部分,接口用于定义业务逻辑组件,定义业务逻辑组件必须实现的方法。通常按模块来设计业务逻辑组件,每个模块设计为一个业务逻辑组件,并且每个业务逻辑组件以多个DAO组件作为基础,从而实现对外提供系统的业务逻辑服务。业务逻辑层工作流能够实现在多个参与者之间按照某种预定义的规则传递文档、信息或任务的过程自动进行,从而实现某个预期的业务目标,或者促进此目标的实现。业务逻辑层实体提供对业务数据及相关功能的状态编程访问,业务逻辑层实体数据可以使用具有复杂架构的数据来构建,这种数据通常来自数据库中的多个相关表。业务逻辑层实体数据可以作为业务过程的部分l/O参数传递,业务逻辑层的实体是可序列化的,以保持它们的当前状态。业务逻辑层是实现系统功能的核心组件,采用容器的形式,便于系统功能的开发、代码重用和管理。
(3)持久层。持久层主要负责数据的持久化存储,主要负责将业务数据存储在文件、数据库等持久化存储介质中。持久层的主要功能是为业务逻辑提供透明的数据访问、持久化、加载等能力。

软件架构建模

结构模型:以架构的构件、连接件和其他概念来刻画结构

框架模型:不太侧重描述结构的细节而更侧重于整体的结构

动态模型:系统的“大颗粒”的行为性质

过程模型:构建系统的步骤和过程

功能模型:由一组功能构件按层次组成,下层向上层提供服务

RUP 4+1 

用例视图(Use Cases View),最初称为场景视图,关注最终用户需求,为整个技术架构的上线文环境.通常用UML用例图和活动图描述。

逻辑视图(Logical view),主要是整个系统的抽象结构表述,关注系统提供最终用户的功能,不涉及具体的编译即输出和部署,通常在UML中用类图,交互图,时序图来表述,类似与我们采用OOA的对象模型。

开发视图(Development View),描述软件在开发环境下的静态组织,从程序实现人员的角度透视系统,也叫做实现视图(implementation view)。开发视图关注程序包,不仅包括要编写的源程序,还包括可以直接使用的第三方SDK和现成框架、类库,以及开发的系统将运行于其上的系统软件或中间件, 在UML中用组件图,包图来表述。开发视图和逻辑视图之间可能存在一定的映射关系:比如逻辑层一般会映射到多个程序包等。

物理视图(Physical view )物理视图通常也叫做部署视图(deploymentview),是从系统工程师解读系统,关注软件的物流拓扑结,以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系:处理视图特别关注目标程序的动态执行情况,而物理视图重视目标程序的静态位置问题;物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。

处理视图(Process view)(进程视图) 处理视图关注系统动态运行时,主要是进程以及相关的并发、同步、通信等问题。处理视图和开发视图的关系:开发视图一般偏重程序包在编译时期的静态依赖关系,而这些程序运行起来之后会表现为对象、线程、进程,处理视图比较关注的正是这些运行时单元的交互问题,在UML中通常用活动图表述。

软件架构风格

架构设计的一个核心问题是能否达到架构级的软件复用
架构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个构件有效地组织成一个完整的系统
架构风格定义了用于描述系统的术语表和一组指导构建系统的规则

 

Garlan和Shaw对通用软件架构风格进行了分类,他们将软件架构分为数据流风格、调用/返回风格、独立构件风格、虚拟机风格和仓库风格。
(1)数据流风格:数据流风格包括批处理序列和管理/过滤器两种风格。
(2)调用/返回风格:调用/返回风格包括主程序和子程序、数据抽象和面向对象,以及层次结构。
(3)独立构件风格:独立构件风格包括进程通信和事件驱动的系统。
(4)虚拟机风格:虚拟机风格包括解释器和基于规则的系统。
(5)仓库风格:仓库风格包括数据库系统、黑板系统和超文本系统。

  • 数据流风格:批处理序列、管道-过滤器
  • 调用/返回风格:主程序/子程序、面向对象、层次结构
  • 独立构件风格:进程通信、事件驱动系统(隐式调用)
  • 虚拟机风格:解释器、基于规则的系统
  • 仓库风格:数据库系统、超文本系统、黑板系统
    “中央数据结构说明当前状态,独立构件在中央数据存储上执行。"
  • CS架构:架构是客户端和服务器架构,通过充分利用两端硬件环境的优势,将任务合理分配到Client端和Server端来实现。
  • BS架构:架构是浏览器和服务器架构,用户工作界面是通过浏览器来实现,极少部分事务逻辑在前端(Browser)实现,但是主要事务逻辑在服务器端(Server)实现。

基于服务的架构 SOA

服务是一种为了满足某项业务需求的操作、规则等的逻辑组合,它包含一系列有序活动的交互,为实现用户目标提供支持

SOA的实现方式:WebService 

SOA的实现方式:ESB  服务总线  各种服务挂到总线上,依赖总线 完成互联互通
面向服务的架构(Service-Oriented Architecture,SOA)是透过业务服务的概念来提供IT的各项基本应用功能,让这些服务可以自由地被排列组合,融会贯通,以便在未来能随时弹性配合新的需求而调整。
SOA架构只是实现和解决了服务模块间调用的互操作问题,为了更好地服务于企业应用,引入了企业服务总线(ESB)的应用架构。这一构架是基于消息中间件(Messaging Middleware)、智能路由和数据转换等技术实现的。
ESB提供了一个基于标准的松散应用耦合模式,
ESB由以下3层构成:
总线接入层:通过这一层可以使用户的各种应用接入ESB,使用ESB的各种服务。在这一层提供对多种主流应用的接入协议支持,如HTTP、JCA/J2C、NET和IBM/CICS等。同时考虑到一些客户自己定制的应用与ESB的连接,在总线接入层提供了适配器服务。
核心层:提供多种企业服务总线所需的必要服务支持,在这一层除了提供总线基本服务(如分发/订阅、队列、安全服务和仲裁服务等)外,还提供了QoS的支持(如高可用性、确保消息传输等)。微流程组合/拆分或定制
路由层:这一层是侧重在业务支持上。通过通用和标准的对象、服务模型,可以在这一层上定义可重用和基于业界标准的业务流程。

WSDL:

服务实现定义: 服务和端口
服务接口定义:绑定,端口类型,消息,类型

 

SO方法的服务建模:按照实施的阶段,服务建模可以分为服务发现、服务规约和服务实现三个阶段。

(1)服务发现。采用自上而下、自下而上和中间对齐的方式,得到候选服务。
(2)服务规约。对候选服务进行分类,根据是否便于复用和组装,是否具有业务对齐性来决定是否将服务暴露。同时,需要考虑服务的信息系统特性。服务规约还包括服务编排、服务库和服务总线中间件模式的设计等过程。
(3)服务实现。根据对业务领域的理解和现有系统的分析,将服务的实现分配到相应的服务构件中,并决定服务的实现方式。具体的实现方式既可以由现有系统暴露相关功能为服务,或者重新开发相关功能提供务,也可以由合作伙伴来提供服务。无论采用哪种方式,系统分析师都需要对于关键点进行技术可行性分析。

 

 

中间件技术

中间件是一种独立的系统软件或服务程序,可以帮助分布式应用软件在不同的技术之间共享资源

  • 负责客户机与服务器之间的连接和通信,以及客户机与应用层之间的高效率通信机制
  • 提供应用层不同服务之间的互操作机制,以及应用层与数据库之间的连接和控制机制
  • 提供多层架构的应用开发和运行的平台,以及应用开发框架,支持模块化的应用开发
  • 屏藏硬件、操作系统、网缩和数据库的差异
  • 提供应用的负载均衡和离可用性、安全机制与管理功能,以及交易管理机制,保证交易的一致性
  • 提供一组通用的服务去执行不同的功能,避免重复的工作和使应用之间可以协作

 

典型应用建构

  • J2EE 分布式多层应用程序
  • .NET
  • MVC/MVP设计模式
    MVC模式,即模型一视图一控制(Model-View-Controller)模式,它实际上是一种架构模式,是为那些需要为同样的数据提供多个视图的应用程序而设计的,它很好地体现了数据层与表示层的分离。
    MCV把应用程序分为3种对象类型。
    模型:应用问题域中包含的抽象领域知识;
    视图:将应用问题域中包含的抽象领域知识呈现给用户的方法:一个模型可以用于多个视图;
    控制器:用户界面对用户输入的响应方式。
  • Web系统架构
    负载均衡:
    基于特定软件的负载均衡(HTTP重定向)(应用层)
    反向代理负载均衡(应用层)
    基于DNS的负载均衡(传输层)
    基于NAT的负载均衡(传输层)
    混合型负载均衡

    静态算法:轮转算法、加权轮转算法、源地址哈希散列算法、目标地址哈希散列算法、随机算法
    动态算法:最小连接数算法、加权最小连接数算法、加权百分比算法
  • 面向消息中间件(Message-Oriented Middleware,MOM):利用高效可靠的消息传递机制进行平台无关的数据传递,并可基于数据通信进行分布系统的集成。通过提供消息传递和消息队列模型,可在分布环境下扩展进程间的通信,并支持多种通信协议、语言、应用程序、硬件和软件平台。
  • EJB    EJB是企业级Java构件,用于开发和部署多层结构、分布式、面向对象的Java应用系统。
    EJB分为会话Bean、实体Bean和消息驱动Bean。
    (1)会话Bean:用于实现业务逻辑,它可以是有状态的,也可以是无状态的。每当客户端请求时,容器就会选择一个会话Bean来为客户端服务。会话Bean可以直接访问数据库,但更多时候,它会通过实体Bean实现数据访问。
    (2)实体Bean:用于实现O/R映射,负责将数据库中的表记录映射为内存中的实体对象。事实上,创建一个实体Bean对象相当于新建一条记录;删除一个实体Bean会同时从数据库中删除对应记录;修改一个实体Bean时,容器会自动将实体Bean的状态和数据库同步。
    (3)消息驱动Bean:EJB3.0中引入的新的企业Bean,它基于JMS消息,只能接收客户端发送的JMS消息后处理。MDB实际上是一个异步的无状态会话Bean,客户端调用MDB后无须等待,立刻返回,MDB将异步处理客户请求。这适合于需要异步处理请求的场合,如订单处理,这样就能避免客户端长时间地等待一个方法调用直到返回结果。
  •   CORBA服务端构件模型中,
    (1)伺服对象(Servant):CORBA对象的真正实现,负责完成客户端请求。
    (2)对象适配器(Object Adapter):用于屏蔽ORB内核的实现细节,为服务器对象的实现者提供抽象接口,以便它们使用ORB内部的某些功能。
    (3)对象请求代理(Object Request Broker):解释调用并负责查找实现该请求的对象,将参数传给找到的对象,并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。

 

软件架构 评估

风险点

非风险点

敏感点:是实现一个特定质量属性的关键特征,该特征为一个或多个软件构件所共有。

权衡点:系统权衡点会影响一个或多个属性,并对于多个属性来说都是敏感点。

 

标签:逻辑,服务,系统,软考,视图,架构,Bean,架构师
来源: https://www.cnblogs.com/yujixuan/p/14973904.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有