Modelamiento de Software y Negocios

Jorge Maturana OrtizSeptiembre 2004

Tabla de Contenidos� PARTE I: Modelamiento de Software� 1. ¿Por qué modelar?� 2. ¿Qué es UML?� 3. Elementos de Orientación a Objetos� 4. Estructura de UML� 5. Diagramas de UML� 6. Trazabilidad� PARTE II: Modelamiento de Negocios� 7. Modelamiento de Negocios con IDEF� 8. Modelamiento de Negocios con UML (Eriksson-Penker)� 9. Diagramas UML para Modelamiento de Negocios� PARTE III: Herramientas� 10. Demostración de Enterprise Architect (UML)� 11. Demostración de AllFusion BPWin (IDEF)

¿Por qué modelar?

Casas de perro y rascacielos

¿Qué es un Modelo?

� Representación simplificada de la realidad� Recoge sólo aspectos de interés� Promueve entendimiento

� Útil para:� Comprender� Describir� Predecir� Responder preguntas

� SW: Modelar es diseñar aplicaciones de SW antes de codificarlas

Modelos de Software: ¿para qué?

� Disminuye costos de falla� Importancia del modelamiento aumenta con el tamaño de los proyectos de SW (casas de perro - rascacielos)

� Aspectos de Calidad de SW:�Externa (observable)� Interna (no observable)

Principios de modelado

� 1. Elegir los modelos a utilizar que sirvan al propósito deseado

� 2. Los modelos pueden ser expresados en distintos niveles de precisión

� 3. Mientras más coherente sea un modelo con la realidad, mejor

� 4. Cualquier sistema no trivial se aborda mejor con varios modelos casi independientes

¿Qué es UML?

¿Se come?

¿Qué es UML?� Lenguaje para especificar, visualizar, y documentar modelos de sistemas de software

� Orientado a Objetos� Lenguaje, NO método de desarrollo� Diagramas se agrupan en 5 perspectivas:

� Usuario� Estructura� Comportamiento� Implementación� Despliegue

Historia de UML� 1970-1980: Aparecen varios lenguajes OO� 1994: Más de 50 Lenguajes de modelamiento diferentes� Lenguajes se empiezan a mezclar, emergiendo los más

predominantes� Booch, Rumbaugh y Jacobson se unen bajo el alero de Rational� 1996: UML 0.9� 1997: UML 1.0 (UML Partners Consortium)� 1997: UML 1.1� 1998: UML 1.2� 1999: UML 1.3� 2000: UML 1.4� Fines de 2004: UML 2.0

Elementos de Orientación a Objetos

Acercándose al paradigma

Clases y Objetos

“reloj”Variables: hora

minuto

Métodos: fijar horadar hora

Relación entre clases

Reloj

Reloj demanecillasReloj

digital

Herencia: establece una jerarquía de clases. Se heredan las características de los padres

pertenece a(asociación)

tiene(agregación)

Asociación: relación simple entre clases

Agregación: relación estrecha entre clases

Estructura de UML

4 + 1 = 5

•Diagrama de Clases•Diagrama de objetos

•Diagrama de Casos de Uso

•Diagrama de Secuencia•Diagrama de Colaboración•Diagrama de Actividades•Diagrama de Estados

•Diagrama de Deployment

•Diagrama de componentes

Vistas de UML – Modelo 4+1

Diagramas de Clase

La estructura

Diagrama de Clases: ¿Para qué?

� “Corazón” de un Modelo UML� Muestra estructura estática de clases en un sistema� Representa:

� Clases con sus variables y métodos� Interfaces� Colaboraciones y relaciones entre clases

� Utilizado para modelar la realidad o un sistema computacional a construir

� Diferentes perspectivas: desde conceptual a implementación

Diagrama de Clases: Elementos (1/2)

� Clase: Abstracción de entidad que indica variables y métodos

� Herencia: relación de especialización entre clases

� Asociación: relación entre clases, puede poseer navegabilidad y multiplicidadPersona Reloj

1 *

Reloj- hora: int- minuto: int

+ fijarHora() : void+ darHora() : hora

Reloj

Reloj_Manecillas

Diagrama de Clases: Elementos (2/2)Reloj_Manecillas Manecilla

� Composición: Relación fuerte entre objetos “compuesto de”

� Interfaz: Comportamiento estándar que es implementado (realizado) por una clase

� Clase asociada: Clase que nace de la asociación entre otras dos, y que no tiene sentido sin ella

Int_Reloj

«realize»

Reloj

Arrendatario Departamento

Contrato

Diagrama de Clases: Ejemplo

Cliente

- rut: int- nombre: string- renta_mensual: int

Cuenta

- numero: int- saldo: int- cliente: Cliente- estado:

+ abonar() : void+ creditar() : void+ retornar_saldo() : void+ transferir_dinero() : void+ abonar_a_cuentas() : void

Cta_Corriente

- sobregiro: int

+ calcular_multas() : void

Cta_Ahorro

- giros_anuales: int- tasa_interés: int

+ calcular_interes() : void

Interfaz_Cuenta

Transacción_Redbanc

+ girar_dinero() : void+ consultar_saldo() : void+ pagar_cuentas() : void+ depositar_dinero() : void

Transacción_Web

+ consultar_saldo() : void+ pagar_cuentas() : void+ transferir_fondos() : void

Contrato

- fecha_Inicio: date- ejecutivo_responsable: string- plan: Plan_de_contrato

Plan_de_contrato

- nombre_plan: string- interés_extra: float- adicionales_gratis: int

10..*

«realize»

herencia

interfaz

clase asociada composición

navegabilidad

asociación

multiplicidad

atributos

métodos

clase

realización

Tarjetas CRC

Identificando clases

CRC: Clase-Responsabilidad-Cooperación

� Método para facilitar la identificación de clases

Repositorio CuentasRepositorio Usuarios

Datos de transacciónUsuario actualGiro de dineroAbono de dineroConsulta de saldo

Transacción bancarianombre clase

datos y accionescolaboradores

Diagramas de Objetos

Clases en acción

Diagrama de Objetos: ¿Para qué?

� Muestra la estructura de los objetos en tiempo de ejecución

� Ilustra un caso particular: una “foto”� Muestra:

�Objetos vivos�Relaciones entre objetos

Diagrama de Objetos: Elementos

Juan:Persona Boby:Perro

� Objetos: Instancias de clases. Objetos “vivos”

� Enlace: Relación entre dos objetos vivos

Juan:Persona

Diagrama de objetos: Ejemplo

Renato Ruiz :Cliente

1203332 :Cta_Corriente

103 :Contrato

Preferencial :Plan_de_contrato

objeto

enlace

enlaceAsociación

ObjetoClase

Diagrama de objetosDiagrama de clases

Diagramas deCasos de Uso

Entendiendo al cliente

Diagrama de CU: ¿Para qué?

� Muestra el comportamiento desde un punto de vista externo (cliente)

� Se enfoca en QUÉ, no CÓMO

� Útil para organizar y modelar el comportamiento de un sistema

� También sirve para modelar sistemas existentes

Diagrama de CU: Elementos (1/2)

� Actor: Entidad que interactúa con el sistema (personas / otros sistemas)

� Caso de Uso: Secuencia de acciones que produce un resultado útil y observable para un actor

� Límite: Barrera que define el interior y el exterior del sistema

Cliente

Compra combo

Diagrama de CU: Elementos (2/2)

Compra combo Pago«include»

Compra combo Agranda combo«extend»

Compra Compra Combo

Cliente

Compra � Asociación: Relación de uso entre un actor y un Caso de Uso

� Inclusión: Comportamiento de un caso de uso “invocado” por otro

� Extensión: Comportamiento alternativo de un Caso de Uso, se pone aparte

� Herencia: Relación de especialización entre Casos de Uso.

Diagrama de Casos de Uso: Ejemplo

cliente

Consultar saldo

validar usuario

solicitar préstamo

realizar transacción

«extend»

«include»

actor

caso de usoasociación

extensión

inclusión

herencia

límite del sistema

Diagramas de Análisis de Robustez

De las ideas a la estructura

Diagrama de Robustez: ¿Para qué?

� Sirve como un puente para pasar del análisis al diseño

� Ayuda a identificar principales bloques de la estructura

� Muestra diferencias entre tipos de elementos que constituirán el sistema

Diagrama de Robustez: Elementos

Interfaz

Motor Clientes

Repositorio OT

� Actor: Entidad que interactúa con el sistema

� Clase límite: Representa una interfaz con un actor

� Clase Control: Representa un elemento con lógica del sistema

� Clase Entidad: Representa un elemento con conocimiento de los datos

� Límite: Define interior y exterior del sistema

Cliente

Diagrama de Robustez: Ejemplo (1/3)

cliente

Consultar saldo

validar usuario

solicitar préstamo

realizar transacción

«extend»

«include»

ClienteInterfaz Redbanc

Motor transacciones

Motor Usuarios Repositorio Usuarios

Repositorio Cuentas

Diagrama de Robustez: Ejemplo (2/3)

ClienteInterfaz Redbanc

Motor transacciones

Motor Usuarios Repositorio Usuarios

Repositorio Cuentas

Redbanc

Usuario

Cuenta

Transaccion

Cliente

Diagrama de Robustez: Ejemplo (3/3)

ClienteInterfaz Redbanc

Motor transacciones

Motor Usuarios Repositorio Usuarios

Repositorio Cuentas

clase límite

clase entidad

clase controlasociación

actor

límite

Diagramas de Secuencia

Líneas de vida

Diagrama de Secuencia: ¿Para qué?

� Describe vista dinámica de un sistema

� Resalta la ordenación temporal de los mensajes

� Muestra creación y destrucción de objetos

� Describe un escenario concreto

Diagrama de Secuencia: Elementos

Motor

método(parámetro)

ack

Objeto: Instancia de una clase que participa en la acción

Línea de Vida: Línea que indica el tiempo durante el cual el objeto vive

Mensaje: Invocación de un objeto a un método propio o de otro objeto

Respuesta: Mensaje de respuesta a una invocación

Muerte: Término de la vida de un objeto, provocado por un mensaje

Diagrama de Secuencia: Ejemplo

Cliente

Cta_Corriente Cta_AhorroRedbanc

Transacción

traspasar dinero

Inicia transacción

traspaso(monto)consulta saldo

saldo

saldo suficiente

debita(monto)

okabona(monto)

oktransacción ok

transacción ok

línea de vidamensaje

respuesta

muerte

objeto

Diagramas de Colaboración

Ayúdeme usted compadre

Diagrama de colaboración: ¿Para qué?

� Propósito similar al diagrama de secuencia: mostrar interacción entre objetos

� Resalta la organización estructural de los objetos que interactúan

� Muestra Objetos, Enlaces y Mensajes

� En UML 2.0 se llama “Diagrama de Comunicación”

Diagrama de colaboración: Elementos

Objeto: Instancia de una clase que participa en la acción

Enlace: Línea que indica relación estructural entre objetos

Mensaje: Invocación de un objeto a un método propio o de otro objeto, posee un número de secuencia para reconocer el orden

Cliente Cuenta

1: método()

Cliente

Diagrama de colaboración: Ejemplo

Transacción Cta_Corriente

Cta_Ahorro

1: consulta saldo

1.1: saldo

1.2: saldo suficiente

1.3: debita(monto)

1.4: ok

1.5: abona(monto)

1.6: ok

objeto

mensaje

enlace

¿Secuencia o Colaboración?

ColaboraciónMuchos objetos

Secuencia

Preferible ColaboraciónPocos objetos

Muchos Mensajes

Pocos Mensajes

Diagramas de Actividad

Pasos a seguir

Diagrama de Actividades: ¿Para qué?

� Muestra flujo de actividades de un sistema

� Parecido a diagramas de flujo

� Admite semántica de concurrencia y sincronización

� Permite modelar decisiones

� Se puede utilizar para modelar negocios

Diagrama de Actividades: Elementos

Actividad

Inicio: Punto en donde se inician las actividades

Actividad: Acción o conjunto de acciones a ejecutarse

Barra de sincronización: Indica el comienzo (fork) o sincronización (join) de actividades concurrentes

Transición: Denota traspaso del control desde una actividad a otra

Decisión: Flujos de control alternativos

Fin: Denota término de actividades

Diagrama de Actividad: Ejemplo

inicio

fin

actividad

fork

join

decisión

transición

Consulta a DicomConsulta a BD clientes

Recopilar informacion decliente

Rechazar clienteabrir cuenta

¿cliente apto?

sí no

Diagramas de Estados

¿Cómo estás?

Diagrama de Estado: ¿Para qué?

� Máquina de estados que describe el ciclo de vida de un sistema o un objeto del sistema

� Identifica estados posibles y qué causas provocan los cambios de un estado a otro

� Resalta comportamiento en función de eventos

Diagrama de Estado: Elementos

Inicio: Punto en donde se inician las actividades

Estado: Condición reconocible dentro de un conjunto finito en los que se puede hallar un sistema u objeto

Transición: Paso de un estado a otro gatillado por un evento

Fin: Denota término de ciclo de vida

esperando

evento

Diagrama de Estados: Ejemplo

activa congelada

congelada durante una año

apertura por cliente

reapertura por cliente

inutilización durante un año

cierre por cliente

inicio

fin

estado

transición

cuenta cerrada

Diagramas de Componentes

De lo lógico a lo físico

Diagrama de Componentes:¿Para qué?

� Muestra los componentes físicos del software (archivos, BD’s)

� Muestra tipos de componentes y relaciones entre ellos

� Normalmente se relaciona con diagramas de clase

Diagramas de Componentes: Elementos

«realize»

<<dll>>Transacciones

Interfaz Clientes

Componente: Parte física de software: archivo

Dependencia: Relación de necesidad de un componente por otro

Interfaz: Comportamiento estándar que es implementado (realizado) por un componente

Realización: Indica que un componente implementa el comportamiento definido por la interfaz

Diagrama de Componentes: Ejemplo (1/2)

Redbanc

Usuario

Cuenta

Transaccion

Cliente

Redbanc

Motor Clientes

Motor Cuentas

Interfaz Clientes

Interfaz Cuentas

«realize»

«realize»

Diagrama de Componentes: Ejemplo (2/2)

Redbanc

Motor Clientes

Motor Cuentas

Interfaz Clientes

Interfaz Cuentas

«realize»

«realize»

componente

interfaz

realización

dependencia

Diagramas de Despliegue

Cada cosa en su lugar

Diagrama de Despliegue: ¿Para qué?

� Muestra información del Hardware (PC’s, PDA’s, servidores, etc.) y sus conexiones

� Modela el mapeo SW / HW

� Al igual que los Diagramas de componentes, muestra dependencia entre componentes

Diagrama de Despliegue: Elementos«Servidor UNIX»

Servidor Aplicaciones

Client DB

Client Server

Nodo: Recurso de Hardware en donde se aloja algún componente

Enlace: Conexión entre nodos

Componente: Parte física de software: archivo

Dependencia: Relación de necesidad de un componente por otro

Diagrama de Despliegue: Ejemplo

Máquina Redbanc «unix»Servidor Banco

Motor Clientes

Motor Cuentas

Interfaz Clientes

Interfaz Cuentas

Redbanc

«realize»

«realize»

nodo

componenteenlace

dependencia

Diagramas de paquetes

Agrupando la multitud

Diagrama de Paquetes: ¿Para qué?

� Agrupa elementos de un diagrama para facilitar su comprensión

� Aplicable a todos los diagramas de UML

Diagrama de Paquetes: Elementos

Repositorios

+ Repositorio Cuentas+ Repositorio Usuarios

Paquete: Recurso de Hardware en donde se aloja algún componente

Dependencia: Relación de necesidad de un paquete por otro (Nace de la relación de elementos que se encuentran en distintos paquetes)

Diagrama de Paquetes: Ejemplo

ClienteInterfaz Redbanc

Motor transacciones

Motor Usuarios Repositorio Usuarios

Repositorio Cuentas

Interfaces

+ Interfaz Redbanc

Lógica de Negocio

+ Motor transacciones+ Motor Usuarios

Repositorios

+ Repositorio Cuentas+ Repositorio Usuarios

paquete

dependencia

Trazabilidad

¿De dónde salió esto?

Trazabilidad: ¿Para qué?

� Indica el “porqué” de diagramas o elementos de un diagrama

� Relaciona elementos de diagramas en distintos niveles de abstracción

� Útil para la gestión de cambios

Trazabilidad: Elementos

«realize»Realización: Indica que un elemento de un diagrama corresponde a otro, en distintos niveles de abstracción.

Trazabilidad: Ejemplo

«PC»Redbanc

«UNIX»Servidor Banco

Realizar transacciónCliente

Validar Usuario

Redbanc Transacción Interfaz UsuarioUsuario

Componete Redbanc

Componente Transacción Componente

Usuario

«include»

«realize»

«realize» «realize»«realize»

«realize» «realize»«realize»

Modelamiento Básicode Negocios

Del software a los negocios

¿Por qué modelar negocios?

� Objetivo último de los sistemas de software: apoyar correcta y completamente el negocio

� Entonces, es necesario modelar el negocio:� Para comprender sus mecanismos principales� Para identificar sus flaquezas� Para tener una base sobre la que construir innovaciones

� Para apreciar cómo los cambios afectarán el negocio

Diferentes enfoques

� Principio de diseño #1: Elegir modelos adecuados a lo que se desea modelar

� Los negocios tienen aspectos ajenos al software: metas, equipos de trabajo, recursos no computacionales, etc.

� UML “puro” presenta dificultades para modelar negocios

IDEF

Nacido para los negocios

¿Qué es IDEF?

� IDEF: Integrated Definition� Lenguaje de modelamiento para describir operaciones

� Creado por la USAF� Desarrollado por KBSI (Knowledge BasedSystems Inc.)

� Conjunto de diagramas IDEF 0 - IDEF 14� Paradigma estructurado

IDEF: ¿Para qué?

� Facilidad para modelar negocios

� Sintaxis más rigurosa que UML

� Modelamiento de Negocios:� IDEF 0: Para modelar QUÉ se hace� IDEF 3: Para modelar CÓMO se hace

IDEF 0: Elementos

ActividadActividad: Acción o conjunto de acciones a ejecutarse

Flecha de precedencia: Indica flujo de distintos tipos dependiendo de su posición:

Borde Superior: ControlBorde Izquierdo: Recurso (Insumo)Borde Derecho: ResultadoBorde Inferior: Recurso (catalizador)

IDEF 0: Ejemplo (1/2)

IDEF 0: Ejemplo (2/2)

IDEF 3: Elementos

Unidad de Trabajo: Acción a ejecutarse

AND síncrono y asíncrono: “y” lógico entre actividades concurrentes

OR síncrono y asíncrono: “o” lógico entre actividades concurrentes

XOR: “o exclusivo” lógico entre actividades concurrentes

Trabajo

1.1

& &

O O

X

IDEF 3: Ejemplo

Modelando Negocioscon UML

Eriksson-Penker

Dialectos de UML

� Extensiones de UML para algún propósito particular

� Mecanismos de extensión:� Estereotipos: etiquetas del tipo <<negocio>>, o modificación de

elementos gráficos)� Tagged values: par variable-valor del tipo {cargo=gerente}� Restricciones: Expresiones booleanas del tipo {edad<40}

� Dialecto Eriksson-Penker:� Extensión orientada al modelamiento de negocios� Similar en cierto aspecto a IDEF 0� Sintaxis más libre

Dialecto Eriksson-Penker

� Conceptos principales para definir negocio:� Recursos: objetos en el negocio� Procesos: actividades que se realizan� Metas: propósito del negocio� Reglas: frase que define o restringe algún aspecto del negocio,

representa el conocimiento del negocio�

Vistas utilizadas:� De visión de negocio: expresa objetivos� De procesos de negocio: expresa actividades y creación de valor� De estructura de negocio: expresa recursos y su estructura� De comportamiento de negocio: expresa comportamiento

individual de recursos de interés

Diagrama de Visión de Negocio

Disminuir_tiempo_de_atención :Meta_cuantitativa

Reducir_número_de_trámites :Meta_cuantitativa

Aumentar_número_de_ejecutivos :Meta_cuantitativa

Conseguir_aumento_de_presupuesto :Meta_cuantitativa

Aumentar_horario_atención :Meta_cuantitativa

objeto: meta cuantitativa

dependencia

Diagrama de Procesos de Negocio

Ejeutivo de Negocio Depto.Proyectos

Elaboración AnteproyectoNecesidad del Cliente

«entregable»Documento

Visión

«trabajador»Ejecutivo Negocio

«procedimiento»CVPS

«trabajador»Funcional

Planificación

«objetivo»definir marco de

proyecto y formalizar su inicio

«trabajador»Director de Proyecto

«objetivo»Definir proyecto y estimar costo

«entregable»Informe de Factibilidad

«control»«cumple»

«recurso» «recurso» «recurso» «recurso»

«cumple»«control»

meta

proceso de negociorecurso

evento

control

Diagrama de Estructura de Negocio

Unidad

Empresa

Trabajador

1

1..*

1

1..*

1

0..*

Codelco :Empresa

GC TIC :Unidad

VP Comercialización :

Unidad

VP Servicios Compartidos :

Unidad

VP Desarrollo y Proyectos :Unidad

GC Abastecimientos :

Unidad

«gerente corporativo»Juan Villarzú :Trabajador

diagrama de clase de estructura diagrama de objetos de estructura

Diagrama de Comportamiento de Negocio

Recibida

Confirmada

Cancelada

En produción Entregada

Recepción de Orden

Fin

verificación de orden

envío a producción

Entrega a cliente

cancelación de orden

cancelación de orden

Diagramas en esta Vista:De EstadosDe ColaboraciónDe Secuencia

Herramientas

Manos a la obra

Herramientas

� UML:� AllFusion� Rational Rose� Enterprise Architect� Poseidon� System Architect�Magic Draw� Visio�…

� IDEF:� AllFusion (BPWin)� AI0 Win� ProSim� System Architect�WorkFlow Modeler � IDEFine�…

Referencias

¿Dónde sigo?

Referencias� Libros

� Booch, Rumbaugh, Jacobson, “El lenguaje Unificado de Modelado”, Addison-Wesley

� Fowler, Scott “UML Gota a Gota”, Addison-Wesley� Eriksson, Penker, “UML Business Patterns at Work”, OMG Press� Jacobson, Ericsson, Jacobson, "The Object Advantage :

Business Process Reengineering with Object Technology“, Addison-Wesley

� Websites� http://www.uml.org� http://usecasedriven.com/UML.htm� http://www.idef.com� http://www.umlderby.org/

� Papers� Eriksson, Penker, “Business Modeling with UML”