Analisis

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.


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.


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:


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


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”


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.


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.


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).


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


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


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


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


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


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.


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


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”.


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”


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.


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”


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.


Programación II

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.

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.


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


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


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


Programación II

Ejercicio – posible diagrama de clases preliminar:


Programación II

Ejercicio – posible diagrama de clases definitivo:


Analisis

Documents

Transcript of Analisis