面向对象分析与设计第7章.pptx

《面向对象分析与设计第7章.pptx》由会员分享，可在线阅读，更多相关《面向对象分析与设计第7章.pptx（74页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、1第7章 理解需求对象是系统中用来描述客观事物的一个实体，它是构成系统的一个基本单位，有一组属性和对这组属性进行操作的服务。类是具有相同属性和相同服务的一组对象的集合，它为属于该类的全部对象提供了统一的抽象描述，其中包括属性和服务两个主要部分。第1页/共74页2第2页/共74页37.1收集需求需求阶段的目标又两个：检查业务上下文：首先需要弄清楚开发软件的原因如果没有好的理由，就不应编写软件。在决定开发软件系统后，就需要理解业务，对业务的理解应与客户的理解相同。描述系统需求：这不仅要决定系统的功能，还要找出所有的约束条件：性能、开发成本、资源等第3页/共74页46.1收集需求研究问题域和用户需求

2、研究用户需求明确系统责任系统的需求包括四个不同层次：业务需求、用户需求、功能需求和非功能性需求。分析员开始一项分析工作首先要研究用户需求，要搞清楚到底要开发什么样的系统。包括：系统需要提供哪些功能，系统的边界在哪里，要达到何种性能指标以及可靠性、安全性要求。人机交互要求等第4页/共74页5收集需求研究问题域和用户需求包括以下活动：阅读相关文档与用户交流进行实地调查记录所得认识整理相关资料认真听取问题域专家的见解借鉴他人经验第5页/共74页66.2确定系统边界确定系统边界，就是明确系统是什么以及系统的环境是什么,划出被开发的系统和与该系统打交道的人或物之间的明确界限，并确定它们之间的接口。认识系

3、统边界的目的是为了明确系统的范围以及与外部世界的接口。第6页/共74页76.3用例描述Ivar Jacobson发明了用例，以定义部分业务或系统的使用方式，它是描述系统功能需求的高效工具。用例开始于一个参与者（actor），之后是业务或系统，最后返回到参与者。用例不是业务建模的唯一方式，比较复杂的方法有业务过程建模和工作流分析，用例比较简单。第7页/共74页86.3用例描述第8页/共74页96.3用例描述第9页/共74页106.4根据需求寻找类第10页/共74页11第11页/共74页12根据需求寻找类商店汽车条形码柜台终端激光阅读器助手客户会员（特殊客户）预约交付收回第12页/共74页13第1

4、3页/共74页146.5 业务分析1、标识业务参与者参与者是在业务中扮演某个角色的人、部门、外部设备或独立的软件系统,标识参与者有助于标识业务的使用方式，这有助于表示用例的含义。第14页/共74页156.5 业务分析2、编写项目术语表第15页/共74页16本课程使用的术语第16页/共74页176.5 业务分析3 标识业务用例第17页/共74页186.6用例模型需求分析的第二步是给要开发的软件建模，以改进业务。域模型用例模型业务过程模型工作流分析系统的用例模型比业务的用例模型更详细、更具说明性。第18页/共74页196.6用例模型对于Ripple，系统用例模型包括参与者列表（带有描述）用例列表（

5、带有描述）用例图用例细节表（包括所有相关的非功能需求）用例调查辅助需求用例的优先级改进的术语表用户界面草图（可选，可放在具体的设计阶段考虑）第19页/共74页206.6用例模型1、标识系统参与者这个阶段标识的参与者应只包括直接与系统交互的人（和外部系统），而不包括更宽泛的业务环境中的参与者第20页/共74页216.6用例模型A、参与者列表第21页/共74页226.6用例模型2、标识系统用例一旦有了参与者，就可以查找用例，每个用例都必须有简短说明。思考用例？第22页/共74页236.6用例模型第23页/共74页24第24页/共74页256.6用例模型3、用例的关系除了参与者之间的特殊化以及和用例

6、之间的关系之外。用例之间还有三种关系：特殊化（specialize）包含（include）扩展（extend）这些关系可以组合相关的用例，分解大的用例，重用行为，指定可选行为。第25页/共74页266.6用例模型特殊化：与参与者一样，用例也可以相互继承。为了避免重新定义步骤和添加额外的步骤，可以只特殊化抽象的用例。纯抽象用例根本没有步骤，其唯一的目的是组合其它用例。包含：如果第一个用例有一些第二个用例提供的步骤，该用例就包含第二个用例。包含关系显示为箭头开放的虚线，从包含的用例指向被包含的用例，并标记扩展：第一个用例给第二个用例增加步骤，就称为扩展第二个用例，扩展关系可以增加可选的额外步骤.扩

7、展关系显示为箭头开放的虚线，从扩展的用例指向被扩展用例，并标记第26页/共74页276.6用例模型第27页/共74页286.6用例模型B、用例列表第28页/共74页296.6用例模型C、用例图第29页/共74页306.6用例模型4、系统用例的细节第30页/共74页316.6用例模型D、用例的细节列表第31页/共74页326.6用例模型5、前置条件与后置条件 前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件；后置条件：用例一旦执行后系统所处的状态；第32页/共74页336.6用例模型6、辅助需求在大多数情况下，可以把非功能需求关联到特定的用例上。不适合任何用例的非功能需求可以记录在辅

8、助需求文档中。第33页/共74页346.6用例模型7、用例的优先级最好按照实现的优先级给系统需求分级，尤其在递增开发过程中，就更应分级。在用例建模过程中，显然应给用例分级，然后给每个用例打分，表示其紧急程度。优先级和紧急程度有助于规划其它开发过程和近一步的递增开发过程。第34页/共74页356.6用例模型有效的打分技术是交通灯（traffic light）绿色（Green）的用例必须当前的递增开发过程中实现。黄色（Amber）的用例在当前递增开发过程中是可选的，只有完成了绿色的用例之后才能尝试完成它。红色（Red）的用例即时当前时间允许，也不在当前的递增开发过程中实现。第35页/共74页36补

9、充参考内容用例建模指南作者：傅纯一 来源：IBM第36页/共74页37Use Case Modeling 用例建模（Use Case Modeling）是使用用例的方法来描述系统的功能需求的过程，用例模型主要包括以下两部分内容：用例图(Use Case Diagram)确定系统中所包含的参与者、用例和两者之间的对应关系，用例图描述的是关于系统功能的一个概述用例规约(Use Case Specification)针对每一个用例都应该有一个用例规约文档与之相对应，该文档描述用例的细节内容。第37页/共74页38Use Case Modeling在用例建模的过程中，我们建议的步聚是先找出参与者，再根

10、据参与者确定每个参与者相关的用例，最后再细化每一个用例的用例规约。用例描述用来详细描述用例图中每个用例，用文本文档来完成。第38页/共74页39一.用例图一.用例图(Use Case Diagram)用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理

11、，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。第39页/共74页40一.用例图用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是UML对用例的正式定义，对我们初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。第40页/共74页41一.用例图系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，

12、边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。第41页/共74页42二.用例规约二.用例规约(Use Case Specification)用例图只是简单地用图描述了一下系统，但对于每个用例，我们还需要有详细的说明，这样就可以让别人对这个系统有一个更加详细的了解，这时我们就需要写用例描述。对于用例描述的内容，一

13、般没有硬性规定的格式，但一些必须或者重要的内容还是必须要写进用例描述里面的。用例描述一般包括：简要描述（说明）、前置（前提）条件、基本事件流、其他事件流、异常事件流、后置（事后）条件等等。下面说说各个部分的意思：第42页/共74页43二.用例规约简要描述：对用例的角色、目的的简要描述；前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件；基本事件流：描述该用例的基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流和异常流，而只有最有可能发生的事件流；其他事件流：表示这个行为或流程是可选的或备选的，并不是总要总要执行它们；异常事件流：表示发生了某些非正常的事情所要执行的流程；

14、后置条件：用例一旦执行后系统所处的状态；第43页/共74页44三 用例图和用例描述设计实例三 用例图和用例描述设计实例里用我开发的一个家教网站来简单的分析用例图的画法和用例描述的写法。这个网站我用UML完整的分析一下，以下我提取了用例图和用例描述的部分。这个家教网站分为前台客户系统和后台管理系统。后台管理系统用例图如下：第44页/共74页45后台管理系统用例图第45页/共74页46对于用例描述第46页/共74页47对于用例描述第47页/共74页48四、用例建模的步聚四、用例建模的步聚在用例建模的过程中，我们建议的步聚是先找出参与者，再根据参与者确定每个参与者相关的用例，最后再细化每一个用例的用

15、例规约。1、寻找参与者 所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。通俗地讲，参与者就是我们所要定义系统的使用者。寻找参与者可以从以下问题入手：第48页/共74页49寻找参与者 系统开发完成之后，有哪些人会使用这个系统？系统需要从哪些人或其他系统中获得数据？系统会为哪些人或其他系统提供数据？系统会与哪些其他系统相关联？系统是由谁来维护和管理的？第49页/共74页50些问题有助于我们抽象出系统的参与者。对于ATM机的例子，回答这些问题可以使我们找到更多的参与者：操作员负责维护和管理ATM机系统、ATM机也需要与后台服务器进行通讯以获得有关用户帐号的相关信息。第50页/共74

16、页511.1 系统边界决定了参与者参与者是由系统的边界所决定的，如果我们所要定义的系统边界仅限于ATM机本身，那么后台服务器就是一个外部的系统，可以抽象为一个参与者。第51页/共74页52如果我们所要定义的系统边界扩大至整个银行系统，ATM机和后台服务器都是整个银行系统的一部分，这时候后台服务器就不再被抽象成为一个参与者。第52页/共74页53值得注意的是，用例建模时不要将一些系统的组成结构作为参与者来进行抽象，如在ATM机系统中，打印机只是系统的一个组成部分，不应将它抽象成一个独立的参与者；在一个MIS管理系统中，数据库系统往往只作为系统的一个组成部分，一般不将其单独抽象成一个参与者。第53

17、页/共74页541.2 特殊的参与者系统时钟有时候我们需要在系统内部定时地执行一些操作，如检测系统资源使用情况、定期地生成统计报表等等。从表面上看，这些操作并不是由外部的人或系统触发的，应该怎样用用例方法来表述这一类功能需求呢？对于这种情况，我们可以抽象出一个系统时钟或定时器参与者，利用该参与者来触发这一类定时操作。从逻辑上，这一参与者应该被理解成是系统外部的，由它来触发系统所提供的用例对话。第54页/共74页552、确定用例2、确定用例找到参与者之后，我们就可以根据参与者来确定系统的用例，主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的。寻找用例可以从以下问题入手（针对

18、每一个参与者）：参与者为什么要使用该系统？参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？参与者是否会将外部的某些事件通知给该系统？系统是否会将内部的某些事件通知该参与者？综合以上所述，ATM系统的用例图可表示如下，第55页/共74页56第56页/共74页57在用例的抽取过程中，必须注意：用例必须是由某一个主角触发而产生的活动，即每个用例至少应该涉及一个主角。如果存在与主角不进行交互的用例，就可以考虑将其并入其他用例；或者是检查该用例相对应的参与者是否被遗漏，如果是，则补上该参与者。反之，每个参与者也必须至少涉及到一个用例，如果发现有不与任何用

19、例相关联的参与者存在，就应该考虑该参与者是如何与系统发生对话的，或者由参与者确定一个新的用例，或者该参与者是一个多余的模型元素，应该将其删除。第57页/共74页58可视化建模的主要目的之一就是要增强团队的沟通，用例模型必须是易于理解的。用例建模往往是一个团队开发的过程，系统分析员在建模过程中必须注意参与者和用例的名称应该符合一定的命名约定，这样整个用例模型才能够符合一定的风格。如参与者的名称一般都是名词，用例名称一般都是动宾词组等。第58页/共74页59对于同一个系统，不同的人对于 参与者和用例都可能有不同的抽象结果，因而得到不同的用例模型。我们需要在多个用例模型方案中选择一种最佳（或较佳）的

20、结果，一个好的用例模型应该能够容易被不同的涉众所理解，并且不同的涉众对于同一用例模型的理解应该是一致的。第59页/共74页60 3、描述用例规约应该避免这样一种误解认为由参与者和用例构成的用例图就是用例模型，用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有一个总体的认识。除此之外，我们还需要描述每一个有例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每一个用例的详细描述用例规约所组成的。RUP中提供了用例规约的模板，每一个用例的用例规约都应该包含以下内容：第60页/共74页61简要说明(Brief Description)简要介绍该用例的作用和目的。事件流

21、(Flow of Event)包括基本流和备选流，事件流应该表示出所有的场景。用例场景(Use-Case Scenario)包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。第61页/共74页62特殊需求(Special Requirement)描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。前置条件(Pre-Condition)执行用例之前系统必须所处的状态。后置条件(Post-Condition)用例执行完毕后系统可能处于的一组状态。第62页/共74页63用例规约基本上是用文本方式来表述的，为了更加清晰地描述事件

22、流，也可以选择使用状态图、活动图或序列图来辅助说明。只要有助于表达的简洁明了，就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。如活动图有助于描述复杂的决策流程，状态转移图有助于描述与状态相关的系统行为，序列图适合于描述基于时间顺序的消息传递。第63页/共74页643.1 基本流3.1 基本流基本流描述的是该用例最正常的一种场景，在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。我们建议用以下格式来描述基本流：(1)每一个步骤都需要用数字编号以清楚地标明步骤的先后顺序。(2)用一句简短的标题来概括每一步骤的主要内容，这样阅读者可以通过浏览标题来快速地了解用例的主要步

23、骤。在用例建模的早期，我们也只需要描述到事件流步骤标题这一层，以免过早地陷入到用例描述的细节中去。第64页/共74页65(3)当整个用例模型基本稳定之后，我们再针对每一步骤详细描述参与者和系统之间所发生的交互。建议采用双向(roundtrip)描述法来保证描述的完整性，即每一步骤都需要从正反两个方面来描述:(1)参与者向系统提交了什么信息；(2)对此系统有什么样的响应。具体例子请参见附录。在描述参与者和系统之间的信息交换时，需指出来回传递的具体信息。例如，只表述参与者输入了客户信息就不够明确，最好明确地说参与者输入了客户姓名和地址。通常可以利用词汇表让用例的复杂性保持在可控范围内，可以在词汇表

24、中定义客户信息等内容，使用例不至于陷入过多的细节。第65页/共74页663.2 备选流备选流负责描述用例执行过程中异常的或偶尔发生的一些情况，备选流和基本流的组合应该能够覆盖该用例所有可能发生的场景。在描述备选流时，应该包括以下几个要素：(1)起点：该备选流从事件流的哪一步开始；(2)条件：在什么条件下会触发该备选流；(3)动作：系统在该备选流下会采取哪些动作；(4)恢复：该备选流结束之后，该用例应如何继续执行。第66页/共74页67备选流的描述格式可以与基本流的格式一致，也需要编号并以标题概述其内容，编号前可以加以字母前缀A(Alternative)以示与基本流步骤相区别。第67页/共74页

25、683.3 用例场景3.3 用例场景用例在实际执行的时候会有很多的不同情况发生，称之为用例场景；也可以说场景是用例的实例，我们在描述用例的时候要覆盖所有的用例场景，否则就有可能导致需求的遗漏。在用例规约中，场景的描述可以由基本流和备选流的组合来表示。场景既可以帮助我们防止需求的遗漏，同时也可以对后续的开发工作起到很大的帮助：开发人员必须实现所有的场景、测试人员可以根据用例场景来设计测试用例第68页/共74页69 3.4 特殊需求特殊需求通常是非功能性需求，它为一个用例所专有，但不适合在用例的事件流文本中进行说明。特殊需求的例子包括法律或法规方面的需求、应用程序标准和所构建系统的质量属性（包括可

26、用性、可靠性、性能或支持性需求等）。此外，其他一些设计约束，如操作系统及环境、兼容性需求等，也可以在此节中记录。需要注意的是，这里记录的是专属于该用例的特殊需求；对于一些全局的非功能性需求和设计约束，它们并不是该用例所专有的，应把它们记录在补充规约中。第69页/共74页70 3.5 前置和后置条件 3.5 前置和后置条件前置条件是执行用例之前必须存在的系统状态，后置条件是用例一执行完毕后系统可能处于的一组状态。第70页/共74页71 4、检查用例模型用例模型完成之后，可以对用例模型进行检查，看看是否有遗漏或错误之处。主要可以从以下几个方面来进行检查：功能需求的完备性 现有的用例模型是否完整地描

27、述了系统功能，这也是我们判断用例建模工作是否结束的标志。如果发现还有系统功能没有被记录在现有的用例模型中，那么我们就需要抽象一些新的用例来记录这些需求，或是将他们归纳在一些现有的用例之中。第71页/共74页724、检查用例模型模型是否易于理解 用例模型最大的优点就在于它应该易于被不同的涉众所理解，因而用例建模最主要的指导原则就是它的可理解性。用例的粒度、个数以及模型元素之间的关系复杂程度都应该由该指导原则决定。是否存在不一致性 系统的用例模型是由多个系统分析员协同完成的，模型本身也是由多个工件所组成的，所以我们要特别注意不同工件之前是否存在前后矛盾或冲突的地方，避免在模型内部产生不一致性。不一致性会直接影响到需求定义的准确性。第72页/共74页734、检查用例模型 避免二义性语义 好的需求定义应该是无二义性的，即不同的人对于同一需求的理解应该是一致的。在用例规约的描述中，应该避免定义含义模糊的需求，即无二义性。第73页/共74页74感谢您的观看！第74页/共74页