You are on page 1of 13

UNIVERSIDAD ANDINA DEL CUSCO

FACULTAD DE INGENIERÍA
PROGRAMA ACADEMICO PROFESIONAL DE INGENIERÍA
INDUSTRIAL
TEMA:

LENGUAJE UNIFICADO DE MODELADO

CURSO

:

ALUMNO

:

CODIGO

:

SOFTWARE PARA LA GESTION
JOEL ANDRÉS BLAS MORA
012100536-G

CUSCO – 2015

 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 . para detallar los artefactos en el sistema y para documentar y construir. Se utiliza para definir un sistema. funciones del sistema. y aspectos concretos como expresiones de lenguajes de programación. Es un lenguaje gráfico para: D V E C i s o s p n c e s u a c t m l i r e i f u n z i t c r a a r r u n s i s t e m a  UML ofrece un estándar para describir un "plano" del sistema (modelo). incluyendo aspectos conceptuales tales como procesos de negocio. esquemas de bases de datos y compuestos reciclados.LENGUAJE UNIFICADO DE MODELADO CONCEPTOS PREIMINARES  Lenguaje Unificado de Modelado (UML. por sus siglas en inglés. es el lenguaje en el que está descrito el modelo.  Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. está respaldado por el OMG (Object Management Group). Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad. En otras palabras.

no es programación. UML no es un método de desarrollo. . pero no especifica en sí mismo qué metodología o proceso usar. lo que significa que no sirve para determinar qué hacer en primer lugar o cómo diseñar el sistema.  Mientras que. los cuales muestran diferentes aspectos de las entidades representadas. y tiene un uso limitado en otro tipo de cuestiones de programación.  UML se compone de muchos elementos de esquematización que representan las diferentes partes de un sistema de software. la programación orientada a objetos viene siendo un complemento perfecto de UML. sino que simplemente le ayuda a visualizar el diseño y a hacerlo más accesible para otros.  UML no puede compararse con la programación estructurada.  UML está controlado por el grupo de administración de objetos (OMG) y es el estándar de descripción de esquemas de software. solo se diagrama la realidad de una utilización en un requerimiento. UTILIZACION  Sirve para especificar. es una forma de programar como lo es la orientación a objetos. pero no por eso se toma UML sólo para lenguajes orientados a objetos. visualizar y documentar esquemas de sistemas de software orientado a objetos.UML cuenta con varios tipos de diagramas.Proceso Unificado Racional o RUP). está diseñado para su uso con software orientado a objetos. que representa alguna parte o punto de vista del sistema. Los elementos UML se utilizan para crear diagramas. pues UML significa Lenguaje Unificado de Modelado. programación estructurada.

. d e s t a c a n d o l o s o b j e t o s DrC e OE l a L c A i oB nO e R s A e C n I t r e e l l o s .TIPOS DE DIAGRAMA DIQuA e G mR Au Me sA t r DEa al sl o cs l a sc et os r ye sl a ( or et rloa sc iuo sn ue as r i o s d e l s i s t e m a ) .i v c i ad mad b esi o . DMQ I u A e G s m Rt r Aua Me l soA t s r Da o E b o j b e j t e o t s o sy y s u s su sm r ú e l t a i pc il oe ns e s . q u e p a r t ic ip a n e n e l in t e r c a m b io d e m e n s a je s . oc u r e n en c i e r a s p ar t e s d el s i s t e m a.s asd e í comes t a od o l ys evenc a m bt oi s end e u n oba a j e ott o r ao ac t i v i d ad j u n t o con l o s even t o s q u e AenD CE TIpE arVS IT tD Ae D deO l s i s t e m a.USs u sO r e l a c i o n e s . l o s c a s o s d e u s o ( l a s s i t u a c i o n e s q u e s e p r o d u c e n c u a n d o u t i l z a n e l Ces inALs ttSre Oe mESe alDE)a ys . SÓ E N C U E N C I A MQD IuA eesG mRt rAua M esA rt Da dE acos t .

DQ Iu A e G m R A u M e s A t r a l ao s Dcl a o E mp r p o og n r a e m n t a e c s i ó y n s CI M O P M L EP MO NE NE NT A T EC SI Ó     N El lenguaje UML se ic n o s m t a p n o c n i a e s n (u c s o rs e a l s a c c i o o m n expresa con t d e e s l d o es m a y o r n i v e l d e e o s K. Podemos establecer una clasificación de estos dividiéndolos en Estructurales y de Comportamiento. . símbolos y/o agrupaciones de estos llamadas diagramas. En el estándar UML 2. y dentro de los de comportamiento tendríamos a los de Interacción.0 se nos habla de un grupo de diagramas determinado que son los más comunes y habituales. p a r t s o J a v a B e a n s ) . Nos sirve fundamentalmente para crear diferentes tipos de ellos permitiéndonos ver desde diferentes perspectivas un sistema software.

El UML hace que esta sea algo tangible. Cada una de ellas nos ofrece diferente información sobre el sistema software:  VISTA DE CASOS DE USO: Nos facilita información sobre el comportamiento y funcionalidad del sistema.  VISTA DE INTERACCIÓN: . en la construcción del mismo y en su posterior despliegue.  Los diagramas son de gran utilidad para trabajar en los requisitos. Siendo el resultado de agrupar los diferentes diagramas en lo que llamamos vistas. de estos a su vez heredan los trece diferentes tipos de diagramas más comunes. Nos permitirán conocer ese concepto del que tanto se habla y que parece tan difícil de determinar que es la Arquitectura del Sistema.  VISTA DE DISEÑO: Nos proporciona información del vocabulario y la funcionalidad del sistema. Estas vistas forman la Arquitectura del Sistema. Existe un tipo primordial que es “Diagrama UML” del cual heredan “Diagrama Estructural” y “Diagrama Comportamiento”. existiendo un tipo intermedio que serían los “Diagrama de Interacción”.Nótese que en el gráfico anterior estamos usando la propia notación UML. en el análisis del sistema.

Nos da información sobre el rendimiento del sistema. Así podemos apreciar que UML nos servirá para reflejar la arquitectura del sistema en un momento del tiempo dado.  Es famosa la frase: “El 80% de los problemas se resuelve con un 20% de UML”. Lo que significará que nuestros diagramas irán cambiando. Es posible que el sistema que estamos desarrollando quede definido con solo algunos de ellos. quedando cada vez más definida.  VISTA DE IMPLEMENTACIÓN: Establece el ensamblado del sistema y la gestión de la configuración. Esto dependerá del tipo y tamaño del sistema que pretendamos crear. ni todos los símbolos. este será el objetivo a la hora de crear software.  Lo normal será que en versiones o iteraciones posteriores del software que estamos creando esta arquitectura evolucione. la escalabilidad del mismo y la capacidad de procesamiento necesaria. conseguir plantear la arquitectura del sistema mediante diagramas UML. Además no es obligatorio usar todos los diagramas. Conviene advertir aquí que el proceso de creación de software es un proceso iterativo e incremental. ya que son estos los que la definen. Los diagramas más importantes para definir la arquitectura de un .  Por lo tanto.

Diagramas de Comportamiento o Interacción. binario y ejecutable. ARTEFACTOS PARA EL DESARROLLO DE PROYECTOS  Un artefacto es una información que es utilizada o producida mediante un proceso de desarrollo de software. incluyendo componentes de código fuente. Pueden ser artefactos un modelo. Diagramas de Clases. siendo interesantes también los diagramas de Componentes y los diagramas de Despliegue. junto con la documentación sobre el sistema constituyen los artefactos principales que el modelador puede observar. binario o ejecutable) que se utiliza para mostrar dependencias en tiempo de compilación. diagramas de Actividad.sistema son: diagramas de Casos de Uso. una descripción o un software. éstos. UML utiliza los diagramas gráficos para obtener estos distintos puntos de vista de un sistema: Diagramas de Implementación. diagramas de Clases.  Se necesita más de un punto de vista para llegar a representar un sistema. . diagramas de Secuencia. DIAGRAMAS DE COMPONENTES Muestra la dependencia entre los distintos componentes de software. Diagramas de Casos de uso. Un componente es un fragmento de código software (un fuente. diagramas de Estructura Compuesta y diagramas de Estado. Los artefactos de UML se especifican en forma de diagramas.

DIAGRAMAS DE INTERACCIÓN O COMPORTAMIENTO Muestran las interacciones entre objetos ocurridas en un escenario (parte) del sistema. Hay varios tipos:  Diagrama de secuencia. los elementos de procesamiento en tiempo de ejecución y los objetos que existen en tiempo de ejecución.  Diagrama de actividad.  Diagrama de colaboración. Un nodo es un objeto físico en tiempo de ejecución. memoria y capacidad de procesamiento.  Diagrama de secuencia. En este tipo de diagramas intervienen nodos.Diagrama De Plataformas O Despliegue Muestra la configuración de los componentes hardware. asociaciones de comunicación. DIAGRAMA DE SECUENCIA . es decir una máquina que se compone habitualmente de. a su vez puede estar formado por otros componentes. los procesos. componentes dentro de los nodos y objetos que se encuentran a su vez dentro de los componentes. por lo menos.  Diagrama de estado.

Muestran las interacciones entre un conjunto de objetos. ordenadas según el tiempo en que tienen lugar. En este tipo de diagramas también intervienen los mensajes. A diferencia de un diagrama de secuencias. Existen distintos tipos de mensajes según cómo se producen en el tiempo: A S i í s m n í p c n l r c e o r s n o o n s o s . En los diagramas de este tipo intervienen objetos. pero en una forma . Los diagramas de secuencias y los diagramas de colaboraciones expresan información similar. Los diagrama de secuencia permiten indicar cuál es el momento en el que se envía o se completa un mensaje mediante el tiempo de transición. es decir son instancias concretas de una clase que participa en la interacción. un diagrama de colaboraciones muestra las relaciones entre los objetos. El objeto puede existir sólo durante la ejecución de la interacción. no la secuencia en el tiempo en que se producen los mensajes. que son la forma en que se comunican los objetos: el objeto origen solicita (llama a) una operación del objeto destino. se puede crear o puede ser destruido durante la ejecución de la interacción. que tienen un significado parecido al de los objetos representados en los diagramas de colaboración. DIAGRAMA DE COLABORACIÓN  Muestra la interacción entre varios objetos y los enlaces que existen entre ellos. Representa las interacciones entre objetos organizadas alrededor de los objetos y sus vinculaciones. Un diagrama de secuencia representa una forma de indicar el período durante el que un objeto está desarrollando una acción directamente o a través de un procedimiento. que se especifica en el diagrama.

Los diagramas de actividad se utilizan para mostrar el flujo de operaciones que se desencadenan en un procedimiento interno del sistema.  Formando parte de los diagramas de colaboración nos encontramos con objetos. existen objetos simples y complejos.diferente. . El enlace puede ser reflexivo si conecta a un elemento consigo mismo. En realidad se corresponden con un caso especial de los diagramas de estado donde los estados son estados de acción (estados con una acción interna y una o más transiciones que suceden al finalizar esta acción. mientras que un objeto es pasivo si mantiene datos pero no inicia la actividad. Un enlace es una instancia de una asociación que conecta dos objetos de un diagrama de colaboración. DIAGRAMAS DE ACTIVIDAD  Son similares a los diagramas de flujo de otras metodologías OO. un paso en la ejecución de lo que será un procedimiento) y las transiciones vienen provocadas por la finalización de las acciones que tienen lugar en los estados de origen. La existencia de un enlace entre dos objetos indica que puede existir un intercambio de mensajes entre los objetos conectados.  Siempre van unidos a una clase o a la implementación de un caso de uso o de un método (que tiene el mismo significado que en cualquier otra metodología OO). Un objeto es una instancia de una clase que participa como una interacción. Un objeto es activo si posee un thread o hilo de control y es capaz de iniciar la actividad de control. enlaces y mensajes. o lo que es lo mismo.

no se provoca un cambio de estado y se representan dentro del estado. existen varios tipos de transiciones entre objetos: simples (normales y reflexivas) y complejas.DIAGRAMAS DE ESTADO  Representan la secuencia de estados por los que un objeto o una interacción entre objetos pasa durante su tiempo de vida en respuesta a estímulos (eventos) recibidos. DIAGRAMAS DE CASOS DE USO  Unos casos de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Una relación es una conexión entre los elementos del modelo. Un estado en UML es cuando un objeto o una interacción satisface una condición. desarrolla alguna acción o se encuentra esperando un evento. un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Representa lo que podemos denominar en conjunto una máquina de estados. en este caso es la acción de la que puede enviar mensajes a uno o varios objetos destinos. Además una transición puede ser interna si el estado del que parte el objeto o interacción es el mismo que al que llega. O lo que es igual. Como en todas las metodologías OO se envían mensajes.  Cuando un objeto o una interacción pasa de un estado a otro por la ocurrencia de un evento se dice que ha sufrido una transición. por ejemplo la relación y la generalización son relaciones. . no de la transición. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y/o otros sistemas.

las empresas pueden utilizar UML como el lenguaje para definir sus propios procesos y lo único que tendrán en común con otras organizaciones que utilicen UML serán los tipos de diagramas.edu. Análisis y Diseño Orientado a Objetos. En este tipo de diagrama intervienen algunos conceptos nuevos: un actor es una entidad externa al sistema que se modela y que puede interactuar con él. Addison-Wesley / Díaz de Santos.uniandes. 2da edición. Los procesos de desarrollo deben ser definidos dentro del contexto donde se van a implementar los sistemas. Las relaciones entre casos de uso y actores pueden ser las siguientes:  Un actor se comunica con un caso de uso. 1996. Robert. Ed.com/uml/ . http://agamenon. Pressman. CONCLUSION UML no define un proceso concreto que determine las fases de desarrollo de un sistema.  Un caso de uso extiende otro caso de uso. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar como reacciona una respuesta a eventos que se producen en el mismo.rational. BIBLIOGRAFIA Booch. un ejemplo de actor podría ser un usuario o cualquier otro sistema. Grady.  Un caso de uso usa otro caso de uso. UML es un método independiente del proceso. Ingeniería de Software.co/~pfigueroa/soo/uml http://www. 1998.