首先是复习一下UML中九种图的理解：
用例图。
用例图是用来描述用户需求的，从用户的角度来描述系统的功能，并指出各个执行者。强调谁在使用，系统的执行者是谁。
类图。
用来定义系统中的类，包括描述类的结构和类之间的关系。类图的主要作用于描述系统的静态结构。
对象图。
对象图是类图的一个实例，描述了系统在具体时间点上所包含的对象以及各个对象之间的关系。
状态图。
状态图说明对象在它的生命周期中响应事件所经历的状态序列，以及它们对那些事件的响应。
构件图。
构件图用来描述代码构件的物理结构以及构件之间的依赖关系。一个构件可以是一个资源文件、一个二进制文件或者已给可执行文件。
实施图（部署图）。
用来定义了系统中硬件的物理体系结构，用来描述实际的物理设备以及它们之间的连接关系。
顺序图（序列图）。
描述对象之间的交互顺序，着重体现对象之间消息传递的时间顺序，强调了对象之间消息的发送顺序，同时也显示了对象之间的交互过程。
协作图。
协作图是一种交互图，强调的是发送和接受消息的对象之间的组织结构。
协作图主要描述协作对象的交互和链接。
显示对象间的连接以及对象之间如何发送消息。
协作图可以表示类操作的实现。
活动图。
概述系统的动态行为，包括活动状态，活动状态是指业务用例的一个执行步骤或一个操作，不是普通对象的状态。活 动 图适合描述在没有外部事件触发的情况下，系统内部的逻辑执行过程，否则状态图更容易描述类似与传统意义上的流程图。业务建模时，用于详述业务用例，描述一项业务的执行过程设计时，描述操作的流程。
下面的图感觉总结的挺好的，所以就粘过来了，便于再次理解UML。
画用例图：
组成：系统边界。参与者。用例。关系。
参与者：Actor不是人，而是指参与用例时担当的角色。
如果一个角色的操作是由另一个角色代理完成的，请建立该角色到另外角色之间的依赖。
怎样识别参与者呢？
-
是谁向系统提供的信息呢.
-
谁向系统获取信息。
-
谁操作系统。
-
系统使用哪些外部资源
-
系统是否和已经存在的系统交互
系统、子系统或类与外部的参与者（actor）交互的动作序列的说明，包括各种序列及出错序列。
用例分析可以认为是对系统功能的分解。
怎样确定用例的粒度呢？
用例的粒度（用例的大小）可大可小，一般一个系统易控制在20个左右。用例是系统级的抽象的描述，不是细化的（是做什么，非怎样做）。对复杂系统可以划分为若干个子系统处理。
怎样获取用例呢？
参与者希望系统执行什么任务？
参与者在系统中访问哪些信息（创建、存储、修改、删除等）？
需要将外界的哪些信息提供给系统？
需要将系统的那个事件告诉参与者？
如何维护系统？
UML中的四种关系。
关联（association）
包含（include） 
扩展（extend）
泛化（generalization）
关联关系
描述参与者和用例之间的关系。
用单向箭头，表示谁启动用例。
每个用例都有角色启动，除了包含和扩展用例。
包含。
是指两个用例之间的关系。其中一个用例（基本用例，base use case）的行为包含了另一个用例（包含用例，inclusion use case）的行为。
如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用力拉可以和这个用例建立包含关系。
上面的例子就是说查询、提款和转账三个用例都有一个一致的功能，所以将这个功能提取出来为一个用例。且这三个用例和提取出的这个用例之间是包含的关系。
执行基本用例的时候也可以执行被包含的用例，被包含的用例也可以单独执行。
如果一个用例的功能太多时，可以用包含关系建模成两个或多个小用例
扩展。
也是指两个用例之间的关系。一个用例可以被定义为基础用例的增量的扩展，称作为扩展关系。扩展关系是把新的行为插入到已有的用例中方法。基础用例即使没有扩展用例的执行不会涉及扩展用例，只有在特定的条件发生，扩展用例才被执行。
泛化（继承）。
一个用例和其几种情形的用例间构成泛化关系。往往父用例表示为抽象用例。
任何父用例出现的地方子用例也可出现。
1 对用例的描述。
-
用例图：只能描述系统的大概功能，是一种视图。
-
用例描述：更详细地描述用例的功能。
2 用例描述的组成
用例名称，简要说明/描述，优先级，参与者，前置条件，基本事件流，其他事件流，扩展点，后置条件。
事件流：就是用例执行时，由一序列活动组成的控制流。
基本事件流：对用例中常规、预期路径的描述。
扩展事件流：主要是对一些异常情况、选择分支进行描述。
前置条件：在用例启动时参与者（actor）与系统应置于什么状态。
后置条件：用例结束时系统应置于什么状态。
以上述的"新增书籍信息"为例，说明如何细化用例描述。
-
用例的概要描述
用例名称：新增书籍（UCO1）
简要说明：录入新购书籍信息，并自动存储建档。
事件流：基本事件流和扩展事件流。
非功能需求
前置条件：用户进入图书管理系统。
后置条件：完成新书信息的存储建档。
扩展点：无
优先级：高（满意度 5 ，不满意度5 ）
-
详细描述
基本事件流
-
图书管理员向系统发出"新增书籍信息"请求。
-
系统要求图书管理员选择要增加的书籍是计算机类还是飞信计算接类
-
图书管理员做出选择后，显示相应界面，让图书管理员输入信息，并自动根据书号规则生成书号。
-
图书管理员输入书籍的相关信息，包括：书名、作者、出版社、ISBN号、开本。页数、定价。是否有CD-ROM。
-
系统确认输入的信息中书名没有重名。
-
系统将所输入的信息存档建档。
扩展事件流。
-
A 如果输入的书名有重名现象，则显示出重名的书籍，并要求图书管理员选择修改书名或取消输入。
-
A（1）图书管理员选择取消输入，则结束用例，不做存储建档工作。
-
A（2）图书管理员选择修改书名后，转到A。
如下例所示建立用例模型。
有一个业务需求如下，要求我们为其构件一个用例图。
1）系统可以供教师使用来为学生记录成绩。
2）系统根据需要创建报告卡。
-
系统允许用户浏览记录的成绩。
首先这里面要问到的是：11）中教师可以记录学生信息，这就是说教师可以录入、修改和删除学生信息了。22）中系统要创建报告卡，是谁来创建报告卡呢？这里就应该有权限的问题了，系统需要管理人员来来执行这项工作，另一个方面做系统的维护工作。报告卡创建后干什么？管理人员检查其准确性之后，由教师来分发报告卡。33） 系统允许用户浏览成绩，是谁可以浏览成绩呢？是学生和老师。
-
从中得到这个系统的参与者是：教师，学生，管理员。
主要用例：录入成绩。更新成绩。生成报告卡。报告卡准确性。分发报告卡。浏览成绩。
要区分用例的优先级。
首先是 ：记录成绩，浏览成绩，更新成绩，生成报告，检查报告卡的准确性，分发报告卡。
细化每一个用例。
对"记录成绩"进行细化，下面是对该用例的主事件流。
-
首先是教师要确定录入哪些学的成绩。
-
系统中要确保学生在数据库中。
-
教师说明记录哪像作业的成绩。
-
系统开始数据库的一些事物。
-
系统为学生把作业加入到数据库中。
-
教师输入学生作业的成绩。
-
系统核对输入的成绩是否符合正确的范围和格式。
-
系统记录作业的成绩。
-
系统结束事物的处理。
-
系统提示教师成绩已经记录好。
从细分的用例中发现新的用例，并根据优先级重新排列。
机房收费系统的用例图。
1、首先是分析系统中的角色（Actor）。
谁向系统提供信息？-----学生
谁从系统获取信息？----学生、管理员、操作员、一般用户
谁操作这个系统呢？--一般用户、操作员、管理员。
谁维护这个系统呢？---管理员。
系统要使用的外部资源？---数据库。
系统是否和已经存在的系统交互？---好像没有。
从中找出这个系统的Actor---（学生、一般用户、管理员、数据库）
-
基本Use case。
找出的参与者希望系统执行什么任务？
学生---去注册卡号，后充值，上机，下机，付钱，查看信息（查看自己的个人信息，上机信息，卡内的余额信息），不想用了就注销卡号。（学生的需求是要通过系统用户对系统的操作来完成的。所以学生和系统用户这两个角色之间是关联关系。）
一般用户—主要是用这个系统来管理学生上下机。可以登录到系统中去，后学生刷卡上机，显示上机的学生的记录，显示登录时间，查看学生上机状态，学生下机，显示下机时间和消费金额，可以修改自己的密码，查询余额。
操作员---主要是用这个系统为学生进行注册充值以及查询一些信息。登录到系统中去，可修改密码，根据学生的要求使用系统来，注册，充值，退卡，注册后充值可以查看收取金额，学生基本信息维护，学生上机统计信息，最后退卡时，查看金额退还信息来退还相应的钱数。最后可以查看老师和自己的工作记录。
管理员---登录到系统中去，可以修改密码以确保安全性。利用这个系统可以对学生的上下机情况查看。可以对一般用户和操作员的工作记录查看。
参与者在系统中访问哪些信息（创建、存储、修改、删除等）？
参与者在系统中需要访问
需要将外界哪些信息供给系统？
外界提供给本系统的信息是---学生信息、系统时间信息、系统用户信息。
需要将系统的哪个事件告诉参与者？
……无……
如何维护系统？
管理员负责对系统的维护-----基本数据的设定。
用例图如下所示：
学生和一般用户的用例图。
学生和操作员的用例图。
学生和管理员用例图所示：
下面是类图的实例（好像大话设计中有）：
UML中类图实例
接口：空心圆+直线（唐老鸭类实现了‘讲人话’）；
依赖：虚线+箭头（动物和空气的关系）；
关联：实线+箭头（企鹅需要知道气候才迁移）；
聚合：空心四边形+实线+箭头（雁群和大雁的关系）；
合成/组合：实心四边形+实线+箭头（鸟和翅膀的关系）；
泛化/继承：空心三角形+实线（动物和鸟的继承关系）；
实现：空心三角形+虚线（实现大雁飞翔的接口）；
UML类图
解释UML类图：
1. 首先看“动物”矩形框，它代表一个类。该类图分为三层，第一层显示类的名称，如果是抽象类就要用斜体显示。第二层是类的特性，通常就是字段和属性。第三层是类的操作，通常是方法和行为。
注意前面的符号，‘+’表示public, ‘—’ 表示private, ‘#’表示protected.
2. “飞翔”矩形框表示一个接口图，它与类图的区别主要是顶端有《interface》显示，第一行是接口名称，第二行是接口方法。接口还有另一种表示方法，俗称棒棒糖表示法，就是唐老鸭类实现了“讲人话”的接口。
interfaceIFly interfaceIlanguage
{ {
voidFly(); void Speak();
} }
3. 动物，鸟，鸭，唐老鸭他们之间都是继承的关系，继承关系用空心三角形+实现来表示。
4.“大雁”实现了“飞翔”接口。实现接口用空心三角形+虚线来表示。（注：下面的图中应为空心三角形）
classBird:Animal class WideGoose:IFly
{ {
//继承动物类 //实现飞翔接口
} }
5. 企鹅与气候有很大的关系，企鹅需要“知道”气候的变化，需要“了解”气候规律。当一个类“知道”另一个类时，可以用关联(association)关系。关联关系用实线箭头来表示。
class Penguin :Bird
{
private Climateclimate;//在企鹅Penguin中，引用到气候Climate对象
}
6. “大雁”和“雁群”这两个类。大雁是群居动物，每只大雁都属于一个雁群，一个雁群可以有多只大雁。所以它们之间就满足聚合(Aggregation)关系。聚合表示一种弱的“拥有”关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分。聚合关系用空心的菱形+ 实线箭头表示。
classWideGooseAggregate
{
private WideGoose[]arrayWideGoose;
//在雁群WideGooseAggregate类中，有大雁数组对象arrayWideGoose
}
7. “鸟”和“翅膀”这两个类。鸟和翅膀似整体和部分的关系，并且翅膀和鸟的生命周期是相同的，在这里鸟和其翅膀就是合成关系。合成(composition)是一种强的“拥有”关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。合成关系用实心的的菱形+实线箭头来表示。另外，合成关系的连线两端还有一个数字“1”和数字“2”，，这被称为基数。表明这一端的类可以有几个实例，很显然，一个鸟应该有两支翅膀。如果一个类可能有无数个实例，则就用“n”来表示。关联关系，聚合关系也可以有基数的。
class Bird
{
private Wing wing;
public Bird()
{
wing=new Wing();
//在鸟Bird类中，初始化时，实例化翅膀Wing,它们之间同时生成
}
}
8. “动物”、“氧气”与“水”之间。动物有几大特征，比如有新陈代谢，能繁殖。而动物要有生命，需要氧气，水以及食物等。也就是说动物依赖于氧气和水。它们之间是依赖关系(Dependency),用虚线箭头来表示。
abstract class Animal
{
public bolism(Oxygenoxygen,Water water)
{
}
}
253
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
