項目UML設計

團隊信息

• 隊名：火箭少男100
• 本次做業課上成員

短學號	名	本次做業博客連接
2507	俞辛(臨時隊長)	http://www.javashuo.com/article/p-wbhimzck-ce.html
2523	宏巖	http://www.cnblogs.com/031602523liu/p/9822823.html
1131	喜源	http://www.cnblogs.com/comeony/p/9823369.html
2502	柏濤	http://www.cnblogs.com/cbattle/p/9823300.html
2431	源	http://www.cnblogs.com/circlek/p/9823269.html
2439	凱欣	http://www.cnblogs.com/ykxx/p/9822397.html
2219	奇豪	http://www.cnblogs.com/S031602219/p/9822576.html
2230	愷翔	http://www.cnblogs.com/leolkx/p/9823308.html
2509	鈞昊	http://www.cnblogs.com/tomvii/p/9823307.html
2325	燊	http://www.cnblogs.com/linshen/p/9823348.html

• 原組成員

短學號	名	本次做業博客連接
2325	燊(隊長)	http://www.cnblogs.com/linshen/p/9823348.html
1232	志豪	http://www.cnblogs.com/dldr/p/9823347.html
1131	喜源	http://www.cnblogs.com/comeony/p/9823369.html
2523	宏巖	http://www.cnblogs.com/031602523liu/p/9822823.html
2230	愷翔	http://www.cnblogs.com/leolkx/p/9823308.html
2509	鈞昊	http://www.cnblogs.com/tomvii/p/9823307.html
2507	俞辛	http://www.javashuo.com/article/p-wbhimzck-ce.html
2501	宇航	http://www.cnblogs.com/mercuialC/p/9823310.html
2502	柏濤	http://www.cnblogs.com/cbattle/p/9823300.html

團隊分工

分而治之

• 在劃分具體工做模塊上，咱們也更願意從最終的產品開始，一層一層往下，把大型交付件分割爲小型、具體的交付件。
• 交付件便可獨立實現且與其餘模塊的耦合度較低的功能模塊。
• 對於咱們的主功能——AR識別商鋪名返回商鋪信息
  及咱們的副功能——基於GPS定位的智能推薦，咱們可依次分割這兩個功能爲如下幾個模塊。
  
• AR識別商鋪名返回商鋪信息

• 關於AR模塊的三個功能，這裏我簡單闡述一下：
  
• 運動追蹤
  • 在物體運動或者設備運動的過程當中，追蹤目標物體，具體取決於虛擬物體和在場人員的數量。還要考慮移動手機使用 AR 時，可能會引發不安全或者阻礙了與現實世界的互動。
• 虛擬交互
  • 主要爲體如今與虛擬資源交互，如選擇容許用戶辨別、操縱虛擬物體，以及與虛擬物體交互，同時要避免在平移過程當中物體的忽然變換或縮放比例。
• 環境加強
  • 當 AR 內容對現實世界環境作出反應時，經過陰影、光照、遮擋、反射和碰撞來模擬物體的真實存在，可是用戶可能所以難以在加強現實體驗中感知深度和距離。利用陰影、遮擋、透視、紋理、常見物體的比例，以及放置參考物體來可視化表達深度。例如：商鋪招牌的流水單引發的光線變化，經過這樣可視化方式代表空間深度。
• 基於GPS定位的智能推薦

• 在獲取位置輸入的前提下，咱們將推薦算法模塊分爲兩個部分，基於位置的協同過濾以及基於用戶的協同過濾，首先介紹一下協同過濾
• 協同過濾
  • 它的原理很簡單，就是根據用戶對物品或者信息的偏好及興趣採樣；
  • 發現物品或者內容自己的相關性，或者是發現用戶的相關性，
  • 而後再基於這些關聯性進行推薦。
• 接下來在介紹一下基於位置的協同過濾以及基於用戶的協同過濾
• 基於位置的協同過濾
  • 在給用戶作推薦的時候，根據用戶過往興趣偏好、地理位置及其時間衰減因子的比重來獲得推薦信息。
• 基於用戶的協同過濾
  • 在給用戶作推薦的時候，根據多用戶的共同興趣偏好、地理位置及其時間衰減因子的比重來獲得推薦信息。

---

alpha版本實現內容

• ①咱們實現安卓前端設計(UI設計) 以及 後端開發
• ②咱們實現目標檢測模塊以及文字識別模塊的算法實現以及優化
• ③經過AR接口實現後端與天然場景下文字識別模型的鏈接。

分工

分工明細

• 具體模塊以下圖所示

• 咱們的alpha模塊主要針對於咱們的核心功能AR識別商鋪名返回商鋪信息來實現，咱們也爲各組覆蓋到每名成員劃分了工做細則——TODO list。

TODO list

短學號	名	工做細則
2325	燊(隊長)	目標檢測模塊與文字識別的模塊間的接口設計及性能優化
1232	志豪	前端UI設計、開發
1131	喜源	完成數據庫的架設、創建服務器端與數據庫的鏈接
2523	宏巖	數據爬取，數據集標註
2230	愷翔	文字識別算法實現
2509	鈞昊	目標檢測算法實現
2507	俞辛	文檔編寫
2501	宇航	實現後端與AR識別模塊間的交互模塊
2502	柏濤	實現後端與前端UI間接口、附加功能嘗試性開發

燃盡圖

• 如下是咱們設計的任務卡片，其中文字識別和目標檢測模塊以及完成初步實現，只是仍需對現有模塊進行鍼對應用的改進

• 燃盡圖以下所示

• 因爲部分任務的實現環節甚至在團隊做業開始以前咱們已經完成，因此咱們後續的規劃包括任務分割也會對此作必定調整。

UML

PART 1 —— 用例圖

1. 我的管理系統和登陸系統

• 這裏描述的是系統哪部分？
  • 這裏是用戶我的管理系統和登陸系統的用例圖。
• 這部分面臨什麼樣的問題？
  • 這部分要面臨用戶登陸、註冊驗證、忘記密碼的基本問題，用戶的管理系統涉及我的信息維護、系統緩存和恢復加載等問題。
• 如下設計解決了哪些問題？
  • 展示了客戶與咱們軟件之間的交互聯繫，便於咱們對用戶我的管理系統和登陸系統的可視化和軟件原型設計，使用戶可以理解使用登陸和我的信息的聯繫，更方便操做，並使開發者可以有條理的實現這些元素。
• 附：

1. 社區管理系統

• 這裏描述的是系統哪部分？
  • 這裏是社區管理系統的用例圖。
• 這部分面臨什麼樣的問題？
  • 這部分要面臨搜索店鋪，推薦店鋪等算法問題，以及查看附近動態的及時性。
• 如下設計解決了哪些問題？
  • 展示了社區管理的基本框架，便於咱們對社區系統的可視化和軟件原型設計，用戶能夠經過這個圖更加理解社區的基本功能，便於操做。
• 附：
  

PART 2 —— 類圖

• 這裏描述的是系統哪部分？
  • 描述了系統每一個部分之間的關係、鏈接狀況。
• 這部分要面臨什麼樣的問題？
  • 對於Yolo和CRNN類的使用，須要使用預先訓練的參數。參數的訓練，須要包含大量數據的數據集，然而，如今尚未有針對性的已經標註好的數據集，這就須要咱們手動收集數據，進行標註，須要大量的人力物力。
  • 卷積運算須要強大的運算能力支持，較低端的單核CPU服務器計算能力較弱，可能沒法知足實時性的需求。將會採用更高性能的CPU服務器甚至GPU服務器。可是這樣成本較高。
• 如下設計解決了哪些問題？
  • 解決了開發者對於各個類體之間關係的宏觀認識。
• 附：
  

PART 3 —— 活動圖

• 這裏描述的是系統哪部分？
  • 描述軟件的大體使用流程，以及店鋪掃描、評論分享功能的使用流程。
• 這部分面臨什麼樣的問題？
  • 用戶在使用軟件的時候流程較爲複雜，活動圖能夠幫助用戶梳理整個軟件的使用流程。
• 如下設計解決了哪些問題？
  • 幫助用戶理清軟件的使用流程，明確各個功能的使用細節。
• 附：
  

PART 4 —— 狀態圖

1. 登入界面

• 這裏描述的是系統哪部分？
  • 用戶登入註冊的部分。
• 這部分面臨什麼樣的問題？
  • 面臨帳號的登入註冊以及遊客登入的設計邏輯的問題。
• 如下設計解決了哪些問題？
  • 解決了在設計登入註冊找回密碼以及遊客登入這幾個方面的邏輯順序。
• 附：
  

1. 主要功能

• 這裏描述的是系統哪部分？
  • 用戶社交，店鋪搜索以及進行店鋪收藏評論的部分。
• 這部分面臨什麼樣的問題？
  • 面臨在用戶使用軟件的幾個主要功能時候的交互操做的邏輯。
• 如下設計解決了哪些問題？
  • 解決了在設計界面主要功能時候。面臨搜索店鋪卡片，查看店鋪介紹，收藏店鋪，點評店鋪。此外，從收藏的店鋪中進行評論店鋪。還有對社交部分的交互邏輯，設計點贊和評論的功能。
• 附：
  

PART 5 —— 實體關係圖

• 這裏描述的是系統哪部分？
  • 這是系統內部各個部分之間的實體關係圖。
• 這部分面臨什麼樣的問題？
  • 這部分將面對如何構建總體數據庫與內部細分以及各數據庫之間的聯繫問題。
• 如下設計解決了哪些問題？
  • 使得各個環節與內部關係之間的聯繫更加的明確，更方便地在後續的編碼過程裏明肯定義各實體對象。
• 附：
  

PART 6 —— 時序圖

• 這裏描述的是系統哪部分？
  • 描述系統中各個對象之間發送消息的時間順序，顯示整個系統和用戶之間的動態協做。
• 這部分面臨什麼樣的問題？
  • 系統各個部分及使用者之間的同步、異步等等時序邏輯的問題。
  • 各個模塊之間傳遞細節的差別問題。
• 如下設計解決了哪些問題？
  • 描述了各個部分之間的消息通訊，確認了模塊間的請求、等待等等關係。
• 附：
  

PART 7 —— 泳道圖

• 這裏描述的是系統哪部分？
  • 描述系統中各工做組工做規劃流程，顯示整個系統和用戶之間的動態協做。
• 這部分面臨什麼樣的問題？
  • 系統各個部分及使用者之間的同步、異步等等時序邏輯的問題。
  • 各個模塊之間傳遞細節的差別問題。
• 如下設計解決了哪些問題？
  • 描述了各部份內部鏈接關係以及各部分與部分之間的鏈接關係
• 附：

PART 8 —— 功能流程圖

• 這裏描述的是系統哪部分？
  • 該部分描述了系統的核心功能實現的流程圖
• 這部分面臨什麼樣的問題？
  • 處理圖片切片、數據獲取接口問題
  • 算法實現穩定性問題
• 如下設計解決了哪些問題？
  • 描述目標檢測模塊和文字識別模塊間具體流程圖
• 附：

PART 9 —— 功能實現圖

• 這裏描述的是系統哪部分？
  • 這裏描述了咱們主要功能的實現步驟。
• 這部分面臨什麼樣的問題？
  • 系統各個部分間聯繫，並行部分的實現的問題。
  • 模塊間傳遞參數的不穩定性問題。
• 如下設計解決了哪些問題？
  • 描述目標檢測模塊和文字識別模塊間的關聯以及內部實現的具體流程
• 附：

工具選擇

本次做業團隊的最終選擇爲 Process On

做業發佈以後，團隊就召集了一次小規模會議（由於比較忽然，有部分人沒能出席）。主要是在 Process On 和 Visio 二者之間進行選擇。最終考慮到如下幾點選擇了Process On：

• Process On 能夠很方便的在網頁上打開使用，而 Visio 須要在機房電腦上從新安裝
• Process On 的基本功能徹底免費，而 Visio 則是須要收費的
• 團隊中大部分紅員都有使用 Process On 的經歷，個別同窗仍是資深用戶

使用後對工具的評價

PSP表格

PSP2.1	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	40	60
· Estimate	· 估計這個任務須要多少時間	40	60
Development	開發	445	500
· Analysis	· 需求分析 (包括學習新技術)	120	150
· Design Spec	· 生成設計文檔	60	60
· Design Review	· 設計複審	20	40
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	15	20
· Design	· 具體設計	30	30
· Coding	· 具體編碼	120	120
· Code Review	· 代碼複審	20	20
· Test	· 測試（自我測試，修改代碼，提交修改）	60	60
Reporting	報告	50	60
· Test Repor	· 測試報告	10	15
· Size Measurement	· 計算工做量	10	10
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	30	35
		合計	535

評估成員的貢獻分配

• 本隊「臨時隊長」給出的「課上」貢獻分評估
  

課堂貢獻度

短學號	名	「課上」貢獻分
2507	俞辛(臨時隊長)	14%
2523	宏巖	14%
1131	喜源	14%
2502	柏濤	16%
2431	源	16%
2439	凱欣	13%
2219	奇豪	13%
2230	愷翔	0%
2509	鈞昊	0%
2325	燊	0%

說明：13%是最基礎的貢獻度，其中奇豪和凱欣都按時完成了任務，可是都進行了返工。而柏濤和源提早完成任務而且高質量完成任務。剩下的同窗都是按時完成任務而且沒有返工。0%貢獻度的同窗本次課請假沒能參與，在線編程因爲比賽會場的網絡緣由，只能給出適當修改意見。

課後貢獻度

短學號	名	「課後」貢獻分
2507	燊	16%
2523	宏巖	7%
1131	喜源	7%
2502	柏濤	7%
2431	宇航	8%
2439	志豪	7%
2219	俞辛	8%
2230	愷翔	20%
2509	鈞昊	20%

說明：因爲燊、愷翔、鈞昊三人因比賽會場網絡緣由，沒能及時將繪製的UML類圖發給軟工時間的各位致使了軟工實踐課程的其餘同窗工做量大。因此在課後的安排中將絕大部分工做都安排給了燊、愷翔、鈞昊三人身上，因此這一次課後做業的大部分貢獻度都分給了這三位同窗。

我的心得

燊

• 首先做爲團隊的隊長，沒有參加此次軟工現場實戰，我感到十分遺憾。因爲比賽時間衝突的緣故，再加上賽場網絡限制的影響，咱們很難參與到現場實戰環節中。咱們設計的UML類圖也沒有辦法及時交付給現場的隊友們。
• 咱們只能經過後續採起的補救措施——承擔課後做業的大部分工做量來儘可能彌補咱們「肝」到心累的隊友們。咱們後續作的燃盡圖也儘可能貼合實際完成了各模塊及子模塊工做的劃分，但願可以在以後的alpha環節，跟你們一塊兒取得更好的表現。

宏巖

• 對於此次團隊做業，我原本應該是交換到別的隊伍去完成任務的。可是因爲咱們組的三位成員外出參加比賽，團隊內成員不足。通過和樂忠豪同窗的溝通以後，他容許了我留在原組的請求，首先要在這裏感謝他的理解！
• 本次做爲團隊成員，因爲團隊的人員較之前減小一些，加上臨時隊長比較溫順，因此團隊的氛圍相較之前會顯得沉寂一些。可是你們均可以專一於本身的任務，並及時的溝通，可是溝通只限於兩三我的之間，沒有整組成員沒有進行過共同的交流。評價被換進來的三位同窗，他們在和咱們明確了軟件的功能以後，迅速的的完成了各種UML圖的製做，可是卻存在着質量不高的問題，有幾張UML也被隊長退回修改屢次（可見臨時隊長真的很嚴格）。接下來評價一下新的隊長，和老隊長相比，新隊長顯得溫順一些，不能調動起你們的積極性，團隊缺乏共同的交流機會，這應該是新隊長要增強的地方。可是新隊長會比老隊長有更嚴格的要求。對咱們的貢獻度評分也很公平公正，並在最後下課的時候也給咱們解釋了評分緣由，這也是老隊長應該向新隊長學習的。
• 總而言之，對於此次集體做業，感謝你們能夠積極配合認真的完成各自的任務，隊長有條不紊的進行彙總並按時提交，學習了你們身上的優勢，帶給我不少的思考。

喜源

• 本次課堂UML設計迎來了一個特殊環節——團隊換人環節。身爲一個沒有被換走的隊員來講，在換隊以前，一想到別隊的成員來咱們隊幫忙作UML仍是挺懼怕的，由於UML設計須要對整個軟件有深刻的瞭解，而一個不是本組的人作起來會不會很吃力？
• 可是事實發現，新隊友仍是很強的，簡單的溝通後就明白了本身負責的圖形應該是個什麼樣。總體來看，咱們在臨時隊長的帶領下，整個過程井井有理，徹底不輸原隊長。新團隊的氛圍很平靜，討論比較少，各作各的，分工得當。原團隊討論會比較多，這是新團體所欠缺的。

柏濤

• 本次團隊任務爲增長趣味性，採起互換團隊成員的形式。我很幸運沒有被換到其餘組去。
• 對臨時隊長的感覺：
  • 1.在三位成員請假，隊長不在的狀況下，咱們的副隊長敢於承當重任，主動肩負起帶領全隊的責任，對團隊各成員的任務進行合理分配，調度協調，確保了各成員工做的順利開展。
• 對被換來的新隊友的感覺：
  • 1.與被換來的新隊友一塊兒工做，因爲你們彼此都不認識，在工做時少了嬉鬧，你們都認認真真的幹活，更加高效；
  • 2.因爲你們都不熟悉，沒什麼顧忌，能夠直接指出對對方方案的不足。利於方案的改進。
  • 3.常說「物以類聚，人以羣分。」能組成一個團隊，很大多是同一類人，有着類似的思想。換來的新隊友來自另外一個徹底不一樣的團隊，有着與原來團隊大相徑庭的思想，站在一個全新的角度思考問題，更容易想出新的創意，爲團隊注入新鮮血液。
• 新舊團隊氛圍對比
  • 1.新團隊比舊團隊多了幾分嚴肅，少了幾分歡樂。優勢是能夠更加高效地工做，缺點是工做變得無趣枯燥。

宇航

• 本次做爲幸運的被選中的交換隊員，體驗了一次別的組的工做氛圍，僅僅是這一次uml團隊做業來看（兩隊風格差別明顯，但從最後成果差別不大，另外對於「拖鞋旅遊隊」的工做氛圍可能只體驗了一次，感覺是片面的）。
• 相比於原隊伍，其餘隊伍優勢：行動力很高，缺點：工做氛圍交流溝通有所欠缺。「拖鞋旅遊隊」臨時隊長分工明確，製做uml圖時每一個圖都有對應的隊員分工，臨時隊長和原隊長風格不一樣，可是對於分工都是很明確的。
• 從行動力上看，「拖鞋旅遊隊」的執行力很高，各個成員很快就完成了本身的工做。可是對於製做不一樣uml圖的隊員之間缺少溝通。對於我我的來講，更喜歡原隊伍的工做氛圍，隊員之間溝通交流多，在明確分工的前提下互幫互助，原隊伍的執行力也是很高的。
• 同時也感謝此次交換機會，能感覺別的隊伍的工做氛圍，有幸能在「拖鞋旅遊隊」中參與他們項目的一部分（uml圖設計製做），感覺了這一隊伍的行動力（很讚的）。最後除了上面幾點的差異，在我看來兩支隊伍都是很優秀的。

志豪

• 做爲被換走的臨時隊員，我心裏是有些拒絕的。從一個熟悉的環境到陌生的地方合做，總會有種強烈不適應的感受。剛開始的確有些尷尬，看着旁邊兩三個同窗談笑風生，玩着我不是很懂的梗，硬接兩句，更尷尬了。還好我臉皮夠厚，還好尷尬總會被工做沖淡，也要感謝趙暢同窗以及他們小組成員的熱情款待。我在這一組並不會被孤立，相反，在個人積極爭取下，還能多作一個圖，獲得了不錯的貢獻分。
• 雖然我以爲我作的圖比較簡單，給的貢獻偏高了，但至少此次換組我仍然可以實現本身的價值。即食組的工做氛圍仍是很活潑的，但行動力和執行力也很強，談笑風生中把任務作完，這是能力強的表現。
• 在一上午的接觸看來，在工做中，臨時隊長趙暢同窗比咱們的林燊大哥更隨和一些，也多是由於我是新來的組員。林燊組長在工做中更爲嚴肅，把工做和生活分的很開，氣場很強，工做效率也很高。兩組各有優劣，從此要更加努力，在林燊和宏巖的帶領下實現一個又一個「穩」。

俞辛

• 其實作爲臨時隊長，個人感覺沒有太多的不一樣。我認爲這是由於從一開始我就對團隊很上心，每次團隊做業參與度都很高。因此很天然而然的就接過了臨時隊長的任務。
• 至於新換來的同窗，執行力都很強，並且會主動承擔任務。印象最深的就是源，在做業發佈以後就聯繫了咱們，和咱們一塊兒對做業的一些細節進行了討論，因此在貢獻度的分配上他也獲得了最高分。
• 由於此次有了新的隊員，隊內的幾個開心果此次也都沒能到場，因此一開始團隊氛圍顯得很沉悶。後來通過我和宏巖的一些鬥嘴，氣氛慢慢活躍了起來，你們之間得溝通交流也多了起來，效率一下就上去了。因此說不論從我的體驗仍是從對團隊的貢獻而言，維護一個好的團隊氛圍仍是頗有必要的，這也算是隊長的一個責任吧。
• 滿分10分，給本身此次的臨時隊長打個9分，小小自戀一下:-）惟一不足的就是沒能讓遠在青島的三個小朋友一塊兒參與進來。

愷翔

• 因爲本次外出時，雖然咱們在線上製做了不少類圖，可是因爲所在會場的網絡環境很差，致使我沒法及時上傳類圖，與軟工小夥伴們同「肝」共苦，內心十份內疚，因而我和鈞昊決定完成剩餘文檔的所有制做，來彌補小夥伴們的損失和他們的精神損失。並且據說今天來了一個換組遊戲，我以爲此次沒有參與進去感到十分惋惜，若是有下次的話，但願可以體驗一下。
• 我在課後也盡力承擔下課後的任務，而且添加上咱們繪製的UML圖，以及框架圖。下次做業咱們也會盡力承擔更多的任務的。

鈞昊

• 本次因爲早上同燊、愷翔兩人比賽答辯，且因爲會場的網絡條件限制，作好的UML類圖沒法發給團隊的其餘同窗，只能經過提出一下修改意見的方式來完成UML設計的實現。其實我是很期待可以體驗一下在陌生的團隊中共同完成設計開發。但是礙於時間衝突，沒有辦法很好完成。
• 期待下一次可以再有這樣有趣的的點子來活躍軟工團隊的氣氛，這裏我也想提供一個可能比較有趣的點子： 在答辯環節交換成員，懟本身組的場景簡直不要要有趣。