聊聊 DoDAF/MoDAF 規格與實作議題

上上個星期,應國防某單位要求,希望由我們利用 EA(Enterprise Archiect) UML 工具,藉由一個案例,來展示在順應 DoDAF 規格下,如何從架構規劃、到依循每一個包括 Operation 與 System View 的設計圖,以及又該如何導出到實作,尤以後者,對他們很困擾,一直不知道該如何將 DoDAF 設計與實作順利地橋接在一起。

其實原來是上個月初過去介紹的是 EA 的 UML 工具,因為 EA 其中一個 Plugin 產品,稱為 MDG for DoDAF-MODAF,兩者的搭配,應用的是 UML Profile 機制,可以充分完整支援 DoDAF 1.5 的設計規格。 說真的,工具沒啥好介紹的,況且席間諸多長官與教授們問最多的問題就是有沒有 “自動化” 的機制,可以從某一個 View 的設計圖,自動轉化到另外一個 View 的設計圖。這個… 我總覺得他們研究的方向會不會有問題? 我只能反問:1. 如果規則明確,例如 OV-2(作業節點連結) 轉 OV-5(作業活動流程)有很明確轉換規格的話,那麼工具當然可以支援。 (可想而知的答案是,當然沒有那種必然明確的規則) 2.能不能轉到程式碼? 這些我都覺得都不是問題耶,前提是有沒有那種確定的規則? 有趣的是,他們用來比較 EA UML 工具的是另一套 T牌、要價 100 萬的工具,也沒有支援他們 “心目中” 的自動化啊。 所以我開玩笑的說,好吧,把那個 T牌與 EA (EA+DoDAF Plugin 才 1萬初頭)的差價,用來委託我們開發那個自動化的 Transform 機制,保證可以幫你們生的出來,不過前提是要能給我們明確的轉換規則。 🙂

我可不會想賺工具的錢啦,要能懂得設計符合 DoDAF 架構規格的系統,要具備的是軟體設計基礎功夫的底子;要能有整體性的架構觀,要知道什麼時候該封裝、什麼時候該打開,分析系統的內部;要懂得如何把一個看起來好像很大的系統(關於系統的定義,可不一定指軟體系統,在這種大格局下,包括企業單位,都可能是一個系統),該如何大題小作;又懂得那個時候該具焦在某一個焦點上,然後小題大作。 這一種整體性的設計思維,正是架構規劃與設計箇中的竅門之所在。

我想要傳達的是,我們可以協助國防某單位,如何具備能具有規劃 DoDAF 架構設計的技能(Skill),與相關軟體設計的基礎功夫,以及所該具有的技術實作能力。當然就是以顧問輔導與教育訓練為主,如果可以的話,規劃成一個外包的專案更是好,然後從實作的過程中帶著學習,作中學的效果會更好的。 不過前提是,我們總是要能先證明我們懂得如何規劃這類超大格局符合 DoDAF 規格的系統,一般當然就是出個題目了,這一向是我個人最為意願的了,比較容易在短時間內取得雙方之間彼此的信賴與共識;也比較現實,會就會,不會的話早一點出局,最不囉唆了。 喔,還有,這是繼我十餘年前從志願役中尉預官退伍後,再一次能回到軍中,為國效勞的好機會呢,哈。 😀

由於國防某單位最近忙了些,等了幾星期,還是沒拿出案例讓我們來演練,所以只好我們團隊內部自行構思一個與軍事相關的案例。 所以呢,這個案例是沒有與軍事任何單位有關連(正因如此,才能拿出來公開分享),完全是充滿想像;也沒有軍事專家的協助,所以需求必然是謬誤百出。不過這也不是什麼困擾,因為我們要做的是如何能捕捉出 DoDAF 的架構規劃與橋接到實做階段的那個精髓之所在。只要未來能有軍事領域專家的協助,那麼就很容易可以調整修正,來符合正確的需求了。

整整花了四天的時間,投入了約 2.3 個人力,以一個我們所想像創造出來的案例,也算是規劃了一個類似 C4ISR(Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) 的聯合作戰指揮系統,透過偵測與防衛系統,發現到敵人即將進軍來襲時,是如何即時協同陸、海、空三軍暨後勤補給中心,來達成防衛作戰的目標。 包括了 Operation、System View 共約 17 張設計圖、再加上利用 .NET 程式碼來模擬諸多系統間的即時互動(透過 Web-Service)。 喔,甚至連那個表達 OV-1 的概念視圖,都還是請美工畫出來的呢,效果十足! 老實說,個人對我們團隊能在如此短的時間內,就能規劃出如此大的架構格局,甚至還產出程式碼來驗證架構的完整性。藉此而能解開 DoDAF 這個算是軍中資訊人員們的 “潘朵拉密盒”,可說是成就感十足,也算頗引以為傲。

ea_dodaf_demo
圖 1、 利用 EA-DoDAF 開發的 SV-1 設計圖

所完成的案例在上上星期至國防某單位的 Seminar 展示效果相當不錯! 在座許多高級長官以及教授們在會後的許多問題透過我們的解說,也算能得到合理的解釋。也讓許多中、上尉的資訊官們,見識到我們是如何從某一些 View 再轉到微觀(Micro)的實做階段。 由於沒有軍事機密等的問題存在(案例全都是想像的),所以到是可以藉由公開發表這一個案例,除了展示是如何實現 DoDAF 規格,並大概解釋一下每一個 View 的 精要(essential)設計意涵為何,同時也算是藉由此,來看看這種偏多個節點(Node)、多個資訊系統是如何做架構規劃的。

閱讀全文 »

{iThome 書評—15} Patterns Of Enterprise Application Architecture

副標題:企業層級的應用系統,是要能兼顧彈性、穩定與效能,而這需要具整體的架構設計觀與前人所提供解決方案的設計模式。

Patterns Of Enterprise Application Architecture Patterns Of Enterprise Application Architecture
———————————–
作者/Martin Fowler /著
出版社/Addison-Wesley Professional
ISBN/0321127420
Amazon 評鑑:四顆半星

內容簡介
The practice of enterprise application development has benefited from the emergence of many new enabling technologies. Multi-tiered object-oriented platforms, such as Java and .NET, have become commonplace. These new tools and technologies are capable of building powerful applications, but they are not easily implemented. Common failures in enterprise applications often occur because their developers do not understand the architectural lessons that experienced object developers have learned.

Patterns of Enterprise Application Architecture is written in direct response to the stiff challenges that face enterprise application developers. The author, noted object-oriented designer Martin Fowler, noticed that despite changes in technology–from Smalltalk to CORBA to Java to .NET–the same basic design ideas can be adapted and applied to solve common problems. With the help of an expert group of contributors, Martin distills over forty recurring solutions into patterns. The result is an indispensable handbook of solutions that are applicable to any enterprise application platform.

This book is actually two books in one. The first section is a short tutorial on developing enterprise applications, which you can read from start to finish to understand the scope of the book’s lessons. The next section, the bulk of the book, is a detailed reference to the patterns themselves. Each pattern provides usage and implementation information, as well as detailed code examples in Java or C#. The entire book is also richly illustrated with UML diagrams to further explain the concepts.

Armed with this book, you will have the knowledge necessary to make important architectural decisions about building an enterprise application and the proven patterns for use when building them.

The topics covered include:

  • Dividing an enterprise application into layers
  • The major approaches to organizing business logic
  • An in-depth treatment of mapping between objects and relational databases
  • Using Model-View-Controller to organize a Web presentation
  • Handling concurrency for data that spans multiple transactions
  • Designing distributed object interfaces

前言

每次研讀 Martin Fowler 的著作,直覺馬上就浮現出一個成語:天縱英才! 從極高度抽象的「分析模式(analysis pattern)」,對程式碼實作階段時的結構重整的 「重構(refactoring)」,以及本次書評所介紹的,關於企業層級系統平台設計議題的 「企業應用架構模式 (patterns of enterprise application architecture, 簡稱 PEAA)。 我是從來沒有看過有人可以如此像他這般,務虛與務實的不同層次都能是軟體業界的第一把交椅,著作的每一本書都是鉅作,然後又能在抽象分析、平台設計、程式碼實作等各層次整理出所謂的 “模式(pattern)”,供我輩軟體人員學習並再利用於現實的軟體開發工作。 前述的這三本書每一本都蠻厚的,但是 Fowler 也能寫出薄薄的那麼一本 「UML 精華(uml distilled)」,真正道盡 UML 的本質精髓,而熱銷全球數十萬本以上。 在我的心目中,Martin Fowler 有如神人一般,可以說是引領我在軟體業界持續奮進與學習的精神導師。

不僅如此,他寫的書,總是能以很淺顯易懂的白話來解釋看起來很深奧的道理。寫到這突然讓我想起,也算是有感而發,想當初我在啟蒙軟體領域的學習時,當然也會先從國內一些所謂的名家作者的著作來研讀。 可明明就是中文字,但閱讀起來就是很吃力,本想說是不是我真的有比較笨,領悟力差。 而後先從接觸 Fowler 的中文翻譯著作(感謝高水平的翻譯),耶! 我看得懂啊,甚至一看再看也不覺得煩,還能讀得津津有味,每一次的重讀又有不同的體會。後來再轉而看他的原文著作,雖然多少有些英文字彙的障礙,但是真的,絕對是比國內那些寫軟工書籍的作者,輕鬆易讀太多了,可以說閱讀 Fowler 的論著,就是一種享受。後來我才逐漸體悟到,太多所謂的軟工技術人,就是常賣弄太多 IT 的專業術語,而把單純的觀念表達的很複雜;還有一點,就是不容易從文字感受到這些 IT技術人 的想法,好像內容就是東拼西湊般,沒有真正自己主觀的想法。 的確,言之有物的好書能帶軟體人員上天堂;太多艱深術語、沒有自己體悟的書籍真的會讓你下地獄。

本次書評的主角,PEAA,所涉及相關軟體設計的議題可是相當廣泛,焦點是全擺在平台面系統設計的諸多議題,包括 分層結構、O-R(Object-Relation) Mapping、WebUI 的狀態控管、多人同時上線時的交易機制處理、分散式的設計策略等。 500 多頁,書本是蠻厚的,不過內容其實不會難懂 (前面說過,作者的風格就是總能以很淺顯的白話表達某一個所討論的主題)。 因為本書真的比較厚一些,我也不可能如同書摘般來記錄每一章的重點,在這裡我是想分享一下我是如何來閱讀本書的。

從書名思考本書的核心關鍵內容,找出自己的體悟

閱讀一本書籍,我總是會先從書名開始思考,本書的核心關鍵字有三個:企業應用程式(簡稱 企業AP)、架構(architecture)、模式(pattern)。 企業AP 會有什麼樣的特性,又與一般的 Web-based AP 有何差異? 我的心中大概就是浮現出大規模的企業AP特性有三:穩定、效能與彈性,三者缺一不可! 而因為有這些各個構面的考量,所以在設計議題上要相當慎重嚴謹,對於開發團隊甚或客戶而言,那種整體性的架構觀是要能有共識的。再來,由於構面與涉及的各類設計議題太多,從無到有是很辛苦的,是否可以借重 “前人” 的設計經驗來應用在現實的開發上,所以,所謂的 “模式”,包括分析、設計、乃至於實作類,期能可以協助我們來解決一再重覆發生的問題。

從關鍵字去推論目前心中的一些想法,其實也沒有什麼對或錯,心中先有個底,再去研讀內容,就會比較有感覺,也可以比較一下作者與自己想法上可能是相同也有可能是不同見解的落差。 本書從大綱的編排上,是分為兩大部分,第一部份是作者稱之為 “Narratives” 的敘述,就是我所說的,Fowler 總是以閒話家常的方式,來表達出他對某些主題的主觀想法。真的是很充分表達出他的觀感,但讀者又不會覺得有壓迫感或那種不是對就是錯的二分邏輯,實在高明之至;再來就是第二部分的 “模式”,這裡如同「重構」那本書一樣,是把每一個模式先歸納在某一個大類內,然後再給予一個名字,成為所謂的模式名錄。 本書我強烈建議的是,要先看 前言與介紹 的部分,價值非凡。 從前言你可以知道作者寫這本書的動機與所要討論的主要議題為何;而介紹也算是作者的一個導讀,也是各個主題的精要解說,甚而是會讓讀者知道可以先從哪裡看起,哪些地方又可以先略過不看,事半功倍。

前言與介紹的部分真的是太精彩了,讓我是逐字細讀來品味作者的想法。Fowler 說他是一位物件導向的狂熱份子,他也不說教,而是從敘述的過程中,讓讀者去瞭解到物件的主要優點在於對複雜的邏輯易於處理。 然後他又提到了一個很有趣的想法,他認為所謂的企業邏輯(business logic)是最沒有邏輯可言的,因為企業邏輯的複雜性,是無法被套用在任何的邏輯性模式,它就是被用在企業人(business people)來贏得商業利益的;任何一點的小改變都有可能贏得商業上的交易,而這也意味著,每一次的小改變都會導致系統的複雜度。為了應付這種 “瞬變” 的無邏輯性,企業AP 就是要被設計成很能禁得起變動,所以本書會討論的設計議題有六大項:企業AP的分層(layering)結構, 企業(領域)邏輯的結構, WebUI 的結構, O-R Mapping 的設計議題, 在 Stateless(無狀態)環境中處理 session(會談) state, 分散的原則。 在介紹這一部份,Fowler 提到了他對一些字彙(術語)的看法,我印象最深刻的就是他說他不懂架構該如何解釋,也不敢去冒犯這個詞彙 (我在想,如果連他都不敢去解釋架構的話,那還有誰能?)。 不過,他還是盡其所能說明架構對他的認知而言,第一個想到的就是 “分層(Layering)” (例如常談及的展示層、企業邏輯層、資料來源層)。 嗯,這裡我倒是也可以分享一下我對架構的看法,我以為架構是一種整體觀,整體需要時常凝聚各種不同角度的觀點,那是一種動態的調和。 另外,作者還有談及包括 效能(performance) 的設計議題,以及對於模式的應用想法。 Fowler 提到了,模式的關鍵點在於具體的實踐,是觀察人們於日常生活與工作中,觀察發現到某一個特定的解決方案;使用模式的關鍵是不能盲目去使用它,所以好像會看到同一個解決方案,但沒有一次是相同的。

設計是務實,是要能調和理想與現實的

500 多頁看來好像好多的內容,其實作者有說只要研讀第一部份即可。這一部份是屬於觀念上的引導,才一百頁而已,而每一個主題又都能分開去看它,其實讀起來並不費力。建立了在平台面設計議題的相關基礎知識與觀念後,就可以參考第二部分作者所整理提供的各類模式,例如 O-R Mapping 的相關設計模式,讓你知道如何建立 Data Mapper 的機制,來橋接領域模型的物件與關連式資料庫的表格。有需要再去看、去查這些模式,否則會很悶,這是作者對讀者的中肯建議。

先前我曾提過,許多所謂的物件導向基本教義派就是掛在無法把他們所認知那種理想美好的那一面(例如,建立純粹是領域的物件模型),給應用在現實的平台環境中。因為,現實上,沒有如此大的記憶體可以容納都是活生生的物件,所以需要給 “冬眠(hibernate)” 到如關連式的資料庫內;因為系統的資源有限,所以需要作資源的控管,包括資料庫連線與物件數量等管理;因為 WebUI 要服務更多廣眾的 Internet 用戶,所以被設計為 “無狀態(stateless)”,但是企業用戶需要的是 “stateful” 服務,如何把 stateless 作成像 stateful,就是考驗了設計者對資源與狀態控管上能否權衡的好。

這是一本專注在系統平台面設計議題的書籍,是討論關於如何把理想美好、能表達出軟體主結構的物件領域模型,橋接至利用現實系統業者所提供對企業層級的開發平台框架與應用伺服器等。對於想要瞭解企業層級的應用系統是如何調和彈性、延展度、穩定與效能等,本書絕對是必備參考的經典鉅作。

{iThome 書評—14} Business Modeling With UML: Business Patterns at Work

副標題:運用物件導向思維與 UML 語法,來保存企業最重要的資產。

Business Modeling With UML: Business Patterns at Work Business Modeling With UML: Business Patterns at Work
———————————–
作者/Hans-Erik Eriksson/Managus Penker /著
出版社/Wiley
ISBN/ 0471295515
Amazon 評鑑:四顆星

內容簡介
Until now, the Unified Modeling Language (UML) has been primarily used to design software, but should you use it to model your entire business as well? That’s the intriguing argument of Business Modeling with UML, a text that combines leading-edge enhancements to UML with some solid thinking about business. Written for any manager with some technical background, this book looks at the possibilities of UML used to model entire organizations.

The book makes a strong case for the advantages of modeling businesses in UML. With models, an organization can provide better software, define and implement new goals, and even decide whether to outsource certain operations. The Erickson-Penker Business Extensions for UML, invented by the authors and presented within the text, permit UML to document the entire business enterprise. This book shows how to model businesses, from business architecture to processes, business rules, and goals. Short case studies–for Web-centric and more traditional companies–are used to illustrate key concepts here.

Later sections of the book will perhaps take a little more background in software engineering to appreciate fully as the book presents a handful of business patterns, which offer reusable solutions to common problems (just like software patterns). The authors also look at how to leverage a business model to create better software.

In engineering, a new car is modeled and thoroughly tested on a computer before any physical prototype is ever built. As the authors point out, a business that has accurate models can test out new ideas cheaply and then adapt to changing market conditions quickly. This title makes a case that UML–a tool traditionally used by software developers–is ready to tackle the job. Read this notably informative and intelligent book to see the possible benefits of business modeling in UML for your organization. –Richard Dragan

Topics covered: Business modeling basics, UML notation and Erickson-Penker Business Extensions, class diagrams and powertypes, object diagrams, statecharts, activity diagrams and swimlanes, sequence and collaboration diagrams, collaboration and use case diagrams, component and deployment diagrams, stereotypes, business architectures, business processes, resources, goals, business rules, Object Constraint Language (OCL) and collections, business views and patterns, business goal allocation, business goal decomposition, business goal-problem, and software architectures

Review
“…excellent value for money.” (Computer Bulletin, September 2000)

前言

一般軟體設計人員以為UML 塑模 (modeling) 的範圍僅限於軟體資訊系統,其實不然,我們也可以把企業當成是塑模的對象,利用物件導向的手法,有效地來保存企業重要的資產。企業塑模的意義就是在於將企業當成是一個系統 (system),把系統視為是一個整體 (whole),我們就可以區分外部的需求觀點與內部的結構觀點。確立了系統範圍的好處在於可以找出系統 (企業)的主要參與者 (primary actor)與支援性的參與者 (supporting actor),前者會需要企業來提供整體性的服務,而它也往往是企業主要的經濟來源與命脈;後者則是企業需要其它關係企業、或子公司的服務支援,以提升企業整體服務的能力。然後,我們再透過觀察內部的組成結構,找出共用性的部分,藉以來支撐外部的需求。企業內部包括靜態的結構元素,可能會有內部工作人員 (internal worker)、軟體資訊系統 (information system)、企業內部經常溝通的術語、概念、實體 (entity)等;還有以及觀察在動態行為期間,為了服務需求,這些元素是如何互動的合作,而構築成所謂的企業流程 (business process)—包括了供應鍊 (supply chain)與內部行政事務的流程等。

可以發現到,應用物件導向分析與設計 (OOAD)的思維與技巧,以及利用標準的 UML 語法與視覺化的圖形表達,簡單又易學、幾乎沒有學習曲線,就可以將企業與軟體資訊系統用一致性的分析手法很平順地互補與轉移,而且可以協助從各種不同的角度來看待組織與企業,不僅只看流程 (這是比較傳統的紀錄方式),還能找出企業核心的本質 (結構)。可以說,企業塑模的價值遠大於軟體資訊系統。除了瞭解企業的運作與規則,也可以知道哪些活動或製程需要資訊系統的支援,如此可以提昇企業的效率與整體競爭力,這也是 BPR (business process re-engineering),企業流程再造的範疇,同時又可以成為專案委外 (outsourcing) 規劃與管理重要的參考依據。

企業塑模真的很有趣,同時又可以擴展軟體人員的視野與格局,不會只是單純僅考量到實作技術面的議題而已。那麼,又如何能建立企業塑模的正知與正覺呢? 我是強烈建議研讀本次書評的主角,它除了說明了 business modeling 的真諦,還教導讀者如何保有多重的觀點 (multiple views)來看待系統,以及如何利用物件以及流程,表達出各個觀點之下的設計圖 (diagrams),不是只有涵蓋理論而已,是絕對可以應用在實務的開發。本書可以說是作者的經典代表作,也是 OMG 系列強力推薦的實用叢書。

從架構與觀點著手,才能掌握整體,瞭解企業塑模的精要

本書我是買精裝硬皮的,質感甚佳,也比一般書籍的 size 大了些,而且看起來好像很厚,約 450 頁左右,這也使得許多讀者望而卻步。但其實印刷的字體還算大,且有著大量豐富的設計圖。我是建議不要逐字細讀 (那太辛苦且沒效率,而且往往很難堅持從頭看完),要能觀其大略。例如我會一開始先研究一下本書的大綱,大概知道一下每一章節要表達的重點為何;在我的心中建構了整體觀之後,然後就會先翻閱到與整體比較有關的章節,然後再看重點標題,當然,基本上圖形大概就可以讓你瞭解到該節想要表達的意義為何。而若是不懂該設計圖的意涵,再去佐以看看那些文字敘述的解釋,大致上瀏覽、能瞭解其意就可以了。我是覺得,本書的編排非常好,讓我閱讀起來是真的很輕鬆。

本書共分為十一個章節。第1章開宗明義,解釋了企業塑模的意義與價值,以及為何是利用 UML 設計與規劃企業流程、企業規則等。第2章是對 UML 語法的簡單介紹,諸如靜態結構的類別圖,以及表達動態行為包括活動圖、狀態圖等,尤其是活動圖,這會是本書後續所常用的。第3章最重要了,它揭露出企業架構的塑模手法。本書最有價值的一張設計圖,正是由兩位作者所自創的語法構成的,由於長得很像火箭,我常把它戲稱為 火箭圖 (其實正確的學名為 Eriksson-Penker Business Extensions,也可以把它視為是活動圖的擴展),用來表達鉅觀的企業流程。而事實上,它也成為我在輔導比較大型 ERP 系統開發時所常用的流程設計圖。一般我經常看到系統分析人員常常把流程畫得很複雜,細細麻麻的長得好像電路圖。其實這就是因為比較沒有層次的觀念,來適時地封裝不必要的細節。火箭圖正是用來表達更高層級的流程活動,它甚至封裝了活動圖所表達的業務流程,只表達出火箭的輸入、輸出、參考與支援的資訊,更有價值的是,它還凸顯出流程處理完之後所能達成的目標 (goal)為何。火箭圖會應用在如 ERP 常講的業務循環,當訂購循環處理完之後 (訂購火箭),輸出會轉到如採購循環或出貨循環 (出貨火箭)等。然後當要觀察每一個火箭內部的作業時,只要打開它,再利用活動圖來瞭解其活動的細節。層次分明、簡單呈現,這正是塑模的精要 (essential)。

第4章則是提及了上述所講的企業觀點問題 (business views)。我這裡再次提醒讀者,記得當把企業當整體單一系統時,起碼保有兩種觀點—外部的需求觀點 (用的角度);內部的結構觀點 (靜態的結構元素關連與分類,動態的流程互動行為)。第五章則是提及如何利用 OCL (Object Constraint Language)來記錄企業規則 (business rule),這倒不是絕對的方法,我個人本身就不太願意被限制如何表達這些規則。6~8 章則是揭露出各種對企業的設計模式 (business patterns),包括了結構、流程、資源、規則與目標規劃等模式。我會建議不用先去看它,等到有身體力行,應用在實務遇到一些想法或問題時,再回來翻閱,會比較有感覺。第 10 章是討論如何從企業塑模轉移到軟體架構的設計階段。我是覺得,本章並沒有一個很明確的轉移規則,算是一種觀念的引導而已。如何從企業轉移到軟體塑模,在我所實際顧問的專案中,是已經釐出一些規則出來。簡單的說,無論什麼領域 (domain),只要能“想辦法”轉移到資訊系統的使用案例圖,那實作上就絕對不會是什麼問題了。最後第11章,是提供一個案例分析,從企業願景 (vision),到結構的結構、行為與流程等,這些設計是如何被產出,以及這些產出之間的關係又是為何。

企業的資產,是由領域與軟體專家們的合作所累積而成的

從企業塑模的層級可以得知,領域專家 (domain expert)是可以與軟體專家合作完成在企業面的設計。對領域專家而言,流程的設計與規劃,是屬於 “企業流程再造的範疇,而對於軟體專家,是可以把 “企業當系統” 來看待,然後利用 企業塑模 的技巧,來協助企業流程、規則等的設計與記錄,真正企業的資產,就是將領域專家們的智慧,經過“企業塑模”所粹取之後的產出(Artifacts)!! 而後參考企業塑模的產出,就可以很清楚地瞭解與規劃,哪一些企業流程的活動,是可以經由資訊系統的協助,來達成自動化或減輕工作人員的負擔。

四述「博X來」訂購系統 — 撰寫使用案例需求陳述

從使用案例圖中,可以明確地定義出系統的設計範圍—系統需提供哪些服務(每一個功能點服務即為使用案例)、誰會來使用系統、系統是否需要其它系統的支援。這對開發團隊的每一個成員,能具有整體性的共識,是相當有助益的。 再來就是決定優先開發的使用案例,通常那是對系統的利益關係人(stakeholder)而言,最有價值的,優先開發! 屬於企業服務層級的系統,屬於商業交易型的使用案例,通常是最具有價值的。 以「博X來訂購系統」為例,《訂購商品》與 《結帳商品》兩個使用案例,會是該系統最有價值的需求服務,參考如下圖1。

圖 1、找出價值最高的使用案例優先開發
圖 1、找出價值最高的使用案例優先開發

對於需求分析師(requirement analyst,RA)而言,為每一個使用案例來寫出使用案例的需求陳述(use case description)才是最重要的。 使用案例敘述要能寫得好的訣竅就在於,只專注描述參與者(actor)與系統的互動對話;也可以這麼說,當參與者(一般為使用者)在使用系統上線的期間(session),RA 要能觀察出參與者與系統會有幾次的訊息傳遞(message passing),然後將之寫成具散文格式的動作步驟,到完成最後一個步驟時,系統即能滿足參與者使用系統的目的。

閱讀全文 »

{iThome 書評—13} Object-Oriented Methods—A Foundation 2nd Edition

副標題:紮實的物件導向設計基礎功夫是奠定系統彈性穩固的基石。

Object-Oriented Methods A Foundation Object-Oriented Methods A Foundation
———————————–
作者/James Martin/James J.Odell /著
出版社/Prentice Hall PTR
ISBN/ 013-905597-5

內容簡介
This book presents those concepts and techniques that support almost any system development approach–whether it involves computers, people, or machines. It considers object structure, object behavior and more advanced concepts such as composition, structural constraints, rules, using rules and diagrams, meta-modeling, and power types. Shows how to represent OOA constructs–modeling object structure, modeling object behavior, modeling state transitions and event diagrams, scenarios. Outlines considerations for design, discusses object-oriented programming, and considers object-oriented design and “instant” CASE. –This text refers to an out of print or unavailable edition of this title.

前言

截至目前為止的書評,我發現到並沒有真正介紹到適合於初學者的軟體入門書籍。大部分所介紹的還是偏向實用性的設計類叢書,即使如 Booch 那本 OOAD,雖然是理論基礎用書,但那本其實難度不低,用字又艱深。事實上,所謂的「物件導向」基礎入門書,要能寫得好,其實非常困難。作者除了觀念要相當透徹外,用字遣詞又要言簡意賅,把複雜的事情簡單的呈現,並不是一件容易的事。不過本次的書評— {Object-Oriented Methtods},兩位作者均同名為 James 的 Martin and Odell,寫出了絕對會是留名軟體青史的代表性著作。即使許多讀者會恐懼於閱讀原文書籍,但本書的英文用句,真的相當淺顯,不太懂文法也是可以讀起來毫不費力。誠如作者在前言裡所提及適合於本書的讀者程度,並不需要具備任何的前置知識,包括程式語言等。更為誇張的是,他們說書中諸多元素用語,已被用來教導約七歲年齡的孩童。這讓我想起,曾經在某購書網站看到,{UML 精華} 那一本書,適用對象竟然是寫為國小程度,哈,許多軟體人員真的是有夠汗顏的了。(其實那是網站筆誤的)

Martin & Odell 可是 OO軟體業界早期相當具知名度的先驅,他們的著作甚多,Odell 除了是物件導向社群的領導者外,也是 OMG UML 規格制訂的主席;而 Martin 看他寫作的資歷,你真的會嚇一大跳,從 1960 年代開始,我都還沒出生的時候,就已經出書了,至今已發表超過 100 本以上的專業書籍,包括軟體、資料庫、電傳通訊、即時性系統等,所涉獵的專業範圍實在廣泛。至今他除了在知名大學教授外,還仍茲茲不倦地研究與寫作。我真的好是佩服,這才是真正致力於軟體之道的大家啊。

清晰明確的術語定義,才能奠定 OO 紮實的基礎

本書共分為六大部分,剛好整整 400 頁,厚薄適中。最後一部份為附錄,除了語法的說明,還有一個訂購系統的分析範例。另外最值得推薦的是附錄D (Toward a Formalization of OO Analysis),是以論文的型態闡述了關於分類的關係、一般化/特殊化、功能/屬性/角色 等在分析過程中,經常會運用到的基礎技能。

第一章是對泛OO系統的概念性介紹。而在前兩部分章節,則為 基本OO的基礎知識。第一部份(2~11 )介紹物件的結構(structure)、第二部分(12~17)介紹的是物件的行為(behavior)。我覺得第一部份可以精讀,那真的是奠定最為紮實的理論基礎了。例如,我們經常說開發的是所謂的物件導向式系統,好吧,那你能否明確的說明出分析的物件從何而來? 再問一個更“俗”的,能不能定義出什麼是物件呢? 嘿,許多軟體人員還會愣住,無法回答出來呢。第二章開宗明義就指出,物件源自於概念(concept),“An Object is anything to which a concept applies. It is an instance of a concept. (物件是概念可以被應用的任何事物,它是概念所呈現的個體)”。 由此定義也可以得知,“物件”與“個體(instance)”這兩個術語,其實是具同義詞性質的。將“概念(concept)”作為認知的對象時,所產出的“個體(instance)”即為物件。但概念會牽涉到人們對於觀點、角度等認知,而會有不同的體認。例如站在遊客的角度,他所看到在森林裡面的樹木,是一個個的“個體”,會從樹木之外的角度來欣賞樹木的茂盛與宏偉,是一種整體性的認知;但站在植物學家的角度,他要研究組成樹木的結構元素,所以會把樹木分為“樹幹”、“樹枝”、“樹葉”、“樹根” 等多個組成樹木的“物件”,從結構的觀點來研究樹木的內部組成。這同時也就代表了,雖然到處都是物件,但並不是任意地將物件給“塞”入軟體系統內,物件導向的設計,是將問題領域(problem domain)的概念,呈現與對映(mapping)至軟體系統內,那麼,如何正確地捕捉(capture)問題領域的概念成為物件,就成為是軟體設計中,最為重要的技能與素養了。 你可以看看,當你能對這些基礎概念術語有很明確的定義時,你就可以很容易地衍生出諸多看來好像很複雜的呈象,但卻又不會違背這些基本的原則。我常戲說,練好這些軟體蹲馬步的基本功,才真正夠得上是武當名門正派的正宗內功!

當能分辦出 物件與類別的區別後,然後再進而瞭解類別之間普遍的三種關係:關連、整體/局部、一般化/特殊化 。透過關連,我們可以分析類別的相依性(dependency),以瞭解耦合(coupling)的程度;透過 整體/局部,我們可以封裝(encapsulate)細節,並以整體的服務呈現給 client;透過 一般化/特殊化,我們把相同的部分抽象出一般化類別,而把特殊或需要擴展的行為分別實現在特殊化的類別,而造成所謂多型(polymorphism)的效果(這也是程式語言中常稱之所謂的繼承)。再來論及的是物件的行為面。從對狀態(state)的說明,然後到狀態的轉移,而發生轉移的觸發(trigger)即是所謂的事件(event)。所以當然就會需要瞭解到事件的種類、事件的處理等,而這也是在當今元件化的系統,在動態期間常會需要用到的機制,在設計上也是相當重要的範疇。

第三部分(18~23)是OO進階的介紹,這裡提及到了限制(Constraints),也就是在類別關係之間如多重性是如何的表示;還有提到了規則(Rules)的表達,是如何呈現在設計圖上。我是覺得這類議題反而比較偏向細節性,倒是不一定要規範如此嚴謹,我是比較主張設計盡量活潑彈性一點,再慢慢地抓出團隊設計的共識即可,至於嚴謹性,倒不如在程式碼驗證即可。

第四部分(24~29)是關於物件導向分析(OOA)的說明。由於這裡涵蓋的議題太過廣泛了,諸如需求面的功能分析、結構面的類別設計、實作面的物件互動等,短短幾個章節不可能詳述清楚的。這裡我也只是大概瀏覽過即可,然後再對上述各個主題,從別的專書中再深入去探究。

第五部分只有一章(30),主題更是嚴肅,設計與實作的考量。開玩笑,一大堆所謂的物件基本教義派就是“掛”在無法將他們理想中的設計具體化呈現在現實的技術平台上,例如所謂的“O-R (Object-Relation) Mapping”,每種平台的實作都不一樣,那也是要相當去深入研究的;還有諸如交易控管、權限控管、分散式 …等,這些都是在實作上必然要面對的挑戰,10 本書都不一定介紹得完,遑論僅有一章?

軟體非“以用為本”

本書在 Amazon 也是頗受佳評的四顆半好書,印刷尤為精美,是我目前唯一有著紅與黑的兩色印刷書。除了 UML 設計圖外,還有許多生動有趣的插圖,佐以解釋主題的呈現。最好是不要抱著從“用”的角度來看待此書,那麼你可能會失望,因為它不一定能馬上讓你可以應用在現實的工作上。當你好奇於為什麼主流的程式語言都採用物件導向式的實作機制、為什麼系統分析/設計也強調所謂的 OO 思維,到底 OO 是要協助來解決什麼樣的軟體設計議題 …,還有當你真正有志於從事軟體專業之路時,本書絕對是修習基礎內功的必備聖典。

三論「博X來」— 訂購商品與結帳是否是同一個使用案例?

這一次倒不是要 “批判” 博X來的訂購系統,而是想藉由該資訊系統,來聊聊需求分析的設計議題...

我們知道,博X來的訂購系統,存在的最大價值,就是提供客戶「訂購商品」的服務,而為了滿足客戶最終能買到所訂購的商品,所以會有包括如「放入購物車」、「快速結帳」等程序。如果妳是一位需求分析師(RA, Requirement Analyst),那麼在分析以使用案例 (use case)為功能點單位 (functional point)的時候,妳會分析出 “多少顆” 使用案例呢 (只涉及到上述討論訂購商品的範圍)?

我經常思考這類的需求分析議題,也曾就該問題與其他資深分析師討論,有人認為是兩個,也有人認為是一個,當然也有人認為是三個、四個…等。 好像是見仁見智,沒有所謂標準明確的答案。 我是在想,能否有一種簡易判斷的 “準則”,來決定使用案例是一個或多個呢? 老實說,從諸多國外名家 (包括創始者 Ivar Jacobson)對使用案例的定義,我仍不容易釐出那個準則,所以我是想透過觀察使用案例的行為,來找出那個判斷的原則為何。

先觀察實體書店一般的購物程序:客戶走入書店,瀏覽與選擇欲購買的商品 (書籍),並放入購物籃內 (拿在手裡也算,代表已準備好欲購買的商品),並拿到櫃臺,結帳並付款。

所以幾個使用案例呢? 我肯定是認為一個:《購買商品》,因為客戶來這個系統 (實體書店)的主要目的就是 購買商品,而為了滿足該目的,他必須經常放入購物籃、結帳等程序,而且整個交易事件的程序 (從放入購物籃到結帳)是有持續的,約幾分鐘到幾個小時就可以完成 (注意此點)。關於傳統書店使用案例圖的表達,可以參考下圖1。

圖 1、實體書店購買商品的使用案例圖
圖 1、實體書店購買商品的使用案例圖

在使用案例圖的表達上,看起來好像是三個使用案例,其實本質上只有一個:《購買商品》。這裡利用《include》這個 stereo type,只是來凸顯《放入購物籃》與《結帳商品》這兩個子程序而已。

再回到博X來網路訂購系統來看,那麼是否訂購商品的程序與傳統實體書店的購買商品程序是一樣的呢? 看起來很像,都有 放入購物籃 (網路上稱為購物車) 與 結帳 兩個程序。只有一點不一樣,放入購物車 與 結帳 可以是兩個不同時間點的交易事件。什麼意思呢? 當客戶瀏覽商品資訊,若是看到打算購買的商品,就把它放入到購物車內,但是客戶並不需要馬上結帳,他可以等過幾天再決定是否結帳。所以很明顯的觀察到,這是兩個可以在不同時間點個別可以獨立完成的交易 (這一點與實體書店不一樣)。 (不過,這兩個交易事件好像又有些關連存在,要 結帳 前必須先有商品 放入購物車,關於此點,留待後述來討論。)

所以,我的觀察與心得是什麼? 我會以為,若是可以獨立在某個時間點可以完成的交易事件,我會把它就視為是一個使用案例。或者再用更通俗的一句話來說,就是參與者在使用這個系統,從上線到離開的過程,可以 “一氣呵成” 地來完成一個功能案例,該功能案例就可以獨立成為一個使用案例。 所以,博X來訂購系統對於 訂購商品 的主要目標上,會有幾個使用案例? 我是會把它切為兩個:《訂購商品》與《結帳商品》,參考下圖2。

閱讀全文 »

軟體思維顧問

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

Personal