Laboratorio 1 De Progiii

UNIVERSIDAD DE PANAMÁ CENTRO REGIONAL UNIVERSITARIO DE VERAGUAS FACUTAD DE INFORMÁTICA, ELECTRÓNICA Y COMUNICACIÓN ESCUELA: INGENIERÍA EN INFORMÁTICA CARRERA DE LICENCIATURA EN INGENIERÍA DE INFORMÁTICA

LABORATORIO # 1

PROGRAMACIÓN III PRORAMACIÓN ORIENTADA A OBJETOS

TEMA: GUÍA DEL ANÁLISIS DE LA ORIENTACIÓN A OBJETOS

PROFESOR: DIEGO SANTIMATEO

PRESENTADO POR LA ESTUDIANTE: EUFEMIA BUITRAGO 2-719-2461

III AÑO

FECHA DE ENTREGA: LUNES, 01 DE SEPTIEMBRE DE 2008.

ÍNDICE

I.

INTRODUCCIÓN.......................................................................................

i

II.

CONTENIDO..............................................................................................

ii

a) Guía del Análisis de la Orientación a Objetos............................

1

b) Ejemplo Ilustrativo......................................................................

3

III.

CONCLUSIÓN...........................................................................................

iii

IV.

WEBGRAFÍA..............................................................................................

iv

INTRODUCCIÓN

El propósito de este trabajo consiste en realizar el análisis orientado a objetos el cual es un método de análisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema. El mismo ha sido estructurado basándose en las explicaciones de las separatas facilitadas por el profesor en las clases junto con conocimientos adquiridos en la búsqueda de información referente al tema en la web.

Con este trabajo adquirirá una base para manejarse por las tecnologías y metodologías orientadas a objetos que dominan actualmente la ingeniería de software. A la ves a través de la guía presentada del análisis orientado a objetos conocerá los pasos que se deben seguir para llegar al modelo del dominio orientado a objetos, junto a la identificación y descripción de cada elemento necesario.

El mismo presenta junto a la guía un ejemplo basado en el tema para facilitar su comprensión.

GUÍA DEL ANÁLISIS DE LA ORIENTACIÓN A OBJETOS

Para lograr con éxito un Análisis Orientado a Objetos, se deben seguir los pasos detallados a continuación:

V.

Planteamiento del Problema: es lo que se desea hacer.

VI.

Dominio del Problema: es el campo o área donde está el Problema.

VII.

Análisis del Problema: es la definición o descripción del Problema.

a) Análisis de Requisitos: es donde se descubren los requisitos que el sistema debe cumplir para satisfacer las necesidades de clientes y usuarios.

b) Lista de Requisitos: reflejan lo que el sistema debe hacer pero no como debe hacerlo.

VIII.

Análisis Orientado a Objetos: describe el dominio del problema mediante clases y objetos basándose en los requisitos, la descripción del problema, el conocimiento de los expertos en el dominio del problema y el conocimiento general sobre el mundo real.

a) Diagramas de Clases: presentan de forma estática las clases del dominio y sus relaciones.

Para identificar las clases suelen utilizarse dos técnicas:

1. La identificación de sustantivos: extrae los sustantivos encontrados en la descripción del problema y considera que corresponden a clases candidatas.

Dada una lista de sustantivos o clases candidatas, deben aplicarse algunas reglas de eliminación como:

a.1. Redundancia: si existen varios sustantivos que se refieren a la misma entidad, se debe elegir el más representativo.

a.2. Atributo: son los sustantivos que describen la estructura de las clases.

a.3. Irrelevancia: son los sustantivos que no tienen relación con el dominio. Debe evitarse la introducción de clases no asociadas a los conceptos del dominio bajo estudio.

a.4. Acción: son aquellos sustantivos que no originan clases.

a.5. Estado: los sustantivos que describen el estado de una entidad no corresponden a clases. a.6. Frecuencia Temporal: son aquellos sustantivos que describen frecuencias de tiempo (no corresponden a clases).

a.7. Entidad de Hardware o de Software: son aquellos sustantivos que describen entidades de hardware o de software (no generan clases), excepto si modela un sistema de hardware o de software.

2. La comparación con una lista de categorías de clases: determina las clases candidatas de un dominio basándose

en una lista de categorías de clases. Se realiza a través de las frases verbales presentes en la descripción del problema y de nuestro conocimiento de éste. Las relaciones pueden aparecer explícitas o implícitas.

i. Atributos de los Objetos: son las propiedades o características de dicho objeto.

ii. Operaciones de los Objetos: eventos que realiza el objeto.

b) Diagramas de Objetos: muestran las interacciones entre los objetos.

IX.

Modelo de Dominio Orientado a Objetos: se expresa en el lenguaje del cliente y el usuario, no depende de ningún entorno informático y no considera las restricciones de implementación.

Ejemplo, Planteamiento del Problema:

El Banco de una pequeña ciudad propone a un experto en el tema la creación de un sistema informático para controlar las transacciones realizadas en dicha institución, donde cada transacción tendrá un código único; junto con los depósitos hechos por los clientes para saldar dicha transacción. Los clientes del banco con una permanencia laboral de un mínimo de dos años pueden solicitar un préstamo de hasta B/.20,000.00 con una taza de interés anual del 2% por un período de hasta 10 años para cancelar la deuda y no pueden refinanciar dicho préstamo en menos de 8 años teniendo sus pagos al día. Los colaboradores del banco pueden sacar hasta B/.25,000.00 con una taza de interés anual del 1.5% por un período de 10 años pudiendo refinanciar en 7 años. El sistema debe ser económico y debe poder ejecutarse en un Pentium IV.

Diagrama del Modelo de Dominio del Banco Cliente_Banco B/.20,000.00

Cantidad de Dinero 8 años 2% Tiempo de Refinanciamient o

Es interés de B/.25,000.00

7

años Interés Anual 1.5% Colaborador_Ban

En este caso, el Dominio es el Banco y los experto en el dominio los colaboradores del mismo. Tras hablar con ellos averigüé que el sistema debe registrar los prestamos y cantidad a abonar quincenalmente junto con el tiempo en el que debe cancelar dicha deuda. La sanción consiste en que, si el socio o colaborador del banco no abona la cantidad debida quincenalmente, se le castiga retrasándole en el tiempo prudente el refinanciamiento del préstamo en el tiempo estipulado. También descubrí que los abonos realizados a cada préstamo tienen códigos correlativos y que para que al aprobarse un préstamo el cliente debe llevar al banco tres fotos actuales(no copias), talonario de la empresa donde labora y rellenar una certificación con los datos personales(nombre, apellido, dirección y teléfono); en dicha certificación figura un número de socio único. Que el sistema sea económico y que se pueda ejecutar en un Pentium IV es un requisito de implementación, fuera del análisis orientado a objetos. Tras el estudio de la descripción del problema, la aplicación de una de las dos técnicas de identificación de clases y la aplicación de las reglas de eliminación de clases candidatas, extraje clases como cliente_banco, colaborador_banco, cant_dinero, interés_a_pagar. Se pueden conservar las clases candidatas sanción y préstamo; consideremos que la información que contienen se encuentra en cliente_banco e interés_a_pagar. Cada clase tiene sus correspondientes atributos, ejemplo; los atributos de cliente_banco son talonario, nombre, dirección, teléfono y numero_cliente. Las relaciones entre esas clases las obtuve a partir de los siguientes hechos extraídos de la descripción y de nuestro conocimiento sobre bancos: 1. Los préstamos tienen un interés anual. 2. Los clientes del banco solicitan una cantidad de dinero prestada.

3. Los clientes del banco hacen depósitos quincenales a dicho préstamo. 4.

Los colaboradores del banco solicitan una cantidad de dinero prestada con una menor taza de interés anual.

5. Los colaboradores hacen depósitos quincenales a dicho préstamo.

CONCLUSIÓN

La programación orientada a objetos se apoya firmemente en el análisis y diseño orientado a objetos, lo cual dificulta en gran manera la comprensión de dicho tema, conclusión a la que llegue durante la realización de dicho trabajo.

Con el mismo aprendí a identificar los elementos que se deben tomar en cuenta a la hora de la realización de un modelo de dominio orientado a objetos junto con la descripción del mismo.

WEBGRAFÍA

6. http://www.di.uniovi.es/~cernuda/pfc/aoo.pdf 7. http://www.inf.utfsm.cl/~hernan/cursos/ILI2362004s2/bitacora/05-Asocs+Atribs+Contratos_6pp.pdf