Este documento describe un taller sobre modelado y diagramación de sistemas automatizados utilizando la herramienta Rational Rose. El taller cubrirá conceptos como ingeniería de software, UML, RUP y modelado de casos de uso, además de modelar y diagramar un sistema automatizado y utilizar la herramienta Rational Rose. El objetivo del taller es unificar conocimientos entre profesores, estandarizar el modelado en proyectos y utilizar herramientas CASE como recursos tecnológicos.

1. 1
Taller de Modelamiento y Diagramación de Sistemas
Automatizados con la utilización de las herramientas
CASE Rational Rose
Actividad N.- 1
www.modelado.pnfi.org
Ing. MSc. Douglas Galvis

2. 2
Contenidos:
1.- Objetivos del Taller.
2.- Conceptualizaciones sobre :
2.1 Ingeniería de Software.
2.2 Proceso Unificado de Desarrollo
2.3 Lenguaje Modificado de Modelación (UML)
2.4 El proceso Unificado de Desarrollo (RUP)
2.5 Modelado y Diagramación de Casos de
Usos del Negocio. (ejemplo tipo)
3.- Modelamiento y Diagramación de un Sistema
automatizado .
4.- Utilización de la Herramienta CASE Rational
Rose

3. 3
1.- Objetivos del Taller
 Unificación de los Conocimientos entre los
Profesores que dictan la Cátedra de Ingeniería de
Software, en las Unidades Curriculares de la malla
del PNFI, en los trayectos 2 y 3.
 Estandarizar el Modelamiento y la diagramación
en los Proyectos Sociotecnológicos al final de los
trayecto 2 y 4.
 Institucionalizar la utilización de Herramientas
CASE, para la elaboración del Modelamiento y
diagramado de los Sistemas, como recursos
tecnológicos en la formación de los profesionales
que egresan de la UPTEM

4. 4
Ingeniería del Software
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.

5. 5
Mejores prácticas para el trabajo
efectivo de un equipo en el
desarrollo del software.
(Dirige y organiza el proceso)
(Notación)

6. 6
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

7. 7
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

8. 8
Proceso de Desarrollo de
Software

9. 9
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

10. 10
Proceso de desarrollo de software (PDS)

11. 11
• 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)

12. 12
UML

13. 13
“ 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
= +

14. 14
(Forma de
expresar el
modelo)
Lenguaje de modelación
+=
(Descripción
de lo que
significa esa
modelación)

15. 15
• 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

16. 16
• 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

17. 17
• 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

18. 18
UML
DocumentarDocumentar
VisualizarVisualizar EspecificarEspecificar
ConstruirConstruir
Σ

19. 19
UML no es un método
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
El Object Management Group u OMG (de sus siglas en inglés Grupo de Gestión de Objetos) es un
consorcio dedicado al cuidado y el establecimiento de diversos estándares de tecnologías
orientadas a objetos, tales como UML, XMI, CORBA.

20. 20
 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

21. 21
Creación del UML
Booch method OMT
Unified Method 0.8OOPSLA ´95
OOSEOther methods
UML 0.9Web - June ´96
public
feedback
UML 1.5
UML 1.0UML partners
UML 2.0
Final submission to OMG, Sep ‘97
First submission to OMG, Jan ´97
UML 1.1
OMG Acceptance, Nov 1997 Version 1.1

22. 22
• 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?

23. 23
GRADY
BOOCH
IVAR
JACOBSON
JAMES
RUMBAUGH
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

24. 24
• 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

25. 25
Contribuciones a UML
Diagrama 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

26. 26
• 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

27. 27
• 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

28. 28
• 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

29. 29
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

30. 30
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?

31. 31
¿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::

32. 32
• 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
Modelos y DiagramasModelos y Diagramas

33. 33
Modelo de
Casos de Uso
Modelo de
Diseño
Modelo de
Implementación
Trazabilidad entre
los modelos
Secuencia
cronológica
ModelosModelos
Modelo de
Despliegue
Modelo de
Análisis
Modelo de
Prueba

34. 34
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

35. 35
• Casos de Uso y Diagramas de Casos de Uso
Diagramas de UML
Casos de uso
Diagrama de casos de uso

36. 36
 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
Cliente
Solicitar Préstamo

37. 37
• Diagramas de estructura estática
• Diagrama de clases
• Diagrama de Objetos
Diagramas de UML

38. 38
 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

39. 39
Diagramas UML
• Diagramas del comportamiento
•Diagramas de Estado
•Diagramas de Actividad
•Diagramas de Secuencia
•Diagrama de Comunicación
•Diagrama de tiempo
Diagrama de Secuencia Diagrama de Comunicación

40. 40
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 : int
nombre : 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

41. 41
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Í

42. 42
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

43. 43
: Encargado
:WInPréstamos
:Socio
:Video
:Préstamo
1: prestar(video, socio)
2: verificar situación socio
3: verificar situación video
4: registrar préstamo
5: entregar recibo
Diagrama de comunicación

44. 44
• Diagramas de implementación
• Diagramas de componentes
• Diagramas de instalación/Distribución
(Despliegue)
Diagramas de UML
Diagrama de componentes

45. 45
Interfaz de Terminal
Gestión de Cuentas Rutinas de conexión Acceso a BD
Control y Análisis
Diagrama de componentes

46. 46
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

47. 47
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

48. 48
¿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.

49. 49
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

50. 50
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?

51. 51
 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

52. 52
El Proceso Unificado de
Desarrollo
(Rational Unified Process- RUP)

53. 53
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

54. 54
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.)
OMT
Booch
UML 0.8
1998
1997
1996
1995
Ericsson
method1967
1987
Evolución de RUP

55. 55
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?

56. 56
Estructura Dinámica
Tiempo
Concepción Elaboración Construcción Transición
• 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.
• Construcción Construye el producto.
• Transición Implementa el producto a sus
usuarios.

57. 57
Fases-Flujos de trabajo de RUP

58. 58
Características del ciclo de vida de
RUP
• Dirigido por Casos de Uso.
• Centrado en la arquitectura.
• Iterativo e incremental.

59. 59
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.

60. 60
Caso de Uso Realización de Análisis Realización de Diseño
Caso de Prueba
X
«trace» «trace»
«trace»
«trace»
Pruebas Funcionales
Pruebas
Unitarias
Dirigido por Casos de Uso
Ciclo de vida de RUP

61. 61
Dirigido por Casos de Uso
Ciclo de vida de RUP

62. 62
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ámicos
Aspectos

63. 63
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.

64. 64
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

65. 65
Iterativo e incremental
Ciclo de vida de RUP
Hito de losHito de los
objetivosobjetivos
Hito de laHito de la
arquitecturaarquitectura
Hito de laHito de la
funcionalidadfuncionalidad
operativaoperativa
Hito de laHito de la
versión delversió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.

66. 66
Enfoque
Cascada
Enfoque
Iterativo e
Incremental
Iterativo e incremental
Ciclo de vida de RUP

67. 67
Grado de Finalización de Artefactos
Iterativo e incremental
Ciclo de vida de RUP

68. 68
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.

69. 69
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

70. 70
Desarrollo
en equipos
UML y RUP
Lenguaje de
Modelamiento
Proceso
Unificado