从需求分析到架构设计PPT课件

1 从需求分类到多视图架构设计方法 需要架构设计的多重视图方法 从根本上来说是因为需求种类的复杂性所致 Eg 设计一座跨江大桥 我们会考虑 连接南北的公路交通 这个 功能需求 从而初步设计出理想化的桥墩支撑的公路桥方案 然后还要考虑造桥要面临的 约束条件 这个约束条件可能是 不能影响万吨轮从桥下通过 于是细化设计方案 规定桥墩的高度和桥墩之间的间距 另外还要顾及 大桥的使用期质量属性 比如为了 能在湍急的江流中保持稳固 可以把大桥桥墩深深地建在岩石层之上 和大地浑然一体 其实 建造期间的质量属性 也很值得考虑 比如在大桥的设计过程中考虑 施工方便性 的一些措施 2 和工程领域的功能需求 约束条件 使用期质量属性 建造期间的质量属性等类似 软件系统的需求种类也相当复杂 具体分类如下图所示 3 超市系统案例 4 功能需求 简单而言 功能需求就是 软件有什么用 软件需要做什么 同时 注意把握功能需求的层次性是软件需求的最佳实践 以该超市系统为例 超市老板希望通过软件来 提高收银效率 那么 你可能需要为收银员提供一系列功能来促成这个目的 比如供收银员使用的 任意商品项可单独取消 功能有利于提供收银效率 笔者曾在超市有过被迫整单取消然后一车商品重新扫描收费的痛苦经历 而具体到这个超市系统 系统分析员可能会决定要提供的具体功能为 通过收银终端的按键组合 可以使收银过程从 逐项录入状态 进入 选择取消状态 从而取消某项商品 5 非功能需求 约束 要开发出用户满意的软件并不是件容易的事 而全面理解要设计的软件系统所面临的约束可以使你向成功迈进一步 约束性需求既包括企业级的商业考虑 例如 项目预算有限 也包括最终用户级的实际情况 例如 用户的平均电脑操作水平偏低 既可能包括具体技术的明确要求 例如 要求能在Linux上运行 又可能需要考虑开发团队的真实状况 例如 开发人员分散在不同地点 这些约束性需求当然对架构设计影响很大 比如受到 项目预算有限 的限制 架构师就不应选择昂贵的技术或中间件等 而考虑到开发人员分散在不同地点 就更应注重软件模块职责划分的合理性 松耦合性等等 6 运行期质量属性 这类需求主要指软件系统在运行期间表现出的质量水平 运行期质量属性非常关键 因为它们直接影响着客户对软件系统的满意度 大多数客户也不会接受运行期质量属性拙劣的软件系统 常见的运行期质量属性包括软件系统的易用性 性能 可伸缩性 持续可用性 鲁棒性 安全性等 在我们的超市系统的案例中 用户对高性能提出了具体要求 真正的性能需求应该量化 表1没体现 他们不能容忍金额合计超过2秒的延时 7 开发期质量属性 这类非功能需求中的某些项人们倒是念念不忘 可惜很多人并没有意识到 开发期质量属性 和 运行期质量属性 对架构设计的影响到底有何不同 开发期质量属性是开发人员最为关心的 要达到怎样的目标应根据项目的具体情况而定 而过度设计会花费额外的代价 8 什么是软件架构视图 PhilippeKruchten在其著作 Rational统一过程引论 中写道 一个架构视图是对于从某一视角或某一点上看到的系统所做的简化描述 描述中涵盖了系统的某一特定方面 而省略了于此方面无关的实体 架构要涵盖的内容和决策太多了 超过了人脑 一蹴而就 的能力范围 因此采用 分而治之 的办法从不同视角分别设计 同时 也为软件架构的理解 交流和归档提供了方便 1995年 PhilippeKruchten在 IEEESoftware 上发表了题为 The4 1ViewModelofArchitecture 的论文 引起了业界的极大关注 并最终被RUP采纳 9 设备调试系统案例 10 11 逻辑视图 设计满足功能需求的架构 应用层 负责设备状态的显示 并提供模拟控制台供用户发送调试命令 使用通讯层和嵌入层进行交互 但应用层不知道通讯的细节 通讯层 负责在RS232协议之上实现一套专用的 应用协议 当应用层发送来包含调试指令的协议包 由通讯层负责按RS232协议将之传递给嵌入层 当嵌入层发送来原始数据 由通讯层将之解释成应用协议包发送给应用层 嵌入层 负责对调试设备的具体控制 以及高频度地从数据采集器读取设备状态数据 设备控制指令的物理规格被封装在嵌入层内部 读取数采器的具体细节也被封装在嵌入层内部 12 13 开发视图 设计满足开发期质量属性的架构 软件架构的开发视图应当为开发人员提供切实的指导 任何影响全局的设计决策都应由架构设计来完成 这些决策如果 漏 到了后边 最终到了大规模并行开发阶段才发现 可能造成 程序员碰头儿临时决定 的情况大量出现 软件质量必然将下降甚至导致项目失败 其中 采用哪些现成框架 哪些第三方SDK 乃至哪些中间件平台 都应该考虑是否由软件架构的开发视图确定下来 图6展示了设备调试系统的 一部分 软件架构开发视图 应用层将基于MFC设计实现 而通讯层采用了某串口通讯的第三方SDK 14 15 在说说约束性需求 约束应该是每个架构视图都应该关注和遵守的一些设计限制 例如 考虑到 一部分开发人员没有嵌入式开发经验 这条约束情况 架构师有必要明确说明系统的目标程序是如何编译而来的 图7展示了整个系统的桌面部分的目标程序pc moduel exe 以及嵌入式模块rom module hex是如何编译而来的 这个全局性的描述无疑对没有经验的开发人员提供了实感 利于更全面地理解系统的软件架构 16 17 进程视图 设计满足运行期质量属性的架构 性能是软件系统运行期间所表现出的一种质量水平 一般用系统响应时间和系统吞吐量来衡量 为了达到高性能的要求 软件架构师应当针对软件的运行时情况进行分析与设计 这就是我们所谓的软件架构的处理视图的目标 处理视图关注进程 线程 对象等运行时概念 以及相关的并发 同步 通信等问题 18 本案例中架构师为了满足高性能需求 采用了多线程设计 应用层中的线程代表主程序的运行 它直接利用了MFC的主窗口线程 无论是用户交互 还是串口的数据到达 均采取异步事件的方式处理 杜绝了任何 忙等待 无谓的耗时 也缩短了系统响应时间 通讯层有独立的线程控制着 上上下下 的数据 并设置了数据缓冲区 使数据的接收和数据的处理相对独立 从而数据接收不会因暂时的处理忙碌而停滞 增加了系统吞吐量 嵌入层的设计中 分别通过时钟中断和RS232口中断来激发相应的处理逻辑 达到轮询和收发数据的目的 19 20 物理视图 和部署相关的架构决策 软件最终要驻留 安装或部署到硬件才能运行 而软件架构的物理视图关注 目标程序