UML Lenguaje de Modelado Unificado Estandarizando el

08/10/2012
UML
Lenguaje de Modelado Unificado
Estandarizando el Desarrollo de
Software de Principio a Fin
Temario
¿Y esto de qué se trata?
•Definición e importancia de UML
•Diagramas de Casos de Uso
•Diagramas de Actividades
•Diagramas de Clases
•Diagramas de Secuencia
•Diagramas de Instalación
•Otros diagramas
1
08/10/2012
Definiendo UML
Entendiendo lo que es y para qué sirve.
La traducción de UML es literalmente Lenguaje de Modelado Unificado, pero
tal vez la pura traducción no sea tan descriptiva de lo que UML realmente es.
Si descomponemos los términos, tenemos que:
•Lenguaje: Tiene la función de comunicar algo, siempre bajo ciertas reglas.
•Modelado: Es una representación de lo que se busca.
•Unificado: Estandariza elementos que antes no estaban estandarizados.
De estos términos, tal vez el más importante sea modelado, debido a que si
bien un modelo es una representación de lo que se busca, también se puede
entender como una abstracción de lo que se busca.
Recordemos que el desarrollo de sistemas es, de por sí, algo completamente
abstracto, así que esta definición es la que tal vez se acerque más a nuestras
necesidades.
Importancia de UML
¿Bosque o Grupo de Árboles?
Existe una metáfora que bien aplica a nuestras necesidades:
“Estar demasiado cerca de los árboles impide ver el bosque”
Tal vez suene un poco absurdo, pero un analista debe utilizar UML teniendo
en mente que un sistema completo, por muy sencillo o complejo que sea,
equivale a apreciar un bosque completo, así que enfocarse en una parte
equivaldría a enfocarse en algunos árboles y perder de vista la totalidad de lo
que se busca.
Por su parte, los “árboles” que componen el análisis de un sistema en UML
son diagramas, pero es importante entender que no se trata de dibujar
diagramas a diestra y siniestra, sino que los diagramas deben capturar la
esencia del sistema que se está diseñando.
2
08/10/2012
4+1 Vistas
La primera descomposición del sistema
No, no son 5 vistas, efectivamente son 4+1 vistas. Cada una de estas vistas en
una parte del sistema. Se dice que son “cuatro más un vistas”, porque la vista
“sobrante” es la que une a las demás.
Vista Lógica
Vista de Proceso
Casos de Uso
Vista Física
Vista de Desarrollo
Estas vistas siguen la máxima “Divide y vencerás”.
Diagramas de Casos de Uso
El punto de arranque de cualquier sistema
V.L.
V.P.
C.U.
V.F.
V.D.
¿Por qué los casos de uso son la parte más importante del sistema?
Simplemente porque se trata de lo que el sistema debe hacer. En otras
palabras, los casos de uso representan los requerimientos del usuario.
Más importante aún, representan los requerimientos del usuario desde el
exterior del sistema, así como el valor que el usuario espera del sistema que
se le está construyendo. En otras palabras, son la primera manera de ver el
bosque completo, de entenderlo, de saber de qué tipo de árboles se trata e
incluso de los animales que corren libremente entre ellos.
3
08/10/2012
Los Requerimientos
¿Qué es un requerimiento y qué no lo es?
No todo lo que nos pide el usuario son requerimientos del sistema. O mejor
dicho, se debe identificar lo que un sistema debe hacer y separarlo de lo que
un sistema necesita para realizar su trabajo, lo cual se descompone en:
•Requerimientos Funcionales: Son todos los requerimientos de lo que un
sistema debe hacer. Esto incluye las diferentes validaciones de reglas de
negocio, despliegue de información, etc.
•Requerimientos No Funcionales: Son todos los requerimientos técnicos del
sistema, como tipo de base de datos, conexiones a través de sockets, comprar
licencias de desarrollo, etc.
Los casos de uso se enfocan en los requerimientos funcionales.
Diagrama de Casos de Uso
Vista de cómo quedaría un diagrama con todos los elementos
Acceder al
Sistema
Usuario
<<extend>>
Validar
Credenciales
<<include>>
Bloquear
Usuario
Al tercer
intento fallido
Correr
Nómina
Dar de Alta
en Hacienda
<<include>>
Recursos
Humanos
Registrar
Contratación
Generar
Balance
<<include>>
<<include>>
Dar de Alta
en Afore
Reportar a
Dir. General
Contabilidad
4
08/10/2012
Ejemplo de Descripción
Lo que una descripción contiene
Caso de Uso
Acceder al Sistema
Actor(es)
Usuario
Activado cuando
El usuario intenta acceder al sistema, proporcionando su login y password.
Precondiciones
Haber abierto la aplicación
Incluye a
Validar Credenciales
Extiende a
No aplica
Flujo
1.- Capturar login y password en casillas correspondientes.
2.- Aceptar la captura.
3.- Validar credenciales (caso de uso: Validar Credenciales)
4.- Abrir pantalla principal del sistema
Flujo Alterno
Paso 3.a: El login o el password son incorrectos
3.a.1- Informar al usuario que tuvo error en la captura.
3.a.2- Incrementar contador de intentos de acceso.
3.a.3- Si el contador llega a 3 intentos, bloquear el usuario (caso de uso: Bloquear Usuario)
3.a.4- Terminar el caso de uso
Incluido en
No aplica
Extensiones
Bloquear Usuario
Diagramas de Actividades
El orden de los procesos
V.L.
V.P.
C.U.
V.F.
V.D.
Los diagramas de actividades tienen la característica de modelar procesos de
negocio con relativa facilidad. De hecho existen herramientas Case que toman
estos diagramas y generan el código de la aplicación con enorme facilidad.
La diferencia principal entre los diagramadores de modelos de proceso de
negocios (BPM) y los diagramadores de UML está en la notación que utilizan,
pero esencialmente representan lo mismo: procesos de negocio.
Básicamente, los diagramas de actividades (o de procesos de negocio) son los
herederos de los antiguos diagramas de flujo que se utilizaban en los inicios de la
programación. Obviamente, estos diagramas han sufrido modificaciones y
adecuaciones con el paso del tiempo hasta llegar a lo que veremos a
continuación.
5
08/10/2012
Diagrama de Actividades
Varias cosas al mismo tiempo
En este ejemplo vemos un diagrama de actividades. Cada actividad va en
secuencia siguiendo a otra desde el punto de partida hasta el final, aunque
también se aprecia que tenemos actividades paralelas, además de una condición
para seguir adelante o terminar.
Diagrama de
Actividades de
un Videojuego
Inicializar
Componentes
α
Procesar
Entrada
Procesar
Escenario
Recibir Entrada
Calcular
Física
Inteligencia
Artificial
Render y
Audio
Validar
Reglas
Sí
α
No
Game Over
Diagramas de Clases
Estableciendo relaciones de responsabilidades
V.L.
V.P.
C.U.
V.F.
V.D.
Al entrar a los diagramas de clases ya estamos hablando de responsabilidades, lo
cual es precisamente el punto importante de la programación orientada a
objetos:
•Un objeto es una entidad con responsabilidad.
•Una clase es la definición de cómo esa responsabilidad se va a llevar a cabo.
Por lo tanto, los diagramas de clases modelan las relaciones entre las diferentes
responsabilidades del sistema.
6
08/10/2012
Partes de una Clase
Identificación, Estados y Comportamientos
Identificación
Estados
Comportamientos
Una clase se compone de tres piezas fundamentales:
1. Su identificación, es decir, el nombre que representa
la responsabilidad que va a cumplir.
2. Sus estados, que son diferentes propiedades que un
objeto puede adquirir en un momento dado.
3. Sus comportamientos o métodos, es decir los
procesos internos que se van a realizar.
Usuario
+idUsuario: long
+Nombre: String
-Password: String
+CambiarPassword(nuevoPassword: String): void
-ValidarNuevoPassword(nuevoPassword: String): Boolean
Tipos de Relación
Cómo una clase se conecta con otra
Existen cuatro tipos de relaciones básicas entre las clases.
A
B
A
B
La flecha en blanco
significa que A es una
generalización de B, o
bien que B es una
especialización de A.
El diamante en blanco
significa que A tiene
agregados uno o varios
objetos de la clase B,
pero no son parte uno
del otro.
A
B
A
B
La flecha punteada
indica que A depende
de B para realizar
alguna tarea, pero sin
que una clase sea
parte de la otra.
El diamante relleno
indica que A se
compone de uno o
varios objetos de B y
no se pueden separar.
7
08/10/2012
Ejemplo de Diagrama de Clases
Una nómina sencilla
1..*
Nomina
-ListaEmpleados:Empleado[*]
+TotalEmpleados:int
+RegistrarNuevoEmpleado(e:Empleado):void
+CorrerNominaMes():XML
+RealizarDepositos(d:XML):Bool
-GenerarBalanceContable(d:XML, f:XML, e:XML):void
Al generar el
balance se
envía mail a
Contabilidad y
a Dir. Gral.
CorreoElectronico
+Servidor:string
+Puerto:string
+Remitente:string
+Destinatarios:string[*]
+Titulo:string
+Mensaje:string
+Attachments:XML[*]
+Enviar():int
Empleado
+Nombre:string
+Direccion:string
+FechaNacimiento:DateTime
+Usuario:string
+Contrasena:string
-historial:Bitacora
+CambiarContrasena(nueva:string):void
0..*
Bitacora
-ActividadRealizada:string
-Fecha:DateTime
+RegistrarAccion(a:string, f:DateTime):void
Diagramas de Secuencia
Poniendo a funcionar el sistema
V.L.
V.P.
C.U.
V.F.
V.D.
Los diagramas de secuencia van más allá de los diagramas de clases y paquetes.
Con los diagramas de clase se modelan las relaciones entre las diferentes
responsabilidades, pero los diagramas de secuencia le ponen más detalle al
asunto.
Los diagramas de secuencia modelan cómo interactúan las clases entre sí,
incluso entre métodos de una misma clase, ya que incluyen no sólo los métodos
con sus parámetros y tipos de retorno, sino que además incluyen el tipo de
mensajes que se tienen que enviar de uno a otro.
8
08/10/2012
Participantes
Objetos o Clases
Los participantes son las clases y/u objetos que están involucrados
en una secuencia. Se denotan con una caja en la parte superior y
en la parte inferior tienen una línea punteada. Esta línea punteada
representa el tiempo que una clase o un objeto en específico está
en uso con respecto a otros objetos o clases.
Para distinguir si estamos hablando de una clase o un objeto que tiene que
instanciarse en código utilizamos los dos puntos (:), donde del lado izquierdo va
el nombre del objeto y del derecho el nombre de la clase. Por lo general, a nivel
de análisis se requiere sólo el nombre de la clase.
Objeto:Clase
Objeto:
:Clase
Activación y Mensajes
El tiempo que una clase u objeto va a interactuar
Objeto:Clase
Las barras de activación son rectángulos que se colocan sobre la
línea de tiempo de un participante. Puede haber más de una barra
de activación dependiendo de cuántos mensajes envíe el
participante a otro participante, incluso entre mensajes que se
envíe un participante a sí mismo.
La manera de enviar o recibir mensajes es con flechas que van de
una barra de activación de un participante a la barra de activación
de otro participante.
Mensaje síncrono (punta cerrada).
Mensaje asíncrono (punta abierta).
Mensaje de retorno (línea punteada)
<<create>>
<<destroy>>
Objeto:Clase
X
En cuanto a la instanciación de
objetos, esto es más común que
usar los destructores, a no ser que
se requiera indicar que el objeto ya
no deberá estar en uso.
9
08/10/2012
Ejemplo de Secuencia
Intentar dar de alta un nuevo usuario
Aceptar:Button
:Usuario
Alta(u:String, p:String):Bool
Validar():Bool
:Bool
si Validar() es verdadero
<<create>>
cond
:BaseDatos
AbrirConexion():void
Query(sp:String, p:Parametros):void
CerrarConexion():void
:Bool
MsgBox(msg:String)
Aviso al usuario
Diagramas de Instalación
Donde la aplicación va a residir
V.L.
V.P.
C.U.
V.F.
V.D.
Si bien la programación es algo abstracto o, mejor dicho, es una abstracción de la
realidad, el resultado final es un archivo electrónico o un conjunto de archivos
que van a tener que ser instalados en algún sitio.
Los diagramas de instalación se usan para llevar la aplicación al mundo real por
medio de mostrar cómo el software se asigna al hardware y cómo las piezas se
comunican.
10
08/10/2012
Nodos y Artefactos
¿Dónde va a quedar y qué es lo que va a quedar?
El hardware y también los componentes requeridos
por el hardware para la aplicación se representan
con nodos. Los nodos son cubos que representan las
“cajas” donde se va a guardar la aplicación instalada.
<<device>>
El_Servidor
El software que se instale se representa con artefactos,
los cuales se pueden representar de diferentes formas.
<<artifact>>
Default.aspx
Default.aspx
<<artifact>>
Default.aspx
Combinando Nodos y Artefactos
Simulando la instalación
La forma tradicional es la de poner cada
artefacto dentro del nodo. Sin embargo, si
la lista de artefactos es muy larga, se
acostumbra simplemente ponerla a
manera de listado.
<<device>>
Servidor Web
<<device>>
El_Servidor
Default.aspx
Clientes.aspx
Empleados.aspx
Configuración.xml
Incapacidades.rpt
FacturasPagadas.rpt
Default.aspx
11
08/10/2012
Nodos Anidados
¿Nodos o Nidos?
Existe la posibilidad de anidar nodos, pero en este caso, la anidación se refiere a
un ambiente de ejecución dentro de un nodo, por ejemplo, para poder ejecutar
páginas como ASP o PHP, el servidor debe tener instalado un servicio que procese
esas aplicaciones.
Esto indica
que el
servidor
(hardware)
requiere un
servidor, como
por ejemplo,
IIS para los
ASP o Apache
para PHP
<<device>>
El_Servidor
<<executionEnvironment>>
Servidor Web
Distribución de Piezas
Cuando la aplicación se encuentra instalada en varias partes
¿Cómo se podría interpretar lo siguiente?
<<device>>
El_Servidor
<<executionEnvironment>>
Servidor Web
Default.aspx
Clientes.aspx
Empleados.aspx
<<executionEnvironment>>
Reporteador
Incapacidades.rpt
FacturasPagadas.rpt
Configuracion.xml
<<device>>
Servidor_Datos
Aplicacion.db
12
08/10/2012
Y aún hay más
Otros diagramas, patrones de diseño y todo un mundo por descubrir
Los diagramas vistos hasta ahora son los básicos utilizados en la mayoría de los
análisis y diseños de sistemas. Sin embargo, es posible hace uso de más
diagramas que diferentes bibliografías sugieren, como máquinas de estados o
diagramas de componentes.
Lo importante es entender que la cantidad de diagramas que se realicen debe
ser acorde al tamaño del proyecto, ya que una cantidad excesiva de diagramas
puede retrasar el análisis y diseño del sistema, mientras que una cantidad
reducida para un sistema mayor puede resultar en que falten detalles
importantes.
Sea cual sea la necesidad a cubrir y los diagramas que se vayan a realizar,
siempre hay que recordar que los diagramas que más completos deben quedar
son siempre los Casos de Uso, ya que son los que nos guiarán durante el resto
del ciclo de vida y evolución del proyecto.
¡Gracias!
Con esto concluimos nuestra presentación
¿Preguntas?
13