viernes, 27 de noviembre de 2009

La importancia de los Sistemas de Información

Las organizaciones siempre utilizaron sistemas que les permitieron administrar el manejo de su información, con lo cual no necesariamente debe existir una computadora para reconocer la existencia de estos tipos de sistemas pues estos pueden ser también del tipo manuales; por ejemplo una distribuidora pequeña que no tenga informatizada la totalidad de sus esquemas de logística y comercialización. Lo importante es que el sistema permita almacenar, recuperar, procesar y distribuir información.

Sin embargo, es cada vez más necesario el disponer de sistemas de información basados en computadoras por los beneficios que estos proporcionan: reducción de errores provocados por las personas a través del control de las entradas, velocidad en el procesamiento de datos, posibilidad de realizar tediosos análisis sobre los mismos, reducción de espacio físico destinado a su almacenamiento, agilidad al momento de buscar algún dato en particular, y otros tipos de ventajas que podrían lograrse en caso de enfocarse en el uso estratégico de los mismos.

En los entornos de negocio actuales, el disponer de una buena gestión en el uso de los sistemas de información se convierte en una estrategia que pueden utilizar las empresas para hacer frente a sus fuerzas competitivas.

Para valorar aún más la importancia del concepto tratado, en (BRIEN, 2006) se hace la pregunta "¿Por qué es importante los sistemas de información y la tecnología de la información?", a lo que responde lo siguiente: Por qué es importante contabilidad, finanzas, administración de operaciones, mercadotecnia, administración de recursos humanos o cualquier otra función principal de negocios. Creo que tal respuesta es más que sufiente para visualizar la importancia que en la actualidad se le otorga a los sistemas de información, pues, en palabras de los de autores de (BRIEN, 2006), "estos tipos de conocimientos se constituyen en un elemento vital de las organizaciones y negocios exitosos".

(BRIEN, 2006). O`Brien, James; Marakas, George. Sistemas de información gerencial. Editorial: Mc Graw Hill. 2006

Diagramas de Clases en UML

Un diagrama de clases muestra un conjunto de clases, interfaces, y colaboraciones y sus relaciones. Gráficamente un diagrama de clase es una colección de vértices y arcos. Es justo un tipo especial de diagrama y comparte propiedades comunes al igual que todos los otros diagramas -un nombre y un contenido gráfico son una proyección dentro de un modelo. Muestra un conjunto de clases, interfaces, y colaboraciones y sus relaciones entre ellos.

Los diagramas de clase se usan en el diseño del modelo estático para ver un sistema. Para las demás partes, este modelado involucra el vocabulario del sistema, el modelado de colaboraciones, o modelado de esquemas. Son importantes no solo para la visualización, especificación y documentación del modelo estructural, pero también para la construcción de sistemas ejecutables. Ingeniería hacia adelante e ingeniería inversa.

UML, usa los diagramas de clase para visualizar el aspecto estático de esa construcción de bloques y sus relaciones y especificar esos detalles para la construcción.

Un diagrama de clases comúnmente con tiene lo siguiente:

  • Clases
  • Interfaces
  • Colaboraciones
  • Dependencia
  • Generalización
  • Relaciones de asociación

Los otros diagramas de clase pueden contener notas y restricciones. Los diagramas de clase pueden también contener paquetes o subsistemas ambos de los cuales son usados para agrupar elementos de su modelo. Algunas veces se quieren instancias de lugar en el diagrama de clases, como también especialmente cuando se quiere visualizar el tipo de una instancia.

Estos diagramas de clase son muy útiles ya que de aquí podemos sacar directamente el código fuente para varias plataformas en las que queramos implementar nuestro sistema, esto es con la ingeniería hacia adelante; o bien, podemos tomar un código fuente que ya este programado, y posteriormente importarlo en un programa que maneje UML, y de esta manera creara el diagrama de clases desde el código, a esto se le llama ingeniería inversa.



Ingeniería hacia adelante.

Es el proceso de transformar un modelo en código a un mapeo en un lenguaje de implementación. La ingeniería hacia adelante resulta en una pérdida de información, porque el modelo escrito UML es semánticamente más rico que cualquier lenguaje de programación orientado a objetos. De hecho esta es una mayor razón por lo que es necesario modelar en adición al código. Características estructurales tales como colaboraciones, y características de comportamiento tales como interacciones pueden ser visualizadas claramente en UML , pero no son tan claras para un línea de código.

Ingeniería inversa.

Es el proceso de transformar código en un modelo a un mapeo de la especificación del lenguaje de implementación. La ingeniería inversa es resultado de la abundancia de información, algo de lo cual está en un nivel bajo de detalle que se necesita para construir modelos útiles. En algún momento la ingeniería inversa es incompleta. Esto trae pérdida de información de los modelos de la ingeniería hacia adelante al código, y también cuando no se puede recrear completamente un modelo de código a menos que las herramientas dosifiquen información en la fuente de comentarios semánticamente más allá del lenguaje de implementación.

Hay algo que quieras aportar? Siéntete libre de comentar

jueves, 26 de noviembre de 2009

Diagramas de Secuencia UML

Siguiendo con la utilización de UML para el diseño de Sistemas de Información, ahora explicaremos otro de los diagramas más usados y que además es muy práctico, ya que con él se puede representar de manera más clara cuál es la función que desempeñara el sistema que vamos a realizar y que es necesario cumplir en cada caso para que el sistema funcione correctamente.

El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso. Mientras que el diagrama de caso de uso permite el modelado de una vista 'business' del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos.

Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si tienes modelada la descripción de cada caso de uso como una secuencia de varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos.

Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como vectores horizontales. Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria.



Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado, o invocado, pertenece a la definición de la case instanciada por el objeto en la recepción final del mensaje.

Te pareció útil la información? Deja un comentario por favor aportando tus experiencias, muchas gracias.

UML como herramienta para la creación de Sistemas de Información

UML es una especificación de notación orientada a objetos. Divide cada proyecto en un número de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los que representa la arquitectura del proyecto.

Con UML nos debemos olvidar del protagonismo excesivo que se le da al diagrama de clases, este representa una parte importante del sistema, pero solo representa una vista estática, es decir muestra al sistema parado. Sabemos su estructura pero no sabemos que le sucede a sus diferentes partes cuando el sistema empieza a funcionar. UML introduce nuevos diagramas que representa una visión dinámica del sistema. Es decir, gracias al diseño de la parte dinámica del sistema podemos darnos cuenta en la fase de diseño de problemas de la estructura al propagar errores o de las partes que necesitan ser sincronizadas, así como del estado de cada una de las instancias en cada momento. El diagrama de clases continua siendo muy importante, pero se debe tener en cuenta que su representación es limitada, y que ayuda a diseñar un sistema robusto con partes reutilizables, pero no a solucionar problemas de propagación de mensajes ni de sincronización o recuperación ante estados de error. En resumen, un sistema debe estar bien diseñado, pero también debe funcionar bien.

Como se menciona anteriormente el diagrama que mas es utilizado es el diagrama de clases, así que se explicara a continuación:

Los diagramas de clases se emplean para visualizar el comportamiento del sistema, una parte de el o de una sola clase. De forma que se pueda conocer como responde esa parte del sistema. El diagrama de uso es muy útil para definir como debería ser el comportamiento de una parte del sistema, ya que solo especifica como deben comportarse y no como están implementadas las partes que define. Por ello es un buen sistema de documentar partes del código que deban ser reutilizables por otros desarrolladores. El diagrama también puede ser utilizado para que los expertos de dominio se comuniquen con los informáticos sin llegar a niveles de complejidad. Un caso de uso especifica un requerimiento funcional, es decir indica esta parte debe hacer esto cuando pase esto.

En el diagrama nos encontramos con diferentes figuras que pueden mantener diversas relaciones entre ellas:

Casos de uso: representado por una elipse, cada caso de uso contiene un nombre, que indique su funcionalidad. Los casos de uso pueden tener relaciones con otros caso de uso. Sus relaciones son:

Include: Representado por una flecha, en el diagrama de ejemplo podemos ver como un caso de uso, el de totalizar el coste incluye a dos casos de uso.

Extends: Una relación de una caso de Uso A hacia un caso de uso B indica que el caso de uso B implementa la funcionalidad del caso de uso A.

Generalization: Es la típica relación de herencia.

Actores: se representan por un muñeco. Sus relaciones son:

Communicates: Comunica un actor con un caso de uso, o con otro actor.

Parte del sistema (System boundary): Representado por un cuadro, identifica las diferentes partes del sistema y contiene los casos de uso que la forman.






En este grafico encontramos tres casos de usos Crear producto utiliza Validar producto, y Crear pack productos es una especialización de Crear productos.

Podemos emplear el diagrama de dos formas diferentes, para modelar el contexto de un sistema, y para modelar los requisitos del sistema

lunes, 17 de agosto de 2009

Sistemas de informacion: Ciclo de vida

En este blog hablaremos de lo que se conoce como Sistemas de Informacion.

Que es lo que son?

Un sistema de informacion es un conjunto de elementos que interactuan entre si, y obtienen, almacenan, procesan y dan informacion a una empresa a cerca de las actividades que desea realizar.

En la actualidad, los sistemas de información son el motor de las actividades y lo principal para la toma de decisiones en las empresas.

El ciclo de vida basico para el desarrollo de sistemas es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información. Consta de 6 fases:

1). Investigación Preliminar: Para poder realizar la peticion de un sistema de informacion, primeramente una persona debe de investigar la situacion que se desea plantear.

2). Determinación de los requerimientos del sistema: Se debe comprender a la perfeccion todas las partes que colaboraran con el sistema. Los analistas deben de buscar los requerimientos basandose en las siguientes preguntas como base:

- ¿Qué es lo que hace?
- ¿Cómo se hace?
- ¿Con que frecuencia se presenta?
- ¿Qué tan grande es el volumen de transacciones o decisiones?
- ¿Cuál es el grado de eficiencia con el que se efectúan las tareas?
- ¿Existe algún problema? ¿Qué tan serio es? ¿Cuál es la causa que lo origina?

3). Diseño del sistema: Aqui decidimos como cumpliremos con los requerimientos que se vieron en la fase de análisis.

4). Desarrollo del software: Los desarrolladores de software pueden hacerlo tratando de abarcar un publico en general o haciendo un software a la medida. Esto depende del tiempo que se tena para terminarlo y la disponibilidad de los programadores.

5). Prueba de sistemas: Aqui se hacen las pruebas del sistema para corregir las fallas, esto se logra dandole datos de prueba para su procesamiento y examinando los resultados que nos arroja.

6). Implantación y evaluación: La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos años.

Deseas aportar mas a esta entrada? sientete libre de comentar y aportar algo más, con esto concluye la informacion basica del ciclo de vida de un sistema de información.