1、一对一,一对多,多对一,多对多
软件设计过程位于软件开发过程的前期。它的任务就是把现实世界中的需求映射到问题域的各个对象。如果能做到一一映射那自然最后不过了,因为这样做的一个好处就是最大程度地保证了软件的可重用,每个对象都是独立的,即对一个对象或类的修改不会波及到另一个对象。但是,这种情况可能永远都是可遇而不可求的。现在的软件产品,门类繁多,功能复杂,除了要满足业务逻辑功能,还要实现其他各种五花八门的辅助功能,举个简单的例子,比如在数据库每一次读写完成之后要进行日志记录,那么这一个小小的功能可能就会散布在众多的与数据库读写有关的功能模块中,这样势必造成功能模块与辅助模块之间的多对一的映射关系。现在假如还要在每次数据库读写前后加入审计授权功能,那么每个相关的功能模块又势必形成多对一的映射关系。在把两种情形组合起来,就形成了众多业务功能与众多辅助功能之间的多对多的映射。天哪,真够乱的。在这种情况下,要修改,维护一个功能,不管是业务功能还是辅助功能,都会牵扯到许多对象。这样就违背了软件设计的至高原则:可重用性。真可谓牵一发而动其全身。由这种现象造成的软件开发失败的例子想必不在少数,尤其是那些开发周期长,需求变化快的项目更是如此。
此为设计师的困惑之一。
2、设计过度与设计不足
如果有一些需求自始至终保存一成不变的项目该多好呀。但是这在现代软件开发世界里可能再也找不到了。在开发一个具体的项目时,往往要考虑众多的因素,如竞争对手,上级的期望,客户的要求,程序员的要求,开发时间,效率,性能...等。如何在这些因素中追求一种平衡,需要设计者的知识与经验。但是即使考虑得再周全,也不可能完全适应需求的变化。有的需求简直可以说天天在变,有时随着开发过程在变。要知道世界上没有先知先觉的天才,当前看起来“周全的,完美的”的设计,过些日子再看就不那么完美了,要么是设计不足(underdesign),要么是设计过度(overdesign),当然也不能完全否定这两种情况。在一定意义和环境下,它们还有一定的好处。设计不足可以降低短期开发阶段的成本,可以缩短产品投放市场的时间,可以预防设计臃肿,而设计过度则可以增强长期开发的可控性,更好地适应需求变化,已及提供较为长久的软件质量。但是要辩证地看待这两种情况,它们在一定条件下是可以相互转换的。所以对于设计者来说,只能是尽可能地去做尽可能好的设计。
此为设计师的困惑之二。
对于第一个困惑,很大原因都属于于当前工程开发方法的本身的问题。而第二个困惑,则属于现实世界中的客观存在。这两者都是无法避免的。所以对于设计师而言,他们要做的是追求一种平衡。对于第一个困惑,他们要追求的是如何尽可能用最少的模块,完成系统的功能,而又最大程度地减少个模块之间的耦合。而耦合过少,可能会达不到系统的要求,耦合过度则会影响系统的效率,降低可重用性。对于第二个困惑,他们要追求的是如何尽可能地满足日益变化的需求。设计不足和设计过度都会使得项目陷入困境,因此设计师往往要在影响项目的众多因素中寻求平衡,做到既顾此而又不失彼。
这种追求平衡的过程将贯穿在整个项目的生命周期,并将伴随在设计师的整个设计生涯。其结果是经验的提升,知识的扩充以及综合能力的历练与成熟。