Introducción al modelado
del software
El lenguaje unificado de modelado, UML
A mediados de los noventa existían muchos
métodos de análisis y diseño OO
Mismos conceptos con distinta notación
Mucha confusión.
En 1994, Booch, Rumbaugh y Jacobson deciden
unificar las notaciones de sus métodos:
Unified Modeling Language (UML)
Proceso de estandarización promovido por el OMG
http://www.omg.org
Explosión de métodos OO en los noventa
OMT Coad/Yourdon
Booch Champeaux
Jacobson Martin/Odell
Shlaer-Mellor OOram
Wirfs-Broks BON
Fusion Open
Catalysis
¡Y muchos más! ¡Guerra
de
métodos!
Evolución UML
Grady Booch y Jim Rumbaugh comenzaron a unificar sus
métodos (Octubre, 1994).
Borrador de UML (versión 0.8) (Octubre, 1995)
Ivar Jacobson se une al proyecto (Noviembre, 1995).
UML 0.9 y se crea un consorcio (Junio, 1996)
OMG lanza una petición para un lenguaje unificado (1996)
UML 1.0 es ofrecido al OMG (Enero, 1997)
Se extiende el consorcio (Enero-Julio, 1997)
UML 1.1 es ofrecido al OMG (Julio, 1997)
OMG adopta UML 1.1 (Noviembre, 1997)
Se crea el UML RTF (1998)
UML 1.3 (Mayo 1999)
UML 2.0 (principios de 2005)
OMG (Object Management Group)
Propone, elabora y mantiene especificaciones
para aplicaciones empresariales distribuidas e
interoperables.
Estándares OMG
– Corba
– UML y perfiles UML
– OCL
– MOF, XMI
– MDA
Ventajas de la unificación
Reunir los puntos fuertes de cada método
Idear nuevas mejoras
Proporcionar estabilidad al mercado
– Proyectos basados en un lenguaje maduro
– Aparición de potentes herramientas
Eliminar confusión en los usuarios
Objetivos en el diseño de UML
Modelar sistemas, desde los requisitos hasta los
artefactos ejecutables desplegados en nodos,
utilizando técnicas OO.
Cubrir las cuestiones relacionadas con el tamaño
propias de los sistemas complejos y críticos.
Lenguaje utilizable por las personas y las
máquinas
Encontrar equilibrio entre expresividad y
simplicidad.
Modelado del Software
El modelado es el análisis y diseño de aplicaciones
software antes de escribir el código.
Se crean un conjunto de modelos (“planos del
software”) que permiten especificar aspectos del
sistema como los requisitos, la estructura y el
comportamiento.
Los modelos
– ayudan a razonar sobre el sistema
– favorecen la comunicación
– permiten documentar las decisiones
– permiten una generación automática de código
Modelos en otras áreas
¿Qué es un modelo?
“Un modelo es una simplificación de la
realidad”
“Un modelo es resultado de un proceso de
abstracción y ayuda a comprender y
razonar sobre una realidad.
¿Qué es un modelo software?
Es una descripción de un aspecto del sistema,
escrita en un lenguaje bien definido.
El lenguaje unificado de modelado, UML
UML es un lenguaje para visualizar, especificar,
construir y documentar los artefactos (modelos)
de un sistema software, desde una perspectiva
orientada a objetos.
“Of the 14 million or so software professionals around
the world, many know of the existence of the UML yet
only a modest percent use the UML on a daily basis”
(Grady Booch, 2002)
Utilidad del modelado
¿Por qué no escribo código
directamente?
Sería lo ideal pero ....
.... necesitamos escribir modelos,
aunque la mayoría de desarrolladores
todavía no practican el modelado
Modelo de
Estructural
1. cerrarEdicionSubasta(es)
int numAjudicaciones =
: Minimo(pujas.length(),
ControladorAnuncios articulos.length());
: Sistema
2. cerrar() 5. numAdjs = calcularAdjudicaciones()
9. [1..numAdjs]* add(adj)
4. * cerrar()
: AnuncioSubasta : EdicionSubasta as : adjudicaciones :
AnuncioSubasta Adjudicacion
3. * as := get()
8. [1..numAdjs]* adj := crear(as, pg, a)
6. [1..numAdjs]* pg := get()
pujas : 7. [1..numAdjs]* a:= get()
PujaOrdinaria
adj :
Se recorre la colección de
Adjudicacion
pujas obteniendo las pujas
: ArticuloConcreto
ganadoras (consideramos
que la colección está
ordenada de mayor a menor Se crean tantas adjudicaciones
valor de puja). como pujas ganadoras haya.
Cada adjudicación se asocia
con un ArticuloConcreto, una
puja adjudicataria y con la
subasta.
Modelo de
Comportamiento
Utilidad del modelado
Hay estructuras que no son visibles en los
programas.
Ayuda a razonar sobre el cómo se implementa.
Se facilita la comunicación entre el equipo al existir
un lenguaje común.
Se dispone de documentación que trasciende al
proyecto.
Generación de código a partir de modelos
– Ha surgido un nuevo paradigma de desarrollo de software
a partir de modelos (p.e. MDA de OMG)
Utilidad del modelado
Los modelos:
– visualizan cómo es o queremos que sea el
sistema
– especifican la estructura y comportamiento del
sistema.
– guían la construcción del sistema.
– documentan las decisiones.
¿Por qué la mayoría de
empresas no practican el
modelado?
¿Se obtienen beneficios con el modelado?
Un coste en formación y tiempo
¿Una mejora de la productividad?
¿Una mejora de la calidad del software?
Modelos en UML
Modelado de Casos de Uso
Modelado Estructural
Modelado de Comportamiento
Modelado de flujos de Actividades
Modelado Implementación
Modelado de Despliegue
Tipos de modelo
¿En qué etapa del proceso se usa? ¿Análisis o
Diseño?
¿Cuál es su grado de detalle? ¿Abstracto o
detallado?
¿Qué sistema describe? ¿Modelo de negocio o
modelo software?
¿Qué aspecto describe? ¿Estructural o de
comportamiento?
¿Es específico o independiente de la plataforma?
¿A qué plataforma va dirigido? EJB, JDBC, .NET,
CORBA, etc.
Propiedades del modelado
La elección de los modelos tiene una profunda
influencia sobre cómo se acomete el problema y se
moldea la solución.
Todo modelo debe estar ligado a la realidad.
Un único modelo no es suficiente. Cualquier
sistema trivial se aborda mejor a través de un
pequeño conjunto de modelos casi independientes.
UML y el modelado
UML es un lenguaje para visualizar, especificar,
construir y documentar los artefactos (modelos) de
un sistema que involucra una gran cantidad de
software, desde una perspectiva orientada a objetos.
UML es una notación, no es un proceso
Se han definido muchos procesos para UML.
– Rational ha ideado RUP, el“proceso unificado”.
Utilizable para sistemas que no sean software
Marco Conceptual de UML
Bloques básicos de construcción
– Elementos
Estructurales, Comportamiento, Agrupación,
Anotación
– Relaciones
– Diagramas
Reglas para combinar bloques
– Establecen qué es un modelo bien formado
Mecanismos comunes
– Especificaciones, Extensibilidad, Dicotomía clase-
instancia, Dicotomía interfaz-realización
Elementos Estructurales
Partes estáticas de un modelo
Ventana <<Interface>> colaboración
origen IAvisable
IAvisable
tamaño
abrir()
cerrar()
interface Gestión Pedidos
mover()
dibujar()
clase
RealizarCompra
caso de uso
Elementos Estructurales
Gestor Eventos
clase activa
suspender() FormularioPedido
vaciarCola()
componente
<<artifact>>
window.dll
Servidor
nodo
artefacto
Elementos de Comportamiento
Son las partes dinámicas de UML.
Interacción
Conjunto de mensajes intercambiados entre varios
objetos con un propósito particular.
cerrarPuja()
mensaje
Elementos de Comportamiento
Máquina de estados
Secuencia de estados por las que pasa un objeto durante
su vida en respuesta a eventos.
activado estado
Elementos de Agrupación
Son las partes de organización de los modelos UML
Modelo del Negocio
paquete
Un paquete incluye un conjunto de elementos de cualquier
naturaleza.
Tiene una naturaleza conceptual.
Elementos de Anotación
Son las partes explicativas de los modelos UML
Retorna 0 si no Nota
existe el valor
Relaciones
Dependencia
0..1 *
Asociación
patron empleado
Generalización
Realización
Ejemplo de diagrama de clases
IteradorCuenta
Cuenta Domiciliacion
1 0..n
Ahorro Corriente
Operacion
Periodica
Diagramas de UML 2.0
Diagrama de Clases
Diagrama de Objetos
Diagrama de Componentes Diagramas no
Diagrama de Estructura Compuesta son modelos
Diagrama de Casos de Uso
Diagrama Secuencia
Diagrama Comunicación (antes de Colaboración)
Diagrama de Estados
Diagrama de Actividades
Diagrama de Despliegue
Diagrama de Artefactos
Diagrama de Paquetes
Diagrama de Tiempos
Diagramas de UML 2.0
Modelos en UML
Modelado de Casos de Uso
– Diagrama de Casos de Uso
Modelado Estructural
– Diagrama de Clases
Modelado de Comportamiento
– Diagramas de Interacción: Secuencia y Comunicación
– Diagramas de Estados
Modelado de flujos de actividades (p.e. Modelo del Negocio)
– Diagramas de actividades
Modelado Implementación
– Diagrama de Componentes
Modelado de Despliegue
– Diagramas de Artefactos
– Diagramas de Despliegue
Responsable Serv icio PE Alumno Sistema
Registrar Curso
Aprobar Curso
Modelo del
Preinscripción Negocio
Avisar
Admitidos
Matriculación
Hay alumnos?
no
Cambiar
admitidos Hay alumnos?
no Diagrama de
actividades
Cancelar Curso
Crear Proyecto
Cerrar Curso
Modelo
Casos de Usos
Realizar puja ordinaria
Cerrar edición de subasta
Pujador Cancelar puja ordinaria
Realizar pago de subasta ordinaria
Rechazar adjudicación
Sistema
Notif icar adjudicatario
Teleoperador Participante
Crear edición de subasta
Diagrama de
Anular anuncio de subasta casos de uso
Administrador
Anular edición de subasta
Diagrama Modelo
de clases Estructural
1. cerrarEdicionSubasta(es)
int numAjudicaciones =
: Minimo(pujas.length(),
ControladorAnuncios articulos.length()); Diagrama de
: Sistema comunicación
2. cerrar() 5. numAdjs = calcularAdjudicaciones()
9. [1..numAdjs]* add(adj)
4. * cerrar()
: AnuncioSubasta : EdicionSubasta as : adjudicaciones :
AnuncioSubasta Adjudicacion
3. * as := get()
8. [1..numAdjs]* adj := crear(as, pg, a)
6. [1..numAdjs]* pg := get()
pujas : 7. [1..numAdjs]* a:= get()
PujaOrdinaria
adj :
Se recorre la colección de
Adjudicacion
pujas obteniendo las pujas
: ArticuloConcreto
ganadoras (consideramos
que la colección está
ordenada de mayor a menor Se crean tantas adjudicaciones
valor de puja). como pujas ganadoras haya.
Cada adjudicación se asocia
con un ArticuloConcreto, una
puja adjudicataria y con la
subasta.
Modelo de
Comportamiento
Máquina de Estado
Diagrama introducirProducto
de estado
Espera Venta introducirProducto Introduccion
Productos
Terminar Venta
manejarRespuesta
efectuar Pago Efectivo Espera
Pago
Autorizacion
Pago
efectuar Pago Tarjeta
Mecanismos comunes de UML
Dicotomía clasificador /instancia
Persona
Elena : Elena :
nombre Persona Persona
direccion
telefono
: Persona : Persona
Mecanismos comunes de UML
Dicotomía interfaz / implementación
IOrtografia
IDiccionario asistenteOrtografico
IUnknown
Mecanismos comunes de UML
Dicotomía rol / tipo
Pedido
cliente: Persona
El tipo declara la clase de una entidad, por ejemplo un objeto o
parámetro, y el rol describe el significado de la entidad en un
determinado contexto, tal como una clase, componente o
colaboración.
Mecanismo de extensibilidad de UML
Estereotipos
– Extienden el vocabulario de UML, permitiendo definir
nuevos tipos de elementos y relaciones a partir de
los existentes pero específicos de un problema o
dominio.
– Algunos son predefinidos en UML.
Valores etiquetados
– Extienden las propiedades de un estereotipo,
permitiendo crear nueva información en la
especificación del estereotipo.
Restricciones
– Especifican condiciones sobre los elementos del
modelo.
Perfiles UML
UML es una familia de lenguajes
– Lenguaje core + Perfiles
Un perfil define una extensión de UML mediante la
especialización de UML.
Un perfil define una forma específica de usar UML para
un dominio concreto: EJB, aplicaciones web, CORBA,
modelado del negocio, esquemas relacionales, ..
Agrupación de un conjunto de estereotipos, valores
etiquetados y restricciones, con su
correspondiente notación.
Ejemplos de estereotipos predefinidos
Clase estereotipadas
<<Actor>>
Cliente
Cliente
IComparator
Estereotipos y Valores Etiquetados
<<Table>> <<BusinessEntity>>
Cliente
Empleado <<UniqueId>> id : String
nombre : String
<<key>> dni : String 1 apellido : String
nombre : String
edad : int <<Query>> findByLastName()
Estereotipo: Table Estereotipo: BusinessEntity
Valores Etiquetados: key Valores Etiquetados: UniqueID y Query
Restricciones
Se expresan en OCL
Permiten asociar información que no se puede
expresar en UML
Ejemplo: “Dos tablas de un mismo esquema
relacional deben tener distinto nombre”.
context Table
inv: tablasDistintoNombre
tablas -> forAll ( t1, t2 |
t1.name = t2.name implies t1 = t2)
end
Restricciones
{xor}
restricciones
{self.esposa.sexo = mujer and
self.esposo.sexo = hombre}
¡Hola, Mundo!
import java.awt.Graphics;
class HolaMundo extends java.applet.Applet {
public void paint (Graphics g) {
g.drawString (“¡Hola, Mundo!”,10,10);
}
}
HolaMundo
g.drawString
("Hola, mundo”)
paint()
Diagrama de Clases
Organización en Paquetes
Organización en Paquetes
java
HolaMundo
applet
awt
lang
Diagrama de Secuencia
root : Thread : Toolkit : ComponentPeer target : HolaMundo
run
callbackLoop
handleExpose
paint
Diagrama de Artefactos
HolaMundo
<<manifest>> <<manifest>>
hola.java
<<artifact>>
HolaMundo.class
hola.html
hola.jpg
