案例POS系统.docx
- 文档编号:7832857
- 上传时间:2023-01-26
- 格式:DOCX
- 页数:14
- 大小:135.50KB
案例POS系统.docx
《案例POS系统.docx》由会员分享,可在线阅读,更多相关《案例POS系统.docx(14页珍藏版)》请在冰豆网上搜索。
案例POS系统
案例研究:
POS系统
POS系统通常用在零售业,主要的功能是记录销售情况并处理交易款支付的工作。
完整的POS由硬件(如计算机、条形码扫描器等)和软件(应用系统)共同构成。
在软件应用系统方面,POS系统并不是独立的,它和其他相关软件之间会存在交互接口如库存控制系统(每笔零售交易必须连动相应的库存信息)等。
出于存在着这样的对外接口,在一个有效的POS应用系统中必须要考虑到在与其他系统交互时的容错处理,如在暂时无法与远端服务交互时(如库存控制系统)。
系统仍需要能够处理销售和现金付款以避免日常经营的中断;而在能够交互时,系统应能将未提交的交易信息再传输给远端其他系统。
同时,POS系统设计时还需要考虑今后的发展情况,如逐渐需要支持不同的客户终端设备和不同的访问方式。
如支持“网页浏览器为基础的终端设备,支持标准个人机上一使用JavaSwing的图形使用界面,支持无线PDA等。
另外,一个商业性POS系统还必须要考虑到不同用户会使用不同的商业规则,尽管POS系统的大流程应该是基本一致的,但每个用户都有可能想在系统的某些特定处理点上执行自己特有的一套商业规则,如VIP卡用户享有特殊折扣等,所以POS系统必须有足够的灵活性,以保证能针对不同用户的不同需求进行有效的客户化。
下面就利用所推荐的迭代式开发方法,介绍如何从需求、面向对象分析、面向对象设计到最终完成系统的实现过程。
由于代码实现与具体的编程技巧相关,所以在这里不对编程部分进行具体介绍.而更集中于介绍其余设计活动。
1.迭代规划
利用RUP中所介绍的阶段和迭代开发的策略来开展工作,分不同阶段和多次迭代来逐步完成POS系统的开发。
根据阶段性开发的特征,不同阶段完成不同的阶段性任务。
根据迭代式开发的特征,每次迭代过程将只完成系统的部分功能,从而保证每次迭代过程的工作内容相对精练和准确。
在初始、细化、构造和移交四个阶段中,与分析设计任务关系最大的阶段是初始和细化阶段,这里重点介绍这两个阶段的工作内容。
在第一次开发迭代过程中,主要完成系统的一些核心功能:
在随后的多次迭代中,逐步扩充系统的功能性。
在案例中,所有分析、设计目相关主题、UML表示法和模式等内容也随着迭代的发展而以迭代方式逐步扩充。
在第一次迭代时,主要提供分析与设计的核心内容以及表示法;在第二次迭代,将引入一些新概念,增加UML表示法和模式;再随后的迭代中也是如此。
这里详细介绍第一次迭代中的各个活动的开展方法和最终制品,后续的多次迭代请读者参考第一次选代的相关方法自己开展。
在对系统进行设计之前,需要先确定POS系统的主要侧重点。
在POS案例中,侧重于应用逻辑和问题领域对象层的设计活动,关注如何为对象分配责任以满足应用需求上;同时,也涉及技术服务层,主要是创建一个与教据库的接口。
2.初始阶段中的用例与制品
初始阶段的主要目的是建立一些初始的、共同的案例构想.进行案例的可行性研究,以决定是否值得做进一部投资。
在迭代式的升发方式中,对于初始阶段而言,不需要完成所涉及的所有工作,而只需要完成其中部分的工作即可。
例如对于系统用例的发现,在此阶段只需要列出大部分用例的执行者名称就可以了,对于用例的细节大概能完成10%就可以了。
2.1用例模型
就POS系统描述一个“用例模型”的创建过程。
对于初始阶段的所有工作而言,首先要做的是认真了解系统的实际需求并写出在某些情况下的系统需求。
由于系统的需求通常隐藏在很多日常行为中,所以将需求有效地抽取出来并不是什容易的事情。
但利用“用例”可以让需求保持在相对简单的状态下,并且所有相关人员都可以很容易地理解这个用例。
通常对于用例描述,有以下三种不同的方式.
●简要式:
只有一段精简的摘要,通常只写出主要情节。
●非正式的:
用非正式的、一段一段的文字记录用例。
在不同段落中描述各种情节。
●正式的:
最详细的格式。
详细写出所有步骤与变异之处,并且也写出其他支持性的内容,如前置条件及后置条件。
下面通过列出的POS系统中的“处理销售”用例的不同描述,来理解用例的不同描述方法。
(1)处理销售(简式)
顾客拿着要买的商品到结账柜台结账。
收银员利用POS系统记录顾客要买的每一件商品。
每记录一件商品时,系统都会算出相应的总价,并显示商品的明细。
顾客在输入付款信息后,系统会验证付款信息并记录。
系统更新库存信息。
顾客从POS系统中收到一份收据后,带着商品离开。
(2)处理销售(非正式)
主要成功场景:
顾客带着要买的商品到结账柜台。
收银员用POS记录顾客要买的每一件商品…(同上,略)
备选代场景:
如果信用卡售权被拒绝,告知顾客换用其他付款方式。
如果无法找到这项商品条码时,告知收银员采用手工输入的方式。
如果......
(3)处理销售(正式)
主要执行者:
●收银员
利益相关者:
●收银员:
希望有准确、快速的输入方式,不会发生付款错误的情况。
●销售员;希望销售佣金能随销售量的变化迅速更新。
●颇客:
希望买到商品,井获得快速的服务,同时希望昀购买后能保证退货。
●公司:
......
●付款授权服务:
......
前置条件:
确认收银员身份.并授权给此收银员使用本系统。
后置条件:
储存销售。
更新库存记录。
更新财务信息。
更新销售佣金信息。
生成收据。
记录付款授权认可。
主要成功场景(基本流程):
1.顾客带着要买的商品,到运行POS系统的结账柜台前。
2.收银员启动一笔新的销售交易。
3.收银员录入商品条码。
4.系统记录销售明细,并显示商品说明文字、价格和累计购买总金额(按一系列的业务规划计算)。
收银员重复步骤3、4,直到完成所有商品的条码录入为止。
5.收银员告诉顾客总金额,并要求顾客付款。
6.顾客付款,并由系统处理付款。
7.系统记录完成的销售,并且将销售信息送给财务系统(以计算佣金和公司财产)和库存系统(更新库存量)。
8.系统给出收据。
9.顾客带着商品和收据离开。
扩充场景(备选流程):
在任何时间点,当系统出现故障时,为了保证系统的复原能力,并修正相应的财务信息,要确认交易中所有容易受影响的状态与事件,从而保证不论是在场景的哪个步骤都能复原:
1.收银员重启系统,登入系统,并要求还原成原有状态。
2.系统重新还原成之前的状态。
具体细节是,系统检查到阻止复原的非正常状态:
i.系统告知阻止复原的错误,从错误中复原,并进入未改信息时的状态。
ii.收银员启动一笔新的销售交易。
3.
3a.无效商品条码。
i.系统告知错误,并且拒绝输入商品条码。
3b.同类多个商品。
i.收银员录入商品条码与数量。
3-(n)a.顾客要求收银员去掉某个原先想买的商品。
i.收银员录入要去掉商品的条码与数量。
ii.系统更新当前的总销售金额。
3-(n)b.顾客要求收银员取消这次销售。
i.收银员取消这次销售交易
3-(n)c.顾客要求收银员暂停本次销售。
i.系统将销售记录下来,而且之后可以在任何POS终端中取回这比销售交易的记录。
4.
4a.不希望采用系统所产生的某项商品价格(如顾客说某件商品的价格应该是更低的价格,顾客有VIP卡或有特殊优惠活动)。
i.收银员录入超额部分的金额。
ii.系统更新价格。
5.
5a.顾客要求用现金支付,但是现金不够。
i.顾客用其他付款方式。
ii.顾客告诉收银员取消这笔销售交易。
收银员取消系统中的这笔销售交易。
6.
6a.用现金付款。
i.收银员输入顾客付的金额。
ii.系统显示结余金额,并打开现金抽屉。
iii.收银员放进顾客付的现金,然后拿结余金额给顾客。
iv.系统记录现金付款金额。
6b.用信用卡付款。
i.顾客录入他们的信用卡号。
ii.系统显外部付款授权服务系统发出付款授权请求,要求付款认可。
a.系统检查到与外部系统间的通信发生错误。
i.系统告知收银员通信错误
ii.收银员要求顾客用其他付款方式
iii.系统收到付款认可,并告知收银员付款已被认可。
b.系统收到拒付信息。
i.系统告知收银员付款被拒绝
ii.收银员要求顾客用其他付款方式
iv.系统记录信用卡付款金额,其中包括付款认可信息。
v.系统呈现信用卡付款签名并提供输入机制。
vi.收银员要求顾客进行信用卡付款签名。
vii.顾客输入签名。
6c.用支票付款。
……
6d.用折扣券付款。
……
特殊需求:
●大型、平面显示器,触摸式使用界面,在30厘米外能看清上面的字。
●能在30秒内相应90%的信用授权。
●由于某种原因造成与外部系统(如库存系统)连接出现故障时,希望系统的复原能力比较强。
●显示的文字应是国际化语言文字。
●能在步骤3-7之间客户华增加企业的业务规则。
技术性变更清单:
3a.(如果有条码的话)用键盘或条码扫描器输入商品识别码。
3b.商品识别码可以是UPC、EAN、JAN、SKU中的任何一种。
7a.用读卡器或键盘输入信用卡帐户信息。
7b.目前使用纸上付款签名。
但在两年内,预计大部分顾客会希望使用数字化签名的方式。
系统使用频率:
连续不断。
开放议题:
●谈到远端服务复原。
●不同企业会有哪些不同的客户化需求。
●顾客可以直接操作读卡机?
还是由收银员操作。
……
在实际应用中,具体使用哪一种描述方法进行用例描述并不重要,只要能够写出主要成功场景和扩充场景细节就可以了。
用例定义的基本流程:
1)选择系统边界。
POS系统是索要设计的系统,系统以外的所有东西都在系统边界外面,收银员、付款授权服务等都在系统边界外面。
2)找出主要执行者及其目标。
例如在POS系统中,收银员是系统的主要执行者,他需要能够通过POS系统进行处理销售的活动,从而我们得到一个执行者和目标的用例。
类似的,可以获得下表所示的一些对应关系:
3)定义用例。
经过分析后,可以获得在当前阶段的主要用例有:
处理销售、处理退货、分析销售活动、管理安全性、取出现金、存入现金和管理系统表格等。
参照前面所列出的“处理销售”用例的描述方法,大家可以模拟其他用例的说明。
根据各用例重要程度的不同.可以使用不同的描述方法进行描述(简式、非正式、正式)。
用例图:
在当前阶段,对于用例的关注重点应该在用例本身上,土要工作应该是在写出用例的说明文字上,而不是在用例图和找出用冽间的关系上。
通常,只需要画出一个简单的用例图,把它和执行者和目标清单关联起来即可,而不要过多地浪费时间去划太多的图。
2.2其他需求内容
2.2.1辅助需求规格书
修订历史
简介
本文档中描述的是在POS系统需求中除用例以外的所有其他需求。
功能性
(这功能有可能是存在于或涉及多个用例中的常见功能)
系统记录错误的处理方法:
要求记录所有系统错误到可永久保存的储存介质中。
系统可嵌入商业规则:
从而在某个特定事件发生时,可以使用某企业自己的商业规则。
安全性
要求系统所有的使用行为必须是得到授权的。
可用性
考虑到人的因素,由于顾客希望能看到POS系统显示的内容,所以需要使用大型显示器,以便于顾客在30厘米以外也能看到文字。
同时,显示时应该避免使用色盲无法辨别的颜色。
另外,为了能及时提醒收银员,不仅要显示文字还需要能够提供声音发出的提示或警告。
可靠性
系统中断时的可恢复性,如当系统无法和外部系统通信时,利用本地临时解决的可能性。
效率
希望90%以上的交易能在一分钟内完成。
可调整性
系统要能根据不同情况,设定相应的商业规则,从而在不同情况下提供不同的服务。
可配置性
用户够根据自身情况选择系统不同的配置方式,如瘦客户机或胖客户机,两层式系统或多层式系统等。
开发限制条件
只能使用Java技术。
界面
硬件界面:
触摸式显示器、条码扫描器、收据打印机、信用卡/借记卡读卡器。
软件界面:
针对大部分外界商业系统(会计系统、库存系统等),需要能嵌入各种不同的系统或界面。
商业规则
其他相关问题
商业识别码与条码扫描器。
POS系统应能支持各种商品条形码,主要的条形码系统包括有UPCs、EANs(含JANs)和SKUs等。
2.2.2POS系统构想(部分)
修订历史
简介
具有容错能力的POS系统,能够支持各种不同客户的商业规则、多种终端设备和使用者界面机制.并能与多种其他厂商的相关系统整合使用。
竞争地位
从企业机会上看,市场上现有的POS系统产品存在着无法根据客户需求进行企业级调整,应用企业所需的商业规则或网络设计方式;多无法随终端设备和企业发展而扩充;无法在与外部系统通信失效时,自动重连或离线运行;难以和其他厂商产品系统整合等问题。
而本系统所设计具有高弹性的POS系统将很好地满足市场的需求。
……(对系统的突出特性,系统定位、系统与竞争对手间差异进行分析和描述。
)
利益相关者描述
……(描述系统的利益相关者目前面临的主要问题,他们的目标在于通过系统获得什么利益等。
)
产品概述
POS系统将主要安装在零售商的商店里面,但也可以使用移动式终端设备,利用商店的网络系统.在商店附近地点使用。
系统特性摘要
●支持(信用卡、借记卡,支票等)付款授权。
●与外部系统的通信失效时自动离线销售处理方式。
●可定制客户自己的商业规则。
......
其他需求与限制
......(描述系统限制、设计限制、可用性。
可靠性、性能、可支持性、使用说明、包装方式等)
2.2.3词汇表
修订历史
定义
2.2.4初始阶段的工作重点
在初始阶段,主要的工作是要收集到足够的信息来建立共同的系统构想,以决定是否需要再开发下去,及系统是否值得继续进行细化阶段的调查工作。
不要在这个阶段中过多地用UML去画太多的图,而只需画出很简单的UML用例图,将工作的重点放在了解系统范围内10%的重点需求上,并用文字描述它们。
事实上,在初始阶段,只是开始写需求而已。
在初始阶段,我们关心的是系统中值得注意的质量特性,如当外部服务失效时,POS系统需要能够复原等。
主要的任务是发现系统开发中的主要风险与挑战。
在初始阶段的系统构想中,可用一张表格来归纳系统的总体概念,从而帮助利益相关者决定是否值得继续下去,需从哪里开始调查工作。
而真正的调查工作是在细化阶段展开的。
初始阶段中的需求讨论会是初始阶段所有工作制品的主要信息来源。
3.细化阶段中的用例与制品
对于POS系统及其他大多数系统而言,在细化阶段建立核心构架与验证工作时,要注意下而这些工作原则:
●利用“宽且浅”的设计实现方式。
即找出独立的处理程序、层次、组包与子系统,以及它们间的高层责任与接口。
通过部分实现这些内容,达到使它们可以相互关联,分清接口即可。
模块内部可能大部分只是“空壳”程序。
●细化模块内的本地与远端接口(包括最详细的参数和返回值),把接口与外部系统关联的存取方式封装起来。
对于接口,应及早尝试进行压力测试、“打破”并细化一些接口,这些接口有助于稍后多个开发团队的并行开发工作,因此接口的稳定非常重要。
●整合现有的部件。
●实现简化的端到端处理场景,从而强化跨多主要部件的设计、实现和测试。
例如在处理销售用侧的主要成功情景中,会用到信用卡付款的扩充情景。
尽早地对核心构架进行测试是很重要的,它可以使我们获得反馈,从而可以调整系统,验证核心构架的稳定性。
例如在POS系统中.早期的测试内容至少应该包括:
●对使用者界面进行可用性测试。
●测试远端服务(如信用卡授权)失效时的系统自动复原能力。
●测试远端服务(如会计系统)的高负载运行能力。
3.1细化阶段工作的重点
细化阶段可以分为多次迭代过程,每次迭代中可以有不同的侧重点。
例如,在POS系统中,可将细化阶段分为三个迭代过程来完成。
在迭代1中侧重于找出系统事件,完成用例交互图;在迭代2中侧重于将迭代1中的内容进行细化,进行固化的对象设计;在迭代3中考虑系统的强壮性等性能因素,如对意外的自动恢复能力,错误修复能力,信用卡授权等。
虽然每次迭代所侧重的内容有所不同,但在每次迭代过程的主要工作方法和过程是基本一致的。
因此.在我们的示例中,将主要介绍在迭代1过程的主要工作方法和内容,而其他迭代过程不再详细描述,大家可参考迭代1的完成方法,自行完成迭代2、3的内容。
细化阶段的迭代1中,工作重点在于找出系统事件,并产生用例的交互图。
在POS系统的细化阶段的迭代1中,主要完成以下工作:
●实现处理销售用例中的关键情景:
输入商品项目并收到现金付款。
●实现启动系统用例并支持所有反复的初始化动作需要。
●不处理较复杂的部分,只处理简要路径的情景,并只做这部分的设计与实现。
●暂不考虑与外系统的合作。
●暂不采用复杂的定价规则。
利用初始阶段的用例描述,可以为P0S系统的“处理销售”用例中的主要成功场景创建图12-2所示的时序图。
该图非常准确地描述了“处理销售”用例的成功场景内容。
由此可见,时序图是表现用例的一个非常好的工具。
系统中的大部分时序图是在细化阶段产生的,时序图可以使我们找出系统事件细节,从而分清哪些操作是设计系统时要处理的、写出系统操作合约、计算出可能有用的支持性估算值等。
需要注意的是,在细化阶段,并不需要产生所有用例、所有情景的时序图。
而是应该针对目前阶段,针对处于迭代过程中的用例的一些情景画出时序图。
3.2领域模型
3.2.1建立领域模型
迭代1中领域模型创建过程的主要任务是:
找出与目前迭代需求有关的概念性类;产生初始版的领域模型。
区分正确与错误的属性;必要时在领域模型中加入概念类;比较概念性观点与实际观点间的差异。
在使用UML来展示领域模型时,会画出一些没有操作的类图。
图中显示的主要内容是:
领域类或概念类;概念类间的关系;概念类的属性等。
在POS系统中,分析用例“处理销售”的主要成功场景。
主要成功场景(基本流程):
1.顾客带着要买的商品,到运行POS系统的结账柜台前。
2.收银员启动一笔新的销售交易。
3.收银员录入商品条码。
4.系统记录销售明细,并显示商品说明文字、价格和累计购买总金额(按一系列的业务规划计算)。
收银员重复步骤3、4,直到完成所有商品的条码录入为止。
5.收银员告诉顾客总金额,并要求顾客付款。
6.顾客付款,并由系统处理付款。
7.系统记录完成的销售,并且将销售信息送给财务系统(以计算佣金和公司财产)和库存系统(更新库存量)。
8.系统给出收据。
9.顾客带着商品和收据离开。
得出候选概念类清单:
Register、ProductSpecification、Item、SalesLineItem、Store、Cashier、Sale、Customer、Payment、Manager、ProductCatalog。
注意在清单中并没有包括Receipt,这是因为收据首先是一种信息报告,它复制了领域中其他地方可以找到的信息,即它可以利用领域中的其他信息源获得,因此,Receipt不必放在领域模型中;其次,由于收据在领域中的应用通常是持收据人拿它退还之前购买的商品,由于在当前迭代阶段并不考虑退货的问题,所以不把Receipt放在当前的领域模型中。
考虑在候选清单中的Store,是应该作为一个独立的概念类?
还是只作为Sale类的属性?
在领域模型创建时,一般来说,如果我们不能把某概念类X看成是真实世界中的数字或说明文字界中的数字或说明文字,那么,就可能是概念类而不是属性。
应用这一原则,Store应是一个概念类,而不是属性。
在分析时,要避免将概念性的东西当成属性的错误。
在不确定的情况下,应先把当成独立概念,一般在领域模型中较少出现属性。
考虑在候选清单中出现的Item和ProductSpecification。
由于Item是一个实体商品概念,虽然它有相应的说明文字、价格和商品项目条码,但这内容都和Item的库存记录联系在一起,一某种商品的库存全部卖完,此商品的相应信息在系统中就会无从查找。
故此,系统需要一个可以记录商品的规格和说明文字信息的概念类,即ProductSpecification。
这样,即使某个商品的库存全部卖完了,其相应的Item对象实体全部删除后,ProductSpecification还会存在。
由于这种说明或规格性对象和他们所描述的物体间有很强的关联性,在领域模型中,我们会说XSpecification是用来描述X的,表示方法如图所示。
经过对候选概念类的分析,最终POS系统在迭代阶段1中最初的领域模型如图所示:
3.2.2在领域模型中增加关联关系
3.2.3在领域模型中增加属性
3.3设计模型
3.3.1设计方法
3.3.2用例实现
3.3.3设计类
3.3.4实现模型
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 案例 POS 系统