該題目是並非取自於多媒體圖書系統，而是來自於自己做過的的一個博客項目，對其進行了詳細的分析與設計過程。具體兩個過程如下：
一、系統分析
1.1、可行性分析
可行性研究報告的目的是確定該系統能否實現，會遇到那些問題，能否解決以及后續發展等問題。發現明確設計項目所要面臨的問題和方法以及如何解決是可行性分析的目標所在。
本課題設計主要是參考網上主流的博客樣式和功能，來模擬實現一個可以在Web端和移動端進行的輕博客的相關功能操作，兩個模塊訪問同一個服務器。Web端的主要功能包括用戶Login，Register，Blog查看，Blog發表，Blog搜索，Blog類別管理，Blog留言，留言管理，個人信息設置等；移動端部分的功能與之大致相同，沒有留言管理。同一個服務器向兩個平台端提供數據請求接口。該系統的相關功能符合市場上的Web端和移動端的博客系統的基本要求，服務端使用Springboot內嵌的Tomcat進行本地實現，保證服務端的高效穩定，Bootstrap被使用於Web前端，保證用戶體驗以及編碼質量，移動端使用用戶廣泛Android平台，版本要求Android6.0，保證一定市場。所使用的相關技術和框架都是比較流行而且穩定，從而保證系統的可行性和穩定性。
1.2、系統需求分析
在軟件開發和維護周期中，需求分析是會一直影響整個課題開發過程的一個階段。在整個軟件開發生命周期中需求分析的重要性可由數據體現，這些失敗的項目高達七成，大約六成的失敗的原因是需求階段問題。事實上，需求階段問題使得一半以上的Developer遇到麻煩，這種重要卻基礎的問題越來越受Developer重視。需求分析階段的主要任務獲取並且明確用戶提出的Demand，以通俗化的交流方式來實現明確模糊的需求，開發者最終形成對需求的完整，明確和的描述，產生需求規格說明書等。
在確定要執行的操作和要實現的功能，然后從上到下分解功能，逐步細化它們，將它們抽象為更小的功能，然后逐步實現它們。在此階段，作為過程和結果還需要創建用例圖和需求規格說明書。
確定課題目標后，以自己熟悉的Web開發和Android開發為基礎，分別在Web端和Android移動端實現輕博客系統，兩端的功能相似，但Web端界面更加美觀，功能更加豐富，Web端博客的相關功能模塊如下說明。
（1）博客瀏覽以及留言：該功能部分主要是給沒有登陸的游客進行博客的瀏覽以及評論，除此之外，用戶查看自己的博客也會調轉到其中的相關博客頁面。
（2）用戶登陸以及注冊：用戶根據自己注冊過的賬戶以及密碼進行Login，經過Server查詢后，返回Success數據跳轉進入博客管理用戶界面。
（3）博客管理：該部分主要以表格的形式展示出當前用戶的所有的博客的標題，類別，日期，點擊數，狀態等信息，可以對所有博客進行刪改。
（4）博客發表：需要填寫的部分包括博客標題，博客類以及博客正文，其中博客正文是Markdown中編輯，博客編輯結束后選擇保存為草稿狀態或者直接發表。
（5）留言管理：將游客的留言以表格的形式展示出來，包括留言內容，留言人，瀏覽時間，刪除操作等。
（6）類別管理：展示出當前所有的類別，並且可以添加新的類別以便發表博文時選擇，同時也支持刪除。
（7）用戶設置：該部分主要可以查看設置用戶的Email和手機號，並且也可以進行密碼的修改。
根據功能的相關需求分析，我們可以畫出Web端的用例圖，實現相關用戶以及用例的關系的可視化，作為以后的系統分析和兩個平台端代碼實現的前提基礎，如圖1.1所示。
圖1.1 Web端博客部分用例圖
Andriod端的功能與Web相似，區別在於Android端缺少留言管理，添加分享功能。相關用例圖如圖1.2所示。
圖1.2 Android端博客部分用例圖
1.3、系統性能分析
性能測試的目的是預計當前系統的性能要求，從而分析解決性能問題，避免不必要的風險。本系統移動端系統采用Android 6.0，開發采用API 23版本SDK，Java使用Jdk1.8，Tomcat的版本為8.0。服務器端支持高並發，但在訪問量達到一定程度時，響應速度會變慢。在一定的並發數量系統正常運行並響應用戶的請求操作，Android客戶端和Web端可以正常獲取服務器的信息並且進行相應的顯示。
操作系統：Windows 7操作系統。
應用服務器：Tomcat8.0以上。系統數據庫服務器是MYSQL，數據庫操作可視化工具采用Navicat Premium 12。
瀏覽器：谷歌瀏覽器（Web端訪問操作）
智能手機：Android6.0操作系統，SDK 23。物理內存為2G以上，手機內存4G以上，能正常開啟數據流量和連接到移動互聯網。
二、系統設計
2.1 系統概要設計
考慮相關功能的具體實現設計和每個模塊之間的交互等具體問題的解決，這是在系統分析階段的主要任務。系統分析結束后就要開始進行系統設計而這一步又是建立在系統分析的結果上，需求分析的目標是解決What的問題，相應的，系統設計的目的則是解決How的問題。
在概要（結構）設計階段，按照一定的原則把把軟件分解為多個模塊層次，每個模塊都會被指定一定的任務，並且模塊間調用關系和接口也進行確定。
在這個階段，主要考慮划分模塊層次、分配功能、確定調用關系等，也需要支持模塊的內部實現。在這個階段，模塊間的接口與傳參過程要清楚，為了以防后續設計產生不必要的問題，需要標注准確的數據字典。功能重復的模塊需要被合並，然后分解出可以復用的模塊常常是典型的調整。在該階段，可以重用的代碼或者邏輯模塊應被盡可能標記精練出，同時設計實現符合面向對象原則的系統結構，來提高系統性能，減少系統實現的代碼量，數據流圖、詳細的數據字典以及每個部分的文本介紹等是概要設計文檔的關鍵部分。
數據流圖主要是以數據流向作為驅動來描述整個系統運行流程。該圖是基於用例圖，在用例圖的基礎上對其中相關功能部分關系的僅需一步細化。當用戶在瀏覽器之上打開本地服務器地址后會進入所有的博客瀏覽界面，無論是用戶還是游客，進入該網址后都可以進行博客瀏覽和相應博客的留言。當需要進一步發表博客或者進行博客、留言分類等的管理時，需要用戶進行Login或者非用戶Register。Login時提交賬號和密碼后，請求服務器進行頁面跳轉，服務器收到登陸請求和數據后，搜索數據庫，Select查詢成功后返回成功消息，並且跳轉到用戶的博客主界面。首頁是對數據庫相關數據的統計，包括博客，留言，日志等相關數據的統計，可以選擇進行博客管理，留言管理，分類管理，個人設置等。進入博客管理后，請求服務器以列表的形式展示出所有博客的相關信息，可以進行修改和刪除，同時也可以進入發表博客界面，需要填寫博客標題，類別，博客正文是以Markdown編輯器進行編寫。博客寫完后，可以選擇保存為草稿或者直接發表，點擊按鈕后，請求服務器進行數據庫的添加，服務器操作數據庫成功后返回成功信息，再次進入博客管理界面時，新的博客信息也會被顯示出。進入留言界面時，向服務器請求留言數據，服務器進行數據庫的Select並返回數據，當然也可以對每一條留言進行刪除操作。
對於每一個Blog，都有相應的類別，還可以進行Classification management，請求Server進行類別的增刪改查，最后就是個人設置，包括密碼，郵箱，手機等信息的修改，Web端的數據流具體如圖。
圖2.1 Web端的數據流圖
Android端的數據流動與Web端的最大區別在於數據的交互方式和通道。移動端的登陸、注冊涉及MySQL數據庫操作，所以需要通過HTTP協議向Server發送請求來實現數據驗證，服務器接收請求並處理成功后，返回Json數據給客戶端，客戶端收到返回結果后，進行格式轉化並判斷后再進行相應的操作，類別管理等模塊的相關請求過程與之相似。但是由於博客正文是在Markdown中撰寫，難以進行格式，文字，圖片的處理，所有在Android系統中使用加載網頁的方式來展示和發表博客。具體的數據流圖如圖2.2所示。
圖2.2 Android端的數據流圖
2.2 系統詳細設計
在具體設計階段，需要詳細准備進行各個模塊的實現。在這個階段，關注與每個模塊，以概要設計的數據流和功能任務為依據，將模塊的算法實現、關系轉換、內部流程等內容用UML和文字說明表示出。根據概要設計文檔，再進一步進行各個模塊的詳細設計。其中，如果需要進行結構修改的時候，需要從上一個階段再開始，調整概要設計文檔的部分內容，而不能直接解決，系統模塊的流程圖、類圖，時序圖等是具體設計文檔重要的UML部分。
類圖是一種顯示系統中Entity的屬性行為以及Entity之間關系的一種的Static model。在項目中主要體現為Java bean實體類，作為控制層和數據處理類的基礎類。具體如圖2.3所示。
圖2.3 系統后台類圖
項目主要包括用戶類，博客類，類別類，評論類，操作日志類和圖片文件類。用戶類主要用於用戶基本信息的操作，包括用戶登陸，注冊，信息修改時會調用該類，並且博客類還有一個圖片類與之一一對應來表示用戶頭像。博客類是其中最主要的一個類，博客的增刪改查都會調用該類，並且博客類中還有用戶Id的屬性用於連接博客溫和用戶。博客類中還有類別屬性，該屬性也會獨立出成一個類別類，涉及類別的增刪改查。除此之外，還有一個留言類，該類連接了用戶類和博客類，並且用戶和評論之間是N對M，博客和評論之間是1對N。
類圖只能靜態顯示基本實體模型以及它們之間的關系，無法顯示每個功能的請求時序，所以我們需要對相關功能進行順序圖的描述。
序列圖是一種展示功能模塊之間傳遞Message的過程的交互圖，用戶登陸功能的順序圖如圖2.4所示。
圖2.4 用戶登陸順序圖
用戶登陸成功后進行博文發表時的順序圖如圖4.5所示。當然博文的其他操作以及其他設計服務器的操作也都與之過程相似。
圖2.5 發表文章順序圖
2.3 數據庫設計
數據庫的設計對系統完成和可維護性非常重要，數據庫設計決定了未來是否能夠很好地維護數據，以后的需求是否得到很好的開發，還能確定系統性能。不恰當的數據庫的關鍵功能更改可能導致對多個表的修改甚至重建，錯誤可能導致數據庫數據不一致。解決這些問題。在數據庫設計開始時，您需要考慮這些問題，減少冗余，提高Reuseablity，並減少未來的系統維護量。
數據庫設計通常分為多個階段，包括分析，設計（包括概要，邏輯和物理），數據庫建立、測試和維護，數據庫概念設計和邏輯設計是其中的主要部分。
概念設計主要是分析出相關的實體中的屬性以及實體之間的關系，並畫出E-R圖來進行表示，E-R圖可以體現出映射項目中相應類的數據庫實體、每個的屬性和他們之間聯系。在基本滿足數據庫的三大范式表設計后，還要向更高層次的范式擴展，從而降低后台操作數據庫產生的冗余，避免非主屬性對碼的部分和傳遞Rely等。博客后台數據庫的E-R圖具體如圖2.6所示。
圖2.6 數據庫E-R圖
在數據庫中每一個實體就是一個表，與項目中的Java bean相對應，根據上面的實體聯系圖，我們可以將其轉化為關系模型，其中涉及每個表中屬性確立，主鍵確立，外鍵確立以及高層次范式確立，從而提高高數據庫的操作效率，減少冗余。關系模型的轉換后開始進行數據庫物理設計方面，即在可視化的數據庫管理系統Navicat中建表。一共有7個表，包括用戶表來存儲用戶信息，博文表來存儲所有博文的相關數據，頭像文件表來存儲與用戶一一對應的用戶頭像，類型表用於存儲系統中的博文可以有的所有類型，留言表由於存儲所有的博客的所有留言，操作日志表則是用來存儲最近的用戶操作（包括登陸，博客處理，類型處理和個人設置）。
以上是一個大致的博客系統的分析與設計過程，考慮到了系統的基本需求功能、工作過程，數據庫等，但還有設計過程不夠全面，功能較少等缺點需要繼續改進。