画图.docx

画图.docx

《画图.docx》由会员分享，可在线阅读，更多相关《画图.docx（17页珍藏版）》请在冰豆网上搜索。

画图

画用例图

2011-10-2214:

18:

26|分类：

默认分类|举报|字号订阅

用例图。

组成：

系统边界。

参与者。

用例。

关系。

参与者：

Actor不是人，而是指参与用例时担当的角色。

如果一个角色的操作是由另一个角色代理完成的，请建立该角色到另外角色之间的依赖。

怎样识别参与者呢？

是谁向系统提供的信息呢.

谁向系统获取信息。

谁操作系统。

系统使用哪些外部资源

系统是否和已经存在的系统交互

系统、子系统或类与外部的参与者（actor）交互的动作序列的说明，包括各种序列及出错序列。

用例分析可以认为是对系统功能的分解。

怎样确定用例的粒度呢？

用例的粒度（用例的大小）可大可小，一般一个系统易控制在20个左右。

用例是系统级的抽象的描述，不是细化的（是做什么，非怎样做）。

对复杂系统可以划分为若干个子系统处理。

怎样获取用例呢？

参与者希望系统执行什么任务？

参与者在系统中访问哪些信息（创建、存储、修改、删除等）？

需要将外界的哪些信息提供给系统？

需要将系统的那个事件告诉参与者？

如何维护系统？

UML中的四种关系。

关联（association）

包含（include）

扩展（extend）

泛化（generalization）

关联关系

描述参与者和用例之间的关系。

用单向箭头，表示谁启动用例。

每个用例都有角色启动，除了包含和扩展用例。

包含。

是指两个用例之间的关系。

其中一个用例（基本用例，baseusecase）的行为包含了另一个用例（包含用例，inclusionusecase）的行为。

如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用力拉可以和这个用例建立包含关系。

上面的例子就是说查询、提款和转账三个用例都有一个一致的功能，所以将这个功能提取出来为一个用例。

且这三个用例和提取出的这个用例之间是包含的关系。

执行基本用例的时候也可以执行被包含的用例，被包含的用例也可以单独执行。

如果一个用例的功能太多时，可以用包含关系建模成两个或多个小用例

扩展。

也是指两个用例之间的关系。

一个用例可以被定义为基础用例的增量的扩展，称作为扩展关系。

扩展关系是把新的行为插入到已有的用例中方法。

基础用例即使没有扩展用例的执行不会涉及扩展用例，只有在特定的条件发生，扩展用例才被执行。

泛化（继承）。

一个用例和其几种情形的用例间构成泛化关系。

往往父用例表示为抽象用例。

任何父用例出现的地方子用例也可出现。

1对用例的描述。

用例图：

只能描述系统的大概功能，是一种视图。

用例描述：

更详细地描述用例的功能。

2用例描述的组成

用例名称，简要说明/描述，优先级，参与者，前置条件，基本事件流，其他事件流，扩展点，后置条件。

事件流：

就是用例执行时，由一序列活动组成的控制流。

基本事件流：

对用例中常规、预期路径的描述。

扩展事件流：

主要是对一些异常情况、选择分支进行描述。

前置条件：

在用例启动时参与者（actor）与系统应置于什么状态。

后置条件：

用例结束时系统应置于什么状态。

以上述的"新增书籍信息"为例，说明如何细化用例描述。

用例的概要描述

用例名称：

新增书籍（UCO1）

简要说明：

录入新购书籍信息，并自动存储建档。

事件流：

基本事件流和扩展事件流。

非功能需求

前置条件：

用户进入图书管理系统。

后置条件：

完成新书信息的存储建档。

扩展点：

无

优先级：

高（满意度5，不满意度5）

详细描述

基本事件流

图书管理员向系统发出"新增书籍信息"请求。

系统要求图书管理员选择要增加的书籍是计算机类还是飞信计算接类

图书管理员做出选择后，显示相应界面，让图书管理员输入信息，并自动根据书号规则生成书号。

图书管理员输入书籍的相关信息，包括：

书名、作者、出版社、ISBN号、开本。

页数、定价。

是否有CD-ROM。

系统确认输入的信息中书名没有重名。

系统将所输入的信息存档建档。

扩展事件流。

A如果输入的书名有重名现象，则显示出重名的书籍，并要求图书管理员选择修改书名或取消输入。

A

（1）图书管理员选择取消输入，则结束用例，不做存储建档工作。

A

（2）图书管理员选择修改书名后，转到A。

如下例所示建立用例模型。

有一个业务需求如下，要求我们为其构件一个用例图。

1）系统可以供教师使用来为学生记录成绩。

2）系统根据需要创建报告卡。

系统允许用户浏览记录的成绩。

首先这里面要问到的是：

11）中教师可以记录学生信息，这就是说教师可以录入、修改和删除学生信息了。

22）中系统要创建报告卡，是谁来创建报告卡呢？

这里就应该有权限的问题了，系统需要管理人员来来执行这项工作，另一个方面做系统的维护工作。

报告卡创建后干什么？

管理人员检查其准确性之后，由教师来分发报告卡。

33）系统允许用户浏览成绩，是谁可以浏览成绩呢？

是学生和老师。

从中得到这个系统的参与者是：

教师，学生，管理员。

主要用例：

录入成绩。

更新成绩。

生成报告卡。

报告卡准确性。

分发报告卡。

浏览成绩。

要区分用例的优先级。

首先是：

记录成绩，浏览成绩，更新成绩，生成报告，检查报告卡的准确性，分发报告卡。

细化每一个用例。

对"记录成绩"进行细化，下面是对该用例的主事件流。

首先是教师要确定录入哪些学的成绩。

系统中要确保学生在数据库中。

教师说明记录哪像作业的成绩。

系统开始数据库的一些事物。

系统为学生把作业加入到数据库中。

教师输入学生作业的成绩。

系统核对输入的成绩是否符合正确的范围和格式。

系统记录作业的成绩。

系统结束事物的处理。

系统提示教师成绩已经记录好。

从细分的用例中发现新的用例，并根据优先级重新排列。

机房收费系统的用例图。

1、首先是分析系统中的角色（Actor）。

谁向系统提供信息？

-----学生

谁从系统获取信息？

----学生、管理员、操作员、一般用户

谁操作这个系统呢？

--一般用户、操作员、管理员。

谁维护这个系统呢？

---管理员。

系统要使用的外部资源？

---数据库。

系统是否和已经存在的系统交互？

---好像没有。

从中找出这个系统的Actor---（学生、一般用户、管理员、数据库）

基本Usecase。

找出的参与者希望系统执行什么任务？

学生---去注册卡号，后充值，上机，下机，付钱，查看信息（查看自己的个人信息，上机信息，卡内的余额信息），不想用了就注销卡号。

（学生的需求是要通过系统用户对系统的操作来完成的。

所以学生和系统用户这两个角色之间是关联关系。

）

一般用户—主要是用这个系统来管理学生上下机。

可以登录到系统中去，后学生刷卡上机，显示上机的学生的记录，显示登录时间，查看学生上机状态，学生下机，显示下机时间和消费金额，可以修改自己的密码，查询余额。

操作员---主要是用这个系统为学生进行注册充值以及查询一些信息。

登录到系统中去，可修改密码，根据学生的要求使用系统来，注册，充值，退卡，注册后充值可以查看收取金额，学生基本信息维护，学生上机统计信息，最后退卡时，查看金额退还信息来退还相应的钱数。

最后可以查看老师和自己的工作记录。

管理员---登录到系统中去，可以修改密码以确保安全性。

利用这个系统可以对学生的上下机情况查看。

可以对一般用户和操作员的工作记录查看。

参与者在系统中访问哪些信息（创建、存储、修改、删除等）？

参与者在系统中需要访问

需要将外界哪些信息供给系统？

外界提供给本系统的信息是---学生信息、系统时间信息、系统用户信息。

需要将系统的哪个事件告诉参与者？

……无……

如何维护系统？

管理员负责对系统的维护-----基本数据的设定。

用例图如下所示：

学生和一般用户的用例图。

学生和操作员的用例图。

学生和管理员用例图所示：

<转>UML类图基本画法

1.类（Class）：

使用三层矩形框表示。

第一层显示类的名称，如果是抽象类，则就用斜体显示。

第二层是字段和属性。

第三层是类的方法。

注意前面的符号，‘+’表示public，‘-’表示private，‘#’表示protected。

2.接口：

使用两层矩形框表示，与类图的区别主要是顶端有<>显示。

第一行是接口名称。

第二行是接口方法。

3.继承类（extends）：

用空心三角形+实线来表示。

4.实现接口（implements）：

用空心三角形+虚线来表示

5.关联（Association）：

用实线箭头来表示，例如：

燕子与气候

6.聚合（Aggregation）：

用空心的菱形+实线箭头来表示

聚合：

表示一种弱的‘拥有’关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分，例如：

公司和员工

组合（Composition）：

用实心的菱形+实线箭头来表示

组合：

部分和整体的关系，并且生命周期是相同的。

例如：

人与手

7.依赖（Dependency）：

用虚线箭头来表示，例如：

动物与氧气

8.基数：

连线两端的数字表明这一端的类可以有几个实例，比如：

一个鸟应该有两只翅膀。

如果一个类可能有无数个实例，则就用‘n’来表示。

关联、聚合、组合是有基数的

类之间的关系

UML把类之间的关系分为以下5种.

●关联：

类A与类B的实例之间存在特定的对应关系

●依赖：

类A访问类B提供的服务

●聚集：

类A为整体类，类B为局部类，类A的对象由类B的对象组合而成

●泛化：

类A继承类B

●实现：

类A实现了B接口

关联（Association）

关联指的是类之间的特定对应关系，在UML中用带实线的箭头表示。

按照类之间的数量对比，关联

可以分为以下三种：

●一对一关联

●一对多关联

●多对多关联

注意：

关联还要以分为单向关联和双向关联

依赖（Dependency）

依赖指的是类之间的调用关系，在UML中用带虚线的箭头表示。

如果类A访问类B的属性或者方法，

或者类A负责实例化类B，那么可以说类A依赖类B。

和关联关系不同，无须在类A中定义类B类型的属性。

聚集（Aggregation）

聚集指的是整体与部分之间的关系，在UML中用带实线的菱形箭头表示。

聚集关系还可以分为两种类型：

●被聚集的子系统允许被拆卸和替换，这是普通聚集关系。

●被聚集的子系统不允许被拆卸和替换，这种聚集称为强聚集关系，或者组成关系。

注：

强聚集（组成）可用带实线的实心菱形箭头表示。

泛化（Generalization）

泛化指的是类之间的继承关系，在UML中用带实线的三角形箭头表示。

实现（Realization）

实现指的是类与接口之间的关系，在UML中用带虚线的三角形箭头表示。

以下是GOF设计模式中的描述：

箭头和三角表示子类关系。

虚箭头线表示一个类实例化另一个类的对象，箭头指向被实例化的对象的类。

普通的箭头线表示相识（acquaintance也叫关联或者引用），意味着一个对象仅仅知道另一个对象。

相识的对象可能请求彼此的操作，但他们不为对方负责，它只标示了对象间较松散的耦合关系。

尾部带有菱形的箭头线表示聚合（aggregation），意味着一个对象拥有另一个对象或者对另一个对象负责。

一般我们称一个对象包含另一个对象，或者是另一个对象的一部分。

聚合意味着聚合对象和其所有者具有相同的生命周期。

抽象类名以斜体表示，抽象操作也以斜体表示。

图中可以包括实现操作的伪代码，代码将出现在带有褶角的框中，并用虚线将该褶角框与代码所实现的操作相连。

图一:

此实线箭头表示,继承,从一个非接口类的继承.

图二:

那条连线表示双向关联:

看左边,Flight扮演assignedFights角色,有0到1个Plane跟他关联（一个航班要么取消了没有飞机,要么只能对应一架飞机）

看右边,Plane扮演着assignedPlane角色,有0到多个Flight跟他关联（一个飞机可以参与多个航班,也可以停在仓库里面烂掉）

图三:

那条连线表示单向关联:

基本的意义跟上面的是一样的,唯一不同的是,右边的类对左边的类是一无所知的.

图四:

那个大的包围的框叫软件包,名字为Account,就一些可以归类的类包装起来.

图五:

如此虚线的箭头表示实现一个接口.

图六:

水平的连线还是表示上面所说的关联,但从关联连线中引伸出来的虚线,这意味当Flight类的一个实例关联到FrequentFlyer类的一个实例时，将会产生MileageCredit类的一个实例.

图七:

带菱形的箭头表示基本聚合,由上图知道,Wheel类扮演wheels角色,聚合4个到Car对象里面去,

空心的菱形表示Wheel对象并不随Car的创建而创建,销毁而销毁.

图八:

意义和上面类似,唯一不同的是,实心菱形表示Department对象随Company对象的创建而创建,销毁而销毁.