但是从软件工程的四个阈（Problem Domain，Human Interface，Data Management，System Interface）来看，将业务层、数据层、界面层分开则是相当有必要的。界面层可交给交互设计师去设计（有几个程序员设计出来的界面值得欣赏），交互设计师不用考虑如何去与用户打交道，他只负责“画”出界面，而不用了解任何语言（Human Interface，HI）；程序员去实现界面，并完成其中的逻辑（Problem Domain，PD），对他来说，不必知道数据是如何存放在哪种数据库中的，是如何组织的，他要做的就是对（Data Management，DM）说“我要×××××××”；而DM要做的是根据PD的要求，读写数据库；表面看上去，一层调用一层，显得烦琐，效率低。但结构很清晰，具有极好的可维护性。在当今，速度并不是决定软件好坏的唯一因素，良好的结构、易维护、可复用、易扩展等也是评价软件好坏的重要指标。
就传统的C/S结构而言，由于数据的存取和处理主要依赖于客户端程序，本地化的程序配制复杂（如必须配制本地ODBC或固定服务器机器名等），逐台配置机器对于一个拥有多用户的复杂系统而言，工作量较大，维护成本高；而应用程序由于需要经常更新，因此逐台更新的问题比较复杂；另一方面，C/S结构对网络底层协议的依赖性大，由于部分程序不是建立在TCP/IP协议之上的，因此对防火墙、多网端等问题的解决并不方便，对跨平台（如Unix—Windows）的支持也稍显不足；另外，目前的应用系统建设一般都超出了局域网范畴，传统C/S结构对实现内网/外网、局域网/广域网间的有机整合也有局限。
相对来说，B/S结构对用户的技术要求比较低，对前端机的配置要求也较低，而且界面丰富、客户端维护量小、程序分发简单、更新维护方便。它容易进行跨平台布置，容易在局域网与广域网之间进行协调，尤其适宜信息发布类应用。但是，B/S结构在客户端对大容量数据进行深层次分析、汇总、批量输入输出、批量更改的工作中出现困难，尤其更难实现图形图像等复杂应用，对于需要与本地资源（如调用本地磁盘文件或其他应用程序，如扫描驱动、OCR识别、图形压缩与解压缩和工作站本地密码机的调用等）进行交互性的操作上极不方便，因而难以适用于基于流程类的办公、办证、审核等系统。
对于C/A/S及B/A/S这种结构，如果企业涉及复杂的业务逻辑，就要单独划分出中间层，以利于软件具有更好的可维护性。中间层有可能会使编码的工作量有所增加，但这些增加的工作是非常有意义的。当然，如果企业的业务逻辑很简单，就不需要这个中间层。确定是否具有中间层的一个重要原则是：划分中间层的目的是为了使各个层次负载均衡，最大限度减少软件的复杂度和软件维护的代价。
以上分析表明，C/S结构与B/S及多层结构各有利弊，只有将他们的优缺点进行互补，按照自身特点选择适合的技术平台，才能得到最理想处理。
4.3结构化设计
4.3.1概述
软件需求分析阶段完成了对问题的分析建模工作，软件设计阶段则要完成对解决问题方案的设计建模工作。因此，软件设计阶段的工作任务和内容是在问题的分析模型基础上，用一定的方法和手段对问题的解决方案进行设计建模。设计结果的好坏、易理解性和易修改性将直接影响到后续阶段软件实现工作的质量和费用。
4.3.2工作内容和任务
结构化软件开发方法采用结构化设计（Structured Design，SD）技术进行问题解决方案的设计工作，它将问题的解决方案表述为：“结构图+关系数据模式”的形式，其中，结构图描述软件系统的程序结构，关系数据模式描述软件系统的数据库结构。因此，结构化设计工作主要包括程序结构设计和数据库结构设计，数据库设计在前面章节已有概述。程序结构设计，又称为概要设计或总体设计。首先是根据数据流图类型将问题分析划分为事务型问题和/或变换型问题，分别将它们映射成事务型结构图和/或变换型结构图；然后对映射得到结构图进行综合和评价改进；最后，按照有关规范编写概要设计说明书和进行复审。
4.3.3程序结构
程序结构或程序物理结构是对要解决的问题或要设计的系统一种分层的表示方法，它指出了组成程序（系统）的各个元素（即各个模块）以及它们之间的关系。程序结构是从需求分析阶段定义的分析模型导出的。程序结构隐含着控制层次的关系，但不表示程序的具体算法或过程关系，即不表示诸如处理的顺序，选择的出现和次序、操作的重复循环等。程序结构通常用结构图的形式表示。
4.3.4结构图
结构图（Structured Charts，SC）是准确表达程序结构的图形表示方法，它能清楚地反映出程序中各模块间的层次关系和联系。与数据流图反映数据流的情况不同，结构图反映的是程序中控制流的情况。
结构图中的主要成分有：
①模块：以矩形框表示，框中标有模块的名字。对于已定义（或者已开发）的模块，则可以用双纵边矩形框表示。
②模块间的调用关系：两个模块，一上一下，以箭头相连，上面的模块是调用模块，箭头指向的模块是被调用模块，模块A调用模块B。在一般情况下，箭头表示的连线可以用直线代替。
③模块间的通信：以表示调用关系的长箭头旁边的短箭头表示，短箭头的方向和名字分别表示调用模块和被调用模块之间信息的传递方向和内容。首先模块A将信息C传给模块B，经模块B加工处理后的信息D再传回给模块A。
④辅助控制符号：当模块A有条件的调用模块B时，在箭头的起点标以菱形。模块A反复地调用模块D时，另加一环状箭头。在结构图中条件调用所依赖的条件和循环调用的循环控制条件通常都无须注明。
一般说来，结构图中可能出现以下4种类型的模块：
①传入模块：从下属模块取得数据，经过某些处理，再将其传送给上级模块。
②传出模块：从上级模块取得数据，进行某些处理，传送给下属模块。
③变换模块：从上级模块取来数据，进行特定处理，送回原上级模块。
④协调模块：对其下属模块进行控制和管理的模块。
值得注意的是，结构图着重反映的是模块间的隶属关系，即模块间的调用关系和层次关系。它和程序流程图（常称为程序框图）有着本质的差别。程序流程图着重表达的是程序执行的顺序以及执行顺序所依赖的条件。结构图则着眼于软件系统的总体结构，它并不涉及模块内部的细节，只考虑模块的作用，以及它和上、下级模块的关系。而程序流程图则用来表达执行程序的具体算法。
没有学过软件开发技术的人，一般习惯于使用流程图编写程序，往往在模块还未作划分、程序结构的层次尚未确定以前，便急于用流程图表达他们对程序的构想。这就像建一栋大楼，在尚未决定建筑面积和楼层有多少时，就已经开始砌砖了，这显然是不合适的。
在结构化分析和设计技术中，通常存在着两种典型的问题类型，变换型问题和事务型问题。它们的数据流图和结构图都有明显的特征。
4.3.5变换型问题
在数据处理问题中，通常会遇到这样一类问题，即从（程序）“外部”取得数据（如从键盘、磁盘文件等），对取得的数据进行某种变换，然后再将变换得到的数据传回给“外部”。其中取得数据这一过程称为传入信息（数据）流程，变换数据的过程称为变换信息（数据）流程，传回数据过程称为传出信息（数据）流程。当数据流图或其中某一段数据流表现出上述特征时，该数据流图或该段数据流图表示的就是一个变换型问题。完成数据变换的处理单元叫变换中心。
4.3.6模块说明
在完成上述程序结构的设计和改进工作之后，还必须对每个模块进行具体定义和说明，主要内容包括以下几个方面：
1.功能说明
描述模块的主要任务、条件决策和输入输出，并且着重说明处理中重要的算法或过程，它应是无歧义的和有限度的。
