Generales
 Dia 1: Introducción a AyDOO y UML.
 Dia 2: Modelado Estático.
Dia 3: Modelado Dinámico.
Dia 4: Modelado Físico.
Dia 5: Caso de Estudio del CURP.
Contenido
 Modelando Casos de Uso.
 Diagrama de Casos de Uso.
 Diagrama de Clases.
 Diagrma de Objetos.
 Relaciones y Multiplicidad.
Modelando Casos de Uso
 Caso de Uso :
– Es una técnica de modelado utilizada para
describir funcionalidad nueva o ya existente de
un sistema.
– La funcionalidad es representada por un
número de casos de uso, cada uno de los cuales
especifica una funcionalidad particular.
Modelando Casos de Uso
– Es construido mediante un proceso de
modelado a través de diálogo entre
desarrolladores y cliente.
– Sus componentes primarios son casos de uso,
actores y el sistema modelado.
– El sistema es conceptualizado como una caja
negra que provee un caso de uso.
Casos de Uso
Set Limits
Update Accounts
Accounting System
Trading Manager
Analize Risk
<<uses>>
<<uses>>
Trader
Price Deal
Valuation
<<extends>>
Limits Exceeded
Salesperson
Un Diagrama de Casos de Uso
Propositos de los Casos de Uso
 Decidir y describir los requerimientos
funcionales del sistema.
 Describir de manera clara y consistente lo que
el sistema debe hacer.
 Proveer una base para la ejecución y
verificación del sistema.
 Facultar el rastreo de requerimientos
funcionales hacia clases y operaciones reales.
Creando un caso de Uso
 Encontrar Actores y Casos de Uso.
 Describir los Casos de Uso.
 Definir las relaciones entre Casos de Uso.
 Validar el Modelo.
Limites del Sistema
Insurance System
Un sistema en un modelo de Casos de Uso
Actores
 Un actor es algo o alguien que interactua
con el sistema, recibe o envia mensajes, o
bien intercambia información.
 Representa una entidad externa, un humano
o un sistema de software o hardware.
 Un actor es un tipo (clase) no una instancia,
representa un rol no un usuario individual.
Actores en el Argot de Modelado
 Estímulo: mensaje que envia un actor para iniciar
un caso de uso.
 Actor primario: interactua con la funcionalidad
principal.
 Actor secundario: administración, mantenimiento.
 Actor activo: inicia y participa un caso de uso.
 Actor pasivo: solo participa en un caso de uso.
Identificando Actores
 Quien hará uso de la funcionalidad
prinicipal del sistema ?.
 Quien requerirá apoyarse del sistema para
desempeñar sus actividades diarias ?.
 Quien necesitará, administrar, mantener y
operar el sistema ?.
Identificando Actores
 Que dispositivos requieren ser controlados
por el sistema ?.
 Existen sistemas externos que requieran
interactuar con el sistema ?.
 Quien o que tiene interés por el valor que el
sistema produce ?.
Representación Visual
<<Actor>>
Insurance Agent
Ins urance Agent
Un actor es una clase y se representa con un rectangulo con el
estereotipo <<actor>>.El icono estereotipo estandar stickman
normalmente es usado en diagramas de casos de uso, con el nombre
del actor debajo.
Estereotipos
 Un estereotipo, se refiere a un concepto de
UML que es definido para proveer la
funcionalidad de extender los elementos
básicos de modelado, de manera tal que
actúe como un artefacto de comunicación
para el buen entendimiento del sistema en
desarrollo.
 La notación es <<nombre>>
Relaciones entre Actores
Cliente
Cliente en Personal
Cliente por Teléfono
La clase base actor Cliente describe el rol general que desempeñan
cliente por teléfono y cliente en persona. Si para caso de uso
el medio por el cual un cliente se pone en contacto es indistinto, se
puede modelar con el cliente genérico, mientras caso de uso que no
enfaticen la importancia del medio que se utilce, debe modelar con
la subclase actor adecuada.
Casos de Uso
 Un caso de uso es un conjunto de secuencias de
acciones que realiza un sistema para procurar un
resultado observable a un actor en particular.
 Es siempre iniciado por un actor.
 Siempre provee un valor a un actor.
 Un Caso de Uso debe representar una descripción
de funcionalidad completa.
Representación Visual
System Name
Actor Name
Use Case A
Communication
Association
Use Case B
Use Case Name
Use Case C
En UML los Casos de Uso se representan con elipses contenidas en
por la periferia de un sistema, pueden tener asociaciones con actores.
Relaciones entre Casos de Uso
 Relación extiende (extends).
 Relación emplea (uses).
 Agrupación.
Relación Extiende
Signing Insurance Policiy
<<extends>>
Signing Car Purchase Contract
Signing Ins urance Policy
<<uses>>
<<uses>>
Signing Car Insurance
Signing Life Insurance
Describiendo Casos de Uso
 Se realiza mediante texto libre o un diagrama de
actividades, debe incluir:
–
–
–
–
–
Objetivo del Caso de Uso.
Forma en que es iniciado.
Flujos de mensajes entre actores y el Caso de Uso.
Flujos alternativos.
Como finaliza el Caso de Uso y el valor entregado al
usuario.
Describiendo Casos de Uso
Introduce dinero en la maquina
Checar dinero es suficiente
Mostrar que la bebida puede ser seleccionada
Consumidor
Elegir bebida
[bebida disponible]
Mostrar que no hay bebida
[Bebida no disponible]
Entregar Bebida
Un Caso de Uso descrito
mediante un diagrama
de actividades
Realizando Casos de Uso
 La tarea de realizar un Caso de Uso es
transformar los pasos y acciones de la
descripción del caso de uso en clases, sus
operaciones y relaciones entre ellas.
Principios para realizar Casos de
Uso
 Un Caso de Uso es realizado en términos de
colaboración.
 Una colaboración es representada como un
número de diagramas que muestran el contexto y
la interacción entre los participantes en la
colaboración, pueden expresarse mediante
diagramas de colaboración, secuencia y
actividades.
 Un escenario es una instancia de un caso de uso o
una colaboración.
Casos de Uso, colaboración y escenarios
Diagrama de Clases
 Describe una vista estática en terminos de
clases y asociaciones entre ellas.
 Describe estructura de la información al
igual que comportamiento.
 Muestra solamente clases y no instancias de
objetos.
 Sirve de base para la construcción de otros
diagramas.
..Diagrama de Clases
Compañia Seguros
1
0..*
Poliza de Seguro
0..*
1..*
Cliente
Clases
Nombre
Atributos
Operaciones
Una Clase en UML.
Notación de Atributos
Visibilidad:expresión-tipo=valor inicial {cadena-propiedad}
Visibilidad :
 + Público
 # Protegido
 - Privado
- nombre : String = “No Especificado”
#status Status = pagado { pagado, debido}
Notación de Atributos
UML
Factura
+ cantidad : real = initval
+ fecha : date = initval
+ cliente : string = initval
+ especificacion : string = initval
- administrador : type = "Ninguno"
- numeroFacturas : int
UML + Rose
Factura
cantidad : real = initval
fecha : date = initval
cliente : string = initval
especificacion : string = initval
administrador : type = "Ninguno"
$ numeroFacturas : int
Una clase y notación de visibilidad de atributos. El atributo
numeroFacturas es utilizado para contabilizar las facturas, este atributo
es el mismo para todos los objetos porque es compartido entre ellos.
Notación de Operaciones
Visibilidad (lista-de-parámetros) : expresión-tipo-devuelto
{cadena-propiedad}
Visibilidad :
 + Público
 # Protegido
 - Privado
Lista-de-parámetros
 nombre :expresión-tipo=valor-default.
Notación de Operaciones
Figura
tamagno: Tamagno
Posicion : Posicion
draw( )
escalar( escalX : int =25, escala Y : int = 25)
regresarPosicion( ):Posicion
llamada
figura.escalar(10,10)  escalaX = 10, escalaY = 10
figura.escalar(37)  escalaX = 37, escalaY = 10
figura.escalar( )  escalaX = 25, escalaY = 25
Mapeo Clase e Implementación
Public class Factura {
public double cantidad;
public Date fecha = new Date();
public String Cliente;
static private int
numeroDeFactura=0;
// Constructor, cada vez la clase
// es instanciada
public Factura () {
numeroDeFactura++;
//Incrementar el atributo de la clase
}
//Otros metodos
};
Estereotipos en Clases
 Clases Entidad: modela información y su
comportamiento asociado que es generalmente no
perecedera.
 Clases frontera: Maneja la comunicación entre la
periferia del sistema.
 Clases Control: Modelan el comportamiento de
secuencia de uno o mas Casos de Uso.
 Otras clases: utilidad, excepción.
Nivel de abstracción
Relaciones
 Asociaciones.
 Generalización.
 Dependencia.
 Refinado.
Relaciones en un diagrama de clases
Representación de asociaciones
PoliticaSeguro
0..1
Expresa un
expresa un
1
CompañiaSeguros
1
tiene
0..*
Contrato
se refiere a
0..*
se refiere a
Tiene
1..*
Cliente
Un diagrama de clases con asociaciones
Representación de asociaciones
Carro
Archivo
1
carro com pañia
conduce
0..*
Directorio
0..*
1
conductor
Persona
Representación de asociaciones
Canvas
*
Figura
Consiste de>
*
Grupo
Dibuja( )
Poligono
Dibuja( )
consiste de>
3..*
Dibuja ()
Linea
Circulo
Dibuja( )
Dibuja( )
Símbolos de asociación
 Multiplicidad : limite inferior.. Límite superior
– [0..1] [1] [*][1..*][1..6][1..3,7..10]
 Ordenamiento : ordenado no ordenado
 Calificador : [0..1] [1] [*]
 Flujo : hacia la clase que apunta la flecha
 Indicadores: Agregación/Composición
 Nombre del rol : rol en la asociación
Restricciones y Notas
Asociaciones Calificadas
Clases Asociación
Asociaciones Ternarias
Agregación y Composición
Composición
Relación de Generalización
Restricciones de Generalización
 Empalmada : puede descender de mas de una
subclase.
 Disjunta : No puede descender de mas de una
subclase.
 Completa : No es posible extender una clase a
mayor nivel.
 Incompleta : Es posible extender una clase a
mayor nivel.
Generalización y Restricciones
Información Derivada
Relación de Dependencia y Refinado
<<friend>>
Clase A
Clase B
Una relación de dependencia entre clases el tipo de dependencia se
muestra como un estereotipo, en este caso <<friend>>.
Clase en análisis
Asociación de refinado.
Clase en diseño
Paquetes y Dependencias
Clases Parametrizadas
T,n:int
Arreglo <Carro,100>
Arreglo <Carro,100>
<<bind>> <Color,50>
ArregloColores
Una clase parametrizada Arreglo con parámetros T (una clase) y n (entero)
Dos formas de representar instancias, una con el nombre del template y los
parámetros, o también mediante una relación de refinado de la clase
instanciada a la clase parametrizada.
Descargar

Desarrollo Orientado a Objetos