UML

UNIFIED MODELING
LANGUAGE
Y
LAS METODOLOGÍAS DE
DESARROLLO DE SOFTWARE

Ing. Manuel Antonio Curto Molano

 HISTORIA DE UML

El lenguaje UML comenzó a gestarse en octubre de 1994, cuando

Rumbaugh se unió a la compañía Rational fundada por Booch
(dos respetados investiga-dores en el área de metodología del
software).

El objetivo de ambos era unificar dos métodos que habían

desarrollado: el método Booch y el OMT (Object Mode-lling Tool ).
Se necesitaba por tanto un lenguaje no sólo para comunicar las
ideas a otros desarrolladores sino también para servir de apoyo en
los procesos de análisis de un problema.
Con este objetivo se creo el Lenguaje Unificado de Modelado
(UML: Unified Modeling Language). UML se ha convertido en ese
estándar tan ansiado para representar y modelar la información con
la que se trabaja en las fases de análisis y, especialmente, de diseño.
 ¿QUÉ ES UML?

UML es ante todo un lenguaje. Un lenguaje proporciona un

vocabulario y una reglas para permitir una comunicación. En este
caso, este lenguaje se centra en la representación gráfica de un
sistema.

UML es un lenguaje de modelado para especificar el análisis y

diseño de sistemas orientados objetos

Este lenguaje nos indica cómo crear y leer los modelos, pero no
dice cómo crearlos. Esto último es el objetivo de las
metodologías de desarrollo.
 Objetivos
Los objetivos de UML son muchos, pero se pueden sintetizar
sus funciones:

 Visualizar:

UML permite expresar de una forma gráfica un sistema de

forma que otro lo puede entender.

 Especificar:

UML permite especificar cuáles son las características de

un sistema antes de su construcción.
 Construir:

A partir de los modelos especificados se pueden construir

los sistemas diseñados.

 Documentar:

Los propios elementos gráficos sirven como documentación

del sistema desarrollado que pueden servir para su futura
revisión.
 Bloques

Un modelo UML esta compuesto por tres clases de bloques de

construcción:

 Elementos:

Los elementos son abstracciones de cosas reales o ficticias

(objetos, acciones, etc.)

 Relaciones:

Relacionan los elementos entre sí.

 Diagramas:

Son colecciones de elementos con sus relaciones.

 MODELADO VISUAL

Tal como indica su nombre, UML es un lenguaje de modelado.

Un modelo es una simplificación de la realidad.

El objetivo del modelado de un sistema es capturar las partes

esenciales del sistema.
Para facilitar este modelado, se realiza una abstracción y se
plasma en una notación gráfica. Esto se conoce como modelado
visual.
El modelado visual permite manejar la complejidad de los
sistemas a analizar o diseñar.

UML sirve para el modelado completo de sistemas complejos,

tanto en el diseño de los sistemas software como para la
arquitectura hardware donde se ejecuten.
 Ventajas

UML es además un método formal de modelado. Esto aporta

las siguientes ventajas:

 Mayor rigor en la especificación.

 Permite realizar una verificación y validación del modelo

realizado.

 Se pueden automatizar determinados procesos y permite

generar código a partir de los modelos y a la inversa (a partir
del código fuente generar los modelos).
 DIAGRAMAS UML

Un diagrama es la representación gráfica de un conjunto de

elementos con sus relaciones.

En concreto, un diagrama ofrece una vista del sistema a

modelar.
Para poder representar correctamente un sistema, UML ofrece
una amplia variedad de diagramas para visualizar el sistema
desde varias perspectivas. UML incluye los siguientes
diagramas:
 Diagrama de casos de uso:

Representa gráficamente los casos de uso que tiene un

sistema.
Se define un caso de uso como cada interacción supuesta con
el sistema a desarrollar, donde se representan los requisitos
funcionales.
Es decir, se está diciendo lo que tiene que hacer un sistema
y cómo.
 Diagrama de clases:

Muestra un conjunto de clases, interfaces y sus

relaciones.

Éste es el diagrama más común a la hora de describir el

diseño de los sistemas orientados a objetos.
Se muestran las clases globales, sus atributos y las
relaciones de una posible solución al problema de la
venta de entradas.
 Diagrama de objetos:

Diagrama que muestra una vista completa o parcial de

los objetos de un sistema en un instante de ejecución
específico.
Un diagrama de objetos es un gráfico de instancias,
incluyendo objetos y datos. Un diagrama de objetos es una
instancia de un diagrama de clases; muestra una 'foto' del
estado de un sistema en un punto de tiempo determinado."

Los diagramas de objeto están ligados a los diagramas de

clase y comparten virtualmente los mismos símbolos para la
notación. Los diagramas de objetos pertenecen a la categoría
de diagramas estructurales en UML.
 Diagrama de secuencia:

Se muestra la interacción de los objetos que componen un

sistema de forma temporal.

Siguiendo el ejemplo de venta de entradas

 Diagrama de colaboración:

Es esencialmente un diagrama que muestra interacciones

organizadas alrededor de los roles. A diferencia de los
diagramas de secuencia, los diagramas de colaboración,
también llamados diagramas de comunicación, muestran
explícitamente las relaciones de los roles

Muestra cómo las instancias específicas de las clases

trabajan juntas para conseguir un objetivo común

Implementa las asociaciones del diagrama de clases

mediante el paso de mensajes de un objeto a otro. Dicha
implementación es llamada "enlace".
 Diagrama de estados:

son una técnica conocida para describir el comportamiento de

un sistema. Describen todos los estados posibles en los que
puede entrar un objeto particular y la manera en que cambia
el estado del objeto, como resultado de los eventos que llegan
a él.

En la mayor parte de las técnicas OOP, los diagramas de

estados se dibujan para una sola clase, mostrando el
comportamiento de un solo objeto durante todo su ciclo de
vida.
 Diagrama de actividades:

Los diagramas de actividades son particularmente útiles para

la descripción del comportamiento que tiene una gran
cantidad de proceso paralelo

Permite seleccionar el orden en que se harán las cosas.

Indica las reglas esenciales de secuenciación que tengo que

seguir. Ésta es la diferencia clave entre un diagrama de
actividades y un diagrama de flujo. Los diagramas de flujo se
limitan normalmente a procesos secuenciales; los diagramas
de actividades pueden manejar procesos paralelos.
 Diagrama de componentes:

Un componente es una unidad modular que puede

reemplazarse en su propio entorno

Un componente también puede tener interfaces necesarias .

En una interfaz necesaria, se definen las funciones o
servicios de otros componentes que son necesarios
Un componente es una parte física de un sistema (modulo,
base de datos, programa ejecutable, etc.)

Se puede decir que un componente es la materialización de

una o mas clases, porque una abstracción con atributos y
métodos pueden ser implementados en los componentes
 Diagrama de despliegue:

Un Diagrama de Despliegue modela la arquitectura en tiempo

de ejecución de un sistema además es un Lenguaje Unificado
de Modelado que se utiliza para modelar el hardware
utilizado en las implementaciones de sistemas y las relaciones
entre sus componentes.
 Metodologías de Desarrollo de Software.

Las Metodologías de Desarrollo de Software surgen ante la

necesidad de utilizar una serie de procedimientos, técnicas,
herramientas y soporte documental a la hora de desarrollar
un producto software.

Dichas metodologías pretenden guiar a los desarrolladores

al crear un nuevo software, pero los requisitos de un
software a otro son tan variados y cambiantes, que ha dado
lugar a que exista una gran variedad de metodologías para
la creación del software.

Se podrían clasificar en dos grandes grupos:

 Las metodologías orientadas al control de los procesos

Estableciendo rigurosamente las actividades a desarrollar,

herramientas a utilizar y notaciones que se usarán. Estas
metodologías son llamadas Metodologías Pesadas

Las metodologías orientadas a la interactuacción con el

cliente y el desarrollo incremental del software

Mostrando versiones parcialmente funcionales del

software al cliente en intervalos cortos de tiempo, para que
pueda evaluar y sugerir cambios en el producto según se va
desarrollando. Estas son llamadas Metodologías
ligeras/ágiles.
 Metodologías Pesadas.

Son las más tradicionales, se centran en la definición

detallada de los procesos y tareas a realizar, herramientas a
utilizar, y requiere una extensa documentación, ya que
pretende prever todo de antemano.

Este tipo de metodologías son mas eficaces y necesarias

cuanto mayor es el proyecto que se pretende realizar
respecto a tiempo y recursos que son necesarios emplear,
donde una gran organización es requerida.
 Una de las metodologías pesadas más conocidas y utilizadas es
la Metodología RUP (Rational Unified Process) que divide el
desarrollo en 4 fases que definen su ciclo de vida:
 Inicio :
El objetivo es determinar la visión del proyecto y definir lo
que se desea realizar.
 Elaboración :
Etapa en la que se determina la arquitectura óptima del
proyecto.
 Construcción :

Se obtiene la capacidad operacional inicial.

 Transmisión :
Obtener el producto acabado y definido.
 La metodología RUP tiene 6 principios clave

 Adaptación del proceso :

El proceso debe adaptarse a las características de la

organización para la que se esta desarrollando el software.
 Balancear prioridades :
Debe encontrarse un balance que satisfaga a todos los
inversores del proyecto.

 Colaboración entre equipos :

Debe haber una comunicación fluida para coordinar
requerimientos, desarrollo, evaluaciones, planes , resultados,
etc.
 Demostrar valor iterativamente :

Los proyectos se entregan, aunque sea de una forma interna, en

etapas iteradas. En cada iteración se evaluará la calidad y
estabilidad del producto y analizará la opinión y sugerencias de
los inversores.
 Elevar el nivel de abstracción:

Motivar el uso de conceptos reutilizables.

 Enfocarse en la calidad :
La calidad del producto debe verificarse en cada aspecto de la
producción.
 Disciplina de desarrollo de RUP.

Determina las etapas a realizar durante el proyecto de creación

del software.

 Ingeniería o modelado del negocio:

Analizar y entender las necesidades del negocio para el cual

se está desarrollando el software.

 Requisitos:

Proveer una base para estimar los costos y tiempo de

desarrollo del sistema.
 Análisis y diseño :

Trasladar los requisitos analizados anteriormente a un sistema

automatizado y desarrollar una arquitectura para el sistema.
 Implementación:
Crear software que se ajuste a la arquitectura diseñada y que
tenga el comportamiento deseado.

 Pruebas :
Asegurarse de que el comportamiento requerido es correcto
y que todo lo solicitado está presente.

 Despliegue:
Producir distribuciones del producto y distribuirlo a los
usuarios.
 Disciplina de soporte RUP.

Determina la documentación que es necesaria realizar durante

el proyecto.

 Configuración y administración del cambio:

Guardar todas las versiones del proyecto.

 Administración del proyecto :

Administrar los horarios y recursos que se deben de

emplear.
 Ambiente :

Administrar el ambiente de desarrollo del software.

 Distribución :
Hacer todo lo necesario para la salida del proyecto.
 Elementos del RUP.

 Actividades:
Procesos que se han de realizar en cada etapa/iteración.

 Trabajadores:
Personas involucradas en cada actividad del
proyecto.

 Artefactos:

Herramientas empleadas para el desarrollo del

proyecto. Puede ser un documento, un modelo, un
elemento del modelo, etc.
 Metodologías Ágiles.
Esta metodología nace en febrero del 2001 en una reunión
celebrada en UtahEEUU.

Principales ideas de la metodología ágil:

 Se encarga de valorar al individuo y las iteraciones del
equipo más que a las herramientas o los procesos utilizados.

 Se hace mucho más importante crear un producto software

que funcione que escribir mucha documentación.

 El cliente está en todo momento colaborando en el

proyecto.
 Es más importante la capacidad de respuesta ante un
cambio realizado que el seguimiento estricto de un plan.
 Programación Extrema o XP (EXTREME
PROGRAMMING).

Es una metodología para el desarrollo de software y consiste

básicamente en ajustarse estrictamente a una serie de reglas que
se centran en las necesidades del cliente para lograr un producto
de buena calidad en poco tiempo.
La Programación Extrema es una metodología ágil centrada
en potenciar las relaciones interpersonales como clave para el
éxito en el desarrollo de software.
Este tipo de método se basa en una realimentación continuada
entre el cliente y el equipo de desarrollo con una
comunicación fluida entre todos los participantes, también
busca simplificar las soluciones implementadas y coraje para
los múltiples cambios.
 Roles de la Programación Extrema (XP).

Según la propuesta de Beck los roles que nos podemos

encontrar son los siguientes:
 Programador :
El programador escribe las pruebas unitarias y produce
el código del sistema.

 Cliente :
Escribe las historias de los usuarios y las pruebas
funcionales para validar su implementación. El cliente
da una gran prioridad a las historias de usuarios y
decide cual implementar en cada iteración centrándose
en aportar mayor valor al negocio.
  Encargado de Pruebas (Tester) :

Ayuda al cliente a escribir las pruebas funcionales. Se

encarga de ejecutar las pruebas con regularidad, difunde los
resultados obtenidos al equipo y es el responsable de las
herramientas que dan soporte a las pruebas.
 Encargado de Seguimiento (Tracker) :
Es el que proporciona la realimentación al equipo. Realiza
el seguimiento del proceso de cada iteración y verifica el
grado de acierto entre las estimaciones realizadas y el
tiempo real dedicado en ello para la mejora de futuras
estimaciones.
 Entrenador (Coach) :

Es el responsable del proceso global. Se encarga de proveer

guías al equipo de forma que se apliquen las practicas XP y se
vaya siguiendo el proceso correctamente.

 Consultor :

Es un miembro externo del equipo con un conocimiento

especifico en algún tema que es necesario para el proyecto, en
el que surjan problemas.
 Gestor (Big boss) :
Es el vinculo entre clientes y programadores, ayuda a que el
equipo trabaje efectivamente creando las condiciones
adecuadas. Su labor esencial es la de coordinación.
 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.
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.

Un ejemplo de una metodología de desarrollo en cascada es:

 Análisis de requisitos  Verificación

 Mantenimiento
 Diseño del Sistema.
 Diseño del Programa
 Codificación.
 Pruebas
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.
 Modelo de prototipos

El Modelo de prototipos, en Ingeniería de software, pertenece a

los modelos de desarrollo evolutivo. El prototipo debe ser
construido en poco tiempo, usando los programas adecuados y no
se debe utilizar muchos recursos.

Etapas

 Plan rápido.
 Modelado, diseño rápido
 Construcción del Prototipo
 Desarrollo, entrega y retroalimentación
 Comunicación
 Entrega del desarrollo final
 Ventajas

Este modelo es útil cuando el cliente conoce los objetivos

generales para el software, pero no identifica los requisitos
detallados de entrada, procesamiento o salida.
También ofrece un mejor enfoque cuando el responsable del
desarrollo del software está inseguro de la eficacia de un
algoritmo, de la adaptabilidad de un sistema operativo o de la
forma que debería tomar la interacción humano-máquina Se
puede reutilizar el código
 Desarrollo iterativo y creciente
Desarrollo iterativo y creciente (o incremental) es un proceso
de desarrollo de software creado en respuesta a las debilidades
del modelo tradicional de cascada.

Básicamente este modelo de desarrollo, que no es más que un

conjunto de tareas agrupadas en pequeñas etapas repetitivas
(iteraciones), es uno de los más utilizados en los últimos tiempos
ya que, como se relaciona con novedosas estrategias de
desarrollo de software y una programación extrema, es empleado
en metodologías diversas.
 Ventajas del desarrollo iterativo

 En el desarrollo de este modelo se da la retroalimentación

muy temprano a los usuarios.
 Permite separar la complejidad del proyecto, gracias a su
desarrollo por parte de cada iteración o bloque.
 El producto es consistente y puntual en el desarrollo.
 Los productos desarrollados con este modelo tienen una
menor probabilidad de fallar.
 Se obtiene un aprendizaje en cada iteración que es aplicado
en el desarrollo del producto y aumenta las experiencias para
próximos proyectos
 Desarrollo en espiral
El desarrollo en espiral es un modelo de ciclo de vida del
software definido por primera vez por Barry Boehm en
1986,1 utilizado generalmente en la Ingeniería de software. Las
actividades de este modelo se conforman en una espiral, en la
que cada bucle o iteración representa un conjunto de actividades.
Las actividades no están fijadas a ninguna prioridad, sino que las
siguientes se eligen en función del análisis de riesgo,
comenzando por el bucle interior.