Monografias.com > Computación > Programación
Descargar Imprimir Comentar Ver trabajos relacionados

El desarrollo de sistemas de información empleando el lenguaje de modelado unificado UML



    1. Resumen
    2. La Ingeniería de
      Software
    3. La complejidad del
      Software
    4. Principios de
      Modelado
    5. El Lenguaje de Modelado
      Unificado UML
    6. El proceso Unificado de
      Modelado (RUP)
    7. Diagramas de
      UML
    8. Conclusiones
    9. Bibliografía

    Resumen.

    El presente artículo describe la evolución de las notaciones que dieron
    lugar a UML (Lenguaje de
    Modelado Unificado), detalla ampliamente sobre el surgimiento de
    la Ingeniería del Software, expone los
    principios de
    modelado en que se fundamenta la notación de UML, asimismo
    muestra y
    explica como el UML adopta el RUP(Proceso
    Unificado de Desarrollo) para modelar las actividades de un
    proyecto.
    Finalmente se propone la
    organización de los diagramas a
    utilizar en las diferentes etapas del desarrollo de los sistemas de
    información.

    1. Introducción.

    A lo largo de los años, el desarrollo de los
    proyectos de
    software causan bastantes confusiones y malas interpretaciones en
    los requerimientos de los clientes y
    usuarios, en parte debido a la abundancia de notaciones,
    metodologías y conceptos que hace que los desarrolladores
    de sistemas no se pongan de acuerdo en que es lo que realmente
    están elaborando. En un esfuerzo para estándarizar
    las notaciones y procesos a
    utilizar, se conformó un consorcio liderado por la empresa
    Rational y por las principales empresas del
    mundo de la industria de
    la informática, entre ellas, Microsoft,
    Oracle, Sun
    Microsystems, Intellicorp, IBM, AMD y otras, quienes
    desarrollaron una notación llamada UML y el proceso de
    desarrollo RUP.

    2. La Ingeniería de
    Software.

    La ingeniería del Software nace como una disciplina
    para aplicar los principios técnicas y
    herramientas
    de desarrollo de software, surgió porque todos los
    desarrolladores en la década de los 80’s, realizaban
    el software de forma artística, es decir utilizando
    métodos y
    técnicas adhoc donde la experiencia (el
    ensayo-error) era el camino a seguir. Este enfoque produjo
    grandes y exitosos productos de
    programación pero conforme los proyectos se
    volvieron más complejos debido al avance del hardware y software y la
    penetración cada vez mayor de la informática en
    todos los ámbitos de la sociedad,
    llevó a que se produjera software sin calidad, se
    incumplieran los presupuestos y
    se incrementara dramáticamente los costos de
    mantenimiento.

    La solución propuesta fue aplicar métodos
    y principios que han sido utilizados y probados en la experiencia
    de desarrollo de software para producir de forma
    inequívoca productos que corran eficientemente y se
    ejecuten sobre máquinas
    reales. En la década de los 70 surgieron una gran variedad
    de metologistas y metodologías entre ellos se destacan
    Yourdon y Demarco cuyas investigaciones
    se basaban en los principios de la programación
    estructurada. En los 80’s y 90’s el paradigma
    estructurado evolucionó hacia el paradigma orientado a
    objetos, en el período de 1989 y 1994 se creó la
    llamada guerra de
    métodos dentro de la comunidad
    orientada a objetos existiendo un incremento de menos de diez a
    más de cincuenta metodologías, es así que
    los desarrolladores de software quedaron muy confundidos sin
    saber cual era la metodología más adecuada para
    elaborar sus proyectos.

    Ante lo enunciado, el UML oficialmente se
    presentó cuando Rumbaugh, Booch y Jacobson unifican sus
    estudios con una semántica y notación, para lograr
    compatibilidad en el análisis y diseño
    orientado a objetos, permitiendo que los proyectos se asentaran
    en un lenguaje de modelado maduro, permitiendo a los
    constructores de herramientas enfocarse en producir
    características más útiles.

    3. La complejidad
    del Software.

    Al observar sistemas complejos sociales como una gran
    empresa, los
    naturales como el universo y los
    sistemas creados por el hombre como
    el computador, se
    observa que exhiben una jerarquía de clases (conceptos) y
    otra de objetos (instancias). En una empresa donde
    conjuntos de
    personas forman un departamento y un conjunto de departamentos
    forman divisiones se describe la forma canónica de un
    sistema complejo
    que exhibe dos jerarquías: Una jerarquía de clases
    y otra jerarquía de objetos, donde cada objeto es una
    instancia de la una clase. Este es
    el modelo del
    cual se apropia el análisis y diseño orientado a
    objetos para desarrollar sistemas donde hay gran cantidad de
    software.

    Figura 1.

    Forma Canónica de un Sistema
    Complejo

    4. Principios de
    Modelado

    En cualquier proyecto de ingeniería como la
    construcción de un gran edificio, un
    avión, una represa hidroeléctrica, la
    construcción de un procesador de
    textos o un software de comunicaciones
    para Internet,
    requieren de etapas de modelamiento que permitan experimentar y
    visualizar el sistema que se construirá. De la experiencia
    en ingeniería se extractan los siguientes principios de
    modelado:

    a) La forma como vemos el problema tiene una profunda
    influencia en forma como acometemos el problema y le damos
    solución al mismo
    .

    Si pensamos que el mundo esta compuesto de clases
    (Abstracciones de la realidad y de la solución del
    problema) y objetos (instancias de éstas abstracciones)
    que interactúan entre si para realizar una funcionalidad,
    así veremos el mundo. Este es precisamente al paradigma a
    que le apuesta UML: el modelo orientado a objetos. Si vemos la
    realidad como compuesta de procesos donde cada uno a su vez se
    puede descomponer en subprocesos entonces estamos concibiendo la
    realidad según el modelo estructurado y la arquitectura del
    sistema en desarrollo estará conformada de programas y
    subprogramas.

    b) Para modelar un sistema complejo no es suficiente
    un único modelo se requieren múltiples modelos donde
    cada uno representa una vista (aspecto) del sistema; estos
    modelos se complementan entre si.

    Esta es la razón de la existencia de varios
    diagramas en UML que modelan diferentes aspectos del sistema,
    desde las vistas lógicas y físicas del sistema
    hasta los aspectos dinámicos, estáticos y
    funcionales del mismo.

    c) Cualquier modelo puede ser representado con
    diferentes grados de precisión
    .

    La precisión se puede ver desde dos
    ópticas: La primera es el grado de detalle con que se
    representa un modelo; por ejemplo, si lo que se desea es razonar
    acerca de los requerimientos del sistema con un cliente o usuario
    final, se puede elaborar un diagrama de
    clases que muestra las clases, sus atributos y operaciones
    así como varios adornos(multiplicidad) en las relaciones;
    por otro lado, si lo que se desea es transmitir el diagrama de
    clases para que sea implementado en un DBMS (Data Base Management
    System, Sistema Administrador de
    Bases de
    Datos) por un programador, el diagrama con toda seguridad
    contendrá la visibilidad de las características
    (atributos y operaciones) de las clases, los tipos de datos de
    los atributos y las signaturas de las métodos de las
    clases.

    La segunda forma de ver la precisión de un modelo
    se refiere al nivel de abstracción, ese decir, a los
    detalles y la vista (porción del sistema o realidad) que
    presenta un modelo al lector; por ejemplo, en un sistema Bancario
    que maneja los retiros que hacen los clientes ya sea en un cajero
    automático o humano, el diagrama de clases contiene
    decenas de éstas; sin embargo las personas encargadas de
    desarrollar la interfaz de un cajero electrónico
    estarían interesadas en las clases necesarias para
    realizar el comportamiento
    del cajero y omiten el resto de clases del sistema.

    d) Los mejores Modelos están ligados a la
    realidad.

    El símbolo de un actor en un diagrama de casos de
    uso representa, de hecho, un actor en el sistema real; así
    como un componente en un diagrama de componentes representa un
    componente físico del software. Cada elemento de UML como
    una clase, objeto, estado,
    componente o nodo tiene su correspondencia con algún
    elemento conceptual o físico del mundo real.

    5. El Lenguaje de
    Modelado Unificado UML.

    "El Lenguaje de Modelado Unificado UML es un lenguaje
    estándar para escribir planos de software. UML puede
    utilizarse para visualizar, especificar, construir y documentar
    los artefactos de un sistema que involucra gran cantidad de
    software"

    El UML es el Lenguaje de Modelado Unificado Orientado a
    Objetos, UML no es un método
    porque no tiene noción de proceso el cual es una parte
    importante de un método.
    Ahora bien si UML no es
    método; entonces ¿Cuáles son las etapas a
    seguir en el desarrollo de sistemas con UML?
    , varios
    especialistas en desarrollo de sistemas de información
    arguyen de que existe la necesidad de adoptar un Proceso de
    Desarrollo de sistemas para enmarcar las fases importantes que
    sigue el UML, por ello los desarrolladores de proyectos de
    sistemas de información emplean el Procesos
    Unificado
    para dar soluciones
    adecuadas a las necesidades de los clientes.

    El desarrollo de sistemas con UML siguiendo el proceso
    unificado incluye actividades específicas, cada una de
    ellas a su vez contienen otras subactividades las cuales sirven
    como una guía de cómo deben ser las actividades
    desarrolladas y secuenciadas con el fin de obtener sistemas
    exitosos; consecuentemente el desarrollo de los sistemas puede
    variar de desarrollador en desarrollador, de proyecto en
    proyecto, de empresa en empresa adoptando siempre un Proceso de
    Desarrollo.

    6. El proceso
    Unificado de Modelado (RUP).

    A través de la historia se han desarrollado
    varios modelos de proceso de software (paradigmas de
    desarrollo) cada uno con sus ventajas, desventajas y utilidad en
    algunos tipos de proyectos y problemas. Al
    igual que cualquier notación, el proceso unificado
    actúa como un modelo que puede adaptarse a cualquier tipo
    de proyecto y empresa (grandes y pequeñas). Las
    características del proceso unificado de modelado
    son:

    • Centrado en los Modelos: Los diagramas son un
      vehículo de comunicación más expresivo que las
      descripciones en lenguaje natural. Se trata de minimizar el uso
      de descripciones y especificaciones textuales del
      sistema.
    • Guiado por lo casos de uso: Los casos de uso
      son el instrumento para validar la arquitectura del software y
      extraer los casos de prueba.
    • Centrado en la arquitectura: Los modelos son
      proyecciones del análisis y el diseño constituye
      la arquitectura del producto a
      desarrollar.
    • Iterativo e incremental: Durante todo el
      proceso de desarrollo se producen versiones incrementales (que
      se acercan al producto terminado) del producto en
      desarrollo.

    Figura 2.

    El Proceso de Modelado
    Unificado

    El gráfico que representa el RUP incluye las
    cuatro etapas importantes que son: la iniciación,
    elaboración, construcción y transición, las
    cuales muestran que para producir una versión del producto
    en desarrollo se aplican todas las actividades de
    ingeniería pero con diferente énfasis; en las
    versiones preliminares, como además indica la
    intuición, hay más énfasis en actividades de
    modelado del negocio, requisitos, análisis y
    diseño; conforme se producen versiones el énfasis
    pasa a las actividades de implementación, pruebas y
    despliegue.

    8. Diagramas
    de UML.

    Los elementos de UML se muestran mediante diagramas que
    presentan múltiples vistas del sistema, ese conjunto de
    vistas son conocidos como modelos.

    UML presenta varios diagramas donde cada uno representa
    un aspecto del sistema. De ahí que varios investigadores
    según sus criterios y puntos de vista mencionan qué
    diagramas emplear en el desarrollo de los sistemas de
    información; sin mencionar cuáles son los diagramas
    más adecuados en las distintas etapas de desarrollo del
    Proceso Unificado, viendo esta necesidad, la autora del presente
    artículo propone un conjunto de diagramas necesarios para
    cada etapa según la complejidad del sistema de
    información a solucionar.

    Dado un sistema a desarrollar no es necesario emplear
    todos los diagramas; para sistemas sencillos un diagrama de
    clases junto con un par de diagramas de actividades e interacción sería suficiente,
    asimismo si los sistemas son complejos requieren de la
    utilización de más diagramas, debido a que
    requieren de etapas incrementales e iterativas(ciclos de
    desarrollo) en el análisis, diseño e
    implementación, por ello es que el conjunto actividades
    deberá especificar la etapa de desarrollo y los diagramas
    recomendados como muestra la siguiente figura:

    Figura 3.

    Para ver el gráfico seleccione la
    opción "Descargar" del menú
    superior 

    Diagramas recomendados en el
    desarrollo de los sistemas de información

    9.
    Conclusiones.

    El lenguaje Unificado de modelado UML es una
    notación que es el resultado de la evolución de las
    notaciones previas en ingeniería de software, toma los
    aspectos fuertes de tres metodologías anteriores: OMT,
    Booch y OOSE.

    La notación UML se fundamenta en principios de
    modelado, lo cual es importante para toda implementación
    de un sistema de información.

    El UML debe adoptar el Proceso Unificado de Desarrollo
    para modelar las actividades de un proyecto.

    Los diagramas a utilizar en las diferentes etapas del
    desarrollo de los sistemas de información, pueden variar
    dependiendo del tamaño y tipo de sistema, por lo que es
    necesario organizarlos según las fases del Proceso
    Unificado.

    BIBLIOGRAFÍA

    1. BARRIENTOS Aleida Proceso Metodológico de
      Auditoría
      Informática aplicado a la evaluación y seguimiento de Sistemas de
      Gestión desarrollados con el
      estándar de modelado UML
      , Tesis de
      Maestría en Ingeniería Informática,
      Universidad
      de Oriente La Habana Cuba
      Universidad Autónoma Tomás Frías,
      Potosí-Bolivia,
      2002.
    2. BOOCH Grady et al. El lenguaje Unificado de
      Modelado
      , Primera Edición, Editorial Addison Wesley,
      1999.
    3. LARMAN Craig UML y Patrones Una
      introducción al Análisis y Diseño
      Orientado a Objetos y al Proceso Unificado
      , Segunda
      Edición, Editorial Prentice Hall, 2002.
    4. JACOBSON Ivar et al. El Proceso Unificado de
      Modelado
      , Primera Edición, Editorial Addison Wesley,
      1999.
    5. RUMBAUGH James Modelado y Diseño Orientado
      a Objetos con OMT,
      Primera Edición, Editorial
      Addison Wesley, 1998

      

    Por:

    Aleida Mirian Barrientos
    Enríquez

    Licenciada en Informática

    Magíster en Ingeniería
    Informática

    Magíster en Educación Superior

    Potosí-Bolivia

    Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

    Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

    Categorias
    Newsletter