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)
¿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?� 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
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
•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
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
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
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
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
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
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
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
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
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
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
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
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: ¿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»
¿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
¿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 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
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
� UML:� AllFusion� Rational Rose� Enterprise Architect� Poseidon� System Architect�Magic Draw� Visio�…
� IDEF:� AllFusion (BPWin)� AI0 Win� ProSim� System Architect�WorkFlow Modeler � IDEFine�…
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”
Top Related