【架构】软件架构决策验证标准

为什么需要软件架构

  • 把架构视为交流工具
  • 对项目规划实施影响力
  • 关注非功能方面能力;
  • 与设计团队做出约定;
  • 为影响力分析提供支持;

企业视图:确定企业中业务流程、数据资源、信息资源、技术、面向客户的用户界面已经传输渠道,并把他们全都表示在同一张视图中。
分层视图:
IT企业视图:
架构决策
验证方式:
1)完整性:如果把某个组件放入架构中,那么该组件应该要能够维持总体架构的完整性,而不应去破坏或损害架构中的某些方面;
2)完备性:每个架构组件所具备的特征应该都得到描述和定义;
3)包含度:每个架构组件都应该位于且只能够位于架构中的某一层里;
4)有效性:要证实某个架构组件能够像预期的那样进行运作;
5)可靠性:每个架构组件都应该能在各种使用情景下运作,而且能够协调一致的运作;
6)独立性:每个架构组件都是可以分开对待的。
7)灵活性:架构组件应该能够与其他组件相集成,并且能够运用在不同的情境中;

功能模型: CBM矩阵(组件的协作,组件职责矩阵)
一个子系统可以封装一个或多个组件。
一个组件可以公布一个或多个接口;
一个接口可以公布一个或多个操作;
与一个或多个数据实体进行交互的职责,可以有组件来负担;

把各组件安排到适当的架构分层中;
物理层面组件
逻辑层面组件

操作模型:是提供一张蓝图,以演示功能组件在运作时所必须的一套网络、服务器、计算测试平台。

集成:
集成层面:
用户界面,
数据层面,
面向消息集成,
基于API的集成(同一个功能,多个实现;把多个功能合并成一个业务流程 BPM),
基于服务的集成
集成模式:
同步请求-响应模式
批次模式
同步批次请求-应答模式
异步批次请求-应答模式
存储并转发模式;
发布-订阅模式;
聚合模式;
管道与过滤模式;
消息路由模式;
消息转换器模式;

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值