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

Presentación del tema: "Ventajas del análisis y diseño orientado a objetos"— Transcripción de la presentación:

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ño orientado 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 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 Implem. AOO DOO Investigación del Problema Solución Lógica Código Encontrar y describir Objetos en el dominio Del problema Definición de objetos Lógicos de software (atributos, métodos)

22 Análisis y Diseño O.O. Analogía de Negocios Qué son los procesos
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

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 (ilustrado en un conjunto de diagramas que describen los
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
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. Proceso de Ingeniería de Software Requerimientos Nuevos ó Modificados Nuevo ó Modificado Sistema

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

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 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) Administrador Base de Datos Líder de Proyecto Analista Diseñador/ Desarrollador Ingeniero de Desempeño Pruebas Administrador de Configuración

50 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”. Desarrollo Iterativo Modelamiento Visual Verificación de la Calidad Arquitecturas con Componentes Administración de Requerimientos Control de Cambios

51 Desarrollo Iterativo de Software
Dados los sistemas de software sofisticados de la actualidad, no es posible hacer de manera secuencial la definición completa del problema, diseñar la solución completa, construir el software y por último probarlo. El descubrimiento de defectos en fases posteriores de diseño dan como resultado un aumento en los costos y/ó la cancelación del proyecto. El tiempo y dinero gastados en la implementación de un diseño fallido, son no recuperables

52 Desarrollo Iterativo Requerimientos Análisis y Diseño Implementación
Pruebas Evaluación Cada iteración produce un producto ejecutable

53 Características del Desarrollo Iterativo
Permite un entendimiento incremental del problema a través de refinamientos sucesivos. Habilita una fácil retroalimentación de usuario. Metas específicas permiten que el equipo de desarrollo mantenga su atención en producir resultados. El progreso es medido conforme avanzan las implementaciones.

54 Administración de Requerimientos
Licitar, organizar, y documentar la funcionalidad y restricciones requeridas. Llevar un registro y documentación de cambios y decisiones. Los requerimientos de negocio son fácilmente capturados y comunicados a través de casos de uso. Los casos de uso son instrumentos importantes de planeación. Modelo de Diseño Modelo de Implementación Modelo de Prueba verifica realización influenciado por Los casos de uso dirigen el trabajo desde el análisis hasta las pruebas

55 Arquitectura Basada en Componentes
Se enfoca en el pronto desarrollo de una arquitectura ejecutable robusta. Resistente al cambio mediante el uso de interfaces bien definidas. Intuitivamente comprensible. Promueve un reuso más efectivo de software. Es derivada a partir de los casos de uso más importantes.

56 Modelación Visual de Software
Captura la estructura y comportamiento de arquitecturas y componentes. Muestra como encajan de forma conjunta los elementos del sistema. Mantiene la consistencia entre un diseño y su implementación. Promueve una comunicación no ambigua.

57 Verificación de la Calidad del Software
Crea pruebas para cada escenario (casos de uso) para asegurar que todos los requerimientos están propiamente implementados. Verifica la calidad del software con respecto a los requerimientos basados en la confiabilidad, funcionalidad, desempeño de la aplicación y del sistema. Prueba cada iteración Los problemas del software son de 100 a 1000 veces mas costosos de encontrar y reparar después del desarrollo

58 Control de Cambios del Software
Controlar, llevar un registro y monitorear cambios para permitir un desarrollo iterativo. Establece espacios de trabajo seguros para cada desarrollador Provee aislamiento de cambios hechos en otros espacios de trabajo Controla todos los artefactos de software – modelos, código, documentos, etc… ALERT REPORT Administración de Espacios de Trabajo Desarrollo en Paralelo Integración de Proceso Administración de Construcción

59 Estructura de RUP El proceso puede describirse en dos dimensiones, o a lo largo de dos ejes: El eje horizontal representa tiempo y muestra el aspecto dinámico del proceso, expresado en términos de ciclos, fases, iteraciones, y metas. El eje vertical representa el aspecto estático del proceso; como está descrito en términos de actividades, artefactos, trabajadores y flujos de trabajo.

60 Iteración(es) Preliminar
Estructura de RUP Cont. Fases Flujos de Trabajo de Procesos Inicio Elaboración Construcción Transición Modelación de Negocios Requerimientos Análisis y Diseño Contenido Implementación Prueba Desarrollo Flujos de Trabajo de Soporte Admin. Configuración Administración Ambiente Iteración(es) Preliminar Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Iteraciones

61 Fases en RUP Metas Principales Tiempo
Inicio – Define el alcance del proyecto Elaboración – Plan del proyecto, especificación de características, arquitectura base Construcción – Construir el producto Transición – Transición del producto a la comunidad del usuario Inicio Elaboración Construcción Transición Tiempo Metas Principales

62 Fase de Inicio Propósito Resultado
Establecer casos de negocios para un nuevo sistema o para alguna actualización importante de un sistema existente Especificar el alcance del proyecto Resultado Una visión general de los requerimientos del proyecto, i.e., los requerimientos principales Un modelo inicial de casos de uso y modelo del dominio (10-20%) Un caso de negocios inicial, incluyendo: Evaluación inicial de riesgos Una estimación de los recursos requeridos

63 Ejemplo de Diagrama de Caso de Uso de Negocios
Caso de Negocios: modelar la empresa (como funciona la empresa a la que se le va a desarrollar el software)

64 Fase de Elaboración Propósito Resultado
Analizar el dominio del problema Establecer una buena arquitectura Lidiar con los elementos de riesgo más altos del proyecto Desarrollar un plan comprensivo mostrando como el proyecto será completado Resultado Un modelo del dominio y de casos de uso 80% completo Requerimientos suplementarios que capturen los requerimientos no funcionales y cualesquiera requerimientos que no estén asociados con un caso de uso específico Una lista de riesgos revisada

65 Fase de Construcción Propósito Productos
Desarrollar incrementalmente producto de software completo el cual estará listo para ser transferido al usuario Productos Un modelo completo de diseño y casos de uso Liberaciones de productos ejecutables de funcionalidad incremental Documentación de usuario Una liberación “beta” del producto

66 Fase de Transición Hacer la transición final del producto de software al usuario Productos Liberaciones ejecutables de producto “Pruebas beta” para validar el nuevo sistema vs. las expectaciones del usuario Manuales de usuario actualizados Documentación de desarrollo actualizada Está el usuario satisfecho? Gastos reales de los recursos vs. Gastos previstos  Aceptables?

67 Iteraciones Cada fase en RUP puede descomponerse en iteraciones. Una iteración es un ciclo de desarrollo completo dando como resultado una entrega de producto ejecutable (interna o externa) Iteración Preliminar Iteración de Arquitectura Iteración de Desarrollo Iteración de Transición Inicio Elaboración Construcción Transición Liberaciones iteraciones internas externas

68 Describe una unidad de trabajo que puede ser asignada a un trabajador.
Noción de Proceso Describe una unidad de trabajo que puede ser asignada a un trabajador. Actividad/Cómo? Trabajador/Quién? Rol que puede ser desempeñado por un individuo o conjunto de individuos en la organización de desarrollo Diseño de Casos de uso Diseñador responsable de Artefacto/Qué? Pieza de información que es producida, modificada, ó utilizada por un proceso Paquete de Caso de Uso Caso de Uso

69 Modelos y Flujos de Trabajo
Una mera enumeración de todos los trabajadores, actividades y artefactos no constituyen un proceso. Se necesita una forma de describir secuencias significativas que produzcan algún resultado válido, y que muestre la interacción entre trabajadores. Un flujo de trabajo es una secuencia de actividades que producen un resultado de valor observable. En términos de UML pueden ser expresados como un diagrama de secuencia, un diagrama de colaboración, ó como un diagrama de actividad. Los grupos de trabajo agrupan actividades en forma lógica

70 Modelos y Flujos de Trabajo Cont.
Cada flujo de trabajo describe como crear y mantener un modelo en particular Modelación de Negocios Modelo de Negocios Flujo de Trabajo de Requerimientos realizado por Modelo de Caso de Uso Flujo de Trabajo de Diseño de Análisis Implementado por Modelo de Diseño Flujo de Trabajo de Implementación verificado por Modelo de Implementación Flujo de Trabajo de Prueba Modelo de Prueba

71 Referencias A Simplified Approach to RUP Gary K. Evans President, Evanetics, Inc. UML y Patrones, Introducción al Análisis y Diseño Orientado a Objetos Craig Larman Prentice-Hall Rational Unified Process, Best Practices for Software Development Teams A Rational Software Corporation White Paper