EA(Enterprise Architect) 的產品特色

EA 的產品特色

涵蓋系統開發週期的軟體設計

物件導向的系統開發絕不僅僅是畫類別圖而已!現今的系統開發重視的是整個開發的週期。包括企業流程分析、以使用案例匯整需求、建立動態流程塑模、元件塑模、部署塑模、系統管理、非功能性的需求、使用者介面設計以及測試、維護等工作。

富有特色的系統設計

Enterprise Architect 是一個完整的 UML 分析與設計工具,涵蓋軟體開發各階段所需要的功能 – 從需求蒐集到分析階段、設計塑模、測試與維護。 EA 採用圖形介面 (Windows/Linux) 而且支援團隊協同開發,它不但可以協助開發團隊建構健全而易於維護的軟體,還提供高品質的文件輸出功能。

產品主要特色

  • UML 2.0 設計與建構
  • 建立使用案例、邏輯、動態、實體塑模
  • 依據開發流程客製化的擴充機制
  • 產出與 Microsoft Word 相容的高品質文件
  • 簡單易用
  • 成本低
  • 建立資料塑模、產生資料庫 DDL,透過 ODBC 由資料庫反向建立資料塑模
  • 團隊協同開發 (Professional/Corporate)
  • 支援 XMI 匯入與匯出
  • 拼字檢查
  • 由塑模產生程式碼,或是由程式碼反向建立塑模
  • –支援 Java, C#, C++, VB.NET, Delphi, Visual Basic, PHP

取得「EA(Enterprise Architect)」塑模工具的產品代理權

經過我們顧問團隊執行長 Steve 三個星期來的交涉,總算取得 EA(Enterprise Architect)的產品代理權。 😀

EA 的產品定位在 UML Modeling and Design Tool,可以整合在 Visual Studio.NET 及 Java Eclipse 的 IDE 開發工具。具有 “Code-generator & reverse” 功能。

詳細的產品介紹,可以參考 Sparx System Inc.

P.S.

  1. 關於中文的使用手冊,我準備撰寫一本利用 EA 塑模工具學習 UML 的入門手冊。
  2. EA 的功能絕不亞於 Rational Rose or Together,但其售價實在是~超具競爭力的…
    Corporate Edition(1-4 User license): US $225
    Professional Edition(1-4 User license): US $189
    Desktop Edition(1-4 User license): US $125

除了正式取得台灣產品代理權外,我們同時取得 VAR(Value-Added Reseller)的資格,亦即,可以使用 EA 系列產品於軟體設計的教育訓練與顧問輔導上。如虎添翼。 🙂

台灣區的 Reseller — HSDc. Co.,Ltd.
EA 的 Reseller 網站:


Enterprise Architect UML Modeling and Design Tool

“Enterprise Architect is a flexible, complete and powerful UML modeling tool for
the Windows platform. Providing the competitive edge for system development,
project management and business analysis; an object oriented CASE
tool for the full development life-cycle – at a sensible price.”

HSDc 的「刺蝟原則」

我為我們的軟體設計專業顧問團隊訂出核心的「刺蝟原則」。這也是未來我們核心團隊的定位!!

HSDc 的全名: High-quality Software Design Center(or Consultant)

  • 我們的使命:提升及協助軟體開發人員在軟體設計的專業技能及必備素養
  • 我們的目標:Keeping Software Soft !!
  • 我們的願景:成為大中華地區的專業軟體設計中心

HSDc's 核心刺蝟原則

淺論 XML 與 UML 的關係

組織 XML 的字彙(Vocabulary)

對於所謂的 e-business 而言,如何在企業與企業之間或企業與供應商(supplier)之間分享彼此的資訊以應付快速變更的 INTERNET 網路經濟是重要的課題。而其中的現實考量的因素就在於各自的資訊系統之間: ”如何交換資訊?”,以及,“要交換什麼資訊?”

”如何交換資訊?” 從早期某些廠商所推出的 EDI(Exchange Data Interface)解決方案,其實已經有為 e-business 用戶考量到這需求,但最大問題在於”沒有標準化”,而顯然 e-business 的交換資訊已是必然的趨勢,”標準化”的制訂也就必須由一國際公認的組織來推動了。

“XML”就是這個需求下所發明的產物。由 W3C 於 1996 年所制訂的規格,目的就在於期望可以在跨不同平台系統的前提下,能以一種標準化的文件格式,來達成 e-business 之間的資訊交換。統一、簡單、可自行定義標籤來依照需求產生不同格式文件、並易懂易學,正是 XML 規格制訂的目的。

使用 XML 規格來制訂文件的標準而得以使得 e-business 之間的資訊交換已是現今 e 化的公司所懂得來運用的共識了。資訊交換的標準化已藉由 XML 規格而能取得共識,再來另一個重要的課題就在於“交換什麼資訊?”

B-to-B 之間最大的價值當然要能分享彼此的“智慧”,而這個所謂的 “智慧” 不應只是單純的以資料為導向性的。將資料轉換為 “智慧”,顯然地,要能賦予這些資料更多的涵意(semantics)。要能做到讓企業與企業的系統與系統之間,人與人之間、人與系統之間均能有共識,並能瞭解其涵意,則必須要能規定在該領域(domain)之間溝通的字彙(vocabulary)為何?所以,也就是說,”交換什麼資訊?”,其所交換的內文(content)就是由這些字彙所組合而成的。

那麼,什麼是字彙(Vocabulary)?狹義的解釋,即是一串列的術語(list of terms)被使用在 B-to-B 相互的溝通。
然而,如果僅列出這些專業溝通的術語並做成如術語表等個別來解釋這些術語,其實是無法看出它更深一層的涵意(semantics),所謂的涵意,代表著術語與術語之間的關連,是否存在著結合(association)關係、一般化、特殊化關係,甚至字彙的分類等。這些涵意,如果沒有更嚴謹的定義,是不容易發現的。

例如,透過基本的字彙表,汽車組裝工廠與零售商之間可以知道要交換的資料有如汽車、引擎、運輸工具及方向盤、輪胎等資訊,但汽車是否屬於運輸工具的一種?汽車需配置幾個引擎,什麼樣型號的方向盤?可以配置幾個輪胎?如果汽車屬於運輸工具的一種,而飛機也是運輸工具,那麼,汽車是否也可以像飛機一樣在天上飛?所有這些的問題,是無法從基本的字彙表中來找到這些關連性的,而這必須靠完整的定義來表示字彙的涵意(semantics)。

XML 的 DTD 或 Schema規格可以來制訂字彙與字彙之間的關連性,但是,DTD、Schema 規格是以文字的格式用在應用軟體與應用軟體之間溝通的標準,單靠純文字的定義,並不適合用來讓人們來閱讀,人與生俱來就有靠豐富的圖像來理解抽象觀念的能力,顯然,要能表達完整字彙的意涵,單靠文字的定義是不夠的,所以,我們需要一套可以表達字彙的機制來同時支援對人的容易閱讀理解與應用軟體的處理。

UML(Unified Modeling Language),就具有這樣的能力,不僅可以捕捉應用軟體領域模型下的意涵,並且可以把這些字彙的完整定義對應至 XML 的字彙來直接交給 e-business 系統處理。UML 也訂出了標準的圖形表達語法(notation)而容易的被人們來閱讀。

{專案}jBpm 2.0 run on JBoss 3.2.6

搭載 jBpm2.0 的 JBoss 版本為 3.2.3。
若欲將 jBpm2.0 Deploy 至 JBoss3.2.6 下,則需修改配置的設定。
將 {jbpm.home}/build.xml 新增底下內容:

{jbpm.home}/build.xml

在 ${jbpm.home} 目錄下, 執行 ‘ant configure.jboss.3.2.6+’.
再依 jBpm “Getting Started” 的 “Installation” 的步驟即可順利地執行內建的範例:

  • start the jbpm configuration of jboss with ‘%JBOSS_HOME%/bin/run.bat -c jbpm’.
    in directory ${jbpm.home}/web run ‘ant deploy’. This will build and deploy the web application to the jboss configuration that we’ve just created.
  • in directory ${jbpm.home}/web run ‘ant deploy.process.archives’. This deploys the demo payraise process to the jbpm database in jboss. Since this is normally your first jbpm access to the database, this will also create the jbpm tables automatically.
  • surf to http://localhost:8080/jbpm

淺論「軟體系統整合」觀

Key abstraction:

  • 軟體廠商應該要能化被動為主動–不是只被動的順應客戶所提出的需求(Requirements),而是要能主動的幫客戶引導出潛在的需求,進而提昇其整體價值。
  • 放棄本位主義,以 同理心 站在客戶的角度來思考,系統整合如何能包容既有系統,保護過去的投資。
  • 軟體廠商要能確保其核心價值之所在,期能使之成為同質性領域內的 No.1。而系統整合,則是掩護核心價值的幕前推手。
    • 核心價值:汽車引擎、關鍵性零組件的專業設計–Domain Framework Design。
    • 系統整合:車體結構–軟體貨櫃。
    • 客製化(Customization):汽車組裝–客製化的產品。
  • 以快速 Prototyping 來展示系統整合的威力,提昇客戶的信賴度及增進團隊開發的信心。

前言:

「從 A 到 A+」一書提到:所謂的「刺蝟原則」代表著公司除了擁有核心事業、核心競爭力外,還必須在該領域達到頂尖的水準。

以此原則來檢視優秀的應用系統軟體開發公司要能在其應用領域的範圍內建構出頂尖水準的核心價值。就如同 Nvidia 在整個 PC 產業中,只專注在繪圖的領域,而開發出超高水平的 3D繪圖卡,使得其它的廠商無法與之抗衡。

與硬體產業較不同的是,硬體的週邊設備及組件均有標準的介面架構在以主機板為中心所組合而成的 PC 系統。而軟體應用系統的介面卻是相當的模糊,模組(Module)與模組之間,並不容易釐清標準的介面何在。有鑑於此,逐漸已有國際的組織如 OMG 在訂製所謂應用軟體標準的介面,例如有 Workflow 的 WFMC 標準,PDM 的 Enabler 規格等。

有了標準的介面,軟體公司更應該來擁抱標準,在標準界面的規範下,發揮「刺蝟原則」,提升其核心競爭的價值,全力發展 Business Framework 的設計,達到世界頂尖的水準。

為了提昇其核心價值(Domain Framework),直接所衝擊的是應用系統要能包容於客戶既有(Legacy)的系統,『系統整合』的最大考驗即在於如何跳脫出子系統之間繁雜的牽絆,能從以整體為出發點的架構觀點(Architecture View)來讓各子系統之間平衡的協調,而具有整體系統的和諧、生生不息的高度彈性。

『系統整合』這把大刀耍得好的話,則更會讓其核心價值達到 A+ 的效果。
所以…
「系統整合」是術 ;「核心 Domain Framework」是略。
「系統整合」是偏 ;「核心 Domain Framework」是正。

戰術與戰略的搭配,正道佐以偏道的支援,才能使得軟體公司達到「基業長青」的永續經營。

要能達成整體、和諧的「系統整合」,軟體公司全體的團隊(包括銷售及開發人員)要更能以大格局宏觀的角度,放棄本位主義(不以自家產品為整合的中心),化被動為主動,發掘及創造出客戶更巨大的利基。

「不行不能知,惟行而後乃能知其知之真偽與是非也」。

「系統整合」的最佳驗證即在於「實踐」,以具體的行動展示而能讓客戶信服,且提昇團隊內部的信心。 『Prototyping』是展示「系統整合」的最佳利器。

閱讀全文 »

軟體思維顧問

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

Personal