2020 软件工程复习 -面向对象分析、设计

2020 软件工程 -面向对象分析、设计

1.面向对象技术
面向对象技术基于对象概念，以对象为中心，以类、组合、继承为构造机制，充分利用接口和多态提供灵活性，来认识、理解、刻画客观世界和设计、构建相应的软件系统。
面向对象=对象 + 类 + 消息 + 继承 + 多态
面向对象方法是一种把面向对象的思想运用于软件开发过程，指导开发活动的系统方法，包括分析、设计和实现等活动
面向对象是软件方法学的返璞归真：面向用户
2.面向对象技术优点
? 沟通
? 稳定
? 复用
? 改善软件结构（模块化与封装），提高软件灵活性
? 增加可扩展性
? 支持增量式开发，支持大型软件开发
3.面向对象vs过程

4.UML建模工具
4.1 UML（统一建模语言）
Unified Modeling Language（统一建模语言）是对象管理组织（OMG）制定的一个通用的、可视化的建模语言标准，可以用来可视化（visualize） 、描述（specify）、构造（construct）和文档化（document）软件密集型系统的各种工件（artifacts，又译制品）。
4.2 UML结构
构造块：基本UML建模元素、关系和图
? 事物：建模元素本身
? 关系：把物件联系在一起，关系说明两个或多个物件时如何语义相关的
? 图：UML模型的视图，它们展现物件的集合，“讲述关于软件系统的故事”，是我们可视化系统将做什么（分析级图）或者系统如何做（设计级图）的方法
公共机制：达到特定目标的公共UML方法
架构：系统架构的UML视图

结构事物
? 类：类是具有相同属性、相同方法、相同语义和相同关系的一组对象的集合。一个类可以实现一个或多个接口。在UML图中，类用包括类名、属性和方法的矩形来表示。

? 协作：协作定义了交互的操作，表示一些角色和其他元素一起工作，提供一些合作的动作。一个给定的类可能是几个协作的组成部分，这些协作代表构成系统的模式的实现。

? 活动类：类对象有一个或多个线程或进程的类。活动类和类相似，只是它的对象代表的元素的行为和其他的元素同时存在。在UML图中，活动类的表示方法和普通类的表示方法相似，也是使用一个矩形，只是最外面的边框使用粗线。

? 节点：节点是一个物理元素，它在运行时存在，代表一个可计算的资源，比如一台数据库服务器。在UML中，节点使用一个立方体来表示。节点通常包括处理器和设备。

状态机：状态机是对象的一个或多个状态的集合。在UML图中，状态机通常用一个椭圆矩形来表示。状态机是一个行为，它说明对象在它的生命周期中响应时间所经历的状态序列以及它们对那些事件的响应。

注释事物
? 注释：注释是依附于一个元素或一组元素之上，对其进行约束或解释的简单符号。

关联：关联是一种结构关系，它描述了一组对象之间的静态连接

依赖：依赖是一种使用关系，它说明一个事物的变化可能影响到使用它的另一个事物

实现：实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。


? 参与者：与系统交互的外部实体
? 用例：从用户角度描述系统的行为
参与者之间的泛化关系：参与者之间的一般与特殊的关系

用例之间的包含关系：一个用例是对另一个用例描述的活动序列的某个活动的细化

类图：描述系统的静态结构；展示系统中的类、类的属性和操作、以及类与类之间的关系(关联、依赖、聚合等)；在系统的整个生命周期都是有效的。

通信图：描述了对象与周围对象之间的交互，以及它们之间的链接；序列图和协作图两者之间可以相互转换；序列图侧重消息之间的时序性，通信图侧重对象间的联系。
活动图：描述由不同对象所执行的一组活动、以及活动之间的关系；反映系统中各种活动的执行顺序。
状态图：描述一组状态、以及状态之间的迁移；反映一个特定对象的所有可能状态以及引起状态迁移的事件。
4.2.4 公共机制
? 规格说明：UML的图形表示用来对系统进行可视化，UML的规格说明用来描述系统的细节。规格说明提供了对构造块的语法和语义的文字叙述。
? 修饰：UML表示中每一个元素都有一个基本符号，可将各种修饰细节加到这个符号上。
? 公共分类：对类和对象的划分；对接口和实现的划分。
? 扩展机制：
衍型：也称构造型，常用《衍型名》表示
约束：增加新的语义或改变已有的规则
标记值：详述与代码生成或配置管理有关的特性，用{(标记)= (值)}表示
UML的规则
UML有用于描述如下事物的语义规则：
? 命名：任何一个UML基本图素和模型图都必须命名
? 作用域：UML成员所定义的内容起作用的上下文环境
? 可见性：UML成员能被其它成员引用的方式
? 完整性：UML成员之间互相关联的合法性和一致性
? 运行属性：UML成员在运行时的特性，如进程、线程、同步等
4.2.5 架构

一般的建模顺序：

4.1.4 描述用例
用例的描述模版：

取款用例描述：

4.2 对象建模
对象建模就是建立系统的对象模型
对象模型反映了系统类与类之间的关系，体现了系统的静态结构
对象模型由类图来表示
4.2.1工具——类图
类图由类、接口等模型元素以及它们之间的关系构成。类图的目的在于描述系统的构成方式，而不是系统如何协作运行。
4.2.2 类
描述类的信息有：名称、属性、操作、职责、约束、注释。
? 属性（Attribute）在UML类图标的矩形框中用文字串说明

属性多重性：多重性为可选项，它表达该类的每个实例的属性值的个数。可以像应用于类之间的关系中那样把多重性应用于属性。

? 操作（Operation）表示类能够提供的功能服务。它在UML类矩形框中用文字串说明。

4.2.3 接口
接口是在没有给出对象的实现和状态的情况下对对象行为的描述。接口包含操作但不包含属性，且它没有对外界可见的关联。在UML中，接口是用一个带有名称的小圆圈表示的，并且通过一条实线与它的模型元素相连接。

对泛化有以下常用的约束：
complete: 说明泛化中所有子元素都已在模型中说明，不允许再增加其它子元素。
disjoint: 父类对象不能有多于一个型的子对象。
incomplete: 说明不是泛化中所有子元素都已说明，允许再增加其它子元素。
overlapping: 给定父类对象可有多于一个型的子对象，表示重载。
? 关联的约束
对关联有以下常用的约束：
implicit:该关联是概念性的，在对模型进行精化时不再用。
ordered:具有多重性的关联一端的对象是有序的。
changeable:关联对象之间的链(Link)是可变的（添加、修改、删除）。
addonly:可在任意时刻增加新的链接。
frozen:冻结已创建的对象，不能再添加、删除和修改它的链接。
xor: “或约束”，某时刻只有一个当前的关联实例。
关联类：OO建模的一个普遍问题是，当类之间具有多对多关系时，一些属性不能容易地放人任何一个类中。例如，下图所示的公司与员工的类关系。

4.3 对象建模过程
理解用例描述、识别类和类的属性、识别类的操作、确定类与类之间的关系、评审 4.3.1 识别分析类
分析类：分析类是概念层次上的内容；在功能需求分析过程中，描述系统较高层次的对象。
三种分析类：
? 边界类：描述与参与者直接打交道的对象，一般是一些UI界面
用于对系统外部环境与其内部运作直接的交互进行建模的类。
? 控制类：描述系统的行为，即系统做什么
用于对一个或几个用例所持有的控制行为进行建模的类。
? 实体类：描述系统的中的数据信息（有些数据是实体类，而有些是实体类的属性）
用于对必须存储的信息和相关行为进行描述的类。
边界类和实体类都对应于用例描述中的名词，而控制类对应于用例描述中的动词
识别对象的准则：搜寻准则、判别准则、检验准则

4.3.2 定义交互行为
识别类的操作的方法：建立对象之间的交互模型
主要手段：为每一个用例建立时序图（序列图、顺序图）
主要任务：分配控制类所代表的系统行为到各个前面所识别的系统类中（一般包括边界类、实体类、以及某些控制类）
顺序图：表达对象之间的基于时间的动态交互关系，着重体现对象间消息传递的时间顺序。
顺序图存在两个轴：
? 水平轴：表示不同的对象
? 垂直轴：表示时间
顺序图由对象、生命线、激活和消息等构成。

（时间线应为虚线）

2.1.1软件体系结构的建模工具：包
? 包（package）是一种逻辑分组手段，可以取UML模型中的任何一种事物，将相关成分聚在一起，以构成更高层的组织单元
? 最常用的方法是将类以包为单位进行分组，比如三层结构中的每一层中的所有类组成一个包
包图：包图用来描述包及其依赖关系，用来标识一个完整系统的主要部分
? 在包图中只使用两个符号：一个包的标识符，一个虚线箭头，虚线箭头表示依赖关系，箭头的尾部表示被依赖的包，头部是独立的包。
? 包依赖关系可以是直接的，也可以间接的，依赖关系可以传递;

三层架构的包图
? 每层对应一个包：用户界面包、业务处理包、数据访问包
? 再把各层中的一些公共部分提出来：权限管理包、异常处理包
2.1.2 硬件体系结构设计
? 指出系统中的类和对象涉及的具体程序或进程。
? 指明系统中配置的计算机和其他硬件设备。
? 指明系统中各种计算机和硬件设备如何进行相互连接。
? 明确不同代码文件之间的相互依赖关系。
硬件体系结构设计：部署图
? 并不是所有的系统都需要建立配置图，一个单机系统只需建立包图或构件图
2.2 详细设计
主要包括对象设计和对象持久化设计（数据库设计）
2.2.1 对象设计
对属性和操作进行建模
属性建模：确定属性的类型和数据结构、可见性等
操作建模：确定操作的可见性、参数、返回值、算法等
2.2.2 对象持久化设计
关注的是对象数据如何存储
对象持久化设计的方法：基于关系数据库存储
关系数据库与面向对象中的概念存在一定的对应
3.面向对象设计原则
? 单一职责原则
一个类只完成某一类功能(职责)；尽可能避免出现一个“复合”功能的类——在同一个类中完成多个不同的功能
? 开放-封闭原则
软件实体类(类、模块、函数等)应该是可以扩展、但是不可修改的
基本思想：不用修改原有类就能扩展一个类的行为
? 接口隔离原则
采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口更好
? Liskov替换原则
子类应当可以替换父类并出现在父类能够出现的任何地方
核心思想：子类型必须能够替换它们的基类型，该原则能够知道设计人员正确地进行类的继承与派生
? 依赖倒置原则
应用系统中的高层模块不应依赖于底层模块；抽象不应该依赖于细节实现，实现细节应该依赖于抽象
如何遵守设计原则：一些成熟的设计模式可以帮助我们解决实际问题，并且符合设计原则
4.设计模式
设计模式：描述一个在我们周围不断重复发生的问题，以及该问题的解决方案。
使用设计模式，我们就能一次一次地利用已有方案而不必做重复劳动。
? 广义上讲：设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。
? 狭义上讲：设计模式就是对特定问题的描述或解决方案，往往直接对应一段程序代码。
作用：记录和提炼了软件人员在面向对象软件设计中的成功经验和问题的解决方案，是系统可复用的基础。正确地使用设计模式，有助于快速开发出可复用的系统。
意义：优化的设计经验、极高的复用性、丰富的表达能力、极低的耦合度
设计模式的四个基本要素：
? 模式名称：一个助记名
? 问题：描述了应该在何时使用模式
? 解决方案：描述了设计的组成成分，解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象组合）来解决这个问题。
? 效果：描述了模式应用的效果及使用模式应权衡的问题。
GOF之23种设计模式：
? 创建型模式：创建型模式关注的是如何创建对象而不是直接实例化对象
抽象工厂模式、工厂方法模式、单例模式、建造者模式、原型模式
? 结构型模式：结构型模式关注的是如何将一组对象组合成更大的结构
适配器模式、外观模式、桥接模式、组合模式、装饰模式、享元模式、代理模式
? 行为型模式：行为型模式关注的是如何定义系统内对像间的通信，以及复杂程序中的流程控制
迭代器模式、观察者模式、策略模式、职责链模式、命令模式、解释器模式、中介者模式、备忘录模式、状态模式、模板方法模式、访问者模式

来源：Villin尼