【SWJTU】软件架构设计重点总结.docVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
【SWJTU】软件架构设计重点总结

复习知识点重点: 整理了大部分,先发给大家,如果继续整理的或者把不恰当的地方给改正了会重新上传的 整理人员:灿哥(6-10)、小黄(11-13、15)、小綦(21-25)、老卢(19、26-29)、乔哥(14、18) 水平有限,有不确切地方还请指正 组成派和决策派两种流派的软件架构概念的相同和区别 相同:1)组成派和决策派是站在不同角度的软件架构概念 2)在具体的软件架构实践中,总是同时体现两派的架构概念 区别:组成派的观点更关注软件,倾向于“组件+交互”的思想;决策派的观点更关注人,倾向于重大决策集合的思想,除了结构和行为,还关注一些非功能的因素。 分离关注点的三种方法 通过职责划分来分离关注点 利用软件系统各部分的通用性不同进行关注点的分离 通过不同粒度级别分离关注点 框架和架构的联系和区别 联系:1)框架和架构的出现,都是为了解决软件系统日益复杂所带来的困难而采取“分而治之”思维的结果。先大局后局部,就出现了架构;先通用后专用,就出现了框架。 2)为了尽早验证架构设计,可以将关键的通用机制甚至整个架构以框架的方式进行实现。 3)软件架构可以借助框架来构造。 区别:1)框架是软件,架构不是软件。 2)引入软件框架之后,整个开发过程变成了“分两步走”,而架构决策往往会体现在框架之中 3)架构是问题的抽象解决方案,他关注大局而忽略细节;而框架是通用半成品,必须根据具体需求进一步定制开发才能变成应用系统 简述软件架构的作用 软件架构的作用包括以下几个方面: 对新产品开发的作用:完成从面向业务到面向技术的转换,在鸿沟上架起一座桥梁,具体包括:上承业务目标,下接技术决策,控制复杂性,组织开发,利用迭代开发和增量交付,提高质量。 对产品线开发的作用:固化核心知识,提供可重用资源,缩短推出产品的周期,降低开发和维护总成本,提高产品质量,支持批量定制。 对软件维护的作用:软件架构是软件维护的基础。 对软件升级的作用:软件架构会限制软件的升级力度。 理解视图的概念以及多种视图多种角度进行架构设计的意义 视图概念:一个架构视图是对于从某一视角或某一点上看到的系统所作的简化描述,描述中涵盖了系统的某一特定方面,而省略了与此方面无关的实体。 多视图多角度架构设计的意义:基于多视图的架构设计方法在一定程度上将各类需求分别对待,通过不同的架构设计视图分别满足它们,从而确保重要的需求一一被满足。 概念性架构和实际架构的区别点和共同点 接口:在实际架构中,借口占据非常核心的地位;而概念性架构中没有接口的概念。 子系统:实际交媾忠实通过子系统和模块来分割整个系统;并且子系统往往有明确的接口; 而概念性架构中只有抽象的组件,这些组件没有接口只有职责,一般是处理组件、数据组件或连接组件中的一种。 交互机制:实际架构中的交互机制是“实在”的,如基于接口编程、消息机制或远程方法调用等等;而概念性构架中的交互机制是“概念化”的。 共同点:该娘型架构和实际架构都满足软件架构的该娘,无论是“架构=组件+交互”,还是“架构=重要决策集”。 软件架构设计四条策略的策略内容、针对问题和关键点 策略一:全面认识需求;内容:弥补非功能需求的缺失;关键点:是否遗漏了至关重要的非功能需求;针对问题:对需求的理解不系统、不全面,对非功能需求不够重视。 策略二:关键需求界定架构;内容:“需求入架构出”的理解过于简单粗糙不能适应实践要求;关键点:能否驯服数量巨大且频繁变化的需求;针对问题:对于时间和质量的矛盾,颁发不足,处理草率。 策略三:多视图探寻架构;内容:架构是开展系统化团队开发的基础,应当为不同涉众提供指导和限制;关键点:能否从容地设计软件架构的不同方面;针对问题:架构设计方案覆盖范围严重不足许多关键决定被延迟,由实现人员仓促决定。 策略四:尽早验证架构;内容:架构设计方案应解决重大技术风险,并尽早验证架构;关键点:是否及早验证架构方案并做出了调整;针对问题:假设架构方案是颗星的,知道后期才发现问题,造成大规模返工。 理解按问题深度和问题广度两个角度解决问题的方法在软件架构设计中的具体体现 一方面,软件架构从大局着手,就技术方面的重大问题作出决策,构造一个具有一定抽象层次的解决方案,而不是将所有熙街统统展开,从而有效地控制了“技术复杂性”,属于“按问题深度分而治之”。 另一方面,有了软件架构设计后,从而可以把不同模块分配给不同小组分头开发,独立地并行工作。对“人尽其才”也有好处,不同小组成员需要精通的技术各不相同。软件架构为开展系统化的团队开发奠定了基础,解决了“管理复杂性”问题,属于“按问题广度分而治之”。 软件架构要设计到什么程度 由于项目、开发团队情况的不同,软件架构设计的成都会有不同; 软件架构应当为开发人员提供足够的指导和限制。 常见的高来高去式架构设计三种

文档评论(0)

haocen + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档