面向對象方法與UML的歷史與發展

1、   不一樣的分析與設計方法

    1.功能分解法（function decomposition）

        以系統須要提供的功能爲中心來組織系統。

        首先定義各類功能，而後把功能分解爲子功能，對較大的子功能進一步分解，直到可給出明確的定義

        設計功能/子功能所須要的數據結構

        定義功能/子功能之間的接口。

        （做爲一種早期的建模方法，沒有明確地區分分析與設計）

        建模過程：層層進行功能分解

        功能分解法獲得的系統模型（由模塊及其接口構成）

        優勢與缺點：

            直接地反映用戶的需求，因此工做很容易開始；

            不能直接地映射問題域，很難檢驗結果的正確性；

            對需求變化的適應能力不好；

            局部的錯誤和修改很容易產生全局性的影響。

    2.結構化方法：

        結構化分析（structured analysis，SA）

        結構化設計（structured design。SD）

        結構化分析又稱數據流法，其基本策略是跟蹤數據流，即研究問題域中數據如何流動，以及在各個環節上進行何種處理，從而發現數據流和加工。獲得的分析模型是數據流圖（DFD），主要模型元素是數據流、加工、文件及端點，外加處理說明和數據字典。

數據流圖

         結構化設計與功能分解法基本相同，基於模塊的概念創建設計模型，分爲概要設計和詳細設計。

                概要設計：肯定系統中包含哪些模塊以及模塊之間的調用關係，獲得模塊結構圖（MSD）。

                詳細設計：描述每一個模塊內部的數據結構和操做流程。

               結構化方法的優缺點：

優勢：

強調研究問題域，而且有嚴格的法則。

缺點：

仍然是間接映射問題域；分析與設計的概念不一致，從分析到設計的過渡比較困難；數據流和加工的數量太多，引發分析文檔的膨脹。

   3.信息建模法（information modeling）

        由實體-關係法（E-R方法）發展而來。

        核心概念是實體和關係。實體描述問題域中的事物，關係描述事物之間在數據方面的聯繫，均可以帶有屬性。

        發展以後的方法也把實體稱做對象，並使用了類型和子類型的概念，做爲實體（對象）的抽象描述。

            E-R圖：

        信息模型：

        信息建模法已經很接近面向對象方法，所以有的文獻也把它稱爲一種面向對象方法，但有如下差異：

                    1)        強調的重點是信息建模和狀態建模，而不是對象建模

                    2)        實體中只有屬性沒有操做

                    3)        只有屬性的繼承，不正常操做的繼承

                    4)        沒有采用信息通信

    4.面向對象方法

        面向對象的分析（OOA）

        面向對象的設計（OOD）

            運用對象、類、繼承、封裝、聚合、關聯、消息、多態性等概念來構造系統。

            把問題域中的事物抽象爲對象，做爲系統的基本構成單位，其屬性和操做刻畫了事物的靜態特徵和動態特徵——完整地刻畫了問題域中事物。

            用類做爲對象的抽象描述，創建它們之間的繼承、聚合、關聯、消息等關係——如實地表達了問題域中事物之間的各類關係。

            封裝、繼承、聚合、關聯、消息通信等原則符合人類的平常思惟——使系統的複雜性獲得控制。

        不一樣的建模方法 體現於

              從不一樣的概念出發認識問題域

                 用不一樣的概念進行系統構造

系統對現實世界的映射方式不一樣

         不一樣的方法對同一應用實例（電話安裝業務系統）的不一樣效果

                 結構化分析——數據流和加工

問題：

    不是直接映射問題域，與事物相關的數據和操做不是圍繞這些事物來組織的，而是分散在數據流和加工中；常常發生信息膨脹——模型中的多個數據裏，實現中其實只是一項數據；分析模型難以與設計模型及源程序對應。

         面向對象方法——對象及其關係

 

       什麼是OOA

    顧名思義，面向對象的分析（OOA），就是運用面向對象方法進行系統分析。

    首先，OOA是分析，是軟件生存週期的一個階段，具備通常分析方法共同具備的內容、目標及策略；

    可是，它強調運用面向對象方法進行分析，用面向對象的概念和表示法表達分析結果。

    基本任務：運用面向對象的概念對問題域進行分析，將問題域中與系統責任有關的事物抽象爲系統中的對象，定義這些對象的屬性與操做，以及它們之間的各類關係。

    最終目標：簡歷一個知足用戶需求、直接映射問題域的OOA模型。

       什麼是OOD

                不一樣時期有不一樣內容及特色

                早期（80年代末期以前）OOD的特色：

                        1)        不是基於OOA的

                        大多基於結構化分析結果（數據流圖）

                        2)        是OO編程方法的延伸

                        多數方法與編程語言無關，特別受Ada影響很大

                        3)        不是純OO的

                        對某些OO概念（如繼承）缺乏支持，摻雜一些非OO概念（如數據流、包、模塊等）

                        4)        不是隻針對軟件生存週期的設計階段

                                        OOD中的「D」——指的是Design或Development，多少涉及分析問題（如識別問題域的對象），但很不完全

                        ——早期的OOD可看做現今OOA&D方法的雛形

                  現今（90年代之後）OOD的特色：

                                          i.              以面向對象的分析爲基礎，通常不依賴結構化分析。

                                         ii.              與OOA方法共同構成一種OOA&D方法體系。OOA和OOD採用一致的概念與原則，但屬於軟件生存週期的不一樣階段，有不一樣的目標及策略。

                                        iii.              較全面地體現面向對象方法的概念與原則。

                                        iv.              大多數方法獨立於編程語言，經過面向對象的分析與設計所獲得的系統模型能夠由不一樣的編程語言實現。

    定義：

           面向對象的設計（OOD）就在是OOA模型基礎上運用面向對象方法進行系統設計，目標是產生一個符合具體實現條件的OOD模型。

       OO方法的主要優勢

               軟件建模面臨的挑戰

                    a)       問題域和系統責任複雜性日益增加

    問題域（problem domain）：被開發系統的應用領域，即在現實世界中由這個系統進行處理的業務範圍。

    系統責任（system responsibilities）：所開發的系統應該具有的職能。

    隨着硬件性能的提升和價格的降低，軟件系統所面臨的問題域和系統責任愈來愈複雜，所以系統也愈來愈龐大。

                    b)      交流問題

    軟件系統的開發須要各種人員之頻繁交流。領域的多樣性使軟件工程中的交流問題比與其餘工程更爲突出。

    有效的交流須要一種彼此都能理解的共同語言，不然將彼此的思惟難以溝通，很容易隱藏下許多錯誤。

                    c)       需求的不斷變化

                    用戶因素，競爭因素，經費因素……

      

                    d)      軟件複用的要求

                     複用級別提升——分析與設計結果複用

                     要求分析與設計模型的基本成分能夠在多個系統中複用

                面向對象方法的優點

                                          i.              對問題域和系統責任的複雜性具備較強的處理能力

          從問題域中的實際事物出發來構造系統模型，使系統模型能直接地映射問題域；繼承、封裝、聚合等概念使系統的複雜性獲得有效的控制。

                                        ii.              提供了便於各種相關人員交流共同語言

                        使用與問題域一致的概念及術語，體現人類的平常思惟方式，爲改進各種人員之間的交流提供了最基本的條件。

                                      iii.              對需求的變化具備較強的適應性

                        按封裝原則把系統中最容易變化的因素隔離起來，系統的各個單元成分之間接口不多，把需求變化所引發的影響局部化。

                                      iv.              爲實現分析與設計級別的軟件複用提供了有力支持

                                      OO方法的封裝、繼承、聚合等原則，對象的完整性、獨立性以及與問題域的良好對應，使之有利於軟件複用。

                                       v.              貫穿軟件生存週期全過程的一致性

                        從OOA開始使用與問題域一致的概念、詞彙、原則及表示法，這種一致性保持到設計、編程、測試、維護等各個階段，對於整個軟件生存週期的開發、維護及管理活動都具備重要的意義。

       幾種典型的OO方法

              方法的異同體現於：

                     概念、表示法、系統模型、開發過程、可用性、技術支持等方面

              Booch方法

                     過程：

      

                     特色：

                         思惟活躍，開拓與創新，可操做性不夠強，類圖與對象圖並存

              Coad/Yourdon方法

                    

                  特色：

                       概念簡練，過程清晰，強調概念的一致性，過程指導不夠具體

              Jacobson方法（OOSE）

                 特色：

   經過用況描述用戶需求，用交互圖描述對象之間的交互，用況驅動的觀點言之有過。

              Rumbaugh方法（OMT）

      

                     特色：

    概念嚴謹，闡述清楚，過程具體，可操做性強，包含了許多非OO的內容，提出若干擴充概念，偏於複雜。

 

 

2、   統一建模語言UML

    1.     UML的背景和發展歷史

    l  誕生背景

        ü  面向對象方法種類繁多（1989年約10種，1994年達到50種以上）

        ü  概念、表示法、過程策略及文檔組織等方面存在不少差別（用戶在選擇建模方法和工具時無所適從，不利於技術交流）

        ü  迫切須要OO概念及表示法走向統一和標準化（統一建模語言UML應運而生）

    l  發展歷史

        n  第一階段：OO方法學家的聯合行動

                                        1995.10： G.Booch 與J.Rumbaugh聯合（推出Unified Method 0.8）

                                        1996.6：I.Jacobson加入（推出UML0.9[Unified Modeling Language]）--各家主要的面向對象方法家將其各自的方法統一爲UML，但不稱統一建模方法，而稱統一建模語言，最根本的緣由在於UML只是統一的概念與表示法，沒有統一過程。

        n  第二階段：公司的聯合行動

                                        1996：成立了UML夥伴組織，12家公司加入。

                                        1997.1：推出UML1.0，另外5家公司加盟。

                                        1997.9：造成UML1.1，提交OMG做爲建模語言規範提案。

                                        1997.11：UML1.1被OMG正式採納。

        n  第三階段：OMG主持下的修訂

                                        1997~2002：OMG成立UML修訂任務組主持UML的修訂，前後產生UML1.2、UML1.3、UML1.4、UML1.5等版本。

        n  第四階段：UML的重大修訂——UML2

                                        1999：開始醞釀，旨在產生比UML1有顯著改進的新版本。

                                        2000~2001：由OMG陸續發不了4個提案需求（RFP）[徵集提案，擇優採納]。

                                        2002年以後前後造成4個UML2.0規範，在OMG的組織下進行修訂，產生了UML2.1~2.4一系列版本。

        n  第五階段：提交到ISO申請成爲國際標準

                                        2005年之後UML2的4個規範陸續進入ISO的標準化日程，目前UML基礎結構、UML上層結構、OCL已被ISO正式採納，成爲建模語言國際標準。

        UML是什麼不是什麼

            「統一建模語言（UML）是一種用來對軟件密集型系統製品進行可視化、詳述、構造和建檔的圖形語言，也可用於業務建模以及其它非軟件系統。」

• 是一種建模語言，不是一種建模方法（「Rational統一過程」不是UML的一部分）

• 用於創建系統的分析模型和設計模型。而不是用於編程

• 是一種已被OMG採納的建模語言規範（spceification）（UML2系列中被ISO採納的部分纔可稱爲標準（standard））

• 部分地採用了形式化語言的定義方式，但並不嚴格（不是一種形式化語言，不能編執行或解析執行

  2.    UML 1概況

    UML1規範的主要構成部分

                                      i.              UML概要（UML Summary）：

                    對UML作歸納介紹，包括起構成、動機、目標、範圍、特色、歷史、現狀以及對將來演化的建議。

                                    ii.              UML語義（UML Semantics）：

                    定義UML的語法和語義，是定義UML語言的基本文件

                                  iii.              UML表示法指南（UML Notation Guide）：

                    定義UML的各類模型圖，給出各類圖中建模元素的可視化表示法

                                 iv.              UML外廓範例（UML Example Profiles）：

                    用於軟件開發過程的UML外廓；用於業務建模的UML外廓

                                   v.              UML模型轉換（UML Model Interchange）：

                    規定了建模工具在實現各類UML模型時須要共同遵照deep語言約定，使來自不一樣廠商的建模工具可以彼此交換和處理各自開發的系統模型。

                                 vi.              對象約束語言OCL（Object Constraint Language）：

                    定義了一種對象約束語言，用來描述模型中關於對象的附加約束，是一種形式化的語言。

                     OMG的四層元模型體系結構

                     抽象元類和具體元類

                     UML1的9種模型圖

                            靜態結構圖（Static Structure Diagram）

                                   類圖（Class Diagram）

                                   對象圖（Object Diagram）

                            用況圖（Use Case Diagram）

                            交互圖（Interaction Diagram）

                                   順序圖（Sequence Diagram）

                                   協做圖（Collaboration Diagram）

                            狀態圖（State chart Diagrams）

                            活動圖（Activity Diagrams）

                            實現圖（Implementation Diagrams）

                                   構件圖（Component Diagram）

                                   部署圖（Deployment Diagram）

                     九種圖支持用戶從不一樣的視角進行系統建模

                     擴展機制：附加到其餘模型元素之上，將原有的模型元素特化成一種語義叫特殊的新變種，或者表示出它們的某些細節。

                     約束（constraint）：用於說明某些必須保持爲真的命題。

                         註釋（comment）：對模型元素的細節所進行的解釋。

                         標記值（Tagged Value）：表示模型元素的附加的特徵。

                         衍型（stereotype）：附加到其餘模型元素之上，從而將原有的模型元素特化成一種語義叫特殊的新變種。

        3.     UML 2概況

從UML1 到UML2

          1999：開始醞釀對UML的重大修訂

          2000~2001：發佈提案需求，徵集提案，擇優採納

          2002年以後前後造成4個UML2.0規範：UML基礎結構、UML上層結構、對象約束語言（OCL）、UML圖交換

          在OMG的組織下繼續進行修訂：產生UML2.1~2.x一系列版本

UML2 的四個規範

            UML2 的13種模型圖

            UML與UML2 的各類圖的對照

            UML的貢獻和存在的問題

貢獻：結束了面向對象建模領域在概念和表示法方面不統一的局面，使之走向規範化和標準化的軌道，成爲一種被學術界和產業界普遍承認的統一建模語言。已被軟件開發和業務建模等各個領域普遍採用，在正式成爲國際標準以前，已經成爲事實上的工業標準。

問題：規模龐大，概念過於複雜，模型圖種類繁多

              UML1.5——736頁，9種模型圖

              UMl2.2——1284頁260多個元類，13種模型圖

       收羅了不少沒必要要的複雜概念，存在一些在理論上不嚴格、難以自圓其說的缺陷。

                                   例：

元模型中的實例級概念引發體系結構層次的混亂