Desarrollo de Sistemas de Información - ocw.unican.es · conjunto de valores Cardinalidad ... para...

Tema2.DiseñoConceptual

DesarrollodeSistemasdeInformación

MartaElenaZorrillaPantaleónDPTO.DEMATEMÁTICAS,ESTADÍSTICAY

COMPUTACIÓN

EstetemasepublicabajoLicencia:CreaGveCommonsBY‐NC‐SA3.0

http://creativecommons.org/licenses/by-nc-sa/3.0/es/

UC‐MartaZorrilla

DISEÑO CONCEPTUAL

  Ensistemasdeinformaciónseasumequeundominioconsistedeunnúmerodeobjetosylasrelacionesentreellosqueseclasificanenconceptos

  Conceptos:cliente,productoyventa

  Objetos:clienteyproducto

  Relación:venta

  Unmodeloconceptualincluyenosóloobjetos,relacionesyconceptos(estructura)sinotambiéncómoeldominiocambia(comportamiento).Ademásdebeserconsistente(reglasdeintegridad)ypuedesernecesariorecogerreglasdederivación.

2

UC‐MartaZorrilla

DISEÑO CONCEPTUAL: ESTRUCTURAL

  Unconceptoesalgoquesehaformadoennuestramenteatravésdelageneralizacióndeciertasinstancias.

  Laextensióndeunconceptoeselconjuntodeinstanciasposible

  LaintensióndeunconceptoeselconjuntodepropiedadescomparGdasdelasinstancias.

  Tipodeen=dadesunconceptocuyasinstanciassonobjetosidenGficables.TodainstanciaesdeunGpodeenGdad,aunquepudieraserlodemásdeuna(persona,estudiante)

  TiposderelaciónsonconceptoscuyasinstanciassonrelacionesentredosomásenGdades(instanciasdeunGpodeenGdad)

  Todoaquelloenloqueestemosinteresadosdebeestarconceptualizado

3

UC‐MartaZorrilla

DISEÑO CONCEPTUAL: COMPORTAMIENTO

  Eventosdedominio(cambiosendominio)

  CuandoseproduceuncambiodeunaomásinstanciasdeunGpoenGdadorelación

  Ej.Transferenciabancaria

  Acciones

  Consultas(noproducencambioeneldominio)

  Accióntemporalqueocurreindependientedelestadodelsistema

  AcciónexplícitainiciadaporunacondiciónsaGsfecha(restriccionesdenegocio,modosdeoperacióndelnegocio,etc.)

  Eventosyaccionessoninstanciasdeconceptos.TienecaracterísGcasquesonlasrelacionesconotrasenGdades.

  P.ej.LascaracterísGcasdeunatransferenciasonlacuentaorigenydesGnoylacanGdadtransferida

4

UC‐MartaZorrilla

DISEÑO CONCEPTUAL: RESTRICCIONES Y REGLAS

  Restriccionesdeintegridad

  Requerido

  Único

  Posibleconjuntodevalores

  Cardinalidad

  Restriccionesdedominionoestructurales

  Reglasdederivación

  CómoinferirhechosnuevosparGendodeotros

5

UC‐MartaZorrilla

INGENIERÍA DE REQUISITOS

  Elmodeladoconceptualprecedealdiseñodelsistema

  Undocumentoconlosrequisitosdelsistemasprecedealmodeladoconceptual.

  IngenieríaderequisitosesunprocesocomplejoporqueimplicalaparGcipacióndediferentesactores(usuarios,analistas,jefes,…)condiferentespuntosdevista,necesidadeseintereses.

  DefinirlascaracterísGcasdeldominioylasfuncionesquedeberealizarelsistemadeinformación(1erniveldedetalle)

  Definirlosrequisitosfuncionalesynofuncionales(denominadaespecificaciónderequisitos)

  Apoyarseenmodelosconceptualesparavalidarconlosusuarioslosrequisitosantesdepasaraldiseño(esquemasconceptualessencillosresultanúGlesenestafase)

6

ER PARA DISEÑO DE BD

7

UC‐MartaZorrilla

8 EVOLUCIÓN HISTÓRICA

  PropuestoporChenendosarbculosyahistóricos,en1976y1977.

  SegúnChen,“ElModeloE/Rpuedeserusadocomounabaseparaunavistaunificadadelosdatos”,adoptando“elenfoquemásnaturaldelmundorealqueconsisteenen2dadesyrelaciones”.

  Posteriormenteotrosautoreslohanampliadoconimportantesaportaciones,formándoseenrealidadunafamiliadeModelosdeDatos.

  SeabordaráelmodeloE/RbásicoyelmodeloE/Rextendido.

  ElModeloE/RhatenidounagrandifusiónenlacomunidadinformáGcadedicadaalasBD,pruebadeelloesquehasidoelmodelomásextendidoenlasherramientasCASEdeayudaaldiseñodeBD.

  DATEcriGcaalmodeloERdiciendoquenoesmásqueunafinacapaporencimadelmodelorelacional

UC‐MartaZorrilla

9 ELEMENTOS ESTÁTICOS

  EnGdad(enGty)  ObjetoqueexisteysedisGnguedelosdemás.

  Puedenserconcretos  P.ej.:unlibro,unapersona,..

  Oabstractas  P.ej.:préstamo,pedido,…

  Atributo(airibute)  PropiedadesquecaracterizanalasenGdades.

  Claveprimaria:atributosqueidenGficanalaenGdad  P.ej.:ISBN(PK),btulo,idioma,…paraenGdadlibro

  Dominio(domain)  ConjuntodevalorespermiGdosparaunatributo

  P.ej:indicandoelGpodedatos(porintensión)  P.ej:sexo‐>MoF(porextensión)

UC‐MartaZorrilla

10 ENTIDADES

  ExistendoscategoríasdeGposdeenGdades:

  Regularesofuertes,quesonaquellascuyosejemplaresGenenexistenciaporsímismos

  Casopréstamosdelabiblioteca:LIBROyAUTOR

  Débiles,enlascualeslaexistenciadeunejemplardependedequeexistaunciertoejemplardeotroGpodeenGdad

  CasodelEJEMPLARquedependedeLIBRO

LIBRO AUTOR

EJEMPLAR

UC‐MartaZorrilla

11 ELEMENTOS ESTÁTICOS (Y 2)

  Relación(relaGonship)

  ConexiónsemánGcaentredosomásenGdades

  Cardinalidad:nºmáximodeunidadesdeunconjuntoqueseconectaorelacionaconunaenGdaddeotroyviceversa

DPTO

EMPLEADO

trabaja 1:m

LIBRO

AUTOR

escribe n:m

PERSONA

ALUMNO

es 1:1

(0:m)

(1:1) (1:m)

(1:n)

(0:1)

(1:1)

UC‐MartaZorrilla

12 RELACIONES REFLEXIVAS

PERSONA

maternidad

hijomadre

  Enestoscasosserequiereespecificarelrol,papelquedesempeña

enlarelación

MECANISMO

consGtuye

Formapartede

Compuestopor

1:N

N:M

UC‐MartaZorrilla

13 RELACIONES

LIBRO

EJEMPLARES

GeneID

EMPLEADO

HIJOS

GeneE

Dependenciadeiden=ficación

Dependenciadeexistencia

numcopia

NRP

estado DNI

0:N

1:1

0:N

1:1

ISBN

UC‐MartaZorrilla

14 ATRIBUTOS Y CLAVES

PERSONA IDPersonaNombre

EdadNIF

Iden=ficador

Clavecandidata

ASIGNATURA

ALUMNO

matriculaCursoacad.

ALUMNO_UC

PERSONA

Enrolla_UCFecha

AtributoderivadoFechanacimiento

AdmitenulosProfesión

Teléfonos Mul=valuado

Dirección

Calle CP Localidad

Atributocompuesto

1:1 n:m

UC‐MartaZorrilla

15 GESTIÓN DE PRÉSTAMOS (EJEMPLO)

  Requisitos:  LabibliotecaestáinteresadaenautomaGzarlagesGónde

préstamos  Elmododefuncionaressencillo,básicamenterequiere

registrarelsocioquesellevaellibro,ydequéejemplarsetrata,asícomolasfechasdeentrega,devoluciónprevistaydedevolución.

  Labibliotecaestáorganizadaendiversassedesyelsociopuedecogerlibrosdecualquieradeellas.

  DelsocioseGenenlosdatospersonalesbásicos.  Ydeloslibros,todosloscamposdescripGvosquelos

caracterizan(btulo,idioma,autores,editorial,fecha,…).  Ademásdecadaejemplarsequerráconocerelestadoenel

queseencuentra(prestable,enreparación,fueradecirculación)

UC‐MartaZorrilla

16 PRÉSTAMOS DE LA BIBLIOTECA

nombreSOCIOCodSocio

dni

CodlibGtulo

FechaAlta

(0,n)

(0,n)

EJEMPLAR

numEjemplar

FechaPrevistaDevFechaDev

nombreSEDEBiblio.CodSed

localidad(1:1)

(0:n)

en

ID

(0:n)(1:1)

Estado

prestar EDITORIAL

publicadoIDEdit

escrito

(0:n)

(1:n)

(0:n)

(1:1)

ISBN

IDAutor

fecha

IDIOMA

(1:1)

IDIdioma

LIBRO

en

(0:n)

nombre

nombreApellido_1

AUTORES

nombre

ubicado

UC‐MartaZorrilla

17 PRÉSTAMOS DE LA BIBLIOTECA

nombreSOCIOCodSocio

dni

CodlibGtulo

NumPrestFechaAlta

(1:1)

(1:1)

EJEMPLAR

numEjemplar

FechaPrevistaDevFechaDev

nombreSEDEBiblio.CodSed

localidad(1:1)

(0:n)

enID

(0:n)(1:1)

Estado

a

EDITORIAL

publicadoIDEdit

escrito

(0:n)

(1:n)

(0:n)

(1:1)

ISBN

IDAutor

fecha

IDIOMA

(1:1)

IDIdioma

LIBRO

en

(0:n)

nombre

nombreApellido_1

AUTORES

nombre

ubicadoPRESTAMO

deun

(0:n)

(0:n)

UC‐MartaZorrilla

18 GESTIÓN DOCENTE (EJEMPLO)

  Requisitos:

  Cadaprofesorperteneceaunsólodepartamentoydebepertenecerauno.

  ElprofesorpuedeimparGrvariosgruposdelamismaodisGntaasignatura,yungrupodebeserenseñadoporunprofesor.

  Losalumnossematriculandevariasasignaturas(almenosuna)cadacursoacadémicoperohandehacerloenungrupo(turnodemañana/tarde).Asuvezungrupotendrávariosalumnosmatriculados.Cadagrupotendráasignadounaulaparacadadíayhoradelasemana.

  LamatrículadaráopciónadosconvocatoriasdeexamenconsurespecGvacalificación.

  Tododepartamentodebetenerundirector,queesprofesor.

  LosatributosdecadaenGdadsonlosquecabríaesperar.

UC‐MartaZorrilla

19 GESTIÓN DOCENTE

nombrePROFESORNroPersonal

Apellido_1

DPTO

pertenece

CodDptonombre

dirige

ALUMNOS CodAlunombre

ASIGNATURA

CodGrupo

GRUPO Max‐alum

imparte

NIF

constaCalificación

Convocatoria(1..2)

MATRICULA

realiza

GeneID

(1:1)

(1:n)

(0:n)

(0:n)(1:1)

(1:1)

(0:n)

(0:1)

(1:1)

(0:n)

(1:1)

CursoAcad

NombreCréditosCarácterCurso

CodMatr

CodAsigocupa

día

horaAULA

(0:n)

(1:n) Nro

(1:1‐dia‐hora)

UC‐MartaZorrilla

20 RELACIONES N-ARIAS

PROVEEDOR

PIEZAcompraTRABAJO(1:n)(1:n)

(1,1)

• UnapiezaYenuntrabajoZ–unapareja(pieza,trabajo)–lasuministran0o1proveedores.• UnproveedorXenuntrabajoZ–unapareja(proveedor,trabajo)–suministra1,2,..,npiezas.• UnproveedorXsuministraunapiezaY–unapareja(proveedor,pieza)–en1,2,..,nproyectos

UC‐MartaZorrilla

21 RELACIONES N-ARIAS (SIN REDUNDANCIA)

PROVEEDOR

PIEZAcompraTRABAJO

Puedesuministrar

(0:n)

(1:n)

(1:n)(1:n)

(0:1)

Puedeintervenir

(0:n)

(0:n)

necesita

(1:n)(0:n) canGdadPrecioud.

CanGdadtotal

precio

UC‐MartaZorrilla

22 GENERALIZACIÓN Y ESPECIALIZACIÓN

PERSONA

CLIENTE EMPLEADO

nombreNroPersona

Apellido_1

CalificacióncrediGcia

salario

puesto

LaGeneralizaciónseconsideracomouncasoespecialderelaciónentreunoovariosGposdeenGdad(subGpos)yunGpomásgeneral(superGpo),cuyascaracterísGcassoncomunesatodoslossubGpos.

Elmecanismodeabstraccióncontrariosellamaespecialización.

UC‐MartaZorrilla


  LadivisiónensubGpos(especialización)puedevenirdeterminadaporunacondiciónpredefinida(porejemplo,enfuncióndelosvaloresdeunatributollamadodiscriminante).

  LaGeneralización/EspecializaciónGenedosrestriccionessemánGcasasociadas:  Totalidad(todoejemplardelsuperGpoGenequepertenecera

algúnsubGpo).ElcasocontrariosellamaParcialidad.  Solapamiento(unmismoejemplardelsuperGpopuede

perteneceramásdeunsubGpo).ElcasocontrariosellamaExclusividad.

UC‐MartaZorrilla


PERSONA

HOMBRE MUJER

Totalexclusiva

PERSONA

EMPLEADO ESTUDIANTE

Totalconsolapamiento

PERSONA

MEDICO ENFERMERO

Parcialexclusiva

EMPLEADO

DOCENTE INVESTIGADOR

Parcialconsolapamiento

(t,e)

(p,e)

(t,s)

(p,s)

UC‐MartaZorrilla

25 RESTRICCIÓN DE EXCLUSIVIDAD

Lapersonaopercibeunabecaoestácontratado

PERSONA

BECApercibe

CONTRATOEstáen

UC‐MartaZorrilla

26 RESTRICCIÓN DE EXCLUSIÓN

Lapersonaimparteorecibeelcurso,nopuedeestarenambasrelacionesalavez

PERSONA

imparte

CURSO

recibe

UC‐MartaZorrilla

27 RESTRICCIÓN DE INCLUSIVIDAD

Laspersonasquedominanidiomassonunsubconjuntodelasquerealizanviajesinternacionales.SiunapersonaparGcipaendomina,GenenecesariamentequeparGciparenhacenviajes

PERSONA

dominan IDIOMA

hacen VIAJESINTERN.

UC‐MartaZorrilla

28 RESTRICCIÓN DE INCLUSIÓN

Loscirujanossonunsubconjuntodelosmédicosdelhospital

MEDICO

aGende

HOSPITAL

opera

UC‐MartaZorrilla

29 AGREGACIÓN

  EsunGpoespecialderelaciónenlacuallascardinalidadesmínimaymáximadelGpodeenGdadagregadasiempreson(1,1)

  Existendosclasesdeagregaciones:

  Compuesto/Componente:

  permiterepresentarqueun“todo”seobGeneporlaunióndediversaspartesquepuedenserGposdeenGdadesdisGntasyquejuegandiferentesrolesenlaagregación.

  Miembro/Colección:

  permiterepresentarun“todo”comounacoleccióndemiembros,todosdeunmismoGpodeenGdadytodosjugandoelmismorol.

  Estaagregaciónpuedeincluirunarestriccióndeordendelosmiembrosdentrodelacolección(indicandoelatributodeordenación).

UC‐MartaZorrilla

30 EJEMPLOS AGREGACIÓN

COCHE

CHASIS MOTOR RUEDA

FLOTA BARCO

(1:1)(1:1) (4:4)

(1:n)

Ordenadopornum_barco

AgregaciónCompuesto/Componente

AgregaciónMiembro/Colecciónconcardinalidadesyrestriccióndeorden

UC‐MartaZorrilla

31 AGREGACIÓN – OTROS USOS

ComoherramientaparaexpresarrelacionesentrerelacionesoentrerelacionesyconjuntosdeenGdades

nombre Aspirante Codemp

tipo

Empresaentrevista

Resultaen

Oferta_empleo

nombre dni

competencias IDemp

fecha Nombre entrevistador

UC‐MartaZorrilla

32 AGREGACIÓN – OTROS USOS ( Y 2 )

UnaformaderesolverestasituaciónenERescreandolaenGdaddébilEntrevistayrelacionaréstaconOferta_empleo

nombre Aspirante Codemp

tipo

EmpresaAEE

Resultaen

Oferta_empleo

nombre dni

competencias IDemp

ENTREVISTA fecha Nombre entrevistador

UC‐MartaZorrilla

33 EVITAR LAS REDUNDANCIAS

  UnelementodeunesquemaesredundantesipuedesereliminadosinpérdidadesemánGca.

  Existendosformasprincipalesderedundancia:

  Enlosatributos(derivadosocalculados):

  Aunquesonredundantes,nodanlugarainconsistenciassiemprequeenelesquemaseindiquesucondicióndederivadosylafórmulamediantelaquehandesercalculados.

  Enlasrelaciones(tambiénllamadasinterrelacionesderivadas):

  UnarelaciónesredundantesisueliminaciónnoimplicapérdidadesemánGcaporqueexistelaposibilidadderealizarlamismaasociacióndeejemplarespormediodeotrasrelaciones.

  Paraelloescondiciónnecesariaperonosuficientequeformepartedeunciclo=>HayqueestudiardetenidamenteloscicloseneldiagramaE/R.

UC‐MartaZorrilla

34 EVITAR LAS REDUNDANCIAS (Y 2)

©Piaynietal.

UC‐MartaZorrilla

35 ¿HAY PROBLEMA DE REDUNDANCIA?

PROFESOR

CURSO

ParGcipa

TEMA Consta

invesGga

Imparte

1:n 1:n

1:n 1:n1:n

1:n

1:n

1:n

1:n

UC‐MartaZorrilla

36 GESTIÓN DE COMPRAS (EJEMPLO)

  Requisitos:  UnaempresaestáinteresadaenautomaGzarsuprocesode

compras  Elmododefuncionaressencillo,básicamenterequiere

registrarlahojadelpedidoquerealizaaundeterminadoproveedorenunadeterminadafecha

  Enlahojadelpedidoquedaconstanciadelnúmerodeunidadesquecompradecadaarbculoyelpreciodecompra,yencasodequeelproveedorobienporvolumenoporpromoción,lerealizaundescuento,tambiénloanota

  LosproductosquecompranGenendisGntoIVA  Generalmenteelpagaasusproveedoresalmesderecibirla

mercancíayportransferencia,aunquelopuedehaceraplazos

  LosatributosdecadaenGdadsonlosquecabríaesperar

UC‐MartaZorrilla

37 GESTIÓN DE COMPRAS

nombrePROVEEDORCodProv

zno

ARTICULO Codartnombre

PEDIDO NumPedFechaPed

suministra

precioUd

unidades

numLinea

precioCompra

consta

(1:1)

(1:n)

(0:n)

iva

ivadescuento

PAGONumPagoFechaPago

Con/del(0:n) (1:1)

(0:n)

TipopagoFechaEntrega

Conceptoc/ccanGdad

c/c

EstadoImportepedido

Dirección

Calle CP Localidad

UC‐MartaZorrilla

38 GENERALIZACIÓN DEL TIPO DE PAGO

PAGO

(p,e)

tarjeta cheque

Fechacaducidadnúmero

(1:1)

NumPagoFechaPago

Tipopago

Concepto

c/c

canGdad

Tipotarjeta{crédito,débito}IBANnúmCheque

transferencia

DISCRIMINANTE

UML PARA DISEÑO DE BD

UC‐MartaZorrilla

DIAGRAMAS UML

  UMLsedefinecomo“unlenguajeestándarparalaespecificación,construcción,visualizaciónydocumentacióndeloscomponentesdeunsistemaso}ware”

  Esindependientedeunlenguajedeprogramaciónoprocesodedesarrolloconcreto

  Cubreladefinicióndeaspectosestá=cos(estructurales)comodinámicos(decomportamiento)delsistemamientrasevolucionaatravésdelciclodevidadeldesarrollohaciendousodedisGntasvistasarquitecturales(CasosdeUso,dediseño,deInteracción,deImplementación,deDespliegue)ydiagramas(casosdeuso,declases,deoobjetos,deSecuencia,deColaboración,etc.)

  HasidoaceptadoparadiseñarBD

40

UC‐MartaZorrilla

JERARQUÍA DE DIAGRAMAS UML 41

UC‐MartaZorrilla

DIAGRAMAS UML

  DiagramasdeEstructura  Clases:clases,relaciones,interfacesycolaboraciones.Vistade

diseñoestáGcaydeprocesos.

  Objetos:modelaninstanciasdelaclaseyseuGlizanparadescribirelsistemaenuninstanteconcretodeGempo.

  Diagramasdecomponentes:organizaciónydependenciasentreunconjuntodecomponentesso}ware(fuente,binariosyejecutables).

  Diagramasdedespliegue:MuestranlaconfiguracióndelsistemaenGempodeejecución,indicandonodoshardware,componentesqueseejecutanenesosnodos,etc.

  Componentes:Describenlaestructuradelso}waremostrandolaorganizaciónylasdependenciasentreunconjuntodecomponentes

  Estructuracompuesta:Muestranlaestructurainterna(incluyendopartesyconectores)deunclasificadorestructuradoounacolaboración

42

UC‐MartaZorrilla

DIAGRAMAS UML

  DiagramasdeComportamiento  Casodeuso:modelanlafuncionalidaddelsistema,conlosactores

queintervienen

  Interacción:objetos,relacionesymensajes:

  Secuencia:ordenacióntemporaldemensajesqueintercambianlosobjetosdeuncasodeuso

  Colaboración:muestralasinteraccionesentreobjetosenformadeseriesdemensajessecuenciados

  Tiempo:MuestranlosGemposrealesenlainteracciónentrediferentesobjetosoroles.

  DeRevisióndeInteracciones:HíbridoentrediagramadeacGvidadydiagramadesecuencia.

  Estado:muestrancómopuedencambiarlosobjetosenrespuestaalossucesosexternos.Engeneralmodelanlastransicionesdeunobjetoespecífico.

  Ac=vidad:modelanelflujodecontroldeunaacGvidad,representanlainvocacióndeunaoperación,unpasodentrodeunprocesodenegocioounprocesodenegociocompleto.

43

UC‐MartaZorrilla

DIAGRAMA DE CLASES

  DiagramadeClases:muestraunconjuntodeclases,interfacesycolaboraciones,asícomolasrelacionesentreellos.

  LaclaseeslaunidadbásicaqueencapsulatodalainformacióndeunTipodeObjeto(unobjetoesunainstanciadeunaclase).

  Unarelaciónesunaconexiónentreelementosestructurales.

  ExistencuatroGposderelacionesenUML2:

  Dependencia

  Asociación  Agregación

  Composición

  Generalización

  Realización

44

UC‐MartaZorrilla

45 CLASES

  Clase:Descripcióndeunconjuntodeobjetosquecompartenlosmismosatributos,operaciones,relacionesysemánGca

  Puedenserconcretasoabstractas

  Atributo:RepresentaunapropiedaddeunaenGdad.CadaatributodeunobjetoGeneunvalorqueperteneceaundominiodevaloresdeterminado.

  Lassintaxisdeunaatributoes:  Visibilidad<nombre>:Gpo=valor{propiedades}

  Dondevisibilidadesunodelossiguientes:  +público.  #protegido.  ‐privado.

  Operación:elconjuntodeoperacionesquedescribenelcomportamientodelosobjetosdeunaclase.

  LasintaxisdeunaoperaciónenUMLes:  Visibilidadnombre(lista_parámetros):@po_retorno{propiedades}

UC‐MartaZorrilla

EJEMPLO: CLASE PERSONA 46

Persona

Nombre:stringDireccion:string[0..1]Tfnos:string[*]/acGvo:booleansetNombre(n)setDireccion(d)getNombre():stringgetDireccion():stringEmpleadoAcGvo():booleanBorrarTfnos{evento=ondelete}

NombredelaClase

Atributos

Métodos

Nota:enBD,engeneral,noseindicalavisibilidadpuesseenGendesiemprepública.LosmétodossetygetseenGendensiempreestablecidos.

Atributoderivado

AcGvo==trueifself.EmpleadoAcGvo()=true

Disparador

UC‐MartaZorrilla

47 ASOCIACIONES

  Lasasociacionesrepresentanrelacionesexistentesentreclases.

  Puedenser:  Binarias

  Reflexivas

  Ternarias

mulGplicidad mulGplicidadNombre

rol rol

navegabilidadDireccióndelnombre

Persona Empresa1..* 1Trabaja_en

empleado patrón

MulGplicidad:1 *

0..1n..m

0..*

UC‐MartaZorrilla

48 ASOCIACIONES

  Laasociaciónpuedeteneratributos

  Puedenserreflexivas

Persona Empresa1..* 1Trabaja_en

empleado patrón

Trabaja_en

Puesto:stringFechaContrato:string

0..*

1

Es_jefe

UC‐MartaZorrilla

ASOCIACIONES BINARIAS COMO ATRIBUTOS

  Engeneral,lasrelacionesbinariasseestablecencomoasociacionesparaunamejorinterpretación

  Seaconsejamodelarsoloaquelloselementosespecíficosdeldominio

49

Empleado

nombre:stringsalario:DinerotrabajaEn:Dpto

<<datatype>>Dinero

canGdad:decimalmoneda:currency

Empleado

nombre:string

Dpto

nombre:string0..1

Trabaja_en

1..n

UC‐MartaZorrilla

ASOCIACIONES N-ARIAS 50

Equipo

nombre:string

ParGdoFecha:dateEspectadores:int

Estadio

nombre:stringvisitante

casa

1

1

1

UC‐MartaZorrilla

AGREGACIÓN Y COMPOSICIÓN

  Unaagregaciónesunaasociaciónquepermiterepresentarobjetoscompuestos.

  Agregación:cuandoambasclasesexistendeformaindependiente

  Composición:laexistenciadeunaclaseestácondicionadaalaexistenciadeotra.

51

Universidad Dpto1 1..*Compuesta_por

Universidad Alumnos1..* 1..*Agregación_de

UC‐MartaZorrilla

GENERALIZACIÓN

  Lageneralizaciónesunaasociaciónentreunaclasemásgeneral(superclaseoclasepadre)yunaclasemásespecífica(subclaseoclasehija).

  Llevaimplícitodosprincipios:herencia(simpleomúlGple)einclusión

52

MujerHombre

Persona

UC‐MartaZorrilla

MECANISMOS DE EXTENSIÓN DE UML

  PermitenadecuarlasemánGcadeloselementosdemodelosparGculares

  Ex@endenlasposibilidadesdeanotación:

  EstereoGpos:palabrasclavesquealteranelsignificadoofuncionalidaddeunelemento.<<persistent>>

  ValoreGquetado:comentariosquepermitenañadirinformaciónalelemento.{versión=3.1}

  Restricción:limitanlafuncionalidaddeunelemento.{edad>18}

  SerecogeenOCL

53

UC‐MartaZorrilla

RESTRICCIONES 54

UC‐MartaZorrilla

RESTRICCIONES 55

UC‐MartaZorrilla

NOTAS 56

UC‐MartaZorrilla

RESTRICCIONES EN OCL

  OCLesunlenguajedemodelosynolenguajedeprogramación

  PermiterecogerlasemánGcadeformanoambigua

  SeuGlizapara

  EspecificarinvariantesparaclasesyGpos

  Especificarpre‐ypost‐condicionesparamétodos

  Comolenguajedenavegación

  Especificarrestriccionesenoperaciones

  Comprobarrequisitosyespecificaciones

57

UC‐MartaZorrilla

RESTRICCIONES EN OCL: EJEMPLOS

  Invariantesenatributos:context Customer invariant agerestriction: age >= 18

context CustomerCard invariant correctDates: validFrom.isBefore(goodThru)

The type of validFrom and goodThru is Date. isBefore(Date):Boolean is a Date operation.

  Invariantesusandonavegacióncontext CustomerCard invariant printedName: printedName =

owner.title.concat(‘ ‘).concat(owner.name)

58

Customer name: String title:String isMale: Boolean dateOfBirth: Date

CustomerCard

valid: Boolean validForm: Date goodThru: Date color: enum{silver, gold} printedName: String

age(): Integer

owner

card 0..* 1

UC‐MartaZorrilla

ATRIBUTOS Y TIPOS DERIVADOS: EJEMPLOS

  Reglasdederivación:

context Producto::cantidadVendida:Decimal derive Venta.cantidad-> sum()

context Cliente::compradorFrecuente:Producto derive Cliente.AllInstances()-> select(c:cliente|c.venta-> (select (s:venta|s.producto=self).cantidad-> sum()>1000)

context Cliente::favorite:Producto derive Producto.AllInstances()-> select(p:producto|p.venta-> (select (s:venta|s.cliente=self).cantidad-> sum()>1000)

59

Producto name: String /cantidadvendida: Decimal

Venta

Fecha: Date cantidad: Natural

0..*

1

Cliente

Nombre: String * * favorito

compradorFrecuente

UC‐MartaZorrilla

DISEÑO DEL COMPORTAMIENTO

  Eldiseñoestructuralrecogeloshechosdelsistemadeinformación.EstoscambianenelGempodeformaorganizada(noarbitraria)

  Elesquemadecomportamientodefineprincipalmentelasrestriccionesyefectosdeloseventos.Estospuedenserdedominioodeacción.

  SedefinenmedianteOCLamododepre‐condicionesypost‐condicionesobienmediantelenguajeprocedimental(pseudocódigo).EnUMLserepresentancomoespecializacionesdeldominiodeloseventosodelasacciones.

60

UC‐MartaZorrilla

DISEÑO DEL COMPORTAMIENTO

  Eventosdedominio:eventoqueproduceuncambioeneldominio

  Ej:enPedidos,laaccióncambiarelestadodelpedidoa“recibido”yactualizarlaunidadesrecibidasdecadaarbculo

  Acciones:eventoinvocadoporunusuariouotroevento.Estepuedeseriniciadoporuneventotemporal

  Ej:enPedidos,el30dediciembreenviarbonoaaquellosclientesquehayangastadomásde1000€

  Ej:nóminas,enviartransaccionesalbancoparapagodelpersonal

61

UC‐MartaZorrilla

EJEMPLO: CARRITO DE LA COMPRA VIRTUAL 62

(Oliveetal,2007)

UC‐MartaZorrilla


(Oliveetal,2007)

UC‐MartaZorrilla

DIAGRAMA DE TRANSICIÓN DE ESTADOS

  PermitenrecogerelcomportamientodeunGpodeenGdad

  Ej:Estadosporlosquepasauncochedealquiler

65

(Oliveetal,2007)

UC‐MartaZorrilla

DIAGRAMA DE TRANSICIÓN DE ESTADOS 66

(Oliveetal,2007)

UML VS ER

67

UC‐MartaZorrilla

68 UML VS ER

  ERnopermitemodelarelcomportamiento(nohayoperacionesnimensajes)

  LosatributosenERdeberíanconsiderarseenUMLcomoasociacionesn..1conlaclaseopuestasuprimida

  ERrepresentalarelaciónconunrombo,UMLpormediodeunaasociación.NoGenelamismasemáGca

¿unempladopuedeestarcontratadovariasvecesporlamismaempresa?

UC‐MartaZorrilla

69 UML VS ER (Y 2)

  EnOO,cadaobjetoGeneunidenGficadorúnicoindependientementedesusatributos.ERuGlizala“key”paraidenGficarcadaenGdad

  UMLnopermiterecogerrestricciones(másquelamulGplicidad),sedebenindicarenOCL

  EnUMLlarelacionesternariasnoGenenelmismosignificadoqueenER

unpréstamoeslaasociaciónentreunúnicosocioyunúnicolibro(porlapropiadefinicióndeclaseasociaGva)

MulGplicidadnosindicaporcadaparejadeinstanciasdedosclases,concuántasinstanciasdelaotraclaseestárelacionadaPero,NOindicaencuántasasociacionesparGcipaunainstanciadeunaclase,hayquerecogerloenOCL

UC‐MartaZorrilla

PROS Y CONTRAS PARA DISEÑO DE BD CON UML

  VentajasdeUML  Esestándar=>Facilitalacomunicación  Estábasadoenunmetamodeloconunasemán=cabien

definida  Sebasaenunanotacióngráficaconcisayfácildeaprender  SepuedeuGlizarparamodelarsistemassoZwarecompletos

endiversosdominios:  Sistemasdeinformaciónempresariales,SistemasWEB,sistemas

críGcosydeGemporeal,etc.

  Esfácilmenteextensiblemedianteperfiles

  InconvenientesdeUML  NoesespecíficoparadiseñodeBD  No=enelamismaexpresividad(semán=ca)queER  Nohayunperfilestandarizado,soloinicia=vas

(Ra=onalRose,porejemplo)

70

Desarrollo de Sistemas de Información - ocw.unican.es · conjunto de valores Cardinalidad ... para...

Documents

Transcript of Desarrollo de Sistemas de Información - ocw.unican.es · conjunto de valores Cardinalidad ... para...