第3章 静态建模: 用例和用例图

第3章 静态建模: 用例和用例图
    用例模型(用例视图):是把应满足用户需求的基本功能(集)聚合起来表示的强大工具.
   a>对于正在构造的新系统,用例描述系统应该作什么,对于己完毕的,则反映了系统能够完成的功能.
   b>构建用例模型是通过开发者与客户(最终使用者)共同协商完成的,
   c>用例模型由用例,角色和系统组成
     用例:描述系统的功能,一个完整的系统通常包含若干个用例,每个用例具体说明完成的功能.
     角色:是与系统交互的外部实体
   d>系统运转的大致过程:外部角色先初始化用例,然后用例执行其所代表的功能,执行完后用例便给角色
     返回一些值,
   e>用例模型主要应用在工程开发的初期,进行系统需求分析时用
   f>用例模型由一个或若干个用例图构成,用例图中显示角色,用例和用例之间的关系.
   g>每个用例的真正实现细节以文本的方式书写.
3.1 用例图
    图示用例图时,既要画出三种模型元素,同时还要画出元素之间的各种关系(关联,依赖,通用化)如图:

3.2 系统
    3.2.1一般是先识别出系统的基本功能(集),然后以此为基础定义一个稳定的,精确定义的系统架构,
         以后不断地扩充系统功能,逐步完善.
    3.2.2在建模初期,定义一些术语和定义是很有必要的,
3.3 角色
    3.3.1角色是一个群体概念,代表是一类能使用某个功能的人和事,角色不是指某个个体.
         具体的个体对象不能称为角色
    3.3.2发现角色,通过回答问题可以发现角色
         a>使用系统主要功能的人是谁(即主要角色)
         b>需要借助于系统完成日常工作的人是谁
         c>谁来维护,管理系统(次要角色),保证系统正常工作
         d>系统控制的硬件设备有哪些?
         e>系统需要与哪些其它系统交互
         f>对系统产生的结果感兴趣的人或事是哪些?
    3.3.3UML中的角色是具有版类<角色>的类,如图:

    3.3.4角色之间的关系,
         角色也是类,在用例图中,只用通用化关系描述若干个角色之间的行为,
         通用化关系是:把某些角色的共同行为,抽取出来表示成通用行为,且把它们描述成超类,如图:

 
3.4 用例
    3.4.1用例代表的是一个完整的功能,是动作步骤的集合,
         用例表示的也是一个类,而不是某个具体的实例,描述了它代表的功能的各个方面
         用例的实例(也是一种动作)代表系统的一种实际使用方法,这个实例通常又叫做脚本
         脚本是系统的一次具体的执行路线
    3.4.2发现用例,询问以下问题
         a>角色需要从系统中获得哪种功能?角色需要做什么?
         b>角色需要读取,产生,删除,修改或存储系统中的某种信息吗?
         c>系统中发生的事件需要通知角色吗?或者角色需要通知系统某件事吗?
           这些事件(功能)能干些什么?
         d>如果用系统的新功能处理角色的日常工作是简单化了,还是提高了工作效率?
         e>系统需要的输入/输出是什么信息,这些信息从哪来到哪去?
         f>系统当前的这种实现方法要解决的问题是什么?
    3.4.3用例之间的关系:扩展,使用,组合三种关系.
         扩展,使用是继承关系的另一种体现
         组合则是把相关的用例打成包,当作一个整体看待.
    3.4.4实现用例:即在系统内部实现用例中描述的动作,
         通过把用例描述的动作转化为对象之间的互相协作,完成用例的实现.
         a>用例实现协作,协作是实现用例内部依赖关系的解决方案.
         b>协作由若干个图表示:协作图,序列图和活动图
         c>协作的实例是脚本
         d>实现用例的主要任务是把用例描述中的各个步骤和动作变换为协作中的类,
           类的操作和类的关系,具体来说,就是把用例中的每个步骤所完成的工作交给协作中的类完成.
         e>用例和它的实现(即协作)之间的关系可以用精化关系表示(图示为带箭头的点画线),如图: 

 

小结: