1、软件开发概要,吕竹青,2,1、软件开发过程,并行开发与测试阶段,架构设计阶段,验收与交付阶段,分析阶段,概念化阶段,可执行系统,交付的系统,架构文档,需求文档,愿景文档,阶段（活动） 产品,3,概念化阶段 产生的文档,愿景和范围文档模板项目名称： 编号：,4,业务目标列表项目名称： 编号：,分析阶段 架构设计阶段 并行开发与测试阶段 验收与交付阶段,5,2、需求工程,业务需求或目标需求功能需求（的层次） 用户需求 普通需求功能需求 期望需求 兴奋需求 需求开发 运行期质量需求质量需求开发期质量需求非功能需求约束需求变更控制 需求管理 需求跟踪版本控制,需 求 工 程,6,各类需求的“易变更性”
2、不同,关键需求,需求种类,易变化性,功能需求,约束需求,质量需求,7,业务规则 规则ID 说明 1. 2.,业务规则,为什么要这样做？,政府有什么要求？,如何计算？,导致对象状态变化发生原因是什么？,什么可能发生？什么不可能发生？,系统怎样知道下一步该如何做？ 是如何关联的？,用户接下来可以做什么？,这些数据之间是如何关联的？,策略,法规,数据模型,事件,对象生存期,执行者决策,公式,系统决策,从不同角度发现业务规则,8,业务规则记录表项目名称： 编写人：,建立开发人员与客户良好的合作伙伴关系 客户的权利（开发者的义务） 客户的义务（开发者的权利）,9,3、架构设计,什么是软件架构 软件架构的
3、概念很混乱。如果你问五个不同的人，可能会得到五种不同的答案。 软件架构概念主要分为两大流派：组成派：软件架构 = 组件 + 交互决策派：软件架构 = 重要决策集 组成派和决策派的概念相辅相成,10,软件架构和子系统、框架之间的关系 复杂性是层次化的。 好的架构设计必须把变化点错落有致地封装到软件系统的不同部分(即关注点分)。通过关注点分离，达到“系统中的一部分发生了变化，不会影响其他部分”的目标。 软件单元的粒度： * 粒度最小的单元通常是“类” * 几个类紧密协作形成“模块” * 完成相对独立的功能的多个模块构成了“子系统” * 多个子系统相互配合才能满足一个完整应用的需求，从而构成了软件“
4、系统” * 一个大型企业往往使用多套系统，多套系统通过互操作形成“集成系统” 软件单元的粒度是相对的。同一个软件单元，在不同场景下我们会以不同的粒度看待它 架构(Architecture)不等于框架(Framework)。 框架只是一种特殊的软件、是半成品，框架也有架构 可以通过架构框架化达到“架构重用”的目的，如很多人都在用 Spring 框架提供的控制反转和依赖注入来构建自己的架构,11,软件架构的作用 如果一个项目的系统架构(包括理论基础)尚未确定，就不应该进行此系统的全面开发。 一个缺陷充斥的系统，将始终是一个缺陷充斥的系统。 软件架构设计为什么这么难？ *因为它是跨越现实世界与计算机
5、世界之间鸿沟的一座桥。 *软件架构设计要完成从面向业务到面向技术的转换，在鸿沟上架起一座桥梁。,12,架构设计过程与策略,架构设计阶段 概 念 性 架 构实 际 架 构,确定关键需求,概念性架构设计,细化架构,验证架构,策略:需求与建模并行进行工具:类图等,策略:关键需求决定架构,策略:全面认识需求,策略:多视图探询架构,策略:尽早验证架构,13,5视图设计架构,14,概念性架构, 概念性架构通过主要的设计元素及它们之间的关系来描述系统； 概念性架构符合组成派软件架构的定义； 概念性组件往往是粗粒度的； 概念性架构设计包括一些高层次设计选择，对未来软件系统的质量和功能都起着关键影响； 概念性架
6、构重点在点明关键机制。 复杂系统的设计往往不能一蹴而就，而概念性架构就是最初的架构设计成果。,15,绑定,发布,发现,服务 注册中心,服务 请求者,服务 提供者,Web服务器的概念架构,16,实际架构,领域概念性架构实际架构技术,概念性架构往往和具体技术的应用、具体平台的选择无关，而实际架构则非常关心这些问题,17,在架构设计中，往往采用：a.现代架构模式（如分层、代理者和MVC等）b. 面向对象设计原则 “开放-闭合”原则-目标 单一职责原则 依赖倒置原则 李氏替换原则 迪米特法则 优先使用组合而不是继承 接口隔离原则c.GOF中的设计模式 d.自己的经验设计模式,实现目标的手段,18,软件
7、架构设计到什么程度,*由于项目的不同、开发团队情况的不同软件架构的设计程度会有不同 * 软件架构应当为开发人员提供足够的指导和限制,19,4、管理过程,评审过程,20,变更控制过程,21,软件需求跟踪过程,用户需求跟踪矩阵项目名称： 编号：,22,软件测试过程,输入 测试活动 输出（产品）,测试计划,测试设计,测试执行,测试总结,需求规格说明 设计说明,测试分析报告,测试记录,测试说明和数据,测试计划,23,测试记录单项目名称： 编号：,测试记录单,24,5、适度的规范化开发规范化开发固然是好的，但是以高投入为代价的。 其策略是，适用的、适度的就是好的。上游文档对下游的开发基本上能起到指导和限
8、制就行。管理过程和技术过程允许有针对性（依据项目开发周期、规模、复杂程度、项目组人员配置情况、所用技术的熟练程度和项目所在的领域知识）的剪裁。,25,小结 1、项目开始有纲领性的文件可操作的项目计划 2、项目实施过程-结合项目具体情况，恰当地运用技术过程与管理过程 3、项目结束有总结-总结报告，积累知识与财富 4、结果-三满意最终用户/客户满意开发组织因项目和/或产品在商业上的成就而高兴开发团队成员为在具有挑战性和高回报的项目中取得的成果而骄傲,26,6、案例：设备调试系统,（1）用户需求设备调试员通过使用该系统，可以查看设备状态（设备的状态信息由专门的数据采集器实时采集），发送调试命令。设备
9、调试系统用例图如右图所示。,设备调试系统用例图,27,（2）逻辑架构设计 首先根据功能需求进行概念设计，进行大粒度的职责划分。如右图所示。,设备调试系统的逻辑架构,其次对三层结构细化,用CRC（类-职责-协作者）卡 描述每层的职责和协作者,28,（3）物理架构设计 软件最终要驻留、安装或部署到硬件才能运行。软件的物理架构关注“目标程序及其依赖的运行库和系统软件”，最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求 。,逻辑层到物理层的映射,29,物理层作为组成软件系统的物理单元，最终要映射到具体的硬件，这是物理架构设计要考虑的，对于分布是软件系统的时而言
10、尤其不可或缺。如下图所示,设备调试系统的物理架构,30,根据具体需要，通过物理架构视图更明确地表达目标模块及其通讯结构。 如下图所示。,PC机,命令发送器,用户界面,消息接收器,调试机,命令接收器,命令执行器,数据采集器,消息发送器,数采器,设备,O O,设备调试系统的物理架构,31,新增非功能需求,开发架构设计 在设计中，采用哪些现成框架，哪些第三方SDK乃至哪些中间件平台，应该考虑是否由软件架构的开发架构确定下来,设备调试系统的开发架构,32,每个架构视图都应当注意满足约束性需求的要求。既然“一部分开发人员没有嵌入式开发经验”，那么架构设计方案应弥补这一点所造成的影响，让更多开发人员清楚我
11、们的架构规划 下图展示了整个系统是如何编译的：桌面部分的应用程序应用VC+，最终的cpp文件回被编译成名为module.exe的标准的Windows应用程序；而嵌入式部分应用C51，c文件和asm文件编译后的结果是可供烧写的rom-module.hex文件。这个全局性的描述无疑对没有经验的开发人员提供了实感。,设备调试系统的开发架构,33,运行架构设计 性能是软件系统运行期间所表现出来的一种质量水平，一般用系统响应时间和系统吞吐量来衡量。 运行架构关注进程、线程和对象等运行概念，以及相关的并发、同步和通讯等问题 。 为了满足高性能需求，采用了多线程的设计。,RS232异步通讯 RS232异步通讯,消息 调用,应用层, 主窗口,通讯层,应用协议模块, RS232通讯模块,嵌入层,数据上传, 中断服务程序, 轮询,设备控制协议 模块,消息调用,设备调试系统的运行架构,34,谢谢!,
