阿里八八「好記」——系統設計

---

說明書修改

需求規格說明書Github連接

不足之處

一、最終軟件版本的需求考慮還不完善，用戶模塊成了一個沒有實際功能的毫無心義的模塊，所以咱們增長了對用戶模塊的基本功能需求，擬實現日程的雲同步功能，使得用戶能夠在不一樣設備對日程進行查看。

二、針對第一點的改動，修改了類圖以及原型界面等。

三、原稿中存在圖片尺寸不合適，同類圖片尺寸不一致等狀況，生成的文檔十分不便於閱讀，咱們調整了統一的圖片尺寸，並把用例圖等圖片的過大尺寸放小，使得文檔更便於閱讀。

---

代碼規範

命名規範

• 控件縮寫

控件	縮寫	控件	縮寫
TextView	text	ProgressBar	bar
EditText	edt	SeekBar	seek
Button	btn	CheckBox	chk
ImageButton	ibtn	Spinner	spin
ImageView	img	TableLayout	table
ListView	list	TableRow	row
RadioGroup	group	LinearLayout	llayout
RadioButton	rbtn	RelativeLayout	rlayout
ScrollView	scroll	SearchView	search
TabHost	host	TabWidget	widget

• 局部變量命名

{範圍描述+}意義描述+類型描述 的組合，用駝峯式，首字母小寫。

例子：

private TextView headerTitleText; // 標題欄的標題 

private Button loginBtn; // 登陸按鈕

• 靜態變量命名

所有爲大寫單詞，單詞之間用下劃線分開。

例子：

public final static int PAGE_SIZE=20;

• 類成員變量命名

{範圍描述+}意義描述+類型描述的組合，用駝峯式。

private TextView HeaderTitleText; // 標題欄的標題 
private Button LoginBtn; // 登陸按鈕

• 類命名

使用大駝峯規則，用名詞或名詞詞組命名，每一個單詞的首字母大寫。 如下爲幾種經常使用類的命名：

activity 類，命名以 Activity 爲後綴，如：LoginActivity，放在根目錄下。

fragment 類，命名以 Fragment 爲後綴，如：DialogFragment，放在 fragment文件夾下。

service 類，命名以 Service 爲後綴，如：DownloadService，放在 service 文件夾下。

adapter 類，命名以 Adapter 爲後綴，如：CouponListAdapter，放在 adapter 文件夾下。

canvas 類，命名以 canvas 爲後綴，如 StepCanvas，放在 Canvas 文件夾下。

painter 類，命名以 Painter 爲後綴，如 ShapePainter，放在 Painter 文件夾下。

基礎類，命名以 base 爲後綴，如 CanvasBase，放在 Base 文件夾下。

通用類，如簡單的自定義控件、輔助類，放在 common 文件夾下。

• 方法命名

使用小駝峯規則，用動詞命名，第一個單詞的首字母小寫，其餘單詞的首字母大寫。

如下爲幾種經常使用方法的命名：

初始化方法，命名以 init 開頭，例：initView()。

按鈕點擊方法，命名以 on 開頭，Click 結尾，例：onLoginClick()。

設置方法，命名以 set 開頭，例：setData()。

具備返回值的獲取方法，命名以 get 開頭，例：getData()。

經過異步加載數據的方法，命名以 load 開頭，例：loadData()。

布爾型的判斷方法，命名以 is 或 has，例：isEmpty()

• layout 命名

組件類型_{範圍_}功能，範圍可選，如下爲幾種經常使用的組件類型命名：

activity_{範圍_}功能，爲 Activity 的命名格式。

fragment_{範圍_}功能，爲 Fragment 的命名格式。

dialog_{範圍_}功能，爲 Dialog 的命名格式。
item_list_{範圍_}功能，爲 ListView 的 item 命名格式。

item_grid_{範圍_}功能，爲 GridView 的 item 命名格式。

header_list_{範圍_}功能，爲 ListView 的 HeaderView 命名格式。

footer_list_{範圍_}功能，爲 ListView 的 FooterView 命名格式

書寫規範

• 括號

花括號不要單獨一行，和它前面的代碼同一行。並且，花括號與前面的代碼之間用一個空格隔開。

public void method() {

}

• 空格

if、else、for、switch、while等邏輯關鍵字與後面的語句留一個空格隔開。

if(boolVar) {

} else {
    
}

運算符兩邊各用一個空格隔開。

int c = a + b;

方法的每一個參數之間用一個空格隔開。

public void method(String param1, String param2);
method(param1, param2)

縮進統一使用4個空格，由於不一樣編輯器對tab顯示不一樣。

• 空行

空行之空一行，不要多空行。在一下狀況須要用一個空行：

一、兩個方法之間
二、方法內的兩個邏輯段之間
三、方法內的局部變量和方法的第一條邏輯語句之間。
四、常量與變量之間

• 其餘

一、應用中的字符串同一在strings.xml中定義，而後在代碼和佈局文件中引用。

二、一行聲明一個變量，不要一行聲明多個變量，這樣有利於註釋。

private String param1;
private String param2;

三、當一個表達式沒法容納在一行內時，可換行顯示，另起的新行用八個空格縮進。

someMethod(longExpression1, longExpression2
        longExpression3,longExpression4)

註釋規範

• 文件頭註釋

文件頂部統一添加版權聲明，聲明格式以下：

/**
 * 2017/10/16
 * Copyright (c) Jun yu Inc. All rights reserved
 */

• 類和接口的註釋

類和接口統一添加註釋，格式以下：

/**
 *類或接口的描述信息
 */

• 方法註釋
  方法同一添加註釋，說明用途，參數說明和返回值說明。

/**
 *登陸
 *
 *@param loginName 登陸名
 *@param password 密碼
 */

• 變量與常量註釋

下面幾種狀況的變量和常量，都要添加註釋，有限採用右側//來註釋，若註釋太長則在上方添加註釋。

一、接口中定義的全部常量
二、公有類的公有常量
三、枚舉類定義的全部枚舉常量
四、實體類的全部屬性變量

public static final int TYPE_CASH = 1;    //現金券
public static final int TYPE_DEBIT = 2;   //折扣券

private int id;         //券id
private String name     //券名稱

總結

制定代碼規範「看似表面文章，實則很是重要」，合理的代碼規範有助於團隊開發過程有更高的效率，所以咱們遵循簡明，易讀，無二義性的原則制定了咱們團隊的代碼規範，主要體如今:

一、變量名和方法名用小駝峯規則，一眼就能看出它的做用，簡潔明瞭。

二、括號和運算符加空格，總體代碼看起來更工整舒服。

三、註釋採用javadoc註釋格式，能讓其餘人快速看懂方法和接口的做用，加強了代碼的可讀性，使代碼改寫和維護更加方便。

---

數據庫ER圖

解釋：
ActivityTime:活動時間

Activity:活動內容

Clock:鬧鐘（提醒時間）

ActivityClass:活動類型

ActivityTitle:活動標題

PhoneNum:手機號

Id:日程編號

UserName:用戶名

PhoneNum:手機號

PassWord：密碼

QQ：qq號

WeiBo:微博號

Picture：頭像

---

後端架構設計

主要功能描述

在Android開發中，Activity並非一個標準的MVC模式中的Controller，它 的首要職責是加載應用的佈局和初始化用戶界面，並接受並處理來自用戶的操做請求，進而做出響應。隨着界面及其邏輯的複雜度不斷提高，Activity類的 職責不斷增長，以至變得龐大臃腫。當咱們將其中複雜的邏輯處理移至另外的一個類（Presneter）中時，Activity其實就是MVP模式中 View，它負責UI元素的初始化，創建UI元素與Presenter的關聯（Listener之類），同時本身也會處理一些簡單的邏輯（複雜的邏輯交由 Presenter處理）。

View不直接與Model交互，而是經過與Presenter交互來與Model間接交互，Presenter與View的交互是經過接口來進行的，更有利於添加單元測試，一般View與Presenter是一對一的，但複雜的View可能綁定多個Presenter來處理邏輯。

1.用戶登陸註冊

2.手動添加日程事件

3.語音識別添加日程事件

4.圖像識別提取日程信息

5.完善和修改用戶信息

MVP框架

模型（Model）：數據層爲UI層提供的數據，或者保存UI層傳下來的數據負責對數據的存取操做，好比存儲、檢索、操縱數據。

視圖（View）：顯示數據（model）而且將用戶指令（events）傳送到presenter以便做用於那些數據的一個接口。負責繪製UI元素、與用戶進行交互(在Android中體現爲Activity)View，一般含有Presenter的引用。

Presenter:做爲View與Model交互的中間紐帶，處理與用戶交互的負責邏輯。View與Model並不直接交互，而是經過與Presenter交互來與Model間接交互。Presenter層會從Model層得到所須要的數據，進行一些適當的處理後交由View層進行顯示。這樣經過Presenter將View與Model進行隔離，使得View和Model之間不存在耦合，同時也將業務邏輯從View中抽離。

選用該框架的緣由有以下幾點：

1.模型與視圖徹底分離，咱們能夠修改視圖而不影響模型。分離了視圖邏輯和業務邏輯，下降了，耦合。

2.全部的交互都發生在一個地方——Presenter內部，高效地使用模型。

3.Presenter 被抽象成接口，能夠有多種具體的實現，因此方便進行單元測試

4.Activity 代碼變得更加簡潔

數據庫模型

文件目錄模型

---

分而治之

Alpha版本WBS圖

Issues任務認領結果

TODO List

102：好記總體框架繪製

513：用戶基本界面繪製+用戶基本功能實現

427：用戶基本界面繪製+用戶基本功能實現

124：用戶基本界面繪製+用戶基本功能實現

538：後臺數據庫搭建

118：日程表單日顯示界面繪製

529：日程表多日自由定製顯示

500：文本日程輸入

燃盡圖

---

分工比例

葉文滔：

李嘉羣： 張嶽： 俞鋆： 劉曉： 黃梅玲： 王國超： 林煒鴻：