3.5软件开发活动[2-系统设计]面向对象设计-UML统一开发过程
1面向对象方法UML
1.1表达客观事物-8个术语，重点3州
类，不提供任何实例的类是抽象类
接口
用况
见表格
抽象类和接口的区别
抽象类和接口在编程中各自扮演着重要的角色，它们之间的主要区别体现在以下方面：
- 定义与实现：
- 抽象类是一个类，它可以包含普通方法和抽象方法，其中抽象方法必须被子类实现。抽象类是对类的抽象，它表示的是“这个对象是什么”。
- 接口是一组抽象方法的集合，它只包含抽象方法，没有具体实现。接口是对行为的抽象，它表示的是“这个对象能做什么”。
- 继承与实现：
- 子类只能继承一个抽象类，但可以实现多个接口。这意味着抽象类提供了更严格的继承关系，而接口则允许更灵活的组合。
- 抽象类中的方法可以是public、protected和default访问控制，而接口中的方法默认是public。
- 构造函数与变量：
- 抽象类可以有构造函数，而接口没有构造函数。抽象类中的构造函数不是用于创建对象，而是让子类调用这些构造器来完成属于抽象类的初始化工作。
- 抽象类可以有变量，包括普通成员变量和静态成员变量，而接口只能定义常量，即public static final类型的变量。
- 默认实现：
- 抽象类可以有普通方法的默认实现，而接口中的所有方法都没有默认实现。
- 抽象类中的抽象方法的访问类型可以是public、protected和默认类型，但接口中的抽象方法只能是public类型的，并且默认即为public abstract类型。
- 其他特性：
- 抽象类可以包含静态方法，而接口不能包含静态方法。
- 抽象类可以包含初始化块，而接口不包含初始化块。
总的来说，抽象类和接口在编程中各有其用途。抽象类更多地被用作系统中多个子类的共同父类，体现一种模板设计；而接口则通常作为系统与外界交互的窗口，体现一种规范。在设计和实现软件时，可以根据具体需求选择使用抽象类或接口。
1.2 表达事物的关系-4种关系
关联
继承
实现
依赖
1.3 建立模型，模型表达工具13种，重点4种
类图
用例图
状态图
顺序图
概述 | 术语 | 定义 | 符号 | 例子 |
支持抽象系统分析和设计中的事物 8个术语 | 类class | 一组具有相同属性、操作、关系和语义的对象的描述 对象是类的一个实例 |
| |
接口interface | 操作的集合，每个操作描述了类、构件或者子系统的一个服务 |
| ||
协作collaboration | 是一个交互，设计交互三要素：交互各方，交互方式和交互内容 |
| ||
用况use case | 对一组动作序列的描述，系统执行这些动作应产生对特定参与者有值的、可观察的结果 |
| ||
主动类active class | 一种至少具有一个进程或线程的类。能够启动系统的控制活动。 其对象的行为通常的与其他元素行为并发的。 |
| ||
构件component | 系统设计中的一种模块化部件，通过外部接口隐藏了它的内部实现 |
| ||
制品artifact | 制品是系统中包含物理信息的、可替代的物理部件 |
| ||
节点node | 是运行时存在的物理元素，表示具有记忆能力和处理能力的计算机资源。 一个构件可以驻留在一个节点中 |
| ||
模型元素之间的关系 4个术语 | 关联association | 对象之间某种方式发生联系
|
| 单向关联： 单向关联例子：考虑一个图书馆管理系统的例子，其中有两个类：Library（图书馆）和Book（书）。在这个系统中，图书馆拥有多本书，因此Library类可以将Book类作为其属性。 双向关联例子：考虑一个订单处理系统，其中有两个类：Customer（顾客）和Order（订单）。顾客可以创建订单，同时订单也需要知道是哪个顾客创建的。 队员效力于球队，球队选择队员 |
且部分可以离开整体而单独存在。 整体与部分生命周期不同。 |
| 聚合关联： 聚合关联例子：考虑一个大学管理系统的例子，其中有两个类：University（大学）和Department（系）。大学由多个系组成，但系可以独立于大学存在。、 考题： 飞机和发动机，是聚合关系 计算机系统由鼠标、显示器，键盘等组成。 | ||
|
| 组合关联例子：考虑一个汽车制造的例子，其中有两个类：Car（汽车）和Engine（发动机）。汽车包含一个发动机，并且发动机不能独立于汽车存在。 考题例子： 咖啡桌由桌面和桌腿 鸟由鸟腿和翅膀 | ||
泛化(继承) generalization | 一般性类目(父类)和特殊性类目(子类)之间的关系 is a is a kind of |
| 动物-鸟 守门员继承球员 前锋继承球员 | |
细化（实现） realization | 接口和实现它们的类之间 like a |
| 比如大雁要飞翔，就要实现飞的接口。 | |
依赖 dependent | 一种使用关系。use a 描述一个类目使用另外一个类目的信息或服务 一般而言，依赖关系在Java语言中体现为成员变量、局域变量、方法的形参、方法返回值 |
| 对于两个相对独立的对象，当一个对象负责构造另一个对象的实例， 或者依赖另一个对象的服务时， 这两个对象之间主要体现为依赖关系。 又分为三种情况： 1：当类A调用和实例化public的类B； 2：类B的实例是类A某个方法的一个局部变量； 3：当类B的实例是类A某个方法的一个入参。依赖关系应该是单向的。 动物类，依赖水和氧气 | |
建立概念模型和软件模型 13钟图形化工具，重点4种 | 类图 （包含类之间的关系） | 创建系统的结构模型，表达构成系统各成分之间的静态关系。 离开了类的关系，类模型至少一堆代表专业领域词汇的杂乱矩形方框。 |
| |
用况图 Use case | 确定系统的使用情况 创建有关系统的功能模型，表达功能结构。 从用户角度，是系统的一组使用场景。 每个场景 |
| ||
状态图 State 状态机图 状态表 | 创建系统的行为生产周期模型，表达系统的动态结构（描述了一个对象所处的可能状态以及状态之间的转换，并给出了状态序列的起点和终点） 显示一个状态机的图。 只对单个对象建立模型。 |
| ||
顺序图 Sequence Diagram 又称为时序图或序列图 | 一个对象和其他对象交互，时间维度。 创建系统的交互模型，表达系统对象之间的交互结构，给出对象如何协作的信息。 交互图，一组对象以及按时间序组织的对象之间的关系组成，还包括对象之间的消息。 |
|
|
考题，识别UML的关系
考题，识别是什么关系，飞机和发动机
考题，依赖关系-动物和氧气
面向对象方法-RUP
定义 | RUP是基于UML的一种过程框架，比较完整的定义了将用户需求转换为产品所需要的活动集，并提出了活动指南以及对产生相关文档的要求。 | |
突出特点 以用况为驱动的，以体系结构为中心的迭代，增量式开发。 | 以用况为驱动的 | 用况为基础，是分析，设计，实现和测试的输入。 |
以体系结构为中心 四个阶段： 初始阶段 细化阶段 构造阶段 移交阶段 | 5个模型描述体系结构： 用况模型 分析模型 设计模型 实现模型 部署模型 | |
增量式开发 | 每个阶段均： 需求获取 需求分析 设计 实现 测试 | |
需求获取 | 工作流和制品artifacts | |
需求分析 | 工作流和制品artifacts | |
设计 | 工作流和制品artifacts | |
实现 | 工作流和制品artifacts | |
测试 | 工作流和制品artifacts | |
RUP需求获取
RUP需求分析
RUP设计
RUP实现
RUP测试
RUP和系统架构的“4+1”视图 的关系
Philippe Kruchten提出的4+1视图方法
1995年，Philippe Kruchten在《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文，引起了业界的极大关注，并最终被RUP采纳。如图2所示。
最终用户关心的是系统的功能，因此会侧重于逻辑视图；
程序员关心的是系统的配置、装配等问题，因此会侧重于实现(开发)视图；
系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，因此会侧重于进程(处理)视图；
系统工程师关心的是系统的发布、安装、拓扑结构等问题，因此会侧重于部署(物理)视图。
分析人员和测试人员关心的是系统的行为，因此会侧重于用例(场景)视图；
原始论文描述 | |
逻辑视图Logical View | |
开发视图Development View | 实现(开发)视图； |
进程视图Process View | 进程(处理)视图； |
物理视图Physical View | 部署(物理)视图。 |
场景视图 Scenarios | 用例(场景)视图； |
