Diseo Estructurado

Generalidades
Estrategias de diseo:
o Botton-Up:
o Top-Down:
Niveles que componen el modelo
o Nivel de las Funcionalidades estndar
o Nivel de las Funcionalidades simples
o Nivel de las Funcionalidades compuestas
Sintaxis
o Elementos descriptivos de los Casos
o Componentes de los pasos
o Estructura de los pasos (Sintaxis)

Nombre Diseo Estructurado

Descripcin -

Versin 3.0
Generalidades
Para afrontar las innumerables complejidades que encierran los diferentes tipos de aplicativos del
cliente, la ingeniera de software recomienda realizar un diseo acorde a las necesidades del proyecto,
para nuestro caso el diseo se convierte en el mapa de la ruta que pretendemos cubrir.
Implementar la estrategia TOP-DOWN o la BOTTON-UP depende del criterio personal de cada analista.
Independiente de la estrategia siempre se busca dar la cobertura adecuada al proyecto y si en este
punto se identifican casos que no se incluyeron dentro del alcance inicial y que representan algn riesgo
para el proyecto, estos deben informarse al cliente para que juntos se analice la pertinencia de esta
adicin en el proyecto.
Estrategias de diseo:

Botton-Up:
 Es una estrategia que se apoya en un modelo jerrquico y cuyo principal objetivo es analizar primero los
elementos de ms bajo nivel y poder elevar el nivel de complejidad hasta lograr detallar el nivel de
complejidad superior, para nuestro modelo, la estrategia botton-Up consiste en :

Iniciar con el anlisis de los componentes tcnicos (denominado nivel estndar), para los cuales
analizamos y detallamos las caractersticas que por estndar de los lenguajes de programacin,
son propias de cada objeto independiente del entorno.
Luego continuamos por analizar y detallar las relaciones posibles que existe entre estos
elementos previamente identificados(denominado nivel bsico) dentro de un nico contenedor y
como estos se relacionan para generar mltiples caminos (Felices o infelices).
Finalmente analizamos y detallamos las mltiples combinaciones entre estos elementos
contenedores, en este punto podremos observar que tendremos muchas combinaciones de
caminos posibles por cada contenedor, as podremos identificar una sumatoria de caminos
(denominado nivel compuesto en nuestro modelo) que me lleva a obtener un resultado
esperado.

Top-Down:
Es una estrategia que se apoya al igual que la estrategia Botton-Up en un modelo jerrquico, su
principal objetivo es analizar primero los caminos o rutas por las que se mueve el aplicativo y as bajar el
nivel de complejidad progresivamente hasta detallar el nivel de menor complejidad. Para el caso de
nuestro modelo la estrategia Top-Down consiste en:

Inicia con el anlisis de las rutas o caminos que se deben seguir para poder satisfacer el
alcance esperado por el proyecto (denominado nivel compuesto en nuestro modelo).
Luego analizamos y detallamos cuales son las combinaciones entre los elementos agrupadores
(denominado nivel bsico) que hacen parte de la ruta que estamos analizando.
Finalmente, pasamos a los componentes tcnicos (denominado nivel estndar) para los cuales
analizamos y detallamos las caractersticas que por estndar de los lenguajes de programacin,
son propias de cada objeto independiente del entorno.

Niveles que componen el modelo

Nivel de las Funcionalidades estndar

Son las funcionalidades que se implementan sobre los elementos que fueron desarrollados con el fin de
tener un comportamiento especfico y dicho comportamiento es estndar, ya que independiente del
cliente, lenguaje de programacin, arquitectura o forma de implementacin, estos elementos siempre se
comportan de la misma forma cuando se ejecuta una accin sobre ellos. En este nivel slo se tiene en
cuenta el comportamiento de cada elemento aislado de los dems, sin incurrir en combinaciones - el
comportamiento cuando se relaciona con otros elementos se considera una funcionalidad simple -.
Dentro de los elementos estndar nos encontramos con: Botones, campos de texto, listas de valores,
imgenes, hipervnculos, entre otros.
Nivel de las Funcionalidades simples
Son las funcionalidades resultado de combinar funcionalidades estndar entre s (cuando estn en el
mismo elemento contenedor). En este nivel comenzamos a evidenciar que las diferentes combinaciones
de elementos pueden generar mltiples caminos o escenarios, los cuales pueden tener dos posibles
orientaciones las que denominamos casos felices, que son cuando el sistema sigue el flujo ideal o
esperado y las orientaciones que denominamos casos infelices que es cuando el sistema no sigue el
camino ideal sino que toma una ruta diferente, ya sea por un mensaje de validacin o por un mensaje de
error controlado por el diseo del aplicativo. (el camino infeliz es diferente al issue ya que el issue no
estuvo contemplado en la construccin del aplicativo, mientras que el camino infeliz s.)

Nivel de las Funcionalidades compuestas

 Son las diferentes combinaciones de funcionalidades simples que se identificaron como caminos felices
y que por diseo del aplicativo deben interactuar entre s, en este punto el diseo de los casos de
prueba se convierten en la unin de las diferentes funcionalidades simples y estos a su vez tambin
pueden agruparse en diferentes escenarios, segn las condiciones del negocio del cliente. En este
punto identificamos transacciones

Sintaxis
Para poder describir los elementos del nuevo lenguaje de diseo nos apoyaremos en dos elementos
constitutivos de todo lenguaje, la sintaxis y la pragmtica, que segn definiciones de los trminos dadas
por la Real Academia de la Lengua ( <a target="_top" href="http://www.rae.es/">www.rae.es</a>), son:

Lenguaje : 6. m. Conjunto de seales que dan a entender algo. 7. m. Inform. Conjunto de

signos y reglas que permite la comunicacin con un ordenador.

Sintaxis : 2. f. Inform. Conjunto de reglas que definen las secuencias correctas de los
elementos de un lenguaje de programacin.
Pragmtica : 3. f. Disciplina que estudia el lenguaje en su relacin con los usuarios y las
circunstancias de la comunicacin.

Para nuestro lenguaje de diseo nos apoyamos en ambos elementos y juntos determinan el significado
de las expresiones verbales. Por ello a continuacin vamos a clarificar y esquematizar la concordancia
entre los elementos que lo conforman, su relacin, la dependencia entre ellos y la estructura que deben
tener los elementos, podemos identificar el nivel de los casos y el nivel de los pasos.

Elementos descriptivos de los Casos

Los elementos que se detallan a continuacin son obligatorios para todos los casos:
 Descripcin: Nombre detallado del caso
Precondicin: Condiciones que se deben cumplir antes de ejecutar una prueba sobre el
componente o sistema que hace parte de la prueba.
Resultado esperado: Es el comportamiento o estado resultado que se obtiene luego de ejecutar
un caso y el aplicativo o funcionalidad se comporta de acuerdo a la solicitud o requisito del
cliente.

Los casos a su vez se componen de pasos los cuales poseen una estructura y sintaxis especfica que
se detalla a continuacin.

Componentes de los pasos

Objetos: Es el nombre de todos aquellos elementos que componen sobre los que se lleva a
cabo una accin.
Tipos de Objeto: Es la clasificacin o agrupacin a la cual pertenece el objeto, esta agrupacin
normalmente est dada por los elementos estndar de la programacin y se adecua a las
especficas si el lenguaje de programacin posee elementos propios. Para nuestro caso se
tienen los tipos de objetos pertenecientes al GUI y a la ejecucin de procesos. Ejem.
Radio_Button, Text_Box, Label, SQL object.
Accin: Es el evento que se pretende realizar sobre un objeto. Ejem. Click, Seleccionar.
Dato, este puede ser de dos naturalezas, las cuales son excluyentes:
o Valor: Nos indica un valor especfico que debe tomar el objeto, el valor a ingresar en
este campo debe ser esttico en el tiempo y no depender del momento de la
ejecucin.
o Caracterstica: Nos indica la naturaleza del dato que se debe ingresar en el campo, es
decir, qu condiciones debe cumplir el valor a ingresar en el objeto con el fin de darle la
orientacin esperada al caso, normalmente se le asocia una sentencia SQL. Ejem.
Para poder ingresar al sistema, el usuario debe existir en el sistema, estar activo y
habilitado para ingresar al sistema.

Estructura de los pasos (Sintaxis)

El lenguaje se compone por objeto seguido del tipo de objeto, las acciones posibles que pueden
tomarse para este tipo de objeto y finalmente el dato debo ingresar para darle la orientacin esperada al
caso de prueba.
En la siguiente tabla podemos observar el esquema estndar que compone nuestro lenguaje de
diseo.

Control del Documento

Workflow

Estado Actual ENREVISION

Transicin

Mensaje de Estado Este documento se encuentra en proceso de modificacin.