闪电咂摸软件隐喻与建模

软件隐喻

 

人们都有幻想的能力，这种幻想带有联系性，如果你具有类比和推理能力，这将是奇妙的。

我们做一件事情的时候，总是希望一个结果，这个结果我们可以把它设想成种种事物。

用之于软件，我们称之为隐喻。

比如以前我做Web应用，往往充斥着用户的各种各样的需求，这些需求堆积起来就在脑海中有了图纸，我把他们适配于各种模块，潜意识里就把这个过程想象成组装电脑的隐喻。

当然组装好了难免要进行调试，或许它“滴滴”的会报警，这时候可以根据警报的声音，长度啊大小的去诊断错误的所在，在程序中，往往表现为功能的不通或不爽。

调通之后，机器会正常运行，这时候程序就可以上线了，交给客户，当然客户还会提出这样那样的完善性需求。于是，我就会给机器加屏幕保护仪、摄像头、扫描仪、打印机之类的辅助设备。

当然这种隐喻对于大型软件的构建并不是十分的可取，或许只是一种瞎想。

有一种隐喻对于绝大部分软件的构建都是成功的，就是把整个过程想象为建造一个建筑物，建筑物需要各种材质，各种格调的适配，各种色彩的搭配，以及给观赏者带来的感觉（用户体验）等。

初期构建，要考虑到成本，需要的材料，人员数量，角色搭配，工期长度。
中期建设，要考虑到施工进度，如何巧妙的节省材料，增加稳定度和优秀度。
后期完善，要考虑到装饰装潢，给用户带来的感觉。

这三部就如同小学生学写作文时候的“大三段”一样，只是个初级考虑，里面的细节可能错综复杂，但无论如何，脑海中有个形象的东西总比概念化要好的多。

 

建模

 

对于很多开发人员甚至设计人员来说,UML是比较困惑的东西,在一些项目的开发中,我们往往不能够正确的使用UML.
在一个项目中,我把使用UML的过程放在了项目早期需求挖掘分析的位置上从而得到了一些好的收效,所以把一点体会与大家分享一下.

1.尽可能使用最简单的工具帮助你理解业务.
   UML可以是一张白纸上的涂涂画画,也可以的开发组的若干个成员在白板上的智慧的结晶,用于分析或探讨解决方案的复杂部分,总之只要是能清晰地或接近清晰地描述业务,那你的UML就是有意义的.
2.珍惜你的头脑风暴
   UML不是文档也不能把它作为文档的作用来使用,它只是你在理解业务的过程中头脑里的快照而已,由于头脑风暴的缘故,项目早期开发人员对业务的理解过程是有连续性的,所以你最好用UML把你的理解记录下来.
3.把握恰当的时机
   项目的早期UML作为草图,并不用于大范围的设计,只是处理一些棘手,困难,不常见,较为复杂的业务问题,而一些简单的设计问题,可以推延到编程阶段由开发人员去完成它.
4.迭代过程中的UML
   这时的UML作为蓝图,主要用于设计和编码的实现,它与开发人员的关系更亲切些,从有利于理解业务到有利于编码实现业务过渡,这种实现是奇妙的.
5.总结
   从一定意义上来说,UML能够很大程度的帮助我们分析问题,取得对需求的最大程度理解,而这种分析正是取得与客户理想软件的最大一致性的可靠保障.无论你采用迭代式开发还是进化式分析,UML总能够很好的帮助你梳理业务.

 

附上UseCase用例模板: