结构化技术讲解

结构化技术内容大纲学习目标4.1导论4.2结构化技术之概念4.3结构化分析与设计工具4.4软硬件环境设计与开发工具选择4.5系统分析与设计之文件样板4.6结论学习目标

详读本章，你至少能了解：结构化分析与设计之概念。何谓由上而下设计、编码与实施。结构化分析与设计之工具与应用准则。

4.1导论系统开发模式主要强调系统开发过程中应有之步骤与执行程序，并不涉及每个步骤中可支援或应用的方法或技术。结构化技术起源于1960年代末期，主要强调如何应用一些概念、策略与工具，以提升系统分析与设计、程序设计与测试之效率与效能。4.2结构化技术之概念结构化技术一般包括：结构化分析(StructuredAnalysis)结构化设计(StructuredDesign)结构化程序设计(StructuredProgramming)由上而下发展(Top-downDevelopment)4.2.1结构化分析与设计结构化设计起源于1960年代末期，其主要目的是将信息系统依由上而下发展，并将程序设计模块化与结构化。4.2.1结构化分析与设计(c.2)程序的模块(Module)是一连串指令的集合，一般来说，模块包括五个部份：模块名称：唯一且应有意义，能表达模块的功能。输入：是指呼叫一模块所需输入的资料。输出：是指模块执行后所产生的输出结果，它与输入合称为模块的界面。处理逻辑：为模块内必须具备的执行程序以达成模块的功能。内部资料：为该模块独自拥有而不与其他模块共享的资料。4.2.1结构化分析与设计(c.3)结构化设计包括文件工具、设计评估准则与设计经验法则等。其中，文件包括：结构图(StructureChart)HIPO图(HierarchicalInputProcessOutput)模块规格描述资料字典4.2.1结构化分析与设计(c.4)结构化设计之实施有一些简单的经验法则(RulesofThumb)可供参考，这些法则很有用，但不保证在所有的个案均可行。Yourdon(1988)认为，最普遍的设计经验法则常关系到：模块大小(ModuleSize)控制间距(SpanofControl)影响范围(ScopeofEffect)控制范围(ScopeofControl)4.2.1结构化分析与设计(c.5)模块大小一般来说，小模块约包含200个以下的程序指令，约可打印在1～2页之A4纸内。基于小模块比较简单的假设，小模块比大模块易于维护与修改，故结构化设计较倾向用小模块。控制间距一个模块不要同时控制太多实时的模块，最多不要超过９个(MagicNumber7±2)，因为控制太多模块将不利于了解与维护。影响范围与控制范围为缩小影响范围与控制范围，当甲模块之行为被乙模块所影响，则甲模块应从属于乙模块。4.2.1结构化分析与设计(c.6)结构化设计最终须产出模块化与结构化之程序和符合正规化之数据库，但应如何做才能产出这样的结果呢?结构化设计并未具体解决该问题，因此结构化分析乃应运而生。结构化分析之概念起源于1970年代中期，利用图形化文件工具(GraphicDocumentationTools)进行企业流程及企业资料格式塑模，以帮助进一步之结构化设计。4.2.1结构化分析与设计(c.7)结构化分析之图形化文件工具包括：事件列(EventList)环境图(ContextDiagram)资料流程图(DataFlowDiagram,DFD)资料字典(DataDictionary,DD)处理规格描述(ProcessSpecification,PS)实体关系图(EntityRelationshipDiagram,ERD)4.2.2结构化程序设计Dijkstra(1969)提出结构化程序设计的概念，以消除以往程序因GOTO指令而造成的混乱状态。结构化程序的背后理论指出，任何程序逻辑仅有一输入与一输出，且均可由如下之三种结构构成：循序、选择与重复。4.2.2结构化程序设计(c.2)循序简单的指令，如COMPUTE、READ、WRITE与代数指令如X=Y+Z。选择当需做决策时，用IF-THEN-ELSE指令与CASE指令。重复当需反覆执行时，用DO-WHILE与DO-UNTIL指令。上述的集合可以组成任何一种程序逻辑，而不需在程序中使用GOTO指令。4.2.3由上而下发展由上而下发展之技术起源于1960年代末期，此技术包含有三个相关但不同方面的「由上而下」：由上而下设计(Top-DownDesign)由上而下编码(Top-DownCoding)由上而下实施(Top-DownImplementation)4.2.3由上而下发展(c.2)由上而下设计由上而下设计是一种设计策略，它把大而复杂的问题分解成较小且较简化的问题，直到原来的问题已可用一些容易且可理解的小问题组合来代表。例如：a.先将主程序分为A、B、C三个子程序b.再划分子程序A为A1与A2，C为C1与C2，如图4-2a图4-2a由上而下设计范例4.2.3由上而下发展(c.4)由上而下设计之特色：一个层级化的设计先考虑程序的主要功能，再依次考虑所属的各个次要功能。延缓考虑细节问题先考虑高层次之功能，再考虑其下之次功能。与程序语言无关使用由上而下设计之方式，可选用任何一种语言来撰写，而不需更改设计内容。便于验证可根据需求分析的结果来检验程序的主要功能是否划分完备，也可以根据各主要功能来检查各次功能。4.2.3由上而下发展(c.5)由下而上设计在此方式下，通常先考虑程序中较底层的项目、动作及其间的关系，再将这些基本的部分组成较高层次的部分，而这些部份又可以组成更高层次的部分，最后组合成一个完整的程序。例如：先独立发展各个细部的子程序X、Y、Z再将X、Y、Z组合成较高层次的子程序A1经过逐次组合的程序全貌如图4-2b图4-2b由下而上设计范例4.2.3由上而下发展(c.7)由下而上设计优点：能及早对程序内部各子程序作绩效评估缺点：难以完全规划一个程序。不易根据此方式将程序划分成几个部分，以及明确订出其间相互影响之资料与关系。4.2.3由上而下发展(c.8)由上而下编码程序编辑的方式很多，可采用由上而下的编码，亦可采由下而上的编码(Button-UpCoding)的方式，或是两者混合的方式。由上而下编码是一种程序编辑策略，当高阶模块设计完成后，就先对高阶模块编码。一般的程序设计方式多采由上而下设计与由上而下编码，当系统很大时，此种作法有助于缩短时间。4.2.3由上而下发展(c.8)由上而下实施又称由上而下整合测试(Top-DownIntegrationTest)。一般来说，测试主要有两种策略：由上而下测试与由下而上测试。软件测试(SoftwareTesting)指的是在规定的条件下操作程序，发掘程序是否有错误，用以衡量软件的质量、正确性、完整性，并评估软件是否满足使用者需求的过程，测试的主要目的是从可执行的程序中找出错误。软件测试有许多方法，一般来说，测试的种类与进行顺序分别是单元测试、整合测试、验收测试与系统测试。4.2.3由上而下发展(c.10)单元测试

(UnitTesting)为测试程序码单元（一个可独立进行的工作，其不受前一次或接下来的工作结果影响）的正确性，发生在模块开发时。整合测试

(AggregateTesting)是单元测试的逻辑延伸，为测试由单元组合之元件及其间的界面，发生于模块结合为次系统时。验收测试

(AcceptanceTesting)为确保软件准备就绪，用以表明软件可依使用者之需求执行，发生在软件部署于硬件之前。系统测试

(SystemTesting)是将软硬件、数据、人员、环境等与系统有关之元素结合在一起测试，发生在系统完成时。4.2.3由上而下发展(c.11)就测试模式而言，可分为两种：白箱测试(WhiteBoxTesting)是以测试的深度为主，测试人员需了解待测试程序的内部结构、算法等讯息，透过测试资料以检查特定条件或循环，来测试软件的逻辑路径。黑箱测试(BlackBoxTesting)是以测试的广度为主，测试人员并不需要对软件的结构性有足够深层的了解，所进行的测试是从使用者的角度对程序进行的测试，只需针对程序的输入（将测试数据输入软件）、输出（确认输出结果是否正确）和系统的功能进行检视。图4-3软件测试之种类与执行顺序4.2.3由上而下发展(c.13)由上而下实施由上而下测试是在低阶模块尚未完成前，先测试系统的高阶模块由下而上测试是由程序结构图的最底端模块开始，逐次往上测试

(如下图)。4.2.3由上而下发展(c.14)应用由上而下的整合测试，首先由结构图上最顶端的模块开始进行测试，而以残根模块(StubModule)或虚拟模块(DummyModule)暂时代替其下一层未完成的模块。以下图为例，测试模块A时，C与D是虚拟模块，同样地，测试模块B时，E与F是虚拟模块。

4.2.3由上而下发展(c.15)由上而下整合测试之优点：系统的整合测试可以减至最少。最高阶层的界面最先被测试，且被测试的机会最多。高阶层的模块是低阶层模块最佳的测试启动(Driver)模块。系统的错误若在上阶层，则可及早发现。4.2.3由上而下发展(c.16)由上而下整合测试之缺点：需要制造残根或虚拟模块。残根或虚拟模块的设计通常比较复杂。以残根或虚拟模块执行输入、输出功能较困难。测试个案的产生可能会很困难。测试结果较难观察。易使人产生误解，认为设计及测试可重叠进行，或认为某些模块的测试可延期完成。低阶层次模块若想做平行测试，将会受制于其上阶层模块是否已完成。4.2.3由上而下发展(c.17)应用由下而上策略，是从结构图的最底端开始，利用启动模块逐次往上测试，而当低阶层的所有模块均已测试完毕时，其启动模块才被真正的上阶层模块所取代。以图4-6为例，当测试模块E时，需有启动模块B。图4-6由下而上测试之启动模块关系4.2.3由上而下发展(c.19)由下而上策略之优点：测试个案较容易设计。测试结果较易观察。系统错误如果在下方，则可及早发现。不会产生设计与测试可以重叠的错误观念。最低阶的测试较彻底。由下而上策略之缺点：必须制造启动模块。整体的系统要等到最后一模块(通常是最顶端模块)加上之后才能见到全貌。4.3结构化分析与设计工具基本上，结构化分析与设计是将资料与流程分开考虑，主要可分成三大部分：资料塑模主要是针对信息系统的知识子系统。流程塑模主要是针对信息系统的问题处理。使用者界面塑模主要是针对信息系统的使用者界面子系统。此三种塑模活动并没有一定的进行顺序，也就是说任何一种塑模活动均可视需要而先进行或以其他塑模活动交互进行。图4-7结构化分析与设计及塑模工具4.3结构化分析与设计工具(c.3)结构化分析与设计的塑模工具包括：事件环境图资料流程图资料字典结构图与HIPO图处理规格描述实体关系图等资料流程图资料流程图提供一种简易的、图形化的方式以表达系统之作业处理与资料流间之关系。典型的系统通常需要数层的资料流程图，最高层称为第零阶，接下来依序为第一阶、第二阶到第“N”阶，其中第零阶表示系统的概观，而其每个处理可再被分解，以表示系统下之子系统。

图4-8资料流程图范例结构图与HIPO图结构图(StructureChart)与HIPO图(HierarchicalInputProcessOutput)等文件工具的目的是用来表达系统的模块结构(Structure)及系统架构(Architecture)，而非针对程序逻辑(ProceduralLogic)。结构图以图形之方式，显示一信息系统之模块如何以层级方式组成，以及如何以资料传递来表示模块间之互动关系。HIPO图亦是以图形之方式，显示一信息系统之模块如何以层级方式组成，其符号与结构图相似，但HIPO图上并不需表示模块间之互动关系，例如少了模块间之资料流与控制流。处理规格描述处理规格描述(ProcessSpecification)允许系统分析师在资料流程图最底层之每个基本处理单元，精确地描述其商业规则（例如作业处理逻辑）。许多不同的方法可被用于描述处理规格，例如流程图、法则、结构化英文(StructuredEnglish)与程序设计语言(ProgramDesignLanguage,PDL)等。实体关系图实体关系图（Entity-RelationshipDiagram,E-RDiagram或ERD）是系统分析与设计时用于资料塑模的主要工具，主要表示企业资料中实体类型间之关系，是关联式数据库之整体逻辑结构的一种图形表示。其可对组织或商业领域的实体(Entities)、关联(Associations)及资料元素(DataElements)提供概念性逻辑结构的表示。吴仁和、林信惠(2016)4.4软硬件环境设计与开发工具选择软硬件环境设计及开发工具选择，包括硬件与网络架构、作业系统、应用系统架构之设计与开发工具之选择等。其中，主从式(Client/