1. 软件架构设计

[toc]

1.1. 软件架构的概念

架构的本质
  • 软件架构为软件系统提供了一个结构、行为和属性的高级抽象。

  • 架构架构风格是特定应用领域的惯用模式,架构定义一个词汇表和一组约束

架构的“4+1”视图
  • 逻辑视图
  • 开发视图
  • 进程视图
  • 物理视图

1.2. 软件架构风格

五大架构风格
  • 数据流风格:
    • 批处理:大量整体数据、无需用户交互
    • 管道过滤器:流式数据、弱用户交互
  • 调用/返回风格:
    • 主程序/子程序
    • 面向对象
    • 层次结构
  • 独立构件风格:
    • 进程通信
    • 事件驱动系统(隐式调用):windows图形界面、断点回调
  • 虚拟机风格:
    • 解释器:适用于需要“自定义规则”的场合
    • 规则系统:适用于专家系统
  • 仓库风格:
    • 数据库系统、
    • 黑板系统:语音识别、知识推理、模式识别、知识推理
    • 超文本系统
其他风格
  • 闭环控制架构(过程控制):适合于嵌入式系统,适用于处理简单任务。经验应用:空调控温、定速巡航
  • C2风格:构件和连接件都有一个顶部和一个底部
层次架构风格
  • 两层C/S --> 三层C/S --> 三层B/S --> 混合架构
  • MVC架构风格
  • MVP架构风格:MVC的变种
  • MVVM
  • RIA架构风格
基于服务的架构SOA
  • 服务 > 构件 > 对象
  • Web Service
  • ESB:提供位置透明性的消息路由和寻址服务

1.3. 架构描述语言ADL

ADL的三个基本元素:
  • 构件:计算或数据存储单元
  • 连接件:用于构件之间交互建模的体系结构构造块及其支配这些交互的规则
  • 架构配置:描述体系结构的构建与连接件的连接图

1.4. 特定领域软件架构DSSA

基本活动
  • 领域分析:建立领域模型
  • 领域设计:获得DSSA
  • 领域实现:开发和组织可复用信息
角色
  • 领域专家:专家只提供意见,不干活
  • 领域分析人员:有经验的系统分析员
  • 领域设计人员:有经验的软件设计人员
  • 领域实现人员:有经验的程序设计人员

1.5. 基于架构的软件开发ABSD

概念
  • ABSD方法是架构驱动,即强调由业务、质量和功能需求的组合驱动架构设计
  • ABSD有三个基础。1.功能的分解。2.通过选择架构风格来实现质量和业务需求。3.软件模板的使用。
  • 采用视角与视图来描述软件架构,采用用例来描述功能需求,采用质量场景来描述质量需求。
  • ABSD 方法是一个自顶向下,递归细化的过程,软件系统的架构通过该方法得到细化,直到能产生软件构件的类。
开发过程
  • 架构需求
  • 架构设计
  • 架构文档化:输出结果为架构规则说明测试架构需求的质量设计说明书这两个文档。
  • 架构复审:目的是标识潜在的风险
  • 架构实现
  • 架构演化

1.6. 软件质量属性 & 软件架构评估

质量属性
  • 性能:系统的响应能力。增加可用资源/
  • 可靠性:
  • 可用性:系统能正常运行的时间比例。ping/echo/心跳/主动冗余
  • 安全性:审计追踪/身份验证
  • 可修改性:信息隐藏
  • 功能性
  • 可变性
  • 互操作性
评估点
  • 敏感点:一个或多个构件的特性
  • 权衡点:多个质量属性的敏感点
  • 风险点
  • 非风险点
基于场景的评估方法
  • 软件架构分析法SAAM
  • 架构权衡分析法ATAM:1.场景和需求收集。2.架构视图和场景实现。3.属性模型构造和分析。4.折中。
  • 成本效益分析法CBAM

1.7. 软件产品线

建立产品线的方式
  • 演化方式
  • 革命方式

1.8. 构件与中间件技术

构建的特性
  1. 独立部署单元
  2. 作为第三方的组装单元
  3. 没有(外部的)可见状态
基于中间件技术的优点
  1. 面向需求
  2. 业务的分隔和包容性
  3. 设计与实现隔离
  4. 隔离复杂的系统资源
  5. 符合标准的交互模型
  6. 软件复用
  7. 提供对应用构件的管理
构件的复用
  • 检索与提取构件
  • 理解与评论构件
  • 修改构件
  • 组装构件
构件标准
  • COBRA
  • COM
  • EJB

基于构件的开发模型由软件的需求分析定义、体系结构设计、构件库建 立、应用软件构建以及测试和发布 5 个阶段组成。

1.9. 软件架构文档

软件架构文档的写作应该遵循一定的原则,这些原则包括:

  • 文档要从使用者的角度进行编写;必须分发给所有与系统有关的开发人员:
  • 应该保持架构文档的即时更新,但更新不要过于频繁:
  • 架构文档中描述应该尽量避免不必要的重复;
  • 每次架构文档修改都应该记录进行修改的原则。
lisahust all right reserved,powered by Gitbook该文件最后修改时间: 2021-10-10 19:14:35

results matching ""

    No results matching ""