introducción a uml
DESCRIPTION
UmlTRANSCRIPT
![Page 1: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/1.jpg)
1
Curso de UML
Actividad 1 Introducción a UML
Dra. Anaisa Hernández González
![Page 2: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/2.jpg)
2
Construcción de una casa para “fido”
Puede hacerlo una sola personaRequiere:
Modelado mínimoProceso simpleHerramientas simples
![Page 3: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/3.jpg)
3
Construcción de una casa
Construida eficientemente y en un tiempo razonable por un equipoRequiere:
ModeladoProceso bien definidoHerramientas más sofisticadas
![Page 4: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/4.jpg)
4
Construcción de un rascacielos
![Page 5: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/5.jpg)
Problemas de la Industria de Software en la actualidad
Tendencia al crecimiento del volumen y complejidad de los productos.
1
2 Proyectos excesivamente tardes y se exige mayor productividad y calidad en menos tiempo.
3 Insuficiente personal calificado.
![Page 6: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/6.jpg)
6
Planificación Irreal1
2 Mala Calidad del Trabajo
3 Personal Inapropiado
4 No Controlar los Cambios
¿ Por qué fallan los ¿ Por qué fallan los Proyectos de Software?Proyectos de Software??
![Page 7: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/7.jpg)
7
Los ingenieros no son capaces de enfrentar un plan porque:
PlanificaciPlanificacióón Irrealn Irreal 1
• NO están entrenados para usar métodos de planificación.
• Frecuentemente, las estimaciones NO se basan en datos reales.
“El sistema es para hoy y con costo 0”
![Page 8: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/8.jpg)
8
2Mala Calidad del TrabajoMala Calidad del Trabajo
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
![Page 9: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/9.jpg)
9
2Mala Calidad del TrabajoMala 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 Una pobre calidad afecta la calidad afecta la planificaciónplanificación y torna y torna
ineficente ineficente el proceso de el proceso de pruebaprueba””
![Page 10: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/10.jpg)
10
3Personal InapropiadoPersonal Inapropiado
Con independencia del plan, los proyectos deben comenzar en tiempo y con todo el personal.
• Demora del personal• Escaso personal• Miembros del equipo a tiempo parcial• Personal con conocimientos
inapropiados
PROBLEMAS COMUNES
• El trabajo se demora o descuida• Trabajo ineficiente• Sufre la moral del equipo
CONSECUENCIAS
![Page 11: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/11.jpg)
11
4Cambios Cambios NONO controlados controlados
• 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
HECHOS a RECORDAR:
![Page 12: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/12.jpg)
12
Las organizaciones requieren:
¿Cómo enfrentarla?¿Cómo enfrentarla??
Desarrollar o adquirir una disciplina
en el desarrollo del software.
1
2 Controlar que los ingenieros usen de
forma consistente los nuevos métodos.
![Page 13: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/13.jpg)
Mejorar el proceso de Mejorar el proceso de desarrollo de softwaredesarrollo de software
¿Qué debe hacer una empresa para obtener
software de buena calidad?
Cómo?
![Page 14: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/14.jpg)
14
Cualquier modelo de calidad para mejorar el Proceso de Desarrollo de
Software, IMPLICA utilizar los métodos y procedimientos de
INGENIERIA Y GESTION DE SOFTWARE
![Page 15: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/15.jpg)
15
¿Qué es la Ingeniería de Software (IS)?
“...la aplicación de un enfoque sistémico, disciplinado y cuantificable hacia el desarrollo, funcionamiento y mantenimiento de software, es decir la aplicación de ingeniería al software”
IEEE,1993
![Page 16: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/16.jpg)
16
IS es una tecnología multicapa
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.
Indican cómo construir técnicamente el Sw.
![Page 17: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/17.jpg)
17
Síntomas•necesidades usuarios
• requerimientos cambiantes
•módulos no calzan
•poco mantenible
• tardía detección
•baja calidad
•baja performance
•versiones y cambios
• liberación y distribución
Causas• requerimientos
insuficientes
•comunicación ambigua
•arquitecturas frágiles
•complejidad excesiva
• inconsistencias no detectadas
•prueba pobre
•evaluación subjetiva
•desarrollo en cascada
•cambios no controlados
•automatización insuficiente
Síntomas - Causas
...tratar los Síntomas no resuelve el problema
Diagnóstico
![Page 18: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/18.jpg)
18
Las Mejores Prácticas de la IS atacan las causas
Controle CambiosControle Cambios
Desarrolle IterativamenteDesarrolle Iterativamente
AdministreAdministreRequerimientosRequerimientos
Modele Modele VisualmenteVisualmente
VeriqueVeriqueCalidadCalidad
Use Use arquitectura arquitectura
de de componentescomponentes
![Page 19: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/19.jpg)
19
Mejores Prácticas de Software
Son propuestas de desarrollo probadas comercialmente, que usadas en forma combinada atacan la raíz de las causas de las fallas, eliminando los síntomas y permitiendo el desarrollo y mantenimiento de software de calidad de manera predictiva y reiterativa.
![Page 20: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/20.jpg)
20
Mejores Prácticas: Equipos de Alto Rendimiento
Jefe deProyecto
Ing. dePerformance
Liberación y Distribución
Analisis
Desarrollador
Probador
ResultadoResultado
• Proyectos más exitosos porque están en plazo, en presupuesto y satisfacen las necesidades del usuario
Control ChangesControl Changes
Develop IterativelyDevelop Iteratively
Use Use ComponentComponent
ArchitecturesArchitecturesManage Manage
RequiremeRequirementsnts
Model Model VisuallyVisually VerifyVerify
QualityQuality
![Page 21: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/21.jpg)
21
SÍNTOMASnecesidades usuarios
requerimientos cambiantes
módulos no calzan
poco mentenible
tardía detección
baja calidad
baja performance
versiones y cambios
liberación y distribución
CAUSASRequerimientos insuficientes
Comunicación ambigua
arquitecturas frágiles
complejidad excesiva
inconsistencias no detectadas
testing pobre
evaluación subjetiva
desarrollo en cascada
cambios no controlados
automatización insuficiente
MEJORES PRÁCTICAS
desarrolle iterativamente
adm. requerimientos
use arquitectura de componetes
modele el software visualmente
verifique calidad
controle cambios
Enfrentando las Causas se eliminan los Síntomas
![Page 22: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/22.jpg)
22
Controle Cambios
Desarrolle Iterativamente
Use Arquitecturas
de Componentes
Modele Visualmente
VeriqueCalidad
Asegura participación del usuariomientrás evolucionan requerimientos
Valida tempranamentelas decisiones arquitectónicas
Pemite manejar la complejidadde diseñar incrementalmente
Mide la calidad en forma oportuna y frecuente
Evoluciona la línea base incrementalmente
Administre Requerimientos
Mejores Prácticas se refuerzan entre si
![Page 23: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/23.jpg)
23
Mejores prácticas para el trabajo efectivo de un equipo en el
desarrollo del software.
(Dirige y organiza el proceso)
(Notación)
![Page 24: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/24.jpg)
24
Sumario
• Conceptos básicos del modelo de objetos• Proceso de desarrollo de software.• El Lenguaje Unificado de Modelación (UML)• El Proceso Unificado de Desarrollo de
Software (RUP)
![Page 25: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/25.jpg)
25
Lecturas Recomendadas
JACOBSON, Ivar; BOOCH, Grady, RUMBAUGH, James, “El Proceso Unificado de Desarrollo de Software”.2000. Addison Wesley.
BOOCH, Grady, RUMBAUGH, James, JACOBSON, Ivar; “El Lenguaje Unificado de Modelación. Libro introductorio”.2000. Addison Wesley.
•LARMAN, Craig “UML y patrones” 1999, Prentice Hall Iberoamericana.
RUMBAUGH, James, JACOBSON, Ivar, BOOCH, Grady; “El Lenguaje Unificado de Modelación. Manual de referencia”.2000. Addison Wesley.
Bibliografía
![Page 26: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/26.jpg)
26
Lecturas Recomendadas
CONALLEN, Jim, “Building Web Applications with UML”.2002. 2nd edition. Addison Wesley.
BOOCH, Grady, MAKSIMCHUCK, Robert, ENGLEm Michael, YOUNG, Bobbi, CONALLEN, Jim, Houston, Kelli; “Objetct-Oriented Analysis and Design with Applications”. Third Edition. Addison Wesley. 2007.
HAMILTON, Kim, MILES, Russell; “Learning UML 2”.2006. O´ Reilly Media
Bibliografía
![Page 27: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/27.jpg)
27
Conceptos básicos del Modelo de Objetos
![Page 28: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/28.jpg)
28
Enfoque Orientado a Objetos
Se basa en conceptos y relaciones entre ellos.
Objetos
Atributos
blanco
Todo
Partes
![Page 29: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/29.jpg)
29
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;
![Page 30: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/30.jpg)
30
Enfoque orientado a Objetos
Método:Implementación en software de la operación.
TSemáforo = class
.....
Cambiar luz();
end;
Cambiar luz
![Page 31: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/31.jpg)
31
EncapsulamientoEmpaque conjunto de datos y métodos.
AtributosOperaciones
Enfoque Orientado a Objetos
![Page 32: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/32.jpg)
32
Enfoque Orientado a Objetos
Herencia: Propiedad de una clase de heredar el comportamiento de sus ancestros.
Polimorfismo: Mecanismo que permite a la subclase implementar la misma operación con un método diferente.
![Page 33: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/33.jpg)
33
Proceso de Desarrollo de Software
![Page 34: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/34.jpg)
34
Proceso
Define “quién” está haciendo “qué”, “cuándo” y “cómo” para alcanzar un determinado objetivo.
Proceso de desarrollo de software (PDS)
Requisitos del usuario Sistema informático
![Page 35: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/35.jpg)
35
Proceso de desarrollo de software (PDS)
![Page 36: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/36.jpg)
36
• Un proceso software debe especificar:– la secuencia de actividades a realizar por
el equipo de desarrollo: flujo de actividades
– productos que deben crearse: qué y cuándo
– asignación de tareas a cada miembro del equipo y al equipo como un todo
– proporcionar heurísticas– criterios para controlar el proceso
Proceso de desarrollo de software (PDS)
![Page 37: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/37.jpg)
37
UML
![Page 38: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/38.jpg)
38
“ Puede ser un seudocódigo, código, imágenes, diagramas, o largos paquetes de descripción; es decir, cualquier cosa
que ayude a describir un sistema ”
Lenguaje de modelación
= +
![Page 39: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/39.jpg)
39
(Forma de expresar el
modelo)
Lenguaje de modelación
+=(Descripción
de lo que significa esa modelación)
![Page 40: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/40.jpg)
40
Interface de Usuario(Visual Basic,
Java, ..)Lógica del Negocio
(C++, Java, ..)
Servidor de BDs(C++ & SQL, ..)
Múltiples Sistemas
Componentes Reutilizados
Manejar la complejidad
Modelar el sistema independientemente del lenguaje de implementación
Promover la Reutilización
Notación visualNotación visual
![Page 41: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/41.jpg)
41
• 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)
Situación de partidaSituación de partida
![Page 42: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/42.jpg)
42
• 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.
Lenguaje Unificado de Modelación
?
¿Qué es el UML- Unified Modeling Language?
U M L
![Page 43: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/43.jpg)
43
• Ofrece un estándar para describir un “plano” del
sistema.
• Incluye aspectos conceptuales tales como procesos
de negocio y funciones del sistema y aspectos
concretos como espresiones de lenguajes de
programación, esquemas de BD y componentes de
software reutilizables.
Lenguaje Unificado de Modelación
?
¿Qué es el UML- Unified Modeling Language?
U M L
![Page 44: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/44.jpg)
44
UML
DocumentarDocumentar
VisualizarVisualizar EspecificarEspecificar
ConstruirConstruir
![Page 45: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/45.jpg)
45
UML no es un método
El UML es una guía al desarrollador para realizar el análisis y diseño orientado a objetos, es un
proceso
El UML es un lenguaje que permite la modelación de sistemas con tecnología orientada a objetos
Aprobado como estándar por OMG en noviembre de 1997
![Page 46: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/46.jpg)
46
El esfuerzo de UML partió oficialmente en octubre de 1994, cuando Rumbaugh se unió a Booch en Rational.
El “Método Unificado” en su Versión 0.8, se presentó en el OOPSLA’95
El mismo año se unió Ivar Jacobson. Los “Tres Amigos” son socios en la compañía Rational Software. Herramienta CASE Rational Rose
Orígenes de UML
![Page 47: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/47.jpg)
47
Creación del UML
Booch method OMT
Unified Method 0.8OOPSLA ´95
OOSEOther methods
UML 0.9Web - June ´96
publicfeedback
UML 1.5
UML 1.0UML partners
UML 2.0
Final submission to OMG, Sep ‘97
First submission to OMG, Jan ´97UML 1.1
OMG Acceptance, Nov 1997 Version 1.1
![Page 48: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/48.jpg)
48
• Las primeras versiones de UML estaban más orientadas hacia la modelación del software y ahora se requiere más la modelación del sistema.
• Necesidad de compartir modelos entre diferentes herramientas.
• Nuevas tecnologías: Arquitectura basada en componentes, MDA
• Las primeras versiones estaban más diseñadas para las personas y no para las máquinas, por lo que hay construcciones que no estaban suficientemente formalizadas.
¿Por qué UML 2.0?
![Page 49: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/49.jpg)
49
GRADYBOOCH
IVARJACOBSON
JAMESRUMBAUGH
Object Modelling Technique 1991(OMT)
Object Oriented Analysis and Design with Applications 1994
Object Oriented Software Engineering: A Use Case Driven Approach 1992 (OOSE)
Las Bases de UML• Booch, • Rumbaugh• Jacobson
Rational Software Corporation. (1995)
Las Bases de UMLLas Bases de UML
![Page 50: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/50.jpg)
50
• Modelar sistemas, a partir de los conceptos hacia los artefactos ejecutables, utilizando técnicas orientadas a objeto.
• Enfocarnos en las cuestiones de escala inherentes a sistemas complejos, críticos en su misión.
• Crear un lenguaje de modelación utilizable tanto por los humanos, como por las máquinas.
Premisas de UML según Booch, Jacobson y Rumbaugh
![Page 51: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/51.jpg)
51
Contribuciones a UMLDiagrama de Casos de uso
Diagrama de Clases
Diagrama de Objetos
Diagrama de Secuencia
Diagrama de Estado
Diagrama de Componentes
Diagrama de Estructura Compuesta
Diagrama de Paquetes
Diagrama de Comunicación
Diagrama de Actividad
Diagrama de Tiempo
Diagrama de Despliegue
OOSE/Jacobson
OOAD/Booch
OMT/Rumbaugh
Otras mejores prácticas
![Page 52: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/52.jpg)
52
• Es un lenguaje formal ya que cada elemento del lenguaje tiene un significado fuerte que ayuda a modelar un aspecto particular del sistema.
• Es conciso con una notación simple.
• Es comprensible porque describe todos los aspecto importante del sistema.
• Es escalable por lo que permite describir proyectos de diferentes tamaños.
Ventajas de UML
![Page 53: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/53.jpg)
53
• Contiene las mejores prácticas de la comunidad orientada a objetos de los últimos 15 años.
• Es un estándar abierto.
• Da soporte a todo el ciclo de vida de desarrollo del software.
• Da soporte a diversas áreas de aplicación.
• Está soportado por muchas herramientas.
Ventajas de UML
![Page 54: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/54.jpg)
54
• Carece de un semántica precisa, lo que ha dado lugar a que la interpretación de un modelo UML no pueda ser objetiva en ocasiones.
• No se presta con facilidad al diseño de sistemas distribuidos. En estos sistemas son importantes factores como transmisión, serialización, persistencia, etc. No se puede señalar si un objeto es persistente o remoto.
Limitaciones de UML
![Page 55: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/55.jpg)
55
Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto de software desde cada una de las perspectivas de interés
![Page 56: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/56.jpg)
56
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. • Los usuarios.• Los interesados.
¿artefactos?
¿Qué es un producto de software?
![Page 57: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/57.jpg)
57
¿Artefactos?
Término general aplicable a cualquier tipo de información creada, cambiada o utilizada por los trabajadores en el desarrollo del sistema
• Diagramas UML y su texto.• Bocetos de interfaz.• Planes de prueba.
EjemplosEjemplos::
![Page 58: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/58.jpg)
58
• 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
Modelos y DiagramasModelos y Diagramas
![Page 59: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/59.jpg)
59
Modelo de Casos de Uso
Modelo de Diseño
Modelo de Implementación
Trazabilidad entre los modelos
Secuenciacronológica
ModelosModelos
Modelo de Despliegue
Modelo de Análisis
Modelo de Prueba
![Page 60: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/60.jpg)
60
Diagramas de UML
Diagrama ¿Dónde aparece?
Caso de uso 1.x
Actividad 1.x
Clase 1.x
Objeto Informalmente 1.x
Secuencia 1.x
Comunicación Antes de Colaboración en 1.x
Tiempo 2.0
Estructura interna 2.0
Componente 1.x, pero cambia su significado en 2.0
Paquete 2.0
Estado 1.X
Despliegue 1.x
Estructura Dinámica Física Gestión del modelo
![Page 61: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/61.jpg)
61
Modelo de Casos de Uso
Modelos y Diagramas
Diagrama de Casos de Uso del Negocio
Diagrama de Secuencia
Diagrama de Comunicación
Diagrama de Casos de Uso del Sistema
Diagrama de Actividades
Diagrama de Estado
Diagrama de Paquetes
![Page 62: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/62.jpg)
62
Casos de Uso y Diagramas de Casos de Uso
Diagramas de UML
Casos de usoDiagrama de casos de uso
![Page 63: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/63.jpg)
63
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
Diagrama de casos de uso
ClienteSolicitar Préstamo
![Page 64: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/64.jpg)
64
Diagramas de estructura estática Diagrama de clases Diagrama de Objetos
Diagramas de UML
![Page 65: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/65.jpg)
65
Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia
La definición de clase incluye definiciones para atributos y operaciones
El modelo de casos de uso aporta información para establecer las clases, objetos, atributos y operaciones
Diagrama de clases
ProfesorDepartamento
0..1 1..*0..1
![Page 66: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/66.jpg)
66
Diagramas UML
Diagramas del comportamientoDiagramas de EstadoDiagramas de ActividadDiagramas de SecuenciaDiagrama de ComunicaciónDiagrama de tiempo
Diagrama de Secuencia Diagrama de Comunicación
![Page 67: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/67.jpg)
67
con préstamos
sin préstamos
alta baja
prestar devolver[ número_préstamos = 1 ]
prestar
devolver[ número_préstamos > 1 ]
número_préstamos = 0
número_préstamos > 0
Socio
número : intnombre : char[50]número_prestamos : int = 0
alta()baja()prestar(código_libro : int, fecha : date)devolver(código_libro : int, fecha : date)
Diagrama de estado
![Page 68: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/68.jpg)
68
Diagrama de actividades
Buscar bebida
¿hay café?
Poner café en filtro
Añadir agua al depósito
Coger taza
Poner filtro en máquina
Encender máquina
Hacer café
Servir café Beber
Servir jugo
¿hay jugo?
SÍNO
NO
SÍ
![Page 69: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/69.jpg)
69
Diagrama de secuencia
: Encargado:WInPréstamos :Socio :Video :Préstamo
prestar(video, socio)
verificar situación socio
verificar situación video
registrar préstamo
entregar recibo
![Page 70: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/70.jpg)
70
: Encargado
:WInPréstamos
:Socio
:Video
:Préstamo
1: prestar(video, socio)
2: verificar situación socio
3: verificar situación video
4: registrar préstamo5: entregar recibo
Diagrama de comunicación
![Page 71: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/71.jpg)
71
Diagramas de implementación Diagramas de componentes Diagramas de instalación/Distribución
(Despliegue)
Diagramas de UML
Diagrama de componentes
![Page 72: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/72.jpg)
72
Interfaz de Terminal
Gestión de Cuentas Rutinas de conexión Acceso a BD
Control y Análisis
Diagrama de componentes
![Page 73: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/73.jpg)
73
Diagrama de despliegue
Punto de Venta
Servidor Central
Terminal de Consulta
Gestión de Cuentas
Comment
Interfaz de Terminal
Comment
Rutinas de Coneccion
Comment
Rutinas de Coneccion
Comment
Interfaz de Terminal
Comment
Rutinas de Coneccion
Comment
Acceso a BD
Comment
Control y Análisis
Comment
![Page 74: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/74.jpg)
74
Tomado de:Rosenberg, Doug, Kendall Scott. Applying use case driven object modeling with UML: an annotated e-commerce example.
¿Cómo se relacionan los diagramas?Solo para comprender la
secuencia de pasos
![Page 75: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/75.jpg)
75
¿Cómo se relacionan los diagramas?Solo para comprender la
secuencia de pasos
Tomado de:Rosenberg, Doug, Kendall Scott. Applying use case driven object modeling with UML: an annotated e-commerce example.
![Page 76: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/76.jpg)
76
Tomado de:Rosenberg, Doug, Kendall Scott. Applying use case driven object modeling with UML: an annotated e-commerce example.
¿Cómo se relacionan los diagramas?Solo para comprender la
secuencia de pasos
![Page 77: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/77.jpg)
77
Tomado de:Rosenberg, Doug, Kendall Scott. Applying use case driven object modeling with UML: an annotated e-commerce example.
¿Cómo se relacionan los diagramas?Solo para comprender la
secuencia de pasos
¿Cómo se relacionan los diagramas?
![Page 78: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/78.jpg)
78
UML define una notación que se expresa como diagramas sirven para representar modelos/subsistemas o partes de ellos
El 80 por ciento de la mayoría de los problemas pueden modelarse usando alrededor del 20 por ciento de UML-- Grady Booch
Resumen
![Page 79: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/79.jpg)
79
El Proceso Unificado de Desarrollo
(Rational Unified Process- RUP)
![Page 80: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/80.jpg)
80
Rational Unified Process
RUP es un proceso para el desarrollo de software orientado a objeto que utiliza UML
para describir un sistema
Rational Software Corporation, 1998
![Page 81: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/81.jpg)
81
Rational Unified Process 5.0
Rational Objectory Process 4.1
Rational Objectory Process 4.0
Rational Approach Objectory
Process
Pruebas de rendimiento y carga(Performance Awareness)
Ingeniería de Negocios
Diseño OO de IU
Ingeniería de Datos(Vigortech)
UML 1.2
Proceso SQA(SQA Inc.)
UML 1.0
Administración de Configuración y Cambios
(Pure-Atria)
Escuela de Requerimientos(Requisite Inc.)
OMTBooch
UML 0.8
1998
1997
1996
1995
Ericsson method1967
1987
Evolución de RUP
![Page 82: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/82.jpg)
82
Estructura Estática de RUP
Fases e Iteraciones
Disciplinas del Proceso
Actividades, flujo de trabajo
Artefactos Modelos, reportes, documentos
Trabajadores
¿Cómo ocurre el proceso y sus
detalles?
¿Qué se produce u obtiene?
¿Quién lo hace o se responsabiliza?
¿Cuándo ocurre el proceso?
![Page 83: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/83.jpg)
83
Estructura Dinámica
Tiempo
Concepción Elaboración Construcción Transición
• Concepción Define el alcance del proyecto y eldesarrollo de los casos del
negocio.• Elaboración Planifica el proyecto, especifica
las características y define los
cimientos de la arquitectura.• Construcción Construye el producto.
• Transición Implementa el producto a sususuarios.
![Page 84: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/84.jpg)
84
Fases-Flujos de trabajo de RUP
![Page 85: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/85.jpg)
85
Características del ciclo de vida de RUP
Dirigido por Casos de Uso. Centrado en la arquitectura. Iterativo e incremental.
![Page 86: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/86.jpg)
86
Dirigido por Casos de Uso
Ciclo de vida de RUP
(Reflejar lo que los futuros usuarios necesitan y desean)
Representa los requerimientos
funcionales
Requisitos Análisis Diseño Implementación Prueba
Caso de Uso
Guían el proceso de desarrollo porque los modelos que se crean llevan a
cabo los casos de uso.
![Page 87: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/87.jpg)
87
Caso de Uso Realización de Análisis Realización de Diseño
Caso de Prueba
X
«trace» «trace»
«trace»«trace»
Pruebas Funcionales
PruebasUnitarias
Dirigido por Casos de Uso
Ciclo de vida de RUP
![Page 88: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/88.jpg)
88
Dirigido por Casos de Uso
Ciclo de vida de RUP
![Page 89: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/89.jpg)
89
Centrado en la arquitectura
Ciclo de vida de RUP
En la construcción,vista de:
A) Estructura.B) Calefacción.C) Plomería.D) Electricidad. Estáticos
DinámicosAspectos
![Page 90: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/90.jpg)
90
Centrado en la arquitectura
Ciclo de vida de RUP
(Visión común del sistema completo en la que desarrolladores y usuarios deben estar de acuerdo )
• Describe los elementos del modelo que son más importantes para su construcción, los cimientos del sistema que son necesarios como base para comprenderlo, desarrollarlo y producirlo económicamente.
• Se desarrolla mediante iteraciones comenzando por los CU relevantes desde el punto de vista de la arquitectura.
![Page 91: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/91.jpg)
91
Centrado en la arquitectura
Ciclo de vida de RUP
Vista lógica
Vista de componentes
Vista de despliegue
Vista física
Vista de Casos de uso Vista de
diseño
Vista de actividades
Vista de estado
Vista estática Vista de
Casos de uso
Vista de despliegue
Vista de componentes
Vista de Gestión del
modelo
Perfil
![Page 92: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/92.jpg)
92
Iterativo e incremental
Ciclo de vida de RUP
Hito de los Hito de los objetivosobjetivos
Hito de la Hito de la arquitecturaarquitectura
Hito de la Hito de la funcionalidad funcionalidad operativaoperativa
Hito de la Hito de la versión del versión del productoproducto
• Dentro de cada fase hay hitos (artefactos a construir) asociados a resultados de cada iteración.
• La terminación de una iteración produce un nuevo incremento.
![Page 93: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/93.jpg)
93
EnfoqueCascada
EnfoqueIterativo eIncremental
Iterativo e incremental
Ciclo de vida de RUP
![Page 94: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/94.jpg)
94
Grado de Finalización de Artefactos
Iterativo e incremental
Ciclo de vida de RUP
![Page 95: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/95.jpg)
95
Beneficios de la iteración
•Reduce el coste del riesgo al coste de un solo incremento.
•Menos riesgo de no sacar el producto al mercado en fecha.
•Acelera el ritmo de desarrollo.
•Las necesidades del usuario y correspondientes requisitos no pueden definirse completamente al principio. Se requieren iteraciones sucesivas.
![Page 96: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/96.jpg)
96
RUP
• RUP es un proceso que garantiza la elaboración de todas las fases de un producto de software orientado a objetos.
•RUP es dirigido por los casos de uso, centrado en la arquitectura, iterativo e incremental.
• RUP utiliza el UML.
• UML es un lenguaje que permite la modelación de sistemas con tecnología orientada a objetos
![Page 97: introducción a uml](https://reader031.vdocuments.net/reader031/viewer/2022013003/557e4e1ad8b42af46d8b484b/html5/thumbnails/97.jpg)
97
Desarrolloen equipos
UML y RUP
Lenguaje deModelamiento
ProcesoUnificado