系統模組化複習

CPS系統 ​

什麼是CPS系統？​

CPS全稱Cyber-Physical Systems，即資訊實體融合系統​

CPS系統的特征​

由新需求和應用驅動的資訊實體耦合每個實體元件中的資訊能力​

大規模有線/無線網絡​

網絡在多個極端尺度上建立系統之系統​

個人了解為建立一個系統，這個系統包含的第一公民是更小的系統新的時空限制​

多樣的時空複雜度​

動态地再組織，再配置非正常計算與實體基礎​

通信/計算/控制之間的新型互動​

高度自動化，在所有次元上的控制回路必須是閉環的控制回路中，存在大量不熟悉技術的使用者​

無處不在的安全與隐私要求​

在一些情況下，操作必須是可靠的，可驗證的​

CPS不是什麼？不是桌面計算，傳統的事後嵌入式/實時系統和傳感器網絡。CPS研究計劃的目标:​

一門面向未來工程和監控/控制實體系統的新科學（以10-20年的視角展望）實體和資訊技術（計算、通信、控制）設計深度融合​

× CPS應用領域( 不在review.ppt上)​

醫療健康 (醫療用具，健康管理系統)​

防禦系統​

遠端實體操作 (遠端醫療)​

交通運輸 (汽車電子，航空與空域管理，鐵路系統)​

過程控制 (大規模基建，實體基礎設施的監控與控制，發電與配電)​

MDA與模型驅動開發 ​

What is MDA?(非review.ppt内容)​

Model Driven Architecture® (MDA®) is an approach to software design, development and implementation spearheaded by the OMG. MDA provides guidelines for structuring software specifications that are expressed as models. MDA separates business and application logic from underlying platform technology​

模型驅動架構®（MDA®）是由OMG牽頭的軟體設計、開發和實施方法。MDA提供了建構以模型表示的軟體規範的指南。MDA将業務和應用程式邏輯與底層平台技術分離​

總結：模型驅動架構(MDA)是軟體開發流程的方法​

[from ​​www.omg.org​​]​

何為模型？​

它是某些系統的簡化/抽象表示，從給定的角度突出感興趣的屬性。​

這個觀點(即上文提及的給定的角度)定義了模型的關注點和關注範圍。​

系統層次圖:​

MDA的三種模型​

計算獨立模型（CIM ,Coputation-Independent Model）​

描述系統的需求和将在其中使用系統的業務上下文。此模型通常描述系統将用于做什麼，而不描述如何實作系統。CIM 通常用業務語言或領域特定語言來表示​

平台獨立模型 （PIM,Platform-Idenpendent Model）​

描述如何構造系統，而不涉及到用于實作模型的技術。此模型不描述用于為特定平台建構解決方案的機制。PIM 在由特定平台實作時可能是适當的，或者可能适合于多種平台上的實作。​

平台特定模型 （PSM,Platform-Specific Model）​

從特定平台的角度描述解決方案。其中包括如何實作 CIM 和如何在特定平台上完成該實作的細節。​

這個圖描述了開發時，CIM,PIM,PSM三者之間在時間上關系​

這個圖描述了開發時，CIM,PIM,PSM具體做什麼，他們之間的層次結構是怎麼樣的​

這個圖進一步具體化描述了三者之間的層次關系​

安全攸關系統與實時系統 ​

實時系統定義​

在實時系統中，系統的正确性不僅取決于計算的邏輯結果，而且還取決于結果産生的時間。​

一些實時系統相關定義​

1. 時間限制（Timing constraint）：對執行時間行為的限制（包括硬實時和軟實時）​
2. 釋出時間（Release Time）：作業變成為可執行的時間。如果所有的工作在系統開始執行時被釋出，那麼就認為沒有釋出時間​
3. 截止期（Deadline）：工作被要求執行完成的時間。如果截止期是無限的，那麼工作就沒有截止期。絕對截止期等于釋出時間加上相對截止期​
4. 響應時間（Response time）：作業從釋出到執行完成的時間長度​

三種類型的系統​

事件驅動系統（Event-Driven System）​

其行為主要是對外部事件的特定反應來驅動而不是自發産生的。時間驅動系統（Time-Driven Systems）​

其行為主要由時間推移或時間的到來驅動。​

下圖主要為事件驅動和時間驅動的差別​

及時性​

(時效性？我不知道怎麼翻譯，反正是這個意思，你懂就好)​

行動的及時性與滿足時間限制的動作有關，如截止期時間。截止期可能是硬的，也可能是軟的。錯過一個硬截止期會構成某種系統故障，是以必須非常小心地確定所有此類操作都能及時執行。及時性的重要模組化關注點是對執行時間、截止期、到達模式、同步模式和時間源進行模組化。​

并發性​

并發是同時執行多個連續的操作鍊。這些操作鍊可以在一個處理器（僞并發）或多個處理器（真并發）上執行。圍繞并發系統執行，必須處理一下問題：​

并發線程的排程特性進入事件的到達模式​

當程序必須同步時使用的複制模式控制共享資源通路的方法​

正确性與魯棒性​

當一個系統在任何時候都做對的事情時，它就是正确的。這樣一個系統在新的（計劃外）情況下做對的事情時是健壯，即使在系統的某些部分出現計劃外故障的情況下也是如此。必須警惕死鎖、競争條件和其他特殊情況。​

死鎖​

産生死鎖的四個條件​

1. 互斥,任務要求獨占共享資源​
2. 占有且等待，當等待其他資源被釋放時，任務保留資源​
3. 不可剝奪性，任務的資源無法被剝奪​
4. 循環等待，存在循環等待條件​

處理死鎖的方法​

死鎖預防：破壞死鎖的必要條件​

死鎖避免：允許前三個必要條件，但采取措施避免形成循環等待（如，銀行家算法）​

死鎖檢查和死鎖解除：系統檢查是否存在死鎖，若存在，則通過撤銷部分程序等方法回收資源，解除死鎖​

否定條件4的方法：​

信号量機制（如，哲學家進餐問題）使用定時會合（timed rendezvous）​

時間自動機 ​

時間自動機是實時系統模組化與驗證的理論。時間自動機本質上是一個用實值變量（時間系統）進行擴充的有限自動機（包含一組有限節點和一組有限帶有标記的邊的圖）​

UPPAAL分為三部分：編輯器，模拟器，驗證器​

其中編輯器用于設計模型，模拟器用于模拟時間自動機的進行，驗證器用于驗證模型是否符合特定的性質​

時間自動機的定義與元素構成​

變量（variables）對系統中的邏輯時鐘進行模組化，在系統啟動時用零初始化，然後以相同的速率同步增加​

時鐘限制（clock constraints），即邊上用于限制自動機行為的限制（Guard）​

當時鐘值滿足在邊上标記限制（Guard）時，邊表示的轉換（transition）就可以發生。 當進行轉換時，時鐘可能被重置為零。​

使用UPPAAL描述時間自動機​

模拟器與編輯器​

編輯器-聲明的文法：​

驗證器-性質驗證的文法：todo​

時間自動機的形式化表達​

（并不想翻譯這個，數學什麼的最煩了啦）​

幾個時間自動機的例子​

實時系統 ​

實時系統的排程算法：​

(後邊會講這兩個算法)​

固定優先級算法, 如RM（Rate Monotonic，單調速率）​

動态優先級算法，如EDF，（Earliest Deadline First，最早截止期優先）​

實時作業系統的特性​

實時作業系統核心的實時性能定量名額包括​

任務上下文切換時間：中斷延遲，響應，恢複時間，任務響應時間最大中斷禁止時間：反映核心對外界停止中斷響應的最長時間​

任務上下文切換時間：系統中最頻繁發生的動作，影響整個系統性能​

包括：儲存目前任務上下文、選擇新任務，及恢複新任務上下文三個階段​

一些實時系統的概念​

這裡的Job,Work,Task含義是不同的​

Job( 我翻譯成作業)，工作（work）的機關比方說計算，檔案讀取，消息傳輸​

屬性​

執行所需的資源時間參數​

任務(Task)：它從讀取輸入資料及其内部狀态開始，以生成結果和更新内部狀态結束。​

(stateless)無狀态任務：調用點上沒有内部狀态​

(statefull)有狀态任務：有内部狀态​

Task就是一系列類似的jobs​

定期任務是這樣定義的: Periodic task(p,e)​

(Period)這個工作每p機關時間内都要執行​

(Execution time)e是在p時間段内，這個任務的最大執行時間(Utilization)使用率U= e/p​

截止期(Deadline)：軟實時與硬實時​

硬截止期(Hard deadline,硬實時)​

逾時則會發生災難性和非常嚴重的後果 (記住它)​

驗證是至關重要的：即使是在最壞的情況下，所有的最後期限都能得到滿足嗎？确定性的保證​

軟截止期(Soft deadline,軟實時)​

理想情況下，截止期前發揮最大性能。逾時則性能下降。​

盡可能地通過各類方法和統計去保證​

可排程性​

訓示實時系統（一組實時任務）是否能在截止期前完成任務的屬性。​

實時排程​

決定實時任務的執行序列靜态優先級排程​

動态優先級排程​

RM (Rate Monotonic)排程算法​

中文名：單調速率排程算法​

最佳靜态優先級排程算法​

根據周期(Period)配置設定優先級周期越短，優先級越高​

每次執行最段周期的任務​

該算法的幾個限制：第三句自己了解​

The original Rate Monotonic approach had several restrictions:​

1. all tasks are independent of each other(e.g. they do not interact)​
2. alltasksareperiodic

no task can block waiting for an external event.​

1. all tasks share a common release time(caled the critical instant)​
2. all tasks have a deadline equal to their period.​

最初的速率單調法有幾個限制：​

1. 所有任務互相獨立（例如，它們不互相作用）​
2. 所有任務都是周期性的

任何任務都不能阻止等待外部事件。​

1. 所有任務共享一個共同的釋出時間（按關鍵時刻計算）​
2. 所有任務的截止期都與任務周期相等。

1. SignalEvent:信号事件​信号異步通信的規範，信号不知道什麼時候來，當信号來的時候，将會作出某個動作。（相當于軟體層面上的中斷）​
2. CallEvent:調用事件​調用是同步通信的規範​
3. TimeEvent:定時事件​
4. ChangeEvent:變化事件​

響應時間​

這裡不知道是所有任務執行完的時間還是任務3的響應時間，猜測應該是單個任務的​

RM算法的使用率綁定(Utilization Bound)​

借由該性質，可以判斷一系列實時任務是否具有可排程性​

EDF(Earliest Deadline First)排程算法​

中文名：最早截止期優先​

截止期越短，優先級越高​

每次選擇最早截止期的任務進行排程​

這句話應該是說EDF可以排程的任務集合​

實時作業系統特點​

提高核心實時性的方法: 任務互斥、同步​

資源有限等待​

任務沒能獲得需要的資源會被阻塞。如果資源不是任務繼續運作必備的，任務可選擇有限等待該資源。​

優先級反轉​

什麼是優先級反轉呢？​

解決方法：​

優先級繼承協定（課程隻教了這個）低優先級任務繼承高優先級的優先級​

多任務核心應允許動态改變任務的優先級以避免發生優先級反轉現象 。為防止發生優先級反轉,核心能自動變換任務的優先級,這叫做優先級繼承(Priority inheritance)​

(不在複習範圍内)優先權極限​

任務進入臨界區時，提升其優先級至最高，退出臨界區後，優先權恢複。使得任務可以盡快退出臨界區。​

ROPES ​

前言說明​

注意，本節基本上是翻譯其他ppt的内容​

其主要介紹ROPES的開發流程，以及每個流程中具體的步驟​

每個流程主要分這幾部分講述：是什麼，元模型實體，Artifact，活動​

“是什麼”主要講述這部分主要幹什麼​

”元模型實體“主要講述了它用的元模型内容是啥，其實就是構成這部分流程的用到的模型是什麼Arrifact我不知道怎麼翻譯，它是指每個流程中，會用到的東西，比方說，需求，用例場景，類圖等等​

活動主要講這部分流程中，要做什麼​

流程主要是分析-設計-實作-測試這四個部分​

元模型​

參考連結：​​http://blog.sina.com.cn/s/blog_8077b6d901012iyf.html​​ 1 什麼是元模型​

首先我們知道，軟體系統的開發過程中有很多種模型，這些模型往往有相似的地方，比方說活動圖和狀态圖。​

元模型定義了描述某一類模型的規範，具體來說就是組成模型的元素和元素之間的關系。​

ROPES: Rapid Object-Oriented Process Embedded System​

快速面向對象過程嵌入式系統​

開發過程的步驟​

分析(Analysis)->設計(Design)->轉化(Translation)->測試(Testing)每個階段都允許關注同一系統的不同方面。​

分析階段進一步劃分為:需求分析，系統分析，對象分析。設計階段進一步劃分為：架構設計，機制設計，詳細設計​

×需求分析-活動（指如何進行需求分析）​

PS：下面讨論會用到用例圖和序列圖，請注意，用例和用例圖不是一個概念用例包含了用例圖，狀态圖，外部事件清單，上下文圖等​

需求分析步驟​

确定用例與相關的參與者用以下關系分解用例​

泛化（generalization）​

使用（包含）（uses (or includes) ）拓展（extends）​

識别并描述影響系統的外部事件​

定義可捕獲系統動态行為的行為場景确定所需的限制​

與其他系統進行互動所需要的接口性能限制​

大多數系統由三種類型的用例構成：​

主要用例：系統外部可見且明顯的功能​

輔助用例（次要用例）：不太常見，但仍可以識别出重要的功能​

安全相關用例：這些用例存在于除了正常功能外，系統還充當另一個系統的安全螢幕或啟用器時。​

一旦用例被定義了，則場景（Senarios）可以被更加詳細地進行檢查。場景是用例的執行個體化。​

PS：下面是讨論的其實是序列圖​

在需求分析期間，還可以識别與系統及其屬性相關的事件。此分析包括參與者發送到系統的消息和事件，以及系統對這些消息的響應。在此級層次上的每個消息的性能屬性包括以下内容：​

參與者：​

消息發送者​

做出反應的接收者​

到達模式（周期性或突發性）：周期性就是周期地來，突發性就是不知道什麼時候來​

消息的到達時間​

周期消息的周期和抖動​

突發消息的最小到達間隔或突發長度消息響應特性​

為硬截止期消息設定的截止期​

為軟截止期消息設定的平均響應時間消息狀态資訊​

該消息的先決條件不變量通信協定​

消息資料​

響應的後條件不變量​

×需求分析-所用的元模型實體​

需求分析中，用到兩種不同的元素：上下文元素和行為元素上下文元素定義了以下内容​

參與者（存在于系統範圍之外的對象）​

系統對象用例​

用例關系​

外部消息（包括事件）危險​

行為元素包含了以下内容限制​

性能要求錯容時間​

狀态圖​

狀态​

轉移邊（transition，直接翻譯是“轉移”，其實就是狀态之間的有向邊）場景（scenario）​

互動協定（在參與者和系統互動時用到）​

× 需求分析-Artifacts​

工件（Artifact）:​

其定義是這樣的：​

An artifact is one of many kinds of tangible by-products produced during the development of software. Some artifacts (e.g., use cases, class diagrams, and other Unified Modeling Language (UML) models, requirements and design documents) help describe the function, architecture, and design of software. Other artifacts are concerned with the process of development itself—such as project plans, business cases, and risk assessments.​

下面是各類工件的介紹​

×系統分析​

系統分析是什麼？​

系統分析是大型複雜實時系統的一個重要階段，如航空航天和汽車應用的系統。系統分析通常會詳細闡述關鍵算法，并将需求劃分為電子、機械和軟體元件。通常，行為模組化工具，如狀态圖，被用來建構可執行模型和探索系統動力學。​

×系統分析-活動（指如何進行系統分析）​

主要流程：​

識别劃分出複雜系統的大規模組織單元為組織單元建構和分析複雜的行為規範​

将系統級的功能劃分為三個工程學科: 軟體,電子,機械（我翻譯成機械，mechanics）用可執行模型測試行為（behavior）​

×系統分析-活動所用的元模型實體​

這圖的“Artifact”與前邊需求分析的Artifact差不多一個意思，隻不過具體指代的東西有所差別​

× 系統分析-對象分析-活動​

主要流程：​

應用對象識别政策來發現系統的基本對象抽象對象得到類​

顯化類和對象之間的關系，關聯是怎麼樣的​

建構滿足用例行為需求的對象協作機制（就是說根據這個用例，對象之間要怎麼樣進行通信，産生對應的行為）​

定義可反應對象的基本行為（可反應對象應該就是說你可以通過某種方法觸發這個對象的行為）确定對象的基本操作和屬性​

用場景測試已識别的機制（就是你發現的對象之間的協作機制）​

将端到端性能限制分解為類操作的性能限制（就是要把兩個端的，比方說兩台機器的，性能限制具體到每個類的操作上，這樣才能滿足實時性的要求。舉例，A和B進行通信，RTT需要小于10ms，則具體到類的操作上，可以是send不超過5ms,receive不超過5ms）​

× 系統分析-對象分析-Artifacts​

× 設計​

當分析确定系統的邏輯或基本模型時，設計定義了一個在某種意義上是“最優”的單一特定解決方案。例如，設計将識别以下的東西：​

哪些對象是活動的（并發模型）應用程式任務排程政策​

可部署元件内的類和對象的組織處理器間通信媒體和協定​

把軟體元件配置設定到節點（特别是，當跳過了系統分析步驟)​

關系實作政策(關聯應該如何實作？指針？引用？TCP/IP套接字？)狀态機的實作模式；​

多值角色的管理（舉例，1-*關聯）錯誤處理政策​

記憶體管理政策​

× 架構設計-活動​

ROPES确定了架構的五個重要視圖：子系統群組件、并發性和資源、配置設定、安全性和可靠性、部署。架構設計的主要活動是​

線程的識别和表征軟體元件及其分發​

架構設計模式的應用：​

全局錯誤處理安全處理​

容錯​

× 架構設計-所用的元模型實體​

由于設計模型是對分析模型的一種詳細闡述，是以它由相同的一組元素組成。基本元素是協作、類、對象及它們之間的關系。​

在體系結構設計中，特别關注的是節點、元件和活動類。節點群組件捕獲了實體部署體系結構。​

活動對象是作為線程的起源的對象。它們構成了UML并發模型的基礎。​

× 架構設計-Artifacts​

× 機制設計-活動​

在機制設計中，通過添加其他對象來細化對象協作的細節。​

例如，如果一個控制器必須管理許多未決的消息，則可以應用容器-疊代器模式。​

這将導緻插入一個容器（例如一個FIFO用來儲存消息的隊列）和允許操作該容器的疊代器。容器類和疊代器類充當“粘合劑”，以促進協作的執行。​

× 機制設計-Artifacts​

× 詳細設計​

詳細設計是設計的最低水準。它涉及到單個類的内部結構和行為的定義。​

（其實就是打代碼）​

× 詳細設計-活動​

一個典型系統中的大多數類都非常簡單，不需要太多詳細的設計。然而，即使在此時，也必須定義關聯、聚合群組合的實作。​

此外，還必須指定操作的前條件不變量和後條件不變量、類的異常處理模型以及屬性的精确類型和有效範圍。​

對于一些小的類集，必須澄清複雜的算法。​

× 詳細設計-活動-Artifacts​

× 轉化（Translation）:todo​

轉化階段将UML模型轉換為源代碼，并通過編譯器轉換為可執行系統，如圖所示。​

× 轉化（Translation）-活動​

在一個不完整的轉化微周期中，轉化多少有一部分是自動化的。​

在詳細說明的方法中，開發人員必須将UML模型元素映射到程式設計語言元素。​

如果使用了一種面向對象的語言，這個過程是相當機械的，因為所有重要的決策都已經在分析和設計過程中做出了。​

如果使用了一種非面向對象的語言，那麼程式設計工作就會更具“創造性”。在這種情況下，通常要編寫一個轉化風格指南。本指南定義了程式員用目智語言實作UML模型的轉化規則，無論是C語言、Pascal還是彙編語言。​

ROPES過程還包括本階段的單元測試。單元測試是一組白盒測試，以確定被測試的單元實際上是内部正确的，并符合設計的要求。​

這通常由單元測試計劃和單元測試程式檔案組成，并最終形成一個單元測試結果檔案。單元測試計劃通常圍繞類的基本單元進行組織。文檔通常是在包或元件級别編寫。​

× 轉化（Translation）-Artifacts​

× 測試​

ROPES過程中的測試階段包括內建測試和有效測試。​

測試将一組測試向量應用于具有可觀察結果的應用程式。測試向量主要基于在需求和對象分析階段中确定的場景。​

生成的工件（artifacts）是一個經過測試的應用程式及其顯示的缺陷（比方說bug）。​

× 測試-活動​

所有的測試都應根據測試計劃來執行，并嚴格按照測試程式檔案來執行。​

在內建測試中，該系統是通過每次添加一個元件來建構的。在添加新元件的每個點上，都将測試通過添加該元件而建立的接口。​

有效測試由測試團隊定義，并表示早期完成的需求和系統分析集。​

有效測試基本上是黑盒子。唯一的例外是對安全方面的測試。這些測試是白盒，因為通常需要進入系統内部并打破（break）一些東西，以確定安全操作被正确執行。​

× 測試-Artifacts​

× ROPES總結​

在ROPES模型中确定的階段被組織成一個疊代的生命周期。每個原型通常實作一個或多個用例，按風險進行組織（風險更大的優先）。這允許對風險進行早期探索，并最小化由于這些風險而必須修改的模型方面的數量。​

為了探索這些風險，必須開發可執行的原型，因為隻能測試可執行的東西。是以，使這一過程快速和高效的關鍵啟用技術是将模型自動轉換為可執行代碼。這将完成疊代所需的時間從幾周或幾個月減少到幾小時或幾天。​

ROPES支援精細(elaborative)和轉化（translative）的發展微周期，但傾向于後者(即轉化)。​

UML模組化（強烈建議直接看第三個ppt，複習PPT講得有點拐彎抹角的，斷斷續續的） ​

将會讨論到的符号與概念​

以下是手動翻譯​

英文名​	中文名​
AdvantagesofObjects​	對象的優點​
StructuredClasses​	結構化類​
Packages​	包​
InterfacesandPorts​	接口與端口​
Stereotypes​	模闆​
Components​	元件​
Architecture​	架構​
ClassesandObjects​	類與對象​
Constraints​	限制​
Subsystems​	子系統​
Relations​	關系​
Tags​	标簽​

對象，類與接口​

屬性（資料）Attributes​

行為（操作或方法）Behavior狀态（記憶體）State​

身份 Identity​

責任（就是該幹啥） Responsibility​

舉例：​

概覽圖：​

詳細舉例​

屬性​

操作與方法​

概覽：動态行為的模組化​

行為的類型狀态圖​

活動圖序列圖​

行為和UML​

QOS限制：非功能性限制​

QOS限制通常使用一種限制語言進行模組化。(OCL)​

行為與單一的對象​

UML的主要特征是他支援有限狀态自動機(FSM)​

狀态圖的兩個基本概念：狀态與轉移（是有向邊附帶了一些動作和其他屬性，類似于下邊的箭頭）​

一個狀态是一個不同于其他條件的執行個體的存在的條件。​

不相交的狀态被稱為 或-狀态（or-states） ，因為對象必須處于其中狀态之一。​

狀态圖​

這兩個圖主要說明了狀态圖是怎麼樣的，以及狀态圖進行狀态轉移時有進入狀态和退出狀态等動作。​

事件​

UML一共包含4種事件​

到達規定時間就會觸發，但是規定時間之内離開了這個狀态，就不會觸發​

與屬性的值更改關聯的事件。它很少用于軟體應用程式；但是，當一個狀态屬性被記憶體映射到一個硬體上時，它可以用來訓示改變了值的記憶體位址。​

Transitions（轉換）​

轉移(Transition)是從起始狀态開始到在目标狀态結束的定向弧。轉移通常可以指定事件觸發器，然後選擇在執行轉移時執行的操作（即可執行語句或操作）。轉移的事件簽名的形式為：​

guard-expression指的是某個布爾表達式，比方說x==0，在判斷限制表達式時，限制表達式裡面的任何變量，比方說x，此時都是隻供該限制的轉移使用的，即實作了臨界區互斥。​

事件可以指定正式的參數清單，這意味着事件可以攜帶實際的參數。​

行為的執行順序很重要。最基本的規則是 exit-transition-entry，exit動作(從某個狀态退出執行的動作)-轉移(轉移邊上的動作)-entry(進入某個狀态執行的動作)。​

參閱 ​​https://www.cnblogs.com/yxx123/p/5227267.html​​​

要會看懂這個圖​

活動圖​

UML1.x中的活動圖在語義上等同于狀态圖，并共享一個共同的元模型。在UML2.0中，活動圖的語義基礎獨立于狀态圖。在UML2.0中，有多個層次的活動圖：基本、中間、完整，等等​

互動​

在UML中有三種主要的圖解形式，用于描述互動場景​

通信圖序列圖時序圖​

序列圖（Sqeuence Diagram）​

序列圖-部分順序​

序列圖-替代、分支、選項與循環​

時間圖​

UML預定義包​

UML預定義包是一種用于使用補充資訊來擴充UML模型的工具。這種機制可以用兩種方式來使用：​

1. 它可以用于擴充UML語言。例如，UML不提供顯式的信号量概念，但是可以通過重載現有的UML概念來添加它，例如Class。其結果是一種特殊的類，除了标準的類語義外，還包含了語量語義。​
2. 它可用于附加附加資訊到輔助目的所需的模型，如模型分析或代碼生成。例如，這樣的注釋可以用于指定類的某個操作的最壞情況執行時間，這可能需要用于分析應用程式的定時特性。​

實驗 ​

實驗一：學會使用Rhapsody建立新工程​

主要内容：​

在預設元件（Default Component）下建立了一個類，名為Display，然後右擊類，選擇顯示所有屬性和操作（即函數）。​

接下來為類新增一個Constructor(構造函數)，并在構造函數裡面寫入輸出語句，這樣這個類被執行個體化的時候即可輸出資訊。​

右擊Diskplay，選擇屬性，在Propetires->ImpIndudes中填入<iostream>，相當于訓示包含進去這個檔案，以供輸出​

更改DefaultComponent的名稱為Test​

将配置（Configurations）下的預設配置資訊（DefaultConfig）改名Release點選Release并在初始化中選擇初始化Display的一個執行個體​

再次點選Release配置，選擇設定，指定好Cygwin作為本項目的編譯器​

此時點選生成并運作，則可以生成程式并看到輸出（注意一開始，可能目錄内并無所需的庫，會開始編譯這些庫，此時需要比較長的時間）​

你也可以右擊Display類，在Display類中編輯代碼​

設定自建選項​

選擇Tools->Customize->helper點選建立一個指令​

這樣你就可以在Tools選擇Explore，直接打開目前代碼的檔案夾​

實驗二：時序圖和狀态圖​

将實驗一建立好的項目，點選另存，并建立一個檔案夾進行儲存，命名為CountDown然後打開這個項目​

接下來點選DisPlay這個類，執行以下操作（基本就是點點點吧，也沒啥好說的，當然也可以右擊​

DisPlay然後選擇編輯代碼）​

新增屬性：int count;此時會自動增加操作：setCount和getCount​

新增兩個重載的函數print,一個參數為int,一個參數為const char *，代碼實作分别輸出參數的内容将構造函數的語句改為​

實作函數isDone其内容為​

(寫不下去了，感覺不如直接看指導書，後邊直接說重點了)​

在類中建立一個狀态圖，記住，這個狀态圖是靜态的，後邊會說到運作時會有動态的狀态圖​

tm是延時函數​

C是僞狀态之一的條件連接配接符然後run一下​

看到下圖​

複制原有的Release配置，改名Debug，把裡面改為動畫​

接下來運作的時候，你就能“像調試一樣”一步一步地運作程式，然後會有DisPlay的執行個體生成，這個時候你可以右擊執行個體看他的動态狀态圖​

這時你可以看到執行個體處于哪個狀态上​

接下來建立時序圖，并增加兩條邊界系統邊界和Display的邊界​

這樣就可以顯示系統和Display之間和他們自身的時間序列行為​

同樣，這個時序圖也是靜态的​

然後再次點選運作，系統會在你打開靜态時序圖時，自動地為你建立一個動态時序圖​

最後你可以自己增加一個狀态​

實驗三：UPPAAL增加狀态和寫性質驗證​

主要内容就是找出人-ATM-銀行能否順暢運作，會不會産生問題，會的話修改​

從上到下分别檢查三個性質第一個是總錢數恒為一個數第二個是不會出現死鎖​

第三個是ATM永遠大于0（其實應該大于等于0）​

實驗四：UPPAAL寫同步機制與互斥機制​