Universidad
Yacambu
Lic.
Información y Documentación
10mo
trimestre
Materia:
Análisis
y Diseño de Sistemas
Prof.
Yaros
Pérez
Trabajo
final
Tema:
UML
Elaborado
por: Aldo Méndez,
Lenguaje
Unificado de Modelado (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; aún cuando todavía no es un estándar oficial, está
apoyado en gran manera por el OMG (Object Management Group). Es un lenguaje gráfico
para visualizar, especificar, construir y documentar un sistema de software. UML
ofrece un estándar para describir un "plano" del sistema (modelo),
incluyendo aspectos conceptuales tales como procesos de negocios y funciones del
sistema, y aspectos concretos como expresiones de lenguajes de programación,
esquemas de bases de datos y componentes de software reutilizables.
El
punto importante para notar aquí es que UML es un "lenguaje" para
especificar y no un método o un proceso. UML se usa para definir un sistema de
software; para detallar los artefactos en el sistema; para documentar y
construir -es el lenguaje en el que está descrito el modelo. UML se puede usar
en una gran variedad de formas para soportar una metodología de desarrollo de
software (tal como el Proceso Unificado de Rational) -pero no especifica en sí
mismo qué metodología o proceso usar.
UML
cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de
las entidades representadas.
·
Diagramas
de Casos de Uso para modelar los procesos 'business'.
·
Diagramas
de Secuencia para modelar el paso de mensajes entre objetos.
·
Diagramas
de Colaboración para modelar interacciones entre objetos.
·
Diagramas
de Estado para modelar el comportamiento de los objetos en el sistema.
·
Diagramas
de Actividad para modelar el comportamiento de los Casos de Uso, objetos u
operaciones.
·
Diagramas
de Clases para modelar la estructura estática de las clases en el sistema.
·
Diagramas
de Objetos para modelar la estructura estática de los objetos en el sistema.
·
Diagramas
de Componentes para modelar componentes.
·
Diagramas
de Implementación para modelar la distribución del sistema.
Dentro
de las muchas características de UML podemos mencionar: soporta un nutrido
conjunto de elementos de notación gráficos. Describe la notación para clases,
componentes, nodos, actividades, flujos de trabajo, casos de uso, objetos,
estados y cómo modelar la relación entre esos elementos. El UML también
soporta la idea de extensiones personalizadas a través elementos estereotipados
y restricciones, Un estereotipo nos permite indicar especificaciones del
lenguaje al que se refiere el diagrama de UML. Una restricción identifica un
comportamiento forzado de una clase o relación, es decir mediante la restricción
estamos forzando el comportamiento que debe tener el objeto al que se le aplica.
La
utilización de UML es independiente del lenguaje de programación y de las
características de los proyectos, ya que éste lenguaje ha sido diseñado para
modelar cualquier tipo de proyectos, tanto informáticos como de arquitectura, o
de cualquier otra indole.
Objetivos
UML
·
Visualizar:
UML permite representar mediante su simbología el contenido y la estructura de
un sistema software.
·
Especificar:
UML permite especificar los procesos de análisis, diseño y codificación de un
sistema software. También permite determinar modelos precisos, sin ambigüedades,
detallando las partes esenciales de los mismos.
·
Construir:
Las anteriores características permiten que UML pueda generar código en
distintos lenguajes de programación y tablas en una base de datos a partir de
modelos UML. Además permite simular el comportamiento de sistemas software.
·
Documentar:
Como ya se comentó antes, UML permite especificar los procesos de análisis,
diseño y codificación y también permite documentar los mismos, dejando clara
la arquitectura del sistema.
Durante
los ochenta y principios de los noventa Grady Booch, James Rumbaugh, e Ivar
Jacobson trabajaban por separado en desarrollo de notaciones para el análisis y
diseño de sistemas orientados a objetos. Los tres llegaron por separado a
obtener bastante reconocimiento.
Booch
había escrito "Object-Oriented Analysis and Design with Applications"
un libro de referencia en el análisis y diseño orientado a objetos
desarrollando su propia notación.
Por
su parte James Rumbaugh había desarrollado su propia notación de diseño
orientado a objetos llamada OMT (Object Modeling Technique) en su libro
"Object-Oriented Modeling and Design".
Por
otro lado Jacobson se había revelado como un visionario del análisis (padre de
los casos de uso) y sobre todo del diseño orientado a objetos, sorprendiendo a
todo el mundo en "Object-Oriented Software Engineering: A Use Case Driven
Approach".
A
mediados de los noventa empezaron a intercambiar documentos y trabajar en
conjunto produciendo grandes avances en el modelado de sistemas orientados a
objetos.
En
1994 Rational contrató a Rumbaugh en donde ya trabajaba Booch, un año después
Jacobson se unía a ellos en Rational.
En
1997 salió a la luz la versión 1.0 de UML.
En
UML 2.0 hay 13 tipos de diagramas. Para comprenderlos, a veces es útil
categorizarlos jerárquicamente, como se muestra en la figura de la derecha.
Diagramas de estructura enfatizan en los elementos que deben
existir en el sistema modelado:
·
Diagrama
de clases
·
Diagrama
de componentes
·
Diagrama
de objetos
·
Diagrama
de estructura compuesta (UML 2.0)
·
Diagrama
de despliegue
·
Diagrama
de paquetes
Diagramas de comportamiento enfatizan en lo que debe suceder en el
sistema modelado:
·
Diagrama
de actividades
·
Diagrama
de casos de uso
·
Diagrama
de estados
Diagramas de Interacción, un subtipo de diagramas de
comportamiento, que enfatiza sobre el flujo de control y de datos entre los
elementos del sistema modelado:
·
Diagrama
de secuencia
·
Diagrama
de comunicación
·
Diagrama
de tiempos (UML 2.0)
·
Diagrama
de vista de interacción (UML 2.0)
Software
libre (Open Source) para modelado en UML
ArgoUML
es la fuente principal abierta UML el instrumento que modela e incluye el apoyo
a todo el estándar UML 1.4 diagramas. Esto corre sobre cualquier plataforma
Javanesa y está disponible en siete lenguas. Mirar la lista de rasgo para más
detalles.
Umbrello
UML Modeller es un programa de diagrama de Lengua de Modelismo Unificado para
KDE. UML le permite para crear los diagramas de software y otros sistemas en un
formato estándar. Nuestro manual da una introducción buena al modelismo de UML
y Umbrello.
GModeler
es un modelo del diagrama de UML libre (gratis) en línea y el instrumento de
documentación, targetted en reveladores que trabajan con ECMA 262 lenguas como
Actionscript de FlashMX, y Javascript.
Además
de esto hace el diagrama de capacidades, esto exporta la documentación de HTML,
FlashMX XML la documentación (para el Panel de Acción y el Panel de
Referencia) y el código de trozo (el código de clase).
gModeler
fue concebido, diseñado y programado por el Desollador(Estafador) de Subvención,
un líder aprobado en el desarrollo de Internet y de aplicación. Fue
desarrollado usando a FlashMX, y el destello OS2 el marco de aplicación.
StarUML
-
Free UML Tool
¿Ya
se hizo familiar con el UML 2.0 notaciones y busca del instrumento de CASO
derecho? VP-UML es su opción. VP-UML no sólo apoyan UML 2.0 diagramas y la
especificación modela, pero también proporcionan el interfaz de modelado
visual más intuitivo que le deja modelar su sistema más fácil y más
eficiente que la utilización de otros instrumentos..
La tecnología orientada a
objetos persigue el antiguo principio del divide y vencerás. Su objetivo es
descomponer la complejidad en partes más manejables y comprensibles. No parece
que esto sea algo novedoso con respecto a la tradicional descomposición
funcional de los métodos estructurados. Sin embargo, la gran diferencia reside
en aplicar la dualidad estructura-función en pequeñas unidades capaces de
comunicarse y reaccionar en base a la aparición de una serie de eventos. El
esquema dominante de la separación de estructuras de datos y funciones (bases
de datos y programas) está amenazado pero aún se resiste a desaparecer.
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.
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 (Object Modeling Technique) 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.
Se
consigue un modelo completo de la realidad cuando el modelo captura los aspectos
importantes del problema y omite el resto. Los lenguajes de programación que
estamos acostumbrados a utilizar no son adecuados para realizar modelos
completos de sistemas reales porque necesitan una especificación total con
detalles que no son importantes para el algoritmo que están implementando. En
OMT se modela un sistema desde tres puntos de vista diferentes donde cada uno
representa una parte del sistema y una unión lo describe de forma completa. En
esta técnica de modelado se utilizó una aproximación al proceso de
implementación de software habitual donde se utilizan estructuras de datos
(modelo de objetos), las operaciones que se realizan con ellos tienen una
secuencia en el tiempo (modelo dinámico) y se realiza una transformación sobre
sus valores (modelo funcional).
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.
Fortalezas
Lenguaje
Unificado de Modelado (UML, por sus siglas en inglés, Unified Modelling
Language) es el lenguaje de modelado de sistemas de software más conocido en la
actualidad; aún cuando todavía no es un estándar oficial, está apoyado en
gran manera por la OMG.
Es
un lenguaje gráfico para visualizar, especificar, construir y documentar un
sistema de software. UML ofrece un estándar para describir un "plano"
del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de
negocios y funciones del sistema, y aspectos concretos como expresiones de
lenguajes de programación, esquemas de bases de datos y componentes de software
reutilizables.
El
punto importante para notar aquí es que UML es un "lenguaje" para
especificar y no un método o un proceso. UML se usa para definir un sistema de
software; para detallar los artefactos en el sistema; para documentar y
construir -es el lenguaje en el que está descrito el modelo. UML se puede usar
en una gran variedad de formas para soportar una metodología de desarrollo de
software (tal como el Proceso Unificado de Rational) pero no especifica en sí
mismo qué metodología o proceso usar.
UML
cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de
las entidades representadas.
Debilidades
A
pesar de su status de estándar ampliamente reconocido y utilizado, UML siempre
ha sido muy criticado por su carencia de una semántica precisa, lo que ha dado
lugar a que la interpretación de un modelo UML no pueda ser objetiva. Otro
problema de UML es que no se presta con facilidad al diseño de sistemas
distribuidos. En tales sistemas cobran importancia factores como transmisión,
serialización, persistencia, etc. UML no cuenta con maneras de describir tales
factores. No se puede, por ejemplo, usar UML para señalar que un objeto es
persistente, o remoto, o que existe en un servidor que corre continuamente y que
es compartido entre varias instancias de ejecución del sistema analizado.
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:
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.
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 increméntales 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.
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.
La abstracción de las
realidades físicas a clases permite obtener una representación sencilla de los
modelos de comportamiento. Sin embargo, no siempre los modelos resultan
sencillos de representar. El desarrollo de cualquier modelo medianamente
complejo conlleva el desarrollo de clases de gran complejidad.
El
modelo de componentes pretende reducir el impacto del desarrollo de clases
reduciendo algunos de los aspectos vinculados a los mismos. Se diferencia de la
clase en que el componente no es una representación sencilla que permita
reproducir un elemento real, sino que es una asociación de clases de la misma o
de diferentes características que presentan un nexo de unión.
Una
segunda diferencia fundamental, es que se pretende abstraer el funcionamiento
del componente del propio proyecto. Por tanto, la generación de
aplicaciones/librerías que se realiza a partir de su código es reutilizable
con independencia del proyecto. Esto provoca una construcción de arquitectura
de diseño específica para permitir dicha funcionalidad.
UML
abarca todas las fases del ciclo de vida de un proyecto, soporta diferentes
maneras de visualización dependiendo de quién tenga que interpretar los planos
y en que fase del proyecto se encuentre.
Infografía
http://www.vico.org/UMLguiaVisualpresentacion.htm
UML
Nuestros
límites para entender esta realidad están en nuestro lenguaje. El mundo es la
suma total de lo que podemos definir, organizar y visualizar. Cabe preguntarse
¿de qué manera un modelo en UML representa nuestra experiencia?. Enseñar a
utilizar un lenguaje formal siempre es problemático. Es necesario mostrar
como este lenguaje puede ser aplicado a la realidad tal como la conocemos y tal
como la compartimos con los demás.
http://www.ilustrados.com/publicaciones/EpyVZFEAlFbLrdQjBE.php
Ingeniería
de SoftwareUML
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.
http://www.monografias.com/trabajos16/lenguaje-modelado-unificado/lenguaje-modelado-unificado.shtml
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
www.gig.etsii.upm.es/jmcabanellas/Doctorado_0405/Doctor_Tecno_Simul_0405_guia_8.pdf
Desarrollo
de Proyectos
El
desarrollo de proyectos software ha sufrido una evolución desde los primeros
sistemas de cálculo, implementados en grandes computadores simplemente ayudados
mediante unas tarjetas perforadas donde los programadores escribían sus
algoritmos de control, hasta la revolución de los sistemas de información e
Internet.
UML:
Diagramas UML. ¿Qué es UML?
UML no es un método de desarrollo.
No te va a decir cómo pasar del análisis al diseño y de este al código. No
son una serie de pasos que te llevan a producir código a partir de unas
especificaciones.
UML
al no ser un método de desarrollo es independiente del ciclo de desarrollo que
vayas a seguir, puede encajar en un tradicional ciclo en cascada, o en un
evolutivo ciclo en espiral o incluso en los métodos ágiles de desarrollo.
http://www.ingenierosoftware.com/analisisydiseno/uml.php
Lenguaje
Unificado de Modelado
Lenguaje
Unificado de Modelado (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; aún cuando todavía no es un estándar oficial, está
apoyado en gran manera por el OMG (Object Management Group).
http://es.wikipedia.org/wiki/UML
¿Qué
es UML?
El
Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas
estándar para modelar sistemas orientados a objetos, y describe la semántica
esencial de lo que estos diagramas y símbolos significan. Mientras que ha
habido muchas notaciones y métodos usados para el diseño orientado a objetos,
ahora los modeladores sólo tienen que aprender una única notación.
http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/multiple-html/c12.html
En
este artículo se muestra en sentido muy amplio información sobre el UML,
UML es un estándar industrial promovido por el grupo OMG al mismo nivel
que el estándar corba para intercambio de objetos distribuidos. Para la revisión
de UML se formaron dos "corrientes" que promovían la aparición de la
nueva versión desde distintos puntos de vista. Finalmente se impuso la visión
más industrial frente a la académica.