從設計觀念的釐清, 到設計方法的探尋, 以及利用各種設計方法來進行機械設計, 到底有沒有一套脈絡或論述可以依循?
設計到底是甚麼?
在工程領域, 設計應該是一種表達, 而且是能夠讓參與設計的所有團隊成員都充分了解, 且據以依循, 可以得到預期結果的具體表達.
工程設計常用的表達至少有口語、文字、2D、3D、數學與實體等六種方式.
例如: 利用 Leo Editor 管理 Pelican 靜態網誌系統的協同使用"設計", 文字表達敘述如下:
- 這是一套允許多人協同編寫位於 content 目錄下的 Markdown 檔案格式或 reStructuredText 格式文章原稿的系統
- 為了完整保留本網誌系統原稿與設定檔案的歷程資料, 採用 Github 或 Fossil SCM 進行內容組態管理
- 為了在組態管理歷程資料過程, 避免各學員的 Leo Editor 專案 XML 檔案, 因合併產生衝突處理上的困難, 規定各成員必須自行維護管理 users 目錄下, 以作者名稱命名的 .leo 檔案
- 為了讓 Pelican 所產生的 html 網誌系統, 可以同時在無網路連線的近端與雲端上使用, 近端利用 pelicanconf.py 加上 local_publishconf.py 轉檔, 遠端則使用 pelicanconf.py 加上 publishconf.py 轉檔
- Pelican 轉換完成的 html 檔案, 設定置於 blog 目錄中
- 由於 Pelican 轉換後的 html 位於 blog 子目錄, 因此整個系統根目錄中的 index.html 以 head 標註中的 meta redirect 跳轉至 blog 目錄中的 index.html
- 為了讓多人所建立的文章原稿, 同時存入 content 目錄而不會產生覆蓋, 規定以作者名稱加上底線, 再加上當天日期及副檔名命名
- 作者若同一天建立多篇文章原稿, 則以用戶名稱_日期-1.md 等 dash 後加上數字區別
- 因為 Pelican 針對沒有 slug 欄位設定的中文標題文章原稿, 會以拉丁拼音命名轉換後的 html 檔案, 比較不容易望文生義, 因此建議各文章以有意義的英文名稱命名, 且最前方加上作者名稱, 以避免因重複 slug 設定, 而讓 Pelican 無法轉檔
- 為了讓各用戶的 Leo Editor 文章節點中, 以 @edit 或 @clean 節點指令下的文章更容易查找, 建議在存檔節點的根節點, 以文章標題註記
- 有關 attila 樣板右方 menu 側欄中的連結增刪, 可以透過編輯 partials 目錄中的 navigation.html 達成
- 頁面正中方的搜尋表達, 以修改近端與雲端 templates 目錄中的 base.html 檔案中的 search section, 套入 search.html 達成
- 系統啟用 summary plugin 的目的, 在於讓 reStructuredText 格式文章原稿可以透過標註, 區隔摘要與內文
- 系統啟用 neighbors plugin 的目的, 在於讓各篇文章末端出現前後文章的連結, 以方便循序瀏覽閱讀
- 系統啟用 tipuesearch plugin 的目的, 在於讓使用者可以透過兩個字元以上的關鍵字進行全文搜尋
- 為了讓 Pelican 轉換完成的 html 檔案, 可以採 tipuesearch Javascript 延伸功能, 以關鍵字搜尋, 近端關鍵字以 tipuesearch_content.js 儲存, 遠端則使用 tipuesearch_content.json 儲存, 詳細內容可參見 plugin 目錄中, tipue_search 子目錄中的 tipue_search.py 設定
- 上述之所以在轉檔階段需要區分近端與雲端的原因, 在於近端無 disqus 設定, 而遠端則附加 disqus 回應系統
- 為了讓近端與遠端瀏覽器中各 AJAX 前後端程式系統的反應一致, 近端利用 www-server 按鈕, 以執行緒啟動 https 伺服器, 使用者可以在轉檔完成後, 以瀏覽器 IPv4 網路協定檢查內容
- 為了讓系統在 IPv6 網路協定下正常運作, 以 ipv6-https-server 按鈕, 以執行緒啟動 https 伺服器, 使用者可以在轉檔完成後 ,以瀏覽器 IPv6 網路協定檢查內容
當然, 本網誌系統的完整原始資料都保存在 Pyslvs 倉儲, 任何人只要 git clone 倉儲, 稍加修改, 就可以另起爐灶, 延續這個網誌系統的價值, 但是其中許多細微精密的設計, 若沒有完整表達, 一旦爾後使用環境改變或各相關系統改版, 使用者就無法充分掌握各開放系統的互動搭配, 獨力配置因應.
換言之, 工程領域中與所謂設計相關的具體表達, 至少是時間與所處環境的函數, 一旦時空轉變, 就必須透過完整的歷程組態管理紀錄, 啟動各互動元件間的配置修改, 方能延續或加值原始設計的表達, 得到預期結果.
設計方法
假如我們接受在工程領域中, 上述所謂設計是一種表達的陳述, 那麼在表達設計的歷程中, 將存在許多解決問題的方法, 與所處時空背景的說明.
首先, 甚麼是方法? "方"為合乎約制條件, 可以實際拿出來使用的策略與規則, 表示並非空想, 而可實際施行的內容, 才叫"方". 至於"法"是順應自然條件下, 可因時空而制宜的最高行事準則. 因此"方法"就是: 配合不同條件, 實際施行的最高準則.
而再從上述設計有六種表達方式的論述出發, 那麼以口語表達而言的設計方法, 就是:
配合不同條件, 實際施行口語表達的最高準則. 也就是因應環境與對象, 將設計內容, 說清楚講明白所採行的策略與準則.
因此, 所謂設計方法, 除了口語表達外, 還可以從文字、2D、3D、數學與實體等表達的形式, 加以發揮, 具體呈現設計內容.
由於設計方法以各種形式表達的過程中, 會因時空背景與參與人員所做決策的差異, 而產生不同的結果, 多人協同團隊為了更有效掌握過程中的各項細節, 因此設計方法及組成元件有關的組態管理系統 (Configuration Management) 因應而生.
機械設計
機械是一種器物, 而且是由固體、流體與軟體元件精巧組合而成, 可互動運作, 達成特定功能之器物. 因此機械設計就是靈活運用六種表達方式, 明確說明如何透過固體、流體與軟體元件之互動運作, 而能達成預定結果之明確與具體表達.
Pyslvs 是機械設計過程中的一項工具, 主要由平面機構模擬核心、演化運算核心與視窗圖形化介面程式所組成. 其中, 兩種運算核心都依據平面機構有關的數學模型與分析表達, 採用軟體元件製作, 再結合 2D 使用者圖形介面建立物件導向, 以及事件驅動程式元件等功能, 讓使用者可以輸入平面機構模型後, 進行模擬或合成運算.
而 Pyslvs 平面機構模擬核心的主體為一套 Geometric Constrain Solver, 依附在 Solvespace 參數化 3D 繪圖套件中. 在 2013 年 9 月透過 SWIG (Simplified Wrapper and Interface Generator) 技術, 轉為 Python2 可呼叫的程式庫, 為 Python2-Solvespace. 2016 年 7 月之後, 經本站轉為 Python3 可呼叫的程式庫, 成為 Python3-Solvespace.
至於 Pyslvs 平面機構合成所使用的演化運算核心 ,則源自 2015 年 4 月利用 Cython (C-extension for Python) 技術所開發的 Algorithm, 包含實數編碼基因 (Real-coded Genetic) 演算法、差分進化 (Differential Evolution) 演算法與螢火蟲 (Firefly) 演算法等模組.