面向對象的分析與設計，難點不在于分析，而在于設計，因此需要正確把握兩項工作之間的工具和銜接方法。通過本篇文章，能讓你更加細致的了解面向對象的分析與設計，希望能對你有所幫助。

今天這篇是軟考——系統分析師的第二篇推文。

去年7月豆芽君寫過這篇文章《產品設計之從業務到產品》。

這次備考過程，我對面向對象有些補充理解，今天寫的內容，會部分推翻之前的內容。但如果你能兩篇文章對照著看，相信你可以對比、了解下結構化分析與設計 VS 面向對象分析與設計。

面向對象技術出現在1980年左右，比豆芽君出生的還早?？赡壳按蠖鄶档?B產品分析與設計，都是行面向對象之名，行結構化之事。

這里面的原因豆芽君認為主要是兩類人造成的：

1）開發人員

開發語言的發展是先有結構化語言C語言等，后面才出現了面向對象語言JAVA等。

所以早期的開發人員，雖然現在在用面向對象的語言，但仍然習慣使用結構化設計、開發的思路。

2）系統分析師/產品經理

說實話，很多產品經理都不是計算機專業科班出身，他們可以做好需求調研、原型設計等表層的工作，但基本上無法去做系統設計這類里層的工作。

這些工作最終還是回到了負責開發管理的開發經理的身上。這群人的問題也就是第一點提到的。

先拋結論：面向對象的分析與設計，難點不在于分析，而在于設計。

今天我們主要講這兩項工作用到的工具？以及如何做好這兩者的工作銜接？

相信你認真看完今天的內容對常見的UML工具不再陌生，也能更好地理解分析與設計的工作如何銜接？這可以讓系統分析師/產品經理與開發經理更好地分工與協作。

一、面向對象的分析

先看下教材上的一段定義：面向對象的分析是解決【做什么】的問題，找出描述問題域和系統功能所需的類和對象，定義它們的屬性和職責，以及它們之間形成的關系。

面向對象分析獨立于具體實現，不考慮與系統具體實現有關的因素。

看起來可能有點燒腦。別急，我會逐一跟你娓娓道來這段話在講啥？

PS : 說實話，如果這段話看不下書去，大學計科的書更看不下去。這樣你就大概知道我們的多數教材有多么勸退人了。

面向對象分析也是基于需求調研進行分析，只是它采用的方法是對現實世界客觀存在的對象進行分析。

舉個例子：銀行客戶去ATM機取款，我們分析出來的對象有銀行客戶、ATM機等。這種分析方法，采用的是需求單位習慣的方式，大家更容易同頻溝通。

在需求分析階段，主要用到UML工具，包括用例圖、類圖（概念類）、時序圖等。

我們來串講下這些工具如何搭配使用，效果更佳？

1. 用例圖

用于以分析對象為維度，去找出它希望在系統里能做什么？還以前面的取款為例，銀行客戶的用例活動包括：登錄、查詢余額、取款等。這里每一個用例活動，都是用戶們耳熟能詳的內容。

關于用例圖更詳細的內容，可見前面推文。

2. 類圖（概念類）

之前的文章，我們當時提到產品經理不要參與類的設計，這個可能誤導實際開發的人。

但實際上類還分為概念類、設計類、實現類，為了向后面的開發環節傳遞你的分析、設計的思想，產品經理們還是有必要再往前走一、兩步。

每個用例圖對應一個概念類圖。概念類圖通過屬性和方法進一步描述它的信息和行為。

以取款這個事件為例，概念類圖示例如下：

先分析出概念類有銀行客戶、銀行卡、ATM機、憑條等（如何分析？這里提供一個簡單辦法，先從用例圖表的文字描述找出名詞和名詞短語，再分析它是不是一個獨立的對象）。

再以銀行客戶這個概念類為例，我們分析出它的屬性含：姓名、性別、身份證號、銀行卡號等；方法含：插入銀行卡、退出銀行卡。

看到這里，豆芽君希望你停下來思考下，概念類圖與ER圖有什么區別？

思考一分鐘后，再往下看。

如果你看過之前的推文，豆芽君在用例圖后是講了ER圖，這是一種結構化分析的方法。ER圖就是我們上一篇講到的數據流程圖的進一步細化，它同樣只保留了數據有關的內容。

而面向對象分析采用的概念類圖，它相對來說更加具象、易理解。從上面取款的事件的概念類圖，我們看到的信息有業務領域的具體對象（銀行客戶、ATM機等），對象間的關系（如銀行客戶和ATM機維修人員都是ATM機使用者），對象所含的信息和能執行的行為。

類圖比ER圖提供了更豐富的信息。類圖同時呈現信息與行為，而ER圖只能呈現數據信息，無法體現行為。

3）時序圖

前面講到的類圖是一種靜態模型圖，無法反映對象間的交互過程，而時序圖等動態模型可以補充說明消息傳遞的次序。

這就像我們做菜時，除了需要有食材、調味料，還得知道每樣食材的蒸煮炒炸的順序，最終才可能做出一道美味的佳肴。時序圖的具體內容，在去年7月的推文已講到，不再贅述。

注意：很多2B產品經理是跳過了類圖/ER圖的分析環節，直接進入了原型圖設計。這樣其實只解決了前端開發的設計問題，而對后端開發沒有起到實質性的指導作用。這也會給后端開發人員帶來二次的分析與設計工作。

到了這里，我們講完面向對象分析的主要工作與工具。我們一起來稍微做下總結：面向對象區別于結構化的特點是，它以業務領域的對象為調研對象，更容易與需求方討論需求；在分析階段依然保持以領域對象為分析對象，分析對象與調研對象可對應。

相比之下，結構化分析一味強調數據與數據流，這種產出物一般只有IT同行可理解，難以與需求單位溝通。

二、面向對象的設計

前面講完面向對象的分析，接下來我們繼續講講面向對象的設計。

同樣先看教材的一段定義：系統設計解決【怎么做】的問題，又稱為物理設計階段。

根據系統規格說明書規定的功能要求，考慮實際條件，具體設計實現邏輯的技術方案，為下一步系統開發工作做準備。

從這段對系統設計階段的目標描述，我們可以看出分析與設計應該是相互緊密銜接的。接下來，我們要講的重點也將放在兩者的銜接上。

先說說設計階段用到的工具主要是類圖，以及對象持久化。

前面分析階段的概念類圖，是設計階段的設計類圖的工作依據。設計類圖進一步分為實體類、控制類、邊界類。設計類是直接可用于后面的程序設計的，我們這里不會講如何去設計這些類。

概念類圖是以業務領域的對象為維度來描述系統的類，而設計類圖則進一步拆分出實體類、控制類、邊界類，并定義了類之間的6種關系（關聯、依賴、泛化、聚合、組合、實現）。

我猜大部分非科班的人是看不下去的，這里豆芽君建議設計類的工作，還是交給開發經理這類崗位的人。

來自《李運華的面向對象設計課》

圖中提到的領域類就是我們教材中的概念類，軟件類就是教材中的設計類。

面向對象的設計主要就是完成類的設計。如果你有興趣可以繼續看下這段視頻：

【面向對象4 | 面向對象設計-嗶哩嗶哩】 https://b23.tv/J5EVdQ2

對象持久化：面向對象既然是以對象為維度，而不像結構化以數據為維度。但是它們的背后都還是要用到數據庫，所以面向對象就多了一個如何與數據庫進行對象/關系映射的過程。

說實話，之前豆芽君也一直犯程序與數據庫是綁定在一起的錯。后面和一些java開發的同學一聊，才發現很多java開發人員并不需要懂數據庫，也可以做好后端開發。

原來在java開發中，可以由DBA這類角色專門負責數據庫設計與開發，java開發人員只需做好對象/關系的映射（ORM）就可以。

對這塊內容有興趣，你可以繼續學習這個視頻：

【242，ORM對象關系映射了解-嗶哩嗶哩】 https://b23.tv/EYc5rmi

好了，關于面向對象設計的工具就講到這。最后我們再補充說下面向對象分析與設計的銜接。

豆芽君說下個人觀點：

• 從分工來看，面向對象分析主要由系統分析師/產品經理來完成，面向對象設計建議還是交由開發經理類的崗位來完成。
• 從工作內容來看，面向對象分析的產出物應該可以直接用于面向對象設計，不應該讓開發經理們再進行二次的分析工作。
• 從方法差異來看，面向對象相比結構化方法，在調研、分析環節更容易邀請需求單位參與，在設計、開發階段也更容易修改和維護代碼。

以上。希望不會寫代碼的你，看完今天的內容，能更好地與會寫代碼的同學撕逼。