Transcript 投影片 1

首席數位
物件導向系統分析與
設計(OOA,OOD)
首席講座: 曾龍博士
UML




統一塑模語言(Unified Modeling Language)
UML是一種開放(Open)的方法,用於說明、可視
化、構建和編寫一個物件導向軟體系統的方法。
UML是一種規格化(Specifying) 、視覺化
(Visualizing)及文件化(Documenting)的軟體塑模
語言
UML展現了一系列最佳工程實踐(best
engineering practices ),這些 最佳實踐在對大規
模,複雜系統進行塑模(Model)方面,特別是在軟
體架構層次已經被驗證有效。
UML已成為物件導向分析與設計的主要塑模語言





UML is a language that unifies the industry’s best
engineering practices for modeling systems.
UML Is a language. It is not simply a notation for
drawing diagrams, but a complete language for
capturing knowledge (semantics) about a subject
and expressing knowledge (syntax) regarding the
subject for the purpose of communication.
Applies to modeling and systems. Modeling involves
a focus on understanding (knowing) a subject
(system) and capturing and being able to
communicate this knowledge.
UML Is the result of unifying the information systems
and technology industry’s best engineering
practices (principles, techniques, methods, and
tools).
UML包含九種圖
[46]物件導向系統分析與設計: UML
UML不是










[1]A visual programming language, but a visual modeling language.
– A programming language communicates an implementation or
solution.
– A modeling language communicates a model (or conceptualization
or specification).
[2]A tool or repository specification, but a modeling language
specification.
– A tool or repository specification specifies a tool’s or repository’s
interface, storage, run-time behavior, and so forth.
– A modeling language specification specifies modeling elements,
notation, and usage guidelines.
[3]A process, but enables processes.
– A process provides guidance regarding the order of activities,
specification of artifacts to be developed, direction of individual
developer and team tasks (or activities), and monitoring and
measuring criteria of project artifacts and activities.
– Processes are organization, culture, and domain specific and
dependent.
– The UML enables and promotes (but does not require nor mandate) a
use-case-driven, architecture-centric, iterative, and incremental
process that is object oriented and component based.
UML Diagrams









1.使用個案圖Use case
2.類別圖class
3.物件圖(Object Diagram)
4.循序圖(Sequence Diagram)
5.合作圖(Collaboration Diagram)
6.狀態圖(State Diagram)
7.活動圖(Activity Diagram)
8.元件圖(Component Diagram)
9.佈署圖(Deployment Diagram)
1.使用個案圖Use case
(1)使用個案圖(Use case diagram)
角色(Role)
行為者
Actors
使用個案(Use Cases)
系統中一系列的交易,以完成某一特定工作
,並對系統之行為者產生可衡量的價值。
也就是說,工作結果對行為者產生一些可看
得見、可量化或質化的效益。
1.使用個案圖Use case
UML引用Jacobson 的使用個案模式
 使用個案圖表示系統使用個案和行為者之
間互動的關係。
 從外部觀點來看,使用者介面及使用個案
的範圍與限制,決定什麼是使用個案
(What)?
 從內部觀點來看,它可描述使用個案是如
何運作的(How)?

NextGen POS專案
(2)類別圖(Class diagram)
2.類別圖class
Diagram
(1)操作(Operation)
(2)關聯(Association) 表示類別間的連結
物件之行為
(Method)
(Dependency)
(Generalization)
(Association)
(3)基數(Multiplicity)
(Realization)
(1)在一個關聯關係中,常須表達有多少物件參與此關係,此種資訊與實體關係模式中之基數表達相同。
(2)基數表示有多少個案例參與該關聯,“多少”稱為關聯角色的基數(Multiplicity)
(3)有三種關聯,分別為一對一(1:1)、一對多(1:N)或多對多(M:N),其中以阿拉伯數字1表示一,以
英文字母N或M表示多,或用“*”表示多
2.類別圖class Diagram
UML引用Booch 與Rumbaugh方法論的類
別圖
 類別圖表示系統存在之類別以及類別間的
邏輯關係
 類別圖是UML模式圖的核心

(3)物件圖(Object Diagram)
基本元件 所表達資訊
物件
[1]類別圖上類別之物件
[2]表達之方式是在類別
之名稱下劃一底線
連結線
用來表示一個物件如何
與另一個物件連接,以
直線來表示。合作圖上
之連結也就是物件間之
路徑(Path)
3.物件圖(Object Diagram)




物件圖是用來描述一系統於某一時間點的靜態結構
物件圖由一群相關之物件及其連結所組成,以表示
系統在某一時間點之一案例(Instance) 。物件圖有
時也稱為案例圖(Instance Diagram),也可以把物
件圖想成沒有訊息傳遞的合作圖
物件常用矩形表示,在矩形內表達名稱;並在名稱
下加底線
真實世界裡,物件的數量相當的龐大,為降低問題
的複雜度,在系統分析時大多採用類別,而較少用
物件。
(4)循序圖(Sequence Diagram)
(4)循序圖(Sequence diagram)
[1]類別圖上類別之物件
[2]表達之方式是在類別之名稱下劃一底線
Object:Class
Message
Operation
由某一物件送至另
一物件以啟動操作
以水平之箭頭表示,
且箭頭起始於送訊息
Focus of Control
之區域,終止於接受 物件執行某動作之時
訊息之區域
段,包括由其執行或
透過其附屬程式。
高且瘦的矩形(長條
圖)表示,且與該物
件之生命線重疊
Lifeline
劃在物件底下與物件垂直之虛線,用予表
達物件在某時段之存在,例如從物件接收
到訊息或被新創出來開始到其被刪除為止
Operation
某一物件接到另一物件送達的訊息時,接收
端之物件為了執行發送端物件送來之要求,
所提供因應處理該訊息之方法。
4.循序圖(Sequence Diagram)
UML之循序圖(Sequence Diagram)是結合
Booch的互動圖與Rumbaugh的訊息追蹤
圖而成
 循序圖用以描述系統運作時,物件間的互
動行為且著重以時間為主軸的處理程序。

(5)合作圖
(5)合作圖(Class diagram)
訊息之發生順序可在訊息前面加一個序數來表示
Link
表示一個物件如何與另一個物件連接,以直線來表示。
合作圖上之連結也就是物件間之路徑(Path)
Object:Class
Operation
Message
Focus of Control
Lifeline
5.合作圖(Collaboration Diagram)



UML之合作圖(Collaboration Diagram)是從
Booch的物件互動圖與Rumbaugh的物件導向資
料流程圖改進而來
合作圖能同時展現物件間的資料流程、控制流程
與訊息傳遞的活動。
合作圖是一個宏觀的總流程,能同步表達資料的
產生與資料轉變的過程,以改進傳統資料流程圖
(DFD)中只著重資料流(Data Flow)的缺點。
(6)狀態圖(State Diagram)
(6)狀態圖(State Diagram)
States
with Depth
訂貨處理狀態圖
6.狀態圖(State Diagram)
UML之狀態圖(State Diagram)是結合
Booch 的狀態轉移圖與Rumbaugh的動態
模式而成
 狀態圖是用來表達物件在其生命週期中的
狀態變化。
 狀態圖是以微觀物件為主,細分物件所發
生的各項事件,並表達物件生命週期之狀
態轉變及活動結果。

(7)活動圖(Activity Diagram)
(7)活動圖(Activity Diagram) 確認採購訂單
Swimlane跳水道
活動狀態(Activity State)
轉換(Transition)
活動狀態(Activity State)
結束用予描述一連串活動的結束(或終點),以一實心圓形外加一空心圓圈表示
7.活動圖(Activity Diagram)
UML之活動圖(Activity Diagram)是狀態圖
的一種變異
 活動圖表達涉及於執行某一作業行為中之
活動。一個活動圖描述一群循序與同步的
活動,一個活動狀態表示一個工作流程步
驟或一個運算的執行活動。

8.元件圖(Component Diagram)
8.元件圖(Component Diagram)



UML之元件圖(Component Diagram) 起源於
Booch的模組圖
元件圖是用來說明系統設計過程各類別與物件的
配置及敘述軟體元件間的組織架構和相依關係。
元件是開發和執行過程之實際物件類別,將可拆
散的實際基本單位模組化,這些基本單位包括模
型(Module)元素並擁有特性和明確定義的介面
(9)部署圖
(9)部署圖(Deployment diagram)
(1)代表著一種計算資源,也可說是一個硬體
(2)節點是以正方體圖形來表示,它必須有一個唯一的名稱以示區別
(3)節點之名稱是以字串表示,原則上名稱可由文字加上數字與標點符號
等組成.節點之名稱有單純的名稱或延伸型的路徑名稱(Path Name).
必要時也可以加上一些標籤值(Tagged Values)
(1)節點(Nodes)
(2)連接(Connections)
節點間的溝通方式或
路徑,也表示節點間
之關係包括相依(De
pendency)、關聯(
Association)等
節點(Nodes)
9.部署圖(Deployment Diagram)

UML之佈署圖(Deployment Diagram) 起
源於Booch的處理圖

佈署圖是用來說明系統各處理器、處理元
件的配置、關聯,以及同一處理器內執行
處理的時程安排等。
使用個 由描述系統行為的使用個案組成,這些
案觀點: 系統行為是由使用者、分析師、測試者
的觀點來描述,並不實際描述軟體系統
的組織。
設計觀
點:
由類別、介面與合作組成,這些是來自
於描述問題及其解決方法中之辭彙描述。
這個觀點主要支援系統的功能需求,表
達系統應提供給使用者之服務。
流程觀 由執行緒與流程所組成,這些是來自於
點: 系統的平行與同步機制,這個觀點主要
表達系統之績效、產出與可擴充性。
實施觀 由可以不同方式組裝實際可運作系統之
點: 獨立的元件與檔案所組成,這個觀點主
要表達系統版本的結構配置管理。
部署觀 由構成系統之硬體類型的節點(Nodes)所
點: 組成,這個觀點主要表達組成實際系統
之零件的分配、傳遞訊息與安裝。