多媒体第三讲时序图_第1页
多媒体第三讲时序图_第2页
多媒体第三讲时序图_第3页
多媒体第三讲时序图_第4页
多媒体第三讲时序图_第5页
已阅读5页,还剩20页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、多媒体课件第三讲课件时序图第1页,共25页,2022年,5月20日,13点55分,星期二 课程学习的内容OO设计原则UML设计图及Rose Rational 工具OO设计模式典型项目的分析与设计第2页,共25页,2022年,5月20日,13点55分,星期二 学习方法掌握主要OO原则的原理和应用要点 改变java编程习惯学会设计 Rational工具的使用; 掌握类图、用例图、顺序图、活动图的设计熟练掌握MVC 设计方法 熟练掌握数据库编程 深化了解API,深化基于API的编程 反复实践典型模式应用于项目的分析和设计第3页,共25页,2022年,5月20日,13点55分,星期二参考书面向对象软件

2、工程与 UML, 李飞跃, 人民邮电出版社 ( 高职教材 )UML与软件建模 , 徐宝文,清华大学出版社(重点大学教材)面向对象设计原理与模式,(美)Dale Skrien著, 清华大学出版社 (国外经典教材) Java设计模式, 耿祥义,清华大学出版社大话设计模式,程杰,清华大学出版社第4页,共25页,2022年,5月20日,13点55分,星期二考核基于典型项目的考察:项目的分析与方案设计UML典型图项目代码中基本原则的应用项目设计中模型的使用第5页,共25页,2022年,5月20日,13点55分,星期二OOP编程要点 OOP追求的目标: 可用性、完整性、健壮性、有效性、可伸缩性、可读性、

3、可重用性、简洁性、可维护性、可扩充行 OOP 典型特点 : 封装性、继承性、重载、属性和修饰符、多态、重构、抽象类 接口、集合、泛型、委托与事件第6页,共25页,2022年,5月20日,13点55分,星期二 实现一个最简单的实例计算立体型几何体体积 要点: 分析其中的耦合性、 程序的复用性 “脏代码”分析第7页,共25页,2022年,5月20日,13点55分,星期二 OO基本原则单一职责原则要点: 开-闭原则依赖倒转原则里氏替换原则面向抽象原则多用组合少用继承原则迪米特原则高内聚/低耦合原则合成/聚集复用原则接口隔离原则第8页,共25页,2022年,5月20日,13点55分,星期二单一职责原则

4、(SRP原则)就一个类而言,应该只有一个引起它变化的原因;失败的案例: 界面处理类+数据库操作+文件读写+业务流程控制 类比: 多功能手机、集成主板的电脑坏一处就全坏经验: 类的设计倾向于越小越好解释: 如果一个类承担的职责过多,就等于把这些职责耦合在一起。一个职责的变化可能会引起消弱或抑制这个类完成其他职责的功能。这种耦合会导致脆弱的设计。当变化发生时,设计会遭到意想不到的破坏。第9页,共25页,2022年,5月20日,13点55分,星期二开-闭原则(核心原则)软件实体(类、模块、方法)应该可以扩展,但不可以修改;换个说法: 类对扩展是开放的, 对修改是封闭的;用extends 和imple

5、ments等开放,用private封闭实际使用: 1.随时准备修改:改变是合理的; 2.原来的代码一般不要改动,合理的方法是 基于原先的代码产生新的类 3.设计之初就准备好应对变化,用抽象来隔 离变化,减少耦合。第10页,共25页,2022年,5月20日,13点55分,星期二开-闭原则的运用:写一个相对固定的内核;不断产生新的类,当修改发生时; 新的类给予接口或抽象类创建;理解: 面向接口编程第11页,共25页,2022年,5月20日,13点55分,星期二里氏替换原则子类型必须能替换掉它们的父类型分析: “企鹅不是鸟” 子类型必须包含父类型的全部特征 第12页,共25页,2022年,5月20日

6、,13点55分,星期二依赖倒转原则抽象不应该依赖于细节,细节应该依赖于抽象; - 针对接口编程,不要对实现编程解释: 1.高层类不应该依赖低层类;两者都应依赖于 抽象; 2.抽象不应该依赖细节;细节应该依赖抽象反转实例: 电话指挥修电脑,谁依赖谁?抽象与实现: 电脑主板-总线插槽-PIC卡的实例 抽象不依赖细节,细节依赖抽象。第13页,共25页,2022年,5月20日,13点55分,星期二依赖止于接口-用接口消除强耦合AB依赖AB依赖I依赖用接口消除强耦合第14页,共25页,2022年,5月20日,13点55分,星期二OO的基本原则89、面向对象的基本设计原则1)LSP(The Liskov

7、Substitution Principle):Liskov替换原则子类不能添加任何父类没有的附加约束。子类对象必须可以替换基类对象。在可能的情况下,由抽象类(接口)继承。抽象类与具体类只要有可能,不要从具体类继承;行为集中的方向是向上的(抽象类);数据集中的方向是向下的(具体类)。2)OCP(The Open-Close Principle):开放-封闭原则对于扩展是开放的(Open for extension)对于更改是封闭的(Closed for modification)关键在于抽象抽象预见了可能的所有扩展(闭)由抽象可以随时导出新的类(开)OCP是OOD中很多说法的核心。LSP是OC

8、P成为可能的主要原则之一。3)SRP单一职责原则(The Single Responsibility Principle)一个类,应该仅有一个引起它变化的原因。体现了内聚性(Cohesion):一个模块的组成元素之间的功能相关性。违反SRP原则会带来物理依赖的缺点。使得每个类仅有一个职责。4)ISP接口隔离原则(The Interface Segregation Principle)客户应该仅知道所需要要的接口。一个类实现多个接口,避免“肥接口(fat interface)”使用委托分离接口,Adapter模式;使用多重继承分离接口。本质:使用多个专门的接口比使用单一的接口好。一个类对另一个类

9、的依赖性应当是建立在最小的接口上的。避免接口污染(Interface Pollution)5)DIP依赖倒置原则(The Dependency Inversion Principle)高层模块不依赖于低层模块,二者都依赖于抽象。抽象不应该依赖于细节,细节应该依赖于抽象。针对接口编程,而不是针对实现编程。Booch:所有结构良好面向对象架构都具有清晰地层次定义,每个层次通过一个定义良好的、受控的接口向外提供了一组类聚的服务。6)启发式原则依赖于抽象依赖关系都应终止于抽象类或者接口。任何变量都不应该拥有指向具体类的指针或者引用。任何类都不应该从具体类派生。任何方法都不应该改写其任何基类中已经实现的

10、方法。第15页,共25页,2022年,5月20日,13点55分,星期二UML中的类图类图中的6种关系 1. 继承(泛化)关系; 2. 实现关系; 3.依赖关系; 4. 关联关系; 5. 组合关系 6. 聚合关系; 基本画法: 1. 指向实体的关系用实线; 指向虚体(接 口和抽象类)的关系用虚拟线; 2. 箭头指向时间上先定义的类 第16页,共25页,2022年,5月20日,13点55分,星期二UML图第17页,共25页,2022年,5月20日,13点55分,星期二类图第18页,共25页,2022年,5月20日,13点55分,星期二 案例分析好友管理系统中的类图分析好友管理系统中消息传送过程分析

11、 - 登录过程分析 - 查询过程分析 - 增加过程过程第19页,共25页,2022年,5月20日,13点55分,星期二序列图系统的动态过程分析时序图时序图展示了几个对象之间的动态交互关系。它主要是用来显示对象之间发送消息的顺序,它还显示了对象之间的交互,即系统执行的某一特定点所发生的事。第20页,共25页,2022年,5月20日,13点55分,星期二时序图例子第21页,共25页,2022年,5月20日,13点55分,星期二时序图例子2第22页,共25页,2022年,5月20日,13点55分,星期二时序图例子3第23页,共25页,2022年,5月20日,13点55分,星期二时序图中包括如下元素:

12、类角色,生命线,激活期和消息1,类角色(Class Role)类角色代表时序图中的对象在交互中所扮演的角色,位于时序图顶部和对象代表类角色。类角色一般代表实际的对象2,生命线(Lifeline)生命线代表时序图中的对象在一段时期内的存在。时序图中每个对象和底部中心都有一条垂直的虚线,这就是对象的生命线,对象间 的消息存在于两条虚线间。3,激活期(Activation)激活期代表时序图中的对象执行一项操作的时期,在时序图中每条生命线上的窄的矩形代表活动期。它可以被理解成C语言语义中一对花括号“”中的内容4,消息(Message)消息是定义交互和协作中交换信息的类,用于对实体间的通信内容建模,信息用于在实体间传递信息。允许实体请求其他的服务,类角色通过发送和接受信息进行通信第24页,共25页,2022年,5月2

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论