第8讲用例及用例图
- 格式:ppt
- 大小:992.50 KB
- 文档页数:143
UML实践----用例图、顺序图、状态图、类图、包图、协作图2009-01-20 作者:Randy Miller 来源:网络面向对象的问题的处理的关键是建模问题。
建模可以把在复杂世界的许多重要的细节给抽象出。
许多建模工具封装了UML(也就是Unified Modeling Language™),这篇课程的目的是展示出UML的精彩之处。
UML中有九种建模的图标,即:∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接。
而且每个部分都有一个小问题,测试一下你对这个部分的理解。
为什么UML很重要?为了回答这个问题,我们看看建筑行业。
设计师设计出房子。
施工人员使用这个设计来建造房子。
建筑越复杂,设计师和施工人员之间的交流就越重要。
蓝图就成为了这个行业中的设计师和施工人员的必修课。
写软件就好像建造建筑物一样。
系统越复杂,参与编写与配置软件的人员之间的交流也就越重要。
在过去十年里UML就成为分析师,设计师和程序员之间的“建筑蓝图”。
现在它已经成为了软件行业的一部分了。
UML提供了分析师,设计师和程序员之间在软件设计时的通用语言。
UML被应用到面向对象的问题的解决上。
想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的。
一个模型model就是根本问题的抽象。
域domain就是问题所处的真实世界。
模型是由对象objects组成的,它们之间通过相互发送消息messages来相互作用的。
记住把一个对象想象成“活着的”。
对象有他们知道的事(属性attributes)和他们可以做的事(行为或操作behaviors or operations)。
对象的属性的值决定了它的状态state。
类Classes是对象的“蓝图”。
一个类在一个单独的实体中封装了属性(数据)和行为(方法或函数)。
对象是类的实例instances。
用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象。
用例图(User Case)用例图是用来描述什么角色通过某某系统能做什么事情的图,用例图关系的是系统的外在表现,系统与人的交互,系统与其它系统的交互。
下面逐一说明用例图中各种符号的意义:小人:对使用某系统的用户进行分类后,可以总结出使用本系统有哪些角色,不同的角色的工作责任不太一样,他们需要用到的系统的功能也会不太一样。
小人就是角色,它给了我们一个启示,我们思考某系统的需求时,可从不同角色的角度来思考。
例如:我们要做一个考勤系统,你会怎样思考呢?会一下子列出很多功能?比较好的方式,应该是先思考什么人会用这个系统,我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统,对于一般员工来说除了打卡,他还关注什么?对于前台,她是不是要做一些考勤的统计?而财务是不是要根据考勤情况来调整员工的薪金?这样的思考方式,会让我们更容易全面发掘系统的需求。
还需要特别说明的是:角色可能是人,也可能不是人,而是另外的一个系统,本系统与另外一个系统交互的话,可以将另外一个系统画成某某角色。
圈圈:圈圈里面会有一段动宾结构的文字,也就是“动词+名词”这样的方式,这个圈圈+圈圈里面的文字,就是用例,这些用例表明了系统能做什么事情。
以考勤系统为例:有两个用例叫“打卡”、“查看自己的考勤情况”,这个两个圈圈分别用一条线连到了“一般员工”这个角色,我们可以按这样的顺序来读这个图:先读出角色的名字,然后读出用例中的文字。
按着这样的读法,我们可以得到两句完整的句子:“一般员工打卡”“一般员工查看自己的考勤情况”大家可以用这样的方式来检查自己用例图是否画得合适。
某用例不一定是只属于某个角色的,有不少用例是多个角色“共享”的。
大框框:在所有用例的外面,有一个方框,这个方框只框住了用例,没有框住角色,这个东西就叫做系统边界,框框的上部会注明本系统的名字。
我们所做的系统,是不可能包括角色的,系统要发挥各种作用,要靠各角色“穿越”系统边界来使用本系统的用例。
用例图的含义及画法用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步,它描述人们如何使用一个系统。
用例视图显示谁是相关的用户、用户希望系统提供什么样的服务,以及用户需要为系统提供的服务,以便使系统的用户更容易理解这些元素的用途,也便于软件开发人员最终实现这些元素。
用例图在各种开发活动中被广泛的应用,但是它最常用来描述系统及子系统。
当用例视图在外部用户出现以前出现时,它捕获到系统、子系统或类的行为。
它将系统功能划分成对参与者(即系统的理想用户)有用的需求。
而交互部分被称作用例。
用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。
用例图包含六个元素,分别是:参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
用例图可一个包含注释和约束,还可一个包含包,用于将模型中的元素组合成更大的模块。
有时,可以将用例的实例引入到图中。
用例图模型如下所示,参与者用人形图标来标识,用例用椭圆来表示,连线表示它们之间的关系。
一.参与者(Actor)1.参与者的概念参与者是系统外部的一个实体,它以某种方式参与用例的执行过程。
参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。
参与着由参与用例时所担当的角色来表示。
在UML中,参与者用名字写在下面的人形图标表示。
每个参与者可以参与一个或多个用例。
它通过交换信息与用例发生交互(因此也与用例所在的系统或类发生了交互),而参与者的部实现与用例是不相关的,可以用一组定义其状态的属性充分的描述参与者。
参与者有三大类:系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。
第一类参与者是真实的人,即用户,是最常见的参与者,几乎存在于每个系统中。
命名这类参与者时,应当按照业务而不是位置命名,因为一个人可能有很多业务。
.1 用例图由前几章可知,用例图用来捕获用户要求,需要首先构建。
为什么?因为用例图在较高级别(即非技术细节)描述用户要求。
概念设计对项目的成败至关重要。
由第2章可知,在决定使用哪种技术前,一定要切实了解影响选择的要求。
用例图的高级特性有利于了解项目范围。
这些图成为项目演化过程中构建明细模型的基础。
用例图的另一个强大之处在于,它使用普通文本和简单绘图技术,不使用任何技术术语,使广大受众都可以理解用例图。
用例图由以下一些基本元素构成:●行动者(Actor)●关系(Relationship)●过程(Process)●包(Package)●系统边界(System boundary)下面几节描述这些元素。
4.1.1 行动者“行动者”是与系统交互的某人或某事。
“交互”指行动者从系统接收收息,或向系统传送信息。
要注意,行动者可以是人,也可以是物(如另一个应用程序),例如从解决方案接收信息的会计系统。
UML行动者的符号是一个人形,如图4-1所示。
图4-1 行动者的符号是一个人形注意:行动者使用的人形符号是最常用也是最正式的符号。
不过,按UML规范,行动者也可以是一个包含Actor定型的矩形。
该符号与类符号类似,在第5章讨论类图时,将看到这个符号。
图4-1的行动者是一个普通行动者,即一个直接与解决方案交互的真正行动者。
还有其他类型的行动者,即业务行动者。
业务行动者是当前分析业务的行动者,换言之,从业务观点看,参与业务日常过程的所有人或事物都是行动者。
业务行动者不一定是您解决方案的行动者,而是相关业务的行动者。
会记助手便是其中一例。
会计助手可能不是当前开发的解决方案的行动者,而是一个业务行动者。
为什么要注意会计助手呢?虽然这个角色不是解决方案的行动者,但他们可能是采访主体,可提供有价值的信息。
在优化一些过程时,会计助手的知识及他们的日常工作也能提供宝贵信息。
在设计解决方案前,必须了解整个业务,即需要进行业务分析。
“业务分析”是记录业务的过程。