OO課程學期末總結
OO課程學期末總結
測試VS正確性論證
OCL vs JSF
對象約束語言(Object Constraint Language)， 簡稱OCL， 是一種指示用戶建模系統中的限制方式。 他是UML可選的附加內容， 可以用來更好地定義對象的行為， 並為任何類元指定約束。
- 相似性：
- 形式化語言：基礎都是集合論和謂詞邏輯。是選擇有歧義的但是多數人能看懂的自然語言，還是無歧義但少數人才能看懂的數學符號，OCL和JSF選擇了“中庸之道”。（不過JSF的形式化沒有OCL那麽強）【PS:數學、邏輯和計算機科學中，形式語言(英語:Formal language)是用精確的數學或機器可處理的公式定義的語言】
- 聲明式語言：就是描述了應該做出什麽結果，而不是應該怎樣做才能達到某個結果，給出了結果而非具體過程。
-
描述的約束相似：OCL可以描述4種約束：不變量、前置條件、後置條件、監護條件。JSF類似。
- 不同之處：
- 類型化語言：OCL中的每一個表達式都是具有類型的。這些類型包括：標準類型、UML圖中的元素、上述元素的集合。
- 表達能力：OCL表達能力更強、也更嚴謹。
- OCL是和UML（統一建模語言）綁定的，JSF是直接面向代碼。
第14次作業單電梯系統UML圖
類圖（greenuml自動生成）：
時序圖（plantuml代碼生成）：
狀態圖（不知為啥plantuml用不了，我就畫圖軟件手畫了，狀態轉移比較簡單）：
【PS：這裏的STILL是廣義靜止，包括 到達某請求目標樓層而導致的靜止（可能馬上又要移動），及，沒有請求而導致的電梯空閑靜止】
整理總結一個學期所學所練
關於四個單元模塊
- 知識點循序漸進，從基礎思想到設計原則，抽象層次越來越高，從代碼完成到測試和驗證，一步步完整實現工程開發。
- 老師並沒有講語法，畢竟大家都有其它語言的基礎，因此語法方面全靠大家自學。
- OO開課前，由於我既沒選大一下的java課，也沒選暑期java先修課，心裏有點虛，於是暑假用兩周時間，看了中國大學MOOC浙大翁愷老師開設的：《面向對象程序設計——Java語言》，翁老師講得真心好，特別是結合了實例，讓我對面向對象的基本思想有了比較深入的了解，為本學期的OO課奠定了很好的基礎，在這裏種草一下。
梳理歷次作業的收獲和進步
闡述自己對工程化開發的理解
- 百度了下軟件工程的開發過程：需求分析、設計（總體）、實現（細節）、測試、驗收、維護。
- 工程化的一套流程，使得開發一個復雜易變的大工程這事兒 更加流程明確和高效，真是妙啊。
- 不過OO課只是給我們打開了軟件工程的一扇小窗，讓我們在一輪又一輪作業中強化體會前四個環節。特別是設計和實現分離，設計好了，實現也就是解決一些小細節而已，要是沒設計好就急忙動手，那必然是內心空虛的蝸牛式前進。
- 順帶一提，每次作業都要靜下心來認真分析指導書的需求，以後每次做一些很長很復雜的題、或者遇到復雜的實際情況時，就會告訴自己“指導書你都看過那麽多了，還對付不了這個嗎！”，以增加自己的耐心和自信心，這一點可以說是OO課給我的最大收獲了【沒事多逼逼自己，如果決定要翻過這面墻，就先把電腦丟過去】
對課程的期望或建議
- 一個不良現象：由於客服群分散為3、4個，因此可能會出現各客服群對同一問題的回答不統一的問題，進而出現 誤導學生直至提交作業後在互測時才發現回答不統一，或，誤導學生且在未提交作業前突然發現口徑不一然後天降需求。這不是學生或助教的錯，而是這個問答機制不大完善。用客服助教來模擬用戶，結果卻發現用戶使用了分身術提出不同的需求，這顯然不是課程組希望看到的。
- 針對上述不良現象的幾個可能的解決方法：
-
客服群之外再建一個群 專門發通知 不允許發問，但是這就需要每個小客服群在回答每個問題之後就發通知，助教除了要回答問題，還要把問題描述清楚（當然截圖也海星）之後發通知，還要註意有沒有其他助教已經發過這個問題的通知。助教比較累。
-
建一個大群，舍棄小群，不允許水群比如發表情包和其它與OO無關的東西。要求提問和解答的內容都盡量控制在一段話內，不要分開發多條消息，想清楚了理好邏輯了再問/再答，每個時間段固定由某位助教回答，重復提問者給予黃牌警告（大家共同監控）。這樣能減少水群信息，方便你我他。不過對於提問者和問答者的要求較高，大家不一定能做到，不易實施。
-
大就大到極端，舍棄群聊，只保留討論區，這樣會減少很多提問的次數，因為大家似乎不大願意在討論區發問，進而，按照大家“不提問就不會改需求”的邏輯，改需求這事兒就會變少，順便要求ddl前一天不允許提問好了，以免天降需求呵呵。
-
小就小到極端，分成7、8個小群（絕對不能按小班分），保證群內人員互測。對於關鍵問題的回答，由助教保證與其它助教的回答統一，不關鍵問題的回答，助教自由發揮，互測時以助教回答為準，該助教負責這個小群內的同學的仲裁工作。但是，或許容易發生私下交易，而且如果指導書的部分需求很不明確時，同學們會大量發問，而且和其它群的同學的問題相似，助教工作較多。
【哇，設計好一門課真是不容易】
- 然後就是互測的問題了，建議在互測仲裁中加入扣分機制。即，仲裁結果分為：
-
確有其事，報告bug/imcomplete成功，測試者得到測試的加分。
- 雙方觀點都挺有道理，報告bug/imcomplete成功/失敗/和棋。
- 測試者惡意測試，報告bug/imcomplete失敗，測試者扣分。
- 最後，希望這門課能越辦越好，達到課程組真正的教學目標，同時也得到學生們的認可：
——“這門課雖然虐人，但是學到了好多好東西，被虐得挺值的嘿嘿嘿”。
OO課程學期末總結