viernes, 13 de julio de 2012

Artefactos y Documentación


   La documentación es la debilidad más frecuente en productos e instalaciones informáticos. Los actores que intervienen en el ciclo de vida del software desempeñan diversos roles. Arquitectos, diseñadores, analistas, programadores, implementadores, administradores o auditores son quienes explicitan distintos aspectos de los productos y procesos.


   El código fuente del software, la estructura de datos y los enlaces de comunicaciones constituyen en conjunto el paradigma de la documentación informática. Sin embargo, cuando los modelos de arquitectura, estructuras y especificaciones de diseño no los vinculan, sólo pueden acceder a éstos dificultosamente los iniciados. Hay buenas prácticas para escribir código fuente pero, las condiciones y circunstancias de cada programa y sistema son tan diversas que, las exigencias habituales se reducen a que funcione razonablemente.

   Artefactos

   Artefactos, de acuerdo con RUP, es una pieza de información producida, modificada o utilizada por un proceso. Artefacto son los productos tangibles del proyecto, las cosas que los proyectos producen o utilizan mientras se trabaja hacia el producto final. Los artefactos son insumos utilizados para realizar actividades y, son los resultados de estas actividades.

   Son artefactos entregables como ejecutables, el código fuente, manuales, planes y proyectos. Productos intermedios, como documentos de arquitectura y diseño, especificaciones de requerimientos, modelos de negocios y casos de uso. De igual forma, son artefactos los elementos que componen los modelos y productos, como glosarios y diccionarios, gráficos, clases o subsistemas. También, en negocios regulados, son artefactos los instrumentos y evidencias de la gestión informática.

   Requisitos y Herramientas


   Los requerimientos con sus especificaciones permiten diseñar y elaborar el software, proveen las glosas, términos, conceptos y definiciones necesarios para elaborar todo tipo de manuales y guías de uso del software. Cuando los requerimientos funcionales tienen marcos legales con requisitos específicos, como en los casos de entidades financieras, empresas que cotizan en bolsa o que manipulan datos personales es necesario además, documentar la gestión del software y, la operación de los sistemas y las instalaciones.

   Herramientas automatizadas para la administración de requerimientos, el modelado del negocios, y las plataformas de desarrollo proporcionan gran parte de la documentación de las estructuras y especificaciones de diseño para articular, mediante referencias y trazabilidad, los casos de uso, con los componentes del software y sus programas fuentes.

    Toda regulación de la operación informática requiere de resguardar datos y configuración, los llamados “back-up”, también la identificación del acceso a la información. Además, la regulación actual requiere evidencias de las modificaciones al software y su configuración, y registros de los incidentes ocurridos en la operación y gestión del software.

  Hay herramientas automatizadas para proporcionar estas evidencias, los sistemas de seguridad, de recuperación de datos ante contingencias, de control de cambios, despliegue de programas y configuración, y de seguimiento de incidentes (suelen utilizarse al menos dos sistemas de incidentes, uno para los del negocio y otro para los de operaciones e instalaciones).

Fundamentos del enfoque Orientado a Objetos

   El paradigma orientado a objetos se basa en el concepto de objeto. Un objeto es aquello que tiene estado (propiedades más valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los demás objetos). La estructura y comportamiento de objetos similares están definidos en su clase común; los términos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento común.


   La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstracción, la "esencia" de un objeto, tal como son. De aquí que un objeto no es una clase, sin embargo, una clase puede ser un objeto.



   En el enfoque Orientado a Objetos, las propiedades del objeto son claves. Los principios del modelo OO son: abstracción, encapsulación, modularidad y jerarquía, fundamentalmente, y en menor grado tipificación (typing), concurrencia, persistencia. [Booch 1986] dice que si un modelo que se dice OO no contiene alguno de los primeros cuatro elementos, entonces no es OO.

   Abstracción. Es una descripción simplificada o especificación de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros.

  Encapsulación. En el proceso de ocultar todos los detalles de un objetoque no contribuyen a sus características esenciales.

   Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes.

    Jerarquía o herencia. Es el orden de las abstracciones organizado por niveles.

   Tipificación. Es la definición precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida.

   Concurrencia. Es la propiedad que distingue un objeto que está activo de uno que no lo está.

   Persistencia. Es la propiedad de un objeto a través de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo después de que su creador ha dejado de existir) y/o el espacio (es decir, la localización del objeto se mueve del espacio de dirección en que fue creado).


Características de la POO.



   Existe un acuerdo acerca de qué características contempla la "orientación a objetos", las características siguientes son las más importantes:


   Abstracción: Denota las características esenciales de un objeto, donde se capturan sus comportamientos. Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción. El proceso de abstracción permite seleccionar las características relevantes dentro de un conjunto e identificar comportamientos comunes para definir nuevos tipos de entidades en el mundo real. La abstracción es clave en el proceso de análisis y diseño orientado a objetos, ya que mediante ella podemos llegar a armar un conjunto de clases que permitan modelar la realidad o el problema que se quiere atacar.

   Por ejemplo, volvamos al ejemplo de los automóviles, ¿Qué características podemos abstraer de los automóviles? O lo que es lo mismo ¿Qué características semejantes tienen todos los automóviles? Todos tendrán una marca, un modelo, número de chasis, peso, llantas, puertas, ventanas, etc. Y en cuanto a su comportamiento todos los automóviles podrán acelerar, frenar, retroceder, entre otros

   En los lenguajes de programación orientada a objetos, el concepto de Clase es la representación y el mecanismo por el cual se gestionan las abstracciones.
Por ejemplo, en Java tenemos:

public class Automovil {
// variables
// métodos
}

   Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente, el encapsulamiento consiste en unir en la Clase las características y comportamientos, esto es, las variables y métodos. Es tener todo esto es una sola entidad. En los lenguajes estructurados esto era imposible. Es evidente que el encapsulamiento se logra gracias a la abstracción y el ocultamiento que veremos a continuación.

    La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, ya que tendremos a las Clases como cajas negras donde sólo se conoce el comportamiento pero no los detalles internos, y esto es conveniente porque nos interesará será conocer qué hace la Clase pero no será necesario saber cómo lo hace.

    Modularidad: Se denomina Modularidad a la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes. Estos módulos que se puedan compilar por separado, pero que tienen conexiones con otros módulos. Al igual que la encapsulación, los lenguajes soportan la Modularidad de diversas formas.

     Principio de ocultación.

    Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que específica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos.

     Es la capacidad de ocultar los detalles internos del comportamiento de una Clase y exponer sólo los detalles que sean necesarios para el resto del sistema.

    El ocultamiento permite 2 cosas: restringir y controlar el uso de la Clase. Restringir porque habrá cierto comportamiento privado de la Clase que no podrá ser accedido por otras Clases. Y controlar porque daremos ciertos mecanismos para modificar el estado de nuestra Clase y es en estos mecanismos dónde se validarán que algunas condiciones se cumplan. En Java el ocultamiento se logra usando las palabras reservadas: public, private y protected delante de las variables y métodos.

   Polimorfismo: Comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación" de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.

   Herencia: Las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple.

     La herencia es uno de los conceptos más cruciales en la POO. La herencia básicamente consiste en que una clase puede heredar sus variables y métodos a varias subclases (la clase que hereda es llamada superclase o clase padre). Esto significa que una subclase, aparte de los atributos y métodos propios, tiene incorporados los atributos y métodos heredados de la superclase. De esta manera se crea una jerarquía de herencia.

    Por ejemplo, imaginemos que estamos haciendo el análisis de un Sistema para una tienda que vende y repara equipos celulares.

     En el gráfico vemos 2 Clases más que posiblemente necesitemos para crear nuestro Sistema. Esas 2 Clases nuevas se construirán a partir de la Clase Celular existente. De esa forma utilizamos el comportamiento de la SuperClase.

        Recolección de basura


       La recolección de basura o garbage collector es la técnica por la cual el entorno de objetos se encarga de destruir automáticamente, y por tanto desvincular la memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el programador no debe preocuparse por la asignación o liberación de memoria, ya que el entorno la asignará al crear un nuevo objeto y la liberará cuando nadie lo esté usando. En la mayoría de los lenguajes híbridos que se extendieron para soportar el Paradigma de Programación Orientada a Objetos como C++ u Object Pascal, esta característica no existe y la memoria debe desasignarse manualmente.

Componentes de la POO

    Un componente es una clase de uso específico, lista para usar, que puede ser configurada o utilizada de forma visual, desde el entorno de desarrollo.


     La principal diferencia, respecto a una clase normal, es que la mayor parte del trabajo lo podemos hacer de forma visual, con el ratón y ajustando las opciones que se nos ofrece en nuestro entorno.


   En la programación orientada a objetos, debemos codificar una serie de operaciones, más o menos laboriosas, para preparar los objetos para su uso. Programar estas operaciones requiere su tiempo, su complejidad y pueden ser origen de errores. Si embargo, en la programación basada en componentes, todas estas operaciones las realizamos de forma visual, para así poder dedicar la atención a nuestro problema.

      Tipos de componentes:

   Aunque hay muchos tipos, podemos diferenciar claramente dos grupos: “Visuales” y “No visuales” 

    Los componentes visuales son aquellos que, al utilizarlos, muestran algún elemento (o dibujo) en la pantalla y es el usuario de nuestros programas el que interactúa con él. El componente es el principal responsable de dibujar en la pantalla lo que sea oportuno, dependiendo de su estado, del valor de sus atributos, etc. Hay muchos componentes de este tipo, como pueden ser los botones (TButton), etiquetas de texto (TLabel), formas (TShape), etc.

     Los componentes no visuales son aquellos que no aparecen en la ventana, y se insertan en un formulario para que el programador los utilice. Son más fáciles de programar que los componentes visuales, ya que no tienen ningún tipo de interfaz gráfico. Ejemplos de componentes no visuales podrían ser un temporizador (TTimer), una tabla (TTable) o una conexión a base de datos (TConnection, TSQLConnection, etc.).

        Propiedades, eventos, métodos y atributos de los componentes

      Las propiedades son datos públicos del componente, muy parecidas a los atributos de una clase, aunque se accede a ellas a través de dos métodos: un método para leer su valor, y otro para modificarlo. Existen propiedades de sólo lectura, en las que podemos consultar pero no modificar su valor, y propiedades de sólo escritura. Por ejemplo, las propiedades “Alto” (Width) y “Ancho” (Height) de un botón permiten que un programador pueda cambiar las dimensiones del componente. Cuando el programador cambia alguna de ellas, el componente debe redibujarse en la pantalla, para mostrar los nuevos cambios. 

    Los eventos son funciones del componente, que se ejecutarán automáticamente cuando ocurra “algo importante”. Un programador puede poner el código que quiera en el evento, para así poder hacer una acción cuando ese “algo importante” ocurra. 

      Los métodos son funciones, que permiten realizar acciones. Normalmente, se utilizan métodos para dos tareas distintas: realizar algo importante (como repintar en pantalla, cambiar el foco o algo así), o para establecer el valor de los atributos internos, haciendo algún tipo de comprobación previa. Como las propiedades pueden ser leídas o escritas a través de métodos, a veces es equivalente la llamada a un método y el cambio de una propiedad. 

Proceso de desarrollo de Software

   Un proceso define quien esta haciendo que, cuando, y como alcanzar un determinado objetivo. En la Ingeniería del software el objetivo es construir un producto software o mejorar uno existente. Un proceso efectivo proporciona normas para el desarrollo eficiente de software de calidad. Captura y presenta las mejores practicas que el estado actual de la tecnología permite. En consecuencia, reduce el riesgo y hace el proyecto mas predecible. El efecto global es el fomento de una visión y una cultura comunes.

   Es necesario un proceso que sirva como guia para todos los participantes clientes, usuarios, desarrolladores y directivos ejecutivos. No nos sirve ningún proceso antiguo; necesitamos uno que sea el mejor proceso que la industria pueda reunir en este punto de su historia. Por ultimo necesitamos un proceso que este ampliamente disponible de forma que todos los interesados puedan comprender su papel en el desarrollo en el que se encuentran implicados.



   Un proceso de desarrollo de software debería también ser capaz de evolucionar durante muchos años. Durante esta evolución debería limitar su alcance, en un momento del tiempo dado, a las realidades que permitan las tecnologías, herramientas, personas y patrones de organización.
  1. Tecnologías: 
    El proceso debe construirse sobre las tecnologías, lenguajes de programación, sistemas operativos computadores, estructuras de red, entornos de desarrollo, entre otros disponibles en el momento en que se va a emplear el proceso. Por ejemplo hace varios años el modelado visual no era realmente de uso general. Era demasiado caro. En aquellos tiempos, un creador de un proceso prácticamente tenia que asumir que se usarían diagramas hechos a mano. Esa suposición limitaba mucho el grado en el cual el creador del proceso podía establecer el modelado dentro del proceso.
  1. Herramientas:
     Los procesos y las herramientas deben desarrollarse en paralelo. Las herramientas son esenciales en el proceso. Dicho de otra forma, un proceso ampliamente utilizado para soportar la inversión necesaria para crear las herramientas que lo soporten.
  1. Personas:
     Un creador del proceso debe limitar el conjunto de habilidades necesarias para trabajar en el proceso a las habilidades que los desarrolladores actuales poseen, o apuntar aquellas que los desarrolladores puedan obtener rápidamente. Hoy es posible empotrar las herramientas software técnicas que antes requieran amplios conocimientos, como la comprobación de la consistencia en los diagramas del modelo.
  1. Patrones de Organización:
     Aunque los desarrolladores de software no pueden ser expertos tan independientes como los músicos de una orquestas, están muy lejos de los trabajadores automatas en los cuales Frederick W. Taylor baso su “Direccion Cientifica” hace cien años. El creador del proceso debe adoptar el proceso a las realidades del momento hechos como mezcla(en empresas pequeñas recien montadas) de socios de la empresa, empleados asalariados, trabajadores de obra y subcontratados y la prolongada escacez de desarrolladores de software.
Los ingenieros del proceso deben equilibrar estos cuatro conjuntos de circunstancias. Ademas el equilibrio debe estar presente no solo ahora, sino también en el futuro. El creador del proceso debe diseñar el proceso de forma que pueda evolucionar, de igual forma que el desarrollador de software intenta desarrollar un sistema que no solo funciona este año, sino que evoluciona con éxito en los años venideros. Un proceso debe madurar durante varios años antes de productos comerciales manteniendo a la vez un nivel razonable de riesgo de utilización.