UML建模

基于UML的系统分析与设计UML建模一种系统开发方法应由建模语言和开发过程组成。建模语言是设计的表示符号,而过程则是描述如何进行开发所需的步骤。UML的开发过程包括需求获取、系统分析、系统设计、实现和测试5个步骤。第一阶段需求获取需求获取1.需求获取系统开发的第一步工作就是进行需求收集。需求收集从调查开始。调查是为了发现了系统中的参与者和高层用例。2.建立用例图为了能够准确的描述用户的需求，就要使用用例。首先需识别用例，然后才能建立用例。⑴确定系统边界在确定参与者和用例的过程中也就确定的了系统的边界，用例是系统之中的，参与者是系统外部的。（1）识别参与者一般地，可以通过以下问题去寻找用例图中的参与者：谁是系统的主要使用者？谁从系统获取信息？谁向系统输入信息？谁从系统中删除信息？谁需要系统支持他们的日常工作？谁来维护、管理系统使其能正常工作？系统需要控制哪些硬件？系统需要与其他哪些系统交互？对系统产生的结果感兴趣的是哪些人或哪些事物？（1）识别参与者除把直接使用系统的人员确认为参与者外。凡是与系统进行信息交换（包括数据信息和控制信息交换）的外部事物均可被确认为参与者。外部事物指的是：人员、设备、外部系统、事件。⑵识别用例基于参与者识别用例l）识别出与系统有关的参与者。2）对每个参与者，识别出他们发起或参加的过程。3）对每个参与者，识别出向他们传递信息的过程。可列一个表为编制用例准备一个表参与者向参与者传递信息的服务或事件用例名简短的描述业务目标参与者→职责→用例参与者名：customer（客户）参与者职责：定货、退还定货、查询定单。参与者检查问题：使用系统主要功能；对系统运行结果感兴趣。参与者→职责→用例从发货者（Shipper）识别发货者要求系统提供什么功能？仓库存储物品的管理；发货处理。发货者需要做什么？从所有的定单中按顺序挑选出优先级较高的定单来发货；在发货单上签上发货的品名、数量。发货者需要阅读、创建、销毁、更新或存储系统的某些信息吗？是，发货者需要阅读、更新仓库存储物品信息和顾客信息。系统中的事件一定要告知发货者吗？仓库有关物品短缺（发货者报告）识别用例通常，在确定用例前应考虑以下问题：参与者需要使用系统吗？对于各个参与者，哪些任务会涉及到系统？系统与参与者之间有哪些交互？系统需要何种输入输出？输入从何处来？输出到何处去？识别用例用例将支持和维护的系统功能是什么？必须提醒参与者的系统事件有哪些？参与者必须提醒系统事件有哪些？怎样把这些事件表示成用例中的功能？用例的粒度不要把用例划分的过大，也不要把用例划分得过于琐碎细小。通常,用例的行为都是用事件流描述，并且会产生显著的目标。这是用例粒度的底线。即每个用例都应当是一个完成有意义的业务目标的事件流集合。用例过细输入用户名输入密码用户提交提示出错系统正确登录一般认为合适的把握购买CD顾客登陆⑷确定关系确定用例的最后一个步骤就是描述关系。关系包括：参与者与用例之间的关系用例之间的关系参与者之间的关系。关系类型包括：关联关系、包含关系、扩展关系和泛化关系。库存管理用例图登陆入库处理出库处理库存查询库存统计销售出库调拨出库库管员盘点处理采购入库退货入库includeinclude登陆入库处理出库处理库存查询库存统计销售出库调拨出库库管员盘点处理采购入库退货入库includeinclude登陆入库处理出库处理库存查询库存统计销售出库调拨出库库管员盘点处理采购入库退货入库includeinclude登陆入库处理出库处理库存查询库存统计销售出库调拨出库库管员盘点处理采购入库退货入库includeinclude登陆出库处理库存查询库存统计销售出库调拨出库库管员盘点处理退货入库includeinclude盘亏处理盘盈处理extendextend调拨入库采购入库入库处理发现包含关系系统分析员应该检查模型中的每个用例，提炼出公共的部分，创建单独的用例，并用包含关系与基本用例连接。这样会降低原来的用例复杂性，增加用例的复用性。发现扩展关系系统分析员检查每个用例，如果发现一个用例比较大，并且其中既包含了一般处理又包含了特殊处理，那么就应该将特殊处理的部分提取出来，创建单独的用例，并且用扩展关系连接这个用例与相关的用例。这样会降低原来的用例复杂性，处理更简单。参与者泛化关系有时参与者之间存在一些共性，为了便于描述参与者之间的区别，使用参与者泛化关系来描述参与者之间的关系。用来判断应使用哪种关系的规则：当处理一般与特殊的关系时，采用泛化关系。当避免两个或多个例出现重复描述时，采用包含关系当描述用例的某种异常动作。采用扩展关系用例的优化用例是否有重复的功能出现（合并）是否有功能上的包含（合并）优化原则：独立集中用例的优化合并同类或相似的用例合并例：电子邮件撰写、邮件查看、合同录入、合同修改、合同删除、合同查看功能性合并文档录入（电子邮件撰写、合同录入）文档查看（邮件查看、合同查看）业务性合并邮件管理、合同管理用例的优化拆分对较大的或复杂的用例用例描述，描述到了第四级，仍无法描述清楚，需用例拆分主流→子流→分支流→子分支流用例的优化拆分例子管理用户包括处理：添加用户、修改用户信息、删除用户、查找用户、修改用户口令、变更用户级别拆分为：维护用户信息、管理用户权限两个用例（按业务相关性）3.定义用例的优先级定义用例的优先级是为了区分需求的优先级。区分用例的优先级是为了确定哪些用例要先行开发，哪些用例要放在随后的迭代工作中开发。区分的依据是前面活动生成的概要用例模型、补充需求说明和术语表。4.用例描述详细具体的描述一个用例还要使用用例描述。用例描述是采用自然语言描述一个用例的功能。通过用例的事件流完全可以描述系统的功能性需求。结构化的用例描述文本描述一个用例，应说明以下细节：用例名前置条件（Pre－Conditions）后置条件（Post-Conditions）扩充点（ExtensionPoints）事件流基流（BasicFlow）分支流（Subflows）（可选）替代流（AlternativeFlows）5.确定用户界面确定参与者如何启动用例，以及用例以什么形式向参与者提供信息，是在构造用户界面的原型。这项活动的输入是：用例模型、详细描述的用例描述。活动的结果是用户界面的简图。目的是为参与者确定用户界面的外观和感觉。逻辑用户界面设计用户界面设计人员逐一检查用例，为需要构造用户界面的用例确定适当的界面元素。如菜单、工具栏、对话框等。界面设计人员通过访谈参与者，请他们回答下面的问题：需要哪些界面元素来启动用例？用户界面元素之间如何相关？用户界面看起来应该是什么样的？应该如何处理这些用户界面元素？针对所涉及的业务领域，用户对用户界面元素有何特殊要求？参与者喜欢用哪些用户界面元素完成工作？界面设计人员通过访谈参与者，参与者可以激发哪些动作？在激发用例的动作前需要哪些指南？参与者向系统提供什么信息？系统向参与者提供什么信息？每项输入输出的长度和类型是什么？用户界面设计人员要确保每个用例都可以通过其用户界面元素进行访问。建立用例模型时应注意的问题①在大型的软件开发过程中，用例图可以分层建立。②在建模的开始阶段，注意保持用例图是对系统功能需求的高层次刻画，不要对它进行过细的分解。7.用例的组织较大的系统往往包含许多用例，为了更好的理解和管理它们，我们可以通过两种方式进行组织：用“包（Package）”来组织：用用例的级别层次关系来组织。产品分销系统用例图—总体图销售中心结算中心销售网点系统维护配送中心公用部分查询统计产品分销系统用例图—销售中心子系统产品资料管理采购管理虚拟库存维护批销管理预订管理供货商信息管理客户信息管理第二阶段系统分析系统分析面向对象系统分析的基本任务是：运用面向对象方法，对问题域和系统责任进行分析和理解，对其中的事物和它们之间的关系产生正确的认识，找出描述问题域以及系统责任所需的类及对象，定义这些对象的属性和操作，以及它们之间的静态和动态关系。最终产生一个符合用户需求，并能够直接反应问题域和系统责任的问题域模型及其详细说明。系统分析具体来说，分析阶段的活动主要是：识别对象；为对象分类；确定类的属性和操作；确定类之间的关系：确定对象之间的交互：确定对象的状态变化等。1.识别对象识别对象并不是从零开始的工作，应该最大限度地利用已有的劳动成果。比较典型的可利用的资料有。用例模型和用例描述。术语表。权威的术语定义集合。课程注册系统的术语表课程课程目录职员财务系统年级教授学期成绩单名册学生教学日历发现对象从用例模型和用例描述中找出名词来。但名词可能是参与者、对象和对象属性，所以还要区别它们。参与者通常比较容易区别，区别对象和对象属性可以通过分析是否有行为，对象是有行为的，而属性只是单纯的信息。三种对象类型分析模型中最常用的三种对象类型，它们是：实体（Entity）边界（Bountary）控制（Control）⑴实体对象实体对象主要的任务是装载信息，同时也具有相关的行为，但是这部分行为主要包括那些和实体对象自身信息直接相关的操作。可以找到实体对象的几个办法①考虑解决问题所需要的全部数据和行为，然后将数据按相关性分组。②识别出重要的名词，并将它们作为实体对象，然后确定每一个实体对象包含的数据和行为。③列出所有的数据、行为以及听起来很重要的名词，然后将数据和行为分配到不同类型的实体对象中。识别实体对象可参考下列问题：识别实体对象可参考下列问题：该对象是否是某个问题中的重要的名词？该对象是否包含用来解决系统问题的重要的信息？该对象是否包含可以解决系统问题的计算或者验证逻辑？⑵边界对象边界对象用于描述拟建系统内部运作与外部环境之间的交互。边界对象主要用于描述三种类型的内容：拟建系统和用户的界面，拟建系统和外部系统的接口拟建系统与设备的接口。⑵边界对象通过检查在用例图中的参与者与用例之间的关系，我们可以识别出边界对象。通常，在分析模型中，每一对参与者／用例都构成了一个边界对象。识别边界对象的可参考下列问题：识别边界对象的可参考下列问题：该对象是否描述了必须显示的信息以及必须提供的服务？该对象是否包含所有的接口设计细节？该对象是否描述了与外部系统的交互？⑶控制对象控制对象用于描述对一个用例所特有的事件流的控制行为。控制对象相当于协调人它自己通常不处理具体的任务，但它知道那些类有能力完成具体的任务。通常一个用例对应一个控制类。识别控制对象可参考下列问题：是否对业务逻辑进行控制？是否将业务逻辑提交给实体对象？顺序图中的边界对象,控制对象和实体对象:实体对象:用户:边界对象:控制对象输入信息请求处理处理建立连接数据处理2.描述对象的协作关系我们还需要详细了解对象在系统中的行为和责任。责任是响应消息的能力。消息被要求者提出，责任由响应者承担。确定责任主要根据责任和消息的简明对应关系，所谓找出责任是根据消息的要求定义责任，即用责任满足消息所提出的要求。对象的行为对象的行为是通过系统中对象之间的交互以及对象内部状态的转化来表现的。对象间通过发送消息而产生交互。同时在一个对象的生命周期内也存在状态的转移以及对事件的响应。⑴系统动态分析动态分析的主要任务包括分析用例的实现过程(要求有详细的用例描述)，从而更好地理解业务流程以及为发现类打好基础；用于进行动态分析的UML图包括顺序图、协作图、活动图和状态图。⑴系统动态分析建立交互图交互图表现的是参与者与系统以及系统内部对象之间的交互，将消息加进交互图时，是在向接收消息的对象指定职责。顺序图与事件流用例的事件流中