面向对象技术与UML综合教程
目录
-
第一部分:面向对象思想核心
(图片来源网络,侵删)- 1 从面向过程到面向对象
- 2 面向对象的三大基本特性
- 3 面向对象的五大基本原则
- 4 为什么需要UML?
-
第二部分:UML基础
- 1 什么是UML?
- 2 UML的两种视图:结构图与行为图
- 3 UML图分类概览
-
第三部分:UML核心图详解(结构图)
- 1 类图 - 系统的静态蓝图
- 类的三要素:名称、属性、操作
- 关系:关联、聚合、组合、泛化、实现、依赖
- 2 对象图 - 类图的实例快照
- 3 组件图 - 物理层面的结构
- 4 部署图 - 系统的物理部署
- 1 类图 - 系统的静态蓝图
-
第四部分:UML核心图详解(行为图)
- 1 用例图 - 从用户视角看系统
参与者、用例、关系(包含、扩展、泛化)
(图片来源网络,侵删) - 2 序列图 - 描述对象间的交互顺序
生命线、激活框、消息
- 3 通信图 - 描述对象间的组织结构和消息
- 4 状态图 - 描述单个对象的生命周期
- 5 活动图 - 描述业务流程或算法逻辑
- 1 用例图 - 从用户视角看系统
-
第五部分:实战演练——在线书店系统设计
- 1 需求分析
- 2 绘制用例图
- 3 识别核心类,绘制类图
- 4 描述用户购买流程,绘制序列图
- 5 总结
-
第六部分:学习资源与工具推荐
第一部分:面向对象思想核心
1 从面向过程到面向对象
- 面向过程:以过程(函数)为中心,思考“第一步做什么,第二步做什么”,代码和数据是分离的,C语言,优点是性能高、流程清晰;缺点是数据和行为分离,代码重用性差,维护困难(牵一发而动全身)。
- 面向对象:以对象为中心,思考“谁来做”,将数据(属性)和操作数据的方法(行为)封装在一起,形成“对象”,对象之间通过消息进行交互,Java, C++, Python,优点是高内聚、低耦合,易于维护和扩展,代码重用性好。
核心思想:万物皆对象,程序是由多个相互协作的对象组成的。

2 面向对象的三大基本特性
-
封装:
- 定义:将对象的属性(数据)和操作(方法)捆绑在一起,形成一个独立的单元(对象),并尽可能对外部隐藏对象的内部细节,只暴露必要的接口(公共方法)供外部调用。
- 目的:保护对象内部数据不被随意修改,降低对象之间的耦合度,提高安全性。
- 比喻:就像一个电视机,你只需要通过遥控器(接口)就能换台、调音量,你不需要也不应该去拆开电视机的后盖去直接操作电路板(内部细节)。
-
继承:
- 定义:允许一个类(子类/派生类)继承另一个类(父类/基类)的属性和方法,子类可以复用父类的代码,并可以在此基础上添加新的功能或重写已有功能。
- 目的:实现代码的重用,并建立类之间的层次关系,体现了“is-a”(是一个)的关系。
- 比喻:“汽车”是一个父类,“轿车”和“卡车”是它的子类,轿车和卡车都继承了汽车的基本属性(如轮子、引擎)和行为(如行驶),但轿车有后备箱,卡车有货厢。
-
多态:
- 定义:指不同类的对象对同一消息(方法调用)做出不同的响应,简单说,同一接口,多种实现”。
- 目的:增加程序的灵活性和可扩展性,在运行时,系统会根据对象的实际类型来调用相应的方法。
- 前提:继承和重写(Override)。
- 比喻:你有一个“动物”的引用,它可以指向“狗”对象,也可以指向“猫”对象,当你调用这个引用的
makeSound()方法时,如果是狗对象,它会“汪汪叫”;如果是猫对象,它会“喵喵叫”。
3 面向对象的五大基本原则
- S - 单一职责原则:一个类只应该有一个引起它变化的原因,即一个类只负责一项职责。
- O - 开闭原则:软件实体应该对扩展开放,对修改关闭,即通过增加新代码来扩展功能,而不是修改已有代码。
- L - 里氏替换原则:子类必须能够替换其父类并出现在父类能够出现的任何地方。
- I - 接口隔离原则:客户端不应该依赖它不需要的接口,即使用多个专门的接口,而不是一个庞大的总接口。
- D - 依赖倒置原则:高层模块不应该依赖低层模块,两者都应该依赖其抽象,抽象不应该依赖细节,细节应该依赖抽象。
4 为什么需要UML?
UML(Unified Modeling Language,统一建模语言)不是一种编程语言,而是一种图形化建模语言。
- 沟通的桥梁:它为开发人员、产品经理、客户等所有项目相关人员提供了一种统一的、无歧义的“语言”,用于交流和讨论系统设计。
- 可视化的设计蓝图:将复杂的系统设计以直观的图形方式展现出来,帮助我们理清思路,发现设计中的问题。
- 文档化的工具:UML图是系统设计的重要文档,有助于项目的维护和交接。
第二部分:UML基础
1 什么是UML?
UML是一种用于软件系统建模的标准化图形语言,它不是过程,也不是方法,而是一种“语言”,你可以用它来描述任何面向对象的系统。
2 UML的两种视图:结构图与行为图
UML图可以从两个大的维度来划分:
- 结构图:描述系统静态结构的图,它展示了系统的构成要素(如类、组件、对象)以及它们之间的关系。
- 行为图:描述系统动态行为的图,它展示了系统在时间上的演进、对象之间的交互以及状态的变化。
3 UML图分类概览
| 类别 | 图名 | 描述 |
|---|---|---|
| 结构图 | 类图 | 描述系统中类的静态结构,包括类、接口、关联、继承等。 |
| 对象图 | 类图的实例,展示一组对象及其关系。 | |
| 组件图 | 描述系统物理组件的组织和依赖关系。 | |
| 部署图 | 描述软件组件在硬件节点上的部署情况。 | |
| 行为图 | 用例图 | 从用户视角描述系统功能,展示参与者与用例之间的关系。 |
| 序列图 | 按时间顺序描述对象之间消息交互的序列。 | |
| 通信图 | 描述对象间的组织结构和消息传递,强调对象间的连接。 | |
| 状态图 | 描述一个对象在其生命周期内所经历的各种状态以及状态之间的转换。 | |
| 活动图 | 描述业务流程、算法或操作步骤的流程,类似于流程图。 |
第三部分:UML核心图详解(结构图)
1 类图 - 系统的静态蓝图
类图是UML中最核心、最常用的图。
-
类的表示:一个类被表示为一个矩形框,分为三层:
- 名称层:类的名称,通常是顶部加粗。
- 属性层:类的属性(成员变量),格式为
可见性 名称: 类型 = 默认值。可见性: (public), (private), (protected), (package)。
- 操作层:类的方法(成员函数),格式为
可见性 名称(参数列表): 返回类型。
+---------------------+ | «interface» | | Drawable | +---------------------+ | + draw(): void | +---------------------+ -
关系:
- 关联:类与类之间的语义联系,用一条实线表示,可以是单向(带箭头)或双向(无箭头)。
- 聚合:弱“拥有”关系,部分可以独立于整体存在,用带空心菱形的实线表示。
- 组合:强“拥有”关系,部分和整体共存亡,用带实心菱形的实线表示。
- 泛化:继承关系,用一条带空心三角箭头的实线表示,箭头指向父类。
- 实现:类实现接口的关系,用一条带空心三角箭头的虚线表示,箭头指向接口。
- 依赖:一个类使用另一个类,用一条带箭头的虚线表示,箭头指向被依赖的类。
- 关联:类与类之间的语义联系,用一条实线表示,可以是单向(带箭头)或双向(无箭头)。
2 对象图
对象图是类图的实例,它展示了在某个特定时刻,系统中一组对象及其相互关系,它看起来和类图很像,但矩形框代表的是对象,并且对象名下会带有下划线。
3 组件图
组件图描述软件系统中物理上的组件(如JAR包、DLL文件、服务)以及它们之间的依赖关系,它关注的是系统的“装配”层面。
4 部署图
部署图描述软件组件如何部署到硬件节点(如服务器、PC、移动设备)上,它展示了系统的物理架构。
第四部分:UML核心图详解(行为图)
1 用例图 - 从用户视角看系统
用例图用于捕获系统的功能性需求。
- 元素:
- 参与者:与系统交互的外部实体,可以是用户、其他系统或硬件,用“小人”图标表示。
- 用例:系统提供的一个功能单元,为参与者创造可观测的价值,用椭圆形表示。
- 系统边界:方框,用来划分系统的范围,方框内是系统的用例。
- 关系:
- 关联:参与者和用例之间的关系,用实线连接。
- 包含:一个用例必须包含另一个用例,用带
<<include>>标记的虚线和空心箭头表示。 - 扩展:一个用例可以在特定条件下扩展另一个用例,用带
<<extend>>标记的虚线和空心箭头表示。
2 序列图 - 描述对象间的交互顺序
序列图按时间顺序展示了一系列对象之间的消息传递,它是描述一个场景(用例)如何实现的绝佳工具。
- 元素:
- 生命线:一条垂直的虚线,代表一个对象的存在时间。
- 激活框:一个小的矩形,画在生命线上,表示对象正在执行操作。
- 消息:对象之间的通信,用水平箭头表示。
- 同步消息:实线箭头,表示发送方需要等待接收方返回结果才能继续。
- 异步消息:开放箭头,表示发送方发送消息后无需等待,可以继续执行。
- 返回消息:虚线箭头,表示同步消息的返回。
3 通信图
通信图也叫协作图,它和序列图一样描述对象间的交互,但它更强调对象之间的组织结构(连接关系),而不是时间顺序,对象用矩形表示,它们之间的连接线表示关联,消息在线上标注,并带有序号来表示执行顺序。
4 状态图
状态图用于描述一个对象在其生命周期内所经历的各种状态以及状态之间的触发条件(事件)。
- 元素:
- 状态:用圆角矩形表示。
- 初始状态:一个实心圆,表示状态的起点。
- 最终状态:一个带实心圆的圆圈,表示状态的终点。
- 转换:带箭头的实线,连接两个状态,线上可以标注触发转换的事件和动作。
5 活动图
活动图是一种流程图,用于描述业务流程、工作流或算法逻辑,它非常适合用来建模复杂的操作流程。
- 元素:
- 动作/活动:圆角矩形,表示一个步骤。
- 决策节点:菱形,表示分支点。
- 合并节点:菱形,表示汇合点。
- 泳道:用水平或垂直的矩形区域划分,将活动分配给不同的参与者或部门。
第五部分:实战演练——在线书店系统设计
让我们设计一个简单的在线书店系统。
1 需求分析
- 用户:游客、注册用户、管理员。
- 功能:
- 游客可以浏览书籍、搜索书籍、注册。
- 注册用户可以浏览、搜索、下单购买、查看订单历史。
- 管理员可以管理书籍信息(增删改)、管理用户信息。
2 绘制用例图
-
参与者:游客、注册用户、管理员。
-
用例:
- 游客:浏览书籍、搜索书籍、注册。
- 注册用户:浏览书籍、搜索书籍、下单购买、查看订单历史。
- 管理员:管理书籍、管理用户。
-
关系:
- 注册用户是游客的泛化。
- “下单购买”和“查看订单历史”都包含了“用户登录”这个通用用例(为了简化,这里不画,但实际设计时需要)。
- “管理书籍”和“管理用户”是管理员的核心用例。
用例图草图:
+----------------+ +-----------------+ | 游客 | | 注册用户 | +----------------+ +-----------------+ | - 浏览书籍 | | - 浏览书籍 | | - 搜索书籍 | | - 搜索书籍 | | - 注册 |------| - 下单购买 | +----------------+ | - 查看订单历史 | +-----------------+ ^ | +----------------+ | | 管理员 |-------------+ +----------------+ | - 管理书籍 | | - 管理用户 | +----------------+
3 识别核心类,绘制类图
从用例和需求中,我们可以识别出以下核心类:
-
User(用户) -
Book(书) -
Order(订单) -
OrderItem(订单项,因为一本书可以在一个订单里买多本) -
类属性和方法:
User:userId,username,password,emaillogin(),register(),browseBooks(),placeOrder()
Book:bookId,title,author,price,stockgetDetails(),updateStock()
Order:orderId,orderDate,totalPrice,statuscalculateTotal(),addItem()
OrderItem:quantity,subTotalupdateQuantity()
-
类关系:
- 一个
User可以创建多个Order(一对多关联)。 - 一个
Order包含多个OrderItem(一对多组合,因为订单项的生命周期依附于订单)。 - 一个
OrderItem对应一本Book(多对一关联)。 OrderItem和Book之间是聚合关系,因为OrderItem需要Book的信息,但Book可以独立存在。
类图草图:
+-----------+ 1..* +-----------+ | User |<>-----------<>| Order | +-----------+ +-----------+ | - userId | | - orderId | | - username| | - date | | - ... | | - ... | +-----------+ +-----------+ | 1..* | 1..* | | | | 1..* | +-----------+ | | OrderItem | | +-----------+ | | - quantity| +------------------------------| - ... | | 1 | +-----------+ ^ | 1 | +-----------+ | Book | +-----------+ | - bookId | | - title | | - ... | +-----------+ - 一个
4 描述用户购买流程,绘制序列图
我们以“用户购买书籍”这个场景为例。
- 用户输入账号密码,点击登录。
- 系统验证用户信息。
- 用户浏览书籍列表,选择一本书加入购物车。
- 用户点击“结算”按钮。
- 系统创建一个新订单。
- 系统将购物车中的商品作为订单项添加到订单中。
- 系统计算订单总价。
- 系统显示订单详情给用户确认。
- 用户确认支付。
- 系统更新订单状态为“已支付”。
- 系统更新书籍的库存。
序列图草图:
用户 --> 认证模块: login(username, password)
认证模块 --> 用户: 返回登录成功/失败
用户 --> 购物车: addToCart(book)
用户 --> 订单系统: checkout()
订单系统 --> 订单: createOrder()
激活 [订单]
订单 --> 购物车: getItems()
激活 [购物车]
购物车 --> 订单: return items()
订单 --> 订单: calculateTotal()
订单 --> 库存系统: updateStock(bookId, -quantity)
库存系统 --> 订单: 返回更新结果
订单 --> 订单: setStatus("PAID")
订单 --> 用户: 显示订单确认信息
5 总结
通过以上步骤,我们从需求出发,用用例图明确了系统的功能边界和参与者,然后识别出核心类并绘制了类图来定义系统的静态结构,最后用序列图详细描述了一个核心业务流程的实现逻辑,这就是使用UML进行面向对象系统设计的一个典型流程。
第六部分:学习资源与工具推荐
学习资源
- 书籍:
- 《UML用户指南》:UML的“圣经”,全面但较厚重。
- 《UML精粹》:UML的快速入门和核心要点,非常适合初学者。
- 《设计模式:可复用面向对象软件的基础》(GoF):面向对象设计的经典之作,理解SOLID原则的必读书。
- 网站:
- UML.org:官方资源,标准定义。
- PlantUML Online:在线编辑器,可以边学边练。
- CSDN/博客园:搜索“UML教程”,有大量中文案例和讲解。
工具推荐
- IDE插件:
- Visual Paradigm for IntelliJ IDEA / Eclipse:功能强大的UML建模插件,支持代码与图双向同步。
- 在线工具:
- draw.io (diagrams.net):免费、开源、功能强大,支持多种图表,非常适合快速绘制草图。
- PlantUML Online:通过文本描述生成UML图,非常适合程序员,可以集成到代码仓库中。
- 专业桌面软件:
- Enterprise Architect (EA):功能非常全面的UML建模工具,但价格昂贵。
- StarUML:界面友好,性价比高,适合中小型项目。
