多媒体第三讲时序图

多媒体课件第三讲课件时序图第一页，共二十五页，2022年，8月28日课程学习的内容OO设计原则UML设计图及RoseRational工具OO设计模式典型项目的分析与设计第二页，共二十五页，2022年，8月28日学习方法掌握主要OO原则的原理和应用要点改变java编程习惯学会设计Rational工具的使用；掌握类图、用例图、顺序图、活动图的设计熟练掌握MVC设计方法熟练掌握数据库编程深化了解API，深化基于API的编程反复实践典型模式应用于项目的分析和设计第三页，共二十五页，2022年，8月28日参考书面向对象软件工程与UML,李飞跃,人民邮电出版社(高职教材）UML与软件建模,徐宝文,清华大学出版社（重点大学教材）面向对象设计原理与模式，（美)DaleSkrien著，清华大学出版社（国外经典教材)Java设计模式,耿祥义,清华大学出版社大话设计模式，程杰，清华大学出版社第四页，共二十五页，2022年，8月28日考核基于典型项目的考察:项目的分析与方案设计UML典型图项目代码中基本原则的应用项目设计中模型的使用第五页，共二十五页，2022年，8月28日OOP编程要点

OOP追求的目标：可用性、完整性、健壮性、有效性、可伸缩性、可读性、可重用性、简洁性、可维护性、可扩充行OOP典型特点：封装性、继承性、重载、属性和修饰符、多态、重构、抽象类接口、集合、泛型、委托与事件第六页，共二十五页，2022年，8月28日实现一个最简单的实例计算立体型几何体体积要点:分析其中的耦合性、程序的复用性“脏代码”分析第七页，共二十五页，2022年，8月28日OO基本原则单一职责原则要点:…开-闭原则依赖倒转原则里氏替换原则面向抽象原则多用组合少用继承原则迪米特原则高内聚/低耦合原则合成/聚集复用原则接口隔离原则第八页，共二十五页，2022年，8月28日单一职责原则(SRP原则)就一个类而言，应该只有一个引起它变化的原因；失败的案例：界面处理类+数据库操作+文件读写+业务流程控制类比：多功能手机、集成主板的电脑—坏一处就全坏经验：类的设计倾向于越小越好解释:如果一个类承担的职责过多，就等于把这些职责耦合在一起。一个职责的变化可能会引起消弱或抑制这个类完成其他职责的功能。这种耦合会导致脆弱的设计。当变化发生时，设计会遭到意想不到的破坏。第九页，共二十五页，2022年，8月28日开-闭原则（核心原则）软件实体(类、模块、方法）应该可以扩展，但不可以修改；换个说法:类对扩展是开放的,对修改是封闭的;用extends和implements等开放，用private封闭实际使用：1.随时准备修改：改变是合理的；2.原来的代码一般不要改动，合理的方法是基于原先的代码产生新的类3.设计之初就准备好应对变化，用抽象来隔离变化，减少耦合。第十页，共二十五页，2022年，8月28日开-闭原则的运用:写一个相对固定的内核;不断产生新的类，当修改发生时；新的类给予接口或抽象类创建；理解:面向接口编程第十一页，共二十五页，2022年，8月28日里氏替换原则子类型必须能替换掉它们的父类型分析：“企鹅不是鸟”––子类型必须包含父类型的全部特征

第十二页，共二十五页，2022年，8月28日依赖倒转原则抽象不应该依赖于细节，细节应该依赖于抽象；----针对接口编程，不要对实现编程解释：1.高层类不应该依赖低层类；两者都应依赖于抽象；2.抽象不应该依赖细节；细节应该依赖抽象反转实例:电话指挥修电脑，谁依赖谁？抽象与实现：电脑主板-总线插槽-PIC卡的实例—抽象不依赖细节，细节依赖抽象。第十三页，共二十五页，2022年，8月28日依赖止于接口--用接口消除强耦合AB依赖AB依赖I依赖用接口消除强耦合第十四页，共二十五页，2022年，8月28日OO的基本原则89、面向对象的基本设计原则

1)LSP(TheLiskovSubstitutionPrinciple):Liskov替换原则

子类不能添加任何父类没有的附加约束。子类对象必须可以替换基类对象。

在可能的情况下，由抽象类(接口)继承。

抽象类与具体类

只要有可能，不要从具体类继承；

行为集中的方向是向上的(抽象类)；

数据集中的方向是向下的(具体类)。

2)OCP(TheOpen-ClosePrinciple):开放-封闭原则

对于扩展是开放的(Openforextension)

对于更改是封闭的(Closedformodification)

关键在于抽象

抽象预见了可能的所有扩展(闭)

由抽象可以随时导出新的类(开)

OCP是OOD中很多说法的核心。

LSP是OCP成为可能的主要原则之一。

3)SRP单一职责原则(TheSingleResponsibilityPrinciple)

一个类，应该仅有一个引起它变化的原因。

体现了内聚性(Cohesion)：一个模块的组成元素之间的功能相关性。

违反SRP原则会带来物理依赖的缺点。

使得每个类仅有一个职责。

4)ISP接口隔离原则(TheInterfaceSegregationPrinciple)

客户应该仅知道所需要要的接口。

一个类实现多个接口，避免“肥接口(fatinterface)”

使用委托分离接口,Adapter模式;使用多重继承分离接口。

本质：

使用多个专门的接口比使用单一的接口好。

一个类对另一个类的依赖性应当是建立在最小的接口上的。

避免接口污染(InterfacePollution)

5)DIP依赖倒置原则(TheDependencyInversionPrinciple)

高层模块不依赖于低层模块，二者都依赖于抽象。

抽象不应该依赖于细节，细节应该依赖于抽象。

针对接口编程，而不是针对实现编程。

Booch：所有结构良好面向对象架构都具有清晰地层次定义，每个层次通过一个定义良好的、受控的接口向外提供了一组类聚的服务。

6)启发式原则

依赖于抽象——依赖关系都应终止于抽象类或者接口。

任何变量都不应该拥有指向具体类的指针或者引用。

任何类都不应该从具体类派生。

任何方法都不应该改写其任何基类中已经实现的方法。

第十五页，共二十五页，2022年，8月28日UML中的类图类图中的6种关系1.继承(泛化)关系;2.实现关系;3.依赖关系;4.关联关系;5.组合关系6.聚合关系;基本画法:1.指向实体的关系用实线；指向虚体（接口和抽象类）的关系用虚拟线；2.箭头指向时间上先定义的类

第十六页，共二十五页，2022年，8月28日UML图第十七页，共二十五页，2022年，8月28日类图第十八页，共二十五页，2022年，8月28日案例分析好友管理系统中的类图分析好友管理系统中消息传送过程分析--登录过程分析--查询过程分析--增加过程过程第十九页，共二十五页，2022年，8月28日序列图—系统的动态过程分析时序图时序图展示了几个对象之间的动态交互关系。它主要是用来显示对象之间发送消息的顺序，它还显示了对象之间的交互，即系统执行的某一特定点所发生的事。第二十页，共二十五页，2022年，8月28日时序图例子第二十一页，共二十五页，2022年，8月28日时序图例子2第二十二页，共二十五页，2022年，8月28日时序图例子3第二十三页，共二十五页，2022年，8月28日时序图中包括如下元素：类角色，生命线，激活期和消息

1，类角色(ClassRole)

类角色代表时序图中的对象在交互中所扮演的角色，位于时序图顶部和对象代表类角色。类角色一般代表实际的对象2，生命线(Lifeline)

生命线代表时序图中的对象在一段时期内的存在。时序图中每个对象和底部中心都有一条垂直的虚线，这就是对象的生命线，对象间的消息存在于两条虚线间。3，激活期(Activation)

激活期代表时序图中的对象执行一项操作的时期，在时序图中每条生命线上的窄的矩形代表活动期。它可以被理解成C语言语义中一对花括号“{}”中的内容4，消息(Message)

消息是定义交互和协作中交换信息的类，用于对实体间的通信内容建模，信息用于在实体间传递信息。允许实体请求其他的服务，类角色通过发送和接受信息进行通信第二十四页