Re: [問題] 抽像化的過程
> ==>發信人: ji3g45j.bbs@ptt.cc (pig), 信區: programming
> ※ 引述《StubbornLin (Victor)》之銘言:
> : 而我現在寫程式如果想要能有很好的擴充性和重覆利用的能力
> : 就必須花很多時間去思考架構,我目前用的方式是慢慢增加功能
> : 慢慢調整各個組件,在整個過程中將架構做出來
> : 可是我發現這樣很沒效率,如果是按圖施工的話就不一樣
> : 速度非常快,但是一開始只想,然後再去做的話
> : 有時會在寫時才發現某些細節有問題...
> : 所以我在這裡想問,程式的架構到底該如何去想比較好
> : 先用一般的方式寫一次再來拆? 還是....
> : 不然要顧慮的東西太多,變成沒辦法專心在解決一個問題上
> : 所以很難構想...
> : 謝謝
> 我也在思考這個問題...我覺得如果能夠將抽象的軟體架構以圖形的方式來描述
> 將會使整個軟體系統運作的更好
做硬體電路的是先畫功能方塊圖, 再思考控制訊息與資料如何銜接.
就明顯有 data-flow , control-flow 兩種接線.
古早的程式是偏重如何處理資料(變數名稱)的處理次序流程圖, 因
圖解佔篇幅, 後來就是 pseudo-code 條列指令形式的 algorithm
表示法. Algorithm 只是小方塊的處理程序, 像零組件. 架構就涉
及大方塊間的流通與處理數量, 方塊間的前後上下關係.
軟體都被認為比硬體複雜, 就是因為一時理不出個清楚的功能模組
方塊, 有了方塊也不知如何實現(凝聚的功能需求不明, 算法也不
明), 通常是不知如何切割, 在何處切割. 切割出來的那一塊該如
何稱呼其功能, 以便能再利用. 如果弄清 藕斷絲連的藕合
(coupling) , 同體凝聚 (cohesion) 的意義特性就容易體會,
圖解表示的好處, 就是會很具體看得見. 如果很誠實的把關係畫出
來, 結果像是一團意大利大雜麵, 那就是切錯了.
在 UML 出來之前, 軟工做分析, 表達架構的方式都是畫 relation
graph 的圈圈泡泡圖.
======================
寫程式很像 "作文" , 先定段落會好寫得多, 如果是 "八股公文",
用 "格式填空" 就能自動產生. 印度的代工並非用一堆手工工匠來
做手工藝品, 而是用格式填表, 很像半定製型半自動化的生產線.
台灣的軟體工程失誤處是陷入 "企圖全自動化" , 硬體製造業的生
產線沒有被學術界重視, 所以一直是走半自動化的路線演變, 反而
VLSI 設計是講究自動化的. 軟體沒有切隔出重點, 未能區分出可為
與不可為的部份, 又被學術界論文發表所迷惑, 被拖往全面自動化
(不如此先進的掰, 如何是領先世界的論文 ?)
分析設計規劃的問題, 免不了策略性的選擇, 更免不了挑戰傳統的
突破 ! 凡事過猶不及, 恰到好處就是難 !
(不過, 事後諸葛容易, 但事後都仍弄不清楚為何敗陣就不好了)
--
◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 140.115.6.234
推
01/31 15:53, , 1F
01/31 15:53, 1F
推
01/31 15:53, , 2F
01/31 15:53, 2F
討論串 (同標題文章)
Programming 近期熱門文章
PTT數位生活區 即時熱門文章