2011-8-25 面向对象设计学习
今天参加了部门的学员培训，学习了面向对象设计及UML类图的基础。
面向对象设计与面向功能的设计
面向对象设计是按照对象或概念分解，主要考虑的问题是如何找对象，从概念模型到物理模型要做什么事。
面向功能（过程）设计的话，主要是利用在结构化分析、结构化设计，按功能或过程分解，MIS系统要用到数据库，侧重功能设计。
面向对象的好处
好处与重大优点就在于具有“抗变”能力，如果是用面向过程的话，是基于现状的，设计出来的数据库表是针对需求而言的，但是客户需求可能不断的变化，这样就会导致如果要改的话，会出现一种“牵一发而动全身”的现象，但是面向对象是可以变化的，对象是世界实体抽象出来的，然而是自然的，所以如果客户需求变化的时候，自然的对象是不会变的，变的只是一些规则之类的东西。
MIS系统
所谓MIS（管理信息系统--Management Information System）系统，主要指的是进行日常事物操作的系统。这种系统主要用于管理需要的记录，并对记录数据进行相关处理。传统的MIS系统的核心是CS（Client/Server--客户端/服务器）架构，而基于Web的MIS系统的核心是BS（Browser/Server--浏览器/服务器）架构。BS架构比起CS架构有着很大的优越性，传统的MIS系统依赖于专门的操作环境，这意味着操作者的活动空间受到极大限制；而BS架构则不需要专门的操作环境，在任何地方，只要能上网，就能够操作MIS系统，这其中的优劣差别是不言而喻的。
UML类图介绍
主要是用于类、抽象类、接口。
聚合： 整体与部分的关系
组合关系： 更强的聚合性，有相同的生命周期
关联关系：除了聚合、组合都是关联
泛化关系：一般称为继承关系
实现关系：对于类和接口之间的关系
依赖关系 绑定友元
概念模型是展示真实世界中的概念
概念模型不包括软件逻辑的内容，不会出现反应逻辑的类或方法
而不是软件类或者软件产品
（概念的识别）先不管对象有没有用，先找出来
对象识别的技巧
方式一：寻找业务描述中的名词短语。对象识别时应考虑问题域内的所有名词进行逐个识别，可以按业务流程来进行识别
方式二：将与需求无关的概念进行删除；
方式三：删除不在本问题域考虑的概念；
方式四：防止把概念当成属性。如果该概念不是一此简单的数字或文本，那么我们就可以把它当成概念，如果无法确定，先当作概念来处理。
方式五：关于描述型概念，如果一个概念会在业务过程中发生数量变化或者消失的话，那么考虑将对该概念的描述内容独立出来作为一个概念，如商品库存、办品用品等。
方式六：一般情况下，如果一个业务名词可以使用数据库中的字段类型来表示，那么就当作属性而不是概念。
找出概念中的派生关系（父子）
在识别概念间的关联关系之前，应先找出概念间存在的父子关系，这样在识别关联时只需要取一个父概念即可。
当概念Ａ是概念Ｂ的一种特例时，那么Ａ为Ｂ的子概念；
如：礼品商品
当概念Ａ是概念Ｂ的增强概念时，那么Ａ为Ｂ的子概念；
如：会员顾客、VIP会员会员
如果概念Ａ与概念Ｂ属于并列的概念，它们有着大量类似的特性时，抽象出
一个共性概念作为Ａ、Ｂ的父概念
如：管理员用户、收银员用户
找出概念间的关联
概念属性的识别
属性识别的原则：
1、概念模型的属性应取简单属性或者纯数据值。
2、常见的如：布尔、日期、数值、字符串、地址、电话、颜色、形状等
3、以及可以用枚举来表达各种属性。
4、属性最好是数据库字段类型可以表达的
避免复杂属性：
如果使用复杂属性，往往会引起混淆，例如：将机场作为航班的一个属
性是不合适的，因为机场不是一个简单的数据，它本身可以具有很多的功能，并
可以分解。在本例中，购物卡不能作为顾客的一个属性，因为它本身具有很
多简单属性
避免设计问题的蔓延：
在概念建模阶段，不应过多考虑数据库设计，或程序实现方面的设计，
以免将问题复杂化，从而即做不好概念建模，又做不好逻辑建模和物理建
模。如，在属性识别是不应考虑外键属性。
从概念模型到物理模型
模型转化原则：
1、原则上将有派生关系的父子对象（概念）转化为同一个物理表。
2、对于存在多对多关系的概念，在转化时需要增加一个中间关系表
3、通过关联关系来表达表之间的主外键关系。
4、表和属性的命名应遵守相应的数据库设计规范；
6、一般情况下一个概念对应一个表，但表和属性的设计应考虑达到第三范
式，可以按范式的需要做部分调整
数据库的前三个范式：
第一范式：表的每一列都是不可分割的基本数据项，同一列中不能有多个值
第二范式：要求实体的属性完全依赖于主关键字,并保证主键唯一；
第三范式：不依赖于其它非主属性，即消除传递依赖；
