面向对象的分析与设计，难点不在于分析，而在于设计，因此需要正确把握两项工作之间的工具和衔接方法。通过本篇文章，能让你更加细致的了解面向对象的分析与设计，希望能对你有所帮助。
今天这篇是软考——系统分析师的第二篇推文。
去年7月豆芽君写过这篇文章《产品设计之从业务到产品》。
这次备考过程，我对面向对象有些补充理解，今天写的内容，会部分推翻之前的内容。但如果你能两篇文章对照着看，相信你可以对比、了解下结构化分析与设计 VS 面向对象分析与设计。
面向对象技术出现在1980年左右，比豆芽君出生的还早。可目前大多数的2B产品分析与设计，都是行面向对象之名，行结构化之事。
这里面的原因豆芽君认为主要是两类人造成的：
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
好了，关于面向对象设计的工具就讲到这。最后我们再补充说下面向对象分析与设计的衔接。
豆芽君说下个人观点：
- 从分工来看，面向对象分析主要由系统分析师/产品经理来完成，面向对象设计建议还是交由开发经理类的岗位来完成。
- 从工作内容来看，面向对象分析的产出物应该可以直接用于面向对象设计，不应该让开发经理们再进行二次的分析工作。
- 从方法差异来看，面向对象相比结构化方法，在调研、分析环节更容易邀请需求单位参与，在设计、开发阶段也更容易修改和维护代码。
以上。希望不会写代码的你，看完今天的内容，能更好地与会写代码的同学撕逼。
作者：豆芽悟，公众号：豆芽悟
本文由 @豆芽悟 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
