以前一提到UML,就想到了复杂的流程图。很敬佩哪些想想就能画出整个系统的UML图的人,因为他们头脑中有整个软件架构的蓝图,这样在编写实现的时候,就会知道哪个地方改怎么做,哪个地方如何扩展。 而想成为架构师,UML也是必备的技能。这里就根据《大象——Thinking in UML》总结一些学习笔记。
平时总是在说什么是面向对象,什么是面向过程。
面向过程,就是典型的C语言这种,一个main函数,从头走到脚,中间可能涉及到一些方法的调用,但是整个代码完全是流水线一样。这样就会导致一个问题,虽然代码流程很清晰,但是不容易扩展,我需要修改某一个计算过程,有可能导致全部代码需要重写。
而面向对象,就是以一种对象的角度来编写程序,设计程序,每个对象具有自己的生命特征。每个对象内部具有一些复杂的变量以及方法,对外提供接口或者公共方法进行调用,这就是封装。而对象之间可以互相关的继承,借鉴存在的方法,这就是继承。相同类型的对象,可以提取公共的部分,形成一个新的父类对象,这就是抽象。每个相同类型的子对象之间可能存在不同的方法,这就是多态。
这样,通过对象的方式,来看待世界,整个过程就变得解耦了,一旦需要扩展或者修改某个地方,单纯的修改与之对应的对象就可以了。
而这其中的难点,就是如何从现实世界中的业务场景转换到抽象的对象模型;而通过复杂对象模型如何表示业务场景。
通过上面这个步骤,就可以从现实世界抽象出模型来表示业务场景了。
首先通过建模,把现实世界中需要的一些数据进行建模,建立对应的模型。
然后根据这些模型去设计相关的一些概念,比如控制类,实体类,以及边界的展现类。
最后设计这些概念模型,进行代码级的实现。
设计思想有了,那么就出现了一种叫做RUP的统一建模的过程模式,通过这种建模的模式,可以完整而且稳定的展示一个软件的软件生命周期。
通过这四个阶段,9个核心,完美的诠释了传统软件的生命活动,但是现代的软件开发,大多讲究极限编程,敏捷开发,想要通过快速的迭代更新,来进行快速的适应,以满足快速的需求变化。但是对于一些10年之久的系统来说,稳定才是最重要的,因此这种统一过程往往是最佳的选择。
对于UML来说,我们最难的就是如何建模了!
首先要明确,建模的目的是什么?需要满足什么业务场景!其次,根据多种场景抽象出模型。
传统的方式可以通过自顶向下,或者自底向上的方式来进行。
自底向上,就是首先建立底层小对象的模型,再通过组合等方式,拼凑出完整的业务场景。
自顶向下,就是先进行大体的场景描述,再慢慢的细分功能。
一般都是这两种方式,不断的迭代,最终找到合适的方案。