软件工程_系统设计与设计模式课程提纲
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
系统设计与设计模式课程提纲
第一章 软件工程导论
一、工程的概念:
•工程简而言之就是多人参与并有计划、有步骤地完成一项任务的活动
•工程强调:目的 / 计划 / 步骤
二、软件发展与软件工程起源
•软件的发展四个阶段:
–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模式所建造的最终产品更容易控制。它将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示
六、适配器模式
•适配器模式就是将两个不兼容的类纠合在一起使用,它需要有被适配者和适配器两个身份,由于适配器类是源的一个子类,因此可以在适配器类种置换掉源的一些方法