Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

UML Lenguaje Unificado de Modelado

tutorial de UML
by

Sandra Milena Vargas Perilla

on 26 October 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of UML Lenguaje Unificado de Modelado

UML Orientación a objetos Introducción a UML Lenguaje Unificado de Modelado UML, por sus siglas en inglés, (Unified Modeling Language) es el lenguaje de modelado de sistemas software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group) Grupo de manejo de Objetos. Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. Los objetos simulan a los objetos del mundo
Objeto es la instancia de una clase , ejemplo usted y yo somos una instancia de la clase persona
Objeto cuenta con una estructura- atributos y acciones
Clase es una plantilla para generar objetos, imaginemos un molde de galletas que produce muchas galletas
La Clase se escribe en mayúscula las iniciales Ejemplo clase: LavadorIndustrial
Las Características se escribe las primeras en minúscula numeroSerie Los objetos tienen dos características, que son su estado y su comportamiento. El estado es una situación en la que se encuentra el objeto, tal que cumple con alguna condición o condiciones particulares, realiza alguna actividad o espera que suceda un acontecimiento. Una tostadora puede estar encendida y cargada de pan y, en cuanto a su comportamiento, lo normal en este estado es tostar pan. Objetos Clases Todos los objetos que son del mismo tipo, comparten el mismo juego de atributos y métodos (aunque cada objeto pueda tener un valor distinto asociado a cada atributo) y por tanto pertenecen a una misma clase. Las clases son como patrones que definen qué atributos y qué métodos son comunes a todos los objetos de un mismo tipo. Sobrecarga: la sobrecarga se usa en solo una clase, y se da cuando utilizamos varias funciones con el mismo nombre pero le llegan diferentes atributos, así dependiendo del atributo podemos identificar la función que queremos utilizar.
Herencia: es el mecanismo que permite a una clase de objeto tomar métodos y atributos de otra clase, y añadirlos a los que ya posee.
Este además posee ventajas como la reutilización de código y el fácil mantenimiento de aplicaciones existentes.Clase es una categoría de un objeto, como instancia de una clase un objeto tiene todas las características del objeto que proviene,”herencia”, cada objeto de la clase hereda dichos atributos y operaciones.
Una objeto no solo hereda una clase , sino que una clase también hereda de otra,
Lavadora , refrigerador , y horno microondas son clases y forman parte de una mas genérica llamada Electrodomésticos Orientación a objetos Polimorfismo: es el mecanismo que nos permite definir e invocar funciones idénticas en denominación e interfaz, pero con implementación diferente, diferentes versiones de un mismo método.

Encapsulamiento: es un mecanismo de la programación que permite mantener los atributos de los objetos como privados y proporcionar acceso a los mismos a través de métodos públicos (métodos de acceso) así se protegen los atributos del acceso directo desde el exterior, forzando que el acceso a dichos atributos sea solo a través de métodos, previniendo la corrupción de datos.
Una lavadora tiene diversas perillas que le permiten establecer niveles de temperatura y agua. Los botones y perillas de la televisión y la lavadora se les conocen como interfaces

Abstracción:quitar las propiedades y acciones de un objeto solo para dejar aquellas que sean necesarias
Los objetos funcionan conjuntamente con el envío de mensajes entre ellos. Los mensajes son peticiones para realizar operaciones Orientación a objetos Herencia Los bloques básicos de construcción de UML son tres, los elementos, las relaciones y los diagramas. - Bloques básicos de construcción de UML •Los elementos son abstracciones que actúan como unidades básicas de construcción. Hay cuatro tipos, los estructurales, los de comportamiento, los de agrupación y los de notación.

En cuanto a los elementos estructurales son las partes estáticas de los modelos y representan aspectos conceptuales o materiales.

Los elementos de comportamiento son las partes dinámicas de los modelos y representan comportamientos en el tiempo y en el espacio.

Los elementos de agrupación son las partes organizativas de UML, establecen las divisiones en que se puede fraccionar un modelo. Sólo hay un elemento de agrupación, el paquete, que se emplea para organizar otros elementos en grupos. Los elementos de notación son las partes explicativas de UML, comentarios que pueden describir textualmente cualquier aspecto de un modelo. Sólo hay un elemento de notación principal, la nota. Elementos Elementos Asociación: cuando una clase se conecta entre si de forma conceptual
Restricciones en las asociaciones: en ocasiones una asociación entre dos clases debe seguir ciertas reglas esta se indica al establecer una restricción junto a una linea de asociación.
una asociación puede tener atributos y operaciones,puede se una clase asociación. , puede concebir a una clase asociaciones como una clase estándar , con una línea discontinua. Relaciones Asociaciones calificadas información de identidad , cuando la multiplicidad de una asociación es de uno a muchos, se presenta la búsqueda, cuando un objeto de una clase tiene que seleccionar un objeto particular de otro tipo para cumplir con un papel en la asociación, la primera clase deberá atenerse a un atributo en particular para localizar al objeto adecuado.

La idea es reducir , con eficiencia , la multiplicidad de uno a muchos a una multiplicidad de uno a uno.

asociaciones reflexivas clase tiene una asociación consigo misma. Cuando una clase tiene objetos que pueden jugar diversos papeles. Relaciones Multiplicidad la cantidad de objetos de una clase que se relación con un objeto de la clase uno a uno, uno a muchos, uno a ninguno, uno a mas, uno a un intervalo definido Multiplicidad Los modelos nos ayudan a visualizar como es o como queremos que sea un sistema.
Los modelos nos permiten especificar la estructura o el comportamiento de un sistema.
Los modelos nos proporcionan plantillas que nos guían en la construcción de un sistema.
Los modelos documentan las decisiones que hemos adoptado.
Construimos modelos de sistemas complejos porque no podemos comprender el sistema en su totalidad.
En general los modelos nos ayudan a organizar, visualizar, comprender y crear sistemas complejos. Importancia UML Herencia y generalización, la clase secundaria puede heredar los atributos y operaciones de otra, la clase principal o superclase. En la generalización un clase hija es sustituible por una clase principal, es decir donde quiera que halla referencia de la clase madre , también se hace referencia a la clase hija.
Si una clase tiene exactamente solo una clase principal tiene herencia simple de lo contrario tiene herencia múltiple.
Las clases abstractas no proporcionan ninguna instancia al modelo . Una clase abstracta se define por tener su nombre en cursiva.
Dependencias en otro tipo de relación una clase utiliza a otra, el uso mas común de una dependencia es mostrar que la firma de la operación utiliza a otra. Relaciones Relaciones Diagramas Diagramas Los diagramas de clases muestran un resumen del sistema en términos de sus clases y las relaciones entre ellas. Son diagramas estáticos que muestran qué es lo que interactúa, pero no cómo interactúa o qué pasa cuando ocurre la interacción.

El siguiente diagrama modela los pedidos de un cliente a una tienda de venta por catálogo. La clase principal es “Pedido”, asociada a un cliente, una forma de pago y un conjunto de artículos. Diagrama de clases Los diagramas de Casos de Uso describen lo que hace un sistema desde el punto de vista de un observador externo, enfatizando el qué más que el cómo. Plantean escenarios, es decir, lo que pasa cuando alguien interactúa con el sistema, proporcionando un resumen para una tarea u objetivo. El siguiente Caso de Uso describe como Carlos va a desayunar (este es su objetivo), para lo que se plantea el escenario de preparar su café y el pan tostado diagrama de casos de uso Los diagramas de estados muestran los posibles estados en que puede encontrarse un objeto y las transiciones que pueden causar un cambio de estado. El estado de un objeto depende de la actividad que esté llevando a cabo o de alguna condición.
Las transiciones son las líneas que unen los diferentes estados. En ellas se representa la condición que provoca el cambio, seguida de la acción oportuna separada por “/”. En un estado en que el objeto esta pendiente de algún tipo de validación que dependa de un proceso en curso, no es necesario evento externo alguno para que se produzca la transición, ya que ésta ocurrirá cuando termine el proceso, en función del resultado de éste. En estos casos es conveniente, por claridad, incluir la condición que de la que depende la transición (entre corchetes).

Los estados inicial, a partir del que se “entra” en la máquina de estados, y final, que indica que la máquina de estados termina, no tienen otro significado adicional, son elementos ornamentales y se representan mediante un circulo negro y un circulo negro resaltado respectivamente. diagrama de estados Los diagramas de secuencia describen como los objetos del sistema colaboran. Se trata de un diagrama de interacción que detalla como las operaciones se llevan a cabo, qué mensajes son enviados y cuando, organizado todo en torno al tiempo. El tiempo avanza “hacia abajo” en el diagrama. Los objetos involucrados en la operación se listan de izquierda a derecha de acuerdo a su orden de participación dentro de la secuencia de mensajes. Diagrama de Secuencia y
Diagrama de Colaboración Los diagramas de actividades son básicamente diagramas de flujo adornados, que guardan mucha similitud con los diagramas de estados. Mientras que los diagramas de estados centran su atención en el proceso que está llevando a cabo un objeto, los diagramas de actividades muestran como las actividades fluyen y las dependencias entre ellas.

Los diagramas de actividades pueden dividirse en “calles” que determinan qué objeto es responsable de qué actividad. Las actividades vienen unidas por transiciones, que pueden separarse en ramas en función del resultado de una condición expresada entre corchetes. Cada rama muestra la condición que debe ser satisfecha para que el flujo opte por ese camino. Igualmente, las transiciones se pueden bifurcarse en dos o más actividades paralelas. diagrama de actividades Los componentes son módulos de código, así que los diagramas de componentes vienen a ser los análogos físicos a los diagramas de clases. Muestran como está organizado un conjunto de componentes y las dependencias que existen entre ellos Diagrama de componentes UML es simplemente un lenguaje de modelado. Define un conjunto de elementos y relaciones entre ellos, que se emplean en la definición de modelos. UML es típicamente usado como parte de un proceso de desarrollo, con la ayuda de una herramienta CASE (Computer Aided Software Engineering) Ingeniería de Software asistida por computador, para definir requerimientos, interacciones y elementos del software que se está desarrollando. UML es independiente de cualquier proceso particular, no está ligado a ningún ciclo de vida de desarrollo del software concreto, no obstante se obtienen mayores beneficios si se selecciona un proceso que esté dirigido por Casos de Uso, se centre en la arquitectura y sea incremental. UML La clase “Pago” es abstracta, en UML los nombres de clases abstractas se representan en Itálica. Las clases abstractas actúan a modo de interfaz, proporcionando únicamente un listado de métodos a ser “realizados” por las clases que las implementan o realizan. “Pago” es una superclase especializada, y a la vez realizada, por sus formas más comunes “Crédito” y “Efectivo”. Un “Pedido” tiene una única forma de pago, expresada por su multiplicidad, 1, mientras que una forma de pago puede estar presente en uno o más pedidos, como sugiere su multiplicidad, 1..*. En cuanto a las asociaciones, observamos que algunas vienen representadas como una flecha navegable, cuya orientación expresa el sentido en que se consultan los datos. Las asociaciones sin flecha son bi-direccionales. Las agregaciones expresan “conjunto de”; la relación entre “Pedido” y “Articulo” es de conjunto. Un pedido es una agregación de una o más líneas de pedido, donde cada una hace alusión a un artículo concreto, así mismo una línea de pedido puede estar presente en varios pedidos y un artículo puede no haber sido solicitado nunca. Así mismo se puede observar que las clases vienen representadas por cajas en las que hay tres separaciones, o compartimentos. El primero se emplea siempre para indicar el nombre de la clase, el segundo para mostrar los atributos y el tercero para los métodos. Tanto los atributos como los métodos vienen precedidos por un símbolo de acceso, que normalmente suele ser un “+” para el acceso público, un “-” para el acceso privado, (sólo por otros métodos de la clase) y un “#” para el acceso protegido (sólo por clases hija), aunque la herramienta empleada en la elaboración del tutorial traduce estos elementos en iconos.

Los atributos tienen un tipo que puede mostrarse a continuación de su nombre separado por “:”. De igual manera, los métodos pueden devolver un elemento de un tipo determinado y recibir parámetros, expresados entre paréntesis mediante el nombre del parámetro y el tipo, separados por “:”. Para el caso de múltiples parámetros, se separan por comas (p1:t1, p2:t2 ... pn:tn). Los parámetros que tienen un valor por defecto se expresan mediante un “=” y el valor, a continuación del tipo (p1:t1=v1) y si un parámetro en la posición “i” de la lista de parámetros tiene valor por defecto, todos los parámetros que le sigan, es decir que ocupen posiciones sucesivas a “i” en la lista, deberán tener también un valor por defecto.

Los atributos y métodos estáticos (de clase) se representan mediante un subrayado (en el caso de los métodos se puede emplear el estereotipo <<static>>, los estereotipos se ven más adelante). En los Casos de Uso, los Actores son papeles que determinadas personas u objetos desempeñan. Se representan mediante un “hombre de palitos”, de modo que en el ejemplo, Carlos es un Actor. Los Casos de Uso se representan por medio de óvalos y las líneas que unen Actores con Casos de Uso representan una asociación de comunicación.
Por su puesto, un Caso de Uso puede ser descrito en mayor profundidad. Por ejemplo si tomamos por separado “Preparar pan” y “Preparar cafe”, podemos bajar un nivel de descripción y llegar a los siguientes Casos de Uso. Los Casos de Uso suelen venir delimitados por fronteras o límites, que definen una separación entre lo que es realmente la funcionalidad del sistema y los actores que la usan o colaboran en su desempeño. En las figuras, esta separación viene representada por medio de la caja que encapsula los óvalos.

Los Casos de Uso son acompañados por una explicación textual que clarifica las posibles cadencias del lenguaje meramente gráfico. De esta manera, combinando Casos de Uso y explicación textual, se puede obtener escenarios no ambiguos, que resultan ideales en la captura de requisitos de usuario, dada su sencillez de comprensión incluso por quien no está familiarizado con UML. Los Casos de Uso se emplean también en la preparación de escenarios de pruebas con que verificar el software una vez ha sido construido. El siguiente Caso de Uso es equivalente al primero, “Desayuno”, sólo que en él se ha condensado la máxima cantidad posible de información. En él se muestra un nuevo elemento que hasta ahora no se había mostrado, el “estereotipo”, que viene entre sendos símbolos angulados “<<” y “>>” y concreta un paso más allá el tipo de relación existente entre dos Casos de Uso. Encontramos dos estereotipos <<include>> y <<extend>>. Las líneas verticales o “líneas de la vida” representan el tiempo de vida del objeto. La vida del objeto “carlos” no termina en este diagrama, sin embargo la del objeto “tosty” sí y esto viene representado mediante el aspa al final de su línea de la vida.

Los rectángulos verticales son barras de activación y representan la duración de la ejecución del mensaje. Los diagramas de colaboración son otro tipo de diagramas de interacción, que contiene la misma información que los de secuencia, sólo que se centran en las responsabilidades de cada objeto, en lugar de en el tiempo en que los mensajes son enviados. Cada mensaje de un diagrama de colaboración tiene un número de secuencia. El primer nivel de la secuencia es 1, y los mensajes que son enviados durante la misma llamada a un método se numeran 1.1, 1.2 y así sucesivamente para tantos niveles como sea necesario. Diagrama de colaboración
Los estados de un diagrama de estados pueden anidarse, de forma que los estados relacionados pueden ser agrupados en un estado compuesto. Esto puede ser necesario cuando una actividad involucra sub-actividades asíncronas o concurrentes. Por
Andrés Leonardo Moreno Moreno Un ejemplo de proceso para la construcción de un programa:

1.Iniciar y mantener reuniones con los usuarios finales del programa, para comprender sus necesidades, el contexto en que lo usarán y todos los detalles necesarios para comprender el ámbito del problema a resolver. Esta información será empleada para capturar las actividades y procesos involucrados y susceptibles de ser incorporados en el programa, a un nivel alto, y proporcionará la base para construir la vista de Casos de Uso.

2.Construir la vista de Casos de Uso definiendo exactamente la funcionalidad que se va a incorporar en el programa, desde el punto de vista de sus usuarios. El modelo resultante es realmente un mapeo de la información obtenida en el paso anterior, en el que cada nuevo Caso de Uso realiza un aspecto de la funcionalidad planteada. Refinar, en conjunto con los usuarios finales, todos los diagramas de Casos de Uso, incluyendo requisitos y restricciones, para llegar a un acuerdo común en lo que el programa hará y no hará. En este punto puede ser conveniente diseñar escenarios de prueba que ayuden a verificar si el programa finalizado cumple con las expectativas del contrato.

3.Partiendo del modelo de Casos de Uso se comienza a estructurar los requisitos en una arquitectura llamada “línea base”. Se definen clases y relaciones entre ellas, los primeros diagramas de secuencia y colaboración, definiendo los comportamientos de cada clase, también las interfaces entre los diferentes elementos de la arquitectura. Se construye aquí la vista de diseño y la vista de procesos. Construir diagramas de clases más elaborados y refinar los comportamientos del sistema.

4.A medida que crece el modelo se puede fraccionar en componentes software y paquetes. Aparecen nuevos requisitos que deben ser integrados. Se define la vista de despliegue, que define la arquitectura física del sistema, y la vista de implementación.

5.Construir el sistema, repartiendo las tareas entre el equipo de programación.

6.Buscar errores de programación, o incluso de diseño, corregirlos e ir sacando sucesivas versiones del programa hasta llegar a una versión que cumpla con todos los requisitos especificados en el contrato con los usuarios.

7.Documentar y entregar el programa a los usuarios finales.
Full transcript