Академический Документы
Профессиональный Документы
Культура Документы
Semana 1
Sesión 2 a 4
Contenido General
Contenido de la sesión:
Parte I: Introducción a UML.
Parte II: Introducción al Proceso Unificado.
Parte I:
Introducción a UML
PARTE I. CONTENIDO
1. Objetivos.
2. Introducción.
3. La Orientación a Objetos, OO.
4. El Lenguaje Unificado de Modelado.
(Elementos, Relaciones, Diagramas).
5. Cómo utilizar UML.
6. Bibliografía.
1. Objetivos:
1.1. Objetivos
2. Introducción:
2.1. Introducción
2. Introducción:
Modela
2.2. Introducción
2. Introducción:
2.3. Introducción
3. La Orientación a Objetos, OO:
Interfaces Protocolos
4.1. El UML
4. El Lenguaje Unificado de Modelado:
4.2. El UML
4. El Lenguaje Unificado de Modelado:
4.3. El UML
4. El Lenguaje Unificado de Modelado:
4.4. El UML
4. El Lenguaje Unificado de Modelado:
Elementos estructurales:
Clase activa
4.5. El UML
4. El Lenguaje Unificado de Modelado:
Elementos estructurales:
4.6. El UML
4. El Lenguaje Unificado de Modelado:
Elementos estructurales:
4.7. El UML
4. El Lenguaje Unificado de Modelado:
Elementos de comportamiento:
4.8. El UML
4. El Lenguaje Unificado de Modelado:
Elementos de agrupación:
Elementos de notación:
4.9. El UML
4. El Lenguaje Unificado de Modelado:
Relaciones: Abstracciones que actúan de unión entre los
elementos.
Es una relación entre dos elementos, tal que un cambio en uno
Dependencia puede afectar al otro.
4.10. El UML
4. El Lenguaje Unificado de Modelado:
Diagramas: Disponen un conjunto de elementos, que
representan el modelo desde distintas perspectivas.
UMLtiene nueve diagramas fundamentales, clasificados
en dos grupos, uno para modelar la estructura estática del
sistema y otro para modelar el comportamiento dinámico.
4.11. El UML
4. El Lenguaje Unificado de Modelado:
Diagrama de Clases:
4.12. El UML
4. El Lenguaje Unificado de Modelado:
Diagrama de Clases:
Las relaciones pueden traer asociada una multiplicidad, expresada “en el lado opuesto” de
la relación. Resume el número de posibles instancias de una clase asociadas a una única
instancia de la clase en el otro extremo.
Multiplicidad Significado
1 Una única instancia
N/* N instancias
0..N / 0..* Entre ninguna y N instancias
1..N / 1..* Entre una y N instancias
0..1 Ninguna o una instancia
N..M Entre N y M instancias
4.13. El UML
4. El Lenguaje Unificado de Modelado:
Diagrama de Clases:
En las relaciones de
dependencia un
cambio en la clase
dependida afectará la
clase dependiente.
Compartimentos de la clase: Acceso de atributos y métodos:
primero nombre “+” público
segundo atributos “-” privado (sólo los métodos),
tercero métodos “#” protegido (sólo clases hija).
4.14. El UML
4. El Lenguaje Unificado de Modelado:
Diagrama de Clases:
Diagrama de Objetos:
Los diagramas de objetos son análogos a los de clases, con la particularidad de que en
lugar de encontrar clases, encontramos instancias de éstas. Son útiles para explicar partes
pequeñas del modelo en las que hay relaciones complejas
4.15. El UML
4. El Lenguaje Unificado de Modelado:
Diagrama de Componentes:
4.16. El UML
4. El Lenguaje Unificado de Modelado:
Diagrama de Despliegue:
Los diagramas de despliegue sirven para modelar la configuración hardware del sistema,
mostrando qué nodos lo componen
4.17. El UML
4. El Lenguaje Unificado de Modelado:
Las líneas que unen los Actores con los Casos de Uso
(óvalos) representan una asociación de comunicación.
4.18. El UML
4. El Lenguaje Unificado de Modelado:
Los Casos de Uso pueden acompañarse de texto que enriquezca el lenguaje gráfico.
4.19. El UML
4. El Lenguaje Unificado de Modelado:
estereotipo
generalización
4.20. El UML
4. El Lenguaje Unificado de Modelado:
Diagrama de Secuencia:
Describen cómo los objetos del sistema colaboran.
Orden participación
4.21. El UML
4. El Lenguaje Unificado de Modelado:
Diagrama de Secuencia:
Los rectángulos verticales son barras de activación. Representan la duración de la
ejecución del mensaje.
Mensaje asíncronos: El emisor puede enviar otros mientras éste está siendo procesado.
Es independiente a otros mensajes.
Mensaje síncronos: El emisor debe esperar que termine el tiempo de proceso de éste
para enviar nuevos mensajes.
4.22. El UML
4. El Lenguaje Unificado de Modelado:
Diagrama de Colaboración:
Son otro tipo de diagramas de interacción. Contienen la misma información que los
diagramas de secuencia, pero se centran en la responsabilidad de cada objeto en lugar
de en el tiempo en que los mensajes son enviados
4.23. El UML
4. El Lenguaje Unificado de Modelado:
Diagrama de Estados:
Muestran los posibles estados en que puede encontrarse un objeto y las transiciones que
pueden causar un cambio de estado. El estado de un objeto depende de la actividad que
esté llevando a cabo o de alguna condición.
Circunstancia o condición inicio Resultado de
que provoca la transición actividad
acción
fin
4.24. El UML
4. El Lenguaje Unificado de Modelado:
Diagrama de Estados:
Los estados pueden anidarse, agrupando estados relacionados en un estado compuesto.
Puede ser necesario cuando una actividad involucra actividades concurrentes o asíncronas.
4.25. El UML
4. El Lenguaje Unificado de Modelado:
Diagrama de Actividades:
Son diagramas de flujo
adornados, con mucha
similitud a los diagramas
de estados.
4.26. El UML
5. Cómo utilizar UML:
UML es simplemente un lenguaje. Define un conjunto de
elementos y las relaciones entre ellos y esto se emplea para
definir modelos.
Vista de Diseño: Engloba las clases e interfaces que conforman el vocabulario del problema
y su solución. Da soporte a los requisitos funcionales del sistema, es decir los servicios que
proporciona a los usuarios finales. Con UML los aspectos estáticos de esta vista se pueden
concretar con los diagramas de clases y de objetos; los aspectos dinámicos con los
diagramas de iteración (secuencia y colaboración), diagramas de estados y de actividades.
Vista de Despliegue: Engloba los nodos que forman la topología hardware sobre el que se
ejecuta el sistema. Da soporte a la distribución, entrega e instalación de las partes que
conforman el sistema físico. Con UML los aspectos estáticos de esta vista se pueden
concretar con los diagramas despliegue; los aspectos dinámicos con los diagramas de
iteración (secuencia y colaboración), diagramas de estados y de actividades.
1. Iniciar y mantener reuniones con los usuarios finales del programa, para
comprender sus necesidades, el contexto en que lo usarán y todos los detalles
necesarios para comprender el ámbito del problema a resolver. Esta información
será empleada para capturar las actividades y procesos involucrados y
susceptibles de ser incorporados en el programa, a un nivel alto, y proporcionará
la base para construir la vista de Casos de Uso.
7.1. OBJETIVOS
8. Conceptos fundamentales
• Proceso:
– Es un marco de trabajo común compuesto por
actividades de trabajo (conjuntos de tareas, hitos,
productos y puntos de garantía de calidad) y
actividades de protección (garantía de calidad, gestión
de configuración y medición) (Pressman 2001).
• Producto:
– Es el resultado previsto y consistente del proceso.
% Implementación
% Conocimiento
Conocimiento
Implementación
Tiempo
PRINCIPIOS
PRINCIPIOSDE
DE
LA
LA INGENIERÍADEL
INGENIERÍA DELSOFTWARE
SOFTWARE
NORMAS
TÉCNICAS
NORMAS
NORMASDE DE OTRAS
LA NORMAS
LA INGENIERÍADEL
INGENIERÍA DELSOFTWARE
SOFTWARE
ESTÁNDARES
MODELOS METODOLOGÍAS
MODELOSDE
DE METODOLOGÍAS
RUP
PROCESO / /PARADIGMAS
PARADIGMAS
PROCESO
PROCESO
TÉCNICAS
TÉCNICAS HERRAMIENTAS
HERRAMIENTAS
PRODUCTO
Flujos de trabajo
del proceso Iniciación Elaboración Construcción Transición
Modelado del
negocio
Requisitos
Análisis y diseño
Implementación
Pruebas
Despliegue
Flujos de trabajo
de soporte
Gestión del cambio
y configuraciones
Gestión del proyecto
Entorno
X,Y,Z:
(y,z): tipos de Configuraciones
modelos del sistema
tiempo
X: Fases
Y: Flujos
de trabajo esfuerzo (x,y): iteraciones
F5: Pruebas
F6: Despliegue
Flujos de trabajo
de soporte
F7: Gestión del cambio
y configuraciones
F8: Gestión del proyecto
F9: Entorno
Iteraciones Iter Iter Iter Iter Iter Iter Iter
preliminares#1 #2 #n #n+1 #n+2 #m #m+1
F2 F2 F3 F2
F1 F1 F4
F3 F3 F1
F9 F9 F9
F4 F4
F8
F8 F5 F8
F5 F5 F7
F6 F7 F6 F6 F7
Modelado del
negocio
Requisitos
Análisis y diseño
Implementación
Pruebas
Despliegue
Flujos de trabajo
de soporte
Gestión del cambio
y configuraciones
Gestión del proyecto
Entorno
Modelo de
Casos de Uso verificado por
Est. Din. Est. Din. Est. Din. Est. Din. Est. Din. Est. Din. Est. Din. Est. Din. Est. Din.
Diagram a de
Casos de Uso X X X
Diagram a de
Interacción- X X X X X X X X
Secuencia
Diagram a de
Interacción- X X X X X X X X
Colaboración
Diagram a de
Clases de X
Análisis
Diagram a de
Objetos de X
Análisis
Diagram a de
Clases de X X
Diseño
Diagram a de
Objetos de X X
Diseño
Diagram a de
Estados X X X X X X
Diagram a de
Actividades X X X X X
Diagram a de
Com ponentes X
Diagram a de
Despliegue X
Vista de casos Proyecta el comportamiento del sistema tal y como Diagramas de casos de Diagramas de interacción
de uso es percibido por los: usuarios finales, analistas y en- uso Diagramas de estados
cargados de las pruebas. Especifica las fuerzas que
configuran la arquitectura del sistema.
Vista de diseño Soporta los requisitos funcionales del sistema: servi- Diagramas de clases Diagramas de interacción
cios proporcionados a los usuarios finales. Vocabula- Diagramas de objetos Diagramas de estados
rio del problema y su solución: clases, interfaces y
colaboraciones. Diagramas de actividades
Vista de procesos Cubre el funcionamiento, capacidad de crecimiento y Diagramas de clases Diagramas de interacción
rendimiento del sistema. Mecanismos de sincroniza- (activas) Diagramas de estados
ción y concurrencia del sistema: hilos y procesos. Diagramas de objetos Diagramas de actividades
Vista de implementa- Cubre la gestión de configuraciones de las distintas Diagramas de componen- Diagramas de interacción
ción versiones de un sistema a partir de componentes y tes Diagramas de estados
archivos quasi-independientes. Ensamblado y dispo-
nibilidad del sistema: componentes y archivos. Diagramas de actividades
Vista de despliegue Contiene los nodos que forman la arquitectura (topo- Diagramas de despliegue Diagramas de interacción
logía) hardware sobre la que se ejecuta el sistema a Diagramas de estados
través de sus componentes. Está destinada a repre-
sentar la distribución, entrega e instalación de las Diagramas de actividades
partes que forman el sistema informático físico.
Vista de Estática
Diseño
Dinámica
Vista de Estática
Procesos
Dinámica
Vista de
Estática
Implemen-
tación
Dinámica
Vista de Estática
Despliegue
Dinámica
1. Conjunto de requisitos:
• Agrupa toda la información que describe lo que debe
hacer el sistema.
• Puede comprender un modelo de casos de uso, un
modelo de requisitos no funcionales, un modelo del
dominio, un modelo de análisis y otras formas de
expresión de las necesidades del usuario, incluyendo
pero no limitándose a maquetas, prototipos de la
interfaz, restricciones legales, etc.
2. Conjunto de diseño:
• Agrupa información que describe cómo se va a
construir el sistema y captura las decisiones acerca
de cómo se va realizar, teniendo en cuenta las
restricciones de tiempo, presupuesto, aplicaciones
existentes, reutilización, objetivos de calidad y
demás consideraciones.
• Puede implicar un modelo de diseño, un modelo de
pruebas y otras formas de expresión de la naturaleza
del sistema, incluyendo, pero no limitándose, a
prototipos y arquitecturas ejecutables.
3. Conjunto de implementación:
• Agrupa toda la información acerca de los elementos
software que comprende el sistema, incluyendo,
pero no limitándose, a código fuente en varios
lenguajes de programación, archivos de
configuración, archivos de datos, componentes
software, etc., junto con la información que describe
cómo ensamblar el sistema.
4. Conjunto de despliegue:
• Agrupa toda la información acerca de la forma en
que se empaqueta actualmente el software, se
distribuye, se instala y se ejecuta en el entorno
destino.
Análisis OO
Espacio de la
Solución de
Implementación
Diseño OO
Espacio de la
Diseño
Solución Técnica
Modelado del
negocio Requisitos
Requisitos
Análisis y diseño
Implementación
Pruebas
Despliegue
Flujos de trabajo
de soporte
Gestión del cambio
y configuraciones
Gestión del proyecto
Entorno
SubModelo de Casos
de Uso de Negocio
SubModelo de Casos
Diagrama de Contexto de Uso (Técnico)
del SMCU Técnico
Diagrama Principal
Busi ness Use-Case
del Modelo de Casos M odel
Us e-Cas e Model
Diagrama de Contexto
del MCU
Modelado del
negocio
Requisitos
Pruebas
Despliegue
Flujos de trabajo
de soporte
Gestión del cambio
y configuraciones
Gestión del proyecto
Entorno
NIVEL1
«trace»
«trace»
Proceso de Conversión:
caso de uso (MCU) Realización (MA)
Casos de Uso
Análisis
Interfaz Gestor/Control Entidad
Diagrama de
Clases de Análisis
Atómico
I_Autenticacion C_Verificador_Autenticacio
n
Servicio(CU)-Subsistema(DA)
MCU MA
Top-Down Nivel 0 Subsistema 1 Nivel 0 Bottom-Up
MA
MCU Subsistema 2
Nivel 1
Nivel 1
Subsistema 3
MCU MA
Nivel 2 Nivel 2
Nivel i Nivel j
MODELO DE CASOS DE USO MODELO DE ANÁLISIS Cliente I_Cajero C_Ges tor_Interfaz Cta_Cliente
«trace»
Diagrama de Clases
de Análisis de Contexto
Modelo de
Casos de Uso verificado por
especificado por
Modelo de
distribuido por Prueba
realizado por
Modelo de
Análisis
Modelo de implementado por
Diseño
Flujo de
Análisis y Modelo de
Diseño Despliegue
Modelo de
Transición del MCA hacia el MD
Implementación
<<trace>> <<process>>
Gestor de cliente Facturas Albarán
<<trace>>
Gestor de clientes
<<Interface_design>>
Teclado
<<trace>>
<<Interface_design>>
<<trace>> Pantalla
<<Interface_design>>
<<trace>> Puerto MSVL
<<trace>>
<<Interface_design>>
Interfaz de terminal celular Altavoz
<<Interface_design>>
<<trace>> Micrófono
Top-Down
+
Level-to-Level
Subsistema(DA)-Subsistema(DD)
Bottom-Up MA MD
Nivel 0 Subsistema 1
Nivel 0
Subsistema 1
MA
Nivel 1 Subsistema 2 MD
Nivel 1 Subsistema 2
Subsistema 3
MA Subsistema 3 Top-Down
MD
Nivel 2 Nivel 2
MA MD
Nivel j Nivel i
Modelo de
Casos de Uso
MA
Nivel 1 MD
F01.01 Consulta saldo
Nivel 1
asociación
Punto Figura_2D
define
Coord_X : Double Centro : Punto
Coord_Y : Double Superficie : Doubl e
Instancias de Instancia de
la c lase Punto la clase
Cliente I_Cajero
MA C_Ges tor_Interfaz Cta_Cliente
MD
abstracción
Figura_2D
Nivel 2 <<object>>
Punto: Pto_1
Coord_X = 5 Nivel 2
define Figura_2D: Triángulo_T1
Coord_Y = 6
define
<<object>> define
MA MD
<<object>>
Punto: Pto_2
Modelo de
Casos de Uso
Diagrama de Clases
de Diseño de Contexto
Modelo de
Casos de Uso verificado por
especificado por
Modelo de
distribuido por Prueba
realizado por
Modelo de
Análisis
Modelo de implementado por
Diseño
Flujo de Flujo de
Análisis y Modelo de Implementa
Diseño Flujo de Despliegue ción
Despliegue
Modelo de
Transición del MD hacia el MDP
Implementación
Modelo de
Implementación
(Vista parcial)
Gestión individuos
Ges tor Base de Datos
Programa Principal
Gestión Interfaces
Gestión Agentes
Gestión Cálculo
componentes
Modelo de Despliegue
(Vista parcial)
nodos /
procesadores
17.1. Resumen
17. Resumen
• La aplicación formal del Proceso Unificado
supone:
– Desventajas:
• Grandes esfuerzos en la construcción de modelos.
• Necesidad del soporte de herramientas informáticas.
– Ventajas:
• Disminuye el riesgo del error de análisis / diseño
acumulado.
• Aligera el esfuerzo en implementación.
• Proporciona la documentación del ciclo de vida en el
mismo proceso.
17.2. Resumen
17. Resumen
• El Proceso Unificado es flexible y se puede adaptar al
grado de complejidad del modelo de proceso de desarrollo
(descarte de algunos modelos o flujos).
• El Proceso Unificado es abierto y permite la incorporación
de enfoques y artefactos complementarios:
– Patrones de diseño.
– Patrones de implementación.
– Marcos de diseño.
– Combinación de varios modelos de proceso.
– Arquitecturas Dirigidas por Modelos (Model Driven
Architectures).
– Ejecutabilidad de modelos: UML 2, validación y verificación
formales.
17.3. Resumen
18. Bibliografía
1. Booch G., Rumbaugh J., Jacobson I. El Lenguaje Unificado de Modelado,
Addison-Wesley, Madrid, 1999.
2. Bruegge B., Dutoit A.H. Ingeniería de Software Orientado a Objetos,
Prentice Hall– Pearson educación, México, 2002.
3. Jacobson I., Booch G., Rumbaugh J. El Proceso Unificado de Desarrollo de
Software, Addison-Wesley, Madrid, 2000.
4. Pressman R.S. Ingeniería del Software. Un enfoque práctico (5ª ed.) Mc
Graw-Hill; New York , 2001.
5. Rumbaugh J., Jacobson I., Booch G. El Lenguaje Unificado de Modelado.
Manual de Referencia, Addison-Wesley, Madrid, 2000.
6. Sommerville I. Ingeniería de software, 6ª edición, Prentice Hall – Pearson
educación, México, 2002.
7. Stevens P., Pooley R. Utilización de UML en Ingeniería del Software con
Objetos y Componentes, Addison-Wesley, Madrid, 2002.
8. http://www.omg.org
9. http://www.uml.org