880 likes | 1.01k Views
第 2 讲 软件工程方法. 内容提要. 开发模式 传统软件开发模式 瀑布模型 结构化分析,结构化设计和结构化编码 面向对象的软件开发模式 面向对象的概念 面向对象的分析,设计和编码 UML 简介. 开发模式 ( Paradigm ). 开发模式又称为范型、范例、风范或模式 ( Pattern) 。开发模式定义了 特定问题和应用的开发过程中将遵循的 步骤 ; 确定将用于表示问题和解的那些成分的 类型 ; 利用这些成分表示与问题解决有关的 抽象 ; 直接得到问题的 结构 。. 开发模式的选择影响到整个软件开发生存期 。就是说,它支配了 设计方法 编码语言
E N D
内容提要 • 开发模式 • 传统软件开发模式 • 瀑布模型 • 结构化分析,结构化设计和结构化编码 • 面向对象的软件开发模式 • 面向对象的概念 • 面向对象的分析,设计和编码 • UML简介
开发模式(Paradigm) • 开发模式又称为范型、范例、风范或模式(Pattern)。开发模式定义了 • 特定问题和应用的开发过程中将遵循的步骤; • 确定将用于表示问题和解的那些成分的类型; • 利用这些成分表示与问题解决有关的抽象; • 直接得到问题的结构。
开发模式的选择影响到整个软件开发生存期。就是说,它支配了开发模式的选择影响到整个软件开发生存期。就是说,它支配了 • 设计方法 • 编码语言 • 测试和检验技术 的选择
内容提要 • 开发模式 • 传统软件开发模式 • 面向对象的软件开发模式
传统软件开发模式 • 又称生命周期方法学或者结构化范型 • 特点: • 采用结构化技术(结构化分析、结构化设计、结构化实现)完成软件开发的各项任务 • 把软件的生命周期划分为若干阶段,然后顺序完成各个阶段的任务 • 每个阶段的开始和结束都有严格的标准,对于 任何两个相邻的阶段而言,前一 阶段的结束标准就是后一阶段的开始标准 • 在每个阶段结束之前都必须正式地进行严格 的技术 和管理审查
System Design Definition 定 义 Feasibility Study Requirements Analysis Program Design 开 发 Coding & Module Testing Integration & System Testing Delivery & Maintenance 维 护 传统软件开发模式
问题定义和可行性研究 • 确定要开发软件系统的总目标 • 给出功能、性能、可靠性以及接口等方面的要求 • 完成该软件任务的可行性研究 • 估计可利用的资源(计算机硬件,软件,人力等)、成本、效益、开发进度 • 制定出完成开发任务的实施计划,连同可行性研究报告,提交管理部门审查
需求分析 • 对待开发软件提出的需求进行分析并给出详细的定义 • 编写软件需求说明书或系统功能说明书及初步的系统用户手册 • 提交管理机构评审
设计 • 总体设计 —“如何解决问题” • 可以列出多种解决方案进行比较 • 把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块,每个模块都和某些需求相对应 • 详细设计 —对每个模块要完成的工作进行具体的描述,为源程序编写打下基础 • 编写设计说明书,提交评审。
编码 • 把软件设计转换成计算机可以接受的程序代码,即写成以某一种特定程序设计语言表示的“源程序清单” • 写出的程序应当是结构良好、清晰易读的,且与设计相一致的
测试 • 单元测试,查找各模块在功能和结构上存在的问题并加以纠正 • 综合测试(包括集成测试和验收测试) • 按规定的各项需求,逐项进行有效性测试,决定已开发的软件是否合格,能否交付用户使用
运行和维护 • 改正性维护 运行中发现了软件中的错误需要修正 • 适应性维护 为了适应变化了的软件工作环境,需做适当变更 • 完善性维护 为了增强软件的功能需做变更
阶段 关键问题 结束标准 问题定义 问题是什么? 关于规模和目标的报告书 可行性研究 有可行的解吗? 系统的高层逻辑模型 数据流图 成本/效益分析 需求分析 系统必须做什么? 系统的逻辑模型 数据流图 数据字典 算法描述 结构分析设计过程
阶段 关键问题 结束标准 总体设计 概括地说,应该如何解决这个问题? 可能的解法: 系统流程图 成本/效益分析 推荐的系统结构; 层次图或结构图 详细设计 怎样具体地实现这个系统? 编码规格说明: HIPO图或PDL 编码和单元测试 正确的程序模块 源程序清单;单元测试方案和结果 综合测试 符合要求的软件 综合测试方案和结果;完整一致的软件配置 维护 持久地满足用户需要的软件 完整准确的维护记录 结构分析设计过程
结构化技术的缺点 • 不适用于软件规模较大,或者对软件的需求是模糊或随时间变化 • 数据与操作分开处理,可能造成软构件对具体应用环境的依赖,可维护性和重用性(reusability)较差.
内容提要 • 开发模式 • 传统软件开发模式 • 面向对象的软件开发模式
面向对象方法学(OOM) • 特点:尽可能模拟人类习惯的思维方式,更直接地描述客观世界中存在的事物(对象)以及它们之间的关系。即问题域与求解域在结构上尽可能一致 • 将客观事物看作具有属性和行为的对象(数据和处理结合)。 • 通过抽象找出同一类对象的共同属性和行为,形成类。 • 通过类的继承与多态实现代码重用
面向对象思想的起源 • 维特跟斯坦是本世纪乃至人类哲学史上最伟大的哲学家之一。他生前只于1922年出版了一本著作——《逻辑哲学论》(Tractatus Logico-Philosophicus)。在该书中,他阐述了一种世界观,或者说一种认识世界的观点,这种观点,在六七十年后的今天,终于由一种哲学思想沉淀到技术的层面上来,成为计算机业界的宠儿,这就是“OO”,Object-Oriented,面向对象。
面向对象思想的起源 • 维特根斯坦在《逻辑哲学论》 一书中提出了如下思想: • *世界可以分解为事实 ( The world divides into facts.)*事实是由原子事实(atomic facts)组成的。*一个原子事实是多个对象(objects)的组合。 *对象是简单的(基本的) The Object is simple。*对象形成了世界的基础。
OOM的四要素:对象:世界由对象构成 • 一般意义上的对象(自然界): • 是现实世界中一个实际存在的事物。 • 可以是有形的(比如一辆汽车),也可以是无形的(比如一项计划)。 • 是构成世界的一个独立单位,具有: • 静态特征:可以用某种数据来描述 • 动态特征:对象所表现的行为或具有的功能
面向对象方法中的对象: • 是系统中用来描述客观事物的一个实体,它是用来构成系统的一个基本单位。对象由一组属性和一组行为构成。 • 属性:用来描述对象静态特征的数据项。 • 行为:用来描述对象动态特征的操作序列
OOM的四要素:类:物以类聚 • 分类——人类通常的思维方法 • 分类所依据的原则——抽象 • 忽略事物的非本质特征,只注意那些与当前目标有关的本质特征,从而找出事物的共性,把具有共同性质的事物划分为一类,得出一个抽象的概念。 • 例如,石头、树木、汽车、房屋等都是人们在长期的生产和生活实践中抽象出的概念。
OOM的四要素:类:物以类聚 • 面向对象方法中的“类”:把对象的属性和服务封装成一个独立的系统单元,是 具有相同属性和服务的一组对象的集合 • 为属于该类的全部对象提供了抽象的描述,包括属性和行为两个主要部分。 • 尽可能隐蔽对象的内部细节。对外形成一个边界(或者说一道屏障),只保留有限的对外接口使之与外部发生联系。 • 类与对象的关系:犹如模具与铸件之间的关系,一个属于某类的对象称为该类的一个实例。
…… …… f1 f2 f3 fi fn gi(X,S) S S’ 输出 输出
OOM的四要素:继承与多态:世界的相似性与多样性OOM的四要素:继承与多态:世界的相似性与多样性 • 继承对于软件复用有着重要意义,是面向对象技术能够提高软件开发效率的重要原因之一。 • 定义:特殊类的对象拥有其一般类的全部属性与服务,称作特殊类对一般类的继承 • 例如:将轮船作为一个一般类,客轮便是一个特殊类。
多态是指在一般类中定义的属性或行为,被特殊类继承之后,可以具有不同的数据类型或表现出不同的行为。这使得同一个属性或行为在一般类及其各个特殊类中具有不同的语义。多态是指在一般类中定义的属性或行为,被特殊类继承之后,可以具有不同的数据类型或表现出不同的行为。这使得同一个属性或行为在一般类及其各个特殊类中具有不同的语义。
Shape Circle Square Hexagon
OOM的四要素:消息:合作之道 ④ 消息(message):对象间只能通过发送消息进行联系,外界不能处理对象的内部数据,只能通过消息请求它进行处理(如果它提供相应消息的话)。
OOM四要素总结 • 对象:世界由对象构成 • 类:物以类聚 • 继承/多态:世界的相似性与多样性 • 消息:合作之道
OOM的优点: OOM:以object 为核心,强调对现实概念的模拟而不强调算法。“面向对象方法学的基本原则,是按照人们习惯的思维方式建立问题域的模型,开发出尽可能直观、自然地表现求解方法的软件系统”。 Class:由特殊到一般的归纳(induction) Inheritance:由一般到特殊的演绎(deduction) ① 传统方法:面向过程设计,以计算为核心,数据与操作分离,不易理解。
② 传统方法:结构依赖于功能,不稳定。 OOM:以object模拟实体,需求变化不会引起结构的整体变化,因为实体相对稳定,故系统也相应稳定。 ③传统方法:通过建立标准函数库来重用软构件。但标准函数缺少必要的“柔性”,难以适应不同场合的不同需要。 OOM:一个class所有的 instances 都可重用它的代码;由 inheritance 派生出的新的 class 可重用其父类的代码,并且可以修改、扩充而不影响其父类的使用。
④ 传统方法:可维护性是最令人头痛的问题。 OOM:从以下几方面改善了可维护性 —— • 稳定性好:软件功能需求的变化不牵动全局,只需局部修改; • Class 独立性强:只要修改不涉及class的对外接口,则内部修改完全不影响外部调用; • Inheritance和多态性(polymorphism)使其很容易被修改和扩充; • 容易理解; 有这一条就什么都好办了! 容易测试、调试。 这一点还可商榷
注:OOM并不是减少了开发时间,而是通过提高可重用性、可维护性,进行扩充和修改的容易程度等,从长远角度改进了软件的质量。注:OOM并不是减少了开发时间,而是通过提高可重用性、可维护性,进行扩充和修改的容易程度等,从长远角度改进了软件的质量。
因此,从面向对象分析,到面向对象设计,再到面向对象程序设计语言是一种与表示法十分一致的策略。因此,从面向对象分析,到面向对象设计,再到面向对象程序设计语言是一种与表示法十分一致的策略。
OOM的构成 • 面向对象的分析(OOA) • 面向对象的设计(OOD) • 面向对象的编程(OOP) • 面向对象的测试(OOT) • 面向对象的软件维护(OOSM)
系统分析 • 系统分析阶段应该扼要精确地抽象出系统必须做什么,但是不关心如何去实现。 • 面向对象的系统分析,直接用问题域中客观存在的事物建立模型中的对象,对单个事物及事物之间的关系,都保留他们的原貌,不做转换,也不打破原有界限而重新组合,因此能够很好地映射客观事物。
设计 • 针对系统的一个具体实现运用面向对象的方法。其中包括两方面的工作: • 把OOA模型直接搬到OOD,作为OOD的一部分 • 针对具体实现中的人机界面、数据存储、任务管理等因素补充一些与实现有关的部分。
编程 OOP工作就是用一种面向对象的编程语言把OOD模型中的每个成分书写出来,是面向对象的软件开发最终落实的重要阶段。
测试 • 测试的任务是发现软件中的错误。 • 在面向对象的软件测试中继续运用面向对象的概念与原则来组织测试,以对象的类作为基本测试单位,可以更准确的发现程序错误并提高测试效率。
维护 • 将软件交付使用后,工作并没有完结,还要根据软件的运行情况和用户的需求,不断改进系统。 • 使用面向对象的方法开发的软件,其程序与问题域是一致的,因此,在维护阶段运用面向对象的方法可以大大提高软件维护的效率。
OOA&OOD • 面向对象技术不仅是一种程序设计方法,更重要的是一种对真实世界抽象思维方式。 • 面向对象的分析和设计应该从建模开始,建模语言一直是面向对象技术的研究重点
建模的定义: • 建模是对现实的简化。就是把复杂的系统变成小的系统,采用“各个击破”的原则逐一解决。
为什么要建模 • 建立大厦和建立茅草屋的区别是建设茅草屋不需要设计。要生产合格的软件就要有一套关于体系结构、过程和工具的规范。 • 模型帮助我们按照实际情况或按照我们所需要的样式对 系统进行可视化 • 模型允许我们详细说明系统的结构和行为。 • 模型给出一个知道我们构造系统的模板。 • 模型对我们的决策进行文档化。
建模的误区 • 无论你遵从的是重量级的方法,比如Enterprise Unified Process(EUP),还是轻量级的开发过程,如Extreme Programming(XP),建模在软件开发中都是不可或缺的。但不幸的是其中充斥着各种谬误与迷思。 这来自于各个方面,有从理论家错误的研究、数十年来信息技术领域内的文化沉积、软件工具开发商天花乱坠半的 市场宣传以及象Object Management Group (OMG)和IEEE 这类组织的标准
误区一:建模就等于是写文档 事实分析:“模型”与“文档”这二者在概念上是风马牛 不相及的----你可以拥有一个不是文档的模型和不是 模型的文档。 建模很象是作计划:作计划的价值在于计划编制的过程中 而非计划本身;价值体现在建模的活动中,而非模型本身 实际上,模型不是你系统中的一部分正式的文档,而且在 完成它们的使命后可以被丢掉。你会发现值得保留的只有 很少的模型,而且它一定是非常完美。
误区二:从开始阶段你可以考虑到所有的一切 怎么才能走出这个误区呢? 首先,你必须认识到你不能考虑到所有的细枝末节。 第二,认识到不管你的最初所作的规格说明书有多好,但 注定代码会很快地与之失去同步,即便是你自己建模自己 编码。一个基本的道理就是代码永远只会和代码保 持一致。 第三,认识到迭代法(小规模地建模,编一些代码,做一些 测试,可能还会做一个小的工作版本)是软件开发的准则。 它是现代重量级的软件开发过程(如RUP),以及轻量级 (如XP)的基本原理。
误区三:建模是在浪费时间 许多人都这样认为,这主要是因为他们所接受的教育仅仅局限于如何编写代码,对于完整的开发流程鲜有接触。而且他们的经验也仅限于如何实现代码,就如初级程序员。他们放弃了提高效率和学习技能的机会,这些技能能够使他们很容易地适应不同的项目或组织。 事实分析:在大多数情况下,在开始编码之前画一个草图、开发一个粗率的原型或者制作一些索引卡片都能提高你的生产效率。高效的开发者在编码之前都要进行建模工作。另外,建模是一种很好的在项目组成员与项目负责人之间沟通途径。你们在这个过程中探讨问题,从而对所要的是一个什么样的东西可以得到更好的 理解,涉及到该项目中的每个成员也可得到对该项目有一个从分的了解。
误区四:所有的开发人员都知道如何建模 事实分析:这肯定是不正确的。建模的技能,是只有当一个开发者通过学习它,并经过长期的实践才能够掌握。 一些非聪明的程序员常常相信自己无所不能,正因为这样的狂妄 自大,他们承当的一些任务是他们根本就没有相应的技能去 完成的。软件开发是如此的复杂,单单一个人是很难具备所 有的技能去成功地进行开发,甚至也不可能去配置有一定复杂程度的系统。开发者应该有自知之明,明白他们自己的弱 点,学无止境。 通过互相取长补短,建模者可从程序员身上学到一项技术的具体细节,程序员也可从建模者那里学到有价值 的设计和体系结构的技术。