¡Descarga Anàlisi de requeriments del software y más Diapositivas en PDF de Ingeniería del Software solo en Docsity!
1
TEMA 2
ANÀLISI DE REQUERIMENTS DEL SOFTWARE
- Introducció.
- Tipus de requeriments.
- Tasques a realitzar.
- Comprensió del problema.
- Tècniques de comunicació.
- Problemes associats.
- Característiques dels mètodes de modelat (Principis de l’anàlisi).
- Especificació de requeriments.
- Propietats desitjables d’una especificació.
- Estàndard d’una especificació de requeriments.
- Revisió i validació de l’especificació.
2
Introducció
- Increment en la complexitat dels problemes => Necessitat d’una fase per analitzar els requeriments del sw.
- Dues tasques en l’etapa d’anàlisi:
- Comprensió del problema.
- Especificació de requeriments.
- Requeriments: conjunt d’idees que el client té sobre què ha de ser el software a desenvolupar. Són les prestacions del sistema.
2.
3
Classificació de requeriments
- Requeriments funcionals.
- Requeriments no funcionals.
- Requeriments de rendiment.
- Restriccions de disseny.
- Requeriments sobre les interfícies externes.
- Objectius de disseny.
- Decisions de disseny.
2.
4
Requeriments funcionals
- Descripció del comportament desitjat del software.
- Cada requeriment funcional expressa una relació entre les entrades i sortides del sistema, és a dir, especifica les sortides que s’han de produir a partir d’unes determinades entrades i les operacions necessàries per aconseguir això.
- També han d’especificar com s’ha de comportar el sistema davant de situacions anormals (entrades invàlides, errors, etc.)
2.
7
RNF. Restriccions de disseny
- Acompliment dels estàndards. Format dels informes, procediments d’assignació de comptes, auditories, etc.
- Limitacions hardware. Disponibilitat de recursos: tipus de màquina, S.O., llenguatge, capacitat d’emmagatzematge.
- Recuperació i fiabilitat davant errors. Pot fer el sistema més complex i car.
- Seguretat. Utilització de certes comandes, control d’accés a les dades, condicions d’accés per a diferents perfils d’usuari, etc.
2.
Factors presents en l’entorn del client que restringeixen les opcions del dissenyador.
8
2.
RNF. Interfícies externes / Objectius de disseny
- Requeriments sobre les interfícies externes. Característiques de la interacció amb gent, hardware i altres mòduls de software.
- Objectius de disseny o requeriments de qualitat. Restriccions que incideixen en determinats aspectes de la qualitat final del software (fàcil d’utilitzar, de mantenir, ampliable).
- Els RIE són més precisos que els OD:
- OD: el sistema hauria de ser user friendly.
- RIE: La interacció es farà mitjançant menús desplegables i comandes no més llargues de 6 caràcters.
9
2.
Procés de separació de requeriments
Separar decisions de disseny Separar objectius de disseny Separar requeriments amb el clientDiscutir no funcionals
DISSENY (^) REQUERIMENTSANÀLISI DE
Document de requeriments d’usuari
Requeriments d’usuari
Requeriments d’usuari
Requeriments funcionals
Requeriments no funcionals
Requeriments no funcionals (resultants de les decisions de disseny)
Decisions de disseny
Objectius de disseny
Especificacions de requeriments
10
Tasques de l’anàlisi de requeriments
- Reconeixement del problema. Comprendre el SW dins del context.
- Avaluació i síntesi del problema. Flux, estructura i contingut de la informació. Definir funcions. Entendre el comportament.
- Modelització. Fer models del sistema.
- Especificació. Representació formal.
- Revisió. Comprovar que tant client com analista han “entès” el problema.
2.
Comprensió del problema
Especificació
13
Característiques dels mètodes de modelat (Principis de l’anàlisi)
- Partició Un sistema complex només es pot entendre si s’estructura en parts interrelacionades. Les eines que utilitzem han de ser capaces de descriure un problema a partir de les seves parts.
- Abstracció S’ha de ser capaç de definir una entitat o problema en termes generals. Treure- li tots els detalls (referentciant-los a part) simplificant-ne la comprensió. Les eines utilitzades han de permetre trobar els detalls de manera progressiva.
- Projecció Permet definir el sistema des de diferents punts de vista (projeccions). Per exemple, operari, administratiu, directiu, etc. La combinació de punts de vista n’assegura la comprensió completa.
2.
Cada mètode d’anàlisi té una notació i un punt de vista propi. Tanmateix, hi ha uns principis que totes les eines de modelat associades a aquests mètodes haurien de complir:
14
Especificació de requeriments
- El resultat de l’anàlisi és el document d’especificació de requeriments.
- Objectius del document d’especificació de requeriments. Fa una doble funció: - Contracte. - Base de treball (referència) del dissenyador.
2.
15
Propietats desitjables d’una especificació
- Especifica el comportament extern, no la implementació.
- Comprensible.
- No ambigües.
- Completes.
- Verificables.
- Consistents.
- Modificables.
- Seguible.
- Usable durant l’operació i el manteniment.
2.
16
Estàndard d’especificació de requeriments ANSI/IEEE (I)
1. Introducció 1.1 Propòsit de l’especificació 1.2 Abast (àmbit) del producte 1.3 Definicions i abreviatures 1.4 Referències 1.5 Visió general de l’especificació 2. Descripció general 2.1 Perspectiva del producte 2.2 Funcions del producte 2.3 Característiques dels usuaris 2.4 Restriccions generals 2.5 Supòsits i dependències **3. Requeriments específics
- Apèndixs
- Índex**
2.
19
Revisió i validació de l’especificació
Una reunió d’experts que intenten valorar la qualitat del producte (especificació). Dos nivells:
- Macroscòpic: comprovar si l’especificació és completa, consistent i precisa.
- Detallat: precisar termes concrets.
2.
1
U@H6"
9DTT@I`9@GTPAUX6S@
- Introducció.
- Procés de disseny.
- Disseny de dades, disseny arquitectònic, disseny de la interfície, disseny procedimental.
- Principis (objectius) del disseny.
- Disseny modular efectiu.
- Independència funcional.
- Cohesió
- Acoblament.
- Heurístiques per a un disseny modular efectiu.
- Conceptes del disseny.
- Abstracció.
- Modularitat.
- Refinament.
2
Introducció
- 9rsvvpv El procés d’aplicar diferents tècniques i principis amb el propòsit de definir un dispositiu, un procés o un sistema amb suficients nivells de detall com per permetre la seva realització física. Està situat en el nucli tècnic del procés d’E.S. I s’aplica independentment del paradigma de desenvolupament utilitzat.
- Piwrpv Produir un model o representació del sistema que pugui ser utilitzat, en una fase posterior, a fi d’implementar-lo.
"
9vvqryQ iyrh => 9vvqryhTypv
5
D. Dades, D. Arquit., D. Procedim., D. Interf.
"
Diccionari de dades
Diagrama de transició d’estats (DTE)
Diagrama de flux de dades (DFD)
Diagrama d’entitat- Modelrelació (DER)
de dades
Model funcional
Model de comportament
D. de dades
D. arquitectònic
D. d’interfície
D. procedimental
Esp. Procés (EP)
9vr@ p h
6
D. Dades, D. Arquit., D. Procedim., D. Interf.
"
D. de dades
D. arquitectònic
D. d’interfície
D. procedimental
Capa de temes (mòduls)
Capa de classes i objectes
Capa d’estructures
Capa d’atributs
Capa de serveis
Component interfície
9vrP vrhhPiwrpr
7
Principis (objectius) del disseny
- Wr vsvphivyvh Poder avaluar la correctesa del disseny.
- 8yrrh Totes les components (estructures de dades, mòduls, interfícies externes, etc.) han de ser especificades.
- 8v-pvh Que no hi hagi inconsistències inherents.
- @svpv-pvh Utilització adequada dels recursos del sistema. Els recursos no són infinits.
- Trtviyr Tots els elements del disseny han de poder-se “mapejar” cap a l’anàlisi de requeriments.
- Tvyvpvh8 rviyr Cal tenir en compte que el document de disseny, igual com era el d’especificació de requeriments, serà utilitzat com a base per a les etapes posteriors.
"
8
Principis (objectius) del disseny
- El procés de disseny no ha de ser únic, s’han d’avaluar alternatives.
- Cada element del model de disseny s’ha de poder seguir enrere fins a l’anàlisi per saber els requeriments que satisfà.
- El disseny no ha d’inventar res de nou. Reutilitzar al màxim.
- Minimitzar la distància entre DP i DS.
- Ha de ser uniforme (un estil constant).
- Ha d’estructurar-se per admetre canvis.
- Ha de ser robust. Acceptar circumstàncies inusuals.
- El disseny no és escriure codi i escriure codi no és dissenyar.
- La qualitat del disseny s’avalua mentre es fa, no després.
- Cal revisar-lo per evitar errors conceptuals (semàntics): omissions, ambigüitats, inconsistències.
"
11
Modularitat
- Aplicar el principi de qvvqrpr al disseny de software.
- H(qy És la unitat bàsica d’un programa, és finita i identificable respecte a la compilació i la lectura. És lògicament separable. Pot ser una macro, una funció, un conjunt de dades i funcions associades, un tipus abstracte de dades, etc.
- Mida recomanable d’un mòdul:
- 8 grau de complexitat d’un problema .
- @ esforç per programar una solució.
- 8 > 8! => @ > @!
- 8 ! > 8 + 8! => @ ! > @ + @!
"!
12
Modularitat. Mida dels mòduls
Però no es pot dividir infinitament. Dividir implica augmentar la interdependència entre mòduls:
- Augmenta el cost associat a crear les interfícies.
- Costa més detectar l’origen dels errors i corregir-los.
"!
Solució (criteri) per arribar a M ⇒ ↑Cohesió, ↓Acoblament
13
Refinament
- Dues estratègies per dissenyar una jerarquia de mòduls (arquitectura del software):
- Uq Refinaments successius. Es comença per un nivell més abstracte i a cada pas obtenim noves components que ofereixen una visió més concreta.
- 7 Es comença des de les components de més baix nivell de la jerarquia i de manera progressiva establim les components de nivell més alt.
- @ h-tvhvh Es comença des dels dos extrems de la jerarquia fins que es troben.
"!
14
Disseny modular efectiu
- Dqrrq-pvhspvhy Un sistema es considera modular si està format per una sèrie de components de manera que cadascuna proporcioni una bona definició d’abstracció, i que un canvi introduït sobre una component tingui un impacte mínim sobre la resta. La modularitat efectiva s’aconsegueix amb independència funcional, que vol dir mòduls amb una funció única i poca interacció entre ells.
- 8urv Cada mòdul té una funció única. És l’extensió del principi de la ocultació.
- 6piyhr És una mesura de la interdependència entre mòduls.
""
Piwrpv) màxima cohesió i mínim acoblament. ↑Cohesió ⇒ ↓Acoblament
17
Acoblament
- 6piyhrqrqhqr Dos mòduls es comuniquen amb paràmetres on cadascun és una dada simple o bé un conjunt de dades homogènies.
- 6piyhrqrh phr rtv r Un mòdul passa a un altre un registre o estructura de dades amb no homogènia (amb diferents camps). Cal una comprovació de les estructures de dades. Per alta banda, cal evitar passar registres amb molts camps dels quals només se n’utilitza algun.
- 6piyhrqrp y Un mòdul passa un paràmetre a un altre amb intenció de controlar el seu comportament. És més acceptable que el mòdul inferior doni un control al superior (per exemple, notificació d’error).
- 6piyhrp< Diversos mòduls accedeixen a la mateixa àrea global de dades.
- Qualsevol error en un mòdul pot afectar a un altre via dades globals.
- Difícil seguir el programa pel que fa a qui modifica les dades globals.
- Manteniment difícil si es canvia l’estructura de dades global (molts mòduls hi accedeixen).
- Si hi ha moltes dades globals, és difícil establir quines dades utilitza cada mòdul.
- 6piyhrqrpvt Un mòdul accedeix directament a una part de l’altre mòdul (sentències tipus t).
""
7hv @rp rqry=hpiyhr 6y
Sense acoblament directe Acoblament de dades Acoblament de marca Acoblament de control Acoblament comú Acoblament de contingut
18
Acoblament
""
Control registres
Buscar registre
Núm c/c
“Error: registre inexistent” Registre
Control registres
Buscar registre
Núm c/c
No trobat Registre
Control registres
Control E/S
Registre
Operació Registre
Control registres
Control entrada
Control sortida
Registre Registre
Control registres
Càlcul base
Càlcul quilometratge
Registre client Registre client Base Quilom.
Jugar a escacs
Moure peça
Tauler esc.
Moviment Tauler actualitzat (^) Validar Telèfon
Registre client Validació
9hqr Srtv r
8 y
1
TEMA 4
INTRODUCCIÓ A LA ORIENTACIÓ A OBJECTE
- Evolució dels llenguatges de programació.
- Paradigmes de programació.
- Principis bàsics de l’O.O.
- Conceptes bàsics de l’O.O.
2
4.
Evolució dels llenguatges de programació (I)
- Llenguatges de primera generació (1954-1958).
- Assemblador, en els inicis.
- FORTRAN I, ALGOL 58, Flowmatic, IPL V, etc.
- Són llenguatges basats en el procés d’expressions matemàtiques.
- Llenguatges de segona generació (1959-1961).
- FORTRAN II (subrutines, compilació separada).
- ALGOL 60 (estructura de blocs, tipus de dades).
- COBOL (descripció de dades, gestió de fitxers).