04 第04章 设计工程.pptx

第1页：软件工程第4章设计工程

软件工程第4章设计工程

第2页：内容摘要

内容摘要

• 软件设计工程概述
• 软件设计原则
• 软件体系结构设计
• 部件级设计技术
• 设计规约与设计评审

第3页：内容摘要（续）

内容摘要

• 软件设计工程概述
• 软件设计原则
• 软件体系结构设计
• 部件级设计技术
• 设计规约与设计评审

第4页：软件设计工程概述

软件设计工程概述

• 软件需求分析解决“做什么”的问题，软件设计过程则解决“怎么做”的问题
• 软件设计是把软件需求变换成软件表示的过程，它主要包含两个阶段：软件体系结构设计阶段和部件级设计
• 对比：早期的软件设计局限于数据结构和算法层面上，抽象层次比较低

第5页：为什么要进行软件系统设计

为什么要进行软件系统设计

• 软件系统实现的高层方案
  • 软件系统越来越复杂，需要将其划分为若干部分分而治之
  • 模块化
• 不同的小组或开发者负责不同的部分
• 然后在系统层面上进行集成
  • 负责不同部分的开发者对于其它模块需要了解的信息越少越好
  • 抽象与信息隐藏
  • 这些部分之间还需要定义清晰、明确的接口
  • 接口设计

第6页：软件系统设计的重要性

软件系统设计的重要性

• 软件系统设计是开发者之间的分工和合作和基础
• 设计方案是决定系统质量的主要因素
  • 设计方案可以借鉴成熟的设计经验
  • 设计方案完成后需要经过质量分析和评审
• 好的设计方案不仅能很好地支持当前需求的实现，而且能减小未来的系统维护(理解、修改、扩展)成本

第7页：软件设计的任务

软件设计的任务

• 在软件分析模型中的需求信息(数据、功能和行为)基础上，产生软件系统各个层次上的设计方案

第8页：数据/类设计

• 数据/类设计：将分析-类模型变换成类的实现和软件实现所需要的数据结构
• 体系结构设计：体系结构设计定义了软件的主要结构元素以及相互之间的关系
• 接口设计：接口设计描述了软件内部、软件和协作系统之间以及软件同人之间如何通信
• 部件级设计：部件级设计将软件体系结构的结构性元素变换为对软件部件的过程性描述

第9页：设计任务1—数据/类设计

设计任务1—数据/类设计

• 基础：在类和CRC中定义的数据对象和关系(实体及实体关系)以及数据字典中描述的详细数据内容(详细信息)
• 数据设计的过程
  • 为在需求分析阶段所确定的数据对象选择逻辑表示
  • 确定对逻辑数据结构所必需的那些操作的程序模块

第10页：设计任务2—体系结构设计

设计任务2—体系结构设计

• 定义软件的整体结构：软件部件、外部可见的属性和它们之间的关系
• 体系结构设计：可以从系统规约、分析模型和分析模型中定义的子系统的交互导出

第11页：设计任务3—接口设计

设计任务3—接口设计

• 接口设计主要包括三个方面
  • UI：用户和计算机间的接口(界面)
  • 和外部系统、设备、网络或信息生产者和消费者(比如外部实体)之间的接口
• 外部系统接口：银行网上支付接口
• 设备接口：读卡器、扫描枪、传感器接口
• 信息接口：需要导入/导出的数据接口
  • 设计软件内部各个部件间的接口

第12页：设计任务4—部件级设计

设计任务4—部件级设计

• 部件级设计完整地描述每个软件部件的内部细节
  • 部件整体的处理和执行流程
  • 部件内本地数据对象的数据结构
  • 部件内处理过程的算法
• 从类为基础的模型、流模型、行为模型中得到的信息是部件设计的基础

第13页：软件设计的

软件设计的(质量)目标

• 满足用户需求
  • 必须实现分析模型中所有的显式需求
  • 必须满足用户希望的所有隐式需求
• 可读、可理解：设计必须是可读、可理解的，使得将来易于编程、易于测试、易于维护
• 全面性：应从实现角度出发，给出与数据、功能、行为相关的软件全貌

第14页：衡量设计的技术原则

衡量设计的技术原则-1

• 分层的设计结构：从而建立软件系统的分层控制结构
• 模块化：从逻辑上将软件划分为完成特定功能或子功能的部件
• 数据与过程：设计既包含数据抽象，也包含过程抽象

第15页：衡量设计的技术原则（续）

衡量设计的技术原则-2

• 高内聚：建立具有独立功能特征的模块
• 低耦合：尽量降低模块与外部环境之间的接口复杂度
• 系统化/方法化：设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法

第16页：软件设计的过程

软件设计的过程-1

• 制定设计规范
  • 通过阅读系统需求说明书确定设计目标以及这些目标的优先顺序
  • 设计方法：结构化、面向对象…
  • 设计文档的编制标准
  • 基本的实现规范：代码的信息形式、与硬件及操作系统的接口规约、命名规则

第17页：软件设计的过程（续）

软件设计的过程-2

• 迭代展开、不断细化的系统设计
  • 体系结构和接口设计
  • 数据/类设计
  • 部件级(过程)设计
• 编写设计文档
• 设计评审

第18页：内容摘要

内容摘要

• 软件设计工程概述
• 软件设计原则
• 软件体系结构设计
• 部件级设计技术
• 设计规约与设计评审

第19页：软件设计的基本原则

软件设计的基本原则

• 抽象：考虑高层问题时忽略低层细节
• 逐步求精：不断接近问题的完整解
• 模块化：将系统划分为相对独立但又有所关联的多个部分
• 信息隐藏：对其它模块隐藏内部细节
• 模块独立：模块功能相对独立
  • 高内聚/低耦合

第20页：软件设计的基本原则（续）

抽象

• 控制复杂性的基本策略
• 抽象过程：从特殊到一般的过程，上层概念是下层概念的抽象，下层概念是上层概念的精化和细化
• 软件开发过程的每一步都是对较高一级抽象的解作一次具体化的描述
  • 与实现无关的需求
  • 考虑特定实现技术的设计、将每个模块逐一编码实现……

第21页：过程抽象与数据抽象

过程抽象与数据抽象

• 过程抽象：功能角度的抽象
  • 使用者将功能体作为单个功能看待
  • 这些功能实际上是由一系列更低级的功能或代码来实现的
  • 过程抽象例：函数、功能性的类/对象
• 数据抽象
  • 定义数据类型和施加于该类型对象的操作
  • 限定了对象的取值范围，只能通过这些操作修改和观察数据
• 例如面向对象的person类封装实际年龄，public接口上开放的是转换为老年/中年/青年/少年…后的年龄段信息

第22页：逐步求精

逐步求精

• 把问题的求解过程分解成若干步骤或阶段，每步都比上步更精化，更接近问题的解法
• 常与分层抽象的思想相结合
  • 抽象使得设计者能够描述过程和数据而忽略低层的细节
  • 求精有助于设计者在设计过程中揭示低层的细节
  • 高层抽象将在下层不断精化，最终得到软件实现

第23页：模块化

模块化(分解)

• 按照设计原则将系统划分为若干个较小的模块
  • 相互独立但又相互关联
  • 实际上是系统分解和抽象的过程
• 模块是相对独立的程序体
  • 是数据说明、可执行语句等程序对象的集合
  • 单独命名的，并且可以通过名字来访问
• 例如：类、过程、函数、子程序、宏等

第24页：通过模块化降低开发复杂度C

通过模块化降低开发复杂度C(x)：问题x的复杂性E(x)：解决问题x所需工作量对于两个问题p1和p2：1)如果C(p1)>C(p2)那么E(p1)>E(p2)问题越复杂解决问题所需要的花费更多2) C(p1+p2)>C(p1)+C(p2)因此E(p1＋p2)>E(p1)+E(p2)将复杂问题分解成可以多个子问题分别解决会更加容易(模块化思想的依据)

第25页：模块化例

模块化例：智能灌溉

• 总体设计：将系统划分为传感器、灌溉决策和灌溉设备控制三个模块，定义好相互之间的数据和控制接口
  • 传感器模块：接受传感器收集的温度、湿度、土壤等各种数据
  • 灌溉决策：根据种植经验和收集到的数据判断灌溉决策
  • 灌溉设备控制：根据决策控制灌溉设备进行灌溉降低整体复杂度：可以分而治之而且可以由具备不同专业知识的开发者分别承担

第26页：模块化例（续）

误区：无限制地进行模块化分?

• 如果我们无限制地划分软件，开发它所需的工作量会变得小到可以忽略?
• 结论：NO
  • 模块数量增加时，只是使各个子模块的工作量之和有所减小
  • 然而开发工作量还有很大一部分来自于模块间的接口和集成
• 除了技术上的接口和集成，还包括人与人之间的沟通
• 集成和沟通的开销到了一定程度就会成为开发工作量的主要部分

第27页：模块化例（续）

结论：适度的模块化

• 模块数增加时，模块间的关系也随之增加，接口和集成的工作量也随之增加
• 结论：寻找最佳模块化程度平衡点

第28页：信息隐藏

信息隐藏

• 每个模块都尽量对其他模块隐藏自己的内部实现细节
  • 模块内部的数据和过程不允许其它不需要这些信息的模块使用
  • 定义和实施对模块的过程细节和局部数据结构的存取限制
  • 典型的信息隐藏：面向对象的访问控制符
• 信息隐藏是实现抽象/模块化机制的基本支撑

第29页：模块独立

模块独立(高内聚/低耦合)

• 模块独立是模块化的根本要求
  • 模块完成独立的功能：明确可辨识
  • 高内聚：内部结构紧密
  • 低耦合：模块间关联和依赖程度尽可能小，与其他模块的接口简单
  • 符合信息隐蔽和信息局部化原则

第30页：模块独立的重要性

模块独立的重要性

• 模块的开发者专注于某一个相对独立的部分
• 不用过多关心其他模块
• 修改和bug影响的范围被局部化
• 单个模块更容易复用
• 独立的模块更易于维护和测试

第31页：模块独立性的指标

模块独立性的指标

• 内聚度与耦合度
  • 内聚(cohesion)：一个模块内部各个元素彼此结合的紧密程度
  • 尽量高
  • 耦合(coupling)：模块之间相互关联的程度
  • 尽量低

第32页：内聚度的七个层次

内聚度的七个层次-1

• 巧合内聚(偶然内聚)：将几个模块中的相同程序代码段独立出来建立的模块(无明显独立性)
• 逻辑内聚：完成一组逻辑相关任务的模块，由控制型参数来确定执行哪一种功能
• 时间内聚：模块中的多个任务必须在一段时间内先后执行(无明确的过程约束)

第33页：内聚度的七个层次（续）

内聚度的七个层次-2

• 过程内聚：模块内的多个任务必须按指定的过程执行
• 通信内聚：模块内所有处理元素都集中在某个数据结构的一块区域中(例如对课程进行选、退课和查询)
• 顺序内聚：指一个模块完成多个功能，这些功能又必须顺序执行(更加单一的过程内聚)
• 功能内聚：指一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割的(单个功能)

第34页：耦合度的七个层次

耦合度的七个层次-1

• 内容耦合：一个模块可以直接访问另一个模块的内部数据或内部功能
• 公共耦合：多个模块共同访问某些公共数据元素
• 外部耦合：多个模块间需要遵循同样的外部约束，例如通信协议、数据格式等

第35页：耦合度的七个层次（续）

耦合度的七个层次-2

• 控制耦合：模块间的交互参数包含控制信息，可影响另一个模块的执行逻辑
• 标记耦合：模块间传递特定的数据结构
• 数据耦合：模块间仅传递简单数据
• 非直接耦合：两个模块可以相对独立工作

第36页：模块独立性

模块独立性：高内聚低耦合

• 模块独立性的模块：高内聚低耦合的模块
  • 一个模块内部各个元素之间的联系越紧密，则它的内聚性就越高
  • 模块之间的连接越紧密，联系越多，耦合性就越高，而其模块独立性就越弱

第37页：内容摘要

内容摘要

• 软件设计工程概述
• 软件设计原则
• 软件体系结构设计
• 部件级设计技术
• 设计规约与设计评审

第38页：软件体系结构设计

软件体系结构设计

• 软件体系结构关注系统的一个或多个结构，包含软件部件、部件对外可见的属性以及部件间的关系
• 体系结构的作用
  • 方便利益相关人员的交流
  • 有利于系统设计的前期决策
  • 可传递、易于理解的系统级抽象

第39页：

第40页：体系结构发展过程

体系结构发展过程-1

• 单主机结构
  • 界面、数据和程序集中在单台主机上
  • 不需要考虑多用户并发操作的问题
• C/S(Client/Server)结构
  • 常见的服务器端体现为关系数据库
  • 客户端负责显示和业务逻辑处理
  • 在部署和扩展性方面存在不足：系统升级需要一一更新所有客户端

第41页：体系结构发展过程（续）

体系结构发展过程-2

• B/S(Browser/Server)结构
  • 瘦客户端：浏览器或客户端程序(Applet等)
  • 三层结构
• 客户端：处理用户接口和用户请求
• Web服务器端：处理Web服务和运行业务代码
• 数据端：关系型数据库和其他后端数据资源
  • 新的发展：多层结构
• Web服务器分离为Web端和业务服务端(例如J2EE应用服务器)

第42页：软件体系结构风格

软件体系结构风格

• 体系结构风格定义了一系列系统的结构组织的模式，它是对一类具有相似结构的系统体系结构的抽象
  • 一些实现系统所需的功能的部件
  • 连接各个部件，负责部件间通信和协作的连接器
  • 定义部件之间怎样整合的系统约束
  • 使设计者能够理解整个系统属性并分析已知属性的语义模型

第43页：数据为中心体系结构

数据为中心体系结构

• 一些数据(比如一个文件或者数据库)保存在整个结构的中心，并且被其他部件频繁地使用、添加、删除、或者修改

第44页：数据流风格的体系结构

数据流风格的体系结构

• 又称管道/过滤器体系结构风格
• 这种结构适用于输入数据被一系列的计算或者处理部件变换成输出数据。

第45页：调用和返回风格的体系结构

调用和返回风格的体系结构

• 这种风格使一个软件设计者设计出非常容易修改和扩充的体系结构
  • 主程序/子程序风格体系结构
  • 远程过程调用风格的体系结构

第46页：在这里要了解几个概念

• 在这里要了解几个概念：
  • 程序结构的深度：程序结构的层次数称为结构的深度。结构的深度在一定意义上反映了程序结构的规模和复杂程度。
  • 程序结构的宽度：层次结构中同一层模块的最大模块个数称为结构的宽度。
  • 模块的扇入和扇出：扇出表示一个模块直接调用（或控制）的其它模块数目。扇入则定义为调用（或控制）一个给定模块的模块个数。多扇出意味着需要控制和协调许多下属模块。而多扇入的模块通常是公用模块。

第47页：面向对象风格的体系结构

面向对象风格的体系结构

• 系统部件封装数据和操作数据的方法
• 部件之间的交互和协调通过消息来传递

第48页：层次式风格的体系结构

层次式风格的体系结构

• 在这种结构中，定义不同的层次，每层都完成了相对外层更靠近机器指令的操作

第49页：评估可选的体系结构

评估可选的体系结构

• 对于同一个软件需求，由于各种设计方法的原理不同，会导出不同的软件结构。
• 同一问题的不同软件结构：

第50页：评估可选的体系结构（续）

ATAM（architecture trade-offanalysis method）1)定义应用场景（scenarios）：通过usecase图来从用户的角度表现系统。2)得出需求、约束和环境描述：这是需求工程的一部分，用以确定所有客户方关心的问题都被列出。3)描述能处理上述情境和需求的体系结构风格。4)单独地评价系统的各项性能。针对体系结构设计的性能包括：可靠性，性能、安全性，可维护性，灵活性，可测试性，可移植性，可重用性和互操作性等。

第51页：评估可选的体系结构（续）

ATAM（architecture trade-offanalysis method）5)针对不同的架构形式，评价第4步提到的这些性能的敏感程度。可以通过这样的方法来评价：在整个架构中做一些小的变更，分析并确定上诉性能有没有很敏感的变化。那些在体系结构改动中受到较大影响的性能被称为敏感点（sensitive point）。6)通过第5步的敏感度分析来评价第三步中提出的那些体系结构。SEI描述的方法如下：当一个架构的敏感点被确定，我们需要找到在系统中最需要权衡利弊的因素（trade-off point）。权衡因素就是指改变架构中的这项内容系统的很多性能就会发生敏感的变化。比如说，一个client-server结构的系统的表现性能和系统中server的数量是息息相关的（比如增加server的数量，一定程度上系统的表现性能就会提高）……这样的话，server的数量就是这个架构中的平衡点。

第52页：在进行软件体系结构设计时

• 在进行软件体系结构设计时，可以参考如下规则：(1)改进软件结构提高模块独立性(2)模块适当的深度、宽度、扇出和扇入(3)模块判断作用范围应在其控制作用范围内(4)力争降低模块接口的复杂度(5)设计单入口单出口的模块(6)模块功能应该是可以预测的模块大小适中(7)一般一个模块包含的语句在30～50条左右较好。(8)一个设计好的软件结构，通常顶层扇出比较高，中层扇出比较少，底层有高扇入。

第53页：内容摘要

内容摘要

• 软件设计工程概述
• 软件设计原则
• 软件体系结构设计
• 部件级设计技术
• 设计规约与设计评审

第54页：部件级设计技术

部件级设计技术

• 在结构化分析和设计方法时部件往往被称为模块
• 在面向对象分析和设计时部件被称为类，在基于构件的开发方法中，部件被称为构件。

第55页：部件级设计技术在部件级设计阶段

部件级设计技术在部件级设计阶段，主要完成如下工作：(1)为每个部件确定采用的算法，选择某种适当的工具表达算法的过程，编写部件的详细过程性描述；(2)确定每一部件内部使用的数据结构；(3)在部件级设计结束时，应该把上述结果写入部件级设计说明书，并且通过复审形成正式文档，作为下一阶段（编码阶段）的工作依据。

第56页：结构化程序设计方法

结构化程序设计方法

• 一种较为流行的定义是：“如果一个程序的代码块仅仅通过顺序、选择和循环这三种基本控制结构进行连结，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的”。
• 随着面向对象和软件复用等新的软件开发方法和技术的发展，更现实、更有效的开发途径可能是自顶向下和自底向上两种方法有机的结合。

第57页：图形表示法

图形表示法

• 程序流程图
• N-S图
• PAD

第58页：程序流程图

程序流程图

• 程序流程图独立于任何一种程序设计语言，比较直观、清晰、易于学习掌握
• 为使用流程图描述结构化程序，必须限制流程图只能使用五种基本控制结构

第59页：控制结构相互组合和嵌套的实例

控制结构相互组合和嵌套的实例

第60页：控制结构相互组合和嵌套的实例（续）

N-S图

• Nassi和Shneiderman提出了一种符合结构化程序设计原则的图形描述工具，叫做盒图，也叫做N-S图
• 五种基本控制结构

第61页：控制结构相互组合和嵌套的实例

控制结构相互组合和嵌套的实例

第62页：控制结构相互组合和嵌套的实例（续）

PAD

• PAD是Problem Analysis Diagram的缩写，由程序流程图演化而来
• 五种基本控制结构

第63页：控制结构相互组合和嵌套的实例（续）

PAD实例

第64页：判定表

判定表

• 当算法中包含多重嵌套的条件选择时，用程序流程图、N-S图或PAD都不易清楚地描述。
• 然而，判定表却能清晰地表达复杂的条件组合与应做动作之间的对应关系。
• 图4-11的例子，把多分支判断改为两分支判断

第65页：不包含多分支结构的流程图实例

不包含多分支结构的流程图实例

第66页：反映程序逻辑的判定表

反映程序逻辑的判定表

第67页：判定表的优点是能够简洁

• 判定表的优点是能够简洁，无二义性地描述所有的处理规则。
• 但判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构

第68页：设计性语言PDL

设计性语言PDL

• PDL（Program Design Language）是一种用于描述功能部件的算法设计和处理细节的语言，称为设计性语言。
• 它是一种伪码。一般地，伪码的语法规则分为“外语法”和“内语法”
  • 外语法应当符合一般程序设计语言常用语句的语法规则；
  • 内语法可以用英语中一些简单的句子、短语和通用的数学符号，来描述程序应执行的功能

第69页：的使用实例

PDL的使用实例

• PROCEDUREspellcheckIS查找错拼的单词BEGINsplit document into single words把整个文档分离成单词lood up words in dictionary在字典中查这些单词display words which are not indictionary显示字典中查不到的单词create a new dictionary造一新字典ENDspellcheck

第70页：的使用实例（续）

PDL特点1.有固定的关键字外语法，提供全部结构化控制结构、数据说明和部件特征。属于外语法的关键字是有限的词汇集，它们能对PDL正文进行结构分割，使之变得易于理解。为了区别关键字，规定关键字一律大写，其它单词一律小写。2.内语法使用自然语言来描述处理特性。内语法比较灵活，只要写清楚就可以，不必考虑语法错，以利于人们可把主要精力放在描述算法的逻辑上。3.有数据说明机制，包括简单的（如标量和数组）与复杂的（如链表和层次结构）的数据结构。4.有子程序定义与调用机制，用以表达各种方式的接口说明。

第71页：内容摘要

内容摘要

• 软件设计工程概述
• 软件设计原则
• 软件体系结构设计
• 部件级设计技术
• 设计规约与设计评审

第72页：设计规约A

设计规约A.系统目标Ⅰ.工作范围B.运行环境C.主要软件需求D.设计约束∕限制A.数据流与控制流复审Ⅱ.体系结构设计B.导出的程序结构C.功能与程序交叉索引A.数据对象与形成的数据结构Ⅲ.数据设计B.文件和数据库结构ⅰ文件的逻辑结构ⅱ文件逻辑记录描述ⅲ访问方式C.全局数据D.文件∕数据与程序交叉索引A.人机界面规格说明Ⅳ.接口设计B.人机界面设计规则C.外部接口设计ⅰ外部数据接口ⅱ外部系统或设备接口D.内部接口设计规则

第73页：处理与算法描述Ⅴ

A.处理与算法描述Ⅴ.各部件的过程设计B.接口描述C.设计语言(或其它)描述D.使用的部件E.内部程序逻辑描述F.注释∕约束∕限制A.运行部件组合Ⅵ.运行设计B.运行控制规则C.运行时间安排A.出错处理信息Ⅶ.出错处理设计B.出错处理对策ⅰ设置后备ⅱ性能降级ⅲ恢复和再启动Ⅷ.安全保密设计Ⅸ.需求∕设计交叉索引A.测试方针Ⅹ.测试部分B.集成策略C.特殊考虑Ⅺ.特殊注解Ⅻ.附录

第74页：设计评审

设计评审

• 软件设计的最终目标是要取得最佳方案
• “最佳”是指在所有候选方案中，就节省开发费用，降低资源消耗，缩短开发时间的条件，选择能够赢得较高的生产率、较高的可靠性和可维护性的方案

第75页：设计评审的内容1．可追溯性

设计评审的内容1．可追溯性：

即分析该软件的系统结构、子系统结构，确认该软件设计是否覆盖了所有已确定的软件需求，软件每一成分是否可追溯到某一项需求。2．接口：即分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。部件是否满足高内聚和低耦合的要求。部件作用范围是否在其控制范围之内。3．风险：即确认该软件设计在现有技术条件下和预算范围内是否能按时实现。4．实用性：即确认该软件设计对于需求的解决方案是否实用。

第76页：设计评审的内容

设计评审的内容（续）5．技术清晰度：即确认该软件设计是否以一种易于翻译成代码的形式表达。6．可维护性：从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。7．质量：即确认该软件设计是否表现出良好的质量特征。8．各种选择方案：看是否考虑过其它方案，比较各种选择方案的标准是什么。9．限制：评估对该软件的限制是否现实，是否与需求一致。10．其它具体问题：对于文档、可测试性、设计过程等等进行评估。

第77页：设计评审

设计评审

• 评审分正式评审和非正式评审两种
• 正式评审除软件开发人员外，还邀请用户代表和领域专家参加，通常采用答辩形式
• 非正式评审多少有些同行切磋的性质，不拘泥于时间和形式

第78页：作业-1第三章需求工程后习题99

作业-1第三章需求工程后习题99.软件需求规约主要包括哪些内容？自己寻找一个实例，亲自写一个需求规约。注：可选择一个自己所了解的某个较小的软件系统，例如小型管理系统、你们所使用的选课系统、一个小型的网上购物网站、编译器原型等

第79页：作业-2第四章设计工程后习题33

作业-2第四章设计工程后习题33.为下面软件问题之一开发一个多层的设计抽象：a.消费者银行应用软件b.计算机图形应用软件的3维变换包c. BASIC语言解释器d.两个自由的机器人控制器e.你和你的导师同意的任何问题随着抽象层次的降低，你的注意力会逐步集中，这样在最后的层次中(源代码)只需要描述单个任务。注：可选择一个自己所了解的某个较小的软件系统，请结合框图等图形手段说明你的多层设计抽象4月14日课上交