Enginyeria Del Programari

Enginyeria del Programari (05.565)

Universitat Oberta de Catalunya (UOC)

http://furniman.blogspot.com


http://furniman.blogspot.com Pgina 2 de 26

TEMA 1.- Introducci a la enginyeria del programari

1.- QU S LENGINYERIA DEL PROGRAMARI? ......................................................................................................................................................5

2.- ORGANITZACI DE LENGINYERIA DEL PROGRAMARI ...................................................................................................................................5

2.1.- DESENVOLUPAMENT, OPERACI I MANTENIMENT .................................................................................................................................................................................. 5

2.2.- ORGANITZACI DELS PROJECTES DE DESENVOLUPAMENT ....................................................................................................................................................................... 5

2.3.- ACTIVITATS DE LENGINYERIA DEL PROGRAMARI ...................................................................................................................................................................................... 6

2.3.1.- Gesti del projecte .................................................................................................................................................................................................................... 6

2.3.2.- Identificaci i gesti dels requisits ......................................................................................................................................................................................... 6

2.3.3.- Modelitzaci .............................................................................................................................................................................................................................. 6

2.3.4.- Construcci i proves.................................................................................................................................................................................................................. 6

2.3.5.- Qualitat ....................................................................................................................................................................................................................................... 6

2.3.6.- Manteniment i reenginyeria ..................................................................................................................................................................................................... 6

2.3.7.- Activitat des del punt de vista del cicle de vida del projecte. ........................................................................................................................................... 6

2.4.- ROLS ...................................................................................................................................................................................................................................................... 7

2.4.1.- Cap de projectes ....................................................................................................................................................................................................................... 7

2.4.2.- Experts del domini (Analista de negoci) .............................................................................................................................................................................. 7

2.4.3.- Analista funcional ...................................................................................................................................................................................................................... 7

2.4.4.- Arquitecte ................................................................................................................................................................................................................................... 7

2.4.5.- Analista orgnic o tcnic ......................................................................................................................................................................................................... 7

2.4.6.- Programadors ............................................................................................................................................................................................................................ 7

2.4.7.- Expert en qualitat (provador) ................................................................................................................................................................................................ 7

2.4.8.- Encarregat de desplegament. ................................................................................................................................................................................................. 7

2.4.9.- Responsable del producte. ....................................................................................................................................................................................................... 7

3.- MTODES DE DESENVOLUPAMENT DE PROGRAMARI .....................................................................................................................................7

3.2.- CLASSIFICACI DE MTODES DE DESENVOLUPAMENT. ............................................................................................................................................................................. 8

3.2.1.- Cicle de vida clssic o en cascada. ........................................................................................................................................................................................ 8

3.2.2.- Cicle de vida iteratiu i incremental. ....................................................................................................................................................................................... 8

3.2.3.- Desenvolupament lean i gil. .................................................................................................................................................................................................. 8

3.3- EXEMPLES DE MTODES DE DESENVOLUPAMENT ....................................................................................................................................................................................... 8

3.3.1.- Mtrica 3 .................................................................................................................................................................................................................................... 8

3.3.2.- Procs unificat (UP) .................................................................................................................................................................................................................. 8

3.3.3. - Scrum (gil) ........................................................................................................................................................................................................................... 10

3.3.4.- Artefactes ................................................................................................................................................................................................................................ 10

3.3.5.- Prctiques ................................................................................................................................................................................................................................ 10

4.- TCNIQUES I EINES DE LENGINYERIA DEL PROGRAMARI ............................................................................................................................ 10

4.1.- TCNIQUES BASADES EN LA REUTILITZACI ........................................................................................................................................................................................... 10

4.1.1.- Desenvolupament orientat a objecte .................................................................................................................................................................................. 11

4.1.2.- Bastiments ................................................................................................................................................................................................................................ 11

4.1.3.- Components ............................................................................................................................................................................................................................. 11

4.1.4.- Desenvolupament orientat a serveis ................................................................................................................................................................................... 11

4.1.5.- Patrons ..................................................................................................................................................................................................................................... 11

4.1.6.- Lnies de producte .................................................................................................................................................................................................................. 11

4.2.- TCNIQUES BASADES EN LABSTRACCI ............................................................................................................................................................................................... 12

4.2.1.- Arquitectura dirigida per models (MDA) .......................................................................................................................................................................... 12

4.2.2.- Llenguatges especfics del domini (DSL) ............................................................................................................................................................................ 12

4.3.- EINES DE SUPORT A LENGINYERIA DE PROGRAMARI (CASE) ............................................................................................................................................................... 12

5.- ESTNDARDS DE LENGINYERIA DE PROGRAMARI ...................................................................................................................................... 13

5.1.- LLENGUATGE UNIFICAT DE MODELITZACI (UML) ............................................................................................................................................................................... 13

5.2.- SOFTWARE ENGINEERING BODY OF KNOWLEDGE (SWEBOK) .......................................................................................................................................................... 13

5.3.- CAPABILITY MATURITY MODEL INTEGRATION (CMMI) ......................................................................................................................................................................... 13

5.4.- PROJECT MANAGEMENT BODY OF KNOWLEDGE (PMBOK) ............................................................................................................................................................... 13



TEMA 2.- Orientaci a objectes

1.- QU S LORIENTACI A OBJECTES? ............................................................................................................................................................. 14

2.- CLASSIFICACI I ABSTRACCI ....................................................................................................................................................................... 14

2.1.- CLASSIFICACI .................................................................................................................................................................................................................................... 14

2.2.- ABSTRACCI ....................................................................................................................................................................................................................................... 14

2.3.- DESCRIPCI DE LES CLASSES DOBJECTES. ............................................................................................................................................................................................ 14

2.3.1.- Atributs ..................................................................................................................................................................................................................................... 14

2.3.2.- Associacions ............................................................................................................................................................................................................................ 14

2.3.3.- Operacions .............................................................................................................................................................................................................................. 15

3.- OCULTACI DINFORMACI I ENCAPSULAMENT. ........................................................................................................................................ 15

4.- HERNCIA I POLIMORFISME ............................................................................................................................................................................ 15

4.1.- HERNCIA ............................................................................................................................................................................................................................................ 15

4.2.- POLIMORFISME .................................................................................................................................................................................................................................... 15

3.- Requisits

1.- INTRODUCCI ALS REQUISITS ........................................................................................................................................................................ 15

1.3.- TIPUS DE REQUISITS.............................................................................................................................................................................................................................. 15

1.4.- REQUISITS AL LLARG DEL DESENVOLUPAMENT ...................................................................................................................................................................................... 16

2.- OBTENCI DELS REQUISITS ............................................................................................................................................................................. 16

2.1.- IDENTIFICACI DSTAKEHOLDERS .......................................................................................................................................................................................................... 16

2.1.1.- Brainstorming o pluja didees ............................................................................................................................................................................................. 16

2.1.2.- Modelitzaci de rols dusuari. ............................................................................................................................................................................................. 16

2.1.3.- Representant dels stakeholders ............................................................................................................................................................................................ 16

2.2.- IDENTIFICACI DE REQUISITS ................................................................................................................................................................................................................ 16

2.2.1.- Entrevistes i qestionaris ....................................................................................................................................................................................................... 16

2.2.2.- Observaci i prototipatge .................................................................................................................................................................................................... 16

2.2.3.- Llistes predefinides (checklists)............................................................................................................................................................................................. 17

3.- GESTI DE REQUISITS ...................................................................................................................................................................................... 17

3.1.- ESTIMACI DE REQUISITS ..................................................................................................................................................................................................................... 17

3.2.- PRIORITZACI DE REQUISITS ................................................................................................................................................................................................................ 18

4.- DOCUMENTACI (ESPECIFICACI) DELS REQUISITS ..................................................................................................................................... 18

4.1.- QUALITATS DUNA BONA ESPECIFICACI DE REQUISITS ........................................................................................................................................................................ 18

4.2.- BONES PRCTIQUES ............................................................................................................................................................................................................................ 19

4.3.- HISTRIES DUSUARI ............................................................................................................................................................................................................................ 19

5.- CASOS DS ...................................................................................................................................................................................................... 19

5.2.- ACTORS I STAKEHOLDERS .................................................................................................................................................................................................................... 19

5.3.- ANATOMIA DUN CAS DS ................................................................................................................................................................................................................. 19

5.4.- CLASSIFICACI DE CASOS DS ........................................................................................................................................................................................................... 20

5.4.1.- Per nivell dels objectius ......................................................................................................................................................................................................... 20

5.4.2.- mbit ........................................................................................................................................................................................................................................ 20

5.5.- IDENTIFICACI I DESCRIPCI DE CASOS DS ....................................................................................................................................................................................... 20

5.5.1.- Identificaci dactors i objectius .......................................................................................................................................................................................... 20

5.5.3.- Relacions entre casos ds: inclusi ..................................................................................................................................................................................... 20

5.6.- CASOS ESPECIALS................................................................................................................................................................................................................................ 21



TEMA 4 Anlisi UML

1.- ANLISI ORIENTADA A OBJECTES AMB UML ................................................................................................................................................ 21

1.2.- LLENGUATGE UML .............................................................................................................................................................................................................................. 21

1.2.3.- Tipus de diagrames ................................................................................................................................................................................................................ 21

2.- MODEL DELS CASOS DS ............................................................................................................................................................................... 21

2.2.- DIAGRAMA DACTIVITATS .................................................................................................................................................................................................................... 22

3.- MODELITZACI DE LA INTERFCIE .................................................................................................................................................................. 23

3.2.- MODELS DE LES PANTALLES .................................................................................................................................................................................................................. 23

3.2.1.- Diagrama destat de les pantalles (mapa navegacional) .............................................................................................................................................. 24

3.3.- CONTRACTES DE LES OPERACIONS DEL SISTEMA................................................................................................................................................................................... 24

4.- MODEL DE DOMINI .......................................................................................................................................................................................... 24

4.2.- CLASSES .............................................................................................................................................................................................................................................. 24

4.2.2.- Tcniques de modelitzaci .................................................................................................................................................................................................... 24

4.3.- ATRIBUTS ............................................................................................................................................................................................................................................. 25

4.3.1- Notaci UML ............................................................................................................................................................................................................................ 25

4.4- ASSOCIACIONS .................................................................................................................................................................................................................................... 25

4.5.- HERNCIA ............................................................................................................................................................................................................................................ 26

4.5.2.- Tcniques de modelitzaci .................................................................................................................................................................................................... 26

4.6.- INFORMACI DERIVADA I REGLES DIDENTITAT ...................................................................................................................................................................................... 26

4.6.1.- Regles dIntegritat ................................................................................................................................................................................................................. 26

4.6.2.- Informaci derivada .............................................................................................................................................................................................................. 26

4.7.- CLASSE I ATRIBUTS ............................................................................................................................................................................................................................... 26

4.8.- ASSOCIACI DELEMENTS AVANATS .................................................................................................................................................................................................. 26

4.8.1.- Composici .............................................................................................................................................................................................................................. 26



TEMA 1.- Introducci a la enginyeria del programari

1.- Qu s lenginyeria del programari? Programari: Conjunt dels programes de computaci, procediments, regles, documentaci i dades associades que formen part de les

operacions dun sistema de cmput.

Codi Font: Manera en que sescriu el programari per a que sigui llegible per a les persones.

Desenvolupament de programari: Acte de produir o crear programes incloent estudi previ, manteniment, manuals

rees potencials daplicaci de lenginyeria de programari (No excloents)

o Programaris de sistemes: (S.O., compiladors) Donen servei a altres programes

o Programari daplicaci: Resolen una necessitat especfica (a mida o de propsit general).

o Programari cientfic i denginyeria

o Programari encastat

Forma part dun aparell

Limitacions de recursos computacionals

Molt adaptat al producte o Programari de lnies de productes

Capacitat especfica

Gran Varietat de Clients

Mercat limitat (gesti dinventaris) ampli (Excel) o Programari dintelligncia artificial

Sistemes experts

Reconeixement de la parla

Sistema dinformaci: Qualsevol combinaci de tecnologia de la informaci i activitats humanes que utilitzen aquesta tecnologia per a

donar suport a loperaci, gesti o presa de decisions.

Enginyeria del Programari: Aplicaci dun enfocament sistemtic, disciplinat i quantificable al desenvolupament, operaci i

manteniment del programari.

Caracterstiques inherents al programari: (Que el diferencien daltres productes industrials)

o El programari s intangible: No consumeix matria fsica.

o El programari no es manufactura: Cost baix. Cpies idntiques.

o El programari no es desgasta: No hi ha peces de recanvi. Si hi un error existir a totes les cpies.

o Queda obsolet rpidament.

2.- Organitzaci de lenginyeria del programari

2.1.- Desenvolupament, Operaci i Manteniment

Desenvolupament

o Temporal (Inici i fi clars)

o Resultat nic (2 processos, 2 productes)

o Organitzaci en projectes

Operaci

o Activitats continues

o Repetitiu

o Organitzaci en Serveis

Manteniment

o Continu (Manteniment correctiu)

o Temporal (Manteniment evolutiu)

2.2.- Organitzaci dels projectes de desenvolupament

Tasques i ordre dexecuci

Rols

o Nombre de rols

o Responsabilitat del rol

o Tasques a dur a terme

Artefactes (Documents i programes..)

o Entrada

o Sortida



2.3.- Activitats de lenginyeria del programari

Activitat: Conjunt de tasques relacionades entre s.

2.3.1.- Gesti del projecte

Conjunt de processos necessaris per a la direcci i gesti i administraci de qualsevol projecte, amb independncia del producte:

o Estudi de viabilitat: Necessitats, alternatives, costos

o Estimaci: Cost del projecte i temps per a dur-lo a terme

o Definici dobjectius: Determinen lxit o el fracs.

o Formaci de lequip: Considerant les estimacions de recursos prvies.

Dedicaci completa

Dedicaci parcial

Stakeholders o Establiment fites: Per verificar la bona marxa.

o Identificar riscos: Tecnolgics, legals

2.3.2.- Identificaci i gesti dels requisits

Expressen les necessitats i restriccions que afecten a un programari

Implica la comunicaci amb els stakeholders.

Problemtiques

o Diferencia respecte a la informaci amb la que treballen les parts

Stakeholder t millor informaci sobre el producte

Programador t millor informaci sobre la tecnologia o Limitacions dels canal utilitzat (verbal, escrit)

o Limitacions del llenguatge utilitzat (natural / formal)

Totes les parts lhan dentendre. o Dificultat de definir el millor sistema possible.

Solucions

o Prototipatge: (Quan sigui possible)

o s de models: Els usuaris / stakeholders han dentendre la notaci.

2.3.3.- Modelitzaci

Facilita la comprensi dels requisits del sistema i el disseny (maquetes)

o UML

No imposa cap mtode de desenvolupament

Defineix la notaci per no els artefactes (un mateix tipus de diagrama es pot fer servir en diferents artefactes)

2.3.4.- Construcci i proves

Escriptura del codi font (Implementaci + gesti configuraci + gesti canvis).

Realitzaci de proves

Desplegament (Crear executables i posar-los a disposici del client)

2.3.5.- Qualitat

Recollecci de mtriques que ajuden a determinar si el programari compleix els criteris de qualitat i la documentaci formal dels

processos.

2.3.6.- Manteniment i reenginyeria

2.3.7.- Activitat des del punt de vista del cicle de vida del projecte.

(Segons Project Management Institute)

Tasques diniciaci: Es comena el projecte? Es compra? (Abast, durada, cost)

Tasques de planificaci

o Tasques a dur a terme

o Ordre

Tasques dexecuci

Tasques de seguiment i control

Tasques de tancament



2.4.- Rols

2.4.1.- Cap de projectes

Perfil no tcnic

Organitza el projecte

Coordina lequip de desenvolupament i la resta de lorganitzaci

Vetlla pels objectius (costos, valor generat)

2.4.2.- Experts del domini (Analista de negoci)

Principal coneixedor dels requisits

Perfil no tcnic

El mtode de desenvolupament marca la implicaci del rol.

2.4.3.- Analista funcional

Modela les visions del domini en un model clar i concs.

Coneix les notacions i estndards de lenginyeria de programari.

Coneix les limitacions tecnolgiques i les maneres daplicar-la a la resoluci de problemes del negoci.

2.4.4.- Arquitecte

Defineix les lnies mestres del disseny del sistema.

Escull la tecnologia adequada per a la implementaci

o Tipus producte

o Coneixements del equip

o Requisits dOrganitzaci

Rol tcnic

Crea un conjunt de documents a partir dels requisits de lanalista que la resta de desenvolupadors faran servir com a base del seu

treball.

2.4.5.- Analista orgnic o tcnic

Disseny detallat del sistema respectant larquitectura definida per larquitecte.

El destinatari de la seva feina s el programador.

En alguns mtodes de desenvolupament aquest rol el fa el programador.

2.4.6.- Programadors

Responsables descriure el codi font a partir del qual shan de generar els programes.

Experts en tecnologia dimplementaci.

Parteixen dels dissenys creats per lanalista orgnic.

Sinclou en aquest grup lexpert en BD.

2.4.7.- Expert en qualitat (provador)

Parteix dels requisits i ha de verificar que els programes els compleixin.

Decideix si el programa es pot posar en mans dels usuaris finals.

2.4.8.- Encarregat de desplegament.

Empaqueta i envia els programes validats als entorns adequats per que arribin al client final.

2.4.9.- Responsable del producte.

Visi global del producte.

Sassegura que el producte encaixa amb lestratgia de la organitzaci.

3.- Mtodes de desenvolupament de programari

Defineix

o Un cicle de vida (conjunt detapes)

Processos

Activitats

Tasques de cada etapa o Assignaci de tasques

o Interacci entre tasques, rols i persones. Taula 1 Wysocki 2009

Soluci coneguda Soluci poc coneguda

Objectiu Clar 1 2 Objectiu poc clar 3 4



3.2.- Classificaci de mtodes de desenvolupament.

3.2.1.- Cicle de vida clssic o en cascada.

Molt senzill daplicar

Poc tolerant als canvis

Afavoreix lespecialitzaci de lequip

Per a projectes de Grau 1 (Objectiu clar, soluci coneguda)

3.2.2.- Cicle de vida iteratiu i incremental.

Sorganitza el desenvolupament en una srie diteracions cada una de les quals s un mini projecte auto contingut que amplia el resultat

final de la iteraci anterior.

Per a projectes del grup 2. (Objectiu clar, soluci poc coneguda)

Accelera la retroalimentaci (Cada iteraci cont requisits, anlisis, implementaci, proves)

En tot moment es t un producte operatiu. (Desprs de cada iteraci es desplega el programa)

Cada iteraci dura entre 1 i 6 setmanes i tenen la mateixa longitud (time-boxing)

Els stakeholders poden decidir la propera iteraci.

3.2.3.- Desenvolupament lean i gil.

Individus i interaccions per sobre de processos i eines.

Programari que funciona per sobre de documentaci exhaustiva.

Collaboraci amb el client per sobre de negociaci de contractes.

Resposta al canvi per sobre de cenyir-se a una planificaci.

Es basa en set principis (desenvolupament lean)

o Evitar la producci innecessria: Produir noms all que es necessita en letapa segent.

o Amplificar laprenentatge: Recollir tota la informaci sobre el producte i la producci per entrar en un cicle de millora

continua de la producci.

o Decidir el ms tard possible: Fins que no prendre la decisi sigui ms car que prendre-la.

o Lliurar el producte com ms aviat millor.

o Donar poder a lequip: Decideix sobre qestions tcniques i es responsabilitza dels terminis.

o Incorporar la integritat: Desenvolupar de manera que es puguin fer canvis fcilment.

o Visi global: Evitar actualitzacions parcials que poden causar problemes en altres etapes.

3.3- Exemples de mtodes de desenvolupament

3.3.1.- Mtrica 3

En cascada

Distingeix 3 processos, el segon dels quals inclou 5 subprocessos.

1. Planificaci de sistemes dinformaci (PSI):

Catleg de requisits, definici darquitectura tecnolgica, model de sistemes dinformaci que han de seguir tots els projectes

que comenci lorganitzaci.

2. Desenvolupament de sistemes dinformaci.

a) Estudi de viabilitat del sistema (EVS): T en compte criteris econmics, legals, tcnics i operatius per saber si cal o no

continuar amb el desenvolupament.

b) Anlisi del sistema dinformaci (ASI): Tracta daconseguir lespecificaci detallada del sistema dinformaci (SI)

mitjanant un catleg de requisits i una srie de models que cobreixen les necessitats dels clients. Sinicia

lespecificaci del pla de proves.

c) Disseny del S.I. (DSI): Obtenim la definici de larquitectura del sistema i de lentorn tecnolgic i lespecificaci

detallada dels components del SI.

d) Construcci del SI (CSI): Construcci i prova dels components del SI a partir del conjunt despecificacions lgiques i

fsiques definides en DSI. Selaboren els manuals.

e) Implementaci i acceptaci del SI (IAS): Implantaci o acceptaci del SI en la seva totalitat.

3. Manteniment del sistema (MSI)

3.3.2.- Procs unificat (UP)

Iteratiu i incremental

Potncia 6 prctiques fonamentals:

1. Desenvolupament iteratiu i incremental

2. Gesti de requisits mitjanant casos ds.

3. Arquitectura basada en components (models i subsistemes amb una funci clara)

4. Utilitzaci de models visuals (UML)

5. Verificaci del programari a totes les etapes del procs

6. Control de canvis del programa

Suggereix que es construeixin abans les parts que incloguin ms riscos

Manifest gil



Fomenta la execuci duna arquitectura executable durant les primeres etapes del projecte.

El projecte es pot descompondre en funci del temps (fases) i en funci dels continguts (activitats)

o Totes les activitats tenen lloc durant totes les etapes encara que no amb el mateix pes.

Tamb es defineixen rols i les seves tasques

3.3.2.1.- Fases del projecte

En funci del temps

1. Inici (inception): Anlisi des del punt de vista de lorganitzaci: mbit, estimaci de recursos i riscos i casos ds. (FITA 1)

2. Elaboraci (Elaboration): Desenvolupem fins a tenir un conjunt de requisits estables, seliminen els riscos principals i es construeix la base

de larquitectura (executable). (FITA 2)

3. Construcci (Construction): Es desenvolupa la resta i sobt el producte i la documentaci. (FITA 3)

4. Transici (Transition): Es posa el producte a disposici dels usuaris (FITA 4)

FITA 1: Quan sha explicat la funcionalitat a desenvolupar, una estimaci del cost inicial, del calendari i dels riscos ens hem de preguntar:

a) Si estem dacord amb lmbit (qu ha de fer i qu no ha de fer el SI) i objectius del projecte.

b) Si estem dacord en que val la pena continuar.

FITA 2: Quan la versi s estable, shan implementat les funcions ms importants i eliminat riscos.

a) Serveix larquitectura definida per a dur a terme tot el projecte?

b) Tenim els riscos sota control?

c) Estem afegint valor a bon ritme?

FITA 3: Hem implementat tota la funcionalitat que calia implementar?

FITA 4: Hem aconseguit els objectius inicials del projecte? (Els clients han dacceptar el projecte).

3.3.2.2.- Activitats

En funci dels continguts

o Modelitzaci de negoci (bussines modelling)

Comunica experts de negoci i especialistes en tecnologia.

Es generen casos ds (bussines use cases) que descriuen els processos principals. o Requisits (requeriments)

Descriu qu fa i qu no fa el sistema amb un sistema de model de casos ds

Ex: Si lusuari fa X, el sistema fa Y.

o Anlisi i disseny (analysis and design)

Es creen models detallats dels components que formen el sistema que serveixen de guia als implementadors.

Han de permetre introduir canvis si els requisits funcionals canvien. o Implementaci (implementation)

Escriure i verificar cada component de manera unitria i generar un sistema executable.

Reutilitzaci de components. o Proves (Test)

Verificaci de la interacci entre objectes i components del sistema (fiabilitat, funcionalitat i rendiment) o Deployment

Lliurament del sistema als usuaris finals, configuraci i versions.

3.3.2.3 Rols

Stakeholder:

o Qualsevol que tingui iters en el resultat final del projecte.

Cap de Projecte

o Planifica i coordina la interacci amb els stakeholders

o Mant lequip centrat a complir els objectius del projecte

Analista

o Recull, classifica i prioritza els requisits dels stakeholders.

o Correspon a lanalista funcional.

Arquitecte

o Defineix lestructura del programari

Desenvolupadors

o Disseny, prototips de la interfcie grfica, implementaci i proves

o Inclou lAnalista Orgnic i els programadors.

Expert en proves

o Identifica, defineix, implementa i fa les proves habitualment sobre un sistema construt.



3.3.3. - Scrum (gil)

3.3.3.1.- Rols

Persones involucrades en el projecte (pollastres) stakeholders

Persones compromeses amb el desenvolupament (porcs) - equip

o Scrum Master

Assegura que sacompleixin les regles de lScrum

Elimina impediments que lequip es pugui trobar dintre de lorganitzaci. o Product Owner

Decideix que simplementa i que s ms prioritari vetllant pels interessos de lstakeholder o Team

Decideixen com fan la feina i ning els diu com lhan de fer.

3.3.4.- Artefactes

Product backlog

o Llista de requisits pendents dimplementar

o Cada entrada (histria dusuari), t associada una estimaci del valor que aporta a lorganitzaci i del seu cost.

Sprint backlog

o Backlog per a una iteraci (sprint) concreta

o Cada histria dusuari (entrada) es descompon en tasques dentre 4 i 16 hores de durada.

Release burndown chart

o Grfic que mostra el progrs de lequip en funci del nombre dhistries dusuaris que falten per implementar.

Sprint burndown

o Burndown per a una iteraci concreta.

3.3.5.- Prctiques

Sprint planning meetin:

o Reuni abans dun sprint.

o Es dedueix quines histries simplementaran i es crea lsprint backlog.

Daily Scrum

o Reuni diria on es responen 3 preguntes amb lobjectiu didentificar oportunitats dajudar-se els uns als altres.

Qu van fer ahir?

Qu pensen fer avui?

Quins impediments shan trobat que els han impedit avanar.

Sprint review meeting

o En finalitzar un sprint es revisa la feina i sensenya una demo a qui estigui interessat.

Sprint retrospective

o Es reflexiona sobre el que ha passat a lsprint

o Sidentifiquen oportunitats de millora en el procs de desenvolupament.

4.- Tcniques i eines de lEnginyeria del Programari

4.1.- Tcniques basades en la reutilitzaci

Avantatges

o Oportunitat

Menys programari a desenvolupar

Ms rapidesa o Disminuci de costos

Components, costos de desenvolupament i manteniments compartits. o Fiabilitat

Ja ha estat provat. o Eficincia

El programador del component sespecialitza i el fa molt eficient. o Reutilitzaci

Saplica des de la presa de requisits fins a la implementaci i desplegament.

Inconvenients

o Sha de desenvolupar un component pensant en la reutilitzaci

o Sha de fer una documentaci exhaustiva

o Qualsevol defecte es propagar a tots els sistemes que el fan servir.

o Sha danar molt en compte amb la compatibilitat entre versions.



4.1.1.- Desenvolupament orientat a objecte

Ocultaci dinformaci

o Es defineixen els aspectes visibles (i utilitzables) i els que no.

Interfcie

Part visible que cal que els programadors coneguin.

Implementaci

Part dels components oculta als usuaris.

Abstracci

o Sagrupen els aspectes comuns a una srie dobjectes que noms shan de definir una vegada (classes) i es creen noves

classes indicant noms les caracterstiques especfiques.

o Sagrupen en biblioteques que es poden fer servir sense necessitat de saber com han estat implementades.

4.1.2.- Bastiments

Conjunt de classes que a ms reutilitzen el disseny del sistema.

Les classes del bastiment criden a les nostres classes.

4.1.3.- Components

Conjunt de classes que es reutilitzen com un tot.

Molt estrictes en quant a la ocultaci dinformaci.

Sha de definir clarament:

o La seva interfcie (Operacions a invocar i parmetres)

o El seu contracte

Postcondicions: Efectes dinvocar una operaci.

Precondicions: Condicions que cal verificar per evitar un error.

Es poden desenvolupar en un llenguatge diferent al del sistema (IDL)

Shan de prevenir els error i minimitzar les conseqncies dun mal s.

4.1.4.- Desenvolupament orientat a serveis

Unitats allades entre s que collaboren a travs duna xarxa (habitualment remotament)

Cicle de vida independent

Es desenvolupen i despleguen de manera independent.

4.1.5.- Patrons

Dona nom, motiva i explica de manera sistemtica un disseny general que permet solucionar un problema recurrent de disseny en

sistemes orientats a objectes.

Avantatges

o Reutilitzar les solucions i aprofitar lexperincia prvia daltres que han dedicat ms esfor a entendre els contextos, solucions

i conseqncies.

o Beneficiar-se dels coneixements mitjanant un enfocament metdic

o Comunicar i transmetre lexperincia a altres persones (si en definim de noves)

o Establir un llenguatge com per millorar la comunicaci

o Encapsular coneixement sobre un problema i les seves solucions assignant-li un nom al que ens puguem referir fcilment.

o No haver dinventar una soluci al problema

Cal documentar

o Definir un nom per fer referncia al patr. (Augmenta el nivell dabstracci)

o Documentar el problema. (Qu resol el patr?)

o Documentar la soluci.

Plantilla que descriu els elements que formen part del patr, les seves relacions, responsabilitats i collaboracions. o Documentar les conseqncies

Resultats i compromisos derivats de laplicaci del patr (cost i beneficis)

4.1.6.- Lnies de producte

Estratgia de marketing que consisteix a oferir de manera individual, una srie de productes relacionats entre s.

Permet mantenir una identitat base comuna a tots els productes de la lnia i oferir un producte adaptat als gustos del consumidor.



4.2.- Tcniques basades en labstracci

Labstracci permet desenvolupar sistemes fent servir llenguatges ms propers als llenguatges naturals que no pas els llenguatges de

les computadores.

Lenginyeria dirigida per models sn un conjunt de tcniques basades en labstracci que veuen el desenvolupament del programari

com un desenvolupament de models (s igual el llenguatge) que sn lartefacte principal existeixi o no codi font.

4.2.1.- Arquitectura dirigida per models (MDA)

T com a objectiu separar la lgica del negoci i aplicaci (la funcionalitat) de la tecnologia en la que simplementar el sistema.

Generalment models grfics

Fase a) Model independent de la computaci (CIM)

o Tamb conegut com a model del negoci o model del domini

o Comunica els requisits dels experts del domini als experts del disseny i construcci del programari.

Fase b) Platform independent model (PIM)

o Model ms proper a la tecnologia per independent de la plataforma

Fase c) Platform Specific Model (PSM)

o Conjunt de regles de transformaci envers diferents plataformes.

o Els PSM pot ser compilat i executat sobre la plataforma.

MDA preveu altres possibilitats com generar codi a partir del PIM o un PSM.

4.2.2.- Llenguatges especfics del domini (DSL)

Llenguatges adaptats al domini del sistema que volem desenvolupar.

4.3.- Eines de suport a lenginyeria de programari (CASE)

Eines que ajuden a lenginyer de programari a aplicar els principis de lenginyeria al desenvolupament de programari.

Automatitzen tasques de lenginyer i el tractament informtic dels productes del seu treball.

Eines de gesti del procs

o Ajuden a la definici, modelitzaci, execuci o gesti del procs de desenvolupament mateix.

Eines de gesti de projectes

o Estimaci, planificaci, anlisi de risc

Eines de gesti de requisits

o Recollida, documentaci, gesti i validaci de requisits.

o Poden ser genriques (documentaci textual) o especfiques (histries dusuari o casos ds)

Eines de modelitzaci

o Creaci de models (ex. UML) validant en ms o menys grau la correctesa de la sintaxi utilitzada.

Eines dEnginyeria Inversa

o Analitza un programari per a comenar a aplicar la enginyeria.

Entorn integrat de desenvolupament

o Codificaci, disseny, proves i depuraci.

Eines de construcci de programari

o Compilen arxius i lempaqueten en el format adequat per a lentrega.

Eines de proves

o Defineixen proves, les executen i gestionen els resultats.

Eines de desenvolupament dinterfcies grfiques dusuari

o El desenvolupador pot arrossegar components a la pantalla visualment i noms programar la part dinmica.

Eines de mesura de mtriques

o Mesures automatitzades que permeten valorar la qualitat del programari en quant a arquitectura, disseny, codi, proves

Eines de gesti de la configuraci i del canvi

o Gestionen el canvi del programari al llarg de la seva vida.

o Gestionen versions i la integraci al producte final.



5.- Estndards de lenginyeria de programari

5.1.- Llenguatge unificat de modelitzaci (UML)

Unifica la notaci grfica que fan servir els diferent mtodes de desenvolupament amb independncia del mtode emprat.

No indica quins modes o artefactes es poden crear. Ofereix una srie de diagrames que els diferents mtodes poden fer servir per als

seus artefactes.

Un mateix tipus de diagrama es pot fer servir en diferents contextos per a artefactes diferents.

5.2.- Software engineering body of knowledge (SWEBOK)

Gua que descriu el coneixement mpliament acceptat per la comunitat denginyers i on els podem trobar.

Objectius:

o Promoure una visi consistent de lenginyeria del programari a nivell mundial.

o Establir fronteres entre lenginyeria de programari, les cincies de la computaci, la gesti de projectes, lenginyeria de

computadors i les matemtiques.

o Caracteritzar els continguts de la disciplina de lenginyeria del programari.

o Proporcionar un accs organitzat al cos de coneixement de lenginyeria de programari.

Swebok organitza el coneixement en 10 rees clau:

1) Requisits del programari 6) Gesti de la configuraci del programari

2) Disseny del programari 7) Gesti de lenginyeria del programari 3) Construcci del programari 8) Procs de lenginyeria del programari 4) Proves de programari 9) Eines i mtodes de lenginyeria del programari 5) Manteniment del programari 10) Qualitat del programari

5.3.- Capability maturity model integration (CMMI)

Gua per a la millora dels processos implicats en el desenvolupament del programari.

Tres rees dactivitat

o rea 1: Gesti de Serveis (CMMI SUC)

Destinat a provedors de serveis per ajudar a reduir costos, millorar la qualitat i la predictibilitat o rea 2: Adquisici (CMM-ACQ)

Ajuda a qui contracta productes o serveis a millorar les relacions amb el provedors, els processos de contractaci i control i ladequaci del producte / servei adquirit a les necessitats de lorganitzaci.

o rea 3: Desenvolupament (CMMI-DEV)

Dirigit a organitzacions que desenvolupen programari.

Ajuda a millorar la satisfacci dels clients, la qualitat del producte i el procs de desenvolupament.

5.4.- Project management body of knowledge (PMBOK)

Gua de bones prctiques per a la gesti del projecte.

Segons SWENOK queda fora de lmbit de lenginyeria.

gesti de la integraci gesti del risc

gesti de labast gesti dels RRHH gesti del temps gesti de la comunicaci

gesti de la qualitat gesti de les compres i adquisicions

gesti dels costos



TEMA 2.- Orientaci a objectes

1.- Qu s lorientaci a objectes? Codi mquina

o Conjunt limitat dinstruccions que poden entendre els processadors.

Llenguatge assemblador

o Llenguatge dinstruccions molt senzilles que es corresponen gaireb una a un amb les operacions que pot entendre el

processador.

Llenguatges dalt nivell o procedimentals

o Permeten expressar-se a un nivell dabstracci molt ms alt que els assembladors.

o Es basen en la definici de procediments per descompondre el problema que es vol tractar en unitats ms petites creant una

abstracci de la mquina sobre la que sexecuten.

Llenguatges orientats a objectes

o En comptes de basar-se en all que la mquina pot entendre, es basen en all que les persones volen comunicar.

Anlisi orientada a objectes

o Consisteix a aplicar els conceptes i idees dels llenguatges orientats a objectes a lanlisi de sistemes.

o Especialment popular UML

2.- Classificaci i abstracci

Un sistema orientat a objectes est format per una srie delements autnoms (objectes) que es comuniquen els uns amb els altres per

tal de dur a terme les seves tasques.

De cada objecte hem de conixer les seves responsabilitats. s a dir: qu sap, amb quins altres objectes es pot comunicar o quines

tasques se li poden demanar.

2.1.- Classificaci

La classificaci simplifica la descripci del sistema identificant els objectes que tenen les mateixes responsabilitats.

El grup sanomena classe i lobjecte instncia.

Les responsabilitats dels objectes duna classe es poden dividir en

o Dades: Informaci que coneixen

o Associacions: Objectes que coneixen

o Operacions: Tasques que poden dur a terme

2.2.- Abstracci

Mecanisme amb que decidim quines de les possibles responsabilitats associades a una classe formaran part de la seva definici.

2.3.- Descripci de les classes dobjectes.

2.3.1.- Atributs

Ens diuen quina informaci coneixem sobre els objectes duna classe determinada.

Consta dun nom i dun tipus (que ajuda a entendre millor la informaci que semmagatzema)

Poden emmagatzemar un valor diferent per a cada instncia (mbit dinstncia) o tenir un valor per a totes les instncies de la classe

(mbit de classe) fet poc habitual.

Pot ser que en alguna instncia un atribut no tingui valor (atributs opcionals) o que en tingui ms dun (atributs multivaluats)

2.3.2.- Associacions

Declaren les relacions amb altres objectes.

Formen part del conjunt dinformaci (dades) que gestiona un projecte.

Es diferencien dels atributs en que fan referncia a dos objectes o ms com a part de les seves responsabilitats.

La relaci dassociaci entre dues instancies s recproca i no tindran mai mbit de classe.

Dues instncies poden estar relacionades diverses vegades entre elles per amb rols diferents (ciutat de naixement ciutat de

residncia) Associaci recursiva.

Una relaci entre instncies pot tenir un valor (instancies de lassociaci). A aquestes classes se les anomena classe associativa. (Nota

dun alumne a una assignatura). Poden tenir atributs, operacions, mtodes i associacions.

Les associacions poden ser entre 3 o ms classes (associacions n-ries). (Alumne semestre assignatura)



2.3.3.- Operacions

Ens diuen quines tasques poden dur a terme les instncies duna classe.

El conjunt dinstruccions que diuen com ho han de fer sanomena mtode.

Les operacions formen part de la interfcie i els mtodes de la implementaci.

Quan un objecte vol que un altre executi el comportament definit en una de les seves operacions, diem que invoca o crida loperaci o

que li envia un missatge.

3.- Ocultaci dinformaci i encapsulament. Lencapsulament s el mecanisme de lorientaci a objectes que ens permet ocultar informaci i definir quins atributs, operacions i

associacions dun objecte seran visibles i quins estaran ocults.

La visibilitat s la propietat dun atribut, associaci o operaci que defineix quins objectes el poden veure

o Visibilitat pblica: Qualsevol objecte hi t accs.

o Visibilitat privada: Noms els objectes de la mateixa classe hi tenen accs. Les subclasses tindran latribut per no shi podr

accedir (ni des de la classe, ni des de la subclasse)

o Visibilitat protegida: Noms els objectes de la mateixa classe o duna subclasse hi tenen accs.

o Visibilitat de paquet: Noms els objectes del mateix grup o paquet hi tenen accs.

Paquet: Agrupaci delements dun sistema orientat a objectes per a facilitar-ne lorganitzaci. Pot contenir classes i altres paquets.

4.- Herncia i polimorfisme

4.1.- Herncia

s una classificaci jerrquica dinstncies de diferents classes amb responsabilitats comuns.

Les subclasses hereten la definici duna superclasse ja que les caracterstiques daquesta ltima li sn comunes i nafegeix de prpies.

El procs de trobar classes ms generals a les que ja tenim sanomena generalitzaci.

Trobar classes ms especfiques a les que ja tenim sanomena especialitzaci.

4.2.- Polimorfisme

s la capacitat dun objecte de presentar-se amb formes (interfcies) diferents segons el context.

Est basat en la visi que els altres objectes tenen de lobjecte que no pas en lobjecte en s.

Una operaci polimrfica s una operaci que t un comportament diferent en funci de la classe concreta a la que pertanyi lobjecte.

Es pot redefinir.

Les classes que no es poden instanciar directament (per qu no tenen cap comportament que no pertanyi a una subclasse sanomenen

classes abstractes.

Una classe abstracta pot definir operacions abstractes que no tenen associat un mtode (comportament) en la classe en que es defineix.

3.- Requisits

1.- Introducci als requisits

s una caracterstica observable del nostre sistema que satisf una necessitat o expressa una restricci que afecta al programari que

estem desenvolupant.

Els stakeholders dun projecte sn aquelles persones o entitats que tenen algun impacte o inters en aquest. Els stakeholders poden NO

ser usuaris.

Els requisits ens diuen qu s el que els diferents stakeholders esperen del nou sistema.

1.3.- Tipus de requisits

Requisits funcionals

o Fan referncia a la funcionalitat que ha de proporcionar el sistema (qu ha de fer)

o Indiquen el comportament del sistema davant dels estmuls que li arriben del exterior

Requisits NO funcionals

o Expressen restriccions sobre el conjunt de solucions possibles (com ho ha de fer)

o Afecten gran part del sistema.



1.4.- Requisits al llarg del desenvolupament

Obtenci de requisits: Dels stakeholders

Gesti dels requisits: Prioritats, contradiccions

Documentaci dels requisits: Amb independncia de si lartefacte forma part de la documentaci final del sistema.

Verificaci del sistema: Si sacompleixen els requisits.

2.- Obtenci dels requisits

Requisits candidats

o Identificar els stakeholders del sistema

o Identificar els requisits de cadascun dels stakeholders

2.1.- Identificaci dstakeholders

2.1.1.- Brainstorming o pluja didees

Tamb per identificar requisits dun usuari

Una sessi de brainstormig consta de:

o Creaci dun grup de treball: Rols diferents.

o Brainstorming inicial: Proposar tantes idees com es sigui capa dimaginar.

o Organitzaci i consolidaci del conjunt inicial

o Refinament: Descriure amb ms detall les propostes.

2.1.2.- Modelitzaci de rols dusuari.

Mitjanant brainstorming

Agrupem segons rol.

Descrivim caracterstiques principals

o Freqncia ds del sistema

o Nivell de coneixement del domini del problema

o Nivell informtic

o Per a qu emprar el sistema

Es pot combinar amb la tcnica de persones. (Crear un personatge amb biografia)

2.1.3.- Representant dels stakeholders

Persona que parla en nom dels stakeholders i ens transmet els requisits.

o No es tan fiable com un stakeholder.

o Pot no ser un usuari del sistema o fer-ne un s diferent i representar-se a s mateix.

o Els desenvolupadors NO son bons representants,

o Els comercials poden centrar-se en el que faci vendre el producte.

o Tamb poden ser formadors, analistes de negoci, experts del domini

2.2.- Identificaci de requisits

2.2.1.- Entrevistes i qestionaris

Escollir correctament els entrevistats. (Mostra representativa i significativa)

Evitar respostes condicionades.

Evitar respostes limitades pel coneixement actual.

Aportar informaci sobre el cost de les alternatives.

2.2.2.- Observaci i prototipatge

Sobserva als usuaris mentre fan servir un sistema dinformaci, ja sigui un sistema existent, una implementaci parcial del sistema final o

un prototip per detectar problemes amb la usabilitat.

Un prototip no forma part del producte definitiu. Un cop obtinguts els requisits, sabandonar.



2.2.3.- Llistes predefinides (checklists)

Requisits NO funcionals

o Requisits de presentaci

Aspectes visuals

Imatge corporativa o Requisits dusabilitat i humanitat (Ergonomia)

Eficincia ds. (Rapidesa)

Facilitat de memoritzaci. (Volum dinformaci que ha de memoritzar un usuari no habitual)

Taxa derror. (del usuari)

Satisfacci

Retroalimentaci. (Informaci que necessita lusuari per confiar que el producte fa el que ha de fer.

Altres

Personalitzaci

Internacionalitzaci

Localitzaci

Corba daprenentatge

Comprensibilitat

Accessibilitat

o Requisits de compliment

Velocitat

Seguretat

Precisi (Nombre de decimals)

Fiabilitat (Temps admissible entre dos caigudes de sistema)

Disponibilitat (Percentatge de temps en que el sistema estar disponible.

Robustesa (Capacitat del sistema per a continuar funcionant en circumstncies inesperades)

Volum usuaris / Volum de dades (Capacitat)

Escalabilitat / Extensibilitat (Com sespera que creixin al llarg del temps)

Longevitat o Requisits operacionals i dentorn

Com els usuaris interactuen amb el sistema

Com interactua el sistema amb altres sistemes externs (interfcies)

Distribuci i programaci de lliuraments. o Requisits de manteniment i suport dusuari

o Requisits de seguretat

Control daccs, integritat, privacitat

Informaci dauditoria o Requisits dimmunitat

Com es defensar el sistema davant dun atac. o Requisits culturals i poltics

o Requisits legals

3.- Gesti de requisits

La bona gesti de requisits ens permet maximitzar el valor obtingut pel projecte de desenvolupament i s una part fonamental de la

gesti del projecte.

s necessari que tothom treballi amb la mateixa informaci.

3.1.- Estimaci de requisits

Lestimaci sha de fer en unitats reals (donen un cost intelligible) o fictcies (obliguen a fer informaci histrica real per a fer clculs de

recursos) i faciliten ajustar les estimacions al llarg del projecte.

Tcniques destimaci

o Comparaci: Abstraiem la feina necessria per a implementar el requisit i ens trobem alguna equiparable prviament

estimada. (No es pot aplicar a primeres estimacions)

o Triangulaci: Comparar amb un requisit ms senzill i un ms complicat.

o Planning Poker: Tcnica gil i collaborativa. Cadasc fa una aposta del cost del requisit. Si no hi ha consens sexplica als

dems els arguments. Es repeteix fins que hi hagi consens.



3.2.- Prioritzaci de requisits

Hem de resoldre la prioritat relativa que cada stakeholder atorga al requisit, a ms, poden haver contradiccions entre requisits.

o Tcnica del 100$

Selecci de requisits

o Sha de fer a cada lliurament del projecte i al principi de cada iteraci en les metodologies iteratives.

o Un mtode consisteix en seleccionar els ms prioritaris i afegir requisits mentre quedin temps i recursos. Si un no hi cap, podem

treurem un de la llista o passar el segent en prioritat (fins que no quedi lloc)

Tamb sha de tenir en compte

o El risc

o El mercat potencial

o La finestra de mercat (perode de temps en que el producte s interessant)

o Preu

o Competncia

o ROI

4.- Documentaci (especificaci) dels requisits

Lartefacte que documenta el conjunt de requisits seleccionats pel projecte sanomena especificaci.

Lespecificaci de requisits recull el contracte entre desenvolupadors i stakeholders i serveix com a eina de comunicaci per a tots dos

grups.

Lestil i formalitat dependr del projecte, del context en que es desenvolupa i de les persones que hi participen. Tamb shaur de tenir

en compte el cost dintroduir un canvi en els requisits.

Una de les tasques de lenginyer de programaci s avaluar el punt anterior.

4.1.- Qualitats duna bona especificaci de requisits

Correcta

o s correcta si tots els requisits ho sn.

No ambigua

o Cada requisit t una nica interpretaci possible.

o Possibilitat de fer servir llenguatges formals

o Definir un glossari si cal.

Completa

o Com a mnim dels requisits seleccionats

o Shan denumerar tots els requisits de tots els stakeholders

o Definir el comportament del sistema especificat per a tot tipus dentrades de dades i situacions.

o Referenciar totes les taules, figures i diagrames del document.

Consistent

o Cap subconjunt de requisits enumerats s contradictori

Requisits etiquetats

o Importncia

o Cost

o Estabilitat (canvis al llarg del temps)

Verificable

o Si tots els requisits tenen un procs finit i de cost efectiu per determinar si el programari satisf o no el requisit.

Modificable

o Lestructura i la redacci permet fer canvis de manera fcil i constant

o Ha de tenir taules de continguts, ndex, referncies creuades i no se redundant.

Traable

o Si cada requisit est identificat i facilita la referncia als artefactes desenvolupats al llarg del projecte (altres documents,

programari desenvolupat, proves)

o s important per els canvia a mig de projecte.



4.2.- Bones prctiques 1. Identificadors de requisits

Ha de descriure de manera breu el valor numric del requisit.

No pot ser un identificador numric

2. Punt de vista global

Evitar escriure necessitats de parts del sistema des del punt de vista del desenvolupador

3. Granularitat

Equilibri entre la llista de requisits i el detall

Depn del mtode de desenvolupament, de les necessitats de lequip, del seu coneixement

4. Interfcie grfica dusuari

Evitar donar-les per suposades

5. Condicions dacceptaci

A cada requisit documentar les condicions dacceptaci

6. s de plantilles

4.3.- Histries dusuari

s leina de documentaci ms habitual en el mtodes gils

Components

o Descripci escrita de la histria

o Seguit de converses per definir i aclarir els detalls de la histria

o Conjunt de proves que documenten els detalls i que determinen quan la histria est implementada completament.

La llista total dhistries dun producte sanomena pila del producte (backlog)

o Ha de tenir forma diceberg on a la part de dalt tindrem en compte les histries de la iteraci actual.

Les histries molt grans sanomenen pics

Les histries dusuari poden ser tils tamb per a requisits NO funcionals.

5.- Casos ds Contracte entre el sistema i els stakeholders mitjanant la descripci del comportament observable del sistema.

5.2.- Actors i stakeholders

Actor principal

o Qui vol fer servir el sistema per a satisfer un objectiu concret.

o Pot ser persona, organitzaci o sistema informtic.

o Ha dinteractuar amb el sistema i tenir un comportament propi.

Actors secundaris

o No fan la petici al sistema per hi participen

5.3.- Anatomia dun cas ds

Nom

o Ha dindicar qu aconsegueix lactor principal en la seva interacci amb el sistema (sol comenar amb un verb)

o Es pot associar tamb un identificador

Actors

o I actor principal

Objectius i mbit

o Identificar els objectius i interessos dels actors i dels stakeholders que NO hi participen.

o Lmbit diu qu queda dintre i qu queda fora del sistema (Tasca, Usuari, General)

Precondicions i garanties mnimes

o Precondicions

Descriuen les condicions que shan de donar per a que es pugui dur a terme la interacci descrita. o Garanties mnimes

All que el sistema ha de garantir en qualsevol escenari (fins i tot derror) o Garanties mnimes en cas dxit

El que el sistema ha de garantir per a considerar amb xit la interacci



Escenaris

o Cada uns de les possibilitats en que pot acabar un escenari dxit.

o Lescenari principal ha de ser un escenari dxit

o La resta descenaris (xit o error) formen escenaris alternatius o extensions

o Tota extensi comena perqu en un pas de lescenari principal es dna una condici que dna pas a lexecuci de lextensi.

Sempre shan descriure reverenciat als esdeveniments de lescenari principal.

o Tots els escenaris descriuen:

Interaccions entre lusuari i el sistema.

Validacions per part del sistema

Canvis a lestat intern del sistema

5.4.- Classificaci de casos ds

5.4.1.- Per nivell dels objectius

Usuari (user goals)

o s el ms important

o Sn els objectius concrets que els actors principals volen aconseguir en fer servir el sistema. (Escriure un missatge al frum)

General (summary goals)

o Serveixen per a donar context o agrupar els objectius dusuari. (Resoldre un dubte al frum)

Tasca (subfunctions)

o Sn el nivell ms concret

o Noms ofereixen una part del valor que lactor espera. (Adjuntar un arxiu a un missatge)

5.4.2.- mbit

mbit dorganitzaci

o Modelitzem com a cas ds el comportament de lorganitzaci o duna de les seves unitats com un tot.

o Els sistemes i persones de dins lorganitzaci no apareixen com a actors

o Altres persones, organitzacions o sistemes externs amb qui sinteractua s seran actors.

mbit de sistema

o Estem modelitzant un sistema informtic

o Tots els components (maquinari / programari) sn interns i no apareixen com a actors

mbit de subsistema

o Estem modelitzant una part del sistema informtic com ara un component

o Els altres components i tots els usuaris directes del component seran actors en el nostre model

o mbit rellevant noms quan volen deixa explcitament fora destudi una part del sistema.

5.5.- Identificaci i descripci de casos ds

5.5.1.- Identificaci dactors i objectius

Actor iniciador dun cas ds

o Qui porta a terme una acci que provoca lexecuci del cas ds.

o No t per qu ser lactor principal

Si lusuari actua en nom duna altra persona, lactor principal s laltra persona. (Exemple: centraleta telefnica)

Si lactor iniciador s un rellotge, lactor principal s lstackholder interessat en que el cas ds sexecuti.

Un cop identificats els actors, shan denumerar els objectius que volen obtenir del sistema.

Per cada objectiu tindrem un cas ds que descrigui linteracci de lactor principal amb el sistema per tal de satisfer lobjectiu.

5.5.3.- Relacions entre casos ds: inclusi

A vegades quan documentem els escenaris ens trobem que s til fer-ne referncia a un altre.

o O b per qu s com (inclusi per reutilitzaci)

o O b per qu el podem descompondre en casos ds amb objectius ms concrets (inclusi per descomposici)

Tamb podem separar en casos ds les extensions molt llargues

Tamb es poden utilitzar casos ds com extensions duna altra que no admet modificacions.



5.6.- Casos especials

Autenticaci dusuaris

o Quan s obligatori com a precondici, si no com a un pas ms de lescenari.

Alta dusuari

o Es pot documentar com un cas dus dusuari o de tasca

Manteniment CRUD

o Es posen les operacions dalta, baixa i modificaci com a escenaris principals a la consulta en un mateix cas ds.

Manteniment de molts CRUD

o Podem tenir el cas ds parametritzat i fer-lo servir de plantilla

o Desprs crearem el nou cas ds fent referncia a la plantilla i indicant-ne els parmetres.

TEMA 4 Anlisi UML

1.- Anlisi orientada a objectes amb UML

1.2.- Llenguatge UML

Propsit general

Visual

Independent del mtode de desenvolupament

Usos

o Llenguatge per a fer un croquis (informal)

o Llenguatge per a fer un plnol (detallat)

o Llenguatge de programaci

Perspectives

o Conceptual El model representa una descripci dels conceptes del domini

o Programari El model representa el model informtic

1.2.3.- Tipus de diagrames

Diagrama de casos ds: Modelitza els casos ds del sistema i els actors

Diagrama de classes: Modelitza les classes objectes i les seves relacions (en la estructura i NO en el comportament)

Diagrama dobjectes: No representa classes si no instncies

Diagrama de paquets: Dependncia entre paquets (agrupacions de qualsevol cosa)

Diagrama de comunicaci: Modelitza la interacci entre diversos objectes (estructura i no funcionalitat)

Diagrama de seqncia: Modelitza l interacci entre diversos objectes (emfatitzant la seqncia temporal)

Diagrama dactivitats: Semblant als diagrames de flux

Diagrames de visi general dinteracci: Combinaci de diagrames de seqncia i activitat

Diagrames destats: Modelitza com afecta a un objecte els diferents esdeveniments del sistema (estats, transicions)

Diagrames de components: Modelitza components del sistema i interfcies

Diagrames destructura composta: Modelitza lestructura interna dun component en temps dexecuci.

Diagrames de desplegament: Distribuci fsica dels diferents artefactes del programari.

Diagrames de temps

2.- Model dels casos ds No substitueix la descripci textual dels casos ds per qu no inclou informaci sobre el comportament del sistema

Permet relacionar visualment actors i casos ds

Dna una visi rpida de la funcionalitat que el sistema ofereix als diferents actors.

El diagrama de casos ds NO mostra la seqncia desdeveniments dun cas ds

Sha devitar tenir casos ds de nivell diferent. Si cal crear dos diagrames.



2.2.- Diagrama dactivitats



3.- Modelitzaci de la interfcie

Descriu

o De quina manera el sistema presenta la informaci als usuaris?

o Com navega lusuari a travs de la informaci que li mostra el sistema per aconseguir els seus objectius?

o Com es relaciona el comportament indicat al model de casos ds amb la interfcie dusuari?

Casos ds essencials

o Descriuen les interaccions actor / sistema de manera independent a la tecnologia i implementaci

Casos ds concrets

o Tenen en compte la tecnologia i la implementaci

3.2.- Models de les pantalles

Ha de deixar clar

o Quina informaci es mostra

o La distribuci de la informaci a la pantalla

o Quines accions pot prendre lusuari a partir de la informaci mostrada

o Quin s el procs que segueix lusuari per a completar el cas ds



3.2.1.- Diagrama destat de les pantalles (mapa navegacional)

s un model que dna informaci sobre el flux de pantalles que pot seguir lusuari.

3.3.- Contractes de les operacions del sistema

Documenten formalment els requisits del sistema. Tres parts:

o Signatura

Nom de loperaci, parmetres dentrada, parmetres de sortida. o Precondicions:

Obligacions que ha de complir qui crida loperaci per qu el sistema sexecuti correctament.

Si no sacompleixen el sistema rebutja lesdeveniment o Postcondicions

Condicions que el sistema es compromet a que siguin certes un cop executada loperaci.

Exemple:

obtenirNimbreMissatgesCarpeta (nomCarpeta: String): Integer pre: El nom de la carpeta es correspon a un carpeta del frum post: El resultat s el nombre de missatges amb independncia de si shan llegit o no.

4.- Model de domini

No hi han restriccions respecte a la nomenclatura, per nosaltres:

o Farem servir minscules amb general

o Les classes, associacions i tipus datributs comenaran en majscula.

o No es faran servir espais. Posarem en majscula la primera lletra de cada paraula

o No es faran servir carcters fora del rang ASCII

4.2.- Classes

En UML es representa amb una caixa amb 3 compartiments (2 opcionals):

4.2.2.- Tcniques de modelitzaci

Identificar les classes del domini

Coad, Lefebvre i Luca (1999) Larman (2005)

Participants, llocs i coses Transaccions, lnies de transacci, producte o serveis

Rols Esdeveniments importants

Moments o intervals Catlegs i descripcions de coses

Descripcions Contenidors fsics i lgics i elements que contenen

Sistemes externs

Enregistraments

Llocs, objectes fsics i reals

Nomenclatura

o Regla del cartgraf

Terminologia que fa servir la gent del domini que es modelitza

No afegir res que no sigui del domini que analitzem

No confondre classes del domini amb classes del programari

o No assignar a les classes responsabilitats del comportament

o No assignar operacions



4.3.- Atributs

4.3.1- Notaci UML

Dins de la caixa que representa una classe sescriu latribut i opcionalment dos punts seguits del tipus datribut i la multiplicitat

Tipus

o Nombres

Enters positius (Nat)

Enters (Int)

No enters (Real) o Textos

Strings sense format o amb format o Booleans

o Informaci temporal

Data

Hora

Moment (1 de gener de 1980 a les 12:43)

Durada o Quantitas

Import

Longitud

Temperatura

Massa o Altres valors amb identitat prpia

Color

Coordenada GPS

CodiPostal

NumeroTelefon

Notaci atributs

o [0..1] Univaluat opcional

o 1 Univaluat obligatori (si no es posa sassumeix)

o [1..*] Com a mnim un valor

o [3..5] Entre tres i cinc valors

o * qualsevol nombre incls 0

4.4- Associacions

Els noms de lassociaci seran verbs de forma que NomClasse NomAssociaci NomClasse sigui una frase amb sentit.

Els noms dels rols i associacions sn opcionals. Si no sindica el nom del rol sassumir el nom de la classe (en plural si s multivaluat)

Cal indicar el nom del rol si hi pot haver confusi o s una associaci recursiva.

Classes associatives

Permeten afegir atributs i associacions a les instncies dassociaci

Es representen amb una lnia discontnua

Es poden representar normal



Errades freqents

s de claus foranies com a atribut

Classes dassociaci amb atribut erronis que pertanyen a les classes que associa.

4.5.- Herncia

UML lanomena generalitzaci.

4.5.2.- Tcniques de modelitzaci

Modelitzaci de lestat dels objectes

Una herncia s dinmica quan una instncia pot canviar de subclasse al llarg de la seva vida.

2 maneres de resoldre

o Una sla classe amb un discriminador i atributs opcionals

o Crear una subclasse estat de la que pengin les subclasses

Modelitzaci dels rols dobjectes i persones.

Una herncia s overlapping quan una mateixa instncia pot pertnyer a ms duna subclasse alhora.

Resoldrem creant 2 classes (sense herncia) com a classes associades a la superclasse.

4.6.- Informaci derivada i regles didentitat

4.6.1.- Regles dIntegritat

Que la informaci no sigui contradictria o incompleta

Les restriccions que no poden ser representades en UML han danar en un document que les recopili com les claus (conjunts datributs

que identifica les instncies de manera nica.

4.6.2.- Informaci derivada

El seu valor es pot deduir dinformaci ja modelitzada.

En UML sindica posant una (/) davant del nom encara que sha dexpressar textualment

4.7.- Classe i atributs

Un tipus de dada es representa en UML amb un classificador amb lestereotip

Les enumeracions es representen amb i la llista enlloc dels atributs.

Visibilitat: No sindica al model del domini

o + Visibilitat pblica

o - Visibilitat privada

o # Visibilitat protegida

o Visibiitat paquet

[Real Only], [Ordered] => no s el mateix (345,879] que [879,345)

Lmbit de classe es subratlla i els dinstncia no.

4.8.- Associaci delements avanats

4.8.1.- Composici

Si destrum una instncia composta, tots els seus components sn tamb destruts.

No pot haver instncies de la classe component que no formin part duna i noms una instncia composta

No podem agafar una instncia component i canviar-la de compost.

No es fan servir modelitzant dominis

Enginyeria Del Programari

Documents

Transcript of Enginyeria Del Programari