《面向对象技术与UML》课程教案Word格式.docx

《面向对象技术与UML》课程教案Word格式.docx

《《面向对象技术与UML》课程教案Word格式.docx》由会员分享，可在线阅读，更多相关《《面向对象技术与UML》课程教案Word格式.docx（96页珍藏版）》请在冰豆网上搜索。

教学参考书：

●《UML基础与ROSE建模案例》，吴建，人民邮电出版社，2007

●《Java与UML面向对象程序设计教程》，刘晓冬，清华大学出版社，2008

●《UML与系统分析设计》，张龙祥，人民邮电出版社，2007

●《软件工程》，钱乐秋，清华大学出版社，2007

教研室

审查意见

注：

表中（）选项请打“√”。

第一章面向对象的概念（4学时）

1.1章节目标（教学目的及要求）

1、解释面向对象的基本原则

2、定义面向对象的基本概念和相关的UML符号

3、展示面向对象的威力

4、列举一些基本UML建模符号

教学内容

1.1什么是UML？

统一建模语言（UML）是一种通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统工作文档。

它记录了与被建系统的有关决策和理解，可用于对系统的理解、设计、浏览、配置、维护以及控制系统的信息。

UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具，旨在统一以往建模技术的经验，吸收当今软件开发的最佳实践从而形成一种标准方法。

UML包括语义概念、表示方法和指导规范，提供了静态、动态、系统环境及组织结构的模型。

它可被交互式的可视化建模工具所支持，这些工具提供代码生成和报表生成。

UML标准并没有定义一种标准的开发过程，但它适用于迭代的开发过程。

它是为支持现今大部分面向对象的开发过程而设计的。

UML是一种语言；

是一种可视化的语言；

是一种可用于详细描述的语言；

是一种构造语言。

是一种文档化的语言；

主要用于软件密集型系统。

1.2软件工程最佳实践

●软件工程六个最佳实践（即DevelopIteratively迭代开发、ManageRequirements需求管理、UseComponentArchitectures组件架构、ModelVisually可视化建模（UML）、ContinuouslyVerifyQuality持续质量改进、ManageChange变更管理）

●与本课程相关三个最佳实践

对象技术帮助成就了以下行为：

1、迭代开发：

适应需求的变更、逐步加入对象元素和功能的可重用性；

2、使用组件为基础的结构：

结构化、组件为基础的开发；

3、可视化模型：

容易理解，修改简单。

1.3什么是对象技术？

什么是面向过程？

以算法和数据结构为核心，一段程序代码解决一个或几个问题。

什么是面向对象？

以客观存在的事物即对象为开发核心，在开发时以类作为对象的框架。

一种指导将语言、数据库和其他工具构造在一起的原则。

（注释：

面向对象是一种新兴的程序设计方法或开发范型paradigm，面向对象运用对象、类、继承、封装、消息等概念来进行程序设计。

其基本思想是，从现实世界中客观存在的事物及对象出发来构造软件系统，并在系统构造中尽可能运用人类的自然思维方式。

）

1.4什么是模型？

----模型是现实的简化。

模型提供了系统的蓝图。

1）什么是模型？

为什么要建模？

模型是对现实的简化。

建模是为了更好地理解正在开发的系统。

因为我们不能完整地理解一个复杂系统，所以我们要对它建模。

现实世界太复杂，我们的理解力有限。

建模一定会进行抽象和简化。

2）为什么要建模？

建模是为了产生对系统的理解。

可视化的理解是最为直观的理解。

对于复杂系统，只用一个模型是不够的，需要对系统拆分并使用多个相互关联的模型。

对于软件密集型系统，就需要一种语言，它贯穿于软件开发生命周期，并能表达系统体系结构的各种不同视图。

建模有四个目标：

----帮助我们可视化我们的系统；

----允许我们制定我们的系统的结构和行为；

----给我们一个构造系统的模板；

----记录我们所做的决定；

3）建模的原则：

●选择要创建什么模型，对如何动手解决问题以及如何形成解决方案，有着意义深远的影响。

●每一种模型你可以在不同的精度级别上表示。

●最好的模型适于现实相联系的。

●单个模型是不充分的。

对每个重要的系统最好用一组几乎独立的模型去处理。

1.5什么是对象？

----通常一个对象代表一个实体，不管它是物理实体、概念实体还是软件实体。

----一个对象是具有明确界限并封装了状态和行为的统一体。

----状态主要表现为属性和关联。

----行为主要表现为操作、方法和状态机。

1.6什么是模板类型？

----根据模板类型中的其他元素定义一个新的元素。

Stereotype构造型：

属于UML扩展机制之一，它允许用户基于已存在的构造块创建新的适应于用户特定问题的构造块。

1.7面向对象的基本原则

----抽象

区别其他实体最本质的特征。

----封装

向调用者隐藏了内部（封装），调用者只能依赖接口实现调用。

----模块

将复杂的整体分割成可以控制的小块，以帮助人们理解复杂的系统。

----继承

任何等级或排序都可以以树形结构表示。

1.8什么是类？

类就是一系列（某一类）对象共享相同属性、操作、关联和语义描述。

对象是类的实例。

1.9什么是属性

属性是类中具有名词特性的参数，属性描述了实例中可取值的范围。

1.10什么是操作

操作能被任何类的实例调用执行、并完成某项实现的功能。

1.11什么是多态？

使用同一接口隐藏了不同的实现。

●多态（Polymorphism）在希腊语中意味着“拥有多种形式”。

●如绘图，图形可以是矩形、圆或曲线，等等。

投资，可以是股票、债券或基金，等等。

●一个接口可能有很多实现，但每一种实现都必须满足接口参数要求。

●有时，一个实现也可以满足多个基本需求接口。

如一个控制器能够控制任何符合这个控制其接口规范的电视机。

多态意味着用同一个名字来引用不同的方法。

JAVA中提供两种形式的多态：

第一种可以通过子类对父类方法的覆盖来实现运行时对态；

第二种利用方法重载在同一个类中定义多个同名（但参数不同）的方法，实现编译时多态。

1.12什么是接口？

1、接口的定义与作用：

1）接口是用来描述类或组件提供的操作的集合。

2）接口正规化了多态。

接口消除了多态的神秘性。

3）接口支持“即插即用”的结构。

2、接口的表示方法：

1）“棒棒糖”表示法（表示接口的存在）

2）“类/模板”表示法（表示接口的详情）

1.13什么是包？

《UML用户手册》：

包package是“对元素进行分组的通用机制”。

包是分组的通常手法，包可以包含其它模型元素。

包可作为管理单元，使模型条理化。

包是简单的分组机制，没有语义上的实例。

所以包就没有必要一定要需要实现，除非它表示一个目录。

1.14什么是子系统？

1）子系统的定义和作用：

子系统是包（包含其他模型元素）和类（拥有行为）的结合。

实现定义在行为中的一个或多个接口。

子系统是“提供了一些特定行为的一组元素”。

2）子系统组件：

组件是设计的物理实现。

子系统能够表示设计中的一个组件。

1.15什么是组件（构件）？

在一个定义良好的系统框架中，宏观的、可以替换的、独立的系统功能。

组件可以是：

源代码组件、实时运行组件、可被执行的组件。

《UML用户手册》component组件：

系统中遵从一组接口并提供其实现的物理的、可替换的部分。

1.16什么是关联？

《UML用户手册》关联association：

是一种结构关系，它指明一个事物的对象到另一个事物的对象间的联系。

两个或多个类的对象之间的联系。

一种结构化的联系，制定了一个对象到另外一个对象的连接。

1.17什么是多重性？

一定数量的某个类的实例对应另外一个类的实例的数量的范围。

《UML用户手册》multiplicity多重性：

对集合可能采用技术范围的说明。

1.18集合是什么？

《UML用户手册》Aggregation聚合：

关联的一种特殊形式，它表示聚集（整体）和构件（部分）之间的“整体-部分”关系。

《UML用户手册》组合compstion：

聚合的一种形式，整体和部件之间具有很强的拥有关系和一致的生存期。

1.19什么导航？

《UML用户手册》Navigation导航：

给定两个类之间的一个简单的、未加修饰的关联，从一个类的对象能够导航到另一个类的对象。

除非另有指定，否则关联的导航是双向的。

在图形上，把一个关联画成一条实线，它可能有方向，偶尔还在其上有一个标记，而且它经常还含有诸如多重性和角色名这样的修饰。

UML有四种关系：

依赖、关联、泛化、实现。

《UML用户手册》Dependency依赖：

两个事物之间的语义关系，其中一个事物（独立事物）的改编将影响到另一个事物（依赖事物）。

在图形上，把一个依赖画成一条可能有方向的虚线，偶尔还在其上有一个标记。

1.20什么是一般化（泛化）？

它们之间是这样的关系：

一个类（子类）共享另外一个类（父类）的结构或者行为。

一个子类能够从一个（单继承）或者多个（多继承）父类继承。

《UML用户手册》generalization泛化：

一般/特殊关系，其中特殊元素（子类）的对象可以替换一般元素（父类）的对象。

一般化（泛化）就是从子类中提取共性而形成父类；

继承则是子类在承接父类的职责和本质（属于共性的关健的属性、操作和关联）的同时，将会产生属于自己的、特殊的个性。

1.21什么是实现？

《UML用户手册》realization实现：

类元之间的一种语义关系，其中一个类元描述一个规格说明，另一个类元保证实现这个规格说明。

在两种地方要遇到实现关系：

一种是在接口和实现它们的类或构件之间；

另一种是在用况和实现它们的协作之间。

提示是什么？

在图像上增加一种注释可以包含更多的信息。

1.22本章小结

1、面向对象的四个最基本原则是什么？

分别简短阐明一下。

2、对象的概念是什么？

类的概念是什么？

他们的区别是什么？

3、属性的概念是什么？

4、操作的概念是什么？

5、多态的概念是什么？

6、什么是包？

7、什么是子系统？

子系统怎么和包能够关联起来？

又怎么和类关联起来？

8、UML语言中有那几种类关系？

他们的定义分别是什么？

9、阐明面向对象的效果。

10、什么是模板类型？

第二章需求概述

（1）（4学时）

教授方式：

讲课讨论

2.1章节目标（教学目的及要求）

1、描述了需求中使用的基本概念以及需求对分析和设计产生的影响。

2、展示了作为分析和设计起点的需求产出品的阅读以及解释方法。

2.2需求概述的内容

（1）简要介绍

1、需求概述的内容

（1）

􀂃

简要介绍

核心概念

用例模型

术语表

补充说明

检查点列举

2、需求工作的目标包含:

●提供一种与客户在系统功能方面进行沟通并达成共识的方式

●使开发者能够更准确的理解系统的需求

●确定系统的边界

●提供了对迭代过程中的技术内容进行计划的基础。

●为系统开发的成本估计提供一个基础

●定义出系统与用户之间的交互接口（交互界面—确定用户的需求和目的）

●USDP：

统一软件开发过程

3、需求的产出:

●用例模型：

角色；

用例；

用例描述。

●术语表

●补充说明

2.3需求概述的内容

（2）核心概念

1、需求概述的内容

（2）

2、系统行为是什么？

系统行为是系统的活动和对输入进行的响应方式

–外界可见的并且可以测试的系统活动

系统行为可以使用用例进行描述

–用例描述了系统，环境以及系统和环境之间存在的关系。

3、用例建模中的核心概念

角色表示与系统交互的任何事物（可以是人—用户、也可以是其他系统或设备）

用例表示系统执行的一系列动作。

这些动作产生对某一角色可见的结果。

2.4需求概述的内容（3）用例模型

1、需求概述的内容（3）

2、用例模型是什么？

用例描述了系统的功能需求

模型化表示了系统的功能（用例）和系统的环境（角色）。

3、用例模型的优点是什么？

交流

在系统开发早期就可以明确最后提交产品的功能；

确保双方都对需求有准确的了解。

标识

确定系统与用户群之间的接口需求。

验证

确保开发团队已完全理解了客户需求。

识别与系统交互的角色；

界定系统边界和功能；

确保即将开的发系统是用户所期望。

4、用例描述

用例名称

概述

事件流

关系

活动图

用例图

特殊需求

前置条件

后置条件

其他图

4、用例事件流

一个正常的基本的路径

多个可选的路径

–正常的可选路径

–罕见的可选路径

–异常路径

5、场景是什么？

场景是用例的一个实例。

6、活动图是什么？

用例模型中的活动图用来描述用例中发生的活动。

活动图必须是一个流程图，需要能够描述清楚系统的活动流程以及分支的时机。

7、事件流

当注册管理员要求关闭注册时，这个用例开始执行。

1）首先系统检查注册用例是否在执行。

如果正在执行，一条消息应该显示给用户，并且用例结束。

如果注册活动在执行，“关闭注册”的活动是无法进行的。

2）对于每个课程，系统需要检查是否有一位教授已经申请教授，并且至少有三个学生选该门课。

只有这两个条件都满足的话，系统才能够提交这门课以安排课程表。

2.5需求概述的内容（4）术语表

1、需求概述的内容（4）

词汇表

1、词汇表实例：

1）选课系统词汇表介绍

这个文档定义并解释了问题域中专有的名词，这些解释可以帮助那些对问题领域不太熟悉的用例描述和其他项目文档的阅读者。

通常情况下，这个文档可以作为一个非正式的数据字典，用来记录数据的定义。

这样可以让用例的描述文档和项目的其他文档能够将注意力更加集中到系统的功能上。

2）词汇定义

词汇表定义了选课系统中的核心概念。

2-1）课程:

学校提供的课程。

2-2）开设课程：

一个学期中学校开设的课程--在一个学期中这将会有若干相同的课程并行开授，你可以在其中选择一个学习。

时间的选择需要视课程提供的时间而定。

2-3）课程总表:

大学所教授的所有课程的列表

2.6需求概述的内容（5）补充说明

功能

可用性

稳定性

性能

可维护性

设计约束

2.7需求概述的内容（6）检查点列举

1、检查点列举:

需求:

用例模型描述的容易理解吗？

通过研究用例模型，一位客户或开发者可以清楚的了解系统的功能和这些功能之间的联系吗？

客户所有的需要都被满足了吗？

用例模型包含有一些多余的行为吗？

每个用例模型是否都分配到合适的包集合中了？

2、检查点列举:

角色

所有的角色都被识别出了吗？

每个角色是否均发生了至少一个用例？

每个角色的职能是否单一？

角色之间是否需要进一步的拆分和合并？

是否存在两个角色，在与同一用例交互时行使着相同的职能？

角色的名称是否直观且含义清晰？

用户和客户对名称的含义的理解是否一致？

3、检查点列举:

用例

是否每个用例都至少涉及到了一个角色？

是否每个用例都和其他用例是独立的？

是否有些用例中存在着类似的行为或事件流？

每个用例的名字都是唯一，直观并且意义足够明确以免在以后阶段发生混淆吗？

是否客户和系统的用户对用例的名称和描述理解相同？

4、检查点列表:

用例描述

用例的执行者是否明确？

用例执行的目的是否明确？

用例简述是否正确描述了用例的功能

用例事件流开始和结束的时机和方式是否明确

角色和用例之间的交互序列是否满足了用户的期望？

角色交互和信息交换是否明确？

是否有用例过于复杂？

5、检查点列表:

每一个词汇的定义是否全是清晰和精确的？

每一个词汇是否都被使用在了某个用例的描述中？

在角色和用例的描述中，每个词汇的含义是否一致？

2.8本章小结

本章小结：

需求总结

需求的主要产出是什么？

需求的产出有什么用途？

用例模型是什么？

角色是什么？

用例是什么？

列举出用例属性的一些例子

用例和场景有何不同？

附加说明是什么？

包含什么内容？

词汇表是什么？

第三章分析和设计概述

3.1章节目标

1、理解分析和设计的核心术语、概念；

2、了解分析和设计的实际过程，包括角色、工件和工作流程；

3、解释分析和设计的差异。

3.2特定情景下的分析和设计

分析和设计的目的是：

●将需求转化为系统设计

●使系统具有更加健壮的架构

●是设计和实现环境相匹配，做性能设计

●商务规则为系统结构提供场景

●需求规则为分析和设计提供了基本输入

●测试规则测试了在分析和设计阶段的系统

●环境规则发展和维护了在分析阶段使用的工件

●管理原则规划整个项目和每一次迭代（迭代项目中）。

3.3分析和设计概述

●输入：

USE-CASE模型（角色、用例、用例描述）、术语表和附加规范（补充说明）。

●产出：

设计模型（作为源代码抽象的模型）

●展开：

设计活动围绕架构的概念展开。

架构优先：

其可行性和正确性是早期设计迭代周期的主要关注点。

通过抽象忽略其细节，展现其主要特征使之具体化。

架构不仅为了开发好的设计模型，还将提高实现过程的质量。

架构由架构文档记录。

●架构文档不在这次课程范围，但我们会讨论其内容及如何解释。

3.4分析和设计综述

（1）核心概念

●从定义分析和设计工作流程的核心术语及概念开始。

1、分析和设计对比（参看幻灯片）

●关注点不同：

分析和设计的差别在于关注点和侧重点。

●分析的目标：

理解问题并建立一个可视化的分析模型，而不去考虑实现的技术细节。

分析关注于把功能需求转化为软件中的概念，目的是得到系统中的对象，侧重于行为的封装。

以便尽快转入设计及其他阶段。

●设计的目标：

细化分析模型，开发一个设计模型，以便迅速过渡到编码阶段。

在设计中，我们必须适应实现环境和分布环境。

实现环境是开发者必须满足的环境，它是分布环境中软件的超集和硬件的子集。

●建模的目标：

从一个和现实世界紧密类似的对象模型出发，找出更为普遍的解决方法。

由此而创建模拟现实世界的模型，更为强大、能更简单地解决问题。

2、分析和设计并不是由下而上或由上而下的

●分析和设计并不是由下而上或由上而下的。

●用例从左侧进入并定义一个中间层：

分析类。

●定义的子系统移动到上部，定义的设计类移动到下部。

●分析可以是上到中、中到上、下到上地移动。

不能说哪一个路径更重要，而是必须覆盖所有的路径以保证系统的正确性。

●所有四种路径同等重要，这就是由上到下或由下到上无法解决问题的原因。

3、什么是架构？

●架构Architecture（体系结构）：

一组关于下述问题的重要决定：

软件系统的组织方式，构成系统的模型元素和它们接口的选择，以及由这些模型元素之间的协作所描述的行为；

这些结构元素和行为元素如何进一步组成较大的系统，以及指导这种组织（这些元素和它们的接口、协作和组合）的结构风格。

软件体系结构不仅关注结构和行为，也关注使用关系、功能性、性能、弹性、复用、可理解性、经济和技术约束与折中以及审美考虑。

●软件架构包含：

组成系统的结构元素和它们的接口；

元素协作的特定行为；

将结构元素和行为元素结合成一个大的子系统；

体系结构风格支配了组织结构。

●架构可以是静态的也可以是动态的。

●相同系统的架构应该是类似的（已用过的特殊类型）：

体系结构=元素+形式+基本原理。

●基本原理决定一个好架构的核心部分。

●模式是将元素聚合为某种形式的指导方针。

4、架构约束设计和实现

●架构包括一套整体设计的结论、规则或者设计约束和结构的模式。

●架构结论是最底层的结论，改变它将带来巨大的影响。

●架构可以被看作一套核心设计结论的集合。

●架构是对系统的最初限制，这些限制往往也是最重要的。

他们组成了软件设计的最基础的结论。

●架构为设计提供了一个框架，因此架构也被称作战略式的设计。

●一个系统架构师的工作就是消除非必须的工作。

随着对代码的越发接近，这些工作就会被除去（架构限制着设计、设计限制着实现）。

这样做是非常有用的，因为在实现过程中，我们可以增加其他方面（例如，提高质量和性能）的工作。

5、软件架构：

“4+1视图”模型

●上面的图表说明了Rational公司用来描述软件架构的模型。

●不同的组织对架构有不同的看法。

在一个指定的项目中，通常有许多投资人，他们对姚开发的系统都有它们自己的看法。

我们的目标是为这些不同的投资人提供一个系统来满足他们所关心的，而忽略一些其他的细节。

●为了满足这些不同的需求，Rational公司定义了“4+1视图”模型。

一个架构视图是对系统从特殊观点或者优势来进行简单描述（或抽象），覆盖特定的关注点，并忽略与这个关联联系不紧密的实体。

视图是模型的“片段”，而不是所有的系统都需要所有的视图（例如，单一处理器：

舍弃分布视图；

单一进程：

舍弃过程视图；

小程序：

舍弃实现视图等）。

●一些项目可以记录所有这些视图，或者附加一些视图。

具体视图的数量依赖所开发的系统。

●这些视图中的每一个，以及用来代表他们的UML符号，将在以后的章节讨论。

3.5分析和设计综述

（2）分析和设计工作流程

●仅仅由开发者、活动和工件并不能组成一个进程。

我们需要一种描述活动的方法，一些有价值的结果，以及开发者之间的交互结果。

工作流程是一个活动序列，而且可以产生能够看得见的价值。

●在UML术语中，工作流程可以