Vous êtes sur la page 1sur 31

UML

OMG (Object Management


Group)
 Organización sin fines de lucro formado en
1989 dedicado al cuidado de estándares de
tecnologías orientados a objetos

 Su método de trabajo se basa en


investigación, análisis y planificación, con el
objeto de anticipar situaciones de mercado y
producir soluciones concretas

 Estandares conocidos bajo OMG: UML, XMI,


CORBA y BPMN
Concepto UML
 UML (Unified Modeling Language) es un lenguaje
de notacion grafica para describir de forma
descriptiva sistemas de software

 Es empleado para especificar y visualizar los


requisitos iniciales, construir el detalle de diseño e
instalación, y documentar las diferentes etapas
del desarrollo de sistema de software.

 UML incrementa la capacidad de lo que se


puede hacer con otros métodos de análisis y
diseño orientados a objetos
Concepto UML
 Literalmente viene a ser un ‘plano’ del sistema de software
propuesto a un usuario especifico (cliente u entidad que
requiere servicios de ingeniero).

 Desde un punto de vista psicológico, un usuario espera


tranquilizarse durante una reunión de planificacion de un
proyecto y los ingenieros encargados mantenien la calma
y confienza al cliente mediante dicho ‘plano’

 ¿Cuando estará terminado el sistema? ¿Estará ajustada al


costo? ¿Estamos atrasados? Digan de nuevo ¿como es
que se va a hacer esto? Son la preguntas habituales que
incurre un usuario
Concepto UML
 Estos ‘planos’ son conocidos como
diagramas o presentación visual de
elementos y relaciones en sintaxis UML.

 Existen gran variedad de diagramas dentro


de UML por lo que estos a su vez, son objeto
de clasificación, presentando informacion
estructural o estatica versus información
dinámica o del comportamiento del sistema.
Modelo
«Un modelo es la simplificación de la realidad»
Dentro de la construccion del software, el
modelo contribuye a:

 Comunicar la estructura de trabajo


 Especificar el comportamiento deseado del
sistema
 Comprender mejor la construccion del
software
 Descubrir oportunidades de simplificacion y
reutilizacion
Notación
 La notación es la parte gráfica que se ve
en los modelos y representa la sintaxis del
lenguaje de modelado
 Suelen ser los nombres de atributos y
propiedades dentro de los objetos, así
como parámetros o variables de entrada
o salida, nivel de multiplicidad (1 a 1, 1 a
muchos, varios a muchos)
Etapas en el desarrollo
orientado a objetos
En la versión definitiva de la metodología
publicada por Booch, Rumbaugh y Jacobson se
pueden tener en cuenta las siguientes etapas:
· Análisis de Requerimientos
· Diseño del sistema
· Diseño detallado
· Implementación y pruebas
Cada etapa consta de actividades que le dan
cuerpo y los documentos que se esperan al final
de cada una de ellas.
Fases de descomposición
1. Planificación y Especificación de Requisitos: Planificación, definición de
requisitos, conocer los procesos del dominio, etc.
2. Construcción: La construcción del sistema. Se subdivide en las siguientes:
 Análisis: Se analiza el problema a resolver desde la perspectiva de los
usuarios y de las entidades externas que van a solicitar servicios al
sistema.
 Diseño: El sistema se especifica en detalle, describiendo cómo va a
funcionar internamente para satisfacer lo especificado en el análisis.
 Implementación: Se lleva lo especificado en el diseño a un lenguaje de
programación.
 Pruebas: Se llevan a cabo una serie de pruebas para corroborar que el
software funciona correctamente y que satisface lo especificado en la
etapa de Planificación y Especificación de Requisitos.

3. Instalación: La puesta en marcha del sistema en el entorno previsto de uso.

.
Diagramas para modelar el
Comportamiento del Sistema
 Diagrama de Casos de Uso: Muestra un conjunto
de casos de uso y actores y sus relaciones.
 Diagrama de Secuencia: Diagrama de
interacción con la relación temporal de los
mensajes y los objetos.
 Diagrama de Colaboración: Diagrama de
interacción que resalta la organización estructural
de los objetos que envían y reciben mensajes.
 Diagrama de Estados: Muestra una máquina de
estados, que consta de estados, transiciones,
eventos y actividades. Vista dinámica del sistema.
 Diagrama de Actividades: Muestra el flujo de
actividades dentro de un sistema.
Diagramas para modelar la
Estructura del Sistema
 Diagrama de Clases: Muestra un conjunto de
clases, interfaces y colaboraciones, así como
sus relaciones.
 Diagrama de Objetos: Muestra un conjunto
de objetos y sus relaciones.
 Diagrama de Componentes: Muestra la
organización y las dependencias entre un
conjunto de componentes.
 Diagrama de Despliegue: Representa la
infraestructura de un sistema en tiempo de
ejecución.
Diagrama de Casos de uso
 Los diagramas de casos de uso sirven para
especificar la comunicación y el
comportamiento de un sistema mediante su
interacción con los usuarios y/u otros
sistemas.

 Visualiza el problema desde el punto de vista


de un Cliente (Actor) y de como este opera
con el sistema en pleno desarrollo, además
de la forma, tipo y secuencia en como los
elementos llegan a interactuar (operaciones
o casos de uso).
Diagrama de Casos de uso
Un diagrama de casos de uso consta de los
siguientes elementos:
 Actor
 Casos de uso
 Relaciones de uso, Herencia y
comunicacion
Elementos de Diagrama de
caso de uso
ACTOR

 Es un rol que un usuario juega con respecto al


sistema

 Un Actor no necesariamente representa a una


persona en particular, sino más bien la labor que
realiza frente al sistema.

 Como ejemplo, en un sistema de ventas en que el


rol de Vendedor con respecto al sistema puede ser
realizado por un Vendedor o bien por el Jefe de
Local.
Elementos de Diagrama de
caso de uso
 Caso de uso
 Es una operación/tarea específica que se realiza tras una orden de algún
agente externo, sea desde una petición de un actor o bien desde la
invocación desde otro caso de uso.

 Ejemplo: el técnico me enseñó el uso del ordenador nuevo

 De este ejemplo, podemos describir los pasos o secuencia de actividades


que deberán realizarse para llevar a cabo el proceso : «Enseñar uso de
ordenador nuevo» , en respuesta aun evento que inicio el actor principal
«tecico» sobre el propio sistema

 Se deriva de:
 Caso: hace referencia a situacion, fenomeno ambiental que ocurre
actualmente
 Uso: Como va a funcionar o se va a utilizar un objeto físico (puede ser un
aparato o maquina de sistema)
Elementos de Diagrama de
caso de uso
 Asociación Es el tipo de relación más
básica que indica la invocación desde
un actor o caso de uso a otra operación
(caso de uso). Dicha relación se denota
con una flecha simple.
Elementos de Diagrama de
caso de uso
 Dependencia o Instanciación Es una
forma muy particular de relación entre
clases, en la cual una clase depende de
otra, es decir, se instancia (se crea).
Dicha relación se denota con una flecha
punteada.
Elementos de Diagrama de
caso de uso
 Generalización Este tipo de relación es
uno de los más utilizados, cumple una
doble función dependiendo de su
estereotipo, que puede ser de Uso
(<<uses>>) o de Herencia (<<extends>>).
Elementos de Diagrama de
caso de uso
 Tipos de relación
 Inclusión: Un caso de uso base incorpora
explícitamente el comportamiento de otro en
algún lugar de su secuencia.
 extends: Se recomienda utilizar cuando un
caso de uso es similar a otro (características).
 uses: Se recomienda utilizar cuando se tiene
un conjunto de características que son
similares en más de un caso de uso y no se
desea mantener copiada la descripción de
la característica.
Resumiendo casos de uso
 Intentaexplicar y detallar las funciones
de un sistema a los usuarios externos
Requerimientos
 Antes de empezar a diagramar, se
requiere indicaciones de como se va a
desarrollar
 Se necesita definir adecuadamente
quienes seran los actores y cuales seran
los casos de uso
Requerimientos
Requerimientos
Resumiendo casos de uso
 Primero se empieza a diagramar casos de
uso
 Mas adelante (de preferencia al culminar
los diagramas de casos de uso), se
empieza a documentar las los eventos de
negocios a nivel de usuario, indicando
como se interactuaron con los casos de
uso
Ejemplo de caso de uso
Maquina recicladora
 Sistema que controla una máquina de reciclamiento de
botellas, tarros y jabas. El sistema debe controlar y/o aceptar:
 Registrar el número de ítems ingresados.
 Imprimir un recibo cuando el usuario lo solicita:
 Describe lo depositado
 El valor de cada item
 Total
 El usuario/cliente presiona el botón de comienzo
 Existe un operador que desea saber lo siguiente:
 Cuantos ítemes han sido retornados en el día.
 Al final de cada día el operador solicita un resumen de todo lo
depositado en el día.
 El operador debe además poder cambiar:
 Información asociada a ítemes.
 Dar una alarma en el caso de que:
 Item se atora.
 No hay más papel.
Ejemplo de caso de uso
 Como una primera aproximación
identificamos a los actores que
interactuan con el sistema:
Ejemplo de caso de uso
 Luego,tenemos que un Cliente puede
Depositar Items y un Operador puede
cambiar la información de un Item o bien
puede Imprimir un informe:
Ejemplo de caso de uso
 Además podemos notar que un item
puede ser una Botella, un Tarro o una
Jaba.
Ejemplo de caso de uso
 Otroaspecto es la impresión de
comprobantes, que puede ser realizada
después de depositar algún item por un
cliente o bien puede ser realizada a
petición de un operador.
Ejemplo de caso de uso
 Diseño final
Webgrafia
 http://users.dcc.uchile.cl/~psalinas/uml/introduccion.html
 http://www.seas.es/blog/informatica/tipos-de-relaciones-en-diagramas-de-
casos-de-uso-uml/
 http://www.cc.uah.es/jlcastillo/POO/POO_07.htm
 http://users.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/Model_Negocio.
html
 https://prezi.com/lldzumc9zuwd/modelado-de-requerimientos-del-sistema-
con-los-casos-de-uso/
 https://synergix.wordpress.com/2007/09/21/definimos-uml-como/

 https://sites.google.com/site/todouml/ejercicios/ejercicios-soluciones
 https://senadsi2014.wordpress.com/21-ejemplos-y-ejercicios-resueltos-de-
diagramas-de-caso-de-uso/
 https://synergix.wordpress.com/2008/06/04/ejemplo-de-caso-de-uso/
 https://synergix.wordpress.com/2008/07/12/ejemplo-de-analisis-de-caso-de-
uso/

Vous aimerez peut-être aussi