Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Un modelo conceptual explica (a sus creadores) los conceptos significativos en un dominio del
problema; es el artefacto más importante a crear durante el análisis orientado a objetos.
Identificar muchos objetos o conceptos constituyen la esencia del análisis orientado a objetos, y
el esfuerzo se compensa con los resultados conseguidos durante la fase de diseño e
implementación.
La identificación de conceptos forma parte de una investigación del dominio del problema. El
lenguaje UML contiene la notación en diagramas de estructura estática que explican
gráficamente los modelos conceptuales.
El paso esencial de un análisis o investigación orientados a objetos es descomponer el
problema en conceptos u objetos individuales: las cosas que sabemos. Un modelo conceptual
es una representación de conceptos en un dominio del problema. En el UML, se ilustra con un
grupo de diagramas de estructura estática donde no se define ninguna operación. La
designación de modelo conceptual ofrece la ventaja de subrayar fuertemente una concentración
en los conceptos del dominio, no en las entidades del software.
Un modelo conceptual puede mostrar:
• Conceptos
• Asociaciones entre conceptos
• Atributos de conceptos
Además de descomponer el espacio del problema en unidades comprensibles (conceptos), la
creación de un modelo conceptual contribuye a esclarecer la terminología o nomenclatura del
dominio. Podemos verlo como un modelo que comunica (a los interesados como pueden serlo
los desarrolladores) cuáles son los términos importantes y cómo se relacionan entre sí.
CONCEPTOS
En términos informales el concepto es una idea, cosa u objeto. En un lenguaje más formal,
podemos considerarlo a partir de su símbolo, intensión y extensión.
• Símbolo: palabras o imágenes que representan un concepto.
• Intensión: la definición del concepto.
• Extensión: el conjunto de ejemplos a que se aplica el concepto.
Consideremos, por ejemplo, el concepto del evento de una transacción de compra. Podemos
optar por designarlo con el símbolo Venta. La intensión de una Venta puede afirmar que
1
UML Y PATRONES. Introducción al análisis y diseño orientado a objetos. Craig Larman.
Prentice Hall, México 1999, Cap. 9, 10, 11.
“representa el evento de una transacción de compra y tiene fecha y hora”. La extensión de
Venta son todos los ejemplos de venta; en otras palabras, el conjunto de todas las ventas.
Venta
“Una venta
representa el
evento de una
transacción de
compra. Tiene Intensión del concepto
fecha y hora”.
Venta4
Es mejor exagerar y especificar un modelo conceptual con muchos conceptos refinados que no
expecificarlo cabalmente.
2
Es frecuente omitir conceptos durante la fase inicial de identificación y descubrirlos más tarde
cuando se examinen los atributos o asociaciones o durante la fase de diseño. Cuando se
detecten, habrá que incorporarlos al modelo conceptual.
3
Obtención de conceptos a partir de la identificación de frases nominales.
Otra técnica muy útil (por su simplicidad) consiste en identificar las frases nominales en las
descripciones textuales del dominio de un problema y considerarlas conceptos o atributos
idóneos.
Este método hay que utilizarlo con mucha prudencia; no es posible encontrar mecánicamente
correspondencias entre sustantivo y concepto, y además las palabras del lenguaje natural son
ambiguas.
Los casos expandidos de uso son una excelente descripción que puede conseguirse con este
análisis. Por ejemplo, puede usarse el caso de uso Comprar productos.
Algunas de las frases nominales anteriores son conceptos idóneos; algunas pueden ser
atributos de conceptos.
Una debilidad de este enfoque es la imprecisión del lenguaje natural; varias frases nominales
pueden designar el mismo concepto o atributo, entre otras ambiguedades que pueden
presentarse.
4
Tal vez el error más frecuente cuando se crea un modelo conceptual es el de representar algo
como atributo, cuando debió haber sido un concepto. Una regla práctica para no caer en él es:
Por ejemplo, pongamos el caso del dominio de las reservaciones en líneas aéreas. ¿Debería
destino ser un atributo de Vuelo o un concepto aparte Aeropuerto?
Antaño, una tienda llevaba un registro: un libro donde asentaba las ventas y los pagos. Con el
tiempo fue automatizado en un registro mecánico de efectivo. Hoy esa terminal desempeña el
papel del registro. Un registro es una cosa que asienta las ventas y los pagos, pero también lo
es la terminal instalada en el punto de ventas. No obstante, el término registro parece tener un
significado más abstracto y denota una implementación menos orientada que TPDV. Pues bien,
¿en el modelo conceptual deberíamos utilizar el símbolo Registro en vez de TPDV?
1. ASOCIACIONES.
La asociación es una relación entre dos conceptos que indica alguna conexión significativa e
interesante entre ellos.
Registra
TPDV Venta actual
1 1
En el lenguaje UML se describen como “relaciones estructurales entre los objetos de diversos
tipos”.
5
relación? Por ejemplo, ¿debemos recordar cuáles instancias de VentasLineadeProducto están
asociaciadas a la instancia Venta? Claro que sí, porque de lo contrario no sería posible
reconstruir la venta, imprimir el recibo ni calcular el total de la venta.
En cambio, ¿necesitamos recordar una relación entre una Venta actual y un Gerente? La
respuesta es negativa: los requerimientos no indican que haga falta ese tipo de relación.
Notación de las asociaciones en el UML. Una asociación se representa como una línea entre
conceptos con el nombre de la asociación. Esta es intrínsecamente bidireccional, o sea es
posible un nexo lógico entre los objetos de un tipo y los del otro. Este vínculo es totalmente
abstracto; no es una afirmación sobre las conexiones entre las entidades del software.
Los extremos de una asociación pueden contener una expresión de multiplicidad que indique la
relación numérica entre las instancias de los conceptos.
Una flecha opcional de la dirección de la lectura (o “flecha de la dirección del nombre”) indica la
dirección en que debe leerse el nombre de la asociación; no denota la dirección de visibilidad o
de navegación. En su ausencia, por convención la asociación se lee de izquierda a derecha o
de arriba hacia abajo, aunque el UML no hace de esto una regla.
6
A se relaciona con una transacción B Pago-Venta
Pasajero-Boleto
A es una transacción relacionada con otra Pago-Venta
transacción B Reservacion-Cancelacion
A esta contiguo a B TPDV-TPDV
Ciudad-Ciudad
A es propiedad de B TPDV-Tienda
Avion-Linea aerea
¿Qué grado de detalle deberían tener las asociaciones? Las asociaciones son importantes,
pero una falla habitual al crear modelos conceptuales es el excesivo tiempo que, durante la
investigación, se dedica al intento de descubrirlas. Es indispensable convencerse de lo
siguiente:
Es mucho más importante identificar los conceptos que las asociaciones. El tiempo consagrado
a la creación del modelo conceptual debería destinarse a identificar los conceptos, no las
asociaciones.
2. PAPELES.
A los extremos de una asociación se les llama papeles. Estos pueden tener:
• Nombre
• Expresión de multiplicidad
• Navegabilidad
Multiplicidad. Define cuantas instancias de un tipo A pueden asociarse a una instancia del tipo
B en determinado momento.
Por ejemplo, una instancia individual de una Tienda puede asociarse a “muchas” instancias
(cero o más marcadas con *) de Producto.
7
1..* uno o más
T
5 T exactamente 5
Los nombres de las asociaciones comienzan con una mayúscula. Una frase nominal debe
construirse con guiones.
Tipicamente, usted no necesita un nombre si se incluyen los nombres de papeles para la
asociación o si tiene un modelo con varias asociaciones y se necesita referirse o distinguir
entre esas asociaciones.
Dos conceptos pueden tener varias asociaciones entre ellos; esto sucede con frecuencia.
* Vuela-a 0..1
Vuelo Aeropuerto
Vuela-de
* 1
8
3. ATRIBUTOS.
Un atributo es un valor lógico de un dato de un objeto.
Venta
fecha
horadeInicio: Hora
En un modelo conceptual, es preferible que los atributos sean atributos simples o valores puros
de datos.
Entre los tipos comunes de atributos simples más frecuentes se cuentan: Booleano, Fecha,
Numero, Cadena (Texto), Hora.
He aquí otros tipos comunes:
Dirección, Color, Geometría (Punto, Rectangulo, ...), Numero telefonico, Numero del Seguro
Social, Codigo Universal de Producto (CUP), CP o codigos postales, tipos enumerados.
9
Modelo Conceptual del Punto de Venta.
10
DIAGRAMA DE CLASES DE DISEÑO2
La definición de este tipo de diagramas se lleva a cabo en la fase de diseño del ciclo de
desarrollo. Su preparación exige crear antes:
• Diagramas de interacción: a partir de ellos el diseñador identifica las clases de software que
intervienen en la solución, así como los métodos de las clases.
• Modelo conceptual: a partir de éste el diseñador agrega detalles a la definición de las
clases.
En la práctica, estos diagramas suelen elaborarse al mismo tiempo que los diagramas de
interacción. Podemos bosquejar muchas clases, nombres de métodos y relaciones al inicio de
la fase de diseño, aplicando los patrones de asignación de responsabilidades antes de dibujar
los diagramas de interacción.
A diferencia del modelo conceptual, un diagrama de este tipo contiene las definiciones de las
entidades del software en vez de conceptos del mundo real. El UML no define concretamente
un elemento denominado “diagrama de clases de diseño”, sino que se sirve de un término más
genérico: “diagrama de clases”, el autor del libro opto por este otro nombre para recalcar el
punto de vista de diseño en el mismo.
2
UML Y PATRONES. Introducción al análisis y diseño orientado a objetos. Craig Larman.
Prentice Hall, México 1999, Cap. 21.
11
Comparación entre el modelo conceptual y los diagramas de clases del diseño.
En el modelo conceptual una Venta no representa una definición de software; más bien es una
abstracción de un concepto del mundo real acerca del cual queremos afirmar algo. En cambio,
los diagramas de clases del diseño expresan –para el sistema computarizado- la definición de
clases como componentes del software. En estos diagramas una Venta representa una clase
de software.
Venta
Modelo TPDV Captura
conceptual 1 1
fecha
estaTerminada: Booleano
hora
TPDV Venta
Captura
Diagrama de
Clases fecha
1 1
terminarVenta() estaTerminada: Booleano
introducirProducto() hora
efectuarPago()
Venta
fecha
estaTerminada
hora
hacerLineadeProducto()
12