Metodologia RUP

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


subsistema Gestión de películas


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.


• 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 …. …

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.


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


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

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.


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


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.

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.

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.

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ó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


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.


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.


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.


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.


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

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

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.

Metodologia RUP

Documents

Transcript of Metodologia RUP