團隊做業2

時間 2019-11-08

標籤團隊简体版

原文原文鏈接

團隊成員：李澤陽（隊長）、季城宇、李旭、謝雨豪html

李旭，博客園連接：http://www.cnblogs.com/lixu512/p/6118829.htmljava

謝雨豪，博客園連接：http://www.cnblogs.com/swwl/p/6118833.htmlpython

季城宇，博客園連接:http://www.cnblogs.com/arthur0618/p/6119172.htmlgit

目錄程序員

1.概述web

1.1 開發背景數據庫

1.2 開發目標安全

1.3 參考資料服務器

1.4 設計原則微信

2.需求分析

2.1 需求陳述

2.2 操做用例

2.3 功能分析劃分

2.3.1 系統登陸

2.3.2 用戶管理

2.4 運行環境

3.整體設計

3.1 系統建模

3.1.1 層次方框圖

3.1.2 ER圖（實體-聯繫圖）

3.1.3 類圖設計

3.2 接口設計

3.2.1 內部接口設計

3.2.2 登陸界面設計

3.2.3 用戶管理界面設計

3.3數據庫結構設計

3.3.1 數據庫E-R圖

3.3.2 數據庫邏輯設計

3.4 出錯處理

3.5 安全保密設計

4.詳細設計

4.1 程序流程圖

4.2 僞代碼編寫

5.實現

5.1 編碼

5.1.1 代碼約定

5.1.2 代碼編寫原則

5.2 測試要點

5.2.1 登陸測試要點

5.2.2 主界面測試要點

5.3 測試結果和總結

6.維護

6.1 維護方法

6.2 維護文檔

6.3 功能拓展方法

1 概述

1.1 開發背景

目前市場還沒有出現或基本沒有這方面的軟件:基於社會組織或特定志願愛心活動，在軟件上實現登陸、預定、參與的這麼一個服務系統，通過咱們的調研和思考，認爲這方面服務應該被發現和發倔，使得有更多的人蔘與到愛心志願活動中來。

1.2 開發目標

基本功能：1.實現用戶登陸和管理員登陸兩種。用戶需先註冊用戶賬號和密碼，管理員統一使用固定帳號與密碼。

2.主界面分爲三個部分：首頁、推薦、個人

首頁模塊主要包括「個人預定」、「活動信息公佈」。

推薦主要包括「近期活動」、「精彩回顧」。

個人主要包括「個人信息」、「設置」、「退出帳戶」。

設置可包括「修改賬戶密碼」、「網辦進度」。

1.3 參考資料

暫無

1.4 設計原則

第一原則：簡潔性。軟件設計並非一種隨意的過程，在軟件設計中須要考慮不少因素。全部的設計都應該儘量簡潔，但不是過於簡化。這有助於構建更易於理解和易於維護的系統。這並非說那些特徵甚至是內部特徵應該以「簡練」爲藉口而取消。的確，優雅的設計一般也是簡潔的設計，簡練也不意味着「快速和粗糙」。事實上，它常常是通過大量思考和屢次工做迭代才達到的，這樣作的回報是所獲得的軟件更易於維護且存在更少錯誤。

第二原則：調用數據庫。因爲用戶須要預定或進行相關操做，故須要調用數據庫，完成相應功能。

第三原則：可拓展性。經過軟件框架來實現：動態加載的插件、頂端有抽象接口的認真設計的類層次結構、有用的回調函數構造以及功能頗有邏輯而且可塑性很強的代碼結構。可擴展性是軟件設計的原則之一，它以添加新功能或修改完善現有功能來考慮軟件的將來成長。可擴展性是軟件拓展系統的能力。

2 需求分析

2.1 需求陳述

本次做業須要完成的是題名爲愛心服務平臺的互聯網+項目。主要需求爲用戶可以經過登陸或註冊進入主界面查看到推送的信息，即身邊的社會組織或特定的志願活動，而且可以預定申請加入他們的團隊，包括預定和取消預定功能，用戶還能夠查看而且修改本身的我的信息和本身預定過的活動。最後，須要有退出帳戶功能。

2.2 操做用例

首先具備登陸和註冊功能，登陸功能包括用戶登陸和管理員登陸功能，登陸或註冊以後進入主界面，其中有三個選擇，爲：「首頁」，「推薦」和「個人」。點擊「首頁」會彈出一個下拉框，包括「個人預定」和「活動信息分佈」兩部分；「推薦」部分主要包括「近期活動」和「精彩回顧」；「個人」部分主要包括「個人信息」、「設置」和「退出帳戶」，可包括點擊任一部分會推送相應的內容。其中「設置」部分可包括「修改帳戶密碼」和「網辦進度」，點擊「退出帳戶」以後，頁面彈回到登陸界面。

2.3 功能分析劃分

2.3.1 系統登陸

登陸模塊分爲三種，註冊，普通登陸，自動登陸。

點擊註冊須要填寫如姓名，設置密碼等信息，，完成註冊進入主界面。其中可能出現的狀況：姓名含有字符、特殊符號（如*、￥、%、@等）、密碼無特殊符號（能夠是數字或者大小寫都可））以上狀況都會致使註冊或者登陸失敗，需從新點擊註冊或清空從新登陸。

登陸須要填寫帳號和密碼做爲登陸條件，若帳號和密碼不符，則會彈出帳號或密碼錯誤，需從新登陸。

自動登陸功能：點擊選擇框選中自動登陸功能，便可實現下次進入是自動登陸。

2.3.2 預定管理

主頁推送的「活動信息公佈」，點擊進去以後會顯示活動的詳細信息而且下方有是否預定活動的選項，點擊預定便可預定成功。若不預定，點擊返回便可。

「個人預定」功能可以將用戶預定的活動詳情以列表形式展示出來，點擊每一個活動鏈接便可顯示活動明細，點擊右上角「選擇」，會在每一個預定信息後出現一個複選框，點中便可選擇刪除，複選框能夠多選和全選。

2.3.3用戶管理

在「設置」部分中會對用戶的我的信息進行管理，能夠查看和修改用戶的詳細信息，好比說點擊修改密碼，會彈出一個界面，須要填寫舊密碼、新密碼和再一次填寫新密碼。若是就密碼輸入錯誤或兩次輸入的新密碼不一致，則修改失敗，刷新修改界面，若果放棄修改，點返回便可。

2.4 運行環境

使用Android Stdio1.0軟件編寫

運行要求：Android 4.0及以上

2.5 出錯處理

（1）「用戶」界面可能出現的錯誤

a.註冊時出錯

1）用戶名，密碼中出現非法字符或超出額定長度；

2）驗證碼錯誤。

b.登陸出錯

1）用戶名或密碼錯誤

2）軟件可能出現的錯誤

（2）首頁包括：個人預定、志願活動

「志願活動」頁面可能出現的錯誤：

1）出現過時活動；

2）活動信息出錯：時間，地點與實際志願活動不符，活動簡介與活動信息不符；

3）點擊肯定參加後，界面無響應；

「個人預定」界面錯誤：

1）在志願活動界面成功預定後，在個人預定中無記錄；

2）預定記錄與實際預定狀況不符；

（3）「個人」界面

1）修改界面無響應，沒法修改信息；

2）顯示成功修改後，信息不變；

3）退出後會清空帳號信息

2.6保障安全性

初次註冊的用戶會綁定一個手機號碼用做驗證，另外用戶可選擇數字密碼或圖案密碼對涉及我的信息的頁面進行保護。

密碼啓動機制

1.用戶可選擇開啓密碼輸入，開啓後用戶在每一次須要訪問我的信頁面時都需輸入預先設置的密碼才能進入頁面。（可直接實現防盜，但操做不便）

2.防盜應急機制（可選擇開啓，推薦開啓）

用戶在開啓防盜應急機制後，須要綁定另外一個手機號碼做爲備用號碼。當手機失竊或更換手機號碼時，需在使用備用號碼的手機上從新註冊帳戶，收取驗證碼的手機號碼即爲備用號碼，系統檢測到該號碼後會提示用戶選擇啓動密碼保護（提早未開啓密碼保護），手機丟失可選擇凍結帳號，沒法登錄，用戶可以使用備用號碼進行從新註冊，我的信息容許相同；更換手機號碼則能夠選擇正常登錄。

3 整體設計

3.1 系統建模

3.1.1 層次方框圖

3.1.2 ER圖（實體-聯繫圖）

3.1.3 類圖設計

【使用UML畫出各個類的屬性、繼承和方法】

3.2 接口設計

【各個子系統之間的接口和用戶接口】

3.2.1 內部接口設計

【各個部件是經過何種方式進行鏈接，好比經過遠程數據庫，http等】

3.2.2 登陸界面設計

效果展現：

3.2.3 用戶管理界面設計

3.3 數據庫結構設計

3.3.1 數據庫E-R圖

3.3.2 數據庫邏輯設計

user

message

4 詳細設計

4.1 程序流程圖

【具體來講就是把通過整體設計獲得的各個模塊詳細的加以描述。】

4.2 僞代碼編寫

【使用中文或者英文進行僞代碼編寫，之後這些僞代碼將會成爲代碼的註釋】

5 實現

5.1 編碼

5.1.1 代碼約定

1.零註釋（公共 API 除外）

2.不要用「Test」爲測試方法開頭

3.不要使用@Override

4.不要使用 getX()/setY() 這樣的函數名

5.可運行的代碼>高性能的代碼

6.使用本身的異常類型

5.1.2 代碼編寫原則

(1) 類名首字母應該大寫。字段、方法以及對象(句柄)的首字母應小寫。對於全部標識符，其中包含的全部單詞都應緊靠在一塊兒，並且大寫中間單詞的首字母。

若在定義中出現了常數初始化字符，則大寫static final基本類型標識符中的全部字母。這樣即可標誌出它們屬於編譯期的常數。

Java包(Package)屬於一種特殊狀況：它們全都是小寫字母，即使中間的單詞亦是如此。對於域名擴展名稱，如com，org，net或者edu等，

所有都應小寫(這也是Java 1.1和Java 1.2的區別之一)。

(2) 對於本身建立的每個類，都考慮置入一個main()，其中包含了用於測試那個類的代*。爲使用一個項目中的類，咱們不必刪除測試代*。

若進行了任何形式的改動，可方便地返回測試。這些代碼也可做爲如何使用類的一個示例使用。

(3) 應將方法設計成簡要的、功能性單元，用它描述和實現一個不連續的類接口部分。理想狀況下，方法應簡明扼要。

若長度很大，可考慮經過某種方式將其分割成較短的幾個方法。這樣作也便於類內代碼的重複使用(有些時候，方法必須很是大，但它們仍應只作一樣的一件事情)。

(4) 設計一個類時，請設身處地爲客戶程序員考慮一下(類的使用方法應該是很是明確的)。

而後，再設身處地爲管理代碼的人考慮一下(預計有可能進行哪些形式的修改，想一想用什麼方法可把它們變得更簡單)。

5.2 測試要點

5.2.1 登陸測試要點

【描述該如何測試，數據的輸入，類型】

5.2.2 主界面測試要點

……

5.3 測試結果和總結

6 維護

6.1 維護方法

1.迅速發現須要變動內容的工具

不管是修復 bug 仍是系統加強，首先都要找到該用例調用的你須要修改的類及方法。基本有兩種方式理解一個用例的工做方式，靜態代碼分析和運行時分析。

源碼分析統計掃描全部代碼而且展現類之間的關係。市場上有不少設備與工具。好比：Architexa， AgileJ， UModel， Poseidon 等。

全部的靜態代碼分析工具缺點在於沒法確切展現用例中類或方法的運行時調用狀況。所以 Java 新加入了特性，如回調機制（callback patterns）。如靜態分析工具沒法推斷出當頁面提交按鈕被點擊時哪一個 Servlet 被調用了。

運行時分析工具可以展現類和方法在用例運行時的狀態。工具包括：MaintainJ， Diver，jSonde，Java Call Tracer 等。這些工具能夠捕獲運行時的堆棧狀態，並以此爲一個用例生成序列圖和類圖。

序列圖展現了該用例在運行時全部調用的方法。若你在修復一個 bug，那這個 bug 極可能就是這些被調用的方法之一。

若你在加強已有功能，利用序列圖理解調用流程而後再修改。多是新增一個驗證，修改 DAO 等。

若你在新增功能，找到一些類似的特性，利用序列圖理解調用流程而後模仿開發新功能。

要當心挑選運行時分析工具。信息過可能是這類工具的主要問題。選擇一些提供簡單過濾無效信息並可以方便的查看各類視圖的工具。

2 迅速發現須要變動內容的工具

若單元測試有效，能夠經過運行單元測試發現變動有沒有破壞其餘測試用例。有效維護而且覆蓋大型企業應用的單元測試仍是比較少的。下面有一些針對該狀況的工具。

仍然是有兩種技術靜態代碼分析和運行時分析可使用。市場中有不少靜態代碼分析工具可用。如：Lattix， Structure101, Coverity， nWire and IntelliJ's DSM。

給定一個變動後的類，上述工具都可識別對該類存在依賴的類的集合。開發者須要根據這些信息「猜想」可能產生影響的用例，由於這些工具沒法展現運行時類之間的調用關係。

市場上的能夠用於運行時影響分析的工具並很少，除了 MaintainJ。MaintainJ 先捕獲在一個用例中調用的全部類和方法。當全部用例的上述信息都被捕獲以後，就很容易發現類的變動對用例的影響。MaintainJ 可以有效工做的前置條件就是項目的全部用例都應當先運行一遍，以便可以得到運行時的依賴關係。

總之，目前你在迅速準確分析變動影響方面，仍是能夠從工具中得到有限的幫助。首先根據須要實施一些影響分析，而後根據本身或小組其餘高級成員評審來判斷變動的影響。你可能須要上面提到的工具對你的判斷進行反覆確認。

6.2 維護文檔

把生成API文檔做爲構建過程的一部分。不一樣語言下有不一樣的工具，好比Java內置了javadoc，python則能夠考慮Sphinx。生成所得的html文檔，打包成壓縮包，保存起來。
搭建一個用做文檔瀏覽的web服務器，把各個項目的文檔壓縮包，按項目+版本，直接解壓放到文件系統上，就能夠對外提供瀏覽。這就是 Home | Read the Docs 在作的事了。不過，只要生成的文檔是html格式，咱們並不須要侷限在python項目。
API文檔只是須要被高效維護的文檔之一。項目中還有其餘形式的文檔，一樣須要被維護。文檔就別用word來寫了，能夠考慮引入Sphinx、gitbook一類的工具，而後用markdown/rst之類的手段來編寫文檔。這樣的文檔，能夠像代碼同樣被存放到scm中，便於追蹤和協做編寫。也能夠像API文檔那樣，在構建時生成，而後送到存放文檔的web服務器上。