• Author / Uploaded
• Luis Morales

• Categories
• Objeto (informática)
• Lenguaje de modelado unificado
• Caso de uso
• Herencia (Programación Orientada a Objetos)
• Software

Citation preview

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.

 

2.

. Objetos de control. 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: >.



Herencia hueca en el extremo que apunta a la superclase.

EJEMPLO:

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

“

”

SIMBOLOGIA

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.

Ejemplo:

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



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 .

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

Anexos

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-declase-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-deestado.html