lunes, 12 de octubre de 2009

LIMPIEZA DE UN CUARTO DE HOTEL



DIAGRAMA DE CASOS DE USO
* El huesped entrega la llave en la recepcion.
* La persona de limpieza toma la llave de la recepcion.
* La persona de limpieza limpia el cuarto y entrega la llave.
* El huesped recoje la llave.


DIAGRAMA DE CLASES


CONTROL DE ACCESO A UN CUARTO DE HOTEL


DIAGRAMA DE CASOS DE USO


* El huesped introduce tarjeta.

* El controlador comprueba si la tarjeta es la correcta.

* El controlador abre la puerta.

* El controlador detecta la fecha y hora de entrada y de salida.

* El huesped retira tarjeta.





DIAGRAMA DE CLASES


jueves, 8 de octubre de 2009

DIAGRAMAS DE UNA GASOLINERA

En este ejercicio haremos los diagramas de casos de uso y de clases para una gasolinera con el programa "argoUML".


Para comenzar necesitamos saber cuales son las restricciones del problema:

* Despachar
* Cobrar
* Dar servicio
* Venta de aditivos

Entonces el diagrama de casos de uso queda asi:




El esenario seria este:

1.- El cliente llega y pide la gasolina.
2.- El encargado despecha la gasolina y ofrece aditivos.
3.- El encargado cobra.
4.- el cliente paga.

El diagrama de clases queda asi:


miércoles, 7 de octubre de 2009

CONTROL DE UNA ALARMA

Los primeros diagramas son sobre el control de una alarma de automovil, para esto usaremos el programa ARGOUML.
Primero tenemos que saber que es lo que va a hacer y los requerimientos del programa:


Activar o desactivar la alarma.
Poner o quitar los seguros.
Abrir la cajuela.



Requerimientos:

Botón 1: Activa la alarma:
*Presionar una ves el botón pone los seguros.
*Presionar dos veces el botón activa alarma.

Botón 2: Desactiva la alarma:
*Presionar una ves el botón quita la alarma, levanta los seguros.
*Presionar dos veces el botón abre las puertas.

Botón 3: Abre la cajuela.




DIAGRAMA DE CASOS DE USO



DIAGRAMA DE CLASES

1.- El usuario presiona un botón.

2.- Depende del botón presionado la alrma se activa o se desactiva.



martes, 8 de septiembre de 2009

Beneficios del modelo de objetos y de la POO sobre otros paradigmas

En resumen, la programación orientada a objetos beneficia a los desarrolladores debido a que:
Los programas son fáciles de diseñar debido a que los objetos reflejan elementos del mundo real.
Las aplicaciones son más sencillas para los usuarios debido a que los datos innecesarios están ocultos.
Los objetos son unidades autocontenidas.
La productividad se incrementa debido a que puede reutilizar el código.
Los sistemas son fáciles de mantener y se adaptan a las cambiantes necesidades de negocios.
Es más fácil crear nuevos tipos de objetos a partir de los ya existentes.
Simplifica los datos complejos.
Reduce la complejidad de la transacción.
Confiabilidad.
Robustez.
Capacidad de ampliación.

Historia de los paradigmas en el desarrollo del software

Paradigmas: Representan un enfoque particular o filosofía para la construcción del software. No es mejor uno que otro sino que cada uno tiene ventajas y desventajas.
También hay situaciones donde un paradigma resulta más apropiado que otro.
Los más comunes son el desarrollo en cascada, el desarrollo en espira’‘, el desarrollo por prototipos, el desarrollo incremental, el desarrollo en V y el desarrollo orientado a objetos. También existen modelo híbridos, los cuales combinan elementos de diferentes modelos según las necesidades existentes.
En Ingeniería de software el desarrollo en cascada es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. Un ejemplo de una metodología de desarrollo en cascada es:  Análisis de requisitos  Diseño  Programación  Prueba  Implantación  Mantenimiento De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto. Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy Para cada actividad habrá cuatro tareas. Imagen:
Modelo Espiral.JPG Determinar o fijar objetivos Fijar también los productos definidos a obtener: requerimientos, especificacion, manual de usuario. Fijar las restricciones. Identificación de riesgos del proyecto y estrategias alternativas para evitarlos. Hay una cosa que solo se hace una vez: planificacion inicial o previa.
Análisis del riesgo Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos. Desarrollar, verificar y validar (probar) Tareas de la actividad propia y se prueba. Planificar Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la proxima actividad. Ventajas El analisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos. Inconvenientes Genera mucho trabajo adicional. Exige una cierta habilidad en los analistas

Elementos primordiales en el modelo de objetos

La programación Orientada a Objetos trata de cumplir las necesidades de los usuarios finales, estás tareas se realizan mediante la modelización del mundo real, el sopote fundamental es el modelo objeto.

Los elementos más importantes de este modelo son:

Abstracción
La abstracción, un principio por el cual se aísla toda aquella información que no resulta relevante a un determinado nivel de conocimiento.

Encapsulamiento
En programación modular, y más específicamente en programación orientada a objetos, se denomina encapsulamiento al ocultamiento del estado, es decir, de los datos miembro, de un objeto de manera que sólo se puede cambiar mediante las operaciones definidas para ese objeto.

Cada objeto está aislado del exterior, es un módulo natural, y la aplicación entera se reduce a un agregado o rompecabezas de objetos. El aislamiento protege a los datos asociados a un objeto contra su modificación por quien no tenga derecho a acceder a ellos, eliminando efectos secundarios e interacciones.
De esta forma el usuario de la clase puede obviar la implementación de los métodos y propiedades para concentrarse sólo en cómo usarlos. Por otro lado se evita que el usuario pueda cambiar su estado de maneras imprevistas e incontroladas.

Modularidad
La modularidad es la capacidad que tiene un sistema de ser estudiado, visto o entendido como la unión de varias partes que interactúan entre sí y que trabajan para alcanzar un objetivo común, realizando cada una de ellas una tarea necesaria para la consecución de dicho objetivo. Cada una de esas partes en que se encuentre dividido el sistema recibe el nombre de módulo. Idealmente un módulo debe poder cumplir las condiciones de caja negra, es decir, ser independiente del resto de los módulos y comunicarse con ellos (con todos o sólo con una parte) a través de unas entradas y salidas bien definidas.

Jerarquia y Herencia
La Jerarquía es una propiedad que permite la ordenación de las abstracciones. Las dos jerarquías más importantes de un sistema complejo son: estructura de clases (jerarquía “es-un” (is-a): generalización/especialización) y estructura de objetos (jerarquía “parte-de” (part-of): agregación).
Las jerarquías de generalización/especialización se conocen como herencia. Básicamente, la herencia define una relación entre clases, en donde una clase comparte la estructura o comportamiento definido en una o más clases (herencia simple y herencia múltiple, respectivamente).
La agregación es el concepto que permite el agrupamiento físico de estructuras relacionadas lógicamente. Así, un camión se compone de ruedas, motor, sistema de transmisión y chasis; en consecuencia, camión es una agregación, y ruedas, motor, transmisión y chasis son agregados de camión.
stefanycuevas

Polimorfismo
La quinta propiedad significativa de los lenguajes de programación orientados a objetos es el polimorfismo. Es la propiedad que indica, literalmente, la posibilidad de que una entidad tome muchas formas. En términos prácticos, el polimorfismo permite referirse a objetos de clases diferentes mediante el mismo elemento de programa y realizar la misma operación de diferentes formas, según sea el objeto que se referencia en ese momento.
Por ejemplo, cuando se describe la clase mamíferos se puede observar que la operación comer es una operación fundamental en la vida de los mamíferos, de modo que cada tipo de mamífero debe poder realizar la operación o función comer. Por otra parte, una cabra o una vaca que pastan en un campo, un niño que se come un caramelo y un león que devora a otro animal, son diferentes formas que utilizan diferentes mamíferos para realizar la misma función (comer).
El polimorfismo adquiere su máxima expresión en la derivación o extensión de clases, es decir, cuando se obtiene una clase a partir de una clase ya existente, mediante la propiedad de derivación de clases o herencia.
El polimorfismo requiere ligadura tardía o postergada (también llamada dinámica), y esto sólo se puede producir en lenguajes de programación orientados a objetos. Los lenguajes no orientados a objetos soportan ligadura temprana o anterior (también llamada estática), esto significa que el compilador genera una llamada a un nombre específico de función y el enlazador (linker) resuelve la llamada a la dirección absoluta del código que se ha de ejecutar. En POO, el programa no puede determinar la dirección del código hasta el momento de la ejecución. Cuando se envía un mensaje a un objeto, el código que se llama no se determina hasta el momento de la ejecución. El compilador asegura que la función existe y realiza verificación de tipos de los argumentos y del valor de retorno, pero no conoce el código exacto a ejecutar.
stefanycuevas