精华内容
下载资源
问答
  • 如何书写UserCase

    千次阅读 2017-10-28 18:09:47
    什么是Use Case 用例描述文档的书写是系统分析人员对用户需求的深刻理解的体现。是后期时序图和实际开发的重要依据。也可以对作为项目估算的依据,以及根据UC复杂度和开发周期来衡量开发人员的工作效率。因此UC的...

    •  

      什么是Use Case

      用例描述文档的书写是系统分析人员对用户需求的深刻理解的体现。是后期时序图和实际开发的重要依据。也可以对作为项目估算的依据,以及根据UC复杂度和开发周期来衡量开发人员的工作效率。因此UC的书写规范及其重要,就工作用的一些经验,比如书写格式、书写内容及其注意事项与大家分享。

      大纲图:

      clip_image001

      一、前期准备

          1).对用户的问题要有非常深刻完善的理解

          2). 确保能够解决用户的所有问题

          3).把用户的需求真正地反应到商业模型

          4).对以后的设计和开发过程提供说明和框架

          5).根据需求生成UI界面

      二、Use Case内容

      首先有用例名称:一般是模块名称或者模块中功能点的名称。

      clip_image002

      其次文档变更记录(Revision History),具体内容如下:

      clip_image003

      1、基本描述(Brief Description)

      描述用例在系统中的作用。比如此用例的使用者是谁、使用者所要做的操作。

      2、前置条件(Precodition)

      描述该用例执行前所要满足的条件。比如用例B执行前,必须先执行A,则用例的前置条件是执行A。

      3、事后保证(PostCodition)

      此用例执行完毕后的条件

      4、主要流程(Basic Flows)

      用户操作该用例的基本流程,是后期时序图的主要参考

      5、选择性流程(Alternative Flows)

      在操作主要流程过程中,出现的一些分支流程,是后期时序图的主要参考

      6、特别需求(Special Requirement)

      对一些细微功能点进行描述,比如用户身份验证规则、订单号码产生规则、是否需要SSL加密等等

      7、使用界面(User Interface)

      美工根据需求制作的UI,及其对UI中栏位进行的说明。

      8、附加资讯(Addition Information)

      一些商务逻辑的描述,可以把系统逻辑试图(Logic View)放到这里

      三、总结

      在阅读UC的过程中主要遇到以下问题“基本流程和选择性流程描述的不够清楚或者不够详细”的问题,主要是因为系统分析人员对需求理解的不够透彻,分析的不够彻底。

      源文档 <http://www.blueidea.com/tech/program/2010/7695.asp>

    • 一、概述

      用例试图描概括了用例中角色和系统之间的关系,描述了系统功能需求,角色和系统的交互以及系统的反应。

      clip_image004

      会员具有浏览商品类别、根据关键字产讯商品和选择商品加入购物车的功能。

      二、术语解释

      1、Extends 用例扩展关系

      扩展关系一般用来描述一个元素延伸为另外一种行为。Use Case中的扩展表示一个UC有可能扩展到另外一个UC的功能。Use Case中的扩展通常暗示一个选择性流程。

      clip_image005

      2、Include 用例包含关系

      包行关系表示源元素包行目标元素的行为,UC中的包含关系就是一个UC中包行另外一个UC的行为功能。用包行关系可以防止在多个UC中同时定义共同的功能模块,有些像委托delegation

      clip_image006

      3、角色(Actor)

      系统中的用户根据系统分为多个角色,每个角色都会与系统有交互。一个用户可以具有一个或者多个角色。

      系统中用到的角色如果细分,可以分为主要角色和辅助角色

      比如:在电子商务网站中主要角色有供应商、前台会员、系统管理员等等;辅助角色有Email Sender、物流系统、金流系统等等。

      三、如何画Use Case 用例视图

      Note: 设计工具是EA(Enterprise Architect 7.0)

      假设目前的功能需求是:

      A、供应商需要填写Form表单提报商品

      B、供应商通过导入CSV文档提报商品

      C、商品开发人员需要对供应商提报的是商品进行审核

      1、新建工程

      【File】->【New Project】->填写工程名称:Example.eap

      2、新建Use Case View 用例视图

      右击上面新建的Project->选择【New View】->弹出对话框,选择【Use Cse】如下图

      clip_image007

      单击【OK】,在Model工程下,这样就新建了一个Package。

      右击Package【商品提报上架】->选择【Add】->选择【Add Diagram】,如下图所示

      clip_image008

      弹出如下对话框:选择【UML Behavioral】->Use Case,单击【OK】

      clip_image009

      这样,一个空的Use Case新建完成。接下来我们需要向空的Use Case添加内容。

      3、根据业务需求画Use Case视图

      clip_image010

      Note:从左侧的ToolBox工具栏中 选择一些Use Case的元素,直接拖曳左边的Element,到右边的工作区,就可以把Element放到咱们的Use Case试图中。

      A、拖曳两个Actor 元素到工作区,分别命名为“供应商”“商品开发人员”

      B、拖曳三个Use Case元素到工作区,分别命名为“商品提报”“CSV档导入商品” “商品审核”

      如下图所示:

      clip_image011

      C、通过关联关系 链接角色与系统功能,如下图:

      clip_image012

      至此,商品提报场景的Use Case图已经画完。一个Use Case视图会对应一个或者多个Use Case用例。

      关于什么是Use Case 请参照《需求阶段如何书写Use Case》

      四、Use Case 在实际项目中的组织结构

      clip_image013

      这是一个使用UC描述的系统需求功能目录图,每一个UC描述了Actor使用使系统时,与系统的交互行为。

      五、总结

      用例试图描概括了用例中角色和系统之间的关系,描述了系统功能需求,角色和系统的交互以及系统的反应。是客户和开发人员全貌理解项目需求功能比较好的一个方式,也是后续功能迭代的依据和方向。

      源文档 <http://www.blueidea.com/tech/program/2010/7695_2.asp>

    • 一、简介

      类是对象的集合,展示了对象的结构以及与系统的交互行为。类主要有属性(Attribute)和方法(Method)构成,属性代表对象的状态,如果属性被保存到数据库,此称之为“持久化”;方法代表对象的操作行为,类具有继承关系,可以继承于父类,也可以与其他的Class进行交互。

      类图展示了系统的逻辑结构,类和接口的关系。

      二、类的构成

      类主要有属性和方法构成。比如商品属性有:名称、价格、高度、宽度等;商品的方法有:计算税率,获得商品的评价等等。如下图

      clip_image014

      三、类之间的关系(Relationship)

      关联(Association)

      两个相对独立的对象,当一个对象的实例与另外一个对象的特定实例存在固定关系时,这两个对象之间就存在关联关系。

      1、单向关联

      A1->A2: 表示A1认识A2,A1知道A2的存在,A1可以调用A2中的方法和属性

      场景:订单和商品,订单中包括商品,但是商品并不了解订单的存在。

      类与类之间的单向关联图:

      clip_image015

      C#代码:

      Public class Order

      {

             Public List<Product> order;

      Public void AddOrder(Product product )

             {

                    order.Add(product);

      }

      }

      Public Class Product

      {

      }

      代码表现为:Order(A1)中有Product(A2)的变量或者引用

      2、双向关联

      B1-B2: 表示B1认识B2,B1知道B2的存在,B1可以调用B2中的方法和属性;同样B2也知道B1的存在,B2也可以调用B1的方法和属性。

      场景:订单和客户,订单属于客户,客户拥有一些特定的订单

      类与类之间的双向关联图

      clip_image016

      C#代码

      Public class User

      {

             Public List<Order> GetOrder()

             {

      }      return new List<Order>();

      }

      Public Class Order

      {

             Public User GetUserByOrderID(string OrderId )

             {

                    Return new User();

      }

      }

      3、自身关联

      同一个类对象之间的关联

      类与类之间自身关联图

      clip_image017

      4、多维关联(N-ary Association)

      多个对象之间存在关联

      场景:公司雇用员工,同时公司需要支付工资给员工

      类与类之间的多维关联图:

      clip_image018

      5、泛化(Generalization)

      类与类的继承关系,类与接口的实现关系。

      场景:父与子、动物与人、植物与树、系统使用者与B2C会员和B2E会员的关系

      类与类之间的泛化图:

      clip_image019

      系统的使用者包括:B2C会员、B2B会员和B2E会员。

      接口的实现,动物都有吃的行为,而人是动物的一个具体实例,实现具体Eat的动作

      clip_image020

      6、依赖(Dependency)

      类A要完成某个功能必须引用类B,则A与B存在依赖关系,依赖关系是弱的关联关系。C#不建议双相依赖,也就是相互引用。

      场景:本来人与电脑没有关系的,但由于偶然的机会,人需要用电脑写程序,这时候人就依赖于电脑。

      类与类的依赖关系图

      clip_image021

      在程序中一般为 using 引用。

      7、聚合(Aggregation)

      当对象A被加入到对象B中,成为对象B的组成部分时,对象B和对象A之间为聚合关系。聚合是关联关系的一种,是较强的关联关系,强调的是整体与部分之间的关系。

      场景:商品和他的规格、样式就是聚合关系。

      类与类的聚合关系图

      clip_image022

      8、组合(Composite)

      对象A包含对象B,对象B离开对象A没有实际意义。是一种更强的关联关系。人包含手,手离开人的躯体就失去了它应有的作用。

      场景: Window窗体由滑动条slider、头部Header 和工作区Panel组合而成。

      类与类的组合关系图

      clip_image023

      四、总结

      本文针对类之间常用的关系进行了简单的描述,主要有:关联关系、泛化、依赖、聚合和组合。

      源文档 <http://www.blueidea.com/tech/program/2010/7695_3.asp>

    • 活动图是UML用于对系统的动态行为建模的另一种常用工具,它描述活动的顺序,展现从一个活动到另一个活动的控制流。活动图在本质上是一种流程图。活动图着重表现从一个活动到另一个活动的控制流,是内部处理驱动的流程。

      一、活动图的组成元素 Activity Diagram Element

      1、活动状态图(Activity)

      活动状态用于表达状态机中的非原子的运行,其特点如下:

      (1)、活动状态可以分解成其他子活动或者动作状态。

      (2)、活动状态的内部活动可以用另一个活动图来表示。

      (3)、和动作状态不同,活动状态可以有入口动作和出口动作,也可以有内部转移。

      (4)、动作状态是活动状态的一个特例,如果某个活动状态只包括一个动作,那么它就是一个动作状态。

      UML中活动状态和动作状态的图标相同,但是活动状态可以在图标中给出入口动作和出口动作等信息。

      clip_image024

      2、动作状态(Actions)

      动作状态是指原子的,不可中断的动作,并在此动作完成后通过完成转换转向另一个状态。动作状态有如下特点:

      (1)、动作状态是原子的,它是构造活动图的最小单位。

      (2)、动作状态是不可中断的。

      (3)、动作状态是瞬时的行为。

      (4)、动作状态可以有入转换,入转换既可以是动作流,也可以是对象流。动作状态至少有一条出转换,这条转换以内部的完成为起点,与外部事件无关。

      (5)、动作状态与状态图中的状态不同,它不能有入口动作和出口动作,更不能有内部转移。

      (6)、在一张活动图中,动作状态允许多处出现。

      UML中的动作状态图用平滑的圆角矩形表示,如下:

      clip_image025

      3、动作状态约束(Action Constraints)

      动作状态约束:用来约束动作状态。如下图展示了动作状态的前置条件和后置条件

      clip_image026

      4、动作流(Control Flow)

      动作之间的转换称之为动作流,活动图的转换用带箭头的直线表示,箭头的方向指向转入的方向。

      clip_image027

      5、开始节点(Initial Node)

      开始节点:表示成实心黑色圆点

      clip_image028

      6、终止节点(Final Node)

      分为活动终止节点(activity final nodes)和流程终止节点(flow final nodes)。

      活动终止节点表示整个活动的结束

      clip_image029

      而流程终止节点表示是子流程的结束。

      clip_image030

      7、对象(Objects)

      clip_image031

      8、数据存储对象(DataStore)

      clip_image032

      使用关键字«datastore»

      9、对象流(Object Flows)

      对象流是动作状态或者活动状态与对象之间的依赖关系,表示动作使用对象或动作对对象的影响。用活动图描述某个对象时,可以把涉及到的对象放置在活动图中并用一个依赖将其连接到进行创建、修改和撤销的动作状态或者活动状态上,对象的这种使用方法就构成了对象流。

      对象流中的对象有以下特点:

      (1)、一个对象可以由多个动作操作。

      (2)、一个动作输出的对象可以作为另一个动作输入的对象。

      (3)、在活动图中,同一个对象可以多次出现,它的每一次出现表面该对象正处于对象生存期的不同时间点。

      对象流用带有箭头的虚线表示。如果箭头是从动作状态出发指向对象,则表示动作对对象施加了一定的影响。施加的影响包括创建、修改和撤销等。如果箭头从对象指向动作状态,则表示该动作使用对象流所指向的对象。

      状态图中的对象用矩形表示,矩形内是该对象的名称,名称下的方括号表明对象此时的状态。

      clip_image033

      10、分支与合并(Decision and Merge Nodes)

      分支与合并用菱形表示

      clip_image034

      11、分叉与汇合(Fork and Join Nodes)

      分为水平风向和垂直方向。

      clip_image035

      对象在运行时可能会存在两个或多个并发运行的控制流,为了对并发的控制流建模,UML中引入了分叉与汇合的概念。分叉用于将动作流分为两个或多个并发运行的分支,而汇合则用于同步这些并发分支,以达到共同完成一项事务的目的。

      12、异常处理(Exception Handler)

      当受保护的活动发生异常时,触发异常处理节点。

      clip_image036

      13、活动中断区域(Interruptible Activity Region)

      活动中断区域围绕一些可被中断的动作状态图。比如下图,正常情况下【Process Order】顺序流转到【Close Order】,订单处理流程完毕;但在【Process Order】过称中,会发送【Cancel Order】请求,这时会流转到【Cancel Order】,从而订单处理流程结束

      clip_image037

      14、泳道(Partition)

      泳道将活动图中的活动划分为若干组,并把每一组指定给负责这组活动的业务组织,即对象。在活动图中,泳道区分了负责活动的对象,它明确地表示了哪些活动是由哪些对象进行的。在包含泳道的活动图中,每个活动只能明确地属于一个泳道。

      泳道是用垂直实线绘出,垂直线分隔的区域就是泳道。在泳道的上方可以给出泳道的名字或对象的名字,该对象负责泳道内的全部活动。泳道没有顺序,不同泳道中的活动既可以顺序进行也可以并发进行,动作流和对象流允许穿越分隔线。

      clip_image038

      二、活动图案例分析

      clip_image039

      1、 泳道分为:会员泳道和系统泳道。会员选择商品并加入购物车,系统完成订单生成及其支付完毕。

      2、 开始节点:会员添加商品到购物车,点击【订单确认】,开始交于系统处理订单流程

      3、 结束节点:商品发送完毕和付款成功,订单处理流程结束

      4、 活动状态:产生订单、Check Credit Cart核对信用卡、Check Stock 核对库存量、Deliver Goods 发送商品、Process Credit Cart付款

      5、 分叉与汇合:【产生订单】份叉为检查库存量和会员支付金额是否足够,如果不足,取消订单,如过库存量和支付金额足够,发送商品和付款,最后汇合为订单完成。

      三、总结

      活动图描述的是对象活动的顺序关系所遵循的规则,它着重表现的是系统的行为,而非系统的处理过程。活动图能够表示并发活动的情形,活动图是面向对象的。

      源文档 <http://www.blueidea.com/tech/program/2010/7695_4.asp>

    • 一、状态图简介(Brief introduction)

      状态图(Statechart Diagram)主要用于描述一个对象在其生存期间的动态行为,表现为一个对象所经历的状态序列,引起状态转移的事件(Event),以及因状态转移而伴随的动作(Action)。一般可以用状态机对一个对象的生命周期建模,状态图用于显示状态机(State Machine Diagram),重点在与描述状态图的控制流。

      如下图例子,状态机描述了门对象的生存期间的状态序列,引起转移的事件,以及因状态转移而伴随的动作(Action)

      clip_image040

      .状态有Opened、Closed、Locked。

      事件有 Open、Close、Lock和Unlock。

      注意:

      1、并不是所有的事件都会引起状态的转移,比如当门是处于【Opened】状态,不能进行【Lock】事件。

      2、转移(Transition)有警备条件(guard condition),比如只有doorWay->isEmpty 条件满足时,才会响应事件。

      二、状态图元素(State Diagram Elements)

      1、状态(States)

      指在对象的生命周期中的某个条件或者状况,在此期间对象将满足某些条件、执行某些活动活活等待某些事件。所有对象都有状态,状态是对象执行了一系列活动的结果,当某个事件发生后,对象的状态将发生变化。

      状态用圆角矩形表示

      clip_image041

      初态和终态(Initial and Final States)

      初态用实心圆点表示,终态用圆形内嵌圆点表示。

      clip_image042

      2、转移(Transitions)

      转移(Transitions)是两个状态之间的一种关系,表示对象将在源状态(Source State)中执行一定的动作,并在某个特定事件发生而且某个特定的警界条件满足时进入目标状态(Target State)

      clip_image043

      事件标记(Trigger):是转移的诱因,可以是一个信号,事件、条件变化(a change in some condition)和时间表达式。

      警界条件(Guard Condition):当警界条件满足时,事件才会引发转移(Transition)。

      结果(Effect):对象状态转移后的结果。

      3、动作(State Actions)

      动作(Actions)是一个可执行的原子操作,也就是说动作是不可中断的,其执行时间是可忽略不计的。

      在上例中,对象状态转移后的结果显示在转移线上,如果目标状态有许多转移,而且每个转移有相同的结果,这时把转移后的结果(Effect)展示在目标状态中(Target State)更好一些,可以定义进入动作(Entry Action )和退出动作(Exit Action),如下图

      clip_image044

      4、自身转移(Self-Transitions)

      状态可以有返回自身状态的转移,称之为自身转移(Self-Transitions)

      clip_image045

      2S后,Poll input事件执行,转移到自己状态【Waiting】

      5、组合状态(Compound States)

      嵌套在另外一个状态中的状态称之为子状态(sub-state),一个含有子状态的状态被称作组合状态(Compound States). 如下图,【Check PIN】是组合状态,【Enter PIN】是子状态。

      clip_image046

      也可用以下方式进行描述

      clip_image047

      如上图,状态机【Check PIN】的细节被分割到另外一个图中了。

      6、进入节点(Entry Point)

      如下图所示,由于一些原因并不会执行初始化(initialization),而是直接通过一个节点进入状态【Ready】,则此节点称之为进入节点(Entry Point)

      clip_image048

      7、退出节点(Exit Point)

      clip_image049

      8、历史状态(History States)

      历史状态是一个伪状态(Pseudostate),其目的是记住从组合状态中退出时所处的子状态,当再次进入组合状态,可直接进入这个子状态,而不是再次从组合状态的初态开始。

      clip_image050

      在上图的状态图中,正常的状态顺序是:【Washing】- >【Rinsing】->【Spinning】。

      如果是从状态【Rinsing】突然停电(Power Cut)退出,,洗衣机停止工作进入状态【Power Off】,当电力恢复时直接进入状态【Running】。

      9、并发区域(Concurrent Regions)

      状态图可以分为区域,而区域又包括退出或者当前执行的子状态。说明组合状态在某一时刻可以同时达到多个子状态。如下图刹车系统,同时进入前刹车【Applying Front Brakes】状态和后刹车【Applying Rear Brakes】状态。

      clip_image051

      三、状态图案例分析(State Diagram Example Analysis)

      clip_image052

      按照blink518的建议(“出货中”是属于条件分支应该使用Decision),改成如下图也是很好的做法:

      clip_image053

      订单成立状态主要有:

      订单成立

      订单取消(Guard:会员订单-缴款期限已过期)

      备货中(Guard:已付款、订单成立、库存量足够)

      出货中(Effect:扣除商品可接单量及移除购物车中的购买资料)

      出货确认(Guard:实际配达日及发票代码、号码均不为空值)

      出货完毕(Guard:实际配达日不为空)

      出货失败

      订单成立(Guard:出货完毕,已付款、鉴赏期结束日期 小于等于 [系统日期])

      分析:

      1、购物车生成订单进入状态【订单成立】

      2、系统检测订单已经付款并且库存量足够,则进入状态【备货中】

      3、物流发货,进入状态【发货中】,状态转移为【发货中】后,需要做的操作有“扣除商品可接单量及移除购物车中的购买资料”

      4、发货完毕后,状态分为【出货确认】和状态【出货失败】,如果状态是【出货失败】,则【结束】,如果状态为【出货确认】,则进入下一步。

      5、配货人员填写实际配达日期,进入状态【出货完毕】。

      6、如果”已付款、鉴赏期结束日期 小于等于 [系统日期]”,则【订单成立】。

      四、总结(Summary)

      状态图重点在于描述对象的状态及其状态之间的转移,状态图的基本元素主要有:状态、转移、动作、自身转移、组合状态、进入节点、退出节点、历史状态、并发区域等,状态中的事件分为调用事件(Call)、变化事件(Change)、时间事件(Time)和信号事件(Singal)。最后以实例对状态对进行了分析。

      源文档 <http://www.blueidea.com/tech/program/2010/7695_5.asp>

      一、时序图简介(Brief introduction)

      时序图(Sequence Diagram)是显示对象之间交互的图,这些对象是按时间顺序排列的。顺序图中显示的是参与交互的对象及其对象之间消息交互的顺序。时序图中包括的建模元素主要有:对象(Actor)、生命线(Lifeline)、控制焦点(Focus of control)、消息(Message)等等。

      二、时序图元素(Sequence Diagram Elements)

      角色(Actor)

      系统角色,可以是人、及其甚至其他的系统或者子系统。

      对象(Object)

      对象包括三种命名方式:

      第一种方式包括对象名和类名;

      第二中方式只显示类名不显示对象名,即表示他是一个匿名对象;

      第三种方式只显示对象名不显示类明。

      clip_image054

      生命线(Lifeline)

      生命线在顺序图中表示为从对象图标向下延伸的一条虚线,表示对象存在的时间

      如下图

      clip_image055

      控制焦点(Focus of Control)

      控制焦点是顺序图中表示时间段的符号,在这个时间段内对象将执行相应的操作。用小矩形表示,如下图。

      clip_image056

      消息(Message)

      消息一般分为同步消息(Synchronous Message),异步消息(Asynchronous Message)和返回消息(Return Message).如下图所示:

      clip_image057

      同步消息=调用消息(Synchronous Message)

      消息的发送者把控制传递给消息的接收者,然后停止活动,等待消息的接收者放弃或者返回控制。用来表示同步的意义。

      异步消息(Asynchronous Message)

      消息发送者通过消息把信号传递给消息的接收者,然后继续自己的活动,不等待接受者返回消息或者控制。异步消息的接收者和发送者是并发工作的。

      返回消息(Return Message)

      返回消息表示从过程调用返回

      自关联消息(Self-Message)

      表示方法的自身调用以及一个对象内的一个方法调用另外一个方法。

      clip_image058

      Combined Fragments

      clip_image059

      1)Alternative fragment(denoted “alt”) 与 if…then…else对应

      2)Option fragment (denoted “opt”) 与 Switch对应

      3) Parallel fragment (denoted “par”) 表示同时发生

      4) Loop fragment(denoted “loop”) 与 for 或者 Foreach对应

      三、时序图实例分析(Sequece Diagram Example Analysis)

      时序图场景

      完成课程创建功能,主要流程有:

      1、请求添加课程页面,填写课程表单,点击【create】按钮

      2、添加课程信息到数据库

      3、向课程对象追加主题信息

      4、为课程指派教师

      5、完成课程创建功能

      时序图实例

      clip_image060

      时序图实例分析

      1、序号1.0-1.3 完成页面的初始化

      2、序号1.4-1.5 课程管理员填充课程表单

      3、序号1.6-1.7 课程管理员点击【Create】按钮,并响应点击事件

      4、序号1.8     Service层创建课程

      5、序号1.9-1.10 添加课程到数据库,并返回课程编号CourseId

      6、序号1.11-1.12 添加课程主题到数据库,并返回主题编号topicId

      7、序号1.13 给课程指派教师

      8、序号1.14 向界面抛创建课程成功与否的消息

      四、总结(Summary)

      时序图(Sequence Diagram)是显示对象之间交互的图,这些对象是按时间顺序排列的。顺序图中显示的是参与交互的对象及其对象之间消息交互的顺序。时序图中包括的建模元素主要有:对象(Actor)、生命线(Lifeline)、控制焦点(Focus of control)、消息(Message)等等。最后,以课程创建功能演示一时序图实例。

      源文档 <http://www.blueidea.com/tech/program/2010/7695_6.asp>

      一、业务处理模型简介(Brief introduction)

      业务处理模型是一组活动的集合,描述了活动从开始到结束在时间或者空间上的顺序,以及输入和输出。业务处理模型最终输出要能够满足业务需要。

      clip_image061

      业务处理模型一般包括:

      1、目标(Goal)

      2、特定的输入(specific inputs)

      3、特定的输出(Specific outputs)

      4、有一定顺序的活动(Activities in some order)

      5、消息(Information)

      6、资源(Resource)

      二、业务处理模型元素(Elements)

      1、目标(Goal)

      每一个业务处理流程都有一些将要达到的目标,这些目标需要能够满足业务需求。

      2、消息(Information)

      使用消息完成活动(Activities)。在业务处理过程中,消息并不没有消耗,只是作为转化流程的一部分。消息可以来自于外部资源、客户、内部组织单元甚至是其他处理流程。比如订单模版,之前用来提供某一种样式的订单,现在作为活动的一部分并没有被消耗和用尽。

      3、资源(Resource)

      资源是一种输入,与消息(Information)不同的是,资源是被消耗和可以被用尽的。

      4、输出(outputs)

      每个业务流程都会产生一些满足业务需要的输出。输出可以是物理对象(例如报表和发票),也可以是整个业务流程的结束(例如完成订单)。

      三、业务处理模型案例分析(Business Process Model Example Analysis)

      clip_image062

      事件(Event)有客户要生成的订单Cutomer Order

      输入(inputs)有客户数据库Customer Database 和库存(Inventory)

      业务处理(Process)是Order handling Process

      输出(outputs)是生成的订单Completed Customer Order

      四、总结(Summary)

      业务处理模型是一组活动的集合,描述了活动从开始到结束在时间或者空间上的顺序,以及输入和输出。业务处理模型最终输出要能够满足业务需要。包括输入、输出、资源、消息和目标等元素。最后以实例进一步说明了业务逻辑模型。

      源文档 <http://www.blueidea.com/tech/program/2010/7695_7.asp>

      一、数据建模简介

      数据建模不仅可以对象的属性建模(比如E-R图),也可以对数据的行为建模(比如触发器Trigger、存储过程Stored Procedure).在进行数据库设计时,设计到如下几个概念:

      模式 Schema、主键 Primary、外键 Foreign key、关系 Relationship、约束constraint、索引 Index、触发器 Trigger、存储过程 Stored Procedure、视图 View。

      二、数据建模元素

      1、表(Table)

      表是关系数据库最基本的模型结构。如下图

      clip_image063

      表的主键:InventoryID

      表的外键:WarehouseId,关联到表Warehouse的主键

      可以设置Table的数据库类型,如下图

      clip_image064

      也可以设置表空间,如下图

      clip_image065

      2、表索引(Table Index)

      指按表文件中某个关键字段或表达式建立记录的逻辑顺序。它是由一系列记录号组成的一个列表,提供对数据的快速访问。索引不改变表中记录的物理顺序

      3、表触发器(Table Trigger)

      当对某一表进行诸如UPDATE、 INSERT、 DELETE 这些操作时,SQL Server 就会自动执行触发器所定义的SQL 语句,从而确保对数据的处理必须符合由这些SQL 语句所定义的规则。

      触发器的主要作用就是其能够实现由主键和外键所不能保证的复杂的参照完整性和数据的一致性

      4、表约束(Table Constraint)

      通过对列的约束,保证数据的有效性。

      clip_image066

      5、视图(View)

      视图是从一个或多个表或视图中导出的表,其结构和数据是建立在对表的查询基础上的。如下图

      clip_image067

      6、存储过程(Stored Procedure)

      将常用的或很复杂的工作,预先用SQL语句写好并用一个指定的名称存储起来, 那么以后要叫数据库提供与已定义好的存储过程的功能相同的服务时,只需调用execute,即可自动完成命令。

      clip_image068

      三、数据建模实例

      clip_image069

      1、表有仓库Warehouse、库存Inventory以及书Book

      2、主键分别为WarehouseID,InventoryID,ISBN

      3、外键,表Iinventory的外键是WarehouseID,同时也是Warehouse的主键表Book的外键是InventoryID,同时也是Inventory的主键

      4、关系,表Warehouse与表Inventory是一对多的关系

      Inventory与表Book是一对多的关系。


      转载: http://www.cnblogs.com/kean/archive/2010/09/17/1829056.html

    展开全文
  • 以前项目整理的用例模板,单个模板样式,包含每项的简要说明
  • 1. Use Case 在面向对象中,我们经常会见到这类型的用例图,其实不难,我们只需了解每一个元素需要的内容就可以完全掌握它,我让我们一起来看吧!!! 1.1用例简介: ...比如:用户(user)想要什么?...

    在这之前,我给大家推荐一款在线画流程图的神奇💁💁开始制作!

    1. Use Case

    在面向对象中,我们经常会见到这类型的用例图,其实不难,我们只需了解每一个元素需要的内容就可以完全掌握它,我让我们一起来看吧!!!

    1.1用例简介:

    use case 讲述了参与者使用系统的故事,用例展示了系统执行的一系列操作,使特定的参与者生成一个可以直观观测的结果。(表达功能和需求)。用例是文本文档,而不是图表,是编写文本的行为。

    比如:用户(user)想要什么?

    • 想要想要从图书馆出一本书
    • 想要付帐
    • 想要输入他的注册详情

    1.2用例的作用:

    1. 对于非分析人员来说是一种简单,熟悉的交流工具,重要的是,它可以减少沟通障碍。
    2. 帮助我们关注所使用系统的业务价值和开发的优先级。
    3. 通过它所展现的故事来说明功能需求。
    4. 定义了系统行为的契约。

    1.3类型:

    • 系统用例(system use case)
    • 业务用例(business use case)

    1.4方法:

    用例的句子一般是(动词+名字构成),比如:确认客户订单,租赁视频,返还视频,支付罚款.....

    2. 角色和用例(Actors and Use Case)

    2.1角色(绘画出人物图标)

    定义系统外部对象所扮演的角色。

    • 是外部观点而不是内部的结构为特征
    • 参与涉及与系统的消息交换和操作的交互
    • 通过与系统交互实现目标
    • 具有充当参与者角色的对象(具有操作和属性)的实例
    • 可能与其他参与者具有泛化关系(后面讲之间的关系)

    2.2用例(对话框或者椭圆)

    定义系统所提供的功能或者单元块 

    • 表示系统及其参与者之间的外部交互序列,即系统如何为各种交互提供服务
    • 产生对参与者有价值的结果
    • 具有表示一系列活动的场景的实例(在序列图中描述)
    • 可能具有扩展点
    • 分层组织

    2.3角色和用例之间的关系

     通信关系(用实线表示)

    • 关联是否显示了参与者和用例之间的交互?
    • 是否只允许参与者和用例之间的关系?

    用例之间的依赖关系

    • <extend>:提供额外功能,并且很可能再次被使用,这两者都应该有助于保持基本UC的简单性,箭头从扩展用例绘制到基本用例
    • <include>:是一个单独的用例,因为它将再次被使用,箭头从基本用例绘制到包含的用例

     

    2.4关于租赁的例子

    角色的意图:

    • 客户赠送会员卡及租赁物品
    • 职员记录项
    • 客户支付 

     

     系统的责任:

    • 记得租来的物品
    • 计算当前价格
    • 授权并记录付款 

     

    2.43 关于该用例图典型的事件流

     角色的意图

    • 顾客带着视频或游戏来到收银台
    •  客户向店员出示他们的会员身份,店员将其输入系统
    • 对于每一款视频或游戏,店员都会将物品标识记录到系统中
    • 店员告诉顾客总费用,并要求付款
    • 顾客用现金或信用卡支付给店员
    • 店员将付款记录到系统中
    • 店员将收据和贷款报告交给顾客,顾客带着租赁物品离开。

    系统的责任

    • 提供会员信息,以及贷款状况(通常没有贷款,也没有未付贷款)
    • 显示累计列表的租赁项目标题,到期日期,总租金,以及任何逾期费用
    •  如果信用付款,给予授权
    • 生成收据和贷款报告 

    2.44 将故障模式作为扩展 

    通常,每一步都可能失败,单独注意失败情况。(备选场景列表)

    替代路径或者方案

    • 客户现金不足。申请信用付款,取消交易,或扣除租赁项目,直到交易可以支付。
    • 客户有未付的滞纳金,不会支付。客户在租用更多商品之前必须先付款,所以要么全额付款,要么取消交易。
    • 未能授权信用付款,原因可能是信用不足或授权服务不活跃。要求现金支付。

    3. 用例描述 

    用例名称

           简要描述

    事件流程

    • 基本流程
    • 子流程
    • 交替流程
    特殊要求
    先决条件
    后置条件
    注释

     

     

     

     

     

     

     

     

     

     

     

    展开全文
  • HDP profile user case

    2012-01-12 10:04:02
    description: HDP profile user case and test case
  • 学习画用例图(UserCase)

    千次阅读 2009-05-16 10:41:00
    学习画用例图(UserCase),注意箭头方向,"扩展到...","包含了...","泛化于..." 

    学习画用例图(UserCase),注意箭头方向,"扩展到...","包含了...","泛化于..."

    用例图

     

    展开全文
  • 利用user case管理开发

    千次阅读 2007-06-18 09:32:00
    最近在带领一个小组进行一个系统的开发,由于人手比较紧张,所以系统的架构、设计自己都要做,自然少了很多和成员沟通的地方。要知道,如果管理岗位如果具体做某件事情是很致命的,比如一个架构师还要负责某个业务...

     

    最近在带领一个小组进行一个系统的开发,由于人手比较紧张,所以系统的架构、设计自己都要做,自然少了很多和成员沟通的地方。要知道,如果管理岗位如果具体做某件事情是很致命的,比如一个架构师还要负责某个业务模块的开发,但现实就是这样。为了保证良好的沟通效果与进度控制,除了要认真地制订出切实执行的计划外,在工作中善于总结和应用方法也会收到好的效果。

    现在把我琢磨的用例管理开发的方法介绍下。

    在需求分析系统设计阶段,我们会画大量的用例图,需求阶段的用例,能够帮助我们更好地整理需求,更方便地去与用户进行交流;系统设计阶段我们会把这些用例转变成系统用例,清楚地标识出系统有那些功能。在开发阶段,我们要善于利用前段的成果,具体做法是:

             把系统用例进行进一步细化,细化到每个功能的的实现,甚至具体的方法(CRUD)等等。有了这些,凭自己的经验,可以勾勒出整个系统的工作量,为人员配备、人员水平的选择提供基础。根据个人水平的高低,把业务用例图分给不同的开发人员。

            在开发人员完成某个功能后,要及时把成果反映在用例图上,我采取的方法是涂鸦,呵呵。开发人员计划本周要完成的涂成兰色,完成中遇到困难的,涂黄,表示需要帮助与支持,确实实现或设计有问题的,变红色,提示设计师或需求人员;完成的则为绿色。这样管理者即使自己工作很忙,也可以抽点时间及时地了解到成员的工作状况。并根据结果采取不同的指导措施。

           图例说明:  兰色   计划完成   

                                 绿色   已经完成  

                                 黄色   需要帮助与支持

                                 红色   实现起来有很大困难


     

    展开全文
  • 高通chi usecase流程分析 本文分为三大部分: 第一部分简述高通isp架构及数据流程, 第二部分分析usecase xml 第三部分分析uscase代码流程
  • 非常有用的User case用例描述模板

    千次阅读 2006-08-04 17:04:00
    Table 6.0 Use Case # DATAENTRYPROJECTCUST-1009
  • 用途:用过描述需求:确定系统的边界和系统应具备的功能(此处的功能是指从用户或系统参与者的角度来看)。目标:用大家都能看的明白的符号,更好的和客户沟通和交流。构成:系统用户、用例、用例之间的关系三部分。...
  • 问题 运行Flink scala程序时,提示如下错误,但仔细检查UserBehavior样例类的确仅定义了一次。 解决 右击重新编译代码,再运行。至于原因还不清楚。 ...
  • Use Case(用例)和User Story(用户故事)他们之间究竟有什么联系和区别,还是他们本身就是一个物种的两种不同叫法而已,究竟哪个好或是哪个不好,这些问题的讨论见诸于各大网络文章之中,其实本人当初也有所迷惑,经过...
  • Use CaseUser Story

    千次阅读 2009-12-01 09:47:00
    Use Case(用例)和User Story(用户故事)他们之间究竟有什么联系和区别,还是他们本身就是一个物种的两种不同叫法而已,究竟哪个好或是哪个不好,这些问题的讨论见诸于各大网络文章之中,其实本人当初也有所迷惑,经过...
  • 如何书写Use Case

    千次阅读 2013-07-18 00:11:04
    什么是Use Case 用例描述文档的书写是系统分析人员对用户需求的深刻理解的体现。是后期时序图和实际开发的重要依据。也可以对作为项目估算的依据,以及根据UC复杂度和开发周期来衡量开发人员的工作效率。因此UC的...
  • Use caseuser story在不同项目中定义会有一定区别,此处只讨论最大众的定义。 最基本的区别:use case是以用例图表示,user story是以一句话表示(笛卡尔积法分析我们如何正确使用Use Story?)。 最基本的共同点...
  • Use Case的学习

    千次阅读 2018-04-15 20:33:27
    用例图是指由参与者、用例,边界以及它们之间的关系构成的用于描述系统功能的视图。用例图是外部用户(被称为参与者)所能观察到的系统功能的模型图。参与者、用例和子系统形状元素描述和主要属性1Actor表示用户、...
  • Use Case图与Use Case详细描述

    万次阅读 2018-05-03 16:06:30
    实验一博客地址:https://blog.csdn.net/chicharito07/article/details/80095891用况登陆:用户输入账号密码登录时系统通过验证,若通过则返回(或进入)主页,否则提示错误。 用况注册:用户点击进入注册界面,...
  • 给游戏开发者们提供的一些用于玩家调研的不同方法。内有案例分析,英文原版
  • Oracle删除用户drop user报错解决方案

    千次阅读 2019-03-21 13:13:58
    由于开发过程中对数据库的操作比较多,另外也是怕占用资源,决定将数据库所使用用户删除掉,... alter user 用户名 account lock; 2.查看当前用户占用资源: select saddr,sid,serial#,paddr,username,status f...
  • sql 关于case when的两种用法

    万次阅读 2018-05-24 20:11:26
    最近做项目关于数据迁移部分了解到case when 的两种用法 1.case 字段 when 条件 then 结果 else 结果 end; 2.case when 条件 then 结果 when 条件 then 结果 else 结果 end; 当处理nul...
  • writing effective use case

    2007-05-11 15:06:23
    怎样写好use case
  • 我们根据上面的三种情况,将对这个接口的用例写在一个对应的单独文件中testFile\case\userCase.xlsx ,userCase.xlsx内容如下: 紧接着,我们有了用例设计的Excel了,我们要对这个Excel进行数据的读取操作,...
  • 网上购物系统领域类图和usecase

    千次阅读 2017-04-11 20:05:46
     Formresponse 订单响应即发货和确认购买(use case)  In goods 商品上架(use case)  Down goods 商品下架(use case)  Goodsmodify 商品信息修改(use case)   3.领域类图 ...
  • 用例描述了用户如何使用系统来实现特定目标。用例图由系统,相关用例和参与者组成,并将这些相互关联起来以便可视化:正在描述什么?(系统)谁正在使用该系统?(参与者)和参与者想要达到什么?...
  • 一. ... 从上面的用例图模型,我们可以大致了解用例图所描述的是什么。... 用例图,即用来描述什么角色通过某某系统能做什么事情的图,用例图关注的是系统的外在表现,系统与人的交互,系统与其它系统的交互。...
  • (use case)是什么,其实用例图是软件开发中的“黑盒”部分,最后我理解的方式就是,每一个角色都扔进去,每一个功能扔进去,其实用例图就是,什么人可以做什么事,有或者理解成,什么东西可以做什么事,因为角色并...
  • UML中的用例(Use Case)概念分析及StarUML实例 收藏UML中的用例(Use Case)概念分析及StarUML实例在UML 中use case 似 乎最簡單的,用例建模的最主要功能就是用来表达系统的功能性需求或行为,依我...
  • plantuml 之用例图(一)

    千次阅读 2018-06-17 18:28:56
    usecase 关键字 as 用于指定别名 效果见图 2-1. 图 2-1 图 2-1 代码 @startuml (&quot;基本语法&quot;) (&quot;as 别名&quot;) as (UC2) usecase &quot;usecase 命令&quot; ...
  • Oracle 12.2 sec_case_sensitive_logon设置为true 或者false 时,针对 system用户和新建用户的区别.
  • 任务Task用例UseCase用户故事UserStory场 任务Task用例UseCase用户故事UserStory场 景Scenario 景Scenario 与任务类似的概念有用例用户故事场景等在本小节我们会对其作详细 与任务类似的概念有用例用户故事场景等在...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 428,375
精华内容 171,350
关键字:

usercase