软件工程 — 详细设计

详细设计的基本任务(六点)

1)为每个模块进行详细的算法设计.
2)为模块内的数据结构进行设计.对于需求分析、概要设计确定的概念性的数据类型进行确切的定义.
3)为数据结构进行物理设计,即确定数据库的物理结构.
4)其他设计：

• 代码设计.
• 输入/输出格式设计.
• 人机对话设计.

5)编写详细设计说明书.
6)评审.

对总体设计划分出来的功能进行算法设计时注意的事项(八项)

1. 性能要求:包括对精度、灵活性和时间特性的要求.
2. 输入项:给出对每一个输入项的特性(名称、标识、数据的类型和格式、数据值的有效范围、输入的方式.数量和频度、输入媒体、输入数据的来源和安全保密条件等等)
3. 输出项:给出对每一个输出项的特性(名称、标识、数据的类型和格式,数据值的有效范围,输出的形式、数量和频度,输出媒体、对输出图形及符号的说明、安全保密条件等等)
4. 流程逻辑:用图表（例如流程图、判定表等）辅以必要的说明来表示本程序的逻辑流程.
5. 接口:用图的形式说明本程序所隶属的上一层模块及隶属于本程序的下一层模块、子程序说明参数赋值和调用方式,说明与本程序相直接关联的数据结构(数据库,数据文卷)
6. 存储分配:根据需要,说明本程序的存储分配.
7. 注释设计:

• 加在模块首部的注释；
• 加在各分枝点处的注释；
• 对各变量的功能、范围、缺省条件等所加的注释；
• 对使用的逻辑所加的注释等等.

8. 限制条件:说明本程序运行中所受到的限制条件.

人机界面设计/用户接口设计

四个重要问题：

1)系统响应时间:

定义:

用户完成某个控制动作到系统响应的时间.它有两个重要属性:长度(响应时间长度) 与易变性(响应时间相对于平均时间的偏差)

2)用户帮助设施:

定义:

用户遇到复杂问题时需要查看用户手册寻找答案的设施

分类:

• • 集成软件帮助设施(一开始就设计在软件中)
  • 附加软件帮助设施(在建立系统后在添加到软件中)
  • [ 普遍认为集成的帮助设施优于附加的帮助设施 ]

具体设计帮助设施时候需要解决的问题:

• • 是提供部分帮助信息还是提供全部帮助信息/span>
  • 用户如何请求帮助/span>one.帮助菜单,two.特殊功能键,three.HELP命令
  • 是否在任何都能请求到功能的帮助信息,请求到的帮助信息是提供部分还是全部/span>
  • 怎样显示帮助信息/span>one.独立的窗口,two.在屏幕固定位置,three.简短提示
  • 用户怎样回到正常交互方式中去/span>one.按屏幕的返回按钮,two.功能键
  • 如何组织帮助信息/span>one.平面结构(所有信息都靠关键字访问),two.信息的层次结构(用户在该结构可以查到更纤细的信息),three.超文本结构

3)出错信息/警告处理:

定义:

用户在和机子交互的过程中给出的”坏消息”.

出错信息/警告消息需具备那些特性:

• • 用用户可以理解的术语描述问题
  • 提供有助于从错误中恢复的建设性意见
  • 应该指出错误可能导致的那些负面后果,以便用户检查是否出现该问题.并在确定出现问题时候及时解决.
  • 信息可以伴随着听觉上视觉上得提示(如发出警铃,或者用明显的颜色标明出错误)
  • 信息不能带有指责色彩,不能责怪用户

4)命令交互:

定义:

用户通过命令行与系统交互

提供命令行用系统交互时候需要考虑的问题:

• • 是否为每个菜单项都有对应命令/span>
  • 采用何种命令形式/span>one.控制序列(Crrl+字母键),two.功能键,three.输入命令
  • 学习和记忆难度大小/strong>
  • 忘记命令怎么办/strong>
  • 用户可以自定或缩写命令/strong>

三个设计指南:

1)一般交互指南:

• 保持一致性:在人机界面中交互中使用一致的格式
• 在执行一个较大破坏的动作前要用户确认（如删文件,覆盖信息,终止一个程序等）
• 减少两次操作之间用户需要记忆的信息量
• 减少用户未完成磨一动作按键次数,鼠标移动距离.尽量避免用户出现问”这是什么意思”的情况
• 按功能对动作分类,并据此设计屏幕布局
• 用简单动词/动词短语作为命名
• 允许犯错:系统能保护自己不受严重错误的破坏

2)信息显示指南:

• 只显示与当前相关的信息
• 显示的信息含义明确简短
• 使用窗口分隔不同类型的消息
• 用模拟显示的方式显示消息(显示炼油厂储油罐的压力,如果用数字表示就没有用温度计形式的表示来的效果好)
• 高效率的使用显示屏(当使用多窗口时,至少让每个窗口有一点空间来显示其一部分)
• 不应用大量的数据流淹没用户(可以使用图像/图表来取代大量表格)

3)数据输入指南:

• 减少用户为完成一个动作,多次输入相同数据或填大量的次要信息(提供默认值).和跳过不必要的动作
• 交互方式灵活,可以调整,供用户选择自己喜欢的交互方式
• 屏蔽当前动作语境中不使用的命令
• 保持信息显示和数据输入的一致性

Jackson设计方法

说明:

Jackson 设计方法是一种面向数据结构的软件设计方法, Jackson 分析方法是面向数据流的分析方法.

一般通过以下五个步骤来完成设计：

• 分析并确定输入数据和输出数据的逻辑结构,并用J ackson 结构图来表示这些数据结构
• 找出输入数据结构和输出数据结构中有对应关系的数据单元
• 按以下的规则由输入、输出的数据结构导出程序结构
  • 为每一对在输入数据结构和输出数据结构中有对应关系的单元画一个处理框
  • 为输入和输出数据结构中剩余的数据单元画一个处理框
  • 所有处理框在程序结构图上的位置,应与由它处理的数据单元在数据结构 Jackson 图上的位置一致
  • 必要时,可以对映射导出的程序结构图进行进一步的细化
• 列出基本操作与条件,并把它们分配到程序结构图的适当位置
• 用伪码写出程序

编程接口设计的五项基本原则

• 简洁明了: 接口的命名和参数应该简单清楚,让人一看就知道要做什么,输入和输出大概是什么
• 直来直去: 接口的实际输入输出,除了名称,传入参数和返回值以外,没有别的隐含在背后的输入输出和假设条件.
• 基本类型: 在接口定义中使用的数据类型尽可能的使用语言本身支持的基本数据类型
• 笼统输入: 要求输入的参数的类型尽量笼统,具体的说,就是有父类则用父类类型,如果有实现的接口就用实现的接口类型,这样一来,该接口也笼统了,适用面也扩大了,威力也马上不一样了,一个接口可以当好几个具体接口来使用.
• 具体返回: 返回的类型是越具体越好.道理其实很简单,有了具体的对象,接口调用者可以随时转换成父类类型或者实现的接口类型

对外公布的公开编程接口不能随意修改.所以在设计的时候要认真谨慎设计

Unix 开发哲学

• 只要可行,一切都应该做成与开源和目标无关的过滤器
• 数据流应尽可能文本化(这样可以使用标准工具来查看和过滤)
• 数据库部署和应用协议应尽可能文本化(让人可以阅读和编辑)
• 复杂的前端(用户界面)和后台应该清楚的分隔开
• 如果可能,用 C 编写前,先用注释性语言搭建原型
• 当且仅当只用一门语言编程会提高程序复杂度时,混用语言编程比单一语言编程来的好
• 宽收严发(接收的东西要包容,对输出的东西要严格)
• 过滤时,不需要丢弃的信息绝不丢
• 小就是美.在确保完成任务的基础上,程序功能尽可能少

线程与进程问题

注意:

不同的进程之间的接口,不能传递指针类型的数据,这点在设计分布式系统和多进程系统时候要特别注意

同步还是异步/strong>

同步犹如打电话直接交流有事情当场了解清楚才结束,异步犹如发邮件只要把信息发到目的地就好;当遇到资源紧缺,或者遇到长时间的操作时候多用异步.但遇到要及时的信息交流是用的是同步

调用函数的重入:

指的是一个线程调用一个函数的过程中.另一个或多个线程也在调用这个函数.如果该函数中有静态的数据或者一个指向静态数据的指针,就等于多个进程对一个数据在进行操作.这样做容易导进程错误

变量可见度:

如线程 A 修改了某个变量 X 后,该变量可能被缓存在中央处理器中的寄存器中,并没有被返回到主内存中,这个时候如果 B 线程要读取变量X的数值话,很自然的是到内存当中去读取所以现在的变量X显然不是最新的值.

代码的注释

常犯的毛病:

• 啰里啰嗦讲怎么做{例:count++ //increase count by one}
• 注解写的和代码所做的就是两码事

正确的有效注解:

• 要注释就注释这是在做什么和为什么这么做
• 最好少注释,或者干么就没注释

隐含规则

• 接口使用顺序: 不同软件接口可能会在顺序上有一定要求但这种关系在接口定义本身无法直接反映出
• 接口的配合关系: 有些接口之间有一定的配合关系,在实现了其中一个之后,就要同时实现另一个.

来源：kz_ang