软件设计过程中画用例图的步骤

软件设计过程中画用例图的步骤

ID:32436538

大小:48.50 KB

页数:3页

时间:2019-02-04

软件设计过程中画用例图的步骤_第1页
软件设计过程中画用例图的步骤_第2页
软件设计过程中画用例图的步骤_第3页
资源描述:

《软件设计过程中画用例图的步骤》由会员上传分享,免费在线阅读,更多相关内容在应用文档-天天文库

1、用例图用例图(UseCaseDiagram)是由软件需求分析到最终实现的第一步,它描述人们如何使用一个系统。用例图包含六个元素,分别是:参与者(Actor)、用例(UseCase)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。一.参与者(Actor)确定参与者在获取用例前首先要确定系统的参与者,开发人员可以通过回答以下的问题来寻找系统的参与者。(1)        谁将使用该系统的主要功能。(2)        

2、谁将需要该系统的支持以完成其工作。(3)        谁将需要维护、管理该系统,以及保持该系统处于工作状态。(4)        系统需要处理哪些硬件设备。(5)        与该系统那个交互的是什么系统。(6)        谁或什么系统对本系统产生的结果感兴趣。二、用例(UseCase)识别用例用例图对整个系统建模过程非常重要,在绘制系统用例图前,还有许多工作要做。系统分析者必须分析系统的参与者和用例,他们分别描述了“谁来做”和“做什么”这两个问题。识别用例最好的方法就是从分析系统的参与者开始

3、,考虑每一个参与者是如何使用系统的。使用这种策略的过程中可能会发现新的参与者,这对完善整个系统的建模有很大的帮助。用例建模的过程是一个迭代和逐步精华的过程,系统分析者首先从用例的名称开始,然后添加用例的细节信息。这些信息由简短的描述组成,它们被精华成完整的规格说明。在识别用例的过程中,通过回答以下几个问题,系统分析者可以获得帮助。(1)        特定参与者希望系统提供什么功能。(2)        系统是否存储和检索信息,如果是,由哪个参与者触发。(3)        当系统改变状态时,是否通知

4、参与者。(4)        是否存在影响系统的外部事件。(5)        哪个参与者通知系统这些事件。三、用例间的关系  1.关联关系(Association)2.包含关系(Include)包含关系把几个用例的公共步骤分离成一个单独的被包含用例。被包含用例称作提供者用例,包含用例称作客户用例,提供者用例提供功能给客户使用。用例间的包含关系允许包含提供者用例的行为到客户用例的事件中。包含关系使一个用例的功能可以在另一个用例中使用,如下所述。(1)        如果两个以上用例有大量一致的功能,则

5、可以将这个功能分解到另外一个用例中。其它用例可以和这两个用例建立包含关系。(2)        一个用例的功能太多时,可以用包含关系建模两个小用例。要使用包含关系,就必须在客户用例中说明提供者用例行为别包含的详细位置。这一点同功能调用有点类似。事实上,它们在某种程度上具有相似的语义。3.扩展关系(Extend)相对于包含关系一定要执行的特性,扩展关系(extend)则是一种可选择执行的关系。以自动柜员机(ATMSystem)为例,打印收据(printreceipt)与提款之间的关系就比较适合采用扩展关

6、系,如下图所示。在提款流程结束之前,会询问顾客是否需要打印收据,所以打印收据不是一段必要的流程,而是一段可选择的流程。4.泛化关系(Generalization)一个用例可以被特别列举为一个或多个用例,这被称为用例泛化。当父用例能够被使用时,任何子用例也可以被使用。在UML中用例泛化与其它泛化关系的表示法相同,用一个三角箭头从子用例指向父用例。在用例泛化中,子用例表示父用例的特殊形式。子用例从父用例处继承行为和属性,还可以添加、覆盖或改变继承的行为。如果系统中一个或多个用例是某个一般用例的特殊化时,就

7、需要使用用例的泛化关系。

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。