基于UML的电子商务系统分析

基于UML的系统分析电子商务系统建设与管理主要内容需求捕获获得候选需求理解系统环境捕获功能需求捕获非功能需求基于UML的功能需求分析需求捕获需求分析的第一步，很重要来源于用户及系统相关者用非专业的表述方式在迭代式开发方法中逐步更新需求获得候选需求对系统相关者提出的需求记录为候选需求清单，该清单是动态变化的清单中包括需求名称、说明、状态、估算成本、优先级、风险级别等序号需求名称说明状态优先级风险1订单提交网上提交……批准的关键关键的2支付网上支付……..未来需要的重要重要的3信用级别客户信用…..建议的可选普通的理解系统环境领域模型：捕获系统环境中重要的对象类型业务对象，表示业务中可操作的东西系统需要处理的现实世界中的对象和概念将要发生或已经发生的事件业务模型：帮助分析人员理清业务过程，从而更准确地进行系统分析，可将整个业务领域描述为一个过程集，可用UML进行建模术语表保存领域模型中所选取的候选类各类人员使用统一的词汇表包括名称、相关解释、标识符号序号名称相关解释标识符号1订单临时存放所购商品Order2客户采购商品的组织或个人Customer非功能性需求可承载性安全性紧急程度使用频率与响应时间可用性可靠性其它补充说明功能分析主要工作：1、识别参与者和系统边界2、识别系统用例，识别用例间关系，建立用例模型3、划分用例优先级，确定时间安排计划4、对部分关键用例详细描述，建立界面模型识别参与者参与用例执行的外部实体：

人、设备、其它系统参与者不是指的一个人，而是一个角色，不同的人可以扮演不同的角色，同一个人可以扮演若干种角色步骤：考虑所有有关的人/设备/系统，确定参与系统维护和操作的参与者，对于每个参与者，判断是否能够确定至少一个用户来扮演该角色并实现其功能，再根据减少功能重叠进行合并，最后命名参与者定义系统边界系统边界标识了哪些功能属于系统，哪些功能不属于系统从不同的角度看待系统会得到不同的边界定义建立用例模型识别用例用例描述了一个参与者使用本系统完成某个过程时的事件发生顺序图示、命名可从业务模型直接导出与系统相关人员共同讨论及分析得出及时复查候选需求清单、领域模型和业务模型，并与客户交流最后确定基于参与者的方法识别出参与者对每个参与者，识别出他们发起或参加的执行过程如：网上购物系统可识别出的参与者有顾客、产品管理人员，分别对应的执行过程是下订单、订单查询、产品信息维护、库存检查基于事件的方法识别出系统必须相应的外部事件把事件与参与者和用例联系起来如：网上购物系统中的外部事件有产品查询请求（顾客/产品查询）、产品购买请求（顾客/下订单）、库存更改（产品管理人员/库存维护）识别用例收尾检查所获取用例是否完整每个参与者的特定任务、都与用例有信息交换？突发性、外部的改变通知系统？支持与维护系统的用例？用例命名标准：公司规定；动词+名词；简洁直观；名称唯一对用例进行简单说明，概括用例动作及所实现的功能参与者→职责→用例从发货者（Shipper）识别

发货者要求系统提供什么功能？发货者需要做什么？答：发货者要求系统提供：仓库存储物品的管理；发货处理。发货者需要做：从所有的定单中按顺序挑选出优先级较高的定单来发货；在发货单上签上发货的品名、数量。

发货者需要阅读、创建、销毁、更新或存储系统的某些信息吗？答：是，发货者需要阅读、更新仓库存储物品信息和顾客信息。

系统中的事件一定要告知发货者吗？答：是，这些事件包括：仓库有关物品短缺（发货者报告）UML需求获取用例的粒度不要把用例划分的过大，也不要把用例划分得过于琐碎细小。通常,用例的行为都是用事件流描述。这是用例粒度的底线。每个用例都应当是一个完成有意义的业务目标的事件流集合。用例图中的关系关系包括：参与者与用例之间的关系、用例之间的关系、参与者之间的关系。关系类型包括：关联关系、包含关系、扩展关系和泛化关系。识别用例间的关系参与者与用例之间的关联（箭头表示交互的发起者）用例之间：包含关系（include）和扩展关系（extend）发现包含关系系统分析员应该检查模型中的每个用例，提炼出公共的部分，创建单独的用例，并用包含关系与基本用例连接。这样会使得原来的用例比较小，增加用例的复用性。还有一种可能是把一个较大的用例分成两个用例：一个基本用例，一个被包含用例发现扩展关系扩展关系主要用于表示：可选择的行为在特定条件下才发生的行为基于操作者的选择而进行的几种不同流程发现扩展关系系统分析员检查每个用例，如果发现一个用例既包含了一般处理又包含了特殊处理，那么就应该将特殊处理的部分提取出来，创建单独的用例，并且用扩展关系连接这个用例与相关的用例。这样会使得原来的用例比较小，处理更简单。参与者泛化关系有时参与者之间存在一些共性，为了便于描述参与者之间的区别，使用参与者泛化关系来描述参与者之间的关系。用例图先组织用例，然后确定共享用例（包含关系），再确定扩展用例，再确定泛化等关系用例模型需要进行非正式评审：将必需的功能性能需求捕获为用例每个用例的具体动作序列是否正确、完整、易于理解考虑是否保留价值很小的用例关系是否合理用例图用例图用来判断应使用哪种关系的规则：当处理一般与特殊的关系时，采用泛化关系。当避免两个或多个例出现重复描述时，采用包含关系当描述用例的某种异常动作。采用扩展关系用例的优化合并：同类或相似的用例合并例：电子邮件撰写、邮件查看、合同录入、合同修改、合同删除、合同查看功能性合并文档录入（电子邮件撰写、合同录入）文档查看（邮件查看、合同查看）业务性合并：邮件管理、合同管理用例的优化拆分：对较大的或复杂的用例例：管理用户包括处理：添加用户、修改用户信息、删除用户、查找用户、修改用户口令、变更用户级别拆分为：管理用户信息、管理用户、管理用户权利三个用例（按业务相关性）识别用例常见错误把用例当作单独的步骤、操作或事务处理过多或过少的用例。用例是否合适确定准则：有价值的结果；具体参与者关系过于复杂其它错误：角色名称矛盾、用例叙述过长混乱、未正确描述功能、难以理解等用例过细一般认为合适的把握用例排序（定义优先级）定义用例的优先级是为了区分需求的优先级。区分用例的优先级是为了确定哪些用例要先行开发，哪些用例要放在随后的迭代工作中开发。步骤：定义用例级别（关键的、重要的、普通的、次要的、可选的）；每个级别内的用例再排序用例排序分类标准：是否对体系结构设计有重要影响是否含有高开发风险、时间紧迫、功能复杂的用例是否涉及重要技术研究或新技术高风险是否代表关键的核心的组织业务流程是否比较容易能否产生直接经济效益或降低成本用例描述采用自然语言描述一个用例的功能。通过用例的事件流完全可以描述系统的功能性需求。主要内容：用例名、基本路径、备选路径由用户对用例进行评审结构化的用例描述文本描述一个用例，应说明以下细节：用例名前置条件（Pre－Conditions）后置条件（Post-Conditions）扩充点（ExtensionPoints）事件流基流（BasicFlow）分支流（Subflows）（可选）替代流（AlternativeFlows）UML需求获取建立用例模型时应注意的问题①在大型的软件开发过程中，用例图可以分层建立。②在建模的开始阶段，注意保持用例图是对系统功能需求的高层次刻画，不要对它进行过细的分解。UML需求获取用例的组织较大的系统往往包含许多用例，为了更好的理解和管理它们，我们可以通过两种方式进行组织：用“包（PackagC）”来组织用用例的级别层次关系来组织产品分销系统用例图—总体图产品分销系统用例图—销售中心子系统产品分销系统用例图—批销管理交互图分析顺序图展示了一个用例的行为，可以只描述基本路径分析阶段的顺序图不过多关心细节，可以等到设计阶段再细化在分析阶段可以不使用顺序图，根据实际情况确定三种对象类型分析模型中最常用的三种对象类型，它们是：实体（Entity）边界（Bountary）控制（Control）⑴实体对象实体对象主要的任务是装载信息，同时也具有相关的行为，但是这部分行为主要包括那些和实体对象自身信息直接相关的操作。⑵边界对象边界对象用于描述拟建系统内部运作与外部环境之间的交互。边界对象主要用于描述三种类型的内容：拟建系统和用户的界面拟建系统和外部系统的接口拟建系统与设备的接口⑵边界对象通过检查在用例图中的参与者与用例之间的关系，我们可以识别出边界对象。通常，在分析模型中，每一对参与者／用例都构成了一个边界对象。⑶控制对象控制对象用于描述对一个用例所特有的事件流的控制行为。控制对象相当于协调人，它自己通常不处理具体的任务，但它知道那些类有能力完成具体的任务。通常一个用例对应一个控制类。顺序图协作图作为对顺序图的补充，协作图可以着重描述对象之间的静态链接关系初步类图：从交互图和对象图可以得到分析类图，此时类图并不完善，需要到设计阶段进一步优化购买构建和修改电子商务企业可以购买一个解决方案或解决方案的一部分，当所购买的软件包不能满足企业的特定要求时，需要自行开发软件包大多数企业采用混合解决方案，即保护已有的投资，又升级了系统功能也有的企业考虑对所购得的包进行扩展开发或修改，以适合本企业的需求解决方案的确定要充分考虑经济性问题经典电子商务系统功能分析B2C零售系统基本需求：注册，动态信息展示，用户反馈，企业信息查询，商品信息显示，订单管理，汇总统计功能，用户管理，销售企业界面，公告板，留言板，客服中心，购物车，电子支付，广告管理，库存管理，产品跟踪，外部接口等，即：

商品管理子系统；交易子系统；客户管理或客户关系管理子系统经典电子商务系统功能分析B2B电子商务基本需求：网上客户的注册与管理，会员权限管理，商品信息的分类录入和发布，网上在线信息管理，网上商务流程管理，拍卖招标管理，电子签证的识别及认证，在线支付，重要信息管理，配送建议，BBS等经典电子商务系统功能分析物流配送系统基本需求：配送合约议定，配送计划制定，进货管理，收货管理，储放管理，出货管理，货物盘点，货物追踪，客户助理，帐务管理，报表管理等经典电子商务系统功能分析企业信息门户基本需求：企业基本信息发布，企业动态与新闻发布，企业产品和服务，企业产品信息目录与导航，搜索与索引，电子邮件与客户反馈，用户访问统计，网站访问分析与统计，个性化服务，电子社区等ATM实例分析两个参与者及注释三个用例ATM实例分析用例图（不合适）ATM实例分析用例图（优化后）ATM实例分析（类图）ATM实例分析（类图）ATM实例分析（顺序图）分析类的概念分析模型中的所有类都是”分析类”。从设计视角看待，“分析类”忽略实现细节，相当粗略。“分析类”是为定义设计类做准备的。确定“分析类”这个步骤就是确定一组备选的、能够执行用例中行为的“分析类”。在确定“分析类”时，使用三种不同的构造型识别和提取潜在的“分析类”，它们是：实体类、控制类、边界类。确定“分析类”边界类：每个参与者和用例的交互存在一个对应的边界类。控制类：一般一个用例对应一个控制类。实体类：这个主要看用例里面用到的持久的数据对象。用到数据库对象时，可能就使用了实体类。类的获取类的获取有两种办法：从用例模型和用例描述中找出名词，有4种名词：参与者、类、类的属性、其他描述性名词。能够找出实体类分析参与者与用例对，找出边界类另一种是检查交互图中的对象，研究对象具有的共同属性和操作来发现类。识别分析类操作分析类在顺序图里要承担一定的“职责”“职责”是对其他对象发送来的消息的响应。也可能是对外部的响应，也可能是维护自身信息所必要的“职责”。这种行为在分析类演化成设计类时，它可能对应一个或多个具体的类的“操作”。通常有两种方法为类识别操作：责任驱动法、通过交互图