了解面向對象思想

面向對象的思維方式：

   面向對象是圍繞對象和類來分析、設計軟體系統的。

面向對象分析：

   面向對象分析的主要任務是根基使用者的需求，建立一個準确的、完整的、一緻的系統模型。在面向對象的分析過程裡，項目

組通過分析軟體的功能性需求，得到一個理想化的系統模型，該模型更多的側重于描述我們需求解決的問題是什麼---我們稱這種模型

為分析模型。

面向對象分析與面向對象設計的差別:

1、在側重點上，面向對象分析側重于了解問題，描述軟體做什麼，而面向對象設計側重于了解解決方案，描述軟體如何做。

2、面向對象分析一般隻考慮理想的設計，不關心技術和實作的細節，而面向對象設計更具體、更詳細、更接近真實的代碼的設計方案。

3、在設計結果的描述方式上，分析階段側重描述對象的行為，設計階段側重于描述對象的屬性和方法。

4、面向對象分析隻關注功能性需求，而面向對象設計既關注功能性需求，也關注非功能性需求。

5、面向對象分析的産生的系統模型通正常模較小，而面向對象的設計産生的系統模型規模較大，内容也比較完整、詳盡。

用例驅動的面向對象分析：

面向對象分析的過程包括：

1、從用例中提取實體對象和實體類。

   提取實體對象的方法，依據用例描述中出現的名詞和名詞短語來提取實體對象，必須對原始的名詞和名詞短語進行篩選。

得到實體對象後，對實體對象進行歸納、抽象出實體類。

2、提取屬性

3、提取關系

4、添加邊界類

5、添加控制類

6、繪制類圖

7、繪制順序圖

8、編制術語表

有了思想才能飛翔，缺乏靈活就象少了輪子的汽車，難以飛奔。為了更好的了解設計思想，結合一個盡可能簡潔的執行個體來說明OOD、設計模式及重構。通過 下面的代碼，詳細地闡述面向對象設計思想。 一、傳統過程化設計思想假定我們要設計一個媒體播放器（隻從軟體設計的角度，不涉及硬體）。該媒體播放器目前隻支援音頻檔案mp3和wav。按照結構化設 計思想，設計出來的播放器的代碼如下：

面向對象設計（ OOD ）思想（ C# ）   有了思想才能飛翔，缺乏靈活就象少了輪子的汽車，難以飛奔。為了更好的了解設計思想，結合一個盡可能簡潔的執行個體來說明OOD、設計模式及重構。通過下面的代碼，詳細地闡述面向對象設計思想。  一、傳統過程化設計思想 假定我們要設計一個媒體播放器（隻從軟體設計的角度，不涉及硬體）。該媒體播放器目前隻支援音頻檔案mp3和wav。按照結構化設計思想，設計出來的播放器的代碼如下： public class MediaPlayer  {       private void PlayMp3()     {        MessageBox.Show("Play the mp3 file.");     }       private void PlayWav()     {        MessageBox.Show("Play the wav file.");     }       public void Play(string audioType)     {             switch (audioType.ToLower())        {            case ("mp3"):               PlayMp3();               break;            case ("wav"):               PlayWav();               break;                    }          }  }  從傳統的過程化設計思想來看，這是一段既實用又簡潔的代碼。 如果，客戶又提出新的要求：要播放器不僅僅播放mp3和wav檔案，還要播放其他音頻檔案如wma、mp4等，為此我們要不斷地增加相應地播放方法和修改條件語句，直止條件語句足夠長。 如果，客戶感到這個媒體播放器功能太少了，隻能聞其聲，不能見其人，太單一。如果在聽着 優美音樂的同時又能看到歌唱者潇灑、英俊的舞姿那就更好了。從代碼設計的角度看，他們希望媒體播放器支援視訊檔案了。也許你會想，不會再增加視訊這方面的 代碼，可以，在增加視訊媒體的播放方法，在修改條件判斷語句，如果還有其他，還可以同樣地增加、修改。到此你也許會提出，要是不修改或很少修改原來的代碼 就能增添其他功能該多好啊！ 這樣看，原來的軟體設計結構似乎有點問題。事實上，随着功能的不斷增加，你越來越發現這 個設計非常的糟糕，因為它根本沒有為未來的需求變更提供最起碼的擴充。為了應接不暇的變更需求，你不得不不厭其煩地修改原來的代碼，使其适應需求變化，甚 至在修改代碼時，由于過多的代碼依賴關系弄得人焦頭爛額，直止一塌糊塗。 二、面向對象設計思想 還是以設計一個媒體播放器為例，設計要求相同。不訪我們換個設計思路利用面向對象設計思想（OOD）來做做看如何！ 根據OOD的思想，我們應該把mp3和wav分别看作是兩個獨立的對象。代碼設計如下： public class MP3  {     public void Play()     {         MessageBox.Show("Play the mp3 file.");     }  }    public class WAV  {     public void Play()     {         MessageBox.Show("Play the wav file.");     }  }    Public class MediaPlayer {       switch (audioType.ToLower())        {            case ("mp3"):                        MP3 m = new MP3();              m.Play();               break;            case ("wav"):               WAV w = new WAV(); w.Play();               break;                    } }             現在我們重構代碼，建立統一的Play()方法，（在後面的設計中，你會發現這樣改名是多麼的重要！）更改媒體播放類MediaPlayer的代碼。如果 這樣的設計代碼，實質上沒有多大的變化，隻是對原來過程化設計思想的一種替代，并沒有擊中要害，亦然沒有靈活性、可擴充性。        2.1 單向分派技術的應用( 在這裡用類的多态來實作的) 我們不訪這樣設想：既然mp3和wav都屬于音頻檔案，都具有音頻檔案的共性，應該建立一個共同的AudioMedia父類。  public class AudioMedia  {     public void Play()     {         MessageBox.Show("Play the AudioMedia file.");     }  }  現在引入繼承思想，OOD就有點雛形了（不是說有了繼承就有了OOD思想，這裡隻是從繼承的角度談一談OOD思想，當然從其他角度如合成、聚合等角度也能很好地展現OOD思想）。 其實在現實生活中，我們的播放器播放的隻能是某種具體類型的音頻檔案如mp3，是以這個AudioMedia類隻能是音頻媒體的一個抽象化概念，并沒有實際的使用情況。對應在OOD設計中，既這個類永遠不會被執行個體化。為此我們應将其改為抽象類，如下： public abstract class AudioMedia  {     public abstract void Play();  }    public class MP3:AudioMedia  {     public override void Play()     {         MessageBox.Show("Play the mp3 file.");     }  }    public class WAV:AudioMedia  {     public override void Play()     {         MessageBox.Show("Play the wav file.");     }  }    public class MediaPlayer  {          //根據需要完成任務的單向分派    public void Play(AudioMedia media)     {              media.Play();     }  }  到此，我們通過單向分派技術使OOD思想得到進一步的展現。現在的設計，即滿足了類之間的層次關系，又保證了類的最小化原則，同時又展現了面向對象設計原則（開—閉原則、裡氏代換原則）更利于擴充。（止此，你會發現play方法名的更改是多麼必要）。  如果現在又增加了對WMA、MP4等音頻檔案的播放，隻需要設計WMA類，MP4類，并繼承AudioMedia，在相應的子類中重寫Play方法就可以了，MediaPlayer類對象的Play方法根本不用任何改變。  如果讓媒體播放器能夠支援視訊檔案，必須另外設計視訊媒體的類。因視訊檔案和音頻檔案有很多不同的地方，不可能讓視訊繼承音頻。假設我們播放器支援RM和MPEG格式的視訊。視訊類代碼如下：  public abstract class VideoMedia  {     public abstract void Play();  }    public class RM:VideoMedia  {     public override void Play()     {         MessageBox.Show("Play the rm file.");     }  }    public class MPEG:VideoMedia  {     public override void Play()     {         MessageBox.Show("Play the mpeg file.");     }  }    這樣設計還是有點糟糕，這樣就無法實用原有的MediaPlayer類了。因為你要播放的視訊RM檔案并不是音頻媒體AudioMedia的子類。        不過，我們可以這樣想，無論音頻媒體還是視訊媒體都是媒體，有很多相似的功能，如播放、暫停、停止等，為此我們把“媒體”這個概念抽象出來做為一個接口。 （雖然也可以用抽象類，但在C#裡隻支援類的單繼承，不過c#支援接口的多繼承）。根據接口的定義，你完全可以将相同功能的一系列對象實作同一個接口。讓 音頻媒體類及視訊媒體類都繼承媒體這個接口。代碼如下：    public interface IMedia  {     void Play();  }    public abstract class AudioMedia:IMedia  {     public abstract void Play();  }    public abstract class VideoMedia:IMedia  {     public abstract void Play();  }    這樣再更改MediaPlayer類的代碼：  public class MediaPlayer  {      public void Play(IMedia media)     {              media.Play();     }   }         現在看來，程式是不是有很大的靈活性和可擴充性了。 總結一下，從MediaPlayer類的演變，我們可以得出這樣一個結論：在調用類對象的屬性和方法時，盡量避免将具體類對象作為傳遞參數，而應傳遞其抽象對象，更好地是傳遞接口，将實際的調用和具體對象完全剝離開，這樣可以很好地展現了軟體工程的靈活性、擴充性。         現在看起來似乎很完美了，但我們忽略了MediaPlayer的調用者這個事實。仍然需要條件語句來實作。例如，在用戶端程式代碼中，使用者通過選擇cbbMediaType組合框的選項，決定播放音頻媒體還是視訊媒體，然後單擊Play按鈕執行。  Public void BtnPlay_Click(object sender,EventArgs e)  {      IMedia media = null;     switch (cbbMediaType.SelectItem.ToString().ToLower())      {          case ("mp3"):               media = new MP3();               break;                        //其它類型略;         case ("rm"):               media = new RM();               break;            //其它類型略；      }      MediaPlayer player = new MediaPlayer();      player.Play(media);  }    2.2 設計模式、條件外置及反射技術的應用 随着需求的增加，程式将會越來越複雜。此時就應調整設計思想，充分考慮到代碼的重構和設計模式的應用。最後當設計漸趨完美後，你會發現，即使需求不斷增加，你也可以神清氣爽，不用為代碼設計而煩惱了。  為了實作軟體工程的三個主要目标：重用性、靈活性和擴充性。我們不訪用設計模式、條件外置及反射來實作。 使用工廠模式，能夠很好地根據需要，調用不同的對象（即動态調用），保證了代碼的靈活性。 雖然這裡有兩種不同類型的媒體AudioMedia和VideoMedia（以後可能更多），但它們同時又都實作IMedia接口，是以我們可以将其視為一種産品。媒體工廠接口如下：  public interface IMediaFactory  {     IMedia CreateMedia();  }    然後為具體的媒體檔案對象搭建工廠，并統一實作媒體工廠接口：  public class MP3Factory:IMediaFactory  {     public IMedia CreateMedia()     {         return new MP3();     }  }  //其它工廠略；   public class RMFactory:IMediaFactory  {     public IMedia CreateMedia()     {         return new RM();     }  }  //其它工廠略；    寫到這裡，也許有人會問，為什麼不直接給AudioMedia和VideoMedia類 搭建工廠呢？很簡單，因為在AudioMedia和VideoMedia中，分别還有不同的類型派生，如果為它們搭建工廠，則在 CreateMedia()方法中，仍然要使用條件判斷語句，代碼缺乏靈活性，不利擴充。 還有一個問題，就是真的有必要實作AudioMedia和VideoMedia兩個抽象 類嗎？讓其子類直接實作接口不是更簡單？對于本文提到的需求，是能實作的。但不排除AudioMedia和VideoMedia它們還會存在其他差別，如 音頻檔案還需給聲霸卡提供接口，而視訊檔案還需給顯示卡提供接口。如果讓MP3、WAV、RM、MPEG直接實作IMedia接口，而不通過 AudioMedia和VideoMedia，在滿足其它需求的設計上也是不合理的。現在用戶端程式代碼發生了稍許的改變：  Public void BtnPlay_Click(object sender,EventArgs e)  {  IMediaFactory factory = null;      switch (cbbMediaType.SelectItem.ToString().ToLower())  {         //音頻媒體         case ("mp3"):               factory = new MP3Factory();               break;          //視訊媒體 case ("rm"):               factory = new RMFactory();               break;            //其他類型略；      }      MediaPlayer player = new MediaPlayer();      player.Play(factory.CreateMedia());  }    到這裡，我們再回過頭來看MediaPlayer類。這個類中通過單向分派，根據傳遞參數的不同，分别實作了不同對象的Play方法。在不用工廠模式時，這個類對象會運作得很好。作為一個類庫或元件設計者來看，他提供了一個不錯的接口，供用戶端程式調用。 利用工廠模式後，現在看來MediaPlayer類已經多餘。是以，我們要記住的是，重構并不僅僅是往原來的代碼添加新的内容。當我們發現一些不必要的設計時，還需要果斷地删掉這些備援代碼。修改後的代碼如下：  Public void BtnPlay_Click(object sender,EventArgs e)  {  IMediaFactory factory = null;      switch (cbbMediaType.SelectItem.ToString().ToLower())      {                 case ("mp3"):               factory = new MP3Factory();               break;                //其他類型略；         case ("rm"):               factory = new RMFactory();               break;            //其他類型略；      }      IMedia media = factory.CreateMedia();      media.Play();  }    如果你在最開始沒有體會到IMedia接口的好處，在這裡你應該已經明白了。我們在工廠 模式中用到了該接口；而在用戶端程式中，仍然要使用該接口。使用接口有什麼好處？那就是你的主程式可以在沒有具體業務類的時候，同樣可以編譯通過。是以， 即使你增加了新的業務，你的用戶端程式是不用改動的。  不過，這樣寫用戶端代碼還是不夠理想的，依然不夠靈活，在判斷具體建立哪個工廠的時候，仍需條件判斷。現在看來，如果執行者沒有完全和具體類分開，一旦更改了具體類的業務，例如增加了新的工廠類，仍然需要更改用戶端程式代碼。 我們可以通過反射技術、條件外置很好地做到用戶端的靈活性。 條件外置來實作，即通過應用程式的配置檔案來實作。我們可以把每種媒體檔案類的類型資訊放在配置檔案中，然後根據配置檔案來選擇建立具體的對象。并且，這種建立對象的方法将使用反射技術來完成。首先，建立配置檔案：    <appSettings>   <add key="mp3" value="MediaLibrary.MP3Factory" />   <add key="wav" value=" MediaLibrary.WAVFactory" />   <add key="rm" value=" MediaLibrary.RMFactory" />   <add key="mpeg" value=" MediaLibrary.MPEGFactory" />  </appSettings>    然後，在用戶端程式代碼中，自定義一個初始化方法如：InitMediaType()，讀取配置檔案的所有key值，填充cbbMediaType組合框控件中：  private void InitMediaType()  {  cbbMediaType.Items.Clear();  foreach (string key in ConfigurationSettings.AppSettings.AllKeys)  {              cbbMediaType.Item.Add(key);  }  cbbMediaType.SelectedIndex = 0;  }    最後，更改用戶端程式的Play按鈕單擊事件：  Public void BtnPlay_Click(object sender,EventArgs e)  {  string mediaType = cbbMediaType.SelectItem.ToString().ToLower();  string factoryDllName = ConfigurationSettings.AppSettings[mediaType].ToString();  //MediaLibray為引用的媒體檔案及工廠的程式集;  IMediaFactory factory = (IMediaFactory)Activator.CreateInstance(“MediaLibrary”, factoryDllName).Unwrap(); IMedia media = factory.CreateMedia();  media.Play();  }    這樣可以很好地展現了軟體工程的三個主要目标：重用性、靈活性和擴充性。 設想一下，如果我們要增加某種媒體檔案的播放功能，如AVI檔案。那麼，我們隻需要在原 來的業務程式集中建立AVI類，繼承于VideoMedia類。另外在工廠業務中建立AVIFactory類，并實作IMediaFactory接口。假 設這個新的工廠類型為MediaLiabrary.AVIFactory，則在配置檔案中添加如下一行：  <add key="AVI" value="MediaLiabrary.AVIFactory" />。  而用戶端程式呢？根本不需要做任何改變，甚至不用重新編譯，程式就能自如地運作！ 另：本文釋出後有熱心的朋友提出，如果提供UML圖，那就更完美了，謝謝這位朋友的提醒。UML圖現補充如下：    

C#面向對象分析

2007-11-28　網友評論 0 條　 點選進入論壇

　　面向對象分析屬于軟體開發過程中的問題定義階段，其目标是清晰、精确地定義問題領域。傳統的系統分析産生一組面向過程的文檔，定義目标系統的功能;面向對象分析則産生一種描述系統功能和問題領域的基本特征的綜合文檔。

　　原則

　　面向對象分析的主要原則如下。

　　1.抽象

　　從許多事物中舍棄個别的、非本質的特征，抽取共同的、本質性的特征，就叫做抽象。抽象是形成概念的必須手段。

　　抽象原則有兩方面的意義：第一，盡管問題域中的事物是很複雜的，但是分析員并不需要了解和描述它們的一切，隻需要分析研究其中與系統目标有關的事物及其本質性特征。第二，通過舍棄個體事物在細節上的差異，抽取其共同特征而得到一批事物的抽象概念。

　　抽象是面向對象方法中使用最為廣泛的原則。抽象原則包括過程抽象和資料抽象兩個方面。過程抽象是指，任何一個完成确定功能的操作序列，其使用者 都可以把它看做一個單一的實體，盡管實際上它可能是由一系列更低級的操作完成的。資料抽象是指根據施加于資料之上的操作來定義資料類型，并限定資料的值隻 能由這些操作來修改和觀察。資料抽象是面向對象分析的核心原則。它強調把資料(屬性)和操作(服務)結合為一個不可分的系統機關(即對象)，對象的外部隻 需要知道它做什麼，而不必知道它如何做。

　　2.封裝

　　封裝就是把對象的屬性和服務結合為一個不可分的系統機關，并盡可能隐蔽對象的内部細節。

　　3.繼承

　　特殊類的對象擁有的其一般類的全部屬性與服務，稱作特殊類對一般類的繼承。

　　在面向對象分析中運用繼承原則，就是在每個由一般類和特殊類形成的一般—特殊結構中，把一般類的對象執行個體和所有特殊類的對象執行個體都共同具有的屬 性和服務，一次性地在一般類中進行顯式定義。在特殊類中不再重複地定義一般類中已定義的東西，但是在語義上，特殊類卻自動地、隐含地擁有它的一般類(以及 所有更上層的一般類)中定義的全部屬性和服務。繼承原則的好處是：使系統模型比較簡練也比較清晰。

　　4.分類

　　就是把具有相同屬性和服務的對象劃分為一類，用類作為這些對象的抽象描述。分類原則實際上是抽象原則運用于對象描述時的一種表現形式。

　　5.聚合

　　聚合的原則是：把一個複雜的事物看成若幹比較簡單的事物的組裝體，進而簡化對複雜事物的描述。

　　6.關聯

　　關聯是人類思考問題時經常運用的思想方法：通過一個事物聯想到另外的事物。能使人發生聯想的原因是事物之間确實存在着某些聯系。

　　7.消息通信

　　這一原則要求對象之間隻能通過消息進行通信，而不允許在對象之外直接地存取對象内部的屬性。通過消息進行通信是由于封裝原則而引起的。在OOA中要求用消息連接配接表示出對象之間的動态聯系。

　　8.粒度控制

　　一般來講，人在面對一個複雜的問題域時，不可能在同一時刻既能縱觀全局，又能洞察秋毫。是以需要控制自己的視野：考慮全局時，注意其大的組成部分，暫時不詳察每一部分的具體的細節;考慮某部分的細節時則暫時撇開其餘的部分。這就是粒度控制原則。

　　9.行為分析

　　現實世界中事物的行為是複雜的。由大量的事物所構成的問題域中各種行為往往互相依賴、互相交織。

　　階段

　　面向對象分析過程可分為問題領域分析和應用分析兩個階段。

　　問題領域分析是軟體開發的基本組成部分，目的是使開發人員了解問題領域的結構，建立大緻的系統實作環境。問題領域分析給出一組抽象概念(從高層 來表示問題領域知識，常常超出目前應用的範圍)作為特定系統需求開發的參考。問題領域分析實際上是一種學習過程。軟體開發人員在這個階段應該盡可能地了解 目前系統中與應用有關的知識，應該放開思維，放寬考慮的範圍，盡可能地辨別與應用有關的概念。問題領域分析的邊界可能很模糊。有了廣泛的問題領域知識，涉 及到具體的應用時，就可以更快地進入狀态，掌握應用的核心知識。而且，在使用者改變對目标系統的需求時，廣泛的分析可以幫助我們預測出目标系統在哪些方面會 發生哪些變化。通常進行小組分析，小組成員可以包括領域專家和分析員等。在分析過程中，應該辨別出系統的基本概念(對象、類、方法、關系等)、識别問題領 域的特征，并把這些概念內建到問題領域的模型中。問題領域的模型必須包含概念之間的關系，以及每個概念的全部資訊。辨別出來的相關概念應該根據資訊内容來 有機地融合到問題領域的綜合視圖中。

　　應用分析是依據在問題領域分析時建立起來的問題領域模型來進行的。應用分析時，把問題領域模型用于目前特定的應用之中。首先，通過收集到的使用者 資訊來對問題領域進行取舍，把使用者需求作為限制條件來使用，以縮減問題領域的資訊量。是以，問題領域分析的視野大小直接影響到應用分析保留的資訊量。一般 來說，問題領域分析階段産生的模型并不需要用程式設計語言來表示，而應用分析階段産生的影響條件則需要用某種程式設計語言來表示。模型識别的要求可以針對 一個應用，也可以針對多個應用。通常我們着重考慮兩個方面，即應用視圖和類視圖。在類視圖中，必須對每個類的屬性和操作進行細化，并表示出類之間的互相作 用關系。

　　目标

　　Coad和Yourdon 認為，面向對象分析主要應該考慮與特定應用有關的對象，以及對象之間在結構和互相作用上的關系。在面向對象分析中，需要建立分析模型來描述系統的功能。

　　面向對象分析需要完成如下兩個任務：

　　— 形式化地說明所面對的應用問題，最終成為軟體系統基本構成的對象，以及系統所必須遵從的、由應用環境所決定的規則和限制條件。

　　— 明确地規定構成系統的對象如何協同工作和完成指定的功能。

　　通過面向對象分析所建立的系統模型是以概念為中心的，是以稱為概念模型。概念模型由一組相關的類組成。面向對象分析可以通過自頂向下地逐層分解來建立系統模型，也可以自底向上地從已經定義的類出發，逐漸構造新的類。概念模型的構造和評審由如下5個層次構成：

　　— 類和對象層

　　— 屬性層

　　— 服務層

　　— 結構層

　　— 主題層

　　這5個層次不是構成軟體系統的層次，而是分析過程中的層次。也可以說是問題的不同側面。每個層次的工作都為系統的規格說明增加了一個組成部分。當5個層次的工作全部完成時，面向對象分析的任務也就完成了。

　　在實際操作中，面向對象分析的目标是得出問題領域的功能模型、對象模型和動态模型，并用相應的UML圖将它們表示出來。

　　步驟

　　面向對象分析通常按照下面的步驟來進行：

　　(1)辨別對象和類。可以從應用領域開始，逐漸确定形成整個應用的基礎類和對象。這一步需要分析領域中目标系統的責任，調查系統的環境，進而确定對系統有用的類和對象。

　　(2)辨別結構。典型的結構有兩種，即一般—特殊結構和整體—部分結構。一般—特殊結構表示一般類是基類，特殊類是派生類。比如，汽車是轎車和 卡車的基類，這是一種一般—特殊結構。整體部分結構表示聚合，由屬于不同類的成員聚合成為新的類。比如，輪子、車體和汽車底盤都是汽車的一部分，這些不同 功能的部件聚合成為汽車這個整體。

　　(3)辨別屬性。對象所儲存的資訊稱為它的屬性。類的屬性描述狀态資訊，在類的某個執行個體中，屬性的值表示該對象的狀态值。需要找出每個對象在目 标系統中所需要的屬性，并将屬性安排在适當的位置，找出執行個體連接配接，最後再進行檢查。應該給出每個屬性的名字和描述，并指定該屬性所受的特殊限制(如隻讀、 屬性值限定在某個範圍之内等)。

　　(4)辨別服務。對象收到消息後執行的操作稱為對象提供的服務。它描述了系統需要執行的處理和功能。定義服務的目的是為了定義對象的行為和對象之間的通信。其具體步驟包括：

　　— 辨別對象狀态

　　— 辨別必要的服務

　　— 辨別消息連接配接

　　— 描述服務

　　可以用類似于流圖的圖形來表示服務。

　　(5)辨別主題。為了更好地了解包含大量類和對象的概念模型，需要辨別主題，即對模型進行劃分，給出模型的整體架構，劃分出層次結構。可以按照如下步驟來辨別主題。

　　— 識别主題

　　— 對主題進行改進和細化

　　— 将主題加入到分析模型

　　主題是一個與應用相關的概念，而不是人為任意引出來的，主題層的工作有助于了解分析的結果。

　　優點

　　面向對象分析的主要有點有：

　　(1)加強了對問題域和系統責任的了解;

　　(2)改進與分析有關的各類人員之間的交流;

　　(3)對需求的變化具有較強的适應性;

　　(4)支援軟體複用;

　　(5)貫穿軟體生命周期全過程的一緻性;

　　(6)實用性;

　　(7)有利于使用者參與。

轉載于:https://www.cnblogs.com/lc-ant/archive/2012/08/13/2635896.html