Enginyeria Del Software, Especificació Amb UML

AULA POLITCNICA / FIB

EDICIONS UPC

Dolors Costal - M. Ribera SanchoErnest Teniente

Enginyeria del SoftwareEspecificaciEspecificaci de sistemes orientats a objectesamb la notaci UML

Primera edici: febrer del 2000

Aquesta publicaci s'acull a la poltica de normalitzaci lingsticai ha comptat amb la collaboraci del Departament de Cultura ide la Direcci General d'Universitats, de la Generalitat de Catalunya.

En collaboraci amb el Servei de Llenges i Terminologia de la UPC

Disseny de la coberta: Manuel Andreu

Els autors, 2000

Edicions UPC, 2000Edicions de la Universitat Politcnica de Catalunya, SLJordi Girona Salgado 31, 08034 BarcelonaTel.: 934 016 883 Fax: 934 015 885Edicions Virtuals: www.edicionsupc.esA/e: [email protected]

Producci: CPET (Centre de Publicacions del Campus Nord)La Cup. Gran Capit s/n, 08034 Barcelona

Dipsit legal: ISBN: 84-8301-366-5

Sn rigorosament prohibides, sense l'autoritzaci escrita dels titulars del copyright, sota les sancionsestablertes a la llei, la reproducci total o parcial d'aquesta obra per qualsevol procediment, inclosos lareprografia i el tractament informtic, i la distribuci d'exemplars mitjanant lloguer o prstec pblics.

ndex- Transparncies

1. Introducci a lEnginyeria del Software ......................................................... 112. Requeriments i Especificaci ......................................................................... 193. Introducci a lorientaci a objectes ............................................................... 28

3.1 - Motivaci i orgens ........................................................................... 283.2 - Aspecte Esttic ................................................................................. 333.3 - Aspecte Dinmic............................................................................... 343.4 - El llenguatge UML (Unified Modeling Language) ............................ 37

4. El llenguatge UML......................................................................................... 394.1 - Model Conceptual en UML............................................................... 394.2 - El llenguatge OCL (Object Constraint Language) ............................. 564.3 - Model de Casos ds en UML.......................................................... 654.4 - Model del Comportament en UML ................................................... 754.5 - Model dels Estats en UML................................................................ 91

5. El Procs Unificat de Desenvolupament de Software...................................... 97

- Recull dexercicis

1. Introducci................................................................................................... 1052. Model Conceptual en UML.......................................................................... 1063. El llenguatge OCL ....................................................................................... 1274. Altres models dUML .................................................................................. 128

Transparncies

ES:E - Introducci a lEnginyeria del Software 1

Introducci a lEnginyeria del Software

Software Importncia Evoluci Caracterstiques Crisi del software

Enginyeria del Software Definicions Caracterstiques Visi genrica

Paradigmes Cicle de vida clssic Prototipatge Model en espiral

Bibliografia


Evoluci de Costos del Hardware i del Software

1960 70 80 90

100%

HARDWARE

SOFTWARE


1950 60 70 80 90 2000

BatchPoca distribuciA mida

MultiusuariTemps realBases de dadesSoftware de producte

DistirubuciHardware baratSoftware de consum

Sistemes sobretaulaSistemes expertsClcul paral.lelOrientaci a objectes

Evoluci del software


Caracterstiques del software

Es desenvolupa, no es fabrica

No sespatlla

Manteniment ms difcil que el hardware

Es construeix a mida, no es reusa


Fallades H/S

ndexfallades

Hardware

Software

temps


Aplicacions del Software

Sistemes

Temps real

Gesti

Denginyeria

Cientfic

Empotrat

De PC

DIntel.ligncia Artificial


Crisi del software

Crisi? Aflicci crnica !!!

Problemes: Evoluci contnua Insatisfacci dels usuaris Poca qualitat Manteniment difcil

Causes: Naturalesa del software Complexitat Gesti

Mites: De gesti Dels clients Dels dissenyadors


Resultat de projectes de software

USAT2%

USATDESPRSCANVIS

3%ABANDONAT O

REFET19%

LLIURAT, NOUSAT29%

PAGAT, NOLLIURAT

47%


Enginyeria del software

Establiment i s de principis de lenginyeria orientats a obtenirsoftware:

Econmic

Fiable

Que funcioni eficientment

Que satisfaci les necessitats dels usuaris


Un enginyer ...

Disposa dun ventall de tcniques provades que donen resultatsprecisos.

Es preocupa de la fiabilitat i del rendiment.

Tracta de reduir costos i complexitat.

Basa els seus models en teories matemtiques slides.

Construeix prototipus dels nous dissenys.

Utilitza diagrames formals.


El procs de lenginyeria

Formulaci

Anlisi

Generaci

Selecci

Especificaci

Implementaci

Modificaci


Visi genrica de lEnginyeria del Software

Definici: Anlisi del sistema Planificaci del projecte Anlisi de requeriments del software

Desenvolupament: Disseny del software Codificaci Prova

Manteniment: Correcci Adaptaci Millora


Cicle de vida clssic

MANTENIMENT

ENG. SISTEMA

ANLISI

DISSENY

CODIFICACI

PROVA


Prototipatge

ANLISIREQUERIMENTS

DISSENYRPID

PROTO_TIPUS

AVALUACI

REFI_ NAMENT

PRODUCTE


Model en Espiral

Planificaci Anlisi de Risc

Avaluaci Enginyeria


Bibliografia

R.S. PressmanIngeniera del Software: Un enfoque prctico.4a edici.McGraw Hill, 1997. (Cap. 1)

ES:E - Requeriments i Especificacions 1

Requeriments i Especificacions

Determinaci dels requeriments del software Requeriments del sistema versus requeriments del software Etapes Estratgies

Especificacions de sistemes software Requeriments funcionals i no funcionals Propietats desitjables de les especificacions Estndards de documentaci

Bibliografia


Requeriments del sistema vs. requeriments del software

La soluci al problema es pot realitzar amb software, hardware,manualment, o amb una combinaci de tots tres.

Si la soluci s composta, abans de dissenyar els detalls duncomponent software concret, cal dissenyar el sistema global.

Requeriment: Condici o capacitat necessitada per un usuariper tal de solucionar un problema o aconseguir un objectiu

Exemple de sistema compost: refineria automatitzadaExemple de sistema noms_software: control destocs


Etapes de lenginyeria de sistemes

Determinar requeriments del sistema Especificar requeriments del sistema Disseny del sistema

HARDWARE

DeterminarrequerimentsEspecificarrequerimentsDisseny

SOFTWARE PERSONES

enginyeriadel hardware

enginyeriadel software

enginyeria de sistemes


Determinar requeriments del sistema global

Comprensi dels objectius i necessitats de lusuari Definir el conjunt de sistemes que podrien satisfer les necessitats o

objectius i avaluar-los Triar el sistema ms adient

QUIN SISTEMA CAL CONSTRUIR?

MAGATZEM

Sistema que rep i verifica els productes demanatsals provedors, i els emmagatzema als prestatges


Especificar els requeriments del sistema global Descriure el comportament extern del sistema, des del punt de vista de

lusuari, o de lentornQU HA DE FER EL SISTEMA?

albar

1. Comprovar si esperada

2. Comprovar correspondncia

3. Control de qualitat

4. Actualitzar comanda

5. Determinar on va

6. Emmagatzemar

COMANDA APROVEDOR

error

error

defectus

PRODUCTESPRESTATGES

PRODUCTES EN PRESTATGES

ordre


Disseny del sistema Determinar larquitectura general del sistema que millor satisf els

requeriments , en termes de: components fsics: hardware, software, persones comunicaci entre ells

MANUAL

albar

COMANDA APROVEDOR

error

error

defectus

PRODUCTESPRESTATGES

PRODUCTES EN PRESTATGESSOFTWARE

HARDWARE

1. Comprovar si esperada

3. Control de qualitat

4. Actualitzar comanda

5. Determinar on va

6. Emmagatzemar

2. Comprovar correspondncia

ordre


Disseny del sistema

albar

Recepci

Transport

SistemaInformtic

albaravs

ordreerrors

resultatdefectus

comanda


Determinar requeriments del software

s el subconjunt dels requeriments del sistema global que han estatassignats al component software concret

SISTEMAINFORMTICalbar

resultat

avs

ordre

errors

comanda


Especificar els requeriments del software Descriure amb detall el comportament extern del component

software concret

TractarAlbarans

RebreComandes

ActualitzarComandes

EmetreOrdre

albar

error

avs

comanda

comandes

productes

prestatges

resultat

ordre


Determinaci dels requeriments del software:Estratgies

Demanar-ho a lusuari

Treure-ho dun sistema software existent

Sintetitzar-ho a partir del sistema global

Descobrir-ho mitjanant experimentaci


Requeriments del software

Funcionals Descriuen totes les entrades i sortides, i la relaci entre ambdues

de dades de procs

No funcionals Defineixen les qualitats generals que ha de tenir el sistema en

realitzar la seva funci Qualitat Interfcies Rendiment extern Econmics Estructurals Poltics


Factors de qualitat del software

Eficincia Flexibilitat Integritat Mantenibilitat Portabilitat Fiabilitat Actualitat Reusabilitat Testability Usabilitat Interoperabilitat


Eficincia

Flexibilitat

Integritat

Mantenibilitat

Portabilitat

Fiabilitat

Actualitat

Reusabilitat

Testability

Usabilitat

Interoperabilitat

Factors de qualitat del software: conflictes


Propietats desitjables de les especificacions

No ambiges

Completes

Verificables

Consistents

Modificables

Traables

Usables durant loperaci i el manteniment


Com organitzar una especificaci de requeriments?estndard de documentaci ANSI/IEEE

1. Introducci1.1 Propsit de lespecificaci1.2 Abast del producte1.3 Definicions i abreviatures1.4 Referncies1.5 Visi general de lespecificaci

2. Descripci General2.1 Perspectiva del producte2.2 Funcions del producte2.3 Caracterstiques dels usuaris2.4 Restriccions generals2.5 Supsits i dependncies

3. Requeriments especfics4. Apndixos5. ndex


Com organitzar una especificaci de requeriments?estndard de documentaci ANSI/IEEE

3. Requeriments especfics3.1 Requeriments funcionals

3.1.1 Requeriment funcional 13.1.1.1 Introducci3.1.1.2 Entrades3.1.1.3 Tractament3.1.1.4 Sortides

3.1.2 Requeriment funcional 23.2 Requeriments dinterfcies externes

3.2.1 Dusuaris3.2.2 Hardware3.2.3 Software3.2.4 Comunicacions

3.3 Requeriments de rendiment3.4 Restriccions de disseny3.5 Atributs3.6 Altres requeriments


Bibliografia

K.Shumate, M.KellerSoftware Specification and Design - A Disciplined Approach forReal-Time Systems.John Wiley, 1992. (Cap. 3)

A. M. DavisSoftware Requirements - Objects, Functions and States.Prentice-Hall, 1993. (Cap. 1-5)

ES:E - Introducci a lorientaci a objectes 1

Introducci a lorientaci a objectes

Motivaci i orgens

Visi dun sistema software Aspecte esttic Aspecte dinmic

La notaci UML


Motivaci

- Aparici dels llenguatges de programaci orientats a objectes.SIMULA: finals dels 1960'sSMALLTALK: principis dels 1970's

- L's d'aquests llenguatges requereix un nou enfocament d'anlisi ide disseny.

- Altres factors:Desenvolupament de noves aplicacionsmfasi principal en l'estructura de dades

Aparici dels primers mtodes d'anlisi i de dissenyorientats a objectes


Fusion

Processos i ModelsRecomanats

OOSE

BOOCH

OMT UML

Martin-Odell

Shlaer &Mellor

Orgens

Rumbaugh, Blaha, Premerlani (OMT) - 1991Coad, Yourdon - 1991Shlaer, Mellor - 1992Booch - 1992Odell, Martin - 1992Jacobson (OOSE) - 1993Fusion - 1994Booch, Rumbaugh, Jacobson (UML) - 1997


Visi dun sistema software


Objectes

Objecte:Entitat que existeix al mn realTenen identitat i sn distingibles entre ells

l'avi ambmatrcula 327

una poma un semfor

l'avi ambmatrcula 999

la factura 3443


Classes dobjectes

Abstracci: eliminar distincions entre objectes per a poder observaraspectes comuns

classe aviabstracci

Els objectes d'una classe tenen les mateixes propietats i elsmateixos patrons de comportament

Classe d'objectes: descriu un conjunt d'objectes amb:- les mateixes propietats- comportament com- idntica relaci amb altres objectes- semntica comuna

Avi


Atributs

Atribut: s una propietat compartida pels objectes d'una classe.

Exemples:Persona => nom, adrea, telfon, ...Avi => model, capacitat, color, ...

- Cada atribut t un valor (probablement diferent) per cadainstncia d'objecte

- Els atributs poden ser bsics o derivats

PersonaNomAdreaTelfonData_naixementEdat

AviModelCapacitatColor


Operacions (I)Operaci: s una funci o transformaci que es pot aplicar als

objectes d'una classe.

- Les operacions d'un objecte sn invocades pels altres objectes

Mtode: especificaci procedural (implementaci) d'una operaci dinsd'una classe.

Encapsulament: consisteix a separar els aspectes externs d'un objectedels detalls d'implementaci.

PersonaNomAdreaTelfonCanvi_adreaCanvi_feina

AviModelCapacitatColorsRepararMoure


Operacions (II)

- En les operacions, cal indicar tamb el tipus dels arguments i del resultat.

Polimorfisme:

- una mateixa operaci es pot aplicar a diferents classes- la seva implementaci depn de cada classe

TriangleColorPosici

Girar (angle)seleccionar (p:Punt):Boole

QuadratColorPosici

Girar (angle)


Associacions

Associaci:defineix la manera d'enllaar o connectar objectes dediferents classes

Exemple: Un pas t una nica capital.

t_capitalPas

NomHabitants

Ciutat

NomHabitants


GeneralitzaciGeneralitzaci: s l'acte o resultat de distingir un concepte que s

ms general que un altre

Herncia: permet que l'estructura de dades i les operacions d'una classesiguin accessibles a una subclasse

EmpleatNomSouContractarPagar_souJubilar

DirectiuPerode contracteDesp. autor.Autoritzar despesesJubilar

ViatjantRegiQuotaAssignar regiAssignar quota

. . .

Especialitzaci Generalitzaci


Orientaci a objectes (I)

Aspecte esttic: descriu l'estructura esttica dels objectes del sistemai les seves interrelacions

Intra - objecte Inter - objectes

Aspecteesttic

Classes dobjectesAtributsOperacions

AssociaciGeneralitzaci...


Descripci del comportament (I)Els objectes es comuniquen mitjanant la invocaci doperacionsdaltres objectes


Descripci del comportament (II)

Hi ha molta divergncia entre els mtodes actuals a l'hora de tractarl'aspecte dinmic

L'aspecte dinmic d'un sistema descriu:- Interaccions entre els objectes- Possibles estats d'un objecte- Transicions entre estats

- Quins esdeveniments es produeixen- Quines operacions s'executen

Aspecte dinmic (de comportament): descriu els aspectes d'un sistemaque canvien amb el temps


Descripci del Comportament (III)

Soltera

casament

Casada

Vdua

divorci

Divorciada

neixement

Separada

enviudarseparaci

enviudar

divorci

casament casament

Diagrama de transici destats: especifica el canvidestat dun objecte causat pels esdevenimentsExemple: estat civil duna persona


Descripci del comportament (IV)

Esquema d'esdeveniments: permet especificar la interacci entrediferents objectes (usat pel mtode de Martin i Odell [MO92])

Acceptarcomanda

Prepararcomanda

Lliurarcomanda

Enviarfactura

Client pagafactura

Tancarcomanda

Client enviacomanda

comandaacceptada

comandapreparada

facturaenviada

facturapagada

comandalliurada

comandatancada


Orientaci a objectes (II)Aspecte esttic: descriu l'estructura esttica dels objectes del sistema

software i les seves interrelacions

Aspecte dinmic (de comportament): descriu els aspectes dunsistema software que canvien amb el temps

Intra - objecte Inter - objectes

Aspecteesttic

Classes dobjectesAtributsOperacions

AssociaciGeneralitzaci...

Aspectedinmic

Diagrama detransici destats

Esquemadesdeveniments


Anlisi i disseny orientats a objectesAnlisi:

- Creaci duna especificaci del problema i dels requeriments- Qu ha de fer el sistema software

Susen els mateixos conceptes a lanlisi i al disseny

s difcil determinar on acaba l'anlisi orientada a objectes i oncomena el disseny:

- estratgia de desenvolupament iterativa- diferncies de criteris segons els autors

Disseny:- definici duna soluci software que satisfaci els requeriments- Com ho far el sistema

orientats a objectes


El llenguatge UML (Unified Modeling Language)

Setembre 97 - Publicaci de lUML 1.1

Gener 97 - Publicaci de lUML 1.0

Juny 96 & Octubre 96

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

Industrialitzaci

Standaritzaci

Unificaci

Fragmentaci

UML PartnersExpertise

publicfeedback


El triangle de lxit

Notaci

Procs(metodologia) Eina

Rational RoseCraig Larman

U.M.L.


ModelDAnlisi

ModelConceptual

Casos ds- nivell alt- essencial

Diagramesde Casos ds

DiagramesEsttics dEstructura pels Objectesdel Domini

Diagrames deseqnciadel sistema

DiagramesdEstat perObjectes iCasos ds

Model deCasos ds

Model delcomportamentdel sistema

Model delsEstats

Contractesper lesoperacionsdel sistema

Model dAnlisi (especificaci)

ES:E - Model Conceptual en UML 1

Introducci Objectes i classes dobjectes Atributs Associacions Classe associativa Generalitzaci/Especialitzaci Agregaci i composici Ampliacions Exemples

Model Conceptual en UML


ModelDAnlisi

ModelConceptual






Model deCasos ds


Model delsEstats




Es la representaci dels conceptes (objectes) significatius enel domini del problema.

Mostra, principalment: Classes dobjectes. Associacions entre classes dobjectes. Atributs de les classes dobjectes.

Model Conceptual


Objectes

Objecte:Entitat que existeix al mn realTenen identitat i sn distingibles entre ells

l'avi ambmatrcula 327 una poma un semfor

l'avi ambmatrcula 999la factura 3443


Classe dobjectes

Abstracci: eliminar distincions entre objectes per a poderobservar aspectes comuns

classe aviabstracci

Els objectes d'una classe tenen les mateixes propietats i elsmateixos patrons de comportament

Classe d'objectes: descriu un conjunt d'objectes amb:- les mateixes propietats

- comportament com

- idntica relaci amb altres objectes- semntica comuna

Avi


TPV producte supermercat venda

caixer client director

pagament catleg especificacide producte

linia de venda

Diagrama de classes


Es una propietat compartida pels objectes duna classe

TPV producte supermercat venda

caixer client director

pagament catleg especificacide producte

linia de venda

adrea: Adreanom: Text

data: Datehora: Time

quantitat: integer

import: Quantitat descripci:Textpreu: Quantitatupc:UPC

Atributs

Els atributs:- Poden prendre valors nuls- Poden ser multivaluats


Es la representaci de relacions entre dos o ms objectes

- direcci de lectura

Persona Ciutat

- nom dassociaci

Viu a

Associacions


Associacions dordre superior a dos

Es matricula

Assignatura Quadrimestre

Alumne


A B1

A B1..*

A B*

A B0..1

A B0..*

A B2..5

A B2, 5

A B1..3,7..10,15..*

Associacions - Multiplicitat

A B

C

1..* 1

0..2

Defineix quantes instncies duna classe A es poden associar amb unainstncia de la classe B en un moment de temps determinat


Cada extrem duna associaci es un rol, que t diverses propietats com:- nom- multiplicitat

El nom de rol identifica un cap de lassociaci i descriu el paper jugat pels objectes en lassociaci.

Vola cap a* 1destinaciVol Ciutat

Nom de RolDescriu el Rol d una ciutaten lassociaci vola cap a

Nom de rol a les associacions


Associacions recursives

Associacions en les que una mateixa classe dobjectes hi participa ms duna vegada (amb papers diferents o no)

Persona

pare fill*0..2

Crea

Persona**

T per amic


Representa una associaci que es pot veure com una classeClasse associativa

Classe associativaEls atributs fan referncia a lassociaciLa seva vida depn de lassociaci

Estudiantnomcrdits

EstMatriculat Assignaturaadreanom * *

Matrculanota

Empresanomadrea

Emplea Persona

* *

Contractesou


Exemple classe associativa

ha_viatjatPersona Ciutat

Viatge sha allotjat Hotel

* *

* *

Incorrecte:

viatjaPersona Ciutat

Hotel

* *

*

(Hi ha viatges sense allotjament en hotel)

(Si una persona P haviatjat algun cop a una ciutat C, existeix una ocurrncia de lassociaci ha_viatjat)


Generalitzaci/Especialitzaci

Persona

Home Dona

E G

supertipus

subtipus

Identificar elements comuns entre els objectes definint relacions de supertipus(objecte general) i subtipus (objecte especialitzat).

sexe {disjoint, complete}

disjoint - Un descendent no ho pot ser en ms duna subclasseoverlapping - Un descendent pot ser de ms duna subclassecomplete - Shan especificat totes les subclassesincomplete - La llista de subclasses s incompleta

discriminador - Es el nom de la partici. Ha de ser nic entre elsatributs i rols de la superclasse


Permet entendre els conceptes en termes ms generals, refinats iabstractes.Fa els diagrames ms expressius.

Tots els membres del subtipus sn membres del supertipus. El 100% de la definici del supertipus ha de ser aplicable

al subtipus. - atributs - associacions(- operacions)

quantitat: Diners

Pagamenten metl.lic

Pagamenta crdit

Pagamentamb tal

PagamentVendaPaga per



Motivacions per particionar un tipus en subtipus El subtipus t atributs addicionals. El subtipus t associacions addicionals. El subtipus s tractat o manipulat de forma diferent daltres subtipus. El subtipus es comporta de manera diferent del supertipus o dels altres subtipus.

Quantitat: Diners

Pagamenten metl.lic

Pagamenta crdit

Pagamentamb tal

Pagamentassociacionsaddicionals

Tarja Tal

*

1 1

Venda11

Atributs i associacions comunes

Cada pagament estracta diferent

Paga per

Pagat ambIdentifica crdit



Quantitat: Diners

Pagamenten metl.lic

Pagamenta crdit

Pagamentamb tal

Pagamentassociacionsaddicionals

Tarja Tal

*

1 1

Venda11

Atributs i associacions comunes

Cada pagament estracta diferent

Paga per

Pagat ambIdentifica crdit

Generalitzaci/EspecialitzaciMotivacions per definir un supertipus: Els subtipus potencials representen variacions dun mateix concepte. Els subtipus tenen atributs que poden ser factoritzats i expressats als supertipus. Els subtipus tenen associacions que poden ser factoritzades i relacionades amb el supertipus.


Lagregaci s un tipus dassociaci usada per modelar relacions part-tot entreobjectes.El tot sanomena composat i les parts components

* *

Ruta Segment

*Men ReceptaUsa 1..*

Agregaci

Cont

La distinci entre associaci i agregaci s sovint subjectiva.Lnica restricci que afegeix lagregaci respecte lassociaci s que les cadenesdagregacions entre instncies dobjectes no poden formar cicles.

A B

C

A1

B1 B2

C1 C2 C3

* *

*

*

*

*

A2 A3 A4


La composici s un tipus dagregaci per la qual:

- La multiplicitat del cap compost pot ser com a mxim 1 (com a mxim uncomposat posseeix un component)

- Si un component est associat a un composat i el composatsesborra aleshores el component tamb sha desborrar (no el potsobreviure)

Composici

1 0..5M Dits

1 0..*Venda LniadeVenda

0..1Catleg Especificaci

de Producte1..*

Cont

Cont

T


Agregaci/Composici Existeix un assemblatge tot-part fsic o lgic. Algunes propietats del tot es propaguen a les parts (com destrucci, moviment, ...)

Agregaci i composici - quan mostrar-la

Composici La vida de la part est inclosa en la vida del composat. Existeix una dependncia crear-esborrar de la part respecte delcomposat.


Informaci derivada

Atribut derivat

Associaci derivada

Una constraint (regla de derivaci) ha despecificar com es deriva

Un element (atribut o associaci) s derivat si es pot calcular a partir daltres elements.Sinclou quan millora la claredat del model conceptual

DepartamentEmpleat

Tnom/nombre_empleats

* *

CiutatEst situat a

Departament

Empleat

1*

T /Treballa a

1

*

1

*


La multiplicitat de classe estableix el rang de possibles cardinalitats per lesinstncies duna classePer defecte, s indefinidaEn alguns casos, per, s til establir una multiplicitat finita, especialment encasos de classes que poden tenir una sola instncia (i que sanomenensingleton)

Multiplicitat de classe

La Puntual, S.A.

NIFadrea

1

- multiplicitat de classe


Altres restriccions sobre associacions

XorUneix diverses associacions lligades a una mateixa classe bsicaUna instncia de la classe bsica participa exactament en una de les associacions unidesper xor.

SubsetIndica que una associaci s un subconjunt duna altra associaci

A part de la multiplicitat, s possible expressar altres restriccions sobre les associacions:- Xor- Subset

Persona

Compte

Empresa

{xor}

*

*

*

1

compte per

compte emp

persona propietria

empresa propietria

Comissi

Pertany a

Persona**

Presideix1 *

{subset}


La canviabilitat indica si els valors dun atribut o lextrem duna associaci podencanviar o no

Canviabilitat

Canviable (changeable) - opci per defecte -

Congelat (frozen)telfon i ciutat-res sn canviables

data-naix i ciutat-naix sn congelats

Noms-afegir (addOnly)

ttol-acad i ciutat-res sn noms-afegir

PersonaCiutat

Viu a

ciutat-res{changeable}

residenttelfon {changeable}**

CiutatVa nixer a

ciutat-naix{frozen}

per-nascuda*

1Persona

data-naix {frozen}

CiutatHa residit a

ciutat-res{addOnly}

resident* *

Personattol-acad {addOnly}


Classificaci mltiple

Persona

Home Dona

Variant de generalitzaci/especialitzaci en la qual una superclasse pot tenirdiverses jerarquies despecilitzaci en funci de diferents discriminadors

sexe

{disjoint, complete}

Soltera Casada Divorc. Vdua

estat



Herncia mltiple

Estudiant

EstUPC EstUAB

Variant de generalitzaci/especialitzaci en la qual una subclasse t msduna superclasse

EstUB Inform. Mates Empres.

InformUPC

estudis{disjoint, incomplete}

universitat{disjoint, incomplete}

Noms es pot utilitzar si no hi ha conflictes dherncia


Equivalncies notacionals (1)

Polgonnombre_costats

Triangle Rectangle Pentgon . . .

Polgon

Triangle Rectangle Pentgon . . .

En UML:

s equivalent a:

Problema?


Equivalncies notacionals (2)

En UML:

s equivalent a:

Classe_Teoria*

Docncia_Assignatura

*

Classe_Probl Classe_Lab*

1 1 1

Classe_Teoria*

Docncia_Assignatura

*

Classe_Probl Classe_Lab*

1


Exemples Quina soluci s millor?

Persona_UPCnomnum-assignaturessou amb valors nuls

nom

Estudiant Empleat

Persona_UPC

num-assignatures sou

sense valors nuls

tipus {overlapping, incomplete}


Exemples Quina soluci s millor?

Persona_UPCnomtelfon

amb valors nuls

nom

Persona_amb_telfon

Persona_UPC

sense valors nuls

telfon

tenir_telfon


Exemples

Un atribut no pot prendre valors duna de les classes del model conceptual

Aquest cas s una associaci

Empleatnom: Textproj_emp: Projecte

Projectecodi_proj: Textdescripcio: Text

Empleatnom: Text

Projectecodi_proj: Textdescripcio: Text

**

Treballa a


Bibliografia

The Unified Modeling Language User GuideG. Booch, J. Rumbaugh, I. JacobsonAddison-Wesley, 1999

En castell:

El Lenguaje Unificado de ModeladoG. Booch, J. Rumbaugh, I. JacobsonAddison-Wesley, 1999

The Unified Modeling Language Reference ManualJ. Rumbaugh, I. Jacobson, G.BoochAddison-Wesley, 1999

Applying UML and PatternsAn Introduction to Object-Oriented Analysis and DesignC. LarmanPrentice-Hall 1998Cap. 9, 10, 11, 28, 30

ES:E -Object Constraint Language 1

Object Constraint Language (OCL)

Per qu serveix? Propietats del Model Conceptual Col.leccions: conjunts, bosses i seqncies Navegaci per classes associatives Generalitzaci / Especialitzaci Com especificar en OCL


Per qu serveix OCL?

Els models grfics no sn suficients per a una especificaci precisa i noambigua

LOCL: s un llenguatge formal permet definir expressions (no t efectes laterals) no s un llenguatge de programaci

Susa per: especificar invariants (restriccions) del Model Conceptual com a llenguatge de navegaci (especificar restriccions en les operacions)


Exemple

PersonadataNaixement : Datanom : Stringcognom : Stringsexe : enum{home,dona}/estCasat : Boolean/estaturat : Boolean/edat : Integer

esposa

esps 0..10..1

director

empleat

empresesDirigides

contractador

Empresa

nom : String/nombredEmpleats: Integer

0..* 0..*

0..*

Casamentlloc : Stringdata : Data

Treballttol : StringdatadInici: Datasalari : Integer

1


Propietats dels objectes Una expressi OCL fa referncia a les propietats dels objectes especificats

al Model Conceptual Una propietat pot fer referncia a:

atributs duna classe dobjectes navegaci a travs de les associacions

Propietats dels atributs duna classe dobjectes: Propietat: edat duna persona -- enter

Personalexpressi ha de ser certa per a totesles instncies de la classe

self.edatinstncia contextual de lexpressi (punt de partida)

Restricci de la propietat: ledat de les persones ha de ser superior o igual azero

Persona o, alternativament: p:Personaself.edat >= 0 p.edat >= 0


Propietats dels objectes (II)Propietats duna navegaci a travs dassociacions:

Partint dun objecte concret, podem navegar a travs de les assocciacions delModel Conceptual per referir-nos a daltres objectes i a les seves propietats

Com es navega? Objecte.nom-de-rol

objecte de partida nom de rol duna associaci de lobjecte

Resultat: conjunt dobjectes de l al tre extrem de nom-de-rol si no hi ha nom de rol especificat, es pot usar el nom de la classe dobjectes de laltre extrem

de lassociaci (amb minscules) Exemples de navegaci:

Empresaself.director -- director de lempresa -- Personaself.director.nom -- nom del director -- Stringself.empleat -- empleats de lempresa -- set(Persona)self.empleat.esps -- esposos dels empleats -- set(Persona)


Col.leccions: conjunts, bosses i seqnciesUna col.lecci delements pot ser del tipus: Conjunt: cada element ocorre una nica vegada a la col.lecci Bossa (multiconjunt): la col.lecci pot contenir elements repetits Seqncia: bossa on els elements estan ordenats

Exemple: nombre de treballadors que treballen per a una persona

Personanum-treb = self.empresesDirigides.empleat -> sizeIncorrecte: el resultat s una bossa i pot contenir repetits.Persona num-treb = self.empresesDirigides.empleat -> asSet -> size

Regles de navegaci: si la multipl icitat de lassociaci s 1 el resultat s un objecte o un conjunt dun nic

objecte. si la multipl icitat de lassociaci s >1 el resultat s una bossa, encara que, de

vegades, pot ser un conjunt


Operacions bsiques sobre col.leccions (I)Select: especifica un subconjunt de la col.lecci

persones majors de 50 anys que treballen a una empresaEmpresa

self.empleat -> select(edat>50)Empresa

self.empleat -> select(p | p.edat>50)Empresa

self.empleat -> select(p:Persona | p.edat>50)

Collect: especifica una col.lecci que es deriva duna altra, per que contobjectes diferents

edats (amb repetits) dels empleats duna empresaEmpresa

self.empleat -> collect(dataNaixement)versi simplificada: self.empleat.dataNaixement


Operacions bsiques sobre col.leccions (II)

forAll: expressi que han de satisfer tots els elements tots els empleats de lempresa sanomenen JackEmpresa

self.empleat -> forAll(nom=Jack)

Exists: condici que satisf almenys un element com a mnim un empleat de lempresa sha de dir JackEmpresa

self.empleat -> exists(nom=Jack)


Combinaci de propietats

Les propietats es poden combinar per formar expressions ms complexes Les persones casades han de ser majors dedat

Personaself.esposa -> notEmpty implies self.esposa.edat >= 18and self.esps -> notEmpty implies self.esps.edat >= 18

Una empresa t com a mxim 50 empleatsEmpresa

self.empleat -> size size=1) and (self.esps -> size=1)

definici de latribut derivat nombredEmpleats Empresa

nombredEmpleats = (self.empleat -> size) definici de latribut derivat estaturat

Personaestaturat = if self.contractador-> isEmpty then true else false


Navegaci per classes associatives

Navegaci a una classe associativa:Es fa servir el nom de la classe associativa (amb minscula)

els sous de les persones que treballen a la UPC han de ser ms alts que 1000Persona

(self.contractador -> select(nom=UPC)).treball)-> forAll (t | t.salari > 1000)

Navegaci des duna classe associativa:Susa el nom de rol de lextrem cap on es vol navegarSi no sha especificat nom de rol, susa el nom de la classe.

les persones que treballen no poden estar aturadesTreball

self.empleat.estaturat = false un casament ha de ser entre una dona i un home

Casamentself.esposa.sexe = #dona and self.esps.sexe = #home


Generalitzaci - Especialitzaci (herncia)

Avantatges: Les propietats de les subclasse es poden ignorar

Compte corrent self.transacci -> select(data.isafter(5-4-1998)) -- transaccions dun compte posteriors al 5-4-1998

Accs directe a les propietats de la superclasseIngrs self.compte-corrent.num-cc -- nmero de compte dun ingrs

Aspectes addicionals: Selecci dobjectes que pertanyen a la subclasse

Compte correntself.transacci -> select(oclType=Ingrs) -- ingressos dun compte

Accs a les propietats definides al nivell de subclasseCompte corrent

self.transacci.oclasType(Extracci).persona -> asSet -- persones que han tret diners dun compte corrent

Transaccidata: Dataquantitat: Integer

Extraccipersona: String

Ingrsc-oficina: Integer

Compte correntnum-cc: Integerentitat: String

efectua1 *



Com especificar en O.C.L. Una expressi O.C.L sespecifica sempre comenant en una classe

dobjectes determinada: instncia contextual Una expressi es pot especificar de diverses maneres, segons la instncia

contextual de partida:Persona

self.esposa -> notEmpty implies self.esposa.edat >= 18 andself.esps -> notEmpty implies self.esps.edat >= 18

Casamentself.esposa.edat >= 18 and self.esps.edat >= 18

Indicacions per escollir la instncia contextual si la restricci restringeix el valor de latribut duna classe, aquesta s la classe

candidata si la restricci restringeix el valor dels atributs de ms duna classe, qualsevol

daquestes ns la candidata qualsevol restricci hauria de navegar a travs del menor nombre possible

dassociacions


Com especificar en OCL: exemples Totes les persones han de ser majors dedat

Personaself.edat >= 18 -- s preferible a

Empresaself.empleat -> forAll (age >= 18)

Els dos membres dun matrimoni no poden treballar a la mateixa empresaEmpresa

self.empleat.esposa -> intersection(self.empleat) -> isEmpty -- s preferible aPersona

self.esps.contractador -> intersection(self.contractador) -> isEmptyandself.esposa.contractador -> intersection(self.contractador) -> isEmpty

Ning no pot ser director i empleat duna empresaEmpresa

not(self.empleat -> includes(self.director))Persona

not(self.empresesDirigides.empleat -> includes(self))-- quina s preferible en aquest cas?


Operacions estndard de tipus boole

Operaci Notaci Resultat

or a or b booleand a and b booleor exclusiu a xor b boolenegaci not a booleigualtat a = b booledesigualtat a b booleimplicaci a implies b booleif-then-else if a then b else b tipus de b o b


Operacions estndard de tipus string

Operaci Notaci Resultat

concatenaci string.concat(string) stringtamany string.size integersubstring string.substring(int,int) stringigualtat string1 = string2 booledesigualtat string1 string2 boole


Operacions estndard de tipus col.lecci

Operaci Resultat

size nombre delements de la col.leccicount(object) nombre docurrncies de lobjecteincludes(object) cert si lobjecte pertany a la col.lecciincludesAll(collection) cert si els elements del parmetre collection sn a la

col.lecci actualisEmpty cert si la col.lecci s buidanotEmpty cert si la col.lecci no s buidasum() suma de tots els elements (els elements shan de poder sumar)exists(expression) expression s cert per algun element?forAll(expression) expression s cert per tots els elements?select(expression) selecciona el subconjunt delements per als quals expression

s certreject(expression) elimina el subconjunt delements per als quals expression s certunion(collection) resultat dunir les dues col.leccionsintersection(collection) resultat de la intersecci


Bibliografia

Unified Modeling LanguageObject Constraint Language Specification, v. 1.1.Setembre 1997.

J.Warmer; A.KleppeThe Object Constraint Language: precise modeling with UMLAddison-Wesley, 1999.

Pgines web amb informaci dOCL:

http://www.software.ibm.com/ad/ocl http://www.rational.com http://www.omg.org

ES:E - Model de Casos ds en UML 1

Propsit Casos ds Diagrama de Casos ds Especificaci de Casos ds Estructuraci de Casos ds Identificaci de Casos ds

Model de Casos ds en UML


ModelDAnlisi

ModelConceptual






Model deCasos ds


Model delsEstats




Determinaci de requeriments dun sistema software:

Identificar i categoritzar les funcions del sistema (requeriments funcionals). Identificar i categoritzar els atributs del sistema (requeriments no funcionals). Relacionar els requeriments no funcionals amb els funcionals.

Especificaci dels requriments dun sistema software

Comprensi dels requeriments. Organitzar els requeriments segons les funcions del sistema. Delimitar la frontera del sistema.

Model de Casos ds: Quines son les funcions del sistema PER CADA ACTOR? mfasi: USOS del sistema, valor afegit per cada actor


Casos dsCas ds: Document que descriu una seqncia desdeveniments que

realitza un actor ( agent extern ) que usa el sistema per dur a terme un procs que t algun valor per a ell [Jacobson 92].

Extracci dediners en

caixer

Actor: Entitat externa al sistema que participa en la histria del Cas ds. Pot ser una persona, un conjunt de persones, un sistema hardware, un sistema software o un rellotge.Iniciador: Genera lestmul que provoca lexecuci del procs (nic).Participant: Interv en el procs.


Cas ds 1

ActornActor1

Nom del sistema

Cas ds 2

Cas ds i

Entorn del sistema

Comunicaci

Diagrama de Casos ds

Mostra conjuntament els diferents casos ds dun sistemasoftware, els actors i les relacions entre actors i casos ds.


Especificaci de Casos dsDalt nivell: Descripci breu de les accions del cas ds.

Cas ds: Nom del cas ds.Actors: Llista dactors, iniciador.Propsit: Objectiu del cas ds.Resum: Descripci breu de les activitats que shan de dur a terme.Tipus: 1 - primari, secundari, opcional.

2 - real o essencial.

Expandida: Descripci detallada de les accions i els requeriments.Afegeix a lespecificaci dalt nivell:

Referncies creuades: Requeriments a qu fa referncia.Curs tpic desdeveniments: Descripci detallada de la interacci

(conversa) entre els actors i el sistema.Descripci dels esdeveniments pas a pas.

Cursos alternatius: Descriu excepcions al curs tpic.


Exemple: Terminal de Punt de Venda

Un terminal de punt de venda (TPV) s un sistema computeritzat usat per enregistrarles vendes i gestionar pagaments. Susa, principalment en supermercats i gransmagatzems. Inclou components hardware (com lordinador i lscanner del codi de barres) i software per executar el sistema.Sens demana que especifiquem el software daquest sistema.


Exemple TPV: Funcions bsiquesRef # Funci CategoriaR1.1 Enregistrar la venda actual - els productes comprats. evidentR1.2 Calcular el total de la renda actual, incloent impostos i clcul de evident

punts de client.R1.3 Capturar la informaci dels productes comprats dun codi de barres, evident

usant un scanner o b a partir de lentrada manual del codi de barres(Universal Product Code).

R1.4 Descomptar les quantitats venudes de lestoc, quan la venda es confirmi. hiddenR1.5 Guardar informaci sobre les vendes realitzades. hiddenR1.6 El caixer ha didentificar-se en iniciar una sessi amb un identificador evident

i una clau daccs.R1.7 Mostrar la descripci i el preu de cada producte comprat. hiddenR2.1 Tractar els pagaments en efectiu capturant la quantitat entregada evident

pel client i calculant el canvi.R2.2 Tractar els pagaments amb tarja de crdit capturant el nmero de la evident

tarja des dun lector de targes o manualment, demanar confirmacidel pagament al servei dautoritzaci de crdit (extern) amb unaconnexi via modem.

R2.3 Enregistrar els pagaments amb tarja per tal que puguin ser facturats. hidden


Example TPV: Diagrama de Casos ds

Terminal Punt de Venda

Directorcomercial

Caixer

Responsablede compres

Iniciar Sessi

Compra de productes

Acabar Sessi

Fixar Preus

Comprar a provedors

Fer ofertes

Retornar producte

Provedor

Client


Exemple TPV: Entorn del sistema

Compra deproductes

CLIENTCAIXER Retornarproducte

Iniciarsessi

TPV

Compra deproductes

CLIENTRetornarProducte

supermercat


Cas ds: Compra de productes en efectiu.Actors: Client (iniciador), Caixer.Propsit: Capturar una venda i el seu pagament en efectiu.Resum: Un client arriba a la caixa amb productes per comprar.

El caixer enregistra els productes i recull el pagament.En acabar, el client sen va amb els productes.

Tipus: Primari i essencial.Referencies creuades: R1.1, R1.2, R1,3, R1.7, R2.1

Curs tpic desdeveniments

Accions dels Actors

1. El cas ds comena quan un client arriba a la caixa amb els productes per comprar.2. El Caixer indica que comena una nova venda4. El Caixer enregistra lidentificador de cada producte. Si hi ha ms duna unitat del producte el Caixer pot entrar la quantitat.6. En acabar lentrada de productes el caixer ho indica.

Resposta del sistema

3. Dna la venda per iniciada5. Determina el preu del producte i afegeix la seva informaci al compte.

7. Calcula i mostra el total del compte.

Exemple TPV: especificaci del cas ds compra de productes en efectiu

(continua)


Cursos Alternatius

Linia 4: Sentra un identificador de producte invlid. Indicar error. Linia 9: El Client no t prous diners. Cancel.la la venda.

Accions dels Actors

8. El Caixer li diu el total al client. 9. El Client entrega una quantitat de diners possiblement ms gran que el total del compte.10. El Caixer indica els diners que ha rebut.13. El Caixer diposita els diners rebuts a la caixa i extreu el canvi. El Caixer dna el canvi i el rebut al client.14. El Client sen va amb els productes comprats.


11. Calcula i mostra el canvi al Client. Imprimeix un rebut.12. Enregistra la venda que sacaba de fer.


Curs tpic desdeveniments Accions dels Actors

1. El cas ds comena quan un client arriba a la caixa amb els productes per comprar.2. (passos intermedis exclosos)...9. El Client escull la forma de pagament: a. If en efectiu, see section pagar en efectiu b. If amb tarja see section pagar amb tarja

12. El Caixer dna el rebut al client.13. El Client sen va amb els productes comprats.

Estructuraci de Casos ds: seccions


10. Enregistra la venda que sacaba de fer.11. Imprimeix un rebut.

Cas ds: Compra de productes


Section: Pagar en efectiu.

Curs tpic desdeveniments

Accions dels actors

1. El Client entrega una quantitat de diners possiblement ms gran que el total del compte.2. El Caixer indica els diners que ha rebut.4. El Caixer diposita els diners rebuts i extreu el canvi. El Caixer dna el canvi al client.

Estructuraci de Casos ds: seccions


3. Calcula i mostra el canvi al Client.

Cursos Alternatius

Linia 4: Efectiu insuficient per tornar el canvi. Demanar canvi al supervisor.

Section: Pagar amb tarja.

Cursos tpics i alternatius per lhistria del pagament amb tarja.


Estructuraci de Casos ds: Relaci Usa

Usa: Relaci dun cas ds concret amb un dabstracte, en la qual la conducta definida pel cas concret usa (empra) la conducta definida en labstracte.

Permet reduir la redundncia quan una seqncia daccions s compartida per diversos casos ds

Pagar amb tarjaCompra de productesCaixer

Client

Cas ds Real

Caixer ClientCompra de productes + Pagar amb tarja


Exemple TPV: Usa

Comprarproductes

Pagar enefectiu

Pagar ambtarga

Retornar producte

Caixer Client

Comptabilitat

Servei dautoritzaci

de crdit

Accions dels Actors

1. El cas ds comena quan un client arriba a la caixa amb els productes per comprar. 2. (Passos intermedis exclosos)... 9. El Client escull el tipus de pagament: a. If s en efectiu initiate

Pagar en efectiu b. If s amb targa initiate

Pagar amb tarja12. El Caixer dna el rebut al client.13. El client sen va amb els productes comprats


10. Enregistra la venda que sacaba de fer.

11. Imprimeix un rebut.


Estructuraci de Casos ds: Relaci Estn

Estn: Relaci dun cas ds a un altre especificant com la conducta definida pel primer pot sser inserida en la conducta definida pel segon. Tamb es pot dir que el primer s semblant al segon, per fa una mica ms.

Una extensi es comporta com si fssin accions que safegeixen en un punt concret de lespecificaci original si es dna una certa condici

Matricular estudiantMatricular Erasmus

Estudiant


Identificaci de casos ds

Mtode basat en els actors

1. Identificar els actors relatius al sistema.2. Per cada actor, identificar els processos que inicia

o en els quals participa.

Mtode basat en els esdeveniments

1. Identificar els esdeveniments externs als que el sistema ha de respondre.

2. Relacionar els esdeveniments amb els actors i casos ds.


Casos ds essencials versus casos ds reals

Essencialmolt abstracte

Realmolt concret

Essencial

Acci de lactor Resposta del sistema1. El client sidentifica. 2. Presenta opcions3. Etc... 4. Etc...

Real

Acci de lactor Resposta del sistema1. El client insereix la tarja. 2. Demana el PIN3. Entra el PIN al teclat 4. Mostra el men dopcions5. Etc... 6. Etc...


Bibliografia

C. LarmanApplying UML and Patterns.An Introduction to Object-Oriented Analysis and Design.Prentice Hall, 1998. (Cap. 6)

I.Jacobson, G.Booch, J.RumbaughThe Unified Software Development ProcessAddison-Wesley, 1999. (Cap. 6,7)

ES:E - Model del Comportament en UML 1

Model del comportament en UML

Introducci Diagrames de seqncia del sistema Contractes de les operacions del sistema Altres consideracions

Compartici dinformaci entre les operacions dun diagrama Informaci elemental vs informaci composta Nombre desdeveniments del diagrama de seqncia Redundncia entre els models

Bibliografia


ModelDAnlisi

ModelConceptual






Model deCasos ds


Model delsEstats


Model dAnlisi (Especificaci)


Descripci del comportament en OO

Els objectes es comuniquen mitjanant la invocaci doperacionsdaltres objectes


Especificaci del comportament en OO

SISTEMA

Considerem un tipus especial sistema que engloba tots els objectes Lespecificaci del comportament es fa amb el model del comportament delsistema


Model del comportament del sistema

Diagrames de seqncia del sistema: Mostren la seqncia desdeveniments entre els actors i el sistema. Permeten identificar les operacions del sistema

Contractes per les operacions del sistema:

Descriuen lefecte de les operacions del sistema


Diagrames de seqncia del sistema

Objectius: identificar els esdeveniments i les operacions del sistema

Punt de partida: casos ds la descripci dels diagrames de seqncia del sistema s posterior a la

descripci dels casos ds Casos ds:

descriuen com els actors interaccionen amb el sistema software lactor genera esdeveniments cap al sistema que exigeixen lexecuci

dalguna operaci com a resposta (durant la interacci) a partir dels casos ds podem identificar quins sn els esdeveniments

que van dels actors cap al sistema

diagrames de seqncia del sistema


Diagrames de seqncia del sistema

Mostra, per a un escenari particular dun cas ds : els esdeveniments generats pels actors externs el seu ordre els esdeveniments interns al sistema (operacions) que resulten de la

invocaci

Definirem un diagrama de seqncia per cada curs rellevantdesdeveniments dun cas ds


Exemple: comprar producte

:Caixer :Sistema

iniciVenda(pv)

*

:venda

entrarProd(venda,prod,quant)

fiVenda(venda):import

pagament(venda,importPag):canvi

sistema com a caixa negra actor

esdev. del sistemainvoca operaci


Construcci dun diagrama de seqncia

1. Dibuixar una lnia vertical que representa el sistema2. Dibuixar una lnia per cada actor que interacciona directament

amb el sistema3. Del curs desdev. del cas ds, identificar els esdeveniments

externs generats pels actors. Mostrar-los al diagrama


Representaci diteracions desdeveniments

:Actor :Sistema

esdev1()

esdev2()

esdev3()

esdev4()

*

*

iteraci dunaseqncia desdev.

iteraci dun solesdeveniment


Esdeveniments i operacions

Esdeveniment del sistema: Esdeveniment extern generat per unactor

Operaci del sistema: Operaci interna que sexecuta com aresposta a la comunicaci de lesdeveniment

La comunicaci dun esdeveniment del sistema provoca lexecuciduna operaci del sistema amb el mateix nom i els mateixosparmetres


Operacions del sistema Les operacions del sistema sagrupen com a operacions del tipus

especial sistema En canvi, les operacions no sassignen a objectes concrets durant

letapa despecificaci

Exemple:

iniciVenda(pv) :vendaentrarProd(venda,prod,quant)fiVenda(venda) :importpagament(venda,importPag): canvi

SISTEMA


Esdeveniments i el lmit del sistema

Per identificar els esdeveniments del sistema s necessari haverdelimitat clarament la frontera del sistema

Els esdeveniments del sistema sn els que estimulen directamental sistema

Exemple::Caixer :Sistema

iniciVenda

*entrarProd

fiVenda

pagament

frontera delsistema

Lactor client no interacciona directament amb el sistema,noms ho fa el caixer


Contractes de les operacions

Contracte duna operaciDescriu el comportament del sistema en termes de: quins sn els canvis destat de la base dinformaci quines sn les sortides que el sistema proporcionaquan sinvoca loperaci

El tipus de descripci s declaratiu: lmfasi es posa en el qu far loperaci ms que en el com ho far

Els contractes de les operacions inclouen primordialment: precondicions i postcondicions que descriuen els canvis destat sortides


Contractes de les operacions: componentsName:nom i arguments de loperaci (signatura de loperaci) Responsibilities: Descripci informal del propsit de loperaci Exceptions: Descripci de la reacci del sistema a situacions excepcionals Preconditions: Assumpcions sobre lestat del sistema abans de la invocaci de loperaci Postconditions: Canvis destat que shan produit:

- altes/baixes dinstncies de classes dobjectes- altes/baixes dinstncies dassociacions- modificaci datributs- generalitzaci dun objecte- especialitzaci dun objecte- canvi de subclasse dun objecte

Sortida: Descripci de la sortida que proporciona loperaci en pseudo-OCL

Observeu el lligam que existeix entre els contractes de lesoperacions i lesquema conceptual


Exemple: esquema conceptual de partida

RI textuals:1- La clau externa de PuntDeVenda s num-pv2- La clau externa de Producte s codi3- Un punt de venda no pot tenir ms duna venda amb el mateix dia i hora

Productecodipreudescripci

LniaDeVendaquantitat

PuntDeVendanum-pv

Vendadiahora/import

1 1..*

1

1*

t*

consta de

correspon a


Exemple: operaci iniciVenda

Name: iniciVenda(pv) :venda

Responsibilities: Iniciar lenregistrament duna venda Exceptions: Si no existeix cap PuntDeVenda amb num-pv=pv, indicar error Preconditions: Existeix un PuntDeVenda amb num-pv=pv Postconditions:

- alta duna instncia V de Venda amb el dia i lhora actuals- alta duna instncia de lassociaci t que associa la venda V i lainstncia de PuntDeVenda amb num-pv=pv

Sortida: V


Exemple: operaci entrarProd

Name: entrarProd(venda,prod,quant)

Responsibilities: Enregistrar un lnia duna venda Exceptions: Si no existeix cap Producte amb codi=prod, indicar error Preconditions: Existeix un Producte amb codi=prod Postconditions:

- alta duna instncia de LniaDeVenda L amb quantitat=quant- alta duna instncia de lassociaci consta de que associa L i venda- alta duna instncia de lassociaci correspon a que associa L i elproducte amb codi=prod

Sortida:


Exemple: operaci fiVenda

Name: fiVenda(venda) :import

Responsibilities: Finalitzar lenregistrament duna venda i mostrar limport a pagar Exceptions:

Preconditions:

Postconditions:

Sortida: import = venda.import


Exemple: operaci pagament

Name: pagament(venda,importPag): canvi

Responsibilities: Mostrar el canvi a retornar Exceptions: Si importPag < venda.import indicar error Preconditions: importPag venda.import Postconditions:

Sortida: canvi = venda.import - importPag


Compartici dinformaci entre les operacions dun diagrama

Mitjanant argumentsaddicionals de les operacions

Mitjanant informaci addicional alesquema conceptual

:Caixer :Sistema

iniciVenda(pv)

*

:venda




:Caixer :Sistema

iniciVenda(pv)

*

:venda

entrarProd(prod,quant)

fiVenda():import

pagament(importPag):canvi

Vendadiahora/import

VendaEnCurs

UML no precisa de quina manera les operacions dun diagrama de seqncia podencompartir informaci

Dues possibles solucions sn:

Restricci implcita: El valor de largumentvenda s el mateix a tots els esdevenimentsdel diagrama


Informaci Elemental vs Informaci Composta

La informaci tractada per una operaci sexpressa tant a nivell delsparmetres com de la sortida que apareixen a la signatura de loperaci

Hi ha dos tipus dinformaci: Informaci Elemental: cont un nic element dinformaci indivisible

Propietat Classe dobjectes predefinida: Integer, Real, ...

Informaci Composta: s una composici dinformacions elementals (i, pertant, cal especificar com es defineix la composici)Exemple: ResumVendes(num-pv) que retorna un llistat de vendes amb la informaci:

Per cada Producte p venut en aquell PuntDeVenda num-pv mostrar - el codi del producte - la quantitat total venuda de p a num-pv

ResumVendes (num-pv:Integer): ???


Informaci Composta - Definici

Problema: com sespecifica el contingut duna informaci composta? En lactualitat, UML no proposa cap soluci Utilitzarem una adaptaci de la definic de fluxes de dades que es fa en

lanlisi estructurada (Yourdon, 1993)

Mecanismes bsics de definici dinformaci composta Inclusi: i1 = i2 + i3 + i4 Selecci: i1 = [i2 l i3 l i4] Repetici: i1 = {i2 + i3 + i4} Opcionalitat: i1 = i2 + (i3 + i4)

Exemple:LlistatVendes = num-pv + {codi-prod + quantitat}num-pv = Integer; codi-prod = Integer; quantitat = Integer

ResumVendes(num-pv:Integer) : LlistatVendes


Informaci composta - Contractes de les operacions Les operacions necessitaran mecanismes per manipular (accedir, construir,

etc.) la informaci composta que apareix a la seva signatura Es necessita estendre OCL per poder manipular informaci composta

Exemple: contracte de loperaci ResumVendes (num-pv): LlistatVendesNom: ResumVendes (num-pv): LlistatVendesResponsabilitats: emetre el resum de vendes demanatTipus: sistemaExcepcions:-

Preconditions: - Postconditions: -

Sortida: Mostrar (num-pv)

Per cada producte p resultant de (Producte.allInstances ->

select (p | p.LniaDeVenda.Venda.PuntDeVenda.num-pv->includes(num-pv)) Fer Qt = (p.LniesdeVenda ->

(select (lv | lv.Venda.PuntdeVenda.num-pv = num-pv).quantitat) -> Sum) Mostrar (p.codi-prod) Mostrar (Qt)


Diagrama de seqncia: quants esdeveniments?

El nombre desdeveniments dun diagrama de seqncia depn de com esprodueix la interacci entre els actors i el sistema software.

:Caixer :Sistema

iniciVenda(pv): venda

*entrarProd(venda, prod, quant)

fiVenda(venda): import

pagament(venda, importPag): canvi

:Sistema-X :Sistema

fer-Venda(infoVenda)

infoVenda = pv + {prod, quant} + importPag

Ambds diagrames suposen la mateixaentrada dinformaci al sistema

Els dos diagrames de seqncia poden sercorrectes, segons les circumstncies


Redundncia - Exemple

Lesquema Conceptual cont restriccions dintegritat (grfiques i textuals) Els contractes de les operacions tenen precondicions, que sn requeriments del

contingut de lesquema conceptual per poder executar una transacci

Cal que les precondicions incloguin la comprovaci de les restriccions del M.Conceptual?

Empleatcodi-empsou

R.I. textual: dos empleats no poden tenir el mateix codi

Nom: AltaEmpleat (codi-emp, sou)Responsabilitats: donar dalta lempleatExcepcions: -Preconditions: no existeix Empleat amb codi-empPostconditions: creaci dun nou objecte Empleat amb codi-emp i souSortida: -

Cal posar aquesta precondici ???


Redundncia - Definici

Una especificaci s redundant si un mateix aspecte del sistemasoftware est especificat diverses vegades.

La redundncia dificulta la modificabilitat de lespecificaci perqu sivaria aquell aspecte cal modificar tots els models que hi fan referncia.

Lespecificaci no hauria de ser redundant !!!

Redundncies possibles:

Entre lEsquema Conceptual i els Contractes Entre els Diagrames de Seqncia i els Contractes ...


Significat habitual:

Redundncia - Esq. Conceptual i Contractes (I)

:Persona :Sistema

CompraCotxe(nom-p,matr)

Personanom-p

Cotxematrany

0..1 0..3t

Nom: CompraCotxe (nom-p,matr)Responsabilitats: compra dun cotxeExcepcions: (les que es dedueixen de les prec.) Preconditions: - existeix Persona p amb nom-p - existeix Cotxe c amb matr - p no t c - p no t ja 3 cotxesPostconditions: - creaci duna associaci t entre p i c Sortida: -

Significat alternatiu:Nom: CompraCotxe (nom-p,matr)Responsabilitats: compra dun cotxeExcepcions: (les que es dedueixen de les prec.) Preconditions: - existeix Persona p amb nom-p - existeix Cotxe c amb matr - p no t cPostconditions: - Si p t ja 3 cotxes llavors

eliminar lassociaci entre p i el cotxe c de ms antiguitat

- creaci duna associaci t entre p i cSortida: -


Redundncia - Esq. Conceptual i Contractes (II) Com shan dinterpretar els contractes en relaci al Model Conceptual?

Precondicions:

qu ha de contenir el Model Conceptual per intentar executar unaoperaci

Restriccions del Model Conceptual:

Estan garantides desprs de lexecuci de totes les operacions queparticipen en un cas ds

Es rebutgen totes les operacions dun cas ds si la seva execuciviola (globalment) alguna restricci dintegritat del Model Conceptual


Redundncia - Esq. Conceptual i Contractes (III)

:Persona :Sistema

AltaPersona(nom,adrea)

:Persona :Sistema

AltaPersona(nom,adrea)ParlaIdioma(nom, idioma)*

Nom: AltaPersona(nom,adrea)

Preconditions:Postconditions: - creaci dun objecte Persona amb el nom i ladrea especificatsSortida:

Nom: ParlaIdioma(nom,idioma)

Preconditions: - existeix idioma amb nom=idioma Postconditions: - creaci duna associaci parla entre la persona amb nom=nom i lidioma Sortida:

Personanomadrea

Idiomanomnm-parlants

* 1..*parla

Cas ds: Afegir-Persona-1 Cas ds: Afegir-Persona-2

No permet afegir mai una persona !


Redundncia - Diagrames de Seqncia i Contractes

Els diagrames de seqncia defineixen un ordre dinvocaci de lesoperacions

Les operacions no han dincorporar informaci per garantir queaquest ordre es compleixi

:Caixer :Sistema

iniciVenda(pv): venda

*entrarProd(venda, prod, quant)

fiVenda(venda): import

pagament(venda, importPag): canvi

Nom: Pagament (venda, importPag): canvi

Preconditions: - existeix venda venda - la venda venda ha finalitzat

Postconditions: ...

Sortida:sn redundants


Bibliografia

C. LarmanApplying UML and Patterns.An Introduction to Object-Oriented Analysis and Design.Prentice Hall, 1998. (Cap. 13, 14)

J. Rumbaugh, I.Jacobson, G.BoochThe Unified Modeling Language Reference ManualAddison-Wesley, 1999.

G.Booch, J. Rumbaugh, I.JacobsonThe Unified Modeling Language User GuideAddison-Wesley, 1999.

ES:E - Model dels Estats en UML 1

Model dels Estats en UML

Introducci s dels diagrames destat Exemples Accions i condicions duna transici Estats imbricats Bibliografia


ModelDAnlisi

ModelConceptual






Model deCasos ds


Model delsEstats




Model dels Estats

Objectius: crear diagrames destat per objectes i casos ds

Esdeveniments, estats i transicions: Esdeveniment:

tot all que requereix una resposta del sistema software

Estat: condici dun objecte o dun cas ds en un moment del temps

Transici: canvi destat com a conseqncia dun esdeveniment


Diagrama destats

Variable: tipus=valor inicial

Nom Estat

Nom EstatEntry/accido/activitatexit/accievent/acci

Esdev.(arguments)[condici]/acci

Nom super estat

Un diagrama destats mostra la seqncia destats que passa un objecte (o una interacci)durant la seva vida en reposta als estmuls rebuts, juntament amb les seves respostes.


Canvi destat civil duna persona

Persona

Soltera VduaDivorciadaSeparadaCasada

estat-civil

Soltera

casament

Casada

Vdua

divorci

Divorciada

neixement

Separada

enviudarseparaci

enviudar

divorci

casament casament



s dels diagrames destat

Un diagrama destats es pot especificar per a una: Classe dobjectes:

per descriure perqu els objectes canvien de subclasse les subclasses dun diagrama destats no tenen perqu aparixer

explcitament a lesquema conceptual per descriure classes dobjectes amb important comportament

dinmic

Cas ds: per descriure la seqncia legal en la que els esdeveniments es

poden produir al mn real

p.ex. en una compra de producte no es pot fer el pagament fins queno shagi tancat la venda.


Diagrama destats del cas dus comprar productes

EsperantVenda

entrarProdIntroduintProductes

entrarProd

EsperantPagament

fiVenda

pagamentEnMetl.lic

AutoritzantPagamentgestionaResposta pagamentAmbTarja


Diagrama destats dun telfon

lliure actiudespenjar

penjar

estat inicial

estat

esdeveniment transici


Accions i condicions duna transici

lliure actiudespenjar [abonatVlid]

/marcarTo

penjar

condici

acci


Estats imbricats

lliureEmetent To Marcar

despenjar [abonatVlid]/marcarTo

penjarMarcant

dgit

dgit Connectantcomplet

Parlant

Actiu

connectat


Bibliografia

C. LarmanApplying UML and Patterns.An Introduction to Object-Oriented Analysis and Design.Prentice Hall, 1998. (Cap. 33)

G. Booch, J. Rumbaugh, I. JacobsonThe Unified Modeling Language User GuideAddison-Wesley, 1999

B. Powel DouglassReal-Time UML.Addison-Wesley, 1998.

ES:E - Procs Unificat de Desenvolupament de Software 1

El Procs Unificat de Desenvolupament de Software

Etapes del procs iteratiu de desenvolupament del software Cicles de desenvolupament Exemple: compra de productes Bibliografia


Pla i Elaboraci Construcci Implantaci

1. Planificar i Elaborar - Planificar, definir requeriments,construir prototipus, ...

2. Construir - Desenvolupament del sistema (especificaci, disseny, etc.)

3. Implantar - Implantar el sistema pel seu s.

Procs de desenvolupament del software - Macro Nivell


1. Definir el Pla Inicial 2. Informe dInvest. Preliminar 3. Definir Requeriments

4. Definir Termes al Glossari 5. Implementar Prototipus 6. Definir Casos Ds7. Definir Model Conceptual

Pla i Elaboraci

Construcci Implantaci

8. Definir Esq. dArquitectura 9. Refinar el Pla.

Inclou la concepci inicial del projecte, detecci de problemes, determinaci dobjectius,investigaci dalternatives de canvi, planificaci i especificaci dels requeriments.

Etapa de planificaci i elaboraci

Pla: calendari, pressupost, etc. Informe dinvestigaci preliminar: motivaci, alternatives, necessitats de negoci. Especificaci de requeriments: descripci declarativa dels requeriments Glossari: diccionari de termes (conceptes, noms) i qualsevol informaci associada


Pla i Elaboraci

Construcci Implantaci

Cicle deDesenvolupament 1

Refinarpla

Cicle deDesenvolupament 2

Sincr.Artefactes

Anlisi Disseny C onstrucci Prova

Avantatges: La complexitat mai no sobrepassa al disenyador Primeres impressions molt rpidament, perqu la implementaciduna petita part del sistema es fa molt rpidament.

Etapa de construcci

...


Cicle de Desenvolupament 1 ...Cicle de Desenvolupament 2

Refinar pla Sincr. Artefactes Anlisi Disseny Construcci Prova

1. Definici dels casosds essencials

2. Refinar elsDiagrames

3. Refinar el ModelConceptual

4. Refinar elGlossari

5. Definir Diagramesde Sequencia

6. Definir ContractesdOperaci

7. Definir DiagramesdEstat

Letapa de construcci inclou diversos cicles de desenvolupament en els qualsel sistema es va estenent de forma progressiva.

Etapa de construcci: cicles de desenvolupament (I)


Cicle de Desenvolupament 1 ...Cicle de Desenvolupament 2

Refinar pla Sincr. Artefactes Anlisi Disseny Construcci Prova

1. Definici dels casosds reals

2. Definir informes iinterfcies dusuari

3. Refinar larquitecturadel sistema

4. Definir els diagramesdinteracci

5. Definir el diagrama declasses de disseny

6. Definir lesquema de labase de dades

Etapa de construcci: cicles de desenvolupament (II)


Cicle dedesenvolupament



Cas ds AVersiSimplificada...

...

...

Cas ds AVersiCompleta...

...

...

Cas ds B...

...

...

Cas ds C...

...

...

Com prioritzar?a. Inclouen funcions arriscades, crtiques o complexes.b. Involucra tecnologia nova o arriscada.c. Representen processos primordials pel negoci.d. Impacte significatiu en el disseny (afegeix moltes classes

al domini o requereix molts serveis).e. Permet obtenir informaci significativa respecte al

disseny amb poc esfor.

Ordenar i prioritzar casos ds


Exemple: compra de productes

:Caixer :Sistema

iniciVenda(pv)

*

:venda



ferPagament

En un primer cicle de desenvolupament pot no interessar-nos distingir entre lesdiverses formes possibles de pagament

Interessa desenvolupar el subsistema necessari per poder efectuar una compra El contracte de pagament hauria de ser prou genric per no entrar en detalls de

la seva forma de pagament


Compra de productes - 2on cicle

Tenim tants diagrames de seqncia com formes de pagament possibles Tots aquests diagrames parteixen del diagrama que sha fet al primer cicle de

desenvolupament.

:Caixer :SistemainiciVenda(pv): venda

*entrarProd(venda,prod,quant)

Interacci comuna atot tipus de pagament

Interacci especfica al pagament en metl.lic

:Caixer :Sistema



Interacci especfica del pagament amb tarja

:Caixer :SistemapagTarjaCrdit(num -t,data-cad)

:Sist. Autor. Crdit

sol.licitaAprov(petici)

tractarResp.Tarja(resposta)

:Gesti Targes

afegeixAprovaci(resposta)

Nom: pagTarjaCrdit (num-tarja, data-cad)Responsabilitats: pagar amb la tarja de crditExcepcions: Preconditions: Postconditions: - creaci dun nou PagamentAmbTarja pmt - nova associaci entre pmt i la venda actual - ...

Sortida: - senvia una sol.licitud daprovaci al servei dautoritzaci de crdit

Nom: tractarResp.Tarja (resposta)Responsabilitats: respondre a la resposta daprovaci rebudaExcepcions:Preconditions: Postconditions: - ...

Sortida: - senvia una aprovaci al sistema de Gesti de Targes perqu lenregistri


Bibliografia

C. LarmanApplying UML and Patterns.An Introduction to Object-Oriented Analysis and Design.Prentice Hall, 1998. (Cap. 13, 32)

I.Jacobson, G.Booch, J.RumbaughThe Unified Software Development Process.Addison-Wesley, 1999.

Recull d'exercicis

Part I: Introducci

1 . Dna, i justifica, una definici de l'enginyeria del software.2 . El cicle de vida anomenat "model espiral" est basat en quatre activitats: Planificaci,

Anlisi de risc, Enginyeria i Avaluaci. Comenta breument l'objectiu de cada unad'aquestes activitats i com s'encadenen.

3 . Dna una definici de requeriment d'un sistema i d'especificaci de requeriments d'unsistema.

4 . Indica la diferncia entre requeriments d'un sistema i requeriments del software.

5 . Resumeix les quatre estratgies per a determinar els requeriments.

6 . Defineix, i descriu breument, tres requeriments no funcionals, de diferent tipus, relatius alprojecte fet durant el curs.

7 . Una de les propietats desitjables de les especificacions s que siguin "traables"(traceability). Defineix aquesta propietat.

8 . Una de les propietats desitjables de les especificacions s que siguin verificables. Defineixquan es pot dir que una especificaci determinada compleix aquesta propietat. Posa unexemple d'un fragment qualsevol d'una especificaci que sigui verificable i un altre que noho sigui.

9 . Molta gent argumenta que el terme "manteniment" s incorrecte aplicat al software - que lesactivitats associades amb el manteniment del software no sn del tot "manteniment". Quen penses?. (Exercici 1.11 de Pressman 93).

10 . Indica quina relaci hi ha (si s que n'hi ha) entre la construcci de prototipus i el model dedesenvolupament de software en espiral.

11. Indica els tres tipus de manteniment de software que hi ha, i explica'ls breument.12. Quins sn els avantatges i els inconvenients principals, si nhi ha, del cicle de vida basat en

el desenvolupament incremental i iteratiu dUML en relaci al cicle de vida clssic, encascada?

13. Explica breument la diferncia entre requeriments funcionals i requeriments no funcionalsdun sistema software. Defineix, i descriu breument, dos requeriments funcionals i dosrequeriments no funcionals, de diferent tipus, relatius al projecte fet durant el curs.

Part II : Model Conceptual en UML

1 . Feu el Model Conceptual amb la notaci UML d'un sistema que cont l'horari i lesassignatures de la Facultat, d'una sola enginyeria.

Una assignatura t un codi, un nom i un cert nombre de crdits (no distingirem entreteoria, problemes i laboratoris), i est assignada a un departament. Les assignatures podenser obligatries o opcionals. Les assignatures poden estar relacionades per prerequisits,pre/corequisits i corequisits.

L'horari indica per cada grup d'una assignatura (per exemple, ES:E grup 10) quins dies dela setmana hi ha classe, en quina aula i en quines hores. Els perodes de classe podeusuposar que sn d'una hora. Cada assignatura t un cert nombre d'hores de classe (no caldistingir entre hores de teora, problemes i laboratoris, ni tenir en compte el concepte desubgrup). Expresseu grficament totes les restriccions que pugueu. Les restriccions que no es podenexpressar grficament i les regles de derivaci dels atributs derivats, si nhi ha, especifiqueu-les en el llenguatge OCL.

2 . Feu el Model Conceptual amb la notaci UML d'una empresa de transports que continformaci relativa a rutes, carreteres i poblacions.

L'empresa cobreix un mbit geogrfic comprs per unes 1000 poblacions. Cada poblacit un codi i un nom. Aquestes poblacions estan unides per unes 50 carreteres. Cada carreterat un codi. Una carretera consta d'una srie de trams consecutius. En mitjana, hi ha 100trams per carretera. Un tram d'una carretera es defineix per les dues poblacions que uneix i ladistncia en kilmetres entre elles. Tamb es considera la duraci del trajecte, en minuts,entre aquestes dues poblacions, que, en el cas general, pot ser diferent segons sigui un sentito l'altre. Per una mateixa poblaci poden passar diverses carreteres.

Un exemple amb 9 poblacions, 3 carreteres i 10 trams podria ser:

A B

G

C

F

D

E

H

I

autA2com12loc1

El trajecte que ha de recrrer un cami de l'empresa s una ruta. Hi ha unes 30 rutes, cadauna de les quals t un codi. Una ruta parteix i acaba en una mateixa poblaci, i consta d'unaserie de trams consecutius de la mateixa o diferents carreteres, que s'han de recrrer en unacerta direcci. Per exemple, la ruta 10 podria ser:

(B,C,autA2),(C,F,com12),(F,E,com12),(E,H,loc1),(H,E,loc1),(E,D,autA2),(D,C,autA2),(C,B,com12)

3 . Feu el Model Conceptual amb la notaci UML d'un sistema que guardi i processi dadessobre les segents relacions entre persones (no cal que aquestes informacions apareguinexplcitament al model, poden obtenir-se indirectament):1. Casaments (entre dues persones).2. Divorcis (id.)3. Fills (o Pare de i Mare de)El model hauria de mostrar explcitament les restriccions (suposades) segents:a) Els casaments sn entre un home i una dona.b) Dues persones noms es poden divorciar si estaven casades.c) Una persona s filla d'un home i d'una dona que es van casar.Pots suposar que:

1. Dues persones no es casen entre elles ms d'una vegada.2. Les persones s'identifiquen pel su nom.3. De les persones en sabem noms el seu sexe.4. No estem interessats en cap altre atribut.

Un cop fet el model, mostreu-ne la instanciaci completa amb les dades segents:

En Joan i la Maria es van casar.L'Helena s una filla del Joan i la Maria.En Joan i la Maria es van divorciar.La Maria es va casar amb el Jordi.L'Albert s un fill del Jordi i la Maria.

4 . Feu el Model Conceptual amb la notaci UML d'un sistema que guardi i processi dadessobre les segents relacions entre persones i cotxes:

1. Propietari: un cotxe t una o ms persones propietries.2. Conductor habitual: un cotxe noms t una, i noms una, persona que n's la

Enginyeria Del Software, Especificació Amb UML

Documents

Transcript of Enginyeria Del Software, Especificació Amb UML