Desarrollo de sistemas

orientado a objetos con

modelado en UML.
Desarrollo de sistemas orientado a objetos con modelado en UML.

Desarrollo de sistemas orientado a objetos con modelado en UML.

Ciclos de vida para el desarrollo de software.
¿Qué es un ciclo de vida?
Forma en que se organiza la ejecución básica del desarrollo de software,
representa la “columna vertebral” de una metodología.
Hay dos modelos básicos:
1. Secuencial.
2. Iterativo (por ciclos cortos de desarrollo).

Ciclos de vida SECUENCIALES

Proponen la ejecución de etapas de manera secuencial, es decir, una etapa
inicia una vez que la anterior ha culminado por completo.
La construcción del producto de software se realiza completa al final del
ciclo de vida.
El cliente obtiene el producto hasta el final del proyecto y lo obtiene
completo (en una sola implantación).

1. Ciclos de vida Cascada.

Propone la realización de 4 etapas secuenciales:
- Especificación y análisis de requerimientos
- Diseño de la solución
- Implementación del código fuente
- Pruebas e implantación del producto

2. Ciclos de vida Cascada por propósitos.

Similar al modelo de cascada pero se entrega un prototipo al final de la
etapa de diseño (antes de empezar la implementación del código fuente).
El prototipo puede ser funcional (tener parte del código implementado) o no
serlo.
El prototipo puede ser reutilizable (ser aprovechado para la versión final del
producto) o no serlo (en cuyo caso no necesariamente es desarrollado en la
misma herramienta en la que se implementará la versión final).

Ciclos de vida ITERATIVOS

Proponen dividir la construcción del software en ciclos o iteraciones, donde:
en cada iteración se alcanza determinado nivel de desarrollo ó en cada
iteración se abarca una parte de la funcionalidad total del sistema.
Al final de cada iteración se realiza una presentación parcial del producto al
cliente. Permite corregir errores durante la propia construcción del software.

1. Ciclo de vida evolutivo.

Propone abarcar toda la funcionalidad del sistema desde el primer ciclo, de
modo que se va refinando conforme se avanza en el desarrollo.
El cliente ve resultados parciales que contemplan todo el producto completo
(aunque en diferentes niveles de desarrollo: prototipo, prototipo validado,
prototipo con conexión a la BD, etc.). Normalmente, el primer ciclo es muy
pretencioso.

2. Ciclo de vida incremental.

Propone dividir la funcionalidad del sistema en “bloques” que se irán
abarcando cada uno en un ciclo independiente.
Desarrollo de sistemas orientado a objetos con modelado en UML.

El cliente ve resultados parciales que contemplan una parte del producto

funcionando al 100%.
Al final de cada ciclo se integra lo realizado en ese ciclo con lo que ya
estaba terminado.
Normalmente, antes de iniciar el primer ciclo se realiza una fase de
conceptualización del problema global.

Metodología de desarrollo basada en un ciclo de vida iterativo e incremental.

Esta compuesta por 3 fases:

1. Conceptualización y planeacion.
Objetivos:
 Entender el problema a resolver por parte del equipo
desarrollador
 Planear el proyecto informático que dará solución al
problema

Pretende establecer:
 El entorno del problema
(¿Dónde está el problema?)
 Las funcionalidades del sistema
(¿Qué quiere el usuario?)
 El alcance del proyectos
(¿Hasta dónde abarcará el proyecto?)
Productos esperados:
 Diagramas y Modelos:
UML-Diagrama General de Casos de Uso.
UML-Modelo Conceptual.
UML-Glosario de Términos.
 Documentos:
Especificación de Requerimientos del Software (ERS).

2. Fase de Construcción.

Objetivos:
 Realizar el diseño de la solución al problema estudiado en la
fase 1.
 Construir el producto de software (aplicación informática)
que dará solución al problema planteado por el usuario

Se divide en ciclos
Cada ciclo contiene 3 etapas:
 Modelaje
(Generación de diagramas y modelos)
 Implementación
(Programación del código fuente)
 Pruebas e integración
(Aplicación de pruebas unitarias y de integración)

Productos esperados:
Diagramas y modelos:
Desarrollo de sistemas orientado a objetos con modelado en UML.

 UML-Refinamientos (Casos uso, Modelo conceptual, Glosario

de términos.)
 UML-Diagramas de Secuencia
 UML-Contratos de las Operaciones
 UML-Diagramas de Colaboración
 UML-Diagrama de Clases de Diseño
 Modelo de Datos
Documentos:
 Informe del Ciclo i.
Otros:
 Especificación de Estándares.

3. Fase de Despliegue de la aplicación.

Objetivos:
 Certificar la calidad del software implementado.
 Implantar el producto software en el entorno del
usuario/cliente.

Se deben aplicar:
 Pruebas de Ejecución.
(¿Hace lo que el usuario pidió?)
 Pruebas de Rendimiento.
(¿Lo hace tan eficiente como el usuario lo pidió?)

Productos esperados:
Documentos:
 Informe Final del Proyecto.
 Manual de Usuario.
Software ejecutándose en el entorno del cliente.
Desarrollo de sistemas orientado a objetos con modelado en UML.

UML dentro de las fases de un proyecto.

Aspectos generales de UML.
UML: Unified Modeling Languaje(Lenguaje de modelado unificado).
¿Qué es UML?
Es un lenguaje de Modelado que incluye diagramas y documentos útiles
durante diferentes etapas de un proyecto.
Concebido por Grady Booch, Ivar Jacobson y Jim Rumbaugh, contratados por
Rational Software Co. para crear una notación estándar para su CASE.
También participaron empresas como Microsoft, IBM, Hewlett-Packard y
Oracle.
Es sólo una notación, no define un proceso de desarrollo específico.
Consiste en una secuencia de modelos, diagramas y documentos que
ayudan tanto a la comprensión del problema como al diseño de la solución.
Ha sido tomado en cuenta por algunos autores en sus metodologías (p.e.
Larman).

1. UML en la Fase de Conceptualización y planeacion:

1. Entender el problemas:
UML interviene en la creación de:
 Casos de uso: definir las necesidades del cliente.
 Modelo conceptual: comprender el entorno del problema.
 Glosario de términos: comprender el entorno del problema.
2. Planear la ejecución del proyecto.

2. UML en la Fase de Conceptualización y planeacion:

1. Diseñar la solución:
- Análisis:
UML interviene en la creación de:
 Casos de uso (Formato extendido).
 Diagramas de secuencia.
 Contratos de Operaciones.
- Diseño:
UML interviene en la creación de:
 Casos de uso (reales).
 Diagramas de colaboración.
 Diagramas de clases.
2. Implementar el Software.

3. UML en la Fase de Despliegue:

1. Certificar el Software:
UML interviene en la creación de:
 Casos de uso: para pruebas finales.
2. Poner en marcha el software en el cliente.

Casos de Uso.
Algunas definiciones de casos de usos:

1. Un documento narrativo que describe la secuencia de eventos de un

actor (un agente externo) que usa un sistema para completar un
proceso.
Desarrollo de sistemas orientado a objetos con modelado en UML.

2. Una interacción típica entre un usuario y un sistema de cómputo.

3. Un caso de uso es una descripción de un proceso de principio a fin.

Características de un caso de uso:

 Capta alguna función visible para el usuario.
 Puede ser pequeño o grande.
 Logra un objetivo discreto para el usuario.

¿Cómo identificar los casos de uso?

Opción A: Basada en Actores.
1. Identificar los actores relacionados con el sistema o la empresa.
2. Para cada actor, identificar los procesos que inicia o en los que participa.
Opción B: Basada en Eventos.
1. Identificar los eventos externos a los que un sistema ha de responder.
2. Relacionar los eventos con los actores y con los casos de uso.
Algunos ejemplos de casos de uso:

 Retirar efectivo de un cajero automático.

 Registrar las carreras que imparte una universidad.
 Solicitar el envío de un pedido de productos.
 Facturar una venta de productos.
 Registrar una solicitud de ingreso.

¿Cuándo y para qué usar casos de uso?

Al inicio del proyecto: Para comprender mejor la interacción entre el sistema
y sus diferentes usuarios. Para establecer los distintos perfiles de usuario (y
así ayudar a establecer la seguridad del sistema).
Durante el diseño: Para detallar más a fondo el accionar de los usuarios
frente a la interfaz del sistema.
Al final del proyecto: Para establecer los escenarios de prueba.

Tipos de casos de uso.

Primario:
Representan los procesos comunes más importantes del sistema.
Se consideran indispensables urgentes.
Ejemplos:
 Registrar Producto (en un sistema de inventario).
 Facturar Compra (en un sistema de facturación).
 Registrar Calificación (en un sistema académico).
Secundario:
Representan los procesos menores o poco frecuentes, pero que
complementan el sistema.
Se consideran indispensables y pero no urgentes.
Ejemplos:
 Eliminar Producto (en un sistema de inventario).
 Anular Facturar (en un sistema de facturación).
 Modificar Calificación (en un sistema académico).

Opcional:
Representan los procesos que pueden perfectamente no abordarse en el
proyecto.
Se consideran no indispensables y no urgentes.
Desarrollo de sistemas orientado a objetos con modelado en UML.

Normalmente, se hacen “si sobra tiempo”

Ejemplos:
 Registrar bodeguero (en un sistema de inventario).
 Modificar tipo de cambio del dólar (en un sistema de facturación).
 Enviar calificaciones a los estudiantes por email (en un sistema
académico).

Diagramas de casos de uso.

Diseñado por Ivar Jacobson en 1994.

Explica gráficamente un conjunto de casos de uso de un sistema, los actores
y la relación entre éstos y los casos de uso.
Su objetivo es ofrecer un diagrama contextual que nos permita conocer
rápidamente los actores externos del sistema y las formas básicas en que lo
utilizan.

Ejemplo de Diagramas de casos de uso:

ELEMENTOS
 Caso de Uso:
Desarrollo de sistemas orientado a objetos con modelado en UML.

Encapsula una interacción usuario-sistema.

Su nombre debe estar compuesto por: <Infinitivo verbal>+<Complemento>
Se representa mediante un óvalo.
 Actor:
Es una entidad externa del sistema que de alguna manera participa en la
historia del caso de uso.
Estimula al sistema con eventos de entrada o recibe algo de él.
Los actores están representados por el papel que desempeñan en el caso:
Cliente, Cajero, Solicitante, Vendedor, Bodeguero, etc.
Se representan mediante una figura estilizada. A pesar de que los actores
estén representados por figuras humanas, no es necesario que los actores
sean seres humanos. Un actor puede ser también un sistema externo que
necesite cierta información del sistema actual.
 Relaciones (actores –casos de uso)
Para vincular un caso de uso a un actor basta con agregar un arco entre
ambos.
Los actores pueden tener varios papeles respecto de un caso de uso:
obtener un valor de él o sólo participar de él. En el segundo caso tiende a
ser confuso quién es el verdadero actor vinculado con ese caso de uso.
Por ejemplo, en un sistema de ventas, para el caso de uso “Enviar
proforma” no se tiene un actor específico que solicite la acción en su propio
beneficio (pues a quien en realidad le interesa la proforma es al cliente). Sin
embargo, probablemente el actor Vendedor le interese enviarla para
obtener una posterior venta por lo que sí existirá vínculo.

 Relaciones (entre casos de uso)

Se representan como una línea que une a los dos casos de uso relacionados,
con una flecha y una etiqueta entre corchetes (<< , >>).
Tipos de relación entre casos de uso
Extiende: <<extends>> Se usa cuando se tiene un caso de uso que es
similar a otro, pero que hace un poco más.

Usa: <<uses>> Se usa cuando se tiene una porción de

comportamiento que es similar en más de un caso de uso y se quiere
reutilizar.

Modelo Conceptual.
El paso esencial de un análisis o investigación orientado 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.
Consiste en un modelo que describe y relaciona los conceptos que
intervienen en el entorno del problema.
Desarrollo de sistemas orientado a objetos con modelado en UML.

El diseño de un modelo conceptual tiene como fin subrayar fuertemente los

conceptos del dominio, no las entidades del software.
Un modelo conceptual puede mostrar:
 Conceptos.
 Asociaciones entre conceptos.
 Atributos de los conceptos.

Un modelo conceptual es una descripción del dominio de un problema real,

no es una descripción del diseño del software, como una clase de Java o C+
+”.
Por ello, un modelo conceptual no debe incluir:
 Artefactos de software (ventanas, base de datos).
 Responsabilidades o métodos (operaciones).

Un concepto, para ser parte de un modelo conceptual, debe tener:

 Símbolo: Palabras o imágenes que le representen.
 Intensión: Definición propia del concepto.
 Extensión: Conjunto de ejemplos a que puede aplicarse.
Cuando se crea un modelo conceptual, por lo general la vista del símbolo y
de la intensión de un concepto es lo que más interesa.

En el análisis estructurado, la descomposición se realiza mediante procesos

o funciones.
En el análisis orientado a objetos, es posible realizar la descomposición con
base en los conceptos del entorno.

Estrategias para identificar los conceptos:

 Es mejor exagerar y especificar un modelo conceptual con muchos
conceptos refinados que no especificarlo cabalmente. No piense que un
modelo conceptual es mejor si tiene pocos conceptos.
 Se suelen omitir conceptos durante la fase inicial y descubrirlos más
tarde, cuando se examinen atributos o asociaciones o durante el diseño.
Cuando se detecten, deben incorporarse al modelo conceptual.
 No excluya conceptos porque los requerimientos no digan que
requiera persistencia, o porque carezca de atributos, pues podría ser
parte importante del comportamiento.
 El error más frecuente cuando se crea un modelo conceptual es
representar algo como atributo, cuando debió haber sido un concepto.

¿Cómo construir un Modelo Conceptual?

Desarrollo de sistemas orientado a objetos con modelado en UML.

1. Liste los conceptos idóneos (utilizando la lista de categorías y las frases

nominales).
2. Dibújelos como cajas o rectángulos.
3. Incorpore las asociaciones necesarias para registrar las relaciones.
4. Agregue los atributos necesarios para cumplir con las necesidades de
información.

Asociaciones:
Una asociación es una relación entre dos conceptos que indica alguna
conexión significativa e interesante entre ellos.
Es conveniente incluir las siguientes asociaciones en un modelo conceptual:
 Las asociaciones en que el conocimiento de la relación ha de ser
preservado durante algún tiempo (asociaciones que “deben
conocerse”).
 Las asociaciones provenientes de la Lista de Asociaciones Comunes.

Sin embargo 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.
Asociaciones Múltiples:
Pueden existir múltiples asociaciones entre los mismos conceptos.
Atributos:
Un atributo es un valor lógico de un dato de un objeto.
Incluya aquellos atributos en que los requerimientos indican o conllevan la
necesidad de recordar información.
No se debe incluir como atributo de un concepto el “identificador” de un
concepto relacionado con él.

Glosario de términos.
Es un documento simple en el que se describen los términos utilizados.
Pretende mejorar la comunicación y aminorar el riesgo de malos entendidos.
Se crea originalmente en la primera fase del proyecto. Luego, se va
refinando conforme avanza cada ciclo de desarrollo.

Ejemplo:
Término Categorí Comentarios
a
Comprar Caso de Descripción del proceso de un cliente que
Productos uso compra productos en una tienda
Producto Concepto Un producto para venderse en una Tienda
Venta.total : Atributo El gran total de la Venta
Cantidad
Pago Concepto Un pago en efectivo

Definición en formato expandido

Un caso expandido de uso muestra más detalles que uno de alto nivel.
Suelen ser útiles para alcanzar un conocimiento más profundo de los
procesos y los requerimientos.
Su formato está compuesto por tres partes:
–Superior.
–Intermedia.
–Inferior.
Desarrollo de sistemas orientado a objetos con modelado en UML.

Parte Superior:
Caso de Uso:<Nombre del caso de uso>
Actores: Lista de actores en la cual se indica quien inicia el caso de uso.
Propósito: Intención del caso de uso.
Resumen: Repetición de la descripción en alto nivel (o algo similar)
Tipo:<Primario / Secundario / Opcional>
<Esencial / Real>
Referencias Cruzadas: Casos de uso relacionados y/o funciones
relacionadas.

Parte Intermedia:
(Curso normal de eventos)
Describe los detalles de la conversión interactiva entre los actores y el
sistema.
Explica la secuencia más común de los eventos: “la historia normal de las
actividades y la terminación exitosa de un proceso”. No incluye situaciones
alternas o imprevistas.
El primer evento suele iniciar con “Este caso de uso empieza cuando…”.

Parte Inferior:
(Curso alterno de eventos)
Describe importantes opciones o excepciones que pueden presentarse en
relación con el curso normal.
Siguen el formato <excepción> <acción>.
Si son complejas, se pueden expandir y convertirlas en casos de uso
independientes.

Casos Esenciales de Uso:

Contienen poca tecnología y pocos detalles de implementación.
Las decisiones de diseño se posponen.
Un caso de este tipo describe el proceso a partir de sus actividades y
motivos esenciales.
Convienen al comenzar a investigar los requerimientos, para entender mejor
el alcance del problema y las funciones necesarias.

Casos Reales de Uso

Describen el proceso a partir de su diseño concreto actual, sujeto a las
tecnologías específicas de E/S.
A menudo ofrece presentaciones de la pantalla a utilizar en el sistema.
Suelen ser útiles cuando la plataforma de ejecución del sistema tenga
características peculiares.
Ejemplo de caso expandido de Uso (Esencial)
Caso de Uso: Retirar Dinero del Cajero Automático.
Actores: Cliente.
Propósito: Realizar un retiro de dinero de una cuenta.
Visión General: Un cliente llega al cajero automático, introduce la tarjeta, se
identifica y solicita realizar un retiro de dinero. El cajero le da el dinero
solicitado tras comprobar que la operación puede realizarse. El cliente toma
el dinero y se va.
Tipo: Primario y Esencial
Referencias: Requerimiento # 7
Desarrollo de sistemas orientado a objetos con modelado en UML.

Curso Típico de Eventos:

Acción del Actor Respuesta del Sistema
1. Este caso de uso empieza cuando 2. Pide la clave de identificación.
un cliente introduce su tarjeta en el
cajero.
3. Introduce la clave. 4. Presenta las opciones disponibles.
5. Selecciona la operación de Retiro 6. Pide la cantidad a retirar.
7. Introduce la cantidad requerida. 8. Procesa la petición y,
eventualmente, da el dinero
solicitado.
10. Recoge el dinero, el recibo y la 9. Devuelve la tarjeta y genera un
tarjeta. recibo.
Curso Alternativo:
Acción del actor Respuesta del sistema.
Línea 4: La clave es incorrecta. Se indica el error y se cancela la
operación.
Línea 8: El saldo no es suficiente. Se indica el error y se cancela la
operación.

Diagramas de Secuencia.
Un diagrama de secuencia muestra gráficamente los eventos que fluyen de
los actores al sistema.
Forma parte del proceso de análisis.
Su creación depende de la formulación previa de los casos expandidos de
uso.
Pretende explicar lo que el sistema hace pero no cómo lo hace.
Ejes:
El vertical es el tiempo (fluye de arriba hacia abajo).
En el horizontal se colocan los objetos y/o actores.
El sistema y cada actor tienen una línea vertical.
Los eventos (mensajes) se representan mediante flechas; pueden incluir
parámetros y se ordenan según su secuencia en el tiempo.
Se suele agregar una nota con el curso normal de eventos del caso de uso
expandido.

Ejemplo:
Desarrollo de sistemas orientado a objetos con modelado en UML.

El nombre de una operación debe mostrar el propósito inmediato de ésta.

Se recomienda que el nombre de los eventos empiece con un infinitivo.
Las operaciones deben expresarse a nivel de propósito y no de
implementación o interfaz.

Contratos de las Operaciones

Se elaboran durante el análisis de cada ciclo de desarrollo.
Para su preparación son muy tomados en cuenta:
Modelo Conceptual.
Diagrama de Secuencias.
Contribuyen a definir el comportamiento de un sistema.
Muestran el efecto que tienen las operaciones sobre el sistema.
Describen el comportamiento de un sistema a partir de cómo cambia el
estado de éste cuando se invoca una de sus operaciones.
Un contrato describe lo que una operación se propone lograr.
Se declara enfatizando lo que sucederá y no cómo se conseguirá.
Puede elaborarse un contrato tanto para una operación del sistema (las del
diagrama de secuencias) o para un método de una clase software.
Secciones de un Contrato:
 Nombre:<nombre de la operación y parámetros>.
 Responsabilidades: Descripción informal de las responsabilidades
debe cumplir la operación.
 Tipo:<sistema, clase software>.
 Referencias Cruzadas: Requerimientos y/o Casos de Uso.
 Notas: Notas de diseño, algoritmos e información afín.
 Excepciones: Casos excepcionales.
 Salidas: Salidas atípicas del sistema (por salidas no estándar).
 Precondiciones: Suposiciones acerca del estado del sistema. antes de
ejecutar la operación.
 Poscondiciones: El estado del sistema después de la operación.
Desarrollo de sistemas orientado a objetos con modelado en UML.

¿Cómo preparar un contrato?

1. Identifique las operaciones del sistema a partir de los diagramas de
secuencia.
2. Elabore un contrato para cada operación.
3. Comience redactando las Responsabilidades.
4. Complete luego la sección de Poscondiciones, describiendo los cambios
de estado de los objetos del modelo conceptual.
5. Para describir las poscondiciones utilice las siguientes categorías:
 Creación y eliminación de las instancias.
 Modificación de los atributos.
 Asociaciones formadas y canceladas.

Poscondiciones: Estipulan cómo cambió el sistema tras la operación.

No son acciones que deben efectuarse durante la operación.
Son declaraciones sobre el estado del sistema que se aplican una vez
concluida la operación (una vez que se haya disipado el humo).
UML no específica cómo expresar las poscondiciones: el analista escoge el
formato.

Ejemplo:
Nombre: introducir Producto (CUP: número, cantidad: entero)
Responsabilidades: Registrar la venta de un producto y agregarla a la venta
total. Desplegar la descripción y el precio del producto.
Tipo: Sistema.
Referencias Cruzadas:
Req.1, 3 y 4
Caso de Uso Comprar Productos
Notas: Tomar en cuenta el uso de códigos de barras
Excepciones: Si el CUP no está registrado, indicar el error.
Salidas:
Precondiciones: El sistema conoce el CUP.

Poscondiciones:
• Si se trata de una nueva venta, se creó una Venta (creación de instancia).
• Si se trata de una nueva venta, la nueva Venta fue asociada al Punto De
Venta (asociación formada).
• Se creó una instancia LíneaDeDetalle (creación de instancia).
• Se asoció una instancia LíneaDeDetalle a la Venta (asociación formada).
• Se asignó cantidad a LineaDeDetalle.cantidad (modificación de atributo)
• Se asoció una instancia LineaDeDetalle a la instancia
EspecificacionDeProducto, basado esto en la correspondencia del
CUP(asociación formada)

Diagramas de Colaboración.
Diagramas de Interacción:
Se realizan durante el diseño de cada ciclo de desarrollo.
Desarrollo de sistemas orientado a objetos con modelado en UML.

Son diagramas que explican gráficamente cómo los objetos interactúan a

través de mensajes para realizar las tareas.
El punto de partida de las interacciones es el cumplimiento de las
poscondiciones de los contratos de operaciones.

Requieren la previa creación de:

 Modelo Conceptual: A partir de éste, el diseñador podrá definir las
clases software correspondiente a los conceptos.
 Contratos de las Operaciones: A partir de ellos, el diseñador identifica
las responsabilidades y las poscondiciones que han de llenar los
diagramas de interacción.
 Casos Reales de Uso: A partir de ellos, el diseñador recaba
información sobre las tareas que realizan los diagramas de interacción

Son muy importantes en la asignación de responsabilidades y el diseño de

la colaboración entre los objetos.
Los diagramas de interacción constituyen uno de los artefactos más
importantes que se generan en el análisis y en el diseño orientado a
objetos.
Existen dos tipos:
1. Diagramas de Colaboración: Describen las interacciones entre los objetos
en un formato de grafo o red.

2. Diagramas de Secuencia: Describen las interacciones entre los objetos en

un formato de cerca o muro.
Desarrollo de sistemas orientado a objetos con modelado en UML.

¿Cómo preparar un Diagrama de Colaboración?

1. Elabore un diagrama por cada operación del sistema durante el ciclo
actual de desarrollo.
2. Diseñe un sistema de objetos interactivos que realicen las tareas, usando
como punto de partida las responsabilidades y poscondiciones del contrato
de operación y la descripción de casos de uso.
Ejemplo:

Relación entre artefactos:

Casos de Uso (eventos del sistema)
Diagrama de Secuencia.
Contratos (operaciones del sistema).
Diagrama de colaboración (mensajes entre objetos internos del sistema).

Clases e Instancias: Nombre del tipo subrayado y precedido por dos puntos.

Vínculos: Línea continúa a través de la cual pueden fluir mensajes.

Mensajes: Se representan por medio de una flecha con un nombre y situada

sobre un vínculo. Se agrega un consecutivo que indica el orden de los
mensajes.
Desarrollo de sistemas orientado a objetos con modelado en UML.

Parámetros: Se anotan dentro de paréntesis, después del nombre del

mensaje. Es opcional incluir o no el tipo de parámetro en cuestión.

Retorno de valores: Puede incluirse un valor de retorno, ante poniéndole al

mensaje un nombre de variable y un operador de asignación (:=). Es
opcional mostrar el tipo de valor de retorno.

Mensajes a “this”: Un objeto puede enviarse un mensaje a sí mismo. Se

representa con un vínculo a sí mismo, pues el mensaje fluye por el vínculo.

Iteraciones: Se indica posponiendo un asterisco (*) al número de secuencia.

También es posible incluir una cláusula de iteración que indique los valores
de recurrencia.
Desarrollo de sistemas orientado a objetos con modelado en UML.

Condicionales: Se indican posponiendo al número de secuencia una cláusula

condicional entre corchetes. El mensaje sólo se envía si la cláusula se envía
como verdadera.

Condicionales mutuamente excluyente: Se utilizan letras minúsculas

(a,b,c,...) después del número de secuencia para indicar la exclusividad
entre los posibles caminos.

Diagrama de Clases.
Una vez que se tienen los diagramas de interacción, se procede a definir las
clases software que conforman el sistema.
Su elaboración requiere previamente:
 Diagramas de Interacción: Para identificar las clases y los métodos.
 Modelo Conceptual: Para agregar detalles a la definición de las
clases.

¿Cuándo elaborarlo?
A pesar de que se supone que deben hacerse después de los diagramas de
interacción, en la práctica se realizan en forma paralela.
Representa el cierre del diseño de la aplicación.
Por ejemplo, conforme se diseña el diagrama de colaboración, van
apareciendo los métodos que estarán contenidos dentro de las clases.
Desarrollo de sistemas orientado a objetos con modelado en UML.

El diagrama de clases describe gráficamente las especificaciones de las

clases de software en una aplicación.
Normalmente contiene:
 Clases.
 Atributos.
 Métodos.
 Asociaciones.
 Navegabilidad.
 Dependencias.

Asociaciones de Herencia:
Se dan cuando varias clases poseen atributos y/o métodos en común
Las subclases heredan parte de las características de la superclase.
Aunque las bases de datos orientadas a objetos no tuvieron mucho éxito,
suele ser útil para ayudar a definir partes del modelo de datos relacional de
un sistema.
Ejemplo de herencia:
Desarrollo de sistemas orientado a objetos con modelado en UML.

Asociaciones de Agregación:
Indican que un objeto de una clase puede estar conformado por uno o varios
objetos de otra clase.

La agregación requiere que:

 Un objeto de la clase A pueda estar formado por varios objetos de la
clase B.
 Un objeto de la clase B sólo existe en el contexto de un objeto de la
clase A (debe existir un objeto a:A).

Ejemplos de agregaciones:
Desarrollo de sistemas orientado a objetos con modelado en UML.