UML系统建模与分析设计.ppt

软件工程方法 需求分析与用例建模 1 客户需求分析与用例建模 用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。 用例驱动是统一过程的重要概念，或者说整个软件生产过程就是用例驱动的。分析、设计、实现、测试都是用例驱动的，都是以实现用例为目标。 在这些开发过程中，开发人员首先捕获客户的需求，并以用例的形式组织成用例模型。然后分析并设计系统来满足这些用例，因此在用例模型之后就是分析模型，接着是设计模型和实施模型。在实现了整个系统之后，还将根据用例模型设计出测试模型来对系统进行验证。 这些模型之间并不是线性转变的，它们是一个迭代、增量的开发过程。也就是在整个项目开发周期中，将会多次经过这五个模型的迭代，每次都将越来越精化。 用例模型描述的是外部执行者(Actor)所理解的系统功能。它描述了待开发系统的功能需求。 它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系统,从而影响到开发工作的各个阶段和 UML 的各个模型。 用例模型由若干个用例图构成，用例图中主要描述执行者和用例之间的关系。在UML中,构成用例图的主要元素是用例和执行者及其它们之间的联系。 用例建模的步骤： 1.4 确定执行者（参与者，角色） 执行者（actor）是指在系统外部与系统交互的人或其他系统，它以某种方式参与了系统内用例的执行。角色在UML中通常以一个稻草人图符来表示。 执行者类型：参与者不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟 ：1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中，银行后台系统就是一个参与者；2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系统时，IC卡读写器就是一个参与者；3）时钟：当系统需要定时触发时，时钟就是参与者 角色与系统交互：角色向系统发送消息、从系统接受消息、或是与系统交换信息。 角色与用例：角色往往是发现新用例的基础，同时也是分析员和用户交流的起点。一个执行者可用启动多个用例，而一个用例也可以被多个执行者启动。 1.寻找和确定执行者 通过向用户提问来识别角色： 谁使用系统提供的主要功能？（主要角色） 谁来维护、管理系统？（次要角色） 谁需要借助于系统完成日常工作任务？ 系统需要控制的硬件设备有哪些？ 系统需要与其他哪些系统交互？ 系统从哪儿得到信息？ 对系统产生的结果感兴趣的人或事是哪些？ ！不能把目光只专著于人身上。 2.定义执行者时应该注意的问题 1）执行者之间可以有继承关系 （2）执行者代表一种角色而不是具体某个人 （3）对同一个人担任角色的限制 （4）执行者可分成主执行者和副执行者 （5）执行者还可细分为主动执行者和被动执行者 1.5 确定用例 用例，就是一件事情，要完成这件事情，需要做一系列的活动；而做一件事情可以有很多不同的方法和步骤，也可能会遇到各种各样的意外情况，因此这件事情是由很多不同情况的集合构成的，在UML中我们称之为场景。一个场景就是一个用例的实例。 从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。在UML中,用例被定义成系统执行的一系列动作（功能）。 1.用例的特征 响应性。一个用例不自动执行，总是有执行者启动。 这件事必须由一个执行者发起，执行者的愿望是用例存在的原因。不存在没有执行者的用例，也不应该主动启动另一个用例。 回执性。 用例执行完毕，向执行者提供可识别的返回值。用例的执行结果对参与者来说是可观测的和有意义的。 如，系统会监控参与者在系统里的操作，并在参与者删除数据之前备份。虽然它是系统的一个必需组成部分，但它在需求阶段却不应该作为用例出现。因为这是一个后台进程，对参与者来说是不可观测的，它应该在系统用例分析阶段定义。 又比如，登录系统是一个有效的用例，但输入密码却不是。这是因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权，但输入密码却是没有意义的，输入完了呢？有什么结果吗？ 完整性。 用例表示一个完整的功能，必须是一完整的描述。 必须以向执行者提供返回值作为该用例完整性的标志。 用例的特征-动宾短语 用例必然是以动宾短语形式出现的。即，这件事必须有一个动作和动作的受体。 例如，喝水是一个有效的用例，而“喝”和“水”却不是。虽然生活常识告诉我们，在没有水的情况下人是不会做出喝这个动作的，水也必然是喝进去的，而不是滑进去的. 但是我们所见的很多用例中类似“计算”，“统计”，“报表”，“输出”，“录入”之类的并不在少数。 2．寻找和确定用例 业务用例：开始阶段，在确定用户需求过程中，系