1. 程式人生 > >OO課程學期末總結

OO課程學期末總結

plan 對象 綁定 報告 做到 集合論 了解 公式 失敗

OO課程學期末總結

測試VS正確性論證

技術分享圖片

OCL vs JSF

對象約束語言(Object Constraint Language), 簡稱OCL, 是一種指示用戶建模系統中的限制方式。 他是UML可選的附加內容, 可以用來更好地定義對象的行為, 並為任何類元指定約束。

  • 相似性:
  1. 形式化語言:基礎都是集合論和謂詞邏輯。是選擇有歧義的但是多數人能看懂的自然語言,還是無歧義但少數人才能看懂的數學符號,OCL和JSF選擇了“中庸之道”。(不過JSF的形式化沒有OCL那麽強)【PS:數學、邏輯和計算機科學中,形式語言(英語:Formal language)是用精確的數學或機器可處理的公式定義的語言】
  2. 聲明式語言:就是描述了應該做出什麽結果,而不是應該怎樣做才能達到某個結果,給出了結果而非具體過程。
  3. 描述的約束相似:OCL可以描述4種約束:不變量、前置條件、後置條件、監護條件。JSF類似。

  • 不同之處:
  1. 類型化語言:OCL中的每一個表達式都是具有類型的。這些類型包括:標準類型、UML圖中的元素、上述元素的集合。
  2. 表達能力:OCL表達能力更強、也更嚴謹。
  3. OCL是和UML(統一建模語言)綁定的,JSF是直接面向代碼。

第14次作業單電梯系統UML圖

類圖(greenuml自動生成):

技術分享圖片

時序圖(plantuml代碼生成):

技術分享圖片

狀態圖(不知為啥plantuml用不了,我就畫圖軟件手畫了,狀態轉移比較簡單):

技術分享圖片

【PS:這裏的STILL是廣義靜止,包括 到達某請求目標樓層而導致的靜止(可能馬上又要移動),及,沒有請求而導致的電梯空閑靜止】

整理總結一個學期所學所練

關於四個單元模塊

技術分享圖片

  • 知識點循序漸進,從基礎思想到設計原則,抽象層次越來越高,從代碼完成到測試和驗證,一步步完整實現工程開發。
  • 老師並沒有講語法,畢竟大家都有其它語言的基礎,因此語法方面全靠大家自學。
  • OO開課前,由於我既沒選大一下的java課,也沒選暑期java先修課,心裏有點虛,於是暑假用兩周時間,看了中國大學MOOC浙大翁愷老師開設的:《面向對象程序設計——Java語言》,翁老師講得真心好,特別是結合了實例,讓我對面向對象的基本思想有了比較深入的了解,為本學期的OO課奠定了很好的基礎,在這裏種草一下。

梳理歷次作業的收獲和進步

技術分享圖片

闡述自己對工程化開發的理解

  • 百度了下軟件工程的開發過程:需求分析、設計(總體)、實現(細節)、測試、驗收、維護。
  • 工程化的一套流程,使得開發一個復雜易變的大工程這事兒 更加流程明確和高效,真是妙啊。
  • 不過OO課只是給我們打開了軟件工程的一扇小窗,讓我們在一輪又一輪作業中強化體會前四個環節。特別是設計和實現分離,設計好了,實現也就是解決一些小細節而已,要是沒設計好就急忙動手,那必然是內心空虛的蝸牛式前進。
  • 順帶一提,每次作業都要靜下心來認真分析指導書的需求,以後每次做一些很長很復雜的題、或者遇到復雜的實際情況時,就會告訴自己“指導書你都看過那麽多了,還對付不了這個嗎!”,以增加自己的耐心和自信心,這一點可以說是OO課給我的最大收獲了【沒事多逼逼自己,如果決定要翻過這面墻,就先把電腦丟過去】

對課程的期望或建議

  • 一個不良現象:由於客服群分散為3、4個,因此可能會出現各客服群對同一問題的回答不統一的問題,進而出現 誤導學生直至提交作業後在互測時才發現回答不統一,或,誤導學生且在未提交作業前突然發現口徑不一然後天降需求。這不是學生或助教的錯,而是這個問答機制不大完善。用客服助教來模擬用戶,結果卻發現用戶使用了分身術提出不同的需求,這顯然不是課程組希望看到的。
  • 針對上述不良現象的幾個可能的解決方法:
  1. 客服群之外再建一個群 專門發通知 不允許發問,但是這就需要每個小客服群在回答每個問題之後就發通知,助教除了要回答問題,還要把問題描述清楚(當然截圖也海星)之後發通知,還要註意有沒有其他助教已經發過這個問題的通知。助教比較累。

  2. 建一個大群,舍棄小群,不允許水群比如發表情包和其它與OO無關的東西。要求提問和解答的內容都盡量控制在一段話內,不要分開發多條消息,想清楚了理好邏輯了再問/再答,每個時間段固定由某位助教回答,重復提問者給予黃牌警告(大家共同監控)。這樣能減少水群信息,方便你我他。不過對於提問者和問答者的要求較高,大家不一定能做到,不易實施。

  3. 大就大到極端,舍棄群聊,只保留討論區,這樣會減少很多提問的次數,因為大家似乎不大願意在討論區發問,進而,按照大家“不提問就不會改需求”的邏輯,改需求這事兒就會變少,順便要求ddl前一天不允許提問好了,以免天降需求呵呵。

  4. 小就小到極端,分成7、8個小群(絕對不能按小班分),保證群內人員互測。對於關鍵問題的回答,由助教保證與其它助教的回答統一,不關鍵問題的回答,助教自由發揮,互測時以助教回答為準,該助教負責這個小群內的同學的仲裁工作。但是,或許容易發生私下交易,而且如果指導書的部分需求很不明確時,同學們會大量發問,而且和其它群的同學的問題相似,助教工作較多。

【哇,設計好一門課真是不容易】

  • 然後就是互測的問題了,建議在互測仲裁中加入扣分機制。即,仲裁結果分為:
  1. 確有其事,報告bug/imcomplete成功,測試者得到測試的加分。

  2. 雙方觀點都挺有道理,報告bug/imcomplete成功/失敗/和棋。
  3. 測試者惡意測試,報告bug/imcomplete失敗,測試者扣分。
  • 最後,希望這門課能越辦越好,達到課程組真正的教學目標,同時也得到學生們的認可:

  ——“這門課雖然虐人,但是學到了好多好東西,被虐得挺值的嘿嘿嘿”。

OO課程學期末總結