UML期末报告Word格式.docx
《UML期末报告Word格式.docx》由会员分享，可在线阅读，更多相关《UML期末报告Word格式.docx（21页珍藏版）》请在冰豆网上搜索。
安全性管理
系统表管理
销售活动系统
分析销售数据
涉众及其关注点：
--收银员：
希望能够准确、快速地输入，而且没有支付错误，因为如果少收货款，将其薪水中扣除
--售货员：
希望自动更新销售提成
--顾客：
希望以最小代价完成购买活动并得到快速服务。
希望便捷、清晰地看到
所输的商品项目和价格。
希望得到购买凭证，以便退货。
--公司：
希望准确地记录交易，满足顾客需求。
希望确保记录了支付授权服务的
支付票据。
希望有一定的容错性，即使在某些服务器构建不可用时（如远程
信用卡验证），也能够完成销售。
希望能够自动、快速地更新账务和库存信息。
--经理：
希望能够快速地执行超空操作，并易于更正收银员的不正当操作。
--政府税收代理：
希望能才能够每笔交易中抽取税金。
可能存在多级税务代理，
比如国家级、州级和县级
--支付授权服务：
希望接收到格式和协议正确的数字授权请求。
希望准确计算对
商店的应付款。
前置条件（或者成功保证）：
收银员必须经过确认和认证。
后置条件（或者基本流程）：
存储销售信息。
准确计算税金。
更新账务和库存信
息。
记录提成。
生成票据。
记录支付授权的批准。
主成功场景：
1、顾客携带所购商品或服务到收银台通过POS机付款。
2、收银员开始一次新的销售交易
3、收银员输入商品条码。
4、系统逐条记录出售的商品，并显示该商品的描述、价格和累计额。
价格通过一组价格规则来计算。
收银员重复3~4步，直到输入结束。
5、系统显示总额和所计算的税金。
6、收银员告知顾客总额，并请顾客付款。
7、顾客付款，系统处理支付。
8、系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理和提成）和库存系统（更新库存）。
9、系统打印票据。
10、顾客携带商品和票据离开（如果有）。
扩展（或者替代流程）：
*a、经理在任意时刻要求进行超控操作
1、系统进入经理授权模式。
2、经理或收银员执行某一经理模式的操作。
例如，变更现金结余，恢复其
他登录者中断的销售交易，取消销售交易等
3、系统回复到收银员授权模式。
*b、系统在任意时刻失败:
为了支持恢复和更正账务处理，要保证所交易的敏感状态和事件都能够从场
景的任何一步中完全恢复。
1、收银员重启系统，登录，请求恢复上次状态。
2、系统重建上次状态。
2a、系统在恢复过程中检测到异常：
1、系统同收银员提示错误，记录此错误，并进入一个初始状态
2、收银员开始一次新的销售交易。
1a、客户或经理需要恢复一个中断的销售交易
1、收银员执行恢复操作，并且输入ID以提取对应的销售交易
2、系统显示被恢复的销售交易状态及其小计
2a、未发现对应的销售交易。
1、系统向收银员提示错误。
2、收银员可能会开始一个新销售交易，并重新输入所有商品。
3、收银员继续该次销售交易（可能要输入更多的商品或处理支付）。
2-4a、顾客告诉收银员其免税状况（例如：
年长者，本国人等）。
1、收银员进行核实，并输入免税状态编码。
2、系统记录该状态编码（在计算税金时使用）
3a、无效商品ID（在系统中未发现）：
1、系统提示错误并拒绝输入该ID。
2、收银员响应该错误。
2a、商品ID可读（例如，数字型的UPC（通用商品代码））：
1、收银员手工输入商品ID。
2、系统显示商品的价格和描述。
2a、无效商品ID：
系统提示错误。
收银员尝试其它方式。
2b、系统内不存在该商品ID，但是商品附有价签：
1、收银员请求经理执行超控操作。
2、经理执行相应的超控操作。
3、收银员选择手工输入价格，输入价签上的价格，并请求对该价目
进行标准计税。
（因为没有产品信息，计税引擎无法确定如何计税）。
2c、收银员通过执行寻找产品帮组以获取正确的商品ID及其价格。
2d、另外，收银员可以向其他员工询问商品ID或价格，然后手工输入
ID或价格（参见以上内容）
3b、当有多个商品项目属于同一类别的时候（例如5个汉堡），不必记录每一个
商品项目的唯一标识：
1、收银员可以输入类别的标识和商品的数量
3c、需要手工输入类别和价格（例如：
花卉或纸牌及其价格）：
1、收银员手工输入特定的类别代码及其价格。
3-6a、顾客要求收银员从所购商品中去掉一项：
所去除商品的价格必须小于收银员权限，否则需要经理执行超控操作。
1、收银员输入商品ID并将其删除。
2、系统删除该项目并显示更新后的累计额
2a、商品价格超过了收银员权限：
1、系统提示错误，并建议经理超控。
2、收银员请求经理超控，完成超控后，重做该操作。
3-6b、顾客要求收银员取消销售交易：
1、收银员在系统中取消销售交易。
3-6c、收银员延迟销售交易：
1、系统记录销售交易信息，使其能够在任何POS登录中恢复操作。
2、系统显示用来恢复销售交易的“延迟票据”，其中包含商品项目和销售交
易ID。
4a、系统定义的商品价格不是顾客预期的价格（顾客对此产生抱怨并要求减价）：
1、收银员请求经理批准
2、经理执行超控操作。
3、收银员手工输入超控后的价格。
4、系统显示新价格。
5a、系统检测到与外部税务计算系统服务的通信故障：
1、系统在POS机节点上重启此服务，并继续操作。
1a、系统检测到该服务无法重启。
1、系统提示错误。
2、收银员手工计算和输入税金，或者取消该销售交易。
5b、顾客声称他们符合打折条件（例如，是雇员或重要顾客）
1、收银员提出打折请求。
2、收银员输入顾客ID。
3、系统按照打折规则显示折扣总计。
5c、顾客要求兑现帐户积分，用于此次销售交易：
1、收银员提交积分请求。
3、系统应用几分直到价格为零，同时扣除结余积分。
6a、顾客要求现金付款，但携带的现金不足：
1、顾客要求使用其他支付方式。
1a、顾客要求取消此次销售交易，收银员自傲系统上取消该销售交易。
7a、现金支付：
1、收银员输入收取的现金额。
2、系统显示找零金额，并弹出现金抽屉。
3、收银员放入收取的现金，并给顾客找零。
4、系统记录该现金支付。
7b、信用卡支付：
1、顾客输入信用卡帐户信息。
2、系统显示其支付信息以备验证
3、收银员确认。
3a、收银员取消付款步骤。
1、系统回复到“商品输入”模式
4、系统向外部支付授权服务系统发送支付授权请求，并请求批准该支付
4a、系统检测到与外部系统协作时的故障：
1、系统向收银员提示错误
2、收银员请求顾客更好支付方式
5、系统收到批准支付的应答并提示收银员，同时弹出现金抽屉（以便放入
签名后的信用卡支付票据）
5a、系统收到拒绝支付的应答：
1、系统向收银员提示支付被拒绝。
2、收银员请求顾客更换支付方式。
5b、应答超时
1、系统提示收银员应答超时
2、收银员重试，或者请求顾客更换支付方式。
6、系统记录信用卡支付信息，其中包括支付批准。
7、系统显示信用卡支付的签名输入机制。
8、收银员请求顾客签署信用卡支付。
顾客输入签名。
9、如果在纸制票据上签名，则收银员将该票据放入现金抽屉并关闭抽屉。
7c、支票支付……
7d、记账支付……
7e、收银员取消支付步骤：
1、系统回到“商品输入”模式。
7f、顾客出示优惠券：
1、在处理支付之前，收银员记录每张优惠券，系统扣除相应金额。
系统记
录已使用的优惠券以备账务处理之用。
1a、输入的优惠券不适用于所购商品:
1、系统向收银员提示错误。
9a、存在产品回扣：
1、系统对每个具有回扣的商品给出回扣表单和票据
9b、顾客索要赠品票据（不显示价格）
1、收银员请求赠品票据，系统给出赠品票据。
9c、打印票据
1、如果系统检测到错误，给出提示
2、收银员更换纸张
3、收银员请求打印其他票据
特殊需求：
●使用大尺寸平面显示器触摸屏UI。
文本信息可见距离为1米。
●90%的信用卡授权响应时间小于30秒。
●由于某些原因，我们希望在访问远程服务（如库存系统）失败的情况下具有比较强的恢复功能。
●支持文本显示的语言国际化
●在步骤3和步骤7中加入可插拔的业务规则
●……
技术与数据变元表:
*a、经理超控需要刷卡（由读卡器读取超空卡）或在键盘上输入授权码。
3a、商品ID可以用条码扫描器（如果有条形码）或键盘输入
3b、商品ID可以使用UPC（通用产品代码）、EAN（欧洲物品编码）、JAN（日本物品编码）或SKU（库存单位）等任何一种编码方式。
7a、信用卡帐户信息可以用读卡器或键盘输入
7b、记录在纸质票据上的信用卡支付签名。
但我们预测，两年内会有许多顾客将希望使用数字签名。
发生频率：
可能会不断地发生
未解决问题：
●税法如何变化？
●研究完成服务的回复问题。
●针对不同的有任务需要怎样进行定制？
●收银员是否必须在从系统注销后带走他们的现金抽屉？
●顾客是否可以直接使用读卡器，还是必须由收银员完成？
●服务器崩溃导致数据丢失如何解决？
●不同等级的计价方案如何权衡？
●并发控制。
3补充规格说明
功能性
（通常跨越多个用例的功能性）
1.日志和错误处理
在持久性存储中记录所有错误
2.可插拔规则
在几个用例的不同场景点执行任意一组规则，以支持对系统功能的定制
3.安全性
任何使用都需要经过用户认证
可用性
人性因素
顾客将能够看到POS大屏幕显示器的显示。
因此：
1.应该在1米外轻松看到文本
2.避免使用一般色盲人群难以辨认的颜色
快捷，无错的销售交易处理极为重要，因为购买者希望快速的离开，否则会给他们的购买体验（和对销售员的评价）带来负面影响。
收银员的视线通常停留在顾客或商品，而不是计算机显示器上。
因此，提示和警告应该通过声音传递而不仅仅是通过图像传递。
可靠性
1.可恢复性
如果在使用外部服务（支付授权，账务系统……..）时出错，为了完成销售交易，需要尝试采用本地方案（如存储和转发）加以解决。
对此需要更深入的分析…..
2.性能
正如“人性因素”一节中所提到的，购买者希望非常快速地完成销售处理过程。
外部的支付授权是瓶颈之一。
我们的目标是：
90%的情况下，能够在1分钟之内完成授权。
可支持性
1.可适应性
POS的不同客户在处理销售时有其特有的业务规则和处理需求。
因此。
在场景中的几个预订之处（例如，当开始新的销售交易时，当增加新的商品时），需要能够启用可插拔的业务规则。
2.可配置性
不同的客户对其POS系统有不同的网络配置需求。
例如，采用胖客户端或瘦客户端，两层或多层物理结构等等。
除此之外，他们还要求具备修改配置的能力，以便适应其变更业务和性能的需求。
因此，系统应该具备一定的可配置能力以适应这些需求。
对此需要进一步分析，以发现哪些地方需要灵活性和灵活性的程度，以及实现这种灵活性所需的工作。
购买构件
税金计算器。
必须支持用于不同国家的可插拔计算器。
接口
1.重要硬件和接口
1）触摸屏（操作系统将此视为普通监视器，且触摸动作也视为鼠标事件）。
2）条形码激光扫描仪（通常附加在一种特殊键盘上，扫描输入在软件中视为见键盘输入）
3）票据打印机
4）信用卡，借记卡读卡器
5）签名读取装置
2.软件接口
由于存在众多外部协作系统（税金计算器，账务，库存，……..），我们需要采用不同的接口，接入不同的系统。
4业务规则（可选）
ID
规则
可变性
来源
规则1
购买者折扣规则。
示例：
员工：
20%折扣额
优先顾客：
10%折扣额
高级：
15%折扣额
高
每个零售商有不同规则
零售商政策
规则2
销售（交易级）折扣规则适用于税前总额。
如果超过100美元，折扣额为10%，每周一折扣额为5%
每天上午9点到10点豆腐的折扣额为50%
每个零售商有不同的规则，每天或每小时都可能改变
规则3
产品（商品级）折扣规格
割草机本周折扣额为10%
汉堡买二送一
二领域对象分析
1领域类图
本人找概念类的策略是：
确定名词短语
在用例中找到的名词为候选的概念类。
名词有：
顾客，商品，服务，POS机付款处，收银员，销售，商品标识，商品，商品描述，价格，累计额，税金，付款，账务系统，库存系统，票据，收取的现金额，找零金额，现金抽屉。
领域类及其之间的关联（领域类图）：
2领域类说明
在上图中有概念类：
CashPayment：
现金付款，顾客为其所购的商品买单，与Sale为1对1的Paid-by（付款）关联关系。
Customer：
顾客，在这个系统里有很多的顾客，为了以后的账目管理，可能顾客类只有一个顾客ID，它与Sale类为1对1的Is-for（属于）关系。
Sale：
交易，这是一个比较重要的类，它与很多的概念类都有关联，它是后面很多业务领域的基础，通过上面介绍已经知道了与CashPayment和Customer的关系，它与SalesLineitem为1对多的Contained-in（包含）关系，与Ledger为多对1的LogsCompleted（完成账目）的关系，与Register为0到1对1的Capturedon（捕获）关系。
SalesLineitem：
销售清单，为一个顾客一次所购买的商品的清单，它与Item类是0….1对多的Records-Sale-of（记录销售）关系，一个购物清单里有很多的商品。
Ledger：
账单，为这部POS机的销售记录，包含里很多的销售，就像日志一样。
它与Sale为1对多的Logs-completed（记录日志）关系，与Store为1对1的Records-accounts-for（记录统计）的关系。
ProductCatalog：
产品目录，表示仓库中开始的存货。
它与Store为1对多的Used-by（被使用）关系，表示仓库要用Store来做最后的统计和其他做账的操作。
与ProductDescription为1对多的Contains（包含）关系，因为每类商品都有他的描述。
Store：
商店，在这里如同一个仓库一样，有出的商品（Ledger）还有剩下的商品（Item），这里的Ledger的计算为根据商家的内部规定如一个礼拜或一个月做一次账单。
它与很多的类都有关系，与Ledger的关系上面已经说了，与Register为1对多的Houses（拥有）的关系，这里只有注册的收银员才可以访问。
与Item的关系为1对多的Stocks（存储）的关系。
与ProductCatalog的关系上面已解释。
Register：
登记簿，表示每个合法的收银员都是经过注册的，有合法的权限的。
它与Store和Sale的关系上面已经解释。
与Casher为1对1的Works-on（使用）的关系，表示每个收银员都可以使用对应的Register来工作。
Cashier：
收银员，为POS系统的主要用户。
它比较简单，与Register的关系上面已经解释。
ProductDescription：
商品描述，记录每一类商品的相关信息。
它与ProductCatalog的关系上面已解释。
与Item为1对1的Describes（描述）关系，表示每件商品对应着一类的商品描述。
Item：
商品，顾客所购得某一件商品条目。
它与ProductDescription,Store,SalesLineitem的关系上面已解释。
三架构设计说明
1逻辑架构包图
在这里本人的逻辑架构是以层来组织的，选用的是网络协议栈中比较常见的UI界面层，Domain业务逻辑层，TechnicalServices技术服务层。
UI界面层：
Domain业务层：
TechnicalServicer技术服务层：
2各层的职责
用户界面层：
给用户提供操作的按钮和一些表单，并且显示一些需要用户注意的或需要的信息。
在这里还有一些特殊的，如这里收银员要扫描顾客购买的商品，以作为记录。
还有当顾客要通过信用卡来支付，这时还要提供给顾客一个输入密码的设备等等。
UI层的职责总的来说和用户直接打交道的，之间相互交互。
这里的ProcessSaleFrame就是一类界面的集合，是界面的一个Gof外观。
业务逻辑层：
这里实现了应用需求，如在这里一共分了Sales（销售），Pricing（价格），ServiceAccess（接受服务），Payments（付款），Inventory（存货清单），POSRuleEngine（规则），Taxes（税金）这几个应用模块，在这里都是一些粗粒度的表示，具体的底层操作没有表示，这里使用的Gof外观模式，只有一些简单的包和子系统，Pricing包就表示把定价时用到的工厂和策略组织在一起。
POSRuleEngine包就是一个子系统它具有独立的引擎，里面有一个POSRuleEngineFacade外观表示价格的规则实现，其具体的实现不用表示出来。
另外这些模块之间是相互关联的：
Sales中的Register收银员登陆要用到ServiceAccess中的ServiceFactory，同时ServiceFactory也要实现Inventory中的IInventoryAdapter接口查看存货清单，具体的联系上面图中已经表示。
技术服务层：
在这层中提供支持性技术服务的常用对象和子系统，例如数据库的接口或错误日志，这里的服务通常是独立于应用的，也可以在多个系统中复用。
这里的Persistence包中的DBFacade外观提供给Domain层以提供访问数据库的功能，类似的Log4J为提供生成日志的功能，Jess为第三方规则引擎，如给POSRuleEngine提供规则制定的接口，SOAP为简单的对象访问协议，如在Inventory和ServiceFactory中都要用到这些协议。
四用例实现
为了确定用例先画出系统的顺序图：
在这里有7个系统操作，为了清晰地设计用例，为这些系统操作编写了契约：
1、契约CO1：
makeNewSale
操作：
makeNewSale（）
交叉引用:
用例—处理销售
前置条件：
收银员成功登录
后置条件：
创建了Sale的实例s
s被关联到Register
s的属性被初始化
选择控制器类
1表示整个“系统”、“根对象”、特定设备或主要子系统的对象：
Store：
一种根对象
Register：
代表运行软件的特定设备的对象
POSSystem：
整个系统的名称
2表示用例场景中所有系统事件的接收者或处理器：
ProcessSaleHandler
ProcessSaleSession
由于系统操作不多，选择Register作为外观控制器是合适的。
2、契约CO2：
enterItem
enterItem（itemID:
ItemID,quantity:
integer）
职责：
输入（记录）一个商品项的信息，并将它记录到销售项中，显示商品描述信息和价格
交叉引用：
用况—处理销售
异常：
如果itemID无效,系统显示出错信息。
有正在进行的销售
创建了SalesLineItem的实例sli
sli被关联到当前Sale
sli.quantity赋值为quantity
基于itemID的匹配，sli被关联到ProductDescription
1.选择控制器
根据控制器模式，继续选择Register作为控制器。
2.是否要显示商品项目的描述和价格?
根据模型—视图分离原则,领域对象的职责不应涉及输出任务，尽管用例中声明该操作
之后要显示描述和价格。
但是有关显示所需的信息在设计中却必须予以考虑。
3.创建新的SalesLineItem
后置条件标明,该系统操作需要创建、初始化SalesLineItem实例，并把新创建的实例sli关联到Sale。
1）领域模型能启发我们，一个Sale可能包含多个SalesLineItem实例（即具有包含关系）。
所以，根据创建者模式，创建SalesLineItem实例的合适的候选者应是Sale对象。
2）后置条件标明，新实例sli的属性应当被初始化为quantity。
因此quantity应当作为参数传递给Sale，而Sale把它作为create消息的一个参数。
3）领域模型也能启发我们，Sale对象创建实例SalesLineItem后，应把新的实例添加到一个容器即对象集合中。
并以这种包含关系形成关联。
4）另一个显而易见的事实是，每一个销售项条目除了包含所购商品数量之外，还应该包含该商品的描述。
后置条件也标明，sli要基于itemID的匹配，与ProductDescription形成关联。
故相关的desc（Description对象标识）也应当作为参数传递给Sale。
3、契约CO3：
endSale
enterSale（）
指示系统销售项已录入完毕，显示销售项总额。
正在进行中的销售
Sale.isComplete被置为真
1.选择控制器类
同样的理由,使用Register作为控制器。
2.设置Sale.isComplete属性
谁应该负责将Sale的isComplete属性设置为true呢?
根据专家模式,应该由Sale本身完成此项任务,因为它拥有并维护isComplete属性,所以
Register将发送一个becomeComplete消息给Sale,Sale将isComplete属性设置为true。
4、契约CO4：
makePayment
makePayment（amount：
Money）
记录支付金额，计算余额及打印收据。
如果本次销售交易没有完成,系统显示出错信息，如果支付的金额小于所购买的商品总额,显示出错信息。
正在进行中的销售。
创建了Payment的实例p
p.amountTendered被赋值为amount
p被关联到当前的Sale
当前的Sale被关联到Store
升级会员 