统一建模语言uml_09

合集下载

UML统一建模语言共29页文档

UML统一建模语言共29页文档

说明和实现间的关系
(虚线空心箭头)
一个元素需要别的元素提供适当功能的情况 (虚线箭头)
川软智能技术有限公司
UML模型图分类和主要概念
分类 模型图 结构特性 类
用例 对象 构件 部署 行为特性 序列 协作 状态转移 活动
英文名称 主要概念
class
类,关联,泛化,依赖,接口
use Case 用例,参与者,泛化,关联,扩展
川软智能技术有限公司
类图
Customer
Name:string Phone:string
Add(Nname,phone)
类名 属性 方法(类的操作)
川软智能技术有限公司
例如:下图是售票系统的类图,他只是售票系统领域模型的一部分。图中表示了 几个重要的类,如Customer,Reservation,Ticket,Performance.顾客可多次 订票,但每一次订票只能由一个顾客来执行。有两种订票方式:个人票或套 票:前者只是一张票,后者包括多张票。每一张票不是个人票就是套票中的 一张,但是不能有事个人票又是套票中的一张。每场演出都有多张票可供预 定,每张票对应一个唯一的座位号。每次演出用剧目名,日期和时间来标识。
川软智能技术有限公司
用例之间的关系 UML用例之间主要有扩展和使用两种关系,他们是泛化关系的两种不同形式。 1》扩展关系 向一个用例中添加一些动作后构成了另一个用例,这两个用例之间的关系就是扩
展关系,后者继承前者的一些行为,通常把后者称为扩展用例。 2》使用关系 当一个用例使用另一个用例时,这两用例之间就构成了使用关系。一般来说,如
Individual Reservation * *
**
Show Name:string

第4章 统一建模语言UML

第4章 统一建模语言UML


XP 系 统 开 发 方 法

XP原则和技术

连续自动测试:在XP方法中每天都发生测试活动。
连续集成:一旦软件模块通过单元测试,该模块就与其 他模块联合起来接收测试。 大量用户参与:一直有一个或多个用户参与到开发组中 来。 团体程序设计:两个程序员坐在工作站前面,共用显示 器和键盘来开发所有软件。 特别注意人机交互和限制:整个开发组在同一个房间内 工作,大小按需要而定。

逻辑视图也定义永久性和并发性的特性, 同时还定义类的接口和内部结构。 对逻辑视图的描述在原则上与软件系统的 实现平台无关。 图形模型包括:类图、对象图、状态图、 顺序图、协作图及活动图等。



3. 组件视图(行为模型视图)
描述形成系统的并发与同步机制的线程和进 程,关注重点是系统的性能、易伸缩性和系 统的吞吐量等非功能性需求。 它利用并发来描述资源的高效实用、并行执 行和处理异步事件。 使用者:开发人员。 组成:组件图
第4章 统一建模语言UML
4.1UML概述
4.1.1 UML的产生背景

UML(Unified Modeling Language)是一个 通用的可视化建模语言,是用于对软件进行 描述、可视化处理、构造和建立软件系统的 文档。 通过使用UML,专业IT人员能够阅读和交流 系统架构和设计规划——就像建筑工人多年 来所使用的建筑设计图一样。



用例视图是核心

它的内容驱动其他视图的开发。系统的最终目标, 即系统将提供的功能在用例视图中描述。同时该 视图还有其他一些非功能特性的描述,因此,用 例视图对所有其他的视图产生影响。
通过测试用例视图,可检验和最终校验系统。 测试来自:客户(这是您想要的吗?)、已完成的系 统(系统是按照要求的方式运作的吗?)。

统一建模语言UML

统一建模语言UML

进程视图
以图形方式说明了系统中进程的详细组织结构, 即建模公式中的“人”、“事”、“物”、
“规则”是如何交互的,它们的关系如何。 即分析设计视图
部署视图
以图形方式说明了处理活动在系统中各个节点 的分布,包括进程和线程的物理分布。
即建模公式中的“人”、“事”、“物”、 “规则”是如何部署在物理节点(主机、网络 环境)上的。
抽象层次
抽象层次越高,具体信息越少,但是概括能力 越强。
抽象层次越高,表达能力越丰富。 有时,抽象甚至比具体还容易让人理解。
适当采用合适的抽象层次。
软件开发中,主体上采用自顶向下的抽象法。 辅以自底向上方法,总结较低抽象层次的实践
经验来改进高抽象层次的概念,提高软件质量。
统一过程的一般抽象层次
实际工作中应该在什么地方应用视图、应用哪 一种视图、总共需要哪些视图?
视图
人们只会关心信息中他感兴趣的那部分视角, 因此在展示信息时应选择恰当的视角。
产品有着很多面,只有将这些方面都描述清楚, 用很多个不同的视图去展示软件的不同方面— 静态的、动态的、结构性的、逻辑性的等—才 能完整的建立模型。
怎么建?
采用不同的方法去认识和描述事物,将导致不 同的建模结果。
过程? 对象?
抽象角度的不同,决定了建模方向的不同。
先弄清楚要从什么角度抽象,再进行后续工作。
模是什么?
决定了抽象角度后,我们试图从该角度进行场 景模拟。
目的是从中得到“人”、“事”、“物”、 “规则”,这就是我们要得到的“模”。
对象分析法
一切都是对象 对象都是独立的 对象都具有原子性 对象都是可抽象的 对象都有层次性

统一建模语言

统一建模语言

统一建模语言统一建模语言(UML)是一种定义良好、易于表达、功能强大且普遍适用的建模语言。

它融入了软件工程领域的新思想、新方法和新技术。

它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。

1.UML的结构UML的结构包括基本构造块、支配这些构造块如何放在一起的规则(体系架构)和一些运用于整个UML的机制。

(1)构造块。

UML有三种基本的构造块,分别是事物(thing)、关系(relationship)和图(diagram)。

事物是UML中重要的组成部分,关系把事物紧密联系在一起,图是很多有相互相关的事物的组。

(2)公共机制。

公共机制是指达到特定目标的公共UML方法,主要包括规格说明(详细说明)、修饰、公共分类(通用划分)和扩展机制四种。

●规格说明:规格说明是事物语义的文本描述,它是模型真正的核心。

●修饰:UML为每一个事物设置了一个简单的记号,还可以通过修饰来表达更多的信息。

●公共分类:包括类元与对象(类表示概念,而对象表示具体的实体)、接口和实现(接口用来定义契约,而实现就是具体的内容)两组公共分类。

●扩展机制:包括约束(添加新规则来扩展事物的语义)、构造型(用于定义新的事物)、标记值(添加新的特殊信息来扩展事物的规格说明)。

(3)规则。

UML用于描述事物的语义规则分别是为事物、关系和图命名。

给一个名字以特定含义的语境,即范围;怎样使用或看见名字,即可见性;事物如何正确、一致地相互联系,即完整性;运行或模拟动态模型的含义是什么,即执行。

UML对系统架构的定义是系统的组织结构,包括系统分解的组成部分、它们的关联性、交互、机制和指导原则等这些提供系统设计的信息。

而具体来说,就是指5个系统视图,分别是逻辑视图、进程视图、实现视图、部署视图和用例视图。

●逻辑视图:以问题域的语汇组成的类和对象集合。

●进程视图:可执行线程和进程作为活动类的建模,它是逻辑视图的一次执行实例,描绘了所设计的并发与同步结构。

第15章统一的建模语言UML

第15章统一的建模语言UML

申请贷款
贷款经理
时序图:打印
计算机
打印驱动器
打印机
队列
输出文件
打印机空闲 打印输出文件
打印机忙 输出文件 入队列
时序图:打电话
访客
交换机
远程交换机
访客
a {b-a<1}
b {c-b<10}
c
{e-d<5}
拿起话筒
蜂鸣音
拨号码
<10
...
d
路径
铃响信号
e 铃响 拿起话筒
铃响停止信号
铃响停止
协同图:打印
状态图:电梯
年编个辑 器
封包
控制器
图组件
见 、、、
图组件
见 、、、
图形核心
基本图形 核心
窗口核心
窗口系统
基本图形 微软窗口
活动图:磁盘
构件分布图
构件图的组合
配置图:主机与外围设备
行为 状态图, 时序图, 协同图, 实现者, 组装者
模型 活动图, 构件图, 配置图
实现
构件图
实现者
模型
环境
配置图
实现者, 组装者,
模型
测试者
事 务
使用实例图

型 事件流

析 脚本
UML规划 操作分析过程
相互作用图(时序图,协同图)
对象&类

向 对
对象图,类图


类分组

封包图
状态图
构件图
配置图
人 持有人 *
类2
角色1
角色2
聚合、导航和个体数目
整体 类名
聚合,单向导航 0..1 0..1 混合聚合,双向导航

lec-09统一建模语言UML和Rational统一过程RUP

lec-09统一建模语言UML和Rational统一过程RUP

第九讲统一建模语言UML和Rational统一过程RUP现代软件开发面临着要尽快将产品推向市场和开发高质量、低成本产品的矛盾。

要成功解决软件开发中的矛盾,必须将软件开发作为一种团队活动。

为了有效组织开发和进行交流,团队中不同参与者统一使用公共的过程、公共的表达语言、以及支持该语言和过程的工具。

Rational统一过程(RUP)就是这样一种公共过程,而且已经在多个软件开发组织的实践中被证实可以有效解决上述矛盾。

统一建模语言(UML)则可以作为开发团队的公共语言。

UML不是完整的开发方法,UML规范也没有定义标准的过程,而RUP则是有效使用UML 的指南。

本讲着重介绍UML和RUP的基本概念,并描述了如何在RUP的指导下用UML 建模。

一.引言现代软件开发中存在着一个基本矛盾:一方面,开发组织需要将产品尽快推向市场;另一方面,推出的软件系统必须兼具高质量和低成本。

要在这二者之间取得平衡很困难:仓促地将一个软件系统推向市场,其质量肯定会受到影响;但是过分注重质量可能会需要过多的时间才能将软件交给用户。

要解决这个矛盾,首先要认识到软件开发已经发生了本质的变化。

以前,许多信息系统的体系结构相当简单:上层的应用程序建立在中间层上,中间层则封装了业务规则和数据存取;中间层建立在持久存储之上,通常表现为一个关系数据库,这个数据库实质上就是系统的中心。

Client/Server体系结构的出现有助于实现这种三层分离的体系,并且易于有效控制系统的变更。

特别地,在保持系统状态不变的情况下可以快速创建和修改应用,可以引入新的业务规则而不影响系统的稳定,也可以随着时间以新的和不可预知的方式来进行数据挖掘。

这种稳定的体系结构使得许多组织以相应的形式组织他们的开发团队:分析人员和最终领域专家一起将用户的要求转化为需求,数据建模人员建立满足用户功能需求的领域模型,应用开发人员则迅速建造满足系统行为需求的新系统。

然而,随着Web的出现,软件开发的世界发生了不可逆转的改变。

统一建模语言UML

统一建模语言UML

UML历史
• Rational公司的G.Booch和J.Rumbaugh决定将他们各自的 方法结合起来成为一种方法。1995年10月发布了第一个 版本,称作统一方法(Unified Method 0.8) • OOSE的作者I. Jacobson也加入了公司,于是也加入了统 一行动,发布了第二个版本UML0.9 • 鉴于统一行动的产物是一种建模语言,而不是一种建模方 法,因此称为统一建模语言 • 在此过程中,Rational公司发起成立了UML伙伴组织,开 始时有12家参加,共同推出了UML1.0版,并在1997年1 月提交给OMG • 其他几家分头向OMG提交提案的公司被纳入进来,推出 了UML1.1版,在1997年11月4日被OMG采纳
行为模型元素
交互
• 交互是系统内一系列的对象之间互相交换消息的行为 消息代表软件系统内两个对象中一个对象向另一个对 象发出的执行某种操作的请求。 交互描述了一系列的对象为完成某一项任务而联合采 取的一系列的行动,主要包括这些行动在时间上的顺 序,消息是描述交互的一个重要手段。 • 在模型图上,消息被表示为一个箭头
UML历史
UML历史
• 面对众多的建模语言,用户由于没有能力区别不 同语言之间的差别,因此很难找到一种比较适合 其应用特点的语言; • 众多的建模语言实际上各有千秋; • 虽然不同的建模语言大多类同,但仍存在某些细 微的差别,极大地妨碍了用户之间的交流; • 因此在客观上,极有必要在精心比较不同的建模 语言优缺点及总结面向对象技术应用实践的基础 上,根据应用需求,取其精华,去其糟粕,求同 存异,统一建模语言。
• 注解大量存在于机械图和电子线路图中,被用来 标示产品的工艺要求,如微机主板等。 • UML中,也存在着相似的语言成分,这就是:注 解元素(annotation things)

什么是统一建模语言(UML)?

什么是统一建模语言(UML)?

什么是统一建模语言(UML)?UML是统一建模语言的缩写,是一种标准化建模语言,由一组集成的图表组成,它开发来帮助系统和软件开发人员指定、可视化、构建和记录软件系统的工件,以及业务建模和其他非软件系统。

UML代表了在大型和复杂系统建模中已被证明是成功的最佳工程实践的集合。

UML是开发面向对象软件和软件开发过程中非常重要的一部分。

UML 主要使用图形符号来表示软件项目的设计。

使用UML帮助项目团队沟通,探索潜在的设计,并验证软件的体系结构设计。

在本文中,我们将向您详细介绍UML是什么、UML的历史以及每个UML图类型的描述,以及UML示例。

What is Unified Modeling Language (UML)?UML, short for Unified Modeling Langung of an integrated set of diagrams, developed to help system and software developers for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. The UML is a very important part of developing object oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software. In this article we will give you detailed ideas about what is UML, the history of UML and a description of each UML diagram type, along with UML examples.The Origin of UMLThe goal of UML is to provide a standard notation that can be used by all object-oriented methods and to select and integrate the best elements of precursor notations. UML has been designed for a broad range of applications. Hence, it provides constructs for a broad range of systems and activities (e.g., distributed systems, analysis, system design and deployment).UML is a notation that resulted from the unification of OMT from1.Object Modeling T echnique OMT [James Rumbaugh 1991] - was best for analysis and data-intensive information systems.2.Booch [Grady Booch 1994] - was excellent for design and implementation. Grady Booch had worked extensively with the Ada language, and had been a major player in the development of Object Oriented techniques for the language. Although the Booch method was strong, the notation was less well received (lots of cloud shapes dominated his models - not very tidy)3.OOSE (Object-Oriented Software Engineering [Ivar Jacobson 1992]) - featured a model known as Use Cases. Use Cases are a powerful technique for understanding the behaviour of an entire system (an area where OO has traditionally been weak).In 1994, Jim Rumbaugh, the creator of OMT, stunned the software world when he left General Electric and joined Grady Booch at Rational Corp. The aim of the partnership was to merge their ideas into a single, unified method (the working title for the method was indeed the "Unified Method").By 1995, the creator of OOSE, Ivar Jacobson, had also joined Rational, and his ideas (particularly the concept of "Use Cases")were fed into the new Unified Method - now called the Unified Modelling Language1. The team of Rumbaugh, Booch and Jacobson are affectionately known as the "Three Amigos"UML has also been influenced by other object-oriented notations:•Mellor and Shlaer [1998]•Coad and Yourdon [1995]•Wirfs-Brock [1990]•Martin and Odell [1992]UML also includes new concepts that were not present in other major methods at the time, such as extension mechanisms and a constraint language.History of UML1.During 1996, the first Request for Proposal (RFP) issued by the Object Management Group (OMG) provided the catalyst for these organizations to join forces around producing a joint RFP response.2.Rational established the UML Partners consortium with several organizations willing to dedicate resources to work toward a strong UML 1.0 definition. Those contributing most to the UML 1.0 definition included:o Digital Equipment Corpo HPo i-Logixo IntelliCorpo IBMo ICON Computingo MCI Systemhouseo Microsofto Oracleo Rational Softwareo TIo Unisys3.This collaboration produced UML 1.0, a modeling language that was well-defined, expressive, powerful, and generally applicable. This was submitted to the OMG in January 1997 as an initial RFP response.14.In January 1997 IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies and Softeam also submitted separate RFP responses to the OMG. These companies joined the UML partners to contribute their ideas, and together the partners produced the revised UML 1.1 response. The focus of the UML 1.1 release was to improve the clarity of the UML 1.0 semantics and to incorporate contributions from the new partners. It was submitted to the OMG for their consideration and adopted in the fall of 1997.1 and enhanced 1.1 to 1.5, and subsequently to UML 2.1 from 01 to 06 (now the UML current version is 2.5)Why UMLAs the strategic value of software increases for many companies, the industry looks for techniques to automate the production of software and to improve quality and reduce cost and time-to-market. These techniques include componenttechnology, visual programming, patterns and frameworks. Businesses also seek techniques to manage the complexity of systems as they increase in scope and scale. In particular, they recognize the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, load balancing and fault tolerance. Additionally, the development for the World Wide Web, while making some things simpler, has exacerbated these architectural problems. The Unified Modeling Language (UML) was designed to respond to these needs. The primary goals in the design of the UML summarize by Page-Jones in Fundamental Object-Oriented Design in UML as follows:1.Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models.2.Provide extensibility and specialization mechanisms to extend the core concepts.3.Be independent of particular programming languages and development processes.4.Provide a formal basis for understanding the modeling language.5.Encourage the growth of the OO tools market.6.Support higher-level development concepts such as collaborations, frameworks, patterns and components.7.Integrate best practices.UML - An OverviewBefore we begin to look at the theory of the UML, we are going to take a very brief run through some of the major concepts of the UML.The first thing to notice about the UML is that there are a lot of different diagrams (models) to get used to. The reason for thisis that it is possible to look at a system from many different viewpoints. A software development will have many stakeholders playing a part.For Example:•Analysts•Designers•Coders•Testers•QA•The Customer•Technical AuthorsAll of these people are interested in different aspects of the system, and each of them require a different level of detail. For example, a coder needs to understand the design of the system and be able to convert the design to a low level code. By contrast, a technical writer is interested in the behavior of the system as a whole, and needs to understand how the product functions. The UML attempts to provide a language so expressive that all stakeholders can benefit from at least one UML diagram.Here's a quick look at each one of these 13 diagrams in as shown in the UML 2 Diagram Structure below:Structure diagrams show the static structure of the system and its parts on different abstraction and implementation levels and how they are related to each other. The elements in a structure diagram represent the meaningful concepts of a system, and may include abstract, real world and implementation concepts, there are seven types of structure diagram as follows:•Class Diagram•Component Diagram•Deployment Diagram•Object Diagram•Package Diagram•Composite Structure Diagram•Profile DiagramBehavior diagrams show the dynamic behavior of the objects in a system, which can be described as a series of changes to the system over time, there are seven types of behavior diagrams as follows:•Use Case Diagram•Activity Diagram•State Machine Diagram•Sequence Diagram•Communication Diagram•Interaction Overview Diagram•Timing DiagramWhat is a Class Diagram?The class diagram is a central modeling technique that runs through nearly all object-oriented methods. This diagram describes the types of objects in the system and various kinds of static relationships which exist between them.RelationshipsThere are three principal kinds of relationships which areimportant:1.Association - represent relationships between instances of types (a person works for a company, a company has a number of offices.2.Inheritance - the most obvious addition to ER diagrams for use in OO. It has an immediate correspondence to inheritance in OO design.3.Aggregation - Aggregation, a form of object composition in object-oriented design.Class Diagram ExampleWhat is Component Diagram?In the Unified Modeling Language, a component diagram depicts how components are wired together to form larger components or software systems. It illustrates the architectures of the software components and the dependencies between them. Those software components including run-time components, executable components also the source code components.Component Diagram ExampleWhat is a Deployment Diagram?The Deployment Diagram helps to model the physical aspect of an Object-Oriented software system. It is a structure diagram which shows architecture of the system as deployment (distribution) of software artifacts to deployment targets. Artifacts represent concrete elements in the physical world that are the result of a development process. It models the run-time configuration in a static view and visualizes the distribution of artifacts in an application. In most cases, it involves modeling the hardware configurations together with the software components that lived on.Deployment Diagram ExampleWhat is an Object Diagram?An object diagram is a graph of instances, including objects and data values. A static object diagram is an instance of a class diagram; it shows a snapshot of the detailed state of a system at a point in time. The difference is that a class diagram represents an abstract model consisting of classes and their relationships. However, an object diagram represents an instance at a particular moment, which is concrete in nature. The use of object diagrams is fairly limited, namely to show examples of data structure.Class Diagram vs Object Diagram - An ExampleSome people may find it difficult to understand the difference between a UML Class Diagram and a UML Object Diagram as they both comprise of named "rectangle blocks", with attributes in them, and with linkages in between, which make the two UML diagrams look similar. Some people may even think they are the same because in the UML tool they use both the notations for Class Diagram and Object Diagram are put inside the same diagram editor - Class Diagram.But in fact, Class Diagram and Object Diagram represent two different aspects of a code base. In this article, we will provide you with some ideas about these two UML diagrams, what they are, what are their differences and when to use each of them.Relationship between Class Diagram and Object Diagram You create "classes" when you are programming. For example, in an online banking system you may create classes like 'User', 'Account', 'Transaction', etc. In a classroom management system you may create classes like 'Teacher', 'Student', 'Assignment', etc. In each class, there are attributes and operations that represent the characteristic and behavior of the class. Class Diagram is a UML diagram where you can visualize those classes, along with their attributes, operations and theinter-relationship.UML Object Diagram shows how object instances in your system are interacting with each other at a particular state. It also represents the data values of those objects at that state. In other words, a UML Object Diagram can be seen as a representation of how classes (drawn in UML Class Diagram) are utilized at a particular state.If you are not a fan of those definition stuff, take a look at the following UML diagram examples. I believe that you will understand their differences in seconds.Class Diagram ExampleThe following Class Diagram example represents two classes - User and Attachment. A user can upload multiple attachment so the two classes are connected with an association, with 0..* as multiplicity on the Attachment side.Object Diagram ExampleThe following Object Diagram example shows you how the object instances of User and Attachment class "look like" at the moment Peter (i.e. the user) is trying to upload two attachments. So there are two Instance Specification for the two attachment objects to be uploaded.What is a Package Diagram?Package diagram is UML structure diagram which shows packages and dependencies between the packages. Modeldiagrams allow to show different views of a system, for example, as multi-layered (aka multi-tiered) application - multi-layered application model.Package Diagram ExampleWhat is a Composite Structure Diagram?Composite Structure Diagram is one of the new artifacts added to UML 2.0. A composite structure diagram is similar to a class diagram and is a kind of component diagram mainly used in modeling a system at micro point-of-view, but it depicts individual parts instead of whole classes. It is a type of static structure diagram that shows the internal structure of a class and the collaborations that this structure makes possible.This diagram can include internal parts, ports through which the parts interact with each other or through which instances of the class interact with the parts and with the outside world, and connectors between parts or ports. A composite structure is a set of interconnected elements that collaborate at runtime to achieve some purpose. Each element has some defined role in the collaboration.Composite Structure Diagram ExampleWhat is a Profile Diagram?A profile diagram enables you to create domain and platform specific stereotypes and define the relationships between them. You can create stereotypes by drawing stereotype shapes and relate them with composition or generalization through the resource-centric interface. You can also define and visualize tagged values of stereotypes.Profile Diagram ExampleWhat is a Use Case Diagram?A use-case model describes a system's functional requirements in terms of use cases. It is a model of the system's intended functionality (use cases) and its environment (actors). Use cases enable you to relate what you need from a system to how the system delivers on those needs.Think of a use-case model as a menu, much like the menu you'd find in a restaurant. By looking at the menu, you knowwhat's available to you, the individual dishes as well as their prices. You also know what kind of cuisine the restaurant serves: Italian, Mexican, Chinese, and so on. By looking at the menu, you get an overall impression of the dining experience that awaits you in that restaurant. The menu, in effect, "models" the restaurant's behavior.Because it is a very powerful planning instrument, the use-case model is generally used in all phases of the development cycle by all team members.Use Case Diagram ExampleWhat is an Activity Diagram?Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. It describes the flow of control of the target system, such as the exploring complex business rules and operations, describing the use case also the business process. In the Unified Modeling Language, activity diagrams are intended to model both computational and organizational processes (i.e. workflows).Activity Diagram ExampleWhat is a State Machine Diagram?A state diagram is a type of diagram used in UML to describe the behavior of systems which is based on the concept of state diagrams by David Harel. State diagrams depict the permitted states and transitions as well as the events that effect these transitions. It helps to visualize the entire lifecycle of objects and thus help to provide a better understanding of state-based systems.State Machine Diagram ExampleWhat is a Sequence Diagram?The Sequence Diagram models the collaboration of objects based on a time sequence. It shows how the objects interact with others in a particular scenario of a use case. With the advanced visual modeling capability, you can create complex sequence diagram in few clicks. Besides, some modeling tool such as Visual Paradigm can generate sequence diagram from the flow of events which you have defined in the use case description.Sequence Diagram ExampleWhat is a Communication Diagram?Similar to Sequence Diagram, the Communication Diagram is also used to model the dynamic behavior of the use case. When compare to Sequence Diagram, the Communication Diagram is more focused on showing the collaboration of objects rather than the time sequence. They are actually semantically equivalent, so some of the modeling tool such as, Visual Paradigm allowsyou to generate it from one to the other.Communication Diagram ExampleWhat is Interaction Overview Diagram?The Interaction Overview Diagram focuses on the overview of the flow of control of the interactions. It is a variant of the Activity Diagram where the nodes are the interactions or interaction occurrences. The Interaction Overview Diagram describes the interactions where messages and lifelines are hidden. You can link up the "real" diagrams and achieve high degree navigability between diagrams inside the Interaction Overview Diagram.Interaction Overview Diagram ExampleWhat is Timing Diagram?Timing Diagram shows the behavior of the object(s) in a given period of time. Timing diagram is a special form of a sequence diagram. The differences between timing diagram and sequence diagram are the axes are reversed so that the time are increase from left to right and the lifelines are shown in separate compartments arranged vertically.Timing Diagram ExampleUML Glossary and Terms•Abstract Class - A class that will never be instantiated. An instance of this class will never exist.•Actor - An object or person that initiates events the system is involved with.•Activity: A step or action within an Activity Diagram. Represents an action taken by the system or by an Actor.•Activity Diagram: A glorified flowchart that shows the steps and decisions and parallel operations within a process, such as an algorithm or a business process.•Aggregation - Is a part of another class. Shown with a hollow diamond next to the containing class in diagrams.•Artifacts - Documents describing the output of a step in the design process. The description is graphic, textual, or some combination.•Association - A connection between two elements of a Model. This might represent a member variable in code, or theassociation between a personnel record and the person it represents, or a relation between two categories of workers, or any similar relationship. By default, both elements in an Association are equal, and are aware of each other through the Association. An Association can also be a Navigable Association, meaning that the source end of the association is aware of the target end, but not vice versa.•Association Class: A Class that represents and adds information to the Association between two other Classes.•Attributes - Characteristics of an object which may be used to reference other objects or save object state information.•Base Class: A Class which defines Attributes and Operations that are inherited by a Subclass via a Generalization relationship.•Branch: A decision point in an Activity Diagram. Multiple Transitions emerge from the Branch, each with a Guard Condition. When control reaches the Branch, exactly one Guard Condition must be true; and control follows the corresponding Transition.•Class: A category of similar Objects, all described by the same Attributes and Operations and all assignment-compatible.•Class Diagram - Shows the system classes and relationships between them.•Classifier: A UML element that has Attributes and Operations. Specifically, Actors, Classes, and Interfaces.•Collaboration: A relation between two Objects in a Communication Diagram, indicating that Messages can pass back and forth between the Objects.•Communication Diagram - A diagram that shows how operations are done while emphasizing the roles of objects.•Component: A deployable unit of code within the system.•Component Diagram: A diagram that shows relations between various Components and Interfaces.•Concept - A noun or abstract idea to be included in a domain model.•Construction Phase - The third phase of the Rational Unified Process during which several iterations of functionality are built into the system under construction. This is where the main work is done.•Dependence: A relationship that indicates one Classifier knows the Attributes and Operations of another Classifier, but isn't directly connected to any instance of the second Classifier.•Deployment Diagram: A diagram that shows relations between various Processors.•Domain -The part of the universe that the system is involved with.•Elaboration Phase - The second phase of the Rational Unified Process that allows for additional project planning including the iterations of the construction phase.•Element: Any item that appears in a Model.•Encapsulation - Data in objects is private.•Generalization - Indicates that one class is a subclass on another class (superclass). A hollow arrow points to the superclass.•Event: In a State Diagram, this represents a signal or event or input that causes the system to take an action or switch States.•Final State: In a State Diagram or an Activity Diagram, this indicates a point at which the diagram completes.•Fork: A point in an Activity Diagram where multiple parallel control threads begin.•Generalization: An inheritance relationship, in which aSubclass inherits and adds to the Attributes and Operations of a Base Class.•GoF - Gang of Four set of design patterns.•High Cohesion - A GRASP evaluative pattern which makes sure the class is not too complex, doing unrelated functions.•Low Coupling - A GRASP evaluative pattern which measures how much one class relies on another class or is connected to another class.•Inception Phase - The first phase of the Rational Unified Process that deals with the original conceptualization and beginning of the project.•Inheritance - Subclasses inherit the attributes or characterics of their parent (superclass) class. These attributes can be overridden in the subclass.•Initial State: In a State Diagram or an Activity Diagram, this indicates the point at which the diagram begins.•Instance - A class is used like a template to create an object. This object is called an instance of the class. Any number of instances of the class may be created.•Interface: A Classifier that defines Attributes and Operations that form a contract for behavior. A provider Class or Component may elect to Realize an Interface (i.e., implement its Attributes and Operations). A client Class or Component may then Depend upon the Interface and thus use the provider without any details of the true Class of the provider.•Iteration - A mini project section during which some small piece of functionality is added to the project. Includes the development loop of analysis, design and coding.•Join: A point in an Activity Diagram where multiple parallel control threads synchronize and rejoin.•Member: An Attribute or an Operation within a Classifier.•Merge: A point in an Activity Diagram where different control paths come together.•Message - A request from one object to another asking the object receiving the message to do something. This is basically a call to a method in the receiving object.•Method - A function or procedure in an object.•Model - The central UML artifact. Consists of various elements arranged in a hierarchy by Packages, with relations between elements as well.•Multiplicity - Shown in a domain model and indicated outside concept boxes, it indicates object quantity relationship to quantiles of other objects.•Navigability: Indicates which end of a relationship is aware of the other end. Relationships can have bidirectional Navigability (each end is aware of the other) or single directional Navigability (one end is aware of the other, but not vice versa).•Notation - Graphical document with rules for creating analysis and design methods.•Note: A text note added to a diagram to explain the diagram in more detail.•Object - Object: In an Activity Diagram, an object that receives information from Activities or provides information to Activities. In a Collaboration Diagram or a Sequence Diagram, an object that participates in the scenario depicted in the diagram. In general: one instance or example of a given Classifier (Actor, Class, or Interface).•Package - A group of UML elements that logically should be grouped together.•Package Diagram: A Class Diagram in which all of theelements are Packages and Dependencies.•Pattern - Solutions used to determine responsibility assignment for objects to interact. It is a name for a successful solution to a well-known common problem.•Parameter: An argument to an Operation.•Polymorphism - Same message, different method. Also used as a pattern.•Private: A Visibility level applied to an Attribute or an Operation, indicating that only code for the Classifier that contains the member can access the member.•Processor: In a Deployment Diagram, this represents a computer or other programmable device where code may be deployed.•Protected: A Visibility level applied to an Attribute or an Operation, indicating that only code for the Classifier that contains the member or for its Subclasses can access the member.•Public: A Visibility level applied to an Attribute or an Operation, indicating that any code can access the member.•Reading Direction Arrow - Indicates the direction of a relationship in a domain model.•Realization: Indicates that a Component or a Class provides a given Interface.•Role - Used in a domain model, it is an optional description about the role of an actor.•Sequence Diagram: A diagram that shows the existence of Objects over time, and the Messages that pass between those Objects over time to carry out some behavior. State chart diagram - A diagram that shows all possible object states.•State: In a State Diagram, this represents one state of a system or subsystem: what it is doing at a point in time, as wellas the values of its data.•State Diagram: A diagram that shows States of a system or subsystem, Transitions between States, and the Events that cause the Transitions.•Static: A modifier to an Attribute to indicate that there's only one copy of the Attribute shared among all instances of the Classifier. A modifier to an Operation to indicate that the Operation stands on its own and doesn't operate on one specific instance of the Classifier.•Stereotype: A modifier applied to a Model element indicating something about it which can't normally be expressed in UML. In essence, Stereotypes allow you to define your own "dialect" of UML.•Subclass: A Class which inherits Attributes and Operations that are defined by a Subclass via a Generalization relationship.•Swimlane: An element of an Activity Diagram that indicates what parts of a system or a domain perform particular Activities. All Activities within a Swimlane are the responsibility of the Object, Component, or Actor represented by the Swimlane.•Time Boxing - Each iteration will have a time limit with specific goals.•Transition: In an Activity Diagram, represents a flow of control from one Activity or Branch or Merge or Fork or Join to another. In a State Diagram, represents a change from one State to another.•Transition Phase - The last phase of the Rational Unified Process during which users are trained on using the new system and the system is made available to users.•UML - Unified Modeling Language utilizes text and graphic documents to enhance the analysis and design of software。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

2013-7-3
24
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
1. 访问
包的访问关系详细的说明了被导入的元素具 有私有的可见性 UML用构造型<<access>>加在虚线上表示 包之间的访问关系
2013-7-3
25
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
2013-7-3
20
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
9.3.2 包中元素的可见性
包中元素的可见性主要有下面三种:
+ : 表示公共的可见性(public),这类元素可以被 包外部的所有元素访问 # : 表示受保护的可见性(protected),种类元素 仅可被继承自该包的子包中的元素所访问 -: 私有可见性(private),这类元素不能被包外 部的元素访问
9.3.1 包
第二种表示方法是用实线将包和包中的元素 连接起来 这种包含关系用接近包那一端的带有加号的 圆圈来表示
2013-7-3
15
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
9.3.1 包
security
Credentials
IdentityVerifier
2013-7-3 27
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
9.3.3 包之间的关系
1.访问(Access) 2.导入(Import) 3.合并(Merge)
2013-7-3
28
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
9.3 包图的表示方法
9.3.1 包 9.3.2 包中元素的可见性 9.3.3 包之间的关系
2013-7-3
11
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
9.3 包图的表示方法
9.3.1 包 9.3.2 包中元素的可见性 9间的关系,它的抽 象表达方式为: 包图 = 包 + 关系 Package Diagram = Package + Relationship
2013-7-3
8
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
9.2 包图
UML包图的语义简单,但意义重大,它用 UML符号表示模型元素的组合 系统中的每个元素都只能为一个包所有,一 个包可嵌套在另一个包中 使用包图可以将相关元素归入一个系统 一个包中可包含附属包、图表或单个元素
包中元素的表示方式有两种,一是在包中用 矩形画出这些元素,这种方法下,包的名称 就可以放在包图左上部的标签中
security
Credentials
IdentityVerifier
2013-7-3
图9-2 包security及其中元素
14
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
3.合并
合并关系表示将目标包中的内容合并到源包 中去。同样,目标包中的私有内容也是不能 被合并的 合并关系用<<merge>>加在虚线上表示,箭 头指向被合并的包
9.1 基于包的系统静止状态下的结构建模
在你分析设计软件系统时,随着对用户需求 的分解,软件系统的功能越分越小,越分越 多,相应的模型也越建越多,最终我们很难 识别诸多模型的建模元素(Element)的归属 我们急需要按照某种要求来划分这些建模元 素的所属范围,以便我们更容易理解所建的 诸多UML模型和它们的建模元素的作用
2013-7-3 33
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
9.3.3 包之间的关系
1.访问(Access) 2.导入(Import) 3.合并(Merge)
2013-7-3
34
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
2013-7-3
12
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
9.3.1 包
UML使用一个左上部带有标签的矩形表示包
security
图9-1包security
2013-7-3
13
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
9.3.1 包
1. 访问
security users 《access》 User +Credentials +IdentityVerifier -MD5Crypt
图9-6 具有访问关系的包图
2013-7-3
26
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
1. 访问
该例中,users被称为源包(Source Package),security被称为目标包(Target Package) 这个例子表示包users要用到包security中的 元素 由于可见性的原因,users中的元素User只 能使用security中的元素Credentials和 IdentityVerifier,而不能使用MD5Crypt
-MD5Crypt
图9-8 包中元素导入关系的示意图
2013-7-3
32
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
2.导入
包的access关系和import关系的区别:
如果包users被导入到另一个包Z中,如果users和 security是access的关系,则Z中的元素是看不到包 security中的元素Credentials和IdentityVerifier的,即包 security中的元素Credentials和IdentityVerifier对包Z中的 元素来说,其可见性是private 如果包users和包security是import的关系,那么,包Z中 的元素是可以见到包security中的元素Credentials和 IdentityVerifier的,也就是说,包security中的元素 Credentials和IdentityVerifier对包Z中的元素来说,其可 见性是public
2013-7-3
31
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
2.导入
security users User security::Credentials security::IdentityVerifier 《import》 +Credentials +IdentityVerifier
包之间有三种关系:
访问(Access) 导入(Import) 合并(Merge)
UML用带开箭头的虚线来表示包之间的关系
2013-7-3
23
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
9.3.3 包之间的关系
1.访问(Access) 2.导入(Import) 3.合并(Merge)
2.导入
包的导入关系指目标包中的内容将被导入到 源包中 目标包中的私有成员是不能被导入的 导入关系用构造型<<import>>加在虚线上表 示
2013-7-3
29
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
2.导入
security users 《import》 +Credentials
2013-7-3
21
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
9.3 包图的表示方法
9.3.1 包 9.3.2 包中元素的可见性 9.3.3 包之间的关系
2013-7-3
22
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
9.3.3 包之间的关系
统一建模语言UML –包图(Package Diagram)
统一建模语言UML
第9章 包图(Package Diagram)
1
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
第9章 包图(Package Diagram)
9.1 9.2 9.3 9.4 基于包的系统静止状态下的结构建模 包图 包图的表示方法 总结
2013-7-3
2
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
第9章 包图(Package Diagram)
9.1 9.2 9.3 9.4 基于包的系统静止状态下的结构建模 包图 包图的表示方法 总结
2013-7-3
3
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
java::util
Date
java::util::Date
(a)
2013-7-3
(b)
19
袁涛 孔蕾蕾
图9-5 用双分号(::)隔开的命名空间表示嵌套的包
统一建模语言UML –包图(Package Diagram)
9.3 包图的表示方法
9.3.1 包 9.3.2 包中元素的可见性 9.3.3 包之间的关系
2013-7-3
5
袁涛 孔蕾蕾
统一建模语言UML –包图(Package Diagram)
相关文档
最新文档