Programación Orientada a Objetos

Inicio

Generalidades

Ejercicios

Talleres

Proyecto

 Análisis & Diseño Orientado a Objetos

Requerimientos: Los requerimientos para un sistema de software determinan lo que hará el sistema y definen las restricciones de su operación e implementación.  Existen requerimientos del usuario y del sistema.   Los documentos de requerimientos de software son la declaración acordada de los requerimientos del sistema. Se estructuran de tal forma que puedan ser utilizados tanto por los clientes del sistema como por los desarrolladores del software. 

  Roger Pressman escribió un prólogo sobre las prácticas efectivas en los requisitos: "Es tu peor pesadilla. Un cliente entra en tu oficina, se sienta, te mira directo a los ojos, y dice: "Yo sé que usted piensa que entiende lo que digo, pero lo que usted no entiende es que lo que digo no es realmente lo que quiero decir".

Esto sucede de manera invariable cuando el proyecto está avanzado, después de que se han realizado los compromisos relativos al tiempo de entrega, las reputaciones están en juego y el dinero está en serio peligro.

Todos los que hemos trabajado en el negocio de los sistemas y el software por más de unos cuantos años hemos vivido esta pesadilla, y sólo unos pocos de nosotros hemos aprendido a continuar aún con esta circunstancia. Nosotros tenemos dificultades al comprender la información que adquirimos. Con frecuencia registramos los requisitos de una manera desorganizada e invertimos muy poco tiempo en verificar lo que registramos. Permitimos que el cambio nos controle en lugar de establecer mecanismos para controlarlo.

En resumen, fallamos al establecer un cimiento sólido para el sistema o software. Cada uno de estos problemas representan un reto. Cuando estos se combinan, la imagen es desalentadora, incluso para los gerentes y profesionales del software más experimentados, pero existen soluciones".

  Los requerimientos del usuario deberían redactarse en lenguaje natural debido a que tienen que ser comprendidos por personas que no son técnicos expertos. Sin embargo, pueden expresarse requerimientos del sistema más detallados de forma más técnica. Una técnica ampliamente usada es documentar la especificación del sistema como un conjunto de modelos del sistema. Estos modelos son representaciones gráficas que describen los procesos del negocio, el problema a resolver y el sistema que tiene que ser desarrollado. Debido a las representaciones gráficas usadas, los modelos son a menudo más comprensibles que las descripciones detalladas en lenguaje natural de los requerimientos del sistema. Ellos constituyen también un puente importante entre el proceso de Análisis y Diseño. Los Casos de Uso son utilizados para la captura de requisitos.

  Puede descargar aquí una presentación sobre  Casos de Uso

 Un modelo es una vista abstracta de un sistema que ignora algunos detalles de dicho sistema. Se pueden desarrollar modelos de sistemas complementarios que presentan diferente información de éste.

  Los modelos de objetos describen las entidades lógicas del sistema y su clasificación y agregación. Combinan un modelo de datos con uno de procesos. Los posibles modelos de Objetos que se pueden desarrollar incluyen modelos de herencia, de agregación y de comportamiento.

 Los bancos de trabajo CASE ayudan al desarrollo de modelos del sistema proporcionándoles herramientas de edición, verificación, emisión de informes y de documentación.  Los siguientes son algunos productos CASE, unos de software propietario y otros de distribución libre:

 Poseidón, ArgoUML, Eclipse, Power-Designer, Rational Rose, Netbeans, Umbrello, Together, Visual Paradigm, Dia, IBM Rational XDE Modeler,   Objecteering, gModeler, MonoUML, Bulma (UML en Linux)...
 

  El diseño orientado a objetos es un medio para diseñar software de tal forma que los componentes del diseño representen objetos con su estado y operaciones privadas propias en lugar de funciones. Los objetos se implementan de manera secuencial o concurrente. Un objeto concurrente puede ser un objeto pasivo cuyo estado sólo se cambia a través de su interfaz o un objeto activo que cambia su propio estado sin intervención externa.

 UML se diseñó para suministrar un conjunto de notaciones diversas que se utilizan para documentar un diseño orientado a objetos. El proceso de un DOO incluye actividades para diseñar la arquitectura del sistema, identificar los objetos en el sistema, describir el diseño utilizando diversos modelos de objetos y documentar las interfaces de objetos.

(Contratos en UML)

http://iie.fing.edu.uy/ense/asign/desasoft/Teorico2/Contratos.pdf
http://www.uvmsf.cl/~lcastillo/media/Clase6MAD.pdf
http://www.elguille.info/colabora/puntoNET/canchala_UML.htm

 Durante un proceso de DOO se produce una gran variedad de modelos, entre los que se encuentran los modelos estáticos (modelos de clases, de generalización, de asociación) y dinámicos (modelos de secuencia y de máquina de estado). Las interfaces de objetos deben definirse de forma precisa para que puedan ser utilizadas por otros objetos (reutilización). Una ventaja importante del DOO es que simplifica la evolución del sistema. Para documentar las interfaces de objetos se utiliza un lenguaje de programación como Java.

 El proceso de diseño de interfaces se centra en el usuario. Una interfaz interacciona con el usuario en sus términos, es lógica y consistente, e incluye recursos para ayudar a los usuarios con el sistema y poder recuperarse de los errores. Los estilos de interacción con un sistema de software incluyen la manipulación directa, los sistemas de menús, llenado de formularios, lenguajes de comandos y lenguaje natural.

 El despliegue gráfico de la información se utiliza cuando se pretenden presentar tendencias y aproximar valores. El despliegue digital sólo se utiliza cuando se requiere precisión. El color se utiliza moderada y consistentemente en las interfaces de usuario. Los diseñadores deben tener en cuenta el hecho de que muchas personas no detectan los colores adecuadamente.

 Los mensajes de error no deben hacer sentir culpable al usuario. Deben ofrecer sugerencias de cómo reparar el error y proveer un vínculo al sistema de ayuda. La documentación del usuario incluye manuales de principiantes y de referencia. Los documentos para los administradores del sistema se proveen de forma separada.

Ejercicios "amistosos"

1. Represente un  diagrama de casos de uso  para un distribuidor de pasajes (boletos o tiquetes) de un sistema de trenes. El sistema incluye dos actores: un viajero que compra diferentes tipos de pasajes y un sistema de computadora central que mantiene una base de datos de referencia para las tarifas. Los casos de uso deben incluir: ComprarBoletoSencillo, ComprarTarjetaSemanal, ComprarTarjetaMensual y ActualizarTarifa. También hay que incluir los siguientes casos excepcionales: Retraso (es decir, el viajero tarda demasiado para insertar el importe correcto), TransacciónAbortada (es decir, el viajero selecciona el botón de cancelar sin terminar la transacción), DistribuidorSinCambio y DistribuidorSinPapel.

2. Elabore un diagrama parcial de casos de uso para un sistema de biblioteca. Incluir tres actores y cuatro casos de uso.

3. Represente un diagrama de clases para un libro definido por la siguiente declaración: "un libro está compuesto por varias partes que a su vez están compuestas de varios capítulos. Los capítulos están compuestos de secciones". Enfóquese sólo en las clases y sus relaciones.

4. Amplíe el diagrama de clases del ejercicio anterior para que incluya los siguientes atributos: <> un libro incluye a un editor, fecha de publicación y un ISBN. <> Una parte incluye un título y un número. <> Un capítulo incluye un título, un número y un resumen. <> Una sección incluye un título y un número.

5. Describa y justifique los objetos que obtiene de cada uno de estos casos: a) Los habitantes de Colombia y sus direcciones de correo.  b) Los clientes de un banco que tienen una caja fuerte alquilada.  c) Las direcciones de correo electrónico de Coruniversitaria.  d) Los empleados de la Fiscalía y sus claves de acceso a sistemas de seguridad.

6. ¿Cuáles serían los objetos que han de considerarse en los siguientes sistemas?:  a) Un programa para maquetar una revista.  b) Un contestador telefónico.  c) Un sistema de control de ascensores.  d) Sistema de suscripción  al periódico 'Tolima 7dias'.

7. Dibujar un diagrama de objetos que represente la estructura de un carro. Indicar las posibles relaciones de asociación, generalización y agregación.