Metodología
de James Martin
Esta
metodología de desarrollo de Software es mejor conocida como Metodología RAD
(Rapid Application Development) o Desarrollo rápido de Aplicaciones, y
fue creada por el gurú de computación James Martin en 1991. Está orientada a
disminuir radicalmente el tiempo necesario para diseñar e implementar Sistemas
de Información, el RAD cuenta con una participación intensa del usuario,
sesiones JAD, prototipaje, herramientas CSE integradas y generadores de código.
El Rad requiere cuatro ingredientes esenciales: gerencia, gente, metodologías y
herramientas.
Fases o
Etapas de Metodología RAD de James Martin.
Esta metodología consta de 4 etapas a saber:
1) Etapa de Planificación de Requisitos:
Esta etapa requiere que los usuarios con un vasto conocimiento de los procesos
de la compañía determinen cuáles serán las funciones del sistema. Debe darse
una discusión estructurada sobre los problemas de la compañía que necesitan
solución.
2) Etapa de Diseño: Esta consiste de un
análisis detallado de las actividades de la compañía en relación al sistema
propuesto. Los usuarios participan activamente en talleres bajo la tutela de
los profesionales de la informática. En ellos descomponen funciones y definen
entidades asociadas con el sistema. Una vez se completa el análisis se crean
los diagramas que definen las alteraciones entre los procesos y la data.
3) Construcción: En la etapa de
construcción el equipo de desarrolladores trabajando de cerca con los usuarios
finalizan el diseño y la construcción del sistema. La construcción de la
aplicación consiste de una serie de pasos donde los usuarios tienen la
oportunidad de afirmar los requisitos y repasar los resultados.
4) Implementación: Esta etapa envuelve la
implementación del nuevo producto y el manejo de cambio del viejo al nuevo
sistema. Se hacen pruebas comprensivas y se adiestran los usuarios.
Ventajas y Desventajas de la Metodología RAD
Ventajas | Desventajas
Ahorro dramático de tiempo
durante el desarrollo del sistema.
Mayor velocidad y menores costos pueden repercutir en la calidad del sistema
(p.e., debido a falta de atención en controles internos).
Puede ahorrarse tiempo, dinero
y esfuerzo humano. Peligrosa incoherencia entre el sistema desarrollado y el
negocio, debido a la falta de información o a procesos del negocio
sobreentendidos.
Estrecha correspondencia entre
los requerimientos del usuario y las especificaciones del sistema.
Pueden producirse
inconsistencias entre diseños internos y entre sistemas.
Trabaja muy bien cuando la
velocidad de desarrollo es importante (cambios rápidos de las condiciones del
negocio), o cuando lo sistemas pueden capitalizarse en oportunidades
estratégicas. Posibles violaciones de estándares de programación relacionadas
con nomenclaturas inconsistentes e insuficiente documentación.
Permite cambiar rápidamente el
diseño de los sistemas cuando los usuarios lo demandan Dificultades con el
reuso de módulos para futuros sistemas.
Los sistemas son optimizados
por los usuarios involucrados en el proceso del RAD. Carencia de un diseño
escalable dentro del sistema.
Se concentra en los elementos
esenciales del sistema, desde el punto de vista del usuario. Falta de atención
de la futura administración del sistema dentro de los sistemas existentes
(p.e., falta de integración con el modelo de datos organizacional y facilidades
de recuperación del sistema) . El
usuario se compromete y se hace propietario del sistema. Altos costos de
compromiso por parte del personal clave.
UML
Concepto:
Lenguaje Unificado de Modelado
(LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje
de modelado de sistemas de software más conocido y utilizado en la actualidad;
está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico
para visualizar, especificar, construir y documentar un sistema. UML ofrece un
estándar para describir un "plano" del sistema (modelo), incluyendo
aspectos conceptuales tales como procesos de negocio y funciones del sistema, y
aspectos concretos como expresiones de lenguajes de programación, esquemas de
bases de datos y componentes reutilizables.
Es importante resaltar que UML
es un "lenguaje de modelado" para especificar o para describir
métodos o procesos. Se utiliza para definir un sistema, para detallar los
artefactos en el sistema y para documentar y construir. En otras palabras, es
el lenguaje en el que está descrito el modelo.
Se puede aplicar en el
desarrollo de software entregando gran variedad de formas para dar soporte a
una metodología de desarrollo de software (tal como el Proceso Unificado
Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la
programación estructurada, pues UML significa Lenguaje Unificado de Modelado,
no es programación, solo se diagrama la realidad de una utilización en un
requerimiento. Mientras que, programación estructurada, es una forma de
programar como lo es la orientación a objetos, sin embargo, la programación
orientada a objetos viene siendo un complemento perfecto de UML, pero no por
eso se toma UML sólo para lenguajes orientados a objetos.
Fases en el desarrollo basado en UML
En la versión definitiva de la
metodología publicada por Booch, Rumbaugh y Jacobson se pueden tener en cuenta
las siguientes fases o etapas:
· Análisis de Requerimientos
· Diseño del sistema
· Diseño detallado
· Implementación y pruebas
Cada etapa consta de
actividades que le dan cuerpo y los documentos que se esperan al final de cada
una de ellas.
Cuadro Estructural UMl
El lenguaje UML se expresa con
símbolos y/o agrupaciones de estos llamadas diagramas. Nos sirve
fundamentalmente para crear diferentes tipos de ellos permitiéndonos ver desde
diferentes perspectivas un sistema software.
Existe un tipo primordial que
es “Diagrama UML” del cual heredan “Diagrama Estructural” y “Diagrama
Comportamiento”, de estos a su vez heredan los trece diferentes tipos de
diagramas más comunes, existiendo un tipo intermedio que serían los “Diagrama
de Interacción”.
Diagramas Utilizados en UML:
En UML 2.0 hay 13 tipos
diferentes de diagramas. Para comprenderlos de manera concreta, a veces es útil
categorizarlos jerárquicamente, como se muestra en la figura de la derecha.
Los Diagramas de Estructura
enfatizan en los elementos que deben existir en el sistema modelado:
* Diagrama de clases
* Diagrama de componentes
* Diagrama de objetos
* Diagrama de estructura compuesta (UML 2.0)
* Diagrama de despliegue
* Diagrama de paquetes
Los Diagramas de
Comportamiento enfatizan en lo que debe suceder en el sistema modelado:
* Diagrama de actividades
* Diagrama de casos de uso
* Diagrama de estados
Los Diagramas de Interacción
son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de
control y de datos entre los elementos del sistema modelado:
* Diagrama de secuencia
* Diagrama de comunicación, que es una
versión simplificada del Diagrama de colaboración (UML 1.x)
* Diagrama de tiempos (UML 2.0)
* Diagrama global de interacciones o Diagrama
de vista de interacción (UML 2.0)
Clases y Objetos.
Un objeto es una representación
de una entidad, ya sea real o conceptual, con límites bien definidos y con
significado dentro de un modelo. Cada objeto en un modelo se caracteriza por su
estado, su comportamiento y su identidad.
El estado de un objeto es una
de las posibles condiciones bajo las que el objeto puede existir. El estado de
un objeto cambia con el tiempo y está definido por un conjunto de propiedades
(atributos), por los valores de esas propiedades y por las relaciones que dicho
objeto puede tener con otros objetos.
El comportamiento de un objeto
determina la forma en que responde ante peticiones de otros objetos, y tipifica
todo lo que el objeto puede hacer. El comportamiento de un objeto se
materializa en el conjunto de operaciones definidas para dicho objeto.
La identidad implica que cada
objeto es único, incluso si su estado es idéntico al de otro objeto.
En UML una clase es una
descripción de un grupo de objetos con propiedades comunes (atributos),
comportamiento común (operaciones), relaciones comunes y semántica común. Por
tanto, una clase es una plantilla (template) para la creación de objetos, donde
cada objeto de dicha clase será una instancia de ella (no pudiendo ser
instancia de más de una clase).
Antes de describir los
distintos elementos que forman parte de un diagrama de clases, es importante
aclarar la forma en que dichos diagramas pueden ser utilizados durante el
proceso software. A la hora de confeccionar o interpretar un diagrama de clases
pueden considerarse tres perspectivas:
Conceptual: Permite
representar los conceptos del dominio. Aunque dichos conceptos suelen llevar,
de una forma natural, a las clases que los implementan, puede que no exista una
correspondencia directa.
Especificación: Cuando se
trata de representar las interfaces del software y no el software en sí.
Implementación: Es en esta
perspectiva donde realmente tenemos clases, siendo ésta la perspectiva más
utilizada.
Un diagrama de clases UML
puede ser utilizado desde cualquiera de estas perspectivas, resulta en este
caso conveniente el indicar la perspectiva de la que se trata por medio de
estereotipos.
Diagrama de clases.
Los diagramas de clases son
diagramas de estructura estática que muestran las clases del sistema y sus
interrelaciones (incluyendo herencia, agregación, asociación, etc). Los
diagramas de clase son el pilar básico del modelado con UML, siendo utilizados
tanto para mostrar lo que el sistema puede hacer (análisis), como para mostrar
cómo puede ser construido. El diagrama de clases de más alto nivel (main class
diagram), será lógicamente un dibujo de los paquetes que componen el sistema. A
su vez cada paquete tendrá un main class diagram que muestra las clases del
paquete Las clases se documentan con una descripción de lo que hacen, sus
métodos y sus atributos. Las relaciones entre clases se documentan con una
descripción de su propósito, su cardinalidad (cuantos objetos intervienen en la
relación) y su opcionalidad (cuando un objeto es opcional el que intervenga en
una relación). La descripción de clases complejas se puede documentar con
diagramas de estados.
Expresa condiciones y asociaciones alternativas de una decisión 
Expresa condición y acciones alternativas de una decisión numérica.
Entrada / Salida: Representa cualquier tipo de Fuente de entrada y salida
Entrada: Lectura de datos por tarjeta perforadas.
Conector dentro de página.
Representa resultado mediante un reporte impreso
Conector fuera de página.
Expresa operación cíclica repetitiva.
Expresa proceso de llamada a una subalterna.
Representa datos grabados en una cinta magnética.
Almacenamiento en línea Disco Magnético.
