Especificacion de Sistemas de Software en UML
-
Upload
alejorobert -
Category
Documents
-
view
53 -
download
13
description
Transcript of Especificacion de Sistemas de Software en UML
-
Especificacin de sistemassoftware en UML
Ernest Teniente LpezDolors Costal CostaM. Ribera Sancho Sams
-
POLITEXT 153
Especificacin de sistemassoftware en UML
-
POLITEXT
EDICIONS UPC
Dolors Costal CostaM. Ribera Sancho SamsErnest Teniente Lpez
Especificacin de sistemassoftware en UML
-
Primera edicin: setiembre de 2003
Diseo de la cubierta: Manuel Andreu
Los autores, 2003
De la traduccin, Sergio Morales Garca, 2003
Edicions UPC, 2003Edicions de la Universitat Politcnica de Catalunya, SLJordi Girona Salgado 31, 08034 BarcelonaTel.: 934 016 883 Fax: 934 015 885Edicions Virtuals: www.edicionsupc.esE-mail: [email protected]
Produccin: CPET (Centre de Publicacions del Campus Nord)La Cup. Gran Capit s/n, 08034 Barcelona
Depsito legal: B-33082-2003ISBN: 84-8301-723-7
Quedan rigurosamente prohibidas, sin la autorizacin escrita de los titulares del copyright, bajo las san-ciones establecidas en las leyes, la reproduccin total o parcial de esta obra por cualquier medio o pro-cedimiento, comprendidos la reprografa y el tratamiento informtico, y la distribucin de ejemplares deella mediante alquiler o prstamo pblicos.
-
ndice
1 Introduccin a la ingeniera del software 9
2 Requisitos y especificacin 17
3 Introduccin a la orientacin a objetos 27
3.1 Motivacin y orgenes .........................................................................................................27
3.2 Aspecto esttico...................................................................................................................32
3.3 Aspecto dinmico ................................................................................................................33
3.4 El lenguaje UML (Unified Modeling Language) ................................................................36
4 El lenguaje UML 39
4.1 Modelo conceptual de datos en UML..................................................................................39
4.2 El lenguaje OCL (Object Constraint Language)..................................................................58
4.3 Modelo de casos de uso en UML.........................................................................................67
4.4 Modelo del comportamiento en UML .................................................................................77
4.5 Modelo de los estados en UML ...........................................................................................94
5 El proceso unificado de desarrollo del software 101
6 Coleccin de ejercicios 107
-
Introduccin a la ingeniera del software 1
Introduccin a la ingeniera del software
Software Importancia Evolucin Caractersticas Crisis del software
Ingeniera del software Definiciones Caractersticas Visin genrica
Paradigmas Ciclo de vida clsico Prototipaje Modelo en espiral
Bibliografa
Introduccin a la ingeniera del software 2
Evolucin de Costes del hardware y del software
1960 70 80 90
100%
HARDWARE
SOFTWARE
9
Los autores, 2003; Edicions UPC, 2003
-
Introduccin a la ingeniera del software 3
Evolucin del software
1950 60 70 80 90 2000
BatchPoca distribucinA medida
MultiusuarioTiempo realBases de datosSoftware de producto
DistribucinHardware baratoSoftware de consumo
Sistemas sobremesaSistemas expertosClculo paralelo
Aplicaciones web
Introduccin a la ingeniera del software 4
Caractersticas del software
Se desarrolla, no se fabrica.
No se estropea.
Mantenimiento ms difcil que el hardware.
Se construye a medida, no se reusa demasiado.
10
Los autores, 2003; Edicions UPC, 2003
-
Introduccin a la ingeniera del software 5
Fallos H/S
ndiceFallos
hardware
software
tiempo
Introduccin a la ingeniera del software 6
Aplicaciones del software
Sistemas
Tiempo real
Gestin
De ingeniera
Cientfico
Empotrado
De PC
De inteligencia artificial
11
Los autores, 2003; Edicions UPC, 2003
-
Introduccin a la ingeniera del software 7
Crisis del software
Crisis? Afliccin crnica!
Problemas: Evolucin continua Insatisfaccin de los usuarios Poca calidad Mantenimiento difcil
Causas: Naturaleza del software Complejidad Gestin
Mitos: De gestin De los clientes De los diseadores
Introduccin a la ingeniera del software 8
Resultados de proyectos de software
In fo rm e C H A O S (19 9 4 )Acabado y operativo, perofuera de plazo, de presupuesto
y sin satisfacer todos losrequisitos
52,7 %
Acabado en el plazo ypresupuesto, satisfaciendo los
requisitos16,2 %
Cancelado durante eldesarrollo
31,1 %
12
Los autores, 2003; Edicions UPC, 2003
-
Introduccin a la ingeniera del software 9
Ingeniera del software
Establecimiento y uso de principios de ingeniera orientados aobtener software:
Econmico
Fiable
Que funcione eficientemente
Que satisfaga las necesidades de los usuarios
Introduccin a la ingeniera del software 10
Un ingeniero ...
Dispone de un abanico de tcnicas probadas que dan resultadosprecisos.
Se preocupa de la fiabilidad y del rendimiento.
Trata de reducir costes y complejidad.
Basa sus modelos en teoras matemticas slidas.
Construye prototipos de los nuevos diseos.
Utiliza diagramas formales.
13
Los autores, 2003; Edicions UPC, 2003
-
Introduccin a la ingeniera del software 11
El proceso de la ingeniera
Formulacin
Anlisis
Generacin
Seleccin
Especificacin
Implementacin
Modificacin
Introduccin a la ingeniera del software 12
Visin genrica de la ingeniera del software
Definicin: Anlisis del sistema Planificacin del proyecto Anlisis de requisitos del software
Desarrollo: Diseo del software Codificacin Prueba
Mantenimiento: Correccin Adaptacin Mejora
14
Los autores, 2003; Edicions UPC, 2003
-
Introduccin a la ingeniera del software 13
Ciclo de vida clsico
MANTENIMIENTO
ANLISIS REQS.
ESPECIFICACIN
DISEO
CODIFICACIN
PRUEBA
Introduccin a la ingeniera del software 14
Prototipaje
ANLISISREQUISITOS
DISEORPIDO
PROTO_TIPO
EVALUACIN
REFI_ NAMIENTO
PRODUCTO
15
Los autores, 2003; Edicions UPC, 2003
-
Introduccin a la ingeniera del software 15
Modelo en espiral
Planificacin Anlisis de riesg s
Evaluacin Ingeniera
Introduccin a la ingeniera del software 16
Bibliografa
Pressman, R.Ssoftware Engineering: A Practitioners Approach.5a edicin.McGraw Hill, 2001. (Cap. 1y 2)
The CHAOS Report, 1994http://www.standishgroup.com/sample_research/chaos_1994_1.php
16
Los autores, 2003; Edicions UPC, 2003
-
Requisitos y especificaciones 1
Requisitos y especificaciones
Determinacin de los requisitos del software Requisitos del sistema vs requisitos del software Etapas Estrategias
Especificaciones de sistemas software Requisitos funcionales y no funcionales Propiedades deseables de las especificaciones Estndares de documentacin
Bibliografa
Requisitos y especificaciones 2
Requisitos del sistema vs. requisitos del software
La solucin al problema se puede realizar con software, hardware,manualmente, o con una combinacin de los tres.
Si la solucin es compuesta, antes de disear los detalles de uncomponente software concreto hay que disear el sistema global.
Requisito: Condicin o capacidad necesitada por un usuario contal de solucionar un problema o conseguir un objetivo
Ejemplo de sistema compuesto: refinera automatizadaEjemplo de sistema slo software: control de stock
17
Los autores, 2003; Edicions UPC, 2003
-
Requisitos y especificaciones 3
Etapas de la ingeniera de sistemas
Determinar requisitos del sistema global Especificar requisitos del sistema global Diseo del sistema global
HARDWARE
Determinarrequisitos
Especificarrequisitos
Diseo
SOFTWARE PERSONAS
Ingenieradel hardware
Ingenieradel software
Ingeniera de sistemas
Requisitos y especificaciones 4
Determinar requisitos del sistema global
Comprensin de los objetivos y necesidades del usuario Definir el conjunto de sistemas que podran satisfacer las necesidades u
objetivos y evaluarlos Escoger el sistema ms adecuado
QU SISTEMA HAY QUE CONSTRUIR?
ALMACN
Sistema que recibe y verifica los productossolicitados a los proveedores y los almacena en lasestanteras
18
Los autores, 2003; Edicions UPC, 2003
-
Requisitos y especificaciones 5
Especificar los requisitos del sistema global Describir el comportamiento externo del sistema, desde el punto de
vista del usuario o del entorno
QU HA DE HACER EL SISTEMA?
albarn
1. Comprobar si esperado
2. Comprobar correspondencia
3. Control de calidad
4. Actualizar pedido
5. Determinar dnde va
6. Almacenar
PEDIDO APROVEEDOR
error
error
defectuoso
PRODUCTOS
ESTANTERAS
PRODUCTOS EN ESTANTERAS
Requisitos y especificaciones 6
Diseo del sistema global Determinar la arquitectura general del sistema que mejor satisfaga
los requisitos en trminos de: componentes fsicos: hardware, software, personas comunicacin entre ellos
MANUAL
albarn
PEDIDO APROVEEDOR
error
error
defectuoso
PRODUCTOSESTANTERAS
PRODUCTOS EN ESTANTERAS
SOFTWARE
HARDWARE
1. Comprobar si esperado
3. Control de calidad
4. Actualizar pedido
5. Determinar dnde va
6. Almacenar
2. Comprobar correspondencia
orden
19
Los autores, 2003; Edicions UPC, 2003
-
Requisitos y especificaciones 7
Diseo del sistema global
albarn
Recepcin
Transp rte
SistemaInf rmtic
albarnaviso
ordenerrores
resultadodefectuoso
pedido
Requisitos y especificaciones 8
Determinar requisitos del software
Es el subconjunto de los requisitos del sistema global que han sidoasignados al componente software concreto
SISTEMAINFORMTICOalbarn
resultado
aviso
orden
errores
pedido
20
Los autores, 2003; Edicions UPC, 2003
-
Requisitos y especificaciones 9
Especificar los requisitos del software Describir con detalle el comportamiento externo del componente
software concreto
Trataralbaranes
Recibirpedidos
Actualizarpedidos
Emitirorden
albarn
error
pedido
pedidos
productos
estanteras
resultado
orden
Requisitos y especificaciones 10
Estrategias de determinacin de los requisitos
Solicitarlos al usuario.
Extraerlos de un sistema software existente.
Sintetizarlos a partir del sistema global.
Descubrirlos mediante experimentacin.
21
Los autores, 2003; Edicions UPC, 2003
-
Requisitos y especificaciones 11
Requisitos del software
Funcionales Describen todas las entradas y salidas y la relacin entre ambas
de datos de proceso
No funcionales Definen las cualidades generales que ha de tener el sistema al
realizar su funcin Eficiencia Tipos de interfaces Econmicos Estructurales Polticos Calidad
Requisitos y especificaciones 12
Factores de calidad del software
Eficiencia
Flexibilidad
Integridad
Mantenibilidad
Portabilidad
Fiabilidad
Actualidad
Reusabilidad
Testability
Usabilidad
Interoperabilidad
22
Los autores, 2003; Edicions UPC, 2003
-
Requisitos y especificaciones 13
Eficiencia
Flexibilidad
Integridad
Mantenibilidad
Portabilidad
Fiabilidad
Actualidad
Reusabilidad
Testability
Usabilidad
Interoperabilidad
Factores de calidad del software: Conflictos
Requisitos y especificaciones 14
Propiedades deseables de las especificaciones
No ambiguas
Completas
Verificables
Consistentes
Modificables
Trazables
Usables durante la operacin y el mantenimiento
23
Los autores, 2003; Edicions UPC, 2003
-
Requisitos y especificaciones 15
Cmo organizar una especificacin de requisitos?Estndar de documentacin ANSI/IEEE (I)
1. Introduccin1.1 Propsito de la especificacin1.2 Alcance del producto1.3 Definiciones y abreviaturas1.4 Referencias1.5 Visin general de la especificacin
2. Descripcin general2.1 Perspectiva del producto2.2 Funciones del producto2.3 Caractersticas de los usuarios2.4 Restricciones generales2.5 Suposiciones y dependencias
3. Requisitos especficos4. Apndices5. ndice
Requisitos y especificaciones 16
Cmo organizar una especificacin de requisitos?Estndar de documentacin ANSI/IEEE (II)
3. Requisitos especficos3.1 Requisitos de interfaces externas3.2 Requisitos funcionales3.3 Requisitos de rendimiento3.4 Requisitos lgicos de la base de datos3.5 Restricciones de diseo3.6 Atributos del sistema software
a) Fiabilidadb) Disponibilidadc) Seguridadd) Mantenibilidade) Portabilidad
3.7 Organizacin de los requisitos especficos3.8 Otros requisitos
24
Los autores, 2003; Edicions UPC, 2003
-
Requisitos y especificaciones 17
Bibliografa
Shumate, K.; Keller, M.Software Specification and Design - A Disciplined Approach for Real-Time Systems.John Wiley, 1992. (Cap. 3)
Davis, A. M.Software Requirements - Objects, Functions and States.Prentice-Hall, 1993. (Cap. 1-5)
IEEE Recommended Practice for Software RequirementsSpecificationsIEEE Std 830-1998 , 20 Oct 1998.
25
Los autores, 2003; Edicions UPC, 2003
-
Introduccin a la orientacin a objetos 1
Introduccin a la orientacin a objetos
Motivacin y orgenes
Visin de un sistema software Aspecto esttico Aspecto dinmico
La notacin UML
Introduccin a la orientacin a objetos 2
Motivacin
- Aparicin de los lenguajes de programacin orientados a objetosSIMULA: finales de los aos 60SMALLTALK: principios de los aos 70
- El uso de estos lenguajes requiere un nuevo enfoque de anlisis yde diseo.
- Otros factores:Desarrollo de nuevas aplicacionesnfasis principal en la estructura de datos
Aparicin de los primeros mtodos de diseo y de anlisis
orientados a objetos
27
Los autores, 2003; Edicions UPC, 2003
-
Introduccin a la orientacin a objetos 3
Fusion
Procesos y modelosrecomendados
OOSE
BOOCH
OMT UML
Martin-Odell
Shlaer &Mellor
Orgenes
Rumbaugh, Blaha, Premerlani (OMT) - 1991Coad, Yourdon - 1991Shlaer, Mellor - 1992Booch - 1992Odell, Martin - 1992Jacobson (OOSE) - 1993Fusion - 1994Booch, Rumbaugh, Jacobson (UML) - 1997
Introduccin a la orientacin a objetos 4
Visin de un sistema software
28
Los autores, 2003; Edicions UPC, 2003
-
Introduccin a la orientacin a objetos 5
Objetos
Objeto:Entidad que existe en el mundo real.Tienen identidad y son distinguibles entre ellos.
el avin conmatrcula 327
una manzana un semforo
el avin conmatrcula 999
la factura 3443
Introduccin a la orientacin a objetos 6
Clases de objetos
Abstraccin: eliminar distinciones entre objetos para poderobservar aspectos comunes.
clase avinabstraccin
Los objetos de una clase tienen las mismas propiedades y losmismos patrones de comportamiento.
Clase de objetos: Describe un conjunto de objetos con:
- las mismas propiedades
- comportamiento comn
- idntica relacin con otros objetos
- semntica comn
Avin
29
Los autores, 2003; Edicions UPC, 2003
-
Introduccin a la orientacin a objetos 7
Atributos
Atributo: Es una propiedad compartida por los objetos de una clase.
Ejemplos:Persona => nombre, direccin, telfono, ...Avin => modelo, capacidad, color, ...
- Cada atributo tiene un valor (probablemente diferente) para cada objeto.
- Los atributos pueden ser bsicos o derivados.
PersonaNombreDireccinTelfonoFecha_nacimientoEdad
AvinModeloCapacidadColor
Introduccin a la orientacin a objetos 8
Operaciones (I)
Operacin: Es una funcin o transformacin que se puede aplicar alos objetos de una clase.
- Las operaciones de un objeto son invocadas por otros objetos.
Mtodo: especificacin procedimental (implementacin) de unaoperacin dentro de una clase.
Encapsulacin: Consiste en separar los aspectos externos de un objetode los detalles de implementacin.
PersonaNombreDireccinTelfonoCambio_direccinCambio_trabajo
AvinModeloCapacidadColorRepararMover
30
Los autores, 2003; Edicions UPC, 2003
-
Introduccin a la orientacin a objetos 9
Operaciones (II)
- En las operaciones, hay que indicar tambin el tipo de los argumentos ydel resultado.
Polimorfismo:
- Una misma operacin se puede aplicar a diferentes clases.
- Su implementacin depende de cada clase.
TringuloColorPosicin
Girar (ngulo: Real)Seleccionar (p:Punto):Booleano
CuadradoColorPosicin
Girar (ngulo: Real)
Introduccin a la orientacin a objetos 10
Asociaciones
Asociacin:Define la manera de enlazar o conectar objetos dediferentes clases.
Ejemplo: Un pas tiene una nica capital.
tiene_capitalPas
NombreHabitantes
Ciudad
NombreHabitantes
31
Los autores, 2003; Edicions UPC, 2003
-
Introduccin a la orientacin a objetos 11
Generalizacin / Especializacin
Generalizacin: Es el acto o resultado de distinguir un conceptoque es ms general que otro.
Herencia: Permite que las propiedades y las operaciones de una clase seanaccesibles en sus subclases.
EmpleadoNombreSueldo
ContratarPagar_sueldoJubilar
DirectivoPeriodo contratoDesp. autor.Autorizar gastosJubilar
ViajanteReginCuotaAsignar reginAsignar cuota
. . .
Especializacin Generalizacin
Introduccin a la orientacin a objetos 12
Orientacin a objetos (I)
Aspecto esttico: Describe la estructura esttica de los objetos delsistema y sus interrelaciones.
Intra - objeto Inter - objetos
Aspectoesttico
Clases de objetosAtributosOperaciones
AsociacinGeneralizacin...
32
Los autores, 2003; Edicions UPC, 2003
-
Introduccin a la orientacin a objetos 13
Descripcin del comportamiento (I)
Los objetos se comunican mediante la invocacin de operacionesde otros objetos.
Introduccin a la orientacin a objetos 14
Descripcin del comportamiento (II)
Existe mucha divergencia entre los mtodos actuales en el momentode tratar el aspecto dinmico.
El aspecto dinmico de un sistema describe:
- Interacciones entre los objetos
- Posibles estados de un objeto
- Transiciones entre estados
- Qu eventos se producen
- Qu operaciones se ejecutan
Aspecto dinmico (de comportamiento): Describe los aspectos de unsistema que cambian con el tiempo.
33
Los autores, 2003; Edicions UPC, 2003
-
Introduccin a la orientacin a objetos 15
Descripcin del comportamiento (III)
Soltera
boda
Casada
Viuda
divorcio
Divorciada
nacimiento
Separada
enviudarseparacin
enviudar
divorcio
boda boda
Diagrama de transicin de estados: Especifica elcambio de estado de un objeto causado por loseventos.
Ejemplo: estado civil de una persona
Introduccin a la orientacin a objetos 16
Descripcin del comportamiento (IV)
Esquema de eventos: Permite especificar la interaccin entre
diferentes objetos (usado por el mtodo de Martin y Odell [MO92]).
Cliente envapedido
Cliente pagafactura
Aceptarpedido
Enviarfactura
Cerrarpedido
Entregarpedido
Prepararpedido
pedidopreparado
pedidoentregado
pedidocerrado
facturaenviada
facturapagada
34
Los autores, 2003; Edicions UPC, 2003
-
Introduccin a la orientacin a objetos 17
Orientacin a objetos (II)
Aspecto esttico: Describe la estructura esttica de los objetos delsistema software y sus interrelaciones.
Aspecto dinmico (de comportamiento): Describe los aspectos de unsistema software que cambian con el tiempo.
Intraobjeto Interobjetos
Aspectoesttico
Clases de objetosAtributosOperaciones
AsociacinGeneralizacin...
Aspectodinmico
Diagrama detransicin deestados
Esquema de eventos
Introduccin a la orientacin a objetos 18
Anlisis y diseo orientados a objetosAnlisis:
- Creacin de una especificacin del problema y de los requisitos- Qu ha de hacer el sistema software
Se usan los mismos conceptos en anlisis y diseo.
Es difcil determinar dnde acaba el anlisis orientado a objetos ydnde comienza el diseo:
- estrategia de desarrollo iterativa- diferencias de criterios segn los autores
Diseo:- Definicin de una solucin software que satisfaga los requisitos- Cmo lo har el sistema
orientados a objetos
35
Los autores, 2003; Edicions UPC, 2003
-
Introduccin a la orientacin a objetos 19
El lenguaje UML (Unified Modeling Language)
Mayo01 OMG adopta UML 1.4
Noviembre97 OMG adopta UML 1.1 como estndar
Enero97 - Publicacin del UML 1.0
Junio96 & Octubre96
OOPSLA 95
Other methods Booch 91 OMT-1 OOSE
Booch93 OMT-2
Unified Method 0.8
UML 0.9 & UML 0.91
UML 1.0
UML 1.1
Industrialitzacin
Estandarizacin
Unificacin
Fragmentacin
UML PartnersExpertise
publicfeedback
UML 1.4
Introduccin a la orientacin a objetos 20
El tringulo del xito
Notacin
Proceso(metodologa)
Herramienta
Rational Rose,Objecteering,Visio, etc.
Craig LarmanThe Unified Process
U.M.L.
36
Los autores, 2003; Edicions UPC, 2003
-
Introduccin a la orientacin a objetos 21
Modelode anlisis
Casos de uso- nivel alto- esencial
Diagramas decasos de uso
Diagramasestticos deestructura para objetosdel dominio
Diagramas desecuenciadel sistema
Diagramasde estado deobjetos ycasos de uso
Modelo decasos de uso
Modelo delcomportamientodel sistema
Modelo de losestados
Contratospara lasoperacionesdel sistema
Modelo de anlisis (especificacin)
Modelo conceptual delos datos
Introduccin a la orientacin a objetos 22
Bibliografa
Pressman, R.S.Software Engineering: A Practiotioners Approach (5th edition)Mc-Graw-Hill, 2001 (Cap. 20 y 21)
Booch, G.Object-Oriented Analysis and DesignBenjamin/Cummings, 1994
Jacobson, I. et al.Object Oriented Software Engineering: A Use Case Driven ApproachAddison-Wesley, 1992
Rumbaugh, J. et al.Object-Oriented Modelling and DesignPrentice-Hall, 1991
Larman, C.Applying UML and PatternsAn Introduction to Object-Oriented Analysis and DesignPrentice-Hall 1998
Jacobson, I.; Booch, G.; Rumbaugh, J.The Unified Software Development ProcessAddison-Wesley, 1999
37
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 1
Introduccin Objetos y clases de objetos Atributos Asociaciones Clase asociativa Generalizacin/Especializacin Agregacin y composicin Ampliaciones Ejemplos
Modelo conceptual de los datos en UML
Modelo conceptual de los datos en UML 2
Modelo de anlisis (especificacin)
Casos de uso- nivel alto- esencial
Diagramas decasos de uso
Diagramasestticos deestructura de objetosdel dominio
Diagramas desecuenciadel sistema
Diagramasde estado deobjetos ycasos de uso
Modelo decasos de uso
Modelo delcomportamientodel sistema
Modelo de losestados
Contratospara lasoperacionesdel sistema
Modelo conceptual delos datos
Modelode anlisis
39
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 3
Es la representacin de los conceptos (objetos) significativos enel dominio del problema.
Muestra, principalmente: clases de objetos asociaciones entre clases de objetos atributos de las clases de objetos restricciones de integridad
Modelo conceptual de los datos
Modelo conceptual de los datos en UML 4
Objetos
Objeto:Entidad que existe en el mundo realTienen identidad y son distinguibles entre ellos
el avin conmatrcula 327 una manzana un semforo
el avin conmatrcula 999la factura 3443
40
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 5
Clase de objetos
Abstraccin: Eliminar distinciones entre objetos para poderobservar aspectos comunes.
clase avinabstraccin
Los objetos de una clase tienen las mismas propiedades ylos mismos patrones de comportamiento.
Clase de objetos: Describe un conjunto de objetos con:
- las mismas propiedades
- comportamiento comn
- idntica relacin con otros objetos
- semntica comn
Avin
Modelo conceptual de los datos en UML 6
Un terminal de punto de venta (TPV) es un sistema computerizado usado para registrarlas ventas y gestionar pagos. Se usa principalmente en supermercados y grandesalmacenes. Incluye componentes hardware (como el ordenador y el escner del cdigo de barras) y software para ejecutar el sistema.Se nos pide que especifiquemos el software de este sistema.
Ejemplo: Terminal punto de venta
41
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 7
TPV Supermercado Venta
Cliente
Pago
Lnea de venta
Ejemplo TPV: Clases de objetos
Producto
Modelo conceptual de los datos en UML 8
Un atributo es una propiedad compartida por los objetos de una clase.
TPV Supermercado Venta
Cliente
Pago
ProductoLnea de venta
direccin: Stringnombre: String
fecha: Datehora: Time
cantidad: Integer
importe: Integer
upc:Integer descripcin [0..1]:Stringprecio: Integer
Ejemplo TPV: Atributos
Los atributos:- Pueden tomar valores nulos (por ejemplo: descripcin).- Pueden ser multivaluados (por ejemplo: telfs).- Pueden ser definidos por el usuario mediante enumeraciones.
-Por ejemplo, TipoCliente se define a parte como una enumeracin con losvalores que puede tener y que son: Normal y Preferente.
nombre: Stringtelfs [1..*]: Integertipcli: TipoCliente
nm-pv: Integer
42
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 9
Es la representacin de relaciones entre dos o ms objetos.
- direccin de lectura
Persona Ciudad
- nombre de asociacin
Vive en
Asociaciones
Modelo conceptual de los datos en UML 10
Asociaciones de orden superior a dos
Se matricula
Asignatura Cuatrimestre
Alumno
43
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 11
A B1
A B1..*
A B*
A B0..*
A B0..1
A B2..5
A B2, 5
A B1..3,7..10,15..*
Multiplicidad de las asociaciones binarias
Dada una instancia a de la clase A cualquiera, la multiplicidad delextremo B define cuntas instancias de B se pueden asociar con a en
un momento de tiempo determinado.
Modelo conceptual de los datos en UML 12
Multiplicidad en las asociaciones ternarias
Dadas una instancia a de A y una instancia b de B cualesquiera,la multiplicidad en el extremo C nos dice cuntas instancias de
C se pueden asociar con la pareja (a,b).
A B
C0..2
44
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 13
Multiplicidad en las asociaciones ternarias Ejemplos
Se responsabiliza
Asignatura Cuatrimestre
Profesor
Se matricula
Asignatura Cuatrimestre
Alumno
Segn este esquema, para toda pareja de asignatura y cuatrimestre, ha de haber comomnimo un profesor reponsable.
1..2
* *
* *
0..500
Este esquema permite que haya alguna pareja de asignatura y cuatrimestre para la cualno hay ningn alumno que se haya matriculado de la asignatura en el cuatrimestre.
Modelo conceptual de los datos en UML 14
Restricciones textualesLas restricciones que no se pueden especificar grficamente con la notacin UML seespecifican de forma textual
La especificacin textual se puede hacer con lenguaje natural, con OCL, etc.
Equipo mdicoPertenece aEspecialidad
Mdico
1
Tiene Asignado a
*
*
*
*
*
nom-esp cod-equipo
num-col
1- Dos especialidades diferentes no pueden tener el mismo nom-esp.2- Dos equipos mdicos diferentes no pueden tener el mismo cod-equipo.3- Dos mdicos diferentes no pueden tener el mismo num-col.4- Un mdico no puede estar asignado a un equipo mdico que pertenezca a unaespecialidad que el mdico no tiene.
Restricciones de clave externa
45
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 15
Cada extremo de una asociacin es un rol, que tiene diversas propiedades como:- nombre- multiplicidad
El nombre de rol identifica un extremo de la asociacin y describe el papeljugado por los objetos en la asociacin.
Vuela hacia* 1destinoVuelo Ciudad
Nombre de RolDescribe el Rol de unaciudad en la asociacinvuela hacia
Nombre de rol en las asociaciones
Modelo conceptual de los datos en UML 16
Asociaciones recursivas
Asociaciones en las que una misma clase de objetos participa msde una vez (con papeles diferentes o no).
Persona
padre hijo*0..2
Tiene
Persona**
Tiene por amigo
46
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 17
Representa una asociacin que se puede ver como una clase.
Clase asociativa
Clase asociativaLos atributos hacen referencia a laasociacinSu vida depende de la asociacin
Estudiante
nombrecrditos
EstMatriculado Asignaturadireccinnombre * *
Matrcula
nota
Empresa
nombredireccin
Emplea Persona
* *
Contrato
sueldo
nombre
Modelo conceptual de los datos en UML 18
Ejemplo de clase asociativa
ParticipaProyecto Empleado
ParticipanteAsiste
Reunin
* *
* *
No es equivalente a:
AsistirProyecto Empleado
Reunin
* *
*
47
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 19
Generalizacin/Especializacin
Persona
Hombre Mujer
E G
superclase
subclase
Identificar elementos comunes entre los objetos definiendo relaciones desuperclase (objeto general) y subclase (objeto especializado).
sexo {disjoint, complete}
disjoint Un descendiente no puede ser de ms de una subclase.overlapping Un descendiente puede ser de ms de una subclase.complete Se han especificado todas las subclases.incomplete La lista de subclases es incompleta.
La clasificacin puede ser esttica o dinmica.
discriminador - Es el nombre de la particin. Ha de ser nico entre losatributos y roles de la superclase.
Modelo conceptual de los datos en UML 20
Permite entender los conceptos en trminos ms generales, refinados y abstractos.Hace los diagramas ms expresivos.
Todos los objetos de la subclase lo son tambin de la superclase. La definicin de la superclase tiene que ser aplicable a la subclase
- atributos - asociaciones - restricciones(- operaciones)
cantidad: Dinero
Pagoen metlico
Pagoa crdito
Pagocon taln
PagoVenta
Paga por
Generalizacin / Especializacin
tipo {disjoint, complete}
48
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 21
Motivaciones para particionar una clase en subclases La subclase tiene atributos adicionales. La subclase tiene asociaciones adicionales. La subclase es tratada o manipulada de forma diferente a las otras subclases. La subclase se comporta de manera diferente a la superclase o a otras subclases.
cantidad: Dinero
Pagoen metlico
Pagoa crdito
Pagocon taln
Pago asociacionesadicionales
Tarjeta
*
1
Venta11
Atributos y asociaciones comunes
Cada pago setrata diferente
Paga por
Identifica crdito
Generalizacin / Especializacin
tipo{disjoint, complete}
nm-taln: Integer
Modelo conceptual de los datos en UML 22
Generalizacin/Especializacin
Motivaciones para definir una superclase Las subclases potenciales representan variaciones de un mismo concepto. Las subclases tienen atributos que pueden ser factorizados y expresados en las
superclases. Las subclases tienen asociaciones que pueden ser factorizadas y relacionadas con la
superclase.
cantidad: Dinero
Pagoen metlico
Pagoa crdito
Pagocon taln
Pago asociacionesadicionales
Tarjeta
*
1
Venta11
Atributos y asociaciones comunes
Cada pago setrata diferente
Paga por
Identifica crdito
tipo{disjoint, complete}
nm-taln: Integer
49
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 23
La agregacin es un tipo de asociacin usada para modelar relaciones parte-todoentre objetos.
El todo se denomina compuesto y las partes componentes.
* *Ruta Segmento
*Men RecetaUsa 1..*
Agregacin
Contiene
La distincin entre asociacin y agregacin es a menudo subjetiva.
La nica restriccin que aade la agregacin respecto a la asociacin es que lascadenas de agregaciones entre instancias de objetos no pueden formar ciclos.
A B
C
A1
B1 B2
C1 C2 C3
* **
*
*
*
A2 A3 A4
Modelo conceptual de los datos en UML 24
La composicin es un tipo de agregacin por la cual:
- La multiplicidad del extremo compuesto puede ser como mximo 1 (comomximo un componente lo es de un compuesto).
- Si un componente est asociado a un compuesto y el compuesto se borraentonces el componente tambin se ha de borrar (no lo puede sobrevivir).
Composicin
1 0..5Mano Dedos
1 0..*Venta LneadeVenta
0..1Catlogo Especificacin
de Producto1..*
Contiene
Contiene
Tiene
50
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 25
Agregacin/Composicin
Existe una semejanza todo-parte fsica o lgica.
Algunas propiedades del todo se propagan a las partes (como destruccin, movimiento...).
Agregacin y composicin - Cundo mostrarla
Composicin
La vida de la parte est incluida en la vida del compuesto. Existe una dependencia crear-borrar de la parte respecto alcompuesto.
Modelo conceptual de los datos en UML 26
Informacin derivada
Atributo derivado
Asociacin derivada
Un elemento (atributo o asociacin) es derivado si se puede calcular a partir de otroselementos.Se incluye cuando mejora la claridad del modelo conceptual.Una constraint (regla de derivacin) ha de especificar cmo se deriva.
DepartamentoEmpleado
Tienenombre/nm_empleados
* *
CiudadEst situado enDepartamento
Empleado
1*
Tiene /Trabaja en
1
*
1
*
El nmero de empleados de un departamento d es igualal nmero de ocurrencias de Tiene donde aparece d.
La ciudad donde trabaja un empleadoes la ciudad donde est situado su
departamento.
51
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 27
La multiplicidad de clase establece el rango de posibles cardinalidades paralas instancias de una clase.
Por defecto, es indefinida.
En algunos casos es til establecer una multiplicidad finita, especialmente encasos de clases que pueden tener una sola instancia (y que se denominansingleton).
Multiplicidad de clase
La Puntual, S.A.
NIFdireccin
1
- multiplicidad de clase
Modelo conceptual de los datos en UML 28
Otras restricciones sobre asociaciones
XorUne diversas asociaciones ligadas a una misma clase bsica.Una instancia de la clase bsica puede participar como mximo en una de lasasociaciones unidas por xor.
SubsetIndica que una asociacin es un subconjunto de otra asociacin
A parte de la multiplicidad, es posible expresar otras restricciones sobre las asociaciones:- Xor- Subset
Persona
Cuenta
Empresa
{xor}
*
*
*
1
cuenta per
cuenta emp
persona propietaria
empresa propietaria
Comisin
Pertenece a
Persona**
Preside1 *
{subset}
52
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 29
La cambiabilidad indica si los valores de un atributo o el extremo de unaasociacin pueden cambiar o no.
Cambiabilidad
Cambiable (changeable) - opcin por defecto -
Congelado (frozen)
telfono y ciudad-res son cambiables
fecha-nac y ciudad-nac son congelados
Slo-aadir (addOnly)
ttulo-aca y ciudad-res son slo-aadir
PersonaCiudad
Vive en
ciudad-res{changeable}
residentetelfono {changeable}**
CiudadNaci en
ciudad-nac{frozen}
per-nacida* 1Persona
fecha-nac {frozen}
CiudadHa residido en
ciudad-res{addOnly}
residente* *Persona
ttulo-aca {addOnly}
Modelo conceptual de los datos en UML 30
Generalizacin/Especializacin - Ejemplos discriminador
num-pagotipo-pagoimporte
Pago
tipo-pago{disj., inc.}
num-pagoimporte
Efectivo Tarjeta
Pago
cambio num-tarjeta
tipo-pago{disj., inc.}
nombre-empleadosueldo/dept
Direccin Produccin
Empleado
matr-coche precio-hora-ext
/dept{disj., inc.}
nombre-dept: Tdept
DepartamentoTrabaja en
* 1
Efectivocambio
Tarjetanum-tarjeta
/dept de un empleado es el nombre-dept deldepartamento donde trabaja el empleado.
Tdept es una enumeracin de Direccin, Produccin yAdministracin.
53
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 31
Clasificacin mltiple
Persona
Hombre Mujer
Variante de generalizacin/especializacin en la cual una superclase puede tenerdiversas jerarquas de especializacin en funcin de diferentes discriminadores.
sexo
{disjoint, complete}
Soltera Casada Divorc. Viuda
estado
{disjoint, complete}
Modelo conceptual de los datos en UML 32
Herencia mltiple
Estudiante
EstUPC EstUAB
Variante de generalizacin/especializacin en la cual una subclase tienems de una superclase.
EstUB Inform. Mates Empres.
InformUPC
estudios{disjoint, incomplete}
universidad{disjoint, incomplete}
Slo se puede utilizar si no hay conflictos de herencia.
Conflicto de herencia: Una clase tiene ms de una superclase con unmismo atributo/asociacin/(operacin) que no proviene de un nicoantecesor.
{incomplete} {incomplete}
54
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 33
Equivalencias notacionales (I)
Polgononmero_lados
Tringulo Rectngulo Pentgono . . .
Polgono
Tringulo Rectngulo Pentgono . . .
En UML:
es equivalente a:
Problema?
Modelo conceptual de los datos en UML 34
Equivalencias notacionales (II)
En UML:
es equivalente a:
Clase_Teora*
Docencia_Asignatura
*Clase_Probl Clase_Lab
*
1 1 1
Clase_Teora*
Docencia_Asignatura
*Clase_Probl Clase_Lab
*
1
55
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 35
Ejemplos (I) Qu solucin es mejor?
Persona_UPCnombrenum-asignaturas [0..1]sueldo [0..1] con valores nulos
nombre
Estudiante Empleado
Persona_UPC
num-asignaturas sueldo
sin valores nulos
tipo {overlapping, incomplete}
Modelo conceptual de los datos en UML 36
Ejemplos (II) Qu solucin es mejor?
Persona_UPCnombretelfono [0..1]
con valores nulos
nombre
Persona_con_telfono
Persona_UPC
sin valores nulos
telfono
tener_telfono
56
Los autores, 2003; Edicions UPC, 2003
-
Modelo conceptual de los datos en UML 37
Ejemplos (III)
Un atributo no puede tomar valores de una de las clases del modelo conceptual.
Este caso es una asociacin.
Empleadonombre: Textoproy_emp: Proyecto
Proyectocod_proy: Textodescripcin: Texto
Empleadonombre: Texto
Proyectocod_proy: Textodescripcin: Texto
**
Trabaja en
Modelo conceptual de los datos en UML 38
Bibliografa
Booch, G.; Rumbaugh, J.; Jacobson, I.The Unified Modeling Language User GuideAddison-Wesley, 1999
Rumbaugh, J.; Jacobson, I.; Booch, G.The Unified Modeling Language Reference ManualAddison-Wesley, 1999
Larman, C.Applying UML and PatternsAn Introduction to Object-Oriented Analysis and Design andthe Unified Process (second edition)Prentice-Hall 2002Cap. 10, 11, 12, 26 y 27
57
Los autores, 2003; Edicions UPC, 2003
-
Object Constraint Language (OCL) 1
Object Constraint Language (OCL)
Para qu sirve? Propiedades del modelo conceptual Colecciones: conjuntos, bolsas y secuencias Navegacin para clases asociativas Generalizacin / Especializacin Cmo especificar en OCL
Object Constraint Language (OCL) 2
Para qu sirve OCL?
Los modelos grficos no son suficientes para una especificacin precisa yno ambigua.
OCL: Es un lenguaje formal. Es un lenguaje de navegacin que permite definir expresiones (o sea, no tiene
efectos laterales). No es un lenguaje de programacin, sino de especificacin. Es un lenguaje tipificado.
Se usa para: Especificar invariantes (restricciones y reglas de derivacin) del modelo
conceptual. Especificar precondiciones, postcondiciones y salidas de las operaciones.
58
Los autores, 2003; Edicions UPC, 2003
-
Object Constraint Language (OCL) 3
Ejemplo
Persona
fechaNacimiento: Fechanombre: Stringapellido: Stringsexo: SexoVlido/estCasado: Boolean/estParado: Boolean/edad: Integer
esposa
esposo 0..1
0..1
director
empleado
empresasDirigidas
contratador
Empresa
nombre: String/nmEmpleados: Integer
* 1..*
*
Matrimonio
l gar : Stringfecha: Fecha
Trabajo
tt lo: StringfechaInicio: Fechasalario: Integer
1
SexoVlido se define como en meracin de Hombre y M jer.
Object Constraint Language (OCL) 4
Propiedades de los objetos
Cada expresin OCL: se escribe en el contexto de una instancia de un tipo determinado. define una propiedad de esta instancia.
Una propiedad puede hacer referencia a: atributos de una clase de objetos. navegacin a travs de las asociaciones.
Propiedades de los atributos de una clase de objetos: Propiedad: edad de una persona -- entero
context Persona invla expresin ha de ser cierta para todaslas instancias de la clase
self.edadinstancia contextual de la expresin (punto de partida)
Restriccin de la propiedad: la edad de las personas ha de ser superior o igual acero
context Persona inv o, alternativamente: context p:Persona invself.edat >= 0 p.edat >= 0
59
Los autores, 2003; Edicions UPC, 2003
-
Object Constraint Language (OCL) 5
Propiedades de los objetos (II)Propiedades de una navegacin a travs de asociaciones:
Partiendo de un objeto concreto, podemos navegar a travs de las asociacionesdel modelo conceptual para referirnos a otros objetos y a sus propiedades.
Cmo se navega? Objeto.nombre-de-rol
objeto de partida nombre de rol de una asociacin del objeto
Resultado: conjunto de objetos del otro extremo de nombre-de-rol
Si no hay nombre de rol especificado, se puede usar el nombre de la clase de objetos delotro extremo de la asociacin (con minsculas).
Ejemplos de navegacin:context Empresa inv
self.director -- director de la empresa -- Personaself.director.nombre -- nombre del director -- Stringself.empleado -- empleados de la empresa -- set(Persona)self.empleado.esposo -- esposos de los empleados -- set(Persona)
Object Constraint Language (OCL) 6
Colecciones: conjuntos, bolsas y secuencias
Una coleccin de elementos puede ser del tipo: Conjunto: cada elemento aparece una nica vez en la coleccin. Bolsa (multiconjunto): la coleccin puede contener elementos repetidos. Secuencia: bolsa donde los elementos estn ordenados.
Ejemplo: nmero de trabajadores diferentes que trabajan para una persona
context Persona invnum-trab = self.empresasDirigidas.empleado -> size()Incorrecto: el resultado es una bolsa y puede contener repetidos.context Persona inv num-trab = self.empresasDirigidas.empleado -> asSet() -> size()
Reglas de navegacin: Si la multiplicidad de la asociacin es 1, el resultado es un objeto (o un conjunto de un
nico objeto). Si la multiplicidad de la asociacin es >1, el resultado es un conjunto. Si se navega por ms de una asociacin y la multiplicidad de alguna de ellas es >1, el
resultado es una bolsa, aunque a veces puede ser un conjunto.
60
Los autores, 2003; Edicions UPC, 2003
-
Object Constraint Language (OCL) 7
Operaciones bsicas sobre colecciones (I)
Select: Especifica un subconjunto de la coleccin. personas mayores de 50 aos que trabajan en una empresa
context Empresa invself.empleado -> select(edad>50)
context Empresa invself.empleado -> select(p | p.edad>50)
context Empresa invself.empleado -> select(p:Persona | p.edad>50)
Collect: Especifica una coleccin que se deriva de otra, pero que contieneobjetos diferentes.
edades (con repetidos) de los empleados de una empresa
context Empresa invself.empleado -> collect(fechaNacimiento)
versin simplificada: self.empleado.fechaNacimiento
Object Constraint Language (OCL) 8
Operaciones bsicas sobre colecciones (II)
forAll: Expresin que han de satisfacer todos los elementos. todos los empleados de la empresa se llaman Jack
context Empresa invself.empleado -> forAll(nombre=Jack)
la clave externa de Empresa es su nombrecontext Empresa inv
Empresa.allInstances -> forAll(e1,e2 | e1 e2 implies e1.nombree2.nombre)
Exists: Condicin que satisface al menos un elemento. como mnimo un empleado de la empresa se ha de llamar Jack
context Empresa invself.empleado -> exists(nombre=Jack)
IsUnique: Devuelve cierto si la expresin se evala a un valor diferentepara cada elemento de la coleccin.
la clave externa de Empresa es su nombrecontext Empresa inv
Empresa.allInstances -> isUnique(nombre)
61
Los autores, 2003; Edicions UPC, 2003
-
Object Constraint Language (OCL) 9
Combinacin de propiedades Las propiedades se pueden combinar para formar expresiones ms
complejas. Las personas casadas han de ser mayores de edad
context Persona invself.esposa -> notEmpty() implies self.esposa.edad >= 18and self.esposo -> notEmpty() implies self.esposo.edad >= 18
Una empresa tiene como mximo 50 empleadoscontext Empresa inv
self.empleado -> size() size()=1) and (self.esposo -> size()=1)
Definicin del atributo derivado numEmpleadoscontext Empresa inv
numEmpleados = (self.empleado -> size())
Definicin del atributo derivado estParadocontext Persona inv
estParado = if self.contratador-> isEmpty() then true else false
Object Constraint Language (OCL) 10
Navegacin por clases asociativas
Navegacin a una clase asociativa:Se utiliza el nombre de la clase asociativa (en minscula).
Los sueldos de las personas que trabajan en la UPC han de ser ms altos que1000
context Persona inv(self.contratador -> select(nombre=UPC)).trabajo)
-> forAll (t | t.salario > 1000)
Navegacin desde una clase asociativa:Se usa el nombre de rol del extremo hacia donde se quiere navegar.Si no se ha especificado nombre de rol, se usa el nombre de la clase.
Las personas que trabajan no pueden estar paradascontext Trabajo inv
self.empleado.estParado = false Un matrimonio ha de ser entre una mujer y un hombre
context Matrimonio invself.esposa.sexo = #mujer and self.esposo.sexo = #hombre
62
Los autores, 2003; Edicions UPC, 2003
-
Object Constraint Language (OCL) 11
Generalizacin - Especializacin (herencia)
Navegacin:
Acceso directo a las propiedades de la superclasecontext Ingreso inv self.cuentaCorriente.num-cc -- nmero de cuenta de un ingreso
Acceso a las propiedades definidas en el nivel de subclasecontext CuentaCorriente inv
self.transaccin.oclAsType(Extraccin).persona -> asSet() -- personas que han extrado dinero deuna cuenta corriente
Aspectos adicionales:
Seleccin de objetos que pertenecen a la subclase.context CuentaCorriente inv
self.transaccin -> select(oclIsTypeOf=Ingreso) -- ingresos de una cuenta
Las propiedades de las subclases se pueden ignorar.context CuentaCorriente inv self.transaccin -> select(fecha.isafter(5-4-1998)) -- transacciones de una cuenta posteriores al 5-4-1998
Transaccinfecha: Datecantidad: Integer
Extraccinpersona: String
Ingresoc-oficina: Integer
CuentaCorrientenum-cc: Integerentidad: String
efecta1 *
{disjoint, complete}
Object Constraint Language (OCL) 12
Cmo especificar en OCL
Una expresin OCL se especifica siempre comenzando en una clase deobjetos determinada: instancia contextual .
Una expresin se puede especificar de diversas maneras, segn la instanciacontextual de partida.
Los dos miembros de un matrimonio no pueden trabajar en la misma empresacontext Empresa inv
self.empleado.esposa -> intersection(self.empleado) -> isEmpty()context Persona inv
self.esposa.contratador -> intersection(self.contratador) -> isEmpty()
Indicaciones para escoger la instancia contextual Si la restriccin restringe el valor del atributo de una clase, sta es la clase
candidata. Si la restriccin restringe el valor de los atributos de ms de una clase,
cualquiera de stas es la candidata. Normalmente, cualquier restriccin debera navegar a travs del menor nmero
posible de asociaciones.
63
Los autores, 2003; Edicions UPC, 2003
-
Object Constraint Language (OCL) 13
Cmo especificar en OCL: Ejemplos El esposo y la esposa de un matrimonio han de ser mayores de edad
context Matrimonio invself.esposa.edad >= 18 and self.esposo.edad >= 18 -- es preferible a
context Persona invself.esposa -> notEmpty() implies self.esposa.edad >= 18 andself.esposo -> notEmpty() implies self.esposo.edad >= 18
Todas las personas han de ser mayores de edadcontext Persona inv
self.edad >= 18 -- es preferible a
context Empresa invself.empleado -> forAll (edad >= 18)
Nadie puede ser director y empleado de una empresacontext Empresa inv
not(self.empleado -> includes(self.director))
context Persona invnot(self.empresasDirigidas.empleado -> includes(self))
-- cul es preferible en este caso?
Object Constraint Language (OCL) 14
Operaciones estndar de tipo booleano
Operacin Notacin Resultado
or a or b booleanand a and b booleanor exclusivo a xor b booleannegacin not a booleanigualdad a = b booleandesigualdad a b booleanimplicacin a implies b booleanif-then-else if a then b else b tipo de b b
64
Los autores, 2003; Edicions UPC, 2003
-
Object Constraint Language (OCL) 15
Operaciones estndar de tipo string
Operacin Notacin Resultado
concatenacin string.concat(string) stringtamao string.size() integersubstring string.substring(int,int) stringigualdad string1 = string2 booleandesigualdad string1 string2 boolean
Operaciones estndar de una clase de objetos
Operacin Resultado
allInstances Retorna el conjunto de todos los elementos de la clase de objetos
Object Constraint Language (OCL) 16
Operaciones estndar de tipo coleccin
Operacin Resultado
size() Nmero de elementos de la coleccincount(object) Nmero de ocurrencias del objetoincludes(object) Cierto si el objeto pertenece a la coleccinincludesAll(collection) Cierto si los elementos del parmetro collection estn en la
coleccin actualexcludes(object) Cierto si el objeto no pertenece a la coleccinexcludesAll(collection) Cierto si los elementos del parmetro collection no estn en la
coleccin actualisEmpty() Cierto si la coleccin est vacanotEmpty() Cierto si la coleccin no est vacasum() suma de todos los elementos (los elementos se han de poder
sumar)exists(expression) expression es cierta para algn elemento?forAll(expression) expression es cierta para todos los elementos?isUnique(expression) Cierto si expression evala a un valor diferente para cada
elemento de la coleccin actual
65
Los autores, 2003; Edicions UPC, 2003
-
Object Constraint Language (OCL) 17
Operaciones estndar (especficas) de tipo conjunto
Operacin Resultado
select(expression) Selecciona el subconjunto de elementos del conjunto actual paralos cuales expression es cierta
reject(expression) Elimina el subconjunto de elementos del conjunto actual para loscuales expression es cierta
union(set) Resultado de unir los dos conjuntosintersection(set) Resultado de la interseccin de los dos conjuntosunion(bag) Resultado de unir el conjunto actual con la bagintersection(bag) Resultado de la interseccin del conjunto actual con la bag
Object Constraint Language (OCL) 18
Bibliografa
OMG - Unified Modeling LanguageObject Constraint Language Specification, v. 1.4.Septiembre 2001.
Warmer, J.; Kleppe, A.The Object Constraint Language: precise modeling with UMLAddison-Wesley, 1999.
Pginas web con informacin de OCL:
http://www.omg.org http://www.software.ibm.com/ad/ocl http://www.rational.com
66
Los autores, 2003; Edicions UPC, 2003
-
Modelo de casos de uso en UML 1
Propsito
Casos de uso
Diagrama de casos de uso
Especificacin de casos de uso
Estructuracin de casos de uso
Identificacin de casos de uso
Modelo de casos de uso en UML
Modelo de casos de uso en UML 2
Modelo de anlisis (especificacin)
Casos de uso- nivel alto- esencial
Diagramas decasos de uso
Diagramasestticos deestructura de objetosdel dominio
Diagramas desecuenciadel sistema
Diagramasde estado deobjetos ycasos de uso
Modelo decasos de uso
Modelo delcomportamientodel sistema
Modelo de losestados
Contratospara lasoperacionesdel sistema
Modelo conceptual delos datos
Modelode Anlisis
67
Los autores, 2003; Edicions UPC, 2003
-
Modelo de casos de uso en UML 3
Determinacin de requisitos de un sistema software:
Identificar y categorizar las funciones del sistema (requisitos funcionales). Identificar y categorizar los atributos del sistema (requisitos no funcionales). Relacionar los requisitos no funcionales con los funcionales.
Especificacin de los requisitos de un sistema software:
Comprensin de los requisitos. Organizar los requisitos segn las funciones del sistema. Delimitar la frontera del sistema.
Modelo de casos de uso: Cules son las funciones del sistema PARA CADA ACTOR?nfasis: USOS del sistema, valor aadido para cada actor.
Modelo de casos de uso en UML 4
Casos de usoCaso de uso: Documento que describe una secuencia de eventos que
realiza un actor (agente externo) que usa el sistema para llevar a cabo un proceso que tiene algn valor para el [Jacobson 92].
Extraccin dedinero del
cajero
Actor: - Entidad externa al sistema que participa en la secuencia deeventos del caso de uso.
- Puede ser una persona, un conjunto de personas, un sistemahardware, un sistema software o un reloj.Iniciador: Genera el estmulo que provoca la ejecucin del proceso (nico).Participante: Interviene en el proceso.
68
Los autores, 2003; Edicions UPC, 2003
-
Modelo de casos de uso en UML 5
Caso de uso 1
ActornActor1
Nombre del sistema
Caso de uso 2
Caso de uso i
Entorno del sistema
Comunicacin
Diagrama de casos de uso
Muestra conjuntamente los diferentes casos de uso de un sistemasoftware, los actores y las relaciones entre actores y casos de uso.
Modelo de casos de uso en UML 6
Especificacin de casos de uso
De alto nivel: Descripcin breve de las acciones del caso de uso.
Caso de uso: Nombre del caso de usoActores: Lista de actores, iniciadorPropsito: Objetivo del caso de usoResumen: Descripcin breve de las actividades que se han de realizarTipo: 1 - primario, secundario, opcional
2 - real o esencial
Expandida: Descripcin detallada de las acciones y los requisitosAade a la especificacin de alto nivel:
Referencias cruzadas: Requisitos a los que hace referenciaCurso tpico de eventos: Descripcin detallada de la interaccin
(conversacin) entre los actores y el sistemaDescripcin de los eventos paso a paso
Cursos alternativos: Describe excepciones al curso tpico
69
Los autores, 2003; Edicions UPC, 2003
-
Modelo de casos de uso en UML 7
Ejemplo: Terminal de punto de venta
Un terminal de punto de venta (TPV) es un sistema computerizado usadao para registrarlas ventas y gestionar pagos. Se usa principalmente en supermercados y grandesalmacenes. Incluye componentes hardware (como el ordenador y el escner del cdigo de barras) y software para ejecutar el sistema.Se nos pide que especifiquemos el software de este sistema.
Modelo de casos de uso en UML 8
Ref # Funcin CategoraR1.1 Registrar la venta actual - los productos comprados. evidentR1.2 Calcular el total de la venta actual, incluyendo impuestos y clculo de evident
puntos de cliente.R1.3 Capturar la informacin de los productos comprados de un cdigo de evident
barras, usando un escner o bien a partir de la entrada manual delcdigo de barras (Universal Product Code).
R1.4 Descontar las cantidades vendidas del stock, cuando se confirme. hiddenR1.5 Guardar informacin sobre les ventas realizadas. hiddenR1.6 El cajero ha de identificarse al iniciar una sesin con un identificador evident
y una clave de acceso.R1.7 Mostrar la descripcin y el precio de cada producto comprado. evidentR2.1 Tratar los pagos en efectivo capturando la cantidad entregada evident
por el cliente y calculando el cambio.R2.2 Tratar los pagos con tarjeta de crdito capturando el nmero de la evident
tarjeta desde un lector de tarjetas o manualmente, pedir confirmacindel pago al servicio de autorizacin de crdito (externo) con unaconexin va mdem.
R2.3 Registrar los pagos con tarjeta con tal que puedan ser facturados. hidden
Ejemplo TPV: Funciones bsicas
70
Los autores, 2003; Edicions UPC, 2003
-
Modelo de casos de uso en UML 9
Ejemplo TPV: Diagrama de casos de uso
Terminal Punto de Venta
Directorcomercial
Cajero
Responsablede compras
Iniciar sesin
Compra de productos
Acabar sesin
Fijar pPrecio
Comprar a proveedores
Hacer ofertas
Devolver producto
Proveedor
Cliente
Modelo de casos de uso en UML 10
Ejemplo TPV: Entorno del sistema
Compra deproductos
CLIENTECAJERO Devolverproducto
Iniciarsesin
supermercado tradicional
Compra deproductos
CLIENTEDevolverProducto
supermercado electrnico
71
Los autores, 2003; Edicions UPC, 2003
-
Modelo de casos de uso en UML 11
Caso de uso: Compra de productos en efectivo.Actores: Cliente (iniciador), Cajero.Propsito: Capturar una venta y su pago en efectivo.Resumen: Un cliente llega a la caja con productos para comprar.
El cajero registra los productos y gestiona el pago en efectivo.Al acabar, el cliente se va con los productos.
Tipo: Primario y esencial.Referencias cruzadas: R1.1, R1.2, R1,3, R1.7, R2.1
Curso tpico de eventos
Acciones de los actores
1. El caso de uso comienza cuando un Cliente llega a la caja con los productos para comprar.2. El Cajero indica que comienza una nueva venta4. El Cajero registra el identificador de cada producto. Si hay ms de una unidad del producto el Cajero puede introducir la cantidad.6. Al acabar la entrada de productos el Cajero lo indica.
Respuesta del sistema
3. Registra el inicio de una nueva venta.5. Determina el precio del producto y aade su informacin a la cuenta.
7. Calcula y muestra el total de la cuenta.
Ejemplo TPV: Especificacin del caso de uso compra de productos en efectivo
(contina)
Modelo de casos de uso en UML 12
Cursos Alternativos
Lnea 4: Se introduce un identificador de producto inexistente. Indicar error. Lnea 9: El Cliente no tiene suficiente dinero. Cancela la venta.
Acciones de los actores
8. El Cajero dice el total al cliente. 9. El Cliente entrega una cantidad de dinero posiblemente ms grande que el total de la cuenta.10. El Cajero indica el dinero que ha recibido.13. El Cajero deposita el dinero recibido en la caja y extrae el cambio. El Cajero da el cambio y el recibo al Cliente.14. El Cliente se va con los productos comprados.
Respuesta del sistema
11. Calcula y muestra el cambio al Cliente. Imprime un recibo.12. Registra la venta que se acaba de hacer.
72
Los autores, 2003; Edicions UPC, 2003
-
Modelo de casos de uso en UML 13
Casos de uso esenciales vs casos de uso reales
Esencial (muy abstracto)Independiente interfaces y tecnologa
Real(muy concreto)
Esencial
Accin del actor Respuesta del sistema1. El cliente se identifica. 2. El sistema valida la identificacin.3. Etc... 4. Etc...
Real
Accin del actor Respuesta del sistema1. El cliente inserta la tarjeta. 2. Solicita el PIN.3. Teclea el PIN por teclado. 4. Muestra el men de opciones.5. Etc... 6. Etc...
Modelo de casos de uso en UML 14
Curso tpico de eventos Acciones de los actores
1. El caso de uso comienza cuando un Cliente llega a la caja con los productos para comprar.2. (pasos intermedios excluidos)...9. El Cliente escoge la forma de pago: a. If en efectivo, see section pagar en efectivo. b. If con tarjeta see section pagar con tarjeta.
12. El Cajero da el recibo al cliente.13. El Cliente se va con los productos comprados.
Estructuracin de casos de uso: Secciones
Respuesta del sistema
10. Registra la venta que se acaba de hacer.11. Imprime un recibo.
Caso de uso: Compra de productosPropsito: Capturar una venta y su pago en efectivo o con tarjeta.
73
Los autores, 2003; Edicions UPC, 2003
-
Modelo de casos de uso en UML 15
Section: Pagar en efectivo
Curso tpico de eventos
Acciones de los actores
1. El Cliente entrega una cantidad de dinero posiblemente ms grande que el total de la cuenta.2. El Cajero indica el dinero que ha recibido.4. El Cajero deposita el dinero recibido y extrae el cambio. El Cajero da el cambio al Cliente.
Estructuracin de casos de uso: Secciones
Respuesta del sistema
3. Calcula y muestra el cambio al Cliente.
Cursos alternativos
Lnea 4: Efectivo insuficiente para devolver el cambio. Pedir cambio a otra persona.
Section: Pagar con tarjeta
Cursos tpicos y alternativos para la historia del pago con tarjeta.
Modelo de casos de uso en UML 16
Estructuracin de casos de uso: Relacin
: Relacin de un caso de uso concreto con uno abstracto en la cual la conducta definida por el caso concreto incluye (usa) la conducta definida en el abstracto.
Permite reducir la redundancia cuando una secuencia de acciones est compartida pordiversos casos de uso.
Pagar con tarjetaCompra de productosCajero
Cliente
caso de uso que se efecta realmente
Cajero Cliente
Compra de productos + Pagar con tarjeta
74
Los autores, 2003; Edicions UPC, 2003
-
Modelo de casos de uso en UML 17
Ejemplo TPV:
Comprarproductos
Pagar enefectivo
Pagar contarjeta
Devolver producto
Cajero Cliente
Contabilidad
Servicio de autorizacinde crdito
Acciones de los actores
1. El caso de uso comienza cuando un cliente llega a la caja con los productos para comprar. 2. (Pasos intermedios excluidos)... 9. El Cliente escoge el tipo de pago: a. If en efectivo include
Pagar en efectivo. b. If con tarjeta include
Pagar con tarjeta.
12. El Cajero da el recibo al cliente.13. El Cliente se va con los productos comprados
Respuesta del sistema
10. Registra la venta que se acaba de hacer.
11. Imprime un recibo.
Modelo de casos de uso en UML 18
Identificacin de casos de uso
Mtodo basado en los actores
1. Identificar los actores relativos al sistema.2. Para cada actor, identificar los procesos que inicia
o en los cuales participa.
Mtodo basado en los eventos
1. Identificar los eventos externos a los que el sistema ha de responder.
2. Relacionar los eventos con los actores y casos de uso.
75
Los autores, 2003; Edicions UPC, 2003
-
Modelo de casos de uso en UML 19
Bibliografa
Larman, C.Applying UML and Patterns: An Introduction to Object-Oriented Analysisand Design and the Unified Process (second edition)Prentice-Hall, 2002. (Cap. 6, 9, 25)
Cockburn, A.Writing Effective Use CasesAddison-Wesley, 2001.
Jacobson, I.; Booch, G.; Rumbaugh, J.The Unified Software Development ProcessAddison-Wesley, 1999. (Cap. 6,7)
76
Los autores, 2003; Edicions UPC, 2003
-
Modelo del comportamiento en UML 1
Modelo del comportamiento en UML
Introduccin Diagramas de secuencia del sistema Contratos de las operaciones del sistema Otras consideraciones
Comparticin de informacin entre las operaciones de un diagrama Informacin elemental vs informacin compuesta Nmero de eventos del diagrama de secuencia Redundancia entre los modelos
Bibliografa
Modelo del comportamiento en UML 2
Modelo de anlisis (especificacin)
Casos de uso- nivel alto- esencial
Diagramas decasos de uso
Diagramasestticos de estructura de objetosdel dominio
Diagramas desecuenciadel sistema
Diagramasde estado deobjetos ycasos de uso
Modelo decasos de uso
Modelo delcomportamientodel sistema
Modelo de losestados
Contratospara lasoperacionesdel sistema
Modelo conceptual delos datos
Modelode anlisis
77
Los autores, 2003; Edicions UPC, 2003
-
Modelo del comportamiento en UML 3
Descripcin del comportamiento en OO
Los objetos se comunican mediante la invocacin de operacionesde otros objetos
Modelo del comportamiento en UML 4
Especificacin del comportamiento en OO
SISTEMA
Consideramos un tipo especial sistema que engloba a todos los objetos. La especificacin del comportamiento se hace con el modelo delcomportamiento del sistema.
78
Los autores, 2003; Edicions UPC, 2003
-
Modelo del comportamiento en UML 5
Modelo del comportamiento del sistema
Diagramas de secuencia del sistema:
Muestran la secuencia de eventos entre los actores y el sistema. Permiten identificar las operaciones del sistema.
Contratos para las operaciones del sistema:
Describen el efecto de las operaciones del sistema.
Modelo del comportamiento en UML 6
Diagramas de secuencia del sistema
Objetivos: Identificar los eventos y las operaciones del sistema.
Punto de partida: Casos de uso. La descripcin de los diagramas de secuencia del sistema es posterior a la descripcin
de los casos de uso. Casos de uso:
Describen cmo los actores interactan con el sistema software. El actor genera eventos hacia el sistema que exigen la ejecucin de alguna operacin
como respuesta (durante la interaccin). A partir de los casos de uso podemos identificar cules son los eventos que van de los
actores hacia el sistema.
Diagramas de secuencia del sistema
79
Los autores, 2003; Edicions UPC, 2003
-
Modelo del comportamiento en UML 7
Diagramas de secuencia del sistema
Muestra para un escenario particular de un caso de uso: los eventos generados por los actores externos su orden los eventos internos del sistema (operaciones) que resultan de la
invocacin
Definiremos un diagrama de secuencia para cada cursorelevante de eventos de un caso de uso.
Modelo del comportamiento en UML 8
Ejemplo: Comprar producto
:Cajero :Sistema
inicioVenta(pv)
*:venta
entrarProd(venta,prod,cant)
finVenta(venta)
:importe
pago(venta,importePago)
:cambio
sistema como caja negraactor
evento del sistemainvoca operacin
80
Los autores, 2003; Edicions UPC, 2003
-
Modelo del comportamiento en UML 9
Construccin de un diagrama de secuencia
1. Dibujar una lnea vertical que representa el sistema.2. Dibujar una lnea para cada actor que interacta directamente
con el sistema.3. Del curso de eventos del caso de uso, identificar los eventos
externos generados por los actores. Mostrarlos en el diagrama.
Modelo del comportamiento en UML 10
Representacin de iteraciones de eventos
:Actor :Sistema
evento1()
evento2()
evento3()
evento4()
*
*iteracin de unasecuencia de event s
iteracin de unnic event
81
Los autores, 2003; Edicions UPC, 2003
-
Modelo del comportamiento en UML 11
Diagramas de secuencia:
:Cajero :Sistema
inicioVenta(pv)
*:venta
entrarProd(venta,prod,cant)
finVenta(venta):importe
Los casos de uso definidos mediante requieren un diagrama desecuencia para la parte comn y uno para cada caso de uso que es incluido.
Ejemplo: caso de uso comprar productos
pagar contarjeta o en efectivo
Parte especfica: pagar con tarjeta
:Cajero :SistemapagTarjetaCrdito(nm-t,fecha-cad)
:Sist. Autor. Crdito
solicitudAprob(nm-t)
:Gestin Tarjetas
aadeAprobacin(respuesta)tratarRespTarjeta(respuesta)
Modelo del comportamiento en UML 12
Eventos y operaciones
Evento del sistema: Evento externo generado por un actor Operacin del sistema: Operacin interna que se ejecuta como
respuesta a la comunicacin del evento
La comunicacin de un evento del sistema provoca la ejecucin deuna operacin del sistema con el mismo nombre y los mismosparmetros.
82
Los autores, 2003; Edicions UPC, 2003
-
Modelo del comportamiento en UML 13
Operaciones del sistema Las operaciones del sistema se agrupan como operaciones del tipo
especial sistema. En cambio, las operaciones no se asignan a objetos concretos
durante la etapa de especificacin.
Ejemplo:
inicioVenta(pv) :venta
entrarProd(venta,prod,cant)
finVenta(venta) :importe
pago(venta,importePago): cambio
SISTEMA
Modelo del comportamiento en UML 14
Eventos y el lmite del sistema
Para identificar los eventos del sistema es necesario haberdelimitado claramente la frontera del sistema.
Los eventos del sistema son los que estimulan directamente elsistema.
Ejemplo::Cajero :Sistema
inicioVenta
* entrarProd
finVenta
pago
frontera delsistema
El actor cliente no interacta directamente con el sistema,slo lo hace el cajero.
83
Los autores, 2003; Edicions UPC, 2003
-
Modelo del comportamiento en UML 15
Contratos de las operaciones
Contrato de una operacinDescribe el comportamiento del sistema en trminos de: cules son los cambios de estado de la base de informacin cules son las salidas que el sistema proporcionacuando se invoca la operacin.
El tipo de descripcin es declarativo: El nfasis se pone en qu har la operacin ms que en cmo lo har.
Los contratos de las operaciones incluyen primordialmente: precondiciones y postcondiciones que describen los cambios de estado salidas
Modelo del comportamiento en UML 16
Contratos de las operaciones: ComponentesNombre: Nombre y argumentos de la operacin (cabecera de la operacin) Responsabilidades: Descripcin informal del propsito de la operacin Excepciones: Descripcin de la reaccin del sistema a situaciones excepcionales Precondiciones: Suposiciones sobre el estado del sistema antes de la invocacin de la operacin Postcondiciones: Cambios de estado que se han producido:
- altas/bajas de instancias de clases de objetos- altas/bajas de instancias de asociaciones- modificacin de atributos- generalizacin de un objeto- especializacin de un objeto- cambio de subclase de un objeto
Salida: Descripcin de la salida que proporciona la operacin en pseudo-OCL
Observad el vnculo que existe entre los contratos de lasoperaciones y el esquema conceptual.
84
Los autores, 2003; Edicions UPC, 2003
-
Modelo del comportamiento en UML 17
Ejemplo: Esquema conceptual de partida
RI textuales:1- La clave externa de PuntoDeVenta es num-pv.2- La clave externa de Producto es cdigo.3- Un punto de venta no puede tener ms de una venta con el mismo da y hora.
Productocdigopreciodescripcin
LneaDeVentacantidad
PuntoDeVentanum-pv
Ventadahora/importe
1 1..*
1
1*
tiene*
consta de
corresponde a
Modelo del comportamiento en UML 18
Ejemplo: Operacin inicioVenta
Nombre: inicioVenta(pv) :venta
Responsabilidades: Iniciar el registro de una venta. Excepciones: Si no existe ningn PuntoDeVenta con num-pv=pv, indicar error. Precondiciones: Existe un PuntoDeVenta con num-pv=pv. Postcondiciones:
- Alta de una instancia V de Venta con el da y la hora actuales.- Alta de una instancia de la asociacin tiene que asocia la venta V y lainstancia de PuntoDeVenta con num-pv=pv.
Salida: V
85
Los autores, 2003; Edicions UPC, 2003
-
Modelo del comportamiento en UML 19
Ejemplo: Operacin entrarProd
Nombre: entrarProd(venta,prod,cant)
Responsabilidades: Registrar una lnea de una venta. Excepciones: Si no existe ningn Producto con cdigo=prod, indicar error. Precondiciones: Existe un Producto con cdigo=prod. Postcondiciones:
- Alta de una instancia de LneaDeVenta L con cantidad=cant.- Alta de una instancia de la asociacin consta de que asocia L y venta.- Alta de una instancia de la asociacin corresponde a que asocia L y elProducto con cdigo=prod.
Salida:
Modelo del comportamiento en UML 20
Ejemplo: Operacin finVenta
Nombre: finVenta(venta) :importe
Responsabilidades: Finalizar el registro de una venta y mostrar el importe a pagar. Excepciones:
Precondiciones:
Postcondiciones:
Salida: importe = venta.importe
86
Los autores, 2003; Edicions UPC, 2003
-
Modelo del comportamiento en UML 21
Ejemplo: Operacin pago
Nombre: pago(venta,importePago): cambio
Responsabilidades: Mostrar el cambio a devolver. Excepciones: Si importePago < venta.importe indicar error. Precondiciones: importePago venta.importe. Postcondiciones:
Sortida: cambio = importePago - venta.importe
Modelo del comportamiento en UML 22
Comparticin de informacin entre las operaciones de un diagrama
Mediante argumentosadicionales de las operaciones
Mediante informacin adicional enel esquema conceptual
:Cajero :Sistema
inicioVenta(pv)
*:venta
entrarProd(venta,prod,cant)
finVenta(venta)
:importe
pago(venta,importePago)
:cambio
:Caixer :Sistema
inicioVenta(pv)
* entrarProd(pv, prod,cant)
finVenta(pv):importe
pago(pv,importePago):cambio
Ventadahora/importe
VentaEnCurso
UML no precisa de qu manera las operaciones de un diagrama de secuenciapueden compartir informacin.
Dos posibles soluciones son:
Restriccin implcita: El valor del argumentoventa es el mismo en todos los eventos deldiagrama.
87
Los autores, 2003; Edicions UPC, 2003
-
Modelo del comportamiento en UML 23
Informacin elemental vs informacin compuesta
La informacin tratada por una operacin se expresa tanto a nivel de losparmetros como de la salida que aparecen en la cabecera de laoperacin.
Hay dos tipos de informacin: Informacin elemental: contiene un nico elemento de informacin indivisible.
Propiedad Clase de objetos predefinida: Integer, Real, ...
Informacin compuesta: es una composicin de informaciones elementales (y,por tanto, hay que especificar cmo se define la composicin).
Ejemplo: ResumenVentas(num-pv) que devuelve un listado de ventas con la informacin:Para cada Producto p vendido en aquel PuntoDeVenta num-pv mostrar - el cdigo del producto - la cantidad total vendida de p en num-pv
ResumenVentas (num-pv:Integer): ???
Modelo del comportamiento en UML 24
Informacin Compuesta - Definicin
Problema: Cmo se especifica el contenido de una informacin compuesta?
En la actualidad, UML no propone ninguna solucin. Utilizaremos una adaptacin de la definicin de flujos de datos que se hace en
el anlisis estructurado (Yourdon, 1993).
Mecanismos bsicos de definicin de informacin compuesta Inclusin: i1 = i2 + i3 + i4 Seleccin: i1 = [i2 l i3 l i4] Repeticin: i1 = {i2 + i3 + i4} Opcionalidad: i1 = i2 + (i3 + i4)
Ejemplo:ListadoVentas = num-pv + {cod-prod + cantidad}num-pv = Integer; codi-prod = Integer; quantitat = Integer
ResumenVentas(num-pv:Integer) : ListadoVentas
88
Los autores, 2003; Edicions UPC, 2003
-
Modelo del comportamiento en UML 25
Informacin compuesta - Contratos de las operaciones Las operaciones necesitarn mecanismos para manipular (acceder, construir,
etc.) la informacin compuesta que aparece en su cabecera.
Se necesita ectender OCL para poder manipular informacin compuesta.
Ejemplo: contracto de la operacin ResumenVentas (num-pv): ListadoVentas
Nom: ResumenVentas (num-pv): ListadoVentasResponsabilitats: Emitir el resumen de ventas solicitadoTipus: sistemaExcepcions:-
Precondiciones: - Postcondiciones: -
Salida: Mostrar (num-pv)
Para cada Producto p resultante de Producto.allInstances ->
select (p | p.LneaDeVenta.Venta.PuntoDeVenta.num-pv->includes(num-pv) Hacer cant = p.LneadeVenta ->
select (lv | lv.Venta.PuntoDeVenta.num-pv = num-pv).cantidad -> sum() Mostrar (p.cdigo) Mostrar (cant)
Modelo del comportamiento en UML 26
Diagrama de secuencia: Cuntos eventos?
El nmero de eventos de un diagrama de secuencia depende de cmo seproduzca la interaccin entre los actores y el sistema software.
:Cajero :Sistema
inicioVenta(pv): venta
* entrarProd(venta, prod, cant)
finVenta(venta): importe
pago(venta, importePago): cambio
:Sistema-X :Sistema
hacer-Venta(infoVenta)
infoVenta = pv + {prod + cant} + importePago
Ambos diagramas suponen la mismaentrada de informacin al sistema.
Los dos diagramas de secuencia puedenser correctos, segn las circunstancias.
89
Los autores, 2003; Edicions UPC, 2003
-
Modelo del comportamiento en UML 27
Redundancia - Ejemplo
El esquema conceptual contiene restricciones de integridad (grficas y textuales).
Los contratos de las operaciones tienen precondiciones, que son requisitos delcontenido del esquema conceptual para poder ejecutar una transaccin.
Es necesario que las precondiciones incluyan la comprobacin de las restricciones delmodelo conceptual?
Empleadocod-empsueldo
R.I. textual: dos empleados nopueden tener el mismo cdigo.
Nombre: AltaEmpleado (cod-emp, sueldo)Responsabilidades: dar de alta al empleadoExcepciones: -Precondiciones: no existe Empleado con cod-empPostcondiciones: creacin de un nuevo objeto Empleado con cod-emp y sueldoSalida: -
Hay que poner esta precondicin?
Modelo del comportamiento en UML 28
Redundancia - Definicin
Una especificacin es redundante si un mismo aspecto del sistemasoftware est especificado diversas veces.
La redundancia dificulta la modificabilidad de la especificacinporque si vara aquel aspecto hay que modificar todos los modelosdonde se le hace referencia.
La especificacin no debera ser redundante!
Redundancias posibles:
Entre el esquema conceptual y los contratos Entre los diagramas de secuencia y los contratos ...
90
Los autores, 2003; Edicions UPC, 2003
-
Modelo del comportamiento en UML 29
Significado habitual:
Redundancia - Esq. conceptual y contratos (I)
:Persona :Sistema
CompraCoche(nom-p,matr)
Personanom-p
Cochematrao
* 0..3tiene
Nombre: CompraCoche (nom-p,matr)Responsabilidades: compra de un cocheExcepciones: (las que se deducen de las prec.) Precondiciones: - existe Persona p con nom-p - existe Coche c con matr - p no tiene c - p no tiene ya 3 cochesPostcondiciones: - creacin de una asociacin tiene entre p y c Salida: -
Significado alternativo:Nombre: CompraCoche (nom-p,matr)Responsabilidades: compra de un cocheExcepciones: (las que se deducen de las prec.) Precondiciones: - existe Persona p con nom-p - existe Coche c con matr - p no tiene cPostcondiciones: - Si p tiene ya 3 coches entonces
eliminar la asociacin entre p y el coche c de ms antigedad
- creacin de una asociacin tiene entre p y cSalida: -
Modelo del comportamiento en UML 30
Redundancia - Esq. conceptual y contratos (II)
Cmo se han de interpretar los contratos en relacin al modeloconceptual?
Precondiciones:
Qu ha de contener el Modelo Conceptual para intentar ejecutar unaoperacin.
Restricciones del modelo conceptual:
Estn garantizadas despus de la ejecucin de todas las operacionesque participan en un caso de uso.
Se rechazan todas las operaciones de un caso de uso si su ejecucinviola (globalmente) alguna restriccin de integridad del modeloconceptual.
91
Los autores, 2003; Edicions UPC, 2003
-
Modelo del comportamiento en UML 31
Redundancia - Esq. conceptual y contratos (III)
:Persona :Sistema
AltaPersona(nombre,direccin)
:Persona :Sistema
AltaPersona(nombre,direccin)
HablaIdioma(nombre, idioma)*
Nombre: AltaPersona(nombre,direccin)Precondiciones:Postcondiciones: - creacin de un objeto Persona con el nombre y la direccin especificadosSalida:
Nombre: HablaIdioma(nombre,idioma)Precondiciones: - existe Idioma con nombre=idioma - no existe la asociacin habla entre nombre e idioma Postcondiciones: - creacin de una asociacin habla entre la Persona con nombre=nombre y el Idioma Salida:
Personanombredireccin
Idiomanombrenm-parlantes
* 1..*habla
Caso de uso: Aadir-Persona-1 Caso de uso: Aadir-Persona-2
No permite aadir nunca una persona!
Modelo del comportamiento en UML 32
Redundancia - Diagramas de secuencia y contratos
Los diagramas de secuencia definen un orden de invocacin de lasoperaciones.
Las operaciones no han de incorporar informacin para garantizarque este orden se cumpla.
:Cajero :Sistema
inicioVenta(pv): venta
* entrarProd(venta, prod, cant)
finVenta(venta): importe
pago(venta, importePago): cambio
Nombre: pago (venta, importePago): cambioPrecondiciones: - existe Venta venta - la Venta venta ha finalizado Postcondiciones: ...Salida:
son redundantes
92
Los autores, 2003; Edicions UPC, 2003
-
Modelo del comportamiento en UML 33
Bibliografa
Larman, C.Applying UML and Patterns: An Introduction to Object-Oriented Analysisand Design and the Unified Process (second edition)Prentice-Hall, 2002. (Cap. 13, 15)
Rumbaugh, J.; Jacobson, I.; Booch, G.The Unified Modeling Language Reference ManualAddison-Wesley, 1999.
Booch, G.; Rumbaugh, J.; Jacobson, I.The Unified Modeling Language User GuideAddison-Wesley, 1999.
93
Los autores, 2003; Edicions UPC, 2003
-
Modelo de los estados en UML 1
Modelo de los estados en UML
Introduccin Uso de los diagramas de estado Ejemplos Acciones y condiciones de una transicin Estados imbricados Bibliografa
Modelo de los estados en UML 2
Modelo de anlisis (especificacin)
Casos de uso- nivel alto- esencial
Diagramas decasos de uso
Diagramasestticos deestructura de objetosdel dominio
Diagramas desecuenciadel sistema
Diagramasde estado deobjetos ycasos de uso
Modelo decasos de uso
Modelo delcomportamientodel sistema
Modelo de losestados
Contratospara lasoperacionesdel sistema
Modelo conceptual delos datos
Modelode anlisis
94
Los autores, 2003; Edicions UPC, 2003
-
Modelo de los estados en UML 3
Modelo de los estados
Objetivos: Crear diagramas de estado para objetos y casos de uso.
Eventos, estados y transiciones:
Evento: aquello que requiere una respuesta del sistema software
Estado: condicin de un objeto o de un caso de uso en un momento del
tiempo
Transicin: cambio de estado como consecuencia de un evento
Modelo de los estados en UML 4
Diagrama de estados
Variable: tipo=valor inicial
Nombre Estado
Nombre EstadoEntry/accindo/actividadexit/accinevent/accin
Ev.(argumentos)[condicin@/accin
Nombre super estado
Un diagrama de estados muestra la secuencia de estados que pasa un objeto (o una interaccin) durante su vida en repuesta a los estmulos recibidos, junto con sus respuestas.
95
Los autores, 2003; Edicions UPC, 2003
-
Modelo de los esta