：建模、繪圖與交互架構(gòu))
簡介基于Qt開發(fā)的故障樹分析FTA工具帶畫圖功能面向系統(tǒng)安全工程師、可靠性分析人員以及Qt圖形界面開發(fā)者。通過QGraphicsView/QGraphicsScene實現(xiàn)節(jié)點、邏輯門與連線的可視化編輯用戶可自由添加事件、AND/OR/NOT邏輯門與轉(zhuǎn)移箭頭支持鼠標(biāo)點擊、拖拽、縮放等交互操作并內(nèi)置布爾邏輯計算與自動布局思路適合輔助風(fēng)險評估與故障模式分析。壓縮包共14個文件核心代碼以5個cpp、4個h為主含2個ui界面文件、1個qmake工程文件及1個pro.user整體僅25KB結(jié)構(gòu)輕量便于直接查看源碼與二次開發(fā)。已有796人學(xué)習(xí)下載可作為Qt圖形編程與故障樹建模結(jié)合的入門參考幫助快速理解QGraphicsItem自定義、交互操作、數(shù)據(jù)結(jié)構(gòu)設(shè)計等關(guān)鍵實現(xiàn)。1. 故障樹工具的需求邊界不是畫個樹那么簡單做Qt上位機開發(fā)的人很多都接到過類似需求把故障樹分析FTA做成帶畫圖功能的軟件。乍一看這不就是畫個樹形結(jié)構(gòu)嗎真動手才發(fā)現(xiàn)故障樹畫圖跟普通思維導(dǎo)圖完全不是一回事它自帶一套邏輯語義——頂事件在最上方中間事件往下展開底事件作為葉子節(jié)點中間用與門、或門等邏輯門連接。圖形只是表達層真正值錢的是背后那套可剪裁、可計算的故障邏輯。我最早接手這類項目時犯過一個典型錯誤上來就掄起QPainter在QWidget上paintEvent里畫矩形、畫線。畫到第三層節(jié)點時已經(jīng)暈頭轉(zhuǎn)向拖拽、選中、連線更新全靠自己算坐標(biāo)代碼越寫越像一鍋粥。后來翻車幾次才想明白——帶畫圖功能的故障樹工具本質(zhì)是一個圖形化編輯器不是繪圖Demo。你需要的不是一個會畫線的Widget而是一套具備場景管理、圖元交互、視圖縮放的架構(gòu)。所以這篇就圍繞“Qt 故障樹 畫圖功能”這個組合把整個項目的核心設(shè)計思路拆開講。文章不是給你一段能直接復(fù)制粘貼的完整代碼而是把架構(gòu)決策、數(shù)據(jù)建模、繪圖交互、持久化方案這些關(guān)鍵點講透你照著這個思路去搭自己的工具會少踩很多坑。適合正在做設(shè)備故障診斷系統(tǒng)、可靠性分析軟件、或者單純想用Qt實現(xiàn)圖形化編輯器的開發(fā)者?？赡苡腥藭枮槭裁床挥矛F(xiàn)成的圖形庫比如Graphviz、YFiles這些。它們畫靜態(tài)樹確實強但故障樹分析工具往往要支持交互式編輯、節(jié)點拖拽、邏輯門配置、故障概率輸入、最小割集計算這些動態(tài)操作第三方庫一旦封裝太死你就要費勁去擴展它的數(shù)據(jù)結(jié)構(gòu)。用Qt自帶的圖形視圖框架Graphics View Framework自己搭反而可控性最強——這玩意兒就是為“場景-圖元-視圖”這種模式設(shè)計的天然適合故障樹這種節(jié)點連線的東西。2. 先建模再畫圖數(shù)據(jù)層設(shè)計的順序不能反很多人在做這類工具時容易犯的毛病是一上來就定義“怎么畫”而不是“畫什么”。對故障樹來說畫什么是指一套穩(wěn)定的數(shù)據(jù)結(jié)構(gòu)。這一步想清楚了后面的繪圖、交互、計算全部順?biāo)浦圻@一步偷懶后期每加一個功能都要重構(gòu)。2.1 節(jié)點類型與邏輯門的抽象方式故障樹里一共有三類基本元素事件頂事件、中間事件、底事件、邏輯門與門、或門復(fù)雜場景還有表決門、優(yōu)先與門等、連接線從一個事件連到邏輯門或從邏輯門連到下一層事件。我的做法是定義一個統(tǒng)一的數(shù)據(jù)結(jié)構(gòu)讓三類元素在同一個模型里流轉(zhuǎn)struct FaultTreeNode { QString id; // 全局唯一ID后續(xù)計算、連線全靠它 QString name; // 顯示名稱比如“電機過熱” QString description; // 詳細描述懸停提示用 NodeType type; // 事件類型Top/Middle/Basic GateType gate; // 邏輯門類型AND/OR/None double probability; // 底事件故障概率用于定量分析 QStringList children; // 子節(jié)點ID列表 bool isNegated; // 是否帶“非”邏輯有些行業(yè)需要 QPointF scenePos; // 圖形位置存儲場景坐標(biāo) };這里有個關(guān)鍵設(shè)計children存的是ID列表不是子對象指針。道理很簡單——故障樹有重父現(xiàn)象同一個底事件可能作為多個中間事件的條件出現(xiàn)如果用對象指針同一個底事件會被多個父節(jié)點持有序列化和比較時非常麻煩。用ID引用所有節(jié)點都放在一個QHash里指向關(guān)系一清二楚。2.2 為什么先定模型再做界面我見過不少項目是先畫界面然后發(fā)現(xiàn)邏輯計算和圖形重繪需要的字段對不上只能來回改結(jié)構(gòu)體。模型驅(qū)動的意思是數(shù)據(jù)模型是唯一的真相源Single Source of Truth圖形只是它的投影。界面上的拖拽、連線本質(zhì)上都是修改這套數(shù)據(jù)模型再讓視圖刷新。舉個例子當(dāng)你從“故障樹”面板里拖一個底事件到畫布上程序做的事情是在QHash里new一個FaultTreeNode分配唯一ID創(chuàng)建一個對應(yīng)圖元對象綁定這個ID圖元顯示位置從鼠標(biāo)坐標(biāo)轉(zhuǎn)換到場景坐標(biāo)后續(xù)改節(jié)點屬性直接改數(shù)據(jù)模型圖元通過信號槽自動更新如果跳過第1步直接畫圖后面做最小割集計算、故障概率傳播時你根本找不到“圖形”對應(yīng)的“邏輯對象”整個工具就廢了。順序永遠是數(shù)據(jù) → 圖形投影 → 交互寫回數(shù)據(jù)。3. 基于QGraphicsView的圖元體系搭建Qt的圖形視圖框架由三個核心類組成QGraphicsScene場景管理所有圖元、QGraphicsItem圖元場景里的每個對象、QGraphicsView視口負責(zé)渲染和交互。故障樹畫圖功能的核心就是圍繞這套框架定制自己的圖元類。3.1 事件圖元、邏輯門圖元與連線圖元的設(shè)計我把圖元分成兩大族節(jié)點圖元繼承QGraphicsItem負責(zé)畫事件框或邏輯門符號連線圖元繼承QGraphicsPathItem負責(zé)畫父子節(jié)點的連接線事件圖元我用一個類搞定但通過枚舉區(qū)分造型。頂事件和中間事件畫矩形底事件畫圓形行業(yè)慣例是底事件用圓形邏輯門畫特殊形狀——與門畫半圓弧平底像大寫字母D的輪廓或門畫一條波浪弧線進門。這樣從視覺上一眼就能看出邏輯關(guān)系符合可靠性工程師的使用習(xí)慣。class FaultTreeItem : public QGraphicsObject { Q_OBJECT public: FaultTreeItem(const QString nodeId, FaultTreeNode *data); QRectF boundingRect() const override; void paint(QPainter *painter, const QStyleOptionGraphicsItem *option, QWidget *widget) override; protected: void mousePressEvent(QGraphicsSceneMouseEvent *event) override; void mouseMoveEvent(QGraphicsSceneMouseEvent *event) override; void mouseReleaseEvent(QGraphicsSceneMouseEvent *event) override; private: QString m_nodeId; FaultTreeNode *m_data; bool m_dragging false; };連線圖元單獨出來的原因很簡單它需要隨端點位置變化實時刷新路徑。節(jié)點拖走連線要跟著走刪除節(jié)點連線要自動刪掉。如果把連線邏輯寫死在節(jié)點paint里每次移動都要遍歷所有子節(jié)點重算性能撐不住。3.2 坐標(biāo)系統(tǒng)與圖層劃分的底層邏輯Graphics View的坐標(biāo)系統(tǒng)是很多新手崩潰的重災(zāi)區(qū)。這里有三個坐標(biāo)系場景坐標(biāo)系、視圖坐標(biāo)系、圖元坐標(biāo)系。鼠標(biāo)事件拿到的坐標(biāo)通常先轉(zhuǎn)成場景坐標(biāo)再判斷落在哪個圖元上。一個實用的做法是所有圖元的數(shù)據(jù)位置比如scenePos全部存場景坐標(biāo)渲染邏輯也以場景坐標(biāo)為基準(zhǔn)。當(dāng)你縮放視圖時QGraphicsView的transform會自動處理縮放你不需要自己乘系數(shù)。這里有個關(guān)鍵點要記住不要在paint里依賴視圖的縮放比例去調(diào)整繪制尺寸否則會出現(xiàn)文字被拉伸變形的怪問題。圖層劃分我也踩過坑。故障樹場景里至少要分三層底層畫網(wǎng)格點可選輔助對齊中層畫連線頂層畫節(jié)點圖元如果不分層節(jié)點移動到連線上面時連線會穿過文本框視覺上非常亂用戶也容易誤點。我用一個簡單的做法給圖元設(shè)置Z值——連線Z值為0節(jié)點Z值為10再開QGraphicsItem::ItemIsFocusable讓節(jié)點始終能接收鼠標(biāo)事件。這就避免了手工維護“誰在上面誰在下面”的麻煩。4. 連線、拖拽與坐標(biāo)換算交互層最容易出錯的三件事如果說數(shù)據(jù)建模決定了工具能不能用那交互層就決定了工具好不好用。故障樹的交互動作主要就三個拖拽移動節(jié)點、畫連線建立邏輯關(guān)系、縮放平移畫布。這三件事每個都有它自己的坑。4.1 拖拽節(jié)點時連線要“活”起來節(jié)點拖拽的第一個坑是QGraphicsItem默認的拖拽行為不通知其他圖元。你移動了一個事件圖元父節(jié)點到它的連線、它到子邏輯門的連線全都還留在原地整個樹被扯斷。解決辦法是把拖拽處理寫在節(jié)點的mouseMoveEvent里每次移動都發(fā)射信號通知關(guān)聯(lián)的連線更新路徑。做成型后的代碼大致是這個思路void FaultTreeItem::mouseMoveEvent(QGraphicsSceneMouseEvent *event) { if (!m_dragging) return; // 移動圖元 setPos(mapToParent(event-pos() - m_dragOffset)); // 通知相關(guān)連線刷新 emit itemMoved(m_nodeId, scenePos()); QGraphicsObject::mouseMoveEvent(event); }而連線圖元監(jiān)聽信號后把起點終點坐標(biāo)重新讀一遍調(diào)用setPath(QPainterPath)更新軌跡。實測下來這個方案在節(jié)點數(shù)量幾百個的規(guī)模下依然流暢完全夠用。另一個小細節(jié)拖拽過程中要把圖元設(shè)為不透明甚至半透明否則節(jié)點移動時頻繁重繪畫面會閃爍。我用setOpacity(0.85)效果就很好。4.2 連線怎么畫才能表達“邏輯門到事件”的層次故障樹的連線有兩種事件 → 邏輯門表示“該事件作為門的輸入”邏輯門 → 事件表示“門的輸出是下一層事件”在畫線上我推薦折線直角連接不用弧線。原因很實際故障樹節(jié)點多、層次深弧線交叉時極難看清誰是誰的父級直角折線加“從上到下、從左到右”的布線規(guī)則視覺上干凈邏輯上清晰。具體實現(xiàn)時連線的起點和終點坐標(biāo)要經(jīng)過換算起點取圖元底部中心點終點取子圖元頂部中心點。路徑則是一個Z字形QPointF from parentItem-getOutputPort(); // 底部中心 QPointF to childItem-getInputPort(); // 頂部中心 QPainterPath path; path.moveTo(from); qreal midY (from.y() to.y()) / 2; path.lineTo(QPointF(from.x(), midY)); path.lineTo(QPointF(to.x(), midY)); path.lineTo(to);這套布線邏輯看起來簡單但能避免90%的連線交叉問題。真要處理多條線交叉的復(fù)雜布局那是另一個大話題可以先不做。4.3 鼠標(biāo)坐標(biāo)、場景坐標(biāo)、圖元坐標(biāo)的三層換算交互層最讓人頭疼的就是坐標(biāo)換算。雙擊場景空白處新建節(jié)點、右鍵刪除節(jié)點、拖放外部節(jié)點到畫布這些操作都涉及“鼠標(biāo)在視圖上的位置”和“場景中的位置”的轉(zhuǎn)換。這里有個最關(guān)鍵的APIview-mapToScene(event-pos())。鼠標(biāo)事件里拿到的是視圖坐標(biāo)必須通過這個函數(shù)轉(zhuǎn)換成場景坐標(biāo)然后才能用來setPos、判斷圖元位置。別自己手動去加減滾動條偏移量、縮放倍數(shù)——Graphics View框架已經(jīng)封裝好了手動算必然出錯。比如整個視圖縮小到50%時你在視圖坐標(biāo)(100, 50)點了一下實際場景坐標(biāo)可能是(200, 100)。如果直接用視圖坐標(biāo)創(chuàng)建圖元畫出來的東西位置完全不對。用了mapToScene之后這套轉(zhuǎn)換自動完成縮放平移都不怕。坐標(biāo)換算還有另一個隱蔽問題圖元內(nèi)部的局部坐標(biāo)。比如一個矩形圖元它的左上角位置是相對于圖元原點通常初始在(0,0)的。當(dāng)你處理圖元內(nèi)部細節(jié)時需要用mapFromScene把場景坐標(biāo)再映射成圖元局部坐標(biāo)。順序記牢視圖坐標(biāo) → 場景坐標(biāo) → 圖元局部坐標(biāo)。5. 文件持久化與擴展功能讓工具從能用到好用畫圖功能做完之后工具只是一個“能畫故障樹的畫板”。真正讓它變成分析工具還需要解決保存打開、數(shù)據(jù)校驗、以及一些錦上添花的功能。5.1 保存格式選JSON還是XML為什么我推薦JSON故障樹的工程文件需要保存兩部分信息數(shù)據(jù)模型節(jié)點、邏輯關(guān)系、概率值、ID和圖形信息每個節(jié)點的場景坐標(biāo)、視圖縮放級別。之前有人用XML但那個格式寫起來啰嗦解析也麻煩。我最后選了JSON。保存結(jié)構(gòu)大致長這樣{ version: 1.0, tree: { rootId: N001, nodes: [ { id: N001, name: 系統(tǒng)故障, type: Top, gate: None, pos: [200, 50] }, { id: N002, name: 電源模塊故障, type: Middle, gate: OR, pos: [200, 200] }, { id: N003, name: 保險絲熔斷, type: Basic, gate: None, probability: 0.001, pos: [100, 350] } ], links: [ { from: N001, to: N002 }, { from: N002, to: N003 } ] } }用QJsonDocument讀寫非常順暢而且這個格式人類可讀調(diào)試的時候肉眼就能看出結(jié)構(gòu)對不對。保存坐標(biāo)時直接存場景坐標(biāo)加載時直接用setPos不用再做二次換算。版本號字段一定要加后面數(shù)據(jù)結(jié)構(gòu)一改舊文件還能做兼容升級別省這一行。5.2 加載文件后的自動校驗與容錯文件加載不是簡單地把JSON塞進場景就完事。來自外部文件的數(shù)據(jù)你必須做一致性校驗否則一個壞文件能讓程序當(dāng)場崩潰。我自己吃過這個虧——有一次測試文件里有一個節(jié)點被手動改成了重復(fù)ID加載時QHash直接覆蓋整個樹關(guān)系錯亂。我總結(jié)了一個至少包含以下檢查項的校驗邏輯每個節(jié)點的ID必須唯一links里引用的from/to節(jié)點必須存在并且不能有環(huán)——故障樹是天然的有向無環(huán)圖一旦出現(xiàn)循環(huán)最小割集計算會死循環(huán)根節(jié)點頂事件必須只有一個所有節(jié)點的parent-child關(guān)系必須能構(gòu)成一棵完整的樹不能有多個斷開的“孤島”校驗失敗就彈個對話框讓用戶選擇“放棄修復(fù)”還是“自動修復(fù)”。自動修復(fù)的做法是斷開的節(jié)點保留在畫布左上角標(biāo)注為“未連接節(jié)點”連線引用了不存在節(jié)點的直接刪除并輸出日志。這套容錯機制對現(xiàn)場用戶來說太重要了因為他們的文件經(jīng)常被各種工具改來改去。5.3 畫布縮放、導(dǎo)出圖片、外部拖入這些“看起來簡單”的功能畫布縮放本身用view-scale()就能實現(xiàn)但要處理“以鼠標(biāo)位置為中心縮放”代碼就不那么直白了。常見做法是把鼠標(biāo)下的視圖坐標(biāo)先轉(zhuǎn)成場景坐標(biāo)縮放后再把場景坐標(biāo)映射回視圖坐標(biāo)調(diào)整滾動條偏移讓場景中的那個點保持在鼠標(biāo)位置。這個功能很多人不知道怎么做其實邏輯就一句話保住錨點不動。導(dǎo)出圖片功能用QGraphicsScene的render()可以直接渲染到QImage但有一個坑默認導(dǎo)出分辨率不高而且不會包含超過視口范圍的場景。需要先計算所有圖元的包圍盒scene-itemsBoundingRect()然后臨時設(shè)置輸出圖像大小和坐標(biāo)變換矩陣再render。這樣導(dǎo)出的圖片才是完整故障樹不是截圖。另外如果你希望用戶能從系統(tǒng)文件管理器直接拖入.faulttree文件到軟件中打開需要重寫QGraphicsView的dragEnterEvent和dropEvent在dropEvent里解析URL拿到文件路徑后調(diào)用加載函數(shù)。這個功能很實用——現(xiàn)場工程師經(jīng)常把文件丟在桌面上能拖進來打開會方便很多。實際上這類“畫圖功能”的擴展空間很大自動布局算法按層次從上到下排布、QChart畫故障率變化曲線、輸出Word格式的故障樹報告、樹形縮略圖導(dǎo)航……每一個都能讓工具從“能用”變成“好用”。我在實際項目中最先驗證的擴展是自動布局——把故障樹層次自動排成整齊的多層結(jié)構(gòu)。我自己的體會是畫布功能一定要留好接口再做擴展。比如我在圖元類里預(yù)留了一個updateVisual()接口所有視覺刷新邏輯都走它后面加自動布局時只需要寫一個算法計算每個節(jié)點的目標(biāo)位置然后調(diào)用所有圖元的updateVisual()就完事了不用改任何圖元繪制代碼。這個設(shè)計幫我省了不止一次返工。本文還有配套的精品資源點擊獲取 基于Qt的故障樹圖形化編輯器開發(fā)：建模、繪圖與交互架構(gòu)
簡介基于Qt開發(fā)的故障樹分析FTA工具帶畫圖功能面向系統(tǒng)安全工程師、可靠性分析人員以及Qt圖形界面開發(fā)者。通過QGraphicsView/QGraphicsScene實現(xiàn)節(jié)點、邏輯門與連線的可視化編輯用戶可自由添加事件、AND/OR/NOT邏輯門與轉(zhuǎn)移箭頭支持鼠標(biāo)點擊、拖拽、縮放等交互操作并內(nèi)置布爾邏輯計算與自動布局思路適合輔助風(fēng)險評估與故障模式分析。壓縮包共14個文件核心代碼以5個cpp、4個h為主含2個ui界面文件、1個qmake工程文件及1個pro.user整體僅25KB結(jié)構(gòu)輕量便于直接查看源碼與二次開發(fā)。已有796人學(xué)習(xí)下載可作為Qt圖形編程與故障樹建模結(jié)合的入門參考幫助快速理解QGraphicsItem自定義、交互操作、數(shù)據(jù)結(jié)構(gòu)設(shè)計等關(guān)鍵實現(xiàn)。1. 故障樹工具的需求邊界不是畫個樹那么簡單做Qt上位機開發(fā)的人很多都接到過類似需求把故障樹分析FTA做成帶畫圖功能的軟件。乍一看這不就是畫個樹形結(jié)構(gòu)嗎真動手才發(fā)現(xiàn)故障樹畫圖跟普通思維導(dǎo)圖完全不是一回事它自帶一套邏輯語義——頂事件在最上方中間事件往下展開底事件作為葉子節(jié)點中間用與門、或門等邏輯門連接。圖形只是表達層真正值錢的是背后那套可剪裁、可計算的故障邏輯。我最早接手這類項目時犯過一個典型錯誤上來就掄起QPainter在QWidget上paintEvent里畫矩形、畫線。畫到第三層節(jié)點時已經(jīng)暈頭轉(zhuǎn)向拖拽、選中、連線更新全靠自己算坐標(biāo)代碼越寫越像一鍋粥。后來翻車幾次才想明白——帶畫圖功能的故障樹工具本質(zhì)是一個圖形化編輯器不是繪圖Demo。你需要的不是一個會畫線的Widget而是一套具備場景管理、圖元交互、視圖縮放的架構(gòu)。所以這篇就圍繞“Qt 故障樹 畫圖功能”這個組合把整個項目的核心設(shè)計思路拆開講。文章不是給你一段能直接復(fù)制粘貼的完整代碼而是把架構(gòu)決策、數(shù)據(jù)建模、繪圖交互、持久化方案這些關(guān)鍵點講透你照著這個思路去搭自己的工具會少踩很多坑。適合正在做設(shè)備故障診斷系統(tǒng)、可靠性分析軟件、或者單純想用Qt實現(xiàn)圖形化編輯器的開發(fā)者?？赡苡腥藭枮槭裁床挥矛F(xiàn)成的圖形庫比如Graphviz、YFiles這些。它們畫靜態(tài)樹確實強但故障樹分析工具往往要支持交互式編輯、節(jié)點拖拽、邏輯門配置、故障概率輸入、最小割集計算這些動態(tài)操作第三方庫一旦封裝太死你就要費勁去擴展它的數(shù)據(jù)結(jié)構(gòu)。用Qt自帶的圖形視圖框架Graphics View Framework自己搭反而可控性最強——這玩意兒就是為“場景-圖元-視圖”這種模式設(shè)計的天然適合故障樹這種節(jié)點連線的東西。2. 先建模再畫圖數(shù)據(jù)層設(shè)計的順序不能反很多人在做這類工具時容易犯的毛病是一上來就定義“怎么畫”而不是“畫什么”。對故障樹來說畫什么是指一套穩(wěn)定的數(shù)據(jù)結(jié)構(gòu)。這一步想清楚了后面的繪圖、交互、計算全部順?biāo)浦圻@一步偷懶后期每加一個功能都要重構(gòu)。2.1 節(jié)點類型與邏輯門的抽象方式故障樹里一共有三類基本元素事件頂事件、中間事件、底事件、邏輯門與門、或門復(fù)雜場景還有表決門、優(yōu)先與門等、連接線從一個事件連到邏輯門或從邏輯門連到下一層事件。我的做法是定義一個統(tǒng)一的數(shù)據(jù)結(jié)構(gòu)讓三類元素在同一個模型里流轉(zhuǎn)struct FaultTreeNode { QString id; // 全局唯一ID后續(xù)計算、連線全靠它 QString name; // 顯示名稱比如“電機過熱” QString description; // 詳細描述懸停提示用 NodeType type; // 事件類型Top/Middle/Basic GateType gate; // 邏輯門類型AND/OR/None double probability; // 底事件故障概率用于定量分析 QStringList children; // 子節(jié)點ID列表 bool isNegated; // 是否帶“非”邏輯有些行業(yè)需要 QPointF scenePos; // 圖形位置存儲場景坐標(biāo) };這里有個關(guān)鍵設(shè)計children存的是ID列表不是子對象指針。道理很簡單——故障樹有重父現(xiàn)象同一個底事件可能作為多個中間事件的條件出現(xiàn)如果用對象指針同一個底事件會被多個父節(jié)點持有序列化和比較時非常麻煩。用ID引用所有節(jié)點都放在一個QHash里指向關(guān)系一清二楚。2.2 為什么先定模型再做界面我見過不少項目是先畫界面然后發(fā)現(xiàn)邏輯計算和圖形重繪需要的字段對不上只能來回改結(jié)構(gòu)體。模型驅(qū)動的意思是數(shù)據(jù)模型是唯一的真相源Single Source of Truth圖形只是它的投影。界面上的拖拽、連線本質(zhì)上都是修改這套數(shù)據(jù)模型再讓視圖刷新。舉個例子當(dāng)你從“故障樹”面板里拖一個底事件到畫布上程序做的事情是在QHash里new一個FaultTreeNode分配唯一ID創(chuàng)建一個對應(yīng)圖元對象綁定這個ID圖元顯示位置從鼠標(biāo)坐標(biāo)轉(zhuǎn)換到場景坐標(biāo)后續(xù)改節(jié)點屬性直接改數(shù)據(jù)模型圖元通過信號槽自動更新如果跳過第1步直接畫圖后面做最小割集計算、故障概率傳播時你根本找不到“圖形”對應(yīng)的“邏輯對象”整個工具就廢了。順序永遠是數(shù)據(jù) → 圖形投影 → 交互寫回數(shù)據(jù)。3. 基于QGraphicsView的圖元體系搭建Qt的圖形視圖框架由三個核心類組成QGraphicsScene場景管理所有圖元、QGraphicsItem圖元場景里的每個對象、QGraphicsView視口負責(zé)渲染和交互。故障樹畫圖功能的核心就是圍繞這套框架定制自己的圖元類。3.1 事件圖元、邏輯門圖元與連線圖元的設(shè)計我把圖元分成兩大族節(jié)點圖元繼承QGraphicsItem負責(zé)畫事件框或邏輯門符號連線圖元繼承QGraphicsPathItem負責(zé)畫父子節(jié)點的連接線事件圖元我用一個類搞定但通過枚舉區(qū)分造型。頂事件和中間事件畫矩形底事件畫圓形行業(yè)慣例是底事件用圓形邏輯門畫特殊形狀——與門畫半圓弧平底像大寫字母D的輪廓或門畫一條波浪弧線進門。這樣從視覺上一眼就能看出邏輯關(guān)系符合可靠性工程師的使用習(xí)慣。class FaultTreeItem : public QGraphicsObject { Q_OBJECT public: FaultTreeItem(const QString nodeId, FaultTreeNode *data); QRectF boundingRect() const override; void paint(QPainter *painter, const QStyleOptionGraphicsItem *option, QWidget *widget) override; protected: void mousePressEvent(QGraphicsSceneMouseEvent *event) override; void mouseMoveEvent(QGraphicsSceneMouseEvent *event) override; void mouseReleaseEvent(QGraphicsSceneMouseEvent *event) override; private: QString m_nodeId; FaultTreeNode *m_data; bool m_dragging false; };連線圖元單獨出來的原因很簡單它需要隨端點位置變化實時刷新路徑。節(jié)點拖走連線要跟著走刪除節(jié)點連線要自動刪掉。如果把連線邏輯寫死在節(jié)點paint里每次移動都要遍歷所有子節(jié)點重算性能撐不住。3.2 坐標(biāo)系統(tǒng)與圖層劃分的底層邏輯Graphics View的坐標(biāo)系統(tǒng)是很多新手崩潰的重災(zāi)區(qū)。這里有三個坐標(biāo)系場景坐標(biāo)系、視圖坐標(biāo)系、圖元坐標(biāo)系。鼠標(biāo)事件拿到的坐標(biāo)通常先轉(zhuǎn)成場景坐標(biāo)再判斷落在哪個圖元上。一個實用的做法是所有圖元的數(shù)據(jù)位置比如scenePos全部存場景坐標(biāo)渲染邏輯也以場景坐標(biāo)為基準(zhǔn)。當(dāng)你縮放視圖時QGraphicsView的transform會自動處理縮放你不需要自己乘系數(shù)。這里有個關(guān)鍵點要記住不要在paint里依賴視圖的縮放比例去調(diào)整繪制尺寸否則會出現(xiàn)文字被拉伸變形的怪問題。圖層劃分我也踩過坑。故障樹場景里至少要分三層底層畫網(wǎng)格點可選輔助對齊中層畫連線頂層畫節(jié)點圖元如果不分層節(jié)點移動到連線上面時連線會穿過文本框視覺上非常亂用戶也容易誤點。我用一個簡單的做法給圖元設(shè)置Z值——連線Z值為0節(jié)點Z值為10再開QGraphicsItem::ItemIsFocusable讓節(jié)點始終能接收鼠標(biāo)事件。這就避免了手工維護“誰在上面誰在下面”的麻煩。4. 連線、拖拽與坐標(biāo)換算交互層最容易出錯的三件事如果說數(shù)據(jù)建模決定了工具能不能用那交互層就決定了工具好不好用。故障樹的交互動作主要就三個拖拽移動節(jié)點、畫連線建立邏輯關(guān)系、縮放平移畫布。這三件事每個都有它自己的坑。4.1 拖拽節(jié)點時連線要“活”起來節(jié)點拖拽的第一個坑是QGraphicsItem默認的拖拽行為不通知其他圖元。你移動了一個事件圖元父節(jié)點到它的連線、它到子邏輯門的連線全都還留在原地整個樹被扯斷。解決辦法是把拖拽處理寫在節(jié)點的mouseMoveEvent里每次移動都發(fā)射信號通知關(guān)聯(lián)的連線更新路徑。做成型后的代碼大致是這個思路void FaultTreeItem::mouseMoveEvent(QGraphicsSceneMouseEvent *event) { if (!m_dragging) return; // 移動圖元 setPos(mapToParent(event-pos() - m_dragOffset)); // 通知相關(guān)連線刷新 emit itemMoved(m_nodeId, scenePos()); QGraphicsObject::mouseMoveEvent(event); }而連線圖元監(jiān)聽信號后把起點終點坐標(biāo)重新讀一遍調(diào)用setPath(QPainterPath)更新軌跡。實測下來這個方案在節(jié)點數(shù)量幾百個的規(guī)模下依然流暢完全夠用。另一個小細節(jié)拖拽過程中要把圖元設(shè)為不透明甚至半透明否則節(jié)點移動時頻繁重繪畫面會閃爍。我用setOpacity(0.85)效果就很好。4.2 連線怎么畫才能表達“邏輯門到事件”的層次故障樹的連線有兩種事件 → 邏輯門表示“該事件作為門的輸入”邏輯門 → 事件表示“門的輸出是下一層事件”在畫線上我推薦折線直角連接不用弧線。原因很實際故障樹節(jié)點多、層次深弧線交叉時極難看清誰是誰的父級直角折線加“從上到下、從左到右”的布線規(guī)則視覺上干凈邏輯上清晰。具體實現(xiàn)時連線的起點和終點坐標(biāo)要經(jīng)過換算起點取圖元底部中心點終點取子圖元頂部中心點。路徑則是一個Z字形QPointF from parentItem-getOutputPort(); // 底部中心 QPointF to childItem-getInputPort(); // 頂部中心 QPainterPath path; path.moveTo(from); qreal midY (from.y() to.y()) / 2; path.lineTo(QPointF(from.x(), midY)); path.lineTo(QPointF(to.x(), midY)); path.lineTo(to);這套布線邏輯看起來簡單但能避免90%的連線交叉問題。真要處理多條線交叉的復(fù)雜布局那是另一個大話題可以先不做。4.3 鼠標(biāo)坐標(biāo)、場景坐標(biāo)、圖元坐標(biāo)的三層換算交互層最讓人頭疼的就是坐標(biāo)換算。雙擊場景空白處新建節(jié)點、右鍵刪除節(jié)點、拖放外部節(jié)點到畫布這些操作都涉及“鼠標(biāo)在視圖上的位置”和“場景中的位置”的轉(zhuǎn)換。這里有個最關(guān)鍵的APIview-mapToScene(event-pos())。鼠標(biāo)事件里拿到的是視圖坐標(biāo)必須通過這個函數(shù)轉(zhuǎn)換成場景坐標(biāo)然后才能用來setPos、判斷圖元位置。別自己手動去加減滾動條偏移量、縮放倍數(shù)——Graphics View框架已經(jīng)封裝好了手動算必然出錯。比如整個視圖縮小到50%時你在視圖坐標(biāo)(100, 50)點了一下實際場景坐標(biāo)可能是(200, 100)。如果直接用視圖坐標(biāo)創(chuàng)建圖元畫出來的東西位置完全不對。用了mapToScene之后這套轉(zhuǎn)換自動完成縮放平移都不怕。坐標(biāo)換算還有另一個隱蔽問題圖元內(nèi)部的局部坐標(biāo)。比如一個矩形圖元它的左上角位置是相對于圖元原點通常初始在(0,0)的。當(dāng)你處理圖元內(nèi)部細節(jié)時需要用mapFromScene把場景坐標(biāo)再映射成圖元局部坐標(biāo)。順序記牢視圖坐標(biāo) → 場景坐標(biāo) → 圖元局部坐標(biāo)。5. 文件持久化與擴展功能讓工具從能用到好用畫圖功能做完之后工具只是一個“能畫故障樹的畫板”。真正讓它變成分析工具還需要解決保存打開、數(shù)據(jù)校驗、以及一些錦上添花的功能。5.1 保存格式選JSON還是XML為什么我推薦JSON故障樹的工程文件需要保存兩部分信息數(shù)據(jù)模型節(jié)點、邏輯關(guān)系、概率值、ID和圖形信息每個節(jié)點的場景坐標(biāo)、視圖縮放級別。之前有人用XML但那個格式寫起來啰嗦解析也麻煩。我最后選了JSON。保存結(jié)構(gòu)大致長這樣{ version: 1.0, tree: { rootId: N001, nodes: [ { id: N001, name: 系統(tǒng)故障, type: Top, gate: None, pos: [200, 50] }, { id: N002, name: 電源模塊故障, type: Middle, gate: OR, pos: [200, 200] }, { id: N003, name: 保險絲熔斷, type: Basic, gate: None, probability: 0.001, pos: [100, 350] } ], links: [ { from: N001, to: N002 }, { from: N002, to: N003 } ] } }用QJsonDocument讀寫非常順暢而且這個格式人類可讀調(diào)試的時候肉眼就能看出結(jié)構(gòu)對不對。保存坐標(biāo)時直接存場景坐標(biāo)加載時直接用setPos不用再做二次換算。版本號字段一定要加后面數(shù)據(jù)結(jié)構(gòu)一改舊文件還能做兼容升級別省這一行。5.2 加載文件后的自動校驗與容錯文件加載不是簡單地把JSON塞進場景就完事。來自外部文件的數(shù)據(jù)你必須做一致性校驗否則一個壞文件能讓程序當(dāng)場崩潰。我自己吃過這個虧——有一次測試文件里有一個節(jié)點被手動改成了重復(fù)ID加載時QHash直接覆蓋整個樹關(guān)系錯亂。我總結(jié)了一個至少包含以下檢查項的校驗邏輯每個節(jié)點的ID必須唯一links里引用的from/to節(jié)點必須存在并且不能有環(huán)——故障樹是天然的有向無環(huán)圖一旦出現(xiàn)循環(huán)最小割集計算會死循環(huán)根節(jié)點頂事件必須只有一個所有節(jié)點的parent-child關(guān)系必須能構(gòu)成一棵完整的樹不能有多個斷開的“孤島”校驗失敗就彈個對話框讓用戶選擇“放棄修復(fù)”還是“自動修復(fù)”。自動修復(fù)的做法是斷開的節(jié)點保留在畫布左上角標(biāo)注為“未連接節(jié)點”連線引用了不存在節(jié)點的直接刪除并輸出日志。這套容錯機制對現(xiàn)場用戶來說太重要了因為他們的文件經(jīng)常被各種工具改來改去。5.3 畫布縮放、導(dǎo)出圖片、外部拖入這些“看起來簡單”的功能畫布縮放本身用view-scale()就能實現(xiàn)但要處理“以鼠標(biāo)位置為中心縮放”代碼就不那么直白了。常見做法是把鼠標(biāo)下的視圖坐標(biāo)先轉(zhuǎn)成場景坐標(biāo)縮放后再把場景坐標(biāo)映射回視圖坐標(biāo)調(diào)整滾動條偏移讓場景中的那個點保持在鼠標(biāo)位置。這個功能很多人不知道怎么做其實邏輯就一句話保住錨點不動。導(dǎo)出圖片功能用QGraphicsScene的render()可以直接渲染到QImage但有一個坑默認導(dǎo)出分辨率不高而且不會包含超過視口范圍的場景。需要先計算所有圖元的包圍盒scene-itemsBoundingRect()然后臨時設(shè)置輸出圖像大小和坐標(biāo)變換矩陣再render。這樣導(dǎo)出的圖片才是完整故障樹不是截圖。另外如果你希望用戶能從系統(tǒng)文件管理器直接拖入.faulttree文件到軟件中打開需要重寫QGraphicsView的dragEnterEvent和dropEvent在dropEvent里解析URL拿到文件路徑后調(diào)用加載函數(shù)。這個功能很實用——現(xiàn)場工程師經(jīng)常把文件丟在桌面上能拖進來打開會方便很多。實際上這類“畫圖功能”的擴展空間很大自動布局算法按層次從上到下排布、QChart畫故障率變化曲線、輸出Word格式的故障樹報告、樹形縮略圖導(dǎo)航……每一個都能讓工具從“能用”變成“好用”。我在實際項目中最先驗證的擴展是自動布局——把故障樹層次自動排成整齊的多層結(jié)構(gòu)。我自己的體會是畫布功能一定要留好接口再做擴展。比如我在圖元類里預(yù)留了一個updateVisual()接口所有視覺刷新邏輯都走它后面加自動布局時只需要寫一個算法計算每個節(jié)點的目標(biāo)位置然后調(diào)用所有圖元的updateVisual()就完事了不用改任何圖元繪制代碼。這個設(shè)計幫我省了不止一次返工。本文還有配套的精品資源點擊獲取