【计算机软件毕业设计】基于Java的手机游戏服务端的设计与实现-文献翻译

1、文 献 翻 译译文：解释流程和发现需求在结构化的方式中，解释程序流程是获取和表达需求的最好方式之一。一个规范的解释会促使你去思考怎样使一个流程成功，流程的精确行为是成功所必须的。解释流程的工作最好是为了发现功能需求，并不是自我限定。随意提出的任何类型的需求包括-非功能性的、有组织的、商业性的等等。获取多余的需求是没有错的，尤其是第一次规划时。你可以在审查周期中消除重复。对每个流程的解释都应该包括以下：l 命名和编号：准确的命名和流程的编号应被描述出来。l 成功的标准：流程基本成功的结果要如何去识别和认定。（The essential successful result of the proce

2、ss and how exactly to identify and measure it.）l 启动：启动流程的前提要求，通常有一个触发事件。根据流程的类型，这还可以包括数据的输入。l 结果：流程的最终状态，包含所有数据的输出，环境的改变和其他产品流程可能不会是成功条件的直接部分。l 要素：在流程中实体存在不仅包括技术组成，如服务器和软件，还包括人和团队。l 行为：流程成功完成包含一系列事件和步骤，也包括成功序列之外的异常。l 要求：准确的函数或条件必须存在，或以某种方式运作都是为了满足流程的成功标准。流程是能被高标准化和具体化的。为了调整详细的级别，所以流程操作可以被描述为少于10个步骤。

3、我确信在某时我们将发现，如果我们早已不复存在，我们的头脑在组织10件事情以上将会非常困难，那将会直接关系到我们自身。在如何获得和呈现信息时你有许多选择，但一种描述不包括其他多种因素，那是不完整的，还将可能是失败的。阿利斯泰尔科伯恩博士在他的杰出的著作Writing Effective Use Cases中用例说明了关于“随意”与“完全打扮”的必要性。因此在本书中我不在用例和流程类型加以区分，我推荐相同的特性。其次，为了适应流程的的范围和每一步骤的层次细节所以你能将行为表述为3到10步。做到准确很重要，太精确将会导致难以理解，解释不清楚和所有精确细节的浪费。我们应当在流程解释时，关注每一个元素的

4、细节。流程命名开始解释时总是以流程的命名和流程的编号开头。我并不想反复讨论这个非常明显的观点，但是我发现，聪明的人往往忽视这个明显的观点，从而妨碍他们的工作。我曾多次看到过非常有才的人因为流程的命名不符而为此做许多的努力去详细的解释。没有流程的命名，细节将与整体不连贯；所有接连的信息将与图、系统、工作范围及其他都没有关系。它就像是凭空想象的，没有人能告诉你作者想解释什么。在你描述数据流程图时，对流程的命名一定要用相同的名字。成功标准成功的标准应该包含在一份简短声明，声明中流程的成功是如何被检测，观察，或其他衡量。流程的成功完成会考虑到功能的本质，和它相关的，是在事件中如何解决主要问题。你或许可

5、以理解为流程成功的过程就像“在美国东部时间下午4点清理所有进入流程系统的事务”。事实上满足这种情况对于流程真正成功的过程根本无关。一个更好的成功标准可能是“买方或者卖方的账户被授权操作者鉴定（监督），当事人反对去办公室或者外国资产控制中心检查大量最近可用的数据，并且职员进入交易处理系统清理交易数据”。当描述一个高层次的过程时，成功的标准仍然包括许多相当抽象的，例如，“客户在满意的范围上，和我们继续生意的服务是灵活的”。开始一个流程开始之前，某种状态必须存在，预期的数据必须达成，所有的必要的元素必须到位，并且一个特殊的结果必然发生。描述的就是这些。一个典型的例子就是：l “客户将交易文件拖入到名

6、为FileTrans的交易文件夹中”。l “确认在美国东部时间下午3点开始，每个营业日都有交易发生”。结果除了实现其成功标准(或没有实现)，一个过程同样产生其他事务。解释所有事都是流程在环境的运转中产生或改变。结果比成功的标准更详细，并且不总是关系到成功。当看所有结果时，我们在这一过程中同样可以发现需求。不要过多的担心结果会有多余的成功条件、行为和需求，它在不同地方看到想同信息时同样有帮助。考虑下以下例子：l 所有事件都标记为清理或不清理。l 所有清理的事件都进入到事件处理系统。l 所有客户文件从文件夹移除并存档。l 交易团队管理者能收到增加交货问题的警报邮件。l 事务处理是冻结或恢复基于交易

7、文件的交易状态。因素列出流程所有的执行者。执行者可以是这个过程中的做了某事或将要做某事的任何人、任何事或者任何系统：服务器、软件、数据、操作人员、应付账单或者用户验证流程。行为行为驾驭过程以达到成功的标准。用简单的词描述每个步骤的说明，写下你的句子如下：执行者行为存在某事达成某事操作人员执行者评论行为购买者账目档案存在某事在账单上确认账目数目是否匹配达成某事创建一系列的行为编号描述所有事务，为了实现流程的成功。写操作最大的挑战是明确的事件可能有一个混乱的随机事件列表。考虑如下的例子：1. 母亲让小红帽把篮子给奶奶。2. 母亲指导小红帽直接穿过森林不要和陌生人说话。3. 小红帽拿着篮子离开了异常

8、处理大多数流程包括各种可能的行为，依靠以前行为的结果。简单解释流程的每个行为是有明确的结果和下一个步骤收益，但是我们都知道在各种步骤中要做许多选择，并且经常有意外的或令人不悦的结果。如果我们解释所有事情都尽可能发生在每一刻，我们将被坏事件或混乱的解释打败。许多这一领域的专家简历写一篇成功标准让每一个行为都有预期的结果。一个成功的场景就是一个非常好的事件，但是它有一个邪恶的姐妹：异常。成功的场景经常伴随一连串的异常，例如：“第五步异常：如果账户是无效的，操作人员要求给买家提供帐号，系统不能继续操作除非操作人员拿到正确的帐号，如果买家的帐号确实与命令的不同，操作人员将命令发送给客户服务器解决。看到

9、一行 782：客户服务细节”。一些非常重要的信息（命令不能处理无有效账户）被人为搁置的结果。当完成其他操作后，异常将可能不读到。这样的put-the-exceptions-after-the-success-scenario方式结束了你的事件。试图努力的解释异常就像你孤独的行走，但使用格式和简洁的语言来保存事件的清晰和前进的动力。用一个合理的叙述保存所有真实重要的信息。不要让读者来回看才得到重要信息。异常处理是注重细节的头脑的一个危险的陷进。如果你太注重异常，你将因为异常驾驭而变得“危险”。这是一个漂亮的行话来描述付出这么多的关注到异常，这也是成功的模糊的简单叙述。与其相反的是不能好好专注于异

10、常情况，甚至可以忽略它们，其结果将是发生异常时关闭系统，或者因为没有什么在需求文档指定的想法而由工程师的方式处理。最详细的细节和异常就如中间路径中正确的一道，当然，很大困难去实现。从我写作的背景，我学到了对异常处理有帮助的许多描述分支条件的方法，他们从所需的流程中结合各种简洁的写作格式对异常来加以区分。我列出他们在以下部分中，根据可能的异常大小。缩进段落解释异常放置一个末编号，编号缩进段落之后的行为提供了一个解释简单的异常的好地方，或许任何你想加上的没有混乱的行为。1 操作人员从网络上的共享文件夹中打开日常事务文件。如果文件不存在，他拨打FileTrans的热线号码并要求延迟的原因和恢复时间的

11、估计。如果恢复估计在俩小时内，他推迟时间继续处理重新开始。如果超过俩小时，他发电子邮件给团队宣布，因为FileTrans中断，交易将不会处理直到下一个工作日。2 操作人员在日常文件中提取帐号的交易情况。3 操作人员比较交易帐号和客户的帐号。缩进要点列出可能的异常如果一个段落解释的异常包括太多的分支，它可以增加一个缩进无序列表描述每一种可能性。把文本的序号列出是一个重要的开始，并且左边的数字并不会妨碍行为。注意下面的例子，然后解释如何处理异常，这是我回复读者关心行为的一个短语，“一旦他成功打开了交易文件.”。1. 操作人员从网络共享文件夹中打开日常交易文件如果文件不存在，他拨打FileTrans

12、热线号码通知技术员说明日常交易文件没有传递。l 如果恢复时间少于2个小时，他延迟处理的时间并一遍遍开始这个过程。l 如果操作人员30分钟后不能找到FileTrans，他电子邮件供应商将要求管理升级。l 如果如果他30分钟后也不能查找到FileTrans，他电子邮件供应商也将要求管理升级。l 如果交付估计时间超过2小时，他发送电子邮件给团队并告知FileTrans中断，交易将不被执行直到下一个工作日。2. 一旦他成功的打开了交易文件，操作人员从日常交易文件中提取了帐号。3. 操作人员比较交易帐号和客户帐号。为异常和结果添加一个表如果你能轻松的处理异常和可能的结果，那么就可以考虑用表来解决。在表里

13、，你能在一个列中列出多种可能的结果，解释的结果在下一列，你甚至可以把药店和编号放在第二列的单元格。尽管一些坚定的传统支持者相信表是不以被阅读的，我觉得可以通过扫描表的行列来快速的标识出异常，那样不用查看每一个字，并且可以非常快速，比一个字一个字阅读起来更快，也更有趣。1 操作人员从网络共享文件夹中取出交易文件。可能的异常如果操作在某一天操作人员得到了交易文件并开始处理如果预计恢复在EST.3点半之前，操作人员向交易事务所通知（口头或电子邮件不可用），并且开始在预计时间前一遍一遍重复。如果预计恢复时间在工作日当天EST.3点半后，工作人员发送电子邮件给交易中心宣布交易不被允许，直到下一个工作日。

14、一个内部系统问题阻止了操作人员共享文件工作人员通知经理并询问恢复的预计时间。文件不在共享文件夹里工作人员通知FileTrans报告这个问题。问题需要FileTrans调查工作人员向交易团队宣布延期，如果FileTrans没有在半小时内回应，工作人员向交易团队发布消息。文件不可读工作人员想交易团队再次发送消息。2 一旦他成功打开了交易文件，工作人员从所有的日常交易文件提取帐号。3 操作人员比较交易帐号和客户帐号。注意表的第一行定义了一个响应任何延迟的处理，其余行解释特殊的阻碍，所有的这些都有延时。那不需要重复的为每个异常延迟响应。交叉引用其他流程当一个特殊的复杂的异常超过了你的表处理的范围，那么

15、可以用交叉引的一个流程来处理。1. 工作人员从网络共享文件夹中打开日常交易文件2. 工作人员从日常交易文件中提取帐号如果文件中包含了 Caymen Mortgage-Backed Credit Derivatives的交易，工作人员移除了这些交易并将它通过电子邮件发送给了Mary。看流程63a，“ Caymen Mortgage-Backed Credit Derivatives过程”对于这些行为的解释，你需要在需求时确定。提取需求写清楚能够让发现需求变得十分简单。再次阅读时思考为了结果成功，什么是每一步所需的，也要处理不成功的结果。在早期的文档中发现过多的需求是没错的。回顾流程可以去除不必要

16、的需求。还有一些操作，如用简短和简单的句式来描述需求，并确定能正确的发现有用的需求。要求句式和行为相似，但是你应该重新考虑到他们如果太相似的问题。记住，你只提取最需要的，不是所有事情都会发生，并不是只有结果。语言要求一些分析人员用相当正式的形式，去表述需求，就像开始总是“系统应.”，而这并没有任何技术上的错误，那只是显得单调多余罢了。避免重复的词和用词的要求，没有人想去阅读那样的句子，就像所以开头都是“系统应.”，这些都是表述需求。我们知道他们应该怎么描述怎么做，那么你可以不使用了。或许，你可以引用一系列的有用的描述，就像“系统过滤用一下方式.”动词，比如shall，can，或者will，他们

17、和名词短语结合起来，能组合成复杂的、清晰的、有说服力或者流行的词语，比较下面两段描述：系统应能够查看未知的输入帐号。系统从传入的数据中过滤出未知帐号。第一句话的开始“系统应.”没法添加任何意思和趣味。需求编号当前流程的每一个需求都应编号。这为每一个过程的需求提供了一个唯一的标识符。标识符是一个关键的工具，通过开发过程的追踪防止混乱。需求的描述并不用太长，它们也不是唯一的。同样，他们对查看需求编号和浏览出现的位置十分有用。用流程编号和需求编号，你可以添加前缀，比如R代表要求，FR代表功能需求，所以，你能够从其他文档额数字中得到它。接下来的例子展示了一些功能需求的编号：系统验证输入的交易帐号和客户

18、授权的帐号是否匹配。FR3.1.1：在EST3点半之前交易到达，系统通过手机或邮件通知交易团队。FR3.1.2：当交易文件不存在或者不可读时，系统立即通知FileTrans并询问恢复时间。FR3.1.3：系统在30分钟内通知交易团队无法送达FileTrans。试着在将要连接前想想，尤其是你在手动完成了某一过程时。因为人们知道他们所做的一些事，手动流程经常没有任何提示来表明操作完成。在我们的例子中我们可以添加一个要求系统验证完成的要求。FR3.1.4：验证一个账户后，工作人员添加“Validated”或“Not Validated”在交易单上。一些谚语说到需求就像是实现细节，但是需求的意义和内容

19、是要合适的。流程说明中的数据需求进程写功能需求你就会发现数据需求，数据需求的描述必须获取新数据或数据的改变才能实现流程的成功结果。完成数据需求需要漫长和详细。一般而言，他们不属于过程描述，除非你能让它们非常简单。最好的特殊需求是对单一数据在一个流程里面的描述，和多余数据的特殊文档，通常他们在一个附录。我们刚创建的示例要求交易档案中有“Validated（验证）”文件，但是我们知道现在没有，我们应该添加一些：DR3.1.1：交易档案包括一个“验证”文件，用以在当前交易中，记录用户验证状态。查看交易档案规范在AppendixB，数据规范。我在第五章解释更多关于数据规范。商务规则和非功能需求任何商务

20、规则都将被我们的操作所考虑到。商务规则并不真的属于过程描述，但他们并不是没有意义，其他人都不足以重视。一个商业规则就在我们账户验证的例子中：BZR3.1：公开的所有交易都必须和账户一起接受OFAC的任意行为的记录。确认这商业规则在你的文档的某个地方列出。流程说明同样可以揭示非功能需求，比如适当的管理支持和与供应商的沟通。在这个例子中，成功成功依靠供应商的及时响应，FileTrans，和交易团队管理。说明在流程中可以突出这些需求的重要性，但你也可能想用交叉引用去描述需求：NFR3.1：FileTrans必须在30分钟内响应文件的查询，并估计恢复时间。NFR3.2：交易团队管理必须应对FileTr

21、ans没有回应和在30分钟不能传递的处理。选择结构图和文本图和文字的排列能给你文档带来不一样的成功。选择一个结构和细节层次能更好适应你的观众，能够适应项目的复杂性，也可以成功的操作时间和可用的资源。一种正式的，表格式的方法表格式的方法适用于文档，包含许多正规的细节，特别的是完成至关重要的所有元素。表能让解释和强调的很小的细节难以忘记，这种方法占用更多的空间，但是比创建more-concise更加简单，更少的正式构建。在为任何工程采集需求时，我通常把每个过程描述在一个表里，每行代表每个部分，再加上一点笔记。在很长的一段时间里，more-concise文档的大系统，它可以很好的保持这种结构，然而，

22、那并不是最利于阅读的。表4.1提供给了一个示例完成流程的描述。验证账号成功标准l 所有买方和卖方的账户日常行为，可以通过验证数据库再三的筛选和确认可疑的当事人。l 验证交易进入交易结算系统。开始l 客户交易文件通过FileTrans交付给交易文件夹。l 验证从EST.下午3点开始的每个工作日发生的任何交易。结果l 所以事务是否标记为清除或者不清除。l 所有清楚的交易都进入交易处理系统。l 所有客户文件都从文件夹中移除并存档l 交易团队管理能收到交货问题的邮件警报。l 交易处理是基于交易文件的状态。因素客户，共享的网络资源，工作人员，数据库行为1 FileTrans在共享交易文件夹中提供交易文件

23、。2 工作人员从网络共享文件夹中打开交易文件。可能的异常如果操作在某一天操作人员得到了交易文件并开始处理l 如果预计恢复在EST.3点半之前，操作人员向交易事务所通知（口头或电子邮件不可用），并且开始在预计时间前一遍一遍重复。l 如果预计恢复时间在工作日当天EST.3点半后，工作人员发送电子邮件给交易中心宣布交易不被允许，直到下一个工作日。一个内部系统问题阻止了操作人员共享文件工作人员通知经理并询问恢复的预计时间。文件不在共享文件夹里工作人员通知FileTrans报告这个问题。问题需要FileTrans调查工作人员向交易团队宣布延期，如果FileTrans没有在半小时内回应，工作人员向交易团队

24、发布消息。等不了30分钟工作人员向交易团队再次发送消息。3. 一旦他成功打开了交易文件，工作人员在日常交易文件中提取帐号。4. 工作人员对比交易帐号和客户帐号。l 如果出现未知账户，工作人员将他们从交易文件中取出，并与OFAC数据库最新数据进行对比。l 如果与OFAC数据库有匹配的可疑账户，职员电子邮箱将账户发送给交易团队管理者并等待回应。l 有与OFAC数据库不匹配的账户，职员将添加账户号码作为新的账户（见3.1a，“添加新账户”）5. 工作人员进入事务处理系统验证账户后继续处理。需求（要求）非功能性需求：NFR3.1：FileTrans必须在30分钟内响应文件传输查询，并且告诉预计的时间。

25、NFR3.2：交易团队管理者必须应对FileTrans没有回应和等待的30分钟。商业规则：BZR3.1：公开的所有交易都必须和账户一起接受OFAC的任意行为的记录功能需求：FR3.1：FileTrans必须在EST.下午3点前将日常交易文件传输给交易文件夹。FR3.2：工作人员在下午3点30分时不能交付交易文件的要通过电话或者邮件告知交易团队管理者。FR3.3：当交易文件不存在或者不可读时工作人员要立即通知FileTrans并询问恢复的时间。FR3.4：工作人员要提醒交易团队等待FileTrans的30分钟。FR3.5：账户筛选数据库日常维护并对可疑账户监控。FR3.6：被认定的买卖双方都应遵

26、守公司交易的指导方针。FR3.7：没有记录的未知账户的可疑活动，考虑给创建新账户。NOTES一个简单的Prose-Based方法<言简意赅标题的老式散文比板状结构的更能快速的阅读和写作，但你必须非常自信地包含所有需要的信息。当写一个故事时列表的方法比写作用板状结构的方法更能辨认。它还需要更多的写作技巧。为了节省时间,我们可以决定可能超出范围的内容忽视别人感觉好的决议。在我们的示例中,我们可以决定该文件交付的问题而不是一个工作新项目是什么。我们只有两天去提出一些,所以我们将包含的成功标准，行动，和要求不仅是一个简短的部分，我们还将只包含功能需求。只有当他们出现在行动中我们能辨别出演员，我们

27、不详细的得出所有的过程的结果。注意这些变化有影响的例子。1.1 验证账号成功的标准：账户验证过程的成功表现在账户中的买卖方在日常事务中能确定数据库和筛选数据，验证交易能进入交易结算系统。行为：交易发生在每个营业日预计的时间下午3点验证。1. 文件交易提供事务文件夹共享事务删除文件夹。2. 操作人员从网络上的共享文件夹中打开一个日常事务文件夹。如果在传递文件时有延迟，估计恢复的时间在预计的时间3:30之前有延迟,操作人员将会宣布延迟事务团队(可用口头或电话如果电子邮件不可用),然后开始一遍又一遍确认约定的时间。如果估计的回复的时间在预计时间3点半后,操作工作人员发送一个电子邮件给事务团队宣布交易

28、将不会被处理,直到下一个营业日。3. 一旦他成功地打开了交易文件,操作人员成员将会从所有日常事务文件提取账户数字。4. 操作人员拿交易账号与已知的客户账户进行比较。l 如果有未知账户,操作员工把它们从交易文件夹和检查的未知事务文件中移除从而对帐号进行数据库筛选。l 在数据库中如果有任何相匹配的可疑账户,工作人员用电子邮件把帐号传递给事务管理团队直到收到管理人的回复。l 在账户中没有匹配的账户筛选数据库,工作人员为了进行处理会添加帐户数量(s)到新的账户文件(见3.1,“添加新账户”)。5. 操作人员为了持续处理在在事务处理系统中从而进入验证账户。需求：FR3.1：在预计的时间下午3点，为了日常

29、事务文件交易删除文件夹，文件交易要提供交易文件。FR3.2：如果文件交易在预计时间下午3:30不能完成，操作人员会通过电话或电子有邮件提醒事务管理团队。FR3.3：如果文件交易在30分钟不能完成，操作人员会提醒事务管理团队。FR3.4：帐户筛选数据库为维护日常提要从批准的服务中来监控可疑账户。FR3.5：每笔交易的买方和卖方为各自的交易确立了符合公司交易的指导方针。FR3.6：为创建新帐户将会对没有记录的可疑行为的未知账户进行研究。一个集成的图和需求如果给你的时间很短,你对非常不耐烦文档的阅读不耐烦,最好把所有的信息汇成一个图表。你还必须做出一系列合适的假设,不是详细的介绍一些例外,只说最基本的要求。添加图和部分介绍到目前为止,我已经介绍了信息至关重要的一个过程。在图中解释所有的流程,画一个简要的总结所有的流程和与整体故事文档相关的介绍图。简要的散文叙事连接文档的一部分从而形成一个有意义的故事是至关重要的。过描述过程细节和需求过程，图表和文字结合可以充分的使故事达到要求，传统散文的最佳写作方法是写一个简要的介绍。摘要介绍通常由一个或两个散文段落构成,可能是散文和要点的结合。它包含大部分相同元素来作为一个个体过程进行描述。你把整个图总结(或一系列图)为一个单一的过程来考虑包括下面的每一个点,这非常类似于作为个人的元素来进行过程描述。然而,你不应该觉