Uploaded on

Tecnología Orientada a Objetos - UNEG - Profesor Mauricio Paletta …

Tecnología Orientada a Objetos - UNEG - Profesor Mauricio Paletta

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
828
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
18
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Presentación Análisis Orientado a Objetos Ing. Mauricio Paletta, Msc INGENIERÍA EN INFORMÁTICA Programación IIUNIVERSIDAD 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 ObjetosNOTA: tanto como sea posible, las clases, los atributosy las asociaciones deben representar informaciónindependiente. Muchos caminos entre clases a vecesindican asociaciones derivadas que están compuestaspor 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 ObjetosNOTA: Hay que tener cuidado porque no todas lasasociaciones que forman múltiples caminos entre clasesindican redundancia. Algunas veces la existencia deuna asociación puede ser derivada de dos o másasociaciones primitivas. Aunque las asociacionesderivadas no agregan información, son útiles para eldiseñ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