Enfoque y Diseño Orientado a Objetos (ADOO)
Es un método de Enfoque que examina los requerimientos desde la perspectiva de clase y objetos encontrada en el vocabulario original del problema. Se fundamenta en un conjunto de cinco principios básicos:
— • Modelar el dominio de la información.
— • Describir la función del módulo.
— • Representar el comportamiento del modelo.
— • Dividir el modelo para mostrar más detalles.
En este tipo de análisis los modelos iniciales representan la esencia del problema, mientras que los últimos aportan detalles de la implementación.
- Características, Aplicabilidad.
Características del Enfoque Orientado a Objetos
— • Identidad: Los datos están cuantificados en entidades discretas y distinguibles denominadas objetos. Estos pueden ser tangibles o intangibles.
— • Clasificación: Los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se agrupan para formar una misma clase, se dice que cada objeto es una instancia de su propia clase, y una clase es una abstracción que describe propiedades importantes para una aplicación y se olvida del resto.
— • Polimorfismo: Significa que una misma operación puede comportarse de modos distintos en distintas clases, una operación es una acción o transformación que se aplica a un objeto.
— • Herencia: Comparte atributos y operaciones entre clases tomando como base una relación jerárquica, es decir que se puede definir una clase que después producirá subclases, sabiendo que todas las subclases adquirirán todas y cada una de las propiedades de su super-clase y le agrega además sus propiedades exclusivas.
- Aplicaciones Orientadas a Objetos.
A lo largo de la historia de la programación, los lenguajes y las metodologías han pasado de una relativa simplicidad a una complejidad creciente. Los lenguajes de programación orientados a objetos pretenden aportar simplicidad a la tarea de programación de grandes aplicaciones.
Cuando se crearon las primeras computadoras todavía no existían los lenguajes de programación, tal como ahora los entendemos. El lenguaje ensamblador puede considerarse como el primer lenguaje de programación propiamente dicho. Permitía al usuario un diálogo más fluido con la máquina a través de instrucciones que tenían relación directa con el conjunto de operaciones que la máquina podía realizar.
A partir de este momento empezó la evolución de los lenguajes de programación. _cada uno tenía su entorno definido y aunque en realidad todos los lenguajes son polivalentes (en teoría, con cualquiera de ellos se puede desarrollar cualquier programa de gestión o científico). Pronto apareció la especialización funcional. Así, COBOL (Common Business Orientated Language) se introdujo como lenguaje mainframe para el diseño de aplicaciones de gestión.; FORTRAN (Formula Translator) para el diseño de aplicaciones científicas; APL (A Programming Language) para el cálculo matemático, etc.
A medida que el software tomaba importancia, aparecieron los primeros problemas relacionados con la programación. Al tiempo que aumenta elvolumen de un programa, disminuye el control del mismo por parte del programador y la capacidad de este de dar mantenimiento.
En un intento de solucionar estos problemas aparecen las metodologías de programación. Una metodología es un conjunto de reglas destinadas a simplificar las tareas de diseño, estimación de costes, desarrollo y mantenimiento de un sistema informático. A menudo se ven acompañadas con unas herramientas (CASE: Computer Aided Software Engeneering) que permiten la elaboración estructurada y documentada de los sistemas informáticos.
Componentes, Tipos, Características y Reusabilidad de componentes.
Un componente de software es un elemento de un sistema software que ofrece un conjunto de servicios, o funcionalidades, a través de interfaces definidas.
Tipos de componentes y características.
Componentes de despliegue o distribución (Deployment)
Estos componentes se usan para formar un sistema ejecutable. Un ejemplo de tal componente es la librería de enlace dinámico y los archivos ejecutables. Otros ejemplos son los componentes COM+, Enterprise Java Beans, componentes CORBA y objetos de base de datos.
Componentes de Producto de Trabajo
Estos componentes son parte del proceso de desarrollo que es esencial para el sistema. Algunos ejemplos de componentes de producto de trabajo son los archivos fuente, archivos de datos y tablas. Ellos son los archivos fuente y archivos de datos que se usan para crear los componentes de distribución como AgenteAnalizado.Java y AnalizadorDatos.txt.
Componentes de Ejecución
Estos componentes son el resultado de un sistema que se está ejecutando. Cuando un DLL es instanciado como un componente COM+, es un ejemplo de un componente de ejecución.
Características
- La característica fundamental de un componente es la habilidad de definir interfaces.
- Es una unidad ejecutable que puede ser implantada independientemente.
- Puede ser sujeto de composición por terceras partes, es decir, una compañía o un desarrollador puede llegar y tomar el componente y agregarlo a lo que esté haciendo, o sea haría una composición de componentes.
- Un componente no tiene estado.
- Se puede tomar a los componentes de software como una analogía a los componentes electrónicos.
Reusabilidad de componentes.
Una vez que una clase ha sido escrita, creada y depurada, se puede distribuir a otros programadores para utilizar en sus propios programas. Esta propiedad se llama reusabilidad o reutilización. Su concepto es similar a las funciones incluidas en las bibliotecas de funciones de un lenguaje procedimental como C que se pueden incorporar en diferentes programas. En C++, el concepto de herencia proporciona una extensión o ampliación al concepto de reusabilidad.
Un programador puede considerar una clase existente y sin modificarla, añadir competencias y propiedades adicionales a ella. Esto se consigue derivando una nueva clase de una ya existente. La nueva clase heredará las características de la clase antigua, pero es libre de añadir nuevas características propias.
La facilidad de reutilizar o rehusar el software existente es uno de los grandes beneficios de la POO: muchas empresas consiguen con la reutilización de clase en nuevos proyectos la reducción de los costes de inversión en sus presupuestos de programación. Las propiedades comunes de varias clases sólo necesitan ser implementadas una vez y sólo necesitan modificarse una vez si es necesario.
Estándares en el proceso de desarrollo de software
Para promover un nivel mayor en el área de ingeniería de software tenemos un conjunto de reglas que ya han usado otros como normas a seguir para que la programación sea mas fácil y eficiente para todos.
El estándar internacional que regula el método de selección, implementación ymonitoreo del ciclo de vida del software es ISO 12207.Durante décadas se ha perseguido la meta de encontrar procesos reproducibles ypredecibles que mejoren la productividad y la calidad. Algunas de estas solucionesintentan sistematizar o formalizar la aparentemente desorganizada tarea de desarrollar software.
Otros aplican técnicas de gestión de proyectos para la creación del software.Sin una gestión del proyecto, los proyectos de software corren el riesgo de demorarse oconsumir un presupuesto mayor que el planeado. Dada la cantidad de proyectos desoftware que no cumplen sus metas en términos de funcionalidad, costes o tiempo deentrega, una gestión de proyectos efectiva es algo que a menudo falta. Planificación.
La importante tarea a la hora de crear un producto de software es obtener losrequisitos o el análisis de los requisitos. Los clientes suelen tener una idea más bienabstracta del resultado final, pero no sobre las funciones que debería cumplir elsoftware.
Una vez que se hayan recopilado los requisitos del cliente, se debe realizar unanálisis del ámbito del desarrollo. Este documento se conoce como especificaciónfuncional.Implementación, pruebas y documentación.La implementación es parte del proceso en el que los ingenieros de software programanel código para el proyecto.
Las pruebas de software son parte esencial del proceso de desarrollo del software. Estaparte del proceso tiene la función de detectar los errores de software lo antes posible.La documentación del diseño interno del software con el objetivo de facilitar su mejora ysu mantenimiento se realiza a lo largo del proyecto. Esto puede incluir ladocumentación de un API, tanto interior como exterior.
Despliegue y mantenimiento.
El despliegue comienza cuando el código ha sido suficientemente probado, ha sidoaprobado para su liberación y ha sido distribuido en el entorno de producción.Entrenamiento y soporte para el software es de suma importancia y algo que muchosdesarrolladores de software descuidan. Los usuarios, por naturaleza, se oponen alcambio porque conlleva una cierta inseguridad, es por ello que es fundamental instruir de forma adecuada a los futuros usuarios del software.
El mantenimiento y mejora del software de un software con problemas recientementedesplegado puede requerir más tiempo que el desarrollo inicial del software. Es posibleque haya que incorporar código que no se ajusta al diseño original con el objetivo desolucionar un problema o ampliar la funcionalidad para un cliente. Si los costes demantenimiento son muy elevados puede que sea oportuno rediseñar el sistema parapoder contener los costes de mantenimiento.
Codificar y corregir.
Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos pasos:
Escribir código.
Corregir problemas en el código.
Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño, validación, y mantenimiento.
Este modelo tiene tres problemas principales:
Después de un número de correcciones, el código puede tener una muy mala estructura, hace que los arreglos sean muy costosos.
Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstrucción es muy cara.
El código es difícil de reparar por su pobre preparación para probar y modificar.
Documentación y Artefactos.
La documentación no es más que la debilidad más frecuente en productos e instalaciones informáticos. Cabe mencionar que 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.
Un artefacto es una pieza de información que es producida o utilizada por procesos. Los artefactos son los elementos son los elementos tangibles de un proyecto, elementos que el proyecto produce o usa mientras se trabaja en busca del producto final. Éstos, pueden tomar varias formas y formatos, como por ejemplo:
Un documento, tal como la visión o la lista de riesgos.
Un modelo, por ejemplo un diagrama de casos de uso o el modelo de diseño.
Un elemento dentro de un modelo, tal como una clase, un caso de uso o un subsistema.
Ejecutables, por ejemplo el ejecutable del prototipo.
Código fuente.
Las actividades tienen artefactos como entrada y salida. Los roles usan artefactos para ejecutar actividades y producen artefactos durante la ejecución de sus actividades. Los artefactos son la responsabilidad sencilla del rol, creando responsabilidades fáciles de identificar y entender, promoviendo la idea de que cada pieza de información producida en un proceso de desarrollo requiere un conjunto apropiado de habilidades. Aunque un rol puede ser el propietario de un artefacto, otros roles pueden hacer uso de éste, incluso podrían actualizar el artefacto si el rol que va a hacerlo, tiene permiso para hacerlo.
En RUP se encuentran conjuntos de artefactos que agrupan artefactos relacionados con el modelo de negocio, los requerimientos, el análisis y diseño, la implementación, las pruebas, la configuración y administración de cambios, el ambiente de desarrollo, entre otros.
Metodologías empleadas
La metodología de desarrollo de software orientada a objetos es cada día más usada, pues permite desarrollar software fácilmente extensible y reusable. Esto último es sólo posible si los desarrolladores conocen muy bien los fundamentos que esté basada esta metodología. Por eso, este curso revisa los conceptos más importantes que se encuentran en las distintas etapas del desarrollo de software orientado a objetos.
PROCESO UNIFICADO DE DESARROLLO (UP DEL INGLÉS UNIFIED PROCESS). FASES DE DESARROLLO. DISCIPLINAS.
El proceso unificado (UP, o Unified Development Process) es una versión libre y abierta (no propietaria) del proceso iterativo e incremental de ingeniería de software propuesto por Jacobson, Booch y Rumbaugh (los “tres amigos”) en su libro El proceso unificado de desarrollo de software, publicado por Addisson-Wesley en 1999. El lenguaje para especificar y diagramar en el UP es UML, por lo cual puede apoyarse en cualquier herramienta que soporte UML.
Sus características principales son:
Ventajas: Su uso es libre (como decir “barra libre”, sin condiciones).
Hay excelentes textos, que explican la aplicación de este proceso paso a paso, como UML y patrones, de Craig Larman, publicado por Pearson-Prentice Hall (Segunda Edición, Madrid, 2003).
Desventaja: Es necesario “aterrizar” los conceptos, lo cual puede resultar un poco difícil para quien no tenga experiencia en el uso de procesos de ingeniería de software.
Fases de Desarrollo
Cada fase representa un ciclo de desarrollo en la vida de un producto de software.
La fase de concepción o inicio tiene por finalidad definir la visión, los objetivos y el alcance del proyecto, tanto desde el punto de vista funcional como del técnico, obteniéndose como uno de los principales resultados una lista de los casos de uso y una lista de los factores de riesgo del proyecto. El principal esfuerzo está radicado en el Modelamiento del Negocio y el Análisis de Requerimientos. Es la única fase que no necesariamente culmina con una versión ejecutable.
La fase de elaboración tiene como principal finalidad completar el análisis de los casos de uso y definir la arquitectura del sistema, además se obtiene una aplicación ejecutable que responde a los casos de uso que la comprometen. A pesar de que se desarrolla a profundidad una parte del sistema, las decisiones sobre la arquitectura se hacen sobre la base de la comprensión del sistema completo y los requerimientos (funcionales y no funcionales) identificados de acuerdo al alcance definido.
La fase de construcción está compuesta por un ciclo de varias iteraciones, en las cuales se van incorporando sucesivamente los casos de uso, de acuerdo a los factores de riesgo del proyecto. Este enfoque permite por ejemplo contar en forma temprana con versiones el sistema que satisfacen los principales casos de uso. Los cambios en los requerimientos no se incorporan hasta el inicio de la próxima iteración.
La fase de transición se inicia con una versión “beta” del sistema y culmina con el sistema en fase de producción.
PROCESO UNIFICADO DE DESARROLLO (UP DEL INGLÉS UNIFIED PROCESS). FASES DE DESARROLLO. DISCIPLINAS.
El proceso unificado (UP, o Unified Development Process) es una versión libre y abierta (no propietaria) del proceso iterativo e incremental de ingeniería de software propuesto por Jacobson, Booch y Rumbaugh (los “tres amigos”) en su libro El proceso unificado de desarrollo de software, publicado por Addisson-Wesley en 1999. El lenguaje para especificar y diagramar en el UP es UML, por lo cual puede apoyarse en cualquier herramienta que soporte UML.
Sus características principales son:
- Está dirigido por casos de uso (véase la sección sobre UML).
- Está centrado en la arquitectura (es decir, en una solución de conjunto.
- Tiene un ciclo de vida iterativo incremental (véase más adelante).
Ventajas: Su uso es libre (como decir “barra libre”, sin condiciones).
Hay excelentes textos, que explican la aplicación de este proceso paso a paso, como UML y patrones, de Craig Larman, publicado por Pearson-Prentice Hall (Segunda Edición, Madrid, 2003).
Desventaja: Es necesario “aterrizar” los conceptos, lo cual puede resultar un poco difícil para quien no tenga experiencia en el uso de procesos de ingeniería de software.
Fases de Desarrollo
Cada fase representa un ciclo de desarrollo en la vida de un producto de software.
La fase de concepción o inicio tiene por finalidad definir la visión, los objetivos y el alcance del proyecto, tanto desde el punto de vista funcional como del técnico, obteniéndose como uno de los principales resultados una lista de los casos de uso y una lista de los factores de riesgo del proyecto. El principal esfuerzo está radicado en el Modelamiento del Negocio y el Análisis de Requerimientos. Es la única fase que no necesariamente culmina con una versión ejecutable.
La fase de elaboración tiene como principal finalidad completar el análisis de los casos de uso y definir la arquitectura del sistema, además se obtiene una aplicación ejecutable que responde a los casos de uso que la comprometen. A pesar de que se desarrolla a profundidad una parte del sistema, las decisiones sobre la arquitectura se hacen sobre la base de la comprensión del sistema completo y los requerimientos (funcionales y no funcionales) identificados de acuerdo al alcance definido.
La fase de construcción está compuesta por un ciclo de varias iteraciones, en las cuales se van incorporando sucesivamente los casos de uso, de acuerdo a los factores de riesgo del proyecto. Este enfoque permite por ejemplo contar en forma temprana con versiones el sistema que satisfacen los principales casos de uso. Los cambios en los requerimientos no se incorporan hasta el inicio de la próxima iteración.
La fase de transición se inicia con una versión “beta” del sistema y culmina con el sistema en fase de producción.
INTRODUCCIÓN AL MODELADO.
El lenguaje de modelado de objetos es un conjunto estandarizado de símbolos y de modos de disponerlos para modelar (parte de) un diseño de software orientado a objetos.
Características de los lenguajes de modelado.
1. UML debe entenderse como:
- Un estándar para modelado de sistemas.
- No es un estándar para procesos de software.
- Debe aplicarse en el contexto de un proceso de software.
2. Es una notación, no es un proceso.
3. Establecido como estándar para documentar el proceso de ingeniería de software.
4. Combina lo mejor del modelado de procesos, objetos, datos y componentes.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware,
y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas.
• Diagramas de Casos de Uso para modelar los procesos ’business’.
• Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
• Diagramas de Colaboración para modelar interacciones entre objetos.
• Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.
• Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.
• Diagramas de Clases para modelar la estructura estática de las clases en el sistema.
• Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.
• Diagramas de Componentes para modelar componentes.
• Diagramas de Implementación para modelar la distribución del sistema.
Diagramas, Símbolos y Notación.
Una de la metas principales de UML es avanzar en el estado de la integración institucional proporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sin embargo para lograr un intercambio exitoso de modelos de información entre herramientas, se requirió definir a UML una semántica y una notación.
La notación es la parte gráfica que se ve en los modelos y representa la sintaxis del lenguaje de modelado. Por ejemplo, la notación del diagrama de clases define como se representan los elementos y conceptos como son: una clase, una asociación y una multiplicidad. ¿Y qué significa exactamente una asociación o multiplicidad en una clase?. Un metamodelo es la manera de definir esto (un diagrama, usualmente de clases, que define la notación).
Para que un proveedor diga que cumple con UML debe cubrir con la semántica y con la notación.
Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismo modelo. Bajo esta definición una herramienta que solo dibuje, no puede cumplir con la notación de UML.
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 (forman la vista lógica.)
Casos de Uso
Diagrama de Interacción (constituyen la vista de proceso.)
Diagrama_Insumo
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.
1. UML debe entenderse como:
- Un estándar para modelado de sistemas.
- No es un estándar para procesos de software.
- Debe aplicarse en el contexto de un proceso de software.
2. Es una notación, no es un proceso.
3. Establecido como estándar para documentar el proceso de ingeniería de software.
4. Combina lo mejor del modelado de procesos, objetos, datos y componentes.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware,
y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas.
• Diagramas de Casos de Uso para modelar los procesos ’business’.
• Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
• Diagramas de Colaboración para modelar interacciones entre objetos.
• Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.
• Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.
• Diagramas de Clases para modelar la estructura estática de las clases en el sistema.
• Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.
• Diagramas de Componentes para modelar componentes.
• Diagramas de Implementación para modelar la distribución del sistema.
Diagramas, Símbolos y Notación.
Una de la metas principales de UML es avanzar en el estado de la integración institucional proporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sin embargo para lograr un intercambio exitoso de modelos de información entre herramientas, se requirió definir a UML una semántica y una notación.
La notación es la parte gráfica que se ve en los modelos y representa la sintaxis del lenguaje de modelado. Por ejemplo, la notación del diagrama de clases define como se representan los elementos y conceptos como son: una clase, una asociación y una multiplicidad. ¿Y qué significa exactamente una asociación o multiplicidad en una clase?. Un metamodelo es la manera de definir esto (un diagrama, usualmente de clases, que define la notación).
Para que un proveedor diga que cumple con UML debe cubrir con la semántica y con la notación.
Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismo modelo. Bajo esta definición una herramienta que solo dibuje, no puede cumplir con la notación de UML.
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 (forman la vista lógica.)
Casos de Uso
Diagrama de Interacción (constituyen la vista de proceso.)
Diagrama_Insumo
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.
Herramientas CASE
Herramienta CASE según ...
Henry David Crockett (Portland State University), "Las herramientas CASE se ven simplemente como herramientas que cualquiera puede escoger y utilizar (como un martillo) para desarrollar un sistema de información, su selección e implementación casi siempre llevará a una reducida productividad y calidad. La selección e implementación de herramientas CASE son un proceso de múltiples etapas que permite errores fatales en cada etapa. Uno de los errores más comunes es escoger una herramienta CASE que apoye un método desconocido para los diseñadores".
Alan Chimura (CASE Associates), "Las herramientas CASE incluyen manejadores, métodos, técnicas, disciplina, e instrucciones, todos trabajando juntos. Definir CASE menos ampliamente y presentarlo sin un suficiente entorno de apoyo es un acto de negligencia".
Las herramientas CASE abarcan cada etapa del proceso de ingeniería y cada actividad que se desarrolla a lo largo del mismo. CASE está formado por un conjunto de bloques que comienzan en el nivel del hardware y del sistema operativo y acaban en cada una de las herramientas.
CASE se refiere a herramientas para el desarrollo de sistemas que constan de cinco componentes: herramientas de diagramación, depósito de información, generadores de interfaces, generadores de código y herramientas de administración. Las herramientas CASE hacen hincapié en las actividades de alto nivel, aunque el objetivo a largo plazo es abarcar las actividades de análisis, diseño y desarrollo.
En resumen, las herramientas CASE son un complemento de la caja de herramientas del ingeniero del software. CASE proporciona al ingeniero la posibilidad de automatizar actividades manuales y de mejorar su visión general de la ingeniería. Al igual que las herramientas de ingeniería y de diseño asistidos por computadora que utilizan los ingenieros de otras disciplinas. Las herramientas CASE ayudan a asegurar la calidad de un producto desde su diseño antes de construirlo.
Bloques básicos de CASE
La ingeniería del software asistida por computadora puede ser tan sencilla como una única herramienta que preste su apoyo para una única actividad de ingeniería del software, o bien puede ser tan compleja como todo un entorno que abarque herramientas, una base de datos, personas, hardware, una red, sistemas operativos, estándares, y otros muchos componentes más.
Los bloques de construcción de CASE
Cada bloque de construcción forma un fundamento para el siguiente, estando las herramientas situadas en la parte superior de la estructura de los niveles de Hardware y Software. Es interesante tener en cuenta que el fundamento de los entornos CASE efectivos tiene relativamente poco que ver con las herramientas de ingeniería del software en sí. Más bien, los entornos que tienen éxito para la ingeniería del software se construyen basándose en una arquitectura de entorno que abarca un hardware y un sistema software adecuado. Además, la arquitectura del entorno debe considerar patrones de trabajo humano que se aplican durante el proceso de ingeniería de software. La arquitectura del entorno debe de considerar los patrones de trabajo humano que se aplicaran durante el proceso de ingeniería del software. Las arquitecturas del entorno constan de una plataforma hardware y de un apoyo de sistema operativo (incluyendo el software de red y de gestión de la base de datos), constituyen los fundamentos de CASE. Aunque su entorno en si requiere de otros bloques de construcción, existe un conjunto de servicios de portabilidad que proporciona un puente entre las herramientas CASE y su marco de referencia de integración y la arquitectura del entorno.
El marco de referencia de integración es una colección de programas más especializados que capacitan a las herramientas CASE individuales para comunicarse entre sí, para crear una base de datos del proyecto, y para mostrar el mismo aspecto al usuario final (el ingeniero del software). Los servicios de portabilidad permiten que las herramientas CASE y su marco de referencia de integración, migren entre distintas plataformas del hardware y sistemas operativos sin un mantenimiento adaptativo que resulte significativo.
Los bloques de construcción representan un fundamento exhaustivo para la integración de herramientas CASE. Sin embargo, la mayor parte de las herramientas CASE utilizados actualmente no han sido construidas empleando todos los bloques de construcción que antes descritos. De hecho, algunas herramientas CASE siguen siendo soluciones puntuales. Esto es, se utiliza una herramienta para que preste apoyo en una actividad de ingeniería del software concreta (p. ej.: análisis y modelado), pero esta herramienta no se comunica directamente con otras. Es decir, no esta unida a una base de datos del proyecto y no forma parte de un entorno integrado CASE (I-CASE), aún cuando no es lo ideal, se puede utilizar una herramienta CASE lo suficientemente eficiente, aunque se trate de una solución puntual.
Ciclo de vida del desarrollo de un sistema con las herramientas CASE y los métodos tradicionales.
Utilizar herramientas CASE para el desarrollo de un sistema tiene una ligera ventaja sobre los sistemas tradicionales (ver Figuras a y b), y entre los beneficios ofrecidos por la tecnología CASE se encuentran los siguientes:
- Facilidad para llevar a cabo la tarea de revisión de especificaciones del sistema así como de representaciones gráficas (lo que aumenta la posibilidad de realizar la tarea).
- Facilidad para desarrollar prototipos de sistemas por medio de la capacidad para cambiar especificaciones y, por otro lado, para determinar el efecto que sobre el desempeño del sistema tendrían otras alternativas.
- Generación de código.
- Soporte para mantenimiento como resultado de haber guardado las especificaciones del sistema en un depósito central de información.
- Aumentar las posibilidades de satisfacer los requerimientos del usuario.
Clasificación de Herramientas CASE
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:
1. Las plataformas que soportan.
2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.
3. La arquitectura de las aplicaciones que producen.
4. Su funcionalidad.
La clasificación basada en las fases del ciclo de desarrollo cubre:
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.
Por funcionalidad podríamos diferenciar algunas como:
1. Las plataformas que soportan.
2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.
3. La arquitectura de las aplicaciones que producen.
4. Su funcionalidad.
La clasificación basada en las fases del ciclo de desarrollo cubre:
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.
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.
Ejemplos de Herramientas Case más utilizadas.
ERwin: PLATINUM ERwin es una herramienta de diseño de base de datos. Brinda productividad en diseño, generación, y mantenimiento de aplicaciones. Desde un modelo lógico de los requerimientos de información, hasta el modelo físico perfeccionado para las características específicas de la base de datos diseñada, ERwin permite visualizar la estructura, los elementos importantes, y optimizar el diseño de la base de datos. Genera automáticamente las tablas y miles de líneas de stored procedure y triggers para los principales tipos de base de datos.
EasyCASE: EasyCASE Profesional, el centro de productos para procesos, modelamiento de datos y eventos, e Ingeniería de Base de Datos, es un producto para la generación de esquemas de base de datos e ingeniería reversa, trabaja para proveer una solución comprensible para el diseño, consistencia y documentación del sistema en conjunto.
Oracle Designer: Oracle Designer es un juego de herramientas para guardar las definiciones que necesita el usuario y automatizar la construcción rápida de aplicaciones cliente/servidor flexibles y gráficas. Integrado con Oracle Developer, Oracle Designer provee una solución para desarrollar sistemas empresariales cliente/servidor de segunda generación.
PowerDesigner: PowerDesigner es una suite de aplicaciones de Powersoft para la construcción, diseño y modelado de datos a través de diversas aplicaciones. Es la herramienta para el análisis, diseño inteligente y construcción sólida de una base de datos y un desarrollo orientado a modelos de datos a nivel físico y conceptual, que dan a los desarrolladores de aplicaciones Cliente/Servidor la más firme base para aplicaciones de alto rendimiento.
System Architect: System Architect posee un repositorio único que integra todas las herramientas, y metodologías usadas. En la elaboración de los diagramas, el System Architect conecta directamente al diccionario de datos, los elementos asociados, comentarios,reglas de validaciones, normalización, etc. Posee control automático de diagramas y datos, normalizaciones y balanceo entre diagramas "Padre e Hijo", además de balanceo horizontal, que trabaja integrado con el diccionario de datos, asegurando la compatibilidad entre el Modelo de Datos y el Modelo Funcional.
SNAP: SNAP es un CASE para el desarrollo de aplicaciones en Sistemas AS/400 de IBM. Proporciona el ambiente integral de trabajo, brindando la posibilidad de construir sistemas de inmejorable calidad, adheridos a los estándares S.A.A de IBM., totalmente documentados y ajustados a los requerimientos específicos de la organización, en una fracción del tiempo y coste del que se invertiría, si se utilizaran herramientas tradicionales.
Toad™ Data Modeler: ayuda a crear modelos de datos de alta calidad y aplicar fácilmente cambios exactos a las estructuras de datos, por una fracción del costo de muchas otras soluciones.
Con este software de modelado de datos de plataformas cruzadas, usted puede:
- Crear modelos de datos lógicos y físicos de alta calidad
- Comparar y sincronizar modelos
- Generar SQL/DDL complejos
- Crear y modificar scripts
- Aplicar ingeniería inversa y directa a bases de datos y sistemas de almacenamiento de datos
Microsoft Visio: es un software de dibujo vectorial para Microsoft Windows. Visio comenzó a formar parte de los productos de Microsoft cuando fue adquirida la compañía Visio en el año 2000.
Las herramientas que lo componen permiten realizar diagramas de oficinas, diagramas de bases de datos, diagramas de flujo de programas, UML, y más, que permiten iniciar al usuario en los lenguajes de programación.
El navegador Internet Explorer incluye un visor de diagramas Visio, cuya extensión es vsd, llamado Visio Viewer.
Umbrello: es una herramienta libre para crear y editar diagramas UML, que ayuda en el proceso del desarrollo de software. Fue desarrollada por Paul Hensgen, y está diseñado principalmente para KDE, aunque funciona en otros entornos de escritorio.
Umbrello maneja gran parte de los diagramas estándar UML pudiendo crearlos, además de manualmente, importándolos a partir de código en C++, Java, Python, IDL, Pascal/Delphi, Ada, o también Perl (haciendo uso de una aplicación externa). Así mismo, permite crear un diagrama y generar el código automáticamente en los lenguajes antes citados, entre otros. El formato de fichero que utiliza está basado en XMI.
StarUML: StarUML es una herramienta de programación escrita en código abierto y de distribución libre que genera los diagramas UML para tus aplicaciones o páginas Web. Puede generar todo tipo de diagramas compatibles con la plataforma de programas Microsoft Office. StarUML se maneja con facilidad. En un vistazo a la interfaz se ven las funciones principales del programa. Otra característica importante del programa es que su código es compatible con C++ y Java.
No hay comentarios.:
Publicar un comentario