授课视频1/2在线视频

大家好。下面一起来看一个案例分析

通过这个案例我们来了解一下

用UML进行面向对象的分析与设计应该如何做

我们主要讨论一个Pos系统的对象模型设计

这个模型来自于一本书

这本书的名字叫做对象模型

副标题是策略模式和应用

这本书写的比较早，但是非常棒

它有中文和英文两种版本

大家可以根据自己的需要进行选择

这本书第一章的示例

就是pos系统的分析与设计

如果你能看到这本书

然后再来听我们的讨论，可能收获更大

下面我们一起来看

Pos系统对象模型是如何

从无到有进行分析和设计的

首先看这种类型

我们把它分成几个部分

第一个部分要了解进行软件设计的目标是什
么

这个目标实际上是通用的

不仅对这个系统有用

对其他系统也很有用

第二个部分，要根据需求来确定系统特性

后面的分析与设计都是基于这个特性进行的

第三块要为模型选择一个架构

大家回顾一下我们前面提到的架构模式

有很多种架构模式

这里采用的比较多的就是MVC三层架构

现在这个对象模型也要按照

MVC三层架构来进行分析与设计

然后我们要讨论关键的问题域

也就是业务逻辑域

在三层结构当中，有用户界面层

用户界面层就是

Human Interface，就是HI组件，有的地方称之为
UI

这是用户界面层和业务逻辑层

这是我们的业务逻辑层

然后就是数据访问层

但是这里，我们主要讨论业务逻辑层

也就是问题域和用户界面

数据访问这一块

目前主要采用这种ORM类的工具

我们这个案例当中并不做过多说明

因为这个系统与其他系统可能有交互

这里简单提一下，大家可以借鉴

至于说暂不考虑，我们在设计的过程当中

由于成本、规模、人员等等因素

不可能面面俱到

把所有的问题都考虑到、都设计进去、都来实现

所以要列出来

哪些问题我们在第一版当中不予考虑

这是整体的这样一个结构

下面就具体来看

首先我们来看具体的系统目标

前面说过，系统目标可以是一个相似的东西

具体到现在这个Pos系统

系统目标是什么呢？

超市的老板找你，让你给他开发一个Pos系统

他想解决什么问题？

一般来说，提高某某的效率

为什么说系统目标具有通用性呢？

对于MIS系统来说

开发这个信息系统都是为了提高效率

只不过这里工作人员就是收银员

所以我们说是提高收银员的工作效率

记录什么过程？不同的系统有不同的过程

这里记录的是销售过程，改善经营效率

这是我们讲的三个目标

提高效率，记录过程，改善经营的效率

我们来看系统的需求

系统的需求我们可以把它对应到需求里面来

这个需求为什么没有向大家详细展示呢？

就是大家日常生活当中去超市买东西

这个行为已经很常见

在我们头脑当中对这个需求其实已经很明确了

首先我们要把重要的信息写入日志

在目标当中提到了

记录销售过程，

记录实际上就是把信息写入日志

具体哪些信息写入日志呢？

回归一下业务流程

upc就是我们的条码

当收银员拿到你的商品

他的条码枪扫描商品上的条码之后

我们就能从数据库当中得到这个商品的价格

这个价格可能还包括税收的价格，在国外

每件不同的商品有不同的税收比率

谁在卖东西，谁在收银

要给它记下来

我们的商品肯定要记下来

卖了什么东西，什么时候卖的，卖了多少钱

这些是在整个业务流程过程当中

非常重要的信息，要把它写入日志

这是整个系统的需求

过程我们要进行管理

在上面这些重要信息当中

核心的几个交易过程比如说根据条码返回价格

对多件商品进行小计和合计，然后支付

这是三个主要的过程

但这个过程比较简单了

分析经营结果就是要进行大量的

报表，无论是日报、周报还是各种各样的图表展示

这里我们只列出了一部分内容

我们要根据收银员每天每个月卖的

商品的数量和金额来确定这个收银员

是不是努力工作，有没有偷懒

然后确定他的奖金

如果是连锁店的话

不同店面它的经营结果

它的利润水平等等都需要拿出来供决策使用

这个系统是与其他系统相关的

比如我们进行刷卡的时候

刷卡要联到外部的银行系统

如果我们有自己的库存系统

那我们还要联到库存

从库存里面获取相关的商品信息

如果我们有人力资源系统

我们需要从人力资源系统中获取收银员的个人信
息

这是我们的系统需求

下面我们选择多层结构

刚才也提到了，我们要选择三层结构

这三层结构的核心问题是业务逻辑

左边与人交互，通过窗口，通过报表与人交互

窗口是双向的，用户可以输入

系统给予用户反馈

报表是单向的，只是系统产生出来的给用户看

问题域也就是业务逻辑域

存取数据需要通过一个数据管理层来操纵数据库

与其他系统的交互要通过接口

确定了多层架构之后

我们要进行问题域的分析

这个是重点内容

问题域的分析主要就是对象

对象我们这么来分

首先选择pd，pd就是问题域

或者叫业务域，都可以

如何选择对象，这里给大家一些策略

也就是说对象是一些名词

谁在什么地方干了什么事

然后分别来识别

谁，在这系统中

有哪些人使用我们的系统

首先收银员肯定是使用的

我们列出一些可能的候选人，收银员使用我们的
系统

有没有一些经理，收银主管他们可能也使用这个
系统

他们的权限可能比收银员更高

那如何设计这个地方的类

收银员是一个类，收银主管是一个类

这里面大家自然而然地会考虑到收银员派生出收
银主管

这是泛化关系

可以提前这样考虑

还可以考虑，如果不采用泛化关系

前面也提到过了，要尽量少用这种继承和派生

能不能在收银员这类当中设一个收银员级别

收银员级别比较低，用一个数字来表示

收银主管的值比他高

通过这个级别就可以区分收银员和收银主管

更高级别的，更丰富的层次

从这种思路来讲，收银主管可以把它拿掉

这个候选的类我们不要它了

就可以把它删掉

继续往下看，顾客可能不可能接受？

如果顾客自助使用系统

顾客肯定是一个参与者

但一般情况下，顾客拿到商品

把商品交给收银员

由收银员执行这种扫码的动作

所以我们认为顾客也不是参与者

下面讨论的问题，收银员是一个角色

或者是一个岗位

执行者，什么意思？

就是谁来承担收银员

这里我们来考虑，这个执行者可能是个人

这里是个人

大家在设计其他系统的时候可能是一些机构

这里可能认为它是个人

现在我们就发现收银员类和人person这个类

经过这样的候选，筛选下来了

现在选择了两个

收银员和个人之间什么关系

回头我们再讨论

人出来了，下面选择地点

地点，我们要考察这件事发生的场景

在商店里，所以会有商店这个类

商店类里还要考虑，这个系统是给连锁店使用

还是给单一的店面使用

如果是连锁店，那么连锁店这个类

和商店类之间是什么关系，我们可以考虑

再考虑在商店里面

商品可能是分区分货架摆放的

货架算不算是一个（地点）？

比如说在一些大型超市当中

有生鲜区和百货区

不同的区

区里面还有不同的货架

这就是一个地点，是一个容器

设计的时候要考虑哪些地点可以作为一个类

放入系统当中

这里货架暂时不予考虑，可以把它拿掉

这样的话，商店是一个地点类

现在为止，已经有三个类了

两个参与者一个地点