1Tema 8:Anlisis Orientado a Objetos con UML
Ingeniera del Software I (4 I.I)
Ingeniera del Software I (4 I.I)
Presentacin de UMLUML (Unified Modeling Language)
Es un lenguaje estndar para construir planos software
Modelo Conceptual de UML
Tres elementos principales:
BloquesPiezas bsicas utilizadas en el modelado.
ReglasDictan cmo combinar los bloques.
MecanismosAportan patrones que permiten construir modelos ms consistentes.
2Ingeniera del Software I (4 I.I)
Presentacin de UMLModelo Conceptual de UML
Estructurales
Comportamiento
Agrupacin
Anotacin
Bloques de construccin
Elementos Diagramas
Clases
Objetos
Casos de Uso
Secuencia
Colaboracin
Estados
Actividad
Componentes
Despliegue
Colaboracin
Dependencia
Asociacin
Generalizacin
Relaciones
Nombre
Alcance
Visibilidad
Integridad
Reglas
Afectan
Afe
ctan
Especificaciones
Adornos
Divisiones comunes
Extensibilidad
Mecanismos
Actan
Ingeniera del Software I (4 I.I)
Presentacin de UMLBloques
Tres tipos bsicos:
? Elementos.- son las abstracciones de primer nivel.
? Relaciones.- unen a los elementos entre s.
? Diagramas.- son agrupaciones de elementos que reflejan una vista del sistema .
3Ingeniera del Software I (4 I.I)
Presentacin de UMLElementos
Dependiendo del uso:? elementos estructurales.- describen los elementos bsicos de la visin esttica del sistema.
? elementos de comportamiento.- describen los elementos bsicos de la visin dinmica del sistema.
? elementos de agrupacin.- describe los elementos de agrupacin o empaquetamiento de algunos elementos fuertemente relacionados.
? elementos de anotacin.- describen los elementos que se utilizan para incluir notas descriptivas dentro de los modelos.
Ingeniera del Software I (4 I.I)
Presentacin de UMLElementos estructurales
Clase Interfaz Caso de Uso Colaboracin
Clase Activa Componente Nodo
4Ingeniera del Software I (4 I.I)
Presentacin de UMLElementos de comportamiento
Interaccin (mensaje) Mquinas de Estados (estado)
Esperando
Dibujar
Paquete
Reglas del negocio
Notas
Devuelve una copia del objeto receptor
Elementos de agrupamiento
Elementos de anotacin
Ingeniera del Software I (4 I.I)
Presentacin de UMLRelaciones
En funcin del tipo de interaccin existente entre los elementos :
? relaciones de dependencia .- indica que un cambio en la especificacin de un elemento puede afectar a otro que lo utiliza.
? relaciones de generalizacin.- expresa una relacin entre un elemento general y una ocurrencia ms especfica de ese elemento (relacin "es un tipo de")
? relaciones de asociacin.- especifica que los objetos de un elemento estn conectados con los objetos de otro.
? relaciones de realizacin.- define una relacin semntica entre clasificadores, en donde un clasificador especifica un contrato que otro garantiza que cumplir.
Dependencia
Asociacin0..1 *
patrn empleado
Generalizacin
Realizacin
5Ingeniera del Software I (4 I.I)
Presentacin de UMLDiagramasRepresentan grficamente una vista de una parte del sistema, aportando diferentes perspectivas y diferentes niveles de detalle que facilitan la comprensin del sistema
Cliente
Venta Normal
Venta en RebajasVendedor
Venta en Oferta
Diagrama de Casos de Uso
: Socio : Encargado : Libro : Ficha libro : Ficha socio : P r s t a m o
Coger libro
Solicitar prstamo
Verificar situacin socio
Si tuacin socio ok
Verificar situacin libro
Situacin libro ok
Introducir prstamo
A u t o r i z a r p r s t a m o
Diagrama de Secuencia
Diagrama de Actividad
: Socio
: Enca rgado
: Libro
: F i c h a l ibro
: Ficha socio
: Prstamo
1 : C o g e r l i b r o
2: Solicitar prstamo
8: Autorizar prstamo
3: Verif icar situacin socio
4: Situacin socio ok
5: Ver i f icar s i tuacin l ibro
6: Situacin libro ok
7: Introducir prstamo
Diagrama de Colaboracin
Avin mi l i tar Avin comercial
Avin de carga Avin de pasajeros
M o t o r
Avin
1. .4
1
Piloto Vendedor de billetes
Reserva
*
1
Vuelo*1
1..2
**1
Lnea area1
*
1
1. .41..2
*
1
*1 * 1 *
*
1
{ disjunta, completa }
{ disjunta, completa }
Diagrama de Clases
Sin prstamos
Con prstamos
Alta Baja
Prestar
Devolver[ Nmero prstamos = 1 ]
P r e s t a r
Devolver[ Nmero prstamos = 1 ]
Nmero prstamos > 1
Nmero prstamos = 0
Diagrama de Estados
Control y Anlisis
C o m m e n t
Acceso a BD
C o m m e n t
Rutinas de Coneccion
C o m m e n t
Inter faz de Terminal
C o m m e n t
Gestin de Cuentas
C o m m e n t
Diagrama de Componentes
P u n t o d e V e n t a
S e r v i d o r C e n t r a l
T e r m i n a l d e C o n s u l t a
G e s t i n d e C u e n t a s
C o m m e n t
I n t e r f a z d e T e r m i n a lR u t i n a s d e C o n e c c i o n
R u t i n a s d e C o n e c c i o n
I n t e r f a z d e T e r m i n a l
R u t i n a s d e C o n e c c i o n
A c c e s o a B D
C o m m e n t
C o n t r o l y A n l i s i s
C o m m e n t
Diagrama de DistribucinDiagrama de ObjetosP1: Profesor
D N I : 5 9 . 4 5 5 . 1 1 1N Contrato:1000
Nombre : Jos Prez Lpez
A 1 : A s i g n a t u r a
C d i g o : T 1 -1 - 03
C u r s o : P r i m e r oN o m b r e : I n t r o d u c c i n a l a I n f o r m t i c a
A 2 : A s i g n a t u r a
Cd igo :4 - 05
Curso: Cuarto
N o m b r e : I n g e n i e r a d e l S o f t w a r e I
T 2 : T i t u l a c i n
C d i g o : T 1
N o m b r e : I n g . S u p e r i o r e n I n f o r m t i c a
T 1 : T i t u l a c i n
C d i g o : T 1
N o m b r e : I . T c n i c a I n f o r m t i c a S i s t e m a s
Ingeniera del Software I (4 I.I)
Presentacin de UMLDiagramas Diagrama de casos de uso.
Muestra un conjunto de casos de uso, actores y sus relaciones.
Son especialmente importantes en la captura de los requisitos funcionales del sistema.
Diagrama de clases.
Muestra las clases, interfaces y colaboraciones, as como sus relaciones. Cubren la vista de diseo esttica de un sistema.
Cliente
Venta Normal
Venta en Rebajas Vendedor
Venta en Oferta
Diagrama de Casos de Uso
Avin militar Avin comercial
Avin de carga Avin de pasajeros
Motor
Avin
1 . . 4
1
P i l o t o Vendedor de billetes
Reserva
*
1
V u e l o*1
1 . . 2
**1
Lnea area
1
*
1
1 . . 4 1 . . 2
*
1
*1 * 1 *
*
1
{ disjunta, completa }
{ disjunta, completa }
Diagrama de Clases
6Ingeniera del Software I (4 I.I)
Presentacin de UMLDiagramas Diagrama de actividad.
Muestra el flujo de actividades dentro del sistema. Son importante para modelar el funcionamiento de un sistema y resaltan el flujo de control entre objetos.
Diagrama de estados.
Muestra una mquina de estados que consta de estados, transiciones, eventos y actividades.
Resaltan el comportamiento dirigido por eventos de un objeto.
.
Diagrama de Actividad
Sin prstamos
Con p rs tamos
A l t a B a j a
Prestar
Devolver[ Nmero prstamos = 1 ]
Prestar
Devolver[ Nmero prstamos = 1 ]
Nmero prstamos > 1
Nmero prstamos = 0
Diagrama de Estados
Ingeniera del Software I (4 I.I)
Presentacin de UMLDiagramas Diagrama de secuencia.
Es un tipo de diagrama de interaccin que resalta la ordenacin temporal de los mensajes
Diagrama de colaboracin.
Es el otro tipo de diagrama de interaccin que resalta la organizacin estructural de los objetos que envan y reciben mensajes.
: Socio : E n c a r g a d o : Libro : F i c h a l i b r o : F icha soc io : P rs tamo
Coger l ib ro
S o l i c i t a r p r s t a m o
V e r i f i c a r s i t u a c i n s o c i o
Situacin socio ok
Verif icar situacin l ibro
S i t u a c i n l i b r o o k
I n t r o d u c i r p r s t a m o
Autor izar prstamo
Diagrama de Secuencia
: S o c i o
: Encargado
: Libro
: F i cha l ibro
: Ficha soc io
: Prstamo
1: Coger l ibro
2: Solicitar prstamo
8: Autorizar prstamo
3: Veri f icar si tuacin socio
4 : S i t uac in soc io ok
5: Verificar situacin libro
6: Situacin l ibro ok
7: Introducir prstamo
Diagrama de Colaboracin
7Ingeniera del Software I (4 I.I)
Presentacin de UMLDiagramas
Diagrama de objetos.
Muestra un conjunto de objetos y sus relaciones. Representa instantneas de las instancias de los elementos de un diagrama de clases.
Diagrama de componentes.
Muestra la organizacin y dependencias de un conjunto de componentes. Un componente se corresponde con clases, interfaces y colaboraciones.
Diagrama de ObjetosP1: Profesor
DNI : 59.455.111N Contrato:1000Nombre : Jos Prez Lpez
A1: Asignatura
Cdigo:T1- 1- 03Curso: PrimeroNombre : Introduccin a la Informtica
A2: Asignatura
Cdigo:4- 05Curso: CuartoNombre : Ingeniera del Software I
T2: Titulacin
Cdigo: T1Nombre : Ing. Superior en Informtica
T1: Titulacin
Cdigo: T1Nombre : I. Tcnica Informtica Sistemas
C o n t r o l y A n l i s i s
C o m m e n t
A c c e s o a B D
C o m m e n t
R u t i n a s d e C o n e c c i o n
C o m m e n t
I n t e r f a z d e T e r m i n a l
C o m m e n t
G e s t i n d e C u e n t a s
C o m m e n t
Diagrama de Componentes
Ingeniera del Software I (4 I.I)
Presentacin de UMLDiagramas
Diagrama de distribucin o despliegue.
Muestra la configuracin de los nodos de procesamiento y los componentes que residen en cada uno de ellos.
P u n t o d e V e n t a
S e r v i d o r C e n t r a l
T e r m i n a l d e C o n s u l t a
G e s t i n d e C u e n t a s
I n t e r f a z d e T e r m i n a lRut inas de Conecc ion
Rut inas de Conecc ion
I n t e r f a z d e T e r m i n a l
Rut inas de Conecc ion
Acceso a BD
C o m m e n t
Control y Anlisis
C o m m e n t
Diagrama de Distribucin
8Ingeniera del Software I (4 I.I)
Presentacin de UMLReglas
Establece restricciones a la hora de combinar los bloques de construccin. UML define reglas semnticas para:
? Nombres.- cmo llamar a los elementos, relaciones y diagramas.
? Alcance.- contexto que da un significado especfico a un nombre.
? Visibilidad.- cmo se pueden ver y utilizar esos nombres por otros.
? Integridad.- cmo se relacionan apropiada y consistentemente unos elementos con otros.
? Ejecucin.- qu significa ejecutar o simular un modelo dinmico.
Ingeniera del Software I (4 I.I)
Presentacin de UMLMecanismos
Aportan patrones que permiten construir modelos ms consistentes. Podemos encontrar los siguientes:
? Especificaciones.- Asociada a cada elemento proporciona una explicacin textual de la sintaxis y semntica del bloque de construccin.
? Adornos.- Se incluye para resaltar algunos detalles de un determinado elemento y pueden ser de tipo textual o grfico.
? Divisiones comunes.- Divisin entre clase y objeto; divisin entre interfaz e implementacin.
? Mecanismos de extensibilidad.- permiten extender de manera controlada el lenguaje.
9Ingeniera del Software I (4 I.I)
Presentacin de UMLAdornos
Son complementos grficos o textuales que se aaden a la notacin bsica de un elemento para mostrar detalles de su especificacin.
Transaccin
Excepciones
AadirAccin()QuitarAccin()
TransaccinVaciaRecursoBloqueado
Nota
? Notas.- se utilizan para especificar caractersticas no recogidas en los elementos del modelo (requisitos, observaciones, revisiones, restricciones, etc.).
? Otros adornos.- Asociada a cada elemento proporciona una explicacin textual de la sintaxis
Dar nombre a los adornos para evitar confusin.
Ingeniera del Software I (4 I.I)
Presentacin de UMLMecanismos de extensibilidad
Permiten extender de manera controlada el lenguaje de modelado propuesto.
? Estereotipos.- extiende el vocabulario, permitiendo crear nuevos bloques derivados de los existentes.
? Valores etiquetados.- extiende las propiedades de un bloque permitiendo aadir nueva informacin a un elemento.
? Restricciones.- extiende la semntica de un bloque permitiendo aadir nuevas reglas o modificar las existentes.
10
Ingeniera del Software I (4 I.I)
Presentacin de UMLEstereotipos
Es un metatipo ya que equivale a crear una nueva clase del metamodelo en el que se apoya UML
Los nuevos bloque estereotipados tiene: Sus atributos (su propio conjunto de valores etiquetados. Su semntica (puede proporcionar restricciones propias). Su notacin (puede proporcionar su propio icono)
Generalmente se presenta como un >
ElementoMetamodelo
Overflow !
Clase Interfaz
Ingeniera del Software I (4 I.I)
Presentacin de UMLEstereotipos
Solo deben crearse cuando realmente son necesarios y no por un desarrollador aislado sino dentro de un proyecto o empresa.
Cuatro tipos de estereotipos:
Decorativos .- aportan smbolos que hacen ms comprensibles los modelos (p.e. smbolo de actor)
Descriptivos.- Utilizados para describir el contexto de aplicacin del concepto (p.e. clase de negocio)
Restrictivos .- Aportan restricciones aplicables a ciertos elementos (p.e. interfaz)
Clase Interfaz Clase ControlClase EntidadActor
11
Ingeniera del Software I (4 I.I)
Presentacin de UMLValores etiquetados
Puede especificar nuevas propiedades a un elemento cualquiera. Por tanto, son una herramienta til para definir detalles semnticos.
Es un metadato porque su valor se aplica al propio elemento, no a sus instancias.
Generalmente se presenta como una cadena de caracteres entre llaves que se coloca debajo del nombre de otro elemento.
Servidor Central
{procesadores=2}
FiguraGeomtrica{abstract Versin=1.3}
Visible: Boolean{sololectura}
Ingeniera del Software I (4 I.I)
Presentacin de UMLRestricciones
Especifica condiciones que deben cumplirse para que el modelo est bien formado.
Estas se pueden escribir en texto libre o utilizando OCL (Object Constraint Language) si se desea una especificacin ms precisa.
{segura}
Cuenta Bancaria
Empresa
Persona
Sexo{Hombre, mujer}
{OR}
0..1 Esposa
0..1 Marido
{self.esposa.sexo = mujer andself.marido.sexo = hombre}
12
Ingeniera del Software I (4 I.I)
Presentacin de UMLRestricciones
Pueden identificarse varios tipos de restricciones bsicas:
? Dependencia.? Consistencia.? Exclusin.? Valores.? Ordenacin.? Frmulas.? Enumeracin.
Ingeniera del Software I (4 I.I)
Presentacin de UMLRestricciones
Dependencia.- Expresan subordinacin entre dos relaciones.
Proyecto
Consistencia-
Empleado
Responsable de
Trabaja en
{subconjunto}
Factuaself.Contrato.Cliente= self.cliente
Cliente
Factura Contrato
Recibe
Tiene
BasadoEn
1
0..*0..*
1
Proyectoself.TrabajaEn->includes(self.ResponsableDe)
13
Ingeniera del Software I (4 I.I)
Presentacin de UMLRestricciones
Exclusin.- Expresan relaciones de tipo OR o XOR.
ProyectocivilPersona {OR}
Proyectomilitar
TrabajaEn
TrabajaEn
Suele ser interesante sustituirla por una generalizacin/ especializacin.
ProyectocivilPersona
Proyectomilitar
TrabajaEnProyecto
Ingeniera del Software I (4 I.I)
Presentacin de UMLRestricciones
Valores.- Las restricciones se aplican a los posibles valores de un atributo.
Tringuloa {c-b
14
Ingeniera del Software I (4 I.I)
Presentacin de UMLRestricciones
Frmulas.- Definicin de reglas de clculo asociadas a atributos derivados.
Persona
fechaNacimiento/edad {edad=hoy-fechaNacimiento}
Enumeracin.- Se utiliza para describir el conjunto de valores posibles de un atributo. Generalmente debe asociarsele una clase a dicho atributo.
Color
Color: {rojo, azul,verde)
Ingeniera del Software I (4 I.I)
Modelos Dominio del Problema.Qu es el Dominio del Problema?
Es una parcela del mundo real que deseamos modelar.
Caractersticas de los modelos asociados al Dominio del Problema.
Deben permitir describir los requisitos del sistema a modelar. Deben tener un alto nivel de abstraccin, deben contestar al QU. No deben responder a preguntas de implementacin.
15
Ingeniera del Software I (4 I.I)
Modelos Dominio del Problema.Dentro de UML tenemos modelos que pueden ser utilizados en diferentes instantes del desarrollo para descubrir nueva informacin sobre el sistema
Modelos que podemos utilizar para estudiar el Dominio del Problema.
Modelo o diagrama de casos de uso. Modelo o diagrama de clases abstractas. Modelo o diagrama de actividades Modelo o diagrama de secuencia bsico.
Ingeniera del Software I (4 I.I)
Captura de requisitos.Requisitos
Se recomienda utilizar los siguientes artefactos:
Descripcin bsica de los objetivos y metas del sistema.
Descripcin de los clientes para los que se desarrolla el producto.
Funciones bsicas, es decir, lo que el sistema deber hacer.
Caractersticas no funcionales que debe tener el producto final.
16
Ingeniera del Software I (4 I.I)
Captura de requisitos.Caractersticas no funcionales
Dentro de las caractersticas no funcionales podemos encontrar:
Facilidad de uso. Tiempo de respuesta. Plataforma de desarrollo e implementacin. Tolerancia a fallos. Fiabilidad y precisin. Mantenibilidad. Prioridades de implementacin....
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
Es una descripcin de un conjunto de accionesque ejecuta un sistema para producir un resultado observable de valor para un actor.
Qu es un caso de uso?
?Captura y especifica el comportamiento de un sistema o de parte del mismo, sin tener que especificar cmo se implementa.
?Representa la interaccin de los elementos externos al sistema.
17
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
?Puede tener variantes
Se puede factorizar el comportamiento comn y reutilizable de un conjunto de casos de uso segn las relaciones siguientes:
? son versiones especializadas de otros ms genricos
? estn incluidos como parte de otros
? extienden el comportamiento de otros ms bsicos
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
? Se utilizan durante muchas fases del desarrollo del software.
? Captura y anlisis de requisitos del sistema.
? Actan como base del proceso de diseo y permiten validarlo.
? Se utilizan para probar el software y en el proceso de asegurar la calidad (Quality Assurance) del mismo.
Las pruebas se realizan para validar la implementacin correcta y completa de los casos de uso.
? Potencialmente puede ser el punto inicial para las ayudas en lnea y el manual de usuario.
18
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
?Son entidades externas (personas o sistemas externos) que interaccionan con el sistema para conseguir una meta.
?Representa un conjunto coherente de roles que juegan los usuarios de los casos de uso al interaccionar con stos.
?Pueden definirse categoras de actores
Actor
Cliente comercial
Cliente
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
? Es frecuente que los actores coincidan con reas de la empresa (vendedor, gestor de almacn, etc.) o distinto nivel en la jerarqua (empleado, supervisor, etc.)
?Se conectan a los casos de uso a travs de asociaciones.Una asociacin indica que el actor y el caso de uso se comunicanentre s y cada uno puede enviar o recibir mensajes
Actor
19
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
El comportamiento de un caso de uso puede especificarse describiendo un flujo de eventos mediante texto.
? La especificacin de un flujo de eventos debe incluir:
?Cmo y cundo empieza y acaba.
?Cundo interacta con los actores.
?Qu objetos se intercambian.
?El flujo bsico y los flujos alternativos.
Flujo de eventos
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
Representa una instancia de un caso de uso y, por tanto, es una secuencia especfica de acciones que ilustra un posible comportamiento dentro de un caso de uso.
? Escenario Bsico.- se corresponde con la funcionalidad bsica
? Escenarios Secundarios.- se corresponden con funcionalidades alternativas y tratamiento de casos de error. No tienen sentido fuera del contexto del caso de uso donde ocurren.
Para su descripcin se pueden utilizar texto, pseudocdigo o incluso diagramas de interaccin.
Escenarios
20
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
Es una sociedad de elementos (tanto estticos como dinmicos) que colaboran para llevar a cabo el comportamiento de un caso de uso.
Especifican la realizacin de un caso de uso, es decir describen cmo se implementa.
Colaboraciones
Hacer pedido
Gestin de pedidos
Caso de uso
Colaboracin
Realizacin
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
Podemos encontrar diferentes relaciones entre casos de uso:
?Inclusin o Uso.- Se utiliza para evitar describir el mismo flujo de eventos, poniendo el comportamiento comn a varios casos en uno dado.
?Extensin.- Se utiliza cuando existe una secuencia opcional de eventos que se desea incluir en el caso de uso.
? Generalizacin.- Permite heredar el comportamiento y la semntica desde el caso de uso ms general.
Relaciones entre casos de uso
21
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
?Inclusin o Uso.-
?Extensin.-? Obtenga primero el caso de uso normal.? Pregntate: qu puede fallar?cmo podra funcionar esto de modo diferente??Dibuje las variaciones que encuentre como extensiones.
? Generalizacin
Relaciones entre casos de usoHacer pedido
Hacer pedido urgente
Validar Usuario
Hacer pedido
Validar UsuarioComprobar retina
Generalizacin
Comprobar clave
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
? Nombre: El nombre del caso de uso (verbo o frase verbal corta y significativa) .
?Meta: Resultado de valor que se pretende conseguir con su ejecucin.
? Actores: actores que participan.
? Disparador : Evento o eventos externos que activan su comienzo.
? Precondicin: cualquier condicin previa necesaria antes de que comience el caso de uso.
? Condicin de xito: qu se considera un final con xito (poscondicin).
? Condicin de fallo: qu se considera un final con fracaso (poscondicin).
? Escenarios .- Descripcin del escenario bsico y de los escenarios secundarios relevantes.
? Notas: Otra informacin relevante: rendimiento, frecuencia de uso...
Descripcin de un caso de uso
22
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
En funcin del nivel de detalle de la descripcin:?Alto nivel.- Descripcin muy breve que permita comprender
la complejidad y la funcionalidad bsica ?Expandido.- Describe el proceso ms a fondo incluyendo la
descripcin del flujo de eventos y escenarios.
En funcin del nivel de abstraccin:? Esencial.- Permiten captar la esencia del proceso y sus
procesos fundamentales sin incluir detalles de diseo.? Real.- Describe concretamente el proceso a partir de su
diseo concreto actual, sujeto a las tecnologas actuales.
Tipos de casos de uso
Alto nivel (poco detalle) Expandido (mayor detalle)
Esencial (muy abstracto) Real (muy concreto)
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
?Alto nivel - Esencial.-
Tipos de casos de uso
?Nombre: Comprar productos.
?Meta: Refleja el proceso de adquisicin de productos por parte de los clientes en un supermercado.
?Actores: Cajero, cliente.
?Disparador : El cliente presenta un conjunto de productos al cajero.
23
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
Tipos de casos de uso
?Nombre: Comprar productos.
?Meta: Refleja el proceso de adquisicin de productos por parte de los clientes en un supermercado.
?Actores: Cajero, cliente.
?Disparador : El cliente presenta en la caja con un conjunto de productos.
? Precondicin : La caja est abierta
?Condicin de xito: El cliente se lleva los productos adquiridos.
?Condicin de fallo: El cliente no tiene dinero para pagar los productos.
?Expandido- Real.-
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
Tipos de casos de uso (Expandido...)?Escenario bsico: (pago en efectivo)
Curso normal1.- El cliente llega a la caja con los productos que desea adquirir.2.- El cajero registra el identificador de cada producto.Si hay varios productos de un mismo tipo el cajero tambin puede introducir la cantidad.3.-Al terminar de introducir los producto el cajero indica su finalizacin al terminal de venta.4.- El cajero indica al cliente la cantidad a pagar.5.- El cliente paga los productos.6.- El cajero le devuelve el cambio.
Curso alternativo
5.1.- el cliente no tiene dinero y no se lleva los productos
24
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
Tipos de casos de uso (Expandido...)?Escenario secundario: (pago con tarjeta)
Curso normal1.- El cliente llega a la caja con los productos que desea adquirir. 2.- ...3.- ...4.- El cajero indica al cliente la cantidad a pagar.5.- El cliente entrega la tarjeta.
6.- El cajero introduce la tarjeta para realizar el cobro7.- El cliente firma el pago
Curso alternativo
5.1.- La tarjeta no es vlida en ese establecimiento6.1.-No existe comunicacin con la central de tarjetas.
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
Tipos de casos de uso (Expandido...)
?Notas:
? El tiempo de respuesta es bsico, ya que es habitual que haya varios clientes esperando.
? Los productos deben ser fcilmente identificables por el sistema.
? Se debe ayudar al cajero en la devolucin del cambio.
25
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
Use Case: 5 Buy Goods--------------------------------------------------CHARACTERISTIC INFORMATIONGoal in Context: Buyer issues request directly to our company, expects goods shipped and to be billed.Preconditions: We know Buyer, their address, etc.Success End Condition: Buyer has goods, we have money for the goods.Failed End Condition: We have not sent the goods, Buyer has not spent the money.Primary Actor: Buyer, any agent (or computer) acting for the customerTrigger: purchase request comes in.----------------------------------------MAIN SUCCESS SCENARIO1. Buyer calls in with a purchase request .2. Company captures buyers name, address, requested goods, etc.3. Company gives buyer information on goods, prices, delivery dates, etc.4. Buyer signs for order.5. Company creates order, ships order to buyer.6. Company ships invoice to buyer.7. Buyers pays invoice.
Descripcin de un caso de uso
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
----------------------EXTENSIONS3a. Company is out of one of the ordered items :
3a1. Renegotiate order.4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case 44)7a. Buyer returns goods :
7a. Handle returned goods (use case 105)--------------------SUB-VARIATIONS1. Buyer may use
phone in, fax in, use web order form, electronic interchange
7. Buyer may pay by cash or money ordercheckcredit card
Descripcin de un caso de uso
26
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
----------------------RELATED INFORMATIONPriority : topPerformance Target: 5 minutes for order, 45 days until paidFrequency: 200/daySuperordinate Use Case: Manage customer relationship (use case 2)Subordinate Use Cases:
Create order (use case 15)Take payment by credit card (use case 44)Handle returned goods (use case 105)
Channel to primary actor: may be phone, file or interacticeSecondary Actors: credit card company, bank, shipping serviceChannels to Secondary Actors :----------------------------OPEN ISSUESWhat happens if we have part of the order?What happens if credit card is stolen?---------------------------SCHEDULE Due Date: release 1.0
Descripcin de un caso de uso
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
?Identificar todos los casos de uso solo a nivel de nombre.?Expresarlos a alto nivel y de manera esencial? Ignorar detalles sobre la forma de la interaccin entre el actor y el
sistema? Incluir en la descripcin slo las alternativas relevantes, ignorando
tratamientos de error y excepcin.? No entrar en los detalles sobre las acciones que realiza el usuario
cuando interacta con el sistema
?Establecer la planificacin de la implementacin de los diferentes casos de uso
?Expresar los casos de uso a nivel expandido? Incluir una descripcin del interfaz con el usuario.? Incluir otras alternativas (errores y excepciones). ? Especificar con mas detalle el comportamiento interno del sistema.
Casos de uso y proceso incremental
27
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
Un proceso de negocio describe una actividad bsica del negocio incluyendo actividades que no son soportadas por el software .
Un caso de uso generalmente se asocia a aquellas actividadesde un proceso del negocio que van a ser soportadas con un desarrollo software .
Casos de Uso & Procesos del Negocio
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
Basados en la identificacin de los actores:
?Identificar actores participantes en el sistema.
?Identificar para cada actor los procesos que inicia o en los que participa.
Basados en la identificacin de los eventos:
?Identificar los eventos externos a los que el sistema debe responder.
?Relacionar eventos con actores y casos de uso.
Identificacin de casos de uso
28
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
Cuestiones tiles para encontrar casos de uso.
? Qu tareas o funciones principales realiza cada actor?
?Qu informacin del sistema debe adquirir, producir o cambiar el actor?
?Tendr que informar el actor al sistema sobre cambios en el entorno externo?
?Qu informacin desea obtener el actor del sistema?
?Desea el actor ser informado acerca de cambios inesperados en el sistema?
Identificacin de casos de uso
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
? Es completo el caso de uso? Han sido recogidos los detalles necesarios?
? Estas seguro que el resultado de valor (meta) para el actor se puede conseguir de manera correcta?
? Hay nuevas metas de actores que deben tenerse en cuenta?
? Hay nuevos actores que no se han representado (directa o indirectamente)?
? Hay cambios en los procesos o requisitos que puedan simplificar el caso de uso?
? ...
Es muy importante que los casos de uso sean validados.
Para ello se pueden realizar las siguientes preguntas:
29
Ingeniera del Software I (4 I.I)
Casos de Uso.Caso de Uso
RealizarPedido
? Nombra un comportamiento simple, identificable y razonablemente atmico.
? Factoriza el comportamiento comn, incorporando ese comportamiento desde otros casos de uso que incluye
? Factoriza variante, colocando ese comportamiento en otros casos de uso que lo extienden
? Describe el flujo de eventos de forma clara para que alguien externo al sistema lo entienda.
? Se describe por un conjunto mnimo de escenarios que especifican la semntica normal y de las variantes.
Caso de uso bien estructurado
Ingeniera del Software I (4 I.I)
Diagramas de Casos de Uso.Se utiliza para modelar la vista esttica de los casos de uso.
Puede utilizarse para:
? Describir el contexto de un sistema.
Implica dibujar una lnea alrededor de todo el sistema y asegurar qu actores quedan fuera de los lmites del sistema.
? Describir sus requisitos funcionales.
Implica especificar qu debera hacer el sistema.
Cliente
Venta Normal
Venta en Rebajas Vendedor
Venta en Oferta
Diagrama de Casos de Uso
30
Ingeniera del Software I (4 I.I)
Diagramas de Casos de Uso.Describir el contexto de un sistema
? Identificar actores entorno al sistema, considerando grupos que:
? Requieren ayuda del sistema para llevar a cabo sus tareas.
? Son necesarios para ejecutar las funciones del sistema.
? Interactan con el hardware externo o con otros sistemas.
? Organizar actores similares en jerarquas.
? Proporcionar un estereotipo para cada uno de esos actores.
? Introducir los actores en el diagrama y especificar las vas de comunicacin de cada actor con los casos de uso.
Cliente
Venta Normal
Venta en Rebajas Vendedor
Venta en Oferta
Diagrama de Casos de Uso
Ingeniera del Software I (4 I.I)
Diagramas de Casos de Uso.
? Establecer el contexto del sistema, identificando los actores a su alrededor.
? Considerar el comportamiento que cada actor espera o requiere que el sistema proporcione.
? Nombrar esos comportamientos como casos de uso.
? Factorizar el comportamiento comn (include) y las variantes (extend).
? Modelar los casos de uso, actores y relaciones en diagramas de casos de uso.
? Adornar los casos de uso con notas que enuncien los requisitos no funcionales.
Cliente
Venta Normal
Venta en Rebajas Vendedor
Venta en Oferta
Diagrama de Casos de Uso
Describir los requisitos de un sistema
31
Ingeniera del Software I (4 I.I)
Diagramas de Casos de Uso. ClienteVenta Normal
Venta en Rebajas Vendedor
Venta en Oferta
Diagrama de Casos de Uso
Ejemplo
Cajero Cliente
Comprarproductosefectivo
Comprartarjeta
>
Ingeniera del Software I (4 I.I)
Diagramas de Casos de Uso. ClienteVenta Normal
Venta en Rebajas Vendedor
Venta en Oferta
Diagrama de Casos de Uso
EjemploSe desea desarrollar un sistema para una empresa dedicada al transporte de pasajeros por avin. El sistema debe planificar los vuelos para el transporte de pasajeros.
El sistema se encarga de transportan tanto pasajeros (nombre, origen, destino, tipo de asiento, etc), como carga (peso, tamao, origen, destino, etc.), considerando a cada uno como elemento de embarque. Los clientes (tanto empresas como particulares) realizan sus reservas de embarque para el vuelo que desean al sistema, el cual debe responder con la confirmacin de las mismas.
Cada vuelo completo (misin) consta de un conjunto de saltos (segmentos de vuelo) que relacionan un aeropuerto de origen y otro de destino.
El personal de control de trfico debe realizar la asignacin de un avin (nmero, estado, modelo, capacidad, situacin, etc) a cada salto. Junto a ello se encargan de controlar y resolver las incidencias o fallos producidos en el transporte (fecha incidente, descripcin, accin correctora, etc.)
Para realizar la asignacin de un avin el personal de control de trfico necesita localizar al avin. Para ello necesita obtener informacin de un radar que enva posiciones en el espacio areo de un avin. Con dichas posiciones se genera una t rayectoria que permite predecir la nueva posicin del avin en un instante posterior.
32
Ingeniera del Software I (4 I.I)
Diagramas de Casos de Uso. ClienteVenta Normal
Venta en Rebajas Vendedor
Venta en Oferta
Diagrama de Casos de Uso
EjemploSolicitar
elemento de embarque
Cliente
Persona Empresa
Controlde trfico
Asignaravin asalto
Localizaravin
>
Radar
Controlar y resolverincidencias
Ingeniera del Software I (4 I.I)
Clases.Clase
Es una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica.
Qu es una clase?
? Son una abstraccin de las cosas que forman parte del vocabulario del dominio.
? Implementa una o ms interfaces.
Nombre
Atributos
Operaciones
33
Ingeniera del Software I (4 I.I)
Clases.Clase
Nombre
? Es una cadena de texto que denomina y describe el concepto asociado a una clase.
? Es interesante que se asocie a un nombre genrico.? Por ejemplo, en vez de Terminal de Registro de Ventana (TRV) es mejor poner registro, pues no se asocia con un dispositivo fsico concreto como en el caso de TRV.
? Generalmente se utilizan nombre simples o expresiones nominales extrados del dominio.
? Por lo general se suele poner la primera letra de cada palabra en maysculas (Cliente; SensorTemperatura)
Ingeniera del Software I (4 I.I)
Clases.Clase
Atributo? Es una propiedad, cualidad o caracterstica asociada a una clase, identificada por un nombre que describe un rango de valores que puede tomar la propiedad.
? Para identificarlos, cada clase debe preguntarse:Qu conozca de mi?
? El nombre de un atributo es un nombre corto o expresin nominal extrada del dominio.
? Por lo general se suele poner la primera letra de cada palabra en maysculas, excepto de la primera (precio; tipoProducto)
? Junto al nombre se pueden incluir otras caractersticas (tipo, valor por defecto, etc.) que se vern en caractersticas avanzadas.
34
Ingeniera del Software I (4 I.I)
Clases.Clase
Operacin
? Es una implementacin de un servicio que puede ser requerido a cualquier objeto de la clase para que muestre un comportamiento.
? Generalmente la invocacin de una operacin sobre un objeto produce un cambio en los datos o el estado de ste.
? El nombre de una operacin es un verbo o expresin verbal extrado del dominio.
? Por lo general se suele poner la primera letra de cada palabra en maysculas, excepto de la primera (comprar; calcularImporte)
Ingeniera del Software I (4 I.I)
Clases.Clase
Operacin
? Junto al nombre se puede especificar su signatura.
? Nombre, tipo y valores por defecto de los parmetros y en ciertos casos necesarios tipo de retorno.
SensorTemperatura
reiniciar()ponerAlarma(t: Temperatura)valor() : Temperatura
35
Ingeniera del Software I (4 I.I)
Clases.Clase
Responsabilidad
? Es un contrato o una obligacin de una clase.
? Las responsabilidades se llevan a cabo mediante los atributos y operaciones.
? Un buen comienzo en el modelado de las clases es especificar las responsabilidades de los conceptos manejados en el dominio del problema.
? Tcnicas para definir responsabilidades:? Tarjetas CRC (Clase-Responsabilidad-Colaborador).? Anlisis basado en casos de uso.
? Se especifican mediante texto libre utilizando una frase o un prrafo corto.
Ingeniera del Software I (4 I.I)
Clases.Clase
Especificacin de una clase
? Para facilitar la comprensin no se suelen mostrar todos los atributos y operaciones de la clase, o incluso a veces slo se muestra el nombre de la clase.
? Se puede indicar explcitamente que hay ms atributos o propiedades mediante: ...
? Para organizar mejor las listas de atributos y operaciones es interesante utilizar estereotipos para anteponer a cada grupo una categora descriptiva.
36
Ingeniera del Software I (4 I.I)
Clases.Clase
El objetivo es identificar los conceptos significativos del dominio.
Dos posibles estrategias:
?A partir de una lista de categoras.
?A partir de identificacin de frases nominales.
Identificacin de clases
Ingeniera del Software I (4 I.I)
Clases.Clase
Categora del concepto Ejemplo
Objetos fsicos tangibles Camin
Especificaciones o Descripcin del productodescripciones de cosasLugares Tienda, Almacn,
Delegacin
Transacciones Venta, Pago, Reserva
Lnea o elemento de una Lnea de una Ventatransaccin
Papeles de las personas Vendedor, Camionero
Lista de categoras conceptos
37
Ingeniera del Software I (4 I.I)
Clases.Clase
Categora del concepto Ejemplo
Contenedores de cosas Tienda, Almacn
Cosas dentro del contenedor Producto
Otros sistemas software Sistema de autorizacin de externos tarjeta de crdito
Conceptos abstractos Hambre
Organizaciones Depto de Ventas
Eventos Pago, Anulacin
Lista de categoras conceptos
Ingeniera del Software I (4 I.I)
Clases.Clase
Categora del concepto Ejemplo
Procesos Venta de un producto
Reglas y polticas Poltica de reembolso por anulacin
Catlogos Catlogo de productos
Documentos, libros Manual de Personal, Ticket de compra
Instrumentos y servicios Existencias, Lnea de crditofinancieros
Lista de categoras conceptos
38
Ingeniera del Software I (4 I.I)
Clases.Clase
Este mtodo consiste en identificar en las descripciones textuales del dominio nombre o frases nominales y considerarlas como conceptos.
En esta estructura los verbos representan asociaciones entre conceptos.
Ejemplo.-El cliente realiza los pedidos
Identificacin de frases nominales
Cliente PedidoRealiza
Ingeniera del Software I (4 I.I)
Clases.Clase
?Incorporacin de documentos como clases.
? Incorporarlos slo si cumplen un papel especial respecto a las reglas del negocio (ejemplo.- un recibo de compra puede ser necesario para realizar una devolucin).
?Distincin entre atributo y clase.
? Si el concepto identificado no se describe mediante un simple nmero o texto descriptivo, posiblemente sea una clase.
Errores y problemas en la identificacin de clases
39
Ingeniera del Software I (4 I.I)
Clases.Clase
Errores y problemas en la identificacin de clases
?Diferenciacin entre elementos fsicos y descripcin de elementos.? Incorpore una clase que hace referencia a una descripcin de elementos si:? La eliminacin de las instancias de los elementos fsicos da como resultado la prdida de informacin.
? Reduce informacin redundante o duplicada.
Producto
identificacindescripcinprecionmeroSerie
Desc. Productoidentificacindescripcinprecio
Producto fsiconmeroSerie
Ingeniera del Software I (4 I.I)
Clases.Clase
Tarjetas CRC? Son tarjetas donde se describen las clases sus responsabilidades y otros colaboradores.
? Un colaborador son aquellas otras clases que deben existir para permitir que la clase original pueda asumir una responsabilidad.
? Es una herramienta particularmente til en el anlisis.
? Ayudan a obtener una visin ms completa y compresible de los conceptos del dominio del problema.
? Su principal aplicacin es estructurar y describir de manera detallada aunque abstracta los conceptos del dominio del problema.
40
Ingeniera del Software I (4 I.I)
Clases.Clase
Tarjetas CRC? Se suele crear una CRC para cada concepto que aparece en un caso de uso. Dicho concepto se asocia con una clase.
? Mientras los casos de uso se encargan de definir el comportamiento, las CRC ayudan a clarificar su estructura.
Pedido
Revisa si hay elementos en stock LneaPedido,Artculo
Determina el precio LneaPedido,Artculo
Revisa si el descuento es correcto Cliente
ColaboradorResponsabilidad
Ingeniera del Software I (4 I.I)
Clases.Clase
Tarjetas CRC? Las tarjetas CRC son una tcnica muy vlida para ser utilizada en sesiones en grupo.
? Son utilizadas con dos propsitos bsicos:? Es una tcnica colectiva que permite definir los conceptos del dominio.? Las discusiones de las diferentes perspectivas permite que las ideas aportadas por los diferentes participantes puedan ser comprobadas en cuanto a su validez.
? Tener en cuenta las siguientes caractersticas:
? Evitar tarjetas demasiado orientadas a los datos.? Especificar el rol con que una clase participa en la colaboracin. Evitar crear varias tarjetas para los diferentes roles de una clase.
41
Ingeniera del Software I (4 I.I)
Clases.Clase
?Proporciona una abstraccin precisa de algo extrado del dominio del problema.?Contiene un conjunto pequeo de responsabilidades.?Proporciona una clara diferenciacin entre la especificacin y su implementacin.
Clase bien estructurada
?Mostrar slo las clases relacionadas.?Mostrar slo aquellas propiedades de la clase que sean importantes para comprender la abstraccin.?Organizar las listas largas de atributos y operaciones agrupndolas segn su categora.
Especificacin de una clase en Diagrama de Clases
Ingeniera del Software I (4 I.I)
Clases.Clase
Clase de anlisis
? Se centra en los requisitos funcionales
? Debe describir un concepto ms conceptual.
? Raramente define u ofrece un interfaz en trminos de operaciones con su signatura.
? Su comportamiento se define mediante responsabilidades a un alto nivel de descripcin.
?Responsabilidad es una descripcin textual de un conjunto cohesivo del comportamiento de una clase.
42
Ingeniera del Software I (4 I.I)
Clases.Clase
Clase de anlisis
? Puede incluir atributos pero a alto nivel de abstraccin y deben ser claramente reconocibles en el dominio del problema.
? Adems los atributos identificados durante el anlisis puede convertirse en clases durante le diseo.
? Participa en relaciones aunque dichas relaciones son conceptuales, desprecindose caractersticas como navegabilidad o estructuras de generalizacin especializacin que permitan optimizar el software o mejorar la reutilizacin.
? Se pueden hacer corresponder con uno de los tres estereotipos bsicos: interfaz, entidad o control .
Ingeniera del Software I (4 I.I)
Clases.Clase
Clase de interfaz
? Se utilizan para modelar la interaccin entre el sistema y sus actores
? Modelan las partes del sistema que dependen de los actores y, por tanto, renen los requisitos en los lmites del sistema.
? Por tanto, las interfaces de usuario y las interfaces de comunicacin quedan aisladas en este tipo de clases.
? Cada clase interfaz debera estar asociada al menos a un actor.
43
Ingeniera del Software I (4 I.I)
Clases.Clase
Clase de interfaz
? Representan abstracciones de los elementos de la interfaz, pero deben mantenerse a un nivel de abstraccin elevado.
?Pueden representar abstracciones de ventanas, formularios, interfaces de comunicacin, sensores , etc., pero no deben detallarse en exceso. Por tanto, no se est pidiendo un prototipo final de la interfaz.
Ingeniera del Software I (4 I.I)
Clases.Clase
Clase de entidad
? Se utilizan para modelar la informacin que posee una vida ms larga y que a menudo es persistente.
? Se corresponden con conceptos del dominio del problema.
? Se pueden derivar directamente de una clase de entidad del negocio, aunque pueden corresponder a un subconjunto de ellas.
? Puede tener un comportamiento relativo a la informacin que representa.
44
Ingeniera del Software I (4 I.I)
Clases.Clase
Clase de control
? Representa la coordinacin, secuencia, transacciones y control de la lgica del negocio compleja que implica a varios objetos.
? Se utilizan para encapsular el control de un caso de uso concreto.
? Se pueden utilizar tambin para representar derivaciones o clculos complejos que no pueden asociarse a ninguna informacin (clase entidad) concreta.
Ingeniera del Software I (4 I.I)
Clases.Clase
Diagrama de clases asociado a la realizacin de un caso de uso? Una clase de anlisis y sus objetos participan en varias realizaciones de casos de uso.
? Algunas responsabilidades, atributos y asociaciones suelen ser slo relevantes para una nica realizacin de caso de uso.
? Es importante, por tanto, durante el anlisis coordinar todos los requisitos sobre una clase y sus objetos que puede estar asociados a diferentes casos de uso.
45
Ingeniera del Software I (4 I.I)
Clases.Clase
Ejemplo
Comprador IU SolicitudPago
Factura
GestorPagos
GestorPedidos
PedidosConfirmados
Pagos
Ingeniera del Software I (4 I.I)
Atributos.Clase
Qu es un atributo?
? Es una propiedad, cualidad o caracterstica asociada a una clase, identificada por un nombre que describe un rango de valores que puede tomar la propiedad.
? Para identificarlos, cada clase debe preguntarse:Qu conozca de mi?
? Un atributo no debera ser un concepto complejo del dominio.
? Para establecer relaciones entre conceptos se deben utilizar relaciones, no atributos.
46
Ingeniera del Software I (4 I.I)
Atributos.Clase
?Los atributos tienen un tipo que no tiene que corresponder obligatoriamente con un tipo primitivo (nmero, carcter, etc.)
?Represente como tipos no primitivos aquellos que pueden considerarse primitivos si:? Se compone de secciones independientes (n telfono, nombre de una persona).
? Normalmente se le asocian operaciones de anlisis o validacin (DNI,ranking o importancia de un cliente, etc).
? Posee otros atributos asociados (el precio de rebajas est asociado a una fecha de inicio y otra de final).
? Es una cantidad con una unidad asociada (el importe del pago puede tener asociada una unidad monetaria).
Ingeniera del Software I (4 I.I)
Relaciones.Qu es una relacin?
Expresa una conexin entre las clases del dominio.
Podemos encontrar tres tipos bsicos de relaciones:
?Dependencias.- Representan relaciones de uso entre clases.
?Generalizaciones.- Conectan clases generales con sus especializaciones.
?Asociaciones.- Representan relaciones estructurales entre objetos.
0..1 *patrn empleado
47
Ingeniera del Software I (4 I.I)
Relaciones.Dependencia
? Declara que un cambio en la especificacin de un elemento puede afectar a otro elemento que lo utiliza, pero no necesariamente a la inversa.
? Se representa mediante una flecha con trazo discontinuo que va dirigida hacia el elemento del cual se depende.
? La mayora de las veces se utiliza para indicar que una clase utiliza otra como argumento en la signatura de una operacin.
0..1 *patrn empleado
PelculaVideo
reproducirEn (c:Canal)
Canal
Ingeniera del Software I (4 I.I)
Relaciones.Generalizacin
? Indica una relacin entre un elemento ms general (supertipo) y un caso ms especfico (subtipo) de ese elemento.
? A veces se le denomina relacin es-un-tipo-de.
? Los objetos hijos se pueden emplear en cualquier lugar que pueda aparecer el padre, pero no a la inversa.
? Las clases hijas heredan las caractersticas (atributos, operaciones y relaciones) de sus clases padres.
0..1 *patrn empleado
48
Ingeniera del Software I (4 I.I)
Relaciones.Generalizacin
? La generalizacin produce una estructura jerrquica en la que existen clases sin padres (clase base) y clases sin hijos (clases especializadas u hojas).
0..1 *patrn empleado
Figura
mover()dibujar()
posicin: Punto
Rectngulo
dibujar()
esquina: Punto Crculo
dibujar()
radio:Float
Polgono
dibujar()
puntos: Lista
Cuadrado
Ingeniera del Software I (4 I.I)
Relaciones.Generalizacin
Cuando deberamos definir un subtipo?.
0..1 *patrn empleado
? Debemos asegurarnos que esta particin es til en el dominio del problema.
? Motivos para realizar la particin:
?El subtipo tiene otros atributos.
?El subtipo tiene otras asociaciones.
?Se pude especificar un comportamiento especfico para el subtipo o se reacciona ante l de manera diferente a como se hara ante el supertipo.
49
Ingeniera del Software I (4 I.I)
Relaciones.Generalizacin
Cuando deberamos definir un supertipo?.
0..1 *patrn empleado
? Motivos para realizar la generalizacin:
?Los conceptos asociados a subtipos potenciales representan variaciones de un concepto semejante.
?Los conceptos comparten entre si varios atributos o comportamientos semejantes.
?Existen relaciones compartidas por los conceptos candidatos a subtipos que pueden generalizarse y asociarse al supertipo.
Ingeniera del Software I (4 I.I)
Relaciones.Generalizacin
Clases abstractas
0..1 *patrn empleado
? Representan clases que no contienen objetos.Slo pueden aparecer dentro de jerarquas de generalizacin.
? Se pueden asociar a clases de una jerarqua en la que los objetos siempre deben pertenecer a uno de los subtipo definidos.
Rectngulos Crculos Polgonos
Figuras
50
Ingeniera del Software I (4 I.I)
Relaciones.Generalizacin
Clases abstractas
0..1 *patrn empleado
? Se representan poniendo el nombre de la clase en cursiva o mediante el valor etiquetado {abstract} debajo del nombre de la clase.
Figura
mover()dibujar()
posicin: Punto
Rectngulo
dibujar()
esquina: Punto Crculo
dibujar()
radio:Float
Polgono
dibujar()
puntos: Lista
Figura{abstract}
mover()dibujar()
posicin: Punto
Ingeniera del Software I (4 I.I)
Relaciones.GeneralizacinEstructuras mltiples:
0..1 *patrn empleado
? La generalizacin puede ser:? simple.- un subtipo solo tiene un supertipo (padre).?mltiple.- un subtipo puede tener varios supertipos (padres).
Personanombredireccin
Empleado
fechaNacimientoidentificacionUsuariopassword
Accionista
nmeroAcciones
EmpleadoAccionista
fechaNacimientoidentificacionUsuariopasswordnmeroAcciones
Persona
nombredireccin
EmpleadofechaNacimientoidentificacionUsuariopassword
AccionistanmeroAcciones
EmpleadoAccionista
51
Ingeniera del Software I (4 I.I)
Relaciones.Asociacin
0..1 *patrn empleado
0..1*
patrn empleado
? Especifica que los objetos de una clase estn conectados con objetos de otra clase.
? Puede verse como:?unin o conexin de ideas?establece las relaciones entre los objetos necesarios para llevar a cabo un conjunto de requerimientos
? Pueden incluirse cuatro adornos a la asociacin.?Nombre.- Se utiliza para describir la naturaleza de la asociacin.?Rol.- Es el papel especfico que juega una clase en dicha relacin.?Multiplicidad.-Indica cuntos objetos pueden conectarse a travs de una instancia de la asociacin.?Agregacin .-Permite modelar relaciones especiales de tipo todo/parte.
Ingeniera del Software I (4 I.I)
Relaciones.Asociacin
0..1 *patrn empleado
0..1*
patrn empleado
Nombre .- describe la relacin existente entre las clases .
Para aclarar su significado suele ser interesante indicar la direccin de lectura.
PersonaEmpresa
Trabaja en
Puede no ser necesario su inclusin si se indican los nombre de los roles.
52
Ingeniera del Software I (4 I.I)
Relaciones.Asociacin
0..1 *patrn empleado
0..1*
patrn empleado
Rol.- es la cara que la clase de un extremo de la relacin presenta a la clase del otro extremo.
Una clase puede jugar el mismo o diferentes roles en otras asociaciones.
PersonaEmpresaEmpleadoPatrn
Ingeniera del Software I (4 I.I)
Relaciones.Asociacin
0..1 *patrn empleado
0..1*
patrn empleado
Multiplicidad.- indica el nmero de objetos que puede participar en una instancia de la relacin.
En una relacin se indican tantas multiplicidades como clases participen en la asociacin.
En la multiplicidad se indican los lmites inferior y superior de los objetos participantes.
? 1 -> exactamente 1? 0,1 -> cero o uno? 0..4 -> entre cero y cuatro? 3,7 -> tres o siete? 0..* -> mayor o igual de cero (por defecto)? 1..* -> mayor o igual a uno? 0..3, 7, 9..* -> cualquier nmero menos 4, 5, 6 y 8
53
Ingeniera del Software I (4 I.I)
Relaciones.Asociacin
0..1 *patrn empleado
0..1*
patrn empleado
Multiplicidad.-
Cuando se indica una multiplicidad en un extremo de la asociacin, se est especificando que, para cada objeto de la clase en el extremo opuesto, debe haber tantos objetos en este extremo
PersonaEmpresa1..*1
Persona 1Empresa 1
Persona 2Empresa 2
Persona 3
Ingeniera del Software I (4 I.I)
Relaciones.Asociacin
0..1 *patrn empleado
0..1*
patrn empleado
Agregacin.- describe asociaciones en las que existe una jerarqua de composicin en la que una clase representa el todo y otras las partes que lo constituyen.
Empresa
1
Departamento
*
Todo
Parte
La existencia de una agregacin no liga la existencia del todo y sus partes.
54
Ingeniera del Software I (4 I.I)
Relaciones.Asociacin
0..1 *patrn empleado
0..1*
patrn empleado
Agregaciones tpicas.-Avin
0,1
Motor
0..4? Partes que componen un objeto de nivel superior
? Elementos contenidos en otro nivel superior
?Miembros de una coleccin o conjunto.
Avin
0,1
Pasajeros
0..n
Vuelo
1..n
SegmentoVuelo
1..n
Ingeniera del Software I (4 I.I)
Relaciones.Asociacin
0..1 *patrn empleado
0..1*
patrn empleado
Composicin.- es un tipo especial de agregacin en la que la existencia de las partes est ligada a la del todo.
El objeto parte puede pertenecer a un todo nico, es ms se espera que las parte vivan y mueran con el todo.
Cliente
CuentaBancaria
0..*
Todo
Parte
55
Ingeniera del Software I (4 I.I)
Relaciones.Otras caractersticas
0..1 *patrn empleado
Las relaciones pueden tener asociados atributos.
Empresa
Empleado
*
1..* Empleo
desdehasta
Ingeniera del Software I (4 I.I)
Relaciones.Clase
Categora de asociacin Ejemplo
A es una parte fsica de B Ala-Avin;
A es una parte lgica de B TramoVuelo-RutaVuelo
A est fsicamente contenido Producto-Estante; en B Pasajero-Avin A est contenido lgicamente Producto-Catlogoen B
A es una descripcin de B DescripcinProducto-Producto
A es un elemento de una lnea LneaPedido-Pedidoen una transaccin B
Lista de categoras asociaciones
56
Ingeniera del Software I (4 I.I)
Relaciones.Clase
Categora de asociacin EjemploA se conoce/introduce/ Reserva-ListaPasajeros;registra/presenta/captura en B Venta-CajaA es miembro de B Piloto-Avin;
Vendedor-TiendaA es una subunidad Departamento-Tienda; organizacional de B Mantenimiento-LneaArea
A usa o dirige a B Piloto-Avin
A se comunica con B Cliente-Vendedor;AgenteReserva-Pasajero
A se relaciona con una Pago-Pedido;transaccin B Pasajero-Billete
Lista de categoras asociaciones
Ingeniera del Software I (4 I.I)
Relaciones.Clase
Categora de asociacin EjemploA es una transaccin relacionada Pago-Venta;con otra transaccin B Reserva-Cancelacin
A est contiguo a B Ciudad-Ciudad
A es propiedad de B Avin-LineaArea;
Lista de categoras asociaciones
57
Ingeniera del Software I (4 I.I)
Diagramas de Clases. Avin militar Avin comercialAvin de carga Avin de pasajeros
Motor
Av in
1 . . 4
1
Pi loto Vendedor de billetes
Reserva
*
1
Vuelo*1
1 . . 2
*
*1
Lnea area
1
*
1
1 . . 41 . . 2
*
1
*
1 * 1 *
*
1
{ disjunta, completa }
{ disjunta, completa }
Diagrama de Clases
Un diagrama de clases muestra un conjunto de clases, interfaces y colaboraciones, as como sus relaciones.
? Colaboracin .- Sociedad de roles (clases) y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos (especificacin de cmo se realiza un elementos, tal como un caso de uso o una operacin, por un conjunto de clasificadores y asociaciones).
?Interfaz.- Coleccin de operaciones que se utilizan para especificar un servicio de una clase o componente.
Ingeniera del Software I (4 I.I)
Diagramas de Clases. Avin militar Avin comercialAvin de carga Avin de pasajeros
Motor
Av in
1 . . 4
1
Pi loto Vendedor de billetes
Reserva
*
1
Vuelo*1
1 . . 2
*
*1
Lnea area
1
*
1
1 . . 41 . . 2
*
1
*
1 * 1 *
*
1
{ disjunta, completa }
{ disjunta, completa }
Diagrama de Clases
Ejemplo Empresa
*
Personanombredireccin
Empleado
fechaNacimientoidentificacionUsuariopassword
Accionista
nmeroAcciones
Departamentonombre
Oficinadireccintelfono
Se ubica
*
1
directormiembro
1..*
{subconjunto}
RegistroPersonalhistorialEmpleossalario
obtenerResgistrosPersonales
0,1
*
1
1..* 1..*
IinformacinSegura
58
Ingeniera del Software I (4 I.I)
Diagramas de Clases. Avin militar Avin comercialAvin de carga Avin de pasajeros
Motor
Av in
1 . . 4
1
Pi loto Vendedor de billetes
Reserva
*
1
Vuelo*1
1 . . 2
*
*1
Lnea area
1
*
1
1 . . 41 . . 2
*
1
*
1 * 1 *
*
1
{ disjunta, completa }
{ disjunta, completa }
Diagrama de Clases
Se utiliza para:
?Modelar el vocabulario de un sistema.? Tomar decisiones sobre qu abstracciones son parte del sistema y cules caen fuera de sus lmites. Se utilizan para especificar abstracciones y sus responsabilidades.
?Modelar colaboraciones simples.? Prestar atencin a la visualizacin especificacin, construccin y documentacin de la forma en que los conceptos abstractos del dominio colaboran entre s.
?Modelar un esquema lgico de base de datos.? Los diagramas de UML son un superconjunto de los diagramas Entidad-Relacin.
Ingeniera del Software I (4 I.I)
Diagramas de Clases. Avin militar Avin comercialAvin de carga Avin de pasajeros
Motor
Av in
1 . . 4
1
Pi loto Vendedor de billetes
Reserva
*
1
Vuelo*1
1 . . 2
*
*1
Lnea area
1
*
1
1 . . 41 . . 2
*
1
*
1 * 1 *
*
1
{ disjunta, completa }
{ disjunta, completa }
Diagrama de Clases
?Cada diagrama debe centrarse en una colaboracin.
?Para modelar una colaboracin:? Identificar los mecanismos a modelar. Un mecanismo representa una funcin o comportamiento de la parte del sistema que se estmodelando que resulta de la interaccin de una sociedad de clases, interfaces y otros elementos.
?Para cada mecanismo identificar las clases, interfaces y otras colaboraciones que participan en esta colaboracin, as como susrelaciones.
? Usar escenarios para recorrer la interaccin entre los elementos.
? Completar la descripcin de los elementos. Para las clases hay que comenzar con un reparto de responsabilidades. Despus hay que convertir dichas responsabilidades en atributos y operaciones.
Modelar colaboraciones simples
59
Ingeniera del Software I (4 I.I)
Diagramas de Clases. Avin militar Avin comercialAvin de carga Avin de pasajeros
Motor
Av in
1 . . 4
1
Pi loto Vendedor de billetes
Reserva
*
1
Vuelo*1
1 . . 2
*
*1
Lnea area
1
*
1
1 . . 41 . . 2
*
1
*
1 * 1 *
*
1
{ disjunta, completa }
{ disjunta, completa }
Diagrama de Clases
?Los modelos de clases no slo permiten describir los datos sino el comportamiento. ? En una base de datos estas operaciones generalmente se convierten en disparadores o procedimientos almacenados.
?Para modelar un esquema:?Identificar aquellas clases cuyo estado debe perdurar en el tiempo.
? Crear un diagrama. Las clases pueden completar su descripcin con valores etiquetados que describan informacin de las base de datos.
? Especificar los atributos , las relaciones y las cardinalidades.
? Considerar el comportamiento de las clases, expandiendo las operaciones de acceso a la base de datos, o aquellas que permiten asegurar la integridad. En general las reglas del negocio deben modelarse en una capa por encima de las clases persistentes.
Modelar un esquema lgico de base de datos
Ingeniera del Software I (4 I.I)
Diagramas de Clases. Avin militar Avin comercialAvin de carga Avin de pasajeros
Motor
Av in
1 . . 4
1
Pi loto Vendedor de billetes
Reserva
*
1
Vuelo*1
1 . . 2
*
*1
Lnea area
1
*
1
1 . . 41 . . 2
*
1
*
1 * 1 *
*
1
{ disjunta, completa }
{ disjunta, completa }
Diagrama de Clases
Ejemplo
origen
destino
destino
destinoorigenorigen
tiene
0,11
1
2..n
0,10..n
1
0..nse asigna
0..n
0..n
0..n
1
1..n
1..n
ElementoEmbarquenmerosituacinActual
Pasajeros
asiento
Carga
pesotamaodescripcin
Aeropuerto
nombreciudad
SegmentoVuelonmerodescripcin
Misinnmerodescripcinhorario
Avinnmeroestadomodelocapacidad
FallosAvinfechahoradescripcin
Trayectoriafecha
PuntoEspacioAreofechahoraposicin
Cliente
ParticularEmpresa
razonSocial
PersonanombreApellidos
adquiere0..n
1
60
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
Qu es un diagrama de actividades?
Es fundamentalmente un diagrama de flujo que muestra el flujo de control entre actividades.
?Un diagrama de interaccin muestra objetos que se pasan mensajes, un diagrama de actividades muestra las operaciones que se pasan entre los objetos.
Actividad es un estado con una accin interna y uno o ms transiciones de salida que automticamente preceden a la terminacin de la accin interna.
?Las actividades producen una accin, que est compuesta de computaciones atmicas ejecutables que producen un cambio en el estado del sistema o la devolucin de un valor
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
Ejemplo
Construir casa ( )
Disponer de solar
Contratar arquitecto
[no aceptado]
Obtener plano ypresupuesto obra
[en otro caso]
Vender casa
Terminarpromocin vivienda
:CertificadoVivienda
[terminado]
Estado accin
Flujo de objeto
Estado inicial
Estado final
Bifurcacin
Divisin
Unin
Estado de actividadcon submquina
Guarda
61
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
Normalmente los diagramas de actividades contienen:
?Estados de actividad y estados de accin.?Estado de actividad.-Elemento compuesto cuyo flujo de control se compone de otros estados de actividad y de accin.?Estado de accin.- Estado que representa la ejecucin de una accin atmica, normalmente la invocacin de una operacin.
?Transiciones.?Relacin entre dos estados que indica que un objeto en el primerestado realizar ciertas acciones y pasar al segundo estado cuando ocurra un evento especfico y satisfaga ciertas condiciones.
?Objetos.?Manifestacin concreta de una abstraccin o instancia de una clase.
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
Estados de actividad y de accin
?Pueden definirse tambin otro tipo de estados:? Inicial.
?Final.
Preparar oferta
Procesar Pedido (f)
?Estado de actividad.-Elemento compuesto, cuyo flujo de control se compone de otros estado de actividad y de accin.
?Estado de accin.- Ejecucin de una accin atmica.?No pueden descomponerse y la aparicin de eventos no puede interrumpir su ejecucin. ?Generalmente se considera que su ejecucin conlleva un tiempo insignificante.
62
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
?Se representa mediante una lnea dirigida del estado inicial al siguiente.
Transiciones
Estado inicial Estado final
?Podemos encontrar diferentes tipos de transacciones:
? Secuencial o sin disparadores.-
?Bifurcacin.-
?Divisin y unin.-
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
?Secuencial o sin disparadores.-
Al completar la accin del estado origen se ejecuta la accin desalida y, sin ningn retraso, el control sigue por la transicin y pasa al siguiente estado.
Transiciones
Estado accin 1
Estado accin 2
Transicin sin disparadorEstado accin
63
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
?Bifurcacin.-
Especifica caminos alternativos, elegidos segn el valor de alguna expresin booleana.
Transiciones
Actividad
[x>0]
[x0]
[x
64
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
?Divisin y unin. -
Por definicin, en la unin los flujos entrantes se sincronizan, es decir, cada uno espera hasta que todos los flujos de entrada hanalcanzado la unin.
Transiciones
? Para expresar otro tipo de unin se pueden utilizar valores etiquetados.
{AND} {OR} {XOR}
? Para expresar que la actividad subsiguiente se realiza mltiple s veces se utiliza *.
*
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
Ejemplo
Cuando recibimos un pedido, comprobamos cada artculo de la lnea de pedido para ver si tenemos existencias de l. Si la respuesta es afirmativa, asignamos la mercanca al pedido. Si esta asignacin hace bajar la cantidad de productos en almacn por debajo del nivel mnimo, se realiza un pedido a los proveedores.Mientras hacemos esto, revisamos el pago para ver si est correcto. Si el pago est bien y hay mercancas en existencia, servimos el pedido. Si el pago est correcto pero no tenemos existencias de ese producto, dejamos el pedido en espera. Si el pago no es correcto, se cancela la orden.
65
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
Recibir orden
Cancelar orden Autorizar pago Comprobar existencia
*[por cada artculo de la lnea de pedido]
[fallo]
[xito] [en existencia]
Asignar a orden
Realizar pedido a proveedoresServir pedido
[se necesita solicitar existencias]
[existencia asignada a todos los artculos de del pedido y pago autorizado]
Disparador mltiple
Condicin de sincronizacin
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
Ejemplo
Cuando llega un reabastecimiento de los proveedores, vemos los pedidos pendientes y decidimos cules pueden servirse con el material recibido y, entonces, asignamos los productos correspondientes a dichos pedidos. Con esto se pueden servir lasordenes pendientes. La mercanca restante se guarda en el almacn.
66
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
Recibirabastecimiento
Servir el pedidoAgregar resto de
productos a existencias
*[por cada artculo de pedido seleccionado]
Asignar artculoa pedido
[existencia asignada a todos los artculos de del pedido y pago autorizado]
Seleccionar artculosde pedidos pendientes
[se han asignado todos los artculos necesarios a los pedidos pendientes]
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
Recibirabastecimiento
Agregar resto deproductos a existencias
*[por cada artculo de pedido seleccionado]
Asignar artculoa pedido
[existencia asignada a todos los artculos de del pedido y pago autorizado]
Seleccionar artculosde pedidos pendientes
[se han asignado todos los artculos necesarios a los pedidos pendientes]
Servir pedido
Recibir orden
Cancelar orden
Autorizar pago Comprobar existencia
*[por cada artculo de la lnea de pedido]
[fallo] [xito]
[en existencia]
Asignar a orden
Realizar pedido a proveedores
[se necesita solicitar existencias]
67
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
Calles (Swimlanes)
? Permiten ver QUIENES son los responsables de realizar las distintas actividades.?Especificar qu parte de la organizacin es responsable de una actividad.
? Cada calle tiene un nombre nico dentro del diagrama.
? Puede ser implementada por una o varias clases.
?Las actividades de cada calle se consideran independientes y se ejecutan concurrentemente a las de otras calles.
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
Recibir orden
Cancelar orden Autorizar pago Comprobar existencia
*[por cada artculo de la lnea de pedido]
[fallo]
[xito] [en existencia]
Asignar a orden
Realizar pedido a proveedoresServir pedido
[se necesita solicitar existencias]
[existencia asignada a todos los artculos de del pedido y pago autorizado]
Disparador mltiple
Condicin de sincronizacin
Ventas Almacn
68
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
Flujo de objetos
?Permiten mostrar los objetos que participan dentro del flujo de control asociado a un diagrama de actividades.?Junto a ello se puede indicar cmo cambian los valores de sus atributos, su estado o sus roles.
Recibir orden
Servir pedido
o: Orden[en progreso]
o: Orden[finalizada]
Objeto
EstadoFlujo de objeto
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
Cundo emplear los diagramas de actividades?
?En el modelado de los procesos del negocio.?Permiten especificar y evaluar el flujo de trabajo de los procesos de negocio.
?En el anlisis de un caso de uso. ?Permiten comprender qu acciones deben ocurrir y cules son las dependencias de comportamiento.
?En la comprensin del flujo de trabajo, a travs de varios casos de uso.?Permiten representar con claridad las relaciones de flujo de trabajo (workflow) entre varios casos de uso.
?Cuando se trata de expresar aplicaciones multihilos.
69
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
En qu situaciones no utilizarlos?
?Para tratar de ver cmo colaboran los objetos.?En estos casos, es mejor utilizar los diagramas de interaccin.
?Para tratar de ver cmo se comporta un objeto durante su ciclo de vida. ?En estos casos, es recomendable utilizar los diagramas de estados.
Ingeniera del Software I (4 I.I)
Diagramas de Actividades.Diagrama de Actividad
Exposicin del caso.-Se desea estudiar el sistema de pedidos de libros, realizados por los clientes, en una librera y su posterior
envo y facturacin.Se supone que la librera no mantiene stock de libros y por tanto debe pedir los libros solicitados a las
editoriales correspondientes, con las cuales tiene concertado un sistema de descuentos en funcin de la cantidad de libros solicitados.
Cada cliente tiene asociado un crdito permitido que debe ser controlado por el sistema para no aceptar pedidos si ste ha sido superado. Una vez validados los pedidos son agrupados por editorial para realizar un pedido de reaprovisionamiento asociado a los pedidos de los clientes.Estos pedidos se realizan dos das por semana.
Cada editorial tiene establecido un tiempo estndar de respuesta. Una vez transcurrido este tiempo ms una semana el pedido reaprovisionamiento puede ser anulado. Tras recibir y validar que lo enviado por la editorial se corresponde con lo solicitado, se deben asociar los pedidos de reaprovisionamiento y los de los clientes.
Cuando el pedido del cliente est completo debe aadirse la direccin de envo y generar una prefactura, la cual ir acompaando a los libros solicitados por el cliente. Una vez recibido el paquete con los libros y la prefactura, el cliente deber realizar el pago asociado a dicha prefactura.
Al ser recibido un pago del cliente, deber asociarse a una prefactura pendiente y enviar una factura definitiva al cliente. Si el pago no se efecta en un perodo de 30 das desde el envo de la prefactura, el pedido llevar un recargo adicional.
La direccin de ventas desea obtener mensualmente una estadstica de compras por cliente, para de este modo poder clasificar a sus clientes en funcin a su volumen de pedidos. Junto a este informe, la misma direccin desea enviar un catlogo general anualmente y otro de novedades con carcter mensual , sobre aquellos temas de ms inters para cada cliente, para lo cual desea disponer de una estadstica que indique los temas ms frecuentemente solicitados.
Una peticin normal de los clientes, una vez solicitado un pedido, es saber en qusituacin se encuentra.
70
Ingeniera del Software I (4 I.I)
Diagramas de Secuencia.
Qu es un diagrama de secuencia?
Es un tipo de diagrama de interaccin.
?Muestra la interaccin entre un conjunto de objeto y sus relaciones, incluyendo los mensajes que pueden enviarse entre ellos, en el que se destaca la ordenacin temporal de los mensajes.
? Este tipo de diagramas se emplea bsicamente en el diseo.
? En el anlisis se utiliza para especificar el paso de mensajes entre los actores y el sistema (diagrama de secuencia del sistema).
: Socio : E n c a r g a d o : L i b r o : Ficha libro : Ficha socio : P r s t a m o
Coger libro
Solicitar prstamo
Ver i f icar s i tuacin socio
S i t u a c i n s o c i o o k
V e r i f i c a r s i t u a c i n l i b r o
Situacin libro ok
I n t r o d u c i r p r s t a m o
Autor izar prs tamo
Diagrama de Secuencia
Ingeniera del Software I (4 I.I)
Diagramas de Secuencia.
Diagrama de secuencia del sistema
? Es una representacin que muestra los eventos generados por los actores externos y su orden .
? Permite expresar qu hace el sistema desde la perspectiva del usuario.
?Puede ser interesante crear uno de estos diagramas para cada escenario de los diferentes casos de uso.
: Socio : E n c a r g a d o : L i b r o : Ficha libro : Ficha socio : P r s t a m o
Coger libro
Solicitar prstamo
Ver i f icar s i tuacin socio
S i t u a c i n s o c i o o k
V e r i f i c a r s i t u a c i n l i b r o
Situacin libro ok
I n t r o d u c i r p r s t a m o
Autor izar prs tamo
Diagrama de Secuencia
71
Ingeniera del Software I (4 I.I)
Diagramas de Secuencia.
Diagrama de secuencia del sistema
: Socio : E n c a r g a d o : L i b r o : Ficha libro : Ficha socio : P r s t a m o
Coger libro
Solicitar prstamo
Ver i f icar s i tuacin socio
S i t u a c i n s o c i o o k
V e r i f i c a r s i t u a c i n l i b r o
Situacin libro ok
I n t r o d u c i r p r s t a m o
Autor izar prs tamo
Diagrama de Secuencia
:Sistema
introducirProducto (identificador, cantidad)
terminarVenta()
pago(totalDinero)
Repetir mientrashaya productos.
Ejemplo:
Evento del sistema
Ingeniera del Software I (4 I.I)
Diagramas de Secuencia.
Diagrama de secuencia del sistema
: Socio : E n c a r g a d o : L i b r o : Ficha libro : Ficha socio : P r s t a m o
Coger libro
Solicitar prstamo
Ver i f icar s i tuacin socio
S i t u a c i n s o c i o o k
V e r i f i c a r s i t u a c i n l i b r o
Situacin libro ok
I n t r o d u c i r p r s t a m o
Autor izar prs tamo
Diagrama de Secuencia
Cmo se elabora?.
?Trazar una lnea vertical que represente al sistema como un todo.
?Identifique los actores que operan directamente con el sistema para un escenario de un caso de uso.
?A partir de la descripcin del escenario identifique los eventos que son generados por los actores.
?Ordene dichos eventos de arriba abajo segn su orden de aparicin o ejecucin.
72
Ingeniera del Software I (4 I.I)
Paquete
Es un mecanismo que permite organizar los elementos de modelado en bloques mayores que se pueden manipular en grupo.
?Permiten controlar la visibilidad de los elementos de un grupo desde el exterior.?Agrupan elementos cercanos semnticamente y que suelen cambiar juntos.?Son cohesivos y poco acoplados.
Paquete
Reglas del negocio
Qu es un paquete?
Reglas del negocio
Ingeniera del Software I (4 I.I)
Paquete
?Un paquete puede contener otros elementos: clases, interfaces, componentes, nodos, colaboraciones, casos de uso, diagramas e incluso otros paquetes.
?Cada elemento pertenece exclusivamente a un nico paquete
?Forma un espacio de nombres nico? Dentro de l no pueden existir dos elementos de la misma categora con el mismo nombre.
?Permiten controlar la visibilidad de los elementos de un grupo desde el exterior.
?Pueden establecerse jerarqua de paquetes? No ms de tres niveles.
Paquete
Reglas del negocio
73
Ingeniera del Software I (4 I.I)
Paquete
?Para poder acceder a los elementos contenidos de un paquete debe importarse dicho paquete.
? Importacin: concede un permiso de un solo sentido para que los elementos de un paquete puedan acceder a los elementos de otro.? Se utiliza el estereotipo import
?Las dependencias de importacin y acceso no son transitivas
?Si un elemento es visible en un paquete lo es a todos los paquetes contenido en ese paquete
Paquete
Reglas del negocio
Importacin
Ingeniera del Software I (4 I.I)
Paquete
?Normalmente los elementos contenidos en un paquete son pblicos (+), es decir, son visibles por cualquier paquete que importe al paquete contenedor.
? El conjunto de partes pblicas constituye su interfaz.
?Los elementos protegidos (#) slo pueden ser vistos por los hijos dentro de una jerarqua de herencia.
?Los elementos privados (-) no son visibles fuera del paquete donde se declaran.
?Los paquete que son amigos (friend) de otro pueden ver todos los elementos de ste, sin importar cul sea su visibilidad.
Paquete
Reglas del negocio
Visibilidad
74
Ingeniera del Software I (4 I.I)
Paquete
?Pueden definirse jerarquas de generalizacin al igual que suceden con otros elementos como clases, casos de uso, etc.
?Los elementos ms especializados heredan los elementos pblicos y protegidos del paquete ms general.
?Los paquetes ms especializados pueden reemplazar a los elementos ms generales y aadir otros.
?Un paquete generalizado puede utilizarse dondequiera que se use un paquete ms general.
Paquete
Reglas del negocio
Generalizacin
Ingeniera del Software I (4 I.I)
Paquete
?Examinar los elementos de una determinada vista arquitectnica en busca de grupos de elementos cercanos desde el punto de vista conceptual o semntico.
?Englobar cada uno de esos grupos en un paquete.
?Para cada paquete definir los elementos que pueden ser accedidos desde fuera. En caso de duda ocultar el elemento.
?Conectar explcitamente los paquetes que dependen de otros a travs de dependencias de importacin.
?En caso de encontrar familias de paquete utilizar la generalizacin.
Paquete
Reglas del negocio
Modelado de grupos de elementos
75
Ingeniera del Software I (4 I.I)
PaquetePaquete
Reglas del negocio
Servicios de Usuario
Servicios de Datos
Servicios de Negocio
Cliente
+ Formulario de pedidos- Pedido
GUI
+ Ventana+ Formulario# GestorEventos
WindowsGUI
+ GUI::Ventana+ Formulario# GUI::GestorEventos+ VBForm
MacGUI
Ingeniera del Software I (4 I.I)
Paquete
?Deberan crearse basndose en los requisitos funcionales y en el dominio del problema y, por tanto, deberan ser reconocibles por las personas con conocimiento del dominio.
?Contiene generalmente clases de anlisis y realizaciones de casos de uso
?Una forma inicial de identificarlos es asignarle los casos de uso que :
? den soporte a un determinado proceso de negocio,? den soporte a un determinado actor del sistema,? estn relacionados mediante relaciones de generalizacin y de extensin.
Paquete
Reglas del negocio
Modelado de paquetes de anlisis
76
Ingeniera del Software I (4 I.I)
Paquete
?Un servicio representa un conjunto coherente de acciones relacionadas funcionalmente que se utilizan en varios casos de uso y que son de valor para un determinado cliente.
?Tiene las siguientes caractersticas:?Contiene un conjunto de clases relacionadas funcionalmente?Es indivisible?Cuando se realiza un caso de
Top Related