- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
面向对象分析与设计Part 3new.ppt
CH12 迭代中的从需求到设计 从以需求为中心到以设计为中心的转移 需求:搞清楚需要做什么(是确定共同的目标而不是让别人牵着走) 设计:如何做。采取的技能、手段 迭代:不断求精 用对象思考和设计 职责分配 设计模式 UML的表示法 设计过程和结果的表示法 CH13 逻辑架构和UML的包 软件架构 软件的整体组织结构; 软件元素-〉模块-〉子系统-〉系统。这是一种构架方式。 软件的架构可以从多个方面去描述 逻辑架构 系统的层、包、框架类、类和子系统的组织方式。 部署架构 系统的进程如何分配到处理单元和网络配置。 逻辑架构和设计模式 架构模式 架构模式 大尺度和粗粒度的设计模式。 层模式。 设计模式 有关中小尺度的对象和构架设计。微观架构模式。 前面讨论的许多设计模式。 外观模式、策略模式… 习惯用法 面向语言的或者面向实现的设计。 实现的技能 为满足性能和效率的 软件的分层设计模式 背景 软件越来越复杂(参与的开发者越来越多) 变化越来越快(业务变化、规模扩大) 问题 系统的许多部分是高度聚合的,部分的变化会设计整体。 应用逻辑和人机界面绑定在一起,代码无法重用。无法将逻辑处理分布到多个计算节点上。 通用逻辑与具体应用绑定在一起,重用和分布受到限制。 开发者不好确定清晰的界限。难以开发。 变更和改进代价高昂。 分层的软件架构 软件的分层设计模式 解决方案:分层设计 层: 软件逻辑上的关系,描述软件元素的组织方式。 3层架构、 N层架构 层之间的关系: 低层为高层提供服务, 低层并不知道高层的存在 低层为更通用的服务,高层为更特定的应用 低层 高层 请求 服务 模型视图分离原则 模型—视图 只涉及领域的内聚模型定义 允许对模型和界面分别开发 变更的影响更小 多视图的可能 模型的重用 模型对象不应和视图对象连接 观察者模式 层间关系 软件的架构视图 构架视图的表现 描述分层的概念(UML的包) 关键性、说明性元素 不要描述过于通用的服务(如:字符串处理…) CH 9 领域模型—可视化概念 领域模型 Doman Model OOA中,将相关的领域(问题的论域)分解成单个的概念类或现实对象。 领域模型是概念类或者领域的现实对象(非软件对象)的可视化表示。 又称:概念模型、领域对象模型。 是业务建模的过程中的一个工件 领域模型的表示 UML中可以将领域模型表示为类图的形式 概念识别 如何找到合适的概念和对象是OOA/OOD中简单而困难的问题。 在早期应该试图捕获所有概念类 识别概念的策略 重用和修改模板 概念类分类列表 识别名词短语 分析模式和数据模型模式 概念分类列表 物理的或具体的对象 事物的描述、设计、规范 位置 交易 交易的项目 人的角色 其它事物的容器 容器里面的事物 系统之外的其他计算机、电子机械装置 抽象的名词、概念 组织 事件 过程 可以表示成一个概念 规则和策略 目录 … 根据名词短语识别概念 简单的现金支付的处理销售场景: 1. 顾客携带商品或服务到POS机前结帐. 2. 收银员开始一个新的销售 3. 收银员输入商品项的标识. 4. 系统记录销售的商品项,显示商品的描述、价格、合计. 收银员重复 3-4直道所有商品处理完毕. 5. 系统进行税金的计算.提供总额和税金。 6. 收银员告诉顾客总额并要求顾客付款. 7. 顾客付款,系统处理付款。. ... 这些都是概念吗? 自然语言问题 和系统是否有直接关系 领域建模的指导原则 步骤: 用概念分类列表和名词短语识别候选的概念类 在领域模型中描述这些概念类 在概念之间添加必要的关联以表示概念之间的关系 添加用来实现需求的必要属性 一些原则: 使用领域中已有的概念 排除不相关的概念 避免添加不属于领域的概念 领域模型的UML示例 其它领域概念 为非现实世界建模 一些领域与自然界中事物不具备相似性 电信应用 计算机网络管理 工业控制 抽取应用领域的对象 消息 协议 会话 说明和描述概念类 为了描述某中事物 如商品的规格型号等属性 对概念类中的某个属性作详细描述 领域模型—属性 领域模型中的属性的作用: 记住概念中的一些关键的描述数据 表达需求中对概念的描述 为设计模型积累素材 属性的UML表示法 概念模型中的属性类型可以不显示 属性还是引用? 属性的简单性 属性和引用的关系 用引用表示复杂的描述 实现中的值类型和引用类型 实现中的引用: C++ Class School CString name; Master * m; Class Master Datetime birthday; … 领域模型中属性设置的一些准则 属性应该是一种数据类型 数据类型和概念类---简单的无意义的和具有一定意义的。 非原始数据类型 包
文档评论(0)