ADSI GEMINIS TECNOLOGY
EQUIPO GEMINIS ENERO 2013
INDICE Pág.
¿Qué es un modelo?
3
¿Por qué modelamos?
3
Acerca del Modelado
3
¿Qué significa modelar?
3
Concepción del UML
4
¿Qué es UML(Unified Modeling Language)?
5
Modelo Conceptual de UML
6
Historia
7
¿Por qué es necesario UML?
9
Bloques de construcción de UML
10
Diagramas UML
13
Referencias
20
2
¿Qué es un modelo? Un modelo es la representación, matemática o no, de algún aspecto de la realidad (por lo general fenómenos físico-químicos) y que es desarrollada para un propósito específico de estudio de dicha realidad.
Un modelo es una abstracción de un sistema o entidad del mundo real.
Una abstracción es una simplificación, que incluye sólo aquellos detalles relevantes para algún determinado propósito.
El modelado permite abordar la complejidad de los sistemas
¿Por qué modelamos? Uno de los objetivos más importantes del modelado es mejorar nuestra comprensión acerca de lo que realmente esta sucediendo en el sistema.
Si el modelo no refleja el conocimiento que se tiene sobre el sistema, probablemente el modelo será inútil. Acerca del Modelado Dado caso que un modelo sea válido para nuestro propósito, cuanto más sencillo sea mejor. No debe complicarse innecesariamente el modelo. No debe realizarse un modelo muy detallado desde el primer momento, ya que: Será un modelo difícil y caro de desarrollar, depurar y ejecutar. Será difícil obtener los datos adecuados para poder evaluar todos los parámetros del modelo. La salida será difícil de explicar e interpretar. Pero, ¿qué significa modelar? La respuesta corta sería: "construir modelos". Sin embargo, esta respuesta nos lleva a otra pregunta: ¿qué es un modelo? La palabra modelo tiene varias acepciones en castellano. Para nosotros en el contexto de UML, un modelo "es una descripción analógica para ayudar a visualizar algo que no se puede observar directamente y que se realiza con un propósito determinado y se destina a un público específico". A modo de ejemplos, un mapa de transportes de una ciudad, es un modelo de la ciudad en cuestión; un plano de instalaciones sanitarias de un edificio, es un modelo de ese edificio; un dibujo de un dragón, es un modelo de un dragón. En los ejemplos 3
anteriores, nos referimos a representaciones de cosas que no podemos observar, pero de las que nos damos una idea a partir del modelo. No obstante, hay varios elementos en la definición anterior que necesitamos desmenuzar. Acabamos de decir que un modelo es una descripción analógica para ayudar a visualizar algo que no se puede observar directamente, y que se realiza con un propósito determinado y se destina a un público específico. Veamos: • Descripción analógica: el modelo no es aquello que se quiere observar, sino una representación simplificada. Por esta razón, el mapa no es la ciudad, el plano sanitario no es la propia instalación sanitaria y el dibujo del dragón no es el propio dragón. • De algo que no puede ser observado directamente: el sistema de transportes de la ciudad no se puede ver, porque es un concepto abstracto que requiere de estudio y observación; las instalaciones sanitarias del edificio no se pueden ver a menos que rompamos las paredes y pisos del mismo; el dragón no puede verse ... porque no existe. • Se realiza con un propósito determinado: el propósito o perspectiva es lo que determina para qué realizamos el modelo. Así, el mapa de transportes sirve para saber cómo llegar de un punto a otro de la ciudad usando el sistema de transportes; en el plano de instalaciones sanitarias se indica por dónde pasan las cañerías del edificio; el dibujo del
dragón, para comunicar a otras personas cómo sería un ejemplar de esta especie mitológica. • Destinado a un determinado público: es decir, existe un público potencial que va a usar el modelo en cuestión. Por ejemplo, el mapa de transportes se realiza para un ciudadano común que necesita moverse por la ciudad o para un planificador de transportes; el plano de instalaciones sanitarias le sirve a un plomero que desee hacer una refacción de un baño, entre otros; el dibujo del dragón puede tener un público infantil o adulto. La finalidad última de un modelo es la comunicación de algo: un proyecto, un concepto, la descripción física de algún elemento, etc. Precisamente, por esta necesidad de comunicar y porque, además, se destina a un determinado público, con cierto propósito, un modelo es, en definitiva, una abstracción. Concepción del UML El UML es la creación de Grady Booch, James Rumbaugh e Ivar Jacobson. Estos tres trabajaban en empresas distintas durante la década de los años 80 y principios de los 90 y cada uno diseño su propia metodología para el análisis y diseño orientado a objetos. A mediados de los 90 empezaron a intercambiar ideas entre si y decidieron desarrollar su trabajo en conjunto. En 1994 Rumbaugh a Rational software corporation, donde ya
4
trabajaba Booch. Jacobson ingreso a rational un año después. Se crea el consorcio del UML conformado por: Intellicorp, DEC, Hwelett Packard, Microsoft, Oracle, Texas Instruments y Rational. En 1997 se crea la versión 1.0 del UML - OMG (Grupo de administración de objetos) para generar un lenguaje estándar de modelado. 1998 se creó de inmediatamente la versión 1.1 de UML. 2004 se creó la versión 2.0 del UML. Para comprender qué es el UML, basta con analizar cada una de las palabras que lo componen, por separado: Lenguaje: Proporciona la sintaxis, vocabulario y las reglas necesarias para la representación conceptual y física de un sistema software. Modelado: El UML es visual. Mediante su sintaxis se modelan distintos aspectos del mundo real, que permiten una mejor interpretación y entendimiento de éste. Unificado: Unifica varias técnicas (orientada a objetos, enfocada al usuario…) de modelado en una única.
¿Qué es UML(Unified Modeling Language)?: Lenguaje de Modelado Unificado. Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software. El UML ofrece un estándar para escribir un "plano" del sistema, 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. Podemos especificar que: Es un lenguaje estándar para escribir planos (modelos) de software. Utilizado para expresar gráficamente el proceso de generación de software. UML es independiente del lenguaje de implementación del software. UML es un Lenguaje “Unificado” de Modelado para: – Visualizar: Representar y Comunicar Ideas. Detrás de cada símbolo de UML hay una semántica bien definida. – Especificar: Modelos precisos, no ambiguos, completos. 5
– Construir: Trasladar en forma directa a un lenguaje de programación. – Documentar: construidos proyecto.
Los artefactos durante un
Modelo Conceptual de UML •
Un modelo UML esta compuesto por tres clases de bloques de construcción:
•
• Elementos: Los elementos son abstracciones de cosas reales o ficticias (objetos, acciones, etc.)
•
• Relaciones: relacionan los elementos entre sí.
•
• Diagramas: Son colecciones de elementos con sus relaciones.
detallar los artefactos en sistema y para documentar construir. En otras palabras, es lenguaje en el que está descrito modelo.
el y el el
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. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para 6
Historia 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 sabía de sus constantes discusiones 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. 7
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. El Lenguaje de Modelado Unificado es un estándar internacional: ISO / IEC 19501:2005 Tecnología de la información - Procesamiento distribuido abierto - Lenguaje de Modelado Unificado (UML) Version 1.4.2 UML 2.x UML ha madurado considerablemente desde UML 1.1. Varias revisiones menores (UML 1.3, 1.4 y 1.5) han corregido defectos y errores de la primera versión de UML. A estas le ha seguido la revisión mayor UML 2.0 que fue adoptada por el OMG en 2005. Aunque UML 2.1 nunca fue lanzado como una especificación formal, las versiones 2.1.1 y 2.1.2, aparecieron en 2007, seguidas por UML 2.2 en febrero de 2009. UML 2.3 fue lanzado oficialmente en mayo de 2010. UML 2.4.1 fue lanzado oficialmente en agosto de 2011. UML 2.5 fue lanzado en octubre de 2012 como una versión "En proceso" y todavía tiene que ser formalmente liberada.
8
¿Por qué es necesario UML? Hoy en día, UML ("Unified Modeling Language") esta consolidado como el lenguaje estándar en el análisis y diseño de sistemas de computo. Mediante UML es posible establecer la serie de requerimientos y estructuras necesarias para plasmar un sistema de software previo al proceso intensivo de escribir código. En otros términos, así como en la construcción de un edificio se realizan planos previo a su construcción, en Software se deben realizar diseños en UML previa codificación de un sistema, ahora bien, aunque UML es un lenguaje, éste posee más características visuales que programáticas, mismas que facilitan a integrantes de un equipo multidisciplinario participar e intercomunicarse fácilmente, estos integrantes siendo los analistas, diseñadores, especialistas de área y desde luego los programadores.
presenta el uso de UML ("Unified Modeling Language"), las razones de esto son evidentes, sin embargo, existen dos puntos claves : El primero se debe a que mediante un plano/visión global resulta más fácil detectar las dependencias y dificultades implícitas del sistema, y la segunda razón radica en que los cambios en una etapa inicial (Análisis) resultan más fáciles de realizar que en una etapa final de un sistema como lo seria la fase intensiva de codificación.
Puesto que UML es empleado en el análisis para sistemas de medianaalta complejidad, era de esperarse que su base radica en otro paradigma empleado en diseños de sistemas de alto nivel que es la orientación a objetos, por lo que para trabajar en UML puede ser considerado un pre-requisito tener experiencia en un lenguaje orientado a objetos.
Complejidad/Objetos
Entre más complejo es el sistema que se desea crear más beneficios
9
Elementos Estructurales de UML
10
Elementos Estructurales de UML
Elementos de Comportamiento de UML
11
Elementos de Agrupación de UML • Son las partes organizativas de los modelos UML. • Hay un elemento de agrupación principal, los paquetes. Un paquete es un mecanismo de propósito general para organizar elementos (estructurales, de comportamiento, e incluso otros elementos de agrupación) en grupos. • Al contrario de los componentes (que existen en tiempo de ejecución), un paquete es puramente conceptual (sólo existe en tiempo de desarrollo).
Elementos de Anotación de UML • Son las partes explicativas de los modelos UML. • Hay un tipo principal llamado Nota. • Son comentarios que se pueden aplicar para describir, clarificar y hacer observaciones sobre cualquier elemento de un modelo.
12
funciones del sistema y los roles de los elementos del entorno con los que interactúan. Por ejemplo, el rol de usuario de un sistema. A estos roles de los elementos del entorno se les denomina actores. Observe que se distinguen los roles, no los elementos en sí. Cada servicio que el sistema deba realizar se modela como un caso de uso y cada rol de los elementos del Un diagrama es la representación gráfica de un conjunto de elementos, visualizando la mayoría de las veces como un grafo conexo de nodos (elementos) y arcos (relaciones).
entorno del sistema se modela como
Los diagramas se dibujan para visualizar el sistema desde diferentes perspectivas, de forma que un diagrama es una proyección de un sistema.
independientemente de su naturaleza.
un actor. Gráficamente un caso de uso se representa con una elipse y un actor se representa con un monigote,
UML incluye nueve tipos de diagramas fundamentales, clasificados en dos grandes grupos, uno para modelar la estructura estática del sistema y otro para modelar el comportamiento dinámico.
Diagrama de casos de uso El
diagrama
de
casos
de
uso
especifica el comportamiento global del sistema y su interacción con el entorno.
Muestra
los
servicios
o 13
Diagrama de clases
La representación gráfica de un objeto
Un diagrama de clases muestra las
en UML es igual que la de una clase
clases que componen el sistema y las
pero con el nombre subrayado. Para
relaciones que existen entre ellos.
mostrar el estado de un objeto, se
Este diagrama se utiliza para modelar
indica el valor de sus atributos y sus
la vista de diseño estructural de un
objetos agregados.
sistema. Los diagramas de clases además, pueden contener paquetes. La única relación entre objetos que se puede representar en UML es el enlace. Un enlace indica una conexión entre dos objetos. Dos objetos pueden estar
conectados
si
existe
una
asociación o una dependencia entre las clases que instancian.
Diagrama de objetos Un diagrama de objetos muestra un conjunto de objetos y sus relaciones en un instante de tiempo determinado. Puede verse como una fotografía del sistema que muestra el estado de los objetos en ese instante.
14
Diagrama de secuencias
estereotipados
Los diagramas de secuencias se han
<<destroy>>
convertido
las
Cuando un objeto es creado durante
representaciones más populares de
la interacción, se sitúa en el diagrama
UML
y
alineado con el mensaje de creación y
capacidad de expresión. Su éxito
no en la parte superior. La destrucción
radica
de un objeto se muestra dibujando
en
una
debido a
en
que
de
su simplicidad
es
muy
sencillo
dibujarlos y, aún más importante, es muy fácil interpretarlos correctamente.
con
<<create>>
y
respectivamente.
una x grande al final de su línea vida. Los diagramas de secuencias se
Los objetos que participan en la
utilizan principalmente para modelar la
interacción se dibujan en la parte
vista
superior
comportamiento, del sistema. Aunque,
del
horizontalmente.
diagrama
Los
objetos
se
debido
de
a
diseño
su
dinámica,
éxito,
o
también
de
es
representan igual que las clases pero
frecuente utilizarlos para describir los
con el nombre subrayado.
flujos de eventos de los casos de uso.
Debajo de cada objeto se dibuja una línea vertical discontinua llamada línea de vida. Esta línea indica el tiempo de existencia del objeto. Generalmente,
los
objetos
que
participan en una interacción existen durante todo el tiempo que dura dicha interacción. Siendo así, los objetos se sitúan en la parte superior y sus líneas de vida se prolongan a lo largo de todo del diagrama. Sin embargo, también pueden crearse y destruirse objetos durante la interacción. La creación y la destrucción de un objeto se
indican
mediante
mensajes 15
Diagrama de colaboración
comportamiento de un objeto dirigido
Un diagrama de colaboración es un
por eventos. Aunque también pueden
diagrama de interacción que resalta la
utilizarse
organización estructural de los objetos
comportamiento del sistema global o
que envían y reciben los mensajes.
de subsistemas.
para
mostrar
el
Este tipo de diagrama muestra un conjunto de objetos, enlaces entre ellos y los mensajes que intercambian. Un diagrama de colaboración es un grafo, donde los nodos del grafo son los objetos y los arcos son los enlaces. Un enlace es una instancia de una asociación o una dependencia entre clases. Se representa con una línea
continua
que une
los dos
objetos.
Un diagrama de estados modela la vida de un objeto mediante una máquina de estados. Cada estado representa una situación durante la cual
el
objeto
satisface
alguna
condición, realiza alguna actividad o espera algún evento. Los estados se dibujan con una caja con las esquinas redondeadas. Se
pueden
definir
dos
estados
especiales:
Estado
inicial:
indica
el
punto de comienzo de la ejecución de la máquina de estados. Se representa con un círculo negro.
Estado
final:
indica
la
terminación de la ejecución de la máquina de estados. Se
Diagrama de estados
representa
con
un
círculo negro dentro de un círculo blanco. En UML los diagramas de estados se utilizan
para
modelar
el 16
Las transiciones entre estados se
flujo de control. En estos diagramas
dibujan con una flecha continua desde
los estados representan actividades o
el estado origen al estado destino.
acciones.
Una
acción
es
una
operación atómica indivisible que no puede ser interrumpida durante su ejecución.
Una actividad es una operación no atómica que puede descomponerse en otras actividades o acciones y que puede ser interrumpida durante su ejecución.
Gráficamente
no
hay
ninguna diferencia entre un estado de actividad y un estado de acción, ambos se representan con una caja de bordes redondeados.
Para indicar el estado inicial y final de
Diagrama de actividades
la actividad global se utilizan los
Los diagramas de actividades de UML son similares a los diagramas de flujo tradicionales.
Generalmente
se
utilizan para modelar flujos de trabajo o para describir detalladamente una
mismos
símbolos
que
en
los
diagramas de estado: un círculo negro para el estado inicial y un círculo negro dentro de un círculo blanco para el estado final.
operación. En UML los diagramas de actividades
Cuando se completa la actividad o la
son
acción de un estado, el flujo de control
un
caso
particular
de
los
diagramas de estado que muestran un
pasa
inmediatamente
al
estado 17
siguiente. La transición de un estado a
Gráficamente,
otro se indica con una flecha continua.
dibuja
un
componente
mediante
una
caja
se con
pestañas. Un
diagrama
muestra
la
de
componentes
organización
y
las
dependencias entre un conjunto de componentes.
Los
componentes paquetes
diagramas
pueden
para
de
contener
organizar
los
elementos.
Diagrama de despliegue Los
diagramas
de
despliegue
modelan la topología del hardware sobre el que se ejecuta el sistema software. Este tipo de diagramas suele utilizarse para modelar sistemas distribuidos o sistemas empotrados. Diagrama de componentes
En
los
sistemas
monolíticos,
generalmente, resultan innecesarios.
En UML los componentes representan
Un diagrama de despliegue muestra la
elementos físicos del sistema, por
configuración
ejemplo ejecutables, páginas HTML,
sistema. En UML, un nodo es un
librerías, tablas, ficheros, etc.
elemento físico que existe en tiempo
de
los
nodos
del
de ejecución y representa un recurso computacional Componente
que,
generalmente,
tiene alguna memoria y, a menudo, capacidad
de
procesamiento.
Habitualmente los nodos representan procesadores y dispositivos hardware. 18
Gráficamente, un nodo se dibuja como
Los
paquetes
un cubo. Las conexiones físicas entre
organizar
los nodos se representan mediante
diagramas en grupos a los que se
relaciones de asociación.
puede dar un nombre y manejar como
los
se
utilizan
elementos
de
para los
un conjunto. Si
terminal
estamos
aplicación
desarrollando
trivial,
una
probablemente
podremos representar todo el sistema en un diagrama que contenga unos servidor
unidad RAID
cuantos elementos y resulte fácil de entender e interpretar. Pero, en un sistema
consola
complejo,
el
número
de
elementos y de relaciones necesarias para modelar el sistema completo puede exceder la capacidad humana de comprensión. Por esta razón se agrupan los elementos en paquetes y el contenido de cada paquete se
Diagrama de Paquetes
muestra en un diagrama distinto. Un paquete es un mecanismo de propósito
general
para
organizar
elementos en grupos. Gráficamente se representa como una carpeta.
<<Nombre >>
19
REFERENCIAS
G. Booch, J. Rumbaugh y I. Jacobson, "El Lenguaje Unificado de Modelado", Addison Wesley, 1999
Jacobson, G. Booch, J. Rumbaugh , "El Proceso Unificado de Desarrollo", Addision Wesley, 2000
E. Hernández, J. Hernández, C. Lizandra, "C++ Es-tandar", ITP Paraninfo 2001
http://www.radioiyambae.com/sitio/index.php?option=com_content&view=art icle&id=5915:simulacion-y-modelo&catid=25:cultural-y-articulos&Itemid=35
http://www.monografias.com/trabajos82/lenguaje-uml-importanciamodelar/lenguaje-uml-importancia-modelar.shtml
20