基于架构的软件设计ABSD
三个基础
1 | 功能分解,ABSD使用已有的基于模块的内聚和耦合技术。 |
ABSD方法的输入
1 | 抽象功能需求:对功能需求进行抽象,在获取需求的时候,需要考虑到所有最终用户。 |
基于架构的软件开发模型ABSDM
ABSDM把基于架构的软件过程划分为架构需求、架构设计、架构文档化、架构复审、架构实现、架构演化等六个子过程。
一、架构需求
需求是用户对软件系统在功能、行为、性能、设计约束等方面的期望,架构需求受技术环境和架构设计师的惊艳影像。
获取需求
架构需求一般来自于 系统的质量目标、系统的业务目标、系统开发人员的业务目标。获取架构需求的目的是为了让开发出来的软件能够满足用户业务上的功能需求。
标识构件
标识构件的目的是为了生成系统的初始逻辑结构。
1 | 生成类图 |
需求评审
评审的主要内容是需求是否是真实需求、类的分组是否合理、构件是否合理。
二、架构设计
架构设计是一个迭代的过程。
提出架构模型
在架构初期,最重要的是确定架构风格,即使这个模型是理想化的,但该模型为将来实现和演化过程建立了目标。
把已标识的构建映射到软件架构中
分析构件之间的相互作用
产生软件架构
设计评审
三、架构文档化
大多数架构都是抽象的,是由一些概念上的构件组成。
文档是在系统演化的每一个阶段、系统设计和开发人员的通信媒介,视为验证架构设计和提炼或修改这些设计的基础。
架构文档化的主要输出结果是《架构需求规格说明书》和《测试架构需求的质量设计说明书》两个文档。
四、架构复审
目的是标识潜在风险,及早发现架构设计中的缺陷和错误。包括架构是否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构建划分是否合理、文档表达是否明确、goUI结案设计师够满足功能和性能的需求等。
五、架构实现
六、架构演化
由于最终用户的需求可能变化、移植时需求产生变化等情况,就必须对架构进行修改,以适应新的软件需求。
需求变化归类
让变化的需求与已有构建对应,对应不到的变动,做好记录,在后续创建新的构件应该这部分变化的需求
架构演化计划
在改变原有架构之前,必须制定一个周密的架构演化计划,为后续演化开发工作做指南。
构件变动
在演化计划的基础上新增、修改或者删除构件,根据需求变化归类决定对构件新增修改或删除。最后对构件进行功能性测试。
更新构件的相互作用
更新构建之间的控制流程
构建组装与测试
通过工具把构建的实现体组装起来,完成真个软件系统的连接与合成。最后进行整体功能和性能测试。
技术评审
评审是否符合用户需求,如果不符合,则在2-6步进行迭代。
演化后的架构
将演化后的架构在原来系统上所做的所有修改必须集成到原来的架构中,完成一次演化过程。