Uml (UnifiedModelingLanguage) antecedentes



Descargar 165,9 Kb.
Fecha de conversión17.09.2017
Tamaño165,9 Kb.

Analisis y Diseño II Ing. Nela Benavides Ignacio


TEMA 4
UML (UnifiedModelingLanguage)

 

ANTECEDENTES.-


Desde que Simula 67 introdujera el concepto de clase y herencia los lenguajes OO han experimentado una rápida e intensa evolución para acercarse a la realidad que la empresa les reclama. Pero no es hasta los inicios de la década de los 90 cuando realmente existe un intento serio de normalizar la metodología OO.
•El Dr. James Rumbaugh en 1991 con Michael Blaha, William Premerlani, Frederick Eddy y William Lorensen desarrollan "ObjectOrientedModeling and Design"  introduciendo OMT (ObjectModelingTechnique) que él mismo define como "una metodología orientada a objetos para el desarrollo de software". •El Dr. Ivar Jacobson en 1992 desarrolla el método OOSE (ObjectOrinted Software Engineer), donde introduce el concepto "use case". •Grady Booch en 1993 crea la metodología "Booch '93". •J. Rumbaugh y G. Booch en el año 1994 se unen en una empresa común (de objetivos y de negocio) Rational Software Corporation donde unifican sus dos métodos. •Un año después y como fruto de dicha unión aparece en octubre del 95 UML 0.8 (UnifiedModelingLanguage). •A finales de ese mismo año se une al grupo I.

Jacobson.




DR. Ivar Jacobson





Grady Booch




• En junio del 96 los tres padres de UML depositan las especificaciones de UML 0.9  en el enlace  http://www.rational.com/uml  de Rational. Este hecho produce una cascada de adhesiones que en pocos meses, concretamente en enero del 97,  va a permitir la creación  de UML 1.0. Por fín se consigue un modelo totalmente unificado


PARTICIPANTES EN UML 1.0

Rational Software (Grady Booch, Jim Rumbaugh y Ivar Jacobson)

Digital Equipment

Hewlett-Packard

i-Logix (David Harel)

IBM

ICON Computing (Desmond D’Souza)



Intellicorp and James

Martin & co. (James Odell)

MCI Systemhouse

Microsoft ObjecTime

Platinium Technology

Sterling Software

Taskon

Texas Instruments



Unisys
Microsoft  con Active X/COM y Componentes 

Oracle con ORDBMS

•En noviembre del 97 UML es aceptado  como estándar por OMG (Object Management Group), después de ser admitidas algunas de sus sugerencias, como el modelado de negocios. Uno de los requisitos exigidos es que UML no fuese propiedad de nadie. Rational comercializa una herramienta CASE sin derechos sobre UML.

CONCEPTO DE UML ( UnifiedModelingLanguage)

UML [UML] es un lenguaje para especificar, construir, visualizar y documentar los artefactos de un sistema de software orientado a objetos (OO). Un artefacto es una información que es utilizada o producida mediante un proceso de desarrollo de software.


UML se quiere convertir en un lenguaje estándar con el que sea posible modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo: no pretende definir un modelo estándar de desarrollo, sino únicamente un lenguaje de modelado. Otros métodos de modelaje como OMT (ObjectModelingTechnique) o Booch sí definen procesos concretos. En UML los procesos de desarrollo son diferentes según los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una aplicación en tiempo real, que el proceso de desarrollo de una aplicación orientada a gestión, por poner un ejemplo.
Las diferencias son muy marcadas y afectan a todas las faces del proceso. El método del UML recomienda utilizar los procesos que otras metodologías tienen definidos.
Un lenguaje de propósito general para el modelado orientado a objetos

Documento “OMG Unified Modeling Language Specification”

UML combina notaciones provenientes desde:

• Modelado Orientado a Objetos

• Modelado de Datos

Modelado de Componentes

• Modelado de Flujos de Trabajo (Workflows)
OBJETIVOS DELUML

El objetivo es conseguir un modelo unificado, abierto, que siga evolucionando en conjunto y no por separado tal como estaba ocurriendo hasta ahora, comprensible por el hombre, utilizable por la máquina y fundamentalmente con la capacidad de unificar las perspectivas de diferentes sistemas (tanto de software como de negocio).


Como otros objetivos principales de la consecución de un nuevo método que aunara los mejores aspectos de sus predecesores, sus protagonistas se propusieron lo siguiente:

  • El método debía ser capaz de modelar no sólo sistemas de software sino otro tipo de sistemas reales de la empresa, siempre utilizando los conceptos de la orientación a objetos (OO).

  • Establecer una notación estándar

  • Crear un lenguaje para modelado utilizable a la vez por máquinas y por personas.

  • Establecer un acoplamiento explícito de los conceptos y los artefactos ejecutables.

  • Manejar los problemas típicos de los sistemas complejos de misión crítica.

Lo que se intenta es lograr con esto que los lenguajes que se aplican siguiendo los métodos más utilizados sigan evolucionando en conjunto y no por separado. Y además, unificar las perspectivas entre diferentes tipos de sistemas (no sólo software, sino también en el ámbito de los negocios), al aclarar las fases de desarrollo, los requerimientos de análisis, el diseño, la implementación y los conceptos internos de la OO.
MODELADO DE OBJETOS
En la especificación del UML podemos comprobar que una de las partes que lo componen es un metamodelo formal. Un metamodelo es un modelo que define el lenguaje para expresar otros modelos. Un modelo en OO es una abstracción cerrada semánticamente de un sistema y un sistema es una colección de unidades conectadas que son organizadas para realizar un propósito específico. Un sistema puede ser descripto por uno o más modelos, posiblemente desde distintos puntos de vista.
Una parte del UML define, entonces, una abstracción con significado de un lenguaje para expresar otros modelos (es decir, otras abstracciones de un sistema, o conjunto de unidades conectadas que se organizan para conseguir un propósito). Lo que en principio puede parecer complicado no lo es tanto si pensamos que uno de los objetivos del UML es llegar a convertirse en una manera de definir modelos, no sólo establecer una forma de modelo, de esta forma simplemente estamos diciendo que UML, además, define un lenguaje con el que podemos abstraer cualquier tipo de modelo.
UML utiliza parte de este planteamiento obteniendo distintos puntos de vista de la realidad que modela mediante los distintos tipos de diagramas que posee. Con la creación del UML se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo de sistema, sea informático o no, mediante los diagramas, es decir, mediante representaciones gráficas que contienen toda la información relevante del sistema. Un diagrama es una representación gráfica de una colección de elementos del modelo, que habitualmente toma forma de grafo donde los arcos que conectan sus vértices son las relaciones entre los objetos y los vértices se corresponden con los elementos del modelo. Los distintos puntos de vista de un sistema real que se quieren representar para obtener el modelo se dibuja dé forma que se resaltan los detalles necesarios para entender el sistema.
Modelos y Diagramas

Un modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle.

Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés El código fuente del sistema es el modelo más detallado del sistema (y además es ejecutable). Sin embargo, se requieren otros modelos ... Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos
Diagrama es una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo conexo de arcos (relaciones) y vértices (otros elementos del modelo). Un diagrama no es un elemento semántico, un diagrama muestra representaciones de elementos semánticos del modelo, pero su significado no se ve afectado por la forma en que son representados. Un diagrama está contenido dentro de un paquete.
La mayoría de los diagramas de UML y algunos símbolos complejos son grafos que contienen formas conectadas por rutas. La infomación está sobre todo en la topología, no en el tamaño o la colocación de los símbolos (hay algunas excepciones como el diagrama de secuencia con un eje métrico de tiempo). Hay tres clases importantes de relaciones visuales: conexión (generalmente de líneas a formas de dos dimensiones), contención (de símbolos por formas cerradas de dos dimensiones), y adhesión visual (un símbolo que está "cerca" de otro en un diagrama). Estas relaciones geométricas se reasignan a conexiones entre nodos en un gráfico en la forma analizada de la notación.
NOTACION UML

La notación de UML está pensada para ser dibujada en superficies bidimensionales. Algunas formas bidimensionales son proyecciones de formas tridimensionales tales como cubos, pero todavía se representan como íconos en una superficie bidimensional.


Hay cuatro clases de construcciones gráficas que se usan en la notación de UML: íconos, símbolos bidimensionales, rutas y cadenas.

Un ícono es una figura gráfica con un tamaño y forma fijos. No se amplía para contener a su contenido. Los iconos pueden aparecer dentro de símbolos de área, como terminadores en las rutas o como símbolos independientes que puedan o no conectar con las rutas.

Los símbolos de dos dimensiones tienen altura y anchura variables, y pueden ampliarse para permitir otras cosas tales como listas de cadenas o de otros símbolos. Muchos de ellos están divididos en compartimientos similares o de tipos diferentes. Las rutas se conectan con los símbolos, el arrastrar o suprimir uno de ellos afecta a su contenido y las rutas conectadas.

de segmentos de recta o de curva que se unen en sus puntos finales. Conceptualmente una ruta es una sola entidad topológica, aunque sus segmentos se pueden manipular gráficamente. unsegemento no debería existir separado de su ruta. Las rutas siempre van conectdas en ambos extremos.


Las cadenas presentan varias clases de información en una forma "no analizada", UML asume que cada uso de una cadena en la notación tiene una sintaxis por la cual pueda ser analizada la información del modelo subyancente. Las cadenas pueden existir como el contenido de un compartimiento, como elementos en las listas, como etiquetas unidas a los símbolos o a las rutas, o como elementos independientes en un diagrama.
DIAGRAMAS UML

Los diagramas expresan gráficamente partes de un modelo. UML está compuesto por los siguientes diagramas:


Diagramas de UML

Diagrama de Casos de Uso

Diagrama de Clases

Diagrama de Objetos

Diagramas de Comportamiento

Diagrama de Estados

Diagrama de Actividad

Diagramas de Interacción

Diagrama de Secuencia

Diagrama de Colaboración

Diagramas de implementación

Diagrama de Componentes

Diagrama de Despliegue
NUEVAS CARACTERÍSTICAS DEL UML

Además de los conceptos extraídos de métodos anteriores, se han añadido otros nuevos que vienen a suplir carencias antiguas de la metodología de modelado. Estos nuevos conceptos son los siguientes:




  • Definición de estereotipos: un estereotipo es una nueva clase de elemento de modelado que debe basarse en ciertas clases ya existentes en el metamodelo y constituye un mecanismo de extensión del modelo.

  • Responsabilidades.

  • Mecanismos de extensibilidad: estereotipos, valores etiquetados y restricciones.

  • Tareas y procesos.

  • Distribución y concurrencia (para modelar por ejemplo ActiveX/DCOM y CORBA).

  • Patrones/Colaboraciones.

  • Diagramas de actividad (para reingeniería de proceso de negocios)

  • Clara separación de tipo, clase e instancia.

  • Refinamiento (para manejar relaciones entre niveles de abstracción).

  • Interfaces y componentes.


EL PROCESO DE DESARROLLO
UML no define un proceso concreto que determine las fases de desarrollo de un sistema, las empresas pueden utilizar UML como el lenguaje para definir sus propios procesos y lo único que tendrán en común con otras organizaciones que utilicen UML serán los tipos de diagramas.
Herramientas CASE
Rational Rose es la herramienta CASE que comercializan los desarrolladores de UML y que soporta de forma completa la especificación del UML 1.1.

Esta herramienta propone la utilización de cuatro tipos de modelo para realizar un diseño del sistema, utilizando una vista estática y otra dinámica de los modelos del sistema, uno lógico y otro físico. Permite crear y refinar estas vistas creando de esta forma un modelo completo que representa el dominio del

problema y el sistema de software.
Desarrollo Iterativo
Rational Rose utiliza un proceso de desarrollo iterativo controlado (controllediterativeprocessdevelopment), donde el desarrollo se lleva a cabo en una secuencia de iteraciones. Cada iteración comienza con una primera aproximación del análisis, diseño e implementación para identificar los riesgos del diseño, los cuales se utilizan para conducir la iteración, primero se identifican los riesgos y después se prueba la aplicación para que éstos se hagan mínimos.

Cuando la implementación pasa todas las pruebas que se determinan en el proceso, ésta se revisa y se añaden los elementos modificados al modelo de análisis y diseño. Una vez que la actualización del modelo se ha modificado, se realiza la siguiente iteración.


Trabajo en Grupo
Rose permite que haya varias personas trabajando a la vez en el proceso iterativo controlado, para ello posibilita que cada desarrollador opere en un espacio de trabajo privado que contiene el modelo completo y tenga un control exclusivo sobre la propagación de los cambios en ese espacio de trabajo.
También es posible descomponer el modelo en unidades controladas e integrarlas con un sistema para realizar el control de proyectos que permite mantener la integridad de dichas unidades.
Generador de Código
Se puede generar código en distintos lenguajes de programación a partir de un diseño en UML.
Ingeniería Inversa
Rational Rose proporciona mecanismos para realizar la denominada Ingeniería Inversa, es decir, a partir del código de un programa, se puede obtener información sobre su diseño.




La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal