软件系统分析第七章.ppt

第七章UML分析与设计方法,概述,基于UML的分析与设计方法是在面向对象的方法上进一步规范与完善分析与设计，使其技能表示系统的静态特征又能表示动态行为；既能表示抽象逻辑特征，又能表示需求功能特征及物理特征。因此是一种较为全局、整体的反映系统分析、设计的工具。,特点,统一性二维模型工具,RUP的二维开发模型,传统的瀑布开发模型是一个一维的模型，开发过程被划分为多个连续的阶段。实际过程中，在开发整个周期中，每个阶段均会产生改变，可以看成是开发全过程中的一种工作流。,在RUP中，软件开发生命周期根据时间和RUP的核心工作流划分为二维空间。横轴表示项目的时间维，通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构纵轴以内容来组织，为自然的逻辑活动。体现开发过程的静态结构,基于二维模型的两种分析于设计方法迭代递增,需求工作流,概述,需求工作流通过对应问题的理解和分析，确立问题涉及的信息、功能和系统行为，将用户需求精确化、完全化。需求的焦点主要在初始和精化阶段，在精化阶段后期，需求捕获的工作量大幅下降。,需求工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围,需求工作流开始前，首先要对业务建模，业务建模就是对业务组织、业务内容和业务流程进行建模。业务模型为需求工作打下基础。(需求工作流开始的前提)需求捕获通过对业务内容进行描述、整理，确立业务实体及其关系；确定业务系统的功能要求；确定实现功能要求的实体间的交互关系。将用户需求精确化、完备化,内容,对问题域的理解首要任务包括对系统功能、性能的了解对业务流程的了解对数据的了解需求调研方法个别调查、会议讨论、搜集书面资料,建立初始功能模型在需求理解基础上，以功能为核心，建立初始功能模型UML里的用例视图描述系统功能,优化模型检验模型是否符合用户的要求修改模型直到达到用户的要求为止,UML制品,在需求捕获工作流，主要的UML制品：用例角色系统联系角色与用例之间的联系用例之间的联系角色之间的联系,用例之间的关系版类Include/Uses：包含/使用关系有先后关系，执行B时，必须要执行A,用例A,用例B,Uses,用例之间的关系版类Extend：扩展关系本质就是泛化,用例A,用例B,Extend,角色之间的关联关联关系：一般性联系,角色之间的关联继承关系：一般与特殊也存在单继承和多继承,场景自然语言描述不是一开始就很详细如同其他工作流一样，随着迭代和递增过程会不断细化及明确,例-用例图,例7.2图7.8例7.3图7.9场景图7.10,工作人员,参与需求捕获阶段的工作人员：系统分析人员（SystemAnalyst）用例描述人员（UseCaseSpecifier）用户界面设计人员（UserInterfaceDesigner）构架设计师（Architect）,需求工作流的活动,需求捕获的工作流主要包括五个活动：确定参与者和用例区分用例的优先级详细描述一个用例构造用户界面原型构造用例模型,确定参与者和用例：确定参与者和用例的目的是界定系统的范围，确定哪些参与者将与系统进行交互，以及他们将从系统中得到哪些服务(用例),业务模型的建立是“确定参与者用例”前提，而“确定参与者用例”又是用例模型（概要）的先决基础。,区分用例优先级：区分用例优先级是为了决定用例模型中哪些用例需要在早期的迭代中进行开发(包括分析、设计、实现等)，以及哪些用例可以在随后的迭代中进行开发,详细描述用例：详细描述用例的主要目的是为了详细描述事件流。这个活动包括建立用例说明、确定用例说明中包括的内容、对用例说明进行形式描述。他最终的结果是以图或文字表示的用例的详细说明。,构造用户界面原型：在系统分析人员建立起用例模型，确定了谁是用户以及他们要用系统做什么后。接下来的工作就是要着手设计用户界面。这个活动由逻辑用户界面设计、实际用户界面设计和构造原型两部分组成，它最终的结果是一个用户界面简图和用户界面原型。,构造用例模型：构造用例模型的主要目的是：整理用例间的关系，分离出包含用例和扩展用例；补充用例场景。这个活动由确功能说明、确定用例之间的其他关系组成。在确定系统用例和参与者之后。系统分析人员可以重新整理用例之间的关系，使模型更易于理解和处理。,图书馆信息系统需求工作流,系统描述图书馆信息系统主要处理要求是有关馆藏图书与杂志的借阅与保存,系统基本要求,图书馆的所有图书、杂志必须在系统中登记、注册（case：增加）。由编目人员负责（actor：编目人员）图书馆会采购新书，对旧书、过期期刊、破损及遗失书刊进行处理（case：删除）由服务人员负责（actor：服务人员）读者可以借阅与归还书刊（case：借阅、归还）（actor：读者）,管理员中的服务人员可以对所借书刊进行预订工作（case：预订、撤销预订）（actor：服务人员）系统采用三层C/S结构，采用*系统和*数据库进行管理,三层C/S结构,表示层是应用的用户接口部分，它担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据，显示应用输出的数据。一般使用图形用户接口，检查的内容也只限于数据的形式和值的范围，不包括有关业务本身的处理逻辑功能层应用的本体，它将具体的业务处理逻辑编入程序中数据层数据层作为DBMS独立出来,基于以上问题域的要求及理解，得出用例角色它们之间的关系场景描述,借阅书刊活动图：,需求工作流细化,以上是粗糙的初始功能模型，可以通过迭代和递增继续深入理解并修改完善，即细化过程。,需要修改的点：实际情况中，某种书刊通常会购买多本，需要区分同一种书刊的多本书书题与书目合并服务人员、编目人员为管理人员，系统不关注它们的信息,功能模型的改动用例：增加书题、删除和修改书题角色：合并为图书馆管理人员关系：场景：图7.15,分析工作流,分析的主要工作开始于初始阶段的结尾，和需求一样是精化阶段的主要焦点。精化阶段的大部分活动是捕获需求，分析工作与需求捕获在很大程度上重叠。旨在给出系统的精确的抽象模型。,分析工作流,建立静态模型表示系统的结构信息，系统的主要框架，是必须要做的UML中用类图表示从用例图中在问题域和业务流程分析理解的基础上，从用例及角色挖掘对象。,建立动态模型描述系统的活动规律，包括消息的活动及状态的变化在UML中用并发视图表示详细的活动规律可以从业务模型、用例场景中获知,检验及改进模型检验：是否满足用户需求是否合理修改通过迭代与递增作进一步修改和补充,UML制品,在分析工作流期间，主要的UML制品：类图四种动态图以时序图应用最为广泛,图书馆信息系统分析工作流,类图类从用例图角色看，有“读者”和“管理员”(忽略)从用例看，有对象“书目”和“书题”，他们与“读者”之间有“借阅”和“预订”的关联。类间关系确定联系类型：在关联、继承、聚合与依赖中，属于“关联”确定重数：,图书馆信息系统类图：,借阅书刊时序图,预订状态图,问题域迭代理解,由于书和期刊的属性不同，因此，加以区分，稍作调整。修改后的用例图图7.19最终的类图图7.20,设计工作流,设计是整个分析模型的精化和扩充，即扩充模型元素的语义以及增加新的元素。设计工作流类一般被组织成具有良好接口的设计包(Package)和设计子系统(Subsystem)，而描述则体现了类的对象如何协同工作，实现用例的功能。设计工作流的主要工作是位于精化阶段的最后部分和构造阶段的开始部分的主要建模活动。,设计工作流,建立设计的静态模型对类内部做细化，增加重要的属性和操作对类进行区分：实体类、控制类、界面类实体类是用于对必须存储的信息和相关行为建模的类，用于保存和更新一些现象的有关信息，例如：事件、人员或者一些现实生活中的对象。实体类通常都是永久性的，它们所具有的属性和关系是长期需要的对应于C/S架构的数据层,控制类用于对一个或几个用例所特有的控制行为进行建模，它描述的用例的业务逻辑的实现，控制类的设计与用例实现有着很大的关系。在有些情况下，一个用例可能对应多个控制类对象。控制类有效将业务逻辑独立于实体数据和边界控制，专注于处理业务逻辑，控制类会将特有的操作和实体类分离，者有利于实体类的统一化和提高复用性。对应于C/S架构的逻辑层,边界类是系统内部与系统外部的角色之间进行交互建模的类，角色通过它来与控制对象交互，实现用例的任务。其形式可以是：为业务主角操作提供的一个GUI，或者系统与其他的系统之间进行一个交互的接口，所以当外部的GUI变化时，或者是通信协议有变化时，只需要修改边界类就可以了，不用再去修改控制类和实体类。对应C/S架构的界面层,根据需要，对类图中的类进行增补，使其更完善。引入接口、taggedvalue，constraint，note等，对类间关系进行补充，语义进行深入描述。划分子系统，组合成包以上工作可以在原分析阶段类图上修改,建立设计的动态模型对类间消息以及状态的变化等，继续细化与深化。根据需要，引入taggedvalue，constraint，note等。可以在分析阶段动态图的基础上修改,检验和改进设计模型检验标准同分析模型引起修改：与用户需求不符合，或用户需求变更。对问题域有新的理解，更加深入。优化逻辑视图。根据实际需要，考虑具体实现以及环境等。,UML制品,类图，以及并发视图里的四种图UML的通用机制便条/注释修饰UML扩展机制Taggedvalue，contraint，stereoType,图书馆信息系统设计工作流,类图增加类的属性及操作，标注属性的类型，以及可见性根据C/S架构，确定3个子系统补充数据相关类和界面相关类增加persistent，封装数据库相关存储机制和操作，控制类从其继承增加若干界面类，一般形式是主界面+若干子界面,设置一些语义限制和约束，设置sterotype，加注note等。业务处理包图7.22,实现工作流,实现工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式(源文件、二进制文件、可执行文件)实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。实现是关于把设计模型转换成可执行代码的过程。实现工作流是构建阶段的焦点。,实现工作流,建立系统物理结构图建立组件图：类的实现文件可以表示成一个组件建立展开图：首先确定硬件环境和硬件之间连接关系