系统架构设计师-软件架构设计（2）

目录

一、基于架构的软件开发方法（ABSD）

        1、架构需求 

                1.1 需求获取

                1.2 标识构件

                1.3 架构需求评审

        2、架构设计

                2.1 提出架构模型

                2.2 映射构件

                2.3 分析构件的相互作用

                2.4 产生架构

                2.5 设计评审

        3、架构文档化

        4、架构复审

        5、架构实现

                5.1 分析与设计

                5.2 构件实现

                5.3 构件组装

                5.4 系统测试 

        6、架构演化

                6.1 需求变化归类

                6.2 制定架构演化计划

                6.3 构件变动

                6.4 更新构件的相互作用

                6.5 构件组装与测试

                6.6 技术评审

二、软件架构风格

        1、数据流风格

        2、调用/返回风格 

        3、独立构件风格

        4、虚拟机风格

        5、以数据为中心                

---

一、基于架构的软件开发方法（ABSD）

        概念：

        · ABSD是架构驱动，即强调由业务【商业】、质量和功能需求的组合驱动架构设计。

        · ABSD方法有三个基础。第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术；第二个基础是通过选择架构风格来实现质量和业务需求；第三个基础是软件模版的使用。

        · 视角与视图：从不同的视角来检查，所以会有不同的视图。

        · 用例用来捕获功能需求、特定场景【刺激、环境、响应】用来捕获质量需求。

         

        开发过程：     

                ABSD模型把整个软件开发过程划分为：架构需求、架构设计、架构文档化、架构复审、架构实现、架构演化。

                ABSD能很好的【支持软件重用】

                ABSD方法是一个自顶向下，递归细化的方法。

                软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。

        1、架构需求 

                1.1 需求获取

                        架构需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。如果以前有类似的系统架构的需求，我们可以从需求库中取出，加以利用和修改，以节省获取需求的时间，减少重复劳动，提高开发效率。

                1.2 标识构件

                        （1）生成类图

                        （2）对类进行分组

                                与其他隔离的类形成一个组，由概括关联的类组成一个附加组，由聚合或合成关联的类组成一个附加组

                        （3）把类打包成构件

                                把类簇打包成构件，这些构件可以分组合并成更大的构件

                1.3 架构需求评审

                        由分析人员，客户，设计人员，测试人员组成小组，检查需求是否真实，类的分组是否合理，构件的合并是否合理

        2、架构设计

                2.1 提出架构模型

                        选择一个合适的架构风格，该模型为将来的实现和演化建立了目标。

                2.2 映射构件

                        把已标识的构件映射到架构中，将产生一个中间结构，它只包含适合架构模型的构件。 

                2.3 分析构件的相互作用

                2.4 产生架构

                        当决定了关键构件之间的相互作用后，就可以在中间结构的基础上进行精化，得到软件架构。

                2.5 设计评审

                        邀请独立于系统开发的外部人员对架构进行评审。

        3、架构文档化

                 架构文档化过程的主要输出结果是架构规格说明和测试架构需求的质量设计说明书这两个文档。

                文档的完整性和质量是软件架构成功的关键因素。

                关于文档的三大注意事项：

                （1）文档要从使用者的角度进行编写。

                （2）必须分发给所有与系统有关的开发人员 。

                （3）且必须保证开发者手上的文档是最新的。

        4、架构复审

                架构复审【架构评估】的目的是标识潜在的风险，及早发现架构设计中的缺陷和错误。

        5、架构实现

                5.1 分析与设计

                        在架构说明书中，已经定义了系统中构件与构件之间的关系，构件接口约束对外唯一代表了构件，所以可以从构件库中直接查找符合接口约束的构件

                5.2 构件实现

                        必要时开发新的满足要求的构件。

                5.3 构件组装

                5.4 系统测试 

                        包括单个构件的功能性测试和被组装应用的整体功能和性能测试

        6、架构演化

                6.1 需求变化归类

                        对需求变化进行归类，使变化的需求与已有构件对应。对找不到对应构件的需求变动，在后续工作中将创建新的构件来对应。

                6.2 制定架构演化计划

                6.3 构件变动

                        修改，增加或删除构件，要对修改和增加的构件进行功能性测试。

                6.4 更新构件的相互作用

                6.5 构件组装与测试

                6.6 技术评审

                

二、软件架构风格

         架构风格定义了用于描述系统的术语表和一组指导构件系统的规则。

        1、数据流风格

                前一步的处理结果是后一步的输入内容【数据驱动】。

                优点：

                （1）松耦合【高内聚-低耦合】（2）良好的重用性/可维护性

                （3）可扩展性【标准接口适配】（4）良好的隐蔽性（5）支持并行

                缺点：

                （1）交互性差（2）复杂性较高（3）性能较差【每个过滤器都需要解析与合成数据】 

                典型实例：

                （1）传统编译器（2）网络报纹处理

                 数据流风格分两种：

                （1）批处理序列：

                        大量整体数据、无需用户交互。

                （2）管道-过滤器：

                        流式数据、弱用户交互。

                        

        2、调用/返回风格

                调用/返回风格分三种： 

                （1）主程序/子程序：面向过程。

                        主程序/子程序风格是结构化开发时期的经典架构风格。

                （2）面向对象：对象的方法调用。

                （3）分层架构风格：层与层之间的方法调用。                

                        优点：

                        （1）良好的重用性，只要接口不变可用在其它处（2）可维护性好

                        （3）可扩展性好，支持递增设计

                        缺点：

                        （1）并不是每个系统都方便分层（2）很难找到一个合适的、正确的层次抽象方法 

                        （3）不同层次之间耦合度高的系统很难实现

                        特点：

                        （1）各个层次的组件形成不同功能级别的虚拟机

                        （2）多层相互协同工作，并且实现透明

        3、独立构件风格

                独立构件风格主要强调系统中的每个构件都是相对独立的个体 ，他们之间不直接通信，以降低耦合度，提升灵活性。

                独立构件风格分两种：

                （1）进程通信

                        构件是独立的过程，连接件是消息传递。这种风格的特点是构件通常是命名过程 ，消息传递的方式可以是点到点、异步和同步方式及远过程调用等。

                        例：A服务 调用 B服务

                （2）事件驱动系统（隐式调用） 

                        构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程调用。 

                 与调用返回风格区别：事件管理机制。

                优点：

                （1）松耦合（2）良好的重用性/可修改性/可扩展性 

                缺点：

                （1）构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会响应它。而且即使它知道事件注册了哪些构件的过程，它也不能保证这些过程被调用的顺序。

                （2）数据交换问题

                （3）既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理就存在问题。

                特点：

                 系统由若干子系统构成且成为一个整体；系统有统一的目标；子系统有主从之分；每一子系统有自己的事件收集和处理机制。

        4、虚拟机风格

                 虚拟机风格分两种：

                （1）解释器：

                         

                （2）规则为中心：

                        基于规则的系统构成：规则集、规则解释器、规则/数据选择及工作内存，一般用在人工智能领域和DSS（决策支持系统）中。                        

                        

        5、以数据为中心（仓库风格）

         以数据为中心风格分三种：

        （1）数据库系统

                特点：以数据为中心。

        （2）黑板系统

                例：语音识别、知识推理。一般基于数据库系统。

        （3）超文本系统