***系統架構設計說明書
2013-12-12 v0.1
修訂歷史記錄
系統構架文件的簡介應提供整個系統構架文件的概述。它應包括此系統構架文件的目的、範圍、定義、首字母縮寫詞、縮略語、參考資料和概述
本文件將從構架方面對系統進行綜合概述，其中會使用多種不同的構架檢視來描述系統的各個方面。它用於記錄並表述已對系統的構架方面做出的重要決策,以便於開發人員高效的開發和快速修改和管理。
本文件用於oto專案組目前正在開發的android app電器管家2.0和已經發布的1.0的開發或修改
參考系統需求文件電器管家app2.020140214
1、 系統需求文件電器管家app2.020140214
2、 品牌品類及對映建議app資料結構及資料樣例
在此簡單介紹系統架構的整體情況，包括用例檢視、邏輯檢視、程序檢視、實施檢視的簡單介紹。另外，簡要介紹各種檢視的作用和針對的使用者
本文件將通過以下一系列檢視來表示4in1系統的軟體架構：用例檢視、邏輯檢視、部署檢視。本文件不包括程序檢視和實施檢視。
這些檢視都是通過powerdesigner工具建立的uml模型。
系統架構在設計過程中有以下設計約束：
1、 安全性：通訊協議採用加密的方式、存放app端資料要進行混淆器加密、**號碼和logo不能通過反編譯批量拿走。
2、 響應速度：
3、 解析度適配原則
本章選擇了app2.0的部分功能用例,其他部分請參考系統需求文件電器管家app2.020140214
原型功能說明
通過輸入模糊查詢和右邊的首字母查詢、查詢出自己想要查詢品牌、然後撥打**進行報修。
原型功能描述
此功能主要主要描述了app2.0的建黨功能以及檔案詳情頁面的呈現
本節通過幾個精選的用例（場景）實現來闡述系統的實際工作方式，並解釋不同的設計模型元素如何促成其功能的實現
試圖資料展示於管理
使用者互動
繪製 adapter
持久化資料（記憶體中，相當於全域性資料）
資料加工（資料層的資料有時候需要進行交工成ui層需要的資料）
資料變化的通知機制
資料訪問（db，檔案，網路等）
快取（**，檔案等）
本系統主要採用的還是mvc的設計模式
1)檢視（view）檢視層能夠實現資料有目的的顯示（理論上，這不是必需的）。在檢視中一般沒有程式上的邏輯。為了實現檢視上的重新整理功能，檢視需要訪問它監視的資料模型（model），因此應該事先在被它監視的資料那裡註冊。
2) 控制器（controller） 控制器起到不同層面間的組織作用，用於控制應用程式的流程。它處理事件並作出響應。「事件」包括使用者的行為和資料模型上的改變。
3)模型層（model）：「資料模型」（model）用於封裝與應用程式的業務邏輯相關的資料以及對資料的處理方法。「模型」有對資料直接訪問的權力，例如對資料庫的訪問。
「模型」不依賴「檢視」和「控制器」，也就是說，模型不關心它會被如何顯示或是如何被操作。但是模型中資料的變化一般會通過一種重新整理機制被公布。為了實現這種機制，那些用於監視此模型的檢視必須事先在此模型上註冊，從而，檢視可以了解在資料模型上發生的改變。
暫無暫無
暫無見app2.0資料結構
根據專案的實際情況，此節可以省略不寫
參考系統需求文件電器管家app2.020140214
參考系統需求文件電器管家app2.020140214暫無
架構設計之執行架構
執行架構 技術選型 控制流劃分 同步關係 執行架構 如圖 1所示 關注程序 執行緒 中斷服務程式等執行時控制流，以及相關的併發 同步 通訊等問題。執行架構的設計 及其所依賴的物理架構設計 對執行期質量屬性有重大影響，例如效能 可伸縮性 持續可用性和安全性等。圖 1 執行架構的設計內容 執行架構和開發...
銷售管理系統軟體架構設計
一 系統功能模組 1.管理員資訊功能模組需求 可以新增新的使用者及密碼，也可以更改當前使用者密碼，並對不同的使用者設定不同的許可權。2.客戶資訊模組功能需求 可以新增新客戶的各種資訊，也可以進行刪除 修改和查詢 3.商品資訊模組功能需求 可以先進行大類，中類，小類的類別增刪查改，能夠新增新商品，最新...
XX專案系統架構設計方案
研發專案小組 文件歷史 這個表包含了這個文件的版本歷史。目錄1 引言 4 1.1 目的 4 1.2 範圍 4 1.3 假設和有待解決的問題 4 1.3.1 假設 4 1.3.2 存在的問題 4 1.4 定義和縮略語 4 1.5 引用檔案和參考資料 4 1.6 組織 角色和職責 4 1.6.1 組織人...