Thinking in UML（一）从现实世界到设计模型

@H_301_0@ 通过开发机房收费系统，从个人开发vb.net版到合作开发，自己对项目的认识也在一点点的积累着。当我们做过项目之后，再回头去看看那些关于关于面向对象、软件架构、面向对象分析的书的时候，那种感觉是很美妙的。接下来，我将用一个系列文章来讲述对UML在软件过程中的思考。

@H_301_0@我们在开发项目的时候，我们首先会想到需要分析，然后呢，会想到用UML中的用例图来捕获需求；接下来呢，我们会根据自己的需求分析，然后结合自己的用例图，就开始了对类的抽象；接着是对给类添加方法，接下来呢，我们最常用的会是时序图，用来表示一个个的用例实现，好象这一切都是自然而然的事，在对类进行抽象的时候，更象是一拍脑门”嗯，就是这样的！”。

@H_301_0@RUP与UML

@H_301_0@实际上不仅仅是RUP和UML的关系，对软件项目来说，面向对象也好，面向过程也好，UML也好，UC矩阵也好，这些都不是最重要的，软件项目真正的是软件过程，软件过程的需要才是这些工具和语言诞生的原因。因此建议大家在学习UML之前，应当先系统学习软件过程。只有掌握了软件过程，才会知识为什么要有用例，为什么要有分析模型；站在软件过程的立场，那些孤独的UML视图才会变得有生命力，才会知道在什么时候，在什么地方需要用什么样的UML图符来表达软件的观点，也才会知道什么时候，在什么地方需要用什么样的UML图符来表达软件观点，也才会知道UML的那些视图到底在软件开发过程里起到了什么作用。认识到这些，UML的元模型和视图就不会面目可憎，它们是一群有着强大能力的精灵，帮助我们在复杂的软件工程道路上搭起一座座通向光明目标的桥梁。

@H_301_0@从现实世界到设计模型

@H_301_0@1、从现实世界到业务模型

@H_301_0@这是把现实世界映射到对象世界的第一步。UML采用用例这一关键元素捕获了现实世界的人要做的事，再通过用例场景、领域模型等视图将现实世界的人、事、物、规则这些构成现实世界的元素用UML这咱语言描述出来。面UML本身被设计成为一种不但适于现实世界理解，也适于对象世界理解的语言，所以用UML来描述现实世界这句话可以衍生换一下说法，变成：现实世界被我们用一种对象型语言描述。

@H_301_0@2、从业务模型到概念模型

@H_301_0@这是从对象世界来描述现实世界的方法。业务模型是用分析类来描述的，用例所代表的现实的业务过程，被“边界”、“控制”、“实体”以及“包”、“组件”等概述替代。面这些概念是可以被计算机理解的。现实世界千差万别的业务，都用“边界”、“控制”、“实体”这几个固定的元素来描述，也就是说，现实具体的业务被“抽象”成几个固定的概念。同时，这些概念还可以用“包”、“组件”等这些与现实世界毫不相干的纯计算机逻辑术语包装。这说明概念模型是计算机视角，或者说是对象视角的，而且这些对象视频的分析类所描述的信息是从映射了现实世界的业务模型转化而来的。

@H_301_0@可以说，从业务模型到概念模型这一过程，正是我们需要的一种从对象世界来描述现实世界的方法。

@H_301_0@3、从概念模型到设计模型

@H_301_0@这是验证对象世界是否正确反映了现实世界的方法。“边界”、“控制”、“实体”这些对象化的概念，虽然是计算机可以理解的，但是它并不是真正的对象实例，即它们并不是可执行代码，概念模型只是纸上谈兵。真正的对象世界行为是由Java类、C++类、EJB、COM+等这些可执行代码构成的。然而，如果缺省了从概念模型到设计模型这个过程，Java类也好，C++也好，它们的行为是否正确凭什么去验证呢？

@H_301_0@换句话说，荆概念模型在特定环境和条件下的“实例”化，实例化后的对象行为“执行”了概念模型描述的那些信息，因此设计模型得以通过概念模型追溯到原始需求来验证对象世界是否正确反映了现实世界。

@H_301_0@这张图，可以深刻地反映出这一点

@H_301_0@

Thinking in UML（一）从现实世界到设计模型

猜你在找的VB相关文章