Ventajas del análisis y diseño orientado a objetos

1. Ventajas del análisis y diseño orientado a objetos Centrado en : • La identificación de objetos y la definición de clases • La organización jerarquizada de clases • La reutilización de clases • La construcción de marcos estructurales de aplicación a partir de librerías de clases

2. Proceso de análisis y diseño orientado a objetos • El resultado de un diseño orientado a objetos es una jerarquía de clases. Estr. de control propias • Clase  Módulo  Datos • Problema en forma natural Objetos y métodos asociados. • Objetos se agrupan en Clases se agrupan en Subclases • Nivel superior es el marco estructural

3. Pasos fundamentales del análisis y diseñoorientado a objetos • Identificación y definición de objetos y clases • Organización de relaciones entre clases • Extracción de estructuras en una jerquía de clases • Construcción de librerías de clases y marcos estructurales de aplicación reutilizables

4. Identificación y definición de objetos • El diseño de un sistema orientado a objetos comienza con los • objetos. • Identificación de objetos: • Inspección gramatical de documentos • Derivación a partir de diagramas de flujo y de relación de entidades

5. Directrices para ayudar a identificar y definir clases y Métodos • Modelar con clases las entidades que ocurren de forma natural en el problema • Diseñar métodos de finalidad única • Diseñar un nuevo método al encontrar una oportunidad de ampliar uno existente • Evitar métodos extensos • Guardar como variables de instancia los datos necesitados por más de un método, o por una subclase • Diseñar pensando en una librería de clases, no pensar solo en la aplicación actual.

6. Cúando crear un clase? Cúando añadir un método? • Dicha nueva clase representa una abstracción significativa del problema • Sea posible que los servicios que proporciona sean utilizados por varias clases más • Su conducta sea inherente compleja • La clase o método haga poco uso de las representaciones de sus valores matemáticos • Si se presentara como un método de otra clase, pocos usuarios de ésta la invocarían

7. Definición y organización de clases • Objetos  Clases Biblioteca de clases • Algunas metodologías para mejorar las jerarquías • Mejorar los protocolos estándar • Construcción de clases abstractas • Identificación de marcos estructurales (frameworks)

8. Algunas metodologías para mejorar las jerarquías • Mejorar los protocolos estándar: nombres y comportamiento de mensajes y métodos • Asignar a mensajes y métodos nombres similares • Reelaborar cualquier código que compruebe de forma explícita la clase de un objeto. (Clases que puedan enviar un mensaje directamente a un objeto) • Reducir el número de argumentos descomponiendo un mensaje en varios • Reducir el tamaño de los métodos

9. Algunas metodologías para mejorar las jerarquías • Construcción de clases abstractas • Identificar mensajes y métodos comunes y transladarlos a una superclase • Eliminar de una superclase aquellos métodos que son ignorados frecuentemente, en su lugar que los hereden subclases. • Acceder a todas las variables solamente mediante el envío de mensajes • Reelaborar las subclases para construir especializaciones

10. Algunas metodologías para mejorar las jerarquías • Identificación de marcos estructurales (frameworks) Objetivo último del diseño orientado a objetos, nivel más alto de abstracción. • Identificar subclases que realicen el mismo método de formas diferentes • Identificar y dividir clases en las que algunos métodos solo accedan a ciertas variables de instancia y otros métodos sólo accedan a otras • Enviar mensajes a otras clases en lugar de hacerlo a la propia clase • Identificar conjunto de métodos combinados en una clase sólo para acceder a variables de instancia comunes (translado de métodos)

11. Herencia • La jerarquía de clases es un mecanismo a través del cual los cambios (a altos niveles) se pueden propagar inmediatamente a través de todo el sistema. • En cada nivel de la jerarquía de clases, pueden añadirse nuevos atributos y operaciones a aquéllos que han sido heredados de niveles superiores de la jerarquía.

12. Herencia Opciones para crear una clase: • La clase puede diseñarse e implementarse de la nada  No se usa herencia. • Se puede rastrear la jerarquía de clases para determinar si una clase ascendiente contiene la mayoría de atributos y operaciones requridas. La nueva clase hereda de su clase ascendiente y pueden añadirse otros elementos si hacen falta.

13. Herencia • Las características de una clase existente pueden sobreescribirse (mecanismo de sustitución) y se pueden implementar versiones de atributos u operaciones para la nueva clase (mecanismo de enriquecimiento). • La jerarquía de clases estructurarse de tal manera que los atributos y operaciones requeridas pueden ser heredados por la nueva clase.

14. Encapsulamiento Beneficios principales de la arquitectura O.O: • Detalles de implementación interna de datos y procedimientos están ocultos al mundo exterior (ocultamiento de información) Se reduce la propagación de efectos colaterales cuando ocurren cambios. • Las estructuras de datos y las operaciones que las manipulan están mezcladas en una entidad sencilla: la clase se facilita la reutilización de componentes.

15. Encapsulamiento • Las interfaces entre objetos encapsulados están simplificadas. Un objeto que envía un mensaje no tiene que pereocuparse de los detalles de las estructuras de datos internos en el objeto receptor se simplifica la interacción, se tiende a reducir el acoplamiento del sistema.

16. Defectos comunes en el diseño • Modificación directa. Clases que hacen modificaciones directas a los valores de datos en otras clases son una violación directa de la encapsulación. Tales uniones se hacen para diseños inflexibles. • Demasiada responsabilidad. Clases con demasiada responsabilidad son dificiles de entender y de usar. La responsabilidad debe ser repartida entre pequeños paquetes y distribuida. • No responsabilidad. Clases con no responsabilidad no tienen propósito. A menudo se presenta cuando los diseñadores igualan existencia física con existencia de diseño lógico. “El dinero no es un objeto”. • Clases con responsabilidad no usada. Como resultado de componentes de software sin pensar en como ellos interactuan.

17. Modelos ó Metodologías Orientadas a Objetos • GOOD (General Object-Oriented Software Development) • HOOD (Hierarchical Object-Oriented Design • MOOD (Multiple-View Object-Oriented Methodology) • OOA (Object Oriented Analysis) • OMT (Object Modeling Technique) • UML (Unified Modeling Language)

18. Modelos ó Metodologías Orientadas a Objetos • GOOD (General Object-Oriented Software Development), utiliza diagramas de flujo de datos en la fase de especificación para identificar entidades abstractas que se convierten en objetos en la fase de diseño. • HOOD (Hierarchical Object-Oriented Design), es un derivado del método de Booch, desarrollado por la agencia europea del espacio. Comienza por descomponer el problema en objetos y métodos, a continuación se inicia la formalización y organización de objetos utilizando gráficos basados en los diagramas de Booch, la descripción formal se completa usando Leng.Descrpformal.Ada. No tiene clases ni herencia. • MOOD (Multiple-View Object-Oriented Methodology), comienza con un modelo estructurado (Ward/Mellor). Permite el paradigma orientado a objetos pero exige que los procesos concurrentes se expresen como tareas convenio de Ada y no de objetos.

19. Análisis y Diseño O.O. • Preguntas del diseño : • Cómo podrían asignarse responsabilidades a las clases de los objetos ? • Cómo podrían interactuar los objetos ? • Qué deberían hacer las clases ? • Patrones : Ciertas fórmulas solución a problemas de diseño que codifican ejemplarmente principios de diseño. • Procesos de Desarrollo Simple (RPM) : Describe un posible orden de actividades y un ciclo de vida de desarrollo. • UML : Lenguaje de Modelamiento Unificado.

20. Análisis y Diseño O.O. 1. Asignar Responsabilidades a componentes de software es la habilidad más importante del AOO. Porque: • Siempre debe realizarse • Tiene profundos efectos en la robustez, mantenibilidad y reutilización de componentes Patrones GRASP : Codifican 9 principios fundamentales de asignación de responsabilidades. 2. Encontrar Abstraciones u objetos apropiados 3. Crear un modelo conceptual que identifique los objetos (conceptos) en el dominio del problema

21. Implem. DOO AOO Investigación del Problema Código Solución Lógica Definición de objetos Lógicos de software (atributos, métodos) Encontrar y describir Objetos en el dominio Del problema Análisis y Diseño O.O. • Su esencia es enfatizar en el dominio del problema y en una solución lógica desde la perspectiva de objetos (cosas, conceptos, entidades). gràfico

22. Analogía de Negocios Qué son los procesos de negocio? Cuáles son los roles de los empleados? Quién es responsable de qué? Cómo ellos interactúan? ADOO Análisis de Requerimientos Análisis del dominio. Asignación de responsabilidades. Diseño de interacción. Documentos Asociados Casos de Uso Modelo Conceptual Diagramas de diseño de clases. Diagramas de Colaboración Análisis y Diseño O.O.

23. Análisis y Diseño O.O. • Casos de Uso : No son actualmente un instrumento del AOO. Ellos son útiles en la etapa preliminar de descripción de requerimientos (utilícese o no el enfoque O.O.)

24. El Modelo Conceptual • El AOO se ocupa de crear una especificación del dominio del problema y de los requerimientos desde la perspectiva de : a) Clasificación por objetos y b) Entender los términos usados en el dominio del problema. IMPORTANTE El modelo conceptual NO es una descripción de componentes de software. El representa conceptos en el dominio del problema en el mundo real.

25. El Modelo Conceptual Identificación de : • Conceptos • Atributos • Asociaciones En el dominio en donde son considerados importantes La descomposición del dominio del problema Involucra Produce El Modelo Conceptual (ilustrado en un conjunto de diagramas que describen los objetos o conceptos).

26. Los Diagramas de Colaboración El DOO se ocupa de definir especificaciones lógicas de software que llenan los requerimientos funcionales basados en descomposición por tipos de objetos. Etapa esencial : • Asignar responsabilidades a los objetos • Ilustrar cómo interactuán los objetos a través de mensajes Se expresan con Diagramas de Colaboración (muestran el flujo de mensajes entre instancias de objetos y el llamado a los métodos)

27. Los Diagramas de Clases Para definir una clase se deben responder varias preguntas • Cómo se conectan unos objetos con otros ? • Cuáles son los métodos de una clase ? Para responderlas: • Conexiones necesarias entre objetos • Métodos que cada Clase debe definir Sugieren Revisar diagramas de colaboración Se expresa con Diagramas de Clases (Definición de clases que deben implementarse)

28. Los Diagramas de Clases IMPORTANTE Los diagramas de clase NO ilustran conceptos del mundo real, sino que describen Componentes de Software

29. UML AGLUTINA ENFOQUES OO

30. Qué es el UML? • UML es un acrónimo para Unified Modeling Language ( Lenguaje de Modelamiento Unificado) • El UML combina lo mejor de lo mejor en: Conceptos del Modelado de datos (Diagramas Entidad-Relación) Modelado del negocio (Flujo de trabajo) Modelado de objetos Modelado de Componentes • El UML es el lenguaje estándar para visualizar, especificar, construir, y documentar los artefactos en un sistema de software a gran escala. • Puede usarse con todos los procesos, a lo largo del ciclo de vida de desarrollo, y a través de diferentes tecnologías de implementación

31. Conceptos sobre el UML • El UML puede ser usado para: • Mostrar los límites de un sistema y sus principales funciones empleando casos de uso y actores • Ilustrar lo que se desea o espera de los casos de uso a través de diagramas de interacción (interaction diagrams) • Representar la estructura estática de un sistema utilizando diagramas de clase (class diagrams) • Modelar el comportamiento de los objetos con diagramas de transición de estado (state transition diagrams) • Dar a conocer la arquitectura física de implementación con diagramas de componentes (component diagrams) y diagramas de utilización (deployment diagrams) • Extender su funcionalidad con estereotipos

32. Modelos y Diagramas • Un modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle. • Diagrama: una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices conectados por arcos

33. Modelos y Diagramas • Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés • El código fuente del sistema es el modelo más detallado del sistema (y además es ejecutable). Sin embargo, se requieren otros modelos ...

34. Modelos y Diagramas • Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos

35. Diagramas de UML • Diagrama de Casos de Uso • Diagrama de Clases • Diagrama de Objetos Diagramas de Comportamiento Diagrama de Estados Diagrama de Actividad Diagramas de Interacción Diagrama de Secuencia Diagrama de Colaboración Diagramas de implementación Diagrama de Componentes Diagrama de Despliegue

36. Diagramas de UML • Los diagramas expresan gráficamente partes de un modelo

37. Diagrama de Casos de Uso • Casos de Uso son una técnica para capturar información de cómo un sistema o negocio trabaja, o de cómo se desea que trabaje. • No pertenece estrictamente al enfoque orientado a objeto, es una técnica para captura de requisitos

38. Diagrama de Casos de Uso

39. Diagrama de Clases • Muestra la relación entre las entidades, es decir muestra la estructura estática del sistema, también puede ser usado para mostrar las clases de implementación.

40. Diagrama de Clases

41. Diagrama de Secuencia • Muestra las llamadas (mensajes) entre los diferentes objetos y su secuencia.

42. Diagrama de Estado • Modela los diferentes estados de una clase y cuales son las transiciones entre un estado y otro.

43. Diagrama de Actividad • Muestra el flujo entre dos ó más clases mientras procesan una actividad

44. Diagrama de Componentes • Es la vista física del sistema y su propósito es mostrar las dependencias que el software tiene con otros componentes.

45. Rational Unified Process

46. Proceso de Ingeniería de Software Requerimientos Sistema Nuevo ó Modificado Nuevos ó Modificados Qué es un Proceso? • Un proceso define Quién está haciendo Qué, Cuándo y Cómo para lograr un cierto objetivo. En la ingeniería de software el objetivo es construir un producto de software ó mejorar alguno existente.

47. Requerimientos • Si un proceso es utilizado, equipos funcionales diferentes normalmente utilizan procesos y lenguajes de modelación inconsistentes. Pruebas Análisis Diseño ? ? ? • La mayoría de los proyectos de softwareutilizan procesos que no están biendefinidos. En su lugar los miembros del equipo (re)inventan sus propios procesos. ? ? ? ? Herramienta • Los procesos no están apropiadamente relacionados con herramientas, ó no están propiamente automatizados. Proceso ? El Problema

48. Rational Unified Process (RUP) • Captura varias de las mejores prácticas en el desarrollo moderno de software en una forma que es aplicable para un amplio rango de proyectos y organizaciones. • Es una guía de cómo utilizar de manera efectiva UML. • Provee a cada miembro de un equipo un fácil acceso a una base de conocimiento con guías, plantillas y herramientas para todas las actividades críticas de desarrollo. • Crea y mantiene modelos, en lugar de enfocarse en la producción de una gran cantidad de papeles de documentación.

49. Ingeniero deDesempeño AdministradorBase de Datos Administrador deConfiguración Líder deProyecto Analista Diseñador/Desarrollador Pruebas Incremento de la Productividad en Equipo Todos los miembros del equipo comparten • 1 Base de conocimiento • 1 Proceso • 1 Vista de cómo desarrollar software • 1 Lenguaje de modelamiento (UML)

50. Administración de Requerimientos DesarrolloIterativo ModelamientoVisual Verificación dela Calidad Arquitecturas con Componentes Control de Cambios 6 Mejores Prácticas(Best Practices) • RUP describe como utilizar de forma efectiva procedimientos comerciales probados en el desarrollo de software para equipos de desarrollo de software, conocidos como “mejores prácticas”.