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.
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.
Desarrollo de sistemas orientado a objetos con modelado en UML.
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.
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?)
Desarrollo de sistemas orientado a objetos con modelado en UML.

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:

UML-Refinamientos (Casos uso, Modelo conceptual, Glosario de
términos.)
Documentos:

UML-Diagramas de Secuencia

UML-Contratos de las Operaciones

UML-Diagramas de Colaboración

UML-Diagrama de Clases de Diseño

Modelo de Datos
Desarrollo de sistemas orientado a objetos con modelado en UML.

Informe del Ciclo i.

Especificación de Estándares.
Otros:
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.
Desarrollo de sistemas orientado a objetos con modelado en UML.
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.
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?
Desarrollo de sistemas orientado a objetos con modelado en UML.
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.
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.
Desarrollo de sistemas orientado a objetos con modelado en UML.
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:
Encapsula una interacción usuario-sistema.
Su nombre debe estar compuesto por: <Infinitivo verbal>+<Complemento>
Desarrollo de sistemas orientado a objetos con modelado en UML.
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.
Desarrollo de sistemas orientado a objetos con modelado en UML.
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.
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.
Desarrollo de sistemas orientado a objetos con modelado en UML.
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?
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.
Desarrollo de sistemas orientado a objetos con modelado en UML.
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ía
Comentarios
Comprar
Caso de
Descripción del proceso de un cliente que compra
Productos
uso
productos en una tienda
Producto
Concepto
Un producto para venderse en una Tienda
Venta.total :
Atributo
El gran total de la Venta
Concepto
Un pago en efectivo
Cantidad
Pago
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.
Desarrollo de sistemas orientado a objetos con modelado en UML.
–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.
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
Desarrollo de sistemas orientado a objetos con modelado en UML.
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
Curso Típico de Eventos:
Acción del Actor
Respuesta del Sistema
1. Este caso de uso empieza cuando un
2. Pide la clave de identificación.
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 recibo.
tarjeta.
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.
Desarrollo de sistemas orientado a objetos con modelado en UML.
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:
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.
Desarrollo de sistemas orientado a objetos con modelado en UML.
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.
¿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:
Desarrollo de sistemas orientado a objetos con modelado en UML.

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)
Desarrollo de sistemas orientado a objetos con modelado en UML.
Diagramas de Colaboración.
Diagramas de Interacción:
Se realizan durante el diseño de cada ciclo de desarrollo.
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:
Desarrollo de sistemas orientado a objetos con modelado en UML.
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.
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.
Desarrollo de sistemas orientado a objetos con modelado en UML.
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.
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.
Desarrollo de sistemas orientado a objetos con modelado en UML.
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:
Asociaciones de Agregación:
Indican que un objeto de una clase puede estar conformado por uno o varios objetos
de otra clase.
Desarrollo de sistemas orientado a objetos con modelado en UML.
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: