UML (LENGUAJE UNIFICADO DE MODELADO UML)

 

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.

UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.

 Antes de UML 1.x

Después de que la Rational Software Corporation contratara a James Rumbaugh de General Electric en 1994, la compañía se convirtió en la fuente de los dos esquemas de modelado orientado a objetos más populares de la época: el OMT (Object-modeling technique) de Rumbaugh, que era mejor para análisis orientado a objetos, y el Método Booch de Grady Booch, que era mejor para el diseño orientado a objetos. Poco después se les unió Ivar Jacobson, el creador del método de ingenieríá de software orientado a objetos. Jacobson se unió a Rational en 1995, después de que su compañía Objectory AB fuera comprada por Rational. Los tres metodologistas eran conocidos como los Tres Amigos, porque se sabia de sus constantes argumentos sobre las prácticas metodológicas.

En 1996 Rational concluyó que la abundancia de lenguajes de modelado estaba alentando la adopción de la tecnología de objetos, y para orientarse hacia un método unificado, encargaron a los Tres Amigos que desarrollaran un Lenguaje Unificado de Modelado abierto. Se consultó con representantes de compañías competidoras en el área de la tecnología de objetos durante la OOPSLA '96; eligieron cajas para representar clases en lugar de la notación de Booch que utilizaba símbolos de nubes.

Bajo la dirección técnica de los Tres Amigos fue organizado un consorcio internacional llamado UML Partners en 1996 para completar las especificaciones del Lenguaje Unificado de Modelado (UML), y para proponerlo como una respuesta al OMG RFP. El borrador de la especificación UML 1.0 de UML Partners fue propuesto a la OMG en enero de 1997. Durante el mismo mes la UML Partners formó una Fuerza de Tarea Semántica, encabezada por Cris Kobryn y administrada por Ed Eykholt, para finalizar las semánticas de la especificación y para integrarla con otros esfuerzos de estandarización. El resultado de este trabajo, el UML 1.1, fue presentado ante la OMG en agosto de 1997 y adoptado por la OMG en noviembre de 1997.

UML 1.x

Como notación de modelado, la influencia de la OMT domina UML (por ejemplo el uso de rectángulos para clases y objetos). Aunque se quitó la notación de "nubes" de Booch, si se adoptó la capacidad de Booch para especificar detalles de diseño en los niveles inferiores. La notación de Casos de Uso del Objectory y la notación de componentes de Booch fueron integrados al resto de la notación, pero la integración semántica era relativamente débil en UML 1.1, y no se arregló realmente hasta la revisión mayor de UML 2.0.

Conceptos de muchos otros métodos OO fueron integrados superficialmente en UML con el propósito de hacerlo compatible con todos los métodos OO. Además el grupo tomó en cuenta muchos otros métodos de la época, con el objetivo de asegurar amplia cobertura en el dominio de los sistemas en tiempo real. Como resultado, UML es útil en una variedad de problemas de ingeniería, desde procesos sencillos y aplicaciones de un sólo usuario a sistemas concurrentes y distribuidos.

MODELOS DE CICLO DE VIDA

En los años 70 se impuso un nuevo enfoque de desarrollo del software, introducido por Royce en 1970, a través de un ciclo de vida en “cascada” (así denominado por la disposición de las distintas fases de desarrollo, en las que los resultados de una fase parecen caer en cascada hacia la siguiente fase, tal como se muestra en la Figura 1). El método ideado por Royce constituye uno de los primeros modelos de ciclo de vida publicados, por lo que también recibe el nombre de modelo de ciclo de vida clásico. Este método modela el ciclo convencional de la Ingeniería del Software, aplicando un enfoque sistemático y secuencial de desarrollo que comienza con la ingeniería del sistema y progresa a través del análisis, diseño, codificación, pruebas y mantenimiento.

Ventajas:

• Es un modelo sencillo y disciplinado
• Es fácil aprender a utilizarlo y comprender su funcionamiento
• Está dirigido por los tipos de documentos y resultados que deben obtenerse al final de cada etapa
• Ha sido muy usado y, por tanto, está ampliamente contrastado
• Ayuda a detectar errores en las primeras etapas a bajo costo
• Ayuda a minimizar los gastos de planificación, pues se realiza sin problemas

Desventajas:

• Los proyectos raramente siguen el proceso lineal tal como se definía originalmente el ciclo de vida
• Es difícil que el cliente exponga explícitamente todos los requisitos al principio
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• No refleja exactamente cómo se programa realmente el sistema, en el que suele haber un gran componente iterativo
• Puede resultar complicado regresar a etapas anteriores (ya acabadas) para realizar correcciones
• El producto final obtenido puede que no refleje todos los requisitos del usuario

 

El modelo en V es una variación del modelo en cascada que muestra cómo se relacionan las actividades de prueba con el análisis y el diseño. Como se muestra en la Figura 3, la codificación forma el vértice de la V, con el análisis y el diseño a la izquierda y las pruebas y el mantenimiento a la derecha.

Figura 3 Modelo de Ciclo de Vida en V
La unión mediante líneas discontinuas entre las fases de la parte izquierda y las pruebas de la derecha representa una doble información. Por un lado sirve para indicar en qué fase de desarrollo se deben definir las pruebas correspondientes. Por otro sirve para saber a qué fase de desarrollo hay que volver si se encuentran fallos en las pruebas correspondientes.
Por lo tanto el modelo en V hace más explícita parte de las iteraciones y repeticiones de trabajo que están ocultas en el modelo en cascada. Mientras el foco del modelo en cascada se sitúa en los documentos y productos desarrollados, el modelo en V se centra en las actividades y la corrección.
Ventajas y desventajas  del Modelo en “V”

Ventajas:
• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos.
• Es un modelo sencillo y de fácil aprendizaje
• Hace explícito parte de la iteración y trabajo que hay que revisar
• Especifica bien los roles de los distintos tipos de pruebas a realizar
• Involucra al usuario en las pruebas

Desventajas:

• Es difícil que el cliente exponga explícitamente todos los requisitos
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas
• El producto final obtenido puede que no refleje todos los requisitos del usuario

INGENIERIA DE SISTEMAS

La ingeniería de sistemas es la aplicación de las ciencias matemáticas y físicas para desarrollar sistemas que utilicen económicamente los materiales y fuerzas de la naturaleza para el beneficio de la humanidad.

Una definición especialmente completa -y que data de 1974- nos la ofrece un estándar militar de las fuerzas aéreas estadounidenses sobre gestión de la ingeniería (MIL-STD-499B Systems Engineering).

Ingeniería de sistemas es la aplicación de esfuerzos científicos y de ingeniería para:

• transformar una necesidad de operación en una descripción de parámetros de rendimiento del sistema y una configuración del sistema a través del uso de un proceso interactivo de definición, síntesis, análisis, diseño, prueba y evaluación;

• integrar parámetros técnicos relacionados para asegurar la compatibilidad de todas las interfaces de programa y funcionales de manera que optimice la definición y diseño del sistema total

•  integrarse factores de fiabilidad, mantenibilidad, seguridad, supervivencia, humanos y otros en el esfuerzo de ingeniería total a fin de cumplir los objetivos de coste, planificación y rendimiento técnico.                                                                                                                                                                                               

Historia  

Esta área comenzó a desarrollarse en la segunda parte del siglo XX con el veloz avance de la ciencia de sistemas. Las empresas comenzaron a tener una creciente aceptación de que la ingeniería de sistemas podía gestionar el comportamiento impredecible y la aparición de características imprevistas de los sistemas (propiedades emergentes). Las decisiones tomadas al comienzo de un proyecto, cuyas consecuencias pueden no haber sido entendidas claramente, tienen una enorme implicación más adelante en la vida del sistema. Un ingeniero de sistemas debe explorar estas cuestiones y tomar decisiones críticas. No hay métodos que garanticen que las decisiones tomadas hoy serán válidas cuando el sistema entre en servicio años o décadas después de ser concebido, pero hay metodologías que ayudan al proceso de toma de decisiones. Ejemplos como la metodología de sistemas blandos (Soft Systems Methodology), la dinámica de sistemas, modelo de sistemas viables (Viable System Model), teoría del Caos, teoría de la complejidad, y otros que también están siendo explorados, evaluados y desarrollados para apoyar al ingeniero en el proceso de toma de decisiones que se puede llegar a ser por medio del CENAL.   

CICLO DE VIDA DE UN SISTEMA DE INFORMACION

El ciclo de vida de un sistema de información es un enfoque por fases del análisis y diseño que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo especifico de actividades del analista y del usuario.

Según James Senn, existen tres estrategias para el desarrollo de sistemas: el método clásico del ciclo de vida de desarrollo de sistemas, el método de desarrollo por análisis estructurado y el método de construcción de prototipos de sistemas. Cada una de estas estrategias tienen un uso amplio en cada una de los diversos tipos de empresas que existen, y resultan efectivas si son aplicadas de manera adecuada. 

En la actualidad para muchas organizaciones, los sistemas de información basados en computadoras son el corazón de las actividades cotidianas y objeto de gran consideración en la toma de decisiones, las empresas consideran con mucho cuidados las capacidades de sus sistemas de información cuando deciden ingresar o no en nuevos mercados o cuando planean la respuesta que darán a la competencia.

Al establecer los sistemas de información basados en computadoras deben tener la certeza de que se logren dos objetivos principales: que sea un sistema correcto y que este correcto el sistema. Ningún sistema que deje satisfacer ambos objetivos será completamente útil para la gerencia u organización.

Si los dispositivos de un sistema de información no se adaptan a su población de clientes, no lograra sus objetivos potenciales. A mismo tiempo, aun cuando se identifiquen precisamente las necesidades del usuario, un sistema de información va tener un valor único si funciona en forma adecuada.

Los informes y las salidas producidas por el sistema deben ser precisos, confiables y completos. La función del Análisis puede ser dar soporte a las actividades de un negocio, o desarrollar un producto que pueda venderse para generar beneficios.

Es el Proceso de gestión para la creación de un Sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimación, estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre.

Aunque la estimación, es más un arte que una Ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen técnicas útiles para la estimación de costes de tiempo. Y dado que la estimación es la base de todas las demás actividades de planificación del proyecto y sirve como guía para una buena Ingeniería Sistemas y Software.

Al estimar tomamos en cuenta no solo del procedimiento técnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificación. El Tamaño del proyecto es otro factor importante que puede afectar la precisión de las estimaciones.

A medida que el tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del Software. La disponibilidad de información Histórica es otro elemento que determina el riesgo de la estimación.

CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS

 El método de ciclo de vida 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. El método del ciclo de vida para el desarrollo de sistemas consta de 6 fases:

1). Investigación Preliminar: La solicitud para recibir ayuda de un sistema de información puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la petición de una persona.

2). Determinación de los requerimientos del sistema: El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave:

¿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: El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo del software, a la que denominan diseño físico.

4). Desarrollo del software: Los encargados de desarrollar software pueden instalar software comprobando a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores.

Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.

5). Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga.

Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados.

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. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses.

Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones. La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:

*Evaluación operacional: Valoración de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información, confiabilidad global y nivel de utilización.

*Impacto organizacional: Identificación y medición de los beneficios para la organización en áreas tales como finanzas, eficiencia operacional e impacto competitivo. También se incluye el impacto sobre el flujo de información externo e interno.

*Opinión de loa administradores: evaluación de las actividades de directivos y administradores dentro de la organización así como de los usuarios finales.

*Desempeño del desarrollo: La evaluación de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estándares, y otros criterios de administración de proyectos. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo.