敏捷軟件開發 之第三部分 薪水支付系統案例研究實現之分析

4月箴言

真的猛士，勇於直面慘淡的人生，勇於正視淋漓的鮮血。—— 魯迅

 

1、客戶需求記錄

一、有些僱員是鐘點工。會按照他們僱員記錄中每小時報酬字段的值對他們進行支付，他們天天會提交工做時間卡，其中記錄了日期以及工做小時數。若是他們天天工做超過8小時，那麼超過部分會按照正常報酬的1.5倍進行支付，每週五對他們進行支付。
二、有些會員會以月薪進行支付。每月的最後一個工做日對他們進行支付。他們的僱員記錄中有一個月薪字段。
三、同時，對於一些帶薪的僱員，會根據他們的銷售狀況。支付給他們必定數量的酬金，他們會提交銷售憑條，其中記錄了銷售的日期和數量。在他們的僱員記錄中有一個酬金報酬字段，每隔一週的週五對他們進行支付。
四、僱員能夠選擇支付方式，能夠選擇把支票郵寄到他們指定的郵政地址；也能夠把支票保存在出納人員那裏隨之支取；或者要求將薪水直接存入他們指定的銀行帳戶之中。
五、一些僱員會加入協會。在他們的僱員記錄中有一個每週應付款項字段。這些應付款項必需要從他們的薪水中扣除。協會有時也會針對單個協會成員徵收服務費用。協會每週會提交這些服務費用，服務費用必需要從相應僱員的下個月的薪水總額中扣除。
六、薪水支付程序每一個工做日運行一次，並在當天未相應的僱員支付。系統會被告知僱員的支付日期，這樣他會計算從僱員上次支付日期到規定的本次支付日期間應支付的數額。

注意、注意、注意：數據庫屬於實現細節，應儘量的推遲考慮數據庫！

抽象的定義：本質部分的放大，可有可無部分的去除。

 

2、基於用例分析 ---<這也是最關鍵的一步>

根據客戶需求能夠整理出的下次迭代的用戶素材：

一、增長僱員
二、刪除僱員
三、登記時間卡
四、登記銷售憑條
五、更改僱員明細（例如：每小時報酬，會費）
六、在當日運行薪水支付系統

咱們須要把這些用戶素材轉化爲具備詳細細節的用例。

備註：關於此時的用例--咱們不須要陷入過多的細節，只要有助於考慮出每一個素材的代碼實現便可。

<具體的用例實現會在以後完善更新，目前對於這個章節的理解還有些疑惑>

3、咱們學到了什麼

簡單的用例分析能夠提供豐富的信息以及系統設計的洞察力

找到潛在的抽象：薪水支付應用中的潛在抽象是「全部的僱員都被支付」，這個是咱們經過以前的用例分析獲得的（好多應用背後的抽象都是經過基礎的用例分析獲得的）

做爲一個一直作應用層的開發人員，涉及到這塊感受仍是比較吃力的，一點點努力嘍！

-----------------未完待續---------------

 

 

PS：設計模式任重道遠！