Programacion y creacion de manuales de ususario

Esta fase de nuestro proyecto nos tomo mucho trabajo, en esta fase yo trabaje mas dentro de la parte que fue la programacion, en nuestro equipo tratamos de crear el proyecto con anticipacion, y asi lo hicimos, pero nos encontramos con un problema, unos dias antes de la fecha de entrega de la programacion, el profesor de modelado nos explico como era que se hiciera exactamente la programacion de su proyecto, y... al parecer, el lenguaje de programacion en el cual estamos creando nuestro sistema, no es orientado a clases, si no que a eventos!!!!.... Lo que propisio una gran problematica en la programacion del sistema, implico que nos pusieramos a investigar la manera de pasar todas las actividades ya programadas a modulos. Despues de encontrar la manera en la que se puede hacer eso, tuvimos que crear un modulo y pasar partes del codigo a el por medio de procedimientos.
Esta vez si nos tuvimos que repartir en grandes cantidades las actividades del sistema, ya que el tiempo estava sobre nosotros, y de no hacerlo no acabariamos...
Lo bueno es que al final, todos cansados y desvelados, logramos alcanzar a terminar con la programacion y la creacion de los manuales.

BITACORA PERSONAL DEL SISTEMA

BITACORA PERSONAL


FASE DE DISEÑO


Durante la elaboracion de este paso, "Fase de diseño", nos encontramos con diversas problematicas, principalmente estuvo el problema que encontramos con la comunicacion, ya que por alguna razon, algunos de mis compañeros de equipo tuvieron problemas con sus cuentas de msn, y la organizacion fue un desastre!!!
Pero bueno, cada quien se repartio una parte del trabajo y al final todo salio bien, aunque, no nos pudimos comunicar con el administrador del,proyecto por un largo lapso de tiempo, los demas integrantes del equipo trabajamos organizadamente.
Algo que nos canso demasiado fue la elaboracion de diagramas!!!... No pensabamos (Bueno... por lo menos yo no) que fueran tantos, lo bueno es que conseguimos un programa para elaborar diagramas UML, esto nos facilito mucho elaborar los diagramas y nos ahorro tiempo, otra problematica fue que teniamos mucha tarea por otras materias, O.ó!!! pero con un poco de organizacion, casi todo salio bien al final...

TAREA NO. 2



BITACORA PERSONAL DE NUESTRO SISTEMA

Para la elaboracion de la primera face de nuestro proyecto "FACE DE ANALISIS" tuvimos que reunirnos en equipo, todos, una vez, para aclara nuestras ideas de como funcionara nustro sistema, determinamos todas las acciones que el sistema podra operar, como el sistema es de control de empleados de un cine, todo el equipo debe tener bien clara la idea que lo unico que relizara el sistema es llevar el control de los empleados, ademas visualizamos las opciones y tipo de accesibidad y privilegios que habra entre cada uno de los usuarios que haran uso del sistema.
Otro punto importante que se trato en la primera reunion, fue sobre que papel desempeñare cada integrante del equipo, ya que los unicos dos papeles ya claros son el del documentador y el administrador del sistema, tratamos de otorgar un papel individual a los demas miembros del equipo, pero al parecer, a la conclusion que llegamos, es que los demas integrantes tomaremos diferentes roles en diferentes etapas del sistema, muchas veces tomaremos el papel de diseñador, de administrador de configuracion, de administracion de validacion y verificador, tester, etc.
Hubo otra reunion pero solo fue entre el documentador y el administraodr del sistema, al parecer para ponerse deacuerdo para la impresion de los documentos.

  • PROBLEMATICAS QUE PUEDO VER EN EL EQUIPO:
La verdad, pienso que nuestro equipo funciona bien, pero pienso que aun nos falta mejorar la comunicacion entre todos los integrantes del equipo, pienso que en esta primeraa face, no logramos aplicar nuestro equipo al 100%. Pero pienso que que es un problema que se solucionara con el tiempo y una buena administracion.

Diagramas de casos de uso de un video club







ASOCIACION, AGREGACION Y COMPOSICION EN UML

TAREA MAS RECIENTE


Esta es la tarea que me dejo el profe, en la cual se debe de demostrar como se representa graficamente la asociación, agregación y composición de un objeto por medio de un diagrama UML

Bueno, pues, mi objeto es una "pistola", una pistola se puede asociar con la clase de "personas". Para representar esto por medio de un diagrama de UML, debemos de asignar un nombre a nuestro objeto, en este caso la pistola es "Magnum", se escribe la palabra "Magnum" y seguido de dos puntos se pone a la clase a la que pertenece el objeto, en este caso pertenece a la clase "Pistola", abajo de esto, se le agregan los atributos del objeto acomodados de uno en uno hacia abajo y escritos totalmente con letras minúsculas, y en la separación de abajo las acciones que realiza nuestro objeto. Como podemos ver en la figura de abajo.
En la figura podemos ver también como están enlazadas por medio de una linea los dos objetos, y como la figura de arriba apunta de "Fulano" de la clase persona a "Magnum" en la clase pistola, esto hace referencia a que existe relación entre estos dos tipos de clases, pero no solo eso, si no que la clase de persona tiene un tipo de dominio sobre la clase de pistola, "Fulano" puede hacer que la pistola realiza acciones que el le mande, eso es lo que nos esta dando a entender el diagrama de UML en este caso.

Otra representación en UML es la de las agregaciones, para representar la agregación de un objeto debemos de crear un mismo recuadro del objeto, como en el diagrama anterior, en el que se muestre el nombre del objeto, la clase, sus atributos y sus acciones, después se enlaza este recuadro a una figura de rombo, y esta se enlaza a otros objetos que pueden funcionar junto a el objeto que se tiene, como se muestra en la figura de abajo:

En este diagrama UML podemos ver como a el objeto de "Pistola" se le agregan otros objetos como el revolver y el acero para que se logre el funcionamiento de alguna acción.

También existe la composición dentro de los objetos, aquellos objetos de los que depende un objeto para que este llegue a funcionar, la forma de demostrar esta propiedad del objeto por medio de un diagrama UML es muy similar a la de agregación, solo que en este caso la figura de rombo aparece rellena y no vacía, así como se muestra en el siguiente diagrama:
Se observa como la figura del rombo de el diagrama de composición es distinto a el de agregación.
En la figura se puede ver como el objeto de "Bala" es un objeto que el objeto de la clase pistola necesita para realizar su acción.

ORIENTACION A OBJETOS

Los objetos estan en todo nuestra alrededor, ellos conforman nuestro mundo, hablando dentro del campo de la programación, el software actual simula al mundo o a alguna parte de él, entonces, el software imita a los objetos del mundo.
En programacion, los objetos tienen ciertos principios que el programador debe de comprender para la utilizacion de la orientacion a objetos en el analisis y diseño de software.
Un objeto es la instancia de una clase.
Por ejemplo: Un automovil, es un objeto instancia de la clase vehículo de transporte, y como objeto de la clase vehículo, este tiene atributos ,como, modelo, año, material, tipo, etc, y realiza tareas como, transportar, cargar, etc.
Si se tuviera la necesidad de crear un sistema para el manejo de informacion acerca de automoviles, tendriamos que tomar en cuanta atributos y acciones de los automoviles para crear un buen software.
Pero no solo la orientacion a objetos se basa en atributos y acciones, debemos tomar en cuanta de que existen otros aspectos dentro de los objetos, como la abstraccion, que consiste en quitar las propiedades y acciones de un objeto para dejar solo aquellas que son necesarias, otra es la Herencia, que se puede explicar como las clases que derivan de otras clases, a la clase que se encuentra en un nivel antes se le llama superclase, y a la que le sigue subclase. El poliformismo, que es cuando una accion puede tener el mismo nombre en diversas clases, y funcionar distinto en cada una, el encapsulamiento, cuando los objetos ocultan su funcionalidad interna, las asociaciones, cuando los objetos se relacionan entre si de alguna forma, el envio de mensajes, para que los objetos de un mismo sistemas puedan trabajar en conjunto, la agregacion, cuando un objeto se conforma de una combinacion de diversos tipos de objetos y la composición, es un tipo de agregacion que trae consigo una estrecha relacion entre un objeto agregado y sus objetos componentes.

INGENIERIA EN SOFTWARE

La ingenieria en software es una disciplina que tiene el proposito de crear software edacuado y de caludad para tratar funciones que hagan de la vida mas fácil, aplicando herramientas y conocimientos de programación.
Hoy en dia, utilizamos software en todo nuestro alrededor, en los negocios, en las escuelas, hospitales, oficinas, bancos, etc.

¿QUE ES UN BLOG?

Un Blog, o tambien conocido como Weblog, es un sitio web donde periodicamente se introducen articulos o comentarios de uno o varios autores, el equivalente de la palabra "Blog" en español, significa bitácora, termino usado anteriormente en los cuadernos de bitácora de los barcos, se puede decir que un Blog es un tipo de diario de cierto autor, solo que este se escribe por medio del internet, asi es como comenzaron los primeros blogs, uno de los primeros escritores de estos diaros online fue Justin Hall, quien mientras era estudiante de la Universidad de Swarthmore, escribia su blog personal.
Hoy en dia, es muy facil obtener un blog personal, existen paginas gratuitas, y con herramientas que se utilizan facilmente para cualquier tipo de ususario, sin la necesidad de que este tenga grandes conocimientos tecnicos para crear un blog, otorgando la facibiladad de subir comentarios sin censuras, al igual que fotografias y videos, paginas como Freewebs, Blogger y LiveJournal
ofrecen un servicio de solucion completa de alojamiento gratuito. Este tipo de software te otorga una direccion electrinca por la cual puedes editar el contenido de la misma, una de las desventajas de este tipo de software es que el usuario se limita a lo que el provedor del servicio ofrece.