MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS 4.

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTADO A OBJETOS El modelo y diseo orientado a objetos u OMT( tcnica de modelado de objetos ) se extiende desde el anlisis hasta la implementacin pasando por el diseo . Actualmente es una de las metodologas mas implantadas. Las tcnicas orientadas a objetos permiten que el software se construya a partir de objetos de compartimiento especifico. Los propios objetos se pueden constituir a partir de otros , que a su vez pueden estar formados por otros objetos .Esto nos recuerda a una maquina compleja construida por partes , subpartes y sub-subpartes,etc. La metodologa de desarrollo de software orientada a objetos es cada da ms usada, pues permite desarrollar software fcilmente extensible y reusable. Esto ltimo es slo posible si los desarrolladores conocen muy bien los fundamentos que est basada esta metodologa. Por eso, este curso revisa los conceptos ms importantes que se encuentran en las distintas etapas del desarrollo de software orientado a objetos. El curso parte dando a conocer la base del diseo y programacin de buenas clases, tanto por si solas como a travs del uso de herencia. Luego introduce el concepto de subtipos, como concepto terico que est detrs de las distintas implementaciones de herencia que proveen los lenguajes y provee el marco conceptual de cuando usar referencia. Ms tarde presenta el proceso de desarrollo de software orientado a objetos, primero enfocado en la etapa de diseo, en donde se dan a conocer las distintas relaciones entre clases que podemos encontrar, provee mecanismos para verificar si una clase y las relaciones entre ellas estn bien diseadas, y en particular si la herencia est bien usada. Esto es fundamental para que los diseos a objetos no sean ms complicados de entender que los de procedimientos y para que el software que se disee sea reusable y fcil de extender. Finalmente presenta los aspectos ms importantes de la etapa de anlisis, dando nfasis a la especificacin de casos de uso y a como detectar objetos y clases relevantes en el problema. Durante el curso se usa la notacin UML (estndar) y los programas estn en C++ o Java. Las clases prcticas son en C++ o Java y se usa una herramienta de apoyo al diseo 1

UNIDAD IV

FUNDAMENTOS DE PROGRAMACION

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS 4.1. IMPORTANCIA DEL MODELADO * Los programas son fciles de disear debido a que los objetos reflejan elementos del mundo real. * Las aplicaciones son ms sencillas para los usuarios debido a que los datos innecesarios estn ocultos. * Los objetos son unidades auto contenidas. * La productividad se incrementa debido a que puede reutilizar el cdigo. * Los sistemas son fciles de mantener y se adaptan a las cambiantes necesidades de negocios. * Es ms fcil crear nuevos tipos de objetos a partir de los ya existentes. * Simplifica los datos complejos. * Reduce la complejidad de la transaccin. * Confiabilidad. * Robustez. * Capacidad de ampliacin.

4.2. IDENTIFICAR Y PLANEAR EL PROBLEMA Existen diferentes directrices informales para identificar los elementos de un modelo de objetos. Podemos identificar objetos examinando el planteamiento del problema a la funcin que desempea aquel objeto. Por ejemplo, si implemente una solucin formara parte del espacio solucin. Los objetos pueden ser de diferentes tipos:

Entidades Externas (dispositivos, personas) que maneja informaciones a usar por sistema computacional. Ocurrencias o eventos (transformaciones de una serie de movimientos) que ocurren dentro del contexto de operacin del sistema Papeles o roles (Ing. Vendedor) desempeados por personas que interactan con el sistema Cosas (Partes del dominio del problema) Lugares (Establece el contexto del problema y la funcin general del sistema)

Para ser considerado como valido n objeto debe de tener las siguiente caractersticas:

Informacin retenida Servicio necesario Atributos mltiples Atributos comunes Operaciones comunes Requisitos esenciales FUNDAMENTOS DE PROGRAMACION

UNIDAD IV

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS Un atributo es aquel objeto que ha sido seleccionado para ser incluido en el modelo de anlisis. Tiene por objetivo definir a los objetos. Las operaciones indican el comportamiento del objeto dentro del sistema, cambia uno o ms atributos contenidos en el sistema. Pueden ser clasificados entre tres grandes categoras

Operaciones que manipulan datos Operaciones que realizan algn Calculo Operaciones que monitorizan un objeto frente a la ocurrencia de un sistema de control 3

El ciclo de vida de un objeto puede resumirse de la siguiente manera:

Crear el objeto Modificarlo Manipulacin Borrar

Las actividades conocidas que ocurren durante su ciclo de vida son:

Asignacin de Tarea Panel de control Alarma audible

4.3. IDENTIFICACIN Y ESPECIFICACIONES DE CLASES Clase En la programacin orientada a objetos, una clase es una construccin que se utiliza como un modelo (o plantilla) para crear objetos de ese tipo. El modelo describe el estado y el comportamiento que todos los objetos de la clase comparten. Un objeto de una determinada clase se denomina una instancia de la clase. La clase que contiene (y se utiliz para crear) esa instancia se puede considerar como del tipo de ese objeto, por ejemplo, una instancia del objeto de la clase "Persona" sera del tipo "Persona". Una clase por lo general representa un sustantivo, como una persona, lugar o (posiblemente bastante abstracta) cosa - es el modelo de un concepto dentro de un programa de computadora. Fundamentalmente, encapsula el estado y el comportamiento del concepto que representa. Encapsula el estado a travs de marcadores de datos llamados atributos (o variables miembro o variables de instancia), encapsula el comportamiento a travs de secciones de cdigo reutilizables llamados mtodos. Ms tcnicamente, una clase es un conjunto coherente que consiste en un tipo particular de metadatos. Una clase tiene tanto una interfaz y una estructura. La UNIDAD IV FUNDAMENTOS DE PROGRAMACION

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS interfaz describe cmo interactuar con la clase y sus instancias con mtodos, mientras que la estructura describe cmo los datos se dividen en atributos dentro de una instancia. Una clase tambin puede tener una representacin (metaobjeto) en tiempo de ejecucin, que proporciona apoyo en tiempo de ejecucin para la manipulacin de los metadatos relacionados con la clase. En el diseo orientado a objetos, una clase es el tipo ms especfico de un objeto en relacin con una capa especfica. Los lenguajes de programacin que soportan clases difieren sutilmente en su soporte para diversas caractersticas relacionadas con clases. La mayora soportan diversas formas de herencia. Muchos lenguajes tambin soportan caractersticas para proporcionar encapsulacin, como especificadores de acceso.

Objetos, Clases y Herencia: Los objetos son entidades en un sistema de software que representan instancias de entidades del mundo real Las clases objetos son templates para objetos. Pueden usarse para crear objetos Las clases objetos pueden heredar atributos y servicios de otras clases objetos Objetos: operaciones que operan sobre este estado.

(clientes) que requieren estos servicios cuando necesitan realizar alguna actividad de cmputo.

incluye las declaraciones de todos los atributos y servicios los cuales deben estar asociados con un objeto de esta clase.

UNIDAD IV

FUNDAMENTOS DE PROGRAMACION

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS

4.4. RELACIN ENTRE CLASES Jerarqua de clases. En una base de datos existen objetos que responden a los mismos mensajes, utilizan los mismos mtodos y tienen variables del mismo nombre y tipo. Sera intil definir cada uno de estos objetos por separado por lo tanto se agrupan los objetos similares para que formen una clase, a cada uno de estos objetos se le llama instancia de su clase. Todos los objetos de su clase comparten una definicin comn, aunque difieran en los valores asignados a las variables. As que bsicamente las bases de datos orientados a objetos tienen la finalidad de agrupar aquellos elementos que sean semejantes en las entidades para formar un clase, dejando por separado aquellas que no lo son en otra clase. Por ejemplo: Retomemos la relacin alumno-cursa-materia agregndole la entidad maestro; donde los atributos considerados para cada uno son alumno: Nombre, Direccin, Telfono, Especialidad, Semestre, Grupo; Maestro: Nombre, Direccin, Telfono, Nmero econmico, Plaza, RFC; Materia: Nombre, Crditos, Clave. Los atributos de nombre, direccin y telfono se repiten en la entidad alumno y maestro, as que podemos agrupar estos elementos para formar la clase Persona con dichos campos. Quedando por separado en alumno: Especialidad, semestre, Grupo. Y en maestro: Nmero econmico, Plaza y RFC; la materia no entra en la agrupacin (Clase persona) ya que la clase especfica los datos de solo personas, as que queda como clase materia.

UNIDAD IV

FUNDAMENTOS DE PROGRAMACION

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS 4.5. DISEO DE MTODOS A lo largo de la historia se han utilizado y complementado distintos mtodos. Asimismo, inicia con una breve resea de los acontecimientos histricos ms importantes, desde la Edad Media, el Renacimiento, el siglo XVII con el inici de la separacin entre arte y tcnica culminando en el siglo XIX. A partir del siglo XX, la Bauhaus formaliza los mtodos de un manejo ms objetivo con el surgimiento del funcionalismo. 6 En 1967, la conferencia de Portsmouth en MIT sobre Mtodos emergentes en diseo ambiental y planeacin hizo destacar tres corrientes principales en el campo de los mtodos de diseo: 1. Utilizacin de computadoras en el proceso de diseo 2. Corriente de la creatividad. 3. Corriente central. Posteriormente se describen algunos de los principios manejados por los autores que ms influencia han tenido:

1. Christopher Jones. Inici las ideas sobre la necesidad de un mtodo, as como los conceptos de caja negra y caja transparente. En el primero se considera que el diseador es capaz de producir resultados en los que confa y que a menudo tiene xito, mas no es capaz de explicar cmo lleg ah. Sus caractersticas son:

El diseo final est conformado por experiencias anteriores. Su produccin se ve acelerada mediante el relajamiento de las inhibiciones a la creatividad.

La capacidad de producir resultados depende de la disponibilidad de tiempo.

Repentinamente se percibe una nueva manera de estructurar el problema. Control consciente de las maneras en que se estructura el problema.

Las caractersticas de la caja transparente son: UNIDAD IV FUNDAMENTOS DE PROGRAMACION

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS

Objetivos, variables y criterios fijados de antemano. Anlisis del problema completado antes de iniciar las soluciones. La evaluacin es verbal y lgica. Las estrategias se establecen antes. Las estrategias son lineales y con retroalimentacin.

Ambos mtodos tienen como resultado ampliar el espacio de bsqueda de la solucin al problema de diseo. 7

2. Morriz Asimow. Concibe el proceso de diseo de manera muy similar al de la informacin. As, la actividad proyectual consiste en "la recoleccin, manejo y organizacin creativa de informacin relevante de la situacin del problema (...) tiene carcter iterativo, se dispone de nueva informacin o se gana una nueva comprensin que requiere se repitan operaciones previas. Asimow plantea las siguientes fases:

Anlisis Sntesis Evaluacin Decisin Optimizacin Revisin Implementacin

Podemos encontrar las fuentes de esta tendencia en los mtodos de diseo en el mtodo cientfico y en la teora clsica de la informacin.

3. Bruce Archer - El mtodo sistemtico para diseadores. Publicado durante 1963 y 1964 por la revista inglesa Design. Archer propone como definicin de diseo "...seleccionar los materiales correctos y darles forma para satisfacer las necesidades de funcin y estticas dentro de las limitaciones de los medios de produccin disponibles", por lo tanto, el proceso de diseo debe contener las etapas analtica, creativa y de ejecucin, que a su vez se subdividen en: UNIDAD IV FUNDAMENTOS DE PROGRAMACION

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS 1. Definicin del problema y preparacin del programa detallado. 2. Obtener datos relevantes, preparar especificaciones y retroalimentar la fase 1. 3. Anlisis y sntesis de los datos para preparar propuestas de diseo. 4. Desarrollo de prototipos. 5. Preparar y ejecutar estudios y experimentos que validen el diseo. 6. Preparar documentos para la produccin. Este mtodo es uno de los ms detallados y exhaustivos publicados hasta la fecha. Asimismo, Archer afirma que el diseo "es una ciencia porque es una bsqueda sistemtica cuya meta es el conocimiento". 8

4. Hans Gugelot - Mtodo usado en la escuela Ulm. Propone una metodologa bsica para el diseo de productos industriales. Con base en los principios de esta metodologa se dieron los fundamentos de la Buena Forma (GuteForm). Las etapas de este mtodo son: 1. De informacin. Recoleccin de la informacin. 2. De investigacin. Necesidades del usuario, contexto, funcionalidad, requerimientos. 3. De diseo. Estudio tipolgico, apoyo en conocimientos cientficos, no en la inspiracin. 4. De decisin. Estudios de costo/beneficios, estudio tecnolgico

fundamentado. 5. De clculo. Ajuste del diseo a las normas y estndares de materiales y produccin. 6. Construccin del prototipo. Pruebas y evaluacin. La estructura de la obtencin de los requerimientos es la siguiente:

Objetivos. Enunciar la funcin de un subcomponente o elemento del diseo. Parmetro determinante. Identificar el factor relevante. FUNDAMENTOS DE PROGRAMACION

UNIDAD IV

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS

Subparmetro. Aspectos que quedan bajo el control del diseador. Cuantificacin. Especificacin de los rangos de accin.

5. Christopher Alexander. En su obra Ensayo sobre la sntesis de la forma, hace un recuento histrico sobre los mtodos que se han usado en el diseo. Ve la necesidad de crear un mtodo verdaderamente cientfico dado que los existentes no son suficientemente rigurosos. 9 El problema de los mtodos tradicionales es que recurren a trminos verbales que corresponden ms a una tradicin cultural que a la estructura real del problema. Para este autor, la clave se encuentra en el anlisis riguroso del problema y en adaptar a ste la estructura del programa del diseo y no al revs. Podemos dividir el mtodo de Alexander en 6 pasos:

Definicin del problema. Mediante una lista de exigencias, se estudia el comportamiento de los sistemas en el contexto.

Se da un juicio para determinar si las soluciones a una de las exigencias estn determinadas con las de otra.

Se analiza y descompone. Se establece una jerarqua de subsistemas. Por medio de diagramas se encuentra una solucin a las exigencias. Los diagramas se van desarrollando hasta lograr la sntesis formal de las exigencias.

Considera que el contexto est compuesto por: ubicacin fsica, uso y mtodos de fabricacin. En todo problema de diseo existen dos componentes: uno formado por exigencias fuera del control del diseador y otro por la forma que el diseador debe adaptar a la anterior.

6. Oscar Olea y Carlos Gonzlez Lobo - Modelo diana. Los factores bsicos en el proceso proyectual son la demanda, la respuesta que da el diseador y el objetivo satisfactor. UNIDAD IV La demanda se conforma por:

FUNDAMENTOS DE PROGRAMACION

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS

a. b. c.

Unibacin. Destino. Economa.

Sitio Finalidad

especfico de la de

donde los

surge de recursos

la la

necesidad. demanda. disponibles.

satisfaccin

Evaluacin

Para que el diseador sea capaz de dar una respuesta adecuada a la demanda, debe manejar cinco niveles: 10 1. Funcional. Soluciones en relaciones objeto-uso. 2. Ambiental. Problemtica en la relacin objeto-contexto fsico. 3. Estructural. Rigidez o durabilidad del objeto en funcin del uso. 4. Constructivo. Problemas surgidos en medios de produccin y su incidencia sobre las soluciones a los dems niveles. 5. Expresivo. Niveles de solucin estticos. Los pasos del modelo Diana son: 1. Configuracin de la demanda. 2. Organizacin de la informacin. 3. Definicin del vector analtico del problema. 4. Definicin del enfoque. 5. Definir las reas semnticas en relacin con la variable. 6. Organizacin de la investigacin. 7. Asignar probabilidades de eleccin. Dar un orden jerrquico. 8. Asignar su factor acumulativo. 9. Establecer las restricciones lgicas. 10. Calificar en forma binaria las reas de la demanda. 11. Fijar el lmite inferior de la probabilidad de eleccin. 12. Pasar los datos a la hoja de codificacin. 13. Iniciar el proceso con la computadora.

UNIDAD IV

FUNDAMENTOS DE PROGRAMACION

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS 7. Modelo General del Proceso de Diseo - Profesores de la Universidad Autnoma Metropolitana Azcapotzalco. Pretenden desarrollar la autoconciencia sobre el mtodo del proceso y asegurar as el proceso mismo y su correcto resultado. Sus fases son: 1. Caso. Especifica tanto el marco terico como las tcnicas a utilzar. 2. Problema. Reunin de datos relevantes que incluyen el criterio de diseo para su interpretacin y solucin. 3. Hiptesis. Alternativas para analizar y resolver los sistemas semitico, funcional, constructivo y de planeacin econmica-administrativa. 4. Proyecto. Interaccin total con los mtodos y tcnicas de las disciplinas que van a implementar en la realidad la hiptesis de diseo. 5. Realizacin. Supervisin y direccin de la realizacin material. Termina cuando es utilizado. Se observa que hay una estrecha relacin entre este modelo y el mtodo cientfico. 11

UNIDAD IV

FUNDAMENTOS DE PROGRAMACION

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS 4.6. COMUNICACIN ENTRE OBJETOS

Arquitectura de capas

Los objetos se relacionan mediante mtodos de acuerdo al siguiente esquema: 12

CONTROLADOR

MANEJADOR MODELO

MANEJADOR VISTA

RAMALES

ACCIONES

ACCIONISTA

BASE DATOS

VISTA IMPRESORA

VISTA MONITOR

Lista de objetos y mtodos

Controlador

+ Controlador(): Constructor de la clase + InterfaceNotificacionVista(arguments): Recibe las notificaciones de la vista + InterfaceNotificacionUsuario(arguments): Recibe las notificaciones desde el usuario - CrearObjetos: Llama a los constructores de las clases Manejador modelo y manejador vista, los cuales a su vez llaman a los constructores subordinados. UNIDAD IV FUNDAMENTOS DE PROGRAMACION

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS

ManejadorModelo

+ ManejarModelo(): Constructor de la clase + CrearRamal(arguments): Interface para el controlador + ModificarRamal(arguments): Interface para el controlador + BorrarRamal(arguments): Interface para el controlador + CrearAccion(arguments): Interface para el controlador + ModificarAccion(arguments): Interface para el controlador + BorrarAccion(arguments): Interface para el controlador + CrearAccionista(arguments): Interface para el controlador + ModificarAccionista(arguments): Interface para el controlador + BorrarAccionista(arguments): Interface para el controlador - CrearObjetos(): Interface para el controlador que da la orden de crear los objetos en base a los datos almacenados en la base de datos. 13

Ramales + Ramales(): Constructor de la clase + ModificarRamal(arguments): Permite modificar informacin interna el ramal.

Acciones + Acciones(): Constructor de la clase + ModificarAcciones(arguments): Permite modificar informacin interna de la accin + AsociarRamal(Ramales): Asocia un ramal a la accin + DesasociarRamal(Ramales): Desasocia un ramal a la accin UNIDAD IV FUNDAMENTOS DE PROGRAMACION

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS

Accionista + Accionista(): Constructor de la clase + ModificarAccionista(arguments): Permite modificar informacin interna del accionista + ComprarAccion(Acciones): Asocia una accin a un accionista + VenderAccion(Acciones): Quita la asociacin a la accin indicada si es que existe 14

Base de datos + BasedeDatos(): Constructor de la clase + Conectar (arguments): Levanta una conexin al motor de base de datos dentro del objeto + Desconectar(): Desconecta la conexin actual (si existe) + CrearRama(arguments): Guarda en base de datos informacin respecto a la rama que dentro del sistema est representada por un objeto + ModificarRama(arguments): Cambia informacin respecto a la rama + DestruirRama(arguments): Borra de la base de datos informacin respecto a la rama + CrearAcciones(arguments): Guarda en base de datos informacin respecto a la accin que dentro del sistema est representada por un objeto + ModificarAcciones(arguments): Cambia informacin respecto a la accin + DestruirAcciones(arguments): Borra de la base de datos informacin respecto a la accin + CrearAccionista(arguments): Guarda en base de datos informacin respecto al accionista que dentro del sistema est representada por un objeto + ModificarRama(arguments): Cambia informacin respecto al accionista + DestruirRama(arguments): Borra de la base de datos informacin respecto al accionista UNIDAD IV FUNDAMENTOS DE PROGRAMACION

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS + LeerRamas(): Devuelve todos las ramas guardadas en base de dato de manera que puedan ser creadas como objetos por el manejador de modelo. + LeerAcciones(): Devuelve todos las acciones guardadas en base de dato de manera que puedan ser creadas como objetos por el manejador de modelo. + LeerAccionistas(): Devuelve todos los accionistas guardados en base de dato de manera que puedan ser creados como objetos por el manejador de modelo. Manejador Vista + ManejadorVista(): Constructor de la clase + Inscribirse(object): Puente de comunicacin desde la vista al controlador, mediante el cual la vista notifica a un objeto determinado que est suscrito. En este caso el controlador ser quin estar suscrito. + ActualizarVista(data): Interface de actualizacin para los nuevos datos del modelo 15

Vista Impresora + VistaImpresora(): Constructor de la clase + ActualizarVista(data): Entrega una actualizacin de los datos para ser estos almacenados dentro de la vista impresora. + VistaPreliminar(): Muestra una vista preliminar en pantalla de los datos que actualmente estn guardados. + Imprimir(): Imprime los datos actuales de la vista

Vista Monitor + VistaMonitor(): Constructor de la clase + ActualizarVista(data): Entrega una actualizacin de los datos para ser estos almacenados dentro de la vista monitor Relaciones Podemos entonces en base al modelo ver cuales son los mtodos que se corresponden con cada relacin UNIDAD IV FUNDAMENTOS DE PROGRAMACION

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS Controlador -> Manejador Modelo + ManejarModelo() + CrearRamal(arguments) + ModificarRamal(arguments) + BorrarRamal(arguments) + CrearAccion(arguments) + ModificarAccion(arguments) + BorrarAccion(arguments) + CrearAccionista(arguments) + ModificarAccionista(arguments) + BorrarAccionista(arguments) 16

Controlador -> Manejador Vista + ManejadorVista() + Inscribirse(object) + ActualizarVista(data)

Manejador Vista -> Controlador + InterfaceNotificacionVista(arguments)

Manejador Modelo -> Ramales + Ramales() + ModificarRamal(arguments)

UNIDAD IV

FUNDAMENTOS DE PROGRAMACION

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS Manejador Modelo -> Accin + Acciones() + ModificarAcciones(arguments) + AsociarRamal(Ramales) + DesasociarRamal(Ramales) 17

Manejador Modelo -> Accionista + Accionista() + ModificarAccionista(arguments) + ComprarAccion(Acciones) + VenderAccion(Acciones)

Manejador Modelo -> Base de Datos + BasedeDatos() + Conectar (arguments) + Desconectar() + CrearRama(arguments) + ModificarRama(arguments) + DestruirRama(arguments) + CrearAcciones(arguments) + ModificarAcciones(arguments) + DestruirAcciones(arguments) + CrearAccionista(arguments) UNIDAD IV FUNDAMENTOS DE PROGRAMACION

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS + ModificarRama(arguments) + DestruirRama(arguments) + LeerRamas() + LeerAcciones() + LeerAccionistas() 18

Manejador Vista -> Vista Impresora + VistaImpresora() + ActualizarVista(data) + VistaPreliminar() + Imprimir()

Manejador Vista -> Vista Monitor + VistaMonitor() + ActualizarVista(data)

UNIDAD IV

FUNDAMENTOS DE PROGRAMACION

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS 4.7. DISEO DE LA CLASE DE PRUEBA Recordando el objetivo de la prueba, debemos disear pruebas que tengan la mayor probabilidad de encontrar el mayor nmero de errores con la mnima cantidad de esfuerzo y tiempo. Las pruebas de caja negra se refieren a las pruebas que se llevan a cabo sobre la interfaz del software. O sea, pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce una salida correcta, as como que la integridad de la informacin externa se mantiene. Una prueba de caja negra examina algunos aspectos del modelo fundamental del sistema sin tener mucho en cuenta la estructura lgica interna del software. Las pruebas de caja blanca se basan en el minucioso examen de los detalles procedimentales. Se comprueban los caminos lgicos del software proponiendo casos de prueba que ejerciten conjuntos especficos de condiciones y/o bucles. A primera vista parecera que una prueba de caja blanca muy profunda nos llevara a tener "programas 100 por ciento correctos", pero desgraciadamente, la prueba exhaustiva presenta ciertos problemas logsticos. Incluso para pequeos programas, el nmero de caminos lgicos posibles resulta ser enorme, con lo que no se pueden probar estos caminos en un tiempo razonable. Por qu no gastamos, entonces, todas nuestras energas en las pruebas de caja negra? La respuesta se encuentra en la naturaleza misma de los defectos del software. A menudo creemos que un camino lgico tiene pocas posibilidades de ejecutarse cuando de hecho, se puede ejecutar muchas veces. Los errores de escritura son en su mayora descubiertos por los mecanismos de comprobacin de sintaxis, pero otros permanecern indetectados hasta que comience la prueba, siendo igual de probable que exista un error tipogrfico en un oscuro camino lgico que en un camino principal. La prueba de la caja negra, sin tener en cuenta cmo sea de completa, puede pasar por alto los tipos de errores que acabamos de sealar. 1- Prueba del camino bsico. El mtodo del camino bsico, propuesto por Tom McCabe, permite al diseador de casos de prueba obtener una medida de la complejidad lgica de un diseo procedimental y usar esa medida como gua para la definicin de un conjunto bsico de caminos de ejecucin. Los casos de prueba derivados del conjunto bsico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia de programa. Cualquier representacin del diseo procedimental se puede traducir a un grafo de flujo. La complejidad ciclomtica de este grafo (como se defini en la clase UNIDAD IV FUNDAMENTOS DE PROGRAMACION

19

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS anterior) define el nmero de caminos independientes del conjunto bsico de un programa y nos da un lmite superior para el nmero de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez. Un camino independiente es cualquier camino del programa que introduce por lo menos un nuevo conjunto de sentencias de procesamiento o una nueva condicin. En trminos del grafo de flujo, un camino independiente se debe mover por lo menos por una arista que no haya sido recorrida anteriormente a la definicin de un camino. 20 La complejidad se puede calcular de tres formas: 1.- El numero de regiones del grafo de flujo 2.- Aristas - Nodos + 2 3.-Nodos predicado + 1 (un nodo predicado es el que representa una condicional if o case, es decir, que de l salen varios caminos) El valor de V(G) nos da el nmero de caminos linealmente independientes de la estructura de control del programa. Entonces se preparan los casos de prueba que forzarn la ejecucin de cada camino del conjunto bsico.

Ejemplo: Diseemos un algoritmo que sea capaz de procesar una situacin de overflow cuando un conjunto de N pilas comparten un rea de memoria comn de M localizaciones enumeradas de L0 a Lm.

L0 L1 L2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LM

Entradas al programa: N - Cantidad de pilas b(j), t(j) J = 1, ..., N i - Pila donde se va a efectuar una insercin Si t(i) > b(i+1) ocurre overflow. Tres casos son posibles: 1.- Existe espacio a la izquierda? Se decrementa j desde i hasta 1 hasta encontrar que t(j) <= b(j+1). Si se encuentra, se corren a la izquierda una posicin todas las pilas desde la j+1 hasta la pila i. Posteriormente se procede a ejecutar la insercin abandonada. 2.- Si no existe espacio a la izquierda existe a la derecha? Se incremente j desde i hasta M hasta encontrar que t(j) <= b(j+1). Si es as, se corren todas las pilas 1 posicin a la derecha desde la i+1 hasta la j. Efectuar la insercin abandonada. 3.- Si no existe espacio a la derecha ni a la izquierda, el overflow no tiene solucin. UNIDAD IV FUNDAMENTOS DE PROGRAMACION

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS Caminos: 129 134579 1346879 13469 Los casos de prueba deben explotar los caminos anteriores. 2- Prueba de condiciones. La prueba de condiciones es un mtodo de diseo de casos de prueba que ejercita las condiciones lgicas contenidas en el mdulo de un programa. Se basa en el criterio de que si un conjunto de pruebas de un programa P es efectivo para detectar errores en las condiciones que se encuentran en P, es probable que el conjunto de pruebas sea tambin efectivo para detectar otros errores en el programa P. Para una expresin relacional de la forma: E1 <operador relacional> E2 se requieren tres pruebas: el valor de E1 mayor, menor o igual que el de E2. La prueba que haga el valor de E1 mayor o menor que el de E2 debe hacer que la diferencia entre estos dos valores sea lo ms pequea posible. Si la expresin es de la forma B1 & B2 donde B1 y B2 son variables lgicas, esta se cubre para B1 verdadero y B2 falso, B1 falso y B2 verdadero y ambos B1 y B2 verdadero. Ver en el libro de Pressman pgs. 642 a 643 ejemplos de expresiones complejas que incluyen expresiones lgicas y de comparacin. 3- Prueba de bucles Los bucles son la piedra angular de la mayora de los algoritmos implementados en software. La prueba de bucles es una tcnica de prueba de caja blanca que centra su punto de atencin en la validez de las construcciones de bucles. A) Bucles simples: Se les debe aplicar el siguiente conjunto de pruebas, donde n es el nmero mximo de pasos permitidos para el bucle: 1. Pasar por alto totalmente el bucle 2. Pasar una sola vez por el bucle 3. Pasar dos veces por el bucle 4. Hacer m pasos por el bucle con m < n 5. Hacer n-1, n y n+1 pasos por el bucle 21

UNIDAD IV

FUNDAMENTOS DE PROGRAMACION

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS B) Bucles anidados 1. Comenzar por el bucle ms interior. Establecer los dems bucles en sus valores mnimos. 2. Llevar a cabo las pruebas de bucles simples para el bucle ms interior, mientras se mantienen los parmetros de iteracin (p. Ej. Contadores de bucles) de los bucles externos en sus valores mnimos. Aadir otras pruebas para valores fuera de rango o excludos. 3. Progresar hacia fuera, llevando a cabos pruebas para el siguiente bucle, pero manteniendo todos los bucles externos en sus valores mnimos y los dems bucles anidados en sus valores "tpicos". 4. Continuar hasta que se hayan probado todos los bucles. C) Bucles concatenados: Se pueden probar mediante el enfoque anteriormente definido para los bucles simples, mientras cada uno de los bucles sea independiente del resto (si el contador del bucle 1 se usa como valor inicial del bucle 2 entonces los bucles no son independientes) D) Bucles no estructurados: Esta clase de bucles se deben redisear para que se ajusten a las construcciones de la programacin estructurada. 4.- Pruebas de caja negra 2.- Particin Equivalente La particin equivalente es un mtodo de prueba de caja negra que divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba.. Un caso de prueba ideal descubre de forma inmediata una clase de errores, que de otro modo requeriran la ejecucin de muchos casos antes de detectar el error genrico. La particin equivalente se dirige a la definicin de casos de prueba que descubran clases de errores, reduciendo as el nmero de casos de pruebaque hay que desarrollar. El diseo de casos de preba para la particin equivalente se basa en una evaluacin de las clases de equivalencia para una condicin de entrada. Una clase de equivalencia representa un conjunto de estados vlidos o invlidos para condiciones de de entrada. 1. Si una condicin de entrada especifica un rango, se define una clase de equivalencia vlida y dos invlidas 2. Si una condicin de entrada requiere un valor especfico, se define una clase de equivalencia vlida y dos invlidas. 3. Si una condicin de entrada especifica un miembro de un conjunto, se define una clase de equivalencia vlida y una invlida. 4. Si una condicin de entrada es lgica, se define una clase vlida y una invlida. UNIDAD IV FUNDAMENTOS DE PROGRAMACION

22

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS Como ejemplo, consideremos los datos contenidos en una aplicacin de automatizacin bancaria. Este software acepta datos en la siguiente forma: Cdigo de rea: En blanco un nmero de 3 dgitos Prefijo: Nmero de 3 dgitos que no comience por 0 1 Sufijo: Nmero de 4 dgitos Contrasea: Vvalor alfanumrico de 6 dgitos Ordenes: "Comprobar", "Depositar","Pagar factura", etc. Las condiciones de entrada relacionadas con cada elemento de la aplicacin bancaria se pueden especificar como: Cdigo de rea: Condicin de entrada lgica - el cdigo de rea puede estar o no presente Condicin de entrada rango - valores definidos entre 200 y 999 Prefijo: Condicin de entrada rango - valor especificado > 200 Sufijo: Condicin de entrada valor- longitud de 4 dgitos Contrasea: Condicin de entrada lgica - la palabra clave puede estar o no presente Condicin de entrada valor - cadena de seis caracteres Orden: Condicin de entrada conjunto, contenida en las rdenes listadas anteriormente. Los casos de prueba se seleccionan de manera que se ejercite el mayor nmero de atributos de cada clase de equivalencia a la vez. 5 - Anlisis de valores lmite (AVL) Esta tcnica complementa a la de particin equivalente. En lugar de seleccionar cualquier elemento de una clase de equivalencia, el AVL lleva a la eleccin de casos de prueba "en los bordes" de la clase. En lugar de centrarse solamente en las condiciones de entrada, el AVL deriva casos de prueba tambin para el campo de salida. 1. Si una condicin de entrada especifica un rango delimitado por los valores a y b, se deben disear casos de prueba para los valores a y b y para valores justo por debajo y justo por encima de a y b, respectivamente. 2. Si una condicin de entrada especifica un nmero de valores, se deben desarrollar casos de prueba que ejerciten los valores mximo y mnimo. Tambin se deben probar los valores justo por debajo del mximo y del mnimo. 3. Aplicar las directrices 1 y 2 a las condiciones de salida. Por ej. supongamos que se requiere una tabla como salida deun programa, entonces se deben disear casos de prueba que creen un informe de salida que produzca el mximo ( y el mnimo) nmero permitido de entradas en la tabla. 4. Si las estructuras de datos internas tienen lmites preestablecidos ( p. Ej. Un arreglo de 100 entradas) hay que asegurarse de disear un caso de prueba que ejercite la estructura de datos en sus lmites. UNIDAD IV FUNDAMENTOS DE PROGRAMACION

23

MODELADO DE APLICACIONES UTILIZANDO EL ENFOQUE ORIENTATADO A OBJETOS 6.- Pruebas de integracin. La prueba de integracin se realiza posteriormente a las pruebas de unidad y su foco de atencin es el diseo y la construccin de la arquitectura del software. Despus de la integracin viene la validacin y por ltimo la prueba del sistema, sta ltima consiste en probar el software junto con los otros elementos de la empresa o entidad, como la gente, departamentos, la base de datos, etc. Las pruebas de integracin pueden ser descendentes o ascendentes o en sandwich, pero estas tienen sentido con ese nombre en los sistemas hechos en lenguajes estructurados, en los que el diagrama de la estructura de mdulos del sistema permite definir un tipo dado de integracin. En los orientados a objeto, otra vez cobra importancia el concepto de caso de uso, pues ste gua a la prueba en cuanto a los requisitos que deben satisfacer un determinado nmero de clases de programacin que tienen que interactuar entre s gobernadas por alguna clase de control del caso de uso. 7.- Pruebas de validacin La validacin se logra cuando el software funciona de acuerdo a las expectativas del cliente. La validacin se consigue mediante una serie de pruebas de la caja negra que demuestran la conformidad con los requisitos. Si aparecen deficiencias, hay que negociar con el cliente un mtodo para resolverlas. La prueba alfa es conducida por un cliente en el lugar de desarrollo. Se usa el software de manera natural, con el encargado de desarrollo "mirando por encima del hombro" del usuario" y registrando errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entrono controlado. La prueba beta se lleva a cabo en uno o ms lugares de clientes por los usuarios finales del software. A diferencia de la prueba alfa, el encargado de desarrollo, normalmente, no est presente. La prueba beta es una aplicacin "en vivo" del software en un entrono que no puede ser controlado por el equipo de desarrollo. El cliente registra todos los problemas (reales o imaginarios) que encuentra y los informa a intervalos regulares. Como resultado, el equipo de desarrollo lleva a cabo modificaciones y as prepara una versin del producto para toda la base de clientes.

24

UNIDAD IV

FUNDAMENTOS DE PROGRAMACION