Documente Academic
Documente Profesional
Documente Cultură
Contenidos
Introduccin al modelado del software Presentacin de UML Modelado de Casos de Usos Diagramas de casos de uso Modelado Estructural Diagramas de Clases
Paquetes
Contenidos
Bibliografa
G. Booch, J. Rumbaugh, I. Jacobson, El lenguaje unificado de modelado, 2 Edicin, Addison-Wesley, 2006. Craig Larman, UML y Patrones: Una introduccin al anlisis y diseo orientado a objetos y al proceso unificado, PrenticeHall, 2003. Jim Arlow, Ila Neustadt, UML 2, Anaya Multimedia, 2006. http://www.uml.org/
Contenidos
Paquetes
En 1994, Booch, Rumbaugh y Jacobson deciden unificar las notaciones de sus mtodos: Unified Modeling Language (UML) Proceso de estandarizacin promovido por el OMG
http://www.omg.org
Y muchos ms!
Evolucin UML
Grady Booch y Jim Rumbaugh comenzaron a unificar sus mtodos (Octubre, 1994). Borrador de UML (versin 0.8) (Octubre, 1995) Ivar Jacobson se une al proyecto (Noviembre, 1995). UML 0.9 y se crea un consorcio (Junio, 1996) OMG lanza una peticin para un lenguaje unificado (1996) UML 1.0 es ofrecido al OMG (Enero, 1997) Se extiende el consorcio (Enero-Julio, 1997) UML 1.1 es ofrecido al OMG (Julio, 1997) OMG adopta UML 1.1 (Noviembre, 1997) Se crea el UML RTF (1998) UML 1.3 (Mayo 1999) UML 2.0 (principios de 2005)
Propone, elabora y mantiene especificaciones para aplicaciones empresariales distribuidas e interoperables. Estndares OMG
Ventajas de la unificacin
Reunir los puntos fuertes de cada mtodo Idear nuevas mejoras Proporcionar estabilidad al mercado
Modelar sistemas, desde los requisitos hasta los artefactos ejecutables desplegados en nodos, utilizando tcnicas OO. Cubrir las cuestiones relacionadas con el tamao propias de los sistemas complejos y crticos. Lenguaje utilizable por las personas y las mquinas Encontrar equilibrio entre expresividad y simplicidad.
El modelado es el anlisis y diseo de aplicaciones software antes de escribir el cdigo. Se crean un conjunto de modelos (planos del software) que permiten especificar aspectos del sistema como los requisitos, la estructura y el comportamiento. Los modelos
ayudan a razonar sobre el sistema favorecen la comunicacin permiten documentar las decisiones permiten una generacin automtica de cdigo
Qu es un modelo?
Un modelo es una simplificacin de la realidad Un modelo es resultado de un proceso de abstraccin y ayuda a comprender y razonar sobre una realidad.
Qu es un modelo software?
Es una descripcin de un aspecto del sistema,
escrita en un lenguaje bien definido.
.... necesitamos escribir modelos, aunque la mayora de desarrolladores todava no practican el modelado
Modelo de Estructural
5. numAdjs = calcularAdjudicaciones()
8. [1..numAdjs]* adj := crear(as, pg, a) 6. [1..numAdjs]* pg := get() pujas : PujaOrdinaria 7. [1..numAdjs]* a:= get()
Se recorre la coleccin de pujas obteniendo las pujas ganadoras (consideramos que la coleccin est ordenada de mayor a menor valor de puja).
adj : Adjudicacion : ArticuloConcreto Se crean tantas adjudicaciones como pujas ganadoras haya. Cada adjudicacin se asocia con un ArticuloConcreto, una puja adjudicataria y con la subasta.
Modelo de Comportamiento
Hay estructuras que no son visibles en los programas. Ayuda a razonar sobre el cmo se implementa. Se facilita la comunicacin entre el equipo al existir un lenguaje comn. Se dispone de documentacin que trasciende al proyecto. Generacin de cdigo a partir de modelos
Ha surgido un nuevo paradigma de desarrollo de software a partir de modelos (p.e. MDA de OMG)
Los modelos:
visualizan cmo es o queremos que sea el sistema especifican la estructura y comportamiento del sistema. guan la construccin del sistema. documentan las decisiones.
Modelos en UML
Modelado de Casos de Uso Modelado Estructural Modelado de Comportamiento Modelado de flujos de Actividades Modelado Implementacin Modelado de Despliegue
Tipos de modelo
En qu etapa del proceso se usa? Anlisis o Diseo? Cul es su grado de detalle? Abstracto o detallado? Qu sistema describe? Modelo de negocio o modelo software? Qu aspecto describe? Estructural o de comportamiento? Es especfico o independiente de la plataforma? A qu plataforma va dirigido? EJB, JDBC, .NET, CORBA, etc.
La eleccin de los modelos tiene una profunda influencia sobre cmo se acomete el problema y se moldea la solucin. Todo modelo debe estar ligado a la realidad. Un nico modelo no es suficiente. Cualquier sistema trivial se aborda mejor a travs de un pequeo conjunto de modelos casi independientes.
Contenidos
Presentacin de UML
Modelado de Casos de Usos Diagramas de casos de uso Modelado Estructural Diagramas de Clases
Paquetes
UML y el modelado
UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos (modelos) de un sistema que involucra una gran cantidad de software, desde una perspectiva orientada a objetos.
UML es una notacin, no es un proceso Se han definido muchos procesos para UML.
Elementos
Estructurales, Comportamiento, Agrupacin, Anotacin
Relaciones Diagramas
Establecen qu es un modelo bien formado Especificaciones, Extensibilidad, Dicotoma claseinstancia, Dicotoma interfaz-realizacin
Mecanismos comunes
Elementos Estructurales
colaboracin
IAvisable
interface
Gestin Pedidos
clase
RealizarCompra
caso de uso
Elementos Estructurales
Gestor Eventos suspender() vaciarCola()
clase activa
FormularioPedido
componente
<<artifact>>
window.dll
Servidor
nodo
artefacto
Elementos de Comportamiento
Son las partes dinmicas de UML.
Interaccin Conjunto de mensajes intercambiados entre varios objetos con un propsito particular.
cerrarPuja()
mensaje
Elementos de Comportamiento
Mquina de estados Secuencia de estados por las que pasa un objeto durante su vida en respuesta a eventos.
activado
estado
Elementos de Agrupacin
Son las partes de organizacin de los modelos UML paquete
Elementos de Anotacin
Son las partes explicativas de los modelos UML
Nota
Relaciones
Dependencia
0..1 *
patron
empleado
Asociacin
Generalizacin Realizacin
Cuenta 1 0..n
Domiciliacion
Ahorro
Diagrama de Clases Diagrama de Objetos Diagramas no Diagrama de Componentes Diagrama de Estructura Compuesta son modelos Diagrama de Casos de Uso Diagrama Secuencia Diagrama Comunicacin (antes de Colaboracin) Diagrama de Estados Diagrama de Actividades Diagrama de Despliegue Diagrama de Artefactos Diagrama de Paquetes Diagrama de Tiempos
Modelos en UML
Modelado Estructural
Modelado de Comportamiento
Modelado Implementacin
Modelado de Despliegue
Responsable
Serv icio PE
Alumno
Sistema
no Cambiar admitidos
Hay alumnos? no
Diagrama de actividades
Cancelar Curso
Pujador
Diagrama de clases
Modelo Estructural
Diagrama de comunicacin
9. [1..numAdjs]* add(adj)
5. numAdjs = calcularAdjudicaciones()
8. [1..numAdjs]* adj := crear(as, pg, a) 6. [1..numAdjs]* pg := get() pujas : PujaOrdinaria 7. [1..numAdjs]* a:= get()
Se recorre la coleccin de pujas obteniendo las pujas ganadoras (consideramos que la coleccin est ordenada de mayor a menor valor de puja).
adj : Adjudicacion : ArticuloConcreto Se crean tantas adjudicaciones como pujas ganadoras haya. Cada adjudicacin se asocia con un ArticuloConcreto, una puja adjudicataria y con la subasta.
Modelo de Comportamiento
Mquina de Estado
Diagrama de estado
Espera Venta introducirProducto introducirProducto
Introduccion Productos
Elena : Persona
Elena : Persona
: Persona
: Persona
IOrtografia IDiccionario
asistenteOrtografico
IUnknown
Pedido
cliente: Persona
El tipo declara la clase de una entidad, por ejemplo un objeto o parmetro, y el rol describe el significado de la entidad en un determinado contexto, tal como una clase, componente o colaboracin.
Estereotipos
Extienden el vocabulario de UML, permitiendo definir nuevos tipos de elementos y relaciones a partir de los existentes pero especficos de un problema o dominio. Algunos son predefinidos en UML.
Extienden las propiedades de un estereotipo, permitiendo crear nueva informacin en la especificacin del estereotipo. Especifican condiciones sobre los elementos del modelo.
Valores etiquetados
Restricciones
Perfiles UML
UML es una familia de lenguajes Lenguaje core + Perfiles Un perfil define una extensin de UML mediante la especializacin de UML. Un perfil define una forma especfica de usar UML para un dominio concreto: EJB, aplicaciones web, CORBA, modelado del negocio, esquemas relacionales, .. Agrupacin de un conjunto de estereotipos, valores etiquetados y restricciones, con su correspondiente notacin.
<<Actor>> Cliente
Cliente
IComparator
<<Table>>
Empleado
<<key>> dni : String nombre : String edad : int
1
Cliente
<<UniqueId>> id : String
nombre : String apellido : String <<Query>> findByLastName()
Restricciones
Se expresan en OCL Permiten asociar informacin que no se puede expresar en UML Ejemplo: Dos tablas de un mismo esquema
relacional deben tener distinto nombre.
context Table inv: tablasDistintoNombre tablas -> forAll ( t1, t2 | t1.name = t2.name implies t1 = t2) end
Restricciones
{xor}
restricciones
Hola, Mundo!
import java.awt.Graphics; class HolaMundo extends java.applet.Applet { public void paint (Graphics g) { g.drawString (Hola, Mundo!,10,10); } }
HolaMundo g.drawString
("Hola, mundo)
paint()
Diagrama de Clases
Organizacin en Paquetes
Organizacin en Paquetes
java
HolaMundo applet awt
lang
Diagrama de Secuencia
root : Thread : Toolkit : ComponentPeer target : HolaMundo
run callbackLoop
handleExpose
paint
Diagrama de Artefactos
HolaMundo
<<manifest>>
<<artifact>>
<<manifest>>
hola.java
HolaMundo.class
hola.html
hola.jpg
Contenidos
Paquetes
Casos de Uso
Un caso de uso especifica un comportamiento deseado del sistema (trabajo tangible). Representan requisitos funcionales del sistema. Un caso de uso especifica un conjunto de secuencias de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un particular actor (Definicin en UML)
Casos de Uso
Conjunto de secuencias de acciones; cada secuencia representa un posible comportamiento del sistema Actores, roles que pueden jugar los usuarios Variantes: versiones especializadas, un cdu que extiende a otro o un cdu que incluye a otro
Casos de uso
Casos de uso son ideados por Jacobson a principios de los noventa, Inspirados en el concepto de escenario. Escenarios haban sido utilizados para describir procesos.
Emisor
Centralita
Receptor
listo( )
tono
marcar_numero
tono_sonando timbre_sonando
Escenario
Describe un conjunto de interacciones entre actores externos y el sistema en consideracin orientadas a satisfacer un objetivo de un actor. [D. Bredemeyer]
Es una coleccin de posibles secuencias de interacciones entre el sistema en discusin y sus actores externos, relacionado con un objetivo particular. [A. Cockburn] Es una coleccin de escenarios de xito y fracaso relacionados que describe a un actor que usa un sistema para conseguir un objetivo [C. Larman]
67
Cajero
Realizar Venta
asociacion
Flujo:
1. El cliente llega al TPV con los artculos. 2. El cajero registra el identificador de cada artculo. 3. El sistema obtiene el precio de cada artculo y aade la informacin a la transaccin de venta. 4. Al acabar el cajero indica la finalizacin de la introduccin de artculos. 5. El sistema calcula el total de la compra y lo muestra.
Actores
Un actor representa un rol que juegan los agentes que interactan con el sistema.
Roles son jugados por personas, dispositivos, u otros sistemas. Ejemplos: Cliente, Pujador, Alumno, SistemaPago, El tiempo puede ser un actor (procesos iniciados automticamente por el sistema) No forman parte del sistema.
Actores
Un actor necesita el caso de uso y/o participa en l. Un mismo usuario puede jugar diferentes roles. En la realizacin de un caso de uso pueden intervenir diferentes actores: Principal y Secundarios Un actor puede intervenir en varios casos de uso. Se pueden identificar casos de uso a partir de actores y eventos externos.
Identificacin de actores
Quin y qu utiliza el sistema? Qu roles desempean en la interaccin? Quin mantiene el sistema? Quin o que inicia y cierra el sistema? Qu otros sistemas interactan con el sistema? Quin o qu consigue o proporciona informacin al sistema? Sucede algo en un momento dado de forma automtica?
Actores
Principal: Requiere al sistema el cumplimiento de un objetivo Secundarios: El sistema necesita de ellos para satisfacer un objetivo
Un caso de uso describe un conjunto de secuencias de interacciones entre actores y el sistema (escenarios):
Principal y secundarios.
Cada escenario acaba con xito o fracaso. Un escenario es una instancia de un caso de uso, una historia particular de uso del sistema. Un flujo principal y varios flujos secundarios. Flujo principal: Todo va bien Flujos secundarios: Alternativas y Excepciones
Son iniciados por un actor con un objetivo en mente y es completado con xito cuando el sistema lo satisface. Puede incluir secuencias alternativas que llevan al xito y fracaso en la consecucin del objetivo. El sistema es considerado como una caja negra y las interacciones se perciben desde fuera. El conjunto completo de casos de uso especifica todas las posibles formas de usar el sistema, esto es el comportamiento requerido.
75
El modelado de casos de uso consiste en escribir texto, no en dibujar diagramas. Texto estructurado informal Texto estructurado formal (plantillas) Pseudocdigo Notaciones grficas: diagramas de secuencia
Debe ser legible y comprensible para un usuario no experto. Debe indicar: actores, flujos principal y excepcionales.
76
Cajero
Realizar Venta
Cliente
:Sistema
: Cajero
crearNuevaVenta()
* introducirItem(upc,cantidad)
finalizarVenta() hacerPago(cantidad)
Interacciones
Aprobar curso
Servicio CPE
Fin matriculacion
Realizar preinscripcin
Sistema
Alumno
Realizar preinscripcin
Gestin Expedientes
Actor Principal
Matriculacin Entidad Bancaria
Actores Secundarios
Reservar Libro
Prstamo revista
Profesor
Prstamo Libro
Devolver revista
Bibliotecario
Extender Prstamo
Consultar
Socio
82
Con un caso de uso se describe un comportamiento esperado del sistema, pero no se especifica cmo se implementa. Una caso de uso se implementa a travs de una colaboracin:
Sociedad de clases y otros elementos que colaborarn para realizar el comportamiento expresado en un caso de uso
Una colaboracin tiene una parte esttica (diagramas de clases) y una parte dinmica (diagramas de secuencia).
colaboracin
Hacer Pedido
El objetivo de la arquitectura del sistema es encontrar el conjunto mnimo de colaboraciones bien estructuradas, que satisfacen el comportamiento especificado en todos los casos de uso del sistema
Un cdu hereda el comportamiento y significado de otro Un cdu base incorpora explcitamente el comportamiento de otro en algn lugar de su secuencia. Un cdu base incorpora implcitamente el comportamiento de otro cdu en el lugar especificado indirectamente por este otro cdu
Inclusin
Extensin
Generalizacin
Los casos de uso hijo son una especializacin del caso de uso padre. Produce confusin y se debera evitar su uso
Cliente
Buscar Producto
Buscar libro
Buscar CD
Ejemplo
Extensin extend
Realizar Pedido Realizar Pedido Urgente
(establecer prioridad)
include
Inclusin
Validar Usuario
Comprobar clave
Generalizacin include
Consultar Pedido
Examinar retina
Relacin de inclusin
Permite factorizar un comportamiento en un caso de uso aparte y evita repetir un mismo flujo en diferentes casos de uso. Ejemplo:
Hacer Pedido:
Obtener y verificar el nmero de pedido; Incluir (Validar usuario); para cada lnea en el pedido: Consultar el estado; Preparar un informe para el usuario
Relacin de extensin
El caso de uso base incluye una serie de puntos de extensin. El caso de uso base no conoce los casos de uso de extensin, est completo sin las extensiones. Los puntos de extensin no son parte del flujo principal. Sirve para modelar
la parte opcional del sistema un subflujo que slo se ejecuta bajo ciertas condiciones varios flujos que se pueden insertar en un punto
Relacin de extensin
Ejemplo:
Hacer Pedido: Incluir Validar usuario; Recoger los tem del pedido del usuario; establecer prioridad: punto de extensin Enviar pedido para ser procesado.
Relacin de extensin
Devolver Libro
Puntos de extensin libro retrasado
extend
Poner multa
Bibliotecario
Nombre: Devolver libro Nombre: Poner multa Actor principal: Bibliotecario Precondicin: Libro devuelto fuera de plazo Precondicin: Bibliotecario est autenticado Flujo: Flujo: 1. El bibliotecario introduce detalles multa 1. El bibliotecario introduce id del prestatario 2. El sistema registra e imprime la multa 2. El sistema muestra datos del prestatario y los libros que tiene prestados 3. El bibliotecario selecciona libro a devolver punto de extensin: libro retrasado 4. El sistema registra devolucin 5. ...
Relacin de extensin
Produce confusin y no debera utilizarse. Conviene su uso slo para insertar un nuevo comportamiento no previsto en un caso de uso existente.
2) Encontrar todos los roles que juegan los usuarios y que son relevantes al sistema. 3) Para cada rol identificar todas las formas (objetivos) de interactuar con el sistema. 4) Crea un caso de uso por cada objetivo. 5) Estructurar los casos de uso. (Cuidado!) 6) Revisar y validar con el usuario.
Nombre del caso de uso Actor Principal Personas involucradas e Intereses (Actores secundarios) Precondiciones (estado del sistema antes de empezar) Postcondiciones (estado del sistema al finalizar) Escenario Principal (Flujo Bsico) Extensiones (Flujos Alternativos) Requisitos especiales Tecnologa y Lista Variaciones de datos Frecuencia Cuestiones abiertas
Cajero: quiere entradas precisas, rpida y sin errores de pago Compaa: quiere registrar transacciones y satisfacer clientes. ...
Precondicin: El cajero est autenticado Postcondiciones: Se registra la venta. Se calcula el impuesto. Se actualiza contabilidad e inventario...
Cuestiones Pendientes:
- Explorar cuestiones de recuperacin de accesos a servicios remotos - Qu adaptaciones son necesarias para diferentes negocios?
Ofrecen un medio sistemtico e intuitivo para capturar los requisitos funcionales, centrndose en el valor aadido para el usuario Dirigen todo el proceso de desarrollo puesto que la mayora de actividades (planificacin, anlisis, diseo, validacin, test,..) se realizan a partir de los casos de uso. Mecanismo importante para soportar trazabilidad entre modelos.
Hay consenso en considerar casos de uso como esenciales para capturar requisitos y guiar el modelado. Pero ha existido mucha confusin sobre cmo usarlos.
Diferente granularidad Un caso de uso se puede asociar a un objetivo del usuario o a una interaccin bsica con el sistema. Un objetivo implica una o ms interacciones. Se debe definir un caso de uso por cada objetivo del usuario.
Granularidad
Ej. Venta productos Objetivo de un usuario Ej. Realizar una compra Forman parte de otro, son como subfunciones Ej. Buscar, Validar, Login
Granularidad
Sirven para planificar el proyecto Se les asocia un flujo de interacciones actor-sistema Deben ser objetivos del usuario En un sistema de venta por internet, son casos de uso Aadir producto al carro de la compra o Introducir datos facturacin ?
Breve : Descripcin en unas pocas lneas Informal : Varios prrafos que cubren varios escenarios Completo : Descripcin detallada con una plantilla Primario, secundario u opcional Esencial : intenciones del usuario y responsabilidades del sistema Concreto : Se contemplan detalles de implementacin (GUI y tecnologa)
Segn la importancia
Recomendaciones
Especificar casos de uso no es una actividad de dibujar diagramas sino de escribir con el detalle necesario el flujo principal y los flujos alternativos: centrado en la escritura en vez del dibujo El objetivo inicial es identificar los actores y a partir de sus objetivos encontrar los casos de uso, el diagrama de casos de uso es una ayuda visual. El texto de los casos de uso debe ser claro. No abusar de la relacin de inclusin.
No hacer una descomposicin funcional!
Recomendaciones
Un caso de uso debe tener una granularidad apropiada, especifica una interaccin en la que se produce un resultado de valor para un actor.
No identificar como caso de uso lo que son interacciones que forman parte de una interaccin mayor que las engloba y no son casos de uso de inclusin.
Un error comn es no identificar como casos de uso las tareas que inicia el propio sistema (Actor Tiempo)
Recomendaciones
No incluir como caso de uso las operaciones CRUD sobre un objeto de negocio (alta, consulta, borrado, actualizacin): funcin del sistema aparte, excepto si se trata de operaciones relevantes para el sistema, como registrar cliente en un sistema de venta por Internet. Cuidado con el empleo de la relacin include
No hacer una descomposicin funcional!
Escribir casos de uso independientes de la interfaz o de detalles de implementacin, escribirlos a nivel esencial. Centrarse en el qu no en el cmo.
Recomendaciones
Hay que comprobar que los casos de uso incluyen toda la funcionalidad del sistema. Preocupacin por mantener la validez y consistencia del conjunto de casos de uso. Cada compaa debe tener un manual sobre uso de los casos de uso. Algunos requisitos funcionales no conviene expresarlos como casos de uso.
<<include>>
Aadir libro
Eliminar libro
<<include>> <<include>>
Aadir peticin
Bibliotecario
Gestionar biblioteca
Mantener peticiones
<<include>>
<<include>>
Eliminar peticin
Mantener prestamos
<<include>>
Prestar libro
Contenidos
Presentacin de UML
Modelado de Casos de Usos Diagramas de casos de uso
Modelado Estructural
Diagramas de Clases
Paquetes
Modelado estructural
Se describen los tipos de objetos de un sistema y las relaciones estticas que existen entre ellos.
Clases Interfaces Relaciones de dependencia, realizacin, generalizacin y asociacin (agregacin, composicin) Tambin pueden incluir paquetes.
Modelado estructural
Conceptos del dominio del problema: atributos, restricciones y relaciones entre ellos. Clases que corresponden a conceptos del dominio Atributos y mtodos Incluye clases que corresponden a decisiones del diseo Clases que corresponden a un lenguaje de programacin
Modelo de Diseo
Modelo de Implementacin
Modelo Conceptual
Modelo Anlisis
IteradorCuenta
Modelo de diseo
Cuenta 1 0..n
Domiciliacion
Ahorro
: Catlogo Curso
: Curso
esMatriculable indica si el alumno puede matricularse en el curso segn los criterios de seleccin del mismo.
1: realizarMatricula(idCurso,dniAlumno) : ControladorMatrculacionCurso
7: addMatricula(a) c : Curso
: Alumno
4: a := getAlumno(dniAlumno)
13: addMatricula(matric)
: Alumno 6: create(datosAlumno)
5: datosAlumno:= getDatosAlumno(dniAlum...
:SistemaGestinAcadmica Si el alumno no est en el catlogo se piden sus datos, se crea y se aade al catlogo.
Realizar Compra
Realizar Compra
Ingeniera directa
Transformar modelos en cdigo en un lenguaje de programacin determinado Obtener un modelo a partir de cdigo. Ms difcil ya que hay prdida de informacin al pasar de los modelos al cdigo.
Ingeniera inversa
Clases
Atributos
Operaciones
No se tienen por qu mostrar todos las propiedades Se pueden agrupar operaciones: <<constructor>>, <<query>>
Clases
Interfaces
Una interfaz es una coleccin de operaciones que especifica los servicios de una clase o componente.
<<Interface>> Collection add() remove() size() contains() iterator()
Atributos
[visibilidad] nombre [: tipo] [[multiplicidad]] [= valor_inicial ] [property-string {, property-string}]
+ = # = = ~ = pblica protegida privada package
Atributos : Ejemplos
origen + origen origen : Punto nombre : String [0..30] origen : Punto = (0,0) id : Integer {readOnly}
Operaciones
[visibilidad] nombre [(lista_parametros)] [: tipo_retorno] [property-string {, property-string}]
+ = # = = ~ = pblica protegida privada package
visibilidad
nombre: nombre de la operacin lista_parmetros: lista de parmetros separados por comas tipo retorno: propiedades: tipo de valor devuelto por la operacin {isQuery}, {sequential}, {concurrent}
Operaciones: Ejemplos
Formato parmetro:
[direccion] nombre : tipo [= valor-por-defecto] direccion puede ser : in, out o inout
Clases Parametrizadas
G
Clase Parametrizada
bind <Empleado>
Instanciacin
Tabla<Cliente>
Empleados
Clases Estereotipadas
<<entity>> Cuenta <<control>> Controlador Ingreso <<boundary>> JFrameBanco
Cuenta
Controlador Ingreso
JFrameBanco
Cuenta
Controlador Ingreso
JFrameBanco
Relaciones
Dependencia
Un cambio en la especificacin de un elemento afecta a otro elemento
Lista <<friend>> Nodo
Relaciones
Generalizacin
Cuenta
Window
Cuenta Ahorro
Cuenta Corriente
TextWindow
BoxDialog
Relaciones
Asociacin
Relacin estructural que especifica que los objetos de un tipo estn conectados con los de otro.
Persona
+patron 0..n
Empresa
Multiplicidad (mnimo..mximo)
Ejemplos: 0..1, 1, 0..*, *, 1..*, 1..10, 2..25
Asociaciones
Agregacin
1..1
Departamento
Navegabilidad
Asociaciones son bidireccionales Posibilidad de limitar la navegacin de una asociacin a una sola direccin Determina si una clase de la asociacin tiene conocimiento de la otra. Nivel de diseo o implementacin
Navegabilidad
class Pedido { private Hashtable _itemsPedido; private Date fecha; private boolean esCompleto; ...} class ItemPedido { private Producto producto; private int cantidad; ...} Class Producto { private Money precio; private String descripcin; }
A
A A
B
B B
A
A A
B
B B
No se usa No se usa
Visibilidad
+ # ~
Usuario
+propietario 1
-clave 0..n
Clave
Asociaciones calificadas
Nivel Conceptual: Dentro del mismo pedido no pueden existir dos lneas con el mismo producto Nivel Anlisis: El acceso a ItemPedido es indexado por productos Nivel Implementacin: Se usa una tabla para almacenar las lneas de pedido
Asociaciones calificadas
Class Pedido { private Hashtable _lineasPedido;
public ItemPedido getItemPedido(Producto unProducto); public void addItemPedido (Integer cantidad, Producto elProducto); }
Agregacin
Dos criterios:
Dependencia:
La existencia de una parte va ligada a la del agregado?
Exclusividad:
Una parte puede pertenecer a ms de un agregado?
Habra cuatro posibles tipos de agregacin; en UML hay dos: agregacin y composicin
Composicin
Forma fuerte de agregacin Una parte pertenece a un nico agregado (exclusividad) Si se elimina un agregado se eliminan todas sus partes (dependiente) Una parte se puede aadir o eliminar en cualquier instante al agregado.
Composicin
Window 1 1 1
agregado
+scrollbar Slider
2
+title
1 +body Panel
Header
partes
Clases Asociacin
Una asociacin que tambin es una clase Una asociacin que posee sus propias caractersticas. Una clase asociacin aade una restriccin: Slo puede existir una instancia de la asociacin entre cualquiera par de objetos participantes No podramos modelar que una persona tiene diferentes contratos para una misma compaa a lo largo del tiempo.
Distinta semntica
Empresa 1..n 1
Asociaciones derivadas
recibe Estudiante Asignatura
/ensea
imparte
Profesor
Asociacin Derivada
Cuenta
{or}
Persona
+miembro
{subset}
1..* Persona +Director 1..1
empleado
patrn 0..1
*
0..1 jefe
Persona
Empresa
{ Persona.patrn= Persona.jefe.patrn }
Realizacin
Relacin entre clasificadores, un clasificador Especifica un contrato que otro clasificador garantiza que cumplir.
<<Interface>> ICollection List add() remove() contains()
List
ICollection
Una interfaz es una coleccin de operaciones que especifican los servicios de una clase o componente. Las interfaces modelan las lneas de separacin o puntos de conexin (seams) de un sistema. Una interfaz permite separar la especificacin de la implementacin. Un tipo especifica un dominio de valores junto con operaciones (no mtodos) aplicables a esos valores. Un rol denota el comportamiento de una entidad dentro de un particular contexto.
Interfaces
Interfaz requerida Interfaz proporcionada
Observer
Target
TargetTracker
Target
Observer
TargetTracker
Clases Estructuradas
0..n Prestamo +prestamos 0..n libroPrestado 1 Libro +catalogo 0..n
1 Prestatario
+prestatarios 0..n 1
1 Biblioteca 1 1..n
Bibliotecario
Estudiante
Personal
Clases Estructuradas
Estructura interna de una clase
Biblioteca
:Bibliotecario [1..*]
biblioConectado:Bibliotecario [0..1]
:Bibliotecario [1..*]
biblioConectado:Bibliotecario [0..1]
Contenidos
Introduccin al modelado del software Presentacin de UML Modelado de Casos de Usos Diagramas de casos de uso Modelado Estructural Diagramas de Clases
Paquetes
Paquetes
Elemento organizativo Puede agrupar elementos de cualquier tipo Permite agrupar elementos relacionados semnticamente Un elemento es exclusivo a un paquete:
Modelo
Paquetes: Notacin
Importacin/Exportacin en paquetes
Visibilidad pblica y privada Relaciones de importacin y generalizacin. La parte pblica de un paquete son sus exportaciones. Cuando un paquete A importa a otro B, todos los elementos pblicos de B son aadidos a A, se accede a ellos sin calificar su nombre. La complejidad de un gran nmero de abstracciones es controlada a travs de los paquetes y de la importacin.
Importacin/Exportacin en paquetes
La relacin de acceso es igual que la importacin, pero los elementos pblicos son aadidos como privados. La relacin de importacin es transitiva. Importacin y acceso se representan mediante relaciones de dependencia estereotipadas con <<import>> y <<access>>. Los paquetes anidados tienen acceso al espacio de nombres del paquete que los contiene.
<<import>>
Politicas + ReglasPedidos + GUI:Ventana
<<import>>
Auxiliary
<<access>>
ShoppingCart WebShop
<<import>>
Types
<<import>>
Generalizacin de Paquetes
GUI + Ventana + Formulario - GestorEventos
MacGUI
Paquetes
ser cohesivo estar poco acoplado pocos anidamientos conjunto equilibrado de elementos
Modelo de Anlisis
<<framework>> Struts
Modelo
Un modelo captura una vista de un sistema fsico. Es una abstraccin de ese sistema con cierto propsito, para cierto conjunto de personas interesadas y a cierto nivel de abstraccin. Un modelo contiene todos los elementos de modelado necesarios. Un modelo y sus elementos se representan mediante diagramas, que expresan una vista del modelo.
Modelo
Vistas UML: 4 + 1
vocabulario funcionalidad ensamblado gestion conf.
Vista de Implementacion
Vista de Diseo
comportamiento
Vista de Interaccin
Vista de Despliegue
Vistas UML: 4 +1
clases interfaces colaboraciones
Vista de Diseo Vista de Implementacion
componentes
casos de uso
Vista de Interaccin
Vista de Despliegue
clases activas
nodos
Vistas UML
Diagramas de clase Diagramas de interaccin Diagramas de estado
Vista de Diseo
Diagramas de estado
Vista de Implementacin
Vista de Interaccin
Vista de Despliegue
Diagramas de despliegue
Contenidos
Enlaces y Conectores
Un enlace es :
una conexin semntica entre objetos. comnmente es una instancia de una asociacin. un camino por el cual enviar un mensaje
Una lnea de vida es un participante en una interaccin. Un conector es un enlace entre lneas de vida
Enlaces y Asociaciones
enlace
p:Persona 1: asignar(desarrollo) :Empresa
objeto mensaje
Enlaces
Diagrama de Objetos
: Cuenta
: Cliente
: CodigoCuenta
: Tarjeta
: Transaccion
: Perfil
Diagrama de Objetos
: Curso
: Alumno : Profesor
: Tarjeta
: Departamento
: Expediente
: Tarjeta
director : Profesor
: GrupoInvestigacion
Diagrama de Objetos
: Curso
: Profesor
profesores *
: Alumno
alumnos *
: Tarjeta
: Departamento
: Expediente
: Tarjeta
grupos *
director : Profesor
: GrupoInvestigacion
Interacciones y Mensajes
Lneas de Vida
umu: Empresa
irene:Persona
asignar(desarrollo)
lnea de vida
mensaje
Lneas de Vida
conector
irene:Persona
1: asignar(desarrollo) p:Persona :Empresa :Empresa umu: Empresa
lnea de vida
mensaje
Tipos de mensajes
Sncrono
Asncrono
Retorno
Creacin y destruccin
<<create>> y <<destroy>>
Se describe cmo los objetos colaboran entre s para realizar cierta actividad. Se expresan mediante los diagramas de interaccin:
Tambin se describe las mquinas de estado que caracterizan a los objetos y flujos de actividades
Diagramas de Interaccin
Destacan la ordenacin temporal de los mensajes Destacan la organizacin estructural de los objetos participantes.
Diagramas de Comunicacin:
Equivalencia semntica
Diagramas de Secuencia
Incluye:
Lneas de vida (antes objetos y su lnea de tiempo ) Focos de control o activacin Mensajes: a instancias o de creacin Mensaje self Informacin de control (en UML 2 slo en diagramas de comunicacin): condiciones y marcas de iteracin Indicar el objeto devuelto por el mensaje: return
(aadirlos slo cuando ayuden a clarificar la interaccin)
Mensajes
Simple: Creacin de objetos: Destruccin de objetos: Asignacin: Identificar hilo: metodo(arg) <<create>> <<destroy>> v:= mtodo(arg) nmero del mensaje en la secuencia precedido por el nombre del proceso o hilo
En UML 2.0 en diagramas de comunicacin: Condicin: [condicion] metodo(arg) Iteracin: * metodo(arg), [1..n] metodo(arg) Numeracin jerrquica o secuencial o ninguna
Mensajes
Simple: Condicin: Iteracin: Asignacin: Identificar hilo: preparar(), addPedido(p) [condicion] metodo(arg) * preparar() hayStock:= eliminar() D3 : activar()
Diagrama de Secuencia
sd Gestin Pedidos
: GUIPedido :GUIPedido : ControladorPedidos :ControladorPedidos ::Pedido Pedido : LineaPedido :LineaPedido : Item :Item : ItemPedido preparar( ) preparar( )
: ItemEntre
* preparar( )
:ItemPedido
[hayStock] <<create>>
:Item Entregado
Diagrama de Comunicacin
sd Gestin Pedidos
1: preparar( ) : GUIPedido : ControladorPedidos 2: preparar( ) : Pedido 3: *preparar( ) 3: preparar() : LineaPedido
lneas *
4: hayStock:=check( ) 5: [hayStock] eliminar( ) 8: [hayStock]<<>create> 6: pedir:=checkPedir( )
: ItemPedido 7: [pedir]<<create>>
: Item
: ItemEntregado
Diagrama de Secuencia
c:Cliente <<create>> establecerAcciones establecerValores :Transaccion p:ProxyODBC
tiempo
exito
establecerValores
Lnea de vida
<<destroy>>
Foco de control
Diagrama de Comunicacin
1: <<create>> 2: establecerAcciones 6: <<destroy>>
c:Cliente :Transaccion {new}
t {local}
proxy {global} 3: establecerValores 4: establecerValores
p:ProxyODBC
Operadores de control
El cuerpo se ejecuta si se cumple una condicin El cuerpo se divide en varias regiones, cada una con una condicin asociada. Se ejecuta el cuerpo de la regin cuya condicin se satisface. El cuerpo se divide en varias regiones. Cada regin representa una computacin paralela. Se ejecuta de forma paralela el cuerpo de cada regin El cuerpo se ejecuta mientras se cumple una condicin El cuerpo hace referencia a otra interaccin
sd reintegro
usuario : Persona banco : CajeroAutomatico
loop(1,3)
[password incorrecto]
introducir (password)
Fragmento combinado
verificar(password)
opt
[password valido]
par
introducir(cuenta)
introducir(cantidad)
entregar(dinero)
ref
Obtener password
opt
[password valido]
ref
Obtener dinero
Numeracin secuencial
2: m2()
1: m1() :A :B
3: m3() :C
4: m4()
:D
Numeracin jerrquica
:A m1( ) :B :C :D
m2( ) m3( )
m4( )
Numeracin jerrquica
:A 1. m1() 1.1. m2() :B :C :D
1.2. m3()
1.3. m4()
Numeracin jerrquica
1.1. m2( )
1. m1( ) :A :B
1.2. m3( ) :C
1.3. m4( )
:D
Numeracin jerrquica
:A 1. m1( ) 1.1. m2( ) 1.1.1. m3( ) :B :C :D
1.2. m4( )
Numeracin jerrquica
1.1. m2( )
1. m1( ) :A :B
1.1.1. m3( ) :C
1.2. m4( )
:D
Diagrama de clases
: Catlogo Curso
: Curso
esMatriculable indica si el alumno puede matricularse en el curso segn los criterios de seleccin del mismo.
1: realizarMatricula(idCurso,dniAlumno) : ControladorMatrculacionCurso
7: addMatricula(a) c : Curso
: Alumno
4: a := getAlumno(dniAlumno)
13: addMatricula(matric)
: Alumno 6: create(datosAlumno)
5: datosAlumno:= getDatosAlumno(dniAlum...
:SistemaGestinAcadmica Si el alumno no est en el catlogo se piden sus datos, se crea y se aade al catlogo.
import java.io.*; public class EjemHilo extends Thread { static PrintWriter out = new PrintWriter (System.out, true); int num; public EjemHilo(String nombre, int n) { super(nombre); num = n; } public void run(){ for (int i=0; i<num;) { out.println(getName()+":"+ ++i); delay(); } } void delay() { long t = System.currentTimeMillis() + 500; while (System.currentTimeMillis() < t); } }
public class TestHilo { private EjemHilo h1, h2; public void inicio(){ h1 = new EjemHilo("Hilo 1", 4); h2 = new EjemHilo("Hilo 2", 6); EjemHilo.out.println(Preparados los dos hilos"); h1.start(); h2.start(); EjemHilo.out.println("Arrancados los dos hilos"); }
public static void main(String[] args) { TestHilo testHilo1 = new TestHilo(); testHilo1.inicio(); }
}
t: TestHilo new(Hilo 2, 4) inicio new(Hilo 2, 6) :h2: EjemHilo println(preparados los dos hilos) start() start() println(arrancan los dos hilos) delay() [1..4] :h1: EjemHilo
EjemHilo1.out:PrintWriter
run() run()
delay() [1..6]
Modelado del aspecto dinmico. Modelado del flujo de control que caracteriza el comportamiento de un sistema:
Equivalencia semntica Simples para comportamientos simples. Si hay mucho comportamiento condicional, usar diferentes escenarios. Diagramas de secuencia muestran mejor el orden en que se ejecutan los mensajes Diagramas de colaboracin muestran claramente los objetos a los que est conectado un determinado objeto. Permiten la generacin de cdigo
Diagramas de Actividad
Representa una actividad. Basados en las redes de Petri. Formado por nodos conectados por arcos:
nodos accin y actividad nodos de control, como control de concurrencia y decisin nodos objeto flujos de control y de flujo de objetos
Una actividad o una accin produce algn efecto que provoca algn cambio en el sistema o retorna un valor.
Nodos de Actividad
Nodos de accin
Realizan un trabajo: llamadas a operaciones, actividades, comportamiento, envo de seales, aceptar un evento.
Controlan el flujo de la actividad Objetos o datos utilizados en la actividad
Nodos de control
Nodos de objetos
Semntica actividades
Basada en el flujo de tokens. Un token contiene un dato, objeto o punto de control y est presente en un nodo. Un nodo inicia la ejecucin cuando se satisfacen las condiciones sobre sus tokens de entrada; al inicio acepta tokens de sus entrada y un token es colocado en el nodo; al finalizar ofrece tokens a sus arcos de salida y elimina el token. Existen reglas de flujo de tokens
Ejemplo
Fabricacin productos
inicio
Planificar tareas
Flujo
Asignar tareas
Realizar tareas
finalizacin
Bifurcacin
Obtener orden de trabajo
Nodo de decisin
[ material disponible ]
[ material no disponible ]
Volver a planificar
Asignar tareas
Nodo de fusin
Obtener siguiente orden de trabajo
Divisin y Unin
Disear producto
divisin
Comercializar producto
Fabricar producto
unin
Vender producto
Ejemplo
Ejemplo
Elegir sitio
Contratar arquitecto
Realizar planos
Pedir ofertas
[ no aceptado ]
Construir
Trabajo administrativo
Finalizar construccin
Solicitar Producto
Procesar Pedido
Extraer Artculos
Enviar Pedido
Recibir Producto
Facturar al cliente
Pagar Factura
Cerrar Pedido
Cliente
Ventas
Almacn
Solicitar Producto
Procesar Pedido
Extraer Artculos
Enviar Pedido
Recibir Producto
Facturar al cliente
Calles
Pagar Factura Cerrar Pedido
Cliente
Solicitar Producto
Ventas
Almacn Objetos
Procesar Pedido
Extraer Artculos
Enviar Pedido
Facturar al cliente
Pagar Factura
Calles
Particiones de actividades
Pins
Regiones de Expansin
Calcular coste
:Dinero
Otras cuestiones
Conectores Enviar seales y aceptar eventos Caractersticas avanzadas de flujo de objetos Multidifusin y multireceptor Conjuntos de parmetros Nodo <<centralBuffer>>
Modelado de flujos de trabajo (workflow) como son los procesos de negocio (business process). Se puede asociar a cualquier elemento de modelado, pero lo ms normal es asociarlo a una operacin: diagrama de flujo de las acciones.
Eventos
Un evento es la especificacin de un acontecimiento que ocupa un lugar en el tiempo y espacio. En una mquina de estado, un evento es un estmulo que dispara una transicin. Eventos externos vs. eventos internos. Tipos de eventos:
Seales
Modelado Excepciones
<<exception>> Excepcion establecerManejador() primerManejador() ultimoManejador()
<<exception>> Duplicado
<<exception>> Overflow
<<exception>> Underflow
<<send>>
<<send>>
<<send>>
Tiempo
at (3 Oct 2006, 1000 UT), at(14:45PM), after 2 seconds, after 1 ms exiting Activo
Cambio
Representa un cambio de estado o que se satisface una condicin. when expresin-booleana when (saldo < 0)
Mquina de estados
Especifica la secuencia de estados por las que pasa un objeto a lo largo de su vida en respuesta a eventos, junto con sus respuestas a esos eventos. tiles para objetos reactivos, las instancias de su clase
deben responder a eventos externos o internos tienen un comportamiento que depende de su historia tienen un ciclo de vida modelado como una progresin de estados, transiciones y eventos.
Estados
Un estado es una situacin en la vida de un objeto en la que satisface cierta condicin, realiza alguna actividad o espera algn evento. Elementos de un estado:
Transiciones
Una transicin de un estado A a un estado B, se produce cuando se origina el evento asociado y se satisface la condicin especificada, en cuyo caso se ejecuta la accin de salida de A, la accin de entrada a B y la accin asociada a la transicin.
Elementos de una transicin:
Estados origen y destino Evento de disparo (cero o ms) Condicin de guarda (cero o ms) Accin (cero o ms)
apagar
Inactivo
haceFrio(tempDeseada) haceCalor(tempDeseada) tempOK
tempOK
Calentando
listo/encender()
Enfriando
haceCalor(tempDeseada) Activacin
haceFrio(tempDeseada)
Activo
ruido
Inactivo
Buscando
Rastreando
contactar
Acoplamiento
Partes de un estado
Espera Venta
introducirProducto
Introduccion Productos
enviarCargo (codigoCuenta,..)
Pago
rechazarPago
Pago No apobado
pagoAprobado
enviarCargo (codigoCuenta,..)
Envio
pedidoEntregado
Entregado
Subestados no ortogonales
introducirTarjeta
Activo
Validacin
Inactivo
cancelar mantener Seleccin
Procesando
Mantenimiento
[no continuar]
Impresin
Subestados ortogonales
Subestados ortogonales
Mantenimiento
Pruebas mantener
Inactivo
Probar perifericos
AutoDiagnosis
Manejo Ordenes
Espera
[continuar] Orden
Pulsar tecla
[no continuar]
Contenidos
Componentes
Es una parte modular de un sistema que encapsula el estado y comportamiento de un conjunto de clasificadores (p.e. clases). Especifica un contrato de los servicios que proporciona y de los que requiere en trminos de interfaces requeridas y proporcionadas Es una unidad reemplazable que se puede sustituir en tiempo de diseo o ejecucin por otro componente que ofrezca la misma funcionalidad en base a la compatibilidad de sus interfaces. Vista externa vs. Vista interna
Componentes
Un componente es una parte reemplazable de un sistema, que conforma con/y proporciona la implementacin de un conjunto de interfaces. Un sistema basado en componentes est formado por componentes que implementan las interfaces, junto con otros que acceden a los servicios proporcionados por esas interfaces. Servicios independientes de la localizacin y reemplazables. Interfaces proporcionadas vs. Interfaces requeridas.
Propiedades de un componente
Interfaz Componente Especificacin Componente
1 *
1..*
Implementacin Componente
1 *
Instancia Componente
Instalacin Componente
Propiedades de un componente
Es una unidad de despliegue independiente. Puede ser conectado con otros componentes En una aplicacin dada existir una nica copia Es una parte sustituible de un sistema (conforma con una o ms interfaces) Realiza una funcin bien definida (cohesin fsica y lgica) Abarca ms de una colaboracin de clases Existe en el contexto de una arquitectura bien definida. Presupone una infraestructura tecnolgica en la que se piensa utilizar
Componentes
Persona
<<component>>
AsignacionItem
Seguimiento
Pedido
Factura
ItemPedido
Interfaces proporcionadas
Interfaces requeridas
Componentes
<<component>>
Pedido
Interfaz proporcionad a
Interfaz requerida
Componentes
JerarquaElementos
explorador.java arbol.java
Componentes
Puertos
Representan un punto de interaccin entre una instancia de un clasificador (clase, componente) con su entorno o con las instancias que contiene (estructura interna). Conjunto semnticamente cohesivo de interfaces. Las interfaces asociadas especifican la naturaleza de la interaccin.
Requeridas: especifican las peticiones que se pueden hacer al entorno Proporcionadas: especifican las peticiones que puede recibir del entorno
Puertos
Los puertos son normalmente parte de un componente Cuando se crea una instancia de un componente, se crean instancias de sus puertos
Un puerto tiene multiplicidad Un puerto tiene identidad: un nombre La instancia de un puerto es un objeto de una clase que implementa las interfaces proporcionadas.
Cargar espectculos
Ventas Ticket
Vendedor Ticket
Tarjetas Crdito
cobros
ventas prioritarias
Ventas Ticket
Conexin de componentes
:Inventario
:EncontrarItems
:EnviarItems
GestionPedido
Una parte es una unidad de implementacin de un componente, que tiene un nombre y un tipo. Una instancia de un componente puede contener una o ms instancias de cada una de sus partes. La estructura interna de un componente est formada por las partes que lo implementan junto con las conexiones entre ellas.
Estructura interna
Compilador
lex:AnalizadorLexico
parse: Parser
Compilar
gen: GeneradorCodigo
opt:Optimizador [1..3]
Estructura interna
Venta Ticket Vuelos
:AsignacionAsiento
normal:Venta
:GestionInventario
Prioridad:Venta
Estructura interna
Ventas por Catalogo
:Cumplimentar
:Inventario
:EncontrarItems
:EnviarItems
:CapturaPedido
GestionPedido
Estructura Interna
<<component>>
A I1 b:B I1
<<delegate>>
I2 c:C
<<delegate>>
I2
Conectores
Una conexin entre dos puertos se denomina conector y denota un enlace en una instancia del componente. Los componentes pueden ser conectados directamente o porque tienen interfaces compatibles. Un conector delegacin conecta un puerto interno a uno externo.
Componentes
Subsistemas
Unidad de descomposicin de un sistema que se define como componente con el estereotipo <<subsystem>>. Elemento lgico, en tiempo de ejecucin se pueden instanciar sus contenidos.
<<subsystem>>
GUI
<<subsystem>>
Contenidos
Modelado del Comportamiento Diagramas de interaccin Diagramas de actividades Mquinas de estado Componentes Modelado de la Implementacin Artefactos y despliegue Diagramas de despliegue Colaboraciones UML, Metamodelado y MDA
Artefactos
Un artefacto es una parte fsica de un sistema que existe a nivel de la plataforma de implementacin. Es una implementacin fsica de un conjunto de elementos lgicos tales como clases y componentes:
Artefactos
artifact agente.java artifact agenteFraudes.dll
manifest
artifact agenteFraudes.dll manifest agenteFraudes PolticaFraudes
manifest
PatrnBsqueda
manifest
AgenteFraudes PolticaFraudes PatrnBsqueda
Tipos de Artefactos
Despliegue
Necesarios y suficientes para formar un sistema ejecutable: libreras dinmicas, ejecutables, script,.. Permanecen al final del proceso de desarrollo: archivos cdigo fuente y ficheros de datos a partir de los cuales se crean los artefactos de despliegue. Se crean durante la ejecucin: objeto .NET instanciado a partir de una DLL.
De ejecucin
Estereotipos de Artefactos
<<file>> : Archivo fsico <<deployment spec>> : especificacin de detalles de despliegue <<document>> : Archivo genrico que contiene cierta informacin <<executable>> : Archivo ejecutable <<script>> : Un script ejecutable sobre un intrprete <<source>> : Archivo fuente <<library>> : Una biblioteca como una DLL o un archivo JAR
Modelado de ejecutables
artifact v.exe
artifact Vwbas20.dll
artifact Vwdev20.dll
artifact Wscr20.dll
Nodos
Un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional que puede tener memoria y capacidad de procesamiento. Los artefactos se ejecutan en nodos Los artefactos se despliegan sobre los nodos. Dos tipos de nodos:
<<device>> : tipo de dispositivo fsico como un PC o un servidor <<execution environment>> : tipo de entorno de ejecucin de software, como el servidor web Apache o el contenedor EJB JBoss.
Nodos
Ventas
artifact pos.exe
artifact contactos.exe
manifest
manifest
Venta
Contrato
Diagramas de Despliegue
El despliegue es el proceso de asignar artefactos a nodos o instancias de artefactos a instancias de nodos Los diagramas de despliegue muestran el hardware sobre el que se ejecutar el sistema y cmo el software se despliega en ese hardware. Muestra la configuracin de los nodos que participan en la ejecucin y de los artefactos que residen en los nodos.
Forma de descriptor y forma de instancia Incluye nodos y arcos que representan conexiones fsicas entre nodos (o instancias de nodos y arcos).
Nodos
<<device>> PC Windows
<<device>> PC Linux
0..*
<<http>>
0..*
<<execution environment>>
FireFox
Diagrama de Despliegue
terminal
<<10-T-Ethernet>>
servidor
Unidad RAID
<<RS-232>> Consola
Contenidos
Modelado del Comportamiento Diagramas de interaccin Diagramas de actividades Mquinas de estado Modelado de la Implementacin Diagramas de componentes Diagramas de despliegue Colaboraciones UML, metamodelado y UML
Colaboraciones
Sociedad de clases, interfaces y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de los elementos. Parte estructural (modelo de clases) y parte de comportamiento (modelo de interaccin).
Colaboraciones
El ncleo de la arquitectura de un sistema est formado por un conjunto de colaboraciones que representan las decisiones de diseo ms importantes. Un sistema orientado a objetos bien estructurado se compone de un conjunto relativamente pequeo de colaboraciones. Modelado de un caso de uso, operacin o mecanismo (patrn o framework)
colaboracin
Hacer Pedido
Gestin Pedidos
realizacin
Modelo Estructural
Modelo Comportamiento
: Usuario 11: recalcularTotal() 1: aadirItem(codigo) 4: aadirItem(codigo) 2: aadirItem(codigo) 3: [primer producto] crear()
: MostrarProductos
: Aadir
: CarroCompras
6: [!nuevoItem]incrementarUnidades()
10: [nuevoItem]put(codigo,i)
5: i:=getItemCarro(codigo)
7: [nuevoItem]p:=get(codigo)
9: [nuevoItem]i:=creaItem(p)
: ItemCarro
: Producto
Ejercicio
Disea una colaboracin de un mecanismo Object Trading que separa la representacin de una informacin de su presentacin y edicin; las clases que representan a los objetos informacin no conocen a las clases que representan editores y viceversa. Un mismo editor puede editar diferentes tipos de informacin y una misma informacin puede ser editada por diferentes editores. El propsito del mecanismo es seleccionar un editor que colaborar adecuadamente con el objeto informacin, crear un objeto editor y lo ligar con el objeto informacin. Un objeto cliente solicitar a un objeto Trader editar cierta informacin.
necesita editar 1..1 ObjetoInformacion 1..n 1..n editado con 1..n Editor
p:= soportaInterfaz(i)
Colaboraciones Plantilla
Modelado de patrones de diseo
Subject Observer
Observer Subject Observer
Alarma
Ventana
Observer
Update()
+subject
observerState= subject->getState()
Contenidos
Modelado del Comportamiento Diagramas de interaccin Diagramas de actividades Mquinas de estado Modelado de la Implementacin Diagramas de componentes Diagramas de despliegue Colaboraciones UML, Metamodelado y MDA
Lenguajes OMG
MOF (Meta Object Facility) UML Perfiles UML OCL Action Semantics
Definir semntica de modelos de comportamiento Muy bajo nivel No define una sintaxis concreta Lenguaje estndar para definir transformaciones
QVT
Metamodelado
Ecore
Otros: Herramientas de metamodelado existentes disponen de uno propio (XMF, Metaedit+, DSL Tools,...)
Metamodelado
Un metamodelo define los elementos de un lenguaje de modelado y las relaciones entre ellos, y las restricciones (semntica abstracta). Un metamodelo define formalmente un lenguaje de modelado o DSL. Crear un metamodelo es una actividad de modelado conceptual OO
Metamodelado
context StateMachine inv: EstadosDistintoNombre states-> forAll (s1 | states->forAll (s2 | s1.name = s2.name implies s1 = s2)) end
0..1 StateMachine 0..1
0..1
0..n
CompositeState
Metamodelado
after (2 sec) send c.estaActivo
ruido
Inactivo
Buscando
Rastreando
contactar
Acoplamiento
Metamodelado
Clases y Atributos Asociaciones en MOF y referencias entre objetos en Ecore Agregacin en MOF Generalizacin Paquetes
MOF es el lenguaje para crear metamodelos propuesto por OMG para MDA.
UML est definido como un metamodelo MOF. Aplicable a cualquier dominio. Lenguajes OMG: CWM, EJB, EAI, EDOC
MOF es descrito con la notacin UML, OCL y texto informal. La notacin para metamodelos MOF es la sintaxis concreta de UML: Puede generar confusin al principio! Comparte elementos de modelado con UML: clases, atributos, generalizacin, etc.
MOF
Cada elemento del lenguaje de modelado se representa mediante una clase y sus propiedades como atributos Las relaciones entre elementos se representan como asociaciones. La generalizacin permite expresar que un elemento es una especializacin de otro. Se usa OCL para expresar la semntica esttica. Uso de paquetes si el metamodelo es muy grande
Nivel M3 M2 M1 M0
Descripcin
MOF metamodelos, instancias de los elementos MOF modelos, instancia de un metamodelo MOF el sistema, objetos y datos, instancias de los elementos de un modelo
M1 M0
Modelo de clases UML para un sistema TPV Instancias de elementos en el modelo de clases del TPV
Lenguaje de especificacin para escribir expresiones sobre modelos, p.e. queries, reglas de derivacin de atributos, el cuerpo de operaciones de consulta, pre y postcondiciones o el invariante, guardas. Extiende la potencia expresiva de UML y permite crear modelos ms precisos y ms completos. Es tipado, cada expresin OCL tiene un tipo. Utilizado para escribir las restricciones
Expresiones OCL
context c : Empresa inv suficientesEmpleados: c.numeroEmpleados > 50
Expresiones OCL
context Person::cumpleaos() post: edad = edad@pre + 1
context Empresa::contratar(p : Persona) post: empleados = empleados@pre->including(p) and precioAccion() = precioAccion@pre() + 10 context Persona::getEsposoActual() : Persona pre: self.estaCasada = true body: self.matrimonios->select( m | m.fin = false ).esposo
MDA
Propuesta basada en estndares de OMG: UML, MOF, XMI, JMI, QVT,... Separa la especificacin de la funcionalidad del sistema de su implementacin sobre una plataforma concreta. Distincin entre PIM y PSM Basada en la arquitectura de cuatro niveles
MDA
PIM PSM
Cdigo
MDA
Transformaciones de modelos en MDA
PIM
L1
UML
Motor M2M
PSM
L2
UML
Motor M2C
Cdigo
L3
Definicin Transformacin L1 a L2
L4
Lenguaje M2M
Definicin Transformacin L2 a L3
L5
Lenguaje M2C
PIM
PSM
Cdigo
public interface Cuenta extends EJBObject {...} public interface CuentaHome extends EJBHome {...} public abstract class CuentaBean implements EntityBean{...} ...
MDA
PIM
PSM Relacional
PSM EJB
PSM Web
Cdigo SQL
Cdigo EJB
Cdigo JSP/Servlets
307