analisis
Post on 03-Nov-2014
9 Views
Preview:
DESCRIPTION
TRANSCRIPT
Programación II
Ing. Mauricio Paletta, Msc
Análisis Orientado a Objetos
Presentación
UNIVERSIDAD NACIONAL EXPERIMENTAL DE GUAYANA
INGENIERÍA EN INFORMÁTICA
Programación II
Programación II
• 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.
Análisis Orientado a Objetos
Programación II
• 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.
Análisis Orientado a Objetos
Programación II
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:
Análisis Orientado a Objetos
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
Análisis Orientado a Objetos
Programación II
Análisis Orientado a Objetos
Programación II
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”
Análisis Orientado a Objetos
Programación II
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.
Análisis Orientado a Objetos
Programación II
• 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.
Análisis Orientado a Objetos
Programación II
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).
Análisis Orientado a Objetos
Programación II
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
Análisis Orientado a Objetos
Programación II
• 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
Análisis Orientado a Objetos
Programación II
• 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
Análisis Orientado a Objetos
Programación II
• 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
Análisis Orientado a Objetos
Programación II
• 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
Análisis Orientado a Objetos
Programación II
• 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.
Análisis Orientado a Objetos
Criterios para no tomar en cuenta
asociaciones incorrectas o innecesarias:
Programación II
• 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
Análisis Orientado a Objetos
Programación II
• 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”.
Análisis Orientado a Objetos
Programación II
• 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”
Análisis Orientado a Objetos
Programación II
• 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.
Análisis Orientado a Objetos
Programación II
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”
Análisis Orientado a Objetos
Programación II
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.
Análisis Orientado a Objetos
Programación II
Ejemplo:
Análisis Orientado a Objetos
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.
Compañía
Computadora*
1
posee
Empleado*1
emplea
asignada
1
0,1
persona y empleado son conceptos redundantes
Programación II
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.
Análisis Orientado a Objetos
Programación II
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
Análisis Orientado a Objetos
Programación II
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
Análisis Orientado a Objetos
Programación II
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
Análisis Orientado a Objetos
Programación II
Ejercicio – posible diagrama de clases preliminar:
Análisis Orientado a Objetos
Programación II
Ejercicio – posible diagrama de clases definitivo:
Análisis Orientado a Objetos
top related