第一章 軟件架構設計思想與體系創建
第一節 軟件架構師的角色和應掌握的知識體系
一、軟件架構
軟件架構（software archiecture）的一種定義是這樣的：
架構是一組有關如下要素的重要決策：
軟件系統的組織，構成系統的結構化元素，接口和它們相互協作的行爲的選擇，結構化元素和行爲元素組合成粒度更大的子系統的方式的選擇，以及指導這一組織（元素及其接口、協作和組合方式）的架構風格的選擇。
軟件架構可以有多種定義，不管對軟件架構如何定義，所有的定義都有一個共同的主題，那就是必須考慮諸如原理、組織、風格、模式、職責、協作、連接、系統的動機和主要子系統等大尺度方面的問題。
軟件架構實際上是兩個層面的事情，一個是設計構造一個完整的軟件系統，這裏的架構也稱作軟件體系結構（Software Archiecture）。另一個層面是構造一個統一的共享的框架或者稱架構（Framework），這種架構事實上是系統的一個基於服務的層。
軟件架構在整個軟件開發過程中，是處在軟件體系結構設計階段（設計），它的必要的輸入，是來自需求工程（分析），而它的輸出，是實現設計（編程），因此這是一個承上啓下過程節點。
在軟件開發中，架構既可以是名詞，也可以是動詞。
作爲名詞，架構包括上面所定義的內容。
作爲動詞，架構一部分是調研，一部分是設計，更清晰的，是架構調研和架構設計。
架構調研：
是指識別對系統存在或可能存在重大影響的功能性或非功能性需求（特別是非功能性需求），例如市場趨勢、性能、成本、維護和系統演進等。廣義上，是對系統的重大設計決策有特別影響的需求進行分析。
架構設計：
是對軟件、硬件、網絡、運營、政策等軟件設計中的需求和要素進行決策。
在統一過程裏面，架構調研和架構設計統稱爲架構分析。
軟件架構設計是一個系統工程，它需要系統構架師有很寬的知識面，從需求分析、架構設計到類設計甚至代碼實現都需要有透徹的理解，這之間的關係是你中有我我中有你，是不可能截然分開的。
在這個課程中，我會站在相對抽象的角度，對軟件系統設計的思想和方法做一些討論，這些觀點，也是不少資深系統架構師經驗的集合。必須說明，軟件系統設計的方法不是一個僵化的規則，我表達的一些觀點你也不一定贊成，這不要緊，關鍵是在實踐中實事求是的摸索規律，從而找出一些符合實際的方法來。
二、軟件架構師的角色
儘管對軟件架構師的角色有這樣或那樣的定義，但大體上下面幾個職責是必需的。
1、技術負責，解決方案的提供者
2、與項目經理合作，制定計劃，決定成員，組織團隊
3、保證項目按計劃和走向完成
由於設計是由需求驅動的，所以，掌握需求分析的技巧，是一個好的架構師必備的能力。
三、軟件架構師最難處理的問題
1、不是做什麼，而是不做什麼
2、不是從純技術的角度來考慮整個項目
3、預見客戶走向，早期決定技術研發
4、不能使用時髦但不可靠的技術
四、如何成長爲一個好的系統架構師
架構師必須關注需求、分析需求，有人認爲架構師只是在需求出來以後，把它的實現模型做出來就行了，真要是這樣，那做一個架構師未免也太容易了。
事實上，現代迭代開發所有的驅動力都在於需求變更，如果架構師不關注需求，不關注和用戶的討論和溝通，那是很難設計出真正有用的東西來的。
軟件架構設計是一個非常嚴肅、細緻、敏感而且困難的工作，必須一點一滴認真做起，紮紮實實的努力，實實在在的積累經驗，尤其是在失敗中積累經驗，這是一個軟件架構師成功的必由之路。
爲此，我們需要注意下面幾點：
1、首先必須是一個好的程序員，技術上要強
2、知識結構：對象的觀點，UML，RUP，設計模式
關鍵不是懂得了原理，而是靈活融合的應用
3、系統的觀念：分析能力，把握抽象的能力
4、溝通能力：與客戶溝通能力，與項目其它成員的溝通能力
5、知識面要廣，把握行業流行趨勢，但不要趕時髦
6、靈活機動，不能教條
五、幾個觀點
1、要承認軟件是不完美的
2、要承認需求是不完全的
3、關鍵是擁抱變化而設計
4、各種性能標準，什麼是架構師最關注的呢？
5、架構師最重要的素質：把握重點。
注意：靈活的把握，實事求是的分析，
善意和把握重點的溝通，
有先見性的設計，
這是一個優秀的系統構架師活的靈魂。
第二節 軟件分析和設計的方法學問題
由於架構設計的源泉來自於軟件分析，不同的分析與設計方法，將會帶來完全不同的架構思路。從方法學的角度來講，目前分析和設計方法主要分爲面向過程的方法與面相對象方法兩種。
一、面向過程的方法
面向過程方法又稱爲結構化方法，起源於20世紀70年代，主要由面向過程分析、面向過程設計和麪向過程編程三部分組成。
面向過程分析：幫助開發人員定義系統需要做什麼（處理需求），系統需要存儲和使用那些數據（數據需求），系統需要什麼樣的輸入和輸出，以及如何把這些功能結合在一起來完成任務。面向過程分析的主要工具是數據流圖（DFD）,這是一種顯示面向過程分析中產生的輸入、處理、存儲和輸出的圖形模型。
在現代面向過程設計中，也引入了事件的概念。
面向過程設計：面向過程設計是爲下列事務提供指導：程序集是什麼，每個程序應該實現哪些功能能，如何把這些程序組成一張層次圖。面向過程設計的主要工具是結構圖，這是一種表達程序模塊層次的圖形模型。
面向過程編程：具有一個開始和結束的程序或者程序塊，並且程序執行的每一步都由三部分組成：順序、選擇或者循環結構，實現這種思想的最典型的語言就是C。
整個面向過程設計的根本目標是：把複雜的系統分解成簡單模塊的層次圖。
二、面向對象的的方法
面向對象的方法由面向對象分析（OOA）、面向對象設計（OOD）以及面向對象編程（OOP）三部分組成。
面向對象方法與面向過程方法根本區別，是把信息系統看成一起工作來完成某項任務的對象集合，而對象是系統對消息作出做出響應的事物，所以面向對象方法中最值得關注的不是它該做什麼，而是它如何做出反應，也就是消息，這是和麪向過程方法的根本不同。
面向對象分析（OOA）：定義在系統中工作的所有類型的對象，並顯示這些對象如何通過相互作用來完成任務，主要工具是統一建模語言（UML）。
面向對象設計（OOD）：定義在系統中人機進行通訊所必需的所有類型的對象，並對每種類型的對象進行細化，以便可以用一種具體的語言來實現這些對象。
面向對象編程（OOP）：用某種具體語言（C++、Java、C#、C的對象模塊等）來實現各種對象的行爲，包括對象間的消息傳遞。
這裏的關鍵是類圖：用面向對象的方法顯示系統中所有對象所屬類的圖形模型。
面向對象的方法起源於20世紀60年代挪威Simula編程語言的開發，80年代建立了整體框架，90年代由於C++的崛起和UML被廣泛認可，逐步成長爲一種主要的和現代的分析和設計方式。
面向對象的方法和傳統面向過程方法有很大不同，它的思維方式不是以設備結構爲基礎，而是利用可感知的對象來思考，對人而言，這是更加自然或者直觀的。但是，如果只是把傳統概念簡單包裝一下換成對象方法（比如封裝），並不能得到實實在在的好處，反而使OO很難理解，面向對象的方法關注的是事件、重用和繼承，關注的多態，它自己有一整套獨特的思維方式，這和麪向過程方法是根本不同的。
90年代中期以後，這種關注帶來了許多新的思維，有代表性的就是設計模式的提出，設計的質量更高，系統的優化空間更大，這就是說應用面向對象的方法，將會給我們提高設計質量帶來巨大的好處
由於面向對象方法把對象看成系統對消息做出響應的事物，這種與面向過程完全不同的看待計算機系統的方法，必然導致完全不同的分析、設計和編程方式。有人認爲，學會了UML幾張圖或幾個符號，就會對象方法了，這是個誤會，UML只是一個表達的工具，關鍵是在什麼層面上去思考。
有個問題，是不是使用面向過程的程序語言（比如C），就一定要使用面向過程方法，實踐表明並不是這樣的，面向對象更多的是一種思維方式，面向過程的語言只需要略加改造就可以應用這種思想（繼承、封裝、多態），國外在這些方面有很多成功的案例和討論，國內在一些大型嵌入式項目中也有很好的嘗試。
一般來說，面向過程技術與面向對象技術是不能混用的，因爲這兩種設計技術基本思想是完全不同的，基本的原則也是不一樣的，面向過程設計提供的是系統功能的體系結構，而面向對象技術是建立一系列交互對象的體系結構，思維不同，方式重點也必然不一樣，這點是需要說清楚的。
在這個課程中，我們將沿着軟件分析和設計的過程，重點研究面向對象的方法，同時與面向過程方法對比着，把思想方法和工作方法討論清楚。
第三節 在信息技術戰略規劃（ITSP）中的軟件架構
一、利用信息技術戰略規劃整合客戶需求
信息技術戰略規劃（ITSP）的核心思想簡述如下：
在信息時代，知識經濟下，正確的結合IT規劃，整合的核心競爭力，在新一輪的產生、發展中取得更大的市場競爭力是必要的。
信息化的問題首先是企業管理層概念的問題。企業管理層的重視，和對信息化的高度認同是企業信息化的關鍵所在。當前國內很多企業管理層很關心資本運作的問題，而對很多國企業而言，管理層最關心的是扭虧增盈。信息化建設投入大、週期長、見效慢、風險高，往往不是企業需要優先解決的問題，導致管理層對信息化的重視程度不夠，無法就信息化建設形成共識
對企業管理信息化帶來的管理模式變化不適應，又抵觸心態，或者僅是爲了形象問題，趕潮流搞信息化。國家提出信息化帶動工業化，信息化成爲一種時髦，信息化工程往往成爲企業的形象工程。
有些公司缺乏統一完整的IT方向，希望上短平快的項目，立竿見影，跳過系統的一些必要發展階段，導致系統後繼無力，不了了之。20世紀末的電子商務熱潮充分說明了這個問題。
有些公司對信息化建設的出發點不明確，在各個方案廠商鋪天蓋地的宣傳下，不能很好的把握業務主線，僅是爲了跟隨潮流，既浪費了資源，同時也對後繼的信息化造成了廖不良的影響，甚至直接導致“領導不重視”這樣的後果。
如今國家正在大力推廣企業信息化。然而人們大多從技術角度來談論信息化和評價解決方案，他們往往脫離了企業的實際需要，以技術爲本是不能根治企業疾病的。企業依然必須明確自己的核心競爭力。明確一切的活動和流程都是圍繞讓核心競爭力升值的過程。IT規劃意識如此，必須也企業核心、業務爲本。再結合公司的實際情況。開發自己需要的系統。
信息化的建設難以對投入產出進行量化，難以進行績效評估，CIO們無法讓企業管理切實感受到信息化帶來的直接效益——經濟效益、社會效益。
戰略規劃是一套方法論，用於企業的業務和IT的融合以及IT自身的規劃。必須滿足如下要求：
1.先進性：採用前瞻性、先進成熟的模型、方法、設備、標準、技術方案，使建議的企業信息方案既能反映當前世界先進水平，滿足企業中長期發展規劃，又能符合企業當前的發展步調，保持企業IT戰略和企業戰略的一致性。
2.開放性：爲保證不同產品的協同運行、數據交換、信息共享，建議的系統必須具有良好的開放性，支持相應的國際標準和協議。
3.可靠性：建議的系統必須具有較強的容錯能力和冗餘設備份，整體可靠性高，保證不會因局部故障而引起整個系統癱瘓。
4.安全性：建議規劃中必須考慮到系統必須具有高度的安全性和保密性，保證系統安全和數據安全，防止對系統各種形式的非法入侵。
5.實用性：規劃中建議的系統相關必須提供友好的中文界面的規範的行業用語，並具有易管理、易維護等特點，便於業務人員進行業務處理，便於管理人員維護管理，便於領導層可及時瞭解各類統計分析信息。
6.可擴充性：規劃不僅要滿足現有的業務需要，而且還應滿足未來的業務發展，必須在應用、結構、容量、通信能力、處理能力等方面具有較強的擴充性及進行產品升級換代的可能性。
爲了實現這樣的規劃，我們必須注意到，軟件設計既是面對程序的技術，又是聚焦於人的藝術，成功的軟件產品來自於合理的設計，而什麼是合理的設計呢？
一個軟件架構師最重要的問題，就是他所設計的產品必須是滿足客戶戰略規劃的需求，能夠幫助客戶解決實際問題的，因此一個合理的設計，首先要想的是：
Who：爲誰設計？
What：要解決用戶的什麼問題？
Why：爲什麼要解決這些用戶問題？
這是一個被稱之爲3W的架構師核心思維，如果這個問題沒搞清楚，就很快的投入程序編寫，那這樣的軟件在市場上是不可能獲得成功的。
Who? Waht? Why? 這三個問題看似簡單，但實際上落實起來是非常困難的。我們經常會看到一些產品，看似想的面面俱到，功能強大，但爲什麼最終沒有得到用戶的廣泛認可呢？一個專家感覺非常得意的東西，普通的使用者未見得感覺滿意，這些情況在我的實踐中屢見不鮮，即使一些知名的公司在設計的時候，往往都不能很好地把握，這足以證明我們必須下功夫來面對它。
那麼，我們該怎麼來做呢？
很重要的問題是，設計的目的是爲了生存，設計的源泉是來自於用戶，滿足用戶的需求，能夠幫助客戶產生可度量的價值，又便於用戶使用，減少維護和培訓的資源消耗，而且製作生產工藝儘可能簡單，這就是設計之本。
二，錯誤設計的幾個原因
但是我們的設計中，違背這樣的原則的情況還是時有發生的，大致來說有這麼幾個原因。
1）新穎的技術成爲設計之本
不少設計人員迷戀於新穎的技術，總是傾向於用剛剛流行的新鮮技術來設計他們的軟件，他們總是認爲只要用了新的技術，就能夠寫出最好的軟件產品，用戶也一定會喜歡。
其實這是個誤會，人們購買軟件產品，並不是購買它的技術本身，而是爲了他的需求來購買，也就是說是市場決定了產品的設計，而不是技術決定產品設計，這一點千萬不要本末倒置。
事實上美國每年倒閉的高科技公司，90%並不是因爲技術落後而倒閉，而是因爲沒有正確的瞭解市場，換句話說，我們不能因爲個人的興趣而設計軟件。
2）把軟件當成自我表達的方式
由於軟件工程師屬於高智商羣體，熱衷於發明，熱愛技術，這樣往往不自覺地把軟件設計當成自我表達的方式，用於表達自己的智慧，以及表達自己對於技術的理解。
這樣的結果往往聰敏反被聰敏誤。
原因很簡單，市場的規則往往決定了產品的命運，而不是技術本身。
我們應該對市場和已有的產品作爲模型來調查，搞清楚用戶對產品的要求到底是什麼？產品的設計應該來自於市場的調研，而不是對新技術的激情，新的技術只有用在合適的地方纔有生命力，而不應該是一種無目的的自我表達。
新技術的採用只有在需要的時候纔有意義。
3）把軟件設計成萬能的
最可怕的是，把軟件設計成萬能的，幾乎能滿足一切需要，而忽略了技術上的可行性。
沒有進行可行性分析的軟件產品，通常會導致軟件的失敗，而且浪費大量的人力物力。一個技術上不成熟的產品流入市場，必將被市場淘汰。典型的例子是日本的第五代計算機、語音翻譯、人臉識別等等，聽着好聽，這些公司都倒閉了也是事實。
4）過分強調功能，而不是使用的方便性
給用戶做一件事情，稱爲“有用的”；
如果一個功能是用戶可以方便的使用的，稱爲“可用的”；
這是兩個完全不同的概念。
如果過分強調“有用的”概念，把算法、系統等等放在思考問題的首位，而忽略了方便性，這樣的軟件往往並不能被用戶接受。
軟件可用性往往和對用戶心理研究是緊密相關的，具體落實在界面設計上，在軟件工程界往往有一種輕視界面設計的傾向，其實這是錯誤的。
現在的問題在於，很多設計者往往只注意需求文檔甚至文檔格式，但不注意挖掘需求過程用戶所表達的思想內涵，這也是導致不恰當設計的一個重要原因。
三、利用ITSP提升企業競爭力的案例陳述
泛泛地說體系結構設計的理念是沒有用的，所以整個課程貫穿一個簡化的TB公司電源設備銷售服務信息系統的案例，這個簡化的例子可以認爲是在信息技術戰略規劃（ITSP）項目中一個構思，根本的木的是企業利用信息化技術提升自己的銷售業績，信息化技術使企業利用信息系統對自己的業務過程和行爲方式作充分改進成爲可能，這種可能引發了企業建立信息化體系的強烈需求。
通過這個案例的研究，我們還可以發現更多的方法學知識。
1，問題陳述
在研究這個陳述的時候，請體會這裏是如何體現Who? Waht? Why?這三個W的。
|
項目名稱：電源設備銷售服務信息系統
項目單位：TB公司電源設備銷售部
最後修改日期：****年**月**日
|
|
|
項目目標
|
TB公司電源設備銷售部是一個以硬件系統配套設備提供商爲基本客戶的專業電源設備配套提供商，銷售的設備來源一部分是自主生產，另一部分由多家國內外知名品牌的電源設備生產商組成供應鏈。本項目將開發新的業務過程以及相應的信息系統過程和服務，以支持該公司的產品和分級客戶服務的戰略。預期最終的系統將提供高度集成的過程和服務，這些過程和服務將跨越多個內部業務部門，直接到達客戶。該項目預期將實現以下內容：
1，開發一個基於Web的網上銷售系統，使銷售渠道順暢。
2，開發一個功能全面應用靈活的內部信息系統，使TB公司在高度競爭的市場中，帶來顯著的競爭優勢。
3，與客戶（硬件系統配套設備提供商）建立一種夥伴關係，其中包括購買電源方案、安裝電源設備方案和定製電源設備配套方案，以產生競爭優勢。注意，這個方案可能需要重新設計業務過程，這個替代方案假定客戶的特殊需求可以和本公司的供應商（電源設備生產廠商）協作完成，並且允許供應商把這些修改加入到他們未來的產品中去，但是，設備生產商的改進將被合同限制在一定時間之後才能銷售給本公司的其它競爭者。
|
|
項目概念
|
這個項目是在信息技術戰略規劃（ITSP）項目中構思的，戰略信息系統規劃爲應用系統、數據庫和網絡（包括使用因特網作爲戰略平臺）。因爲市場被認爲是優先級最高的考慮，所以，一個方便的網上訂單處理系統，和一個跨部門的高度集成的客戶服務系統被認爲是最重要的系統之一，同時也和另一個高優先級的庫存和供應鏈系統有合適的接口。
|
|
問題陳述
|
基於Web的網上訂單系統主要用於是客戶可以方便的自主組合訂單。
客戶服務系統主要與訂單處理系統結合處理客戶訂單，並且可以按分級處理方式處理客戶訂閱，多年以來本公司主要使用Microsoft Excel作爲主要的工具，所以現有的計算機處理只是一種初步的方式。該部門急需有一個方便的網上電源銷售系統，另外靈活多變的銷售策略是提升銷售業績的主要方法，但它們和現有的企業信息系統並不兼容，難以提升整體的效率，爲此銷售部門在討論中提出了以下具體問題：
1，經常變化的產品組合導致的不兼容，應急配備的系統產生內部的低效率以及與客戶關係複雜化。
2，產品構成的易於變化爲建立新的基本客戶創造了機會，這些易於變化的特徵將會吸引未來的客戶，但是目前的系統和工作方式並不支持這種易於變化特性。
3，在擴大業務的過程中由於積極的廣告行爲和基本客戶量的大幅度增加，不久將會超出現有方式的實時事務處理的能力，向客戶發貨的延遲將會導致現金流動困難。
4，管理層建議實現一種“優惠級基本客戶”制度，這種制度不能在現有的工作方式上實現，比如不同的業務人員接待具有“優惠級基本客戶”資格的同一個客戶的時候，難以使用相同的規則。
5，未付款的訂單比兩年前增加了2%，發現主要原因是業務量增大以後，由於未付款客戶檢查過程繁複而遺漏是主要問題。
6，兩年中，無效合同增加了7%，根據分析主要原因是目前的工作方式對合同的有效性難以確認。
7，來自其它企業的競爭，迫使管理層提出了一個動態調整“優惠級基本客戶”策略的方案，但現有的工作方式無法做這種動態的改變。
8，某些應急配備設備客戶的訂單沒有得到及時處理，長時間的延時導致客戶拒收或者後期處理耗盡倉庫的庫存。
9，TB公司的管理層意識到，電源設備銷售目前部分使用了計算機處理營銷服務渠道，但由於與公司其它營銷模式不匹配，難以提升整體效率，但是網上電源銷售的成功堅定了管理層的信心，改變這個現狀事實上已經成爲該公司未來發展戰略的一部分。
|
|
項目影響範圍
|
這個交叉功能項目將支持或者影響以下的業務功能或外部團體：
1，營銷
2，訂閱
3，銷售和訂單錄入（對所有的銷售辦事處，工作方式應該是相同的）
4，倉儲（對不同地域的倉儲中心可以實現統一調度）
5，庫存控制和採購
6，發貨和驗收
7，所有的不同級別的客戶服務
8，外部團體
a,潛在客戶
b,客戶
c,曾經的客戶
d,供應商
e.生產廠
項目範圍在項目執行過程中可能會發生變化，但第一階段儘可能的清楚界定。
|
|
項目構想
|
信息技術戰略規劃要求該系統必須做到：
1，通過改進數據收集技術、方法、渠道和決策支持加速訂閱和訂單的處理，管理層希望原有的因特網銷售系統略加改造就能夠加入到本系統中去，成爲本系統的一個子系統。
2，到****年底，未付款的訂單減少到2%。
3，到****年底，無效合同減少到5%。
4，到****年底，在現有人力資源基本不變的情況下，訂單處理能力提高3倍。
5，系統將可以協助完成動態調整“優惠級基本客戶”策略的方案，同時可以檢查合同結構，並支持在線的動態合同修改。
6，便於重新考慮引起客戶抱怨的底層業務過程、程序和策略。
7，提供改進的訂單和應急配備設備客戶的跟蹤機制。
|
|
業務限制
|
新系統必須符合以下要求：
1，系統的第一個版本必須在9 個月內完成，後續的升級版本必須每6 個月發佈一次。
2，沒有會計部門的同意，不得改變現有系統的任何文件和數據庫結構。
3，作爲TB公司通過ISO 9000認證這個戰略目標的一部分，所有的業務過程都需要接受業務過程重構，以改進全面質量管理並支持持續改進。
4，系統必須具備很好的可維護、可升級以及安全性。
|
|
技術限制
|
新系統必須符合下面信息技術架構標準：
1，局域網架構爲基於服務的三層架構，客戶端爲Windows應用程序，服務器操作系統爲Windows 2003 Server。因特網服務則使用Internet Information Server（IIS）。
2，該項目要求開發一個或者多個企業數據庫，數據庫服務器操作系統爲Windows 2003 Server，希望能自動實現數據備份，從各種因素考慮，數據庫採用Sql Server 2005。
3，該項目開發的應用系統採用Microsoft.net 2005，首推的語言爲C#，在某些特殊的地方也可能使用VC++編寫的結構塊，但是，並不拒絕在必要的情況下使用Java語言。
4，外部客戶所使用的環境一律使用瀏覽器，但並不限制操作系統，對不同級別的客戶，權力要實現限制。
5，內部員工一律使用Windows XP或升級版本，除了瀏覽器外，還可能使用桌面應用程序，需要預裝Microsoft.net Framework 2.0（或以上版本）。
|
|
項目組織方式
|
爲此項目成立專門的開發管理班子，職責爲：
1，任命項目經理
2，任命首席構架師和分析師
3，任命項目經理推薦的項目團隊
4，評審並批准項目發佈的內容
5，確保項目符合管理層的想法
6，認可所有的範圍、預算和計劃變更
要求項目團隊每週召開情況工作會議，由項目經理組織，並把細節報告給管理班子。
開發團隊需要建立自己的開發網站，其主要的內容爲軟件架構文檔（Software Architecture Document SAD），用以公佈項目決策的概要和架構的視圖，便於開發成員瞭解項目的進程和主要思想。
|
2，子系統組成
下面只列出了本課程作爲案例的子系統說明。
|
電源設備銷售服務信息系統各子系統功能說明
|
|||
|
編號
|
子系統
|
功能說明
|
要求
|
|
1
|
訂單處理子系統
|
1，客戶直接利用因特網構建電源設備購買訂單。
2，客戶可以選擇標準配置，也可以在線建立自己的配置。
3，對每一種配置，系統通過客戶服務系統提供客戶相關信息計算銷售價格。
4，訂單通過倉庫服務系統獲取發貨策略。
|
訂單生成使用Web頁面。
內部服務使用桌面程序。
|
|
2
|
客戶服務子系統
|
1， 實現客戶分級管理策略。
2，處理客戶訂閱。
3，處理客戶資料。
4，處理訂單和客戶資料。
5，查詢客戶購買歷史。
6，處理促銷方案。
7，每日生成默認合同報告。
8，向訂單處理子系統發送價格處理結果。
|
客戶訂閱和查詢使用Web頁面。
內部處理使用桌面程序。
|
|
3
|
倉庫管理子系統
|
1，處理庫存。
2，處理進貨。
3，決定發貨策略。
4，有供應鏈子系統獲取供貨信息。
|
使用桌面程序。
|
第四節 軟件生命週期設計與統一軟件開發過程
一、軟件設計的生命週期與基本過程
軟件開發過程描述的是軟件構造、部署還有維護的一種方法，成功的軟件設計過程更多的是研究用戶和市場，而不是技術本身。
經典的瀑布式過程大致的情況是這樣的：
1）收集市場數據，做市場分析。
2）確定用戶，與用戶交流，理解用戶，理解用戶的工作並與用戶建立良好的關係，以便將來的設計和開發過程中經常得到他們的反饋意見。
3）建立典型用戶羣，通過對用戶工作的瞭解，發現和自己設計工作有關的典型用戶羣。這些典型用戶羣應該能夠描述用戶工作中的一個或者幾個重要環節。
4）與用戶交流進一步細化典型用戶羣，並寫出場景腳本。
5）確定軟件的主要功能。
6）確定這些功能的主次，並確定優先級。
7）確定需求並寫出說明書。
8）由用戶羣檢查需求說明書，看需求說明能不能滿足用戶的需要。
9）進行軟件體系結構設計。
可以看出來，在這個過程中軟件分析佔了軟件設計很大一部分工作量，用戶、市場、分析、設計，是整個軟件設計中密不可分的幾個部分，這樣一個過程也稱之爲“瀑布式”過程，可以用圖形描述如下：
成功的軟件開發過程的最顯著的特點，是把“研究和開發”活動與“生產”活動明確的分開。
不成功的項目大多具有以下特點：
1，過分強調研究和開發，進行太多的分析和書面研究，因此工程基線被推遲。這種狀況，在傳統的軟件過程中倍受推崇，也是傳統軟件過程需要改進的原因。
2，過分強調生產，匆忙做出判斷和設計，編碼人員過分賣力的做不成熟的編碼，造成持續不斷的刪改。
成功的項目，當從研究階段到生產階段的轉變的時候，有十分明確的項目里程碑。
較前期的階段，側重於功能的實現，較後期的階段，側重於如和實現交付給客戶的產品。
由此形成了如下過程。
1，立項管理流程
2，項目規劃流程
3，需求管理流程
4，需求開發流程
5，技術預研流程
6，系統設計流程
7，實現與測試流程
8，系統測試流程
9，配置管理流程
10，質量保證流程
11，結項管理流程
12，服務與維護流程
二、順序“瀑布”生命週期所帶來的問題
經典的軟件開發生命週期是順序的、線性的或“瀑布”的生命週期，最常見的步驟如下：
1）澄清、記錄和承諾一組完整的已經凍結的需求。
2）設計基於這個需求的一組系統。
3）基於設計，實現系統。
但是，這樣的開發過程往往帶來了很多問題，這些問題促使了統一軟件開發過程（UP）的提出，這是一種流行的構造面向對象系統的軟件開發過程，並已經被廣泛採納。
統一過程（UP）把普遍接受的最佳實踐（迭代生命週期和風險驅動開發），合併爲內聚和具有良好文檔的過程描述。而迭代開發是在統一過程中最有價值的實踐，它是軟件開發的一種巧妙的方法。
MIT Sloan Management Review（麻省理工學院項目管理評論）所刊載的一個爲時兩年對成功軟件項目的研究報告指出，軟件項目獲得成功的共同因素，排在首位的是迭代開發，而不是瀑布過程。
（其它的因素是：
2，至少每天把新代碼合併到整個系統，並且通過測試，對設計變更做出快速反應。
3，開發團隊具備運作多個產品的工作經驗。
4，很早就致力於構建和提供內聚的架構。
這四個因素中有三個在UPO中有顯式的實踐。）
爲什麼會是有這樣的結果呢？
三、迭代開發希望能解決的問題
需求變更對項目過程的影響
所謂需求，是系統必須提供的能力和必須遵從的條件。
需求最根本的挑戰在於：
尋找、交流並記錄什麼是真正需要的，並能夠向用戶和開發團隊講解。
一個關於影響項目進展的因素的研究如下圖。
（Jim Johnson 1994 Chaos:Charting the Seas of Information Technology. Published Report .The Standish Group）
可見37%的問題都與需求有關，這就需要“需求管理”。
早期需求管理是瀑布式的，也就是說在項目的第一階段，在任何設計和實現工作之前，儘可能的推敲，把需求完全定義清楚，並把它穩定下來，並且實際開發前凍結需求，但歷史證明這種方式是失敗的，在項目很大的時候，凍結需求幾乎沒有可能。
正是這種困難，迫使人們在項目過程控制中，轉而使用迭代式方法，所謂迭代式方法，是用一種條理化的方法來尋找、記錄、組織和跟蹤不斷變化的需求。
這裏的關鍵是“不斷變化”這個詞，把需求變化作爲項目進展的不斷驅動力，另一個重要的詞是“尋找”，可以通過寫出用例和召開需求研討會等手段巧妙的得出需求。
整個問題都來自於，用戶往往對自己的願望並不清晰，需求會不斷的變化。
所以，我們必須使用一種處理過程，這種處理過程的特點就在於適應這種需求的變化。
很多單位爲什麼放棄了多年使用面向過程方法，轉而研究面向對象的方法，需求變化的困擾是一個主要原因，而面向對象的設計和分析，所有問題的焦點都聚焦於如何適應變化上，這是一個值得我們關注的課題。
統一過程（UP）提倡了幾種最佳實踐，其中影響力最大的實踐，那就是迭代開發。
什麼是迭代開發？
1）開發被組織成一系列固定的短期（如四個星期）小項目，稱爲迭代。
2）每次迭代都產生經過測試的，經過集成的，和可執行的系統。
3）每次迭代都有自己的需求分析、設計、實現和測試活動。
迭代生命週期貫穿多個迭代，系統在這個過程中被持續擴展和精化。
系統迭代過程的驅動力有兩個：
循環反饋；
適應調整。
隨着一次又一次的迭代遞進，系統增量式的發展完善，因此這一過程也稱之爲迭代增量開發。
我們來看一個簡單的實例：
討論一個兩週的迭代。
星期一：分析和澄清本次迭代的任務和需求，同時由一人對上次迭代的代碼進行逆向工程，形成UML並打印出重要的圖。
星期二：在白板上進行分組設計工作，畫出UML草圖，使用數碼相機記錄，並寫出一些僞代碼和設計註釋。
剩餘的八天：
實現；
測試（單元測試、驗收測試、可用性測試）；
進一步設計；
集成；
每日的構造工作；
系統測試及部分系統的穩定；
與項目相關人員進行演示和評估；
計劃下一步迭代。
注意：
1）不要匆忙編碼。
2）不要試圖在編程前完善所有設計細節的長期持續的設計步驟。
3）少量超前設計使用粗略和快速的UML可視建模來完成。
4）開發人員大概用半天或一整天的時間進行分組的設計工作。
每次迭代的結果是一個可執行但不完善的系統，一般需要10到15次迭代系統纔可能投入生產。
迭代輸出不是實驗性的，也不是即將丟棄的原型，迭代開發也不是原型開發。與之相反，它的輸出是最終產品的子集。
一般來說，儘管每次迭代需要擴展新需求並增量擴展系統，但迭代偶爾也會重新審視現有的軟件並對它進行改造，例如，並不增加一個子系統的新特性，而致力於提高它的性能。
四、初始階段
大多數項目需要一個簡短的初始階段來考慮以下幾種問題：
1）項目的構想怎麼樣？業務的案例是什麼？
2）可行性怎麼樣？
3）購買還是開發？
4）粗略估計一下成本：一萬到十萬？還是上百萬？
5）項目是否停止或者繼續進行？
想要定義構想和獲得一個粗略的（不一定可靠）的預測結果，就必須研究需求。
但是，初始階段的目標並不是要定義所有的需求，或產生一個真實可信的項目估計或計劃。
簡而言之，初始階段的目標：
只進行一定的研究，得到未來新系統的可行性以及實現系統總體目標的合理判斷，並確定是否值得繼續深入研究系統即可。
深入研究是細化階段的工作。
初始階段的時間：
大多是一週到幾周，太長就失去了初始的意義。
注意：重要的問題是，確定這個項目是不是值得深入的去研究。
在統一過程中，真正的項目研究在細化中。
下面列出初始階段的工件以及各個工件需要完成的工作：
1）構想和業務案例：
描述高層的目標和約束、業務案例、並提供一個執行摘要。
2）用例模型
描述功能需求和非功能需求。
3）補充規範
描述其它需求。
4）術語表
關鍵的領域術語。
5）風險列表和風險管理計劃
描述業務、技術、資源和進度上的風險，以及如何減輕這些風險，以及如何應對。
6）原型個概念驗證
闡明構想，驗證技術問題。
8）迭代計劃
描述第一此細化迭代中應該做些什麼。
9）階段計劃和軟件開發計劃
對細化階段的持續時間和工作量進行抵精度的猜測，開發涉及的工具、人員、培訓和其他資源。
10）開發案例
描述爲本項目定製的統一過程的步驟和工作，在統一過程中，總需要爲項目定製一些步驟和工作。
在上面的工作中，需要我們關注的是所謂“用例模型”。
迭代開發的一個關鍵理解就是：
這些工件在初始階段只是部分完成，在之後的迭代中再逐步精化和提煉，甚至在認定某個工件確實有用之前，根本無需來創建它，所以初始階段進行的研究和工件內容都很少。
注意：
初始階段會有一些編程，其目的是創建“概念驗證”，通過面向用戶的界面原型，來澄清一些需求，或者對關鍵的技術問題作一些編程實驗。
初始階段關注的是確實對項目有價值的工作，要放棄那些不必要的工作。工件的關鍵不是文檔本身，而是其中蘊含的思想、分析和前期準備。
五、精化階段，反饋和調整
注意：
迭代開發不是試圖在實現以前完成所有的設計，“凍結”所有需求的變更。
而是用擁抱變更、適應調整的態度來作爲迭代開發真正必要的驅動力。
但這並不表明迭代開發和UP鼓勵不受控制的、反應式的“特性蔓延”驅動過程，事先，我們必須和相關人員認真探討他的構想和需求，以及市場變化的時候，UP如何平衡需求。另一方面，我們也需要認清需求會變更這個事實。
每次迭代都選擇一小組需求，並且快速的設計、實現和測試，在早期迭代中對需求和設計的選擇可能並不準確，也可能不是最終的需求，但這樣可以迅速得到來自用戶、開發人員或者測試人員的反饋。
這種早期的反饋十分重要，這種來自實際構建和測試的反饋，提供了實際的洞察力，以及修改或者調整需求或設計的機會。
最終用戶將有機會看到部分系統，並說：“不錯…..但是…..”。
這種“不錯…..但是…..”的循環，正是改進軟件或者獲得相關人員認可的巧妙方式，不過，注意這裏並不是認可混亂的反應式開發。
另外，負載測試也可以驗證部分設計是不是正確，這可以決定下次迭代是不是要改變核心架構，最好在早期解決和驗證關鍵設計，以規避決策風險，迭代開發正好提供了這種機制。
因此，通過一系列有序的“構造-反饋-調整”循環，工作不斷向前推進，早期迭代偏離“正確軌跡”會大於後來的迭代，隨着時間的推移，系統將沿着這一軌跡推移。
六、迭代開發的優點
在早期而不是晚期緩解高風險（技術、需求、目標、可用性方面的風險）；
早期可見的發展；
早期反饋、用戶參與和調整，會得到一個更接近用戶真實需求的經過精化的系統；
可控複雜性，開發組不會被“分析癱瘓”或者長期複雜過程所淹沒；
在一次迭代中所學到的知識，可以被有系統的運用於改進開發過程本身。
七、迭代的長度和時間分區
UP（或有經驗的迭代開發人員）建議，迭代長度在2-6周之間比較好。
小步驟、快速反饋和調整，是迭代開發的主要思想。
長期迭代複雜性會變得不可收拾，反饋也會延遲, 會增加項目風險。
短於兩週的的迭代不足以產出和反饋。
一個關鍵思想：
時間分區是固定的，每次迭代不鼓勵時間推遲，如果無法完成，可以除去一部分任務轉移到下一次迭代中去。
大型開發團隊（幾百人）可能需要6周以上的迭代時間。
例：
20世紀90年代，加拿大空中交通系統。
首席架構師：Philippe Kruchten
150個程序員被組織到6個月的迭代中。
但是，即使在6個月的迭代中，10 – 20 人的子系統，仍然把任務分解成一連串6 個爲其一個月的迭代。
6 個月迭代是大型開發團隊的特例，但不是準則。
UP的建議普通的迭代應該在 2 – 6 周之間。
八、統一軟件開發過程最佳實踐和概念
UP所欣賞和實踐的主要思想是：短時間分區式的迭代和適應性開發。
UP的另一個核心思想是使用對象技術。
其它一些UP 的關鍵概念是：
在早期迭代中解決高風險和高價值的問題；
不斷的讓用戶參與評估、反饋和需求；
在早期的迭代中建立內聚的核心架構；
不斷的驗證質量，提早、經常和實際的測試；
應用用例；
可視化建模（UML）；
仔細的管理需求；
實行變更請求和配置管理。
九、統一過程階段和麪向進度表的術語
一個UP項目跨越4 個主要階段：
1）初始階段：
大體構想、業務案例、範圍、模糊評估。
2）細化階段：
已經精化的構想，核心架構的迭代實現，高風險的解決，大多數需求和範圍的識別，更爲現實的評估。
3）構造階段：
迭代實現遺留下來的風險較低的和比較容易的元素，準備部署。
4）移交階段：
beta測試，部署。
UP和過去“瀑布”或順序生命週期不同，它不是一開始就定義全部需求，然後進行全部或大部分設計。
初始階段不是一個需求階段，而是一個類似於可行性階段，在這個時候需要進行充分的調查，以確定是否繼續或終止項目。
同樣，細化階段也不是一個需求或設計階段，而是一個迭代實現核心架構並降低高風險的階段。
下圖是UP中常用的面向進度表的術語，注意，一個開發週期（以系統投運作爲結束標誌）由多個迭代組成。
十、UP流程（工作流）
UP描述了流程（discipline），簡短的說，流程是在一個主題域中的一組活動，例如需求分析中的活動。
工件（artifact），是對任何工作產品的通用術語，比如：代碼，Web圖形，數據庫模式，文本文檔，圖，模型等。
需要說明，在2001年，爲了與OMG SPEM的國際標準化工作一致，過去的UP 術語“工作流”（workflow）改成了流程（discipline），術語“工作流”（worlflow）有新的含義，並且和UP 的含義稍有不同，在一個特定的項目中，工作流是特定順序的一組活動，可能跨越流程（工作的流轉），但現在在UP中還有人使用“工作流”這個名詞，儘管這並不嚴格正確。
Up中有多個流程，但下面我們將專注於以下三個流程的建模。
1）業務建模
在開發單獨的應用的時候，業務建模包括領域對象建模。
在從事大規模業務分析和業務過程再工程的時候，業務建模包括跨越整個企業的業務過程的動態建模。
2）需求
對應的需求分析，比如寫出用例，和識別非功能性需求。
3）設計
設計的所有方面，包括總體框架、對象、數據庫、網絡連接等。
下圖列出了更多的UP 流程。
在圖中:
實現：表示編程的構建系統，而不是部署。
環境：實質建立工具，併爲項目定製過程，也就是說設置工具和過程環境。
十一、流程和階段
在上面的圖中，在一次迭代中，工作會在大部分流程或全部流程中進行。但隨着時間變化，這些流程的相對工作量會變化。
早期迭代更多的工作量在需求分析和設計。
後期迭代這種需求的變化會減少，表明需求和核心設計通過反饋和適應調整過程已經穩定。
對於UP階段（初始、細化、構造、移交），各階段相對工作量如下圖。
比如，在細化階段，迭代趨向於相對高層的需求和設計工作，儘管同時有一些實現。
在構造階段，工作的重點更多的是放在實現而非需求分析上。
十二、敏捷UP
方法論者談起過程是這樣來區分的：
重量級過程和輕量級過程；
預測性過程和適應性過程。
重量級過程（heavy process）是一個貶義詞，它的含義如下：
1）在官僚氣氛中創建工作。
2）刻板和憂鬱。
3）細化的、長期的、詳細的計劃。
4）預測的而不是適應性的。
預測性過程（predictive process）：
試圖在相對長期的時間（例如項目的大部分時間）內詳細的計劃和預測活動和資源（人員）分配。
預測性過程通常具有“瀑布”或順序生命週期的特點：
1）定義所有需求。
2）定義詳細的設計。
3）實現。
適應性過程（adaptive process）：
認爲變化是不可避免的驅動因素，鼓勵靈活的改寫。
它通常具有迭代生命週期。
敏捷過程（agile process）：
通常意味着輕量級和適應性過程，敏捷的反映不斷變化的需要。
UP 的作者不想讓UP成爲重量級和預測性過程，儘管大量可選的工件和活動集中在這個方面導致這種印象，敏捷UP由以下的應用示例：
1）推薦一小組UP活動和工件：
一般來說，應該儘可能保持簡單。
2）UP是一個迭代過程：
需求和設計實現之間並不是完全的，它們是基於反饋，通過一系列的可適應迭代完成。
3）對整個項目沒有詳細計劃：
項目的一個高層計劃（階段計劃）確立項目完成日期和其它主要里程碑，但它沒有詳細描述這些里程碑的細粒度步驟。
詳細計劃（迭代計劃）只是預先對迭代進行的更詳細的計劃，詳細計劃從迭代到迭代是可適應的。
強調相對小量工件和迭代開發，是敏捷UP的精髓。
十三、何時你會知道你並不瞭解UP
你如果是用如下方式之一處理問題，就表明你並不瞭解UP。
1）認爲初始=需求，細化=設計，構造=實現。
2）爲細化的目的，是完整的細緻的定義模型，這些模型在構造過程中會轉化爲代碼。
3）試圖在開始設計或實現之前定義絕大部分需求。
4）試圖在開始實現之前定義絕大多數設計，試圖在迭代編程和測試之前完整的定義和確認架構。
5）在編程開始之前進行“長期”的需求和設計工作。
6）認爲合適的迭代長度是4個月，而不是四個星期（除非上百人開發一個項目）。
7）認爲UML繪圖是完整而且詳細的定義設計和模型，認爲編程就是把這些設計圖簡單而機械的轉變成代碼。
8）認爲採用UP意味着實行大量可能的活動和創建許多文檔，認爲UP是一種形式化的繁瑣的過程，這個過程有許多要遵守的步驟。
9）試圖從頭到尾詳細計劃一個項目，試圖投機的預測所有迭代和每次迭代可能發生的事情。
10）在細化階段結束之前，想要可信的項目計劃和評估。
第二章 需求過程與分析的核心理論
架構設計過程分爲兩個階段：高層設計階段和詳細設計階段。
高層設計階段的重點是軟件系統的體系結構設計。詳細設計階段的重點是用戶界面設計、數據庫設計和模塊設計。
而高層設計的信息，主要來自於需求分析。
第一節 需求過程在軟件架構中的重要作用
作爲一個架構師，工作的主要舞臺是系統設計，但設計的輸入來自於需求工程，什麼樣的需求思想，就有什麼樣的架構思維。
這就是說，合理而且正確的需求分析過程，是架構設計過程的一個有機的組成部分，所以，我們首先必須討論需求分析的領域建模的有關問題。
需求開發與需求管理是相輔相成的兩類活動，它們共同構成完整的需求工程。需求工程結構圖如下所示：
|
|
需求開發和需求管理的流程下所示。
|
|
其中，需求變更控制是指依據“變更申請－審批－更改－重新確認”的流程處理需求的變更，確保需求的變更不會失去控制而導致項目發生混亂。
需求的類型：
作爲一個檢查表，需求可以按照FURPS+模型進行分類的，每個字母含義如下：
F：
功能性（Functional）：特性、能力、安全性。
U：
可用性（Usability）：人性化因素，幫助，文檔。
R：
可靠性（Reliability）：故障週期，可恢復性，可預測性。
P：
性能（Performance）：響應時間，吞吐量，準確性，有效性，資源利用率。
S：
可支持性（Supportability）：適應性，可維護性，國際化，可配置性。
+：
輔助和次要的因素，比如：
實現（Implentation）：資源限制，語言和工具，硬件等。
接口（Interface）：與外部系統接口所加的約束。
操作（Operations）：系統操作環境中的管理。
包裝（Packaging）：
授權（Legal）：許可證或其它方式。
事實上，FURPS+模型並不是唯一的，但用它來作爲需求範圍檢查表是很有效的，這可以降低考慮系統的時候遺漏某些因素的風險。
還有一些分類方式和FURPS+模型類似，比如ISO9126，它主要來自於美國軟件工程研究所(SEI)。
第二節 面向過程的需求分析核心知識
傳統的面向過程需求分析與面向對象分析是不同的，傳統方法把系統看成一個過程的集合體，由人和機器共同完成一個任務，計算機與數據交互、讀出數據、進行處理又把結果寫回到計算機裏面去。
在討論事件的時候，過程方法強調組件的過程模型。
而對象方法把系統看成一個相互影響的對象集，對象重要的是具有行爲（方法），行爲發送消息請求另一個對象做事情，就本質而言，對象方法不包括計算機過程和數據文件，而是對象執行活動並記錄下數據，當爲系統響應建模的時候，對象方法包括響應模型、模型行爲以及對象的交互。
兩種方式的不同點如下圖：
下面我們先簡單討論一下面向過程分析的特點，一般來說，面向過程的分析必將導致面向過程的架構（設計）。
一、數據流程圖DFD
1，DFD的符號
面向過程的核心理念是數據流，所以它的模型主要是數據流程圖（DFD），它只用了5個符號。
概念：
外部實體：在系統邊界之外的個人和組織，它提供數據，或者接受數據輸出。
過程：在DFD中的一個符號，它代表數據輸入轉換到數據輸出的算法或者程序。
數據流：在DFD中的箭頭，它表示在過程、數據存儲和外部實體間的數據移動。
數據存儲：保存數據的地方，將來一個或者多個過程來訪問這些數據。
2，關聯圖
系統內部在單個過程符號中概括所有處理活動的DFD。
下面是客戶支持系統的關聯圖簡單例子：
注意，箭頭表示數據的流向。
二、事件劃分的系統模型（0層圖）
DFD的細節稱作片段，片段的組合有多種方式，現代過程分析也是以事件爲基礎，所以完全集可以組合到一個事件劃分系統模型或者稱爲0層圖中去。其中，每個過程爲一個事件的處理。
三、分解過程
如果一個DFD片斷包括更多的處理，可以把過程進行分解，以便作更詳細的研究。
四、評估DFD的質量
高質量的DFD是可讀的、內部一致的以及能準確表示系統需求的。
複雜性最小化：
人們對複雜信息處理是有侷限性的，當太多的信息同時出現的時候，人們把這種現象稱作信息超量。在這樣的情況下，可以把信息劃分爲小的相對獨立的子集，這樣便於單獨考察和理解信息，這也是建模最根本的目的。
7±2原則：
這個原則也稱之爲Mille數，由心理學研究，一個人可同時記住或操縱的信息塊的數目大約在7到9之間，也就是一個模型的過程數不要超過7±2個。
另外數據流進、流出一個過程、數據存儲或者數據元素的個數不要超過7±2個。
這不是強制原則，但可以給我們提供一個警告。
接口最小化：
這裏的接口是指一個問題或者描述中的一部分與其它部分的連接。源於7±2原則，連接數應該保持最小，如果超出了這個原則，可把一個過程分解爲更多的過程，以使得分析簡單。
數據流一致性：
通過分析數據流的不一致，可以找到錯誤。
下面的例子使用了過程描述（面向過程英語）來描述內部過程，流入的B、C沒有任何處理，也沒有流出，被稱之爲“黑洞”。
下面的例子，流出的B、Y和內部的X並沒有流入，被稱之爲“奇蹟”。
面向過程的分析已經有了一套完整而且成熟的方法，像決策表和決策樹等等，這裏就不再討論了。
五、案例：訂單處理子系統
1、問題陳述：
|
項目名稱：電源設備訂單處例子系統
項目單位：TB公司電源設備銷售部
最後修改日期：****年**月**日
|
|
|
系統目標
|
1，客戶直接利用因特網購買電源設備，客戶選擇設備，設備分爲普通不間斷電源、服務器專用不間斷電源和專業級不間斷電源加自主供電設備等。
2，客戶可以選擇標準配置，也可以在線建立自己的配置。
3，可配置的構件顯示在一個下拉列表中，對每一種配置，系統可以計算價格。
|
|
系統要求
|
1，發出訂單時，客戶需要填上運送和付款信息，系統可接受的付款方式爲信用卡和支票，一旦訂單輸入，系統將向客戶發送一個確認e-mail信息，並且附上訂單細節，在等待電源設備送到的時候，客戶可以在任何時候在線查到訂單狀態。
2，後端訂單處理包括下面所需的步驟：由客戶服務系統提供這個客戶的等級以及根據等級和促銷策略計算出的相應折扣方式，驗證客戶的信任度和付款方式，向倉庫請求所訂購的配置，打印發票，並且請求倉庫將電源設備運送給客戶。
|
1，功能分解圖
功能分解顯示了一個系統自頂向下的分解結構，也爲我們繪製數據流圖（DFD）的提綱。
2，過程事件圖
現在我們的眼睛盯住具體的細節，爲每個事件過程繪製一個事件圖，這實際上是一個事件的上下文流圖。在研究事件圖的時候，往往需要了街所有的數據存儲。必要的時候，數據庫分析和設計可以提到前面先來完成，我們將在後面的章節來討論這個問題。要說明的是分析的時候並不需要數據庫的詳細設計，而只是把數據存儲用實體的方式從大的方面規範清楚，以此作爲詳細設計的一個必要的輸入。
大多數事件圖包括一個單一過程，並且需要說明以下內容：
1）輸入及輸入來源，來源被描述爲外部代理。
2）輸出及輸出目的地，目的地被描述爲外部代理。
3）必須讀取記錄的任何數據存儲都應該被加入到事件圖中，事件流應該加入命名。
4）對數據的任何增、刪、改、查都應該加入到事件流中，事件流應該加入命名。
事件圖的敏感性和簡單性，使它成爲專家和用戶溝通的強有力的工具，下面是一個簡單的外部事件圖。
一個簡化的“訂單處理子系統”的過程事件圖如下。
|
參與者
|
事件（或者用例）
|
觸發器
|
響應
|
|
客戶
|
選擇產品（由Web頁面驅動）
|
產品查詢
|
生成“目錄描述”
|
|
客戶
|
發出訂單
|
新客戶訂單
|
生成“客戶訂單確認”，在數據庫中創建“客戶訂單”和“客戶訂購的產品”。
|
|
客戶
|
修改訂單
|
客戶訂單修改請求
|
生成“客戶訂單確認”，修改數據庫中 “客戶訂單”和“客戶訂購的產品”。
|
|
客戶
|
取消訂單
|
客戶訂單取消
|
生成“客戶訂單確認”，在數據庫中邏輯的刪除 “客戶訂單”和“客戶訂購的產品”。
|
3，系統DFD圖
事件圖並不是孤立存在的，它們集合在一起定義了系統和子系統，所以，構造一個或者多個系統或者子系統中所有事件相互關係的系統圖也是有意義的。在繪製系統圖的時候，必須平衡不同詳細程度的事件圖，以保證一致性和完整性，必要的時候可以擴展爲多個DFD。系統圖更多的是從宏觀的角度看爲題，更多的考慮相互關係，這點很重要。
4，基本圖
系統圖中的某些重要的事件過程可以擴展爲一個基本的數據流圖，以揭示更多的細節，這對比較複雜的業務過程（比如訂單處理特別重要），有些事件比較簡單（比如報告生成），所以不需要進一步擴展。
5，完整的規格說明
上下文圖、系統圖、事件圖和基本圖的組合構成了過程模型，一個工藝良好的完整過程模型可以在最終用戶和計算機軟件設計者以及程序人員之間有效的溝通需求，消除大部分系統設計、編程和實施階段出現的混淆。
注意，完整的過程模型並不僅僅是這些圖，更多的是文字說明，把圖形和文字結合起來，設計就會非常的清晰而且避免歧義，這非常重要。
第三節 面向對象的需求分析和用例
在面向對象的需求分析中，對象、事件和響應成爲分析的主體，分析的着力點轉向了交互。但是，還是有相應的方法來描述功能，這就是用例，這也是需求分析的重要部分。
一、用例及用例圖的基本概念
用戶一定會有自己的目標，並且希望計算機能夠幫助他們實現這些目標。
用例就是表達如何使用系統達到目標的一組情節。
用例的幾個概念
參與者（actor）：具有行爲能力的事務，可以是個人（由其扮演的角色來識別），計算機系統，或者組織。
場景（scenario）：是參與者和被討論系統之間一系列特定的活動和交互，通常被稱之爲“用例的實例”。通俗地講，場景實際上是在說故事。一般來說，一個用例就是描述參與者使用系統達成目標的時候一組相關的成功場景和失敗場景的集合。
用例分析的關鍵是專注於“怎樣才能使系統爲用戶提供可觀測的數據，或幫助用戶實現它們的目標”，而不是僅僅把系統需求用特性和功能的細目羅列出來。
在需求分析中，我們必須專注於考慮系統怎麼才能增加價值和實現目標。
用例的主要思想是：爲功能需求寫出用例（而不是老式的爲“系統會怎麼做”的功能列表），在統一過程中用例是發現和定義需求的主要方法，是功能性行爲。
參與者的發現:
發現參與者對提供用例是非常有用的。因爲面對一個大系統,要列出用例清單常常是十分困難。這時可先列出參與者清單,再對每個參與者列出它的用例,問題就會變得容易很多。
二、用例（UseCase）及其定義
1）用例：
1．用例是關於單個活動者在與系統對話中所執行的處理行爲的陳述序列（Jacobson）。它表達了系統的功能和所提供的服務，用例的圖示如下。
2．它描述了活動者給系統特定的刺激時系統的活動，是活動者通過系統完成一個過程時出現的一組事件，最終以實現一種功能。
3．通常，用例側重於功能，但不重點描述該功能的實現細節。
4．所有的用例必須始於參與者（Actor），而且有些用例也結束於參與者。
2）用例的分類
1．業務用例（Business Use Case）
指系統提供的業務功能與參與者的交互，表現問題領域中各實體間的聯繫和業務往來活動（如果某個用例的範圍包含了人以及由人組成的團隊、部門、組織的活動，那麼這個用例必然是業務用例）。
2，系統用例（System Use Case）
指參與者與系統的交互，它表現了系統的功能需求和動態行爲（如果僅僅是一些軟件、硬件、機電設備或由它們組成的系統，並不涉及到人的業務活動，那麼該用例是系統用例）。
3）用例的聯繫（橫向方面）
1．泛化關聯
泛化關聯代表一般與特殊的關係，它充分體現了面向對象的繼承性：子類具有父類的所有屬性，還可以擁有自己的屬性特點及行爲。泛化關聯包括用例之間及活動着之間的關聯關係。例如，修改員工資料和修改開發部員工資料就是用例的泛化關聯。泛化關聯用空心三角箭頭的實線表示：其方向從特殊指向一般。
2，包含關聯（include）
包含關聯指一個基本用例的行爲包含了另一個用例的行爲，這種關聯是一種依賴關係，被包含的用例不能獨立存在，只能作爲包含它的用例的一部分。
例如，一個信息維護的模塊，無論是錄入人員信息還是修改人員信息，都必須對當前登錄者進行驗證，因而錄入及修改人員信息這/兩個用例都用到了對當前用戶的權限驗證的用例。
其表示方法爲用一條虛箭線從基本用例指向被包含的用例，並標有構造型<<include>>：
3，擴展關聯（extend）
擴展關聯的基本含義與泛化關聯類似，但是對於擴展用例有更多的規則，即基本的用例必須聲明若干新的規則---擴展點（Extension Points），擴展用例只能在這些擴展點上增加新的行爲並且基本用例不需要了解擴展用例的如何細節。
例如，保存人員信息用例可以是刪除人員信息及新增和修改人員信息用例的擴展，它們之間存在着擴展關係。如果特定的條件發生，擴展用例的行爲才能執行。
其圖形表示方法爲在用例圖上用一條從基本用例指向擴展用例的虛箭線表示，並在線上標註購造型<<extend>>：
三、用例圖及其表達原則
用例圖主要表現各個用例之間寬泛的關係，如下圖所示。
在上面的圖中，計算機系統的參與者有兩種表示法，其中有些人喜歡用不同於人型的方框表示外部計算機系統參與者，<<actor>>稱作UML構造型，這是用某種方式分類元素的方式夠造型的名稱被書名符號包住，這本來就是法文印刷中表示引用的符號。
注意：主要參與者和用戶目標和系統邊界有關
有個問題，在“處理銷售”用例中，爲什麼主要參與者是收銀員而不是顧客呢？
這和系統邊界有關，我們定義的銷售系統邊界，服務目標是收銀員。
如果把系統邊界定義爲企業交款服務，那顧客就是一個主要參與者了。
我們也可以通過事件分析找出參與者。
第四節 用例的事件流與用例文檔
用例的事件流是對完成用例行爲所需的事件的描述。事件流描述了系統應該做什麼，而不是怎麼做。
可以通過一個清晰的，易被用戶理解的時間流來說明一個用例的行爲。
在事件流中包括用例何時開始和結束，用例何時和參與者交互，什麼對象被交互以及該行爲的基本流和可選流。
一、用例的事件流的組成
（1）用例事件流所應該包含的內容
簡要說明：描述該使用案例的作用（可以不寫出）；
前置條件：開始使用該用例之前必須滿足的系統和環境的狀態和條件（必要條件而不是充分條件）
主事件流：用例的正常流程（事件流是關注系統幹什麼，而不是怎麼幹），也稱爲用例的路徑。
其它（備選）事件流：用例的非正常流程，如錯誤流程
後置條件：用例成功結束後系統應該具備的狀態和條件（但不是每個用例都有後置條件）
（2）主事件流（用例的路徑）
可能包含有基本路徑、備選路徑、異常路徑、成功路徑和失敗路徑等幾個方面的內容。
二、描述用例的事件流的主要方式
1，面向過程語言：
每個用例只描述沒有大的分支的行爲的單個線索，在事件流中要對事件流進行面向過程說明（主事件流和備選事件流）。
2，UML的活動圖（系統活動圖---和用例活動圖）：
使用活動圖可以表示由內部生成的動作驅動的事件流，活動圖能提醒您注意並展示並行的和同時發生的活動。這使得活動圖成爲建立工作流模型、分析用例以及處理多線程應用程序的得力工具。
三、事件流描述文檔的基本要求
1）首先寫出基本的路徑
這是最主要的事情，因爲它是用戶最關心或者最想看到的內容。
2）用例交互的四步曲
1，參與者產生某個行爲動作；
2，然後系統對此動作進行響應；
3，響應成功後再根據動作的要求進行狀態的改變；
4，最後將改變後的結果再回饋給參與者。
3）模板格式
用例的模版可以有不同的形式，關鍵是要表達清楚：
作者: _______________ 日期: ___________
版本: ___________
|
用例名:
|
|
用例類型
|
|
用例ID:
|
|
|
|
主要業務參與者:
|
|
|
|
其它參與者:
|
|
|
|
項目相關人員興趣:
|
|
|
|
描述：
|
|
|
|
前置條件：
|
|
|
|
後置條件：
|
|
|
|
觸發條件:
|
|
|
|
基本流程:
|
|
|
|
擴展流程：
|
|
|
|
結束:
|
|
|
|
業務規則：
|
|
|
|
實現約束和說明：
|
|
|
|
假設：
|
|
|
|
待解決問題:
|
|
|
對於上述一些時間流，以及一些關鍵和重要的問題，需要對用例進行詳細設計，這是需要使用文檔而不是圖。
四、用例文檔中幾個元素的解釋
1）序言元素
要把最重要的元素放在一開始。而把一些不重要的“標題”材料放在末尾。
用戶興趣列表：
這個列表很重要也很實用。
用例作爲行爲的契約，撲獲所有與滿足客戶興趣有關的行爲。
這就回答了一個問題，用例應該包含什麼？
答：
用例應該包含滿足所有客戶感興趣的內容，另外，在寫出用例所有部分之前，需要確定用戶及其興趣。
例如，如果我們沒有列出“銷售人員提成”的興趣，在開始部分我們可能會漏掉這個職責。以客戶興趣作爲視點來觀察，會給我們提供一種徹底的、系統化的程序，用來發現和記錄所有必需的行爲。
例：
項目相關人員的興趣：
收銀員：希望能夠準確快速的輸入，沒有支付錯誤。
售貨員：希望自動更新銷售提成。
等。
2）前置條件和後置條件（成功後的保證）
前置條件：
規定了用例一個場景開始之前必須爲“真”的條件。
前置條件在用例中不會被檢驗，我們假定它已經被滿足，通常前置條件是已經成功完成的其它用例的一個場景。
比如：
“系統已經被登錄”或“收銀員已經被識別和授權”。
但不要包括沒有價值的條件，比如“系統已經被供電”。
前置條件主要表達讀者應該引起警惕的或者值得注意的那些假設。
後置條件：
後置條件也叫“成功後的保證”，表達了用例成功結束以後必須爲真的條件，這個“保證”應該滿足所有客戶方的需要。
這裏所有的客戶方，指的是所有參與使用項目的人員。
例：
前置條件：收銀員已經被識別和授權。
後置條件：存儲銷售信息，準確計算稅金，更新賬目和庫存，記錄提成，生成收據。
3）基本流程
我們可以把主要成功場景成做“基本流程”，它描述了能滿足客戶興趣的典型成功路徑。
一般它不包括任何條件和分支，而把條件和分支放在“擴展”部分說明。
場景記錄以下三種步驟：
1）參與者之間的交互。
2）一個驗證動作（通常由系統來完成）。
3）由系統完成的狀態改變。
例：
注意表示重複的習慣用法
主要成功場景：
1．顧客攜帶購買的商品到達POS機收費口
2．收銀員開始一次新的銷售
3．收銀員輸入商品標識
4．…..
重複 3 – 4 步，直到結束。
5．………
3）擴展
擴展又稱之爲“替代流程”，它說明了所有其它的場景和分支。
擴展往往比主要成功場景長而且複雜，這正是我們所希望的。在寫完整用例的時候，基本流程加上擴展能滿足幾乎所有客戶的興趣。
擴展場景是從主要成功場景中分離出來的，所以標記方式應該相同，比如，第3步的一個擴展就被標記爲3a。
擴展：
3a.非法標識
1．系統指示錯誤並拒絕輸入。
3b.多個具有相同類別的商品，不需要跟蹤每個商品的唯一身份
1． 收銀員可以輸入商品類別的表識和數量。
3c.顧客要求從藝術如商品中減去一個商品
1．收銀員輸入商品標識並將其刪除。
2．系統顯示更新後的累加值。
……..
一個“擴展”有兩部分組成：條件和處理，處理的步驟可以有多個。
有時候擴展可能會非常複雜，這就需要用單個用例來完成擴展。
下面看看怎麼標記擴展中的失敗：
7b.信用卡支付
1.顧客輸入信用卡賬號
2.系統向外部信用卡授權服務系統請求支付驗證
2a系統檢測到和外部信用卡授權服務系統通信故障
1. 系統向收銀員知識發生了錯誤
2.收銀員向客戶請求更換支付方式
3…….
如果想要描述一個可能在任何一步（至少是絕大多數步驟）都會發生的條件，那麼應該使用類似“*a”、“*b”這樣的標記。
*a.任何時刻，發生一下狀況，系統將會崩潰。
1．收銀員重啓系統，登錄，請求恢復上次狀態。
2．系統重建之前的狀態。
4）特殊需求
如果有一些與這個用例有關的非功能性需求（質量屬性或約束條件），那麼應該把他們記錄在一起。
例：
特殊需求
在大型平板顯示器上觸摸屏界面，文本信息要能在一米之外看清。
90%信用卡授權機構的響應，應該能在30秒之內收到。
支持多種語言顯示。
在步驟2和步驟6種可以插入新的業務規則。
經典的統一過程建議，第一次寫出用例的時候，把特殊需求和用例寫在一起。
但現在更通用的做法是把所有非功能性需求放在“補充規範”中，這樣更容易進行內容管理，也更容易讀，因爲這些需求通常要求在進行系統整體架構分析的時候通盤考慮。
5）技術和數據的變化列表
系統通常有一些技術上的變化是關於“應該怎樣做”，而不是“應該做什麼”，需要在用例中把這些變化記錄下來。
比如，數據表示方案可能會有不同的變化，在列表中應該記錄這種變化。
技術和數據的變化列表：
3a. 商品標識可以用條碼掃描也可以用鍵盤輸入。
3b. 商品表識可以採用UPC、EAN、JAN、SKU等不同的編碼方式。
7a. 信用卡賬號信息可以使用讀卡器或鍵盤輸入。
7b. 記錄在紙面收據上的信用卡支付簽名，但我們預測，兩年內會有許多顧客希望使用數字簽名。
五、示例：銷售系統
這裏爲了把問題表達清楚，添加了一些項目。
舉個例子。
POS銷售系統
作者: _______________ 日期: ___________
版本: ___________
|
用例名:
|
Process Sale
|
用例類型
|
|
用例ID:
|
TB-SALE2.00
|
業務需求
|
|
主要業務參與者:
|
收銀員
|
|
|
項目相關人員興趣:
|
收銀員：希望能準確、快速的輸入，而且沒有支付錯誤。
售貨員：希望自動更新銷售提成。
顧客：希望購買過程能夠省力，並得到快速服務，希望得到購買證明，以便退貨。
公司：希望準確的記錄交易，並滿足顧客要求，希望保證支付授權服務的信息被記錄，希望有一定的容錯性，即使某些服務不可用也能允許收款，希望能自動快速的更新賬目和庫存信息。
政府稅務機關：希望從每筆交易中抽取稅金。
支付授權服務：希望按照正確的格式和協議收到數字授權的請求，希望準確計算給商店的應付款。
|
|
|
前置條件：
|
收銀員已經被識別和授權。
|
|
|
後置條件：
|
存儲銷售信息，準確計算稅金，更新賬目和庫存，記錄提成，生成收據。
|
|
|
觸發條件:
|
當客戶開始驗證購買的商品的時候，該用例被觸發。
|
|
|
基本流程：
|
1．顧客攜帶購買的商品到達POS機收費口
2．收銀員開始一次新的銷售
3．收銀員輸入商品標識
4．…..
重複 3 – 4 步，直到結束。
5．………
…….
10．顧客攜帶商品和收據離開
|
|
|
替代流程
|
*a.任何時刻，發生以下狀況，系統將會崩潰。
1．收銀員重啓系統，登錄，請求恢復上次狀態。
2．系統重建之前的狀態。
3a.非法標識
1．系統指示錯誤並拒絕輸入。
3b.多個具有相同類別的商品，不需要跟蹤每個商品的唯一身份
2． 收銀員可以輸入商品類別的標識和數量。
3-6a.顧客要求從已輸入商品中減去一個商品
1．收銀員輸入商品標識並將其刪除。
2．系統顯示更新後的累加值。
……..
7b.信用卡支付
1.顧客輸入信用卡賬號
2.系統向外部信用卡授權服務系統請求支付驗證
2a系統檢測到和外部信用卡授權服務系統通信故障
2. 系統向收銀員指示發生了錯誤
2.收銀員向客戶請求更換支付方式
|
|
|
結束:
|
當客戶完成支付，該用例結束。
|
|
|
特殊需求：
|
1，在大型平板顯示器上觸摸屏界面，文本信息要能在一米之外看清。
2，90%信用卡授權機構的響應，應該能在30秒之內收到。
3，支持多種語言顯示。
4，在步驟2和步驟6種可以插入新的業務規則。
|
|
|
技術和數據的變化列表：
|
3a. 商品標識可以用條碼掃描也可以用鍵盤輸入。
3b. 商品標識可以採用UPC、EAN、JAN、SKU等不同的編碼方式。
7a. 信用卡賬號信息可以使用讀卡器或鍵盤輸入。
7b. 記錄在紙面收據上的信用卡支付簽名，但我們預測，兩年內會有許多顧客希望使用數字簽名。
|
|
|
發生頻率：
|
可能會持續發生。
|
|
|
待解決問題:
|
1，什麼是稅法的變化？
2，研究遠程服務的恢復問題
3，不同的業務需要什麼樣的定製？
4，收銀員是否必須在退出系統以後帶走他的現金抽屜？
5，顧客是否可以直接使用讀卡器，而不需要收銀員代勞？
|
|
這個例子雖然不完整，但是一個實際的例子，足以給我們提供一個真實的感受。
在統一過程中提倡一種簡樸的書寫風格，也就是不考慮用戶界面，而專注於他們的意圖，只對用戶意圖和系統職責這一級描述，這點很重要。
六、案例：訂單處理子系統
1、問題陳述：
與過程分析相同。
2、參與者
通過如下分析，把問題條理化，發現參與者，注意，描述的時候不要使用隱語。
比如：要e-mail給客戶；
正確的：銷售人員要e-mail給客戶。
|
1，客戶使用公司的的Web頁面查看所選擇的電源設備標配，同時顯示價格。
2，客戶查看配置細節，可以更改配置，同時計算價格。
3，客戶選擇訂購，也可以要求銷售人員在訂單真正發出之前和自己聯繫，解釋有關細節。
4，要發出訂單，客戶必須填寫表格，包括地址，付款細節（信用卡還是支票）等。
5，客戶訂單送到系統之後， 系統由客戶服務系統取得該客戶的等級，以及由銷售策略決定的折扣。
6，銷售人員發送電子請求到倉庫管理系統，並且附上配置細節。
7，事務的細節（包括訂單號和客戶帳戶號），銷售人員要e-mail給客戶，使得客戶可以在線查詢訂單狀態。
8，倉庫從銷售人員處獲取發票，並且向客戶運送電源設備。
|
從中我們可以發現四個參與者：
客戶；
銷售人員；
倉庫管理系統；
客戶服務系統。
3、建立用例
用例表示一個完整的給用戶傳值的功能單元，不與用例通信的參與者是沒有意義的，但用例可以只爲泛化，而不與參與者通信。
我們可以建立一個表來分析，把功能需求賦予參與者和用例。注意，有些潛在的業務功能可能不在應用範圍只內，它們不能被轉換爲用例，比如倉庫裝配電源設備並且把它運送給客戶，這個任務已經超出這個系統的業務範圍，不能作爲用例。
|
編號
|
需求
|
參與者
|
用例
|
|
1
|
客戶使用電源部的Web頁面查看所選擇的電源設備標配，同時顯示價格。
|
客戶
|
顯示標準電源配置
|
|
2
|
客戶查看配置細節，可以更改配置。
|
客戶
|
構造電源配置
|
|
3
|
系統由客戶服務系統取得該客戶的等級，以及由銷售策略決定的折扣，同時計算價格。
|
客戶
客戶服務系統
|
獲取銷售策略
|
|
4
|
客戶選擇訂購，也可以要求銷售人員在訂單真正發出之前和自己聯繫，解釋有關細節。
|
客戶
銷售人員
|
訂購配置了的電源設備
請求與銷售人員聯繫
|
|
5
|
要發出訂單，客戶必須填寫表格，包括地址，付款細節（信用卡還是支票）等。
|
客戶
|
訂購配置了的電源設備
效驗和認可客戶付款
|
|
6
|
銷售人員發送電子請求到倉庫管理系統，並且附上配置細節。
|
銷售人員
倉庫管理系統
|
通知倉庫關於訂購信息
|
|
7
|
事務的細節（包括訂單號和客戶帳戶號），銷售人員要e-mail給客戶，使得客戶可以在線查詢訂單狀態。
|
銷售人員
客戶
|
訂購配置了的電源設備
更新訂購狀況
|
|
8
|
倉庫管理系統從銷售人員處獲取發票，並且向客戶運送電源設備
|
倉庫管理系統
銷售人員
|
打印發票
|
可以建立如下用例：
4、用例圖
用例圖的作用是把用例賦給參與者，用例圖是系統行爲模型的主要可視化技術。還可以建立用例之間的關係，比如圖中Extend表示“訂購配置了的計算機”可以被“客戶”擴展爲“請求與銷售人員聯繫”。而訂購配置了的電源設備包含了（include）獲取銷售策略的行爲，這種依賴關係，表達了獲取銷售策略的用例不能獨立存在，只能作爲包含它的訂購配置了的電源設備用例的一部分。
5、編寫用例文檔
用例必須用事件流文檔來描述，這個文檔表達了系統必須做什麼和參與者什麼時候激活用例。用例文檔大概10頁左右，需要完整的表達用例的過程。
|
用例名:
|
訂購配置了的電源設備
|
用例類型
|
|
用例ID:
|
|
業務用例
|
|
主要業務參與者:
|
客戶
|
|
|
描述：
|
該用例允許客戶輸入一份購物訂單，該訂單包括提供運送和發票地址，以及關於付款的詳細情況。
|
|
|
前置條件：
|
客戶通過瀏覽器進入訂單輸入的Web頁面，該頁面顯示已配置電源設備及價格的詳細信息。
當客戶在訂單信息已經顯示在屏幕上的時候，選擇“客戶”或者相似命名的功能鍵來確認訂購所配置的電源設備的時候，該用例開始。
|
|
|
後置條件：
|
如果用例成功，購物訂單記錄進系統的數據庫，否則系統的狀態不變。
|
|
|
基本流程:
|
1．系統請求客戶輸入購買細節，包括銷售人員的名字（如果知道的話）、運送信息（客戶的名字和地址）、發票細節（如果運送地址不同的話）、付款方法（信用卡和支票）以及任何其它註釋。
2．客戶選擇計算價格功能鍵來發送購買細節，系統通過客戶服務系統獲取這個等級的客戶銷售策略，然後計算購買價格。
3．客戶選擇購買功能鍵來發送訂單給系統。
4．系統給購買訂單賦與一個唯一的訂單號碼和客戶賬號，系統將訂單信息存入數據庫。
5．系統把訂單號和客戶號與所有訂單細節一起e-mail給客戶，作爲接受訂單的確認。
|
|
|
擴展流程：
|
2a，客戶對計算的價格有疑問，可以查閱客戶服務系統的相應頁面，以查詢自己的客戶等級及當前的銷售策略
3a，客戶在提供所有要求錄入的信息之前，激活購買功能鍵，系統將顯示錯誤信息，它要求提供所漏掉的信息。
3b，客戶選擇Reset（或其它相似命名）功能來恢復一個空白的購物表格，系統允許客戶重新輸入信息。
|
|
七、用例的目標
1）基本業務過程的用例
基本業務過程（EBP）是這樣定義的：
由一個人在某個時間某個地點執行一項任務，這項任務是對某一業務事件的反應，而且可以增加可度量的業務價值，並且能夠保持數據狀態的一致。
其實這個定義過於教條，業務只能由一個人完成？兩個人就不行？
所以對原則的理解不應該教條主義的處理問題，用例強調了能夠增加可見的和可度量的業務價值，而且能夠使系統和數據處於穩定和一致的狀態中。
其實我們使用EBP原則的時候，主要是在對應用進行分析的時候來尋找主要用例。
2）用例和目標
參與者都有自己的目標（或需要），因此，一個EBP級別上的用例，通常被稱之爲一個用戶目標級別上的用例。
因此，處理問題的過程應該是：
首先找出用戶的目標，然後爲每個目標定義一個用例。
3）用EBP指導原則的實例
作爲一個系統分析師，在需求分析會上可以這樣了提出問題：
系統分析師：在使用POS系統的時候，你的目標是什麼？
收銀員：快速登錄還有收款
系統分析師：你認爲登錄更高級別上的目標什麼？
收銀員：我要向系統證明身份，這樣才能允許我使用系統
系統分析師：比這更高的目標呢？
收銀員：防止盜竊、數據崩潰，不顯示不宜公開的企業信息。
我們分析一下這段對話。
“防止盜竊、數據崩潰，不顯示不宜公開的企業信息”實際上比起用戶目標要高，可以認爲是企業目標，所以在此不做考慮。
“我要向系統證明身份，這樣才能允許我使用系統”看起來接近於用戶目標，但它不是EBP級別上的行爲，因爲它不會增加可見的或者可以度量的業務價值，它是爲期它目標服務的。
而“完成一次銷售”是符合EBP原則的更高一級目標。
第五節 非功能性需求的識別
僅僅寫出用例還是不夠的，還需要識別其它種類的需求，這些將被包含在補充規範中。
例如：
簡介
功能性
日誌和錯誤處理
安全性
人性因素
可靠性
可恢復性
性能
適應性
可配置性
實現約束
比如開發的領導層堅持要使用Java開發。
採購的組件
免費開放源碼的組件
接口
值得注意的硬件和接口
觸摸屏
條碼掃描儀
數據打印機
信用卡讀卡器
簽名讀取器（第一版中不支持）
術語表
|
術語
|
定義和相關信息
|
|
商品
|
銷售的產品或服務
|
|
支付授權
|
一外部的支付授權服務提供驗證，保證銷售者得到支付
|
|
支付授權請求
|
以電子方式發送到支付授權系統的一組元素，通常是字符串，這些元素包括：商場ID，顧客賬號，數據和時戳
|
術語表也可以作爲數據字典使用。
第六節 合理的應用活動分析
一、爲什麼要應用活動建模
上面用文字表示用例事件流，可以很細膩的表達一些用例的過程，但是，當用例的事件流比較複雜的時候，單純用文字表達難以清楚的表示相互之間的關係，特別是一些併發關係，這時，可以借用活動圖來表示，活動圖更善於表達流程和併發關係。
活動圖表示了計算的步驟，每一步都是一個關於幹什麼事的狀態。因爲這個原因，執行步驟被稱之爲活動狀態。
這個圖表示了哪步應該按次序執行，哪步可以並行進行，從一個活動狀態到另一個活動狀態的轉換，稱之爲“轉換”。
如果用例文檔完成了，活動狀態可以從主要的和附加的流中間發現。
但是用例描述和活動模型之間存在着一些重要的區別，用例描述是從外部參與者的角度出發來編寫的，而活動模型則採用內部系統的觀點。
活動圖也可以在用例編寫以前，在一個高的抽象層次來理解業務進程。
活動
如果活動建模是爲了表達可視化用例中活動的次序，則活動狀態可以根據用例文檔來建立，這時，活動應該從系統的角度，而不是參與者的角度來命名。
活動圖形也可以表達活動狀態和活動行爲。
活動和行爲的區別在於其時間跨度，活動是要花時間來完成的，而行爲則可看成快照，被認爲是不花時間的。
活動視圖（Activity Diagram）主要用於對計算流程和工作流程建模，它很類似於面向過程建模中的流程圖。
使用活動圖可以表示由內部生成的動作驅動的事件流，活動圖能提醒您注意並展示並行的和同時發生的活動。比較適合建立工作流模型。
下面是一個訂單處理的活動圖。
泳道：
將模型中的活動按照職責組織起來通常很有用。
例如，可以將一個商業組織處理的所有活動組織起來。這種分配可以通過將活動組織成用線分開的不同區域來表示。由於它們的外觀的緣故，這些區域被稱作泳道。
下圖表示了一個銷售過程的活動。
活動圖並沒有表示出計算處理過程中的全部細節內容。
它只是表示了活動進行的流程但沒表示出執行活動的對象。
活動圖是設計工作的起點。爲了完成設計，每個活動必須擴展細分成一個或多個操作，每個操作被指定到具體類。
這種分配的結果引出了用於實現活動圖的設計工作。
二、案例：訂單處理子系統
1，發現活動
針對上面已經建立了用例的關於電源設備採購的例子，我們從系統用例的描述，來找出活動，注意，活動是站在設備的角度來描述的。
|
編號
|
用例描述
|
活動狀態
|
|
1
|
當客戶在訂單信息已經顯示在屏幕上的時候，選擇“客戶”或者相似命名的功能鍵來確認訂購所配置的電源設備的時候，該用例開始。
|
顯示當前配置；
獲得客戶請求
|
|
2
|
系統請求客戶輸入購買細節，包括銷售人員的名字（如果知道的話）、運送信息（客戶的名字和地址）、發票細節（如果運送地址不同的話）、付款方法（信用卡和支票）以及任何其它註釋。
|
顯示購買窗體
|
|
3
|
系統由銷售服務系統取得客戶的等級以及當前銷售策略，計算客戶購買的實際價格。
|
顯示購買價格
|
|
4
|
客戶選擇Purchase（購買，或者相似命名的）功能鍵來發送訂單給TB公司。
|
獲得購買詳細資料
|
|
5
|
系統給購買訂單賦與一個唯一的訂單號碼和客戶賬號，系統將訂單信息存入數據庫。
|
存儲訂單
|
|
6
|
系統把訂單號和客戶號與所有訂單細節一起e-mail給客戶，作爲接受訂單的確認。
|
Email訂單資料
|
|
7
|
客戶在提供所有要求錄入的信息之前，激活Purchase（或者相似命名的）功能鍵，系統將顯示錯誤信息，它要求提供所漏掉的信息。
|
獲得購買詳細資料
顯示購買窗體
|
|
8
|
客戶選擇Reset（或其它相似命名）功能來恢復一個空白的購物表格，系統允許客戶重新輸入信息。
|
顯示購買窗體
|
把標識的活動畫出來。
2，活動圖
把活動用轉換連線連接起來，就成爲活動圖。
“顯示當前配置”是初始活動狀態，在這個活動上有一個遞歸轉換的表達，描述在進行下一個活動以前，這個活動一直在反覆執行。這個方式強調了這是活動而不是行爲。
當活動轉換爲“顯示購買窗體”的時候，timeout將終止這個活動模型的執行，或者“獲得購買詳細資料”的活動被激活。
如果購買資料不完全，系統又回到“顯示購買窗體”，否則進入“存儲訂單”。並且接着進入“Email訂單資料”，然後活動結束。
一般來說，只有“退出”活動狀態被顯示出來，一般活動內部的分支，可以推斷出來。有時候重要的分支可以使用分支，並附上監護條件。
三、客戶服務子系統用例分析
下面，我們來研究一下另外一個重要的子系統，客戶服務子系統的用例分析。
1，發現參與者
客戶服務子系統主要實現客戶分級管理策略，而且可以靈活的處理促銷策略，從項目影響範圍的研究中，我們可以發現參與者。
|
參與者詞彙表
|
|
|
參與者
|
描述
|
|
基本客戶
|
已經有穩定業務往來的公司。
|
|
潛在客戶
|
預計可能有業務往來的公司。
|
|
曾經客戶
|
過去有業務往來，但是最近6個月內沒有購買設備，但仍然保持良好的身份記錄。
|
|
市場部
|
響應創建折扣和訂閱程序，併爲公司進行銷售的組織部門。
|
|
客戶服務部
|
按照合同爲客戶提供聯繫服務的組織部門。
|
|
財務部門
|
處理客戶付款和收費，以及維護客戶賬戶信息的組織部門。
|
|
時間
|
觸發時序事件的參與者。
|
|
倉庫管理子系統
|
存儲和維護TB公司產品庫存，並且處理顧客發貨和退貨的實體。
|
|
網上銷售子系統
|
實現基於Web的電源產品銷售。
|
2，確定業務需求用例
與已經建立的網上訂購項目相比，這個新系統的最大特點，是把市場行爲作爲系統的重要功能，所以功能上和以前的系統有諸多不同。
首先我們需要記錄項目的初始範圍，也就是定義一個系統應該準備支持的業務方向，這就是所謂系統上下文數據流圖，其方法是：
1，區分內部和外部，忽略內部工作，專注於外部功能。
2，詢問最終用戶系統需要響應什麼業務事務，這些業務事務就是系統的淨輸入。
3，詢問最終用於系統需要有什麼響應，這些相應就是系統的淨輸出。
4，確定外部數據存儲，以實體的形式表達，數據庫和文件一般是屬於外部的。
注意：系統上下文並不是越複雜越好，而是要把握系統功能的重點，細節問題可以在後面的詳細分析中解決。
下面是這個項目子系統的上下文。
在這個系統中定義邊界的時候，可以考慮把網上銷售子系統暫時排除在外，也就是把網上銷售子系統定義成外部接受者。我們可以建立一些用例並定義它的詞彙。
|
編號
|
用例名稱
|
用例描述
|
預期的參與者和角色
|
|
1
|
提交訂閱訂單
|
描述一個潛在客戶通過訂閱加入本系統，這個潛在客戶至少答應在兩年內購買一定數量的本公司設備。
|
潛在客戶
|
|
2
|
提交訂閱更新訂單
|
描述一個過去的客戶通過訂閱加入本系統，這個客戶過去是本公司的基本客戶，儘管6個月內這個活動一度中斷，但現在準備恢復商業活動。
|
曾經客戶
|
|
3
|
提交客戶資料修改
|
描述一個基本客戶修改他的個人資料，包括公司地址、e-mail、密碼和基本購買配置方式。
|
基本客戶
|
|
4
|
處理訂單和客戶資料
|
描述一個客戶通過網上銷售子系統提交一個TB公司產品訂單，以及有關的客戶資料，等待客戶服務子系統返回相關的折扣信息。
|
網上銷售子系統
市場部
|
|
5
|
查詢購買歷史
|
描述一個基本客戶查閱他三年內的購買歷史。
|
基本客戶
|
|
6
|
建立新客戶訂閱程序
|
描述市場部建立一個新的客戶訂閱計劃（在什麼情況下可以得到更大的優惠）來吸引新的客戶。
|
市場部
|
|
7
|
提交訂閱程序修改
|
描述市場部爲基本客戶修改訂閱計劃，比如優惠期的延長等等。
|
市場部
|
|
8
|
提交曾經客戶重新訂閱程序
|
描述市場部建立一個重新訂閱計劃，比如曾經客戶可以更短的時間內享受到優惠，以吸引回曾經客戶。
|
市場部
|
|
9
|
提交新促銷
|
描述市場部建立一個新的促銷計劃，以吸引不同的客戶來購買。需要注意，促銷計劃一般有專門的名稱，以表明在某種情況下可以以特殊的價格來購買。這些促銷產品可以集成到一個特殊的目錄中在網上公佈，並且通過e-mail發送給基本客戶。
|
市場部
|
|
10
|
修改促銷
|
描述市場部修改促銷條件。
|
市場部
|
|
11
|
每日生成默認合同報告
|
描述每天生成一個報告，列出還沒有達到“優惠級基本客戶”購買量的基本客戶，這些客戶購買量以30天、60天、120天過期三個級別排序。
|
時間（發起）
客戶服務部（外部接收者）
|
注：參與者沒有標註的爲主要業務參與者，表達他收到了某些可度量的價值。
這樣就可以畫出系統的用例圖。注意這個圖中，並沒有致力於包含和依賴關係的研究，這是因爲圖形比較複雜的時候，有些事情單獨考慮更有利，比如我們會在後面單獨考慮依賴關係，並且以此生成開發策略。
3，撰寫用例文檔
爲了更清楚的表達用例的事件流，需要寫出用例文檔，這裏只列出了“處理訂單和客戶資料”用例的文檔。
電源客戶服務系統
作者: _______________ 日期: ___________
版本: ___________
|
用例名:
|
處理訂單和客戶資料
|
用例類型
|
|
用例ID:
|
TB-ES2.00
|
業務需求
|
|
主要業務參與者:
|
網上設備銷售子系統
|
|
|
其它參與者:
|
基本客戶，曾經客戶，潛在客戶
銷售部（外部接收者）
財務部（外部接收者）
|
|
|
項目相關人員興趣:
|
客戶：對自己的級別能得到的優惠感興趣。
市場部：對銷售活動感興趣，同時也爲了計劃新的促銷。
採購部：對銷售活動感興趣，爲了補充庫存。
管理層：對銷售活動感興趣，爲了評估公司業績和客戶滿意度。
|
|
|
描述：
|
該用例描述一個客戶提交一個TB公司產品訂單和客戶資料，由客戶服務系統根據客戶級別和銷售策略計算銷售價格。
客戶的資料信息以及他的帳號被驗證，訂單提交後系統需要查詢客戶所處於的級別，再根據促銷策略，提供則扣信息，然後計算銷售價格。
|
|
|
前置條件：
|
客戶已經登錄，由網上設備銷售子系統傳送來客戶資料和購買細節。
|
|
|
後置條件：
|
訂單被記錄，向網上設備銷售子系統發送具有折扣的付款信息。
|
|
|
觸發條件:
|
當新的客戶訂單被提交的時候，該用例被觸發。
|
|
|
基本流程:
|
1，由“網上設備銷售子系統”傳遞過來客戶提交的資料信息、訂單信息和支付信息。
2，系統驗證所有信息。
3，根據客戶信息驗證客戶優惠級別。
4，對於訂購的每件產品，系統驗證產品標識。
5，對每件產品，系統根據客戶優惠級別和當前促銷政策計算價格。
7，系統計算總價格
8，系統檢查客戶付款帳號的狀態。
9，系統檢查客戶支付狀況（如果是網上支付）。
10，系統記錄訂單信息，向“網上設備銷售子系統”返回價格和優惠信息。
|
|
|
替代流程：
|
1a，客戶沒有提供足夠的信息，通知客戶重新提交。
4a，如果客戶需要的產品和TB公司提供的商品不符，則要求客戶澄清。
8a，如果客戶帳號信用不良，則把訂單掛起，並且通知客戶，退出用例。
9a，如果標準支付方式無法完成，則通知客戶，並希望客戶提供另一種支付方式。
|
|
|
結束:
|
當“網上設備銷售子系統”收到價格信息的時候，該用例結束。
|
|
|
實現約束和說明：
|
“網上設備銷售子系統”客戶爲Web界面，內部工作人員爲GUI界面。
|
|
|
待解決問題:
|
需要研究客戶對優惠級別或者促銷政策有疑問，能夠快速的和有關銷售人員聯繫，該銷售人員能夠迅速查閱信息，並作出解釋。
|
|
4，風險分析和優先級的考慮
爲了發現最重要的用例，需要對用例的重要性或者開發風險進行評估，可以採用用例分級和評估矩陣來做這個初步分析，數據的來源可以採用項目相關人員和開發團隊打分法來完成。
|
用例名稱
|
分級標準（1-5）
|
總分
|
優先級
|
構造週期
|
|||||
|
1
|
2
|
3
|
4
|
5
|
6
|
||||
|
提交訂閱訂單
|
5
|
5
|
5
|
4
|
5
|
5
|
29
|
高
|
1
|
|
處理訂單和客戶資料
|
4
|
4
|
5
|
4
|
5
|
5
|
27
|
高
|
2
|
|
建立新客戶訂閱程序
|
4
|
5
|
5
|
3
|
5
|
5
|
27
|
高
|
1
|
|
每日生成默認合同報告
|
1
|
1
|
1
|
1
|
1
|
1
|
6
|
低
|
3
|
|
修改促銷
|
2
|
2
|
3
|
3
|
4
|
4
|
18
|
中
|
2
|
|
提交新促銷
|
3
|
2
|
3
|
4
|
2
|
1
|
15
|
低
|
2
|
從上面的表中，發現“提交訂閱訂單”優先級最高，應該首先開發。但這還不能完全確定，還需要考慮用例的依賴關係。
所謂用例的依賴關係，表達的是這個用例完成的狀態（後置條件）恰恰是這個用例的前置條件。從下面的圖可以看出來，建立“新客戶訂閱程序”雖然優先級並不是最高的，但它處於依賴關係的最前端，所以應該最先開發。
四、客戶服務子系統的過程分析
從方法學的角度，儘管很多情況下我們提倡面向對象的分析，但對於系統功能來說，面向過程的分析有時還是有其優點的，因爲它直接對應於工作流程和系統的結構，事實上現代分析中，通過引入用例和事件的概念，使這種改進的過程分析仍然具有生命力，下面對於我們所研究的課題，採用過程來細化分析。
1，上下文數據流圖
這個問題已經在前面討論過，這裏就直接畫出這個系統的上下文來。
2，功能分解圖
功能分解顯示了一個系統自頂向下的分解結構，也爲我們繪製數據流圖（DFD）的提綱，下面是圖中的數字含義：
1）整個系統。
2）系統最初的子系統/功能塊。並不要求和實際的組織系統對應，分析員和用戶越來越多的被要求忽略組織邊界，構造並且理順過程和數據共享的交叉功能系統。
3）區分系統的運行部分和報告部分。
3，事件響應或用例清單
我們可以借用面向對象的用例分析來進行這一步的研究，主要是確定系統必須響應什麼業務事件，從本質上說，系統存在三類事件：
1）外部事件：該事件發生時，產生一個到系統的事件流。
2）時序事件：以時間爲基礎的處罰過程。
3）狀態事件：系統由一個狀態轉換爲另一個狀態時觸發的事件。
當使用用例分析的參與者的時候，引發事件的參與者，將成爲DFD中的外部代理，而事件將由DFD中的某個過程來處理。
下面，我們部分的列出在這裏比較合用的用例清單。
|
參與者
|
事件（或者用例）
|
觸發器
|
響應
|
|
市場部
|
制定一個新的客戶關係訂閱計劃，把潛在客戶變爲基本客戶。
|
新客戶訂閱程序
|
生成“訂閱計劃確認”，在數據庫中創建合同。
|
|
市場部
|
制定一個新的客戶關係訂閱計劃，以把曾經客戶重新變爲基本客戶。
|
曾經客戶訂閱計劃
|
生成“訂閱計劃確認”，在數據庫中創建合同。
|
|
市場部
|
爲當前客戶改變訂閱計劃（例如延長優惠時間）
|
訂閱計劃改變
|
生成“合同修改確認”，修改數據庫中合同。
|
|
（時間）
|
一個訂閱計劃過期。
|
（當前日期）
|
生成“合同修改確認”，在數據庫中邏輯的刪除（置空）合同。
|
|
市場部
|
在達到計劃的過期日期之前取消一個訂閱計劃。
|
訂閱計劃取消
|
生成“合同修改確認”，在數據庫中邏輯的刪除（置空）合同。
|
|
客戶
|
潛在客戶通過訂閱加入本系統，這個潛在客戶至少答應在兩年內購買一定數量的本公司設備。
|
新訂閱
|
生成“合同目錄修改確認”，在數據庫中創建“客戶”，在數據庫中創建第一個“客戶訂單”和“客戶訂購的產品”。
|
|
客戶
|
修改地址（包括電子郵件和密碼）
|
地址修改
|
生成“客戶目錄修改確認”，修改數據庫中的“客戶”。
|
|
財務部
|
修改客戶的信用狀態。
|
信用狀態修改
|
生成“信用目錄修改確認”，修改數據庫中的“客戶”。
|
|
訂單處理系統
|
輸入訂單和客戶資料，獲取針對具體客戶的銷售策略
|
客戶確認產品
|
生成“客戶訂購產品優惠價格”發送給訂單處理系統。
|
|
（時間）
|
市場部決定停止銷售一個商品後90天。
|
（當前日期）
|
生成“目錄修改確認”，在數據庫中邏輯的刪除（失效）“產品”。
|
|
（時間）
|
訂單處理後90天
|
（當前日期）
|
在數據庫中實際的刪除 “客戶訂單”和“客戶訂購的產品”。
|
|
客戶
|
查詢自己購買歷史記錄（3年爲限）
|
客戶購買查詢
|
生成“客戶購買歷史”。
|
|
客戶服務部
|
生成月末報告
|
（當前日期）
|
生成“月度銷售分析報告”
生成“月度客戶合同例外情況分析報告”
生成“客戶關係分析報告”
|
認真把這個通過這個表思考清楚：
1）引發事件的參與者，它們將成爲DFD的外部代理。
2）事件，它們由DFD的某個過程處理。
3）輸入或者觸發器，它們將成爲DFD中的一個數據流或者控制流。
4）所有的輸出響應，它們也將成爲DFD中的數據流，注意我們是用括號來表達時序事件。5）輸出，注意這裏不要暗示實現方式，當我們使用報告這個詞的時候，並不一定指的是書面報告。輸出包括了修改數據模型中存儲的實體模型，比如創建新的實體實例、修改實體的現有實例以及刪除實體實例等。
一個系統的用例可能很多，對於設計者來說詳細的列出是非常有必要的，仔細研究這些用例，然後給每一個事件分配一個子系統功能，可以繪製出事件分解圖。
4，事件分解圖
爲了進一步分解功能，我們把每個用例的事件處理過程分解到圖中，這個圖可以認爲是前面功能分解圖的一個細化，如果太複雜，必要的時候可以多頁來繪製。這個圖可以作爲分析和設計的一個提綱。
5，事件圖和系統圖
現在我們的眼睛盯住具體的細節，爲每個事件過程繪製一個事件圖，它們集合在一起定義了系統和子系統，系統圖更多的是從宏觀的角度看爲題，更多的考慮相互關係，具體的繪圖學員可以自己來完成。
