基于android的個人記賬系統分析與設計本科畢業設計論文-資料下載頁

【導讀】寫過的研究成果，沒有偽造數據的行為。本畢業設計（論文）作者完全了解學校有關保留、使用論文的規定。并向有關管理部門或機構送交論文的復印件和電子版，允許論文被查閱和借閱。影印、縮印或掃描等復制手段保存和匯編本論文。

　　

【正文】 都是一個 Activity。 業務邏輯層：專門完成業務邏輯的處理。常用來對 表 現 層 傳入 的數據進行 業務邏輯 處理。為了完成某個業務功能，它可能會跟多個數據訪問對象 DAO打交道。 使用 POJO類來實現。 通常由業務服務 Service類和業務實體類 Entity組成。 數據持久層：該層次專著于數據持久化邏輯的實現，將 內存 數據模型（如實例化對象）轉換為持久化的存儲模型數據（數據庫 記錄），也可將持久的存儲模型數據轉換為內存數據模型。 系統架構的層次圖如下所示： 圖 3– 1 系統架構層次圖 一個具有良好用戶體驗的系統，需要優秀的邊界類提供給參與者，使參與者能夠與系統進行良好的交互 ，并且獲取參與者錄入的數據 ，反應 觸發的事件 并將結果反饋第 3章 系統設計 30 給參與者 。 在 Android應用中，邊界類主要以 Activity界面類來表示。 在 系 統的 表示層 中 添加以下邊界類： 系統 主頁 邊界類、記賬 界面 邊界類、 明細查詢界面邊界類、統計報表界面邊界類、 數據管理界面邊界類、基礎設置界面邊界類等。 系統主界面顯示 本日支出和本月支出，以及進行支出、收入、轉賬和借貸的記賬按鈕，底部工具欄顯示進入其他界面的按鈕。 圖 3– 2 系統首頁界面邊界類 記賬界面由 4個 Tab選項卡組成，用戶可分別通過選項卡來選擇進行支出、收入、轉賬和 借貸四種賬目的記錄，每個選項卡具有符合各賬目類型的輸入框和下拉菜單，并驗證用戶錄入數據的合法性，最后將數據傳遞至業務層進行業務邏輯的處理。 圖 3– 3 記賬界面邊界類 在第二章的分析模型中，對系統中的概念類進行了分析，在設計階段，需要 在概念類的基礎上設計出實體類。 實體類是系統的重要組成部分，系統的大部分功能都是通過實體類來傳遞信息與數據的， 所以實體類 往往 需要 進行持久化。 根據系統功能需求，分析得出“用戶”、“賬目”、“收入”、“支出”、“轉賬”、“借貸”、“賬戶”等類是需要進行持久化的 實體類 。 對各個 實體類，進行屬性和方法的添加， 進行實體類圖的繪制， 由于每個實體類都具有若干的 private私有屬性，因此也具有每個私有屬性對應的 getter與 setter方法 以 供外部類調用，為了使類圖的簡潔明了的體現重要的核心屬性和方法，因此 類圖中并未將屬性的 getter、setter的方法 畫出 。 得到的實體類圖如下所示： 用戶記賬界面 b o u n d a r y 用戶系統首頁 b o u n d a r y 第 3章 系統設計 31 圖 3– 4 實體類圖 (1) 系統輸入設計： 輸入內容： 賬目金額、 記賬日期、關聯賬戶、 賬目備注、 賬目搜索條件、報表統計條件 、 收入支出類別信息 、賬戶信息、借貸賬戶信息 等。 輸入方式： 通過觸摸屏的手勢操作 文本框 的輸入和 下拉菜單的選擇 輸入設備：觸摸屏、軟鍵盤、 手指 (2) 系統輸出設計： 輸出內容：賬目信息、賬戶信息、報表統計結果 、賬目明細 、收入支出類別信息、接待人賬戶信息等。 輸出方式： 滾動列表、柱狀圖、折線圖 輸出設備：顯示屏 (3) 人機界面設計 系統首頁界面設計： 首頁界面的頂部有 一標題欄，正中位置顯示本系統的名稱“ iFinance”，其最右端有一循環箭頭圖標，點擊此圖標可將手機上的數據同步至服務器端的 Web版 的 個人記賬系統； 標題欄下方，是簡要的收入、支出統計，分別為本日、本周、本月三個時期 的收入和支出金額統計，讓用戶在首頁就能簡要了解自己的近期收入、支出的金額 ； 再下方是四個功能按鈕，分別為“新增支出”、“新增收入”、“新增轉賬”、“新增借貸”，用戶只要點擊這些按鈕，就能進入相應的記賬界面 ； 最底部是快速工具欄 ，包括“首頁”、“明細”、“報表”、“數據”、“設置”等五個菜單項 ，點擊相應 的菜單項即可進入相應界面。 系統首頁界面設計如 圖 3– 2所示： 第 3章 系統設計 32 設 置首 頁 數 據報 表明 細新 增 支 出新 增 收 入新 增 轉 賬 新 增 借 貸i F i n a n c e今 天本 周本 月+ ￥ 3 0 0+ ￥ 3 0 0+ ￥ 3 0 0 ￥ 1 0 0 ￥ 1 0 0 ￥ 1 0 02 0 1 2 年 5 月 2 4 日5 月 2 1 日 5 月 2 7 日5 月 0 1 日 5 月 3 1 日 圖 3– 5 系統首頁人機界面設計 新增賬目 界面設計： 界面頂部為標題欄“新增賬目”，標題欄下方是由 4個 Tab選項卡組件組成的組合頁面， 分別為“支出”、“收入”、“轉賬”和“借貸”記錄界面， 用戶可根據選項卡進行所需記賬賬目類型的選擇進入相應的記賬界面 。每個 選項卡所包含的用戶數據錄入域各不相同，例如“支出”界面，包含“金額”、“支出類別”、“時間”、“賬戶”和“備注”等五個輸入域（文本域和選擇菜單）。 選項卡組件下方，是“保存”和“返回”按鈕，分別完成賬目保存和撤銷功能，二者在完成時間響應之后，都將返回至系統首頁界面。 新增賬目界面的設計如 圖 3– 3所示： 第 3章 系統設計 33 設 置首 頁 數 據報 表明 細保 存轉 賬收 入 借 貸支 出1 0 0 . 0 0餐 飲 午 餐2 0 1 2 5 2 4 1 2 : 0 5小 雞 燉 蘑 菇現 金新 增 賬 目金 額類 別時 間備 注賬 戶 圖 3– 6 新 增賬目人機界面設計 類 圖 通過 概念類 的分析，以及邊界類、實體類的設計， 對系統中的業務邏輯層的Service服務類和數據訪問層的 DAO接口以及實現類進行設計。 首先，在數據訪問層中定義了一個 IBaseDao公共 基礎接口， 在此接口中定義了 基本的 CRUD方法 聲明 ，例如： add(T entity)、 update(T entity)、 delete(Serializable id)、 get(Serializable id)、 getAll()等。 然后，定義了一個 BaseDaoImpl類實現IBaseDao接口， 并實現所有聲明的方法。 其類圖如 圖 3– 7所示： 圖 3– 7 數據訪問層基礎接口和實現類 有了基礎接口和基礎實現類，以后每一個需要持久化的實體類需要增加相應的 DAO第 3章 系統設計 34 接口和 DAO實現類的時候，只需要將其 DAO接口繼承自 IBaseDao， DAO實現類實現 其 DAO接口并繼承自 BaseDaoImpl就可以了，在沒有復雜業務邏輯的情況下，甚至不用寫任何額外的屬性和方法 ，例如，“ 賬戶 ”相關的 DAO接口和實現類的類圖結構，如 圖 3– 8所示 （為省略空間此處不再顯示 IBaseDao和 BaseDaoImpl的屬性和方法） ： I B a s e D a o I n t e r f a c e B a s e D a o I m p lI A c c o u n t D a o I n t e r f a c e A c c o u n t s D a o I m p l 圖 3– 8 賬戶 DAO接口和實現類 不僅僅是“賬戶” Account實體類的 DAO接口以及實現類是這樣的 泛化 關系， 只要是需要進行持久化的持久類，都統一使用這樣的泛化關系，其余的 DAO接口以及實現類的類圖就不一一畫出。 對于業務邏輯層中的 Service類， 定義了一個 BaseService基礎服務類 ， 在此 基礎類 中 定義了一個 IBaseDao類型的屬性 dao，并 定義了基本的 CRUD方法 ，例如： add(T entity)、 update(T entity)、 delete(Serializable id)、 get(Serializable id)、getAll()等 方法，這些方法均是通過調用 IBaseDao中的 CRUD方法來是實現的。 需要注意 的 是 ， 屬 性 dao 的 具 體 實 現 類 由 BaseService 的 子 類 來 決 定 ， 通 過 調 用(dao : IBaseDao)方法。 基礎服務類 BaseService的類圖，如 圖 3– 9所示： 圖 3– 9 基礎業務服務類的類圖 每一個實體類都應該對應一個屬于自身類型的 Service服務類，且均繼承自BaseService基礎服務類。 因為在 BaseService類中都已經 實現了基本的 CRUD方法，因第 3章 系統設計 35 此一般無復雜業務的情況下，實體類對應的 Service類都不用在自定義方法，十分方便， 充分利用了 Java面向對象語言的代碼復用性。 例如，收入 Ine實體類與IneService類、 IneDao接口關聯的類圖，如 圖 3– 10所示： 圖 3– 10 收入實體類相關聯類圖 根據上述對邊界類、業務邏輯層的 Service類以及數據訪問層的 DAO接口及實現類的分析， 對各個實體類對應的邊界類、 Service類和 DAO接口及實現類 設計屬性和 方法之后，進行 系 統 類圖的重新繪制， 如 圖 3– 11和 圖 3– 12所示： 第 3章 系統設計 36 圖 3– 11 重新繪制的類圖 1 第 3章 系統設計 37 圖 3– 12 重新繪制的類圖 2 在 系統各種類型的 類的屬性和方法都添加 了之后，需要對 分析 模型中 的順序 圖 進行細化， 使得消息和職責在順序 圖中得到良好的體現， 并且將邊界類和控制類添加到順序圖中，使對用例的事件流有更為直觀的描述 。 “支出管理”用例包括：新增支出、編輯支出和刪除支出。 “新增支出” ： 用戶首先進入系統的新增支出界面， 根據頁面 UI組件的提示來錄入相關數據 ， 其 中 有 一 級 支 出 類 別 ， ExpenseActivity 邊界類通過getParentExpenseCategory()方法獲取 ParentExpenseCategory對象 ； 而二級支出類別是在一級支出類別的基礎上關聯獲取的， 通過 ParentExpenseCategory對象的getSubExpenseCategory()方法 ；同理通過 getAccount()方法獲取 Account對象；ExpenseActivity邊界類再將用戶錄入的各數據進行驗證、封裝成為 Expense支出對象，通過 ExpenseService的 add(expense : Expense)方法將 Expense對象持久化；ExpenseService繼續調用 IExpenseDao的 add(expense : Expense)方法將 Expense對象存第 3章 系統設計 38 入數據庫中。 其順序圖如 圖 3– 13所示： : U s e r : E x p e n s e A c t iv it ye x p e n s e : P a r e n t E x p e n s e C a t e g o r y : S u b E x p e n s e C a t e g o r y : A c c o u n t : E x p e n s e : E x p e n s e S e r v ic e : I E x p e n s e D a o : M a in A c t iv it ya d d E x p e n s ec r e a t eg e t P a r e n t E x p e n s e C a t e g o r y ( )g e t S u b E x p e n s e C a t e g o r y ( )s u b E x p e n s e C a t e g o r ya d d ( e x p e n s e : E x p e n s e )e x p e n s ea d d ( e x p e n s e : E x p e n s e )g e t A c c o u n t ( )a c c o u n tu p d a t e E x p e n s ee x p e n s e : = g e t E x p e n s e ( )e x p e n s e : = g e t E x p e n s e ( )e x p e n s ee x p e n s eg e t P a r e n t E x p e n s e C a t e g o r y ( )g e t S u b E x p e n s e C a t e g o r y ( )g e t A c c o u n t ( )u p d a t e E x p e n s e ( e x p e n s e : E x p e n s e )u p d a t e E x p e n s e ( e x p e n s e : E x p e n s e )s u c c e s ss u c c