desarrollo de aplicaciones web en el entorno servidor

Desarrollo de aplicaciones web en el entorno servidor

Programación web en el entorno servidor 02/11/2017 José Miguel Castillo Castillo

DESARROLLO DE APLICACIONES WEB EN EL ENTORNO SERVIDOR

1

INDICE DE CONTENIDO. DESARROLLO DE APLICACIONES WEB EN EL ENTORNO SERVIDOR 1 EL PROCESO DEL DESARROLLO DE SOFTWARE 1.1 Modelos del ciclo de vida del software 1.2 Análisis y especificación de requisitos 1.3 Diseño 1.4 Implementación. Conceptos generales de desarrollo de software 1.5 Validación y verificación de sistemas 1.6 Pruebas de software 1.7 Calidad del software 1.8 Herramientas de uso común para el desarrollo de software 2 LA ORIENTACIÓN A OBJETOS 2.1 Principios de la orientación a objetos 2.2 Clases de objetos 2.3 Objetos 2.4 Herencias 2.5 Modularidad 2.6 Generalidad y sobrecarga 2.7 Desarrollo orientado a objetos 2.8 Lenguajes de modelización en el desarrollo orientado a objetos 3 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 4 LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR 4.1 Características de los lenguajes de programación 4.2 Tipos y características de los lenguajes de uso común 4.3 Criterios en la elección de un lenguaje de programación 4.4 Características generales 4.5 Gestión de la configuración 4.6 Gestión de la seguridad 4.7 Gestión de errores 4.8 Transacciones y persistencia 4.9 Componentes en servidor 4.10 Modelos de desarrollo 4.11 Documentación del software. Inclusión en código fuente. Generadores de documentación.


2

1. EL PROCESO DEL DESARROLLO DE SOFTWARE

Tanto en el proceso de desarrollo del software como del hardware se siguen unas fases de análisis, diseño y desarrollo. En el caso de producción de hardware a gran escala, el coste del producto depende del coste de los materiales empleados y del propio proceso de producción, no influyendo tanto en el coste las fases previas de ingeniería. La situación del desarrollo de software es diferente ya que la producción a gran o pequeña escala no influye en el impacto que tiene la ingeniería en el coste, al ser un producto inmaterial.

Hay que destacar que el software no requiere un control de calidad individualizado, cosa que sí que ocurre en el hardware, y los costes del software radican en el desarrollo de la ingeniería y no en la producción.

1.1. Modelos del ciclo de vida del software

En cascada (waterfall).

Este es el más básico de todos los modelos. Su visión plantea un desarrollo basado en la secuencia simple de fases que poseen un conjunto de metas bien definidas.

En la etapa final de cada una de las fases se reúne la documentación para garantizar que cumple con las especificaciones y los requisitos antes de pasar a la siguiente fase.

Su punto débil es la habitual falta de comunicación con el usuario final y las características primordiales son:

Planear un proyecto antes de embarcarse en él.

Definir el comportamiento externo antes de diseñar su arquitectura interna.

Documentar los resultados de cada actividad.

Diseñar un sistema antes de codificarlo.

Testear el sistema después de construirlo.


3

Iterativo.

Esta etapa involucra el rediseño e implementación de una tarea de la lista de control de proyecto, un constante análisis actualizado del sistema. El objetivo del diseño e implementación de cualquier iteración debe ser simple, directa y modular.

El código puede, en ciertos casos, representar la mayor fuente de documentación del sistema. El análisis de una iteración se basa en la retroalimentación del usuario y en el análisis de las funcionalidades disponibles del programa. Involucra el análisis de la estructura, modularidad, usabilidad, confiabilidad, eficiencia y eficacia (alcanzar las metas).

Las normas básicas que deben regir los distintos análisis son:

Cualquier dificultad en el diseño, codificación y prueba de una modificación debería apuntar a la necesidad de rediseñar o vuelta a codificar.

Las modificaciones deben ajustarse fácilmente a los módulos comunes y a los aislados.

Las modificaciones deben ser más fáciles de hacer conforme avanzan las iteraciones.

Los parches normalmente deben permanecer solo por una o dos iteraciones. Se hacen necesarios para evitar el rediseño durante una fase de implementación.

La implementación existente debe ser analizada frecuentemente para determinar qué tal se ajusta a las metas del proyecto.

Las facilidades para analizar el programa deben ser utilizadas cada vez para ayudar en el análisis de implementaciones parciales.

La opinión del usuario debe ser solicitada y analizada para indicar deficiencias en la implementación referida por él.

Incremental.

Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes por lo que se usa un desarrollo incremental como método de reducción de riesgos, construyendo sólo una parte del sistema, reservando otros aspectos para niveles posteriores.

El desarrollo incremental es un proceso de construcción que paulatinamente va incrementando subconjuntos de requerimientos del sistema.

El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:

Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.

Desarrollar parte de las funcionalidades es más sencillo de elaborar si los requerimientos planeados para los niveles subsiguientes son correctos.

Si un error importante es realizado, sólo la última iteración necesita ser descartada.

Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.

Si un error importante es realizado, el incremento previo puede ser usado.

Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.


4

En V.

Proporciona una guía para la planificación y realización de proyectos siguiendo un esquema similar a la siguiente imagen.

Los siguientes objetivos están destinados a ser alcanzados durante la ejecución del proyecto:

Minimización de los riesgos del proyecto.

Mejora la transparencia del proyecto y control del proyecto describiendo los resultados correspondientes y funciones de responsabilidad.

Permite una detección temprana de las desviaciones y los riesgos y mejora la gestión de procesos, reduciendo así los riesgos del proyecto.

Mejora y Garantía de Calidad.

Asegura que los resultados que se proporcionan sean completos y contengan la calidad deseada. Los resultados provisionales definidos se pueden comprobar en una fase temprana.

La uniformidad en el contenido del producto mejora la legibilidad, comprensibilidad y verificabilidad.

Reducción de los gastos totales durante todo el proyecto y sistema de Ciclo de Vida.

El esfuerzo para el desarrollo, producción, operación y mantenimiento de un sistema puede ser calculado, estimado y controlado de manera transparente mediante la aplicación de un modelo de procesos estandarizados.

Se reduce la dependencia en los proveedores y el esfuerzo para las siguientes actividades y proyectos.

Basado en componentes (CBSE).

La reutilización de software es un proceso de la Ingeniería de Software que conlleva al uso recurrente de elementos o componentes software que están activos.

Según algunos autores, "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”.


5

Las características de un componente se esquematizan bajo las siguientes premisas:

Identificable. Debe tener una identificación que permita acceder fácilmente a sus servicios que permita su clasificación.

Contenido propio. Un componente no debe requerir de la utilización de otros para finiquitar la función para la cual fue diseñado.

Reemplazable. Se puede remplazar por nuevas versiones u otro componente que lo remplace y mejore.

Mantenimiento de servicios. Las funcionalidades ofrecidas en su interfaz no deben variar, pero su implementación sí.

Documentado. Un componente debe estar correctamente documentado para facilitar su búsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc.

Genérico. Sus servicios deben servir para varias aplicaciones.

Independiente de la plataforma.

El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo en espiral. Es evolutivo por naturaleza y exige un enfoque iterativo para la creación del software.

El modelo de desarrollo basado en componentes conduce a la reutilización del software, y la reutilización proporciona beneficios a los ingenieros de software.

Por ejemplo, según estudios de reutilización, QSM Associates, Inc. el ensamblaje de componentes lleva a una reducción del 70 por 100 de tiempo de ciclo de desarrollo, un 84 por 100 del coste del proyecto y un índice de productividad del 26.2, comparado con la norma de industria del 16.9 Aunque estos resultados están en función de la robustez de la biblioteca de componentes, no hay duda de que el ensamblaje de componentes proporciona ventajas significativas para los ingenieros de software.

El paradigma de ensamblar componentes y escribir código para hacer que estos componentes funcionen se conoce como Desarrollo de Software Basado en Componentes. El uso de este paradigma posee algunas ventajas:

Reutilización del software. Nos lleva a alcanzar un mayor nivel de reutilización de software.

Simplifica las pruebas.

Simplifica el mantenimiento del sistema. Cuando existe un débil acoplamiento entre componentes, el desarrollador es libre de actualizar y/o agregar componentes según sea necesario, sin afectar otras partes del sistema.

Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organización, la calidad de una aplicación basada en componentes mejorará con el paso del tiempo.


6

De la misma manera, el optar por comprar componentes de terceros en lugar de desarrollarlos, posee algunas ventajas:

Ciclos de desarrollo más cortos.

Mejor ROI.

Funcionalidad mejorada.

Desarrollo rápido (RAD).

El desarrollo de software mediante métodos rápidos reduciendo el tiempo del ciclo de vida del software (por lo tanto, acelerando el desarrollo) generando una versión prototipo y después integrándola en el conjunto del proyecto de manera iterativa para satisfacer los requisitos del cliente y controlar todo el ciclo de desarrollo.

Los métodos rápidos se originaron por la inestabilidad del entorno técnico y el hecho de que el cliente a veces es incapaz de definir cada uno de los requisitos al inicio del proyecto.

El término rápido es una referencia a la capacidad de adaptarse a los cambios de contexto y a los cambios de especificaciones que ocurren durante el proceso de desarrollo.

Los impulsores de este método redactaron un manifiesto en el que expresaron los siguientes puntos principales:

Individuos e interacciones en lugar de procesos y herramientas.

Desarrollo de software en lugar de documentación exhaustiva.

Trabajo con el cliente en lugar de negociaciones contractuales.

Apertura para los cambios en lugar de cumplimiento de planes poco flexibles.

Con la ayuda de los métodos rápidos, el cliente tiene control total de su proyecto y logra una rápida implementación del software.

Ventajas e inconvenientes. Pautas para la selección de la metodología más adecuada

Hay distintos modelos de ciclo de vida que son utilizados para el desarrollo de un sistema software, especificando el orden de las tareas o actividades involucradas, la coordinación entre ellas y la posible realimentación. Es posible utilizar cualquier tipo ya existente o incluso elaborar uno propio. Lo importante es optimizar el proceso de desarrollo conforme a los requerimientos que se nos piden en el mismo logrando así desarrollar un programa de mayor calidad.


7

Los factores que influyen a la hora de elegir un ciclo de vida para resolver un problema son:

Disponibilidad de recursos ya sean económicos, tiempo, equipos, humano, etc.

Entender los requerimientos.

Dominio del problema, si se tiene los conocimientos para dar solución al problema central.

Complejidad y magnitud del proyecto.

1.2. Análisis y especificación de requisitos

El resultado del análisis de requisitos con el cliente debe quedar reflejado en un documento llamado ERS (Especificación de Requisitos del Sistema) cuya estructura puede venir definida por varios estándares, tales como CMMI. Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las principales entidades que participarán en el desarrollo del software.

La captura, análisis y especificación de requisitos es fundamental puesto que de ello en gran medida el logro de los objetivos finales.

La IEEE 830-1998 normaliza la creación de las especificaciones de requisitos de software (Software Requirements Specification).

No siempre en la etapa de análisis de requisitos las distintas metodologías de desarrollo llevan asociado un estudio de viabilidad y/o estimación de costes. El más conocido de los modelos de estimación de coste del software es el modelo COCOMO.

La especificación de requisitos software es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales. Además de los casos de uso, la ERS también contiene requisitos no funcionales (o complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación.

Por ejemplo, las restricciones en el diseño o en los estándares de calidad.

Tipos de requisitos.

En la ingeniería clásica, los requisitos se utilizan como datos de entrada en la etapa de diseño del producto estableciendo qué debe hacer el sistema, pero no cómo hacerlo.

La fase de captura y registro de requisitos puede estar precedida por una fase de análisis conceptual del proyecto. Esta fase puede dividirse en recolección de requisitos, análisis de consistencia e integridad, definición en términos descriptivos para los desarrolladores y un esbozo de especificación, previo al diseño completo.

En ingeniería de sistemas existen los siguientes tipos de requisitos:

1. Un requisito funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requisito específica algo que el sistema entregado debe ser capaz de realizar.

2. Un requisito no funcional especifica algo sobre el propio sistema, y cómo debe realizar sus funciones.

Algunos ejemplos de estos aspectos son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.


8

3. Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto.

Por ejemplo, la compatibilidad con cierto sistema operativo o la adecuación a regulaciones aplicables al producto.

Modelos para el análisis de requisitos.

Los modelos de análisis utilizan una mezcla de formatos en texto y diagramas para representar los requisitos del software, las funciones y el comportamiento haciendo más fácil de comprender dicha representación, ya que es posible examinar los requisitos desde diferentes puntos de vista aumentando la probabilidad de encontrar errores, de que surjan debilidades y de que se descubran descuidos.

El modelo de análisis con UML comienza con la creación de escenarios en la forma de “los casos de uso, diagrama de actividad y diagrama de carril”.

Este modelo en simples palabras sirve para una interacción más amena entre el sistema y el usuario.

Caso de uso. Describe un escenario de un caso específico en un lenguaje directo desde el punto de vista de un actor definido.

Por ejemplo,


9

Diagrama de actividad. Es un modelo muy parecido al caso de uso pero mucho mejor complementado y proporciona una representación del flujo de interacción dentro de un escenario específico.

Por ejemplo,

Diagrama de carril. Consiste en tomar el diagrama actividad y situarlo en filas o en carriles. En este modelo los actores son fundamentales ya que en el diagrama de carril se especifica claramente, con un carril, la responsabilidad a cada actor.

Por ejemplo,


10

Propiedades del DFD

El nivel 0 del diagrama del flujo debe representar al software.

La entrada y la salida primaria se deben establecer con cuidado.

La refinación debe comenzar por el aislamiento de procesos, objetos de datos y almacenamiento de datos candidatos a ser representados en el siguiente nivel.

Todas las flechas y burbujas se deben rotular con el nombre.

Se debe tener la continuidad de flujo al cambiar el nivel.

La refinación de burbujas debe hacerse una por una.

Por ejemplo, este diagrama es orientado al tiempo y rendimiento.

Modelos basados en clases.

Una clase orientada a objetos encapsula atributos de los datos pero también incorpora las operaciones que manipulan los datos implicados por dichos atributos.

Por ejemplo,


11

Las clases se manifiestan en la siguiente forma: entidades externas, sucesos o eventos, cosas, papeles o roles, unidades organizacionales, sitios y estructuras.

Modelo CRC (clase-responsabilidad-colaborador).

El modelado de Clase-Responsabilidad-Colaborador (CRC) proporciona un medio simple para identificar y organizar las clases relevantes para los requisitos del sistema o producto.

Por ejemplo,

Un modelo CRC es una colección de tarjetas índices estándar que representan clases. La idea final es poder desarrollar una representación organizada de las clases.

Existen diferentes categorías entre las clases que nos permite establecer la siguiente clasificación:

Clases de entidad. Se extraen de manera directa del enunciado del problema.

Clases de frontera. Se utilizan para crear la interfaz que el usuario ve y con la cual interactúa cuando se utiliza el software.

Clases de controlador. Manejan unidades de trabajo desde el inicio hasta el final.

Responsabilidad. Son los atributos y las operaciones relevantes para la clase.

Colaboradores. Son aquellas clases que se emplean para que una clase reciba la información necesaria para completar una responsabilidad.

Agregación. Son las subclases que forman parte de una clase, se conectan a través de una relación de tipo "es parte de”.

Diagrama de estado: Nos permiten representar los diferentes comportamientos de las clases.

Ejemplo de diagrama de estados,


12

Diagrama de Secuencia: Representa el comportamiento al describir la forma en que las clases se mueven de estado a estado.

Ejemplo de diagrama de secuencia.

Documentación de requisitos.

El objetivo principal de la tarea de documentar los requisitos del sistema es continuar con la definición del sistema software a desarrollar, tomando como punto de partida los requisitos generales y los casos de usos en su versión inicial, y considerando los objetivos de negocio y el modelo de negocio a implantar.

Los casos de uso que se considere necesario se van completando con más información y los requisitos generales se van detallando en requisitos funcionales, no funcionales, de integración y en restricciones técnicas.

Por ejemplo,

Validación de requisitos.

Es muy importante asegurar la validez de los requisitos antes de comenzar estrictamente lo que es un desarrollo de software. Para llevar a cabo tal tarea se suele realizar comprobando que el modelo obtenido responde de la misma forma deseada que la que el cliente pide por un lado, y por otro a la inversa si otras respuestas del modelo convencen al cliente. En algunos casos será necesario construir prototipos con una funcionalidad similar muy reducida para que el cliente se haga una idea aproximada del resultado.


13

Los parámetros a validar en los requisitos son:

Validez. Hay que conocer a todos los potenciales usuarios ya que pueden tener puntos de vista distintos y necesitar otros requisitos.

Consistencia. No debe haber contradicciones entre unos requisitos y otros.

Completitud. Deben estar todos los requisitos.

Esto es imposible en un desarrollo iterativo, pero, al menos, deben estar disponibles todos los requisitos de la iteración en curso.

Verificabilidad. Hay que comprobar que cada requisito se cumple.

Las principales técnicas de validación de requisitos son las siguientes:

- Dentro de los tipos principales de prototipos de interfaz de usuario los destacados son: o Desechables. Se utilizan sólo para la validación de los requisitos y posteriormente se

desechan. Pueden ser prototipos en papel o en software. o Evolutivos. Una vez utilizados para la validación de los requisitos, se mejora su calidad y se

convierten progresivamente en el producto final.

- Recorrido de casos de uso. El recorrido o walkthrough es una técnica de revisión de productos tradicionalmente asociada a la inspección de código fuente. Su principal objetivo es encontrar conflictos en el producto que se revisa, de forma que puedan plantearse alternativas y los participantes aumenten su conocimiento del producto en cuestión.

Gestión de requisitos.

Entre los problemas del desarrollo de software destacan el inadecuado entendimiento de las necesidades de los usuarios, la incapacidad de absorber cambios en los requisitos y las insatisfacciones de los clientes.

Las principales causas de estas desavenencias son la administración insuficiente de requisitos, los problemas que afectan la comunicación, las inconsistencias no detectadas entre requisitos, diseño y programación, las validaciones tardías de requisitos, el enfrentamiento reactivo de riesgos y la propagación de cambios sin control.

Podemos señalar entonces que los modelos de proceso de Ingeniería de Requisitos (IR) aún presentan carencias. Es necesario proporcionar un procedimiento para efectuar la gestión de los requisitos de un proyecto de software basado en la integración de las mejores prácticas, con un enfoque holístico, proactivo y estratégico que potencie de manera efectiva el desempeño del proceso de gestión de desarrollo del proyecto de software y la satisfacción del cliente.

Los principios para realizar la gestión de los requisitos del software son:

El acuerdo de los requisitos es el puente entre el desarrollo de requisitos y la gestión de requisitos.

La gestión de requisitos incluye todas las actividades para mantener la integridad, exactitud y difusión de los acuerdos de los requisitos durante la vida del proyecto.


14

1.3. Diseño

Según la IEEE610, el diseño se definido como: "El proceso de definición de la arquitectura, componentes, interfaces y otras características de un sistema o componente que resulta de este proceso".

Modelos para el diseño de sistemas.

Cada vez es mayor el número de organizaciones que son conscientes de la necesidad de gestionar su información como un recurso de alto valor estratégico, pero que sin embargo tiene dificultades a la hora de llevarla a la práctica.

A diferencia de lo que ocurre con otros ámbitos de gestión, no existen modelos formalizados para el diseño e implementación de sistemas que gestionen la información.

La modelización presenta diferentes etapas:

Investigación preliminar.

El objetivo de esta etapa es proporcionar a la organización la comprensión del contexto en el que desarrolla su actividad lo que nos llevará a identificar los factores que más influyen en la creación de un sistema de gestión de la información.

Se trata del punto de partida donde se recoge información sobre la visión que la entidad tiene respecto al concepto y al valor de la información, ayudando a definir la situación en materia de cultura de la información y a evaluar posibles carencias.

Análisis de las actividades de la organización.

El objetivo de esta etapa consiste en desarrollar un modelo conceptual sobre qué hace una organización y cómo lo hace.

Trata de medir el grado de satisfacción de sus necesidades de información sobre las áreas que deben ser de su interés. Una cobertura oportuna de las áreas que deben ser conocidas y sobre las que hay que disponer de la información relevante contribuirá a la toma de decisiones y a un posicionamiento adecuado en el entorno.

Identificación de los requisitos.

Consiste en identificar los requisitos que ha de cumplir la organización para hacer un seguimiento estructurado y sistemático de la información. Los requisitos sobre la identificación y seguimiento de las fuentes de información se definen a través de un análisis sistemático de las necesidades de la organización. Esta etapa proporciona las razones para la identificación, seguimiento y análisis de las fuentes de información, así como la base del diseño de los sistemas que se encargarán de incorporarlas y mantenerlas.

Evaluación de los sistemas existentes.

El objetivo de esta etapa consiste en analizar los procedimientos, herramientas y criterios empleados para la clasificación, el almacenamiento, el acceso y la difusión de la información, con el fin de valorar en qué medida la información se trata y se difunde de manera coherente con las actividades y objetivos de la organización.


15

Identificación de estrategias para cumplir los requisitos.

El objetivo de esta etapa consiste en evaluar el uso que la organización hace con la información obtenida como herramienta para la toma de decisiones. A su vez, una adecuada puesta en valor de la información debería facilitar las políticas, procedimientos, normas y planes que la organización necesita para el éxito de su actividad.

Diagramas de diseño. El estándar UML.

Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un modelo del sistema en el que se incorporan aspectos conceptuales como los procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.

UML es un lenguaje de modelado para especificar o para describir métodos o procesos.

Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir.

UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se esquematiza la realidad de una función o de un requerimiento. En cambio, la programación estructurada es una forma de programar como lo es la orientación a objetos. En cualquier caso, la programación orientada a objetos es un complemento perfecto a UML.

Por ejemplo,

Documentación.

Los programas cuya única documentación es el código se quedan obsoletos rápidamente y es imposible mantenerlos.

La falta de documentación no sólo genera trabajo adicional, sino que también tiende a dañar la calidad del código. Si no se posee una nítida caracterización del problema, es imposible que desarrolle una solución clara.


16

Es necesaria la formación específica para aprender a documentar software puesto que es una tarea complicada y exige un criterio de ingeniería maduro.

Documentar de forma concisa es un error habitual pero el otro extremo puede resultar igual de perjudicial.

Por ejemplo, si escribe documentaciones extensas atosigaremos a la persona que la consulta y constituirán una carga a la hora de conservarlas. Es esencial documentar sólo los asuntos correctos. La documentación no sirve de ayuda para nadie si su extensión desanima a la gente a la hora de leerla.

Aunque algunas veces es conveniente posponer la tarea de la documentación mientras se realizan experimentos, los programadores con experiencia suelen documentar de forma metódica incluso el código provisional, los análisis de un problema inicial y los borradores de un diseño. Al tener la creación de documentación como hábito les resulta normal documentar a medida que van avanzando.

Es esencial que no se piense que la documentación es un asunto rutinario y aburrido.

1.4. Implementación. Conceptos generales de desarrollo de software

Una implementación o implantación es la realización de una aplicación, instalación o la ejecución de un plan, idea, modelo científico, diseño, especificación, estándar, algoritmo o política.

En ciencias de la computación, una implementación es la realización de una especificación técnica o algoritmos como un programa, componente software, u otro sistema de cómputo. Muchas implementaciones son dadas según a una especificación o un estándar. Por ejemplo, un navegador web respeta (o debe respetar) en su implementación, las especificaciones recomendadas según el World Wide Web Consortium (W3C), y las herramientas de desarrollo del software contienen implementaciones de lenguajes de programación.

Habitualmente, la implementación se refiere al proceso post-venta de guía de un cliente sobre el uso del software o hardware que el cliente ha comprado. Esto incluye el análisis de requisitos, análisis del impacto, optimizaciones, sistemas de integración, política de uso, aprendizaje del usuario, marcha blanca y costes asociados.

La implementación de software comprende el trabajo de grupos de profesionales que son relativamente nuevos en la economía basada en la gestión del conocimiento, tales como analista de negocios, analistas técnicos, arquitecto de software, y directores de proyecto.

Principios básicos del desarrollo de software.

KISS es uno de los principales principios de desarrollo de software. Se puede resumir en que en igualdad de condiciones la solución más sencilla es probablemente la correcta.

Los puntos básicos que lo definen son:

Partes sencillas y comprensibles, que permite trabajar fácilmente en grupos de trabajo.

Fácil mantenimiento y flexibilidad.

Con errores de fácil detección y corrección.

Descartar lo complejo e innecesario.


17

Los patrones de diseño son herramientas para mitigar la complejidad de los sistemas de software ya que encapsulan modelos de resolver determinados tipos de problemas y es un elemento fundamental de las buenas prácticas de programación. Básicamente ofrecen múltiples plantillas en las que basar nuestros desarrollos.

Fuente de información primaria.

Es aquella información que se obtiene directamente de la realidad misma, sin sufrir ningún proceso de elaboración previa. Son las que el investigador recoge por sí mismo en contacto con la realidad.

Fuente de información secundaria.

Los analistas utilizan una variedad de métodos a fin de recopilar los datos sobre una situación existente, como entrevistas, cuestionarios, inspección de registros (revisión en el sitio) y observación. Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigación completa.

Entrevista.

La entrevista se utiliza para recabar información en forma verbal, a través de preguntas que propone el analista. Quienes responden pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema existente, usuarios potenciales del sistema propuesto o aquellos que proporcionarán datos o serán afectados por la aplicación propuesta.

El analista puede entrevistar al personal en forma individual o en grupos algunos analistas prefieren este método a las otras técnicas que se estudiarán más adelante. Sin embargo, las entrevistas no siempre son la mejor fuente de datos de aplicación.

Dentro de una organización, la entrevista es la técnica más significativa y productiva de que dispone el analista para recabar datos. En otras palabras, la entrevista es un intercambio de información que se efectúa cara a cara. Es un canal de comunicación entre el analista y la organización; sirve para obtener información acerca de las necesidades y la manera de satisfacerlas.

Revisión Documental.

El objetivo de esta técnica es estar actualizado en el tema que se explora. Es requisito de la revisión documental obtener la información de los archivos de bibliotecas y hemerotecas, archivos digitales clasificados, revistas y publicaciones registradas y certificadas, archivos documentales de instituciones y/o grupos reconocidos en el campo de investigación, entre otros.


18

La indagación sobre el conocimiento es necesaria para comprender el campo sobre el cual se investiga. El estudio documental permite hacer una retrospección del tema en cuestión, permite plantear comparaciones o relaciones entre las categorías que han sido definidas por el investigador, para plantear hipótesis, con respecto al desarrollo del tema a investigar.

La revisión documental abarca información suficiente del tema, para captar el significado que se trata de comprender y explicar sobre el tema planteado.

Técnica de Costo-Beneficios.

Esta técnica se implementa habitualmente como guía para lograr una respuesta de viabilidad. Los resultados no son definitivos pero ayudan a tomar decisiones posteriores ya que presentan un nivel de certeza muy razonable.

Los resultados obtenidos no representan una regla a seguir por todo el mercado y ni por un sector en particular. Sin embargo, las tendencias nos pueden decir mucho y referencias de organizaciones que tomaron uno u otro camino son de gran ayuda el momento de decidir.

La disponibilidad de información histórica es otro elemento que determina el riesgo de la estimación, donde las experiencias son más elocuentes que promesas infundadas de proveedores o entusiastas tecnológicos.

Los elementos que intervienen en un análisis de Costo-Beneficio para una evaluación correcta son los que a continuación se detallan.

Costos:

Precio del Software (A).

Infraestructura. Incluidos todos los componentes hardware y software (B).

Implantación. Consultoría para instalación y puesta en funcionamiento (C).

Entrenamiento de los usuarios de la aplicación (D).

Costo Total de la Solución (CTS) = A + B + C + D

Beneficios:

Mejora de Procesos. Permitiendo la reducción de tiempo y recursos (A).

Disponer de Sistemas de Información. Mejora la toma de decisiones y obtención de ingresos (B).

Personal Motivado (C).

Intangibles. Otros beneficios intangibles que sean identificados y cuantificables (D).

Beneficio Total de la Solución (BTS) = A + B + C + D

Si CTS < BTS entonces la solución es Viable, en caso contrario no es recomendable.

Cada uno de los elementos a incluirse debe ser cuantificado y ponderado, de tal forma que el agregado final determine un resultado tangible.

Técnicas de desarrollo de software.

El diagrama de flechas completo da una representación gráfica de las relaciones entre las actividades del proyecto. La ventaja de esta etapa es que permite conocer con detalle las diversas actividades o fases del proyecto y de esta manera se pueden sugerir mejoras antes de que el proyecto se ejecute.


19

EL diagrama debe comprender como mínimo las siguientes fases:

Establecimiento de objetivos.

Identificación de actividades principales: se identificarán aquellas fases necesarias para crear la aplicación. Este punto estará referido al diseño y desarrollo de la aplicación y a la puesta en común de las necesidades de recursos. Éstas como mínimo deberían ser:

Diseño de la arquitectura.

Diseño técnico.

Implementación.

Revisión y verificación de diseño.

Creación documentación (manuales de usuario, de instalación, etc.).

Implantación cliente.

Creación de la estructura de proyecto: se definirán los responsables de ejecutar las actividades planeadas, y se asignarán los recursos necesarios para cada una de ellas.

Estimación de tiempos de actividad.

Análisis y aprobación del plan.

Por ejemplo,

1.5. Validación y verificación de sistemas

Planificación.

El objetivo de planificación del proyecto de software es proporcionar un marco de trabajo que facilite hacer estimaciones razonables en cuanto a los recursos, costo y planificación temporal. Estas estimaciones se deben realizar dentro de un plazo de tiempo previamente establecido aunque se deben permitir actualizaciones según vaya progresando el proyecto.

Estas estimaciones deberían definir los escenarios del " mejor caso " y " peor caso " de forma que los resultados del proyecto puedan limitarse.


20

El objetivo de la planificación se logra mediante un proceso de descubrimiento de la información que lleve a estimaciones razonables.

La primera actividad de la planificación del proyecto de Software siempre es determinar el ámbito del software por lo que debemos evaluar aspectos como la función, el rendimiento, las restricciones, las relaciones entre partes del programa y la fiabilidad.

Ejemplo de aplicación para la planificación del desarrollo software, GanttProyect

Métodos formales de verificación.

Entre los métodos de verificación más utilizados se encuentra el de las aserciones E/S. Basado en la lógica de Hoare se especifica mediante aserciones que relacionan las entradas y salidas del programa. Se garantiza que si la entrada actual satisface las restricciones de entrada (precondiciones) la salida satisface las restricciones de salida (poscondiciones).

Se utiliza una expresión del tipo P {programa} Q, siendo P y Q aserciones de la lógica, para indicar que si P es cierto antes de la ejecución del programa y dicho programa termina, entonces Q es cierto tras la ejecución de dicho programa. Este método permite tanto la corrección parcial como total de los programas.

Un caso especial son los bucles, donde los predicados deben mostrar una relación invariante, es decir, deben ser ciertos independientemente del número de vueltas del bucle, por lo tanto el predicado debe cumplir lo siguiente:

Es cierto a la entrada del bucle.

Es cierto en cualquier paso del bucle.

Junto con la negación de la condición del bucle, implica que el predicado se cumple a la salida del bucle.

Precondición más débil. Dada una proposición (P) S (Q) donde S es un conjunto de sentencias de un módulo de un programa, y donde P y Q son los predicados que se cumplen antes y después de S respectivamente, se dice que P es la precondición más débil (wp) de S, si es la condición mínima que garantiza que Q es cierto tras la ejecución de S.


21

Inducción estructural. La inducción estructural es una técnica de verificación formal que se basa en el principio de inducción matemática.

Por ejemplo,

Dado un conjunto S con una serie de propiedades y una proposición P que se desea probar, la inducción matemática:

* Demuestra que P es cierto para el mínimo número de elementos (o casos triviales) de S.

* Asume que P es cierto para un número de elementos (o casos posibles) de S menores o iguales a N.

* Demuestra que entonces P es cierto para el elemento N+11 de S.

Métodos automatizados de análisis.

El testeo automático, tanto funcional como unitario, se divide en dos fases:

Estrategia y planificación. En esa primera fase, se investigan la necesidad y posibilidad del testeo automático.

Prototipo e implementación. En la segunda fase se realiza un prototipo del sistema de testeo automático y se integra en el proceso de desarrollo.

1.6. Pruebas de software

Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento de dicho proceso de desarrollo.

Tipos.

Las pruebas en conjunto tienen como objetivo general verificar y validar un software, independientemente de las características y el entorno donde se desarrollen, además de los recursos y los factores vinculados al proceso de desarrollo.

Funcionalidad.

Función: Pruebas fijando su atención en la validación de las funciones, métodos, servicios, caso de uso.

Seguridad: Asegurar que los datos o el sistema solamente es accedido por los actores deseados.

Volumen: Enfocada en verificando las habilidades de los programas para manejar grandes cantidades de datos, tanto como entrada, salida o residente en la BD.

Usabilidad.

Prueba enfocada a factores humanos, estéticos, consistencia en la interfaz de usuario, ayuda sensitiva al contexto y en línea, asistente documentación de usuarios y materiales de entrenamiento.


22

Fiabilidad.

Integridad: Enfocada a la valoración exhaustiva de la robustez (resistencia a fallos).

Estructura: Enfocada a la valoración a la adherencia a su diseño y formación. Este tipo de prueba es hecho a las aplicaciones Web asegurando que todos los enlaces están conectados, el contenido deseado es mostrado y no hay contenido huérfano.

Stress: Enfocada a evaluar cómo el sistema responde bajo condiciones anormales. (extrema sobrecarga, insuficiente memoria, servicios y hardware no disponible, recursos compartidos no disponible).

Rendimiento.

Benchmark: Es un tipo de prueba que compara el rendimiento de un elemento nuevo o desconocido a uno de carga de trabajo de referencia conocido.

Contención: Enfocada a la validación de las habilidades del elemento a probar para manejar aceptablemente la demanda de múltiples actores sobre un mismo recurso (registro de recursos, memoria).

Carga: La variación en carga es simular la carga de trabajo promedio y con picos que ocurre dentro de tolerancias operacionales normales.

Soportabilidad.

Configuración: Enfocada a asegurar que funciona en diferentes configuraciones de hardware y software. Esta prueba es implementada también como prueba de rendimiento del sistema.

Instalación: Enfocada a asegurar la instalación en diferentes configuraciones de hardware y software bajo diferentes condiciones (insuficiente espacio en disco, etc.)

Pruebas funcionales (BBT).

Las pruebas funcionales se desarrollan usando modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el software a estudiar.

Una prueba funcional es una prueba basada en la ejecución, revisión y retroalimentación de las funcionalidades previamente diseñadas para el software. Las pruebas funcionales se hacen mediante el diseño de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el paquete informático. Con estas pruebas específicas podemos validar que el software hace lo que debe, es decir, lo que se ha especificado previamente.

Pruebas estructurales (WBT).

Este tipo de pruebas son aplicables a varios niveles —unidad, integración y sistema— aunque habitualmente se aplican a las unidades de software.

Su función principal es comprobar los flujos de ejecución dentro de cada unidad pero también pueden analizar los flujos entre unidades durante la integración, e incluso entre subsistemas, durante las pruebas de sistema.

Las principales técnicas de diseño de pruebas de caja blanca son:

Pruebas de flujo de control.

Pruebas de flujo de datos.

Pruebas de bifurcación (branch testing).

Pruebas de caminos básicos.


23

Un ciclo de vida incluye las siguientes fases:

Planificación

Análisis

Diseño

Ejecución

Ciclos

Pruebas finales e implementación

Producción

Comparativa. Pautas de utilización.

Planificación de las pruebas (Fase de definición del producto).

La fase de planificación de pruebas significa redactar el test plan ó plan de pruebas que es un documento a alto nivel que describe las estrategias a seguir durante el desarrollo de las pruebas.

Análisis de pruebas (Fase de documentación).

La fase de análisis es una extensión de la fase de la planificación. Mientras que la fase de planificación es a más alto nivel, la fase de análisis es donde se comienza a documentar los planes detallados.

Se comienza a analizar los casos de prueba:

Revisión de los inputs.

Formatos. Generalmente en esta fase se crea una matriz de validación basada en los requisitos.

Test Cases (casos de prueba). Siguiendo la matriz de validación y otros documentos de entrada (inputs), se escriben los test cases. Comenzamos también a vincular los requisitos con cada test case.

Automatización. Mientras se crean test cases, se identifican los casos que deben ser automatizados. También se identifican las áreas para las pruebas de rendimiento, de carga y de stress.

Plan de Regresión: Los ciclos de pruebas, es decir, número de veces que se probará de nuevo la aplicación para verificar que los defectos encontrados no han introducido nuevos errores.

Diseño de pruebas.

El ciclo de vida de las pruebas transcurre prácticamente en paralelo al de desarrollo.

Durante esta fase todos los planes, test cases, etc.… de la fase de análisis son revisados y finalizados.


24

Pueden ser añadidos nuevos elemento de prueba y preparar el documento de gestión de riesgos. También se deben desarrollar los scripts de pruebas automáticas y, por supuesto, los informes de pruebas, especialmente los informes sobre pruebas unitarias.

Ámbitos de aplicación.

Lo más recomendable es hacer un test de cualificación de la versión para evaluar que la aplicación es lo suficientemente estable para comenzar la ejecución de las pruebas.

De nada serviría comenzar una ronda de test si con unas cuantas acciones la aplicación rompe. Es necesario un mínimo de estabilidad.

Para llevar el seguimiento de la ejecución de los test cases se pueden utilizar alguna de las herramientas comerciales que hay en el mercado ó utilizar una matriz de hoja de cálculo (Excel, Calc) donde iremos apuntado nuestros PASSED o FAILED (OK or NOT).

Pruebas de Sistemas.

Las pruebas del sistema tienen un propósito particular que es comparar el sistema o el programa con sus objetivos originales (requerimientos funcionales y no funcionales).

Partiendo de esta premisa se presentan dos implicaciones:

1. Las pruebas de sistema no se limitan a los sistemas. Si el producto es un programa, la prueba del sistema es el proceso de procurar demostrar cómo el programa, en su totalidad, no resuelve sus objetivos o requerimientos.

2. Las pruebas de sistema, por definición, son imposibles si no están los requerimientos por escrito, mensurables para el producto.

Las pruebas de sistema tienen como objetivo ejercitar profundamente el sistema comprobando la integración del sistema de información globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica.


25

Existen diferentes tipos de pruebas como podemos ver en la tabla siguiente.

Pruebas de comunicaciones.

Pruebas de rendimiento.

Pruebas de recuperación

Pruebas de volumen.

Pruebas de sobrecarga.

Pruebas de tensión.

Pruebas de disponibilidad de datos.

Pruebas de facilidad de uso.

Pruebas de operación.

Pruebas de entorno.

Pruebas de seguridad.

Pruebas de usabilidad.

Pruebas de almacenamiento.

Pruebas de configuración.

Pruebas de instalación.

Pruebas de la documentación.

Pruebas de componentes.

Se realizan pruebas de forma individual sobre componentes del software para los cual se dispone de documentación con su especificación independiente.

Las pruebas de software (en inglés software testing) son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Se trata de una actividad más en el proceso de control de calidad.

Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento de dicho proceso de desarrollo.


26

Existen distintos modelos de desarrollo de software, así como modelos de pruebas. A cada uno corresponde un nivel distinto de involucramiento en las actividades de desarrollo.

Pruebas estáticas.

Son el tipo de pruebas que se realizan sin ejecutar el código de la aplicación. Puede referirse a la revisión de documentos, ya que no se hace una ejecución de código. Esto se debe a que se pueden realizar "pruebas de escritorio" con el objetivo de seguir los flujos de la aplicación.

Pruebas dinámicas.

Todas aquellas pruebas que para su ejecución requieren la ejecución de la aplicación. Las pruebas dinámicas permiten el uso de técnicas de caja negra y caja blanca con mayor amplitud. Debido a la naturaleza dinámica de la ejecución de pruebas es posible medir con mayor precisión el comportamiento de la aplicación desarrollada.

Automatización de pruebas. Herramientas.

En el mercado existen variadas herramientas. Veamos alguna de ellas.

HP Quicktest Professional (QTP).

Proporciona la capacidad de automatizar pruebas funcionales y pruebas de regresión para software y ambientes de prueba. Proporciona la capacidad de definir Scripts de prueba y posee una interfaz gráfica que le permiten al usuario emular la funcionalidad que desea probar, incluyendo el uso de interfaces de usuario de las aplicaciones a probar. Incluye características como: Vista de experto, pruebas de procesos de negocio, grabado de pantalla (para captura de las evidencias de prueba), entre otras posibilidades.


27

Watir.

Forma parte de la familia de librerías Ruby de Código Abierto (Open Source) para la automatización de navegadores web. Le permite a su usuario escribir pruebas fáciles de leer y mantener. Sencilla y flexible. Tiene la capacidad de hacer clic en enlaces, llenar formularios de pantallas con datos y presionar botones. Tiene la capacidad de enlazarse con bases de datos, leer archivos de datos y hojas de cálculo, exportar XML y estructurar los códigos como librerías reutilizables.

Selenium.

Es un framework para pruebas de aplicaciones Web, descargable de forma gratuita desde su sitio web. Proporciona una herramienta de grabación y playback, que permite desarrollar pruebas sin necesidad de aprender un lenguaje de Scripting. Incluye características como grabación, playback, selección de campos, auto completar formularios, pruebas de recorrido (Walkthrough), debug, puntos de control, scripts ruby y otros formatos.


28

Visual Studio Test Proffessional.

Conjunto de herramientas de pruebas integradas desarrolladas por Microsoft, que proporcionan soporte a todo el ciclo de planificación, ejecución y registro de pruebas, con facilidades de colaboración entre analistas de prueba (testers) y desarrolladores en la herramienta. Proporciona capacidad de realizar pruebas manuales, reutilización de pruebas manuales, integración con el “team foundation server”, gestión de ciclo de vida de aplicaciones, entre otros.

Rational Functional Tester.

Herramienta de automatización de pruebas funcionales y de regresión. Proporciona capacidades de pruebas de interfaz gráfica, pruebas manejadas por datos (Data Driven), pruebas funcionales y pruebas de regresión. Algunas de sus características son: Simplificación de creación y visualización de pruebas, pruebas de tipo storyboards, trazabilidad en todo el ciclo de vida, validación de data dinámica (por medio de un wizard), e inclusive capacidad de definir scripts (por medio de lenguajes de Scripting).


29

Estándares sobre pruebas de software.

Las pruebas de software son un elemento imprescindible y crítico para la validación de un producto de software. Dichas pruebas de software deben apoyarse en estándares que revisan los aspectos fundamentales que debe considerar todo proceso de pruebas.

El estándar ISO/IEC 29119 para pruebas de software es un referente internacional en el ámbito de las pruebas software y permite eliminar las inconsistencias existentes entre las normas actuales.

La estructura de ISO/IEC 29119 consta de cuatro partes:

1. Conceptos y Vocabulario. 2. Proceso de Pruebas. 3. Documentación de Pruebas. 4. Técnicas de Prueba.

Las partes 2 (procesos) y 3 (documentación) han sido planificadas en una primera secuencia, que tras sucesivas revisiones por expertos externos e internos a los diferentes comités producirán los primeros borradores del comité (Committee Draft: CD) para continuar con los procesos de tramitación y revisión habituales en la elaboración de los estándares ISO.

Son varias las normas que las principales organizaciones internacionales de normalización (ISO, IEEE, BSI, etc.) han publicado relacionadas directa o indirectamente con las pruebas de software.

1.7. Calidad de software

En el desarrollo de software, la calidad de diseño debe acompañar al desarrollo de los requisitos, especificaciones y diseño del sistema. La calidad de concordancia es un aspecto centrado principalmente en la implementación; Si la implementación sigue al diseño, y el sistema resultante cumple con los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta.

El software puede tener errores, incidencias pero no son similares a lo que cualquier equipo de carácter físico.


30

Principios de calidad del software.

Watts Humphrey, considerado padre de la calidad de los procesos software planteó seis principios de la calidad:

1. Principio 1: Si un cliente no demanda calidad probablemente no la conseguirá. 2. Principio 2: Para obtener calidad de manera constante los desarrolladores deben gestionarla

en su trabajo. 3. Principio 3: Para gestionar la calidad los desarrolladores deben medirla. 4. Principio 4: La calidad de un producto la determina el proceso usado para desarrollarlo. 5. Principio 5: Ya que las pruebas solucionan solo una fracción de los defectos, debes tener

pruebas de calidad. 6. Principio 6: La calidad solo la producen profesionales motivados orgullosos de su trabajo.

Métricas y calidad del software.

Las posibilidades de que aparezca el fallo humano en el proceso de desarrollo de software son enormes. Es complicado realizar un buen software, y muchos de los productos que se construyen tienen calidad insuficiente, además de no acertar con las estimaciones de tiempo y recursos inexactos para la construcción de los mismos.

Los responsables expertos de compañías reconocen que la alta calidad ahorro de coste y mejora general. Además, todos los métodos, herramientas y procedimientos que constituyen la Ingeniería del Software van orientados a un único fin: producir software de calidad.

La calidad del software es, según Pressman, la “concordancia con los requisitos funcionales y de rendimiento, con los estándares de desarrollo y con las características implícitas que se espera del software desarrollado profesionalmente”.

No existe una definición única de calidad debido a las siguientes cuestiones:

Es un concepto relativo.

Es un concepto multidimensional.

Está ligada a restricciones (por ejemplo, el presupuesto).

Está ligada a compromisos aceptables (por ejemplo, plazos de fabricación).

No es ni totalmente subjetiva ni objetiva.

Puede resultar transparente cuando está presente y reconocible cuando está ausente.

La calidad del software se plantea siempre a dos niveles:

1. A nivel de empresa: para conseguir software de calidad, las organizaciones deben tener una estructura organizativa apropiada para fomentar el trabajo por la calidad de todas las personas y departamentos de la empresa, además de fomentar procesos específicos para asegurar la calidad.

2. A nivel de proyecto: se trata de llevar a la práctica en las actividades cotidianas las disposiciones fijadas en el sistema de calidad. Se aplica durante todo el proceso de ingeniería del software, es decir, en Análisis, Diseño, Codificación y Prueba.

Las métricas del software se aplican para valorar cualitativamente algún factor relativo al mismo. No existen métricas generales y únicas, aún menos para la calidad, ya que se puede examinar el software a través de múltiples perspectivas y con diferentes objetivos.


31

Las características que debe tener una buena métrica son:

Simple y fácil de calcular.

Empírica.

Consistente y objetiva.

Independiente del lenguaje de programación.

Que proporcione información útil.

Veremos las más representativas en cada fase del ciclo de vida.

No existen demasiadas métricas en esta etapa debido a que se están tratando temas de muy alto nivel conceptual, difíciles de cuantificar. Las más representativas miden el tamaño del software a desarrollar:

Esquemáticamente distinguimos un sistema complejo de uno sistema simple,

Otras métricas de complejidad son las de Card y Glass que se basan en dos factores, calculados para cada módulo a partir del diagrama de estructuras:

Complejidad estructural: número de módulos que controla un módulo dado

Complejidad de datos: suma de variables de entrada y salida de un módulo (dividido por el número de módulos que controla, para que no influya la complejidad estructural)

La complejidad del sistema se calcula como la suma de la complejidad estructural y la complejidad de datos de cada módulo

Las métricas de cohesión y acoplamiento sirven para cuantificar la cohesión y acoplamiento de los módulos en programación estructurada. A partir de los parámetros de entrada, los parámetros de salida, las variables globales utilizadas y el fan-in y fan-out de los módulos, genera un valor que es menor cuanto mejores son la cohesión y el acoplamiento.

Otro ejemplo de métrica para conocer la calidad del software es la profundidad árbol de herencia.

Cuanto mayor es la profundidad, menor es la calidad del software.


32

Concepto de métrica y su importancia en la medición de la calidad.

En el campo de la ingeniería del software una métrica es cualquier medida o conjunto de medidas destinadas a conocer o estimar el tamaño u otra característica de un software o un sistema de información, generalmente para realizar comparativas o para la planificación de proyectos de desarrollo. Un ejemplo ampliamente usado es la llamada métrica de punto función .

Existen diferentes metodologías de medición, de las cuales la más popular es la mantenida por el International Function Point Users Group (IFPUG).

Principales métricas en las fases del ciclo de vida software.

Para aplicar el sistema de calidad al ciclo de vida es necesaria la utilización de métricas adecuadas que permitan medir la calidad del proyecto.

La medición es fundamental para cualquier disciplina de ingeniería, y la ingeniería del Software no es una excepción.

Las métricas del Software se refieren a un amplio elenco de medidas para el Software de computadora. La medición se puede aplicar al proceso de Software con el intento de mejorarlo sobre una base continua.

Definimos las métricas o medidas de software como la aplicación continua de técnicas basadas en las medidas de los procesos de desarrollo de Software y sus productos, para producir una información de gestión significativa y a tiempo. Esta información se utilizará para mejorar esos procesos y los productos que se obtienen de ellos.

Estas medidas son aplicables a todo el ciclo de vida del desarrollo, desde la iniciación, cuando debemos estimar los costos, al seguimiento y control de la fiabilidad de los productos finales, y a la forma en que los productos cambian a través del tiempo debido a la aplicación de mejoras.

Las medidas del software y los modelos de medida son entonces útiles para estimar y predecir costos y para medir la productividad y la calidad del producto.

Un ingeniero del software recopila medidas y desarrolla métricas para obtener indicadores.

Estándares para la descripción de los factores de Calidad.

En un escenario en el que los sistemas de software se desarrollan y construyen por terceros proveedores, el contratante del servicio, como primer receptor del mismo, en muchos casos debe confiar en el buen hacer del proveedor seleccionado, especialmente si no dispone de los medios apropiados para auditar la entrega y en su caso argumentar defectos en el proceso de desarrollo.

En general, una vez validado que el sistema responde a los principales requisitos funcionales especificados, el usuario realizará las pruebas de aceptación, corrigiéndose los errores encontrados y traspasándose al fin al entorno de producción. Sin embargo, en muy pocas ocasiones se validan de manera rigurosa los requisitos funcionales y los no funcionales, o se ejecutan validaciones que aseguren que el sistema es lo suficientemente robusto y estable como para pasar a un entorno productivo con las garantías adecuadas.

Por ejemplo, no se realizan estimaciones de los recursos necesarios para el sistema, imprescindibles para un adecuado dimensionamiento de los servidores, o se anticipan eventuales picos de trabajo, o en resumen, todo aquello que al fin asegure la satisfacción total del usuario.


33

Hay que considerar entonces que estas eventualidades además de provocar un coste económico importante, principalmente por el elevado número de personas involucradas en su resolución, también producen la pérdida de confianza de los usuarios en el sistema.

ISO-9126.

Esta norma definida por un marco conceptual basado en los factores tales como Calidad del Proceso, Calidad del Producto del Software y Calidad en Uso; según el marco conceptual, la calidad del producto, a su vez, contribuye a mejorar la calidad en uso.

La norma ISO/IEC 9126 presentan dos modelos de calidad, el primero referido a la calidad interna y externa y el segundo modelo referido a la calidad en uso, a continuación se describe cada uno de ellos.

La calidad externa se define como la totalidad de las características del producto software desde una perspectiva externa. Es la calidad del software cuando es ejecutado, la cual es típicamente medida y evaluada mientras se prueba en un ambiente simulado, con datos simulados y usando métricas externas. Durante las pruebas, muchas fallas serán descubiertas y eliminadas. Sin embargo algunas fallas todavía pueden permanecer después de las pruebas. Como es difícil corregir la arquitectura de software u otros aspectos fundamentales del diseño del software, el diseño fundamental permanece sin cambios a través de las pruebas.

Las características y cualidades de la calidad externa e interna pueden verse en el siguiente esquema,

Otros estándares. Comparativa.

NORMA ISO/IEC - 14598

Establece un marco de trabajo para evaluar la calidad de los productos de software proporcionando, además, métricas y requisitos para los procesos de evaluación de los mismos.


34

La norma define las principales características del proceso de evaluación:

Repetitividad.

Reproducibilidad.

Imparcialidad.

Objetividad.

Para estas características se describen algunas medidas concretas:

Análisis de los requisitos de evaluación.

Evaluación de las especificaciones.

Evaluación del diseño y definición del plan de evaluación.

Ejecución del plan de evaluación.

Evaluación de la conclusión.

NORMA ISO/IEC 25000 (SquaRE)

Su objetivo principal es guiar el desarrollo de los productos de software con la especificación y evaluación de requisitos de calidad. Establece criterios para la especificación de requisitos de calidad de productos software, sus métricas y su evaluación.

Al igual que la norma ISO/IEC 9126, este estándar define tres vistas diferenciadas en el estudio de la calidad de un producto:

1. Vista interna: esta vista se ocupa de las propiedades del software como: el tamaño, la complejidad o la conformidad con las normas de orientación a objetos.

2. Vista externa. 3. Vista en uso: mide la productividad y efectividad del usuario final al utilizar el software.

La primera puede utilizarse desde las primeras fases del desarrollo, permitiendo detectar deficiencias en el software en edades muy tempranas del ciclo de vida del software.

La segunda, sin embargo, necesita que el producto software este completo y se utilizará por tanto en el pase a producción del producto, siendo muy dependiente de la máquina donde se ejecute.

Por último la tercera vista que también estudia el producto software finalizado será dependiente del usuario y estará condicionada a los factores personales del mismo.

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

El proceso de desarrollo de aplicaciones de software normalmente involucra varias etapas. El desarrollo de software puede ser una actividad compleja y larga, por lo que las herramientas disponibles pueden reducir el estrés y aumentar el desempeño tanto de desarrolladores como de las aplicaciones resultantes. Hay herramientas disponibles para cada etapa en el proceso de desarrollo de software.

Editores orientados a lenguajes de programación.

Un editor es un programa que permite la creación y edición de archivos de texto. Para desarrollar un programa basta con un simple editor como el bloc de notas de Windows.


35

Las características que aportan estos programas de forma genérica son:

Coloreado de sintaxis

Edición de múltiples archivos

Formateo de textos

Conexiones con repositorio o FTP

Enlaces a otras herramientas como compiladores, repositorios, etc.

Entre los más conocidos podemos destacar Notepad++ y SublimeText2.

Compiladores y enlazadores.

Un compilador es un programa que permite traducir el código fuente de un programa en lenguaje de alto nivel, a otro lenguaje de nivel inferior (típicamente lenguaje de máquina). De esta manera un programador puede diseñar un programa en un lenguaje mucho más cercano a cómo piensa un ser humano, para luego compilarlo a un programa más manejable por una computadora.

Como parte importante de este proceso de traducción, el compilador informa a su usuario de la presencia de errores en el programa fuente.

Un enlazador (en inglés, linker) es un programa que toma los objetos generados en los primeros pasos del proceso de compilación, la información de todos los recursos necesarios (biblioteca), quita aquellos recursos que no necesita, y enlaza el código objeto con sus bibliotecas con lo que finalmente produce un fichero ejecutable o una biblioteca. En el caso de los programas enlazados dinámicamente, el enlace entre el programa ejecutable y las bibliotecas se realiza en tiempo de carga o ejecución del programa.

Generadores de programas.

Son herramientas que crean software basado en algún lenguaje de programación sin necesidad de tener nociones del mismo.

Por ejemplo PHPRuner permite generar una interfaz plenamente funcional en PHP sobre una base de datos partiendo de la misma.

Otros serían Adobe Muse que habilita al usuario para desarrollar un sitio web basado en la combinación de HTMl5, CSS3 y Javascript.

Depuradores.

Un depurador (en inglés, debugger), es un programa usado para probar y depurar (eliminar los errores) de otros programas (el programa "objetivo"). El código a ser examinado puede alternativamente estar corriendo en un simulador de conjunto de instrucciones (ISS), una técnica que permite gran potencia en su capacidad de detenerse cuando son encontradas condiciones específicas pero será típicamente algo más lento que ejecutando el código directamente en el apropiado (o el mismo) procesador. Algunos depuradores ofrecen dos modos de operación - la simulación parcial o completa, para limitar este impacto.

Los depuradores también ofrecen funciones más sofisticadas tales como correr un programa paso a paso (un paso o animación del programa), parar el programa (breaking), es decir, pausar el programa para examinar el estado actual en cierto evento o instrucción especificada por medio de un breakpoint, y el seguimiento de valores de algunas variables. Algunos depuradores tienen la capacidad de modificar el estado del programa mientras que está corriendo, en vez de simplemente observarlo.


36

La misma funcionalidad que hace a un depurador útil para eliminar errores permite ser usado como herramienta de craqueo de software para evadir la protección anticopia, la gestión digital de derechos, y otras características de protección de software. A menudo también lo hace útil como herramienta general de verificación de pruebas, cobertura de fallas, o analizador de desempeño, especialmente si son mostradas las longitudes de trayectoria de instrucción.

De prueba y validación de software.

Algunas herramientas ofrecen entornos integrados que soportan las pruebas y el desarrollo a lo largo de la vida de un proyecto, desde la reunión de los requisitos hasta el soporte del funcionamiento en vivo del sistema. Algunos proveedores se enfocan en una sola parte del ciclo de vida. La base de conocimientos de las herramientas de prueba de software proporciona los criterios funcionales que se esperan de una herramienta de pruebas, la infraestructura que la soporta y una idea de la posición que ocupa el proveedor en el mercado.

Optimizadores de código.

Un compilador optimizador es un compilador que trata de minimizar ciertos atributos de un programa informático con el fin de aumentar la eficiencia y rendimiento. Las optimizaciones del compilador se aplican generalmente mediante una secuencia de transformaciones de optimización, algoritmos que transforman un programa para producir otro con una salida semánticamente equivalente pero optimizada.

Generalmente hay varios aspectos que se desean optimizar:

Optimización temporal.

Optimización espacial.

Reducir el tamaño del programa.

Minimizar la potencia consumida por un programa (debido a las computadoras portátiles).

Las tareas del front-end (exploración, análisis sintáctico, análisis léxico, análisis semántico) son bien conocidas y, sin optimizar, la generación de código es relativamente sencilla. La optimización, por otra parte, aún es un campo que no se ha terminado de desarrollar de forma completa.

Empaquetadores.

Estos paquetes están formados por los programas ejecutables de la aplicación, así como por todas las bibliotecas de las que depende y otros tipos de ficheros (como imágenes, ficheros de audio, traducciones y localizaciones, etc.), de forma que se proporcionan como un conjunto. Las bibliotecas de las que depende el programa pueden haber sido enlazadas tanto de forma dinámica como también estática. Por tanto, el usuario percibe que el paquete como un conjunto que representa al programa en sí, cuando en realidad incluye varios ficheros.

El empaquetado de aplicaciones permite evitar los problemas de las dependencias tanto a la hora de instalar la aplicación como a la hora de usarla, ya que cada paquete lleva consigo sus dependencias, y la instalación o desinstalación de otro software no va a afectar a las dependencias de dicho paquete.

La principal ventaja del empaquetado de aplicaciones es precisamente que se evitan la problemática de las dependencias, y que la aplicación se puede trasladar de un computador a otro sin necesidad de reinstalarla, ya que el paquete de la aplicación contiene todos los ficheros necesarios para ejecutarla. Sin embargo, como desventaja se presenta que estos paquetes ocupan mucho más espacio en el disco, especialmente si el paquete incluye bibliotecas.


37

Generadores de documentación de software.

Un generador de documentación es una herramienta de programación que genera documentación destinada a los programadores (documentación de API) o a usuarios finales, o a ambos, a partir de un conjunto de código fuente especialmente documentado, y en algunos casos, archivos binarios.

Los tipos de documentos a los que nos referimos son:

Documentos batch (documentos automatizados).

Documentos interactivos (documentos que no pueden ser producidos automáticamente).

Formularios (formularios para páginas web).

Gestores y repositorios de paquetes. Versionado y control de dependencias.

Los paquetes incluyen información importante además del propio software, como pueden ser el nombre completo, una descripción de su funcionalidad, el número de versión, el distribuidor del software, la suma de verificación y una lista de otros paquetes requeridos para el correcto funcionamiento del software. Esta metainformación se introduce normalmente en una base de datos de paquetes local.

El versionado de software es el proceso de asignación de un nombre o número único a un software para indicar su nivel de desarrollo. Generalmente se asigna dos números, mayor.menor (en inglés: major.minor), que van incrementando conforme el desarrollo del software aumente y se requiera la asignación de un nuevo nombre o número único. Aunque menos habituales, también puede indicarse otro número más, micro, y la fase de desarrollo en que se encuentra el software.

De distribución de software.

Una distribución de software es un conjunto de software específico ya compilado y configurado. Pueden tomar formas de licencia como son GPL u open source o también puede trabajar bajo una distribución binaria, es decir, un instalador (.exe) que pueda ser descargado desde Internet.

Una licencia es un contrato entre el desarrollador de un software y el usuario, en el cual se definen con precisión los derechos y deberes de ambas partes. Es el desarrollador, o aquél a quien éste haya cedido los derechos de explotación, quien elige la licencia según la cual distribuye el software.

Por otro lado, una patente es el conjunto de derechos exclusivos garantizados por la autoridad al inventor de un nuevo producto (material o inmaterial) susceptible de ser explotado industrialmente para el bien del solicitante por un periodo de tiempo limitado.

Los derechos de autor o copyright es la forma de protección proporcionada por las leyes vigentes en la mayoría de los países para los autores de obras originales incluyendo obras literarias, dramáticas, musicales, artísticas e intelectuales, tanto publicadas como pendientes de publicar.

Habitualmente el software se distribuye en forma de paquetes, frecuentemente encapsulado en un solo fichero. Estos paquetes incluyen otra información importante, además del software mismo, como pueden ser el nombre completo, una descripción de su funcionalidad, el número de versión, el distribuidor del software, la suma de verificación y una lista de otros paquetes requeridos para el correcto funcionamiento del software.


38

Gestores de actualización de software.

Los sistemas operativos incluidos los smartphones disponen de una tienda de aplicaciones propia con programas de actualización.

Es posible instalar programas que centralizan las renovaciones haciendo más cómoda su gestión al usuario y mejoran el funcionamiento del móvil, portátil, PC o tablet.

Este proceso en los ordenadores es más complicado, al ser mayor el número de aplicaciones instaladas. Habitualmente se recomienda configurarlas para que sólo se puedan actualizar de modo manual y cuando el usuario lo indique.

En el sistema operativo GNU/Linux, este problema está resuelto con la utilización de Synaptic Package Manager, un programa para la gestión de paquetes de aplicaciones. Utiliza los diferentes repositorios de archivos para la gestión y actualización, mediante un entorno gráfico sencillo, de todos los paquetes instalados en el sistema.

Los sistemas operativos Windows XP y Windows Vista, en cambio, disponen de un gestor de actualizaciones que resulta muy útil para mantener el sistema operativo al día, pero que deja fuera todas las aplicaciones de terceros instaladas en el ordenador. Para solucionarlo, diferentes propuestas gestionan la actualización de los programas externos a Windows de forma sencilla.

Algunas aplicaciones populares para Windows son:

SUMo (Software Updates Monitor) es una aplicación gratuita para los sistemas operativos Windows que disponen de un método de detección automática del software instalado, para buscar actualizaciones o parches. SUMo no realiza la puesta al día de software, sino que avisa cuando la actualización es posible e indica al usuario la dirección de Internet donde descargar e instalar la nueva versión.

UpdateStar es un buscador de actualizaciones que almacena una gran cantidad de programas en su base de datos para controlar las nuevas versiones.

FileHippo Update Checker es una pequeña aplicación gratuita para el sistema operativo Windows. El servicio revisa las aplicaciones e informa de cuáles requieren ser actualizadas.

De control de versiones.

Se llama control de versiones a la gestión de los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo. Una versión, revisión o edición de un producto, es el estado en el que se encuentra dicho producto en un momento dado de su desarrollo o modificación. Aunque un sistema de control de versiones puede realizarse de forma manual, es muy aconsejable disponer de herramientas que faciliten esta gestión dando lugar a los llamados sistemas de control de versiones o SVC

Ejemplos de este tipo de herramientas son entre otros: CVS, Subversion, SourceSafe, ClearCase, Darcs, Bazaar , Plastic SCM, Git, Mercurial, Perforce.

El control de versiones se realiza principalmente en la industria informática para controlar las distintas versiones del código fuente dando lugar a los sistemas de control de código fuente o SCM (siglas del inglés Source Code Management). Sin embargo, los mismos conceptos son aplicables a otros ámbitos como documentos, imágenes, sitios web, etc.


39

Un sistema de control de versiones debe proporcionar:

Mecanismo de almacenamiento de los elementos que deba gestionar (ej. archivos de texto, imágenes, documentación...).

Posibilidad de realizar cambios sobre los elementos almacenados (ej. modificaciones parciales, añadir, borrar, renombrar o mover elementos).

Registro histórico de las acciones realizadas con cada elemento o conjunto de elementos (normalmente pudiendo volver o extraer un estado anterior del producto).

Aunque no es estrictamente necesario, suele ser muy útil la generación de informes con los cambios introducidos entre dos versiones, informes de estado, marcado con nombre identificativo de la versión de un conjunto de ficheros, etc.

Entornos integrados de desarrollo (IDE) de uso común.

Un IDE es un entorno de programación que ha sido empaquetado como un programa de aplicación; es decir, consiste en un editor de código, un compilador, un depurador y un constructor de interfaz gráfica (GUI). Los IDEs pueden ser aplicaciones por sí solas o pueden ser parte de aplicaciones existentes.

Por ejemplo, el lenguaje Visual Basic puede ser usado dentro de las aplicaciones de Microsoft Office, lo que hace posible escribir sentencias Visual Basic en forma de macros para Microsoft Word.

Los IDE proveen un marco de trabajo amigable para la mayoría de los lenguajes de programación tales como C++, PHP, Python, Java, C#, Delphi, Visual Basic, etc. En algunos lenguajes, un IDE puede funcionar como un sistema en tiempo de ejecución, en donde se permite utilizar el lenguaje de programación en forma interactiva, sin necesidad de trabajo orientado a archivos de texto, como es el caso de Smalltalk u Objective-C.

Los elementos que conforman estas herramientas suelen ser los siguientes:

Un editor de texto.

Un compilador.

Un intérprete.

Un depurador.

Un cliente.

Posibilidad de ofrecer un sistema de control de versiones.

Factibilidad para ayuda en la construcción de interfaces gráficas de usuario.

1.9. Gestión de proyectos de desarrollo de software

Los proyectos de desarrollo de software se diferencian de los otros proyectos de ingeniería tradicional en la naturaleza lógica del producto software.

La gestión del proyecto de software es el primer nivel del proceso de ingeniería de software, porque cubre todo el proceso de desarrollo. Para conseguir un proyecto de software fructífero se debe comprender el ámbito del trabajo a realizar, los riesgos en los que se puede incurrir, los recursos requeridos, las tareas a llevar a cabo, el esfuerzo (costo) a consumir y el plan a seguir.


40

Planificación de proyectos.

El objetivo de la planificación de proyectos es obtener una distribución de las actividades en el tiempo y una utilización de los recursos que minimice el coste del proyecto cumpliendo con los condicionantes exigidos (plazo de ejecución, tecnología a utilizar, recursos disponibles, nivel máximo de ocupación de dichos recursos).

Por tanto la planificación de proyectos es una programación de actividades y una gestión de recursos para obtener un objetivo de coste cumpliendo con los condicionantes exigidos por nuestro cliente.

La programación de actividades debe aportar al director de proyecto un calendario de ejecución del proyecto donde se refleje la fecha de inicio y finalización de las distintas actividades en que se ha descompuesto el proyecto.

Para poder definir dicho calendario se hace necesario conocer la duración de cada actividad y su orden, así como la fecha de inicio del proyecto.

Por ejemplo,

Control de proyectos.

El control de proyecto tiene como objetivo principal el mantener el proyecto alineado con sus objetivos. Todas las dimensiones del proyecto han de ser gestionadas de manera concurrente, integrando costes, plazo, alcance y calidad en el método de control utilizado. De poco serviría un producto que cumpliera con los objetivos de costes, plazos y alcance, pero que no tuviese la calidad especificada, o un producto con la calidad adecuada pero con un coste o un retraso que le hagan no ser competitivo.

Gracias al control de proyecto podemos comparar entre los valores planificados e incurridos:

Evaluar la actuación o ejecución pasada en cualquier instante de la vida del proyecto.

Analizar tendencias futuras que permitan estimar los costes y plazos de finalización del proyecto (método del valor ganado).

Ejecución de proyectos.

Esta es la etapa de desarrollo del trabajo en sí. Esta etapa es responsabilidad del contratista, con la supervisión del cliente. Durante la ejecución del proyecto, se debe poner énfasis en la comunicación para tomar decisiones lo más rápido posible en caso de que surjan problemas.


41

Así, es posible acelerar el proyecto estableciendo un plan de comunicación, por ej., a través de:

El uso de un tablero que muestre gráficamente los resultados del proyecto, permitiendo que el director del proyecto arbitre en caso de variaciones.

Un informe de progreso que permita a todas las personas involucradas en el proyecto estar informadas sobre las acciones en progreso y aquellas terminadas. Generalmente, "informar" incluye la preparación completa y la presentación de informes sobre las actividades.

Además, se deberán organizar regularmente (una vez por semana, preferentemente) reuniones para administrar el equipo del proyecto, es decir, discutir regularmente el progreso del proyecto y determinar las prioridades para las siguientes semanas.

Herramientas de uso común para la gestión de proyectos.

Las herramientas más habituales con las que podemos trabajar son:

@Task

AceProject.

Dekker Trakker.

ConceptDraw Project.

VPMi Professional.

Project Tracker.

Intellisys Project Desktop.

Infowit Creative Manager.


42

MinuteMan.

SmartWork Project Planner.

YZ Project Manager.

TargetProcess.

Acteo.


43

Recuerda…

Entre los métodos de verificación más utilizados no se encuentra el de las oportunidades. Basado en la lógica de Hoare se especifica mediante aserciones que relacionan las entradas y salidas del programa.

El desarrollo incremental no es un proceso de construcción que incrementa de forma directa los requerimientos del sistema.

En la especificación de requisitos los casos de uso también son conocidos como Requisitos funcionales.

La llamada mejora y garantía de calidad asegura que los resultados que se proporcionan sean completos y contengan la calidad deseada.

El concepto "informar" incluye la preparación completa y la presentación de informes sobre las actividades.

Las posibilidades de que aparezca el fallo humano en el proceso de desarrollo de software son muy altas.

La primera actividad de la planificación del proyecto de software siempre es determinar el ámbito del software.

El enunciado "Para gestionar la calidad los desarrolladores deben medirla." pertenece a los principios de calidad de Watts Humphrey.

La Prueba funcional está basada en la ejecución, revisión y retroalimentación de las funcionalidades previamente diseñadas para el software

El diagrama de flechas completo da una representación gráfica de las relaciones entre las actividades del proyecto.


44

2. LA ORIENTACIÓN A OBJETOS

La programación estructurada anima al programador a pensar sobre todo en términos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan.

En la programación estructurada solo se escriben funciones que procesan datos. Los programadores que emplean POO, en cambio, primero definen objetos para luego enviarles mensajes solicitándoles que realicen sus métodos por sí mismos.

2.1. Principios de la orientación a objetos. Comparación con la programación estructurada

Ocultación de información (information hiding).

En informática denominamos principio de ocultación de información a la desaparición controlada y temporal de decisiones de diseño en un programa con la idea de proteger a otras partes del código.

Proteger una decisión de diseño supone proporcionar una interfaz estable que proteja el resto del programa de la implementación (y que sean susceptible de cambios).

Por ejemplo la encapsulación, que en los lenguajes de programación modernos es una forma de expresión del principio de ocultación de información.

El término encapsulación a menudo se utiliza como sinónimo de la ocultación de información pero tan similitud no se ajusta exactamente a la realidad.

No existe un acuerdo sobre las diferencias, siendo común la idea de que la ocultación de información es el principio mientras que la encapsulación es la técnica.

Por ejemplo, un módulo de software oculta información encapsulándola en otro módulo u otra construcción con la que se comunica mediante una interfaz.

El uso más común de la ocultación de información es ocultar el diseño del almacenamiento físico de los datos, de manera que si dicho diseño es modificado solamente afecte a un pequeño subconjunto del programa total.

Por ejemplo, si un punto tridimensional de coordenadas (x, y, z) es representado en un programa con tres variables escalares de coma flotante y posteriormente dicha representación es modificada a una variable array de tamaño 3, un módulo diseñado mediante la ocultación de información en principio protegería al resto del programa de este cambio.

El tipo abstracto de datos (ADT). Encapsulado de datos.

En programación orientada a objetos, se denomina encapsulamiento al ocultamiento del estado, es decir, de los datos miembro de un objeto de manera que sólo se pueda cambiar mediante las operaciones definidas para ese objeto.

Cada objeto está aislado del exterior, es un módulo natural, y la aplicación entera se reduce a un agregado o rompecabezas de objetos. El aislamiento protege a los datos asociados de un objeto contra su modificación por quien no tenga derecho a acceder a ellos, eliminando efectos secundarios e interacciones.


45

Con esto se consigue que la clase pueda obviar la implementación de los métodos y propiedades para concentrarse sólo en cómo usarlos así como evitar que el usuario pueda cambiar su estado de maneras imprevistas e incontroladas.

Las formas de encapsular conocidas son:

Estándar (Predeterminado).

Abierto: El miembro de la clase puede ser accedido desde el exterior de la clase o desde cualquier parte del programa.

Protegido: Sólo es accesible desde la propia clase y desde las clases que heredan (a cualquier nivel).

Semi cerrado: Sólo es accesible desde la clase heredada.

Cerrado: Solo es accesible desde la propia clase.

En el encapsulamiento hay analizadores que pueden ser semánticos y sintácticos.

Paso de mensajes.

MPI (Message Passing Interface, Interfaz de Paso de Mensajes) es un estándar que define la sintaxis y la semántica de las funciones contenidas en una biblioteca diseñada para ser usada en programas que trabajen con múltiples procesadores.

Su principal característica es que no precisa de memoria compartida por lo que es muy habitual su uso en la programación de sistemas distribuidos.

Los elementos principales que intervienen en el paso de mensajes son:

El proceso que envía.

El proceso que recibe.

El mensaje.

Dependiendo de si el proceso que envía el mensaje espera a que el mensaje sea recibido, se puede hablar de paso de mensajes síncrono o asíncrono.

En el paso de mensajes asíncrono, el proceso que envía, no espera a que el mensaje sea recibido, y continúa su ejecución, siendo posible que vuelva a generar un nuevo mensaje y a enviarlo antes de que se haya recibido el anterior. Esta es la razón por la que se utilizan buzones, en los que se almacenan los mensajes a espera de que un proceso los reciba. Generalmente empleando este sistema, el proceso que envía mensajes sólo se bloquea o para, cuando finaliza su ejecución, o si el buzón está lleno.

En el paso de mensajes síncrono, el proceso que envía el mensaje espera a que un proceso lo reciba para continuar su ejecución. Este método es conocido como técnica encuentro. Dentro del paso de mensajes síncrono se engloba a la llamada a procedimiento remoto, muy habitual en las arquitecturas cliente/servidor.


46

2.2. Clases de objetos

Atributos, variables de estado y variables de clase.

Un objeto es una instancia de una clase, por lo que se pueden intercambiar los términos objeto o instancia.

Una clase se compone de dos partes:

Atributos (denominados, por lo general, datos miembros. Son los datos que hacen referencia al estado del objeto.

Métodos (denominados, por lo general, funciones miembros). Son funciones que pueden aplicarse a objetos

Por ejemplo, si tenemos una clase llamada auto, los objetos SEAT y AUDI serán instancias de esa clase. También puede haber otros objetos SEAT León, diferenciados por su número de modelo. Asimismo, dos instancias de una clase pueden tener los mismos atributos, pero considerarse objetos distintos independientes.

Los atributos que asociamos a una clase, dependen en gran medida del uso que le daremos dentro del sistema que diseñamos actualmente, pero también pueden ser definidos pensando en futuras implementaciones. También son conocidos como variables de estado (o variables de instancia) puesto que su valor define el estado del objeto.

Métodos. Requisitos e invariantes.

En la programación orientada a objetos, un método es una subrutina asociada exclusivamente a una clase (llamados métodos de clase o métodos estáticos) o a un objeto (llamados métodos de instancia).

Un método consiste en una serie de sentencias para llevar a cabo una acción, un juego de parámetros de entrada que regularán dicha acción y un valor de salida (o valor de retorno) de algún tipo. Este último elemento es opcional.

En lenguajes compilados, los métodos pueden ser objetos de primera clase, y en este caso se puede compilar un método sin asociarse a ninguna clase en particular, y luego asociar el vínculo o contrato entre el objeto y el método en tiempo de ejecución.

En cambio en lenguajes no compilados dinámicamente (conocidos también como tipados estáticamente) se acude a precondiciones para regular los parámetros del método y postcondiciones para regular su salida (en caso de tenerla). Si alguna de las precondiciones o postcondiciones es falsa el método genera una excepción. Si el estado del objeto no satisface la invariante de su clase al comenzar o finalizar un método, se considera que el programa tiene un error de programación.

La diferencia entre un procedimiento (generalmente llamado función si devuelve un valor) y un método es que éste último, al estar asociado con un objeto o clase en particular, puede acceder y modificar los datos privados del objeto correspondiente de forma tal que sea consistente con el comportamiento deseado para el mismo.

Hay que entender la idea de método no como una secuencia de instrucciones sino como la forma en que el objeto hace su trabajo. Y partiendo de esta premisa considerar al método como el pedido a un objeto para que realice una tarea determinada o como la vía para enviar un mensaje al objeto y que éste reaccione acorde a dicho mensaje.


47

Gestión de excepciones.

Estas condiciones de error pueden ser errores en la lógica del programa como un índice de un array fuera de su rango o una división por cero o errores disparados por los propios objetos que denuncian algún tipo de estado no previsto.

La idea general es que cuando un objeto encuentra una condición que no sabe manejar crea y dispara una excepción que deberá ser capturada por el que le llamó. Las excepciones son objetos que contienen información del error que se ha producido. Si nadie captura la excepción interviene un manejador por defecto que normalmente imprime información que ayuda a encontrar quién produjo la excepción.

Existen dos categorías de excepciones:

1. Excepciones verificadas. El compilador obliga a verificarlas. Son todas las que son lanzadas explícitamente por objetos de usuario.

2. Excepciones no verificadas. El compilador no obliga a su verificación. Son excepciones como divisiones por cero, excepciones de puntero nulo, o índices fuera de rango.

Una excepción es una condición anormal que surge en una secuencia de código durante la ejecución de un programa. O sea, es un error en tiempo de ejecución.

La gestión de excepciones usa las palabras reservadas try, catch, throw, throws y finally.

try {

// bloque de código

}

catch (TipoExcepcion1 obEx){

// gestor de excepciones para TipoExcepcion1

}

catch (TipoExcepcion2 obEx){

// gestor de excepciones para TipoExcepcion2

}

// ...

finally {

// bloque de código que se ejecutara antes de

// que termine el bloque try

}


48

Agregación de clases.

Los componentes pueden ser compartidos por varios compuestos (de la misma asociación de agregación o de varias asociaciones de agregación distintas). La destrucción del compuesto no conlleva la destrucción de los componentes. Habitualmente se da con mayor frecuencia que la composición.

La agregación se representa en UML mediante un diamante de color blanco colocado en el extremo en el que está la clase que representa el "todo”.

Veamos el siguiente ejemplo, donde tenemos una clase empresa, una clase cliente una empresa agrupa a varios clientes.

2.3. Objetos

Los objetos interactúan unos con otros, en contraposición a la visión tradicional en la cual un programa es una colección de subrutinas (procedimientos), o más sencillamente, una lista de instrucciones para el computador. Cada objeto es capaz de recibir mensajes, procesar datos y enviar mensajes a otros objetos de manera similar a un servicio.

En la programación orientada a objeto, un objeto es el resultado de la instanciación de una clase que queda implementada sólo al crear una instancia de la clase, en la forma de un objeto.

Por ejemplo: dado un plano para construir mesas (una clase de nombre clase_mesa), entonces una mesa concreta, en la que podemos colocar cosas encima, construida a partir de este plano, sería un objeto de clase_mesa. Es posible crear (construir) múltiples objetos (mesas) utilizando la definición de la clase (plano) anterior.

Los conceptos de clase y objetos son análogos a los de tipo de datos y variable; es decir, definida una clase podemos crear objetos de esa clase, igual que disponiendo de un determinado tipo de dato (por ejemplo el tipo entero), podemos definir variables de dicho tipo:

int a,b;

Creación y destrucción de objetos.

Técnicamente, el dominio de la programación orientada a objetos está formado por los tipos abstractos de datos, la herencia y el polimorfismo, pero las formas de crear objetos es también muy importante.

Es especialmente importante la forma en que se crean y se destruyen los objetos. Dependiendo de los lenguajes de programación se trabaja bajo distintas filosofías al respecto.


49

C++ adopta un enfoque en el que el control de eficiencia es la cuestión más importante, pero eso delega la elección al programador. Para una velocidad máxima de ejecución, el almacenamiento y la vida se determinan mientras el programa se escribe, colocando los objetos en la pila o en almacenamiento estático. La pila es un área de memoria usada directamente por el microprocesador para almacenar datos durante la ejecución del programa. A veces las variables de la pila se llaman variables automáticas o de ámbito.

Se sacrifica flexibilidad porque se debe conocer la cantidad exacta, vida, y tipo de objetos mientras el programador escribe el programa. Si está intentando resolver un problema más general, como un diseño asistido por computadora, gestión de almacén, o control de tráfico aéreo, eso también es restrictivo.

Otro enfoque es crear objetos dinámicamente en un espacio de memoria llamado montículo. En este enfoque no se sabe hasta el momento de la ejecución cuántos objetos se necesitan, cuál será su ciclo de vida, o su tipo exacto. Estas decisiones se toman de improviso mientras el programa está en ejecución. Si necesita un nuevo objeto, simplemente se crea usando la palabra reservada new. Cuando ya no se necesite ese espacio de almacenamiento puede liberarse usando la palabra reservada delete.

Por ejemplo,

Taxi taxi1 = new Taxi(); //Creación de un objeto tipo Taxi

Persona persona1 = new Persona(); //Creación de un objeto tipo Persona

TaxiCond taxiCond1 = new TaxiCond (taxi1, persona1);

/*Creación de un objeto tipo TaxiCond pasando como parámetros otros objetos creados previamente*/

El enfoque dinámico asume que los objetos tienden a ser complicados, por eso la sobrecarga extra de encontrar espacio para alojarlos y después liberarlos, no tiene un impacto importante en la creación de un objeto. Además, el aumento de flexibilidad es esencial para resolver problemas generales de programación.

Sintaxis del operador delete,

[::]delete [<expresión>]

[::]delete[] [<expresión>]

Otra cuestión importante es el tiempo de vida de un objeto. En C++, el programador debe determinar programáticamente cuándo destruir el objeto, y entonces llevar a cabo la destrucción usando la palabra reservada delete. Como alternativa, el entorno puede proporcionar una característica llamada recolector de basura (garbage collector) que automáticamente descubre qué objetos ya no se usan y los destruye. Escribir programas usando un recolector de basura genera códigos más eficientes pero requiere que todas las aplicaciones sean capaces de tolerar la existencia del recolector de basura y la sobrecarga que supone.

Ejemplo de uso,

int main() {

char *c;

int *i = NULL;


50

float **f;

int n;

// Cadena de 122 más el nulo:

c = new char[123];

// Array de 10 punteros a float:

f = new float *[10]; (1)

// Cada elemento del array es un array de 10 float

for(n = 0; n < 10; n++) f[n] = new float[10]; (2)

// f es un array de 10*10

f[0][0] = 10.32;

f[9][9] = 21.39;

c[0] = 'a';

c[1] = 0;

Otro ejemplo,

using namespace std;

int main() {

int *x;

x = new int(67);

cout << *x << endl;

delete x;

}

En este caso, reservamos memoria para un entero, se asigna la dirección de la memoria obtenida al puntero x, y además, se asigna el valor 67 al contenido de esa memoria.

Llamada a métodos de un objeto.

Tan solo hemos de añadir al nombre del objeto referenciado el nombre del método (separados por un punto) y proporcionar los argumentos al método (entre paréntesis). Si el método no necesitase argumentos, utilizaremos los paréntesis vacíos.

La sintaxis tendría que seguir esta forma:

// Código 1

objetoReferenciado.nombreMetodo(listaArgumentos);


51

Por ejemplo,

// Código 2

rectangulo.move(15, 37);

Esta sentencia realiza una llamada al método move() del objeto rectángulo con dos parámetros: los valores enteros 15 y 37, y tiene el efecto de mover el objeto rectángulo al igual que hicimos en las sentencias anteriores mediante la modificación directa de las variables x e y del objeto rectángulo.

Si quisiéramos mover un rectángulo diferente, por ejemplo, el que antes llamamos rectangulo2, a una nueva posición lo podríamos hacer así:

// Código 3

rectangulo2.move(244, 47);

Podemos observar que las llamadas a métodos se hacen directamente a objetos específicos. El objeto especificado en la llamada al método es el que responde a la instrucción.

Las llamadas a los métodos son también conocidas como mensajes y, como en la vida real, los mensajes siempre deben ser dirigidos a un receptor concreto. Es más, el mismo mensaje puede devolver distintos resultados dependiendo del receptor.

En el ejemplo anterior se podía ver que el mensaje move() produce resultados distintos según se envía al objeto rectángulo o al objeto rectangulo2.

Una llamada a un método es una expresión cuyo valor es el valor de retorno (si tiene alguno). Algunas veces, asignaremos el valor devuelto por un método a una variable. Otras veces, podremos usar la llamada al método dentro de otra expresión o sentencia.

El método move() que hemos usado no devuelve ningún valor. No obstante, el método inside() de la clase Rectangle sí tiene valor de retorno. Este método como parámetros las coordenadas x e y de un punto, y devuelve un valor booleano que indica si dicho punto está dentro del rectángulo.

Por ejemplo, podemos usar el método inside() para saber si el puntero del ratón se encuentra dentro del rectángulo y hacer algo en función de ello. Lo podemos ver en el ejemplo siguiente:

// Código 4

if (rectangulo.inside(raton.x, raton.y)) {

// El ratón está dentro del rectángulo metodo1()

} else {

// El ratón está fuera del rectángulo metodo2()

}

El objeto al que hacemos referencia en la llamada a uno de sus métodos debe ser una referencia a objeto. Dado que se puede utilizar un nombre de variable en su lugar, también puede utilizarse cualquier expresión que devuelva una referencia a un objeto. Hemos dicho que el operador new devuelve una referencia a un objeto, por lo que podemos utilizar el valor devuelto por new para acceder a las variables del objeto recién creado.


52

Veamos un ejemplo,

// Código 5

new Rectangle(0, 0, 100, 50).equals(rectangulo2)

La expresión new Rectangle(0, 0, 100, 50) nos devuelve una referencia a un objeto de tipo Rectangle. Por lo tanto, podemos usar la notación de punto para llamar al método equals() del nuevo objeto y saber si el rectángulo nuevo es igual al que se ha especificado como argumento de equals().

Visibilidad y uso de las variables de estado.

Según el tipo de variable y su visibilidad, podemos tener variables locales y globales.

Variables locales.

Este tipo de variables son solo accesibles desde dentro de un bloque de instrucciones. Por tanto la definición de una variable ha de realizarse dentro del nivel al que pertenece.

Por ejemplo,

int max (int a, int b)

{

if (a>b)

{

int aux = a;

}

else

{

int aux = b;

}

return aux;

}

En el bloque anterior el compilador de Java produciría un error debido a que en la sentencia "return" se está intentando pasar una variable llamada "aux" que no está definida dentro de los corchetes pertenecientes a la función, si no dentro de los pertenecientes al "if-else" y por tanto se trata de una variable de ámbito local delimitada por los corchetes. Para solucionarlo tendríamos que hacer lo siguiente:


{

int aux; // Definir la variable en el ámbito de los corchetes correspondientes a la función.


53

if (a>b)

{

aux = a;

}

else

{

aux = b;

}

return aux;

}

Referencias a objetos.

Según el tipo de variable y su visibilidad, podemos tener variables locales y globales.

Variables locales.

Este tipo de variables son solo accesibles desde dentro de un bloque de instrucciones. Por tanto la definición de una variable ha de realizarse dentro del nivel al que pertenece.

Por ejemplo,


{

if (a>b)

{

int aux = a;

}

else

{

int aux = b;

}

return aux;

}


54

En el bloque anterior el compilador de Java produciría un error debido a que en la sentencia "return" se está intentando pasar una variable llamada "aux" que no está definida dentro de los corchetes pertenecientes a la función, si no dentro de los pertenecientes al "if-else" y por tanto se trata de una variable de ámbito local delimitada por los corchetes. Para solucionarlo tendríamos que hacer lo siguiente:


{

int aux; // Definir la variable en el ámbito de los corchetes correspondientes a la función.

if (a>b)

{

aux = a;

}

else

{

aux = b;

}

return aux;

}

En Java no se puede declarar instancias de clases usando el nombre de la clase y un nombre para el objeto (como se hace en C++).

Variables globales.

Las variables globales son aquellas que son accesibles desde cualquier punto de la ejecución del programa, incluso desde dentro de funciones diferentes.

Persistencia de objetos.

En el caso de persistencia de objetos la información que persiste en la mayoría de los casos son los valores que contienen los atributos en ese momento, no necesariamente la funcionalidad que proveen sus métodos.

La persistencia no es ni una capacidad ni una propiedad de la POO, no tiene nada que ver con el paradigma en sí, solo es el mecanismo que se usa para persistir información de un determinado tipo (como puede ser serializar, guardar los datos en una tabla, en un archivo plano, etc.)

Desde la óptica de la persistencia, se podrían clasificar los objetos en:

Transitorio, cuyo tiempo de vida depende directamente del ámbito del proceso que los instanció.

Persistentes, cuyo estado es almacenado en un medio secundario para su posterior reconstrucción y utilización, por lo que su tiempo de vida es independiente del proceso que los generó.


55

La persistencia permite al programador almacenar, transferir y recuperar el estado de los objetos. Para esto existen varias técnicas:

Serialización.

Motores de persistencia.

Bases de datos orientadas a objetos.

Optimización de memoria y recolección de basura (garbage collection).

Un recolector de basura (del inglés garbage collector) es un mecanismo implícito de gestión de memoria implementado en algunos lenguajes de programación de tipo interpretado o seminterpretado.

Cualquier programa informático hace uso de una cierta cantidad de memoria de trabajo puesta a su disposición por el sistema operativo. Esta memoria tiene que ser gestionada por el propio programa para:

Reserva de espacios de memoria.

Liberación espacios de memoria previamente reservados.

Compactar espacios de memoria libres y consecutivos entre sí.

Contabilización de los espacios libres.

Generalmente, el programador dispone de una librería de códigos para realizar estas tareas aunque el propio desarrollador es responsable de utilizar adecuadamente esta biblioteca.

Estas librerías hacen un uso eficiente de la memoria, es decir, los espacios de memoria quedan libres cuando ya no son necesarios. No obstante, este mecanismo explícito de gestión de memoria es propenso a errores.

Por ejemplo, un programador puede olvidar liberar la memoria de manera que, tarde o temprano, no quede memoria disponible, abortando la ejecución del programa.

Como alternativa es necesaria una gestión implícita de memoria, con lo que el programador no es consciente de la reserva y liberación de memoria. Esto es obligado en algunos lenguajes de programación en los que no se maneja el concepto de memoria. Por ejemplo, en lenguajes declarativos como Lisp o Prolog .

Por ejemplo Visual Prolog,


56

Cuando un lenguaje dispone de recolección de basura, el programador no tiene que invocar a una subrutina para liberar memoria. La reserva de memoria también es más o menos automática sin la intervención del programador.

Por ejemplo, en los lenguajes orientados a objetos se reserva memoria cada vez que el programador crea un objeto pero éste no tiene que saber cuánta memoria se reserva ni cómo se hace esto.

Y en los lenguajes declarativos cada vez que se construye una expresión se reserva memoria (de una manera inteligente), pero el programador no es consciente de ello.

Cuando se compila el programa, automáticamente se incluye en éste una subrutina correspondiente al recolector de basura. Esta rutina también es invocada periódicamente sin la intervención del programador.

Cuando se llama el recolector de basura, este recorre la lista de espacios reservados observando el contador de referencias de cada espacio. Si un contador ha llegado a cero significa que ese espacio de memoria ya no se usa y, por tanto, puede ser liberado.

El único inconveniente de este mecanismo es averiguar previamente cuándo es conveniente ejecutar el recolector de basura. Existen varios algoritmos para hacerlo pero el más eficiente es el primero de ellos:

Esperar a que no quede memoria libre, y entonces, ejecutar el recolector de basura.

Fijar un umbral de ocupación de la memoria libre y ejecutar el recolector de basura cuando se supere dicho umbral.

Ejecutar el recolector de basura a intervalos regulares (no siempre es posible).

Ejecutar el recolector de basura justo antes de cada reserva de memoria.

Permitir al programador que invoque explícitamente al recolector de basura cuando quiera.

El recolector de basura localiza todas las reservas de memoria que se producen en el programa y de esta forma llevar una cuenta de todas las referencias que existen a un determinado espacio de memoria reservado.


57

2.4. Herencias

Concepto de herencia. Superclases y subclases.

En orientación a objetos la herencia es, después de la agregación o composición, el mecanismo más utilizado para alcanzar algunos de los objetivos más preciados en el desarrollo de software como lo son la reutilización y la extensibilidad.

A través del mecanismo de herencia los diseñadores pueden crear nuevas clases partiendo de una clase o de una jerarquía de clases preexistente (ya comprobadas y verificadas) evitando con ello el rediseño, la modificación y verificación de la parte ya implementada.

Por ejemplo, si declaramos una clase párrafo derivada de una clase texto, todos los métodos y variables asociadas con la clase texto, son automáticamente heredados por la subclase párrafo.

La herencia es uno de los mecanismos de los lenguajes de programación orientada a objetos basados en clases por medio del cual una clase se deriva de otra de manera que extiende su funcionalidad. La clase de la que se hereda se suele denominar clase base, clase padre, superclase, clase ancestro (la nomenclatura exacta dependerá mucho del lenguaje de programación utilizado).

La herencia es un mecanismo que permite la definición de una clase a partir de la definición de otra ya existente. La herencia permite compartir automáticamente métodos y datos entre clases, subclases y objetos.

La herencia está fuertemente ligada a la reutilización del código en la programación orientada a objetos, es decir, el código de cualquiera de las clases puede ser utilizado simplemente creando una clase derivada de ella, o bien una subclase.

Encontramos dos tipos de herencia:

Herencia simple, en la que se pueden definir nuevas clases solamente a partir de una clase inicial.

Herencia múltiple, donde se pueden definir nuevas clases a partir de dos o más clases iniciales. Java sólo permite herencia simple.

El concepto de herencia conduce a una estructura jerárquica de clases o estructura de árbol lo que significa que en la programación orientada a objetos todas las relaciones entre clases deben ajustarse a dicha estructura.


58

En esta estructura jerárquica, cada clase tiene sólo una clase padre. La clase padre de cualquier clase es conocida como su superclase. La clase hija de una superclase es llamada una subclase.

Una superclase puede tener cualquier número de subclases.

Una subclase puede tener sólo una superclase.

Herencia múltiple.

Lenguajes que soportan herencia múltiple en mayor o menor medida son: C++, Centura SQL Windows, CLOS, Eiffel, Object REXX, Perl y Python.

La herencia múltiple permite a una clase tomar funcionalidades de otras clases.

Por ejemplo, permitir a una clase llamada MusicoEstudiante heredar de una clase llamada Persona, una clase llamada Músico, y una clase llamada Trabajador.

Podríamos expresarlo de forma abreviada como:

MusicoEstudiante : Persona, Músico, Trabajador.

Clases abstractas.

Hay ocasiones, cuando se desarrolla una jerarquía de clases en que algún comportamiento está presente en todas ellas pero se materializa de forma distinta para cada una.

Por ejemplo, pensemos en una estructura de clases para manipular figuras geométricas. Podríamos pensar en tener una clase genérica, que podría llamarse FiguraGeometrica y una serie de clases que extienden a la anterior que podrían ser Circulo, Polígono, etc.

Podría haber un método dibujar dado que sobre todas las figuras puede llevarse a cabo esta acción, pero las operaciones concretas para llevarla a cabo dependen del tipo de figura en concreto (de su clase).

Por otra parte la acción dibujar no tiene sentido para la clase genérica FiguraGeometrica, porque esta clase representa una abstracción del conjunto de figuras posibles.

Para resolver esta problemática Java proporciona las clases y métodos abstractos.


59

Tipos de herencia.

Herencia simple.

Cuando un objeto extiende las características de otro objeto y de ningún otro, es decir, que sólo puede heredar o tomar atributos de un solo padre o de una sola clase.

Herencia múltiple.

Un objeto puede extender las características de uno o más objetos, es decir, puede tener varios padres.

Algunos desarrolladores no admiten la herencia múltiple por las posibles coincidencias en nombres de métodos o datos miembros.

Por ejemplo C++, Python, PHP permiten herencia múltiple, mientras que Java, Ada y C# sólo permiten herencia simple.

Otros conceptos muy utilizados en la programación son:

Especificación.

Se trata de un caso especial de sub-clasificación por especialización, excepto que las sub-clases no son refinamientos de un tipo existente, sino más bien realizaciones de una especificación incompleta. Es decir, que la superclase describe un comportamiento que será implantado solo por las sub-clases.

Construcción.

Se da cuando la sub-clase ha heredado casi completamente su comportamiento de la superclase y solo tiene que modificar algunos métodos o los argumentos de cierta manera.

Generalización.

Se debe evitar; solo deben aplicarse cuando no se pueden modificar las clases existentes o se deben anular métodos de las mismas.

Extensión.

Agrega una capacidad totalmente nueva a un objeto existente. Se distingue de la generalización, ya que esta debe anular al menos un método de la clase base, mientras que la extensión solo agrega métodos nuevos.

Limitación.

Es una variante de la especificación en donde el comportamiento de la sub-clase es más reducido o está más restringido que el comportamiento de la superclase. También se da en situaciones en las que las clases existentes no pueden modificarse.

Variación.

Se da cuando dos o más clases tienen implantaciones similares, pero no parece haber ninguna relación jerárquica entre los conceptos representados por las clases.

Combinación.

Se da cuando una sub-clase resulta de la combinación de características de dos o más clases.


60

Características y funciones de cada uno de los miembros que participan:

Solo se pueden heredar clases, no funciones ordinarias ni variables.

Una sub-clase deriva de una clase base. La clase derivada puede a su vez ser utilizada como clase base para derivar más clases, conformándose así la jerarquía de clases.

Podemos destacar de la clase derivada o sub-clase las siguientes características:

Puede a su vez ser una clase base, dando lugar a la jerarquía de clase.

Los miembros heredados por una clase derivada, pueden a su vez ser heredados por más clases derivadas a ella.

Hereda todos los miembros de la clase base, pero solo podrá acceder a aquellos que los especificadores de acceso de la clase base lo permitan..

No tienen acceso a los miembros private de la clase base.

Pueden añadir sus propios datos y funciones miembros.

Hay que tener en cuenta que algunos elementos de la clase base no se heredan como son los constructores y destructores, las funciones y datos estáticos de la clase, las funciones amigas y los operadores sobrecargados (solo en C++).

Polimorfismo y enlace dinámico (dynamic binding).

El polimorfismo se puede establecer mediante sobrecarga, sobre-escritura y enlace dinámico.

EL término sobrecarga se refiere al uso del mismo identificador u operador en distintos contextos y con distintos significados.

Si para cada funcionalidad necesitada fuese necesario escribir un método, el código resultante sería inmanejable.

Por ejemplo, supongamos que los desarrolladores de Java hubiesen creado un método para escribir en pantalla una cadena de texto, otro diferente para escribir un entero, otro para un doble, y así para todas las combinaciones posibles, sería casi imposible conocer dichos métodos en totalidad. En cambio, con “System.out.print()” o “System.out.println()” podemos escribir cualquier mensaje en pantalla.

Esta operación es posible gracias a la sobrecarga, la cual se aplica a métodos y constructores.

La sobrecarga de métodos hace que un mismo nombre pueda representar distintos métodos con distinto tipo y número de parámetros, manejados dentro de la misma clase. En el ámbito de la programación orientada a objetos, la sobrecarga de métodos se refiere a la posibilidad de tener dos o más métodos con el mismo nombre pero distinta funcionalidad, es decir, dos o más métodos con el mismo nombre realizan acciones diferentes y el compilador usará una u otra dependiendo de los parámetros usados. Esto también se puede aplicar a los constructores.

Podemos diferenciar varios métodos sobrecargados a través de sus parámetros, ya sea por la cantidad, el tipo o el orden de los mismos.

Por ejemplo, un uso concreto de métodos sobrecargados,


61

Por ejemplo, un uso concreto de sobreescritura,

En la relación de herencia del ejemplo de las figuras aunque la clase base “Figura” tiene los métodos “calcularArea” y “calcularPerimetro”, las subclases “Circulo”, “Cuadrado”, “Triangulo” y “Rectangulo” redefinen estos métodos ya que el cálculo del área y el perímetro de cada uno de ellos es diferente.

Java permite que la definición de los tipos de objetos se pueda producir por enlazado posterior (late binding) donde el compilador tomará la decisión sobre qué objeto ejecutará qué método de acuerdo a la forma de crear la instancia. Estamos ante enlaces dinámicos.


62

Por ejemplo, si requiero un entero lo declaro como entero pero ¿para qué declarar un elemento como un tipo y luego usarlo como otro?. La razón es que no siempre se puede determinar exactamente el tipo de elemento que va a usarse en la ejecución de nuestro programa.

Directrices para el uso correcto de la herencia.

Se debe tener por lo menos una relación de herencia que permita determinar un tipo base para la declaración, sea cual sea el subtipo que se instancie.

Por ejemplo,

En este caso, el método muevete llama al método mover de un mamífero y aunque no sabe con qué clase de mamífero trata, funciona y se llama al método correspondiente al objeto específico que lo llama (es decir, primero un gato y luego un perro). Si no existiera el enlace dinámico, tendríamos que crear un método muevete para los mamíferos de tipo Gato y otro para los de tipo Perro.

En este otro ejemplo tenemos instancias que se crean de forma aleatoria,


63

En esta ocasión, el método generarInstrumento crea aleatoriamente las instancias de los diferentes tipos de instrumentos.


64

Además el arreglo de elementos del tipo de instrumentos es llenado con diferentes elementos de los cuales sólo sabemos que son objetos basados en Instrumento. Aunque los métodos tocarInstrumento y afinarInstrumento reciben como parámetro un Instrumento llaman adecuadamente a los métodos afinar o tocar según la instancia que reciben.

2.5. Modularidad

Librerías de clases. Ámbito de utilización de nombres.

El espacio de nombre es el ámbito en el que un identificador debe ser único.

En el caso del lenguaje C tenemos cuatro clases distintas de identificadores:

Nombres de etiquetas goto. Deben ser únicas dentro de la función en que se han declarado (goto tiene ámbito de función).

Nombres estructuras, uniones y enumeraciones. Deben ser únicas dentro del bloque en que se han definido. Las etiquetas definidas fuera de cualquier función deben ser únicas (ya que son globales al fichero).


65

Nombres de miembros de estructuras y uniones. Deben ser únicos dentro de la estructura o unión en que se han definido. No existe restricción en el tipo de miembros del mismo nombre en diferentes estructuras.

Variables, funciones, typedef y enumeradores. Deben ser únicos dentro del ámbito en que han sido definidos. Los identificadores declarados externos deben ser únicos entre las variables declaradas externas. C++ tiene una palabra clave: namespace, que es en realidad un recurso para manejar los identificadores. Permite dividir el espacio total de nombres en regiones distintas e independientes respecto a los identificadores.

Ventajas de la utilización de módulos o paquetes.

La programación modular es un paradigma de programación que consiste en dividir un programa en módulos o subprogramas con el fin de hacerlo más legible y manejable.

Se presenta históricamente como una evolución de la programación estructurada para solucionar problemas de programación más grandes y complejos de lo que ésta puede resolver.

Un módulo es cada una de las partes de un programa que resuelve uno de los subproblemas en que se divide el problema complejo original. Cada uno de estos módulos tiene una tarea bien definida y algunos necesitan de otros para poder operar. Cuando un módulo necesita usar otro puede comunicarse con éste mediante una interfaz de comunicación que también debe estar bien definida.

Si bien un módulo puede entenderse como una parte de un programa en cualquiera de sus formas y variados contextos, en la práctica se los suele tomar como sinónimos de procedimientos y funciones.

No es necesario identificar directamente un módulo con una función o un procedimiento, ya que el mismo puede contener muchos de ellos.

No debe confundirse el término "modulo" (en el sentido de programación modular) con términos como "función" o "procedimiento", propios del lenguaje que lo soporte.

Ventajas:

Simplifica el diseño.

Disminuye la complejidad de los algoritmos.

Disminuye el tamaño total del programa.

Ahorra en tiempo de programación porque promueve la reusabilidad del código.

Favorece el trabajo en equipo.

Facilita la depuración y prueba.

Facilita el mantenimiento.

Permite la estructuración de librerías específicas.

2.6. Generalidad y sobrecarga

Concepto de genericidad.

Se trata de la facilidad de un lenguaje de programación para definir clases parametrizadas con los tipos de datos.


66

Ejemplos de uso de la genericidad,

Operaciones aplicables a cualquier dato, independientemente de su tipo (swap).

Contenedores cuyas operaciones no dependen del tipo de datos almacenado (colas, pilas, listas)

Acceso uniforme a contenedores secuenciales (arrays, ficheros, etc.)

Algoritmos y contenedores aplicables a tipos de datos para los que esté definida una determinada operación (ordenación).

Concepto de sobrecarga. Tipos de sobrecarga.

En programación orientada a objetos la sobrecarga se refiere a la posibilidad de tener dos o más funciones con el mismo nombre pero funcionalidad diferente. Es decir, dos o más funciones con el mismo nombre realizan acciones diferentes. El compilador usará una u otra dependiendo de los parámetros usados. A esto se llama también sobrecarga de funciones.

También existe la sobrecarga de operadores que al igual que con la sobrecarga de funciones se le da más de una implementación a un operador.

El mismo método dentro de una clase permite hacer cosas distintas en función de los parámetros.

Java no permite al programador implementar sus propios operadores sobrecargados, pero sí utilizar los predefinidos como el +. C++, por el contrario si permite hacerlo.

Sobrecarga de operadores.

Tienen determinados algoritmos en la práctica (no en todos los algoritmos es sencillo calcular analíticamente su coste concreto en operaciones por lo que se deben usar análisis empíricos).

Sobrecarga de métodos.

Algunos métodos en una clase pueden tener el mismo nombre. Estos métodos deben contar con diferentes argumentos. El compilador decide qué método invocar comparando los argumentos. Se generara un error si los métodos sólo varían en el tipo de retorno.

Por ejemplo,

public class Articulo {

private float precio;

public void setPrecio() {

precio = 3.50;

}

public void setPrecio(float nuevoPrecio) {

precio = nuevoPrecio;

}

}


67

Por ejemplo, trabajaremos un método que soporta varios tipos de parámetros, entonces cuando hacemos uso de este, lo que hace el compilador es buscar el que posee ese tipo de parámetros.

Color (int r, int g, int b)

Color (float a, float b, float c)

//--------------------------------------------

//r,g,b (son valores enteros entre 0 y 255)

//a,b,c (son valores flotantes entre 0.0 y 1.0)

Entonces cuando hacemos un llamado a este método (en este caso sería un constructor), el compilador hace referencia al tipo de parámetros. La sobrecarga seria redefinir cualquiera de estos métodos utilizando los mismos parámetros pero para un proceso distinto.

Comparación entre genericidad y sobrecarga.

Cuando exista la duda entre usar genericidad o sobrecarga, la clave es la siguiente:

Si para todos los tipos de datos se requiere una acción común, hay que usar genericidad. En caso contrario, se recomienda el uso de sobrecarga.

En caso de usar sobrecarga existe el riesgo de usar demasiados métodos que realizan lo mismo pero con diferentes tipos de datos. Si en un momento dado hay que modificar el método habría que retocar todas las implicaciones.

2.7. Desarrollo orientado a objetos

Lenguajes de desarrollo orientado a objetos de uso común.

La llamada interfaz del objeto es la forma de interactuar con el objeto.

Un programa orientado a objetos se caracteriza por la interacción de esos objetos. El diseño orientado a objetos es la disciplina que define los objetos y sus interacciones para resolver un problema de negocio que fue identificado y documentado durante el análisis orientado a objetos.

Hay que reseñar que los conceptos definidos en la programación orientada a objetos no son una condición sino que son para definir que un lenguaje es orientado a objetos. Existen conceptos que pueden estar ausentes en un lenguaje dado y sin embargo, no invalidar su definición como lenguaje orientado a objetos.

El lenguaje aporta un formalismo que modeliza mejor las propiedades de un sistema orientado a objetos, los tipos de datos abstractos.

Cualquier lenguaje que permita la definición de tipos de datos, de operaciones nuevas sobre esos tipos de datos, y de instanciar el tipo de datos podría ser considerado orientado a objetos.


68

Por ejemplo, la programación de interfaces gráficas de usuario para los sistemas X-Window usa infraestructuras de funciones y APIs como Motif, Xview y Xlib que son realizadas usualmente en lenguaje C pero organizando el código en una manera que "parecen objetos" (los Widgets).

Algunos de los lenguajes más comunes son:

C++.

Objective C.

Java.

Smalltalk.

eC (Ecere C).

Eiffel.

Léxico (en castellano).

Ruby.

Python.

OCAML.

CLIPS.

Visual .net.

COBOL.

Perl.

C#.

Visual Basic.NET.

PHP.

Simula.

Delphi

PowerBuilder.

Maya.

Herramientas de desarrollo.

Las IDE (entornos de desarrollo integrado) son un tipo de programa informático que está conformado por un conjunto de herramientas de programación.

Con cada una de esos entornos podemos trabajar exclusivamente con un solo tipo de lenguaje de programación o utilizar para varios tipos de lenguajes.

En algunos lenguajes de programación el IDE tiene la capacidad de funcionar como un sistema en tiempo de ejecución el que permite utilizar el lenguaje de programación en forma interactiva.

Un lenguaje de programación que nos permite trabajar en un entorno de desarrollo integrado es el Eclipse. Cuenta con las siguientes funciones:

Editor de texto en el cual resalta la sintaxis, donde se puede observar el contenido del fichero en el que se está realizando el trabajo, dispone de una lista de tareas y otros módulos similares y su compilación es en tiempo real, entre muchas otras.


69

Las ventajas que se pueden encontrar en este son:

o Emplea módulos que nos proporcionan toda su funcionalidad a diferencia de otros tipos de IDE’s.

o La arquitectura de los módulos nos permite escribir cualquier extensión que deseemos en el ambiente.

Zend Studio. Es un editor de texto para páginas PHP que nos proporciona excelente ayuda desde la creación y gestión de proyectos hasta la depuración del código. A diferencia de sus versiones más anteriores que ya no se trata de un IDE desarrollado en Java.

Visual C#. Este es un grupo de herramientas de desarrollo diseñadas a través de una interfaz de usuario común. Algunas de sus herramientas se pueden compartir con otros lenguajes de programación como Visual Studio y otras, como es el caso del compilador de C#, son de Visual C#.


70

2.8. Lenguajes de modelización en el desarrollo orientado a objetos

Uso del lenguaje unificado de modelado (UML) en el desarrollo orientado a objetos.

Algunas organizaciones los usan extensivamente en combinación con una metodología de desarrollo de software para avanzar de una especificación inicial a un plan de implementación y para comunicar dicho plan a todo un equipo de desarrolladores. El uso de un lenguaje de modelado es más sencillo que la auténtica programación pues existen menos medios para verificar efectivamente el funcionamiento adecuado del modelo.

Algunos metodólogos del software orientado a objetos distinguen tres grandes generaciones cronológicas de técnicas de modelado de objetos:

1. Primera generación. Tecnólogos aislados y grupos pequeños desarrollaban técnicas que resolvían problemas que se encontraban de primera mano en los proyectos de desarrollo orientado a objetos.

2. Segunda generación. La comunidad del software orientado a objetos empezaba a reconocer los beneficios que la estandarización de las técnicas conllevaría.

3. Tercera generación. Creación de un lenguaje unificado para la industria, cuyo mejor ejemplo es UML

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento UML mejorado.

La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripción se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas.


71

La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de uso coherente y consistente promueven una imagen fácil de comprender del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.

Por ejemplo, el diagrama que describe la funcionalidad de un supuesto Restaurante podría ser,

Es posible crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del ámbito de las descripciones de los casos de uso.

Ejemplos de esos temas incluyen restricciones de diseño como: rendimiento, temas de escalabilidad/gestión, o cumplimiento de estándares.

La interacción entre actores no se ve en el diagrama de casos de uso. Si esta interacción es esencial para una descripción coherente del comportamiento deseado, quizás los límites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la interacción entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie de rol, un usuario humano u otra entidad externa pueden jugar varios papeles o roles.

Por ejemplo, en el esquema anterior, el chef y el cajero podrían ser realmente la misma persona.

Diagramas para la modelización de sistemas orientados a objetos.

El lenguaje está dotado de múltiples herramientas para lograr la especificación determinante del modelo, pero en nuestro caso se trabaja en forma simplificada sobre:

Modelamiento de Clases.

Casos de Uso.

Diagrama de Interacción.


72

Ejemplo de diagrama de interacción,

Los diagramas de clases de UML forman la vista lógica.

Los diagramas de interacción de UML constituyen la vista de proceso.

La vista de desarrollo captura el software en su entorno de desarrollo.

Los diagramas de despliegue integran la vista física.

Los escenarios: el modelo de casos de uso.

Un diagrama de clases está compuesto por los siguientes elementos:

Clase: atributos, métodos y visibilidad.

Recuerda que una clase es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).

Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

En UML, una clase es representada por un rectángulo que posee tres divisiones.


73

En donde,

Superior. El nombre por el que se reconocerá la clase.

Intermedio. El listado de cualidades o atributos.

Inferior. Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad, private, protected o public).

Por ejemplo,

Una Cuenta Corriente que posee como característica el balance podría realizar las siguientes operaciones,

Depositar

Girar

Balance

y el diseño asociado sería

Los atributos o características de una clase, como hemos comentado en el párrafo anterior, pueden ser de tres tipos:

1. public (+). Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados.

2. private (-). Señala que el atributo sólo será accesible desde dentro de la clase. 3. protected (#).

Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características:

public (+). Señala que el método será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados.

private (-). Indica que el método sólo será accesible desde dentro de la clase.

protected (#). Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accedido por métodos de la clase además de métodos de las subclases que se deriven.

La herencia (especialización/generalización) indica que una subclase hereda los métodos y atributos especificados por una Super Clase.

La Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected), ejemplo:

Por ejemplo, en el siguiente esquema se especifica que Auto y Camión heredan de Vehículo, es decir, Auto posee las Características de Vehículo (Precio, VelMax, etc) además posee algo particular que es Descapotable, en cambio Camión también hereda las características de Vehículo (Precio, VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.


74

Lo único "visible" es el método Características aplicable a instancias de Vehículo, Auto y Camión, pues tiene definición pública, en cambio atributos como Descapotable no son visibles por ser privados.

Para modelar objetos complejos no bastan los tipos de datos básicos que proveen los lenguajes (enteros, reales y secuencias de caracteres).

Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades:

Por Valor. Este tipo de relación es comúnmente llamada composición (el objeto base se construye a partir del objeto incluido, es decir, es "parte/todo").

Por Referencia. Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada agregación (el objeto base utiliza al incluido para su funcionamiento).

Por ejemplo, un caso de relación dinámica,

En donde se destaca que:

Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias).


75

Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.

La composición (por Valor) se destaca por un rombo relleno.

La agregación (por Referencia) se destaca por un rombo transparente.

La flecha en este tipo de relación indica la navegabilidad del objeto referenciado. Cuando no existe este tipo de particularidad la flecha se elimina.

La relación entre clases conocida como Asociación permite asociar objetos que colaboran entre sí. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.

Por ejemplo,

El objeto creado (en este caso Ventana) no se almacena dentro del objeto que lo crea (en este caso Aplicación).

Una clase abstracta se denota con el nombre de la clase y de los métodos con letra "itálica".

Esto indica que la clase definida no puede ser instanciada pues posee métodos abstractos (aún no han sido definidos, es decir, sin implementación). La única forma de utilizarla es definiendo subclases, que implementan los métodos abstractos definidos.

Una clase parametrizada se denota con un subcuadro en el extremo superior de la clase, en donde se especifican los parámetros que deben ser pasados a la clase para que esta pueda ser instanciada.

Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso.


76

Es importante resaltar que los diagramas de casos de uso no están pensados para representar el diseño y no puede describir los elementos internos de un sistema. Este tipo de herramienta se utiliza para facilitar la comunicación con los futuros usuarios del sistema, y con el cliente, y resultan especialmente útiles para determinar las características necesarias que tendrá el sistema.

Los diagramas de casos de uso describen qué es lo que debe hacer el sistema, pero no cómo.

Ejemplos usando UML Modeller,

Un caso de uso describe, —desde el punto de vista de los actores—, un grupo de actividades de un sistema que produce un resultado concreto y tangible.

Los casos de uso son descriptores de las interacciones típicas entre los usuarios de un sistema y ese mismo sistema.


77

Cuando se trabaja con casos de uso es importante tener presentes algunas reglas:

Cada caso de uso está relacionado como mínimo con un actor.

Cada caso de uso es un iniciador (es decir, un actor).

Cada caso de uso lleva a un resultado relevante (un resultado con «valor intrínseco»).

Recuerda…

Los lenguajes no compilados dinámicamente son también conocidos como Tipados estáticamente.

Una clase abstracta se denota con el nombre de la clase.

La herencia está fuertemente ligada a la reutilización del código en la programación orientada a objetos.

En lenguajes compilados, los métodos pueden ser objetos de primera clase.

Algunos metodólogos del software orientado a objetos distinguen tres grandes generaciones.

En la visión tradicional de la programación un programa no puede ser una colección de objetos con propiedades.

El uso de un lenguaje de modelado es más sencillo que la auténtica programación.

Módulo es como se denominan cada una de las partes de un programa que resuelve alguno de los apartados en que se divide el problema complejo original.

Java permite que la definición de los tipos de objetos se pueda producir por un mecanismo llamado enlazado posterior.

Una clase parametrizada no se denota con un subcuadro en centro recogiendo los parámetros a pasar.


78

3. ARQUITECTURAS WEB

La arquitectura Web es la unión de multitud de acciones encaminadas al desarrollo de páginas web y su optimización así como un control del posicionamiento que en los buscadores puede llegar a alcanzar.

3.1. Concepto de arquitectura web

El principal objetivo de la arquitectura Web es resolver las necesidades específicas que han hecho que la empresa cliente se plantee su presencia en Internet desde un sitio web o una aplicación:

Venta de productos.

Servicios online.

Satisfacción de las necesidades de los potenciales clientes.

Al igual que los principios que rigen la arquitectura tradicional, el diseño web de un portal o una aplicación específica se basa en la satisfacción de las necesidades de las personas a las que va dirigido el negocio.

Los detalles de un edificio son equiparables al diseño que requiere una página web por lo que es habitual la comparación de ambas construcciones para reforzar aspectos concretos, como por ejemplo, la recomendación de acudir a profesionales especializados específicamente en las siguientes áreas:

Lenguajes de programación.

Bases de datos.

Es fundamental destacar que la formación y experiencia que requiere la puesta en marcha de las acciones englobadas en la arquitectura Web requiere de profesionales en constante formación, dinámicos y en continua evolución, con el valor agregado de contar con la constancia del objetivo final: La satisfacción de los usuarios que utilizarán el portal Web.

El efecto de la arquitectura Web sobre el posicionamiento es total porque la inclusión de aplicaciones dinámicas y adaptables a las necesidades de los usuarios facilitaría una navegación sencilla y el uso de acciones rápidas aumentará las posibilidades de alcanzar un buen posicionamiento y, además, haría aumentar nuestra reputación online lo que influiría positivamente en el retorno de los clientes.

El efecto final de un buen posicionamiento Web es el de generar tráfico y visitas hacia un portal a partir de una óptima coordinación con los motores de búsqueda y de todos ello, fundamentalmente de Google.

Los arquitectos Web y especialistas en posicionamiento son profesionales especializados en evitar este tipo de situaciones y sus objetivos apuntan al éxito de su proyecto, por lo que contratar asesoría experta es una inversión con óptimo nivel de retorno que no se debe pasar por alto.


79

3.2. El modelo de capas

La estrategia tradicional de utilizar aplicaciones compactas causa gran cantidad de problemas de integración en sistemas software complejos como pueden ser los sistemas de gestión de una empresa o los sistemas de información integrados consistentes en más de una aplicación. Estas aplicaciones suelen encontrarse con importantes problemas de escalabilidad, disponibilidad, seguridad, integración...

Para solventar estos problemas se ha generalizado la división de las aplicaciones en capas que normalmente serán tres:

1. Una capa que servirá para guardar los datos (base de datos). 2. Una capa para centralizar la lógica de negocio (modelo). 3. Una interfaz gráfica que facilite al usuario el uso del sistema.

Si establecemos una separación entre la capa de interfaz gráfica (cliente), desarrollada en cada uno de los entornos de usuario, y la capa modelo podríamos concluir con una potente arquitectura con las siguientes ventajas:

Centralización de los aspectos de seguridad.

No replicación de lógica de negocio en los clientes,

Mayor sencillez de los clientes.

Si intentamos aplicar esto a las aplicaciones web, debido a la obligatoria sencillez del software cliente que será un navegador web, nos encontramos con una doble posibilidad:

Crear un modelo de 4 capas separando cliente, servidor web, modelo y almacén de datos. Otorgando una mayor extensibilidad en caso de que existan también clientes no web en el sistema, que trabajarían directamente contra el servidor del modelo.


80

Mantener el número de capas en 3 integrando interfaz web y modelo en un mismo servidor aunque conservando su independencia funcional. Ésta es la distribución en capas más común en las aplicaciones web

Por ejemplo, la arquitectura utilizada por el proyecto ONess define tres capas bien diferenciadas, si bien gracias al soporte que proporciona en framework Spring permite la implantación de una capa de modelo basada en Enterprise JavaBeans (EJB) que posibilitase una arquitectura de cuatro capas y unas funcionalidades más orientadas a grandes sistemas o sistemas críticos como pueden ser replicación, trabajo en cluster, …

3.3. Plataformas para el desarrollo en las capas servidor

Un servicio web (en inglés, Web Service o Web services) es una tecnología que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones.

Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet. Esto es fundamental.

La interoperabilidad se consigue mediante la adopción de los llamados estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y reglamentación de los servicios Web.

También, para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I, encargado de desarrollar diversos perfiles para definir de manera más exhaustiva estos estándares. Podemos resumirlo como una máquina que atiende las peticiones de los clientes web y les envía los recursos solicitados.

Aquí una lista de los principales servidores de aplicaciones para servicios Web:

JBoss servidor de aplicaciones J2EE Open Source de Red Hat inc.

Oracle Fusion Middleware.


81

IBM Lotus Domino a partir de la versión 7.0.

Axis y el servidor Jakarta Tomcat (de Apache)

ColdFusion MX de Macromedia.

Java Web Services Development Pack (JWSDP) de Sun Microsystems (basado en Jakarta Tomcat).

JOnAS (parte de ObjectWeb una iniciativa de código abierto).

Microsoft .NET.

Novell exteNd (basado en la plataforma J2EE).

WebLogic.

WebSphere.

JAX-WS con GlassFish.

VERASTREAM de AttachmateWRQ para modernizar o integrar aplicaciones host IBM y VT.

PHP.

Zope es un servidor de aplicaciones Web orientado a objetos desarrollado en el lenguaje de programación Python.


82

3.4. Herramientas de desarrollo orientadas a servidor de aplicaciones web

Tipos de herramientas.

Herramientas front-end. Tiene la misión especial de facilitar el engorroso trabajo del programador, intentando cubrir el hueco que existe entre el diseñador y el programador. No tiene por qué ser más fácil hacer un sitio web usando estas herramientas que cuando no las había porque actualmente la cantidad de elementos a incluir en una aplicación web son muchos más y de mayor complejidad que en los principios del diseño.

Ejemplos: Easel, SQLNetwork de Gupta y Extra de Attachmate

Herramientas de acceso a bases de datos de PCs. Pretenden conjuntar capacidades visuales de creación de GUIs con un lenguaje 3GL o 4GL con el diseño y gestión de bases de datos. Estos productos utilizan generalmente gateways o pasaralenas para acceder a bases de datos de servidor. Algunas pueden funcionar con más de una base de datos.

Por ejemplo, Visual Basic de Microsoft, ObjectVision de Borland, ObjectView de KnowledgeWare, SQLWindows de Gupta, PowerBuilder de PowerSoft, Easel Workbench de Easel, CA-dBFast de Computer Associates y Uniface.

Bibliotecas orientadas a objetos. Se trata de las llamadas bibliotecas de clase para ayudar a los programadores en la construcción de aplicaciones Windows orientada a objetos.

Lenguajes 3GL para proceso cliente/servidor. Tienen como objetivo interconectar las interfaces de programación de aplicaciones Windows (API) con potentes conexiones con el entramado Microsoft o Borland. La mayor parte están adquiriendo drivers ODBC, basados en el estándar Open Database Connectivity de Microsoft. Generalmente son débiles en el acceso a SQL.

Por ejemplo, C++ y Pascal for Windows de Borland, C 7.0 y Visual C++ de Microsoft, Realia Cobol de CA.


83

Lenguajes 4GL para proceso cliente/servidor. Similar al anterior pero con tecnología 4GL.

Ejemplos, Mapper de Unisys, Focus de Information Builders, Natural de Software AG, Powerhouse de Cognos, Windows 4GL de ASK Group, PGA, Progress 4GL..

Herramientas con base de conocimientos. Algunos vendedores de productos de inteligencia artificial han presentado herramientas de uso general orientadas a objetos para proceso cliente/servidor.

Estos productos resultan excelentes para crear aplicaciones en las que intervengan reglas y lógica complejas, integradas en el entorno Windows.

Ejemplos, ProKapp PC de Intellicorp, Enterprise Object de Inference, LBMS.

Herramientas para consultas e informes gráficos. Permiten la creación de sistemas de información ejecutiva empleando una metáfora de hoja electrónica simple para crear informes y consultas.

Ejemplos: Forest and Trees de Trinzic, DataEase Express for Windows de DataEase International, Q+E Database Editor de Pioneer Software, Holos C/S de Ross Systems.

Herramientas CASE. Las herramientas CASE tienen la ventaja de disponer módulos de análisis y diseño más amplios que la mayoría de las herramientas de red. Además, las metodologías CASE incluyen características de gestión de proyectos y control de versiones que son importantes para crear aplicaciones a nivel de empresa. La mayoría de las herramientas Windows son mejores que CASE como soluciones departamentales de menor escala.

Ejemplos, Synon CSG de Synon, Application Development Workbench de Knowledgeware, High Productivity System de SEER Technologies, Method Manager de Manager Software Products, System-Architect de Popkin Software Systems, Foundation de Andersen Consulting, Axiant de Cognos, Informix, Momentum de Sybase.

Extensibilidad. Instalación de módulos.

Una de las ventajas de la instalación de extensiones concretas es, por ejemplo, permitir rellenar formularios y hacer clic en un botón "Enviar" para enviar datos a un servidor Web e invocar la aplicación correspondiente que se encargará de procesar la información para proporcionar contenido personalizado o almacenarlo en una base de datos.

Las extensiones de servidor Web pueden usar la información de una base de datos para generar páginas Web dinámicamente y después enviarlas a los equipos cliente para su presentación. Su aplicación puede añadir funcionalidad personalizada y proporcionar datos al cliente mediante HTTP y HTML.

Tanto las extensiones como los filtros de servidor se ejecutan en el espacio de procesos del servidor Web, proporcionando una forma eficiente de extender la capacidad del servidor.

Por ejemplo, una extensión de servidor ISAPI (Microsoft) es un archivo DLL que puede cargarse y ser llamado por un servidor HTTP. Las extensiones de servidor de Internet, también conocidas como aplicaciones de servidor de Internet (ISA), se utilizan para ampliar las capacidades de un servidor compatible con la API de servidor de Internet (ISAPI).


84

Técnicas de configuración de los entornos de desarrollo, preproducción y producción.

Que un producto funcione en el entorno de pruebas no garantiza al 100% su funcionamiento en el entorno de producción. Podemos encontrarnos que una misma versión de una aplicación funcione correctamente en pruebas y no en el entorno de producción y al revés, es decir, que funcione en producción, pero que no funcione en pruebas.

Un entorno de preproducción resulta esencial en el conjunto del desarrollo software por lo que no hay que mimar sólo las infraestructuras de producción, debiéndose dotar de recursos hardware, software y humanos suficientes al entorno de preproducción para que sea coherente con el de producción, garantizándose que si el producto funciona correctamente en preproducción, además de cumplir los requisitos de seguridad, rendimiento, etc. tendrá un comportamiento similar en el entorno de producción.

Las actividades mejor soportadas por herramientas de desarrollo son normalmente las de codificación y las vinculadas a la realización de pruebas. El conjunto de herramientas que soportan estas actividades constituyen lo que se llama un entorno de programación. A veces se utilizan las siglas IDE (Integrated Development Environment) para designar estos entornos, aunque no son un entorno de desarrollo completo, sino sólo una parte de él.


85

Funcionalidades de depuración.

La depuración de programas es el proceso de identificar y corregir errores de programación. En inglés se le conoce como debugging (buscando la analogía con la eliminación de bugs / bichos), y así es como se conoce informalmente a los errores de programación.

Se dice que el término bug proviene de la época de los ordenadores de válvula termoiónica, en los cuales los problemas se generaban por los insectos que eran atraídos por las luces y estropeaban el equipo.

Existen técnicas para la revisión sistemática del código fuente y medios computacionales para la detección de errores (depuradores) y ayudas integradas en los sistemas lower CASE y en los ambientes de desarrollo integrado pero sigue siendo en buena medida una comprobación manual que ponga en valor la intuición del programador.

En ocasiones se requiere incluir en el código fuente instrucciones auxiliares que permitan el seguimiento de la ejecución del programa, presentando los valores de variables y direcciones de memoria y ralentizando la salida de datos (modo de depuración). Dentro de un proceso formal de aseguramiento de la calidad, puede ser asimilado al concepto de prueba unitaria.

86

4. LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR

Un lenguaje del lado del servidor es aquel que se ejecuta en el servidor web, justo antes de que se envíe la página a través de Internet al cliente. Las páginas que se ejecutan en el servidor pueden realizar accesos a bases de datos, conexiones en red, y otras tareas para crear la página final que verá el cliente.

Los lenguajes de lado servidor más ampliamente utilizados para el desarrollo de páginas dinámicas son el ASP, JSP, PERL y PHP.

4.1. Características de los lenguajes de programación web en servidor

Lenguaje ASP.

ASP no necesita ser compilado para ejecutarse. Existen varios lenguajes que se pueden utilizar para crear páginas ASP. El más utilizado es VBScript, nativo de Microsoft. ASP se puede hacer también en Perl and Jscript (no JavaScript). El código ASP puede ser insertado junto con el código HTML. Los archivos cuentan con la extensión (asp).

Perl.

Perl es un lenguaje de propósito general originalmente desarrollado para la manipulación de texto y que ahora es utilizado para un amplio rango de tareas incluyendo administración de sistemas, desarrollo web, programación en red, desarrollo de GUI y más.

Se creó con la idea de que fuera práctico (facilidad de uso, eficiente, completo) en lugar de hermoso (pequeño, elegante, mínimo). Sus principales características son que es fácil de usar, soporta tanto la programación estructurada como la programación orientada a objetos y la programación funcional, tiene incorporado un poderoso sistema de procesamiento de texto y una enorme colección de módulos disponibles.

Python.

Python es un lenguaje de programación multiparadigma. Esto significa que más que forzar a los programadores a adoptar un estilo particular de programación, permite varios estilos: Programación orientada a objetos, programación estructurada, programación funcional y programación orientada a aspectos. Otros muchos paradigmas más están soportados mediante el uso de extensiones.

SSI (Server Side Includes).

Los Server Side Includes o Inclusiones del Lado Servidor aportan un sencillo lenguaje de programación del lado servidor usado básicamente para el desarrollo de webs. Su cometido básico es el de incluir los contenidos de un fichero dentro de otro, mediante la especificación de una sencilla instrucción que es procesada por el servidor Web.

Por ejemplo, mediante la inclusión de un sencillo código del tipo

 podremos hacer que el servidor web nos incluya siempre dentro del fichero HTML el texto contenido en el fichero “texto.txt”.


87

CGI.

Es el sistema más antiguo que existe para la programación de las páginas dinámicas de servidor. Actualmente se encuentra un poco por la pesada carga que supone para el servidor que los ejecuta.

Los CGI se escriben habitualmente en el lenguaje Perl, sin embargo, otros lenguajes como C, C++ o Visual Basic pueden ser también empleados para construirlos.

PHP.

Es un lenguaje de programación utilizado para la creación de sitio web. PHP significa “Hypertext Pre-processor”, inicialmente se llamó (Personal Home Page). Es un lenguaje de script interpretado en el lado del servidor utilizado para la generación de páginas web dinámicas.

PHP no necesita ser compilado para ejecutarse, para su funcionamiento necesita tener instalado Apache o IIS con las librerías de PHP. Los archivos cuentan con la extensión (php).

JSP.

Es un lenguaje para la creación de sitios web dinámicos, acrónimo de Java Server Pages. Está orientado a desarrollar páginas web en Java es un lenguaje multiplataforma.

Ruby.

Es un lenguaje interpretado de muy alto nivel y orientado a objetos, que puede cargar librerías de extensiones dinámicamente si el sistema operativo lo permite. Con una sintaxis inspirada en Python y Perl.

ASP.NET.

Para su funcionamiento de las páginas se necesita tener instalado IIS con el Framework .Net. El lenguaje ASP consiste en una serie de clases .NET utilizadas para crear aplicaciones Web, tanto del lado cliente (Web Form) como del lado servidor (Web Service).

4.2. Tipos y características de los lenguajes de uso común

Interpretados orientados a servidor.

Los lenguajes de lado de servidor surgieron de la necesidad de dotar a las páginas web de mayor funcionalidad y de superar el hecho de que fueran totalmente estáticas. Un lenguaje interpretado no necesita compilación previa, es decir, se ejecuta al mismo tiempo que se va analizando semántica y sintácticamente, lo que conlleva un ahorro de tiempo de máquina importante.

El funcionamiento de los lenguajes de lado de servidor puede esquematizarse en los pasos que indica la siguiente imagen.


88

Lenguajes de cliente interpretados en servidor.

También es posible desarrollar dichas aplicaciones con lenguajes compilados como Java o incluso C/C++.

Entre las características de estos intérpretes encontramos:

Son multiplataforma, es decir, siempre que contemos con una implementación del intérprete para nuestro sistema operativo podremos correr la aplicación. Los intérpretes más utilizados cuentan con una licencia libre.

Permiten intercalar contenido estático HTML y código interpretado. En lugar de escribir todo un programa que genere la salida deseada, lo que se escribe es un documento (una página web) en la que mediante el uso de unas marcas se incluye el código que deberá ser interpretado.

Se trata de lenguajes de alto nivel que facilitan el desarrollo rápido de la aplicación.

Lenguajes compilados.

Un lenguaje compilado es aquel cuyo código fuente, escrito en un lenguaje de alto nivel, es traducido por un compilador a un archivo ejecutable entendible para la máquina en determinada plataforma. Con ese archivo se puede ejecutar el programa cuantas veces sea necesario sin tener que repetir el proceso por lo que el tiempo de espera entre ejecución y ejecución es ínfimo.

Dentro de los lenguajes de programación que son compilados tenemos la familia C que incluye a C++, Objective C, C# y también otros como Fortran, Pascal, Haskell y Visual Basic.

Java es un caso particular ya que hace uso de una máquina virtual que se encarga de la traducción del código fuente por lo que hay veces es denominado compilado e interpretado. Esta máquina virtual permite ejecutar código Java en cualquier máquina que la tenga instalada. En muchas ocasiones esto es una gran ventaja.

Los lenguajes interpretados se usa de forma masiva en el desarrollo de aplicaciones o sitios web que van acompañados de frameworks que facilitan en gran medida su programación. La gran mayoría necesitan simplemente un navegador actualizado y conexión a Internet para acceder a las aplicaciones en línea.

Los lenguajes compilados se utilizan más para desarrollar software de escritorio ya que requieren mayores recursos y acceso a archivos determinados. También, naturalmente, por el peso mayor que estos suelen tener en sus archivos ejecutables.

4.3. Criterios en la elección de un lenguaje de programación web en servidor. Ventajas e inconvenientes

Sabemos que un lenguaje del lado del servidor es aquel que se ejecuta en el servidor web, justo antes de que se envíe la página a través de Internet al cliente. Las páginas que se ejecutan en el servidor pueden realizar accesos a bases de datos, conexiones en red y otras tareas para crear la página final que verá el cliente.

Entre los lenguajes de programación, no hay una sola aplicación que hace todas las cosas diferentes, de todas las maneras diferentes, que los programadores necesitan. Debido a la gran cantidad y diversidad de las tareas de programación, la elección de una aplicación web lenguaje de programación se ha convertido en un paso de importancia crítica.


89

En el desarrollo de una nueva aplicación web encontramos diversas alternativas, entre las más utilizadas: PHP, Python, Perl, Ruby y JavaServer Pages.

Destaca el caso del PHP, trabajando bajo una licencia libre sin copyleft y no compatible con la GPL. Goza de una gran aceptación, se encuentra en continua evolución y hay una gran colección de bibliotecas y componentes escritos que pueden ser utilizados.

Tanto Python como Perl provienen del mundo de la administración de sistemas pero cuentan con su cuota particular de aplicaciones web. Ambos disponen de intérpretes libres y de una gran colección de componentes/bibliotecas que pueden ser utilizados para casi cualquier necesidad. En el caso de Python su uso se suele asociar a frameworks propios como Zope o Django.

Cuando se programa en PHP se escriben documentos, conocidas como páginas web, que contienen su propio código HTML. Si no se trata de una página estática, en algún punto del documento se introducirá mediante la marca "<?php" el inicio de un bloque de PHP.

Es aquí donde se introducirá el código que será procesado por el intérprete y para marcar su fin se utilizará la marca "?>".

En un mismo documento es posible abrir y cerrar fragmentos de código PHP varias veces, entrelazando las sentencias script con el código HTML estático.

Veamos un ejemplo,

<HTML>

<HEAD>

<TITLE>Ejemplo PHP</TITLE>

</HEAD>

<BODY>

<?php echo '<p>Hola Mundo</p>'; ?>

</BODY>

</HTML>

4.4. Características generales

Tipos de datos.

A la hora de programar tendremos que hacer uso de multitud de datos de diferentes tipos, es decir que podrán contener formas de información concretas.

PHP dispone distintos tipos de estos datos que es necesario conocer para poder programar con garantías. Ninguno de ellos es difícil de asimilar aunque unos son más simples que otros.

Cuando asignamos una variable a un tipo de dato, ésta adquirirá en su denominación la del tipo de dato.

Por ejemplo, si asignamos a una variable un dato booleano ésta se llamará variable de tipo booleano.


90

Booleanos.

Para hacer una variable de este tipo tan solo hay que escribir su nombre y asignarle o true o false; ya que éstos son los dos únicos datos booleanos que existen.

Por ejemplo,

<?php

$guapo = true;

$simpatico = false;

?>

El valor false equivale al número 0 mientras que el valor true a cualquier otro número. No obstante, se suele utilizar el número 1.

Enteros.

También se incluye el cero y los números negativos.

Por ejemplo,

<?php

$cero = 0;

$ocho = 8;

$ocho = -3;

?>

Decimales.

Por ejemplo,

<?php

$mi_nota = 7.5;

$tu_nota = 8.67;

$mi_negativo = -2.32;

?>

Cadenas.

Una cadena es una sucesión de caracteres. Estos pueden ser letras, números, signos de puntuación y en general cualquier carácter.

Para escribir cadenas es necesario ponerlas entre comillas, con la posibilidad que sean comillas simples o dobles.

Vemos un ejemplo:


91

<?php

$mi_cadena = 'hola, mundo.';

?>

Clases.

La sintaxis básica de una clase en PHP es la siguiente.

<?php

class nombre_clase {

var $propiedad_1;

var $propiedad_2;

var $propiedad_3;

function método_1($parametro) {

instrucciones_del_método;

}

}

?>

Una vez definida la clase, que es el molde del objeto, se pueden crear instancias a partir de ella. En PHP se hace de la siguiente forma:

<?php

$nombre_instancia = new nombre_clase($parametros);

?>

En PHP no hay una forma establecida de organizar las clases. Una buena forma de hacerlo es escribiendo cada clase en un archivo distinto, de forma que a simple vista y sin tener que ver el contenido se pueda saber dónde está cada una. Para poder hacer uso de esa clase, es decir, para poder crear instancias de ella hay que hacer que su definición se incluya, esté presente, en el archivo donde se cree su instancia.

Por ejemplo,

<?php

include("clases/class_persona.php");

$luis=new Persona();

?>


92

Sin la instrucción del include, que sustituye esa instrucción por el contenido de class persona.php, no se podría crear una instancia de la clase Persona, ya que la aplicación no encontraría su definición en ningún sitio.

Operadores básicos. Manipulación de cadenas de caracteres.

En PHP, por ejemplo, se pueden usar los operadores habituales en los distintos lenguajes de programación.

Estos operadores nos permiten realizar operaciones aritméticas: suma, resta, multiplicación, división, etc. así como obtener el módulo o resto de una división entre dos enteros.

Por ejemplo, el operador resto o módulo es un operador útil en algunos procesos repetitivos en programación. Fijémonos en los valores que toma cuando van progresando los valores que toma una variable.


93

Operadores de incremento y decremento.

Operadores de asignación.

Con el uso de los operadores de asignación, podremos simplificar (escribir abreviadamente) algunas expresiones de asignación.

Es muy importante conocer el significado de estas expresiones por si nos enfrentamos a tener que interpretar código escrito por otras personas.

Estructuras de control. Bucles y condicionales.

La sentencia If evalúa una condición, expresada entre paréntesis ( ). Si esta se cumple, ejecuta el bloque de instrucciones que tiene entre llaves { }.


94

if (condición) {

bloque de instrucciones;

}

También podemos indicar un bloque de instrucciones, con la palabra else, que se ejecutará si no se cumple la instrucción.

if (condición) {

bloque de instrucciones si se cumple;

} else {

bloque de instrucciones si nos e cumple;

}

Podemos poner varios elseif, con otras condiciones entre paréntesis. Se irán evaluando todas las condiciones hasta encontrar la primera cierta. Si una se cumple, se ejecutarán sólo esas instrucciones, aunque hubiesen otras condiciones ciertas. Si no se ha cumplido ninguna, se ejecutará el else si lo hay.

if (condición1) {

bloque de instrucciones si se cumple condición1;

} elseif (condición2) {


} elseif (condición3) {


} elseif {

bloque de instrucciones si no se ha cumplido ninguna;

}

Las sentencias If se pueden anidar, siempre que una quede completamente dentro de otra.

Cuando se emplea la sentencia If para asignar un valor a una variable, se suele utilizar la siguiente estructura, más compacta:

$variable = (condición) ? valor_si_se_cumple : valor_si_no;

Por ejemplo:

$calificacion = (nota < 5) ? 'Suspenso' : 'Aprobado';

Los bucles nos permiten iterar conjuntos de instrucciones, es decir repetir la ejecución de un conjunto de instrucciones mientras se cumpla una condición.


95

Sentencia while.

<?php

while (condición)

{

instrucciones a ejecutar.

}

?>

Mientras la condición sea cierta se reiterará la ejecución de las instrucciones que están dentro del while.

Ejemplo básico de While,

Módulos o paquetes.

Un Paquete en Java es un contenedor de clases que permite agrupar las distintas partes de un programa cuya funcionalidad tienen elementos comunes.

El uso de paquetes proporciona las siguientes ventajas:

Agrupamiento de clases con características comunes.

Reutilización de código.

Mayor seguridad al existir niveles de acceso.

Un paquete puede contener:

Clases

Interfaces

Tipos Enumerados

Anotaciones


96

Herencia.

La herencia significa que se pueden crear nuevas clases partiendo de clases existentes, que tendrá todos los atributos y los métodos de su 'superclase' o 'clase padre' y además se le podrán añadir otros atributos y métodos propios.

En el caso concreto de PHP, a diferencia de otros lenguajes orientados a objetos (C++), una clase sólo puede derivar de una única clase, es decir, PHP no permite herencia múltiple.

Las clases hijas (descendientes) heredan (incorporan) automáticamente los atributos y métodos de la clase padre.

Subclase.

Clase descendiente de otra. Hereda automáticamente los atributos y métodos de su superclase. Es una especialización de otra clase. Admiten la definición de nuevos atributos y métodos para aumentar la especialización de la clase.

Por ejemplo,

class Suma extends Operacion{

Utilizamos la palabra clave extends y seguidamente el nombre de la clase padre (con esto estamos indicando que todos los métodos y atributos de la clase Operación son también métodos de la clase Suma).

Luego la característica que añade la clase Suma es el siguiente método:

public function operar()

{

$this->resultado=$this->valor1+$this->valor2;

}

El método operar puede acceder a los atributos heredados (siempre y cuando los mismos se declaren protected, en caso que sean private si bien lo hereda de la clase padre solo los pueden modificar métodos de dicha clase padre.

Ahora podemos decir que la clase Suma tiene cuatro métodos (tres heredados y uno propio) y 3 atributos (todos heredados)

Si creamos un objeto de la clase Suma tenemos:

$suma=new Suma();

$suma->cargar1(10);

$suma->cargar2(10);

$suma->operar();

echo 'El resultado de la suma de 10+10 es:';

$suma->imprimirResultado();


97

Podemos llamar tanto al método propio de la clase Suma "operar()" como a los métodos heredados. Quien utilice la clase Suma solo debe conocer que métodos públicos tiene (independientemente que pertenezcan a la clase Suma o a una clase superior).

En otro ejemplo podemos considerar que el problema consta de tres tipos de vehículo: taxi, autobús y tranvía, y que esos tipos los denominamos clases.

Gestión de bibliotecas (libraries).

El uso de librerías es tremendamente útil, nos permiten agrupar varias funciones y variables en un mismo fichero, de manera que luego podemos incluir esta librería en distintas páginas y disponer de esas funciones fácilmente.

4.5. Gestión de la configuración

Configuración de descriptores.

Un descriptor es un fichero XML que contiene información necesaria para que una aplicación web funcione en el lado del servidor. No olvidar que la tecnología Java necesita un servidor complementario funcionando. Este servidor podría ser Apache Tomcat que viene incluido en el paquete XAMP.

Sólo deben crear una carpeta local en raíz o dentro directorio “Archivos de programa“, esta será la ruta a la que accederá el Netbeans. Los principales directorios que se generan son:

/bin – contiene los elementos necesarios para el arranque o cierre del servidor, así como otras utilerías.

/temp – principalmente gestionado por el servidor para manejar archivos temporales.


98

/conf – Desde esta ubicación se configuran algunos parámetros principales.

/logs – historial de registros del servidor.

/webapps – directorio que contiene las aplicaciones web a desarrollar.

/work – almacén temporal de ficheros y directorios.

Para iniciar el servidor basta con ejecutar el archivo startup.bat y shutdown.bat para detenerlo, ubicados en el directorio /bin, pero antes debemos configurar el acceso.

Configuración de ficheros.

WebContent.

Ficheros típicos de web (HTML, JavaScript, CSS, JSP, imágenes, etc.). Aquí es habitual tener un fichero index.html o index.jsp. Pueden organizarse en subdirectorios.

WebContent/WEB-INF.

web.xml – descriptor de despliegue. Se puede omitir en servlet 3.0 apps, si se hacen los mappings de servlet con las anotaciones @WebServlet en el código Java

WebContent/WEB-INF/lib.

Ficheros JAR específicos de la aplicación

src/paquete.

Código Java del paquete. Para crear un paquete hacer New package en "Java Resources: src" Usar siempre paquetes. No es nada recomendable usar el default

4.6. Gestión de la seguridad

Es la protección de la infraestructura computacional y todo lo relacionado con ésta, incluyendo la información que ésta contenga. Existen una serie de estándares, protocolos, métodos, reglas, herramientas y leyes concebidas, para minimizar los posibles riesgos a los medios o la información.

Conceptos de identificación, autenticación y autorización.

Es la primera línea de defensa para la mayoría de los sistemas computarizados, permitiendo prevenir el ingreso de personas no autorizadas. Es la base para la mayor parte de los controles de acceso y para el seguimiento de las actividades de los usuarios.

Existen cuatro tipos de técnicas que permiten realizar la autenticación de la identidad del usuario, las cuales pueden ser utilizadas individualmente o combinadas:

Una clave secreta de acceso o password, una clave criptográfica, un número de identificación personal o PIN, etc. Algo que el usuario conoce.

Uso de tarjetas magnéticas o digitales. Algo que el usuario utiliza.

Huellas digitales o la voz. Algo que el usuario posee.

Uso de patrones de escritura. Algo que el usuario sabe hacer.


99

Para cada una de estas técnicas vale lo mencionado en el caso de la seguridad física en cuanto a sus ventajas y desventajas. Se destaca que en los dos primeros casos enunciados, es frecuente que las claves sean olvidadas o que las tarjetas o dispositivos se pierdan, mientras que por otro lado, los controles de autenticación biométricos serían los más apropiados y fáciles de administrar, resultando ser también, los más costosos por lo dificultosos de su implementación eficiente.

Desde el punto de vista de la eficiencia, es conveniente que los usuarios sean identificados y autenticados solamente una vez, pudiendo acceder a partir de allí, a todas las aplicaciones y datos a los que su perfil les permita, tanto en sistemas locales como en sistemas a los que deba acceder en forma remota. Esto se denomina "single login" o sincronización de passwords.

Una de las posibles técnicas para implementar esta única identificación de usuarios sería la utilización de un servidor de autenticaciones sobre el cual los usuarios se identifican, y que se encarga luego de autenticar al usuario sobre los restantes equipos a los que éste pueda acceder. Este servidor de autenticaciones no debe ser necesariamente un equipo independiente y puede tener sus funciones distribuidas tanto geográfica como lógicamente, de acuerdo con los requerimientos de carga de tareas.

La seguridad informática se basa, en gran medida, en la efectiva administración de los permisos de acceso a los recursos informáticos, basados en la identificación, autenticación y autorización de accesos.

Esta administración abarca:

Proceso de solicitud, establecimiento, manejo, seguimiento y cierre de las cuentas de usuarios. Es necesario considerar que la solicitud de habilitación de un permiso de acceso para un usuario determinado, debe provenir de su superior y, de acuerdo con sus requerimientos específicos de acceso, debe generarse el perfil en el sistema de seguridad, en el sistema operativo o en la aplicación según corresponda.

Además, la identificación de los usuarios debe definirse de acuerdo con una norma homogénea para toda la organización.

Revisiones periódicas sobre la administración de las cuentas y los permisos de acceso establecidos.

Las revisiones deben orientarse a verificar la adecuación de los permisos de acceso de cada individuo de acuerdo con sus necesidades operativas, la actividad de las cuentas de usuarios o la autorización de cada habilitación de acceso. Para esto, deben analizarse las cuentas en busca de períodos de inactividad o cualquier otro aspecto anormal que permita una redefinición de la necesidad de acceso.

Detección de actividades no autorizadas. Además de realizar auditorías o efectuar el seguimiento de los registros de transacciones (pistas), existen otras medidas que ayudan a detectar la ocurrencia de actividades no autorizadas.

Nuevas consideraciones relacionadas con cambios en la asignación de funciones del empleado. Para implementar la rotación de funciones, o en caso de reasignar funciones por ausencias temporales de algunos empleados, es necesario considerar la importancia de mantener actualizados los permisos de acceso.


100

Procedimientos a tener en cuenta en caso de desvinculaciones de personal con la organización, llevadas a cabo en forma amistosa o no. Los despidos del personal de sistemas presentan altos riesgos ya que en general se trata de empleados con capacidad para modificar aplicaciones o la configuración del sistema, dejando "bombas lógicas" o destruyendo sistemas o recursos informáticos. No obstante, el personal de otras áreas usuarias de los sistemas también puede causar daños, por ejemplo, introduciendo información errónea a las aplicaciones intencionalmente.

Para evitar estas situaciones, es recomendable anular los permisos de acceso a las personas que se desvincularán de la organización, lo antes posible. En caso de despido, el permiso de acceso debería anularse previamente a la notificación de la persona sobre la situación.

Técnicas para la gestión de sesiones.

Para poder establecer una sesión entre una computadora servidor y una computadora cliente, se ha desarrollado un mecanismo de control a través del envío de sesiones mediante al menos dos modalidades. Una por URL y otra mediante Cookies. Según el método elegido, el servidor de esta forma, podrá establecer un proceso de negociación de sesión entre una computadora cliente y el servidor.

Por medio de la URL se pasan las variables o los datos de un punto a otro mediante dos técnicas GET o POST. Si se realiza en forma de GET, los datos se anexan a la dirección que apunta al recurso o si se utiliza POST, los datos se anexan en el encabezado de la solicitud de envío que es dirigida al recurso apuntado. Cuando un cliente se identifica en el servidor, el servidor envía hacia el cliente un código único de identificación y gestión de sesión llamado SID.

Este SID se almacena en el ordenador cliente temporalmente hasta que la abandona el recurso cerrando la sesión en el servidor. El ordenador cliente tan solo guarda este número de identificación.

En el lado del servidor, el número es almacenado junto a otros factores relacionados con las variables de la sesión y otros datos operativos de gestión interna del servidor.

En el caso del uso de cookies en el equipo del cliente se almacena un pequeño archivo que guarda el número SID y otros parámetros relacionados con la expiración, las páginas o recursos dirigidos, etc. Estos últimos parámetros resultan ser opcionales excepto el número SID. A través de este pequeño archivo que genera una cookie, el servidor puede identificar al cliente y puede de esta forma controlar la sesión entre ambas garantizando así la funcionalidad operativa.

El uso de cookies podría estar condicionado debido a que muchos navegadores Web o, bien, no soportan cookies, no los utilizan o no permiten el uso de Cookies.

4.7. Gestión de errores

Técnicas de recuperación de errores.

La principal técnica de recuperación de errores de Java es la excepción. Está compuesto por dos bloques de código más otro opcional:

Bloque try: contiene el código conflictivo.

Bloque catch: contiene el bloque se ejecuta si se dispara la excepción.

Bloque finally: Este bloque se ejecuta siempre.


101

Ejemplo de uso de bloque Try Catch,

Programación de excepciones.

El manejo de excepciones ayuda al programador a crear un mejor código puesto que la cantidad de errores se reduce y se hacen los programas más robustos.

Este manejo está diseñado para procesar errores que ocurren cuando se ejecuta una instrucción.

Algunos ejemplos serían el desbordamiento aritmético, la división entre cero, los parámetros inválidos de método y la asignación fallida en la memoria.

Las excepciones se dividen en verificadas y no verificadas. Este detalle es importante porque el compilador implementa requerimientos de atrapar o declarar para las verificadas lo que hará que se detecten las excepciones automáticamente y de acuerdo al lenguaje de programación utilizado se utilizará un método para corregirlas.

En el caso de las no verificadas se producirá un error indicando que deben atraparse y declararse y es cuando el programador debe pensar en los problemas que pueden ocurrir cuando se llama a un método y definir excepciones para verificarse cuando sean importantes. Las clases de excepciones pueden derivarse de una superclase común, por lo que con un manejador para atrapar objetos de la superclase, también se pueden atrapar todos los objetos de las subclases de esa clase. Pero también, se pueden atrapar a cada uno de los tipos de las subclases de manera individual si estas requieren ser procesadas diferente.

Por ejemplo, las excepciones iniciadas por un método de servicio Web creado mediante ASP.NET se envían de vuelta al cliente en forma de un error de SOAP. Un error de SOAP es un elemento XML Fault incluido en un mensaje SOAP que especifica cuándo se produjo un error. Puede contener detalles tales como la cadena de excepción y el origen de la excepción.

4.8. Transacciones y persistencia

Acceso a bases de datos. Conectores.

ODBC.

Es un estándar de acceso a bases de datos que utilizan los sistemas Microsoft. Las siglas significan Open DataBase Connectivity. A través de ODBC, en un sistema Windows se puede conectar con cualquier base de datos. Bueno habría que decir que permite conectar con cualquier base de datos de la que exista un driver ODBC. Los creadores de las distintas bases de datos son los responsables de crear un driver ODBC para que su base de datos se pueda conectar desde un sistema Microsoft.


102

Para conectar con ODBC una base de datos se ha de crear un DSN, que es un nombre que asociamos a una conexión por ODBC para referirnos a ella desde las aplicaciones o programas que deban conectarse con la base de datos.

Cualquier base de datos que se pretenda utilizar desde aplicaciones Windows debe tener su propio driver ODBC.

Por ejemplo, MySQL dispone de un Driver ODBC que se puede descargar desde su página web. Las bases de datos Access (Microsoft Jet) y SQL Server de Microsoft también tienen su driver ODBC y este ya se encuentra instalado en el Windows de fábrica.

Estamos planteando un sistema de conectividad abierta de bases de datos. Casi todas las DB actuales tienen un ODBC. Debido a que este elemento impone ciertas limitaciones, ya que no todo lo que la DB sabe hacer es compatible con la aplicación, como velocidad de proceso, tiempos de espera, máxima longitud de registro, número máximo de registros, versión de SQL, etc., está cayendo en desuso a cambio de otras técnicas de programación, pero aún le quedan muchos años de buen servicio.

DAO.

La ventaja de usar objetos de acceso a datos es que cualquier objeto de negocio (aquel que contiene detalles específicos de operación o aplicación) no requiere conocimiento directo del destino final de la información que manipula.

Los Objetos de Acceso a Datos pueden usarse en Java para aislar a una aplicación de la tecnología de persistencia Java subyacente(API de Persistencia Java), la cual podría ser JDBC, JDO, EJB,CMP , TopLink, Hibernate), iBATIS, o cualquier otra tecnología de persistencia. Usando Objetos de Acceso de Datos significa que la tecnología subyacente puede ser actualizada o cambiada sin cambiar otras partes de la aplicación.

Estándares para el acceso a bases de datos.

Dependiendo de la base de datos que disponga el producto, la plataforma (Sistema Operativo) sobre la que se ubique su servicio web y el lenguaje de programación que utilice en sus páginas web, tendrá que conectarse al servidor de datos utilizando distinto código.


103

Lenguaje estándar para acceder a una base de datos relacional, estandarizado por el American National Standards Institute (ANSI): SQL-92. En gran parte, los distintos DBMS utilizan todos el mismo SQL, si bien cada vendedor le ha añadido sus propias extensiones. El lenguaje SQL se divide en:

DDL (Data Definition Language), utilizado para crear y modificar la estructura de la base de datos.

Por ejemplo,

CREATE TABLE tab1 (

col1 INTEGER CONSTRAINT pk PRIMARY KEY,

col2 CHAR(25) NOT NULL,

col3 CHAR(10) CONSTRAINT uni1 UNIQUE,

col4 INTEGER,

col5 INT CONSTRAINT fk5 REFERENCES tab2 );.

DML (Data Manipulation Language), empleado para manipular los datos almacenados en la base de datos.

Por ejemplo, consultas con la sentencia SELECT usando una sintaxis del estilo

SELECT [ ALL / DISTINC ] [ * ] / [ListaColumnas_Expresiones] AS [Expresion]

FROM Nombre_Tabla_Vista

WHERE Condiciones

ORDER BY ListaColumnas [ ASC / DESC ]

DCL (Data Control Language), para establecer permisos de acceso (GRANT, REVOKE, DENY) y gestionar transacciones (COMMIT y ROLLBACK).

Gestión de la configuración de acceso a bases de datos.

Para acceder a las bases de datos en Java mediante JDBc existen cuatro clases básicas cada una con una funcionalidad definida:

DriveManager permite cargar el driver o conector que facilita la conectividad con la base de datos.

Connection, establece la conexión con la base de datos.

Statement: permite ejecutar sentencias.

ResultSet: permite trabajar con el resultado devuelto por una sentencia.


104

Acceso a directorios y otras fuentes de datos.

El protocolo ligero de acceso a directorios es un conjunto de protocolos abiertos usados para acceder información guardada centralmente a través de la red. Está basado en el estándar X.500 para compartir directorios, pero es menos complejo e intensivo en el uso de recursos. Por esta razón, a veces se habla de LDAP como "X.500 Lite."

El estándar X.500 es un directorio que contiene información de forma jerárquica y categorizada, que puede incluir nombres, directorios y números telefónicos.

Como X.500, LDAP organiza la información en un modo jerárquico usando directorios. Estos directorios pueden almacenar una gran variedad de información y se pueden incluso usar de forma similar al Servicio de información de red (NIS), permitiendo que cualquiera pueda acceder a su cuenta desde cualquier máquina en la red acreditada con LDAP.

En la mayoría de los casos, LDAP se usa simplemente como un directorio telefónico virtual, permitiendo a los usuarios acceder fácilmente la información de contacto de otros usuarios. LDAP va mucho más lejos que un directorio telefónico tradicional, ya que es capaz de propagar su consulta a otros servidores LDAP por todo el mundo, proporcionando un repositorio de información ad-hoc global.

Cuando una aplicación cliente LDAP se conecta a un servidor LDAP puede, o bien consultar un directorio, o intentar modificarlo. En el evento de una consulta, el servidor, puede contestarla localmente o puede dirigir la consulta a un servidor LDAP que tenga la respuesta. Si la aplicación cliente está intentando modificar información en un directorio LDAP, el servidor verifica que el usuario tiene permiso para efectuar el cambio y después añade o actualiza la información.

La mayor ventaja de LDAP es que se puede consolidar información para toda una organización dentro de un repositorio central.

Por ejemplo, en vez de administrar listas de usuarios para cada grupo dentro de una organización, puede usar LDAP como directorio central, accesible desde cualquier parte de la red. Puesto que LDAP soporta la SSL y la Seguridad de la capa de transporte (TLS), los datos confidenciales se pueden proteger de los curiosos.

LDAP también soporta un número de bases de datos back-end en las que se guardan directorios. Esto permite que los administradores tengan la flexibilidad para desplegar la base de datos más indicada para el tipo de información que el servidor tiene que diseminar. También, ya que LDAP tiene una interfaz de programación de aplicaciones (API) bien definida, el número de aplicaciones acreditadas para LDAP son numerosas y están aumentando en cantidad y calidad.

Programación de transacciones.

Una transacción en un Sistema de Gestión de Bases de Datos (SGBD), es un conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o atómica.

Un SGBD se dice transaccional, si es capaz de mantener la integridad de los datos, haciendo que estas transacciones no puedan finalizar en un estado intermedio. Cuando por alguna causa el sistema debe cancelar la transacción, empieza a deshacer las órdenes ejecutadas hasta dejar la base de datos en su estado inicial (llamado punto de integridad), como si la orden de la transacción nunca se hubiese realizado.


105

Para esto, el lenguaje de consulta de datos SQL (Structured Query Language), provee los mecanismos para especificar que un conjunto de acciones deben constituir una transacción.

BEGIN TRAN .

COMMIT TRAN .

ROLLBACK TRAN

En un sistema ideal, las transacciones deberían garantizar todas las propiedades ACID; en la práctica, a veces alguna de estas propiedades se simplifica o debilita con vistas a obtener un mejor rendimiento.

Un ejemplo de transacción

Un ejemplo habitual de transacción es el traspaso de una cantidad de dinero entre cuentas bancarias. Normalmente se realiza mediante dos operaciones distintas, una en la que se decrementa el saldo de la cuenta origen y otra en la que incrementamos el saldo de la cuenta destino. Para garantizar la atomicidad del sistema (es decir, para que no aparezca o desaparezca dinero), las dos operaciones deben ser atómicas, es decir, el sistema debe garantizar que, bajo cualquier circunstancia (incluso una caída del sistema), el resultado final es que, o bien se han realizado las dos operaciones, o bien no se ha realizado ninguna.

Un ejemplo de transacción con MySql

En cualquier Transacción debemos de tomar en cuenta que es Atómica porque cada consulta es individual, nos garantiza la Consistencia porque se ejecuta todo o no se ejecuta nada, tiene Aislamiento porque no afecta a otras transacciones o consultas que se estén ejecutando paralelamente (si afecta si están anidadas con la transacción actual) y por último es Durable porque una vez que se ha terminado con ella no se perderán los cambios hechos por la misma.

Siempre que diseñemos una Transacción debemos tener presente las características ACID ya que nos sientan las bases para que nuestras Transacciones no posean errores lógicos y por lo tanto tengamos problemas más adelante con las mismas.

Transacciones en MySQL.


106

Para poder utilizar una Transacción en MySQL nuestras tablas deben estar usando el motor InnoDB ya que este nos permite integridad referencial y otras muchas cosas, en mi opinión personal el motor InnoDB nos permite tener una BD seria y profesional, aunque MyISAM es mucho más rápido pero no nos garantiza la integridad así que depende de cada persona que motor usar, pero si queremos usar Transacciones vamos a tener que usar InnoDB.

Ejemplo de creación de una base de datos y dos tablas dentro de ella.

4.9. Componentes en servidor. Ventajas e inconvenientes en el uso de contenedores de componentes

Estas acciones pueden ser por ejemplo, el envío de correo electrónico, realizar upload de ficheros al servidor (subida de archivos), conectar con una base de datos, etc.

ASP es el lenguaje con el que se escribe (VBScript o Jscript) ofreciendo unas funcionalidades básicas en cualquier lenguaje:

Trabajo con variables de diverso tipo.

Estructuras de control.

Un juego de funciones (que en el caso de VBScript es bastante limitado).

Así que, si en una página ASP estamos pensando en hacer algo un poco complejo, lo más seguro es que lo tengamos que realizar a través de algún componente del servidor. Incluso las conexiones y accesos a bases de datos que muchos de vosotros realizaréis habitualmente se hacen a través de un componente del servidor.

Para hablar sobre los componentes de servidor es necesario hablar también de la tecnología ActiveX de Microsoft. Ésta se trata de un conjunto de tecnologías independientes del lenguaje de programación orientadas a posibilitar que trabajen entre si los distintos componentes en entornos de red.


107

Los componentes ActiveX no son otra cosa que los componentes de servidor que estamos comentando. Por otra parte, están los controles ActiveX (controles esta vez, no componentes) que son pequeños programas que se insertan en las páginas web a través de las etiquetas <OBJECT> y <PARAM>. Los controles se ponen en marcha en el cliente, cuando se ejecutan lo hacen dentro de la página web. Un ejemplo típico es la invocación de una animación de Flash o Shockwave. El motor de Flash o Shockwave, es un control ActiveX. Por otra parte y como decíamos, los componentes ActiveX se ponen en marcha en el servidor.

Los componentes ActiveX, por tanto, son los que nos interesan a nosotros en este artículo, pues son los que se invocan desde ASP y se ejecutan en el servidor al mismo tiempo que la página, antes de enviarla al cliente.

Para crear componentes de servidor se puede utilizar cualquier lenguaje de programación. Aunque muy habitualmente se hacen en Visual Basic, se pueden hacer también en Delphi, Visual C++ o el propio C++ por ejemplo. Para su programación es necesario que se sigan unas normas y estructuras.

Los componentes son objetos que, como objetos que son, tienen propiedades y métodos. Las propiedades son las características del objeto y los métodos son sus funcionalidades. Para trabajar con un componente primero debemos instanciarlo (crearlo e inicializarlo). Una vez creado, habitualmente, lo configuraremos accediendo a sus propiedades y actualizando sus valores. Finalmente llamaremos a sus métodos para poner en marcha sus funcionalidades.

Además del envío de correo electrónico por el servidor o subir archivos al servidor también son un ejemplo de uso de esta aplicación el acceso al sistema de archivos del servidor y la creación de imágenes en el servidor.

Algunos de los componentes que necesitamos en la programación de páginas ASP están ya instalados por defecto en los servidores web, es el caso del componente de conexión con la base de datos o el de conexión con el sistema de archivos del servidor. Sin embargo, otros componentes sí que necesitaremos instalarlos en la máquina que vaya a utilizarlos.

Un componente suele ser un archivo .dll, -librería de Windows- y para instalarla en nuestro sistema deberemos seguir sus instrucciones de instalación. Tanto las instrucciones de instalación como las de manejo del componente deberían acompañar a la dll entre los archivos de descarga del componente.


108

Es habitual que la instalación de esa dll se realice manualmente. Para ello copiaremos el archivo .dll en nuestro directorio system (\winnt\system32 en NT o \windows\system en Win95) y luego registraremos la dll en nuestro sistema con el comando regsvr32 mi_componente.dll, que debemos ejecutar desde línea de comandos (C:\>).

En algunos casos, el componente se instala en Windows igual que cualquier otra aplicación. Como decíamos, cada componente puede instalarse de manera diferente.

Si tenemos alojada la página en un servidor que no es nuestro, en un servidor de hosting, es importante que preguntemos al soporte técnico de ese proveedor la manera de instalar los componentes.

4.10. Modelos de desarrollo. El modelo vista controlador

Modelo: programación de acceso a datos.

El modelo vista controlador (MVC) propone la construcción de tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado define componentes para la representación de la información, y por otro lado para la interacción del usuario. Este patrón de diseño se basa en las ideas de reutilización de código y la separación de conceptos, características que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento.

De manera genérica, los componentes de MVC se podrían definir como sigue:

El Modelo: Envía a la 'vista' aquella parte de la información que en cada momento se le solicita para que sea mostrada (típicamente a un usuario).

El Controlador: Responde a eventos (usualmente acciones del usuario) e invoca peticiones al 'modelo' cuando se hace alguna solicitud sobre la información (por ejemplo, editar un documento o un registro en una base de datos). También puede enviar comandos a su 'vista' asociada si se solicita un cambio en la forma en que se presenta de 'modelo' (por ejemplo, desplazamiento o scroll por un documento o por los diferentes registros de una base de datos), por tanto se podría decir que el 'controlador' hace de intermediario entre la 'vista' y el 'modelo'

La Vista: Presenta el 'modelo' (información y lógica de negocio) en un formato adecuado para interactuar (usualmente la interfaz de usuario) por tanto requiere de dicho 'modelo' la información que debe representar como salida.


109

Los objetos del modelo son las partes de la aplicación que implementan la lógica del dominio, también conocida como la lógica comercial. La lógica del dominio administra los datos que se pasan entre la base de datos y la interfaz de usuario.

Por ejemplo, en un sistema de inventario, el modelo lleva un seguimiento de los elementos en almacenamiento y la lógica para determinar si un artículo está en inventario. Además, el modelo formaría parte de la aplicación que actualiza la base de datos cuando un artículo se vende y distribuye fuera del almacén. A menudo, el modelo también almacena y recupera el estado modelo en una base de datos.

Vista: Desarrollo de aplicaciones en cliente. Eventos e interfaz de usuario.

Una plantilla es un fichero de texto con la información necesaria para generar documentos en cualquier formato de texto (HTML, XML, CSV, LaTeX, JSON, etcétera). Cualquier tipo de plantilla consiste en un documento con el formato que se quiere generar, y con variables expresadas en el lenguaje propio de la plantilla y que representas a los valores que son calculados dinámicamente por la aplicación.

Por ejemplo, cuando desarrollamos aplicaciones web con PHP, la forma más sencilla de implementar plantillas es usando el propio PHP como lenguaje de plantillas.

Esencialmente no es más que un trozo de documento HTML donde la información dinámica se obtiene procesando código PHP. La característica principal de este código PHP es que debe ser escueto y corto. De manera que no “contamine” la estructura del HTML. Por ello cada instrucción PHP comienza y termina en la misma línea.

Es muy habitual la utilización de bucles foreach - endforeach para recorrer arrays de datos, así como los bloques condicionales if - endif para pintar bloques según determinadas condiciones.

En el ejemplo anterior hemos generado el código HTML de una tabla que puede tener un número variable de filas. Se recoge en la plantilla el parámetro alimentos, que es un array con datos de alimentos, y se genera una fila por cada elemento del array con información de la URL de una página sobre el alimento (línea 9), y su nombre, energía y grasa total (líneas 10-14).

Es interesante también ver la forma de construir el bucle foreach que se abre en la línea 7 y se cierra en la 16. Lo particular de la sintaxis de este tipo de bucle para plantillas es que la instrucción foreach que lo abre terminan con el carácter: Y la necesidad de cerrarlo con un <?php endforeach; ?>.


110

Programación del controlador.

Por lo general, todos los scripts de una aplicación realizan una serie de tareas que son comunes.

Por ejemplo, interpretar y manipular la request, comprobar las credenciales de seguridad y cargar la configuración.

Gran parte del código generado puede ser compartido entre los scripts. Para ello podemos utilizar el mecanismo de inclusión de ficheros de PHP.

Muchos programadores se preguntan, ¿qué ocurre si en un momento dado, cuando ya tengamos escrito mucho código, queremos añadir a todas las páginas de la aplicación una nueva característica que requiere, por ejemplo, el uso de una nueva librería? Tenemos, entonces, que añadir dicha modificación a todos los scripts PHP de la aplicación. Lo cual supone una degradación en el aumentando las probabilidades de fallos una vez que el cambio se haya realizado.

Otro problema que ocurre con esta estrategia es que si se solicita una página que no tiene ningún script PHP asociado, el servidor arrojará un error (404 Not Found) cuyo aspecto no podemos controlar dentro de la propia aplicación (es decir, sin tocar la configuración del servidor web).

Una solución sería utilizar un solo código que se encargue de procesar todas las peticiones. A este único script de entrada se le conoce como controlador frontal.

El controlador frontal, en función de los parámetros que lleguen en la query string determinará qué acciones debe realizar para construir la página solicitada.

Por ejemplo en,

http://tu.servidor/index.php?accion=hola, la query string sería ?accion=hola.

Query string, en español puede definirse como una cadena de consulta. Este término generalmente se utiliza para hacer referencia a una interacción con una base de datos. En muchas ocasiones se simplificando diciendo que es la parte de una URL que contiene los datos que deben pasar a aplicaciones web.

Por ejemplo,

www.sitiodeejemplo.net/paginaprincipal/paginasecundaria/contenido.html

En los comienzos de la web las direcciones de las páginas contenían la estructura jerárquica de los directorios del sitio. Estos sitios eran estáticos: a menos que el administrador modifique las páginas siempre mostrarían el mismo contenido a los visitantes.

Más tarde aparecieron los sitios dinámicos. En este caso, el servidor crea automáticamente la página cuando el navegante la solicita. Para ello se vale de una serie de parámetros o datos que se incluyen en la URL. Éstos normalmente están compuestos por un nombre y un valor separados por el signo igual.

El ejemplo quedaría así,

www.sitiodeejemplo.net/pagina.php?nombredevalor1=valor1&nombredevalor2=valor2


111

4.11. Documentación del software. Inclusión en código fuente. Generadores de documentación

En el caso de programas pequeños y poco importantes que sólo se utilizan durante un corto periodo de tiempo unos cuantos comentarios en el código podrían ser suficientes. Sin embargo, la mayoría de los programas cuya única documentación es el código se quedan obsoletos rápidamente y es imposible realizar un mantenimiento profesional. La dedicación de esfuerzo a la documentación recibirá en el futuro recompensas incluso dentro de los límites de un pequeño proyecto.

No documentar todas las decisiones ocasionará que se repitan los mismos errores.

La falta de documentación no sólo genera trabajo adicional sino que también tiende a dañar la calidad del código.

Si no se posee una nítida caracterización del problema es imposible desarrollar una solución clara.

Aprender a documentar software es una tarea complicada y exige un criterio de ingeniería maduro.

Documentar de forma concisa es un error habitual, pero el otro extremo puede resultar igual de perjudicial: si se escriben documentaciones extensas se corre el riesgo de atosigar al futuro lector y constituirá una carga a la hora de la conservación o actualización del software. Es esencial documentar sólo los asuntos correctos.

La documentación no sirve de ayuda para nadie si su extensión desanima a la gente a la hora de leerla.

Existe la tentación de centrar los esfuerzos en temas sencillos ya que éstos suelen resultan más fáciles de documentar. Para muchos autores esto es un error. Hay que dedicar esfuerzo en documentar los elementos complejos.

Otro tema espinoso es cuándo documentar. Aunque algunas veces es conveniente posponer la tarea de la documentación mientras se realizan experimentos, los programadores con experiencia suelen documentar de forma metódica incluso el código provisional, los análisis de un problema inicial y los borradores de un diseño. Ellos creen que esto hace que la experimentación sea más productiva. Además, dado que han tomado la documentación como hábito, les resulta normal documentar a medida que van avanzando.

Ejemplos de documentación en diferentes lenguajes de programación

1.- Ensamblador.

;comentario

2.- Java.

//comentario de línea

/*comentario

de bloque*/

3.- C/C++

//comentario en línea

/* comentario

en bloque*/


112

4.- Delphi


{ comentario

en bloque }

(* comentario

en bloque *)

En delphi se pueden anidar comentarios de bloque siempre que no usen el mismo delimitador.

(*

comentario en bloque

{

que contiene otros

comentarios en bloque

}

// o de fin de línea

y que es perfectamente

válido

*)

5.- Ruby

#comentario

=begin

comentario de bloque

=end

6.- Python

#comentario

7.- Perl

#comentario

113

8.- Javascript

En archivo.js pueden darse las siguientes formas:


/* comentario

en bloque */

9.- HTML

En las páginas webs .html se introduce el comentario entre





10.- SQL

//esto es un comentario

--este también

/* y este

en bloque */

11.- Visual Basic

'comentario

'''comentario XML

12.- PHP


#este también

/* comentario

en bloque */

13.- Cobol

* Comentario


114

Recuerda…

Siempre se debe posponerse la tarea de la documentación mientras se realizan experimentos.

La sentencia If no evalúa una condición expresada entre paréntesis corchetes [].

Perl es un lenguaje de propósito general.

La Gestión de la seguridad es como se denomina a la protección de la infraestructura computacional y todo lo relacionado con ésta.

Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I

Si establecemos una separación entre la capa de interfaz gráfica y la capa modelo no perderíamos las ventajas de los proyectos por capas.

Un lenguaje del lado del servidor es aquel que se ejecuta en el servidor web, justo antes de que se envíe la página a través de Internet al cliente.

La interoperabilidad se consigue mediante la adopción de los llamados estándares abiertos.

En un Sistema de Gestión de Bases de Datos (SGBD) la Transición es el conjunto de órdenes que se ejecutan formando una unidad de trabajo.

Las herramientas CASE tienen la ventaja de disponer módulos de análisis y diseño más amplios que la mayoría de las herramientas de red.

desarrollo de aplicaciones web en el entorno servidor

Technology