茫茫網海中的冷日
         
茫茫網海中的冷日
發生過的事,不可能遺忘,只是想不起來而已!
 恭喜您是本站第 1664706 位訪客!  登入  | 註冊
主選單

Google 自訂搜尋

Goole 廣告

隨機相片
IMG_4446.jpg

授權條款

使用者登入
使用者名稱:

密碼:


忘了密碼?

現在就註冊!

軟工藝術 : [轉貼]從軟體架構師(Architect)的觀點來看軟體開發流程

發表者 討論內容
冷日
(冷日)
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15766
[轉貼]從軟體架構師(Architect)的觀點來看軟體開發流程
Kenming | 22 Mar, 2007 12:13(原文
前言

筆者多年來輔導過諸多不同類型與不同領域的軟體開發專案,本身的職務是擔任軟體架構師(Architect)與顧問輔導。架構師不是只負責技術面的 問題,更要兼顧到專案開發的過程中, 」人」 的互動所衍生而來的諸多問題,包括想法的歧異、見解的落差、不同的觀點與角度,甚至情緒問題等等,這些都需要與專案經理協同合作,一同來解決問題。

軟體的開發,最終目標雖然是 「完成高品質」 的軟體系統,但在進行階段過程中,所衍生出的兩大議題—專案管理(Project Management)與開發流程(Development Process),卻是首要需克服的階段目標。而該兩大議題,均是係以 「人」 為核心的考量,專案管理講究的是 「領導統御」、」人和」;開發流程重視的是 「調和 (凝聚團隊成員的觀點、角度,保持產出的一致性)」。專案管理的部分,筆者的角色比較不方便闡述(此一部份由專案管理者來論文比較妥當),倒是相關於開發 流程的議題,筆者倒是可以把藉由所觀察到諸多各形的開發型態,以及個人的一些研究、學習、思考與體悟的心得提供給讀者參考之,文中內容會是筆者比較偏以 「主觀意義」 的表達。

變動無常的軟體專案

軟體系統的專案開發,特別的是,需求往往不明確,更何況是經常處於變動中,所以導致專案的範圍與規模無法界定,連帶也引起時程無法估算(人月? 神話吧)。那麼,是不是開發成本的成本也無法預估,而往往也因為成本與時程的低估,更容易導致品質不佳、粗製濫造的軟體系統。

正是由於軟體別於如硬體產業的變動性問題,使得在其它成熟領域的專案管理經驗,並不容易全盤導入至純粹是軟體的系統開發上。若是把軟體開發當成是知 識與創新的產業,那麼一成不變且僵化的專案管理方式,並不妥當;除非是將軟體產業當成是軟體工廠,需求固定且明確,工作者(worker) 各司其職,負責實做局部的小功能,再由 「大一點」 的工作者,來組裝成大功能。請記得,這樣的方式,其假設前提是需求不容易變動,工作者也不太需要具備創新獨立思考的能力。


個人是很難相信需求不會變動,同時也認為正是因為軟體的多變性,才造就了更多的好機會,所以軟體的開發,不應該視善變為畏途,反而是把變動看成是理 所當然,更是多添了許多的好機會。我們所要作的事情只是,如何將變動抑制或收斂在某一程度可以被控管的範圍內,同時,學會如何在某一問題領域 (Problem Domain),重覆性、同質性高的軟體系統,來找出不容易變動的部分,成為系統的框架(framework),或稱之為主結構(Main- Structure)。而容易變動的部分,又是如何從主結構中抽離出來,爾後只花少許的 「工作量(effort)」,就可以輕而易舉的滿足客戶的需求。

很難嗎? 只要有兩個滿足的要素即可:一為開發的資源(包括成本與時程)多一點;另一為團隊對軟體的基礎養成與默契好一點。 但是好像要能滿足這兩點可真是困難,該如何才有可能達成這種 「夢幻」 的要件呢?

這就回到最現實 「人」 的因素了,要能爭取到多一點的開發資源,如果你沒有什麼誘因吸引老闆或業主(兩者可統稱為關係利益人, stakeholder),是不太容易的。專案的領導者總是要有 「實績」 才能讓關係利益人信賴並願意投入資源,而資源越多,當然專案成功的機會就更大。後文會提及,「反覆與漸增(I&I, Iteration and Incremental) 」,會是提升專案開發 「實績」 的好手段。

再探討另外一點,如何才能讓團隊成員對軟體的基礎養成與默契好一點? 默契要好,溝通必然要多,要能溝通多,當然就是要勇於把自己的想法給表達出來,而這些,則是有賴於專案領導者的支援與協調。總之,好的專案領導者是要能懂 得 「觀察」 在整個專案開發的過程中,成員之間互動所衍生出的種種問題,然後找出 「解決方案」 來謀和 「人」 的問題;另外回到最根本的是,畢竟這是軟體的開發,軟體的基礎養成功夫不足,當然也不太可能作得好軟體開發,軟體人員持續的學習與成長,更會是軟體產業的 命脈。

幾個可能是軟體開發流程的問題點

正是由於 「變動無常」 的軟體開發專案,有些人的想法是想要 「凍結」 住需求,然後依照固定不變的製程,一個階段接續下一個階段以循序式 (Sequential)的開發產出 (artifacts),例如預估一年開發期的專案,三個月的系統分析(SA, System Analysis)、三個月的系統設計(SD, System Design),六個月的實做與測試(Implement and Test),這樣的開發方式稱之為 「瀑布式(Waterfall)」 的開發流程,參考如圖1。


圖2、反覆式(Iteration)及漸增性(Incremental)的開發方式
圖2、反覆式(Iteration)及漸增性(Incremental)的開發方式

這樣有何好處? 開發時間是否會縮短? 其實並沒有,反而一開始開發時間會拉長,慢慢習慣這樣的開發模式後,才能倒吃甘蔗般,效率會提升上來。 反覆式最大的好處就是在於提早可以揭露潛藏的風險(Risk),而儘早處理掉。 如 果軟體開發人員必須要在數個月等需求分析、設計的階段過後才開始實作程式碼,一旦發現問題,要再回頭去修正,則必須花費相當長的時間來做修正;另外因為開 發人員之間可以在一個 Iteration 期間內就可以看到具體的結果(可執行的程式碼),他們可以維持良好的注意力在實際結果上,也能很快得到工作上的回饋(Feedback),當過程中有小錯 誤,開發人員可以回頭去修正,時間不會離得太遠。

反覆式流程的開發方式有下列優點:

  • 提早降低風險。
  • 較早能具有可視性(Visible)的進展(Progress)。
  • 較早能得到回饋,較可以得到使用者的保證(engagement)及適應性(adaptation),由此再精緻(refine)系統的設計,以更進一步契合使用者的需求。

  • 增加團隊的信心,並且可以一直持續學習。
  • 產品的整體品質較佳。

看來 I&I 好處多多,而且技術上其實很容易呈現,但是卻很難達成它。因為它同時會衍生出許多的管理議題,而最主要的一個因素就是: 人們往往無法忍受不確定性。 這是心理層面的議題,而個人是這麼認為,如果它是對的方向,那麼,你幹嘛太在乎與恐懼於現實上的困難? 這些問題本來就是應該克服的,包括文化、政治(沒錯,這是最大的問題)、溝通等等。以筆者在任職顧問單位所輔導的專案來說,這幾年是一直堅持 I&I 的開發,老實說,遇到的問題的確很多、也很辛苦,但同時也是持續在過程中,思考與找到解決問題的方案(Solution),這條路可是不能退縮、妥協與放 棄的。 」Do the right thing (往對的方式走)」 後,才有可能 「Do the thing right (把事情做好)」。

其中的不確定性,其實團隊可以就整體來建立共識,那個整體,就是以架構為中心。

以架構為中心的開發

以架構為中心,就是希望擔任各個角色的軟體開發成員,都能對開發中的系統有一致性(consistence)的全貌見解。專案中有架構師最好 (若沒有,也最好組成架構團隊),他必須具備關照系統整體觀的能力,也需要時時刻刻來 「調和」 各個角色的觀點與產出。擔任架構師者,可不是只偏往實做面的平台技術(這其實是技術長的執掌),還包括與領域專家(Domain Expert)的溝通,如何萃取其智慧,並得以抽像化(abstract),分離出善變的功能部分,與比較穩定、重用價值高的主結構部分;他同時也知道該 如何與 IT 平台的專家合作,將源自於領域知識的需求  軟體設計模型,具體實現在企業層級的平台(包括 .NET, J2EE 等);當然,更知道事情不可能一次就那麼順利,所以會透過快速反覆來取得開發過程中的回饋,據此來作為下一循環的修正,或也可能透過實做才知道設計的茫點 (或無法貼近現實),而回過頭來作設計的變更。請注意,所有開發的產出與修正,都是基於以架構為中心的考量,不會是偏頗於某一個觀點,而這些會是整個團隊 開發成員們都需要具有的共識。


以架構為中心,那麼具體的呈現會是什麼呢?參考下圖3,RUP 是提出 「4+1」 的架構觀點,筆者是把它再精簡一下,只用了三個觀點來代表架構的呈現,而每一個觀點,會有其開發產出 (artifacts),並可能成為另一個觀點的參考來源。這裡筆者直接舉小小的例子,來說明下圖的意涵。

圖3、以架構為中心、動態調和軟體開發的三大構面
圖3、以架構為中心、動態調和軟體開發的三大構面

需求功能面,代表的會是系統的外部觀點,是站在 「用」 的角度來看系統所提供的功能,而功能其實就是源自於使用者的需求,或者是領域專家的知識。 「新增訂購」、」查詢訂購訂購」、」查詢採購」 等,都是屬於使用者對系統的期望,也就是系統開發人員會來協助實現 (Realize)的。

而結構面,代表的是系統內部,會有哪些元素的互動合作,來完成系統所交付的功能。善於抽像的結構分析師,觀察 「訂購單(Order Form)」、」採購單(PurchaseOrder Form)」,會把兩者視為是 UI(User Interface) 的元素,而不是單一的物件;兩種表單都可能會共用到某些固定的資訊,然後分析找出了 「訂購(Order)」、」訂購細項(Order LineItem)」、」產品(Product)」、」項目(Item)」 等支撐系統,且再利用性 (ReUse)價值高的企業物件(Business Object)。
落實到現實的平台上,就需要考量到安全性(security)、交易(Transaction)控管、永續性(Persistence) 等現實的議題,尤其光以後者永續性 O-R(Object-Relation) Mapping的問題,就需要花上許多的功夫在系統底層細部設計的思考上,能兼顧到效能又要維持結構的完整性(Integrity),這就不是一件容易的 事。


從需求分析、結構設計到系統的實做(同時就會涵蓋到上述三個觀點),是要快速循環、走過一遍的。再次強調,每個 Iteration 的開發週期是以 「週」 為單位,最晚不得超過 2 週。如果將每一個功能單位(使用案例或功能點)規劃為三個Iteration,每一個循環要作的事可能是:

Iteration #1:確認使用案例所要完成的目標(Goal),建立結構與程式碼框架,找出從分析至實作的風險因子,建立溝通的管道。
Iteration #2:將實現使用案例的細節部分補足,包括規則、流程、欄位明細與資料型態等。
Iteration #3:作例外處理(Exception Handling)的考量與實現。

以架構為中心,必然會是學習型的開發團隊,相當重視對整體的關照與大量的溝通。溝通越形順暢,風險自然越低,開發效率也才有可能提升(這可不是透過 工具與自動化來做到的,它們僅是輔助用的機制,是建立在溝通順暢的前提下)。而這整個開發過程,就是要快速跑過整個涵蓋開發的觀點(功能需求、結構、實 做),再回頭來調整,修正,繼續再跑下一循環 ...

以架構為中心的開發流程正是具備了: 正回饋環路 (Feedback Loop) 的特質!

下一期的主題,筆者會來介紹「以架構為中心的主要設計產出」,並說明這些產出的應用與時機。

冷日
(冷日)
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15766
[轉貼]以架構為中心 的主要設計產出

{程序員邀稿}以架構為中心 的主要設計產出 (1)

2007-06-15

{程序員邀稿}以架構為中心 的主要設計產出 (1)

全文均刊登於北京「程序員(Programmer)」雜誌(台灣天瓏書局可購得), 2007 6月刊, p74~p77。 感謝朱海豔(helenna)小姐用心將文稿轉為 簡體專業術語,以及將 Model 重新美編,並轉為 簡體。

前言


筆者在輔導專案的初期,第一個時間點就要能抓出 系統開發的架構 全貌,請注意一下,系統不全然是指軟體資訊系統,也有可能是將企業當成是系統,並對其作需求分析、結構設計 ,此稱之為 企業塑模(Business Modeling)。這是牽涉到系統開發的範圍與層級,無論是企業或軟體系統,如何讓開發團隊所有成員與利益關係人(stakeholder),都能對待開發的系統有一致性的整體觀,這會是架構 師首重的工作與責任。

保持整體觀可不是只透過一種設計產出 就能讓所有人瞭解,道理很簡單,開發人員經常會有各自所關注的觀點,例如,需求分析人員關心的是系統能提供什麼功能與服務給使用者,他重視的是系統外部的功能需求;結構設計 人員關注的是如何找出 穩定的結構元素(經常是源自於問題領域的概念(concepts)),來支撐與應變外部需求的變動,他重視的就是系統內部的結構組成元素;實做人員當然就是重視能不能快速寫出 程式(program),同時還能有高效率與彈性,他重視的就是系統平台面(ex. .NET or J2EE)的實做與相關設計 議題;甚至,連客戶單位的高層管理人員,也有他重視的觀點,如資訊系統是如何協助與協助企業流程(Business Process)的自動化 …。

所謂架構 呈現的整體,並不是靜態不變的,而是持續性的動態調和,架構 師就是要能懂得如何調和 需求功能面、結構面與平台實作面 等多重觀點,凝聚各種不同的角色,還能有一致性的全貌見解。這可不是容易的事,軟體架構 不只跟結構與行為有關,同時也跟背景環境有關,包括:使用方式、功能性(Functionality)、效能、彈性、再利用性(Reuse)、可理解性(Comprehensibility)、經濟效應與技術的限制與取捨 … 等。


本篇內文,筆者是希望利用一些 UML 視覺化的設計產出 (artifacts),來說明這些產出 是如何來協助架構 師觀照與協調整體。這些設計產出 ,彼此之間有某種程度的關連性,並且要能保持一致性;架構 師也容易瞭解架構 的全貌是從哪一種角度來看待的觀點,然後知道如何在表象複雜的系統中,聚焦(focus)在系統廣度與深度的某一點,而不致偏離所探討的主題。 聚焦可是架構 師必具備的能力,知道焦點的所在,決定是否再細分下去探究內部的細節;還是因為成員之間常因細節爭擾不紛時,就知道應該再把討論的焦點層次再往上,才比較能取得共識。

以架構為中心 的觀點與產出

在前一期的專欄中,筆者提及了三個觀點來呈現架構 (關於該三個觀點的解釋,請參照上期內容),參考如下圖 1。

圖 1、表達軟體架構的三種觀點
(點擊圖片鏈接看原圖)圖 1、表達軟體架構 的三種觀點

以下列出 筆者個人經常在使用的設計 圖,用來呈現與解釋各種架構 的觀點。請注意,筆者並不是會全部用到所有的設計 圖,會視專案的規模與性質來決定該有哪些架構設計 ,有時甚至也會有額外、不一定非得是標準 UML 的設計 圖。重點還是在於:你要知道該設計產出 是在那一個觀點、表達的是那一個範圍與層次。筆者太常看到,團隊成員們之間,爭論的話題,根本就是不同觀點、不同層次,卻又不自知,難怪會經常導致溝通障礙的問題了。

[More:]

需求功能觀點:


  • 表達大範圍企業流程的Eriksson-Penker Business Extension Diagram
  • 表達單一企業流程的活動圖(Activity Diagram)
  • 表達系統範圍的使用案例圖(Use Case Diagram)

結構觀點:

  • 表達軟體主結構的類別圖(Class Diagram)
  • 表達元件、子系統之間介面(interface)溝通的複合結構圖(Composite Diagram)

實做觀點:

  • 表達資訊系統與套件之間相依的部署圖(deploy diagram)
  • 表達物件互動的循序圖(sequence diagram)

需求面的設計產出

需求面是從系統外部,一般也就是從使用者的角度來看待系統所提供的功能(function),從系統的角度來看時,也就是系統應該提供什麼服務(service)給外部的使用者。筆者一直在強調,既然是站在系統外部,那就是以 的角度來看系統,千萬不要在此階段討論到系統的 How-to 面議題,否則可是會永遠都分析不完,陷入癱瘓。那會是留待在結構設計 與實做的階段。

需求面主要 有兩個焦點的設計 議題: 企業流程(Business Process) 與 系統功能(System Functions)


企業流程對軟體資訊系統而言,是一個大的框架。從流程當中,我們才可以得知,哪些流程的活動(activity),需要資訊系統的協助與參與;活動與活動之間,是否也要透過資訊系統的傳遞轉移(transition)。UML 活動圖,是表達企業流程的最佳工具,不過它只能表達單一的流程(例如訂購流程),有時我想看某一流程(內有多個活動與條件判斷)結束後,又會轉移到另一個流程,這些流程之間的資訊流是什麼樣的關係。就是想知道更大一點範圍的業務流程,例如,訂購(Order)循環→採購(PurchaseOrder)循環→出 貨循環。那麼筆者還會使用非標準 UML 圖:Eriksson-Penker Business Extension,由於該圖形很像火箭,所以筆者常簡稱為 火箭圖(Rocket Diagram)。簡單的說,小 BP 用活動圖即可;而大BP,則可以使用火箭圖。

圖 2、表達訂購流程的火箭圖
圖 2、表達訂購流程的火箭圖


上圖是訂購業務流程的範例,它綜合了火箭圖與活動圖,也就是在火箭內部表達出 收到訂單之後訂購活動的流程。一般筆者是會另行以 一張活動圖來表達比較複雜一點的流程活動。火箭圖表達了事件(event)的觸發者(trigger),圖中就是 收到訂單 後即觸發訂購的業務流程;它也呈現了在該流程的進行過程中,有哪些會支援或提供的資訊,如圖出 貨與財務部門 均會支援(或者參與)訂購業務流程,而 訂購資訊 則是在流程中會使用到的資訊;筆者最喜歡該火箭圖的一點就是它能呈現出 該業務流程的目的(goal)為何。這重要,這可以讓利益關係人知道某業務流程所能呈現的價值與目的為何,而可以省略掉看諸多細節的活動。以 圖中的例子而言,訂購業務流程的目的即是可以處理客戶訂單與出 貨事宜。其實火箭圖說穿了,就是一種很典型的 I-P-O(Input-Process-Output) 表示法,但很有效,它可以封裝(encapsulate)流程內複雜的活動,而這些細部的活動,則由活動圖來表達比較理想。

圖 3、訂購流程的活動圖
(點擊圖片鏈接看原圖)圖 3、訂購流程的活動圖

上圖則是利用 UML 活動圖 表達了訂購的業務流程。在此筆者並不打算來說明活動圖的語法,這在一般 UML 入門書籍即可以看到。總之,活動圖很像傳統行之有年的流程圖(flow-chart),但有經過一些語法上改良與修正,例如增加了並行流程的表示法。


有件事可要注意,筆者在表達業務流程,無論是使用活動圖或火箭圖時,都絕對不會加入資訊系統的表達,也就是完全是先以 純人工作業的方式來看這些傳統業務流程活動之間的資訊傳遞,如此會單純化很多,也能夠比較能把焦點擺在一個個的活動。為什麼不要加入資訊系統呢? 因為在此階段,你不容易瞭解所要開發的資訊系統會有幾個,是的,這可是一個最常見的問題,軟體開發人員經常會把開發的系統當成僅有一個,且都是自行開發,是這樣嗎? 請看看上圖的訂購業務流程,假如需求有說到活動處理完畢需要電子簽核,那麼,會有哪幾個系統的參與呢? 是否有 訂購系統、出 貨系統、財會系統,還有工作流程系統(workflow),或者根本就只是 ERP 系統與工作流程系統呢?

如何界定有哪些系統的參與,不會是在畫業務流程圖時來決定的,因為你不能:1.決定哪些活動是由哪一個資訊系統來支援;2.不是所有的活動都需要資訊系統的參與,有些活動可能仍是人工作業。表達資訊系統的範圍界定與外部系統的互動,以及參與的使用者,利用使用案例圖是最佳的呈現。筆者看過許多的軟體開發單位,會直接從業務流程圖轉至系統的開發,這絕對不是一個好方法,除了上述提及的問題外,也因為這樣,而忽略掉了系統內部的結構分析與設計 ,而這才真正是支撐系統的彈性應變與穩定性的根本所在!

火箭圖與活動圖都是與資訊系統無關,它就是單純表達原來在企業上就會有的流程。經由一些原則與步驟,其實可以很容易地從活動圖中的活動,找出 局部功能觀點的資訊系統使用案例圖。因為使用案例可以明確地釐清系統範圍、系統操作的使用者、使用者操作系統的目的,所以,使用案例可以成為實現系統功能需求的最佳前導工具。

如何得知活動圖中的每一個活動是否需要資訊系統的參與? 基本上,就是針對每一個活動詢問幾個問題:1. 誰是主要 的參與者? 2. 需要系統提供服務嗎?若是,是由哪一個系統負責? 3. 系統提供什麼服務? 4. 系統是否需要支援的參與者(Supporting Actor)?若需要,是哪一個外部系統? 筆者曾在前幾期連載的內容中,有說明與範例,如何從企業流程(活動)圖找出 資訊系統的使用案例,可以參考。

使用案例圖(Use Case Diagram)可以說是筆者擔任架構 師的最愛,它最大的價值反而不是在釐清有多少功能需求,需求功能的釐清,是需求分析師會需要瞭解的,而架構
師反而關注的是系統的範圍。
下圖係利用套件(Package)圖來界定網路訂購系統範圍(System Boundary)。
界定了系統範圍,即代表框框內橢圓形的使用案例是我們負責設計 開發的系統,包括了軟體與硬體。而在框框之外的,則表示並非是由我們負責設計 的,例如表達外部系統的參與者,它是在我們的系統設計 範圍之外。

界定系統範圍最大的價值,乃在於,決定什麼是內?什麼是外?;什麼該作、什麼不需作。

下圖左邊棒形人偶圖示,包括客戶、財會人員、業務人員,他們是屬於主要 的參與者(Primary Actor),是站在從系統外面來看系統所提供的功能。他們關注的是自身的利益,是否系統能滿足他們的需求,這也就是為什麼筆者說使用案例是表達系統的局部功能的原因了。而外部功能的觀點是站在 用 的角度來看系統提供的服務,自然就不應該也不需要知道系統內部的實做面議題。使用案例圖易學難精,原因正是要讓 SA 不去考量到流程(那會是表達在活動圖)、不想到權限控管等實做面問題(那是系統內部的結構設計 或實作的議題),好像很困難。簡單的說,要能寫得好使用案例,就是要能表現出 無知,只看系統怎麼用就好了。

右邊棒形人偶圖示,包括 庫存系統、Banking 系統、會計系統,它們是提供服務給網路訂購系統,是屬於支援性參與者(Supporting Actor)。被歸為 外部系統,也就是並不屬於在系統的開發範圍內,系統的開發範圍是被界定在網路訂購系統內。對於 訂購商品 這個使用案例而言,它需要兩個外部系統的支援,一為 庫存系統,以 取得庫存商品資訊;另一為 Banking 系統,以 取得信用卡付款時的驗證扣款的服務。

只要是被界定為 外部系統者,則不需要去探究外部系統的內部結構,只要知道如何透過 介面(interface) 的呼叫連結,來取得相關的服務即可(再一次強調,這就是一種用的角度)。例如庫存系統可能是提供 Web Service 介面供外界呼叫使用,那麼訂購系統就要知道如何呼叫該 Web Service 的連結方式;而若是 Banking 系統只提供 Main-Frame 大型系統的連結介面,那麼我們就要知道,在實做層次的階段時,是如何連接呼叫該系統所提供的 APIs 了。


圖 4、網路訂購系統的使用案例圖
(點擊圖片鏈接看原圖)圖 4、網路訂購系統的使用案例圖

再來思考一個問題,庫存系統為什麼會是外部系統呢? 這就是界定系統範圍的重點了。有可能庫存系統已經存在,我們不需要再重新設計 一個新的庫存系統;也有可能在系統架構設計 時,就打算將訂購系統與庫存系統分成兩個獨立的模組(Module),讓彼此之間的耦合度(coupling)不致太過緊密,而可以形成可抽換(PnP, Plug and Play) 的高度彈性。但只要切開後,就需要定義明確的介面規格,這是非常困難的事,同時也要耗費更多的開發成本。一般以 專案導向(Project-based)的開發,會比較傾向是把兩者合成同一個系統(此時系統名稱就可能會改為 進銷存系統較為適合);而開發產品(product)者,因為會賣給不同的客戶有不同功能的模組,且需要順應客戶需求的客製化(customization),是需要有較高度的彈性,如此把兩者分開會是比較理想的。

筆者已經是將使用案例圖當成在架構設計 規劃時,用來表達多個資訊應用系統整合時的重要工具。但筆者在此階段從來不提資料庫系統,原因在於系統整合講究的是介面的整合,而不是資料的整合。資料庫是被封裝在每一個應用系統內部的私有倉儲(private storage)了,例如 訂購系統、庫存系統、會計系統 都各有自己所屬的資料庫,資料庫之間,絕對嚴禁直接連結,否則即會違背了整體架構 的設計 ,那也不用再談所謂的彈性與延展性了!

※ 延伸參考:
o {程序員邀稿}
從軟體架構 師(Architect)的觀點來看軟體開發流程

前一個主題 | 下一個主題 | 頁首 | | |



Powered by XOOPS 2.0 © 2001-2008 The XOOPS Project|