,但是,稍后我认识到,在涉及计算机的文字时,本身结构足够清晰,所以不需要多想。但是我仍然要组织文字结构,虽然这在我头脑中是半意识的。即便我们认为自己的计划只是一上来就开始编码,在后续阶段仍然需要不断地询问和回答一些问题。
任务陈述
无论构建什么系统,不管如何复杂,都有其基本目的的,有其要处理的业务,有其所要满足的基本需要。通过依次审视用户界面、硬件或系统的特殊细节、算法编码和效率问题,我们将最终找出它的核心。通常简单又直接。就像来自好莱坞电影的所谓的高层概念,我们能用一句或两句话表述。这种纯粹的表述是起点。
高层概念很重要,因为它设定了项目的基调,这是一种任务陈述。我们不必一开始就让它正确(我们也许正处于在项目变得完全清晰之前的最后阶段),但是要不停地努力直到它越来越正确。例如:在一个空中交通指挥系统中,我们可以从关于正在建立的系统的一个高层概念入手:"塔楼程序跟踪飞机"。但是当我们将这一系统收缩以适用于一个非常小的机场时,它考虑将发生什么情况:可能只有一个控制人员甚至什么都没有。一个更有用的模型不应当它描述问题那样多地关注正在创建的解决方案,例如"飞机到达、卸货、维修、重新装货和离开等"。
第一阶段:我们在做什么?
这一阶段中我们有必要把注意力始终放在核心问题上:确定这个系统要做什么。为此,最有价值的工具是一组所谓的"用例"。用例指明了系统中的关键特性,它们将战线我们使用的一些基本的类。它们实际上是对类似下述这些问题的描述性回答:
*"谁将使用这个系统?"
*"执行者用这个系统做什么?
*"执行者如何使用这个系统工作?"
*"如果其他人也做这件事,或者同一个执行者有不同的目标,该怎么办?(揭示变化)
*"当使用这个系统时,回发生什么问题?(揭示异常)
通过确定用户在系统中可能有的所有的交互行为,用例就生成了需求规范说明。我们试图找到系统的完整用例,完成之后,我们就得到了系统任务的核心内容。将注意力集中在用例上的好处是,它们总是带回到要点部分而不留心那些对完成任务无关紧要的问题。也就是说,如果得到了全部用例就可以描述系统并进入到下一个阶段。在最初的尝试中我们很难完全得到特征,但这已经很好了。任何事物随着时间的推移都会自己暴露出来,如果在这一点上就要求系统规范说明完美将会永远止步不前。
阶段2:我们将如何建立对象?
在这一阶段,我们必须做出设计,描述这些类和他们如何交互。确定类和交互的出色技术是类职责协同(Class-Responsibility-Collaboration,CRC)卡片。此技术的部分价值是它非常简单:只有一组3到5英寸的空白卡片,在上面书写。每张卡片描述一个类,在卡片上写的内容是:
1.类的名字。这是很重要的,因为名字体现了类行为的本质,所以有一目了然的作用。
2.类的职责:它应当做什么。通常,它可以仅由成员函数的名字陈述(因为在好的设计中,这些名字应当是描述性的),但并不产生其他的注记。如果需要开始这个过程,请从一个懒程序员的立场来看这个问题:你希望有什么样的对象魔术般地表现,把你的问题全部解决?
3.类的协同:它与其他类有哪些交互?"交互"是非常宽泛的术语。它可以是一些已经存在的其他对象对这个类的对象提供的服务。协同还应当考虑这个类的观众。例如如果创建了鞭炮,那么谁将观察它,是药剂师,还是观众?前者希望知道鞭炮由什么化学成分组成,后者对鞭炮爆炸后的颜色和形状有反应。
我们可能想让卡片更大一些,因为我们希望从中得到全部信息,但是他们是非常小的,这不仅能保持我们的类小,而且能防止过早地陷入许多的细节。如果一张小卡片上放不下类所需要的信息,那么这个类就太复杂了(或者是考虑过细了,或者应当创建多个类)。理想的类应当一目了然。CRC卡片的思想是帮助我们找到设计的第一印象,是的我们能得到总体概念,然后精炼我们的设计。
在我们开始用CRC卡片之前,当提出最初的设计时,我最成功的咨询经验就是站在一个没有OOP经验的项目组前,在白板上描述对象。我们讨论对象应当如何互相通信,擦除其中的一些,用其他的对象代替它们。实际上我是在白板上管理所有的"CRC卡片"。项目组(他们知道项目的目标)真正地在做这个设计,他们"拥有"这个设计,而不是获得即成的设计。我所做的所有事情就是通过提问正确的问题,提炼这些假设,并且从项目组得到反馈,修改这些假设来指导这个过程。这个过程的真正好处是项目组学习了如何做面向对象的设计,不是通过复审抽象的例子,而是通过在一个设计上工作,这对于他们是最有兴趣的。
制作了一组CRC卡片之后,我们可能希望用UML创建这个设计的更形式化的描述。我们并不非要用UML,但它可能有所帮助,特别是如果我们要将一个图表挂在墙上,让大家一起思考时,这是一个很好的想法。除了UML之外的另一个选择是对象机器接口的文字描述,这或许依赖于我们的程序设计语言,也就是代码本身。
UML还提供了另外一种图形符号来描述系统的动态模型。在一个系统或子系统的状态转换占主导地位,以至于它们需要自己的图表的情况下,这是有帮助的(例如在控制系统中)。我们可能还需要描述数据结构,因为系统或子系统中数据结构是重要因素(例如数据库)。
当已经描述了对象及其接口后,阶段2也就要完成了。这时已经知道了对象中的大多数,通常会有对象漏掉,知道阶段3才被发现。这没问题。我们关心的是最终能够找到所有的对象。在这个阶段较早地发现它们是好的。因为OOP提供了充分的结构,所以如果我们稍迟发现它们也可以。事实上,对象设计可能在程序设计全过程的五个阶段中都会发生。
对象设计的五个阶段
阶段3:创建核心
这是从粗线条设计向编译和执行可执行代码体的最初转换阶段,特别是,它将证明或否定我们的体系结构。这不是一遍的过程,而是反复地建立系统的一系列步骤的开始,我们将在阶段4中看到这一点。
我们的目标是寻找实现系统体系结构的核心,尽管这个系统在第一遍不太完整。我们正在创建一个框架,在将来的反复中可以完善它。我们正在完成第一遍多系统集成和测试,向风险承担者提出反馈意见,关于他们的系统看上去如何以及如何发展等等。理想情况下,我们还可以暴露一些严重的问题。我们大概还可以发现对最初的体系结构能做那些改变和改进----本来在没有实现这个系统之前,可能是无法了解这些内容的。
建立这个系统的一部分工作是实际检查,就是对照需求分析和系统规范说明与测试结果(无论需求分析和规范说明以何种形式存在)。确保我们的测试结果与需求和用例符合。当系统核心稳定后,我们就可以向下进行和增加更多的功能了。
阶段4:迭代用例
一旦代码框架运行起来,我们增加的每一组特征本身就是一个小项目。在一次迭代期间,我们增加一组特征,一次迭代是一个相当短的开发时期。
一次迭代有多长时间?理想情况下,每次迭代为一到三个星期(具体岁实现语言而异)。在这个 期间的最后,我们得到一个集成的、测试过的、比前一周期有更多功能的系统。特别有趣的是迭代的基础:一个用例。每个用例是一组相关功能,在一次迭代中加入系统。这不仅为我
们更好地提供了"用例应当处于什么范围内"的概念,而且还对用例概念进行了巩固,在分析和设计之后这个概念并为丢弃,它是整个软件建造过程中开发的基础单元。
当我们达到目标功能或外部最终期限到了,并且客户对当
上一篇:
vb电表管理系统vb+access源代码+可执行程序+论文(论文和程序)
下一篇:
高容量手机电池产品开发论文