Resumen Informatica IV

8/17/2019 Resumen Informatica IV

1/58

RESUMEN INFORMATICA IV

PUDS FASES:

Inicio Elaboración Construcción Transición

Cada Flujo se trabajo se describe enunciando: Actividades Artefactos Trabajadores

UNIDAD N° 1 MODELO DE DISEÑO

Modelo de Análisis: Terminado el modelo se tiene una descripción detallada de todos los reuisitos delsistema!

Modelo de Diseño: Constituye una formalización y refinamiento adicional al modelo de anlisis!

Modelo de o"#etos re$resentando la realización f%sica de los casos de uso!

&ermite conocer es$ecificaciones muy detalladas de todos los o"#etos'

incluyendo o$eraciones y atri"utos!

Se definir"n e#pl$citamente las interfaces de los objetos % la sem"ntica de lasoperaciones! Se compondr" de bloues ue constituir"n los objetos de dise&o' ue lue(o ser"nimplementados como códi(o fuente' abstra%endo la implementación real! Inicialmente cada objeto de an"lisis se transformar" en un bloue' teniendo

rastreabilidad en los modelos! Es una abstracción de cómo el sistema se constru%e realmente % nos permitereducir la complejidad del mismo! Es la )ltima parte de la iteración de elaboración % comien*a la de construcción! Se deben tener definidas las +erramientas ue se utili*ar"n en el desarrollo de laaplicación' %a ue muc+as cosas se pueden dejar listas % auto(enerarlas para el modelode implementación!

Para desarrollar el modelo de dise&o debemos:• Identificar el am"iente de im$lementación: Identificar e investi(ar las consecuencias ue elambiente de implementación tendr" sobre el dise&o!•

Incor$orar estas conclusiones y desarrollar un $rimer enfo(ue del modelo de dise)o*Usamos el modelo de an"lisis como base % traducimos los objetos de an"lisis a objetos de dise&o'de acuerdo al ambiente actual de implementación!

,

Flujos de trabajo -odelado de .e(ocio /euerimientos

Dise&o Implementación Prueba

Info I0

A DS


2/58

• +escri"ir cómo interact,an los o"#etos en cada caso de uso es$ec%fico : El modelo de dise&ose focali*a en describir todos los est$mulos enviados entre objetos % u1 operación +ar" cada uno!Este proceso nos dar" las interfases de cada objeto!

Rastreabilidad: Se puede rastrear una clase desde el códi(o fuente al an"lisis % viceversa! Es importante porue a medida ue el sistema tiene cambios a lo lar(o de su

ciclo de vida se necesita saber siempre dónde se deben +acer los cambios en elcódi(o fuente!

Artefatos-!.Clases de dise)o*

Son a"stracciones de clases de im$lementación!

-uc+as caracter$sticas de las clases tienen relación directa con el len(uajede pro(ramación' por eso es necesario tenerlo ele(ido en esta instancia! Se deben definir para cada clase sus m1todos' atributos' par"metros' tipos'visibilidad de los atributos 2p)blicos' prote(idos' privados' ami(os3!

/!.Realización de casos de uso de dise)o*

Se 0inculan directamente con las realizaciones de casos de uso de

anlisis' los cuales se relacionan con casos de uso de modelos de casos de

uso 1as% se traza rastrea"ilidad a tra02s de los distintos modelos3!

Se tienen en cuenta los distintos reuerimientos no funcionales ue sefueron recolectando! 4as realizaciones $oseen*

• descri$ción te5tual del flu#o de e0entos'

• dia6ramas de clases'

• dia6ramas de interacción! Dia!ra"as de lases:

4as clases % subsistemas pueden intervenir en m"s de un caso de unareali*ación de casos de uso! A trav1s de ellos se pueden tener re(istrado u1 clases intervienen en lasreali*aciones de los distintos casos de uso!

Administrador de

sistema

Interfaz Entrada

Botones de Com ando

Cuadros de Texto

Etiquetas

Opciones()

Interfaz Salida

Botones de Com ando

Etiquetas

visualización()

Confirmación()

suario

!om"re Apellido

#irección

Telefono

Id Empleado

In$resar()

Borrar()

%odificar()

&estor de personal

Entidad de control de personal

O"tener datos de us uarios()

Actualizar datos de usuarios()

Imprimir resultados()

&enerar consulta de usuarios()

5


3/58

Dia!ra"as de interai#n:o Se utili*an Dia!ra"as de se$enia%o En ellos las interacciones entre objetos se representan mediante la

transferencia de mensajes entre dic+os objetos!o -uestra las interacciones entre objetos ordenadas en secuencia temporal!

o Se utili*an para validar casos de uso!o Documentan el dise&o desde el punto de vista de los casos de uso

observando u1 mensajes se env$an a los objetos' componentes o casos deuso % viendo (rosso modo cu"nto tiempo consume el m1todo invocado!

o A%udan a comprender los cuellos de botella potenciales para poder eliminarlos!

o &one'tos relaionados: L(nea de )ida de $n ob*eto +lifeline,:

• /epresenta la vida del objeto durante la interacción!• Un objeto se representa como una l$nea vertical punteada con

un rect"n(ulo de encabe*ado % con rect"n(ulos a trav1s de la l$nea principal ue denotan la ejecución de m1todos 2activación3! Elrect"n(ulo de encabe*ado contiene el nombre del objeto % el de suclase en un formato nom"reO"#eto*nom"reClase!

Ati)ai#n: • -uestra el per$odo de tiempo en el cual el objeto seencuentra desarrollando al(una operación!• Se denota como un rect"n(ulo del(ado sobre la l$nea de vidadel objeto!

Mensa*e: • Se denota mediante una l$nea sólida diri(ida desde el objeto

ue emite el mensaje +acia el objeto ue lo ejecuta!-ie"'os de transii#n: • En un entorno de objetos concurrentes o de demoras en larecepción de mensajes es )til a(re(ar nombres a los tiempos desalida % de lle(ada de mensajes!

6


4/58

' Administrador de

sistema

' Administrador de

sistemaInterfaz entradaInterfaz en trada &estor (ersonal&estor (ersonal suariossuarios Interfaz SalidaInterfaz Salida

In$resa opcion

Solicita In$reso #atos

In$resa #atos

#atos a c)equear

Solicita "usqueda de #atos

#evuelve #atos

C)equea consistencia

Solicita visualización de la transacción

*isualiza Transacción

7!.Su"sistema de dise)o*

.er"ite or!ani/ar 0 a!r$'ar las lases de diseño de a$erdo a s$ f$nionalidad +ará "as "ane*able el "odelo,% Debe e#istir independencia entre los subsistemas para lo(rar su

reutili*ación % a la +ora de las modificaciones' %a ue los cambios en unos noafectar"n a los otros! Su"sistema de ser0icio: prepara al sistema para cambios de serviciosindividuales!

7


5/58

8!.Interfaz*

A tra02s de ellas se es$ecifican las distintas o$eraciones (ue $ueden ser

realizadas $or una clase o los su"sistemas!

Re$resentan la cara 0isi"le de la funcionalidad de una clase!

+entro de una clase' sus atri"utos y m2todos conformarn la interfaz!

Si se cambia el códi(o de un m1todo pero no se cambia ni su nombre' tipo % par"metros' sólo se +abr" cambiado funcionalidad % no su interfa*' por lo cual las clasesrelacionadas a 1sta no deber$an sufrir nin(una modificación! Si se a(re(an par"metros o se cambian tipos' s$ se debe cambiar la forma en ueestas clases se relacionaban!

9!.+escri$ción de la ar(uitectura*

+e"e estar constituida $or*

definición de su"sistemas (ue conforman el modelo de dise)o'

con sus interfaces'

clases de dise)o relacionadas directamente con clases deanlisis (ue conforma"an la 0ista del la ar(uitectura del modelo de

anlisis'

realizaciones de casos de uso rele0antes' los cuales tienen una

relación con las realizaciones del modelo de anlisis y con los casos de

uso del modelo de casos de uso!

:!.Modelo de des$lie6ue*

&ermite re$resentar cómo ser la distri"ución f%sica del sistema' o sea dónde

residir f%sicamente cada uno de los com$onentes 1clases de interfaz' de control'

de entidad3! 4as ubicaciones f$sicas se denominan nodos! E#isten relacionen entre ellos representadas por medios de comunicación: Internet'e#tranet' intranet! 8a% nodos ue contienen los componentes asociados a interfaces entre el sistema %los actores 2por ejemplo donde residen las distintas pantallas de aplicación3! 9tros nodos contienen las clases de control' ue residen en los servidores deaplicación!

8a% nodos donde estar"n las clases de entidad ue lue(o constituir"n los repositoriosde datos 2ASES DE DAT9S3!

Servidor de Base de

#atos Terminal de

ventas

Terminal de

administración

;


6/58

-raba*adores Ar2$iteto:

Res$onsa"le de ase6urar (ue el modelo de dise)o y de des$lie6ue se

corres$ondan con el modelo de casos de uso y de anlisis!

Cuida ue sea consistente % ue est1 todo lo si(nificativo para la aruitectura delmodelo!In6eniero de Casos de Uso*

Es el encar6ado de ase6urar las realizaciones de casos de uso del modelo de

casos de uso y del modelo de anlisis!

Cuida los detalles para ue cada caso de uso sea comprendido perfectamente % uelas relaciones con los casos de uso de los modelos anteriores est1n totalmente claras!

In6eniero de com$onentes*

Es el encar6ado de definir todo lo referido a las clases del dise)o y tam"i2n de

los su"sistemas de dise)o!

Para las clases define sus m1todos' atributos 2interfa*3 % las relaciones ue e#istencon otras clases' ue relaciones e#isten con otros subsistemas % de u1 forma serelacionan con los otros subsistemas 2interfaces3!

Fl$*o de -raba*o

+ise)o de la ar(uitectura*

Comenzamos en esta eta$a a definir los modelos de dise)o y de des$lie6ue'

utilizamos $ara ello los si6uientes elementos*

a% Nodos 0 s$s onfi!$raiones de o"$niai#n%b% S$bsiste"as 0 s$s interfaes%% &lases de diseño rele)antes 'ara la ar2$itet$ra%d% Meanis"os !en3rios de diseño%

a) Nodos y sus configuraciones de comunicación:

Toda a$licación est com$uesta $or tres ca$as' una encar6ada de la interfaz

con el usuario' otra de almacenamiento de la información y una ca$a intermedia

encar6ada de $rocesar las re6las y ló6ica del ne6ocio!

Estas capas pueden tener tanto una división ló(ica como f$sica:•di)isi#n l#!ia: en la aplicación se encuentran mu% biendivididas las tres funcionalidades de estas capas'


7/58

•di)isi#n f(sia: estas capas pueden residir en nodosdiferentes!

4as primeras aplicaciones' manejaban estas tres capas todas juntas' tanto f$sicacomo ló(icamente! El procesamiento se reali*aba en las mainframes % los usuariosacced$an a 1l a trav1s de terminales bobas! 4ue(o aparecieron aplicaciones partidas ló(icamente en dos capas: una reside en el

servidor % la otra se ejecuta en los clientes!2-odelo cliente= servidor3!• E#isten dos variantes de este modelo:

• Ser0idor inteli6ente* tanto la capa de datos como la de re(las de ne(ocioresiden en un servidor llamado D-S 2Dataase -ana(ement S%stem3!

4os clientes cumplen sólo la función de capa de interfa*' tomando lainformación ue los usuarios in(resan al sistema' enviando esto +acia elservidor % mostrando lo ue dic+o servidor env$a +acia el puesto!

• Cliente inteli6ente* en este caso el cliente no cumple )nicamente lafunción de interfa* con el usuario sino tambi1n las funciones de la capa intermedia'reali*ando todos los c+eueos % controles necesarios antes de +acer llamadas a la

capa de datos! Por )ltimo' est"n auellas aplicaciones partidas ló(icamente en tres capas 2podr$anestar o no divididas tambi1n f$sicamente!3:

• En estas aplicaciones est"n aisladas las tres funcionalidades de unaaplicación: interfa*' control % datos!• Entre las distintas ventajas est" la posibilidad de aumentar el rendimiento dela aplicación a medida ue e#istan m"s reuerimientos con la misma' %a ue lacapa intermedia al estar independi*ada de las otras dos' puede ir residiendo entantos servidores como va%a siendo necesario % es posible a(re(ar servidores amedida ue va%a +aciendo falta!• 4o mismo suceder$a con los servidores de base de batos' donde +a% dos

variantes de este modelo:• Aplicaciones ue se ejecutan en cada estación de trabajo'

(eneralmente reali*adas en len(uajes de pro(ramación' como 0isualasic!

• Aplicaciones ue se ejecutan en un servidor >eb % sonaccedidas desde las estaciones de trabajo por al()n e#plorador deinternet' como Internet E#plorer!

En el caso de aplicaciones ?indo>s' 1stas residen en cadaeuipo % deben estar instaladas en cada euipo! 4as aplicaciones?eb est"n instaladas en servidores >eb' 1stos pueden ir creciendo %

a(re(ando nuevos servidores a medida ue la aplicación aumentesus reuerimientos de rendimiento! En este $unto del flu#o se analizan los distintos nodos (ue se utilizarn' con sus

caracter%sticas t2cnicas' como las cone5iones (ue e5istirn entre 2stos!

b) Subsistemas y sus interfaces:

O"#eti0o de su"sistema* or6anizar el modelo de dise)o en $iezas mane#a"les!

A $artir de los $a(uetes de anlisis y de ser0icios definidos se de"en identificar

los su"sistemas (ue e5isten! Si la clase de un subsistema interact)a con una clase de otro sistema' se definir"una relación entre estos! Debemos definir la manera en ue estas clases se relacionan'es decir las interfaces ue permiten ue una clase sea accedida!2Ej!: los m1todos ueesta e#pone +acia fuera para ue sean invocados por otras clases3!

c) Clases de diseño relevantes para la arquitectura:

@


8/58

Es im$ortante detallar las clases (ue ;ay (ue tener en cuenta $ara la

ar(uitectura!

.o debemos anali*ar un (ran n)mero de clases ni bajar en un nivel de detallee#tremo en ese momento' sólo anali*ar las relevantes para la aruitectura! El an"lisis m"s fino se +ar" en el dise&o de clases % en el de casos de uso!

d) Mecanismos genéricos de diseño:

Se trata de todos a(uellos re(uisitos es$eciales (ue fuimos detectando enmodelos anteriores y $os$usimos ;asta tener me#or definidas las caracter%sticas

ms t2cnicas del $royecto 1$lataforma de cada ca$a' len6ua#es' "ases de datos3!

Suelen relacionarse con:• Persistencia!• Distribución transparente de objetos locales % remotos!• Se(uridad!• -ono o multiusuario!• -anejo de errores!• Transacciones!• Aruitectura de la aplicación 2una' dos o m"s capas ló(icas3!• Tipos de interfa* de usuario 2?indo>s o ?eb3!

+ise)o de un caso de uso*

ste tiene como objetivos:a3 Identificación de clases de dise&o!

b3 Interacciones entre objetos!c3 Identificación de subsistemas de dise&o!

d3 Interacciones entre subsistemas!a) Identificación de clases de diseño Para cada reali*ación de caso de uso se reco(en todas las clases del dise&o ueintervienen a trav1s de un dia(rama de clases de dise&o! Tomaremos el caso de uso = an"lisis con sus clases de an"lisis correspondientes %en base a esto % al resto de la información recabada +asta el momento para dic+o casodetectaremos todas las clases con sus respectivas relaciones! Para cada clase de dise&o asi(naremos un in(eniero de componentes comoresponsable de la misma!

b) Interacciones entre ob!etos

Se definen cómo interact,an las clases (ue inter0ienen en cada realización de

caso de uso! Se utili*a un dia(rama de secuencia ue contiene instancias de actores' los objetosde dise&o % las transmisiones de mensajes entre estos! Se transforma el dia(rama de colaboración de la reali*ación de caso de uso=an"lisis en un esbo*o inicial del correspondiente dia(rama de secuencia! A medida ue bajemos en detalle en cada caso podemos encontrar cursosalternativos para los casos como:

• nodos o cone#iones ue dejan de funcionar'• in(resos erróneos de información por parte de actores'• errores (enerados por la misma aplicación o por +ard>are!

c) Identificación de subsistemas de diseño

B


9/58

Se tomarn los $a(uetes de anlisis detectados en el modelo de anlisis y

adems a(uellos re(uisitos (ue de#amos $ara esta eta$a de dise)o y con esto se

delinearn los distintos su"sistemas de dise)o (ue inter0endrn en el sistema!

Se utili*ar" un dia(rama de clases!d) Interacciones entre subsistemas

&ara detectar las interacciones (ue e5isten entre los distintos su"sistemas se

utilizarn los dia6ramas de secuencia! Se reflejan las relaciones entre los actores % subsistemas a trav1s del env$o demensajes entre los mismos

+ise)o de una clase*

a se tiene claro cu"l ser" el rol e#acto de cada clase dentro de las distintasreali*aciones de casos de uso! a se tra*ó la relación con las clases detectadas en elmodelo de an"lisis! Pasemos a anali*ar para cada una de ellas:

o operaciones'o atributos'o

relaciones'o m1todos'o estados!

En el caso de las clases de entidad el anlisis de$ende de la "ase de datos a

utilizar y en este $unto se est en condiciones de normalizar la


10/58

Con el objeto de a(re(ar ma%or detalle para la implementación de la clase podemosreflejar los estados por los ue puede pasar una clase! En muc+os casos suele ser importante utili*ar dia(ramas de estados a trav1s de loscuales podemos reflejar su comportamiento cuando reciben un mensaje!

Dia!ra"a de estados -uestra el conjunto de estados por los cuales pasa un objeto durante su vida en una

aplicación junto con los cambios ue permiten pasar de un estado a otro! "stado:

Identifica un periodo de tiempo del objeto =no instant"neo= en el cual 1l est"esperando al(una operación' tiene cierto estado caracter$stico o puede recibirdeterminado tipo de est$mulos! Se representa mediante un rect"n(ulo con los bordes redondeados ue puede tenertres compartimientos: uno para el nombre' otro para el valor caracter$stico de losatributos del objeto en ese estado % otro para las acciones ue se reali*an al entrar'salir o estar en un estado 2entr%' e#it o do respectivamente3!

"ventos

Es una ocurrencia ue puede causar la transición de un objeto de un estado a otro! El nombre de un evento tiene alcance dentro del pauete en el cual est" definido'no es local a la clase ue lo nombre!

"nv#o de mensa!es

Puede representarse el momento en el cual se env$an mensajes a otros objetos! Esto se reali*a mediante una l$nea punteada diri(ida al dia(rama de estados delobjeto receptor del mensaje!

+ise)o de un su"sistema*

4os puntos clave a tener en cuenta son:• independencia entre subsistemas'• mantener interfaces % sus operaciones'• ase(urar ue el subsistema cumple con su objetivo en las distintasreali*aciones en las ue est1 involucrado!

&aso .rátio

-!. +ia6rama de casos de uso

4os casos de uso especifican una interacción entre un usuario % el sistema en el ue 1ste puede lo(rar un objetivo!Casos de uso para a(encia de aluiler de autos:• El cliente reser0a el 0e;%culo

Antes de disponer del ve+$culo el cliente debe +acer la reserva! Para ello se pone encontacto con la a(encia de aluiler % reali*a una solicitud! 4a a(encia la acepta o la rec+a*a bas"ndose en una serie de criterios' como porejemplo la disponibilidad de los ve+$culos o el +istorial de aluiler del solicitante! Si se acepta la reserva el comercio llena un formulario con los detalles del cliente %el pa(o del depósito completa el proceso de reserva!

• El cliente acude $or el 0e;%culo

Cuando el cliente lle(a a la a(encia de ve+$culos 1sta le asi(na el modelo deve+$culo solicitado se()n los niveles de stoc disponibles! Una ve* abonado el importe total el cliente recibe el automóvil!

,


11/58

• El cliente de0uel0e el 0e;%culo

El cliente devuelve el ve+$culo a la a(encia el d$a especificado en el acuerdo dealuiler!

/!.+ia6rama de clases de estructura esttica

4a si(uiente tarea consiste en clasificar los objetos % sus relaciones! E#aminar los casos de uso a%uda a identificar las clases! 4as clases de objetos se modelan utili*ando dia(ramas de estructura est"tica o declases ue muestran la estructura (eneral del sistema' as$ como las propiedadesrelacionales % de comportamiento!

7!. +ia6rama de secuencia

Proporcionan una vista detallada de un caso de uso! -uestran una interacción or(ani*ada en una secuencia de tiempo % a%uda adocumentar el flujo de ló(ica dentro de la aplicación! 4os participantes se muestran en el conte#to de los mensajes ue se transfierenentre ellos!

,,


12/58

8!.+ia6rama de cola"oración

4os dia(ramas de colaboración constitu%en otro tipo de dia(rama de interacción! -uestran cómo operan los objetos de un (rupo entre s$ en un caso de uso! A cada mensaje se le asi(na un n)mero para documentar el orden en el ue tienelu(ar!

9!.+ia6rama de estados

El estado de un objeto se define como sus atributos en un momento determinado! 4os objetos van pasando por distintos estados a medida ue se ven influenciados

por est$mulos e#ternos! El dia(rama de estados asi(na estos estados' as$ como los eventos de activaciónue +acen ue un objeto se encuentre en un estado determinado!

:!.+ia6rama de acti0idades

,5


13/58

4os dia(ramas de actividades muestran la ló(ica ue tiene lu(ar como respuesta alas acciones (eneradas internamente! Est" relacionado con una clase o caso de uso espec$fico % muestra los pasos ue sedeben reali*ar para llevar a cabo una operación determinada!

=!.+ia6rama de des$lie6ue

-uestran cómo est"n confi(urados el +ard>are % el soft>are del sistema!

>!.+ia6rama de com$onentes

Corresponden al modelo de implementación! -uestran cómo distintos subsistemas de soft>are conforman la estructura (eneraldel sistema ue se crea en una base de datos centrali*ada ue contiene re(istros de

aluileres anteriores' detalles del ve+$culo' re(istros de servicios % detalles del cliente% del empleado!

,6


14/58

/esulta esencial ue estos datos se centralicen en una base de datos porue losniveles de stoc var$an con las +oras % todas las partes deben disponer de informaciónde )ltima +ora! El mantenimiento de los datos actuali*ados reuiere actuali*aciones de lainformación en tiempo real de todas las partes!

UNIDAD N°4 MODELO DE IM.LEMEN-A&ION

Modelo de I"'le"entai#n: usca implementar cada objeto espec$fico en t1rminos de componentes 2scripts' arc+ivos

de códi6o "inario ? e#ecuta"les.'etc!3! Son ;erramientas fundamentales los len6ua#es de $ro6ramación y las li"rer%as!

Se toman los resultados del dise)o $ara con0ertirlos en un soft@are e#ecuta"le un

sistema (ue inte6ra com$onentes e5$resados en arc;i0os fuentes' e#ecuta"les' códi6o "inario y

similares dndole com$ortamiento concreto al modelo!

4a im$lementación es el $roceso $rota6onista durante las iteraciones de la fase de

construcción! 9bserve ue tambi1n se desarrolla trabajo de implementación durante las fases deelaboración % transición! Generalmente en estos casos' las actividades de implementación dansoporte a los flujos de an"lisis % dise&o mediante prototiposH % la corrección de errores empotradosen el códi(o' respectivamente! 4os propósitos de este flujo de trabajo son los si(uientes:

•

Planificar en pasos peue&os % manejables 2enfoue incremental3 las inte(racionesde sistema necesarias en cada iteración!

,7


15/58

• Definir la or(ani*ación ue tendr" el códi(o en t1rminos de subsistemas % capas de proceso' mostrando la asi(nación de componentes ejecutables a nodos del dia6rama dedes$lie6ue!

• Implementar clases % objetos en t1rminos de componentes 2arc+ivos de códi(ofuente' arc+ivos binarios' arc+ivos ejecutables' etc!3' mostrando la asi(nación %distribución de los mismos en un dia6rama de com$onentes!• Probar los componentes individuales implementados' compilando e inte(r"ndolosen uno o m"s ejecutables libres de errores!• Inte(rar los resultados producidos por desarrolladores individuales o euipos en unsistema ejecutable!

Relación con otros flu#os de tra"a#o

Al(unas vinculaciones entre el flujo de trabajo implementación % los dem"s flujos de trabajo: Todo el proceso de desarrollo propuesto por el PUD est" conducido por casos de uso! Eneste flujo de trabajo se producen modelos ue reali*an % tienen una tra*a definida +acia el modelo decasos de uso obtenido en el flujo reuerimientos! 4os artefactos $roducidos durante los flu#os de tra"a#o anlisis y dise)o son una

entrada $rimaria $ara el $roceso desarrollado durante este flu#o de tra"a#o!

En el flujo de trabajo pruebas se definen los casos de prueba ue ser"n incluidos durante

cada una de las inte(raciones de subsistemas % sistemas ue acontecen durante este flujo de trabajo!2.1. Implementar el diseño

Cada clase del dise&o es implementada codificando en un len(uaje de pro(ramación' outili*ando un componente pree#istente! Por eso la manera en ue una clase del dise&o ser"concretamente implementada depende del len(uaje utili*ado!

El modelo de dise&o puede ser m"s o menos ajustado al modelo de implementacióndependiendo de cómo +a(a corresponder las clases o construcciones similares en el len(uaje deimplementación ele(ido!

Es necesario disponer antes de ue el dise&o comience' la forma en ue las clases en elmodelo de dise&o se relacionan con las clases de implementación asentando esta decisión en la Gu$ade Dise&o!

/!/! 4as $rue"as de desarrollo 4a frase Prueba de DesarrolloJ es utili*ada para cate(ori*ar las actividades de pruebaejecutadas por los aruitectos' in(enieros de componentes' pro(ramadores o desarrolladores desoft>are!

En muc+os de los m1todos tradicionales se consideran los si(uientes tipos de pruebas:• Pruebas de unidad: prueba de cada componente individual• Pruebas de inte(ración: prueba de funcionamiento de subsistemas• Pruebas de Sistema: prueba de funcionamiento del sistema como un todo!

Esta cate(ori*ación es correcta' sin embar(o el problema sur(e cuando se decide inte(rarlos subsistemas % el sistema total cuando casi se +a concluido la codificación de los componentes %se definen euipos de pruebas ue actuar"n por etapas! Puede ser mu% tarde' los errores podr$an propa(arse sin ser detectados por los diferentes euipos de prueba!

4as fallas descubiertas podr$an develar (raves problemas de dise&o % (enerar un alto (radode retrabajo no deseable para los costos % oportunidad de entre(a del producto final!

.o espere terminar todos los componentes para inte(rar subsistemas % el sistema final! 4oue ser$a peor a)n' no deje las pruebas de componentes para el final de la fase de construcción! Encada iteración' de la fase construcción' en cada construcción' a)n en la fase de elaboración' +a(a pruebas de inte(ración % pruebas de sistema!

/!7! Entornos de desarrollo e inte6ración

Un sistema (eneralmente es implementado por euipos de desarrolladores o pro(ramadoresindividuales ue trabajan juntos % en paralelo! Para ue esto sea posible son necesarios los si(uientesespacios o entornos de trabajo:

Un entorno de desarrollo indi0idual $ara cada $ro6ramador*• A los efectos de editar' compilar' ejecutar % probar todos los componentes% el subsistema asi(nado' cada pro(ramador tendr" un entorno de trabajoindividual!

,;


16/58

• .o es necesario ue en este espacio el desarrollador dispon(a de los dem"ssubsistemas sobre los cuales no tiene responsabilidad!• Es recomendable por otra parte ue cada pro(ramador ten(a accesomediante un repositorio com)n desde donde acceder a otros subsistemas % librer$asde uso compartido!

o Un entorno de inte6ración de su"sistemas $ara el 6ru$o de desarrollo*

• A veces euipos de implementadores desarrollan simult"neamente sobreel mismo subsistema! En este caso los primeros necesitan inte(rar suscomponentes en un subsistema antes de ue el mismo pueda ser liberado para su inte(ración al sistema total! Un miembro del euipo de desarrolloact)a como inte(rador' siendo su responsabilidad tambi1n sumantenimiento % rendimiento!

o Un entorno de inte6ración del sistema total*

• Kui1n o ui1nes cumplan con el rol de inte(rador deber"n contar con unentorno de inte(ración del sistema total en el ue puedan a(re(ar loscomponentes individuales %Lo subsistemas ue resultaran al cabo de cadaiteración en una Construcción!

Fl$*o de traba*o de i"'le"entai#n Estructurar el -odelo de Implementación es la primera actividad desarrollada en el marcode la Implementación! 4os flujos: reuerimientos' an"lisis % dise&o ocurren con preeminencia en la Fase deElaboración! En esa etapa comen*amos a dar forma al -odelo de Implementación! En cada iteración' % en la medida en ue avan*amos +acia la fase de Construcción Mdondesubsisten declinando su incidencia actividades de reuerimientos' an"lisis % dise&o= toman ma%or prota(onismo las de: Estructuración del -odelo de Implementación' Planeamiento de la Inte(ración'Implementación de Componentes' Inte(ración de los Subsistemas % el Sistema como un todo!

,


17/58

Ati)idades

3.1. Estructurar el modelo de implementación

El propósito del flujo de trabajo Estructurar el -odelo de Implementación es: Identificar los componentes si(nificativos aruitectónicamente 2ejecutables3! Asi(nar componentes a los nodos de red! El propósito de esta actividad desarrollada por el aruitecto de soft>are es establecer laaruitectura en la ue se apo%ar" la implementación % la asi(nación de responsabilidades parasubsistemas de implementación % sus respectivos componentes! Un modelo de implementación bien or(ani*ado resulta en la ocurrencia de un n)meromenor de conflictos durante el desarrollo de componentes % el proceso de construcciónH tambi1n previene problemas de confi(uración % facilita las sucesivas inte(raciones de componentes %subsistemas!

-raba*adores Kuien cumpla con el rol de aruitecto de soft>are es uien tiene la principalresponsabilidad en la definición de -odelo de Implementación! 4a naturale*a del trabajo adesarrollar su(iere ue la o las personas ue administran esta actividad posean e#periencia en laconstrucción' administración de la confi(uración % el len(uaje de pro(ramación ue se utili*ar" paraimplementar el sistema!

Linea"ientos de -raba*o Estructurar el modelo de implementación es al(o ue debemos +acer en paralelo con la

evolución de otros aspectos de la aruitectura!

,@


18/58

4a actividad Estructurar el -odelo de Implementación a su ve* contempla los si(uientes pasos:

Crear el modelo de implementación inicial Ajustar los subsistemas de implementación Definir los imports M referencias a otros componentes = necesarios para cada

subsistema! Decidir cómo tratar los ejecutables! Decidir cómo tratar los elementos de prueba! Actuali*ar la vista de implementación!

&rear el "odelo de i"'le"entai#n iniial 4a primera versión del modelo de implementación se obtiene como una copia espejada de

la )ltima versión del -odelo de Dise&o! 4os pauetes de dise&o se e#presan como subsistemas compuestos a su ve* de

componentes % todos los arc+ivos relacionados necesarios para implementarlos! Considere ue cada clase del dise&o ser" un componente implementado codificando en un

len(uaje de pro(ramación o empleando un componente pree#istente! 4a manera en ue una clase deldise&o ser" concretamente implementada depender" del len(uaje utili*ado!

A*$star los s$bsiste"as de i"'le"entai#n

El propósito de este paso es adaptar la estructura del modelo de implementación acuestiones t"cticas relacionadas con el entorno de trabajo! Estas adaptaciones facilitan laor(ani*ación del euipo de trabajo % debe e#presar' si +ubiera' las restricciones del len(uaje de pro(ramación a utili*ar!

Definir i"'orts neesarios 'ara ada s$bsiste"a El objeto au$ es definir las dependencias % visibilidad de componentes entre subsistemaso módulos! Generalmente' las dependencias en el modelo de implementación son +eredadas delmodelo de Dise&o' e#cepto cuando la estructura del modelo de implementación +a sido ajustada! Se presenta la estructura de capas de los subsistemas en dia(ramas de componentes!

Deidir #"o tratar e*e$tables 4os ejecutables % otros objetos derivados son el resultado de aplicar un proceso deconstrucción sobre un subsistema de implementación' % pertenecen ló(icamente a dic+o subsistema! En el caso m"s simple' para cada subsistema de implementación +abr" un $tem deconfi(uración 2nodo de la red3 para cada ejecutable' % un $tem de confi(uración para contener losfuentes % otros elementos utili*ados para producirlo! Desde el punto de vista del modelado' un conjunto de ejecutables producidos en un proceso de construcción puede ser representado como un artefacto: el artefacto Construcciónasociado a un subsistema de implementación dado!

Deidir #"o tratar los ele"entos de 'r$eba En (eneral los componentes % subsistemas de prueba no son tratados en forma mu%diferente al del resto del soft>are desarrollado! Sin embar(o' los componentes % subsistemas de prueba no forman parte del sistema

implantado' % por lo (eneral no se entre(an al cliente! Por lo tanto la recomendación es aislar estoscomponentes en una estructura de directorio o pauete' (aranti*ando su visibilidadH pero facilitandosu eliminación al momento de construir la versión operativa del soft>are!

At$ali/ar la )ista de i"'le"entai#n Este paso consiste b"sicamente en la actuali*ación del documento de Aruitectura deSoft>are % los dia(ramas correspondientes al modelo de implementación!

7!/! &lanear la inte6ración

En la planificación de la inte(ración se consideran los subsistemas ue ser"nimplementados as$ como otros subsistemas e#istentes ue ser"n inte(rados en la iteración corriente! El propósito del flujo de trabajo Planear la Inte(ración es por lo tanto:

Planear la inte(ración del sistema para la actual iteración!-raba*adores

4a inte(ración es +ec+a +abitualmente por una persona o un peue&o euipo!

,B


19/58

4os inte(radores necesitan e#periencia en la (estión de construcciones %confi(uraciones de soft>areH pero fundamentalmente se reuiere ue los mismos posean unfluido manejo del len(uaje de pro(ramación sobre el cual se desarrollaran los componentes!

Debido a ue a menudo la inte(ración se desarrolla con un alto (rado deautomati*ación' se reuiere tambi1n conocimientos en sistemas operativos' interpretes decomandos % +erramientas!

Linea"ientos de -raba*o

4a planificación de la inte(ración debe ser +ec+a tempranamente' al menos de modorudimentario cuando se define la aruitectura! Con el objeto de evitar ue el plan de construcción uede obsoleto' este debe seractuali*ado cada ve* ue sucedan modificaciones en la aruitectura % el dise&o! Al menos una ve* por cada iteración en las fases de construcción % transición' uiencumple con el rol de inte(rador' desarrolla esta actividad ue tiene como objetivo principal el de planear el modo en ue +an inte(rarse cada componente % cada subsistema en el sistema ue seconstru%e! 4os si(uientes son los pasos ue comprenden esta actividad:

• Identificar subsistemas•Definir conjuntos de construcción

•Definir series de construcción! Identifiar S$bsiste"as

El plan de la iteración identifica % especifica los subsistemas con sus respectivos casos deusos % escenarios a ser implementados! En el plan se anali*an tambi1n las reali*aciones decasos de uso' dia(ramas de secuencia % colaboración! Se identifican tambi1n otros subsistemasnecesarios para facilitar la compilación % crear una versión ejecutable del soft>are!

Definir on*$ntos de onstr$i#n Para facilitar las cosas % manejar la complejidad se reduce el n)mero de cosas sobre lasue es necesario pensar! En esta situación es recomendable definir conjuntos si(nificativos desubsistemas ue funcionan juntos % pueden considerarse como una unidad desde el punto de vista deuna inte(ración!

Definir series de onstr$i#n

Se define una serie de construcciones para inte(rar el sistema incrementalmente! Esto es+ec+o de abajo +acia arriba en la estructura de capas del sistema ue compone el modelo deimplementación! Por cada construcción' se definen cuales subsistemas deben ir en el % ue otrossubsistemas deben estar disponibles en calidad de stubs M componentes de utilidad para facilitar suimplementación =!

7!7! Im$lementar com$onentes

4os implementadores escriben códi(o fuente' adaptan códi(o e#istente' compilan %ejecutan pruebas de unidad de componentes' (enerando re trabajo para el dise&ador en caso dedetectarse errores atribuibles al mismo! 4os implementadores tambi1n corri(en defectos % vuelven a ejecutar pruebas de unidad

para verificar cambios! Finalmente el códi(o es revisado para evaluar calidad % cumplimiento de lasre(las ue podr$an estar previstas en una (u$a de pro(ramación! El objeto principal del flujo de trabajo Implementar Componentes consiste en

• Producir componentes de soft>are ajustado a los reuerimientos % libre deerrores!

-raba*adores 4a actividad de pro(ramación normalmente es desarrollada por una persona' sin embar(o propuestas metodoló(icas actuales como NP MNtreme Pro(rammin(= est"n proponiendo ue lacodificación de cada componente sea reali*ada de a pares de pro(ramadores! /ecordar ue las personas ue cumplan este rol deben manejar fluidamente el len(uaje de pro(ramación adoptado! Linea"ientos de traba*o

4a actividad de revisión es recomendable ue la lleven a cabo peue&os euipos de dos otres personas ue podr$an incluir miembros del "rea usuaria % pro(ramadores e#perimentados!

,


20/58

Este trabajo tiene mejores resultados si se reali*a en varias etapas' cada una enfocada en peue&as secciones del códi(o! Son m"s productivas las revisiones frecuentes con un alcance acotado! En estas sesiones seidentifican los problemas espec$ficos ue necesitan ser resueltos! 4as correcciones se implementanal terminar la revisión! El propósito principal de esta actividad es producir nuevo códi(o fuente o modificar ele#istente de acuerdo a las especificaciones del modelo de dise&o! 4a actividad implementar componente a su ve* contempla los si(uientes pasos:

Implementar operaciones Implementar Estados Dele(ar para reutili*ar Implementar asociaciones Implementar atributos 8acer la revisión preliminar del códi(o!

I"'le"entar o'eraionesPara implementar operaciones +acemos lo si(uiente:

Ele(imos un al(oritmo Ele(imos una estructura de datos apropiada para el al(oritmo

Definimos nuevas clases % operaciones de ser necesario Codificamos la operación

Elección de un al(oritmo* muc+as operaciones son lo suficientemente simples para serimplementadas directamente desde la especificación de las mismas! En otros casos podr$a reuerir unal(oritmo no trivial por al(una de las si(uientes ra*ones:

o Intentamos implementar operaciones complejaso Kueremos optimi*ar operaciones simples pero resueltas de modo ineficiente! Por ejemplo'

un componente ue debe ordenar los elementos de una listaH por ra*ones de perfomance' podr$amos optar entre escribir nuestro propio al(oritmo 2burbuja' s+ell' dicotómicos' etc!3o el provisto por el len(uaje de implementación!

Elección de una estructura de datos apropiada para el al(oritmo: la implementación de la

estructura de datos para implementar el al(oritmo va a depender del len(uaje ele(ido % podr$a recaer enal(una de las si(uientes: arra%s' lists' ueues' stacs' ba(s o variaciones de estas! 4a ma%or$a de loslen(uajes orientados a objetos proveen librer$as de componentes reusables con estos tipos!

Definición de nuevas clases % operaciones* esto sucede cuando necesitamos nuevas clasesue manten(an resultados intermedios! Por ejemplo' al descomponer una operación compleja en dosoperaciones m"s simples! Estas operaciones ser"n privadas % visibles por lo tanto solo en el conte#to de lamisma % no fuera de ella!

Codificar la operación* escribimos el códi(o para la operación empe*ando por lassentencias ue definen su interfase! Por ejemplo' la declaración de función miembro en COO'especificación de subpro(ramas en Ada' m1todos en 0isual asic o ava ! I"'le"entar estados

4a manera m"s sencilla de implementar el estado de un objeto es por referencia a los

valores de sus atributos sin nin(una representación especial! 4a transición de estados para un objetoestar" impl$cita en los cambios de valor de los atributos % las variaciones de comportamiento ueser"n pro(ramadas a trav1s de sentencias condicionales! Esta solución no ser" satisfactoria paracomportamientos complejos debido a la dificultad implicada en una eventual modificación delcomportamiento la necesidad de nuevos estados! Si el comportamiento de los componentes es estadodependiente' podr$an ser necesarios dia(ramas de transición de estados ue describan sucomportamiento' faciliten su interpretación % posterior codificación!

Dele!ar 'ara re$tili/ar Si una clase o parte de una clase puede ser implementada reutili*ando una clase e#istente'se usa el mecanismo de dele(ación en lu(ar de la +erencia! Dele(ación si(nifica ue la clase es implementada con la a%uda de otra clase! 4a clase

referencia un objeto de otra clase utili*ando una variable! Cuando una operación es llamada' laoperación llama una operación del objeto referenciado =de la clase reutili*ada=! /ecuerde ue en un buen dise&o de objetos' estos son bastante +ara(anes! Est"n buscando todo el tiempo dele(ar laresponsabilidad a un especialistaJ para ue +a(a lo ue a 1l se le +a pedido!

5


21/58

I"'le"entar asoiaiones Una asociación unidireccional es implementada como un puntero =un atributo ue contieneuna referencia a un objeto=! Si la cardinalidad destino fuera uno' entonces esta puede ser definidacomo un puntero simple! En cambio si la cardinalidad destino es muc;os' entonces debe ser tratadacomo un conjunto de punteros! Una asociación bidireccional es materiali*ada como atributos en ambas clases procediendodel mismo modo ue se indicó para asociaciones unidireccionales!

En cada len(uaje de pro(ramación en particular podr" descubrir mecanismos de asociación propios del entorno ue se utili*a!

I"'le"entar atrib$tosE#isten tres maneras de implementar atributos:

A trav1s de variables primitivas incluidas en el len(uaje /eutili*ando una clase o componente e#istente Por medio de una nueva clase! Definir una nueva clase es a menudo m"s fle#ible' pero ten(a en cuenta ue introduce unaindirección innecesaria! Por ejemplo' el n)mero de se(uridad social de un empleado podr$a serimplementado como un atributo de tipo Strin( o como una nueva clase! Podr$a darse tambi1n el caso ue (rupos de atributos se combinen en dos nuevas clases tal

como se muestra en el ejemplo si(uiente donde ambas implementaciones son correctas:

5aer la re)isi#n 'reli"inar del #di!o Siempre se compila el códi(o' % se fija al m"#imo nivel de detalle los avisos delcompilador! Se controla mentalmente las operaciones' recorriendo el códi(o tratando de encontrar todoslos caminos e identificando todas las condiciones de e#cepción! Esto se lleva a cabo tan pronto comose pueda despu1s de implementar al(o nuevo! Si fuera posible' se utili*a +erramientas autom"ticas de revisión!

7!8! Inte6rar cada Su"sistema

Si m"s de un implementador trabaja en la construcción del mismo subsistema' es necesariocrear re(ularmente una nueva versión consistente del subsistema para ue en la misma se inte(renlos cambios producidos por cada desarrollador individual! El resultado de estas inte(raciones esalojado en el entorno de inte(ración de subsistemas referido en el punto 5!6! Una ve* en este entorno de inte(ración cada construcción es probada' lue(o de lo cual' %+abiendo superado los reuerimientos de calidad preestablecidos' la nueva versión del subsistema pasa al entorno de inte(ración del sistema total! Entonces el propósito de este flujo de trabajo es:

Inte(rar los cambios producidos por m)ltiples desarrolladores' creando una nuevaversión de un subsistema de implementación!

-raba*adores 4a inte(ración de cada subsistema es +ec+a +abitualmente por una persona o un peue&oeuipo! 4os inte(radores necesitan e#periencia en la (estión de construcciones % confi(uracionesde soft>areH pero fundamentalmente se reuiere ue los mismos posean un fluido manejo dellen(uaje de pro(ramación sobre el cual se desarrollaran los componentes! Debido a ue a menudo lainte(ración se desarrolla con un alto (rado de automati*ación' se reuiere tambi1n conocimientos ensistemas operativos' interpretes de comandos % +erramientas! L inea"ientos de -raba*o El trabajo de inte(ración tiene +abitualmente un alto (rado de automati*ación con esfuer*omanual reuerido solo cuando la construcción falla por al(una circunstancia! Una estrate(ia

frecuente es pro(ramar construcciones % pruebas de unidad mediante procesos autom"ticos ue seejecuten durante la noc+e!7!9! Inte6rar el sistema

5,


22/58

Si(uiendo el plan de inte(ración de construcciones se a(re(a e inte(ra cada subsistema enel entorno de trabajo del sistema! De este modo se obtiene una nueva versión del soft>are ue essometida al flujo de trabajo de pruebas! El propósito entonces de este flujo de trabajo es:

o Inte(rar subsistemas de implementación para crear una nueva versión consistente delsistema total!

-raba*adores

/i(e lo mismo ue en el item anterior! Linea"ientos de -raba*o

/i(e lo mismo ue en el item anterior!

8!8 E#ecución de $rue"as unitarias

El propósito principal de esta actividad es verificar la especificación % la estructura internade una clase o del componente ue lo implementa! 4os pasos principales de esta actividad son los si(uientes:

Ejecutar pruebas unitarias Evaluar la ejecución de pruebas

0erificar resultados de pruebas /ecuperar a partir de pruebas suspendidas

E*e$tar 'r$ebas $nitarias Este paso consiste en la ejecución de procedimientos de prueba o scripts si las pruebas sonautomati*adas! El procedimiento mencionado consiste b"sicamente en:

Establecer el entorno de prueba para ase(urar ue todos los elementos necesariostales como +ard>are' soft>are' +erramientas' datos' librer$as' etc! +an sido previstos!

Iniciali*ar el entorno de prueba para ase(urar ue todos los componentes est"n enel estado inicial correcto para el inicio de la prueba!

Ejecutar los procedimientos de pruebas! 4a ejecución de los procedimientos de prueba var$an' lo cual depende tanto de si el mismo

es autom"tico' manual como de la necesidad de componentes Stubs % drivers espec$ficos! Pruebas automati*adas: se ejecutan los scripts creados durante el paso Implementar

Pruebas del Subflujo Implementar Componentes! Pruebas -anuales: se utili*an los procedimientos desarrollados durante la actividad

Estructurar Procedimientos de Pruebas ue son usados para ejecutar manualmente la prueba! E)al$ar la e*e$i#n de 'r$ebas

Este paso tiene el propósito de determinar si las pruebas conclu%eron con 1#ito' % tener unavisión clara de la acción correctiva reuerida! 4a ejecución de las pruebas termina en al(una de las si(uientes condiciones!

Normal* todos los procedimientos de pruebas 2o scripts3 se ejecutaron como se

pro%ectó! Si la prueba termina en condición normal' entonces se debe continuarcon la 0erificación de /esultados de Pruebas!

Anormal o $rematuro* los procedimientos de pruebas o scripts no se ejecutaroncompletamente como se +ab$a previsto! Cuando la prueba termina de modoanormal los resultados de la prueba pueden ser poco fiables! 8a% ue identificar lacausa del error' corre(irlo % re ejecutar el test!

Si la prueba termina de modo anormal' se debe retomar en el paso/ecuperación a partir de pruebas suspendidas!

6erifiar res$ltados de 'r$ebas El propósito de este paso es determinar si el resultado de la prueba es confiable eidentificar las acciones correctivas si los resultados indican fallas!

Cuando la prueba termina' se revisan los resultados para ase(urar ue los mismos sonconfiables' ue las advertencias de compilación 2>arnin(s3' o resultados inesperados' no +an sidoocasionados por influencias e#ternas tales como una iniciali*ación o datos incorrectos! Si las fallasreportadas se deben a errores identificados en artefactos de prueba o debido a problemas con el

55


23/58

entorno de prueba' se toman las acciones correctivas apropiadas % se ejecuta la prueba nuevamente!Si los resultados indican ue las fallas son (enuinamente atribuibles a los artefactos probadosentonces se contin)a con la actividad Corre(ir Errores!

Re$'erar a 'artir de 'arada de 'r$ebas En este caso la meta ser" determinar las acciones correctivas apropiadas para reiniciar una prueba detenida' corre(ir el problema' recuperar % ejecutar la prueba nuevamente! Esta parada puede deberse a fallas en los scripts utili*ados para lan*ar pruebas' en fallas

del sistema tales como ca$das de red' ca$das de +ard>are' etc! En todos estos casos los s$ntomas son parecidos: acciones inesperadas' ventanas emer(entes % eventos no previstos! El entorno de prueba parece no responder % +asta podr$a col(arse el sistema!

Para recuperar a partir de una situación como 1sta deber$a: Determinar la causa real del problema! Corre(ir el problema! Iniciali*ar el entorno de pruebas nuevamente! Ejecutar las pruebas nuevamente!

8!9 Corre6ir defectos

El propósito principal de esta actividad es implementar las correcciones al códi(o

documentadas en el documento de reuerimientos de cambios durante las actividades de pruebasunitarias de componentes % revisiones de códi(o!

4os pasos principales de esta actividad son: Estabili*ar el defecto! 4ocali*ar la falla! Corre(ir la falla!

Estabili/ar el defeto Este es el primer paso' e#teriori*ado como un s$ntoma del pro(rama' for*ando suocurrencia en forma efectiva! Si no se puede lo(rar ue el error suceda efectivamente' estamos antecomplicaciones % ser" muc+o m"s dif$cil locali*arlo! 4ue(o se limita el caso de prueba identificando cu"l de los factores del caso de prueba

+acen ue el error ocurra' % cuales factores son irrelevantes al mismo! Para determinar si un factor esirrelevante' se cambia el factor en cuestión % ejecuta el caso de pruebaH si el error a)n as$ ocurre' estefactor puede ser probablemente eliminado! Si se lo(ró' se finali*a con al menos un caso de prueba ue reproduce el error % tambi1ncon al(una idea sobre ue factores est"n relacionados con la ocurrencia del error!

Loali/ar la falla El pró#imo paso es ejecutar los casos de prueba ue ori(inan la falla e intentar identificarel lu(ar concreto del códi(o donde se produce el fallo! Ejemplos de cómo locali*ar una falla son:

Pon(a atención a la re(ión sospec+osa del códi(o! Pruebe una peue&a parte de 1l'comente para ue no se ejecute M la o las sentencias ue supone producen el error% corra nuevamente el caso de prueba! Contin)e comentando peda*os del pro(rama mientras el error persista! Como resultado se podr" identificar el lu(ar

preciso donde se produce la falla! Utilice un debu((erJ M +erramienta provista por un entorno de desarrollo de un

len(uaje de pro(ramación para locali*ar un error M para revisar el códi(o l$nea porl$nea % monitorear los valores de variables si(nificativas del pro(rama!

&orre!ir la falla Cuando la falla +a sido locali*ada es momento de corre(ir el códi(o! Esta debiera ser la

parte m"s f"cil del proceso! 4as si(uientes son al(unas recomendaciones para +acer efectiva la corrección:

• Ase()rese de comprender el problema % el pro(rama antes de efectuar lacorrección!• Corrija el problema' no el s$ntoma!

• 8a(a un cambio a la ve*! Corre(ir errores es en si misma una actividad propensa a incluir nuevos errores! Introdu*ca los cambios incrementalmente parafacilitar la locali*ación de nuevas fallas!

56


24/58

• Cuando la falla +a sido corre(ida a(re(ue un caso de prueba especial ueverifiue particularmente el error!

9! Artefactos

9!- Modelo de im$lementación

El modelo de implementación describe la forma en ue los elementos del modelo dedise&o' como las clases' se implementan en t1rminos de componentes' como arc+ivos de códi(ofuente' ejecutables' etc! Describe tambi1n cómo se or(ani*an los componentes de acuerdo con los mecanismos deestructuración % aruitectura de módulos disponibles en el entorno de implementación % en elle(uaje len(uajes de pro(ramación utili*ados' % cómo dependen los componentes unos de otros!

9!/ Construcción

Una Construcción es una versión operativa de parte o de un sistema completo uedemuestra un subconjunto de capacidades o funcionalidades propias del producto final! Es una e#presión concreta % resultante del ciclo de vida iterativo! /epresenta % demuestranla funcionalidad desarrollada a la fec+a! Cada Construcción es puesta bajo el mecanismo de control de confi(uración con el objetode retornar eventualmente a versiones previas cuando el a(re(ado de funcionalidad ocasiona problemas de funcionamiento o compromete la inte(ridad % estabilidad del sistema!

Durante el desarrollo iterativo del soft>are podr" +aber numerosas construcciones! Cadauna proveer" puntos de revisión % a%udar" a descubrir problemas de inte(ración en la medida uelos mismos +an sido introducidos!

9!7 Com$onente

Un componente es el empauetamiento f$sico de los elementos de un modelo' como sonlas clases en el modelo de dise&o! Al(unos estereotipos est"ndar de componentes son los si(uientes:

QQEjecutableRR: es un pro(rama ue puede ser ejecutado en un nodo! QQFileRR: es un arc+ivo ue contiene códi(o fuente o datos! QQ4ibrar%RR: es una librer$a est"tica o din"mica! 2dlls3 QQTablaRR: es una tabla de base de datos! QQDocumentoRR: es un documento!

Durante la creación de componentes en un entorno de implementación particular estosestereotipos pueden ser modificados para reflejar el si(nificado real de estos! 4os componentes

tienen las si(uientes caracter$sticas: /elación de tra*a con los elementos del modelo ue implementan! Implementación de varios elementos!

Por ejemplo' un componente podr$a implementar varias clases' sin embar(o' la formae#acta en ue se crea esta tra*a depende de cómo van a ser estructurados % armados en módulos losarc+ivos de códi(o fuente' dado el len(uaje de pro(ramación ue se est1 utili*ando!

9!8 Stu"s

Un componente es probado remitiendo mensajes a su interfase' esperando ue este lo procese % revisando el resultado! En el transcurso de este proceso' mu% +abitualmente' se utili*anotros componentes enviando tambi1n mensajes % utili*ando sus resultados! Estos )ltimoscomponentes pueden ocasionar problemas a la prueba:

Por no +aber sido a)n implementados! Por tener errores de funcionamiento' ocasionando confusión sobre el ori(en de los

problemas! Porue uno o m"s componentes de +ard>are podr$an no estar disponibles para el

pro(ramador! Piense por ejemplo en un sistema de control de accesos en el ue losdispositivos de lectura de las tarjetas ma(n1ticas o mecanismos de apertura de puertas podr$an no disponerse por los pro(ramadores!

Debido a ue la prueba podr$a tornarse mu% lenta cuando por ejemplo necesitainiciali*ar una base de datos!

a ue es mu% dif$cil provocar ciertos resultados! Piense por ejemplo ue todoslos m1todos de sus clases ue escriben en disco validan previamente el espaciodisponible! 9casionar la situación Sin espacio en discoJ podr$a ser una tarea bastante en(orrosa!

57


25/58

Para evitar estos problemas utili*amos los componentes Stubs' los cuales se comportancomo si fueran los componentes reales' al menos para los valores o mensajes ue su componenteenv$a al momento de la prueba! Con una perspectiva m"s amplia podr$amos considerar en estacate(or$a a emuladores ue simulan el comportamiento real de otros componentes no disponibles!

9!9! Su"sistema de im$lementación

4os subsistemas de implementación proporcionan una forma de or(ani*ar los artefactosdel modelo de implementación en tro*os m"s manejables! Un subsistema puede estar formado por

componentes' interfaces % otros subsistemas' inclusive en forma recursiva! Adem"s' un subsistema puede implementar =% as$ proporcionar= las interfases ue representan la funcionalidad ue e#portanen forma de operaciones! 4os subsistemas de implementación est"n mu% relacionados con los subsistemas de dise&oen el modelo de dise&o visto anteriormente! De +ec+o' los subsistemas de implementación deber$anse(uir la tra*a uno a uno de sus subsistemas de dise&o correspondientes!

9!: Interfases

4as interfases' %a definidas como artefactos en el Flujo de Trabajo Dise&o' pueden serutili*adas en el modelo de im$lementación para especificar las operaciones reali*adas porcomponentes % subsistemas! Adem"s como se mencionó anteriormente los componentes % los subsistemas pueden tener dependenciasJ de uso sobre interfases! En este caso las interfases no son necesariamente pantallas sino ue podr$amos entenderlascomo conectores o facilitadores de acceso a los elementos de un modelo! 4a definición de estosconectores puntos de enlace se implementan de acuerdo al len(uaje utili*ado! 4a firma 2visibilidad'nombre' ar(umentos de entrada L salida3 de una clase en cOO o en java son la interfase de acceso a lasmismas!

9!=! 4a 0ista del modelo im$lementación

4a vista de implementación es una de las cinco vistas aruitectónicas de un sistema! 4as

otras son la vista ló(ica' vista de casos de uso' vista de procesos % vista de desplie(ue! El propósito de la primera es capturar las decisiones de aruitectura +ec+as para laimplementación! T$picamente la vista de implementación contiene:

Una enumeración de todos los subsistemas del modelo de implementación! Dia(ramas de componentes ilustrando cómo los subsistemas est"n or(ani*ados en

capas % sus jeraru$as! Ilustraciones de las dependencias de importación entre subsistemas!

4a vista de implementación es utili*ada para: Asi(nar trabajo de implementación a pro(ramadores individuales' euipos de

pro(ramadores subcontratistas!

Evaluar la cantidad de códi(o a ser desarrollado' modificado o eliminado! Anali*ar la reutili*ación a (ran escala! Considerar estrate(ias del la versión en desarrollo!

Tanto la vista de implementación como las otras vistas de aruitectura son documentadasen el Documento de Aruitectura del Soft>are!

:! Tra"a#adores

:!- Ar(uitecto de Soft@are

El aruitecto de soft>are tiene por sobre todo % principalmente la responsabilidad demanejar las decisiones t1cnicas respecto de la aruitectura del soft>are! T$picamente el aruitectoidentifica % documenta los aspectos si(nificativos de la estructura del sistema' inclu%endo las vistasde reuerimientos' dise&o' implementación % puesta en marc+a del mismo!

El aruitecto es responsable de tomar decisiones ra*onables' atenuando los conflictos ue pudieran plantearse a partir de los intereses particulares de cada apostador = stae+older = delsistema! Es tambi1n su obli(ación manejar adecuadamente los ries(os t1cnicos % ase(urar ue las

5;


26/58

decisiones de 1ste tipo son convenientemente comunicadas' validadas % compartidas por losmiembros del euipo de trabajo!

:!/ Im$lementador

El rol del implementador o pro(ramador consiste fundamentalmente en el desarrollo % prueba de componentes en concordancia con los est"ndares adoptados en el pro%ecto para su posterior inte(ración en un subsistema ma%or! Cuando son necesarios componentes de prueba talescomo drivers stubs es el mismo pro(ramador el responsable de su desarrollo % prueba para

incorporarlos en los subsistemas de apo%o!:!7 Inte6rador de Sistemas

4os inte(radores son responsables de planificar % reali*ar la inte(ración de elementos deimplementación para producir construcciones o versiones ejecutables del sistema! Tal como se dijo en el punto 5!6 los implementadores liberan sus pro(ramas probados enun espacio de inte(ración de subsistemas donde el inte(rador los combina para producir unaconstrucción de un módulo o pauete del sistema! El inte(rador es responsable tambi1n de planear lainte(ración ue tiene lu(ar una ve* finali*ada la del nivel de subsistemas! Efectivamente' lossubsistemas o módulos obtenidos son a(re(ados e inte(rados posteriormente en otro espacio detrabajo correspondiente al sistema total!

UNIDAD N°7 MODELO DE .RUE8AS

&ro$ósito de las $rue"as

Planificar las pruebas necesarias en cada iteración' inclu%endo las pruebas de inte(ración %las pruebas de sistema! 4as pruebas de inte(ración son necesarias para cada construcción dentro de la iteraciónHmientras ue las pruebas de sistema son necesarias sólo al final de la iteración! Dise&ar e implementar las pruebas creando los casos de prueba ue especifican u1 probar'los procedimientos de prueba ue detallan cómo reali*ar las pruebas % si es posible' componentes de

prueba ejecutables para automati*ar las pruebas! /eali*ar las diferentes pruebas % manejar los resultados de cada una de ellassistem"ticamente! 4as construcciones en las ue se detectan defectos son probadas de nuevo % posiblementedevueltas a otro flujo de trabajo' como dise&o o implementación' de forma ue los defectosimportantes puedan ser arre(lados!Relación con otros flu#os de tra"a#o

El flujo de trabajo re(uerimientos captura los reuisitos para los productos de soft>are!Estos reuerimientos son el punto de partida % entrada principal de la actividad de identificación delas pruebas a reali*ar! El flujo de trabajo anlisis y dise)o determina el dise&o apropiado para el producto desoft>areH esta es otra entrada importante del proceso de identificación de las pruebas a reali*ar! El flujo de trabajo im$lementación produce construcciones del producto de soft>are ueson validadas por el flujo de trabajo pruebas! Dentro de una iteración varias construcciones podr$anser testeadas! +abitualmente una por ciclo de pruebas!

2.1. Psicología y economía de las pruebas Cuando se prueba un pro(rama se desea a(re(arle al()n valor =es decir' puesto uela prueba es una actividad costosa' se desea un incremento del valor del pro(rama! A(re(ar valor si(nifica aumentar su calidad o su confiabilidad' lo ue' a su ve*'si(nifica encontrar % eliminar errores! De au$ ue no se deba probar un pro(rama paramostrar ue funcionaH m"s bien es conveniente comen*ar con la suposición de ue el

pro(rama contiene errores % lue(o probar el pro(rama para encontrar tantos como sea posible! Puesto ue los seres +umanos tendemos a estar fuertemente orientados +acia laobtención de metas' el establecimiento de una de ellas en forma apropiada tiene (ranimportancia desde el punto de vista psicoló(ico!

5


27/58

Si la nuestra es demostrar ue el pro(rama no tiene errores' estaremos entoncessubconscientemente diri(idos +acia este fin' es decir' tenderemos a seleccionar datos de

prueba con baja probabilidad de +acer ue el pro(rama falle! Si nos proponemos demostrar ue el pro(rama tiene errores' nuestros datos de

prueba tendr"n una ma%or probabilidad de lo(rarlo! Esta )ltima manera de enfocar el problema a(re(a al pro(rama ma%or valor ue la

primera! Un caso de prueba ue descubre un error dif$cilmente pueda ser considerado comono e#itosoH mas bien' +a demostrado ser una valiosa inversión!2.2. Conceptos básicos-estin! de soft9are

/eali*ar testin( de soft>are no es debu((ear un códi(o' %a ue el objetivo es encontrar los problemas' pero no el ori(en de los mismos' aunue puede ocurrir ue en al(unas ocasiones losencuentre 2lue(o de encontrar el problema se buscar" el ori(en3! Tampoco es la demostración de ue en dic+o soft>are no +a% errores! Testear o probar un soft>are es someterlo a ciertas condiciones a fin de demostrar si esv"lido o no a partir de los reuerimientos ue le dieron ori(en' es decir' si satisface losreuerimientos definidos 20alidación3' %a ue podr$a ocurrir ue un soft>are no tuviera defectos

pero ue tampoco reali*ara la funcionalidad especificada % acordada con el usuario! Implica la 0erificación de ue dic+as funcionalidades se implementan correctamente! Testin( es una actividad destructiva' % el mismo es e#itoso en la medida ue descubredefectos en el soft>are! Esta actividad' definitivamente a(re(a valor 2calidad3 al producto' % a)n m"s' si seanali*an los resultados' tambi1n al proceso de desarrollo utili*ado! Podr$a decirse ue un soft>are no tiene calidad por ejemplo cuando el sistema se cancelainesperadamente' no cumple las funcionalidades reueridas por los usuarios' implementa dic+asfuncionalidades en forma incorrecta' sus respuestas son lentas' es dif$cil de utili*ar 2no es ami(able3' permite cometer errores' es dif$cil entender el códi(o fuente' sólo uien lo constru%ó puedemodificarlo' es m"s complejo de lo necesario' no se sabe bien cómo probarlo' entre otros! 4a calidad es un resultado del esfuer*o +ec+o durante todo el desarrollo' aumentar lacantidad de las pruebas no aumenta necesariamente la calidad del sistema soft>are! Testin( es una de las barreras para evitar ue productos soft>are de baja calidad lle(uen aclientes! En un códi(o ue estamos probando se pueden encontrar errores ue causan defectos' loscuales muestran fallas!

Falla +fail$re, Es una diferencia entre los resultados 2comportamientos3 reales % los esperados! Se da por ejemplo cuando un pro(rama no se comporta como se esperaba ue lo +iciera! Puede ser interna o e$terna!

Una falla interna aparece antes de liberar el producto al cliente 2consid1rese au$el concepto de cliente e#terno % cliente interno3!

Una falla e#terna aparece lue(o de entre(ar el producto al cliente 2e#terno ointerno3!

4as fallas aparecen a partir de los casos de prueba! 4as fallas pueden ser:

Catastróficas: no se lo(ra la salida esperada porue el soft>are se cancela sin producirla o sin +aberla completado!

%uncional : los valores obtenidos como resultado difieren de los esperados! &ropiedad : +ace referencia al incumplimiento de una propiedad ue se +ab$a

definido como importante' por ejemplo' un tiempo de respuesta ma%or al definidoes una falla de propiedad de desempe&o!

%ormato: la salida puede mostrar los resultados esperados' pero la forma de la

misma no es correcta! 4a tipificación de la falla siempre se +ace en la ma%or cate(or$a ue esta pueda alcan*ar' por ejemplo' si la falla es de propiedad % funcional 2tal es el caso de un conjunto de datos ue seobtienen en un tiempo ma%or al esperado % con datos erróneos3' la misma ser" catalo(ada como

5@


28/58

funcional 2%a ue un conjunto de datos erróneos puede obtenerse a la velocidad ue se desea % a)nas$ la falla no se +abr" solucionado3! A pesar de esto la falla debe describirse completamente!

Defeto +fa$lt, Se presenta en el códi(o % puede mostrar o causar una falla! Si el sistema no falla no +a% defectos! Un defecto ocasiona de !!n fallas!

Error +"istae,

Es cualuier euivocación +umana en un sistema soft>are ue (enera defectoLs! El mismoser" encontrado por el desarrollador

2.3. Tipos de prueba Para encarar el proceso de pruebas de cada componente' subsistema o sistema es necesariodeterminar la estrate(ia ue +a de aplicarse! Se presenta a continuación dos maneras de focali*ar el an"lisis del soft>are en busca dedefectos de construcción!

&rue"as ti$o ca#a ne6ra Una forma de e#aminar el funcionamiento de un pro(rama consiste en tomar solamente losdatos de entrada % salida obtenidos con los primeros! 4a persona ue efect)a la prueba considera el pro(rama como una caja ne(ra' es decir' se

desentiende completamente del comportamiento % estructura internos! Su inter1s se diri(e )nicamente a encontrar circunstancias en las cuales el pro(rama no secomporta de acuerdo con sus especificaciones' es decir sin aprovec+ar el conocimiento de laestructura interna del pro(rama! Si el objetivo es +allar todos los errores en un pro(rama' el criterio ser" probar la entradade datos e#+austivamente! Esto implica emplear toda posible condición de entrada como un caso de prueba!

&rue"as ti$o ca#a "lanca 4as pruebas de caja blanca o ló(icas' permiten e#aminar la estructura interna de los pro(ramas!

Us"ndola el operador de la prueba obtiene datos de prueba a partir del e#amen de la ló(icadel pro(rama! Una prueba e#+austiva de secuencia no (aranti*a de nin(una manera ue el pro(ramacumpla con su especificación! Por ejemplo' si se pide +acer una rutina para ordenar valoresnum1ricos en orden creciente % en forma inadvertida se escribe la rutina para trabajar en formadecreciente' entonces una prueba e#+austiva de secuencia podr" ser de mu% escasa a%uda paradescubrir el error! Un pro(rama puede ser incorrecto por causa de secuencias faltantes! Por supuesto' una prueba e#+austiva de secuencias no detectar" la falta de secuencias ló(icas necesarias! Una prueba de este tipo podr" no detectar errores de sensitividad de los datos! E#isten muc+os ejemplos de estos errores' pero bastar" con presentar uno simple! Supon(a ue en un pro(rama se deben comparar dos n)meros para detectar una

conver(encia' es decir determinar si la diferencia entre los dos n)meros es menor ue un valor predeterminado!

Se podr$a escribir la sentencia en la forma si(uiente: Por supuesto' esta sentencia contiene un error porue deber$amos comparar EPSI49. conel valor absoluto de A= % no se lo detectar" necesariamente ejecutando cada secuencia ló(ica posible dentro del pro(rama! En conclusión' aunue la prueba e#+austiva de entrada 2caja ne(ra3 es superior a la pruebae#+austiva de secuencia 2caja blanca3' nin(una de ellas resulta ser una estrate(ia )til porue ambasson impracticables! E#isten' sin embar(o' modos de combinar elementos de ambos m1todos paralle(ar a una estrate(ia ra*onable' aunue no sea perfecta! Esto es lo ue esperamos aportar con elcontenido metodoló(ico planteado en esta unidad!

/!8! Eta$as de &rue"a

4as pruebas se aplican con distintos niveles de esfuer*o % enfoues en el ciclo de vida dedesarrollo del soft>are!

5B


29/58

Es mu% importante tener un enfoue adecuado en cada un de los momentos del pro%ecto!&rue"as de desarrollo

4as pruebas de desarrollo se focali*a sobre los aspectos de test m"s apropiados para serencarados por los propios desarrolladores del pro%ecto! En contraste' las pruebas de sistemamencionadas m"s adelante' pueden ser encaradas por un (rupo independiente de pruebas! Tradicionalmente' las pruebas de desarrollo +an sido concebidas como pruebas de unidadcon foco ocasional en aspectos de inte(ración e infrecuentemente otros aspectos de prueba! Se(uircon este criterio tradicional presenta ries(os en la calidad del soft>are! A menudo aspectos uecorresponden a los l$mites de esta cate(ori*ación son i(norados! En particular las pruebas dedesarrollo +an sido tratadas en la unidad 6 en el flujo de trabajo implementación! 4a mejor estrate(ia es dividir el esfuer*o de trabajo de pruebas a los fines de tener ciertasuperposición natural cu%a ma(nitud depende de cada pro%ecto en particular! 4o ue resultainsosla%able % recomendable siempre es ue tanto los desarrolladores como el (rupo independientede pruebas del sistema compartan una misma visión de calidad!

&rue"as de unidad

4as pruebas de unidad de una iteración se enfocan en la verificación de los m"s peue&oselementos del soft>are! Se aplica a componentes del modelo de implementación para comprobarue el flujo de control % de datos esperados +an sido contemplados % funcionan como se espera!

Estas e#pectativas se basan en como el componente participa en la ejecución de un caso de uso!/ecuerde ue tanto los dia(ramas de secuencia como los de colaboración' construidos a partir de loscasos de uso permiten visuali*ar el desempe&o 2colaboración3 de cada componente! 4os detalles delas pruebas de unidad son abordados en el flujo de trabajo Implementación!

&rue"as de inte6ración

4as pruebas de inte(ración son +ec+as para ase(urar ue los componentes del -odelo deImplementación funcionan armónicamente cuando son combinados para ejecutar un caso de uso! Elalcance de la prueba es t$picamente un pauete o un (rupo de pauetes del modelo deimplementación! Estos pauetes podr$an ori(inarse en distintos (rupos de desarrollo! 4as pruebas deinte(ración e#ponen las omisiones o errores de especificación de sus respectivas interfaces !

&rue"as de sistema 4as pruebas de sistema indican los aspectos del esfuer*o de prueba a ser abordados preferentemente por un (rupo independiente de desarrollo ue no participó en la implementación delcódi(o! .ormalmente estas pruebas son reali*adas cuando el sistema %a funciona como un todo! Elciclo de vida iterativo permite ue estas pruebas se desarrollen tan pronto como sea posible con unconjunto estabili*ado de casos de usos!

&rue"as de ace$tación

4as pruebas de aceptación son la prueba final ue antecede a la entre(a del soft>are! Elobjetivo au$ es verificar ue el soft>are est" listo % puede ser utili*ado por los usuarios finales en eldesarrollo de esas funciones % tareas para las ue el fue construido! 8abitualmente las pruebas de aceptación adoptan al(una de estas tres modalidades:

Aceptación formal! Aceptación informal o test alfa! Aceptación beta o test beta! 4a elección de la estrate(ia +abitualmente obedece a los reuerimientos contractuales' eldominio de la aplicación % los estandares or(ani*acionales!

Ace$tación formal

4a prueba de aceptación formal es un proceso cuidadosamente administrado! 4os tests son planeados % dise&ados con el mismo nivel de detalle ue las pruebas del sistema! 4os casos de prueba ele(idos deben ser un subconjunto de los utili*ados para la prueba delsistema! Es importante no desviarse de nin(una manera de los casos de prueba ele(idos' % la presencia indispensable' en este caso' de los usuarios finales! 4as actividades % artefactos producidosen la prueba de aceptación formal son los mismos ue se emplearon en la prueba del sistema! 4os beneficios de este tipo de pruebas de aceptación son:

4as funciones % caracter$sticas a ser probadas son conocidas! 4os detalles de las pruebas son conocidos % pueden ser medidos!

5


30/58

4os tests pueden ser automati*ados! El pro(reso de la prueba puede ser medido % monitoreado! El criterio de aceptación es conocido!

4as desventajas: /euiere importante cantidad de recursos % planeamiento! 4a prueba se puede convertir en una re implementación de la prueba del sistema!

Podr$a no descubrir defectos subjetivos del soft>are' %a ue solo se buscandefectos esperados!Ace$tación informal

En las pruebas de aceptación informal los procedimientos de test no son tan ri(urosamentedefinidos como en las pruebas de aceptación formal! 4as funciones % aspectos de ne(ocio a serevaluadas se identifican % documentan pero no tienen los casos de prueba particular a se(uir comoen el caso anterior! Kuien est" probando determina no solo ue +acer sino tambi1n la aprobacióncuando se encuentra satisfec+o! 4os beneficios de esta forma de prueba de aceptación son:

las funciones % caracter$sticas a ser probadas son conocidas! El pro(reso de la prueba puede ser medido % monitoreado! El criterio de aceptación es conocido! Podr$a descubrir defectos subjetivos del soft>are' %a ue la elección de los casos

de prueba es aleatorio % podr"n aparecer defectos no esperados! 4as desventajas

se reuieren recursos' planeamiento % administración! .o se tiene control sobre los casos de prueba a ser utili*ados! 4os usuarios finales podr$an dar su conformidad sin detectar defectos! 4os usuarios finales tienden a focali*arse en la comparación del nuevo sistema con

uno anterior perdiendo prioridad la b)sueda de defectos!Ace$tación


31/58

los desarrolladores implementan los componentes % stubs necesarios para dar la ma%orautomati*ación posible al proceso!

Todo esto se +ace para cada construcción entre(ada como resultado del flujo de trabajo deimplementación! Finalmente' con estos casos' procedimientos % componentes de prueba como entrada' losin(enieros de pruebas de inte(ración % de sistema eval)an cada construcción % detectan

cualuier defecto ue encuentren en ellos! 4as fallas sirven como realimentación tanto para otros flujos de trabajo' como el de dise&o% el de implementación' como para los in(enieros de pruebas a fin de ue lleven a cabo unaevaluación sistem"tica de los resultados de las pruebas!

7!-! &lanificar $rue"as

Au$ se produce la planificación (eneral del proceso de pruebas! Se especificanestimaciones de los reuerimientos de recursos +umanos % sistema necesarios' as$ como ladeterminación de una estrate(ia adecuada!

El propósito principal de este flujo es: Identificar los objetivos % entre(ables del esfuer*o de pruebas!

Identificar una buena estrate(ia de utili*ación de recursos! Definir los l$mites % alcances del proceso! Delinear el m1todo ue ser" usado! Definir el modo % criterio con el ue el proceso ser" se(uido % evaluado!

6,


32/58

Cuando preparan el plan de prueba los in(enieros de prueba se mueven sobre un ran(o devalores de entrada! El modelo de casos de uso % los reuisitos adicionales a%udan a decidirse por untipo adecuado de pruebas % a estimar el esfuer*o necesario para llevarlas a cabo! El dise&ador de pruebas usar" tambi1n otros artefactos de entrada' como por ejemplo elmodelo de dise&o! 4os dise&adores de pruebas desarrollan una estrate(ia de prueba para la iteración' es decir'deciden ue' % cuando ejecutar los tipos de prueba % determinar si el esfuer*o de prueba tiene 1#ito!En el si(uiente ejemplo se define una estrate(ia de prueba de sistema para una )ltima iteración en lafase de elaboración! Al menos el @; por ciento de las pruebas deber" estar automati*ado! El resto podr" sermanual! Cada caso de uso ser" probado para su flujo normal % para tres flujos alternativos! Criterio de 1#ito: por ciento de los casos de prueba pasados con 1#ito! .o +abr" nin()n defecto de prioridad medio=alta sin resolver El desarrollo' reali*ación % evaluación de cada caso procedimiento % componente de prueba lleva al()n tiempo % cuesta dinero! Sin embar(o' nin()n sistema puede ser probadocompletamente' por tanto' deber$amos identificar los casos' procedimientos % componentes de prueba con un ma%or retorno a la inversión en t1rminos de mejora de calidad! El principio (eneral

consiste en desarrollar casos % procedimientos de prueba con un solapamiento m$nimo para evaluarlos casos de uso m"s importantes % tambi1n los reuisitos ue est"n asociados a los ries(os m"saltos!

7!/! +ise)ar $rue"a

4os propósitos de dise&ar las pruebas son: Identificar % describir los casos de prueba para cada construcción! Identificar % estructurar los procedimientos de prueba especificado cómo reali*ar

los casos de prueba!+ise)o de los casos de $rue"a de inte6ración

4os casos de prueba de inte(ración se utili*an para verificar ue los componentesinteraccionan entre s$ de la forma apropiada despu1s de +aber sido inte(rados en una construcción!

4a ma%or$a de los casos de prueba de inte(ración pueden ser derivados de lasreali*aciones de casos de uso=dise&o' %a ue las reali*aciones de casos de uso describen cómointeraccionan las clases % los objetos' % por tanto cómo se relacionan tambi1n los componentes entres$!

65


33/58

4os in(enieros de pruebas deben crear un conjunto de caso de prueba ue +iciera posiblealcan*ar los objetivos establecidos en el plano de prueba con un esfuer*o m$nimo! Para esto' losdise&adores de prueba intentan encontrar un conjunto de caso de prueba con un solapamientom$nimo' cada uno de los cuales procura un camino o escenario interesante a trav1s de unareali*ación de caso de uso!

+ise)o de los casos de $rue"a del sistema

4as pruebas de sistemas se usan para verificar ue el sistema funciona correctamente como

un todo! Cada prueba de sistema prueba principalmente combinaciones de caso de uso instanciados bajo condiciones diferentes! Estas condiciones inclu%en diferentes:

confi(uraciones +ard>are 2procesadores' memoria principal' disco duro' etc!3'diferentes niveles de car(a del sistema' diferentes n)meros de actores % diferentestama&os de la base de datos!

Cuando se desarrollan los casos de prueba de sistema los dise&adores de prueba deber$andar prioridad a las combinaciones de los casos de uso ue:

se necesitan ue funcionar en paralelo! Posiblemente funcionen en paralelo! Probablemente se influencian mutuamente si se ejecutan en paralelo! Involucran varios procesadores!

Usan frecuentemente recursos del sistema' como procesos' procesadores' bases dedatos % soft>are de comunicaciones' ui*"s en formas complejas e impredecibles!

Pueden encontrarse' por lo tanto' muc+os casos de prueba de sistema considerando loscasos de uso' especialmente considerando sus flujos de eventos % sus reuisitos esenciales' como losreuisitos de rendimiento!

+ise)o de los casos de $rue"a de re6resión

Al(unos casos de prueba de construcciones anteriores se adoptan para pruebas de re(resiónen construcciones subsi(uientes' aunue no todos son adecuados! Para ser adecuados % contribuir a la calidad del sistema deben ser suficientemente fle#ibles% ser resistentes a cambios en el soft>are ue est" siendo probado! 4a fle#ibilidad reuerida en un caso de prueba de re(resión puede suponer un esfuer*o de

desarrollo e#tra' lo ue si(nifica tener cuidado % convertirlos en caso de prueba de re(resión)nicamente cuando el esfuer*o mere*ca la pena!Identificación y estructuración de los $rocedimientos de $rue"a

4os dise&adores pueden trabajar cada caso de prueba % su(erir procedimientos decomprobación para cada uno! Intentamos emplear procedimientos de prueba e#istentes tanto comosea posible' lo ue si(nifica ue podemos necesitar modificarlos de forma ue se utilicen paraespecificar cómo reali*ar un caso de prueba nuevo o cambiado! Adem"s estos profesionales tambi1n intentan crear procedimientos de prueba ue puedanser reutili*ados en varios casos de prueba! Esto les permite usar un conjunto reducido de procedimientos de prueba con rapide* % precisión para muc+os casos de prueba! En el si(uiente se muestra un ejemplo de procedimiento de prueba! "l subsistema de servicios Cuentas proporciona funcionalidad para mover dinero entre

cuentas "sta funcionalidad est' involucrada en varias reali(aciones de casos de uso como las de &agar %acturas y *ransferencias entre Cuentas +n procedimiento de prueba llamado ,erificar

*ransferencia entre Cuentas especificar' cómo probar el movimiento de dinero entre cuentas por lo

cual toma como par'metros de entrada dos identidades de cuentas y una cantidad a transferir y

valida la transferencia preguntando por el saldo de las dos cuentas involucradas antes y después de

transferir -os diseñadores de prueba crean . casos de prueba para el caso de uso &agar %actura y

/0 casos de uso para el caso de uso *ransferencia entre Cuentas "l procedimiento de prueba

,erificar *ransferencia entre Cuentas especifica cómo se reali(an parte de todos esos casos de

prueba

7!7! Im$lementar $rue"a

El propósito de la implementación de las pruebas es automati*ar los procedimientos de

prueba creando componentes de prueba si eso es posible' pues no todos los procedimientos puedenser automati*ados! 4os componentes de prueba se crean usando los procedimientos de prueba como entrada:

66


34/58

cuando usamos una +erramienta de automati*ación de pruebas reali*amos oespecificamos las acciones como se describen el los procedimientos de prueba!Estas cciones son entonces (rabadas dando como salida un componente de pruebaH por ejemplo' (enerando un script de prueba en 0isual asic!

Cuando pro(ramamos los componentes de prueba e#pl$citamente usamos los procedimientos de prueba como especificaciones iniciales! 9bserve ue dic+oesfuer*o de pro(ramación podr$a reuerir personal con buenas +abilidades

pro(ramadoras! 4os componentes de prueba emplean a menudo (randes cantidades de datos de entrada para ser probados % producen tambi1n muc+$simos datos de salida como resultado de las pruebas! Es)til visuali*arlos de forma clara e intuitiva de manera ue puedan especificarse correctamente % losresultados de las pruebas sean interpretados! Utili*amos para ellos +ojas de c"lculo % bases de datos!

7!8! Realizar $rue"as de inte6ración

En esta actividad se elaboran las pruebas de inte(ración necesarias para cada una de lasconstrucciones creadas en una iteración % se recopilan los resultados de las pruebas! 4as pruebas de inte(ración se llevan a cabo en los si(uientes pasos:

reali*ar las pruebas de inte(ración relevantes a la construcción llevan a cabo los

procedimientos de prueba manualmente para cada caso de prueba o ejecutandocualuier componente de prueba ue automatice los procedimientos de prueba! Comprobar los resultados de las pruebas con los resultados esperados e investi(ar

los resultados de las pruebas ue no coinciden con los esperados! Comunicar de los defectos a los in(enieros de componentes responsable de los

componentes ue se cree contiene lo fallos! Informar de los defectos a los dise&adores de prueba' uienes usar"n los defectos

para evaluar los resultados del esfuer*o de prueba!7!9! Realizar $rue"a de sistema

El propósito de la prueba de sistema es reali*ar las pruebas de sistema necesarias en cadaiteración % recopilar los resultados de las pruebas! 4a prueba de sistema puede empe*ar cuando las pruebas de inte(ración indican ue se +analcan*ado los objetivos de calidad de inte(ración fijados en el plan de prueba de la iteración actualH por ejemplo' el ; por ciento de los casos de prueba de inte(ración se ejecutan con el resultadoesperado! 4a prueba de sistema se elabora de forma an"lo(a a la forma en ue se reali*a la prueba deinte(ración!

7!:! E0aluar $ru

Resumen Informatica IV

Documents

Transcript of Resumen Informatica IV