《UML大战需求分析》阅读随笔（三）

一：

需求中提到的各种业务概念、人物等，经过抽象后都可以视之为类。

平时遇到的人、物，我们将遇到的都是具体的人、物，也就如程序中的对象，是一个实实在在的东西。

当我们分析需求的时候，设计模型的时候，我们就需要将之抽象，也就是最关键的一步——提炼。

提炼出这个东西，我们所需要的部分。

比如，在教室，主要存在两类人，学生和教师。

当我们做的项目为：人员管理系统

在如上的环境中，我们需要的是学生和教师的姓名和年龄、学号（工号）等这些利于了解基本信息的数据。那么，我们进行模型设计的时候，类图就应该主要包含这些东西。

当我们做的项目为：培训管理系统

我们需要的是学生的知识水平和接受能力，老师的知识水平、表达能力和讲课经验。这些才利于培训的分配和安排，那么设计的类图就应该包含这些东西

上面两个简单例子，就是区分在需求分析的时候，我们考虑的对象，在我们所做的项目下，我们需要从中真正需要的是什么，也是使用我们的软件的客户，真正看到的、使用到的是什么，要让其存在意义。

二：

类之间也存在关系

一切从直线开始，表示它们之间存在某种关联关系

“导航”关系，例如通过请假单可以找到请假者

“包含”关系，空心菱形是“弱”包含，实则为聚合，实心菱形是“强”包含，实则为组合，两者的区别主要是强烈程度不同。

“继承关系”，学生、讲师都“继承”了员工，它们具备员工的属性，也有自己的特有的属性。实则为 泛化

“依赖”关系，但依赖程度是相对而言的，不一定是A没有B就不能“生存”了，对于某个事情，A需要B来协助才能完成，这也为一种依赖。好比烟鬼和香烟

三：

利用类图来描述一些架构，如公司的组织架构。

比如某公司由一个一个的部门组成，类图表达其组织结构可能如下：

但这样没有显示出类图的优势，没有发挥抽象和提炼的优势。进一步改进如下：

这就更加形象了，有助于我们在项目进行中，分类和分层，更加清晰地看见其内部结构，成果思路也更有层次。