爱雨语
驱动牛犊
驱动牛犊
  • 注册日期2018-05-02
  • 最后登录2018-06-13
  • 粉丝0
  • 关注0
  • 积分-50分
  • 威望110点
  • 贡献值0点
  • 好评度0点
  • 原创分0分
  • 专家分0分
阅读:16回复:0

创建敏捷模型的初衷

楼主#
更多 发布于:2018-06-13 09:19
要想了解敏捷开发,你需要了解模型和敏捷模型之间的区别。模型是一个抽象的概念,它描述了一个的问题的一个或多个方面,或是处理这个问题可能的解决方案。传统意义上,模型被认为是图表加上相应的文档。然而那不够直观的artifact,也可以被视为模型,例如CRC卡片集,单条或多条业务规则的文字描述,或是业务流程的一段结构化英文描述。一个敏捷模型就是一个刚刚足够好的模型。但是你怎么知道什么时候模型才是刚刚足够好呢?当敏捷模型显现出如下的特性时,它就是刚刚足够好的:
敏捷模型实现了它们的目的。有时你为沟通而建模,或许你需要把你工作的范围告诉高级经理;有时你为理解而建模,或许你需要确定一个设计策略,实现一组Java类。一个敏捷模型是否足够好,要看它是不是满足了创建它时的初衷。
敏捷模型是可理解的。敏捷模型要能为其预期听众所理解。使用用户能够理解的业务语言来描述需求模型,反之,技术架构模型则需要使用开发人员熟悉的技术术语。你所使用的建模符号会影响易懂性--如果你的用户不了解UML用例图中的符号的含义,那用例图对用户就没有任何价值。这样的话,要么使用另一种方法,要么教授用户学习建模技术。风格问题同样也会影响易懂性,例如避免交叉线。杂乱的图表比清晰的图表难懂。模型的细节程度(见下文),也会影响易懂性,因为相较一个不那么详细的模型来说,一个过于详细的模型要难于理解。简单(见下文)同样是影响易懂性的一个因素。
敏捷模型是足够正确的。模型通常都不需要100%正确,只要足够正确就行了。举个例子,如果一张街道地图漏画了一条街道,或是它标示某条街道是通行的,但你发现它已经关闭维修了,那你会不会扔掉你的地图开始在城里飙车犯罪呢?不太可能。你会考虑更新你的地图,你可能会拿出笔来自己做修改或是去当地的商店买一张最新版的地图(你原来的那张过期了)。也许你还是会接受那张虽不完美但仍可使用的地图,因为它对你来说已经足够好了。你还是可以用这张地图四处转转,因为它还是个正确的模型,标记出了大部分街道的位置。你在发现这张地图不正确的时候,你没有立刻扔掉它,原因是你根本不在乎它是否完美。类似的,当你在需求模型、数据模型中发现错误的时候,你也会选择更新或是接受--虽不完美但已经足够好了。有些项目成员能够容忍这种不正确而有些则不能:这取决于项目的特性,每个团队成员的特性,组织的特性。充分正确性既和模型的听众有关,也和你要处理的问题有关。
敏捷模型是足够一致的。一个敏捷模型并不需要和自己(或其它有用的artifact)保持完全的一致。如果一个用例在它的一个步骤中显式的调用了另一个用例,那么相应的用例图需要用UML的 <> 版型来标记这两个用例之间的关系。然而,你看了看图表,发现它们并没有这样做,天哪!用例和图之间不一致!危险!太危险了!红色警报!快逃命呀!等一下,你的用例模型是有不一致的地方,但也没到世界末日啊。是的,理想情况下,你的所有artifact最好是能够完全一致,但这通常是不可能的。当我开发一个简单的商用系统时,我通常都可以容忍部分的不一致。但有时我是不能容忍这种不一致的。最有力的佐证就是1999年 NASA发射火星太空探测器时采用了精密的测量系统。要树立一个观点,敏捷模型只要足够一致就行了,你通常不需要使用那么完美的模型。
游客

返回顶部