可能变化比较多，通过分离，有效地降低了软件维护的成本。类的这三种类型也 可以类比一个企业内的组织分工，实体类就是那些岗位员工，是真正处理业务的： 边界类就是那些销售和供应人员，负责与外界打交道：控制类是企业中的管理人 员，本身不干活，负责协调大家。一个合理的组织分工这三者都是需要的。 3.类识别注意点 在识别类的时候，有以下注意点： 1)类的命名：在类命名时，首先应该用实际业务中的名字，同时，名字应该 相对通用，而不是过早限定具体的方式。例如，在教室预定系统中，代表 终端的类，可以是MobileTerminal,也可以是MobilePhone, MobileTerminal不限于MobilePhone,是不是客户端只支持MobilePhone 可以留待后续设计时决定，那么用MobileTerminal就会比较通用。 2) 虽然我们一再强调类应该代表现实中的概念，然而我们毕竟在开发软件， 所以在识别类时，可能会专门创造一些用来记忆“公共信息”的类，以避免 信息的重复。例如，在现实生活中，每一件商品上都是有商品信息（名称、 产地、成分等等)的，但是同类商品上的这些商品信息都是一样的，为了 避免重复，我们可以添加一个ProductSpecificaion类，记录商品信息， Product类本身只保存商品编号、生产日期等信息，从而避免信息的冗余。 3) 在识别类时，也有可能依据软件的具体需要，适当添加一些实际生活中并 不存在、但是出于软件的特点而添加的类，控制类就属于这种情景。 5.2.2对象模型的表达 识别出类后，我们将利用类图来表示对象模型。类图由类和类之间的关联关 系构成。分析阶段的对象模型主要是对真实世界中概念类的表示，而不是软件对 象的表示。对象模型中要考虑： 1.属性的添加 每一个类需要添加属性，类的对象的属性取值保存和刻画了对象当前的状态。 每一个类都有许多细节信息，因此可以作为属性的数据项也很多，但是，我们并 不需要也不可能把一切数据项都作为属性。我们可以根据该属性是否对我们当前 的应用有价值来确定是否需要添加该属性。 另外一个问题是哪些应该作为属性，哪些作为类来建模。一般而言，属性应可能变化比较多，通过分离，有效地降低了软件维护的成本。类的这三种类型也 可以类比一个企业内的组织分工，实体类就是那些岗位员工，是真正处理业务的； 边界类就是那些销售和供应人员，负责与外界打交道；控制类是企业中的管理人 员，本身不干活，负责协调大家。一个合理的组织分工这三者都是需要的。 3. 类识别注意点 在识别类的时候，有以下注意点： 1） 类的命名：在类命名时，首先应该用实际业务中的名字，同时，名字应该 相对通用，而不是过早限定具体的方式。例如，在教室预定系统中，代表 终 端 的 类 ， 可 以 是 MobileTerminal ， 也 可 以 是 MobilePhone ， MobileTerminal 不限于 MobilePhone，是不是客户端只支持 MobilePhone 可以留待后续设计时决定，那么用 MobileTerminal 就会比较通用。 2） 虽然我们一再强调类应该代表现实中的概念，然而我们毕竟在开发软件， 所以在识别类时，可能会专门创造一些用来记忆“公共信息”的类，以避免 信息的重复。例如，在现实生活中，每一件商品上都是有商品信息（名称、 产地、成分等等）的，但是同类商品上的这些商品信息都是一样的，为了 避免重复，我们可以添加一个 ProductSpecificaion 类，记录商品信息， Product 类本身只保存商品编号、生产日期等信息，从而避免信息的冗余。 3） 在识别类时，也有可能依据软件的具体需要，适当添加一些实际生活中并 不存在、但是出于软件的特点而添加的类，控制类就属于这种情景。 5.2.2 对象模型的表达 识别出类后，我们将利用类图来表示对象模型。类图由类和类之间的关联关 系构成。分析阶段的对象模型主要是对真实世界中概念类的表示，而不是软件对 象的表示。对象模型中要考虑： 1. 属性的添加 每一个类需要添加属性，类的对象的属性取值保存和刻画了对象当前的状态。 每一个类都有许多细节信息，因此可以作为属性的数据项也很多，但是，我们并 不需要也不可能把一切数据项都作为属性。我们可以根据该属性是否对我们当前 的应用有价值来确定是否需要添加该属性。 另外一个问题是哪些应该作为属性，哪些作为类来建模。一般而言，属性应