ES - RESUM PARCIAL 2 (2017)

Resumen Catalán
Universidad Universidad Autónoma de Barcelona (UAB)
Grado Ingeniería Informática - 2º curso
Asignatura Enginyeria del Software
Año del apunte 2017
Páginas 24
Fecha de subida 02/08/2017
Descargas 0
Subido por

Descripción

Resum de tota la teoria d'Enginyeria del Software fins al 2n Parcial.

Vista previa del texto

ES - RESUM PARCIAL 2 TEMA 5 – UML (UNIFIED MODELING LANGUAGE) 1. Introducció 1.1.
       UML: Definicions. Objectius. Modelat. Utilitat Definició: 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’ES i s’aplica independentment del paradigma de desenvolupament utilitzat.
𝑫𝒐𝒎𝒊𝒏𝒊 𝒅𝒆𝒍 𝑷𝒓𝒐𝒃𝒍𝒆𝒎𝒂 → 𝑫𝒐𝒎𝒊𝒏𝒊 𝒅𝒆 𝒍𝒂 𝑺𝒐𝒍𝒖𝒄𝒊ó Objectiu: Produir un model o representació del sistema que pugui ser utilitzat, en una fase posterior, a fi d’implementar-ho.
UML (Unified Modeling Language): Llenguatge visual de modelat orientat a objecte.
Objectius en el disseny UML: o Modelar sistemes, des del concepte fins als elements executables, utilitzant tècniques orientades a objecte.
o Cobrir tots els aspectes relacionats amb la mida inherent als sistemes complexos i crítics.
o Crear un llenguatge de modelat utilitzable tant per les persones com per les màquines.
o Trobar un equilibri entre expressivitat i simplicitat.
UML i el modelat: “UML és un llenguatge per visualitzar, especificar, construir i documentar els elements d’un sistema que involucra una gran quantitat de SW, des d’una perspectiva OO.” o UML és una notació, no un procés. S’estan definint molts processos per UML.
Rational ha ideat RUP, “Rational Unified Process” (Iteratiu i Incremental).
Utilitat UML: o Permet especificar totes les decisions de l’anàlisi, disseny i implementació, construint models precisos, no ambigus i complerts.
o UML pot connectar-se a llenguatges de programació (Enginyeria directa i inversa).
o Permet documentar tots els elements d’un procés de desenvolupament (requeriments, arquitectura, proves, versions, ...).
Model Conceptual de UML: o Blocs bàsics de construcció: Vocabulari. Elements (Estructurals, Comportament, Agrupació, Anotació), Relacions, Diagrames.
o Regles per combinar blocs: establir què és un model ben format (regles sintàctiques i semàntiques: noms, visibilitat, integritat, etc.).
o Mecanismes comuns: notació que permet fixar un estil dins del model. És una notació vàlida per als diferents elements dels diferents diagrames.
1.2.
   Blocs de construcció Elements o Estructurals: parts estàtiques que representen coses que són conceptuals o materials (Classe, actor, interfície, components, cas d’ús, node...).
o Comportament: parts dinàmiques que representen comportament en el temps i l’espai (Interaccions, Estat, ...).
o Agrupació: parts organitzatives dels models (Paquet).
o Anotació: parts explicatives del models (Nota).
Relacions o Dependència: Relació semàntica, si modifiquem l’element independent pot afectar al dependent.
o Associació: Relació estructural, connexions entre elements (Composició, Agregació) o Generalització: Relació generalització/especialització.
o Realització: Relació semàntica entre classificadors on especifica un contracte que un altre classificador garantirà.
Diagrames o Casos d’Ús: mostren un conjunt de casos d’ús, actors i les seves relacions.
o Classes: mostren un conjunt de classes, interfícies i col·laboracions, així com les seves relacions.
o Objectes: mostren un conjunt d’objectes i les seves relacions.
o Interacció:  Seqüència: mostra ordenació temporal dels missatges.
 Col·laboració: mostren la organització estructural dels objectes que envien i reben missatges.
o Estats: mostra una màquina d’estats.
o Activitats: tipus de diagrama d’estat que mostra els fluxos de control.
o Components: mostra l’organització i la dependència entre un conjunt de components.
o Desplegament: mostra la configuració dels nodes de processament.
1.3.
 Mecanismes comuns. Arquitectura i Vistes Mecanismes comuns o Especificacions:  La notació en UML té una doble component:  Una part gràfica que permet visualitzar un sistema o una projecció d’aquest.
 Una part semàntica que ens permet especificar els detalls de cada elements del sistema.
 Això permet construir un model de forma incremental dibuixant diagrames i després afegir detalls.
o Guarniments:  La notació gràfica bàsica de cada element pot incloure guarniments textuals o gràfics per posar de manifest algunes propietats de l’especificació.
o Divisions Comuns:  Al modelar els sistemes OO, aquests poden dividir-se en un parell de formes.
 Dicotomia classe/objecte (UML representa tant classes com objectes).
 Dicotomia interfície/implementació.
o Mecanismes d’extensivitat:  Estereotips: Estenen el vocabulari de UML, permeten afegir nous blocs de construcció.
 Valors etiquetats: Estenen les propietats d’un bloc de construcció, afegint informació.
 Restriccions: Estenen la semàntica d’un bloc, afegint regles o modificant les existents.
 Arquitectura o L’UML permet modelar diferents vistes o visions d’un problema i la seva solució, depenent del que ens interessi representar en cada ocasió. A cada vista li correspon un o més diagrames.
o Per què cal vistes?  És impossible comprendre completament un sistema complex des d’un únic punt de vista, i d’un sol cop.
 Fer els diagrames comporta fer-se les preguntes adequades i prendre decisions sobre quina i com serà la solució.
 Vistes segons els rols del projecte o Visió d’usuari: Què, no com. Usuaris, Analistes, Dissenyadors i provadors.
o Visió estructural: Disseny de classes per implementar els requisits funcionals i no funcionals. Dissenyadors, Programadors, Provadors.
o Visió de comportament: Aspectes dinàmics del SW en execució: flux de missatges entre objectes, flux de control en una funció, canvis d’estat.
Dissenyadors, Programadors, Provadors.
o Visió d’implementació: Organització del SW a l’entorn de desenvolupament.
Directors de projectes, Gestors de la qualitat del SW, Dissenyadors, Programadors, Provadors, etc.
o Visió d’implantació: Correspondència entre el SW i HW lliurats.
Dissenyadors, Enginyers de sistemes.
2. Model de Casos d’Ús (Visió Lògica) 2.1.
   Ofereixen un mitjà semàntic i intuïtiu per capturar els requeriments funcionals, centrant-se en el valor afegir per l’usuari.
Dirigeixen tot el procés de desenvolupament atès que la majoria d’activitats (planificació, anàlisi, disseny, validació, test) es realitzen a partir dels casos d’ús.
Mecanisme important per a suportar “traçabilitat” entre models.
2.2.
    Modelat Casos d’Ús Un cas d’ús especifica el comportament desitjat del sistema.
Representen els requeriments funcionals del sistema.
Descriuen què fa el sistema, no com ho fa.
Escenari: Seqüència específica d’accions que ilustra el comportament d’un cas d’ús.
2.3.
    Són iniciats per un actor amb un objectiu previst i es completen amb èxit quan el sistema el satisfà.
Poden incloure seqüències alternatives que condueixen a l’èxit i fracàs en la consecució de l’objectiu.
El sistema es considera com una “caixa negra” i les interaccions es perceben des de fora.
El conjunt complet de casos d’ús especifica totes les possibles formes d’usar el sistema, és a dir, el comportament requerit.
2.4.
 Obtenció i descripció de casos d’ús Obtenció 1.
2.
3.
4.
5.
6.
 Propietats dels casos d’ús Identificar els usuaris del sistema.
Trobar tots els rols que juguen els usuaris i que són rellevants al sistema.
Per cada rol identificar totes les formes (objectius) d’interactuar amb el sistema.
Crear un cas d’ús per cada objectiu.
Estructurar els casos d’ús.
Revisar i validar amb l’usuari.
Descripció o Descriure el flux d’esdeveniments: Associació a una especificació, pot fer-se en text estructurat informal, text estructurat formal (pre i postcondicions), pseudocodi, notacions gràfiques (diagrames d’activitats).
o Ha de ser llegible i comprensible per a un usuari inexpert .
o Ha d’indicar-se: inici i final, actors, objectes que intervenen, flux principal i excepcionals.
2.5.
 Actors i Associacions Actors Un actor representa un conjunt coherent de rols que juguen els usuaris dels casos d’ús a l’interactuar amb el sistema.
o o o o o o o  Rols jugats per persones, dispositius, o altres sistemes.
NO formen part del sistema.
Un usuari pot jugar diferents rols.
En la realització d’un cas d’ús poden intervenir diferents actors.
Un actor pot intervenir en diversos casos d’ús.
Identificar casos d’ús mitjançant actors i esdeveniments externs.
Un actor necessita el cas d’ús i/o participa en ell.
Associacions o Generalització: Un CU hereta el comportament i significat de l’altre.
o Inclusió: Un CU base incorpora explícitament el comportament d’un altre en algun punt de la seva seqüència. 𝑪𝑼 𝒃𝒂𝒔𝒆 → 𝑰𝒏𝒄𝒍𝒖𝒔𝒊ó  Permet factoritzar un comportament en CU apart i evitar repetir un mateix flux en diferents casos d’ús.
 Exemple “Seguir Comanda”  <Include>  “Validar usuari”.
(Obtenir i verificar el número de comanda  Examinar l’estat de cada part de la comanda i preparar un informe per a l’usuari) o Extensió: Un CU base incorpora implícitament el comportament d’un altre CU en el lloc especificat indirectament per aquest altre CU. Un CU completa la funcionalitat d’un altre CU. 𝑬𝒙𝒕𝒆𝒏𝒔𝒊ó → 𝑪𝑼 𝑩𝒂𝒔𝒆  Serveix per a modelar: la part opcional del sistema, un subflux que només s’executa sota certes condicions, diversos fluxos que es poden inserir en un punt.
 Exemple “Fer Comanda Urgent”  <Extend>  “Fer Comanda”.
(Recollir els ítems de la comanda (establir prioritat)  Enviar comanda per a ser processada) 2.6.
Escenari i Col·laboracions. CU (UML) i Històries d’usuari (SCRUM)   Escenari: Cas d’Ús “en execució”. Instància d’un Cas d’Ús.
Efecte d’expansió dels CU als escenaris: Fluxos principals vs fluxos alternatius.
 Col·laboracions: Implementació d’un CU.
Conjunt de classes i altres elements que col·laboraran per realitzar el comportament expressat en un CU.
UML vs SCRUM: Un CU és una unitat funcional del SW, i els diferents escenaris (fluxos principals i alternatius) poden generar diferents històries d’usuari que es resolen en els diferents Sprint.
Els actors, com a perfils d’usuari, ajuden a definir els Stakeholders.
  3. Model de Comportament (Visió Lògica) 3.1.
  Diagrames d’Interacció (Visió Dinàmica) Modelen aspectes dinàmics del sistema: Seqüències i Col·laboració.
Seqüències: Destaquen ordenació temporal dels missatges. Representen escenaris.
o Objectes: papers que els objectes poden jugar en la interacció.
o Línia de vida: Existència d’un objecte en un període de temps.
o Focus de control o Activacions: Temps durant el qual un objecte opera.
o Missatges: Comunicació entre objectes.
o Informació de control: Condicions i marques d’iteració.
 Col·laboració: Destaquen organització estructural dels objectes participants. Útils a la fase exploratori per identificar objectes. Mostren interaccions organitzades entre objectes a partir de la topologia que mostra l’enviament dels seus missatges.
o Objectes: Papers que els objectes poden jugar en la interacció.
o Enllaços entre objectes: Connexions estructurals entre objectes. (Estàtica) o Missatges: Comunicació entre objectes. (Dinàmica) o Informació de Control: Condicions i marques d’iteració.
3.2.
 Diagrama d’Estats (Visió Dinàmica) Modela el comportament dinàmic d’un objecte, per objectes amb comportament significatiu. S’utilitzen per mostrar els estats en què ens podem trobar un objecte durant el seu temps de vida, els esdeveniments que causen la transició d’un estat a un altre i les accions que resulten d’un canvi d’estats.
o Estats: Període de temps en la vida de l’objecte durant el qual està esperant alguna operació, té un cert comportament característic o pot rebre estímuls.
o Transició: Canvi d’estats, pot anar acompanyat d’alguna acció. Les accions són comportaments que succeeixen de forma ràpida i sense interrupció.
També poden disparar esdeveniments que serien missatges que s’envien a altres objectes del sistema. Una guarda és una expressió booleana que fa que la transició només es produeixi si la condició s’avalua a true. Hi ha transicions automàtiques quan s’acaba l’activitat de l’estat origen (no hi ha un esdeveniment associat amb la transició), i no automàtiques quan existeix un esdeveniment que pot pertànyer a un altre objecte, o estar fora del sistema.
3.3.
    Diagrames d’Activitats (Visió Dinàmica) Un diagrama d’activitats és essencialment un diagrama de flux d’accions que mostra l’activitat que esdevé al llarg del temps.
Un diagrama d’activitats és un cas especial de diagrama d’estats en què els estats són estats d’activitat i les transicions es disparen per l’acabament de les activitats en l’estat d’origen.
Una activitat produeix alguna acció que produeix algun canvi en el sistema o retorna un valor.
Estats d’activitat: Es compon d’altres estats acció i activitat. Tenen durada i s’executen dins d’un estat de l’objecte. Es poden interrompre quan es desencadena l’operació de sortida de l’estat.
 Barres de sincronització: Permeten representar activitats que s’executen en paral·lel, així com punts d’unió en el flux de control, és a dir, activitats que s’han de completar abans que el procés continuï.
 Carrers (Swimlanes): Divideixen un diagrama d’activitats. Mostren quina persona o organització és la responsable de les activitats contingudes al carrer.
 Activitats vs Estats: Fluxos de processament vs estats en què es troba un objecte.
4. Model Estructural (Visió Lògica) 4.1.
Diagrames de Classes (Visió Estàtica)   Descriuen els tipus d’objectes d’un sistema i les relacions estàtiques entre ells.
Classe: Descripció d’un grup d’objectes amb propietats comunes (atributs), comportament comú (operacions), relacions comunes amb altres objectes i semàntica comuna. Els membres d’una classe poden tenir la visibilitat: o Públic: Accessibles per tots els clients.
o Protegit: Accessibles només per les subclasses, amigues i la mateixa classe.
o Privat: Accessibles només per les classes amigues i la mateixa classe.
o Implementació: Accessible per la implementació del paquet que la conté  S’utilitzen per modelar: o Vocabulari del sistema: identificar classes per abstraccions rellevants del domini del problema.
o Col·laboracions (Part Estàtica): Identificar classes i interfícies la interacció dels quals produeix el comportament desitjat. Un diagrama de col·laboració representa una instància del diagrama de classes per a un escenari concret.
o Esquema lògic de Bases de Dades.
Classes d’anàlisi: Aquelles que tenen responsabilitats i comportament.
o Comunicació/Interfície: Gestionen interacció entre el sistema i el seu entorn.
o Control: Coordinen esdeveniments necessaris pel comportament d’un CU.
o Entitat: Modelen informació i el seu comportament. Representen entitats del món real o entitats internes necessàries per executar les tasques del sistema. Independents de com l’entorn es comunica amb el sistema i sovint independents també de l’aplicació (transportables a altres aplicacions).
  Atributs:  Operacions:  Classes Parametritzades:  Relacions o Dependència: Un canvi en l’especificació d’un element afecta l’altre.
 Bind: Entre una classe genèrica i una instanciació.
 Friend: Dependència de classe amiga.
 Refine: Relació de refinament.
 Use: Relació d’ús.
 Import: Un paquet importa els elements d’un altre.
 Extend/Include: Per a CU.
o Generalització: Relació “ser un tipus de”. La especialització d’una general. Jerarquia d’abstraccions on la subclasse hereta les propietats d’una o més superclasses.
 Herència Simple/Múltiple: Deriva d’una o més d’una classe.
 Herència Solapada/Disjunta: Deriva o no de més d’una subclasse.
 Herència Completa/Parcial: Tots (o no tots) els objectes estan representats per alguna subclasse.
 Classificació dinàmica: Un objecte pot canviar de classe.
o Associació: Els objectes d’un element estan connectats als d’un altre.
o Agregació: Associació tot-part o de continent-contingut. (Amo-Mascota) o Composició: Agregació amb un propietari fort i temps de vida coincidents.
(Casa-Habitació)     Multiplicitat: Quants objectes participen en una relació. S’especifica amb un rang.
Navegació: Tot i que les associacions i agregacions són bidireccionals, a vegades és desitjable restringir la navegació a una direcció. S’indica amb la punta d’una fletxa.
Realització: Una classe que és realització d’una altra indica que la primera garanteix la implementació de l’especificació de la segona.
Interfície: Visió externa de les funcionalitat de l’objecte que s’exporten. La realització representa la implementació d’allò que especifica la interfície.
4.2.
   Diagrames d’Objectes (Visió Estàtica) Representa un conjunt d’objectes i relacions en un moment concret.
“Fotografia” del sistema en un moment d’execució. Instància del diagrama de classes.
Representa una visió estàtica del sistema. Complementat amb diagrames de col·laboració.
5. Model Arquitectònic (Visió Física) 5.1.
   Una component és una part física i reemplaçable d’un sistema que realitza un conjunt d’interfícies i proporciona la realització d’aquestes.
Modela artefactes com ara: executables, biblioteques, taules, fitxers, documents...
Representa l’empaquetament físic d’elements lògics com ara classes, interfícies...
5.2.
   Diagrames de Components (Visió Estàtica) Diagrames de Desplegament (Visió Estàtica) Dimensió lògica d’un sistema: classes, interfícies, col·laboracions, interaccions, i màquines d’estats.
Dimensió física d’un sistema: components (empaquetaments físics dels elements lògics), nodes (elements físics existents en temps d’execució que representen un recurs computacional, i HW sobre el qual es despleguen i executen les components), arcs (connexions físiques entre nodes).
Mostren la configuració dels nodes que participen en l’execució i de les components que resideixen als nodes.
TEMA 6 – QUALITAT DEL SOFTWARE 1. Introducció      Prova: Avaluació d’un sistema de forma manual o automàtica per tal de verificar que satisfà els requisits especificats o per identificar diferències entre els resultats esperats i els obtinguts.
Importància: És impossible desenvolupar SW sense errors, i el cost dels errors és molt gran. La prova representa des d’un 40% d’esforç i fins a un 80%.
Objectius: Descobrir errors (de major gravetat, diferents tipus, amb el menor esforç i temps possibles).
Motivació o Les proves pretenen executar un sistema (o parts) en un entorn controlat.
o Desviacions dels resultats observats respecte els previstos indica un bug de disseny o d’implementació (assumint els requeriments com a correctes).
o Dues activitats: definició dels casos de prova i execució de les proves.
o La definició es pot fer paral·lela als requeriments i utilitzar-la per avaluar-los.
Correcció d’errors: Com més aviat es trobi un error, menor serà el cost de correcció.
La majoria dels defectes venen causat per una mala definició de requeriments.
2. Disseny de Casos de Prova      Definició Casos de Prova: quines propietats del sistema es provaran i com.
Execució de les proves: s’executa el sistema per cada cas de prova i s’avalua la desviació de la sortida esperada respecte la obtinguda.
“Prova de SW”: Execució sistemàtica d’una unitat SW, objecte de prova, amb l’ànim de detectar errors. No hauria de ser una tasca dins de Proves, sinó Debugging.
Limitació de les proves: Gairebé impossible provar totes les condicions d’entrada i sortida  Cal fer una bona selecció de tests per cobrir el màxim de situacions.
Model en V: 2.1.
  Classes de Proves Prova de Caixa Negra: Tenint en compte les especificacions, fer proves per veure si totes les funcions són operatives. Només Input-Output.
o Examen d’aspectes del comportament d’un sistema.
o No es té en compte la lògica interna del sistema.
o Es centra en els requeriments:  Funcions incorrectes o absents.
 Errors d’interfície.
 Errors en estructures de dades o accés a Bases de Dades externes.
 Errors de rendiment, d’inicialització/finalització.
 ...
Prova de Caixa Blanca: Coneixent l’estructura interna, fer proves per veure que “totes les peces encaixen”.
o Examen minuciós de la lògica interna d’un sistema.
o Es centra en examinar els diferents camins d’execució:  Garantia d’execució (almenys una vegada) de totes les línies de codi.
 Portar fins al límit l’execució de bucles.
 Garantir que totes les estructures de dades són utilitzades.
 Garantir que el sistema és portat a “tots” els estats.
 Garantir que s’executa el mecanisme d’excepcions.
 ...
o Comprovar amb caixa blanca al 100% un sistema és inviable, cal només provar els camins bàsics d’execució: 1. Representar el flux de control en un graf (Cada node pot representar més d’una línia).
2. Comptar el nombre de camins bàsics independents.
3. Trobar un possible conjunt d’aquests camins.
4. Determinar un cas de prova que ens porti per cada camí.
5. Executar el codi comprovant si el resultat és o no l’esperat.
2.2.
Caixa Blanca: Prova del Camins Bàsics 1. Construir graf a partir d’un pseudocodi  Es pot representar a més com una matriu d’adjacència amb els pesos 𝛼, 𝛽, 𝛾, 𝛿, 𝜀, 𝜃 … a cada adjacència (arc) entre dos nodes  Algorisme Dijkstra.
2. Comptar nombre de camins bàsics independents      Mètrica del SW que proporciona una mesura quantitativa de la complexitat de la lògica d’un programa.
En el context del mètode de prova del camí bàsic, serveix per definir el nombre de camins d’execució independents: ens dóna un límit superior del nombre de proves a fer per assegurar que cada sentència de codi s’executi almenys una vegada.
Camí d’execució independent: qualsevol camí del programa que introdueixi almenys un nou conjunt de sentències en l’execució o una nova condició.
En termes del graf de flux, un camí independent està construït per almenys un arc que no hagi estat recorregut abans de la definició del camí.
La complexitat ciclomàtica es pot calcular de diferents formes: o 𝑽(𝑮) = #𝑹𝒆𝒈𝒊𝒐𝒏𝒔 𝒅𝒆𝒍 𝒈𝒓𝒂𝒇 𝒅𝒆 𝒇𝒍𝒖𝒙 (𝒆𝒙𝒕𝒆𝒓𝒊𝒐𝒓 𝒊𝒏𝒄𝒍𝒐𝒔𝒂) o 𝑽(𝑮) = #𝑨𝒓𝒄𝒔 – #𝑵𝒐𝒅𝒆𝒔 + 𝟐 o 𝑽(𝑮) = #𝑵𝒐𝒅𝒆𝒔𝑪𝒐𝒏𝒅𝒊𝒄𝒊ó + 𝟏 o A l’exemple de dalt → 𝑉(𝐺) = 4 3. Trobar un possible conjunt de camins independents amb cardinalitat 𝑽(𝑮)  Conjunt bàsic: si es proven tots aquests camins haurem executat totes les instruccions del programa i avaluat totes les condicions simples a cert i fals.
4. Determinar (disseny) un cas de prova per a cada camí independent    Vol dir forçar valors de variables de forma que l’execució dle programa recorri el camí donat.
Consell: Identificar en primer lloc els nodes condició.
Cal destacar que a vegades hi ha camins independents que no es poden provar de forma aïllada, en aquest cas el camí es pot recórrer com a part d’altra prova. Això pot implicar tornar a considerar el conjunt bàsic donat per tal d’eliminar altres camins redundants.
5. Executar el codi comprovant si el resultat és o no l’esperat   Durant el disseny dels casos de prova cal anotar els resultats esperats de l’execució de la prova per tal de fer una comparació amb els resultats obtinguts.
En alguns casos es pot automatitzar la comparació de resultats esperats amb els resultats obtinguts. En aquests casos (especialment en SW d’àmbit científic) cal un Groundtruth: o Conjunt d’entrades de les proves.
o Conjunts de sortides esperades.
o Mesura d’avaluació del rendiment.
2.3.
 Es centra exclusivament en la validesa de les construccions dels bucles.
2.4.
 Caixa Blanca: Prova dels Bucles Caixa Blanca: Prova Basada en el Flux Cadena definició-ús (DU) d’una variable X té la forma [X,S,S’] on S i S’ són identificadors de sentència, X ∈ DEF(S) i X ∈ US(S′ ), i la definició de X en la sentència S està vívida a la sentència S’.
 Provada Basada en el Flux: Requereix que es cobreixi almenys un cop cada cadena DU.
1. Seleccionar les variables d’interès.
2. Trobar les seves cadenes de DU.
3. Trobar un conjunt de tests que cobreixi totes les cadenes DU de totes les variables.
4. Executar, comprovant si el resultat és l’esperat.
2.5.
      No es poden derivar tots els casos, s’ha de seleccionar un número representatiu de casos de prova.
Partició en classes d’equivalència.
Fer una partició de l’espai de possibles entrades del programa en classes equivalents respecte d’algun criteri: o Entrada vàlida/No vàlida.
o Tipus de processament a realitzar.
Classes d’equivalència: La prova d’un element de la classe troba els mateixos errors que qualsevol altre element d’ella  Redueix nombre de casos de prova.
Tècnica: Escollir un representant de cada classe i fer la prova amb ell.
Els errors tendeixen a donar-se amb més freqüència a les “fornteres” de les classes d’equivalència que al seu “centre” (Ex.: Rang [a,b]  a, b, 𝑎 ± 𝜀, 𝑏 ± 𝜀). També aplicable als valors de sortida  donar entrada que generi sortida amb valors límit.
2.6.
     Caixa Negra: Prova de Partició Equivalent Caixa Negra: Prova de Comparació Per situacions on la fiabilitat del SW és molt crítica (avions, plantes nuclears, etc.) HW i SW redundant.
Diferents equips d’enginyeria del SW desenvolupen per separat el SW a partir de les mateixes especificacions.
Totes les versions es proven amb les mateixes dades de prova i s’executen en paral·lel comprovant en temps real els resultats.
Problema: si l’error està a l’especificació, totes les sortides poden ser incorrectes.
3. Estratègia de Prova 3.1.
  Verificació de mòduls, amb un comportament principal de caixa blanca a diferents nivells de detall. Es prova: o Interfície del mòdul.
o Estructures de dades locals.
o Camins independents.
o Condicions límit.
Pot requerir la inclusió de mòduls simulats: “Controladors” (drivers) i “Resguards” (stubs). Tot i això, algunes funcions s’hauran de provar mitjançant la prova d’integració.
3.2.
       Proves de Components (Unitat) Proves d’Integració Si un conjunt de mòduls funciona bé per separat, perquè no ho fan quan s’ajunten per formar el programa? o Interfícies inconsistents.
o Acoblament: Un mòdul afecta a un altre perquè comparteixen variables.
o Combinació de funcions no produeix la funció principal desitjada.
o Acumulació d’errors de precisió tolerables individualment.
La prova d’integració és una tècnica per construir el programa a partir dels mòduls a l’hora que es van duent a terme proves per detectar errors deguts a la seva interacció  Integració incremental.
La integració incremental requereix la creació de controladors i resguards, i pot ser de dos tipus: Descendent i Ascendent.
Es fan servir tècniques de caixa blanca i de caixa negra.
Integració = Col·laboració = Interacció = Missatges entre Objectes = Crida a funcions.
Objectiu de la prova d’interacció: Trobar errors en la col·laboració entre objectes de classes que suposem ja proves en unitat.
Identifiquem interaccions entre classes com: o Operació que esmenta una o més classes com el tipus d’un dels seus paràmetres.
o Operació que esmenta una classe com el tipus del seu retorn.
o Funció membre que crea una instància a una altra classe.
3.3.
  Es prova el sistema com un tot, comprovant si hi ha desviacions del seu comportament respecte dels requeriments.
Quan el SW és només una component d’un sistema més complex. Proves de: o Recuperació o Seguretat o Resistència o Rendiment 3.4.
 Proves d’acceptació Es comprova si es proporcionen els serveis que el client i el desenvolupador van acordar (contracte). Inclou diferents proves individuals: o Proves de camp: Es prova una versió beta (pre-release) en condicions reals.
o Proves d’acceptació de l’usuari: Els usuaris reals proven el sistema:  Alfa: Dutes a terme al lloc de desenvolupament, un client prova i els desenvolupadors observen. Entorn controlat.
 Beta: Dutes a terme al lloc de treball dels usuaris finals, per ells mateixos. Els usuaris registren tots els problemes observats. Entorn no controlat.
o Acceptació respecte el contracte: Es proven les condicions incloses al contracte per donar el servei com acceptat per part del client.
3.5.
 Proves de Sistema Prova Orientada a Objecte Unitat de la prova: o Els mètodes no tenen sentit fora del context de la seva classe  La unitat de prova és la classe o bé agrupacions de poques classes.
o Les proves d’integració es compliquen perquè no hi ha una jerarquia única de classes, tot és distribuït  Integració ascendent o descendent es fa més difícil.
   Herència implica més proves: o Els mètodes es fan servir en un context diferent (la classe especialitzada).
o Poden ser redefinits.
o Possibilitat d’herència múltiple.
Encapsulament dificultat saber l’estat dels objectes (valors atributs) o No és una font d’errors però dificulta la traça. Solució: afegir getters/setters.
Polimorfisme (Templates C++) o Cada possible binding d’un element polimòrfic (atribut, mètode) requereix una prova addicional.
o Pot ser difícil de trobar tots els possibles bindings, sent major la probabilitat d’error.
3.6.
 S’ha de verificar que la implementació d’una classe correspon a la seva especificació (que se suposa correcta).
1. Identificar casos de prova.
2. Implementar un test driver que executi cadascun dels casos de prova, compari el resultat amb l’esperat i desi la comparació  Crear com a mínim un objecte de la classe, portar-lo a l’estat desitjat, enviar el missatge corresponent al cas de prova.
3.7.
  Proves d’Unitat: A nivell de classe Implementació d’un test driver Test Driver (TD): Programa que executa casos de prova, en recull els resultats i els compara amb els resultats esperats segons l’especificació.
Dues possibilitats per a la implementació en C++ d’un TD de la classe C són: o A l’arxiu C.cpp implementar una funció main() que es pugui compilar condicionalment, que creï objectes de la classe C, estableixi valors pels seus atributs, els hi enviï els missatges per executar els casos de prova, reculli resultats, els compari i ho desi tot en un arxiu.
o Implementar tot això en una nova classe separada, CTester, mitjançant els seus atributs i mètodes.
4. Definició de Casos de Prova Basada en Requeriments 4.1.
  Els casos de prova es poden definir seguint dos enfocaments: o Definició basada en el codi: L’estructura del codi font serveix com a referència  Caixa Blanca.
o Definició basada en les especificacions. Es consideren les entrades i sortides, no la implementació  Caixa Negra.
Implicacions: o Aplicabilitat a nivells:  Codi: Components i en alguns casos de la integració.
 Especificació: Integració, sistema i acceptació.
o Cobertura:  Codi: En cas ideal, cobreix tot ja que es disposa del codi quan es defineix el cas de prova.
 Especificació: no té cobertura total ja que no es té el codi en el moment de la especificació, però pot detectar per exemple que no s’ha implementat una part.
4.2.
   Escenaris de Casos de Prova L’execució d’un Cas de Prova comprèn una seqüència d’interaccions entre elements del context de l’objecte de prova (usuaris, provadors) i el propi objecte.
Escenari de cas de prova: Especifica interaccions a diferents nivells d’abstracció, és a dir, tipus d’entrades, tipus de sortides esperades, i les interaccions entre els tipus d’actors implicats en la prova.
4.3.
  Definició de Casos de Prova Nivells de les proves i tipus d’escenaris Escenaris interns al sistema: Proves de components i proves d’integració.
Escenaris d’interacció: Proves de sistema (es proven les interaccions del sistema amb els usuaris o altres sistemes).
Escenaris de context: Proves d’acceptació. Per exemple, si es defineix una prova de camp, s’haurà d’especificar en el cas de prova quines interaccions del context afecten al sistema (un sistema de lectura de matrícules en peatges, pot tenir un context en pluja).
4.4.
  Definició de Casos de Prova Basada en Requeriments Definició basada en requeriments de casos de prova per a proves de sistema i d’acceptació. Avantatges: o Els casos de prova estan relacionats amb les propietats del sistema significatives per a clients i usuaris.
o Atès que els casos de prova es deriven dels requeriments, durant l’execució de les proves es pot detectar requeriments que falten o implementacions errònies.
o Errors no detectats dels requeriments es poden detectar en definir casos de prova a partir dels requeriments.
Dos tipus: o Derivació directa dels casos de prova a partir dels requeriments.
 Prova de partició equivalent.
o Derivació de casos de prova basada en models.
 Quan els requeriments s’han especificat amb eines de modelat (com diagrames d’activitat o d’estats en UML), poden utilitzar-se com a models de prova.
 Cada camí a través d’un model de prova representa un escenari de prova.
 Es defineixen els camins segons criteris de cobertura: 5. Gestió de la Configuració (GC) 5.1.
Definició Del anglès SCM (SW Configuration Management), disciplina que una empresa pot utilitzar per estructurar, identificar i controlar els canvis fets als artefactes que produeix, i les seves versions al llarg del cicle de vida del SW. També per donar suport als processos de construcció de sistema i al seu desplegament a l’entorn dels clients.
Té com a estàndard: ↑ 𝑭𝒊𝒂𝒃𝒊𝒍𝒊𝒕𝒂𝒕 ; ↑ 𝑸𝒖𝒂𝒍𝒊𝒕𝒂𝒕 5.2.
     Ítem de Configuració (IC): Conjunts d’elements SW tractats com una sola unitat.
Exemple: Conjunt de funcions en un mateix fitxer de codi.
Versió d’un IC: Variant respecte l’IC original, difereix en quelcom, inclou millores.
Revisió d’un IC: Nona “versió”, de correcció d’errors d’una versió anterior.
Línia base (Baseline): Especificació o producte que ha estat revisat formalment i serveix com a base per a posteriors desenvolupament. Només es pot modificar mitjançant mecanismes formals de gestió de canvis.
La línia base es pot veure com un tall horitzontal del SW, mentre que les versions i revisions dels IC són talls verticals.
5.3.
         Conceptes GC Best Practices (“Què”) Identificar i emmagatzemar els artefactes seleccionats com a IC en un repositori segur.
Seguiment dels canvis als IC.
Organitzar els IC en components amb versió associada.
Crear Baselines.
Organitzar i integrar conjunts consistents de versions utilitzant activitats.
Mantenir llocs de treball estables i consistents.
Assegurar que la construcció de sistemes és reproduïble.
Suportar canvis concurrents sobre IC i components.
Integrar aviat i freqüentment.
*El “Com” i “Qui” s’especifiquen en un pla de GC (SCM Plan).
...

Tags:
Comprar Previsualizar