IFCD0210-MF0492_3-Uf1844 Desarrollo de aplicaciones web en el entorno servidor by Unión Editorial para la Formación

Ifcd0210

Informática y comunicaciones

dEsarrOllO dE APLICACIONES cOn tEcnOlOGÍas WEB

Módulo Formativo 0492_3

programación web en el entorno servidor

Unidad Formativa 1844 desarrollo de aplicaciones web en el entorno servidor

Certiﬁcado de Profesionalidad

Impreso en España. Printed in Spain 1ª edición Autor: José Manuel Carballeira Rodrigo «Cualquier forma de reproducción, distribución, comunicación pública o transformación de esta obra solo puede ser realizada con la autorización de sus titulares, salvo excepción prevista por la ley. Diríjase a CEDRO (Centro Español de Derechos Reprográficos) si necesita fotocopiar o escanear algún fragmento de esta obra (www.conlicencia.com; 91 702 19 70 / 93 272 04 47)». Reservados todos los derechos. Está prohibido, bajo las sanciones penales y el resarcimiento civil previstos en las leyes, reproducir, registrar o transmitir esta publicación, íntegra o parcialmente por cualquier sistema de recuperación y por cualquier medio sea mecánico, electrónico, magnético, electroóptico, por fotocopia o por cualquier otro medio presente o futuro, sin la autorización previa de Unión Editorial para la Formación (UEF).

Ifcd0210

dEsarrOllO dE aplIcacIOnEs cOn tEcnOlOGÍas wEB

Modulo Formativo 0492_3 programación web en el entorno servidor

Unidad Formativa 1844

desarrollo de aplicaciones web en el entorno servidor

Elaboración de documentos web mediante lenguajes de marca REFERENCIA AL CERTIFICADO DE PROFESIONALIDAD............................................................................................ 8 INTRODUCCIÓN...................................................................................................................................................................... 9 OBJETIVOS................................................................................................................................................................................. 10 MAPA CONCEPTUAL............................................................................................................................................................. 11 unidad didáctica 1. El proceso del desarrollo de software.................................................................14 1.1. Modelos del ciclo de vida del software....................................................................................................15 1.1.1. En cascada (waterfall)................................................................................................................................................... 18 1.1.2. Interativo......................................................................................................................................................................... 19

1.1.3. Incremental...........................................................................................................................................................20 1.1.4. En V..........................................................................................................................................................................22 1.1.5. Basado en componentes (CBSE)...............................................................................................................................24 1.1.6. Desarrollo rápido (RAD)............................................................................................................................................26 1.1.7.Ventajas e inconvenientes. Pautas para la selección de la metodología más adecuada..................................27 1.2. Análisis y especificación de requisitos..........................................................................................................27 1.2.1. Tipos de requisitos........................................................................................................................................................ 31 1.2.2. Modelos para el análisis de requisitos......................................................................................................................32 1.2.3. Documentación de requisitos....................................................................................................................................34 1.2.4.Validación de requisitos......................................................................................................................................41 1.2.5. Gestión de requisitos.........................................................................................................................................41 1.3. Diseño....................................................................................................................................................................................42 1.3.1. Modelos para el diseño de sistemas.........................................................................................................................44 1.3.2. Diagramas de diseño. El estándar UML....................................................................................................................46 1.3.3. Documentación............................................................................................................................................................. 48 1.4. Implementación. Conceptos generales de desarrollo de software.....................................48 1.4.1. Principios básicos del desarrollo de software........................................................................................................48 1.4.2. Técnicas de desarrollo de software..........................................................................................................................50 1.5.Validación y verificación de sistemas.............................................................................................................54 1.5.1. Planificación..........................................................................................................................................................55 1.5.2. Métodos formales de verificación.............................................................................................................................56 1.5.3. Métodos automatizados de análisis..........................................................................................................................59 1.6. Pruebas de software..................................................................................................................................................60 1.6.1. Tipos................................................................................................................................................................................. 62 1.6.2. Pruebas funcionales (BBT)..........................................................................................................................................64 1.6.3. Pruebas estructurales (WBT)....................................................................................................................................65 1.6.4. Comparativa. Pautas de utilización..................................................................................................................66 1.6.5. Diseño de pruebas........................................................................................................................................................ 68 1.6.6. Ámbitos de aplicación..................................................................................................................................................69 1.6.7. Pruebas de Sistemas..................................................................................................................................................... 70

1.6.8. Pruebas de componentes............................................................................................................................................72 1.6.9. Automatización de pruebas. Herramientas.............................................................................................................73 1.6.10. Estándares sobre pruebas de software..................................................................................................................74 1.7. Calidad del software...............................................................................................................................................75 1.7.1. Principios de calidad del software.............................................................................................................................76 1.7.2. Métricas y calidad del software.................................................................................................................................80 1.7.3. Concepto de métrica y su importancia en la medición de la calidad...............................................................81 1.7.4. Principales métricas en las fases del ciclo de vida software................................................................................82 1.7.5. Estándares para la descripción de los factores de Calidad..................................................................................83 1.7.6. ISO9126.......................................................................................................................................................................... 84 1.7.7. Otros estándares. Comparativa.................................................................................................................................85 1.8. Herramientas de uso común para el desarrollo de software.................................................87 1.8.1. Editores orientados a lenguajes de programación................................................................................................88 1.8.2. Compiladores y enlazadores......................................................................................................................................89 1.8.3. Generadores de programas........................................................................................................................................89 1.8.4. Depuradores.................................................................................................................................................................. 90 1.8.5. De prueba y validación de software.........................................................................................................................90 1.8.6. Optimizadores de código............................................................................................................................................91 1.8.7. Empaquetadores............................................................................................................................................................ 91 1.8.8. Generadores de documentación de software.......................................................................................................91 1.8.9. Gestores y repositorios de paquetes.Versionado y control de dependencias...............................................92 1.8.10. De distribución de software....................................................................................................................................93 1.8.11. Gestores de actualización de software..................................................................................................................93 1.8.12. De control de versiones...........................................................................................................................................93 1.8.13. Entornos integrados de desarrollo (IDE) de uso común..................................................................................94 1.9. Gestión de proyectos de desarrollo de software............................................................................96 1.9.1. Planificación de proyectos..........................................................................................................................................97 1.9.2. Control de proyectos.................................................................................................................................................. 99 1.9.3. Ejecución de proyectos..............................................................................................................................................100 1.9.4. Herramientas de uso común para la gestión de proyectos..............................................................................101 unidad didáctica 2. La orientación a objetos...................................................................................................104 2.1. Principios de la orientación a objetos. Comparación con la programación estructurada..................................................................................................................................104 2.1.1. Ocultación de información (information hiding).................................................................................................105 2.1.2. El tipo abstracto de datos (ADT). Encapsulado de datos..................................................................................106 2.1.3. Paso de mensajes........................................................................................................................................................106 2.2. Clases de objetos.........................................................................................................................................................107 2.2.1. Atributos, variables de estado y variables de clase.............................................................................................109 2.2.2. Métodos. Requisitos e invariantes...........................................................................................................................113 2.2.3. Gestión de excepciones............................................................................................................................................116 2.2.4. Agregación de clases...................................................................................................................................................124

2.3. Objetos................................................................................................................................................................................127 2.3.1. Creación y destrucción de objetos........................................................................................................................127 2.3.2. Llamada a métodos de un objeto............................................................................................................................128 2.3.3.Visibilidad y uso de las variables de estado...........................................................................................................130 2.3.4. Referencias a objetos.................................................................................................................................................134 2.3.5. Persistencia de objetos..............................................................................................................................................134 2.3.6. Optimización de memoria y recolección de basura (garbage collection)......................................................136 2.4. Herencia.............................................................................................................................................................................138 2.4.1. Concepto de herencia. Superclases y subclases...................................................................................................138

2.4.2. Herencia múltiple............................................................................................................................................. 141 2.4.3. Clases abstractas.........................................................................................................................................................142 2.4.4. Tipos de herencia........................................................................................................................................................143 2.4.5. Polimorfismo y enlace dinámico (dynamic binding)............................................................................................144 2.4.6. Directrices para el uso correcto de la herencia..................................................................................................147 2.5. Modularidad..................................................................................................................................................................148 2.5.1. Librerías de clases. Ámbito de utilización de nombres............................................................................ 149 2.5.2.Ventajas de la utilización de módulos o paquetes................................................................................................153 2.6. Genericidad y sobrecarga...................................................................................................................................153 2.6.1. Concepto de genericidad..........................................................................................................................................153 2.6.2. Concepto de Sobrecarga. Tipos de sobrecarga....................................................................................................154 2.6.3. Comparación entre genericidad y sobrecarga.....................................................................................................155 2.7. Desarrollo orientado a objetos....................................................................................................................155 2.7.1. Lenguajes de desarrollo orientado a objetos de uso común............................................................................155 2.7.2. Herramientas de desarrollo......................................................................................................................................156 2.8. Lenguajes de modelización en el desarrollo orientado a objetos....................................157 2.8.1. Uso del lenguaje unificado de modelado (UML) en el desarrollo orientado a objetos..............................157 2.8.2. Diagramas para la modelización de sistemas orientados a objetos................................................................158 unidad didáctica 3. Arquitecturas web.................................................................................................................162 3.1. Concepto de arquitectura web.....................................................................................................................162 3.2. El modelo de capas....................................................................................................................................................164 3.3. Plataformas para el desarrollo en las capas servidor.................................................................167 3.4. Herramientas de desarrollo orientadas a servidor de aplicaciones web.......................171 3.4.1. Tipos de herramientas...............................................................................................................................................171 3.4.2. Extensibilidad. Instalación de módulos...................................................................................................................172

3.4.3. Técnicas de configuración de los entornos de desarrollo, preproducción y producción.................................................................................................................................... 173 3.4.4. Funcionalidades de depuración................................................................................................................................173 unidad didáctica 4. Lenguajes de programación de aplicaciones web en el lado servidor................................................................................................................................................................176 4.1. Características de los lenguajes de programación web en servidor...............................176 4.2. Tipos y características de los lenguajes de uso común...............................................................177

4.2.1. Interpretados orientados a servidor......................................................................................................................177 4.2.2. Lenguajes de cliente interpretados en servidor..................................................................................................177 4.2.3. Lenguajes compilados. ..............................................................................................................................................177 4.3. CRITERIOS EN LA ELECCIÓN DE UN LENGUAJE DE PROGRAMACIÓN wEB EN SERVIDOR.VENTAJAS E INCONVENIENTES.............................................................................................................177 4.4. CARACTERíSTICAS GENERALES. ................................................................................................................................186 4.4.1. Tipos de datos.............................................................................................................................................................186 4.4.2. Clases............................................................................................................................................................................189 4.4.3. Operadores básicos. Manipulación de cadenas de caracteres.........................................................................189 4.4.4. Estructuras de control. Bucles y condicionales...................................................................................................193 4.4.5. Módulos o paquetes..................................................................................................................................................199 4.4.6. Herencia.......................................................................................................................................................................199 4.4.7. Gestión de bibliotecas (libraries). ..........................................................................................................................201 4.5. GESTIÓN DE LA CONFIGURACIÓN..........................................................................................................................203 4.5.1. Configuración de descriptores. ..............................................................................................................................203 4.5.2. Configuración de ficheros........................................................................................................................................204 4.6. GESTIÓN DE LA SEGURIDAD. ......................................................................................................................................206 4.6.1. Conceptos de identificación, autenticación y autorización. .............................................................................206 4.6.2. Técnicas para la gestión de sesiones......................................................................................................................207 4.7. GESTIÓN DE ERRORES....................................................................................................................................................210 4.7.1. Técnicas de recuperación de errores....................................................................................................................210 4.7.2. Programación de excepciones. ...............................................................................................................................211 4.8. TRANSACCIONES y PERSISTENCIA............................................................................................................................213 4.8.1. Acceso a bases de datos. Conectores. ..................................................................................................................213 4.8.2. Estándares para el acceso a bases de datos.........................................................................................................213 4.8.3. Gestión de la configuración de acceso a bases de datos..................................................................................213 4.8.4. Acceso a directorios y otras fuentes de datos....................................................................................................216 4.8.5. Programación de transacciones..............................................................................................................................218 4.9. COMPONENTES EN SERVIDOR.VENTAJAS E INCONVENIENTES EN EL USO DE CONTENEDORES DE COMPONENTES. ..................................................................................................................220 4.10. MODELOS DE DESARROLLO. EL MODELO VISTA CONTROLADOR. ..........................................................221 4.10.1. Modelo: programación de acceso a datos..........................................................................................................222 4.10.2.Vista: Desarrollo de aplicaciones en cliente. Eventos e interfaz de usuario................................................223 4.10.3. Programación del controlador..............................................................................................................................224 4.11. DOCUMENTACIÓN DEL SOFTwARE. INCLUSIÓN EN CÓDIGO FUENTE. GENERADORES DE DOCUMENTACIÓN.........................................................................................................................224 RESUMEN .......................................................................................................................................................................................... 226 BIBLIOGRAFíA.................................................................................................................................................................................. 227 GLOSARIO ........................................................................................................................................................................................ 228

Referencia al certificado de Profesionalidad CERTIFICADO DE PROFESIONALIDAD:

(IFCD0210) DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB (RD 1531/2011, de 31 de octubre)

MODULO FORMATIVO: MF0492_3: Programación web en el entorno servidor. UNIDAD FORMATIVA: UF1844: Desarrollo de aplicaciones web en el entorno servidor

Introducción Introducción “Si no tienes presencia en Internet, tu empresa no existe”. Esta máxima cobra cada día más vigencia, si bien no es siempre cierta, ya que siguen existiendo empresas que apenas figuran en Internet y mantienen su modelo de negocio como siempre lo ha hecho; pero lo que está claro es que esas empresas están perdiendo una gran oportunidad de negocio: bien por la generación directa de ventas o bien por el marketing y publicidad que conlleva para la empresa. Hay empresas que utilizan las tecnologías web para ampliar su volumen de negocio, ya que posibilita ampliar el negocio a un mercado global, y en el otro extremo encontraos empresas que únicamente tienen una página de referencia para indicar una descripción de la empresa, servicios y forma de contacto, manteniendo así el modelo de negocio clásico. Paulatinamente todas las empresas irán ampliando y cambiando su modelo de negocio para integrarlo con las nuevas tecnologías. Esto, cuanto menos, da una imagen moderna y dinámica de la empresa. Las aplicaciones web cumplen un papel muy importante para el crecimiento y el funcionamiento global de los negocios en este escenario de desarrollo de última tecnología. Las aplicaciones web correctamente diseñadas se generan con la ayuda de lenguajes de programación, lo que resulta imprescindible para concebir un desarrollo web personalizado. Para hacer frente a la competencia feroz es muy importante tener un sitio web, que esté totalmente adaptado en cuanto al contenido y diseño, así como por su área específica relativa al funcionamiento de la empresa. Sin el diseño y el desarrollo de aplicaciones web personalizadas, una presentación adecuada y llamativa (concepto que variará según el contexto) y un pulido inteligente.Y es que en el escenario actual de negocios, su sitio web no sólo representa a su empresa, si no que en muchas ocasiones actúa como su lugar de oficina virtual, por lo que es muy importante para diseñar y desarrollar las aplicaciones web de forma adecuada según el contexto. El proceso de desarrollo de aplicaciones web consiste el desarrollo de aplicaciones de a través de técnicas especializadas. Estos programas son usados para crear páginas web enfocadas a la creación, diseño y desarrollo. Así hay una serie de lenguajes de programación especializados para el desarrollo web, como pueden ser PHP, ASP, JavaScript, Java y JSP, etc. La finalidad de estos lenguajes es el desarrollo de sitios web o aplicaciones web móviles (aunque para esto último hay otros lenguajes más específicos, siendo los anteriormente citados un complemento a los principales).

Entre las primordiales Características y Ventajas sobre el desarrollo de aplicaciones web encontramos: –– La web se ha convertido en el mercado virtual para los negocios donde las empresas se representan a sí mismas, interactúan con los clientes y amplían su negocio. En este escenario una página web debe estar bien desarrollada en el propio contexto de la empresa para permitirle mantenerse erguida entre los competidores del mercado. –– La aplicación web que se vaya a crear podrá ser tomada como el punto de partida para el marketing empresarial, debido a que la empresa podrá centrar en ella todo su modelo de publicidad y marketing. –– El desarrollo de aplicaciones web personalizadas hace que el sitio web sea más interactivo y elegante o que su diseño se enfoque en la línea que se desee. –– Las aplicaciones web están continuamente abiertas a las nuevas ideas, es un mercado en continuo estudio y ampliación ya que las innovaciones permiten diferenciar a una empresa de otra, lo que podría repercutir en sus volúmenes de negocio. –– Este proceso ayuda a las firmas comerciales para establecerse en el mercado global, permitiendo así ampliar sus negocios al tratar con clientes extranjeros, sin ningún tipo de molestias ni continuos desplazamientos. Así la importancia de estas tecnologías se centra especialmente en el punto de vista tecnológico (para la generación de aplicaciones web adecuadas, seguras y rentables tanto para la empresa que la desarrolla como para el cliente), así como el punto de vista estético (que no es motivo de estudio de este módulo). Para facilitar la comprensión y acercar a la realidad al alumno el porqué de los contenidos se usarán ejemplos de diversos ámbitos de la informática, usándose en numerosas ocasiones el campo del marketing empresarial como ejemplo, especialmente en lo relacionado al mundo de la planificación de proyectos, especificaciones y pruebas.

Objetivos Objetivos Objetivo General • Crear componentes software con tecnologías de desarrollo orientadas a objetos. Objetivos Específicos • Gestionar componentes software en el entorno del servidor mediante herramientas de desarrollo y lenguajes de programación contando con documentación de diseño detallado. • Crear objetos, clases y métodos adecuados a la funcionalidad del componente software a desarrollar utilizando lenguajes de programación orientados a objetos. • Formular estructuras de datos y flujo de control mediante lenguajes de programación orientados a objetos según la funcionalidad del componente software a desarrollar. • Documentar el componente software desarrollado. • Construir componentes de software mediante herramientas de desarrollo y lenguajes de programación orientados a objetos a partir de documentación de diseño detallado.

Mapa conceptual Mapa conceptual PROYECTO SOFTWARE

ANÁLISIS

DISEÑO

DESARROLLO

PRUEBAS

¿Qué método usar?

¿Qué tipo de

-Métodos Formales

Diagramas UML

aplicación es?

- Automáticos

- Requisitos de Diseño - Arquitectura

Elección de Lenguaje de Programación

- Inter-Relaciones

-Diseño de Pruebas -Tipos de Pruebas

Definición de: Documentación

Documentación

Estructuras de datos; Clases; Herencia ; Bases de datos

Implementación Depuración

- PLANIFICACIÓN - CALIDAD

Documentación

MANTENIMIENTO

01 El proceso del desarrollo de software 1.1. Modelos del ciclo de vida del software

1.7. Calidad del software

1.1.1. En cascada (waterfall) 1.1.2. Iterativo 1.1.3. Incremental 1.1.4. En V 1.1.5. Basado en componentes (CBSE) 1.1.6. Desarrollo rápido (RAD) 1.1.7. Ventajas e inconvenientes. Pautas para la selección de la metodología más adecuada

1.7.1. Principios de calidad del software 1.7.2. Métricas y calidad del software 1.7.3. Concepto de métrica y su importancia en la medición de la calidad 1.7.4. Principales métricas en las fases del ciclo de vida software 1.7.5. Estándares para la descripción de los factores de Calidad 1.7.6. ISO9126 1.7.7. Otros estándares. Comparativa

1.2. Análisis y especificación de requisitos

1.2.1. Tipos de requisitos 1.2.2. Modelos para el análisis de requisitos 1.2.3. Documentación de requisitos 1.2.4. Validación de requisitos 1.2.5. Gestión de requisitos 1.3. Diseño

1.3.1. Modelos para el diseño de sistemas 1.3.2. Diagramas de diseño. El estándar UML 1.3.3. Documentación 1.4. Implementación. Conceptos generales de desarrollo de software

1.4.1. Principios básicos del desarrollo de software 1.4.2. Técnicas de desarrollo de software 1.5. Validación y verificación de sistemas

1.5.1. Planificación 1.5.2. Métodos formales de verificación 1.5.3. Métodos automatizados de análisis

1.6. Pruebas de software

1.6.1. Tipos 1.6.2. Pruebas funcionales (BBT) 1.6.3. Pruebas estructurales (WBT) 1.6.4. Comparativa. Pautas de utilización 1.6.5. Diseño de pruebas 1.6.6. Ámbitos de aplicación 1.6.7. Pruebas de Sistemas 1.6.8. Pruebas de componentes 1.6.9. Automatización de pruebas. Herramientas 1.6.10. Estándares sobre pruebas de software

1.8. Herramientas de uso común para el desarrollo de software

1.8.1. Editores orientados a lenguajes de programación 1.8.2. Compiladores y enlazadores 1.8.3. Generadores de programas 1.8.4. Depuradores 1.8.5. De prueba y validación de software 1.8.6. Optimizadores de código 1.8.7. Empaquetadores 1.8.8. Generadores de documentación de software 1.8.9. Gestores y repositorios de paquetes. Versionado y control de dependencias 1.8.10. De distribución de software 1.8.11. Gestores de actualización de software 1.8.12. De control de versiones 1.8.13. Entornos integrados de desarrollo (IDE) de uso común 1.9. Gestión de proyectos de desarrollo de software

1.9.1. Planificación de proyectos 1.9.2. Control de proyectos 1.9.3. Ejecución de proyectos 1.9.4. Herramientas de uso común para la gestión de proyectos

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

1. El proceso del desarrollo de software Un sistema es un conjunto organizado de elementos relacionados entre sí debido a su meta común, que actúan en un cierto entorno y que tienen una capacidad de auto control. El proceso de desarrollo del software es un conjunto de actividades que concluyen en la creación de uno o más productos para un cliente o usuario final. Debe tener un comienzo y un final bien definidos y que se desarrolla típicamente dentro de un plan de desarrollo. En algunas ocasiones, y para pequeños proyectos, estas actividades serán únicamente un desarrollo software desde cero en un cierto lenguaje de programación, pero este modelo está cada vez más obsoleto, ya que el software se crea reutilizando código existente, modificando y ampliando un código previamente creado, consiguiendo así una optimización en los recursos existentes y un descenso en el coste del proyecto. Los procesos de desarrollo software son procesos complejos que dependen de las decisiones que toman ciertas personas, de ahí la conveniencia de la definición de roles en la toma de decisiones. Actualmente existen una serie de herramientas para la automatización de procesos de ingeniería de software asistido por ordenador (CASE) que ayudarán en ciertas partes del proyecto, si bien la automatización de las decisiones es una meta extremadamente difícil, debido a la eliminación del componente humano, así como la ingente diversidad de los procesos software. Esta tarea de automatización es una meta muy perseguida por muchas empresas, pero que será muy difícilmente alcanzada a medio plazo. Pese a la diversidad de procesos software, hay una serie de actividades comunes, que son: • Especificación del software: su misión es definir la funcionalidad y la misión del software a crear; • Diseño del software: a partir de una especificación bien definida, se debe definir la estructura del mismo; • Implementación del software: tras el diseño y con éste mismo y las especificaciones, los desarrolladores han de implementarlos; • Verificación y validación del software: su misión es la prueba del software para comprobar que el sistema funciona correctamente (sin fallos) y que hace lo que se dice en las especificaciones del sistema; • Mantenimiento del software: en esta fase se recoge la corrección de errores posteriores, así como la evolución del programa (nuevos requisitos añadidos según las nuevas necesidades del cliente).

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

En este capítulo estudiaremos las diferentes tareas y los roles necesarios para una adecuada elaboración de un proyecto software 1.1. Modelos del ciclo de vida del software. El ciclo de vida de un proyecto software comprende las etapas por las que pasa un proyecto, desde la concepción de la idea que lanza la necesidad de diseñar el sistema, pasando por el análisis, implementación y mantenimiento del software, y termina cuando el sistema muere al ser sustituido por otro sistema. El ciclo de vida del software es un intervalo de tiempo que se inicia al concebir el sistema y acaba al retirar de operación (y/o del mercado) el sistema. No hay un ciclo de vida único para el software, la elección de uno u otro dependerá de las necesidades del software, de la estructura de la empresa que lo crea, o del propio criterio del equipo. A grandes rasgos, y de forma común, podemos afirmar que: • A partir de una Necesidad se crea unas Especificaciones (Definir la necesidad); • A partir de unas Especificaciones se crea el Producto Software (Resolver la necesidad); • A partir del Producto se crea una nueva Necesidad (Ampliar la necesidad). Todo proyecto de ingeniería tiene un propósito relacionado con la producción de un producto, proceso o servicio que debe ser generada a través de diversas actividades. Algunas de estas actividades pueden agruparse en fases porque contribuyen a nivel mundial para obtener un producto intermedio, el cual es necesario para alcanzar el producto final y facilitar la gestión de proyectos. La totalidad de las fases utilizadas se denomina ciclo de vida. En cambio, para agrupar las actividades, objetivos de las fases, los tipos de productos intermedios generados, etc, pueden ser distintos dependiendo del producto o proceso a generar y de las tecnologías usadas. La complejidad de las relaciones entre las actividades crece exponencialmente con el tamaño, que se convertiría rápidamente intratable si no fuera por la técnica divide y vencerás. Así, la división de los proyectos en fases es un primer paso para reducir la complejidad, en el caso de la elección de las partes de modo que las relaciones entre ellos sean tan simples como sea posible.

Importante Las decisiones tomadas en cada fase del proyecto tendrá consecuencias en las siguientes. La temprana prevención de errores en cada aspecto del diseño o del desarrollo evitará que estos se arrastren.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

La definición de un ciclo de vida facilita el control sobre cuándo es necesario aplicar todos los recursos (personas, equipos, suministros, etc.) para el proyecto. Si el proyecto incluye subcontratación de partes del sistema, el control de mano de obra contratada se facilita para que esas partes encajen bien en la estructura de las fases. El control de calidad también será facilitado si la separación de fases se asigna a los puntos que se deben verificar (a través de los controles de los productos parciales obtenidos). De la misma manera, la práctica adquirida en el diseño de modelos de ciclo de vida para una variedad de situaciones nos permite beneficiarnos de la experiencia obtenida con el método que mejor se adapte a nuestras necesidades. Un ciclo de vida de un proyecto está compuesto de fases correlativas compuestas por tareas planificables. De acuerdo con el modelo de ciclo de vida, la secuencia de fases se puede ampliar con bucles de realimentación sobre el mismo, lo que se considera conceptualmente la misma fase se puede ejecutar más de una vez más de un proyecto; y el proyecto recibirá en cada pasada las contribuciones de cada ejecución de los resultados intermedios que se producen (esto es lo que se conoce como retroalimentación). Los distintos elementos que integran un ciclo de vida son: • Fases. Una fase es un conjunto de actividades con un objetivo en el desarrollo del proyecto. Se construye al agrupar las tareas (actividades elementales) que pueden compartir un determinado tramo de la vida de un proyecto. Las tareas pueden agruparse de forma temporal, lo que implica que se creen requisitos temporales para poder asignarles los recursos (humanos, financieros y materiales). Cuanto más complejo y de mayor volumen sea un proyecto, será necesario un mayor detalle en la creación de las fases para conseguir que su contenido sea manejable. Así cada fase se considera un pequeño proyecto en sí mismo, compuesto por pequeñas fases. • Entregables. Se trata de los productos intermedios a generar en las fases. Serán materiales (equipos, componentes) o inmateriales (software, documentos). Los entregables servirán para evaluar el proceso del proyecto al comprobar su bondad con los requisitos funcionales y condiciones de realización. Estas evaluaciones pueden servir también para la toma de decisiones en el desarrollo del proyecto. Los ciclos de vida del proyecto definen: • El trabajo técnico que se debe realizar en cada fase;

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

• Quién involucra cada fase (así la ingeniería concurrente necesita que los desarrolladores se involucren en las fases de requisito y diseño) • Cuándo generar los productos entregables en cada fase y cómo revisarlos, verificarlos y validar cada entregable; • Cómo aprobar y comprobar cada fase. Se puede especificar cada fase del ciclo de vida de forma muy general, o bien hacerlo muy detalladamente. Al hacerlo detallado se incluirán diagramas, formularios, listas de control para dar estructura y control. Los ciclos de vida de proyectos tienen ciertas características comunes, como son: • De forma general las fases son secuenciales y, suelen estar definidas por alguna transferencia de información técnica o de componentes técnicos. • El nivel de incertidumbre es muy alto y así se amplía el riesgo de no cumplir los objetivos en relación con el inicio del proyecto. Esta incertidumbre se disminuye según avance el proyecto. • El coste y nivel de personal es bajo al principio, alcanzando su nivel máximo en fases intermedias para luego caer rápidamente al aproximarse a su conclusión. Una de las principales razones de este fenómeno es que aumenta el coste de los cambios y de la corrección de errores al avanzar el proyecto. • Los interesados en el proyecto pueden influir en las características finales del producto que se espera del proyecto. Hay pocos proyectos con ciclos de vida idénticos, incluso teniendo nombres de fases y productos de entrega similares. Algunos ciclos de vida tienen cuatro o cinco fases, pero también los hay con diez más. En un área de aplicación puede haber variaciones significativas. El ciclo de vida del desarrollo de software de una empresa puede tener una única fase de diseño, y otro puede tener fases separadas para los diseños arquitectónico y detallado. Los sub-proyectos podrán también tener ciclos de vida de proyectos diferentes. Así por ejemplo, una empresa de arquitectura que diseñará un nuevo edificio participa en la fase de definición que realiza con el propietario, mientras realiza el diseño, y posteriormente realizará la fase de edificación, mientras da soporte a la construcción.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

El proyecto de diseño del arquitecto tendrá también su propia serie de fases, que va desde el desarrollo conceptual, pasando por la definición, implementación, hasta llegar a la conclusión. El arquitecto puede también tratar el diseño de edificios y la construcción como proyectos separados, cada uno de ellos con su propio conjunto de fases.

RECUERDE

1.1.1. En cascada (waterfall).

Se deben establecer un ciclo de vida personalizado para cada proyecto, teniendo en cuenta las exigencias y características propias del sistema.

Se trata del primer modelo de desarrollo del software y que derivó en otros modelos posteriores. Recibe el nombre debido a su forma de cascada, en la que el flujo del sistema cae de una fase a otra. Se trata de un modelo lineal y cuyas etapas se transforman en actividades del desarrollo, y son: • Análisis y Formulación de los requisitos: definiendo los servicios, metas y excepciones del sistema que se pueden acotar tras las consultas con los usuarios/ clientes. Se detallarán estos requisitos sirviendo como especificaciones del sistema. • Diseño del sistema: diferencia entre los requisitos software y hardware. Formará una arquitectura completa del sistema, identificando y formulando las abstracciones fundamentales del sistema software, así como las relaciones del mismo. • Implementación y pruebas unitarias: en esta etapa se realizan las pruebas como un conjunto o unidades del programa. Las pruebas unitarias implican el verificar que cada unidad cumpla su especificación asociada. • Integración y prueba del sistema en su conjunto: en esta etapa los programas se integran para formar el sistema completo, y así probar las funcionalidades generales del sistema. En esta etapa se asegura la validación completa de los requisitos del software. Tras estas pruebas el sistema se entrega al cliente. • Puesta en servicio y Mantenimiento: suele ser la fase más larga. El sistema se instala y se pone en funcionamiento. El proceso del mantenimiento implica corregir errores no descubiertos antes en las etapas previas. Como puede apreciarse, se trata de un modelo totalmente secuencial, en el que ha de terminar una fase para iniciar la siguiente. No establece la retroalimentación entre fases y la redefinición de las anteriores.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

RECUERDE El modelo en cascada sólo será adecuado para sistemas sencillos y plantea mejoras relevantes frente a no usar ningún modelo.

Modelo de Ciclo de Vida en Cascada 1.1.2. Interativo. Una variante de este modelo es el denominado “Modelo en Cascada Retroalimentado”, que permite la retroalimentación y anidación entre las fases. Pasa a ser un modelo iterativo, y no lineal. Se congelan partes del modelo según las necesidades del proyecto.

Modelo de Ciclo de Vida Iterativo

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

EJEMPLO Para un proyecto de creación de una web para comercio electrónico. Fases: • Requisitos: se realizan reuniones con el cliente para saber lo que piensa que necesita y también hacerle entender lo que realmente necesita (una página web de diseño atractivo, con colores llamativos y agradables, bien maquetada, con una cesta de la compra, una pasarela de pago, etc.); • Diseño: se procede a determinar la estructura de la página web, así como la decisión de cómo realizarlo, qué lenguajes utilizar,…; • Implementación: se implementa el código de la página web (ejemplo: HTML, PHP y JavaScript); • Verificación: se prueba la página web buscando errores y posibles bugs, comprobando si la web hace en todo momento lo que se supone que debe hacer (se prueba a hacer una compra muy grande, pedir muchas unidades del mismo artículo verificando si comprueba el stock, etc); • Mantenimiento: se da soporte a la página web creada por los posibles problemas o errores que puedan surgir. • Se repite todo en una segunda y sucesivas fases, mejorando las características y el funcionamiento real de la web.

Este modelo, junto con el ciclo de vida en cascada, es inflexible en la partición en las diferentes fases, pero constituyen un modelo estructurado en el proceso de ingeniería. 1.1.3. Incremental. Este ciclo de vida se basa en ir incrementando las funcionalidades del programa. De forma iterativa se construyen módulos, cada uno de los cuales cumplirá las funciones del sistema. Esto permitirá aumentar gradualmente las funcionalidades del software. Este modelo permite dividir el trabajo entre distintos equipos para que realice cada uno un módulo.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

El modelo es una evolución del ciclo de vida en cascada que de forma iterativa, ayudará a construir el programa con todas sus funcionalidades. Al terminar cada iteración se entrega una versión al cliente con una nueva funcionalidad. El sistema crea versiones del software mejorando y aprendiendo de las versiones anteriores de forma iterativa. Así habrá una entrega en cada iteración y el cliente conocerá la evolución del sistema en todo momento. Los beneficios de este modelo son: • Permite construir un sistema inicialmente pequeño, lo que conlleva menos riesgos que hacerlo con uno grande; • Al desarrollar independientemente las distintas funciones, es más sencillo detectar los requisitos de usuario; • Si detectamos un error grave, sólo habrá que desechar la última fase del proyecto; • No se requiere tener los requisitos de todas las funcionalidades al principio del proyecto, facilitando la labor de desarrollo (divide y vencerás). Este modelo es especialmente útil cuando el cliente precise entregas rápidas aun siendo estas parciales.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

EJEMPLO Para un proyecto de creación de una web para comercio electrónico. Fases: • Requisitos: se realizan reuniones con el cliente para saber lo que piensa que necesita y también hacerle entender lo que realmente necesita (una página web de diseño atractivo, con colores llamativos y agradables, bien maquetada, con una cesta de la compra, una pasarela de pago, etc); • Diseño: se procede a determinar la estructura de la página web, así como la decisión de cómo realizarlo, qué lenguajes utilizar,…; • Implementación: se implementa el código de la página web (ejemplo: HTML, PHP y JavaScript). Se construye un modelo funcional de la página web. • Verificación: se prueba la página web buscando errores y posibles bugs, comprobando si la web hace en todo momento lo que se supone que debe hacer (se prueba a hacer una compra muy grande, pedir muchas unidades del mismo artículo verificando si comprueba el stock, etc); • Se muestra el modelo al cliente, comprobando si cumple con sus expectativas.

RECUERDE La construcción en módulos dotan al sistema de flexibilidad, permitiendo su construcción por fases y su posterior ampliación.

• Se refina en posteriores iteraciones en las fases anteriores hasta llegar a un nivel aceptado por el cliente, momento en que pasa a ser funcional y se pone en operación. • Mantenimiento: se da soporte a la página web creada por los posibles problemas o errores que puedan surgir. • Si se desea se repite todo en una segunda y sucesivas fases, mejorando las características y el funcionamiento real de la web.

1.1.4. En V. El Método-V fue creado por la Administración Alemana para regular el desarrollo de software. Su nombre es una clara referencia a su representación gráfica. Este modelo resume las principales medidas a adoptar para las prestaciones relativas al marco del sistema de validación.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

El modelo describe las actividades y resultados que deben producirse en el desarrollo del producto. Modelo de Ciclo de Vida “en V” La parte izquierdo de laV se corresponde con las necesidades y las especificaciones del sistema. La parte derecha de la V se corresponde con la integración de las partes y su verificación. V, además de corresponderse con la forma de su imagen, hace referencia a “Verificación y validación”. Es semejante al modelo en cascada clásico, siendo muy rígido y con numerosas iteraciones.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

EJEMPLO página web de diseño atractivo, con colores llamativos y agradables, bien maquetada, con una cesta de la compra, una pasarela de pago, etc); Se realiza un feedback para las pruebas de aceptación del sistema; • Se reflejan los requisitos de la web en un documento. Se realiza un feedback para las pruebas del sistema;

RECUERDE Este modelo define la programación del proyecto asociando cada fase con las pruebas que deben establecerse, siendo bidireccional.

• Diseño: se procede a determinar la estructura de la página web, así como la decisión de cómo realizarlo, qué lenguajes utilizar. Se realiza un feedback para las pruebas de integración del sistema; • Implementación: se implementa el código de la página web (ejemplo: HTML, PHP y JavaScript). Se construye un modelo funcional de la página web. Se realizan las pruebas unitarias de los mismos; • Mantenimiento: se da soporte a la página web creada por los posibles problemas o errores que puedan surgir.

1.1.5. Basado en componentes (CBSE). Este modelo se inicia en 1968, cuando Douglas McIlroy identifica la necesidad de una industria de componentes software para dar solución a la crisis del software. La ingeniería del software basada en componentes (CBSE) (también conocido como desarrollo basado en componentes (CBD)) es una rama de la ingeniería de software que se basa en la separación de las tareas con respecto a la funcionalidad disponible en un sistema determinado. Se trata de un enfoque que se basa en la reutilización del ejercicio de definir, componer e implementar componentes independientes levemente acoplados a los sistemas. Esta práctica se realiza para lograr un grado de tan amplio alcance en las prestaciones, y tanto a largo como a corto plazo, para el mismo software y para las organizaciones que realizan este tipo de software. Los módulos software se construyen ensamblando módulos software reutilizables, que fueron diseñados para que sean independientes de las aplicaciones donde serán utilizados. Los componentes realizan este papel en los servicios web, en las arquitecturas orientadas a servicios (SOA), por medio de un componente

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

es convertido un servicio web en un servicio, y luego hereda características adicionales más allá de la de un componente ordinario. Hay muchas definiciones de componente software, pero una de las más significativas es la que hizo en 1998 Szyperski: “Un componente es una unidad de composición de aplicaciones software, que posee un conjunto de interfaces y un conjunto de requisitos, y que ha de poder ser desarrollado, adquirido, incorporado al sistema y compuesto con otros componentes de forma independiente, en tiempo y espacio”. Las características principales de un componente software son: • Aislamiento: Un componente se puede instalar independiente en una plataforma. • Opacidad: Un componente siempre se maneja de forma opaca, sin que los diseñadores de aplicaciones que lo usan, ni el entorno, deban acceder a sus detalles internos para usarlo. • Componibilidad: Un componente se puede componer de otros para formar aplicaciones. Basada en unos principios fundamentales, que son: • Desarrollar software con piezas ya existentes • Mantener y personalizar las piezas para producir nuevas funciones • Posibilidad de reutilizar las piezas en otras aplicaciones Un modelo de componentes definirá estándares específicos para la composición e interacción. La implementación de un modelo de componentes es el conjunto de elementos ejecutables de software que soportan la ejecución de componentes conformes a un modelo. Los componentes producirán o consumirán eventos, pudiéndose usar para las arquitecturas orientadas a eventos (EDA).

RECUERDE Este modelo de ciclo de vida permite la creación de módulos reutilizables.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

1.1.6. Desarrollo rápido (RAD). El Desarrollo Rápido de Aplicaciones (DRA) (Rapid Application Development RAD) es un modelo de desarrollo del software que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a gran velocidad en el que se logra el desarrollo rápido usando un enfoque de construcción basado en componentes. Si se comprenden los requisitos y se limita el ámbito del proyecto, el proceso DRA permite crear un sistema totalmente funcional en periodos cortos de tiempo. Cuando se usa principalmente para aplicaciones de sistemas de información, el enfoque DRA tendrá las siguientes fases: • Modelado de datos: el flujo de información que se definió como parte de la fase de modelado de gestión se refina como conjunto de objetos de datos requeridos para apoyar la empresa. Se definen los atributos de cada objeto y las relaciones entre ellos. • Modelado de gestión: el flujo de información entre las funciones de gestión hace que responda a las siguientes preguntas: ¿Qué información se genera? ¿Qué información conduce el proceso de gestión? ¿Quién la genera? ¿Quién la procesó? ¿A dónde va la información? • Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos se transforman para lograr el flujo de información necesario para usar una función de gestión. Las descripciones del proceso se crean para modificar, suprimir, añadir, o recuperar un objeto de datos. Es la comunicación entre objetos.

RECUERDE Este modelo, como su nombre indica, es útil para lograr un desarrollo rápido de la aplicación web.

• Generación de aplicaciones: El DRA asume el uso de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de la tercera generación, el proceso DRA se ocupa de rehusar componentes de programas ya existentes, cuando esto sea posible, o a crear componentes reutilizables, cuando se requiera. En todos los casos se usarán herramientas automáticas que facilitarán la construcción del software. • Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se comprobaron muchos de los componentes de los programas. Esto reduce el tiempo destinado a pruebas. Pero se deben probar todos los componentes nuevos y deben ejercitarse todos los interfaces a fondo.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

1.1.7. Ventajas e inconvenientes. Pautas para la selección de la metodología más adecuada. Las principales diferencias entre los modelos de ciclo de vida son: • Las características (contenidos) de las fases que incluye el ciclo. Esto dependerá del propio tema relacionado con el proyecto (no es lo mismo las tareas que se deben realizar para proyectar un puente que un avión), o de la organización (interés por reflejar en la división en fases aspectos relativos a la división interna o externa del trabajo). • El alcance del ciclo de vida, que depende de hasta dónde llegue el correspondiente proyecto. Un proyecto comprometerá un simple estudio de viabilidad para el desarrollo de un producto o toda la historia del producto con su fabricación, desarrollo, y modificaciones posteriores que llegan hasta su retirada del mercado. • La estructura de la sucesión de las etapas, habiendo realimentación, y si se pueden repetir. En todos los modelos de Ciclo de vida se debe contar con el riesgo que supone adoptarlo; con riesgo se entiende la probabilidad que hay de retomar una de las etapas anteriores (lo que supone un esfuerzo en tiempo y dinero). Hay que tener claro que ninguno de los anteriormente citados ciclos de vida evita los riesgos que aparecerán durante el proyecto; siempre va a existir una incertidumbre por el cambio, errores o cualquier otra eventualidad.

1.2. Análisis y especificación de requisitos. La identificación de necesidades será el primer paso del análisis del sistema. En este proceso el Analista se reúne con cliente y/o usuario (un representante departamental, institucional, o un cliente particular), y analizan las perspectivas del cliente, identifican las metas globales, sus necesidades y requerimientos, sobre líneas de mercado/ producto, la planificación temporal y presupuestal, y otros puntos que pueden ayudar a la identificación y desarrollo del proyecto. Esta etapa se divide en cinco partes: • Reconocimiento del problema.

RECUERDE Hay que estudiar las características propias de cada sistema antes de seleccionar el ciclo de vida a usar.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

• Evaluación y Síntesis. • Especificación. • Modelado. • Revisión. Antes de la reunión con el analista, el cliente debe preparar un documento conceptual sobre el proyecto, aunque es recomendable que este se elabore durante la comunicación Cliente-analista, ya que de hacerlo el cliente solo de todas maneras tendría que ser modificado, durante la identificación de las necesidades. La etapa de análisis se encuadra en la fase de definición del ciclo de vida. El análisis de requisitos caracteriza el problema que se trata de resolver. Se concretará en la obtención del modelo global que define totalmente el comportamiento requerido del sistema. Un problema planteado al analista es lograr un interlocutor válido para llevar a cabo el análisis. Este interlocutor puede estar constituido por una o varias personas expertas en una parte o en todo el trabajo que se pretende automatizar. Hay casos en los que no habrá nadie capaz de asumir el papel de cliente, debido a que nadie conoce exactamente lo que se requiere del sistema o simplemente por lo novedoso de la aplicación. No se debe asociar cliente con la persona o entidad que financie el proyecto. El cliente, junto con el analista, será el encargado de elaborar las especificaciones del proyecto de software, que posteriormente se encargarán de verificar el cumplimiento de las mismas a modo de contrato. A veces el cliente será el usuario final de la aplicación, y otras coincidirá con el cliente que financia el proyecto, en otros puede ser parte de una especificación de otro proyecto de mayor envergadura. OBJETIVOS DEL ANÁLISIS El objetivo del análisis es obtener las especificaciones que debe cumplir el sistema a desarrollar. Para lograr esto se debe de realizar un modelo válido, necesario y suficiente donde recoger todas las necesidades y exigencias que el cliente precisa del sistema y además todas aquellas restricciones que el analista considere que debe de verificar el sistema. Quedarán descartadas aquellas exigencias del cliente que no se puedan lograr con los recursos puestos a disposición del proyecto. Quedarán convenientemente matizadas cada una de las exigencias y necesidades del sistema para adaptarlas a los medios disponibles para el proyecto. El modelo global del sistema deberá cumplir: • Ser completo y sin omisiones.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

• Ser conciso y sin trivialidades. • Fácilmente entendible por el cliente. Importante usar un lenguaje que sea asequible y que facilite la colaboración entre analista y cliente. Emplear notaciones gráficas. • Separar requisitos funcionales y no funcionales. • Requisitos funcionales. Destinados a establecer el modelo de funcionamiento del sistema y serán el fruto fundamental de las discusiones entre analista y cliente. • Requisitos no funcionales. Destinados a encuadrar el sistema dentro de un entorno de trabajo. Tienen un origen más técnico y no tienen tanto interés para el cliente. Deben permanecer separados en el modelo del sistema. Capacidades mínima y máxima. Interfases con otros sistemas. Recursos que se necesitan. Aspectos de seguridad, fiabilidad, mantenimiento, calidad. Etc. • No tener detalles de diseño o implementación. El objetivo del análisis es definir QUÉ debe hacer el sistema y no el CÓMO lo debe de hacer. No se debe entrar en ningún detalle del diseño o implementación del sistema en la etapa de análisis. • No tener ambigüedades. El modelo resultante del análisis es un contrato con el cliente. Nada debe quedar ambiguo o de se producirán fricciones y problemas que son de consecuencias difíciles de prever. • Fijando los criterios de validación del sistema. Es importante que en el modelo del sistema queden indicados cuáles serán los criterios de validación del sistema. Un método para fijar los criterios de validación es realizar con carácter preliminar el Manual de Usuario del sistema, aunque en dicho manual no se recogen todos los aspectos a validar, es un buen punto de partida. • Dividiendo y jerarquizando el modelo. Simplificar un modelo complejo del sistema es dividirlo y jerarquizarlo. Esta división dará lugar a sub-modelos. En el modelo global del sistema se debe de ir de lo general a lo particular.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

TAREAS DEL ANALISIS Pasos para la realización correcta de un análisis de requisitos: 1. Estudio del sistema en su contexto. Conocer el medio en el que se va a desenvolver el sistema. Importante, el análisis del dominio de la aplicación. Incide directamente no sólo en la terminología a emplear en la especificación, sino también en la creación de sistemas con una visión más globalizadora y que facilita la reutilización posterior de alguna de sus partes. 2. Identificación de necesidades. La labor del analista es concretar las necesidades que se pueden cubrir con los medios disponibles y dentro del presupuesto y plazos de entrega asignados a la realización del sistema. Fundamental mantener un dialogo constante y fluido con el cliente. El analista deberá recoger y estudiar sus sugerencias para elaborar una propuesta que satisfaga a todos. Descartando funciones muy costosas de desarrollar y que no aportan gran cosa al sistema. Para aquellas funciones que tengan un cierto interés y que requieran más recursos de los disponibles, el analista deberá aportar una solución que aunque sea incompleta, encaje dentro de los presupuestos del sistema. Las necesidades que finalmente se identifiquen deberán estar consensuadas por todos aquellos que junto al analista hayan participado en el análisis. El analista tratara de convencer a todos de que la solución adoptada es la mejor con los medios disponibles, nunca tratara de imponer su criterio. 3. Establecimiento del modelo del sistema. El modelo se irá perfilando a medida que se avanza en el estudio de las necesidades y las soluciones adoptadas. Para la elaboración del modelo se utilizarán todos los medios disponibles, procesadores de texto, herramientas CASE, herramientas gráficas, y todo aquello que contribuya a facilitar la comunicación entre analista, cliente y diseñador. 4. Elaboración del documento de especificación de requisitos. El resultado final del análisis es el documento de especificación de requisitos. Debe de recoger todas las conclusiones del análisis. Una parte fundamental del documento será el modelo del sistema y es en este documento donde se debe ir perfilando su elaboración a lo largo de todo el análisis. Este documento será el que utilice el diseñador como punto de partida de su trabajo. Este documento es el encargado de fijar las condiciones de validación del sistema una vez concluido su desarrollo e implementación.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

5. Análisis de alternativas. Estudio de viabilidad. Existen infinitas soluciones a un mismo problema. Es labor del analista buscar aquella alternativa que cubra las necesidades reales detectadas y que tenga en cuenta su viabilidad tanto técnica como económica. Con cada alternativa presentada es necesario realizar su estudio de viabilidad correspondiente. 6. Revisión continuada del análisis. La labor de análisis no acaba al dar por finalizada la redacción del documento de especificación de requisitos. A lo largo del desarrollo del sistema y según aparezcan problemas en las etapas de diseño e implementación se tendrán que modificar alguno de los requisitos del sistema. También se suelen modificar requisitos debido a cambios de criterio del cliente.

RECUERDE Identificar correctamente las necesidades del cliente y su negocio es clave para la correcta elaboración de las especificaciones, que son el punto clave para la elaboración del software.

1.2.1. Tipos de requisitos. Se pueden establecer numerosas categorizaciones de requisitos, así es frecuente oír sobre requisitos de implementación, requisitos de rendimiento, requisitos de usabilidad… Si bien la categorización más frecuente es la que divide los requisitos según su característica de funcional o de no funcional, así: • Requisito Funcional: característica que precisa el sistema que expresa una capacidad de acción del sistema – una funcionalidad; generalmente expresada en una declaración verbal. Al hablar de una característica requerida de que se sabe que va a ser satisfecha por medio de la adición de un bloque de código o subsistema en el software, entonces estamos ante un requisito funcional, por lo que es un requisito que denota una funcionalidad del sistema. • Requisito no funcional: característica que precisa el sistema sobre el servicio prestado, el proceso de desarrollo u otro aspecto del desarrollo, que señala una restricción del mismo. Un requisito no funcional se refiere a todas las exigencias de cualidades impuestas al proyecto: exigencias para usar un cierto lenguaje de programación o plataforma tecnológica. Un requisito no funcional es una característica bien del proyecto, del sistema o del servicio de soporte, que es requerida junto con la especificación del sistema pero que no se satisface añadiendo código, sino cumpliendo como si de una restricción se tratara. Cabe también destacar la definición de requisito general del producto (que se obtienen del cliente). Estos requisitos comprenden necesidades de control e información, comportamiento y funcionalidad del producto, diseño, restricciones de la interfaz, rendimiento general del producto, y otras necesidades especiales.

RECUERDE Hay que identificar unívocamente tanto las características funcionales del sistema como el resto de implicaciones del proyecto.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

1.2.2. Modelos para el análisis de requisitos. El modelado de los sistemas realizados mediante software también tiene como objetivo entender mejor el funcionamiento requerido y facilitar la compresión de los problemas planteados. El modelo, es completo y preciso del comportamiento u organización del sistema software. Existen diversas metodologías para realizar el análisis de los requisitos que debe cumplir un proyecto software. Todas tienen un aspecto común: facilitar la obtención de uno o varios modelos que detallen el comportamiento deseado del sistema. Modelo conceptual, es todo aquello que nos permite conseguir una abstracción lógico-matemática del mundo real y que facilita la comprensión del problema a resolver. El modelo de un sistema software establece las propiedades y restricciones del sistema.Visión de alto nivel. El modelo debe explicar QUÉ debe hacer el sistema y no CÓMO lo debe de hacer. Objetivos que se deben cubrir con los modelos: • Facilitar la comprensión del problema a resolver. • Establecer un marco para la discusión, que simplifique y sistematice tanto la labor del análisis inicial como de las futuras revisiones del mismo. • Fijar las bases para realizar el diseño. • Facilitar la verificación del cumplimiento de los objetivos del sistema.

TÉCNICAS DE MODELADO: DESCOMPOSICIÓN. MODELO JERARQUIZADO. La primera técnica que se debe usar con un problema complejo es descomponerlo en otros más sencillos. Divide y vencerás. Se establece un modelo jerarquizado, en el que el problema global queda subdividido en un cierto número de subproblemas. • Descomposición horizontal. Descomponer funcionalmente el problema. Ejemplo: Un sistema integral para una empresa, se puede descomponer. Sistema de nóminas, sistema de contabilidad, sistema de facturación, etc. • Descomposición vertical. Descomponer tratando de detallar su estructura.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

Ejemplo: Entrada datos del trabajador, calculo de ingresos brutos, etc. Es posible descomponer cada uno de estos subsistemas en otros más simples. APROXIMACIONES SUCESIVAS Es corriente que el sistema software que se quiera modelar sustituya a un proceso de trabajo ya existente, que se realiza de forma totalmente manual o con un grado de automatización menor del que se pretende lograr con el sistema nuevo. Crear un modelo de partida basado en la forma de trabajo anterior, será un modelo sólo preliminar y tendrá que ser depurado mediante aproximaciones sucesivas hasta alcanzar un modelo final. Es importante contar con la colaboración de alguien que conozca muy bien el sistema anterior y que sea capaz de incorporar mejoras dentro del nuevo sistema y discutir las ventajas e inconvenientes de cada uno de los modelos intermedios elaborados. EMPLEO DE DIVERSAS NOTACIONES Una posible notación para describir el modelo de un sistema es mediante el lenguaje natural, este método puede dar lugar a un modelo difícil de apreciar en su conjunto por lo farragoso de las explicaciones. Se producirán imprecisiones, repeticiones e incluso incorrecciones en el modelo así realizado. Lo ideal es emplear la notación con la que mejor se cubran los objetivos de un modelo. Es aconsejable emplear varias notaciones juntas cuando sea necesario. Existen herramientas de modelado para la ayuda al análisis y diseño de los sistemas, herramientas CASE (Computer Aided Software Engineering) CONSIDERAR DISTINTOS PUNTOS DE VISTA El modelo estará necesariamente influenciado por el punto de vista adoptado. Elegir el que permita obtener el modelo más apropiado para representar el comportamiento que se desea del sistema. • Punto de vista funcional. • Punto de vista del usuario del sistema. • Punto de vista del mantenedor del sistema. • Etc….

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

En ocasiones el modelo no quedará completamente definido con un solo punto de vista. Lo adecuado será realizar el modelo desde distintos puntos de vista. REALIZAR UN ANÁLISIS DEL DOMINIO Dominio es el campo de aplicación que encuadra el sistema a desarrollar. Es importante analizar el dominio de la aplicación para situarla en un entorno mucho más global. Se aconseja estudiar aspectos como: • Otros sistemas semejantes. • Normativa que afecte al sistema. • Estudios recientes en el campo de la aplicación. • Bibliografía clásica y actualizada. • Etc…

RECUERDE Para realizar el modelo conceptual hay que centrarse en lo que hace el sistema y no en cómo lo hace.

Este estudio facilitará que se forme un modelo más universal. Como ventajas de este enfoque tenemos: • Creación de elementos que sean más significativos del sistema. Al ignorar el dominio de una aplicación, la solución se particulariza en exceso. • Facilitar la comunicación entre usuario del sistema y analista. • Reutilización del software desarrollado. 1.2.3. Documentación de requisitos. La especificación es una descripción del modelo del sistema que se pretende desarrollar. Para un mismo modelo conceptual, dependiendo de la notación o notaciones que se empleen para su descripción, se obtendrán distintas especificaciones. El empleo de la notación más adecuada en cada caso redundará en una mejor especificación del sistema. Será preferible usar una notación gráfica que el texto que la pueda describir. Para sistemas de una complejidad pequeña, es suficiente el lenguaje natural. Cuando la complejidad del sistema es mediana o grande, resulta prácticamente imposible utilizar sólo el lenguaje natural. El lenguaje natural se usará siempre que sea necesario aclarar cualquier aspecto concreto

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

del sistema, que no sean capaces de reflejar el resto de notaciones. Siempre que se use el lenguaje natural es muy importante organizar y estructurar los requisitos recogidos en la especificación. La mejor forma, es concebir cada uno de los requisitos como una cláusula de un contrato entre el analista y el cliente. Se pueden agrupar los requisitos según su carácter: • Funcionales • Fiabilidad • Seguridad • Calidad • … Y dentro de cada grupo, establecer y numerar correlativamente las cláusulas de distintos niveles y sub-niveles que estructuren los requisitos. 1. Funcionales 1.1 Modos de funcionamiento. 1.2 Formatos de entrada. 1.3 Formatos de salida. 1.4 … Como opción más formal que el lenguaje natural tenemos el lenguaje natural estructurado, que establece ciertas reglas para la construcción de las frases en las que se especifica una acción de tipo secuencia, condición o iteración. No se trata de usar siempre una misma palabra clave (SI, REPETIR, etc.) sino emplear las misma construcción en todas las frases, al menos, de una misma especificación. Diagramas de flujo de datos (DFD). Notación asociada a la metodología de análisis estructurado, cuyo enfoque es considerar que un sistema software se puede modelar mediante el flujo de datos que entra al sistema, las transformaciones que se realizan con los datos de entrada y el flujo de datos que se produce a la salida como resultado de la transformación. En los diagramas de flujo de datos (DFD) se pueden modelar las transformaciones y los flujos de datos.

RECUERDE Tan importante como documentar todos los requisitos del sistema es la composición de los documentos de requisitos y diseño que entregar al cliente, y el uso de un lenguaje adecuado para su redacción, según el tipo de cliente y del propio sistema.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

Software Requirements Document (SRD). Recogerá el fruto del trabajo realizado en la etapa de análisis del sistema de una forma integral en un sólo documento. Documentos previos al SRD: Estudios de alternativas, Estudios de viabilidad, Historia del proyecto, …. Todos estos documentos tienen una utilidad muy concreta pero no son imprescindibles. El SRD es un documento fundamental y es el punto de partida del desarrollo de cualquier sistema software. La mejor manera de redactar este documento es en forma de contrato con sus distintas cláusulas organizadas y agrupadas según el carácter de los requisitos. Modelo de documento SRD basado en la propuesta de Agencia Espacial Europea:

1. INTRODUCCIÓN

3.1 Requisitos funcionales

1.1 Objetivo

3.2 Requisitos de capacidad

1.2 Ámbito

3.3 Requisitos de interfase

1.3 Definiciones, siglas y abreviaturas

3.4 Requisitos de operación

1.4 Referencias

3.5 Requisitos de recursos

1.5 Panorámica del documento

3.6 Requisitos de verificación

2. DESCRIPCIÓN GENERAL 2.1 Relación con otros proyectos 2.2 Relación con proyectos anteriores y posteriores

3.7 Requisitos de pruebas de aceptación 3.8 Requisitos de documentación 3.9 Requisitos de seguridad

2.3 Objetivo y funciones

3.10 Requisitos de transportabilidad

2.4 Consideraciones de entorno

3.11 Requisitos de calidad

2.5 Relaciones con otros sistemas

3.12 Requisitos de fiabilidad

2.6 Restricciones generales

3.13 Requisitos de mantenibilidad

2.7 Descripción del modelo

3.14 Requisitos de salvaguarda

3. REQUISITOS ESPECÍFICOS

4. APÉNDICES

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

1. INTRODUCCIÓN Visión general de todo el documento SRD. 1.1 Objetivo Exponer brevemente el objetivo del proyecto, a quién va dirigido, participantes y el calendario previsto. 1.2 Ámbito Identificará y dará nombre al producto o los productos resultantes del proyecto. Se explicará que hace y que no hace cada uno. Se detallarán de manera precisa las posibles aplicaciones y beneficios del proyecto. 1.3 Definiciones, siglas y abreviaturas. Glosario que contendrá un listado de definiciones de siglas, términos y abreviaturas particulares utilizadas en el documento, que se quiera reseñar para facilitar su lectura o evitar ambigüedades. 1.4 Referencias Se dará un listado con la descripción bibliográfica de los documentos referenciados. 1.5 Panorámica del documento Describirá la organización y contenido del resto del documento. 2. DESCRIPCIÓN GENERAL Visión general del sistema, ampliando lo contenido en la sección de introducción. 2.1 Relación con otros proyectos Semejanzas y diferencias de este proyecto con otros semejantes o complementarios. Si no hay sistemas o proyectos relacionados, se indicará “No Aplicable” 2.2 Relación con proyectos anteriores y posteriores Indicará si el proyecto es continuación de otro o si continúa el desarrollo para proyectos posteriores. Si no hay proyectos de este tipo, se indicará “No existen.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

2.3 Objetivo y funciones Describe el sistema en su conjunto con las funciones y objetivos principales. 2.4 Consideraciones de entorno Las características especiales que debe tener el entorno se describirán en que se utilice el sistema a desarrollar. Si no requiere características especiales, se indicará “No existen”. 2.5 Relaciones con otros sistemas Describirá las conexiones del sistema con otros sistemas, si debe funcionar de forma integrada en ellos o usando entradas y salidas de información indirectas. Si el sistema no requiere intercambiar información con ningún otro, se indicará “No existen”. 2.6 Restricciones generales Restricciones generales a tener en cuenta para diseñar y desarrollar el sistema. • Lenguajes de programación. • Empleo de determinadas metodologías. • Restricciones hardware • Normas particulares • Restricciones del sistema operativo • Etc.. 2.7 Descripción del modelo Seguramente el apartado más extenso de la sección. Describe el modelo conceptual propuesto para desarrollar el sistema en su conjunto y para cada una de sus partes más relevantes. Se puede realizar usando todas las notaciones y herramientas. 3. REQUISITOS ESPECÍFICOS Se trata de la sección más extensa y fundamental en todo el documento. Debe contener la lista detallada y completa de los requisitos que ha de cumplir el

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

sistema a desarrollar. Se debe explicar de la forma más precisa posible, sin que la descripción de cada requisito resulte excesivamente extensa. Es importante no incluir aspectos de diseño o desarrollo. Los requisitos deben referirse en forma de lista numerada. Cada requisito debe ir acompañado de una indicación del grado de cumplimiento necesario. • Obligatorio • Recomendable • Opcional Los requisitos se agruparán en los siguientes apartados. Si no hay requisitos en alguno, se indicará “No existen”. 3.1 Requisitos funcionales Describen las funciones o QUÉ debe hacer el sistema y están muy ligados al modelo conceptual propuesto. Concretar las operaciones de tratamiento de información, almacenamiento de información, generación de informes, cálculos, estadísticas, operaciones, etc. 3.2 Requisitos de capacidad Se refieren a los volúmenes de información a procesar, tamaños de ficheros o discos, tiempo de respuesta, etc. Se deben expresar mediante valores numéricos. Cuando sea necesario se darán valores para el mejor, el peor y el caso más habitual. 3.3 Requisitos de interfase. Referentes a cualquier conexión con otros sistemas. Incluye: • Bases de datos • Sistemas operativos • Protocolos • Datos a intercambiar con otros sistemas o aplicaciones • Formatos de ficheros 3.4 Requisitos de operación Referentes al uso general del sistema.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

3.5 Requisitos de recursos Referentes al hardware, software, instalaciones, etc. Necesarios para el funcionamiento del sistema. Es importante estimar los recursos con cierto coeficiente de seguridad previendo las necesidades de última hora imprevistas. 3.6 Requisitos de verificación Se refiere a los que debe cumplir el sistema para que facilite la verificación y certificación del correcto funcionamiento. Funciones de emulación, auto-test, simulación, etc. 3.7 Requisitos de pruebas de aceptación Son los que deben cumplir las pruebas de aceptación a que someteremos el sistema. 3.8 Requisitos de documentación Documentación que formará parte del producto a entregar 3.9 Requisitos de seguridad Referentes a la protección del sistema contra cualquier reutilización o manipulación. 3.10 Requisitos de transportabilidad Referentes a la posible utilización del sistema en diversos sistemas operativos o entornos de una forma sencilla y barata. 3.11 Requisitos de calidad Referentes a aspectos relativos a calidad. 3.12 Requisitos de fiabilidad Referentes al límite tolerable de fallos o caídas durante la operación del sistema. 3.13 Requisitos de mantenibilidad Los que debe cumplir el sistema para que se pueda realizar el mantenimiento de forma adecuada la fase de explotación.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

3.14 Requisitos de salvaguarda Los que debe cumplir el sistema para evitar que sus errores durante el funcionamiento o la operación del sistema tengan graves consecuencias en los equipos o personas. 4. APÉNDICES

RECUERDE Hay que estudiar y contemplar diferentes aspectos del software y de su desarrollo para incluirlos en la documentación.

Todos los elementos que completen el contenido del documento, y que no estén recogidos en otros documentos accesibles a los que pueda referenciarse. 1.2.4.Validación de requisitos. Consisten en hacer funcionar un proyecto software o una parte del mismo en condiciones determinadas y comprobar si los resultados son correctos. Su objetivo es descubrir los errores que pueda contener el software. No permiten garantizar la calidad de un producto. Una prueba será exitosa si se descubre algún error, con lo que se sabe que el producto no cumple con algún criterio de calidad/ funcionalidad. Si la prueba no descubre ningún error, esto no garantiza con ello la calidad del producto, ya que puede haber otros errores que se descubrirán con otras pruebas diferentes. 1.2.5. Gestión de requisitos. La gestión de requisitos es un grupo de actividades que ayudan al equipo de trabajo a identificar, seguir y controlar los requisitos y cambios en cualquier momento. Como en la Gestión de Configuración del Software (GCS), la gestión de requisitos comienza en la actividad de identificación. A cada requisito se le asigna un identificador único. Una vez se identificó a los requisitos se desarrollarán un conjunto de matrices para realizar su seguimiento. Cada matriz de seguimiento identifica los requisitos relacionados con uno o varios aspectos del sistema o de su entorno. Entre las posibles matrices de seguimiento encontramos las siguientes: • Matriz de Seguimiento de características: Muestra los requisitos identificados relacionados a las características definidas por el cliente del sistema/ producto. • Matriz de Seguimiento de orígenes: Identifica el origen de cada requisito del sistema.

RECUERDE La validación es necesaria para comprobar el funcionamiento del sistema.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

• Matriz de Seguimiento de dependencias: Indica cómo se relacionan entre sí los requisitos del sistema.

RECUERDE Para proyectos de una cierta complejidad, existen técnicas que nos permitirán hacer un seguimiento del estado y evolución del proyecto.

• Matriz de Seguimiento de subsistemas: Vincula los requisitos a los subsistemas que los gestionan. • Matriz de seguimiento de interfaces: Muestra como los requisitos se encuentran vinculados a los interfaces externos o internos del sistema. En numerosos casos, las matrices de seguimiento se añaden como parte de un requisito de base de datos y se usa para buscar ágilmente los diferentes aspectos del sistema que estén afectados por el cambio de requisito. 1.3. Diseño. Durante la etapa de diseño se pasa progresivamente del QUÉ debe hacer el sistema a CÓMO lo debe hacer, estableciendo la organización y la estructura física del software. Como actividades habituales en el diseño de un sistema tenemos: • Diseño detallado. Se centra la organización de los módulos. Trata de encontrar cuál es la estructura más adecuada para cada uno de los módulos en que se subdividió el sistema global (elaboraría los módulos de definición). Podrán aparecer nuevos módulos que deben incorporarse al sistema global. • Diseño arquitectónico. Es la primera actividad y dentro de ella se abordan los aspectos de organización y estructurales del sistema y la posible división en subsistemas o módulos. Proporcionan una visión global del sistema, por lo que resulta esencial. • Diseño de datos. Se centra en la organización de la base de datos del sistema y puede realizarse en paralelo con el diseño detallado y el procedimental. • Diseño procedimental. Se centra en la organización de las operaciones de cada uno de los módulos (se centra en los módulos de implementación). Se detallan en forma de pseudo código los aspectos más relevantes de cada algoritmo. • Diseño de la interfaz del usuario. El resultado de estas fases debe resultar en una especificación lo más formal posible de la estructura global del sistema así como de cada uno de los elementos. Esto constituye el producto del diseño, que se recogerá en el Documento de Diseño del Sistema (SDD).

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

ABSTRACCIÓN. En el diseño del software se pueden usar fundamentalmente tres formas de abstracción: • Abstracciones funcionales. Sirven para crear expresiones o acciones parametrizadas debido al el empleo de funciones o procedimientos. • Máquinas abstractas. Permiten concretar un nivel de abstracción superior a los anteriores y con él se define formalmente el comportamiento de una máquina. • Tipos abstractos. Sirven para crear nuevos tipos de datos. MODULARIDAD. Además de permitir la división del trabajo aporta como ventajas la claridad, reutilización y reducción de costes. Se debe aplicar el concepto de modularidad incluso en los casos en los que haya limitaciones de tiempo o memoria. Es un concepto de diseño que no debe ligarse a la codificación. REFINAMIENTO. Acerca las especificaciones incluidas en el documento SRD al lenguaje de programación en particular. ESTRUCTURAS DE DATOS. Es tarea del diseñador buscar, partiendo de estructuras básicas (listas, pilas, árboles,..), la más adecuada combinación que dé respuesta a las necesidades de la propia especificación. OCULTACIÓN. El diseño de la estructura de cada uno de los módulos de un sistema debe realizarse de tal manera que dentro de él queden ocultos todos los detalles que sean irrelevantes para su utilización. La ocultación tiene como ventajas la mejora del mantenimiento y de la depuración. GENERICIDAD. Consiste en agrupar los elementos del sistema que usan estructuras semejantes o que precisan un tratamiento similar. Este concepto es muy importante en el diseño y da lugar a soluciones sencillas y fáciles de mantener. Sin embargo su implementación puede llegar a ser problemática.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

HERENCIA. Establece una jerarquía en los elementos que tienen características comunes. Esta característica permite reutilizar gran cantidad de código del software. POLIMORFISMO. Concepto que engloba distintas posibilidades: • Herencia. Produce dos tipos de polimorfismos; cuando una operación anula a otra que es más general se denomina anulación. Cuando no puede implementarse la operación más general, se plantea el polimorfismo diferido, que plantea unas operaciones para el padre que se concretarán en el hijo. • Generalidad • Polimorfismo por sobrecarga. Cuando las funciones, los operadores o los procedimientos adquieren múltiples formas. CONCURRENCIA. Cuando se intenta diseñar un sistema con restricciones temporales se debe de tener en cuenta lo siguiente: • Tareas concurrentes.

RECUERDE En el documento de diseño se refleja cómo debe funcionar el sistema (interrelaciones), más que en lo que hace el sistema.

• Conmutación entre tareas. • Ínter bloqueos • Sincronización de tareas. El concepto de concurrencia incluye una complejidad adicional al sistema que sólo debe utilizarse cuando no haya una solución secuencial. 1.3.1. Modelos para el diseño de sistemas. MODELOS ESTRUCTURALES: Estos modelos cubren un nivel del diseño arquitectónico y tratan de estructurar y desglosar el sistema en sus partes fundamentales.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

• Diagrama HIPO. Diseña los sistemas como una estructura jerarquizada de módulos o subprogramas. El formato de estos módulos se adapta a los propios datos de entrada, al tipo de proceso que se realiza con ellos y la salida que nos proporciona. • Diagramas de Jackson. Diseña los sistemas partiendo de la estructura de los datos de entrada y salida. Esta metodología se engloba dentro de las de Diseño Dirigido pos los Datos, y sirve tanto para especificar la estructura del programa como la de sus datos. • Diagrama de estructura. Describe la estructura de los sistemas como una jerarquía de módulos o subprogramas. No establece una secuencia concreta de utilización de los módulos y sólo va a reflejar una organización estática. MODELOS ESTÁTICOS: Describen las características estáticas del propio sistema sin tener en cuenta el funcionamiento del mismo. • Diccionario de datos. Detalla la estructura interna de los datos que va a manejar el sistema • Diagramas E-R. Permiten definir el modelo de datos, sus relaciones internas y en general la organización del sistema. MODELOS DINÁMICOS: Permiten describir el comportamiento del sistema durante su fase de funcionamiento. • Diagramas de transición de estados. • Diagrama de flujo de datos. • Lenguaje de descripción de programa (PDL). MODELOS HÍBRIDOS: Tratan de cubrir simultáneamente los aspectos estáticos, dinámicos y estructurales. • Diagramas de objetos. • Diagramas de abstracciones.

RECUERDE El uso de herramientas para el diseño ayuda a obtener una visión general del mismo.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

1.3.2. Diagramas de diseño. El estándar UML. El Lenguaje de Modelado Unificado, UML (Unified Modeling Language) que se basa y centra en su notación gráfica, que permite: especificar, visualizar, construir y documentar los objetos de un sistema software. Como se indicaba, UML es un lenguaje de modelado y no un método. La mayoría de los métodos consisten en un lenguaje y un proceso para modelar. Un lenguaje de modelado es la notación, sobre todo gráfica, de la cual se sirven los métodos para expresar sus diseños.Y el proceso es la orientación que se da sobre los pasos a seguir para realizar el diseño. Los objetivos principales del UML son: Proporcionar a los usuarios un lenguaje de modelado visual fácil de utilizar para poder desarrollar e intercambiar modelos. Ser independiente de cualquier lenguaje de programación o proceso de desarrollo concretos El UML modela el sistema usando los objetos que forman parte del mismo, así como las relaciones estáticas o dinámicas que hay entre ellos. UML puede ser usado para expresar los diseños por cualquier metodología de análisis y diseño orientada a objetos. 1. Diagrama de Casos de Uso: muestra las diferentes operaciones que se esperan de un sistema o aplicación y cómo se relaciona con su entorno. Es una herramienta que permite capturar los requisitos, así como la planificación y control de un proyecto interactivo. Cada caso de uso es una operación completa que se desarrolla por los actores y por el sistema en forma de diálogo. El conjunto de casos de uso representa la totalidad de las operaciones desarrolladas por el sistema. 2. Diagrama de Clases: representa un grupo de entidades con propiedades comunes. Una clase es un constructor que va a definir la estructura y comportamiento de una colección de objetos llamados instancia de la clase. 3. Diagrama de Actividades: es un caso especial de un diagrama de estados en el que casi todos los estados son acciones (identificarán que acción se ejecuta en él) y casi todas las transiciones se envían al estado anterior al terminar la acción ejecutada. 4. Diagrama de Iteración: son modelos que describen como colaboran en ciertos ambientes los grupos de objetos. En general un diagrama de interacción captura el comportamiento de un único caso de uso. Hay dos tipos de diagramas de interacción: diagramas de secuencia y diagramas de colaboración. 4.1. Diagrama de Secuencia: muestra la interacción de los objetos de una aplicación durante el tiempo. Esta descripción es importante porque puede

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

detallar los casos de uso, aclarándolos al nivel de mensajes de los objetos existentes, así como también muestra los mensajes usados de las clases diseñadas en el contexto de una operación. 4.2. Diagrama de Colaboración: es una forma de representación de la interacción entre los objetos, o sea, las relaciones entre ellos y la secuencia de mensajes de las iteraciones se indican indicadas por una diferencia de los diagramas de secuencia, pudiendo mostrar el contexto de la operación y los ciclos en la ejecución. Muestra como colaboran los objetos en un solo caso de uso. 5. Diagrama de Estados: muestra el conjunto de estados por los que pasa un objeto durante su vida en una aplicación, junto con los cambios que le permiten cambiar de estado. Está representado principalmente por: estado, elemento y transición. 6. Diagrama de Implementación: muestran ciertos aspectos de la implementación del sistema, incluyendo la estructura del código fuente y su implantación en tiempo real con la arquitectura del sistema. 6.1. Diagrama de Componentes: representa los componentes físicos de la aplicación. 6.2 Diagrama de Despliegue: representa una visualización de los componentes que hay sobre los dispositivos físicos. Ejemplo de diagrama UML

Autor: Felipe Caparelli http://upload.wikimedia.org/wikipedia/commons/e/e9/Uml_diagram.png

RECUERDE El estándar UML se usa para la representación de forma gráfica de las relaciones del sistema.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

1.3.3. Documentación.

RECUERDE Todos los aspectos relativos al diseño del sistema se reflejan en el Documento de Diseño del Software.

El resultado de la labor de la etapa de diseño se recoge en un documento que se utiliza como elemento de partida para las sucesivas etapas del proyecto, el Documento de Diseño del Software SDD. Las normativas establecen el empleo de un Documento de Diseño Arquitectónico (ADD), para describir el sistema en su conjunto y otro Documento de Diseño Detallado (DDD), para describir por separado cada uno de los componentes del sistema. 1.4. Implementación. Conceptos generales de desarrollo de software. 1.4.1. Principios básicos del desarrollo de software. La creación de un nuevo producto de software puede involucrar a docenas, cientos, incluso miles de miembros de los equipos que juegan todos los diferentes roles y trabajar juntos bajo un calendario muy apretado. Los detalles de lo que hacen estas personas, cómo interactúan y cómo se toman las decisiones son parte del proceso de desarrollo de software. El término utilizado en la industria del software para describir un componente de producto de software que se crea y se transmite a otra persona es entregable. La manera más fácil de explicar lo que todas estas prestaciones son es organizarlos en categorías principales. Requisitos del cliente El software está escrito para cumplir con una necesidad de que una persona o un grupo de personas tienen. Para llenar adecuadamente esa necesidad, el equipo de desarrollo de producto debe saber lo que quiere el cliente. Algunos equipos simplemente adivinar, pero la mayoría recogen información detallada en forma de encuestas, los comentarios de las versiones anteriores del software, información de producto de la competencia, las revisiones de revistas, grupos de enfoque, y muchos otros métodos, algunos formales, otros no. Toda esta información se estudia, se condensa, e interpreta para decidir exactamente qué características del producto de software debe tener. El resultado de los estudios de necesidades de los clientes sólo constituirá los datos en bruto, sin describir el producto propuesto; sólo se confirma si se debe (o no debe) ser creado el software y lo que ofrece a los clientes. Los

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

requisitos tienen toda esta información, además de los requisitos obligatorios y no declarados, pero realmente definen lo que el producto va a ser, lo que va a hacer, y cómo será su aspecto. El formato de las especificaciones varía mucho. Algunas compañías cuidan especialmente estas documentaciones, como son los productos en desarrollo para el gobierno, el sector aeroespacial, así como las industrias financieras y médicas, que requieren un proceso muy riguroso con muchos controles y equilibrios. El resultado es una especificación muy detallada y completa de lo que está bloqueado, de lo que significa que no puede cambiar. Todos en el equipo de desarrollo conocerán exactamente lo que están creando. Hay equipos de desarrollo que crean software para aplicaciones menos críticas, que producen las especificaciones mucho menos detalladas. Esto tiene la ventaja de resultar mucho más flexible, pero hay mucho riesgo intrínseco de que el sistema no cumpla finalmente con las expectativas del cliente o con factores de seguridad que hagan que se deseche. Por supuesto, esto varía mucho según la empresa y el proyecto, pero para la mayor parte de las funciones son las mismas, sólo los títulos que son diferentes. La siguiente lista incluye a los principales actores y lo que hacen. Se dan los nombres más frecuentes, pero puede haber variaciones y adiciones: • Los jefes de proyecto, directores de programas, o productores impulsan el proyecto de principio a fin. Suelen ser responsable de escribir las especificaciones del producto, la gestión de la programación y la toma de decisiones importantes, así como de las compensaciones. • Arquitectos o ingenieros de sistemas son los expertos técnicos en el equipo de producto. Suelen ser muy experimentado y por lo tanto están capacitados para diseñar la arquitectura de sistemas en general o el diseño para el software. Ellos trabajan muy estrechamente con los programadores. • Los programadores, desarrolladores o programadores diseñar y escribir software y corregir los errores que se encuentran. Trabajan en estrecha colaboración con los arquitectos y gerentes de proyecto para crear el software. • Probadores o del personal de control de calidad (control de calidad) son responsables de encontrar y reportar problemas en el producto de software. Trabajan en estrecha colaboración con todos los miembros del equipo a medida que desarrollan y ejecutan sus pruebas, y reportar los problemas que encuentren.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

RECUERDE En un proyecto de software hay varios roles que, a partir de cierta complejidad de proyecto, se hace necesario diferenciar para poder delimitar las funciones y roles, así como sus obligaciones y competencias.

• Los escritores técnicos, asistencia al usuario, formación de usuarios, manuales de escritores, ilustradores o crean la documentación en papel y en línea que viene con un producto de software. • Los gestores de la configuración o el constructor se encargan de reunir todo el software escrito por los programadores y toda la documentación creada por los escritores y poner juntos en un solo paquete. Como puede ver, hay varios grupos de personas contribuyen a un producto software. En los equipos grandes que puede haber decenas o cientos que trabajen juntos. Para comunicarse y organizarse con éxito, se necesita un plan, un método para llegar del punto A al punto B y así poder concluir el proyecto con éxito.

1.4.2. Técnicas de desarrollo de software. En los últimos años se ha promovido los criterios de agilidad y la disciplina para desarrollar los productos de software, que siempre se enfrenta a restricciones de costes, tiempo y disponibilidad de recursos. Estas restricciones han de conjugarse con el hecho de que no se debe descuidar la calidad del producto ni el proceso para su desarrollo. Para abordar la cuestión de la producción de software de calidad se han propuesto modelos de referencia, métodos y estándares que definen un conjunto de actividades, procesos y prácticas que se pueden adaptar a la gran diversidad de aplicaciones. En muchos casos se logra establecer ciertas similitudes entre ellos, en otros se consideran aspectos con mayor detalle y específicamente relacionados con la descripción de procesos, practicas y actividades. Un modelo de procesos ágil o disciplinado debe dirigir la implementación de productos de software que se refinen de manera cíclica, con la participación activa del cliente o usuario durante este proceso. Desde un punto de vista práctico, un proceso de implementación ágil o disciplinado incluirá actividades para el uso, la visualización y prueba temprana de la funcionalidad del programa, permitiendo la puesta en servicio parcial y progresiva. De esta forma los desarrolladores de software pueden estudiar la evolución del producto por la transformación progresiva del modelo conceptual, implementable y operativo.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

Modelos de Procesos Disciplinados La elección, definición y mejora de un proceso de desarrollo, de acuerdo con las características de la propia organización así como con el software a desarrollar, han generado el estudio de estándares y prácticas recomendadas, así como a la formalización profesional de los procesos de desarrollo de software. Modelos integrados de capacidad y madurez (CMMI) Los Modelos Integrados de Capacidad y Madurez (o lo que es lo mismo, CMMI) se desarrollaron por el Software Engineering Institute (SEI), para poder medir la madurez y la capacidad de los procesos de software. CMMI recomienda una serie de buenas prácticas para la realización de actividades de desarrollo y del posterior mantenimiento de software. Este modelo cinco niveles para clasificar la madurez de los procesos que emplea la organización para la realización del software, y las clasifica en función de áreas de procesos gestionadas con principios de ingeniería. La implementación de software se incluye en el área de procesos conocida como Solución Técnica, y se corresponde con las metas de desarrollo del diseño y de la implementación del producto. Esta área debe diseñar, desarrollar e implementar soluciones para los requisitos del software enfocándose en evaluar y concretar soluciones que satisfagan un conjunto de requisitos, y desarrollar diseños detallados para dichas soluciones. La práctica de documentación incluye qué documentos son necesarios para la operación, instalación y mantenimiento del sistema: manuales de operación, de entrenamiento, de usuario y ayuda en línea. Cuerpo de conocimientos de la Ingeniería de Software (SWBOK) El cuerpo de conocimientos de la Ingeniería de Software detalla el conocimiento aceptado como necesario para ejercer la profesión de la Ingeniería de Software. La Implementación de Software se corresponde con una de las diez áreas de conocimiento del SWEBOK, definiendo Construcción de Software como la elaboración detallada de software funcional y significativo a través de la combinación de codificación, verificación, pruebas y depuración del código. Es un área en estrecha relación con las áreas de Diseño y Pruebas de Software, debido a que la construcción de software involucra actividades significativas del diseño y de las pruebas. El área Implementación de Software contiene, entre otros, los siguientes fundamentos:

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

• minimizar de la complejidad: creación de un código simple y bien legible; • anticipación del cambio: para la preparación y facilidad de cambios en el código fuente por los cambios en el entorno del software; • construcción para la verificación: realización de de prácticas que permitan comprobar fácilmente, bien manual, bien automáticamente, si el producto desarrollado cumple con la especificación. Estándar ISO/IEC 12207 Se desarrolló por la IEEE en 1995, y establece un marco común de trabajo para los distintos procesos del ciclo de vida del software que se usan como referencia en el desarrollo de software. El estándar contempla los procesos, tareas y actividades que deben implementarse durante la compra de un producto o servicio software así como en el suministro, operación, desarrollo, mantenimiento y disposición de un producto de software. Estándar IEEE 1074 El estándar IEEE 1074 describe los procesos y actividades necesarios para el desarrollo y mantenimiento del software, creando un marco común para los modelos de ciclo de vida. Los procesos del ciclo de vida en este estándar comprenden la implementación, las pruebas y la integración del software en actividades y sub-actividades. Así para la fase de implementación tenemos las siguientes tareas: • Crear código fuente: código compilable, así como sus comentarios asociados; • Crear documentación operativa: documentación requerida para la operación, instalación y soporte del software; • Integrar el software: componer e integrar los componentes de software para que formen un solo entregable; • Conducir revisiones sobre (entre otros procesos) la implementación. Método WATCH El método WATCH es una metodología focalizada en el desarrollo de software basado en componentes.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

El método incluye los procesos de Programación e Integración y Pruebas. El proceso de Programación e Integración se encarga de elaborar, probar e integrar los distintos componentes de la aplicación, y consiste en: • construir, codificar y/o adaptar cada componente; • probar cada componente como una unidad; • integrar estos componentes conforme a la arquitectura del sistema; • probar la integración de los componentes. Desarrollo ágil El conocido como “Manifiesto Ágil” da las pautas de este tipo de desarrollo, y como patrones generales indica que se debe dar mayor prioridad: • A los individuos y sus relaciones, frente a los procesos y las herramientas; • A que el software que funcione, antes que a la documentación detallada; • A la participación del cliente en el proceso, antes que a la negociación del contrato del proyecto; • A responder ante los cambio, antes que a guiarse por un plan estricto. Dentro del Desarrollo Ágil encontramos los siguientes métodos: Programación eXtrema (XP) La Programación Extrema se basa en los valores de comunicación, simplicidad, retroalimentación y valentía del equipo de trabajo, la implantación de prácticas sencillas que permita recibir un feedback de la situación real del proyecto y ajustar todas las prácticas a las situación en cada momento. Tiene como meta reducir el coste del cambio, cuando las metodologías tradicionales buscan que los requisitos se establezcan al comienzo del proyecto de desarrollo y se mantenga estáticos. AgileUP El Proceso Ágil Unificado tiene ciclo de desarrollo en serie respecto a sus procesos generales, iterativo a nivel detallado y con una entrega de versiones del producto incremental a lo largo del tiempo.

RECUERDE Los modelos de desarrollo disciplinarios buscan asegurar la calidad del software producido por encima de cumplir con los plazos.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

RECUERDE Los modelos de desarrollo ágiles buscan producir un software de forma rápida por encima de asegurar la calidad del programa.

En este modelo se concentra el énfasis en entender y priorizar los requisitos, en obtener mejores ideas sobre las soluciones propuestas, y en codificar y probar el producto. Si fuese necesario se desplegarán interna o externamente las primeras versiones del producto, para conseguir un feedback del usuario. La fase de implementación termina cuando se ha desarrollado un producto operacional. 1.5.Validación y verificación de sistemas. Las pruebas del software constituyen un elemento de un tema más amplio que muchas veces es conocido como verificación y validación. La verificación se refiere al conjunto de actividades que se encaminan a aseguran que el software ejecuta correctamente una función específica. La validación se refiere a un conjunto diferente de actividades que se encaminan a asegurar que el software construido se ajusta completamente a los requisitos del cliente. Así podemos diferenciar estos conceptos con las preguntas: • Verificación: “¿Estamos construyendo el sistema correctamente? • Validación: “¿Estamos construyendo el sistema adecuado?” La verificación y la validación abarcan una amplia lista de actividades que incluyen: auditorias de calidad y de configuración, revisiones técnicas formales, monitorización de rendimientos, estudios de factibilidad, simulación, análisis algorítmico, revisión de la documentación, revisión de la base de datos, pruebas de validación , pruebas de desarrollo y pruebas de instalación. Pese a que las actividades de prueba tienen un papel muy importante en V&V, hay muchas otras actividades que son también necesarias.

RECUERDE El término Verificación hace referencia a que el sistema funcione como debe. El término Validación hace referencia a que el sistema cumpla los requisitos del usuario.

Las pruebas serán la última fase desde el que se puede evaluar la calidad y, de forma más pragmática, descubrir los posibles errores. Pero las pruebas no se deben ver como una red de seguridad, ya que esto podría condicionar la fase de programación. Hay que tener en cuenta que no se puede probar la calidad si ésta no está ahí antes de lanzar la prueba, no va a estar tampoco cuando se termine. La calidad se va a incorporar en el software durante el proceso de ingeniería del software. La adecuada aplicación de los métodos y las herramientas, las revisiones técnicas formales efectivas y una sólida gestión y medición, va a conducir a la calidad, que se confirma posteriormente durante las pruebas. Podemos concluir que la prueba del software se relaciona con la garantía de calidad al establecer que la motivación que hay para realizar de la prueba de los sistemas es confirmar la calidad del software por medio de métodos que se pueden aplicar de forma efectiva y económica, tanto para los grandes como para los pequeños sistemas.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

1.5.1. Planificación. En un proyecto de software suele existe un conflicto de intereses inherente que aparecerá al iniciar la fase de pruebas. En esta fase muchas veces se pide a la gente que construyó el software que lo pruebe. Esto parece inofensivo, al fin y al cabo, ¿quién conocerá mejor un programa que los propios que lo han desarrollado? Por desgracia esos mismos programadores van a pretender demostrar a toda costa que el programa está totalmente libre de errores, y que funciona de acuerdo con las especificaciones del cliente y que va a estar listo de acuerdo con los plazos y el presupuesto aprobado. Cada uno de estos intereses se convierte en un inconveniente a la hora de poder encontrar errores a lo largo de los procesos de la fase de prueba. Desde el punto de vista psicológico, los propios análisis y diseño del software (junto con la codificación) serán tareas constructivas. El ingeniero del software va a crear un programa, su documentación y sus propias estructuras de datos asociadas. Al igual que un constructor de edificios, el ingeniero del software está orgulloso de la obra que acaba de construir y se va a enfrentar a cualquiera que trate de sacarle defectos. Cuando comience la fase de pruebas prueba aparecerá una intención de “romper” lo que el ingeniero del software ha construido previamente. Desde el punto de vista del constructor, la prueba puede considerarse (de forma psicológica) como algo destructivo. Por esto el constructor está pendiente, diseñando y ejecutando pruebas que demuestren que su programa funciona, en lugar de enfocar las pruebas en detectar errores. Pero por desgracia los errores seguirán estando. Y si el ingeniero del software no los consigue encontrar el cliente si lo hará. Muy a menudo, existen ciertos malentendidos que se pueden deducir equivocadamente del razonamiento anterior: • el responsable del desarrollo no debería estar en el proceso de prueba; • el software debe conservarse a salvo y lejos de extraños que puedan probarlo de forma despiadada; • los encargados de la prueba sólo deben aparecer en el proyecto cuando comienzan las etapas de prueba. Estos tres razonamientos son erróneos y debe cambiarse la filosofía y el concepto que hay de las pruebas para poder entregar un software de calidad. El responsable del desarrollo del software será responsable de probar las unidades individuales (llamadas módulos) del programa, asegurándose de que cada una cumple con la función para la que fue diseñada. En muchos casos, también se va

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

a encargar de la prueba de integración, y el paso de las pruebas que encaminen a la construcción (y posterior prueba) de su módulo dentro de la estructura total del sistema. Sólo una vez completada la arquitectura del software entrará en juego un grupo independiente de prueba. El papel de un grupo independiente de prueba (GIP) es eliminar los problemas asociados con el software construido. Una prueba independiente va a eliminar el conflicto de intereses que, de otra forma, podría estar presente. Así al personal del equipo independiente de pruebas se le paga para que encuentre errores.

RECUERDE La planificación del proyecto es necesaria para poder cumplir con los plazos acordados con el cliente y, de producirse retrasos, delimitar dónde se están produciendo para corregirlo en posteriores ocasiones.

El responsable del desarrollado del software no entrega el programa al GIP y se desentiende. El responsable del desarrollado y el GIP trabajan estrechamente durante todo proyecto de software para asegurar que se realizan pruebas lo suficientemente exhaustivas. Mientras se está realizando la prueba el desarrollador debe estar disponible para corregir los errores que se vayan detectando. El GIP forma parte del equipo del proyecto de desarrollo de software debido a que se ve implicado durante el proceso de especificación y posteriormente seguirá implicado (en las fases de planificación y especificación de los procedimientos de prueba) en lo que dure el proyecto. Sin embargo, en muchas ocasiones, el GIP informa a la organización de garantía que se ofrecerá respecto a la calidad del software, consiguiendo así un grado de independencia que no sería posible si fuera una parte del desarrollo del software.

1.5.2. Métodos formales de verificación. El proceso de ingeniería del software puede verse en forma de espiral. Inicialmente, la ingeniería de sistemas definirá el papel del software y conducirá al análisis de los requisitos del software, donde se establecen el dominio de la información, la función, las restricciones, el rendimiento, el comportamiento y los criterios de validación del software. Al movemos hacia el interior de la espiral se encamina hacia el diseño y por último, a la codificación del software. Para desarrollar un software daremos vueltas en la espiral por medio de una serie de flujos o líneas que disminuyen el nivel de abstracción en cada vuelta de la espiral.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

También podemos ver la estrategia de la prueba del software en el contexto de la espiral. La prueba de unidad comenzará en el vértice de la espiral y se centrará en cada unidad del software tal y como está implementada en forma de código fuente. La prueba avanza desplazándose hacia fuera de la espiral para llegar a la prueba de integración, donde se enfoca la atención en el diseño y construcción de la arquitectura del software. Dando otra vuelta hacia fuera por la espiral encontramos la prueba de validación, donde se validan los requisitos que se establecieron como parte del análisis de requisitos del software, para compararlos con el sistema que se construyó. Y finalmente si consideramos el proceso como un procedimiento, las pruebas, en el contexto de la ingeniería del software, son una serie de cuatro pasos llevados a cabo secuencialmente. De forma inicial la prueba se centrará de forma individual en cada módulo, asegurando que los módulos funcionan adecuadamente como una unidad (de ahí el nombre de prueba de unidad). La prueba de unidad se realiza usando las técnicas de prueba de caja blanca (que se explicarán más adelante), ejercitando caminos específicos en la estructura de control del módulo para poder asegurar un alcance completo y una detección máxima de errores. A continuación, deben ensamblarse o integrarse los módulos para formar el paquete de software completo. La prueba de integración va dirigida a todos los aspectos asociados con el ejercicio de verificación y de construcción del programa. Durante la integración prevalecen las técnicas de diseño de casos de prueba de caja negra (que también se verán más adelante), aunque adicionalmente se pueden llevar a cabo algunas pruebas de caja blanca para asegurar que se cubren los principales caminos de control. Después de que el software fuese integrado, se establecen un conjunto de pruebas de alto nivel. Se deben comprobar los criterios de validación (que fueron establecidos durante el análisis de requisitos). La prueba de validación dota de una seguridad final de que el software va a satisfacer todos los requisitos funcionales, de comportamiento y de rendimiento. Durante la validación del sistema se usan exclusivamente técnicas de prueba de caja negra. Llegamos así a la prueba del sistema en global, en la que se prueba el software y otros componentes del sistema como un todo. Para probar software nos movemos hacia fuera por una espiral que, a cada vuelta hacia fuera, aumenta el alcance de la prueba.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

El último paso de la prueba de alto nivel quedará fuera de los límites de la ingeniería del software, entrando en el contexto de ingeniería de sistemas, que resulta más amplio. El software, una vez validado, debe combinarse con el resto de elementos del sistema (como el hardware, bases de datos, …). La prueba del sistema verifica que cada elemento encaje adecuadamente y que alcanza la funcionalidad y el rendimiento del sistema total. Criterios para completar la prueba: Cuando se realizan las pruebas del software surge una clásica pregunta: ¿Cuando hemos terminado la fase de pruebas?, ¿cómo sabemos que hemos probado lo suficiente? Por desgracia no hay una respuesta definitiva a esta pregunta, pero hay algunos criterios prácticos y nuevos intentos de base empírica. Una respuesta a la pregunta anterior es: “La prueba nunca terminará, ya que el responsable del desarrollo del software pasa el problema al cliente.” Cada vez que el cliente/usuario ejecute un programa, dicho programa se está probando con un nuevo conjunto de datos. Este hecho subraya la importancia de realizar otras actividades en la fase de garantía de calidad del software. Otra respuesta también cierta es: “Se termina la prueba cuando se agotan los recursos bien de tiempo, bien de dinero asignados para tal efecto.” Aunque algunos profesionales usen estas respuestas como argumento, un ingeniero del software debe usar un criterio más riguroso para determinar cuando se ha realizado la prueba suficiente. La respuesta debe ir en la línea de: “No podemos tener la absoluta certeza de que el software no fallará jamás, pero con base a un modelo estadístico teórico y validado experimentalmente, se han realizado las pruebas suficientes para decir, con un 95% de certeza, que la probabilidad de funcionamiento libre de fallo del sistema para 1000 horas de CPU, en un entorno definido de forma probabilística, es menor al 0,995. Por medio del modelado estadístico y de la teoría de fiabilidad del software, se pueden desarrollar modelos de fallos del software diferentes a los descubiertos durante las pruebas, como pueden ser una función del tiempo de ejecución. Por la agrupación de métricas durante la fase de pruebas y, haciendo uso de los modelos de fiabilidad del software que existen, es posible desarrollar las directrices importantes para responder a la pregunta: ¿cuándo terminamos la prueba?

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

Indudablemente todavía queda mucho trabajo por hacer antes de que se puedan establecer unas reglas cuantitativas para las pruebas, pero los enfoques empíricos que actualmente existen son mucho mejores que la pura intuición. 1.5.3. Métodos automatizados de análisis. El poder ofrecer un nivel de prestaciones y calidad adecuado (en criterios de seguridad, corrección, etc.) repercute en que los sistemas software actuales tengan una complejidad tal que su desarrollo, mantenimiento y su uso exijan el uso de técnicas y herramientas de asistencia automáticas durante toda la vida útil del software.

RECUERDE Establecer las pruebas adecuadas (en cuanto a método y cantidad de pruebas) es un estudio que debe realizarse para optimizar el tiempo de pruebas sin descuidar la calidad del software.

Estas técnicas deben basarse en fundamentos sólidos que permitan al usuario (gestor, ingeniero o programador) mantener el control y la confianza en la aplicación. Esta es la máxima que permite la aplicación de los métodos formales en la ingeniería del software. Para mejorar los resultados del uso de los métodos formales, este enfoque emplea una aproximación rápida que, al contrario que los métodos tradicionales que promueven una excesiva formalización y que requieren que los usuarios finales tengan una cierta formación matemática, se basa en una selección enfocada y precisa de los métodos y notaciones, que integre varias técnicas formales, lenguajes y herramientas automáticas que revierta en una mejor y más sencilla aplicación. Los métodos formales, y las herramientas y técnicas automáticas asociadas se enfocan en dar soporte racional y continuo al desarrollo del software. Usando un enfoque moderno que tenga en cuenta tanto los propios programas, como los datos y propiedades, se usarán distintos procesos formales que compongan automáticamente estos componentes. Así encontramos, entre otros, estos mecanismos: • Modeling: enfocada al análisis y especificaciones; • Diagnóstico y Corrección: enfocado a la depuración; • Análisis y Transformación: enfocado a la optimización; • Machine learning: enfocado a la síntesis; • Model-checking: enfocado a la verificación; • Proof-carrying code: enfocado a la certificación.

RECUERDE Con ciertos métodos formales creados específicamente para cada aspecto del desarrollo software, podemos tener un soporte en el análisis de ese aspecto durante el desarrollo del software.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

1.6. Pruebas de software. Las pruebas del software constituyen un elemento crítico para la garantía de la calidad del software y representan una revisión final de las especificaciones, diseño y codificación. La creciente percepción del software como un componente del sistema y la relevancia de los costes asociados a los fallos del propio sistema, están propiciando la creación de pruebas cada vez más minuciosas y mejor planificadas. Es frecuente encontrarnos con que desarrollo de software emplee entre el 30 y el 40 por ciento de los recursos de un proyecto en las pruebas del mismo. En casos extremos, las pruebas del software para actividades críticas (por ejemplo, control de tráfico aéreo, control de reactores nucleares) pudiendo costar de tres a cinco veces más que el resto de los pasos de la ingeniería del software juntos. Durante las fases de definición y de desarrollo el ingeniero trata de construir el software partiendo de un concepto abstracto para llegar a realizar una implementación tangible. Posteriormente llegan las pruebas, en las que el ingeniero crea una serie de casos de prueba que van a intentar “romper” el software construido. Así las pruebas son uno de los pasos de la ingeniería del software que se puede apreciar por algunos como destructivos en lugar de constructivo si bien, como ya hemos dicho, es una fase más en el intento de conseguir de un software de calidad. Con las pruebas sólo puede demostrar que existen defectos en el software, en ningún momento se puede asegurar la ausencia de defectos porque las pruebas implementadas hayan pasado correctamente (salvo en el hipotético caso de poder probar toda la casuística). Cualquier proceso de ingeniería puede ser probado de varias formas: • Se pueden realizar pruebas que demuestren que cada función es totalmente operativa. Esto se conoce como prueba de caja negra. • Se pueden realizar pruebas que aseguren que la operación interna se ajusta a las especificaciones y que se han comprobado adecuadamente todos los componentes internos. Esto se conoce como prueba de la caja blanca. Como parte del proceso industrial las pruebas añaden un valor añadido al producto: todos los programas contienen errores y la fase de pruebas se basa en descubrirlos. El objetivo concreto de las fases de pruebas es el conseguir encontrar el mayor número de errores posible. Las pruebas de software son un elemento crítico para poder garantizar la calidad del software y constituye una revisión final de las especificaciones, el diseño y la codificación.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

Es frecuente afirmar que el objetivo de esta fase es convencerse de que el sistema funciona bien, ya que este es objetivo de las fases anteriores; esto es falso. El objetivo de las pruebas es encontrar los fallos que haya en el sistema para poder cumplir objetivo final de un sistema tras las pruebas, que ya sí es el realizar un sistema que funcione bien y haga lo que debe hacer. Para implementar una estrategia de prueba exitosa se deben considerar los siguientes puntos: • Especificar los requisitos del producto de forma cuantificable con suficiente antelación al comienzo de las pruebas. Aunque el objetivo principal de la prueba sea encontrar errores una adecuada estrategia de prueba también evaluará otras características de calidad como la facilidad de mantenimiento y facilidad de uso, así como la transportabilidad del sistema. Esto debería especificarse de forma que sea medible para evitar la ambigüedad de los resultados de la prueba. • Comprender los usuarios que tendrá el software y desarrollar un perfil para cada usuario o categoría de usuarios. Para este fin se deben usar casos que describan el escenario para la interacción para cada categoría de usuario pudiendo reducir el esfuerzo total de prueba, para así concentrar la prueba en el test del producto software en sí. • Establecer los objetivos de la prueba de manera explícita. Se deberían establecer en términos medibles los objetivos específicos de la prueba. Por ejemplo la cobertura de la prueba, efectividad de la prueba, el coste para encontrar y arreglar errores, tiempo medio de fallo, densidad de fallos remanente o frecuencia de ocurrencia, y horas de trabajo por prueba de regresión.Todos estos parámetros deberían tenerse en cuenta en la planificación de la prueba. • Construir un software robusto enfocado en la posibilidad de probarse por sí mismo. El software debe diseñarse para que use tipos de depuración anti-errores. De esta forma el software podrá de diagnosticar ciertos tipos de errores. Y además de esto, el diseño debe incluir una batería de pruebas automatizadas y de pruebas de regresión. • Crear un plan de prueba que haga énfasis en la prueba de ciclo rápido. Se recomienda que una parte del equipo de ingeniería del software aprenda a probar en ciclos rápidos de incrementos de funcionalidad y/o la mejora de la calidad útiles para el cliente y que se puedan probar en el emplazamiento final del sistema. La realimentación que se genera por estas pruebas de ciclo rápido se puede usar para controlar los niveles de calidad y las estrategias de prueba. • Usar revisiones formales, de carácter técnico y formal, como filtro antes de realizar la prueba. Estas revisiones pueden resultar tan efectivas en el descu-

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

RECUERDE El proceso de pruebas es fundamental para la elaboración de un software de calidad. Hay una serie de pautas a seguir ara poder establecer la adecuada estrategia de pruebas.

brimiento de errores como las propias pruebas. Por este motivo las revisiones pueden reducir el esfuerzo de prueba que se necesita para producir un software de alta calidad. • Realizar revisiones técnicas formales para poder evaluar la estrategia de prueba y los propios casos de prueba. Las revisiones técnicas formales posibilitan el descubrir omisiones, inconsistencias y errores claros en el enfoque de la prueba. Esto ahorra tiempo y mejora también la calidad del producto. • Desarrollar una mejora continua al proceso de prueba. La estrategia de prueba es un proceso que debe ser cuantificable. Las métricas agrupadas en la prueba deben usarse como parte del enfoque estadístico para el control del proceso de la prueba del software. 1.6.1. Tipos. Se pueden establecer varias clasificaciones de las pruebas, como son: • Pruebas estáticas: Son aquellas que se realizan sin ejecutar el código de la aplicación. • Pruebas dinámicas: Son aquellas que requieren ejecutar el código de la aplicación para su aplicación. También pueden diferenciarse en: • Pruebas funcionales; • Pruebas no funcionales. Según su ejecución pueden diferenciarse las pruebas en: • Manuales • Automáticas: En las pruebas de software la automatización de las pruebas consiste en el uso de un software especial (que casi siempre se encuentra separado del software que se está probando) para controlar así la ejecución de las pruebas y poder comparar los resultados obtenidos con los resultados esperados. La automatización de pruebas permite también incluir pruebas repetitivas (iteración) que son necesarias dentro del proceso formal de pruebas que ya existe, o bien adicionar otras pruebas cuya ejecución manual resultaría más difícil.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

Según el enfoque de las pruebas en: • Pruebas de caja negra: se denomina caja negra al elemento que se estudia desde el punto de vista de las entradas que recibe y las respuestas o salidas que produce, sin tener en cuenta el funcionamiento interno del sistema. En otras palabras, del sistema nos interesará cómo interactúa con el medio que le rodea (en algunas ocasiones serán otros elementos que también podrían ser tratados como cajas negras) entendiendo qué es lo que el sistema hace, pero sin importar cómo lo hace. Por lo tanto, de una caja negra se debe definir muy bien sus entradas y salidas (su interfaz); y en cambio, no se necesita definir ni conocer los detalles de cómo funciona internamente. • Pruebas de caja blanca: se centran en los detalles del software en relación a cómo trata los datos, por lo que su diseño está muy ligado al código fuente. El ingeniero de pruebas escoge los distintos y adecuados valores de entrada para examinar la ejecución del sistema en cada uno de los posibles flujos de ejecución del programa y comprobar así que devuelven las salidas adecuadas. Según los niveles que se prueban: • Pruebas unitarias: La prueba de unidad centra la verificación en la menor unidad posible y completa que hay en el diseño del software: el módulo. Usando como guía la descripción del diseño procedimental, se comprueban los caminos de control más importantes para descubrir errores en el límite del módulo. • Pruebas de integración: La prueba de integración se trata de una técnica sistemática para poder construir la estructura del programa mientras que se llevan a cabo las pruebas para detectar todos los errores asociados con la interacción. El objetivo es, a partir de los módulos ya probados en las pruebas unitarias, construir una estructura del programa que esté de acuerdo con lo que indica el diseño. • Pruebas de sistema: Como ya se ha indicado, el software es sólo un elemento de un sistema mayor. Al final del proceso el software se integra con el resto de elementos del sistema (elementos como el nuevo hardware, bases de datos, etc.) y se realizan una batería de pruebas de integración del sistema y de validación. Estas pruebas están fuera del ámbito de la ingeniería del software y no las debe realiza únicamente el desarrollador del software. En cambio los pasos dados en el diseño del software y durante la prueba pueden mejorar enormemente la probabilidad de éxito en la fase de integración del software en el sistema completo. Finalmente, y según lo que se quiere probar, podemos diferenciar entre:

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

RECUERDE Las clasificaciones de las pruebas pueden ser numerosas, si bien las más importantes son las que hacen referencia a qué aspecto del software se está probando y las referidas a los niveles del software.

• Pruebas de recuperación. Comprueban la capacidad del sistema para recuperarse ante los eventuales fallos que puedan producirse. Además de provocar el fallo se debe de comprobar que el sistema lo detecte si está especificado, que lo corrige y verificar si el tiempo de recuperación es menor de lo especificado como límite. • Pruebas de seguridad. Comprueban los mecanismos de seguridad contra un acceso o manipulación no autorizada. Las pruebas deben de intentar provocar la violación de los mecanismos previstos para la protección. • Pruebas de resistencia. Comprueban el comportamiento del sistema ante las posibles situaciones excepcionales. Con ellas se debe forzar el sistema por encima de sus prestaciones y capacidades normales para verificar su funcionamiento en estos casos. • Pruebas de sensibilidad. Comprueban el tratamiento que da el sistema a ciertas peculiaridades, que casi siempre se relacionan con los algoritmos matemáticos utilizados. Se debe buscar los datos que produzcan alguna operación incorrecta, o al menos poco precisa, en un entorno considerado como sensible. • Pruebas de rendimiento. Comprueban las prestaciones del sistema consideradas como críticas en cuanto al tiempo. Se realizan sobre todo en sistemas de ejecución en tiempo real. 1.6.2. Pruebas funcionales (BBT). Las pruebas de caja negra, también llamada prueba de comportamiento, se centran en comprobar los requisitos funcionales del software. O lo que es lo mismo, esta prueba permite obtener los conjuntos de condiciones de entrada para que se pasen completamente todos los requisitos funcionales del programa. La prueba de caja negra no constituye una alternativa a las técnicas de prueba de caja blanca, es más bien un enfoque complementario que intentará descubrir otros tipos de errores diferentes que los que descubrirán los métodos de caja blanca. La prueba de caja negra intenta encontrar errores de las siguientes categorías: • errores en las estructuras de datos o en los accesos a bases de datos externas, • funciones incorrectas o que están ausentes, • errores en el rendimiento, • errores de inicialización y de terminación, • errores en el interfaz.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

A diferencia de la prueba de caja blanca, que se realiza previamente, la prueba de caja negra tiende a aplicarse en fases posteriores de la prueba. Ya que estas pruebas de caja negra ignoran de forma intencionada la estructura de control, va a centrar su atención en la prueba de la información que se devuelve. Las pruebas de caja negra se diseñan para responder a las siguientes preguntas: • ¿Cómo se prueba la validez funcional del sistema? • ¿Qué niveles y volúmenes de datos va a tolerar el sistema? • ¿Qué tipos de entrada tendrán unos buenos casos de prueba? • ¿Cómo se prueba el comportamiento y el rendimiento del sistema? • ¿Es el sistema más sensible a ciertos valores de entrada? • ¿Qué efectos en la operación del sistema tendrán combinaciones de datos específicas? • ¿Cómo están aislados los límites de un tipo de datos? Con estas técnicas de prueba de caja negra se elabora un conjunto de casos de prueba destinadas a satisfacer los siguientes criterios: • Casos de prueba que van a reducir, con un coeficiente mayor que uno, el número de casos de prueba adicionales a diseñar para alcanzar una prueba adecuada; • Casos de prueba que informan sobre la presencia o ausencia de los tipos de errores en lugar de errores únicamente asociados con la prueba que realizamos. 1.6.3. Pruebas estructurales (WBT). La prueba de caja blanca, también llamada prueba de caja de cristal, es un método de diseño de casos de prueba usado para, a partir de la estructura de control del diseño procedimental, obtener los casos de prueba. Por medio de estos métodos de prueba de caja blanca se puede obtener un conjunto de casos de prueba que: • garanticen que se ejecuten al menos una vez todos y cada uno de los caminos independientes de cada módulo; • ejecuten todas las decisiones lógicas como verdadera/ falsa;

RECUERDE Las pruebas de caja negra no tiene en cuenta cómo funciona el sistema, sólo estudia las salidas que se producen ante las distintas entradas.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

• ejecuten todos los bucles en sus límites y con sus propios límites operacionales; • ejecuten todas las estructuras internas de datos para poder garantizar su validez. A menudo se piensa que un camino lógico va a encontrarse con pocas posibilidades de ejecutarse cuando se pueda ejecutar de una forma normal. A veces el flujo lógico de un sistema no es nada intuitivo, lo que hace que las posibles suposiciones intuitivas en torno al control del flujo y los datos pueden llevar a incluir errores en el diseño los cuales sólo se van a descubrir cuando comience la prueba del camino elegido. Con este método puede surgir una duda: ¿Por qué usar tiempo y energía preocupándose de las minuciosidades lógicas cuando se podría emplear mejor el esfuerzo para asegurar que se alcanzaron los requisitos del programa? O lo que es lo mismo, ¿por qué no gastamos todas nuestras energías en la prueba de caja negra? La respuesta a esta pregunta se encuentra en la propia naturaleza de los defectos del software:

RECUERDE Las pruebas de caja blanca se centran en cómo funciona internamente el sistema (flujo de los datos).

Hay que tener en cuenta que el número de suposiciones incorrectas y errores lógicos son inversamente proporcionales a la probabilidad de ejecutar un camino del programa. Los errores tienden centrarse en las fases de diseño e implementación de las condiciones, funciones o controles que están fuera de lo normal. Así los procedimientos habituales suelen ser más comprensible y fáciles de ejecutar, mientras que el estudio y el procesado de casos especiales tiende a ser complicado. Los errores tipográficos son muy aleatorios. En el proceso de traducción de un programa de código fuente a un lenguaje de programación es probable que se cometan ciertos errores. Muchos de ellos se descubrirán por ciertos mecanismos de comprobación de sintaxis que dan muchas de las herramientas de programación, pero hay otros que permanecerán ocultos hasta que comience la prueba; y es tan probable que haya un error tipográfico en un camino lógico que apenas se recorra, como que éste aparezca en un camino principal. 1.6.4. Comparativa. Pautas de utilización. Pruebas de Caja negra: Las pruebas del software en el desarrollo de sistemas de información se aplican, como se indicó anteriormente, de forma similar a una espiral, que se ejecuta moviéndonos de adentro hacia a fuera.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

• La PRUEBA DE UNIDAD empieza en el vértice de la espiral y se va a centrar en cada módulo del software, tal como esté implementado en código fuente. • La prueba avanza para pasar a la PRUEBA DE INTEGRACIÓN, donde la atención recae sobre el diseño y la construcción de la arquitectura del software. • En la siguiente vuelta hacia afuera encontramos la PRUEBA DE VALIDACIÓN, donde se validan los requisitos que se establecieron en el análisis de requisitos del software, los cuales se comparan con el sistema que fue construido. • Finalmente se concluye con la PRUEBA DEL SISTEMA, en la que se prueban como un todo el software, así como el resto de elementos del sistema. Pruebas de Caja blanca: Método de prueba de caja blanca del camino básico Es una técnica que permite obtener una medida de la complejidad lógica de un diseño procedimental. Y permite también usar esta medida como una guía para la definición del conjunto básico de caminos de ejecución. Los casos de prueba obtenidos a partir del conjunto básico garantizan que durante la prueba se ejecute al menos una vez cada sentencia y camino del programa. Método de prueba de caja blanca de condiciones Prueba los tipos de errores que pueden aparecer en una de las siguientes condiciones: • Hay un error en un operador lógico • Hay un error en un operador relacional • Hay un error en una expresión aritmética • Hay un error en un paréntesis lógico Método de prueba de caja blanca de bucles Se trata de pruebas para Bucles simples (siendo “n” el número máximo de iteraciones permitidas en el bucle). Los objetivos de este método son: • No ejecutar nunca el bucle;

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

• Ejecutar una sola vez el bucle;

RECUERDE Las pruebas de caja negra/ blanca no son excluyentes, así cada tipo de prueba (caja negra o caja blanca, así como sus variantes) van enfocadas a probar un tipo de cosas.

• Ejecutar dos veces el bucle; • Ejecutar m pasos por el bucle con m < n; • Ejecutar n-1, n y n + 1 pasos por el bucle. Pruebas estructurales Las pruebas estructurales son de tipo caja blanca y constituyen una aproximación al diseño de casos de prueba donde las pruebas parten del conocimiento de la estructura y de la implementación del software. 1.6.5. Diseño de pruebas. El diseño de pruebas para cualquier producto de ingeniería puede requerir el mismo esfuerzo como llevó el diseño inicial del producto. Pero los ingenieros del software a menudo tratan las pruebas como algo sin importancia, desarrollando casos de prueba que parecen adecuadas, pero que tienen poca garantía de ser completas. Volviendo al objetivo de las pruebas, se deben diseñar pruebas que tengan la mayor probabilidad de encontrar el mayor número de fallos y errores con la mínima cantidad de esfuerzo y recursos, y el menor tiempo posible. Tendremos en cuenta que cualquier producto de ingeniería puede probarse de una de estas dos formas: • conociendo la función específica para la que fue diseñado, así se pueden llevar a cabo pruebas que demostrarán que cada función es completamente operativa y a la vez centrado en la búsqueda de errores en cada función; • conociendo el funcionamiento del producto pueden diseñarse pruebas que aseguren que los módulos encajen perfectamente, que la operación del sistema se ajusta a las especificaciones y que todos los componentes internos se comprobaron correctamente. El primer enfoque de prueba se llama prueba de caja negra, mientras que el segundo se denomina prueba de caja blanca. Cuando se considera un proceso de ingeniería de un producto software la prueba de caja negra se refiere a las pruebas que se realizarán sobre la interfaz

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

de usuario del software, así los casos de prueba tratan de demostrar que las funciones del software son operativas y adecuadas, así como que la entrada se acepta correctamente y que se produce un resultado adecuado, al igual que se mantiene la información externa (como los archivos de datos). Una prueba de caja negra examina aspectos del modelo fundamental del sistema sin contemplar la estructura lógica interna del sistema. La prueba de caja blanca se basa en el examen meticuloso de los detalles de funcionamiento del sistema. Se comprueban los caminos lógicos del software al diseñar casos de prueba que prueben conjuntos específicos de condiciones y/ o bucles. Se puede examinar el estado del software en diversos puntos para determinar si el estado real coincide con el esperado según las especificaciones. El método de prueba de camino básico se puede aplicar a un diseño procedimental detallado o a un código fuente. La prueba del camino básico se puede enfocar como una serie de pasos, a modo de ejemplo: • Usando el diseño o el código como base, se dibuja el grafo de flujo que se corresponda. • Se halla la complejidad ciclomática del grafo de flujo que resulte. • Se halla un conjunto básico de caminos linealmente independientes. • Preparamos los casos de prueba que ejecutarán el conjunto básico de cada camino. Se deben escoger los datos para que las condiciones de los nodos del resultado estén totalmente establecidas para así poder comprobar cada uno de los camino. 1.6.6. Ámbitos de aplicación. Dentro del diseño de las pruebas del software se incluye una sección relativa al ámbito de aplicación de las pruebas a realizar. Este capítulo contiene las tareas de pruebas necesarias para poder conseguir el objetivo del proyecto, así como los diferentes enfoques de las pruebas que se deben adoptar, en definitiva, la consecución de los requisitos de usuario. No es la descripción detallada de las pruebas (esto se describe en el capítulo “Casos de prueba”), si no un listado de tareas y características que posteriormente serán evaluadas.

RECUERDE Se debe perfilar perfectamente el objetivo de las pruebas para realizar un eficiente diseño de las mismas.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

RECUERDE El ámbito de las pruebas incluye las tareas de pruebas necesarias para conseguir el objetivo del proyecto.

Esta sección también debe incluir el conjunto de tareas de pruebas descartadas. • Pruebas dentro del ámbito: Es el conjunto de tareas enfocadas a la consecución de los objetivos del proyecto, y que permite probar el sistema en su iteración actual dentro de su entorno. • Pruebas fuera del ámbito: Es un listado de las pruebas que quedaron excluida del ámbito de pruebas las cuales pudieron haber sido establecidas dentro del mismo. Estas pruebas que quedan fuera, en muchos casos se documentan también, justificando el por qué de quedar fuera del ámbito de las pruebas, y esto se usará posteriormente en el plan de calidad del sistema. 1.6.7. Pruebas de Sistemas. Estas pruebas no entran en el ámbito del proceso de ingeniería del software y tampoco las realiza el desarrollador del software, al menos no de forma exclusiva. Los pasos adoptados durante el diseño y durante la prueba del software pueden mejorar bastante la probabilidad de éxito para integrar el software en el sistema. La prueba del sistema está formada por unas pruebas diferentes cuyo finalidad primordial es ejercitar el sistema software de forma meticulosa. Aunque cada prueba tenga su propio propósito, todas ellas intentan verificar que se integraron correctamente todos los elementos del sistema y que estos realizan las funciones apropiadas. Pruebas de Recuperación Muchos sistemas informáticos deben recuperarse de los fallos y continuar su ejecución en un tiempo establecido en las especificaciones. Hay casos de sistemas que han de ser tolerantes a los fallos (los fallos del proceso no deben hacer cesar el funcionamiento de todo el sistema). La prueba de recuperación se trata de una prueba del sistema que fuerza el fallo del software de formas muy variadas, verificando que la recuperación se realiza adecuadamente. Si la recuperación la lleva a caso el propio sistema (recuperación automática) hay que evaluar la corrección de los mecanismos de recuperación del estado del sistema, de la inicialización, de la recuperación de datos y del proceso de rearranque. Si la recuperación precisa la intervención humana, hay que evaluar los tiempos medios de reparación (TMR) para estudiar si son tiempos aceptables o no.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

Prueba de seguridad Cualquier sistema informático que trabaje con información sensible o ejecute acciones que puedan realizar un prejuicio/ beneficio impropio a ciertas personas es un posible objetivo para ataques y entradas impropias o no autorizadas al sistema. Este acceso no autorizado al sistema incluye piratas informáticos que tratan de entrar en los sistemas por reto personal, empleados disconformes con la empresa que intentan penetrar por venganza y personas que intentan penetrar para obtener beneficios que no les corresponden. La prueba de seguridad verificar que los mecanismos de protección incorporados en el sistema son lo suficientemente efectivos para protegerlo de accesos impropios. Pruebas de resistencia (stress) Durante los anteriores pasos de prueba las técnicas de caja blanca y de caja negra resultaban en la evaluación del funcionamiento y rendimiento normales del programa. Las pruebas de resistencia se enfocan en encarar al software con situaciones anormales. De esta forma quién realiza la prueba de resistencia ha de calcular la potencia a la que ha de ajustar el sistema antes de que éste falle. La prueba de resistencia ejecuta un sistema para que pida recursos en volumen, frecuencia o cantidad anormales. Una variante de esta prueba es la técnica conocida como prueba de sensibilidad. Pruebas de rendimiento Para sistemas de tiempo real y sistemas empotrados no se puede aceptar que el sistema ejecute las funciones requeridas pero no se ajuste a los requisitos relacionados con el rendimiento. La prueba de rendimiento se diseña para probar el rendimiento del software en tiempo real dentro del contexto que plantea un sistema integrado. La prueba de rendimiento se puede aplicar a todos los pasos del proceso de la prueba. En el nivel de unidad se prueba el rendimiento de los módulos individuales a medida que se ejecute en las pruebas de caja blanca. Pero hasta que no estén totalmente integrados los elementos del sistema no puede asegurarse realmente el rendimiento del sistema. Frecuentemente las pruebas de rendimiento están relacionadas con las pruebas de resistencia y también requieren instrumentación de software y de hardware. Así muchas veces es necesario medir el uso de recursos de forma exacta. La

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

RECUERDE Las pruebas del sistema van encaminadas a verificar el correcto funcionamiento del sistema ya montado.

instrumentación externa podrá monitorizar los sucesos ocurridos (tales como interrupciones), los intervalos de ejecución, y muestras de los estados de la máquina en un funcionamiento normal. Así se podrán detectar situaciones que lleven a degradaciones y posibles fallos del sistema. 1.6.8. Pruebas de componentes. La prueba de componente centra el proceso de pruebas en la menor unidad del diseño del software: el componente unitario software o módulo. Durante la prueba de unidad es necesaria la comprobación selectiva de los caminos de ejecución. Se diseñarán casos de prueba para la detección de errores debidos a cálculos y comparaciones incorrectas o flujos de control inapropiados. Las pruebas del camino básico y de bucles (anteriormente mencionadas) son técnicas muy usadas y muy efectivas para encontrar muchos errores en los caminos. Debido a que el componente no es un programa independiente por sí mismo se ha de desarrollar un software específico que lo controle para poder realizar la prueba. En la mayoría de las aplicaciones se usan controladores que acepten los datos del caso de prueba; un controlador es un programa principal, los pasa al módulo (para ser probado) e imprime los resultados más importantes. Los resguardos servirán para reemplazar los módulos subordinados al componente que se va a probar. Un resguardo, o subprograma simulado, usa la interfaz que pertenece al módulo subordinado, y lleva a cabo una manipulación de datos que es mínima, imprimiendo una verificación de entrada y devuelve el control al módulo de prueba que lo ha invocado. Los controladores y los resguardos representan más trabajo al ser un software que debe desarrollarse (aunque a esto normalmente no se aplica un diseño formal) pero que no se entregará con el producto de software final. Ha de entenderse como una mejora, y si los resguardos y controladores son sencillos el trabajo adicional es relativamente pequeño. Por desgracia muchos componentes no pueden tener una prueba unitaria adecuada con un software adicional que sea sencillo. En estos casos la prueba completa se pospone hasta llegar al paso de prueba de integración (donde también se pueden usar controladores o resguardos). La prueba de unidad se simplifica bastante cuando se diseña un módulo con un grado de cohesión alto. Cuando un módulo sólo realiza una función se reducirá

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

el número de casos de prueba y los errores serán predecibles, permitiendo descubrirlos más fácilmente.

RECUERDE

1.6.9. Automatización de pruebas. Herramientas.

Las pruebas de componentes van encaminadas a verificar el correcto funcionamiento de cada módulo por separado.

Resulta muy complicado poder ir en tiempo con las entregas y los cambios que van saliendo por parte del cliente. Para lograr una mejora en los tiempos dedicados a las pruebas, dependiendo de las características del sector y del sistema en sí, puede optarse por automatizar las pruebas funcionales y de regresión, para que estas pruebas se puedan ejecutar más rápidamente y de forma repetitiva/ iterativa. La automatización de prueba constituye una ventaja cuando el software se modifica constantemente ya que incluso las modificaciones menores pueden hacer que la funcionalidad ya desarrollada deje de funcionar. Debemos conocer una serie de definiciones sobre los procesos de automatización de las pruebas, como son: Un banco de pruebas para el software es un conjunto integrado de herramientas que darán soporte al proceso de pruebas. Además de los marcos de trabajo de las pruebas, un banco de trabajo puede incluir herramientas que simulen otras partes del sistema y generen datos de prueba de dicho sistema. Gestor de pruebas: Gestiona la ejecución de las pruebas automáticas del programa, manteniendo un registro de los datos de ellas, los resultados esperados y las facilidades probadas del programa. Generador de datos de prueba: Genera los datos de prueba para inyectar en el programa objeto de la prueba. Se obtiene seleccionando datos de una base de datos o usando patrones para generar datos de forma aleatoria. Oráculo: Predice resultados que se esperan para las pruebas. Podrán ser versiones previas del programa o sistemas de prototipos. Las pruebas conocidas como back-to-back implican ejecutar paralelamente el oráculo y el programa a probar; resaltándose las diferencias entre sus salidas. Comparador de ficheros: Compara los ficheros que contienen los resultados correspondientes a las salidas de las pruebas del programa con los resultados de pruebas previas, elaborando (de una forma más o menos estructurada) un informe con las diferencias entre ellos. Se usan en pruebas de regresión, comparando los resultados de ejecutar diferentes versiones. Generador de informes: Facilita informes y otras facilidades de generación para interpretar los resultados de las pruebas.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

RECUERDE Se deben elegir bien las herramientas de las pruebas para que constituyan una ayuda y no ralenticen este proceso.

Analizador dinámico: Añade código a un software para realizar un recuento del número de veces que se ha ejecutado cada sentencia. Después de las pruebas, se generará un perfil de ejecución que muestra las iteraciones de cada sentencia del programa. Simulador: Los hay de varios tipos, como son: • Los simuladores de la máquina objetivo, que simulan la máquina sobre la que se ejecutará el programa; • Los simuladores de interfaces de usuario, que están conducidos por scripts que simulan múltiples interacciones de usuarios simultáneamente. Para los grandes sistemas las herramientas de pruebas tienen que configurarse y adaptarse para el propio sistema que se prueba, de forma específica. 1.6.10. Estándares sobre pruebas de software. El objetivo de la norma ISO / IEC 29119 es dar una norma definitiva para las pruebas de software que defina el vocabulario, la documentación, los procesos, las técnicas y el modelo de evaluación para los procesos de pruebas de software. Esta norma se puede utilizar dentro de cualquier ciclo de vida de desarrollo de software. La norma se centra sobre un modelo de proceso que se basa en el riesgo en tres niveles de pruebas de software que dan la orientación sobre el desarrollo de las estrategias de pruebas organizativas, la gestión de proyectos de pruebas, incluido el diseño de las estrategias, las políticas de pruebas, y planes de pruebas del proyecto, el nivel vigilancia y control pruebas, y un proceso de prueba dinámica que servirá como guía para el análisis de pruebas y el diseño, así como la prueba del ambiente de configuración y mantenimiento, la ejecución de pruebas y la presentación de informes. Esta norma actualmente está siendo desarrollada, probada y revisada por diversos profesionales y académicos de todo el mundo. Este modelo incluye las siguientes normas relacionadas/ subordinadas: • BS 7925-1: este estándar recoge los conceptos y vocabularios usados en las pruebas de software. • BS-7925-2: describe las técnicas de diseño y medición para los casos de prueba, sobre la ejecución y análisis de resultados, características a determinar, comparar y mejorar la calidad del test.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

• BS-7925-2 y IEEE1008: se encargan de los procesos (a nivel de organización, proyecto y pruebas) • IEEE829: de encarga de estandarizar la documentación de las pruebas software, así especifica ocho etapas para la documentación: • Planificación de las pruebas; • Especificación del diseño de la prueba; • Especificación del procedimiento de prueba; • Reporta la evolución de los ciclos probados; • Realiza un registro de la prueba en sí; • Resume la prueba. 1.7. Calidad del software. La calidad es un aspecto actualmente muy valorado. El interés por la calidad crece continuamente según los clientes se vuelven más selectivos y rechazar productos poco fiables o que piensan que pueden no dar respuesta a sus necesidades. Cabe preguntarse: ¿qué es la calidad del software? La Calidad del Software es la concordancia del software con los requisitos funcionales y de rendimiento que se han establecido, así como con los estándares de desarrollo previamente documentados y también con las características implícitas que se esperan del software desarrollado por profesionales. La Calidad del Software es una disciplina dentro de la Ingeniería del Software. La principal herramienta para garantizar la calidad de las aplicaciones es el Plan de Calidad, que se basa en normas o estándares genéricos así como en procedimientos particulares. Estos procedimientos pueden variar en cada empresa, pero lo importante es que estén escritos y adaptados a los procesos de la empresa y sobre todo que se sean cumplidos. Teniendo en cuenta esta definición, se puede decir que los requisitos del software serán la base de las medidas de calidad y que la no concordancia con los requisitos es una falta de calidad del software. Los estándares (o metodologías) marcan el conjunto de criterios de desarrollo que guían cómo se aplica la Ingeniería del Software. Si no se sigue metodología

RECUERDE Utilizar estándares sobre las documentaciones y pruebas ayudará a mantener el proceso bajo control, y también dará prestigio a la organización si se consigue certificar en estos estándares.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

RECUERDE

siempre habrá una falta de calidad. Todas las metodologías y las herramientas usadas tienen como único fin producir software de gran calidad.

La calidad del software se centra en que el sistema cubra los requisitos del cliente, así como el rendimiento solicitado para el software.

Se debe diferenciar entre la calidad del Producto de Software y la calidad del Proceso de Desarrollo. Así las metas que se establezcan para la calidad del producto determinarán las metas a establecer para cumplir la calidad del proceso de desarrollo, ya que la calidad del producto irá en función de la calidad del proceso de desarrollo. Sin un buen proceso de desarrollo es prácticamente imposible obtener un buen producto. 1.7.1. Principios de calidad del software. Algunos desarrolladores de software continúan creyendo que la calidad del software es algo en lo que empiezan a preocuparse una vez que se ha generado el código. La garantía de calidad del software es una actividad de protección que se aplica a lo largo de todo el proceso del software. La Calidad del Software engloba: • un enfoque de gestión de calidad; • tecnología efectiva de ingeniería del software (métodos y herramientas); • un procedimiento adecuado para el aseguramiento a los estándares de desarrollo del software (cuando sea posible), • un control de la documentación del software así como de los cambios realizados; • revisiones técnicas formales a aplicar durante el proceso del software; • una estrategia de prueba multi-escalada; • mecanismos de medición y de generación de informes. Con Calidad se puede entender una característica (atributo) de algo. Como un atributo, la calidad se referirá a las características medibles (atributos que se puedan comparar con estándares conocidos como longitud, color, propiedades eléctricas, etc.). Sin embargo, el software en conjunto, como entidad intelectual, es más difícilmente caracterizable que los objetos físicos. En relación al software hay una serie de medidas características de un programa. Entre estas propiedades se incluyen complejidad ciclomática, cohesión, número de puntos de función, líneas de código y muchas otras.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

Al examinar un elemento según sus características medibles, podemos diferenciar entre dos tipos de calidad: calidad del diseño y calidad de concordancia. • La calidad de diseño hace referencia a las características que especifican los ingenieros de software para cada elemento. A la calidad del diseño contribuyen el grado de materiales, tolerancias y las especificaciones. Al usar materiales de alto grado y especificar tolerancias más estrictas y niveles de rendimiento más altos, aumentará la calidad de diseño de un producto, si el producto está siendo fabricado conforme con las especificaciones. • La calidad de concordancia es el grado de cumplimiento de las especificaciones de diseño durante su ejecución. Cuanto mayor sea el grado de cumplimento, mayor será el grado de calidad de concordancia. En el desarrollo del software, la calidad de diseño comprende los requisitos, especificaciones y el diseño del sistema. La calidad de concordancia es un aspecto centrado principalmente en la implementación. Si la implementación sigue el diseño, y el sistema resultante cumple los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta. El control de calidad comprende inspecciones, revisiones y pruebas usadas durante el proceso del desarrollo del software para asegurar que cada producto cumpla con los requisitos se le asignados. Este proceso de control de calidad incluye una realimentación (feedback) cíclica del proceso que creó el producto. La combinación de realimentación y medición permite afinar el proceso cuando sus productos fallen al cumplir sus especificaciones. Así el control de calidad es una fase del proceso de fabricación. La garantía de calidad consiste en la auditoria y funciones de información de la gestión. El objetivo de la garantía de calidad es facilitar la gestión para informar de los datos requeridos sobre la calidad del producto, por lo que se adquiere una visión más profunda y segura de que se cumplen los objetivos la calidad del producto. Por supuesto, si los datos facilitados por la garantía de calidad identifican problemas, será responsabilidad de la gestión el afrontar dichos problemas y aplicar los recursos necesarios para resolver estos aspectos de calidad. El coste derivado de la calidad incluye los costes derivados de la búsqueda de la calidad y del resto de actividades relacionadas con su obtención. Se realizan estudios sobre el coste de calidad para dar una línea base del coste actual de calidad y así identificar las oportunidades de reducir dicho coste, así como para proporcionar una base de comparación normalizada. Y es que la normalización

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

RECUERDE La calidad de un producto software se basa en buena medida en la calidad relativa a cada aspecto del mismo.

tiene siempre un precio. Finalmente, tras normalizarse los costes de calidad sobre un precio base, tenemos los datos precisos para poder evaluar el lugar en donde se pueden mejorar los procesos del sistema. Es más, se podrá evaluar cómo afectan los cambios, en términos de dinero. Los costes de calidad se dividen en costes asociados con prevención, con evaluación y con los fallos. Entre los costes de prevención se incluyen: • revisiones técnicas formales, • equipo de pruebas, • planificación de la calidad, • formación. Entre los costes de evaluación serian los generados de realizar la verificación de la conformidad del proceso de producción (revisión de mantenimientos, gastos de inspección de compras,…). Los costes de fallos no existirían de no surgir defectos antes del envío del producto a los clientes. Estos costes se subdividen en costes de fallos internos y externos. • Los internos se producen al detectarse un error en el producto antes de su envío. • Los externos son los asociados a los defectos encontrados una vez enviado el producto al cliente. Así los costes relativos a encontrar y reparar un defecto aumentan según se cambia desde el fallo interno al externo y desde prevención a detección. Actualmente los responsables expertos de compañías de todo el mundo reconocen que el seguimiento de una alta calidad del producto a la vez se traduce en ahorro de coste y en una mejora del producto en general. Como ocurre con las pruebas, lo mejor en muchas ocasiones (cuando así lo permita el presupuesto) es que haya un equipo independiente de calidad de software. De existir dicho equipo (SQA) tendrá las siguientes actividades asignadas:

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

• Establecimiento del plan de SQA para el proyecto. El plan se establecerá en la planificación del proyecto y se revisará por las partes interesadas de la organización y cliente. Este plan guía las actividades de garantía de calidad que realice el equipo de ingeniería del software y el grupo SQA. Dicho plan identifica: • auditorías y revisiones a realizar, • errores, • procedimientos para información y seguimiento de documentos producidos por el grupo SQA, • evaluaciones a realizar, • estándares que se pueden aplicar al proyecto, • realimentación de información proporcionada al equipo de proyecto del software. • Participación en la descripción inicial del proceso de software del proyecto. El equipo de ingeniería del software procederá a seleccionar un proceso para el trabajo que va a realizar, mientras que el grupo de calidad de software revisará la descripción dicho proceso para ajustarse a los estándares internos del software, los estándares impuestos externamente (por ejemplo: 1SO 9001), a la política de la empresa y a otras partes del plan de proyecto del software. • Revisión de las actividades de ingeniería del software para poder verificar su ajuste al proceso de software inicialmente definido. El grupo de calidad de software identifica, estudia y documenta la pista de las desviaciones del proceso, verificando que se hicieron las correcciones. • Auditoria de los productos de software para verificar su ajuste con los productos inicialmente definidos como parte del proceso del software. El grupo de calidad de software revisará los productos seleccionados; identifica, estudia y documenta la pista de las desviaciones; verifica que se hicieron las correcciones, y procede a informar periódicamente de los resultados de su trabajo al director del proyecto. • Asegurar que las desviaciones del producto de software y el trabajo se documentan y se gestionan de acuerdo con un procedimiento establecido.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

RECUERDE Para proyectos de cierta envergadura es conveniente contar con un equipo de calidad independiente, que también interactúe con el resto de equipos.

Las desviaciones pueden encontrarse en el plan del proyecto, en los estándares aplicables, en la descripción del proceso o en los productos técnicos. • Registro de lo que no se ajuste a los requisitos e informe a sus superiores. Los elementos que no se ajusten a los requisitos serán seguidos hasta que se ajusten. Además de todo lo anterior, el grupo de calidad de software mantiene la coordinación del control y de la gestión de cambios, ayudando también a recopilar y a analizar las métricas del software. 1.7.2. Métricas y calidad del software. Aunque hay muchas medidas relacionadas con la calidad de software, la corrección, integridad y facilidad de uso, facilidad de mantenimiento, serán indicadores útiles como referencia para el equipo del proyecto. Conviene conocer las siguientes definiciones y medidas para cada uno de ellos, así: Corrección: A los programas le corresponde operar correctamente, en caso contrario darán poco valor a sus usuarios. La corrección se refiere al grado en el que el software realice una función determinada. La medida más común de corrección es aquella en la que un defecto se define como un fallo verificado de conformidad con los requisitos establecidos. Facilidad de mantenimiento: El mantenimiento del software ocupa más recursos que cualquier otra actividad de ingeniería del software. La facilidad de mantenimiento es la sencillez con la que se puede corregir un programa si se encuentra un error, éste se puede adaptar si el entorno cambia u optimizar si el cliente desea cambiar los requisitos. No hay forma de medir con precisión la facilidad de mantenimiento al comienzo; para esto se deben usar medidas indirectas. Una métrica orientada al tiempo simple es el tiempo medio de cambio, es decir, el tiempo que se emplea en analizar una petición de cambio, luego diseñar una modificación apropiada, efectuar el cambio, probarlo y finalmente distribuir el cambio a todos los usuarios. Como media los programas más sencillos de mantener tendrán un índice más bajo que los que sean más difíciles de mantener. Integridad: En esta época de ataques cibernéticos, ataques informáticos en general y de virus, la integridad del software se ha considerado un tema de mucha importancia. Este atributo mide la capacidad de un sistema para soportar estos ataques no deseados contra su seguridad (que pueden ser accidentales o intencionados). Estos ataques se pueden dar en cualquiera de los tres componentes del software: bien en los programas, documentos o en los datos.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

Para medir la integridad, se deben definir dos atributos más: amenaza y seguridad. La amenaza es la probabilidad (que se puede estimar de forma teórica o empírica) de que un ataque de un determinado tipo ocurra en un cierto tiempo. La seguridad es la probabilidad (que se puede estimar de forma teórica o empírica) de que se podrán contra-atacar y repeler los ataques de un determinado tipo. La integridad del sistema se puede determinar como: • integridad = Ó[1 amenaza x (1 seguridad)] ecuación en la que se suman la amenaza y la seguridad para cada tipo de ataque. Facilidad de uso: Si un programa no resulta amigable con el usuario este está (salvo en contadas excepciones) próximo al fracaso, incluso aunque realice funciones. La facilidad de uso es un intento de calcular lo amigable que puede ser el sistema para un usuario, y se intenta medir en función de estas cuatro características: • el tiempo necesario para ser medianamente eficiente en el uso del sistema; • destreza física y/o intelectual necesaria para aprender el sistema; • valoración subjetiva (se puede obtener mediante un cuestionario) de la opinión de los usuarios hacia propio el sistema; • el aumento neto en productividad (con respecto al sistema que reemplaza) medida cuando alguien usa el sistema mediana y eficazmente. Los cuatro factores anteriores son ejemplos de todos los que se han propuesto como medidas destinadas a medir la bondad del software. 1.7.3. Concepto de métrica y su importancia en la medición de la calidad Es necesario empezar con unas definiciones relacionadas con la métrica: • Medida: dota de una indicación cuantitativa de las dimensiones, cantidad o tamaño de algunos atributos del producto. • Medición: acto de calcular una medida.

RECUERDE Hay numerosos criterios medibles que nos permiten conocer el grado de calidad del producto desarrollado, no sólo basado en criterios puramente funcionales, sino también otros como por ejemplo la seguridad, mantenimiento e integridad.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

RECUERDE Las métricas son necesarias para poder tener una idea de la calidad asociada a cada aspecto del programa. Sin métricas no hay una valoración objetiva.

• Métrica: forma del grado en que un componente, sistema o proceso posee un cierto atributo. Las métricas de software incluyen un amplio rango de actividades, de entre las que destacan: • Modelos de fiabilidad; • Modelos y evaluación de ejecución; • Aseguramiento y control de calidad; • Modelos y medidas de productividad. Las métricas de software se pueden clasificar según los siguientes criterios: • De calidad: métricas que definen la calidad del propio software: exactitud, estructuración (modularidad), pruebas, mantenimiento. • De complejidad: métricas que van a definir la medida de la complejidad: tamaño, anidaciones, volumen y configuración. • De desempeño: métricas que miden el comportamiento de módulos y sistemas de un software que se encuentra bajo la supervisión del hardware o del sistema operativo. • De competencia: métricas que tratan de valorar o medir la productividad de los trabajadores en las actividades, con respecto a su rapidez, rapidez, eficiencia, eficacia y competencia. • Estilizadas: métricas de preferencia y experimentación: estilo de código, limitaciones, convenciones, etc.

1.7.4. Principales métricas en las fases del ciclo de vida software. Para aplicar el proceso de calidad al ciclo de vida se precisa la utilización de métricas que sean adecuadas para poder la calidad del proyecto. Se va a comparar los parámetros de calidad del sistema con estimaciones realizadas por medio del uso de estándares o de datos que aporte la experiencia en proyectos previos. Es preciso usar las métricas que sean más adecuadas para poder realizar un seguimiento, control y mejora de la calidad, y para esto se necesita los factores de calidad más importantes para el proyecto.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

Cuando el cliente nos da un documento de especificaciones de requisitos del software se debe proceder a cuantificar la complejidad y tamaño de lo que nos están pidiendo para poder ajustar un presupuesto. La técnica más usada para estimar el tamaño es la técnica del punto función, que trata de enumerar las consultas, informes, datos, etc. que serán necesarios para conseguir el producto terminado. Las fases del ciclo de vida software, como ya hemos visto antes, son: • Especificación de requisitos software: donde definimos qué hacer; • Diseño del sistema: donde definimos cómo cumplir los requisitos; • Construcción del sistema: donde desarrollamos el código del sistema; • Pruebas: donde se realizan las pruebas sobre el código/ programa desarrollado; • Validación: entrega al cliente, estimaciones finales y mantenimiento. Las métricas nos permiten conocer cosas tales como la importancia o el número de los errores detectados en los tests o que se corresponden a las reclamaciones recibidas del cliente. Se pueden hacer pruebas durante todas las fases del ciclo de vida, si bien serán las propias características del producto las que marquen cuántas pruebas hacer y dónde (en qué fase) centrarlas. Si en cada proyecto medimos el grado de error con el tiempo al final obtendremos un histórico que nos indicará si estamos mejorando o no. También nos va a servir para realizar predicciones sobre cómo evoluciona el volumen de errores y tiempo de corrección; estos datos nos serán de utilidad en nuevos proyectos antes de la fase de pruebas. En resumen, la información recopilada de cada proyecto nos servirá para otros futuros. 1.7.5. Estándares para la descripción de los factores de Calidad. Se reconoce que un se conseguirá un nivel de calidad del producto como consecuencia de seguir unos procesos operativos que estén suficientemente. Luego, al normalizar todos los procesos que influyen en ella se podrá estar más seguro de que se han respetado durante toda esa secuencia productiva, sin ser necesario realizar un control de la calidad del producto obtenido para poder asegurar su conformidad. Un proceso normalizado se transforma en un procedimiento, debiendo vigilarse su cumplimiento por parte de los auditores de calidad. Esta será la única forma

RECUERDE Tras realizar las estimaciones usando las métricas se debe comparar con los criterios establecidos en las especificaciones del sistema y así obtener un grado de cumplimiento.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

RECUERDE Al igual que con las pruebas, el uso de estándares nos permite tener controlado el estado de la calidad del software.

de poder predecir la calidad del servicio o producto, y en consecuencia su coste de producción. A continuación se debe documentar todo lo acontecido en el Sistema de Aseguramiento de Calidad y de Procedimientos. Este sistema ha de realizarse de acuerdo con determinados referentes, como ISO 9000, para que pueda ser certificada la empresa por la entidad certificadora. Para una empresa contar con certificaciones de calidad supone que muchos clientes se fijen en ella frente a sus competidores, ya que tener una certificación asegura que en esa empresa se cumplen las pautas marcadas en la norma certificada. 1.7.6. ISO9126. El estándar ISO 9126 se desarrolló en un intento de unificar y estandarizar los atributos clave de calidad para el software. El estándar refleja los siguientes atributos clave respecto a la calidad: • Funcionalidad: define el grado de satisfacción por parte del software satisface sobre las necesidades indicadas por los siguientes sub-atributos: corrección, conformidad, idoneidad, interoperabilidad, y seguridad. • Eficiencia: define el grado en que el software optimiza el uso de los recursos del sistema. Se refleja por los siguientes sub-atributos: tiempo de uso y recursos usados. • Usabilidad: grado en que el software es de uso sencillo.Viene determinado por los siguientes sub-atributos: facilidad de aprendizaje, facilidad de comprensión y operatividad.

RECUERDE Centrado en los aspectos más importantes del sistema, ISO 9126 estandariza los aspectos claves para medir la calidad del programa.

• Confiabilidad: cantidad de tiempo que el software estará disponible para su uso. Está marcado por los siguientes sub-atributos: tolerancia a fallos, facilidad de recuperación y madurez. • Portabilidad: la facilidad con que el software puede transportarse de un entorno a otro. Se determina por los siguientes sub-atributos: facilidad de instalación, facilidad de adaptación al cambio, facilidad de ajuste. • Facilidad de mantenimiento: se refiere a la facilidad con que se puede realizar una modificación. Está referida por los siguientes sub-atributos: facilidad de análisis, facilidad de cambio, facilidad de prueba y estabilidad.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

1.7.7. Otros estándares. Comparativa. Los definidos por el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE): • IEEE 730 – 2002: Standard for Software Quality Assurance Plans. Define la información que debe incluir un plan de aseguramiento de la calidad software, y su propia relación con el resto procesos implicados (gestión de incidencias, gestión de la configuración). • IEEE 829 – 1998: Standard for Software Test Documentation. Define la documentación que debe generarse en cada una de las fases del proyecto de pruebas. • IEEE 830 – 1998: Recommended Practice for Software Requirements Specifications. Proporciona una guía de buenas prácticas para elaborar una especificación de requisitos. • IEEE 1012 – 2004: Standard for Software Verification and Validation. Detalla los procesos de verificación y validación (V&V) del software, así como su organización. • IEEE 1061 – 1998: Standard for a Software Quality Metrics Methodology. Define el establecimiento, el desarrollo, el análisis y la validación de las métricas de calidad de software. Los definidos por la Organización Internacional para la Estandarización (ISO): • En especial cabe destacar la norma ISO 9001:2000 que especifica los requisitos para un sistema de gestión de la calidad, en concreto: • ISO 9001: este es un estándar que describe el sistema de calidad que debe usarse para mantener el desarrollo de un producto que también implique diseño. • ISO 9000-3: este es un documento específico que interpretará el ISO 9001 para el desarrollo de software. • ISO 9004-2: este documento dota de las directrices para las facilidades del software, tales como soporte de usuarios. Los requisitos se agrupan bajo 20 títulos: • Control de diseño;

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

• Control de producto no aceptado; • Control de documentación; • Responsabilidad de la gestión; • Sistema de calidad; • Inspección y estado de pruebas; • Inspección, medición y equipo de pruebas; • Revisión de contrato; • Acción correctiva; • Tratamiento, almacenamiento, empaquetamiento y entrega; • Compras; • Inspección y estado de pruebas; • Identificación y posibilidad de seguimiento del producto; • Auditorías internas de calidad; • Formación; • Control del proceso;

RECUERDE Existen numerosos estándares de calidad del software, el uso de uno u otro no es tan importante como la propia decisión de estandarizar los procesos de calidad.

• Servicios; • Técnicas estadísticas; • Producto proporcionado al comprador; • Registros de calidad. Y también el estándar ISO 9126, que ya estudiamos en el capítulo anterior.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

1.8. Herramientas de uso común para el desarrollo de software ENTORNOS DE DESARROLLO SOFTWARE. La palabra entorno designa el contexto en el que se efectúa una determinada actividad, y en particular se utiliza para definir la combinación de instrumentos disponibles para tal efecto. Un entorno de desarrollo software es un conjunto de los elementos disponibles para realizar este desarrollo, haciendo especial hincapié en los instrumentos informáticos que faciliten esta labor. Las técnicas de soporte informático para el desarrollo del software se referencian habitualmente con las siglas CASE. SOPORTE DE LAS FASES DE DESARROLLO. El entorno de programación clásico gira en torno a un compilador al que se añaden un editor de textos y también un montador de enlaces. Una posición alternativa se constituye con los intérpretes de lenguaje, que van a combinar en una misma herramienta las funciones de edición y ejecución del software. La aparición de metodologías específicas para el análisis y el diseño da lugar a la progresiva aparición de herramientas para dar soporte de las mismas. Para la fase de pruebas e integración se dispondrá de herramientas de ensayo. Para la fase de mantenimiento se dispondrá de soporte de gestión de la configuración el cual habitualmente también se aplica a las fases anteriores de codificación, pruebas e integración. Este soporte incluirá la gestión de versiones y el control de cambios del software. FORMAS DE ORGANIZACIÓN. Un entorno de desarrollo de software suele estar constituido de una combinación de elementos que automatizan una serie de funciones. El entorno en su conjunto puede organizarse de diferentes maneras. Se pueden combinar varias herramientas distintas en forma de cadena, haciendo que la salida de una herramienta sea la entrada de otra. También se puede realizar contando con un almacén común de información, llamado repositorio, donde se guarda la información en un formato común a todas las herramientas. Las herramientas CASE de análisis y diseño están organizadas así. Finalmente también se puede hablar de entornos que se organizan como una única herramienta global que es capaz de realizar todas las funciones necesarias.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

OBJETIVO DE UN ENTORNO DE DESARROLLO. Los entornos de desarrollo tienen diversas metas, como pueden ser:

RECUERDE Hay numerosos tipos de herramientas para el desarrollo de software. Se deben conocer sus funcionalidades para decidir cuál/ cuales serán las que más se ajusten a nuestras necesidades.

• Quizás el objetivo más básico y fundamental de estas herramientas es dar soporte a la programación en un lenguaje concreto. • Otro objetivo es dar soporte a una cierta metodología de desarrollo independiente del lenguaje de programación. • También hay entornos de trabajo centrados en la planificación y en el control del proceso de desarrollo. • Otro objetivo será ayudar al desarrollo de los mismos entornos de desarrollo. Así tenemos los meta-entornos, que van a permitir la construcción de entornos o herramientas destinados a dar soporte a una cierta metodología o a un cierto lenguaje. 1.8.1. Editores orientados a lenguajes de programación. Un editor de programación es un programa que incluye un entorno de trabajo integrado, es decir, que contará con: • interfaz grafica, • compiladores, • funciones de depuración, • ayuda, etc.

RECUERDE La integración de herramientas para la elaboración de software ahorra tiempo y problemas de compatibilidades entre los programas que se usen.

Estos editores usan librerías previamente definidas y se van a enfocar en ciertos lenguajes de programación (como son c++, visual studio, Java, pascal, Net Framework) y cuyo fin es el de asistir al programador para la elaboración de un software propio. Existen multitud de editores, si bien podría usarse un editor de texto para la redacción del código de programación, pero actualmente hay editores muy complejos y útiles que asisten al programador indicándole en cada momento los errores de sintaxis, que incluyen ayuda, sugerencias, entradas válidas, así como los compiladores y depuradores necesarios.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

1.8.2. Compiladores y enlazadores. Para obtener un programa ejecutable se deben seguir los siguientes pasos: El primero es compilar o traducir el código fuente a su código objeto equivalente (en el lenguaje de programación que se esté usando). Este trabajo lo realizan los compiladores y consiste en obtener el fichero equivalente a nuestro programa fuente de forma que sea utilizable para el ordenador; este fichero es lo que se conoce como fichero objeto, y su contenido es el código objeto. Los compiladores actúan como programas traductores que leen un fichero de texto donde se contiene el programa fuente y que generan un fichero que va a contener el código objeto. El código objeto es diferente para cada ordenador y para cada sistema operativo. Por lo tanto existen diversos compiladores para los diferentes sistemas operativos y para cada tipo de ordenador. El enlazador o linker partiendo de todos los ficheros objeto que componen el programa, los combina con los ficheros de biblioteca que sean necesarios y crea un fichero ejecutable. Una vez terminada la fase de enlazado, ya podemos ejecutar nuestro programa. 1.8.3. Generadores de programas. La programación automática trata de que sea el propio ordenador o un software auxiliar el que escriba los programas que necesitan las personas, siguiendo las indicaciones introducidas. Desde que existen los ordenadores, los programadores han tratado de que su trabajo sea lo más sencillo y diligente posible. Para ello han inventado y desarrollado diferentes técnicas y multitud de programas para tratar de resolver los diferentes tipos de problemas que se les presentan tanto a ellos mismos como a otras personas para que con ayuda de ordenadores hacer que sus trabajos sean más efectivos o rentables, o que se puedan solucionar con mayor facilidad y efectividad. Existen muchos ejemplos de programas que a su vez escriben otros programas, por ejemplo, los traductores de lenguajes que toman como origen un programa fuente escrito por el programador y producen como salida un programa que pueda ejecutarse, es decir que producen un ejecutable.

RECUERDE El compilador traduce el código en lenguaje de alto nivel a lenguaje de bajo nivel. El enlazador combina los ficheros necesarios y referenciados en el código para crear un fichero ejecutable.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

RECUERDE La programación automática puede ayudarnos para elaborar ciertas funciones básicas de forma más rápida, si bien aun no se ha logrado aplicar para programas de complejidad media o alta.

En cambio cuando se habla de programación automática los objetivos suelen ser más ambiciosos y eso ya no es algo fácil de conseguir. Una de las principales dificultades es que los programas generados por los ordenadores son muy largos y difíciles de comprender. No siendo tan sencillos como los programas escritos por personas y, en general, contienen muchas instrucciones e iteraciones repetidas. En la actualidad se están realizando esfuerzos en conseguir que el ordenador ayude en la construcción de programas. Algunas empresas invierten muchos recursos materiales y humanos para conseguir avanzar en la investigación que conlleve el logro de estos objetivos. 1.8.4. Depuradores.

RECUERDE Los depuradores son los encargados de identificar y eliminar errores del código software.

La función del depurador es probar e identificar, así como eliminar errores en el software. Dentro de los depuradores encontramos: • Depurador absoluto. Realiza una ejecución controlada del programa. Resulta incomodo de usar, ya que hace referencia a registros del procesador y a posiciones de memoria. • Depurador simbólico. Realiza una función similar al anterior, pero haciendo referencia al código fuente, por lo que será más cómodo de usar.

RECUERDE Las herramientas automáticas de pruebas son muy útiles para agilizar el proceso de las pruebas, si bien en muchos ambientes (software crítico) no se pueden ni deben usar.

1.8.5. De prueba y validación de software. El uso de herramientas automatizadas para las pruebas de software es algo que se lleva investigando y usando desde hace tiempo, debido a la gran cantidad de recursos necesarios para la elaboración y testeo de las pruebas de software. Las herramientas automatizadas de pruebas software ahorran mucho dinero y tiempo. Por un lado se ahorra pagar a un probador durante un proceso más largo de pruebas, lo que supone un ahorro en recursos considerable, y por otro lado se ahorra un tiempo que ayuda a cumplir más fácilmente los hitos de entrega. Pese a la bondad teórica de estas herramientas, ocurre como con los generadores automáticos de código, y es que en muchos ambientes (como en el software crítico como puede ser el de los sistemas de control de tráfico aéreo, medicina, militares,…) las pruebas son un proceso delicado que no deben dejar cabida a error, por lo que el uso de estas herramientas se elimina o se relega a acelerar ciertos procesos sencillos de prueba.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

1.8.6. Optimizadores de código.

RECUERDE

Los optimizadores de código son programas que tratan de convertir programas o código existentes en otros programas (o códigos) que realicen las mismas tareas en un tiempo menor, y con menos recursos de memoria, o usando óptimamente. La optimización puede tener sentido a distintos niveles: desde los niveles más bajos (escritura de código máquina diseñado para la arquitectura, desarrollo de circuitos), hasta los niveles más altos de implementación o elaboración, diseño o uso de algoritmos. Suele recomendarse dejar la optimización para el final del proceso de desarrollo, ya que una prematura optimización puede introducir nuevos errores (que generalmente son más difíciles de detectar por ser de tipo algorítmico).

Los optimizadores de código nos permiten reutilizar códigos de software anteriormente creados para ser incluidos en el código de un nuevo software.

1.8.7. Empaquetadores. Los empaquetadores son programas que crean un solo ejecutable (en la mayoría de los casos), cuya ejecución permitirá instalar adecuadamente el programa, con todas las funciones asociadas requeridas (crear carpetas, agregar claves al registro, descomprimir ficheros). En muchos casos los instaladores tendrán su propia interfaz gráfica para realizar el proceso de instalación de forma guiada y permitir introducir personalizaciones en la instalación. 1.8.8. Generadores de documentación de software. Un generador de documentación es una herramienta de programación que se usa para generar la documentación destinada a los programadores (documentación de API), a usuarios finales, o para ambos, partiendo de un código fuente especialmente documentado, y en algunos casos archivos binarios. Pueden ser: • Documentos batch (documentos automatizados) • Documentos interactivos (no pueden producirse automáticamente) • Formularios (para páginas web)

RECUERDE El empaquetador crea un único archivo que realizará todas las funciones de instalación del programa al ser ejecutado.

RECUERDE Hay herramientas para generar automáticamente cierto tipo de documentación. Estas herramientas solo serán útiles para ciertas documentaciones; para las documentaciones importantes del sistema sigue siendo necesario tener a personal especializado para su generación.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

RECUERDE Las herramientas automáticas de pruebas son muy útiles para agilizar el proceso de las pruebas, si bien en muchos ambientes (software crítico) no se pueden ni deben usar.

1.8.9. Gestores y repositorios de paquetes.Versionado y control de dependencias. Un repositorio es un lugar en la red donde se almacenan paquetes para una distribución de un programa/ sistema operativo, se organizan, catalogan y almacenan para facilitar su distribución e uso. La función de los repositorios es hacer disponible el software sin tener que preocuparse de su búsqueda, de la versión ni de conflictos que pueda haber entre programas, etc. El repositorio es el primer lugar donde se acude para instalar un programa que, de estar en dicho repositorio solo se tiene que solicitar que se instale el paquete. No hará necesario el uso de versiones, números de licencia, claves, abstrayendo al usuario de los detalles en el proceso de actualización. Se puede decir que los repositorios son webs que contienen muchos paquetes o programas, constando de principalmente dos partes: • Una de ellas es la parte “dist” y esta parte contiene sub-secciones que dan amparo a las ediciones varias de una distribución. • Y la otra parte los “pools” que utilizan la misma estructura que usa “dist” y contiene los paquetes convenientemente ordenados. Estos repositorios cuentan con un directorio (que normalmente se compone de tres archivos) que indexa los datos de cada paquete y la versión del mismo, dato que se encuentra en dicha web.

RECUERDE Los repositorios son contenedores de los archivos necesarios para realizar actualizaciones/ ampliaciones del software.

Para instalar un programa de los contenidos en el repositorio de distribución se debe usar la herramienta de paquetes software y solicitar su instalación. La herramienta encontrará por si misma el repositorio mas conveniente (normalmente por criterio de cercanía), descargará el paquete así como todos los demás paquetes que se requieran para que el programa funcione o las llamadas “dependencias”, lo descomprimirá, instalará y finalmente lo configurará. Para agregar un programa a un repositorio, el sistema tendrá un listado de los paquetes contenidos en esa web y nos permite visualizarla desde el Gestor de Paquetes para descargarlos, automatizando las dependencias, es decir, que basta con marcar un paquete para su descarga, que el sistema se encargue de analizar si ya se cuenta con todas las dependencias instaladas. De ser necesario el sistema incluirá automáticamente las dependencias para su descarga.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

1.8.10. De distribución de software. Una distribución de software es un compilado de software específico (o una colección múltiple de software, incluso el sistema operativo), ya compilado y correctamente configurado. Generalmente las distribuciones pueden tomar formas de licencia, pero también puede tomar la forma de una distribución binaria, un instalador (.exe) que se puede descargar desde Internet.

RECUERDE Una distribución de software es el conjunto de paquetes entregables.

Existen herramientas para ayudar a la creación de paquetes de código fuente que pueda ser portable a varios sistemas, por ejemplo el GNU Build System, que se usa para el desarrollo de software libre. 1.8.11. Gestores de actualización de software. Un gestor de actualizaciones mantiene un registro de la versión instalada del programa y, de forma automática, rastreará el repositorio oficial del programa para comprobar la existencia de nuevas versiones y, en caso de que existan, proceder a su actualización. Normalmente esto se realiza teniendo en cuenta permisos definidos por el usuario para su actualización automática, manual, etc. De no existir estos gestores, cada usuario debería conocer la versión que tiene instalada de cada programa y buscar el repositorio de cada uno de ellos para comprobar la existencia de nuevas versiones y, en su caso, proceder a su actualización. 1.8.12. De control de versiones. Control de versiones se refiere a la gestión de los cambios que se realizan sobre los elementos de un producto o una configuración del mismo. Una versión, edición o revisión de un producto es el estado en que se encuentra ese producto en un momento dado de su desarrollo o modificación. Aunque el control de versiones puede realizarse manualmente, es aconsejable disponer de las herramientas que faciliten esta gestión de forma automática, dando lugar a los llamados sistemas de control de versiones. Estos sistemas facilitan tanto la administración de las diferentes versiones de cada producto, así como las posibles especializaciones realizadas (por ejemplo, para algún cliente en concreto). El fin del uso del control de versiones es el control de las distintas versiones del código fuente que dará lugar a los sistemas de control de código fuente.

RECUERDE Los gestores de actualizaciones de software abstraen al usuario del proceso de control de versiones, evitando incoherencias.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

Los programas usados para el control de versiones son un tipo de aplicaciones originalmente pensadas para gestionar de forma ágil los cambios en el código fuente de los programas así y poder revertirlos en caso necesario, así su ámbito ha sido ampliado pasando del concepto Control de versiones al de Gestión de Configuraciones, que engloba todas las actividades que se podrán realizar por un equipo sobre un gran proyecto software u otra actividad que genera ficheros digitales. Actualmente hay dos modelos para el control de versiones, que son:

RECUERDE El control de versiones se realiza para conocer qué cambios diferencian una versión de sus predecesoras y sucesoras.

• Modelo cliente/ servidor: Con la llegada de las redes los desarrolladores usan un repositorio centralizado al que se accede mediante un cliente en su equipo. Con el uso de las redes públicas hay que distinguir entre programas abiertos (con su código fuente disponible) y propietarios (comerciales, cuyo código no está disponible de forma abierta). • Modelo distribuido: En este modelo cada desarrollador trabaja directamente con su repositorio local, y los cambios se comparten posteriormente entre los distintos repositorios. 1.8.13. Entornos integrados de desarrollo (IDE) de uso común. Un entorno de desarrollo integrado (IDE) (también conocido por los nombres de entorno de depuración integrado, entorno integrado de diseño o entorno de desarrollo interactivo) es una aplicación de software que da servicios integrales a los programadores para el desarrollo de software. Un IDE se compone normalmente de: • Un editor de código fuente: es un editor de texto del programa que fue diseñado específicamente para la edición del código fuente de programas por parte de los programadores. Puede ser una aplicación independiente y normalmente suele estar integrado en el IDE. Los editores de código fuente tienen unas características diseñadas específicamente para acelerar y simplificar la entrada de código fuente, como el auto-completado, el resaltado de sintaxis y el soporte de la funcionalidad de juego. Estos editores también incluyen una forma eficaz para ejecutar un intérprete, depurador, compilador, u otro programa que sea relevante para el desarrollo de software. De esta forma, mientras muchos editores de texto se pueden usar para editar código fuente, hay otras posibilidades menos complejas pero sin la posibilidad de automatización y sin la facilidad de la edición de código, por lo que no son editores de código fuente en sí, sino simplemente serán editores de texto que se puede utilizar para editar código fuente (como puede ser el notepad).

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

Los editores de código fuente pueden comprobar la sintaxis mientras se programa en “tiempo real”, avisando inmediatamente de los problemas sintácticos. Otros editores de código fuente comprimirán el código, convirtiendo las palabras clave en elementos de un solo byte, eliminado espacios en blanco que son innecesarios y convirtiendo los números a una forma binaria. Estos editores comprimen el código fuente, pero cuando se va imprimir insertan los espacios y mayúsculas adecuadas. Hay editores que realizan ambas tareas. • Un compilador y/ o un intérprete: Un compilador es un programa o conjunto de programas que transforman el código fuente escrito en un código fuente en otro lenguaje de programación estructurado (el idioma destino, que a menudo tiene un formato binario más conocido como código objeto). La razón más común es la de querer transformar el código fuente para crear un archivo ejecutable del programa. El nombre de compilador se usa principalmente para los programas que traducen el código fuente de un lenguaje de programación de alto nivel a un lenguaje de bajo nivel (lenguaje ensamblador o lenguaje de código máquina). Y por el contrario, un intérprete es un programa capaz de analizar y ejecutar otros programas distintos, escritos en un lenguaje de alto nivel. La diferencia entre intérpretes y compiladores es que los compiladores traducen un programa desde su misma descripción en un lenguaje de programación al código de máquina del sistema, y los intérpretes sólo realizan la traducción cuando ésta que sea necesaria y se realizan instrucción por instrucción, y normalmente no guardarán el resultado de dicha traducción. Por medio del uso de un intérprete, un único archivo fuente se puede ejecutar incluso en sistemas diferentes (plataformas Mac, Linux o Windows; incluso en sistemas con distinta arquitectura hardware). Al usar un compilador, un único archivo fuente es específico para cada sistema, y así sobre la arquitectura desde la que se ha compilado. • Automatización de generación de herramientas: La construcción y automatización que se produce dinámicamente, integra las secuencias de comandos o la automatización de múltiples tareas que los desarrolladores de software hacen entre sus actividades usando las características y herramientas que ofrece un IDE. • Un depurador: Se trata de un programa usado para probar y eliminar los errores (depuración) de otros programas. El código examinado puede correr alternativamente en un simulador de conjunto de instrucciones. Con frecuencia se usa una técnica que permite incrementar la potencia deteniéndose cuando

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

encuentra condiciones específicas, pero será algo más lento que al ejecutar directamente el código. Algunos depuradores ofrecen dos formas de operación para limitar este impacto: la simulación parcial y la completa. Si se trata de un depurador de nivel de código fuente o depurador simbólico, éstos están integrados en los entornos de desarrollo integrados (IDE), cuando el programa para o alcanza una condición predefinida, en la depuración se muestra la posición (línea) en el código fuente donde se encuentra el error. Entre las principales funciones de un IDE tenemos: • Asistente de código; • Edición (creación y modificación) del código fuente; • Control de versiones;

RECUERDE Un entorno integrado de desarrollo software ayudará al programador al tener todas las herramientas necesarias en un solo programa, y también evitando posibles incompatibilidades entre las tecnologías.

• Validación y depuración de errores; • Funcionamiento y repositorios. No hay un límite bien definido entre entorno de desarrollo integrado y otras partes de un entorno de desarrollo de software más amplio. A veces integra un sistema de control de versiones y otras herramientas encaminadas a simplificar la construcción de una interfaz gráfica de usuario. Muchos entornos de desarrollo actuales también contienen un navegador de clases, un inspector de objetos, y una jerarquía de clases, normalmente todo ello para ser usado con el desarrollo de software orientado a objetos. 1.9. Gestión de proyectos de desarrollo de software. La gestión de proyectos es la aplicación del conocimiento, habilidades, herramientas y técnicas a las actividades del proyecto de forma tal de cumplir con los requerimientos del proyecto. La gestión de proyectos se lleva a cabo mediante el uso de procesos tales como: iniciación, planificación, ejecución, control y término. El equipo del proyecto gestiona el trabajo de los proyectos, trabajo que comúnmente implica: • Distintas demandas de: alcance, tiempo, costo, riesgo y calidad. • Clientes con diferentes necesidades y expectativas. • Requerimientos identificados.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

Es importante hacer notar que muchos de los procesos contenidos dentro de la gestión de proyectos son iterativos por naturaleza. Esto se debe, en parte, a la existencia de y a la necesidad de una elaboración progresiva de un proyecto durante toda su ciclo de vida; es decir, mientras más sabe usted acerca de su proyecto, mejor será su capacidad para manejarlo. El término gestión de proyectos se utiliza a veces para describir un enfoque organizacional para el manejo o administración de operaciones continuas. Este enfoque, más correctamente llamado gestión por proyectos, trata los diversos aspectos de las operaciones continuas como proyectos de forma tal de aplicar a estos las técnicas de gestión de proyectos. Aunque contar con una comprensión de la gestión de proyectos es un aspecto crítico para aquella organización que realiza la gestión por proyectos, no está dentro del alcance de este documento referirse detalladamente al enfoque en sí. Los proyectos y la gestión de proyectos operan en un ambiente más amplio que el del proyecto en sí. El equipo de gestión del proyecto debe entender este contexto más amplio – la gestión de las actividades diarias del proyecto es una actividad necesaria para el éxito, pero no es suficiente. Dado que los proyectos son empresas únicas, estos implican un grado de incertidumbre. Las organizaciones que ejecutan proyectos dividirán, generalmente, cada proyecto en varias fases de proyecto a fin de mejorar el control de la gestión y para establecer vínculos con las operaciones continuas de la organización ejecutante. De forma colectiva, las fases del proyecto se conocen como ciclo de vida del proyecto. 1.9.1. Planificación de proyectos. • La planificación es de mayor importancia para un proyecto, ya que el proyecto implica realizar algo que no se ha hecho antes. Como resultado de lo anterior, hay relativamente más procesos en esta sección. No obstante, la cantidad de procesos no significa que la gestión de proyectos sea principalmente la planificación la cantidad de planificación realizada debe ser comparada con el alcance del proyecto y la utilidad de la información desarrollada. La planificación es un esfuerzo continuo durante toda la vida del proyecto. Procesos Centrales: Algunos procesos de planificación tienen claras dependencias que hacer que sean ejecutados esencialmente en el mismo orden en la mayoría de los proyectos. Por ejemplo, las actividades deben definirse antes de que se puedan programar o costear. Estos proceso centrales de planificación pueden ser iterados varias veces durante cualquier fase de un proyecto. Estas incluyen:

RECUERDE Un gestor de proyectos debe contar no sólo con los ciertos medios, sino también con ciertas habilidades personales.

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

• Planificación del Alcance – desarrollar una declaración escrita del alcance como base para las futuras decisiones del proyecto. • Definición del Alcance – subdividir las principales prestaciones del proyecto en componentes más manejables y más pequeños. • Definición de las Actividades – identificar las actividades específicas que se deben ejecutar con el objeto de producir las distintas prestaciones del proyecto. • Secuencia de Actividades – identificar y documentar las dependencias interactividades. • Estimación de la Duración de las Actividades – estimación del número de periodos de trabajo que serán necesarios para completar las actividades individuales. • Desarrollo de Programas – analizar las secuencias de actividades, las duraciones de las actividades y los requerimientos de recursos para crear el programa del proyecto. • Planificación de la Gestión de Riesgos – decidir cómo abordar y planificar la gestión de riesgos en un proyecto. • Planificación de los Recursos – determinar qué recursos (personas, equipos, materiales, etc.) y en qué cantidades de cada uno, se deben utilizar para desarrollar las actividades del proyecto. • Estimación de los Costos – desarrollar una aproximación (estimación) de los costos de los recursos requeridos para completar las actividades del proyecto. • Presupuesto de Costos – asignar la estimación global de costos a paquetes de trabajo individuales. • Desarrollo del Plan del Proyecto – tomar los resultados de los demás procesos de planificación y colocarlos en un documento consistente y coherente. Procesos Facilitadores: Las interacciones entre los demás procesos de planificación son más dependientes de la naturaleza del proyecto. Por ejemplo, en algunos proyectos, puede haber poco o ningún riesgo identificable sino hasta después que se haya realizado gran parte de la planificación y el equipo reconozca que las metas de costo y programa son extremadamente agresivas y, por lo tanto, implican un riesgo considerable. Aunque estos procesos facilitadores se llevan a cabo en forma intermitente y según sean necesarios durante la planificación del proyecto, estos no son opcionales e incluyen:

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

• Planificación de la Calidad – identificar que normas de calidad son relevantes para el proyecto y determinar cómo satisfacerlas. • Planificación Organizacional – identificar, documentar y asignar roles de proyecto, responsabilidades y relaciones de reporte. • Contratación de Personal – obtener los recursos humanos que es necesario asignar a y trabajar en el proyecto. • Planificación de las Comunicaciones – determinar las necesidades de comunicación e información de parte de los clientes o accionistas: quién necesita qué información, cuándo la va a necesitar y cómo se le proveerá dicha información. • Identificación de los Riesgos determinar cuáles son los riesgos que podrían llegar a afectar el proyecto y documentar las características de cada uno de ellos. • Análisis Cualitativo del Riesgo – realizar un análisis cualitativo de los riesgos y condiciones a fin de priorizar sus efectos en los objetivos del proyecto. • Análisis Cuantitativo del Riesgo – medir la probabilidad e impacto de los riesgos y estimar sus implicancias para con los objetivos del proyecto. • Planificación de la Respuesta ante el Riesgo – desarrollar los procedimientos y técnicas para aumentar las oportunidades y reducir las amenazas de riesgo para los objetivos del proyecto. • Planificación del Abastecimiento – determinar qué se debe adquirir, cuánto se debe comprar y cuándo. • Planificación de la Requisición – documentar los requerimientos de productos e identificar las fuentes potenciales. 1.9.2. Control de proyectos. Los procesos de control son aquellos que aseguran el cumplimiento de los objetivos del proyecto, monitoreando y midiendo el avance regularmente, a objeto de identificar las variaciones respecto del plan, de modo tal de que sea posible tomar la acción correctiva cuando sea necesario. A fin de identificar las distintas desviaciones con respecto al plan, se hace necesario monitorear y medir regularmente el rendimiento / desempeño del proyecto. Dichas desviaciones o varianzas son ingresadas en los procesos de control de las distintas áreas de conocimiento. En caso de observarse varianzas

RECUERDE La planificación es un proceso vivo que debe ser actualizado y revisado durante todas las fases del proyecto.

100

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

RECUERDE El control de procesos nos permite conocer los aspectos que fallan en la elaboración de los mismos.

significativas (es decir, aquellas que ponen en peligro los objetivos del proyecto), se realizan ajustes en el plan, repitiendo los procesos de planificación del proyecto que correspondan. Por ejemplo, la falta de una fecha de término de actividad puede requerir de ajustes al actual plan de contratación de personal, la dependencia en el sobre-tiempo, o de compensaciones entre los objetivos de presupuesto y de programa. Tener control implica, además, tomar una acción preventiva anticipándose a posibles problemas. El grupo de procesos de control contiene los procesos centrales y los procesos facilitadores, e interactúan así: • Control Integrado de Cambios coordinar los cambios dentro de todo el proyecto. • Verificación del Alcance – formalizar la aceptación del alcance del proyecto. • Control de Cambios de Alcance – controlar los cambios al alcance del proyecto. • Control de Programa – controlar los cambios al programa del proyecto. • Control de Costos – controlar los cambios al presupuesto del proyecto. • Control de Calidad – monitorear los resultados específicos del proyecto con el objeto de determinar si estos cumplen con las normas de calidad relevantes, e identificar las formas de eliminar las causas de rendimiento / desempeño insatisfactorio. • Reporte de Desempeño / Rendimiento – recopilar y diseminar la información sobre el rendimiento / desempeño. Esto incluye informar sobre los estados, la medición del avance y de las predicciones. • Control y Monitoreo de los Riesgos – hacer un seguimiento de los riesgos identificados, monitorear los riesgos residuales e identificar los nuevos riesgos, asegurando la ejecución de los planes de riesgos y evaluar su eficacia en la reducción del riesgo.

1.9.3. Ejecución de proyectos. La ejecución del plan del proyecto es el proceso principal del plan del proyecto y dónde se gasta gran parte del presupuesto del proyecto. Aquí el gerente del proyecto y el equipo de gestión del proyecto deben dirigir y coordinar todas las interfaces organizacionales y técnicas que hay en el proyecto. El proceso del

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

101

proyecto es lo que se verá más afectado por parte del área de aplicación del proyecto, debido a que el producto del proyecto se crea en él. Se debe efectuar una continua monitorización del rendimiento y desempeño con respecto a la línea base del proyecto, de forma que se puedan acometer las acciones correctivas con base al rendimiento y desempeño real en relación al plan del proyecto. Se deben llevar a cabo predicciones periódicas de los resultados finales de costo y programa. Como consecuencias de la propia ejecución del plan del proyecto tenemos: • Resultados del trabajo. Los resultados del trabajo serán las consecuencias de las actividades efectuadas para realizar el proyecto. La información de los resultados del trabajo se recopila como parte de la ejecución del plan del proyecto y se incluirá en el reporte de rendimiento y del desempeño. Cabe señalar que las consecuencias suelen ser prestaciones tangibles como por ejemplo carreteras, edificios, etc., éstas suelen ser intangibles como el caso de las personas capacitadas quienes pueden aplicar dicha capacitación de forma efectiva y eficiente. • Solicitudes de cambio. Las solicitudes de cambio (como pueden ser cambios para modificar el presupuesto del proyecto, expandir o contraer el alcance del proyecto, modificar las estimaciones de programa se identifican frecuentemente mientras se lleva a cabo el trabajo del proyecto. 1.9.4. Herramientas de uso común para la gestión de proyectos. Para realizar una adecuada ejecución del plan del proyecto se necesitan ciertas habilidades personales, que se pueden complementar con herramientas específicas, así encontramos: • Habilidades generales de gestión. Incluye el liderazgo, negociación y comunicación y serán esenciales para la eficaz y efectiva ejecución del plan del proyecto. • Habilidades y conocimiento del producto. El equipo del proyecto debe disponer de un conjunto adecuado de habilidades al igual que de un conocimiento del producto del proyecto. Las habilidades necesarias se definen como parte de la planificación (en la planificación de recursos) y se entregan por medio de adquisición de personal. • Sistema de autorización del trabajo. Se trata de un procedimiento formal para sancionar el trabajo del proyecto, lo que se realiza para asegurar que el trabajo

RECUERDE El control de procesos nos permite conocer los aspectos que fallan en la elaboración de los mismos.

RECUERDE La ejecución del proyecto es el proceso principal, por lo que se debe controlar en todo momento para evitar retrasos y fallos en el mismo.

102

Unidad didáctica 1. EL PROCESO DEL DESARROLLO DE SOFTWARE

se realice en el momento adecuado y en la secuencia correcta. El principal mecanismo es una autorización escrita para comenzar el trabajo en una cierta actividad o paquete de trabajo. El diseño de un sistema de autorización de trabajo debe poder equilibrar el valor del control en relación a sus costos asociados. Así en proyectos menores bastará con usar las autorizaciones verbales.

RECUERDE La gestión de proyectos se apoya en un conjunto de herramientas así como en las habilidades personales del equipo de gestión. La intuición derivada de la experiencia es fundamental.

• Reuniones de revisiones de estados. Se trata de reuniones programadas de forma regular que se realizan para intercambiar información sobre el proyecto. En la mayoría de los proyectos las reuniones de revisión de estados se realizan con distintas frecuencias y en niveles diferentes (por ejemplo, el equipo de gestión del proyecto puede reunirse solo en forma semanal y ya con el cliente o usuario de forma mensual). • Sistema de información de gestión del proyecto. • Procedimientos organizacionales. Todas las organizaciones involucradas en el proyecto pueden tener procedimientos formales e informales que sean de utilidad para la realización del proyecto

02 La orientación a objetos 2.1. Principios de la orientación a objetos. Comparación con la programación estructurada 2.1.1. Ocultación de información (information hiding) 2.1.2. El tipo abstracto de datos (ADT). Encapsulado de datos 2.1.3. Paso de mensajes 2.2. Clases de objetos 2.2.1. Atributos, variables de estado y variables de clase 2.2.2. Métodos. Requisitos e invariantes 2.2.3. Gestión de excepciones 2.2.4. Agregación de clases 2.3. Objetos 2.3.1. Creación y destrucción de objetos 2.3.2. Llamada a métodos de un objeto 2.3.3. Visibilidad y uso de las variables de estado 2.3.4. Referencias a objetos 2.3.5. Persistencia de objetos 2.3.6. Optimización de memoria y recolección de basura (garbage collection) 2.4. Herencia 2.4.1. Concepto de herencia. Superclases y subclases 2.4.2. Herencia múltiple 2.4.3. Clases abstractas 2.4.4. Tipos de herencia 2.4.5. Polimorfismo y enlace dinámico (dynamic binding) 2.4.6. Directrices para el uso correcto de la herencia

2.5. Modularidad 2.5.1. Librerías de clases. Ámbito de utilización de nombres 2.5.2. Ventajas de la utilización de módulos o paquetes 2.6. Genericidad y sobrecarga 2.6.1. Concepto de genericidad 2.6.2. Concepto de Sobrecarga. Tipos de sobrecarga 2.6.3. Comparación entre genericidad y sobrecarga 2.7. Desarrollo orientado a objetos 2.7.1. Lenguajes de desarrollo orientado a objetos de uso común 2.7.2. Herramientas de desarrollo 2.8. Lenguajes de modelización en el desarrollo orientado a objetos 2.8.1. Uso del lenguaje unificado de modelado (UML) en el desarrollo orientado a objetos 2.8.2. Diagramas para la modelización de sistemas orientados a objetos

104

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

2. La orientación a objetos En este apartado se van a estudiar las bases teóricas de los lenguajes orientados a objetos, explicando sus características principales y comunes a todos ellos. Además se va a explicar cómo programar en un lenguaje concreto orientado a objetos que es Java. De esta forma a cada concepto teórico, le acompañará, si corresponde, una descripción práctica de cómo programarlo en Java. 2.1. Principios de la orientación a objetos. Comparación con la programación estructurada. En la programación estructurada, se crean unos módulos, que ejecutan una serie de acciones (por ejemplo puede ser un cálculo matemático, ordenar unos datos, reemplazar texto según unas condiciones, etc). De esta forma cada vez que se requiera realizar una de esas acciones el programa principal, llama al módulo correspondiente, las realiza y retorna el control al programa principal. Estos módulos se llaman también procedimientos, funciones, subrutinas, según las características o el lenguaje, y pueden devolver o no valores: por ejemplo, un módulo que calcule la suma de varios números devolverá el resultado, pero un módulo que ordene varios datos, realizará esas acciones sin devolver ningún valor. En la programación estructurada los módulos se diseñan de forma descendente, lo cual quiere decir que un programa complejo se va descomponiendo en subprogramas (módulos) más pequeños y más fáciles, cada uno de los cuales a su vez se puede descomponer en otros subprogramas cada vez más pequeños y más fáciles. Cada módulo de programa se codifica usando tres tipos de estructuras de control: • Estructuras secuenciales Cada instrucción de código se ejecuta de forma inmediata a la anterior. • Estructuras de selección o condicionales En este tipo de estructuras se evalúa una condición, la cual sólo puede ser verdadera o falsa. En caso de ser verdadera se ejecutan unas instrucciones y en caso de ser falsa se ejecutan otras. Se pueden anidar estas estructuras para hacer que se ejecuten más de dos alternativas. También, según el lenguaje, hay estructuras de selección que comparan un dato entre una gama de posibles valores, realizando unas acciones u otras según el valor que tome en cada momento.

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

105

• Estructuras de iteración En este tipo de estructuras, también llamadas bucles, un conjunto de instrucciones se ejecutan hasta que se cumpla una condición, momento en el que se pararía el bucle. Por ejemplo, se puede ir leyendo unos datos numéricos hasta encontrar el primero negativo. También entran dentro de esta categoría los bucles que se ejecutan un número determinado de veces, por ejemplo, sumar los n primeros números. La programación estructurada sirve para resolver problemas más o menos sencillos, pero en cuanto el problema es complejo, este tipo de programación no es el más adecuado por varias razones: • En primer lugar, todos los lenguajes llevan incorporados unos tipos de datos. Si se desean crear nuevos tipos de datos, estos lenguajes no suelen permitirlo por lo que se son más difíciles de mantener. • Además, los datos pueden ser accedidos por varios módulos, por lo que el medio en el que se almacenan es crítico; la disposición de los datos no se puede cambiar sin modificar todos los módulos que acceden a ellos. Frente a la programación estructurada y como avance de la misma, surgió la programación orientada a objetos (POO). Mientras que la programación estructurada se centra en el programa y su flujo de control, la programación orientada a objetos se centra en los datos. Dicho de otra forma, mientras que la primera trata de adaptar el problema a resolver al lenguaje, en la segunda se intenta adaptar el lenguaje al problema. Para conseguirlo se crean unas unidades lógicas llamadas datos. En POO un objeto es la representación de cualquier elemento del mundo real. Es decir, un objeto puede ser una persona, un animal, una moto, un cuadro de dialogo, un tipo de dato complejo definido por el usuario, etc. Todo objeto tiene dos características asociadas: sus atributos, que son los datos o variables que le caracteriza y sus métodos, que son las acciones que cambian el estado del objeto. Por ejemplo, si se crease un objeto casa, sus atributos serían, metros_cuadrados, precio, fecha_construccion, etc. y sus métodos podrían ser tasar_casa y reformar_casa. 2.1.1. Ocultación de información (information hiding). Como se comentaba en el punto anterior un objeto contiene propiedades y métodos. Éstos se encuentran como encerrados dentro de una cápsula y el

RECUERDE Las dos características principales de la programación estructurada son la modularidad y la estructuración.

106

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

interior de esta cápsula no es visible, por lo que no se puede ver qué información contiene un objeto y cómo está distribuida; por poner un ejemplo visual clarificador, un objeto sería como un huevo de cáscara opaca que no permite distinguir los detalles de lo que hay en su interior. A esta propiedad de los objetos se le llama ocultación de la información (en inglés information hiding). Esto no quiere decir que no se pueda conocer o manipular lo que hay en su interior, ya que entonces el objeto no tendría mucha utilidad, pero para hacerlo se tiene que hacer mediante el paso de los mensajes que se verá más adelante.

2.1.2. El tipo abstracto de datos (ADT). Encapsulado de datos. La abstracción es la propiedad de los objetos que consiste en tener en cuenta sólo los aspectos más importantes desde un punto de vista determinado y no tener en cuenta los restantes aspectos. El primer concepto en el mundo de la orientación a objetos nació con los tipos abstractos de datos (TAD o ADT). Un tipo abstracto de datos describe no sólo los atributos o características de un objeto, sino también su comportamiento, sus métodos. Por ejemplo, un modelo de abstracción del objeto bicicleta es la combinación de diferentes partes como dos ruedas, sillín, engranajes, etc. El encapsulado o encapsulación de datos (data encapsulation) es el proceso de agrupar atributos y métodos relacionados bajo un mismo nombre, lo cual materializa la abstracción. 2.1.3. Paso de mensajes. De forma general, un objeto no suele ser útil de forma independiente ya que por lo general un objeto forma parte de un programa que contiene más objetos. Los objetos interactúan entre sí mediante mensajes. Cuando un objeto X quiere que otro objeto Y ejecute uno de sus métodos, el objeto X manda un mensaje al objeto B. En ese mensaje se pueden pasar parámetros o argumentos que a veces son necesarios para ejecutar el método. Las tres partes fundamentales de un mensaje son el objeto al que va dirigido el mensaje, el método que debe ejecutar ese objeto y los parámetros que necesita para ejecutarlo. Por ejemplo si tenemos dos objetos: Coche y Persona, y se quiere que la persona cambie de marcha, el objeto Persona mandaría un mensaje al objeto Coche con el

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

método que debe ejecutar CambiardeMarcha y el parámetro que necesita, en este caso la marcha que se desea meter. MENSAJES EN JAVA Un mensaje en Java es una petición para que un objeto realice algún comportamiento. El mensaje en Java se escribe con una referencia al objeto receptor (por ejemplo System.out, que es la salida estándar , es decir, la pantalla del ordenador) seguida de un punto y luego el mensaje que se quiere enviar. Por ejemplo para enviar el mensaje println con el argumento necesario (el texto a imprimir) se escribe la siguiente instrucción en Java:

System.out.println(“Texto de ejemplo”);

2.2. Clases de objetos. Como se ha indicado anteriormente, un objeto es la representación de cualquier elemento del mundo real, pero en el mundo real suelen existir varios objetos del mismo tipo. Ese tipo de objetos es lo que en POO se denomina clase. Por ejemplo, mi_casa es una de las muchas casas que existen en el mundo. En POO se dice que mi_casa es una instancia de la clase de objetos Casas. Todas las casas tienen algunos atributos (superficie, precio, color_fachada) y algunos métodos (tasar_casa, reformar_ casa) en común. Sin embargo, el estado particular de cada casa es independiente del estado de las demás casas. Es decir, una casa podrá tener la fachada blanca y otra azul, pero ambas tienen en común el hecho de tener un atributo llamado color_fachada. Se podría hacer una analogía entre la clase y una plantilla para hacer casas. Se crearían casas a partir de la plantilla con los atributos y métodos de todas ellas. En POO se dice que se crea un objeto casa de la clase casas. En el ejemplo planteado la clase Casas define variables miembro comunes a todas las casas (todas las casas van a tener una superficie, un color de fachada, etc) y también declara e implementa los métodos o funciones miembro que permiten a la persona tasar una casa, abrir la puerta, etc. Una vez creada la clase Casas, se puede crear cualquier objeto casa a partir de esa clase. Cuando se crea una instancia de una clase, el sistema reserva suficiente memoria para el objeto con todas sus variables miembro. Atributos, variables de estado y variables de clase.

107

108

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

CLASES EN JAVA Una clase es un conjunto de atributos y métodos. En Java para crear una clase se usa la siguiente sintaxis: [public] class NombreClase { /* Dentro de este bloque de deben definir los atributos y métodos */ }

En esta sintaxis se debe tener en cuenta lo siguiente: La palabra public es opcional, por eso se ha puesto entre corchetes. sino se pone la palabra public, la clase tiene la visibilidad que tiene por defecto, : si no se pone, la clase sólo es visible para las demás clases del paquete. Dentro de ese bloque deben definirse todos los atributos y métodos de esa clase Las características más importantes de las clases en Java son: • Todos los atributos y métodos de Java deben pertenecer a una clase. No hay atributos y métodos globales. • Si una clase deriva de otra, por el concepto de herencia, hereda todos sus métodos y atributos sin necesidad de hacer nada. • Java tiene una jerarquía de clases estándar, que los usuarios pueden usar para crear sus propias clases. • Como en Java no hay herencia múltiple, una clase sólo puede heredar de una única clase. Si al definir una clase no se especifica de qué clase deriva, deriva de la clase Object. La clase Object es la base de la jerarquía de clases de Java. • En un fichero sólo puede una clase public y el fichero se llamará como la clase public que contiene con la extensión .java; es decir, si la clase se llama MiClase, el fichero se llamará MiClase.java. Aunque sólo puede haber una clase public por fichero, en el mismo se pueden declarar varias clases, aunque lo normal es que sólo haya una clase por fichero. Si la clase que contiene el fichero no es public, no es , no es necesario que el fichero se llame como la clase.

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

• Los métodos de una clase pueden referirse de modo global al objeto de esa clase al que se aplican por medio de la referencia this. • Las clases pueden agruparse en packages. Para hacer esto se introduce una línea al principio del fichero con la sintaxis: package NombrePackage. 2.2.1. Atributos, variables de estado y variables de clase Los atributos son las características de un objeto y determinan su apariencia, estado u otras características. Todo atributo tiene un nombre para identificarlo y un valor. Respecto al nombre en todos los lenguajes POO deben cumplir unas normas y siempre existen unas palabras reservadas que no pueden ser utilizadas como nombre de un atributo. Sobre el valor, en POO, cada lenguaje posee sus propios tipos de atributos o tipos de datos, pero en general todos los lenguajes cuentan con este tipo de datos: • De tipo entero para almacenar números sin decimales • De tipo decimal • De tipo booleano, es decir, aquellos atributos que sólo poseen uno de dos valores: verdadero o falso. • Una estructura de datos, array, vector o arreglo, es decir, un tipo de dato que permite almacenar diferentes datos, del mismo tipo normalmente, aunque pueden ser de diferente tipo también. • Un objeto de otra clase. • Punteros, es decir, datos que contienen la dirección de memoria de otros datos, es decir son datos cuyo valor es un apuntador a otros datos. Se suelen usar en listas y en POO hay dos punteros muy importante que son el puntero this, el cual apunta al mismo objeto y el puntero super que se usa para referirse a métodos de la clase padre. Los valores de los atributos se guardan en variables llamadas variables de instancia o variables de estado o miembros dato. Cada objeto en particular puede tener diferentes valores para esas variables. Estas variables se declaran en la clase pero sus valores se asignan y se cambian en el objeto.

109

110

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

Además de las variables de estado, están las variables de clase, que son aquellas que se aplican a la clase y a todas sus instancias. Por ejemplo, el número de ruedas de una bicicleta es siempre dos para todos los objetos bicicleta, por lo que el atributo numero_ruedas del objeto Bicicleta es el mismo (dos), para todos las bicicletas. Este atributo numero_ruedas se guarda en una variable de clase. Por el contrario, el color del cuadro de una bicicleta puede ser diferente en cada objeto bicicleta, por lo que el atributo color_cuadro se guarda en una variable de estado. DATOS EN JAVA En Java los nombres de las variables deben cumplir las siguientes normas: • El primer carácter del nombre debe ser una letra, el carácter “_” o el carácter “$”. No se admiten nombres que empiecen por números por tanto. • No puede contener espacios en blanco. • No se admite como nombre las palabras reservadas de Java. Estas palabras reservadas son las utilizadas por Java para sus propósitos internos: Ejemplos de palabras reservadas son abstract, boolean, double, extends, try, new, this, true, false, etc. • Los nombres son sensibles a mayúsculas y minúsculas, con lo que estos nombres serán diferentes para Java: Peso, peso, PESO. Respecto al tipo de datos, Java soporta los siguientes: • Números enteros: En función del rango que alcancen pueden ser: • byte o números enteros de ocho bits con valores de -128 a 127 • short o números enteros de 16 bits con valores de -32768 a 32767 • int o enteros de 32 bits cuyos valores están comprendidos entre 231 (-2.147.483.648) y 231-1 (2.147.483.647) • long o enteros de 64 bits con valores están comprendidos entre 263 y 263-1 • Números decimales: De igual forma que los anteriores, dependiendo del rango numérico que permitan pueden ser:

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

• float: números reales de simple precisión de 32 bits y con rango de 3.4e-038 a 3.4e+038 • double: números reales de doble precisión de 64 bits y su rango es de 1.7e308ª 1.7e+308, empleando mucha más precisión que float. • De tipo carácter: char .Es de tipo 16 bits sin signo por lo que sus valores pueden ir desde 0 a 65536, usando la codificación Unicode para hacer la transformación entre el número y el carácter representado. • De tipo booleano: Asignado por la palabra clave boolean y que puede tomar los valores true (verdadero) o false (falso). Sólo necesita un bit para su almacenamiento

EJEMPLO de programa en Java con uso de diferentes tipos de datos public class Clase_Ejemplo { private int precio; private String profesor; private boolean es_hombre; private boolean es_moreno; private float sueldo; private float peso; private short edad; private char letra_dni; } //Fin de la clase /* Inicialización de las variables */ Precio = 42; profesor = “Pedro Martín”;

111

112

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

es_hombre = true; es_moreno = false; diametro = 925.45f; // Una f o F final indica que es float. peso = 86.25; // Tipo double. Un número con punto decimal se interpreta como double. edad = 36; // Entero tipo short letra_dni = ‘X’; // Tipo char que se escribe entre comillas simples.

Además de estos datos simples, en Java, como en muchos otros lenguajes existen los arreglos o arrays, que son un conjunto de variables el mismo tipo. Estas variables pueden ser simples o referencias a otros objetos. En Java todos los arrays deben ser declarados y construidos antes de poder ser usados de alguna de estas dos formas equivalentes: • tipo [ ] NombreArray; • tipo [ ] NombreArray; Una vez declarados se crean, reservan memoria: NombreArray=new tipo [x]; //x es el número de elementos del array En un array siempre se asigna los valores desde el índice cero al índice n-1 siendo n el número de elementos del array.

EJEMPLO de uso de array en Java //Se declara un array de tres elementos de tipo entero int conjunto [3];

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

/* Se asignan valores a los dos primeros elementos del array. El tercer del elemento del array queda sin inicializar */ conjunto[0]=15; conjunto[1]=4;

En Java no existe tipos de datos que permitan almacenar cadena de caracteres o frases, ya que el tipo de dato char sólo almacena un carácter. Para trabajar con cadenas de caracteres se podría trabajar, como en otros lenguajes con arrays de tipo char, pero en lugar de hacerlo manualmente, en Java existe una clase que implementa las cadenas de caracteres que es la clase String. A través de los métodos miembros de la clase se accede a este array de caracteres o String. Para indicar que una variable es de clase se usa la palabra reservada static en su declaración. 2.2.2. Métodos. Requisitos e invariantes. Al igual que los atributos describen las propiedades de un objeto, los métodos implementan el comportamiento de los objetos de una clase. Se puede definir un m método como un conjunto de instrucciones que realizan una tarea. Los métodos son equivalentes a las funciones y procedimientos de los lenguajes estructurados. Como se ha comentado, hay variables de estado o instancia y variables de clase. De forma similar hay métodos de instancia y métodos de clase. Los métodos de instancia son llamados por un objeto en particular para realizar una determinada tarea y los métodos de clase son llamados desde la propia clase. MÉTODOS EN JAVA De forma similar a las variables de clase, se usa la palabra static para indicar que un método es de clase. Además, en función del tipo de valor que dato que devuelva el método, existen dos tipos de métodos: De tipo void, que ejecutan unas acciones pero no devuelven ningún valor y por tanto serían similares a los procedimientos en lenguajes estructurados.

113

114

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

Aquellos métodos que devuelven una variable tras ejecutar sus tareas y que son equivalentes a las funciones en los lenguajes estructurados. Para entender lo que significa un método y las ventajas del mismo se van a proponer un par de ejemplos.

EJEMPLO de programa en Java sin usar métodos public class Main { public static void main(String[] args) { int contador=0; /* Este bucle se ejecuta desde que contador vale cero hasta que llega a 6, ya que entonces no se cumple la condición y pararía. Es decir se ejecutaría 6 veces –de 0 a 5- y cada vez que se repita sacará por pantalla la frase “Contador vale 1”, “contador vale “, etc. */ while (contador!=6) { System.out.println(“ Contador vale: “+contador); contador++; } } }

El mismo comportamiento del código anterior se puede lograr con un método, según se muestra en este ejemplo:

public class Main { public static void main(String[] args) { bucleDeImpresiones(); //Se llama al método para que se ejecute }

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

/* Aquí comienza el método. Este método ejecuta acciones, pero no devuelve ningún valor, por eso se declara con void */ public void bucleDeImpresiones (){

int contador=0;

while(contador!=6) { System.out.println(“Contador vale: “+contador); contador++; } } } Por último, se va a indicar cómo ejecutar el mismo código pero con un método que devuelva valores. public class Main { public static void main(String[] args) { int contador=0; while(contador!=6) { System.out.println(“Contador vale: “+contador); /* Se llama al método SumarUno con el argumento contador y lo que devuelve (contador +1) se almacena en la variable valor_devuelto */ valor_devuelto=SumarUno (contador); //Se llama al método para que se ejecute /* Para que el bucle funcione bien, contador toma el valor de valor_devuelto. Realmente esta variable no es necesaria, pero se ha usado para dejarlo más claro. */ contador=valor_devuelto; } /* Este método recibe como parámetro un numero entero y lo incrementa en uno y devuelve como parámetro ese número entero incrementado. En su declaración, la palabra int primera hace referencia al tipo de dato que devuelve y

115

116

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

lo que se escribe dentro del paréntesis son los distintos argumentos que recibe el método separados por comas. Cada argumento consta de una palabra que indica el tipo de dato que es y su nombre. En este caso, el método SumarUno devuelve un tipo de dato entero, tras recibir como un único argumento de valor entero y nombre numero */

public int SumarUno (int numero){

numero++; valorfinal=numero;

/*con la palabra return se indica qué valor se devuelve desde la función desde el método al lugar desde donde ha sido llamado. En este caso se devuelve la variable valorfinal.*/

return valorfinal; } } }

La diferencia entre el primer código que no usaba métodos y el segundo y tercero que sí que usaba código es que los dos últimos están más optimizados y son reutilizables por los siguientes motivos: los métodos usados, SumarUno y bucleDeImpresiones no sólo sirven para este programa, sino que pueden ser aprovechados para otros, sin más que copiar su código ya independiente (aunque hay otras maneras). Además al dividir en métodos varios programadores pueden trabajar de manera conjunta y sin interferirse. Un programador se puede encargar de implementar un método llamado SumarUno que recibe un argumento de tipo entero y devuelve otro valor entero, sin necesidad de saber qué hace el programa principal. 2.2.3. Gestión de excepciones. Una excepción es un evento que perturba el flujo normal de ejecución de un programa. Las excepciones permiten gestionar los distintos tipos de errores que pueden producirse, tanto los errores del sistema como de aplicación.

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

Cuando se produce un error en un método en un lenguaje de programación orientado a objetos se crea un objeto de una clase que trate las excepciones, que contiene información sobre el tipo de error y el estado del programa en el momento en que se ha producido dicho error. Cuando se codifican mensajes que pueden provocar una excepción se puede capturar y tratar la excepción si se sabe el origen del error y se puede depurar o lanzar la excepción, ya que nos e podrá depurar ese error. EXCEPCIONES EN JAVA En contraposición a otros lenguajes de programación orientados a objetos, Java incorpora en el propio lenguaje la gestión de errores. El momento óptimo para detectar los errores es durante la compilación, pero en este período sólo se suelen detectar errores de sintaxis, surgiendo los demás problemas durante la ejecución de los programas. Una excepción en Java (Exception) es una condición anormal o un tipo de error producido durante la ejecución de un programa. Algunas excepciones son fatales y provocan la finalización de la ejecución del programa. Si esto sucede, se debe acabar de forma ordenada y lanzar un mensaje indicando el tipo de error producido. Otras excepciones pueden ser recuperables, por ejemplo no poder hallar un fichero para escribir en él. De suceder esto, el programa debe dar al usuario la posibilidad de subsanar el error, en el ejemplo propuesto, se le indicaría la nueva ubicación del fichero perdido. Un programa bien desarrollado debe poder tratar casi todos los errores que se produzcan, de dos formas: • mediante el uso de códigos de error que son evaluados en bucles if-else. Esta forma es compleja si hay varios niveles de llamadas a los métodos. • el propio lenguaje proporciona para gestionar los errores o Exceptions. En Java, los errores se representan con dos tipos de clases derivadas de la clase Throwable: Error y Exception. En el siguiente esquema se ve esta jerarquía de clases:

117

118

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

Throwable Error Exception RuntimeException NullPointerException IndexOutOfBoundsException NegativeArraySizeException Etc. IOException EOFException FileNotFoundException MalformedURLException Etc AWTException Etc

La clase Error está relacionada con errores de compilación, del sistema o de la máquina virtual de Java, JVM. Estos errores suelen irrecuperables y no dependen del programador por lo que no hay que capturarlos ni tratarlos. La clase Exception es más importante y dentro de ellas se encuentran: • Excepciones RuntimeException: Son bastante usuales y relacionadas con errores de programación. Se pueden llamar excepciones implícitas. • En contraposición a las anteriores el resto de clases derivadas de Exception son excepciones explícitas y se deben chequear y tratar.

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

Java comprueba y lanza las excepciones que derivan de RuntimeException durante la ejecución de un programa, por lo que el programador no necesita establecer los bloques try/catch para controlar este tipo de excepciones. Estas excepciones corresponde a dos casos de errores de programación: Un error que de forma usual no puede ser detectado por el programador, por ejemplo que un método se reciba una referencia null. Un error que sí que podría haber detectado el programados al escribir el código, por ejemplo sobrepasar el tamaño asignado de un array. Si que se podría comprobar estos tipos de errores, pero se complicaría muchísimo el código si hubiese que estar chequeando continuamente este tipo de errores. Las clases derivadas de la clase Exception pertenecen a distintos packages de Java., como java.lang (por ejemplo Throwable, Exception y RuntimeException, etc) java.io (como EOFException, FileNotFoundException, ...) y otros packages. Al heredar de la clase Throwable todos los tipos de excepciones pueden usar los métodos siguientes: String getMessage() Extrae el mensaje asociado con la excepción. String toString() Devuelve un String que describe la excepción. void printStackTrace() Indica el método donde se lanzó la excepción. LANZAR UNA EXCEPCIÓN EN JAVA Este es el proceso de lanzamiento de una excepción: • Se crea un objeto Exception de la clase que corresponda. • Se lanza la excepción con la sentencia throw seguida del objeto Exception creado.

EJEMPLO de excepción con throw /* Código que lanza la excepción MyException una vez detectado el error */

119

120

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

MyException me = new MyException(“MyException message”); throw me;

Esta excepción deberá ser capturada y gestionada en el propio método o en algún otro lugar del programa. Al lanzar una excepción el método termina de inmediato, sin devolver ningún valor, salvo si el método incluye los bloques try/catch/finally, en cuyo caso se ejecutará el bloque catch que la captura o el bloque finally si existe. Cualquier método en el que se puede producir uno o más tipos de excepciones y que no utiliza los bloques try/catch/finally para tratarlos, debe declararlas en el encabezamiento de la función por medio de la palabra throws. Si un método puede lanzar varias excepciones, se ponen detrás de throws separadas por comas, por ejemplo: public void leerFichero(String fich1) throws EOFException, FileNotFoundException {…} Es posible declarar sólo una superclase de excepciones, con lo que significa que se pueden lanzar excepciones de cualquiera de sus clases derivadas. El caso anterior sería equivalente a: public void leerFichero(String fich1) throws IOException {…} Las excepciones pueden ser lanzadas directamente por leerFichero() o por alguno de los métodos llamados por leerFichero(), al derivar las clases EOFException y FileNotFoundException de IOException. Al ser excepciones implícitas, no hay que declarar que se pueden lanzar objetos de la clases Error o RuntimeException. CAPTURAR UNA EXCEPCIÓN EN JAVA Si un usuario llama a un método que lanza una excepción sin tenerla en cuenta se produce un error de compilación con un mensaje parecido a este: “Exception java.io.IOException must be caugth or it must be declared in the throws clause of this method”. El programa no se compilará si el usuario no realiza una de estas acciones:

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

GESTIONAR LA EXCEPCIÓN CON UNA ESTRUCTURA TRY-CATCH Es obligatorio capturar las excepciones explícitas, aunque luego no se haga nada con ellas, aunque lo habitual es escribir un mensaje indicando la excepción producida. Las excepciones explícitas de las clases RuntimeException se deben capturar con los bloques try, catch y finally. En el bloque try se introduce el código del programa, si se lanza una excepción el programa sale del bucle try y pasa al bloque catch correspondiente según la excepción. Cada bloque catch tratará un tipo de excepción por lo que se pueden incluir tantos como sean necesarios. Las excepciones puede capturarse de una en una o de forma colectiva, a través de una superclase de la que deriven todas ellas. El bloque finally es opcional y las instrucciones que se incluyan en él se ejecutan siempre: aunque el bloque try tenga una instrucción continue, break o return, se produzca o no excepción, y si se produce, sea cual sea dicha excepción. Este bloque se necesita si se desea recuperar o devolver a su estado inicial a algunos elementos. Por ejemplo, si en un bloque try se abre un archivo para lectura y modificación de datos y se quiere cerrar ese archivo después tanto si se produce como si no se produce una excepción. Las instrucciones para cerrar el archivo se incluirían en el bloque finally, así se ejecutarán siempre independientemente de la excepción que se produzca o incluso si no se produce ninguna excepción. Ejemplo de excepción en Java donde el propio método trata la excepción El método controla una IOException en relación a la lectura ficheros y una MyException propia:

void metodo1(){ ...

try {

/* Este código puede producir las excepciones IOException y MyException*/

} catch (IOException e1) {

/* Este bloque se encarga IOException imprimiendo un mensaje */

121

122

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

System.out.println(e1.getMessage());

} catch (MyException e2) {

/*Se encarga de MyException: imprime un mensaje y finaliza la función */

System.out.println(e2.getMessage()); return;

} finally {

// Instrucciones que se ejecutan siempre

... } ... } // Final metodo1 En ocasiones, un método puede generar una Exception, pero no se quiere que el propio método la gestione. En esos casos, el método puede pasar o relanzar esa excepción al método desde el que ha sido llamado, sin usar los bloques try y catch. Para hacer esto se usa la palabra reservada throws seguida del nombre de la Exception. Este método tiene que tener los bloques try y catch para gestionarla o bien, puede volver a relanzarla.Así, se puede ir relanzando una excepción a los métodos superiores de forma recursiva hasta llegar al método principal del programa, el método main(). Ejemplo de excepción en Java donde el método relanza la excepción al siguiente método void metodo2() throws IOException, MyException { ... // Este código puede tratar las excepciones IOException y MyException ... } // Final metodo2

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

Por tanto, si un método llama a otros métodos que tratan excepciones, puede hacerlo de dos formas: capturando las posibles excepciones y tratándolas o remitirlas a otro método anterior en el stack (pila) para que sea éste el que las trate. En caso de no realizar ninguna de estas dos acciones, el compilador da un error, excepto en una excepción de la clase RuntimeException. Esquema de código general para tratar excepciones

try {

/* Código donde se controla si se lanza una excepción de tipo X, Y o Z */

} catch (X x1) {

} catch (Y y1) {

// Este código trata la excepción Y

} catch (Z z1) {

// Este código trata la excepción X

// Este código trata la excepción Z

} finally {

// Instrucciones que se ejecutan siempre

} }

CREACIÓN DE NUEVAS EXCEPCIONES EN JAVA Para crear nuevas excepciones, la persona que programe el código debe crear una clase que herede de la clase Exception o de algunas de las clases derivadas que mejor se adecue al tipo de excepción. La clase Exception puede tener dos constructores:

123

124

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

• Un constructor sin argumentos. • Un constructor que recibe como parámetro un String, en el cual se suele definir un mensaje aclarador del tipo de excepción generada. Este constructor debe llamar al constructor de la clase de la que deriva super (String). Ejemplo de código para crear nuevas excepciones

class ExcepcionPropia extends Exception {

public ExcepcionPropia () { // Constructor por defecto

super(); }

public ExcepcionPropia (String x) { // Constructor con mensaje

super(x); } }

EXCEPCIONES Y HERENCIA Si un método redefine otro método de una superclase que utiliza throws, el método de la clase derivada no es obligatorio que pueda lanzar todas las excepciones de la clase superior: podrá lanzar algunas o todas las excepciones, pero nunca más, ni tampoco nuevas excepciones. Esta restricción hace que el código que funciona con la clase base podrá trabajar automáticamente con referencias de clases derivadas, hasta en el tratamiento de excepciones. 2.2.4. Agregación de clases. Como las clases no están aisladas entre si, se producen relaciones entre ellas. Las relaciones más importantes son:

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

• Herencia. Se va a tratar más adelante con detenimiento. • Agregación Estas relaciones se basa en la idea de que un objeto es una composición de otros objetos. Desde otro punto de vista, estas relaciones de agregación se pueden entender como unas relaciones en las que una serie de clases aparecen como tipos de los atributos de otra clase. Este tipo de relaciones son conocidas como relaciones “todo-partes” siendo el “todo” la clase que une a las otras clases que son las “partes”. Una forma de averiguar si existe una relación de agregación es preguntarse si la clase a definir tiene un atributo de la otra clase que se está usando y si la frase “tiene un” tiene sentido. Por ejemplo, los objetos ordenador y teclado tiene una relación de agregación, ya que el objeto ordenador, se compone, entre otros, del objeto teclado y además la frase “un ordenador tiene un teclado” tiene sentido. Ejemplo de cómo implementar la agregación en Java

public class ordenador { private String fabricante; private String modelo;

/* La variable de referencia teclado es declarada e inicializada al mismo tiempo */ private Teclado teclado= new Teclado(); public ordenador() { }

}

//Constructor

125

126

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

• Asociación Existe una relación de asociación entre clases cuando una de ellas tiene que acceder a alguna de las propiedades o de los métodos de las otras. Estas relaciones son más débiles que las de agregación, ya que no se requiere crear un objeto nuevo a partir de otros, sino tan solo que los objetos interactúen entre si. Estas relaciones de asociación crean enlaces (permanentes o no) entre objetos. • Una forma de averiguar si existe una relación de asociación es si la frase “Usa un”, tiene sentido. Por ejemplo, una relación de asociación se da entre las clases ingeniero y calculadora, ya que la clase ingeniero debe acceder a las propiedades y métodos de la calculadora y además la frase “un ingeniero usa una calculadora” tiene sentido. Ejemplo de cómo implementar la asociación en Java public class Ingeniero { private int identificador; private String Nombre; private Calculadora calculadora; public Ingeniero() { //Constructor } public void setCalculadora(Calculadora calculadora) { this.calculadora = calculadora; } ……. }

En este ejemplo y, a diferencia de la agregación, se puede un objeto de tipo Ingeniero y asignarle un objeto Calculadora más adelante mediante el método setCalculadora.

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

2.3. Objetos. 2.3.1. Creación y destrucción de objetos. Al construir objeto hay que inicializar sus atributos con unos valores. Para hacer esto, todas las clases poseen un método llamado constructor que es el que se ejecuta de forma automática cada vez que se crea un objeto. Lo habitual es que este método constructor tenga el mismo nombre de la clase y no suele retornar ningún valor. Una clase puede tener más de un constructor, cada uno de los cuales tendrá unos argumentos diferentes. Pero aunque una clase tenga varios constructores, cuando se cree un objeto, sólo se utilizará uno de ellos. De forma similar, todas las clases tienen un método llamado destructor que es el que se ejecuta automáticamente cuando u objeto es destruido. Es recomendable emplear el constructor para inicializar las variables internas del objeto, o para obtener recursos, mientras que el destructor se suele emplear para liberar esos recursos obtenidos en el constructor. CREACIÓN Y DESTRUCCIÓN DE OBJETOS EN JAVA En Java el nombre de un método constructor es siempre el mismo que el nombre de la clase a la que pertenece y puede contener argumentos o no. Se usa la palabra clave new para solicitar la creación de un objeto que pueda recibir un mensaje. Por ejemplo, la clase String tiene un método constructor llamado String y se invocaría al constructor de esta forma: new String (“Texto de prueba”); Para que se pueda manejar ese objeto se lo asignamos a una variable. Ejemplo de uso de constructor en Java

String texto1, textomayusculas; //Se usa el constructor de String para crear un objeto con contenido texto1= new String (“Texto de prueba);

127

128

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

//Se saca por pantalla el texto “Texto de Prueba” (sin comillas) System.out.println(texto1); /*Se pasa el texto a mayúsculas y se almacena en la variable textomayusculas */ //Se sacar por pantalla el mismo texto en mayúsculas textomayusculas=texto.toUpperCase();

En Java no existen destructores por lo que la destrucción de los objetos se realiza de forma automática cuando el recolector de basura detecta que el objeto no está siendo usado. 2.3.2. Llamada a métodos de un objeto. Para acceder a los atributos de un objeto se escribe el nombre el objeto seguido de un punto y del atributo, por ejemplo para acceder al atributo cilindrada el objeto coche la sintaxis es: coche.cilindrada=3500; De igual forma cuando se necesita llamar a los métodos de un objeto para que se ejecuten sus acciones se emplea la misma sintaxis, por ejemplo, si se desea ejecutar el método cambiar_marcha (que tiene como argumento el número de marcha al que se quiere meter) del objeto coche se emplea la sintaxis: coche. cambiar_marcha (4); Como se ha indicado anteriormente, un método puede tener argumentos o parámetros. Existen dos tipos de parámetros: • Parámetros actuales: Son los que aparecen en la llamada a un método y contienen los valores que se le pasan al mismo. Estos parámetros pueden ser un objeto, una variable, etc. • Parámetros formales: Son los parámetros que aparecen en la cabecera del método y reciben los valores que se envían en la llamada al método. Se usan como variables dentro del método.

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

Ambos parámetros deben coincidir en número, orden y tipo. Si no coinciden los tipos, pero ambos tipos son compatibles, el sistema convierte el tipo del parámetro actual al del parámetro formal. Si no es posible la conversión, se produce un error. Si un método devuelve un valor, la llamada al método puede estar incluida en una expresión que recoja el valor devuelto, asignándolo a una variable por ejemplo. Ejemplo de parámetros formales y actuales en Java

public class Main { public static void main(String[] args) {

int contador=0;

while(contador!=6) { System.out.println(“Contador vale: “+contador);

/*La variable contador es el parámetro actual. */

valor_devuelto=SumarUno (contador);

//Se llama al método para que se ejecute

/* Se recoge el valor devuelto por el método en una variables */ contador=valor_devuelto }

/* la variable numero es parámetro formal */

public int SumarUno (int numero){

numero++; valorfinal=numero;

129

130

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

/*con la palabra return se indica qué valor devuelve el método al lugar desde donde ha sido llamado. En este caso se devuelve la variable valorfinal.*/

return valorfinal; } }

}

2.3.3.Visibilidad y uso de las variables de estado. La visibilidad de una variable especifica en qué parte del programa esa variable está definida y se puede usar. En POO esto es equivalente a decir desde qué clases se pueden acceder a ellas. En POO las variables según su visibilidad o modo de acceso pueden clasificarse en: • Publicas: Si una variable es declarada pública, se puede acceder a la variable desde cualquier clase, de manera independiente a que la clase pertenezca o no al paquete en que se encuentra el atributo. Este tipo de variables no son recomendables si se desea proteger los datos de la clase. • Privadas: Sólo es posible acceder a una variable de tipo privada desde la clase en la que ha sido definida. • Protegidas: Las variables protegidas sólo pueden ser accedidas desde la clase en que han sido definidas y desde todas las clases derivadas de ésta. • Privadas para el paquete (package-private): Si las variables sólo pueden ser accedidas desde las clases que pertenezcan al mismo paquete.

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

Recuerde Diferentes tipos de variables en POO según su visibilidad La misma clase

Otra clase del mismo paquete

Subclase de otro paquete

Privadas Package-Private Protegidas Publicas

El uso de una variable de estado o el ámbito de la misma es la zona del programa donde la variable puede ser usada. Existen dos ámbitos para las variables: • Ámbito local: Las variables locales sólo pueden usarse dentro del método o bloque de programa donde se definió. • Ámbito global: las variables globales se pueden usar desde cualquier punto del programa. Cualquier parte del programa puede acceder a estas variables tanto para visualizar su valor como para modificarlo. VISIBILIDAD EN JAVA En Java existen cuatro modificadores de acceso que se anteponen al nombre de la variable y que determinan la visibilidad de las variables: • public: para las variables publicas • private: para las variables privadas • protected: para las variables protegidas • package-private: si no se especifica ningún modificador para la variable ÁMBITO DE LAS VARIABLES EN JAVA En Java el ámbito o uso de las variables viene determinado por el lugar de declaración de una variable:

Otra clase de otro paquete

131

132

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

• Las variables locales: Son las que se definen dentro de cualquier método, incluyendo el método principal del programa, main. Por tanto, si una variable se define dentro de un método, sólo se puede usar dentro del mismo, desde el punto donde se ha declarado. Dentro de su ámbito, el nombre de una variable local debe ser único, pero puede haber dos variables ocales en dos métodos distintos con el mismo nombre, ya que tiene ámbitos diferentes. Estas variables se crean en memoria cuando se declaran y se destruyen cuando acaba la ejecución del método. No tienen un valor inicial por defecto y se le deben asignar valores iniciales válidos. Los parámetros formales, por ejemplo, son variables locales al método. • Variable local de un método: Si una variable se pasa como argumento de un método, actúa como variable local de ese método. • Las variables globales: Se definen fuera de todos los métodos incluyendo main y se pueden usar en cualquier parte del programa. • Variables miembro o atributos de una clase Se declaran dentro de una clase, pero fuera de todos los métodos. Es usual declararlas al inicio de la clase, pero no es obligatorio, mientras se declaren fuera de todo método es válido. Estas variables pueden ser inicializadas (si no se inicializan se les asigna un valor por defecto) y son accesibles desde cualquier método de la clase Si se declara una variable local con igual nombre que una variable miembro de la clase, la variable miembro es ocultada por la local y queda inaccesible en el ámbito de la variable local con el mismo nombre. • Variables de bloque Son las variables declaradas dentro de un bloque de instrucciones delimitado por llaves y no son visibles por otros bloques. Su ámbito comienza en el punto donde se declara la variable y se pueden usar desde su declaración hasta el final del bloque donde se declaran. Diferentes bloques pueden contener variables con el mismo nombre. Si tenemos bloques anidados uno dentro de otro. en el bloque interior no se puede declarar una variable con el mismo nombre que otra del bloque exterior.

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

Estas variables de bloque se crean en memoria cuando se declaran y se destruyen al finalizar la ejecución del bloque. Al igual que las variables locales, no tienen valor inicial por defecto y se les debe asignar valores iniciales. Ejemplo de variables en Java

public class Ejemplo { private int num1; //variable miembro public void metodo_ejemplo(){

int num2=20;//Variable local del método

{ System.out.println (num2+”,”´num1);

int num3=10; //Variable de bloque

System.out.println (num2+”,”´num3); { num4=1;//Variable de boque System.out.println (num2+”,”´num3+”,”+num4);

} /*Fin del ámbito de num4. Final del bloque donde ha sido declarada*/

System.out.println (num2+”,”´num3+”,”+num4); /* Error de compilación ya que num4 está fuera de su ámbito y no se puede usar. */

} /*Fin del ámbito de num3. Final del bloque donde ha sido declarada*/ } //Fin del ámbito de num2. Final del método metodo_ejemplo }//Fin del ámbito num1. Final de la clase

133

134

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

2.3.4. Referencias a objetos. Los parámetros se pueden pasar de dos formas a un método: • Paso de parámetros por valor Al llamar al método se crea una nueva variable, que es el parámetro formal y se le copia el valor del parámetro actual. En este caso, aunque tengan el mismo nombre, el parámetro actual y el formal son dos variables distintas. El método trabaja con la copia de la variable por lo que cualquier modificación que se realice sobre la copia de la variable dentro del método no afecta al valor de la variable fuera y por tanto, el método no puede modificar el valor de la variable original. • Paso de parámetros por referencia Al llamar al método se crea una nueva variable, que es el parámetro formal a la que se le asigna la dirección de memoria donde se encuentra el parámetro actual. Así, el método trabaja con la variable original por lo que puede modificar su valor. Aunque algunos lenguajes POO soportan ambas formas de paso de parámetros, en Java todos los parámetros se pasan por valor. 2.3.5. Persistencia de objetos. La persistencia de objetos se refiere a la acción de guardar la información de ese objeto (losa valores de sus atributos) de forma permanente, de forma que posteriormente se pueda recuperar esa información para poder ser de nuevo usada. Basándose en la persistencia, se puede clasificar los objetos en dos tipos: • Objetos persistentes: Aquellos objetos en los que se almacena su estado para su uso posterior y por tanto, son objetos en los que su tiempo de vida no depende del procesos que los instanció. • Objetos transitorios: Aquellos objetos en los que su tiempo de vida depende del proceso que los instanció.

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

PERSISTENCIA Y BASE DE DATOS Una de las aplicaciones más importantes de la persistencia son las bases de datos. Mientras que un programa estructurado puede acceder a una base de datos relacional sin problemas, en el caso de un programa orientado a objetos es bastante más complicado, ya que la base de datos trabaja con datos, registros y un POO trabaja con objetos. Para resolver esto se puede usar SQL, pero la conversión en ambos sentidos de formato de datos orientados a objetos a SQL requiere gran cantidad de código y las instrucciones deben ser implementadas por el programador. Otra posibilidad es usar una API, que igualmente implementada por el programador. La solución a la incompatibilidad entre el modelo de datos relacional de las bases de datos y el modelo orientado a objetos han aparecido las bases de datos orientadas a objetos que, como indica su nombre, almacenan objetos. Y ésta es la mejor solución para implementar una aplicación que necesite información persistente. Sin embargo, las bases de datos orientadas a objetos presentan algunos inconvenientes: al estar bastante menos desarrolladas que las bases de datos relacionales, tienen menor fiabilidad, facilidad de administración y rendimiento. Además, ambas bases de datos suelen ser incompatibles entre ellas, por lo que no es posible pasar una aplicación de uno a otro gestor y por tanto se depende de un único proveedor con todas las desventajas que ello conlleva: falta de competencia de precios y se deben aceptar lo de ese proveedor, si el proveedor falla no existe soporte, etc. Otra opción es usar un traductor capaz de traducir estos dos formatos de datos (registros y objetos). Este traductor es una capa de programación a la que se llama capa de persistencia o motor de persistencia. Si el programa quiere grabar un objeto invoca al motor de persistencia, el cual traduce el objeto a registros y llama a la base de datos para que guarde estos registros. Igualmente, si el programa desea recuperar un objeto, la base de datos selecciona los registros correspondientes, los cuales son traducidos en formato de objeto por el motor de persistencia. La forma de trabajar del motor de persistencia es totalmente transparente y al aprovechar las ventajas de ambos sistemas es la mejor opción para trabajar con bases de datos persistentes y objetos.

135

136

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

Diagrama de funcionamiento del motor de persistencia

Algunos motores de persistencia de Microsoft son NET Objectspaces y ORM.NET.

PERSISTENCIA EN JAVA Las dos soluciones vistas en teoría para abordar la persistencia en base de datos tienen su aplicación práctica en Java: • Java DataBase Connectivity (JDBC) es el API de Java que permite ejecutar aplicaciones sobre bases de datos, de forma independiente al motor de base de datos al que se acceda. • Entre los motores de persistencia en Java los hay de código abierto como Hibernate, OJB y Cayenne y otros comerciales como TopLink, Cocobase y FastObjects.

2.3.6. Optimización de memoria y recolección de basura (garbage collection). La recolección de basura es una técnica por la cual el programador no tiene que preocuparse de la asignación o liberación de la memoria, ya que el entorno la asigna cuando se crea un objeto nuevo y la libera cuando nadie lo está usando. Hay muchas estrategias para la recolección de basura usadas por los programas, algunas de las más usadas son: • Recuento de referencias (Reference counting): Recuento de referencia es una forma de recolección de basura que cada objeto tiene un recuento del número de referencias a ella. Se identifica por tener un recuento de referencia de cero. Recuento de referencias de un objeto se incrementa cuando se crea una referencia a él, y disminuye cuando se destruye una referencia. La memoria del ser reclamado cuando la cuenta llegue a cero.

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

El recuento de referencias garantiza de que los objetos se destruyen tan pronto como estén inalcanzable (suponiendo que no hay ciclos de referencia), y por lo general sólo tiene acceso a la memoria que puede ser en caché de CPU, en los objetos para ser liberados, o directamente señaló por ellos, y por lo tanto tiende a no tener efectos secundarios negativos significativos en caché de la CPU y el funcionamiento de la memoria virtual. -Barrido de marcas (Mark and sweep): Se trabaja en dos fases, la fase de marca y la fase de barrido. Cada objeto de memoria tiene un flag o indicador que suele ser un bit que indica si está libre o no. En la fase de marca se examinan los objetos y se marcan como “en uso” a aquellos objetos que están siendo utilizados a través del flag indicado (poniendo la cero o uno según corresponda). Todos los objetos que no se han marcado en esta fase son sin referenciar, por lo que los candidatos para la recolección. En la fase de barrido, los objetos en memoria que no se han marcado como “en uso” por la fase de marca se eliminan de la memoria. El principal inconveniente de este sistema es que es no determinista, lo que significa que los objetos se eliminan en un tiempo no especificado durante la ejecución del programa. Esta es la forma más común de la recolección de basura, y la que es apoyada por la mayoría de las implementaciones de Eiffel, Smalltalk, Ruby y Java. LIBERACIÓN DE MEMORIA EN JAVA En Java no existen destructores como en otros lenguajes orientados a objetos. En Java automáticamente liberar la memoria de los objetos ya no tienen ningún nombre por el cual acceder a ellos, y por tanto son objetos que ya han perdido la referencia. Esto se puede dar en múltiples circunstancias de ejecución del programa, por ejemplo al llegar al final del bloque en el que han sido definidos, o bien porque a la referencia se le ha asignado el valor null o porque a la referencia se le ha asignado la dirección de otro objeto. Esto es en Java la recolección de basura. En el lenguaje Java es habitual que varias variables apunten al mismo objeto. En estos casos el programa tiene un contador interno, que contabiliza el número de referencias que cada objeto tiene. Un objeto se puede borrar si ese contador llega a cero. Una forma de que un objeto se quede sin referencia es cambiar la referencia al valor null. La recolección de basura en Java puede no activarse si no existe poca memoria, pero se puede llamar de forma expresa a este recolector de basura en el momento que se desee mediante el método gc de la clase System (System.gc()).

137

138

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

Por ejemplo, se puede desear llamar al recolector de basura para que se ejecute justo antes de una sección del programa que va a utilizar mucho la memoria. Si bien el recolector de basura necesita unos pocos milisegundos para poder completar su cometido, se debe tener este tiempo de milisegundos de ejecución en cuenta, ya que se debe llamar cuando su ejecución vaya a ser posible sin que interrumpa al programa de forma crítica.

2.4. Herencia. 2.4.1. Concepto de herencia. Superclases y subclases. Herencia es una propiedad de los sistemas POO que permite a una clase incorporar métodos y atributos de otra clase, añadiéndolos a los que ya tiene. La clase que hereda las características de otra se la llama subclase, clase hija o clase derivada y la clase de la que se hereda recibe el nombre de superclase , clase padre o clase base. Los sistemas orientados a objetos permiten definir clases en término de otras clases. Por ejemplo, piso y chalet son diferentes tipos de casas. En la terminología orientada a objetos Piso y Chalet son subclases de la clase Casas. O dicho de otra forma, Casa es la superclase de Piso y de Chalet. Cada subclase hereda los atributos de la superclase. Es decir, tanto la clase Piso como la clase Chalet tendrán los atributos superficie, color de fachada, precio, etc. definidos en la clase Casa. Una subclase no tiene por qué tener sólo los atributos de su superclase, también puede tener sus propios atributos o redefinir algunos definidos en su superclase. Y no solo puede haber un nivel de herencia, se pueden tener tantos como se necesite. Por ejemplo, Apartamento hereda de Piso y este a su vez de Casa. Además la herencia siempre es transitiva, lo cual quiere decir que una clase puede heredar características de otras superclases que se hallan muchos niveles más arriba en la jerarquía de herencia. Por ejemplo, Siames una clase hija de Gato, Gato es una clase hija de Mamiferos y Mamiferos es una clase hija de Animal: esto implica que la clase Siamés hereda características de la clase Gato, pero también de la clase Mamiferos y de la clase Animal. Gracias a la herencia, se puede reutilizar el código todas tantas veces como se quiera.

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

HERENCIA EN JAVA En Java, para declarar que una clase deriva de otra se usa el modificador extends con la siguiente estructura: public Nombre_Clase_Derivada extends Clase_de_La_Que_Hereda Una clase al derivar de otra, hereda todos sus métodos y propiedades, siempre que no sean privados. La clase derivada puede redefinir los métodos y propiedades de la que deriva, siempre que no sean del tipo final o static. Los métodos de la clase superior que son redefinidos pueden ejecutarse a través de la referencia: super.Nombre_Del_Metodo(); Por otra parte el constructor de una clase puede usar el constructor de la clase superior para no tener que inicializar los atributos derivados. Esto se hace con la instrucción: super (parámetro1, parámetro2…) Después, el constructor de la clase derivada asigna los valores a los atributos no heredados. Ejemplo de código fuente de Java que implementa herencia

/*Se define la clase Persona con los atributos nombre y apellidos y el constructor Persona */ class Persona {

protected String nombre;

protected String apellidos;

/* Constructor de la clase Persona que asigna nombre y apellidos a un nuevo objeto Persona*/

public Persona(String nombre,String apellidos) {

139

140

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

this.nombre = nombre;

this.apellidos = apellidos;

}

/* Método de la clase Persona que devuelve el nombre completo de la forma “apellidos, nombre”

public String nombreCompleto() {

return this.apellidos + “, “ + this.nombre;

}

// Método de la clase Persona que devuelve el nombre completo

public String identificacion() {

return this.nombreCompleto();

} } /* Subclase de la clase persona que hereda sus propiedades y tiene un atributo nuevo, nif , un constructor y un método sobreescrito */ class Hombre extends Persona {

protected String nif;

public Hombre(String nombre,String apellidos, String nif) {

super(nombre,apellidos);

this.nif = nif;

}

public String identificacion() {

} }

return super.identificacion() + “, nif: “ + this.nif;

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

/* Clase que usa los constructores para crear dos nuevos objetos Persona y Hombre */ public class Herencia {

public static void main (String args[]) {

Persona persona1 = new Persona(“José”,”Pérez Fernández”);

Hombre hombre1 = new Hombre(“Jose”,”Ros”,”1222333H”);

} }

2.4.2. Herencia múltiple. Existen dos tipos de herencia: herencia simple y herencia múltiple. En herencia simple una clase sólo puede tener un ascendiente, o lo que es lo mismo, una subclase sólo puede heredar de una única clase. En la herencia múltiple, una clase puede tener más de un ascendiente o lo que es lo mismo una subclase puede heredar de más de una clase. Según el lenguaje de programación, puede admitir una u otra clase de herencia. Un ejemplo de herencia simple es el de la clase Animales, de la cual heredan las subclases Aves y Mamiferos y de la clase Aves a su vez heredan Buho y Paloma. Cada una de las subclases sólo puede heredar de una sola clase, es decir, no puede haber un animal que sea mamífero y ave a la vez. Por el contrario un ejemplo de herencia múltiple es un estudiante que trabaja. Si existe una clase llamada Trabajador y una clase llamada Estudiante, la subclase EstudianteTrabajador hereda de las dos. Todo lo que se puede hacer con herencia simple se puede hacer con múltiple, pero con la múltiple suele ser más difícil. La ventaja principal de la herencia múltiple es que se pueden definir clases hibridas, que comparten los atributos y métodos de dos o más clases, sin necesidad de escribir código. La principal desventaja es que resulta más difícil de implementar y es más lenta.

141

142

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

En una herencia simple es fácil descubrir si una clase hereda un método o atributo, basta con ir subiendo la jerarquía y comprobar si las clases padres los tienen; en cuanto aparezca se sabe que lo va a heredar y se puede detener la búsqueda. En una herencia múltiple al poder tener más de una clase padre, la búsqueda es mas tediosa, pero además puede suceder que el atributo o método esté presente en dos o más clases padre, en cuyo caso habría que programar qué se desea que suceda: que predomine la clase padre que primero aparezca, la más cercana o que no predomine ninguno y herede ambas, en cuyo caso habría que discernir cómo tratar esa simultaneidad. HERENCIA MÚLTIPLE EN JAVA El programa Java permite múltiples niveles de herencia, pero no permite la herencia múltiple, al contrario que otros lenguajes POO. Java tiene otro mecanismo parecido al de la herencia múltiple que son los interfaces. Un interface en Java es una clase donde no se implementa ningún método, es decir, son métodos abstractos y la clase es abstracta pura. Esto permite definir qué forma tendrá la clase, los métodos, argumentos, etc, pero sin entrar al código de la clase. Para crear una interface se utiliza la palabra clave reservada interface en lugar de la palabra class usada para definir una clase. La interface se puede definir pública o package-private (si no se indica modificador de acceso) teniendo el mismo significado que en las clases para los atributo; ya que en una interface todos los métodos son públicos. Se usa la palabra reservada implements (en lugar de extends) para indicar que una clase implementa los métodos de una interface. De esta forma una clase puede implementar más de una interface. 2.4.3. Clases abstractas. En POO las clases pueden ser de dos tipos: abstractas o concretas. Las clases abstractas son las clases de nivel más alto y no se pueden instanciar, es decir, nos e puede crear objetos de esa clase. Las clases concretas suelen ser las del nivel más alto en jerarquía y se pueden instanciar. Las clases abstractas se usan como clase base de otras clases y se corresponden con conceptos generales, difíciles de traducir en ejemplos concretos, por lo que se usan para dar una descripción de las características comunes de esos objetos.

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

Un ejemplo de clase abstractas puede ser animales de dos patas, siendo clases derivadas de la misma gallina y avestruz. Otro ejemplo de clase abstracta es figura cuyas clases derivadas podrían ser cuadrado, rectángulo y círculo. DIFERENCIAS ENTRE CLASE ABSTRACTA E INTERFACE EN JAVA Las diferencias fundamentales entre estos dos conceptos son: A diferencia de las clases que se extienden por las subclases, las interfaces se implementan (implements en lugar de extends). Aunque una clase sólo puede extender de una sola clase, puede implementar de más de un interface. En el interface cualquier método es abstracto y público aunque no se declare. Todas las variables que se declaran en una interface son variables de clase por lo que tendrán el mismo valor en todas las instancias que se creen de la clase que implementa una interface. Ninguna variable declarada en una interface será variable de instancia. 2.4.4. Tipos de herencia. Existen dos tipos de herencia: • Herencia por especialización: Es la que se genera al necesitar una clase nueva con las mismas características que otra, pero en la que va a ser necesario definir nuevas características. • Herencia por generalización: Se genera cuando existen varias clases que comparten características y se decide crear una clase que tenga esas características comunes para que todas esas clases hereden de ésta y sólo quedarán las características distintivas en casa una de las subclases. De esta forma se evita la redundancia. La herencia es la misma, esta diferencia es conceptual para explicar por qué se ha llegado a la misma. Un ejemplo de herencia por especialización es una empresa en la cual tenemos la clase padre Empleado que tiene unas características comunes a todas las clases hijas: sueldo, horario, etc. Si deseamos tener como clases hijas Secretaria (que va a trabajar mucho con ordenador) y Tecnico (que tiene muchos manuales de

143

144

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

sus maquinas en inglés), van a necesitar características especializadas, la clase Secretaria necesita una característica nueva y propia que es velocidad_teclado y la clase Tecnico necesita su propia característica distintiva que es nivel_ingles. Se generaría herencia por especialización. Un ejemplo de herencia por generalización es un zoológico donde tenemos varias clases (Leones,Tigres, Elefantes, etc) con las mismas características comunes (peso, altura, numero_crias_edad..). Para evitar redundar datos se crea mediante herencia por generalización una clase padre de todas estas, la clase Mamiferos, que tiene las características comunes de las clases hija. Se crea herencia por generalización. 2.4.5. Polimorfismo y enlace dinámico (dynamic binding). El polimorfismo es una característica de la POO que consiste en construir varios métodos diferentes con el mismo nombre. Por ejemplo, si se tiene la clase números con el atributo valor que es el valor numérico concreto y se define el método hallar_mayor para dos objetos números, lo que hace este método es hacer una comparación entre los atributos valor de cada uno de ellos en función de que la comparación salga verdadera o falsa obtiene el numero mayor. Pero ese mismo sistema de POO, puede tener una clase Fecha que tenga tres atributos: dia, mes y anno. Se puede aplicar el mismo método llamado hallar_mayor que comparará dos objetos fecha y obtendrá el objeto fecha mayor, para ello tendrá que ir comparando los atributos anno, mes y dia en ese orden para obtenerlo. Es decir, usamos el mismo nombre para dos métodos diferentes. Ejemplo de polimorfismo

class Animal { public void respirar() { System.out.println(“Respirar...”); } }

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

class Animal { public void respirar() { System.out.println(“Respirar...”); } } class Pez extends Animal { public void respirar() { System.out.println(“Burbujear...”); } }

En este caso el método respirar produce un efecto distinto si es invocado desde un objeto de la clase Animal como por ejemplo un objeto gato, que si se llama desde el objeto pez, que, aunque hereda de la clase Animal, sobreescribe la función respirar. El polimorfismo evita la complicación de manejar métodos diferentes para el mismo objetivo. en el ejemplo indicado anteriormente, el método siempre va a hacer lo mismo , hallar el mayor de los objetos dados. En lenguajes no orientados a objetos y que por tanto, no tienen la propiedad de polimorfismo, se tendría que emplear un método diferente para cada tipo de objeto, sería tedioso, ya que habría que definir el método hallar_mayor_de_numeros, el método hallar_mayor_ de_fechas, el método hallar_mayor_de_matrices, etc. Al ser el concepto “hallar el mayor” el mismo, lo deseable es poderlo aplicar en forma uniforme.

145

146

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

Además en los lenguajes no orientados a objetos es muy tedioso tener un método que se comporte de forma diferente si hay dos argumentos, que tres que n o bien manejar métodos que reciban un número variable de argumentos. En cualquier caso, no es un enfoque natural para resolver el problema. En lenguajes orientados a objetos es posible definir la misma operación para diferentes clases, por lo que permite realizar esa operación sobre elementos de diferentes clases, y combinaciones de ellos. Esta característica se conoce en algunos lenguajes como sobrecarga de operadores. Existe tipo de poliformismo que está muy relacionado con el concepto de herencia. Si una clase Y hereda de una clase X, entonces Y es tratada como un subtipo de X. En cualquier lugar en que el compilador reconozca una instancia de la clase X, también aceptará una instancia de la clase Y. Si se tiene un arreglo de elementos de la clase X, este arreglo aceptará también elementos de la clase Y, puesto que una Y es una X. Es decir, una entrada del arreglo puede contener un objeto de clase X, la siguiente una instancia de la clase Y, y si existiera una clase Z que hereda de Y, la siguiente entrada puede contener un elemento de clase Z. Entonces se dice que esas referencia a los elementos son polimórficas. Además mediante la herencia es posible redefinir métodos. Por lo tanto, si la clase X define un método f particular, y Y la redefine (con todo el derecho de una subclase), entonces invocaciones del método f aplicados a diferentes objetos pueden tener efectos completamente diferentes. Por ejemplo, se tiene aplicación donde se necesita manejar polígonos. Para ello se define una clase Polígono, de la cual heredan las clases Pentagono, Rectangulo, y Triangulo. Todos ellos redefinen la función calcular_area asociada a Polígono. Por lo tanto, si se tiene una lista de polígonos, y se recorre enviando el mensaje “calcular_area” a cada elemento, entonces cada uno de ellos conocerá la manera correcta de calcular su superficie según su naturaleza. Ya que una referencia polimórfica puede corresponder a objetos de varias clases durante el tiempo, existen los conceptos de tipo estático y tipo dinámico. El tipo dinámico puede cambiar de un instante a otro durante la ejecución del programa. El tipo estático se determina a partir de la declaración de la referencia en el programa. Se conoce en tiempo de compilación y determina el conjunto de tipos válidos que la referencia podrá aceptar. La posibilidad de proveer tipos dinámicos implica poder implementar un mecanismo de binding dinámico. Es decir, que el código asociado a una invocación de un método debe poderse determinar en tiempo de ejecución.

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

En los lenguajes tradicionales la dirección en memoria a la que se dirige al producirse una invocación a un método es fija (en realidad es siempre relativa a la dirección en que se cargue el programa, pero ese desplazamiento no varía). Pero el método calcular_area indicado antes tiene varias implementaciones, y la correcta se conoce únicamente en tiempo de ejecución en el instante en que se produzca la invocación. Además, así como la herencia permite desarrollar diseños de sistemas extensibles al facilitar la reutilización de definiciones existentes para desarrollar nuevos métodos, el polimorfismo también los hace extensibles al permitir que cualquier instancia de una subclase aparezca en el lugar en que puede aparecer una instancia de una clase base. Si tras realizar el diseño es necesario especializar una clase para cubrir un nuevo requerimiento, las instancias de esa clase se podrán usar bajo el esquema existente, con lo que se permite la inclusión de nuevas características con muy pocas modificaciones al resto de la aplicación. Algunos lenguajes implementan un tipo de polimorfismo denominado polimorfismo paramétrico, que conste en que se usa el mismo código para manejar diferentes tipos de objetos. El tipo es un parámetro para el cuerpo del código. Esto es muy útil al implementar clases contenedoras de objetos, como arreglos, listas, pilas, y colas, ya que en estas clases el código es casi totalmente independiente de los elementos que contengan. Debido al polimorfismo, si se describe una clase lista implementada como un arreglo en donde cada entrada es un elemento de clase A, entonces cada entrada podrá mantener una instancia de cualquier subclase de A, y de A misma. Con el polimorfismo paramétrico es posible enviar como parámetro el tipo de las entradas, y no es necesario entonces que pertenezcan a una jerarquía determinada. 2.4.6. Directrices para el uso correcto de la herencia. La herencia debe usarse tal y como se ha visto para permitir la reutilización del código. Antes de usar la herencia se debe analizar si tras la misma va a haber sobreescritura y si es necesaria la herencia; si tras la herencia es necesario sobreescribir y por tanto, generar nuevo código, seguramente no se esté implementando bien el proyecto. Además no es recomendable usar la herencia como otra herramienta más de programación usada para estructurar programas.

147

RECUERDE La asociación, o vínculo, entre cada llamada a uno de los métodos y la implementación concreta finalmente invocada puede establecerse en tiempo de compilación y entonces se habla de vinculación estática (static binding) o bien puede establecerse en tiempo de ejecución y se habla de vinculación dinámica (dynamic binding).

148

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

2.5. Modularidad. La modularidad es la propiedad que permite dividir un programa en partes más pequeñas llamadas módulos. Estos módulos deben ser independientes entre si y del programa, de tal forma que un modulo pueda ser usado en un programa diferente sin problemas. En programación estructurada se crea el concepto de que para resolver un problema difícil, es recomendable dividirlo en subproblemas más pequeños, los cuales se pueden diseñar, programar y probar de manera fácil e independiente del resto del programa. Esto se resume en la frase muy usada en programación “divide y vencerás”. Por ejemplo, si tenemos un fichero con datos numéricos y se quiere hallar el mayor de esos datos, en lugar de hacer un programa único que ejecute todas las acciones se creará un modulo llamado leer_fichero que lea un dato de un fichero y lo almacene en algún sitio (variable o estructura), también se creará un modulo comparar_numeros que compare dos números y obtenga el mayor y un modulo recorrer_fichero que vaya recorriendo las posiciones de un fichero de forma correlativa hasta llegar al final. De esta forma un problema complicado se divide en varios problemas más simples (los cuales a su vez se pueden subdividir en otros problemas aún más simples y así sucesivamente). Además cada uno de estos módulos si están bien programados se podrían usar en otro programa. Por ejemplo el modulo leer fichero se podría usar en un programa que ordene un fichero.

Importante En programación estructurada, modularizar consiste en dividir en partes la solución del problema, mientras que en POO se modulariza el problema.

En programación orientada a objetos, la modularización se produce a nivel de clases, no a nivel de métodos. De esta forma se divide en el análisis el problema en clases, y a partir de esas clases conceptuales, se modulariza la solución del mismo. Se puede decir que en POO no es importante lo que hace el programa, sino a qué se lo hace. Y aunque la POO también tiene módulos funcionales, que son los métodos de las clases, es una modularización mucho menos importante que la principal, la de las clases. Por último, se debe indicar que también hay otro tipo de módulo que es el paquete, librería de clases o package, el cual sirve para agrupar clases cuando su número es relativamente grande.

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

2.5.1. Librerías de clases. Ámbito de utilización de nombres. Las clases se agrupan en paquetes o librerías para facilitar su organización. Si una clase no pertenece a ningún paquete, se le asigna el paquete de forma automática al paquete al que pertenecen las clases que no declaran ningún paquete. Además de usar los paquetes que vengan creados por defecto, el programador puede crear sus propios paquetes. Un programa puede estar hecho por varios programadores y no es difícil que a la hora de programar, utilicen el mismo nombre en algunas de sus clases. Cuando esas clases con el mismo nombre se junten en el mismo programa, se produce un conflicto. Para evitarlo, cada programador debe crear sus propios paquetes e incluir sus clases en los mismos. De esta forma, el nombre de la clase incluye el nombre del paquete y no se produce el conflicto. Evidentemente, esto funciona siempre que los nombres de los paquetes no sean iguales, para ello una de las posibilidades es usar el dominio en Internet de la empresa que crea el paquete. LIBRERÍA DE CLASES EN JAVA Para declarar que una clase pertenece a un paquete se debe indicar la siguiente instrucción justo antes de la declaración de la clase: package nombre_paquete; Todas las clases pertenecientes a un mismo paquete tendrán esta declaración con el mismo nombre del paquete, obviamente. Para poder usar los paquetes, se tienen que declarar en la primera línea del fichero con la sintaxis: import nombre_paquete; Por ejemplo, la instrucción import java.applet.*; Importa todas las clases del paquete applet que se necesiten con el operador asterisco. Pero se debe tener en cuenta que sólo importa las clases de ese paquete, no las clases de paquetes inferiores en la jerarquía, es decir, clases que pertenezcan a paquetes dentro del paquete applet. Para hacer eso, habría que incluir la instrucción:

149

150

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

import java.applet.subpaquete.*; Si sólo se necesitase importar una clase concreta del paquete, como la clase Applet se usaría la instrucción: import java.applet.Applet; En Java la variable de entorno del ordenador CLASSPATH contiene los directorios donde Java va a buscar los paquetes cuando se invoquen. LIBRERÍA DE CLASES ESTÁNDAR EN JAVA -java.lang: Es el paquete por defecto y contiene las clases integradas en Java. -java.applet: Contiene los componentes para la creación de aplicaciones tipo applet, que son programas de Java embebidos o incrustados en una pagina web. • java.awt: Permite la construcción de la interfaz de usuario AWT (Abstract Window Toolkit), que es la original de Java. • java.beans: Da la posibilidad de crear componente software llamados javabeans • java.io: Implementa la comunicación de entrada y salida del programa con periféricos (impresora, pantalla, teclado) y ficheros. • java.math: Es la librería que contiene funciones matemáticas: logarítmicas, trigonométricas, etc. así como constantes como PI y E. • java.net: Implementa las comunicaciones internas en la red local y externas en Internet • java.rmi: Contiene los componentes necesarios para el acceso a objetos remotos situados fuera del propio ordenador. • java.security: Paquete con los mecanismos de seguridad • java.sql: Permite la conectividad con las bases de datos • java.util: Contiene varias clases de utilidad general como Date o Vector. • javax.swing: Permite la construcción de la interfaz gráfica Swing, mejora de la interfaz AWT.

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

Tal y como se indicó anteriormente, el ámbito de los nombres de las variables puede ser de cuatro tipos. Estos es válido también para el ámbito de uso de los métodos. Los cuatro tipos, como se ha visto, son: • public, si todas las clases pueden acceder al atributo o al método. • protected, sólo se tiene acceso a él desde la propia clase que lo define y desde todas las que heredan de él. • private sólo se tiene acceso a él desde la propia clase que lo define. • package, se tiene acceso desde las clases que se encuentren contenidas dentro del mismo paquete que la clase que los define. Se va a explicar lo siguiente con un ejemplo:

public class Ejemplo { public int numEntero; protected String cadena; private float numReal; public Ejemplo() { } public void metodoPublico() { metodoPrivado(); metodoProtegido(); metodoPublico(); numEntero=15; cadena=”prueba”; numReal=3.1416;

151

152

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

... } protected void metodoProtegido() { ... } private void metodoPrivado(); }

Si se implementa una clase que herede de esta clase Ejemplo, se va a explicar el ámbito de nombres: El método declarado privado (y llamado MetodoPrivado) sólo puede ser accedido desde la clase Ejemplo, no desde su heredada, por eso daría error. En cambio el método Publico puede ser accedido desde cualquier clase y el protegido también puede ser accedió desde la subclase como en este caso. De igual forma pasa con los atributos públicos y protegido y en cambio el atributo numReal al ser privado no podría ser accedido desde la clase Hija. public class HijaDeEjemplo extends Ejemplo { public void otroMetodo() { metodoPublico(); metodoProtegido(); metodoPrivado(); // -> Error. numEntero=2; cadena=”prueba”; numReal=3.14159; // -> Error. } }

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

En este otro ejemplo se instancia un nuevo objeto de la clase Ejemplo. El método privado y protegido no puede ser invocado de igual forma que los atributos con el mismo ámbito. Ejemplo miEjemplo = new Ejemplo(); miEjemplo.metodoPublico(); miEjemplo.metodoProtegido(); // -> Error. miEjemplo.metodoPrivado(); // -> Error. miEjemplo.numEntero=25; miEjemplo.cadena=”otra prueba”; // -> Error. miEjemplo.numReal=27.5; // -> Error.

2.5.2.Ventajas de la utilización de módulos o paquetes. El uso de módulos o paquetes otorgan las siguientes ventajas: • Evitan conflictividad en los nombres, tal y como se ha comentado anteriormente. • Permiten organizar el código de una aplicación, clasificando las clases e interfaces relacionadas en un mismo paquete, lo cual a su vez, facilita la búsqueda y uso de los diferentes datos • Permiten controlar el acceso a clases y métodos de un paquete, lo cual garantiza la seguridad • Permiten la reutilización

2.6. Genericidad y sobrecarga. 2.6.1. Concepto de genericidad. La genericidad es un mecanismo que permite escribir trozos de código genérico (subprogramas, módulos, clases...), que incluye referencias a uno o varios nombres

153

154

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

de tipos de datos (o clases) o incluso a algoritmos, sin que exista una declaración de los mismos. Dicho de otra forma, con la genericidad se pueden escribir algoritmos o definir contenedores que se puedan aplicar a un amplio rango de tipos de datos Un ejemplo de uso de genericidad son los contenedores cuyas operaciones no dependen del tipo de datos almacenado, por ejemplo listas o pilas. 2.6.2. Concepto de Sobrecarga. Tipos de sobrecarga. Sobrecarga en un lenguaje de programación es la capacidad que tiene para poder nombrar con el mismo identificador diferentes variables u operaciones. La sobrecarga de métodos se refiere a poder tener varios métodos con el mismo nombre, pero que realizan tareas distintas. Se usará uno u otro en función de los parámetros utilizados, ya que para que funcionen de forma correcta los métodos implicadas en la sobrecarga deben tener diferentes argumentos. Si se aplica un método u otro a un objeto producirá resultados diferentes. También existe la sobrecarga de operadores, que significa que un operador tiene más de una implementación. Sobrecarga en Java Java permite sobrecarga de métodos funcionando de la siguiente forma: se pueden varios métodos con el mismo nombre y diferentes colecciones de parámetros. Se ejecutará un método u otro en función de los diferentes parámetros de esta forma: • primero se busca un método que tenga la misma distribución de parámetros de la llamada, • sino existe ninguno, se intentan promover los parámetros a uno de orden superior (por ejemplo un parámetro int se intenta convertir en un long, un float en un double, etc) • Si realizando la anterior conversión, no se encuentra ningún método, el programador debe realizar un casting (convertir u tipo de datos en otro) de los parámetros para que coincidan con la definición de los métodos. No es lo mismo la sobrecarga de métodos que la redefinición. En esta última, un método heredado puede tener una redefinición, pero debe tener la misma

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

colección de argumentos que el original. Si hay un método redefinido, es el que se ejecuta siempre; si se desea ejecutar el método original (el de la clase de la que deriva) se debe usar la instrucción: super.nombre_metodo 2.6.3. Comparación entre genericidad y sobrecarga. Ambos mecanismos se pueden considerar como técnicas de reutilización de código. Con los sobrecarga de métodos, por ejemplo, varios métodos con el mismo nombre realizan acciones diferentes, siendo esto una facilidad sintáctica para los clientes y permite escribir el mismo código cliente. Con la genericidad, se pueden definir módulos parametrizados cuyos parámetros representan tipos, siendo esto una facilidad para los creadores de módulos (ya que permite escribir el mismo código al usar la misma implementación de un concepto, aplicado a distintos tipos de objetos) y los módulos clientes deben instanciar el modulo genérico.

2.7. Desarrollo orientado a objetos. 2.7.1. Lenguajes de desarrollo orientado a objetos de uso común. Los primeros lenguajes que poseen las características principales de un lenguaje orientado a objetos fueron Simula, fue usado a finales de los sesenta para hacer programas de simulación y el lenguaje Smalltalk, desde la década de los setenta se usó como ejemplo para explicar la teoría de la programación orientada a objetos, no fue hasta mediados de los años ochenta que esta programación empezó a hacerse popular sobre todo por la proliferación de interfaces gráficas de usuarios, para las que la POO es idónea. Desde entonces han ido apareciendo diferentes lenguajes de programación orientados, algunos de los cuales son: • Ada El estándar de este lenguaje se publico en 1983 y sus siglas son en honor a la primera programadora de la historia, Augusta Ada Byron. Lo diseñó la empresa Honeywell-Bull por encargo del Departamento de Defensa de Estados Unidos. Se tomó como base para la creación del lenguaje los lenguajes PL/I, PASCAL.

155

156

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

Entre sus características destacan compilación separada, los tipos abstractos de datos, programación concurrente y estructurada, mientras que su principal inconveniente es su gran extensión. Mientras que en otros lenguajes como Java es casi imposible trabajar con ellos sin programación orientada a objetos, en Ada, el programado elige cuándo usar esta metodología. En Ada las clases de objetos se representan por tipos abstractos de datos. Permite el polimorfismo. Un objeto se puede implementar como una instancia de una clase o también mediante un paquete en forma de máquina de estados abstracta. Un paquete de este tipo presenta en su especificación las los métodos del objeto. • Java: Es una de los lenguajes POO más usados y es el que se usa en estos puntos como ejemplo de este tipo de lenguajes. Desarrollado por la empresa Sun Microsystems en 1995. Dicha empresa seria absorbida por Oracle. La sintaxis de este programa parte de la de C y C++. • PHP: Lenguaje de código libre de propósito general del lado servidor, el cual a partir de su versión 5 incorporó características de lenguaje de programación orientado a objetos. • PowerBuilder: Es un software propietario de pago de la empresa Sybase y sus aplicaciones deben ser ejecutadas de forma exclusiva en el sistema operativo Windows. • Python: Es un lenguaje de código abierto y aparte de programación orientada a objetos, soporta también programación imperativa y programación funcional. Su máxima es ofrecer un código fácilmente legible e interpretable con una sintaxis muy limpia. Es multiplataforma y es un lenguaje interpretado. • Ruby: Se trata de un lenguaje de programación de código abierto orientado a objetos e interpretado .Fue creado por un programador japonés en 1993 y se basa en la sintaxis de Perl y Python. Sus características de POO parten de Smalltalk. • Otros lenguajes de POO: C++, C#,Visual Basic .Net (VB.NET), Delphi ffel, etc.

Ei-

2.7.2. Herramientas de desarrollo. Entre las herramientas de desarrollo existentes para facilitar el trabajo con los lenguajes de programación orientados a objetos destacan las siguientes:

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

• Eclipse Eclipse es un entorno de desarrollo integrado o IDE (Integrated Development Environment) que sirve para implementar los trabajos de edición, compilación y ejecución de los programas durante la fase de desarrollo, facilitando dichas tareas. Eclipse sólo proporciona el entorno de desarrollo, por lo que, según el lenguaje se necesitarán herramientas adicionales para compilar y ejecutar las aplicaciones (por ejemplo en Java se necesita el JDK). Se trata de una herramienta gratuita y de código abierto, lo cual facilita su mayor uso. Eclipse soporta varios lenguajes de programación siendo el más usado Java . • Rational El entorno de desarrollo RAD (Rational Application Developer), anteriormente conocido como WSAD (WebSphere Studio Application Developer) es creado por una división de IBM, basándose en Eclipse y soportando sus extensiones, a modo de compatibilidad. Sus herramientas permiten trabajar con Java, JSP,VB.Net, C#, Html, Uml, Xml, SQL y acceso a a bases de datos y servicios web entre otras tecnologías. 2.8. Lenguajes de modelización en el desarrollo orientado a objetos. 2.8.1. Uso del lenguaje unificado de modelado (UML) en el desarrollo orientado a objetos. El lenguaje UML cada vez se usa más en los lenguajes POO. Los elementos comunes a todos los diagramas de UML son: • Notas: Sirve para añadir un comentario a un diagrama o a un elemento del mismo. Se representa como un rectángulo con una esquina doblada con texto en su interior. Puede aparecer en un diagrama tanto sola como unida a un elemento por medio de una línea discontinua. • Dependencias: Una relación de dependencia entre dos elementos de un diagrama significa que un cambio en el elemento destino puede implicar un cambio en el elemento origen, por lo que si se modifica el destino se debería revisar el origen. Se representa por medio de una línea de trazo discontinuo entre los dos elementos con una flecha en su extremo, siendo el origen de la flecha el elemento dependiente es el origen de la flecha.

157

158

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

2.8.2. Diagramas para la modelización de sistemas orientados a objetos. Un diagrama de clases sirve para visualizar las relaciones entre las diferentes clases. Estas relaciones pueden ser de varios tipos: de herencia, de uso, asociativa, etc. Un diagrama de clases está compuesto por las clases (con sus atributos, y métodos) y las relaciones entre ellas. Las clases en un diagrama se representan como una caja dividida en tres partes: • En la parte superior se muestra el nombre de la clase • En la parte central los atributos • En la inferior los métodos. También se puede representar de forma esquemática suprimiendo atributos y métodos siendo entonces tan solo un rectángulo con el nombre de la clase. Nombre_Clase Atributos Métodos Para indicar la visibilidad de los atributos se emplean las siguientes notaciones: • Si el atributo es público y por tanto es visible desde cualquier clase, se usa el símbolo “+” • Si el atributo es privado y sólo puede ser accedido por métodos de la propia clase se usa el símbolo “-“ • Si el atributo es protegido y por tanto puede ser accedido por métodos de la propia clase, pero también por métodos de las subclases, se usa el símbolo “#”. La visibilidad de los métodos se indica con los mismos símbolos (“+” para métodos públicos, “-“ para métodos privados y “#” para métodos protegidos). Un objeto se representa por un una caja también pero en el compartimento superior de la misma se indica el nombre del objeto junto con el nombre de la clase subrayados, de esta forma: nombre_del_objeto:nombre_de_la_clase. Puede representarse sin nombre, en cuyo caso, sólo aparece el nombre de la clase con la sintaxis :nombre_de_la_clase.

Unidad didáctica 2. LA ORIENTACIÓN A OBJETOS

Con UML se puede representar de forma visual, las clases, los objetos, las clases abstractas, las relaciones entre clases, como agregación y asociación y en general todos los elementos de la programación orientada a objetos. Ejemplo de clase representada en UML y su equivalente código fuente: Telefono -color: String -precio: int #marcarnumero (numero: int) : void

public class Telefono { private String color; private int precio; protected void marcanumero (int numero); }

159

03 Arquitecturas web 3.1. Concepto de arquitectura web 3.2. El modelo de capas 3.3. Plataformas para el desarrollo en las capas servidor 3.4. Herramientas de desarrollo orientadas a servidor de aplicaciones web 3.4.1. Tipos de herramientas 3.4.2. Extensibilidad. Instalación de módulos 3.4.3. Técnicas de configuración de los entornos de desarrollo, preproducción y producción 3.4.4. Funcionalidades de depuración

162

Unidad didáctica 3. ARQUITECTURAS WEB

3. Arquitecturas web Un sistema de información web emplea la tecnología web para obtener la información y realizar la entrega de productos y servicios. Los sistemas y las arquitecturas de sistemas de información web deben: • Integrar diversas fuentes (como bases de datos) por arquitecturas multi-capa; • Ser extensibles para permitir la ampliación de su uso a nuevas tecnologías y formas de operación; • Gestionar información heterogénea tal como datos estructurados, documentos, etc; • Dar información sobre usuarios y su entorno (lo que se conoce como contexto); • Etc.

3.1. Concepto de arquitectura web. Igualmente que los arquitectos tradicionales coordinan y diseñan la construcción de edificios, los arquitectos web coordinan y diseñan el desarrollo de sitios web. Los sitios web son una mezcla compleja de sistemas integrados entre sí (como son servidores, redes, bases de datos, componentes de seguridad, etc). El resultado final será un sitio web que pueda resolver las necesidades del negocio: Servir las necesidades de los clientes y vender productos y servicios online. En el diseño de sitios web, al igual que en el diseño de edificios, se precisa de un amplio conocimiento de las tecnologías aplicadas. En el diseño de edificios estos conocimientos son sobre las propiedades de los materiales, mecánica, fontanería, electricidad, etc, y en el desarrollo web se requieren de conocimientos de lenguajes programación y estructura de bases de datos, el lenguaje HTML, el protocolo TCP/IP y muchos otros. En ambos casos se precisa tener conocimientos generales y ser un voraz estudiante de las tecnologías, ya que estas están en continuo desarrollo. Sin embargo, hay algo constante: debe ser usable por el público. Si no consiguen usarla fácilmente se irán de nuestra web y será un fracaso, desperdiciándose una

Unidad didáctica 3. ARQUITECTURAS WEB

gran oportunidad de negocio y un volumen de dinero. La misión del arquitecto web es asegurarse de que esto no ocurra. Los modelos arquitectónicos han evolucionado desde las antiguas aplicaciones de interfaz de entrada común, que permite a un cliente solicitar datos de un programa ejecutado en un servidor web, el paso por los JSP (Java Server Pages) y Servlets, el salto al Modelo Vista Controlador (MVC), a las aplicaciones multicanal y luego el modelo de capas que veremos en este capítulo. El uso de arquitecturas web dota de: • Escalabilidad, • Separación de responsabilidades, • Portabilidad, • Composición en componentes de los servicios de infraestructura, • Gestión de la sesión del usuario, cacheado de entidades, • Aplicación de patrones de diseño. La escalabilidad tiene una relevancia muy alta debido a la necesidad de realizar un correcto dimensionamiento de la aplicación, y esta característica de escalable dota al sistema de una adaptabilidad ante el incremento de la demanda. Se pueden realizar escalabilidades: • Horizontales: clonando al sistema y balanceando la carga; • Verticales: con una separación lógica entre capas, de forma que permita la separación física entre ellas; requiere un middleware; • Por cluster de servidores: que puede ser vertical y horizontal, y distribuye y escala el sistema de forma transparente para el usuario y administrador. Garantiza que, con independencia de la máquina que realice la petición http, habrá acceso a la sesión del usuario. Debemos introducir en este momento ciertas definiciones que son básicas para la creación de aplicaciones web, como son: • El modelo cliente/servidor es un modelo de comunicación de computadores en el cual el computador cliente solicita servicios al computador servidor por medio de mensajes. La diferencia entre el cliente y el servidor es que el cliente

163

164

Unidad didáctica 3. ARQUITECTURAS WEB

RECUERDE La definición de una arquitectura web nos servirá para tener presente y defender cómo funciona la aplicación web.

es el que inicia el contacto y el servidor es el que responde a dicha solicitud de conexión. • El middleware abarca todo el software distribuido que se necesita para dar soporte a las interacciones entre clientes y servidores. Es el enlace que permite al cliente obtener un servicio del servidor. Comienza en el módulo de API del cliente que se usa para invocar un servicio e incluye la transmisión de la solicitud por la red y su respuesta. No incluye el software que presta el servicio en si, ni a la interfaz de usuario. 3.2. El modelo de capas. El término arquitectura cliente/servidor es utilizado comúnmente para hablar de la arquitectura del software. De igual forma, los términos arquitectura en 2 y 3 capas se aplican al mismo concepto. Debe distinguirse entre ambos. Se entiende por arquitectura física a la topología de la aplicación. Independientemente de ésta, desde un punto de vista lógico, una aplicación puede ser dividida en componentes que denominamos capas. Estas son unidades altamente cohesivas, con responsabilidades de alto nivel, bien definidas y auto-contenidas. A la organización del software en términos de estos componentes le llamamos arquitectura lógica. Arquitectura cliente/servidor habla de la topología del software, mientras que decir que su arquitectura es en capas habla de su arquitectura lógica. Las aplicaciones de software incluyen tres aspectos fundamentales: • hacer que los datos sean persistentes (D), • procesar los datos de forma acorde a la lógica del negocio (L), • presentar los datos de forma adecuada a los usuarios (P). Las aplicaciones en una capa (P+L+D), donde no hay una separación lógica de estos tres aspectos, son muy grandes así como difíciles de distribuir y mantener y son incompatibles con la arquitectura cliente/servidor, son pesadas y consumen muchos recursos. Otro modelo que ya incluye distribución de las responsabilidades de la aplicación en dos unidades lógicas es la arquitectura en dos capas, que es presentada en la siguiente sub-sección.

Unidad didáctica 3. ARQUITECTURAS WEB

Por último, en la actualidad se tiende a desarrollar aplicaciones con arquitectura en tres capas, donde cada aspecto se corresponde a una unidad lógica. ARQUITECTURA EN DOS CAPAS Un arquitectura en dos capas distribuye la aplicación en dos componentes lógicos. Se definirá una división de responsabilidades entre los componentes de esta arquitectura. Esta arquitectura surge como consecuencia de la arquitectura cliente/servidor, y permite distribuir la carga que tiene la aplicación en dos computadores distintas, lo que hace distribuir las responsabilidades de la misma entre las dos unidades lógicas. Este modelo así como todas sus variantes, presenta unas desventajas, como son: • Incremento de la carga de la red: ya que el procesado de los datos se efectúa en el cliente hay mucha información que debe ser transmitida desde el servidor. • Se plasma la lógica del negocio. • La lógica de la aplicación no puede ser reutilizada, ya que está asociada al manejo de persistencia de datos o a la interfaz de usuario. • El PC procesa y presenta la información. Lleva a aplicaciones monolíticas, de difícil mantenimiento y caras. • Las estaciones de trabajo pueden tener recursos limitados. Los desarrolladores deben saber optimizar la aplicación de forma que pueda ser utilizada en entornos con recursos limitados. • Implica un procedimiento de distribución complejo, ya que si se cambian los PCs se debe actualizar. Es difícil garantizar que un cliente esté trabajando en una versión anterior. ARQUITECTURA EN TRES CAPAS La arquitectura en dos capas, con su evolución P/L+D, evolucionó hacia la arquitectura en tres capas. La lógica de negocios y el uso de persistencia serán una unidad que presenta importantes desventajas, como son: • el manejador de base de datos resulta pequeño y hay que migrarse a otro,

165

166

Unidad didáctica 3. ARQUITECTURAS WEB

• debe actualizarse la versión, • se quieren añadir datos de nuevas fuentes. En esta arquitectura la lógica de la aplicación se encuentra en una capa intermedia que está separada de los datos y de la interfaz de usuario (P/L/D). Los procesos pueden ser administrados y se despliegan de forma autónoma, sin que guarde relación con el manejador de base de datos y con la interfaz de usuario.Teóricamente los sistemas en tres capas son de más fácil ampliación y son más flexibles y robustos. Además permitirán integrar datos de múltiples fuentes. Los límites entre las capas son de carácter lógico, por lo que se pueden ejecutar las tres capas en la misma máquina. Lo más importante es que el sistema está estructurado y que cuente con una buena planificación de los límites entre todas las capas. • Presentación: tiene las responsabilidades lógicas de la presentación, tales como: • Validación de datos de entrada; • Formateo de los datos de salida; • Navegabilidad del sistema; • Internacionalización; • Etc. • Negocio: tiene las responsabilidades de lógica de negocio (o dominio) del sistema. Como resultado del análisis funcional da un conjunto de reglas de negocio que abstraen el mundo real. • Persistencia: sin ser necesariamente una base de datos relacional, comprende las responsabilidades de lógica de persistencia en las entidades del sistema en desarrollo, tales como: • Inserciones; • Eliminaciones; • Actualizaciones; • Búsquedas;

Unidad didáctica 3. ARQUITECTURAS WEB

167

• Etc. Ventajas de este modelo son: • Separación clara de la interfaz de usuario de la lógica de la aplicación. Esta separación permite tener diferentes presentaciones accediendo a la misma lógica; • La redefinición del almacenamiento de información no influye sobre la presentación; • En contraste con una arquitectura en dos capas, donde solamente los datos serán accesibles al público, los objetos de negocios pueden incluir servicios por la red; • Otras ventajas dependen de la distribución que tengan los componentes lógicos sobre los nodos físicos. 3.3. Plataformas para el desarrollo en las capas servidor. Cada capa de diseño constituye un área de la aplicación que tiene objetivos específicos; las tecnologías que se aplican en cada uno de ellos poder satisfacer sus requisitos, y acoplarse fácilmente a las tecnologías que se asocian al resto de las capas. JAVA Java es un lenguaje de programación orientado a objetos que fue creado por la compañía Sun Microsystems. Sun construyo Java partiendo de lenguajes orientados a objetos que ya existían, como era C++, sin ser compatible con ellos crearon otras funcionalidades y conceptos nuevos, como recolección de basura, programación multi-hilos y gestión de la memoria a cargo del lenguaje. Java fue diseñado para que realizar una ejecución segura de código a través de la red, para lo que se terminó con el uso de herramientas de C como los punteros. También se eliminaron otros conceptos que se demostró que no eran demasiado eficaces en la práctica, tales como sobrecarga de operadores, y herencia múltiple. Una de las claves de Java fue la portabilidad; para lograr que las aplicaciones se escriban en una sola vez, sin la necesidad de ser modificadas para que corran en otras plataformas. Esta independencia se logra tanto a nivel de código fuente como a nivel de código binario. La solución elegida fue el compilar el código fuente para generar un código intermedio (denominado bytecodes) que es igual para cualquier plataforma.

RECUERDE La característica principal del modelo de capas es la separación de responsabilidades del desarrollo.

168

Unidad didáctica 3. ARQUITECTURAS WEB

La JVM (Máquina Virtual de Java), que es donde se encuentra el intérprete Java, sólo tiene que interpretar estos bytecodes. JAVA DATABASE CONECTIVITY JDBC (Conectividad de Base de Datos) es un interfaz que incluye comunicación con bases de datos. Se forma por de un conjunto de interfaces y clases escritas en el lenguaje Java, que incluyen una API (Interfaz de Programación de Aplicación) estándar para los desarrolladores de herramientas de base de datos, dando independencia de la aplicación de la base de datos que usa. La API JDBC es la interfaz usada para las abstracciones y conceptos básicos de SQL (Lenguaje de Consultas Simple): permite la creación de conexiones, permite ejecutar sentencias SQL y permite también manipular los resultados logrados. Es similar a la ODBC (Conectividad de Base de Datos Abierta), pero ésta no será adecuada para ser usada de forma directa desde Java, ya que usa una traducción literal de C a Java y un interfaz en C que no son deseables. JDBC soporta dos tipos de acceso a base de datos: modelo de dos y tres capas. En el modelo de dos capas la aplicación Java se comunica directamente con la base de datos usando un controlador JDBC específico para cada DBMS (Sistema de Administración de Base de Datos) que se vaya a manipular. En el modelo en tres capas los comandos se envían a un capa intermedia de servicios, que se encarga de reenviar las sentencias SQL a la base de datos. Incluye también un controlador, el puente JDBC-ODBC, que realiza las operaciones de JDBC partiendo desde operaciones ODBC, así que se permite acceder a cualquier base de datos con un controlador ODBC disponible. SERVLETS Un servlet es una clase Java que se encuentra dentro del web server y se usa para extender la capacidad que tiene servidor. La API de servlets incluye interfaces y clases que permiten responder a cualquier tipo de requisitos; en concreto para las aplicaciones que corren en servidores web, la API define clases de servlet concretas para los requisitos HTTP. No precisan ser ejecutados como unos nuevos procesos debido a que corren directamente en el web server. Son persistentes y viven entre sesiones, no siendo

Unidad didáctica 3. ARQUITECTURAS WEB

necesario crear un servlet por cada requisito de cliente, sino que hay múltiples hilos corriendo dentro de éste. Los servlets son programas Java que permiten generar dinámicamente contenidos Web. Pueden ser ejecutados por medio de una línea de comando. A diferencia de los applets, no tendrán restricciones de seguridad. Tienen las propiedades de cualquier aplicación Java y acceden a los archivos del servidor para leer y escribir, cambiar propiedades del sistema, cargar clases, etc. Igual que las aplicaciones de programas Java, el uso de los servlets está restringido por los permisos del sistema. Los servlets se cargan la primera vez que se usan, y permanecen en memoria para satisfacer a los futuros requisitos. Cuentan con un método init, donde el programador inicializar el estado del servlet, y un método destroy que permite administrar los recursos que son mantenidos por el servlet. JAVA SERVER PAGES JavaServer Pages (JSP) es una tecnología Java que permite crear contenido dinámico en forma de archivos HTML, XML u otro tipo, para web. Al ejecutar una página JSP se traduce a una clase de Java, que se compila para poder obtener un servlet. Esta traducción y compilación sólo acontece cuando el archivo JSP es invocado por primera vez, o bien después de que ocurran cambios en él. JSP y XML tienen una interesante relación. De igual forma que pueden generarse páginas HTML dinámicas partiendo de una fuente en JSP, también pueden generarse dinámicamente documentos XML de la misma forma. EXTENSIBLE MARKUP LANGUAGE La familia XML se forma por un conjunto de especificaciones que conforman el estándar que va a definir las características de un mecanismo de forma independiente de plataformas, desarrollado para compartir datos. Se puede considerar XML como un formato de intercambio de datos multi-plataforma. El XML es un subconjunto del Lenguaje de Marcado Generalizado Standard (SGML), cuyo objetivo es permitir que se pueda servir el SGML genérico, que se recibe y procesa en la web, de igual forma que actualmente se realiza con HTML. XML fue diseñado de forma que sea sencillo de implementar. Este lenguaje se propone como lenguaje de bajo nivel (a nivel de aplicación, no siendo adecuado

169

170

Unidad didáctica 3. ARQUITECTURAS WEB

para la programación) usado para el intercambio de la información estructurada entre diversas plataformas. XML hace uso de etiquetas, las cuales usará sólo para delimitar datos y atributos, dejando la interpretación de los datos a la aplicación que realmente los utiliza. Por esto se forman lenguajes que parten del XML y, observándolo desde este punto de vista, XML se puede usar que es un metalenguaje. El conjunto de convenciones o reglas que impone la especificación XML va a permitir diseñar tipos de datos en forma formatos de texto para los datos estructurados, para conseguir que éstos se almacenen sin ambigüedad, de forma independiente de la plataforma y que en la recuperación se pueda verificar si la estructura es la correcta. Para comprobar que los documentos estén correctamente formados se utilizan los denominados Definición de Tipo de Documento (DTD), que se trata de una definición de los elementos que se pueden incluir en el documento XML, la relación entre ellos, posibles valores, sus atributos, etc. Se trata de una definición de la sintaxis del documento, al procesar cualquier tipo de información formateada por medio de XML, primeramente se ha de comprobar si está bien formada, para luego incluirla o referenciarla a un DTD, y comprobar que sigue sus reglas gramaticales.

EXTENSIBLE STYLESHEET LANGUAGE Lenguaje de Hojas de Estilo Extensible (XSL) es una especificación que se desarrolla dentro del World Wide Web Consortium (W3C) para dar formato a los documentos XML de una forma estandarizada. Aunque se ha establecido una forma para que puedan usarse hojas de estilo Hojas de Estilo en Cascada (CSS) dentro de los documentos XML, hace falta tener un estándar paralelo y similar asociado a él para aprovechar las características del nuevo lenguaje. Según el W3C, XSL es un lenguaje que permite transformar documentos XML, así como incluye un vocabulario XML que permite especificar una semántica de formateo de documentos. Además del aspecto que ya tenía CSS en lo relativo a la presentación y estilo de los elementos del documento, añade así una pequeña sintaxis de lenguaje de comandos que permite procesar los documentos XML más cómodamente. El XSL permite añadir lógica de procesado a la hoja de estilo.

Unidad didáctica 3. ARQUITECTURAS WEB

171

Se trata de asociar al documento XML una hoja de estilo, y partiendo de esto visualizar el documento XML para cualquier plataforma: PC, PalmPC, Internet Explorer, Firefox, etc. y con el aspecto elegido (fuentes, colores, etc). Así podemos considerar que XSL son dos lenguajes: uno de formateo y otro de transformación. El lenguaje de transformación permitirá transformar un documento XML en otro e diferente formato, como puede ser texto plano, HTML, o bien otro documento XML. El lenguaje de formateo es un vocabulario XML que permite especificar objetos de formateo. Al igual que con HTML también se pueden especificar las hojas de estilo, XSL, CSS y se puede realizar dentro del propio documento XML o bien referenciándolas de forma externa. Esto será muy útil para mover datos de una representación XML a otra representación diferente, basada en intercambio de datos electrónicos, correo electrónico, intercambio de metadatos, y alguna aplicación que tenga que convertir datos entre varias representaciones de XML a otro tipo de representación. La gran ventaja de utilizar XSL y XML es que los datos y su presentación quedan almacenados en dos archivos diferentes.

RECUERDE La elección de un lenguaje de programación debe ser basada en las necesidades del sistema y las características que ofrece cada uno de los lenguajes.

3.4. Herramientas de desarrollo orientadas a servidor de aplicaciones web. Las fases de un desarrollo web y los lenguajes de programación que puede usar son muy variados y por lo que se requieren herramientas específicas para cada fase. A continuación se explicarán las principales herramientas existentes que ayudan a desarrollar un proyecto web de forma sencilla. En el desarrollo web se cuenta con unas herramientas para el diseño, otras para la programación, otras para la depuración y otras para la maquetación. Todas las herramientas son muy importantes y por ello se deben elegir las más adecuadas a nuestras necesidades y capacidades. 3.4.1. Tipos de herramientas. Para desarrollar una web lo primero que debemos elegir es el Sistema Operativo que se usará, y su elección no es tan trivial. Para su elección se deben tener en cuenta las aplicaciones con las que cuenta el Sistema Operativo y sus costes. Para elegir las herramientas a usar, primeramente se deben identificar las fases del proceso que forman el ciclo de vida de un desarrollo web.

RECUERDE Además del propio lenguaje de programación existen herramientas en las que podemos apoyar el desarrollo de aplicaciones web.

172

Unidad didáctica 3. ARQUITECTURAS WEB

• Diseño: consiste en la creación de esbozos de la web final por medio de una herramienta gráfica, como GIMP, Photoshop o Inkscape. • Maquetación HTML/CSS: consiste en la transformación de los esbozos creados en la anterior fase en forma de plantillas HTML, su hoja de estilos, y las imágenes usadas. Dependiendo del dominio con el que se cuente de herramientas gráficas se puede saltar la fase anterior para comenzar directamente con esta. • Programación cliente: consiste principalmente en Javascript. Una web puede no precisar de programación cliente, como puede ser el caso de una pequeña web corporativa con escasa información estática, o puede requerir enormes esfuerzos, como ocurre con los proyectos Web 2.0. • Programación servidor: esta fase se desarrolla junto con la anterior se usa para crear la aplicación web en lenguaje de servidor, como por ejemplo ASP .NET, Python, PHP, Perl, etc. • Depuración: esta fase sirve de puente entre la fase anterior y la siguiente, y es donde realizaremos las pruebas unitarias, trazas, aserciones, etc. • Pruebas en local: se realizarán todas las pruebas posibles en nuestro servidor local.

RECUERDE El uso de herramientas contribuye a la creación de un software de calidad de una forma más fácil y eficiente.

• Subir ficheros al host: cuando nuestra web esté completada y bien probada en nuestro servidor local la subiremos al servidor del host elegido. Dependiendo del host, se podrá usar FTP, WebDAV, SFTP (SSH). • Pruebas en host: se realizarán las últimas pruebas en el servidor del host para probar que el cambio de servidor no ha alterado nada. Para evitar problemas el servidor local debe tener la misma configuración que el servidor del host. 3.4.2. Extensibilidad. Instalación de módulos.

RECUERDE El desarrollo de la aplicación web en forma modular tendrá las mismas ventajas que las definidas para el desarrollo software en general, dotando al sistema de dos grandes ventajas: la flexibilidad y la “ampliabilidad”.

Uno de los hitos más relevantes de la era Web 2.0 es la proliferación de APIs (Interfaces de Programación de Aplicaciones) bidireccionales. Una API incluye la forma de integrar diferentes aplicaciones de entornos variados. También permite la extensibilidad de los sistemas de su aplicación. En el entorno de la Web, por medio de la implementación de los Servicios Web, se convierte en una herramienta capaz de mover un sitio web a una red distribuida de sitios. Así mismo el desarrollo de aplicaciones web se realiza sobre el producto Web a medida por medio de módulos, con los servicios adicionales de programación a medida de los módulos web u otros servicios del soporte técnico.

Unidad didáctica 3. ARQUITECTURAS WEB

173

3.4.3. Técnicas de configuración de los entornos de desarrollo, preproducción y producción. Tener un entorno de trabajo completo y bien configurado es fundamental a la hora de enfrentarse a cualquier proyecto web. Se debe conocer las herramientas más adecuadas así como los diferentes sistemas operativos. Tras la elección del entorno de desarrollo y de las herramientas que se quieren usar, se debe proceder a: • Instalar las aplicaciones; • Configurar estas aplicaciones o módulos; • Instalar el software adicional; • Instalar el IDE (Eclipse, Netbeans, GVim…); • Instalar los depuradores; • Instalar las herramientas UML. Para estos cometidos la secuencia de instalación, así como las órdenes que deben ejecutarse para su instalación y configuración dependerán de las tecnologías que se usen.

RECUERDE El desarrollador deberá configurar adecuadamente el entorno de desarrollo que va a usar, así como deberá instalar todos los programas y herramientas necesarias para la creación de la aplicación.

3.4.4. Funcionalidades de depuración. Existen numerosas herramientas que permiten la depuración del código HTML, CSS, JavaScript y en general todas las tecnologías web. Estas herramientas, que se instalan como extensión en el navegador, lejos de quedarse en comprobar las entradas y salidas y errores en el código, comprueban además la existencia de código muerto (que no se ejecutará), comprobación de vínculos rotos, y en general ofrecer un análisis del rendimiento web para proceder a su mejora.

RECUERDE Los depuradores se centran en encontrar errores en el software, más allá de la sintaxis del código.

04 Lenguajes de programación de aplicaciones web en el lado servidor 4.1. Características de los lenguajes de programación web en servidor 4.2. Tipos y características de los lenguajes de uso común 4.2.1. Interpretados orientados a servidor 4.2.2. Lenguajes de cliente interpretados en servidor 4.2.3. Lenguajes compilados 4.3. Criterios en la elección de un lenguaje de programación web en servidor. Ventajas e inconvenientes 4.4. Características generales 4.4.1. Tipos de datos 4.4.2. Clases 4.4.3. Operadores básicos. Manipulación de cadenas de caracteres 4.4.4. Estructuras de control. Bucles y condicionales 4.4.5. Módulos o paquetes 4.4.6. Herencia 4.4.7. Gestión de bibliotecas (libraries) 4.5. Gestión de la configuración 4.5.1. Configuración de descriptores 4.5.2. Configuración de ficheros 4.6. Gestión de la seguridad 4.6.1. Conceptos de identificación, autenticación y autorización 4.6.2. Técnicas para la gestión de sesiones

4.7. Gestión de errores 4.7.1. Técnicas de recuperación de errores 4.7.2. Programación de excepciones 4.8. Transacciones y persistencia 4.8.1. Acceso a bases de datos. Conectores 4.8.2. Estándares para el acceso a bases de datos 4.8.3. Gestión de la configuración de acceso a bases de datos 4.8.4. Acceso a directorios y otras fuentes de datos 4.8.5. Programación de transacciones 4.9. Componentes en servidor. Ventajas e inconvenientes en el uso de contenedores de componentes 4.10. Modelos de desarrollo. El modelo vista controlador 4.10.1. Modelo: programación de acceso a datos 4.10.2. Vista: Desarrollo de aplicaciones en cliente. Eventos e interfaz de usuario 4.10.3. Programación del controlador 4.11. Documentación del software. Inclusión en código fuente. Generadores de documentación

176

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

4. Lenguajes de programación de aplicaciones web en el lado servidor En este apartado se van a estudiar lenguajes de programación de aplicaciones web en el lado servidor, explicando en primer lugar la diferencia con los lenguajes en lado cliente, sus tipos y sus características generales en varios aspectos para finalizar. Además se va a explicar cómo programar en un lenguaje concreto de aplicaciones web en el lado servidor que es PHP 5. De esta forma a cada concepto teórico, le acompañará, si corresponde, una descripción práctica de cómo programarlo en PHP 5. 4.1. Características de los lenguajes de programación web en servidor. Hay dos tipos de lenguajes de programación web: los lenguajes orientados a servidor y los lenguajes orientados a cliente. Los lenguajes de lado cliente son aquellos que no necesitan pasar por el servidor y que pueden ser tratados directamente por el cliente (el ordenador del usuario que está visualizando las páginas web). Estos lenguajes son independientes del servidor, por lo que la página puede ser albergada en cualquier lugar. El inconveniente de estos lenguajes es que el navegador o el ordenador donde se está visitando esa web debe tener instalados los plugins adecuados para su correcta visualización (los plugins típicos son los de Flash Player, Shockwave o Pdf). Otro de los inconvenientes de estos lenguajes es que el código fuente de las páginas web puede ser visualizado por cualquiera, lo cual es bastante inseguro. Ejemplos de lenguajes de cliente son Html, Vbscript y Javascript. Un lenguaje de programación web de lado servidor, es el que se ejecuta en el servidor web, inmediatamente antes de que se envíe la página a través de Internet al cliente. Las páginas que son ejecutadas en el servidor pueden realizar accesos a bases de datos, conexiones en red, y otras tareas hasta llegar a la página final visualizada por el cliente. Una vez realizadas todas las acciones en el servidor se devuelven las páginas al cliente en un formato comprensible para él. Una de las ventajas de estos lenguajes es que el código fuente de la página es tratado en el servidor y se devuelve al cliente adaptado para él, pero en ningún caso se puede visualizar el código fuente de la página, lo cual es mucho más seguro. Por el contrario, en este tipo de lenguajes, es muy importante el servidor donde se alojen las páginas, que tiene que ser compatible con ellas. Por ejemplo, si las páginas están escritas en PHP, deben ser alojadas en un servidor que cumpla con todos los requisitos para instalar la versión correcta de ese lenguaje. Más adelante se van a describir los principales lenguajes de este tipo.

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

4.2. Tipos y características de los lenguajes de uso común. 4.2.1. Interpretados orientados a servidor. Los lenguajes interpretados orientados a servidor son lenguajes que no necesitan traducirse a código máquina antes de empezar a tratarse, sino que se traducen mediante el intérprete a un lenguaje intermedio y cada instrucción es interpretada y traducida a lenguaje máquina en tiempo de ejecución. Ejemplos de lenguajes interpretados son Php, Java y Perl. 4.2.2. Lenguajes de cliente interpretados en servidor. Estos lenguajes son lenguajes de cliente que son enviados al servidor para ser interpretados, tras lo cual se envían de nuevo al cliente. Un ejemplo es Ajax. 4.2.3. Lenguajes compilados. Un lenguaje compilado es aquel en que una vez implementado, se traduce, instrucción a instrucción, de ese lenguaje al código máquina (el lenguaje de nivel más bajo que entiende un ordenador y que está formado por ceros y unos) para conseguir una rapidez mucho mayor, siendo el compilador ese traductor. Ejemplo de lenguaje compilado es C. 4.3. Criterios en la elección de un lenguaje de programación web en servidor.Ventajas e inconvenientes. A continuación se describen los lenguajes de programación web en servidor más usados junto con sus características principales, y sus ventajas y desventajas. ASP (Active Server Pages) Es un lenguaje comercializado por Microsoft. Para su correo funcionamiento hay que instalar Internet Information Server (IIS). Respecto a la estructura de un programa ASP, de forma somera se puede comentar: Además del código HTML habitual para las páginas Web, al crear las páginas ASP se puede elegir entre dos lenguajes de script para codificar los contenidos dinámicos:VBScript (el más usado y con origen en Visual Basic) y JScript (similar a JvaScript). El lenguaje elegido se indicará con una de estas sentencias:

177

178

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

<%@ LANGUAGE=”VBSCRIPT” %> <%@ LANGUAGE=”JSCRIPT” %> Las sentencias se codifican así: <% Sentencias %> Los comentarios en el programa se codifican mediante comilla simple, por ejemplo: <% ‘Ejemplo de comentario %> Todas las variables son de tipo variante por lo que no debe especificarse su tipo; si bien su declaración es opcional es recomendable realizarla con la palabra reservada Dim. Se pueden anidar varias declaraciones con separador “,”. Ejemplo de creación y asignación de variables en ASP:

<%@ LANGUAGE=”VBSCRIPT” %> <% Option explicit ’Se declaran tres variables Dim nombre_completo, fecha_nacimiento, numero_hijos ‘Se le asignan valores nombre = “Juan Rivas” fecha_nacimiento = “15/08/81” numero_hijos = 2 %> Ejemplo de página ASP <%@ LANGUAGE=”VBSCRIPT” %>

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

<HTML> <BODY> <% Dim nombre nombre = “ Juan Rivas “ %> <h2>Mi nombre es: <b> <%=nombre%></b></h2>%> </BODY> </HTML>

En ASP los objetos son programas compilados e instalados en el servidor, que se programan para realizar operaciones que sean accesibles por otras aplicaciones. Los 6 objetos por defecto de ASP son: • Request: Recoge la información recibida en las peticiones de usuario. Tambien permite el acceso a protocolos de comunicación cifrados. • Response: Devuelve una respuesta al cliente y permite que se acceda a las cabeceras HTTP de respuesta. • Application: Mantiene información compartida por las distintas sesiones establecidas en el servidor. • Session: Mantiene la información de cada sesión, que se almacena en el servidor al no guardar HTTP información entre peticiones. Esta información dura lo que dure la sesión, aunque se puede establecer un tiempo de inactividad, pasado el cual, la sesión se elimina. • Server: Permite crear objetos en el servidor entre otras funciones. • ASPError: Permite acceder a los errores en tiempo de ejecución para informar o corregir.

179

180

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

• Write: Envía información al navegador. Ejemplo de utilización de un objeto en ASP. Objeto Response

<%@ LANGUAGE=”VBSCRIPT” %> <HTML> <BODY> <% Dim nombre nombre = “ Juan Rivas “ ‘Se imprime el nombre de la variable y concatena strings usando VBSCRIPT Response.Write(“<h2>Mi nombre es: <b>” & nombre & “</b></h2>”) ‘Se imprime la cadena de texto entre comillas. ‘El mismo resultado que Response.Write utilizando el signo igual (=”Esta es mi primera página ASP”) %> </BODY> </HTML> Entre sus ventajas se encuentra que al usar Visual Basic Script, es fácil para los usuarios y que soporta JScript. Respecto a sus desventajas, se pueden citar que su código es desorganizado y extenso, que es un lenguaje propietario y que el hosting de sitios web es caro. ASP.NET ASP.NET es el sucesor de la tecnología ASP y ha servido para resolver algunos de sus problemas. Para su correo funcionamiento hay que instalar Internet Information Server (IIS) con el Framework .Net. A diferencia de ASP, ASP.Net ya no interpreta el código, sino que dentro del entorno NGWS (New Generation Windows Services) el código es compilado.

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

• Este lenguaje construye unas páginas denominadas web forms o formularios web , uno de los medios principales para el desarrollo de aplicaciones web. Estas páginas tiene extensión aspx y tiene tanto código HTML como XHTML estático. Si se desea colocar código dinámico se hace de forma similar a otros lenguajes dentro de un bloque <% - - %>. No se recomienda usar código dinámico, ya que necesita más llamadas en la carga de la página. Ejemplo de formulario web en ASP.NET

<%@ Page Language=”C#” %> <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”> <script runat=”server”> protected void Page_Load(object sender, EventArgs e) { Label1.Text = DateTime.Now.ToLongDateString(); } </script> <html xmlns=”http://www.w3.org/1999/xhtml” > <head runat=”server”> <title>Página de Ejemplo</title> </head> <body> <form id=”formulario1” runat=”server”> <div> <asp:Label runat=”server” id=”etiqueta1” /> </div> </form> </body> </html>

181

182

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

Se recomienda realizar programación dinámica con el modelo Code-behind : se coloca el código en un fichero aparte con nombre igual que el archivo aspx con la extensión correspondiente, por ejemplo, mipagina1.aspx.cs. Ejemplo de code-behind

<%@ Page Language=”C#” CodeFile=”MiEjemplo.aspx.cs” Inherits= “MiServidor.MiEjemplo” AutoEventWireup=”true” %>

Entre sus ventajas, caben destacar que está totalmente orientado a objetos, que posee una clara división entre código y diseño, que tiene controles de usuario y personalizados, mayor seguridad y velocidad así como más velocidad de respuesta del servidor y que es recomendable para grandes aplicaciones por su fácil mantenimiento. Por el contrario, como principal desventaja, está su alto consumo de recursos.

JSP (JavaServer Pages) Es un lenguaje desarrollado por Sun Microsystems y tiene un motor de páginas basado en los servlets de Java. Para que funcione es necesario instalar un servidor Tomcat, Glassfish, JSWDK o Sun Java System Web Server entre otros. En este lenguaje las páginas se compilan en la primera petición, separa la parte estática de la dinámica en las páginas web y el código JSP se puede inscrustar en código HTML. En una página JSP se puede incrustar código Java y directivas de control de parámetros del servlet y acciones de control de flujo. Los principales aspectos de la estructura de un programa JSP son: Ejemplo de código de una página JSP:

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

<%@ page errorPage=”myerror.jsp” %> <%@ page import=”com.foo.bar” %> <html> <head> <%! int serverInstanceVariable = 1;%> ... <% int localStackBasedVariable = 1; %> <table> <tr><td></td></tr> ...

JSP utiliza directivas, que son etiquetas a partir de las cuales se genera información que puede ser utilizada por el motor de JSP. Configurar cómo se ejecutará la página, por lo que su resultado no es visible para el usuario. La sintaxis de una directiva es: <%@ directiva atributo=”valor” %> Las directivas de JSP son: • include: Incluye el contenido de un fichero en la página mediante el atributo file. <%@ include file=”cabecera.html” %> • taglib: Importa librerías de etiquetas . <%@ taglib uri=”/tags/struts-html” prefix=”html” %> • page: Indica atributos de la página a procesar. Otro aspecto importante de JSP es el Script, que permite declarar variables,

183

184

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

funciones y datos estáticos. Los scripts son partes de código Java incrustados entre los elementos estáticos de la página. <% código Java %> <%! int maxAlumnosClase = 50; %> Las expresiones se evalúan dentro de la servlet. No deben acabar en “;”. En este ejemplo se pone como título de la página el atributo “nombre” contenido en el objeto request:

<% String titulo = “”; if (request.getAttribute(“titulo”) != null) { titulo = (String) request.getAttribute (“nombre”); } %>

Algunas de sus ventajas de JSP son que se trata de un lenguaje multiplataforma, robusto, seguro, con rápida ejecución de servlets e integración con módulos de Java. Su principal desventaja es la complejidad que requiere su aprendizaje.

PERL Perl (Practical Extraction and Report Language) fue desarrollado por Larry Well y creado a partir de herramientas de administración de sistemas Unix, como awk, sed y grep, gracias a lo cual uno de sus elementos más potentes es el tratamiento de expresiones regulares. Está basado en scripts y se usa mucho para escribir cgis (common gateway interface), scripts ejecutados en las páginas web. Además, la sintaxis de este programa facilita una programación rápida y poco limpio, pero funcional, lo cual lo hace ideal para hacer pruebas con algoritmos para comprobar su funcionamiento antes de programarlos en otro lenguaje más eficiente.

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

Sus principales ventajas es que es multiplataforma y soporta múltiples sistemas operativos como Unix y Windows, siendo los programas escritos en una plataforma compatibles con la otra. Además es un lenguaje script bastante rápido. Posee una gran cantidad de módulos que se pueden incorporar a cualquier script realizado en Perl y que están disponibles en el CPAN (Comprehensive Perl Archive Network). Quizás lo más importante para muchos programados es que es un software gratuito y libre, por lo que su código puede ser modificado y personalizado o adaptado según las necesidades. Sus desventajas son su lentitud para algunas aplicaciones, que se trata de un lenguaje interpretado y que utiliza más recursos que otros.

PHP PHP (Hipertext Preprocesor) es un lenguaje gratuito y libre e independiente de plataforma, con gran documentación y múltiples librerías y compatible con todos los navegadores, ya que el cliente sólo recibe una página con el código html resultante de la ejecución del programa PHP. Sus ventajas son su gran rapidez, su soporte para la orientación a objetos, que es muy fácil de aprender y que es multiplataforma. Además se puede usar para conectar con la mayoría de gestores de bases de datos. Aparte de éstas, como se ha comentado es libre y posee gran documentación, ejemplos y funciones ya realizadas. Sus principales desventajas son que todo el trabajo es realizado por el servidor, tiene código más difícil de leer al mezclar html y php y es difícil de organizar por capas de la aplicación. PHP es un poderoso lenguaje e intérprete, ya sea incluido como parte de un servidor web en forma de módulo o ejecutado como un binario CGI separado, es capaz de acceder a archivos, ejecutar comandos y abrir conexiones de red en el servidor. Estas propiedades hacen que cualquier cosa que sea ejecutada en un servidor web sea insegura por naturaleza. PHP está diseñado específicamente para ser un lenguaje más seguro para escribir programas CGI que Perl o C, y con la selección correcta de opciones de configuración en tiempos de compilación y ejecución, y siguiendo algunas prácticas correctas de programación.

185

186

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

4.4. Características generales. 4.4.1. Tipos de datos. Todos los lenguajes de programación web en servidor manejan los mismo tipos de datos de manera general: • Datos enteros, números sin decimales, positivos y negativos. • Datos decimales, de varios tipos según la precisión que proporcionan. • Datos de texto, según el lenguaje son cadenas de caracteres que se almacenan en un mismo tipo de dato o caracteres almacenados en arrays. • Lógicos o Booleanos: Son aquellos que sólo admiten dos valores: Verdadero y Falso. Sirven para usarse en comparaciones. • Arrays o matrices, son estructuras que almacenan un conjunto de datos con un mismo nombre. • Objetos: Aquellos lenguajes que estén orientados a objetos, manejan este tipo de datos ya tratados en un tema anterior. TIPOS DE DATOS EN PHP 5 En PHP 5 las variables comienzan por el símbolo del dólar y no necesitan ser declaradas antes de comenzar el programa, al contrario que sucede en otros lenguajes de programación. Los nombres de las variables no pueden empezar por número, pero pueden contener cualquier carácter alfanumérico y el guion bajo. PHP 5 es sensible a las mayúsculas por lo que las variables $variable1, $VARIABLE1 y $Variable1 son distintas. Existen varios tipos de datos que pueden ser asignados a las variables: • Entero (integer): permite almacenar números sin decimales. Estos números pueden ser positivos, negativos (añadiendo un signo menos delante del número) o cero. Se puede usar la notación decimal escribiendo el número sin más (por ejemplo 83), la notación octal anteponiendo un cero al número (por ejemplo 031) o la notación hexadecimal anteponiendo 0x al número (por ejemplo 0x25).La salida o impresión de los números se hace en decimal, aunque se haya asignado en otro sistema de numeración. • Coma flotante (double): para almacenar números decimales. Las operaciones

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

entre números enteros y de coma flotante dan como resultado un número de coma flotante. • Carácter (String): almacena texto que puede escribirse entre comillas dobles o entre comillas simples. La diferencia entre unas comillas y otras es que las simples imprimen el contenido literal de los caracteres encerrados y las dobles interpretan caracteres especiales. El caso más usado es el de las variables. Si se usa una variable $variable1 entre comillas doble imprime el literal $variable1, pero si se usa entre comillas dobles imprime el valor de $variable1. Existen algunos caracteres especiales que no se pueden añadir de forma directa a una variable de tipo String. Para poder añadirla y que la reconozca bien, se debe añadir una secuencia de escape (en PHP 5 es una barra invertida ,\). Ejemplo de secuencias de escape más comunes en PHP 5 \” Comillas dobles \’ Comillas simples \$ Símbolo de dólar \\ Barra invertida \n Nueva línea \r Retorno de carro \t Tabulador \f Salto de página

• Boolean: esta variable sólo tiene dos valores posibles: verdadero o falso. Se suele usar en condicionales. El valor 0 se considera falso y el valor 1 verdadero. Para asignar un valor a un valor boolean a una variable se debe usar las palabras claves TRUE (para variable con valor verdadero) y FALSE (para variable con valor falso) • Nulo (NULL): tipo especial de dato para indicar que no tiene valor. Una variable es considerada como null en uno de estos casos: si no ha sido definida con

187

188

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

ningún valor o si se le ha asignado la constante NULL o si ha sido eliminado su valor con la función unset. Estos primeros cinco tipos de datos son considerados simples en PHP 5. Ejemplo de tratamiento de datos simples en PHP 5

<? $numero_entero1=25; $numero_entero2=0x10; $numero_decimal=1.25; $cadena1=”125”; $cadena2=”Prueba de texto”; $variable_booleana=TRUE; $variable_nula=$NULL; echo (“El valor de numero_entero1 es $numero_entero1; el valor de \$numero_ entero2 es $numero_entero2 y el valor de cadena2 es $cadena2”); /* El resultado de la función echo anterior es que mostrará por pantalla el siguiente texto: El valor de numero_entero1 es 25; el valor de $numero_entero2 es 16 y el valor de cadena2 es Prueba de texto */ echo (‘El valor de numero_entero1 es $numero_entero1; el valor de \$numero_ entero2 es $numero_entero2 y el valor de cadena2 es $cadena2’); /* El resultado de la función echo anterior es que mostrará por pantalla el siguiente texto: El valor de numero_entero1 es $numero_entero1; el valor de \$numero_entero2 es $numero_entero2 y el valor de cadena2 es $cadena2*/ ?> • Vectores o arreglos (arrays): Conjuntos de datos • Objetos (object): Objetos en POO, es decir, conjunto de atributos y métodos independientes.

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

Para asignar un valor a una variable simplemente se usa el símbolo igual (=). Si el valor se incluye entre comillas, la variable se transforma en tipo String. 4.4.2. Clases. En aquellos lenguajes de programación web en servidor que sean lenguajes orientados a objetos, la teoría sobre clases, objetos, herencia etc. es la vista en el tema anterior de esta unidad formativa. CLASES EN PHP 5 Para definir una clase se usa la palabra reservada class. Dentro de la clase, los atributos se definen con la palabra reservada var y los métodos con la palabra function. Cuando se define un atributo de la clase se debe indicar el tipo de atributo con una de estas tres palabras reservadas: • public: Se define el atributo como público, ya que esta palabra indica que el atributo puede ser accedido (y modificado) desde cualquier parte del programa. Por compatibilidad con versiones anteriores de PHP, si se usa la palabra var es interpretado como un alias de public. • private: Especifica que sólo la clase especificada puede acceder a ese atributo. Incluso las clases que hereden de ésta, no tendrán acceso al mismo. Se está encapsulando la información, de tal forma que el valor de ese atributo sólo puede ser accedido mediante métodos incluidos en su propia clase. • protected: Similar a prívate pero permite el acceso a las subclases, es decir, el atributo puede ser accedido por la misma clase y sus clases heredadas. 4.4.3. Operadores básicos. Manipulación de cadenas de caracteres. En todos los lenguajes de programación de lado servidor existen varios operadores básicos divididos según su uso: • Operadores aritméticos: Sirven para realizar las operaciones matemáticas con datos numéricos, variables o constantes. Ejemplo de operadores aritméticos son suma, resta, multiplicación, módulo (resto de la división entera), etc. • Operadores de comparación: Se usan para comparar expresiones. El resultado de la comparación va a ser un tipo de dato booleano, es decir, la comparación

189

190

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

va a ser verdadera o falsa. Ejemplo de estos operadores son “es igual”, “es distinto”, “es mayor”, ”es menor”, “es mayor o igual”, etc. • Operadores lógicos o booleanos: Se usan con expresiones que devuelven valores lógicos, verdaderos o falso. Los más usados de estos operadores son: • El operador negación: Se aplica sobre una expresión y devuelve lo contrario en valor booleano de ésta. Es decir, si la expresión es verdadera, devuelve falso y si es falsa, devuelve verdadero. • El operador Y, que evalúa dos expresiones. Sólo si ambas expresiones son verdaderas, el resultado es verdadero. En el caso de que alguna de las expresiones sea falsa, el resultado es falso. • El operador O, que también evalúa dos expresiones. El resultado es verdadero si alguna de las dos expresiones sale verdadera. Sólo devuelve valor falso en el caso de que ambas expresiones evaluadas sean falsas. Ejemplo de los posibles casos y resultados del operador Y. Expresión 1

Expresión 2

Resultado: Expresión 1 Y Expresión 2

FALSO

VERDADERO

FALSO

VERDADERO

FALSO

VERDADERO

Ejemplo de los posibles casos y resultados del operador O. Expresión 1

Expresión 2

Resultado: Expresión 1 O Expresión 2

FALSO

VERDADERO

FALSO

VERDADERO

FALSO

VERDADERO

Se ha puesto el caso de dos expresiones, pero en el caso de más de dos expresiones funcionarían igual estos operadores: el operador Y sólo devuelve verdadero si todas las expresiones son verdaderas y el operador O sólo devuelve falso si todas las expresiones son falsas.

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

• Manipulación de cadenas de caracteres: Según el lenguaje y la operación, puede tratarse operadores o métodos (funciones). Las operaciones más comunes suelen ser: búsqueda dentro de una cadena, extraer subcadenas, comparación de cadenas, concatenación de cadenas, conversión mayúsculas-minúsculas, etc. RESUMEN OPERADORES ARITMÉTICOS EN PHP 5 Operador

Nombre

Descripción

Ejemplo

Suma

Suma variables

$var1+$var2

Resta

Resta variables

$var3-$var4

Multiplicación

Producto de variables

$var5*$var6

División

Cociente de dos variables

$var7/$var8

Módulo

Resto de la división entera

5%3 da como resultado 2

Incremento

Suma 1 al valor de la variable

$var9++

Decremento

Resta 1 al valor de la variables

$var10--

RESUMEN OPERADORES DE COMPARACIÓN EN PHP 5 Operador

Nombre

Ejemplo

Resultado

Igualdad

$v1==$v2

Devuelve TRUE si $v1 y $v2 son iguales

===

Identidad

$v1= = =v2

Devuelve TRUE si $v1 y $v2 son iguales y del mismo tipo

!= o <>

Distinto

!==

No idéntico

Menor

$v1<$v2

Devuelve TRUE si $v1 es menor que $v2

Mayor

$v1>$v2

Devuelve TRUE si $v1 es mayor que $v2

Menor o igual

$v1==$v2

Devuelve TRUE si $v1 es menor o es igual que $v2

Mayor o igual

$v1==$v2

Devuelve TRUE si $v1 es mayor o es igual que $v2

$v1!=$v2 o $v1<>$v2 $v1!= = $v2

Devuelve TRUE si $v1 y $v2 son distintos Devuelve TRUE si $v1 y $v2 son distintos o sino tiene el mismo tipo

191

192

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

RESUMEN OPERADORES LÓGICOS EN PHP 5 Operador

Nombre

Ejemplo

Resultado

Y o &&

expr1 && expr2 o expr1 Y expr2

Devuelve TRUE si las dos expresiones son verdaderas

O o ||

expr1 || expr2 o expr1 O expr2

Devuelve TRUE si una de las dos expresiones o las dos, don verdaderas

xor

O exclusivo

Negación

expr1!=expr2 o expr1<>expr2 expr1!= = expr2

Devuelve TRUE si una expresión es verdadera y la otra es falsa Devuelve TRUE si la expresión es falsa

MANIPULACIÓN DE CADENA DE CARACTERES EN PHP 5 Algunas de las funciones usadas en el tratamiento de cadenas de caracteres en PHP 5 son éstas: • strlen (cadena): Devuelve la longitud de la cadena de caracteres que se le pasa como argumento. • strstr(cadena, cadenaBuscada): Busca la aparición de la cadena pasada como segundo argumento (cadenaBuscada) dentro de la cadena pasada como primer argumento (cadena) y devuelve la subcadena comprendida entre la primera aparición cadenaBuscada hasta el final de cadena. La búsqueda distingue entre mayúsculas y minúsculas. La función stristr es simular pero sin hacer esa distinción. • strpos (cadena1, cadena2, desplazamiento): Busca, diferenciando entre mayúsculas y minúsculas, la primera aparición de cadena2 dentro de cadena1 y devuelve la posición numérica de esa aparición (es decir, si cadena2 aparece en el tercer carácter devuelve un 2, ya que se empieza a contar en 0). El argumento desplazamiento indica a partir de qué posición dentro de cadena1 se debe empezar a buscar. Si desplazamiento se omite, la posición es la inicial, la cero.

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

• strcmp (cadena1, cadena2): Compara las dos cadenas y devuelve un valor negativo si la segunda es mayor que la primera, un valor positivo si la primera es mayor que la segunda y devuelve un cero si ambas cadenas son iguales. -strtolower (cadena1): Convierte la cadena cadena1 recibida como argumento en minúsculas. • strtoupper (cadena1): Convierte la cadena cadena1 recibida como argumento en mayúsculas. 4.4.4. Estructuras de control. Bucles y condicionales. ESTRUCTURAS DE ELECCIÓN O CONDICIONALES (SI..SINO) En estas estructuras, se evalúa una expresión, que puede ser verdadera o falsa, y en función del resultado se realizan unas u otras acciones. Esta estructura de selección simple puede anidarse para realizar múltiples elecciones. ESTRUCTURA IF EN PHP 5 La sintaxis de esta estructura es if (condicion) instruccion; Si la condición se cumple, es decir, es verdadera, se ejecuta la instrucción; en caso de que nos e cumpla, es decir que sea falsa, no se ejecuta nada. Si se quiere que se ejecuten varias instrucciones, se deben poner entre llaves: if (condicion) { instruccion1; instruccion2; instruccion3; .. instruccion n; }

193

194

Unidad didรกctica 4. LENGUAJES DE PROGRAMACIร N DE APLICACIONES WEB EN EL LADO SERVIDOR

al igual que antes, si se cumple la condiciรณn, se ejecutan todas las instrucciones entre llaves y si no se cumple, nos e ejecuta nada. ESTRUCTURA IF-ELSE EN PHP 5 Si se quiere que se ejecuten instrucciones si la condiciรณn se cumple y otras en caso de que nos e cumpla se usa la estructura if-else de la siguiente forma: if (condicion){ instruccion 1; instruccion 2; .. instruccion n; } else { instruccion1else; instruccion2else; .. } Si la condiciรณn es verdadera se ejecutan las instrucciones del primer bloque de llaves y si es falsa, se ejecutan las instrucciones del segundo bloque de llaves. ESTRUCTURA ELSEIF EN PHP 5 Si se desean hacer comparaciones en cascada se usa la siguiente sintaxis de con elseif anidados: if (condicion1){ instruccion1;

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

195

} elseif (condicion2) { instruccion2; } elseif (condicion3) { instruccion3; } else { instruccion4; }

En este ejemplo, si se cumple la condicion1, se ejecuta la instruccion1 y el programa se para (no se comprueban el resto de instrucciones ya que se ha cumplido la primera). Si no se cumple la condicion1, se evalúa condicion2 y si es verdadera, se ejecuta instruccion2 y el programa se para. Si condicion2 no se cumple, se evalúa condicion3 y si es verdadera, se ejecuta instruccion3 y se para el programa. Si condicion3 no se cumple, al ser el último if, se ejecuta directamente la instruccion4. En el anterior ejemplo se ha escrito una sola instrucción

ESTRUCTURA SWITCH EN PHP 5 Esta estructura evalúa una expresión que suele ser una variable y en función de los posibles valores que pueda tomar se ejecutan unas instrucciones u otras. Ejemplo:

switch (expresión){ case valor1: instruccion1valor1; instruccion2valor1; …

Importante En una estructura elseif anidada en el momento que se cumple una condición no se evalúan las demás.

196

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

break;

case valor2: instruccion1valor2; instruccion2valor2; …

break;

case valor3: instruccion1valor3; instruccion2valor3; …

break;

default: instruccion1default; instruccion2default; … }

En este ejemplo, si la expresión toma el valor1 se ejecutan las instrucciones del primer bloque (desde isntruccion1valor1 hasta el primer break). La palabra reservada break sirve para interrumpir el programa y que no siga evaluando. Si la expresión en lugar de tomar el valor1, toma el valor2 o el valor3, igualmente se ejecutan las instrucciones correspondientes (desde el case correspondiente hasta el siguiente break). En caso de que la expresión no tome ninguno de los valores de los case, se ejecuta el bloque de instrucciones tras default. Este bloque no tiene break ya que finaliza con la llave de cierre.

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

197

BUCLES (REPETIR, MIENTRAS, PARA) Los bucles son estructuras de control que permiten repetir varias veces las mismas instrucciones hasta que se cumpla una condición o hasta que se repita un número determinado de veces. BUCLE WHILE EN PHP 5 El bucle while evalúa una condición al principio y si se cumple se ejecutan todas las instrucciones el bucle y se vuelve a evaluar la condición. Este bucle se repite hasta que la condición deje de cumplirse.

while (condición) { instruccion1; instruccion2; … instrucción n; } ya que la condición se evalúa al principio, si la condición no se cumple al llegar al bucle, el bucle no se ejecuta.

BUCLE DO-WHILE EN PHP 5 Este bucle es muy similar al anterior con la salvedad de que la condición se evalúa al final de las instrucciones. De esta forma, las instrucciones del bucle se ejecutan al menos una vez. do { instruccion1; instruccion2; …

Importante En todos los bucles la condición debe poder llegar a ser falsa, ya que si no el bucle se repetiría indefinidamente, a esto se llama bucle infinito.

198

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

REFLEXION

instrucción n;

Aunque los bucles do-while y while, son muy similares ¿es siempre lo mismo usar uno que otro o hay circunstanciaos más favorables para uno de los dos según el programa?

} while (condición) ;

BUCLE FOR EN PHP 5 La sintaxis de este bucle es la siguiente:

for (expresión inicial; condición de finalización; expresión de fin){ instruccion1; instruccion2; .. instruccion n }

El funcionamiento es el siguiente: -la expresión inicial se ejecuta una sola vez al principio del bucle -la condición de fin se evalúa cada vez que se ejecuta el bucle; si esta expresión se cumple, se continua con la ejecución del bucle y si es falsa se para -la expresión de fin se ejecuta tras cada ejecución del bucle y sirve para que se pueda cumplir la condición de fin y evitar un bucle infinito que se repita indefinidamente. Un ejemplo más concreto en PHP 5 sería el siguiente: for ($contador=1; $contador<=10; $contador++){ echo (“numero $contador”); }

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

En este ejemplo la expresión inicial es la inicialización de la variable $contador a 1 y la condición de fin es $contador<=10. Dicho de otra forma este bucle funciona así: se le asigna el valor 1 a la variable contador, como obviamente no se cumple la condición de fin, se ejecuta el bucle una vez, se ejecuta la expresión de fin (es decir $contador pasa a valer 2) y se vuelve a evaluar la condición de fin, como sigue siendo falsa, se vuelve a ejecutar el bucle y así hasta que la variable contador vale 10, momento en el que la condición de fin sigue siendo verdadera, se ejecuta el bucle una vez más, se incrementa en uno la variable $contador, con lo que pasa a valer once, tras lo cual la condición de fin es falsa y se para el bucle. Resumiendo, este bucle se ejecuta diez veces (desde que $contador vale uno hasta que vale diez) e imprime por pantalla “numero 1”, “numero 2” y así hasta “numero 10”. Este es un típico ejemplo de uso de bucle for: cuando se saben el número de iteraciones que se desean ejecutar, por ejemplo, si se desea hacer una tabla de multiplicar. 4.4.5. Módulos o paquetes. El concepto de módulo o paquete estos lenguajes de programación web en servidor es el mismo que en Programación Orientada a Objetos. Un paquete contiene un conjunto de clases relacionadas entre sí. Dependiendo del lenguaje, éste vendrá preparado para gestionar los paquetes directamente o se deberá hacer alguna emulación. En el caso de PHP aún no está preparado pero se puede simular el comportamiento de paquetes a través de la función import. 4.4.6. Herencia. El concepto de herencia es el visto en POO: la relación que se da entre dos clases, en las cuales una de ella, la clase hija, además de tener sus propios métodos y atributos, hereda loa s de la otra, la clase padre. HERENCIA EN PHP 5 En PHP 5 para que una clase pueda heredar las características de otra, tiene que usar en su declaración la palabra reservada extends seguida del identificador de la clase superior.

199

REFLEXION ¿Se puede hacer lo mismo que con un bucle for que con un bucle while?

200

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

Ejemplo de herencia en PHP 5

<? class Clase_Superior { … } class Clase_Hija extends Clase_Superior{ .. } .. ?>

Al definir una clase hija, los métodos de la clase padre son automáticamente heredados. La redefinición de métodos consiste en crear métodos en la clase hija con el mismo nombre que en la clase padre. En PHP 5 se pone delante de cualquier método la palabra reservada final, ese método no podrá ser sobrecargado en las clases que lo hereden.También es posible declarar clases completas como final, lo que significa que no podrán ser heredadas. Si se intenta sobrecargar un método marcado como final, aparece un error en pantalla: Fatal error: Cannot override final method. Aunque PHP 5 no permite herencia múltiple (heredar de varias clases a la vez), si que permite la herencia encadenada, que significa que se puede heredar de varias clases padres correlativamente. Ejemplo de herencia encadenada en PHP 5

class X { } class Y extends X{ }

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

class Z extends Y { }

4.4.7. Gestión de bibliotecas (libraries). Una librería es una colección de funciones almacenadas en un archivo que sirve para que puedan reutilizarse en múltiples programas esas funciones. Para hacerlo, se debe “cargar” en el programa esa biblioteca y una vez “cargada” se pueden usar cualquiera de sus funciones. FUNCIONES Y BIBLIOTECAS EN PHP 5 En PHP 5 las funciones (o métodos) se definen de la siguiente forma:

function nombre_funcion ($argumento1, $argumento2,$argumento3….){ instruccion1; instruccion2; .. instrucción n [return (valor_devuelto)] }

Como se comentó en POO, los argumentos son cada una de las variables que necesita la función para efectuar su trabajo. Se debe invocar a la función con el mismo número y tipo de argumentos que en la definición. Si es una función que devuelve un valor ese valor es devuelto a través de la instrucción return. Cuando se crea una función, luego puede ser de utilidad en otro programa. Para hacer eso los pasos a seguir son:

201

202

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

Guardar las funciones que se deseen usar más adelante en un fichero de extensión .php, .inc, etc. A estos archivos se les llamará bibliotecas. Usar en la web en las que se quiera usar las directivas include() o require() La diferencia entre include() y require() en PHP 5 es que include() es más tolerante a fallos y permite que se pueda seguir ejecutando el programa aunque se encuentre un fallo. En cambio require() para si encuentra un fallo crítico. Puede pasar que en un mismo proyecto se hagan varias inclusiones del mismo archivo con funciones desde varios sitios. Para evitar que se carguen múltiples veces el mismo archivo (y por tanto se ejecute una carga innecesaria de memoria) existen las funciones equivalentes include_once() y require_once(). En estas funciones si se intenta incluir un fichero varias veces se ignorará. Con el siguiente ejemplo se puede ver más claro el comportamiento de estas funciones, Se van a usar tres archivos que luego se van a unir. Archivo 1 : cabecera.php : <html> <head> <title> Ejemplo de uso includes </title> </head> <body> Archivo 2: pie.php : </body> </html> Archivo 3: union.php : <? include(“header.php”); ?> <p> Contenido de la web

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

</p> <? include(“footer.php”); ?> El resultado que visualizaría el usuario sería <html> <head> <title> Ejemplo de uso includes </title> </head> <body> <p> Contenido de la web </p> </body> </html>

4.5. Gestión de la configuración. 4.5.1. Configuración de descriptores. En programación, los ficheros no se identifican por nombre o ruta, sino que son una zona de memoria que queda identificada por su dirección e memoria inicial. Para acceder a esa dirección se usa un puntero (un dato que contiene una dirección de memoria); se dice que el puntero apunta a la dirección de memoria del fichero o que apunta al fichero. A ese puntero se le llama descriptor. Cuando un lenguaje de programación, como PHP 5, trabaja con ficheros realmente trabaja con los descriptores del mismo.

203

204

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

4.5.2. Configuración de ficheros. Las principales operaciones sobre ficheros son la apertura, lectura, escritura y cierre del fichero. Se debe tener en cuenta a la hora de trabajar con ficheros que se debe comprobar que cada operación se realiza de forma correcta y programar lo que ocurre si la operación falla. Por ejemplo, si se abre un fichero y falla esta operación (por no existir el fichero, por no tener permisos, etc.), no se podrá leer del mismo, por tanto, con una estructura condicional habría que distinguir los dos casos : si el fichero se abre correctamente, en cuyo caso se leería, y si el fichero no se puede abrir , en cuyo caso, podría salir un mensaje de texto indicando esta circunstancia. Se van a describir las principales acciones sobre ficheros aplicadas a PHP 5 y cómo implementarlas: APERTURA DE UN FICHERO Se usa la función fopen(), la cual asigna a una variable un descriptor al fichero que se desea abrir. Esta variable se usa posteriormente para cualquier operación con ese fichero. Si no es posible abrir el fichero, bien porque no exista o porque exista pero no se pueda abrir, la función fopen() devuelve un valor false. En ese caso, mediante un condicional hay que tratar ese caso y hacer que aparezca un mensaje de error o simplemente parar con el programa; si no se verifica si se puede abrir el fichero y se siguen con las operaciones, el sistema emite un mensaje de error. Existen distintos modos de apertura de un fichero: • Modo lectura y escritura (r+): Si el fichero existe, con este modo se puede leer y escribir en él. • Modo escritura y lectura aunque el fichero no exista (w+): Parecido al anterior, pero en este caso no es necesario que el fichero exista. Si no existe, lo intenta crear. • Modo solo lectura (r): Solo se puede leer. • Modo solo escritura (w): Solo se puede escribir. • Modo lectura y escritura al final (a+): Se puede leer y se escribe siempre al final, es decir, se añade pero no se puede editar.

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

• Modo escritura al final (a): Permite añadir datos al final del fichero pro no editar los existentes. LECTURA DE UN FICHERO La función fread() usada para este propósito acepta como parámetro el descriptor del fichero, que ha sido devuelto por la función fopen() y el tamaño de datos que se desea leer. Para conocer el tamaño de un fichero se puede usar la función filesize() ESCRITURA DE UN FICHERO La función fwrite() escribe en un fichero , que está apuntado por un descriptor, una cadena de caracteres. Evidentemente, si el fichero no ha sido abierto en uno de los modos de escritura indicados, se produce un error. Otra función equivalente a fwrite() es fputs(). Ejemplo de lectura y escritura de un fichero en PHP 5

<? //Apertura del fichero en modo lectura $fichero1=fopen(“fichero_lectura.txt”, “r”); //Se valida que se ha abierto en modo lectura de forma correcta if($fichero1){ //Se lee todo el fichero usando filesize para conocer su tamaño $contenido = fread($fichero1, filesize(“fichero_lectura.txt “)); //Se saca por pantalla el resultado echo $contenido;

205

206

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

//Se abre un segundo fichero en modo escritura

$fichero2=fopen(“ficherofinal.txt”, “w”);

if($fichero2){ //validamos que se ha realizado correctamente /* Se escribe en el segundo fichero el contenido leído del primer fichero */

fputs($fichero2, $contenido);

} else {

echo (“no se ha podido abrir el fichero de escritura”);

fclose($fichero2); } else {

echo (“no se ha podido abrir el fichero de lectura”);

} fclose($fichero1); //Cerramos el archivo ?>

4.6. Gestión de la seguridad. 4.6.1. Conceptos de identificación, autenticación y autorización. Se van a definir y explicar estos conceptos que a veces se confunden y explicar de forma somera su implementación en PHP 5. IDENTIFICACIÓN Es el proceso por el cual el usuario se da a conocer al sistema, por ejemplo, introduce sus datos de acceso en u formulario y pulsa el botón enviar.

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

En PHP 5 se suelen usar formularios para este fin. AUTENTICACIÓN Es un proceso en el que se comprueba la identidad de alguna persona o algún objeto, mediante unas pruebas llamadas credenciales. Por ejemplo, si se desea comprobar la identidad de alguien en un formulario se le pide como credenciales su nombre de usuario y password (el usuario se identifica) y se autentica contra una base de datos donde estarán guardadas los logins y contraseñas de todos los usuarios del sistema. En PHP 5 se usa el acceso a base de datos con MySQL para este fin. AUTORIZACIÓN Es el proceso por el que, una vez comprobadas las credenciales, se determinan los derechos de acceso a los recursos tanto al recurso como a los permisos que se tiene dentro de él, ya que un usuario puede tener acceso a un recurso en modo lectura y otro usuario puede tener acceso al mismo recurso en modo escritura). Esos derechos se pueden determinar usando listas de control de acceso o ACL. En PHP 5 se suele usar para este fin las sesiones, cookies y otros mecanismo más avanzados, por ejemplo certificado SSL o métodos personalizados.

4.6.2. Técnicas para la gestión de sesiones. Las variables mantienen su valor durante la ejecución del programa, pero al cambiar de página, las variables desaparecen. Pero a veces interesa que una variable mantenga su valor para cada usuario, no sólo en la ejecución de un programa, sino en toda la visita a la web, o dicho de otra forma, en la visita a todos los archivos del dominio de la página web. Este periodo de tiempo que dura esa visita se llama sesión y la gestión de las sesiones es uno de los aspectos más importantes en lenguajes de programación orientados a servidor. SESIONES EN PHP 5 Para utilizar sesiones en PHP 5 se debe llamar a la función session_start() al principio de la página, antes de cualquier salida que se muestre en pantalla y se usa la variable superglobal $_SESSION para almacenar valores.

207

208

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

En el siguiente ejemplo de dos páginas, en una se define la variable de sesión y en la otra se trabaja con su valor. Ejemplo página donde se define la variable de sesión: <?php session_start(); $_SESSION[‘login’] = ‘usuario1’; ?> Ejemplo de página donde se trata la variable de sesión. <?php session_start(); echo “El login es: “.$_SESSION[‘login’]; ?>

Para poder almacenar los valores en $_SESSION se tiene que haber llamado antes a la función session_start() , ya que si no, no funcionaría. FUNCIONES PARA EL MANEJO DE SESIONES EN PHP 5 Las principales funciones para el manejo de sesiones son: • La función session_start() inicia una sesión y permite almacenar valores de la misma en $_SESSION. • La función session_destroy() sirve para eliminar todos los datos asociados a la sesión actual. • Si necesitamos conocer el nombre de la sesión, que usualmente es PHPSESSIONID se llama a la función session_name().

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

• Si en lugar del nombre, necesitamos el identificados de 32 caracteres de la sesión, la función session_id() los devuelve. • La función session_is_registered()(string nombre), acepta por parámetro el nombre de una variable y comprueba si esa variable está registrada en la sesión actual en cuyo caso devuelve TRUE y en caso contrario FALSE. COOKIES Una cookie es una información que se almacena en el ordenador del usuario que visita una página web. Esta información está codificada y contiene siempre un nombre y un valor. Un ejemplo típico de uso de cookies es para guardar las preferencias de navegación de un usuario dentro de un sitio web. Si un portal de contenido tienes diferentes secciones (cine, motor, deportes, moda…) la cookie va a almacenar qué apartados ha visitado el usuario para, por ejemplo, ofrecerle un banner de publicidad de una temática u otra cuando vuelva a visitar la página (si el usuario no ha borrado ese cookie). Las cookies se almacenan a través del navegador el ordenador del cliente, por lo que, aunque éste no puede ver su contenido al estar codificado, si que puede eliminarlas, manualmente o programándolo. Además, según el navegador, hay un número limitado de cookies por dominio o sitio web que se pueden almacenar. COOKIES EN PHP 5 En PHP 5 la función setcookie se encarga de registrar las cookies y para recuperar el valor se usa la variable superglobal $_COOKIE. Los argumentos que admite la función setcookie() son: • El nombre de la variable cookie • El valor que almacena • El tiempo de vida de la cookie representado por un número entero. Si el número es cero, la cookie nunca “muere”. • La ruta del servidor desde donde se lama a la cookie • El dominio de servidor que puede leer la cookie.

209

210

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

Para borrar una cookie se llama a la función setcookie() pero con el parámetro valor vacío, que hace que se elimine. 4.7. Gestión de errores. 4.7.1. Técnicas de recuperación de errores. Todo lenguaje de programación web orientado a servidor debe tener unos mecanismos para gestionar, manejar y recuperarse de errores. Se debe tratar de evitar que se produzcan errores, pero a veces son inevitables, por lo que se deben implementar medios que eviten que se aborte el programa en caso de error o en todo caso , que sean transparentes de cara al usuario. En caso de error, se deben registrar para su posterior estudio y personalizar las acciones para cada tipo de error. GESTIÓN DE ERRORES EN PHP 5 PHP 5 genera tres tipos de error, según su gravedad: • Notice: Son errores simples y que no crean grandes problemas. No se suelen mostrar en pantalla. Es representado por la constante E_USER_NOTICE. • Warning: Es un aviso de que una parte del código ha producido u error, pero se puede continuar con la ejecución del programa. Se representa por la constante E_USER_WARNING. • Fatal error: Es un error grave que hace que se para la ejecución del programa. Se usa la constante E_USER_ERROR para representarlo. Se puede elegir el nivel de error que se desea mostrar por pantalla mediante la función error_reporting() dentro del archivo de configuración php.ini. Se pueden crear funciones que controlen errores sin más que definirlas y luego llamar a la función set_error_handler() y pasarle como parámetro el nombre de la función para que PHP sepa que esa función va a ser la encargada del control de errores. Para depurar errores la función error_log crea un fichero donde se almacenan las errores del código. Esta función recibe tres parámetros: • el primero indica el mensaje que debe ser registrado

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

• el tercero indica el destino donde se van a almacenar esos mensajes • el segundo es un numero entero que identifica el tipo de error y lo que se debe hacer con él: • 0: Se usa el mecanismo del sistema operativo • 1: Se envía un correo al email especificado como cuarto parámetro • 2:Ya no se usa esta opción. • 3: Envía el error a un fichero 4.7.2. Programación de excepciones. Una excepción es una condición que se presenta de forma inesperada en un programa, que no puede manejar el código del mismo. Las excepciones distinguen entre los diferentes tipos de errores que se pueden presentar y los manejan de una forma u otra dependiendo del tipo. EXCEPCIONES EN PHP 5 En PHP 5 se creó la clase Exception para el manejo de las excepciones. Se usa una instancia de esta clase para capturar los errores y mostrar mensajes personalizados. Una excepción es lanzada a través de la palabra reservada thrown y debe haber un bloque entre llaves que comience por la palabra reservada catch para capturarla. Si ese bloque no se encuentra se interrumpe la ejecución del programa y se emite u mensaje de error fatal Para que la captura de la excepción sea válida el código debe estar dentro de un bloque try. Ejemplo de tratamiento de excepciones en PHP 5

<? function prueba() { try { throw new Exception(‘Excepción producida’);

211

212

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

} catch (Exception $excepcion1) { // .. } } prueba(); ?>

La sentencia thrown sólo admite objetos de la clase Exception o derivados de ésta. El constructor de Exception admite dos parámetros: • Una cadena de caracteres para describir el error • Un número entero asignado por el programador para describir el código de error. Los métodos que puede manejar un objeto de la clase Exception son: • getMessage() devuelve el mensaje de la excepción que fue el primer argumento pasado al constructor. • getCode() devuelve el código del error, segundo argumento pasado al constructor. • getFile() devuelve el nombre del fichero que lanzó la excepción. • getLine() devuelve el número de la línea del fichero en que ocurrió la excepción. • getTrace() devuelve un array con los puntos donde han ocurrido excepciones. • getTraceAsString() : es igual que getTrace, pero en lugar de devolverlos en un array lo hace en forma de cadena de caracteres.

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

4.8. Transacciones y persistencia. 4.8.1. Acceso a bases de datos. Conectores. Cuando se habla de conector se hace referencia a un software que permite la conexión a un servidor de base de datos desde una aplicación. MySQL tiene conectores para varios lenguajes de programación, incluido PHP. Por tanto, para acceder a una base de datos a través de un lenguaje de programación se debe elegir el sistema gestor de base de datos y comprobar que tiene preparado un conector para ese lenguaje. Aunque PHP 5 acepta muchos de los gestores de bases de datos relacionales, los más usados son MySQL y PostgresSQL, siendo el primero el más popular y el que se va a explicar. 4.8.2. Estándares para el acceso a bases de datos. Entre los estándares o normas para el acceso a base de datos destacan las siguientes: • ODBC (Open Database Connectivity) es un estándar que fue desarrollado en 1992 para tratar de unificar el acceso a bases de datos SQL y desde entonces se ha convertido en el estándar más utilizado para este fin. • JDBC (Java Database Connectivity) es el estándar de acceso a base de datos con Java y es incluida con JDK ( Kit de Desarrollo de Java). • OLE DB: Microsoft lanzó este estándar en teoría más amplio que ODBC, ya que permite acceder a cualquier base de datos con datos estructurados de forma tabular. Pero a pesar de ello, se ha acabado imponiendo ODBC. • ADO: Otra norma de acceso más reciente es ADO (ActiveX Data Object), que está orientada a objetos. Realmente es una implementación de acceso al paradigma de datos OLE DB, siendo éste el encargado de obtener los datos y ADO se ocupa de presentarlos al programador. 4.8.3. Gestión de la configuración de acceso a bases de datos. Todos los lenguajes de programación web en servidor necesitan trabajar con bases de datos, por lo que tienen unas serie de funciones para la conexión con la base de datos, el acceso a las tablas y el tratamiento de los registros de esas tablas.

213

214

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

CONFIGURACION DE ACCESO A BASES DE DATOS EN PHP 5 Se van a describir las principales tareas de acceso a bases de datos con PHP 5. Para ello, se debe tener en cuenta que PHP proporciona diferentes APIs (Application Programming Interface) o formas de comunicarse con las bases de datos. Se van a explicar dos de las extensiones usadas por PHP: • Extensión clásica mysql: Es la que más se ha usado hasta ahora y aunque va a quedar obsoleta a partir de PHP 5.5, se va a seguir encontrando en programas con código anterior a esa versión y en programas alojados en servidores con versiones anteriores. • Extensión mysqli: Se introdujo a partir de PHP 5 y al contrario que la anterior, si tiene interfaz para programación orientada a objetos. FUNCIONES DE ACCESO A BASE DE DATOS CON EXTENSION MYSQL • Función mysql_connect: Se usa para conectarse con un servidor de base de datos y requiere tres argumentos:

-Servidor de la base de datos, que se le puede pasar por nombre o por IP.

-Nombre de usuario con permisos de acceso al servidor de la base de datos

• Contraseña del usuario Un ejemplo de conexión servidor de base de datos con mysql_connect $conexion1 = mysql_connect(“192.168.1.50”, “usuario1”,”password1”); • Función mysql_select_db: Una vez realizada la conexión a la base de datos, se usa esta función para elegir la base de datos del servidor. Se usa con dos argumentos: • Nombre de la base de datos • Referencia de la conexión que se ha realizado con mysql_connect() y que se suele guardar en una variable, aunque no es imprescindible y se puede usar la propia instrucción. Un ejemplo de conexión a base datos con mysql_select_db $conexion1 = mysql_connect(“192.168.1.50”, “usuario1”,”password1”);

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

mysql_select_db(“nombre_base_datos”,$conexion1); • Función mysql_query: Se usa para usar cualquier instrucción SQL de petición a la base de datos anteriormente seleccionada. Se usa con dos argumentos: • la petición escrita como cadena de caracteres en SQL • La referencia a la conexión de base de datos • Función mysql_result: Se usa para obtener el resultado de una consulta (query). Se suele usar con dos o tres argumentos: • El primer parámetro es la consulta • El segundo parámetro es un indicador numérico que indica la posición de la variable que queremos obtener, como índice de un array. Ejemplo de consulta de datos y obtención de resultado:

$conexion1 = mysql_connect(“192.168.1.50”, “usuario1”,”password1”); mysql_select_db (“nombre_base_datos”,$conexion1); $consulta1 = mysql_query(“select nombre FROM tabla1”,$conexion1); //La consulta extrae todos los campos nombre de la tabla (sin ninguna condición restrictiva ya que no se usa Where) y muestra el cuarto nombre (ya que se empieza a contar en cero y por tanto el índice 3 corresponde al cuarto elemento). $resultado1 = mysql_result ($consulta,3);

FUNCIONES DE ACCESO A BASE DE DATOS CON EXTENSION MYSQLI Con esta extensión, se usa una clase llamada mysqli, la cual tiene una serie de métodos para el acceso a base de datos. Si usamos el mismo ejemplo anterior con esta extensión quedaría así: $conexion1 = new mysqli (“192.168.1.50”, “usuario1”,”password1,”nombre_base_ datos”);

215

216

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

$consulta1 = $conexion1->query( “select nombre FROM tabla1”); $resultado1 = $consulta1->fetch_assoc();

4.8.4. Acceso a directorios y otras fuentes de datos. Un lenguaje de programación web en servidor puede necesitar acceder a base de datos o a ficheros para trabajar con sus datos, como se ha visto, pero además, puede necesitar manejar directorios. Un ejemplo típico es que necesite guardar una imagen que el usuario ha subido a través del programa. Para guardarla debe poder almacenar ese fichero en el directorio especificado, para ello sino existe o envía mensaje de error o lo crea. Todo lenguaje proporciona unas herramientas para manejo con directorios u otras fuentes de datos, como fuentes externas de datos. TRABAJO CON DIRECTORIOS EN PHP 5 En PHP 5,aparte del acceso a base de datos y a ficheros, ya visto, hay algunas funciones muy interesantes para trabajar con directorios. Algunas de estas funciones son muy similares a las usadas en Unix en modo comando. • Función opendir: Abre un directorio, necesita como argumento la ruta del mismo. Ejemplo: $directorio1=opendir($ruta); • Función readdir: Lee un elemento del directorio abierto previamente con opendir y el puntero pasa a apuntar al siguiente elemento. $directorio1=opendir($ruta); readdir($directorio); • Función rmdir: Elimina el directorio que le pasemos como argumento. rmdir ($directorio1); • Función mkdir: Crea un directorio. Se le pasa como argumento la ruta donde debe ser creado el directorio y los permisos del mismo.

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

• Estos permisos se asignan siguiendo la notación de la función chmod de Unix, donde cada directorio puede tener tres tipos de permisos (lectura-r-, escritura-w y ejecución-x-), para tres tipos de usuarios diferentes (el propietario del directorio, el grupo de usuarios del propietario y el resto de usuarios). Estos permisos toman el valor 1 si están presentes y 0 si no lo están. Así por ejemplo si se da todos los permisos a todos sería: rwxrwxrwx Siendo esto expresando en notación decimal: 777 De igual forma, si queremos que el propietario tenga todos los permisos y el grupo y el resto permisos de lectura y ejecución, pero no de escritura, sería: rwxr-xr-x Que en notación decimal sería 755 Estos dos permisos (777 y 755) son los más habituales, pero dependiendo del directorio se puede optar por el resto de combinaciones. Estos permisos es lo que se indicaría como segundo argumento a la función mkdir. mkdir($ruta2;$permisos); • Función rewindir: Coloca el puntero apuntando al primer elemento del directorio. rewindir ($directorio); • Función closedir: Cierra un directorio que se ha abierto anteriormente con opendir. closedir ($directorio3); A la hora de trabajar con directorios en PHP 5, el método es muy similar a los ficheros. Ejemplo de programa que trabaja con directorios

217

218

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

<? //Se define la ruta de accesos $ruta1 = “directoriopersonal/documentos”; //Se abre el directorio $directorio1 = opendir($ruta1); //Se leen los elementos del directorio y se muestran while ($elemento_directorio = readdir($directorio1)) { echo $ elemento_directorio.”<br>”; } //Se cierra el directorio closedir($directorio1); ?>

4.8.5. Programación de transacciones. Una transacción son varias operaciones de un gestor de base de datos, por ejemplo, MySQL, que son ejecutadas como un bloque, por lo que, al fallar una de las instrucciones, fallan todas. Si esto sucede o se debe cancelar, todas las modificaciones realizadas en los datos de la base de datos se borran. Si una transacción se realiza correctamente, todas las operaciones realizadas en la base de datos durante la misma, se confirman y son grabadas en la misma. Un típico ejemplo de transacción es una transferencia bancaria. Al hacer un traspaso de un a cuenta a otra, mientras no se confirme dicho traspaso, no se retira de la cuenta origen y se graba en la cuenta destino.

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

IMPLEMENTACIÓN DE TRANSACCIONES EN PHP 5 Para trabajar con transacciones en PHP 5 la base de datos utilizada debe tener soporte para tablas en un modo de almacenamiento concreto, modo innodb, lo cual se puede comprobar desde MySQL con una instrucción del tipo “ALTER TABLE tabla1 ENGINE = INNODB;” Ejemplo de transacción en PHP 5

<? $miusuario=”NombreUsuario”; $mipassword=”NombrePassword”; $miservidor=”NombreServidor”; $mibasededatos=”NombreBaseDatos”; $conexion1 = mysql_connect($miservidor,$miusuario,$mipassword); mysql_select_db($mibasededatos,$conexion1); $instruccionsql = “SET AUTOCOMMIT=0;”; $resultado1 = mysql_query($instruccionsql, $conexion1); $instruccionsql = “BEGIN;”; $resultado1 = mysql_query($instruccionsql, $conexion1); $instruccionsql = “SELECT * FROM tabla1; “; $resultado1 = mysql_query($instruccionsql, $conexion1); $instruccionsql = “INSERT INTO `tabla2` (`id`, `descripcion`) VALUES (‘’, ‘Valor ejemplo’);”; $resultado1 = mysql_query($instruccionsql, $conexion1); $instruccionsql = “INSERT INTO `tabla1` (`id`, `ripcion`) VALUES (´´, ´Valor ejemplo´);”;

219

220

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

$resultado1 = mysql_query($instruccionsql, $conexion1); if ($resultado1) { echo ‘Operación correcta’; $instruccionsql = “COMMIT”; $resultado1 = mysql_query($instruccionsql, $conexion1); } else { echo ‘Operación incorrecta’; } ?>

4.9. Componentes en servidor. Ventajas e inconvenientes en el uso de contenedores de componentes. Una de las posibles definiciones de componente, es ésta: un objeto de software que se ha diseñado con un objetivo concreto. Ejemplos de componentes pueden ser los botones en un formulario o las ventanas en una aplicación. Un contenedor es una clase que sirve para almacenar y organizar componentes y que sirve de unión entre la aplicación cliente y el componente que contiene. Entre las ventajas del uso de contenedores de componentes se encuentran: • Encapsulan la programación de los componentes que contienen. De esta forma, evitan escribir código y hacen que el código resultante sea más fácil de leer y de mantener. • Hacen más fáciles los procesos de eliminar, modificar o añadir componentes, ya que sólo debemos ejecutar la operación y el contenedor se encarga de reajustar los componentes.

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

• Facilitan la portabilidad del sistema, al ajustar el contenedor los componentes al sistema operativo en el que se encuentran. Algunas de las desventajas de su uso son: • Son difíciles de aprender a manejar por lo que su uso necesita bastante práctica. • Al principio, y debido al punto anterior, se pueden crear contendores muy pesados que dificulten el trabajo de la aplicación. 4.10. Modelos de desarrollo. El modelo vista controlador. El Modelo Vista Controlador (MVC) es un patrón para el desarrollo del software, usado sobre todo en aplicaciones web. Se basa en separar los tres elementos: • Los datos Modelo • La lógica interna Controlador • La interface de usuario -Vista

El funcionamiento de este modelo es el siguiente: Cuando el usuario activa un elemento, por ejemplo, enviar un formulario, este evento lo gestiona el controlador, el cual consulta y modifica el modelo y manda la respuesta a la interfaz, que manda al usuario el evento respuesta correspondiente (una vez enviado el formulario le llega email de confirmación). Entre los frameworks que usan este modelo se pueden citar:

221

222

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

• CodeIgniter en PHP • Zend en PHP • Ruby on Rails en Ruby • Spring en Java • Catalyst en OPerl • Django en Python

4.10.1. Modelo: programación de acceso a datos. Representa la información o datos del sistema. El controlador accede a él para todas las consultas y actualizaciones de datos que necesite hacer. La vista también accede a él para presentar los datos al usuario. Se va a ilustrar este modelo con un ejemplo en el que se seleccionan y listan los artículos de una base de datos y se muestra su precio y descripción. Se va a poner el ejemplo de cada fichero PHP de cada parte de este modelo para ilustrar la teoría. Ejemplo de fichero archivomodelo.php <?

function ObtenerArticulos() { $conexion2 = mysql_connect(‘localhost’, ‘usuario’, ‘poassword’); mysql_select_db(‘basedatosejemplo’, $conexion2);

$resultado2 = mysql_query(‘SELECT precio, titulo FROM $conexion2);

articulos’,

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

$listado_articulos = array();

while($articulos = mysql_fetch_assoc($resultado2)) { $listado_articulos[] = $articulos; }

mysql_close();

return $listado_articulos; } ?>

4.10.2.Vista: Desarrollo de aplicaciones en cliente. Eventos e interfaz de usuario. Presenta el Modelo en un formato apto para que el usuario pueda trabajar con él. Ejemplo de fichero archivovista.php

<h2>Listado de Articulos</h2> <table> <tr> <td>Precio</td> <td>Descripción del articulo</td> </tr>

223

224

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

<? foreach($listado_articulos as $articulos): ?> <tr> <td><? echo $articulos[‘precio’]?></td> <td><? echo $articulos[‘descripcion’]?></td> </tr> <? endforeach; ?> </table>

4.10.3. Programación del controlador. Interactúa con los dos elementos anteriores y gestiona los eventos enviados, bien por el usuario o bien por el programa. Ejemplo de fichero archivocontrolador.php

require(‘archivomodelo.php’); $articulos = ObtenerArticulos(); require(‘archivovista.php’);

4.11. Documentación del software. Inclusión en código fuente. Generadores de documentación. Un generador de documentación sirve para crear documentación a partir del código del programa. Esta documentación puede ser de varios tipos: de arquitectura y diseño, técnica o de usuario final. Según el generador de documentación elegido, aparte de tener unos requisitos técnicos para funcionar (sistema operativo en que funciona, lenguajes de

Unidad didáctica 4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

programación que lee) también puede tener unos requisitos funcionales (los lenguajes deben estar con comentarios o el código distribuido en clases, etc). Existen muchos generadores de documentación, algunos de los más conocidos son: • PHPDocumentor para PHP • PHPDoc para PHP • JavaDoc para Java • Doxygen para Java, PHP y C++ • Rdoc de Ruby

225

Resumen Resumen El trabajo que se asocia a la los procesos de desarrollo del software se puede dividir en varias fases, con independencia del tamaño o complejidad del proyecto, así como del área de aplicación. Así tenemos: La fase de definición se centra sobre el qué. Así durante la definición la organización que desarrolla el software intenta identificar qué información ha de ser procesada, qué rendimiento se desea, qué función ha de usarse, qué comportamiento del sistema, qué interfaces serán establecidas, qué restricciones de diseño hay, y qué criterios de validación se requieren para definir un sistema correcto. Es decir, han de identificarse los requisitos clave del sistema. La fase de desarrollo se centra en el cómo. Así durante el desarrollo se intenta definir cómo se ha de diseñar las estructuras de datos, cómo ha de implementarse cada función, así como los interfaces, los detalles procedimentales, cómo se debe traducir el diseño en un lenguaje de programación (o lenguaje no procedimental). En este módulo se ha visto en profundidad las bases de los lenguajes orientados a objetos, que son los lenguajes que permiten la definición de tipos de datos, nuevas operaciones de esos tipos de datos, y de crear instancias de los tipos de datos. Se ha puesto como ejemplo, el lenguaje Java, usando el mismo para explicar de forma práctica los conceptos teóricos explicados. Así mismo también explican las generalidades de los lenguajes web orientados en el lado servidor, que constituyen un paradigma de programación que usara los objetos en sus interacciones para diseñar aplicaciones software. Se basa en varias técnicas, incluyendo cohesión, herencia, polimorfismo, encapsulamiento, abstracción y acoplamiento. Como ejemplo de este tipo de lenguajes se ha usado PHP en su versión 5, implementada para el tratamiento de objetos. La fase de pruebas se centra en definir las estrategias y objetivos de las pruebas según las características del software. La fase de mantenimiento se centra en el cambio asociado a la corrección de errores y a las adaptaciones necesarias según evoluciona el entorno del software, y a cambios que conllevan las mejoras realizadas por los cambios sobre los requisitos del cliente. En este módulo hemos estudiado también otros conceptos como: ––Las herramientas usadas para el desarrollo de software; ––La calidad del software; ––Y los procesos, estándares y conceptos fundamentales que involucran las distintas fases del desarrollo de proyectos software.

Bibliografía Bibliografía • Carlos M Fontela. (2008). Orientación a Objetos. Editorial Nueva Librería. • Roger S. Pressman. (2002) Ingeniería del Software – Un enfoque práctico. Mc Graw Hill. • Ian Sommerville. (2005). Ingeniería del Software. Pearson. • Sklar, David.(2005). PHP 5. Anaya Multimedia. • Instituto de Gestión de Proyectos de Newton Square, Pennsylvania USA. (2000). Guía fundamental para la gestión de proyectos.

Glosario Glosario Arquitectura cliente-servidor Modelo arquitectónico para sistemas distribuidos cuya funcionalidad para con el sistema se ofrece con un grupo de servicios prestados por un servidor. Arquitectura software Modelo de estructura, organización fundamental de un sistema software. Atributo Contenedor de valor que permite saber el estado de una propiedad de un objeto en un momento dado. Ciclo de vida del software Término que hace referencia a todo el proceso que tiene el software, desde que es una idea, hasta que el sistema se retira de uso. Clase de objetos Define los atributos y operaciones de los objetos. Los objetos se crean durante la ejecución por una referenciación en la definición de la clase. Componente: Unidad de software independiente y desplegable que se define totalmente y al que se accede por medio de interfaces. Constructor Método especial de una clase que sirve para crear objetos de la misma. Desarrollo incremental Enfoque para el desarrollo de software en el que este se entrega por fases, en las que el software va creciendo. Desarrollo iterativo Enfoque para el desarrollo de software en el que se entrelazan los procesos de especificación, diseño, programación y pruebas. Desarrollo orientado a objetos Enfoque para el desarrollo de software donde las abstracciones fundamentales del sistema son objetos independientes. Esta abstracción será común durante la especificación, diseño y desarrollo. Desarrollo rápido de aplicaciones Enfoque para el desarrollo de software dirigido a la rápida entrega de éste. Suele implicar usar programación de bases de dato y herramientas de apoyo como generadores de pantallas e informes.

229

Entrega Versión de un sistema software puesta a disposición del cliente. Gestión de la Configuración Proceso destinado a manejar los cambios del producto software que se desarrolla. Gestión de Requisitos Proceso destinado a manejar los cambios en los requisitos para asegurar que estos se analicen e implementen correctamente en el sistema. Gestión de Riesgos Proceso destinado a identificar, evaluar, y planificar las medidas a adoptar ante los riesgos, así como supervisar el software y los procesos software para los riesgos. Herencia Propiedad por la cual una clase hija tiene los mismos atributos y métodos de una clase padre. Herramientas CASE Herramientas usadas para ayudarse a desarrollar un software. Interfaz: Especificación de atributos y operaciones asociados a un componente software. Se usa como medio para tener acceso a la funcionalidad de un componente. Lenguaje de Modelado Unificado (UML) Lenguaje gráfico usado en el desarrollo orientado a objetos, donde se incluyen los tipos de modelos del sistema que dan diferentes aspectos del sistema. Mantenimiento: Proceso de realizar cambios en el sistema después de su puesta en funcionamiento. Método de una clase: Una serie de instrucciones que explican un comportamiento de una clase.También se le llama procedimiento (sino devuelve ningún valor) o función (si devuelve un valor). Métodos formales Métodos de desarrollo software que se basan en enfoques rigurosos para modelar el software usando construcciones matemáticas formales tales como predicados y conjuntos.

230

Seguridad Característica del sistema para funcionar sin fallos catastróficos. Servicio Web Componente software independiente al que se puede acceder por la web usando protocolos estándares. Servidor Programa que da algún tipo de servicio a otros programas, llamados clientes. Sistema crítico Sistema software cuyo mal funcionamiento puede causar graves pérdidas económicas, humanas o para el medio ambiente. Sistema de objetos distribuidos Sistema software distribuído donde los componentes ejecutables son objetos. Sistema distribuido Sistema software donde sus componentes se ejecutan en distintos procesadores. Validación Proceso de verificación de que un sistema software cumple con las expectativas y necesidades del cliente. Verificación Proceso de verificación de que un sistema software cumple con su especificación.

Certiﬁcado de Profesionalidad

IFCD0210

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB

as competencias profesionales que se adquieren con este Certificado de Profesionalidad son desarrollar documentos y componentes software que constituyan aplicaciones informáticas en entornos distribuidos. Utilizando tecnologías web, partiendo de un diseño técnico ya elaborado, realizando la verificación, documentación e implantación de los mismos.

Módulos formativos y Unidades formativas • MF0491_3: Programación web en el entorno cliente Uf1841: Elaboración de documentos web mediante lenguajes de marca Uf1842: desarrollo y reutilización de componentes software y multimedia mediante lenguajes de guión Uf1843: aplicaciones técnicas de usabilidad y accesibilidad en el entorno cliente

Uf1844: desarrollo de aplicaciones web en el entorno servidor Uf1845: acceso a datos en aplicaciones web del entorno servidor Uf1846: desarrollo de aplicaciones web distribuidas • MF0493_3: Implantación de aplicaciones web en entorno internet, intranet y extranet

ISBN: 978-84-16047-33-8

• MF0492_3: Programación web en el entorno servidor