56195149 Metodologia RUP

5/12/2018 56195149 Metodologia RUP - slidepdf.com

http://slidepdf.com/reader/full/56195149-metodologia-rup 1/118

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 esteproyecto?

•¿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 deproyecto.

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 nuevosistema potencial.

La fase de inicio debería ser relativamente corta en lamayoría de los proyectos, una duración de una a unaspocas semanas.



INICIO

“Vislumbrar el alcance del producto, visión yanálisis del negocio”

El propósito es establecer una visión común inicial de losobjetivos del proyecto, determinar si es viable y decidir si

merece la pena llevar a cabo algunas investigacionesserias 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 que

consiste 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 una

secuencia 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. El

cliente 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, y

pensar 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 contenidas

dentro 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 la

informació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 listacon los diferentes objetivos que se esperanalcanzar cuando el sistema software a

desarrollar esté en explotación. Seránespecificados mediante una plantilla paraobjetivos.



Diagramas

OBJ –01 Gestionar las cintas y películas

Descripción El sistema deberá gestionar las cintas ypelí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 delví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 decintas: entregas, devoluciones, devolucionestardías, reclamaciones, disponibilidad, etc.

Estabilidad alta

Comentarios ninguno



Requisitos de almacenamiento deinformación

Esta sección contiene la lista derequisitos de almacenamiento deinformación que se han identificado,

utilizando para especificarlos la plantillapara requisitos de almacenamiento deinformación. Especificaremos toda la

información que debemos almacenaren 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 correspondientea 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 delví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 pendientesDescripció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 alquilerIntervalo temporal sólo presente

Estabilidad alta

Comentarios Un socio puede hacer ingresos a cuenta, por ejemplo para enviar a sus hijospor películas sin que éstos tengan que llevar dinero



Diagramas de casos de uso

En esta sección hemos incluido losdiagramas de casos de uso de nuestrosistema, desarrollados con la herramienta

Rational Rose 98



Diagrama de casos de uso delsubsistema Gestión de socios



Diagrama de casos de uso delsubsistema Gestión de películas



Diagrama de casos de uso delsubsistema Gestión de alquileres



Definición de actores

Este apartado contiene los diferentes actores que sehan identificado, especificados mediante la plantillapara 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 delvídeo –club

Comentarios ninguno



ELABORACIÓN

• La elaboración es la serie inicial de iteraciones durantelas que el equipo lleva a cabo un estudio serio,implementa (programas y pruebas) el núcleo central dela 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 yseis semanas.



ELABORACIÓN

• Se fija la duración de la elaboración entendiendo quese fija la fecha de finalización; si es probable que elequipo no cumpla con la fecha, algunos requisitos secolocan en la lista de tareas futuras.

• La iteración debe terminar a tiempo, con una versiónestable 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 sistemafinal 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 manerarealista.

• Adaptar en base a la retroalimentación procendente delas pruebas, usuarios y desarrolladores.

• Escribir la mayoría de los casos de uso y otrosrequisitos 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écnicacomo otros factores, como incertidumbre del esfuerzo o

facilidad de uso.

• COBERTURA: implica que todas las partesimportantes del sistema se tratan, al menos en lasprimeras 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.

Ó Ó




• 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ón2, etc, cuando nuevos requisitos y nuevasinterpretaciones influyan en el orden.

Rango Requisito(Caso de uso o característica) Comentario

Alto Procesar ventaRegistro(logging)

Puntuación alta en todoslos criterios de clasificación.Extendido. Difícil de añadirmás tarde

Medio Mantener usuarios….

Afecta subdominio deseguridad…

Bajo …. …

Ó Ó






ROLES EN RUPAnalistas:

• 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áficoEspecialista 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 artefactomás importante que se crea durante el análisisorientado a objetos.

• Un modelo del dominio es una representación declases conceptuales no de componentes software. Nose trata de un conjunto de diagramas que describenclases software, u objetos software conresponsabilidades.

• El UP define al modelo del dominio como uno de losartefactos que pueden crearse en la Disciplina delModelado del negocio.



MODELO DEL DOMINIO

Utilizando notación UML el modelo del dominio se

representa con un conjunto de diagrama de clases en losque 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 lasabstracciones relevantes, vocabulario del dominio e información del dominio



MODELO DEL DOMINIOEs 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 basede datos, a menos que se esté modelando sea de

conceptos software, como un modelo de interfacesde 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 enté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 seaplica la clase conceptual.

C



Clases conceptuales

Cl l



Clases conceptuales

Una diferencia esencial entre el análisis orientado a

objetos y el estructurado es: la división por clasesconceptuales (objetos) en lugar de la división porfunciones.

• La principal tarea del análisis es identificardiferentes conceptos en el dominio del problema ydocumentar el resultado en un modelo del dominio.

Id ifi ió d Cl l



Identificación de Clases conceptuales

El objetivo es crear un modelo del dominio de clases

conceptuales interesantes significativas del dominio deinterés. En este caso eso significa conceptos relacionadoscon el caso de uso en estudio.

No piense que un modelo de dominio es mejor si contienepocas clases conceptuales suele ser verdad justamente locontrario.

Es valido tener clase conceptuales sin atributos, o clasesconceptuales con un rol puramente de comportamiento enel dominio en lugar de un rol de información.

Id ifi ió d Cl l




Técnicas para identificar clases conceptuales:

1. Utilización de una lista de categorías de clasesconceptuales.

2. Identificación de frases nominales.

Id tifi ió d Cl t l



Identificación de Clases conceptualesCategoría o clase conceptual Ejemplo

Objetos tangibles o físicos Registro

AviónEspecificaciones, diseños odescripciones de las cosas

EspecificaciónDelProductoDescripcionDelVuelo

Lugares Tienda

Transacciones Venta, pago

Líneas de transacción LineaDeVenta

Roles de la gente CajeroPiloto

Contenedores de otras cosas Tienda, lataAvión

Cosas en un contenedor ArticuloPasajero

Otros sistemas informáticos oelectromecánicos externos al sistema

SistemaAutorizacionPagoCreditoControlTraficoAreo




Identificación de Clases conceptualesCategoría o clase conceptual Ejemplo

Conceptos abstractos AnsiaAcrofobia

organizaciones DepartamentoDeVentasCompañiaAerea

Hechos Venta, pago, reunionVuelo,colision,aterrizaje

Procesos (normalmente no se presentan

como conceptos, pero podría ocurrir)

VentaDeProducto

ReservaUnAsientoReglas y políticas PoliticaDeReintegro

PoliticaDeCancelación

Catálogos CatalogoProductosCatalogoPiezas

Registros de finanzas, trabajo, contratos,cuestiones legales

Recibo, libroMayor, contratoEmpleoRegistroMantenimiento

Instrumentos y servicios financieros LineaCreditoStock

Manuales, documentos, artículos de

referencia, libros

ListaDeCambiosDe PrecioDiario

ManualReparaciones









A partir del análisis de la Lista de categorías de clases

conceptuales y las frases nominales, se genera una listade clases candidatea del dominio. La lista está restringidaa los requisitos y simplificaciones que se están estudiando.

No existe una lista correcta, es una colección algoarbitraria de abstracciones y vocabulario del dominio queel modelador considere relevantes.

RegistroArticuloTiendaVentaPago

CatalogoDePagosEspecificacionDelProductoLineaDeVentaCajeroClienteEncargado

G í l d l d d l d i i



Guía para el modelado del dominio

Aplique los siguientes pasos para crear un modelo de

dominio.

1. Liste las clases conceptuales candidatas (utilizando lastécnicas).

2. Represéntelos en un modelo de dominio

3. Añada las asociaciones necesarias para registrar lasrelaciones que hay que mantener en memoria.

4. Añada los atributos necesarios para satisfacer losrequisitos de información.

A i i



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 quees necesaria conservar durante un periodo de tiempo.

Una asociación se representa en UML con una línea entreclases con un nombre de asociación.

A i i



Asociaciones

Son bidireccionales.

Los extremos de una asociación pueden contener unaexpresión de multiplicidad que indica la relación numéricaentre las instancias de las clases.

Una flecha de dirección de lectura opcional indica ladirección de la lectura del nombre de la asociación; noindica la dirección de la visibilidad o navegación.

Asociaciones



Asociaciones

Asociaciones



AsociacionesMultiplicidad.

Localización de las asociaciones



Localización de las asociaciones

Categoría Ejemplo

A es una parte de B Cajón – registroAla - avión

A es una parte lógica de B LineadeVenta – VentaEtapaVuelo - RutaVuelo

A está contenido físicamente en B Registro-Tienda, Artículo-estantería

A esta contenido lógicamente en B DescripcionArticulo-catalogoVuelo-planificaciónVuelo

A es una descripción de B DescripcionArticulo-articulo

A es una línea de transacción oinforme de B

LineaVenta-ventaTrabajoMantenimiento- registroMantenimiento

A se conoce/informa/captura en B Venta – registroReserva -listaPasajeros

A es miembro de B Cajero – tiendaPiloto - compañiaArea

Comience la inclusión de las asociaciones utilizando la siguiente tabla

Asociaciones de prioridad alta



Asociaciones de prioridad altaCategorías que son invariablemente útiles incluirlas en elmodelo del dominio.

A es parte lógica o física de BA está contenida lógica o físicamente en BA se registra en B

Tarea:

Investigar el manejo de los atributos en el modelo del dominio

Asociaciones



Asociaciones

Asociaciones



Asociaciones



DIAGRAMAS DE SECUENCIA

Diagramas de secuencia



Diagramas de secuenciaEl diagrama de secuencia de un sistema muestragráficamente los eventos que fluyen de los actores alsistema.

Los diagramas de secuencia de un sistema se preparandurante la fase de análisis de un ciclo de desarrollo. Su

creación depende de la formulación previa de los casos deuso.




Diagramas de secuenciaLos diagramas de secuencia es un artefacto creado demanera rápida y fácil, que muestra los eventos de entraday 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 actpresexternos 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 sucomportamiento como una “caja negra” (que hace, sin

saber como lo hace).




Diagramas de secuenciaEs deseable aislar e ilustrar las operaciones que un actorexterno solicita al sistema, porque constituyen una parteimportante de la comprensión del comportamiento delsistema.

Un diagrama de secuencia es un dibujo que muestra, para

un escenario específico de un caso de uso, los eventosque generan los actores externos, el orden y los eventosentre los sistemas.









Eventos



EventosEl evento de un sistema es un hecho externo de entradaque un actor produce en un sistema. El evento da origen a

una operación de respuesta. La operación de un sistemaes una acción que éste ejecuta en respuesta a un eventodel sistema.

Elaboración de diagramas de secuencia:1. Trace una línea que represente el sistema como unacaja negra.

2. Identifique los actores que operan directamente sobreel sistema. Trace una línea para cada uno de ellos.

3. A partir del curso normal de los eventos del caso deuso identifique los eventos del sistema que songenerados por los actores. Muéstrelos en el diagrama.

Eventos



EventosEl evento de un sistema es un hecho externo de entradaque un actor produce en un sistema. El evento da origen a

una operación de respuesta. La operación de un sistemaes una acción que éste ejecuta en respuesta a un eventodel sistema.

Elaboración de diagramas de secuencia:1. Trace una línea que represente el sistema como unacaja negra.

2. Identifique los actores que operan directamente sobreel sistema. Trace una línea para cada uno de ellos.

3. A partir del curso normal de los eventos del caso deuso identifique los eventos del sistema que songenerados por los actores. Muéstrelos en el diagrama.

4. A la izq. del diagrama puede incluir el texto del caso.







DE LOS REQUISITOS AL DISEÑO



Hasta el momento, el caso ha hecho hincapié en el estudiode los requisitos, conceptos, y operaciones relacionadascon un sistema. Se investigaron un 10% de los requisitosen la fase de inicio, y se comenzó un estudio un poco másprofundo 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 losrequisitos a un enfoque centrado en el diseño y la

implementación

Diseño



DiseñoDurante el diseño de los objetos, se desarrolla unasolución lógica basada en el paradigma orientado a

objetos.

Lo esencial en esta solución es la creación de diagramasde interacción, que representa el modo en que los objetos

colaboran para satisfacer los requisitos.

En paralelo a la elaboración de los diagramas deinteracción se pueden representar los diagramas de

clases. Éstos resumen la definición de las clases desoftware (e interfaces) que se van implementar en elsoftware.



DIAGRAMAS DE INTERACCIÓN

Diagramas de interacción



Diagramas de interacciónEl término diagrama de interacción es una generalizaciónde dos tipos de diagramas de UML más especializados;

ambos pueden utilizarse para representar de foema similarla interacción entre los mensajes:

•Diagramas de colaboración.

•Diagramas de secuencia.Los diagramas de colaboración ilustran interaccionesentre los objetos se pueden colocar en cualquier lugar deldiagrama.

Los diagramas de secuencia ilustran las interacciones enun tipo de formato con el aspecto de una cerca (valla), enel que cada objeto nuevo se añade a la derecha.




Diferencias entre los diagramas



Diferencias entre los diagramas

Tipo Puntos Fuertes Puntos Débiles

secuencia Muestra claramente lasecuencia u ordenación enel tiempo de los mensajes.

Notación simple

Fuerza a extender por laderecha cuando se añadenobjetos; consume espaciohorizontal

colaboración Economiza espacio,flexibilidad al añadir nuevosobjetos en dos dimensiones.

Es mejor para ilustrarbifurcaciones complejas y

comportamiento concurrente

Difícil ve la secuencia demensajes.

Notación más compleja





http://slidepdf.com/reader/full/56195149-metodologia-rup 77/118Diagramas de interacción



Diagramas de interacciónSe debe dedicar un tiempo y esfuerzo no trivial a lacreación de diagramas de interacción, como reflejo que se

ha estudiado cuidadosamente los detalles del diseño delos objetos.

Cree los diagramas de interacción por parejas, no solo. El

diseño colaborando con otro será mejor, y los compañerosaprenderán rápidamente uno de los otros.

Principalmente durante esta etapa se requiere la aplicaciónde las técnicas del diseño, en términos de patrones, estilos

y principios.

Notación de los diagramas de interacción



Notación de los diagramas de interacción

Para cualquier elemento UML (clase, actor,.. ) unainstancia utiliza el mismo símbolo gráfico que el tipo, perocon una cadena de texto que lo designa subrayada.

Venta :Venta v1:Venta



DIAGRAMAS DE COLABORACIÓN

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 ovisibilidad entre los objetos. De manera formal un enlacees una instancia de una asociación.

MensajesCada mensaje entre objetos se representa con unaexpresión de mensaje y una pequeña flecha que indica la

dirección del mensaje. Pueden fluir muchos mensajes através de un enlace. Se añade un número de secuenciapara mostrar el orden secuencial de los mensajes en elhilo del control actual





DIAGRAMAS DE SECUENCIA




g

Enlaces.

A diferencia de los diagramas de colaboración, losdiagramas de secuencia no muestran enlaces.

MensajesCada mensaje entre objetos se representa con unaexpresión de mensaje sobre una línea con punta de flechaentre los objetos. El orden del tiempo se organiza de arribahacia abajo.




g

Focos de control y cajas de activación

En los diagramas de secuencia se pueden mostrar losfocos de control utilizando una caja de activación, la cuales opcional.

Representación de retornosSe pueden mostrar el retorno de un mensaje mediante unalínea punteada con una flecha abierta, al final de una cajade activación. Algunos anotan la línea de retorno para

describir lo que está devolviendo a partir del mensaje.




http://slidepdf.com/reader/full/56195149-metodologia-rup 87/118Diagramas de secuencia



g

Mensajes self (this)

Se puede representar un mensaje que se envía de unobjeto a él mismo utilizando una caja de activaciónanidada.




g

Línea de vida del objeto y destrucción de objetosLas líneas verticales debajo de los objetos indican suduración de vida en el diagrama. En algunascircunstancias es deseable mostrar la destrucciónexplícita de un objeto.










http://slidepdf.com/reader/full/56195149-metodologia-rup 94/118Diseño y patrones



y pEl diseño es una etapa crítica; es la parte esencial de lo

que entendemos por desarrollar un sistema orientado aobjetos, 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 paraasignar responsabilidades- ) son un apoyo para laenseñanza que ayuda a entender el diseño de objetosesencial, y aplica el razonamiento para el diseño de una

forma sistemática, racional y explicable.

Responsabilidad



pUML define una responsabilidad como un contrato u

obligación de un clasificador. Las responsabilidades estánrelacionadas con las obligaciones de un objeto en cuanto asu 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, perolos métodos se implementan para llevar a cabo

responsabilidades.

Patrones



Repertorio tanto de principios generales como desoluciones 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 anuevos contextos, idealmente proporciona consejos sobreel modo de aplicarlo en varias circunstancias y consideralos puntos fuertes y compromisos.

Patrones GRASP



La asignación habilidosa de responsabilidades esextremadamente importante en el diseño de objetos.

La decisión acerca de la asignación de responsabilidadesa menudo, tiene lugar durante la creación de losdiagramas de interacción y con seguridad durante la

programación.Los patrones GRASP describen los principiosfundamentales del diseño de objetos y asignación deresponsabilidades, 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 – laclase que tiene la información necesaria para realizar la

responsabilidad –

Problema: ¿Cuál es el principio general para asignarresponsabilidades a los objetos?

Ejemplo: En la aplicación del PDV , algunas clases necesitan conocerel 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 analizarlas clases que tienen la información necesaria.

Experto en Información


http://slidepdf.com/reader/full/56195149-metodologia-rup 102/118Experto en Información




http://slidepdf.com/reader/full/56195149-metodologia-rup 104/118Experto en Información



Contraindicaciones: Algunas veces la solución no es deseable, debidoa problemas de acoplamiento y cohesión. ¿Quién es el

responsable de almacenar una venta en una base dedatos?

Beneficios: Se mantiene el encapsulamiento de la información, puestoque los objetos utilizan su propia información para llevar acabo 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 unainstancia de la clase A si se cumple uno o más de los sig.Casos:

1. B agrega objetos de A2. B contiene objetos de A.3. B registra instancias de objetos de A,4. B utiliza más estrechamente objetos de A5. 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 unanueva instancia de alguna clase?

Ejemplo: En la aplicación del PDV , quién debería ser responsable dela creación de LIneaDeVenta.

Creador


http://slidepdf.com/reader/full/56195149-metodologia-rup 107/118Creador


http://slidepdf.com/reader/full/56195149-metodologia-rup 108/118Creador



Contraindicaciones: A menudo, la creación requiere una complejidadsignificativa, como utilizar instancias recicladas por motivosde rendimiento, crear condicionalmente una instancia de apartir de una familia de clases similares basado en el valorde una propiedad externa. Preferible utilizar una Factoría

Beneficios: Se soporta bajo acoplamiento, lo que implica menosdependencias 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 acoplamienttopermanezca bajo.

El acoplamiento es una medida de la fuerza con que unelemento está conectado a, tiene conocimiento de, confíaen , otros elementos. Un elemento con bajo acoplamientono depende demasiado de otros elementos.

Problema: ¿Cómo soportar bajas dependencias, bajo impacto delcambio e incremento de la reutilización?

Ejemplo: Asuma que tenemos la necesidad de crear una instancia dePago 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 altoentre objetos estables y elementos generales. Por ejemplouna aplicación java J2EE puede acoplarse con seguridadcon librerías de java porque son estables y extendidas.

Beneficios: No afectan los cambios en otros componentes.Fácil de entender de manera aisladaConveniente de utilizar.

Patrones relacionados: Variaciones protegidas.

Bajo AcoplamientoC C



En los lenguajes orientados a objetos como C++, java, y C#, algunasde las formas comunes de acoplamiento entre el TipoX yelTipoY son:

1. El TipoX tiene un atributo (miembro de datos, o variable deinstancia) que hace referencia a una instancia de TipoY, oal propio TipoY.

2. Un objeto de TipoX invoca los servicios de un objeto de

TipoY3. 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 deTipoY, 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ónS l ió A i bilid d d l h ió



Solución: Asignar una responsabilidad de manera que la cohesiónpermanezca alta.

La Cohesión es una medida de la fuerza con la que serelacionan los objetos y del grado de focalización de lasresponsabilidades de un elemento. Un elemento conresponsabilidades altamente relacionadas y que no haceuna 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 dePago y asociarla con la venta. ¿Qué clase debería ser

responsable de esto?

Alta CohesiónC t i di i E i t l té j tifi d l



Contraindicaciones: Existen pocos casos en los que esté justificada laaceptación de baja cohesión.

Un caso es la agrupación de responsabilidades o código en una claseo componentes para simplificar el mantenimiento por unapersona.

Beneficios: Se incrementa la claridad y facilita la comprensión deldiseño.

Se simplifica el mantenimiento y las mejoras.Se soporta a menudo bajo acoplamientoEl grano fino de funcionalidad altamente relacionadaincrementa la reutilización porque una clase cohesiva sepuede utilizar para un propósito muy específico.

Patrones relacionados: Variaciones protegidas.

ControladorS l ió A i l bilid d d ibi j j



Solución: Asignar la responsabilidad de recibir o manejar un mensajede evento del sistema a una clase que representa una delas siguientes opciones:

• Representa el sistema global, dispositivo o subsistema(controlador de fachada).

• Representa un escenario de caso de uso en el que tienelugar el evento del sistema a menudo denominado

<NombreCasoUso>Manejador,<NombreCasoUso>Coordinador, o<NombreCasoUso>Sesion.

• Utilice la misma clase controlador para todos los eventosdel sistema en el escenario del caso de uso.

• Informalmente, una sesión es una instancia de unaconversación con un actor.

Problema: ¿Quién es el responsable de gestionar un evento deentrada al sistema?

ControladorEj l E l li ió N E h i i d l



Ejemplo: En la aplicación NuevaEra, hay varias operaciones delsistema, que muestran al propio sistema como una clase ocomponente.

¿Quién debería ser el controlador de los eventos del sistema comointroducirArticulo y finalizarVenta?

Beneficios: Aumenta el potencial para reutilizar y las interfaces

conectablesRazonamiento sobre el estado de los casos de uso.

Documents

56195149 Metodologia RUP