Facultad de Ingeniería

Escuela profesional de Ingeniería de sistemas

Ingeniería de Software I

Ing. Oscar Ascón Valdivia

oasconval@hotmail.com
1
 El Lenguaje
Unificado de
Modelado

2
El Triángulo de Desarrollo de Software

Proceso

Herramienta
Notació Visual
n

3
 El Lenguaje Unificado de Modelado

Definición:

El UML es un lenguaje gráfico para la

especificación, visualización, construcción y
documentación de modelos orientados a objetos
que representan sistemas intensivos en software.

= Unified Modeling
Language

UML no es un método sino un lenguaje de

modelamiento
4
 Objetivo del UML

Describir cualquier tipo de sistema en

términos de diagramas orientados a objetos
Algunas categorías de Sistemas

Sistemas de Información
Sistemas de Tiempo Real
Sistemas de Conocimiento
Sistemas Distribuidos
Sistemas de Negocios

5
 UML toma lo mejor de varios métodos

Rumbaugh
Booch Jacobson

Odell
Clasificación Meyer
Pre y Post condiciones

Shlaer-Mellor
Ciclo de vida de objetos
Harel
Máquinas de estado
Gamma et. al.
Marcos de trabajo,
patrones, notas
Embly Wirfs-Brock
Singleton clases Responsabilidades
Fusion
Descripción de operaciones,
numeración de mensajes

6
 Características del UML

- Proporciona a los desarrolladores un lenguaje de

modelamiento ampliamente aceptado y listo para usar.
- Integra las mejores prácticas del desarrollo de software.
- Permite el intercambio de modelos entre las diferentes
herramientas de software.
- Es independiente del lenguaje de programación y de
métodos y procesos particulares de desarrollo de
software.
- Proporciona sus propios mecanismos de extensión
- Agrupa los conceptos de orientación a objetos definiendo
su significado.

7
 Por qué aprender UML
-Porque UML es el lenguaje de modelado de objetos
estándar dominante.
-Porque es apoyado por metodólogos y empresas
importantes en Tecnologías de Información.
-Porque cuenta con la aprobación de la OMG como
notación estándar.
-Porque todas las herramientas modernas proporcionan
soporte para UML.
-Porque nos facilita el aprendizaje del enfoque orientado
a objetos pues basta con aprender este estándar y no
perdernos en toda la jungla de métodos y notaciones
existentes.
8
 Breve historia del UML
- Los lenguajes de modelado orientados al
objeto comenzaron a aparecer a mediados
de la década de '70.

- El número de lenguajes que modelaban

objetos aumentó de menos de 10 a más de
50 durante el período entre 1989-1994.

- Muchos de los que utilizaban estos lenguajes no

encontraban satisfacción completa en ninguno de ellos,
esto motivó la llamada "Guerra de los Métodos".

9
. . . Breve historia del UML
. . . La “Guerra de los Métodos”

Existían muchos métodos y cada uno

tenía un lenguaje de modelado
propio.

Esto dificultó el aprendizaje,

aplicación, construcción, uso de
herramientas, etc.

Pugna entre los distintos gurús que

defendían sus propios métodos y
simbologías.

Se observa la necesidad de una

notación estándar.
10
 . . . Breve historia del UML
El desarrollo del UML comenzó en finales de
1994 en que Grady Booch y Jim Rumbaugh
de Rational Software Corporation,
comenzaron su trabajo sobre la unificación
de los métodos de Booch y de OMT (Object
Modeling Technique).

A finales de 1995, Ivar Jacobson y su

compañía de Objectory se unieron a
Rational y combinaron sus métodos.

Booch, Rumbaugh, y Jacobson, definieron

el UML 0,9 y 0,91 en junio y octubre de
1996.

11
 . . . Breve historia del UML

Sep ‘97 UML 1.1

Ene ‘97 UML 1.0

Microsoft
Jun ‘96 UML 0.9 Oracle
IBM, HP
Etc.
Oct ‘95 Método Unificado 0.8
Ivar Jacobson se une a Use Case
Rational en otoño ‘95
(OOSE)
James Rumbaugh se une
a Rational en Oct ‘94 OMT Booch Otros métodos
12
 Versiones del UML
<<document>>
1997
(Adoptada por OMG)
UML 1.1

1998 <<document>>
(revisión editorial sin <<document>> ISO Publica
cambios significativos) UML 1.2 especificación

1999
(revisión menor <<document>>
públicamente disponible) UML 1.3
2000
(planificada una revisión <<document>>
menor)
UML 1.4
2001
(planificada una revisión <<document>>
menor)
UML 1.5
2002
(planificada una revisión <<document>>
mayor) UML 2.0
13
 Vistas de un modelo
“Un modelo es una descripción completa de un sistema desde una perspectiva concreta”

Vista Diagrama de Casos de Uso

lógica
Diagrama de Clases

Diagrama de Objetos
Vista de
Diagrama de Secuencia
implementación
Vista de Diagrama de Colaboración
requerimientos
Vista de Diagrama de Estado
despliegue Diagrama de Actividad

Diagrama de Componentes
Vista de
Diagrama de Despliegue
procesos
14
 Modelando con UML

Use Case
Use Case State
Diagramas de
Diagrams State
Diagrams Diagramas de
Diagrams
Component Casos de Uso Diagrams
Component
Diagramas Clases State
Diagrams de
Diagrams State
Despliegue Diagramas de
Diagrams
Diagrams
Objetos

State Use Case

State Use Case
Diagramas de
Diagrams Diagramas de
Diagrams
Diagrams Diagrams
Componentes Modelo Secuencia

Scenario
Scenario Scenario
Diagramas de Scenario Diagramas de
Diagrams
Diagramas de
Diagrams Diagrams
Actividad Diagrams Colaboración
Estados

15
 La Crisis del Software
Introducción

 Ud. será capaz de:

◦ Explicar la crisis del software
◦ Discutir las fortalezas de la tecnología de objetos
◦ Discutir dónde la tecnología OO puede ser usada
◦ Definir análisis y diseño

16
La Crisis del Software
◦ El departamento de vehículos motorizados de
California gastó más de $43 millones de dólares en
un proyecto destinado a fusionar los sistemas de
conductores y registro de vehículos
 El sistema fue abandonado sin ni siquiera haber sido
usado
◦ Un fallido esfuerzo de $165 millones de dólares de
American Airlines de vincular su software de reserva
de pasajes con el sistema de reservaciones de
Marriott, Hilton y Budget
◦ El aeropuerto de Denver computarizó su sistema de
equipaje, lo que resultó en millones de dólares
perdidos por la demora en la apertura del aeropuerto

Software failures reported by W. Wayt Gibbs in the

September, 1994 issue of Scientific American

Ejemplos extremos, PERO hay muchos desastres similares en una menor escala
17
La Crisis del Software

◦ En marzo de 1989, Arthur Andersen reportó

 Más de $300 mil millones al año son gastados en
actividades de software comercial en los Estados
Unidos
 Sólo el 8% resulta en software que es distribuido y
funciona

◦ ¿Cuáles son las razones para la crisis del software?

 Base inestable
 Fallas en el manejo del riesgo
 La complejidad del software

18
Base Inestable

◦ Los requerimientos del negocio son ciclos de

desarrollo más cortos
 Los usuarios esperan más en términos de
flexibilidad
◦ Los requerimientos iniciales usualmente están
mal definidos

19
Fallas en el Manejo de Riesgos

◦ EL ciclo de vida de cascada retrasa la

identificación de problemas
◦ No hay pruebas de que el sistema funcionará
hasta que está cerca de ser terminado
◦ El resultado es de máximo riesgo

20
Complejidad de Software

◦ La demanda del software de negocios se está

incrementando
◦ Nadie entiende el sistema completo
◦ Los sistemas antiguos deben ser mantenidos,
pero los desarrolladores originales ya no están

21
Análisis y Diseño Orientado a Objetos

OOA OOD
Modelo de desarrollo Agregar detalles y
de requerimientos decisiones de diseño

Perspectiva del Usuario Perspectiva del Desarrollador

22
Desarrollo Iterativo e Incremental

Ing. Oscar Ascón Valdivia

oasconval@hotmail.com

23
Objetivos: Desarrollo Iterativo e
Incremental
 Ser capaz de:
◦ Definir un proceso de desarrollo iterativo e
incremental
◦ Enumerar las fases, los productos y las
actividades principales para cada fase del
proceso de desarrollo iterativo e incremental
◦ Definir una iteración y enumerar sus
actividades

24
¿Qué es un Desarrollo Iterativo e
Incremental?
◦ El desarrollo iterativo e incremental es el
proceso de construir el sistema en pequeños
pasos
◦ Beneficios
 Reducción de riesgos basado en una respuesta
temprana
 Mejor flexibilidad para acomodar
requerimientos nuevos o modificados
 Incrementar la calidad del programa

25
El Ciclo de Vida del Software
◦ El ciclo de vida de un programa desencadena una
secuencia de ciclos de desarrollo, en la cual el
resultado de estos ciclos es la generación de un
producto (Ejecutable)

◦ Cada ciclo es una sucesión de fases

 Inicio
 Elaboración
 Construcción
 Transición

Inicio Elaboración Construcción Transición

tiempo

26
Fase de Inicio
◦ Propósito
 Establecer el caso de negocio para un nuevo
sistema o para la puesta al día de un sistema ya
existente
◦ Artefactos desarrollados
 El núcleo de lo solicitado para el proyecto
 Una asesoría de riesgo inicial
◦ Artefactos opcionales:
 Un prototipo conceptual
 Un modelo inicial de dominio (10% - 20%
completo)

27
Fase de Elaboración
◦ Propósito
 Analizar el dominio del problema
 Establecer una arquitectura sólida
 Abordar el elemento más riesgoso del proyecto
 Desarrollar un plan integral para mostrar cómo el
proyecto será terminado

28
Fase de Elaboración (cont.)
◦ Productos
 Un modelo del comportamiento del sistema,
incluyendo el contexto del sistema, escenarios y
modelos del dominio (80% terminado)
 Una arquitectura ejecutable
 Una visión de la línea base del producto a partir
del modelo del dominio
 Una evaluación del riesgo
 Un plan de desarrollo
 Criterios de evaluación
 Un manual preliminar para el usuario (opcional)
 Estrategias de pruebas
 Plan de pruebas

29
Fase de Construcción
◦ Objetivo
 Desarrollar incrementalmente un producto
completo (un programa) que está listo para
introducirse en la comunidad de los usuarios
◦ Productos
 Una secuencia de ejecutables
 Prototipos de comportamiento
 Resultados de calidad asegurados
 Documentación del usuario y del sistema
 Plan de despliegue
 Criterios de evaluación para al menos la siguiente
iteración

30
Fase de Transición
◦ Propósito
 Implantar el software en su entorno de
operación
◦ Productos
 Una secuencia de ejecutables.
 Resultados de calidad asegurados
 Documentación del usuario y del sistema
actualizada
 Análisis del rendimiento del proyecto
“Postmortem”

31
¿Qué es una Iteración?
◦ Una iteración es un ciclo de desarrollo que termina
en la entrega de un subconjunto de productos
finales
◦ Cada iteración pasa por todos los aspectos de
desarrollo del programa
 Análisis de Requerimientos
 Diseño e Implementación
 Prueba
 Documentación
◦ Cada entrega iterativa es una “pieza” totalmente
documentada del sistema final

Iteración Iteración Iteración Iteración Iteración Iteración Iteración de Iteración de

preliminar arquitect. arquitect. desarrollo desarrollo desarrollo transición transición

32
 Reducción de Riesgo a través de Iteraciones
Definir la iteración para
consignar el mayor riesgo
Riesgo inicial
Campo de acción inicial del
proyecto Planificar y desarrollar la iteración

Iteración N
Estimar la iteración

Revisión del plan Eliminación

del proyecto del riesgo

Revisión de la Evaluación de riesgo

33
Proceso de Planificación de una
Iteración
◦ Identificar y priorizar los riesgos del proyecto
◦ Seleccionar un número pequeño de escenarios que
contengan los mayores riesgos
◦ Los escenarios seleccionados son usados por:
 Los desarrolladores para identificar lo que será
implementado para la iteración
 Los probadores para desarrollar el plan de pruebas y el
procedimiento de prueba para la iteración
◦ Al final de la iteración
 Determinar qué riesgo ha sido reducido o eliminado
 Determinar si algún nuevo riesgo ha sido descubierto
◦ Poner al día el plan para las iteraciones restantes

34
Juntando Todo

35
Características Esenciales de RUP

 Proceso Dirigido por los Casos de Uso

 Proceso Iterativo e Incremental
 Proceso Centrado en la Arquitectura
Proceso dirigido por los Casos de Uso

Capturar, definir y
Requisitos
validar los casos de
uso
Análisis & Diseño Casos de Uso Realizar los
integran el casos de uso
Implementación trabajo

Verificar que se
Pruebas satisfacen los casos
de uso
Proceso Iterativo e Incremental

 El ciclo de vida iterativo se basa en la

evolución de prototipos ejecutables que se
muestran a los usuarios y clientes
 En el ciclo de vida iterativo a cada
iteración se reproduce el ciclo de vida en
cascada a menor escala
 Los objetivos de una iteración se
establecen en función de la evaluación de
las iteraciones precedentes
... Proceso Iterativo e Incremental
 Las actividades se encadenan en una mini-
cascada con un alcance limitado por los
objetivos de la iteración

Análisis

Diseño

Codific.

Pruebas e
n veces Integración
... Proceso Iterativo e Incremental
 Cada iteración comprende:
◦ Planificar la iteración (estudio de riesgos)
◦ Análisis de los Casos de Uso y escenarios
◦ Diseño de opciones arquitectónicas
◦ Codificación y pruebas. La integración del nuevo
código con el existente de iteraciones anteriores
se hace gradualmente durante la construcción
◦ Evaluación de la entrega ejecutable (evaluación
del prototipo en función de las pruebas y de los
criterios definidos)
◦ Preparación de la entrega (documentación e
instalación del prototipo)
Proceso Centrado en la Arquitectura
 Arquitectura de un sistema es la organización
o estructura de sus partes más relevantes
 Un arquitectura ejecutable es una
implementación parcial del sistema,
construida para demostrar algunas funciones
y propiedades
 RUP establece refinamientos sucesivos de una
arquitectura ejecutable, construida como un
prototipo evolutivo

Inception Elaboration Construction Transition

Architecture