DISEO

SISTEMA

Daniel Martnez

DEL

DISEO ESTRUCTURADO

El objetivo principal del diseo

estructurado es desarrollar la
estructura de programa as como las
relaciones entre los elementos,
denominados mdulos, que componen
esta estructura.

DIAGRAMA DE ESTRUCTURAS

En mtrica a este diagrama se le

denomina diagrama de cuadros de
constantine. Los elementos principales
de un diagrama de estructura son:
mdulos, conexiones entre mdulos y
comunicacin entre mdulos.

MODULO

Un modulo consiste en una unidad

claramente definida y manejable, con
interfaces modulares perfectamente
definidas.
El nombre del modulo tiene que
representar la funcin que realiza. Los
mdulos pueden comunicarse entre s
por medio de estructuras de datos y de
control (flags).

CONEXIN ENTRE MDULOS

Un sistema esta compuesto por

mdulos jerrquicamente, cooperando
y comunicndose entre s para realizar
una tarea.

COMUNICACIN ENTRE MDULOS

La comunicacin intermodular se
realiza a travs de los datos y los flags.
Los datos se procesan; por el contrario,
los flags solo sirven como valores de
condicin para comunicar condiciones
entre los mdulos.

TEORA DE LA NORMALIZACIN

Esta tcnica ayuda a los diseadores a

prevenir problemas de redundancia y
anomalas de modificacin, insercin o
borrado en los esquemas de datos.
En efecto, esta tcnica consiste en ir
descomponiendo los registros en otros de
menor tamao, de forma que satisfaga una
serie de restricciones especficas que
definen lo que se conoce por forma
normal.

TRANSFORMACIN DEL ESQUEMA E.R. AL ESQUEMA

RELACIONAL

Dentro de las actividades que hay que

realizar en la fase de diseo, cabe
destacar la transformacin de los
esquemas E.R.(o de los diagramas de
estructura de datos) al modelo lgico
que soporte los datos : jerrquico,
codasyl o relacional.

MODELO RELACIONAL

En el modelo relacional la estructura

basica es la relacin, en la que se
distinguen un conjunto de columnas
llamadas atributos y un conjunto de
filas denominadas tuplas, que son las
ocurrencias de la relacin.

Este modelo que en la actualidad sigue

la mayora de las bases de datos
existentes, tiene como objetivos:
-Independencia fsica
-Independencia lgica
-Flexibilidad
-Uniformidad
-Sencillez

EJEMPLO

REGLAS DE TRANSFORMACIN

-Toda entidad se convierte en una

relacin
-Toda interrelacin n:m se transforma
en una relacin
-Toda interrelacin 1:n se traduce en el
fenmeno de propagacin de clave

MODELO DE CLASES DE DISEO

Un modelo de clases es la descripcin

mas clara de la estructura esttica de
un sistema software, durante el
anlisis, el modelo de clases ser
conceptual, ms centrado en
representar los conceptos de
informacin que manejara la
aplicacin.

En el diseo, las decisiones tomadas

por los desarrolladores sobre la
estructura de la aplicacin se reflejan
en un modelo de clases donde se
especifican los atributos y las
operaciones necesarias para que cada
clase cumpla con el cometido que se le
ha asignado. Tambin es necesario
aplicar las ideas de visibilidad a los
atributos, operaciones y clases.

Publico: sin restriccin de accesibilidad.

Protegido: accesible desde las clases
que heredan y desde las que estn en
el mismo paquete.
Privado: accesible solo desde la propia
clase.

La norma general de la orientacin a

objeto sugiere que los atributos de las
clases sean privados y que los mtodos
sean pblicos o privados en funcin del
acceso que se requiera para realizar las
distintas funciones de la aplicacin.

EJEMPLO

PATRONES

Los patrones de software son reglas o

guas para resolver un problema dentro
de un contexto. La solucin no es
determinista, sino que ofrece un
modelo de actuacin que quien lo
aplique debe adaptar a la situacin
concreta en la que se encuentra.

PATRN SE DEFINE CON CUATRO ELEMENTOS

-Un nombre descriptivo que permita

una referencia rpida del patrn.
-El problema que aborda y que indica
cuando es interesante aplicar el patrn.
-La solucin propuesta.
-Las consecuencias, ventajas e
inconvenientes de su aplicacin.

DISEO DE PROCEDIMIENTOS DE USUARIO

Para que la operacin con el sistema

sea exitosa es necesario definir las
tareas que debe realzar el usuario para
lograr su correcto funcionamiento. Los
procedimientos de usuario describirn
el conjunto de operaciones manuales
que han de seguir los usuarios a la hora
de trabajar con el sistema.

En estos procedimientos podemos distinguir

dos mbitos principales:
Instalacin y conversin de datos
Operacin y exploracin del sistema
El diseo de estos procedimientos tiene un
impacto directo en la elaboracin de
manuales o documentacin de apoyo para
los distintos perfiles de usuario, as como en
las actividades de formacin de los mismos.

DISEO DE LA INTERFAZ DE
USUARIO

El paso de una interfaz de pantallas

mono cromadas en modo carcter a un
moderno entorno de ventanas a todo
color con potentes grficos y
multimedia supone para muchos
usuarios un cambio espectacular a
pesar de que las funciones o el
rendimiento de la aplicacin no hayan
sido alterados.

Debido a la dificultad de ajustarse a los

gustos y preferencias de los usuarios
expertos en el dominio de la aplicacin,
es habitual recordar a los diseadores
que ellos no son los usuarios:
-Estos son muy variados
-No suelen ser expertos informticos
-No saben la trascendencia de sus
peticiones y decisiones.

Por ello, es fundamental que exista un

diseo iterativo basado en un eficaz
feedback por parte del usuario
mediante pruebas de prototipos y
demos de la interfaz

EJEMPLO

PRUEBAS DEL SOFTWARE

DEFINICIONES:

Prueba (test): una actividad en la cual

un sistema o uno de sus componentes
se ejecutan en circunstancias
previamente especificadas, los
resultados se observan y registran y se
realiza una evaluacin de algn
aspecto.

Caso de prueba(test case): un conjunto

de entradas, condiciones de ejecucin
y resultados esperados desarrollados
para un objetivo particular como, por
ejemplo, ejercitar un camino concreto
de un programa o verificar el
cumplimiento de un determinado
requisito.

Defecto (defect, fault, bug): Un defecto

en el software como, por ejemplo, un
proceso, una definicin de datos o un
paso de procesamiento incorrectos en
un programa.

Fallo (failure): La incapacidad de un

sistema o de alguno de sus
componentes para realizar las
funciones requeridas dentro de los
requisitos de rendimiento
especificados.

Error (error): tiene varias aceptaciones:

un defecto, un resultado incorrecto o
una accin humana que conduce a un
resultado incorrecto.

EL PROCESO DE PRUEBA

El proceso de prueba comienza con la

generacin de un plan de pruebas en
base a la documentacin sobre el
proyecto y la documentacin sobre el
software a probar. A partir de dicho
plan, se entra en detalle diseando
pruebas especficas basndose en la
documentacin del software a probar.

A partir de los resultados de salida, se

pasa a su evaluacin mediante
comparacin con la salida esperada. A
partir de esta, se pueden realizar dos
actividades:

-La depuracin (localizacin y

correccin de defectos) .
-El anlisis de la estadstica de errores.

LA DEPURACIN

La depuracin puede corregir o no los

defectos. Si no consigue localizarlos,
puede ser necesario realizar pruebas
adicionales para obtener ms
informacin. Si se corrige un defecto,
se debe volver a probar el software
para comprobar que el problema est
resuelto.

EL ANLISIS DE LA ESTADSTICA DE ERRORES

El anlisis de errores puede servir para

realizar predicciones de la fiabilidad del
software y para detectar las causas
ms habituales de error y mejorar los
procesos de desarrollo.

TIPOS DE PRUEBAS

PRUEBA FUNCIONAL

La prueba funcional o de caja negra se

centra en el estudio de la
especificacin del software, del anlisis
de las funciones que debe realizar, de
las entradas y de las salidas.

PRUEBAS ALEATORIAS

En las pruebas aleatorias se simula la

entrada habitual del programa creando
datos para introducir en el que sigan la
secuencia y la frecuencia con las que
podran aparecer en la prctica diaria,
de forma continua, sin descanso.

PRUEBA DE UNIDAD

Hablamos de una unidad de prueba

para referirnos a uno o ms mdulos
que cumplen las siguientes
condiciones:
-todos son del mismo programa
-al menos uno de ellos no ha sido
probado
-el conjunto de mdulos es el objeto de
un proceso de prueba.

PRUEBAS DE INTEGRACIN

Las pruebas de integracin estn

totalmente ligadas a la forma prevista
de integrar los distintos componentes
del software hasta contar con el
producto global que debe entregarse.
As, las pruebas de integracin implican
una progresin ordenada de pruebas
que parte desde los componentes y que
culmina en el sistema completo.

PRUEBA DEL SISTEMA

La prueba del sistema es el proceso de

prueba de un sistema integrado de
hardware y software para comprobar si
cumple los requisitos especificados.

PRUEBA DE ACEPTACIN

El objetivo que se desea lograr consiste

en comprobar si el producto est listo
para ser implantado para su uso
operativo en el entorno del usuario.

TwT
por fin termine
Y
gracias.