Re: [問題] 怎樣的class diagram才算好呢？

看板CSSE (電腦科學及軟體工程)作者reader (讀者)時間13年前 (2011/08/20 11:57)推噓1(1推 0噓 0→)

留言1則, 1人參與討論串2/3 (看更多)

※ 引述《yungshiang (加油)》之銘言： : 我想請教一下，怎樣的class diagram才算好呢 : 比如： : 一個類別有沒有研究內含多少屬性與操作是最好的 : 或者類別的數量與類別間各種關係的比例有沒有一定準則 : 或者類別、屬性、操作、關係，應依照時間怎樣的成長才算好的 : 或者其他........... : 有人想過嗎？或者有相關研究？ : 懇請賜教，感謝由於個人的讀書習慣不良，所以只能提供一點印象派的訊息。記得在 2000 年前後，就有一些相關研究，像是以 Java 類別庫原始碼做統計，不過談不上很有指導意義，應該仍然屬於學術上的嘗試而已。這主題在早期 OOP 的發展中，就有很多人想過了，只是歸納分析不易，大家能提出來的東西，以經驗性的抽象原則佔了多數。不過比較可以多說一點的地方是，這種統計或科學化的軟體工程研究和想法，其實是過去結構化程式設計時代的軟體工程研究的延續，泰勒式的軟體生產效率科學化研究，在 1980 年代是相當主流的學術方向。當時所謂的軟體工程，是真的把軟體開發，當成土木工程管理一樣的事情，儘量加以數據化、規則化，並已開始嘗試建立標準化作業規範了，特別是在歐洲，在這方面的進展不比美國差。但個人電腦產業的興起，把這些東西全部掃掉了。資訊產業的不斷革新，也就一次次地打破這樣的規範化嘗試，在以 web 為中心的網路程式設計興起之後，又讓 OOP 的規範化，只剩下少數人在做了。因此大部分的相關發展，都是在 1990 年代中期就已經建構出來的，此後都是比較小的改進或修正了。當然，更重要的概念進展，是通過工具化且有彈性的方法，以適應不同的需要，來取代過去那種不斷細化疊加的硬性規制，也更尊重開發者的創新能力和自主性，這種觀念上的轉變，也使得後來的軟體工程研究，愈來愈少計算數字，而主要變成一種不斷調整改進的過程。回到原題，軟體生產過程中的 "關注目標"（不管那是什麼）的過度簡化或繁化，都不適合實際作業。此外在生產過程不同階段工作的平衡性，也是增進分工效率的主要方法，相關的學術研究，則主要是經過統計和設計，以得到切合最多數工作者現況的生產規範。於是可以說，人性就是最重要的準則，對中小型團隊來說，溝通協調還是最關鍵的，與其依賴理論性的規則，不如好好去關心開發過程中，每個人的感覺和評析。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 218.174.32.211