RSS

Archivos Mensuales: septiembre 2010

apuntes de la unidad

DISEÑO DE LA ARQUITECTURA DEL SOFTWARE.

La arquitectura está compuesta por su componente la relación que existe entre ellos y con el ambiente que trabajaran, así como también los principios o regalas que normaran su diseño y su evolución.

Una definición por parte de la ingeniería del software será lo siguiente.

Una arquitectura del software es la estructura de estructuras de un sistema, la cual abarca componentes de software propiedades estrena visible a estos componentes.

¿Porque es importante la arquitectura?

1.-Por que las representaciones de la arquitectura del software facilitan la comunicación entre todas las partes interesadas, en el desarrollo de un sistema avanzado en computadora.

2.- Destacan decisiones tempranas de diseño que tendría un profundo impacto en todo el trabajo de ing.

3.-Porque constituye un modelo relativamente pequeño e intelectualmente comprensible de como este estructurado el sistema y de cómo trabajan junto los componentes.

APLICACIONES MONOLITICAS

Son aquellas que conocemos como aplicaciones de estación en otras palabras interfaces graficas de usuario GUI’S son servicios de presentación, negocios y pertinencia de datos, en la misma maquina no ahí concurrencia de usuarios.

ARQUITECTURA LIENTE/SERVIDOR una de sus características es que cuenta con clientes pesados aunque esto no es un estándar dependiendo del lenguaje, existen conexiones dedicadas a la base de datos mediante esta arquitectura generalmente los protocolos de comunicaciones son pesados, existe ejecución remota de SQL’S existe alta administración y el rendimiento es bajo el tráfico en la red puede estar saturado o ser muy alto

ARQUITECTURA LIENTE/SERVIDORMEJORADA.Se aplica en la lógica de negocios en la base de datos existen cliente pesados aunque también no es un estándar las conexiones a las bases de datos se convierten a conexiones dedicadas el rendimiento en este tipo de arquitectura es mucho mejor  existe una alta administración baja escalabilidad, flexibilidad y portabilidad.

ARQUITECTURA DE TRES NIVELES. Reutilización de la lógica de negocios para diferentes clientes o sistemas son aplicables en este enfoque se mejora la escalabilidad y la flexibilidad de las aplicaciones existe una completa independencia de la base de datos.

ARQUITECTURA VERSUS DISEÑOS. la arquitectura envuelve un conjunto de decisiones de  estrategias de diseños,linchamiento de  reglas y patrones que restringen el diseño Y la implementación de un software.

DISEÑO DE INTERFACES DE USUARIOS

Antes de implementar los formularios y los informes ahí que diseñar su aspecto para ello es necesario tener en cuanta.

1.-Utilizar títulos que sean significativos, y que identifiquen sin ambigüedad el propósito del informe o formulario.

2.-Dar instrucciones breves y fáciles de comprender.

3.-Agrupara y secuenciar los campos de forma lógica.

4.-Aser que el aspecto del informe o formulario sea atractivo a la vista.

5.-Utlizar nombres familiares para etiquetar los campos.

6.-Utilizar terminología y abreviaturas contingentes.

7.-Hacer un uso razonable de los colores.

8.-Dejar un espacio visible para los espacios de entrada y delimitarlo

9.- Permitir un uso y adecuado del cursor.

10.-Permitir la correxion de carácter a carácter y de campos correctos.

11.-Dar mensajes de error para los valores ilegales.

12.-Marcar los campos que sean opcionales o en su defecto requisitos.

13.-Dar mensajes a nivel de campo para indicar su significado.

14.-Dar una señal que indique cuando el informe o formulario está completo.

El sistema no está usando tu aplicación

La cuestión más básica a considerar en el diseño de interfaces de usuario es que el usuario no quiere utilizar tu aplicación. Quieren hacer su trabajo de la forma más sencilla y rápida posible y la aplicación no es más que una herramienta para ayudarles a lograrlo.

LEY DE FITT.

Esta ley es la más básica y conocida entre las leyes de diseño de interfaces de usuario esta ley dice que cuando más grande y más cercano al puntero del ratón es un objeto más sencillo es hacer clic sobre él.

Esto es sentido común, pero muchas veces es ignorado en el diseño de interfaces de usuario.

INTERFERENCIAS INECESARIAS

Esto quiere decir que cuando un usuario está trabajando sobre una aplicación normalmente está concentrado en su trabajo, suponga el caso de que una aplicación “modernista” facilita automáticamente al usuario la notificación puntual de cada hora mediante un mensaje grafico o animación, el usuario tiende a distraerse y perder la concentración; llevando a esto como consecuencia que el usuario recapitule lo que estaba haciendo.

UTILIZAN LA POTENCIA DE LA COMPUTADORA.

1.- utiliza su potencia para ayudar al usuario.

2.- as que se pueda distinguir fácilmente entre los elementos similares.

3.-recuerda las opciones de la aplicación.

BASE DE DATOS.

Las bases de datos no son tan solo una colección de archivos. Más bien, una base de datos es una fuerte central de datos destinados a compartirse entre muchos usarios para diversidad de aplicaciones.

OBJETIVOS DE EFECTIVIDAD DE LA BASE DE DATOS.

1.-asegurar que los datos se puedan compartir entre los usuarios para una diversidad de aplicaciones.

2.-mantener datos que sean exactos y consistentes.

3.-asegurar que todos los datos requeridos por las aplicaciones actuales y futuras se podrán aceder con facilidad.

4.-permitir a la base de datos evolucionar con forme aumentan las necesidades de los usuarios.

5.-permitir a los usuarios contruir su vista personal de los datos, sin preocuparse por la forma en que los datos se encuentran almacenados físicamente.

EJEMPLO ENTIDAD/RELACION

 
Deja un comentario

Publicado por en 6 septiembre, 2010 en SISTEMAS DE INFORMACION II

 

ACOPLAMIENTO Y COHESIÓN

Todo desarrollador de software debe tener en cuenta que se obtienen tantos más beneficios cuanto más alta es la cohesión en una unidad de software y más bajo es el acoplamiento entre las unidades. Esta máxima se debe aplicar tanto en el diseño, la arquitectura y la codificación.

A menudo escuchamos problemas relacionados con dos partes de software que están fuertemente acopladas, y escuchamos términos como desacoplar.

Tanto el acoplamiento como la cohesión son términos un tanto abstractos y difíciles de medir. Hace algunos años, cuando sólo existía la programación imperativa, las cosas eran un tanto más concreta. En la actualidad, con varios paradigmas en marcha (programación orientada a objetos, a aspectos, extreme programming, etc.. ) y múltiples lenguajes y plataformas, los términos de acoplamiento y cohesión se hacen más difíciles de concretar, pero siguien teniendo aplicación, aunque su significado sea más abstracto.

Empezaremos por el acoplamiento. El término “acoplamiento” hace alusión al grado de dependencia que tienen dos unidades de software. Tiempo atrás se utilizaba la palabra “módulo” o “subrutina” en lugar de unidad de sofware. Hoy en día, en opinión del que escribe, la palabra “módulo” es completamente inadecuada y obsoleta. Mejor utilizaremos “unidad de software”, que es un concepto más amplio.

ACOPLAMIENTO

Bien… ¿Qué es una unidad de software? Pues simplemente cualquier pieza de software que realice algún cometido. Por ejemplo: una función, un método, una clase, una librería, una aplicación, un componente, etc…

I) Unidades completamente desacopladas

Ya lo hemos comentado, dos unidades están completamente desacopladas cuando hacen su trabajo de manera totalmente independiente. Esto nos permitiría coger una de ellas y utilizarla tal cual en un programa sin necesidad de llevarnos la otra.

Por ejemplo, estos dos métodos (en C#), están totalmente desacoplados. Ninguno de ellos necesita al otro para hacer su trabajo.

static int metodo1(int a, int b)

{

return a * b;

}

static int metodo2(int a, int b)

{

return a + b;

}

II) Acoplamiento normal

El acoplamiento más común que existe es aquel en el que una unidad de software necesita del trabajo que hace la otra.

Por ejemplo, estos dos métodos tienen un acoplamiento normal.

static int metodo1(int a, int b)

{

int c = metodo2(a, b); ;

return 2 * c;

}

static int metodo2(int a, int b)

{

return a + b;

}

III) Acoplamiento de datos.

Una unidad de software está acoplada a otra por los datos cuando ambas necesitan del mismo conjunto local de datos para funcionar.

Por ejemplo, observa estos dos métodos de la misma clase:

class Ejemplo

{

int compartido=0;

void metodo1(int a, int b)

{

compartido = a * b;

}

void metodo2(int a, int b)

{

compartido = a + b;

}

}

COHERENCIA DEL SOFTWARE (COHESIÓN)

La cohesión hace referencia a la forma en que agrupamos unidades de software (módulos, subrutinas…) en una unidad mayor. Por ejemplo: la forma en que se agrupan funciones en una biblioteca de funciones o la forma en que se agrupan métodos en una clase, etc.

El consenso general para una buena programación o un buen diseño es que la cohesión debe ser alta. Es decir, mientras más cohesionados estén los elementos agrupados, mejor.

El acoplamiento, junto con la modularidad, la cohesión y otros factores, permiten mejorar la programación y el diseño de sistemas informáticos y aplicaciones, y son cruciales en el incremento de la reutilización de los códigos.

 
Deja un comentario

Publicado por en 6 septiembre, 2010 en SISTEMAS DE INFORMACION II

 

ver diapositivas

http://www.slideshare.net/sistemasdeinformacion2/determinacin-del-flujo-de-datos

 
Deja un comentario

Publicado por en 6 septiembre, 2010 en SISTEMAS DE INFORMACION II

 

presentaciones de determinacion de flujo de datos

presentacion de la unidad

 
Deja un comentario

Publicado por en 6 septiembre, 2010 en SISTEMAS DE INFORMACION II

 

ENSAYO DE LA UNIDAD I

LINK DE DESCARGA

 
Deja un comentario

Publicado por en 5 septiembre, 2010 en SISTEMAS DE INFORMACION II

 

DISEÑO DE SISTEMAS

 
Deja un comentario

Publicado por en 5 septiembre, 2010 en SISTEMAS DE INFORMACION II

 

DISEÑO DE SITEMAS

TIPOS DE SIETMASEDGAR ABRAHAM CASTAÑEDA ESCAJEDA

 
Deja un comentario

Publicado por en 1 septiembre, 2010 en SISTEMAS DE INFORMACION II