Informe Técnico - Kárdex

Informe Técnico

Informe Técnico - Tienda en Línea

Informe Técnico

Informe Técnico - Cajero Automático.

Informe Técnico

Caso de estudio: Cajero Automático.

     Para este caso de estudio nos enfocaremos en el sistema desde el diagrama de Casos de uso que definimos previamente en el post dedicado al UML. El sistema que desarrolláremos será el de un cajero automático: un ente físico con una interfaz de fácil uso para un usuario que desee realizar transacciones diarias con su cuenta en un banco sin la necesidad de asistir directamente a la sucursal de la empresa que le presta el servicio para guardar el dinero. 

   

Casos de Uso:

-Usuario: introduce tarjeta.

-Cajero: retiene tarjeta. Pide contraseña a usuario.
-Usuario: introduce contraseña.
-Cajero: lee contraseña. Verifica contraseña con Banco. Espera respuesta de Banco.

-Banco: informa a Cajero que la contraseña es correcta. (Informa a Cajero que la contraseña es incorrecta). 

-Cajero: muestra menú 1. 

-Usuario: escoge opción Retiro. (Depósito - Consultar Saldo - Cambiar Clave). 

-Cajero: muestra menú Retiro. 

-Usuario: escoge monto. (Otro monto).

-Cajero: confirma monto. 

-Usuario: indica monto correcto. (Indica monto incorrecto). 

-Cajero: verifica monto suficiente en cuenta de Usuario con Banco. Espera respuesta de Banco.

-Banco: informa a Cajero que el dinero en cuenta es suficiente para el retiro. (Informa a Cajero que el monto es mayor al dinero en la cuenta). 

-Cajero: pide a Usuario dos primeros o dos últimos dígitos de la cédula.

-Usuario: ingresa los dígitos solicitados.
-Cajero: verifica que los dígitos sean correctos con Banco. Espera respuesta de Banco.

-Banco: informa a Cajero que los dígitos son correctos. (Informa a cajero que los dígitos son incorrectos). 

-Cajero: cuenta el dinero. Despecha el dinero. Recuerda a Usuario que retire el dinero. Finaliza la operación. 

-Usuario: Retira dinero. Retira tarjeta. 

Manejadores de archivos

   Un manejador de archivos, o gestor de archivos, se caracteriza porque permite al usuario la capacidad de administrar los documentos que posee en la memoria física de su computador. Originalmente fueron desarrollados para los sistemas operativos usando una interfaz de texto bastante sencilla, pero luego se fueron incorporando poco a poco maneras más gráficas de representar los espacios en la memoria, lo que dio lugar a que se pudieran relacionar archivos con programas o según el tipo de archivo que fuese (.txt, .exe, entre otros). El primer manejador de archivos para un sistema operativo en utilizar una interfaz gráfica fue el Dired. 

   Las bases de datos sirven para guardar información relevante para un usuario o sistema, información de gran importancia que debe permanecer guardada aún cuando el sistema no esté operativo (la aplicación esté cerrada o el dispositivo apagado). Los manejadores de archivos se crearon como interfaces sencillas para permitir que el usuario accediera y pudiera interactuar con los datos almacenados para realizar distintas operaciones con ellos, según deseara: crear nuevos archivos, moverlos de lugar, cambiar el nombre de los mismos, editarlos o, inclusive, eliminar información. Los gestores de archivos usan un espacio de memoria temporal (ram) para realizar sus operaciones necesarias, pero la información que se queda en esta memoria se pierde luego que el programa finaliza su función, pero en la memoria física (disco duro) del ordenador se puede guardar información de manera más durable en el tiempo; y para poder trabajar con sencillez sobre esta memoria secundaria es que se han ido mejorando al paso de los años los manejadores de archivos.

     Hoy en día hay muchos gestores de archivos, de diferentes maneras presentadas, para distintos sistemas operativos e inclusive para otras aplicaciones, como podrían ser sitios webs o programas de un ordenador que necesite guardar información concreta de manera no volátil. Hay manejadores de archivos de código libre, y muchos otros que se debe adquirir una licencia para poder usarlos, pero todos básicamente cumplen con la misma función de dar un acceso fácil y eficaz a los archivos ubicados en una dirección específica de la memoria.

Fin del décimo tercer post.
Autor: Daniel Marcano.
Tiempo tomado para investigar y redactar: 8 horas.
Fuentes: www.wikipedia.org 

UML

     Al hablar de un sistema de información o software debemos tener en cuenta que antes hay que definir sus partes, realizar una especie de "plano" o modelado de lo que se desea obtener del sistema en cuestión: funcionalidades, objetivos, maneras para lograrlo, usos posibles, necesarios y opcionales, y una gama de componentes más que tienen relación con el modelo que buscamos realizar. Pero surge un problema, ¿Qué es un modelo? Pues Booch, Rumbaugh y Jacobson definieron en 1999 un modelo como "una simplicidad de la realidad"; una manera con un nivel de abstracción tal que permita obtener sólo lo relevante al problema que deseamos solucionar para enfocarnos en ello. 

   Estas tres personas mencionadas previamente son importantes al hablar sobre el Lenguaje Unificado de Modelado (UML por sus siglas en inglés) ya que fueron ellos quienes realizaron la propuesta de usar una semántica universal para diseñar el plano y toda la documentación previa al desarrollo del software, ya que anterior a esta propuesta no había nada concreto y entre programadores podía haber confusión sobre lo que se quería representar del sistema, ya que no todos tenemos el mismo nivel ni capacidad de abstracción. Ante esta problemática fue que se hizo la propuesta del UML en 1995, que sería posteriormente aprobada por la Organización Internacional de la Normalización (ISO) para ser adaptado como el lenguaje más común para realizar diagramas sobre sistemas. Aunque es el lenguaje más usado, no es el único lenguaje existente en el modelado de sistemas, pero nos enfocaremos únicamente en este. 

     El UML se basa en el método Booch, que es un lenguaje de modelado de objetos, ampliamente usada en la ingeniería de software para el diseño y el análisis orientado a objetos por su representación gráfica que ahora utiliza UML; en la técnica de Modelado de Objetos (OMT), de la cual adquiere los tipos de clase (específicas y generales), las relaciones de asociación o los símbolos de generalización; y en la Ingeniería de Software Orientada a Objetos (OOSE), de la cual obtiene los "casos de uso" que fue una de las principales características de OOSE, pero al igual que los otros dos lenguajes pertenecientes a la cuña base del UML, han quedado obsoletos por la aparición del mismo. 

   Este lenguaje está enfocado más que todo en la programación orientada a objetos y esto es apreciado fácilmente, no sólo por la base que le dio vida al UML sino también por los distintos diagramas que lo componen:  

• Diagramas de Estructura. 
• Diagramas de Comportamiento.
• Diagramas de Interacción.

     Entre los diagramas de estructura tenemos el diagrama de clases, que es uno de los diagramas que trabajaremos en el aula de clase, por tanto será uno a los que demos mayor énfasis. 

     El diagrama de clases es un diagrama de estructura estática que sirve para visualizar más eficientemente las distintas clases del sistema, sus atributos, operaciones y la relación con otros objetos del sistema que se esté modelando. Es importante definir una clase, para poder saber cómo se debería estructurar el diagrama, partiendo de esto podemos decir que una clase son varios elementos que comparten una serie de atributos, operaciones y relaciones dentro del sistema, pudiendo así agruparlos dentro de un único objeto que represente a esos elementos ahí encontrados. Hay elementos que tienen atributos y/u operaciones en común, pero otros muchos en los que difieren, por ejemplo: si tuviésemos una clase llamada vehículos, los vehículos todos tienen una atributo en común: permiten la movilización, pero tenemos diferentes tipos de vehículos, bien sean terrestres, aéreos, acuáticos, incluso hasta espaciales. Es aquí donde UML tiene en su diagrama de clase la característica obtenida de la OMT, que son clases generales y clases específicas, representando en una clase generalizada llamada vehículo, la cual podría tener atributos tales como Velocidad, Combustible; que serían atributos generales que heredan las clases específicas que se desprendan de él. Hemos escogido estos dos atributos como generales porque todo vehículo tiene una velocidad a la que se mueve y usa un tipo de combustible, por lo tanto puede ser una clase general para que todos los vehículos, sin importar sus especificaciones, tengan estos atributos. 

     En clases específicas tendríamos, por ejemplo: carro, avión, moto, helicóptero. Todas estas son vehículos, por lo tanto comparten las mismas características de la clase general, pero tienen atributos diferentes en sí: tamañoRin sería un atributo de las motos y los carros, pero que no aplicaría para algunos helicópteros, así mismo longitudHélices sería un atributo de helicópteros, pero que no aplicaría para los carros o motos, sin embargo podrían cumplir con dicha características uno que otro avión. Tenemos también el siguiente ejemplo: 

     El diagrama de casos de uso sirve para representar al actor principal o usuario del sistema interactuando de las diferentes maneras posibles con el software para poder tener una idea de las necesidades del sistema, pero no sólo así con el actor principal ya que hay otros usuarios secundarios que no son parte directa del sistema, pero el mismo podría interactuar con ellos para lograr su objetivo. Los diagramas de caso de uso se pueden representar de manera narrativa y gráfica. Aquí dejaré un ejemplo de manera gráfica de un diagrama de caso de uso de un restaurante y más adelante veremos cómo se trabaja de manera narrativa este tipo de diagrama de comportamiento. 

Fin del décimo post.

Tiempo tomado para investigar y redactar: 6 horas.

Autor: Daniel Marcano.

Fuentes: www.wikepedia.org

Sistema de Gestión Académica

Gestión académica tiene un objetivo de aprobar las unidades de crédito necesarias para ir avanzando en el sistema de educación superior en el que se encuentre el sistema controlado (estudiante). Según esto, podemos observar que el sistema de gestión académica tiene una naturaleza controladora sobre otro sistema, modificando entradas de este (hábitos) según los resultados (notas) que el estudiante vaya arrojando. 

Así que el ambiente en el que se desarrolla el sistema es un sistema no físico, donde se maneja información. El sistema tiene otros elementos en su medio los cuales serían: notas, alumno, tiempo (que también es un límite) y un plan de evaluaciones. De todos estos elementos que componen el medio ambiente de la gestión académica, se ve una relación de entradas/salidas que podríamos describir de la siguiente manera: por entradas, provenientes de notas, llegan datos; del plan de evaluación o evaluaciones ingresa la lista de evaluaciones planteadas en el lapso esperado (tiempo límite para lograr objetivo), por salida un plan al alumno para que efectúe una modificación en sus hábitos y así poder lograr el objetivo del sistema gestión académica.

De manera gráfica se apreciaría así: 

Gráfico 1

Pero dentro de sí el sistema tiene interrelación entre sus elementos (sensor, comparador y activador). El sensor recibe datos de entrada de las notas, como se aprecia en el gráfico 1, estos datos son transformados en información por el sensor y compartido al comparador; pero también el sensor puede recibir información del alumno, como el tiempo que le dedica a aplicar los planes que le indica el activador, así como otros datos en general; el comparador recibe información del sensor y da una señal específica al activador para que envíe al alumno un plan correspondiente según el caso que se esté dando (por ejemplo: que dedique más horas de estudio, que estudie más un tema en específico, que dedique más tiempo a las asignaciones o que mantenga el nivel de lo que está haciendo para seguir con el rendimiento académico elevado).

Si el sistema Alumno no aplicase el tiempo, dedicación o atención suficiente al plan que debe acatar, o decide ignorar las salidas de la gestión académica, crearía entropía en el sistema controlador, ya que no se estaría cumpliendo la función; así mismo si el alumno cumpliese con el plan pero no lograra los resultados esperados, el sistema deberá evolucionar y reorganizarse internamente para que el alumno, siguiendo el plan, pueda aprobar o mejorar la nota obtenida en sus actividades académicas. El sistema debe desechar un cierto nivel de entropía para seguir siendo útil, es decir: la neguentropía. Esta podría ser bien: dar una señal de reorganización del tiempo empleado por el alumno, es decir, disminuir el tiempo invertido es cosas menos relevantes para usarlo en aplicar el plan de estudio que arroje el sistema controlador; pero también podrían ser nuevos métodos de estudio para el comprendimiento y mejor internalización de lo que debe aprender el alumno, o sea, tomar planes de contingencia. 

Si el sistema se consigue con mucha entropía entrante desde su medio, se verá obligado a reorganizarse, o sea, evolucionar de manera que pueda seguir siendo útil para controlar las notas obtenidas por el alumno. 

Las partes elementales del sistema (sensor, comparador y activador) se comunican en diversas maneras con el medio ambiente del sistema gestor al que pertenecen. Los que más actividad tienen con el mismo son el sensor y el activador, que reciben entradas y ofrecen salidas respectivamente; el que menos interactúa con el ambiente, pero aún así recibe información del mismo, es el comparador que recibe información de las evaluaciones a lo largo del plazo de tiempo estipulado para poder elegir qué señal da al activador (por ejemplo, si el comparador nota que no hay manera posible de aprobar el semestre con las evaluaciones que faltan por realizar, podría mandar una señal al activador que active el plan de retirar la materia; para que el resto del semestre no se vea afectado por esto). 

Así, pues, vemos que el comparador cuenta con distintos elementos dentro de él (es un subsistema). Estas partes se encargarían de ver la información entrante del sensor, o sea, la nota obtenida, compararla contra la nota esperada, revisar las evaluaciones ya aprobadas, las reprobadas y las que faltan por evaluar para así tener información sobre qué tal va el alumno en la asignatura que el sistema evalúa. Si el alumno ha raspado la mayoría; si es la primera evaluación que presenta y la reprueba; si es la primera evaluación, la aprueba pero con una nota baja; si lleva aprobadas la mayoría de evaluaciones; si lleva muchas reprobadas y ya no quedan evaluaciones restantes suficientes para aprobar; todos estos son casos que los elementos del comparador evalúa para enviar la señal correcta al activador, que enviará un plan específico al alumno para poder cumplir el objetivo final que se plantea. 

Si lo resultados obtenidos por el alumno en una asignatura se ven positivamente influenciados y que aprueba con bastante facilidad los créditos necesarios, el sistema tendrá un crecimiento en su estructura teniendo varios sensores, comparadores y activadores para controlar la variabilidad que egresa de él, ya que el alumno podría querer aplicarlo para más asignaturas, o más alumnos podrían querer hacer uso del sistema y este deberá crecer y evolucionar para suplir la demanda exigida.

De manera gráfica se apreciaría así: 

Fin del noveno post.
Tiempo tomado para investigar y redactar: 6 horas.
Autor: Daniel Marcano.
Fuentes: daniel-marcano.blogspot.com