根据产品原型结合主流程抽取类，属性以及关系

最近又开始做项目，一直对软件构建流程中的需求分析与设计没有很明确的节奏，这次想根据我们团队的开发节奏边做边整理，希望固化这些东西不用每次都思考，
不能说是最优，但起码能够给一些没有固定打法的同学一些建议。

找出主流程对应的页面

相信会有很多人在拿到原型之后会不知所措，不知道怎么看原型，不知道怎么抽取核心业务，不知道根据核心业务怎么抽取类，
前面的一篇博客可以给你一些思路：根据产品原型如何抽取主流程
以前一直没有找到主流程的意义，现在终于知道，它的确可以指导我们看原型而且不会偏离主业务。
这第一步就是：我们根据主流程的流向和节点可以找出对应的页面。

在页面上找名词

根据主流程找到页面之后，从左到右从前到后一个名词都不放过，
把你所有认为可以作为备选的全部列出来。

根据你列举的所有名词，做以下操作

走到这一步你会发现，你的名词列表会很多，别着急做一下操作可以帮助你简化你的名词列表。

确定每个名词的含义

在做项目中我们难免会做超出我们认知范围内的领域知识，找产品和客户搞清楚这些名词的含义这一点很重要，
因为一旦这个名词作为类之后，可以帮助我们确定这个类的职责。

去重名词

如果两个名词在概念上比较相似，但是表面词语不太一样的可以将这两个词归为一类，
删除多余的名词。

对名词分组

有一些名词都是可以分到一个组中去的，比如：程序员，人事，cto,都是公司的员工，
所以可以分到员工组中。

验证你的名词列表是否符合业务

根据流程图，找到对应的页面，一个一个页面去验证：
流程里的所有名词是不是都有对应的类（或者类里的属性），
如果没有的话，就说明不符合，如果都覆盖了，就说明满足。
注意：
一个系统不会有太多的名词，名词越精简越有利于你理解系统。

建立类图

你可以根据你的名词列表建立对应的类图，这个时候不用体现属性。
给每一个类确定一个职责，因为只有明确这个类的职责定义清楚，你才可以确定哪些属性应该放到哪个对象上。

确定类关系

一个系统中的类不可能独立存在而和其他的类没有任何关系，那这个类可以考虑删掉了，
我们需要梳理清楚某个类都和其他的类有什么关系。
确定类的关系，可以参考另外一篇博客:我对uml类图关系的理解

填充类属性

根据类的职责结合原型中的信息，将属于这个类的属性放到这个类上。
注意：
在类图上添加属性的时候，只存放属于自己的属性，所依赖的对象可以通过关系去体现。
比如：学校和学生是一个单独的类，学生里要有一个学校的属性那这个属性要不要在类图上体现，
建议是通过关联关系或者依赖关系的图形表示。