Desarrollos de Software Orientados a Objetos usando UMLAgustn J. GonzlezOOP&D.Material Tomado de: Departamento Sistemas Informticos y Computacin (DSIC)Universidad Politcnica de Valencia (UPV) - Espaawww.dsic.upv.es/~uml

IntroduccinModelado de SW

Construccin de una casa para fido Puede hacerlo una sola personaRequiere:Modelado mnimoProceso simpleHerramientas simplesI. Introduccin: Modelado de SW

Construccin de una casaConstruida eficientemente y en un tiempo razonable por un equipoRequiere:ModeladoProceso bien definidoHerramientas ms sofisticadasI. Introduccin: Modelado de SWI

Construccin de un rascacielosI. Introduccin: Modelado de SI

Claves en Desarrollo de SIHerramientasProcesoNotacinI. Introduccin: Modelado de SWI

Abstraccin - Modelado Visual (MV) Sistema ComputacionalEl modelado captura laspartes esenciales del sistema I. Introduccin: Modelado de SW

MV para manejar la complejidad I. Introduccin: Modelado de SW

MV promueve la reutilizacinMltiples SistemasComponentes ReutilizadosI. Introduccin: Modelado de SW

Por qu la Orientacin a Objetos?Proximidad de los conceptos de modelado respecto de las entidades del mundo real

Mejora 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 problema Facilita construccin, mantenimiento y reutilizacinIII. El Paradigma Orientado a Objeto

Por qu la Orientacin a Objetos?

Conceptos comunes de modelado durante el anlisis, diseo e implementacin

Facilita la transicin entre distintas fasesFavorece el desarrollo iterativo del sistemaDisipa la barrera entre el qu y el cmo

Sin embargo, existen problemas ...III. El Paradigma Orientado a Objeto

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 StrigelIII. El Paradigma Orientado a Objeto

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 objetosIII. El Paradigma Orientado a Objeto

Fundamentos de Modelado OO

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)III. El Paradigma OO: Fundamentos de Modelado OO

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 subrayadoIII. El Paradigma OO: Fundamentos de Modelado OO

ObjetosEjemplo de varios objetos relacionados:III. El Paradigma OO: Fundamentos de Modelado OO

ObjetosObjeto = Identidad + Estado + ComportamientoEl estado est representado por los valores de los atributosUn atributo toma un valor en un dominio concretoIII. El Paradigma OO: Fundamentos de Modelado OO

Clases y ObjetosIII. El Paradigma OO: Fundamentos de Modelado OO

EstadoEl estado evoluciona con el tiempo

Algunos atributos pueden ser constantes

El comportamiento agrupa las competencias de un objeto y describe las acciones y reacciones de ese objeto

Las operaciones de un objeto son consecuencia de un estmulo externo representado como mensaje enviado desde otro objetoIII. El Paradigma OO: Fundamentos de Modelado OO

ComportamientoEjemplo de interaccin:III. El Paradigma OO: Fundamentos de Modelado OO

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 sueloIII. El Paradigma OO: Fundamentos de Modelado OO

PersistenciaLa persistencia de los objetos designa la capacidad de un objeto trascender en el espacio/tiempo

Podremos despus reconstruirlo, es decir, cogerlo 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 destruyaIII. El Paradigma OO: Fundamentos de Modelado OO

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 componenIII. El Paradigma OO: Fundamentos de Modelado OO

ComunicacinCategoras de objetos:Activos - PasivosCliente Servidores, Agentes

Objeto Activo: posee un hilo de ejecucin (thread) propio y puede iniciar una actividad

Objeto Pasivo: no puede iniciar una actividad pero puede enviar estmulos una vez que se le solicita un servicio

Cliente es el objeto que solicita un servicio. Servidor es el objeto que provee el servicio solicitadoIII. El Paradigma OO: Fundamentos de Modelado OO

ComunicacinLos agentes renen las caractersticas de clientes y servidores

Son la base del mecanismo de delegacin

Introducen indireccin: un cliente puede comunicarse con un servidor que no conoce directamenteIII. El Paradigma OO: Fundamentos de Modelado OO

ComunicacinEjemplo en el que un agente hace de aislante:Un agente Un cliente Sevidor 1 Servidor 2 III. El Paradigma OO: Fundamentos de Modelado OO

El Concepto de MensajeLa unidad de comunicacin entre objetos se llama mensaje

El mensaje es el soporte de una comunicacin que vincula dinmicamente los objetos que fueron separados previamente en el proceso de descomposicin

Adquiere toda su fuerza cuando se asocia al polimorfismo y al enlace dinmico

III. El Paradigma OO: Fundamentos de Modelado OO

El Concepto de MensajeObjeto 4Objeto 3Objeto 2Objeto 1: Mensaje E: Mensaje D: Mensaje C: Mensaje AIII. El Paradigma OO: Fundamentos de Modelado OO

Proceso de Desarrollo de SW basado en UML

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 SoftwareIV. Proceso de Desarrollo de SW basado en UML

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 EricssonUMLIV. Proceso de Desarrollo de SW basado en UML

Dos DimensionesIV. Proceso de Desarrollo de SW basado en UML

Fases e Hitos (Milestones)tiempoObjetivos(Vision)

Arquitectura

CapacidadOperacionalInicial

Releasedel ProductoInceptionElaborationConstructionTransitionIV. Proceso de Desarrollo de SW basado en UML

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 precedentesIV. Proceso de Desarrollo de SW basado en UML

... Proceso Iterativo e IncrementalLas actividades se encadenan en una mini-cascada con un alcance limitado por los objetivos de la iteracinn vecesIV. Proceso de Desarrollo de SW basado en UML

Proceso Iterativo e IncrementalEnfoqueCascadaEnfoqueIterativo eIncrementalIV. Proceso de Desarrollo de SW basado en UML

Fases del Ciclo de VidaEl ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versin del producto

Cada ciclo est compuesto por fases y cada una de estas fases est compuesta por un nmero de iteraciones

Las fases son:Inicio o Estudio de oportunidadElaboracinConstruccinTransicin IV. Proceso de Desarrollo de SW basado en UML

...Fases del Ciclo de VidaInicio o Estudio de oportunidad (inception)Define el mbito y objetivos del proyectoSe define la funcionalidad y capacidades del producto

ElaboracinTanto la funcionalidad como el dominio del problema se estudian en profundidadSe define una arquitectura bsicaSe planifica el proyecto considerando recursos disponibles

IV. Proceso de Desarrollo de SW basado en UML

...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 documentacinIV. Proceso de Desarrollo de SW basado en UML

...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 iteracionesIV. Proceso de Desarrollo de SW basado en UML

Esfuerzo respecto de las Workflows15%10%15%30%15%10% gestin cambios5% mantenimientoUna iteracin en lafase de elaboracinRequisitosDiseoImplementacinPruebasAnlisis

...Esfuerzo respecto de las FasesEsfuerzo: 5%20% 65% 10%Duracin: 10%30% 50% 10%Una iteracin en lafase de elaboracinRequisitosDiseoImplementacinPruebasAnlisisIV. Proceso de Desarrollo de SW basado en UML

Conclusiones

Claves en el Desarrollo de SIHerramientasp.e. Rational RoseProcesop.e. Rational Unified ProcessNotacinUMLV. Conclusiones

Contexto de Desarrollo: Grado de Complejidad V. Conclusiones

Bibliografa RecomendadaUMLwww.omg.org/uml/Meta-links www.celigent.com/uml/ y www.cetus-links.org/oo_uml.html Pierre-Alain Muller Instant UMLMartin Fowler, UML Destilled (UML Gota a Gota)Terry Quatrani, Visual Modeling ..., un caso de estudio

Herramientas CASEHerramientas basadas en UML www.objectsbydesign.com/tools/umltools_byPrice.html International Council in SE (INCOSE) www.incose.org/tools/Herramientas basadas en UML www.objectsbydesign.com/tools/umltools_byPrice.htmlOtrasRevista IEEE Software, Conferencias: OOPSLA, ECOOP Patrones www.enteract.com/bradapp/docs/patterns-intro.html, Tutoriales en ingls www.celigent.com/omg/umlrtf/tutorials.htm

V. Conclusiones

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."

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

... Hay dos formas de construir software: una es hacerlo tan simple que obviamente no existan deficiencias, otra es hacerlo tan complejo que no existan deficiencias obvias C:A.R. Hoare, Turing Award Lecture 1980.Para mayores detalles respecto de estos problemas consultar:Real-Life Object-Oriented Systems, Soren Lauesen, IEEE Software March/April 1998.Sintaxis para denominar objetos:: C una instancia annima de la clase C/ R una instancia annima desempeando el rol R/ R : C una instancia annima de la clase C desempeando el rol RO / R una instancia llamada O desempeando el rol RO : C una instancia llamada O de la clase CO / R : C una instancia llamada O, de la clase C y desempeando el rol RO una instancia llamada O

El proceso propuesto tiene mucho en comn con el modelo de proceso propuesto por Barry Bohem en 1988: El modelo espiral. Los cuadrantes de la espiral son: Determinar objetivos, alternativas y restricciones Evaluar alternativas, identificar y resolver riesgos, construir proptotiposDesarrollo y verificacin del productoPlanificacin de las siguientes fasesFigura Triangle for Success adaptada desde Visual Modeling with Rational Rose and UML de Terry Quatrani Extraida desde la presentacin Software Architecture and UML de Grady Booch (Rational Software).