你来我们毒蛇帮总部干什么|

asdio

园龄:4年7个月粉丝:1关注:0

软件工程概论

第一章 软件工程概论

1.软件危机

定义

  1. *软件:是计算机程序、方法、规则、相关的文档以及运行计算机系统时所必需的数据的总和(狭义定义:软件=程序+数据+文档)
  2. *软件的特性:软件是复杂的、软件是不可见的、软件是不断变化的和软件质量难以稳定。
  3. *软件的质量特性:功能性、可靠性、易用性、效率、维护性、可移植性。
  4. 软件危机:指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

软件危机的主要表现:

  • 对软件开发成本和进度估计常常很不准确
  • 用户对"已完成"的系统不满意的现象经常发生
  • 软件产品的质量往往靠不住
  • 软件常常是不可维护的
  • 软件成本在计算机系统总成本所占的比例逐年上升

软件危机产生的主要原因:

  • 软件日益复杂和庞大
  • 软件开发管理困难和复杂
  • 软件开发技术落后
  • 生产方式落后
  • 开发工具落后
  • 软件开发费用不断增加

软件危机如何解决

既要有技术措施(方法和工具),又要有必要的组织管理措施。

2.软件工程的基本概念

软件工程介绍

  1. 软件工程:是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件,把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来,以经济地开发出高质量的软件并有效地维护它。

  2. 软件工程的本质特征:

    • 软件工程关注于大型程序的构造
    • 在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品
    • 开发软件的效率非常重要
    • 软件工程的中心课题:控制复杂性
    • 软件经常变化
    • 软件必须有效地支持它的用户
    • 和谐地合作是开发软件的关键
  3. 软件工程的基本原理:

    • 用分阶段的生命周期计划严格管理
    • 坚持进行阶段评审
    • 实行严格的产品控制
    • 采用现代程序设计技术
    • 结果应能清楚的审查
    • 开发小组的人员应该少而精
    • 承认不断改进软件工程实践的必要性

软件工程方法学

  1. 软件工程以关注软件质量为目标,包括方法、过程、工具、范式四个要素。

  2. 软件工程方法学:把软件生命周期全过程中使用的一整套技术方法的集合成为方法学(也称范型paradigm),包括三个要素:方法,工具和过程.目前使用最广泛的是传统方法学和面向对象方法学

    • 传统方法学(也称生命周期方法学或结构化范型):采用结构化技术(结构化分析,结构化技术,结构化实现)来完成软件开发的各项任务,并使用适当的软件工具或软件环境来支持结构化技术的运用

    • 面向对象方法学:有4个要点;它是一个多次反复迭代的演化的过程;特有的继承性和多态性进一步提高了面向对象软件的可重用性

3. 软件生命周期

  • 问题定义:确定要解决的问题是什么(通过客户的访问调查,系统分析员写出问题的性质,工程目标和工程规模的书面报告,并得到客户的确认)
  • 可行性研究:不是具体解决问题,而是研究问题的范围,探索问题是否值得去解,是否有可行的解决方法
  • 需求分析:准确确定"为了解决这个问题,目标系统必须做什么",主要是确定目标系统必须具备哪些功能
  • 总体设计:设计出目标系统的多种方案;设计程序的体系结构
  • 详细设计:详细的设计每个模块,确定要实现模块功能所需要的算法和数据结构
  • 编码和单元测试:写出正确的容易理解,容易维护的程序模块
  • 综合测试:通过各种类型的测试(及相应的的调试)使软件达到预定的要求
  • 软件维护:通过各种必要的维护活动使系统持久地满足用户的需要

4. 软件过程

  1. 软件过程:指为了获得高质量软件所需完成一系列任务框架,它规定了完成各项任务的工作步骤;通常使用生命周期模型简洁地描述软件过程
  2. 生命周期模型:也称过程模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序

瀑布模型

  • 瀑布模型特点:

    • 阶段间具有顺序性和依赖性:
      必须等前一阶段的工作完成后之后,才能开始后一段的工作;前一段的输出文档就是后一阶段的输入文档
    • 推迟实现的观点:
      在编码之前设置了系统分析和系统设计的各个阶段,分析与设计阶段的基本任务规定,这两个阶段主要考虑目标系统的逻辑模型,不涉及物理实现
    • 质量保证的观点:
      每个阶段必须完成规定的文档;每个阶段结束前都要对完成的文档进行评审,以便尽早发现问题
  • 瀑布模型适用:在开发的早期阶段软件需求被完整确定

  • 瀑布模型的优点:

    • 可强迫开发人员采用规范的方法;
    • 严格规定了每个阶段必须提交的文档;
    • 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证
  • 瀑布模型缺点:
    瀑布模型是由文档驱动;最终产品不能真正满足客户的需求

快速原型模型

首先建立一个反映用户主要需求的原型系统,让用户体验,之后提出意见,随之进行修改,再让用户体验...直至用户完全满意,据此写出规格说明文档

2. 增量模型:也称渐增模型,把产品作为一系列的增量构件来设计、编码、集成、测试。

  • 增量模型优点:
    • 人员分配灵活,刚开始不用投入大量人力资源;
    • 可先发布部分功能给客户,对客户起到镇静剂的作用;
    • 增量能够有计划地管理技术风险。
  • 增量模型缺点:
    • 需要软件具备开放式的体系结构;
    • 容易退化为边做边改模型,从而使软件过程的控制失去整体性;
    • 增加系统内部的耦合复杂性。

螺旋模型

把它看作在每个阶段之前增加了风险分析的快速原型模型。

  • *螺旋模型与增量模型的区别:
    • 两者迭代层级不同:增量模型在活动级迭代;螺旋模型在过程级迭代;
    • 两者需求分析的时间不同:增量模型常常是先做总体需求分析和设计,然后在编码和测试中逐个增量开发;螺旋模型在开发周期内采用简化瀑布模型或快速模型;
    • 两者提交软件的方式不同:增量开发在上次增量的基础上提交新的一部分软件;螺旋模型每次迭代都提交一个新的完整的软件版本;
    • 两者减少风险的方式不同:增量模型使用未成熟技术和经常的客户反馈等方法减少风险;螺旋模型中直接加进风险识别,风险分析、风险控制,计划性较强.

喷泉模型

典型的具有面向对象软件开发过程迭代和无缝的特性
用面向对象开发软件时,在分析、设计、编码等各项开发活动之间并不存在明显的边界,每个阶段都有该阶段内的迭代维护。

第二章 可行性研究

1.可行性研究的任务

  1. 可行性研究的目的不是为了解决问题,而是确定问题是否值得去解决
  2. 可行性:技术可行性、经济可行性、操作可行性、运行可行性、法律可行性。

2. 可行性研究过程

  • 复查系统规模和目标
  • 研究正在使用的系统
  • 导出新系统的高层逻辑模型
  • 进一步定义问题
  • 导出和评价供选择的解法
  • 推荐行动方针
  • 草拟开发计划
  • 书写文档提交审查

3. 系统流程图

  1. *系统流程图:是概括地描绘物理系统的传统工具。用图形符号以黑盒子形式描绘组成系统的每个部件(程序,文档,数据库,人工过程等)。表达的是 数据在系统中各部件之间的流动情况。
符号 名称 说明
矩形 处理 能改变数据值或数据位置的加工或部件。如程序 、处理机、人工加工等都是处理
平行四边形 输入输出 表示输入或输出,是一个广义的不指名具体设备的符号
圆形 连接 指出转到图的另一部分或从图的另一部分转来,通常在同一页上
矩形下面 加个三角 换页连接 指出转到另一页图上或另一页图转来
箭头 数据流 用来连接其他符号,指明数据流的方向

4.数据流图

数据流图(Data Flow Diagram)是一种简单的图形方式,用来描述数据和信息流从输入移动到输出过程中所经受的变换。

数据流图的表示

5. 数据字典

数据字典是关于数据的信息的集合,也就是对数据流图中所有元素的定义的集合。

数据字典定义组成

  • 数据流
  • 数据流分量(即数据元素)
  • 数据存储
  • 处理

6. 成本效益分析

第一步估计开发成本、运行费用和新系统将带来的经济效益。需从货币时间价值,投资回收期,纯收入,投资回收率

方法有三种:

  • 代码行技术:软件成本=每行代码的平均成本*估计的源代码总行数
  • 任务分解技术:单本任务成本=任务所需人力估计值*每人每月平均工资;软件开发项目总成本=每个单独任务成本估计总和
  • 自动估计成本技术:采用自动估计成本的软件

第三章 需求分析

1. 需求分析的任务

  • 确定对系统的综合要求
    • 功能需求
    • 性能需求
    • 可靠性和可用性需求
    • 出错处理需求
    • 接口需求
    • 约束
    • 逆向需求
    • 将来可能提出的需求
  • 分析系统的数据要求
  • 导出系统的逻辑模型
  • 修正系统开发计划

2. 分析建模与规格说明

模型: 就是为了理解事物而对事物作出的一种抽象,是对事物的一种无歧义的书面描述。通常,模型由一组图形符号和组织这些符号的规则组成
需要建立的三种模型:数据模型、功能模型和行为模型

* 实体-联系图

描绘数据对象、数据对象的属性及数据对象之间的关系,用于建立数据模型

* 数据规范化

同数据库中一二三范式

* 状态转换图

描绘了系统的状态及引起状态转换的事件,是建立行为模型的基础

  • 状态
    • 任何可以被观察到的系统行为模式
  • 事件
    • 对引起系统做动作或从一个状态转换到另一个状态的外界事件的抽象
  • 符号

举例如下:

其他图形工具

  • 层次方框图
    用树形结构的一些了多层级的矩形框描绘的数据的层次结构。
  • Warnier图
    表面信息的逻辑组织
  • IPO图
    输入处理输出图的简称。

3.验证软件需求

验证的方面

  • 一致性
  • 完整性
  • 现实性
  • 有效性

第四章 形式化说明技术

软件工程使用方法按形式化程度分为三类:

  • 非形式化,如用自然语言描述规格说明
  • 半形式化,如用数据流图或实体-联系图建立模型
  • 形式化,如描述系统性质是基于数学的技术

1. 概述

非形式化的缺点

  • 矛盾性:在需求规格说明书中对同一问题前后存在不同的描述
  • 二义性:读者可以用不同的方式理解的陈述
  • 含糊性:需求规格说明书对某一问题描述不清晰,不可理解
  • 不完整性:需求规格说明书对某一问题只说明了局部,没说明整体
  • 抽象层次混乱:指在非常抽象的陈述中混入了关于低层次的细节陈述

形式化的优点:

  • 能够简洁准确的描述物理现象、对象或动作的结果
  • 在不同的软件工程活动之间平滑过渡
  • 提供了高层确认的手段

2. 应用形式化准则

  • 选用适当的表示方法
  • 应该形式化,但不要过分形式化
  • 应该估算成本
  • 应该有形式化顾问随时提供咨询
  • 不应该放弃传统的开发方法
  • 应该建立详尽的文档
  • 不应该放弃质量标准
  • 应该测试,测试再测试
  • 应该重用

第五章 总体设计

设计过程

总体设计分为

2个阶段

  • 系统设计阶段
    确定系统的具体实现方案
  • 结构设计阶段
    确定软件结构

9个步骤

  • 设想供选择的方案
  • 选取合理的方案
  • 推荐最佳方案
  • 功能分解
  • 设计软件结构
  • 设计数据库
  • 制定测试计划
  • 书写文档
  • 审查和复审

2.设计原理

设计原理的相关概念

  • 模块化:
    就是把程序划分成独立命名且可独立访问的模块,每个模块完成一个子功能,这些模块集成起来构成一个整体,可以完成指定的功能满足用户的需求
  • 抽象:
    抽出事物本质特性而暂时不考虑细节
  • 逐步求精:
    为了能集中精力解决最主要问题而尽量推迟对问题细节的考虑。逐步求精是人类解决复杂问题时采用的基本方法,也是许多软件工程技术的基础
  • 信息隐藏:
    应该这样设计和确定模块,使得一个模块内包含的信息对于不需要这些信息的模块来说是不能访问的
  • 局部化:
    是指把一些关系密切的软件元素物理地址放得彼此靠近
  • 模块独立:
    是模块化、抽象、信息隐藏和局部化的概念的直接结果。独立的程度测量标准:内聚、耦合
    • 耦合:是对一个软件结构内不同模块之间互连程度的度量。耦合强弱取决于模块间接口的复杂程度,进入或访问一个模块的点,以及通过接口的数据。耦合程度强烈影响着系统的可理解性、可测试性、可靠性、可维护性。设计原则:尽量使用数据耦合,少用控制耦合和特征耦合,限制公共环境的耦合的范围,完全不用内容耦合

      • 数据耦合:如果两个模块彼此间通过参数交换信息,而且交换的信息仅仅是数据。数据耦合是低耦合
      • 控制耦合:传递的信息中有控制信息。中等耦合,增加了系统的复杂性
      • 特征耦合:当整个数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素时
      • 公共环境耦合:当两个或多个模块通过一个公共数据环境互相作用时。公共环境可以是全程变量、共享通信区、内存的公共覆盖区、任何存储介质的文件、物理设备等。
      • 内容耦合:如果发生之一就是:
        • 一个模块访问另一个模块的内部数据
        • 一个模块不通过正常入口而转到另一个模块的内部
        • 两个模块有一部分程序代码重叠
        • 一个模块有多个入口
    • 内聚:标志着一个模块内各个元素彼此之间结合的紧密程度,它是信息隐藏和局部化概念的扩展。设计原则:力求高内聚,通过提高模块间的内聚降低耦合从而使模块获得较高的独立性。高内聚意味着低耦合

      • 低内聚
        • 偶然内聚:如果一个模块完成一组任务,这些任务彼此之间有关系,关系也是很松散的。如在一个程序内有一组语句在两处或多处出现,于是把这些语句作为一个模块以节省内存
        • 逻辑内聚:如果一个模块完成的任务在逻辑上属于相同或相似的一类。如一个模块产生各种类型的全部输出
        • 时间内聚:如果一个模块包含的任务必须在同一时间内执行。如模块完成各种初始化工作
      • 中内聚
        • 过程内聚:如果一个模块内的处理元素是相关的,且必须以特定次序执行。如流程图确定模块的划分,得到的往往是过程内聚的模块
        • 通信内聚:如果一个模块中所有元素都是用同一个输入数据和产生同一个输出数据
      • 高内聚
        • 顺序内聚:如果一个模块内的处理元素和同一个功能密切相关,且这些处理必须顺序执行。如一个处理元素的输出数据作为下一个处理元素的输入数据,根据数据流图划分模块得到往往是顺序内聚模块
        • 功能内聚:如果模块内的所有处理元素属于一个整体,完成单一的功能

      内聚评分

      类型 功能内聚 顺序内聚 通信内聚 过程内聚 时间内聚 逻辑内聚 偶然内聚
      评分 10 9 7 5 1 1 0

3. 启发规则

  • 改进软件结构提高模块的独立性
  • 模块规模应该适中
  • 深度、宽度、扇出和扇入都应适当
    • 深度:软件结构控制的层数
    • 宽度:同一个层次上的模块总数的最大值
    • 扇出:一个模块直接控制(调用)的模块数,平常应该控制在3-4个(上限5-9个)
    • 扇入:有多少个上级模块之间调用它,越大越好,但不能盲目追求多
  • 模块的作用域应该在控制域内
  • 力争降低模块接口的复杂程度
  • 设计单入口单出口的模块
  • 模块的功能应该可预测

4. 描绘软件结构的图形工具

  • 层次图:描绘软件的层次结构。一个矩形框代表一个模块,方框间的连线表示调用关系
  • HIPO图:"层次图加输入/处理/输出图",就是在层次图的每个方框加编号
  • 结构图:每个方框代表一个模块,框内注明模块的名字或主要功能,方框间的箭头(或直线)代表模块的调用关系,注释表示来回传递的信息

    尾部空心圆表示传递数据,实心圆代表传递控制信息

5. 面向数据流的设计方法

概念

  • 变换流:
    信息以外部世界的形式进入软件系统,经过处理后再以外部时间的形式离开系统
  • 事务流:
    据沿输入通路到达一个处理T,这个处理根据输入数据的类型在若干个动作序列中选出一个来执行。这类数据流应该划为一类特殊的数据流﹐称为事务流。

变换分析

变换分析是一系列设计步骤的总称,经过这些步骤把具有变换流特点的数据流图按预先确定的模式映射成软件结构。

第六章 详细设计

详细设计阶段的根本目标是确定应该怎样具体地实现所要求的系统,也就是说,经过这个阶段的设计工作,应该得出对目标系统的精确描述,从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。

1. 结构程序设计

如果只允许使用顺序、IF THEN_ELSE型分支和 DO_WHILE型循环这3种基本控制结构,则称为经典的结构程序设计;如果除了上述3种基本控制结构之外,还允许使用DO-CASE型多分支结构和DO_UNTIL型循环结构,则称为扩展的结构程序设计;如果再允许使用LEAVE(或BREAK)结构,则称为修正的结构程序设计。

2. 人机界面设计指南

  • 一般交互指南
  • 信息显示指南
  • 数据输入指南

3. 过程设计的工具

程序流程图:

  • 优点:对控制流程的描绘直观,初学者很容易掌握
  • 缺点:
    • 程序流程图不是精益求精的好工具,它诱使程序员过早地考虑程序的控制流程,而不去考虑全局结构
    • 程序流程图中用箭头代表控制流 ,因此程序员不受任何约束,可以完全不顾结构程序设计的思想,随意转移
    • 程序流程图不易表示数据结构

盒图(N-S图)

  • 功能域明确
  • 不可能任意转移控制
  • 很容易确定局部和全局数据的作用域
  • 很容易表现嵌套关系,也可以表示模块的层次结构

问题分析图(PAD图)

使用二维结构的图来表示程序的控制流。

其优点:

  • 使用PAD符号设计出来必然是结构化程序
  • PAD图描绘的程序结构十分清楚
  • PAD图表现程序的逻辑,易读、易懂、易记
  • 很容易将PAD图转化为高级语言程序
  • 即可表示程序逻辑,也可表示数据结构
  • PAD符号支持自动向下,逐步求精

判定表

当算法中含有多重嵌套的条件选择时

  • 优点:能清晰表示复杂的条件组合与应做的动作之间的关系
  • 缺点:
    • 判定表的含义不能一眼看出来
    • 当数据元素多于两个时,判定表的简洁程度下降

判定树

判定表变种

  • 优点:一眼看出其含义,易于掌握,使用
  • 缺点:
    • 简洁性不如判定表,数据元素需重复写多遍
    • 判定树的分支次序对画出的判定树的简洁程度有较大影响

4. 面向数据结构的设计方法

Jackson方法和Warnier方法是两个著名的面向数据结构的设计方法。

Jackson方法

数据元素彼此间的逻辑关系只有顺序、选择、重复三种。

Jackson方法由以下步骤组成:

  • 分析并确定输入数据和输出数据的逻辑结构,并用Jackson图描绘这些图的结构。
  • 找出输入数据结构和输出结构中有对应关系的数据单元。
  • 利用以下规则从描绘数据结构的Jackson图导出描绘程序结构的Jackson图
    • 为每对有对应关系的数据单元﹐按照它们在数据结构图中的层次在程序结构图的相应层次画一个处理框(注意﹐如果这对数据单元在输入数据结构和输出数据结构中所处的层次不同,则和它们对应的处理框在程序结构图中所处的层次与它们之中在数据结构图中层次低的那个对应)。
    • 根据输入数据结构中剩余的每个数据单元所处的层次,在程序结构图的相应层次分别为它们画上对应的处理框。
    • 根据输出数据结构中剩余的每个数据单元所处的层次,在程序结构图的相应层次分别为它们画上对应的处理框。
  • 列出所有的操作和条件,并分配到程序结构图的适当位置。
  • 用伪代码表示。

5. 程序复杂程度的定量度量

McCabe方法

McCabe根据程序控制流的复杂程度度量 程序的复杂程度,这样度量出的结果称为程序的环形复杂度

  • 流图的表示:

    • 结点:用圆表示,一个圆代表一条或多条语句
    • 边:箭头线称为边,代表控制流
    • 区域:由边和结点围成的面积 称为区域,当计算区域数时应该包括图外未被围起来的区域
    • 判定结点:包含条件的结点
  • 计算环形复杂度的方法:

    • 流图中线性无关的区域数等于环形复杂度
    • 流图G的环形复杂度 V(G)=E-N+2,其中E是流图中边的条数,N是结点数
    • 流图G的环形复杂度 V(G)=P+1,其中P是流图中判定结点的数目

第七章 实现

实现包括编码测试

1.编码

编码:把详细设计结果翻译成某种程序语言书写的程序
软件测试:是保证软件质量的关键步骤,是对软件规格说明、设计和编码的最后复审

2.测试

测试的目标

  • 测试是为了发现程序中的错误而执行程序的过程。
  • 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。
  • 成功的测试是发现了至今为止尚未发现的错误的测试。

测试的准则

  • 所有测试都应该能追溯到用户需求
  • 应该远在测试开始之前就制定出测试计划
  • 应用Pareto原理

    测试中发现的80%的错误是由于20%的模块引起的

  • 应该从小规模测试开始,并逐步进行大规模测试
  • 穷举测试是不可能的
  • 应该由独立的第三方从事测试工作

测试步骤

  1. 模块测试
  2. 子系统测试
  3. 系统测试
  4. 验收测试
  5. 平行测试

单元测试

单元测试集中检测软件设计中的最小单元——模块。

单元测试的测试重点包括:

  • 模块接口
  • 局部数据结构
  • 重要的执行通路
  • 出错处理通路
  • 边界条件

集成测试

集成测试是测试和组装软件的系统化技术。

由模块组装成程序时有两种方法。

  • 非渐增式测试方法:分别测试每个模块,再按要求结合
  • 渐增式测试:把下一个要测试的模块同已经测试好的模块结合起来测试。

渐增式测试包括两种集成策略:

  • 自顶向下集成
    从主控制模块开始,沿着程序的控制层次向下移动,逐渐将各个模块结合起来
  • 自底向上集成
    从“原子”模块开始组装和测试

回归测试是指重新执行已经做过的测试的某个子集,以保证上述这些变化没有带来非预期的作用。

确认测试

确认测试也叫验收测试,目的式验证软件的有效性

  • 测试范围:有用户积极参与,以用户为主的测试
  • 内容:复制软件配置
  • 方法:
    • alpha测试
      由用户在开发者的场所进行,在开发者对用户的指导下进行测试
    • beta测试
      由软件的最终用户们在一个或多个客户场所进行。

测试方法

  • 白盒测试
    把程序看成装在一个透明的白盒子里,测试者完全知道程序的结构和处理算法。

    白盒测试的典型技术

    • 逻辑覆盖
      • 语句覆盖
      • 判定覆盖
      • 条件覆盖
      • 判定\条件覆盖
      • 条件组合覆盖
      • 点覆盖
      • 边覆盖
      • 路径覆盖
    • 控制结构测试
      • 基本路径结构
      • 条件测试
      • 循环测试
  • 黑盒测试
    把程序看作一个黑盒子,完全不考虑程序的内部结构和处理过程

    黑盒测试的典型技术

    • 等级划分
    • 边界值分析
    • 错误推理

3. 调试

调试是指在测试发现错误之后排除错误的过程。
调试途径包括:

  • 蛮干法
  • 回溯法
  • 原因排除法

4.软件可靠性

软件可靠性

软件可靠性是指程序在给定的时间间隔内,按照规格说明书的规定成功地运行的概率。

软件可用性

软件可用性是指程序在给定的时间点,按照规格说明书上的规定,成功地运行的概论。

第八章 维护

软件维护的定义:就是在软件已经交付使用之后,为了改正错误或满足新的需要而修改软件的过程

1. 软件维护的特点

结构化维护和非结构化维护

非结构化维护

  • 如果软件配置的唯一成分是程序代码,那么维护活动从评价代码开始,而且由于内部文档不足而使评价更困难
  • 非结构化维护需要付出巨大代价,是没有使用良好定义的方法学开发出来的必然结果

结构化维护

  • 如果有一个完整软件配置存在,那么维护从评价设计文档开始就很规范
  • 减少精力的浪费,提高维护的总体质量

2. 决定软件可维护的因素

  • 可理解性
  • 可测试性
  • 可修改性
  • 可重用性

第九章 面向对象方法学引论

1. 面向对象方法学要点

  • 基本原则:

    尽可能模拟人类习惯的思维方式,是开发软件的方法和过程尽可能接近人类认识的世界解决问题的方法和过程

  • 4个要点

    • 软件是由对象组成的,任何元素都是对象,复杂软件对向由比较简单的软件对象组成
    • 所有对象都划分成对象类,类都定义了一组数据和一组方法
    • 若干对象类组成一个层次的系统
    • 对象间仅能通过传递消息互相联系
  • 面向对象方法学优点

    • 与人类习惯的思维方法一致
    • 稳定性好
    • 可重用性好
    • 较易开发大型软件产品
    • 可维护性好

2.面向对象的概念

对象:是描述该对象属性的数据以及对这些数据施加的所有操作封装在一起构成的统一体

对象的定义

  • 对象是具有相同状态的一组操作的集合
  • 对象是对问题域中某个东西的抽象
  • 对象::=

对象的特点

  • 以数据为中心
  • 对象是主动
  • 实现了数据的封装
  • 本质上具有并行性
  • 模块独立性好

其它概念

  • 类:是一组具有相同属性和相同操作的对象的集合。
  • 实例:由某个特定的类所描述的一个具体的对象。
  • 消息:要求某个对象执行在定义它的那个类中所定义的某个操作的规格说明。组成部分:接收消息的对象;消息名;消息变元
  • 方法:就是对象所能执行的操作,也就是类中所定义的服务。
  • 属性:属性就是类中所定义的数据,它是对客观世界实体所具有的性质的抽象。
  • 封装:对象封装了对象的数据以及对这些数据的操作。
  • 继承:继承是子类自动地共享基类中定义的数据和方法的机制。
  • 单重继承:子类仅从一个父类继承属性和方法
  • 多重继承:子类可从多个父类继承属性和方法
  • 多态性:指子类对象可以像父类那样使用
  • 函数重载:指在同一作用域内的若干参数特征不同的函数可以使用相同的函数名
  • 运算符重载:指在同一个运算符可以施加于不同类型的操作数上面

第十章 面向对象分析

1. 建立对象模型

  • 三个子模型,按所解决的问题进行划分

    • 静态结构(对象模型)
    • 交互次序(动态模型)
    • 数据变换(功能模型)
  • 5个层次

    • 主题层
    • 类与对象层
    • 结构层
    • 属性层
    • 服务层

对象模型创建的步骤

  • 确定类与对象
  • 确定关联
  • 划分主题
  • 确定属性
  • 识别继承关系
  • 反复修改

第十一章 面向对象设计

面向对象设计准则

  • 模块化
  • 抽象
  • 信息隐藏
  • 弱耦合
  • 强内聚
  • 可重用

类构件的重用方式

  • 实例重用
  • 继承重用
  • 多态重用

本文作者:asdio

本文链接:https://www.cnblogs.com/agitm/p/16078768.html

版权声明:本作品采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行许可。

posted @   asdio  阅读(1152)  评论(0编辑  收藏  举报
点击右上角即可分享
微信分享提示
评论
收藏
关注
推荐
深色
回顶
收起