TWed2k - 程式開發討論區 - [轉貼] 物件導向的天空(二)--UML

TWed2k » 程式開發討論區 » [轉貼] 物件導向的天空(二)--UML

可打印版本 | 推薦給朋友 | 訂閱主題 | 收藏主題 | 純文字版

jocosn
白銀驢友

今日心情

．積分： 1386
．精華： 2
．文章： 2945
．收花： 9537 支
．送花： 3671 支
．比例： 0.38
．在線： 1295 小時
．瀏覽： 19041 頁
．註冊： 7601 天
．失蹤： 1603 天

#1 : 2005-4-17 09:03 AM 只看本作者	送花 (0) 送出中...

淺談UML http://www.iiiedu.org.tw/knowledge/knowledge20031231_2.htm
資策會教育訓練處講師郭惠民

　
UML是什麼？
UML是Unified Modeling Language的簡稱，中譯為「統一塑模語言」。其中：
●Unified：UML是一種標準語言，廣泛運用於全世界。
●Modeling：UML用途在於塑模(Modeling)，也就是畫軟體藍圖。
●Language：UML是一種塑模語言，而非程式語言或標示語言。
也就是說，UML是軟體系統發展人員用以建造模型，而這些模型使得工作團隊能夠：將系統具象化(Visualization)、將系統結構及行為規格化(Specification)、建構(Construction)系統、以及記錄(Documentation)發展系統過程中之各項決策。

什麼是塑模？
作曲家會將其腦袋中的旋律譜成樂曲，建築師會將其設計之建築物畫成藍圖，行銷廣告人員會將其創意製作成簡報；這些樂曲、藍圖及簡報就是模型(Model)，而建構這些模型的過程就稱為塑模(Modeling)。
軟體開發如同音樂譜曲及建築設計，其過程中也必須將需求、分析、設計、實作、佈署等各項工作流程之構想與結果予以呈現，這就是軟體系統之塑模。

為什麼要塑模？
絕大部份的音樂演奏都需要樂譜(除了少數即性式表演外)!
絕大部份的建築施工都需要藍圖(除非要蓋的是一間狗屋)!
同樣的，所有軟體系統的建構最好都有適當的分析設計藍圖，因為軟體開發的過程絕對不是任意的、隨性的、且戰且走的、天馬行空的。
UML在軟體塑模中所扮演的角色是什麼？
軟體發展之方法論中包含了程序(Process)及表示法(Notation)兩個部份，其中：
●程序指的是系統開發的流程，例：瀑布模式、漸增模式、擴展模式、雛型模式、螺旋模式等。
●表示法指的是建構軟體模型中所會用到之符號及規則。
UML所涵蓋的內容是表式法而非程序，UML是與程序無關的(Process Independent)，也就是說，無論以任何程序來開發軟體系統，都可以使用UML來建構軟體模型。
UML與物件導向方法之關係
●UML之訂定與物件導向方法的確有非常密切之關係。
●UML中的各種符號及規則與物件導向語言(Java，C++)之結構有完整對應。
●但是，UML絕對不僅限用在物件導向軟體開發，UML中有些概念與圖形甚至可說是與物件導向無關，例：Use Case Diagram及Statechart Diagram
●因此，軟體開發時無論是否採用物件導向方法，UML都是適用的。

UML的重要性
●UML是OMG公佈的官方標準。
●UML已為全世界軟體業者所廣泛採用，各大軟體公司(Microsoft、IBM、Oracle等)
   在其產品中均支援UML。
●UML的應用領域越來越廣(資料庫設計、韌體設計、資訊管理等)。

UML的現行版本
UML現行版本為1.5版(http://www.omg.org/technology/documents/formal/uml.htm)，但2.0版將近完成，應會在短期內正式公佈(http://www.omg.org/uml)。
[註] 轉貼此文時已出2.0，包括類別圖、循序圖、物件圖、套件圖、配置圖、使用案例圖、狀態機圖（state machine diagram）、活動圖、通訊圖（communication diagram）、合成結構（composite structure）、元件圖、互動概觀圖（interaction overview diagram）與時序圖（timing diagram）。新的UML 2.0版中，循序圖部分針對流程控制，新增互動框（interaction frame）表示法

UML的內容到底是什麼？
UML對於軟體開發相關人員而言，其實就只是一組符號及規則，其中包括：
1.Basic Building Blocks(都有其相對的符號)
(1) Things
      ●Structura˙Things：Class、Interface、Collaboration、Use Case、Active Class、Component、Node
      ●Behaviora˙Things：Interaction、State Machine
      ●Grouping Things：Package
      ●Annotation Things：Note
(2) Relationships：Association、Generalization、Dependence、Realization
(3) Diagrams
      ●Structural：Class、Object、Component、Deployment
      ●Behavior：Use Case、Activity、Statechart、Sequence、Collaboration
2.Rules(符號的使用規則)
Name、Scope、Visibility、Integrity、Execution
3.Common Mechanisms(各類符號及圖形通用的機制)
Specification、Adornments、Common Division、Extensibility Mechanisms

如何學習UML？
●找本淺顯易懂的入門書籍，先掌握UML的全貌，千萬不要被過多抽象的軟體工程專有名詞所絆住。記住：UML只是一組符號而已!
●先學習讀圖，讓自己先習慣於UML之各種符號，尤其注意UML中以擴充機制(Extensibility Mechanisms)所產生之符號，此部份最容易使初學者迷惑。
●練習畫圖，訓練自已將心中之構想以UML符號呈現出來，注意各類符號之正確表示法，不要隨意更改之。
●選用適當之CASE工具，Rationa˙Rose，Microsoft Visio，Borland Together都是很好的軟體工具。
如何應用UML於軟體開發？
●選擇一個適當之開發程序(Process)，例：RUP
●選擇一個適當之UML發展工具，例：Rationa˙Rose
●相關人員接受完整之訓練

[如果你喜歡本文章，就按本文章之鮮花～送花給作者吧，你的支持就是別人的動力來源]

本文連接

快速回覆

jocosn
白銀驢友

今日心情

#2 : 2005-4-17 09:08 AM 只看本作者	送花 (0) 送出中...

系統開發模式(SoftWare Process Model)
　瀑布式(Waterfall)
　　　‧編碼與修正模式(Code-andfix Model)
　　　‧階段模式(Stagewise Model)：Benington(1956)
　　　‧瀑布模式(Waterfall Model)：
　　　　Royce(1970) = 系統發展生命週期(System Development Life Cycle;SDLC)

　　　　特徵
　　　　　　* 適用於需求明確，領域知識(Domain KnowHow)容易取得的專案
　　　　　　* 強調開發過程需有完整的規劃，分析，設計，測試及文件等管理控制
　　　　　　* 前一階段完成後才能進入下一階段，各階段僅循環一次
　　　　　　* 沒有明確規定要劃分成多少個階段，每一階段皆有文件產出
　　　　至少劃分3階段
　　　　　　* 分析
　　　　　　* 設計
　　　　　　* 實施
　　　　通常劃分5~7階段不等(每一家學說都不同,掌握精神即可)
　　　　　　* 初步調查 (Preliminary Investigation)
　　　　　　* 系統分析 (System Analysis)
　　　　　　* 系統設計 (System Design)
　　　　　　* 系統開發 (System Development)
　　　　　　* 系統實施與評估 (System Implementation and Evaluation)

　反覆式(Iterative)
　　‧漸增模式(Incremental Model)：Mills(1971)
　　　　* 強調需求可分成幾個部分
　　　　* 開發週期可反覆進行
　　‧雛形模式(Prototyping Model)：Bally(1977)
　　　　* 適用於需求不明確，專案小，應用領域不熟悉或高風險之專案
　　　　* 強調雛形之快速開發，以雛形作為使用者與資訊人員溝通之工具，使用者高度參與等
　　　　雛形策略
　　　　　　* 演進式雛形(Evolutionary Prototyping)
　　　　　　* 用後丟棄式雛形(Rapid Throwaway Prototyping)：因成本較高，故適用於風險
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　最高的情形
　　‧螺旋模式(Spiral Model)：Boehm(1988)
　　　　強調「風險分析」結合了SDLC與雛形模式
　　　　螺旋模式的4個步驟
　　　　　　* 找出系統目標，可行方案與限制
　　　　　　* 依目標與限制評估方案
　　　　　　* 開發雛形
　　　　　　* 使用者評估，決定下一步驟
　　‧同步模式(Concurrent Model)：Aoyama(1993)
　　　　構想源於製造業的同步工程(Concurrent Engineering)目的在於縮短產品開發時間，適用於套裝軟體的專案
　　　　同步模式的構想
　　　　　　* 活動同步(Activity Concurrency)：不同團隊平行開發
　　　　　　* 資訊同步(Information Concurrency)：不同團隊資訊共享
　　　　　　* 整合性的管理系統：協調各種資源的互動關係

http://www2.cyut.edu.tw/~s9154610/se.html

[jocosn 在 2005-4-17 09:17 AM 作了最後編輯]

[如果你喜歡本文章，就按本文章之鮮花～送花給作者吧，你的支持就是別人的動力來源]

本文連接

快速回覆

所在時區為 GMT+8, 現在時間是 2025-4-19 07:16 PM	清除 Cookies - 連絡我們 - TWed2k © 2001-2046 - 純文字版 - 說明 Discuz! 0.1 \| Processed in 0.023752 second(s), 8 queries , Qzip disabled