miSiOneS dOMiNicAs - miSiOneS rEaleS

Que tal,

Tuve en puerta otro proyecto, lo que me gusto mucho de él fue que, otra vez, abarcaba muchas áreas. Se me hace muy interesante cuando involucras a muchas personas en un proyecto porque podemos ver a cada persona como una parte del sistema y entonces un grupo de personas donde cada quien hace su parte se convierte en nuestra "arquitectura del sistema".

El meollo de este tipo de proyectos es que uno debe diseñar la arquitectura del sistema en términos de las personas que participan en el proyecto y sus funciones. Por ejemplo sí, en nuestra arquitectura el componente 1 hace las tareas X y Y pero en la vida real, la tarea X la hace una persona y la tarea Y la hace otra, entonces debemos considerar "dos componentes" en la arquitectura. Para esto es importante saber definir no solo funciones de los "componentes" sino también responsabilidades de las personas.

Por ejemplo, me topé con el siguiente problema:

1.La persona X era responsable de construir una vista SQL para pasarle datos a un sistema.
2.La persona Y debía acceder a dicha vista y procesar los datos.
3.La persona Y tenía que validar los datos antes de procesarlos.

La duda:
¿qué es mejor? ¿Que la persona X valide los datos desde la sentencia SQL que define los datos o que la persona Y los valide al nivel de la aplicación?

Le dí muchas vueltas y no supe que responder =(, los dos caminos eran completamente viables. Un compañero arquitecto de muchos años de experiencia le dío al clavo. El notó que la consulta debía acceder millones de registros, por lo que sí metíamos la validación en las sentencias SQL, la consulta tardaría mucho y nos quedaríamos sin saber que pasaba. En cambio si validabamos los datos en la aplicación, la consulta sería más rápida y podíamos ir actualizando algún indicador cada que procesaramos N registros para saber que el sistema seguía vivo. =)

Este tipo de cosas de la arquitectura de sistemas, solo se domina con el tiempo! =)

Finalmente, todos los involucrados cooperaron y el sistema esta a punto de liberarse.

Este tipo de proyectos son retadores porque te invitan a no sólo crear una arquitectura de un software, sino además debes considerar la "capa humana" y, por lo mismo, tratar con humanos, ejercitar al máximo la inteligencia y audacia para explicar, motivar y pedir las cosas! =)

Hasta Pronto!

A lo largo del desarrollo del sistema, me he dado cuenta de otros detalles que no se deben dejar pasar durante la fase del diseño arquitectónico del sistema. Me refiero al diseño de la base de datos.

La base de datos es el conjunto de información que le da sentido a un sistema. No existen sistemas que no trabajen con datos y cuando estos datos necesitan ser almacenados tendrán que hacerlo en una base de datos. Incluso un solo archivo .txt puede verse como una base de datos primitiva.

Los manejadores de bases de datos modernos nos permiten operar con bases de datos muy poderosas y complejas, capaces de resguardar por sí solas, de manera íntegra, todos los datos de un negocio. Esto lo hacen a traves de procedimientos almacenados, disparadores de eventos, restricciones, índices y paquetes, entre otras cosas.

Cuando diseñamos una base de datos, la tarea principal consiste en identificar los datos y sus respectivas relaciones. Es importante tomar en cuenta la teoría de normalización de bases de datos en esta fase. Otra tarea consiste en definir tipos de datos y llaves. A primera vista, una vez que se tiene esto listo, parece que hemos terminado y surge la constante tentación del programador poco experimentado: COMENZAR A PROGRAMAR. En este caso, comenzar a utilizar la base de datos...

Sin embargo no es así. El diseño conceptual de la base de datos, anteriormente citado, es sólo el PRINCIPIO de la construcción de una buena base de datos. Hay más factores a tomar en cuenta, tanto del diseño lógico como del físico.

Respecto del diseño lógico, es importante tener cuidado incluso de los nombres de los campos, es importante definir una nomenclatura para diferenciar tablas crecientes de tablas catalogo, columnas llave de columnas descriptivas, etc. Una vez que hemos definido nuestra nomenclatura, es importante apegarse a ella a lo largo de todas las tablas. Esto nos facilitara mucho la programación de sql y hará que nuestras consultas sean legibles, facilitando así el mantenimiento de la base y de la aplicación.

Siguiendo con el diseño lógico, una vez que hemos terminado el diseño de las tablas y sus relaciones, es necesario definir los usuarios de la base. Debido a los ataques de inyección de sql, una buena medida de seguridad consiste en utilizar siempre usuarios con permisos limitados según las actividades que le son necesarias. Por ejemplo, al momento de generar un reporte únicamente necesitamos permisos de lectura por lo que podríamos crear un usuario que solo pueda leer y utilizar ese usuario cada vez que vayamos a generar un reporte. Cuando necesitemos escribir, utilizaremos otro usuario. Para obtener una seguridad mas rigurosa, además de limitar el acceso por permisos, lo limitamos también por objetos. Es decir, indicamos que un usuario puede leer o escribir SOLAMENTE en ciertas tablas.

Respecto del diseño físico, es importante considerar en que lugar estará la base de datos, ver si usará el mismo servidor para la base que para la aplicación. En caso de que no sea así, ver si existen las configuraciones de red necesarias para que los dos servidores puedan comunicarse, analizar el tráfico que aumentarán a la red las transacciones entre ambos servidores y definir las reglas de crecimiento para la base.

Es interesante esto de ser arquitecto de sistemas! :=)

Hasta Pronto.

Liga del día:
http://www.owasp.org/index.php/Preventing_SQL_Injection_in_Java

Página del día:
http://www.ctube.net/
;-)

Canción del día:
Sweet Sacrifice - Evanescence

Frase del día:
No porque me guste la misma música que una persona significa que soy igual a esa persona. :-o

Nunca se bajen música de:
Eagles

Después de aventurarme en al confuso mundo de la documentación, he terminado de realizar la etapa de análisis y diseño de un nuevo sistema de reporteo. El saldo son 11 hojas completitas, llenas de diagramas por todas partes.

He de confesar, que de todo lo que hice, solo entendí el 50%, por mucho. En gran parte me confundía y no sabía bien que hacer debido, en primer lugar, a que no tengo quien me revise los diagramas. En fin, poco a poco iré aprendiendo con ayuda del método tradicional de IS en México: prueba y error! jejejeje.

Sin embargo, estoy muy asombrado de los resultados de ambas etapas. No cabe duda que la IS ayuda mucho. Experimente una especie de iluminación progresiva que me permitió ir descrifrando y DISEÑANDO una solución completa, eficaz y mantenible sin tener que programar nada. Debido a que esa es la meta de la IS, parece que tuve éxito.

Tengo el presentimiento de que todos los diagramas que hice, en particular el diagrama de clases, me ayudará muchísimo a programar fluidamente y sin descalabros. Mis dedos simplemente bailarán sobre el teclado....

De todo este trabajo lo que siento que me sirvió más son los modelos CRC, el diagrama de clases y el prototipo.


Pues vamos a comenzar a programar!!!!!!! Yuhuuuuu!!!!!!! Ya después les cuento si todo este rollo, de hacer primero los planos, sirve de algo. =)


El libro del día: Aprendiendo UML en 24 horas, Joseph Shmuller, Prentice Hall.
La liga del día: http://www.altillo.com/chistes/ingenierosa.asp
La imagen del día:


Pasenla Bien.
;-)

Hola a todos, hoy ando aburrido, por eso me puse a iniciar este blog. Ya veremos en que se convierte. ;-P

Suerte a todos.