zoukankan      html  css  js  c++  java
  • 《软件架构设计》-阅读笔记3

    3. 软件架构设计过程

    3.1 软件架构设计过程总览

    ◎ 一般的软件过程:

       概念化阶段 -> 分析阶段 -> 架构设计阶段 -> 并行开发与测试阶段 -> 验收与交付阶段
       ──┬──    ──┬─    ───┬──    ────┬────    ───┬───
           ↓            ↓            ↓                ↓                  ↓
          愿景          需求          架构           可执行系统          交付的系统

    ◎ 软件架构设计过程:

       需求分析 -> 领域建模 -> 确定关键需求 -> 概念性架构设计 -> 细化架构 -> 验证架构
       │                │    └──────┬──────┘    └────┬───┘
       │                │              概念性架构                     实际架构
       └───┬────┘                  └───────┬──────┘
            分析阶段                                    架构设计阶段

    3.2 需求分析

    3.2.1 几个概念

    ◎ 需求捕获 vs 需求分析 vs 系统分析

       * 需求捕获是获取知识的过程,知识从无到有。
       * 需求分析是挖掘和整理知识的过程,它在已掌握知识的基础上进行。
       * 系统分析?如果说需求分析致力于“做什么”,那么系统分析则涉及“怎么做”。

    3.2.2 架构师必须掌握的需求知识

    ◎ 软件架构师不必是需求捕获专家,也不必是编写《软件需求规格说明书》的专家。

       但他一定应在需求分类、需求折衷和需求变更的研究方面是专家,否则他和其他软件架构师相比,就输在了“起跑线”上。

    ◎ 软件需求的类型

                ┌ 功能需求               ┌ 运行期质量属性
       软件需求 ┤            ┌ 质量属性 ┤
                └ 非功能需求 ┤          └ 开发期质量属性
                              └ 约束

    ◎ 软件质量属性分类方式

       运行期质量属性

       * 性能 (Performance)
       * 安全性 (Security)
       * 易用性 (Usability)
       * 持续可用性 (Availability)
       * 可伸缩性 (Scalability)
       * 互操作性 (Interoperability)
       * 可靠性 (Reliability)
       * 鲁棒性 (Robustness)

       开发期质量属性

       * 易理解性 (Understandability)
       * 可扩展性 (Extensibility)
       * 可重用性 (Reusability)
       * 可测试行 (Testability)
       * 可维护性 (Maintainability)
       * 可移植性 (Portability)

    3.3 领域建模

    ◎ 就像《高效能人士的七个习惯》提到的“由内而外全面造就自己”的观点一样,对待软件开发,要具备“由内而外造就软件”的理念。

    ◎ 想让软件系统随需应变吗?请给软件一个支持变化的“心”。

    ◎ 什么是领域模型?

       领域模型是对实际问题领域的抽象表示,它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系。

    ◎ 领域建模和需求分析活动是相互伴随、互相支持、交叠演进的。

    ◎ 领域模型对软件架构乃至整个软件系统开发工作的作用:

       * 探索复杂问题、固化领域知识;
       * 决定功能范围、影响可扩展性;
       * 提供交流基础、促进有效沟通。

    3.4 确定关键需求

    ◎ 功能、质量和商业需求的某个集合“塑造”了架构。-- Len Bass, 《软件架构实践(第2版)》

    ◎ 关键需求决定架构,其余需求验证架构。

    ◎ 什么是对软件架构关键的需求?

       * 关键的功能需求。
       * 关键的质量属性需求。
       * 关键的商业需求。

    ◎ 如何确定关键需求?

                                            ┌> 确定关键功能需求     ┐
       ● -> 全面整理需求 -> 分析约束性需求 ┤                       ├> ●
                                            └> 确定关键质量属性需求 ┘

    3.5 概念性架构设计

    ◎ 概念性架构设计的步骤(这三个步骤以迭代方式进行):

       1. 鲁棒性分析;
       2. 引入架构模式;
       3. 质量属性分析。

    3.5.1 鲁棒性分析

    ◎ 所谓鲁棒性分析是这样一种方法:通过分析用例规约中的事件流,识别出实现用例规定的功能所需的主要对象及其职责,形成以职责模型为主的初步设计。

    ◎ 鲁棒性分析是从功能需求向设计方案过度的第一步,所获得的初步设计是一种理想化的职责模型,它的重点是识别组成软件系统的高级职责块、规划它们之间的关系。

    ◎ 鲁棒性分析填补了分析和设计之间的鸿沟。

    ◎ 鲁棒图包含三种元素:边界对象、控制对象和实体对象。(见书P196)

    3.5.2 引入架构模式

    ◎ 较为经典的几种架构模式:

       分层、MVC、微内核、基于元模型的架构、管道-过滤器。

    ◎ 关于架构模式的几点说明:

       * 分层
         避免名不副实的分层架构,即对各层之间交互接口和交互机制的设计严重不足。
       * 微内核
         缺点:设计和实现的复杂性;性能较低。
         优点:扩展性强,可移植性强,软件系统的生命周期长。

    3.5.3 质量属性分析

    ◎ “属性-场景-决策”表方法。举例如下:

       ┌────┬─────────┬─────────────────────┐
       │属性    │场景              │决策                                      │
       ├────┼─────────┼─────────────────────┤
       │可扩展性│数据库类型可替换  │建立数据库存取层                          │
       ├────┼─────────┼─────────────────────┤
       │        │允许加载第三方模块│采用插件机制                              │
       ├────┼─────────┼─────────────────────┤
       │...     │...               │...                                       │
       └────┴─────────┴─────────────────────┘

    3.6 细化架构设计

    ◎ 架构细化工作主要体现在基于五视图方法进行架构细化:

                          约束
                           ↓
                   ┌───────┐
       领域模型 -> │基于五视图方法│
       关键需求 -> │              │-> 架构方案
       概念架构 -> │ 进行架构细化 │
                   └───────┘
                           ↑
                          经验

    ◎ 架构细化设计的工作内容:

       ┌───────┬──────────────────────────┐
       │ 架构设计视图 │ 设计任务                                           │
       ├───────┼──────────────────────────┤
       │ 逻辑架构     │ 细化功能单元;                                     │
       │              │ 发现通用机制;                                     │
       │              │ 细化领域模型;                                     │
       │              │ 确定子系统接口和交互机制。                         │
       ├───────┼──────────────────────────┤
       │ 开发架构     │ 确定要开发或直接利用的程序包之间的依赖关系;       │
       │              │ 确定采用的技术;                                   │
       │              │ 确定采用的框架等。                                 │
       ├───────┼──────────────────────────┤
       │ 数据架构     │ 持久化数据存储方案;                               │
       │              │ 数据传递、数据复制、数据同步等策略(可选)。         │
       ├───────┼──────────────────────────┤
       │ 运行架构     │ 确定引入哪些进程与线程;                           │
       │              │ 确定主动对象、被动对象,以及控制关系;             │
       │              │ 处理进程线程的创建、销毁、通信机制、资源争用等;   │
       │              │ 协议设计。                                         │
       ├───────┼──────────────────────────┤
       │ 物理架构     │ 确定物理配置方案;                                 │
       │              │ 确定如何将目标程序映射到物理节点。                 │
       └───────┴──────────────────────────┘

    ◎ 逻辑架构设计中,“发现通用机制”是应被特别强调的。

       机制(Mechanism)是模式的实例。机制是特定上下文中重复出现的问题的特定解决方案。

       具有良好架构的系统具备概念完整性。它通过对系统架构建立一种清晰的认识来发现通用的抽象和机制。利用这种共性使最终产生的系统结构更为简单。

    3.7 实现并验证软件架构

    ◎ 好的策略必须是一再求证、测试、发现瑕疵漏洞,另想途径或方法来弥补策略不足,有时甚至得全盘放弃,重新策划。-- 张明正,《挡不住的趋势》

    ◎ 架构原型对功能性需求的实现非常有限,那么“架构验证”要验证什么?

       答案是要验证架构对质量属性需求的支持程度,包括运行期质量属性和开发期质量属性。

    ◎ 验证架构的两种方法:

       * 原型法
         对于项目型开发,常采用“原型法”。即对一组架构设计决策在非功能需求方面的满足程度进行验证。该原型往往是演进型,而非抛弃型。
       * 框架法
         对于产品型开发,采用“框架法”有更多优点。该方法将架构设计方案用框架的形式实现,并在此基础上进行评估验证。在框架实现后,在框架基础上实现部分应用的功能,即实现一个小的垂直原型,从而进行实际非功能测试和开发期质量属性评价。

  • 相关阅读:
    Visifire正式版(v1.1)发布
    [转]PSP机能强大!已能模拟运行WINDOWS系统?
    在Silverlight+WCF中应用以角色为基础的安全模式(一)基础篇之角色为基础的安全模式简介 Virus
    C#的加密解密算法,包括Silverlight的MD5算法 Virus
    MMORPG programming in Silverlight Tutorial (10)Implement the sprite’s 2D animation (Part IV)
    Game Script: Rescue Bill Gates
    MMORPG programming in Silverlight Tutorial (9)KeyFrame Animation
    MMORPG programming in Silverlight Tutorial (5)Implement the sprite’s 2D animation (Part II)
    MMORPG programming in Silverlight Tutorial (7)Perfect animation
    MMORPG programming in Silverlight Tutorial (3)Animate the object (Part III)
  • 原文地址:https://www.cnblogs.com/zql98/p/13083656.html
Copyright © 2011-2022 走看看