Docsity
Docsity

Prepara tus exámenes
Prepara tus exámenes

Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity


Consigue puntos base para descargar
Consigue puntos base para descargar

Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium


Orientación Universidad
Orientación Universidad


Anàlisi de requeriments del software, Diapositivas de Ingeniería del Software

Asignatura: Enginyeria del software, Profesor: xavier Roca, Carrera: Enginyeria Informàtica, Universidad: UAB

Tipo: Diapositivas

Antes del 2010

Subido el 17/11/2008

j-firex
j-firex 🇪🇸

4.5

(13)

1 documento

1 / 145

Toggle sidebar

Esta página no es visible en la vista previa

¡No te pierdas las partes importantes!

bg1
1
1
TEMA 2
ANÀLISI DE REQUERIMENTS DEL SOFTWARE
1. Introducció.
Tipus de requeriments.
Tasques a realitzar.
2. Comprensió del problema.
Tècniques de comunicació.
Problemes associats.
Característiques dels mètodes de modelat
(Principis de l’anàlisi).
3. 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.1
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26
pf27
pf28
pf29
pf2a
pf2b
pf2c
pf2d
pf2e
pf2f
pf30
pf31
pf32
pf33
pf34
pf35
pf36
pf37
pf38
pf39
pf3a
pf3b
pf3c
pf3d
pf3e
pf3f
pf40
pf41
pf42
pf43
pf44
pf45
pf46
pf47
pf48
pf49
pf4a
pf4b
pf4c
pf4d
pf4e
pf4f
pf50
pf51
pf52
pf53
pf54
pf55
pf56
pf57
pf58
pf59
pf5a
pf5b
pf5c
pf5d
pf5e
pf5f
pf60
pf61
pf62
pf63
pf64

Vista previa parcial del texto

¡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

  1. Introducció.
    • Tipus de requeriments.
    • Tasques a realitzar.
  2. Comprensió del problema.
    • Tècniques de comunicació.
    • Problemes associats.
    • Característiques dels mètodes de modelat (Principis de l’anàlisi).
      1. 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

  1. Apèndixs
  2. Í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@

  1. Introducció.
    • Procés de disseny.
    • Disseny de dades, disseny arquitectònic, disseny de la interfície, disseny procedimental.
    • Principis (objectius) del disseny.
      1. Disseny modular efectiu.
        • Independència funcional.
        • Cohesió
        • Acoblament.
        • Heurístiques per a un disseny modular efectiu.
  2. Conceptes del disseny.
  • Abstracció.
  • Modularitat.
  • Refinament.

2

Introducció

  • 9rsvvpv 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.
  • Piwrp‡vˆ Produir un model o representació del sistema que pugui ser utilitzat, en una fase posterior, a fi d’implementar-lo.

"

9‚€vvqryQ ‚iyr€h => 9‚€vvqryhT‚yˆpv

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)

9v††r’@†‡ ˆ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

9v††r’P vr‡h‡hPiwrp‡r

7

Principis (objectius) del disseny

  • Wr vsvphivyv‡h‡ Poder avaluar la correctesa del disseny.
  • 8‚€ƒyr‡r†h Totes les components (estructures de dades, mòduls, interfícies externes, etc.) han de ser especificades.
  • 8‚†v†‡-pvh Que no hi hagi inconsistències inherents.
  • @svpv-pvh Utilització adequada dels recursos del sistema. Els recursos no són infinits.
  • Trtˆviyr Tots els elements del disseny han de poder-se “mapejar” cap a l’anàlisi de requeriments.
  • Tv€ƒyvpv‡h‡8‚€ƒ r†viyr 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 qv‰vqrp‚„ˆr al disseny de software.
  • H(qˆy É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):
  • U‚ƒq‚ 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‡-tvh€v‘‡h Es comença des dels dos extrems de la jerarquia fins que es troben.

"!

14

Disseny modular efectiu

  • Dqrƒrq-pvhsˆpv‚hy 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.
  • 8‚ur†v Cada mòdul té una funció única. És l’extensió del principi de la ocultació.
  • 6p‚iyh€r‡ És una mesura de la interdependència entre mòduls.

""

Piwrp‡vˆ) màxima cohesió i mínim acoblament. ↑Cohesió ⇒ ↓Acoblament

17

Acoblament

  • 6p‚iyh€r‡qrqhqr† Dos mòduls es comuniquen amb paràmetres on cadascun és una dada simple o bé un conjunt de dades homogènies.
  • 6p‚iyh€r‡qr€h phƒr  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.
  • 6p‚iyh€r‡qrp‚‡ ‚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).
  • 6p‚iyh€r‡p‚€< 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.
  • 6p‚iyh€r‡qrp‚‡vtˆ‡ Un mòdul accedeix directament a una part de l’altre mòdul (sentències tipus t‚‡‚).

""

7hv‘ ••••••••••••••• @†ƒrp‡ rqry=hp‚iyh€r‡••••••••••••••• 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

  1. Evolució dels llenguatges de programació.
  2. Paradigmes de programació.
  3. Principis bàsics de l’O.O.
  4. 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).