【公佈】五,六月份的軟體設計課程—台中場UML與非正規學分班系統分析課程

各位 台中地區 的朋友們大家好:

開課日期: 2007/05/26、27(星期六、日) 共兩日

HSDc. 今年在教育訓練的計畫是,在中部與南部至少每三個月舉辦巡迴性的「軟體設計單元性」課程,能讓中南部地區有志於學習軟體設計各類議題的朋友們也多了一個充電學習的管道。HSDC. 已與「逢甲大學」洽談場地教室與資源等合作事項,台中地區的學員們,得享有交通便利、且環境清幽的上課環境。

同時,我們也熱烈邀請,台中地區大學資訊科系的助教、講師們,歡迎蒞臨旁聽,完全免費
另外,關於 HSDc. 的所有課程,只要是 出具家扶或清貧 等證明的學員們,也是完全免費

更是歡迎報名的學員,能將在日常工作上的設計與實做所碰到的各類問題,課餘或課堂中,HSDc 講師們均會熱心協助提出解決方案的...

課餘結束後,HSDc. 會在星期六舉辦晚餐的聚會(成本問題,煩請與會人員們自備晚餐費用),屆時更是期待能在茶餘飯後之餘,一同來探討軟體各類事項的議題,那是非常有意思與有趣的活動。


台中場次】UML 2.0 觀念引導與實務操作入門 (星期六、日) — (05/26、27)

課程大綱  我要報名


課程簡述:
  • 以 "問題-解決方案(Problem-Solution)" 的觀念傳授與實做方式,引導學員實際針對案例分析並利用 UML 工具畫出 UML 2.0 十三種圖。
課程特色:
  1. 示範與引導學員實際操作與練習。
  2. 第一日上課時即會發送給學員教學光碟,內容提供 EA 自動安裝與教材內容及範例。
  3. 提供兩個完整的案例研討(Case Study),自然又流暢地整合:
    • UML 2.0 13張 設計圖 (包括企業流程、系統需求、內容結構、動態行為等構面)。
    • 提供 UML Model 檔(EA 6 格式)。
  4. 本課程均保留與提供了學員免費再旁聽乙次同樣課程的權利,以一次低廉的收費,就可以擁有兩次上課的收穫,課程的師資、內容與品質,我們有信心是不會讓學員們失望的。
課程目標:
  1. 畫每一個 UML 圖之前,會先以一個問題的陳述,來說明應用該圖形的時機與場合,然後提出具體的解決方案。
  2. 課程提供兩個案例,並涵蓋串連整個 UML 13 種圖。
  3. 完全以實務為主,指導學員如何利用 EA(Enterprise Architect)學會畫 UML 2.0 的圖形。
  4. 學員於課堂上實際親自操作 UML 工具,由講師示範與指導畫每一張圖的技巧與圖形的元素說明。
授課日期
  1. 2007/05/26、27(星期六、日) 共兩日。
  2. 每日上課為六個小時(AM 9:30~12:30、PM 1:30~4:30),課後並留半個小時供學員自由提問。
授課地點:
  1. 逢甲大學會議廳教室,地址:台中市西屯區文華路100號。
  2. 上課前一週會通知上課所在教室位置(待本部與該校總務處確認教室後公佈)。
  3. 報名人數滿 10 人即開班(同時保留 5 名學員重新選修該課程)。
適合學員:
  • 系統分析/設計(SA/SD), PM, Programmer 等在職軟體開發者或在學學生。
  • 想實際學會如何利用 UML 工具來畫 UML 2.0 十三種圖。
  • 看了很多 UML 書籍,仍然無法在正確的時機畫出正確的 UML 設計圖。
課程費用:
  1. $3,600, 含稅。
  2. 曾經上課過本公司的「單元系列課程」學員,優惠 $3,200,含稅。(請記得註明為舊生,本公司查詢確認即以優惠算)
  3. 三人同行,或同時報名另一單元課程(兩日),亦比照舊生的優惠折扣,每位只需$3,200(含稅)。
師資簡介:
  • 賴信仁(Ringle Lai),王克明(Kenming Wang)
  • 擅長以非常淺顯易懂的比喻及說明,將複雜的系統抽絲剝繭,重新釐清脈絡,讓學員一清二楚,並善於引導學員具備設計應有的反思能力。
使用教材:
  1. 由授課講師提供講義,包括內容、案例分析與 UML 13 種圖範例。
  2. 學員可攜帶相關 UML 參考書籍,並對於書中內容有問題者,可以直接提問。
開發工具:
  1. EA 6.5(Trial) UML Tool。
備註:
  1. 教室設備包括白板與投影機,由講師親自說明與操作示範。(學員可攜帶錄音筆)
  2. 學員最好能攜帶 Notebook,可以於課程中實際操作與練習。
  3. 報名滿 10 名即確定開班,同時保留 5 名學員重新選修同一課程(請攜帶原上課講義)。開課前兩日會以電子郵件聯絡與通知學員。
  4. 為確保報名足額人數,煩請先以 ATM 轉帳預約費用($1000),並請於報名表備註欄位內,註明您的轉帳帳號末 5 碼與轉帳金額。(若實在不及轉帳者,仍可現場報名,但請在報名表內註明現場繳費)。
  5. ATM 轉帳帳號: 新光銀行 (103) 帳號: 0772-50-100979-9
課程諮詢:

聯絡電話: (02) 2722-7179
Email: service.hsdc@gmail.com
專業論壇: http://www.hsdc.com.tw

各位好:

開課日期: 2007/6/30 每週六白天,共九個星期。
54 Hrs、完整軟體系統開發、分析與設計的課程,只要 NT$9,000
(同等課程原價學費為 $25,000 以上,其它差額,係由教育部與本中心吸收補助。)
(家扶清貧同學,只要出示相關證明,與本中心聯絡報名,費用全免!!)

這是教育部委由 HSDc. 於台北地區舉辦之{教育部非正規學分課程}系統開發分析與設計 課程。上完本課程,即可取得大學同等資格之三個學分(大學、研究所承認資格, 已奉教育部台社(一)字0950154417號核定)。

本課程為教授以大學水平為對象及對系統分析、設計入門的學員,課程內容儘量採淺顯、凸顯主題,卻又不失實務,讓系統分析與設計不會背離現實的平台與開發環境。除了適合想修習軟體資訊工程、取得學分的同學外,對於一般已擔任軟體開發職人員,想習得正規軟體開發的方法與正則的系統分析與設計的思維,更是應該把握本系列的課程。

P.S. 高雄地區同等課程可參考: http://www.taiwan-cspa.org 諮詢報名


{教育部非正規學分課程}系統開發分析與設計 (54 Hrs, 06/30 開課, 每週六白天)

課程大綱  我要報名


課程說明
  • 本課程係為本顧問中心與教育部合辦之「軟體資訊開發與管理」系列之大學教育訓練課程。學員上完本課程(54 Hrs),即可取得大學同等資格的三個學分(大學、研究所承認資格, 已奉教育部台社(一)字0950154417號核定)。
課程目標
  1. 瞭解軟體開發的模式,以及符合現代 e化系統開發的流程與方法論。
  2. 瞭解物件導向本質觀念與在軟體上的應用。
  3. 瞭解系統需求分析與結構設計的觀念與塑模能力。
  4. 學會正反向軟體工程與應用程式碼的部署。
上課日期
  1. 2007/06/30 起,每週六白天,每次上課為六個小時(AM 9:30~PM 4:30),共九個星期。課後並留半個小時供學員自由提問。
  2. 預定上課日期: 6/30, 7/7, 7/14, 7/21, 7/28, 8/4, 8/11, 8/18, 8/25。
  3. 遇國定假日或颱風等因素,則延至下一週上課日(本中心會主動通知學員),以此類推。
授課地點
  1. 開羅會議中心,地址:台北市光復南路65號B2 (光復南路、市民大道交接口)。
  2. 參考交通與地圖
適合學員
  • 具高級中學同等學校畢業、或同等學歷資格、或年滿22歲以上等人員。
  • 學員最好有基本的程式設計能力(基本即可)。
  • 當然,本課程也極為適合想瞭解與學會整套軟體系統開發、分析與設計的軟體開發人員。
課程費用
  • 9,000元,每學分3000元,計三學分 (含講義、稅金,但不含參考書籍)
  • (同等課程原價學費為 $25,000 以上,其它差額,係由教育部與本中心吸收補助。)
師資簡介
  • 賴信仁(Ringle Lai)、宋敏如(Cathy Sung)、陳明儀(Simon Chen)、王克明(Kenming Wang) 。
  • 授課講師均具有 10 年以上專業開發、輔導與授課經驗,必能帶給學員最正確的觀念與技術。
使用教材
  1. 由授課講師提供講義,包括內容、案例分析與 Model/程式碼 等範例。
  2. 學員可攜帶相關軟體設計參考書籍,並對於書中內容有問題者,可以直接提問。
  3. 建構選讀參考書目:「Applying UML and Patterns(Craig, Larman, 有中文翻譯版, 活用 UML 與樣式, 趙光正譯)」, 「UML User Guide(Grady Booch, Ivar Jacobson, James Rumbaugh)」, 「Object Oriented Analysis and Design(Grady Booch)」。
核發證明
  • 本課程學期中與期末均會舉行測驗,每次測驗時間為三個小時。
  • 測驗成績達 60 分以上,缺課未超過總上課時數六分之一,由教育部核發學分證明書(有效期為十年)。
備註
  1. 教室設備包括白板與投影機,由講師親自說明與操作示範。(學員可攜帶錄音筆)
  2. 學員最好能攜帶 Notebook,可以於課程中實際操作與練習。
  3. 報名學分班學員,請先以 ATM 轉帳預約費用($1000),並請於報名表備註欄位內,註明您的轉帳帳號末 5 碼與轉帳金額。
  4. ATM 轉帳帳號: 新光銀行 (103) 帳號: 0772-50-100979-9
  5. 本課程上課學員需滿 20 人以上,若未達上課人數則延期至下一梯次開課,已報名學員,本中心會電話通知,並主動辦理退費(或可保留至下一梯次)。
課程諮詢
  • 關於課程內容與學分等問題,可直接聯繫本中心。
  • 諮詢電話: (02) 27227179 聯繫郵件: service.hsdc@gmail.com

類別之間的關係(Relationship) — 一般化—特殊化(Generalization-Specialization) (3) — Basic

說明

從生活面的觀點來觀察時,當發現到兩個以上的類別有其相似之處(但又不盡相同),我們可以把相似之處抽象(abstract)放在更高層次的一般性類別。例如,觀察「貓」與「狗」兩個類別,是否有可能抽象化成為一般性的類別? 兩者的品種完全不同,但其實也存在著某種程度的相似性,事實上,若我們要開發一個 “寵物店管理系統”,那麼,其實很自然,就可以將此兩個類別抽象成為「寵物」這個一般化的類別。相對來說,只要是符合「寵物」一般化類別共同特性的其它類別,包括可愛、能取悅、陪伴主人等特徵與行為,就可以成為「寵物」的特殊化類別。一般化—特殊化關係的 UML 表示法如下圖。

 

範例、一般化—特殊化的 UML 表示法
圖1、範例 一般化—特殊化的 UML 表示法

概念上,所有貓、狗的個體(instances)從定義來看也都是「寵物」的個體,那麼就可以將「貓」、「狗」等視為是「寵物」的子型態(sub-type)。由此可以看出,「貓」是一種特別的「寵物」。其中一個重要的觀念在於,所有與「寵物」有關係的特徵(features),包括關連、屬性(attributes)與操作(operations),對「貓」、「狗」、「烏龜」來說也都是成立的。

從軟體的觀點來看,對一般化關係的具體實作就是 “繼承(inheritance)” : 「貓」是「寵物」的子類別(sub-class),在主流的 OOP 語言,包括 Java 與 .NET 等,子類別會繼承超類別(super-class)的所有特性,而且還可以覆寫(override)任何超類別的方法(method)。

一般程式設計人員最容易誤解物件導向的繼承觀念就在於,以為繼承是被用來 “可重用(re-use)”的:可重用既有的程式碼。其實繼承的最重要原則是在於 “可被替代性(substitutability)”,而這正是物件導向另一個非常重要的思維– “多型(polymorphism)”:讓外界(Client)能以「一視同仁」的角度來看待多個特殊化類別所抽象出的一般化類別!

關於 "多型" ,留待在在進階主題內再行詳述。請記得,多型同時也是解決軟體複雜度的一個重要原則。

閱讀全文 »

【設計樣式】「Chain of Responsibility」的範例與說明

範例描述

“敗家子” 是一部經典的武功喜劇,關於本片的劇情介紹,可以參考:【老片分享】經典功夫喜劇片—敗家子
其中,元彪所飾演的 “敗家子”,好打架,經常製造許多麻煩,但他又是九代單傳的寶貝兒子。父親怕他受傷,所以派了一個隨從 “派通街”,在背後協助解決所製造的麻煩。

敗家子是 “麻煩製造者(trouble maker)”,而派通街是 “麻煩處理者(trouble handler)”,敗家子所闖的禍,均交由派通街來處理。

而隨著製造的麻煩越多,派通街需要更多的助手來「分門別類」地處理,這些處理者逐漸有系統性地形成一種 “串鍊(chain)”,當麻煩透過派通街送進來時,第一個處理者認為麻煩不是他所處理的,就會交給後續的(successor)處理者來處理,如此依序跑完整個 “串鍊”,若沒有人可以處理,則拋出 “無法處理” 的訊息。

CoR(Chain of Responsibility) 的說明

敗家子永遠不用擔心 “誰” 來幫他處理麻煩,只要將麻煩丟給一致的介面(interface)–派通街處理即可。

視麻煩的程度或種類,交由串鍊中某一個處理者來處理,當然也有可能因麻煩大到無法解決,而沒有處理者可以處理。

這是一種 “責任的串鍊(Chain of Responsibility, CoR)”,Client 端(敗家子)不需要也不會知道 “誰” 來處理他所丟出的麻煩,如此可以降低 “Client” 與 “處理者” 的耦合(coupling)程度;但相對,”串鍊” 的處理者最好不要太多,否則因責任一直轉派的緣故,會降低處理效率。

CoR 類別圖(Class Diagram)說明

圖、CoR 的 UML 類別圖
(點擊圖片鏈接看原圖)圖、CoR 的 UML 類別圖

  • 把 “派通街” 角色設計為 “抽象類別(abstract class)”,他本身只負責制訂一致性的處理介面: handleTrouble(),與實作指向後續者(successor)的鏈結。
  • 來自 “敗家子” 的 “Trouble” 訊息,會依照麻煩的大小程度依序交給 “大、中、小” 三個具體的類別來處理;其中 “Null Trouble Handler” 類別,並非是空的,而是指麻煩超乎程度而無法處理了。
  • “大、中、小、Null” 四個具體(concrete)的類別,會覆寫(override) “handleTrouble()” 操作(operation),個別實作處理麻煩的方法。
  • “麻煩(Trouble)” 被當作參數從敗家子傳給派通街,實做上可以是 “字串”、”XML”、”物件” 等。

使用案例分析常見的幾個問題

前言

要能建構一份有效的使用案例需求模型 (Use Case Model),比想像中得難,使用案例是 “易學難精”,只是那麼幾個簡單的圖形元素來畫使用案例圖、以及僅用白話的文字敘述來紀錄使用案例的需求描述,但是,若沒有把持使用案例最根本的原則與精神,真的很難寫得好。筆者在諸多 IT 單位的顧問輔導經驗中,所看到多個單位所 “畫” 出的使用案例,10 個中就有8個有問題,探究其中最大的問題,在於寫使用案例的需求分析人員,很難擺脫掉 “既有傳統” 的束縛,例如會從企業流程 (Business Process) 的觀點來分析使用案例,或者是馬上就聯想到系統內部的實作問題,包括權限控管等問題。筆者常開玩笑的說,要能寫好使用案例,最好本身就是 “無知”,不知道企業流程的邏輯判斷規則、”看不到” 系統內部是如何實現(Realize)使用案例的。奇怪的是,要能 “逼” 自己 “無知”,對系統需求分析人員好像很難,而且往往就是在不知不覺中,就把既往對 “領域” 與 “平台” 的知識給表達在使用案例中,事實上,根本就是把使用案例當成是 “另一種” 需求記錄的工具而已。

很是可惜,筆者一直認為,使用案例絕對是以 “專案型態(Project-based)” 開發的最有效利器,它表達的就是 “純粹” 的資訊系統 “局部” 功能觀點的需求模型,只要能寫好使用案例,甚至在不需要作系統內部結構分析的情況下,馬上就可以轉移至程式碼的實作階段,而且是很快速直覺。再利用分析層次的類別 (analysis class),就可以建構符合三層 (3-tier) 結構的 MVC 模型,有效隔離 UI 與資料庫的變動性,同時,再加上一個極為重要的手段:
”對每一個使用案例”,都加上能驗證功能的測試程式碼!” 如此在每一次的功能需求變動,都能提醒開發人員注意變動的影響部分,包括功能測試碼也跟著要修正。

為了順應短線的專案開發生態,快速實現「使用案例」,馬上導出至系統的實作,是最有效與最現實的手段。然後加上兩個配套的措施,以確保專案的品質:以使用案例為單位,撰寫功能測試程式碼;利用分析類別,建構符合 MVC 的三層實體框架,以隔離 UI 與 資料庫的變動。

而當第一個釋出(release)的專案能滿足系統的功能需求後,因此而能取得更多的開發資源,以及開發人員的溝通默契與技能逐漸成熟後,且已有基本的框架結構,此時再針對程式碼施以重構(refactoring),以及對結構作重整(refine),兩者是屬於系統內部結構分析的範疇,如此而更有機會成為可再利用性高價值的產品(Product)。

所以,如何寫出有效能確實表達系統功能觀點的使用案例,可以說是專案開發成功與否最重要的關鍵。但如同前述,使用案例是「易學難精」,在此筆者列出幾個比較常見的問題,再以簡單的三言兩語來說明為何這些是問題、SA 大概是以什麼角度、假設點在分析使用案例的,然後筆者再提供修正後的建議。底下的每一個問題,是經過簡化,實際的案例,大部分是同時有著眾多下述的問題合著來的,而開發團隊卻經常有茫點,而無法理出問題會是在哪裡。

1、從企業流程的觀點描述使用案例之間的關係

問題:
這幾乎是因為太清楚領域知識與業務流程的 “資深 SA” 所畫出來的,經常都會把使用案例當成是企業流程的活動(activity),然後 “想辦法” 將這些使用案例依據業務流程的規則與順序給 “串起來”。請記得!! 使用案例是不表達業務流程的,業務流程的表達,會利用如活動圖(activity diagram)來描述,使用案例僅僅是表達參與者在某個時間點使用系統的局部功能觀點。

問題—從企業流程的觀點描述使用案例之間的關係
圖1、問題—從企業流程的觀點描述使用案例之間的關係

修正:
絕對不要把業務流程的觀點給表達在使用案例的,就是老老實實,根據參與者希望系統該提供 “哪些系統功能”,這些功能,就會成為一個個的使用案例。

修正—只 “老老實實” 表達局部功能觀點的使用案例
圖2、修正—只 “老老實實” 表達局部功能觀點的使用案例

閱讀全文 »

利用 UML 類別圖表達 CMMI Content 與範例說明

關於 CMMI

  • 與其說 CMMI 是流程框架(Process Framework),倒不如說 CMMI 是目標框架(Objective Framework)。
  • CMMI 是以 “流程區域(Process Area)” 為主要完成目標。無論是以 “Continuous” 或 “Staged” 的途徑(approach),均以 “Process Area” 為單位,來檢驗 “軟體能力” 的成熟度。
  • Ex. “需求管理(Requirement Management)” 為一個 “Process Area”,是 CMMI level 2 必須完成的主要目標。(level 2 需完成 7 個主要的 “Process Area”;level 3 需完成 14 個”)。
  • 每一個 “流程區域” 會細分為多個子目標。若該子目標只對應單一的流程區域,稱為 “特定目標(Specific goal)”;若子目標會涵跨多個流程區域,則稱為 “一般目標(Generic goal)”。
  • 每一個特定目標/一般目標會列出一到多個 “期望(expected)” 的特定實務(specific-practice, sp)/一般實務(generic-practice, gp)。實務為一段陳述(statement),表達了完成子目標時的作法。
  • 實務並非為絕對、唯一達成子目標的唯一作法,它是 CMMI 建議、期望的作法,但仍可就現實狀況來找出 “自己” 的的實務作法,重點是,能達成(achieve)子目標(GG/SG)的規範與要求。
  • 既然實務僅為敘述性的陳述,可以把它視為是 “抽象(abstract)” 的 “How-to”,要能找出符合實務的作法,可以從主流軟體開發流程,如 RUP/Agile/XP 等,找出實踐的具體手段。

CMMI 的 Model Content 為:Process Area, GG/SG, GP/SP。其中,Process Area 與 GG/SG 為達成軟體能力成熟度的必要元件(required component);GP/SP 則為 "期望(expected)" 的元件,屬建議性,並非絕對需要。若以 UML 類別圖表達 CMMI Content 之間的關連,如下圖1 表示。

利用UML 類別圖表達 CMMI Content 之間的關連

圖1、範例-利用 RUP/XP 方法論實現 Requirement Development -> SG3

CMMI Content 類別圖說明:

  • CMMI Level (2~5) 包含(aggregate) 多個“流程區域(Process Area)”。
  • 每一個流程區域會包含多個子目標(Goal),子目標依性質區分為“一般目標(Generic Goal, GG)”與“特定目標(Specific Goal, SG)”。
  • 將 GG/SG 設計為“Interface”的意涵在於,任一個具體(concrete)的實務(practice)類別,只要符合該子目標的介面規範即可,也就是說,CMMI 不規定“how-to”,只要能確實達成(achieve)子目標的規範即可。
  • GP/SP 可視為是“抽象(abstract)”的“how-to”陳述(statement),因此,具體實務類別也可以依循 GP/SP 內的陳述來具體實現。

閱讀全文 »

【書摘】使用案例的 12 步寫作訣竅

摘錄自 「Writing Effective Use Cases」,中文譯名:「使用案例寫作實務」,譯者:趙光正

尤其是第一個步驟,是個人在規劃使用案例圖時,覺得最為重要的關鍵所在(從架構觀點的角度視之),但也是許多單位 SA 所經常忽略與不重視的。

  1. 找出系統邊界(情境圖、專案範圍內/外清單。
    Find the boundaries of the system(context diagram, in/out list).

  2. 用腦力激盪法列出主要參與者(參與者簡述表)。
    Brainstorm and list the primary actors(actor profile table).

  3. 用腦力激盪法窮舉系統中主要參與者的使用者目標(參與者—目標清單)。
    Brainstorm and list the primary actors’ goals against the system(actor-goal list).

  4. 找出最外層目標摘要等級的使用案例,裡面會涵蓋上述的所有東西。
    Write the outermost summary-level use cases covering all of the above.

  5. 重新討論並修正目標摘要等級的使用案例。新增、刪除或合併一些目標。
    Reconsider and revise the strategic use cases. Add, subtract, and merge goals.

  6. 選出一個使用案例,展開它或寫出其敘事情節,以熟悉使用案例的寫作材料。
    Pick a use case to expand or write a narrive to get acquainted with the material.

  7. 補上使用案例的關係人與其利益、事先條件與事後保證,並重複檢查它們。
    Fill in the stakeholders, interests, preconditions, and guarantees. Double-check them.

  8. 寫出主要成功情節;重新檢查關係人的利益與事後保證。
    Write the main success scenario; check it against the interests and the guarantees.

  9. 用腦力激盪法窮舉可能的失敗條件與替代路徑成功條件。
    Brainstorm and list possible failure conditions and alternate success conditions.

  10. 寫出每個擴充情節中參與者跟系統如何動作。
    Write how he actors and system should behave in each extension.

  11. 把需要自己獨力出來的東西分開變成子使用案例。
    Break out any sub use case that needs its own space.

  12. 從最高層的使用案例開始重新調整整組使用案例。有必要時新增、粹取或合併使用案例。請重新檢查使用案例的完整性、可讀性與失敗條件。
    Start from the top and readjust the use cases. Add, subtract, and merge as appropriate. Double-check for completeness, readability, and failure conditions.
軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal