uml完整教案

UML 与软件建模备课教案
1绪论[教学目的]
本部分是《UML 与软件建模》课程的开篇部分讲述，需要首先阐明什么是软件建模。

为此需要引入一些软件工程课程的内容让学生对软件开发生命周期有所理解，通过SDLC 的介绍让学生知道在软件的生命周期中有着不同的软件开发模型，模型的表达需要一套约定俗成的规范，这就是现代软件工程中广泛使用的UML 图形建模。

[教学重点]
软件开发生命周期（SDLC ）
需求分析与设计阶段的区别与联系
几种迭代/增量模型的不同侧重特点与联系UML 与ROSE 、RUP 的关系[教学难点]
用例驱动、测试驱动的含义[教学方法]
传统软件开发过程与现代软件开发过程的优劣进行对比适当举例告诫学生需求规约的重要性[教学内容]
一、SDLC（软件开发生命周期）
1、计划阶段：
也就是可行性研究阶段，可行性主要是技术可行性和经济可行性，在技术角度来看的技术可行性容易理解，但经济可行性也不可忽视。

可研实际上分为甲方（即需求方）的可研和乙方（供应方）的可研，两者对此的侧重点有所不同。

2、开发阶段：
分为需求分析阶段和设计阶段。

前者系统分析员深入充分的理解用户需求，
明确“做什么”，并以一定规范的格式记录下用户的需求形成需求规约；后者以需求规约为基础将需求细化为描述处理进程和算法的伪代码，确定软件的体系结构和模块划分，以一定规范的格式记录下它们形成设计规约。

3、实现阶段：
分为编码/编程和测试两个阶段。

前者要遵守设计规约定义的体系结构、模块划分等要求，以可在需求规约定义的运行环境下运行的程序实现需求规约定义的需求，并以一定规范形成编码文档；后者按照需求规约的要求尽可能多的寻找出没有实现的以及错误的实现，并形成一定规范的测试文档。

注意通过举例说明甲乙方可行性研究的侧重点不同以及紧密相联系。

举例说明功能性需求与非功能性需求的区别。

本部分重
点要理解分析与设计的不同与联系。

编码与设计的融合、测试先行、自动化测试、独立存
在。

绪论
4、运行维护阶段：
交付给用户使用，一般需对用户进行操作培训，并对未发现的软件错误及时更正，以及应客户要求加入软件的新特性新功能。

二、软件开发过程模型
1、瀑布模型（Waterfall Model）
以上一项活动的结果为输入；该项活动的工作成果作为输出传给下一项活动；逐级评审，未通过则返回前项活动甚至更前项活动。

2、迭代模型（Iterative Model）
将一个软件系统的整个开发过程划分为不同的迭代周期，每个迭代周期都是对系统的连续扩充和细化。

每个迭代周期都包含分析、设计、编码、测试这些阶段。

迭代模型有不同的变型，但都是增量与迭代的结合，没有本质不同，分为以下几种：
2.1、快速原型模型（Rapid Prototype Model）
最初做界面设计，不断推出模块的实现补充到原有的原型中。

2.2、螺旋模型（Spiral Model）
划分为四个象限，不断测试和集成,同时加入了风险分析，对每个迭代周期和每个阶段的风险进行预先评估，在迭代的每次初期对风险较大的进行先行的“穿刺”。

2.3、RUP 统一过程（Rational Unified Process）
用例(Use Case)驱动；以体系结构(Architecture)为中心；迭代(Iterative)
与增量(Incremental)相结合；与UML 一起，成为事实上的软件行业标准，
使用Rational Rose 实施；是适合较大公司和中大型项目实施的重型过程。

2.4、XP 极限编程（eXtreme Programming）
不是编程，而是一种软件开发过程模型，借鉴了RUP，可看成是RUP 的简化和轻型化。

适合中小型组织用于开发需求快速变化的软件项目，是一种轻量型过程方法。

迭代周期很小，强调持续集成和自动化集成与测试；测试驱动、结对编程、集体拥有；是个快速灵活的轻型化过程。

相当于售后服务和交货前给用户试用
提宝贵意见。

可维护性日益成为评价软件质量的最重要
的指标。

要学生理解在初期
迭代中应尽量选择难度大和相对复杂的部分做实现以降
低项目开发风险。

分问题域分析阶段、需求分析阶段、构造阶段和交付阶段介绍rose 在RUP 不同阶段中的应
用。

理解测试驱动与结队编程、集体拥有的好处。

UML与软件建模备课教案[本章小结]
1、SDLC是软件开发过程中任务的阶段划分，而不简单就是对时间阶段的
划分。

2、瀑布模型虽然有逐级评审反馈，但对SDLC各任务阶段的时间安排是顺
序模型，不存在迭代或认为其迭代周期太长，难以适应变化，风险大。

3、迭代/增量模型提供了渐进实现的手段，灵活性强，每次迭代都完整经
历SDLC的各任务阶段。

2理解面向对象[教学目的]
本周是《UML 与软件建模》课程的第二部分内容，第二部分内容拟安排三周到四周时间对面向对象技术进行剖析和展开，培养建立学生对面向对象思想具有较为深刻的认识。

为此首先温习类的引入，对象的概念定义以及类的识别的过程。

然后展开类/对象间的关系（聚合、继承）以及两类多态性。

最后对类/对象间的通信消息机制、面向对象思想的基本原则以及面向对象与面向功能的区别与联系进行阐述。

[教学重点]继承
两类多态性
聚合
消息机制
面向对象的基本原则
面向功能与面向对象的区别与联系[教学难点]
继承与赋值兼容性
运行时绑定的动态多态性理解消息机制[教学方法]
程序举例、启发式提问一起温习面向对象程序设计课程中的内容。

[教学内容]
一、类、类的识别、类图
1、对象
现实世界存在或能想像到的一切个体事物，是名词性和个体的概念，一个对象就是类的一个实例。

2、类
它是一批对象所具有的共同的共性特征，是名词性和总称的概念。

类和对象是一般与个别、共性与个性、普遍与特殊、泛化与具体的关系。

3、类的成员（组成）
由属性和操作构成，属性描述该类事物“有意义”的特征，名词；操作描述该类事物的“有意义”的行为，动词。

4、属性与类
在一具体情景下某名词有记录下来的必要但是没有操作联系时可“弱化”为一个类的属性。

以程序举例和一次作业结合让学生理解动态绑定和静态绑定。

一切事物，当我们思考它，把它作为思考和观察的对象
时，它就是我们考察的一个对象。

对象是类的一个实
例（实际例子）。

没有必要记录记忆下来的名词淘汰出
类的候选集。

“有意义”记录但无操作时“弱化”
为属性。

5、类图/对象图
类名/对象名，属性名、操作名三段组成。

6、类的识别方法过程
建立目标问题域的顶层业务描述文字。

将顶层业务描述文字分为不同顶层用例－一个个完整的行为过程描述。

从各个不同顶层用例的文字描述中得到名词构成的类的候选集。

从各顶层用例中识别出参与者、实体类，并可能需要添加一些控制类。

将与一个类密切相关的名词变为其属性成员－该成员可以是一个聚合类；更多的情形是该名词是一个弱化了的类，直接做普通属性成员。

根据“谁知道谁负责”的原则将“有意义的行为”加入到“知道”的那个类成为其操作成员。

二、继承
继承是重要的复用手段，使个别可以扩展一般，理解了IS-A 关系，就理解了赋值兼容性规则的来源。

三、类/对象的聚合
1、一个类包含另一个类，或者说一个对象包含另一个对象，包含者和被包含者（聚合类和被聚合类）之间也称之为“Has A”关系。

2、两个类关联时，就发生了聚合。

有强聚合（组成）和弱聚合（形参或指针关联时）的两类聚合。

强聚合
四、多态性（两类多态性）
注意无名对象或匿名对象的图的画法。

以课本篮球比赛的例子来说明从业务
描述文字和启发式提问做动名词划分得到类候选集的方法，继而运用“谁
知道谁负责”的原则最终得到初步类
图。

强聚合天然就是一
个对象成员，弱聚
合仅在发生实形参传递时建立了一种
依赖关系——不是对象生存期一直存在，也很短暂程序
可控其持久性的。

硬盘显卡显示器
应用软件
hardware :硬件
科学计算()
1、编译时绑定的静态多态性
函数重载和模板（包括类模板，函数模板）是编译时绑定的静态多态性类型——编译时进行代码参数类型检查和代码转换
2、运行时绑定的动态多态性
C++语言中virtual 关键字来提醒编译器在编译时不要对成员函数的调用进行绑定，而是推迟到运行时再说，也称为run at time 或just in time，
是编译器的一种发展方向。

绑定来自于因为“binding”，对于aobj.f()编译器一般会认为是调用aobj 对象的f 方法，也就是在编译时编译器对这句源代码进行转换，指示当运行时去调用aobj 对象内存单元的f 方法而不是其它。

3、重载、覆盖、隐藏的区分
重载（overloading）发生在一个类的内部，成员函数被重载的特征：（1）相同的范围（在同一个类）；（2）函数名字相同；（3）参数不同；
覆盖（overriding）发生在两个类之间（基类和派生类），基类virtual 成员函数，被派生类覆盖改写的条件特征：
函数模板实质通过函数重载来实现。

模板函数间就是函数重载关系
这里会进行一次作业和一次作业习题课的讲授，让学生体会面向对象思想的精髓，即多态性的好处。

覆盖带来的动态多态性是面向对象思
想的精髓这部分内容在第三部分的教案中一个
一个自动化养猪场的例子。

class Base
{
public;//或者protected:
virtual void run();//virtual 表示它是动态联编，即运行时编译。

}
class Derived:public Base {
override virtual void run();/*
1、override 关键字（覆盖）可以省略；
2、派生类定义的函数必须和基类中声明完全完全一样；
3、virtual 的虚函数动态绑定特性被派生类的覆盖改写成员函数继承保持。

*/}
int main(){
Base b;Derived d;Base *p=&b;p->run();p=&d;p->run();}
覆盖程序举例
（1）不同的范围
（2）函数原型完全相同（也成函数声明或函数签名相同）；
（3）基类必须是virtual标识的虚成员函数；隐藏是指派生类的同名函数覆盖了基类的继承下来的函数，如果仍需要访问基类的该成员函数，使用基类名::函数名()。

（1）如果派生类的函数与基类的函数同名，但是参数不同（不论有无virtual 关键字），基类的函数将被隐藏（注意别与重载混淆）。

（2）如果派生类的函数与基类的函数同名，并且参数也相同，但是基类函数没有virtual关键字。

此时，基类的函数被隐藏（注意别与覆盖混淆）。

class Base
{
public:
void f(int x);
};
class Derived:public Base
{
public:
void f(char*str);
};
隐藏程序举例
五、消息机制
面向对象思想中的消息
对象A调用对象B的GetData()函数，用UML的术语来说，就是对象A向对象B发送了一个GetData消息，函数的参数就是消息的参数。

在一个进程内部，发送消息就是调用对方对象公开（Public）的一个成员函数。

Windows操作系统的消息
在Windows系统和各种支持图形用户界面的GUI操作系统中，应用程序使用向一个窗口发送消息的办法来相互通信，接收到消息的窗口负责处理该消息的动作。

由于Windows对进程地址空间的保护，进程间不能直接调用对方的功能函数，因此需要借助操作系统的消息通信机制。

LRESULT SendMessage(//同步发送消息的函数
HWND hwnd,//接收窗口句柄
UINT Msg,//消息类型，可自定义
WPARAM wParam,//消息参数，下同
LPARAM lParam
);
发送异步消息的PostMessage()的形式参数完全相同，同步异步就是指发
送消息者（请求服务的客户机）是否等待服务完毕才继续下一步。

进程A 实际上先发往的是操作系统，操作系统将该消息放到进程B 的消息循环（消息泵）
Windows 操作系统中进程A 向进程B 发送消息步骤一：
Windows 操作系统中进程A 向进程B 发送消息步骤二：
为什么需要异步消息？
（1）多任务操作系统中为了提高效率：
消息队列是个循环，进程B 取出其一个先到达的消息处理后应尽快继续后面的消息处理，而不可以被一个任务长期独占。

（2）同一个进程内部避免（函数）重入：
重入：一个函数没有调入完成退出前又被调用了一次，类似于函数的递归调用。

若对象A 在其消息处理函数中需要向对象B 发一个消息，然后B 在处理中又向C 发送了一个消息，C 在处理时又向A 发送消息，这样形成了对A
联系DOS 系统，DOS 的不可重入就是说21号中断不可重
入。

一般中断处理程序都是很快处理就返回，如果需要
长时间的处理，就存在重入的风险。

的某函数的递归调用。

由于消息处理函数都是简单的处理，没有所谓的为被递归调用而设计的递归出口，结果造成无限递归，数据混乱和系统崩溃。

回调：就是定义好的一个函数不是被显式的调用，而是被操作系统自动调用，一般用于需要操作系统中转的消息处理函数或需要异步服务的场合。

六、面向对象思想的基本原则
开闭原则：一个模块对扩展应是开放的，对修改应是关闭的。

完全替换原则：派生类应该能完全替换掉基类（接口定义）。

依赖倒置原则：依赖于抽象，而不要依赖于具象。

非循环依赖原则：包与包之间不能有循环依赖关系。

只实现你真正需要的东西，不要去实现你认为需要的东西。

不要重复自己：出现三次重复的地方，都应该重构。

保持简化设计。

强调可读性：为人写代码，而不是为机器写代码。

七、面向功能与面向对象的区别与联系
面向功能是从使用功能出发，特别针对数据，也称以数据为中心；面向对象指从对象的现实世界模拟出发，通过用例图和业务描述文字，找出与现实世界对应的合适的在计算机模型模拟的类，继而把所有的功能描述为对象/类之间的关联来提供。

八、软件复用技术
软件复用的层次（不同的粒度上不同的复用级别和抽象层次）软件复用的两种现代主流技术（框架与类库）九、面向对象的开发过程
分为：面向对象分析（OOA）——分析模型；面向对象设计（OOD）——系统模型；面向对象编码（OOP）——实现的系统。

[本部分小结]
1、动态多态性结合了继承和虚函数技术，可以实现不变应对万变。

2、件复用技术中，在细粒度上，多态性是精华技术，在OO 的发展大潮中，
静态多态性中的模板技术应用方兴未艾。

辅以设计模式，是未来的应用和研究热点。

3、理解消息机制的原理，就理解了操作部署的原则。

4、面向对象的开发过程，是一个从外部窥视其功能到内部理解其实现的过程。

下一个部分内容将联系一个养猪场的计算机模拟来说明面向对象思想的初步应用。

注意对接口的理解。

3Rational Rose基本视图
[教学目的]
本周是《UML与软件建模》课程的第三部分内容，第三部分拟安排二周到三周时间，主要是做一个实际的分析静态建模。

要求学生从自己较为熟悉的领域出发做一个完整例子的类识别、用例图、初步类图、细化类图的过程，为下一步顺序图动态建模做好准备。

[教学重点]
UML面向对象分析的一般过程
用例图、用例、参与者
问题域
用例间关系－关联
[教学难点]
参与者
问题域
以不变应万变——多态性举例
[教学方法]
启发式提问，现实举例分析。

[教学内容]
一、UML面向对象分析的一般过程
面向对象分析首要任务是识别用户需求，并用合适的模型工具记录下来，最终得到分析模型。

首先需要了解、熟悉用户业务的领域问题，通常需要和用户进行广泛而深入的交流，了解他们真正想要的东西是什么。

抓住问题域的本质对于分析来说是最重要的任务，如果从一开始就错误的理解了用户的需求，最终开发出来的软件必将无法让用户满意。

需求的捕获可通过由用户写一段介绍性描述（纯文字、表格或一系列图形）、分析员对用户提问的回答等。

分析员应整理识别的结果，确定问题域和给出一段简要、具有概括性的系统问题域描述。

UML的用例模型一直被推荐为识别和捕获需求的首选工具，在分析员对于问题域知识整理的基础上，以用例模型图形形式确定系统系统的边界、主要功能和活动。

用例描述的是对用户可见功能的使用，并不分析功能的实现。

在描述问题域时的很多用例并不需要进一步的分析，但如果该用例是用户的需求，就必须进行用例分析，这就是问题域的实质和系统边界的划分要点。

顺序图、写作图和活动图是进行用例分析的工具，用例分析的目的不是实现或者设计用例，而是要尽量找出那些直接反映问题域本质和用户需求的活动和功能。

UML的静态建模机制包括用例图、类(对象)图，以及包图、组件图和
部署图。

用例图和类图是分析阶段的最主要的模型元素。

二、用例图（use case diagram）、用例（用况，use case）、参与者等
用例图由用例、参与者（角色，actor）、关联（association）组成。

用例描述使用的例子，从使用者角度出发，外部窥测系统应有的使用方式和功能特点，并且为测试验收提供了最可靠和简单的驱动方法。

用例定义为由系统执行的一个动作序列，并能产生可观察的结果值给某个特定的角色。

用例具有三个特征：
用例由某个角色直接或间接来启动执行，当一个用例被启动执行时，伴随着某些事件发生。

要么增加一个角色启动某个用例，要么删除用例。

用例必须把执行结果反馈给角色。

用例在功能上具有完整性，每个用例必须从输入开始，直至产生结果值给某个角色，否则不成为用例。

用例完整的描述系统的功能使用，包括执行过程中可能产生的诸多变化、错误和异常情况。

用例执行的一个具体特定情况，称之为场景(scenario)。

如果把用例看成完整描述系统功能使用的类，场景就是用例的一个实例。

用例的某种传参数值后的实例化就是某个具体场景，其包含了相关角色的实例化。

参与者是发起用况最可能的起点，也是分析员与用户交流的起点。

角色以在系统中存在的身份来划分，可能是一个用户，但不同于用户，一个用户可能有多种角色。

例如保险公司经理，在系统不同的用例场景中可能分别是管理者、审计者和投保客户三种重要角色之一；角色更可以不是人，可以是任意的外部系统；不同的系统边界，参与者(角色)会完全不同。

识别用例的方法使用启发式提问，其目的是为了识别出类和为测试提供方法：
某个角色要求系统为其提供什么功能？该角色要做哪些职责工作？角色需要读取、创建、删除、更新或者存储系统中的某些信息吗？系统中的事件需要告知角色吗？角色需要告诉系统一些什么信息吗？系统需要什么样的输入/输出?输入来自哪里？输出去往哪里？
该系统当前存在哪些主要问题是有待开发成计算机自动化处理的？由上可以看出，其实用例和角色，是一起交互发现和分析的，问题域的系统边界就在角色与用例交互的中间处。

四、用例间关系－关联的一般形式和几种特殊形式：依赖、泛化、包含、扩展。

关联：是最普通和普遍的表达两个实体间关系的UML 元素，由于stereotype 可自定义，因此关联可以替代其它更专用的UML 图形元素。

一个用例可以是另一个用例的直接启动者(最终的启动者一定是某个角色)，它们用带方向的关联箭头表示。

以两个实例来说明参与者的识别与系
统边界的关系。

用例间的一般关联：表达启动
关联的某种弱化－依赖：虚线箭头，即依赖，也可以表达用例间的通信关系，发送请求或者启动下一个用例处理过程，都可以看成是上一个用例依赖下一个用例提供服务。

用例间关联－泛化：一个用例可以类似于类的继承一样进行具体化细
化，多种不同派生继承意味着不同的实现细节。

可以使用泛化线
（generalization ）表达这种继承关系，也可以使用通用的关联符号加上<<realize>>这种构造型来表示一种具体实现。

用例间的关联：泛化（继承）
更常见的，是依赖线仅用于表达间接
的包之间因为某个模块而具有的依赖关系。

查读者借阅记录
读者
查读者借阅记录
读者
读者自助查找书目
工作人员查找书目
查找书目
用例间关联－包含与扩展：包含关系——某子用例是一个功能执行过程而被另一个抽象级别更高的包含调用；扩展关系，表示一个过程可能执行也可能不被调用执行，依赖于一定条件（扩展点）；包含可理解成一个用例被另一个用例启动，所以可简单使用关联（略）；也可理解成被包含方是基类，包含方是派生类而使用泛化；扩展也可使用关联表达一种功能的可能扩展，也可理解成泛化扩展了基类。

不论使用哪种图形元素表达，注意扩展和包含的箭头方向不一样。

用例间的关联：包含与扩展
五、以不变应万变——多态性举例。

多态性在C++语言中主要表现为函数重载和虚函数继承两种形式，即编译时静态绑定的多态性和运行时绑定的动态多态性。

这里以上课时讲述的面向对象养猪场为例阐释动态多态性对软件体系结构带来的好处为例说明（以静态多态性函数重载或模板的例子说明也可以）
工作()
吃()
吃()
版本二
[本部分小结]
1、用例图是面向对象分析图形建模的第一步，在此前需要分析员先给
出一段顶层的业务描述文字——该描述文字从和用户进行初步沟通而来。

2、深刻领会系统边界或问题域的正确理解。

只有正确的划分了系统边
界，才能正确的找出问题域中的用例，和与问题域交互的参与者。

3、关联线是最普通的表达用例间或任何对象间关系的图形元素，对不
同的场合，可能会具体使用它的某种变形。

4、面向对象的开发过程，是一个从外部窥视其功能到内部理解其实现
的过程。

抽象出一个基类也
就是猪接口类，这
样调用方的工作函
数可以简化为只使
用基类类型的形参
类型。

4Rational Rose 基本视图动态建模（顺序图、协作图）[教学目的]
本周是《UML 与软件建模》课程的第四部分内容，第四部分拟安排三周时间，主要是利用实验对第三部分静态建模的部分做细化处理，利用顺序图对关键用例和不清楚细节的用例做细化分析来完成详细类图——系统的体系结构图，最终完成面向对象方法的对系统分析建模部分。

[教学重点]顺序图
use case view 中用例图与logical view 中类图间存在的思维迭代关系顺序图[教学难点]
消息的进一步部署（grasp 原则）[教学方法]
实验举例，给出一个完整的进销存系统的分析建模实例。

[教学内容]
一、简单图形元素类、包、注释：
方法操作
参与者、用例：
用例
参与者。