Conceptos Basicos Uml

Ingeniería de Software

Tema: Conceptos Básicos de UML 2

Profesor Gerardo Cerda Neumann

[email protected]

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


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


4

Modelamiento de Software

Un Modelo de Software es una Simplificación de la RealidadSimplificación de la Realidad


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:


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


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


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.


Los Modelos Tienen Los Modelos Tienen Diferentes Niveles de Precisión Diferentes Niveles de Precisión


9

• La idea principal de la orientación a objetos – acercarse a la realidad.


Los Mejores Modelos Los Mejores Modelos Tienen la Relación Clara con la Realidad Tienen la Relación Clara con la Realidad


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


Para Entender el Sistema Se Necesitan Para Entender el Sistema Se Necesitan Varios Modelos Complementarios Varios Modelos Complementarios


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


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


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..*


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


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


agregación, composiciónagregación, composición

Auto

Motor

Mano Dedo


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


herenciaherencia

Auto

VoladorVehiculo

Av ion


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


Clase asociativaClase asociativa

Persona

Auto

Compra

- fecha: Date- monto: Double

Mario :Persona

Renault :Auto

Jorge :Persona

1234 :Compra

2222 :Compra


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


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


20

Diagrama de CU: Ejemplo

Sistema de Pub

Barmen

Vender Bebida

Informar Bodega

Registrar Venta

Sistema de Bodega

«extend»

«include»


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


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


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


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


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


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)


asociaciónasociación

Usuario

Navegar Lista de Mensajes

Realizar log in

Sistema Web Pay

Realizar el Pago


27

• El diálogo incluído es una parte obligatoria del diálogo incluyentey va a resultar ejecutado cada vez que este se ejecute


incluyeincluye

Usuario

Realizar log in

Validar Datos de Autentificación

«include»


28

• El diálogo extendiente es una parte OPCIONAL del diálogo extendido y va a resultar ejecutado en CIERTAS EJECUCIONES del primer escenario


extiendeextiende

UsuarioNav egar Lista de

Mensajes

Abrir Mensaje

«extend»


29

• Un Caso de Uso es especificación del otro


herencia (de casos de uso)herencia (de casos de uso)

Realizar Transacción

Realizar Giro

Realizar DepositoCliente


30

• Un Actor es especificación del otro


herencia (de Actores)herencia (de Actores)

Usuario

Usuario Registrado

Consultar Producto

Comprar Producto


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»


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


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


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


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


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


37

Diagrama de Paquetes: Ejemplo

Datos

+ Base de Datos PUB

Interfaz Visual Pub

Lógica de Negocio Pub

+ Componentes Bodega

+ Componentes Pub

Serv icios


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


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


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


41


• Un paquete contiene el otro

AnidaciónAnidación

Alimentos

+ Carnes

+ Frutas

+ Verduras

Carnes

(from Alimentos)

Frutas

(from Alimentos)

Verduras

(from Alimentos)

Anidación


42


• 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»


43


• 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


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

[email protected]

Conceptos Basicos Uml

Technology

Transcript of Conceptos Basicos Uml