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

需求分析与用例建模;用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。 用例驱动是统一过程的重要概念，或者说整个软件生产过程就是用例驱动的。分析、设计、实现、测试都是用例驱动的，都是以实现用例为目标。 在这些开发过程中，开发人员首先捕获客户的需求，并以用例的形式组织成用例模型。然后分析并设计系统来满足这些用例，因此在用例模型之后就是分析模型，接着是设计模型和实施模型。在实现了整个系统之后，还将根据用例模型设计出测试模型来对系统进行验证。 这些模型之间并不是线性转变的，它们是一个迭代、增量的开发过程。也就是在整个项目开发周期中，将会多次经过这五个模型的迭代，每次都将越来越精化。 ; 1.1 建造需求模型——用例建模 ;用例图中包含系统、角色和用例等三种模型元素，以及它们之间的关系。;用例模型描述的是外部执行者(Actor)所理解的系统功能。它描述了待开发系统的功能需求。 它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系统,从而影响到开发工作的各个阶段和 UML 的各个模型。 用例模型由若干个用例图构成，用例图中主要描述执行者和用例之间的关系。在UML中,构成用例图的主要元素是用例和执行者及其它们之间的联系。; 确定系统的范围和边界； 确定系统的执行者和用例； 对用例进行描述； 定义用例之间的关系； 审核用例模型。 ;1.2 用例图 ;1.3 定义系统的边界和范围 ;1.4 确定执行者（参与者，角色）;1.寻找和确定执行者;;;;2.定义执行者时应该注意的问题;（2）执行者代表一种角色而不是具体某个人 （3）对同一个人担任角色的限制 （4）执行者可分成主执行者和副执行者 （5）执行者还可细分为主动执行者和被动执行者 ;1.5 确定用例;1.用例的特征;回执性。 用例执行完毕，向执行者提供可识别的返回值。用例的执行结果对参与者来说是可观测的和有意义的。 如，系统会监控参与者在系统里的操作，并在参与者删除数据之前备份。虽然它是系统的一个必需组成部分，但它在需求阶段却不应该作为用例出现。因为这是一个后台进程，对参与者来说是不可观测的，它应该在系统用例分析阶段定义。 又比如，登录系统是一个有效的用例，但输入密码却不是。这是因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权，但输入密码却是没有意义的，输入完了呢？有什么结果吗？ ;完整性。 用例表示一个完整的功能，必须是一完整的描述。 必须以向执行者提供返回值作为该用例完整性的标志。 ;用例的特征-动宾短语 用例必然是以动宾短语形式出现的。即，这件事必须有一个动作和动作的受体。 例如，喝水是一个有效的用例，而“喝”和“水”却不是。虽然生活常识告诉我们，在没有水的情况下人是不会做出喝这个动作的，水也必然是喝进去的，而不是滑进去的. 但是我们所见的很多用例中类似“计算”，“统计”，“报表”，“输出”，“录入”之类的并不在少数。 ;2．寻找和确定用例;建立用例模型时，可询问？;通过与用户反复交流，确定主要业务用例和次要业务用例。 对于建立的每一个业务用例，都需要一组系统用例来辅助和支持。（不严谨） 系统用例是执行者与系统的交互，它描述了系统的功能需求和动态行为。 系统用例用于建立系统用例模型，可通过分析系统的业务流和控制流来寻找和确定系统用例。（活动图） ;如何获得用例——访谈;目标和步骤的误区;怎样确定用例的粒度？;ATM取钱的场景中，取钱，读卡，验证账号，打印回执单等都是可能的用例？ 客户代表说：我希望这台ATM能支持跨行业务，我插入卡片输入密码后，可以让我选择是取钱还是存钱；为了方便，可以设置一些默认的存取金额按钮；我可以修改密码，也可以挂失；还有我希望可以交纳水费、电费和电话等费用；为了安全起见，ATM上应当有警示小心骗子的提示条，还有摄像头；如果输入三次密码错误，卡片应当被自动吞没。 ;判断题;支持跨行业务 错，这是一个业务规则，限定业务的范围 插入卡片 错，这是一个过程步骤，不是完整目标 输入密码 错，这是一个过程步骤，不是完整目标 选择服务 错，这是一个过程步骤，不是完整目标 取钱 对，这是一个完整有效的目标 存钱 对，这是一个完整有效的目标 挂失卡片 对，这是一个完整有效的目标 交纳费用 对，这是一个完整有效的目标 警示骗子 错，已超出了边界范围 三次错误吞没卡片 错，这是一个业务规则，限定业务的范围 ;3.描述用例;用例文字描述; 用例编号:001