TDD开发的全过程之分析建模

一、起因

  公司交给我一个任务,为测试员写一个手机模拟界面,以方便她们的手机短信测试。过去她们都是用MC4J直接调用公司服务器的MBean服务来模拟进行测试,以验证我们整个系统平台。这种测试主要是检查收发短信是否正常,而我的要做的工作就是,让她们在测试的时候更方便更直观。

二、需求

  我和测试员陈MM(也就是软件的使用者)约定了一个时间,大家一起来讨论这个软件的需求。

  1、首先,我大概了解了一下她们的测试工作,知道我要做个什么小编。

  2、然后我回去思考了一下,再次找她详细了解其测试的具体步骤,并在一张白纸上以UML用例图的方式,记录下需求的功能。用例是什么?用例就是需求,就是你的软件应该具有的功能,当然用例图只是概括性的对功能进行了描述。

  3、最后,我坐在我的电脑前开始用MagicDraw UML来画用例图(我不喜欢用Rose,那玩意太笨重了,界面友好性也不好)。在画用例图的时候,我发现了一些隐含的功能,这些是陈MM在和我做需求时没有考虑到的(注:开发者应该为用户挖掘隐含需求)。我和陈MM一一确定了这些我新发现的需求,最后得到如下的用例图。

  (1)手机前台测试操作的用例图(说明:include是指某用例包含(include)子用例)

(2)后台管理

三、界面设计

  接下来是界面设计。既然是手机模拟,我很自然就拿我的motorola手机的操作界面来做参考。不过这里应该注意到,手机操作环境和电脑操作环境不尽相同(比如说电脑有鼠标,还有键盘可以输入文字),所以没有必要唯妙唯肖的完全模枋,还是以使用者操作方便为主。

  界面设计是很重要的一步,不要一上来就写程序,一定要先做到心中有个大概,否则返工的可能性就很大。而且,把界面拿出来给客户看,客户也就能做到心中有数,还能尽早提出一些新需求和意见来。千万不要等到软件做完了再拿给客户看,到时客户看了如果要修改,那就做太多白费工了。

  由于软件界面相对简单,陈MM基本没有提修改意见,但这不是个好兆头。不过极限编程就是要拥抱变化不是^_^。咱不怕她改,只要大致的界面她能定下来就行了。

  界面我喜欢用Visio来画,当然也听说有人喜欢用VB来快速构建界面原型的,看个人喜好了。整个界面如下:

这个是后台管理界面

四、类图

类图反映了软件的数据模型。在设计数据模型,我参考了界面设计图和用例图,找出一个个的类。然后参照用例图的一个个功能,设计出了各类的属性和方法。设计初始的类图当然不可能很详细,但至少应该看到个大概。有错误不要紧,后期可以慢慢修正,但大体关系就算定下来了。

Neil(公司CTO,一个40岁左右的真正的资深程序员)说:看一个软件的设计主要看两个类:类图和时序图。类图确定了软件数据模型的静态关型,时序图则是数据模型的动态关系。

类图如下,看英文大致可以知道类/属性/方法的含义和作用了,就不一一介绍了。

五、时序图

时序图是本文最后一个图,时序图表明了用例图中各功能的实现方案,同时也反应了类图中各类的交互关系。以后程序的逻辑和时序图基本一致。不过,有些人会去画得很详细的时序图,详细到都快赶上伪代码级别了,我觉得这没必要。我把时序图看做反映自己思路的大概过程,所以也就画个大概。

我认为时序图要简洁易懂,这样以后你的后继维护者,拿到这个软件的时序图(当然也包括用例图、类图),就能明白你的大概设计思路。另外,画时序图也能整理自己的思路,同时还可以对类图的设计进行验证。在画这个时序图的过程中,我就纠正了在类图中的几处考虑不周的地方。

总结:时序图可以(1)整理思路(2)验证类的设计(3)是很好的软件文档,对维护者理解代码很有帮助。

这里仅给出其中几个时序图(实际上我也没有把用例都画完,有些类似的简单的,就忽略了。

(1)新增一个手机号码

(2)关机


(3)开机

(4)发送短信

到这里设计阶段就完成了,用时一天。下一步是编码,将应用TDD先写测试代码的方式来写代码。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


什么是设计模式一套被反复使用、多数人知晓的、经过分类编目的、代码 设计经验 的总结;使用设计模式是为了 可重用 代码、让代码 更容易 被他人理解、保证代码 可靠性;设计模式使代码编制  真正工程化;设计模式使软件工程的 基石脉络, 如同大厦的结构一样;并不直接用来完成代码的编写,而是 描述 在各种不同情况下,要怎么解决问题的一种方案;能使不稳定依赖于相对稳定、具体依赖于相对抽象,避免引
单一职责原则定义(Single Responsibility Principle,SRP)一个对象应该只包含 单一的职责,并且该职责被完整地封装在一个类中。Every  Object should have  a single responsibility, and that responsibility should be entirely encapsulated by t
动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强烈推荐。原文截图*************************************************************************************************************************原文文本************
适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,它是针对软件开发中经常遇到的一些设计问题,总结出来的一套通用的解决方案。
模板方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中,使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。
迭代器模式提供了一种方法,用于遍历集合对象中的元素,而又不暴露其内部的细节。
外观模式又叫门面模式,它提供了一个统一的(高层)接口,用来访问子系统中的一群接口,使得子系统更容易使用。
单例模式(Singleton Design Pattern)保证一个类只能有一个实例,并提供一个全局访问点。
组合模式可以将对象组合成树形结构来表示“整体-部分”的层次结构,使得客户可以用一致的方式处理个别对象和对象组合。
装饰者模式能够更灵活的,动态的给对象添加其它功能,而不需要修改任何现有的底层代码。
观察者模式(Observer Design Pattern)定义了对象之间的一对多依赖,当对象状态改变的时候,所有依赖者都会自动收到通知。
代理模式为对象提供一个代理,来控制对该对象的访问。代理模式在不改变原始类代码的情况下,通过引入代理类来给原始类附加功能。
工厂模式(Factory Design Pattern)可细分为三种,分别是简单工厂,工厂方法和抽象工厂,它们都是为了更好的创建对象。
状态模式允许对象在内部状态改变时,改变它的行为,对象看起来好像改变了它的类。
命令模式将请求封装为对象,能够支持请求的排队执行、记录日志、撤销等功能。
备忘录模式(Memento Pattern)保存一个对象的某个状态,以便在适当的时候恢复对象。备忘录模式属于行为型模式。 基本介绍 **意图:**在不破坏封装性的前提下,捕获一个对象的内部状态,并在该
顾名思义,责任链模式(Chain of Responsibility Pattern)为请求创建了一个接收者对象的链。这种模式给予请求的类型,对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为
享元模式(Flyweight Pattern)(轻量级)(共享元素)主要用于减少创建对象的数量,以减少内存占用和提高性能。这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结