UML用例图

http://hi.baidu.com/xiechengfa/blog/item/253acf0b64d90f286b60fb8b.html

前些时间参加了潘加宇老师的技术讲座,UML建模技术受益匪浅。我也把平时的一些积累和上次的收获总结在这篇文章中,主要讲解用例图相关的知识。
      
用 例图是软件需求分析到最终实现的第一步,它描述用户如何使用系统及使用系统什么样的功能。用例图从业务角度上体现谁来使用系统、用户希望系统提供什么样的 服务,以及用户需要为系统提供的服务,也便于软件开发人员最终实现这些功能。用例图在开发中被广泛的应用,但是它最常用来描述系统提供了什么样的功能给什 么样的用户使用。

       在官方文档中用例图包含六个元素,分别是:执行者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。但是有些UML的绘图工具多提供了一种直接关联关系(DirectedAssociation)。

        用例图可一个包含注释和约束,还可一个包含包,用于将模型中的元素组合成更大的模块。有时,可以将用例的实例引入到图中。用例图模型如下所示,执行者用人形图标来标识,用例用椭圆来表示,连线表示它们之间的关系。


一、执行者(Actor)

       1、执行者概念

     是指用户在系统中扮演的角色。如图1-1是一个用户管理的用例图,图中的用户、管理员就是用例的执行者。


                     图1-1

          2、从业务中找出执行者

    获取系统用例首先要找出系统的执行者。我们可以通过用户回答一些问题的答案来识别执行者。可以参考以下问题:

  1. 谁使用系统的主要功能(主要使用者)?
  2. 谁需要系统支持他们日常工作?
  3. 谁来维护、管理系统使其正常工作(辅助使用者)?
  4. 系统需要控制哪些硬件?
  5. 系统需要其他哪些系统交互?这里包含其他计算机系统或者应用程序。
  6. 对系统产生结果感兴趣的是哪些人和哪些事物?

       3、执行者之间关系

因为执行者是类,所以多个执行者之间可以具有与类相同的关系。在 用例图中,使用了泛化关系来描述多个执行者之间的公共行为。如果系统中存在几个执行者,它们既扮演自身的角色,同时也扮演更具一般化的角色,那么就用泛化 关系来描述它们。这种情况往往发生在一般角色的行为在执行者超类中描述的场合。特殊化的执行者继承了该超类的行为,然后在某些方面扩展了此行为。执行者之 间的泛化关系用一个三角箭头来表示,指向扮演一般角色的超类。这与UML中类之间的返还关系符号相同。图1-2


                    图1-2

二、用例(Use Case)

         1、用例概念

     用例就是外部可见的系统功能,对系统提供的服务进行描述。

          2、从业务中找出用例

     找出系统的用例,我们从执行者入手,对每个执行者提出一些问题,然后从执行者对这些问题的答案中获取用例。可以参考以下问题:

  1. 执行者要求系统提供哪些功能(执行者需要做什么)?
  2. 执行者需要读、产生、修改、删除或者存储系统中的信息有哪些类型?
  3. 执行者必须提醒系统事件有哪些?把这些事件表示成系统用例。

         3、用例之间关系

二、用例之间关系

         1、关联关系(Association)

关联关系是连接执行者和用例,表示该执行者代表的外部系统实体与该用例描述的系统需求有关。


图1-3

         2、包含关系(Include)

包含关系是来自于用例的抽象,即从数个不同的Use Case中,分离出公共的部分,而成为可以复用的用例。


图1-4

        3、扩展关系(Extend)

    扩展关系表示某一个用例的对话流程中,可能会根据条件临时插入另外一个用例,而前者称为基础用例后者称为扩展用例。

    

                 图1-5

4、泛化关系(Generalization)

    一个用例可以被特别列举为一个或多个用例,这被称为用例泛化,如果系统中一个或多个用例是某个一般用例的特殊化时,就需要使用用例的泛化关系。

    

                 图1-6

Tags: UML用例建模 建模 No Comments

UML中几种类间关系:继承、实现、依赖、关联、聚合、组合的联系与区别

2009-03-01

本文已同步发于:http://blog.csdn.net/sfdev/archive/2009/02/18/3906243.aspx

这是一堂关于UML基础知识的补习课;现在我们做项目时间都太紧了,基本上都没有做过真正的class级别的详细设计,更别提使用UML来实现规范 建模了;本篇主要就以前自己一直感觉很迷糊的几种class之间的关系进行整理,让我们在真正用UML进行比如类图设计时能够更加清晰明了;以下就分别介 绍这几种关系:

继承

指的是一个类(称为子类、子接口)继承另外的一个类(称为父类、父接口)的功能,并可以增加它自己的新功能的能力,继承是类与类或者接口与接口之间最常见的关系;在Java中此类关系通过关键字extends明确标识,在设计时一般没有争议性;

实现

指的是一个class类实现interface接口(可以是多个)的功能;实现是类与接口之间最常见的关系;在Java中此类关系通过关键字implements明确标识,在设计时一般没有争议性;

依赖

可以简单的理解,就是一个类A使用到了另一个类B,而这种使用关系是具有偶然性的、、临时性的、非常弱的,但是B类的变化会影响到A;比如某人要过河,需要借用一条船,此时人与船之间的关系就是依赖;表现在代码层面,为类B作为参数被类A在某个method方法中使用;

关联

他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系,比如我和我的朋友;这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性 的,一般是长期性的,而且双方的关系一般是平等的、关联可以是单向、双向的;表现在代码层面,为被关联类B以类属性的形式出现在关联类A中,也可能是关联 类A引用了一个类型为被关联类B的全局变量;

聚合

聚合是关联关系的一种特例,他体现的是整体与部分、拥有的关系,即has-a的关系,此时整体与部分之间是可分离的,他们可以具有各自的生命周期, 部分可以属于多个整体对象,也可以为多个整体对象共享;比如计算机与CPU、公司与员工的关系等;表现在代码层面,和关联关系是一致的,只能从语义级别来 区分;

组合

组合也是关联关系的一种特例,他体现的是一种contains-a的关系,这种关系比聚合更强,也称为强聚合;他同样体现整体与部分间的关系,但此 时整体与部分是不可分的,整体的生命周期结束也就意味着部分的生命周期结束;比如你和你的大脑;表现在代码层面,和关联关系是一致的,只能从语义级别来区 分;

对于继承、实现这两种关系没多少疑问,他们体现的是一种类与类、或者类与接口间的纵向关系;其他的四者关系则体现的是类与类、或者类与接口间的引 用、横向关系,是比较难区分的,有很多事物间的关系要想准备定位是很难的,前面也提到,这几种关系都是语义级别的,所以从代码层面并不能完全区分各种关 系;但总的来说,后几种关系所表现的强弱程度依次为:组合>聚合>关联>依赖;

Tags: UML依赖关联组合继承聚合 软件工程 2 Comments

踩个UML的脚印

2009-01-05

目的
对前段时间学习 UML过程的一个记录

起因

为了理清mall的一些业务逻辑,以便今后的顺利开发,需一种工具来帮助自己更好更快的熟悉这些业务,这种工具很多,如各类思维导图软件,UML, 我就选了UML。因为之前也没怎么画,知识也很缺乏,就开始边学边画啦 :D

经过

在边学边画前,要找一款好点的画UML软件,经同事TJJ的推荐,用上了一款韩国人开发的startUML,用来
画了几个图后发现不是特别好用,sigh~ 通过伟大的google,用上了 ArgoUML界面虽难看了点,但确实好用,在这里也推荐下,哈哈。

在学UML过程中,接触到了几个概念,记录下:

关联: 模型元素之间的一种语义联系,是类之间的一种很弱的联系, 如:当仅当一个类为另一个 类方法中的参数时为关联关系

组合:表示类之间整体和部分的关系,但是组合关系中部分和整体具有统一的生存期。一旦整体
对象不存在,部分对象也将不存在。部分对象与整体对象之间具有共生死的关系。

聚合: 也指的是整体与部分的关系。需求描述中“包含”、“组成”等词常意味着聚合关系。

亲密关系从大到小为 组合>聚合>关联


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值