Análisis de Sistemas

42
DISEÑO DEL SISTEMA Daniel Martínez

description

Sistemas

Transcript of Análisis de Sistemas

Diseo del sistema

Diseo del sistema

Daniel Martnez

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.