软件设计概念
- 什么是软件设计?软件的设计是将需求转变为软件陈述(表达)的过程。这种陈述是一个对软件的全局观点。系统通过逐步求精使得设计陈述逐渐接近程序代码。
第一步是概要设计,关注于怎么将需求转换成数据和软件框架。
第二步是详细设计,关注于将框架逐步求精细化为具体的数据结构和软件的算法表达。
软件设计阶段的输出主要是(D )
A、程序
B、模块
C、伪代码
D、设计规格说明书 - 设计概念
抽象——数据,过程,控制
体系结构——软件的整体结构
模式——传递已验证设计方案的精髓
关注点分离——任何复杂问题在被分解为若干块后将更易处理
模块化——数据和功能的分割
(信息)隐蔽——控制接口
功能独立——单一功能和低耦合
求精——细化所有抽象的细节
方面——理解全局需求如何影响设计的机制
重构——简化设计的重组技术
功能独立
通过开发具有“专一”功能和“避免”与其他模块过多交互的模块,可以实现功能独立。
模块独立:
模块的独立性是指软件系统中每个模块只涉及软件要求的具体的子功能,而和软件系统中其他模块的接口是简单的。
内聚性 显示了某个模块相关功能的强度;
一个内聚的模块执行一个独立的任务,与程序的其他部分构件只需要很少的交互。简单地说,一个内聚的模块应该(理想情况下)只完成一件事情。
耦合性 显示了模块间的相互依赖性;
耦合性依赖于模块之间的接口复杂性、引用或进入模块所在的点以及什么数据通过接口进行传递。
软件设计中划分模块的一个准则是( C )
A、低内聚低耦合
B、低内聚高耦合
C、高内聚低耦合
D、高内聚高耦合
体系结构风格
1.什么是体系结构风格
描述某一特定应用领域中系统组织方式的惯用模式。它反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效地组织成一个完整的系统。
每一种风格描述一种系统类别,包括:
一组构件,它们完成某种功能
一组连接器,它们实现构件间的 “通信、合作和协调”
约束,定义构件如何集成为一个系统
语义模型,使设计者能通过分析系统的构成,来理解系统的整体性质
-
以数据为中心的体系结构:
数据存储驻留在体系结构的中心,其他构件访问该数据存储,并进行各种数据操作
-
数据流体系结构
也称管道/过滤器结构
拥有一组称为过滤器的构件,这些构件通过管道连接,每个过滤器独立于其上游和下游的构件而工作
-
调用和返回体系结构
主程序/子程序体系结构:将功能分解为一个控制层次结构,其中的“主”程序调用一组程序构件,这些程序构件又去调用别的程序构件(此时,对于被调者来说,这些主调者就是主程序)
远程过程调用体系结构:构件分布在网络的多个计算机上。 -
层次体系结构
定义了不同的层次,各个层次完成各自操作
每一层为上层提供服务,又接受下层的服务
体系结构设计
方法:
结构化设计
数据流模型->软件结构图
面向对象设计
用例模型->分析类图->设计类图->构件图
构件级设计
- 如何理解构建级设计:
体系设计——建筑平面图、结构、房间和外部环境之间的连接机制
构件级设计——每个房间的内部细节设计 - 构件图(组件图)包含如下基本要素:
构件(组件)
端口
内部结构
关系 - 构件的组织形式
(1)用包来组织构件。通过包都系统构件进行层次划分,按层次组织构件
(2)用构件之间的交互关系来组织构件。通过定义构件间的依赖关系、继承关系、关联关系和实现关系组织构件,组成构件图 - 构建的分类:
按实现文件分类
(1)源代码构件
(2)二进制构件
(3)可执行构件
按配置方式分类
实施构件
配置构件
工作产品构件 - 基本设计原则:
开闭原则(OCP). “模块[构件]应该对外延具有开放性,对修改具有封闭性.
Liskov替换原则(LSP). “子类可以替换它们的基类.
依赖倒置原则(DIP). “依赖于抽象,而非具体实现.”
接口分离原则(ISP). “多个客户专用接口比一个通用接口要好.
发布复用等价性原则(REP). “复用的粒度就是发布的粒度.”
共同封装原则(CCP). “一同变更的类应该合在一起.”
共同复用原则(CRP). “不能一起复用的类不能被分到一组.”
用户界面设计
人机界面(Human-Computer Interface,HCI)是计算机直接与人打交道的途径,是计算机系统的重要组成部分,它的开发工作量占系统开发工作量的40-60%
黄金规则:
- 把控制权交给用户
- 不强迫用户进入不必要或不希望的交互模式
- 提供灵活的交互
- 允许用户交互被中断和撤销
- 对破坏性操作的确认
- 设置撤销功能
- 当技能级别增长时可以使交互流线化并允许定制交互
- 使用户与内部技术细节隔离
- 设计应允许用户与出现在屏幕上的对象直接交互
- 减少用户的记忆负担
- 减少对短期记忆的要求
- 建立有意义的缺省
- 定义直观的快捷方式
- 界面视觉布局应该基于真实世界的象征
- 以不断进展的方式揭示信息
- 保持界面一致
- 允许用户将当前任务放入有意义的环境中
- 在应用系统家族内保持一致性
- 如果已经建立起用户期望,轻易不要改变它
详细设计所用工具
结构化详细设计也称为结构化程序设计。
结构化程序设计的理念是在20世纪60年代,由Dijkstra等人提出并加以完善的。
一种较为流行的定义是:“如果一个程序的代码块仅仅通过顺序、选择和循环这三种基本控制结构进行连结,并且每个代码块只有一个入口和一个出口,则称这个程序是结构化的”
过程描述语言PDL
过程描述语言(PDL-Procedural Description Language)介于自然语言和形式语言之间的一种半形式化语言,是在自然语言基础上加了一些限定,使用有限的词汇和有限的语句来描述加工逻辑。
外层用来描述控制结构,采用顺序、选择、重复三种基本结构。
内层一般采用祈使语句的自然语言短语,使用数据字典中的名词和有限的自定义词,其动词含义要具体,尽量不用形容词和副词来修饰。
以下是使用PDL语言描述
N=1
WHILE N<=10 DO
IF A(N)<=A(N+1)THEN
MAX =A(N+1);
ELSE
MAX =A(N)
ENDIF;
N=N+1;
END WHILE;
程序流程图
程序流程图又称为程序框图,Goldstine于1946年首先采用。
它的主要优点是对控制流程的描绘很直观,便于初学者掌握。
程序流程图的主要缺点:
程序流程图本质上不是逐步求精的好工具,它诱使程序员过早地考虑程序的控制流程,而不去考虑程序的全局结构;
程序流程图中用箭头代表控制流,因此程序员不受任何约束,可以完全不顾结构程序设计的精神,随意转移控制;
程序流程图不易表示数据结构。
盒图(N-S图)
盒图是由Nassi和Shneiderman提出的,所以又称为N-S图。
每个处理步骤都用一个盒子来表示,这些处理步骤可以是语句或语句序列,在需要时,盒子中还可以嵌套另一个盒子,嵌套深度一般没有限制。
盒图具有下述特点:
功能域(即,一个特定控制结构的作用域)明确,可以从盒图上一眼就看出来。
由于只能从上边进入盒子然后从下面走出盒子,除此之外没有其它的入口和出口,所以盒图限制了任意的控制转移,保证程序有良好的结构。
很容易确定局部和全程数据的作用域。
很容易表现嵌套关系,也可以表示模块的层次结构。
盒图很容易表示程序结构化的层次结构,确定局部和全局数据的作用域。由于没有箭头,因此不允许随意转移控制。
PAD问题分析图
PAD是问题分析图(Problem Analysis Diagram)的英文缩写,自1973年由日本日立公司发明。
它是由程序流程图演化而来,用二维树形结构的图来表示程序的控制流,将这种图翻译成程序代码比较容易。
PAD图的基本原理:采用自顶向下、逐步细化和结构化设计的原则,力求将模糊的问题解的概念逐步转换为确定的和详尽的过程,使之最终可采用计算机直接进行处理。
判定表
例如:某数据流图中有一个“确定保险类别”的加工,指的是申请汽车驾驶保险时,要根据申请者的情况确定不同的保险类别。
加工逻辑为:
如果申请者的年龄在21岁以下,要额外收费;
如果申请者是21岁以上并是26岁以上的女性,适用于A类保险;
如果申请者是26岁以下的已婚男性,或者26岁以上的男性,适用于B类保险;
如果申请者是21岁以下的女性或26岁以下的单身男性适用于C类保险;
除此之外的其他申请者都适用于A类保险。
提取问题中的条件:年龄、性别、婚姻。
标出条件的取值
计算所有条件的组合数N。N=3×2×2
提取可能采取的动作或措施。适用于A类保险、B类保险、C类保险,额外收费共四种。
制作判定表
完善判定表
缺少判定采取的动作
有冗余的列
制作判定表:
合并判定表:
判定树
判定树是判定表的变形,一般情况下它比判定表更直观,且易于理解和使用
IPO 输入加工输出(Input Process Output)图
IPO图,全称输入加工输出(Input Process Output)图,是结构化设计中变换型结构的三要素的缩写。它是对每个模块进行详细设计的工具,由美国IBM公司发起并完善起来,被广泛应用在系统设计阶段,成为重要的文档资料。在IPO图中,会清晰展示模块的输入、处理和输出三个环节,帮助设计者和开发者更好地理解和控制系统的运行过程。
在详细设计阶段所使用到的设计工具是( A)。
A、程序流程图,PAD图,N-S图,判定表,判定树
B、数据流程图,程序流程图,PAD图,N-S图,HIPO图
C、判定表,数据流程图,系统流程图,PAD图,N-S图
D、判定树,数据流程图,系统流程图,程序流程图,层次图
注:HIPO图是一种描述系统结构和模块内部处理功能的工具,由IBM公司于20世纪70年代中期在层次结构图的基础上推出。HIPO图由层次结构图和IPO图两部分构成,前者描述整个系统的设计结构以及各类模块之间的关系,后者描述某个特定模块的输入、输出和处理功能。
详细设计的基本任务是确定每个模块的(D)
A、功能
B、调用关系
C、输入输出数据
D、算法