{交易指標} 三日紅黑值

這是網友 kktoget 在我前一篇:「抓緊時機」留言迴響時,請我協助他在 HTS 交易系統寫一個指標。我並非專業或兼職寫指標程式,一切是因為自己的研究,有需要時才會動手去寫的,況且,近乎 VBScript 的語法,似乎沒什麼好學的,反正就是有足夠的函數手冊(一般不會有完整),寫了能運作就好了。不過既然 kktoget 網友已經把指標的公式給放進迴響內容了,看其公式好像還挺有趣的,所以花個半小時研究一下,並且利用 HTS 寫出來,先看看 kktoget 的「三日紅黑值」演算邏輯。

1.當日K收紅, 則為紅值, 計算公式 : 收盤價- 最低價=正價差
2.當日K收黑, 則為黑值, 計算公式 : 收盤價-最高價=負價差

將 今日向前推算三日之紅黑值相加則為當日3日紅黑值
如: 前天負(正)價差 + 昨天負(正)價差 +今天負(正)價差 , 則得當日的3日紅黑值
紅黑轉折值=當日的3日紅黑值與昨日的3日紅黑值相差值
如今日紅黑值為+0.1, 昨日紅黑值為-0.4, 則紅黑轉折為+0.1-0.4=0.3
如今日紅黑值為-0.3, 昨日紅黑值為+0.1, 則紅黑轉折為-0.3+0.1=0.2

紅黑轉折值的部份是以當日計算出的紅值(或黑值)與昨日紅值(或黑值)的相差值 ^__^
如今日紅(黑)值為+3.8, 昨日紅(黑)值為-2.5, 則紅黑轉折為3.8+(-2.5)=1.3, 判讀今日紅黑轉折值為-1.3.(說明: 若股價今日為[-1.3]才會紅值轉黑值)

我所寫出的公式與在 HTS 畫面的圖形如下:

//三日紅黑值指標
//	written by Kenming Wang , date: 2007/04/26

Variables: RB(0),RB1(0),RB2(0), TR(0)

//判斷近三日收紅或收黑
IF C > O THEN
  RB = C-L ELSE
  RB = C-H
END IF

IF C[1] > O[1] THEN
  RB1 = C[1]-L[1] ELSE
  RB1 = C[1]-H[1]
END IF

IF C[2] > O[2] THEN
  RB2 = C[2]-L[2] ELSE
  RB2 = C[2]-H[2]
END IF

//計算三日轉折值
TR = RB + RB1 + RB2
//PRINT("TR",TR)

//將紅黑轉折值畫在圖表上
DRAW1(TR-TR[1], "%紅黑轉折值")
DrawBase1(0, "分界", DarkGray, 1)

三日紅黑值指標

不知道寫得對不對? 這還要請 kktoget 驗證並告知一下。另外,是否可以請解釋一下該指標的目的與其操盤邏輯呢? 我不太清楚該指標的主要作用為何? 是否是乖離型的指標呢? !^^

漫談高鐵訂票系統的結構分析—觀念篇

我在網路上看了諸多評論「高鐵訂票系統」重複訂位相關問題的文章與討論串,大部分的 IT 人,謾罵聲不斷,認為該檢討承包系統開發的廠商;也有一小部份人提出自己的看法與建議的解決方案。這非常好,系統的不穩定性造成民眾的不便,本來就該有人監督,廠商也應該虛心接受眾多人所給予的建議。個人並不打算批判,以擔任軟體架構顧問的角度來看此事件時,先找出根本的問題是什麼,然後再提出具體的解決方案。我打算分兩篇文章論述,一篇為觀念篇;另一為實作篇。觀念部分,希望能就系統的結構性來探討;實作部分則會提出整個系統分析設計的過程與實作碼的產出,同時也打算模擬數千至數萬人同時訂票的情境與意外的處理,應該是盡量會接近原廠商所使用的平台(J2EE Solution)。當然,個人更是歡迎,若有機會,原廠商可以找我們過去聊聊,我們絕對很樂意效勞,也願意更進一步說明我們所診斷出來的問題,並且提供開出的處方為何。

一般看待高鐵訂票系統之所以出問題,原因有二:

  1. 經營者的看法與實際使用有落差:
    持這種觀點的人,主要是著眼在經營者提出利用「飛機訂票系統」的觀念來實做高鐵的訂位,實際上並不恰當,飛機的訂位主要是預定「航班」,而實際的劃位則必須在各自的機場櫃臺進行Check-in,這與高鐵的座位預售,明顯有相當大的差距。
  2. 實做平台的考量上,未考慮到分散式交易:
    這種看法大多是資訊專業人員的看法,也就是說,由於未考慮到各售票單位(包括櫃臺以及售票機)對於某一個已訂位的位置的交易,造成在同一時間內,多個售票單位可以販售同一個位置的現象,這主要是屬於「Transaction Lock」的問題。

事實上,這兩個問題都是存在的,然而,這卻不是造成高鐵訂票系統出問題的「主要原因」! 無論是持哪種看法,其實都是「見樹不見林」,忽略了整體軟體設計最重要的核心 – 「軟體結構」的問題。

先從第一個觀點說起:
使用者需求本來就是會不斷地變動,然而,身為軟體設計人員,在開始進行系統分析設計時,本來就應該要想到「使用者需求」是「暫時」的,然而,重點應該是在於軟體結構本身,能不能夠充分地配合使用者需求的變動而有所彈性;因此,把系統出問題怪罪到使用者需求的變動,是軟體設計人員的「墮落」!
從上述的例子來說,使用者雖然在一開始就提出了不正確的需求,但是,當管理者在上線前一、兩個月就發現了這個「重複訂位」的問題,軟體設計人員卻沒有辦法在這段期間內修復這個問題,這很明顯地,並非是單純的「需求變動」而已,勢必是整體的軟體結構發生了大問題,造成了「地基不穩」,以致於「挖東牆補西牆」,永遠沒有辦法確實解決這個問題。

再從第二個觀點來看:
Transaction 的問題,其實是資訊系統管理面「最基本」的問題,套用前述的觀點,怎麼有可能在一、兩個月前發現這個問題,卻拖了一、兩個月都沒有辦法解決,這也很明顯地,勢必是在結構上出了嚴重的問題,以致於根本沒有辦法對症下藥。

那麼,軟體結構究竟是出了什麼問題呢? 以下,我們就上述兩個現象分別來說明:

第一個現象主要是軟體的整體結構不夠穩定,而且缺乏彈性,因此,當使用者的「企業規則」(Business Rule)有所變動時,系統沒有辦法快速因應。

這很明顯地,是設計人員在設計系統時,並沒有針對企業的應用系統結構進行良好的分析,致使在捕捉系統的「本質性物件(Essential Object)」時,出了大問題。本質性物件沒有辦法捕捉好,自然而然對於整體系統的未來彈性,就很容易出嚴重的問題。什麼叫「本質性物件」呢? 其實就是無論企業的作業流程(Process Flow)或是企業的使用者需求(User Requirement)如何變動,但是其基本的結構都不會輕易改變的那些重要概念(Essential Concept),就是所謂的本質性物件。

我們以高鐵訂票系統為例,其本質性物件其實非常單純,我們以 UML 標準的 類別圖(ClassDiagram)來表達:

圖、高鐵訂購系統的核心結構
(點擊圖片鏈接看原圖)圖、高鐵訂購系統的核心結構

從這張圖中,其實就可以看出個端倪:

左下角的兩個物件:Seat班次,主要是由高鐵人員自行維護的相關基本資料,然而,所有的重點應該在於「訂票交易」與「訂票Demand」這兩個物件上。

從訂票交易來說,其只要能夠提供起站及下車站給「訂票Demand」的物件,不管究竟是像飛機的依班次決定是否有空位;或是像現在高鐵實際營運的依特定座位決定是否有空位,其實,該訂票Demand物件只要回答「可不可以訂位」就可以了

至於其實做的相關細節,應該都被隱藏在「Specific 班次」以及「SpecificSeat」兩個子型態(SubType)的物件中。

這樣設計的結構最大的好處是:
當我們發現未來高鐵的軟硬體設施真的如同飛機一樣,可以讓乘客先行訂位,之後才在各自搭乘的櫃臺進行「Check-in」以確認其真實的位置,此時,我們只要再重新「Plug-in」「Specific 班次」的物件到高鐵的訂票系統中就可以了!

至於第二個問題,則是整體 IT 結構規劃的問題。也就是說,由於沒有對整體的系統結構作一個有效的區分,而導致 系統面 與實際 問題領域(ProblemDomain) 面糾纏不清,大幅增加了整體應用系統的複雜度與管理成本。這個部分的問題,其實可以用 "Boundary-Control-Entity" 的 分析層次的設計框架 來予以解決。關於實作的相關設計議題,我們留待實作篇再來討論。

【好書分享】抓緊時機
抓緊時機  抓緊時機
 ———————————–
 作者: 邱一平/著
 出版社:大益文化
 ISBN: 9868253012

內容簡介
傳統的技術分析偏重於量、價的分析,事實上,技術分析應該包含「量、價、時間」三要素。然而費伯納西時間序列、甘氏矩陣、星座理論……雖然一直是「時間」追求者奉為圭皋的典範,但是這些理論有的艱澀難懂,有的雖然簡潔扼要,不過得到的結論,經常莫衷一是。可以說在技術分析的領域中,「時間」的概念僅聊備一格罷了,然而對大部分投資人而言,它是真正未來交易勝算的絕對關鍵。

作者累積了二十年經驗,發現不論投資人採用哪種類型的技術分析,如果時機不對,即使績效再好的指標訊號也會徒勞無功。只有在真正的交易時機出現時,技術指標的交易訊號才能夠發揮它的關鍵作用。

在這本書中,作者將和投資人一起剖析傳統技術交易訊號的盲點,共同探討交易時機的重要性,並且首度向投資人介紹交易時機的三大構成要素:終極指標、XTD指標、XJC指標。

當然!利潤是金融交易最重要的目的,但是在循環交易尚無法確定交出漂亮成績單之前,投資人仍然必須考慮自己是否具備堅忍的意志?是否耐得住人性考驗?否則,技術分析永無止境的循環交易,永遠只是理論上的紙上談兵。任何再完美的技術理論,如果只是看得到卻吃不到,還不如務實的面對它。人性與現實環境是必然無法迴避的因素,如何創造一個符合人性並且符合人生節奏的交易規則,才是技術派投資人必須思考的方向。

本書內容是作者多年領悟與心血的結晶,期待投資人在金融交易領域的節奏,也能像把握人生的機會一般,敏銳的等待機會來臨,時機到了才進場交易。換言之,「時機」會變成決定交易與否的第一關鍵要素。在對的時間點做對的事,正符合所有投資人對於人生的期待。如果過去你也曾經盲目的相信技術分析交易訊號,如果過去你不斷在技術分析操作中遭受挫折,那麼這本書的內容,希望能為你帶來新的領悟與獲利的機遇。

這一本書是 邱一平 先生繼 「技術分析‧靈活一點」、「頭部與底部的秘密」一口氣在 2006 年所著作的第三本書。 其實年前我就在書局看到「頭部與底部的秘密」該書,但甚不欣賞,也就沒有再去留心,後來是我的好朋友希望我能幫他寫「抓緊時機」書中的兩個指標程式,翻閱了書的標題與內容後,倒是覺得對於本書,個人倒就蠻能接受與認同,所以乾脆後來在「博客來書店」把三本書給全訂購回來。結果「抓緊時機」這本書缺貨,所以是前兩本先拿到。再仔細翻閱了「頭部與底部的秘密」,沒錯,這本書我真的就是不能認同接受,事實上,該書試圖想要去解釋「波浪理論」,本來就不容易。

倒是「抓緊時機」一書,我就非常認同本書作者在前言就直接提到,時機才是交易關鍵!
是的,想要掌握波段利潤的投機者,卻往往會陷入在 70% 的盤整期中,耗費許多隨機與頻繁的買賣,而造成人力與精力的耗損。這也是我為什麼一直無法認同程式交易的原因,因為,程式交易太容易會產生假象了。試問,一個交易人連續四次的虧損後,然後第五次可能全賺回來,但問題是:1.第五次那個時機剛剛你就是不在,沒有投入交易;2.前四次的虧損,投機人的精神力是否能持續屹立不搖呢? 我一直很懷疑這些… 如同本書作者所提:其實傳統流水式的交易模式,只是包裹著糖衣的技術陷阱而已。 我更是作者這句話:等待時機是穩健投資人明智的選擇,亂槍打鳥只是無意義的人力與財力耗損。因此【時機+訊號】不僅是技術分析的最佳境界,「時機」更是決定交易與否的第一關鍵要素

本書的作者邱一平先生,他的寫作風格讓我聯想到了 Larry Williams,我非常的欣賞與讚佩,邱先生也是與 Williams 大師一樣,會對現有的指標或現狀感到不足或困惑,然後他們會在心中有個假設的問題,再去找解決的方法(可能是寫出指標),具體化出來,並且透過統計數據來驗證。我覺得從本書收穫最大的,不是我又得看到了許多神奇的指標,而是邱先生做學問的方法,懷疑、提問、假設、解決、驗證。

邱先生很有創意,他從三個構面:天時、地利、人和,來解釋如何掌握時機。「天時」所提出的假設是,大盤終有「時間的循環」,當觀察到可能是「週期共振」或「均線共振」,也就是諸多均線糾纏一起時,也就暗示了可能下一波的循環即將出現(只是,不一定知道轉多或轉空)。這裡邱先生提出了兩個指標來代表「天時」,一個是 Larry Williams 在 1989 發表的「終極指標」;另一個則是邱先生自己對該指標修正其參數後的 XTD 指標。在「地利」方面,很有意思,邱先生利用整座山脈的觀念,來解釋登山客(投機者)目前所處的位置,是在山頭、谷底,還是鞍部。當然,這些是相對位置,而不是絕對,否則若能透過指標就可以知道大盤的頭部與底部,那不是神話嗎? 作者是做了一個技術指標綜合評分表,可能是 10 個,也可能是 27種,包括趨勢型、超買超賣型、成交量型等各類指標,並命名為 XJC 指標,來協助判讀波段目前是處在相對高點、還是在相對低點上。「人和」方面,當然就是看人氣,而人氣最重要的參考就是成交量了。邱先生發明了一個 XSV 指標,來改良傳統凹凸不平的成交量,並且加入了價格的考量,是屬於趨勢型的量能指標;另外他也針對如台指期並沒有成交量的考量,而運用了 Williams 的 WVAD 指標,來衡量當時的「人氣」的多空性。

這些指標都不難寫,但是我發現到,作者有「留一手」的感覺,並不是很大方。我在寫 XSV 指標時發生了問題,因為在書中作者所公開的公式,有兩個參數,N 與 N1,但他都沒有提這兩個參數的預設值為何,然後透過在「聚財網」發短信詢問,邱先生是很客氣,但也是很客套化,不是那麼願意告訴你參數為何;還有,我發現到我寫出來的指標有正負值,但書中的圖形卻都是 0 以上,我還以為我寫錯了,後來是邱先生有告訴我有負值是沒錯的,但如此的話,那書中那些 XSV 圖形是否有問題呢? 我是很懷疑那些圖形是邱先生早期所寫的「邱式量法」成交量型的指標,但與 XSV 不太相同。「留一手」的眾多邱式自創指標,尤其是在第一本書「技術分析‧靈活一點」更是明顯。這點沒有如 Larry Williams 的泱泱大師風範,是其可惜之處。

我把 WVAD 與 XSV 寫在 HTS 的程式碼公佈出來,也請有經驗的朋友們,看看 XSV 這方面的邏輯是否有問題?

//WVAD 指標
Parameters: N(14)
Variables: C(0),WVAD(0)

C = ((CLOSE-OPEN)/(HIGH-LOW))*Volume
WVAD = SUM(C,N)

Draw1(WVAD)
DrawBase2(0, "分界", DarkGray, 1)
//XSV 指標
//P%=((收盤價/N天平均價)-1)*100
//V%=((成交量/N天平均量)-1)*100
//XSV = ((RMA*N1)-N1天M% + 次一日M%)/N1

Parameters: N(30), N1(6)
Variables: P(0),V(0),M(0),RMA(0),XSV(0)

P = ((CLOSE/AVERAGE(CLOSE,N))-1) * 100
V = ((VOLUME/AVERAGE(VOLUME,N))-1) * 100
M = V-P
RMA = SUM(M,N1)/N1
XSV = ((RMA*N1)-M[N1]+M[-1])/N1

Draw1(XSV)

twt_day_line_070422

淺論資訊系統的分層結構

領域模型具體化到資訊系統的實現,必須配合現實的技術平台,包括系統廠商所提供的 圖形使用者介面(GUI, Graphic User Interface)的使用、開發與呈現(例如 Browser, Struts/ASP.NET, Web Server)、資料永續儲存的儲存庫(一般泛稱資料庫, Database,如 Oracle, MySQL)、應用程式伺服器(Application Server, 又可稱之為 Middleware, 提供包括如交易, 權限控管, 分散, 資源控管等系統服務,如 MTS, JBoss, WebLogic),尤其是為了能完整實現領域模型的建構與實現,更需要能讓程式開發人員有物件導向程式語言(OOP, Object-Oriented Programming)的開發機制,例如 .NET 平台所提供的 VB.NET, C#.NET,以及 J2EE 平台的 Java 語言,甚而 PHP, Ruby 等,也都是提供物件化的開發機制。只是後者與前兩者的差別在於,PHP,Ruby 等所提供的系統框架(System Framework)偏於 Web 端的開發,而 .NET 與 J2EE 則在UI端、中間層(Middleware)等均提供了適合於企業層級系統開發的 Frameworks,得以享有諸多便利的系統服務機制。

參考下圖,典型的所謂物件導向式資訊系統在設計時會分成幾個分層的結構與模組(modules)。

圖、資訊系統的分層結構
(點擊圖片鏈接看原圖)圖、資訊系統的分層結構

幾個主要的分層結構如:

  • 表達層(Presentation):圖形使用者操作介面,包括 Windows Form, Web Form, Java Swing 等,都是屬於系統廠商所提供給圖形介面開發人員來使用的工具與框架。
  • 中間層:領域物件模型主要所在的位置。為了應付功能性需求,UI 端的功能性呼叫(functional call)是透過中間層的控制物件(Co, Control Object)來控制與協調為完成該功能所需要相關領域物件互動參與的資訊與企業邏輯(business logic)運算;為了隔離外部系統(包括資料庫與外部系統)的變動性,控制物件會透過 邊界類型的物件(boundary object),如 永續性物件(PO, Persistent Object),連結資料庫系統、調變性物件(AO, Adapter Object),連結外部系統,如 Mainframe, Message Quese System, 其它需透過介面(interface)傳遞的系統等,來取得外部系統的資訊。而真正軟體的主結構,其實就是落在 Domain 物件(在中間層稱之為企業物件,Bo, Business Object)上,也就是源自於問題領域的概念性物件,以滿足應用程式的需求。所謂的軟體結構分析設計人員,其實就是應該要聚焦在如何作好領域物件的結構分析與設計!

    三種類型的物件(Control, Entity, Boundary),均會呼叫系統平台所提供的技術層級服務,瞭解平台特性的系統設計人員,會透過系統框架(System Frameworks)所提供的 APIs(Application Programming Interfaces),來呼叫取得所需要的系統服務。這些服務通常與應用領域無關,例如與資料庫之間的溝通介面或記錄程式執行與錯誤的紀錄(log),這些是系統廠商(.NET or J2EE),甚至是 3rd party 的工具廠商,所會提供的。請注意! 不要把這些類型的系統物件當作是要 「可重用(reuse)」 的對象,領域物件才是! 它們只是便於取得系統服務的工具物件而已,會隨著技術的規格變動而變動,甚至有更好用的工具出現,就要換掉原來在用、卻不會影響到系統的主結構。

  • 資料層:中間層領域物件在妥協於現實(記憶體容量與揮發性問題)的技術環境下,需把其狀態(state)永續(persistent)儲存於資料庫內,並且需要使用資料時再透過永續性的機制,將其取出至中間層的領域物件,運算取得結果,並送達至客戶端呈現。現今對於企業層級主流的資料庫系統是以 關連式(Relation)DB 為主,例如 Oracle, MySQL, SQL Server 等。同時關連式資料庫也是最有效可以完整表達問題領域的資料模型,它運用 E-R(Entity-Relationship)的分析技術,就可以呈現為資料庫的 Table Schema,而且其分析的手法與在中間層對於領域物件的分析方式是一致的,可以說 領域物件模型 與 E-R 模型 是 本是同根生(源自於問題領域),而兩者主要的差別只在於,E-R 呈現的是領域概念的資料層,而領域物件(企業物件)則再加上物件應有的行為(behavior),在軟體模型中,是稱之為操作(operation),而在程式語言中,則稱之為 方法(method)。
有無出版社想協助 HSDc. 出版軟體設計相關書籍的?

今年我與 Ringle,都打算整理近年來的一些文章與軟體設計教材的內容,出版成為實體書籍。本來的打算是與 Ringle 一起合著,不過發現到我的寫作與他的 Style 大不相同,其實就不要勉強,各出各的就好了。

其實去年我就打算出版書籍了,一方面是有些忙(藉口啦),另一方面,透過一位朋友的介紹,與某大國內知名出版社的一位編輯洽談。她提到啦,只要是軟體設計、UML 相關內容的書籍,都賣得很差,這從他們出版的一些軟體設計中文譯書的銷售狀況就可以得知。聽起來,好像是希望能出版一些工具類使用操作的書籍,這類型書籍在國內賣得比較好。

當時我可是就沒啥興趣了,國內 How-to 類操作性的資訊書籍,已經蠻多了吧,況且這些內容透過 google 都可以查得到,另外我也實在不擅長寫操作性的書籍。倒是今年想法有些調整,對於初學軟體設計的人來說,有實體工具的操作,佐以基本卻是正則的設計觀念,再加上實做的範例,包括 Model 與 程式碼的對照,未嘗不是一種學習的好方法?

有了這想法後,我也與 Ringle 討論過,他打算先出版一本 UML 觀念導引與實務操作入門的書籍,工具當然是以 EA(Enterprise Architect)為主,而且會延伸談到 EA 的眾多功能實做,包括許多軟體人員最關心的 Code generation,以及 MDA(Model-Driven Architecture), SQL DDL generation, Document generation 等。

內容已寫了十分之九,剩下的是一些細節上的修飾與補充,頁數預計約有 3,400 頁左右。

嗯,就是希望還有哪些出版社願意出版這類型的軟體設計書籍? 另外,除了偏操作性的技術書籍,也希望個人的一些對於軟體設計的想法,尤其偏以架構整體性的思考引導性內容,也歡迎出版社的編輯們能與我聯絡,討論一下比較符合市場的大綱與內容。

【公佈】五,六月份的軟體設計課程—台中場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
Page 1 of 179123456789101112...203040...Last »