《面向对象的分析》PPT课件.ppt

1,第六章 面向对象的需求分析,面向对象的需求分析方法的核心 是利用面向对象的概念和方法为软件需求建造模型。它包含面向对象风格的图形语言机制以及用于指导需求分析的面向对象方法学。 UML（统一建模语言，Unified Modeling Language）,2,主要内容 ,面向对象的概念与思想 UML概述 基于UML的需求分析,第六章 面向对象的需求分析,3,6.1 面向对象的概念与思想,面向对象(Object-Oriented,简称OO)的需求分析方法 通过提供对象、对象间消息传递等语言机制让分析人员在解空间中直接模拟问题空间中的对象及其行为，从而削减了语义断层，为需求建模活动提供了直观、自然的语言支持和方法学指导。,6.1面向对象的概念与思想,4,面向对象的概念与思想,面向对象 = 对象 + 类 +类间的关系 + 消息,6.1面向对象的概念与思想,返回,5,对象(object),对象是现实世界中个体或事物的抽象表示，是其属性和相关操作的封装。 例如，人张三就是一个对象，他具有身高180cm，体重55kg，年龄23岁等属性，对于该对象可以实施吃饭、睡觉等操作。,6.1面向对象的概念与思想,返回,6,类(class) ,类表示某些对象在属性和操作方面的共同特征，即类是具有相同属性、操作、关系的对象集合的总称。 例如，人类，每个人都有身高、体重等属性和吃饭睡觉等操作。,6.1面向对象的概念与思想,返回,7,类间的关系 ,继承 聚合 构成 关联 依赖 耦合从高到低的顺序 继承构成聚合关联依赖,6.1面向对象的概念与思想,返回,8,继承(inherit) ,类之间的继承关系是现实世界中遗传关系的模拟，它表示类之间的内在联系以及对属性和操作的共享，即，子类可以沿用父类(被继承类)的某些特征。子类也可以具有自己独有的属性和操作。 例如，老人、年轻人等，他们可以继承人的某些属性和操作，他们自己独立的属性分别可以是年龄50岁和年龄30岁。 补充: 多态性是指同一个操作名称，能表现出不同的行为，即重载。它使程序复用程度和维护程度更高。,6.1面向对象的概念与思想,返回,9,聚合（聚集）,用于描述部分整体关系，聚合可以进一步细分为构成和聚合。,6.1面向对象的概念与思想,返回,10,聚合(普通聚合),在普通聚合关系中，部分类的生命周期独立于整体类的生命周期。 为了表现一个聚合关系，你画一条从父类到部分类的实线，并在父类的关联末端画一个未填充棱形，见下图。,6.2UML概述,P148图6.2中类课程与类课程设置之间就是一种聚合关系，它表示课程可以由多个课程设置构成。,返回,11,构成（组合聚合）,构成关系是聚合关系的另一种形式，但是子类实例的生命周期依赖于父类实例的生命周期（或一个部件只能参与一个整体）。 注意组合关系如聚合关系一样绘制，不过这次菱形是被填充的。,6.2UML概述,返回,12,关联,一个关联用两个类间的实线表示。在线的任一端，放置一个多重值。 见教材P148图6.2中老师和课程设置之间就是一个关联。其含义分别是：一个老师可以选择上0到4门课，一门课程只能由一个老师上课。,6.2UML概述,返回,13,依赖,依赖关系是一种关联关系的弱化，被依赖的事物的改变有可能会影响到依赖该事物的事物，反之不成立（P163）。通常情况下，依赖关系体现一种使用或调用关系。 P148图6.2中类学生与课程注册表有依赖关系，学生使用课程注册表上的课程进行学习。 依赖关系，表示为一条带有指向已知类的开放箭头（关闭的箭头或三角形，用于标志继承）的实线。,6.2UML概述,返回,14,消息,消息传递是对象与其外部世界相互关联的唯一途径。对象可以向其它对象发送消息以请求服务，也可以响应其它对象传来的消息，完成自身固有的某些操作，从而服务于其它对象。 因为对象的操作主要用来响应外来消息并为其它对象提供服务，所以它们也被称作“外部服务”。,6.1面向对象的概念与思想,返回,15,6.2 UML概述,6.2.1 UML的语言机制 6.2.2 基于UML的软件开发过程,第六章 面向对象的需求分析,返回,16,UML的语言机制,UML通过图形化的表示机制从多个侧面刻画系统的分析和设计模型。 UML共定义十种视图，可分四类： 用例图 静态图（类图、对象图、包图） 行为图（交互图顺序图和协作图)、状态图、活动图） 实现图（构件图和布署图）,6.2UML概述,17,用例图（use case view）,用例图从外部用户的角度描述系统的功能，并指出功能的执行者。 用例图包含两部分： 用例图 用例描述 实例,6.2UML概述,返回,18,用例图（use case view）,用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每个用例，用文本文档来完成。,6.2UML概述,返回,19,用例图参与者,（1）参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。,6.2UML概述,20,用例图,参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称,6.2UML概述,返回,21,用例图用例,概念 图示 用例间的关系,6.2UML概述,返回,22,概念,用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是UML对用例的正式定义，即用例是参与者想要系统做的事情。 对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。,6.2UML概述,返回,23,用例图,用例在画图中用椭圆来表示，椭圆下面附上用例的名称。,6.2UML概述,返回,24,用例之间的关系,用例之间的关系有三种：即包含（include）或使用（use）、扩展(extend)、泛化(generalization)等3种关系。 P158,6.2UML概述,25,用例之间的关系,包含关系 在一个复杂系统中，不同的用例之间可能存在一些相同的行为，这时可以将这些相同的行为提取出来单独组成一个用例。当其他用例使用该用例时，用例之间就形成了包含关系。在uml语言中，包含关系用带关键字的虚线表示，箭头指向被包含的用例。见下图：,6.2UML概述,26,用例之间的关系,扩展关系 在用例的执行过程中，可能会出现异常行为，也可能会在不同的流程分支中选择执行，这时可以将异常行为或可选分支抽象成一个单独的扩展用例，它与主用例之间形成扩展关系。它用带关键字的的虚线表示，箭头指向被扩展的用例。见下图：,6.2UML概述,27,用例之间的关系,泛化关系 用例间的泛化关系是描述用例之间的一般与特殊关系的，不同的子用例代表了父用例的不同实现方法。（相当于继承）见下图：同样的参与者之间也可以存在泛化关系。,6.2UML概述,返回,28,用例图系统边界,（3）系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以,在画图时可省略。,6.2UML概述,返回,29,用例图箭头,（4）箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。,6.2UML概述,返回,30,用例描述,用例名称:对用例的命名 简要描述：对用例的角色、目的的简要描述； 前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件； 基本事件流：描述该用例的基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流和异常流，而只有最有可能发生的事件流； 其他事件流：表示这个行为或流程是可选的或备选的，并不是总要总要执行它们； 异常事件流：表示发生了某些非正常的事情所要执行的流程； 后置条件：用例一旦执行后系统所处的状态；,6.2UML概述,返回,31,用例图和用例描述设计实例,前台客户系统的用例图如下：,6.2UML概述,32,用例图和用例描述设计实例,后台管理系统用例图如下：,6.2UML概述,33,网站公告发布这个用例的描述,6.2UML概述,返回,34,静态图类图(class view),类图描述系统的静态结构，类图的节点表示系统中的类及其属性和操作。见图6.2 类的 UML 表示是一个长方形，垂直地分为三个区，如下图所示。,6.2UML概述,35,静态图类图(class view),类是具有相同属性、操作、关系的对象集合的总称。类的 UML 表示是一个长方形，垂直地分为三个区，如下图所示。,6.2UML概述,36,静态图类图(class view),（1）名称 每个类都必须有一个名字，用来区分其它的类。类名是一个字符串，称为简单名字。路径名字是在类名前加包含类的包名为前缀。例如Wall、java:awt:Wall都是合法的类名。 （2）属性 属性是指类的命名的特性，常常代表一类取值。类可以有任意多个属性，也可以没有属性。在类图中属性只要写上名字就可以了，也可以在属性名后跟上类型甚至缺省取值。如上图。,6.2UML概述,37,静态图类图(class view),（3）操作 操作是类的任意一个实例对象都可以调用的，并可能影响该对象行为的实现。操作在类图中如上图描述。 （4）关系 类之间的关系包含：继承、关联、依赖和聚合等。,6.2UML概述,38,静态图对象图,对象图（object diagram）是类图的一个实例，它描述在某种状态下或在某一时间段，系统中活跃的对象及其关系。在对象图中，一个类可以有多个活跃的对象图。,6.2UML概述,返回,39,静态图包图,概念 命名空间 包标记 包间的关系,6.2UML概述,40,包图概念,包图描述系统的分解结构，它表示包以及包之间的关系,常用于建立系统的顶层构架。（文件夹）,6.2UML概述,返回,41,包图命名空间,包对放入包的类元提供命名空间。即如果在包中放入一个某种类型的元素，那么它的名字对于那个包中具有那种元素的类型来说是唯一的，可以在不同的包中具有相同的名字。,6.2UML概述,返回,42,包标记,在包图中，包表示如下图：,6.2UML概述,返回,43,包间的关系,包之间存在四种关系： 依赖 构成 连接器 继承,6.2UML概述,返回,44,依赖,如果对类A的修改导致B的改变，则称为B依赖于A。 如果两个包中存在具有依赖关系的两个类，则认为这两个包存在依赖关系。在图中用带箭头的虚线表示。见P159图6.11,6.2UML概述,返回,45,构成,包的构成关系是指包是可以嵌套的，即包中不仅可以包含类，还可以包含子包 在图中为了表示这种构成关系，从子包拉出一条闭合的，单键头（或三角形）的虚线指向父包。见P159图6.11,6.2UML概述,返回,46,连接器,为了表示软件构架，还需要在包之间引进一种称为一种“连接器”的边。连接器用来表示包之间的信息传递、事件发送和软件调用等关系，且有单向和双向之分。见P160图6.12,6.2UML概述,返回,47,继承,和类一样，包之间存在继承关系。如果两个包中存在具有继承关系的两个类，则认为这两个包存在继承关系。,6.2UML概述,返回,48,行为图,行为图是刻画系统的动态行为的视图。为了从不同的侧面刻画系统的动态行为，一般行为图包含以下三个视图： 活动图 状态图 交互图,6.2UML概述,返回,49,行为图活动图,概念 作用 组成,6.2UML概述,返回,50,活动图的概念,活动图(activity diagram)描述系统为完成某项功能而执行的操作序列，这些操作序列可以并发和同步。如图 活动图实际上是用例的一种描述方式。 在用例模型中，活动图用来捕捉用例的活动，使用框图的方式显示动作及其结果。活动图着重描述操作(0peration)以及用例实例或对象中的活动。,6.2UML概述,返回,51,作用,活动图可以用作下述目的： 1)描述一个操作执行过程中所完成的工作(动作)，这是活动图最常见的用途。 2)描述对象内部的工作。 3)显示如何执行一组相关的动作，以及这些动作如何影响它们周围的对象。 4)显示用例的实例如何执行动作以及如何改变对象状态。 5)说明一次商务活动中的人(角色)、工作流组织和对象是如何工作的。,6.2UML概述,返回,52,活动图的组成,活动图由以下一些元素组成： 起始状态(start state)和终止状态(end state) 动作与转移及守护条件 决策(decision) 同步棒(synchronization bar) 泳道(swimlane),6.2UML概述,返回,53,起始状态和终止状态,起始状态显式地表示活动图上一个工作流程的开始，用实心圆点来表示（如图）。 在一个活动图中，只有一个起始状态。终止状态表示了一个活动图的最后和终结状态，一个活动图中可以有0个或多个终止状态，终止状态用实心圆点外加一个小圆圈来表示(如图)。,6.2UML概述,返回,54,行为图活动图,6.2UML概述,55,动作与转移及守护条件,动作 活动图中的动作用一个圆角四边形表示，其内部的文本串用来说明采取的动作。如图 转移 动作之间的转移用箭头来表示，称为转移，用带有箭头的实线表示。 守护条件 箭头上可能还带有守护条件、发送短句和动作表达式,守护条件用来约束转移，守护条件为真时转移才可以开始,他们用“ ”括起来（如实发金额0）。,6.2UML概述,返回,56,决策,用菱形符号来表示决策点(交叉点)，决策符号可以有一个或多个进入转移，两个或更多的带有守护条件的发出转移。如图,6.2UML概述,返回,57,同步棒,可以将一个转移分解成两个或更多的转移，从而导致并发的动作。所有的并行转移在合并之前必须被执行。一条粗黑线表示将转移分解成多个分支，同样用粗黑线来表示分支的合并，粗黑线称为同步棒(如图)。,6.2UML概述,返回,58,泳道,作用 活动图告诉你发生了什么,但没有告诉你该项活动由谁来完成。在程序设计中,这意味着活动图没有描述出各个活动由哪个类来完成。泳道解决了这一问题。 图形符号 如图所示,泳道用矩形框来表示,属于某个泳道的活动放在该矩形框内,将对象名放在矩形框的顶部,表示泳道中的活动由该对象负责。,6.2UML概述,返回,59,行为图状态图,概念 符号集 状态 转移,6.2UML概述,返回,60,概念,状态图(statechart diagram)用来描述一个特定对象的所有可能状态及其引起状态转移的事件。大多数面向对象技术都用状态图表示单个对象在其生命周期中的行为。,6.2UML概述,返回,61,符号集,状态图的符号集包括5个基本元素： 初始起点，它使用实心圆来绘制；见教材P150 状态之间的转换，它使用具有开箭头的实线来绘制； 状态，它使用圆角矩形来绘制； 注释，它使用一个页面标志来表示； 一个或者多个终止点，它们使用内部包含实心圆的圆来绘制。,6.2UML概述,返回,62,状态,状态的概念 状态的种类,6.2UML概述,返回,63,状态的概念,状态是对象执行了一系列活动的结果。所有对象都具有状态。当某个事件发生后,对象的状态将发生变化。,6.2UML概述,返回,64,状态的种类,状态图中定义的状态有: 初态（一个） 终态（一个或多个） 中间状态 复合状态,6.2UML概述,返回,65,中间状态,中间状态包括两个区域: 名字域 内部转移域 如下图所示。图中内部转移域是可选的 ,其中所列的动作将在对象处于该状态时执行,且该动作的执行并不改变对象的状态。,6.2UML概述,66,行为图状态图,6.2UML概述,返回,67,复合状态,概念 一个状态可以进一步地细化为多个子状态,我们将可以进一步细化的状态称作复合状态。 子状态之间有“或”和“与”两种关系。 或关系(如图4)说明在某一时刻仅可到达一个子状态。 例如,一个处于行驶状态的汽车,在“行驶”这个复合状态中有向前和向后两个不同的子状态,在某一时刻汽车要么向前,要么向后。 与关系(如图5)说明复合状态中在某一时刻可同时到达多个子状态(称为并发子状态)。具有并发子状态的状态图称为并发状态图。,6.2UML概述,68,行为图状态图,6.2UML概述,返回,69,转移,转移 状态图中状态之间带箭头的实线被称为转移。状态的变迁通常是由事件触发的,此时应在转移上标出触发转移的事件表达式。如果转移上未标明事件,则表示在源状态的内部活动执行完毕后自动触发转移。见教材P150图6.5,6.2UML概述,返回,70,行为图交互图,交互图描述对象之间的消息传递，它又可分为顺序图与合作图两种形式。 顺序图强调对象之间消息传递的时间序。 合作图强调对象间的动态协作关系。,6.2UML概述,返回,71,行为图交互图顺序图,顺序图 顺序图存在两个轴:水平轴表示不同的对象,垂直轴表示时间。 顺序图中的对象用一个带有垂直虚线的矩形框表示,并标有对象名和类名。见教材P149图6.3。垂直虚线是对象的生命线,用于表示在某段时间内对象是存在的。对象间的通信通过在对象的生命线间画消息（要对消息进行编号）来表示。消息的箭头指明消息的类型(简单、异步或同步消息) P233图10.2 。具体类型即详情我们在第十章讲解。,6.2UML概述,返回,72,行为图交互图合作图,合作图 合作图(Collaboration Diagram)用于描述相互合作的对象间的交互关系和链接关系 。 虽然顺序图和合作图都用来描述对象间的交互关系,但侧重点不一样。顺序图着重体现交互的时间顺序,合作图则着重体现交互对象间的静态链接关系。 P-149图6.4 ，P-234图10.3,6.2UML概述,73,行为图交互图合作图,链接 对象间的链接关系类似于类图中的联系(但无多重性标志)。通过在对象间的链接上标志带有消息串的消息(简单、异步或同步消息)来表达对象间的消息传递。,6.2UML概述,74,行为图交互图合作图,消息流 在合作图的链接线上,可以用带有消息串的消息来描述对象间的交互。消息的箭头指明消息的流动方向。 消息串说明要发送的消息、消息的参数、消息的返回值以及消息的序列号（序列号可以表示时间顺序）等信息。P-149图6.4,6.2UML概述,返回,75,实现图,主要描述软件实现系统的组成和分布情况。实现图包括构件图和部署图。,6.2UML概述,返回,76,构件图,构件图描述软件实现系统中各组成部件以及它们之间的依赖关系。一个部件可能是一个资源描述文件。一个二进制文件或一个可执行文件。构件图主要用于理解和分析软件各部分之间的相互影响程度。,6.2UML概述,返回,77,实现图构件图,在一个简单的画图的C+程序中，包含3种类： main类(主程序类)放在main.cpp中； shape类(基类)放在Shape.cpp中。 派生类 如：由shape类派生如下几种类 Line类(画线)放在Line.cpp中 Triangle类(画三角形)放在Triangle.cpp中， Square类(画正方形)放在Square.cpp中， Rectangle类(画矩形)放在Rectangle.cpp中。 把编译、链接和执行时上述程序组件之间的依赖关系放在一张组件图中，如下图所示。,6.2UML概述,78,6.2UML概述,从图中可以看出，maincpp的编译依赖于Shape.cpp、Line.cpp、Triangle.cpp、Square.cpp和Rectangle.cpp。,返回,79,实现图部署图,部署图描述作为软件系统运行环境的硬件、网络的物理体系结构，其节点表示实际的计算机和设备，边表示节点之间的物理连接关系，也可表示连接的类型及节点之间的依赖性。见下图：,6.2UML概述,返回,80,6.2.2 基于UML的软件开发过程,UML能够在几乎任何一种软件开发过程中使用。 下图，表示了一种迭代的渐进式软件开发过程，它包含四个阶段：初启，细化，构造和移交。,6.2UML概述,81,1 初启,在初启阶段，软件项目的发起人确定项目的主要目标和范围，并进行初步的可行性分析和经济效益分析。,6.2UML概述,返回,82,2 细化,工作内容 在此阶段需要完成以下工作： 初步的需求分析 初步的高层设计 部分的详细设计 部分的原型构造 结束条件,6.2UML概述,返回,83,初步的需求分析,用例图的使用 描述所有比较重要、比较有风险的用例 类图的使用 应用领域中的概念及概念之间的关系。这些相互关联的概念构成领域模型。 活动图的使用 如果领域中含有明显的流程处理成分，可以考虑利用UML的活动图来刻画领域中的工作流，并标识业务流程中的并发、同步等特征。,6.2UML概述,返回,84,初步的高层设计,对象： 规模比较庞大的软件系统 困难： 用例、类将非常多 解决途径： 包图,6.2UML概述,返回,85,部分的详细设计,可以用两种UML图形来设计： 交互图 对于系统中某些重要的、或者风险比较高的用例，可以采用交互图进一步探讨其内部实现过程。 类图 对于系统中的关键类，也可以详细研究其属性和操作，并在UML类图中加以表现。,6.2UML概述,返回,86,为了构造原型，需要针对用例生成详尽的交互图，对所有相关类给出明确的属性和操作定义。,部分的原型构造,6.2UML概述,返回,87,要满足以下三点： 所有主要的用户需求已通过用例和用例图得以描述； 所有重要的风险已被标识，并对风险应对措施了如指掌； 能够比较精确地估算实现每一用例的时间。,细化阶段的结束条件,6.2UML概述,返回,88,3 构造,多次迭代 好处 用户可以及早，降低开发风险 制定迭代计划的原则 注意事项 可能使用的UML语言机制,6.2UML概述,返回,89,计划的制定原则,计划的制定需遵循两项原则： （1）用户认为业务价值较大的用例应优先安排。 （2）开发人员评估后认为开发风险较高的用例应优先安排。,6.2UML概述,返回,90,注意事项,在迭代计划中，要确定迭代次数、每次迭代所需时间，以及每次迭代中应完成（或部分完成）的用例。 每次迭代过程有针对用例的分析、设计、编码、测试、集成共5个子阶段构成。,6.2UML概述,返回,91,构造阶段可能使用的UML语言机制,（1）用例及用例图。它们是开发人员在构造阶段进行分析和设计的基础。 （2）类图。在领域概念模型的基础上引进为软件实现所必需的类、属性和方法。 （3）交互图：表示针对用例设计的软件实现方法。 （4）状态图：表示类的对象的状态事件响应行为。 （5）活动图：表示复杂的算法过程，尤其是过程中的并发和同步。 （6）包图：表示目标软件系统的顶层结构。 （7）构件图。 （8）部署图。,6.2UML概述,返回,92,4 移交,在移交阶段，开发人员对构造阶段获得的软件系统在用户实际工作环境（或接近实际的模拟环境）中试运行，根据用户的修改意见进行少量调整。,6.2UML概述,返回,93,6.3 基于UML的需求分析,初步业务需求描述形成后，基于UML的需求分析分为以下两个可并行的步骤：见下图 利用用例及用例图表示需求 总体框架结构的表示,第六章 面向对象的需求分析,94,需求分析过程,6.3基于UML的需求分析,返回,95,利用用例及用例图表示需求,获取执行者和场景 形成用例 生成用例图,返回,96,6.3.1 开发场景,场景定义 场景描述 示例 场景的分类 场景的获取,6.3基于UML的需求分析,返回,97,定义,场景是从单个执行者的角度观察目标软件系统的功能和外部行为，是用例的实例，而用例是某类场景的共同抽象。,6.3基于UML的需求分析,返回,98,描述,对场景的完整描述包含场景名称、执行者实例、前置条件、事件流和后置条件。,6.3基于UML的需求分析,返回,99,学校的网上选课系统的需求,学校的网上选课系统主要包括如下功能：管理员通过系统管理界面进入，建立本学期要开的各种课程、将课程信息保存在数据库中并可以对课程进行改动和删除。学生通过客户机浏览器，根据学号和密码进入选课界面，在这里学生可以进行三种操作：查询已选课程、选课以及付费。同样，通过业务层，这些操作结果存入数据库中。,6.3基于UML的需求分析,100,学校的网上选课系统的分析,本系统拟使用Java语言通过三层模型实现：数据核心层、业务逻辑层和接入层。其中，数据核心层包括对于数据库的操作；业务逻辑层作为中间层对用户输入进行逻辑处理，再映射到相应的数据层操作；而接入层包括用户界面，包括系统登录界面、管理界面、用户选课界面等。 本系统涉及的用户包括管理员(Registrar)和学生(student)，他们是用例图中的活动者，他们的主要特征相似，都具有姓名和学号等信息，所以可以抽象出“基”活动者People，而Registrar和 Student则从People统一派生。数据库管理系统是另外一个活动者。,6.3基于UML的需求分析,101,网上选课系统场景的描述,从执行者“管理员”来看有场景：“添加课程”、“修改课程”、“删除课程” 从执行者“学生”来看有场景：“选课”、“查询”、“付费”。,6.3基于UML的需求分析,102,网上选课系统场景的描述,场景名称：添加课程 参与执行者：“管理员”、“数据库管理系统” 前置条件：已开机 事件流： (1)管理员选择进入管理界面，用例开始。 (2)系统提示输入管理员密码 (3)管理员输入密码。 (4)系统验证密码。 A1：密码错误 (5)进入管理界面，系统显示目前所建立的全部课程信息 (6)管理员选择添加课程,6.3基于UML的需求分析,103,网上选课系统场景的描述,(7)系统提示输入新课程信息 (8)管理员输入信息。 (9)系统验证是否和已有课程 A2：有冲突 (10）系统添加新课程，提示课程添加成功。 (11)系统重新进入管理主界面，显示所有课程。 (12)用例结束。 其他事件流： A1：密码错误 (1)系统提示再次输入。 (2)用户确认。 (3)三次错误，拒绝再次访问。 (4)否则进入添加课程事件流第5步。,6.3基于UML的需求分析,104,网上选课系统场景的描述,A2：有冲突 (1)系统提示冲突，显示冲突课程信息 (2)用户重新输入。 (3)继续验证直到无冲突。 (4)进入添加课程事件流第10步。 后置条件：处于可查询状态,6.3基于UML的需求分析,返回,105,场景的分类,实际场景 对实际的业务处理流程或其优化流程的描述，是用户需求的重要组成部分。 设想场景 分析人员对目标软件系统投入应用后经改进或优化的业务流程的描述。 评价场景 确认需求或提出改进建议为主要目的的业务流程描述。评价场景可以在用例生成后对用例进行实例化而形成，以便用户对用例进行评价或改进。 培训场景：面向开发人员及用户解释系统的功能和外部行为的业务流程描述。,6.3基于UML的需求分析,返回,106,场景的获取,确定执行者和场景的关键在于理解业务领域和初步需求描述文档。下列问题的回答可帮助分析人员获取场景： （1）目标软件系统有哪些执行者？ （2）执行者希望系统执行的任务有哪些？ （3）执行者希望获得哪些信息？这些信息由谁生成？由谁修改？ （4）执行者需要通知系统哪些事件？系统响应这些事件时会表现出哪些外部行为？ （5）系统将通告执行者哪些事件？,6.3基于UML的需求分析,返回,107,6