UML_和_Rational_Rose

17.1概述7.2静态建模机制7.3动态建模机制7.4描述物理架构的机制7.5使用和扩展UML7.6RationalRose的使用27.1.1UML的产生和发展UML(UnifiedModelingLanguage)的概念于1996年由面向对象方法领域的三位著名专家GradyBooch，JamesRumbaugh和IvarJacobson提出的。1996年6月和10月分别发布了UML0.9,UML0.91。1997年1月，UML1.0被提交给对象管理组织OMG。1997年9月，提交UML1.1，1997年11月被OMG采纳作为基于面向对象技术的标准建模语言。1998、1999、2000、2001年分别发布了UML1.2、UML1.3、UML1.4、UML1.5。7.1概述3UML已经迅速成长为一个事实上的工业标准。不论在计算机学术界、软件产业界还是在商业界，UML已经逐渐成为人们为各种系统建模、描述系统体系结构、商业体系结构和商业过程时使用的统一工具，而且在实践过程中人们还在不断扩展它的应用领域。47.1.2UMLUML是一种标准的图形化(即可视化)建模语言，它由图和元模型组成。图是UML的语法，而元模型给出图的含义，是UML(1)UMLUML的语义是定义在一个四层(四个抽象级别)建模概念框架中的，这四层分别是：5(1)元元模型(meta_metamodel)•由UML最基本的元素“事物(thing)”组成，代表要定义的(2)元模型(metamodel)•由UML基本元素组成，包括面向对象和面向构件的概念。这一层的每个概念都是元元模型中“事物”概念的实例(通过版类化)6(3)模型(model)•由UML模型组成，这一层的每个概念都是元模型层中概念的实例(通过版类化)。这一层的模型通常称为类模型或类(4)用户模型(usermodel)•由UML模型的例子组成，这一层中的每个概念都是模型层的一个实例(通过分类)，也是元模型层模型的一个实例(通过版类化)。这一层的模型通常称为对象模型或实例模78UML的语义描述UML精确的元模型定义，即我们将用什么符号来表示我们要做的事情。元模型是UML所有元素在语法上提供的一种标记方法，为我们建立模型提供了简单一致的通用的方法，开发者可以在语义上为某一个表示取得一致的标准，从而消除了以往因人而异的表示方法。如对一个操作者，我们可以表示为一个圆，也可以表示为一个小人。UML给我们提供了一个标准：用一个小人来代表所有和系统发生关系但并不是系统的一部分的事物，即actor（操作者）。9UML中的基本元模型有：操作者(actor)：用例(usecase)：10类(class)：包(package)：11消息(messages)：关联(association)：聚集(aggregation)：其它：12(2)UML的表示法UML的表示方法定义了UML的符号表示，为开发者或开发工具提供使用这种图形表示方法为系统建模。这些符号或文字表达是应用级的模型，在语义上是UML元模型的实例。UML由视图(view)、图(diagram)、模型元素(modelelement)和通用机制(generalmechanism)等几个部分组成。13视图为了完整地描述一个系统，往往需要描述该系统的许多方面。用视图可以表示被建模系统的各个方面，也就是说，从不同目的出发可以为系统建立多个模型，这些模型都描述同一个系统，只是描述的角度不14图图是用来表达一个视图的内容的，通常，一个视图由多张图组成。UML语言共定义了9种不同的图，把它们有机地结合起来就可以描述系统的所有视图。15模型元素可以在图中使用的概念(例如，用例、类、对象、消息和关系)，统称为模型元素。模型元素在图中用相应的视图元素(图形符号)表示。一个模型元素可以用在多个不同的图中，不管怎样使用，它总是具有相同的含义和相同的符号表示。16通用机制UML语言利用通用机制为图附加一些额外的信息，比如，可以在“笔记”中书写注释，或用“标签值”说明模型元素的性质等。此外，它还提供扩展机制(例如，版类、标签值、约束)，使UML能够适应一种特殊171.用例图(use-casediagram)用例是对系统提供的功能(即系统的具体用法)的描述。用例图从用户的角度描述系统功能，并指出各个功能的操作者。用例图定义了系统的功能需求。用户、项目主管、分析人员、开发人员、质量保证工程师和任何对系统感兴趣的人都可以浏览这个框图，了解系统的功能。7.1.3UML图18一个用例实质上是用户与计算机系统之间的一次典型的交互作用，它代表的是系统的一个完整的功能。在UML中把用例定义成系统执行的一系列动作，动作的结果能被外部执行者察觉到。在UML用例图中，用例表示为一个椭圆。在自动售货机系统的用例图中，“售货”、“供货”和“取货款”都是典型的用例。19自动售货机系统用例图20·用例代表某些用户可见的功能，实现一个具体的用户目标。·用例由执行者激活，并提供确切的值给执行者。·用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。212.静态图(staticdiagram)这类图描述系统的静态结构，属于这类图的有类图(classdiagram)，对象图(objectdiagram)，包图（pakagediagrame）。(1)类图:类图不仅定义系统中的类，表示类与类之间的关系(例如，关联、依赖、泛化和细化等关系)，也表示类的内部结构(类的属性和操作)。类图描述的是一种静态关系，在系统的整个生命期22(2)对象图:对象图是类图的实例，它使用几乎与类图完全相同的图示符号。两者之间的差别在于，对象图表示的是类的多个对象实例，而不是实际的类。由于对象有生命周期，因此对象图只能在系统的某个时间段内存在。一般说来，对象图没有类图重要，它主要用来帮助对类图的理解，也可用在协作图中，表示一组对象之间的动态协作关系。(3)包图:包是指把功能或者用途相近的一个或多个类或对象用一个符号来表示，并代表所有这些类或对象的静态、动态特征。主要是为简化复杂系统的视图而设计的。可以把几个类放在一个包里，由包来和其它对象或类发生联系，并把消息传递给所属的类或对象。233.行为图(behaviordiagram)这类图描述系统的动态行为和组成系统的对象间的交互关系，包括状态图(statediagram)和活动图(activitydiagram)两种图形。(1)状态图:状态图描述类的对象可能具有的所有状态，以及引起状态变化的事件，状态变化称作状态转换。通常，状态图是对类图的补充。实际使用时，并不需要为每个类都画状态图，仅需要为那些有多个状态，且其行为在不同状态有所不同24(2)活动图:活动图描述为满足用例要求而进行的动作以及动作间的关系。活动图是状态图的一个变种，它是另一种描述交互的254.交互图(interactivediagram)这类图描述对象间的交互关系，包括顺序图(sequencediagram)和协作图(collaborationdiagram)两种图形。26(1)顺序图:顺序图显示若干个对象间的动态协作关系，它强调对象之间发送消息的先后次序，描述对象之间的交互过程。分析人员从Sequence框图可以看到处理流程，开发人员看到需要开发的对象和这些对象的操作，质量保证工程师可以看到过程的细节，并根据这27(2)协作图:协作图与顺序图类似，也描述对象间的动态协作关系。除了显示对象间发送的消息之外，协作图还显示对象及它们之间的关系(称为上下文相关)由于顺序图和协作图都描述对象间的交互关系，所以建模者可以选择其中一种表示对象间的协作关系：如果需要强调时间和顺序，最好选用顺序图；如果285.实现图(implementationdiagram)这类图提供关于系统实现方面的信息，构件图(componentdiagram)和配置图(deploymentdiagram)属于这类图。29(1)构件图:构件图描述代码构件的物理结构及各个构件之间的依赖关系。构件可能是源代码、二进制文件或可执行文件。使用构件图有助于分析和理解构件之间的相互影响。•一般编译系统的人员要使用Component框图。构件框图显示组件应以什么顺序编译，还显示编译时会生成哪些运行组件，显示了类与实现组件之间的映射。30(2)配置图:配置图定义系统中软件和硬件的物理体系结构。通常，配置图中显示实际的计算机和设备(用节点表示)，以及各个节点之间的连接关系，也可以显示连接的类型及构件之间的依赖关系。在节点内部显示可执行的构件和对象，以清晰地表示出哪个软件单元运行在哪个节点上。项目管理人员、用户和部署人员通过配置图了解网络的物理布局和各种组件的位置。项目管理员通过这个框图与用户沟通系统的布局。部署人员用它进行部署规划。317.1.4UMLUML是一种建模语言，是一种标准的表示方法，而不是一种完整的方法学。因此，人们可以用各种方法使用UML，无论采用何种方法，它们的基础都是UML的图，这就是UML的最终用途——为不同领域的人提供统一的交流方法。32UML适用于系统开发的全过程，它的应用贯穿于从需求分析到系统建成后测试的各个阶段。•需求分析：可以用用例来捕获用户的需求。通过用例建模，可以描述对系统感兴趣的外部角色及其对系统的功能要求(用例)33分析：分析阶段主要关心问题域中的基本概念(例如，抽象、类和对象等)和机制，需要识别这些类以及它们相互间的关系，可以用UML的逻辑视图和动态视图来描述。类图描述系统的静态结构，协作图、顺序图、活动图和状态图描述系统的动态行为。在这个阶段只为问题域的类建模，而不定义软件系统的解决方案细节(例如，处理用户接口、数据库、通信和并行性等问题的类)34设计：把分析阶段的结果扩展成技术解决方案，加入新的类来定义软件系统的技术方案细节。设计阶段用和分析阶段类似的方式使用UML。构造(编码)：这个阶段的任务是把来自设计阶段35测试：对系统的测试通常分为单元测试、集成测试、系统测试和验收测试等几个不同的步骤。UML模型可作为测试阶段的依据，不同测试小组使用不同的UML图作为他们工作的依据：单元测试使用类图和类规格说明；集成测试使用构件图和协作图；系统测试使用用例图来验证系统的行为；验收测试由用户进行，用与系统测试类似的方法，验证系统是否满足在分析阶段确定的所有需求。总之，统一建模语言UML适用于以面向对象方法来描述任何类型的系统，而且适用于系统开发的全过程，从需求规367.2静态建模机制任何建模语言都以静态建模机制为基础，UML也不例外。UML的静态建模机制包括371.用例模型用例模型描述的是外部执行者(actor)所理解的系统功能。用例模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，描述了开发者和用户对需求规格达成的共识。首先，它描述了待开发系统的功能需求；其次，它把系统看作黑盒子，从外部执行者的角度来理解系统；第三，它驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的各个阶段和UML在UML中，一个用例模型由若干个用例图来描述，用例图的主要元素是用例和执行者7.2.1用例图382.用例一个用例实质上是用户与计算机系统之间的一次典型的交互作用，它代表的是系统的一个完整的功能。在UML中把用例定义成系统执行的一系列动作，动作的结果能被外部执行者在UML用例图中，用例表示为一个椭圆。图1是自动售货机系统的用例图，其中“售货”、“供货”和“取货款”都是用例代表某些用户可见的功能，实现一个具体的用户目标。用例由执行者激活，并提供确切的值给执行者。用例可大可小，但它必须是对一个具体的用户目标实现的完39图1自动售货机系统用例图403.执行者是与系统交互的人或物，它代表外部实体，例如，用户、硬件设备或与本系统交互的另一个软件系统。使实践表明，执行者对确定用例是非常有用的。面对一个大型、复杂的系统，要列出用例清单往往很困难，这时可以