Especificacion de Sistemas de Software en UML

Especificacin de sistemassoftware en UML

Ernest Teniente LpezDolors Costal CostaM. Ribera Sancho Sams

POLITEXT 153


POLITEXT

EDICIONS UPC

Dolors Costal CostaM. Ribera Sancho SamsErnest Teniente Lpez


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


Evolucin de Costes del hardware y del software

1960 70 80 90

100%

HARDWARE

SOFTWARE

9

Los autores, 2003; Edicions UPC, 2003


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


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



Fallos H/S

ndiceFallos

hardware

software

tiempo


Aplicaciones del software

Sistemas

Tiempo real

Gestin

De ingeniera

Cientfico

Empotrado

De PC

De inteligencia artificial

11



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


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



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


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



El proceso de la ingeniera

Formulacin

Anlisis

Generacin

Seleccin

Especificacin

Implementacin

Modificacin


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



Ciclo de vida clsico

MANTENIMIENTO

ANLISIS REQS.

ESPECIFICACIN

DISEO

CODIFICACIN

PRUEBA


Prototipaje

ANLISISREQUISITOS

DISEORPIDO

PROTO_TIPO

EVALUACIN

REFI_ NAMIENTO

PRODUCTO

15



Modelo en espiral

Planificacin Anlisis de riesg s

Evaluacin Ingeniera


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


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



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


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



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


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



Diseo del sistema global

albarn

Recepcin

Transp rte

SistemaInf rmtic

albarnaviso

ordenerrores

resultadodefectuoso

pedido


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



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


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



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


Factores de calidad del software

Eficiencia

Flexibilidad

Integridad

Mantenibilidad

Portabilidad

Fiabilidad

Actualidad

Reusabilidad

Testability

Usabilidad

Interoperabilidad

22



Eficiencia

Flexibilidad

Integridad

Mantenibilidad

Portabilidad

Fiabilidad

Actualidad

Reusabilidad

Testability

Usabilidad

Interoperabilidad

Factores de calidad del software: Conflictos


Propiedades deseables de las especificaciones

No ambiguas

Completas

Verificables

Consistentes

Modificables

Trazables

Usables durante la operacin y el mantenimiento

23



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


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



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


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


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



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


Visin de un sistema software

28



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


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



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


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



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)


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



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


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



Descripcin del comportamiento (I)

Los objetos se comunican mediante la invocacin de operacionesde otros objetos.


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



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


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



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


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



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


El tringulo del xito

Notacin

Proceso(metodologa)

Herramienta

Rational Rose,Objecteering,Visio, etc.

Craig LarmanThe Unified Process

U.M.L.

36



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


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


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





Diagramasestticos deestructura de objetosdel dominio








Modelode anlisis

39



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


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



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


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



TPV Supermercado Venta

Cliente

Pago

Lnea de venta

Ejemplo TPV: Clases de objetos

Producto


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



Es la representacin de relaciones entre dos o ms objetos.

- direccin de lectura

Persona Ciudad

- nombre de asociacin

Vive en

Asociaciones


Asociaciones de orden superior a dos

Se matricula

Asignatura Cuatrimestre

Alumno

43



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.


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



Multiplicidad en las asociaciones ternarias Ejemplos

Se responsabiliza


Profesor

Se matricula


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.


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



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


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



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


Ejemplo de clase asociativa

ParticipaProyecto Empleado

ParticipanteAsiste

Reunin

* *

* *

No es equivalente a:

AsistirProyecto Empleado

Reunin

* *

*

47



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.


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


tipo {disjoint, complete}

48



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


tipo{disjoint, complete}

nm-taln: Integer


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



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


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



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.


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



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


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



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}


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



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



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



Equivalencias notacionales (I)

Polgononmero_lados

Tringulo Rectngulo Pentgono . . .

Polgono

Tringulo Rectngulo Pentgono . . .

En UML:

es equivalente a:

Problema?


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



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}


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



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


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


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


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



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.


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



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)


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



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


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



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


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



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 *



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



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?


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



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


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



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


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


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













Modelode Anlisis

67



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.


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



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.


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



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.


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



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


Ejemplo TPV: Entorno del sistema

Compra deproductos

CLIENTECAJERO Devolverproducto

Iniciarsesin

supermercado tradicional

Compra deproductos

CLIENTEDevolverProducto

supermercado electrnico

71



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)


Cursos Alternativos

Lnea 4: Se introduce un identificador de producto inexistente. Indicar error. Lnea 9: El Cliente no tiene suficiente dinero. Cancela la venta.


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.


11. Calcula y muestra el cambio al Cliente. Imprime un recibo.12. Registra la venta que se acaba de hacer.

72



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


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


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



Section: Pagar en efectivo

Curso tpico de eventos


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


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.


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



Ejemplo TPV:

Comprarproductos

Pagar enefectivo

Pagar contarjeta

Devolver producto

Cajero Cliente

Contabilidad

Servicio de autorizacinde crdito


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


10. Registra la venta que se acaba de hacer.

11. Imprime un recibo.


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



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


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





Diagramasestticos de estructura de objetosdel dominio








Modelode anlisis

77



Descripcin del comportamiento en OO

Los objetos se comunican mediante la invocacin de operacionesde otros objetos


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



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.


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.


79




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.


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



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.


Representacin de iteraciones de eventos

:Actor :Sistema

evento1()

evento2()

evento3()

evento4()

*

*iteracin de unasecuencia de event s

iteracin de unnic event

81



Diagramas de secuencia:

:Cajero :Sistema

inicioVenta(pv)

*:venta


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)


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



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


finVenta(venta) :importe

pago(venta,importePago): cambio

SISTEMA


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



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


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



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


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



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:


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



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


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


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



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


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



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)


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



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?


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



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


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



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!


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



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


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













Modelode anlisis

94



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


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


Modelo de los esta

Especificacion de Sistemas de Software en UML

Documents

Transcript of Especificacion de Sistemas de Software en UML