《面向对象建模》——OO基本概念、UML

编程语言及拓扑结构

拓扑结构：语言的物理建筑模块及如何连接在一起
Fortran和COBOL语言的基本建筑是子程序
Subroutine，subprogram：子程序，类似c的函数

面向对象语言的拓扑结构：

过程抽象
数据抽象：强调数据类型，整理、组织数据

              过程抽象 + 数据抽象  面向对象 
            类就是将 数据抽象和 过程抽象 捆绑在一起

对象模型

面向对象技术的元素的全体：对象模型 没有全局变量
设计原则：

• 抽象：抽象出对象的外部行为
  原则：最低承诺（对象的接口仅仅提供基本行为，而不是更多）、最不惊讶（抽象捕捉了某对象的全部行为，不多不少。没有超越边界的“惊喜”和副作）

• 封装：具体信息 隐藏信息 行为的具体实现
• 模块化 ：将类分组到一些包中
• 层次 ：继承、聚合
• 类型 ：并发 持久

结构化：算法《——》类与对象
对象将算法抽象和数据抽象统一起来

使用对象而不是算法编程
每个对象都是某个类的实例
通过继承得到类之间的关系

• 编程方法：合适、有效的使用某种语言机制（继承、多线程、指针）
• 设计方法：有效的给复杂问题建立结构（通过继承、聚合等确定类之间的关系）

面向对象设计：

• 面向对象分解过程：产生类 对象抽象
• 与各种模型的描述记号（如UML） 类名是名词

继承的缺点：子类访问超类的变量、调用超类的私有方法、引用超类的超类
面向对象概念框架：抽象、封装、模块化、层次化

对象的定义

 对象: 是一个具有状态(数据变量）、行为、标识(变量名）的实体；
 相似对象的结构和行为由共同的类定义。

对象状态包括对象的性质，以及这些性质的当前的值

对象具有状态说明每个对象都占用一定的空间；或者在现实世界，或者计算机内存(系统中的所有对象都封装一些状态；系统的所有状态（数据）都被对象封装)

同一个类生成的对象之间，不会共享内存空间

 对象行为是其 状态 与施加于状态上的操作的函数；

一些操作改变了对象的状态 对象的状态代表其行为的积累结果

角色与责任：

一个对象的所有方法构成了其协议；
协议定义了对象允许的行为信封；构成了该对象的全部的静态、动态视图

主动对象与被动对象

• 主动对象包含了自己的控制线程，是自治的。
• 被动对象没有，仅仅当被调用的时候，才能经历状态改变
  
  两种对象之间的关系：
• 链接：对象之间的物理与概念上连接; 对象通过链接与其它对象协作，通过关联另一个对象，使用另一个对象的服务
• 聚合：代表整体-部分关系，聚合对象可以发送消息给其“部分”对象
  消息传递通常是单向的（尽量避免双向传递消息），但是，数据可能双向流动

对象的3种角色：

控制器（操作其他对象，而不被控制）
服务器（只被控制）
代理（既可控制也可被控制）

信息专家模式将责任分配

类

• 类的接口提供外部视图
• 类的实现属于内部视图：实现接口声明的所有操作

建立类关系的两个依据：
1.共享 - 产生继承关系
2.语义连接- 聚合等关系

3种基本类的关系：

1.“is a” 继承关系
2.“part of”聚合关系 （整体与部分）

3.关联关系：语义依赖 通常是双向的，确定关联重数：一对一，一对多，多对多
继承的两种方式，效果：

• 使用继承拓展超类的结构和行为
• 使用继承对超类的行为进行限制

多态

类设计

类设计的五个有意义的度量

• 耦合：一个模块到另一个模块的的关联强度的指标
• 内聚：一个独立模块中元素的连通程度
• 充足性 类或者模块包含了足够的某种抽象的特点 eg：集合类既有add（）,也有remove（）
• 完整性 ：类或者模块接口中包含某种抽象的所有有意义的特征（但不要过分）
  
• 原始性 ：只有通过直接访问封装的数据表示而实现的操作

类结构情况：宽而浅、窄而深、平衡

设计原则

1.单一责任原则

定义：每个上下文里面有个单一的责任，责任完全的被封装在环境里
责任：一个改变的理由，一个类应该仅仅有一个改变原因（责任越小越好）

2.开闭原则

定义：软件实体对拓展开放，对修改关闭
重用抽象接口，不用实现代码

3.Liskov替换原则

定义：子类型对象可以替换超类对象（但不修改程序功能）

4.接口分离原则

定义：客户端不应该被迫依赖它不需要的方法
将大的接口拆分成小的，保持较低耦合

5.依赖倒转原则

定义：依赖抽象

责任分配的一般原则

信息专家模式

• 将责任分配给信息专家类（拥有**实现**该责任的信息的类）
  

创建者模式

• **创建**某个类的对象的责任
  
• 特殊情况下超类可以创建子类对象
  

低耦合模式

两种保存出库单的设计

高内聚

控制器模式

• 将接受（处理）系统事件消息的责任分配给一个代表整体系统（子系统、设备）或者代表一个用例场景的类
  - 控制器是一个非用户图形界面类

多态模式

• 当相关的行为基于类型而变化，使用多态操作，将行为责任分配给相关的类型（比如程序使用了条件语句，要加入新的条件）
  

纯虚构模式

• 将一组高内聚的责任分配给一个虚构的类
• 

间接模式

• 将责任分配给中介对象

受保护变化模式

• 确定能预测到（类型）变化或不稳定点；分配责任以建立一个稳定的接口
  

早期开发模型

瀑布模型

直观性、通用性、计划性、自顶向下、软件开发的可管理性

进化模型

及早发现并修正错误、及时测试

螺旋模型

迭代

统一建模语言 UML

视图：

图可以分为：结构图、行为图

系统分析阶段：用例图、类图、状态图
系统架构图：包图、类图、对象图、组件图、部署图

类图

• 定义：表示类的存在以及逻辑层面类之间的关系
• 要素：类，以及类之间的关系
• 有类名、属性名、方法
  
• 有泛化、聚合、组合（整体与部分对象同时存在，同时被消灭）等关系
  
• 四种可视性：

public（+）：
protected（#）：
private（-）：
package（~）：

• 限制的种类：incomplete：还包含其他的；disjoint：互斥
• 最好将限定关联1—>*转换成 1<—>1的关联（通过使用HashTable等）

对象图

• 表示对象的存在及之间的关系，一组类实例的可能发生的结构关系
  
• 表示方法：：ClassName / objectName:ClassName
• 对象通过链接互相交互

包图

• 可以在包记号内部使用：包、用例图、类图、组件图
  
• 包也有+ / - 可视性
• 依赖关系：当要实现其责任时，依赖于另外一个元素，使用虚线开放箭头表示
• 组织一个系统的多种方式：依据架构层（3层架构）、依据子系统、依据用户功能
• 引入：import 公有包 ；access 私有包 可以使用非限定语直接引用被引入包的元素

组件图

• 组件：系统中遵从一组接口且提供其实现的物理的可替换的部分
• 定义：一组组件及之间的相互关系，包括编译、链接、执行时组件之间的依赖关系
• 组件类型：配置组件（dll、exe、ejb、web页等）、工件产品、执行组件
• 基本元素：组件、接口、接口实现
• 端口：作为与其环境交互，提供了结构化的封装
• 

部署图

• 表示工件分配到系统的物理设计节点
• 基本元素：工件、节点、连接

用例图

• 描述系统环境与系统应该提供的功能（谁与系统交互，客户让系统做什么）

• 用例描述：用例名、目的；乐观流；实际流

• 若一个用例描述太长，可以拆分：

  • 《include》包含：明确说明共同功能
  • 《extend》拓展：简化复杂而用例流

• 泛化关系

业务建模：创建组织结构图、领域建模