Para crear las mejores soluciones, debe seguir un proceso detallado para 

analizar 

los 

requerimientos

 de su 

proyecto (es decir, determinar 

qué es lo que se supone debe hacer el sistema) y desarrollar un 

diseño

 que cumpla 

con esos requerimientos (es decir, decidir 

cómo debe hacerlo el sistema). Idealmente usted pasaría por este proceso 

y revisaría cuidadosamente el diseño (o haría que otros profesionales de software lo revisaran) antes de escribir 
cualquier código. Si este proceso implica analizar y diseñar su sistema desde un punto de vista orientado a objetos, 
lo llamamos un 

proceso de análisis y diseño orientado a objetos (A/DOO)

. Los programadores experimentados 

saben que el análisis y el diseño pueden ahorrar innumerables horas, ya que les ayudan a evitar un método de de-
sarrollo de un sistema mal planeado, que tiene que abandonarse en plena implementación, con la posibilidad de 
desperdiciar una cantidad considerable de tiempo, dinero y esfuerzo.
 

A/DOO es el término genérico para el proceso de analizar un problema y desarrollar un método para resol-

verlo. Los pequeños problemas como los que se describen en los primeros capítulos de este libro no requieren de 
un proceso exhaustivo de A/DOO. Podría ser sufi ciente con escribir 

pseudocódigo

 antes de empezar a escribir el 

código en Java; el pseudocódigo es un medio informal para expresar la lógica de un programa. En realidad no es 
un lenguaje de programación, pero podemos usarlo como un tipo de bosquejo para guiarnos mientras escribimos 
nuestro código. En el capítulo 4 presentamos el pseudocódigo.
 

A medida que los problemas y los grupos de personas que los resuelven aumentan en tamaño, los métodos 

de A/DOO se vuelven más apropiados que el pseudocódigo. Idealmente, un grupo debería acordar un proce-
so estrictamente defi nido para resolver su problema, y establecer también una manera uniforme para que los 
miembros del grupo se comuniquen los resultados de ese proceso entre sí. Aunque existen diversos procesos de 
A/DOO, hay un lenguaje gráfi co para comunicar los resultados de 

cualquier proceso A/DOO que se ha vuelto 

muy popular. Este lenguaje, conocido como Lenguaje Unifi cado de Modelado (UML), se desarrolló a mediados 
de la década de los noventa, bajo la dirección inicial de tres metodologistas de software: Grady Booch, James 
Rumbaugh e Ivar Jacobson.

Historia de UML

En la década de los ochenta, un creciente número de empresas comenzó a utilizar la POO para crear sus aplica-
ciones, lo cual generó la necesidad de un proceso estándar de A/DOO. Muchos metodologistas (incluyendo a 
Booch, Rumbaugh y Jacobson) produjeron y promocionaron, por su cuenta, procesos separados para satisfacer 
esta necesidad. Cada uno de estos procesos tenía su propia notación, o “lenguaje” (en forma de diagramas gráfi -
cos), para transmitir los resultados del análisis y el diseño.
 

A principios de la década de los noventa, diversas compañías (e inclusive diferentes divisiones dentro de la 

misma compañía) utilizaban sus propios procesos y notaciones únicos. Al mismo tiempo, estas compañías que-
rían utilizar herramientas de software que tuvieran soporte para sus procesos particulares. Con tantos procesos, 
se les difi cultó a los distribuidores de software proporcionar dichas herramientas. Evidentemente era necesario 
contar con una notación y procesos estándar.
 

En 1994, James Rumbaugh se unió con Grady Booch en Rational Software Corporation (ahora una división 

de IBM), y comenzaron a trabajar para unifi car sus populares procesos. Pronto se unió a ellos Ivar Jacobson. En 
1996, el grupo liberó las primeras versiones de UML para la comunidad de ingeniería de software, solicitan-
do retroalimentación. Casi al mismo tiempo, una organización conocida como 

Object Management Group™ 

(OMG™, Grupo de administración de objetos)

 hizo una invitación para participar en la creación de un lenguaje 

común de modelado. El OMG (

www.omg.org

) es una organización sin fi nes de lucro que promueve la estanda-

rización de las tecnologías orientadas a objetos, emitiendo lineamientos y especifi caciones como UML. Varias 
empresas (entre ellas HP, IBM, Microsoft, Oracle y Rational Software) habían reconocido ya la necesidad de 
un lenguaje común de modelado. Estas compañías formaron el consorcio 

UML Partners (Socios de UML)

 en 

respuesta a la solicitud de proposiciones por parte del OMG (el consorcio que desarrolló la versión 1.1 de UML y 
la envió al OMG). La propuesta fue aceptada y, en 1997, el OMG asumió la responsabilidad del mantenimiento 
y revisión de UML en forma continua. La versión 2 que está ahora disponible marca la primera modifi cación 
importante al UML desde el estándar de la versión 1.1 de 1997. A lo largo de este libro, presentaremos la termi-
nología y notación de UML 2. 

¿Qué es UML?

UML es ahora el esquema de representación gráfi ca más utilizado para modelar sistemas orientados a objetos. Evi-
dentemente ha unifi cado los diversos esquemas de notación populares. Aquellos quienes diseñan sistemas utilizan 
el lenguaje (en forma de diagramas) para modelar sus sistemas.

1.16 Ejemplo práctico de Ingeniería de Software: introducción a la tecnología de objetos y UML 

21

01_MAQ_CAP_01.indd21

4/19/081:18:17AM