Desarrollos de Software Orientados a Objetos usando UML

Presentación del tema: "Desarrollos de Software Orientados a Objetos usando UML"— Transcripción de la presentación:

1 Desarrollos de Software Orientados a Objetos usando UML
Agustín J. González OOP&D. Material Tomado de: Departamento Sistemas Informáticos y Computación (DSIC) Universidad Politécnica de Valencia (UPV) - España

2 Introducción Modelado de SW

3 Construcción de una casa para “fido”
I. Introducción: Modelado de SW Construcción de una casa para “fido” Puede hacerlo una sola persona Requiere: Modelado mínimo Proceso simple Herramientas simples Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).

4 Construcción de una casa
I. Introducción: Modelado de SWI Construcción de una casa Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Construida eficientemente y en un tiempo razonable por un equipo Requiere: Modelado Proceso bien definido Herramientas más sofisticadas

5 Construcción de un rascacielos
I. Introducción: Modelado de SI Construcción de un rascacielos Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Obviamente el debe ser el contexto de desarrollo (envergadura del proyecto) el que determine la configuración adecuada del proceso y los recursos necesarios. Existen propuestas radicales que promueven un proceso/modelado más “ligth”, tales como: Extreme Programming (Kent Beck) y Agile Modeling (Scott Ambler). Sin embargo, para proyectos de envergadura es difícil eludir un proceso y modelado más rigurosos. Una lectura interesante: Extreme Programming in the Quick-change Era 'Beware of the religion of the code-generating modeling tool.‘by Alexandra Weber Morales About 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."

6 Claves en Desarrollo de SI
I. Introducción: Modelado de SWI Claves en Desarrollo de SI Notación Figura “Triangle for Success” adaptada desde “Visual Modeling with Rational Rose and UML” de Terry Quatrani Herramientas Proceso

7 Abstracción - Modelado Visual (MV)
I. Introducción: Modelado de SW Abstracción - Modelado Visual (MV) “El modelado captura las partes esenciales del sistema” Proceso de Negocios Orden Item envío Sistema Computacional

8 MV para manejar la complejidad
I. Introducción: Modelado de SW MV para manejar la complejidad “... 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.

9 MV promueve la reutilización
I. Introducción: Modelado de SW MV promueve la reutilización Múltiples Sistemas Componentes Reutilizados

10 ¿Por qué la Orientación a Objetos?
III. El Paradigma Orientado a Objeto ¿Por qué la Orientación a Objetos? Proximidad de los conceptos de modelado respecto de las entidades del mundo real Mejora captura y validación de requisitos Acerca el “espacio del problema” y el “espacio de la solución” Modelado integrado de propiedades estáticas y dinámicas del ámbito del problema Facilita construcción, mantenimiento y reutilización

11 ¿Por qué la Orientación a Objetos?
III. El Paradigma Orientado a Objeto ¿Por qué la Orientación a Objetos? Conceptos comunes de modelado durante el análisis, diseño e implementación Facilita la transición entre distintas fases Favorece el desarrollo iterativo del sistema Disipa la barrera entre el “qué” y el “cómo” Sin embargo, existen problemas ...

12 III. El Paradigma Orientado a Objeto
Problemas en OO “...Los conceptos básicos de la OO se conocen desde hace dos décadas, pero su aceptación todavía no está tan extendida como los beneficios que esta tecnología puede sugerir” “...La mayoría de los usuarios de la OO no utilizan los conceptos de la OO de forma purista, como inicialmente se pretendía. Esta práctica ha sido promovida por muchas herramientas y lenguajes que intentan utilizar los conceptos en diversos grados” --Wolfgang Strigel

13 III. El Paradigma Orientado a Objeto
… Problemas en OO Un objeto contiene datos y operaciones que operan sobre los datos, pero ... Podemos distinguir dos tipos de objetos degenerados: Un objeto sin datos (que sería lo mismo que una biblioteca de funciones) Un objeto sin “operaciones”, con sólo operaciones del tipo crear, recuperar, actualizar y borrar (que se correspondería con las estructuras de datos tradicionales) Un sistema construido con objetos degenerados no es un sistema verdaderamente orientado a objetos Para mayores detalles respecto de estos problemas consultar: “Real-Life Object-Oriented Systems”, Soren Lauesen, IEEE Software March/April 1998.

14 Fundamentos de Modelado OO

15 III. El Paradigma OO: Fundamentos de Modelado OO
Objetos Objeto = unidad atómica que encapsula estado y comportamiento La encapsulación en un objeto permite una alta cohesión y un bajo acoplamiento Un objeto puede caracterizar una entidad física (coche) o abstracta (ecuación matemática)

16 III. El Paradigma OO: Fundamentos de Modelado OO
… Objetos El Modelado de Objetos permite representar el ciclo de vida de los objetos a través de sus interacciones En UML, un objeto se representa por un rectángulo con un nombre subrayado Otro Objeto Un Objeto más Sintaxis para denominar objetos: : C una instancia anónima de la clase C / R una instancia anónima desempeñando el rol R / R : C una instancia anónima de la clase C desempeñando el rol R O / R una instancia llamada O desempeñando el rol R O : C una instancia llamada O de la clase C O / R : C una instancia llamada O, de la clase C y desempeñando el rol R O una instancia llamada O

17 III. El Paradigma OO: Fundamentos de Modelado OO
… Objetos Ejemplo de varios objetos relacionados:

18 III. El Paradigma OO: Fundamentos de Modelado OO
… Objetos Objeto = Identidad + Estado + Comportamiento El estado está representado por los valores de los atributos Un atributo toma un valor en un dominio concreto

19 III. El Paradigma OO: Fundamentos de Modelado OO
Clases y Objetos

20 III. El Paradigma OO: Fundamentos de Modelado OO
Estado El 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 estímulo externo representado como mensaje enviado desde otro objeto

21 III. El Paradigma OO: Fundamentos de Modelado OO
Comportamiento Ejemplo de interacción:

22 III. El Paradigma OO: Fundamentos de Modelado OO
… Comportamiento Los mensajes navegan por los enlaces, a priori en ambas direcciones Estado y comportamiento están relacionados Ejemplo: no es posible aterrizar un avión si no está volando. Está volando como consecuencia de haber despegado del suelo

23 III. El Paradigma OO: Fundamentos de Modelado OO
Persistencia La persistencia de los objetos designa la capacidad de un objeto trascender en el espacio/tiempo Podremos después reconstruirlo, es decir, cogerlo de memoria secundaria para utilizarlo en la ejecución (materialización del objeto) Los lenguajes OO no proponen soporte adecuado para la persistencia, la cual debería ser transparente, un objeto existe desde su creación hasta que se destruya

24 III. El Paradigma OO: Fundamentos de Modelado OO
Comunicación Un sistema informático puede verse como un conjunto de objetos autónomos y concurrentes que trabajan de manera coordinada en la consecución de un fin específico El comportamiento global se basa pues en la comunicación entre los objetos que la componen

25 III. El Paradigma OO: Fundamentos de Modelado OO
… Comunicación III. El Paradigma OO: Fundamentos de Modelado OO Categorías de objetos: Activos - Pasivos Cliente – Servidores, Agentes Objeto Activo: posee un hilo de ejecución (thread) propio y puede iniciar una actividad Objeto Pasivo: no puede iniciar una actividad pero puede enviar estímulos una vez que se le solicita un servicio Cliente es el objeto que solicita un servicio. Servidor es el objeto que provee el servicio solicitado

26 III. El Paradigma OO: Fundamentos de Modelado OO
… Comunicación Los agentes reúnen las características de clientes y servidores Son la base del mecanismo de delegación Introducen indirección: un cliente puede comunicarse con un servidor que no conoce directamente

27 III. El Paradigma OO: Fundamentos de Modelado OO
… Comunicación Ejemplo en el que un agente hace de aislante: Sevidor 1 Un agente Servidor 2 Un cliente

28 III. El Paradigma OO: Fundamentos de Modelado OO
El Concepto de Mensaje La unidad de comunicación entre objetos se llama mensaje El mensaje es el soporte de una comunicación que vincula dinámicamente los objetos que fueron separados previamente en el proceso de descomposición Adquiere toda su fuerza cuando se asocia al polimorfismo y al enlace dinámico

29 … El Concepto de Mensaje
III. El Paradigma OO: Fundamentos de Modelado OO … El Concepto de Mensaje Objeto 1 : Mensaje A Objeto 2 : Mensaje C : Mensaje E Objeto 3 Objeto 4 : Mensaje D

30 Proceso de Desarrollo de SW basado en UML

31 ¿Qué es un Proceso de Desarrollo de SW?
IV. Proceso de Desarrollo de SW basado en UML Define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo No existe un proceso de software universal. Las características de cada proyecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable Sistema nuevo o modificado Requisitos nuevos o modificados Proceso de Desarrollo de Software

32 IV. Proceso de Desarrollo de SW basado en UML
Historia de RUP Pruebas funcionales Pruebas de desempeño Gestión de requisitos Gestión de cambios y configuración Ingeniería de Negocio Ingeniería de datos Diseño de interfaces Rational Unified Process 1998 Rational Objectory Process UML Objectory Process Enfoque Ericsson

33 IV. Proceso de Desarrollo de SW basado en UML
Dos Dimensiones

34 Fases e Hitos (Milestones)
IV. Proceso de Desarrollo de SW basado en UML Fases e Hitos (Milestones) Inception Elaboration Construction Transition Objetivos (Vision) Arquitectura Capacidad Operacional Inicial Release del Producto tiempo

35 Proceso Iterativo e Incremental
IV. Proceso de Desarrollo de SW basado en UML Proceso Iterativo e Incremental El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables que se muestran a los usuarios y clientes En el ciclo de vida iterativo a cada iteración se reproduce el ciclo de vida en cascada a menor escala Los objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes El proceso propuesto tiene mucho en común 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 proptotipos Desarrollo y verificación del producto Planificación de las siguientes fases

36 ... Proceso Iterativo e Incremental
IV. Proceso de Desarrollo de SW basado en UML ... Proceso Iterativo e Incremental Las actividades se encadenan en una mini-cascada con un alcance limitado por los objetivos de la iteración Análisis Diseño Codific. Pruebas e Integración n veces

37 Proceso Iterativo e Incremental
IV. Proceso de Desarrollo de SW basado en UML Proceso Iterativo e Incremental Enfoque Cascada Enfoque Iterativo e Incremental

38 IV. Proceso de Desarrollo de SW basado en UML
Fases del Ciclo de Vida El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versión del producto Cada ciclo está compuesto por fases y cada una de estas fases está compuesta por un número de iteraciones Las fases son: Inicio o Estudio de oportunidad Elaboración Construcción Transición

39 IV. Proceso de Desarrollo de SW basado en UML
...Fases del Ciclo de Vida Inicio o Estudio de oportunidad (inception) Define el ámbito y objetivos del proyecto Se define la funcionalidad y capacidades del producto Elaboración Tanto la funcionalidad como el dominio del problema se estudian en profundidad Se define una arquitectura básica Se planifica el proyecto considerando recursos disponibles

40 IV. Proceso de Desarrollo de SW basado en UML
...Fases del Ciclo de Vida Construcción El producto se desarrolla a través de iteraciones donde cada iteración involucra tareas de análisis, diseño e implementación Las fases de estudio y análisis sólo dieron una arquitectura básica que es aquí refinada de manera incremental conforme se construye (se permiten cambios en la estructura) Gran parte del trabajo es programación y pruebas Se documenta tanto el sistema construido como el manejo del mismo Esta fase proporciona un producto construido junto con la documentación

41 IV. Proceso de Desarrollo de SW basado en UML
...Fases del Ciclo de Vida Transición Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas de marketing, empaquetado atractivo, instalación, configuración, entrenamiento, soporte, mantenimiento, etc. Los manuales de usuario se completan y refinan con la información anterior Estas tareas se realizan también en iteraciones

42 Esfuerzo respecto de las Workflows
I n c e p t i o E l a b o r t i n C o n s t r u c i T r a n s i t o 15% Requisitos Una iteración en la fase de elaboración 10% Análisis 15% Diseño 30% Implementación 15% Pruebas P r e l i m n a y I t o ( s ) i t e r . # 1 i t e r . # 2 i t e r . # n i t e r . # n + 1 i t e r . # n + 2 i t e r . # m i t e r . # m + 1 5% mantenimiento 10% gestión cambios

43 ...Esfuerzo respecto de las Fases
IV. Proceso de Desarrollo de SW basado en UML ...Esfuerzo respecto de las Fases I n c e p t i o E l a b o r t i n C o n s t r u c i T r a n s i t o Requisitos Una iteración en la fase de elaboración Análisis Diseño Implementación Pruebas P r e l i m n a y I t o ( s ) i t e r . # 1 i t e r . # 2 i t e r . # n i t e r . # n + 1 i t e r . # n + 2 i t e r . # m i t e r . # m + 1 Esfuerzo: % 20% % % Duración: 10% 30% % %

44 Conclusiones

45 Claves en el Desarrollo de SI
V. Conclusiones Claves en el Desarrollo de SI Notación UML Figura “Triangle for Success” adaptada desde “Visual Modeling with Rational Rose and UML” de Terry Quatrani Herramientas p.e. Rational Rose Proceso p.e. Rational Unified Process

46 Contexto de Desarrollo: Grado de Complejidad
V. Conclusiones Contexto de Desarrollo: Grado de Complejidad Extraida desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).

47 Bibliografía Recomendada
V. Conclusiones UML Meta-links y Pierre-Alain Muller “Instant UML” Martin Fowler, “UML Destilled” (“UML Gota a Gota”) Terry Quatrani, “Visual Modeling ...”, un caso de estudio Herramientas CASE Herramientas basadas en UML International Council in SE (INCOSE) Otras Revista IEEE Software, Conferencias: OOPSLA, ECOOP Patrones Tutoriales en inglés