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

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

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

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

Mejores prácticas para el trabajo efectivo de un equipo en el

desarrollo del software.

(Dirige y organiza el proceso)

(Notación)

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

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

Proceso de Desarrollo de Software

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

Proceso de desarrollo de software (PDS)

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

UML

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

(Forma de expresar el

modelo)

Lenguaje de modelación

+=(Descripción

de lo que significa esa modelación)

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

• 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

• 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

UML

DocumentarDocumentar

VisualizarVisualizar EspecificarEspecificar

ConstruirConstruir

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

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

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

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

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

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

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

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

• 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

• 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

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

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

¿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

• 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

33

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

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

Casos de Uso y Diagramas de Casos de Uso

Diagramas de UML

Casos de usoDiagrama de casos de uso

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

ClienteSolicitar Préstamo

37

Diagramas de estructura estática Diagrama de clases Diagrama de Objetos

Diagramas de UML

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

Diagramas UML

Diagramas del comportamientoDiagramas de EstadoDiagramas de ActividadDiagramas de SecuenciaDiagrama de ComunicaciónDiagrama de tiempo

Diagrama de Secuencia Diagrama de Comunicación

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

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

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

: 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

44

Diagramas de implementación Diagramas de componentes Diagramas de instalación/Distribución

(Despliegue)

Diagramas de UML

Diagrama de componentes

45

Interfaz de Terminal

Gestión de Cuentas Rutinas de conexión Acceso a BD

Control y Análisis

Diagrama de componentes

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

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

¿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

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

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

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

El Proceso Unificado de Desarrollo

(Rational Unified Process- RUP)

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

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

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

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.

57

Fases-Flujos de trabajo de RUP

58

Características del ciclo de vida de RUP

Dirigido por Casos de Uso. Centrado en la arquitectura. Iterativo e incremental.

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

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

61

Dirigido por Casos de Uso

Ciclo de vida de RUP

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ámicosAspectos

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

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

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.

66

EnfoqueCascada

EnfoqueIterativo eIncremental

Iterativo e incremental

Ciclo de vida de RUP

67

Grado de Finalización de Artefactos

Iterativo e incremental

Ciclo de vida de RUP

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

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

Desarrolloen equipos

UML y RUP

Lenguaje deModelamiento

ProcesoUnificado