República Bolivariana de Venezuela
Universidad Bicentenaria de Aragua
Facultad de Ingeniería
Escuela de Sistemas
Integrantes:
Arencibia, Sosiree V- 14.741.783
Guerra, Briceida V-15.648.865
Mata, Leonardo V-20.451.242
Morales Luis V-19.516.118
Turmero, 12 Julio de 2015
INTRODUCCION
Un proyecto de software con éxito es aquél que produce un software de calidad,
consistente y sobre todo que satisface las necesidades de los usuarios que van a
utilizar el producto resultante. El modelado es una parte fundamental en el desarrollo
de sistemas, debido a que se construyen modelos para visualizar el comportamiento
del sistema y controlar su arquitectura. Incluso al producir software de sistemas
pequeños se hace necesario realizar un análisis y un modelado ya que se producirían
con una mejor calidad. Por lo tanto, mientras mas más grande y complejos son los
sistemas más importante es hacer un buen modelado para que ayude a entender el
comportamiento del sistema en su totalidad.
El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un
lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que
comprende el desarrollo de software. UML entrega una forma de modelar cosas
conceptuales como lo son procesos de negocio y funciones de sistema, además de
cosas concretas como lo son escribir clases en un lenguaje determinado, esquemas de
base de datos y componentes de software reusables. Tiene como objetivo principal
entregar un material de apoyo que le permita al lector poder definir diagramas propios
como también poder entender el modelamiento de diagramas ya existentes.
En todo proceso de software donde se utilice una metodología orientada a objetos y la
notación UML no pueden faltar los diagramas, para representar las diferentes vistas
del producto final. Los diagramas de UML se pueden dividir en estáticos (aportan una
visión estática del sistema) y dinámicos (aportan una visión dinámica del sistema).
Entre los diagramas estáticos se observan: Diagrama de casos de uso, Diagrama de
clases, Diagrama de objetos, Diagrama de componentes, Diagrama de despliegue;
mientras que los diagramas dinámicos son: Diagrama de estados, Diagrama de
actividad, Diagramas de interacción o Diagrama de secuencia o Diagrama de
colaboración.
En este sentido, es de gran importancia identificar al momento del modelado de
sistemas cuales de los diagramas son necesarios para el proyecto a ejecutar. En tanto,
será la práctica y experiencia y el tipo de sistema a desarrollar lo que determinará este
proceso. Por ejemplo, se puede decir que en aplicaciones “cliente” el diseñador suele
utilizar los diagramas de casos de uso, de clase y de colaboración o de secuencia, para
aplicaciones donde sean importantes los eventos será necesario utilizar el diagrama de
estados, para aplicaciones cliente-servidor además de los diagramas de casos de uso,
clases y objetos puede ser conveniente utilizar los diagramas de despliegue y
componentes, y para aplicaciones complejas cliente-servidor es recomendable utilizar
todos los diagramas de UML debido a que dará una visión más amplia de cómo será
el sistema final.
DIAGRAMA DE CLASES
El diagrama de clases recoge las clases de objetos y sus asociaciones. En este
diagrama se representa la estructura y el comportamiento de cada uno de los objetos
del sistema y sus relaciones con los demás
temporal.
Con el fin de facilitar la comprensión del diagrama, se pueden incluir paquetes como
elementos del mismo, donde cada uno de ellos agrupa un conjunto de clases.
Este diagrama no refleja los comportamientos temporales de las clases, aunque para
Los elementos :
1. Clases
. Los objetos son instancias de las clases.
No existe un procedimiento inmediato que permita localizar las clases del diagrama
de clases. Estas suelen corresponderse con sustantivos que hacen referencia al ámbito
del sistema de información y que se encuentran en los documentos de las
especificaciones de requisitos y los casos de uso.
Dentro de la estructura de una clas
:
Los atributos de una clase representan los datos asociados a los objetos
instanciados por esa clase.
los objetos de una clase, caracterizando a dichos objetos.
Las clases y en general todos los elementos de los diagramas, pueden estar
clasificados de acuerdo a varios criterios, como por ejemplo su objetivo dentro de un
programa. Esta clasificación adicional se expresa mediante un Estereotipo
pueden aparecer en un modelo. Los tipos son:
Objetos Entidad.
.
Objetos de control.
2. Relaciones
Los tipos más importantes de relaciones estáticas entre clases son los siguientes:
es general, y denota
básicamente una dependencia semántica. Por ejemplo, una Persona trabaja
para una Empresa.
:
o Rol, o nombre de la asociación, que describe la semántica de la
relación en el sentido indicado. Por ejemplo, la asociación entre
Persona y Empresa recibe el nombre de trabaja para, como rol en ese
sentido.
o Multiplicidad, específica cuantas instancias de una clase están
asociadas a una instancia de la otra clase. Los tipos de multiplicidad
son: Uno a uno, uno a muchos y muchos a muchos.
Herencia. Herencia es el mecanismo que permite a una clase de objetos
incorporar atributos y métodos .
Con la herencia se refleja u . La clase de la cual se
hereda se denomina superclase, y la que hereda subclase.
jerárquica entre un objeto
que representa la totalidad de ese objeto y las partes que lo componen.
Permite el agrupamiento físico de estructuras relacionadas lógicamente. Los
“ -parte- ” P motor, ruedas,
carrocería son parte de automóvil.
Composición. La composición
de propiedad es más fuerte, e incluso coinciden los tiempos de vida del objeto
completo y las partes que lo componen.
Dependencia de dependencia se utiliza entre dos clases o entre
una clase y una interfaz, e indica que una clase requiere de otra para
proporcionar alguno de sus servicios.
3. Interfaces
e
una clase o paquete que son visibles desde otras clases o paquetes. Normalmente, se
corresponde con una parte del comportamiento del elemento que la proporciona.
4. Paquetes
Los paquetes se usan para dividir el modelo de clases del sistema de información,
agrupando clases u otros paquetes según los criterios que sean oportunos. Las
dependencias entre ellos se definen a partir de las relaciones establecidas entre los
distintos elementos que se agrupan en estos paquetes.
SIMBOLOGIA
Una clase se representa como una caja, separada en tres zonas por líneas horizontales.
En la zona superior se muestra el nombre de la clase y propiedades generales como el
estereotipo. El nombre de la clase aparece centrado y si la clase es abstracta se
representa en cursiva. El estereotipo, si se muestra, se sitúa sobre el nombre y entre el
símbolo:
<< .... >>.
La zona central contiene una lista de atributos, uno en cada línea. La notación
utilizada para representarlos incluye, dependiendo del detalle, el nombre del atributo,
su tipo y su valor por defecto, con el formato:
visibilidad nombre : tipo = valor-inicial { propiedades }
(+), privada (-) o protegida (#
.
:
visibilidad nombre - - ): tipo-devuelto { propiedad
}
(+), privada (-) o protegida (#
:
nombre : tipo = valor-por-defecto
La notación especificada se puede simplificar según el nivel de detalle con el que se
quiera trabajar en un momento dado.
Relaciones
con la misma clase, indicando que una instancia d
instancias de la misma clase, lo que se conoce como .
. Los estereotipos permiten
clasificar las relaciones en familias y se escribirán : << ... >>.
Las diferen
:
Multiplicidad
‘n ‘*
.
Orden: Se puede especificar si las instancias guardan un orden con la palabra
‘{ordered}
.
Navegabilidad
.
Rol o
está unida a una clase, para expresar como esa cla
.
Además, existen notaciones específicas para los otros tipos de relación, como son:
Agregación: Se representa con un rombo hueco en la clase cuya instancia es
una agregación de las instancias de la otra.
Composición: Se representa con un rombo lleno en la clase cuya instancia
contiene las instancias de la otra clase.
Dependencia: Una línea discontinua con una flecha apuntando a la clase
cliente. La relación puede tener un estereotipo que se coloca junto a la línea, y
entre el símbolo: << ... >>.
DIAGRAMA DE COLABORACION
Los diagramas de colaboración muestran las interacciones que ocurren entre los
objetos que participan en una situación determinada. Esta es más o menos la misma
información que la mostrada por los diagramas de secuencia, pero destacando la
forma en que las operaciones se producen en el tiempo, mientras que los diagramas
de colaboración fijan el interés en las relaciones entre los objetos y su topología.
En los diagramas de colaboración los mensajes enviados de un objeto a otro se
representan mediante flechas, mostrando el nombre del mensaje, los parámetros y la
secuencia del mensaje. Los diagramas de colaboración están indicados para mostrar
una situación o flujo programa específicos y son unos de los mejores tipos de
diagramas para demostrar o explicar rápidamente un proceso dentro de la lógica del
programa.
Simbología del Diagrama de Colaboraciones.
EJEMPLO: LA MAQUINA DE GASEOSAS
Las cosas se hacen más interesantes cuando aplica las condiciones a una situación
real, como lo hizo en la hora anterior con la máquina de gaseosas. Iniciemos con la
“ ”
1. El cliente inserta el dinero en la alcancía que se encuentra en la fachada de la
máquina.
2. El cliente hace su elección.
3. El dinero viaja hacia el registrador.
4. El registrador verifica si la gaseosa elegida está en el dispensador.
5. Dado que es mejor situación, asumimos que si hay gaseosas, y el registrador
actualiza su reserva de efectivo.
6. El registrador hace que el dispensador entregue la gaseosa en la fachada de la
máquina.
M “ ”
DIAGRAMA DE SECUENCIAS:
Los diagramas de secuencia ilustran la interacción entre objetos y el orden secuencial
en el que ocurren dichas interacciones, es decir cómo se comunican los objetos entre
sí. Este tipo de esquema muestra la interacción de un conjunto de objetos en una
aplicación a través del tiempo y se modela para cada caso de uso. El diagrama de
secuencia contiene detalles de implementación del escenario, incluyendo los objetos y
clases que se usan para implementar el escenario y mensajes intercambiados entre
ellos.
Los objetos están representados por líneas intermitentes verticales, con el nombre del
objeto en la parte más alta. El eje de tiempo también es vertical, incrementándose
hacia abajo, de forma que los mensajes son enviados de un objeto a otro en forma de
flechas con los nombres de la operación y los parámetros
Se Caracteriza principalmente por:
Mostrar la secuencia de mensajes entre objetos durante un escenario concreto.
Cada objeto viene dado por una barra vertical.
El tiempo transcurre de arriba abajo.
Cuando existe demora entre el envío y la atención se puede indicar usando
una línea oblicua.
Se prepara durante la fase de análisis de un ciclo de desarrollo.
Su creación depende de la formulación previa de los casos de uso.
El comportamiento del sistema es una descripción de lo que hace y no de
cómo lo hace.
Entre sus Ventajas tenemos:
Da la posibilidad de representar los mensajes en función del tiempo.
La separación de los mensajes no indica intervalos o cantidades de tiempo,
solo ordenación temporal.
Es posible añadir restricciones temporales.
Desventajas del Diagrama de Secuencia:
Una representación de un diagrama de secuencia demasiado largo, puede ser
difícilmente entendido por alguien ajeno al sistema.
La Simbología utilizada en este Diagrama es la siguiente:
Línea de vida de un objeto:
La línea de vida de un objeto representa la vida del objeto durante la interacción. En
un diagrama de secuencia un objeto se representa como una línea vertical punteada
con un rectángulo de encabezado y con rectángulos a través de la línea principal que
denotan la ejecución de métodos (activación).
Activación:
Muestra el período de tiempo en el cual el objeto se encuentra desarrollando alguna
operación, bien sea por sí mismo o por medio de delegación a alguno de sus atributos.
Se denota como un rectángulo delgado sobre la línea de vida del objeto.
Mensaje:
El envío de mensajes entre objetos se denota mediante una línea sólida dirigida, desde
el objeto que emite el mensaje hacia el objeto que lo ejecuta.
Tiempos de transición:
En un entorno de objetos concurrentes o de demoras en la recepción de mensajes, es
útil agregar nombres a los tiempos de salida y llegada de mensajes.
Caminos alternativos de ejecución y concurrencia:
En algunos casos sencillos los caminos alternativos pueden expresarse en un
diagrama de secuencias alternativas de ejecución. Estas alternativas pueden
representar condiciones en la ejecución o diferentes hilos de ejecución
Destrucción de un objeto
Se representa como una X al final de la línea de ejecución del objeto.
Modelar sistemas medianos o grandes conlleva manejar una cantidad considerable de
elementos de modelado (clases, interfaces, componentes, nodos, relaciones,
diagramas); en la medida en que estos sistemas se hacen más grandes, se vuelve más
difícil comprenderlos, así como entender sus cambios. A su vez, los métodos
estructurados se valieron de la descomposición funcional, en la cual el sistema en su
conjunto se correlacionaba como función y se dividía en subfunciones, que a su vez
se dividían en otras subfunciones, y así sucesivamente. Dicho esto, las funciones eran
como los casos de uso en un sistema orientado a objetos, en el que las funciones
representaban algo que hacía el sistema como un todo.
Dentro de la misma idea, el proceso y los datos llegaron a manejarse de modo en que
se entendían como elementos separados. De tal modo que, además de una
descomposición funcional, también había una estructura de datos. Esta última
ocupaba el segundo lugar, aunque ciertas técnicas de ingeniería de información
agrupaban los registros de datos en áreas temáticas y producían matrices que
mostraban la interrelación entre las funciones y los registros de datos.
Es desde este punto de vista que puede apreciarse el gran cambio que han significado
los objetos. Ha desaparecido la separación entre el proceso y los datos, y la
descomposición funcional. Una idea es agrupar las clases en unidades de nivel más
alto. Esta idea aparece, aplicada de manera muy libre, en muchos métodos orientados
a objetos. En el UML, a este mecanismo de agrupamiento se le llama paquete o las
abstracciones que organizan un modelo.
Paquete
Un paquete es un mecanismo de propósito general para organizar un modelo de
manera jerárquica. También posee la funcionalidad de organizar los elementos
modelados con UML, facilitando de ésta forma el manejo de los modelos de un
sistema complejo. Es también importante, que define un espacio de nombres: dos
elementos de UML pueden tener el mismo nombre, con tal y estén en paquetes
distintos.
Características
Son completamente diferentes a las clases, ya que las clases son abstracciones de
aspectos del problema o la solución, y los paquetes son mecanismos para organizar,
pero no tienen identidad (no puede haber instancias de paquetes).
Un paquete puede contener elementos como clases, interfaces, componentes, nodos,
colaboraciones, casos de uso e incluso otros paquetes. De esta forma, cuando se
muestran los elementos del paquete, el nombre se coloca en la pestaña de la carpeta.
También, entre un paquete y sus elementos existe una relación de composición a
saber, un elemento del modelo se declara en un sólo paquete, aunque puede ser
referenciado desde otros. Por lo que, si el paquete se destruye, el elemento también es
destruido.
A su vez, y respecto al contenido, un paquete forma un espacio de nombres
(namespace). Dicho de otra forma, no puede haber dentro de un paquete dos
elementos del mismo tipo – si de tipos diferentes – con el mismo nombre.
Por otra parte, los paquetes pueden controlar la visibilidad de los elementos que
contienen:
+ Público: Elemento disponible a otros elementos del paquete contenedor o
uno de sus paquetes anidados, y a paquetes que importan el paquete
contenedor.
- Privado:No disponibles fuera del paquete contenedor.
Por lo anteriormente expuesto, los paquetes pueden contener a otros paquetes (se
forman jerarquías de paquetes). Con esto los paquetes anidados tienen acceso al
espacio de nombres del paquete que los contiene, sin embargo no recomendable más
de 3 niveles.
La generalización entre paquetes es muy parecida a la generalización entre clases. !
Un paquete especializado puede usarse en sustitución de un paquete más general, del
cual hereda.
Las dependencias entre paquetes denotan que algún elemento de un paquete depende
de los elementos en otro paquete. Entre paquetes puede haber tres tipos de relaciones
de dependencia:
Importación: modelado como una dependencia estereotipada con <<Import>>
Exportación: modeladas indicando la visibilidad pública en los elementos de
un paquete. No se exporta explícitamente a algún paquete. Se pone público,
para que cualquier otro paquete pueda importarlo.
Acceso: modelado como una dependencia estereotipada con <<Access>>.
Es importante que una relación de fusión (merge) entre dos paquetes especifique que
el contenido del paquete origen (receptor) se extiende con el contenido del paquete
destino. Por lo anteriormente comentado se identifica necesario un mecanismo para
fusionar los contenidos de ambos paquetes, ya que resuelve los conflictos de nombres
mediante especialización y redefinición, es bastante complicado y se define mediante
restricciones (precondiciones) y transformaciones (post-condiciones).
Diagrama de Paquetes
Es un diagrama de estructura cuyo contenido es, principalmente, paquetes y sus
relaciones. La distinción entre los diversos tipos de diagramas de estructura (clases,
objetos y paquetes) es relativa y todos pueden incluir: como nodos del grafo clases,
Interfaces, Instancias o Paquetes; y como arcos o relaciones agregaciones,
asociaciones, composiciones, dependencias, generalizaciones, realizaciones,
dependencias de uso, y fusiones, importaciones y accesos entre paquetes.
Dicho de otra forma, presentan cómo se organizan los elementos de modelado en
paquetes y las dependencias entre ellos, incluyendo importaciones y extensiones de
paquetes; dividiendo un modelo para agrupar y encapsular sus elementos en unidades
lógicas individuales
Características
Cohesivo: proporciona un límite bien definido alrededor de un grupo de elementos
relacionados
Poco acoplado: exportando sólo los elementos que otros paquetes necesitan ver
realmente e importando sólo aquellos elementos necesarios y suficientes para que los
elementos del paquete hagan su trabajo
Agrupación: seccionamiento de elementos con un objetivo común o relaciones
conceptuales fuertes, pertenecientes a un mismo árbol de herencia o a mismo caso de
uso
Simbología
Elementos del diagrama de
paquetes
Conectores del diagrama de
paquetes
Ejemplo práctico: considere el sistema de control de una franquicia de comida
rápida y cree un diagrama de paquetes del mismo, haciendo referencia a una vista
funcional
DIAGRAMAS DE ESTADO
Los diagramas de estado muestran el conjunto de estados por los cuales pasa un
objeto durante su vida en una aplicación en respuesta a eventos (por ejemplo,
mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones.
También ilustran qué eventos pueden cambiar el estado de los objetos de la clase.
Normalmente contienen: estados y transiciones.
En el diagrama de estados o dinámico tenemos que distinguir los siguientes
elementos:
Las diferentes situaciones en que se puede encontrar un objeto(los estados).
Qué cambios de estado son posibles (transiciones).
Cuál es el hecho que los produce (acontecimiento).
COMPONENTES DEL DIAGRAMA DE ESTADO:
Eventos
Un evento es una ocurrencia que puede causar la transición de un estado a otro de un
objeto. Esta ocurrencia puede ser una:
• Condición que toma el valor de verdadero (normalmente descrita como una
expresión booleana). Es un EventoCambio.
• Recepción de una señal explícita de un objeto a otro. Es un EventoSeñal.
• Recepción de una llamada a una operación. Es un EventoLlamada.
• Paso de cierto período de tiempo, después de entrar al estado actual, o de cierta hora
y fecha concretas. Es un EventoTiempo.
Acciones
Una acción es una operación atómica, que no se puede interrumpir por un evento y
que se ejecuta hasta su finalización. Una acción puede ser:
• Una llamada a una operación (al objeto al cual pertenece el diagrama de estado o
también a otro objeto visible),
• La creación o la destrucción de otro objeto,
• El envío de una señal a un objeto.
Actividades
Cuando un objeto está en un estado, generalmente está esperando a que suceda algún
evento. Sin embargo, a veces, queremos modelar una actividad que se está
ejecutando. Es decir, mientras un objeto está en un estado, dicho objeto realiza un
trabajo que continuará hasta que sea interrumpido por un evento. Por lo tanto, una
acción contrasta con una actividad, ya que ésta última puede ser interrumpida por
otros eventos.
Estados
Un estado identifica una condición o una situación en la vida de un objeto durante la
cual satisface alguna condición, ejecuta alguna actividad o espera que suceda algún
evento. Un objeto permanece en un estado durante un tiempo finito (no instantáneo).
Un estado se representa gráficamente por medio de un rectángulo con los bordes
redondeados y con tres divisiones internas. Los tres compartimentos alojan el nombre
del estado, el valor característico de los atributos del objeto en ese estado y las
acciones que se realizan en ese estado, respectivamente. En muchos diagramas se
omiten los dos compartimentos inferiores.
¿POR QUÉ SON IMPORTANTES LOS DIAGRAMAS DE ESTADOS?
El diagrama de estados proporciona una gran cantidad de símbolos y abarca varias
ideas. Los desarrolladores, deben saber la forma en que los objetos se supone se
comportarán, ya que son ellos quienes tendrán que establecer tales comportamientos
en el software.
Los diagramas de estado se aseguran que no tendrán que adivinar lo que se supone
que harán los objetos, con una clara representación de un objeto aumenta la
probabilidad de que el equipo de desarrollo produzca un sistema que cumpla con los
requerimientos.
SIMBOLOGIA
Rectángulo de vértices redondeados que representa a un estado, junto con una línea
continua y una punta de flecha, que representa una transición. Ejemplo:
EJEMPLO
CONCLUSION
El Lenguaje de Modelado Unificado es, sin lugar a duda una de las mejores
alternativas para el diseño y desarrollo de sistemas mediante el empleo de sus
notaciones gráficas e iconos en el diseño de diagramas que hacen más comprensible
el desarrollo del sistema. Este lenguaje unificado de notación (UML) sirve para
especificar, visualizar y documentar esquemas de sistemas de software orientado a
objetos. UML no es un método de desarrollo, lo que significa que no sirve para
determinar qué hacer en primer lugar o cómo diseñar el sistema, sino que
simplemente le ayuda a visualizar el diseño y a hacerlo más accesible para otros. Está
controlado por el grupo de administración de objetos (OMG) y es el estándar de
descripción de esquemas de software.
Se compone de muchos elementos de esquematización que representan las diferentes
partes de un sistema de software. Entre los elementos que se utilizan para crear
diagramas, que representa alguna parte o punto de vista del sistema tenemos los
siguientes:
-Diagrama de casos de uso, que muestra a los actores (otros usuarios del sistema) los
casos de uso (las situaciones que se producen cuando utilizan el sistema) y sus
relaciones.
-Diagrama de clases, que muestra las clases y las relaciones entre ellas.
-Diagrama de secuencia, muestra los objetos y sus múltiples relaciones entre ellos.
-Diagrama de Paquetes, muestra cómo un sistema está dividido en agrupaciones
lógicas mostrando las dependencias entre esas agrupaciones.
-Diagrama de colaboración, que muestra objetos y sus relaciones, destacando los
objetos que participan en el intercambio de mensajes.
-Diagrama de estado, muestra estados, cambios de estado y eventos en un objeto o en
parte del sistema.
-Diagrama de actividad, que muestra actividades, así como los cambios de una a otra
actividad junto con los eventos que ocurren en ciertas partes del sistema.
-Diagrama de componentes, que muestra los componentes de mayor nivel de la
programación (cosas como Kparts o Java Beans).
-Diagrama de implementación, que muestra las instancias de los componentes y sus
relaciones.
-Diagrama de relaciones de entidad, que muestra los datos y las relaciones y
restricciones entre ellos.
UML como todo producto de mercado, ha sido criticado por su falta de semántica
precisa, sin embargo, lo más importante de este lenguaje es su capacidad de
desarrollar, interpretar y diseñar un buen software, indicando las ventajas y
desventajas del mismo. Cada uno de los diagramas de UML son útiles, dependiendo
del objetivo del software; muchos se parecen entre sí, pero cada quien tienen sus
propias cualidades.
BIBLIOGRAFIA
http://www.ecured.cu
https://docs.kde.org
UML diagrama de colaboraciones.pdf
Libro PDF: UML_clase_06_UML_secuencia
http://es.wikipedia.org/wiki/.
http://jams001.blogspot.com/2012/09/diagrama-de-secuencia-y-colaboracion.html
http://www.codecompiling.net/files/slides/UML_clase_05_UML_paquetes.pdf
http://es.slideshare.net/carlosmercado92372/diagrama-de-paquete?next_slideshow=1
http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-i/materiales-de-
clase-1/is1_t09_trans.pdf
http://analisisydiseoiii.blogspot.com/2011/05/diagrama-de-paquetes.html
http://datateca.unad.edu.co/contenidos/204023/Otero_M._s.f._._Diagramas_De_Estad
o.pdf
http://ingsoftwaremartin.blogspot.com/2011/11/ejemplo-de-diagramas-de-
estado.html
Top Related