Unified Modeling Language 的出现给当今面向对象的世界增添了浓墨淡彩的一笔。可视化的建模工具让开发人员丰富地表达了他们的想象力，并且以uml的方式向其他人展示。
首先我们得理解什么是面向对象(Object Oriented)。对象是各种各样的实体，即是具体的事物也是抽象的事物。面向对象不光是对对象的属性和行为建模，它还包括其它方面。其中就有抽象、继承、多态和封装。抽象的概念很抽象，其意思是说抽象出你所需求的属性和操作，即是所需的东西。它是一种从一般的观点看事物的方法，焦点应该集中在事物的本质性质上，而不要过分地去追求细节，应该是抽象出一般化的东西。世界是复杂的，但不能因为它复杂就不去理解它，我们可以把它抽象化，其实抽象后世界也不大。
继承：顾名思意就是子类拥有父类的所有的内部状态和运动规律。公共的东西可以被子类分享，正所谓，子又有孙，孙又有子，子子孙孙无穷溃也。当然不能像这样来设计。
多态：多个形态，同样的一种动作，在不同的对象进行演绎的时候可能演绎的细节就会不一样。正所谓大家都喜欢吃，但是男人吃饭跟女人吃饭就不一样。男的可能吃的快吃的多，女的吃的少吃的慢，但大家都是吃这个动作，换了个对象来吃，就效果不一样。
封装：举个例子，人们在看电视时，人们看到的是电视的屏幕，电视的按钮，至于屏幕为什么上面会有美女，按下按钮为什么会换台，人们好象不必去关心其是怎么工作的吧，当然也有闲人喜欢钻牛角尖。所以电视机就封装了如何让屏幕显示美女的工作。那么电视机的按钮和屏幕实际上就是电视机给我们这些喜欢看电视的人的接口。我们关心的也只是这些接口。至于这些接口怎么实现的，请交给厂家吧，世界也就是由若干个各司其职的人组成的。
重载：说白了就是做同一件事的几种不同的方案。比方说：在公司加班，正常情况下，默认是吃盒饭，有一天老板归来，来一句走出去吃饭我请。如果用方法来表示的话就是public void eat(盒饭类 a) public void eat(饭店类a ,老板类b )。
消息传递：在这个世界里，光有对象是不够的，那样人都是行尸走肉。对象之间是要相互协作的。那么相互协作之间是通过相互发送消息的方式。比方说看电视，我们使用遥控器打开电视。那么遥控器对象就向电视机对象发送了一个开机的消息。电视机对象接收了此消息后就打开了。
正如世界是一个由若干个对象以及对象之间的若干个错综复杂的关系组成的。那么对象与对象之间又会有什么样的关系呢？打开电视时，我们说是你和电视机之间发了关联关系。再比方说你暗恋一个女生，你跟她之间形成了一个单向的关联关系。因为她不知道你暗恋她，当然你暗恋她，她也暗恋你的情况也有可能出现，此处我们不予探讨。如果她也暗恋你，那就是一个双向的关联关系。对象之间的依赖关系说明是目标对象与源对象之间的依赖关系。依赖就是当目标对象有所变化的时候源对象也相应的发生改变。
收集系统需求时，把用户的业务需求转换成开发人员能够理解的需求，并最终把需求转化为代码。通过将需求映射为代码，可以保证代码满足这些需求，同时代码也可以回溯成需求。这样的过程就称为建模。建模过程的结果可以跟踪业务需求，到要求、到模型，到代码的全过程及其相反的过程，而不会在这个过程中迷路。
可视化建模将模型中的信息用标准的图形元素直观的表示。这个标准的图形元素就是本文中提到的UML。它的出现为用户、开发人员、分析人员、测试人员、管理人员、需求调研人员等相关人员提供了沟通的桥梁。其中很直观的例子：对于用户来说，他更关心自己需要在这个系统中操作什么，以及这些操作是否满足了自己的业务需要，那么利用模型他可以直观的看到自己与这个系统的交互，根据这样的交互保证需求的获取。对于分析人员来说，他需要分析模型的对象之间的交互，以及这样的交互是否满足系统的需要，是否可以保证这样的交互对于业务的解析，解决自己分析时存在的疑惑，同时也可以根据模型交互的结果向需求调研人员提出问题。对于开发人员来说，他要考虑开发的对象以及这些开发对象需要完成的工作。对于测试人员来说，他们根据模型看到对象间的交互并且根据这些交互以及交互的产出准备测试用例。在RUP中就可以同步地进行测试了，而不是像瀑布模型那样最后才准备测试。对于项目管理人员来说，他需要看到系统中各个部分或者子系统之间的交互，在项目的实施过程根据计划看到各个系统模型完成的情况及相应的进度。对于公司的主管人员来说可能只需要看到更高层的模型，看到各个子系统运行情况结果。可视化的建模确实带来了系统的可控。通过先建模再编写代码，从一开始就保证了系统的结构合理。利用模型可以更方便地捕获设计缺陷，从而以较低的成本修正这些缺陷。
Rational Rose是分析和设计面向对象软件系统的强大的可视化工具，可以用来先建模系统再编写代码，支持业务模型，帮助了解系统的业务，有助于系统分析，可以先设计使用案例和Use Case框图，显示系统的功能。也可以用Interaction框图显示对象之间如何配合，提供所需的功能。Calss框图可以显示系统中对象及其相互关系。Component框图可以演示类如何映射到实现组件。最后Deployment框图可以显示系统的网络结构。Rose模型的四个社图是：Use Case视图、Logical视图、Component视图和Deployment视图。每个视图针对不同对象，具有不同的用途。
Use Case视图包括系统中的所有角色、使用案例和Use Case框图，还包括一些Sequence或Collaboration框图。该视图是系统中与实现无关的视图。该视图关注系统功能的高层形状，而不关注系统具体的实现方法。项目开始时，开发小组可以选择使用Use Case视图中生成业务模型，完成了业务模型后便是使用案例模型。客户、分析人员和项目经理利用使用案例、Use Case框图和使用案例文档来确定系统的高层视图。随着项目的进行，开发小组的成员也可以通过Use Case视图了解正在建立的系统的使用案例文档，通过使用案例描述事件流程。利用Use Case视图，测试人员开始编写测试脚本，技术人员开始编写文档。一旦用户同意了角色和使用案例，就确定了系统的范围。然后可以在Logical视图中继续开发，关注系统如何实现使用案例中提出的功能。
Logical视图，关注系统如何实现使用案例中提出的功能。提供系统的详细图形，描述组件间如何关联，还包括特定的类、Class框图和StateChart框图，利用这些元素，开发人员可以构造出系统的详细设计。该视图关注的是系统的逻辑结构，在这个视图中，要标识系统组件，检查系统的信息和功能，检查组件之间的关系。
Component视图，包括模型代码库，可执行文件，运行库和其他组件的信息。系统的Component视图可以显示代码模块间的关系。详细包括：组件，代码的实际模块；Component框图，显示组件及其相互关系；包，相关组件的组。该视图的主要用户是控制代码和编译部署应用程序的人。有些组件是代码库，有些是运行组件。
Deployment视.图，关注于系统的实际部署。还包括容错，网络带宽，故障恢复和响应时间等。详细包括：进程，是在自己的内存空间执行的线程；处理器，任何有处理功能的机器；设备，包括任何没有处理功能的机器，如打印机。
下面讨论UML以及UML的可视化工具给我们带来了什么样的好处。rose建立的业务模型关注系统针对的业务。业务模型包括：业务角色、业务用例、业务工人。业务模型研究的是业务的机构以及机构的角色。在建立业务模型的过程中，检查机构的结构和机构中的角色以及它们之间的相互关系，还需要介绍机构的工作流，公司中的主要过程，以及这些过程如何的工作，效率如何，是否有任何的瓶颈。简要的说就是要弄清楚业务的内部和外部，以及内外部如何进行通信。那么这些信息都将被记录在业务模型中。业务模型中框图有助于外部世界和机构的关系，以及机构如何完成这些目标。业务模型的主要工具之一是工作流框图。这些框图描述机构中的特定过程流程；显示这个过程中参与的人员，这个过程的步骤和参与这个过程的业务实体。业务过程建模人员首先用工作流框图建模当前过程，然后可以分析这些框图，寻找工作流中的缺陷和其他问题。完成业务模型的好处在于开始规划系统工作之前就完全了解了业务过程，这样就可以事先确定最需要自动化的工作流领域和系统中最有助于机构开发的部分从而建立对公司或者机构最有利的系统。
实体类：实体类是要永久保存的信息。实体类通常在事件流和Interaction框图中，是对用户最有意义的类，通常用业务域术语来命名。边界类：边界类位于系统与外界的交界处，包括所以窗体、报表、打印机和扫描仪等硬件的接口以及与其他系统的接口。要寻找和定义边界类，可以检查Use Case框图。每个角色／用例 交互至少要有一个边界类。控制类：控制类负责协调其它类的工作。每个用例通常都有一个控制类，控制用例中的事件的顺序。在Interaction框图中，控制类具有协调责任。