Curso de UMLActividad 1 Introduccin a UML

Dra. Anaisa Hernndez Gonzlez

Construccin de una casa para fido Puede hacerlo una sola personaRequiere:Modelado mnimoProceso simpleHerramientas simples

Construccin de una casaConstruida eficientemente y en un tiempo razonable por un equipoRequiere:ModeladoProceso bien definidoHerramientas ms sofisticadas

Construccin de un rascacielos

Problemas de la Industria de Software en la actualidadTendencia al crecimiento del volumen y complejidad de los productos.12Proyectos excesivamente tardes y se exige mayor productividad y calidad en menos tiempo.3Insuficiente personal calificado.

Planificacin Irreal12Mala Calidad del Trabajo3Personal Inapropiado4No Controlar los Cambios Por qu fallan los Proyectos de Software??

Los ingenieros no son capaces de enfrentar un plan porque:Planificacin Irreal NO estn entrenados para usar mtodos de planificacin. Frecuentemente, las estimaciones NO se basan en datos reales.El sistema es para hoy y con costo 0

Mala Calidad del TrabajoCAUSASPrcticas pobres de ingenieraCarencia de mtricas de calidadInadecuado entrenamiento en calidadDecisiones de los directivos guiadas por una planificacin irreal

Mala Calidad del TrabajoCONSECUENCIASTiempos de pruebas impredeciblesProductos con muchos defectosDemoras en la aceptacin de los usuariosExtensa garanta de servicio y reparacionesUna pobre calidad afecta la planificacin y torna ineficente el proceso de prueba

Personal InapropiadoCon independencia del plan, los proyectos deben comenzar en tiempo y con todo el personal.

Cambios NO controladosSiempre ocurren cambios en los requerimientos.Los planes del proyecto se basan en el alcance del trabajo conocido.Los cambios siempre requieren ms trabajo.Sin planes detallados, los equipos no pueden estimar el efecto o magnitud de los cambios.Si los equipos no controlan cada cambio, se pierde gradualmente el control del plan del proyectoHECHOS a RECORDAR:

Las organizaciones requieren: Cmo enfrentarla??Desarrollar o adquirir una disciplina en el desarrollo del software.1

Mejorar el proceso de desarrollo de softwareQu debe hacer una empresa para obtener software de buena calidad?

Cualquier modelo de calidad para mejorar el Proceso de Desarrollo de Software, IMPLICA utilizar los mtodos y procedimientos de INGENIERIA Y GESTION DE SOFTWARE

Qu es la Ingeniera de Software (IS)?...la aplicacin de un enfoque sistmico, disciplinado y cuantificable hacia el desarrollo, funcionamiento y mantenimiento de software, es decir la aplicacin de ingeniera al software IEEE,1993

IS es una tecnologa multicapaSoporte automtico o semiautomtico para el proceso y los mtodos.Es el fundamento de la IS. Es la unin que mantiene juntas las capas de la tecnologa.

Sntomasnecesidades usuariosrequerimientos cambiantesmdulos no calzanpoco mantenibletarda deteccinbaja calidadbaja performanceversiones y cambios liberacin y distribucin

Causasrequerimientos insuficientescomunicacin ambiguaarquitecturas frgilescomplejidad excesivainconsistencias no detectadas prueba pobreevaluacin subjetivadesarrollo en cascada cambios no controladosautomatizacin insuficiente

Sntomas - Causas...tratar los Sntomas no resuelve el problemaDiagnstico

Las Mejores Prcticas de la IS atacan las causas

Mejores Prcticas de SoftwareSon propuestas de desarrollo probadas comercialmente, que usadas en forma combinada atacan la raz de las causas de las fallas, eliminando los sntomas y permitiendo el desarrollo y mantenimiento de software de calidad de manera predictiva y reiterativa.

Mejores Prcticas: Equipos de Alto RendimientoResultadoProyectos ms exitosos porque estn en plazo, en presupuesto y satisfacen las necesidades del usuario

SNTOMASnecesidades usuariosrequerimientos cambiantesmdulos no calzanpoco mentenibletarda deteccinbaja calidadbaja performanceversiones y cambios liberacin y distribucin CAUSASRequerimientos insuficientesComunicacin ambiguaarquitecturas frgilescomplejidad excesivainconsistencias no detectadas testing pobreevaluacin subjetivadesarrollo en cascada cambios no controladosautomatizacin insuficiente

MEJORES PRCTICASdesarrolle iterativamenteadm. requerimientosuse arquitectura de componetesmodele el software visualmenteverifique calidadcontrole cambios

Enfrentando las Causas se eliminan los Sntomas

Controle CambiosUse Arquitecturasde ComponentesModele Visualmente VeriqueCalidadAsegura participacin del usuariomientrs evolucionan requerimientosValida tempranamentelas decisiones arquitectnicasPemite manejar la complejidadde disear incrementalmenteMide la calidad en forma oportuna y frecuenteEvoluciona la lnea base incrementalmenteAdministre RequerimientosMejores Prcticas se refuerzan entre si

Mejores prcticas para el trabajo efectivo de un equipo en el desarrollo del software.(Dirige y organiza el proceso)(Notacin)

SumarioConceptos bsicos del modelo de objetosProceso de desarrollo de software.El Lenguaje Unificado de Modelacin (UML)El Proceso Unificado de Desarrollo de Software (RUP)

Lecturas RecomendadasJACOBSON, Ivar; BOOCH, Grady, RUMBAUGH, James, El Proceso Unificado de Desarrollo de Software.2000. Addison Wesley.BOOCH, Grady, RUMBAUGH, James, JACOBSON, Ivar; El Lenguaje Unificado de Modelacin. Libro introductorio.2000. Addison Wesley.

LARMAN, Craig UML y patrones 1999, Prentice Hall Iberoamericana.RUMBAUGH, James, JACOBSON, Ivar, BOOCH, Grady; El Lenguaje Unificado de Modelacin. Manual de referencia.2000. Addison Wesley.

Lecturas RecomendadasCONALLEN, Jim, Building Web Applications with UML.2002. 2nd edition. Addison Wesley.BOOCH, Grady, MAKSIMCHUCK, Robert, ENGLEm Michael, YOUNG, Bobbi, CONALLEN, Jim, Houston, Kelli; Objetct-Oriented Analysis and Design with Applications. Third Edition. Addison Wesley. 2007.HAMILTON, Kim, MILES, Russell; Learning UML 2.2006. O Reilly Media

Conceptos bsicos del Modelo de Objetos

Enfoque Orientado a ObjetosSe basa en conceptos y relaciones entre ellos.Todo

Partes

Enfoque Orientado a ObjetosTipo de Objeto:Descripcin generalizada que describe una coleccin de objetos similares.Clase:Implementacin en software de un tipo de objeto.

Enfoque orientado a Objetos

Mtodo:Implementacin en software de la operacin.

Cambiar luz

EncapsulamientoEmpaque conjunto de datos y mtodos.AtributosOperacionesEnfoque Orientado a Objetos

Enfoque Orientado a ObjetosHerencia: Propiedad de una clase de heredar el comportamiento de sus ancestros.Polimorfismo: Mecanismo que permite a la subclase implementar la misma operacin con un mtodo diferente.

Proceso de Desarrollo de Software

ProcesoDefine quin est haciendo qu, cundo y cmo para alcanzar un determinado objetivo.

Proceso de desarrollo de software (PDS)

Un proceso software debe especificar:la secuencia de actividades a realizar por el equipo de desarrollo: flujo de actividadesproductos que deben crearse: qu y cundo asignacin de tareas a cada miembro del equipo y al equipo como un todoproporcionar heursticascriterios para controlar el procesoProceso de desarrollo de software (PDS)

UML

Puede ser un seudocdigo, cdigo, imgenes, diagramas, o largos paquetes de descripcin; es decir, cualquier cosa que ayude a describir un sistema Lenguaje de modelacin=+

(Forma de expresar el modelo)Lenguaje de modelacin+=(Descripcin de lo que significa esa modelacin)

Manejar la complejidadModelar el sistema independientemente del lenguaje de implementacinPromover la ReutilizacinNotacin visualNotacin visual

Diversos 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)

Situacin de partidaSituacin de partida

Descrito en "The Unified Modeling Language for Object-Oriented Development" de Grady Booch, James Rumbaugh e Ivar Jacobson.Basado en las experiencias personales de los autores.Incorpora contribuciones de otras metodologas.Lenguaje Unificado de ModelacinQu es el UML- Unified Modeling Language?U M L

Ofrece un estndar para describir un plano del sistema.Incluye aspectos conceptuales tales como procesos de negocio y funciones del sistema y aspectos concretos como espresiones de lenguajes de programacin, esquemas de BD y componentes de software reutilizables.Lenguaje Unificado de ModelacinQu es el UML- Unified Modeling Language?U M L

UML

UML no es un mtodoEl UML es una gua al desarrollador para realizar el anlisis y diseo orientado a objetos, es un proceso

El esfuerzo de UML parti oficialmente en octubre de 1994, cuando Rumbaugh se uni a Booch en Rational. El Mtodo Unificado en su Versin 0.8, 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 Rose

Orgenes de UML

Creacin del UMLBooch methodOMTpublicfeedback

Las primeras versiones de UML estaban ms orientadas hacia la modelacin del software y ahora se requiere ms la modelacin del sistema.Necesidad de compartir modelos entre diferentes herramientas.Nuevas tecnologas: Arquitectura basada en componentes, MDALas primeras versiones estaban ms diseadas para las personas y no para las mquinas, por lo que hay construcciones que no estaban suficientemente formalizadas.Por qu UML 2.0?

GRADYBOOCHIVARJACOBSONJAMESRUMBAUGHObject Modelling Technique 1991(OMT)Object Oriented Analysis and Design with Applications 1994Object Oriented Software Engineering: A Use Case Driven Approach 1992 (OOSE)Las Bases de UMLBooch, RumbaughJacobsonRational Software Corporation. (1995)Las Bases de UMLLas Bases de UML

Modelar sistemas, a partir de los conceptos hacia los artefactos ejecutables, utilizando tcnicas orientadas a objeto.Enfocarnos en las cuestiones de escala inherentes a sistemas complejos, crticos en su misin.Crear un lenguaje de modelacin utilizable tanto por los humanos, como por las mquinas.Premisas de UML segn Booch, Jacobson y Rumbaugh

Contribuciones a UMLDiagrama de Casos de usoDiagrama de ClasesDiagrama de ObjetosDiagrama de SecuenciaDiagrama de EstadoDiagrama de ComponentesDiagrama de Estructura CompuestaDiagrama de PaquetesDiagrama de ComunicacinDiagrama de ActividadDiagrama de TiempoDiagrama de DespliegueOOSE/JacobsonOOAD/BoochOMT/RumbaughOtras mejores prcticas

Es un lenguaje formal ya que cada elemento del lenguaje tiene un significado fuerte que ayuda a modelar un aspecto particular del sistema.Es conciso con una notacin simple.Es comprensible porque describe todos los aspecto importante del sistema.Es escalable por lo que permite describir proyectos de diferentes tamaos.Ventajas de UML

Contiene las mejores prcticas de la comunidad orientada a objetos de los ltimos 15 aos.Es un estndar abierto.Da soporte a todo el ciclo de vida de desarrollo del software.Da soporte a diversas reas de aplicacin.Est soportado por muchas herramientas.Ventajas de UML

Carece de un semntica precisa, lo que ha dado lugar a que la interpretacin de un modelo UML no pueda ser objetiva en ocasiones.No se presta con facilidad al diseo de sistemas distribuidos. En estos sistemas son importantes factores como transmisin, serializacin, persistencia, etc. No se puede sealar si un objeto es persistente o remoto.Limitaciones de UML

Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto de software desde cada una de las perspectivas de inters

Un producto de software es el cdigo mquina y los ejecutables de un sistemaUn producto de software es el conjunto de artefactos que se necesitan para representarlo en forma comprensible para: Las mquinas. Los trabajadores. Los usuarios. Los interesados.

artefactos?Qu es un producto de software?

Artefactos?Trmino general aplicable a cualquier tipo de informacin creada, cambiada o utilizada por los trabajadores en el desarrollo del sistema Diagramas UML y su texto. Bocetos de interfaz. Planes de prueba.Ejemplos:

Un 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 arcosModelos y DiagramasModelos y Diagramas

Trazabilidad entre los modelosSecuenciacronolgicaModelosModelos

Diagramas de UMLEstructura Dinmica Fsica Gestin del modelo

Modelos y DiagramasDiagrama de Casos de Uso del NegocioDiagrama de SecuenciaDiagrama de ComunicacinDiagrama de Casos de Uso del SistemaDiagrama de ActividadesDiagrama de EstadoDiagrama de Paquetes

Casos de Uso y Diagramas de Casos de UsoDiagramas de UMLCasos de usoDiagrama de casos de uso

Casos de Uso es una tcnica para capturar informacin de cmo un sistema o negocio trabaja, o de cmo se desea que trabaje

No pertenece estrictamente al enfoque orientado a objeto, es una tcnica para captura de requisitosDiagrama de casos de uso

Diagramas de estructura estticaDiagrama de clasesDiagrama de Objetos

Diagramas de UML

Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia

La definicin de clase incluye definiciones para atributos y operaciones

El modelo de casos de uso aporta informacin para establecer las clases, objetos, atributos y operacionesDiagrama de clases

Diagramas UMLDiagramas del comportamientoDiagramas de EstadoDiagramas de ActividadDiagramas de SecuenciaDiagrama de ComunicacinDiagrama de tiempoDiagrama de SecuenciaDiagrama de Comunicacin

Diagrama de estado

Diagrama de actividades

Diagrama de secuencia

Diagrama de comunicacin

Diagramas de implementacinDiagramas de componentesDiagramas de instalacin/Distribucin (Despliegue)

Diagramas de UMLDiagrama de componentes

Diagrama de componentes

Diagrama de despliegue

Tomado de:Rosenberg, Doug, Kendall Scott. Applying use case driven object modeling with UML: an annotated e-commerce example. Cmo se relacionan los diagramas?Solo para comprender la secuencia de pasos

Cmo se relacionan los diagramas?Solo para comprender la secuencia de pasosTomado de:Rosenberg, Doug, Kendall Scott. Applying use case driven object modeling with UML: an annotated e-commerce example.

Cmo se relacionan los diagramas?Solo para comprender la secuencia de pasos

Tomado de:Rosenberg, Doug, Kendall Scott. Applying use case driven object modeling with UML: an annotated e-commerce example. Cmo se relacionan los diagramas?Solo para comprender la secuencia de pasosCmo se relacionan los diagramas?

UML define una notacin que se expresa como diagramas sirven para representar modelos/subsistemas o partes de ellos

El 80 por ciento de la mayora de los problemas pueden modelarse usando alrededor del 20 por ciento de UML-- Grady BoochResumen

El Proceso Unificado de Desarrollo(Rational Unified Process- RUP)

Rational Unified ProcessRUP es un proceso para el desarrollo de software orientado a objeto que utiliza UML para describir un sistemaRational Software Corporation, 1998

Rational Unified Process 5.0Rational Objectory Process 4.1Rational Objectory Process 4.0Rational ApproachObjectory ProcessPruebas de rendimiento y carga(Performance Awareness)Ingeniera de NegociosDiseo OO de IUIngeniera de Datos(Vigortech)UML 1.2Proceso SQA(SQA Inc.)UML 1.0Administracin de Configuracin y Cambios(Pure-Atria)Escuela de Requerimientos(Requisite Inc.)OMTBoochUML 0.81998199719961995Ericsson method19671987Evolucin de RUP

Estructura Esttica de RUPFases e Iteraciones

Disciplinas del Proceso Actividades, flujo de trabajo

Artefactos Modelos, reportes, documentos

TrabajadoresCmo ocurre el proceso y sus detalles?Qu se produce u obtiene?Quin lo hace o se responsabiliza?Cundo ocurre el proceso?

Estructura DinmicaConcepcinElaboracinConstruccinTransicin Concepcin Define el alcance del proyecto y eldesarrollo de los casos del negocio.Elaboracin Planifica el proyecto, especifica las caractersticas y define los cimientos de la arquitectura.Construccin Construye el producto.Transicin Implementa el producto a sususuarios.

Fases-Flujos de trabajo de RUP

Caractersticas del ciclo de vida de RUPDirigido por Casos de Uso.Centrado en la arquitectura.Iterativo e incremental.

Dirigido por Casos de UsoCiclo de vida de RUP(Reflejar lo que los futuros usuarios necesitan y desean)

Caso de UsoRealizacin de AnlisisRealizacin de DiseoCaso de PruebaXtracetracetracetracePruebas FuncionalesPruebasUnitariasDirigido por Casos de UsoCiclo de vida de RUP

Dirigido por Casos de UsoCiclo de vida de RUP

Centrado en la arquitecturaCiclo de vida de RUPEn la construccin,vista de:A) Estructura.B) Calefaccin.C) Plomera.D) Electricidad.Estticos

DinmicosAspectos

Centrado en la arquitecturaCiclo de vida de RUP(Visin comn del sistema completo en la que desarrolladores y usuarios deben estar de acuerdo )Describe los elementos del modelo que son ms importantes para su construccin, los cimientos del sistema que son necesarios como base para comprenderlo, desarrollarlo y producirlo econmicamente.Se desarrolla mediante iteraciones comenzando por los CU relevantes desde el punto de vista de la arquitectura.

Centrado en la arquitecturaCiclo de vida de RUPVista lgicaVista de componentesVista de despliegueVista fsicaVista de Casos de usoVista de diseoVista de actividadesVista de estadoVista estticaVista de Casos de usoVista de despliegueVista de componentesVista de Gestin del modeloPerfil

Iterativo e incrementalCiclo de vida de RUPDentro de cada fase hay hitos (artefactos a construir) asociados a resultados de cada iteracin.La terminacin de una iteracin produce un nuevo incremento.

EnfoqueCascadaEnfoqueIterativo eIncrementalIterativo e incrementalCiclo de vida de RUP

Grado de Finalizacin de ArtefactosIterativo e incrementalCiclo de vida de RUP

Beneficios de la iteracinReduce el coste del riesgo al coste de un solo incremento.

Menos riesgo de no sacar el producto al mercado en fecha.

Acelera el ritmo de desarrollo.

Las necesidades del usuario y correspondientes requisitos no pueden definirse completamente al principio. Se requieren iteraciones sucesivas.

RUP RUP es un proceso que garantiza la elaboracin de todas las fases de un producto de software orientado a objetos.

RUP es dirigido por los casos de uso, centrado en la arquitectura, iterativo e incremental.

RUP utiliza el UML.

UML es un lenguaje que permite la modelacin de sistemas con tecnologa orientada a objetos

UML y RUP

Extrada desde la presentacin Software Architecture and UML de Grady Booch (Rational Software).Extrada desde la presentacin Software Architecture and UML de Grady Booch (Rational Software).

Extrada desde la presentacin Software Architecture and UML de Grady Booch (Rational Software).

Obviamente el debe ser el contexto de desarrollo (envergadura del proyecto) el que determine la configuracin adecuada del proceso y los recursos necesarios. Existen propuestas radicales que promueven un proceso/modelado ms ligth, tales como: Extreme Programming (Kent Beck) y Agile Modeling (Scott Ambler). Sin embargo, para proyectos de envergadura es difcil eludir un proceso y modelado ms rigurosos. Una lectura interesante:Extreme Programming in the Quick-change Era 'Beware of the religion of the code-generating modeling tool.by Alexandra Weber MoralesAbout 30 years ago, Barry Boehm theorized that the cost of software change increased exponentially over time; that is, if an error caught in requirements gathering cost $1, an error caught during deployment would cost $1000. "What if," said Robert Martin, a former preacher who now uses his persuasive speaking skills to promote Smalltalk guru Kent Beck's Extreme Programming (XP) methodology, "you took a moment to suspend disbelief and considered that--due to today's technology--the cost of change is essentially flat. When costs don't change over time, up-front speculative work is a liability. Ambiguity and volatility are reasons to delay." In such a world, Martin told a packed room at the UML World conference in New York city on June 14, developers need a process that exploits a flat change/cost curve?and XP is that process. The five-year-old methodology values communication (but not on paper), simplicity, feedback and courage. It's designed for small to medium-sized teams of no more than 12 people who work in a common area, integrate and test their code constantly, pair program on single computers and use whiteboards hung on the periphery to hash out designs. Source code is the preferred archival medium, and cards containing "user stories"(requirements written by customers) and tasks are the "high-density storage mechanism," according to Martin, who runs a training firm called Object Mentor out of Green Oaks, IL. "Where does modeling fit in? asked an audience member, reminding Martin that his talk, at this point nearly over, had promised to describe the interaction between the UML and XP. "Paper and pencil or whiteboards are the best CASE tools I know of. In Kent's case, he uses CRC cards, not the UML," said Martin. "But whether it's Booch notation or UML, you do the highest-level map you can, but you don't do all your design up front. Remember, in XP it's not an archival resource, it's a communication device. The only archive I want is the code and a few poignant, incisive documents explaining why I made certain decisions." Does this mean that ever more sophisticated modeling tools have no place in XP? Not exactly, said Martin. "If a code-generating tool works for you, use it. After all, that's what a compiler does. But beware of the religion of modeling tools that spit out executable prototypes. Sometimes getting the code from the tool is more time-consuming than writing it yourself."