uml与面向对象系统分析与设计与java8

249概念设计:UML用户需求描述方法基于用例的方法usecaseUML用例分析250系统发展生命周期分析设计计划Planning可行性研究FeasibilityStudy(optional)需求确定RequirementsDetermination概念设计ConceptualDesign物理设计PhysicalDesign构建ConstructionPurchase(prototype)培训Training转化Conversion-oldtonewImplementation实施Evolution进化UML用例分析251REQUIREMENTS需求DETERMINATION确定Anactivityusedtodeterminewhatis“in”andwhatis“out”!通俗的说是一种决定什么“内”与什么是“外”的问题的一种活动问题域的详细内容需求确定问题域的精确描述UML用例分析252需求分析?在软件工程中，需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围和定义时所要做的所有的工作。需求分析是软件工程中的一个关键过程。UML用例分析253获取用户需求的过程UML用例分析254需求分析涉众分析需求来自于用户，不论是用什么方法，首先应是找到我们需要访问的对象，然后对对象进行分类，再逐步对对象进行访问。具体访问过程中可以针对不同的访问对象采用不同的方法，根据访问的内容进行确定。本文要讨论的是，如何确定我们的访问对象，以及如何对确定用户对象进行调查。1of2UML用例分析255识别用户第一步是找出系统的未来推进者。第二步是把握系统的整体流程第三步找出真正的用户。UML用例分析256需求分析第四步掌握一手资料。第五步协助用户进行流程重组。第六步正确理解需求列表。2of2UML用例分析257实践证明，用例技术是迄今为止最为深刻、准确和有效的系统功能需求描述方法。基于USECASE的需求分析UML用例分析258为什么使用UsecaseUML用例分析259Usecase定义jacobson强调用例是系统执行的一个动作序列（注：这其中也包括与用户的交互），这些动作必须对某个特定的使用者（Actor）产生可观测的、有价值的结果。UML用例分析260那么到底什么结果叫“可观测、有价值”呢？它首先强调用例是各种系统受益人（Stakeholder）之间的一种行为契约（注：行为包括对象的活动、动作和对象之间的交互等），建立契约的目的是为了达成某种目标，因此每一个用例及其名称实际上都应代表一个用户目标，这个目标是否得到真正满足正是判断我们抽取的某个用例是否“有价值”的关键。通过用例的具体执行来展现Actor的目标是如何实现或失败的，而一个用例其实就是多个在不同条件下执行并可能导致许多不同后续状态的情节（scenario，又译“场景”）的叠加，这就是用例结果的“可观测”。因此综合起来，我们只要抓住这样几个关键词：目标、行为契约、行为(事件)序列（动作和交互）、情节、可观测、有价值，就可以比较准确地描述出用例的本质特征。UML用例分析261Actor(使用者)常见的翻译包括“参与者、执行者、主角”等等。“参与者、执行者”的问题主要是不准确。首先，“参与者”通常让大家马上想到的词是participant，而且请注意，一个用例的真正参与者决不是只有外部的Actor，它们必然还包括系统本身及其内部的各种元素。“执行者”的问题与此类似：一个用例的真正执行者应该是系统本身！因此严格地讲这样译是错误的，兴许叫作“外部参与者”、“外部执行者”才更为恰当。“主角”的译法同样存在着矛盾。如果把Actor叫作“主角”，那么PrimaryActor就应该叫作“主主角”了。看来Actor的译法中是不能含有“主”的，那么就剩下“角”了，而UML已经有了一个专门术语role（角色），我们又不能把Actor直接叫作“角色是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此使用者可以是人，可以是事物，也可以是时间或其他系统等等。UML用例分析262UML用例分析263系统边界系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。UML用例分析264箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。UML用例分析265前台客户系统的用例图家教网站用例图的画法和用例描述的写法UML用例分析266后台管理系统用例图UML用例分析267用例描述用例图只是简单地用图描述了一下系统，但对于每个用例，我们还需要有详细的说明，这样就可以让别人对这个系统有一个更加详细的了解，这时我们就需要写用例描述。对于用例描述的内容，一般没有硬性规定的格式，但一些必须或者重要的内容还是必须要写进用例描述里面的。用例描述一般包括：简要描述（说明）、前置（前提）条件、基本事件流、其他事件流、异常事件流、后置（事后）条件等等。下面说说各个部分的意思：简要描述：对用例的角色、目的的简要描述；前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件；基本事件流：描述该用例的基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流和异常流，而只有最有可能发生的事件流；其他事件流：表示这个行为或流程是可选的或备选的，并不是总要总要执行它们；异常事件流：表示发生了某些非正常的事情所要执行的流程；后置条件：用例一旦执行后系统所处的状态；UML用例分析268：用例名称：网站公告发布用例标识号：202参与者：负责人简要说明：负责人用来填写和修改家教网站首页的公告，公告最终显示在家教网站的首页上。前置条件：负责人已经登陆家教网站管理系统基本事件流：1．负责人鼠标点击“修改公告”按钮2．系统出现一个文本框，显示着原来的公告内容3．负责人可以在文本框上修改公告，也可以完全删除，重新写新的公告4．负责人编辑完文本框，按“提交”按钮，首页公告就被修改5．用例终止其他事件流A1：在按“提交”按钮之前，负责人随时可以按“返回”按钮，文本框的任何修改内容都不会影响网站首页的公告异常事件流：1．提示错误信息，负责人确认2．返回到管理系统主页面后置条件：网站首页的公告信息被修改注释：无UML用例分析269JAVA学习内容JAVA核心类（输入＼输出，collection，JAVA国际化等）java多线程javaGui设计与java多媒体java与数据库J2EE编程与java架构J2ME