Desarrollo de Software Orientado a Objetos

Carolina Valencia Gil Carolina Henao Acosta Juan Pablo Ortiz Villegas

INTRODUCCION
El anlisis y diseo orientado a objetos (ADOO) es un enfoque de la ingeniera del software . Modela un Sistema como un grupo de objetos que interactan entre s. Dominio en trminos de conceptos compuestos por verbos y sustantivos, clasificados deacuerdo a su dependencia funcional. En este mtodo se crea un conjunto de modelos utilizando una notacin acordada, Eje: UML. No est orientado solamente a diseo de programas de computadora, cubre sistemas de distintos tipos. El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estndar usado en anlisis y diseo orientado a objetos.

Conceptos de la POO
Se basa en Objetos y ofrece dos ventajas con respecto a la programacin 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 algn objeto solo los afectaran a el nada ms.

Anlisis Orientado a Objetos

objeto objeto

objeto

objeto

funciones

datos

Objetos Globales que contienen datos y funciones locales.

Anlisis Orientado a Objetos

Objeto x Objeto y

Fecha
objeto

funciones
Da Mes Ao
Ao de 2 Dgitos

funciones

Da Mes Ao

Ao de 4 Dgitos

Desarrollo de Software Orientado a Objetos

MODELO DE REQUISITOS Permite delimitar y darle claridad al problema con sus implicaciones, con el acompaamiento del usuario pero con la perspectiva del desarrollador.

MODELO DE REQUISITOS Descripcin del problema Informe preliminar de necesidades Modelo de Casos de Uso Describe un sistema desde sus distintas formas de utilizacin. Cada caso de uso debe ser guiado por el usuario de manera secuencial por eventos.

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

MODELO DE REQUISITOS

MODELO DE CASOS DE USO Se lee la descripcin del problema y se discute con los actores

MODELO DE REQUISITOS Extensin

Inclusin

MODELO DE REQUISITOS Generalizacin

Documentacin

MODELO DE REQUISITOS Ejemplo de Documentacin

MODELO DE REQUISITOS Modelo de Interfaces Describe la presentacin de informacin entre los actores y el sistema. Se especifica en detalle como se vern las interfaces de usuario al ejecutar cada uno de los casos de uso.

MODELO DE REQUISITOS Ejemplo de Interfaces Grficas

MODELO DE REQUISITOS Ejemplo de Interfaces Grficas

MODELO DE REQUISITOS
Modelo de Dominio del Problema Define un modelo de clases comn, 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 mdulos cuando el sistema es muy grande.

MODELO DE REQUISITOS Identificacin de Clases

1. Se toma la descripcin del problema y se resaltan los sustantivos para obtener las clases candidatas.

MODELO DE REQUISITOS Identificacin de Clases

2. Se seleccionan las clases mas relevantes, teniendo en cuenta: Que no tengan que ver con interfaces de usuario Que sean claras y no permitan ambigedades Que no sean de actores del sistema Que no sean redundantes

MODELO DE REQUISITOS Clases Identificadas y Diagrama de Clases

MODELO DE REQUISITOS
Diagrama de Asociaciones

MODELO DE REQUISITOS

Diagrama de Clases con Asociaciones

MODELO DE REQUISITOS
Diagrama de Clases con Roles

MODELO DE REQUISITOS

Diagrama de Clases con Roles

MODELO DE REQUISITOS
Identificacin de Atributos

MODELO DE REQUISITOS

Diagrama de Clases con Atributos

MODELO DE ANLISIS
El objetivo del modelo de anlisis 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 implementacin todava , en otras palabras el anlisis pretende modelar el sistema bajo condiciones ideales. No es una reflexin del dominio del problema sino una representacin de sta adaptada a la aplicacin particular, genera una representacin conceptual del sistema. Consistiendo de clases de objetos.

MODELO DE ANLISIS

Arquitectura de clases
El modelo de anlisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseo posterior del sistema. Dependiendo de la aplicacin existen diversas arquitecturas que se pueden utilizar, para nuestro caso nos enfocamos en aquellas diseadas para el manejo de sistemas de informacin 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 informacin uno de los tipos de arquitectura ms importantes es la arquitectura MVC-Modelo, vista, control popularizada por los ambientes de desarrollo smalltalk, esta arquitectura se basa en tres dimensiones principales: Modelo (informacin), Vista (Presentacin) y control (comportamiento):

 La vista o presentacin corresponde a los bordes que se le presentan al usuario para el manejo de la informacin. La informacin representa el dominio del problema y es almacenada en una base de datos Por otro lado el control corresponde a la manipulacin de la informacin a travs de sus diversas presentaciones. Aunque exista cierta independencia entre estas tres dimensiones se considera que la manera de presentar la informacin es independiente de la propia informacin y de cmo 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 ms propenso a ser modificado, seguido de la vista y finalmente el modelo.

Clases con Estereotipos

El tipo de funcionalidad o la razn de ser de un objeto dentro de una arquitectura se le conoce como su estereotipo. Para los sistemas de informacin la arquitectura del sistema segn nuestro modelo de anlisis se basa en tres estereotipos bsicos de objetos: El estereotipo entidad (entity en ingls)para objetos que guarden informacin sobre el estado interno del sistema, a corto y largo plazo, correspondiente al dominio del problema. Todo comportamiento naturalmente acoplado con esta informacin tambin 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 ingls) para objetos que implementen la presentacin o vista correspondiente a las bordes del sistema hacia el mundo externo, para todo tipo de actores, no slo usuarios humanos. Un ejemplo de un objeto borde es la funcionalidad de interface de usuario para insertar o modificar informacin sobre el registro de usuario. El estereotipo control (control en ingls) 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 ningn otro tipo de objeto, como el comportamiento que opera en varios objetos entidad a la vez, por ejemplo, hacer alguna computacin y luego devolver el resultado a un objeto borde. Un ejemplo tpico de objeto control es analizar el uso del sistema por parte de algn usuario registrado y presentar tal informacin posteriormente. Este comportamiento no le pertenece a ningn objeto entidad u objeto borde especfico.

Clases con Estereotipos

MODELO DE DISEO
Prototipos de Diseo
Se desarrolla para explorar y comprender la arquitectura particular del sistema, sirve como base para la evaluacin de rendimiento y espacio y para pruebas de redundancia e inconsistencias en el diseo. Identifica cuellos de botella en el sistema y donde se quiere revisar con ms detalle el producto final. Se transforma el anlisis, a una arquitectura particular y detallada del sistema que satisfaga todos los requisitos del sistema, donde las condiciones dadas durante el anlisis se reemplazan por requisitos del ambiente de implantacin particular, se contesta la pregunta del como del sistema.

MODELO DE DISEO
La funcionalidad de los casos de uso ya estructurada por el anlisis es realizada por el modelo de diseo, adaptndose al ambiente de implementacin real y refinndose an ms.

MODELO DE DISEO
Es un refinamiento y formalizacin adicional al modelo de anlisis. El resultado son especificaciones muy detalladas de todos los objetos, incluyendo sus operaciones y atributos. Es requerido ya que el modelo de anlisis no es lo suficientemente formal para poder llegar al cdigo fuente Se busca adems aspectos como: Requisitos de rendimiento, necesidades de tiempo real, concurrencia, manejo de BD. Durante el diseo se puede ver si los resultados del anlisis son apropiados para su implementacin. Se considera el modelo de diseo como una formalizacin del espacio de anlisis, extendindolo para incluir una dimensin adicional correspondiente al ambiente de implementacin.

MODELO DE DISEO

La transicin de anlisis a diseo debe decidirse por separado para cada aplicacin en particular, no es recomendable abarcar los dos modelos al tiempo ya que esto aumenta su complejidad.

MODELO DE DISEO
Aspectos principales del modelo del diseo

Diseo de Objetos: Se refina y formaliza el modelo para generar especificaciones muy detalladas de todos los objetos incluyendo operaciones y atributos. Diseo de Sistema: Se adapta el modelo al ambiente de implementacin. Se incluye identificar e investigar las consecuencias del ambiente de implementacin sobre el diseo.

MODELO DE DISEO
Estrategias de diseo
Arquitectura: Es la organizacin de las clases dentro del sistema, durante el anlisis se gener una arquitectura de clases y su funcionalidad conceptual, aqu esta arquitectura debe detallarse. Robustez: Es uno de los objetivos principales del diseo, jams debe agregarse funcionalidad o simplificar cdigo a expensas de la robustez , se deben escoger lenguajes que apoyen el manejo de excepciones , las principales consideraciones relacionadas con la robustez son: 1. El sistema debe estar protegido contra parmetros incorrectos proporcionados por el usuario. 2. El sistema no debe optimizarse hasta que funcione de manera correcta.

MODELO DE DISEO
Estrategias de diseo
Reuso: Aspecto fundamental, cuanto mas se pueda reutilizar el cdigo mayor ser su robustez. Posibilidades de mejorar el reuso: 1. 2. A travs de la herencia se puede incrementar el reuso del cdigo. El uso de impropio de la herencia puede hacer que los programas sean difciles de mantener, alternativa la delegacin provee un mecanismo para lograr el reuso del cdigo, agregacin a travs de clases intermedias. El encapsulamiento es efectivo para lograr el reuso.

3.

MODELO DE DISEO
Estrategias de diseo
Extensibilidad: La mayora de los sistemas se vuelven extensivos de manera no prevista en el diseo, por lo tanto los componentes reutilizables mejoran la extensibilidad: 1. 2. 3. 4. No se deben exportar estructuras de datos desde un mtodo. 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 pblicas.

MODELO DE DISEO
Diseo de Objetos Es un proceso de aadir detalles al anlisis y tomar decisiones junto con diseo de sistema Para el diseo de objeto se seguir el diseo por responsabilidades (RDD), est basado en un modelo cliente-servidor donde las clases son vistas como clientes cuando generan alguna peticin y como servidores cuando reciben peticiones de otras clases.

MODELO DE DISEO
Diseo de Objetos
Tarjeta de Clase: Tambin conocidas como tarjetas CRC ClaseResponsabilidad-Colaboracin permiten al diseador visualizar las diferentes clases de manera independiente y detallada.

MODELO DE DISEO
Diseo de Objetos
De tal manera se debe especificar una tarjeta para cada clase en el sistema, donde inicialmente las tarjetas incluirn nicamente entradas para el nombre de la clase, mdulo al que pertenecen y estereotipo correspondiente. Dado que an no se ha identificado herencia, no habrn entradas para propiedades, superclase o subclase. Responsabilidades: Uno de los esfuerzos ms grandes del desarrollo y que involucra mayor complejidad es la especificacin del comportamiento de cada una de las clases del sistema.

MODELO DE DISEO
Diseo de Objetos
Colaboraciones: Es indispensable que los objetos dentro de un programa colaboren entre si o de lo contrario el programa consistir de mltiples miniprogramas 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 diseo de objetos.

MODELO DE DISEO
Diseo de Objetos
Ejemplo Colaboraciones:

MODELO DE DISEO
Diseo 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 diseo, 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 IMPLEMENTACION
En esta etapa lo ms importante es definir el cdigo fuente de la aplicacin. El modelo de implementacin toma el resultado del modelo de diseo para generar el cdigo final. Con un buen diseo, la tarea de implementacin es mucho ms fluida, y el implementador se ocupa solo de resolver problemas de implementacin. Ejemplo: si se necesita una funcionalidad que no fue diseada

MODELO DE IMPLEMENTACION
Durante el modelo de implementacin se hace una adaptacin al lenguaje de programacin y la base de datos de acuerdo a la especificacin del diseo y segn las propiedades del lenguaje de implementacin y base de datos. La eleccin del lenguaje influye en el diseo, pero el diseo no debe depender de los detalles del lenguaje. Ejemplo: Si se cambia de lenguaje de programacin no debe requerirse el re-diseo del sistema.

MODELO DE IMPLEMENTACION
En general, no se debe comenzar prematuramente a programar, es importante primero completar el proceso de planeacin del sistema final desarrollado durante el diseo. Se debe usar guas de programacin existentes en la organizacin. Si no existen, el equipo de software deben crear sus propias guas para decidir aspectos como: Formatos para la asignacin de nombres a las variables. Estilo de programacin. Mtodos de documentacin. Documentacin en lnea.

MODELO DE IMPLEMENTACION
Herramientas a utilizar

Editor de texto para escribir el cdigo fuente como un archivo de tipo texto plano. ejemplo: notepad para guardar los archivos como HTML Intrprete que procese el cdigo fuente y lo ejecute ejemplo: el browser que ejecuta scripts en javaScript al cargar la pgina web Debugger que ayude a depurar los errores y a corregir el cdigo fuente hasta lograr un programa ejecutable sin errores Ejemplo: el browser que enva mensajes para encontrar errores al ejecutar el programa

MODELO DE PRUEBAS

Encargado de revisar la calidad del sistema desarrollado Debe ser planificado y tenido en cuenta durante toda la etapa del desarrollo

TIPOS DE PRUEBAS Verificacin Validacin

MODELO DE PRUEBAS
TECNICAS DE PRUEBAS Prueba de Regresin Prueba de Operacin Prueba de Escala Completa Prueba de Rendimiento Prueba de Sobrecarga Prueba Negativa Prueba basada en requisitos o de casos de uso Pruebas Ergonmicas Prueba de Documentacin de Usuario Prueba de Aceptacin o de Validacin

MODELO DE PRUEBAS
NIVEL DE PRUEBAS Prueba de Unidad Prueba de Especificacin o de caja de negra Prueba Basada en Estados Prueba Estructural Prueba de Integracin Prueba de Sistema

MODELO DE PRUEBAS

MODELO DE PRUEBAS

MODELO DE PRUEBAS

MODELO DE PRUEBAS