业务概念—类图

用类图获取需求的大致步骤如下：
1. 识别出类
2. 识别出类的主要属性
3. 描绘出类与类之间的关系
4. 对各类进行分析、抽象、整理

识别出类

在需求分析中遇到的各种业务概念经过抽象后就是类，表示一类……。例如：在图书管理系统中，书籍是一个类，借阅者也是一个类。识别出类，看似很简单的一句话却非常考验面向对象分析的能力，需要不断的学习，总结才能做到既快又正确的识别出类
在UML图中，用一个矩形框表示类图，类图包含：类的名称、类的属性、类的动作，如下图：

识别出类的主要属性

识别出类，只是找到了某软件中的业务概念，还需要对业务概念进行描述，识别出类的主要属性就是对业务概念的进一步描述，加深对该业务概念的理解。属性有三种类型：

• 公有，属性名称前带+的属性为公有属性，可以在类外直接访问
• 保护，属性名称前带#的属性为保护属性，只可以在类及其子类中访问
• 私有，属性名称前带-的属性为私有属性，只能在类中访问，其子类和类外都不可以访问

在Book类中，主要的属性包含：名称、作者、出版社等，修改后如下图：

如果某个类的一些属性，感觉怪怪的，既可以是A类，也可以是B类，那可能需要考虑一下是否可能弄出一个关联类，把这些属性放到这个关联类中，例如，公司与员工的薪资信息（一般类的属性可以由类自身单独决定，像薪资和供职期间需要公司与员工双方面决定的属性则有很大可能属于关联类的属性）：

描绘出类与类之间的关系

一开始我试图通过一个例子把类与类之间的关系全部包含进来，经过尝试之后，我就放弃了这个想法，毕竟我还是一只大菜鸟，弄懂这些关系已经非常不容易了，胖子要慢慢吃。

关联（Association）

关联关系应该是类与类之间最简单的关系了，在类图中用一条直线连接关联的两个类来表示，直线的两端可以设置几对几的关系，直线上还可以给关系命名。在代码中体现为从一方可以找到另外一方，关联关系也有单向关联和双向关联的区别。网上看到一张图片很好的诠释了关联关系的两个类型：

下面是我画的夫妻关系的图：

依赖（Dependency）

依赖是关联的强化关系，比如很小很小的熊猫无法离开熊猫妈妈而单独生存，可能被饿死，也可能被猴子派来的逗逼打死。小熊猫就依赖于熊猫妈妈：

继承（Generalization）

继承是面向对象的一大特点，继承的类是被继承类的一个特例，可以理解成特例化一个类的过程叫做继承。例如：水果是一个类，苹果、梨、香蕉是一种水果，可以用类图表示他们的关系，继承关系在类图中用带空心三角符的箭头表示，箭头所在的一方为被继承的类，也叫父类，另一方为子类：

聚合（Aggregation）

强调整体与部件的关系，部件可以脱离整体单独存在。例如：汽车和车轮；公司与员工

组合（Composition）

组合也是强调整体与部件的关系，与聚合的不同之处在于，组合关系中的部件不能脱离整体而存在，比如：公司与部门的关系