- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
* 4.3 模型及其规约 在分析阶段和设计阶段建立的系统模型分别称为OOA模型和OOD模型 正规理解:一个系统模型,应包括建模过程中产生的图形、文字等各种形式的文档。因为,所谓“模型”是指某一级别上的系统抽象描述,构成这种描述的任何资料都是模型的一部分。 习惯说法:目前大部分OOA/OOD著作谈到“模型”,一般是指OOA或OOD过程中产生的图形文档。 本书采用习惯说法 ——将模型和模型规约分别讨论 OOA和OOD模型包括需求模型、基本模型和辅助模型,通过模型规约 做详细说明 * 基本模型——类图 面向对象的建模中最重要、最基本的模型图 集中而完整地体现了面向对象的概念 为面向对象的编程提供了直接、可靠的依据 可以从三个层次来看 对象层 特征层 关系层 需求模型——用况图 每个用况是一项系统功能使用情况的说明,把每一类参与者对每一项系统功能的使用情况确切地描述出来,便全面地定义了系统的功能需求 辅助模型——其他各种图 对类图起到辅助作用,提供更详细的建模信息,或者从不同的视角来描述系统。例如包图、顺序图、活动图等 模型规约 对上述各种模型图及其模型元素的详细而确切的定义和解释。 * OOA模型框架 基本模型:类图 模 型 规 约 需求模型: 用况图 辅助模型: 包图 顺序图 活动图 …… 对象层 特征层 关系层 * OOD模型框架 ——从两个侧面来描述 人机交互部分 数据接口部分 控制驱动部分 问题域 部分 从一个侧面看: OOD模型包括几个主要部分? 一个核心加三个外围 需 求 模 型 辅 助 模 型 类 图 模 型 规 约 从另一侧面看: OOD模型每个部分 如何用OO概念表达? 采用与OOA相同的概念及 模型组织方式 * 确定系统边界 发现参与者 定义用况 发现对象 定义对象 的特征 定义对象 间的关系 原型开发 建立模型规约 建立需求模型 建立基本模型 建立包图 建立辅助模型 建立 活动图 建立 其他图 建立 顺序图 4.4 建模过程 OOA过程 * 问题域部分设计 输入OOA模型 人机交互部分设计 控制驱动部分设计 数据接口部分设计 构件化与系统部署 向OOP输出OOD模型 OOD过程 * 4.5 OOA与OOD的关系 一致的概念与表示法 OOA和OOD采用一致的概念和表示法,从而不存在分析与设计之间的鸿沟。 不同的内容、目标和抽象层次 OOA:研究问题域和用户需求,运用面向对象的观点发现问题域中与系统责任有关的对象,以及对象的特征和相互关系。目标是建立一个直接映射问题域,符合用户需求的OOA模型。 OOD:在OOA模型基础上,针对选定的实现平台进行系统设计,按照实现的要求进行具体的设计,目标是产生一个能够在选定的软硬件平台上实现的OOD模型。 OOA模型:抽象层次较高,忽略了与实现有关的因素 OOD模型:抽象层次较低,包含了与实现平台有关的细节 * 在软件生存周期中的位置 ——可适应不同的生存周期模型 分析 (OOA) 设计 (OOD) 编程 (OOP) 测试 维护 瀑布模型 强调严格的阶段划分和前后次序 先做完OOA再进行OOD 演化 集成 测试 编程 (OOP) 设计 (OOD) 分析 (OOA) 喷泉模型 各个阶段之间没有严格的界限,其活动可以交叠和回溯 有些工作既可在OOA中进行,也可在OOD中进行 各阶段概念和表示法的一致为采用这种模型提供了条件 * OOA与OOD的分工——两种不同的观点 第二种观点的理由: (1)过分强调“分析不考虑怎么做”将使某些必须在OOA考虑的问题得不到完整的认识。 (2)把仅与问题域和系统责任有关的对象的描述在分析阶段一次完成,避免设计阶段重复地认识同一事物,减少了工作量总和。 (3)对那些与问题域和系统责任紧密相关的对象细节,分析人员比设计人员更有发言权。 (4)由于OOA和OOD概念和表示法的一致,不存在把细化工作留给设计人员的必然理由。 (5)OOA阶段建立平台无关的模型(PIM),OOD阶段针对不同的平台建立平台专用模型(PSM)可在最大程度上实现对OOA结果的复用。 关键问题:对象的特征细节(如属性的数据类型和操作流程图),是在分析时定义还是在设计时定义? 做 什 么 怎 么 做 分 析 设 计 第 一 种 观 点 问题域与 系统责任 与实现有 关的因素 分 析 设 计 第二种观点 * 4.6 从MDA看OOA与OOD的关系 模型驱动的体系结构(model-driven architecture,MDA ) 是OMG的一个技术规范,是一种加强模型能力的系统开发途径。 模型驱动( model-driven ):用
文档评论(0)