PROCESO UNIFICADO
PROCESO UNIFICADO
PROCESO UNIFICADO
INICIO
INICIO
La mayoría de los proyectos requieren una etapa inicial
breve en la que estudian los siguientes tipos de preguntas:
•¿Cuál es la visión y el análisis del negocio para este
proyecto?
•¿Es viable?
•¿Comprar o construir?
•Estimación aproximada del costo
•¿Deberíamos abordarlo o no seguir?
INICIO
El objetivo de la etapa de inicio no es definir todos los
requisitos, o generar una estimación creíble o plan de
proyecto.
Aún bajo riesgo de simplificar demasiado, la idea es hacer
la investigación justa para formar una opinión racional y
justificable del propósito global y la viabilidad del nuevo
sistema potencial.
La fase de inicio debería ser relativamente corta en la
mayoría de los proyectos, una duración de una a unas
pocas semanas.
INICIO
“Vislumbrar el alcance del producto, visión y
análisis del negocio”
El propósito es establecer una visión común inicial de los
objetivos del proyecto, determinar si es viable y decidir si
merece la pena llevar a cabo algunas investigaciones
serias en la fase de elaboración.
INICIO
CASOS DE USO
Resumen
• En este trabajo se ofrecen un ejemplo de la técnica de loscasos de uso, aplicándolo al caso de la gestión de unpequeño vídeo–club.
• En la introducción inicial se explica brevemente en queconsiste esta técnica y sus características más importantes. Acontinuación se han desarrollado los diferentes casos de usodel ejemplo junto a las plantillas para su especificación. Dadoque se trata de un ejemplo ficticio se han simplificado lasplantillas eliminando los campos relativos a versión, autores,fuentes, importancia, urgencia y estado de desarrollo.
• El ejemplo no es una especificación de requisitos completa,se incluye sólo a modo de ejemplo.
Definición de un Caso de Uso
Los casos de uso son una técnica para laespecificación de requisitos funcionalespropuesta inicialmente en [Jac93] y queactualmente forma parte de la propuesta deUML [Boo99].
Un caso de uso es la descripción de unasecuencia de interacciones entre el sistemay uno o más actores en la que se consideraal sistema como una caja negra y en la quelos actores obtienen resultados observables.
Definición de un Caso de Uso
Son un mecanismo para ayudar a mantenerlo simple yentendible para todo el personal involucrado.
Son historias del uso de un sistema para alcanzarobjetivos.
Formato Breve:
Procesar Venta. Un cliente llega a una caja con artículospara comprar. El cajero utiliza el sistema de punto de ventapara registrar cada artículo comprado. El sistema presentauna suma parcialy detalles de cada línea de venta. Elcliente introduce los datos del pago, que el sistema valida yregistra. El sistema actualiza el inventario. El cliente recibeun recibo del sistema y se va con los artículos.
Actores Principales de una CU
Los actores son personas u otros sistemas queinteractúan con el sistema cuyos requisitos se estándescribiendo.
Los casos de uso presentan ciertas ventajas sobrela descripción meramente textual de los requisitosfuncionales, ya que facilitan la licitación derequisitos y son fácilmente comprensibles por losclientes y usuarios.
Además, pueden servir de base a las pruebas delsistema y a la documentación para los usuarios.
Eficiencia
La idea base de los sistemas distribuidos esla de obtener sistemas mucho más rápidosque los ordenadores actuales. (Paralelismo)
Para lograr un sistema eficiente hay quedescartar la idea de ejecutar un programa enun único procesador de todo el sistema, ypensar en distribuir las tareas a losprocesadores libres más rápidos en cadamomento.
Representación Gráfica de un CU
Los casos de uso tienen una representación gráficaen los denominados diagramas de casos de uso[Boo99]. En estos diagramas, los actores serepresentan en forma de pequeños monigotes y loscasos de uso se representan por elipses contenidasdentro de un rectángulo que representa al sistema.
La participación de los actores en los casos de usose indica por una flecha entre el actor y el caso deuso que apunta en la dirección en la que fluye lainformación. Cada caso de uso puede estar definidopor: texto que lo describe, secuencia de pasosejecutados dentro del caso de uso, condiciones pre-post para que el caso de uso comience o termine.
Objetivos del Sistema
En este apartado vamos a definir una lista
con los diferentes objetivos que se esperan
alcanzar cuando el sistema software a
desarrollar esté en explotación. Serán
especificados mediante una plantilla para
objetivos.
Diagramas
OBJ–01 Gestionar las cintas y películas
Descripción El sistema deberá gestionar las cintas y
películas disponibles en el vídeo club:
adquisiciones, retiradas, disponibilidad, etc.
Estabilidad Alta
Comentarios Ninguno
OBJ–02 Gestionar los socios
Descripción El sistema deberá gestionar las socios del
vídeo–club: altas, bajas, modificaciones de
datos, sanciones, personas autorizadas,
cuentas, etc.
Estabilidad Alta
Comentarios Ninguno
Diagramas
OBJ–03 Gestionar los alquileres
Descripción El sistema deberá gestionar los alquileres de
cintas: entregas, devoluciones, devoluciones
tardías, reclamaciones, disponibilidad, etc.
Estabilidad alta
Comentarios ninguno
Requisitos de almacenamiento de
información
Esta sección contiene la lista de
requisitos de almacenamiento de
información que se han identificado,
utilizando para especificarlos la plantilla
para requisitos de almacenamiento de
información. Especificaremos toda la
información que debemos almacenar
en nuestro sistema.
Requirimientos
RI–01 Información sobre películas
Objetivos asociados OBJ–01 Gestionar las películas y cintas
Requisitos asociados RF–04 Alta de película
RF–05 Alta de cinta de vídeo
RF–08 Baja de cinta de vídeo
RF–10 Consulta de película
RF–13 Consulta de películas alquiladas un día determinado
Descripción El sistema deberá almacenar la información correspondiente
a las películas del vídeo–club. En concreto:
Datos específicos Título de la película
Cintas de la película alquiladas en cada momento
Cintas de la película disponibles para ser alquiladas en cada momento
Tipo de la película: infantil, acción, ciencia-ficción o adultos
Duración de la película, en horas y minutos
Actores principales de la película
Director de la película
Productora de la película
Año de producción de la película
Intervalo temporal pasado y presente
Estabilidad alta
Comentarios ninguno
RequerimientosRI–02 Información sobre socios
Objetivos asociados OBJ–02 Gestionar los socios
Requisitos asociados RF–01 Alta de socio
RF–02 Baja de socio
RF–03 Modificación de datos de un socio
RF–11 Consulta de un socio
RF–12 Consulta de socios con pagos pendientes
RF–12 Consulta de los socios más rentables
RF–15 Identificación de socio
Descripción El sistema deberá almacenar la información correspondiente a los socios del
vídeo–club. En concreto:
Datos específicos Número de socio, que deberá ser único para cada socio
Número del documento nacional de identidad
Nombre y apellidos
Fecha de nacimiento
Sexo
Fecha de alta como socio
Dirección
Teléfonos
Películas alquiladas en un momento dado
Intervalo temporal sólo presente
Estabilidad alta
Comentarios ninguno
RequerimientosRI–03 Información sobre cuentas de socios
Objetivos asociados OBJ–02 Gestionar los socios
Requisitos asociados RF–01 Alta de socio
RF–02 Baja de socio
RF–05 Alquiler de cinta de vídeo
RF–08 Devolución de cintas de vídeo
RF–09 Ingreso a cuenta
RF–11 Consulta de un socio
RF–12 Consulta de socios con pagos pendientes
Descripción El sistema deberá almacenar la información correspondiente a las cuentas de
los socios del vídeo–club. En concreto:
Datos específicos Saldo de la cuenta en cada momento
Ingresos realizados en la cuenta, indicando fecha y cantidad
Cargos realizados en la cuenta, indicando fecha, motivo y cantidad
Pagos pendientes, indicando motivo que podrá ser alquiler no pagado o
multa; en el caso de alquiler no pagado se debe indicar también la
película alquilada y la fecha del alquiler
Intervalo temporal sólo presente
Estabilidad alta
Comentarios Un socio puede hacer ingresos a cuenta, por ejemplo para enviar a sus hijos
por películas sin que éstos tengan que llevar dinero
Diagramas de casos de uso
En esta sección hemos incluido los
diagramas de casos de uso de nuestro
sistema, desarrollados con la herramienta
Rational Rose 98
Diagrama de casos de uso del
subsistema Gestión de socios
Diagrama de casos de uso del
subsistema Gestión de películas
Diagrama de casos de uso del
subsistema Gestión de alquileres
Definición de actores
Este apartado contiene los diferentes actores que se
han identificado, especificados mediante la plantilla
para actores de casos de uso.
ACT–01 Socio
Descripción Este actor representa a los socios del vídeo–club
Comentarios ninguno
Definición de actores
ACT–02 Empleado del vídeo–club
Descripción Este actor representa a los empleados del
vídeo–club
Comentarios ninguno
ELABORACIÓN
• La elaboración es la serie inicial de iteraciones durante
las que el equipo lleva a cabo un estudio serio,
implementa (programas y pruebas) el núcleo central de
la arquitectura, aclara la mayoría de los requisitos y
aborda las cuestiones de alto riesgo.
• En el PU el “riesgo” incluye valor del negocio.
• La elaboración consta entre dos y cuatro iteracciones;
se recomienda que cada iteracción dure de entre dos y
seis semanas.
ELABORACIÓN
• Se fija la duración de la elaboración entendiendo que
se fija la fecha de finalización; si es probable que el
equipo no cumpla con la fecha, algunos requisitos se
colocan en la lista de tareas futuras.
• La iteración debe terminar a tiempo, con una versión
estable y que se pueda probar.
• En esta fase no se crean prototipos desechables; sino
que el código y el diseño son porciones del sistema
final con calidad de producción.
ELABORACIÓN (recomendaciones)
• Llevar a cabo iteraciones breves, de duración fija,
dirigidas por el riesgo.
• Comenzar a programar pronto.
• Diseñar, implementar y probar de manera adaptable,
las partes básicas y arriesgadas de la arquitectura.
• Probar desde el principio, a menudo y de manera
realista.
• Adaptar en base a la retroalimentación procendente de
las pruebas, usuarios y desarrolladores.
• Escribir la mayoría de los casos de uso y otros
requisitos a detalle, a través de una serie de talleres,
uno por cada iteración de la elaboración
PLANIFICACIÓN DE LA ELABORACIÓN
• Organice los requisitos y las iteraciones según el
riesgo, grado de cobertura y naturaleza crítica.
• RIESGO: comprende tanto la complejidad técnica
como otros factores, como incertidumbre del esfuerzo o
facilidad de uso.
• COBERTURA: implica que todas las partes
importantes del sistema se tratan, al menos en las
primeras iteraciones – quizás una implementación
“amplia y superficial” a través de muchos
componentes- .
• NATURALEZA CRÍTICA: se refiere a las funciones de
alto valor para el negocio.
PLANIFICACIÓN DE LA ELABORACIÓN
• La clasificación se realiza antes de la iteración 1, pero
después de la iteración 1 otra vez antes de la iteración
2, etc, cuando nuevos requisitos y nuevas
interpretaciones influyan en el orden.
Rango Requisito
(Caso de uso o característica)
Comentario
Alto Procesar venta
Registro(logging)
Puntuación alta en todos
los criterios de clasificación.
Extendido. Difícil de añadir
más tarde
Medio Mantener usuarios
….
Afecta subdominio de
seguridad
…
Bajo …. …
PLANIFICACIÓN DE LA ELABORACIÓN
ROLES EN RUP
Analistas:
• Analista de procesos de negocio.
• Diseñador del negocio.
• Analista de sistema.
• Especificador de requisitos.
Desarrolladores:
• Arquitecto de software.
• Diseñador
• Diseñador de interfaz de usuario
• Diseñador de cápsulas.
• Diseñador de base de datos.
• Implementador.
• Integrador.
Gestores:
• Jefe de proyecto
• Jefe de control de cambios.
• Jefe de configuración.
• Jefe de pruebas
• Jefe de despliegue
• Ingeniero de procesos
• Revisor de gestión del proyecto
• Gestor de pruebas.
Apoyo:
• Documentador técnico
• Administrador de sistema
• Especialista en herramientas
• Desarrollador de cursos
• Artista gráfico
Especialista en pruebas:
• Especialista en Pruebas (tester)
• Analista de pruebas
• Diseñador de pruebas
Otros roles:
• Stakeholders.
• Revisor
• Coordinación de revisiones
• Revsor técnico
• Cualquier rol
MODELO DEL DOMINIO
MODELO DEL DOMINIO
• Un modelo del dominio muestra clases conceptuales
significativas del dominio del problema; es el artefacto
más importante que se crea durante el análisis
orientado a objetos.
• Un modelo del dominio es una representación de
clases conceptuales no de componentes software. No
se trata de un conjunto de diagramas que describen
clases software, u objetos software con
responsabilidades.
• El UP define al modelo del dominio como uno de los
artefactos que pueden crearse en la Disciplina del
Modelado del negocio.
MODELO DEL DOMINIO
Utilizando notación UML el modelo del dominio se
representa con un conjunto de diagrama de clases en los
que no se define ninguna operación. Puede mostrar:
• Objetos del dominio o clases conceptuales.
• Asociaciones entre clases conceptuales.
• Atributos de las clases conceptuales.
MODELO DEL DOMINIO
El modelo del dominio podría considerarse un diccionario visual de las
abstracciones relevantes, vocabulario del dominio e información del dominio
MODELO DEL DOMINIO
Es una representación de cosas del mundo real del
dominio de interés, no de componentes de software
(clases o objetos).
MODELO DEL DOMINIO
Los siguientes elementos no son adecuados para el
modelo del dominio:
• Artefactos software, como una ventana o una base
de datos, a menos que se esté modelando sea de
conceptos software, como un modelo de interfaces
de usuario gráficas.
• Responsabilidades o métodos.
Clases conceptuales
Una clase conceptual es una idea, cosa u objeto. Más
formalmente una clase conceptual podría considerarse en
términos de su símbolo, intensión y extensión:
• Símbolo: palabras o imágenes que representan una
clase conceptual.
• Intensión: la definición de la clase conceptual
• Extensión: el conjunto de ejemplos a los que se
aplica la clase conceptual.
Clases conceptuales
Clases conceptuales
Una diferencia esencial entre el análisis orientado a
objetos y el estructurado es: la división por clases
conceptuales (objetos) en lugar de la división por
funciones.
• La principal tarea del análisis es identificar
diferentes conceptos en el dominio del problema y
documentar el resultado en un modelo del dominio.
Identificación de Clases conceptuales
El objetivo es crear un modelo del dominio de clases
conceptuales interesantes significativas del dominio de
interés. En este caso eso significa conceptos relacionados
con el caso de uso en estudio.
No piense que un modelo de dominio es mejor si contiene
pocas clases conceptuales suele ser verdad justamente lo
contrario.
Es valido tener clase conceptuales sin atributos, o clases
conceptuales con un rol puramente de comportamiento en
el dominio en lugar de un rol de información.
Identificación de Clases conceptuales
Técnicas para identificar clases conceptuales:
1. Utilización de una lista de categorías de clases
conceptuales.
2. Identificación de frases nominales.
Identificación de Clases conceptualesCategoría o clase conceptual Ejemplo
Objetos tangibles o físicos Registro
Avión
Especificaciones, diseños o
descripciones de las cosas
EspecificaciónDelProducto
DescripcionDelVuelo
Lugares Tienda
Transacciones Venta, pago
Líneas de transacción LineaDeVenta
Roles de la gente Cajero
Piloto
Contenedores de otras cosas Tienda, lata
Avión
Cosas en un contenedor Articulo
Pasajero
Otros sistemas informáticos o
electromecánicos externos al sistema
SistemaAutorizacionPagoCredito
ControlTraficoAreo
Identificación de Clases conceptualesCategoría o clase conceptual Ejemplo
Conceptos abstractos Ansia
Acrofobia
organizaciones DepartamentoDeVentas
CompañiaAerea
Hechos Venta, pago, reunion
Vuelo,colision,aterrizaje
Procesos (normalmente no se presentan
como conceptos, pero podría ocurrir)
VentaDeProducto
ReservaUnAsiento
Reglas y políticas PoliticaDeReintegro
PoliticaDeCancelación
Catálogos CatalogoProductos
CatalogoPiezas
Registros de finanzas, trabajo, contratos,
cuestiones legales
Recibo, libroMayor, contratoEmpleo
RegistroMantenimiento
Instrumentos y servicios financieros LineaCredito
Stock
Manuales, documentos, artículos de
referencia, libros
ListaDeCambiosDe PrecioDiario
ManualReparaciones
Identificación de Clases conceptuales
Identificación de Clases conceptuales
A partir del análisis de la Lista de categorías de clases
conceptuales y las frases nominales, se genera una lista
de clases candidatea del dominio. La lista está restringida
a los requisitos y simplificaciones que se están estudiando.
No existe una lista correcta, es una colección algo
arbitraria de abstracciones y vocabulario del dominio que
el modelador considere relevantes.
Registro
Articulo
Tienda
Venta
Pago
CatalogoDePagos
EspecificacionDelProducto
LineaDeVenta
Cajero
Cliente
Encargado
Guía para el modelado del dominio
Aplique los siguientes pasos para crear un modelo de
dominio.
1. Liste las clases conceptuales candidatas (utilizando las
técnicas).
2. Represéntelos en un modelo de dominio
3. Añada las asociaciones necesarias para registrar las
relaciones que hay que mantener en memoria.
4. Añada los atributos necesarios para satisfacer los
requisitos de información.
Asociaciones
Una asociación es una relación entre tipos que indica una
conexión significativa e interesante.
En UML, las asociaciones se definen como “la relación
semántica entre dos o más clasificadores que implica
conexiones entre sus instancias.
Las asociaciones que valen la pena registrar,
normalmente, implican conocimiento de una relación que
es necesaria conservar durante un periodo de tiempo.
Una asociación se representa en UML con una línea entre
clases con un nombre de asociación.
Asociaciones
Son bidireccionales.
Los extremos de una asociación pueden contener una
expresión de multiplicidad que indica la relación numérica
entre las instancias de las clases.
Una flecha de dirección de lectura opcional indica la
dirección de la lectura del nombre de la asociación; no
indica la dirección de la visibilidad o navegación.
Asociaciones
AsociacionesMultiplicidad.
Localización de las asociaciones
Categoría Ejemplo
A es una parte de B Cajón – registro
Ala - avión
A es una parte lógica de B LineadeVenta – Venta
EtapaVuelo - RutaVuelo
A está contenido físicamente en B Registro-Tienda, Artículo-estantería
A esta contenido lógicamente en B DescripcionArticulo-catalogo
Vuelo-planificaciónVuelo
A es una descripción de B DescripcionArticulo-articulo
A es una línea de transacción o
informe de B
LineaVenta-venta
TrabajoMantenimiento- registroMantenimiento
A se conoce/informa/captura en B Venta – registro
Reserva -listaPasajeros
A es miembro de B Cajero – tienda
Piloto - compañiaArea
Comience la inclusión de las asociaciones utilizando la siguiente tabla
Asociaciones de prioridad alta
Categorías que son invariablemente útiles incluirlas en el
modelo del dominio.
A es parte lógica o física de B
A está contenida lógica o físicamente en B
A se registra en B
Tarea:
Investigar el manejo de los atributos en el modelo del dominio
Asociaciones
Asociaciones
DIAGRAMAS DE SECUENCIA
Diagramas de secuencia
El diagrama de secuencia de un sistema muestra
gráficamente los eventos que fluyen de los actores al
sistema.
Los diagramas de secuencia de un sistema se preparan
durante la fase de análisis de un ciclo de desarrollo. Su
creación depende de la formulación previa de los casos de
uso.
Diagramas de secuencia
Los diagramas de secuencia es un artefacto creado de
manera rápida y fácil, que muestra los eventos de entrada
y salida relacionados con el sistema que se está
ejecutando.
UML incluye la notación de los diagramas de secuencia
para representar los eventos que parten de los actpres
externos hacia el sistema.
Antes de iniciar con el diseño lógico de cómo funcionará la
aplicación de software, es conveniente estudiar y definir su
comportamiento como una “caja negra” (que hace, sin
saber como lo hace).
Diagramas de secuencia
Es deseable aislar e ilustrar las operaciones que un actor
externo solicita al sistema, porque constituyen una parte
importante de la comprensión del comportamiento del
sistema.
Un diagrama de secuencia es un dibujo que muestra, para
un escenario específico de un caso de uso, los eventos
que generan los actores externos, el orden y los eventos
entre los sistemas.
Diagramas de secuencia
Diagramas de secuencia
EventosEl evento de un sistema es un hecho externo de entrada
que un actor produce en un sistema. El evento da origen a
una operación de respuesta. La operación de un sistema
es una acción que éste ejecuta en respuesta a un evento
del sistema.
Elaboración de diagramas de secuencia:
1. Trace una línea que represente el sistema como una
caja negra.
2. Identifique los actores que operan directamente sobre
el sistema. Trace una línea para cada uno de ellos.
3. A partir del curso normal de los eventos del caso de
uso identifique los eventos del sistema que son
generados por los actores. Muéstrelos en el diagrama.
EventosEl evento de un sistema es un hecho externo de entrada
que un actor produce en un sistema. El evento da origen a
una operación de respuesta. La operación de un sistema
es una acción que éste ejecuta en respuesta a un evento
del sistema.
Elaboración de diagramas de secuencia:
1. Trace una línea que represente el sistema como una
caja negra.
2. Identifique los actores que operan directamente sobre
el sistema. Trace una línea para cada uno de ellos.
3. A partir del curso normal de los eventos del caso de
uso identifique los eventos del sistema que son
generados por los actores. Muéstrelos en el diagrama.
4. A la izq. del diagrama puede incluir el texto del caso.
Diagramas de secuencia
DE LOS REQUISITOS AL DISEÑO
Hasta el momento, el caso ha hecho hincapié en el estudio
de los requisitos, conceptos, y operaciones relacionadas
con un sistema. Se investigaron un 10% de los requisitos
en la fase de inicio, y se comenzó un estudio un poco más
profundo en la primera iteración de la fase de elaboración.
En el desarrollo iterativo, en cada iteración tendrá
lugar una transición desde un enfoque centrado en los
requisitos a un enfoque centrado en el diseño y la
implementación
DiseñoDurante el diseño de los objetos, se desarrolla una
solución lógica basada en el paradigma orientado a
objetos.
Lo esencial en esta solución es la creación de diagramas
de interacción, que representa el modo en que los objetos
colaboran para satisfacer los requisitos.
En paralelo a la elaboración de los diagramas de
interacción se pueden representar los diagramas de
clases. Éstos resumen la definición de las clases de
software (e interfaces) que se van implementar en el
software.
DIAGRAMAS DE INTERACCIÓN
Diagramas de interacciónEl término diagrama de interacción es una generalización
de dos tipos de diagramas de UML más especializados;
ambos pueden utilizarse para representar de foema similar
la interacción entre los mensajes:
•Diagramas de colaboración.
•Diagramas de secuencia.
Los diagramas de colaboración ilustran interacciones
entre los objetos se pueden colocar en cualquier lugar del
diagrama.
Los diagramas de secuencia ilustran las interacciones en
un tipo de formato con el aspecto de una cerca (valla), en
el que cada objeto nuevo se añade a la derecha.
DIAGRAMAS DE INTERACCIÓN
Diferencias entre los diagramas
Tipo Puntos Fuertes Puntos Débiles
secuencia Muestra claramente la
secuencia u ordenación en
el tiempo de los mensajes.
Notación simple
Fuerza a extender por la
derecha cuando se añaden
objetos; consume espacio
horizontal
colaboración Economiza espacio,
flexibilidad al añadir nuevos
objetos en dos dimensiones.
Es mejor para ilustrar
bifurcaciones complejas y
comportamiento concurrente
Difícil ve la secuencia de
mensajes.
Notación más compleja
DIAGRAMAS DE INTERACCIÓN
Diagramas de interacciónSe debe dedicar un tiempo y esfuerzo no trivial a la
creación de diagramas de interacción, como reflejo que se
ha estudiado cuidadosamente los detalles del diseño de
los objetos.
Cree los diagramas de interacción por parejas, no solo. El
diseño colaborando con otro será mejor, y los compañeros
aprenderán rápidamente uno de los otros.
Principalmente durante esta etapa se requiere la aplicación
de las técnicas del diseño, en términos de patrones, estilos
y principios.
Notación de los diagramas de interacción
Para cualquier elemento UML (clase, actor,.. ) una
instancia utiliza el mismo símbolo gráfico que el tipo, pero
con una cadena de texto que lo designa subrayada.
Venta :Venta v1:Venta
DIAGRAMAS DE COLABORACIÓN
Diagramas de colaboración
Enlaces.
Un enlace es un camino de conexión entre dos objetos;
indica que es posible alguna forma de navegación o
visibilidad entre los objetos. De manera formal un enlace
es una instancia de una asociación.
Mensajes
Cada mensaje entre objetos se representa con una
expresión de mensaje y una pequeña flecha que indica la
dirección del mensaje. Pueden fluir muchos mensajes a
través de un enlace. Se añade un número de secuencia
para mostrar el orden secuencial de los mensajes en el
hilo del control actual
DIAGRAMAS DE SECUENCIA
Diagramas de secuencia
Enlaces.
A diferencia de los diagramas de colaboración, los
diagramas de secuencia no muestran enlaces.
Mensajes
Cada mensaje entre objetos se representa con una
expresión de mensaje sobre una línea con punta de flecha
entre los objetos. El orden del tiempo se organiza de arriba
hacia abajo.
Diagramas de secuencia
Focos de control y cajas de activación
En los diagramas de secuencia se pueden mostrar los
focos de control utilizando una caja de activación, la cual
es opcional.
Representación de retornos
Se pueden mostrar el retorno de un mensaje mediante una
línea punteada con una flecha abierta, al final de una caja
de activación. Algunos anotan la línea de retorno para
describir lo que está devolviendo a partir del mensaje.
Diagramas de secuencia
Mensajes self (this)
Se puede representar un mensaje que se envía de un
objeto a él mismo utilizando una caja de activación
anidada.
Diagramas de secuencia
Línea de vida del objeto y destrucción de objetos
Las líneas verticales debajo de los objetos indican su
duración de vida en el diagrama. En algunas
circunstancias es deseable mostrar la destrucción
explícita de un objeto.
Diseño y patrones
El diseño es una etapa crítica; es la parte esencial de lo
que entendemos por desarrollar un sistema orientado a
objetos, no el dibujo de diagramas del modelo de dominio,
diagramas de paquetes, etc.
Los patrones GRASP (General Responsibility Assignment
Sotware Patterns – patrones generales de software para
asignar responsabilidades- ) son un apoyo para la
enseñanza que ayuda a entender el diseño de objetos
esencial, y aplica el razonamiento para el diseño de una
forma sistemática, racional y explicable.
Responsabilidad
UML define una responsabilidad como un contrato u
obligación de un clasificador. Las responsabilidades están
relacionadas con las obligaciones de un objeto en cuanto a
su comportamiento.
Las responsabilidades son de dos tipos Conocer y Hacer.
Responsabilidades hacer:
• Hacer algo él mismo, como crear un objeto o hacer
un cálculo.
• Iniciar una acción en otros objetos.
• Controlar y coordinar actividades en otros objetos.
Responsabilidad
Responsabilidades conocer:
• Conocer los datos privados encapsulados.
• Conocer objetos relacionados.
• Conocer las cosas que puede derivar o calcular.
Las responsabilidades se asignan a las clases durante el
diseño de objetos.
1. Una venta es responsable de la creación de una
LineaDeVenta.
2. Una Venta es responsable de conocer su total.
Una responsabilidad no es lo mismo que un método, pero
los métodos se implementan para llevar a cabo
responsabilidades.
Patrones
Repertorio tanto de principios generales como de
soluciones basadas en aplicar ciertos estilos que les guían
en la creación de software.
Estos si se codifican con un formato estructurado que
describa el problema y la solución y se les da un nombre,
podrían llamarse patrones.
Un patrón es una descripción de un problema y la solución,
a la que se les da un nombre, y que puede aplicar a
nuevos contextos, idealmente proporciona consejos sobre
el modo de aplicarlo en varias circunstancias y considera
los puntos fuertes y compromisos.
Patrones GRASP
La asignación habilidosa de responsabilidades es
extremadamente importante en el diseño de objetos.
La decisión acerca de la asignación de responsabilidades
a menudo, tiene lugar durante la creación de los
diagramas de interacción y con seguridad durante la
programación.
Los patrones GRASP describen los principios
fundamentales del diseño de objetos y asignación de
responsabilidades, expresados como patrones.
Patrones GRASP
Cinco patrones GRASP:
•Experto en Información.
•Creador.
•Alta Cohesión.
•Bajo Acoplamiento.
•Controlador.
Experto en Información
Solución: Asignar una responsabilidad al experto en información – la
clase que tiene la información necesaria para realizar la
responsabilidad –
Problema: ¿Cuál es el principio general para asignar
responsabilidades a los objetos?
Ejemplo: En la aplicación del PDV , algunas clases necesitan conocer
el total de una venta.
¿Quién debería ser responsable de conocer el total de una venta?
Mire en el modelo del dominio o en el modelo de diseño para analizar
las clases que tienen la información necesaria.
Experto en Información
Experto en Información
Experto en Información
Contraindicaciones: Algunas veces la solución no es deseable, debido
a problemas de acoplamiento y cohesión. ¿Quién es el
responsable de almacenar una venta en una base de
datos?
Beneficios: Se mantiene el encapsulamiento de la información, puesto
que los objetos utilizan su propia información para llevar a
cabo las tareas. Da lugar a bajo Acoplamiento.
Patrones relacionados: Bajo acoplamiento y alta cohesión.
Creador
Solución: Asignar a la clase B la responsabilidad de crear una
instancia de la clase A si se cumple uno o más de los sig.
Casos:
1. B agrega objetos de A
2. B contiene objetos de A.
3. B registra instancias de objetos de A,
4. B utiliza más estrechamente objetos de A
5. B tiene los datos de inicialización que se pasarán a un
objeto de A cuando sea creado.
Problema: ¿Quién debería ser responsable de la creación de una
nueva instancia de alguna clase?
Ejemplo: En la aplicación del PDV , quién debería ser responsable de
la creación de LIneaDeVenta.
Creador
Creador
Creador
Contraindicaciones: A menudo, la creación requiere una complejidad
significativa, como utilizar instancias recicladas por motivos
de rendimiento, crear condicionalmente una instancia de a
partir de una familia de clases similares basado en el valor
de una propiedad externa. Preferible utilizar una Factoría
Beneficios: Se soporta bajo acoplamiento, lo que implica menos
dependencias de mantenimiento y mayores oportunidades
para reutilizar.
Patrones relacionados: Bajo acoplamiento y factoría, todo-parte.
Bajo Acoplamiento
Solución: Asignar una responsabilidad de manera que el acoplamientto
permanezca bajo.
El acoplamiento es una medida de la fuerza con que un
elemento está conectado a, tiene conocimiento de, confía
en , otros elementos. Un elemento con bajo acoplamiento
no depende demasiado de otros elementos.
Problema: ¿Cómo soportar bajas dependencias, bajo impacto del
cambio e incremento de la reutilización?
Ejemplo: Asuma que tenemos la necesidad de crear una instancia de
Pago y asociarla con la venta. ¿Qué clase debería ser
responsable de esto?
Bajo Acoplamiento
Bajo Acoplamiento
Bajo Acoplamiento
Contraindicaciones: No suele ser un problema el acoplamiento alto
entre objetos estables y elementos generales. Por ejemplo
una aplicación java J2EE puede acoplarse con seguridad
con librerías de java porque son estables y extendidas.
Beneficios: No afectan los cambios en otros componentes.
Fácil de entender de manera aislada
Conveniente de utilizar.
Patrones relacionados: Variaciones protegidas.
Bajo Acoplamiento
En los lenguajes orientados a objetos como C++, java, y C#, algunas
de las formas comunes de acoplamiento entre el TipoX y
elTipoY son:
1. El TipoX tiene un atributo (miembro de datos, o variable de
instancia) que hace referencia a una instancia de TipoY, o
al propio TipoY.
2. Un objeto de TipoX invoca los servicios de un objeto de
TipoY
3. El TipoX tiene un método que referencia a una instancia de
TipoY, o al propio TipoY, de algún modo. Esto,
generalmente, comprende un parámetro o variable local de
TipoY, o que el objeto de retorno de un mensaje sea una
instancia de TipoY.
4. El TipoX es una subclase, directa o indirecta del TipoY.
5. El TipoY es una interfaz y el TipoX implementa esa
interfaz.
Alta Cohesión
Solución: Asignar una responsabilidad de manera que la cohesión
permanezca alta.
La Cohesión es una medida de la fuerza con la que se
relacionan los objetos y del grado de focalización de las
responsabilidades de un elemento. Un elemento con
responsabilidades altamente relacionadas y que no hace
una gran cantidad de trabajo, tiene alta cohesión.
Problema: ¿Cómo mantener la complejidad manejable?
Ejemplo: : Asuma que tenemos la necesidad de crear una instancia de
Pago y asociarla con la venta. ¿Qué clase debería ser
responsable de esto?
Alta Cohesión
Contraindicaciones: Existen pocos casos en los que esté justificada la
aceptación de baja cohesión.
Un caso es la agrupación de responsabilidades o código en una clase
o componentes para simplificar el mantenimiento por una
persona.
Beneficios: Se incrementa la claridad y facilita la comprensión del
diseño.
Se simplifica el mantenimiento y las mejoras.
Se soporta a menudo bajo acoplamiento
El grano fino de funcionalidad altamente relacionada
incrementa la reutilización porque una clase cohesiva se
puede utilizar para un propósito muy específico.
Patrones relacionados: Variaciones protegidas.
Controlador
Solución: Asignar la responsabilidad de recibir o manejar un mensaje
de evento del sistema a una clase que representa una de
las siguientes opciones:
• Representa el sistema global, dispositivo o subsistema
(controlador de fachada).
• Representa un escenario de caso de uso en el que tiene
lugar el evento del sistema a menudo denominado
<NombreCasoUso>Manejador,
<NombreCasoUso>Coordinador, o
<NombreCasoUso>Sesion.
• Utilice la misma clase controlador para todos los eventos
del sistema en el escenario del caso de uso.
• Informalmente, una sesión es una instancia de una
conversación con un actor.
Problema: ¿Quién es el responsable de gestionar un evento de
entrada al sistema?
Controlador
Ejemplo: En la aplicación NuevaEra, hay varias operaciones del
sistema, que muestran al propio sistema como una clase o
componente.
¿Quién debería ser el controlador de los eventos del sistema como
introducirArticulo y finalizarVenta?
Beneficios: Aumenta el potencial para reutilizar y las interfaces
conectables
Razonamiento sobre el estado de los casos de uso.