Herramientas CASE
Estas
herramientas 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. Ya en los años 70 un proyecto llamado ISDOS diseñó un
lenguaje y por lo tanto un producto que analizaba la relación existente entre
los requisitos de un problema y las necesidades que estos 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 o
computadoras centrales, 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.
Sus objetivos son:
1.
Mejorar la productividad del
software.
2.
Aumentar la calidad del software.
3.
Reducir el tiempo y costo de
desarrollo y mantenimiento de los sistemas informáticos.
4.
Mejorar la planificación de un
proyecto.
5.
Aumentar la biblioteca de
conocimiento informático de una empresa ayudando a la búsqueda de soluciones
para los requisitos.
6.
Automatizar el desarrollo del
software, la documentación, la generación de código, las pruebas de errores y
la gestión del proyecto.
7.
Ayuda a la reutilización del
software, portabilidad y estandarización de la documentación.
8.
Gestión global en todas las fases
de desarrollo de software con una misma herramienta.
9.
Facilitar el uso de las distintas
metodologías propias de la ingeniería del software.
¿Qué es un software portable?
Definición:
Programas
portables o software portable son aquellos programas que se ejecutan en la pc
sin necesidad de instalación y puedes llevarlos en cualquier dispositivo de
memoria extraíble (disquete, pendrive USB, memorias SD, etc.).
La configuración de estos programas se mantiene en el mismo dispositivo
portable, por la que no se modifican ningún archivo de la pc.
Nota:
Recomiendo usar programas portables para mayor comodidad ya que es fácil y no
modifica el REGEDIT de la pc.
¿Qué son las técnicas de diseño de software?
Técnicas
generales de diseño de software
I. Diseño procedimental
1.
Diseño funcional descendente
1.1.
Técnica del refinamiento progresivo Aplicación, a la fase de diseño, del
concepto de refinamientos sucesivos [Wirth]. Consiste en plantear la aplicación
como única operación global, e irla descomponiendo en operaciones más
sencillas, detalladas y específicas. En cada nivel de refinamiento, las
operaciones identificadas se asignan a módulos separados. La construcción de
programas mediante refinamientos sucesivos proviene de la metodología de
programación estructurada [Dijkstra]. Esta metodología de programación consiste
en la utilización sólo de estructuras de control claras y sencillas, con
esquemas de ejecución con un único punto de inicio y un único punto final.
1.2. Técnica de programación estructurada de
Jackson Aplicación, a la fase de diseño, de la metodología de programación
estructurada [Dijkstra]. Esta metodología de programación consiste en la
utilización sólo de estructuras de control claras y sencillas, con esquemas de
ejecución con un único punto de inicio y un único punto final. Dichas estructuras
son la secuencia, la selección y la iteración. La técnica de Jackson consiste
en construir las estructuras del programa de forma similar a las estructuras de
los datos de entrada-salida que se manejan. 1.3. Técnica de diseño estructurado
[Yourdon] Técnica de diseño complementaria del ‘análisis estructurado’
(utilización de DFD). Consiste en:
.
Utilización de DFD para la descripción del funcionamiento de la aplicación.
2.
Con los primeros niveles de la descomposición en DFD, se construye un único diagrama
en el que se incluyen los procesos implicados y se prescinde de los elementos
de almacenamiento. Es este último diagrama, se realiza un análisis para
identificar o bien un único flujo global (flujo de transformación) o bien uno o
varios puntos en los que el flujo global se bifurca (flujo de transacción).
3.
Según el patrón identificado en el análisis anterior, se construye el diagrama
de diseño mediante la notación de los diagramas de estructura. Para ello, a
partir de los DFD iniciales, se asignan procesos o grupos de procesos a los
módulos de diseño y se establece una jerarquía o estructura de control en
función del mencionado patrón identificado en el punto anterior (transformación
o transacción).
2.
Diseño con abstracciones
2.1. Descomposición modular con abstracciones
Consiste en dedicar módulos separados a la realización de cada tipo abstracto
de datos y cada función importante. Se emplea la notación de los diagramas de
bloques jerarquizados; en los que se representan las relaciones de uso y la
jerarquía se establece de arriba hacia abajo (‘los de arriba usan a los de
abajo’). Se puede aplicar de forma descendente (ampliación del refinamiento
progresivo con las abstracciones) o ascendente (ampliación de primitivas hacia
abstracciones de nivel superior).
2.2. Método de Abbott Metodología para
identificar los elementos abstractos que formarán parte del diseño. Las
abstracciones obtenidas se complementan y se organizan en un diagrama de
diseño. El método se suele aplicar a las descripciones del análisis (formales o
informales).
3
3. Diseño orientado a objetos En esencia es similar al diseño con abstracciones
pero, además de la relaciones de uso y agregación, hay que considerar la
herencia y el polimorfismo. En la descomposición modular del sistema, cada
módulo contiene la descripción de una clase o de varias clases de objetos
relacionadas entre sí. Se suele utilizar un diagrama de estructura para
describir la arquitectura del sistema y las relaciones de uso y diagramas
ampliados de las clases y objetos en las que se representan las distintas
relaciones entre los datos (herencia, polimorfismo, etc.).
¿Qué
es el desarrollo en cascada?
En Ingeniería de software el desarrollo en cascada, también
llamado modelo en cascada (denominado así por la posición de
las fases en el desarrollo de esta, que parecen caer en cascada “por
gravedad” hacia las siguientes fases), es el enfoque metodológico que
ordena rigurosamente las etapas del proceso para
el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización
de la etapa anterior.1 Al final de cada etapa, el modelo está diseñado
para llevar a cabo una revisión final, que se encarga de determinar si el
proyecto está listo para avanzar a la siguiente fase. Este modelo fue el
primero en originarse y es la base de todos los demás modelos de ciclo de vida.
La versión original fue propuesta por Winston W. Royce en 1970 y
posteriormente revisada por Barry Boehm en 1980 e Ian Sommerville en 1985.2
Un ejemplo de una metodología de desarrollo en cascada es:
1.
Análisis de requisitos.
2.
Diseño del Sistema.
3.
Diseño del Programa.
4.
Codificación.
5.
Pruebas.
6.
Verificación.
7.
Mantenimiento.
De esta forma, cualquier error de diseño detectado en la etapa de prueba
conduce necesariamente al rediseño y nueva programación del código afectado,
aumentando los costos del desarrollo. La palabra cascada sugiere,
mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para
introducir un cambio en las fases más avanzadas de un proyecto.
Sus fases del modelo son:
Análisis de requisitos
En esta fase se analizan las necesidades de los usuarios finales del
software para determinar qué objetivos debe cubrir. De esta fase surge una
memoria llamada SRD (documento de especificación de requisitos), que contiene
la especificación completa de lo que debe hacer el sistema sin entrar en
detalles internos.
Es importante señalar que en esta etapa se debe consensuar todo
lo que se requiere del sistema y será aquello lo que seguirá en las siguientes
etapas, no pudiéndose requerir nuevos resultados a mitad del proceso de
elaboración del software de una manera.
Diseño del Sistema
Descompone y organiza el sistema en elementos que puedan elaborarse por
separado, aprovechando las ventajas del desarrollo en equipo. Como resultado
surge el SDD (Documento de Diseño del Software), que contiene la descripción de
la estructura relacional global del sistema y la especificación de lo que debe
hacer cada una de sus partes, así como la manera en que se combinan unas con
otras.
Es conveniente distinguir entre diseño de alto nivel o arquitectónico y
diseño detallado. El primero de ellos tiene como objetivo definir la estructura
de la solución (una vez que la fase de análisis ha descrito el problema)
identificando grandes módulos (conjuntos de funciones que van a estar
asociadas) y sus relaciones. Con ello se define la arquitectura de la solución
elegida. El segundo define los algoritmos empleados y la organización del
código para comenzar la implementación.
Diseño del Programa
Es la fase en donde se realizan los algoritmos necesarios para el
cumplimiento de los requerimientos del usuario así como también los análisis
necesarios para saber qué herramientas usar en la etapa de Codificación
Codificación
Es la fase en donde se implementa el código fuente, haciendo uso de prototipos así como de pruebas y
ensayos para corregir errores.
Dependiendo del lenguaje de programación y su versión se crean las
bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer
que la programación sea un proceso mucho más rápido.
Pruebas
Los elementos, ya programados, se ensamblan para componer el sistema y se
comprueba que funciona correctamente y que cumple con los requisitos, antes de
ser entregado al usuario final.
Verificación
Es la fase en donde el usuario final ejecuta el sistema, para ello el o los
programadores ya realizaron exhaustivas pruebas para comprobar que el sistema
no falle.
Mantenimiento
Una de las etapas más críticas, ya que se destina un 75 % de los
recursos, es el mantenimiento del Software ya que al utilizarlo como usuario
final puede ser que no cumpla con todas nuestras expectativas.
¿Qué es el desarrollo en espiral?
Sus ciclos ó interaciones son:
En cada
vuelta o iteración hay que tener en cuenta:
·
Los Objetivos: qué
necesidad debe cubrir el producto.
·
Alternativas: las
diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes
puntos de vista como pueden ser:
1.
Características: experiencia
del personal, requisitos a cumplir, etc.
2.
Formas de gestión del sistema.
3.
Riesgo asumido con cada
alternativa.
·
Desarrollar y Verificar: Programar
y probar el software.
Si el resultado no es el
adecuado o se necesita implementar mejoras o funcionalidades:
·
Se planificaran los siguientes
pasos y se comienza un nuevo ciclo de la espiral. La espiral tiene una forma de caracola y
se dice que mantiene dos dimensiones, la radial y la angular:
1.
Angular: Indica
el avance del proyecto del software dentro de un ciclo.
2.
Radial: Indica
el aumento del coste del proyecto, ya que con cada nueva iteración se pasa más
tiempo desarrollando.
Este sistema es muy utilizado
en proyectos grandes y complejos como puede ser, por ejemplo, la creación de un
Sistema Operativo.
Al ser un modelo de Ciclo de
Vida orientado a la gestión de riesgo se dice que uno de los aspectos
fundamentales de su éxito radica en que el equipo que lo aplique tenga la
necesaria experiencia y habilidad para detectar y catalogar correctamente los
riesgos.
¿Qué son los Diagramas de Warnier/Orr?
Los diagramas de Warnier/Orr (también
conocidos como construcción lógica de programas/construcción lógica de
sistemas) fueron desarrollados inicialmente en Francia por Jean Dominique
Warnier y en los Estados Unidos por Kenneth Orr. Este método ayuda al diseño de
estructuras de programas identificando la salida y resultado del procedimiento,
y entonces trabaja hacia atrás para determinar los pasos y combinaciones de
entrada necesarios para producirlos. Los sencillos métodos gráficos usados en
los diagramas de Warnier/Orr hacen evidentes los niveles en un sistema y más
claros los movimientos de los datos en dichos niveles.
Los diagramas de Warnier/Orr son un tipo de
diagramas jerárquicos que se utilizan para
Describir tanto la organización de datos
como de procedimientos.
Hay cuatro construcciones básicas
utilizadas en los diagramas de W/O: jerarquía,Secuencia, repetición, y
selección.
¿Qúe es el desarrollo de software UML?
UML es el primer método en publicar un meta-modelo en
su propia notación, incluyendo la notación para la mayoría de la información de
requisitos, análisis y diseño. Se trata pues de un meta-modelo auto-referencial
(cualquier lenguaje de modelado de propósito general debería ser capaz de
modelarse a sí mismo).
UML es un lenguaje estándar que sirve para escribir
los planos del software, puede utilizarse para visualizar,
especificar, construir y documentar todos los artefactos que componen un
sistema con gran cantidad de software. UML puede usarse para modelar desde
sistemas de información hasta aplicaciones distribuidas basadas en Web,
pasando por sistemas empotrados de tiempo real.
UML es solamente un lenguaje por lo que es sólo una
parte de un método de desarrollo software, es independiente del proceso aunque
para que sea optimo debe usarse en un proceso dirigido por casos de uso,
centrado en la arquitectura, iterativo e incremental.
UML es un lenguaje por que proporciona un vocabulario
y las reglas para utilizarlo, además es un lenguaje de modelado lo que
significa que el vocabulario y las reglas se utilizan para la representación
conceptual y física del
sistema.
UML es un lenguaje que nos ayuda a interpretar grandes
sistemas mediante gráficos o mediante texto obteniendo
modelos explícitos que ayudan a la comunicación durante el desarrollo ya que al
ser estándar, los modelos podrán ser interpretados por personas que no
participaron en su diseño (e incluso por herramientas) sin ninguna ambigüedad.
En este contexto, UML sirve para especificar, modelos concretos, no
ambiguos y completos.
Debido a su estandarización y su definición completa
no ambigua, y aunque no sea un lenguaje de programación, UML se puede conectar
de manera directa a lenguajes de programación como Java,
C++ o Visual Basic,
esta correspondencia permite lo que se denomina como ingeniería directa
(obtener el código fuente
partiendo de los modelos) pero además es posible reconstruir un modelo en UML
partiendo de la implementación, o sea, la ingeniería inversa.
UML proporciona la capacidad de modelar actividades
de planificación de
proyectos y de sus versiones, expresar requisitos y las pruebas sobre
el sistema, representar todos sus detalles así como la propia arquitectura.
Mediante estas capacidades se obtiene una documentación que es valida durante
todo el ciclo de vida de
un proyecto.
El lenguaje UML se compone de tres elementos básicos,
los bloques de construcción, las reglas y algunos mecanismos comunes. Estos
elementos interaccionan entre sí para dar a UML el carácter de
completitud y no-ambigüedad que antes comentábamos.
Los bloques de construcción se
dividen en tres partes:
·
Elementos,
que son las abstracciones de primer nivel.
·
Relaciones,
que unen a los elementos entre sí.
·
Diagramas,
que son agrupaciones de elementos.
Existen cuatro tipos de elementos en UML, dependiendo
del uso que se haga de ellos:
·
Elementos estructurales.
·
Elementos de comportamiento.
·
Elementos de agrupación
·
Elementos de anotación.
