魔都网站建设,网络营销试题,百度网站官方认证怎么做,自动推广工具基于架构的软件开发方法 基于架构的软件开发方法#xff08;ABSD#xff09;概述概念与术语开发模型体系结构需求体系结构设计体系结构文档化体系结构复审体系结构实现体系结构的演化 基于架构的软件开发方法#xff08;ABSD#xff09;
基于体系结构的软件设计 (Architec… 基于架构的软件开发方法 基于架构的软件开发方法ABSD概述概念与术语开发模型体系结构需求体系结构设计体系结构文档化体系结构复审体系结构实现体系结构的演化 基于架构的软件开发方法ABSD
基于体系结构的软件设计 (Architecture-Based Software DesignABSD) 是一种软件开发方法。 强调在开发过程中首先定义系统的体系结构然后根据这个体系结构来实现系统。它有助于确保系统的结构和设计与业务需求保持一致。
概述
ABSD方法是由体系结构驱动的即指由构成体系结构的商业、质量和功能需求的组合驱动的。使用 ABSD 方法设计活动可以从项目总体功能框架明确就开始这意味着需求抽取和分析还没有完成甚至远远没有完成就开始了软件设计。 设计活动的开始并不意味着需求抽取和分析活动就可以终止而是应该与设计活动并行。特别是在不可能预先决定所有需求时例如产品线系统或长期运行的系统快速开始设计是至关重要的。 ABSD方法有3个基础。第1个基础是功能的分解。在功能分解中 ABSD方法使用已有的基于模块的内聚和耦合技术 第2个基础是通过选择体系结构风格来实现质量和商业需求。 第3个基础是软件模板的使用软件模板利用了一些软件系统的结构。
ABSD方法是递归的且迭代的每一个步骤都是清晰定义的。因此不管设计是否完成体系结构总是清晰的这有助于降低体系结构设计的随意性。
概念与术语
设计元素 ABSD 方法是一个自顶向下递归细化的方法软件系统的体系结构通过该方法得到细化直到能产生软件构件和类。 ABSD方法中使用的设计元素如下图。 在最顶层系统被分解为若干概念子系统和一个或若干个软件模板。在第2层概念子系统又被分解成概念构件和一个或若干个附加软件模板。视角与视图 考虑体系结构时要从不同的视角(Perspective) 来观察对架构的描述这需要软件设计师考虑体系结构的不同属性。用例和质量场景 用例已经成为推测系统在一个具体设置中的行为的重要技术用例被用在很多不同的场合用例是系统的一个给予用户一个结果值的功能点用例用来捕获功能需求。 在使用用例捕获功能需求的同时人们通过定义特定场景来捕获质量需求并称这些场景为质量场景。质量场景必须包括预期的和非预期的场景。
开发模型
ABSD模型把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现和演化共6个子过程如下所示。
体系结构需求
需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。 需求过程主要是获取用户需求标识系统中所要用到的构件。体系结构需求过程如下图。
需求获取 体系结构需求一般来自3个方面分别是系统的质量目标、系统的商业目标和系统开发人员的商业目标。标识构件 上图中虚框部分属于标识构件过程该过程为系统生成初始逻辑结构包含大致的构件。这一过程又可分为3步来实现。 第1步生成类图。生成类图的 CASE 工具有很多例如 Rational Rose 2000能自动生成类图。 第2步对类进行分组。在生成的类图基础上使用一些标准对类进行分组可以大大简化类图结构使之更清晰。一般地与其他类隔离的类形成一个组由概括关联的类组成一个附加组由聚合或合成关联的类也形成一个附加组。 第3步把类打包成构件。把在第2步得到的类簇打包成构件这些构件可以分组合并成更大的构件。架构需求评审 组织一个由不同代表(如分析人员、客户、设计人员和测试人员)组成的小组对体系结构需求及相关构件进行仔细地审查。 审查的主要内容包括所获取的需求是否真实地反映了用户的要求类的分组是否合理构件合并是否合理等。必要时可以在“需求获取一标识构件一需求评审”之间进行迭代。
体系结构设计
体系结构需求用来激发和调整设计决策不同的视图被用来表达与质量目标有关的信息。 体系结构设计是一个迭代过程如果要开发的系统能够从已有的系统中导出大部分则可以使用已有系统的设计过程。
提出软件体系结构模型 在建立体系结构的初期选择一个合适的体系结构风格是首要的。在这个风格的基础上开发人员通过体系结构模型可以获得关于体系结构属性的理解。此时虽然这个模型是理想化的其中的某些部分可能错误地表示了应用的特征但是该模型为将来的实现和演化过程建立了目标。把已标识的构件映射到软件体系结构中 把在体系结构需求阶段已标识的构件映射到体系结构中将产生一个中间结构这个中间结构只包含那些能明确适合体系结构模型的构件。分析构件之间的相互作用 为了把所有已标识的构件集成到体系结构中必须认真分析这些构件的相互作用和关系。产生软件体系结构 一旦决定了关键构件之间的关系和相互作用就可以在第2阶段得到的中间结构的基础上进行精化。设计评审 一旦设计了软件体系结构必须邀请独立于系统开发的外部人员对体系结构进行评审。
体系结构文档化
主要产出两种文档即架构(体系结构)规格说明测试架构(体系结构)需求的质量设计说明书。文档是至关重要的是所有人员通信的手段关系开发的成败。
体系结构复审
从体系结构开发模型的图中可以看到体系结构设计、文档化和复审是一个迭代过程。从这个方面来说在一个主版本的软件体系结构分析之后要安排一次由外部人员用户代表和领域专家参加 的复审。 复审的目的是标识潜在的风险及早发现体系结构设计中的缺陷和错误包括体系结构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求等。
体系结构实现
“实现”就是要用实体来显示出一个软件体系结构即要符合体系结构所描述的结构性设计决策分割成规定的构件按规定方式互相交互。体系结构的实现过程如下图。 虚框部分是体系结构的实现过程。 整个实现过程是以复审后的文档化的体系结构说明书为基础的每个构件必须满足软件体系结构中说明的对其他构件的责任。这些决定即实现的约束是在系统级或项目范围内给出的每个构件上工作的实现者是看不见的。
体系结构的演化
构件开发过程中用户的需求可能还有变动。在软件开发完毕正常运行后由一个单位移植到另一个单位需求也会发生变化。在这两种情况下就必须相应地修改软件体系结构以适应已发生变化的软件需求。体系结构演化过程如图。
需求变化归类 首先必须对用户需求的变化进行归类使变化的需求与已有构件对应。对找不到对应构件的变动也要做好标记在后续工作中将创建新的构件以对应这部分变化的需求。制订体系结构演化计划 在改变原有结构之前开发组织必须制订一个周密的体系结构演化计划作为后续演化开发工作的指南。修改、增加或删除构件 在演化计划的基础上开发人员可根据在第1步得到的需求变动的归类情况决定是否修改或删除存在的构件、增加新构件。最后对修改和增加的构件进行功能性测试。更新构件的相互作用 随着构件的增加、删除和修改构件之间的控制流必须得到更新。构件组装与测试 通过组装支持工具把这些构件的实现体组装起来完成整个软件系统的连接与合成形成新的体系结构。然后对组装后的系统整体功能和性能进行测试。技术评审 对以上步骤进行确认进行技术评审。评审组装后的体系结构是否反映需求变动、符合用户需求。如果不符合则需要在第2到第6步之间进行迭代。 在原来系统上所做的所有修改必须集成到原来的体系结构中完成一次演化过程。
