J2EE项目实训UML及设计模式——第1章 获得和描述项目的需求(第3部分)

J2EE项目实训UML及设计模式——第1章获得和描述项目的需求(第3部分)第1章获得和描述项目的需求（第3/4部分）1.1描述项目的需求1.1.1利用用例图实现对项目的需求进行建模1、面向过程的需求分析中采用系统功能结构图来表达功能间的关系在面向过程的需求分析中，是采用功能结构图的方式来描述软件系统中的功能。因为结构化方法是一种基于功能分解的分析方法，并且采用自上向下地分解或分层。在结构化方法中首先要定义出需要哪些功能程序模块，每个程序模块应该实现哪些功能，然后按照某种方式把整个软件系统的各个程序模块组织成一张图，该图称为功能结构图。下面的图1.2所示为某个BBS论坛系统项目中的功能结构图，分层框图把系统中的各种功能模块用多层方框按照树形结构组织起来。在结构图的顶层，用一个方框代表整个系统结构。下面各层由表示不同功能模块类别的方框组成，它们可以看成是上一层方框的子集。在该图的最低一层中的每个框包含单独的功能模块。图1.2某个BBS论坛系统项目中的功能结构图2、用例及用例图产生的技术背景（1）准确地捕获和描述软件项目功能方面的需求在软件系统的需求分析中，必须要了解并准确描述出软件项目的功能方面的需求，以便于确定并建立出所需要的类。因为开发者在系统开发时必须要了解并准确地描述出用户的各个方面的需求，这包括功能、非功能以及环境的约束等方面需求。那开发者如何描述需求？采用什么形式？具体应该包含什么内容？所采用的方法能否避免常规的方法所带来的问题？（2）面向过程中常规的描述方法很长时间以来，无论是传统的软件开发方法还是面向对象的开发方法，都采用自然语言（如中文）来描述软件系统的需求。这样的方法有几个致命的缺陷。1)缺乏描述的形式化，随意性较大，常常产生理解上的含混及不确定性。因为自然语言的描述容易产生歧义；2)没有统一的格式，不能自动化地验证各种需求在逻辑上的合理性；3)不能保证需求文档与所编程实现的程序之间进行同步和一致性。（3）在面向对象的开发中可以采用UML用例模型方法在这种技术需求的背景下，有关专家提出了用例（UseCase）的概念及其图形表示方法的用例图，这种方法很快得到业界广泛的应用和认可。在软件项目开发的开始阶段，用例图的主要使用者是客户、项目的分析人员和项目管理人员。这些人员利用用例、用例图和使用需求说明书文档来确定系统的高层视图、并建立出软件系统的逻辑模型。3、面向对象的需求分析中采用用例图描述项目的功能在面向对象的需求分析中，对象、事件和响应成为了系统分析的主体，系统分析的着力点转向了系统中的各个对象之间的交互。但是，还是有相应的方法来描述系统的功能，这就是采用统一建模语言（UML）中的用例及用例图。在UML中，用面向对象进行系统建模的第一步是“用例”的分析，“用例”体现了软件系统的功能单元。软件系统的外部人员（也就是下面所要介绍的参与者）或其它系统通过和“用例”交换消息来了解和使用系统的功能。下面的图1.3所示为某个BBS论坛系统项目中的面向注册用户的各种留言信息操作的UML的用例图。图1.3某个BBS论坛系统项目中的面向注册用户的UML用例图（1）用例图的主要作用由于软件系统的使用者用户，一般都会有自己对软件系统所要求提供的业务功能的一个既定的目标，并且希望借助于所开发出的软件系统来帮助用户实现这些业务功能的目标。而UML中的用例就是表达如何使软件系统来达到这些目标的一种方式。用例图借助于其中的用例（UseCase）来描述“系统（System）”和“参与者（Actor）”之间的交互的系统行为；同时再通过分解软件系统的各个功能目标的具体实现过程，利用用例的事件流来描述参与者为了实现这些目标而必须执行的各个步骤或者活动过程。（2）用例建模方法最主要的优点首先在于它是用户导向的，用户可以根据自己所对应的用例来不断细化自己的需求；此外，使用用例还可以方便地得到系统功能的测试用例。当然，开发者也应该明确的是，用例仅能捕获和描述软件系统中的功能性需求，而不适合于捕获非功能性需求和设计约束等。因此，必须再辅助其它的手段来全面地描述软件系统中的各种形式的需求。（3）建立用例模型的目的●面向软件系统的使用者用户可以实现从用户角度来描述系统所应该具有的功能，同时并能够指出各功能的操作者；也能够显示出与系统进行交互的外部参与者及其使用方式。●面向软件系统的开发者表示正在构造的新系统应该具有的功能，同时对已经构造完毕的系统，则反映了系统能够完成什么样的功能。建立用例模型的目的则是帮助开发团队理解客户对系统的各种功能需求、各个功能之间的相互关系，这些功能是提供给系统中的哪些参与者的。4、UML用例模型的主要作用用例图是一种图形化的工具，它用简单的图形元素表示出软件系统的参与者、用例以及它们之间的联系。通过用例图能够较好地避免了软件系统在功能表达方面的歧义性，便于软件系统的最终用户和软件系统的开发人员共同理解系统的需求，取得一定的共识。（1）准确地表示软件系统的功能性的需求软件系统的开发者可以应用UML用例模型来表示软件系统的需求，然后以这些用例为基础来推动软件系统开发的其它方面的工作如设计、编程实现和测试等方面的工作开展。（2）连接软件系统的使用者用户与软件系统的功能性需求用例在软件系统的最终用户和软件系统的功能性需求之间建立起一个连接和桥梁，并且还可用来在软件的功能性需求和系统实现本身之间进行回溯。（3）作为一个连接点用例也可以作为一个连接点，连接到一个详细的说明需求细节的用例文档中。5、面向对象中的用例模型和面向过程中的功能分解方法的不同将项目分解成用例是个面向对象的过程而不是面向实现的过程，因此不同于面向过程中传统的功能分解法中所产生的系统功能结构图。功能分解法主要关注如何将一个复杂的系统分解成能处理的各个小功能模块或者子系统，而用例首先关注用户对系统的功能性的需求。因为在用例图中，不仅可以体现出各个用例，也还能够体现出各个用例之间的关系、用例与参与者之间的交互关系等方面的信息。所应该注意的是，面向对象的分析过程实际上是反复迭代的。各个步骤可能是以某种交织、迭代或并行的方式进行的。这是因为对于一个大型的软件系统的开发实现，是不可能一次性地完成对复杂软件系统中所需要的各种对象、类、消息等的识别和描述的。1.1.2UML中的用例和用例图1、用例模型的基本组成部件在用例模型的用例图中一般包含下面的三个组成元素：参与者、用例和系统边界，请见下面的图1.4所示。图1.4用例图中一般包含有参与者、用例和系统边界三个组成元素（1）参与者（Actor）参与者表示系统用户能扮演的某种角色(Role)，这些参与者可能有三大类：系统用户、与所建系统交互的其它系统、时间。因此，参与者不完全都是“人”！在UML的用例图中是用一个小人形状的图符表示，请见下面的图1.5所示的“用户”和“管理员”参与者的表示形式。1)系统用户：使用本软件系统的具体用户；2)其它系统：可能是其它的计算机或者一些硬件或者甚至是其它的软件系统；3)时间：时间作为参与者时，经过一定时间触发系统的某个事件。例如，ATM机可能每天午夜运行一些协调处理的功能程序。（2）用例（UseCase）及其定义用例是关于单个参与者在与软件系统对话中所执行的处理行为的陈述序列。它表达了系统的功能和所应该提供的服务；当然它描述了参与者给系统特定的刺激时软件系统所产生的活动，是参与者通过软件系统完成一个功能过程时出现的一组事件，最终以达到实现一种特定的业务功能。通常，用例侧重于功能，但不重点描述该功能的具体实现的细节；同时用例的大小划分一般以事件流在10个步骤左右为好。并且所有的用例必须始于参与者，而且有些用例也结束于参与者。在UML用例图中是用一个实线椭圆表示，并且用例的名称可以写在椭圆内部或者下面。具体请见下面的图1.5所示的各种用例的表示形式。（3）系统及系统边界系统代表的是一部机器或者一个商务活动等，而并不一定完全是真正所要实现的软件系统本身；系统的边界用来说明构建的用例模型的应用范围（用例应该在系统边界之内存在）。在UML用例图中，系统的表示形式是采用一个长方形框表示，系统的名字写在方框的上面或者方框内（但在RationalRose的工具中不需要画出系统边界）。下面的图1.5某个BBS论坛系统项目中的后台管理功能的UML用例图。图1.5某个BBS论坛系统项目中的后台管理功能的UML用例图2、用例模型中的参与者（1）参与者之间的关系可以为泛化（特化或者继承）关系由于参与者最终是类的对象实例，所以它拥有与类相同的继承关系描述，其UML的图示是用带空心三角形（箭头）的直线表示。下面的图1.6中所示为某个UML用例图中的注册用户的参与者和用户参与者之间存在泛化关系的图示。图1.6某个UML用例图中的注册用户和用户之间的关系图（2）如何获得软件系统中的各个参与者获取用例首先要找出软件系统中的各个参与者，但准确地识别出参与者也不是一件简单的事情，在需求整理的各种形式的沟通交流讨论会中，开发方的各个有关人员可以通过“头脑风暴”来获得主要参与者。或者可以通过根据用户回答的一些问题答案来识别参与者。以下的各个问题可供在识别出软件系统的参与者时进行参考:1)谁将使用本软件系统的主要功能，他们将是系统的主要参与者。2)谁需要系统支持或者辅助他们的日常工作，以减轻其劳动强度。3)谁来维护、管理使软件系统正常工作(辅助使用者)。谁来进行用户管理和安全管理？4)软件系统需要操纵哪些计算机硬件设备。5)软件系统需要与哪些其它软件系统进行交互或者通讯,这包括其它的计算机系统和其它的应用系统程序等。6)对软件系统产生的结果感兴趣的人或事物。7)是否存在一个监控系统，在系统错误的时候能够自动产生错误的警报？（3）获得软件系统中的参与者的示例在某个网上书店的应用系统中，根据本软件系统在具体应用时的要求，可能会有下面的各种类型的用户存在。这些用户将为本系统中的参与者。1)图书信息的浏览者(Visitor，没有进行购买行为的用户)2)图书的购买者（读者用户）3)收银员（如财务人员）4)管理员和超级管理员(Administrator，系统管理员)。其中的系统管理员负责软件系统的初始化工作、权限分配、图书购入维护等工作。而用户作为消费者使用本软件系统来查询以查找出所需要的各种图书的信息；而收银员使用销售系统根据消费者的类型（会员、非会员）负责相应的优惠收款。而在某个网上银行的应用系统中，同样根据系统在具体应用时的要求，可能会有个人用户、企业用户、银行职员、财务人员以及管理员和超级管理员(Administrator，系统管理员)等形式的人员存在。同样这些用户将成为本系统中的参与者。（4）所要注意的问题用例图中的参与者和用例之间的通信体现为参与者和用例之间的使用关系，在用例图中表示为一个带箭头的直线。1)参与者主要是指角色而非具体的个人，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。如“管理员”是角色，而“A管理员”则是具体的某个人。2)一个用户可以为多个参与者角色，如：张三即可以是网上书店的读者——读者角色，也可以是管理员；3)一个参与者可以包含多个不同的具体用户，如：网上书店的读者角色可以是张三和李四；发现参与者对提供用例是非常有用的，因为面对一个大系统要完整地罗列出用例清单，常常也是十分困难的。这时可先列出参与者清单，再对每个参与者列出与它相关的的各个用例，此时的问题的解决可能就会变得简单和容易。3、用例模型中的用例（1）用例的分类●业务用例（BusinessUseCase）主要是指软件系统所提供的业务功能与参与者之间的交互，表现问题领域中各实体间的联系和业务往来活动。比如报表处理系统中的数据汇总计算、网上商城系统中的“产生订单”、BBS论坛系统中的“发表BBS信息”等。因此，如果某个用例的范围包含了人以及由人组成的团队、部门、组织的活动，那么这个用例必然是业务用例。●系统用例（SystemUseCase）指软件系统的参与者与软件系统之间的交互，它表现了系统（仅仅是一些软件、硬件、机电设备或由它们组成的系统）的功