高级软工笔记

OOP

对象

对象是存在的具体实体，具有明确定义的状态和行为。

消息指一个对象为执行某项特定操作而向另一个对象发送的请求

对象执行的操作称为方法

类

类是具有相同属性和行为的一组对象的集合

在类中表示对象或实体拥有的特性时称为属性

类和对象

类是概念模型，是对象的原型，对象是实际实体

对象是对客观事物的抽象，类是对对象的抽象

对象是类的实例，类是对象的模板。对象是通过类的构造方法来产生的

抽象和封装

隐藏属性、方法或实现细节的过程称为封装

抽象是指只关注事物的重要细节，而忽略事物的次要细节。

• 处理事物复杂性的方法

• 抽象包括过程抽象和数据抽象

封装是屏蔽细节，抽象是提取共性

包(package)

• 包将类名空间划分为更加容易管理的块
• 包既是命名机制也是可见度控制机制

package packName;	//创建包
import packName;	//导入包

多态

继承

子类构造函数时需先构造父类
调用父类构造方法的语法为：
super()或super(参数列表);
super()方法始终指向调用类的父类

多态包括方法重写(override)和方法重载(overload)

重载同名不同参，重写同名同参，可用super.methodname()调用父类方法

访问修饰符

方法修饰符

• static：修饰的方法叫静态方法
• final：子类不能重写方法/修改变量
• abstract：修饰的方法叫抽象方法，修饰的类叫抽象类
  • 抽象类不能实例化
  • 构造方法和static方法不能抽象

接口

• 接口就是某个事物对外提供的一些功能的申明
• 一般使用接口声明方法或常量，接口中的方法只能是声明，不能是具体的实现
• 使用interface关键字定义接口

总结

• 封装、继承和多态是面向对象的主要特征
• 继承可提高代码的重用性，java使用extends关键字来实现。
• 除了构造方法之外，父类的所有方法和属性都被子类的对象继承
• 多态性是不同的实例对象以不同的方式对相同的信息作出不同的表现
• 访问修饰符用于确定访问类成员的方式
• Java常用修饰符有static、final、abstract
• 接口是Java编程一项重要的技术，同过它可以实现多态，同时它也弥补了Java单一继承的不足

UML图

统一建模语言UML是第三代用例为OO开发系统的产品进行说明，可视化和编制文档的方法

类图

接口

多重性

表示参与对象数目的上下界

• 1：表示1个对象
• x..y：表示x个或y个对象
• • :表示0到多个对象

依赖

依赖关系是指两个或多个类之间的依存关系

依赖关系用虚线箭头来表示，箭头指向为依赖的方向。

聚合与组合

• 聚合关系是“has-a”关系，组合关系是“contains-a”关系
• 聚合是空心的菱形；组合是实心的菱形

如果A由B聚合成，表现为A包含有B的全局对象，但是B对象可以不在A创建的时刻创建

如果A由B组成，表现为A包含有B的全局对象，并且B对象在A创建的时刻创建。

• 聚合成员对象可脱离整体对象独立存在

• 组合时子物体随父物体消失而消失

泛化

面向对象里的继承是泛化的特例，泛化是空心三角形

关联

关联关系是类之间一种相互影响的关系，影响的方向就是关联的方向。

三种画法

• 实心三角形箭头（可不画）
• 箭头
• 双向关联可以双箭头，也可以没有箭头

实现

针对类和接口，空心三角形+虚线

领域类图

又称为概念类图，即是没有方法的类图的集合

用例图

用例是软件产品的外部用户(参与者)和软件产品自身的交互模型

用例图包括：参与者，用例，关系

聚合关系

参与者与用例之间的实线，表示两种之间交互

包含关系 < < include > >

基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行

如果发现多个用例叙述中有一部分流程相同，就可以独立处理，重用。

虚线，上面写着< < include > >，箭头从基用例指向子用例。

扩展关系< < extend > >

基用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能。

在特定条件下才被额外使用的，部分独立处理就是扩展。

虚线，上面写着< < extend > >，箭头从子用例指向基用例。

泛化关系

空心三角形箭头，表示继承，子类指向父类

额外：用例描述

• 围绕“交互”进行场景描述。
• 保持“规格说明”级别，尽可能不要涉及界面、按钮、方法等软件系统的内部构造机制。
• 正常流程中，注意交互序列的完整性，用户操作与系统反应都应该写出来。

时序图

又称为顺序图，序列图，是对象直接传送消息的时间顺序的可视化表示

画法细节

• 生命线名称可带下划线。当使用下划线时，意味着序列图中的生命线代表一个类的特定实体

• 同步消息是实心三角形箭头，发送人在它继续之前，将等待同步消息响应

  

• 异步消息是箭头实线，在发送方继续之前，无需等待响应的消息

  

• 返回消息用虚线，发送消息和自调用消息都是实线

• 注释是实心圆点+虚线+方框注释

  

• 约束格式是: [Boolean Test]

  

• 组合片段

  • 以下条件均用"[条件]"的形式
  • 选择if else ：Alt
  • 选项：Opt
    • 包含一个可能发生或不发生的序列
  • 循环（Loop）
    • 片段重复一定次数。 可以在临界中指示片段重复的条件。
  • 并行（Par）

详细图解用例图，类图，时序图：https://blog.csdn.net/chengquanlam/article/details/73161038

ER图

构成E-R图的基本要素是实体型、属性和联系

包图

包图是在 UML 中用类似于文件夹的符号表示的模型元素的组合

一般由大小两个矩形，左上方矩形可写包名

通过对包中各个包以及包之间关系的描述，展现出系统的模块与模块之间的依赖关系

包中元素可以是接口，类，用例

画法细节

• 可见度控制

  

• 基本画法：文件夹，一般由大小两个矩形，左上方矩形可写包名

• 包图关系

  • 使用use：说明客户包中的元素以某种方式使用提供者包的公共元素
  • 包含import：提供者包(箭头指向的包)的命名空间（包本身代表命名空间）将被添加到客户包（发出者）的命名空间中，客户包中的元素也能够访问提供者包的所有公共元素
  • 访问access：提供者包命名空间的公共元素被添加为客户包命名空间上的私有元素
  • 跟踪trace：模型之间的关系一个元素历史地发展成为另一个版本。

• 绘制原则

  • 最小化包之间的依赖，最小化每个包中的public、protected元素的个数，最大化每个包中private元素个数
  • 在建模时应该避免包之间的循环依赖

面向对象的设计原则

LSP：里氏代换原则

Liskov Substitution Principle，LSP

• 若在任何情况下，子类或实现类与基类都可以互换，那么继承的使用是合适的
• 子类不能添加任何父类没有的附加约束
• 子类对象必须可以替换基类对象

例子

正方形继承长方形类，违背LSP原则，导致出现错误。

OCP：开闭原则

Open Closed Principle，OCP

软件实体应该是可扩展的，但不可修改的

• 对于扩展是开放的
• 对于更改是封闭的
  • 对模块行为扩展时，不必改动模块源代码或二进制代码

OCP的关键在于抽象

• 抽象技术：abstract class，Interface
• 抽象预见了可能的所以扩展(闭)
• 抽象随时可导出新的类(开 )

例子：

手开关抽屉，门，冰箱。。。

那如果手直接和可开关的具体类关联，则每次添加新的具体类都需要修改手的源代码

解决方案：新增一个接口

SRP：单一职责原则

Single Responsibility Principle，SRP

• SRP体现了内聚性，即一个模块的组成元素直接的功能相关性
• 类的职责定义为“变化的原因”，当一个类承担了多于一个职责，那么引起变化的原因会有多个

例子

解决方案

ISP：接口隔离原则

Interface Segregation Principle，ISP

• 客户不应该依赖他们用不到的方法，只给每个用户它所需要的接口
• 为避免肥接口，应该一个类实现多个接口，每个客户仅知道必须的接口
• 要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

例子：接口污染

DIP：依赖倒置原则

Dependence Inversion Principle，DIP

• 高层模块不应该依赖底层模块，二者应该依赖于抽象
• 抽象不应该依赖于细节，细节应该依赖于抽象
• 针对接口编程，不要针对实现编程

例子：传统依赖关系

解决方案

LKP：最少知识原则

Least Knowledge Principle，又叫迪米特法则（Law of Demeter，LoD）

启发式原则

• 依赖于抽象，即所有依赖关系都应该止于抽象类或接口
• 任何类不应该从具体类派生
• 任何变量不应该拥有指向具体类的指针或者引用
• 任何方法都不应该改写任何基类中已经实现的方法

体系结构

软件体系结构的核心由5种元素组成：

构件、连接件、配置，端口和角色。

其中，构件、连接件和配置是最基本的元素

体系结构的全部内容就是复杂性管理：
将解决方案划分成多个小的组成部分，再将这些小的部分结合起来，构成更大的、更一致的结构

• 包
• 包依赖关系图
• 子系统
• 层

作用

• 指出系统应该具有的功能
• 为完成这些功能，涉及到哪些类，这些类如何联系

体系结构风格（宏体系结构模式）

• 是对某个体系结构的一组约束，定义了能满足要求的一组或一族体系结构
• 也可以看作是提供软件系统高层组织的元模型
  • 通用结构：分层、管道过滤器、黑板
  • 分布式系统：客户-服务器、三层、中介
  • 交互式系统：MVC、表示-抽象-控制
  • 可适配系统：微内核、反映式
  • 其他：批处理、解释器、进程控制、基于规则

包

• 包是一种将模型元素分组的机制
• 包主要用于
  • 组织模型元素
  • 配置管理单元
• 分包原则
  • 职责相似：将一组职责相似’但以不同方式实现的类归为一组有意义的包
  • 协作关系：包含了各个不同类型的类，它们之间通过相互协作实现一个意义重大的职责

包依赖关系

体系结构设计过程

1. 确立目标
2. 将类分组
3. 展示技术
4. 抽取子系统
5. 针对准则和目标对体系结构进行评估