La Trinchera del Jorge

En los diagramas de caso de uso, existen unas lineas llamadas "extends" e    "include". Pero por algún motivo no se bien cual es su significado, así que por eso voy a tratarlo aquí.

EXTENDS

Extends grafica una relación directa. Generalmente se extienden dos casos de uso y son catalogados como el caso de uso "base" y el "extendido". Extends indica que el caso de uso "base" es significativo por su propia cuenta, esto quiere decir que no necesariamente tiene que ejecutarse el caso de uso extendido para que el base funcione. En si es como un plus para el caso de uso base. 

En este caso, Registration es el base, y se puede ejecutar perfectamente sin que el extendido se ejecute. Aunque si se ejecuta el extendido le da un valor extra al base ( el caso de uso extendido ejecuta una ayuda para registrarse).

INCLUDE

Es una relacion entre dos casos de uso, en el cual el comportamiento de uno es necesario para que el caso de uso principal se ejecute correctamente. Esa es la diferencia con la relación extends.

Merece la pena estudiar este cápitulo para poder conocer bien que son los casos de uso y como implementarlos bien. Como estudiante uno sabe que es un caso de uso pero no lo maneja al 100%.

Los casos de uso son un mecanismo ampliamente utilizado para descubrir y registrar los requisitos (Especialmente los funcionales). Influencian muchos aspectos del proyecto, incluyendo el A/DOO (análisis y diseño orientado a objetos) .

La escritura de casos de uso -Historias de uso de un sistema- es una técnica excelente para entender y describir los requisitos.

Los clientes y usuarios finales tienen objetivos (también conocidos como necesidades)  y quieren sistemas informáticos que les ayuden a conseguirlos, que varían desde registrar las ventas hasta estimar el flujo de petróleo de futuros pozos. Hay varias formas de capturar estos objetivos y requisitos del sistema; las mejores son simples y familiares , por que esto hace que sea mas facíl                  -especialmente para clientes y usuarios finales- contribuir a su definición y evaluación. Esto reduce el riesgo de perder el hilo.

Los casos de uso son un mecanismo para ayudar a mantenerlo simple y entendible para todo el personal involucrado. De manera informal, son historias del uso de un sistema para alcanzar los objetivos. A continuación presentamos un ejemplo de un caso de uso en formato breve: Procesar venta: Un cliente llega a una caja con artículos para comprar. El cajero utiliza el sistema PDV para registrar cada artículo comprado. El sistema presenta una suma parcial y detalles de cada línea de venta. El cliente introduce los datos del pago, que el sistema valida y registra. El sistema actualiza el inventario. El cliente recibe un recibo del sistema y luego se va con el artículo.

A menudo, los casos de uso necesitan una elaboración mayor que ésta, pero la esencia es descubrir y registrar los requisitos funcionales , mediante la escritura de historias del uso de un sistema., para ayudar a cumplir los objetivos  de varias de las personas involucradas.; esto es, los casos de uso.

Capitulo 3: El sistema de archivos

Conceptos clave:

- La base del árbol de directorios de linux es un archivo llamado / y se conoce como el directorio root. ( es el simbolo porsiacaso..)

- Las referencias absolutas de archivos, tales como /home/jorge/prueba.txt se refiere a los archivos relativos al directorio raiz.

- Las referencias relativas de archivos tales como prueba.pxp hacen referencia al directorio actual en donde estemos.

- El comando cat se usa para leer el contenido de un archivo.

- Al utilizar el caracter > podemos direccionar la salida de un comando a un archivo.

- El directorio home es uno de los pocos lugares en donde los usuarios pueden crear archivos nuevos.

Dar nombres a archivos y directorios

En linux, la informacion esta almacenadas en discos como archivos. Los archivos se encuentran agrupados en directorios ( o carpetas). En los directorios pueden existir mas directorios y mas archivos. Esta jerarquía es lo que se conoce como árbol de directorios.

La base de este arbol es un directorio llamado simplemente / y se conoce como el directorio raiz. Los archivos dentro de este directorio raiz se conocen como /nombredelarchivo. En centos el directorio raiz contiene otros directorios tales como /etc. Por ejemplo el archivo network que se encuentra dentro del directorio sysconfig , que a su vez se encuentra en el directorio etc, el cual esta dentro de root / puede conocerse como /etc/sysconfig/network.

Siempre existen dos maneras de referirse a un archivo. Las referencias de archivos relativos a la raiz siempre comienzan con el signo /. en cambio las referencias absolutas no llevan /, ya que están dentro de otro directorio. por ejemplo, estamos en etc, y para buscar prueba.txt solo citamos ese nombre.

Listado del contenido con el comando LS

Desde una shell los usuarios pueden listar el contenido de un directorio con el comando ls. este comando significa lista, así que es fácil recordarlo. Si se usa sin ningun argumento, lista el contenido del directorio actual en el que la shell este. Este comando es super poderoso y extenso, pero nos quedaremos con esto nada mas. tambien se puede usar el -a.

El comando cat

Con este comando puedes ver el contenido de algun archivo de texto. por ejemplo estamos en /home/documents/ y dentro de documents existe un texto.txt, puedes ver su contenido tecleando esto: cat texto.txt y paff !! veras el contenido en el terminal. !! El comando > que redirecciona

Recuerdan el calendario que salia con el comando cal? pues bien, puedes hacer que ese calendario se escriba en un .txt en la ubicacion que quieras. esto se hace asi. - llama el calendario con cal

- situate en /home/tunombre/document ( depende de donde quieras situarte, document esta bien).

- ahora que estas en document, llama al calendario y usamos el simbolo y el destino:

cal > elcalendario.txt

y paff !!! el calendario esta impreso en el archivo elcalendario.txt Si quieres verlo, usa cat elcalendario.txt y veras el calendario.

Seguiré con la otra parte del pedeefe del profe... emekadiiiiiiiiiiiiiiiiiiir XD

Capitulo 2: un poco sobre el kernel, programas y procesos.

El kernel de linux es un sistema operativo asi como el windows, el MacOS, etc. EL sistema operativo es un entorno en donde se ejecuta un programa, proporcionándole los mecanismos a los programas para interactuar con el hardware del computador. EL kernel le permite saber a un programa cuando el usuario pulsa una tecla, mueve el mouse, se manda un condoro, etc etc. EL kernel permite a los programas acceder al disco duro, y muchas tareas ya conocidas por todos.

Los programas

Los programas son archivos almacenados en el disco duro. Es un conjunto de instrucciones básicas que le dicen al sistema que hacer y cuando hacerlo.

Las Shell

Los usuarios de linux utilizan un tipo especial de programas llamados shell para interactuar con el kernel. La shell se ejecuta dentro de una terminal emitiendo un "prompt" y esperando a que le digan que hacer. para probar esto, abre una consola, y teclea lo siguiente:

cal

El shell ejecuta obedientemente la instrucción y te muestra un sencillo programita de calendario.

El comando PS

El comando ps se utiliza para para enumerar los procesos ejecutándose en un sistema. EL comando ps sin argumentos lista todos los procesos actuales en la maquina.

Para comprender mas... cuando hagas esto en la terminal veras cosas como:

PID: es el id de proceso TTY: ya sabemos que corresponde a la consola o terminal TIME: es el tiempo que la CPU ha utilizado.

Prueba de Administración de sistemas operativos !!! Muy bien señores, vamos a estudiar los conceptos que nos enseño el profe armijo, de sus excelentisimos pedeefes XD. jajaja intentare plasmar lo mejor de esa información. Vamos a eso. Capitulo 1: Inicio de sesión

En linux, primero tenemos que iniciar sesión en la maquina. Cada usuario tiene su sesión predefinida.

Para iniciar sesion, tenemos que tener el usuario y la contraseña. . !NO me digas????? ! XD. Voy a resumir la chachara En linux existen 7 consolas virtuales, las cuales pueden ser accedidas con las teclas Ctrl + alt mas F1... HASTA EL F6. (sale una terminal donde te pide user y pass). para volver a la interfaz gráfica, hay que hacer lo mismo pero con F7.

Un comando interesante es el "WHO" el cual lista a los usuarios que tienen una sesión activa y la manera en que iniciaron sesión.

nota: Tenemos 7 consolas virtuales disponibles. entonces por que el documento solo nombra 6 y la séptima es para volver a la interfaz gráfica?? Es por que en la consola numero 7 se aloja el servidor que nos provee del entorno gráfico. jaja lógico no?

Un poco de teoría

El sistema operativo unix, creado a fines de los 70, precede los días de los computadores personales. Originalmente muchos usuarios utilizarían unix de forma simultanea operando en un computador central. En vez de que cada usuario tuviera un computador personal, utilizaban que lo hoy dia se conoce como un "terminal tonto" ( solo una pantalla y un teclado conectado a un computador central mediante una conexión serial). Para identificarse con unix, el usuario tenia que identificarse con su usuario y su password.

Aunque linux a crecido para tomar ventaja de los computadores personales al alcance de todos, no han perdido los conceptos esenciales como los usuarios, las contraseñas, el inicio de sesión y las terminales con pantallita negra. ( no soy un nostalgico de la consola como para seguir citando toda la leyenda XD).

Uso del comando WHO

Los usuarios pueden ocupar el comando WHO para saber quien se encuentra en el sistema y como iniciaron sesión. Solo escribe WHO ( en minúscula !!, no faaaltan 77). y saldra la informacion asi:

Para hacer esto facil: tty1, tty2, etc corresponden a los terminales virtuales

:0 corresponde a la interfaz grafica

la fecha y la hora es... la fecha y la hora que iniciaron sesión

ah y el nombre de cada usuario.

Crear usuarios en la consola

Esto no sale en el pdf del profe, pero es bueno saberlo. Para crear usuarios mediante la terminal, tenemos dos comandos:

- useradd - passwd

para usarlos, escribe - useradd nuevouser

Luego escribes

- passwd nuevouser

Y les pedirá la contraseña para el nuevo usuario. la ingresan y aunque reclame que la contraseña es corta, la reingresas, y paff !!! nuevo usuario creado.

Excelente !! hoy vamos a hablar de las 10 Heurísticas de usabilidad de una aplicación web. 

Bueno bueno, el creador de estas heurísticas es el señor Nielsen, en el año 1990 fue que se le ocurrió. En ese entonces no lo hizo pensando en la web, por lo que en el año 1997 un señor de apellido Instone las adapto a las nuevas tecnologías.

En términos prácticos estas diez reglas nos sirven para que nuestras interfaces web tengan un alto grado de usabilidad. En fin vamos a verlas cada una.

Visibilidad del estado del sistema : El usuario siempre debe saber cual es el estado del sistema. Por ejemplo, si el sistema esta cargando una imagen, yo como usuario tengo que saber claramente que el sistema esta cargando una imagen. Esto se puede lograr con un simple mensaje que diga "cargando imagen". La idea es siempre retroalimentar al usuario en el accionar de nuestra página. 

Adecuación del sistema con el mundo real: En otras palabras, esto quiere decir que el sitio web tiene que manejar el lenguaje del usuario. Por ejemplo, un simple botón que confirma el almacenamiento de algún dato en una BD. Este botón tiene que llamarse " guardar ", y no "almacenar registro". Para un usuario común, "guardar" es mucho mas claro ¿no?.

Control por parte del usuario y libertad: El usuario tiene que tener libertad total para usar el sitio. El caso típico es cuando el usuario comete un error. Cuando esto ocurra tenemos que proveerle al usuario de todas las alternativas para corregir el error o al menos guiarlo, y no obligarlo a que termine la acción. un buen ejemplo es el grabar algún dato de formulario, si el usuario guarda una palabra fuera del contexto del sitio, darle la oportunidad de verificar su acción con un simple mensaje de " va a guardar xxxx registro ". Con esto le damos la libertad para decidir.

Consistencia y cumplimiento de estándares: Es simple este punto, solo tenemos que basarnos en estándares normales de creación de una interfaz. el ejemplo mas básico es la típica opción de cerrar la ventana. Todas las interfaces tienen esta opción en la parte superior derecha. seria un poco iluso si coloco esta opción de cerrar en el centro de la pantalla. No podemos dejar afuera los estándares de la W3C y todo eso. El fin de este punto es seguir los estándares y punto.

Prevención de errores:  Aquí habla de prevenir errores, siendo claros en las instrucciones del sitio, validando la información que el usuario ingrese, impidiendo acciones incorrectas. simple.

Minimizar el uso de memoria del usuario: Cuidado !! no estamos hablando ni de memoria ram ni rom ni nada por el estilo. Hablamos de la memoria del usuario. Por ejemplo si en la primera pagina del sitio sale un link llamado " videos " en la parte central de la página, no tenemos por que colocar ese mismo link en la 2 pagina en el costado superior derecho. si hacemos eso obligamos al usuario a estar analizando en donde esta el famoso link. tiene que ser intuitivo y fácil de recordar.

Flexibilidad y eficiencia de uso: Siempre hay que maximizar el uso del sitio, tomando medidas que hagan flexible el sistema. En el caso de la pagina web, no sobrecargar con imágenes innecesarias o cosas inútiles. si el usuario quiere ir a una sección, pues que se dirija a esa sección sin contratiempos. 

Diseño Minimalista: Solo colocar información relevante, y no sobrecargar el sitio con cosas que no vienen al caso ( es tarde y tengo sueño, por eso estoy resumiendo XD).

Ayuda y control de errores: Siempre tienen que existir mensajes de error que ayuden al usuario a solucionarlos. Estos mensajes tienen que ser claros y sin rodeos.

Ayuda y documentación: El usuario no puede estar solo en el sitio, siempre hay que dejar una sección para la documentación del mismo.

Un archivo de código fuente solo puede tener una clase publica. Y si este archivo de origen contiene tal clase public, el nombre del mismo tiene que coincidir con el nombre de la clase, en este caso "Prueba". (quedaría como Prueba.java).

class TestPrueba { }

public class Prueba /* esta es la única clase publica que puede existir */ {                         public prueba()                         {                           object obj;                           String palabra = new String ("hola");                           obj=palabra;                          }  }

-------------------------------------------------------------------------------------

Un archivo solo puede contener una declaración package, pero múltiples sentencias import. La instrucción package siempre tiene que ir de las primeras, y los import después del package y antes de la declaración de clase. no existe otra forma.

package nuevo; import java.util.*;

public class Clase1    /* declaración de clase*/ { } 

-------------------------------------------------------------------------------------

Excelente !! encontré el material de java que dio la profesora Viviana Alvarez, una gran profe !.

Introducción

Que es la certificación?

Nombre: Oracle Certified Profesional Java Programer Sigla: 1Z0-851

la obtencion de este titulo certifica que el programador comprende la sintaxis y la estructura basica del lenguaje de programacion java y puede crear aplicaciones java que se ejecutan en sistemas de servidor y escritorio utilizando JSE 6.0.

EL examen consta de 60 preguntas, con un tiempo de 150 minutos. Para aprobar se deben contestar bien 37 de 60 preguntas, es decir un 61%.

Tipo de examen: Selección múltiple en idioma ingles.

Temario

Sección 1: Declaraciones y control de acceso, Asignación y Operadores 

Sección 2: Control de Flujo 

Sección 3: Contenido API

Sección 4: Concurrencia – Hilos

Sección 5: Conceptos OO 

Sección 6: Colecciones y Genéricos 

08/01/2009

By bombadil... reescrito por jorge

El desarrollo orientado a pruebas (TDD, test driven developed) es una forma de desarrollar basándose en que un cierto algoritmo responda de una forma especifica a unos datos específicos. Para explicar mejor esto, voy a explicar el enfoque tradicional y luego expongo las mejoras que introduce esta forma.

Enfoque Tradicional

Cuando se pide el desarrollo del proyecto, lo que se pide es "qué" hay que hacer sobre el problema planteado. Por ejemplo, un programa de contabilidad, podría consistir, a groso modo en almacenar los datos contables y ofrecer los informes correspondientes. En el momento en que pasamos a desarrollar la idea, el problema, entramos en el "como" hay que hacerlo. Se desarrolla un modelo en el que se plasma como almacenar los datos, presentar los informes y desarrollamos nuestra aplicación basándose en esas premisas. 

Teniendo ya el software terminado, pasamos a las pruebas, tras las cuales podemos descubrir fallos y pasar a corregirlos, asi hasta que todos los errores esten solucionados. 

El problema de este sistema es que, si la previsión o las fases han sido realizadas de forma superficial, es muy posible que ciertos usos hayan escapado de nuestro diseño, es más, es posible que, aún habiendo pedido el cliente un cierto uso, lo hayamos malentendido o no funcione de forma correcta por una decisión de diseño mal orientada.

En ese caso, habría que retroceder hasta el punto del diseño, comprobar de nuevo los requisitos con esta nueva información y continuar hacia adelante. Es un proceso muy lento y tedioso.

Enfoque TDD

Basándonos en el principio YAGNI (you ain’t gonna need it?, ¿realmente lo necesitas?), podemos pedir unos casos que cubran la mayor parte de los casos practicables, según los requisitos, de modo que tengamos los datos de entrada y los datos de salida de nuestra aplicación, es decir, no solo saber qué proceso se debe de hacer, sino además, tener un ejemplo palpable de los datos que se deben de poder conseguir, para construir la aplicación con solo y exclusivamente lo que nos pidan.

Teniendo claro qué se debe de hacer, ilustrado con los ejemplos, pasar al cómo es bastante simple, puesto que se trata de realizar un programa que permita hacer el paso de unos datos, de una forma a otra, sin más.

La batería de pruebas está definida, desde antes de comenzar a codificar, y se pueden desarrollar unidades pequeñas que pueden ir probándose para ver que cumplen lo que se pide. Para esto podemos emplear sistemas de pruebas unitarias.

En el ejemplo de las cuentas contables, puede pasar por determinar el uso de las cuentas contables en sí, los datos que se requieren almacenar para los informes y los datos que se deben de introducir por parte del usuario: número de cuenta, concepto, valor, etc.; en lugar de desarrollar un complejo programa que incluya todo referente a la contabilidad en sí.

Este enfoque, en sí fusiona los conceptos de codificación y pruebas, de modo que se hacen de forma conjunta, al disponer de datos para ello. Así mismo, incluye el diseño de las pruebas en el análisis, y se usan como requisito para el diseño, con lo que se puede apreciar que las pruebas, están presentes en todas las etapas de desarrollo y, no hay una etapa separada o específica para ellas, aunque pueda hacerse.

Conclusiones

MVC para aplicaciones web

La idea de la arquitectura MVC para aplicaciones web es bastante simple, tenemos que tener las siguientes responsabilidades claramente separadas en nuestra aplicación.