2月 29

包图

包图就是由包与包之间的关系组成的。

包图也是一种静态结构,包可以拥有的元素:

我想上面的元素大家都是有所了解的,我这里就不一样举例说明了,下面通过一个例子来显示如何使用包图。

包的访问限制:与我们平时了解的3个访问权限设置关键字用法相同。

包与包之间的关系:

a、引入与访问依赖:首先这个关系与平时我们说的类的继承关系是不同的.包括包的访问域不能继承。

用于在一个包中引入另一个包输出的元素,因此A依赖B,包A引入包B中的B方法。B这里的访问权限是公共的。A中的方法是保护的。

b、泛化关系:

泛化关系描述了一种继承关系。即基类与特殊类之间的关

系,途中描述的意思是只要是包A出现的位置都可以用包B替换。

3、组合结构图

组合结构图:以结构化的方式给出类型的内部结构。组合结构图是一种静态结构,它显示了一个类型内部的成员及成员之间的关系。组合结构图可以这样理解,

就是描述类的内部结构及成员之间的调用关系的建模图。组合结构图用于扑捉类的内部细节,描述了对象如何在某个类中协同工作。

组合图中其实就是描述类的内部的结果,基本上的元素有:类、对象,其他等,具体的关系请参考类图中的关系。

组合图实例:

上图显示了产品与产品品牌与产品分类的组合关系。产品品牌与产品分类是关联关系(关联关系可

以是1:N),通过一条直线来链接。如果有不清楚的地方请看类图的相关介绍:系统架构师-基础到企业应用架构-系统建模[上篇]。

written by ocean

2月 29

对象图

首先、我们闲来讲解对象图。对象图用来描述系统的各个对象在某一时刻的状态。对象和类图一样他们是静态结构图。他们是从实际的或者原型化的场景去表达

的。对象图显示了某一时刻对象与对象的关系。一个对象图可以看作类图的特殊用例,类图中的关系同样适用在对象图中。可以这样理解,对象图就是类图的实例。对

象图是有生命周期的,因此对象图只在某个时间段内存在。

对象图中的元素在类图中都可以找到,只是把类图中的类元素换成对象即可。而类图中类元素之间的关系,在对象图中同样适用。这里不在复述。如果对类图不

是特别的熟悉,请看这篇文章中的讲解:系统架构师-基础到企业应用架构-系统建模[上篇]。

下面讲解对象图的举例:

这里的对象是指某个类的实例。

这样的格式表示了某个类的实例的格式,冒号“:”后面跟着类名,也就是这里的“父类”。另外还必须加上下划

线。

对象首先是一个确定,所以一般情况下,对象属性一般把值直接列出来。如下形式:

对象图中的所有的对象名可以为空,但是为了更好的标识对象图中的对象,不建议这么做,并且如果未指定对象名那么必须指定该对象所属的类格式如下:

没有对象名的对象实例。

下面以B2C中的订单系统中的新订单的状态为例,讲述下各对象的状态。

这里的关系表示的是组合关系

上图中的订单信息的状态:订单(新订单)-物流信息(未发货)-支付信息(未支付)-产品状态(产品信息)。

written by ocean

2月 29

活动图

活动图主要是用来描述系统的动态行为,从一个活动到另一活动的控制流。活动图的本质是流程图,但是与流程图又有所不同。在本小节中将会详细的讲解活动

图与流程图的本质的区别及活动图与状态图的区别。

按照惯例,我们先来看看活动图的元素:

1、动作状态:

通过用圆形边的长方形来表示一个动作状态。动作状态有几个特点:原子性(要么执行,要么不执行)、不可中断的操作,并且此次动作完成后一定转向到另外一种

状态。 动作状态是构造活动图的最小单位。

状态图区别:

a、活动图中动作状态可以有入转换与出转换,意思就是说可以从当前状态转向到另外一个状态,也可以从另外一个状态转换到当前状态。图形化的表示如下:

B动作状态,可以有入转换A,出转换C。

动作状态必须至少有一个出转换,转换都是以内部的完成为起点,与外部事件无关。

实心圆:代表起始状态。

环形内的实心圆:代表结束状态。

b、动作状态与状态图不同的是,动作状态不能有入口动作与出口动作。更不能有内部转移。

2、活动状态:

通过二个半圆与一个长方形组合起来来标识活动状态。

活动状态首先可以被分解成多个子活动或者多个子动作状态。活动状态他不像动作状态是原子性的。活动状态是非原子性。活动图内部的活动,可以用另外一个

活动图来表示。活动状态可以看作多个动作状态和多个子活动的组合。

活动状态与动作状态不同,动作状态是活动状态的一个特例,当某个活动状态只有一个动作状态时,这个活动状态就是一个动作状态。活动状态可以有入口动作

和出口动作。还可以有内部转移。因为活动图是多个子活动和多个动作状态的组合,所以本来动作状态直接的转向就可以看作是内部转移了,所以就很好理解了。

上图已经基本表示出来了活动状态中的动态状态的转移等。我相信大家都能理解。

3、动作节点之间的关系

a、控制流: 与状态图中的转向相同,活动图也使用一个带箭头的线段,箭头指向要转入的状态。

b、分支: 活动状态从A分支出来活动状态B、C,

c、合并: 活动状态B从活动状态A与C合并后得到。

d、泳道:泳道将活动图中的多个活动划分成多个组。并且把每一组活动都由对象来负责组织业务,泳道区分了负责活动的对象。并且泳道明确的表

示了哪些活动是由哪些对象进行的。泳道通过垂直线来区分。而2个垂直线分割的区域即是一个泳道。上面的解释可能有点绕,说白了泳道即是上面说的对象,对象就是

泳道。把不同的泳道就叫一个对象。每个活动状态在有泳道的活动图中,只能属于一个泳道。

下面来看有泳道的图例:

上面有2个泳道,分别是我是泳道1,我是泳道,并且我是泳道1中的D与我

是泳道中的活动状态A有转向关系。

e、对象流。

对象流是对象与动作状态或者活动状态直间的依赖关系。表示动作使用对象或者动作对对象的影响。一般我们在使用中,我们可以把对象通过依赖关系与动作状态或者活动状态进行链接。

对象流的几个特点:

(1)、一般一个对象可以由多个活动状态或动作状态操作。

(2)、一个活动状态或动作状态的输出对象可以作为另一个活动状态或动作状态的输入。

(3)、一个对象可以在一个活动图中多次出现,但是有点需要注意,这个对象多次出现时表名该对象处于生命周期的不同时期。

包含对象流的活动图:

泳道M1中出现了对象。并且该对象与活动状态B有依赖关系。

总结

本节中讲解了,活动图的基本知识,下面我们以我们平时比较熟悉的B2C业务,电子商城为例说明下,会员的产品管理流程。通过状态图的形式来表达。以巩固

下我们学习的成果。

例如B2C中的产品管理。首先必须是会员才能登入系统中,然后必须是我是卖家,然后才能进行发布产品的操作。

会员先要开启店铺,设置权限后才能进行产品管理

written by ocean

2月 29

部署图

首先,我们先来讲解部署图。部署图主要是用来描述一系列组件部署到节点运行的结构。部署图显示了系统运行时的结构。一般情况下部署图帮助我们来理解分布

式应用系统。同时部署图还传达了构建应用系统的软件与硬件元素的配置及部署方式。

部署图中的基本元素:

1、节点:这里就是指组件运行的环境。可以是软件(操作系统、其他等)或硬件资源(计算机,其他硬件)。

UML建模语言中的通用图形化表示为:

2、节点实例:节点实例与节点的区别就是有下划线和冒号,节点实例必须紧跟冒号,当然这个节点实例名称可以为空,节点必须要有。

3、组件容器:一个节点可以包含其他节点,可以是组件,也可以是节点。

4、节点之间的关系

(1)、单向依赖:

上图表示 查询统计组件,通过.net提供的ADO.NET访问SQLServer2005数据库。

(2)、双向依赖:

上图表示:产品管理模块会把数据写入到数据库中,同时产品管理中的信息会从数据库中读取,双向依赖。

(3)、通信:

上图表示:应用软件系统与数据库通过.NET提供的方式相互通信,个人理解任务就是双向通信(双向依赖)[错误之处,还请高人指出]。

5、实例讲解:

下面我们已一个简单的系统B2C来进行讲解:

我们先来看看B2C系统中的相应节点:

客户端通过浏览器访问B2C站点,首先进入会员管理,如果注册,则进入到注册系统。会员管理中完成对采购的管理、支付、发布等。

节点描述:

浏览器:通过键入网站地址访问B2C站点。这是与B2C系统交互的唯一入口。

注册系统:完成用户的注册与数据库通信。图上并未画出,所有的节点除了浏览器不需要直接与数据库交互外,其他的模块都需要与数据库通信。

会员管理:完成会员中心的管理。会员的个人信息,开店的店铺信息,收货地址等等信息的管理,我的采购,我发布的产品等等。

采购系统:系统中的子功能,用于完成买家的产品采购。

发布系统:主要为卖家提供服务,发布产品信息等。与数据库通信

支付系统:完成支付交易的操作。与个人账户进行通信。

当然这里只是举个简单的例子,其他的内容,比如前台的展示等等,这些目前都没有考虑其中,也没有仔细分析,这里只是达到介绍的目的。

6、总结

通过上面的讲解相信大家对部署图已经有了基本的认识,部署图主要是用来完成将组件部署到节点上运行的结构。从整体上描述了,系统运行时的结构。部署图是

必须要掌握的建模图。

written by ocean

2月 29

状态图其实是针对一个对象(实体、组件其他元素等)来说的。主要是描述了,对象的行为如何改变状态的反映。我们研究UML状态图的目的就是为了搞清楚,对

象状态的变化与行为的关系。建模对象的实时行为。创建状态图的条件:当对象行为的改变与状态有关的时候才创建状态图。状态图反映了对象如何改变状态相应行为

的变化和展示对象的生命周期的创建和删除的全过程。

详细

状态图可建模的对象:

用例:可以描述用例图中的某个用例状态的变化。

类:可以描述某个类的状态的变化。

子系统:可以描述某个子系统中状态的变化。

整个系统:类似(WF)工作流中的流程,每个节点其实就相当于一个状态。

上面简单的绘制了一个去餐厅吃饭的状态变化,每个状态变化的行为都有描述,当然我这里只是简单的举例说明状态图的变化,并没有详细分析的所有可能状态都画出来。

具体的状态还请大家自己练习画出来,此处只是简单的举例说明。

状态图中的元素:

状态标记:

状态图中可以标识一个或多个初始状态,也可以包含一个或多个结束状态。

状态图中不同状态之间的关系:

转移关系,用来描述对象的状态从一个状态转移到另外一个状态的处理流,箭头指向转移后的状态。

状态图中提供了类似流程图中的判定的功能元素:决策点。

通过元素决策点来完成:

决策点,用来决策跳向不同的状态。

具体用例如下:

就是起到了一个决策的作用。这里不在复述。

状态图中的同步:

状态图中的同步主要是为了说明并发工作流的分岔和联合。下图描述了状态图中的同步条:

初始状态进入到同步条中分岔同步执行操作A与B,分别进入A状态、B状态,然后分别执行A1,B1联合进入到结束状态。

一个对象可以通过同步操作同事拥有多个状态。有时候一个对象还可以拥有不同层次的多个状态。当单个状态拥有独立的附加子状态时就可以在状态图中使用层次结

构的状态。

组合状态就是这样的比较复杂的状态结构图,有时候我们需要把一个复杂的状态细化成多个子状态的合成,那么这个复杂的状态就可以叫组合状态。

下面举例说明:

组合状态B,也即复合状态B,内部可能有比较复杂的状态(C-D状态)。这种只是组合状态B中存在单个状态变化流程的情况,还可能组合状态B中包含更多的状态流。

那么我们就要用如下的状态图完成:

上图中1代表的是下单的流程,2代表付款流程。

总结

通过上面的学习我想大家对状态图有了一定的了解,那么我们来总结下,如何建模状态图。

第一步:我们知道建模状态图,首先需要抽象出来要建模的对象。

第二步:我们基于这个对象分析出该对象具有的所有状态及发生状态改变的行为。

第三步:标识每个对象状态的起始状态与结束状态。

第四步:开始创建对象的状态图,分析是否有必要创建复杂的组合状态。

系统架构设计的过程中,我们首先要分析出哪些对象需要使用状态图来描述。如果某个对象具有复杂的行为,那么可以使用活动图来建模比使用状态图更适合。每个

状态图必须至少有一个起始状态和结束状态。并且详细的分析对象发生状态改变的行为。从某个状态转移到另外一个状态的行为是什么。在某些情况下,如果对象的某

个状态无法清晰的表达时,可以通过创建组合状态来进一步细化该状态,这样能更清晰的表达对象的状态变化。

written by ocean

2月 29

简介

众所周知,组件图是用来描述系统中的各组件之间的关系。首先我们必须知道组件的定义是什么,然后组件之间有哪些关系。理清楚这些,我们在以后的设计中才能

派上用场。UML语言对组件的定义已发生了巨大变化。在之前的版本里面,UML如下定义组件的:

UML1.1语言中对组件的描述:把某个文件或者可以运行的程序称之为组件。但是我们知道,UML出现组件图以前,组件一般用来描述COM组件或者其他的组件,因此造成冲突,所以随着后续UML语言的发布,修改了原有的含义。

UML2.x语言中对组件的的描述:组件是独立的,是运行在一个系统中的封装单位,提供了一系列的服务。

通过上述UML语言中的变迁,目前的理解是:一个系统,可以随意更换系统中的某个组建。而不会影响系统的运行。这可以理解为类似,大家熟悉IOC容器的都应该

知道,运行在IOC容器中的对象,可以看作组件,那么替换其中的提供某一服务的组件,只要满足该组件服务的相关契约就能自动完成替换。而不会影响系统的运行。

每个组件都封装了一些特殊的行为,实现了特定的服务。

组件之间的关系有哪些呢?我们通过下图来看看,组件直接可能存在的关系:

组件直接的关系基本上来说就这2种。下面会举例区别2中关系。

组件图提供的服务:组件图为系统架构师提供了解决方案的自然形式。组件图允许架构师验证系统的必需功能是由组件来完成的。组件是可以复用的。

详解

组件图中包含的元素:

下面我们分别讲解:

(1)、组件:我们知道组件是组件图中最基本的组成元素,组件上面已经讲述了组件的定义。这里就不在多介绍,组件图组成的基本单位即组件。

(2)、容器:可以为多个组件提供服务的管理容器,容器中的组件相互交互。

(3)、包:可以看作一个子系统,其实也可以看作是特殊的组件。

(4)、约束:用于定义接口规范。

(5)、给组件图中的相应元素添加相应注释信息。

组件上可以定义自己的接口。例如上图,人这个组件提供了2个接口。Thinking与Sleep接口。

组件关系的建模:

我们来看看组件之间的关系的表示,根据上面讲解的组件的关系有依赖和泛化,参考类图中的依赖和泛化。

依赖关系,标识一个组件依赖另外一个组件,如果被依赖组件无法正常运行,那么该组件也无法运行。

泛化关系。标识一个组件与其他多个组件的关系为继承关系。

总结:

通过上面的学习我们知道:组件图主要是为系统架构师对整个系统的解决方案的自然形成,可以通过组件图的形式把系统的大体功能进行区分和设计。通过组件图把

系统功能进行抽象和分离。然后通过顺序图把功能流程细分成多个步骤,然后通过类图去构建每个流程步骤中的每个类应具有的个方法。最后形成一个完整的设计文

档。

written by ocean

2月 29

介绍

顺序图也称序列图,主要用来系统中的某个流程的详细步骤。顺序图能够给出流程中一系列对象的交互顺序。通过顺序图可以让我们更好的了解如何实现某个用例

的方法。我们知道用例图用来描述系统的功能需求。而顺序图清晰的描述了某个用例也就是系统功能的的实现方法。

详解

在顺序图中包含的元素:

对象:用来标识流程中的详细步骤中的对象。

活动条:用来标识当前对象是活动的,如果想表示某个对象是活动的,那么必须使用一个虚线+活动图的形式来构建。

例如我们现在要标示一个简单的做公交车的刷卡流程:

IC卡刷卡操作。

相关解释说明:

公交卡,首先放在刷卡终端上,终端读取卡中的余额信息,然后刷卡终端与终端中的扣款程序对象交互,扣款程序根据读取的余额信息,与刷卡终端中的固定刷卡

金额对比,如果当前IC卡的余额大雨刷卡终端的固定金额则,扣除金额,并且返回一个消息,提示刷卡成功的操作。

途中的实线表示调用被调用对象的方法,虚线表示当被调用对象执行成功后,返回的虚线上表示返回值的逻辑名称,这样可以提高了可读性。

在公交卡与活动条之间,应有一个虚线链接。

在上图中我们使用了活动条,活动条作为生命线的一部分。我们并没有定义对象的创建和销毁,因此我们来看UML建模语言提供的描述对象的创建与销毁实例。

上图中的X符号的图标代表的时候对象的销毁。创建对象通过new来创建,上图中,我用中文描述“创建对象”来完成对象的创建,那么在生命线下的的X符号代

表销毁对象,从内存中移除对象。当然这个对象的销毁对不同的开发语言有这不同的处理方式。C++中的销毁对象,必须调用析构函数来销毁对象。C#与JAVA语言中

则只是说明当前需要销毁的对象没有被其他的对象引用,那么这类语言编译器提供垃圾回收器来完成回收。

注意:当某个对象引用了另外一个对象,该对象有责任销毁被引用对象并且必须显示销毁该被引用对象时,那么必须要显示的发送被引用对象销毁的通知消息。白

话文来说就是显示的调用被引用对象的销毁方法。

顺序途中的同步与异步。

顺序图中的同步与异步与我们平时书写代码中的同步与异步的解释意思差不多。这里不过多解释,通过图例说明:

客户去餐厅吃饭,首先要点餐,必须等待点餐完了才能上菜。意思就是可以这样简单描述。A简单调用B方

法,必须等待,等到B方法执行完毕后,继续执行。

函数A调用函数B,如果B需要的时间特别长,那么此时A可以去继续执行做其他的事情比如做和函

数C交互,等B函数执行完了,只需要回调通知A,B函数执行完了即可。在函数调用中的术语就是回调。

UML建模语言中同步与异步消息的标识格式:

UML提供了一些顺序图的高级功能:例如可以通过顺序图实现流程的控制。具体的实现工具是通过UML提出的交互框来实现流程条件的控制。

交互框其实就是定义了流程控制图中的控制逻辑,基于交互框定义流程执行的条件。如果满足这个条件,那么则执行交互框中已定义好的顺序步骤。否则不做任何

操作。交互框中除了定义流程控制的条件外,还有一些自己特殊的操作符,具体的操作符及其作用,如下列表:

每个关键字代表的含义都有相应的描述。大家应该都可以看明白,上述的所有含义都是针对交互框来说的。

总结

如果在系统功能中有特殊需求,那么顺序图中的交互框是可以支持嵌套的。嵌套交互框的话,会提高顺序图的复杂度,降低可读性。因此我们设计时的原则尽量把复

杂的流程拆分成几个简单的,分别绘制顺序图来完成相应步骤。

written by ocean

2月 29

类图也是UML建模中最常用的一种结构图,类图用来标示系统的静态结构。静态结构是由类型及关系构成。

类图表示不同的实体(人、事物和数据)如何彼此相关;换句话说,它显示了系统的静态结构。类图可用于表示逻辑类,逻辑类通常就是业务人员所谈及的事物种

类–摇滚乐队、CD、广播剧;或者贷款、住房抵押、汽车信贷以及利率。类图还可用于表示实现类,实现类就是程序员处理的实体。实现类图或许会与逻辑类图显示一

些相同的类。然而,实现类图不会使用相同的属性来描述,因为它很可能具有对诸如Vector和HashMap这种事物的引用。

类图其实就是一个长方形,内部分成3个区域。每个区域的含义不同。

类图中也有命名空间的概念,是通过包来实现的如果想定义该类在某个命名空间中,则在定义类名时按照如下类似格式标示

命名空间 :: 类名 [必须按照这样的形式才可以]。

类图中的有3类修饰符,每种修饰符标示的含义不同。

具体用法如下:

理解成具体的类代码的格式如下:

public class Product

{

Public string ProductName;

public void GetProductLists(string sWhere)

{

//TODO….

}

}

如果在类图中的属性定义与函数成员的定义是斜体表示的话,则表名该成员是虚成员。

虚成员

如果在类图中的属性定义与函数成员的定义是带下划线的话,则表名该成员是静态成员。

静态成员

当然这是最基本的类图,还有一种特殊的,类图支持参数化类型即是.NET中的特殊类型[泛型格式]标示。

参数化类图

具体的表示形式如:该符号在类的右上角有个长方形其中可输入类型如上图。

类图中属性包含的元素:

访问修饰符:Public、Protected、Private

特性/属性名称:特性/属性名称

类型:可以是自定义类型或者是系统类型。

默认值:即特性/属性的默认值,如果有的话。

重复性:可以用来定义多个对象的集合,特性值中包含的对象个数。

类图中操作包含的元素:

访问修饰符:Public、Protected、Private

操作名称:函数名称

操作列表:函数的参数列表。

返回值:函数的返回值,如果有的话。

函数参数列表中的参数方向:

类图之间的关联关系

首先我们知道,我们在设计类的时候就是把独立的功能放在一个类中,不同的类之间进行交互,那么我们在类图中如何去表述这样的类之间的关系呢?

类图直接的关系:

1、关联关系:关联标识2个类直接存在关系。是通过一条线来表示,关联关系中包含了2种特殊的关系:聚合和组合

聚合代表的2个类直接是has-a的关系,即部分与整体的关系,具体的图标通过一条虚线带有菱形箭头,箭头指向的方向即是整体的部分,代表该类包含另一部分。

聚合例如: 代表产品中具有ProductName这个成员。

组合举例:组合关系的标示与聚合比较类似,唯一区别实心的菱形。

组合例如:

组合与聚合的区别:

在聚合关系中被包含对象可能不完全依赖容器对象,也就是说ProductName不完全依赖Product。如果Product对象销毁,但是可能ProductName对象没有被销

毁。可以这么想想产品的分类不会因为产品销毁而不存在。

组合关系中则是比聚合的关联程度更高,Product完全包含ProductName。如果销毁Product时,那么ProductName也一定被销毁。产品从数据库被删除了,那

么与产品相关的的数据列属性也被删除了,这里只是举例子,可能不太合适。

类图之间的泛化关系

泛化关系:存在2个类之间。一个类是另外一个类的子类,表示一个类是另外一个类的特例。

表示方法:通过一个带有空的三角形箭头的线段标识,箭头指向父类型。

表示火车和汽车是交通工具的子类型。

类图之间的依赖关系

依赖关系描述为:一个类型必须依靠另外一个类才能实现相应的功能。最简单的理解方式:依赖注入中的构造函数注入。

具体的表示方法:一个带有箭头的虚线段。箭头方向标示被依赖的类型。

例如:

written by ocean

2月 29

1、用例图:

我想用例图大家都应该基本上有所了解,只要使用过UML建模的除了基本的流程图基本上大家都会的使用外,用例图用过是最常见的一种建模图形。

用例图中主要包含的元素:系统、参与者、用例、关系。

用例图主要的应用场景:一般用例图用来描述需求中的系统应具有的功能,系统参与者(使用者,维护者、外部系统或者用户等)与系统如何交互进行一个模型话的描述。

用例图的目的:帮助开发团队以一种可视化的方式理解系统的功能需求。

一般使用如下方式来进行操作:

用来标识系统的参与者,任何与系统交互的对象,都可以叫参与者。

是用来描述系统中的某个模块与参与者的一次交互过程。

系统参与者与用例之间的具体关系通过如下连线标示:

这几类不同的连线来标识不同的用例之间或者用例与参与者或者2个参与者直接直接的关系。

UML定义了3类标准的关系:

第一种:包含,通过一条直线链接2个用例,因此是用例之间的关系链接,表述了箭头的开始一端包含箭头指向的一端的用例。

例如:

第二种:扩展,通过一个反向的直线来标识某个用例扩展了另外一个用例的行为,一般情况下箭头指向的用例即是被扩展的用例。

例如:

第三种:泛化,用来标识具有同质关系的参与者与参与者或者用例与用例之间的关系,泛化类似继承关系。箭头指向的为父元素。

例如:

除了以上的3中关系还有一种未列在规范关系的我们把它叫做关联关系。这种关系是用来描述用例与参与者直接的关系的。是通过一条直线来完成链接的,泛化关系

描述了链接的2个部分存在某种程度的交付。一般情况下,我们可以系统的功能情况分析出系统中的主动发和被动方。

 

如何使用用例图:

第一步:先把系统按照功能进行划分,比如一个简单的内容管理系统。先把他细化,细化成多个模块功能。每个模块的功能相对独立,但是可能又与另外一个有交

互。

第二步:把功能需求抽象,达到高内聚,低耦合的标准,然后分析出该模块功能的参与者是什么,例如用户是谁?或者细分成角色,与该模块交互还可能是数据库?

等,把所有交互的对象分析出。

第三步:把系统模块中的每个功能模块看是否能再按照子功能进行细分,细分后形成具体的用例。

第四步:分析用例与参与者之间的关系,分析同质对象(参与者与参与者、用例与用例)之间的关系。

第五步:根据以上四步完成建模。在建模的过程如果发现某块功能不清晰或者参与者不清晰,可重复前4步。

written by ocean

2月 29

UML建模语言(Unified Modeling Language) 统一建模语言。经过不断的发展,目前UML已成为业界公认的标准的建模语言。

 

学习过UML语言的开发人员都知道UML分为以下几类模型图:

通过上图我们知道UML的分类,分为结构型与行为型建模图形。下面的内容将详细的讲述每种建模图形的使用场景及如何使用

 

用例图

类图

顺序图

组件图

部署图 

活动图

对象图

包图

转载地址:

http://www.博客园.com/hegezhou_hot/archive/2010/09/10/1822887.html

written by ocean