《面向对象分析》PPT课件.ppt

第6章 面向对象分析,4学时,引言面向对象分析构建三个模型,第6章 面向对象分析,1）面向对象分析的方法、步骤2）面向对象分析和结构化分析之间的区别3）面向对象需求分析规格说明书的主要内容,掌握理解了解,要求,6.1 面向对象需求分析概述,面向对象分析和设计涉及到3方面内容：一套完善的建模符号一系列有效的分析步骤一个方便易用的建模工具。目前流行的建模符号采用UML的一套图形符号；从描述用户需求的文件中，抽象出目标系统的本质属性，建立以用例模型、对象模型和动态模型为核心的分析模型；建模工具可以选择Rational ROSE。,面向对象需求分析的任务,面向对象分析是抽取和整理用户需求并建立问题域精确模型的过程。识别问题域的对象并分析它们相互之间的关系，最终建立简洁、精确、可理解的正确模型是分析阶段的关键。开发人员首先要理解用户的需求，找出描述问题域和系统责任所需的对象和类，将用例行为映射到对象上，进一步分析它们的内部构成和外部关系，从而建立面向对象分析模型。在此基础上，开发人员和用户一起检查模型，保证模型的正确、一致、完整和可行。面向对象的分析过程是一个循环渐进过程，需要多次循环迭代完成。,面向对象需求分析3个主要模型,目前的面向对象分析方法有许多，大多数的分析方法可以被归结为建立以下三个模型：功能模型:表达系统的详细需求,由用例图和场景描述组成对象模型:表示静态的、结构化的系统“数据”性质。描述现实世界中实体的对象以及它们之间的关系,表示目标系统的静态数据结构。在面向对象方法中,类图是构件对象模型的核心工具。动态模型:描述系统的动态结构和对象之间的交互,表示瞬时的、行为化的系统的“控制”特性。面向对象方法中,常用状态图、顺序图、合作图、活动图构件系统的动态模型。,6.2 创建用例模型,第1步：创建组织机构和角色职能图用例模型的本质是要确定系统的功能。为了解系统功能，我们需要一种简便的方法能够快速有效地找出谁使用系统？他们用系统做什么？在哪里做？什么时间做？为了便于理解，对于信息系统我们建议用一张相关的组织机构和角色职能图来反映谁可能使用使用系统，做什么？在哪个部门做？注意：这个图不是UML的一部分。如果不是信息系统这个图可能没有意义。,第2步：确定角色系统分析人员与用户一起确定与系统发生交互活动的所有角色。使用者如果是信息系统,则从第1步的组织机构和角色职责图中能够很容易发现系统的使用者。如果不是信息系统,总还有系统的使用者吧,把系统的使用者都列出来。,外部系统需要与本系统发生关系(功能,数据)的其他软件系统外部设备与本系统发生关系的外部设备(控制的设备,或接受其他设备的控制)时间受时间影响的任务(按时间自动触发的任务),第3步 确定用例确定角色之后,系统分析人员从每个角色出发研究该角色要干什么？把要做的事情映射到用例，研究过程中需要弄清的几个问题:角色要求系统提供哪些功能(使用者需要做什么)？角色需要了解和处理的信息有哪些类型？必须提醒角色的系统事件有哪些？角色必须提醒系统的事件有哪些？怎样把这些事件表示成用例中的功能？,为了完整地描述用例，还需要知道角色的某些典型功能是否能够被系统自动实现？系统需要的输入输出是什么？输入从何处来？输出到何处？当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题？,第4步 确定用例模型使用用例图展示系统的用例模型。,第5步 用例模型说明包括角色说明；用例总览和详述。见用例说明,角色说明,用例总览,用例详述,第6步 用例模型评价在初步建立了用例模型后，应该邀请领域专家和其他相关的用户一起对模型进行评审，回答下面的问题：是否已将所有必须的功能性需求都捕获为用例。每个用例的动作系列是否正确、完善、易于理解。是否已经确定了一些价值很小或根本没有价值的用例，如果又将它们删除。,第7步 优化用例模型系统分析员检查模型中的每个用例，提炼出公共部分，创建抽象用例，并用使用关系与之连接；确定补充功能或可选功能；检查每个用例，如果发现一个用例比较大，并且其中既包含了一般处理又包含了特殊处理，那么则应该将特殊处理的部分提取出来，创建单独的用例，并且用扩展关系连接相关的用例。这样做可以减小用例规模，简化用例的处理。,第8步 构造用户界面的原型 系统分析员已经确定了用例与角色之间的对应关系，现在要确定角色如何启动用例，以及用例以什么形式向角色提供信息。这项活动的结果是用户界面原型。,界面设计人员考虑下面的问题：,需要哪些界面元素来启动用例？用户界面元素之间如何相关？用户界面看起来应该是什么样的？应该如何处理这些用户界面元素？针对所涉及的业务领域，对用户界面元素有何特殊要求？角色可以激发哪些动作？在激发这些动作前需要哪些指南？角色向系统提供什么信息？系统向角色提供什么信息？每项输入/输出的长度和类型是什么？,6.3 创建对象模型,第1步：识别分析类。分析用例模型的每个用例，确定实现用例的类，分析每个类的职责、属性和关联。将参与用例实现的类收集到一个类图中。界面类描述系统与角色之间的接口。控制类在分析模型内表示协调、顺序、事务处理以及控制其他对象的类。实体型为需要长久保存的信息进行建模的类。,识别边界类,在每一个用例中，每一个参与者至少与一个边界类进行交互。边界类担负着协调参与者与用例之间的交互职责。因此初步给每一对（参与者，用例）确定一个边界类，并在分析的过程中有可能进行分解和合并。,用户界面的位置,识别控制类,控制类负责协调边界类和实体类，通常在现实世界中没有对应的事物。它负责接收边界类的信息，并将其分发给实体类。对于控制类来说，我们初步给每个用例设置一个控制类，随着分析的发展有可能进行分解和合并。,注意：,在有些情况下，用例事件流的逻辑结构十分简单，这时没有必要使用控制类，边界类可以实现用例的行为，例如图书馆图书信息关系系统中的“登录”用例就是这种情况。当用例比较复杂时，特别是产生分支事件流的情况下，一个用例可以有多个控制类。,识别实体类,实体类通常是用例中的参与对象，对应着现实世界中的“事物”。识别实体类需要开发人员进一步理解应用领域，可以通过分析用例描述和词汇表等发现备选的实体对象。,可能作为实体类的选择,第2步 构造类图,6.4 构造动态模型,通过描述分析类实例之间的消息传递将用例的职责分配到分析类中。在初步找出一些分析类之后，用顺序图将用例和分析对象联系在一起，描述用例的行为是怎样在它的参与对象之间分布的。顺序图可以将用例的行为分配到所识别的分析类中，并且帮助开发人员发现和补充前面遗漏的分析类。例如，图书馆信息管理系统“借书”用例的顺序图,6.5 评价分析模型,为了使需求评审工作更加具有可操作性，下面列出了一些问题清单:1检查“正确性”的问题列表用户是否可以理解实体对象的术语表？抽象类与用户层次上的概念对应吗？所有的描述都与用户定义一致吗？所有的实体类和边界类都使用具有实际含义的名词短语吗？所有的用例和控制类都使用具有实际含义的动词短语吗？所有的异常情况都被描述和处理了吗？是否描述了系统的启动和关闭？是否描述了系统功能的管理？,2检查“完整性”的问题列表每一个分析类都是用例需要的吗？它在什么用例中被创建、修改和删除？是否存在边界类可以访问它？每一个属性是在什么时候设置的？类型是什么？它是限定词吗？每一个关系是在什么时候被遍历？为什么选择指定的基数？一对多和多对多的关系能被限定吗？每一个控制类对象是否有必要访问参与用例的对象？,3检查“一致性”的问题列表类或用例有重名吗？具有相同名字的实体表示相同的对象吗？所有的实体都以同样的细节进行描述吗？是否存在具有相同属性和关系却不在同一个继承层次中的对象？,4检查“可行性”的问题列表系统中有什么创新之处？建立了什么计划或原型来确保这些创新的可行性？性能是否符合可靠性需求？这些需求是否已被运行在指定硬件上进行原型验证？,6.6 面向对象的需求规格说明书,面向对象的需求分析使用的方法和工具与结构化方法有很大的区别，本小节给出一个基于面向对象方法的需求规格说明书的文档模板。见模板,本章要点,面向对象分析和设计用到的三个内容：一套完善的建模符号、一系列有效的分析步骤和一个方便易用的建模工具。面向对象的分析模型由功能模型、对象模型和动态模型三部分组成，其中功能模型由用例图和顺序图表示，对象模型由类图和对象图表示，动态模型由活动图、状态图和顺序图表示。在分析对象模型中，分析类是概念层次上的内容，分为实体类、边界类和控制类三种类型。分析模型是在开发人员与用户之间的密切交流过程中迭代形成的，开发人员和用户必须对所形成的分析模型进行正式评审，确保分析模型的正确性、完整性、一致性和可行性。,