Ingeniera de Software ISESION 51. Paradigma de la Programacin Orientada a Objetos.2. Presentacin de UML.3. Compresin de los Requisitos4. Clasificacin de los Requisitos.5. Tipos de los requisitos segn el modelo FURPS+.6. Modelo de Casos de Uso.7. Relaciones en los Diagramas de Casos de Uso8. Casos de Estudio.CONTENIDO - SESION 5Ingeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del Softwarehttp://www.redalyc.org/articulo.oa?id=66661111UML (Lenguaje Unificado de Modelado) /(Unified Modeling Languaje).Conjunto de notaciones y diagramas para modelar sistemas orientados a objetos.UML es un lenguaje de modelado, y no un mtodo.El lenguaje de modeladoes la notacin (principalmentegrafica)de que se valen losmtodos para expresar los diseos.La notacin es el material grafico que se ve en los modelos; es la sintaxis del lenguajede modelado.Creadores: Grady Booch Jim Rumbaugh Ivar Jacobson.UML unifica los mtodos de Booch, Rumbaugh y Jacobson.UML es el sucesor de una oleada de mtodos de anlisis y diseo orientados a objetosque surgieron a finales de la dcada de 1980 y principio de los noventa.Ingeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareUML (Lenguaje Unificado de Modelado) /(Unified Modeling Languaje) es unaherramienta queayudaacapturarlaideadeunsistemaparacomunicarlaluegoaquien este involucrado en su proceso de desarrollo; esto se lleva a cabo mediante unconjuntodesmbolos ydiagramas, cadadiagramatienefines distintos dentrodelproceso de desarrollo.UML permite a los creadoresde sistemas generar diseos que capturan sus ideas enuna forma fcil de comprender para otras personas.UMLsepuedeusarparamodelardistintostiposdesistemas: sistemasdesoftware,sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramasen los cuales modelar sistemas.Ingeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareDiagramas de UML1. Diagramas de Casos de Uso. Modela los procesos del sistema.2. Diagramas de Secuencia.Modelar el paso de mensajes entre objetos.3. Diagramas de Interaccin. Modela interacciones entre objetos.4. Diagramas de Colaboracin. diagrama que muestra interacciones organizadas alrededor de los roles5. Diagramas de Estado. Modela el comportamiento de los objetos en el sistema.6. Diagramas de Actividad. Modela el comportamiento de los Casos de Uso, objetos u operaciones.7. Diagramas de Clases(Modelado delDominio). Modelar la estructura esttica de las clases en el sistema.8. Diagramas de Objetos. Modelar la estructura esttica de los objetos en el sistema.9. Diagramas de Componentes.Modela componentes.10. Diagramas de Implementacin. Modela la distribucin del sistema.Ingeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareEl paradigma de la Programacin Orientacin a Objetos - UML Mecanismoorientacin a objetosObjetosMensajesMtodos-(Acciones)ClasesUna clase es un tipo de objetos definidos por el usuario. Una clase equivale a la generalizacin de un tipo especifico de objetosConjunto de variables (o datos) y mtodos (o funciones) relacionados entre si Ingeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareEl paradigma de la Programacin Orientacin a Objetos - UML ABSTRACCIONCaptar las Caractersticas esenciales dede un objeto Centrarse en losaspectos quepermitan tener una visin global del problemaIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareEl paradigma de la Programacin Orientacin a Objetos- UML HERENCIACrear nuevas clases basadas en clases existentesIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwarePOLIMORFISMOEl polimorfismo es la capacidad que tiene un objeto de comportarse de mltiples formas.El paradigma de la Programacin Orientacin a Objetos- UML Ingeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareENCAPSULAMIENTOUnir en la clase las caractersticas(variables)y comportamientos(M todos)Los objetos encapsulan lo que hacen.Ocultan la funcionalidad interna de susoperaciones.El paradigma de la Programacin Orientacin a Objetos- UML Ingeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareEl paradigma de la Programacin Orientacin a Objetos- UML ENVIO DE MENSAJESEn un sistema losobjetostrabajanenconjunto, esto selogra mediante elenvi de mensajesentre ellos.Ingeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareASOCIACIONESLos objetos serelacionanentresi dealguna forma.El paradigma de la Programacin Orientacin a Objetos- UML Ingeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareEl paradigma de la Programacin Orientacin a Objetos- UML AGREGACIONOtro tipo deasociacin o adicinentre objetos.Ingeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareEl paradigma de la Programacin Orientacin a Objetos UML -CLASES Y OBJETOSCirculo-radio: double-centrox: double-centroy: double+Area(): double+Permetro(): doubleNombre de la ClaseAtributosOperacionesunCirculo: Circuloradio = 3.4centrox = 2 0centroy = 2.0Nombre del Objeto Clase del ObjetoValores de los AtributosVisibilidadPblica: +Privada: -Protegida: #Paquete: ~Ingeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareEl paradigma de la Programacin Orientacin a Objetos UML -CLASES Y OBJETOSAtributos:Los atributos o caractersticas de una Clase pueden ser de tres tipos, los quedefinen el grado de comunicacin y visibilidad de ellos con el entorno, estosson:public (+, ): Indica que el atributo ser visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.private (-, ): Indica que el atributo slo ser accesible desde dentro de la clase (slo sus mtodos lo pueden accesar).protected (#, ): Indica que el atributo no ser accesible desde fuera de la clase, pero si podr ser accesado por mtodos de la clase adems de las subclases que se deriven (ver herencia).CLASESIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareCLASESMtodos:Los mtodos u operaciones de una clase son la forma en como sta interactacon su entorno, stos pueden tener las caractersticas:public (+, ): Indica que el mtodo ser visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.private (-, ): Indica que el mtodo slo ser accesible desde dentro de la clase (slo otros mtodos de la clase lo pueden accesar).protected (#, ): Indica que el mtodo no ser accesible desde fuera de la clase, pero si podr ser accesado por mtodos de la clase adems de mtodos de las subclases que se deriven (ver herencia).El paradigma de la Programacin Orientacin a Objetos UML -CLASES Y OBJETOSIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareEJEMPLO DE CLASES SIN RELACIONES MODELADO DE JUEGO BALONCESTOEl paradigma de la Programacin Orientacin a Objetos UML -CLASES Y OBJETOSIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareASOCIACIONESUSO DE RELACIONES ENTRE CLASESEl paradigma de la Programacin Orientacin a Objetos UML -CLASES Y OBJETOSIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareEl paradigma de la Programacin Orientacin a Objetos UML -CLASES Y OBJETOSASOCIACIONESIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareEl paradigma de la Programacin Orientacin a Objetos UML -CLASES Y OBJETOSASOCIACIONESIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareEl paradigma de la Programacin Orientacin a Objetos UML -CLASES Y OBJETOSRESTRICCIONES EN LA ASOCIACIONESIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareMULTIPLICIDADEl paradigma de la Programacin Orientacin a Objetos UML -CLASES Y OBJETOSIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareEl paradigma de la Programacin Orientacin a Objetos UML -CLASES Y OBJETOSPOSIBLES MULTIPLICIDADESIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareEl paradigma de la Programacin Orientacin a Objetos UML -CLASES Y OBJETOSASOCIACIONES CALIFICADASIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareEl paradigma de la Programacin Orientacin a Objetos UML -CLASES Y OBJETOSASOCIACIONES REFLEXIVASIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareEl paradigma de la Programacin Orientacin a Objetos UML -CLASES Y OBJETOSHERENCIA Y GENERALIZACIONIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareEl paradigma de la Programacin Orientacin a Objetos UML -CLASES Y OBJETOSCLASES ABSTRACTASIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareDEPENDENCIASEl paradigma de la Programacin Orientacin a Objetos UML -CLASES Y OBJETOSIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareEl paradigma de la Programacin Orientacin a Objetos UML -CLASES Y OBJETOSINTERFACES Y REALIZACIONESIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareEl paradigma de la Programacin Orientacin a Objetos UML -CLASES Y OBJETOSIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareCOMPRESION DE LOS REQUESITOSLos requisitos son capacidades y condiciones con las cuales Debe ser conforme elsistema.Los requisitos encuentran, comunicany recuerdanloque se Necesita, estosignifica claridad para el cliente y el equipo de Desarrollo.Fuente : UML y Patrones Craig Larman Pearson Prentice HallIngeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareCOMPRESION DE LOS REQUESITOSFuente : UML y Patrones Craig Larman Pearson Prentice Hall Fuente : UML y Patrones Craig Larman Pearson Prentice HallLos requisitos son capacidades ycondiciones con las cuales debe serconforme el sistema.Los requisitos determinan lo que har elSistema, restriccionessobresuoperacine implementacin.Losrequisitosencuentran, comunicanyrecuerdan lo que se Necesita, estosignifica claridad para el cliente y elequipo de Desarrollo.El PUfomenta buenas practicas en lagestin de requisitos.El costo del proyecto depende en buenamedida de los requisitos.Ingeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareCLASIFICACIN DE LOS REQUIISTOSFuente : UML y Patrones Craig Larman Pearson Prentice HallDescriben el funcionamientos del Sistema.Los servicios que el Sistema debe proporcionar.Como debe reaccionar ante entradas.Como debe comportarse el sistema ante situaciones particulares.Requisitos FuncionalesEjemplosEl sistema debe almacenar los datos bsicos de los usuarios con una foto reciente. El sistema debe enviar un email al usuario cuando se retira dinero de su cuenta.El ingreso al sistema se realiza mediante el uso de clave y contrasea.El usuario tiene 30 das para descargar en su computador las canciones adquiridas.Ingeniera de Software ILa etapa de Anlisis y el proceso de modelado del SoftwareCLASIFICACIN DE LOS REQUIISTOSFuente : UML y Patrones Craig Larman Pearson Prentice HallSon propiedades o cualidades que el producto debe tener.Restricciones en el diseo o la implementacin.No modifican la funcionalidad del producto y si aaden funcionalidad al producto.Describen la experiencia del usuario cuando trabaja con el producto .Requisitos No FuncionalesEjemplosEl sistema debe funcionar en cualquier navegador. El sistema debe cumplir con la ley de confidencialidad de datos clnicos del paciente .El sistema no debe tardar ms de cinco segundos en mostrar los resultados de una bsqueda.El sistema debe funcionar en los sistemas operativos Linux y windows.Ingeniera de Software IAnlisis y la Especificacin de Requerimientos del SoftwareTIPOS DE REQUISITOS SEGN EL MODELO FURPS+Fuente : UML y Patrones Craig Larman Pearson Prentice HallEste modelo desarrollado por deHewlett-Packard(Grady, 1987). Basadoen el acrnimodeFURPS+: Funcionalidad (Functionality), Usabilidad (Usability), Confiabilidad (Reliability), Desempeo(Performance)y Soportabilidad (Supportability). Lasiguientetablapresentalaclasificacinde los atributos de calidad que seincluyenenel modelo, juntoconsuscaractersticas (Pressman, 2002).Ingeniera de Software IAnlisis y la Especificacin de Requerimientos del SoftwareMODELO DE CASOS DE USOFuente : UML y Patrones Craig Larman Pearson Prentice HallPermiten describir y registrar los requisitos(Especialmente los funcionales).Es una tcnica para entender y describir losrequisitos.El conjunto de casos de uso, es un modelode la funcionalidad y entorno del sistema.Laideadeutilizar los casos deusoparadescribir los requisitos funcionales fueintroducida por Ivar Jacobson en1986.Mejoras Como deben ser y comoescribirlos. Alistair Cockburn. WritingEffective Use Cases (1992).Ingeniera de Software IAnlisis y la Especificacin de Requerimientos del SoftwareMODELO DE CASOS DE USOFuente : UML y Patrones Craig Larman Pearson Prentice HallUn CASO DE USO es la descripcin de las acciones de un sistema desde el punto devistadel usuario. Uncasodeusoes, enesencia, unainteraccinentreunusuario y un sistema de computo. Con una coleccin de casos de uso se puedehacer el bosquejo de un sistema entrminos lo que los usuarios intenten hacercon el.Ingeniera de Software IAnlisis y la Especificacin de Requerimientos del SoftwareMODELO DE CASOS DE USOFuente : UML y Patrones Craig Larman Pearson Prentice HallCasos de UsoPasos Identificar los limites del sistema. Identificar los actores principales. Para cada uno, identificar sus objetivos. Definir casos de uso que satisfagan sus objetivosLos casos de uso son tiles en tres reas : Especificacin de requisitos. Comunicacin con los clientes. Generacin de casos de prueba: a partir de los escenarios de un caso de uso.Ingeniera de Software IAnlisis y la Especificacin de Requerimientos del SoftwareMODELO DE CASOS DE USOCaso de uso 1Caso de uso 2Casode uso 3Caso de uso 4Caso de uso 5Caso de usoActorInteraccinSistemaLimites del SistemaActor 1Actor 2Actor 3Ingeniera de Software IAnlisis y la Especificacin de Requerimientos del SoftwareMODELO DE CASOS DE USOFuente : UML y Patrones Craig Larman Pearson Prentice HallACTORAlgo con comportamiento, como unapersona (rol definido), Sistema uOrganizacin, por ejemplo un Cajero.ESCENARIOEs una secuencia de especifica de acciones einteracciones entre los actores y es sistemaobjeto de estudio. Por ejemplo el escenariode xito de compra de artculos con pago enefectivo, oel escenariodefalloal retirardinerodel cajerodebidoal rechazodelatransaccin por un motivo especifico.Un CASO DE USO es una coleccin de escenarios con xito y fallo relacionados, que describen a los Actores utilizando un sistema para satisfacer un objetivo.Ingeniera de Software IAnlisis y la Especificacin de Requerimientos del SoftwareRELACIONES EN LOS DIAGRAMAS DE CASOS DE USOFuente : UML y Patrones Craig Larman Pearson Prentice HallCOMUNICACIONRelacin(asociacin) entreunactor y uncaso de uso.INCLUSINUn caso de uso base incorporaexplcitamenteel comportamientodeotroen algn lugar de su secuencia.La relacin de inclusin sirve paraenriquecer un caso de uso con otro ycompartir una funcionalidad comn entrevarios casos de uso, tambin puedeutilizarseparaestructurar uncasodeusodescribiendo sus subfunciones.http://www.seas.es/blog/informatica/tipos-de-relaciones-en-diagramas-de-casos-de-uso-uml/Ingeniera de Software IAnlisis y la Especificacin de Requerimientos del SoftwareEJEMPLO 1: RELACIONES EN LOS DIAGRAMAS DE CASOS DE USOFuente : UML y Patrones Craig Larman Pearson Prentice Hallhttp://www.seas.es/blog/informatica/tipos-de-relaciones-en-diagramas-de-casos-de-uso-uml/INCLUSIN - includeIngeniera de Software IAnlisis y la Especificacin de Requerimientos del SoftwareEJEMPLO 2: RELACIONES EN LOS DIAGRAMAS DE CASOS DE USOFuente : UML y Patrones Craig Larman Pearson Prentice Hallhttp://www.seas.es/blog/informatica/tipos-de-relaciones-en-diagramas-de-casos-de-uso-uml/INCLUSIN - includeIngeniera de Software IAnlisis y la Especificacin de Requerimientos del SoftwareEXTENSIN - extendLarelacindeextensinsirveparamodelar: laparteopcional del sistema, unsubflujo que slo se ejecuta bajo ciertas condiciones o varios flujos que se puedeninsertar en un punto determinado.Fuente : UML y Patrones Craig Larman Pearson Prentice Hallhttp://www.seas.es/blog/informatica/tipos-de-relaciones-en-diagramas-de-casos-de-uso-uml/RELACIONES EN LOS DIAGRAMAS DE CASOS DE USOIngeniera de Software IAnlisis y la Especificacin de Requerimientos del SoftwareEXTENSIN - extendFuente : UML y Patrones Craig Larman Pearson Prentice Hallhttp://www.seas.es/blog/informatica/tipos-de-relaciones-en-diagramas-de-casos-de-uso-uml/EJEMPLO 1:RELACIONES EN LOS DIAGRAMAS DE CASOS DE USOIngeniera de Software IAnlisis y la Especificacin de Requerimientos del SoftwareRELACIONES EN LOS DIAGRAMAS DE CASOS DE USOESPECIALIZACION Y GENEALIZACION DE LOS CASOS DE USOUn caso de uso (subcaso) hereda el comportamiento y significado de otro, es decirlasrelacionesdecomunicacin, inclusinyextensindel super-casodeuso. Enmuchas ocasiones este super-caso de uso es abstracto y corresponde a uncomportamiento parcial completado en el subcaso de uso. O dicho de otra manera,Loscasosdeuso hijosonunaespecializacindel casodeuso padre. Enlamedidadeloposibledeberaevitarsepuestoqueproduceciertaconfusinenalgunas ocasiones.Fuente : UML y Patrones Craig Larman Pearson Prentice Hallhttp://www.seas.es/blog/informatica/tipos-de-relaciones-en-diagramas-de-casos-de-uso-uml/Ingeniera de Software IAnlisis y la Especificacin de Requerimientos del SoftwareEJEMPLO : FICHA CASO DE USOIngeniera de Software IAnlisis y la Especificacin de Requerimientos del SoftwareEJEMPLO CASO DE USOPedidosInformesAverasReservasSugerenciasInforme para UsuariosActividadResponsable de InformticaResponsable deMantenimientoUsuarioIngeniera de Software IAnlisis y la Especificacin de Requerimientos del SoftwareDescripcin de los Casos de Uso del ejemplo anterior1.PEDIDOSEscenario general donde se realizan todas las operaciones relativas a pedidos: hacer, recibir, anular ydevolver pedidos. Todo es realizado por el Responsable de Informtica.2.INFORMESTodos los informes que son necesarios para el funcionamiento de la empresa: informe de pedido, deamortizaciones, de inactividad, de composicin de equipos bsicos, de composicin de otros equipos,de inventario software y manuales, de garantas y de disponibilidad. Estos informes son realizadospara el Responsable de Informtica.3.AVERIASEnglobatodas lsoperaciones relativas alasaverastantoel avisoquepuedeser realizadoporcualquier actor (Responsable de Informtica, de Mantenimiento o Usuario) , como el parte de averaque es realizado por el Responsable de Mantenimiento y entregado al Responsable de Informtica.Ingeniera de Software IAnlisis y la Especificacin de Requerimientos del SoftwareDescripcin de los Casos de Uso del ejemplo anterior4.RESERVASEs tanto la peticin de reserva de un equipo con unas caractersticas determinadas, que puede serrealizada por cualquier usuario al Responsable de Informtica, como la concesin de una reserva querealiza este ltimo a un usuario.5.SUGERENCIASEs una lnea de comunicacin entre los diferente agentes que interaccionan con el sistema.6.INFORMES PARA EL USUARIOEs un informe especialmente realizado para el usuario donde este puede encontrar toda lainformacin que pueda necesitar en un momento determinado sobre un equipo, su disponibilidad,software o un manual.7.ACTIVIDADRealizadoporel ResponsabledeInformticaenglobatodolorelativoal buenfuncionamientodelmaterial de la empresa: dar de baja temporalmente un equipo cuando esta en reparacin, dar de bajapermanentemente un equipo cuando no tiene arreglo y actualizar tanto software como los manuales.Ingeniera de Software IAnlisis y la Especificacin de Requerimientos del SoftwareHACER CONSULTAHACER RESERVABORRAR RESERVAPRESTAR LIBRO GESTIONAR PERSONALVERIFICAR MULTA CONTROLAR ACCESOREGISTRAR LECTORDEVOLVER LIBROBIBLIOTECARIOUSUARIOLECTORSI - ADMINISTRATIVO

Ejemplo-Diagrama de Casos de UsoDIRECTORIngeniera de Software IAnlisis y la Especificacin de Requerimientos del SoftwareCASO DE ESTUDIOCASOS DE USOTESIS212-PG:126 (Ficha Casos de Uso) TESIS CON UML-PG:67 (Diagramas Casos de Uso)Ingeniera de Software IIntroduccin a la Ingeniera del SoftwareTALLER 4LEER1. Booch G; Rumbaugh J; Jacobson I. El Lenguaje Unificado de Modelado. UML 2.0: Paradigma de la Programacin Orientada a Objetod . Captulos 1 y 2.2. Booch G; Rumbaugh J; Jacobson I. El Lenguaje Unificado de Modelado. UML 2.0: Presentacin de UML,Captulo 2.