Analisis Y DiseñO Orientado Objetos
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Analisis Y DiseñO Orientado Objetos

  • 25,992 views
Uploaded on

Exposicion hecha en clases

Exposicion hecha en clases

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
25,992
On Slideshare
25,882
From Embeds
110
Number of Embeds
5

Actions

Shares
Downloads
871
Comments
0
Likes
2

Embeds 110

http://www.slideshare.net 39
http://www.isp.fuac.edu.co 37
http://gc.scalahed.com 25
http://gc.initelabs.com 5
http://aulavirtual.utel.edu.mx 4

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Análisis y diseño de sistemas orientado a objetos Johana carolina camargo buelvas Lady johana tristancho paez UPC
  • 2. Introducción
    • Hoy en día la tecnología orientada a objetos ya no se aplica solamente a los lenguajes de programación, además se viene aplicando en el análisis y diseño con mucho éxito, al igual que en las bases de datos. para hacer una buena programación orientada a objetos hay que desarrollar todo el sistema aplicando esta tecnología, de ahí la importancia del análisis y el diseño orientado a objetos.
    • La programación orientada a objetos es una de las formas más populares de programar y viene teniendo gran acogida en el desarrollo de proyectos de software desde los últimos años.
  • 3. Perspectiva histórica
    • la programación fue hecha en una manera secuencial o lineal, es decir una serie de pasos consecutivos con estructuras consecutivas y bifurcaciones.
    • Los lenguajes basados en esta forma de programación ofrecían ventajas al principio, pero el problema ocurre cuando los sistemas se vuelven complejos. Estos programas escritos al estilo “espaguetti” no ofrecen flexibilidad y el mantener una gran cantidad de líneas de código en sólo bloque se vuelve una tarea complicada.
    • Frente a esta dificultad aparecieron los lenguajes basados en la programación estructurada. La idea principal de esta forma de programación es separar las partes complejas del programa en módulos o segmentos que sean ejecutados conforme se requieran. De esta manera tenemos un diseño modular, compuesto por módulos independientes que puedan comunicarse entre sí. Poco a poco este estilo de programación fue reemplazando al estilo “espaguetti” impuesto por la programación lineal.
  • 4.
    • Fomenta la reutilización y extensión del código.
    • Permite crear sistemas más complejos.
    • Relacionar el sistema al mundo real.
    • Facilita la creación de programas visuales.
    • Construcción de prototipos
    • Agiliza el desarrollo de software
    • Facilita el trabajo en equipo
    • Facilita el mantenimiento del software
    Ventajas del lenguaje orientado a objetos
  • 5. El modelo orientado a objetos
    • Para entender este modelo debemos tratar con los siguientes conceptos básicos:
      • Objeto
      • Clase
      • Herencia
  • 6. ¿ Qué es un objeto ?
    • Un objeto del mundo real es cualquier cosa que vemos a nuestro alrededor, donde poseen las siguientes cualidades : identidad , estado y comportamiento.
  • 7. ¿ Que es una clase ?
    • Conjunto de objetos que poseen características similares , es decir objetos del mismo tipo.
  • 8. Diferencia entre clase y objeto
    • Clase: Es un conjunto de objetos relacionados. Ejemplo: La clase Zapato.
    • Objeto: Es una instancia de una clase. Ejemplo: Zapato mocasín.
  • 9. ¿ Que es la herencia ?
    • La herencia es uno de los conceptos más cruciales en la POO. La herencia básicamente consiste en que una clase puede heredar sus variables y métodos a varias subclases (la clase que hereda es llamada superclase o clase padre). Esto significa que una subclase, aparte de los atributos y métodos propios, tiene incorporados los atributos y métodos heredados de la superclase. De esta manera se crea una jerarquía de herencia.
  • 10. En general, podemos tener una gran jerarquía de Clases tal y como vemos en el siguiente gráfico:
  • 11. Envío de mensajes
    • Un objeto es inútil si está aislado. El medio empleado para que un objeto interactúe con otro son los mensajes. Hablando en términos un poco más técnicos, los mensajes son invocaciones a los métodos de los objetos.
  • 12.
    • Abstracción: La abstracción consiste en captar las características esenciales de un objeto, así como su comportamiento.
    • Encapsulamiento: El encapsulamiento consiste en unir en la Clase las características y comportamientos, esto es, las variables y métodos. Es tener todo esto es una sola entidad.
    • Ocultamiento: Es la capacidad de ocultar los detalles internos del comportamiento de una Clase y exponer sólo los detalles que sean necesarios para el resto del sistema.
    • Polimorfismo: capacidad que tienen objetos de diferentes clases de responder al mismo mensaje. Comportamientos alternos entre clases derivadas relacionadas.
    • Servicio: Es el comportamiento de los objetos. Son métodos o procedimientos, que llegan a ser parte de los objetos, en forma muy similar a los atributos.
    Características asociadas al poo
  • 13.
    • Para el desarrollo de software orientado a objetos no basta usar un lenguaje orientado a objetos. También se necesitará realizar un análisis y diseño orientado a objetos.
    • El modelamiento visual es la clave para realizar el análisis OO. Desde los inicios del desarrollo de software OO han existido diferentes metodologías para hacer esto del modelamiento, pero sin lugar a duda, el Lenguaje de Modelamiento Unificado (UML) puso fin a la guerra de metodologías.
    • Según los mismos diseñadores del lenguaje UML, éste tiene como fin modelar cualquier tipo de sistemas (no solamente de software) usando los conceptos de la orientación a objetos. Y además, este lenguaje debe ser entendible para los humanos y máquinas.
    Análisis y diseño orientado a objetos
  • 14. OOD es...
    • Modular
    • Efectos laterales mínimos (encapsulamiento)
    • Programación por extensión
    • Orientado a datos
    • Explota la herencia (jerárquico)
    • Reutilización de clases
    • Fácil de modificar
  • 15. Ventajas de OOD
    • Módulos con fuerte cohesión interna y escaso acoplamiento externo (sin variables globales, …)
    • Facilita el funcionamiento en entorno multiprocesador (objetos distribuidos)
    • Correspondencia directa con el mundo real
    • Prototipos rápidos
    • Herramientas y bibliotecas muy amplias
    • Aplicaciones construidas enganchando objetos
    • Mejor comprensión y mantenimiento
  • 16. Inconvenientes de OOD
    • Impactos desfavorables sobre espacio y tiempo de ejecución
    • Forma de pensar diferente: curva de aprendizaje lenta
    • Peligro de atomización, con dificultad de comprensión global
    • Herencia y ligadura dinámica dificulta las pruebas
  • 17. Metodologías de Análisis y Diseño (OOA/OOD)
    • Booch (OOAD)
    • Rumbaugh (OMT)
    • Jacobson (OOSE)
    • UML (Unified Modelling Language)
      • Lenguaje visual
      • Unión de los tres anteriores
      • Estándar internacional (OMG)
      • Versión actual: 2.0
    • UP (Unified Process)
      • Metodología de diseño iterativo
      • Basada en casos de uso
      • Incorpora UML de forma natural
  • 18.
    • - Diseñar es un proceso iterativo e incremental - Ni top-down, ni bottom-up: "ida y vuelta" - Modelo en espiral - dirigido según los riesgos (risk driven)
    • Pasos de la Metodología de Booch
    • 1- Identificar las clases y los objetos a un cierto nivel de abstracción 2- Identificar la semántica de esas clases y objetos 3- Identificar las relaciones entre esas clases y objetos 4- Implementar esas clases y objetos
    Metodología de Booch
  • 19. Metodología de Rumbaugh (OMT)
    • Modelos
  • 20. Metodología de Diseño
  • 21. Metodología de Jacobson (OOSE)
  • 22. ¿ Que es UML ?
    • El Lenguaje de Modelamiento Unificado (UML) es un lenguaje para especificar, construir, visualizar y documentar los elementos que componen un sistema de software intensivo.
    • El UML es una notación para escribir modelos de objetos
    • Define los diagramas, sus gráficos y su semántica
  • 23. principales beneficios de UML
    • Mejores tiempos totales de desarrollo (de 50 % o más).
    • Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.
    • Establecer conceptos y artefactos ejecutables.
    • Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
    • Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
    • Mejor soporte a la planeación y al control de proyectos.
    • Alta reutilización y minimización de costos.
  • 24. Autores de UML
    • - Autores
    • * Grady Booch: Booch-91, 93 * James Rumbaugh y otros : OMT-1, OMT-2 * Ivar Jacobson y otros: OOSE
    • - Aportes importantes
    • * Rebeca Wirfs-Brock
    • * Shlaer y Mellor
    • - Aportes importantes No-OO
    • * Harrel: Diagramas de estados * Work flow: Diagramas de Actividades
  • 25. UML, ¿Método o Lenguaje de Modelado? Un modelo es expresado en un lenguaje de modelado . Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelo y los símbolos utilizados en los modelos y un conjunto de mecanismos generales o reglas que indican cómo utilizar los elementos. Las reglas son sintácticas, semánticas y pragmáticas.
  • 26. Proceso de Unificación
  • 27. Partes de UML
    • Vistas
      • Conjunto de diagramas
    • Diagramas
      • 9 tipos de grafos
      • Combinan los elementos del modelo
    • Elementos del modelo
      • Clases, objetos, mensajes, relaciones
    • Mecanismos generales
      • Comentarios, información, semántica, extensiones y adaptaciones
  • 28. VISTAS
    • Vista de Casos de Uso
      • Funcionalidad externa del sistema
    • Vista Lógica
      • Estructura estática y conducta dinámica del sistema
    • Vista de Componentes (software)
      • Organización de las componentes
    • Vista de Concurrencia
      • Comunicaciones y sincronización
    • Vista de Despliegue ( deployment )
      • Arquitectura física
  • 29. Las Vistas en UML Casos uso lógica comp conc despliegue
  • 30. Casos de uso Los casos de uso requieren tener al menos un conocimiento parcial de los requerimientos del sistema. Un caso de uso es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso. Vista de Casos de uso
  • 31. El formato para la descripción de los casos de uso es el siguiente: Caso de uso : Nombre Actores : Lista de actores (agentes externos) Propósito : Intención del caso de uso Resumen : Repetición del caso de uso de alto nivel o alguna síntesis. Tipo : Primario, secundario u opcional. Esencial o real. Referencias cruzadas : Casos de uso relacionados y funciones relacionadas del sistema. Descripción : Descripción del caso de uso. Vista de Casos de uso
  • 32. Ejemplo : el siguiente caso de uso describe el proceso de comprar artículos en una tienda, a través de un terminal de punto de venta. Caso de uso : Comprar productos Actores : Cliente, cajero Tipo : Primario Descripción : Un Cliente llega a la caja registradora con los artículos que va a comprar. El Cajero registra los artículos y cobra el importe. Al terminar la operación, el Cliente se marcha con los productos. Es conveniente comenzar con los casos de uso de más alto nivel para lograr comprender mejor los principales procesos globales. Vista de Casos de uso
  • 33. Diagrama UML de casos de uso para el sistema de punto de venta: Este esquema tiene por objeto ofrecer un diagrama contextual que nos permita conocer rápidamente los actores externos de un sistema y las formas básicas en que éstos lo utilizan. Vista de Casos de uso
  • 34. Un diagrama de casos de uso más refinado seria el siguiente: Vista de Casos de uso
  • 35. Casos de Uso
    • Dirigida al Análisis de Requisitos (lo que quiere hacer el usuario)
    • Describe la funcionalidad del sistema, como la perciben los actores externos
    • Dirige el desarrollo de las otras vistas
    • Define los objetivos finales del sistema
    • Permite validar el sistema
    • Actor externo:
      • Usuario
      • Otro sistema
    • Se plasma en diagramas
      • de Casos de Uso
      • de Actividad
  • 36. Vista Lógica
    • Describe la funcionalidad interna
    • Dirigida a diseñadores y desarrolladores
    • Define la estructura estática
      • Clases, objetos y relaciones
    • Define las colaboraciones dinámicas
      • Mensajes y funciones
    • Propiedades adicionales
      • Persistencia y concurrencia
      • Interfaces y estructura interna de las clases
  • 37.
    • Se plasma en diagramas
      • Estáticos
        • de Clases
        • de Objetos
      • Dinámicos
        • de Estado
        • de Secuencia
        • de Colaboración
        • de Actividad
    Vista Lógica
  • 38. Vista de Componentes
    • Describe los módulos del sistema y sus dependencias
    • Dirigida a desarrolladores
    • Se plasma en diagramas
      • de Componentes
  • 39. Vista de Concurrencia
    • Describe la división del sistema en procesos y procesadores
    • Dirigida a desarrolladores e integradores
    • Resuelve problemas de
      • uso eficiente de los recursos
      • ejecución en paralelo (hilos)
      • comunicación y sincronización de hilos
    • Se plasma en diagramas
      • dinámicos
      • de Componentes
      • de Despliegue
  • 40. Vista de Despliegue
    • Muestra la distribución física del sistema (ordenadores, dispositivos) y sus conexiones
    • Dirigida a desarrolladores, integradores y probadores
    • Se plasma en
      • el diagrama de Despliegue
      • el mapa de asignación de componentes a la arquitectura física
  • 41. Tipos de Diagramas
    • De Casos de Uso
    • Estáticos
      • de Clases
      • de Objetos
    • Dinámicos
      • de Estado
      • de Secuencia
      • de Colaboración
      • de Actividad
    • De Componentes
    • De Despliegue (deployment)
  • 42. Diagramas de secuencia El diagrama de secuencia de un sistema muestra gráficamente los eventos que originan los actores y que impactan al sistema. La creación de los diagramas de secuencia depende de la formulación de los casos de uso. Durante la operación del sistema, los actores generan eventos, solicitando alguna operación a cambio. Ejemplo: cuando un cajero ingresa un código de barras de un artículo, está pidiendo al sistema de TPV que registre esa compra. Con este evento se inicia una operación en el sistema.
  • 43. Antes de hacer el diseño lógico de la aplicación de software, es conveniente investigar y definir su comportamiento como una "caja negra". Se estudia el comportamiento del sistema , desde la perspectiva de qué es lo que hace, y no de cómo lo hace. Diagramas de secuencia Definición: El diagrama de secuencia de un sistema es una representación que muestra, en determinado escenario de un caso de uso, los eventos generados por actores externos, su orden y los eventos internos del sistema. En esta fase del proyecto, el sistema mismo es una caja negra.
  • 44. Recordemos el caso de uso Comprar productos: Caso de uso: Comprar productos Actores: Cliente, cajero Tipo: Primario Descripción: Un Cliente llega a la caja registradora con los artículos que va a comprar. El Cajero registra los artículos y cobra el importe. Al terminar la operación, el Cliente se marcha con los productos. Diagramas de secuencia
  • 45. El diagrama de secuencia del caso de uso ComprarProductos podría ser el siguiente: Diagramas de secuencia
  • 46. Diagramas de colaboración Diagramas de colaboración Los diagramas de interacción (diagramas de secuencia y diagramas de colaboración) explican gráficamente cómo los objetos interactúan a través de mensajes para realizar las tareas. Antes de definir estos diagramas, hay que generar el modelo conceptual y los casos de uso reales (estos últimos se generan a partir de los casos de uso definidos en el análisis).
  • 47. Diagramas de colaboración Los diagramas de colaboración explican gráficamente las interacciones entre las instancias del modelo (objetos). Por ejemplo:
  • 48. Diseño de la solución Para cada evento del sistema se debe construir un diagrama de colaboración cuyo mensaje inicial sea el de sus eventos. En el caso del punto de venta, tendremos tres diagramas, uno para cada evento: pasarProducto , terminarVenta , y efectuarPago . Diagramas de colaboración
  • 49. El diagrama de colaboración del caso de uso pasarProducto sería el siguiente: Diagramas de colaboración
  • 50. Diagramas de clases
  • 51. Análisis y Diseño OO Las herramientas usadas en la etapa de análisis (investigación del problema) se pueden resumir en la siguiente tabla. Herramienta de análisis Preguntas que contesta Casos de uso ¿Cuáles son los procesos del dominio? Modelo conceptual ¿Cuáles son los conceptos, los términos? Diagramas de secuencia ¿Cuáles son los eventos y las operac. del sistema?
  • 52. Análisis y Diseño OO
  • 53. muchas gracias por su atencion