軟體系統架構有感

現在架構給了我一個很直觀的感受，那就是跟UML差不多。因為你架構就必須得把相應的靜態圖和動態圖繪製出來，而你能夠繪製出來就說明你對軟體的需求，邏輯架構等有了很充分的瞭解和準備。所以在做作業之前，我又把有關UML的教材看了一遍，而且把Thinking in UML的UML核心試圖那一章節也看了一遍。

架構給我的印象最深的一點是，通過架構，軟體可以推倒出來，而不是coding出來。這其實也是我們軟體工程師，而不是軟體編碼師，所應該著重學習的。在以前總不明白UML有什麼用，因為自己在繪圖的時候自搞一套，在程式設計的時候又換了一套。我把自己的這種錯誤的做法歸根為自己物件導向的思想運用的不夠完善。在繪圖的時候較多地考慮了物件導向，而有的時候在編碼的時候則過多的考慮了程式導向，而且在學習完資料庫設計的時候，在考慮邏輯功能的時候，總是想到關係型資料庫的設計問題，而資料庫的設計和麵向物件的設計根本不是一個路子的，因為兩種方法的核心出發點就不同。物件導向設計是為了將各個物件的功能按照類的方法分開，是為了強調各個模組在功能邏輯上的分工，而資料庫設計是為了資料的持久化，為了資料能夠高效的儲存和查詢。所以自己在以前犯的錯誤很多，把很多思路和方法混合在一起，所以總是做不出好的架構，因而總是感覺軟體的編寫總是那麼難。

首先說一下用例圖。其實用例圖就是需求嘛，關鍵是你得從哪些方面，哪些角度考慮這些需求，這其實就好比是軟體的包圖，你得分開描述，這樣才更容易理解。大象書上說，要從業務，業務實現，概念，系統，系統實現這五個角度進行用例的挖掘和繪製，然而這樣的角度對於我們的淘味兒網來說，要畫全簡直是太多了，而我考慮到有的用例大家都很熟悉，便沒有進行進一步的細化，所以我們的用例圖其實就是業務設計的用例圖。我是從這個角度，分成五個場景進行繪製的，因為我主要考慮了業務模組。主要有遊客，使用者中心，使用者互動，賣家管理，使用者通訊這五個角度。然後接下來的圖我也是通過用用例圖來驅動的方式繪製的。首先畫了序列圖，從以上四個場景中分別繪製了四個序列圖，然後又通過rose的轉換工具將序列圖轉換出了協作圖。然後我又繪製了活動圖，由於系統的功能比較複雜，所以我只繪製了使用者下單時的活動圖，因為這是系統最核心的功能。繪製完活動圖之後，又簡要的繪製了類圖，大象書上說類圖要從三個方面逐步深入的繪製，分別是概念層，說明層和實現層，實現層的繪製目前來說比較困難，因為我們的系統採用的是SSH的框架，而且我覺得應該更加註重資料庫的設計，必要的時候可以犧牲一下物件導向的設計，因為網站資料量會比較大，對資料的查詢和存取效能要求比較高，不能讓資料庫成為系統效能的瓶頸，而且採用了Hibernate的ORM框架，所以需要細細考慮一下資料庫。所以我暫時只是畫出了說明層的類圖。之後的會再詳細畫出來。

以上只是一些小小的感受，我覺得針對於怎麼想和想什麼這兩個角度，老師更應該強調怎麼想，在邏輯架構各個部分的建模過程中，強調一下建模的各個階段該怎麼做，這樣更容易使得我們放開思路。

由於昨天寢室停電，所以作業沒能及時給老師發過去，忘老師理解。

淘味兒網