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

1、基于基于UMLUML的系统分析的系统分析电子商务系统建设与管理电子商务系统建设与管理主要内容主要内容o需求捕获需求捕获n 获得候选需求获得候选需求n 理解系统环境理解系统环境n 捕获功能需求捕获功能需求n 捕获非功能需求捕获非功能需求o基于基于UML的功能需求的功能需求分析分析需求捕获需求捕获o 需求分析的第一步，很重要需求分析的第一步，很重要o 来源于用户及系统相关者来源于用户及系统相关者o 用非专业的表述方式用非专业的表述方式o 在迭代式开发方法中逐步更新需求在迭代式开发方法中逐步更新需求获得候选需求获得候选需求o 对系统相关者提出的需求记录为候选需求清单，该对系统相关者提出的需求记录为候

2、选需求清单，该清单是动态变化的清单是动态变化的o 清单中包括需求名称、说明、状态、估算成本、优清单中包括需求名称、说明、状态、估算成本、优先级、风险级别等先级、风险级别等序号需求名称说明状态优先级风险1订单提交网上提交批准的关键关键的2支付网上支付. 未来需要的重要重要的3信用级别客户信用.建议的可选普通的理解系统环境理解系统环境o 领域模型：捕获系统环境中重要的对象类型领域模型：捕获系统环境中重要的对象类型n 业务对象，表示业务中可操作的东西业务对象，表示业务中可操作的东西n 系统需要处理的现实世界中的对象和概念系统需要处理的现实世界中的对象和概念n 将要发生或已经发生的事件将要发生或已经发

3、生的事件o 业务模型：帮助分析人员理清业务过程，从业务模型：帮助分析人员理清业务过程，从而更准确地进行系统分析，可将整个业务领而更准确地进行系统分析，可将整个业务领域描述为一个过程集，可用域描述为一个过程集，可用UML进行建模进行建模术语表术语表o 保存领域模型中所选取的候选类保存领域模型中所选取的候选类o 各类人员使用统一的词汇表各类人员使用统一的词汇表o 包括名称、相关解释、标识符号包括名称、相关解释、标识符号序号名称相关解释标识符号1订单临时存放所购商品Order2客户采购商品的组织或个人Customer非功能性需求非功能性需求o 可承载性可承载性o 安全性安全性o 紧急程度紧急程度o

4、使用频率与响应时间使用频率与响应时间o 可用性可用性o 可靠性可靠性o 其它其它o 补充说明补充说明功能分析功能分析o 主要工作：主要工作：o 1、识别参与者和系统边界、识别参与者和系统边界o 2、识别系统用例，识别用例间关系，建立、识别系统用例，识别用例间关系，建立用例模型用例模型o 3、划分用例优先级，确定时间安排计划、划分用例优先级，确定时间安排计划o 4、对部分关键用例详细描述，建立界面模、对部分关键用例详细描述，建立界面模型型识别参与者识别参与者o 参与用例执行的外部实体：参与用例执行的外部实体：人、设备、其它系统人、设备、其它系统o 参与者不是指的一个人，而是一个角色，不参与者不是

5、指的一个人，而是一个角色，不同的人可以扮演不同的角色，同一个人可以同的人可以扮演不同的角色，同一个人可以扮演若干种角色扮演若干种角色o 步骤：考虑所有有关的人步骤：考虑所有有关的人/设备设备/系统，确系统，确定参与系统维护和操作的参与者，对于每个定参与系统维护和操作的参与者，对于每个参与者，判断是否能够确定至少一个用户来参与者，判断是否能够确定至少一个用户来扮演该角色并实现其功能，再根据减少功能扮演该角色并实现其功能，再根据减少功能重叠进行合并，最后命名参与者重叠进行合并，最后命名参与者Customer定义系统边界定义系统边界o 系统边界标识了哪些功能属于系统，哪些功系统边界标识了哪些功能属于

6、系统，哪些功能不属于系统能不属于系统o 从不同的角度看待系统会得到不同的边界定从不同的角度看待系统会得到不同的边界定义义CustomerNetShoppingSystemCustomerCustomer ManagerNetShoppingSystem建立用例模型建立用例模型o 识别用例识别用例n 用例描述了一个参与者使用本系统完成某用例描述了一个参与者使用本系统完成某个过程时的事件发生顺序个过程时的事件发生顺序n 图示、命名图示、命名n 可从业务模型直接导出可从业务模型直接导出n 与系统相关人员共同讨论及分析得出与系统相关人员共同讨论及分析得出n 及时复查候选需求清单、领域模型和业务及时复查

7、候选需求清单、领域模型和业务模型，并与客户交流最后确定模型，并与客户交流最后确定orderorder基于参与者的方法基于参与者的方法o 识别出参与者识别出参与者o 对每个参与者，识别出他们发起或参加对每个参与者，识别出他们发起或参加的执行过程的执行过程o 如：网上购物系统可识别出的参与者有如：网上购物系统可识别出的参与者有顾客、产品管理人员，分别对应的执行顾客、产品管理人员，分别对应的执行过程是下订单、订单查询、产品信息维过程是下订单、订单查询、产品信息维护、库存检查护、库存检查基于事件的方法基于事件的方法o识别出系统必须相应的外部事件识别出系统必须相应的外部事件o把事件与参与者和用例联系起来

8、把事件与参与者和用例联系起来o如：网上购物系统中的外部事件有产品查如：网上购物系统中的外部事件有产品查询请求（顾客询请求（顾客/ /产品查询）、产品购买请产品查询）、产品购买请求（顾客求（顾客/ /下订单）、库存更改（产品管下订单）、库存更改（产品管理人员理人员/ /库存维护）库存维护）识别用例收尾识别用例收尾o 检查所获取用例是否完整检查所获取用例是否完整n 每个参与者的特定任务、都与用例有信息交换？每个参与者的特定任务、都与用例有信息交换？n 突发性、外部的改变通知系统？突发性、外部的改变通知系统？n 支持与维护系统的用例？支持与维护系统的用例？o 用例命名标准：公司规定；动词用例命名标准

9、：公司规定；动词+名词；简名词；简洁直观；名称唯一洁直观；名称唯一o 对用例进行简单说明，概括用例动作及所实对用例进行简单说明，概括用例动作及所实现的功能现的功能参与者参与者职责职责用例用例n 从发货者（从发货者（Shipper）识别）识别 发货者要求系统提供什么功能？发货者需要做什么？发货者要求系统提供什么功能？发货者需要做什么？答：发货者要求系统提供：答：发货者要求系统提供：仓库存储物品的管理；发货仓库存储物品的管理；发货处理处理。发货者需要做：。发货者需要做：从所有的定单中按顺序挑选出从所有的定单中按顺序挑选出优先级较高的定单来发货；在发货单上签上发货的品优先级较高的定单来发货；在发货单

10、上签上发货的品名、数量名、数量。 发货者需要阅读、创建、销毁、更新或存储系统的某发货者需要阅读、创建、销毁、更新或存储系统的某些信息吗？些信息吗？答：是，发货者需要答：是，发货者需要阅读、更新仓库存储物品信息和顾阅读、更新仓库存储物品信息和顾客信息客信息。 系统中的事件一定要告知发货者吗？系统中的事件一定要告知发货者吗？答：是，这些事件包括：答：是，这些事件包括：仓库有关物品短缺仓库有关物品短缺（发货者报（发货者报告）告）UML需求获取需求获取o 用例的粒度用例的粒度n 不要把用例划分的过大，也不要把用不要把用例划分的过大，也不要把用例划分得过于琐碎细小。例划分得过于琐碎细小。n 通常通常,用

11、例的行为都是用事件流描述。用例的行为都是用事件流描述。这是用例粒度的底线。这是用例粒度的底线。n 每个用例都应当是一个完成有意义的每个用例都应当是一个完成有意义的业务目标的事件流集合。业务目标的事件流集合。 用例图中的关系用例图中的关系o 关系包括：参与者与用例之间的关系、关系包括：参与者与用例之间的关系、用例之间的关系、参与者之间的关系。用例之间的关系、参与者之间的关系。o 关系类型包括：关联关系、包含关系、关系类型包括：关联关系、包含关系、扩展关系和泛化关系。扩展关系和泛化关系。识别用例间的关系识别用例间的关系o 参与者与用例之间的关联（箭头表示交互的参与者与用例之间的关联（箭头表示交互的

12、发起者）发起者）o 用例之间：包含关系（用例之间：包含关系（include）和扩展关）和扩展关系（系（extend）CustomerorderCustomerorder发现发现包含关系包含关系o 系统分析员应该检查模型中的每个用例，系统分析员应该检查模型中的每个用例，提炼出公共的部分，创建单独的用例，提炼出公共的部分，创建单独的用例，并用并用包含包含关系与基本用例连接。这样会关系与基本用例连接。这样会使得原来的用例比较小，增加用例的复使得原来的用例比较小，增加用例的复用性。用性。o 还有一种可能是把一个较大的用例分成还有一种可能是把一个较大的用例分成两个用例：一个基本用例，一个被包含两个用例：

13、一个基本用例，一个被包含用例用例orderStateCheck发现发现扩展关系扩展关系o 扩展关系主要用于表示：扩展关系主要用于表示：n 可选择的行为可选择的行为n 在特定条件下才发生的行为在特定条件下才发生的行为n 基于操作者的选择而进行的几种不同流程基于操作者的选择而进行的几种不同流程orderErrorReport发现发现扩展关系扩展关系o 系统分析员检查每个用例，如果发现一个用系统分析员检查每个用例，如果发现一个用例既包含了一般处理又包含了特殊处理，那例既包含了一般处理又包含了特殊处理，那么就应该将特殊处理的部分提取出来，创建么就应该将特殊处理的部分提取出来，创建单独的用例，并且用扩展

14、关系连接这个用例单独的用例，并且用扩展关系连接这个用例与相关的用例。这样会使得原来的用例比较与相关的用例。这样会使得原来的用例比较小，处理更简单。小，处理更简单。取钱快取参与者泛化关系参与者泛化关系o 有时参与者之间有时参与者之间存在一些共性，存在一些共性，为了便于描述参为了便于描述参与者之间的区别，与者之间的区别，使用参与者泛化使用参与者泛化关系来描述参与关系来描述参与者之间的关系。者之间的关系。用例图用例图o 先组织用例，然后确定共享用例（包含关系），先组织用例，然后确定共享用例（包含关系），再确定扩展用例，再确定泛化等关系再确定扩展用例，再确定泛化等关系o 用例模型需要进行非正式评审：用

15、例模型需要进行非正式评审：n 将必需的功能性能需求捕获为用例将必需的功能性能需求捕获为用例n 每个用例的具体动作序列是否正确、完整、每个用例的具体动作序列是否正确、完整、易于理解易于理解n 考虑是否保留价值很小的用例考虑是否保留价值很小的用例n 关系是否合理关系是否合理用例图用例图ErrorReportCustomerCreditCheckCustomerIDCheckorderCustomer ManagerStateCheckCreditComputeProduct ManagerStockUpdate用例图用例图入库到货入库调拨入库调拨出库退货出库查询配送，退货单出库登录库存汇总查询库存

16、到/出货审核残损审核盘点长短审核库存管理人员用来判断应使用哪种关系的规则：用来判断应使用哪种关系的规则：o当处理一般与特殊的关系时，采用泛化关当处理一般与特殊的关系时，采用泛化关系。系。o当避免两个或多个例出现重复描述时，采当避免两个或多个例出现重复描述时，采用包含关系用包含关系o当描述用例的当描述用例的某种异常某种异常动作。动作。采用采用扩展扩展关关系系用例的优化用例的优化o 合并：同类或相似的用例合并合并：同类或相似的用例合并n 例：电子邮件撰写、邮件查看、合同例：电子邮件撰写、邮件查看、合同录入、合同修改、合同删除、合同查录入、合同修改、合同删除、合同查看看o 功能性合并功能性合并n 文

17、档录入（电子邮件撰写、合同录入）文档录入（电子邮件撰写、合同录入）n 文档查看（邮件查看、合同查看）文档查看（邮件查看、合同查看）o 业务性合并：邮件管理、合同管理业务性合并：邮件管理、合同管理用例的优化用例的优化o 拆分：对较大的或复杂的用例拆分：对较大的或复杂的用例o 例：管理用户包括处理：添加用户、修例：管理用户包括处理：添加用户、修改用户信息、删除用户、查找用户、修改用户信息、删除用户、查找用户、修改用户口令、变更用户级别改用户口令、变更用户级别 拆分为：管理用户信息、管理用户、管理拆分为：管理用户信息、管理用户、管理用户权利三个用例（按业务相关性）用户权利三个用例（按业务相关性）识别

18、用例常见错误识别用例常见错误o 把用例当作单独的步骤、操作或事务处理把用例当作单独的步骤、操作或事务处理o 过多或过少的用例。用例是否合适确定准过多或过少的用例。用例是否合适确定准则：有价值的结果；具体参与者则：有价值的结果；具体参与者o 关系过于复杂关系过于复杂o 其它错误：角色名称矛盾、用例叙述过长其它错误：角色名称矛盾、用例叙述过长混乱、未正确描述功能、难以理解等混乱、未正确描述功能、难以理解等用例过细用例过细输入用户名输入密码用户提交提示出错系统正确登录一般认为合适的把握一般认为合适的把握登录购买CD用户用例排序（定义优先级）用例排序（定义优先级）o 定义用例的优先级是为了区分需求的优

19、定义用例的优先级是为了区分需求的优先级。先级。o 区分用例的优先级是为了确定哪些用例区分用例的优先级是为了确定哪些用例要先行开发，哪些用例要放在随后的迭要先行开发，哪些用例要放在随后的迭代工作中开发。代工作中开发。o 步骤：定义用例级别（关键的、重要的、步骤：定义用例级别（关键的、重要的、普通的、次要的、可选的）；每个级别普通的、次要的、可选的）；每个级别内的用例再排序内的用例再排序用例排序用例排序o 分类标准：分类标准：n 是否对体系结构设计有重要影响是否对体系结构设计有重要影响n 是否含有高开发风险、时间紧迫、功能复杂的是否含有高开发风险、时间紧迫、功能复杂的用例用例n 是否涉及重要技术研

20、究或新技术高风险是否涉及重要技术研究或新技术高风险n 是否代表关键的核心的组织业务流程是否代表关键的核心的组织业务流程n 是否比较容易是否比较容易n 能否产生直接经济效益或降低成本能否产生直接经济效益或降低成本用例描述用例描述o 采用自然语言描述一个用例的功能。采用自然语言描述一个用例的功能。o 通过用例的事件流完全可以描述系统通过用例的事件流完全可以描述系统的功能性需求。的功能性需求。o 主要内容：用例名、基本路径、备选主要内容：用例名、基本路径、备选路径路径o 由用户对用例进行评审由用户对用例进行评审结构化的用例描述文本结构化的用例描述文本o 描述一个用例，应说明以下细节：描述一个用例，应

21、说明以下细节：o 用例名用例名o 前置条件（前置条件（PrePreConditionsConditions）o 后置条件（后置条件（Post-ConditionsPost-Conditions）o 扩充点（扩充点（Extension PointsExtension Points）o 事件流事件流o 基流（基流（Basic FlowBasic Flow）o 分支流（分支流（SubflSubflo owsws）（可选）（可选）o 替代流（替代流（Alternative FlowsAlternative Flows）UML需求获取需求获取o 建立用例模型时应注意的问题建立用例模型时应注意的问题o 在

22、大型的软件开发过程中，用例图可在大型的软件开发过程中，用例图可以分层建立。以分层建立。o 在建模的开始阶段，注意保持用例图在建模的开始阶段，注意保持用例图是对系统功能需求的高层次刻画，不要是对系统功能需求的高层次刻画，不要对它进行过细的分解。对它进行过细的分解。UML需求获取需求获取o 用例的组织用例的组织o 较大的系统往往包含许多用例，为了更较大的系统往往包含许多用例，为了更好的理解和管理它们，我们可以通过两好的理解和管理它们，我们可以通过两种方式进行组织：种方式进行组织：n 用用“包（包（PackagC）”来组织来组织n 用用例的级别层次关系来组织用用例的级别层次关系来组织产品分销系统用例

23、图产品分销系统用例图总体图总体图 销售中心结算中心销售网点系统维护配送中心公用部分查询统计产品分销系统用例图产品分销系统用例图销售中心子系统销售中心子系统 产品资料管理 采购管理 虚拟库存维护 批销管理 预订管理 供货商信息管理 客户信息管理产品分销系统用例图产品分销系统用例图批销管理批销管理 预订发货处理缺货处理网点添货客户退货网点退货向网点主发向客户主发日常配送计划处理退货调拨主发批销产品分发批销管理人员交互图分析交互图分析o 顺序图展示了一个用例的行为，可以只顺序图展示了一个用例的行为，可以只描述基本路径描述基本路径o 分析阶段的顺序图不过多关心细节，可分析阶段的顺序图不过多关心细节，可

24、以等到设计阶段再细化以等到设计阶段再细化o 在分析阶段可以不使用顺序图，根据实在分析阶段可以不使用顺序图，根据实际情况确定际情况确定三种对象类型三种对象类型o 分析模型中最常用的分析模型中最常用的三种对象类型，它三种对象类型，它们是：们是：n 实体（实体（Entity）n 边界（边界（Bountary）n 控制（控制（Control）实体对象实体对象o 实体对象主要的任务是装载信息，同时实体对象主要的任务是装载信息，同时也具有相关的行为，但是这部分行为主也具有相关的行为，但是这部分行为主要包括那些和实体对象自身信息直接相要包括那些和实体对象自身信息直接相关的操作。关的操作。边界对象边界对象o

25、边界对象用于描述拟建系统内部运作与边界对象用于描述拟建系统内部运作与外部环境之间的交互。外部环境之间的交互。o 边界对象主要用于描述三种类型的内容：边界对象主要用于描述三种类型的内容：n 拟建系统和用户的界面拟建系统和用户的界面n 拟建系统和外部系统的接口拟建系统和外部系统的接口n 拟建系统与设备的接口拟建系统与设备的接口边界对象边界对象o 通过检查在用例图中的参与者与用例之通过检查在用例图中的参与者与用例之间的关系，我们可以识别出边界对象。间的关系，我们可以识别出边界对象。o 通常，在分析模型中，每一对参与者通常，在分析模型中，每一对参与者用例都构成了一个边界对象。用例都构成了一个边界对象。

26、控制对象控制对象o 控制对象用于描述对一个用例所特有的控制对象用于描述对一个用例所特有的事件流的控制行为。事件流的控制行为。o 控制对象相当于协调人，它自己通常不控制对象相当于协调人，它自己通常不处理具体的任务，但它知道那些类有能处理具体的任务，但它知道那些类有能力完成具体的任务。力完成具体的任务。o 通常一个用例对应一个控制类。通常一个用例对应一个控制类。顺序图顺序图 : Customer : OrderForm : OrderControl : LineItem : Order : Product1: select item2: select item3: add item4: confi

27、rm order5: confirm order6: create order7: update inventory协作图协作图o 作为对顺序图的补充，协作图可以着重作为对顺序图的补充，协作图可以着重描述对象之间的静态链接关系描述对象之间的静态链接关系 : OrderForm : OrderControl : LineItem : Order : Product : Customer1: select item2: select item3: add item4: confirm order5: confirm order6: create order7: update inventory初步

28、类图：初步类图：o 从交互图和从交互图和对象图可以对象图可以得到分析类得到分析类图，此时类图，此时类图并不完善，图并不完善，需要到设计需要到设计阶段进一步阶段进一步优化优化购买构建和修改购买构建和修改o 电子商务企业可以购买一个解决方案或解决电子商务企业可以购买一个解决方案或解决方案的一部分，当所购买的软件包不能满足方案的一部分，当所购买的软件包不能满足企业的特定要求时，需要自行开发软件包企业的特定要求时，需要自行开发软件包o 大多数企业采用混合解决方案，即保护已有大多数企业采用混合解决方案，即保护已有的投资，又升级了系统功能的投资，又升级了系统功能o 也有的企业考虑对所购得的包进行扩展开发也

29、有的企业考虑对所购得的包进行扩展开发或修改，以适合本企业的需求或修改，以适合本企业的需求o 解决方案的确定要充分考虑经济性问题解决方案的确定要充分考虑经济性问题经典电子商务系统功能分析经典电子商务系统功能分析o B2C零售系统基本需求：注册，动态信息展零售系统基本需求：注册，动态信息展示，用户反馈，企业信息查询，商品信息显示，用户反馈，企业信息查询，商品信息显示，订单管理，汇总统计功能，用户管理，示，订单管理，汇总统计功能，用户管理，销售企业界面，公告板，留言板，客服中心，销售企业界面，公告板，留言板，客服中心，购物车，电子支付，广告管理，库存管理，购物车，电子支付，广告管理，库存管理，产品跟

30、踪，外部接口等，即：产品跟踪，外部接口等，即：商品管理子系统；交易子系统；客户管理或商品管理子系统；交易子系统；客户管理或客户关系管理子系统客户关系管理子系统经典电子商务系统功能分析经典电子商务系统功能分析o B2B电子商务基本需求：网上客户的注电子商务基本需求：网上客户的注册与管理，会员权限管理，商品信息的册与管理，会员权限管理，商品信息的分类录入和发布，网上在线信息管理，分类录入和发布，网上在线信息管理，网上商务流程管理，拍卖招标管理，电网上商务流程管理，拍卖招标管理，电子签证的识别及认证，在线支付，重要子签证的识别及认证，在线支付，重要信息管理，配送建议，信息管理，配送建议，BBS等等经

31、典电子商务系统功能分析经典电子商务系统功能分析o 物流配送系统基本需求：配送合约议物流配送系统基本需求：配送合约议定，配送计划制定，进货管理，收货定，配送计划制定，进货管理，收货管理，储放管理，出货管理，货物盘管理，储放管理，出货管理，货物盘点，货物追踪，客户助理，帐务管理，点，货物追踪，客户助理，帐务管理，报表管理等报表管理等经典电子商务系统功能分析经典电子商务系统功能分析o 企业信息门户基本需求：企业基本信企业信息门户基本需求：企业基本信息发布，企业动态与新闻发布，企业息发布，企业动态与新闻发布，企业产品和服务，企业产品信息目录与导产品和服务，企业产品信息目录与导航，搜索与索引，电子邮件与

32、客户反航，搜索与索引，电子邮件与客户反馈，用户访问统计，网站访问分析与馈，用户访问统计，网站访问分析与统计，个性化服务，电子社区等统计，个性化服务，电子社区等ATMATM实例分析实例分析o 两个参与者及注释两个参与者及注释o 三个用例三个用例Clientke huFinancial Centerjin rong zhong xinke hujin rong zhong xinjin rong ka huo xin yong kazhu ping mujie shu cao zuo ClientIdentityCardMainScreenFinancial CenterEndOperationA

33、TMATM实例分析实例分析o 用例图（不合适）用例图（不合适）IdentityCardMainScreenEndOperationDepositMoneyQueryBalanceWithdrawalMoneyEasyWithdralMoneyTransferMoneyChangePasswordPayTaxATMATM实例分析实例分析o 用例图（优化后）用例图（优化后）IdentityCardEndOperationDepositMoneyQueryBalanceWithdrawalMoneyEasyWithdralMoneyTransferMoneyChangePasswordPayTaxA

34、TMATM实例分析（类图）实例分析（类图）ATMATM实例分析（类图）实例分析（类图）ATMCasherInternetBankInfoCardn1n1TransactionAgentnnnnATMManager1n1n1n n1DailyLogn1n1Sessionn1n11n1nn1n1 : Client : ATM : ATMManager : Bank1: InsertCard2: passWord?3: InputThePassword4: CheckThePassword5: CheckInformation6: PWIsRight7: PWIsRight8: Selection9

35、: HowMuch?10: KeyboardIn11: AskFor12: Bank13: OK14: DataBase15: Conform16: CashATMATM实例分实例分析（顺析（顺序图）序图）分析类的概念分析类的概念o 分析模型中的所有类都是分析模型中的所有类都是”分析类分析类”。o 从设计视角看待，从设计视角看待， “分析类分析类”忽略实现忽略实现细节，相当粗略。细节，相当粗略。o “分析类分析类”是为定义设计类做准备的。是为定义设计类做准备的。确定确定“分析类分析类”o 这个步骤就是确定一组备选的、能够执行用这个步骤就是确定一组备选的、能够执行用例中行为的例中行为的“分析类分

36、析类”。o 在确定在确定“分析类分析类”时，使用三种不同的构造时，使用三种不同的构造型识别和提取潜在的型识别和提取潜在的“分析类分析类”，它们是：，它们是：实体类、控制类、边界类。实体类、控制类、边界类。确定确定“分析类分析类”o 边界类：每个参与者和用例的交互存在边界类：每个参与者和用例的交互存在一个对应的边界类。一个对应的边界类。o 控制类：一般一个用例对应一个控制类。控制类：一般一个用例对应一个控制类。o 实体类：这个主要看用例里面用到的持实体类：这个主要看用例里面用到的持久的数据对象。用到数据库对象时，可久的数据对象。用到数据库对象时，可能就使用了实体类。能就使用了实体类。类的获取类的

37、获取o 类的获取有两种办法：类的获取有两种办法：n 从用例模型和用例描述中找出名词，从用例模型和用例描述中找出名词，有有4种名词：参与者、类、类的属性、种名词：参与者、类、类的属性、其他描述性名词。能够找出实体类其他描述性名词。能够找出实体类n 分析参与者与用例对，找出边界类分析参与者与用例对，找出边界类n 另一种是检查交互图中的对象，研究另一种是检查交互图中的对象，研究对象具有的共同属性和操作来发现类。对象具有的共同属性和操作来发现类。识别分析类操作识别分析类操作o 分析类在顺序图里要承担一定的分析类在顺序图里要承担一定的“职责职责”o “职责职责”是对其他对象发送来的消息的是对其他对象发送

38、来的消息的响应。也可能是对外部的响应，也可能响应。也可能是对外部的响应，也可能是维护自身信息所必要的是维护自身信息所必要的“职责职责”。o 这种行为在分析类演化成设计类时，它这种行为在分析类演化成设计类时，它可能对应一个或多个具体的类的可能对应一个或多个具体的类的“操操作作”。o 通常有两种方法为类识别通常有两种方法为类识别操作操作：责任驱动法、：责任驱动法、通过交互图通过交互图责任驱动法识别类责任驱动法识别类“操作操作”o 责任驱动主要基于两个概念：责任驱动主要基于两个概念：n 第一，一个对象在系统中负有一定的第一，一个对象在系统中负有一定的责任，例如它要获得特定的信息（了责任，例如它要获得

39、特定的信息（了解的责任）和为其他对象提供特定的解的责任）和为其他对象提供特定的信息（做的责任）；信息（做的责任）；n 第二，一个对象与其它对象合作来提第二，一个对象与其它对象合作来提供所要求的服务。供所要求的服务。责任驱动法识别类责任驱动法识别类“操作操作”o 责任驱动法为类识别责任驱动法为类识别“操作操作”o 责任分析的一种有用技术责任分析的一种有用技术CRC（ClassResponsibilityCollaboration）卡技）卡技术。术。为类分配操作为类分配操作CRCCRC卡卡 类的名称类的名称类的名称类的名称责任责任1 1责任责任1 1的协作者的协作者对该类的描述对该类的描述责任责任

40、2 2责任责任2 2的协作者的协作者责任责任3 3责任责任3 3的协作者的协作者CRCCRC卡卡用交互图描述用例来为类识别用交互图描述用例来为类识别“操作操作”o 面向对象系统是通过对象间相互发送消面向对象系统是通过对象间相互发送消息来完成系统功能的。息来完成系统功能的。o 这些对象间传递的消息就可以映射为对这些对象间传递的消息就可以映射为对象的操作。象的操作。分析类操作的设计分析类操作的设计o 一个类的操作太多或太少都是不合适的，一个类的操作太多或太少都是不合适的，太多说明这个类过于复杂，这时要特别太多说明这个类过于复杂，这时要特别分析一下这个类是否有很高的内聚，通分析一下这个类是否有很高的

41、内聚，通常情况下应该将过于复杂的类拆成多个常情况下应该将过于复杂的类拆成多个较小的类。较小的类。o 如果类中的操作太少，有时甚至没有操如果类中的操作太少，有时甚至没有操作，全部都是属性，这时应该分析这个作，全部都是属性，这时应该分析这个类，判断其是否能够合并到其他类中。类，判断其是否能够合并到其他类中。识别分析类属性识别分析类属性o “分析类分析类”要能执行相应的操作，它要依要能执行相应的操作，它要依赖于两方面的内容：赖于两方面的内容：n 一方面是利用它自己保存的信息，即一方面是利用它自己保存的信息，即它的属性；它的属性；n 另一方面是利用其他的类另一方面是利用其他的类 。获得属性的渠道获得属

42、性的渠道o 属性的来源有许多。获得属性的渠道有属性的来源有许多。获得属性的渠道有几个：几个：o 通过查看用例文档，寻找名词。通过查看用例文档，寻找名词。n 通常，在用例文档中用名词表示属性，通常，在用例文档中用名词表示属性，如如“图书的出版社、价格等图书的出版社、价格等”。n 这些名词中有些是对象；有些是参与这些名词中有些是对象；有些是参与者；有些是属性。确定是对象还是属者；有些是属性。确定是对象还是属性，答案在于要实现的功能。性，答案在于要实现的功能。获得属性的渠道获得属性的渠道o 通过查看文档，发现系统要收集的信通过查看文档，发现系统要收集的信息，这些信息就是类的属性。息，这些信息就是类的

43、属性。如为了下如为了下订单而搜集的供货商的姓名、电话及银订单而搜集的供货商的姓名、电话及银行帐号等。行帐号等。o 如果已经定义了数据库结构，则数据如果已经定义了数据库结构，则数据库表中的字段就是属性。库表中的字段就是属性。属性的特点属性的特点o 类的属性不宜太多，如果某个类的属性太多，类的属性不宜太多，如果某个类的属性太多，最好将其分解成更小的类。最好将其分解成更小的类。o 同样，属性也不要太少，太少的情况下应进同样，属性也不要太少，太少的情况下应进行类的合并。行类的合并。属性的类型属性的类型o 属性的类型指属性值的类型。属性的类型指属性值的类型。o 可以是基本数据类型，例如整数、实数、布可以

44、是基本数据类型，例如整数、实数、布尔型、字符串型等，也可以是用户自定义的尔型、字符串型等，也可以是用户自定义的类型。类型。o 分析阶段一般不需要确定属性的类型分析阶段一般不需要确定属性的类型描述类之间的关系描述类之间的关系o 类之间的关系有关联关系、聚合关系、类之间的关系有关联关系、聚合关系、组合关系、泛化关系、依赖关系。组合关系、泛化关系、依赖关系。n 1）找出关系。有的类只和其它一个类）找出关系。有的类只和其它一个类有关系，而有些类同时和其它多个类有关系，而有些类同时和其它多个类存在关系。在一个面向对象系统中，存在关系。在一个面向对象系统中，不存在完全独立的类。不存在完全独立的类。n 2）

45、命名关系。最好给每个关系取一）命名关系。最好给每个关系取一个名字以标识出类之间的关系。通常个名字以标识出类之间的关系。通常可以使用动词和动词短语来标识关系。可以使用动词和动词短语来标识关系。类之间的关系类之间的关系n 3）设置关联重数。关联的重数）设置关联重数。关联的重数（MulhpliCity）依赖于系统的具体）依赖于系统的具体需求，要根据需求文档的上下文进行需求，要根据需求文档的上下文进行分析。在系统分析阶段，不必特别地分析。在系统分析阶段，不必特别地考虑重数。考虑重数。n ）设置关联的其它特性。如果需要）设置关联的其它特性。如果需要的话，可以为每个关联设置关联角色的话，可以为每个关联设置

46、关联角色名、构造型、限定符等细节。名、构造型、限定符等细节。寻找关系的具体方法如下：寻找关系的具体方法如下：o 要寻找关系，可以检查交互图，大多数关系信要寻找关系，可以检查交互图，大多数关系信息已经在交互图中列出。息已经在交互图中列出。n (1)(1)如果一个类向另一个类发出消息，则它如果一个类向另一个类发出消息，则它们必有关系，并且通常是关联或依赖关系。们必有关系，并且通常是关联或依赖关系。n （2 2）检查类的整体和部分关系。）检查类的整体和部分关系。任何由其任何由其他类组成的类都参与聚合他类组成的类都参与聚合.n （3 3）检查类的泛化关系，寻找相似对象的）检查类的泛化关系，寻找相似对象的不同点，将不同的部分下降为特殊的类，将不同点，将不同的部分下降为特殊的类，将共性的部分上升为基础类，两者之间的关系共性的部分上升为基础类，两者之间的关系确定为泛化关系。确定为泛化关系。 发现类关系发现类关系 课程注册管理员 : 注册管理员数学18 : 课程3.加入学生借借以以确确定定类类图图关关联联关关系系的的协协作作图图发现类之间的关系发现类之间的关系o 除了上述方法外，判断两个类之间到底有没除了上述方法外，判断两个类之间到底有没有关联关系，要看它们之间是否存在下表中有关联关系，要看它们之间是否存在下表中的关系：的关系：判断两个类之间到底有无关联关系判断两个类之间到