PROCESO UNIFICADO

PROCESO UNIFICADO

PROCESO UNIFICADO

INICIO

INICIO
La mayora de los proyectos requieren una etapa inicial breve en la que estudian los siguientes tipos de preguntas:
Cul es la visin y el anlisis del negocio para este proyecto? Es viable? Comprar o construir? Estimacin aproximada del costo Deberamos abordarlo o no seguir?

INICIO
El objetivo de la etapa de inicio no es definir todos los requisitos, o generar una estimacin creble o plan de proyecto. An bajo riesgo de simplificar demasiado, la idea es hacer la investigacin justa para formar una opinin racional y justificable del propsito global y la viabilidad del nuevo sistema potencial.
La fase de inicio debera ser relativamente corta en la mayora de los proyectos, una duracin de una a unas pocas semanas.

INICIO
Vislumbrar el alcance del producto, visin y anlisis del negocio
El propsito es establecer una visin comn 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 elaboracin.

INICIO

CASOS DE USO

Resumen
En este trabajo se ofrecen un ejemplo de la tcnica de los casos de uso, aplicndolo al caso de la gestin de un pequeo vdeoclub. En la introduccin inicial se explica brevemente en que consiste esta tcnica y sus caractersticas ms importantes. A continuacin se han desarrollado los diferentes casos de uso del ejemplo junto a las plantillas para su especificacin. Dado que se trata de un ejemplo ficticio se han simplificado las plantillas eliminando los campos relativos a versin, autores, fuentes, importancia, urgencia y estado de desarrollo.

El ejemplo no es una especificacin de requisitos completa, se incluye slo a modo de ejemplo.

Definicin de un Caso de Uso

Los casos de uso son una tcnica para la especificacin de requisitos funcionales propuesta inicialmente en [Jac93] y que actualmente forma parte de la propuesta de UML [Boo99]. Un caso de uso es la descripcin de una secuencia de interacciones entre el sistema y uno o ms actores en la que se considera al sistema como una caja negra y en la que los actores obtienen resultados observables.

Definicin de un Caso de Uso

Son un mecanismo para ayudar a mantenerlo simple y entendible para todo el personal involucrado. Son historias del uso de un sistema para alcanzar objetivos. Formato Breve: Procesar Venta. Un cliente llega a una caja con artculos para comprar. El cajero utiliza el sistema de punto de venta para registrar cada artculo comprado. El sistema presenta una suma parcialy detalles de cada lnea de venta. El cliente introduce los datos del pago, que el sistema valida y registra. El sistema actualiza el inventario. El cliente recibe un recibo del sistema y se va con los artculos.

Actores Principales de una CU

Los actores son personas u otros sistemas que interactan con el sistema cuyos requisitos se estn describiendo. Los casos de uso presentan ciertas ventajas sobre la descripcin meramente textual de los requisitos funcionales, ya que facilitan la licitacin de requisitos y son fcilmente comprensibles por los clientes y usuarios.

Adems, pueden servir de base a las pruebas del sistema y a la documentacin para los usuarios.

Eficiencia
La idea base de los sistemas distribuidos es la de obtener sistemas mucho ms rpidos que los ordenadores actuales. (Paralelismo) Para lograr un sistema eficiente hay que descartar la idea de ejecutar un programa en un nico procesador de todo el sistema, y pensar en distribuir las tareas a los procesadores libres ms rpidos en cada momento.

Representacin Grfica de un CU
Los casos de uso tienen una representacin grfica en los denominados diagramas de casos de uso [Boo99]. En estos diagramas, los actores se representan en forma de pequeos monigotes y los casos de uso se representan por elipses contenidas dentro de un rectngulo que representa al sistema. La participacin de los actores en los casos de uso se indica por una flecha entre el actor y el caso de uso que apunta en la direccin en la que fluye la informacin. Cada caso de uso puede estar definido por: texto que lo describe, secuencia de pasos ejecutados dentro del caso de uso, condiciones prepost 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 explotacin. Sern especificados mediante una plantilla para objetivos.

Diagramas
OBJ01 Descripcin Gestionar las cintas y pelculas El sistema deber gestionar las cintas y pelculas disponibles en el vdeo club: adquisiciones, retiradas, disponibilidad, etc. Alta Ninguno Gestionar los socios El sistema deber gestionar las socios del vdeoclub: altas, bajas, modificaciones de datos, sanciones, personas autorizadas, cuentas, etc. Alta Ninguno

Estabilidad Comentarios OBJ02 Descripcin

Estabilidad Comentarios

Diagramas
OBJ03 Gestionar los alquileres

Descripcin

El sistema deber gestionar los alquileres de cintas: entregas, devoluciones, devoluciones tardas, reclamaciones, disponibilidad, etc.
alta ninguno

Estabilidad Comentarios

Requisitos de almacenamiento de informacin

Esta seccin contiene la lista de requisitos de almacenamiento de informacin que se han identificado, utilizando para especificarlos la plantilla para requisitos de almacenamiento de informacin. Especificaremos toda la informacin que debemos almacenar en nuestro sistema.

Requirimientos
RI01 Objetivos asociados Requisitos asociados Informacin sobre pelculas OBJ01 Gestionar las pelculas y cintas RF04 Alta de pelcula RF05 Alta de cinta de vdeo RF08 Baja de cinta de vdeo RF10 Consulta de pelcula RF13 Consulta de pelculas alquiladas un da determinado

Descripcin Datos especficos

El sistema deber almacenar la informacin correspondiente a las pelculas del vdeoclub. En concreto: Ttulo de la pelcula Cintas de la pelcula alquiladas en cada momento Cintas de la pelcula disponibles para ser alquiladas en cada momento Tipo de la pelcula: infantil, accin, ciencia-ficcin o adultos Duracin de la pelcula, en horas y minutos Actores principales de la pelcula Director de la pelcula Productora de la pelcula Ao de produccin de la pelcula

Intervalo temporal Estabilidad Comentarios

pasado y presente alta ninguno

Requerimientos
RI02 Objetivos asociados Requisitos asociados Informacin sobre socios OBJ02 Gestionar los socios RF01 Alta de socio RF02 Baja de socio RF03 Modificacin de datos de un socio RF11 Consulta de un socio RF12 Consulta de socios con pagos pendientes RF12 Consulta de los socios ms rentables RF15 Identificacin de socio

Descripcin Datos especficos

El sistema deber almacenar la informacin correspondiente a los socios del vdeoclub. En concreto: Nmero de socio, que deber ser nico para cada socio Nmero del documento nacional de identidad Nombre y apellidos Fecha de nacimiento Sexo Fecha de alta como socio Direccin Telfonos Pelculas alquiladas en un momento dado

Intervalo temporal Estabilidad Comentarios

slo presente alta ninguno

Requerimientos
RI03 Objetivos asociados Requisitos asociados Informacin sobre cuentas de socios OBJ02 Gestionar los socios RF01 Alta de socio RF02 Baja de socio RF05 Alquiler de cinta de vdeo RF08 Devolucin de cintas de vdeo RF09 Ingreso a cuenta RF11 Consulta de un socio RF12 Consulta de socios con pagos pendientes

Descripcin Datos especficos

El sistema deber almacenar la informacin correspondiente a las cuentas de los socios del vdeoclub. En concreto: 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 tambin la pelcula alquilada y la fecha del alquiler

Intervalo temporal Estabilidad Comentarios

slo presente alta Un socio puede hacer ingresos a cuenta, por ejemplo para enviar a sus hijos por pelculas sin que stos tengan que llevar dinero

Diagramas de casos de uso

En esta seccin 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 Gestin de socios

Diagrama de casos de uso del subsistema Gestin de pelculas

Diagrama de casos de uso del subsistema Gestin de alquileres

Definicin de actores
Este apartado contiene los diferentes actores que se han identificado, especificados mediante la plantilla para actores de casos de uso.
ACT01 Descripcin Comentarios Socio Este actor representa a los socios del vdeoclub ninguno

Definicin de actores
ACT02 Empleado del vdeoclub

Descripcin

Este actor representa a los empleados del vdeoclub

ninguno

Comentarios

ELABORACIN
La elaboracin es la serie inicial de iteraciones durante las que el equipo lleva a cabo un estudio serio, implementa (programas y pruebas) el ncleo central de la arquitectura, aclara la mayora de los requisitos y aborda las cuestiones de alto riesgo.
En el PU el riesgo incluye valor del negocio.

La elaboracin consta entre dos y cuatro iteracciones; se recomienda que cada iteraccin dure de entre dos y seis semanas.

ELABORACIN
Se fija la duracin de la elaboracin entendiendo que se fija la fecha de finalizacin; si es probable que el equipo no cumpla con la fecha, algunos requisitos se colocan en la lista de tareas futuras.
La iteracin debe terminar a tiempo, con una versin estable y que se pueda probar.

En esta fase no se crean prototipos desechables; sino que el cdigo y el diseo son porciones del sistema final con calidad de produccin.

ELABORACIN (recomendaciones)
Llevar a cabo iteraciones breves, de duracin fija, dirigidas por el riesgo. Comenzar a programar pronto. Disear, implementar y probar de manera adaptable, las partes bsicas y arriesgadas de la arquitectura. Probar desde el principio, a menudo y de manera realista. Adaptar en base a la retroalimentacin procendente de las pruebas, usuarios y desarrolladores.

Escribir la mayora de los casos de uso y otros requisitos a detalle, a travs de una serie de talleres, uno por cada iteracin de la elaboracin

PLANIFICACIN DE LA ELABORACIN
Organice los requisitos y las iteraciones segn el riesgo, grado de cobertura y naturaleza crtica. RIESGO: comprende tanto la complejidad tcnica 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 quizs una implementacin amplia y superficial a travs de muchos componentes- . NATURALEZA CRTICA: se refiere a las funciones de alto valor para el negocio.

PLANIFICACIN DE LA ELABORACIN
La clasificacin se realiza antes de la iteracin 1, pero despus de la iteracin 1 otra vez antes de la iteracin 2, etc, cuando nuevos requisitos y nuevas interpretaciones influyan en el orden.
Rango
Alto

Requisito (Caso de uso o caracterstica)

Procesar venta Registro(logging)

Comentario
Puntuacin alta en todos los criterios de clasificacin. Extendido. Difcil de aadir ms tarde Afecta subdominio de seguridad

Medio

Mantener usuarios . .

Bajo

PLANIFICACIN DE LA ELABORACIN

ROLES EN RUP
Analistas: Analista de procesos de negocio. Diseador del negocio. Analista de sistema. Especificador de requisitos. Desarrolladores: Arquitecto de software. Diseador Diseador de interfaz de usuario Diseador de cpsulas. Diseador de base de datos. Implementador. Integrador. Otros roles: Stakeholders. Revisor Coordinacin de revisiones Revsor tcnico Cualquier rol Gestores: Jefe de proyecto Jefe de control de cambios. Jefe de configuracin. Jefe de pruebas Jefe de despliegue Ingeniero de procesos Revisor de gestin del proyecto Gestor de pruebas. Apoyo: Documentador tcnico Administrador de sistema Especialista en herramientas Desarrollador de cursos Artista grfico Especialista en pruebas: Especialista en Pruebas (tester) Analista de pruebas Diseador de pruebas

MODELO DEL DOMINIO

MODELO DEL DOMINIO

Un modelo del dominio muestra clases conceptuales significativas del dominio del problema; es el artefacto ms importante que se crea durante el anlisis orientado a objetos. Un modelo del dominio es una representacin 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 notacin UML el modelo del dominio se representa con un conjunto de diagrama de clases en los que no se define ninguna operacin. Puede mostrar: Objetos del dominio o clases conceptuales. Asociaciones entre clases conceptuales.

Atributos de las clases conceptuales.

MODELO DEL DOMINIO

El modelo del dominio podra considerarse un diccionario visual de las abstracciones relevantes, vocabulario del dominio e informacin del dominio

MODELO DEL DOMINIO

Es una representacin de cosas del mundo real del dominio de inters, 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 grficas.

Responsabilidades o mtodos.

Clases conceptuales
Una clase conceptual es una idea, cosa u objeto. Ms formalmente una clase conceptual podra considerarse en trminos de su smbolo, intensin y extensin: Smbolo: palabras o imgenes que representan una clase conceptual. Intensin: la definicin de la clase conceptual Extensin: el conjunto de ejemplos a los que se aplica la clase conceptual.

Clases conceptuales

Clases conceptuales
Una diferencia esencial entre el anlisis orientado a objetos y el estructurado es: la divisin por clases conceptuales (objetos) en lugar de la divisin por funciones. La principal tarea del anlisis es identificar diferentes conceptos en el dominio del problema y documentar el resultado en un modelo del dominio.

Identificacin de Clases conceptuales

El objetivo es crear un modelo del dominio de clases conceptuales interesantes significativas del dominio de inters. 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 informacin.

Identificacin de Clases conceptuales

Tcnicas para identificar clases conceptuales: 1. Utilizacin de una lista de categoras de clases conceptuales. 2. Identificacin de frases nominales.

Identificacin de Clases conceptuales

Categora o clase conceptual Objetos tangibles o fsicos Especificaciones, diseos o descripciones de las cosas Lugares Transacciones Registro Avin EspecificacinDelProducto DescripcionDelVuelo Tienda Venta, pago Ejemplo

Lneas de transaccin
Roles de la gente Contenedores de otras cosas Cosas en un contenedor Otros sistemas informticos o electromecnicos externos al sistema

LineaDeVenta
Cajero Piloto Tienda, lata Avin Articulo Pasajero SistemaAutorizacionPagoCredito ControlTraficoAreo

Identificacin de Clases conceptuales

Categora o clase conceptual Conceptos abstractos organizaciones Hechos Procesos (normalmente no se presentan como conceptos, pero podra ocurrir) Reglas y polticas Catlogos Ansia Acrofobia DepartamentoDeVentas CompaiaAerea Venta, pago, reunion Vuelo,colision,aterrizaje VentaDeProducto ReservaUnAsiento PoliticaDeReintegro PoliticaDeCancelacin CatalogoProductos CatalogoPiezas Ejemplo

Registros de finanzas, trabajo, contratos, cuestiones legales

Instrumentos y servicios financieros Manuales, documentos, artculos de referencia, libros

Recibo, libroMayor, contratoEmpleo RegistroMantenimiento

LineaCredito Stock ListaDeCambiosDe PrecioDiario ManualReparaciones

Identificacin de Clases conceptuales

Identificacin de Clases conceptuales

A partir del anlisis de la Lista de categoras 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 estn estudiando. No existe una lista correcta, es una coleccin algo arbitraria de abstracciones y vocabulario del dominio que el modelador considere relevantes.
Registro Articulo Tienda Venta Pago

CatalogoDePagos EspecificacionDelProducto LineaDeVenta Cajero Cliente Encargado

Gua para el modelado del dominio

Aplique los siguientes pasos para crear un modelo de dominio. 1. Liste las clases conceptuales candidatas (utilizando las tcnicas). 2. Represntelos en un modelo de dominio

3. Aada las asociaciones necesarias para registrar las relaciones que hay que mantener en memoria.
4. Aada los atributos necesarios para satisfacer los requisitos de informacin.

Asociaciones
Una asociacin es una relacin entre tipos que indica una conexin significativa e interesante. En UML, las asociaciones se definen como la relacin semntica entre dos o ms clasificadores que implica conexiones entre sus instancias. Las asociaciones que valen la pena registrar, normalmente, implican conocimiento de una relacin que es necesaria conservar durante un periodo de tiempo.

Una asociacin se representa en UML con una lnea entre clases con un nombre de asociacin.

Asociaciones
Son bidireccionales. Los extremos de una asociacin pueden contener una expresin de multiplicidad que indica la relacin numrica entre las instancias de las clases. Una flecha de direccin de lectura opcional indica la direccin de la lectura del nombre de la asociacin; no indica la direccin de la visibilidad o navegacin.

Asociaciones

Asociaciones
Multiplicidad.

Localizacin de las asociaciones

Comience la inclusin de las asociaciones utilizando la siguiente tabla
Categora A es una parte de B A es una parte lgica de B Cajn registro Ala - avin LineadeVenta Venta EtapaVuelo - RutaVuelo Ejemplo

A est contenido fsicamente en B

A esta contenido lgicamente en B A es una descripcin de B A es una lnea de transaccin o informe de B A se conoce/informa/captura en B

Registro-Tienda, Artculo-estantera
DescripcionArticulo-catalogo Vuelo-planificacinVuelo DescripcionArticulo-articulo LineaVenta-venta TrabajoMantenimiento- registroMantenimiento Venta registro Reserva -listaPasajeros

A es miembro de B

Cajero tienda Piloto - compaiaArea

Asociaciones de prioridad alta

Categoras que son invariablemente tiles incluirlas en el modelo del dominio. A es parte lgica o fsica de B A est contenida lgica o fsicamente 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 grficamente los eventos que fluyen de los actores al sistema. Los diagramas de secuencia de un sistema se preparan durante la fase de anlisis de un ciclo de desarrollo. Su creacin depende de la formulacin previa de los casos de uso.

Diagramas de secuencia
Los diagramas de secuencia es un artefacto creado de manera rpida y fcil, que muestra los eventos de entrada y salida relacionados con el sistema que se est ejecutando. UML incluye la notacin de los diagramas de secuencia para representar los eventos que parten de los actpres externos hacia el sistema. Antes de iniciar con el diseo lgico de cmo funcionar la aplicacin 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 comprensin del comportamiento del sistema. Un diagrama de secuencia es un dibujo que muestra, para un escenario especfico 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

Eventos
El evento de un sistema es un hecho externo de entrada que un actor produce en un sistema. El evento da origen a una operacin de respuesta. La operacin de un sistema es una accin que ste ejecuta en respuesta a un evento del sistema.

Elaboracin de diagramas de secuencia: 1. Trace una lnea que represente el sistema como una caja negra. 2. Identifique los actores que operan directamente sobre el sistema. Trace una lnea 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. Mustrelos en el diagrama.

Eventos
El evento de un sistema es un hecho externo de entrada que un actor produce en un sistema. El evento da origen a una operacin de respuesta. La operacin de un sistema es una accin que ste ejecuta en respuesta a un evento del sistema.

Elaboracin de diagramas de secuencia: 1. Trace una lnea que represente el sistema como una caja negra. 2. Identifique los actores que operan directamente sobre el sistema. Trace una lnea 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. Mustrelos en el diagrama. 4. A la izq. del diagrama puede incluir el texto del caso.

Diagramas de secuencia

DE LOS REQUISITOS AL DISEO

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 ms profundo en la primera iteracin de la fase de elaboracin.

En el desarrollo iterativo, en cada iteracin tendr lugar una transicin desde un enfoque centrado en los requisitos a un enfoque centrado en el diseo y la implementacin

Diseo
Durante el diseo de los objetos, se desarrolla una solucin lgica basada en el paradigma orientado a objetos. Lo esencial en esta solucin es la creacin de diagramas de interaccin, que representa el modo en que los objetos colaboran para satisfacer los requisitos.

En paralelo a la elaboracin de los diagramas de interaccin se pueden representar los diagramas de clases. stos resumen la definicin de las clases de software (e interfaces) que se van implementar en el software.

DIAGRAMAS DE INTERACCIN

Diagramas de interaccin
El trmino diagrama de interaccin es una generalizacin de dos tipos de diagramas de UML ms especializados; ambos pueden utilizarse para representar de foema similar la interaccin entre los mensajes: Diagramas de colaboracin. Diagramas de secuencia. Los diagramas de colaboracin 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 aade a la derecha.

DIAGRAMAS DE INTERACCIN

Diferencias entre los diagramas

Tipo secuencia Puntos Fuertes Muestra claramente la secuencia u ordenacin en el tiempo de los mensajes. Notacin simple colaboracin Economiza espacio, flexibilidad al aadir nuevos objetos en dos dimensiones. Es mejor para ilustrar bifurcaciones complejas y comportamiento concurrente Difcil ve la secuencia de mensajes. Notacin ms compleja Puntos Dbiles Fuerza a extender por la derecha cuando se aaden objetos; consume espacio horizontal

DIAGRAMAS DE INTERACCIN

Diagramas de interaccin
Se debe dedicar un tiempo y esfuerzo no trivial a la creacin de diagramas de interaccin, como reflejo que se ha estudiado cuidadosamente los detalles del diseo de los objetos. Cree los diagramas de interaccin por parejas, no solo. El diseo colaborando con otro ser mejor, y los compaeros aprendern rpidamente uno de los otros. Principalmente durante esta etapa se requiere la aplicacin de las tcnicas del diseo, en trminos de patrones, estilos y principios.

Notacin de los diagramas de interaccin

Para cualquier elemento UML (clase, actor,.. ) una instancia utiliza el mismo smbolo grfico que el tipo, pero con una cadena de texto que lo designa subrayada.

Venta

:Venta

v1:Venta

DIAGRAMAS DE COLABORACIN

Diagramas de colaboracin
Enlaces. Un enlace es un camino de conexin entre dos objetos; indica que es posible alguna forma de navegacin o visibilidad entre los objetos. De manera formal un enlace es una instancia de una asociacin. Mensajes Cada mensaje entre objetos se representa con una expresin de mensaje y una pequea flecha que indica la direccin del mensaje. Pueden fluir muchos mensajes a travs de un enlace. Se aade un nmero 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 colaboracin, los diagramas de secuencia no muestran enlaces. Mensajes Cada mensaje entre objetos se representa con una expresin de mensaje sobre una lnea 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 activacin En los diagramas de secuencia se pueden mostrar los focos de control utilizando una caja de activacin, la cual es opcional. Representacin de retornos Se pueden mostrar el retorno de un mensaje mediante una lnea punteada con una flecha abierta, al final de una caja de activacin. Algunos anotan la lnea 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 enva de un objeto a l mismo utilizando una caja de activacin anidada.

Diagramas de secuencia
Lnea de vida del objeto y destruccin de objetos Las lneas verticales debajo de los objetos indican su duracin de vida en el diagrama. En algunas circunstancias es deseable mostrar la destruccin explcita de un objeto.

Diseo y patrones
El diseo es una etapa crtica; 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 enseanza que ayuda a entender el diseo de objetos esencial, y aplica el razonamiento para el diseo de una forma sistemtica, racional y explicable.

Responsabilidad
UML define una responsabilidad como un contrato u obligacin de un clasificador. Las responsabilidades estn 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 clculo. Iniciar una accin 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 diseo de objetos. 1. Una venta es responsable de la creacin de una LineaDeVenta. 2. Una Venta es responsable de conocer su total. Una responsabilidad no es lo mismo que un mtodo, pero los mtodos se implementan para llevar a cabo responsabilidades.

Patrones
Repertorio tanto de principios generales como de soluciones basadas en aplicar ciertos estilos que les guan en la creacin de software.

Estos si se codifican con un formato estructurado que describa el problema y la solucin y se les da un nombre, podran llamarse patrones.

Un patrn es una descripcin de un problema y la solucin, 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 asignacin habilidosa de responsabilidades extremadamente importante en el diseo de objetos. es

La decisin acerca de la asignacin de responsabilidades a menudo, tiene lugar durante la creacin de los diagramas de interaccin y con seguridad durante la programacin. Los patrones GRASP describen los principios fundamentales del diseo de objetos y asignacin de responsabilidades, expresados como patrones.

Patrones GRASP
Cinco patrones GRASP:

Experto en Informacin.
Creador.

Alta Cohesin.
Bajo Acoplamiento.

Controlador.

Experto en Informacin
Solucin: Asignar una responsabilidad al experto en informacin la clase que tiene la informacin necesaria para realizar la responsabilidad Problema: Cul es el principio general responsabilidades a los objetos? para asignar

Ejemplo: En la aplicacin del PDV , algunas clases necesitan conocer el total de una venta. Quin debera ser responsable de conocer el total de una venta?

Mire en el modelo del dominio o en el modelo de diseo para analizar las clases que tienen la informacin necesaria.

Experto en Informacin

Experto en Informacin

Experto en Informacin
Contraindicaciones: Algunas veces la solucin no es deseable, debido a problemas de acoplamiento y cohesin. Quin es el responsable de almacenar una venta en una base de datos? Beneficios: Se mantiene el encapsulamiento de la informacin, puesto que los objetos utilizan su propia informacin para llevar a cabo las tareas. Da lugar a bajo Acoplamiento. Patrones relacionados: Bajo acoplamiento y alta cohesin.

Creador
Solucin: Asignar a la clase B la responsabilidad de crear una instancia de la clase A si se cumple uno o ms 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 ms estrechamente objetos de A 5. B tiene los datos de inicializacin que se pasarn a un objeto de A cuando sea creado. Problema: Quin debera ser responsable de la creacin de una nueva instancia de alguna clase? Ejemplo: En la aplicacin del PDV , quin debera ser responsable de la creacin de LIneaDeVenta.

Creador

Creador

Creador
Contraindicaciones: A menudo, la creacin 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 Factora Beneficios: Se soporta bajo acoplamiento, lo que implica menos dependencias de mantenimiento y mayores oportunidades para reutilizar. Patrones relacionados: Bajo acoplamiento y factora, todo-parte.

Bajo Acoplamiento
Solucin: 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, confa en , otros elementos. Un elemento con bajo acoplamiento no depende demasiado de otros elementos. Problema: Cmo soportar bajas dependencias, bajo impacto del cambio e incremento de la reutilizacin? Ejemplo: Asuma que tenemos la necesidad de crear una instancia de Pago y asociarla con la venta. Qu clase debera 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 aplicacin java J2EE puede acoplarse con seguridad con libreras de java porque son estables y extendidas. Beneficios: No afectan los cambios en otros componentes. Fcil 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 mtodo que referencia a una instancia de TipoY, o al propio TipoY, de algn modo. Esto, generalmente, comprende un parmetro 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 Cohesin
Solucin: Asignar una responsabilidad de manera que la cohesin permanezca alta. La Cohesin es una medida de la fuerza con la que se relacionan los objetos y del grado de focalizacin de las responsabilidades de un elemento. Un elemento con responsabilidades altamente relacionadas y que no hace una gran cantidad de trabajo, tiene alta cohesin. Problema: Cmo mantener la complejidad manejable? Ejemplo: : Asuma que tenemos la necesidad de crear una instancia de Pago y asociarla con la venta. Qu clase debera ser responsable de esto?

Alta Cohesin
Contraindicaciones: Existen pocos casos en los que est justificada la aceptacin de baja cohesin. Un caso es la agrupacin de responsabilidades o cdigo en una clase o componentes para simplificar el mantenimiento por una persona. Beneficios: Se incrementa la claridad y facilita la comprensin del diseo. Se simplifica el mantenimiento y las mejoras. Se soporta a menudo bajo acoplamiento El grano fino de funcionalidad altamente relacionada incrementa la reutilizacin porque una clase cohesiva se puede utilizar para un propsito muy especfico. Patrones relacionados: Variaciones protegidas.

Controlador
Solucin: 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 sesin es una instancia de una conversacin con un actor.

Problema: Quin es el responsable de gestionar un evento de entrada al sistema?

Controlador
Ejemplo: En la aplicacin NuevaEra, hay varias operaciones del sistema, que muestran al propio sistema como una clase o componente. Quin debera 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.