销售系统的UML建模分析与详细设计

需求分析


确定参与者 即 系统管理员|经理，收银员，采购员 识别用例 收银员
系统管理员 采购员


识别用例

收银员 能够通过该系统进行销售商品活动。 首先登录系统，验证身份成功后，获取 商品信息，然后将销售信息更新，最后 对客户进行商品销售。
识别用例 -收银员用例图
识别用例

系统管理员 负责本系统的系统维护。系统管理员负责 员工信息管理、供货商信息管理以及系统维护 等。每种管理者都通过自己的用户名称和密码 登录到各自的管理系统中
识别用例 -系统管理员用例图
识别用例

采购员 能够通过该系统进行订货管理活动。 采购员首先根据经营情况统计所缺的生 产资料。
识别用例 -采购员用例图
查看顺序图 幻灯片 33
主要事件流
用例编号：UC—03 用例名：修改商品信息 用例描述：经理、采购员修改一种商品的信息并保存到数据库 参与者：经理、采购员 前置条件：登录成功，数据库中存在这种商品的记录 后置条件：经理、采购员可以继续其他商品的相关操作。 基本路径： 1.经理、采购员进入商品信息界面GoodsDialog，并在界面中点击修改商品信息，弹出 FindGoodsDialog对话框。 2．经理、采购员输入要修改的商品的ID，单击按钮“OK”提交。 3．界面FindGoodsDialog将查询的信息传递到控制对象Control。 4．控制对象到数据库中查询的该商品信息对象是否存在并判断是否可以修改。 5.界面GoodsDialog显示商品的详细信息，经理、采购员将该商品的信息进行编辑，然后单击按钮 “更新”； 6．控制对象Control将该商品的信息进行保存。 7．控制对象将修改成功的信息返回到界面GoodsDialog并显示。 8．经理、采购员从GoodsDialog界面获得修改成功的信息。 扩展点： 4a. 控制对象检测到该商品信息对象无法进行修改，用例终止。 补充说明：无。
系统 功能图
识别用例-用例模型元素概述



用例模型的基本组成元素是用例、参与者和通讯关联。 用例用于描述系统的功能。用于表示系统所提供的服 务，它定义了系统是如何被参与者所使用的， 参与者是与系统进行交互的外部实体，它可以是系统 用户，也可以是其它系统或硬件设备参与者表示人或 事物与系统发生交互时所扮演的角色，而不是特定的 人或者特定的事物； 通讯关联用于表示参与者和用例之间的对应关 系，如依赖关系，实现关系，泛化关系等。
1.组件图和部署图
系统需求
专卖店管理系统包括三个基本的部分：
（1） 收银员: 收银员可以查看商品价格，查 看会员信息，修改会员消费记录，和结账的权限。 而结帐又分为前台收银和当天营业结算的任务。 即系统有相应任务的功能。 （2） 系统管理员|经理 :系统管理员|经理有对 会员信息的增删改查，以及对商品信息的增删改 查的权限。因此，专卖店管理系统也会有对应的 需求和功能 （3）采购员 : 采购员有查看、添加、修改， 删除商品的信息的权限。
查看顺序图幻 灯片 34
主要事件流
查看商品信 息
用例编号：UC—02 用例名：查看商品信息 用例描述：参与者根据商品编号查询输入商品的商品信息的过程。 参与者：经理、采购员 前置条件：登录成功 后置条件：经理、采购员可以修改商品的相关信息。 基本路径： 1.经理、采购员进入商品信息界面GoodsDialog，并在界面中点击查看商品信息，弹出 FindGoodsDialog界面。 2．经理、采购员输入要查看的商品的ID，单击按钮“OK”提交。 3.界面GoodsDialog将商品查询的信息传递到控制对象Control; 4.控制对象从数据库中得到所查询的商品信息; 5.控制对象Control将得到的信息返回到界面GoodsDialog并显示; 6.经理、采购员从GoodsDialog获得自己想要的商品信息。 扩展点：无。 补充说明：无。
用例识别的依据
用例实例是系统执行的一系列动作，这些动作将生成 特定主角（参与者）可观测的结果值。一个用例定 义一组用例实例。 通俗来说 Actor使用系统达到某个目标
用例的特征： 用例总是由参与者初始化



用例为参与者提供值
用例具有完全性
需求分析
（1）采购员根据商品库存情况判断采购用品， 对需要订购产品信息统计订货的，并对产品入 库等处理。 （4）收银员为客户提供售货服务时，接受客户 购买产品，根据系统的定价计算出产品的总价， 客户付款，系统自动保存客户购买记录。 （5）系统管理员负责本系统的系统维护。系统 管理员负责员工信息管理、供货商信息管理以 及系统维护等。每种管理者都通过自己的用户 名称和密码登录到各自的管理系统中。
wenku.baidu.com
主要事件流
登录
用例编号：UC—01 用例名：登录 用例描述：完成一次登录的完整过程。 参与者：经理、收银员、采购员 前置条件：系统正常运行 后置条件：如果登录成功，可以进行查询等相关操作。 基本路径： 1．经理（收银员、采购员）希望通过专卖店销售系统进行某一项操作； 2．经理（收银员、采购员）登录系统，在登录页面Login_Form输入自己的用户名和密码并提交； 3．系统将经理（收银员、采购员）提交的用户名和密码传递到的Control类中检查用户合法身份的 方法中。该方法将用户信息与数据库中的用户信息进行比较，检查用户信息中是否存在此用户的信 息; 4．检查通过，将验证结果返回到登录界面显示; 5．经理（收银员、采购员）在登录界面获得验证结果。 扩展点： 4a. 系统标识码有效性检查失败 4a1. 系统通知用户，重新输入识别码 4a2. 经理（收银员、采购员）重新输入识别码 4b. 经理（收银员、采购员）通过系统提示找回密码 4c. 经理（收银员、采购员）输入无效次数超过限制（不超过3次），系统显示提示信息，用例终止。 补充说明： 无。
用例描述——用例规约内容



每一个用例的用例规约都应该包含以下内容： 1用例描述（简要说明）:对用例作用和目的的简要描述。
2 前置条件: 执行用例之前系统必须所处的状态。例如，前置
条件是要求用户有访问的权限或是要求某个用例必须已经执行完。 3 后置条件:用例执行完毕后系统可能处于的一组状态。例如， 要求在某个用例执行完后，必须执行另一个用例。 4 事件流:事件流包括基本流（基本路径）和备选流。基本流描 述的是用例的基本流程，是指用例“正常”运行时的场景。 5 用例场景:同一个用例在实际执行的时候会有很多不同的情况 发生，称之为用例场景，也可以说用例场景就是用例的实例。 6 特殊需求: 特殊需求指的是一个用例的非功能性需求和设计 约束。特殊需求通常是非功能性需求，包括可靠性、性能、可用 性和可扩展性等。例如法律或法规方面的需求、应用程序标准和 所构建系统的质量属性等。
销售系统的UML建模分析与 详细设计
指导老师：*** weibo昵称：年年有余事事 顺利
目录


（一）系统需求
1.系统功能图
（二）需求分析
1.识别用例 2.主要事件流



（三）静态结构模型
1.类图
（四）动态行为模型
1.顺序图和协作图 2.活动图和状态图

（五）数据库模型 （六）物理模型