lunes, 23 de agosto de 2010

1. Construir la clase denominada Circulo que permita
a. Definir el centro y el radio
b. Calcular su area
c. Calcular la longitud de la circunferencia
d. Un metodo que muestre todos los atributos del objeto

Esta clase debe heredar de la clase punto para definir su centro

2. Construir la clase Cilindo que herede de la clase Circulo que permita:
a. Calcular su volumen
b. Un metodo que muestre todos los atributos del objeto

3. Construir la clase Cono que herede de la clase
Circulo que permita

a. Calcular su volumen V = 1/3(Area*h)
b. Calcular su area total At = Pi*r(g+r)
c. Un metodo que muestre todos los atributos del objeto

El area debe ser un atributo heredado y g es la
hipotenusa que forma h y r del cono

4. Estas clases deben ser construidas en lenguaje JAVA
y los datos de los objetos deben ser ingresados
por el usuario.

Mentalidad para solucionar y pensar en orientación a objetos.
Se debe usar la herencia y aplicar conceptos de programación orientada a objetos.

Para las dos horas de Clase:
3. Modelamiento del negocio (modelo de dominio y procesos)

domingo, 22 de agosto de 2010

Casos de uso


 El banco universal requiere sistematizar la recepción y consignación de cheques al sistema bancario e integrarlo al cajero tradicional que el banco maneja.
El cajero tradicional permite al usuario consultar retirar, ver saldo, consignar y hacer transacción entre cuentas previa inscripción de la cuenta de destino, pago de facturas donaciones a entidades sin ánimo de lucro  cambiar la clave.
 El nuevo cajero debe proveer la funcionalidad al usuario de consignar cheques únicamente de bancos colombianos si el usuario lo solicita el cajero entregara en efectivo el valor del cheque consignado previo  a verificación en el banco del cheque que se consigna
Es necesario tener en cuenta que los clientes del banco tienen descuento especial sobre todas las transacciones Que realicen generalmente es el administrador  del banco quien tiene la autorización para retirar los cheques consignados de la maquina.
Generalmente quien ingresa billetes es el representante de la casa de valores 





    IDENTIFICADOR DE ACTORES
    usuario:
    • CONSULTAR SALDO
    • RETIRAR
    • Consignar
    • Hacer transacciones
    • Pagar facturas
    • Donar
    • Cambiar clave
    Representante de valores:
    • Ingresar Dinero



    No proceso 1
    Nombre: consultar saldo
    El usuario ingresa al sistema(previa verificación) selecciona la opción de consultar su saldo, el cajero le muestra automáticamente el saldo de su cuenta actual

    No proceso 2
    Nombre: Retirar
    El usuario ingresa al sistema(previa verificación) selecciona la opción de realizar un retiro, selecciona un monto(viable) el cajero desembolsa la cantidad solicitada el usuario retira el dinero

    No proceso 3
    Nombre: Realizar transacciones
    El usuario debe registrar la cuenta de destino, registrar los datos de la transacción(se aplica corroboración de datos de cuentas), el cajero realiza la transacción y se termina el proceso


    No proceso 4
    Nombre: Donar
    El usuario ingresa al sistema, selecciona la opción donación, el cajero le pide la cantidad, el usuario digita la cantidad, el cajero descuenta el dinero de la cuenta





    No. Caso de Uso
    NOMBRE CASO DE USO
    01
    Consultar saldo
    ACTORES
    Usuario
    OBJETIVO
    Revisar el saldo actual de el usuario para dicha cuenta
    PRECONDICIONES
    ü  El login y la tarjeta son correctos
    POSCONDICIONES
    ü  el cajero descuenta el valor de la consulta
    ü  el cajero se preparara para otra transaccion
    FLUJO DE EVENTOS
    Actividades del Actor
    1. insertar tarjeta
    3. el usuario digita el login
    6. el usuario selecciona consultar saldo
    Respuesta del Sistema
    2. el cajero pide el login
    4. el cajero verifica el login
    5. el cajero despliega opciones
    7. el cajero muestra el saldo al usuario
    MANEJO DE SITUACIONES EXEPCIONALES
    ü  si el login o la tarjeta son incorrectos el cajero mostrara mensajes de error
    .



    MODELO DEL DOMINIO 

    Diagrama de procesos


    lunes, 9 de agosto de 2010

    TUTORIAL PA SUBIR JOOMLA...

    como primer paso es registrarnos en un servidor de host... en este caso usaremos uno que nos permite crear un subdominio... y alli instalar el joomla para administrar la pagina web.... en este caso ingresamosa la pagina y nos registramos... despues de esto accedemos a nuestra cuenta en freehostia y entramos al panel de control de freehostia como se ve en la imagen



    vamos a manejar subdominios y creamos un subdominio... como se ve en la imagen...

    luego de esto volvemos al panel principal y vamos a  Elefante Free Scripts y alli nos aparece la opcion jooomla damos click....aparece algo asi


    luego en instalar aparece esta ventana
     
    aqui seleccionamos un username y password para el adminitrador de joomla y la apgina a la cual nos la va a instalar en este caso en el subdominio http://rappublica.freehostia.com/
    seleccionamos instalar y no lo instala automaticamente... ahora solo resta arministrarlo para esto usamos nuestro subdominio y terminado en /joomla/administrator para nuestro caso http://rappublica.freehostia.com/joomla/administrator aqui nos sale un panel para ingresar el usuario y la contraseña de administrador que habiamos ingresado posteriormente y asi se nos despliega el panel de control para manejar joomla... comos e ve en la imagen final


    asi lo unico que resta es administrar nuestra pagina.... eso es todo....

    domingo, 8 de agosto de 2010


    CICLO DE VIDA EN CASCADA PURO

    Este modelo de ciclo de vida fue propuesto por Winston Royce en el año 1970. Es un ciclo de vida que admite iteraciones, contrariamente a la creencia de que es un ciclo de vida secuencial como el lineal. Después de cada etapa se realiza una o varias revisiones para comprobar si se puede pasar a la siguiente. Es un modelo rígido, poco flexible, y con muchas restricciones. Aunque fue uno de los primeros, y Una de sus ventajas, además de su planificación sencilla, es la de proveer un producto con un elevado grado de calidad sin necesidad de un personal altamente calificado. Se pueden considerar como inconvenientes: la necesidad de contar con todos los requerimientos (o la mayoría) al comienzo del proyecto, y, si se han cometido errores y no se detectan en la etapa inmediata siguiente, es costoso y difícil volver atrás para realizar la correccion posterior.
    Además, los resultados no los veremos hasta que no estemos en las etapas finales del ciclo, por lo que, cualquier error detectado nos trae retraso y aumenta el costo del desarrollo en funcion del tiempo que insume la correccion de éstos Es un ciclo adecuado para los proyectos en los que se dispone de todos los requerimientos al comienzo, para el desarrollo de un producto con funcionalidades conocidas o para proyectos, que aun siendo muy complejos, se entienden perfectamente desde el principio.
    Se evidencia que es un modelo puramente teórico, ya que el usuario rara vez mantiene los requerimientos iniciales y existen muchas posibilidades de que debamos retomar alguna etapa anterior.


    Ciclo de vida en espiral
    Este ciclo puede considerarse una variación del modelo con prototipado, fue diseñado por Boehm en el año 1988. El modelo se basa en una serie de ciclos repetitivos para ir ganando madurez en el producto final. Toma los beneficios de los ciclos de vida incremental y por prototipos, pero se tiene más en cuenta el concepto de riesgo que aparece debido a las incertidumbres e ignorancias de los requerimientos proporcionados al principio del proyecto o que surgirán durante el desarrollo. A medida que el ciclo se cumple (el avance del espiral), se van obteniendo prototipos sucesivos que van ganando la satisfacción del cliente o usuario.
    A menudo, la fuente de incertidumbres es el propio cliente o usuario, que en la mayoría de las oportunidades no sabe con perfección todas las funcionalidades que debe tener el producto.
    En este modelo hay cuatro actividades que envuelven a las etapas



    Planificación: Relevamiento de requerimientos iniciales o luego de una iteración.
    Análisis de riesgo: De acuerdo con el relevamiento de requerimientos decidimos si continuamos con el desarrollo.
    •Implementación: desarrollamos un prototipo basado en los requerimientos.
    •Evaluación: El cliente evalúa el prototipo, si da su conformidad, termina el proyecto. En caso contrario, incluimos los nuevos requerimientos solicitados por el cliente en la siguiente iteración

    CICLO DE VIDA INCREMENTAL

    Este modelo de ciclo de vida se basa en la filosofía de construir  incrementando las funcionalidades del programa. Se realiza construyendo por módulos que cumplen las diferentes funciones del sistema. Esto permite ir aumentando gradualmente las capacidades del software. Este ciclo de vida facilita la tarea del desarrollo permitiendo a cada miembro del equipo desarrollar un modulo particular en el caso de que el proyecto sea realizado por un equipo de programadores.
    Es una repetición del ciclo de vida en cascada, aplicándose este ciclo en cada funcionalidad del programa a construir. Al final de cada ciclo le entregamos una versión al cliente que contiene una nueva funcionalidad. Este ciclo de vida nos permite realizar una entrega al cliente antes de terminar el proyecto El modelo de ciclo de vida incremental nos genera algunos beneficios tales como los que se describen a continuacion:
    • Construir un sistema pequeño siempre es menos riesgoso que construir un sistema grande.
    • Como desarrollamos independientemente las funcionalidades, es más fácil relevar los requerimientos del usuario.
    • Si se detecta un error grave, sólo desechamos la última iteración.
    • No es necesario disponer de los requerimientos de todas las funcionalidades en el comienzo del proyecto y además facilita la labor del desarrollo con la conocida filosofía de divide & conqueror
    Este modelo de ciclo de vida no está pensado para cierto tipo de aplicaciones, sino que está orientado a cierto tipo de usuario o cliente. Podremos utilizar este modelo de ciclo de vida para casi cualquier proyecto, pero será verdaderamente útil cuando el usuario necesite entregas rápidas, aunque sean parciales.