基于UML的需求分析.pptVIP

3.UML基础-用例图用例图表达了哪些内容：参与者与用例之间的通讯关系，也可以参与者与参与者之间的关系，以及用例与用例之间关系。参与者（或叫角色），它可以是人或者其它外部系统或者计算机设备。用例：描述参与者与系统的交互，它向参与者提供了有重要价值的操作序列。关系（Association）包用例的组织形式3.UML基础-用例图：Actor案例：Actor：叫法很多，有“参与者/执行者/主角/使用者”，可以是人也可以其它事物（包括计算机设备与外部系统），用一个小人表示。参与者之间的关系，参与者其实质就是类：继承（泛化）关系参与者与用例之间的关系1、单向关系2、双向关系Actor可以启动UserCaseActor也可以接收系统的发出的信息，如外部系统。3.UML基础-用例图：用例(usecase)Usecase的叫法：用况/用案/用例。用例之间的三种关系：包含关系继承关系，扩展关系记忆方法：用例之间的关系是纵坐标+横坐标。原则上来说：用例之间都是独立的，并列的，它们之间不存在包含从属关系。但是为了体现一些用例之间的业务关系，以及提高可维护性和一致性。它都是从现有的用例中抽取出公共的那部分信息，作为一个单独用例，然后通过不同的方法来重用这个公共的用例，以减少模型维护工作量。3.UML基础-用例图：用例(usecase)-包含关系包含关系类似于主程序调用子程序的关系。包含用例描述了插入到基本用例中的行为片段。基本用例可控制与包含用例的关系，并可依赖于执行包含用例所得的结果，但基本用例和包含用例都不能访问对方的属性。何时使用：通常把多个用例都用到的片段，抽出来形成一个公共的用例。这样维护方便且简单。主要实现复用。3.UML基础-用例图：用例(usecase)-扩展关系扩展关系用例中的一部分是可选的，可以把可选行为和必选行为分开。只在特定的条件下执行的分支流。一组行为段，其中的一个或者多个段可以在基本用例中的扩展点处插入，是否插入取决于基本用例与参与者的交互。扩展是有条件的，扩展用例可以访问和修改基本用例的属性，但基本用例看不到扩展用例，也无法访问它们的属性。3.UML基础-用例图：用例(usecase)-继承关系继承关系，很少用，常用用例中的备选流来代替。子用例和父用例相似，但加入了特别的行为，子用例继承了父用例的所有结构、行为和关系。UML基础-用例图：扩展关系和包含关系区别03包含：是在用例A的某一点（不是判断分支点），会到另一个用例B运行，B完成后，会回到A，并继续该点的紧接着的下一步骤。添加标题扩展：是在用例A的某点（条件判断），当满足一定条件则到B用例运行，B完成后，回到A中该点所属条件分支结束后的下一步骤。01添加标题02添加标题3.UML基础-用例图：用例关系示意包含关系继承关系扩展关系注意：可以为一个用例创建对应的参与者，也可以为一个参与者创建对应的多个用例。3.UML基础-类图软件模型1、在了解类图之前，先了解软件模型，并且对需求分析工作来说，我这里不介绍类图，只介绍概念模型。１、域对象：实体域对象，过程域对象，事件域对象。2、域对象的关系。２、类，实体，对象三者之间关系实体类过程类事件类类对象是类的实例化，它可以是一个或者几个类的抽象形成。实体类简称实体。一个或多个表；表的所有索引；视图；触发器；表与表之间的参照完整性。业务逻辑或者流程警告，屏常，超时等事件人，事物，地点或者概念3.UML基础-概念模型（即实体关系图）需求分析阶段常做的两件事：1、对问题域详细分析后，确定用例。2、概据用例建立概念模型，它是用来模拟问题域中的真实实体。它描述了每个实体的概念和属性，以及实体之间的关系，但不描述实体的行为。这些实体在设计阶段转化为类。3.UML基础-实体之间关系数量来说：实体之间的关系（一对一，一对多，多对多）。关系类型来说，实体的关系是：3+1关联聚合组合关系继承（泛化）类之间的关系多了一个依赖关系(Dependency)，但实体之间不描述这种关系。横向纵向UML基础-实体之间关系：关联(Assosication)一对一关系一对多关系多对多关系整体与部分关系，部分与可以脱离整体而存在。3.UML基础-实体之间关系：聚合(Aggregation)UML基础-实体之间关系：组合(又叫合成)组合关系中的部分实体对象不能单独存在，它的生命周期依赖于整体实体的对象生命周期，当整体消失时，部分也就随之消失。而对于存在关联关系的两个实体，可以允许每实体的对象都单独存在，如雇员和雇主就是这样的