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