Desarrollo de Software Orienta a Objetos

Desarrollo de Software Orientado a Objetos

Carolina Valencia GilCarolina Henao AcostaJuan Pablo Ortiz Villegas

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.

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.

Análisis Orientado a Objetos

objeto

objeto

objeto

datos

funciones

objeto

Objetos Globales que contienen datos y funciones locales.

Análisis Orientado a Objetos

Objeto x

Fecha

Objeto y

Año de 4

Dígitos

funciones

objeto

DíaMesAño

Año de 2

Dígitos

funciones

DíaMesAño

Desarrollo de Software Orientado a Objetos

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.


• Descripción del problemaInforme preliminar de necesidades

• Modelo de Casos de UsoModelo 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.


Actores• Son entidades externas al software que no

necesariamente son los usuarios.• Son la herramienta principal para modelar

los casos de uso


MODELO DE CASOS DE USOSe lee la descripción del problema y se discute con los actores


• Extensión

• Inclusión


• Generalización

• Documentación


Ejemplo de Documentación


Modelo de InterfacesModelo 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.


Ejemplo de Interfaces Gráficas


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.

MODELO DE REQUISITOSIdentificación de Clases

• Se toma la descripción del problema y se resaltan los sustantivos para obtener las clases candidatas.

MODELO DE REQUISITOSIdentificación de Clases

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


Clases Identificadas y Diagrama de Clases


Diagrama de Asociaciones


Diagrama de Clases con Asociaciones


Diagrama de Clases con Roles


Identificación de Atributos


Diagrama de Clases con Atributos

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.

MODELO DE ANÁLISIS

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.

• 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):

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

Clases con EstereotiposEl 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.

Clases con Estereotipos

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.

• 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

• 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

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

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

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:

5. El sistema debe estar protegido contra parámetros incorrectos proporcionados por el usuario.

6. El sistema no debe optimizarse hasta que funcione de manera correcta.

MODELO DE DISEÑO

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


MODELO DE DISEÑO

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


MODELO DE DISEÑO

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

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

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

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

Diseño de Objetos• Ejemplo Colaboraciones:

MODELO DE DISEÑO

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

• 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

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


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


– 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 IMPLEMENTACIONHerramientas a utilizar

• 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

• 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

• Prueba de UnidadPrueba de Especificación o de caja de negraPrueba Basada en EstadosPrueba Estructural

• Prueba de Integración

• Prueba de Sistema

MODELO DE PRUEBAS

NIVEL DE PRUEBAS

MODELO DE PRUEBAS

Desarrollo de Software Orienta a Objetos

Technology

Transcript of Desarrollo de Software Orienta a Objetos