Mtodos orientados a objetos

1
Métodos orientados a objetos

• Diseño e implementación

2
Dominios del problema y de la solución

• Decisiones de diseño explícitas y conocidas para
  poder corregirlas o cambiarlas.
• Modelos del problema reutilizables
• Experimentar con varios diseños y elegir el más
  conveniente.

3
Relación entre modelos de UML

• Modelo de clases y de colaboración
• Los mensajes del diagrama de colaboración son
  operaciones que aparecen en las clases.
• Para que un objeto mande un mensaje a otro, éste
  debe estar en el ámbito de visibilidad del
  primero enlace o atributo.
• Algunos contenedores de los diagramas de
  colaboración pueden no aparecer en los diagramas
  de clases.

4
Relación entre modelos de UML

• Modelo de clases y de estados
• Estado condición que deben cumplir una serie de
  atributos y enlaces de los objetos.
• Transiciones operaciones permitidas según el
  estado.
• El modelo dinámico de una clase es heredado por
  sus subclases. Según los atributos que determinan
  el estado en la clase y sus subclases
• Conjuntos de atributos disjuntos la subclase
  tiene un DTE compuesto de DTE concurrentes
  (agregación).
• No disjuntos el diagrama padre debe ser una
  proyección del diagrama hijo (generalización).

5
Arquitectura del software aspectos

• Distribución
• Centralizado, distribuido.
• Interacción entre componentes
• Jerárquica, cliente-servidor.
• Control
• Síncrono, asíncrono, concurrente, secuencial.
• Interacción del usuario

6
Interacción del usuario

• Separación de dos aspectos datos (modelo) y
  manipulación (vistas)
• Los cambios en cada aspecto deberían afectar lo
  menos posible al otro.

7
Interacción del usuario MVC

• Model, View, Controller (Smalltalk).
• Un sistema será una clase con objetos agregados
  de dos tipos
• Los datos los objetos que representan los datos.
• Las vistas los objetos que permiten interactuar
  con los datos.

8
Interacción del usuario MVC

• Necesidad de conocimiento mutuo entre vista y
  modelo

• INCONVENIENTES
• Pérdida de independencia
• Al añadir vistas hay que cambiar el modelo

9
Interacción del usuario MVC

• La aplicación relaciona modelos y vistas

10
Interacción del usuario Eventos
AlquilerDeVehiculos

• Se generan eventos ante los que reaccionan
  modelos y vistas

Objeto Vista (VistaCoche)
Objeto Modelo (Coche)
Gestor de eventos
Usuario
Objeto Vista (VistaCoche)
E1
11
Eventos código abstracto

• Generación de eventos
• ON ClaseModelo CHANGE tipoCambioModelo GENERATE
  eventName
• ON ClaseVista CHANGE tipoCambioVista GENERATE
  eventName
• Acciones ante un evento
• ON eventName MODEL DO métodoClaseModelo
• ON eventName VIEW DO métodoClaseVista

12
Eventos código ejemplo

• En Access se producen eventos para
• los objetos modelo tablas y registros.
• los objetos vista formularios, los Campos
  (controles).
• Al pinchar un control botón llamado calcTotal
• Private Sub calcTotal_Click()
• 'cálculo del total
• End Sub

13
Decisiones de diseño clases adicionales

• Clases del dominio del problema Ingreso,
  Paciente, Cama,...
• Clases contenedoras para manipular conjuntos de
  objetos necesitaremos estructuras de datos que
  contengan objetos del dominio del problema
  Tablas, Diccionarios, Listas,..
• Clases de interacción serán clases que nos
  permitan manipular la información de los objetos
  del dominio del problema. En general, estas
  clases son Vistas.

14
Clases adicionales contenedoras
15
Clases adicionales contenedoras
16
Clases adicionales vista
17
Clases adicionales vista
18
Decisiones de diseño navegabilidad

• Es una propiedad del papel de una asociación.
• Indica la posibilidad de navegar
  unidireccionalmente en una asociación desde los
  objetos fuente hasta la clase destino.

19
Decisiones de diseño navegavilidad

• Los diagramas de secuencia y colaboración
  muestran situaciones comunes que revelan la
  necesidad de definir navegabilidad entre clases
• La clase A envía un mensaje a la clase B.
• La clase A crea una instancia de la clase B.
• La clase A necesita mantener una conexión con la
  clase B.

20
Transformación de clases para una implementación
OO

• Todo atributo y operación en el diagrama de
  clases se debe declarar formando parte de su
  clase correspondiente.

class LíneaVenta int cantidad
subtotal( ) ... LíneaVenta() ...
21
Transformación de asociaciones para una
implementación OO

• Una asociación bidireccional es implementada,
  normalmente, como un atributo de referencia
  dentro de cada objeto asociado.
• Si la asociación es unidireccional sólo se
  necesita añadir un atributo de referencia a una
  de las clases.
• Una asociación también se puede implementar como
  una clase.

22
Transformación de asociaciones para una
implementación OO

• Los atributos de referencia de la clase uno
  son simplemente referencias a un objeto.
• Los atributos de referencia de la clase muchos
  necesitan un contenedor de objetos.
• Una asociación cualificada se puede implementar
  en forma de objeto diccionario.

23
Transformación de asociaciones para una
implementación OO
empresario
empleado
class Compañía Persona empleado
Compañía( )
class Persona Compañía empresario
Persona( )
24
Transformación de asociaciones para una
implementación OO
1..
1
Edita
Libros
Editorial
class Editorial Libro mislibros
Editorial( )
class Libro Libro( )
25
Transformación de clase asociación para una
implementación OO
0..
Esta autorizado en
0..
Usuario
Estación de trabajo
Autorización
class autorización usuario miusuario
estaciónt miestación autorización( )
class Usuario autorización miautori
Usuario( )
class estaciónt autorización miautori
estaciónt( )
26
Transformación de atributos de enlace para una
implementación OO

• Asociación uno-a-uno Los atributos de enlace se
  pueden almacenar como atributos de cualquiera de
  los objetos.
• Asociación uno-a-muchos Los atributos de enlace
  se pueden almacenar como atributos del objeto
  muchos.
• Asociación muchos-a-muchos Se implementa la
  asociación como una clase.

27
Transformación de agregación para una
implementación OO

• Se implementa igual que la asociación.

computadora
1
1..
monitor
teclado
class Computadora Monitor mismonitores
Teclado miteclado Computadora( )
class Monitor Monitor( )
class Teclado Teclado( )
28
Transformación de herencia simple para una
implementación OO
Lámpara
Incandescente
Fluorescente
class Fluorescente extends
Lámpara Fluorescente( )
class Incandescente extends Lámpara
Incandescente( )
class Lámpara Lámpara( )
29
Transformación de clases para una implementación
relacional

• Cada clase se corresponde con una o más tablas.
• La tabla debe contener todos los atributos de la
  clase y un atributo más para identificar los
  objetos.
• Se asigna un dominio a cada atributo.
• Se específica la clave primaria de la tabla.
• Se identifican los grupos de atributos a los que
  se accede con más frecuencia.

30
Transformación de clases para una implementación
relacional
Clave primaria ID-persona Acceso frecuente
ID-persona, nombre
31
Transformación de asociaciones para una
implementación relacional

• Cada asociación uno-a-uno se corresponde con una
  tabla distinta, o puede incluirse en forma de
  clave externa dentro de la tabla de cualquiera de
  las clases.
• Cada asociación uno-a-muchos se corresponde con
  una tabla distinta, o puede incluirse en forma de
  clave externa dentro de la tabla de la clase
  muchos.
• Cada asociación muchos-a-muchos se corresponde
  siempre con una tabla diferente.

32
Transformación de asociaciones para una
implementación relacional

• Los nombres de los rol se incorporan como parte
  del nombre de atributo de las claves externas.
• Las agregaciones siguen las mismas reglas que
  las asociaciones.

33
Transformación de asociaciones para una
implementación relacional
cargo
a) Clave externa independiente Tabla Persona
Clave primaria ID-persona.
34
Transformación de asociaciones para una
implementación relacional
Tabla Compañía
Clave primaria ID-compañía.
Tabla trabaja-para
Clave primaria ID-persona. Acceso frecuente
ID-persona, ID-compañía.
35
Transformación de asociaciones para una
implementación relacional
b) Clave externa incluida Tabla Persona
Clave primaria ID-persona.
Tabla Compañía
Clave primaria ID-compañía.
36
Transformación de asociaciones para una
implementación relacional
1..
1..
Posee acciones
Persona nombre dirección
Compañía nombre dirección
Número acciones
Tabla Persona
Clave primaria ID-persona.
37
Transformación de asociaciones para una
implementación relacional
Tabla Compañía
Clave primaria ID-compañía.
Tabla Posee-acciones
Clave primaria ID-persona, ID-compañía. Acceso
frecuente ID-persona, ID-compañía.
38
Transformación de asociaciones para una
implementación relacional
1..
1..
Persona nombre dirección
Compañía nombre dirección
cargo
Tabla Persona
Clave primaria ID-persona.
39
Transformación de asociaciones para una
implementación relacional
Tabla Compañía
Clave primaria ID-compañía.
Tabla para asociación cualificada
Clave primaria ID-persona, ID-compañía,
cargo. Acceso frecuente ID-persona, ID-compañía,
cargo.
40
Transformación de herencia simple para una
implementación relacional
41
Transformación de herencia simple para una
implementación relacional
a) Tabla para cada una de las clases Tabla
Pieza Tabla Bomba
Clave primaria ID-pieza. Clave primaria
ID-pieza. Tabla Intercambiador de calor
Clave primaria ID-pieza.
42
Transformación de herencia simple para una
implementación relacional
b) Duplicación de atributos de la superclase en
las subclases Tabla Bomba
Tabla Intercambiador de calor
Clave primaria ID-pieza. Clave
primaria ID-pieza.
43
Transformación de herencia simple para una
implementación relacional
c) Unificación en una sola tabla
Clave primaria ID-pieza.
44
Transformación de la especificación en diseño

• 1. Toma de decisiones sobre el diseño.
• 2. Identificación de las clases modelo más
  importantes.
• 3. Introducción en el modelo de clases de las
  clases de interacción (vistas).
• 4. Diseño de la interfaz de usuario.
• 5. Otras consideraciones de diseño.

45
1. Toma de decisiones sobre el diseño

• Decisiones sobre arquitectura.
• Lenguaje de implementación.
• Forma de implementación de asociaciones y
  herencia.
• Clases contenedoras y persistentes adicionales.

46
2. Clases modelo más importantes

• Según la INTERACCIÓN
• Clase principal clase núcleo del problema que
  posee entidad como para requerir interacción de
  algún tipo (Paciente, Ingreso, Coche, Cliente,
  Alquiler).
• Clase secundaria depende siempre de una
  principal y nunca se va a interactuar de forma
  independiente con ella. Son clases muy raras
  (Cama).
• Según la COMPOSICIÓN
• Clases simples sus objetos se pueden crear de
  forma independiente del resto de objetos del
  sistema (Paciente).
• Clases compuestas al crear objetos hay que
  relacionarlos con otros objetos ya existentes o
  que deben ser creados simultáneamente (Ingreso,
  Alquiler).

47
4. Diseño de la interfaz de usuario

• Dos formas principales de interacción
• Funcional según las operaciones principales del
  sistema.
• Objetos según las clases principales del
  sistema.

Archivo Edicion Ver Insertar Formato
Documentos Párrafos Letras Herramientas
Ventanas
48
Con frecuencia se mezclan sin ninguna sistemática
49
4. Diseño de la interfaz de usuario

• Una interfaz basada en Clases principales es más
  fácil de estructurar y más cercana al usuario.
• Ejemplo de Admisión
• Ejemplo TPDV

Pacientes Plantas Ingresos
Ventas Productos
50
(No Transcript)
51
4. Diseño de la interfaz de usuario

• Clases principales simples
• Se diseña una vista para ellas que permita
  realizar operaciones con sus objetos
• Crear introducir nuevos objetos.
• Modificar modificar los atributos de los
  objetos.
• Barrer recorrer el contenedor de objetos que las
  contienen y localizar objetos en ellas.
• Operaciones adicionales requeridas por el sistema.

52
(No Transcript)
53
(No Transcript)
54
4. Diseño de la interfaz de usuario

• Clases principales compuestas
• Igual que para las simples y además ...
• Se crean Subinterfaces para cada una de las
  componentes (clases relacionadas por
  asociaciones).
• Se crean Subinterfaces para las subclases.

55
(No Transcript)
56
(No Transcript)
57
(No Transcript)
58
PACIENTES
PLANTAS
Añadir Buscar...... Id Nombre Apellidos
Dirección
Añadir Buscar Borrar Listar PLANTA 3.1
SERVICIO Cirugía estética
Trasladar ------------ Ocupar ------------ Liberar
Modifica la cama en Ingreso Ojo con la
cardinalidad! 1 ó N?
59
5. Otras consideraciones de diseño

• Diagrama de transición de estados
• Restricciones sobre operaciones precondiciones,
  errores y excepciones.
• El estado de un objeto presentación del estado
  en la interfaz.
• Lógica algorítmica de estados.
• Seguridad protección de datos,
  comunicaciones,...
• Integridad modificaciones de objetos
  relacionados bajo un sistema de transacción.
• Mantenibilidad, eficiencia,...

60
Implementación en el modelo relacional

• Transformación de clases y asociaciones en
  tablas.
• Visualización de datos de varias tablas --gt
  consultas sobre las tablas relacionadas.
• Interfaz --gt lenguaje de programación con la
  misma filosofía (formularios o equivalentes).

61
Clases y asociaciones
Visualización de datos de varias tablas
62
(No Transcript)
63
(No Transcript)
64
Private Sub Pago_Click() On Error GoTo
Err_Pago_Click Dim stDocName As String
Dim stLinkCriteria As String Dim numero As
Double Call calcTotal_Click stDocName
"Pago" stLinkCriteria "id"
Me!id DoCmd.OpenForm stDocName, , ,
stLinkCriteria Forms!Pago.id
Me.id Forms!Pago.fecha Me.fecha
Forms!Pago.total Me.total Exit_Pago_Click
Exit Sub Err_Pago_Click MsgBox
Err.Description Resume Exit_Pago_Click
End Sub
Private Sub calcTotal_Click() total
totalTemp If IsNull(total) Then total 0 End
If