clase6

UNPSJB - 2005Ingeniera de Software - Clase 6*Ingeniera de SoftwareClase 6UML

Ingeniera de Software - Clase 6

UNPSJB - 2005Ingeniera de Software - Clase 6*Contenido de la clase 6Desarrollo de soft OO usando UMLIntroduccin Modelado del softUML (Conceptos bsicos)Paradigma OOFundamentosDiagramas de CUDiagramas de InteraccionesDiagramas de claseDiagramas de estado/actividadDiagrama de componentesDiagrama de despliegue


UNPSJB - 2005Ingeniera de Software - Clase 6*BibliografaUMLwww.dsic.upv.es/~umlPatricio Letelier Torres UPV (politcnica de Valencia)UML Gota a Gota (Fowler)UML (Booch, Rumbaugh, Jacobson)Instant UML (Muller)Webswww.omg.org/uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Modelado del softwareEjemplosConstruccin de una cucha para un perroPuede hacerlo una sola persona Requiere:Modelado mnimoProceso simpleHerramientas simplesConstruccin de una casaConstruida eficientemente y en un tiempo razonable de un equipoModeladoProceso bien definidoHerramientas ms sofisticadasConstruccin de un rascacielosContexto de desarrolloDeterminar configuracin del procesoRecursos necesariosHerramientas ms sofisticadas an.

www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Claves en Desarrollo de SIHerramientasProcesoNotacinwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Sistema ComputacionalEl modelado captura laspartes esenciales del sistema Abstraccin - Modelado Visual (MV) www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Qu es UML?UML = Unified Modeling LanguageUn lenguaje de propsito general para el modelado orientado a objetosDocumento OMG Unified Modeling Language Specification UML combina notaciones provenientes desde:Modelado Orientado a Objetos Modelado de DatosModelado de Componentes Modelado de Flujos de Trabajo (Workflows)www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*MotivacinDiversos mtodos y tcnicas OO, con muchos aspectos en comn pero utilizando distintas notacionesInconvenientes para el aprendizaje, aplicacin, construccin y uso de herramientas, etc.Pugna entre distintos enfoques (y correspondientes gurs)Establecer una notacin estndarwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Historia de UMLComenz como el Mtodo Unificado, con la participacin de Grady Booch y Jim Rumbaugh. Se present en el OOPSLA95

El mismo ao se uni Ivar Jacobson. Los Tres Amigos son socios en la compaa Rational Software. Herramienta CASE Rational Rosewww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Historia de UMLNov 97UML aprobado por el OMG199819992000 UML 1.2UML 1.3UML 1.42001UML 2.0Revisiones menoreswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*UML aglutina enfoques OOUMLRumbaughJacobsonMeyerHarelWirfs-BrockFusionEmblyGamma et. al.Shlaer-MellorOdellBoochPre- and Post-conditionsState ChartsResponsabilitiesOperation descriptions, message numberingSingleton classesFrameworks, patterns, notesObject life cycleswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Aspectos NovedososDefinicin semi-formal del Metamodelo de UML Mecanismos de Extensin en UML:StereotypesConstraintsTagged Values

Permiten adaptar los elementos de modelado,asignndoles una semntica particularwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Inconvenientes en UMLDefinicin del proceso de desarrollo usando UML. UML no es una metodologaFalta integracin con respecto de otras tcnicas tales como patrones de diseo, interfaces de usuario, documentacin, etc. Monopolio de conceptos, tcnicas y mtodos en torno a UMLwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Perspectivas de UMLUML ser el lenguaje de modelado orientado a objetos estndar predominante los prximos aosRazones:Participacin de metodlogos influyentesParticipacin de importantes empresasAceptacin del OMG como notacin estndarEvidencias:Herramientas que proveen la notacin UMLEdicin de librosCongresos, cursos, etc.www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Modelos y DiagramasUn modelo captura una vista de un sistema del mundo real. Es una abstraccin de dicho sistema, considerando un cierto propsito. As, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propsito del modelo, y a un apropiado nivel de detalle. Diagrama: una representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo con vrtices conectados por arcosOMG UML 1.4 Specificationwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*... Modelos y DiagramasUn proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de intersEl cdigo fuente del sistema es el modelo ms detallado del sistema (y adems es ejecutable). Sin embargo, se requieren otros modelos ...

Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modeloswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagramas de UMLDiagrama de Casos de UsoDiagrama de ClasesDiagrama de Objetos Diagramas de Comportamiento Diagrama de Estados Diagrama de Actividad Diagramas de Interaccin Diagrama de Secuencia Diagrama de Colaboracin Diagramas de implementacin Diagrama de Componentes Diagrama de Desplieguewww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*... Diagramas de UMLLos diagramas expresan grficamente partes de un modelowww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Organizacin de Modelos4+1 vistas de Kruchten (1995)Vista LgicaVista de ProcesosVista de DistribucinVista de RealizacinVista de los Casos de UsoEste enfoque sigue el browser de Rational Rosewww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*... Organizacin de ModelosPropuesta de Rational Unified Process (RUP)M. de Casos de Uso del Negocio (Business Use-Case Model)M. de Objetos del Negocio (Business Object Model)M. de Casos de Uso (Use-Case Model)M. de Anlisis (Analysis Model)M. de Diseo (Design Model)M. de Despliegue (Deployment Model)M. de Datos (Data Model)M. de Implementacin (Implementation Model)M. de Pruebas (Test Model) www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Paquetes en UMLLos paquetes ofrecen un mecanismo general para la organizacin de los modelos/subsistemas agrupando elementos de modeladoSe representan grficamente como:www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Paquetes en UMLCada paquete corresponde a un submodelo (subsistema) del modelo (sistema)Un paquete puede contener otros paquetes, sin lmite de anidamiento pero cada elemento pertenece a (est definido en) slo un paqueteUna clase de un paquete puede aparecer en otro paquete por la importacin a travs de una relacin de dependencia entre paqueteswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Paquetes en UMLTodas las clases no son necesariamente visibles desde el exterior del paquete, es decir, un paquete encapsula a la vez que agrupaEl operador :: permite designar una clase definida en un contexto distinto del actualwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Paquetes en UMLwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama de Casos de UsoCasos de Uso es una tcnica para capturar informacin de cmo un sistema o negocio trabaja, o de cmo se desea que trabajeNo pertenece estrictamente al enfoque orientado a objeto, es una tcnica para captura de requisitoswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* EjemplosEn el paquete tipos de venta:www.dsic.upv.es/~umlOtro Ejemplo


UNPSJB - 2005Ingeniera de Software - Clase 6* Ejemploswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama de Secuenciawww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama de Colaboracinwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama de ClasesEl Diagrama de Clases es el diagrama principal para el anlisis y diseoUn diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herenciaLa definicin de clase incluye definiciones para atributos y operacionesEl modelo de casos de uso aporta informacin para establecer las clases, objetos, atributos y operacioneswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Ejemploswww.dsic.upv.es/~uml(Clase y Visibilidad)Asociacin


UNPSJB - 2005Ingeniera de Software - Clase 6* Ejemplos (Clase Asociacin)www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Ejemplos (Generalizacin)www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Ejemplos www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama de Estadoswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama de Actividadwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Emitir billetePasajeroVendedorAirline Otro Ejemplo (con swim lines)Solicitar pagoReservar plazasConfirmar plaza reservadaPagar pasajeInformar alternativas y preciosVerificar existencia vueloDar detalles vueloSolicitar pasajeSeleccionar vuelowww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama Componenteswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama de Desplieguewww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*ResumenUML define una notacin que se expresa como diagramas sirven para representar modelos/subsistemas o partes de ellosEl 80 por ciento de la mayora de los problemas pueden modelarse usando alrededor del 20 por ciento de UML-- Grady Booch



UNPSJB - 2005Ingeniera de Software - Clase 6*UMLParadigma OODiagramas


UNPSJB - 2005Ingeniera de Software - Clase 6*Por qu la Orientacin a Objetos?Proximidad de los conceptos de modelado respecto de las entidades del mundo realMejora captura y validacin de requisitosAcerca el espacio del problema y el espacio de la solucin Modelado integrado de propiedades estticas y dinmicas del mbito del problemaFacilita construccin, mantenimiento y reutilizacinConceptos comunes de modelado durante el anlisis, diseo e implementacinFacilita la transicin entre distintas fasesFavorece el desarrollo iterativo del sistemaDisipa la barrera entre el qu y el cmoSin embargo, existen problemas ...www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Problemas en OO...Los conceptos bsicos de la OO se conocen desde hace dos dcadas, pero su aceptacin todava no est tan extendida como los beneficios que esta tecnologa puede sugerir...La mayora de los usuarios de la OO no utilizan los conceptos de la OO de forma purista, como inicialmente se pretenda. Esta prctica ha sido promovida por muchas herramientas y lenguajes que intentan utilizar los conceptos en diversos grados--Wolfgang Strigelwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Problemas en OOUn objeto contiene datos y operaciones que operan sobre los datos, pero ...Podemos distinguir dos tipos de objetos degenerados:Un objeto sin datos (que sera lo mismo que una biblioteca de funciones)Un objeto sin operaciones, con slo operaciones del tipo crear, recuperar, actualizar y borrar (que se correspondera con las estructuras de datos tradicionales)Un sistema construido con objetos degenerados no es un sistema verdaderamente orientado a objetosLas aplicaciones de gestin estn constituidas mayoritariamente por objetos degeneradoswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Reflexiones respecto de Situacin Actual de Desarrollo de SIAnlisisDiseoEnfoque EstructuradoEnfoque OODiagramas de Casos de UsoDiagramas de ActividadDiagramas de SecuenciaDiagramas de Colaboracin dDFDsDiagrama de ClasesDiagrama de EstadosDiagramas de ActividadDEsModeloRelacional !!ImplementacinEntornos de Programacin VisualBases de Datos (Objeto-) RelacionalesModeloRelacionalE-R


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagramas de Casos de Uso


UNPSJB - 2005Ingeniera de Software - Clase 6*Casos de UsoLos Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el p.d.v. del usuarioPermiten definir los lmites del sistema y las relaciones entre el sistema y el entornoLos Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementacinComparacin con respecto a los Diagramas de Flujo de Datos del Enfoque EstructuradoUn caso de uso es una funcin atmica ofrecida por el sistema al entorno (actores)DFD puede ser detallada en un DFD HijoCaso Uso y Proceso igual modelado, pero caso de uso expresa funcionalidad mediante interaccin de actoresCaso de uno no modela detalle funcional internoRelaciones de extensin y generalizacin de CU no tienen igual en DFDwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Casos de UsoLos Casos de Uso cubren la carencia existente en mtodos previos (OMT, Booch) en cuanto a la determinacin de requisitosLos Casos de Uso particionan el conjunto de necesidades atendiendo a la categora de usuarios que participan en el mismoEstn basado en el lenguaje natural, es decir, es accesible por los usuarioswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Casos de UsoActores:Principales: personas que usan el sistemaSecundarios: personas que mantienen o administran el sistemaMaterial externo: dispositivos materiales imprescindibles que forman parte del mbito de la aplicacin y deben ser utilizadosOtros sistemas: sistemas con los que el sistema interactaLa misma persona fsica puede interpretar varios papeles como actores distintosEl nombre del actor describe el papel desempeadowww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Casos de UsoLos Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interaccin, los escenarios, desde el punto de vista del usuarioUn escenario es una instancia de un caso de usoLos casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estar dirigido por los casos de usowww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Casos de Uso: RelacionesUML define cuatro tipos de relacin en los Diagramas de Casos de Uso:ComunicacinInclusin : una instancia del Caso de Uso origen incluye tambin el comportamiento descrito por el Caso de Uso destino

reemplaz al denominado www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Casos de Uso: RelacionesExtensin : el Caso de Uso origen extiende el comportamiento del Caso de Uso destinoHerencia : el Caso de Uso origen hereda la especificacin del Caso de Uso destino y posiblemente la modifica y/o ampla



UNPSJB - 2005Ingeniera de Software - Clase 6* Casos de Uso: RelacionesEjemplo:www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Casos de Uso: ConstruccinUn caso de uso debe ser simple, inteligible, claro y concisoGeneralmente hay pocos actores asociados a cada Caso de UsoPreguntas clave:cules son las tareas del actor?qu informacin crea, guarda, modifica, destruye o lee el actor?debe el actor notificar al sistema los cambios externos?debe el sistema informar al actor de los cambios internos?www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Casos de Uso: ConstruccinLa descripcin del Caso de Uso comprende:el inicio: cundo y qu actor lo produce?el fin: cundo se produce y qu valor devuelve?la interaccin actor-caso de uso: qu mensajes intercambian ambos?objetivo del caso de uso: qu lleva a cabo o intenta?cronologa y origen de las interaccionesrepeticiones de comportamiento: qu operaciones son iteradas?situaciones opcionales: qu ejecuciones alternativas se presentan en el caso de uso?www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*


UNPSJB - 2005Ingeniera de Software - Clase 6*Modelo de Casos de Uso y Modelo Conceptual (Anlisis)La especificacin de cada caso de uso y los correspondientes D. de Interaccin establecen el vnculo con el modelo conceptualEn mtodos OO que carecen de una tcnica de captura de requisitos se comienza inmediatamente con la construccin del modelo conceptual (anlisis)www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagramas de Interaccin


UNPSJB - 2005Ingeniera de Software - Clase 6*InteraccinLos objetos interactan para realizar colectivamente los servicios ofrecidos por las aplicaciones. Los diagramas de interaccin muestran cmo se comunican los objetos en una interaccinExisten dos tipos de diagramas de interaccin: el Diagrama de Colaboracin y el Diagrama de SecuenciaMensajes:Sintaxis para mensajesPredecesor/fuarda secuencia:retorno := msg (args)www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagramas de interaccinEl Diagrama de Secuencia es ms adecuados para observar la perspectiva cronolgica de las interaccionesEl Diagrama de Colaboracin ofrece una mejor visin espacial mostrando los enlaces de comunicacin entre objetosEl D. de Colaboracin puede obtenerse automticamente a partir del correspondiente D. de Secuencia (o viceversa)www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama de SecuenciaMuestra la secuencia de mensajes entre objetos durante un escenario concretoCada objeto viene dado por una barra verticalEl tiempo transcurre de arriba abajoCuando existe demora entre el envo y la atencin se puede indicar usando una lnea oblicuawww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Diagrama de Secuenciawww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama de Secuenciamostrando foco de control, condiciones, recursincreacin y destruccin de objetos


UNPSJB - 2005Ingeniera de Software - Clase 6* Diagrama de Secuenciawww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama de ColaboracinSon tiles en la fase exploratoria para identificar objetosLa distribucin de los objetos en el diagrama permite observar adecuadamente la interaccin de un objeto con respecto de los demsLa estructura esttica viene dada por los enlaces; la dinmica por el envo de mensajes por los enlaceswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*MensajesUn mensaje desencadena una accin en el objeto destinatarioUn mensaje se enva si han sido enviados los mensajes de una lista (sincronizacin):

Un mensaje se enva de manera condicionada:www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* MensajesUn mensaje que devuelve un resultado:

AB1: distancia:= mover(x,y)www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama de Clases


UNPSJB - 2005Ingeniera de Software - Clase 6*ClasificacinEl mundo real puede ser visto desde abstracciones diferentes (subjetividad)Mecanismos de abstraccin:Clasificacin / InstanciacinComposicin / DescomposicinAgrupacin / IndividualizacinEspecializacin / GeneralizacinLa clasificacin es uno de los mecanismos de abstraccin ms utilizadoswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*ClasesLa clase define el mbito de definicin de un conjunto de objetosCada objeto pertenece a una claseLos objetos se crean por instanciacin de las clases

Cada clase se representa en un rectngulo con tres compartimientos:nombre de la claseatributos de la claseoperaciones de la clasewww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Clases: Notacin GrficaOtros ejemplos:

listaprimeroultimoaadirquitarcardinalidadpilaapilardesapilarcardinalidadwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Clases: EncapsulacinLa encapsulacin presenta dos ventajas bsicas:Se protegen los datos de accesos indebidosEl acoplamiento entre las clases se disminuyeFavorece la modularidad y el mantenimientoLos atributos de una clase no deberan ser manipulables directamente por el resto de objetoswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Clases: Encapsulacin (Recordar)Los niveles de encapsulacin estn heredados de los niveles de C++:(-) Privado : es el ms fuerte. Esta parte es totalmente invisible (excepto para clases friends en terminologa C++)(#) Los atributos/operaciones protegidos estn visibles para las clases friends y para las clases derivadas de la original(+) Los atributos/operaciones pblicos son visibles a otras clases (cuando se trata de atributos se est transgrediendo el principio de encapsulacin)www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Clases: EncapsulacinEjemplo:www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Relaciones entre ClasesLos enlaces entre de objetos pueden representarse entre las respectivas clasesFormas de relacin entre clases:Asociacin y Agregacin (vista como un caso particular de asociacin)Generalizacin/EspecializacinLas relaciones de Agregacin y Generalizacin forman jerarquas de claseswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*AsociacinLa asociacin expresa una conexin bidireccional entre objetosUna asociacin es una abstraccin de la relacin existente en los enlaces entre los objetoswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* AsociacinEjemplo:



UNPSJB - 2005Ingeniera de Software - Clase 6* AsociacinEspecificacin de multiplicidad (mnima...mxima)1Uno y slo uno0..1Cero o unoM..NDesde M hasta N (enteros naturales)*Cero o muchos0..*Cero o muchos1..*Uno o muchos (al menos uno)La multiplicidad mnima >= 1 establece una restriccin de existenciawww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Asociacin Cualificada AerolneaViajeronro_billete*0..1TableroAjedrezfilacolumna11CuadroReduce la multiplicidad del rol opuesto al considerar el valordel cualificadorwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Agregacin La agregacin representa una relacin parte_de entre objetosEn UML se proporciona una escasa caracterizacin de la agregacinPuede ser caracterizada con precisin determinando las relaciones de comportamiento y estructura que existen entre el objeto agregado y cada uno de sus objetos componenteswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Agregacin: Caracterizacin Caracterizaciones relacionadas con la multiplicidad Objeto AgregadoObjeto ComponenteMxima1 disjunto> 1 no disjunto

Multiplicidad Mxima1 univaluado> 1 multivaluado

Multiplicidad Mnima 0 flexible> 0 estricta Multiplicidad

Multiplicidad Mnima 0 nulos permitidos> 0 nulos no permitidos(mnc, mxc)(mna, mxa)www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*... Agregacin: Caracterizacin En UML slo se distingue entre agregacin y composicin (aggregate composition), siendo esta ltima disjunta y estrictaAdems se una agregacin se podra caracterizar segn: Puede el objeto parte comunicarse directamente con objetos externos al objeto agregado? No => inclusivaSi => no inclusivaPuede cambiar La composicin del objeto agregado? Si => dinmicaNo => estticawww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Ejemplos



UNPSJB - 2005Ingeniera de Software - Clase 6*... Ejemplos



UNPSJB - 2005Ingeniera de Software - Clase 6* EjemplosCuentaPersona1*orAsociacin excluyenteEmpresa**UsuarioEstacinest-autorizado-enprioridadprivilegioscamb_privilAutorizacin**Clase de asociacinPolgonoPuntocontiene3.. *1{ordenado}Agregacinwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Clases y ObjetosDiagrama de Clases y Diagramas de Objetos pertenecen a dos vistas complementarias del modeloUn Diagrama de Clases muestra la abstraccin de una parte del dominioUn Diagrama de Objetos representa una situacin concreta del dominioLas clases abstractas no son instanciadaswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*GeneralizacinPermite gestionar la complejidad mediante un ordenamiento taxonmico de clasesSe obtiene usando los mecanismos de abstraccin de Generalizacin y/o EspecializacinLa Generalizacin consiste en factorizar las propiedades comunes de un conjunto de clases en una clase ms general



UNPSJB - 2005Ingeniera de Software - Clase 6*... GeneralizacinNombres usados: clase padre - clase hija. Otros nombres: superclase - subclase, clase base - clase derivadaLas subclases heredan propiedades de sus clases padre, es decir, atributos y operaciones (y asociaciones) de la clase padre estn disponibles en sus clases hijasLa Generalizacin y Especializacin son equivalentes en cuanto al resultado: la jerarqua y herencia establecidasGeneralizacin y Especializacin no son operaciones reflexivas ni simtricas pero s transitivaswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*... Generalizacin



UNPSJB - 2005Ingeniera de Software - Clase 6*... GeneralizacinLa especializacin es una tcnica muy eficaz para la extensin y reutilizacin

Restricciones predefinidas en UML: disjunta - no disjuntatotal (completa) - parcial (incompleta)www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*... GeneralizacinLa nocin de clase est prxima a la de conjuntoDada una clase, podemos ver el conjunto relativo a las instancias que posee o bien relativo a las propiedades de la claseGeneralizacin y especializacin expresan relaciones de inclusin entre conjuntosParticionamiento del espacio de objetos => Clasificacin EstticaParticionamiento del espacio de estados de los objetos => Clasificacin DinmicaEn ambos casos se recomienda considerar generalizaciones/especializaciones disjuntaswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*... GeneralizacinUn ejemplo de Clasificacin Esttica:

{ esttica }www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*... GeneralizacinUn ejemplo de Clasificacin Dinmica:

{ dinmica }www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*... GeneralizacinExtensin: Posibles instancias de una claseIntensin: Propiedades definidas en una claseint(A) int(B)

ext(B) ext(A) www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*... GeneralizacinClasificacin Esttica

ext(C0) = ext(Ci) completaext(Ci) ext(Cj) = disjuntaC0C1Cn{ static }www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*... GeneralizacinClasificacin Dinmica

ext(C0) = ext(Ci) completaextt(Ci) extt(Cj) = disjunta en t

extt1(Ci) extt2(Cj) posiblemente no disjunta en diferentes instantesC0C1Cn{ dinmica }www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*... GeneralizacinEjemplo: varias especializaciones a partir de la misma clase padre, usando discriminadores:

Vehculo AreoAvinHelicpteroComercialMilitarestructurausowww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Clasificacin Mltiple (herencia mltiple)Se presenta cuando una subclase tiene ms de una superclaseLa herencia mltiple debe manejarse con precaucin. Algunos problemas son el conflicto de nombre y el conflicto de precedenciaSe recomienda un uso restringido y disciplinado de la herencia. Java y Ada 95 simplemente no ofrecen herencia mltiplewww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Herencia MltipleUso disciplinado de la herencia mltiple: clasificaciones disjuntas con clases padre en hojas de jerarquas alternativasAnimalBpedoCuadrpedoCon PelosCon PlumasCon EscamasHerbvoroCarnvorocuberturacoberturacoberturacomidanro patasnro patascomidaConejowww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Principio de SustitucinEl Principio de Sustitucin de Liskow (1987) afirma que: Debe ser posible utilizar cualquier objeto instancia de una subclase en el lugar de cualquier objeto instancia de su superclase sin que la semntica del programa escrito en los trminos de la superclase se vea afectado.www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Principio de SustitucinDado que los programadores pueden introducir cdigo en las subclases redefiniendo las operaciones, es posible introducir involuntariamente incoherencias que violen el principio de sustitucinEl polimorfismo que veremos a continuacin no debera implementarse sin este principiowww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*PolimorfismoEl trmino polimorfismo se refiere a que una caracterstica de una clase puede tomar varias formasEl polimorfismo representa en nuestro caso la posibilidad de desencadenar operaciones distintas en respuesta a un mismo mensajeCada subclase hereda las operaciones pero tiene la posibilidad de modificar localmente el comportamiento de estas operacioneswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* PolimorfismoEjemplo: todo animal duerme, pero cada clase lo hace de forma distintadormir??www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* PolimorfismoDormir(){en un rbol}Dormir(){sobrela espalda}Dormir(){sobre el vientre}Dormir(){}Animaldormir()Lendormir()Osodormir()Tigredormir()www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* PolimorfismoLa bsqueda automtica del cdigo que en cada momento se va a ejecutar es fruto del enlace dinmicoEl cumplimiento del Principio de Sustitucin permite obtener un comportamiento y diseo coherentewww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama de Estados


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama de EstadosLos Diagramas de Estados representan autmatas de estados finitos, desde el p.d.v. de los estados y las transicionesSon tiles slo para los objetos con un comportamiento significativoEl formalismo utilizado proviene de los Statecharts (Harel)Cada objeto est en un estado en cierto instanteEl estado est caracterizado parcialmente por los valores algunos de los atributos del objeto El estado en el que se encuentra un objeto determina su comportamientoCada objeto sigue el comportamiento descrito en el D. de Estados asociado a su claseLos D. De Estados y escenarios son complementarioswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Diagrama de EstadosLos D. de Estados son autmatas jerrquicos que permiten expresar concurrencia, sincronizacin y jerarquas de objetosLos D. de Estados son grafos dirigidos Los D. De Estados de UML son deterministasLos estados inicial y final estn diferenciados del restoLa transicin entre estados es instantnea y se debe a la ocurrencia de un evento



UNPSJB - 2005Ingeniera de Software - Clase 6* Diagrama de EstadosEstados y Transiciones

ABEvento [condicin] / AccinTanto el evento como la accin se consideran instantneoswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Diagrama de EstadosEjemplo de un Diagrama de Estados para la clase persona:www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*AccionesPodemos especificar la solicitud de un servicio a otro objeto como consecuencia de la transicin:

ABEvento [condicin] / OtroObjeto.Operacinwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* AccionesSe puede especificar el ejecutar una accin como consecuencia de entrar, salir, estar en un estado, o por la ocurrencia de un eventoestado Aentry: accin por entrarexit: accin por salirdo: accin mientras en estadoon evento: accinwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Generalizacin de EstadosPodemos reducir la complejidad de estos diagramas usando la generalizacin de estadosDistinguimos as entre superestado y subestadosUn estado puede contener varios subestados disjuntosLos subestados heredan las variables de estado y las transiciones externaswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Generalizacin de EstadosEjemplo:ABCe1e2e2www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Generalizacin de EstadosQuedara como:CabABe1e2www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Generalizacin de EstadosLas transiciones de entrada deben ir hacia subestados especficos:CabABe1e2e0www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Generalizacin de EstadosEs preferible tener estados iniciales de entrada a un nivel de manera que desde los niveles superiores no se sepa a qu subestado se entra:CabABe1e2e1e0www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Generalizacin de EstadosLa agregacin de estados es la composicin de un estado a partir de varios estados independientesLa composicin es concurrente por lo que el objeto estar en alguno de los estados de cada uno de los subestados concurrenteswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Generalizacin de EstadosEjemplo:www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*HistoriaPor defecto, los autmatas no tienen memoriaEs posible memorizar el ltimo subestado visitado para recuperarlo en una transicin entrante en el superestado que lo englobaTambin es posible la memorizacin para cualquiera de los subestados anidados (aparece un * junto a la H)www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* HistoriaEjemplo:Ad2d1H*BCxyDoutinwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* HistoriaEjemplo:EnjuagueLavadoSecadoHEnjuagueLavadoSecadoHEsperaabir puertacerrar puertawww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Destruccin del ObjetoLa destruccin de un objeto es efectiva cuando el flujo de control del autmata alcanza un estado final no anidadoLa llegada a un estado final anidado implica la subida al superestado asociado, no el fin del objetowww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Destruccin de ObjetoEjemplo:www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Transiciones temporizadasLas esperas son actividades que tienen asociada cierta duracinLa actividad de espera se interrumpe cuando el evento esperado tiene lugarEste evento desencadena una transicin que permite salir del estado que alberga la actividad de espera. El flujo de control se transmite entonces a otro estadowww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Transiciones temporizadasEjemplo:Aesperar dineroentry: Mostrar mensajeexit: cerrar ranuraBanular transaccin / Abrir ranuraDepsito efectuadodespus de30 segundoswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama de ActividadEl Diagrama de Actividad es una especializacin del Diagrama de Estado, organizado respecto de las acciones y usado para especificar:Un mtodoUn caso de usoUn proceso de negocio (Workflow) Las actividades se enlazan por transiciones automticas. Cuando una actividad termina se desencadena el paso a la siguiente actividadwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Ejemplos


UNPSJB - 2005Ingeniera de Software - Clase 6*... Ejemplos


UNPSJB - 2005Ingeniera de Software - Clase 6*... Ejemploswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama de Componentes


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama de ComponentesLos diagramas de componentes describen los elementos fsicos del sistema y sus relacionesMuestran las opciones de realizacin incluyendo cdigo fuente, binario y ejecutableLos componentes representan todos los tipos de elementos software que entran en la fabricacin de aplicaciones informticas. Pueden ser simples archivos, paquetes de Ada, bibliotecas cargadas dinmicamente, etc.Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componentewww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Diagramas de ComponentesEjemplo:www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama de Despliegue


UNPSJB - 2005Ingeniera de Software - Clase 6*Diagrama de DespliegueLos Diagramas de Despliegue muestran la disposicin fsica de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodoswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Diagrama de DespliegueLos estereotipos permiten precisar la naturaleza del equipo:DispositivosProcesadoresMemoriaLos nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparsewww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* Diagrama de DespliegueEjemplo de conexin entre nodos:Terminal Punto de Venta

Base de Datos

Control

Podemos distinguir tipos de nodos y connexiones por estereotipado



UNPSJB - 2005Ingeniera de Software - Clase 6*Proceso de Desarrollo de SW basado en UML


UNPSJB - 2005Ingeniera de Software - Clase 6*Qu es un Proceso de Desarrollo de SW? Define Quin debe hacer Qu, Cundo y Cmo debe hacerlo

No existe un proceso de software universal. Las caractersticas de cada proyecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurableRequisitos nuevoso modificadosSistema nuevoo modificadoProceso de Desarrollo de Softwarewww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Historia de RUP Pruebas funcionalesPruebas de desempeoGestin de requisitosGestin de cambios y configuracinIngeniera de NegocioIngeniera de datosDiseo de interfacesRational Unified Process1998Rational Objectory Process1996-1997Objectory Process1987-1995Enfoque EricssonUMLwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Dos dimensioneswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Fases e Hitos (Milestones)tiempoObjetivos(Vision)

Arquitectura

CapacidadOperacionalInicial

Releasedel ProductoInceptionElaborationConstructionTransitionwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Elementos en RUP Workflows (Disciplinas)Workflows Primarios Business Modeling (Modado del Negocio) Requirements (Requisitos)Analysis & Design (Anlisis y Diseo)Implementation (Implementacin)Test (Pruebas)Deployment (Despliegue)Workflows de ApoyoEnvironment (Entorno)Project Management (Gestin del Proyecto)Configuration & Change Management (Gestin de Configuracin y Cambios)www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*... Elementos en RUP Workflow, Workflow Detail , Workers, Actividades y Artefactos. EjemplosWorkflow Detail:Analyse the ProblemWorkflow: Requirementswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*... Elementos en RUP Workers Analyst workersBusiness-Process Analyst Business DesignerBusiness-Model Reviewer Requirements ReviewerSystem AnalystUse-Case Specifier User-Interface DesignerDeveloper workersArchitectArchitecture Reviewer Capsule DesignerCode ReviewerDatabase Designer Design ReviewerDesignerImplementer IntegratorTesting professional workersTest DesignerTesterManager workers Change Control Manager Configuration ManagerDeployment ManagerProcess EngineerProject ManagerProject ReviewerOther workersAny WorkerCourse Developer Graphic ArtistStakeholderSystem AdministratorTechnical WriterTool Specialist



UNPSJB - 2005Ingeniera de Software - Clase 6*... Elementos en RUP Workers, Actividades, Artefactos Ejemplo: System Analyst Worker



UNPSJB - 2005Ingeniera de Software - Clase 6*... Elementos en RUP Artefactos Resultado parcial o final que es producido y usado durante el proyecto. Son las entradas y salidas de las actividadesUn artefacto puede ser un documento, un modelo o un elemento de modeloConjuntos de ArtefactosBusiness Modeling SetRequirements SetAnalysis & Design SetImplementation SetTest SetDeployment SetProject Management SetConfiguration & Change Management SetEnvironment Setwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*... Elementos en RUP Artefactos, Workers, ActividadesEjemplo:Business Modeling Artifact Set



UNPSJB - 2005Ingeniera de Software - Clase 6*Caractersticas Esenciales de RUP Proceso Dirigido por los Casos de UsoProceso Iterativo e IncrementalProceso Centrado en la Arquitectura



UNPSJB - 2005Ingeniera de Software - Clase 6*RequisitosCapturar, definir y validar los casos de usoRealizar los casos de usoVerificar que se satisfacen los casos de usoAnlisis & DiseoImplementacinPruebas

Casos de Usointegran eltrabajo

Proceso dirigido por los Casos de Usowww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Caso de UsoRealizacin de AnlisisRealizacin de DiseoCaso de PruebaXtracetracetracetracePruebas FuncionalesPruebasUnitarias[The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999] ... Proceso dirigido por los Casos de Usowww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*..Proceso dirigido por los casos de Usowww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Proceso Iterativo e IncrementalEl ciclo de vida iterativo se basa en la evolucin de prototipos ejecutables que se muestran a los usuarios y clientesEn el ciclo de vida iterativo a cada iteracin se reproduce el ciclo de vida en cascada a menor escalaLos objetivos de una iteracin se establecen en funcin de la evaluacin de las iteraciones precedenteswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*... Proceso Iterativo e IncrementalLas actividades se encadenan en una mini-cascada con un alcance limitado por los objetivos de la iteracinn veceswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*... Proceso Iterativo e IncrementalCada iteracin comprende:Planificar la iteracin (estudio de riesgos)Anlisis de los Casos de Uso y escenariosDiseo de opciones arquitectnicasCodificacin y pruebas. La integracin del nuevo cdigo con el existente de iteraciones anteriores se hace gradualmente durante la construccinEvaluacin de la entrega ejecutable (evaluacin del prototipo en funcin de las pruebas y de los criterios definidos)Preparacin de la entrega (documentacin e instalacin del prototipo)www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Proceso Iterativo e IncrementalEnfoqueCascadaEnfoqueIterativo eIncrementalwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Grado de Finalizacin de Artefactos... Proceso Iterativo e Incrementalwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Proceso Centrado en la Arquitectura Arquitectura de un sistema es la organizacin o estructura de sus partes ms relevantesUn arquitectura ejecutable es una implementacin parcial del sistema, construida para demostrar algunas funciones y propiedadesRUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivoInceptionElaborationConstructionTransitionwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Fases del Ciclo de VidaEl ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versin del productoCada ciclo est compuesto por fases y cada una de estas fases est compuesta por un nmero de iteracionesLas fases son:Inicio o Estudio de oportunidadElaboracinConstruccinTransicin www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*...Fases del Ciclo de VidaInicio o Estudio de oportunidad (inception)Define el mbito y objetivos del proyectoSe define la funcionalidad y capacidades del productoElaboracinTanto la funcionalidad como el dominio del problema se estudian en profundidadSe define una arquitectura bsicaSe planifica el proyecto considerando recursos disponibleswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*...Fases del Ciclo de VidaConstruccinEl producto se desarrolla a travs de iteraciones donde cada iteracin involucra tareas de anlisis, diseo e implementacinLas fases de estudio y anlisis slo dieron una arquitectura bsica que es aqu refinada de manera incremental conforme se construye (se permiten cambios en la estructura)Gran parte del trabajo es programacin y pruebasSe documenta tanto el sistema construido como el manejo del mismoEsta fase proporciona un producto construido junto con la documentacinwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*...Fases del Ciclo de VidaTransicinSe libera el producto y se entrega al usuario para un uso realSe incluyen tareas de marketing, empaquetado atractivo, instalacin, configuracin, entrenamiento, soporte, mantenimiento, etc.Los manuales de usuario se completan y refinan con la informacin anteriorEstas tareas se realizan tambin en iteracioneswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Esfuerzo respecto de las Workflows15%10%15%30%15%10% gestin cambios5% mantenimientoUna iteracin en lafase de elaboracinRequisitosDiseoImplementacinPruebasAnlisis


UNPSJB - 2005Ingeniera de Software - Clase 6*...Esfuerzo respecto de las FasesEsfuerzo: 5%20% 65% 10%Duracin: 10%30% 50% 10%Una iteracin en lafase de elaboracinRequisitosDiseoImplementacinPruebasAnlisis


UNPSJB - 2005Ingeniera de Software - Clase 6*UML - ANEXOFundamentos del Modelado OOPara evaluacin por parte de los alumnos


UNPSJB - 2005Ingeniera de Software - Clase 6*ObjetosObjeto = unidad atmica que encapsula estado y comportamiento

La encapsulacin en un objeto permite una alta cohesin y un bajo acoplamiento

Un objeto puede caracterizar una entidad fsica (coche) o abstracta (ecuacin matemtica)www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* ObjetosEl Modelado de Objetos permite representar el ciclo de vida de los objetos a travs de sus interaccionesEn UML, un objeto se representa por un rectngulo con un nombre subrayadowww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* ObjetosEjemplo de varios objetos relacionados:www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* ObjetosObjeto = Identidad + Estado + ComportamientoEl estado est representado por los valores de los atributosUn atributo toma un valor en un dominio concretowww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Clases y Objetoswww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Identidad

Oid (Object Identifier)Cada objeto posee un oid. El oid establece la identidad del objeto y tiene las siguientes caractersticas: Constituye un identificador nico y global para cada objeto dentro del sistema

Es determinado en el momento de la creacin del objeto

Es independiente de la localizacin fsica del objeto, es decir, provee completa independencia de localizacinwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*

Es independiente de las propiedades del objeto, lo cual implica independencia de valor y de estructuraNo cambia durante toda la vida del objeto. Adems, un oid no se reutiliza aunque el objeto deje de existirNo se tiene ningn control sobre los oids y su manipulacin resulta transparenteSin embargo, es preciso contar con algn medio para hacer referencia a un objeto utilizando referencias del dominio (valores de atributos) Identidadwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*EstadoEl estado evoluciona con el tiempoAlgunos atributos pueden ser constantesEl comportamiento agrupa las competencias de un objeto y describe las acciones y reacciones de ese objetoLas operaciones de un objeto son consecuencia de un estmulo externo representado como mensaje enviado desde otro objetowww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*ComportamientoEjemplo de interaccin:www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* ComportamientoLos mensajes navegan por los enlaces, a priori en ambas direcciones

Estado y comportamiento estn relacionados

Ejemplo: no es posible aterrizar un avin si no est volando. Est volando como consecuencia de haber despegado del suelowww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*PersistenciaLa persistencia de los objetos designa la capacidad de un objeto trascender en el espacio/tiempo

Podremos despus reconstruirlo, es decir, tomarlo de memoria secundaria para utilizarlo en la ejecucin (materializacin del objeto)

Los lenguajes OO no proponen soporte adecuado para la persistencia, la cual debera ser transparente, un objeto existe desde su creacin hasta que se destruyawww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*ComunicacinUn sistema informtico puede verse como un conjunto de objetos autnomos y concurrentes que trabajan de manera coordinada en la consecucin de un fin especfico

El comportamiento global se basa pues en la comunicacin entre los objetos que la componenwww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* ComunicacinCategoras de objetos:Activos - PasivosCliente Servidores, AgentesObjeto Activo: posee un hilo de ejecucin (thread) propio y puede iniciar una actividadObjeto Pasivo: no puede iniciar una actividad pero puede enviar estmulos una vez que se le solicita un servicioCliente es el objeto que solicita un servicio. Servidor es el objeto que provee el servicio solicitadoIII. El Paradigma OO: Fundamentos de Modelado OO


UNPSJB - 2005Ingeniera de Software - Clase 6* ComunicacinLos agentes renen las caractersticas de clientes y servidoresSon la base del mecanismo de delegacinIntroducen indireccin: un cliente puede comunicarse con un servidor que no conoce directamentewww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6* ComunicacinEjemplo en el que un agente hace de aislante:Un agente Un cliente Sevidor 1 Servidor 2 www.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*El Concepto de MensajeLa unidad de comunicacin entre objetos se llama mensajeEl mensaje es el soporte de una comunicacin que vincula dinmicamente los objetos que fueron separados previamente en el proceso de descomposicinAdquiere toda su fuerza cuando se asocia al polimorfismo y al enlace dinmico



UNPSJB - 2005Ingeniera de Software - Clase 6* El Concepto de MensajeObjeto 4Objeto 3Objeto 2Objeto 1: Mensaje E: Mensaje D: Mensaje C: Mensaje Awww.dsic.upv.es/~uml


UNPSJB - 2005Ingeniera de Software - Clase 6*Mensaje y EstmuloUn estmulo causar la invocacin de una operacin, la creacin o destruccin de un objeto o la aparicin de una sealUn mensaje es la especificacin de un estmuloTipos de flujo de control:Llamada a procedimiento o flujo de control anidadoFlujo de control planoRetorno de una llamada a procedimientoOtras variacionesEsperado (balking)Cronometrado (time-out)www.dsic.upv.es/~uml


Figura Triangle for Success adaptada desde Visual Modeling with Rational Rose and UML de Terry Quatrani

9Documento OMG Unified Language Specification, (versin 1.3, 808 pginas, 8 de Julio de 1999 y versin 1.4, 582 pginas, 1 de Noviembre de 2000)ResumenSemntica (185 pginas)Gua de Notacin (173 pginas)Profiles EstndaresDefinicin de Interfaz CORBAfacilityEspecificacin DTD de XMIEspecificacin del Object Constraint LanguageElementos Estndar de UMLGlosario de Modelado del OMG

Stereotype = EstereotipoConstraint = Restriccin de IntegridadTagged Values = Valores Etiquetados, es un par (nombre propiedad, valor)

Los mecanismos de extensin pueden usarse para:Aadir nuevos elementos de modelado sin crear nuevos smbolos. En este caso el smbolo existente estar etiquetado con el correspondiente estereotipo. Esto permite que el metamodelo de UML no se vea alterado.Definir extensiones necesarias en un proceso de desarrollo o lenguaje de implementacin especfico.Asignar una semntica particular o informacin no semntica a elementos de modelado. Las restricciones de integridad pueden escribirse usando un lenguaje especfico para representar restricciones (tal como OCL, Object Constraint Language, que expresa restricciones mediante frmulas bien formadas, desarrollado por IBM) u otros lenguajes (por ejemplo, un determinado lenguaje de programacin) o incluso en lenguaje natural.

Tipos de enfoques: no-formales, semi-formales y formalesLas principales mejoras al utilizar mtodos formales son: Mayor rigor en la especificacin Mejores condiciones para realizar la verificacin y validacin Mejores condiciones para automatizacin de procesos para la generacin automtica de prototipos y/o cdigo final

El Diagrama de Objetos en realidad no se provee como un tipo de diagrama separado. En Diagramas de Secuencia, Diagramas de Colaboracin y en Diagramas de Actividad se modelan objetos. He visto en algunos libros referirse a Diagramas de Paquetes, Diagramas de Subsistemas y Diagramas de Modelos. Sin embargo, stos corresponden a casos particulares de los diagramas arriba mencionados, cuando en stos slo se incluye paquetes (o subsistemas, o modelos, respectivamente).OJO tratar de explicar desde algn lado....Cada Caso de Uso puede estar definido por:

texto que lo describesecuencia de pasos (flujo de eventos) ejecutados dentro del caso de usoprecondiciones y postcondiciones para que el caso de uso comience o terminemezclando las anteriores

En los D. de Casos de Uso no existe el concepto de explosin tal como se tiene en los DFDs (Diagramas de Flujo de Datos). La funcionalidad representada por un caso de uso es atmica (aunque en Rational Rose 98 a un caso de uso se le puede asociar un nuevo D. de Casos de Uso!!). En UML el concepto de paquete permite organizar de manera jerrquica un modelo, y en este caso, un paquete puede tener asociado un nuevo diagrama.

En UML 1.3 se disponen de tres tipos de relaciones entre casos de uso, representadas por un smbolo de generalizacin desde un caso de uso a otro. Los tipos de relacin son: Inclusin (con el estereotipo ), Extensin (con el estereotipo ) y Generalizacin (sin estereotipo).

En UML 1.3 se utiliza el estereotipo en lugar de .

Ms adelante, cuando se entre en detalles de los D. de Casos de Uso se abordarn con ms detalle las relaciones entre casos de uso.

Los Diagramas de Secuencia y de Colaboracin son usados para describir grficamente un caso de uso o un escenario

Un Diagrama de Secuencia muestra los objetos de un escenario mediante lneas verticales y los mensajes entre objetos como flechas conectando objetos

Los mensajes son dibujados cronolgicamente desde arriba hacia abajoLos rectngulos en las lneas verticales representan los periodos de actividad de los objetos.

El Diagrama de Colaboracin modela la interaccin entre los objetos de un Caso de Uso

Los objetos estn conectados por enlaces (links) en los cuales se representan los mensajes enviados acompaados de una flecha que indica su direccin

El Diagrama de Colaboracin ofrece una mejor visin del escenario cuando el analista est intentando comprender la participacin de un objeto en el sistema

El Diagrama de Estados modela el comportamiento de una parte del sistema

Tpicamente se elabora un diagrama de Estados para cada clase que tenga un comportamiento significativo

El comportamiento es modelado en trminos del estado en el cual se encuentra el objeto, qu acciones se ejecutan en cada estado y cul es el estado al que transita despus de un determinado evento

Caso especial de Diagrama de Estados donde:Todos (o la mayora de) los estados son estados de accinTodas (la mayora de) las transiciones son disparadas como consecuencia de la finalizacin de la la accin. El Diagrama de Actividades puede especificar:El comportamiento de los objetos de una claseLa lgica de una operacin (mtodo)Parte o toda la descripcin de un Caso de usoLa descripcin de un Flujo de Trabajo

Un diagrama de Componentes permite modelar la estructura del software y la dependencia entre componentes

Un componente es un grupo de clases que trabajan estrechamente. Los componentes pueden corresponder cdigo fuente, binario o ejecutable

Una relacin de dependencia indica que un componente utiliza otro, por lo cual depende de l

El Diagrama de Distribucin modela la distribucin en tiempo de ejecucin de los elementos de procesamiento y componentes de software, junto a los procesos y objetos asociados

En el Diagrama de Distribucin se modelan los nodos y la comunicacin entre ellos

Cada nodo puede contener instancias de componentes

Para mayores detalles respecto de estos problemas consultar:Real-Life Object-Oriented Systems, Soren Lauesen, IEEE Software March/April 1998.Algunas similitudes y diferencias entre DFDs y D. de Casos de Uso:Un caso de uso es una funcin (servicio o transaccin) atmica ofrecida por el sistema al entorno (actores), mientras que un proceso de un DFD puede ser detallado en un DFD hijo. As, el concepto de explosin de proceso slo se aplica a los DFDs. Aunque en cierta forma con relaciones de inclusin entre casos de uso (que se explican ms adelante) puede mostrarse la factorizacin de un caso de uso, esto no llega a ser equivalente a explosin de proceso.Aunque un caso de uso y un proceso modelan una pieza de funcionalidad del sistema su especificacin es diferente. En un caso de uso interesa expresar la funcionalidad mediante la interaccin (pasos de comunicacin) actor(es) sistema. En un proceso la funcionalidad se expresa mediante la transformacin que se hace de los flujos de entrada para producir flujos de salida.Un caso de uso en general no modela un particionamiento (o detalle) funcional interno del sistema pues se concibe desde la perspectiva de los actores, es decir una visin externa del sistema. La excepcin a lo anterior podra producirse al factorizar funcionalmente un caso de uso para establecer una relacin de inclusin (que se explica ms adelante). Un DFD, segn sea el nivel de detalle, puede mostrar descomposicin funcional interna del sistema.La diferencia entre Captura de Requisitos y Anlisis radica esencialmente en el grado de detalle que se obtiene respecto del particionamiento del problema (funcional y de datos). La Captura de Requisitos ofrece un particionamiento en el contexto del usuario y adecuado para su comprensin. El Anlisis provee un particionamiento que pueda ser utilizado como entrada para el Diseo del Sistema. As, se puede afirmar que los D. de Casos de Uso son una herramienta exclusivamente de Captura de Requisitos mientras que los DFD podran utilizarse en ambas actividades. En captura de requisitos para un DFD una entidad externa equivale a un actor, un almacn nico y global evita entrar en anlisis de datos y los procesos establecidos slo hasta el nivel de transacciones externas se corresponderan con casos de uso.Las relaciones de extensin y de generalizacin entre casos de uso no tienen correspondencias en los DFDs....Una caracterstica resaltada respecto de un proceso de desarrollo de software asociado a UML es su naturaleza use case driven, es decir, el proceso es dirigido por los casos de uso. Esto significa que en puntos determinado del desarrollo se valida y verifica el correspondiente modelo respecto del modelo de casos de uso. En s la especificaciones de casos de uso (con los respectivos diagramas de interaccin) constituyen una especificacin de casos de prueba para el sistema (pruebas funcionales).Para la explicacin de las relaciones entre casos de uso se han identificado como caso de uso origen y caso de uso destino slo para indicar el sentido del smbolo (flecha de generalizacin).

Las relaciones y corresponden ambas a factorizaciones del comportamiento de un caso de uso, es decir, el caso de uso incluido y el caso de uso que extiende representan un fragmento de interaccin de otro caso de uso. Sin embargo, la intensin es diferente; la relacin pretende evitar duplicacin de interacciones en distintos casos de uso, la relacin pretende describir una variacin del comportamiento normal de un caso de uso, sobre todo cuando dicha variacin pudiera complicar la legibilidad del caso de uso.En el documento UML no se proporcionan reglas especficas respecto de las modificaciones y ampliaciones posibles en el caso de uso hijo. Lo intuitivo es pensar que un caso de uso obtenido por especializacin tiene en principio los mismos pasos de interaccin que el caso de uso padre pero que puede insertar nuevos y/o reescribir los pasos heredados.

Podra en este ejemplo haberse modelado el caso de uso Transferencia por Internet con una relacin de generalizacin hacia el caso de uso Transferencia?. Si la idea de extensin (vista como especializacin) forma parte esencial del concepto de generalizacin/especializacin, para qu tener dos tipos de relaciones? ... estos son algunos de lo muchos aspectos de UML que estn en discusin.Esta es una posible plantilla para utilizar al especificar un caso de uso (obtenida desde http://www.lsi.us.es/~amador/publicaciones/lsi-2000-10.pdf.zip)Casos de Uso a fondo, en la pgina de Alistair Cockburn, http://members.aol.com/acockburnPredecesor es una lista separada por coma de los nmeros de secuencia de mensajes que deben ocurrir antes del mensaje especificado. La guarda representa una condicin para el envo del mensajeSecuencia representa el nivel de anidamiento procedural. Por ejemplo el mensaje 3.1.4 es posterior al mensaje 3.1.3 dentro de la activacin 3.1. Tambin se pueden aadir nombres para especificar mensajes concurrente, por ejemplo, el mensaje 3.1a y el mensaje 3.1b son concurrentes dentro de la activacin 3.1. Adems se puede incluir una especificacin de iteracin de la forma *[i:=0 1..n] para representar el envo de una secuencia de mensajes o *||[i:=0..n] para indicar que el envo es en paralelo.Ejemplos:2: mostrar(x,y)mensaje simple1.3.1: p: = encontrar(espec)llamada anidada con valor de retorno[x

clase6

Documents