PROCESO UNIFICADO
PROCESO UNIFICADO
PROCESO UNIFICADO
PROCESO UNIFICADO
INICIO
INICIO La mayoría de los proyectos requieren una etapa inicial breve en la que estudian los siguientes tipos de preguntas: •¿Cuál es la visión y el
análisis del negocio para este
proyecto? •¿Es viable? •¿Comprar o construir? •Estimación aproximada del costo •¿Deberíamos abordarlo o no seguir?
INICIO El objetivo de la etapa de inicio i nicio 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 los casos de uso, aplicándolo al caso de la gestión de un pequeñ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. A continuación se han desarrollado los diferentes casos de uso del ejemplo junto a las plantillas para su especificación. Dado que se trata de un ejemplo ficticio se han simplificado las plantillas 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 la especificación de requisitos funcionales propuesta inicialmente en [Jac93] y que actualmente forma parte de la propuesta de UML [Boo99]. Un caso de uso es la descripción de una secuencia de interacciones entre el sistema y uno o más actores en la que se considera al sistema como una caja negra y en la que los actores obtienen resultados observables.
Definición 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 artículos para comprar. El cajero utiliza el sistema de punto de venta para registrar cada artículo comprado. El sistema presenta una suma parcialy detalles de cada línea 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 artículos.
Actores Principales de una CU Los actores son personas u otros sistemas que interactúan con el sistema cuyos requisitos se están describiendo. Los casos de uso presentan ciertas ventajas sobre la descripción meramente textual de los requisitos funcionales, ya que facilitan la licitación de requisitos y son fácilmente comprensibles por los clientes y usuarios. Además, pueden servir de base a las pruebas del sistema y a la documentación para los usuarios.
Eficiencia La idea base de los sistemas distribuidos es la de obtener sistemas mucho más rápidos 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 más rápidos en cada momento.
Representación Gráfica de un CU Los casos de uso tienen una representación gráfica en los denominados diagramas de casos de uso [Boo99]. En estos diagramas, los actores se representan en forma de pequeños monigotes y los casos 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 uso se indica por una flecha entre el actor y el caso de uso que apunta en la dirección en la que fluye la información. 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 explotación. Serán especificados mediante una plantilla para objetivos.
Diagramas OBJ –01 Descripción
Gestionar las cintas y películas 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
Descripción Datos específicos
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
El sistema deberá almacenar la información correspondiente a las películas del vídeo –club. En concreto:
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
Requerimientos RI –02
Información sobre socios
Objetivos asociados
Requisitos asociados
Descripción Datos específicos
OBJ –02 Gestionar los socios 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
El sistema deberá almacenar la información correspondiente a los socios del vídeo –club. En concreto:
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
Requerimientos RI –03
Información sobre cuentas de socios
Objetivos asociados
OBJ –02 Gestionar los socios
Requisitos asociados
Descripción Datos específicos
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
El sistema deberá almacenar la información correspondiente a las cuentas de los socios del vídeo –club. 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 también la película alquilada y la fecha del alquiler
Intervalo temporal
sólo presente
Estabilidad
alta
Comentarios
Un socio puede hacer ingresos a cuenta, por ejemplo para enviar a sus hijos por películas sin que éstos tengan que llevar dinero
Diagramas de casos de uso En esta sección hemos incluido los diagramas de casos de uso de nuestro sistema, desarrollados con la herramienta Rational Rose 98
Diagrama de casos de uso del subsistema Gestión de socios
Diagrama de casos de uso del subsistema Gestión de películas
Diagrama de casos de uso del subsistema Gestión de alquileres
Definición de actores Este apartado contiene los diferentes actores que se han identificado, especificados mediante la plantilla para actores de casos de uso. ACT –01
Socio
Descripción
Este actor representa a los socios del vídeo –club
Comentarios
ninguno
Definición de actores ACT –02
Empleado del vídeo –club
Descripción
Este actor representa a los empleados del vídeo –club
Comentarios
ninguno
ELABORACIÓN •
La elaboración es la serie inicial de iteraciones durante las que el equipo lleva a cabo un estudio serio, implementa (programas y pruebas) el núcleo central de la arquitectura, aclara la mayoría de los requisitos y aborda las cuestiones de alto riesgo.
•
En el PU el “riesgo” incluye valor del negocio.
•
La elaboración consta entre dos y cuatro iteracciones; se recomienda que cada iteracción dure de entre dos y seis semanas.
ELABORACIÓN •
Se fija la duración de la elaboración entendiendo que se fija la fecha de finalización; si es probable que el equipo no cumpla con la fecha, algunos requisitos se colocan en la lista de tareas futuras.
•
La iteración debe terminar a tiempo, con una versión estable y que se pueda probar.
•
En esta fase no se crean prototipos desechables; sino que el código y el diseño son porciones del sistema final con calidad de producción.
ELABORACIÓN (recomendaciones) •
Llevar a cabo iteraciones breves, de duración fija, dirigidas por el riesgo.
• •
Comenzar a programar pronto. Diseñar, implementar y probar de manera adaptable, las partes básicas y arriesgadas de la arquitectura.
Probar desde el principio, a menudo y de manera realista. • Adaptar en base a la retroalimentación procendente de las pruebas, usuarios y desarrolladores. •
•
Escribir la mayoría de los casos de uso y otros requisitos a detalle, a través de una serie de talleres, uno por cada iteración de la elaboración
PLANIFICACIÓN DE LA ELABORACIÓN •
Organice los requisitos y las iteraciones según el riesgo, grado de cobertura y naturaleza crítica.
•
RIESGO: comprende tanto la complejidad técnica como otros factores, como incertidumbre del esfuerzo o facilidad de uso.
•
COBERTURA: implica que todas las partes importantes del sistema se tratan, al menos en las primeras iteraciones – quizás una implementación “amplia y superficial” a través de muchos
componentes- . •
NATURALEZA CRÍTICA : se refiere a las funciones de alto valor para el negocio.
PLANIFICACIÓN DE LA ELABORACIÓN •
La clasificación se realiza antes de la iteración 1, pero después de la iteración 1 otra vez antes de la iteración 2, etc, cuando nuevos requisitos y nuevas interpretaciones influyan en el orden. Rango
Alto
Medio
Requisito (Caso de uso o característica) Procesar venta Registro(logging) Mantener usuarios ….
Comentario Puntuación alta en todos los criterios de clasificación. Extendido. Difícil de añadir más tarde Afecta subdominio de seguridad …
Bajo
….
…
PLANIFICACIÓN DE LA ELABORACIÓN
ROLES EN RUP Analistas: • Analista de procesos de negocio. • Diseñador del negocio. • Analista de sistema. • Especificador de requisitos.
Desarrolladores: • Arquitecto de software. • Diseñador • Diseñador de interfaz de usuario • Diseñador de cápsulas. • Diseñador de base de datos. • Implementador. • Integrador.
Otros roles: • Stakeholders. • Revisor • Coordinación de revisiones • Revsor técnico
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
MODELO DEL DOMINIO
MODELO DEL DOMINIO •
Un modelo del dominio muestra clases conceptuales significativas del dominio del problema; es el artefacto más importante que se crea durante el análisis orientado a objetos.
•
Un modelo del dominio es una representación de clases conceptuales no de componentes software. No se trata de un conjunto de diagramas que describen clases software, u objetos software con responsabilidades.
•
El UP define al modelo del dominio como uno de los artefactos que pueden crearse en la Disciplina del Modelado del negocio.
MODELO DEL DOMINIO Utilizando notación UML el modelo del dominio se representa con un conjunto de diagrama de clases en los que no se define ninguna operación. Puede mostrar: •
Objetos del dominio o clases conceptuales.
•
Asociaciones entre clases conceptuales.
•
Atributos de las clases conceptuales.
MODELO DEL DOMINIO
El modelo del dominio podría considerarse un diccionario visual de las abstracciones relevantes, vocabulario del dominio e información del dominio
MODELO DEL DOMINIO Es una representación de cosas del mundo real del dominio de interés, no de componentes de software (clases o objetos).
MODELO DEL DOMINIO Los siguientes elementos no son adecuados para el modelo del dominio: •
Artefactos software, como una ventana o una base de datos, a menos que se esté modelando sea de conceptos software, como un modelo de interfaces de usuario gráficas.
•
Responsabilidades o métodos.
Clases conceptuales Una clase conceptual es una idea, cosa u objeto. Más formalmente una clase conceptual podría considerarse en términos de su símbolo, intensión y extensión: •
Símbolo: palabras o imágenes que representan una clase conceptual.
•
Intensión: la definición de la clase conceptual
•
Extensión: el conjunto de ejemplos a los que se aplica la clase conceptual.
Clases conceptuales
Clases conceptuales Una diferencia esencial entre el análisis orientado a objetos y el estructurado es: la división por clases conceptuales (objetos) en lugar de la división por funciones. •
La principal tarea del análisis es identificar diferentes conceptos en el dominio del problema y documentar el resultado en un modelo del dominio.
Identificación de Clases conceptuales El objetivo es crear un modelo del dominio de clases conceptuales interesantes significativas del dominio de interés. En este caso eso significa conceptos relacionados con el caso de uso en estudio. No piense que un modelo de dominio es mejor si contiene pocas clases conceptuales suele ser verdad justamente lo contrario. Es valido tener clase conceptuales sin atributos, o clases conceptuales con un rol puramente de comportamiento en el dominio en lugar de un rol de información.
Identificación de Clases conceptuales Técnicas para identificar clases conceptuales: 1. Utilización de una lista de categorías de clases conceptuales. 2. Identificación de frases nominales.
Identificación de Clases conceptuales Categoría o clase conceptual Objetos tangibles o físicos Especificaciones, diseños o descripciones de las cosas Lugares Transacciones Líneas de transacción Roles de la gente Contenedores de otras cosas Cosas en un contenedor Otros sistemas informáticos o electromecánicos externos al sistema
Ejemplo Registro Avión EspecificaciónDelProducto DescripcionDelVuelo Tienda Venta, pago LineaDeVenta Cajero Piloto Tienda, lata Avión Articulo Pasajero SistemaAutorizacionPagoCredito ControlTraficoAreo
Identificación de Clases conceptuales Categoría o clase conceptual Conceptos abstractos organizaciones Hechos Procesos (normalmente no se presentan como conceptos, pero podría ocurrir) Reglas y políticas Catálogos Registros de finanzas, trabajo, contratos, cuestiones legales Instrumentos y servicios financieros Manuales, documentos, artículos de referencia, libros
Ejemplo Ansia Acrofobia DepartamentoDeVentas CompañiaAerea Venta, pago, reunion Vuelo,colision,aterrizaje VentaDeProducto ReservaUnAsiento PoliticaDeReintegro PoliticaDeCancelación CatalogoProductos CatalogoPiezas Recibo, libroMayor, contratoEmpleo RegistroMantenimiento LineaCredito Stock ListaDeCambiosDe PrecioDiario ManualReparaciones
Identificación de Clases conceptuales
Identificación de Clases conceptuales A partir del análisis de la Lista de categorías de clases conceptuales y las frases nominales, se genera una lista de clases candidatea del dominio. La lista está restringida a los requisitos y simplificaciones que se están estudiando. No existe una lista correcta, es una colección algo arbitraria de abstracciones y vocabulario del dominio que el modelador considere relevantes. Registro Articulo Tienda Venta Pago
CatalogoDePagos EspecificacionDelProducto LineaDeVenta Cajero Cliente Encargado
Guía para el modelado del dominio Aplique los siguientes pasos para crear un modelo de dominio. 1. Liste Liste las las clase clasess concep conceptua tuales les cand candida idatas tas (utili (utilizan zando do las técnicas). 2. Repr Repres esén énte telo loss en un un mode modelo lo de de domi domini nioo 3. Añada Añada las las asocia asociacio ciones nes nec necesa esaria riass para para regist registrar rar las las relaciones que hay que mantener en memoria. 4. Añada Añada los los atrib atributo utoss neces necesari arios os para para sati satisfa sface cerr los requisitos de información.
Asociaciones Una asociación es una relación entre tipos que indica una conexión significativa e interesante. i nteresante. En UML, las asociaciones se definen como “la relación
semántica entre dos o más clasificadores que implica i mplica 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 multiplicidad que indica la relación relación numérica 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
Asociaciones Multiplicidad.
Localización de las asociaciones Comience la inclusión de las asociaciones utilizando la siguiente tabla Categoría A es una parte de B
Ejemplo
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 LineaVenta-venta informe de B TrabajoMantenimiento- registroMantenimiento A se conoce/informa/captura en B Venta – registro Reserva -listaPasajeros A es miembro de B Cajero – tienda Piloto - compañiaArea
Asociaciones de prioridad alta Categorías que son invariablemente útiles incluirlas en el modelo del dominio. A es parte lógica o física de B A está contenida lógica o físicamente en B A se registra en B
Tarea: Investigar el manejo de los atributos en el modelo del dominio
Asociaciones
Asociaciones
DIAGRAMAS DE SECUENCIA
Diagramas de secuencia El diagrama de secuencia de un sistema muestra gráficamente los eventos que fluyen de los actores al sistema. Los diagramas de secuencia de un sistema se preparan durante la fase de análisis de un ciclo de desarrollo. Su creación depende de la formulación previa de los casos de uso.
Diagramas de secuencia Los diagramas de secuencia es un artefacto creado de manera rápida y fácil, que muestra los eventos de entrada y salida relacionados con el sistema que se está ejecutando. UML incluye la notación de los diagramas de secuencia para representar los eventos que parten de los actpres externos hacia el sistema. Antes de iniciar con el diseño lógico de cómo funcionará la aplicación de software, es conveniente estudiar y definir su comportamiento como una “caja negra” (que hace, sin
saber como lo hace).
Diagramas de secuencia Es deseable aislar e ilustrar las operaciones que un actor externo solicita al sistema, porque constituyen una parte importante de la comprensión del comportamiento del sistema. Un diagrama de secuencia es un dibujo que muestra, para un escenario específico de un caso de uso, los eventos que generan los actores externos, el orden y los eventos entre los sistemas.
Diagramas de secuencia
Diagramas de secuencia
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 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.
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 operación de respuesta. La operación de un sistema es una acción que éste ejecuta en respuesta a un evento del sistema. Elaboración de diagramas de secuencia: 1. Trace una línea que represente el sistema como una caja negra. 2. Identifique los actores que operan directamente sobre el sistema. Trace una línea para cada uno de ellos. 3. A partir del curso normal de los eventos del caso de uso identifique los eventos del sistema que son generados por los actores. Muéstrelos en el diagrama. 4. A la izq. del diagrama puede incluir el texto del caso.
Diagramas de secuencia
DE LOS REQUISITOS AL DISEÑO
Hasta el momento, el caso ha hecho hincapié en el estudio de los requisitos, conceptos, y operaciones relacionadas con un sistema. Se investigaron un 10% de los requisitos en la fase de inicio, y se comenzó un estudio un poco más profundo en la primera iteración de la fase de elaboración. En el desarrollo iterativo, en cada iteración tendrá lugar una transición desde un enfoque centrado en los requisitos a un enfoque centrado en el diseño y la implementación
Diseño Durante 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ón El término diagrama de interacción es una generalización de dos tipos de diagramas de UML más especializados; ambos pueden utilizarse para representar de foema similar la interacción entre los mensajes: •Diagramas de colaboración. •Diagramas de secuencia.
Los diagramas de colaboración ilustran interacciones entre los objetos se pueden colocar en cualquier lugar del diagrama. Los diagramas de secuencia ilustran las interacciones en un tipo de formato con el aspecto de una cerca (valla), en el que cada objeto nuevo se añade a la derecha.
DIAGRAMAS DE INTERACCIÓN
Diferencias entre los diagramas Tipo secuencia
colaboración
Puntos Fuertes Muestra claramente la secuencia u ordenación en el tiempo de los mensajes. Notación simple Economiza espacio, flexibilidad al añadir nuevos objetos en dos dimensiones.
Puntos Débiles Fuerza a extender por la derecha cuando se añaden objetos; consume espacio horizontal Difícil ve la secuencia de mensajes. Notación más compleja
Es mejor para ilustrar bifurcaciones complejas y comportamiento concurrente
DIAGRAMAS DE INTERACCIÓN
Diagramas de interacción Se debe dedicar un tiempo y esfuerzo no trivial a la creación de diagramas de interacción, como reflejo que se ha estudiado cuidadosamente los detalles del diseño de los objetos. Cree los diagramas de interacción por parejas, no solo. El diseño colaborando con otro será mejor, y los compañeros aprenderán rápidamente uno de los otros. Principalmente durante esta etapa se requiere la aplicación de las técnicas del diseño, en términos de patrones, estilos y principios.
Notación de los diagramas de interacción Para cualquier elemento UML (clase, actor,.. ) una instancia utiliza el mismo símbolo gráfico que el tipo, pero con una cadena de texto que lo designa subrayada.
Venta
:Venta
v1:Venta
DIAGRAMAS DE COLABORACIÓN
Diagramas de colaboración Enlaces.
Un enlace es un camino de conexión entre dos objetos; indica que es posible alguna forma de navegación o visibilidad entre los objetos. De manera formal un enlace es una instancia de una asociación. Mensajes Cada mensaje entre objetos se representa con una expresión de mensaje y una pequeña flecha que indica la dirección del mensaje. Pueden fluir muchos mensajes a través de un enlace. Se añade un número de secuencia para mostrar el orden secuencial de los mensajes en el hilo del control actual
DIAGRAMAS DE SECUENCIA
Diagramas de secuencia Enlaces.
A diferencia de los diagramas de colaboración, los diagramas de secuencia no muestran enlaces. Mensajes Cada mensaje entre objetos se representa con una expresión de mensaje sobre una línea con punta de flecha entre los objetos. El orden del tiempo se organiza de arriba hacia abajo.
Diagramas de secuencia Focos de control y cajas de activación
En los diagramas de secuencia se pueden mostrar los focos de control utilizando una caja de activación, la cual es opcional. Representación de retornos Se pueden mostrar el retorno de un mensaje mediante una línea punteada con una flecha abierta, al final de una caja de activación. Algunos anotan la línea de retorno para describir lo que está devolviendo a partir del mensaje.
Diagramas de secuencia Mensajes self (this)
Se puede representar un mensaje que se envía de un objeto a él mismo utilizando una caja de activación anidada.
Diagramas de secuencia Línea de vida del objeto y destrucción de objetos Las líneas verticales debajo de los objetos indican su duración de vida en el diagrama. En algunas circunstancias es deseable mostrar la destrucción explícita de un objeto.
Diseño y patrones El diseño es una etapa crítica; es la parte esencial de lo que entendemos por desarrollar un sistema orientado a objetos, no el dibujo de diagramas del modelo de dominio, diagramas de paquetes, etc. Los patrones GRASP (General Responsibility Assignment Sotware Patterns – patrones generales de software para asignar responsabilidades- ) son un apoyo para la enseñanza que ayuda a entender el diseño de objetos esencial, y aplica el razonamiento para el diseño de una forma sistemática, racional y explicable.
Responsabilidad UML define una responsabilidad como un contrato u obligación de un clasificador. Las responsabilidades están relacionadas con las obligaciones de un objeto en cuanto a su comportamiento. Las responsabilidades son de dos tipos Conocer y Hacer. Responsabilidades hacer: • Hacer algo él mismo, como crear un objeto o hacer un cálculo. • Iniciar una acción en otros objetos. • Controlar y coordinar actividades en otros objetos.
Responsabilidad Responsabilidades conocer: • Conocer los datos privados encapsulados. • Conocer objetos relacionados. • Conocer las cosas que puede derivar o calcular. Las responsabilidades se asignan a las clases durante el diseño de objetos. 1. Una venta es responsable de la creación de una LineaDeVenta. 2. Una Venta es responsable de conocer su total.
Una responsabilidad no es lo mismo que un método, pero los métodos se implementan para llevar a cabo responsabilidades.
Patrones Repertorio tanto de principios generales como de soluciones basadas en aplicar ciertos estilos que les guían en la creación de software. Estos si se codifican con un formato estructurado que describa el problema y la solución y se les da un nombre, podrían llamarse patrones. Un patrón es una descripción de un problema y la solución, a la que se les da un nombre, y que puede aplicar a nuevos contextos, idealmente proporciona consejos sobre el modo de aplicarlo en varias circunstancias y considera los puntos fuertes y compromisos.
Patrones GRASP La asignación habilidosa de responsabilidades es extremadamente importante en el diseño de objetos. La decisión acerca de la asignación de responsabilidades a menudo, tiene lugar durante la creación de los diagramas de interacción y con seguridad durante la programación. Los patrones GRASP describen los principios fundamentales del diseño de objetos y asignación de responsabilidades, expresados como patrones.
Patrones GRASP Cinco patrones GRASP: •Experto en Información. •Creador. •Alta Cohesión. •Bajo Acoplamiento. •Controlador.
Experto en Información Solución: Asignar una responsabilidad al experto en información – la clase que tiene la información necesaria para realizar la responsabilidad – Problema:
¿Cuál es el principio general responsabilidades a los objetos?
para
asignar
Ejemplo: En la aplicación del PDV , algunas clases necesitan conocer el total de una venta. ¿Quién debería ser responsable de conocer el total de una venta? Mire en el modelo del dominio o en el modelo de diseño para analizar las clases que tienen la información necesaria.
Experto en Información
Experto en Información
Experto en Información Contraindicaciones: Algunas veces la solución no es deseable, debido a problemas de acoplamiento y cohesión. ¿Quién es el responsable de almacenar una venta en una base de datos? Beneficios: Se mantiene el encapsulamiento de la información, puesto que los objetos utilizan su propia información para llevar a cabo las tareas. Da lugar a bajo Acoplamiento. Patrones relacionados: Bajo acoplamiento y alta cohesión.
Creador Solución: Asignar a la clase B la responsabilidad de crear una instancia de la clase A si se cumple uno o más de los sig. Casos: 1. B agrega objetos de A 2. B contiene objetos de A. 3. B registra instancias de objetos de A, 4. B utiliza más estrechamente objetos de A 5. B tiene los datos de inicialización que se pasarán a un objeto de A cuando sea creado. Problema: ¿Quién debería ser responsable de la creación de una nueva instancia de alguna clase? Ejemplo: En la aplicación del PDV , quién debería ser responsable de la creación de LIneaDeVenta.
Creador
Creador
Creador Contraindicaciones: A menudo, la creación requiere una complejidad significativa, como utilizar instancias recicladas por motivos de rendimiento, crear condicionalmente una instancia de a partir de una familia de clases similares basado en el valor de una propiedad externa. Preferible utilizar una Factoría Beneficios: Se soporta bajo acoplamiento, lo que implica menos dependencias de mantenimiento y mayores oportunidades para reutilizar. Patrones relacionados: Bajo acoplamiento y factoría, todo-parte.
Bajo Acoplamiento Solución: Asignar una responsabilidad de manera que el acoplamientto permanezca bajo. El acoplamiento es una medida de la fuerza con que un elemento está conectado a, tiene conocimiento de, confía en , otros elementos. Un elemento con bajo acoplamiento no depende demasiado de otros elementos. Problema: ¿Cómo soportar bajas dependencias, bajo impacto del cambio e incremento de la reutilización? Ejemplo: Asuma que tenemos la necesidad de crear una instancia de Pago y asociarla con la venta. ¿Qué clase debería ser responsable de esto?
Bajo Acoplamiento
Bajo Acoplamiento
Bajo Acoplamiento Contraindicaciones: No suele ser un problema el acoplamiento alto entre objetos estables y elementos generales. Por ejemplo una aplicación java J2EE puede acoplarse con seguridad con librerías de java porque son estables y extendidas. Beneficios: No afectan los cambios en otros componentes. Fácil de entender de manera aislada Conveniente de utilizar. Patrones relacionados: Variaciones protegidas.
Bajo Acoplamiento En los lenguajes orientados a objetos como C++, java, y C#, algunas de las formas comunes de acoplamiento entre el TipoX y elTipoY son: 1. El TipoX tiene un atributo (miembro de datos, o variable de instancia) que hace referencia a una instancia de TipoY, o al propio TipoY. 2. Un objeto de TipoX invoca los servicios de un objeto de TipoY 3. El TipoX tiene un método que referencia a una instancia de TipoY, o al propio TipoY, de algún modo. Esto, generalmente, comprende un parámetro o variable local de TipoY, o que el objeto de retorno de un mensaje sea una instancia de TipoY. 4. El TipoX es una subclase, directa o indirecta del TipoY. 5. El TipoY es una interfaz y el TipoX implementa esa interfaz.
Alta Cohesión Solución: Asignar una responsabilidad de manera que la cohesión permanezca alta. La Cohesión es una medida de la fuerza con la que se relacionan los objetos y del grado de focalización de las responsabilidades de un elemento. Un elemento con responsabilidades altamente relacionadas y que no hace una gran cantidad de trabajo, tiene alta cohesión. Problema: ¿Cómo mantener la complejidad manejable? Ejemplo: : Asuma que tenemos la necesidad de crear una instancia de Pago y asociarla con la venta. ¿Qué clase debería ser responsable de esto?
Alta Cohesión Contraindicaciones: Existen pocos casos en los que esté justificada la aceptación de baja cohesión. Un caso es la agrupación de responsabilidades o código en una clase o componentes para simplificar el mantenimiento por una persona. Beneficios: Se incrementa la claridad y facilita la comprensión del diseño. Se simplifica el mantenimiento y las mejoras. Se soporta a menudo bajo acoplamiento El grano fino de funcionalidad altamente relacionada incrementa la reutilización porque una clase cohesiva se puede utilizar para un propósito muy específico. Patrones relacionados: Variaciones protegidas.
Controlador Solución: Asignar la responsabilidad de recibir o manejar un mensaje de evento del sistema a una clase que representa una de las siguientes opciones: • •
• •
Representa el sistema global, dispositivo o subsistema (controlador de fachada). Representa un escenario de caso de uso en el que tiene lugar el evento del sistema a menudo denominado Manejador, Coordinador, o 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?
