软件架构设计案例分析

所需积分/C币:9 2014-09-30 15:42:38 5.35MB PDF
35
收藏 收藏
举报

软件架构是系统的抽象 定义了元素以及它们之间的交互 忽略了纯粹属于局部的信息,元素的细节不属于架构
何谓软件架构? ·软件架构是系统的抽象 定义了元素以及它们之间的交互 忽略了纯粹属于局部的信息,元素的细节不属 于架构 架构关注的元素外部可见属性指: ·元素提供的服务, 需要的服务, 具备的性能特性、容错特性、对共享资源的使用等 第二种定义 某个软件或计算机系统的软件架构是该系 统的一个或多个结构, 每个结构均由软件元素、这些元素的外部 可见属性、以及这些元素之间的关系组成。 架构={结构,… 结构=阮元素,外部可见属性,关系 RDBMS例:元素=模块 relational database management system关系型数据库管理系统 Q Buit M Manager H Depends- Manager 连锁超市例:元素=节点 连锐超市系统架构 后台数掘库罪器 B|决策分梢 连锁总部 连:超市配送中心系统 c通讯服务乐统 ③ 后台数居库限务器 后白数据库服务 连锁超市门系 门店A 门店日 Pn系统 架构定义综述 架构=元素+交互 架构需多角度考虑 不同角色对架构的理解 程序员说,架构就是要决定需要编写哪些类、使用哪些现成框架,程 序经理笑了 程序经理说,架构就是模块的划分和接口的定义,系统分析员笑了 分析员说,架构就是为业务领域对象的关系建模,配置管理员笑了 配置管理员说,架构就是开发出来的、以及编译过后的软件到底是个 啥结构,数据库工程师笑了 数据库工程师说,架构规定了持久化数据的结构,其他一切都不过是 对数据的操作而已,部署工程师笑了 部署工程师说,架构规定了软件部署到硬件的策略,用户笑了 用户说,架构就是决定一个个功能子系统如何划分,程序员又笑了 子系统、模块 中断服务程序 关键类 ·控制流组织 久数据单 编译铱赖关形 Pc、服务器 片机.甲故机,专用机 数据仵储格式 物理节点拓扑 Pre- Architecture阶段 Pre- architecture的故事 Pre- architecture总论 架杓师必须懂需求 需求结构化与分析约束影响 确定关键质量与关键功能 Conceptua| Architecture阶段 概念架构的故事 Conceptual Architecture总论 重大需求塑造概念架构 初步没计 高层分割 考虑非功能需求 Refined Architecture阶段 3 细化架构的故事 Refined archilecture总论 5视图方法 逻辑构 物理架构、运行架构、开发架构 数据架构的难点:数据分布 专题:非功能目标的方法论 4 故事:困扰已久的非功能问题 总论:非功能目标的设计环节 目标-场景一决策表 何谓成功的软件架构设计 好的软件架构应当具备如下品质 .良好的模化。毎ˆ模块职责明晰,模块之间松耦合,模块内部髙聚合并 合理地实现了信息隐藏 2.适应功能需求的变化,适应技术的变化。典型地,应该保持应用相关模块 和领堿通用模块的分离,抆术平台相关模块和独立于具体技术的模块相分离, 从而达到“隔离变化”的效果 ·3.对系统的动态运行有良好的规划。标识出哪些是主动模块,哪些是被动模 块一面向对象中往往是主动类和被动类,明确这些模块之间的调用关系和加 锁策略,并说明关键的进程、线程、排队、消息等机制 4.对数据的良好规划。不仅应包括数据的持久化存储方案,还可能包括数据 传递、数据复制和数据同步等策略: 5.明确、灵活的部詈规划。还往往涉及到可移植性、可伸缩性、持续可用性 和互操作性等大型企业软件特别关注的质量属性的架构策略; 成功架构设计的关键要素 ·是否遗漏了至关重要的非功能需求 ·能否驯服数量巨大且频繁变化的需求 能否从容设计软件架构的不同方面 是否及早验证架构方案并作出了调整 制定软件架构设计策略 键点 问题 危害 策略策略要点 是台遗派了至对需求的理解不系造成返工全面认弥补非功能需求的缺 关重要的非功统、不全面,对非,项目失识需求失 能需求 功能需求不够重视败 能否驯服数量对于时间和质量的耗时不少多视图 需求入架构出”的 巨大且频繁变孑盾,颁发不足,,质量不探寻架理解过于简单粗糙不 化的需求 处理草率 构 能适应实践要求 能否从地设梨构设计方案覆盖开发混乱|多视图架构是开展系统化团 计软件架构的范围严重不足许多,质量不探寻架队开发的基礓,应当 不同方面 关键决定被延迟由高 构 为不同涉众提供指导 实现人员仓促决定 和限制 是否及早验证假设架构方案是可造成返工尽早验架构设计方案应解决 架构方案并作行的,直到后期才,项目失证架构重大技术风险,并尽 出了调整 发现问题,造成大敗 早验证架构 规模返工 策略一:全面认识需求 对需求分类; 功能需求质量属性约東 对需求权衡和取 舍; 组织级 用户级 开发级 需求空间 策略二:关键需求决定架构 没有必要对所有需求进行深入分析 接受现实,采取策略 让关键需求决定架构: 功能需求数量众多,应该控制架构设计时需要详细分析的用例的个数 不同质量属性之间往往具有相互制约性,应权衡哪一部分质量属性是架 构设计的重点目标; 软件进行架构级设计和软件复杂性增长有关 分而治之的方法之所以有效,在于它把复杂的问题划分成多个相对简 单的子问题分别解决 基于多视图的架构设计方法之所以有效,在于分而治之 策略三:尽早验证架构 ·根据具体项目或产品的情况不同,有两种验证技 术可以采用 ·采用原型技术。 通过开发一个垂直演进原型,来实现软件架构。 采用框架技术。 确切地说,是框架+垂直抛弃原型。这样做的好处是利于软件产品 后期的演进和升级,对致力于开发某个领域的系列软件产品的企 业尤其有帮助; 三个经典难题 ·混乱是思维的大敌 输入乱 输出乱 不能深入全面把 不能错落有致提 握需求 供设计决策 求>架构设计架构 思维过程乱 不能系统有序进 行思维 Pre- architecture:不仅是理解需求 第1步:需求结构化 第2步:分析约束影响 第3步:确定关键质量 ·第4步:确定关键功能 影响架构的 因素多而杂 全面有序理解需求 ②民 确定关确定关分析约 键功能键质量束影响

...展开详情
立即下载 低至0.43元/次 身份认证VIP会员低至7折
一个资源只可评论一次,评论内容不能少于5个字
CHQIUU 感谢共享,非常好的案例
2020-07-22
回复
sherwinzhubuaa 感谢共享,非常好的案例!
2018-05-11
回复
您会向同学/朋友/同事推荐我们的CSDN下载吗?
谢谢参与!您的真实评价是我们改进的动力~
关注 私信
上传资源赚积分or赚钱
最新推荐