Análisis de Sistemas

Administrativos
Unidad 2.1
Facultad de Tecnología Informática UAI

UML y el Proceso
de Desarrollo de Software
 Programa de la Asignatura
1.1. Análisis y diseño OO
2.1. Proceso de desarrollo de software. 1º parte
3.1. Casos de uso
3.2. Diagramas de clases.
3.3. Diagramas de colaboración.
3.4. Diagramas de secuencia.
4.1. Lenguaje de restricción de objetos.
5.1. Patrones de Diseño.
6.1. Transformación del Modelo de Clases al
Modelo ER
 UML
¿Qué son los modelos?
¿Para qué sirven los modelos?
¿Cuáles son los modelos de UML?
¿Se usan todos...?
 ¿Qué son los modelos?

Un modelo es una representación que capta los aspectos

más importantes de lo que estamos modelando y simplifica u
omiten el resto

Es la representación de una abstracción

Un modelo de un sistema software está construido en un

lenguaje de modelado. Tiene semántica y notación. Incluye
gráficos y texto
 ¿Para qué sirven los modelos?

● Para pensar el diseño de un sistema

La simplicidad de crear y de modificar modelos
permite un pensamiento creativo e innovación a
bajo precio

● Para explorar económicamente múltiples soluciones

● Para trabajar con sistemas complejos

 Historia de UML

● UML (Unified Modeling Language) es un lenguaje

que permite modelar, construir y documentar los
elementos que forman un sistema software
orientado a objetos. Se ha convertido en un
estándar , debido a que ha sido concebido por los
autores de los tres métodos más usados de
orientación a objetos: Grady Booch, Ivar Jacobson
y Jim Rumbaugh. Estos autores fueron contratados
por la empresa Rational Software Co. para crear una
notación unificada en la que basar la construcción de
sus herramientas CASE. En el proceso de creación
de UML han participado, no obstante, otras empresas
de gran peso en la industria como Microsoft,
 Logo de UML
. Desarrollo Orientado a Objetos con UML
El objetivo principal cuando se empezó a gestar UML
era posibilitar el intercambio de modelos entre las
distintas herramientas CASE orientadas a objetos del
mercado. Para ello era necesario definir una notación y
semántica común..
En la figura se puede ver cuál ha sido la evolución de UML hasta la
creación de UML 1.1.
Esta primera versión se ofreció a un grupo de
trabajo en 1997 para convertirlo en un estándar
del OMG (Object Management Group) . Object
Management Group) es un consorcio con más de
700 compañías con el objetivo de proveer una
estructura común (estándares) para el desarrollo
de aplicaciones usando técnicas de programación
orientada a objetos. La versión de UML 1.1, fue
adoptada por el OMG como estándar en
noviembre de 1997. Desde aquella versión han
habido varias revisiones que gestiona la OMG. La
última versión aprobada es la UML 2.0
superstructure. En estos momentos se están
 Diagramas UML
State
State
Diagrama
Use Case Diagrams
Use Case
Diagrama Diagrams
s de State
Use Case Diagrams State
Diagrama
Use Case
Diagrama Diagrams
s de Clases Diagrams
Diagrams Diagrams
s de
Diagrams
s de Casos de
Objetos
Secuenci Uso
a
Scenario State
Scenario
Diagrama State
Diagrama
Diagrams Diagrams
Diagrams
s de Diagrams
s de
Mode
Comunic Compone
lo
acion ntes
Scenario Component
Scenario
Diagrama Diagrama
Component
Diagrams
Diagrams Diagrams
Diagrams
s de Diagrama s de
Estados s de Desplieg
Actividad ue
 Diagrama de Casos de Uso

Muestra las distintas operaciones que se esperan de un

sistema y cómo se relacionan con su entorno
 Diagrama de Clases

Muestra las distintas las clases atributos,

métodos y relaciones entre ellas
Diagramas de Secuencia (objetos)

Muestra la interacción de un conjunto de objetos

en una aplicación a través del tiempo
Proceso de Unificado de
Desarrollo
 Proceso Unificado de desarrollo
UML no es un proceso...
...UML es una notación
Distintos ciclos de vida (procesos de desarrollo):
● Ciclo de Vida en Cascada Incluye no solo las etapas
de ingeniería sino toda la vida del producto, es decir,
la vida útil del software y el mantenimiento, hasta que
llega el momento de sustituirlo
● Ciclo de Vida de Prototipos Se hará hincapié mas en
la forma y apariencia que en el contenido y será
aprobado por el usuario.
● Ciclo de Vida en Espiral Incorpora el factor de “riesgo
del proyecto” al modelo de ciclo de vida
 Proceso Unificado (PU)

Proceso de Desarrollo de
Software
Conjunto de actividades para
transformar los requisitos del
usuario en un sistema
software

Proceso Unificado (UP)

● Dirigido por Casos de Uso

● Centrado en la Arquitectura
● Iterativo e Incremental
 Dirigido por Casos de Uso
● Los casos de uso
representan los requisitos
funcionales
(características,
capacidades) y guían el
diseño, la implementación
y la prueba

● Basándose en los casos

de uso los desarrollares
crean modelos de diseño
e implementación que
 Centrado en la Arquitectura
● La arquitectura es una vista
de diseño con las
características más
importantes, dejando los
detalles de lado. Describe
diferentes vistas del sistema

● Constituyen la “forma del

sistema”, incluye aspectos
estáticos y dinámicos

● La arquitectura y los casos de

 Iterativo e Incremental/1
● Desarrollo iterativo:

El desarrollo se organiza en una serie de mini proyectos

de duración fija, llamados iteraciones (2 a 6
semanas)

● El resultado de cada uno es un sistema que puede

ser probado, integrado y ejecutado.

● Cada iteración incluye sus propias actividades de:

análisis de requisitos, diseño, implementación y
prueba
 Iterativo e Incremental/2
● Desarrollo incremental:
El sistema crece incrementalmente a lo largo del tiempo,
iteración tras iteración.

● El resultado de cada iteración es un sistema ejecutable,

pero incompleto

● En general, cada iteración aborda nuevos requisitos y

amplia el sistema incrementalmente

● La salida de una iteración NO es un prototipo

desechable, es un subconjunto de calidad del sistema
final
 Desarrollo iterativo e incremental
La
Requisitos Requisitos
retroalimentación
tiemp de la iteración N
Diseño Diseño nos lleva a refinar
Implementación
o Implementación y adaptar
Prueba Prueba los requisitos
Integración y mas Integración y mas y diseño de la
Diseño Diseño iteración N+1
Integración Final Integración Final
Y Pruebas de Y Pruebas de
Sistema Sistema

4 semanas (por
ej.)

Se fija la El sistema crece

de
duración
manera
de las
 Disciplinas y fases
Disciplina: conjunto de
actividades y artefactos
vinculados en una área
determinada: requisitos,
diseño, implementación,
etc.

Fases: periodo de
tiempo entre dos hitos
principales de un
proceso de desarrollo
 Fases del Proceso Unificado
● Inicio: visión aproximada,
incluye: análisis del negocio,
alcance, estimaciones
imprecisas

● Elaboración: visión refinada,

implementación iterativa del
núcleo central de la
arquitectura, resolución de
riesgos altos, identificación de
más requisitos

● Construcción:
implementación iterativa del
Fase de inicio
 Fase de inicio/1

● Actividades a realizar (una o algunas)

● Visión y análisis del negocio (objetivos y

restricciones de alto nivel)
● Modelo de casos de uso (requisitos funcionales y
no funcionales relacionados)
● Especificaciones complementarias (otros
requisitos)
● Listas de riesgos (del negocio, técnicos, etc.)
● Prototipos (para clarificar la visión)
● Plan de iteración (qué hacer en la primera iteración)
 Fase de inicio/2

●No se entendió la fase de inicio si...

○La duración es mayor a unas pocas
semanas
○Se intenta definir la mayoría de los
requisitos
○Se espera que los planes y la estimación
sea fiable
○Se define la arquitectura
○No se identifican la mayoría de de los
nombres de los casos de uso y los actores
○Se escribieron todos los casos de uso en
Fase de
elaboración
 Fase de elaboración/1
● Actividades a realizar
○ Se descubren y estabilizan la mayoría de los
casos de uso
○ Se reducen o eliminan los riesgos importantes
○ Se implementan y prueban los elementos básicos
de la arquitectura
○ Duración: 2 a 4 iteraciones con una duración de 2
a 6 semanas (dependiendo de la duración del
proyecto)
 Fase de Elaboración/2
● Artefactos de la fase de elaboración
○ Modelo del dominio (entidades del dominio)
○ Modelo de diseño (diagramas de clases, de
iteración. etc)
○ Modelo de datos
○ Modelo de pruebas
○ Modelos de implementación

El producto resultante no es un prototipo desechable

El código y el diseño son de calidad y se integran al
sistema final
 Fase de Elaboración/3

● No se entendió la fase de elaboración si...

○ Sólo comprende una iteración
○ La mayoría de los requisitos se definieron antes de
la elaboración
○ NO hay programación de código ejecutable
○ Se intenta llevar a cabo un diseño completo antes
de la codificación
○ Los usuarios no se involucran en la evaluación
Fase de
construcción
 Fase de Construcción

● Objetivos
○ Terminar de construir la aplicación
○ Realizar pruebas alfa
○ Preparar pruebas beta (para la transición)
○ Preparación de guías de usuario
○ Preparación de materiales de aprendizaje
Fase de
transición
 Fase de Transición

Objetivo: poner el sistema en producción

● Actividades
○ Realización de pruebas beta
○ Reaccionar a la retroalimentación a partir de las
pruebas beta
○ Conversión de datos
○ Cursos de entrenamiento
 Bibliografía Básica

Larman C. UML y patrones. Una introducción al Análisis

y Diseño Orientado a Objetos y al Proceso Unificado. 2ª
ed. Madrid: Prentice-Hall; 2003.

Jacobson I. Booch G. Rumbaugh J. El Proceso de

Desarrollo Unificado. Addison-Wesley. 2000
 Sugerencias
● Recuerde que cada fase, si bien pasa por todas las disciplinas
(análisis, diseño, etc.) pone énfasis en algunas de ellas más que en
otras

● Valore la importancia de los casos de uso (unidad 3.1). A partir de

ellos se crean todos los demás modelos del sistema

● Tenga en cuenta que después de cada iteración (que corresponde

aproximadamente a un ciclo de vida en cascada) se va definiendo un
sistema ejecutable, pero incompleto, que debe corroborar con el
usuario

● Recuerde que inicio no es igual a requisitos, elaboración no es igual

a análisis y construcción no es igual a diseño, etc

● Recuerde que cada iteración tiene un duración fija de 2 a 6 semanas

aproximadamente
 Auto evaluación/1

Comprendí los conceptos más

importantes de la unidad 1.1 si
puedo definir y dar ejemplos de:

● Disciplinas / Fases
● Fase de inicio
● Fase de elaboración
● Fase de construcción
● Fase de transición
● Desarrollo iterativo e incremental

● Interpreto en el gráfico que

significan las “montañitas”
 Auto evaluación/2

Comprendí los conceptos más importantes de la unidad 1, si

● Entiendo la diferencia entre el ciclo de vida en cascada y el UP

● Comprendo la relación que existe entre disciplinas de UP y el

ciclo de vida en cascada

● Entiendo que tienen en común el ciclo de vida en espiral y el UP

● Comprendo en que hacen énfasis cada una de las fases del UP

● Entiendo en que termina cada iteración

 2º parte
Proceso de desarrollo
“simplificado”
 Comenzamos con
los casos de uso.
Inicialmente el
nombre
y una descripción

Primera
iteración
ETAPA DE
INICIO
 Describimos
los casos de uso
con
mayor detalle.

Escenario principal

El cliente ingresa a la pagina Web de CVLI

Primera iteración
El cliente ingresa a la opción “registración “
El sistema solicita ingreso de los datos
ETAPA DE
personales
ELABORACIÓN El sistema evalúa el país….
…..
 Creamos los
diagramas
de secuencia de
sistemas
para cada caso de uso.

Escenario principal
Primera iteración
El cliente ingresa a la pagina Web de CVLI
ETAPA DE El cliente ingresa a la opción “registración “
El sistema solicita ingreso de los datos
ELABORACIÓN
personales
 Creamos el modelo
del dominio:
CLASES,
ASOCIACIONES,
ATRIBUTOS

Primera iteración
ETAPA DE
ELABORACIÓN
 Asignamos
responsabilidades
a las clases, asistidos
por los patrones de
ASIGNACION DE
RESPONSABILIDADE
S

Primera iteración
ETAPA DE
ELABORACIÓN
 Transformamos
el modelo de
clases a un
modelo de
datos y luego al
modelo
relacional

Primera iteración
ETAPA DE
ELABORACIÓN
 Codificamos y
probamos.

Mostramos el
ejecutable al usuario

public class AdaptadorFigura extends Figura

{
private int x;
Primera iteración
public AdaptadorFigura()
ETAPA DE { variables
ELABORACIÓN x = 0; }
}
 Comenzamos
una nueva
iteración
trabajando con
nuevos casos de
uso (o
mejorando los
anteriores)

Segunda
iteración
ETAPA DE
ELABORACIÓN
Fin