Enginyeria Del Programari
-
Upload
victorpedraza -
Category
Documents
-
view
30 -
download
2
description
Transcript of Enginyeria Del Programari
-
Enginyeria del Programari (05.565)
Universitat Oberta de Catalunya (UOC)
http://furniman.blogspot.com
-
Enginyeria del Programari (05.565)
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
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 3 de 26
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
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 4 de 26
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
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 5 de 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
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 6 de 26
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
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 7 de 26
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
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 8 de 26
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
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 9 de 26
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.
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 10 de 26
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.
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 11 de 26
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.
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 12 de 26
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.
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 13 de 26
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
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 14 de 26
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)
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 15 de 26
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.
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 16 de 26
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.
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 17 de 26
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.
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 18 de 26
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.
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 19 de 26
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
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 20 de 26
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.
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 21 de 26
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.
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 22 de 26
2.2.- Diagrama dactivitats
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 23 de 26
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
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 24 de 26
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
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 25 de 26
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
-
Enginyeria del Programari (05.565)
http://furniman.blogspot.com Pgina 26 de 26
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