Mostrando entradas con la etiqueta Puntos Extra POO. Mostrar todas las entradas
Mostrando entradas con la etiqueta Puntos Extra POO. Mostrar todas las entradas

domingo, 30 de octubre de 2011

Ejercicio Heurísticas de diseño.

En este ejercicio vamos a ver unos ejemplos de como se rompe la heurística en el diseño de interfaces gráficas, así como proponer una interfaz mejor.


Ejemplo 1.
En este ejemplo, podemos tener dos errores, el primero me da la opción de poner mi edad, sin embargo esto puede ser poco viable, ya que puedo teclear letras en lugar de números, el segundo error yo puedo seleccionar las dos opciones, cuando en verdad solo debemos de seleccionar una, para evitar confusiones.






Ejemplo 2.
En este ejemplo el único error que veo es la combinación de colores de la ventana y del texto, ya que para el usuario va a ser un poco molesto estar leyendo con esa combinación, para lo cual considero que hay que cambiar esa combinación.


Ejemplo 3.
En este ejemplo, es un software de impresión, rompe con la heurística de metáfora, ya que utiliza botones que son propios de un reproductor de música, aparte de que el botón rewind no tiene porque estar.



Referencias:
http://homepage.mac.com/bradster/iarchitect/shame.htm

jueves, 8 de septiembre de 2011

Diagrama de clases.

Para hacer este diagrama de clases utilizamos el software Umbrello.

Ejercicio 3 - Caso biblioteca.

La universidad X tiene un sistema de información que le maneja el catálogo de biblioteca y los préstamos.
El usuario ingresa con un nombre (matrícula, # de nómina) y contraseña (nip asignado por biblioteca).
Puede buscar dentro del catálogo aquellos libros que le interesan; se le despliegan los datos bibliográficos (incluida imagen).

  • Considerar que el libro no siempre está disponible: prestado, en reparación, en encuadernación, apartado, etc.

También se puede sacar los libros prestados

  • Siempre y cuando el usuario no tenga muchas multas.
  • Si los libros son de consulta, no se pueden sacar.
  • El tiempo de préstamo es diferente si se trata de un alumno de licenciatura, maestría, doctorado o un maestro.



Casos de uso.


U1: Alumno de licenciatura.
U2: Alumno de maestría.
U3: Alumno de doctorado.
U4: Maestro.



Nombre del caso
Actor involucrado
Descripción
Casos de uso involucrados
Ingresar al sistema
U1, U2, U3, U4
El usuario mediante la introducción de una matrícula o número de nómina y una contraseña ingresa al sistema

Ver catálogo
U1, U2, U3, U4
Una vez dentro del sistema el usuario podrá ver el contenido del catálogo

Buscar libro
U1, U2, U3, U4
El usuario introduce los  datos del libro a buscar
Ver catálogo
Ver bibliografía
U1, U2, U3, U4
El usuario podrá ver datos como: nombre del libro, autor, edición, editorial, número de páginas, etc.
Ver catálogo
Ver imagen
U1, U2, U3, U4
El usuario verá la imagen del libro (si ésta existe).
Ver catálogo
Ver disponibilidad
U1, U2, U3, U4
El usuario podrá ver si el libro está: prestado, en reparación, apartado, etc.
Ver catálogo
Pedir prestado
U1, U2, U3, U4
El usuario pide el libro para consulta externa (siempre y cuando este disponible).
Ver disponibilidad
Actualizar estado del libro
Administrador
El administrador actualiza el estado del libro cada vez que éste no se encuentre disponible.
Ver disponibilidad
Salir del sistema
U1, U2, U3, U4
El usuario después de checar el libro, sale del sistema.



Clases.


Usuario.
Atributos: Nombre, contraseña, tipo de usuario.
Métodos: Ingresar al sistema, Ver catálogo, Pedir libro, Salir del sistema.


Libro.
Atributos: Número de libros, Imagen, Tamaño del libro, Disponibilidad.
Métodos: Ver disponibilidad, Ver bibliografía, Consultar.


Préstamo:
Atributos: Préstamo interno, Préstamo externo, Tiempo del préstamo.
Métodos: Aceptar el préstamo, Ver tiempo, Regresar libro.


Catálogo.
Atributos: Tamaño del catálogo, Idioma.
Métodos: Buscar libro, Ver información del libro, Seleccionar idioma.




Relaciones de herencia.


Usuario.

  • Alumno
    • Licenciatura (U1).
    • Maestría (U2).
    • Doctorado (U3).
  • Empleado.
    • Maestro (U4).
Préstamo.
  • Interno.
    • Licenciatura.
    • Maestría.
    • Doctorado.
    • Maestro.
  • Externo.
    • Licenciatura.
    • Maestría.
    • Doctorado.
    • Maestro.

Ejercicio 2 - Conceptos.

UML.
Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad, es un lenguaje de modelado para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir.


OOP.
La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de programación que usa objetos y sus interacciones, para diseñar aplicaciones y programas informáticos. 
Está basado en varias técnicas: 

  • Herencia.
  • Abstracción.
  • Polimorfismo.
  • Encapsulamiento.

OOSAD.
Object - Oriented Systems Analysis and Design, modela un sistema mediante un grupo de objetos interactivos. Cada objeto representa una entidad de interés en el sistema y que se caracteriza pos su clase, estado (elementos de datos) y su comportamiento.


OMG.
El Grupo de Gestión de Objetos (de sus siglas en ingles, Object Management Group), es un consorcio dedicado al cuidado y el establecimiento de diversos estándares de tecnologías orientadas a objetos, tales como UML, XMI, CORBA. Es una organización sin ánimo de lucro que promueve el uso de tecnología orientada a objetos mediante guías y especificaciones para las mismas. El grupo está formado por diversas compañias y organizaciones con distintos privilegios dentro de la misma.
Algunos miembros:
  • HSBC.
  • IBM.
  • Microsoft Corporation.
  • Eclipse Foundation.

OOSE.
Object-Oriented Software Engineering (OOSE), es una técnica de diseño software que se utiliza en el diseño de software de programación orientada a objetos. OOSE es desarrollado por Ivar Jacobson en 1992. OOSE es la primera metodología orientada a objetos de diseño que emplea a los casos de uso en el diseño de software.OOSE es uno de los precursores del Lenguaje de Modelado Unificado (UML), comoBooch y OMT. Se incluyen los requerimientos, el análisis, el diseño, implementación y un modelo de prueba.


Referencias:

Ejercicio 1 - Relaciones de herencia.

SIASE


Usuario.

  • Alumno.
  • Maestro.
Encuestas.
  • DEL.
  • Verano.
Formatos de pago.
  • Cuota interna.
  • Cuota rectoría.
Inscripción.
  • Ordinario.
  • Laboratorio.
  • Posgrado.

miércoles, 31 de agosto de 2011

La crisis del software.

Propiamente la crisis del software se detecto en la década de los 60's, y desde 1968 se empezó a utilizar este término, en la primera conferencia organizada por la OTAN sobre desarrollo de software, así mismo, se utilizó por primera vez el término ingeniería del software para describir el conjunto de conocimientos que existían en aquel estado inicial. En la siguiente imagen veremos la evolución del software y la aparición de la crisis del software.


Definición: Es el hecho de que el software que se construye no solamente no satisface los requerimientos ni las necesidades pedidos por el cliente, sino que además excede los presupuestos y los horarios de tiempos.


A raíz de la crisis del software los científicos se dieron cuenta de la necesidad de desarrollar mejores técnicas para un sólido y métodico desarrollo de software que garantice su calidad en términos de estabilidad, robustez, funcionalidad. 


Causas de la crisis del software.

  • Requerimientos sin fin, Cambios continuos y descontrolados.
  • Cronogramas arbitrarios.
  • Insuficiente tiempo para probar.
  • Entrenamiento inadecuado.
  • Estándares fuera de control.
  • Tecnología.
Como se ve, si nosotros iniciamos con requerimientos que no tienen fin o estamos  cambiando a cada rato de requerimientos, lo más seguro es que el tiempo se nos venga ensima, y así habrá menos tiempo para probar el producto, que en la mayoría de los casos esto es lo que ocasiona que el  producto que se venda salga con fallas, al igual que si se pone a personal que no esta previamente capacitado en el tema, o las normas que se deben de seguir no son las mas adecuadas, o las herramientas tecnológicas que se están usando son muy obsoletas o no son las adecuadas para ese proyecto, propician que el producto a entregar salga con muchas fallas.


Como ejemplo de la crisis del software, citare el sistema operativo Windows Vista.



La gran mayoría de nosotros manejamos cualquier sistema operativo de la familia Windows, inclusive hubo personas de nuestra generación que llegaron a utilizar una versión anterior a Windows 2000.
El sistema operativo que mas agrado a la mayoría de los usuarios de Windows fue el Windows XP, porque era muy cómodo, sin embargo, los avances en el desarrollo de software se san día con día, lo que sucedió con este sistema operativo es que se volvió "obsoleto" y es así que sale al mercado Windows Vista. Para los usuarios en un principio, esto significaría mejores cosas en su interfaz, en programas, etc., pero la verdad es que este sistema operativo en sus inicios tuvo muchas fallas, como que no admitía la instalación de ciertos programas, o que requería estar en constante actualización, por mencionar solo algunas. Es por eso que este es el sistema operativo que menos se utiliza de la familia Windows, las causas posiblemente fueron una mala planeación al inicio o el tiempo de entrega se les vino ensima.


Otro caso soprendente es el del accidente del vuelo 603 de Aeroperú del 2 de octubre de 1996, producido porque el sistema informático del avión (un Boeing 757) se volvió loco a causa de la obstrucción de uno de los juegos de puertos estáticos que miden la presión atmosférica para calcular la altura y velocidad del avión: en lugar de indicar que había una discrepancia entre los datos que proporcionaban los puertos estáticos de la intrumentación del capitán y los del copiloto, el sistema a ratos no daba datos y a ratos daba datos incorrectos, llegando  a dar a la vez alarmas de exceso de velocidad y de peligro de entrada en pérdida por ir demasiado despacio, lo que evidentemente no puede suceder a la vez. Dado que el vuelo era de noche y al no poder confiar en sus instrumentos, los pilotos estaban a todos los efectos volando a ciegas por lo que terminaron por chocar con el mar cuando intentaban volver al aeropuerto y creían estar volando a una altura segura.


Es por eso que al momento en que vamos a desarrollar un software, necesitamos analizar muy bien que es lo que vamos a crear y tomar en cuenta cuales son los requerimientos del cliente.


Referencias:
http://www.itlalaguna.edu.mx/academico/carreras/sistemas/ingsofware1/Unidad1.pdf
http://sitiopoo.galeon.com/crisis.html
http://www.informatizate.net/index.php?option=com_content&view=article&id=67%3Acomo-desarrollar-software-y-no-morir-en-el-intento&catid=36%3AArt%C3%ADculos+de+Miembros+de+informatizate&Itemid=62&limitstart=4
http://www.microsiervos.com/archivo/ordenadores/software-fuera-de-control.html
http://www.microsiervos.com/archivo/ordenadores/software-fuera-de-control.html
http://www.lawebdelpiloto.com/2011_05_08_archive.html

Metodologías de diseño de software.

Primero empezaremos por definir lo que es una metodología.


Metodología: Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software.



La metodología indica cómo hay que obtener los distintos productos parciales y finales.


Existen tres generaciones de metodologías:

  • Desarrollo Convencional (Sin Metodología) .
  • Desarrollo Estructurado.
  • Desarrollo Orientado a Objetos.
A continuación veremos las características de cada una de ellas:


Desarrollo Convencional.
  • Los resultados finales son impredecibles.
  • No hay forma de controlar lo que está sucediendo en el proyecto.
  • Los cambios organizativos afectan negativamente al proceso de desarrollo.
Con este tipo de desarrollo sin metodología, uno de los principales riesgos que se corre es que el software no funcione adecuadamente o definitivamente no funcione, haciendo que el se le entregue un producto que no sirve al cliente o en el peor caso no entregar el producto final.


Desarrollo Estructurado.
  • Programación estructurada.
  • Diseño estructurado.
  • Análisis estructurado.
Con este tipo de desarrollo el software será mejor de lo que se esperaba con el anterior desarrollo, ya que al ser todo estructurado se tiene un mejor control de las cosas,por lo cual hace mas completo el desarrollo del software y el producto final será de mejor calidad que uno que no tiene una metodología.


Desarrollo Orientado a Objetos.
  • Se eliminan las fronteras entre las fases, debido a la naturaleza iterativa del desarrollo OO.
  • Aparece una nueva manera de concebir los lenguajes de programación, al incorporarse bibliotecas de clases y otros componentes reutilizables.
  • Hay un grado alto de iteración y soplamiento, lo que lleva a una forma de trabajo muy dinámica.

La esencia del desarrollo orientado a objetos  es la identificación y organización de conceptos del dominio de la aplicación y no tanto de su representación final en un lenguaje de programación.

Entre las características deseables de toda metodología están:
  • Existencia de reglas predefinidas.
  • Cobertura total del ciclo de desarrollo.
  • Verificaciones intermedias.
  • Planificación y control.
  • Comunicación efectiva.
  • Utilización sobre un abanico amplio de proyectos.
  • Fácil información.
  • Herramientas CASE.
  • Actividades que mejoran el proceso de desarrollo.
  • Soporte al mantenimiento.
  • Soporte de la reutilización del software.

Existen tres tipos de metodologías:
  • Estructuradas: Se definen primero las estructuras de datos de entrada y salida.
  • Orientadas a objetos: Pueden ser de dos tipos, revolucionarios o puros, y sintetistas o evolutivos.
  • Para sistemas en tiempo real: En este tipo de metodología, al ser en tiempo real, trata de hacer las tareas sincronizadas, poder reaccionar cuando se presente algún evento externo y manejar datos continuos o discretos, entre otras cosas.
Las fases de la metodología son:

Requisitos: Los requisitos son una lista de cosas que queremos que haga nuestro programa. 

Análisis: Definir más claramente qué es lo que va a hacer nuestro programa. Durante el análisis debemos de hacer varias cosas como:
  • Identificar actores: Usuarios y/o sistemas con los que se comunica nuestro programa.
  • Identificar casos de uso: Un caso de uso es algo que un actor quiere hacer con nuestro programa.
  • Detallar los casos de uso: Describir mas a fondo los casos de uso.
  • Diagrama de clases: Es un diagrama de clases de objetos que tienen sentido para el usuario.
Diseño preliminar: En esta etapa, vamos a pensar en como se van a hacer las cosas, tratando de establecer la arquitectura de nuestro programa.

Diseño detallado: En este tipo de diseño ya nos enfocamos a las clases y a los métodos.

Implementación y pruebas: Como su nombre lo indica aquí vamos a ponernos a trabajar nuestro programa, es decir, la codificación, una vez terminada esta fase es necesario hacer varias pruebas, en caso de algún error hay que ver en que nos equivocamos con anterioridad y corregirlo de inmediato.

Referencias: