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 ejecucin bsica del desarrollo de software,
representa la columna vertebral de una metodologa.
Hay dos modelos bsicos:
1. Secuencial.
2. Iterativo (por ciclos cortos de desarrollo).

Ciclos de vida SECUENCIALES

Proponen la ejecucin de etapas de manera secuencial, es decir, una etapa

inicia una vez que la anterior ha culminado por completo.
La construccin 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 implantacin).
1. Ciclos de vida Cascada.
Propone la realizacin de 4 etapas secuenciales:
- Especificacin y anlisis de requerimientos
- Diseo de la solucin
- Implementacin del cdigo fuente
- Pruebas e implantacin del producto
2. Ciclos de vida Cascada por propsitos.
Similar al modelo de cascada pero se entrega un prototipo al final de la
etapa de diseo (antes de empezar la implementacin del cdigo fuente).
El prototipo puede ser funcional (tener parte del cdigo implementado) o no
serlo.
El prototipo puede ser reutilizable (ser aprovechado para la versin final del
producto) o no serlo (en cuyo caso no necesariamente es desarrollado en la
misma herramienta en la que se implementar la versin final).

Ciclos de vida ITERATIVOS

Proponen dividir la construccin del software en ciclos o iteraciones, donde:
en cada iteracin se alcanza determinado nivel de desarrollo en cada
iteracin se abarca una parte de la funcionalidad total del sistema.
Al final de cada iteracin se realiza una presentacin parcial del producto al
cliente. Permite corregir errores durante la propia construccin 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 conexin a la BD, etc.). Normalmente, el primer ciclo es muy
pretencioso.

Desarrollo de sistemas orientado a objetos con modelado en UML.

2. Ciclo de vida incremental.
Propone dividir la funcionalidad del sistema en bloques que se irn
abarcando cada uno en un ciclo independiente.
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
conceptualizacin del problema global.

Metodologa de desarrollo basada en un ciclo de vida iterativo e incremental.

Esta compuesta por 3 fases:

1. Conceptualizacin y planeacion.
Objetivos:

Entender el problema a resolver por parte del equipo

desarrollador

Planear el proyecto informtico que dar solucin al

problema
Pretende establecer:

El entorno del problema

(Dnde est el problema?)

Las funcionalidades del sistema

(Qu quiere el usuario?)

El alcance del proyectos

(Hasta dnde abarcar el proyecto?)
Productos esperados:

Diagramas y Modelos:
UML-Diagrama General de Casos de Uso.
UML-Modelo Conceptual.
UML-Glosario de Trminos.

Documentos:
Especificacin de Requerimientos del Software (ERS).

2. Fase de Construccin.
Objetivos:

Realizar el diseo de la solucin al problema estudiado en la

fase 1.

Construir el producto de software (aplicacin informtica)

que dar solucin al problema planteado por el usuario
Se divide en ciclos
Cada ciclo contiene 3 etapas:

Modelaje
(Generacin de diagramas y modelos)

Implementacin
(Programacin del cdigo fuente)

Pruebas e integracin

Desarrollo de sistemas orientado a objetos con modelado en UML.

(Aplicacin de pruebas unitarias y de integracin)
Productos esperados:
Diagramas y modelos:

UML-Refinamientos (Casos uso, Modelo conceptual, Glosario

de trminos.)

UML-Diagramas de Secuencia

UML-Contratos de las Operaciones

UML-Diagramas de Colaboracin

UML-Diagrama de Clases de Diseo

Modelo de Datos
Documentos:

Informe del Ciclo i.

Otros:

Especificacin de Estndares.

3. Fase de Despliegue de la aplicacin.

Objetivos:

Certificar la calidad del software implementado.

Implantar el producto software en el entorno del
usuario/cliente.

Se deben aplicar:

Pruebas de Ejecucin.
(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 ejecutndose 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 notacin estndar para su CASE.
Tambin participaron empresas como Microsoft, IBM, Hewlett-Packard y
Oracle.
Es slo una notacin, no define un proceso de desarrollo especfico.
Consiste en una secuencia de modelos, diagramas y documentos que
ayudan tanto a la comprensin del problema como al diseo de la solucin.
Ha sido tomado en cuenta por algunos autores en sus metodologas (p.e.
Larman).

1. UML en la Fase de Conceptualizacin y planeacion:

1. Entender el problemas:
UML interviene en la creacin de:

Casos de uso: definir las necesidades del cliente.

Modelo conceptual: comprender el entorno del problema.

Glosario de trminos: comprender el entorno del problema.

2. Planear la ejecucin del proyecto.

2. UML en la Fase de Conceptualizacin y planeacion:

1. Disear la solucin:
- Anlisis:
UML interviene en la creacin de:

Casos de uso (Formato extendido).

Diagramas de secuencia.

Contratos de Operaciones.
- Diseo:
UML interviene en la creacin de:

Casos de uso (reales).

Diagramas de colaboracin.

Diagramas de clases.
2. Implementar el Software.

3. UML en la Fase de Despliegue:

1. Certificar el Software:
UML interviene en la creacin de:

Casos de uso: para pruebas finales.

2. Poner en marcha el software en el cliente.

Casos de Uso.

Desarrollo de sistemas orientado a objetos con modelado en UML.

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.
2. Una interaccin tpica entre un usuario y un sistema de cmputo.
3. Un caso de uso es una descripcin de un proceso de principio a fin.

Caractersticas de un caso de uso:

Capta alguna funcin visible para el usuario.

Puede ser pequeo o grande.
Logra un objetivo discreto para el usuario.

Cmo identificar los casos de uso?

Opcin 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.
Opcin 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 automtico.

Registrar las carreras que imparte una universidad.
Solicitar el envo de un pedido de productos.
Facturar una venta de productos.
Registrar una solicitud de ingreso.

Cundo y para qu usar casos de uso?

Al inicio del proyecto: Para comprender mejor la interaccin 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 diseo: Para detallar ms 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 ms importantes del sistema.
Se consideran indispensables urgentes.
Ejemplos:

Registrar Producto (en un sistema de inventario).

Facturar Compra (en un sistema de facturacin).

Registrar Calificacin (en un sistema acadmico).

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 facturacin).

Desarrollo de sistemas orientado a objetos con modelado en UML.

Modificar Calificacin (en un sistema acadmico).

Opcional:
Representan los procesos que pueden perfectamente no abordarse en el
proyecto.
Se consideran no indispensables y no urgentes.
Normalmente, se hacen si sobra tiempo
Ejemplos:

Registrar bodeguero (en un sistema de inventario).

Modificar tipo de cambio del dlar (en un sistema de facturacin).

Enviar calificaciones a los estudiantes por email (en un sistema

acadmico).

Diagramas de casos de uso.

Diseado por Ivar Jacobson en 1994.
Explica grficamente un conjunto de casos de uso de un sistema, los actores
y la relacin entre stos y los casos de uso.
Su objetivo es ofrecer un diagrama contextual que nos permita conocer
rpidamente los actores externos del sistema y las formas bsicas en que lo
utilizan.
Ejemplo de Diagramas de casos de uso:

Desarrollo de sistemas orientado a objetos con modelado en UML.

ELEMENTOS

Caso de Uso:
Encapsula una interaccin 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 estn representados por el papel que desempean en el caso:
Cliente, Cajero, Solicitante, Vendedor, Bodeguero, etc.
Se representan mediante una figura estilizada. A pesar de que los actores
estn representados por figuras humanas, no es necesario que los actores
sean seres humanos. Un actor puede ser tambin un sistema externo que
necesite cierta informacin 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 slo participar de l. En el segundo caso tiende a
ser confuso quin 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 especfico que solicite la accin 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 vnculo.

Relaciones (entre casos de uso)

Se representan como una lnea que une a los dos casos de uso relacionados,
con una flecha y una etiqueta entre corchetes (<< , >>).
Tipos de relacin 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 ms.
Usa: <<uses>> Se usa cuando se tiene una porcin de
comportamiento que es similar en ms de un caso de uso y se quiere
reutilizar.

Modelo Conceptual.

Desarrollo de sistemas orientado a objetos con modelado en UML.

El paso esencial de un anlisis o investigacin orientado a objetos es
descomponer el problema en conceptos u objetos individuales: las cosas
que sabemos.
Un modelo conceptual es una representacin de conceptos en un dominio
del problema.
Consiste en un modelo que describe y relaciona los conceptos que
intervienen en el entorno del problema.
El diseo 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 descripcin del dominio de un problema real,
no es una descripcin del diseo 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 mtodos (operaciones).

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

Smbolo: Palabras o imgenes que le representen.

Intensin: Definicin propia del concepto.

Extensin: Conjunto de ejemplos a que puede aplicarse.

Cuando se crea un modelo conceptual, por lo general la vista del smbolo y
de la intensin de un concepto es lo que ms interesa.

En el anlisis estructurado, la descomposicin se realiza mediante procesos

o funciones.
En el anlisis orientado a objetos, es posible realizar la descomposicin 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 ms

tarde, cuando se examinen atributos o asociaciones o durante el diseo.
Cuando se detecten, deben incorporarse al modelo conceptual.

Desarrollo de sistemas orientado a objetos con modelado en UML.

No excluya conceptos porque los requerimientos no digan que

requiera persistencia, o porque carezca de atributos, pues podra ser
parte importante del comportamiento.

El error ms frecuente cuando se crea un modelo conceptual es

representar algo como atributo, cuando debi haber sido un concepto.
Cmo construir un Modelo Conceptual?
1. Liste los conceptos idneos (utilizando la lista de categoras y las frases
nominales).
2. Dibjelos como cajas o rectngulos.
3. Incorpore las asociaciones necesarias para registrar las relaciones.
4. Agregue los atributos necesarios para cumplir con las necesidades de
informacin.
Asociaciones:
Una asociacin es una relacin entre dos conceptos que indica alguna
conexin significativa e interesante entre ellos.
Es conveniente incluir las siguientes asociaciones en un modelo conceptual:

Las asociaciones en que el conocimiento de la relacin ha de ser

preservado durante algn tiempo (asociaciones que deben
conocerse).

Las asociaciones provenientes de la Lista de Asociaciones Comunes.

Sin embargo es mucho ms importante identificar los conceptos que las
asociaciones. El tiempo consagrado a la creacin del modelo conceptual
debera destinarse a identificar los conceptos, no las asociaciones.
Asociaciones Mltiples:
Pueden existir mltiples asociaciones entre los mismos conceptos.
Atributos:
Un atributo es un valor lgico de un dato de un objeto.
Incluya aquellos atributos en que los requerimientos indican o conllevan la
necesidad de recordar informacin.
No se debe incluir como atributo de un concepto el identificador de un
concepto relacionado con l.

Glosario de trminos.
Es un documento simple en el que se describen los trminos utilizados.
Pretende mejorar la comunicacin 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:
Trmino
Comprar
Productos
Producto
Venta.total :
Cantidad
Pago

Categor
a
Caso de
uso
Concepto
Atributo

Comentarios

Concepto

Un pago en efectivo

Definicin en formato expandido

Descripcin del proceso de un cliente que

compra productos en una tienda
Un producto para venderse en una Tienda
El gran total de la Venta

Desarrollo de sistemas orientado a objetos con modelado en UML.

Un caso expandido de uso muestra ms detalles que uno de alto nivel.
Suelen ser tiles para alcanzar un conocimiento ms profundo de los
procesos y los requerimientos.
Su formato est compuesto por tres partes:
Superior.
Intermedia.
Inferior.
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.
Propsito: Intencin del caso de uso.
Resumen: Repeticin de la descripcin 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 conversin interactiva entre los actores y el
sistema.
Explica la secuencia ms comn de los eventos: la historia normal de las
actividades y la terminacin 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
relacin con el curso normal.
Siguen el formato <excepcin> <accin>.
Si son complejas, se pueden expandir y convertirlas en casos de uso
independientes.
Casos Esenciales de Uso:
Contienen poca tecnologa y pocos detalles de implementacin.
Las decisiones de diseo 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 diseo concreto actual, sujeto a las
tecnologas especficas de E/S.
A menudo ofrece presentaciones de la pantalla a utilizar en el sistema.
Suelen ser tiles cuando la plataforma de ejecucin del sistema tenga
caractersticas peculiares.
Ejemplo de caso expandido de Uso (Esencial)
Caso de Uso: Retirar Dinero del Cajero Automtico.
Actores: Cliente.
Propsito: Realizar un retiro de dinero de una cuenta.

Desarrollo de sistemas orientado a objetos con modelado en UML.

Visin General: Un cliente llega al cajero automtico, introduce la tarjeta, se
identifica y solicita realizar un retiro de dinero. El cajero le da el dinero
solicitado tras comprobar que la operacin puede realizarse. El cliente toma
el dinero y se va.
Tipo: Primario y Esencial
Referencias: Requerimiento # 7
Curso Tpico de Eventos:
Accin del Actor
1. Este caso de uso empieza cuando
un cliente introduce su tarjeta en el
cajero.
3. Introduce la clave.
5. Selecciona la operacin de Retiro
7. Introduce la cantidad requerida.
10. Recoge el dinero, el recibo y la
tarjeta.
Curso Alternativo:
Accin del actor
Lnea 4: La clave es incorrecta.
operacin.
Lnea 8: El saldo no es suficiente.
operacin.

Respuesta del Sistema

2. Pide la clave de identificacin.
4. Presenta las opciones disponibles.
6. Pide la cantidad a retirar.
8. Procesa la peticin y,
eventualmente, da el dinero
solicitado.
9. Devuelve la tarjeta y genera un
recibo.
Respuesta del sistema.
Se indica el error y se cancela la
Se indica el error y se cancela la

Diagramas de Secuencia.
Un diagrama de secuencia muestra grficamente los eventos que fluyen de
los actores al sistema.
Forma parte del proceso de anlisis.
Su creacin depende de la formulacin previa de los casos expandidos de
uso.
Pretende explicar lo que el sistema hace pero no cmo 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 lnea vertical.
Los eventos (mensajes) se representan mediante flechas; pueden incluir
parmetros y se ordenan segn su secuencia en el tiempo.
Se suele agregar una nota con el curso normal de eventos del caso de uso
expandido.

Desarrollo de sistemas orientado a objetos con modelado en UML.

Ejemplo:

El nombre de una operacin debe mostrar el propsito inmediato de sta.

Se recomienda que el nombre de los eventos empiece con un infinitivo.
Las operaciones deben expresarse a nivel de propsito y no de
implementacin o interfaz.

Contratos de las Operaciones

Se elaboran durante el anlisis de cada ciclo de desarrollo.
Para su preparacin 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 cmo cambia el
estado de ste cuando se invoca una de sus operaciones.
Un contrato describe lo que una operacin se propone lograr.
Se declara enfatizando lo que suceder y no cmo se conseguir.
Puede elaborarse un contrato tanto para una operacin del sistema (las del
diagrama de secuencias) o para un mtodo de una clase software.
Secciones de un Contrato:

Nombre:<nombre de la operacin y parmetros>.

Responsabilidades: Descripcin informal de las responsabilidades

debe cumplir la operacin.

Tipo:<sistema, clase software>.

Referencias Cruzadas: Requerimientos y/o Casos de Uso.

Notas: Notas de diseo, algoritmos e informacin afn.

Excepciones: Casos excepcionales.

Salidas: Salidas atpicas del sistema (por salidas no estndar).

Precondiciones: Suposiciones acerca del estado del sistema. antes de

ejecutar la operacin.

Desarrollo de sistemas orientado a objetos con modelado en UML.

Poscondiciones: El estado del sistema despus de la operacin.

Cmo preparar un contrato?

1. Identifique las operaciones del sistema a partir de los diagramas de
secuencia.
2. Elabore un contrato para cada operacin.
3. Comience redactando las Responsabilidades.
4. Complete luego la seccin de Poscondiciones, describiendo los cambios
de estado de los objetos del modelo conceptual.
5. Para describir las poscondiciones utilice las siguientes categoras:

Creacin y eliminacin de las instancias.

Modificacin de los atributos.

Asociaciones formadas y canceladas.

Poscondiciones: Estipulan cmo cambi el sistema tras la operacin.
No son acciones que deben efectuarse durante la operacin.
Son declaraciones sobre el estado del sistema que se aplican una vez
concluida la operacin (una vez que se haya disipado el humo).
UML no especfica cmo expresar las poscondiciones: el analista escoge el
formato.
Ejemplo:
Nombre: introducir Producto (CUP: nmero, cantidad: entero)
Responsabilidades: Registrar la venta de un producto y agregarla a la venta
total. Desplegar la descripcin 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 cdigos 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 (creacin de instancia).
Si se trata de una nueva venta, la nueva Venta fue asociada al Punto De
Venta (asociacin formada).
Se cre una instancia LneaDeDetalle (creacin de instancia).
Se asoci una instancia LneaDeDetalle a la Venta (asociacin formada).
Se asign cantidad a LineaDeDetalle.cantidad (modificacin de atributo)
Se asoci una instancia LineaDeDetalle a la instancia
EspecificacionDeProducto, basado esto en la correspondencia del
CUP(asociacin formada)

Diagramas de Colaboracin.
Diagramas de Interaccin:
Se realizan durante el diseo de cada ciclo de desarrollo.

Desarrollo de sistemas orientado a objetos con modelado en UML.

Son diagramas que explican grficamente cmo los objetos interactan a
travs 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 creacin de:

Modelo Conceptual: A partir de ste, el diseador podr definir las

clases software correspondiente a los conceptos.

Contratos de las Operaciones: A partir de ellos, el diseador identifica

las responsabilidades y las poscondiciones que han de llenar los
diagramas de interaccin.

Casos Reales de Uso: A partir de ellos, el diseador recaba

informacin sobre las tareas que realizan los diagramas de interaccin
Son muy importantes en la asignacin de responsabilidades y el diseo de
la colaboracin entre los objetos.
Los diagramas de interaccin constituyen uno de los artefactos ms
importantes que se generan en el anlisis y en el diseo orientado a
objetos.
Existen dos tipos:
1. Diagramas de Colaboracin: 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.

Cmo preparar un Diagrama de Colaboracin?

1. Elabore un diagrama por cada operacin del sistema durante el ciclo
actual de desarrollo.
2. Disee un sistema de objetos interactivos que realicen las tareas, usando
como punto de partida las responsabilidades y poscondiciones del contrato
de operacin y la descripcin de casos de uso.
Ejemplo:

Relacin entre artefactos:

Casos de Uso (eventos del sistema)
Diagrama de Secuencia.
Contratos (operaciones del sistema).
Diagrama de colaboracin (mensajes entre objetos internos del sistema).
Clases e Instancias: Nombre del tipo subrayado y precedido por dos puntos.

Vnculos: Lnea contina a travs de la cual pueden fluir mensajes.

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

sobre un vnculo. Se agrega un consecutivo que indica el orden de los
mensajes.

Desarrollo de sistemas orientado a objetos con modelado en UML.

Parmetros: Se anotan dentro de parntesis, despus del nombre del

mensaje. Es opcional incluir o no el tipo de parmetro en cuestin.

Retorno de valores: Puede incluirse un valor de retorno, ante ponindole al

mensaje un nombre de variable y un operador de asignacin (:=). 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 vnculo a s mismo, pues el mensaje fluye por el vnculo.

Iteraciones: Se indica posponiendo un asterisco (*) al nmero de secuencia.

Tambin es posible incluir una clusula de iteracin que indique los valores
de recurrencia.

Desarrollo de sistemas orientado a objetos con modelado en UML.

Condicionales: Se indican posponiendo al nmero de secuencia una clusula
condicional entre corchetes. El mensaje slo se enva si la clusula se enva
como verdadera.

Condicionales mutuamente excluyente: Se utilizan letras minsculas

(a,b,c,...) despus del nmero de secuencia para indicar la exclusividad
entre los posibles caminos.

Diagrama de Clases.

Una vez que se tienen los diagramas de interaccin, se procede a definir las
clases software que conforman el sistema.
Su elaboracin requiere previamente:

Diagramas de Interaccin: Para identificar las clases y los mtodos.

Modelo Conceptual: Para agregar detalles a la definicin de las

clases.
Cundo elaborarlo?
A pesar de que se supone que deben hacerse despus de los diagramas de
interaccin, en la prctica se realizan en forma paralela.
Representa el cierre del diseo de la aplicacin.
Por ejemplo, conforme se disea el diagrama de colaboracin, van
apareciendo los mtodos que estarn contenidos dentro de las clases.

Desarrollo de sistemas orientado a objetos con modelado en UML.

El diagrama de clases describe grficamente las especificaciones de las

clases de software en una aplicacin.
Normalmente contiene:

Clases.

Atributos.

Mtodos.

Asociaciones.

Navegabilidad.

Dependencias.
Asociaciones de Herencia:
Se dan cuando varias clases poseen atributos y/o mtodos en comn
Las subclases heredan parte de las caractersticas 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 Agregacin:
Indican que un objeto de una clase puede estar conformado por uno o varios
objetos de otra clase.

La agregacin requiere que:

Un objeto de la clase A pueda estar formado por varios objetos de la

clase B.

Un objeto de la clase B slo 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.