Desarrollo de Software Orienta a Objetos

1. 1. Desarrollo de Software Orientado a Objetos Carolina Valencia Gil Carolina Henao Acosta
Juan Pablo Ortiz Villegas

2. 2. INTRODUCCION <ul><li>El análisis y diseño orientado a objetos (ADOO) es un enfoque

de la ingeniería del software . </li></ul><ul><li>Modela un Sistema como un grupo de
objetos que interactúan entre sí. </li></ul><ul><li>Dominio en términos de conceptos
compuestos por verbos y sustantivos, clasificados deacuerdo a su dependencia funcional.
</li></ul><ul><li>En este método se crea un conjunto de modelos utilizando una notación
acordada, Eje: UML. </li></ul><ul><li>No está orientado solamente a diseño de programas
de computadora, cubre sistemas de distintos tipos. </li></ul><ul><li>El lenguaje unificado
de modelado se ha vuelto el lenguaje de modelado estándar usado en análisis y diseño
orientado a objetos. </li></ul>

3. 3. Conceptos de la POO <ul><li>Se basa en Objetos y ofrece dos ventajas con respecto a la
programación tradicional: </li></ul><ul><li>Permite al programador organizar un
programa de acuerdo a abstracciones de mas alto nivel, la manera de pensar de la gente.
</li></ul><ul><li>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. </li></ul>

4. 4. Análisis Orientado a Objetos objeto objeto objeto datos funciones objeto Objetos
Globales que contienen datos y funciones locales.

5. 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. 6. Desarrollo de Software Orientado a Objetos

7. 7. <ul><li>MODELO DE REQUISITOS </li></ul><ul><li>Permite delimitar y darle claridad al

problema con sus implicaciones, con el acompañamiento del usuario pero con la
perspectiva del desarrollador. </li></ul>

8. 8. <ul><li>MODELO DE REQUISITOS </li></ul><ul><li>Descripción del problema

</li></ul><ul><li>Informe preliminar de necesidades </li></ul><ul><li>Modelo de Casos
de Uso </li></ul><ul><li>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.
</li></ul>

9. 9. <ul><li>MODELO DE REQUISITOS </li></ul><ul><li>Actores </li></ul><ul><li>Son

entidades externas al software que no necesariamente son los usuarios.
</li></ul><ul><li>Son la herramienta principal para modelar los casos de uso </li></ul>

10. 10. <ul><li>MODELO DE REQUISITOS </li></ul>MODELO DE CASOS DE USO Se lee la

descripción del problema y se discute con los actores

11. 11. <ul><li>MODELO DE REQUISITOS </li></ul><ul><li>Extensión

</li></ul><ul><li>Inclusión </li></ul>
12. 12. <ul><li>MODELO DE REQUISITOS </li></ul><ul><li>Generalización
</li></ul><ul><li>Documentación </li></ul>

13. 13. <ul><li>MODELO DE REQUISITOS </li></ul><ul><li>Ejemplo de Documentación

</li></ul>

14. 14. <ul><li>MODELO DE REQUISITOS </li></ul><ul><li>Modelo de Interfaces

</li></ul><ul><li>Describe la presentación de información entre los actores y el sistema.
</li></ul><ul><li>Se especifica en detalle como se verán las interfaces de usuario al
ejecutar cada uno de los casos de uso. </li></ul>

15. 15. <ul><li>MODELO DE REQUISITOS </li></ul><ul><li>Ejemplo de Interfaces Gráficas

</li></ul>

16. 16. <ul><li>MODELO DE REQUISITOS </li></ul><ul><li>Ejemplo de Interfaces Gráficas

</li></ul>

17. 17. <ul><li>MODELO DE REQUISITOS </li></ul><ul><li>Modelo de Dominio del Problema

</li></ul><ul><li>Define un modelo de clases común, para los analistas y los clientes.
</li></ul><ul><li>El desarrollador deberá definir con base a lo que el usuario describa, los
objetos que va a utilizar en el desarrollo. </li></ul><ul><li>Es importante separar las clases
en módulos cuando el sistema es muy grande. </li></ul>

18. 18. <ul><li>MODELO DE REQUISITOS </li></ul><ul><li>Identificación de Clases

</li></ul><ul><li>Se toma la descripción del problema y se resaltan los sustantivos para
obtener las clases candidatas. </li></ul>

19. 19. <ul><li>MODELO DE REQUISITOS </li></ul><ul><li>Identificación de Clases

</li></ul><ul><li>Se seleccionan las clases mas relevantes, teniendo en cuenta:
</li></ul><ul><li>Que no tengan que ver con interfaces de usuario </li></ul><ul><li>Que
sean claras y no permitan ambigüedades </li></ul><ul><li>Que no sean de actores del
sistema </li></ul><ul><li>Que no sean redundantes </li></ul>

20. 20. <ul><li>MODELO DE REQUISITOS </li></ul><ul><li>Clases Identificadas y Diagrama de

Clases </li></ul>

21. 21. <ul><li>MODELO DE REQUISITOS </li></ul><ul><li>Diagrama de Asociaciones

</li></ul>

22. 22. <ul><li>MODELO DE REQUISITOS </li></ul>Diagrama de Clases con Asociaciones

23. 23. <ul><li>MODELO DE REQUISITOS </li></ul><ul><li>Diagrama de Clases con Roles

</li></ul>

24. 24. <ul><li>MODELO DE REQUISITOS </li></ul>Diagrama de Clases con Roles

25. 25. <ul><li>MODELO DE REQUISITOS </li></ul><ul><li>Identificación de Atributos

</li></ul>

26. 26. <ul><li>MODELO DE REQUISITOS </li></ul>Diagrama de Clases con Atributos

27. 27. MODELO DE ANÁLISIS <ul><li>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. </li></ul><ul><li>No se considera el ambiente de implementación
todavía , en otras palabras el análisis pretende modelar el sistema bajo condiciones
ideales. </li></ul><ul><li>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. </li></ul>

28. 28. MODELO DE ANÁLISIS

29. 29. Arquitectura de clases <ul><li>El modelo de análisis tiene como objetivo generar una
arquitectura de objetos que sirva como base para el diseño posterior del sistema.
</li></ul><ul><li>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 </li></ul><ul><li>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.
</li></ul>

30. 30. <ul><li>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): </li></ul>

31. 31. <ul><li>La vista o presentación corresponde a los bordes que se le presentan al usuario
para el manejo de la información. </li></ul><ul><li>La información representa el dominio
del problema y es almacenada en una base de datos </li></ul><ul><li>Por otro lado el
control corresponde a la manipulación de la información a través de sus diversas
presentaciones. </li></ul><ul><li>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 </li></ul><ul><li>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.
</li></ul>

32. 32. Clases con Estereotipos <ul><li>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: </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>

33. 33. Clases con Estereotipos

34. 34. MODELO DE DISEÑO <ul><li>Prototipos de Diseño </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>

35. 35. <ul><li>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. </li></ul>MODELO DE DISEÑO

36. 36. <ul><li>Es un refinamiento y formalización adicional al modelo de análisis.

</li></ul><ul><li>El resultado son especificaciones muy detalladas de todos los objetos,
incluyendo sus operaciones y atributos. </li></ul><ul><li>Es requerido ya que el modelo
de análisis no es lo suficientemente formal para poder llegar al código fuente
</li></ul><ul><li>Se busca además aspectos como: Requisitos de rendimiento,
necesidades de tiempo real, concurrencia, manejo de BD. </li></ul><ul><li>Durante el
diseño se puede ver si los resultados del análisis son apropiados para su implementación.
</li></ul><ul><li>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. </li></ul>MODELO DE DISEÑO

37. 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. 38. <ul><li>Aspectos principales del modelo del diseño </li></ul><ul><li>Diseño de

Objetos: Se refina y formaliza el modelo para generar especificaciones muy detalladas de
todos los objetos incluyendo operaciones y atributos. </li></ul><ul><li>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. </li></ul>MODELO DE
DISEÑO
39. 39. Estrategias de diseño <ul><li>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. </li></ul><ul><li>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:
</li></ul><ul><li>El sistema debe estar protegido contra parámetros incorrectos
proporcionados por el usuario. </li></ul><ul><li>El sistema no debe optimizarse hasta que
funcione de manera correcta. </li></ul>MODELO DE DISEÑO

40. 40. <ul><li>Reuso: Aspecto fundamental, cuanto mas se pueda reutilizar el código mayor
será su robustez. Posibilidades de mejorar el reuso: </li></ul><ul><li>A través de la
herencia se puede incrementar el reuso del código. </li></ul><ul><li>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. </li></ul><ul><li>El encapsulamiento es efectivo para lograr el reuso.
</li></ul>Estrategias de diseño MODELO DE DISEÑO

41. 41. <ul><li>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:
</li></ul><ul><li>No se deben exportar estructuras de datos desde un método.
</li></ul><ul><li>Una clase debe tener un conocimiento limitado de la arquitectura de
clases del sistema. </li></ul><ul><li>Se debe n evitar expresiones de caso s (case) sobre
tipos de objetos. </li></ul><ul><li>Se debe distinguir entre operaciones privadas y
públicas. </li></ul>Estrategias de diseño MODELO DE DISEÑO

42. 42. Diseño de Objetos <ul><li>Es un proceso de añadir detalles al análisis y tomar
decisiones junto con diseño de sistema </li></ul><ul><li>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. </li></ul>MODELO DE DISEÑO

43. 43. Diseño de Objetos <ul><li>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 . </li></ul>MODELO DE DISEÑO

44. 44. Diseño de Objetos <ul><li>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. </li></ul><ul><li>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. </li></ul>MODELO DE DISEÑO

45. 45. Diseño de Objetos <ul><li>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. </li></ul>MODELO DE DISEÑO

46. 46. Diseño de Objetos <ul><li>Ejemplo Colaboraciones: </li></ul>MODELO DE DISEÑO

47. 47. Diseño de Objetos <ul><li>Subsistemas: </li></ul><ul><li>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”.
</li></ul>MODELO DE DISEÑO

48. 48. <ul><li>En esta etapa lo más importante es definir el código fuente de la aplicación.
</li></ul><ul><li>El modelo de implementación toma el resultado del modelo de diseño
para generar el código final. </li></ul><ul><li>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. </li></ul><ul><li>Ejemplo: si se necesita una funcionalidad
que no fue diseñada </li></ul>MODELO DE IMPLEMENTACION

49. 49. <ul><li>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. </li></ul><ul><li>La
elección del lenguaje influye en el diseño, pero el diseño no debe depender de los detalles
del lenguaje. </li></ul><ul><li>Ejemplo: Si se cambia de lenguaje de programación no
debe requerirse el re-diseño del sistema. </li></ul>MODELO DE IMPLEMENTACION

50. 50. <ul><li>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. </li></ul><ul><li>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: </li></ul><ul><ul><li>Formatos para la asignación de nombres a
las variables. </li></ul></ul><ul><ul><li>Estilo de programación.
</li></ul></ul><ul><ul><li>Métodos de documentación.
</li></ul></ul><ul><ul><li>Documentación en línea. </li></ul></ul>MODELO DE
IMPLEMENTACION

51. 51. <ul><ul><li>Editor de texto para escribir el código fuente como un archivo de tipo
texto plano. </li></ul></ul><ul><ul><li>ejemplo: notepad para guardar los archivos como
HTML </li></ul></ul><ul><ul><li>Intérprete que procese el código fuente y lo ejecute
</li></ul></ul><ul><ul><li>ejemplo: el browser que ejecuta scripts en javaScript al cargar
la página web </li></ul></ul><ul><ul><li>Debugger que ayude a depurar los errores y a
corregir el código fuente hasta lograr un programa ejecutable sin errores
</li></ul></ul><ul><ul><li>Ejemplo: el browser que envía mensajes para encontrar errores
al ejecutar el programa </li></ul></ul>MODELO DE IMPLEMENTACION Herramientas a
utilizar
52. 52. <ul><li>Encargado de revisar la calidad del sistema desarrollado
</li></ul><ul><li>Debe ser planificado y tenido en cuenta durante toda la etapa del
desarrollo </li></ul>MODELO DE PRUEBAS <ul><li>TIPOS DE PRUEBAS
</li></ul><ul><li>Verificación </li></ul><ul><li>Validación </li></ul>

53. 53. <ul><li>Prueba de Regresión </li></ul><ul><li>Prueba de Operación

</li></ul><ul><li>Prueba de Escala Completa </li></ul><ul><li>Prueba de Rendimiento
</li></ul><ul><li>Prueba de Sobrecarga </li></ul><ul><li>Prueba Negativa
</li></ul><ul><li>Prueba basada en requisitos o de casos de uso </li></ul><ul><li>Pruebas
Ergonómicas </li></ul><ul><li>Prueba de Documentación de Usuario
</li></ul><ul><li>Prueba de Aceptación o de Validación </li></ul>MODELO DE PRUEBAS
TECNICAS DE PRUEBAS

54. 54. <ul><li>Prueba de Unidad </li></ul><ul><li>Prueba de Especificación o de caja de

negra </li></ul><ul><li>Prueba Basada en Estados </li></ul><ul><li>Prueba Estructural
</li></ul><ul><li>Prueba de Integración </li></ul><ul><li>Prueba de Sistema
</li></ul>MODELO DE PRUEBAS NIVEL DE PRUEBAS

55. 55. MODELO DE PRUEBAS

56. 56. MODELO DE PRUEBAS

57. 57. MODELO DE PRUEBAS

58. 58. MODELO DE PRUEBAS