Trabajo de Metodología

El desarrollo rápido de aplicaciones o RAD (acrónimo en inglés de rapid application development) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo interactivo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.

Hoy en día se suele utilizar para referirnos al desarrollo rápido de interfaces gráficas de usuario tales como Glade, o entornos de desarrollo integrado completos. Algunas de las plataformas más conocidas son Visual Studio, Lazarus, Delphi,Foxpro , Anjuta, Game Maker, Velneo o Clarion. En el área de la autoría multimedia, software como Neosoft Neoboo y MediaChance Multimedia Builder proveen plataformas de desarrollo rápido de aplicaciones, dentro de ciertos límites.

Comenzando con las ideas de Barry Boehm y Scott Shultz, Martin desarrolló el Rapid Application Development durante los años 1980 en IBM y finalmente lo formalizó publicando un libro en 1990

La metodología de desarrollo conocida como diseño rápido de aplicaciones RAD (por sus siglas en inglés) ha tomado gran auge debido a la necesidad que tienen las instituciones de crear aplicaciones funcionales en un plazo de tiempo corto. Esta modalidad de desarrollo consiste de diferentes etapas que suceden de forma paralela y exigen la colaboración de los usuarios en todos los niveles. Por el contrario, en la metodología de diseño tradicional, las etapas suceden de forma lineal y el usuario es excluido del proceso, lo que hace que esta modalidad sea más lenta y poco eficiente. Hoy día la competencia en el mercado demanda calidad lo más pronto posible y RAD se enfoca en estas características.

LA METODOLOGÍA DE DISEÑO RÁPIDO DE APLICACIONES

La metodología conocida como diseño rápido de aplicaciones (RAD según sus siglas en inglés) ha tenido mucho auge recientemente en el mundo de la informática. Esta metodología propone un proceso de desarrollo de "software" que permite que se creen sistemas de computadoras utilizables en un periodo de tiempo entre 60 a 90 días. RAD es un ciclo de desarrollo diseñado para crear aplicaciones de computadoras de alta calidad de las que acontecen en corporaciones grandes.
El desarrollo de aplicaciones enfrenta una transformación fundamental. Hace cinco años un proyecto para desarrollar una...

Introducción al RUP

Las siglas RUP en ingles significa

Rational Unified Process

(ProcesoUnificado de Rational) es un producto del proceso de ingeniería de

software

queproporciona un enfoque disciplinado para asignar tareas y responsabilidadesdentro de una organización del desarrollo. Su meta es asegurar la produccióndel

software

de alta calidad que resuelve las necesidades de los usuariosdentro de un presupuesto y tiempo establecidos

El RUP tiene dos dimensiones:

•

El eje horizontal representa tiempo y demuestra los aspectos del ciclo devida del proceso.

•

El eje vertical representa las disciplinas, que agrupan actividadesdefinidas lógicamente por la naturaleza.La primera dimensión representa el aspecto dinámico del proceso y seexpresa en términos de fases, de iteraciones, y la finalización de las fases. Lasegunda dimensión representa el aspecto estático del proceso: cómo sedescribe en términos de componentes de proceso, las disciplinas, lasactividades, los flujos de trabajo, los artefactos, y los roles.

En la figura 1 se puede observar como varía el énfasis de cada disciplinaen un cierto plazo en el tiempo, y durante cada una de las fases. Por ejemplo,en iteraciones tempranas, pasamos más tiempo en requerimientos, y en lasúltimas iteraciones pasamos más tiempo en poner en práctica la realización delproyecto en si.

Figura 1. Disciplinas, fases, iteraciones del RUP

Se puede hacer mención de las tres características esenciales quedefinen al RUP:

Proceso Dirigido por los Casos de Uso: Con esto se refiere a la utilizaciónde los Casos de Uso para el desenvolvimiento y desarrollo de lasdisciplinas con los artefactos, roles y actividades necesarias. Los Casos deUso son la base para la implementación de las fases y disciplinas del RUP.Un Caso de Uso es una secuencia de pasos a seguir para la realización deun fin o propósito, y se relaciona directamente con los requerimientos, yaque un Caso de Uso es la secuencia de pasos que conlleva la realización eimplementación de un Requerimiento planteado por el Cliente.

•

Proceso Iterativo e Incremental: Es el modelo utilizado por RUP para eldesarrollo de un proyecto de

software

. Este modelo plantea laimplementación del proyecto a realizar en Iteraciones, con lo cual sepueden definir objetivos por cumplir en cada iteración y así poder ircompletando todo el proyecto iteración por iteración, con lo cual se tienenvarias ventajas, entre ellas se puede mencionar la de tener pequeñosavances del proyectos que son entregables al cliente el cual puede probarmientras se esta desarrollando otra iteración del proyecto, con lo cual elproyecto va creciendo hasta completarlo en su totalidad. Este proceso seexplica mas adelante a detalle.

•

Proceso Centrado en la Arquitectura: Define la Arquitectura de un sistema,y una arquitectura ejecutable construida como un prototipo evolutivo.Arquitectura de un sistema es la organización o estructura de sus partesmás relevantes. Una arquitectura ejecutable es una implementación parcialdel sistema, construida para demostrar algunas funciones y propiedades.RUP establece refinamientos sucesivos de una arquitectura ejecutable,construida como un prototipo evolutivo.

FasesFigura 2. Fases del RUP

El ciclo de vida del

software

del RUP se descompone en cuatro fasessecuenciales (figura 2). En cada extremo de una fase se realiza una evaluación(actividad: Revisión del ciclo de vida de la finalización de fase) para determinarsi los objetivos de la fase se han cumplido. Una evaluación satisfactoria permiteque el proyecto se mueva a la próxima fase.

1.1.2.1. Planeando las fases

El ciclo de vida consiste en una serie de ciclos, cada uno de los cualesproduce una nueva versión del producto, cada ciclo está compuesto por fases ycada una de estas fases está compuesta por un número de iteraciones, estasfases son:1. Concepción, Inicio o Estudio de oportunidad



Define el ámbito y objetivos del proyecto



Se define la funcionalidad y capacidades del producto

Elaboración



Tanto la funcionalidad como el dominio del problema se estudian enprofundidad



Se define una arquitectura básica



Se planifica el proyecto considerando recursos disponibles3. Construcción



El producto se desarrolla a través de iteraciones donde cada iteracióninvolucra tareas de análisis, diseño e implementación



Las fases de estudio y análisis sólo dieron una arquitectura básica quees aquí refinada de manera incremental conforme se construye (sepermiten cambios en la estructura)



Gran parte del trabajo es programación y pruebas



Se documenta tanto el sistema construido como el manejo del mismo



Esta fase proporciona un producto construido junto con ladocumentación4. Transición



Se libera el producto y se entrega al usuario para un uso real



Se incluyen tareas de

marketing

, empaquetado atractivo, instalación,configuración, entrenamiento, soporte, mantenimiento, etc.



Los manuales de usuario se completan y refinan con la informaciónanterior



Estas tareas se realizan también en iteracionesTodas las fases no son idénticas en términos de tiempo y esfuerzo.Aunque esto varía considerablemente dependiendo del proyecto, un ciclo dedesarrollo inicial típico para un proyecto de tamaño mediano debe anticipar ladistribución siguiente el esfuerzo y horario:

En un ciclo evolutivo, las fases de concepción y elaboración seríanconsiderablemente más pequeñas. Algunas herramientas que puedenautomatizar una cierta porción del esfuerzo de la fase de Construcción puedenatenuar esto, haciendo que la fase de construcción sea mucho más pequeñaque las fases de concepción y elaboración juntas. Este es precisamente elobjetivo del trabajo.Cada paso con las cuatro fases produce una generación del

software

. Amenos que el producto "muera", se desarrollará nuevamente repitiendo lamisma secuencia las fases de concepción, elaboración, construcción ytransición, pero con diversos énfasis cada fase.

Estos ciclos subsecuentes se llaman los ciclos de la evolución. Mientrasque el producto pasa durante varios ciclos, se producen las nuevasgeneraciones. En la figura 4 se muestre este ciclo evolutivo.

Los ciclos evolutivos pueden ser iniciados por las mejoras sugeridas porel usuario, cambios en el contexto del usuario, cambios en la tecnologíasubyacente, reacción a la competición, etcétera. Los ciclos evolutivos tienentípicamente fases de concepción y elaboración mucho más cortas, puesto quela definición y la arquitectura básicas del producto son determinadas por losciclos de desarrollo anteriores. Las excepciones a esta regla son los ciclosevolutivos en los cuales ocurre o surge un producto significativo o unaredefinición arquitectónica.

Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.

Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas: Scrum de Scrums

Características de Scrum

Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores.

Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint.[2] Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.

Scrum permite la creación de equipos autoorganizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.

Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.

Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.

Roles en Scrum

Roles Principales

Product Owner

El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.

ScrumMaster (o Facilitador)

El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.

Equipo de desarrollo

El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc).

Roles Auxiliares

Los roles auxiliares en los "equipos Scrum" son aquellos que no tienen un rol formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint.

Stakeholders (Clientes, Proveedores, Vendedores, etc)

Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su producción. Sólo participan directamente durante las revisiones del sprint.

Administradores (Managers)

Es la gente que establece el ambiente para el desarrollo del producto.

Reuniones en Scrum

Daily Scrum

Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily standup". El scrum tiene unas guías específicas:

• La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por el equipo- para quien llegue tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plástico del cuello, etc)

• Todos son bienvenidos, pero sólo los responsables pueden hablar.

• La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.

• Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta)

• La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.

Durante la reunión, cada miembro del equipo contesta a tres preguntas:

• ¿Qué has hecho desde ayer?

• ¿Qué es lo que estás planeando hacer hoy?

• ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).

Scrum de Scrum

Cada día normalmente después del “Daily Scrum”

• Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración.

• Asiste una persona asignada por cada equipo.

La agenda será la misma que la del Daily Scrum, añadiendo además las siguientes cuatro preguntas:

• ¿Qué ha hecho tu equipo desde nuestra última reunión?

• ¿Qué hará tu equipo antes que nos volvamos a reunir?

• ¿Hay algo que demora o estorba a tu equipo?

• ¿Estás a punto de poner algo en el camino del otro equipo

• La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de programación que usa objetos y sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herencia, abstracción, polimorfismo y encapsulamiento. Su uso se popularizó a principios de la década de los años 1990. En la actualidad, existe variedad de lenguajes de programación que soportan la orientación a objetos

Los objetos son entidades que tienen un determinado estado, comportamiento (método) e identidad:

• El estado está compuesto de datos o informaciones , será uno o varios atributos a los que se habrán asignado unos valores concretos (datos).

• El comportamiento está definido por los métodos o mensajes a los que sabe responder dicho objeto, es decir, qué operaciones se pueden realizar con él.

• La identidad es una propiedad de un objeto que lo diferencia del resto, dicho con otras palabras, es su identificador (concepto análogo al de identificador de una variable o una constante).

Un objeto contiene toda la información que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interacción llamados métodos, que favorecen la comunicación entre ellos. Esta comunicación favorece a su vez el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separa el estado y el comportamiento.

Los métodos (comportamiento) y atributos (estado) están estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a alguno de ellos. Hacerlo podría producir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que manejen a las primeras por el otro. De esta manera se estaría realizando una programación estructurada camuflada en un lenguaje de programación orientado a objetos.

La POO difiere de la programación estructurada tradicional, en la que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. 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.

Origen

Los conceptos de la programación orientada a objetos tienen origen en Simula 67, un lenguaje diseñado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard del Centro de Cómputo Noruego en Oslo. En este centro, se trabajaba en simulaciones de naves, que fueron confundidas por la explosión combinatoria de cómo las diversas cualidades de diferentes naves podían afectar unas a las otras. La idea surgió al agrupar los diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus propios datos y comportamientos. Fueron refinados más tarde en Smalltalk, desarrollado en Simula en Xerox PARC (cuya primera versión fue escrita sobre Basic) pero diseñado para ser un sistema completamente dinámico en el cual los objetos se podrían crear y modificar "sobre la marcha" (en tiempo de ejecución) en lugar de tener un sistema basado en programas estáticos.

La programación orientada a objetos se fue convirtiendo en el estilo de programación dominante a mediados de los años ochenta, en gran parte debido a la influencia de C++, una extensión del lenguaje de programación C. Su dominación fue consolidada gracias al auge de las Interfaces gráficas de usuario, para las cuales la programación orientada a objetos está particularmente bien adaptada. En este caso, se habla también de programación dirigida por eventos.

Las características de orientación a objetos fueron agregadas a muchos lenguajes existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp, Pascal, entre otros. La adición de estas características a los lenguajes que no fueron diseñados inicialmente para ellas condujo a menudo a problemas de compatibilidad y en la capacidad de mantenimiento del código. Los lenguajes orientados a objetos "puros", por su parte, carecían de las características de las cuales muchos programadores habían venido a depender. Para saltar este obstáculo, se hicieron muchas tentativas para crear nuevos lenguajes basados en métodos orientados a objetos, pero permitiendo algunas características imperativas de maneras "seguras". El Eiffel de Bertrand Meyer fue un temprano y moderadamente acertado lenguaje con esos objetivos pero ahora ha sido esencialmente reemplazado por Java, en gran parte debido a la aparición de Internet, y a la implementación de la máquina virtual de Java en la mayoría de navegadores. PHP en su versión 5 se ha modificado, soporta una orientación completa a objetos, cumpliendo todas las características propias de la orientación a objetos.

Conceptos fundamentales

La programación orientada a objetos es una forma de programar que trata de encontrar una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes:

• Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas.

• Herencia: (por ejemplo, herencia de la clase C a la clase D) Es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos métodos y variables publicas declaradas en C. Los componentes registrados como "privados" (private) también se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y sólo pueden ser accedidos a través de otros métodos públicos. Esto es así para mantener hegemónico el ideal de OOP.

• Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos) los mismos que consecuentemente reaccionan a eventos. Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase.

• Método: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema.

• Evento: Es un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. También se puede definir como evento, a la reacción que puede desencadenar un objeto, es decir la acción que genera

• Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó.

• Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.

• Estado interno: es una variable que se declara privada, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase.

• Componentes de un objeto: atributos, identidad, relaciones y métodos.

• Identificación de un objeto: un objeto se representa por medio de una tabla o entidad que esté compuesta por sus atributos y funciones correspondientes.

En comparación con un lenguaje imperativo, una "variable", no es más que un contenedor interno del atributo del objeto o de un estado interno, así como la "función" es un procedimiento interno del método del objeto

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.

• 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.

• 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 se pueden compilar por separado, pero 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 especifica 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.

• 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.

• 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

Herramienta CASE

//commons.wikimedia.org/wiki/File:Umbrello_1.png?uselang=es//commons.wikimedia.org/wiki/File:Umbrello_1.png?uselang=es

/wiki/Archivo:Umbrello_1.pngLas herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costos, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras, que analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statement Analyzer).

Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear nuevos proyectos informáticos, la primera herramienta CASE fue Excelerator que salió a la luz en el año 1984 y trabajaba bajo una plataforma PC.

Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM había conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el mercado de diversas herramientas más específicas para cada fase del ciclo de vida del software.

Objetivos

Mejorar la productividad en el desarrollo y mantenimiento del software.

Aumentar la calidad del software.

Reducir el tiempo y coste de desarrollo y mantenimiento de los sistemas informáticos.

Mejorar la planificación de un proyecto

Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos.

Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores y la gestión del proyecto.

Ayuda a la reutilización del software, portabilidad y estandarización de la documentación

Gestión global en todas las fases de desarrollo de software con una misma herramienta.

Facilitar el uso de las distintas metodologías propias de la ingeniería del software.

Clasificación

Aunque no es fácil y no existe una forma única de clasificarlas, las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parámetros:

Las plataformas que soportan.

Las fases del ciclo de vida del desarrollo de sistemas que cubren.

La arquitectura de las aplicaciones que producen.

Su funcionalidad.

La siguiente clasificación es la más habitual basada en las fases del ciclo de desarrollo que cubren:

• Upper CASE (U-CASE), herramientas que ayudan en las fases de planificación, análisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML.

• Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y diseño de la aplicación.

• Lower CASE (L-CASE), herramientas que semi-automatizan la generación de código, crean programas de detección de errores, soportan la depuración de programas y pruebas. Además automatizan la documentación completa de la aplicación. Aquí pueden incluirse las herramientas de Desarrollo rápido de aplicaciones.

Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificación excluyente entre sí, ni con la anterior:

• Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo software, desde análisis hasta implementación.

• MetaCASE, herramientas que permiten la definición de nuestra propia técnica de modelado, los elementos permitidos del metamodelo generado se guardan en un repositorio y pueden ser usados por otros analistas, es decir, es como si definiéramos nuestro propio UML, con nuestros elementos, restricciones y relaciones posibles.

• CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software.

• IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de vida, incluyen componentes para la gestión de proyectos y gestión de la configuración activa.

Por funcionalidad podríamos diferenciar algunas como:

• Herramientas de generación semiautomática de código.

• Editores UML.

• Herramientas de Refactorización de código.

• Herramientas de mantenimiento como los sistemas de control de versiones·