

首页  思维导图  详情



架构风格

2021-09-26 20:13:19   32  举报





AI智能生成

架构风格

模版推荐

作者其他创作

大纲/内容

架构描述语言ADL

概念

一种形式化的语言

基于底层语义的工具为体系结构的表示、分析、演化、细化、设计过程等提供支持

要素

构件和构件接口

连接件

架构配置

主要的架构描述语言

Aesop

MetaH

Rapide

SADL

Unicon

WrIght

特定领域软件架构DSSA

概念

专用于一类特定类型的任务（领域）的、 在整个领域中能有效地使用的、 为成功构件应用系统限定了标准的组合结构的软件构件的集合

特定的问题领域中支持一组应用的 领域模型、参考需求、参考架构等 组成的开发基础，其目标就是支持在一个特定领域中多个应用的生成

水平域

特定领域中的同于的软件架构

垂直域

多个不同的特定领域之间的相同部分的小工具 （购物和教育都有收费系统，收费系统就是水平域）

基本活动

领域分析

获得领域模型

确定需求是领域中的系统广泛共享的， 从而建立领域模型

领域设计

获得特定领域软件架构（DSSA）

领域实现

根据领域模型和DSSA开发和组织可重用信息

四种角色

领域专家

领域分析人员

领域设计人员

领域实现人员

建立过程

定义领域范围

定义领域

三层次模型

领域开发环境

领域架构师决定核心架构

参考结构，参考需求、架构、领域模型、开发工具

应用工程师根据具体环境来将核心架构实例化

应用执行环境

操作员实现实例化后的架构

层次架构

两层C/S架构

客户端和服务器都有处理功能

不常用，开发成本较高，客户端程序设计复杂， 信息内容和形式单一、软件移植困难。新技术不能轻易应用、安全性问题、服务器压力大难以复用

三层C/S架构

将处理功能独立出来，表示层和数据层都变得简单

四个优点

逻辑独立，结构清晰，提高可维护性和可拓展性

升级性和开放性

并行开发，每层能找到最合适的语言

功能层有效的隔离表示层和数据层， 为严格的安全管理奠定了坚实的基础，整个系统的管理层次也更加合理和可控制

慎重考虑三层间的通信方法

三层B/S

是三层C/S的变种

在浏览器上

安全性难以控制

响应速度低于C/S

数据的动态交互性不强，不利于OLTP应用

混合架构风格

内外有别模型

内部CS

外部BS

查改有别模型

查询BS

修改cs

混合架构实现困难，成本高

富互联网应用RIA

小程序

面向服务的架构SOA

概念

是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义结构进行通信，不涉及底层编程接口和通信模型

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

不仅是开发方法，还具有管理上的优点，管理员可直接管理开发人员构建的相同服务。多个服务通过企业服务总线提出服务请求，由应用管理来进行处理

实施特征

从企业外部访问，随时可用

粗粒度接口

服务分级、松散耦合

可重用的服务及服务接口设计管理

标准化的接口

支持各种消息模式

精准定义的服务接口

基于服务的构件与传统构件的区别

服务构件粗粒度，传统构件细粒度

服务构件的接口标准（WSDL），传统构件常以API形式出现

服务构件的实现与语言是无关的，而传统构件常绑定某种特定的语言。

服务构件可以通过构件容器提供QoS的服务，而传统构件完全由程序代码直接控制

关键技术

发现服务

UDDI

用于web服务注册和服务查找，描述了服务的概念，定义了编程接口，供其他企业来调用

DISCO

发现公开服务的功能及交互协议

描述服务

WSDL

web服务的描述语言

XML SCHEMA

消息格式

SOAP

服务和服务请求之间的通信提供支持

REST

HTTP和XML进行基于web通信的技术

编码格式

XML

传输协议

HTTP

TCP/IP

SMTP

实现方式

WEB service

服务提供者

服务注册中心

服务请求者

服务注册表

服务注册

服务位置

服务绑定

企业服务总线

客户端

基础构件服务

核心集成服务

六点功能

提供位置透明性的消息路由和寻址服务

提供服务注册和命名的管理功能

支持多种的消息传递泛型

支持多种可以广泛使用的传输协议

支持多种数据及其仙湖转换

提供日志和监控功能

基于架构的软件开发ABSD

概念

ABSD方法是架构驱动，强调由业务、 质量和功能需求的组合驱动设计。强调 采用视角和视图来描述软件架构，采用 用例和质量属性场景来描述需求

用例描述的事功能需求

质量属性场景描述的事质量需求

需求获取和分析没完成，就开始了软件设计

三个个基础

功能的分解，使用已有的基于模块的内聚和耦合技术

选择架构风格来实现质量和业务需求

软件模板的使用，软件模板利用了一些软件系统的结构

是递归的，迭代的每一步都是清晰定义的。因此，不管是设计是否完成，架构总是清晰的，有助于降低架构设计的随意性

开发过程

在需求分析之后，概要设计之前

为了解决需求分析和软件设计之间的鸿沟问题

开发过程分类6步

体系结构需求

需求获取

标识构件

生成类图

对类进行分组

把类打包成构件

需求评审

体系结构设计

提出架构模型

映射构件

分析构件相互作用

产生架构

设计评审

体系结构文档化

架构（体系结构说明）

测试架构（体系结构）需求的质量设计说明书

体系结构复审

由外部人员参加复兴，是否满足需求，质量问题，架构划分合理性等。 若复审不通过，则返回架构设计阶段，进行重新设计，文档化，再复审

体系结构实现

复审后的文档化的机构

分析与设计

构件实现

构件组装

系统测试

架构演化

体系结构演化

需求变化归类

架构演化计划

构件变动

更新构件的相互作用

构件组装与测试

技术评审

演化后的架构

 Collect

Get Started

REST风格服务器类图

 Collect

Get Started

架构图设计：业务架构图（风格2）

 Collect

Get Started

架构图设计：系统架构图风格2

 Collect

Get Started

系统整体设计架构图-双箭头风格





0 条评论

下一页