1 / 15

Análisis y Diseño O.O.

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

chance
Download Presentation

Análisis y Diseño O.O.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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 (RUP) : Describe un posible orden de actividades y un ciclo de vida de desarrollo. • UML : Lenguaje de Modelamiento Unificado.

  2. Análisis y Diseño O.O. Patrones GRASP : Codifican 9 principios fundamentales de asignación de responsabilidades. 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. 2. Encontrar Abstraciones u objetos apropiados 3. Crear un modelo conceptual que identifique los objetos (conceptos) en el dominio del problema

  3. ADOO Implement AOO DOO Investigación del problema Encontrar y describir objetos en el dominio del problema Solución Lógica Definición de objetos lógicos de software (atributos, métodos) Código 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).

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

  5. 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.)

  6. El Modelo Conceptual 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. 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.

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

  8. Los Diagramas de Interacción Se expresa con Diagramas de Interacción: de colaboración y de secuencia (muestran el flujo de mensajes entre instancias de objetos y el llamado a los métodos) 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 interactúan los objetos a través de mensajes

  9. Los Diagramas de Clases Sugieren Se expresa con Diagramas de Clases (Definición de clases que deben implementarse) 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 Revisar diagramas de Interacción

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

  11. AD Estructurado vs ADOO S.I. Biblioteca SIB Catálogo Bibliotecario Registrar Préstamos Adicionar Recursos Generar Informes Libro Biblioteca ADE : Descomposición con base en funciones - Jerarquía de subprocesos que componen procesos ADOO : Descomposición por objetos o conceptos ADE ADOO

  12. El Proceso de Desarrollo OOSE Jacobson Booch Booch RUP OMT Rumbaugh UML RUP : Proceso Unificado Rational Influencias sobre el RUP

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

  14. UML Apoya el desarrollode aplicaciones Relaciones Objetos Objetos del negocio Sistemas a gran escala ORDBMS Oracle UNIFIED MODELING LANGUAGE Clases Descomposición de la aplicación Components Microsoft Escenarios CORBA OMG Casos de uso ActiveX/COM Microsoft Procesos del negocio

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

More Related