《软件工程》教案06 面向对象分析与设计.docx

《软件工程》教案06 面向对象分析与设计.docx

《《软件工程》教案06 面向对象分析与设计.docx》由会员分享，可在线阅读，更多相关《《软件工程》教案06 面向对象分析与设计.docx（17页珍藏版）》请在冰豆网上搜索。

《软件工程》教案06面向对象分析与设计

山东轻工业学院

教师授课教案

课程名称：

软件工程

课程代码：

0310040

学分：

3

课程类别：

选修课

开课单位:

信息科学与技术学院

授课班级：

计科07-12

授课教师：

赵培英

山东轻工业学院教务处制

授课时间

2009年10月30日星期五第34节

2009年11月4日星期三第34节

2009年11月6日星期五第34节

2009年11月13日星期五第34节

授课内容概要

第六章面向对象分析与设计

第一节面向对象的基本概念（对象，类，继承，信息，多态，动态绑定。

）

第二节面向对象分析与设计过程（OOA的任务、步骤及过程，OOD步骤、过程，设计模式。

）

第三节UML概述（UML各种视图与图的对应，UML各种图的简介。

）

第四节用例建模（利用用例、用例图实现功能建模。

）

第五节静态建模（利用类图和对象图实现静态建模。

）

第六节动态建模（利用状态图、顺序图等实现动态建模。

）

第七节物理体系结构建模（构件图、部署图的使用。

）

目的要求

✧了解设计模式、UML视图与图的对应，了解构件图、部署图；

✧掌握OOA的任务、步骤及过程，OOD步骤、过程；

✧熟练掌握面向对象的基本概念，掌握面向对象建模方法。

重

点

✧面向对象的基本概念；

✧类图、对象图、状态图、用例图的使用；

✧建立对象模型、动态模型、功能模型的基本步骤。

难

点

✧建立对象模型、动态模型、功能模型的基本步骤。

作业布置

1.列举并简要说明OO的基本概念？

2.OOA的步骤？

OOD步骤？

3.什么是用例？

什么是执行者？

4.结合课本实例说明创建用例模型的步骤？

参考书

1.《软件工程》钱乐秋等清华大学出版社

2.软件工程导论（第四版），张海藩主编，清华大学出版社，2003年。

3.面向对象与经典软件工程（第5版）（英文影印版），（美）StephenR.Schach主编，机械工业出版社，2002年。

课型

理论课

学

时

分

配

复习

5分钟

主要教具

多媒体

讲授

35分钟

教学方法

多媒体课件

指导

2分钟

教学手段

讲授结合实例

总结

3分钟

备注

授课：

双周周三34，每周周五34，轻化B507

答疑：

每周四78节，机电C415

学时分配：

指本章节每节课（45分钟）的平均分配情况

授课内容

备注

复习及引言

讲授新课

第一节面向对象的基本概念

面向对象=对象（object）+分类（classification）+继承（inheritance）

+通过消息的通信（communicationwithmessages）

1、对象（object）：

对象是指一组属性以及这组属性上的专用操作的封装体。

属性（attribute）通常是一些数据。

对象的属性值，表示该对象的状态。

操作（operation）（也称方法或服务）规定了对象的行为，表示对象所能提供的服务。

封装（encapsulation）是一种信息隐蔽技术。

2.类（class）：

又称对象类，是一组具有相同属性和相同操作的对象的集合。

3.继承（inheritance）：

基于层次关系的类共享数据和操作的一种机制。

父类中定义了子类的公共属性和操作。

子类中除了定义自己特有的属性和操作外，可以继承其父类（或祖先类）的属性和操作，还可以父类（或祖先类）中的操作重新定义其实现方法（重载）。

分单重继承和多重继承。

抽象类（abstractclass）：

没有实例的类称为抽象类。

在抽象类中可以定义抽象操作，指：

只定义这个类的操作接口，不定义它的实现，其实现部分由其子类定义。

4.消息（message）：

对象间通信的手段。

5.多态性（polymorphism）：

指同一个操作作用于不同的对象上可以有不同的解释，并产生不同的执行结果。

6.动态绑定（dynamicbinding）：

运行时才将消息所请求的操作与实现该操作的方法连接起来。

第二节面向对象的分析和设计过程

一、面向对象的分析OOA（Object-OrientedAnalysis）

（一）OOA过程

1.获取客户基本需求

常采用用例来收集客户需求：

Ø首先标识执行者（actor）。

（与用户不同）

Ø执行者的每一个使用场景（或功能）称为一个用例，所有用例构成系统的完整需求。

2.标识类和对象：

类和对象来自问题领域。

可采取CRC技术。

3.定义类的结构和层次

类的结构主要有两种：

复习：

引出：

Ø一般—特殊结构（generalization—specialization）反映类间的一般与特殊关系，即“isa”关系。

可形成类层次结构。

Ø整体—部分结构（whole—part）反映类间的整体与部分关系。

是一种“hasa”关系。

整体—部分结构也具有层次结构。

主题（subject）或子系统（subsystem）：

互相协作以完成一组紧密结合在一起的责任的类的集合。

实际上是系统更高抽象层次上的一种描述。

4. 建造对象——关系模型：

描述系统静态结构。

指出类间的关系：

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

5.建立对象——行为模型：

描述了系统的动态行为。

步骤如下：

Ø评估所有的用例，以完全理解系统中交互的序列。

Ø标识驱动交互序列的事件，理解这些事件如何和特定的对象相关联。

Ø为每个用例创建事件轨迹（eventtrace）。

Ø建造状态机图。

Ø复审。

（二）OOA模型

1、基本模型：

一个类图（classdiagram）。

以直观的方式表达系统最重要的信息。

分三个层次（对象层、特征层、关系层）分别描述了：

系统中应设哪几类对象，每类对象的内部构成，对象与外部的关系。

2、补充模型

Ø主题图画出了系统的主题。

Ø交互图（interactiondiagram）是Usecase与系统成分之间的对照图。

3、详细说明：

对分析模型进行说明和解释。

主要以文字为主。

二、面向对象设计OOD（Object-OrientedDesign）

将分析模型转换为设计模型，解决“如何作”的问题。

（一）面向对象设计准则

1）模块化2）抽象3）信息隐藏

4）弱耦合5）强内聚6）可重用

（二）面向对象设计的主要内容

Ø1）设计问题域组元

Ø2）设计人机交互组元

Ø3）设计任务管理组元

Ø4）设计数据管理组元

OOD的一般步骤

Ø系统设计:

将分析模型划分为若干子系统，子系统应该具有良好的接口，子系统内的类相互协作。

标识问题本身的并发性，为子系统分配处理器。

并选择设计策略和设计控制机制。

Ø对象设计:

为每个类的属性和操作进行详细设计，包括它们的数据结构和实现算法。

Ø消息设计：

设计连接类与它的协作者之间的消息规约（specificationofthemessages）。

Ø复审

（四）OOD模型

三、设计模式（designpatterns）

帮助设计者复用以前成功的设计。

一个设计模式通常可用四个信息来描述：

1）模式名:

应具实际含义，反映模式的适用性和意图。

2）使模式可被应用所必须存在的环境和条件。

3）设计模式的特征:

指出一些设计的属性，调整这些属性使该模式能适应各种不同的问题。

4）应用设计模式的结果（consequences）:

表明设计决策的走向。

第三节UML概述

•UML（UnifiedModelingLanguage）一种基于面向对象的可视化的通用建模语言。

•UML的主要组成

Ø视图（Views）:

观察角度

Ø图（Diagrams）

Ø模型元素（Modelelements）

Ø元模型及扩展机制

一、UML2.0的视图与图

二、模型元素

模型元素代表OO中的对象、类等基本概念以及模型元素间相互连接的关系。

三、元模型及扩展机制

Ø元模型：

用于描述建模语言自身，用于表示注释，模型元素的语义等信息。

Ø扩展机制（Extensibilitymechanisms）：

Ø剖面机制允许在不修改基础元模型前提下，对UML进行扩展

Ø包括3个扩展结构：

构造型（Stereotype）、标记值（Taggedvalue）和约束（Constraint）

第四节用例建模

Ø通过开发者和客户之间为导出需求规约而进行的交互过程来建立用例模型。

Ø用例模型通过用例图来描述。

一、用例图的组成及符号

Ø用例图给出了用户所感受到的系统行为。

其主要成分：

用例、执行者和系统。

Ø每个用例指明了一个完整的功能。

二、用例建模步骤

Ø定义系统

Ø确定执行者

Ø确定用例

Ø描述用例（普通正文，或活动图）

Ø定义用例间的关系（关联、扩展、包含、泛化）

Ø确认模型

（一）确定执行者

Ø可以通过回答下列问题来确定执行者：

Ø谁使用系统的主要功能（主执行者）？

Ø谁需要从系统中得到对他们日常工作的支持？

Ø谁需要维护、管理和维持系统的日常运行（副执行者）？

Ø系统需要控制哪些硬件设备？

Ø系统需要与哪些其它系统交互？

Ø哪些人或哪些系统对系统产生的结果（值）感兴趣？

（二）确定用例

可以通过让每个执行者回答以下问题来寻找用例：

Ø执行者需要系统提供哪些功能？

执行者需要做什么？

Ø执行者是否需要读、创建、删除、修改或储存系统中的某类信息？

Ø执行者是否要被系统中的事件提醒，或者执行者是否要提醒系统中某些事情？

从功能观点看，这些事件表示什么？

Ø执行者的日常工作是否因为系统的新功能（尤其是目前尚未自动化的功能）而被简化或提高了效率？

另外还有一些不是目前的执行者回答的问题：

（三）用例描述

Ø通常用正文来描述,也可用活动图来描述。

Ø用例的正文描述应包括以下内容：

Ø用例的目的：

用例的最终目的是什么？

它试图达到什么？

Ø用例是如何启动的：

哪个执行者在什么情况下启动用例的执行？

Ø执行者和用例之间的消息流：

用例与执行者之间交换什么消息或事件来通知对方改变或恢复信息？

描述系统与执行者之间的主消息流是什么？

以及系统中哪些实体被使用或修改？

Ø用例中可供选择的流：

用例中的活动可根据条件或异常（exception）有选择地执行。

Ø如何通过给执行者一个值来结束用例：

描述何时可认为用例已结束.

Ø用例的简要描述

Ø订购货物：

客户创建一个新的请求商品的订单，并为那些商品付费

Ø取消订单：

客户取消一个已经存在的订单

Ø用例的详细描述模版

Ø用例名称

Ø参与的执行者

Ø前置条件和后置条件：

表示用例开始和结束的条件

Ø事件流（flowofevents）：

事件流是一系列陈述句，它是从执行者的角度看，列出用例的各个步骤。

事件流可分为两部分：

基本路径，可选路径。

基本路径是运转正常时的路径，是一系列没有分支和选择的简单陈述句。

可选路径是指不同于基本路径而允许不同的事件序列的路径。

对于明显有可能随时发生的事情来说，可选路径非常有效

Ø用例描述中可以包含条件、分支和循环。

Ø其他需求：

在用例中还可描述一些特殊的需求，这些需求常常是非功能性需求，如可用性、安全性、可维护性、负载、性能、自动防故障、数据需求等。

（四）、确定用例之间的关系

（五）实例

第五节静态建模（类和对象建模）

类和对象模型描述了系统的静态结构，在UML中用类图和对象图来表示。

类和对象模型的基本模型元素:

类、对象以及它们之间的关系。

一、类图和对象图的图形记号

二、确定类－CRC技术

CRC技术：

类—责任—协作者（class—responsibility—collaborator）技术。

（一）CRC卡片

CRC实际上是一组表示类的索引卡片

每张卡片分成三部分，它们分别描述类名、类的责任和类的协作者。

（二）CRC技术标识类的步骤

1.  标识类

（1）标识潜在的对象类：

陈述中的名词或名词短语

（2）筛选对象类，确定最终对象类

2.标识责任

责任是与类相关的属性和操作。

（1）  标识属性

（2）定义操作

3.标识协作者

协作标识了类间的关系。

如果一个对象为了完成某个责任需要向其它对象发送消息，则我们说该对象和另一对象协作。

4.复审CRC卡

复审应由客户和软件分析员参加。

复审方法：

三、表示类之间的关系

1.  关联

（1）二元关联

关联的两端可加上重数（multiplicity），表示该类有多少个对象可与对方的一个对象关联

（2）多元关联

三个或三个以上的类之间可以互相关联

（3）受限关联（qualifiedassociation）：

用于一对多或多对多的关联。

限定符用来区分关联“多”端的对象集合，指明了在关联“多”端的某个特殊对象

（4）聚集和组合

聚集（aggregation）是表示整体一部分关系的一种关联，它的“部分”对象可以是任意“整体”对象的一部分。

组合（composition）：

一种更强形式的关联，代表整体的组合对象有管理它的部分对象的特有责任。

组合关联具有强的物主身份，即“整体”对象拥有“部分”对象，“部分”对象生存在“整体”对象中。

（5）关联类：

UML中可以把关联定义成类，该关联的每个链都是这个类的实例

（6）导航性（navigability）

2.  泛化

•类间的“一般—特殊关系”（is-a）

Ø一般类定义公共属性和操作

Ø对一般类扩展一些属性和/或操作后，可以特化（specialize）成特殊类

Ø特殊类可以继承一般类的属性和操作

Ø一般类是特殊类的父类，特殊类是一般类的子类

Ø子类可以定义自己的属性和操作，也可重新定义父类中的操作，但重新定义的操作必须与父类具有相同的操作特征（signature）

3.实现：

Ø实现关系将一个模型元素（如类）连接到另一个模型元素（如接口），后者（如接口）是行为的规约，前者是后者的实现。

Ø泛化和实现的关系

4.依赖：

Ø依赖指出两个或多个模型元素之间语义上的关系。

它表示被依赖元素的变化会要求或指示依赖元素的改变。

5．约束和派生（constraint&derivation）

Ø约束：

是用自然语言或特定的形式语言正文表示的语义条件或限制。

用“｛正文字符串｝”形式表示。

约束可以附加到任何模型元素上。

Ø派生：

是一个元素与另一个元素之间的关系，前者能通过后者计算得到。

计算派生元素的公式可以用约束给出。

派生元素的表示：

元素名前加斜线。

6．模板（Templates）

模板是一个参数化的模型元素，使用它时参数必须在建模时绑定到实际值。

第六节动态建模

用来描述系统的动态行为，显示对象在系统运行期间不同时刻的动态交互。

UML中用状态机图、活动图、顺序图、通信图和协作图来建立动态模型。

1．状态机图

Ø状态机图描述了对象的动态行为，是一种对象生存周期的模型。

Ø状态机图的基本符号

Ø画状态机图的步骤

2．活动图

Ø一种特殊形式的状态机，用于对计算流程和工作流建模。

Ø活动图使用状态机图的符号表示，活动图中的状态称为动作状态，用圆角矩形表示，动作状态之间的迁移用箭头表示，迁移上可以附加警戒条件、发送子句和动作表达式。

Ø与状态机图不同的是，活动图中动作状态之间的迁移不是靠事件触发的，当动作状态中的活动完成时迁移就被触发。

3．顺序图

Ø顺序图用来描述对象间的交互行为，它关注于消息的顺序。

Ø顺序图还揭示了一个特定场景的交互，即系统执行期间发生在某时间点的对象之间的特定交互。

它适合于描述实时系统中的时间特性和时间约束。

Ø顺序图有两个坐标，垂直坐标表示时间（从上到下），水平坐标表示一组对象（用对象框表示）。

Ø顺序图中对象框下可画一垂直的虚线，称为该对象的生存线（lifeline），用来指出该对象执行期间的时序。

Ø对象之间的消息发送用生存线之间的消息箭头表示。

当一个对象接收到一个消息时，该对象开始活动，称为激活。

激活画成对象生存线上的一个长方形框，表示该对象可能在执行自己的代码，可能在等待另一对象的返回。

Ø按垂直坐标从上到下的次序读顺序图，可以观察到随时间的前进消息通信的顺序。

4．通信图

Ø通信图展示了围绕着组合结构的各部分或协作的各角色而组织的一种交互。

Ø通信图对包含在交互中的角色和链（link）建模，角色与对象绑定，链与对象间的关联绑定，用附加到关联上的箭头表示角色之间的消息通信。

同一进程中的所有消息是顺序排列的，不同进程中的消息可以是并发的，也可以是顺序的。

第七节物理体系结构建模

描述系统各部分的结构、接口以及它们用于通信的机制。

UML中物理体系结构用构件图、内部结构图和部署图来描述。

1．构件图

Ø显示了系统中的构件及其依赖关系。

Ø构件是系统设计的模块化部分，它给出一组外部的接口，而隐藏了它的实现。

Ø构件的内部结构用内部结构图定义

2．部署图

Ø描述了处理器、设备和软件构件运行时的体系结构。

基本元素：

结点、连接、构件、依赖等。

小结及作业