北美IT 求職必備技術—RUP
作者：李訓軍博士
隨著現代信息產業的蓬勃發展，軟件開發已經成為一項浩大繁複的工程。 就像是建造一座宏偉的宮殿， 從計劃、設計到施工， 每一個環節都必須嚴格把關， 稍有不慎， 整個工程就會失敗。 據統計， 僅在美國， 每年就有180,000個信息技術項目， 耗資大約$2500億美元， 其中25-30%的項目會流產。 由此可見， 由於管理不善和設計上的失誤所造成的損失是巨大的。現代軟件開發的管理和方法論顯得比以往任何時候都更為重要。
軟件開發的過程由方法論和工具構成（process = methodology + tools）。正如裝配電子設備一樣，僅有工具就可以勝任裝配任務。但為了減少失誤和提高效率，人們往往採用流水線作業，流水線作業便是一種應用於電子設備裝配中的方法論。目前，信息技術市場流行的方法論有RUP(Rational Unified Process), The Zachman Framework, XP (Extreme Programming)等。在這些方法論中，最流行的要數RUP。RUP是由Rational Software公司首創的。因它與當前流行的JAVA, J2EE技術和麵向對象的設計思想（OOAD）緊密的結合在一起，所以在大型的信息技術項目中得到了廣泛的應用。在這篇文章中，我們試圖對RUP的特點作一個初步的探討，並且討論它是如何貫穿在整個軟件開發的生命週期之中的。
RUP最重要的它有三大特點：1）軟件開發是一個疊代過程，2）軟件開發是由Use Case驅動的，3）軟件開發是以構架設計（Architectural Design）為中心的。
按照傳統的瀑布（Waterfall）開發模式，軟件開發大致經歷如下幾個步驟：商務需求分析（Business Requirement Analysis），系統分析（System Analysis），系統設計（System Design），開發實現（Implementation），測試（Test），發佈（Deployment），系統支持（Supporting）和系統變更管理（Change Management）。傳統的瀑布開發模式假定在進行新的開發過程時，上一個過程已經完成，而且不會回到上一個過程。初看起來，這似乎是一個非常合理，高效率的解決方案，但20多年的實踐證明，這個開發模式存在著很大的弊病，原因是軟件開發是一個非常複雜的工程，有諸多的因素影響工程的效率和成敗。軟件開發需要許多不同背景的個人和團隊參與。由於這些複雜性，在軟件開發的整個生命週期中每一個階段都有可能留下隱患和錯誤。如果等到系統已經開發實現完畢，在測試階段發現了重大問題，這時的返工將會造成人力、物力、財力及時間上的巨大浪費。鑑於以上的考慮，RUP強調軟件開發是一個疊代模型（Iterative Model），RUP定義了四個階段(Phase)：開端(Inception)，闡述 (Elaboration)，建造(Construction)，過渡(Transition)。其中每個階段都有可能經歷以上所提到的從商務需求分析開始的各個步驟，只是每個步驟的高峰期會發生在相應的階段。例如開發實現的高峰期是發生在建造階段。實際上這樣的一個開發方法論是一個二維模型。這種疊代模型的實現在很大程度上提供了及早發現隱患和錯誤的機會，因此被現代大型信息技術項目所採用。
RUP 的另一大特徵是Use Case 驅動。Use Case 是RUP方法論中一個非常重要的概念。簡單地說，一個 Use Case就是系統的一個功能。例如在一個基於電子商務的醫療系統中，病人可以坐在家裡通過網上瀏覽器與醫生約定看病的時間 (Make appointment)，這樣，「Make appointment」就是系統的一個Use Case。在系統分析和系統設計中， Use Case被用來將一個複雜的龐大系統分割、定義成一個個小的單元，這個小的單元就是Use Case,然後以每個小的單元為對象進行開發。按照 RUP, Use Case貫穿整個軟件開發的生命週期。在商務需求分析中，客戶或用戶對Use Case進行描述，在系統分佈和系統設計過程中，設計師對Use Case進行分析，在開發實現過程中，開發編程人員對Use Case進行實現，在測試過程中，測試人員對Use Case進行檢驗。
RUP的第三大特徵是它強調軟件開發是以構架為中心的。構架設計（Architectural Design）是系統設計的一個重要組成部分。在構架設計過程中，設計師(Architect)必須完成對技術和運行平台的選取，整個項目的基礎框架(Framework)的設計，完成對公共組件的設計，如審計(Auditing)系統，日誌(Log)系統，錯誤處理(Exception Handling)系統，安全 (Security)系統等。設計師必須對系統的可擴展性(Extensibility)，安全性(Security)，可維護性 (Maintainability)，可延拓性(Scalability)，可重用性(Reusability)和運行速度(Performance)提出可行的解決方案。
在RUP方法論中，不同的角色可以從不同的側面來認識同一個項目。RUP定義了「4+1」個場景(View）： Use Case場景(Use Case View)，邏輯場景(Logic View)，進程場景(process View)，實現場景 (Implementation View)和發佈場景(Deployment View)。在Use Case場景中，客戶和商務分析員對 Use Case進行描述，在邏輯場景中，設計師對系統進行分析和設計，在進程場景中，設計師對系統可能出現的併發性，運行速度和分佈特性進行描述。實現場景則反映了程序開發員開發實現的過程。發佈場景是描述系統管理員和組裝人員實施系統發佈和管理的過程。值得強調的是，系統構架的設計是在邏輯場景中描述的。
RUP還定義了4個模型，即Use Case模型（Use Case Model），分析模型 (Analysis Model)，設計模型(Design Model)和實現模型(Implementation Model)。Use Case模型包含Use Case Diagram和Use Case文檔。Use Case模型是其他三個模型的基礎，分析模型即是概念模型 (Conceptual Model)，是系統分析所得到的結果，分析模型包含了類圖(Class Diagram)，次序圖 (Sequence Diagram)以及活動圖(Activity Diagram)。設計模型則是構架設計和系統設計的結果。當設計模型完成後，開發編程人員便可以進行編程了。設計模型主要包含了類圖，次序圖和狀態圖(State Chart Diagrams)。分析模型和設計模型看起來有許多相似之處，但兩者的含義有本質的區別。分析模型強調的是問題的範圍，但並不給出解決問題的方案，分析模型並不涉及具體的技術和平台。例如它並不關心是否應用 EJB或一般的JAVA BEANS，系統是安裝在WebSphere或是在WebLogic。但是與之相反，設計模型要考慮這些細節，而且要提供解決這些問題的全部方案。當然設計模型是建立在分析模型之上的，分析模型中的一個類可直接映射成為設計模型中的類，但這種映射關係一般並不是一一對應的，最後一個模型是實現模型。實現模型包含構件圖（Component Diagram），從這個模型出發，開發編程人員可以產生骨架源程序 (Skeleton Source Code)，也可以從源程序出發更新設計模型。
目前應用於系統分析和設計的工具主要有Rational Rose和Together Software Center (TogetherJ)。JAVA和J2EE的開發工具有IBM Websphere Application Developer(WSAD), Borland Jbuilde和WebGain VisualCafe. WSAD和WebSphere Application Server應用在一起，使得服務器端的排錯和系統的發布變得非常的容易。Jbuilder和VisualCafe一般與WebLogic Server緊密結合在一起。目前WebSphere Server和WebLogic Server佔據了Application Server市場的66%，其中 WebSphere Server佔據了37%，成為同類產品的No.1。在單位測試和集成測試中，廣泛應用的工具和框架有Junit, JunitPerf和Cactus.。
綜上所述，軟件開發的方法論已經成為現代軟件工程過程中不可缺少的一個重要部分。是目前在Java/J2EE和麵向對象的大型項目中廣泛被採用的一種方法論。他對整個軟件開發的生命週期提供了基礎框架和指導。RUP, UML/Rational Rose, Java/J2EE, WSAD, Websphere Application Server和Oracle這樣的技術、工具和平台的組合是目前許多公司、政府信息技術項目中採用的方案。因此，RUP的知識和經驗也是現在求職市場所需求的熱門技能。
2007年4月30日 星期一
RUP
原文在此
一 前言
軟件過程是指實施於軟件開發和維護中的階段、方法、技術、實踐及相關產物(計劃、文檔、模型、代碼、測試用例和手冊等)的集合。行之有效的軟件過程可以提高開發軟件組織的生產效率、提高軟件質量、降低成本並減少風險。
RUP具有較高認知度的原因之一恐怕是因為其提出者Rational軟件公司聚集了物件導向領域三位傑出專家Booch、Rumbaugh和 Jacobson，同時它又是物件導向開發的行業標準語言——標準建模語言(UML)的創立者。RUP是由Objectory過程演化而來。本文主要討論 RUP的主要內容和特點。
二 RUP的二維開發模型
RUP可以用二維坐標來描述。橫軸通過時間組織，是過程展開的生命週期特徵，體現開發過程的動態結構，用來描述它的術語主要包括週期 (Cycle)、階段(Phase)、迭代(Iteration)和里程碑(Milestone)；縱軸以內容來組織為自然的邏輯活動，體現開發過程的靜態結構，用來描述它的術語主要包括活動(Activity)、產物(Artifact)、工作者(Worker)和工作流(Workflow)。
三 開發過程中的各個階段和里程碑
RUP中的軟件生命週期在時間上被分解為四個順序的階段，分別是：初始階段(Inception)、細化階段(Elaboration)、構建階段(Construction)和交付階段(Transition)。每個階段結束於一個主要的里程碑(Major Milestones)；每個階段本質上是兩個里程碑之間的時間跨度。在每個階段的結尾執行一次評估以確定這個階段的目標是否已經滿足。如果評估結果令人滿意的話，可以允許項目進入下一個階段。
初始階段(Inception Phase)
初始階段的目標是為系統建立商業案例並確定項目的邊界。為了達到該目的必須識別所有與系統交互的外部實體，在較高層次上定義交互的特性。本階段具有非常重要的意義，在這個階段中所關注的是整個項目進行中的業務和需求方面的主要風險。對於建立在原有系統基礎上的開發項目來講，初始階段可能很短。
初始階段結束時是第一個重要的里程碑：生命週期目標(Lifecycle Objective)里程碑。生命週期目標里程碑評價項目基本的生存能力。
細化階段(Elaboration Phase)
細化階段的目標是分析問題領域，建立健全的體系結構基礎，編製項目計劃，淘汰項目中最高風險的元素。為了達到該目的，必須在理解整個系統的基礎上，對體系結構作出決策，包括其範圍、主要功能和諸如性能等非功能需求。同時為項目建立支持環境，包括創建開發案例，創建模板、準則並準備工具。
細化階段結束時第二個重要的里程碑：生命週期結構(Lifecycle Architecture)里程碑。生命週期結構里程碑為系統的結構建立了管理基準並使項目小組能夠在構建階段中進行衡量。此刻，要檢驗詳細的系統目標和範圍、結構的選擇以及主要風險的解決方案。
構建階段(Construction Phase)
在構建階段，所有剩餘的構件和應用程序功能被開發並集成為產品，所有的功能被詳細測試。從某種意義上說，構建階段是一個製造過程，其重點放在管理資源及控制運作以優化成本、進度和質量。
構建階段結束時是第三個重要的里程碑：初始功能(Initial Operational)里程碑。初始功能里程碑決定了產品是否可以在測試環境中進行部署。此刻，要確定軟件、環境、用戶是否可以開始系統的運作。此時的產品版本也常被稱為「beta」版。
交付階段(Transition Phase)
交付階段的重點是確保軟件對最終用戶是可用的。交付階段可以跨越幾次迭代，包括為發佈做準備的產品測試，基於用戶反饋的少量的調整。在生命週期的這一點上，用戶反饋應主要集中在產品調整，設置、安裝和可用性問題，所有主要的結構問題應該已經在項目生命週期的早期階段解決了。
在交付階段的終點是第四個里程碑：產品發佈(Product Release)里程碑。此時，要確定目標是否實現，是否應該開始另一個開發週期。在一些情況下這個里程碑可能與下一個週期的初始階段的結束重合。
四 RUP的核心工作流(Core Workflows)
RUP中有9個核心工作流，分為6個核心過程工作流(Core Process Workflows)和3個核心支持工作流(Core Supporting Workflows)。儘管6個核心過程工作流可能使人想起傳統瀑布模型中的幾個階段，但應注意迭代過程中的階段是完全不同的，這些工作流在整個生命週期中一次又一次被訪問。9個核心工作流在項目中輪流被使用，在每一次迭代中以不同的重點和強度重複。
商業建模(Business Modeling)
商業建模工作流描述了如何為新的目標組織開發一個構想，並基於這個構想在商業用例模型和商業對像模型中定義組織的過程，角色和責任。
需求(Requirements)
需求工作流的目標是描述系統應該做什麼，並使開發人員和用戶就這一描述達成共識。為了達到該目標，要對需要的功能和約束進行提取、組織、文檔化；最重要的是理解系統所解決問題的定義和範圍。
分析和設計(Analysis & Design)
分析和設計工作流將需求轉化成未來系統的設計，為系統開發一個健壯的結構並調整設計使其與實現環境相匹配，優化其性能。分析設計的結果是一個設計模型和一個可選的分析模型。設計模型是源代碼的抽像，由設計類和一些描述組成。設計類被組織成具有良好接口的設計包(Package)和設計子系統 (Subsystem)，而描述則體現了類的對象如何協同工作實現用例的功能。
設計活動以體系結構設計為中心，體系結構由若干結構視圖來表達，結構視圖是整個設計的抽像和簡化，該視圖中省略了一些細節，使重要的特點體現得更加清晰。體系結構不僅僅是良好設計模型的承載媒介，而且在系統的開發中能提高被創建模型的質量。
實現(Implementation)
實現工作流的目的包括以層次化的子系統形式定義代碼的組織結構；以組件的形式(源文件、二進制文件、可執行文件)實現類和對像；將開發出的組件作為單元進行測試以及集成由單個開發者（或小組）所產生的結果，使其成為可執行的系統。
測試(Test)
測試工作流要驗證對像間的交互作用，驗證軟件中所有組件的正確集成，檢驗所有的需求已被正確的實現, 識別並確認缺陷在軟件部署之前被提出並處理。RUP提出了迭代的方法，意味著在整個項目中進行測試，從而儘可能早地發現缺陷，從根本上降低了修改缺陷的成本。測試類似於三維模型，分別從可靠性、功能性和系統性能來進行。
部署(Deployment)
部署工作流的目的是成功的生成版本並將軟件分發給最終用戶。部署工作流描述了那些與確保軟件產品對最終用戶具有可用性相關的活動，包括：軟件打包、生成軟件本身以外的產品、安裝軟件、為用戶提供幫助。在有些情況下，還可能包括計劃和進行beta測試版、移植現有的軟件和數據以及正式驗收。
配置和變更管理(Configuration & Change Management)
配置和變更管理工作流描繪了如何在多個成員組成的項目中控制大量的產物。配置和變更管理工作流提供了準則來管理演化系統中的多個變體，跟蹤軟件創建過程中的版本。工作流描述了如何管理並行開發、分佈式開發、如何自動化創建工程。同時也闡述了對產品修改原因、時間、人員保持審計記錄。
項目管理(Project Management)
軟件項目管理平衡各種可能產生衝突的目標，管理風險，克服各種約束併成功交付使用戶滿意的產品。其目標包括：為項目的管理提供框架，為計劃、人員配備、執行和監控項目提供實用的準則，為管理風險提供框架等。
環境(Environment)
環境工作流的目的是向軟件開發組織提供軟件開發環境，包括過程和工具。環境工作流集中於配置項目過程中所需要的活動，同樣也支持開發項目規範的活動，提供了逐步的指導手冊並介紹了如何在組織中實現過程。
五 RUP的迭代開發模式
RUP中的每個階段可以進一步分解為迭代。一個迭代是一個完整的開發循環，產生一個可執行的產品版本，是最終產品的一個子集，它增量式地發展，從一個迭代過程到另一個迭代過程到成為最終的系統。
傳統上的項目組織是順序通過每個工作流，每個工作流只有一次，也就是我們熟悉的瀑布生命週期。這樣做的結果是到實現末期產品完成並開始測試，在分析、設計和實現階段所遺留的隱藏問題會大量出現，項目可能要停止並開始一個漫長的錯誤修正週期。
一種更靈活，風險更小的方法是多次通過不同的開發工作流，這樣可以更好的理解需求，構造一個健壯的體系結構，並最終交付一系列逐步完成的版本。這叫做一個迭代生命週期。在工作流中的每一次順序的通過稱為一次迭代。軟件生命週期是迭代的連續，通過它，軟件是增量的開發。一次迭代包括了生成一個可執行版本的開發活動，還有使用這個版本所必需的其他輔助成分，如版本描述、用戶文檔等。因此一個開發迭代在某種意義上是在所有工作流中的一次完整的經過，這些工作流至少包括：需求工作流、分析和設計工作流、實現工作流、測試工作流。其本身就像一個小型的瀑布項目。
與傳統的瀑布模型相比較，迭代過程具有以下優點：
降低了在一個增量上的開支風險。如果開發人員重複某個迭代，那麼損失只是這一個開發有誤的迭代的花費。
降低了產品無法按照既定進度進入市場的風險。通過在開發早期就確定風險，可以儘早來解決而不至於在開發後期匆匆忙忙。
加快了整個開發工作的進度。因為開發人員清楚問題的焦點所在，他們的工作會更有效率。
由於用戶的需求並不能在一開始就作出完全的界定，它們通常是在後續階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些。
六 總結
RUP具有很多長處：提高了團隊生產力，在迭代的開發過程、需求管理、基於組件的體系結構、可視化軟件建模、驗證軟件質量及控制軟件變更等方面，針對所有關鍵的開發活動為每個開發成員提供了必要的準則、模板和工具指導，並確保全體成員共享相同的知識基礎。它建立了簡潔和清晰的過程結構，為開發過程提供較大的通用性。但同時它也存在一些不足： RUP只是一個開發過程，並沒有涵蓋軟件過程的全部內容，例如它缺少關於軟件運行和支持等方面的內容；此外，它沒有支持多項目的開發結構，這在一定程度上降低了在開發組織內大範圍實現重用的可能性。可以說RUP是一個非常好的開端，但並不完美。
一 前言
軟件過程是指實施於軟件開發和維護中的階段、方法、技術、實踐及相關產物(計劃、文檔、模型、代碼、測試用例和手冊等)的集合。行之有效的軟件過程可以提高開發軟件組織的生產效率、提高軟件質量、降低成本並減少風險。
RUP具有較高認知度的原因之一恐怕是因為其提出者Rational軟件公司聚集了物件導向領域三位傑出專家Booch、Rumbaugh和 Jacobson，同時它又是物件導向開發的行業標準語言——標準建模語言(UML)的創立者。RUP是由Objectory過程演化而來。本文主要討論 RUP的主要內容和特點。
二 RUP的二維開發模型
RUP可以用二維坐標來描述。橫軸通過時間組織，是過程展開的生命週期特徵，體現開發過程的動態結構，用來描述它的術語主要包括週期 (Cycle)、階段(Phase)、迭代(Iteration)和里程碑(Milestone)；縱軸以內容來組織為自然的邏輯活動，體現開發過程的靜態結構，用來描述它的術語主要包括活動(Activity)、產物(Artifact)、工作者(Worker)和工作流(Workflow)。
三 開發過程中的各個階段和里程碑
RUP中的軟件生命週期在時間上被分解為四個順序的階段，分別是：初始階段(Inception)、細化階段(Elaboration)、構建階段(Construction)和交付階段(Transition)。每個階段結束於一個主要的里程碑(Major Milestones)；每個階段本質上是兩個里程碑之間的時間跨度。在每個階段的結尾執行一次評估以確定這個階段的目標是否已經滿足。如果評估結果令人滿意的話，可以允許項目進入下一個階段。
初始階段(Inception Phase)
初始階段的目標是為系統建立商業案例並確定項目的邊界。為了達到該目的必須識別所有與系統交互的外部實體，在較高層次上定義交互的特性。本階段具有非常重要的意義，在這個階段中所關注的是整個項目進行中的業務和需求方面的主要風險。對於建立在原有系統基礎上的開發項目來講，初始階段可能很短。
初始階段結束時是第一個重要的里程碑：生命週期目標(Lifecycle Objective)里程碑。生命週期目標里程碑評價項目基本的生存能力。
細化階段(Elaboration Phase)
細化階段的目標是分析問題領域，建立健全的體系結構基礎，編製項目計劃，淘汰項目中最高風險的元素。為了達到該目的，必須在理解整個系統的基礎上，對體系結構作出決策，包括其範圍、主要功能和諸如性能等非功能需求。同時為項目建立支持環境，包括創建開發案例，創建模板、準則並準備工具。
細化階段結束時第二個重要的里程碑：生命週期結構(Lifecycle Architecture)里程碑。生命週期結構里程碑為系統的結構建立了管理基準並使項目小組能夠在構建階段中進行衡量。此刻，要檢驗詳細的系統目標和範圍、結構的選擇以及主要風險的解決方案。
構建階段(Construction Phase)
在構建階段，所有剩餘的構件和應用程序功能被開發並集成為產品，所有的功能被詳細測試。從某種意義上說，構建階段是一個製造過程，其重點放在管理資源及控制運作以優化成本、進度和質量。
構建階段結束時是第三個重要的里程碑：初始功能(Initial Operational)里程碑。初始功能里程碑決定了產品是否可以在測試環境中進行部署。此刻，要確定軟件、環境、用戶是否可以開始系統的運作。此時的產品版本也常被稱為「beta」版。
交付階段(Transition Phase)
交付階段的重點是確保軟件對最終用戶是可用的。交付階段可以跨越幾次迭代，包括為發佈做準備的產品測試，基於用戶反饋的少量的調整。在生命週期的這一點上，用戶反饋應主要集中在產品調整，設置、安裝和可用性問題，所有主要的結構問題應該已經在項目生命週期的早期階段解決了。
在交付階段的終點是第四個里程碑：產品發佈(Product Release)里程碑。此時，要確定目標是否實現，是否應該開始另一個開發週期。在一些情況下這個里程碑可能與下一個週期的初始階段的結束重合。
四 RUP的核心工作流(Core Workflows)
RUP中有9個核心工作流，分為6個核心過程工作流(Core Process Workflows)和3個核心支持工作流(Core Supporting Workflows)。儘管6個核心過程工作流可能使人想起傳統瀑布模型中的幾個階段，但應注意迭代過程中的階段是完全不同的，這些工作流在整個生命週期中一次又一次被訪問。9個核心工作流在項目中輪流被使用，在每一次迭代中以不同的重點和強度重複。
商業建模(Business Modeling)
商業建模工作流描述了如何為新的目標組織開發一個構想，並基於這個構想在商業用例模型和商業對像模型中定義組織的過程，角色和責任。
需求(Requirements)
需求工作流的目標是描述系統應該做什麼，並使開發人員和用戶就這一描述達成共識。為了達到該目標，要對需要的功能和約束進行提取、組織、文檔化；最重要的是理解系統所解決問題的定義和範圍。
分析和設計(Analysis & Design)
分析和設計工作流將需求轉化成未來系統的設計，為系統開發一個健壯的結構並調整設計使其與實現環境相匹配，優化其性能。分析設計的結果是一個設計模型和一個可選的分析模型。設計模型是源代碼的抽像，由設計類和一些描述組成。設計類被組織成具有良好接口的設計包(Package)和設計子系統 (Subsystem)，而描述則體現了類的對象如何協同工作實現用例的功能。
設計活動以體系結構設計為中心，體系結構由若干結構視圖來表達，結構視圖是整個設計的抽像和簡化，該視圖中省略了一些細節，使重要的特點體現得更加清晰。體系結構不僅僅是良好設計模型的承載媒介，而且在系統的開發中能提高被創建模型的質量。
實現(Implementation)
實現工作流的目的包括以層次化的子系統形式定義代碼的組織結構；以組件的形式(源文件、二進制文件、可執行文件)實現類和對像；將開發出的組件作為單元進行測試以及集成由單個開發者（或小組）所產生的結果，使其成為可執行的系統。
測試(Test)
測試工作流要驗證對像間的交互作用，驗證軟件中所有組件的正確集成，檢驗所有的需求已被正確的實現, 識別並確認缺陷在軟件部署之前被提出並處理。RUP提出了迭代的方法，意味著在整個項目中進行測試，從而儘可能早地發現缺陷，從根本上降低了修改缺陷的成本。測試類似於三維模型，分別從可靠性、功能性和系統性能來進行。
部署(Deployment)
部署工作流的目的是成功的生成版本並將軟件分發給最終用戶。部署工作流描述了那些與確保軟件產品對最終用戶具有可用性相關的活動，包括：軟件打包、生成軟件本身以外的產品、安裝軟件、為用戶提供幫助。在有些情況下，還可能包括計劃和進行beta測試版、移植現有的軟件和數據以及正式驗收。
配置和變更管理(Configuration & Change Management)
配置和變更管理工作流描繪了如何在多個成員組成的項目中控制大量的產物。配置和變更管理工作流提供了準則來管理演化系統中的多個變體，跟蹤軟件創建過程中的版本。工作流描述了如何管理並行開發、分佈式開發、如何自動化創建工程。同時也闡述了對產品修改原因、時間、人員保持審計記錄。
項目管理(Project Management)
軟件項目管理平衡各種可能產生衝突的目標，管理風險，克服各種約束併成功交付使用戶滿意的產品。其目標包括：為項目的管理提供框架，為計劃、人員配備、執行和監控項目提供實用的準則，為管理風險提供框架等。
環境(Environment)
環境工作流的目的是向軟件開發組織提供軟件開發環境，包括過程和工具。環境工作流集中於配置項目過程中所需要的活動，同樣也支持開發項目規範的活動，提供了逐步的指導手冊並介紹了如何在組織中實現過程。
五 RUP的迭代開發模式
RUP中的每個階段可以進一步分解為迭代。一個迭代是一個完整的開發循環，產生一個可執行的產品版本，是最終產品的一個子集，它增量式地發展，從一個迭代過程到另一個迭代過程到成為最終的系統。
傳統上的項目組織是順序通過每個工作流，每個工作流只有一次，也就是我們熟悉的瀑布生命週期。這樣做的結果是到實現末期產品完成並開始測試，在分析、設計和實現階段所遺留的隱藏問題會大量出現，項目可能要停止並開始一個漫長的錯誤修正週期。
一種更靈活，風險更小的方法是多次通過不同的開發工作流，這樣可以更好的理解需求，構造一個健壯的體系結構，並最終交付一系列逐步完成的版本。這叫做一個迭代生命週期。在工作流中的每一次順序的通過稱為一次迭代。軟件生命週期是迭代的連續，通過它，軟件是增量的開發。一次迭代包括了生成一個可執行版本的開發活動，還有使用這個版本所必需的其他輔助成分，如版本描述、用戶文檔等。因此一個開發迭代在某種意義上是在所有工作流中的一次完整的經過，這些工作流至少包括：需求工作流、分析和設計工作流、實現工作流、測試工作流。其本身就像一個小型的瀑布項目。
與傳統的瀑布模型相比較，迭代過程具有以下優點：
降低了在一個增量上的開支風險。如果開發人員重複某個迭代，那麼損失只是這一個開發有誤的迭代的花費。
降低了產品無法按照既定進度進入市場的風險。通過在開發早期就確定風險，可以儘早來解決而不至於在開發後期匆匆忙忙。
加快了整個開發工作的進度。因為開發人員清楚問題的焦點所在，他們的工作會更有效率。
由於用戶的需求並不能在一開始就作出完全的界定，它們通常是在後續階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些。
六 總結
RUP具有很多長處：提高了團隊生產力，在迭代的開發過程、需求管理、基於組件的體系結構、可視化軟件建模、驗證軟件質量及控制軟件變更等方面，針對所有關鍵的開發活動為每個開發成員提供了必要的準則、模板和工具指導，並確保全體成員共享相同的知識基礎。它建立了簡潔和清晰的過程結構，為開發過程提供較大的通用性。但同時它也存在一些不足： RUP只是一個開發過程，並沒有涵蓋軟件過程的全部內容，例如它缺少關於軟件運行和支持等方面的內容；此外，它沒有支持多項目的開發結構，這在一定程度上降低了在開發組織內大範圍實現重用的可能性。可以說RUP是一個非常好的開端，但並不完美。
2007年4月1日 星期日
連線方式
Datagram可提供應用程式 Connectionless(UDP) 與 Connect-Oriented(TCP) 二種服務
(一) Connection-Oriented style(連結式網路通訊)
線路交換(Circuit Switching)連線時資源專屬(dedicated)，故效率與頻寬保證技術上是以電路方式進行傳輸，系統保留一條點對點傳輸的頻寬，以64Kbps速率傳送語音，當電話接通，這段頻寬便完全佔線，直到兩端通完電話為止，這樣的技術是以全雙工(full duplex) 的傳輸方式，也稱為connection-oriented。使用connection oriented傳送資料如果中斷，就必須重新傳輸直到傳送完畢。
(二) Connectionless style(非連結式網路通訊)
無連接描述的是兩個網路終端點之間的通信，消息從一個終端點發送到另一個終端點，並且不需要按照先前的排列。從一個終端發送到另一個終端的設備，在發送資料時不需要確認另一個終端點已經準備接收資料，此設備只需按照給出的位址發送資料即可。如果傳輸中發生問題，它可能會再次重複發送資料，並嘗試幾次。
ex. connectionless: 就是不先確認狀況(不管是否可和對方通訊)就進行通訊的方法。
(一) Connection-Oriented style(連結式網路通訊)
線路交換(Circuit Switching)連線時資源專屬(dedicated)，故效率與頻寬保證技術上是以電路方式進行傳輸，系統保留一條點對點傳輸的頻寬，以64Kbps速率傳送語音，當電話接通，這段頻寬便完全佔線，直到兩端通完電話為止，這樣的技術是以全雙工(full duplex) 的傳輸方式，也稱為connection-oriented。使用connection oriented傳送資料如果中斷，就必須重新傳輸直到傳送完畢。
(二) Connectionless style(非連結式網路通訊)
無連接描述的是兩個網路終端點之間的通信，消息從一個終端點發送到另一個終端點，並且不需要按照先前的排列。從一個終端發送到另一個終端的設備，在發送資料時不需要確認另一個終端點已經準備接收資料，此設備只需按照給出的位址發送資料即可。如果傳輸中發生問題，它可能會再次重複發送資料，並嘗試幾次。
ex. connectionless: 就是不先確認狀況(不管是否可和對方通訊)就進行通訊的方法。
2007年1月4日 星期四
2006年12月27日 星期三
Bash內建參數
Bash內建參數 |
|---|
| 來源:http://www.openchess.org/noitatsko/programming/ (2001-05-25 21:04:01) |
| PPID : 該bash的呼叫者process ID. PWD : 目前的工作目錄。 OLDPWD : 上一個工作目錄。 REPLY : 當read命令沒有參數時，直接設在REPLY上。 UID : User ID。 EUID : Effective User ID。 BASH : Bash的完整路徑。 BASH_VERSION : Bash版本。 SHLVL : 每次有Bash執行時，數字加一。 RANDOM : 每次這個參數被用到時，就會產生一個亂數在RANDOM上。 SECONDS : 從這個Shell一開始啟動後的時間。 LINENO : Script的行數。 HISTCMD : 歷史記錄數。 OPTARG : getopts處理的最後一個選項參數。 OPTIND : 下一個要由getopts所處理的參數號碼。 HOSTTYPE : 機器種類。 OSTYPE : 作業系統名稱。 IFS : Internal Field Separator。 PATH : 命令搜尋路徑。 PATH="/usr/gnu/bin:/usr/local/bin:/usr/ucb:/bin:/usr/bin:." HOME : 目前使用者的home directory; CDPATH : cd命令的搜尋路徑。 ENV : 如果這個參數被設定，每次有shell script被執行時，將會執行它所設定的檔名做為環境設定。 MAIL : 如果這個參數被設定，而且MAILPATH沒有被設定，那麼有信件進來時，bash會通知使用者。 MAILCHECK : 設定多久時間檢查郵件一次。 MAILPATH : 一串的郵件檢查路徑。 MAIL_WARNING : 如果有設定的話，郵件被讀取後，將會顯示訊息。 PS1 : 提示訊息設定，內定為"bash\$ "。(請詳見提示訊息一節。) PS2 : 第二提示訊息設定，內定為"> "。 PS3 : select命令所使用的提示訊息。 PS4 : 執行追蹤時用的提示訊息設定，內定為"+ "。 HISTSIZE : 命令歷史記錄量，內定為500。 HISTFILE : 歷史記錄檔，內定~/.bash_history。 HISTFILESIZE : 歷史記錄檔行數最大值，內定500。 OPTERR : 如果設為1，bash會顯示getopts的錯誤。 PROMPT_COMMAND : 如果設定的話，該值會在每次執行命令前都顯示。 IGNOREEOF : 將EOF值當成輸入，內定為10。 TMOUT : 如果設為大於零，該值被解譯為輸入等待秒數。若無輸入，當成沒有輸入。 FCEDIT : fc命令的內定編輯器。 FIGNORE : 請詳見READLINE。 INPUTRC : readline的startup file，內定~/.inputrc notify : 如果設定了，bash立即報告被終結的背景程式。 history_control, HISTCONTROL : history使用。 command_oriented_history : 存入多行指令。 glob_dot_filenames : 如果設定了，bash將會把"."包含入檔案路徑中。 allow_null_glob_expansion : 如果設定了，bash允許路徑明稱為null string。 histchars : history使用。 nolinks : 如果設定了，執行指令時，不會跟隨symbolic links。 hostname_completion_file, HOSTFILE : 包含與/etc/hosts相同格式的檔名。 noclobber : 如果設定了，Bash不會覆寫任何由">"、">&"及"<>"所操作的檔案。 auto_resume : 請見任務控制一節。 no_exit_on_failed_exec : 如果該值存在，非互動的shell不會因為exec失敗而跳出。 cdable_vars : 如果啟動，而cd命令找不到目錄，可切換到參數形態指定的目錄下。 |
系統預設已經有相當多的變數定義了, 因此在你的shell script裡面 要去避免這些變數. 以下就是一些預設的系統變數.
BASH_ENV absolute path of startup file
CDPATH directories searched by cd
FCEDIT absolute path of history editor
HISTCMD the history number of the current command
HISFILE absolute path of history file
HISTSIZE number of remembered commands
HOME login directory
IFS token delimiters
LINENO current line number in shell script
LINES terminal height
MAIL absolute path of mailbox
MAILCHECK number of seconds to check mail
OLDPWD absolute path of previous directory
OPTARG option set by getopt
OPTIND option's ordinal position set by getopt
OSTYPE the OS on which bash is executing
PATH command search path
PPID process ID of parent
PS1 primary prompt
PS2 secondary prompt
PWD absolute path of current directory
RANDOM random integer
REPLY default variable for read
SECONDS number of seconds since shell started
SHELL absolute pathname of preferred shell
TMOUT seconds to log out after lack of use
UID user ID of the current user
$ process ID of current shell
? exit status of most recent statement
訂閱：
文章 (Atom)
