业务建模(Business Modeling)对领域内企业管理和业务对象进行建模。包括业务流程建模和领域建模。业务流程建模描述系统内各单位、人员之间业务关系、作业顺序和管理信息流向。领域建模是从现实的问题域中找到最有代表性的概念对象,抽象成分析类。
A. 业务流程建模。
u 使用UML活动图分析目标系统所支持的业务流程。
UC1销售开单用例
UC2收银用例
u 使用文字对流程中每个活动的涉众、业务规则、使用到的单据进行必要的说明。
涉众:顾客、收银员、酒店经理
业务规则:
ID |
规则 |
可变性 |
来源 |
规则1 |
顾客折扣规则。如: 酒店经理:10%折扣额 |
高,没每间酒店都有不同规则 |
酒店政策 |
使用到的单据:
收款票据,内容包括:酒店名称,开单时间,台号,经理工号,消费详细,商品单价,商品数量,应收金额,实收金额,找零金额等
B. 领域建模。
u 使用UML类图构建领域模型。
需求规格说明书(Software Requirements Specification)描述了系统的功能需求。构建系统用例模型描述功能需求。
A. 系统用例图。绘制整个系统的UML用例图。
B. 用例详述文本。
对所有业务活动用例采用详述风格(包括前置条件、后置条件、主事件流,扩展、业务规则等)进行描述。
范围:POS应用
主要参与者:经理,收银员
前置条件:收银员和经理必须经过确认和认证
成功保证(后置条件):存储消费信息。准确计算税金,准确计算消费总额,生成票据。
主成功场景:
1.经理给用户开台
2.顾客物色好菜式后,经理给顾客点菜
3.经理把顾客所点的菜式输入POS系统
4.顾客用餐
5.顾客用餐完毕要求结账
6.收银员进行结账,系统显示总额和所计算的税金,并打印出小票
7.经理凭票据向顾客收款
8.顾客付款
扩展:
*a.系统在任意时刻失败:
1. 收银员或经理重启系统,登录,请求恢复上次状态。
2. 系统重建上次状态
1a.顾客因人数或者喜好需要换桌
经理进入系统,修改此次消费订单对应的台号
4a.顾客用餐过程需要加菜
经理给顾客进行加单,并且输入系统对应的消费订单
4b.顾客用餐过程因等待太久或者因菜式有问题需要进行退单
经理确认情况给顾客进行退单,并且更新系统对应的消费订单
7a.顾客核对自己的消费详细记录,发现有有误及时提出
1.经理核对具体情况,确认无误后进入系统更新订单
2.继续第6步
补充性规格说明补货并确定其他类型的需求,如可靠性(如10000人并发访问)、可用性(如1米外轻松看到文本)、接口(如支持钱箱、支持网银支付接口)等。也可以包括其他跨越多个用例的功能性需求如报表、安全性、日志和错误处理、数据备份、数据导入导出等。
简要描述本项目最终系统数据查询与报表,系统权限管理的功能需求。也可以描述项目组计划实现的其他需求。
功能性
1、日志和错误处理
在持久性存储中记录所有错误。
2、可插拔规则
在几个用例的不同场景点执行任意一组规则,以支持对系统功能的定制。
3、安全性
任何使用都需要经过用户认证。
可用性
1、避免使用一般色盲人群难以辨认的颜色。
2、快捷、准确的结账处理及其重要,因为顾客希望快速结束结账过程,否则会给他们的购买体验带来负面影响。
可靠性
1. 性能
需要体现出系统的稳定性以及反应速度。
2、数据备份
系统支持定时或实时的对数据进行备份,避免数据的破坏或者丢失,如处理消费交易过程中,系统出现闪退或者奔溃情况下导致的数据丢失或者需要重新录入。
可支持性
1、可适应性
不同客户在处理销售时有其特有的业务规则和处理需求。因此,在场景中的几个预定之处(如开始新的销售交易时,增加新的商品时),需要能够启用可插拔的业务规则。
2、可配置性
系统具备一定的可配置能力以适应该店对其POS系统的不同的网络配置需求。
实现约束
使用的程序设计语言为java,其具备易于开发,能够提高远期的移植和可支持性能力。
购买构件
税金计算器,必须支持用于不同国家的可插拔计算器。
免费开源构件
建议使用免费的Java技术开源构件。
接口
重要硬件和接口
显示屏(显示POS系统)。
票据打印机
信用卡、借记卡读卡器