居然跟老師爭論如何畫UML類圖，我覺得我的沒錯，請大神進來評評理，我該怎麼辦？

01-21

我是信息管理與信息系統專業，學的內容主要就是做項目管理之類的事，但編碼方面的課多而不精，大部分時間在學著寫！文！檔！寫需求分析，資料庫說明書，概要設計，詳細設計，畫各種類圖，ER圖，時序圖等等，
事情是這樣的，我們老師是教授，他出了本書，我們的課程內容就是按照他那本書的流程完成一個項目，但是當我們畫類圖的時候我看到這書上的東西我就蒙了，因為我之前自己寫項目的時候也畫過類圖，但是跟著完全不一樣，類圖的泛化，實現等關係，介面抽象類，方法返回值，某個類型竟然是void！我很不能理解，於是我讓我們小組就按我的想法寫了類圖交上去，被老師打下來了，說我們的類圖不對，要按他的寫，意思就是不按他的寫就過不了這一關，我也凌亂了，因為我在我們班算編程比較多的，其他人之前根本沒有了解過類圖，全班沒有一個人跟我一起反駁老師，最後我都不知道到底誰是對的了，文字下面就是類圖
我有兩個問題，首先，這個UML類圖真的是這樣嗎，類圖可以自定義的？
然後，我該怎麼辦？

你的老師這個顯然不對，把不同的概念全部混淆起來了。不過既然是作業，你管那麼多幹什麼，老師說怎麼畫就怎麼畫。

從你截圖來看，絕對不推薦這樣去畫類圖，而且完全沒有意義，如果你們老師書是這樣的話，這本書應該不及格。要學習UML就好好看UML官方用戶手冊和參考手冊，看RUP方面的書籍。

從你截圖來看最大的缺點就是以界面表單入手再考慮類圖，而實際上核心的類圖在設計的時候是不會立馬去考慮UI和表單的，而是真正搞清楚核心的業務對象是什麼? 如上圖，真正的核心業務對象是部門，員工，用戶，工資才是核心對象，要搞清楚有哪些核心對象，這些對象間是啥關係，然後再識別對象應該提供的方法。至於是在一個類裡面全部定義，還是要單獨出實體類和控制類是後面需要思考的事情。總之從UI入手再考慮類設計，就是最大的錯誤。

無所謂的。。。反正就是示意圖。。。

等你工作了，發現大家根本不畫所謂的「標準uml圖」，你就更凌亂了。。。

為什麼建模出來的全是表單？表單之間的依賴關係是什麼意思？有了這張圖接下來就可以寫代碼了嗎？

第一次見到全是表單的「類圖」，但這分明就不是類圖吧，我都能從裡面拆出來活動圖了。

說實話，之前我在做助教時候，這種作業我是不給過的，然後你老師就拿來出書了？

連個派生都沒有？圖就算畫對了，這oop也夠嗆吧

hhhhhhhhhhh，求書名，給大家瞻仰一下...

UML是有標準的。。。不存在什麼爭論不爭論，查一查就好了

2.x版本的class diagram標準如下

UML basics: The class diagram

題主你沒有貼上自己的class diagram，所以不好評價你的理解是什麼。

不過從你們老師的class diagram來看，有幾個奇怪的地方。

1. "&<&<" ">&>"中寫「表單」是幾個意思？

2. association全用虛線是幾個意思？

3. class name都是動詞是幾個意思？

你們老師的類圖格式是沒有錯的，class name下面是attribute，再下面是methods，即便沒有也要空出來。題主之前畫的是不是都沒有明細這兩項？

摘自維基百科「The individual classes are represented just with one compartment, but they often contain up to three compartments「

btw

寫文檔是很高大上的。。。這是區分code monkey和architect的指標之一。

你自己寫個小網站，聊天機器人可以沒有開發者文檔，class活著component diagram。

但是如果eclipse，M$ Word, GAE這種大型項目沒有文檔的話，你叫後來的新人怎麼活？把幾十萬行代碼從頭到尾都看一遍？

OMG（ Object Management Group 還是 Oh My God，隨你）去看規範啦。

UML 是 OMG 管理的規範，當前版本是 formal/15-03-01；

也是 ISO 正式發布的標準，ISO/IEC 19501, 19505。

拿 http://www.omg.org/spec/UML/ 去拍你們老師一臉就好。不過，拍之前，建議你先學習一下這個問題：給 59 分強行不給過的老師是一種怎麼樣的存在？ - 大學

uml 不是一種思想，而是一個具體的方法，所以沒有什麼爭論的必要，你老師畫的「類圖」是錯誤的，不是一個合格類圖。

uml 的類圖長什麼樣大家都知道的，就不需要啰嗦了。你老師自己寫了本書，大概是有自己的一套方法論，但是，就算假設你老師自己有創新，他畫的這也不是合格的類圖。類圖是什麼？類圖就是代碼，只要有合適的工具，類圖就應該可以編譯成具體實現為空的框架代碼。你老師這個圖連對象之間的關係都無法區分，有可能生成代碼嗎？

但是你跟你老師爭論是沒有意義的，以他的知識水平不可能不知道 uml 什麼樣，他既然不按照那個來，必然是認為他自己這一套比 uml 更牛逼。你跟他爭論的並不是知識本身，而是價值觀。

價值觀沒什麼好爭論的，就算他考你填空題「最優秀的編程語言是____」，你也只需要按照他的講授填寫 php 或者 java 即可。

借這個機會去看看 uml 教材，學學 uml 怎麼畫才是正經事。至於你老師的發明，借鑒一下思想就好，畢竟不是業界主流。

我覺得懷疑老師的行為是正確的。教科書上的程序一半是有錯誤的。不過在這件事情上，我覺得你錯了。

我沒有系統的學過uml的構圖，不過就你貼的圖，清晰地把邏輯結構流程描述清楚了，我不知道你覺得哪裡有問題。如果你用vs的設計模式看dataset，會發現微軟的圖形描述和教科書上有很多相似之處。

最重要一點，你掌握了老師的設計思想了沒有？從你的描述來看，因為違反了你的常識所以你首先是想要去反駁，這個是最不嚴謹的科學態度之一。

學院派和實戰派有衝突很正常，問題是學院派雖然有酸氣，不代表真的一無是處。

樓上這麼多支持老師的我也是醉了

UML的意義是什麼，是一個統一的標準，一個可以交流設計的通用語言。就好比大家都會點英語，不管你本來是哪國人，都能進行基本的交流一樣。

你自己牛逼哄哄的「發明」了一種新的語言，還硬要說這是通行的英語？

根本就不用費心去判斷老師的這種畫法到底好不好，直接負分滾粗！

以個人的經驗，這個書上的內容確實不是百分百的正確，但是建議不要試圖去反駁老師，可以在課下去溝通，把你做好的講給老師。相信他能聽懂你的意見的。課堂上反駁效果不理想，因為這些內容前後都是有聯繫的，隨意修改教材的一部分，會影響整體。但我相信老師發現問題後會想辦法更新他的教材。不一定所有的老師都對，尤其是IT知識的更新速度太快。

由「打算用UML表達啥？」決定：

老師的類圖確實是「類圖」（有點小問題），但他對學生的要求有問題
題主的想法也沒問題，不過沒必要和老師爭論

UML不是C++，它的表達方式更靈活。

怎麼表達，取決於所建模型的層次(Levels of Models)。（--&> OO三駕馬車，後文有文獻）

一、類圖

在UML應用於特定的軟體過程時（RUP），需求之後會存在兩個階段：「分析階段」 + 「設計階段」（詳見本文 2.1節）

分析階段有分析類，

下圖就是一個分析類：

圖1. 課程的類圖（來自：RUP 2000 中文版 - 工件：分析類）

這個類圖表達了「a nearly ideal picture of the system」[2]

所以，不能說題主老師給的類圖是完全錯誤的——它有可能是分析模型的一部分（苛刻一點，半吊子分析模型）。

當然，那個類圖中有一些錯誤：

1）日期時間屬性的類型是 void。void是C/C++的東西，分析模型不應與具體語言綁定

2）虛線實心三角箭頭。實心三角箭頭不符語法；虛線代表依賴，說明依賴類的某個方法的參數是被依賴類類型。[1]

3）作為Stereo Type的「表單」未加以說明，一些「表單」之間「依賴」有點奇怪

設計階段有設計類：

圖2. 設計類（來自http://www.aka.citf.net，2001）

題主提交的類圖應該是上圖的形式吧？

但是，UML怎麼表達一個目標系統，取決於所建模型的層次(Levels of Models)。

二、模型層次

UML在不同模型層次上有不同的表現。

2.1 分析階段與設計階段

【可跳過下述引文，看引文後總結】
The purpose of analysis is to transform the requirements of the system into a form that maps well to the software designer"s area of concern—that is, to a set of classes and subsystems. This transformation is driven by the use cases and is shaped further by the system"s nonfunctional requirements. Analysis focuses on ensuring that the system"s functional requirements are handled. For simplicity"s sake, it ignores many of the nonfunctional requirements of the system and also the constraints of the implementation environment. As a result, analysis expresses a nearly ideal picture of the system.
The purpose of design, on the other hand, is to adapt the results of analysis to the constraints imposed by nonfunctional requirements, the implementation environment, performance requirements, and so forth. Design is a refinement of analysis. It focuses on optimizing the system"s design while ensuring complete requirements coverage. [2]

「分析」要確保系統的功能性需求是否都被處理了，但是會忽略非功能性需求和實現環境的約束；

「設計」則要調整分析的結果，使之適應上述被忽略的東西，確保模型能夠覆蓋所有需求

簡言之，「分析」得到的「分析模型」不含或者少含與編程語言、具體資料庫等有關的東西；「設計」得到的「設計模型」則是與某種具體的編程語言相關的。

2.2 模型中細節的多寡應遵循的第一個原則

【可跳過下述引文，看引文後總結】
Guides to the thought process. [3]
High-level models built early in a project serve to focus the thought process of the stakeholders and highlight options. They capture requirements and represent a starting point toward a system design. The early models help the originators explore possible options before converging on a system concept. As design progresses, the early models are replaced by more accurate models. There is no need to preserve every twist and turn of the early exploratory process. Its purpose is to produce ideas. The final 「thinking models」 should be preserved even after the focus shifts to design issues, however. Early models do not require the detail or precision of an implementation model, and they do not require a full range of implementation concepts. Such models use a subset of UML constructs, a more limited subset than later design models.

模型的詳略應有助於引導建模的思考過程。

高層模型建於項目早期，捕獲需求呈現一個系統設計的起點。...... 隨著設計的進行，早期模型被更多更精確的模型替代。......早期模型不需要細節或者達到實現模型的精度。...... 這些模型使用了UML的子集。

換句話說，用中文寫的「類圖」也是類圖，如果作為早期模型，那麼不需要達到實現模型的精度。

所以，得出本答案的結論：

用UML，表達分析設計的思路要重於糾結語法的正確性。所以，少年，從了你老師吧。拿到分數以後，你該咋畫就咋畫。

參考文獻：

[1] Grady Booch, etc., The Unified Modeling Language User Guide, 1st Ed., 2001. para. 5.3.1

[2] Philippe Kruchten, The Rational Unified Process: An Introduction (3rd Ed.), Addison Wesley, 2003

[3] James Rumbaugh, etc., The Unified Moding Language Reference Manual, 1999. ch. 2

錄音，往院里和學校里投訴。按他的圖根本做不出來。

我覺得這不是類圖，而是界面系統的操作示意圖

個人角度來說，沒什麼不能接受的，UML本身就只是一種示意圖，能看懂就行。

啊咧、類是啥玩意兒來著？

類圖？？畫法錯了，這沒什麼，找個工具就是。問題是這是類？？？你們這位教授連oo編程的門都沒入。

從uml角度是正確的。一般大家都用名詞作為類名，這裡用了動詞一開始讓人疑惑，用動詞的話可能用的是設計模式裡面的command模式，但這裡肯定不是。仔細看一下上面有&<&<表單&>&>這樣的標記，表示每個類都是從表單這個原型繼承的，這樣的話每個類都表示一個windows窗口，比如「部門查詢窗體」、「員工信息輸入窗體」等等，每個窗口的界面元素和可以執行的操作也有了。這樣說你確實沒有理解老師的意思。

如果你已經拿到一個已經開發完成的系統，然後叫你畫出界面窗口之間的關係就是這樣的，但一般開發總是從分析業務模型開始的，大概大家也很少畫界面之間的關係圖，所以你看到這個圖會感到很奇怪，也可能跟你的實踐脫節，但希望你不要產生偏見，你老師在這點上沒錯。

首先的贊老師自己都出書了，不管對錯，我想你們老師一定是把自己多年做事方法以及經驗都寫在這本書了，你要仔細看並多與老師交流。

你敢發這個圖，我想你對如何畫UML類圖查了大量資料，還是不太認可他的類圖。

能實現結果的方法都是可以的，主要你畫著東西是讓大家看的。你們老師能用這個方法做出項目，應該是實踐過得，不過的得說是閉門造車。這張圖把業務需求，表單操作甚至數據安全的備份恢復都寫進去了，他是想讓人看什麼呢？簡直逆天的想把UML用一個類圖全表示完。

老師畢竟是老師多尊重，多跟他交流問問他如何去理解這個圖，你聽了他的理解。自己把信息分下類就好。