面向對象程式設計第四單元總結

目錄

• 面向對象程式設計第四單元總結
  • UML
    • 類圖
      • 類
      • 接口
      • 六大關系
        • 繼承關系（Generalization）
        • 實作關系（Implementation）
        • 關聯關系（Association）
        • 聚合關系（Aggregation）
        • 組合關系（Composition）
        • 依賴關系（Dependence）
    • 順序圖
      • 協同
      • 參與者（participant）
        • 生命線
        • 終點
      • 消息(Message)
      • 六種消息類型
        • 同步消息
        • 異步消息
        • 傳回消息
        • 建立消息
        • 删除消息
        • 丢失消息
        • 找回消息
    • 狀态圖
      • 狀态機(State Machine)
      • 區域 (Region)
      • 狀态 (State)
        • 起始狀态（UmlPseudostate)
        • 普通狀态（UmlState)
        • 終止狀态（UmlFinalState)
      • 轉移 (Transition)
        • 事件 (Event)
        • 警戒 (Guard)
  • 架構設計
    • 作業分析
  • 四個單元中架構設計及OO方法了解的演進
    • 第一單元
    • 第二單元
    • 第三單元
    • 第四單元
  • 四個單元中測試了解與實踐的演進
    • 第一單元測試
    • 第二單元測試
    • 第三單元測試
    • 第四單元測試
  • 課程收獲
  • 改進建議

第四單元學習的内容是UML (Unified Modeling Language)

主要學習了三種圖：類圖(class diagram)， 順序圖(sequence diagram)， 狀态圖(state machine diagram)

類圖分三層，第一層顯示類的名稱，如果是抽象類，則就用斜體顯示。第二層是類的特性，通常就是字段和屬性。第三層是類的操作，通常是方法或行為。注意前面的符号，‘+' 表示public, '-' 表示private,“#' 表示protected.”

與類類似， 在staruml中用圓圈表示

也稱泛化關系

可以簡單了解為繼承， 在uml中用空心三角箭頭表示

java中類不可以多繼承

類實作接口的關系， 在uml中用虛線加空心三角表示， 在staruml中就是一根直線(也叫做interface realization)

一個類可以實作多個接口

類與類之間的聯系：關聯的本質是一個類需要另一個類來管理資料或者請求服務

關聯關系是一種擁有的關系，它使一個類知道另一個類的屬性和方法

在staruml中是一根直線， 一般是一根實線箭頭(單向)

聚合關系表示的是整體和部分的關系

整體由部分組成，而整體和部分又可以分開， 在staruml中用空心菱形和實作表示

整體與部分的關系，但是整體與部分不可以分開， 一般用實心菱形加實線表示

隻要是在類中用到了對方，那麼它們之間就存在依賴關系。如：類的成員屬性， 方法的傳回類型， 方法接受的參數等。

staruml中用虛線箭頭表示

UmlInteraction用于表示對象的互動

參與者描述本次互動的發起者， 在作業中主要用到的包括兩類

UmlLifeline， 生命線用于描述對象的生存周期， 在uml中一般用方塊加一條虛線表示

UmlEndpoint，顧名思義就是結束點， 一般用實心原點表示

UmlMessage， 對象之間通過發送消息來進行互動， 不同的消息在staruml中的表示方法也不一樣

沒有重點考察，隻是大緻了解

(sync message) 或者 (self message)

一般就用實線箭頭表示。 一個對象向另一個對象發出同步消息後，将處于阻塞狀态，一直等到另一個對象的回應。

一個對象向另一個對象發出同步消息後，将處于阻塞狀态，一直等到另一個對象的回應

一般用普通箭頭表示

傳回消息用虛線箭頭表示

注意生命線的變化

消息指向一個黑點

從一個黑點指出消息

主要用到的幾個概念

狀态圖最頂端的部分， 狀态機整體

狀态機下面的子部分， 用畫布的概念了解

引用吳際老師原話

不直接在StateMachine下直接加狀态的原因：StateMachine 中除了state之外還可以增加其他的内容，在staruml中可以發現還可以加constraint和tag。 這樣在StateMachine和State之間加入Region可以有更好的層次。

區域下面的概念， 正真表示狀态機内的狀态

個人感覺pseudostate和初始狀态Initial State還是有一點差別， 但是在作業中就當起始狀态用了

結束狀态

或者說狀态轉換：兩個狀态之間的關系，它表明當某事發生時，對象先從目前狀态轉換到後來的狀态，用帶有标記事件的箭頭表示。

表示狀态轉移的發生條件

判定是否狀态轉移發生的條件

前兩次作業都是輸入一系列的UmlElement然後對這些UmlElement 進行解析， 将其分成不同的類

第一次作業類圖：

将UmlElement解析為Class, Interface, Attribute, Operation, Parameter, Association, Generalization, InterfaceRealization.

第二次作業順序圖和狀态圖

将UmlElement解析為 StateMachine, Region, State Transition, Event, Interaction, LifeLine, Message

由于這些元素之間都是有關聯的， 是以我們需要知道每一個UmlElement的parent是什麼，

• 對于類圖

UmlElement	parent
class	-
interface
attribute
operation	class / interface
parameter

類圖還有三類特殊的UmlElement

表示類圖元素的關系

• association

  end1 和 end2分别表示關聯的兩個端點

• generalization

  繼承有source 和 target

• interface realization

  接口的實作， 同樣有source和target

如此可以用圖的思想建立類圖

主要有兩類結點：class 和 interface

class類包含的屬性有attribute 和 operation

interface包含的屬性有operation

operation又有自己的parameter

節點之間的關系可以表示成有向圖的形式：

association就是雙向的有向圖， 相當于無向圖

而generalization和interface realization 就是正真的有向圖， 表示的是從source到target的一條邊

• 對于順序圖

順序圖需要解析的元素隻有lifeline, interaction, 和message

interaction
lifeline
message

我們隻需要建立一個特殊的interaction包含lifeline和message就能表示順序圖中的元素

• 對于狀态圖

狀态圖需要解析的元素有statemachine, region, state, transition, event

statemachine
region
state
transition
event

statemachine之下的唯一兒子就是region

是以我選擇用region存所有的狀态而不是用statemachine

中間利用了一個statemachine的hashmap将statemachine和region之間的關系記錄下來

這個特殊的region中包含了state和transition

transition又包含了自己的event記錄

總體上就是将類圖表示成一個圖， 将順序圖和狀态圖分别表示成另外的兩個圖， 通過利用資料建立圖的概念來對圖中的元素和屬性進行查詢。

第一單元涉及到了表達式的求導， 主要用到的架構就是對表達式進行正規表達式解析，之後将表達式分成表達式， 項， 因子等， 利用遞歸的思想對表達式進行求導。

第二單元的電梯， 主要運用了多線程的概念， 架構主要是對排程器的架構。 主要運用了兩層排程器， 第一層排程器對所有對電梯送出請求的人進行分類排程， 将所有的人放入第一層緩存區， 第二次排程是将緩存區的人放入不同的電梯序列， 然後通過電梯線程對不同的人進行分别的運載。

第三單元幾乎不涉及到架構， 因為都是按照給好的規格直接寫函數， 談不上架構

架構如上所述

第一單元測試應該是四次作業中測試做的最好的。 應為是正真能夠測試的單元， 在第三次作業中首先對表達式序列進行了正規表達式比對， 不對直接Wrong Fromat， 之後由于強大的python庫， 我們可以對表達式進行求導， 并且利用python庫進行表達式求導， 并且對比結果輸出， 隻要結果輸出不對直接WA。

此外做測試還可以直接進行表達式計算， 對表達式帶入值進行計算， 然後比較帶入值後的表達式的結果。

此外測試還可以通過構造特殊樣例進行驗證， 随機化測試可以覆寫大量的點， 但是對于其中一些特殊的點， 可能覆寫到的幾率非常的低，是以我們需要進行手動構造樣例來進行驗證。這樣幾乎可以将所有的情況涵蓋， 隻要構造的樣例足夠強的話。

第二單元的測試依舊沿用第一單元的思路， 主要利用自動化測試讓程式自己跑，這個一般能夠測試出很多的bug， 當自動化測試已經不能很好的測bug的時候就需要手動構造樣例。

實際的時候就遇到了在自動測試下長時間都沒有出鍋， 但是被構造的兩行樣例hack。

第二單元測試的最大困難就是多線程的不确定性。

主要表現在測試死鎖的時候， 很多時候雖然你能将對方的bug找出來， 但是多線程具有不确定性， 是以你并不能保證百分百複現， 這樣的bug不能用于hack， 但是你又能确定對方存在死鎖的風險。在這個方面完全沒有辦法解決。

• 首先在oo實驗的過程中java語言的了解有着質的提升，雖然上學期上過半學期的java課， 但由于實踐太少， java的很多概念不是很熟悉， 對于正規表達式等知識點更是一竅不通。
• oo課程主要學到的還是面向對象的相關知識， 了解了工廠模式， 封裝， 繼承，多态等内容。 此外對java中類， 接口等概念有了深入的了解， 對深拷貝， 淺拷貝等知識有了一定的了解。 對java中的異常類及異常處理有了更深入的了解。
• oo課程主要給我帶來的還是思想上的改變， 表達式求導的第一次作業我仍舊帶着面向過程的思想來完成作業。而越到後面， 思維逐漸面向對象， 在電梯的排程上盡可能少的使用面向過程的方法， 而使用面向對象的方法。但是仍舊存在一個問題就是如何在盡可能面向過程的方向上提升性能， 是以在電梯單元很多與性能相關的地方仍舊使用了面向過程的實作。在未來這是一個可以努力的方向。

• 建議合并jml和uml， 這兩個單元知識都很概念化， 在實作上并沒有達到前兩個單元的難度， 單獨開兩個單元的意義不是很大。 而且後兩個單元和前兩個單元的落差确實很大。
• 互測的限制比較嚴格， 互測很多時候不能将bug找出來， 建議将互測資料範圍改成和強測一樣。
• 指導書說明不是很清楚， 特别是第四單元最後一次作業， 了解指導書花費了大量的時間。建議完善指導書的表述，加強語言的嚴謹性，清楚的傳達内容。