今天开始我的第一份日报吧

今天完成的事情:

task1-1~1-3

       了解了业务模型--类图，知道了什么是类图，怎么画类图，以及面向对象的内容。

1.1什么是面向对象，怎样用面向对象的思想解决问题？

      先说什么是对象，都说万物皆对象，就是说对象是现实世界存在的各种实体，如一本书，椅子，大象，高楼大厦，都是对象。面向对象就是关注，思考这个对象，考虑这个对象具备什么样的属性和行为。面向对象编码是一种基于类的编程方法，每一个类有特定的作用，类中有属性和方法，一条条语句只存在于属性或方法中。用面向对象的思路来求解问题，就是要设计出能解决问题的一个或多个类，通过类之间的相互操作和协作来解决问题。类是对代码的进一步封装，比方法对代码的封装要进一大步，类的出现要求我们编程的思想更进一步。

1.2类图基础内容

       类图作用，类图能帮助我们识别出一些人、业务概念、物品和事情等，并理清它们的关系。将某类东西归纳为一起，可以称为一个类。类有很多种提炼角度，需要根据系统的目标、业务的场景等，选取合适的角度对事物进行归纳。

简单一个类的类图

一个类就是一个矩形的方框，最上面是类的名字，中间是属性（Attribute），最下面是操作（Operation）。表示一个类时，可只显示类名，也可以只显示类名和属性，或者是类名和操作。

我们看看这个属性：+属性1:int。

前面的“+”号表示这个属性是public类型的，实际上在需求分析时，不需要管属性是public还是private，全部画成public就可以了。

冒号后面的int，表示属性的类型是int型（整数型），往往在需求分析初始阶段，可不必标识属性的类型，至于操作在业务建模是不用标注出来。

用类图获取需求的大致步骤如下：

1) 识别出类。

2) 识别出类的主要属性。

3) 描绘出类之间的关系。

4) 对各类进行分析、抽象、整理。

然后就可以开始画类图了。

一个培训管理系统，请你用类图识别出课室中有什么人？这些人有什么关键属性？

这是两个类。

下面是他们的属性。

1.3怎么画类图，类的关系有几种，分别是直线，包含，继承，依赖关系。

1.3.1直线关系有：

一对一关系。

一对多关系。

一对零到多个关系，这个图表示一个G对应0到3个M，“0..3”表示0到3个注意有两个点（“..”）而不是一个点（“.”）。

包含关系有：

这里有两种表示法，一种是空心菱形，一种是实心菱形。两种菱形表示包含的强烈程度不同，空心菱形是“弱”包含，实心菱形则是“强”包含。你可以这样记忆：空心菱形是空心的，显得虚弱一点，这是“弱”包含；实心菱形是实心的，显得更加强壮，这是“强”包含。

“弱”包含表示如果部门没有了，员工也可以继续存在；“强”包含表示如果部门没有了，员工也不再存在。关于这两者的另外一个重要区别是：如果是“弱”包含关系，儿子可以有多个父亲（当然只有一个父亲也是可以的）；如果是“强”包含关系，则儿子只能有一个父亲。

继承关系：

1.4自包含，自关联

图  文件夹与文件关系，自包含关系

文件夹里面有文件夹，里面的文件夹里面有可能有文件夹，这可能是无穷无尽的“递归”啊！而这个包含关系可以自己指向自己，可以“自包含”，这个无穷“递归”的问题就解决了，实在太完美了！

无论是弱包含还是强包含，都可以“自包含”。除了“自包含”可以形成“递归”，其实直线关系同样是可以指向自己的，这个叫“自关联”，这样也形成了“递归”关系。

图  自关联

1.5三角关系

“三角”关系

前面有个练习，要求你画出公司与雇员的关系，现在要求你分别列出公司和雇员至少3个关键属性。

待你列出关键属性后，请你思考这些问题：

1)薪金是雇员的关键属性吗？合同期、职位呢？

2)公司与雇员，这两者的关系在法律上是如何确立的？

你一定会想到，公司与雇员要签署劳动合同，而劳动合同上会有薪金、合同期、职位这些重要的内容，那么薪金、合同期、职位还算是雇员的属性吗？公司、雇员、劳动合同这三者是怎样的关系

在表示公司与雇员的关系的直线上，拉出一条虚线，虚线另外一端连接劳动合同类，这样的类叫做关联类（Association Class），关联类是对两个类的关系的进一步约束。

要识别出能表征两个类关系的关联类，难度是有点高的，有这样的一些实践建议供你参考：

1)如果觉得两个类有关系，则先拉上一条直线再说。

2)如果觉得两个类有关系，但怎样画都觉得这个关系不太合适，那么可以思考是不是漏了一个关联类了。

3)分别列出这两个类的关键属性，思考这些属性的属性值是不是由该类本身就可以确定了。例如：如果我们最开始将薪金作为员工的属性，那么你可以思考薪金的具体数字，是不是员工自己本身可以确定的？你会发现薪金其实是由公司和员工商定后确定的，并不是员工自己本身可以决定。

4)通过对属性的思考，可能会发现这个属性应该是属于另外一个类的，思考这个类是不是能表征原来两个类关系的关联类

关联类这样复杂的东西，客户是不太可能直接告诉你的，你需要在需求分析中发现和提炼出关联类，这对需求的理解以及项目后期的设计工作将会有很大的帮助。

将薪金、职位、合同期这些信息直接当成是雇员的属性也不是不可以的，这跟我们做系统的目标很有关系。如果我们只是做很简单的员工信息管理，可能就没有必要将合同提炼出来。如果我们要做一个人事管理系统，甚至要产品化，这样就需要我们将业务模型分析得更加透彻。

这个图可能最体现它们的“三角”关系了，关联类也可以表达成这样的方式。但我在实际工作还是以关联类的方式来表达，我觉得关联类的表达方式更加贴切和专业一点。

在具体的需求分析工作时，如果你发现三个类形成了类似该图的“三角”关系，你可以思考其中一个类是不是可能是关联类，但要注意并不是凡是出现了“三角”关系就一定会有关联类。

1.6对象图

3.7 关于对象图

写过代码的朋友比较容易理解什么是对象，类（class）的实例（instance）就是对象（object）。第1章大话UML曾讲解过对象图，我们再来复习一下。

这是Person类：

图 Person类

下面这句代码将Person类实例化为person对象：

Person person = new Person（）;

用对象图表示为：

图 person对象

一个公司包含多个员工，用类图这样表示：

图 1.38 公司和员工的关系

此图的公司和员工并没有指具体是哪个公司或者哪个员工，如果某公司A有甲、乙、丙三位员工，用对象图则可以这样表示：

图  公司A与员工甲、乙、丙的关系

“A:公司”表示对象A是公司这个类的实例；如果是“:公司”，则表示这是公司这个类的实例，但没有给出这个实例的具体名称。

类是某一类东西的抽象或者叫统称，而对象则是具体的一个东西，A公司如果有1000名员工，那么就需要画一千个“包含”才能表示出A公司与所有员工的关系。对象与对象之间如果有关系，那肯定是一对一的关系，因为两者都是具体的东西，不可能存在第二个。比方说张三和李四是好朋友，他们的关系就是一对一的好朋友关系，因为不可能再有另外一个张三或者李四，但如果我们将张三和李四抽象为人时，一个人可以与很多人交朋友，这样就可以建立多对多的朋友关系。

需求分析时，其实我们接触到的是一个个具体的东西，如：见到一个个具体的人，接触到一份份具体的业务数据等等，这些具体的东西其实就是对象。而我们分析需求不能就事论事，我们需要将这些对象提炼为类，这样的分析才更具有代表性。我们软件系统并不是用来解决具体某次事件中的一个问题，而是希望能解决某一类问题。

需求分析工作中很少需要用到对象图。基本不会使用对象图，而直接使用类图，在少数需要使用对象图时，我甚至会直接用类图代替，这样做也并没有不妥而且也容易理解和解决问题。

回到任务一中的第一个小任务。

tast1.1

参考修真院线下报名贴（学习资料-线下报名-北京报名）中报名的格式，整理出业务模型，确定需要几个对象，每个对象的属性是什么，对象和对象之间的关系是一对一，还是一对多。

该报名中有一个对象即学员金石开，金石开的属性有，姓名，联系方式，入学时间，院校，线上学号，安排师兄，日报链接等属性，可用有多个学员

明天计划事情：创建报名贴的业务表，并将表结构粘贴到日报中，复习java基础知识，继续实施任务一。

收获：知道类图的使用，面向对象解决问题，知道了mysql和navicat的概念，并安装了eclipse，navicat，mysql。