敏捷式系統分析設計與實作—活用 UML/SCRUM 與 C#.NET (2017/07/15, 48 Hrs)

§ 課程介紹

****** 
1. 本課程包括 UML Model & C#.NET/JAVA 完整程式碼均會以開源 (open-source)方式置於 GitHub 供學員免費下載與持續更新。
2. 課程的實作會同時提供 C#.NET 案例程式碼與 UML Model 檔。
3. 每一期同類型課程會以 C#.NET 與 Java/Srping 交替作為案例實作展示,學員可免費再次旁聽下一期不同程式語言的課程。
******

HSDc. 顧問開發團隊綜合多年來的大型系統實務輔導與開發經驗,並結合大量研究的理論知識與平台技術,所推出關於完整的系統分析、設計至實作的課程,期能協助軟體開發人員在現實的工作中,能瞭解完整的開發流程與各個角色的工作執掌與產出。

在基於以架構為中心來建立團隊具共識的整體觀下,能聚焦在適切開發單位的功能點內,快速地從需求分析導出到實作,找出並克服開發過程中,包括溝通、技能與技術等風險因子。而後基於這樣的框架目標內,得以對系統的結構作重整,卻又不至於影響已有的功能前提下,得以對程式碼施以重構的技巧,讓系統更有延展度與彈性。

觀念的傳授、設計的圖形化塑模表達、程式碼的實作三層次,是我們對於系統分析設計與實作課程的基本原則與態度。

修習本次系統分析的學員們,也必然可以拿到完整的教材、完整案例的 Model 檔與實作程式碼的對應,帶回去自行練習,並能對映於工作上,如此才會有顯著且實質的效益。

HSDc. 軟體團隊,強調的是「虛」與「實」兩者調和的『知行合一』...。

==================================================================================================
繼續閱讀 »

關於 PTT Soft_Job 對於 OOP 的一些回應

沒想到 PTT 的 Soft_Job 看版有人在聊 OOP 的觀念,忍不住作了一些回應。

  1. 早期把物件化的分析/設計思維歸為 OOA/OOD (Object-Oriented Analysis/Design);實現物件化思維的程式語言則稱之為 OOP (OO Programming)。
  2. 實現 OO 思維主要有兩個機制:介面 (interface)、多型 (polymorphism)。包括 .NET/Java 等主流語言,早已支持 OOP,甚至連 php/python 等原來屬於 script-based 的程式語言,也朝向 OO 化的實現機制。
  3. 從 OOP 的角度來看到物件化的設計思維是不妥的;原因在於絕大數開發人員並不知道 Why OO Thinking!其實採用 OO 設計化思維是必然會增加開發成本的。因為它並非為了解決某一局部的邏輯性問題,而是考量全局,從系統整體來看待「變動 (Change)」的議題,進而提出如何擁抱改變 (embrace changing)的解決方案。
  4. 再則從實作上,OO 化的特徵是分散式的 (因為基於類別 (class)的責任分派 (responsibility assign)原則)。所以為了實現 OOP 的分散式架構,程式碼必然大量分散於各類別內,如此會造成實作與偵錯的難度;因而一個必要的配套措施:TDD (Test Driven Development),測試先行是一定要養成的好習慣。
  5. 越是大型變動頻繁、高度維護,或者期待包裝為產品,增加其再利用性價值的系統,採以 OO 的設計/實現 (當然,前提要有這樣實在技能的軟體架構師/Developer)才能感受到其好處:每一次只改變一點點;每一次的變動可以侷限在可控制的變動範圍內。
  6. OO 的特徵是將 程序/資料 封裝至某一類別內,其實在抽象層次,程序稱之為「行為 (behavior)」、資料稱之為「屬性 (attribute)」,兩者均為物件必然會有的特徵 (features),是非常自然不致分離的。但因現實仍沒有一種有效的機制能把物件的狀態 (state)儲存起來,所以實作技術上是把物件與資料分離,資料儲存於資料庫系統內、待執行期間 (run-time)才透過如 OR Mapping (如 .NET ER Framework、Java Hibernate 等),將物件與資料合而為一。
  7. 實業界很有趣的一個現象:重視 MIS (Management Infomation System)系統的公司,幾採以資料導向的開發模式;重視 Web 框架如網路行銷公司,大都採以程序導向的開發模式。至於所謂的 OO 化,實現的程度其實還蠻微小的。
  8. 順待提下重構 (refactor)的觀念:重構是屬於事後 (Coding 後)的設計,一般與事前 (Coding 前,如典型的 SA/SD)設計可能存在著 3:7 或 4:6 (事前:事後)的比重。而且往往寫完程式才是另一段故事的開始:持續重構 (continous refactoring)。
  9. 重構的要件:不會影響到已經上線系統的所有功能。 衡量重構的指標:每一個 method 不會超過 10 行、最長不得超過 20 行。
  10. 如今重視 Web 相關技術、快速實現商業創意的年代,其實已少人有人談及 OO 更遑論具體實踐了。西元2000年以前,包括 UML 三大師 (Booch、Rumbaugh、Jacobson)、Martin Fowler (重構一書即為他的著作)、Kent Beck (XP/Agile 的始祖)、Bob (Clean Code 作者)均為支持物件思維的軟體大家。國外除了這些大師外,實現 OO 的專家其實也不多,一般是會落在如開發底層框架 (如 .NET Framework)的關鍵架構師。
  11. 繼續閱讀 »

程式碼與 UML 類別_循序圖 的關係探討-完結 (4)

支援自動產出循序圖的工具

  • EA (Enterprise Architect) 8.x-內建動態產出循序圖的機制。
  • Together, RSA, Flowchart4j(c#) -支持靜態產出循序圖的方式。
  • HSDc. Sequence Genenator (名稱暫訂)
    • 實作於 EA 7.x-8.x Plugin。
    • 支持靜態產出循序圖的方式。
    • 可支持正向/反向 將程式碼/循序圖互轉的功能。

HSDc Seq. Generator plugin 操作示範

  1. 安裝 Seq. Generator plugin

    圖、安裝 Seq. Generator plugin
    (點擊圖片鏈接看原圖)圖、安裝 Seq. Generator plugin

  2. 繼續閱讀 »

程式碼與 UML 類別_循序圖 的關係探討 (3)

程式碼與循序圖的正反向工程

先瞭解一個重點:靜態程式碼結構並無法直接對應循序圖 (對應的是類別圖)

兩種方法可以產出循序圖:

  • 動態產出:設定 run-time 環境,實際執行應用程式,再由 UML 工具至系統內追蹤解析。
  • 靜態產出:直接掃瞄程式碼,解析物件之間的參考 (reference)。

動態產出循序圖的優缺點:

  • 優點:
    • 不需要程式原始碼,只要具有能直接執行的應用程式 (如 .NET DLL 執行檔)即可。
    • 可以確實捕捉單一程序內,物件之間的呼叫情形。
  • 缺點:
    • 需要事先設定好可以執行該應用程式的 run-time 環境。設定相當複雜繁瑣 (一般需為命令列模式),且不同的程式語言 (如 C#NET, Java, PHP …等)均須各自設定不同的 run-time 執行環境。
    • 只能呈現單一執行路徑內的物件互動。意即,無法呈現如 If…Then…Else 或 Exception 等多種條件或替代路徑。

靜態產出循序圖的優缺點:

  • 優點:
    • 不需要設定繁瑣的 run-time 執行環境,操作相當簡潔。
    • 可以指定所掃瞄的程式碼深度 (層次)。
    • 可以同時呈現多重的條件或替代路徑的物件呼叫互動情形。
  • 缺點:
    • 需要有原始程式碼,以提供靜態掃瞄的來源依據。
    • 轉換工具的實作邏輯並無明確的轉換 (transform)規則;相對來說,需要考量到程式語言個別的機制與語法,故轉換工具的實作難度相對提高。

※ 延伸參考
o 程式碼與 UML 類別_循序圖 的關係探討 (1)
o 程式碼與 UML 類別_循序圖 的關係探討 (2)

程式碼與 UML 類別_循序圖 的關係探討 (2)

程式碼與 UML 設計圖之間的關聯性

從抽象的角度思考 類別(Class)/物件(Object) 的關係

  • 物件是活的!
  • 但是,類別可不是死的 (更不是活的);因為,它僅是對系統的設計契約而已。

問題思考!?
程式原始碼 (Source Code) 對應的是 UML 哪一張設計圖?

推導-1
程式碼 = 靜態結構 = 設計契約 = 類別設計

所以 程式碼 對應的是:UML 類別圖 (Class Diagram)

Ex. 程式碼與類別圖的對應

範例-靜態的程式碼設計契約
範例-程式碼與類別圖的對應關係

使用 UML 類別圖 (Class Diagram)的好處

  • 快速定義類別的結構 (包括類別名稱、屬性與行為)。
  • 過濾程式碼實做的細節,容易聚焦於類別的責任分派 (responsibility assign)設計議題。
  • 可以透過工具,將類別圖轉出至對應的程式碼 (反之亦然)骨架 (skeleton)。

類別圖無法作到 …

  • 無法呈現系統執行期間 (run-time),程序單位之間的呼叫情形。
  • 無法追蹤為完成某一特定功能案例,物件之間的動態相依呼叫關係。
  • 無法掃瞄物件之間的動態連結,是否有違背類別圖的結構設計。

繼續閱讀 »

程式碼與 UML 類別_循序圖 的關係探討 (1)

基礎觀念導引 - 何謂靜態與動態?

靜態結構 (Static Structure)

  • 表達軟體內部的結構設計。
  • 一般指程式原始碼 (Source Code)。
  • 軟體人員對資訊系統的設計契約 (Design Contract)。

靜態結構的設計契約

public class myclass {
	public void method_1() {
		//do something
	}
 
	public string method_2(string var) {
		//return a string
		return var;
	}
}

誰來解讀設計契約?

  • 一般指軟體資訊系統或應用軟體伺服器 (Application Server)。
  • ie. 可以編譯 C#.NET 程式碼 (設計契約)並能在 .NET 平台上執行應用程式。
  • 可以編譯 Java Spring 程式碼並能在支持 JEE (Java Enterprise Edition)平台執行完成編譯的應用程式。

動態相依 (Dynamic Dependency)

  • 系統在執行某一特定功能時,所啟始不同的程序單元之間呼叫的一種動態相依關係。
  • 一般指程式碼經過編譯後在執行期間 (run-time)的應用程式。
  • 資訊系統履行軟體人員的設計契約,使之可以在其平台上執行。

繼續閱讀 »

第 1 頁 / 共 248 頁123456789101112...203040...最後一頁 »