Antecedentes (UML)

Seguramente habrá observado sistemas de información computarizados y no computarizados, y en un porcentaje mínimo tenemos a los usuarios que están conforme con los programas desarrollados, o tal vez hemos conversado con usuarios que han deseado modificar un sistema integrado y dicho cambio le ha producido el desequilibrio de otras unidades del sistema incorporado, o ha encontrado  desarrolladores que sin conocer correctamente los procesos empiezan construyendo formulario tras formulario y desarrollan la aplicación, todo esto conlleva a poder analizar las causas que generan este desequilibrio es el incorrecto análisis de los procesos para la construcción de software deaplicaciones comerciales.Para ello el UML, (Unified Modeling Language), Lenguaje Unificado de Modelado esta compuesto por una gama de diagramas o artefactos, que permiten graficar o tomar una radiografía a los procesos para una interpretación de los mismos desde el punto de vista de usuario como de los desarrolladores de Software, el UML es como que si fuese el Castellano que utiliza un abecedario compuesto de letras, las cuales formaran silabas, palabras, oraciones, párrafos y documentos que contendrán un pensamiento, mediante el castellano Usted podrá escribir una novela, una canción una poesía entres otros, Algo análogo es el UML es un lenguaje el cual usa sus diagramas como que si fuera el abecedario del idioma castellano, y estos servirán para plasmar los procesos de un determinado negocio, para de esta manera construir modelos o maquetas de la interpretación de los mismos entre usuarios y desarrolladores de los sistemas de información. Existiendo para ello un lenguaje común de comunicación, Cuando no se usa la notación UML( conjuntos de Diagramas) se tiene la problemática de no encontrar los términos adecuados, ya que los analistas usan términos informáticos de difícil entendimiento por los usuarios, y por otra parte los desarrolladores no entienden el lenguaje queusan los usuarios del mundo real de estudio.Y la metodología es otra cosa que está muy estrechamente relacionada a UML, una metodología va ha indicar el camino a seguir para el desarrollo de sistemas de información. Y existen muchas de ellas tal como: OMT, RUP, OBJECTORY, FUSION, GRAPPLE, usando la notación UML, Por tal sentido el UML nos deja las puertas abiertas para que cada uno de nosotros pueda implementar un metodología que se acople a nuestras necesidades extrayendo de los diagramas o artefactos UML los que fueran necesarios para la construcción de los modelos del sistema de información a desarrollar. Con UML, usted podrá hacer un análisis y diseño que lo llevarán a la construcción de sistemas orientados a objetos, porque le permitirán pensar a en el ámbito de componentes que son objetos reutilizables que podrán estar comprendidos en archivos dll (librerías Dinámicas) y plasmaran la lógica del negocio correctamente teniendo accesibilidad a los cambios.

 Principios de UML

Siglas de Unified Modeling Language( Lenguaje Unificado de Construcción de modelos) El UML es resultado de estudios de parte de Grady Booch, James Rumbaugh e Ivar Jacobson, estos señores se le apodado como los “tres amigos”, cada uno de ellos en los años ochenta trabajaron en empresas distintas con sus propias metodologías de análisis orientada a objetos predominando entre sus competidores, sin embargo a mediados de los años noventa empezaron a intercambian ideas y emprendieron lo que es hoy es el UML, quienes también fueron creadores de Rational Software Corporation. Después de tantas discusiones fue presentado el proyecto de UML a OMG(grupo de Administración de Objetos) quienes adoptaron a UML como estándar en la industria del software y continua evolucionando.

 Historia de Metodologías e importancia de UML

A un analista o estudiante de análisis le es común seguramente haber observado los siguientes gráficos en la construcción de modelos de negocios.

Proceso

 Algún tiempo atrás, se utilizaban Diagramas de Flujo de datos(figura I.1) bajo la notación de Yourdon y algunas otras notaciones como las de Gane y Sarson, por mucho tiempo se utilizo para la interpretar procesos esta notación, la cual tenia la dificultad para analizar los niveles de descomposición, debido a que no existía una herramienta que les permitiera graficar bajo la nomenclatura planteada, y otros de los inconvenientes era la revisión de los modelos con los usuarios, no existiendo un lenguaje de entendimiento de los diagramas con el conocimiento del mundo real. Posteriormente y en la actualidad se utiliza IDEF, que es técnica de análisis y diseño de sistemas que son utilizadas para la definición de sistemas, análisis de requisitos y diseño de software, consiste en un conjunto de procedimientos que permiten al analista de sistemas descomponer y comprender mejor las interrelaciones del sistemas y sub-sistemas de los procesos de negocio, paso a paso para explicar el proceso total. Cada actividad es administrada como una transformación de entradas en salidas, tomando control sobre las restricciones y mecanismos o factores de producción consumidos por la actividad bajo el modelo ICOM (Input Control Output Mecanismo)  

ICOM

De hecho que es una técnica que aporta un conocimiento orientado al punto de vista netamente informático, Pero los clientes a los cuales se les construye los sistemas no comprenden el lenguaje informático, porque el analista tiene que ser el aprendiz de los procesos y no implantador de los mismos y es aquí donde existe un rompimiento en el desarrollo de sistemas Es por ello que el UML es un lenguaje que con la notación de sus diagramas (figura I.3) pretende establecer una comunicación entre el analista de sistemas y el usuario, para que de esta manera se comprendan como los sistemas funcionan, creo que es lo más importante, por que cuando el analista de sistemas logre cubrir el entendimiento de los procesos podrá idearlos en términos informáticos para la fabricación de los sistemas de información. Y también con la gama de diagramas se pueden considerar los distintos puntos de vista que puedan existir entre los usuarios del sistema a desarrollar y por ende se podrá recopilar en su totalidad las necesidades del negocio. 

Casos

Antecedentes UML

uml

Seguramente habrá observado sistemas de información computarizados y no computarizados, y claro tenemos a los usuarios que están conforme con los programas desarrollados, o tal vez hemos conversado con usuarios que han deseado modificar un sistema integrado y dicho cambio le ha producido el desequilibrio de otras unidades del sistema incorporado, o ha encontrado desarrolladores que sin conocer correctamente los procesos empezamos construyendo formulario tras formulario y desarrollan la aplicación, todo esto conlleva a poder analizar las causas que generan este desequilibrio es el incorrecto análisis de los procesos para la construcción de software de aplicaciones comerciales. Pues bien esta es la entrega de los Antecedentes a saber acerca de de esta metodología.

Normalización de Bases de Datos (las 3 formas normales)

Existen 3 niveles de Normalización que deben respetarse para poder decir que nuestra Base de Datos, se encuentra NORMALIZADA, es decir, que cumple con los requisitos naturales para funcionar optimamente y no perjudicar las Performance por mala arquitectura.Estas 3 reglas de Normalización se las conoce como las 3 FORMAS NORMALES.

La Primera Forma Normal Esta primera Forma Normal, nos lleva a no repetir datos en nuestras tablas. Los famosos maestro – detalle, deben aplicarse a la estructura de la tabla.Si nuestra tabla de ventas repite una y otra vez (por cada venta) , el nombre, el domicilio y otros datos del Cliente, es que no hemos aplicado esta Normalizaciòn.Si tenemos una tabla clientes, en la tabla ventas, solo deberia figurar el codigo del cliente, para que el resto de los datos se puedan referenciar automaticamente sin problemas y sin duplicar información.Lo mismo ocurriria en una tabla de detalle de ventas, si por cada item vendido colocamos el detalle del producto, con su descripción , medidas, etc…Tendriamos un desaprovechamiento de espacio y recursos muy grande. Para ello, tendremos nuestra tabla maestra de Productos y con solo grabar el código de dicho producto en nuestra tabla de ventas, será suficiente.

La Segunda Forma Normal (Si o si debe estar previamente aplicada la Primera Forma Normal) La Segunda Forma Normal nos habla de que cada columna de la tabla debe depender de la clave.Esto significa que todo un registro debe depender únicamente de la clave principal, si tuvieramos alguna columna que se repite a lo largo de todos los registros, dichos datos deberian atomizarse en una nueva tabla.Veamos un ejemplo

 VentaID ItemID  FechaVenta  ClienteVenta  ProductoId  Cantidad 
1  01/12/2007 2334  10 
 01/12/2007 2 3333
 01/12/2007 2 66643  34 
 01/12/2007 21 
 1  02/12/2007 3566 

Ahi tenemos un claro problema !!!Acaso no se busca NO REPETIR DATOS ?Si toda una venta tendrá el mismo numero de Cliente y la misma Fecha…Por que no crear una Tabla de MAESTRO DE VENTAS y que contenga esos 2 datos ?Es evidente que la columna ClienteVenta y FechaVenta se repetirán por cada venta realizada.Es por ello que proponemos el siguiente esquema 

 VentaID ItemID  ProductoId  Cantidad 
1 2334  10 
3333
66643  34 
21 
 1 3566 

Y ahora nuestra nueva tabla maestra

VentaId  FechaVenta  ClienteVenta 
1 01/12/2007  2
02/12/2007 

Entonces, nuestra 2da Forma Normal nos habla de que cada columna de una tabla debe depender de toda la clave y no constituir un dato unico para cada grupo de registros.

La Tercera Forma Normal En realidad si nos guiamos en el ejemplo de esta nota, ya no quedaria normalización por aplicar y podriamos decir que nuestro ejemplo cumple con las 3 formas normales, ya que la 3ra Forma Normal nos habla de que :

  1. Ninguna Columna puede depender de una columna que no tenga una clave
  2. No puede haber datos derivados

En el 2do ejemplo hemos descubierto campos que dependian de la clave principal (VentaID) y que podrian incluirse en una tabla maestra.Pero supongamos un ejemplo donde ciertas columnas no dependen de la clave principal y si dependen de una columna de nuestra tabla.

 VentaID ItemID  ProductoID  Cantidad  Descripcion  Medida  Proveedor 
 1 3455  12  Impresora HP LJ8000  122cm 
 1 2455  34  Scanner HP A3555  33cm 
 2 1 5444  21  Mouse HP Wireless  – 

Esto es muy normal encontrar en bases mal normalizadas.Vemos que los campos DESCRIPCION , MEDIDA y PROVEEDOR no dependen de VENTAID y es por ello que no deberian estar dentro de la tabla de detalle de ventas, ya que dependen de PRODUCTOID.Aqui no se trata ya de eliminar grupos repedidos de datos (1ra Forma Normal) sino que ante la inclusion de una clave perteneciente a otra tabla, cualquier campo que sea subordinado de dicha clave debe estar en otra tabla y no en nuestra tabla detalle.

ConclusiónFinalmente si tomamos en cuenta que una tabla de detalle de venta (item x item) puede contener un volumen de millones de registros, al haberle aplicado las 3 formas normales nos estaremos ahorrando varios Gigabytes de tamaño en dicha tabla y por supuesto mejorado notablemente la performance.

Normalización de Bases de Datos (las 3 formas normales)

 

Diseñar una Base de Datos sin los conocimientos básicos de Normalización puede llevarnos al rotundo fracaso.

Existen 3 niveles de Normalización que deben respetarse para poder decir que nuestra Base de Datos, se encuentra NORMALIZADA, es decir, que cumple con los requisitos naturales para funcionar optimamente y no perjudicar las Performance por mala arquitectura.

Estas 3 reglas de Normalización se las conoce como las 3 FORMAS NORMALES. pulse aqui en este enlace detallada a contunuación.