一、需求描述
该超市的系统组成主要由以下几个部分，其中各个部分有不同的参与者情况，每个部分主要针对一个或一系列功能设计：
（1）收银管理系统。
该部分的参与者主要是收银人员，同时该部分是与库存管理以及业务管理直接关联的。
收银的业务操作直接対库存管理以及业务管理进行影响。
其中的类比如收银单、条形码、商品细项等。
收银部分中的一些实体类是与其他部分中的实体类共通的。
每次收银操作，都会生成业务信息，影响营业额、订单数、收银人员工作记录等。
（2）线上订单系统。
该部分的参与者主要是后台管理人员以及会员顾客。
这个部分是一个自身功能较为完整，依赖性较小的部分，其中一些重要的类比如线上订单、购物车、商品细项。
可以明确的如线上订单和收银部分的收银单都可以是业务管理中业务记录这种抽象接口的具体实现实体类，也就是继承泛化，并拓展自己额外的属性。
线上订单系统的时序流程会比较复杂，类似课程教授的的购车用例。
该部分是会员顾客与订单系统的交互，同时也会涉及对业务管理的、库存管理的变动，这种变动是对其底层实体类的具体存储参数的修改。
通过订单系统种的功能函数实现。
（3）人员管理系统是另一个重要的系统组成。
该部分的参与者主要是后台管理人员和顾客会员。
这里要区分的是后台管理人员参与者以及后台管理人员类。
后者是系统中的一项组成，用于实现数据记录和某些功能，而前者是角色。
人员管理中最重要的三个实体类分别是后台人员、收银人员以及顾客会员。
这里暂时不考虑超市的其他员工，因为收银人员在收银系统中扮演重要地位，其收银记录，对业务管理的底层数据都有影响。
人员管理主要分为两种，一种是后台人员的编辑、添加、删除。
这种管理适用于三个主要实体类。
而顾客会员类存在注册函数，也就是说该部分的参与者是顾客会员自身，顾客会员类信息是需要自身编辑的。
该系统主要是对系统中的角色类进行管理，对角色类进行实现增、删、查、改。
同时也会附加权限的管理。
（4）库存管理系统主要是后台管理人员参与，细化的功能为商品入库、商品出库，库存紧缺提醒等，库存管理的部分依赖于商品管理部分，也就是说该部分主要是对商品细项类中的数量特性进行操作。
库存操作将影响将直接影响到线上订单系统的界面类的商品展示情况，也会影响到超市的铺货情况，这里铺货的流程被省略，将货架铺货商品量与库存量合并，即线下顾客无法在收银系统中登记库存为0的商品，以此简化流程。
库存管理中，比较重要的实体类应有商品库存、入库记录、出库记录等。
（5）商品管理系统主要是后台人员参与，该部分的重要实体类是商品细项类，这个类有这众多的特性，用来记录商品的各项属性。
这个部分的主要功能即记录商品信息，不论库存管理、收银系统、线上订单系统皆与这个部分有直接联系，他们对商品的识别都需要查询商品管理部分的存储再数据库的商品细项类。
而部
分的控制类无疑可以实现后台管理人员对商品信息的增、删、查、改。
库存管理、收银系统、线上订单系统都依赖于该系统组成。
（6）业务管理系统主要负责的是交易单的综合记录功能，其直接参与者是后台管理人员，但是收银人员以及会员顾客也会通过在收银系统和线上订单系统的操作生成相应的业务记录交给业务管理部分。
无论是超市收银或者是线上订单，一笔交易在其系统中是收银记录和订单记录，但是都会汇总到业务管理部分中，提取出关键的业务记录信息，以业务记录实体类的父类模式存入数据库。
这种处理方式可以使得超市的运营统计有一个统一的标准，方便超市的营业情况、销售商品情况的统计，这样对于超市的市场走向分析、大众消费喜好都有帮助。
当然，具有权限的后台管理员仍然可以对业务记录进行增、删、查、改。
以上的部分是组成系统的主要组成。
参与者主要是后台管理人员、收银员以及会员顾客。
各个部分中实体类之间都存在联系，一个部分可以划分会一个完整的用例，别的部分的控制类中的一些操作也会相应影响到自己的实体类数据。
六、面向对象设计
(1)包设计，包设计可以按照mvc架构设计，也可以按功能模块设计，这里按功能模块设计：
(2)部署图设计
对于内部管理人员访问系统，使用C/S架构，前台有应用客户端，后台有应有服务器，使用JBoss netty处理socket连接，还有数据库服务器，这里使用Oracle 数据库：
对于线上购物系统，针对用户，为便携用户使用，故采用B/S架构，由于会员顾客可以访问，潜在的并发量会很大，所以将请求处理进程和业务逻辑进程不部署在同一台服务器。
用户通过HTTP请求访问Web服务器。
应用服务器使用JBoss，数据库服务器采用Oracle数据库：
(3)子系统设计
由于人员管理中，用标识符即可区分不同人员：管理员、收银员以及会员顾客在数据库中的存储。
人员管理可以作为一个子系统，其对人员的操作完备，后台管理员对不论自身、收银员还是会员顾客操作时，都可以调用人员管理这个基本接口，由此接口实现的功能类则分别针对不同人员类别操作，这样大大增加了系统复用性：
无论线上订单还是收银单都是业务记录的一种，业务管理系统中对业务的操作，可以作为接口提供给线上订单的操作以及收银单操作，业务管理中的业务操作也就可以独立成一个子系统：
在超市系统中，对商品细项的操作会再很多情况下发生，比如入库、出库就会对商品库存信息变更，线上购买、收银结账也会对修改其数据，又比如后台管理员修改商品的某些属性，并且这些操作前肯定需要先查询该项商品的信息，才可做出操作。
这些可以通过实现商品信息查询与编辑的子系统，调用该子系统接口进行操作，这样大大减少了程序冗余、代码重复：
(4)类设计
在面向对象分析中，已经创建了实体类、边界类和控制类3种分析类。
类的优化即是创建设计类，将分析类映射为设计类。
优化视图类，由于线上订单系统采用B/S架构，前端使用html，视图类的处理的是选择从控制类得到的指令获得，从而构建返回的视图，这里的视图类更重要的是生成相应的html代码。
而后台系统以及收银系统是C/S架构，这里的视图类主要是针对控件的设计以及布局等。
该报告主要以优化后者视图类为主。
人员管理视图可以如下优化，使用一些接口：
商品库存管理视图类可以如下优化：
收银系统视图类可以如下优化：
优化控制类有几个要素：复杂性、可能性的变化、视图分配和业务管理。
在收银系统，收银记录会影响业务管理中的记录，需要使用通知类调用业务管理子系统接口，而这中跨系统的操作，如果放入控制类中，那么参数存储，内部子操作就无法实现，操作会变得复杂。
故将该通知业务系统作为一个类分出控制类，会优化系统，同样线上订单控制类也可以如此：
优化实体类。
因为实体对象通常是被动和持久的，所以对实体类优化需要注意持久化存储的实现，如Java EE 中经常使用Bean 类。
该项目将一些实体类的操作函数转为一些通用的数据处理类，如DataHelper 类、SqlHelper 类。
这里列出人员管理中的会员顾客实体类、业务记录的业务记录实体类、商品管理里的商品细项实体类以及库存管理的库存记录类的优化，DataHelper 将操作函数中的得到变量设为特性，在生成函数处理该变量，以替代实体类的函数，这样可以提高复用性。
如商品细项的生产厂家属性，可以单独作为一个GoodsmfDatahelper 类，那么在库存管理、业务管理中，都可以调用该类进行生产厂家的属性操作：。