想到的一点uml的东西 ~

在学习了UML（统一建模语言）后，我们的矛头指向了 机房收费管理系统的开发文档，我们要在短时间内消化一些uml建模知识，并且建立一个初步的系统模型，做好各项相关的文档，也方便了我们接下来学习.NET ，用.NET 按照写好的文档实际开发一下”升级”后的收费管理系统。

接下来，简短说一说我对其中某些图的”偏见”。

那建模初始，需要做些什么呢？存在需求，这是很重要的一点，这其实也是很浅显的一个道理，有买有卖才为买卖嘛。

开始，我们做系统的目的就是为了满足用户需求，其实这也就是功能上的满足，就是实现某些功能。而这些功能呢，按照相同种类的许多对象共有一些特性，这样就引出了类的概念。uml中的用例图是可以详细描述系统使用的信息的，深入就到了功能的实现上。

把这些东西，这些有着相似特性的东西，层次抽象出来就成了类，按照面向对象的思想，在类里还要有属性、方法、事件。在uml里边再层次抽象一下，将那些功能类似的类划分为一个包，包的概念就是这样，就是将许多类跟接着划分，说白了，这就是一层套一层的关系。在uml里边包图和类图都是很重要的，其中类图就是很贴近具体代码了，算是最深入细节的了吧。

关于如何划分一个软件系统的类，在uml视频中刘惠老师讲到，在和用户进行相关需求交流的时候，涉及到的名词都将会成为类名，动词短语之类的将会成为相关的类的属性、方法。这也就是说，当我们在接到一个项目的时候，动手开发的底层基础就是根据用户的需求，成功划分的类（当然这需要充分理解用户的需求）。继而同样的方法可以用来划分出系统中很多的包。

接着我们可以根据划分类时涉及来判定各类对象间的关系，比如关联（聚合/组合）关系、依赖关系、泛化（继承）关系、实现关系。当然这都需要对准备开发的系统需要十分了解。如是，分清了各类对象之间的关系也就理顺了它们之间的实现顺序关系，并且各对象，实例之间还有交互关系等等。

后面，系统开发末期，会有 部署图 跟进，将整体系统和外围设备环境勾连起来宏观展示。也就是相当于我们站在高处去看问题，实际上也是将一定程度上完善好了的系统整体架构规划一下。


总的，再看一下这个建模过程，就是图的一个”便”，再升至”变”。

便，系统建模方便了系统开发人员和用户等之间的交流，其实也是凸显系统信息的一个传递，使得开发更符合要求的系统成为可能，一定程度上简化了软件开发的复杂度（分析阶段很重要！要有一个良好的开端！）。

变，基于”便”，在这里我想到的是，在后期甚至开发中期，出现的种种需求突变，对于用户方面的要求，我们开发人员还是需要去硬性执行的，为了方便描述问题，方便找到需要更正的地方，建模的优越性就凸现出来了。其实，建模也是对系统内部信息的一种影射。

万变不离其宗，这东东就是随着发展一步一步积淀成的，重要性不容忽视，否则也存活不到今天。


理解的很浅显，还待提高，加油！ (*^__^*) 嘻嘻……