El documento presenta una introducción al análisis orientado a objetos. Explica que este involucra descomponer un problema en sus partes, identificar tipos de objetos antes que objetos individuales, y enfocarse más en la estructura que en el comportamiento. También detalla los 4 pasos del análisis: 1) identificar la idea y objetivos del sistema, 2) identificar actores/nombres, 3) identificar procesos/requerimientos, y 4) identificar clases y asociaciones.

1. Presentación
Análisis Orientado a Objetos
Ing. Mauricio Paletta, Msc
INGENIERÍA EN INFORMÁTICA
Programación II
UNIVERSIDAD NACIONAL EXPERIMENTAL DE GUAYANA
Programación II

2. Análisis Orientado a Objetos
• Descomposición de un problema en sus
partes.
• Resultado: Problema entendido como una
preparación para el diseño.
• Preocuparse más por identificar los tipos de
objetos que los objetos individuales.
Programación II

3. Análisis Orientado a Objetos
• Preocuparse más por el modelo estático
(estructura) que por el modelo dinámico
(comportamiento).
• Productos: Diagramas de casos de uso y
diagrama de clases.
• 4 pasos a realizar.
Programación II

4. Análisis Orientado a Objetos
Paso 1: Identificar la idea y objetivos
básicos del sistema
• Primer contacto con el problema, se busca entenderlo
de forma completa.
• Técnicas que se pueden seguir:
o Escribir entre 5 y 20 oraciones de la información que
se haya podido recopilar mediante entrevistas.
o Si ya se tiene un enunciado o documento explicativo,
extraer las oraciones de allí.
o Mapas mentales sobre el problema.
Programación II

5. Análisis Orientado a Objetos
Programación II

6. Análisis Orientado a Objetos
Programación II

7. Análisis Orientado a Objetos
Paso 2: Identificar actores / nombres
• Los actores o nombres son posibles clases.
• Se identifican a partir de las oraciones obtenidas en el
paso anterior.
• Todos los nombres deben ser considerados
inicialmente, luego se hará un proceso de selección o
filtrado.
Ejemplo:
“Un sistema de reservación para la venta de boletos a
varias obras de teatro”
Programación II

8. Análisis Orientado a Objetos
Paso 3: Identificar procesos /
requerimientos
• Descripción del sistema desde el punto de vista del
usuario. Se conocen como casos de uso y se pueden
representar mediante los diagramas de casos de uso de
UML.
• Colección de situaciones respecto al uso de un sistema.
Cada escenario describe una secuencia de eventos.
Cada secuencia se inicia por una persona, otro sistema,
una parte del hardware o por el paso del tiempo. A estas
entidades que inician secuencias se les conoce como
actores.
Programación II

9. Análisis Orientado a Objetos
• El resultado de una secuencia debe ser algo utilizable
ya sea por el actor que la inició o por otro actor.
• El detalle de la secuencia de eventos desde que un
actor la inicia hasta que se llega al resultado se puede
representar mediante los diagramas de actividad de
UML.
Programación II

10. Análisis Orientado a Objetos
Paso 4: Identificar Clases y Asociaciones
• Obtener la lista definitiva de conceptos que representan
clases dentro del contexto del problema. Hay que
aplicar criterios para identificar clases incorrectas o
innecesarias.
• Identificar las relaciones o asociaciones entre clases.
Hay que aplicar criterios para saber si las asociaciones
son o no correctas.
• Realizar el Diagrama de Clases sin niveles de detalle.
Representar las relaciones entre clases incluyendo los
roles (breve descripción de su objetivo) y la multiplicidad
(número de elementos involucrados en la relación).
Programación II

11. Análisis Orientado a Objetos
Criterios para identificar clases
incorrectas o innecesarias:
• Clases redundantes: cuando dos clases expresan la
misma información; se debe tomar el nombre más
descriptivo. Ejemplo:
cliente / pasajero – persona que va a tomar un vuelo
cliente / usuario – ATM o cualquier servicio bancario
Programación II

12. Análisis Orientado a Objetos
• Clases irrelevantes: cuando una clase tiene poco o
nada que ver con el problema. La posible clase a
eliminar puede ser importante en otro contexto.
Ejemplo:
reservación – cuando el contexto es la ocupación del
teatro
venta – cuando el contexto es administrativo /
financiero
Programación II

13. Análisis Orientado a Objetos
• Clases vagas: cuando una clase no es específica, no
tiene sus límites bien definidos con claridad o su
alcance es muy amplio. Ejemplo:
sistema / universo / horizonte
• Clases o atributos: Nombres que describen objetos
individua-les pueden ser considerados como atributos
de una clase. Si fuese importante la existencia de una
propiedad independiente, entonces hacer de ésta una
clase y no un atributo. Ejemplo:
nombre / edad / peso / dirección – estudiante
dirección – sistema de correo
Programación II

14. Análisis Orientado a Objetos
• Clase u operación: si un nombre describe una
operación que es aplicada a objetos, no es una clase.
Una operación que tiene características propias debe
ser modelada como una clase. Ejemplo:
llamada telefónica – contexto del problema es el
teléfono
llamada telefónica – sistema de facturación
• Clase o asociación: el nombre de una clase debe
reflejar su naturaleza intrínseca y no un role que ésta
juega en una asociación. Ejemplo:
propietario no es una clase – producción de carros
Programación II

15. Análisis Orientado a Objetos
• Uso de implementaciones: Implementaciones
externas al mundo real no se deben agregar en el
análisis. Probablemente se requieran en el diseño. Está
basado en la reutilización de elementos. Ejemplo:
CPU / subrutina / proceso / algoritmo / interrupción /
lista enlazada / arreglo / árbol / conjunto / tabla /
elementos de interfaz
Programación II

16. Análisis Orientado a Objetos
Criterios para no tomar en cuenta
asociaciones incorrectas o innecesarias:
• Asociaciones entre clases eliminadas: si una de las
clases de la asociación ha sido eliminada, la
asociación debe ser eliminada o redefinida en términos
de otra clase.
Programación II

17. Análisis Orientado a Objetos
• Asociaciones irrelevantes o de implementaciones:
eliminar toda asociación que está fuera del dominio del
problema o tenga que ver con el uso de
implementaciones. Ejemplo:
“Banco mantiene ATM” es irrelevante cuando el
contexto del problema es el servicio que el banco
presta a sus clientes
“ATM tiene impresora” tiene que ver con
implementación
Programación II

18. Análisis Orientado a Objetos
• Acciones: una asociación debe describir una propiedad
estructural del dominio de la aplicación, no un evento. Un
requerimiento expresado como una acción puede
implicar una relación estructural y debe ser reescrito
acordemente. Ejemplo:
“ATM acepta tarjetas de débito” describe parte de un
ciclo de interacción entre ATM y Cliente, no una
relación entre ATM y tarjeta de débito.
“Computador central transfiere transacción con banco”
describe una acción que implica la siguiente relación:
“Computador central se comunica con el banco”.
Programación II

19. Análisis Orientado a Objetos
• Asociaciones ternarias: muchas asociaciones entre 3
o más clases se pueden descomponer en asociaciones
binarias o rescritas como asociaciones calificadas. Si un
término en una asociación ternaria es puramente
descriptivo y no tiene características propias, el término
es un atributo enlace en una asociación binaria.
Ejemplo:
“Cajeros introducen transacciones de cuentas” se
puede romper en “Cajeros introducen transacciones” y
“transacciones tienen que ver con cuentas”.
“La compañía emplea personas con un sueldo”
Programación II

20. Análisis Orientado a Objetos
• Asociaciones derivadas: asociaciones que pueden ser
definidas en términos de otras asociaciones deben ser
omitidas ya que son redundantes. También hay que
omitir asociaciones definidas por condiciones en los
atributos. Ejemplo:
“Abuelo de” puede ser definido usando un par de
relaciones “Padre de”
“Más joven que” expresa una condición en la edad de
dos personas, no es información adicional.
Programación II

21. Análisis Orientado a Objetos
NOTA: tanto como sea posible, las clases, los atributos
y las asociaciones deben representar información
independiente. Muchos caminos entre clases a veces
indican asociaciones derivadas que están compuestas
por asociaciones primitivas. Ejemplo:
“Consorcio comparte ATM” es una composición de
“Consorcio tiene computador central” y “computador
central se comunica con los ATM”
Programación II

22. Análisis Orientado a Objetos
NOTA: Hay que tener cuidado porque no todas las
asociaciones que forman múltiples caminos entre clases
indican redundancia. Algunas veces la existencia de
una asociación puede ser derivada de dos o más
asociaciones primitivas. Aunque las asociaciones
derivadas no agregan información, son útiles para el
diseño.
Programación II

23. Análisis Orientado a Objetos
Ejemplo:
Una compañía emplea a muchas personas y es
propietaria de muchas computadoras; a cada empleado
se le puede asignar alguna de estas computadoras para
su uso personal.
persona y empleado son conceptos redundantes
Compañía 1 * Empleado
emplea
1 1
posee asignada
* Computadora 0,1
Programación II

24. Análisis Orientado a Objetos
Ejercicio – enunciado del problema:
Una red bancaria computarizada incluye tanto cajeros humanos como
automáticos (ATM), éstos últimos compartidos por un consorcio de
bancos. Cada banco provee su propia computadora para mantener
sus propias cuentas y procesar las transacciones contra ellas. Las
estaciones de los cajeros son propias de cada banco y se comunican
directamente con la computadora propia del banco. Los cajeros
humanos introducen datos de cuentas y transacción. Los ATM se
comunican con un computador central el cual transfiere las
transacciones con los bancos apropiados. Un ATM acepta una tarjeta
de débito, interactúa con el usuario, se comunica con el sistema
central para llevar a cabo la transacción, dispensa efectivo e imprime
un recibo. El sistema requiere de mecanismos de seguridad y
auditoria adecuados. El sistema puede manejar acceso concurrente a
la misma cuenta. Los bancos proveen su propio software para sus
propias computadoras. El costo del sistema compartido es distribuido
por los bancos según el número de clientes con tarjetas de débito.
Programación II

25. Análisis Orientado a Objetos
Ejercicio – identificación de nombres / conceptos:
Una red bancaria computarizada incluye tanto cajeros humanos como
automáticos (ATM), éstos últimos compartidos por un consorcio de
bancos. Cada banco provee su propia computadora para mantener
sus propias cuentas y procesar las transacciones contra ellas. Las
estaciones de los cajeros son propias de cada banco y se comunican
directamente con la computadora propia del banco. Los cajeros
humanos introducen datos de cuentas y transacción. Los ATM se
comunican con un computador central el cual transfiere las
transacciones con los bancos apropiados. Un ATM acepta una tarjeta
de débito, interactúa con el usuario, se comunica con el sistema
central para llevar a cabo la transacción, dispensa efectivo e imprime
un recibo. El sistema requiere de mecanismos de seguridad y
auditoria adecuados. El sistema puede manejar acceso concurrente a
la misma cuenta. Los bancos proveen su propio software para sus
propias computadoras. El costo del sistema compartido es distribuido
por los bancos según el número de clientes con tarjetas de débito
Programación II

26. Análisis Orientado a Objetos
Ejercicio – aplicar criterios:
Nombres: red bancaria, cajero, ATM, consorcio, banco,
computadora-banco, cuenta, transacción, estación-
cajero, datos-cuenta, datos-transacción, computador-
central, tarjeta-débito, usuario, sistema, efectivo,
recibo, mecanismos-seguridad, mecanismos-
auditoria, acceso, software, costo, cliente
Programación II

27. Análisis Orientado a Objetos
Ejercicio – aplicar criterios:
Vagas: sistema, mecanismos-seguridad, mecanismos-
auditoria, red-bancaria
Atributos: datos-cuenta, datos-transacción, recibo, efectivo
Irrelevante: costo
Redundante: usuario
Implementaciones: acceso, software
Definitivos: cuenta, ATM, banco, computadora-banco, tarjeta-
débito, cajero, estación-cajero, computador-
central
Programación II

28. Análisis Orientado a Objetos
Ejercicio – posible diagrama de clases preliminar:
Programación II

29. Análisis Orientado a Objetos
Ejercicio – posible diagrama de clases definitivo:
Programación II