l

2020年6月22日 星期一

UML Class Diagram小抄

June 22 10:12~10:38

▲小抄第一頁


明天要上第十梯次【敏捷開發懶人包:物件導向技能】課程。這門課主要是介紹物件導向觀念、SOLID原則、DBC,以及OOAD流程快速導覽。以往在課堂上Teddy並沒有講UML,當課程進行時如果有學員不清楚再補充說明。

前陣子參加一場碩士班口試,發生學生有一張基本的UML class diagram畫錯,這件事一直放在Teddy心中。UML 2.5.1版規格書一大本754頁,一般軟體工程師並不用去記住所有細節,但一些常用的基本符號大致上還是需要知道,至少做到團隊溝通時不要造成誤會。

這兩天花了點時間整了兩頁的UML class diagram常用符號,想說明天上課還是稍微補充說明一下,對學員應該還是有幫助。

▲小抄第二頁


兩頁的UML Class Diagram小抄可在此下載,有需要修正或加強之處歡迎提供建議。

***

友藏內心獨白:有點重要又不會太重要。

2020年6月20日 星期六

為什麼不反駁?

June 01 09:20~10:26

▲學生發問的問題,圖由學生所繪製


好問題

Teddy這學期在北科教軟體架構課程,設計一個專案給學生練習,題目是:「用DDD + Clean Architecture + TDD,開發看板系統的後端。」這禮拜四在北科上課,學生DD問:「Calculate cycle time這個Command要傳送給哪一個Aggregate?還是應該把這個Command實作成一個Application service?」

由於這整學期Teddy都在教學生如何把Event Storming的產出透過一致性、固定的步驟,在套用Clean Architecture的前提之下,採用TDD方式將設計轉成程式碼,以達到Ubiquitous Language in Code的目的。因此當學生認為他們找不到合適的Aggregate來接收Command,Teddy直覺反應就是:「因為這個Aggregate還沒有存在你們的domain model裡面,是你們還沒開始找,而不是沒有合適的Aggregate。

後來Teddy詢問每一組,得到的回答大都是「沒有合適的Aggregate,直接把這個Command做成Application service。」只有一組將這個Command送給Workflow Aggregate,但Teddy覺得送給Workflow並不合適,因為Workflow沒有Card移動的資料,無法計算cycle time。

***

公堂之上大膽假設

最後Teddy提議增加Cycle Time Calculator這個Class,由它負責計算cycle time,並寫了一段程式碼給學生參考。

Teddy:Cycle Time Calculator是一個沒有狀態的service類別,service有兩種:domain service與application service,它應該屬於domain service,放在clean architecture的entity層。

學生DD:可是老師你說接收Command的對象是Aggregate,而Aggregate是有ID與狀態的類別。但是Cycle Time Calculator是service,它並沒有狀態,這樣不是違反了之前design level event storming的規範?

討論到這裡Teddy不得不稱讚一下這位同學,因為這個問題Teddy之前也沒想過…

Teddy:將design level event storming轉成clean architecture的程式碼的方法是我們自己定義的,我們可以加上一個規則「Aggregate與Service都可以接受Command」。

這種說法感覺有點硬坳,但乍看之下也還說得過去。

***

忙到忘記

回家之後過了一會Teddy才想起來:「這個問題之前和ezKanban團隊開會時曾經討論過!」當時Teddy告訴團隊:「計算cycle time是在Reporting bounded context,它不是看板系統的core domain。因為它是產生報表的domain,是唯讀的,所以我們不一定要套用DDD或是OOAD的方式來建這個reporting domain,也許可以用transaction script就可以產生報表。

但後來Teddy沒有進一步與ezKanban團隊review他們實作reporting domain的程式碼,所以細節上他們到底如何實作Teddy也不知道。

***

討論無身分高低

在這禮拜四上課時Teddy曾詢問ezKanban的人如何實作Calculate cycle time?只得到「設計成service」的答案。後來Teddy發表一堆「公堂之上大膽假設」的言論,ezKanban的人也沒跳出來 打槍 提醒Teddy,這個問題之前曾經討論過。

可能學生預設認為上課只是來聽老師開講,把所謂的「正確答案」記下來就好,不要質疑老師,也儘量不要跟老師對上眼、說上話。

但Teddy的課程不一樣,第一個禮拜上課Teddy就告訴學生:「叫我Teddy就好,不用叫我老師。別的課我不知道,但在我的課堂上我們的關係是平等的,不是上下階級。我只是在課題上扮演老師的角色,你們扮演學生的角色,僅此而已。修這門課我會問很多問題,你要願意與我互動,再來修這門課,不然就請退選。

▲課堂上老師與學生的關係是A還是B?


雖然第一周上課Teddy就把話說得很清楚,但學生心裡還是千百個不願意,可能還是怕被老師擺一道,萬一多說話得罪「方丈」日子就不好過了。但專業討論不應有身分高低,如果學生心中有看法,但礙於身分不敢說,這其實是陷老師於不義,阻礙了課堂上探索知識的機會

***

反思

敏捷開發強調要透明,唯有透明,探索調適才可能發生作用。很顯然Teddy與學生之間的互信可能還不夠,導致學生有看法不好意思公開表達。

不過,學生當下沒提出來也不能排除另一個原因,就是學生自己也忘了,根本沒想那麼多。

***

友藏內心獨白:腦補得太厲害。