Ingeniería de Software
Tema: Conceptos Básicos de UML 2
Profesor Gerardo Cerda Neumann
Profesor Gerardo Cerda Neumann [email protected]
2
Agenda
• Conceptos básicos a revisar• Los 4 principios de modelamiento• Propósito del Diagrama de Clases• Propósito del Diagrama de Casos de
Uso• Modelo conceptual• Diagramas de Paquetes
Profesor Gerardo Cerda Neumann [email protected]
3
• Objeto de una clase SE RELACIONASE RELACIONAcon un objeto de otra clase
• Objeto de una clase CONTIENECONTIENEun objeto de otra clase
Relaciones
AgregaciónAgregación
AsociaciónAsociación
agregación a
gregació
n
asociación
Profesor Gerardo Cerda Neumann [email protected]
4
Modelamiento de Software
Un Modelo de Software es una Simplificación de la RealidadSimplificación de la Realidad
Profesor Gerardo Cerda Neumann [email protected]
5
– Provee el planoplano (Blueprint) (Blueprint) del sistema a construir– Puede representar un plan detalladoplan detallado o– dar una vista de muy alto nivelvista de muy alto nivel – Si es bueno, incluye los aspectos
realmente importantes para cierto punto de vista.
– Estructurales (Estáticos)Destacan la estructura y la organización del sistema
– De Comportamiento (Dinámicos)Destacan los aspectos dinámicos del sistema.
Modelamiento de Software
Un Modelo (según Grady Booch):Un Modelo (según Grady Booch):
Tipos de Modelos:Tipos de Modelos:
Profesor Gerardo Cerda Neumann [email protected]
6
La Selección del Modelo Importa
Los Modelos Pueden TenerDiferentes Niveles de Precisión
Los Mejores ModelosTienen la Relación Clara Con la Realidad
Para Entender el Sistemase Necesitan Varios Modelos Complementarios
4 Principios de modelamiento
Profesor Gerardo Cerda Neumann [email protected]
7
• Los modelos bien elegidosreflejan los aspectos relevantes del sistemay permiten su implementación óptima
• Los modelos mal elegidosdestacan los aspectos de poca relevanciay llevan hacia la implementación equivocada.
Principio 1 de Modelamiento
La Selección del Modelo ImportaLa Selección del Modelo Importa
Profesor Gerardo Cerda Neumann [email protected]
8
• Dependiendo del próposito del sistema– ¿Quién va a usar el modelo?
• Cliente, Usuario, Implementador, Testeador, etc.– ¿Para qué
se construye el modelo?
• Prototipo, base de datos, conceptual, etc.
Principio 2 de Modelamiento
Los Modelos Tienen Los Modelos Tienen Diferentes Niveles de Precisión Diferentes Niveles de Precisión
Profesor Gerardo Cerda Neumann [email protected]
9
• La idea principal de la orientación a objetos – acercarse a la realidad.
Principio 3 de Modelamiento
Los Mejores Modelos Los Mejores Modelos Tienen la Relación Clara con la Realidad Tienen la Relación Clara con la Realidad
Profesor Gerardo Cerda Neumann [email protected]
10
• Un sistema tiene varios aspectos importantesvarios aspectos importantes– Estructura, escenarios típicos, interfaz usuaria, etc.
• No todos los sistemas necesitan todos los modelos– Sistemas distribuidos sistemas monólitos– Alta concurrencia un solo usuario– Usan base de datos los sistemas embedded
Principio 4 de Modelamiento
Para Entender el Sistema Se Necesitan Para Entender el Sistema Se Necesitan Varios Modelos Complementarios Varios Modelos Complementarios
Profesor Gerardo Cerda Neumann [email protected]
11
• Un conjunto de las abstracciones relacionadas con el dominio del problema
• Ayuda el ENTENDERENTENDER el problema y no su resolución
Vista Conceptual
contie
ne
ahorra
posee
protege
usa
Profesor Gerardo Cerda Neumann [email protected]
12
Propósito del Diagrama de Clases
• Usados Para Demostrar la Estructura Estática de un Sistema Computacional o una Parte Relevante de Mundo Real
• Los Diagramas Más Frecuente y Ampliamente Usados, con Tres Perspectivas Posibles– Conceptual – demuestra las entidades del mundo real
con sus relaciones– Especificación – demuestra la estructura del sistema
o su parte, destacando las interfaces– Implementación – el “blueprint” del código fuente
Profesor Gerardo Cerda Neumann [email protected]
13
Diagrama de Clases: Ejemplo
Cliente
Bebida
Barmen
Pedido
Venta
- valor: Doble
+ ImprimirBoleta()
Bodega
Jugo Natural
Gaseosa
1
1..*
1
realiza
0..*
1tiene
1..*
1almacena
0..*
Profesor Gerardo Cerda Neumann [email protected]
14
• Representa la relación genérica entre dos clases• El significado de una asociación
depende de la perspectiva del diagrama
Relaciones en Diagramas de Clases
asociaciónasociación
Chofer
Auto«Java»Cuenta
Corriente
+ Número: long+ Saldo: double
«Java»Cliente
- RUT: String
+ getCuenta() : Cuenta Corriente
Profesor Gerardo Cerda Neumann [email protected]
15
• Representan una asociación “fuerte” entre dos clase• No existe una separación estricta entre
asociación y agregación o composición– Asociación representa una relación en el sentido más general– Agregación puede significar que una clase está compartida– Composición indica un vínculo exclusivo y permanente
Relaciones en Diagramas de Clases
agregación, composiciónagregación, composición
Auto
Motor
Mano Dedo
Profesor Gerardo Cerda Neumann [email protected]
16
• La clase heredera es una especialización de su súper clase
• Herencia Múltiple Una clase puede ser heredada de varias súper clases
Relaciones en Diagramas de Clases
herenciaherencia
Auto
VoladorVehiculo
Av ion
Profesor Gerardo Cerda Neumann [email protected]
17
• Es una clase creada de una asociación• Enlace entre dos objetos corresponden al objeto asociado• Se usa cuando la asociación no es suficiente para describir la relación• Habitualmente se le agregarán atributos o aún métodos
Relaciones en Diagramas de Clases
Clase asociativaClase asociativa
Persona
Auto
Compra
- fecha: Date- monto: Double
Mario :Persona
Renault :Auto
Jorge :Persona
1234 :Compra
2222 :Compra
Profesor Gerardo Cerda Neumann [email protected]
18
Diagrama de Clases: Ejemplo
Cliente
Bebida
Barmen
Pedido
Venta
- valor: Doble
+ ImprimirBoleta()
Bodega
Jugo Natural
Gaseosa
1
1..*
1
realiza
0..*
1tiene
1..*
1almacena
0..*
asociación
multiplicidad
atributooperación
herencia
Profesor Gerardo Cerda Neumann [email protected]
19
• Proporciona credibilidad en una etapa inicial del desarrollo del sistema
• Asegura una comprensión mutua de los requisitos
• Quién interactuará con el sistema y qué deberá hacer el sistema
• Qué interfaz deberá tener el sistema
• Que se hayan capturado todos los requerimientos• Que los desarrolladores hayan entendido los requerimientos
Propósito de Casos de Uso
Usados Para VerificarUsados Para Verificar
Usados Para Comunicarse Usados Para Comunicarse con el Usuario Final y el Experto de Dominio con el Usuario Final y el Experto de Dominio
Usados Para IdentificarUsados Para Identificar
Profesor Gerardo Cerda Neumann [email protected]
20
Diagrama de CU: Ejemplo
Sistema de Pub
Barmen
Vender Bebida
Informar Bodega
Registrar Venta
Sistema de Bodega
«extend»
«include»
Profesor Gerardo Cerda Neumann [email protected]
21
Elementos de Diagrama de CU
Actor
Caso de Uso
• Un Actor representa cualquier entidad que interactúe con el sistema
• Un Caso de Uso es una secuencia de acciones que un sistema realiza, que produce un resultado observabley de valor para un Actor
Profesor Gerardo Cerda Neumann [email protected]
22
• Los Actores no son parte del sistema, ellos representan roles que un usuario del sistema puede desempeñar
Actor
Actor
Caso de Uso
• Un Actor puede intercambiar activamente la información con el sistema
• Un Actor puede ser un receptor pasivo de la información
• Un Actor puede representar a un humano, una máquina u otro sistema
Profesor Gerardo Cerda Neumann [email protected]
23
Caso de Uso
Actor
Caso de Uso
• Un caso de uso modela un diálogo entre el actor y el sistema, una interacción
• Un caso de uso es iniciado por un actor para invocar una cierta funcionalidad en el sistema
• Un caso de uso es un flujo de eventos completos y significativos
• Tomados al mismo tiempo, todos los casos de uso constituyen todas las formas posibles de ocupar el sistema
Profesor Gerardo Cerda Neumann [email protected]
24
Actor
Caso de Uso 1
Caso de Uso 2
Caso de Uso 3
Actor 2
Actor 3
Alcance del Sistema
sistema
límitedel sistema
¿Hasta Donde Llega el Sistema a Construir?
mundo
Profesor Gerardo Cerda Neumann [email protected]
25
• asociación
• incluye • extiende• herencia
• herencia
Relaciones en Diagramas de CU
Entre un Actor y un Caso de UsoEntre un Actor y un Caso de Uso
Entre Dos Casos de UsoEntre Dos Casos de Uso
Entre Dos ActoresEntre Dos Actores
Profesor Gerardo Cerda Neumann [email protected]
26
• El Actor interactúa con el sistema mediante un diálogo– El Actor típicamente inicia el diálogo (Actor Activo)– A veces el caso de uso toma la primera acción (Actor Pasivo)
Relaciones en Diagramas de CU
asociaciónasociación
Usuario
Navegar Lista de Mensajes
Realizar log in
Sistema Web Pay
Realizar el Pago
Profesor Gerardo Cerda Neumann [email protected]
27
• El diálogo incluído es una parte obligatoria del diálogo incluyentey va a resultar ejecutado cada vez que este se ejecute
Relaciones en Diagramas de CU
incluyeincluye
Usuario
Realizar log in
Validar Datos de Autentificación
«include»
Profesor Gerardo Cerda Neumann [email protected]
28
• El diálogo extendiente es una parte OPCIONAL del diálogo extendido y va a resultar ejecutado en CIERTAS EJECUCIONES del primer escenario
Relaciones en Diagramas de CU
extiendeextiende
UsuarioNav egar Lista de
Mensajes
Abrir Mensaje
«extend»
Profesor Gerardo Cerda Neumann [email protected]
29
• Un Caso de Uso es especificación del otro
Relaciones en Diagramas de CU
herencia (de casos de uso)herencia (de casos de uso)
Realizar Transacción
Realizar Giro
Realizar DepositoCliente
Profesor Gerardo Cerda Neumann [email protected]
30
• Un Actor es especificación del otro
Relaciones en Diagramas de CU
herencia (de Actores)herencia (de Actores)
Usuario
Usuario Registrado
Consultar Producto
Comprar Producto
Profesor Gerardo Cerda Neumann [email protected]
31
Diagrama de CU: Ejemplo
incluye
caso de uso
actor
extiende
Límite Sistema de Pub
Barman
Vender Bebida
Informar Bodega
Registrar Venta
Sistema de Bodega
«extend»
«include»
Profesor Gerardo Cerda Neumann [email protected]
32
Práctica: Modelo Conceptual
• Notación Usada
• Declaración del Problema
• Consultas
• Identificación de las Clases
• Especificación de las CRC
• Estructuración del Modelo de Clases
Profesor Gerardo Cerda Neumann [email protected]
33
Notación Usada
Modelo CRC Modelo CRC (Tarjetas de Responsabilidad-Colaborador)(Tarjetas de Responsabilidad-Colaborador)
• Método popular de análisis• Identificar los conceptos, sus responsabilidades
y las colaboraciones con otros conceptos
Diagrama de ClasesDiagrama de Clases
• Elemento estándar de UML• Identificar las clases
y sus relaciones
Profesor Gerardo Cerda Neumann [email protected]
34
Modelo CRC
Identificar los ConceptosIdentificar los Conceptos
• ¿Qué “sabe” el concepto? (Datos, Atributos)• ¿Qué “hace” el concepto? (Operaciones, Métodos)
<Nombre del Concepto>• Responsabilidad 1• Responsabilidad 2• ...• Responsabilidad N
• Colaborador 1• Colaborador 2• ...• Colaborador N
Identificar las ResponsabilidadesIdentificar las Responsabilidades
Identificar los ColaboradoresIdentificar los Colaboradores• Otros conceptos
Profesor Gerardo Cerda Neumann [email protected]
35
Diagrama de Clases
Diagramas de Clases de UML SimplificadoDiagramas de Clases de UML Simplificado
Clase
- atributo1: - atributo2: - ...: - atributoN:
+ método1()+ método2()+ ...()+ métodoN() : void
Otra Clase
Clase Heredada
Clase Compuesta
Una Clase más
1
+base
0..1
1..*0..*
0..*
0..*
Clase
Herencia
Multiplicidad
Composición
Navegabilidad
Profesor Gerardo Cerda Neumann [email protected]
36
Propósito de Diagrama de Paquetes
• Una de las preguntas más antiguasen desarrollo de software: “Como dividir un sistema en varios subsistemas?”
• Usados para simplificar el modelo agrupando sus elementos relacionados
• Aplicables en todos otros diagramas UML (caso de uso, clases, componentes)
• “Oficializados” desde el UML 2.0
Profesor Gerardo Cerda Neumann [email protected]
37
Diagrama de Paquetes: Ejemplo
Datos
+ Base de Datos PUB
Interfaz Visual Pub
Lógica de Negocio Pub
+ Componentes Bodega
+ Componentes Pub
Serv icios
Profesor Gerardo Cerda Neumann [email protected]
38
Elementos de Diagrama de Paquetes
• Un Paquete representa un grupo de elementos (casos de uso, clases, componentes, otros paquetes)relacionados según algún criterio
• Una Interfaz representa la parte pública del paquete,visible y accesible desde afuera del mismo paquete
Interfaz
Paquete
Profesor Gerardo Cerda Neumann [email protected]
39
Relaciones en Diagrama de Paquetes
• Dependencia• Anidación• Especialización
Entre Dos PaquetesEntre Dos Paquetes
Entre un Paquete y una InterfazEntre un Paquete y una Interfaz
• Dependencia• Realización
Profesor Gerardo Cerda Neumann [email protected]
40
Relaciones en Diagramas de Paquetes
• Por lo menos un elemento de un paquete depende de un elemento del otro (ejemplo: una clase de un paquete llama a una clase del otro)
DependenciaDependencia
Alimentos
+ Carnes
+ Frutas
+ Verduras
Supermercado
Dependencia
Profesor Gerardo Cerda Neumann [email protected]
41
Relaciones en Diagramas de Paquetes
• Un paquete contiene el otro
AnidaciónAnidación
Alimentos
+ Carnes
+ Frutas
+ Verduras
Carnes
(from Alimentos)
Frutas
(from Alimentos)
Verduras
(from Alimentos)
Anidación
Profesor Gerardo Cerda Neumann [email protected]
42
Relaciones en Diagramas de Paquetes
• Por lo menos un elemento del paqueterealiza la interfaz
• La interfaz es la parte visible y accesible del paquete
RealizaciónRealización
Realización
Alimentos
+ Carnes
+ Frutas
+ Verduras
Pedir Alimento
«realize»
Profesor Gerardo Cerda Neumann [email protected]
43
Relaciones en Diagramas de Paquetes
• Por lo menos un elemento de un paquetehace uso de la interfaz (es decir, un elemento del otro)
DependenciaDependencia
Alimentos
+ Carnes
+ Frutas
+ Verduras
Restorante
Pedir Alimento
«realize»
Dependencia
Profesor Gerardo Cerda Neumann [email protected]
44
Diagrama de Paquetes: Ejemplo
Datos
+ Base de Datos PUB
Interfaz Visual Pub
Lógica de Negocio Pub
+ Componentes Bodega
+ Componentes Pub
Serv icios
MailSeguridad
Subsistema Bodega
(from Lógica de Negocio Pub)
Subsistema Pub
(from Lógica de Negocio Pub)
«realize»«realize»
Ingeniería de Software
Tema: Conceptos Básicos de UML 2
Profesor Gerardo Cerda Neumann