当前位置:文档之家› 软件工程_系统设计与设计模式课程提纲

软件工程_系统设计与设计模式课程提纲

系统设计与设计模式课程提纲第一章 软件工程导论一、工程的概念:•工程简而言之就是多人参与并有计划、有步骤地完成一项任务的活动•工程强调:目的 / 计划 / 步骤二、软件发展与软件工程起源•软件的发展四个阶段:–1950年前后到1960年前后,程序设计阶段;–1960年前后到1970年前后,软件系统阶段;–1970年前后到1980年前后互联网络兴起,软件工程阶段;–1980年前后到现在,分布式软件工程阶段;•1968年,北大西洋公约组织的计算机科学家召开国际会议,第一次提出软件危机的概念,产生了应对软件危机的对策---软件工程。

三、工程策略•任何工程都有如下的策略:分而治之 / 复用 / 折衷优化 / 检验并保证质量•软件工程也会充分利用这些策略四、软件工程的目标•软件工程的目标是提高软件的质量与生产率,最终实现合格的软件。

质量是软件需求方最关心的问题 / 生产率是软件供应方最关心的问题。

五、软件工程的准则生命周期计划 / 阶段评审 / 变更控制 / 改进程序设计技术 / 控制人员规模 / 定义评审 / 不断改进软件工程六、软件工程的组成•人员管理 / 项目管理 / 过程管理七、三种过程模型•瀑布模型 / 演化模型 / 迭代模型•过程模型中各个阶段的任务和描述:–可行性分析:做还是不做–需求分析:都有什么功能–概要设计:供有多少子功能–详细设计:子功能怎么实现–编码:子功能实现了吗–测试:功能是否完备–部署:需要多少设备和软件的支持–维护:软件运行是否正常第二章 软件项目管理一、项目管理的定义•项目管理分三个阶段:制定项目计划 / 管理和跟踪项目 / 结束项目•项目管理的时间、范围、费用•项目的轮廓定义:目标 / 前提 / 限制 / 范围•项目计划要素:任务 / 任务相关性(FF-SF-FS-SS) / 工期 / 成本 / 资源二、 工作分解结构(WBS)•工作分解结构(WBS Work Breakdown Structure),以可交付成果为导向对项目要素进行的分组,它归纳和定义了项目的整个工作范围,每下降一层代表对项目工作的更详细定义。

WBS总是处于计划过程的中心,也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。

WBS同时也是控制项目变更的重要基础。

项目范围是由WBS定义的,所以WBS也是一个项目的综合工具。

三、Project 中创建项目计划文档•Project中的项目管理概念•Project中创建项目计划文档:新建项目文档 / 添加分层任务 / 添加资源 / 给任务配备资源 / 审查日程•任务的相关操作:创建里程碑 / 创建周期性任务 / 创建和删除任务链接 / 创建任务相关性 / 设置任务限制•工时计算公式:工时=工期×单位(资源工作分配单位)工期是完成任务所经历的实际时间•甘特图甘特图(Gantt Chart)以图形或表格的形式显示活动,可以直观地表明任务计划在什么时候进行,及实际进展与计划要求的对比。

管理者由此可以非常便利地弄清每一项任务(项目)还剩下哪些工作要做,并可评估工作是提前还是滞后,亦或正常进行。

除此以外,甘特图还有简单、醒目和便于编制等特点。

甘特图对于项目管理是一种理想的控制工具。

•关键路径 / 关键任务计算法则:调整关键路径上任务的时间进度将会影响整个项目的交付时间。

第三章 MSF介绍一、MSF(Microsoft Solution Framework)是指微软解决方案框架。

•MSF描述了微软公司从众多大小软件产品研发实践中总结的管理软件开发过程的经验二、MSF三个核心模型:组队模型 / 过程管理模型 / 应用程序模型三、组队模型中的角色:程序管理 / 开发 / 测试 / 发布经理 / 用户体验 / 产品经理•可合并的角色四、过程模型:•构想阶段:定义初步的商业需求 / 风险管理 / 定义项目结构 / 研究和收集设想 / 制定初步的项目范围•设计阶段:创建功能描述 / 开发计划 / 测试计划 / 用户培训计划 / 后勤计划 / 产品管理计划 / 程序管理计划 / 合并项目计划•开发阶段:迭代开发一到多次的内部发布版 / 功能说明冻结 / 最后的特性开发 / 最后的后勤开发 / 最后的性能支持开发•稳定阶段:发布一到多个测试版,包括α测试版和β测试版 / 收集错误 / 改正高优先级的错误,发布无错误版 / 进行最后的错误分类 / 黄金发布版五、应用程序模型第四章 设计模式一、设计模式概述•定义:设计模式是设计范畴的术语,是指相似的软件分析背景条件下,处理同一类软件分析结果的典型设计结构•Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides等四人合著的《Design Patterns—Elements of Reusable Software》1995年出版后推动了软件设计模式的发展。

四个作者被称为GOF(Gang Of Four)•设计模式的两大目的是实现可维护性和软件复用。

二、单子模式•概念:–Singleton模式主要作用是保证一个类Class只有一个实例存在–使Singleton的好处:节省内存 / 有利于Java垃圾回收(garbage collection)/ 提高了系统的性能–Java代码中的Runtime类就是一个典型的单例模式的应用–单子模式的必备条件:构造器私有 / 静态工厂方法 / 静态本类实例–饿汉式 / 懒汉式:创建实例的时机不同三、简单工厂•简单工厂模式是类的创建模式,根据需要动态的决定创建具体类的实例,将类的实例化责任转移到独立的工厂类中,有利于提供程序的可维护性。

•Java语言中的DataFormat类就是一个简单工厂的实现四、工厂方法•工厂方法模式旨在定义一个创建产品对象的工厂接口,将实际创建工作推迟到子类中。

•与简单工厂模式之间的区别:–简单工厂模式是建立一个工厂对象来决定创建对象的类型。

工厂模式是将各种产品的创建封装在各个不同的创建者(也可以说是生产者)中。

–简单工厂只允许一个工厂造产,工厂方法创建了一个框架,让子类决定要如何实现,允许不同的工厂都制造产品。

–在工厂方法中产品类与创建者类是平行的,因为它们都是抽象的,都有自己的许多具体的子类,每个子类都有自己的特定实现。

简单工厂不具备工厂方法的弹性,如果有新的产品出现,将不得不修改创建方法,它不能变更正在创建的产品。

五、建造模式 (builder模式)•建造模式的使用使得产品的内部可以独立的变化,使用建造模式可以使客户端不必知道产品内容组成的细节•Builder模式允许用户通过指定复杂对象的类型和内容就可以构建它们,用户不知道内部的具体构建细节•Builder模式将部件和组装过程分开•使用Builder是为了将构建复杂对象的过程和它的部件解耦。

注意:是解耦过程和部件,使用builder模式所建造的最终产品更容易控制。

它将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示六、适配器模式•适配器模式就是将两个不兼容的类纠合在一起使用,它需要有被适配者和适配器两个身份,由于适配器类是源的一个子类,因此可以在适配器类种置换掉源的一些方法•使用适配器类可以实现指方为圆,避重就轻的效果七、代理模式•所谓代理,就是一个人或一个机构代表另一个人或另一个机构采取行动。

而代理对象可以再客户端和目标对象之间起到中介的作用•代理模式是给某一个对象提供一个代理对象,并由代理对象控制对原对象地引用八、门面模式•门面模式又称为Facade模式,使用Facade模式可以为子系统中的一组接口提供一个一致的界面,简化方法的调用。

•Facade作为子系统类的客户端,组装了子系统的实现过程•降低系统之间的耦合度,有助于子系统间的松散耦合九、模版方法模式•模版方法模式是一种基于继承的复用•模版方法模式将实现顶层逻辑的抽象类中的部分方法以具体方法及构造子方法实现,然后将剩余的逻辑声明为抽象方法,延迟到子类中实现•模版方法模式中使用抽象角色给出顶级行为的实现,而将作为细节步骤的基本方法留给具体子类实现十、命令模式•命令模式是对命令的封装,命令模式把发出命令的责任和执行命令的责任分割开,委派给不同的对象•命令模式允许请求的一方和接收的一方独立开来,使得请求的一方无需接收请求的一方的接口•每一个命令都是一个操作,命令类中通常只会有一个方法,请求的一方发出请求要求执行一个操作,接收的一方收到请求,并执行操作,这个责任是分开的。

彼此不受影响。

命令类只负责发出请求,至于请求被执行的过程则独立于命令类之外十一、观察者模式•被观察者可以通知观察者进行更新。

•Java的API中提供了两个类,以辅助我们实现观察者模式,分别是被观察者Observable和观察者Observer。

•被观察者类是java.util.Observable类的子类,java.util.Observable提供公开的方法支持观察者对象,其中比较重要的有setChanged(),一个是notifyObservers(),第一个方法setChanged()被调用后会设置一个内部标记变量,代表被观察者对象的状态发生了变化•第二个方法notifyObservers()被调用时,会调用所有登记过的观察者对象的update()方法,使这些观察者对象可以更新自己。

•MVC基于观察者模式十二、总结•设计模式是保证软件复用性设计的基础•设计模式使程序便于维护•模式是代表性问题的一种解决方案附注:(这些内容课本上没有包括,但很重要,可能面试时会有用到,最好背一下,考试会涉及到一小部分)一、面向对象设计根本的指导原则是提高可维护性和可复用性。

二、设计模式的原则主要有:1. 开闭原则:一个软件实体应该对扩展开放,对修改关闭。

2. 依赖倒转原则:依赖倒转原则讲的是:要依赖于抽象,不要信赖于实现。

开闭原则是目标,而达到这一目标的手段是依赖倒转原则。

Spring中的IoC是依赖倒转原则的一个具体应用。

3. 里氏代换原则:要求任何基类能出现的地方,子类都可以出现。

换句话说也就是子类可以完全替代基类。

4. 合成/聚合复用原则:要尽量使用合成/聚合,而不是继承关系达到复用的目的。

5. 迪米特原则:也叫最少知识原则,如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用。

如果其中一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用。

经常比喻为:1)只与你直接的朋友们通信。

2)不要跟“陌生人”说话。

6. 接口隔离原则:应当为客户端提供尽可能小的单独接口,而不要提供大的总接口。

也即是使用多个专门的接口比使用单一的总接口要好。

三、依据设计模式思想,程序开发中应优先使用的是对象组合关系实现复用,而不是继承。

相关主题