Desarrollo de Software Orienta a Objetos
Descargar como PPT, PDF12 recomendaciones29,868 vistas
El desarrollo de software orientado a objetos (OOP) utiliza la interacción de objetos para modelar sistemas, apoyándose en principios como el análisis y diseño orientado a objetos (AOO) y el lenguaje de modelado UML. Se enfoca en la creación de modelos de requisitos y arquitecturas que separan clases y funciones, promoviendo la reutilización y robustez del código a través de patrones de diseño establecidos. La implementación y pruebas se realizan para asegurar la calidad y adaptabilidad del sistema, siguiendo guías de programación y técnicas de prueba sistemáticas.
Desarrollo de Software Orienta a Objetos
- 1. Desarrollo de Software Orientado a Objetos Carolina Valencia Gil Carolina Henao Acosta Juan Pablo Ortiz Villegas
- 2. INTRODUCCION El análisis y diseño orientado a objetos (ADOO) es un enfoque de la ingeniería del software . Modela un Sistema como un grupo de objetos que interactúan entre sí. Dominio en términos de conceptos compuestos por verbos y sustantivos, clasificados deacuerdo a su dependencia funcional. En este método se crea un conjunto de modelos utilizando una notación acordada, Eje: UML. No está orientado solamente a diseño de programas de computadora, cubre sistemas de distintos tipos. El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estándar usado en análisis y diseño orientado a objetos.
- 3. Conceptos de la POO Se basa en Objetos y ofrece dos ventajas con respecto a la programación tradicional: Permite al programador organizar un programa de acuerdo a abstracciones de mas alto nivel, la manera de pensar de la gente. Los datos globales desaparecen, se convierten en parte interna de los objetos, por lo tanto los cambios generados en algún objeto solo los afectarían a el nada más.
- 4. Análisis Orientado a Objetos objeto objeto objeto datos funciones objeto Objetos Globales que contienen datos y funciones locales.
- 5. Análisis Orientado a Objetos Objeto x Fecha Objeto y Año de 4 Dígitos funciones objeto Día Mes Año Año de 2 Dígitos funciones Día Mes Año
- 6. Desarrollo de Software Orientado a Objetos
- 7. MODELO DE REQUISITOS Permite delimitar y darle claridad al problema con sus implicaciones, con el acompañamiento del usuario pero con la perspectiva del desarrollador.
- 8. MODELO DE REQUISITOS Descripción del problema Informe preliminar de necesidades Modelo de Casos de Uso Describe un sistema desde sus distintas formas de utilización. Cada caso de uso debe ser guiado por el usuario de manera secuencial por eventos.
- 9. MODELO DE REQUISITOS Actores Son entidades externas al software que no necesariamente son los usuarios. Son la herramienta principal para modelar los casos de uso
- 10. MODELO DE REQUISITOS MODELO DE CASOS DE USO Se lee la descripción del problema y se discute con los actores
- 11. MODELO DE REQUISITOS Extensión Inclusión
- 12. MODELO DE REQUISITOS Generalización Documentación
- 13. MODELO DE REQUISITOS Ejemplo de Documentación
- 14. MODELO DE REQUISITOS Modelo de Interfaces Describe la presentación de información entre los actores y el sistema. Se especifica en detalle como se verán las interfaces de usuario al ejecutar cada uno de los casos de uso.
- 15. MODELO DE REQUISITOS Ejemplo de Interfaces Gráficas
- 16. MODELO DE REQUISITOS Ejemplo de Interfaces Gráficas
- 17. MODELO DE REQUISITOS Modelo de Dominio del Problema Define un modelo de clases común, para los analistas y los clientes. El desarrollador deberá definir con base a lo que el usuario describa, los objetos que va a utilizar en el desarrollo. Es importante separar las clases en módulos cuando el sistema es muy grande.
- 18. MODELO DE REQUISITOS Identificación de Clases Se toma la descripción del problema y se resaltan los sustantivos para obtener las clases candidatas.
- 19. MODELO DE REQUISITOS Identificación de Clases Se seleccionan las clases mas relevantes, teniendo en cuenta: Que no tengan que ver con interfaces de usuario Que sean claras y no permitan ambigüedades Que no sean de actores del sistema Que no sean redundantes
- 20. MODELO DE REQUISITOS Clases Identificadas y Diagrama de Clases
- 21. MODELO DE REQUISITOS Diagrama de Asociaciones
- 22. MODELO DE REQUISITOS Diagrama de Clases con Asociaciones
- 23. MODELO DE REQUISITOS Diagrama de Clases con Roles
- 24. MODELO DE REQUISITOS Diagrama de Clases con Roles
- 25. MODELO DE REQUISITOS Identificación de Atributos
- 26. MODELO DE REQUISITOS Diagrama de Clases con Atributos
- 27. MODELO DE ANÁLISIS El objetivo del modelo de análisis es comprender y generar una arquitectura de objetos para el sistema en base a lo especificado en el modelo de requisitos. No se considera el ambiente de implementación todavía , en otras palabras el análisis pretende modelar el sistema bajo condiciones ideales. No es una reflexión del dominio del problema sino una representación de ésta adaptada a la aplicación particular, genera una representación conceptual del sistema. Consistiendo de clases de objetos.
- 29. Arquitectura de clases El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño posterior del sistema. Dependiendo de la aplicación existen diversas arquitecturas que se pueden utilizar, para nuestro caso nos enfocamos en aquellas diseñadas para el manejo de sistemas de información La funcionalidad de cada arquitectura se determina por la de sus objetos involucrados, ejemplo el manejo de bordes y base de datos , si existen distintos tipos se considera la arquitectura de dos dimensiones.
- 30. En el caso de los sistemas de información uno de los tipos de arquitectura más importantes es la arquitectura MVC-Modelo, vista, control popularizada por los ambientes de desarrollo smalltalk, esta arquitectura se basa en tres dimensiones principales: Modelo (información), Vista (Presentación) y control (comportamiento):
- 31. La vista o presentación corresponde a los bordes que se le presentan al usuario para el manejo de la información. La información representa el dominio del problema y es almacenada en una base de datos Por otro lado el control corresponde a la manipulación de la información a través de sus diversas presentaciones. Aunque exista cierta independencia entre estas tres dimensiones se considera que la manera de presentar la información es independiente de la propia información y de cómo esta se controla Sin embargo, cada una de ellas probablemente experimente cambios a lo largo de la vida del sistema, donde el control es el más propenso a ser modificado, seguido de la vista y finalmente el modelo.
- 32. Clases con Estereotipos El tipo de funcionalidad o “la razón de ser” de un objeto dentro de una arquitectura se le conoce como su estereotipo. Para los sistemas de información la arquitectura del sistema según nuestro modelo de análisis se basa en tres estereotipos básicos de objetos: El estereotipo entidad (“entity” en inglés)para objetos que guarden información sobre el estado interno del sistema, a corto y largo plazo, correspondiente al dominio del problema. Todo comportamiento naturalmente acoplado con esta información también se incluye en los objeto entidad. Un ejemplo de un objeto entidad es un registro de usuario con sus datos y comportamiento asociados. El estereotipo interface o borde (“boundary” en inglés) para objetos que implementen la presentación o vista correspondiente a las bordes del sistema hacia el mundo externo, para todo tipo de actores, no sólo usuarios humanos. Un ejemplo de un objeto borde es la funcionalidad de interface de usuario para insertar o modificar información sobre el registro de usuario. El estereotipo control (“control” en inglés) para objetos que implementen el comportamiento o control especificando cuando y como el sistema cambia de estado, correspondiente a los casos de uso. Los objetos control modelan funcionalidad que no se liga naturalmente con ningún otro tipo de objeto, como el comportamiento que opera en varios objetos entidad a la vez, por ejemplo, hacer alguna computación y luego devolver el resultado a un objeto borde. Un ejemplo típico de objeto control es analizar el uso del sistema por parte de algún usuario registrado y presentar tal información posteriormente. Este comportamiento no le pertenece a ningún objeto entidad u objeto borde específico.
- 34. MODELO DE DISEÑO Prototipos de Diseño Se desarrolla para explorar y comprender la arquitectura particular del sistema, sirve como base para la evaluación de rendimiento y espacio y para pruebas de redundancia e inconsistencias en el diseño. Identifica cuellos de botella en el sistema y donde se quiere revisar con más detalle el producto final. Se transforma el análisis, a una arquitectura particular y detallada del sistema que satisfaga todos los requisitos del sistema, donde las condiciones dadas durante el análisis se reemplazan por requisitos del ambiente de implantación particular, se contesta la pregunta del “como” del sistema.
- 35. La funcionalidad de los casos de uso ya estructurada por el análisis es realizada por el modelo de diseño, adaptándose al ambiente de implementación real y refinándose aún más. MODELO DE DISEÑO
- 36. Es un refinamiento y formalización adicional al modelo de análisis. El resultado son especificaciones muy detalladas de todos los objetos, incluyendo sus operaciones y atributos. Es requerido ya que el modelo de análisis no es lo suficientemente formal para poder llegar al código fuente Se busca además aspectos como: Requisitos de rendimiento, necesidades de tiempo real, concurrencia, manejo de BD. Durante el diseño se puede ver si los resultados del análisis son apropiados para su implementación. Se considera el modelo de diseño como una formalización del espacio de análisis, extendiéndolo para incluir una dimensión adicional correspondiente al ambiente de implementación. MODELO DE DISEÑO
- 37. La transición de análisis a diseño debe decidirse por separado para cada aplicación en particular, no es recomendable abarcar los dos modelos al tiempo ya que esto aumenta su complejidad. MODELO DE DISEÑO
- 38. Aspectos principales del modelo del diseño Diseño de Objetos: Se refina y formaliza el modelo para generar especificaciones muy detalladas de todos los objetos incluyendo operaciones y atributos. Diseño de Sistema: Se adapta el modelo al ambiente de implementación. Se incluye identificar e investigar las consecuencias del ambiente de implementación sobre el diseño. MODELO DE DISEÑO
- 39. Estrategias de diseño Arquitectura: Es la organización de las clases dentro del sistema, durante el análisis se generó una arquitectura de clases y su funcionalidad “conceptual”, aquí esta arquitectura debe detallarse. Robustez: Es uno de los objetivos principales del diseño, jamás debe agregarse funcionalidad o simplificar código a expensas de la robustez , se deben escoger lenguajes que apoyen el manejo de excepciones , las principales consideraciones relacionadas con la robustez son: El sistema debe estar protegido contra parámetros incorrectos proporcionados por el usuario. El sistema no debe optimizarse hasta que funcione de manera correcta. MODELO DE DISEÑO
- 40. Reuso: Aspecto fundamental, cuanto mas se pueda reutilizar el código mayor será su robustez. Posibilidades de mejorar el reuso: A través de la herencia se puede incrementar el reuso del código. El uso de impropio de la herencia puede hacer que los programas sean difíciles de mantener, alternativa la delegación provee un mecanismo para lograr el reuso del código, agregación a través de clases intermedias. El encapsulamiento es efectivo para lograr el reuso. Estrategias de diseño MODELO DE DISEÑO
- 41. Extensibilidad: La mayoría de los sistemas se vuelven extensivos de manera no prevista en el diseño, por lo tanto los componentes reutilizables mejoran la extensibilidad: No se deben exportar estructuras de datos desde un método. Una clase debe tener un conocimiento limitado de la arquitectura de clases del sistema. Se debe n evitar expresiones de caso s (case) sobre tipos de objetos. Se debe distinguir entre operaciones privadas y públicas. Estrategias de diseño MODELO DE DISEÑO
- 42. Diseño de Objetos Es un proceso de añadir detalles al análisis y tomar decisiones junto con diseño de sistema Para el diseño de objeto se seguirá el diseño por responsabilidades (RDD), está basado en un modelo cliente-servidor donde las clases son vistas como clientes cuando generan alguna petición y como servidores cuando reciben peticiones de otras clases. MODELO DE DISEÑO
- 43. Diseño de Objetos Tarjeta de Clase: También conocidas como tarjetas CRC Clase-Responsabilidad-Colaboración permiten al diseñador visualizar las diferentes clases de manera independiente y detallada . MODELO DE DISEÑO
- 44. Diseño de Objetos De tal manera se debe especificar una tarjeta para cada clase en el sistema, donde inicialmente las tarjetas incluirán únicamente entradas para el nombre de la clase, módulo al que pertenecen y estereotipo correspondiente. Dado que aún no se ha identificado herencia, no habrán entradas para propiedades, superclase o subclase. Responsabilidades: Uno de los esfuerzos más grandes del desarrollo y que involucra mayor complejidad es la especificación del comportamiento de cada una de las clases del sistema. MODELO DE DISEÑO
- 45. Diseño de Objetos Colaboraciones: Es indispensable que los objetos dentro de un programa colaboren entre si o de lo contrario el programa consistirá de múltiples “mini-programas” independientes. Las colaboraciones entre objetos se dan en base a las relaciones entre las responsabilidades de las distintas clases. Dado la infinidad de posibles relaciones entre clase, las colaboraciones son la fuente principal de complejidad en el diseño de objetos. MODELO DE DISEÑO
- 46. Diseño de Objetos Ejemplo Colaboraciones: MODELO DE DISEÑO
- 47. Diseño de Objetos Subsistemas: Como se ha podido apreciar hasta el momento, la complejidad del sistema aumenta a medida que se incorporan nuevos detalles en el diseño, algo que por lo general es inevitable. Para lograr un mejor manejo de esta complejidad introducimos el concepto de subsistemas, el cual permite dividir el sistema completo en diversas partes, inspirado en la idea de “divide y conquista”. MODELO DE DISEÑO
- 48. En esta etapa lo más importante es definir el código fuente de la aplicación. El modelo de implementación toma el resultado del modelo de diseño para generar el código final. Con un buen diseño, la tarea de implementación es mucho más fluida, y el implementador se ocupa solo de resolver problemas de implementación. Ejemplo: si se necesita una funcionalidad que no fue diseñada MODELO DE IMPLEMENTACION
- 49. Durante el modelo de implementación se hace una adaptación al lenguaje de programación y la base de datos de acuerdo a la especificación del diseño y según las propiedades del lenguaje de implementación y base de datos. La elección del lenguaje influye en el diseño, pero el diseño no debe depender de los detalles del lenguaje. Ejemplo: Si se cambia de lenguaje de programación no debe requerirse el re-diseño del sistema. MODELO DE IMPLEMENTACION
- 50. En general, no se debe comenzar prematuramente a programar, es importante primero completar el proceso de planeación del sistema final desarrollado durante el diseño. Se debe usar guías de programación existentes en la organización. Si no existen, el equipo de software deben crear sus propias guías para decidir aspectos como: Formatos para la asignación de nombres a las variables. Estilo de programación. Métodos de documentación. Documentación en línea. MODELO DE IMPLEMENTACION
- 51. Editor de texto para escribir el código fuente como un archivo de tipo texto plano. ejemplo: notepad para guardar los archivos como HTML Intérprete que procese el código fuente y lo ejecute ejemplo: el browser que ejecuta scripts en javaScript al cargar la página web Debugger que ayude a depurar los errores y a corregir el código fuente hasta lograr un programa ejecutable sin errores Ejemplo: el browser que envía mensajes para encontrar errores al ejecutar el programa MODELO DE IMPLEMENTACION Herramientas a utilizar
- 52. Encargado de revisar la calidad del sistema desarrollado Debe ser planificado y tenido en cuenta durante toda la etapa del desarrollo MODELO DE PRUEBAS TIPOS DE PRUEBAS Verificación Validación
- 53. Prueba de Regresión Prueba de Operación Prueba de Escala Completa Prueba de Rendimiento Prueba de Sobrecarga Prueba Negativa Prueba basada en requisitos o de casos de uso Pruebas Ergonómicas Prueba de Documentación de Usuario Prueba de Aceptación o de Validación MODELO DE PRUEBAS TECNICAS DE PRUEBAS
- 54. Prueba de Unidad Prueba de Especificación o de caja de negra Prueba Basada en Estados Prueba Estructural Prueba de Integración Prueba de Sistema MODELO DE PRUEBAS NIVEL DE PRUEBAS
Notas del editor
- #9: Modelo de casos de uso : Es describir un sistema desde sus distintas formas de utilización. Cada caso de uso debe ser guiado por el usuario para determinar cual es el que necesito. Modelo de interfaces: Es presentarle al usuario de manera gráfica lo que el quiere, pero haciendo un modelado de cada caso de uso. Tiene que haber consistencia entre la imagen del usuario y el comportamiento real del sistema. Modelo del dominio del problema: Define un modelo de clases común, para los analistas y los clientes. En esta técnica se utiliza un lápiz y un papel para que el cliente dibuje su visión del sistema. El desarrollador deberá definir con base a lo que el usuario describa, los objetos que va a utilizar en el desarrollo. Es importante separar las clases en módulos cuando el sistema es muy grande.
- #10: .