第一章 系统设计

        ActionScript开发人员最常问的问题就是"这个类该由什么组成?我该如何编写它呢?"虽然这个问题很普通,但却反映了一个非常大的难题的核心:构建一个成功项目,从开始到完成、从定义到实现的步骤应该是怎样一个过程？这就是我们需要花费大精力去解决的一个问题。很多人都试图在方法学上改良以便解决这一难题。        其实，从头开始，一步一步教会一个人构建 系统的困难之处就在于：其中有很多原理很难用言语表述清楚，因而更难去教会他人。这需要我们扩展视野、多角度观察整个问题的全景；需要我们具有创新性的思维以及抽取核心信息的能力；需要大量的实践以及经验。但是，请不要担心。虽然，这是一项很具有挑战性的工作，但是在ActionScript类的开发过程中，我们还是有一些步骤可以遵循，有一些成熟的技术可以借鉴使用。本章会提到对于ActionScript开发人员非常有用的一些步骤和技术。        一些方法论中提到，构建一个完整系统的过程为5步，也有一些方法论中说是8步，还有一些则说不能确定其中的步骤。而大多数开发人员都公认的一个成功系统构建必须具备的阶段有3个：      （1）分析阶段      （2）设计阶段      （3）实现阶段      除此之外，多数开发人员也认为测试是系统开发过程中至关重要的一部分。虽然，测试并不认可为一个核心阶段，但是在本章，我们仍然将测试作为系统构建的第4个关键阶段。      不过，大家要注意一点，这4个阶段之间并不是一种线性关系。只要需要，您都可以从任意一个位置回到先前某个阶段。比如说，在设计阶段，如果忘记了系统当中一个很重要的用例（use case），可以直接从当前者一点回到先前的分析阶段去找到这个用例。但在进行下一个阶段的工作之前，一定要确保本阶段彻底完成。最好不要过早地结束分析阶段，直接进入设计阶段。您在每一个阶段中工作完成得越彻底，系统整体构建成功的可能性就越高。并且，如果您最后需要修改主体系统结构（这可能严重影响到整个项目的时间进度以及成功可能性），那么每一阶段工作完成的彻底性可以帮助您最小化此时的风险。1.1 分析阶段        分析阶段的主要任务就是搞清楚系统应该做什么？而如何达到这一目标则是设计与实现阶段的任务。通常来说，分析阶段的工作最富有挑战性，因为您需要将一些想法，通常是模糊的概念转换成为具体的函数需求，您必须构建出整个系统的宏观蓝图。也许，对于一个小型项目，我们不必再分析阶段花费大量精力就可以完成项目构建。但是大家一定要谨记，随着项目规模以及功能的不断扩展与增强，分析阶段也越来越重要。当然，如果在自己家周围散步，您当然不需要地图，可如果是穿越整个国家呢？无疑，您需要一张全国地图。对于系统开发而言，分析阶段同样是必不可少的一个环节。        大家一般都不会太关注分析阶段，只是随便确定一下系统的功能，就立即进入下一阶段，或者即使进行系统分析，也根本不强调该阶段的重要性。糟糕的分析最终会导致项目失败。实现程序的软件开发人员、从头到尾一直关注整个项目开发过程的项目经理、需要可以成功运行软件的客户以及使用软件的最终消费者等都可能必须忍受那些由于失误的分析阶段而导致的受限功能以及程序错误。分析的目的在于根据用户需求的要点制定出详细的说明书。不像后面的几个阶段那样，分析阶段必须尽可能地不掺杂任何技术性的成分。      通常，分析阶段的最终成果就是一篇描述功能需求的文档。这些需求之间的联系方法是多样的。分析阶段的文档没有具体的格式要求。最终要的就是您、您的团队以及您的公司正在采取的方法以及文档格式，它们才是最适合您的，可以有效地帮助您获得整个项目的宏观蓝图。      虽然它并没有统一的方法以及格式，但是在此我们使用用例来向大家进行讲解。如果您初次接触将分析进行正规的形式化，那么您一定会觉得用例太好用了，它可以有效地帮助您实现一切。当然，我们也鼓励大家去寻找更适合自己的方法以及文档格式。1.1.1用例介绍       定义系统功能性需求最简单的方法就是将系统需要实现的功能全部列出。可是无论您采取何种方式，它们都无法考虑到系统在现实生活中的真实使用情况。系统并不是孤立存在的，它们需要和各种类型的用户打交道。因而，描述功能性需求更为实际、有用的办法就是站在如果使用项目的立场来进行考虑。这种方式产生的功能性需求就是用例。        用例可以使用多种方式表现功能性需求。用户可以根据自己的需要选择其中任意一种。一个简单用例示例如下图所示：        • 地图生成：用户提交街道地址表。系统将在物理地图上展现该街道地址，也就是说，放大地图到现实详细街道细节的级别。      用例的表现形式很多。通常，专家们认为用例有如下3种基本格式：      （1）精炼用例：使用一段话语成功描述主场景。先前的示例就是一个精炼格式。      （2）非正式用例：使用多个段落，不仅描述主场景，还描述相关场景。下面就是非正式用例示例：       • 地图生成：              主场景：用户提交街道地址表。系统将在物理地图上展现该街道地址，也就是说，将放大地图到显示详细街道细节的级别。              相关场景：如果地址无效，则地址格式显示为一个错误信息，告知用户操作失败的原因。              如果对于指定地址，默认的放大比例不可用，那么地图将显示与该位置相关的最大放大细节级别。      （3）正式用例：最精细的用例文档格式。这种格式列举出用例的所有环节，包括参与者和条件在内的支持数据信息。接下来，我们会详细讨论正式用例。1.1.2书写正式用例        一般情况下，我们都使用正式用例来创建功能性需求文档。在这一部分，我们就来学习如何创建正式用例。一个正式用例应该包含下列几个部分：       • 主要参与者：描述用例中驱动操作进行的用户，应包括参与者角色（比如匿名、初级、管理员等）以及与该系统交互的用户相关特征（年龄、权限等）。       • 先决条件：执行用例之前必须满足的条件       • 主场景：比基础以及非正式用例格式更具有粒度（基于环节）的系统描述。       •相关场景：比非正式用例更具有粒度（基于环节）的相关场景的系统描述       • 专门需求：不符合主场景以及相关场景部分的需求列表。       • 尚需进一步磋商的事项：将关于实现用例解决方案的进一步有待实现的要点以及问题记录下来。     下面就是一个正式用例的示例。大家要注意该示例中并不包含尚需进一步磋商的事项。       • 地图生成      主要参与人员：顾客。      先决条件：顾客已经检查过指定地址的表格，并通过按钮提交该表格。     •  主场景：    （1）顾客填写地址表格。    （2）顾客提交地址数据。    （3）系统从映射服务器上获取所需地图数据。     （4）系统以指定细节级别绘制地图。    •  相关场景：