- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
1软件结构设计的一般过程
* * * * * * * * * * * * * * * * * * * * * * * * * * * 软件体系结构设计 从软件设计约束与非功能需求角度谈起 基于体系结构的软件开发模型 ABSDM 基于体系结构的软件开发模型 体系结构需求 基于体系结构的软件开发模型 体系结构设计 基于体系结构的软件开发模型 体系结构文档化 文档是在系统演化的每一个阶段,系统设计与开发人员的通讯媒介,是为验证体系结构设计和提炼或修改这些设计(必要时)所执行预先分析的基础。 体系结构文档化过程的主要输出结果是体系结构需求规格说明和测试体系结构需求的质量设计说明书这两个文档。生成需求模型构件的精确的形式化的描述,作为用户和开发者之间的一个协约。 软件体系结构的文档要求与软件开发项目中的其他文档是类似的。文档的完整性和质量是软件体系结构成功的关键因素。文档要从使用者的角度进行编写,必须分发给所有与系统有关的开发人员,且必须保证开发者手上的文档是最新的。 基于体系结构的软件开发模型 体系结构复审 体系结构设计、文档化和复审是一个迭代过程。从这个方面来说,在一个主版本的软件体系结构分析之后,要安排一次由外部人员(用户代表和领域专家)参加的复审。 复审的目的是标识潜在的风险,及早发现体系结构设计中的缺陷和错误,包括体系结构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求等等。 由外部人员进行复审的目的是保证体系结构的设计能够公正地进行检验,使组织的管理者能够决定正式实现体系结构。 基于体系结构的软件开发模型 体系结构实现 基于体系结构的软件开发模型 体系结构演化 软件体系结构设计方法 软件体系结构设计已经成为大型软件系统开发过程中不可或缺的步骤,因为非功能需求的介入,这个任务变得非常复杂和随意 基于模式的设计 模式的使用在许多工程领域是普遍的,对公共设计形式的确定和共享的理解是成熟工程领域的特点之一 一个模式提供了有效的语义环境:关注点、期望的演化路径、计算范型和与其他相似系统之间的关系 依据其规模不同,模式经常被分为三个层次: 体系结构风格 (architecture styles) 设计模式 (design patterns) 编程泛型 基于模式的体系结构设计方法使用丰富的风格知识库,指导体系结构的设计,有助于分析冲突的需求和不同设计的折衷 设计模式* 设计模式概述 模式是指从某个具体的形式中得到的一种抽象,在特殊的非任意性的环境中,该形式不断地重复出现。 一个软件体系结构的模式描述了一个出现在特定设计语境中的特殊的再现设计问题,并为它的解决方案提供了一个经过充分验证的通用图示。解决方案图示通过描述其组成构件及其责任和相互关系以及它们的协作方式来具体指定。 设计模式* 设计模式概述 MVC模式 设计模式* 一个好的模式必须做到以下几点: 解决一个问题:从模式可以得到解,而不仅仅是抽象的原则或策略。 是一个被证明了的概念:模式通过—个记录得到解.而不是通过理论或推测。 描述了一种关系:模式并不仅仅描述模块,它给出更深层的系统结构和机理。 模式有重要的人为因素:所有的软件服务于人类的舒适或生活质量,而最好的模式追求它的实用性和美学 设计模式* 模式的组成成分: 模式名称 用简单的词汇描述一个设计问题、解法或者后果 问题 什么时候要使用设计模式、解释问题及其背景 用一个强制条件集来表达 解决方案必须满足的需求 必须考虑的约束 必须具有哪些期望的特性 解决方案 描述设计的基本要素,它们的关系、各自的任务以及相互之间的合作 规定了特定的结构、规定了运行期间的行为 后果 描述应用设计模式后的结果和权衡 一个简单的例子(1/2) 需求:假设在一个系统中,需要有一个数据源和多种不同的显示方式,例如,电子表格、柱状图、饼图等,不同视图中的数据需要保持一致,并且可能会在今后增加新的显示方式 如何设计这样一个系统,同时满足功能需求和非功能需求? 如果体系结构设计人员熟悉各种模式或者有一个模式列表可供参考,那么Observer模式(又称为Publish-Subscribe模式)是个可能的候选者 在Observer模式的环境描述中,“当把系统划分为一组相互协作的类时,需要维护相关对象之间的一致性。Observer模式不希望通过类的紧密耦合实现一致性,因为这样会降低它们的可复用性。” 这正是我们所需要的模式! 一个简单的例子(2/2) 基于结构描述和例子,不难设计出该系统。设计人员还知道使用这种模式的后果,例如 主体和观察者可以独立变化 复用主体,而不必复用相关的观察者 复用观察者,而不必复用相关的主体,等等 这个例子似乎是直接和完美的,但实际上,因为系统规模和复杂性的增加,应用这些模
文档评论(0)