introduccionuml

44
1 2005 Introducción a UML ANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN Unified Modeling Language - UML UML es presentado como un lenguage de modelado para Visualizar Especificar Construir Documentar básicamente los componentes de un sistema de información computacional.

Upload: patrier

Post on 18-Aug-2015

214 views

Category:

Documents


0 download

DESCRIPTION

Introducción a UML. Sistemas

TRANSCRIPT

12005Introduccin a UMLANLISIS Y DISEO DE SISTEMAS DE INFORMACINUnified Modeling Language - UMLUML es presentado como un lenguage de modeladopara Visualizar Especificar Construir Documentarbsicamente los componentes deunsistema de informacin computacional.2UML definevariosmodelosbsicosparalarepresentacin del modelo del sistema: el modelo de clases que captura la estructura esttica; elmodelodeestados queexpresaelcomportamiento dinmico de los objetos; elmodelodecasosdeuso quedescribelasnecesidades del usuario; el modelo de interaccin que representa los escenarios y flujos de mensajes; elmodelodeimplementacin quemuestralasunidades de trabajo; elmodelodedespliegue queprecisalaformaenquese distribuyen los procesos.Elmodelodelsistema esvistoymanipuladopormediode vistas, que consisten en proyecciones a travs de los elementos de modelado.Puedenconstruirsenumerosasvistas apartirdelos modelosbsicos,mostrandolatotalidad oparte delos modelos.Lasvistassonexpresadasatravsdelosdiagramas,que consistenenrepresentacionesgrficas,usualmentegrafosque vinculan los elementos del modelo. UML define nueve tipos de diagramas:1. de clases 2. de secuencia 3. de colaboracin4. de objetos 5. de transicin de estados6. de casos de uso 7. de actividades 8. de componentes 9. de despliegue3ModeloClase Personavista ..........DCU8DC5DCU9diagramasDS1DC2DCU1vista de usuariosvista de diseoDS3DC7DCU4El vocabulario y las reglas de un lenguaje como UML indican como crear y leer modelos bien formulados, aunque no indican que y cuandolos modelos deben ser creados.El vocabulario de UML est compuesto de tres elementos bsicos: entidades relaciones diagramas4UML posee cuatro tipos de entidades: estructurales, que representan la estructura del modelo comportamiento, que representan aspectos dinmicos agrupamientos, representan conjuntos de los otros elementos del lenguaje descriptores, expresan comentarios asociados a los componentes del modeloEntidades Estructurales Clases Interfaces Colaboraciones Casos de uso Componentes (representa una parte fsica del sistema) Nodos (representan elementos fsicos qu existen en tiempo de ejecucin, y generalmente poseen memoria o capacida de procesamiento)5 Cada clase debe tener un nombre nico. Un atributo expresa una propiedad particular de una clase. Una operacin refleja un servicio del objeto en el sistema. Una clase puede implementar una o ms interfaces

atributo1:atributo2:..........operacin1:operacin2:operacin3:..........CLASESson la descripcin de un conjunto de objetos que comparten losmismos atributos, operaciones, relaciones y semnticaEl nombre de las clases abstractas se escribe en tipo cursivoes unconjutno deoperaciones que especifican los servicios quepuede brindar una clase o componente.

INTERFAZUna interfaz describe el comportamiento visible desde el exteriorde una entidad. Una Interfaz: debe tener un nombre nico. puede describir el comportamiento completo o parcialde una clase. define un conjunto de especificaciones de operaciones, nunca sus implementaciones.6COLABORACINdefine una interaccin y una sociedad de roles y otros elementos quetrabajan en conjunto proveyendo un comportamiento cooperativo.

Unacolaboracin se describe a travs de una dimensin esttica y otra dinmica.

Diagrama de SecuenciasDiagrama de ClasesRELACIONESLas relaciones expresan: unvnculo semntico entre lasclases.Organizacin Departamentocompuesto-por1...* el hecho que las clases estnvinculadas de alguna manera.Vendedor Clienteconfecciona1...*ClienteatiendeLa identificacin de relaciones permite reconocer la manera en que colaboran los distintos objetos en el dominio.Una relacin es la abstraccin de una asociacin entreinstancias de objetos.7En UML existen cuatro tipo de relaciones: Asociacin Dependencia Generalizacin RealizacinAsociacinGeneralizacinRealizacinDependenciaASOCIACINUnaasociacin conecta dos clases yrefleja elhecho quelas mismas estnrelacionadas eneldominiode aplicacin.Empresa Empleadotrabaja-enGerentedireccinLasrelaciones no necesariamente deben estaretiquetadas con un nombreEmpresa ClienteProveedorcompra8ASOCIACINLas asociaciones son inherntemente bidireccionales: el sentido de lectura lo da el nombre, pero la relacin es vlida en ambos sentidos. Empresa PersonaempleadoEmpresa Personatrabaja-enSe puede agregar una punta de flecha que indica en que direccindebe ser ledo el nombre de la relacinASOCIACINEl sentido de lectura elegido durante esta etapa no implicadecisiones de diseo.Proceso Compuestomateria primaproduceUna clase puede tener una asociacin a s misma (asociacinreflexiva). Empresa Empresaproveedorcliente9ASOCIACINEsposible tener ms deuna asociacin entre el mismo par de clasesPersona EmpresaempleadoentrevistaAvin AeropuertoarribadespegaPersona ClubmiembropresidenteASOCIACINLacardinalidad deuna asociacin indica elnmero de instancias deuna clase que pueden relacionarse conuna nicainstancia de la clase asociadaCardinalidad Descripcin1 Exactamente uno* Cantidad ilimitada0 .. * Cero o ms1 .. * Uno o ms0 .. 1 Cero o uno2 .. 6 Rango especfico2 .. 6, 10 Rango especfico o nmero exacto10ASOCIACINCardinalidadAeropuerto Avinarribadespega110..*0..*UnAvinarriba enexactamenteunAeropuerto.Aun Aeropuerto arriban varios Aviones (cero si est cerrado).ASOCIACINCardinalidadEditorialAutorIndiceLibro11..*1..*1..*11Captulo1111..*1..*1..*111..*1Unlibro tiene varios captulos,uncaptulo pertenece aunslolibro. Cada libro tiene un ndice, el cual pertenece a un nico libro. Un libro puede tener mltiples personas como autores y, a su vez, una persona puede ser autor de diferentes libros. 11ASOCIACINLa cardinalidad pone de manifiesto suposiciones acerca del dominio de aplicacin. *1Empleado Empresa*1ContratoNo interesa que la misma represente una Verdad Universal para los ObjetosRelacionados. Slo debe representar lo que se verifica en el dominio modeladoCurso Estudiante1..*0..*1..*0..*MatriculaLa relacin Matrcula no requiere que un Estudiante est relacionado con un Curso. Este hecho puede ser diferente en otro contexto en el cual un Estudiantepierde su condicin si no est registrado en un Curso, lo cual se representara de la siguiente forma:1..*1..*Curso Estudiante1..*1..*MatriculaRoles de un objetoEl rol de un objeto indica el papel que juega un objeto en su relacincon otros objetos. Un rol representa un comportamiento de una entidad participando en un contexto dado.ContratoEmpleado Empresa1..** +contratado+contratante*1..* Los nombres de roles enriquecen la semntica de unarelacin. Los nombres de roles son opcionales y aparecen comosustantivos. El nombre de un rol es escrito cerca de la clase a la cualcalifica.12AGREGACINUna Asociacin entre dos clases representa una relacin estructuralentre pares.En ciertos casos es necesario modelar relacin del tipo "todo/parte", en la cual una clase representa el todo y la otra clase la parte.DepartamentoEmpresa1*1*Representa el Todo (contenedor)LaAgregacin simplees slo conceptualyslo distingue eltodo dela parte.No realiza ninguna vinculacin acerca delcilo devida delas clasesvinculadas .AGREGACIN(una variacin de Agregacin)Composicin expresa una relacin de pertenencia y asocia los ciclos de vida del todo y la parte.FacultadDepartamento1..*111..*LasPartes conmultiplicidad variablepuedensercreadas luego que el todo,sinembargo,una vez creadas nopodrn persistir si eltododesaparece.En una Composicin el todo es responsable de la vida de sus partes, lo cual quiere decir que deber administrar su creacin y destruccin.13DepartamentoEstudiante Facultad1..*11..*10..*1..*0..*1..* Las relaciones entre Facultad y Estudiante, Facultad y Departamentoson claramente diferentes. Una facultad tiene cerooms estudiantes,yunestudiante estregistrado en una o ms facultades. Una facultad posee uno oms departamentos.Cada departamentoest asociado a exactamente una sola facultad.Se podra haber modelado el sistema con Asociaciones simples. Sin embargo elempleo derelaciones Agregacin representan que Facultad esorganizacionalmente superior a Departamento y Estudiante.ASOCIACIONES COMO CLASESSurgen cuando las caractersticas a representar se originan como consecuencia de la relacin entre dos objetos.Estas propiedades se representan a travs de un nuevo objeto cuyaexistencia y significado depende de los dos objetos vinculados.Una asociacin como clase se representa como unaclase asociada a la relacin a travs de una relacincon lnea punteada.Persona Empresa * 1..* * 1..*PuestoInicioSalarioDescripcin14GENERALIZACINRelacintaxonmicaentreunelementomsgeneralyotro msespecfico.Elelementomsespecficoes completamenteconsistenteconelmsgeneralycontiene informacin adicional.Una instancia del elemento ms especfico puede ser empleado donde el elemento ms general es permitido.UnarelacindeGeneralizacinesunarelacindirigida entre dos elementos del mismo tipo ().FiguraCirculo Elipse LineasuperclasesubclasegeneralizacinGENERALIZACINUnaRestriccin puedeseraplicadaaunconjuntode relacionesdegeneralizacinyloshijosquecompartenun padre en comn. Se pueden especificar las siguientes propiedades: disjoint:ningunainstanciapuedesersimultneamente instancia de ms de uno de los hijos. overlapping:unainstanciapuedeserinstanciadeunoo ms hijos complete:todosloshijoshansidoenumeradosynose pueden adicionar ms incomplete: inversa de completeFiguraCirculo Elipse Lineasuperclase{disjoint,incomplete}15DEPENDENCIADependencia es una relacin utilizada para representar que un cambio en la especificacin de una de las clases participantes, puede afectar a la otra clase que hace uso de ella.PlandeCurs osadicionar(c : Curs o)eliminar(c : Curso)Curs oPlandeCursos depende de Curso,debido aque Curso esempleado por las operaciones adicionar y eliminar.REALIZACINRelacin entreunaespecificacin ysuimplementacin;una indicacindelaherenciadecomportamientosinlaherenciade estructura. Especificacin:describeelcomportamiento dealgosindeterminar como ser implementado el comportamiento. Implementacin: provee los detalles acerca de como implementar el comportamiento(puedenexistirmltiplesimplementacionespara una especificacin).BloqueEleccionessetDefault()getChoice()

MenuPopUpsetDefault()getChoice()ArregloBotonessetDefault()getChoice()ImplementacionesEspecificacinrealizacin16DIAGRAMA DE CLASESRepresenta una vista esttica del sistemaMuestra la existencia de clases y sus relacionesEspecifica los atributos yresponsabilidades delasentidades que proveen el comportamiento de un sistemaEst compuesto por (como mnimo):Clases.InterfacesColaboracionesRelaciones entre clases.OtorgamientoReclamoInternoExpedienteTitularTemaNmeroEstadoFechaInicioInicio()Transferir()Finalizar()Archivar()es-unes-unes-unOficinaUbicacinClienteBeneficioSolicitudFamil iarEmpleadoTrmiteIntegranteNomnbreApellido1 : StringApellido2 : StringNombre1 : StringNombre2 : StringNombre3 : StringPersonaNombreDireccinCiudadFechaNacDocumentoTipoDocumentoNumIncorporar()ActualizarFam()CalcularHaber()AsociacinGeneralizacinClaseOperacionesNombreComposicinAtributosDiagrama de Clases17Unpaquete encapsulaunconjuntodeelementos empleados en el modelo (clases, relaciones, paquetes, etc).Un paquete es un mecanismo de propsito general empleado paraadministrarlacomplejidaddeunmodelo,mediantesu descomposicin en grupos de elementos.PAQUETE (Package)Un paquete se emplea para:agruparymanipularenconjuntoelementosdel modelocontrolar la visibilidad de los elementos contenidospresentardiferentesvistasdelaarquitecturadel sistemaUnpaquete biendiseadoagrupaelementoscon semnticasrelacionadasyquesuelensufrircambiosen conjunto.18Cliente+ FormOrden# Orden- FormSeguimientoPAQUETEElnombrecompleto deloselementosincluidosenunpaquete,incluye el nombre del paquete en el cual estn contenidoCliente::OrdenUnpaquete puedecontener:clases,interfaces,componentes, colaboraciones, casos de uso, diagramas y otros paquetes.Si el paquete se destruye, su contenido tambin. Todo elemento es posedo por un nico paquete.Unpaquetedefineunespaciodenombres,esdecir,los elementos dentro del paquete deben poseer nombres nicos.Pueden existir elementos del mismo tipo, con el mismo nombre, pero definidos en diferentes paquetes.Cliente::Port Servidor::PortUnpaquete poseeunnombrequelo distingue del resto de los paquetes.VISIBILIDADLavisibilidaddeloselementosqueposeeunpaquete sepuede establecerdelamismaformaquesehaceconlosatributosy operaciones de una clase.noesvisible desdefueradelpaquete en que fue declaradoprivado#esvisibleslo desdeloshijos delpaquetecontenedorprotegido-es visible desde los elementos contenidos de cualquierpaquete queimporte los elementos del paquete contenedorpblico+La parte pblica del package constituye su interface.Cliente+ FormOrden# Orden- FormSeguimiento19IMPORTACIN Y EXPORTACIN ENTRE PAQUETESLa importacin brinda permiso en un sentido para que elementos de un paquete puedan acceder elementos de otro paquete.Cliente+ FormOrden+ FormSeguimientoOrdenServidor+ BasedeDatos+ ServiciosdeLoggingPolticas+ ReglasOrdenGUI+ Window+ FormEventHandler

Elementos exportablesEnUMLlarelacindeimportacinentrepaquetes semodelacomouna dependencia, etiquetada con Agrupandolasabstraccionesdelmodeloenconjuntos significativos(mediantepaquetes),ycontrolandoluegoel accesoalosmismosmediantelaimportacin,esposible controlar la complejidad de modelos de gran dimensinIMPORTACIN Y EXPORTACIN ENTRE PAQUETESExportacinLoselementospblicosdeunpaquete constituyensuparte exportable.Esdecir,accesiblesmedianterelaciones .Loselementosqueunpaquete exporta sonvisibles solamenteaaquellospaquetes vinculadosmedianteuna relacin .La relacin no es transitiva20Manejo de OrdenesAlmacenamiento ExternoUIProcesamiento de OrdenesCalculo de Precios1. Lospaquetescontenidos tieneaccesodirectoacualquier elementodelpaquetecontenedor, sinnecesidadderelacin orestriccindevisibilidad.Estovaleparacualquier nivel de contenido.2. El paquete contenedor requiere una relacin con el paquete contenido.VISIBILIDAD ENTRE PAQUETES CONTENIDOSManejo de Ordenes solo ve UITodos los paquetes ven OrdenOrdenGENERALIZACIONLageneralizacin entrepaquetes essemejanteala generalizacin entre clases. El paquete especializado: hereda loselementospblicosy protegidosdel paquete ms general puede reemplazar y agregar nuevos elementosAlmacenamiento ExternoDiscosFijosRemoviblesPaquete generalPaquete especializado21EMPLEO DE PAQUETESEl empleo ms usual del concepto de paquete, es para agrupar un cierto nmero de elementos del modelo, de forma tal que puedan ser manipulados y referenciados como un conjunto.Por que usar un paquete y no una clase?LaraznesquelasClases sonabstraccionesdecosas queexistenenelproblemaolasolucin;mientrasque unpaquete esunmecanismoparaorganizarlos elementos en el modelo.Lospaquetes notendrnexistenciaenelsistema;las clases existirnenelsistema(lasclases poseen instancias que son elementos del sistema ejecutable).Lospaquetes sepuedenemplearparaagruparelementos delmodelodeacuerdoadiferentescriterios:similaridad, relacin funcional, representacin de vistas, etc. Servicios al UsuarioServicios de NegociosServicios de DatosProveen la interfase visual para presentar e ingresar datosProveenlacomunicacinentrela presentaciny losdatos,ylasreglas delnegocioquerestringenalos mismosLoselementosdeestepaquetepermitenmantener,accedery actualizar los datos.22Clientes OrdenesAplicacion de Captura de OrdenesAplicacion de MailingUI Captura OrdenesUI MailingAWTSihayunamodificacinenunaclasedeOrdenes,se deben revizar las clases de UICapturaOrdenes?EnestecasosehageneradounpaqueteDominio,locual permiteespecificardependenciasreferenciando elpaquete contenedor, en lugar de hacerlo individualmente.Aplicacion de Captura de OrdenesAplicacion de MailingUI Captura OrdenesUI MailingAWTDominioClientesOrdenes23Aplicacion de Captura de OrdenesAplicacion de MailingUI Captura OrdenesUI MailingAWTDominioClientesOrdenesInterfase a Base de DatosInterfase OracleInterfaseSybasePaquete abstractoImplementanla interfasededel paquete generalLospaquetes poseenunafinalidadprimariaqueeslade convertirse en un mecanismo de control de configuacinyacceso,quepermitaalosdesarrolladoresorganizar modelos de gran dimensin y administrar su evolucin. Lospaquetescomoherramientasparaelcontrolde configuracin debernconteneraquelloselementosque evolucionarn conjuntamente. Lospaquetesdebernconteneraquelloselementosquese compilan en forma conjunta. 24ESTABILIDAD vs. GENERALIDAD DE PAQUETESLospaquetes queimportan sondependientes de aquellos que exportan.Siunpaquete noesimportado porningnpaquete(noposee dependientes)loclasificamoscomoirresponsable.Ningn elemento depende de l y sus cambios no tienen impacto. Lospaquetes importados pormuchospaquetes,posee muchos dependientes, lo clasificamos como responsables. Muchos elementos depende de ellos.ABC

D

paquete responsablepaquete irresponsablepaquete irresponsableESTABILIDAD vs. GENERALIDAD DE PAQUETESLos paquetes que no importan son independientes.Ningn paquete puede inducir cambios en unpaquete independienteSera aconsejable que:Lasdecisionesarquitectnicas seencuentrenen paquetes independientesLosdetallesdeimplementacin seencuentrenen paquetes irresponsablesABC

D

paquete independientepaquete irresponsablepaquete irresponsable25ESTABILIDAD vs. GENERALIDAD DE PAQUETESIrresponsableResponsableIndependiente DependienteDependenciasDependientesEstableInestableEspacio ms frecuente para paquetesEsdeseablequelospaquetesindependientesy reponsablesseanestables.ESTABILIDAD vs. GENERALIDAD DE PAQUETESSecuencia PrincipalEstructura arquitectnicaDetalles de implementacinLos paquetes ms generales y que constituyen las bases del sistemasdebenserlosmsestables.Loscambiosenlos mismos poseen un alto grado de propagacin.InestabilidadGeneralidad , Abstraccinindependienteresponsabledependienteirresponsable26CASOS DE USOEl modelo de Casos de Uso emplea dos conceptos bsicosActor y Caso de UsoEstos conceptos permiten definir: queelementosexternos alsistemainteractuancon l (Actor) y qu funciones deben ser realizadas por el sistema (Caso de Uso)Los casos de uso describen bajo la forma de acccionesy reacciones el comportamiento de un sistema desde elpuntodevistadeunusuario;permitendefinirlos lmitesdelsistemaylasrelacionesentreel sistemayel entorno.27clienteempleadocaso de usootro sistemaactorCASOS DE USOCASOS DE USOLa dinmica de un caso de uso puede ser especificada enformatextual omediantediversosdiagramasUML(secuencia, mquina de estados o colaboracin)Ladefinicindeuncasodeuso incluyeladescripcin de todos los comportamientos que representa:la secuencia principaldiferentesvariacionesdelcomportamiento normaltodas las condiciones de excepcin que pueden ocurrir28Flujo de eventos principal: Elcaso de uso comienza cuando el sistema le solicitaalcliente elnmerodePIN.Elcliente puedeahoradigitarsu PIN por medio del teclado. El cliente confirma lo ingresado por medio de lateclaEnter.ElsistemaluegoverificasielPINesvlido.SielPINes vlido, el sistema comunica la aceptacin, y termina el caso de uso.Flujodeeventosexepcional (Cancelacin): Elcliente puedecancelarla transaccinencualquiermomentopresionandolateclaCancel,ypor lo tantosereiniciaelcasodeuso.Noserealizaningun cambioenla cuenta del cliente.Flujodeeventosexepcional (Re-digitacindelPIN): Elcliente puede borrarelPINencualquiermomentoantesconfirmarloingresadoy reingresar un nuevo PIN.Flujodeeventosexepcional (PINnovlido): Sielcliente ingresaun nmero de PINinvlido, el caso de uso comienzanuevamente.Siesto ocurretresvecesseguidas,elsistemacancelalatransaccin, indicndolealcliente quepor60segundosnopodrinteractuarconla mquina.CASO DE USO: Validar Cliente en un Cajero1. Flujo de eventos principal2. Cancelacin3. Re-digitacin del PIN 4. PIN no vlidoClienteCuandoseposeesuficienteconocimiento,usualmentese empleaundiagramadesecuencia paradescribircadaflujo de eventos incluido en el caso de uso.Validar Cliente29Los actores no forman parte del sistema. Un actor puede: solamente ingresar informacin al sistema solamente recibir informacin del sistema ingresar y recibir informacin del sistemaACTORUsualmente estos actores aparecen en la descripcin del dominio,en las entrevistas con los usuarios y/o con los expertos. Por ejemplo: sistema de alumnado: alumno, profesor, etc. sistema de stock: sist. facturacin, vendedorIDENTIFICACIN DE ACTORESLas siguientes preguntas usualmente colaboran en la deteccin de actores: Quin est interesado en ciertos requerimientos? En qu lugar de la organizacin el sistema ser usado? Quin se beneficiar con el uso del sistema? Quinsuministraralsistemaestainformacin,usaresta informacin,y eliminar esta informacin? Quin mantendr el sistema? El sistema usar recursos externos? Una misma persona desarrollar diferentes roles? El mismo rol ser desempeado por varias personas? El sistema interactuar conun sistema preexistente?30Un Caso de Uso modela el dilogo entre un actor y el sistema. El conjunto de todos los casos de uso de un sistema constituyetodas las formas en que el sistema puede ser empleado.IDENTIFICACIN DE CASOS DE USO Las siguientes consultas pueden ayudar a identificar casos de uso:Cules son las tareas de cada actor?Algnactorcrear,almacenar,modificar,eliminaroleer informacin del sistema?Qucasodeusocrea,almacena,modifica,eliminaolee informacin del sistema?Existealgnactorquerequierainformaralsistemadealgn cambio externo?Algnactornecesitaqueelsistemaloinformedealgncambio en l?Qu casos de uso soportarn y mantendrn el sistema?Todos los requerimientos funcionales son realizados por los casos de uso.Casos de Uso para un Sistema de StockRecepcin de mercaderaSistema de Planificacin de ComprasVendedorConsulta de ExistenciaMantener Informacin deMercaderaMantener Informacin de UsuariosAdministrador deSistemaMantiene Informacin deProveedoresSistema deFacturacinDar de Baja un ItemRecepcionistaRecepcin de mercaderaDar de baja un itemConsulta sobre existenciaMantener informacin de usuariosMantener informacin de proveedoresMantener informacin de mercaderas31RELACIONES ENTRE CASOS DE USOUtiliza: Una relacin de este tipo entre casos de usosignificaqueunainstanciadelcasodeusoorigen incluyetambinelcomportamientodelcasodeusodestinoAB

Extiende: Una relacin de este tipo entre casos de usosignificaqueunainstanciadelcasodeusoorigenes unaextensinovariantedelcomportamiento representado por el caso de uso destinoAB

Cliente LocalCliente RemotoGiro por InternetGiro

Validacin cliente

Colocar orden de ventaSeguir ordenValidacin cliente

Despachar orden parcialmente Despachar orden

RELACIONES ENTRE CASOS DE USO32DIAGRAMA DE SECUENCIALos Diagramas de Secuenciarepresentan explcitamentela secuencia ordenada de interacciones (mediante el envo de mensajes) descriptas en el Caso de Uso.IDENTIFICACIN DE LAS CARACTERSTICAS DE LAS CLASESLosDiagramasdeSecuencia puedenserempleados paraconocerlasresponsabilidades delasclasesy objetos.LosDiagramasdeSecuencia permitenidentificarlos objetoseinteracciones necesariasparabrindaralgn servicio.DIAGRAMA DE SECUENCIAUnDiagramadeInteraccin (DI)oSecuencia se compone de: Un conjunto de objetos (clase o instancia). Unconjuntodemensajes quecomunicanpares de objetos. Secuencias de comportamiento de los objetos. Informacindecontrol(Condicional,Repeticin, etc.)33Actividad: Controlar TemperaturaControladorSensorTValvulaVaporControlar Temperaturaentre 60 y 70 CObjetoBorde del sistemaDescripcin de lasinteracciones entre losobjetos, estructurascondicionales, etc.ActividadabrirobtenerTObtener la Tempera-tura Actual.Si T < 60LuegoAbrir Vlvula de VaporSi T> 70LuegoCerrar Vlvula de VaporcerrarDIAGRAMA DE SECUENCIAVentanarea demensajeMenreadetrabajoCirculo RetnguloEl usuario elige delmen la opcinActualizar VentanaactualizarVentanaactualizarredibujarlimpiardibujardibujaractualizarObjeto Borde del sistemaDescripcin delas interaccionesentre los objetosTiempo queest activo unmtodoactualizarActividad: Actualizar VentanaDIAGRAMA DE SECUENCIA34while X loopend loopa b cmensaje 1mensaje 2mensaje 3If Xelseend iff2: crearXdestruirEmpleode pseudocdigopararepresentar estructurasde controlCreacin de instanciasDestruccin de instanciasDIAGRAMA DE SECUENCIAPreguntas que se deben realizar continuamente al revisar un escenario1. Quobjetodebeserresponsabledeunaaccin determinada?2. Posee el objeto suficiente conocimiento para realizar la accin,odebedelegaresecomportamientoaotro objeto?3. Noseleestnasignandodemasiadasaccionesal objeto?4. Qu podra fallar?35Cmo se interpreta un Diagrama de Secuencia?Lasinteraccionescomienzanconlaocurrenciade algn requerimiento externo al sistema.Las interacciones se llevan a cabo a medida que los objetos se envan mensajes.El orden de las barras que representan a los objetos es indistinto.Si es necesario representar ms de una instancia de una clase dada, pueden dibujarse una o ms barras, segn resulte ms claro.DIAGRAMA DE SECUENCIAEl eje temporal se mueve en forma descendente. No es lineal sino controlado por eventos.La barra (sobre la lnea de un objeto), que representa aunasecuenciadecomportamientos,permite identificarelconjuntodeactividadesquesellevana cabo como consecuencia de un evento dado.AlaizquierdadelaBarradeBordedelSistema,se pueden documentar las actividades (en aquello casos que sea necesario). 36Cliente Vendedor Inventario ResponsablePlanificacinPlan deProduccinResponsableManufacturaProducto1: pedido2: HayStock?Si no haystocksuficiente3: Requerimientos4: Crear5: Plan6: Elaborar8: NuevoProducto7:Los Casos de Usoconstituyen una tcnica centrada en el usuario para relevarlosrequerimientosdelsistemasdesdesuenfoquesonunmedioapropiadodecomunicacinconlos usuarios,yaqueesencialmenteseexpresanen lenguaje natural, que si bien se representan mediante DIconelsoportedeCASE,losmismosrequieren muy poca asistencia por parte de la CASE.CASOS DE USODIAGRAMA DE SECUENCIA37sonunaherramientaadecuadapararelevarla manera en que se llevan a cabo las actividades.facilitan la identificacin de los objetos de un dominio.son de gran ayuda para manejar la complejidad de los proyectos,yaquepermitendescomponerloensus principalesfuncionalidades,especificadasdesdeel punto de vista del usuario.Los Casos de UsoCASOS DE USODIAGRAMA DE SECUENCIAusualmente involucran la colaboracin de varias clases yobjetos,porlocualcontribuyenadescubriry proponerlosmensajesqueloscomunican. Proveenunaalternativaalenfoquetradicionalenlas metodologasorientadasaobjetos,queponen demasiadonfasisenlosaspectosestticosdel modelo (herencia, y estructuras de clases y objetos).sonunabuenabaseparalaverificacindelos modelos de alto nivel de abstraccin.CASOS DE USODIAGRAMA DE SECUENCIA38DIAGRAMA DE SECUENCIASe origina de manera forward.Puede ser empleado para verificar los requerimientos de un sistema.Tiene una naturaleza funcional.Nosiempresedisponedeinformacinacercadela maneraenquedebeninteractuarunconjuntode objetos para cumplir un objetivo.Precauciones:DIAGRAMA DE SECUENCIALosCasosdeUso sondenaturalezaFuncional, porlotanto,sedebesercuidadosoensuempleo en un proyecto que emplea el Modelo de Objetos.El concepto clave a remarcar es que Las Funciones no son ObjetosyLos Objetos no son FuncionesCASOS DE USO39PELIGROS EN EL EMPLEO DE CASOS DE USOEngeneralexisteunarelacinN-M entreCasosde Usos yClases-Objetos,yaqueseguramenteocurrir que:1. CadaCasodeUso emplealascaractersticas de varios objetos y clases, y 2. Cadaobjeto yclaseindividualparticipade varios Casos de UsoPorlotantocualquierdescomposicinrealizadaen baseaCasosdeUso,distribuirCaractersticas de Clases-Objetos,ylasmismasClases-Objetos enlos distintos Casos de Uso .CASOS DE USOQu puede ocurrir con el empleo de Casos de Uso en un proyecto ?SienelproyectoseasignacadaCasodeUso aun equipodedesarrolladoresdistinto,lousualesquelos distintos equipos produzcan varias veces la misma clase, en forma redundante y con variaciones parcialesEstoobviamenteproducirlaconsiguienteprdidade productividad,pueselprocesodeintegracinde resultados no ser trivial.40VISTA DE INTERACCIONESLos objetos interactuan para implementar un comportamiento.Estainteraccinsepuededescribirendosformas complementarias, focalizandose:1. en una coleccin de objetos cooperantes - Colaboracin2. en objetos individuales Mquinas de EstadosUna colaboracin tiene aspectos:esttico (define el contexto del comportamiento)decomportamiento(elconjuntodemensajesquese intercambian los objetos - Interaccin)UnaInteraccin puederepresentarsecondostiposde diagramas:de secuenciade colaboracinElDiagramadeColaboracin modelalosobjetosylosenlaces (links) quesonsignificativosparaunainteraccin determinada. ElDiagramadeColaboracin muestralasinteracciones entre los objetos, representando adems las relaciones estructurales que permiten la colaboracin del grupos de objetos.DIAGRAMA DE COLABORACIN : Ascensor : Cabina : Luz : Puerta1: Subir2: Encender3: Cerrarlinksmensajes41En el diagrama de colaboracin se muestan los enlacesque representan instancias de las asociaciones, as como losvnculostemporarios (representandoargumentosde mtodos, variables locales y referencias a s mismo).: Asc ens or: Cabi na: Puert at ra n si e n t3: Cerrarr1:c ompon ente1: Subir: Luzi 1: il umi naci n2: EncenderAscensorPuertaCabinaLuzcomponenteiluminacinpartees-instancia-dees-instancia-deLosobjetos queparticipanpuedenserespecificadosa travs de:I Slo el nombre de la instancia:C Slo el nombre de la claseI:C Los nombres de la instancia y claseLos enlaces se representan por lneas entre los objetos:Los mensajes se representan a travs de flechas sobre el enlace.Un mensaje se compone de:Un nmero de secuenciaUn smbolo de sincronizacinUna etiqueta que identifica al mensajeDIAGRAMA DE COLABORACIN42UsuarioTitulocrearEjemplar()reservaprestamoLibro BibliotecacatalogoEjemplarvolumenprestamoinventarioSetrabajasobreelSI deunabiblioteca,enlacualsemanejara por separado el concepto de ttulo y los distintos ejemplares que de un determinado ttulo existen en el inventarioempleado : actor: Biblioteca: Ejemplar: Libro1: Ingresar( )2: crearEjemplar( )4: incorporarInventario(Ejemplar)3: crear(Bibloteca)Se desea representar la incorporacin de un nuevo ejemplar al inventario delabiblioteca.Seutilizaundiagramade colaboracin para representar el caso de uso.Elempleado interactua conelSI,ingresandoelnuevo ejemplar. Por razones de eficiencia se requiere que se pueda acceder directamente a cada ejemplar, sin recurrir a ttulo.43Enlosdiagramasdecolaboracin esposibleespecificarel tipo de link que vincula a los objetos en la colaboracin. Si se tratadeunlinktransitorio (argumento,variablelocal, autoreferencia) o un link permanente (asocciacin).F : catalogo : actor : Biblioteca : Ejemplar : Libro1: Ingresar( )2: crearEjemplar( )PF5: incorporarInventario(Ejemplar)L3: crear( )4: iniciar(datos, Biblioteca)LIndica de que forma :Libro ubica la identidad de :Ejemplar

PIndicadequeforma:Ejemplar ubica la identidad de :Biblioteca

Instanciadela agregacin :catalogoElservidor estvinculadopor una asociacin al clienteFElservidor estasociadoauna variable local del mtodo que se est ejecutando en el cliente

LElservidor estasociadoaun parmetro delmtodoquese est ejecutando en el cliente

PSIGNIFICADO NOTACIN : A: BPservidor cliente6: 44 : actor : Biblioteca : Ejemplar : Libro1: Ingresar( )F : catalogo2: crearEjemplar( )PF5: incorporarInventario(Ejemplar)L3: crear( )4: iniciar(datos, Biblioteca){new}En eldiagrama de colaboracin se puede especificar si durante la ejecucin el objeto:se crea {new}se crea y destruye {transient}se destruye {destroyed}Elobjeto:Ejemplar noexistacuandocomenzabalacolaboracin, y se crea durante la mismaDiagramas de Secuencia y de Colaboracin Ambosdiagramasmuestraninteracciones,aunqueenfatizan aspectos diferentes. : actor : Biblioteca: Ejemplar: Libro1: Ingresar( )2: crearEjemplar( )3: crear( )4: incorporarInventario(Ejemplar)LosDiagramasdeSecuenciamuestranclaramentela secuenciatemporal yaunque nolasrelacionesentrelos objetos. : actor : Biblioteca : Ejemplar : Libro{new}1: Ingresar( )libro : 2: crearEjemplar( )PF 4: incorporarInventario(Ejemplar)L3: crear( )LosDiagramasdeCola-boracin muestranexpl-citamente lasrelaciones entrelosobjetos,yla secuenciatemporaldebe serinducidaapartirdela numeracindelos mensajes.