sdfly: 4月 2018

建立專案情境 4

我覺得，除了設計ER Diagram外，還要設計自己的Data Model。我為自己的系統設計了一套自己的Data Model。Data Model 要與 Design Pattern 互相搭配(如圖1)，我現在要搭配起來，最後才串接 Framework。我想這就是為什麼以前的日本超大型的專案，在 OOA 的階段，會花許多的時間的原因吧(除了，還要分析舊系統，將其 Break Down 至最細的一層，這要許多的人一起合作)。

圖1

抽象的Data Model 架構好後，就可用 Design Pattern 實作(開始定義)自己的Object Model的行為，並且用Context Model界定系統的界限(boundaries)，然後再定義好跨系統的 Data Model。這就難了。難怪，Data Flow Diagram這麼複雜。
(這樣想下去，我會有個激動，會想將我當時設計的產證管理系統的Data Model拿來重新學習、設計，天啊，要學習的東西越來越多了。)
好久沒用Design Pattern了，最近要學的是跟Data 息息相關的Pattern。我記得十幾年前在公司內第一個教我們UML的資深同事，說Design Pattern是從建築業開始的。
一般我們常用的DAO也是一種Design Pattern。
若設計好抽象的跨系統的Context Model，可以，透過SUN JAVA RMI，可以架構多個Client Server，可以用來實作跨系統的Context Model，藉以用來練習界定系統的界限(boundaries)，可是，同時得學習如何設計好的Interface(和interface相關的Design Pattern是Facade)(近年來，很多案子用大陸的套裝軟體，並與大陸的團隊合作，他們稱之為接口。我不適應這個名稱，我覺得，如果硬翻成中文，很憋扭，那還是沿用原文的好。Interface沒定義好，也是很多災難的開始，例如：很多，即便是同公司，但不同的部門，要求對方的部門要修改Interface，若對方不願意改....，或是對方的回傳值跟你談定的不一樣，或是有NullPointException的問題......。)，同時UML也很重要。

使用Maven Install 好projects之後，就可以練習了。圖2，是我使用一個Git的Open Source Project當作練習，共有一百多個Module。