<三>面向对象分析之UML核心元素之参与者

一:版型
        --->在UML里有一个概念叫版型.有些书里也称类型,构造型。
        --->这个概念是对一个UML元素基础定义的扩展。在同一个元素基础定义的基础上赋予特别的含义,使得这个元素适用于特定的场合。
        --->例如(1)用例:的版型有:“业务用例”,“业务用例实现”
                      (2)类:的版型有:“接口”,“边界类”,“实体类”,“控制类”
        --->除了UML已经定义的版型外,为了在某种场合下让元素表达某种特定的含义,版型也是可以自己定义的。也就是说在项目里,可以有自己项目的版型定义。例如:包元素有“子系统”,“组织结构”,“模块”等默认的版型。
        --->版型只是UML的一种扩展手段,本身并不涉及太多的思想和方法,而是在建模的不同阶段,为了区分视图之间的不同观点,会采用不同的图示来表示。

二:参与者

【1】以人为本是当代流行的词汇。UML建模也是以人为本的。建模是从寻找抽象角度开始的。那么定义人,准确地说是定义参与者,就是我们寻找抽象角度的开始。
       【2】基本概念
                ---->参与者在建模过程中是处于核心地位的。
                ---->UML官方文档对参与者的定义为:actor是在系统之外与系统交互的某人或某事务。

        
                ---->图3.1中的系统被一个边界包裹着。系统之外的定义说明参与者和系统之间有一个明确的边界,参与者只可能存在于边界之外,边界之内的所有人和事物都不是参与者。边界在UML图中有时会显示地绘制出来,有时则不绘制出来。但是无论是显示的还是隐式的,一谈到参与者,读者必须想到系统边界的存在,否则参与者就是可疑的。
                ---->如何找出参与者,第一步是弄明白系统边界。
                ---->如何搞明白系统边界,弄明白两个问题(1)谁对系统有着明确的目标和要求并且主动发出动作?(2)系统为谁服务的?
                ---->参与者也叫主角,只有主动启动了某个业务的,才是参与者。

例子:小王到银行开户,想大厅经理询问了办理手续,填写表单,交给柜台职员,拿到了银行存折。这个场景中,谁是参与者?
        (1)小王是参与者
        (2)大厅经理,柜台职员。虽然参与了该开户行为,但不属于主动发起者,称之为“业务工人”,而不是参与者。

【3】参与者可以非人
                        --->建模着也常常会面临另一个问题,有些需求并没有人参与,参与者如何确定?例如这样一个需求:每天自动统计网页访问量,生成统计报表,并发送至管理员邮箱。这个需求参与者是谁?
                                (1)物理学有一个熟知的概念,在没有外力的情况下,物体保持静止或匀速直线运动状态。这个概念也适用计算机系统。在没有“外力”的情况下,计算机保持等待或循环任务状态。因此必须有“东西”发出指令或动作,计算机才会做出相应的反应。
                        --->参与者一定是直接并且主动地向系统发出动作并获得反馈的。否则就不是参与者。
                        ---->参与者和系统边界是共存的,相对的。随着系统边界的扩大或缩小,与之对应的参与者也在变动。
                        --->(1)业务主角:一个功能性需求的主动发起者。
                        --->(2)业务工人(不属于参与者):有些人员参与了业务,但属于被动参与业务。
                        --->(3)如何区分参与者和业务工人?可以通过三个问题来澄清他们的身份1他是主动向系统发出动作的吗?2他有完整的业务目标吗?3系统是为它服务的吗?

【4】参与者与与之相关方面的关系
                        ---->参与者与涉众的关系.
                                        (1)涉众(stakeholder),也称之为干系人。涉众是与要建设的这个系统有利益相关的一切人和事。
                        ---->参与者与用户的关系。
                                        (1)用户(user),是指系统的使用者,通俗点说是系统操作员。
                        ---->参与者与角色的关系
                                        (1)角色(role),是参与者的职责。是一类参与者的抽象。

时间: 2024-08-03 19:41:15

<三>面向对象分析之UML核心元素之参与者的相关文章

&lt;八&gt;面向对象分析之UML核心元素之分析类

一:基本概念        ---->在那大数项目中,分析类是被忽视的一种非常有用的元素.        ---->分析类用于获取系统中主要的“职责簇”,他们代表系统的原型类,是系统必须处理的主要抽象概念的“第一个关口”.如果期望获得系统的“高级”概念性简述,则可对分析类本身进行维护,分析类还可产生系统设计的主要抽象——系统的设计类和子系统.二:分析类的性质        ----->分析类代表系中主要的“职责簇”,这以为着分析类是从功能性需求向计算机实现转化过程中的“第一个关口”   

&lt;十&gt;面向对象分析之UML核心元素之关系

关系        --->在UML中关系是非常重要的语义,它抽象出对象之间的联系,让对象构成特定的结构.        一,关联关系(association) --->关联关系是用一条直线表示的.        --->描述不同类的对象之间的结构关系.它在一段时间内将多个类的实例链接在一起,这与依赖关系是不同的.依赖关系通常表示两个实例之间的临时关联关系.        --->单行关联关系,A知道B的存在,B不知道A的存在.比如UML建模中,参与者知道用例的存在,用例不知道参与

&lt;九&gt;面向对象分析之UML核心元素之设计类,类,属性,方法,可见性

设计类 --->设计类是系统实施中一个或多个对象的抽象.        --->设计类已经直接映射到实现代码了,因此设计类依赖于实施语言.另一方面,设计类来源于前期的系统分析,在统一过程中,类不是品空想像出来的.他们可以一一映射到前期系统分析的成果上.从这个观点出发,分析类的重要性就能够体现出来.分析类为设计类中多需要的界面,逻辑和数据提供了非常好的抽象基础,设计类可以非常容易和自然地从分析类中演化出来. 类        --->类对对象进行定义,而对象又实现(或成为实施)用例.类的来

&lt;六&gt;面向对象分析之UML核心元素之业务实体

一:基本概念          ---->业务实体类(class)的一种版型.特别用于在业务建模阶段建立领域模型.业务实体是业务模型中非常重要的一个因素,它为问题领域中的关键概念建立概念化的理解.是人们认识问题领域的重要手段.如果说参与者和用例描述了我们在这个问题领域中达到的什么样的目标,那么业务实体就描述了我们使用什么来达到业务目标以及通过什么记录这个业务目标.        ---->官方定义:业务实体代表业务角色执行业务用例处理或使用的“事物”.        ---->一个业务实

&lt;十一&gt;面向对象分析之UML核心元素之组件

组件一:概念        --->组件是系统中实际存在的可更换部分,它实现特定的功能,符合一套接口标准并实现一组接口.        --->组件代表系统中的一部分物理实施.包括软件代码(源代码,二进制代码或可执行代码)或其等价物(如脚本或命令文件)        --->在UML的定义中,组件之间唯一的关系就是依赖.在Rose中,组件视图中允许的唯一链接也是依赖关系,而依赖意味着一个组件的修改会导致依赖于它的其他组件的修改.        --->在笔者看来,一个组件应当是一个

【笔记】UML核心元素

1.参与者 定义:在系统之外与系统交互的某人或某物. 特点:1.可以非人:2.与系统直接交互:3.主动发出动作并获得反馈:4.涉众(stakerholder)的代表 具有两个版型: 1.业务主角(business actor): 在需求阶段中用于业务建模 特点:针对业务人员而非计算机用户 2.业务工人(business worker) 特点:在业务过程中,扮演某一环节不可或缺的部分,但是该业务并非其主动提出,并获得最后的反馈: 2.用例 定义:定义了一组用例实例,其中每个实例都是系统所执行的一些

Thinking in UML 学习笔记(三)——UML核心视图之类图

类图的作用:用于展示系统中的类及其相互之间的关系. UML在解决面向对象的方法中对类理解为三个层次,分别是:概念层.说明层.实现层.在UML中,从开始的需求到最终设计类,类图也是围绕这三个层次的观点进行建模的. 一.概念层类图 在概念层上类图着重于对问题领域的概念化理解,而不是实现,因此类名称通常都是问题领域中实际事物的名称. 网上购物主要由商品.订单.支付卡这几个关键类构成,这几个类的交互能够完成网上购物这个业务目标. 二.说明层类图 这一层是类的接口而不是实现,类图中表达类和类之间的交互接口

UML面向对象分析与设计试题2008-B卷

UML面向对象分析与设计试题2008-B卷 UML图中类之间的关系:依赖,泛化,关联,聚合,组合,实现 提交APPStore流程http://www.360doc.com/content/15/0203/15/19663521_445974056.shtml

面向对象分析与设计—OOD部分

第三部分 面向对象设计 3.1 面向对象设计(OOD)的定义? 在面向对象分析阶段,已经针对用户需求建立起用面向对象概念描述的系统分析模型.在设计阶段,要考虑为实现系统而采用的计算机设备.操作系统.网络.数据库管理系统以及所采用的编程语言等有关因素,进一步运用面向对象的方法对系统进行设计,最后形成一个可以实现的设计模型,即面向对象设计模型. 3.2 面向对象设计(OOD)与面向对象分析(OOA)的关系? 在面向对象分析阶段,针对的是现实世界,把需求转化为面向对象概念所建立的模型,以易于理解问题域