网站大量收购独家精品文档,联系QQ:2885784924

UML 教程重点.doc

  1. 1、本文档共24页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
UML 教程 统一建模语言(UML)已经迅速变成建立面向对象软件的事实标准。本教程提供了Enterprise Architect支持的13种UML图的技术概览。UML 2 详细的语义解释请看新的UML 2 教程。 首先... 什么是UML? OMG组织规范声明 : 统一建模语言(UML)是一种图形化的语言,用于软件密集系统要素的可视化、制定规范、构建对象和编写文档。UML提供了一种标准的方式来描述系统的设计图,既包括概念方面,例如业务过程和系统功能,也包括具体事务,如编程语言语句,数据库图示和可重用的软件组件。 这里着重指出的是UML是一种说明性的“语言”,而不是一种方法或程序。UML通常用来定义软件系统与细化、编写、构造系统中的要素,是“写”设计图的语言。UML可以用不同的方式来支持软件开发方法(例如:统一软件开发过程)-但是它本身并不指定某种方法或过程。 UML 定义了下列领域的标注和语义: - 用户交互或用例模型?-描述系统和用户之间的界定和交互。在某些方面对应于一个需求模型。 - 交互或通信模型 -描述系统中的对象彼此之间如何进行交互以完成工作。 - 状态或动态模型?-状态图表描述随着时间变化,类所呈现的状态和条件。活动图则描述系统即将执行的工作流程。 - 逻辑或类模型?- 描述构成系统的类和对象。 - 物理组件模型?- 描述构成系统的软件(有时也包含硬件)。 - 物理部署模型?- 描述物理架构与物理架构中组件的部署。 UML 也定义了一些扩展机制,以扩展UML符合特别需要(例如:业务过程建模的扩展)。 第二部分 教程?展开论述如何使用UML定义和建立真实系统。 如果你有关于这些材料的任何建议和评语,请把你的想法发到sparks@。 UML 教程 - 第二部分 我们已经在第一部分建立了这样一种认识,即UML是一种用于制定软件系统构成要素和交互方式标准的语言。UML涉及6大主要方面- 从用例模型、动态和逻辑模型到最终的物理部署模型,以及允许给模型添加特别标注的扩展机制。 那么,如何使用UML呢? 一般地,UML作为软件开发过程的一部分,在具体的CASE工具支持下,用来定义所开发系统的需求,交互和元素。开发过程的确切性质则取决所采用的开发方法。一个典型的开发过程大致如下: 1. 建立一个业务过程模型。业务过程模型被用来定义发生在企业或组织内部的高级业务活动和业务过程,并且是建立用例模型的基础。一般来说业务过程模型比一个软件系统所能实现的更多(比如:业务模型包括人力和其他过程)。 2. 映射用例模型到业务过程模型以精确定义你要提供的功能,并且是站在业务用户角度考虑的。每增加一个用例时,将创建一个从适当的业务过程到该用例的可跟踪链接(如:一个实现链接)。这个映射清楚地表达新系统将提供什么样的功能来满足业务过程中所描述的业务需求。这种映射也确保系统中每个用例都是有用的。 3. 完善用例-包括需求,约束、复杂程度、注释及情形。这些信息清楚地描述用例做什么,如何做以及执行时的相关约束。这个过程要保证用例始终满足业务过程的需求,包括每个用例的系统测试定义,该定义为该用例定义了接收标准。也包括了一些用户可接受的测试脚本:这些脚本定义了用户将如何进行测试和测试接收的标准。 4. 有了业务过程模型的输入与输出和用例的详细信息,就可以开始构建领域模型(高级业务对象)、顺序图、协作图和用户接口模型。这些图描述新系统中的要素以及这些要素之间的相互作用和用户执行用例时所需各种情形的接口。 5. 在领域模型、用户接口模型和情形图的基础上,开始建立对象类模型。这是制定系统中对象的明确规范:数据、属性、行为和操作。使用继承机制,可将领域对象抽象为类层次结构。处理各种情形的消息一般被映射到类的操作。如果使用一个现存的框架或设计模式,则可能导入现存模型的元素到新系统中。为每一个类定义单元测试、集成测试和系统测试。测试目的:1)类的功能是否如所定义的,2)类与其它类及组件的交互是否如期望的。 6. 当开发类模型时,可能需要将它分解成包和组件。一个组件代表一个可使用的软件块,它是一个类或者多个类的数据和行为的结合,并严格定义一个对外提供服务的接口。所以,从类模型的角度看,构造组件模型就是定义类的逻辑包。对于每一个组件,需要定义集成测试,以证实组件的接口满足规范要求,即与其它软件元素的关系。 7. 在完成上述工作的同时,需要获取一些额外的需求并整理成文档。例如:非功能性需求,性能需求,安全需求,义务需求,发布计划等。将这些需求在模型内部进行整合并随模型的进展而更新。 8. 部署模型定义系统的物理架构。这个工作可以提前开始以便于掌握系统的物理结构特性-使用什么样的硬件、操作系统、网络规模、接口与支持软件,来构成新系统,和系统部署在

文档评论(0)

4477704 + 关注
实名认证
内容提供者

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

1亿VIP精品文档

相关文档