本文探討了在嵌入式開(kāi)發(fā)中設(shè)計(jì)嵌入式軟件架構(gòu)的第四步——接口和組件設(shè)計(jì)。
在上一篇文章中，我們探討了如何將一個(gè)系統(tǒng)分解成域和任務(wù)，我們已經(jīng)確定了該系統(tǒng)的數(shù)據(jù)資產(chǎn)。你可能還記得，我們創(chuàng)建的上一張圖將我們的應(yīng)用程序分為安全和非安全應(yīng)用程序域、硬件獨(dú)立和依賴(lài)域(由抽象層分隔)，最后分為任務(wù)。我們的系統(tǒng)分解如圖1所示。
由于blog格式的空間和時(shí)間限制，我們建議在描述如何讓任務(wù)進(jìn)行交互的架構(gòu)過(guò)程中增加額外的步驟。我們想探索如何完成我們的一項(xiàng)任務(wù)，并設(shè)計(jì)我們的界面和組件。讓我們看看如何為電機(jī)任務(wù)定義組件及其接口。
步驟4–接口和組件設(shè)計(jì)
組件和界面設(shè)計(jì)是密切相關(guān)的活動(dòng)。事實(shí)上，如果我們查看組件的標(biāo)準(zhǔn)定義，我們會(huì)發(fā)現(xiàn)以下描述：
軟件組件是一個(gè)組合單元，具有合同規(guī)定的接口和明確的上下文依賴(lài)關(guān)系。
我們甚至不能在不討論接口的情況下定義組件！接口是軟件開(kāi)發(fā)人員用來(lái)與組件交互的工具。因此，我們開(kāi)始將我們的運(yùn)動(dòng)任務(wù)分解為組件是有意義的，然后我們可以為每個(gè)組件定義接口。
定義軟件組件
嵌入式開(kāi)發(fā)人員可以使用許多不同的方法和技術(shù)來(lái)識(shí)別將堆疊在一起以執(zhí)行任務(wù)提供的期望行為的組件。我對(duì)幾乎任何任務(wù)的偏好都是將系統(tǒng)分解成一個(gè)分層的軟件圖，從底層驅(qū)動(dòng)程序開(kāi)始，一直到應(yīng)用程序代碼。圖2顯示了一個(gè)示例，顯示了電機(jī)任務(wù)的這種圖。
這些組件的用途可能是不言自明的，但為了以防萬(wàn)一，讓我們定義一下每個(gè)組件的作用：
pwm_drv — 微控制器上用于脈寬調(diào)制的硬件外設(shè)驅(qū)動(dòng)器。
Abstraction layer — 打破電機(jī)驅(qū)動(dòng)器和硬件之間的依賴(lài)關(guān)系。這允許我們使用PWM驅(qū)動(dòng)器來(lái)驅(qū)動(dòng)電機(jī)，或者用外部集成電路的驅(qū)動(dòng)器來(lái)代替pwm_drv。
motor_drv — 設(shè)計(jì)用于控制電機(jī)的驅(qū)動(dòng)器。它沒(méi)有硬件依賴(lài)性。它唯一的依賴(lài)是抽象層。
motor_sm — 跟蹤電機(jī)當(dāng)前狀態(tài)和所需狀態(tài)的狀態(tài)機(jī)。
motor_app — 特定應(yīng)用支持功能。這些功能可能包括收集遙測(cè)數(shù)據(jù)、檢查故障等。
motor_task — 保存實(shí)際電機(jī)任務(wù)代碼的組件。該元件依賴(lài)于其他電機(jī)元件。電機(jī)任務(wù)可能包括RTOS應(yīng)用程序交互，如信號(hào)量、隊(duì)列、互斥和事件邏輯。
總之，這些組件具有接收命令的所有必要行為，該命令改變控制電機(jī)的狀態(tài)機(jī)，然后啟動(dòng)電機(jī)。這種分解很酷的一點(diǎn)是，如果電機(jī)控制鏈的各個(gè)方面發(fā)生變化，比如新的驅(qū)動(dòng)芯片、新的應(yīng)用程序需求等，有了適當(dāng)?shù)慕涌冢?span>嵌入式開(kāi)發(fā)人員只需要進(jìn)行最小的更改。
定義接口
對(duì)于motor任務(wù)，我們需要定義兩類(lèi)接口。首先，有一個(gè)任務(wù)接口，它接收來(lái)自其他應(yīng)用程序組件的命令，告訴它電機(jī)應(yīng)該做什么，比如MOTOR_ON或MOTOR_OFF。其次，每個(gè)組件都有接口。
電機(jī)任務(wù)接口設(shè)計(jì)
在定義與電機(jī)任務(wù)通信的接口時(shí)，回顧圖1中所示的數(shù)據(jù)資產(chǎn)是很有幫助的。我們可以看到控制器任務(wù)與電機(jī)任務(wù)交互。為了讓控制器任務(wù)告訴電機(jī)任務(wù)電機(jī)應(yīng)該做什么，需要幾條信息：電機(jī)狀態(tài)、電機(jī)方向、電機(jī)轉(zhuǎn)速。
如果我們希望系統(tǒng)可伸縮以管理多個(gè)電機(jī)，我們甚至可以包括一個(gè)電機(jī)ID。例如，在有些應(yīng)用中，狀態(tài)機(jī)通過(guò)消息控制電機(jī)，但用戶可以用消息覆蓋狀態(tài)。在這些情況下，我們甚至可能希望包含一個(gè)任務(wù)ID，以便電機(jī)任務(wù)知道哪個(gè)任務(wù)正在請(qǐng)求電機(jī)控制。
從數(shù)據(jù)接口的角度來(lái)看，嵌入式開(kāi)發(fā)人員可以為數(shù)據(jù)定義一個(gè)結(jié)構(gòu)，該結(jié)構(gòu)將用于控制和電機(jī)任務(wù)的接口。用C語(yǔ)言編寫(xiě)如下代碼：
MotorMessage_t結(jié)構(gòu)定義了命令電機(jī)任務(wù)執(zhí)行實(shí)際工作所需的數(shù)據(jù)接口。我們?nèi)绾潍@得機(jī)動(dòng)任務(wù)的信息取決于項(xiàng)目的需求。例如，使用消息隊(duì)列、數(shù)據(jù)緩沖區(qū)或其他機(jī)制。然而，這些細(xì)節(jié)是由程序員決定的，而不是軟件架構(gòu)師。
定義組件接口
有幾種不同的方法來(lái)為我們的組件設(shè)計(jì)界面。首先，我們可以做一個(gè)便簽，列出我們認(rèn)為需要的功能。接下來(lái)，我們可以使用一些UML圖表工具并利用類(lèi)圖，即使我們沒(méi)有編寫(xiě)面向?qū)ο蟮拇a。最后，我們可以直接進(jìn)入代碼，開(kāi)始編寫(xiě)測(cè)試，迫使我們?yōu)榻M件的行為開(kāi)發(fā)接口。
類(lèi)圖很棒，因?yàn)樗鼈冊(cè)试S嵌入式開(kāi)發(fā)人員指定屬性、操作和類(lèi)之間的關(guān)系(模塊和組件也可以)。有幾件事我們應(yīng)該注意。首先，電機(jī)任務(wù)使用電機(jī)應(yīng)用程序、電機(jī)狀態(tài)機(jī)和電機(jī)驅(qū)動(dòng)器。這里沒(méi)有繼承關(guān)系。我們可以看到電機(jī)驅(qū)動(dòng)器有一個(gè)電機(jī)接口。motor應(yīng)用程序使用MotorError_t枚舉，但除此之外，組件是解耦的，不進(jìn)行交互。
接下來(lái)，我們定義了我們認(rèn)為的操作是什么，以及組件需要的功能或方法。例如，我們可以看到電機(jī)驅(qū)動(dòng)器有兩個(gè)功能：電機(jī)初始化和電機(jī)命令。電機(jī)命令采用電機(jī)消息類(lèi)型和所有信息來(lái)命令電機(jī)，這是通過(guò)電機(jī)接口(抽象層)完成的。
當(dāng)我們查看類(lèi)圖時(shí)，我們可以看到電機(jī)任務(wù)與底層組件進(jìn)行交互，并驅(qū)動(dòng)電機(jī)的最終行為。首先，信息通過(guò)MotorQ進(jìn)入電機(jī)任務(wù)；然后，電機(jī)任務(wù)運(yùn)行電機(jī)狀態(tài)機(jī)。最后，電機(jī)任務(wù)調(diào)用電機(jī)應(yīng)用程序查找錯(cuò)誤，并使用狀態(tài)結(jié)果通過(guò)電機(jī)驅(qū)動(dòng)器命令電機(jī)。從一個(gè)可能并不明顯的類(lèi)圖中可以得出很多東西。那么，我們的架構(gòu)是否遺漏了什么？
我們的設(shè)計(jì)缺少了什么？
我們可能有足夠的資源來(lái)開(kāi)始實(shí)現(xiàn)電機(jī)應(yīng)用程序代碼；然而，更多的圖表和時(shí)間可以極大地提高清晰度。例如，嵌入式開(kāi)發(fā)人員可以考慮額外的UML圖，比如序列圖，來(lái)顯示控制任務(wù)與電機(jī)任務(wù)交互的時(shí)序要求。或是創(chuàng)建一個(gè)序列圖，以便開(kāi)發(fā)人員了解電機(jī)任務(wù)如何與其他組件交互。比如電機(jī)任務(wù)是應(yīng)該在任務(wù)結(jié)束的時(shí)候命令電機(jī)，還是先做，把抖動(dòng)降到最低？如果出現(xiàn)錯(cuò)誤，處理的邏輯是什么？電機(jī)應(yīng)該保持運(yùn)轉(zhuǎn)還是停止運(yùn)轉(zhuǎn)？
你通常會(huì)發(fā)現(xiàn)，你至少需要三到四個(gè)UML圖來(lái)完整地指定一項(xiàng)任務(wù)，以便開(kāi)發(fā)人員可以對(duì)其進(jìn)行編碼。我們只看了幾個(gè)，這意味著還有更多的事情要做。我們可以開(kāi)始開(kāi)發(fā)測(cè)試，并使用測(cè)試驅(qū)動(dòng)的開(kāi)發(fā)來(lái)進(jìn)一步發(fā)展我們的界面和對(duì)系統(tǒng)的理解。這可能是目前的發(fā)展方向。但是，我們知道的足夠多，隨著我們實(shí)現(xiàn)細(xì)節(jié)，問(wèn)題將會(huì)出現(xiàn)，這將推動(dòng)對(duì)初始架構(gòu)的更改。
軟件架構(gòu)設(shè)計(jì)第4步結(jié)論
正如本文所見(jiàn)，我們可以利用UML圖和組件堆疊圖來(lái)識(shí)別組件并定義它們的接口。此外，類(lèi)圖可以成為設(shè)計(jì)師進(jìn)行界面設(shè)計(jì)的優(yōu)秀工具。嵌入式開(kāi)發(fā)人員必須記住，雖然我們遵循一個(gè)簡(jiǎn)單的五步過(guò)程來(lái)開(kāi)發(fā)我們的架構(gòu)，但這些步驟只是一個(gè)指南，而不是全部。作為架構(gòu)師，我們經(jīng)常需要更深入。
