架构设计：策略与过程研究.ppt

架构设计：策略与过程 温 昱 wenyu@ 议程 分而治之之道 架构在软件开发中的“位置” 架构设计策略 架构设计过程 思考：C++语言的细节 思考：C++语言与分而治之 思考：动态场景 分而治之的两种方式 议程 分而治之之道 架构在软件开发中的“位置” 架构设计策略 架构设计过程 软件开发（黑盒） 功能vs.结构 软件开发（灰盒） 架构设计不仅关心结构 架构的位置 原来如此 架构在生命周期中的作用 议程 分而治之之道 架构在软件开发中的“位置” 架构设计策略 架构设计过程 策略1：全面认识需求 需求层次论 需求层次论 付诸实践 策略2：关键需求决定架构 从功能到结构 “关键需求决定架构”的原因 付诸实践 特别提醒 策略3：多视图探寻架构 4+1视图 概念图 上下文图（数据流图语法） 上下文图（Use Case语法） 策略4：尽早验证架构 原型法 可执行架构 架构框架化 总结：架构设计策略 全面认识需求 关键需求决定架构 多视图探寻架构 尽早验证架构 议程 分而治之之道 架构在软件开发中的“位置” 架构设计策略 架构设计过程 架构分析 架构设计 谢谢大家！ RUP中的可执行架构（executable architecture），即垂直进化原型。 Common spot Hot spot Framework多种分类方法: 技术框架 业务框架（针对不同领域） 白盒框架（玻璃盒为特例） 黑盒框架 灰盒框架 Application Framework Middleware Framework Infrastructure Framework 垂直框架 水平框架 * “力量是一种关系。” 结构是否适应功能？ 完成从功能到 结构的转换 真正重视非功能需求之后，需求空间平面被“拉”成了立方体。 来源：《Software Requirements》 建立自己的、多维的、 Check list式的“需求分类 图谱”。 实用！ 是防守，更是进攻！ 防守：务实，甚至不得已 进攻：为了更好的架构 来源：Ivar Jacobson 来源：Ivar Jacobson 　 　 organize documents process make a diagram explain technical writer retrieve documents access to FVS detect conflicts access to PVS detect load balance examine deliberations send / receive an e- mail participants coordinator programmer analyst designer analyst designer FVS FVS IF sources diagrams CVSlog detect detectIF PVS operate operate PVS IF load analyze analyze detectIF mails extract summary detect structure deliberation threads examineIF examine mailIF send receive make makeIF record explanation recordIF processIF process Processed organizeIF organize documents in XML retrieve retrieveIF conflicts 来源： Koichiro Ochimizu 不同时期，划分需求重要等级的尺度不同！ 著名的4+1视图…… 可根据情况增减…… 验证架构的技术可分为两种： 原型法（RUP称为可执行架构） 框架化（Framework First） *