Académique Documents
Professionnel Documents
Culture Documents
1
Construcción de una casa para “fido”
2
Construcción de una casa
4
Problemas de la Industria de Software
en la actualidad
1 Tendencia al crecimiento
del volumen y complejidad
de los productos.
2 Proyectos excesivamente tardes y
se exige mayor productividad y
calidad en menos tiempo.
3 Insuficiente personal calificado.
¿ Por qué fallan los
? Proyectos de Software?
1 Planificación Irreal
2 Mala Calidad del Trabajo
3 Personal Inapropiado
4 No Controlar los Cambios 6
1
Planificación Irreal
CAUSAS
• Prácticas pobres de ingeniería
• Carencia de métricas de calidad
• Inadecuado entrenamiento en calidad
• Decisiones de los directivos guiadas
por una planificación irreal 8
2
Mala Calidad del Trabajo
CONSECUENCIAS
• Tiempos de pruebas impredecibles
• Productos con muchos defectos
• Demoras en la aceptación de los usuarios
• Extensa garantía de servicio y reparaciones
“Una pobre calidad afecta la
planificación y torna ineficente el
proceso de prueba” 9
3
Personal Inapropiado
• Demora del personal
PROBLEMAS • Escaso personal
COMUNES
• Miembros del equipo a tiempo parcial
• Personal con conocimientos
inapropiados
• El trabajo se demora o descuida
CONSECUENCIAS • Trabajo ineficiente
• Sufre la moral del equipo
Con independencia del plan, los
proyectos deben comenzar en tiempo
y con todo el personal.
10
4
Cambios NO controlados
HECHOS a RECORDAR:
• Siempre ocurren cambios en los requerimientos.
• Los planes del proyecto se basan en el alcance del
trabajo conocido.
• Los cambios siempre requieren más trabajo.
• Sin planes detallados, los equipos no pueden
estimar el efecto o magnitud de los cambios.
• Si los equipos no controlan cada cambio, se
pierde gradualmente el control del plan del
proyecto
11
? ¿Cómo enfrentarla?
IEEE,1993
15
IS es una tecnología multicapa
Indican cómo construir
técnicamente el Sw.
Soporte automático o
semiautomático para el
proceso y los métodos.
Es el fundamento de la
IS. Es la unión que
mantiene juntas las
capas de la tecnología.
16
Síntomas - Causas
Síntomas Diagnóstico Causas
• necesidades usuarios • requerimientos
• requerimientos insuficientes
cambiantes • comunicación ambigua
• módulos no calzan • arquitecturas frágiles
• poco mantenible • complejidad excesiva
• inconsistencias no
• tardía detección detectadas
• baja calidad • prueba pobre
• baja performance • evaluación subjetiva
• versiones y cambios • desarrollo en cascada
• liberación y • cambios no controlados
distribución
• automatización
...tratar los Síntomas no resuelve el problema17
insuficiente
Las Mejores Prácticas de la IS
atacan las causas
Desarrolle Iterativamente
Use
Administre arquitectura Modele Verique
Requerimientos de Visualmente Calidad
componentes
Controle Cambios
18
Mejores Prácticas de Software
19
Mejores Prácticas: Equipos de Alto
Rendimiento
Resultado
• Proyectos más exitosos
Ing. de
porque están en plazo, Performance
en presupuesto y Analisis
satisfacen las
necesidades del usuario Jefe de
Develop Iteratively Proyecto
Desarrollador
Use Model
Manage Component Visually Verify
Requireme Architectures Quality Probador
nts
Control Changes
Liberación y Distribución
20
Enfrentando las Causas se eliminan los Síntomas
23
(Notación)
Sumario
24
afía
r
Bib
l io g
Lecturas Recomendadas
• BOOCH, Grady, RUMBAUGH, James, JACOBSON, Ivar;
“El Lenguaje Unificado de Modelación. Libro
introductorio”.2000. Addison Wesley.
• RUMBAUGH, James, JACOBSON, Ivar, BOOCH, Grady;
“El Lenguaje Unificado de Modelación. Manual de
referencia”.2000. Addison Wesley.
26
Conceptos básicos del Modelo
de Objetos
27
Enfoque Orientado a Objetos
Objetos
Atributos
blanco
Partes
28
Enfoque Orientado a Objetos
Tipo de Objeto:
Descripción generalizada que describe una
colección de objetos similares.
Clase:
Implementación en software de un tipo de
objeto.
Tlibro = class
private
. . .
end;
29
Enfoque orientado a Objetos
Método:
Implementación en software de la operación.
TSemáforo = class
Cambiar luz
.....
Cambiar luz();
end;
30
Enfoque Orientado a Objetos
Encapsulamiento
Empaque conjunto de datos y métodos.
Atributos
Operaciones
31
Enfoque Orientado a Objetos
32
Proceso de Desarrollo de
Software
33
Proceso
Define “quién” está haciendo “qué”, “cuándo” y
“cómo” para alcanzar un determinado objetivo.
35
Proceso de desarrollo de software (PDS)
37
Lenguaje de modelación
= +
38
Lenguaje de modelación
= +
(Forma de (Descripción
expresar el de lo que
modelo) significa esa
modelación)
39
Notación visual
Manejar la complejidad
Interface de Usuario
(Visual Basic,
Java, ..)
Lógica del Negocio
(C++, Java, ..)
Múltiples Sistemas
Servidor de BDs
(C++ & SQL, ..)
Modelar el sistema
independientemente Componentes
Reutilizados
del lenguaje de
implementación
Promover la Reutilización
40
Situación de partida
• Diversos métodos y técnicas OO, con muchos aspectos en
común pero utilizando distintas notaciones
• Inconvenientes para el aprendizaje, aplicación,
construcción y uso de herramientas, etc.
• Pugna entre distintos enfoques (y correspondientes
gurús)
41
?
UML
¿Qué es el UML- Unified
Modeling Language?
Lenguaje Unificado de Modelación
• Descrito en "The Unified Modeling Language for
Object-Oriented Development" de Grady Booch,
James Rumbaugh e Ivar Jacobson.
• Basado en las experiencias personales de los
autores.
• Incorpora contribuciones de otras metodologías. 42
?
UML
¿Qué es el UML- Unified
Modeling Language?
Lenguaje Unificado de Modelación
Visualizar Especificar
Documentar
Construir 44
UML no es un método
46
Creación del UML UML 2.0
UML 1.5
OMG Acceptance, Nov 1997 Version 1.1
Final submission to OMG, Sep ‘97 UML 1.1
First submission to OMG, Jan ´97
public
feedback
UML partners UML 1.0
47
¿Por qué UML 2.0?
53
Limitaciones de UML
55
¿Qué es un producto de software?
Un producto de software es el código
máquina y los ejecutables de un sistema
Un producto de software es el conjunto de
artefactos que se necesitan para
representarlo en forma comprensible para:
• Las máquinas.
• Los trabajadores.
¿artefactos? • Los usuarios.
• Los interesados.
56
¿Artefactos?
Término general aplicable a
cualquier tipo de información
creada, cambiada o utilizada por
los trabajadores en el desarrollo
del sistema
Ejemplos:
• Diagramas UML y su texto.
• Bocetos de interfaz.
• Planes de prueba.
57
Modelos y Diagramas
• Un modelo captura una vista de un sistema del
mundo real. Es una abstracción de dicho sistema,
considerando un cierto propósito. Así, el modelo
describe completamente aquellos aspectos del
sistema que son relevantes al propósito del
modelo, y a un apropiado nivel de detalle.
• Diagrama: una representación gráfica de una
colección de elementos de modelado, a menudo
dibujada como un grafo con vértices conectados
por arcos
58
Modelos
Diagrama de Casos de
Uso del Negocio
Diagrama de Casos de
Uso del Sistema
Diagrama de Actividades
Diagrama de Estado
Diagrama de Paquetes 61
Diagramas de UML
Casos de uso
Diagrama de casos de uso
62
Diagrama de casos de uso
Casos de Uso es una técnica para
capturar información de cómo un
sistema o negocio trabaja, o de cómo
se desea que trabaje
No pertenece estrictamente al
enfoque orientado a objeto, es una
técnica para captura de requisitos
63
Solicitar Préstamo
Cliente
Diagramas de UML
64
Diagrama de clases
Departamento Profesor
0..1 1..*
65
Diagramas UML
• Diagramas del comportamiento
•Diagramas de Estado
•Diagramas de Actividad
•Diagramas de Secuencia
•Diagrama de Comunicación
•Diagrama de tiempo
alta baja
Socio
número : int
nombre : char[50] núm er o_prés tam os = 0
número_prestamos : int = 0 sin pr éstam os
alta()
baja()
prestar(código_libro : int, fecha : date)
devolver(código_libro : int, fecha : date)
pres tar devol ver [ núm ero_p rést amo s = 1 ]
c on prés tam os
pres tar
Buscar bebida
NO ¿hay jugo?
¿hay café?
SÍ NO
SÍ
Poner filtro en
máquina
Encender
máquina
Hacer café
prestar(video, socio)
verificar situación socio
registrar préstamo
entregar recibo
69
Diagrama de comunicación
:Socio
:Video
5: entregar recibo
: Encargado 4: registrar préstamo
:Préstamo
70
Diagramas de UML
• Diagramas de implementación
• Diagramas de componentes
• Diagramas de instalación/Distribución
(Despliegue)
Diagrama de componentes
71
Diagrama de componentes
Interfaz de Terminal
Control y Análisis
72
Diagrama de despliegue
Servidor Central Control y Análisis
Acceso a BD Comment
Comment
Rutinas de Coneccion
Comment
Terminal de Consulta
Interfaz de Terminal
Rutinas de Coneccion
Comment Comment
Punto de Venta
Rutinas de Coneccion
Comment
Comment Comment
73
¿Cómo se relacionan los diagramas?
So
lo
se par
cu a c
en om
cia p
de ren
pa der
so la
s
Tomado de:
Rosenberg, Doug, Kendall Scott. Applying use
74
case driven object modeling with UML: an
annotated e-commerce example.
¿Cómo se relacionan los diagramas?
So
lo
se par
cu a c
en om
cia p
de ren
pa der
so la
s
Tomado de:
Rosenberg, Doug, Kendall Scott. Applying use
case driven object modeling with UML: an 75
annotated e-commerce example.
¿Cómo se relacionan los diagramas?
So
lo
se par
cu a c
en om
cia p
de ren
pa der
so la
s
Tomado de:
Rosenberg, Doug, Kendall Scott. Applying use
76
case driven object modeling with UML: an
¿Cómo se relacionan los diagramas?
So
lo
se par
cu a c
en om
cia p
de ren
pa der
so la
s
Tomado de:
Rosenberg, Doug, Kendall Scott. Applying use
77
case driven object modeling with UML: an
annotated e-commerce example.
Resumen
78
El Proceso Unificado de
Desarrollo
(Rational Unified Process- RUP)
79
Rational Unified Process
80
Evolución de RUP
Pruebas de rendimiento y carga Diseño OO de IU
(Performance Awareness)
1998 Rational Unified Ingeniería de Datos
Ingeniería de Negocios Process 5.0 (Vigortech)
Administración de
Configuración y Cambios UML 1.2
(Pure-Atria)
Escuela de Rational Objectory Proceso SQA
1997 Requerimientos Process 4.1 (SQA Inc.)
(Requisite Inc.)
UML 1.0
Rational
1995 Approach Objectory
Process
1987
Ericsson
1967 81
method
Estructura Estática de RUP
Tiempo
• Concepción Define el alcance del proyecto y el
desarrollo de los casos del negocio.
• Elaboración Planifica el proyecto, especifica
las características y define los
cimientos de la arquitectura.
84
Características del ciclo de vida de
RUP
85
Ciclo de vida de RUP
Dirigido por Casos de Uso
(Reflejar lo que los futuros usuarios
necesitan y desean)
Caso de Uso
Requisitos Análisis Diseño Implementación Prueba
«trace»
«trace»
Pruebas
Unitarias
Pruebas Funcionales X
Caso de Prueba
87
Ciclo de vida de RUP
Dirigido por Casos de Uso
88
Ciclo de vida de RUP
Centrado en la arquitectura
En la construcción,
vista de:
A) Estructura.
B) Calefacción.
C) Plomería.
D) Electricidad. Estáticos
Aspectos
Dinámicos 89
Ciclo de vida de RUP
Centrado en la arquitectura
(Visión común del sistema completo en la que
desarrolladores y usuarios deben estar de acuerdo )
Enfoque
Cascada
Enfoque
Iterativo e
Incremental
93
Ciclo de vida de RUP
Iterativo e incremental
Grado de Finalización de Artefactos
94
Beneficios de la iteración
• Reduce el coste del riesgo al coste de un
solo incremento.
Desarrollo
en equipos
Lenguaje de Proceso
Modelamiento Unificado
97