4月箴言
真的猛士，敢于直面惨淡的人生，敢于正视淋漓的鲜血。
一、客户需求记录
1、有些雇员是钟点工。会按照他们雇员记录中每小时报酬字段的值对他们进行支付，他们每天会提交工作时间卡，其中记录了日期以及工作小时数。如果他们每天工作超过8小时，那么超过部分会按照正常报酬的1.5倍进行支付，每周五对他们进行支付。
2、有些会员会以月薪进行支付。每个月的最后一个工作日对他们进行支付。他们的雇员记录中有一个月薪字段。
3、同时，对于一些带薪的雇员，会根据他们的销售情况。支付给他们一定数量的酬金，他们会提交销售凭条，其中记录了销售的日期和数量。在他们的雇员记录中有一个酬金报酬字段，每隔一周的周五对他们进行支付。
4、雇员可以选择支付方式，可以选择把支票邮寄到他们指定的邮政地址；也可以把支票保存在出纳人员那里随之支取；或者要求将薪水直接存入他们指定的银行账户之中。
5、一些雇员会加入协会。在他们的雇员记录中有一个每周应付款项字段。这些应付款项必须要从他们的薪水中扣除。协会有时也会针对单个协会成员征收服务费用。协会每周会提交这些服务费用，服务费用必须要从相应雇员的下个月的薪水总额中扣除。
6、薪水支付程序每个工作日运行一次，并在当天未相应的雇员支付。系统会被告知雇员的支付日期，这样他会计算从雇员上次支付日期到规定的本次支付日期间应支付的数额。
注意、注意、注意：数据库属于实现细节，应尽可能的推迟考虑数据库！
抽象的定义：本质部分的放大，无关紧要部分的去除。
二、基于用例分析 ---<这也是最关键的一步>
根据客户需求可以整理出的下次迭代的用户素材：
1、增加雇员
2、删除雇员
3、登记时间卡
4、登记销售凭条
5、更改雇员明细（例如：每小时报酬，会费）
6、在当日运行薪水支付系统
我们需要把这些用户素材转化为具有详细细节的用例。
备注：关于此时的用例--我们不需要陷入过多的细节，只要有助于考虑出每个素材的代码实现即可。
<具体的用例实现会在之后完善更新，目前对于这个章节的理解还有些疑惑>
三、我们学到了什么
简单的用例分析可以提供丰富的信息以及系统设计的洞察力
找到潜在的抽象：薪水支付应用中的潜在抽象是“所有的雇员都被支付”，这个是我们通过之前的用例分析得到的（好多应用背后的抽象都是通过基础的用例分析得到的）
作为一个一直做应用层的开发人员，涉及到这块感觉还是比较吃力的，一点点努力喽！
-----------------未完待续---------------
PS：设计模式任重道远！