INFORME ULM

UML es:

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.

UML es el sucesor de la ola de métodos de A y DOO que aparecieron a finales de los 80 y principios de los 90.

UML unifica principalmente los métodos de Booch, Rumbaught (OMT) y Jacobson. Pero pretende dar una visión más amplia de los mismos.

UML es un lenguaje de modelado, no un método.

Importancia de UML

Entre más complejo es el sistema que se desea crear más beneficios presenta el uso

de UML, sin embargo, existen dos puntos claves: El primero se debe a que mediante

un plano/visión global resulta más fácil detectar las dependencias y dificultades

implícitas del sistema, y la segunda razón radica en que los cambios en una etapa

inicial (Análisis) resultan más fáciles de realizar que en una etapa final de un sistema

como lo sería la fase intensiva de codificación

Los beneficios del modelado

Aprender / Entender. 1. En primer lugar hay que destacar que la experiencia demuestra que el

principal beneficio en la generación de un modelo es el entendimiento que el modelador adquiere del comportamiento de la realidad. Puede ocurrir, y de hecho ocurre con frecuencia, que una vez finalizado el modelo, los objetivos perseguidos inicialmente se hayan alcanzado sin hacer ningún tipo de experimento.

2. Es habitual que para desarrollar un modelo se tenga que acceder a información a la que nunca se le habría prestado atención.

3. Una vez construido el modelo, se puede utilizar su ejecución para conocer como el sistema actúa y reacciona.

Implementar en un ordenador.

1. La automatización de procesos exige la modelización previa. Así, solo es posible implementar la contabilidad en un ordenador porque está completamente normalizada.

2. Si se desea gestionar la información que genera una empresa, o implementar un sistema de gestión de recursos humanos es necesario realizar un modelo de dicha empresa que comprenda de la manera más eficiente posible toda la información vinculada.

Toma de decisiones

1. Los modelos construidos permiten mediante su resolución ayudar a la toma de decisiones generando decisiones al problema que optimizan un objetivo establecido.

2. Asimismo pueden ser utilizados para evaluar el impacto de tomar decisiones, antes de tomarlas, y de este modo elegir la que más se ajuste a la solución.

Origen de UML Después de que la Rational Software Corporation contratara a James Rumbaugh de General Electric en 1994, la compañía se convirtió en la fuente de los dos esquemas de modelado orientado a objetos más populares de la época: el OMT (Object-modeling technique) de Rumbaugh, que era mejor para análisis orientado a objetos, y el Método Booch de Grady Booch, que era mejor para el diseño orientado a objetos. Poco después se les unió Ivar Jacobson, el creador del método de ingeniería de software orientado a objetos. Jacobson se unió a Rational en 1995, después de que su compañía Objectory AB fuera comprada por Rational. Los tres metodologistas eran conocidos como los Tres Amigos, porque se sabía de sus constantes argumentos sobre las prácticas metodológicas. En 1996 Rational concluyó que la abundancia de lenguajes de modelado estaba alentando la adopción de la tecnología de objetos, y para orientarse hacia un método unificado, encargaron a los Tres Amigos Bajo la dirección técnica de los Tres Amigos fue organizado un consorcio internacional llamado UML Partners en 1996 para completar las especificaciones del Lenguaje Unificado de Modelado (UML), El resultado de este trabajo, el UML 1.1, fue presentado ante la OMG en agosto de 1997 y adoptado por la OMG en noviembre de 1997. Métodos en los que está basado: Los métodos particulares en los que se basa (principalmente Booch, OMT y OOSE).

Los objetivos de UML 1. Expresar de una forma gráfica un sistema de manera tal que otros lo puedan

entender. 2. Permite especificar cuáles son las características de un sistema antes de su

construcción. 3. A partir de estos puntos, permite la construcción del diseño del sistema. 4. Permite que los propios elementos gráficos sirvan como documentación del

sistema desarrollado y que así estos pueden servir para futuras revisiones. El futuro de UML Ivar Jacobson y Steve Cook han escrito un artículo en Dr. Dobbs journal dando su opinión acerca del futuro del UML. Básicamente puede resumirse en una frase: “Para el 80% de todo el software sólo hace falta un 20% de lo que es el UML actual”. Por supuesto, lo difícil es decidir cuál es este 20% (que además va a depender del dominio de aplicación).

Ciclos de vida del software

Cualquier producto a desarrollar tiene un comienzo y un fin. Así, el software tiene una vida, un ciclo de vida, que determina qué tipo de producto se tendrá. Este ciclo está compuesto de distintas etapas, y puede ser muy variado dependiendo de lo que se quiere construir, de su tamaño, del presupuesto, de la capacidad del equipo, de la experiencia de los desarrolladores, etc.

Etapas del ciclo de vida

Las etapas que constituyen el Ciclo de Vida pueden variar, según el autor que se consulte; sin embargo, como mínimo deben estar contemplados los siguientes elementos:

1. Planeación: Especificaciones iniciales, factibilidad

2. Desarrollo: Construcción del software

3. Operación: Uso del sistema

4. Mantenimiento: Corrección y actualización

El Ciclo de Vida más tradicional contempla:

1. Análisis de Requerimientos

2. Especificación

3. Diseño

4. Implementación

5. Integración

6. Mantenimiento

7. Retiro

Análisis de Requerimientos

El equipo de desarrollo se reúne con el Cliente para entender la problemática y lo que se espera que resuelva “el software”. El entregable esperado en esta etapa es un documento que concentre los REQUERIMIENTOS DEL USUARIO.

Especificación

Considerando los Requerimientos, se genera una especificación de la “funcionalidad” a ser incluida. Además establece una metodología de desarrollo y una estimación de tiempos y costos.

Diseño

Tomando la especificación funcional, los diseñadores generan el diseño detallado y la arquitectura general del software, así como la interfaz para el usuario.

Implementación

Basados en el diseño, los programadores codifican todos los componentes relacionados.

Integración

Los componentes y módulos se combinan y prueban.

Ciclo de Vida (SDLC)

Mantenimiento

Una vez aceptado el producto original, cualquier modificación posterior se considera como mantenimiento.

Retiro

Cuando el producto es eliminado.

Mantenimiento de Software

Tipos de actividades durante el mantenimiento de software:

1. Corregir errores (mantenimiento correctivo)

2. Adaptación (revisión, funciones)

3. Perfectivo (mejoras o modificaciones)

4. Preventivo (reingeniería)

Problemas en el mantenimiento

1. Es difícil o imposible seguir el proceso de evolución del software a través de varias versiones. Los cambios no están documentados adecuadamente.

2. Es muy difícil entender el programa de “alguien” más.

3. Ese “alguien” muy a menudo no se encuentra para explicarlo, debido a la rotación de personal.

4. La documentación no existe o es inadecuada.

5. Mucho software no está diseñado para el cambio.

El ciclo de vida más difundido y el único utilizado hasta los años 80’s, es el conocido como “cascada”. El ciclo de vida de cascada consiste, fundamentalmente, de las etapas de análisis de requerimientos, diseño, construcción, pruebas e implantación. Una etapa inicial hasta que termina la anterior con actividades de validación de los entregables al final de cada etapa. Está basado en documentos y obliga a la formalidad, atacando de esta manera desventajas del ciclo de construir y corregir. Sin embargo, tiende a ser muy largo y dada que una etapa no inicia hasta que la anterior termina, la retroalimentación del cliente es tardía y muchos de los proyectos utilizando este ciclo de vida fallan por no haber entendido los requerimientos del usuario (documentos ambiguos y difíciles de leer) y por lo tanto, generando un producto que el cliente no necesita y no va a utilizar. Otro problema con este ciclo de vida es que ignora que los requerimientos no son estáticos sino que cambian rápidamente y que el producto generado debe irse ajustando a dichos cambios.

A fin de garantizar que los requerimientos sean claros y que el producto se ajuste a cambios en éstos, se han creado otros ciclos de vida como los siguientes:

1. Prototipo rápido

2. Incremental

3. Evolutivo

4. Espiral

Acorde con Craig Larman (2005) el ciclo de vida iterativo y evolutivo consiste de una

serie de iteraciones cortas y fijas en duración (entre dos y seis semanas).

Los principales beneficios de este tipo de desarrollo son: [Larman, 2005]:

Menor probabilidad de que el proyecto falle. Mayor productividad. Mitigación de riesgos en iteraciones tempranas. Progreso visible en un corto tiempo. Retroalimentación oportuna. En cada iteración se genera conocimiento que permitirá mejorar las

subsecuentes iteraciones.