UNIVERSIDAD TCNICA DE MANAB

FACULTAD DE CIENCIAS INFORMTICAS

CARRERA DE INGENIERA EN SISTEMAS
INFORMTICOS
CUARTO NIVEL
A

TEMA:
ARQUITECTURA, IMPLEMENTACIN Y PRUEBAS

AUTORES:

BRAVO MENNDEZ CARLOS FABRICIO.

MARCILLO MIELES MARCELO FABIN.
RAMREZ MIELES RAMN ALFREDO.
RUIZ LAVA DANILO XAVIER.
PALMA ZAMBRANO JORGE VICENTE.
ZAMBRANO MACAS GABRIEL MOISS.

DOCENTE:
ING. PATRICIO LOOR.

SEMESTRE:
MAYO SEPTIEMBRE 2015
PORTOVIEJO - MANABI ECUADOR

Arquitectura, implementacin y pruebas

Usted no hace el progreso por mantenerse al margen, lloriqueando y quejndose. Usted hace el
progreso mediante la implementacin de ideas. Shirley Hufstedler
Aunque se trata de un libro sobre arquitectura de software se dio cuenta de que por ahora, sin duda,
tenemos que recordar de vez en cuando que la arquitectura no es un objetivo en s mismo, sino slo
el medio para un fin. Sistemas constructivos de la arquitectura es el final del juego, los sistemas que
tienen las cualidades necesarias para responder a las preocupaciones de sus grupos de inters. Este
captulo cubre dos reas crticas en el sistema de fomento de la implementacin y pruebas, desde
el punto de vista de la arquitectura. Cul es la relacin de la arquitectura con la aplicacin (y
viceversa)? Cul es la relacin de arquitectura de probar (y viceversa).
Arquitectura e Implementacin
Arquitectura est destinado a servir como modelo para la implementacin. La barra lateral potayto,
potahto. . . "Hace que el punto de que las arquitecturas e implementaciones se basan en diferentes
conjuntos de vocabulario, que se traduce en herramientas de desarrollo por lo general sirven a una
comunidad u otro bastante bien, pero no tanto. Con frecuencia los ejecutores son tan absorto en su
tarea inmediata en cuestin que hagan opciones de implementacin que degradan la estructura
modular de la Arquitectura,
Por ejemplo:
Esto lleva a una de las situaciones ms frustrantes para los arquitectos, es fcil para el cdigo y su
arquitectura destinada a separarse; esto a veces se llena de cdigo y la arquitectura consistente.
"erosin arquitectura". En esta seccin se habla de cuatro tcnicas para ayudar a mantener
La reproduccin del diseo en el Cdigo
Una tarea clave para los ejecutores es ejecutar fielmente las prescripciones de la arquitectura.
George Fairbanks, en Just Enough Arquitecture, prescribe el uso de un "estilo arquitectnico
evidente codificacin." A lo largo del cdigo, los ejecutores pueden documentar el concepto
arquitectnico o gua que est cosificar. Es decir, pueden "encajar" la arquitectura en sus
implementaciones. Tambin pueden tratar de locales-ize la aplicacin de cada elemento
arquitectnico, en oposicin a la dispersin que a travs de diferentes entidades de
implementacin. Esta prctica se hace ms fcil si los ejecutores (consistentemente a travs de un
proyecto) adoptan un conjunto de convenciones de cmo los conceptos arquitectnicos "aparecen"
en el cdigo. Por ejemplo, la identificacin de la capa a la que una unidad de cdigo pertenece har
que sea ms probable que los ejecutores y mantenedores respetarn (y por lo tanto no viola) la
estratificacin.
Frameworks
"Framework" es un trmino usado en exceso terriblemente, pero aqu nos referimos a un conjunto
reutilizable de bibliotecas o clases de un sistema de software. "Biblioteca" y "clase" son trminos
similares a IMPLEMENTA-CIN, pero los Frameworks tienen implicaciones que arquitectnicos
amplios son un lugar donde la arquitectura y la aplicacin se encuentran. Las clases (en un
framework orientado a objetos) son apropiadas para el dominio de la aplicacin del sistema que se

est construyendo. Los Framework pueden variar desde pequeas y sencillas (como los que
proporcionan un conjunto de tipos de datos estndar y de uso comn a un sistema) a grande y
sofisticado. Por ejemplo, el Architecture Automotive Open System (AUTOSAR) es un Framework
para el software de automocin, desarrollado en conjunto por los fabricantes de automviles,
proveedores y desarrolladores de herramientas. Framewor de que son grandes y sofisticado a
menudo codifican arquitectnicos mecanismos en-interaccin, mediante la codificacin de cmo
las clases (y los objetos derivados de ellos) se comunican y sincronizan entre s Por ejemplo,
AUTOSAR es una arquitectura y no (solo) un marco de arquitectura. Un marco equivale a una (en
algunos casos, enorme) pieza sustancial de software reutilizable, y que trae consigo todas las
ventajas de la reutilizacin: ahorro de tiempo y costo, evitando una tarea de diseo costosa, el
conocimiento del dominio de codificacin, disminuyendo la posibilidad de errores de
implementadores individuales de codificacin lo mismo de manera diferente y errneamente.
Por otro lado, los framework para disear y obtener la correcta. La adopcin de un framework
significa invertir en una seleccin pro-ceso, as como la formacin y el framework no puede
proporcionar toda la funcionalidad que usted requiere. La curva de aprendizaje de un framework es
a menudo extremadamente empinada. Un framework que proporciona un conjunto completo de
funcionalidades para la implementacin de una aplicacin en un dominio particular se llama una
"plataforma".
Plantillas de cdigo
Una plantilla proporciona una estructura dentro de la cual se logra alguna func-cionalidad
arquitectura especfica, en un amplio sistema de forma consistente. Muchos generadores de cdigo,
tales como constructores de interfaz de usuario, producen una plantilla en la que un desarrollador
inserta cdigo, aunque plantillas tambin pueden ser proporcionados por el entorno de desarrollo.
Supongamos que una arquitectura para un sistema de alta disponibilidad prescribe que cada
componente que implementa una responsabilidad crtica debe utilizar una tcnica de conmutacin
por error que cambia el control a una copia de seguridad del mismo en caso de un fallo se-protegidas
revocado de su funcionamiento. La arquitectura poda, y sin duda sera, describir el protocolo de
conmutacin por error. Podra ser algo como esto:
En el caso de que se detecte un fallo en un componente de aplicacin crtica, se produce una
conmutacin de la siguiente manera:
1. Una copia secundaria, la ejecucin en paralelo en el fondo en un pro-procesador diferente, es
promovido a la nueva primaria.
2. La nueva primaria reconstituye con los clientes de la aplicacin mediante el envo de un mensaje
que significa, en esencia: La unidad operativa que serva ha tenido un fracaso. Estabas esperando
nada de nosotros en el momento? Se procede entonces a atender todas las solicitudes recibidas en
respuesta.
3. Una nueva secundaria se inicia para servir como una copia de seguridad para el nuevo primario.
4. Las propias anuncia secundarias recin iniciadas a la nueva primaria, que comienza el envo de
mensajes que en su caso para mantenerlo al da mientras se est ejecutando en segundo plano.

Si se detecta un fallo en un secundario, uno nuevo se inicia en algn otro procesador. Coordina con
su primaria y comienza a recibir datos de estado.
A pesar de que las copias de primaria y secundaria no estn haciendo lo mismo al mismo tiempo (el
primario est realizando su deber y el envo de estado de arriba-fechas a sus copias de seguridad, y
los secundarios estn esperando para entrar en accin y aceptar actualizaciones estatales), ambos
componentes provienen de copias idnticas del mismo cdigo fuente.
Para lograr esto, los codificadores de cada componente crtico seran ex esperadas para
implementar dicho protocolo. Sin embargo, una forma ms inteligente es dar al codificador una
plantilla de cdigo que contiene la parte de conmutacin por error complicado como repetitivo y
contiene complete las secciones en blanco donde los programadores pueden llenar en la aplicacin
para la funcionalidad, que es nica para cada aplicacin.
Esta plantilla puede estar integrada en el entorno de desarrollo de manera que cuando el
desarrollador especifica que el modulo se est desarrollando es el apoyo a un protocolo de
conmutacin por error, la plantilla aparece como THT cdigo inicial para el mdulo. Un ejemplo de
una plantilla tal, tomado de un sistema de control de trfico areo se ilustra en la figura 19.1. La
estructura es un bucle continuo que los servicios en los prximos eventos. Si el evento es el que
hace que la aplicacin para tomar una accin normal (no relacionada con la tolerancia a fallos), lleva
a cabo la accin adecuada, seguido de una actualizacin de los datos de sus contrapartes de copia
de seguridad "para que la contraparte puede asumir el control si es necesario. La mayora de las
aplicaciones pasan la mayor parte de su tiempo de procesamiento de eventos normales. Otros
eventos que puedan recibirse implican la transferencia (transmisin y recepcin) de las
actualizaciones de estado y de datos. Por ltimo, hay un conjunto de eventos que involucra tanto el
anuncio de que esta unidad se ha convertido en el principal y solicitudes de los clientes por los
servicios que el anterior (ahora no) primaria no se ha completado.
Utilizando una plantilla tiene implicaciones arquitectnicas: hace que sea fcil de aadir nuevas
aplicaciones al sistema con un mnimo de preocupacin por los de trabajo reales de los mecanismos
de tolerancia a fallos diseados en el enfoque.
Los codificadores y mantenedores de las aplicaciones no necesitan saber acerca de Mecanismos de
tratamiento de mensajes-excepto en abstracto, y que no es necesario para asegurarse de que sus
aplicaciones son tolerantes a errores que se ha manejado arquitectnicamente.
Plantillas de cdigo tienen implicaciones para la fiabilidad: una vez que la plantilla es depurado,
clases luego enteras de errores de codificacin a travs de todo el sistema de desaparecer. Pero en
el contexto de esta discusin, plantillas representan un verdadero terreno comn donde la
arquitectura y la implementacin se unen de una manera coherente y til.
Mantener Cdigo y Arquitectura Consistente
El cdigo puede alejarse de la arquitectura en un deprimente gran nmero de maneras. En primer
lugar, puede que no haya restricciones impuestas a los codificadores para seguir la arquitectura.
Esto no tiene sentido aparente, para qu bamos a molestar a invertir en una arquitectura si no
vamos a usarlo para restringir el cdigo? Sin embargo, esto sucede ms a menudo de lo que piensas.
En segundo lugar, algunos proyectos utilizan la arquitectura publicada para empezar, pero cuando

se encuentran problemas (ya sea tcnica o programacin relacionada), la arquitectura se abandona

y codificadores se apresuran a alinear el sistema de la mejor manera posible. En tercer lugar (y tal
vez ms comn), despus de que el sistema ha sido campo, cambios en l se llevan a cabo con slo
cambios de cdigo, pero estos cambios afectan a la arquitectura. Sin embargo, la arquitectura
publicada no est actualizado, fechado para guiar los cambios, ni actualiza despus de mantenerse
al da con ellos. Un mtodo simple para remediar la falta de actualizacin de la arquitectura es la de
no tratar la arquitectura publicado como un asunto de todo o nada es o todo correcto o todo intil.
Las partes de la maysecome arquitectura fuera de fecha, pero ser de gran ayuda si las partes estn
marcados como ya se aplica "o" para ser revisada. Marcado concienzudamente secciones como
fuera de fecha mantiene la documentacin arquitectura un documento vivo y (paradjicamente)
enva un mensaje ms fuerte sobre el resto: todava es correcta y todava se puede confiar.

FIGURA 19.1 :Una plantilla de cdigo para un protocolo de conmutacin por error. "Proceso"
"Proceso X" y, son marcadores de posicin para el cdigo especfico de la aplicacin.
Adems, la fuerte gestin y disciplina proceso ayudarn a prevenir la erosin. Una forma es el
mandato que los cambios en el sistema, no importa cuando se producen, son examinados a travs
de la arquitectura de primera. Las alternativas para lograr la alineacin de Cdigo con la arquitectura
incluyen los siguientes:
Sincronizacin en hito del ciclo de vida. Desarrolladores cambiar el cdigo hasta el final de alguna
fase, tal como una liberacin o al final de una iteracin. En ese momento, cuando la presin es
inferior horario, la arquitectura se actualiza.
Sincronizacin en crisis. Este enfoque no deseado sucede cuando un proyecto se ha encontrado
en un atolladero tcnico y necesita orientacin arquitectnica de conseguir en s ir de nuevo.
Sincronizar el momento del check-in. Reglas para la arquitectura se codifican y se utilizan para
investigar a cualquier registro de entrada. Cuando un cambio en el cdigo "rompe" las reglas de la
arquitectura, las partes interesadas clave del proyecto son informados y luego o bien el cdigo o las
reglas arquitectura deben ser modificados. Este proceso est normalmente automatizado por
herramientas. Estas alternativas pueden funcionar slo si la implementacin sigue el arquitectura
sobre todo, partiendo de que slo aqu y all y en pequeas cosas. Es decir, funciona al sincronizar
la arquitectura implica una actualizacin y no una revisin al por mayor o hacer en off.
Potayto, Potahto, Tomayto, Tomahto Let's Call the Whole Thing Off!
Una de las realidades ms acuciantes sobre el software de-desarrollo basado en la arquitectura es
el abismo entre ontolo-logas arquitectnicas y de ejecucin, el conjunto de conceptos y trminos
propios de un rea. Pregunte a un arquitecto de qu conceptos se trabaja con todo el da, y es muy
probable que or cosas como mdulos, componentes, conectores, partes interesadas, evaluacin,
anlisis, documentacin, visitas, modelado, atributos de calidad, los objetivos de negocio, y hojas
de ruta tecnolgicas. Pregunte a un implementador la misma pregunta, y es probable que no se oye
ninguna de esas palabras. En su lugar se escucha acerca de los objetos, mtodos, algoritmos,
estructuras de datos, variables, depuracin, comentarios de cdigo declaraciones, compiladores,
genricos, la sobrecarga de operadores, punteros, y construir scripts. Esta es una brecha en un
lenguaje que refleja una brecha en los conceptos. Esta brecha es, a su vez, que se refleja en los
idiomas de las herramientas que utiliza cada comunidad. UML comenz como una manera de
modelar diseos orientados a objetos que podran ser convertidos rpidamente al cdigo que es,
UML es conceptualmente "cerca" de cdigo. Hoy en da es un hecho la arquitectura lenguaje de
descripcin de, y probablemente el ms popular. Pero tiene hay construida en concepto para el ms
ubicuo de los conceptos arquitectnicos, la capa. Si usted quiere representar capas en UML, usted
tiene que adoptar una convencin para hacerlo. Paquetes estereotipados como capa, asociado a
estereotipada << permitido utilizar dependencias hacen el truco. Pero es un truco, una solucin
para una deficiencia idioma.
Cul es la relacin entre la arquitectura y las pruebas? Una posible respuesta es "Ninguno", o "No
mucho." La prueba puede ser visto como el proceso de asegurarse de que un sistema de software
cumple sus requisitos, que trae la funcionalidad necesaria (dotado con los atributos de calidad
necesarias) para su comunidad de usuarios. Pruebas, visto de esta manera, se conecta simplemente

a los requisitos, y apenas conectado a arquitectura en absoluto. Mientras que el sistema funciona
como se espera, a quin le importa lo que el arquitectura es? S, la arquitectura jug el papel
principal en conseguir que el sistema funcione como se esperaba, muchas gracias, pero una vez que
ha desempeado ese papel que debe hacer una salida elegante fuera del escenario. Probadores
trabajan con los requisitos: pero vamos a tomar desde aqu. No es sorprendente que no nos gusta
esa respuesta. Esta es una vista empobrecida de pruebas, y de hecho un poco realista uno as. Como
veremos, la arquitectura no puede dejar de jugar un papel importante en las pruebas. Ms all de
eso, sin embargo, vamos a ver que la arquitectura puede ayudar a hacer la prueba menos costosa y
ms efectiva cuando se abrazaron en las actividades de prueba. Tambin veremos lo que los
arquitectos pueden hacer para ayudar a los probadores, y lo que los probadores pueden hacer para
aprovechar la arquitectura.
Niveles de Pruebas y cmo la arquitectura juega un papel en cada uno hay "niveles" de las pruebas,
que van desde pruebas de pequeas piezas, individuales en el aislamiento de todo un sistema.
Las pruebas unitarias se refiere a las pruebas se ejecutan en software. Prueba de la unidad suele
ser una parte del trabajo de la aplicacin de esas piezas. De hecho, las pruebas unitarias son
tpicamente escritas por los propios desarrolladores. Cuando las pruebas se escriben be-tanto el
desarrollo de la unidad, esta prctica se conoce como desarrollo basado en pruebas. La certificacin
de que una unidad ha pasado sus pruebas de unidad es una condicin previa para la entrega de esa
unidad a las actividades de integracin. Las pruebas unitarias probar el software de manera
independiente, a menudo apoyndose en "trozos" TOPlay el papel de otras unidades con las que la
unidad probada interacta, como aquellas otras unidades no pueden estar disponibles. La unidad
no se suele detectar errores relativos a la interaccin entre los elementos que viene despus, pero
las pruebas de unidad proporcionan la confianza que cada uno de los bloques de construccin
pruebas del sistema est exhibiendo tanta exactitud cmo es posible por su cuenta. Una unidad
corresponde a un elemento arquitectnico en una de las vistas del mdulo de la arquitectura. En el
software orientado a objetos, una unidad podra corresponder a una clase. En un sistema de capas,
una unidad puede corresponder a una capa, o una parte de rbol de descomposicin una capa. Muy
a menudo una unidad corresponde a un elemento en la hoja de un mdulo que juega un papel
importante en las pruebas unitarias. En primer lugar, define las unidades: son elementos
arquitectnicos en uno o ms de los puntos de vista de los mdulos. En segundo lugar, define las
responsabilidades y requerimientos establecidos para cada unidad.
Requisitos modificabilidad tambin pueden ser probados en el tiempo de prueba de unidad. Por
cunto tiempo se tardar en hacer cambios especficos se pueden probar, aunque esto rara vez se
hace en la prctica. Si los cambios especificados toman demasiado tiempo para los desarrolladores
hacer, imagina cunto tiempo van a tomar cuando una nueva y separada grupo mantenimiento est
a cargo sin el conocimiento ntimo de los mdulos. Aunque las pruebas unitarias van ms all de la
arquitectura, no pueden empezar su trabajo sin la arquitectura.
Las pruebas de integracin a prueba lo que sucede cuando las unidades de software
independientes comienzan a trabajar juntos. Las pruebas de integracin se centran en la bsqueda
de problemas relacionados con las interfaces entre los elementos de un diseo. Las pruebas de
integracin es ntimamente conectado a los incrementos o subconjuntos especficos que se han
programado en el desarrollo de un sistema. El caso en el que est previsto un nico incremento, lo

que significa que la integracin de todo el sistema se producir en un solo paso, se llama "big bang
integracin" y en gran medida ha sido desacreditada en favor de la integracin de muchos
subconjuntos incrementalmente ms grandes. Integracin incremental hace localizar errores
mucho ms fcil, ya que cualquier nuevo error que aparece en un subconjunto integrado es
probable que vivan en cualquier nuevas piezas se han aadido en esta ocasin. Al final de las
pruebas de integracin, el proyecto cuenta con la confianza de que las piezas de trabajo de software
juntos correctamente y proporcionan al menos algunas funciones de todo el sistema correcto
(dependiendo de lo grande que se est integrando un subconjunto del sistema). Casos especiales
de pruebas de integracin son los siguientes:
Las pruebas del sistema, que es una prueba de todos los elementos del sistema, incluido el
software y el hardware en su entorno de trabajo
Las pruebas de integracin que involucra software de terceros Una vez ms, la arquitectura no
puede dejar de jugar un papel importante en las pruebas de integracin. En primer lugar, los
incrementos que estarn sujetos a las pruebas de integracin deben planearse, y este plan se basar
en la arquitectura. La vista usos es particularmente til para esto, ya que muestra los elementos que
deben estar presentes para que una determinada pieza de funcionalidad que se envi. Es decir, si el
proyecto requiere que (por ejemplo) en el siguiente incremento de las redes sociales los usuarios
del sistema podrn gestionar fotografas que han permitido que otros usuarios puedan publicar en
sus propios espacios miembros, el arquitecto puede informar de que esta nueva funcionalidad es
parte del mdulo de permisos de usuario, que utilizar una nueva parte del mdulo para compartir
fotos, que a su vez utilizar una nueva estructura en la base de datos de enlaces de usuario principal,
y as sucesivamente. La gestin de proyectos se sabe, pues, que todo el software debe estar listo
para su integracin al mismo tiempo. En segundo lugar, las interfaces entre elementos son parte de
la arquitectura, y las interfaces determinan las pruebas de integracin que se crean y ejecutan. Las
pruebas de integracin es que los requisitos de atributos de calidad de tiempo de ejecucin se
pueden probar.
Rendimiento y pruebas de fiabilidad se puede lograr. Un instrumento de prueba sofisticada es til
para realizar este tipo de pruebas. Cunto tiempo dura una sincronizacin de extremo a extremo
de una base de datos local con una base de datos global? Qu sucede si fallas se inyectan en el
sistema? Qu sucede cuando falla un proceso? Todas estas condiciones pueden ser probados en
el tiempo de integracin. Las pruebas de integracin es tambin el momento para poner a prueba
lo que sucede cuando el sistema se ejecuta durante un perodo prolongado. Usted podra supervisar
el uso de los recursos durante la prueba y buscar los recursos que se consumen, pero no liberados.
Tiene su grupo de conexiones de bases de datos gratuitas a disminuir con el tiempo? Entonces tal
vez conexiones de base de datos deben ser manejados de manera ms agresiva. Muestra el grupo
de subprocesos signos de degradacin en el tiempo? dem
Las pruebas de aceptacin es una especie de prueba del sistema que se realiza por los usuarios, a
menudo en el entorno en el que el sistema funcionar. Dos casos especiales de las pruebas de
aceptacin son alfa y beta prueba. En ambos, los usuarios se les da rienda suelta a utilizar el sistema
a su gusto, a diferencia de las pruebas que se produce bajo un rgimen planificada de antemano de
un conjunto especfico de pruebas. Pruebas alfa por lo general ocurre en la casa, mientras que las
pruebas beta hace que el sistema dispone de un conjunto selecto de usuarios finales en virtud de

un "Usuario tenga cuidado" condicin. Sistemas de prueba beta generalmente son bastante fiables,
despus de todo, el desarrollo de la organizacin est muy motivado para hacer una buena primera
impresin en el usuario de la comunidad, pero nosotros-res se les da la advertencia justa que el
sistema podra no estar libre de errores o (si " libre de errores "es demasiado alto un gol) por lo
menos no hasta el nivel de calidad previsto. Arquitectura juega un papel menos importante en las
pruebas de aceptacin que en los otros niveles. Pero todava importante. Las pruebas de aceptacin
implican destacando el comportamiento atributo de calidad del sistema ejecutndolo con cargas
muy pesadas, sometindolo a ataques de seguridad, privndolo de recursos en los momentos
crticos, y as sucesivamente. Una analoga cruda es que si quieres derribar una casa, se pueden
ballenas lejos en paredes aleatorias con un mazo, pero su tarea se llevar a cabo mucho ms
eficiente si usted consulta la arquitectura primero en encontrar cul de las paredes es la celebracin
del tejado. (El punto de prueba es, despus de todo, a "derribar la casa.") La superposicin de todos
estos tipos de pruebas son pruebas de regresin, que es la prueba de que se produce despus de
haber hecho un cambio en el sistema. El nombre proviene del deseo de descubrir errores antiguos
que podran resurgir despus de un cambio, una seal de que el software ha retrocedido a un estado
menos maduro. Las pruebas de regresin pueden ocurrir en cualquiera de los niveles antes
mencionados, ya menudo consiste en volver a ejecutar el banco de pruebas y la comprobacin de
la existencia de viejos (o para el caso, nuevos fallos).
Black-Box and White-Box Pruebas
Prueba (a cualquier nivel) puede ser "recuadro negro" o "caja blanca". Las pruebas de recuadro
negro trata el software como un opaco "recuadro negro", no utilizando ningn conocimiento sobre
el interior de diseo, estructura y aplicacin. La nica fuente tester's- de informacin sobre el
software es sus requisitos. Arquitectura juega un papel en las pruebas de recuadro negro, ya que a
menudo es el documento, donde se describen los requisitos para una pieza del sistema. Un
elemento de la arquitectura es poco probable que corresponden uno a uno con un re-requisito muy
bien capturado en un documento de requisitos. Por el contrario, cuando el arquitecto crea un
elemento arquitectnico, l o ella usualmente le asignan una amalgama de exigencias o requisitos
parciales, para llevar a cabo. Adems, la interfaz a un elemento tambin constituye un conjunto de
"requisitos" para que el elemento debe felizmente aceptar los parmetros especificados y producir
el efecto especificado como resultado. Probadores realizan las pruebas de recuadro negro en un
elemento arquitectnico (como un subsistema importante) es improbable que sean capaces de
hacer su trabajo utilizando nicos requisitos en un documento de requisitos. Necesitan la
arquitectura, as, porque la arquitectura ayudar al probador entender qu partes de los requisitos
relacionados con el subsistema especificado. Pruebas de caja blanca hace un uso completo de las
estructuras, algoritmos, y de control y de datos flujos internos de una unidad de software. Los
exmenes que se ejercen todas las rutas de control de una unidad de software son un ejemplo
primordial de pruebas de caja blanca. Blanco-caja de probacin es ms a menudo asociado con la
unidad de pruebas, pero tiene un papel en los niveles superiores tambin. En las pruebas de
integracin, por ejemplo, pruebas de caja blanca se puede utilizar para construir pruebas que
intentan sobrecargar la conexin entre dos componentes mediante la explotacin de conocimiento
acerca de cmo un componente (por ejemplo) gestiona mltiples interacciones simultneas. Las
pruebas de caja gris se encuentran, como era de esperar, entre lo interno y blanco. Tes-tros llegar a
hacer uso de algunos, pero no todos, de la estructura interna de un sistema. Por ejemplo, pueden

probar las interacciones entre los componentes pero no emplear pruebas basadas en el
conocimiento de las estructuras de datos internos de un componente. Hay ventajas y desventajas
de cada tipo de prueba. Las pruebas de recuadro negro no estn sesgada por un diseo o aplicacin,
y se centra en asegurar que se cumplen los requisitos. Pero puede ser ineficaz por (por ejemplo) que
se ejecuta muchas pruebas unitarias que una inspeccin de cdigo simple revelara ser innecesaria.
Pruebas de caja blanca a menudo claves en los errores crticos ms rpidamente, pero puede sufrir
de una prdida de perspectiva concentrando pruebas para hacer la ruptura de ejecucin, pero no
se concentra en el software de la entrega de la funcionalidad completa bajo todos los puntos en su
espacio de entrada.
Prueba basado en el riesgo
Ms alto, las pruebas se concentra el esfuerzo en las reas donde se percibe el riesgo de ser el, el
ms alto, tal vez debido a las tecnologas inmaduras, requisitos incertidumbre. Experiencia brechas
de desarrollo, y as sucesivamente. La arquitectura puede informar a la prueba basada en el riesgo,
contribuyendo categoras de riesgos a considerar. Los arquitectos pueden identificar reas en las
decisiones arquitectnicas (si mal) tendran un impacto generalizado.
Dnde interno de diseo, estructura y aplicacin. nica fuente del probador de informacin sobre
sobre el software es sus requisitos. RMA-arquitectura juega un papel en las pruebas de recuadro
negro, ya que a menudo es el documento arquitectura, donde se describen los requisitos para una
pieza del sistema. Un elemento de la arquitectura es poco probable que corresponden uno a uno
con un re-requisito muy bien capturado en un documento de requisitos. Por el contrario, cuando el
arquitecto crea un elemento arquitectnico, l o ella usualmente le asignan "una amalgama de
exigencias o requisitos parciales, para llevar a cabo. Adems, la interfaz a un elemento tambin
constituye un conjunto de "requisitos" para ella, el elemento debe felizmente aceptar los
parmetros especificados y producir el efecto especificado como resultado. Probadores realizan las
pruebas de recuadro negro en un elemento arquitectnico (como un subsistema importante) es
improbable que sean capaces de hacer su trabajo utilizando nicos requeridas pub en un
documento de requisitos. Necesitan la arquitectura, as, porque la arquitectura ayudar al probador
entender qu partes de los requisitos relacionados con el subsistema especificado. Pruebas de caja
blanca hace un uso completo de las estructuras, algoritmos, y de control y de datos flujos internos
de una unidad de software. Los exmenes que se ejercen todas las rutas de control de una unidad
de software son un ejemplo primordial de pruebas de caja blanca. Blanco-caja de probacin es ms
a menudo asociado con la unidad de pruebas, pero tiene un papel en los niveles superiores tambin.
En las pruebas de integracin, por ejemplo, pruebas de caja blanca se puede utilizar para construir
pruebas que intentan sobrecargar la conexin entre dos componentes mediante la explotacin de
conocimiento acerca de cmo un componente (por ejemplo) gestiona mltiples interacciones
simultneas. Las pruebas de caja gris se encuentran, como era de esperar, entre el blanco y negro.
Tes-tros llegar a hacer uso de algunos, pero no todos, de la estructura interna de un sistema. Por
ejemplo, pueden probar las interacciones entre los componentes pero no emplear pruebas basadas
en el conocimiento de las estructuras de datos internos de un componente. Hay ventajas y
desventajas de cada tipo de prueba. Las pruebas de recuadro negro no est sesgada por un diseo
o aplicacin, y se centra en asegurar que se cumplen los requisitos. Pero puede ser ineficaz por (por
ejemplo) que se ejecuta muchas pruebas unitarias que una inspeccin de cdigo simple revelara
ser innecesaria, Pruebas de caja blanca a menudo claves en los errores crticos ms rpidamente,

pero puede sufrir de una prdida de perspectiva al concentrar las pruebas para hacer la pausa
REALIZACIN, pero no se concentra en el software de la entrega de la funcionalidad completa bajo
todos los puntos en su espacio de entrada.
El arquitecto tambin puede dar una idea en cuanto a la complejidad o, si el software no existe an
, la complejidad esperada de cada una de las unidades de software . El arquitecto tambin puede
sugerir tecnologas de pruebas tiles que sern compatibles con la arquitectura; por ejemplo, la
capacidad de Java para respaldar la constatacin en el cdigo puede aumentar drsticamente la
capacidad de prueba de software, y el arquitecto puede proporcionar argumentos a favor o en
contra de la adopcin de esa tecnologa. Para el desarrollo de la prueba, el arquitectura puede hacer
que sea fcil de intercambiar datos dentro y fuera del sistema. Por ltimo, los informes de ensayo y
anlisis de defectos suelen ser reportados en trminos arquitectnicos: este elemento pasa todas
sus pruebas, pero ese elemento an tiene errores crticos que muestran . Esta capa pas la prueba
de la entrega, pero esa capa no lo hizo.
El papel del Arquitecto
Estas son algunas de las cosas que un arquitecto puede hacer para facilitar las pruebas de calidad.
Abeto y ante todo, el arquitecto puede disear el sistema para que se IHT? Primero altamente
comprobable. Es decir, el sistema debe ser diseado con la calidad de un tribute de la capacidad de
prueba en mente. Aplicando la regla de oro de la arquitectura ("Conozca sus grupos de inters"), el
arquitecto puede trabajar con el equipo de pruebas (y, en la medida en que tienen una participacin
en las pruebas, otras partes interesadas) para establecer lo que se necesita. Juntos, pueden llegar a
una definicin de los requisitos de capacidad de prueba utilizando escenarios como se describe en
el captulo 10. Los requisitos de capacidad de prueba tienen ms probabilidades de ser una
preocupacin de la organizacin y no tanto del cliente o usuarios, as que no esperes ver muchos
requisitos de prueba en un documento de requisitos. El uso de esos requisitos de prueba de
habilidad, las tcticas de la capacidad de prueba en el Captulo 10 pueden ser llevados a soportar
para proporcionar la capacidad de prueba necesaria. Adems de disear para la capacidad de
prueba, el arquitecto tambin puede hacer estas otras cosas para ayudar al esfuerzo de la prueba:
Asegurar que los evaluadores tienen acceso al cdigo fuente, documentos de diseo, y los
registros de cambio.
Dar a los probadores de la capacidad de controlar y restablecer todo el conjunto de datos que
almacena un programa en una base de datos persistente. Revertir la base de datos a un estado
conocido es esencial para la reproduccin de los insectos o la realizacin de pruebas de regresin.
Del mismo modo, un banco de pruebas en la base de datos de carga ing es til. Incluso los productos
que no utilizan data bases pueden beneficiarse de rutinas para precargar automticamente un
conjunto de datos de prueba. Una forma de lograr esto es disear una "capa de persistencia" de
modo que todo el programa es independiente base de datos. De esta manera, toda la base de datos
se pueden intercambiar para las pruebas, incluso utilizando una base de datos en memoria si se
desea.
Dar a los probadores de la capacidad de instalar varias versiones de un producto de software en
una sola mquina. Esto ayuda a los probadores comparan las versiones, el aislamiento cuando se
introdujo un error. En aplicaciones distribuidas, esto ayuda configuraciones de despliegue de
pruebas y la escalabilidad del producto. Esta capacidad podra exigir a los puertos y las disposiciones
de comunicacin-con configurable para evitar colisiones con los recursos tales como el registro.

En la prctica, el arquitecto no puede permitirse el lujo de ignorar el pro pruebas. Proceso porque
si , despus del parto, algo va muy mal , el arquitecto ser una de las primeras personas contratado
para diagnosticar el problema. En un caso, nos enteramos, esto implic volar a las remotas
montaas de Per para diagnosticar un problema con equipos de minera.