结构化设计（实验二）

实验二：软件设计规约及评审

概要设计规约

概要设计规约指明软件的组织结构，其主要内容包括:

1. 系统环境：
   • 硬件、软件接口与人机界面
   • 外部定义的数据库
   • 与设计有关的限定条件
2. 设计描述：
   • 软件模块的结构
   • 模块之间的接口
   • 数据流和主要数据结构
3. 对每个模块的描述：
   • 处理过程外部行为
   • 界面定义
   • 数据结构
   • 必要的注释
4. 文件结构和全局数据
   • 文件的逻辑结构、记录描述以及访问方式
   • 交叉引用信息

详细设计规约

详细设计规约是对软件各组成部分内部属性的描述，它是概要设计的细化。即在概要设计规约的基础上，增加以下内容:

1. 各处理过程的算法
2. 算法所涉及的全部数据结构的描述，特别地，对主要数据结构往往包括与算法实现有关的描述

设计规约格式

1. 1. 引言
2. 1.1 编写目的
3. 说明编写本软件设计说明书的目的。
4. 1.2 背景说明
5. （1）给出待开发的软件产品的名称；
6. （2）说明本项目的提出者、开发者及用户；
7. （3）说明该软件产品将做什么，如有必要，说明不做什么；
8. 1.3 术语定义
9. 列出本文档中所用的专门术语的定义和外文首字母组词的原词组。
10. 1.4 参考文献
11. 列出本文档中所引用的全部资料，包括标题、文档编号、版本号、出版日期及出版单位等，必要时注明资料来源。
12. 2. 总体设计
13. 2.1 需求规定
14. 说明对本软件的主要输入、输出、处理等功能及性能要求。
15. 2.2 运行环境
16. 简要说明对本软件运行的软件、硬件环境和支持环境的要求。
17. 2.3 处理流程
18. 说明本软件的处理流程，尽量使用图、文、表的形式。
19. 2.2 软件结构
20. 在 DFD 图的基础上，用模块结构图来说明各层模块的划分及其相互关系，划分原则上应细到程序级（即程序单元），每个单元必须执行单独一个功能（即单元不能再分了）。
21. 3. 运行设计
22. 3.1 运行模块的组合
23. 说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块的组合，说明每种运行所经历的内部模块和支持软件。
24. 3.2 运行控制
25. 说明各运行控制方式、方法和具体的操作步骤。
26. 4. 系统出错处理
27. 4.1 出错信息简要说明每种可能的出错或故障情况出现时，系统输出信息的格式和含义。
28. 4.2 出错处理方法及补救措施
29. 说明故障出现后可采取的措施，包括：
30. （1）后备技术。当原始系统数据万一丢失时启用的副本的建立和启动的技术，如周期性的信息转储；
31. （2）性能降级。使用另一个效率稍低的系统或方法（如手工操作、数据的人工记录等），以求得到所需结果的某些部分；
32. （3）恢复和再启动。用建立恢复点等技术，使软件再开始运行。
33. 5. 模块设计说明
34. 以填写模块说明表的形式，对每个模块给出下述内容：
35. （1）模块的一般说明，包括名称、编号、设计者、所在文件、所在库、调用本模块的模块名称和本模块调用的其他模块名；
36. （2）功能概述；
37. （3）处理描述；
38. （4）引用格式；
39. （5）返回值；
40. （6）内部接口，说明本软件内部各模块间的接口关系，包括：
41. （a）名称；
42. （b）意义；
43. （c）数据类型；
44. （d）有效范围；
45. （e）I/O 标志；
46. （7）外部接口，说明本软件同其他软件及硬件间的接口关系，包括：
47. （a）名称；
48. （b）意义；
49. （c）数据类型；
50. （d）有效范围；
51. （e）I/O 标志；
52. （f）格式，指输入或输出数据的语法规则和有关规定；
53. （g）媒体；
54. （8）用户接口，说明将向用户提供的命令和命令的语法结构，以及软件的回答信息，包括：
55. （a）名称；
56. （b）意义；
57. （c）数据类型；
58. （d）有效范围；
59. （e）I/O 标志；
60. （f）格式，指输入或输出数据的语法规则和有关规定；
61. （g）媒体

62. 
63. 

 

实验二：软件详细设计-2

面向数据流的设计方法-2

模块结构图

模块结构图（Module Structure Diagram, MSD）是用来表示系统的模块划分与层次分解关系，表示模块的调用关系、模块间数据流与控制流的传递关系以及模块与外界或数据存储的信息接口的规范化图形，是结构化系统设计的一种重要的图表描述工具。

组成元素

• 方框：内有名称，表示模块；
• 直线：表示上层模块对下层模块的调用；
• 尾部带空心圆的箭头：表示按方向传递的数据信息；
• 尾部带实心圆的箭头：表示按方向传递的控制信息。

作用

描述模块间参数交换情况、评价模块间耦合情况、确定模块间的接口。结构图一般不列入设计文档，只用于设计阶段检查模块设计的正确性和模块独立性。

变换设计

变换设计就是从变换型数据流图映射出软件模块结构的过程，也称以变换为中心的设计。
变换设计的基本方法有两步：

1. 分解第一层模块结构，就是把整个变换分解成输入控制模块Ci、输出控制模块Co和变换中心控制模块Ct，由主控模块控制；

   

   
   图1 变换设计

    

   

   
   图2 变换设计

2. 分别设计输入、输出和处理的下层模块结构，方法是：从变换中心边界向两侧移动，分别把输入通路和输出通路的每个处理映射成输入控制模块Ci和输出控制模块Co的下属模块。变换中心的下层模块，是把每个处理映射成变换中心控制模块Ct的一个直接下属模块。

   

   
   图3 变换设计

事务设计

事务设计就是从事务型数据流图映射出软件模块结构的过程，也称为以事务为中心的设计。
事务设计的基本方法有两步：

1. 建立主控模块、接收输入类型分析模块和事务调度模块；

   

   
   图4 事务设计

2. 分别设计输入类型分析模块和调度模块的下层模块结构。方法是：将输出的每条通路作为调度模块的一个判断分支，而输入类型分析模块的下层模块与变换设计类似。

   

   
   图5 事务设计

    

   

   
   图6 事务设计

、

实验二：面向数据流的设计方法-1

 

模块及模块化设计思想 

模块及模块化思想

系统的模块数目增加，每个模块的规模减小，开发单个模块的成本减小，但是，随着模块数目增加，设计模块间接口的工作量增也加。所以随着模块数目的增加，系统的总成本先降低后增加，总成本曲线出现一个最小成本区。如果一个大型程序仅有一个模块，它将很难被人所理解，模块化的目的之一是为了让一个大型的程序更容易被人所理解。

采用模块化原理可以使软件结构更加清晰，更加易于阅读和理解。程序错误通常出现在部分模块及它们间的接口，所以模块化思想使软件更加容易测试和调试，提高了软件的可靠性，模块化使得一个大型的程序分解成不同的模块，对难易程度不同的模块可以分配技术熟练程度不同的程序员编写，有助于软件开发的组织管理。模块化的缺点是会造成性能损耗，系统逐步分层，调用链长，模块间通信很耗性能。

逐步求精中每一层中的模块都是对系统抽象层次的一次精化。软件结构顶层的模块,控制系统的主要功能。软件结构底层的模块,完成对数据的一个具体处理，软件结构中，首先抽象出系统的主要功能，然后逐步实现低层细节采用自顶向下，由抽象到具体的方式分配控制，提高了软件的可理解性和可测试性。

信息隐藏与局部化。在软件结构中，各个模块间的信息应该彼此相对独立，隐藏模块的实现细节，仅允许访问其他模块中为了完成系统功能所需要的的信息，在模块中使用局部数据元素有助于实现信息隐藏。编写系统的不同模块时，可以根据实际需要自由命名局部变量。模块独立的概念是模块化、抽象、信息隐藏和局部化概念的直接结果。

闯关要求

案例介绍

项目背景及介绍

电商系统致力于提供产品展示及订购，为核心的网上购物服务宣传自己商店的商品并将自己的产品展现给用户，让客户通过网站能自由地选择购买产品。
该网站是通过用户登录浏览商品、查看公告、购买、确定购买、实现用户模块功能。其中订单的生成，网站后台系统，通过系统管理员管理商品、订单、用户来实现。用户可以在商城前台进行浏览商品，加入购物车，下单等操作。后台管理模块可以对商品、订单、会员以及库存进行管理。

功能需求

功能块划分

网上商城共分两个部分，一部分是面向用户的部分，包括：顾客在线注册、购物、提交订单、付款等操作；另外一部分是商城管理部分，这部分的内容包括：产品的添加、删除、查询、订单的管理、操作员的管理、注册用户的管理等。三，商家（增，删，改）

功能块描述

（一）面向用户部分功能

1. 注册功能。顾客首先要注册为网上商城的用户。注册时只要填写登录用户名、密码、联系电子信箱3项信息即可。注册后，用户可继续如实填写详细个人信息及收货人信息，同时可修改密码、查询及修改订单。
2. 选择产品功能。顾客浏览网上商城，将自己需求的产品放入到购物车中（可在网上商城首页、专柜首页、产品小类、专卖店首页、搜索结果页面、产品详细信息页面进行该操作），可连续添加商品。
3. 管理购物车。顾客选择完商品后可进入购物车页面，查看自己要购买的商品，可修改某一商品数量、取消购买某商品和清空整个购物车。
4. 订单功能。顾客确定购物车中的商品后提交订单，如顾客已填写收货人信息，则页面显示该信息并由顾客确认。如尚未填写则显示相应表单请其填写，系统记录顾客提交的收货人信息以便其下次购物时使用。顾客提交订单后可在网上商城查询该订单，并可对尚未处理的订单进行取消、修改等操作。
5. 付款功能。顾客在订单被销售方确认后，要选择付款方式，并付款给销售方，然后才可以收到货。

（二） 后台管理部分功能

耦合原则

如果模块间必须存在耦合，就尽量使用数据耦合、少用控制耦合、限制公共耦合的范围以及坚决避免使用内容耦合。

内聚定义

内聚（Cohesion）是指一个模块之内各成分之间相互依赖程度的度量。

常见内聚类型（由低到高）

闯关要求

案例介绍

网上商城系统致力于提供产品展示及订购，为核心的网上购物服务宣传自己商店的商品并将自己的产品展现给用户，让客户通过网站能自由地选择购买产品。
用户可以在商城前台进行浏览商品，加入购物车，下单等操作。后台管理模块可以对商品、订单、会员以及库存进行管理。

题目

请根据网上商城系统案例描述以及相关知识点，完成相应题目。

常见的启发规则

1.改进软件结构提高模块独立性

1. 管理人员部分。该部分的用户有一个超级管理员以及若干个普通管理员，超级管理员拥有最高权限，可访问所有订单，可浏览、查询订单，可浏览、修改普通管理员和会员的资料，普通管理员分两种，一种是订单管理员：主要负责订单管理，可浏览、修改订单状态，可浏览会员信息；另一种是界面管理员：主要负责界面管理，可增、删商品和广告等操作。
2. 管理订单功能。顾客可通过Web方式取消、修改自己提交的订单（在管理员确认前），查询自己提交的订单（随时）。如订单的状态在一定时限（如12个小时）后仍没有发生变化（“订单关闭”状态除外），系统自动提醒管理员（如该订单变色，弹出提醒窗口等方式。订单状态发生变化，系统自动发E-mail给顾客，“无效订单”、“订单关闭”状态除外）。
3. 管理商品功能。管理员可以添加、修改、删除商品。
4. 
5. 
6. 
7. 

   耦合定义

   耦合（Coupling）是指不同模块之间相互依赖程度的度量。

   常见耦合类型（由强到弱）

8. 内容耦合：
   • 定义：一个模块直接修改或操作另一个模块的数据。
   • 举例：在模块A中定义了某个变量，在模块B中直接使用了该变量。
9. 公共耦合：
   • 定义：两个以上的模块共同引用一个全局数据项。
   • 举例：我们定义了全局变量a，在模块、模块B和模块C中均使用到了此变量a。
10. 控制耦合
    • 定义：一个模块向另一模块传递一个控制信号，接收信号的模块将依据该信号值进行必要的活动。
    • 举例：模块A实现了统计最近三天以及最近七天销量的功能，而具体执行哪种统计由传入的控制参数决定，则该模块具有控制耦合。逻辑内聚的模块调用就是典型的控制耦合。
11. 标记耦合
    • 定义：两个模块至少有一个通过界面传递的公共参数，包含内部结构，如数组、字符串等。
    • 举例：模块A向模块B传递数组类型数据。
12. 数据耦合
    • 定义：模块间通过参数传递基本类型的数据。
    • 举例：模块A实现两个数的加法操作，模块B实现数字的初始化，模块B将数字传递给模块A，由模块A完成加法。
13. 偶然内聚
    • 定义：一个模块之内各成分之间没有任何关系，只是把分散的功能整合到了一起。
    • 举例：A模块中有三条语句（一条赋值，一条求和，一条传参），表面上看不出任何联系，但是B、C模块中都用到了这三条语句，于是将这三条语句合并成了模块A。模块A具有偶然内聚。
14. 逻辑内聚
    • 定义：几个逻辑上相关的功能放在同一模块中。
    • 举例：模块A实现了统计最近三天以及最近七天销量的功能，而具体执行哪种统计由传入的控制参数决定，则模块A具有逻辑内聚。
15. 时间内聚
    • 定义：一个模块完成的功能必须在同一时间内完成，而这些功能只是因为时间因素关联到一起。
    • 举例：模块A实现了全部全局变量的初始化操作。模块A这种初始化模块就具有时间内聚。
16. 过程内聚
    • 定义：处理成分必须以特定的次序执行。
    • 举例：模块A依次读取用户的用户名、密码和地址信息，并且这个次序是事先规定的，则模块A具有过程内聚。
17. 通信内聚
    • 定义：各成分都操作在同一数据集或生成同一数据集。
    • 举例：模块A根据员工生日分别计算员工年龄和退休日期，则模块A具有通信内聚。
18. 顺序内聚
    • 定义：各成分与一个功能相关，且一个成分的输出作为另一成分的输入。
    • 举例：模块A根据员工生日计算员工年龄，再根据员工年龄计算退休日期，则模块A具有顺序内聚。
19. 功能内聚
    • 定义：模块的所有成分对完成单一功能是最基本的，且该模块对完成这一功能而言是充分必要的。
    • 举例：模块A根据员工生日计算员工年龄。

设计出软件的初步结构以后，应该审查分析这个结构，通过模块分解或合并，力求降低耦合提高内聚。例如，多个模块公有的一个子功能可以独立成一个模块，由这些模块调用；有时可以通过分解或合并模块以减少控制信息的传递及对全程数据的引用，并且降低接口的复杂程度。

2.模块规模应该适中

过大不易理解；太小则接口开销过大。
经验表明，一个模块的规模最好能写在一页纸内(通常不超过60行语句)。

3.深度、宽度、扇出和扇入都应适当

深度：表示软件结构中控制的层数。
深度能粗略地标志一个系统的大小和复杂程度，深度和程序长度之间有粗略的对应关系
宽度：表示软件结构中控制的总跨度。
宽度是同一个层次上的模块总数的最大值，宽度越大系统越复杂；对宽度影响最大的因素是模块的扇出。
扇出：表示一个模块直接控制(调用)的模块数目扇出为3-4，上限扇出为5-9。
扇入：表示有多少个上级模块直接调用该模块扇入越大则共享该模块的上级模块数目越多。

4.模块的作用域应该在控制域之内

模块的控制域：这个模块本身以及所有直接或间接从属于它的模块的集合。
模块的作用域：受该模块内一个判定影响的所有模块的集合。
在一个设计得很好的系统中，所有受判定影响的模块应该都从属于做出判定的那个模块，最好局限于做出判定的那个模块本身及它的直属下级模块。

5.力争降低模块接口的复杂程度

模块接口复杂是软件发生错误的一个主要原因。应该仔细设计模块接口，使得信息传递简单并且和模块的功能一致。接口复杂或不一致(即看起来传递的数据之间没有联系)，是紧耦合或低内聚的征兆，应该重新分析这个模块的独立性。接口复杂可能表明模块的独立性差。

6.设计单入口单出口的模块

这条启发式规则警告软件工程师不要使模块间出现内容耦合。当从顶部进入模块并且从底部退出来时，软件是比较容易理解的，因此也是比较容易维护的。

7.模块功能应该可以预测

模块的功能应该能够预测，但也要防止模块功能过分局限。

 

 

 

 

 

 

 

 

1. 相同输入必产生相同输出
2. 反例：模块中使用全局变量或静态变量，则可能导致不可预测。