本文使用COMET方法對機器人協作系統進行軟件建模與設計，並使用LabVIEW Actor Framework 進行詳細設計。
關於這篇文檔為什么要做這些，以及具體是如何做的，請參考文獻[1]
參考文獻
[1] Gomaa H. Software Modeling and Design Software Modeling and Design: UML, Use Cases, Patterns, and Software Architectures[M]. Cambridge University Press, 2011.
[2] Kim M, Kim S, Choi M, et al. UML-based service robot software development: a case study[J]. International Conference on Software Engineering. 2006: 534-543.
[3] Gamma E, Helm R, Johnson R. Design Patterns: Elements of Reusable Object-Oriented Software[M]. 1994.
[4] Mklab. StarUML Documentation[M]. Release 2.0.0 ed. 2015.
[5] Aristosqueue. READ THIS FIRST to get started with Actor Framework[Z]. NI Community, 2011: 2015.
[6] Lippman S B, Lajoie J, Moo B E. C++ Primer[M]. 5 ed. Pearson Education Inc., 2013.
[7] 邵維忠，楊芙清. 面向對象的系統分析[M]. 第二版. 北京: 清華大學出版社, 2006.
一些自己的想法（讀者請略過）
- 命令至少包括兩種：模式命令（切換到某種模式）和機器人控制命令（語音控制命令，被自然處理模塊和空間推理模塊處理）
- 人機交互界面應該在InputOperator操作者
- 命令解釋器在算法服務部分，是機器人的高層大腦，具體執行動作的程序（來自機器人商業庫）是底層大腦
- 考慮手動指令解析和語音指令解析並沒有統一的方法，所以並不形成一個包含用例，而且這個包含用例太小了
- 是否應該改成“交互環境建模與展現”或者增加“交互環境建模”用例？（模仿 eyes 的鼠標拖動機器人進行定位）
- 自頂向下的類建模，並使用操作者框架，實際上一個ACTOR可以充當邊界對象，控制對象
- 添加用例（命令非法警報用例，異常處理，錯誤恢復用例等）
用COMET解釋LabVIEW Actor Framework（讀者請略過）
- （什么是框架）
- 。。。。參考文獻[3]
- （對操作者的解釋）
- 實際上ACTOR類可以看作一個構件，該構件可以充當任何一種類或多種類（控制類，實體類，人機交互類，算法類等），並能很好地實現狀態控制（采用其擴展功能State Pattern Actor），該構件內部集成了消息通信端口（支持點對點通信，不嚴格支持組播通信，且通信范圍遵循任務樹（Task Tree）），還支持TCP/IP遠程通信。
- （操作者框架可實現的消息通信模式）
- 每一個ACTOR構件都是一個並發對象。ACTOR與ACTOR之間的通信模式可以是：帶回復的同步（緊耦合）消息通信模式，異步（松耦合）消息通信模式，帶回調的異步消息通信模式。另外，使用操作者框架還可以在面向服務的體系結構中實現代理者（Broker）通信模式。
- （從類圖的角度來描述ACTOR類，是一個復合類）
- ACTOR類其實是個復合類，它還可以擴充自己的私有數據，即還可以包含更多（"Has A"）的類（現在的程序中沒有包含更多的類，是因為我們自己的程序並不是使用面向對象方法設計的），所以在靜態建模時，一個ACTOR應該是一個子系統，使用系統之系統。
正文：機器人遠程協作系統建模與設計說明書
- 這是草稿！This IS A DRAFT!
問題描述
- 機器人監管者（Supervisor）在本地工作站上，通過無線局域網與遠程的P3AT移動機器人（P3-AT Mobile Robot）進行協作，完成巡邏，環境監測，危險排除等任務。具體來講，機器人監管者可以使用兩種方式與機器人進行協作：手動控制（Manual Synergetic Control）和語音控制（Voice Synergetic Control），為了更好地與機器人進行協作，機器人在監管者面前應該是透明的，即機器人本體狀態及周圍環境信息應實時展現給監管者。
- 在手動控制中，監管者在本地工作站上使用操縱桿對機器人進行遠程控制，監管者能夠直接控制機器人自身移動，操作機械臂等執行機構，監管者也可以在地圖上點擊一個目標點，命令機器人到達該點位置；在語音交互中，監管者對手機講述中文語音，將聲音信號傳遞給機器人，機器人收到語音信號后執行對應的任務，如“向前走五米”命令。
- 機器人應做到較底層的行為自主，能夠做到自我保護，環境識別與推理，路徑規划等。機器人能夠在較高的思維抽象層次與監管者進行協作。機器人在工作過程中，監管者能夠隨時打斷機器人，獲得最終控制權。
- 在監管者向機器人發送協作指令的同時，機器人將自身的狀態信息和采集到的周圍環境信息傳輸回本地工作站，本地工作站對其進行建模，通過人機交互界面將信息可視化。監管者在本地工作站上將能夠清晰地了解機器人的情況。
用例模型
- 機器人遠程協作系統用例模型如圖所示，根據問題描述，該模型擁有兩個參與者和四個用例（其中一個為包含的子用例）。系統中的人類參與者“監管者”負責發起所有用例，即“語音協作控制”、“手動協作控制”和“查看機器人狀態”。由於所有用例均為人類參與者發起，外部系統參與者“P3-AT機器人”為次要參與者。
- 監管者通過輸入輸出設備與機器人進行協作，由於不管進行何種形式的協作控制，都需要先進行定位，所以“協作定位”用例作為“語音協作控制”和“手動協作控制”用例的包含用例。
//此處可以繼續說明，將機器人參與者特殊化為執行器和傳感器兩個參與者
用例文檔如下
“協作定位”用例
- 用例名：協作定位
- 概述：遠程機器人結合對環境信息的推理以及監管者的提示對自身位置進行確定
- 參與者：監管者和P3-AT機器人
- 前置條件：工作站與機器人連接成功
- 主序列：
- 系統檢查當前定位是否有效
- 如果當前定位無效，則開始交互定位。機器人自主對自身周圍環境信息進行分析，推測自己的位置信息，包括高層信息（如在A513辦公室）和底層信息（坐標信息），並反饋到工作站人機交互界面
- 工作站結合機器人的狀態信息，對信息進行分析，得到關於機器人狀態的信息，反饋到工作站人機交互界面
- 監管者結合反饋的信息，對信息進行確認或者修改，將最后確定的機器人位置信息傳遞給P3-AT機器人，定位成功，定位結束。
- 可替換序列：
- 步驟2：當前定位有效，定位成功定位結束。
- 步驟2-4：監管者無法確定機器人位置，取消定位，定位失敗，定位結束。
- 后置條件：機器人定位成功。
“手動協作控制”用例
- 用例名：手動協作控制
- 概述：監管者在本地工作站，使用標准輸入設備（鍵盤和鼠標）和游戲手柄輸入設備對機器人進行遠程控制。
- 參與者：監管者和P3-AT機器人
- 前置條件：工作站與機器人連接成功
- 主序列：
- 機器人與監管者交互定位
- 監管員要求進行手動協作控制，並選擇控制模式：鍵盤控制、手柄控制或地圖導引控制
- 監管者操作標准輸入設備和游戲手柄，將命令錄入到本地工作站
- 如果命令錄入成功，本地工作站結合機器人狀態數據，對命令進行初步分析，得到指令的抽象信息（類型，參數大小等），同時驗證命令的合法性
- 如果命令合法，本地工作站對命令進行解釋，解釋成機器人能夠理解或直接執行的較底層指令
- 如果解釋成功，本地工作站將解釋好的指令傳遞給遠程機器人
- 遠程機器人對指令進行執行，並在人機交互界面顯示命令執行情況
- 如果命令執行情況正常，則在命令執行完畢后在人機交互界面顯示執行結束情況
- 可替換序列：
- 步驟4：如果輸入設備命令輸入失敗，工作站人機交互界面予以顯示並停止，並要求監管者檢查設備。
- 步驟5：如果命令不合法，工作站人機交互界面上予以顯示並停止，並要求監管者修改或者重新輸入命令
- 步驟6：如果命令解釋失敗，工作站人機交互界面上予以顯示並停止，並要求監管者檢查命令或重新輸入命令
- 步驟8：如果命令執行過程中出現失敗，工作站人機交互界面上予以顯示並停止，並要求監管者重新輸入命令。
- 步驟2-8：監管者放棄手動協作控制，控制結束。
“語音協作控制”用例
- 用例名：語音協作控制
- 概述：監管者在本地工作站，使用安卓手機輸入語音信號，對機器人進行遠程控制。
- 參與者：監管者和P3-AT機器人
- 前置條件：工作站與機器人連接成功
- 主序列：
- 機器人與監管者交互定位
- 監管員要求進行語音協作控制
- 監管者使用手機輸入進行語音信號錄入，手機端將語音信號解釋為中文命令，錄入到本地工作站
- 本地工作站結合機器人狀態數據，對命令進行初步分析，得到指令的抽象信息（類型，參數大小等），驗證命令的合法性
- 如果命令合法，本地工作站對命令進行解釋（翻譯？），解釋成機器人能夠理解或直接執行的指令
- 如果解釋成功，本地工作站將解釋好的指令傳遞給遠程機器人
- 遠程機器人對指令進行執行，並在人機交互界面顯示命令執行情況
- 如果命令執行情況正常，則在命令執行完畢后在人機交互界面顯示執行結束情況
- 可替換序列：
- 步驟5：如果命令不合法，工作站人機交互界面上予以顯示並停止，並要求監管者修改或者重新輸入命令
- 步驟6：如果命令解釋失敗，工作站人機交互界面上予以顯示並停止，並要求監管者檢查命令或重新輸入命令
- 步驟8：如果命令執行過程中出現失敗，則在人機交互界面上予以顯示並停止，並要求監管者重新輸入命令。
- 步驟2-8：監管者放棄語音協作控制，控制結束。
“查看機器人狀態”用例
- 用例名：查看機器人狀態
- 概述：機器人將周圍環境信息和自身狀態信息進行建模和分析，然后發送會本地工作站進行圖形化顯示，供監管者查看。
- 參與者：監管者和機器人
- 前置條件：工作站與機器人連接成功
- 主序列：
- 監管者要求開啟某項機器人傳感器
- 機器人檢查自身完整性
- 若機器人設備完好無損，則開始進行環境信息采集工作
- 機器人結合自身的知識庫或本體情況對采集到的環境信息進行分析，得出抽象狀態信息
- 如果抽象狀態信息分析成功且有效，則將其傳回本地工作站的人機交互界面。
- 工作站的人機交互界面對信息進行可視化處理，形成友好的圖形化數據。
- 可替換序列
- 步驟3：如果機器人某項設備損壞，則向工作站人機交互界面顯示，要求監管者檢查。
- 步驟5：如果抽象狀態信息分析失敗，則向工作站人機交互界面顯示，要求調整。
- 步驟2-6：監管者關閉所有傳感器，機器人狀態查看退出。
- //對用例文檔還要畫出活動圖
靜態建模Static Model
- 本節先對問題域和系統上下文進行考慮，然后討論實體類的靜態建模。
問題域的概念靜態模型Conceptual Static Model
- 圖【】給出了用類圖表示的概念靜態模型。這里描述了一個系統之系統，包括“輸入管理系統”，“全局協調系統”，“命令解析系統”，“執行管理系統”，“顯示系統”。“輸入管理系統”被建模為一個復合類，包括“手柄讀入器”，“聲音讀入器”，“控制面板”類。
- 人類參與者通過手柄，聲音輸入設備，人機交互面板將協作命令輸入到輸入管理系統，輸入管理系統通過全局協調系統與命令解析系統和執行管理系統聯絡，通過執行管理系統與外部的機器人參與者交互，同時機器人參與者將自身消息錄入，通過全局協調系統與現實系統聯絡，顯示機器人狀態信息。
- 為了便於下一節建模，這里給出所有的物理類：。。。
系統上下文的靜態建模Context Model
- 軟件系統的上下文類圖使用靜態建模表示法，將“機器人協作系統”看作一個聚合類。描述了與“機器人協作系統”存在交互關系的外部類。我們通過考慮問題域的靜態建模過程中所所確定的物理類來開發上下文類圖。
- 如圖所示，從整個系統（包括軟件和硬件）的角度看，“監管者”和“機器人”參與者都位於系統外部。“監管者”參與者通過鍵盤顯示器、手柄和聲音輸入設備與軟件系統交互。“機器人”參與者作為外部系統直接與機器人協作軟件系統交互。從整個軟硬件系統的角度來說，這些通用或專用的輸入輸出設備是系統的一部分。從軟件的角度來說，這個設備位於軟件系統的外部。所以在軟件系統的上下文類圖中，這些設備被建模為外部類。
- 兩個參與者都被建模為外部用戶。
- 注意：顯示系統根本就不是什么外部系統，建模為ACTOR，這個想法是錯誤的！要是都建模為外部系統，那還編什么程序，都在軟件系統外部。
系統實體類建模（在顯示控件中的數據是實體數據？？）
- 理解不夠深刻，不知道怎么將操作者框架和COMET結合起來
- 初步的想法是，操作者框架中的消息就是存有數據的實體。（Message is the object）
- 實體類是概念性的數據密集型類——他們的主要目的是存儲數據並提供對這些數據的訪問。在許多情況下，實體類是持久的，這意味着數據是長久存在的，並需要存儲在文件或者數據庫中。實體類通常在設計階段映射到一個數據庫或文件。
- 為消息建模？
-
消息名稱
從
到
在設計過程中分成了幾個子消息
任務
JoystickControlMsg
ExternalDevice
JoyStick Actor
讀取
JoyStick Actor
InputOperator
直傳
InputOperator
Cooradinator
直傳
Cooradinator
P3AT
直傳
VoiceStringMsg
ExternalDevice
VoiceControl
讀取
VoiceControlMsg
VoiceControl
InputOperator
解析后傳
InputOperator
Cooradinator
直傳
Cooradinator
AgorithmService
(ServiceManager)
直傳
ExecutionMsg
AgorithmService
Cooradinator
解析后傳
Cooradinator
OutputOperator
直傳
OutputOperator
P3AT
解析后傳
P3ATRTData
ExternalDevice
P3AT
P3AT
OutputOperator
OutputOperator
MapDisplayer
- 考慮到，除了手柄控制消息之外，其他數據都是只發一次的按需發送消息（按需I/O），為了在致命錯誤時能夠正常恢復數據，這些數據都應該作為持久數據以便進行恢復。
- 每一個實體類都包括大量屬性，還有一些公共的屬性，如：是否過期（有效）布爾值；（目前不確定）
- 所以，最終我們建了若干實體類，但是仍然有一些數據需要持久存儲，比如P3AT機器人的IP地址和Port數據，這一部分還需進一步考慮
- 還需要畫出類與類間的關系圖，多重性關系，目前還不清楚，需要設計。
對象組織（所有的函數/過程都應該成為類的方法！）
- 在定義了用例和開發了問題域的靜態模型后，下一步是確定系統的軟件對象。在這個階段，重點在對問題域中真實世界對象進行建模的軟件對象上。
- 軟件對象是由用例和問題域的靜態模型確定的。重點是在真實世界中發現的問題域對象，而不是在設計時確定的解域對象。
- 上一節中描述的靜態建模被用來確定外部類，然后這些外部類會被描繪在軟件系統上下文類圖中。這些外部類會用來幫助確定軟件邊界類——連接到外部環境並與之通信的軟件類。實體類及其關系也是在靜態建模時確定的。本節中，軟件系統所需要的對象和類被確定和分類。特別的，本節的焦點是那些在問題域靜態建模期間沒有被確定的附加的軟件對象和類。
- （接下來的工作是審查LV代碼，將所有的函數/過程都建模為類！）然后進行類和對象組織！
動態建模
子系統高層通信圖