COLEGIO DE BACHILLERES

PLANTEL No.6 “VICENTE GUERRERO” ACADEMIA TIC ASIGNATURA: SOLUCIONES INFORMÁTICAS EN LENGUAJE POO

GUÍA DE ESTUDIO PROFR. OMAR RAMIREZ HERNÁNDEZ

Diciembre 2011

Programador de Sistemas de Cómputo Soluciones Informáticas en un Lenguaje POO

Enfoque

La Informática desde inicios del siglo XXI ha sido una herramienta sustancial para la operación de

las organizaciones, ya que busca aprovechar la capacidad tecnológica para el desarrollo de los

proyectos, administrar los riesgos y lograr ventajas competitivas. El personal en informática debe

aprovechar los recursos tecnológicos para efectuar una gestión inteligente de los riesgos en cada

una de las operaciones de la organización, a través de lograr la colaboración, el consenso, la

comunicación y el trabajo en equipo; con una visión más creativa, proactiva, innovadora y

estratégica que genere valor y mejora competitiva en las empresas.

Competencias

Introducción

El colegio de bachilleres con el Modelo Académico del Colegio de Bachilleres, el

Área de Formación Laboral: contribuye en el proyecto de construcción de vida del

estudiante en el ámbito de lo laboral, a través de situaciones que le permitan

adquirir conocimientos, habilidades, actitudes y destrezas para producir algún bien

o servicio, satisfaciendo sus necesidades materiales y existenciales, que

posibiliten su transformación como sujeto individual y social, en el momento

histórico y cultural en el que vive; fortaleciendo la capacidad de ingresar,

mantenerse y progresar exitosamente en el mundo laboral. Dicha área se organiza

en grupos ocupacionales, que dan cuenta de diversas salidas ocupacionales, las

que se logran a través de módulos de aprendizaje.

De esta forma, la salida ocupacional Programador de Sistemas de Cómputo se

ubica en el Grupo Ocupacional Informática, tiene como Estándares de

Referencia a las Normas: OMG Certified UML Professional nivel fundamental e

intermedio de la Object Management Group; NCL: CINF0669.01 Programación,

desarrollo y diseño de soluciones en JAVA (Norma Técnica del CONOCER);

Certificación en: SCJA Sun Certified JAVA Associate "Certificación básica en

plataforma JAVA" (Estándar de Sun), Certificación en: SCJP Sun Certified JAVA

programmer "Programador Certificado en Plataforma JAVA"(Estándar de Sun) y la

norma española Programación con lenguajes orientados a objetos y bases de

datos relacionales (IFC080_3).

Programa de la asignatura

Bloque I. Programar los componentes de la solución informática en JAVA

Fase 1.Verificar que los componentes de la solución informática cumplan con las

especificaciones del diseño y los niveles de calidad establecidos.

Fase 2.Desarrollar clases aplicando los fundamentos del Paradigma Orientado a

Objetos.

Fase 3.Elaborar la documentación completa relativa a las clases desarrolladas y

pruebas.

Fase 4. Realizar pruebas para verificar y corregir las clases desarrolladas.

Fase 5. Modificar las clases existentes por cambios de especificaciones.

Bloque II. Manipular base de datos relacionales mediante el uso de un

Sistema Gestor de Base de Datos (SGBD) y JAVA.

Fase 6. Seleccionar el SGBD más adecuado para la solución informática.

Fase 7. Realizar consultas a la base de datos para la toma de decisiones.

Bloque III. Desarrollar interfaces de usuario en JAVA.

Fase 8. Diseño de la interfaz gráfica a partir del diseño detallado.

Fase 9. Construir una aplicación con interfaz de usuario a partir del código

generado por una herramienta de interfaz gráfica IDE: NetBeans.

Fase 10. Validación y finalización del desarrollo de la aplicación para su entrega

con el cliente.

Problemática

El estacionamiento “Hay lugar” ubicado en el centro de la Ciudad de México, cobra por la primera hora o fracción $16.00 y por cada 15 minutos después de la primera hora $4.00. El estacionamiento cuenta con cuatro niveles con 40 cajones cada uno, 20 acomodadores y un administrador. Al momento que llega un vehículo lo recibe un acomodador quien registra la marca, modelo, color, placas y estado de éste, así como el número de boleto secuencial y su número de acomodador para cualquier aclaración. El administrador revisa los cajones en una tabla y le indica al acomodador, el cajón disponible para estacionar el vehículo y le solicita el número de boleto de estacionamiento y anota la fecha y hora de entrada. Al momento que el cliente regresa por su vehículo, entrega el boleto al administrador y éste registra la hora de salida, calcula la cantidad a pagar y despacha a algún acomodador disponible para que traiga el vehículo. Una vez entregado el vehículo, el administrador anota el número del acomodador para cualquier aclaración y marca disponible el cajón desocupado en su tabla. Cada semana se requiere un informe en el que se identifique a los 5

acomodadores que más trabajaron, a partir de contar los servicios realizados

(estacionamiento y entrega de automóvil), con la intención de abonarles el 10% de

su pago semanal. Dicho informe debe contener los siguientes datos: nombre,

número del acomodador, cantidad de servicios efectuados por día y por semana,

sueldo y cantidad adicional a pagar.

Bloque I. Programar los componentes de la solución informática en JAVA

Propósito: Que el estudiante desarrolle la programación de las clases, mediante

el lenguaje de programación orientado a objetos JAVA, para resolver las

necesidades del cliente.

Preguntas detonadoras

¿Cuál es el modelo de solución del sistema? ¿Qué lenguaje de programación se utilizará? ¿Qué clases a primera instancia reconoces? ¿Cuáles son los atributos de dichas clases? ¿Qué relación existe entre una clase y un objeto? ¿Dónde registro la información desarrollada de las clases? ¿Cómo sé si mi programa da respuesta a las necesidades del cliente? ¿Qué ambiente de desarrollo de programación necesito?

Núcleo Temático a) Interpretación del modelo de la solución informática en UML. UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas. • Diagramas de Casos de Uso para modelar los procesos ’business’. Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. Componentes:

Por ejemplo:

• Diagramas de Secuencia para modelar el paso de mensajes entre objetos. Muestran objetos o clases y mensajes entre ellos. Componentes: Línea de Vida: Representa la existencia de un objeto a lo largo de un período de tiempo. Foco de control: Representa el período de tiempo durante el cual el objeto ejecuta una acción. Ejemplo:

• Diagramas de Colaboración para modelar interacciones entre objetos. Un diagrama de colaboración es una forma de representar interacción entre objetos, alterna al diagrama de secuencia.

Elementos:

Objeto

Enlaces

Flujo de mensajes

Marcadores de creación y destrucción de objetos

Objeto compuesto

• Diagramas de Estado para modelar el comportamiento de los objetos en el sistema. Los diagramas de estado muestran el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación en respuesta a eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones. Eventos Acciones Actividades Estados Ejemplo:

• Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.

El Diagrama de Actividad es un diagrama de flujo del proceso multi-propósito que se usa para modelar el comportamiento del sistema. Los diagramas de actividad se pueden usar para modelar un Caso de Uso, o una clase, o un método complicado.

Representa el comportamiento interno de una operación o de un caso de uso.

El propósito del diagrama de actividad es:

Modelar el flujo de tareas.

Modelar las operaciones.

• Diagramas de Clases para modelar la estructura estática de las clases en el sistema. Se utilizan para modelar la visión estática de un sistema. Esta visión soporta los requisitos funcionales del sistema, en concreto, los servicios que el sistema debería proporcionar a sus usuarios finales.

• Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema. Está relacionado de cerca con un diagrama de Clases, con la diferencia de que éste describe las instancias de los objetos de clases en un punto en el tiempo. Esto podría parecer similar al diagrama de Estructura Compuesta, que modela el comportamiento en tiempo de ejecución; la diferencia es que el diagrama de

Objetos ejemplifica al diagrama de Clases estático, mientras que los diagramas de Estructura Compuesta refleja las arquitecturas diferentes de sus contrapartes estáticas

El siguiente ejemplo primero muestra un diagrama de Clases simple, con dos elementos clase conectados.

Las clases de arriba se instancian abajo como objetos en un diagrama de Objetos. Hay dos instancias de Computadora en este modelo, lo que puede probar su utilidad por considerar las relaciones y las interacciones que las clases juegan en la práctica, como objetos.

• Diagramas de Componentes para modelar componentes. Este ilustra los fragmentos de software, controladores embebidos, etc. que conformarán un sistema. Un diagrama de componentes tiene un nivel de abstracción más elevado que un diagrama de clase.

El siguiente diagrama muestra algunos componentes y sus relaciones internas. Los conectores emsamble "vinculan" las interfaces proporcionadas suministrada por Producto y Cliente a las interfaces requeridas especificadas por Orden. Una relación de dependencia asigna los detalles de cuenta asociados del cliente a la interfaz requerida, "pago", indicado por Orden.

• Diagramas de Implementación para modelar la distribución del sistema. Un diagrama de implementación muestra la estructura del código (Diagrama de componentes) y la estructura del sistema en ejecución (Diagrama de ejecución). UML tiene dos tipos de diagramas de implementación Diagramas de Componentes

Muestran la estructura del código fuente

Se corresponden con Categorias de clases en Booch Paquetes de UML Diagramas de Módulos en Booch

– Diagramas Desplegables (Deployment Diagrams)

Muestran la estructura del sistema en tiempo de ejecución

Se corresponden con los Diagramas de Procesos de Booch b) Fundamentos de la Programación orientada a objetos en Java.

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, incluyendo herencia, abstracción, polimorfismo y encapsulamiento. Su uso se popularizó a principios de la década de los años 1990. En la actualidad, existe variedad de lenguajes de programación que soportan la orientación a objetos.

La POO es una técnica para desarrollar soluciones computacionales utilizando componentes de software (objetos de software).

Los objetos son entidades que tienen un determinado estado, comportamiento (método) e identidad:

El estado está compuesto de datos, será uno o varios atributos a los que se habrán asignado unos valores concretos (datos).

El comportamiento está definido por los métodos o mensajes a los que sabe responder dicho objeto, es decir, qué operaciones se pueden realizar con él.

La identidad es una propiedad de un objeto que lo diferencia del resto, dicho con otras palabras, es su identificador (concepto análogo al de identificador de una variable o una constante).

Conceptos fundamentales

Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas.

Herencia: (por ejemplo, herencia de la clase C a la clase D) Es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos métodos y variables publicas declaradas en C. Los componentes registrados como "privados" (private) también se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y sólo pueden ser accedidos a través de otros métodos públicos. Esto es así para mantener hegemónico el ideal de OOP.

Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos) los mismos que consecuentemente reaccionan a eventos. Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase.

Método: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la

generación de un "evento" con un nuevo mensaje para otro objeto del sistema.

Evento: Es un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. También se puede definir como evento, a la reacción que puede desencadenar un objeto, es decir la acción que genera.

Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó.

Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.

Características de la POO

Abstracción: denota las características esenciales de un objeto, donde se capturan sus comportamientos.Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción.El proceso de abstracción permite seleccionar las características relevantes dentro de un conjunto e identificar comportamientos comunes para definir nuevos tipos de entidades en el mundo real. La abstracción es clave en el proceso de análisis y diseño orientado a objetos, ya que mediante ella podemos llegar a armar un conjunto de clases que permitan modelar la realidad o el problema que se quiere atacar.

Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente.

Modularidad: Se denomina Modularidad a la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes. Estos módulos se pueden compilar por separado, pero tienen conexiones con otros módulos. Al igual que la encapsulación, los lenguajes soportan la Modularidad de diversas formas.

Principio de ocultación: Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos

que especifica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos.

Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.

Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple.

Recolección de basura: la recolección de basura o garbage collector es la técnica por la cual el entorno de objetos se encarga de destruir automáticamente, y por tanto desvincular la memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el programador no debe preocuparse por la asignación o liberación de memoria, ya que el entorno la asignará al crear un nuevo objeto y la liberará cuando nadie lo esté usando. En la mayoría de los lenguajes híbridos que se extendieron para soportar el Paradigma de Programación Orientada a Objetos como C++ u Object Pascal, esta característica no existe y la memoria debe desasignarse manualmente.

c) Relación clases y objetos.

Una clase es un conjunto de objetos que comparten una estructura y comportamiento comunes.

Clase representa una abstracción, la esencia que comparten los objetos. Un objeto es un ejemplo de una clase. Un objeto no es una clase, y una clase no es un objeto (aunque puede

serlo, p.e. en Smalltalk). Las clases actuan como intermediarias entre una abstracción y los clientes

que pretenden utilizar la abstracción. De esta forma, la clase muestra: 1. visión externa de comportamiento (interface), que enfatiza la

abstracción escondiendo su estructura y secretos de comportamiento.

2. visión interna (implementación), que abarca el código que se ofrece en la interface de la clase

Relaciones entre clases

Representan tipos de compartición entre clases, o relaciones semánticas.

1. Asociación. Indica relaciones de mandato bidireccionales (Punteros ocultos en C++). Conlleva dependencia semántica y no establece una dirección de dependencia. Tienen cardinalidad.

2. Herencia. Por esta relación una clase (subclase) comparte la estructura y/o comportamiento definidos en una (herencia simple) o más (herencia múltiple) clases, llamadas superclases.

o Representa una relación del tipo "es un" entre clases. o Una subclase aumenta o restringe el comportamiento o estructura de

la superclase (o ambas cosas). o Una clase de la que no existen ejemplos se denomina {\it abstracta}. o C++ declara como virtuales todas aquellas funciones que quiere

modificar en sus subclases. 3. Agregación. Representa una relación del tipo "tener un" entre clases.

Cuando la clase contenida no existe independientemente de la clase que la contiene se denomina agregación por valor y además implica contenido físico, mientras que si existe independientemente y se accede a ella indirectamente, es agregación por referencia.

4. Uso. Es un refinamiento de la asociación donde se especifica cual es el cliente y cual el servidor de ciertos servicios, permitiendo a los clientes acceder sólo a las interfaces públicas de los servidores, ofreciendo mayor encapsulación de la información.

5. Ejemplificación Se usa en lenguajes que soportan genericidad (declaración de clases parametrizadas y argumentos tipo template). Representa las relaciones entre las clases parametrizadas, que admiten parámetros formales, y las clases obtenidas cuando se concretan estos parámetros formales, ejemplificados o inicializados con un ejemplo.

6. Metaclases Son clases cuyos ejemplos son a su vez clases.

Todo objeto es el ejemplo de una clase, y toda clase tiene 0 ó más objetos.

Mientras las clases son estáticas, con semántica, relaciones y existencia fijas previamente a la ejecución de un programa, los objetos se crean y destruyen rápidamente durante la actividad de una aplicación.

d) Codificación de las clases utilizando el IDE Java NetBeans 6.9.

NetBeans es un entorno de desarrollo integrado libre, hecho principalmente para el lenguaje de programación Java. Existe además un número importante de módulos para extenderlo. NetBeans IDE es un producto libre y gratuito sin restricciones de uso.

NetBeans es un proyecto de código abierto de gran éxito con una gran base de usuarios, una comunidad en constante crecimiento, y con cerca de 100 socios en todo el mundo. Sun MicroSystems fundó el proyecto de código abierto NetBeans en junio de 2000 y continúa siendo el patrocinador principal de los proyectos.

Con respecto a una problemática dada y el diseño de los diagramas UML, se tiene una Clase

Automóvil

+ Marca + Modelo + Año + Estado

- Arrancar()

A través de está Clase es posible realizar la programación Java en NetBeans e) Documentación de las clases. Documentar el código de un programa es añadir suficiente información como para explicar lo que hace, punto por punto, de forma que no sólo los ordenadores sepan qué hacer, sino que además los humanos entiendan qué están haciendo y por qué.

Porque entre lo que tiene que hacer un programa y cómo lo hace hay una distancia impresionante: todas las horas que el programador ha dedicado a pergeñar una solución y escribirla en el lenguaje que corresponda para que el ordenador la ejecute ciegamente.

Documentar un programa no es sólo un acto de buen hacer del programador por aquello de dejar la obra rematada. Es además una necesidad que sólo se aprecia en su debida magnitud cuando hay errores que reparar o hay que extender el programa con nuevas capacidades o adaptarlo a un nuevo escenario. Hay dos reglas que no se deben olvidar nunca:

1. todos los programas tienen errores y descubrirlos sólo es cuestión de tiempo y de que el programa tenga éxito y se utilice frecuentemente

2. todos los programas sufren modificaciones a lo largo de su vida, al menos todos aquellos que tienen éxito

Por una u otra razón, todo programa que tenga éxito será modificado en el futuro, bien por el programador original, bien por otro programador que le sustituya. Pensando en esta revisión de código es por lo que es importante que el programa se entienda: para poder repararlo y modificarlo.

¿Qué hay que documentar?

¿de qué se encarga una clase? ¿un paquete? ¿qué hace un método? ¿cuál es el uso esperado de un método? ¿para qué se usa una variable? ¿cuál es el uso esperado de una variable? ¿qué algoritmo estamos usando? ¿de dónde lo hemos sacado? ¿qué limitaciones tiene el algoritmo? ¿... la implementación? ¿qué se debería mejorar ... si hubiera tiempo?

En Java disponemos de tres notaciones para introducir comentarios: javadoc Comienzan con los caracteres "/**", se pueden prolongar a lo largo de varias líneas (que probablemente comiencen con el carácter "*") y terminan con los caracteres "*/". una línea Comienzan con los caracteres "//" y terminan con la línea f) Pruebas del sistema. Las pruebas de sistema tienen como objetivo ejercitar profundamente el sistema comprobando la integración del sistema de información globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica.

Las pruebas de software, en inglés testing son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación, calidad, o usabilidad de un programa de ordenador o videojuego. Básicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas.

Las pruebas de software se integran dentro de las diferentes fases del ciclo del software dentro de la Ingeniería de software. Así se ejecuta un programa y mediante técnicas experimentales se trata de descubrir que errores tiene.

g) Corrección de errores en las clases y en la documentación.

Actividades

1. Recuperar los diagramas vistos en el Módulo anterior Modelado de Sistemas.

2. Verificar que los componentes de la solución informática cumplan con las

especificaciones del diseño y los niveles de calidad establecidos.

3. Desarrollar clases aplicando los fundamentos del Paradigma Orientado a

Objetos.

4. Elaborar la documentación completa relativa a las clases desarrolladas y

pruebas.

5. Realizar pruebas para verificar y corregir las clases desarrolladas.

6. Modificar las clases existentes por cambios de especificaciones

Lista de Cotejo

COLEGIO DE BACHILERES

Soluciones_Informáticas_en_Lenguaje_POO

EVALUACIÓN DEL NÚCLEO TEMÁTICO I “Programar los componentes de la solución

informática en JAVA”

NOMBRE: FECHA

No.

Indicador

SI

NO

Observaciones

1 Verificaste que los componentes de la solución

informática cumplan con las especificaciones del

diseño y los niveles de calidad establecidos.

2 Desarrollaste clases aplicando los fundamentos del

Paradigma Orientado a Objetos.

3 Elaboraste la documentación completa relativa a las

clases desarrolladas y pruebas.

4 Realizaste pruebas para verificar y corregir las clases

desarrolladas.

5 Modificaste las clases existentes por cambios de

especificaciones

BLOQUE II. Administrar base de datos relacionales mediante el uso de un Sistema Gestor de Base de Datos (SGBD) y JAVA. Propósito: Que el estudiante realice la administración de base de datos relacionales, mediante la selección del SGBD más adecuado para la solución informática y la realización de consultas a la base de datos para la toma de decisiones. Preguntas detonadoras ¿Qué es una base de datos? ¿Qué es una base de datos relacional? ¿Qué es un SGBD? ¿Qué criterios considerar para seleccionar el SGDB? ¿Cómo relacionar las clases con la base de datos? ¿Cómo utilizar el SGDB? ¿Cómo diseñar consultas y reportes utilizando el SGBD?

Núcleo Temático a) Concepto de base de datos relacionales. El Dr. Edgar Frank Codd propuso que los sistemas de bases de datos deberían presentarse a los usuarios con una visión de los datos organizados en estructuras llamadas relaciones, definidas como conjuntos de tuplas (filas) y no como series o secuencias de objetos, con lo que el orden no es importante. Por tanto, detrás de una relación puede haber cualquier estructura de datos compleja que permita una respuesta rápida a una variedad de consultas. Una base de datos relaciona1 almacena los datos en un conjunto de tablas relacionadas; cada una es una secuencia O lista de registros. Todos los registros en la tabla son del mismo tipo. Cada fila de la tabla es equivalente a un registro y se le denomina tupla. Cada columna de la tabla es equivalente a un campo, que por lo general se llama atributo. En 1985 Codd publicó sus famosas 12 reglas sobre el modelo relacional de bases de datos, un resumen de sus características fundamentales. La estructura fundamental del modelo relacional es la relación, es decir una tabla bidimensional constituida por filas (tuplas) y columnas (atributos). Las relaciones representan las entidades que se consideran interesantes en la base de datos. Cada instancia de la entidad encontrará sitio en una tupla de la relación, mientras que los atributos de la relación representan las propiedades de la entidad. Por ejemplo, si en la base de datos se tienen que representar personas, podrá definirse una relación llamada "Personas", cuyos atributos describen las características de las personas. Cada tupla de la relación "Personas" representará una persona concreta. Por ejemplo, la relación: Personas (RFC, nombre, apellido, sexo, estadoCivil, fechaNacimiento) es apenas una definición de la estructura de la tabla, es decir su nombre y la lista de atributos que la componen. Si esta estructura se puebla con datos, entonces tendremos una lista de valores individuales para cada tupla, atributo por atributo. b) Uso del Sistema Gestor de Base de Datos.

Un Sistema Gestor de base de datos (SGBD) es un conjunto de programas que permiten crear y mantener una Base de datos, asegurando su integridad, confidencialidad y seguridad. Por tanto debe permitir:

- Definir una base de datos: especificar tipos, estructuras y restricciones de datos..

- Construir la base de datos: guardar los datos en algún medio controlado por el mismo SGBD

- Manipular la base de datos: realizar consultas, actualizarla, generar informes.

Así se trata de un software de propósito general. Ejemplo de SGBD son Oracle y SQL Server de Microsoft .

Algunas de las características deseables en un Sistema Gestor de base de datos SGBD son:

- Control de la redundancia: La redundancia de datos tiene varios efectos negativos (duplicar el trabajo al actualizar, deperdicia espacio en disco, puede provocar inconsistencia de datos) aunque a veces es deseable por cuestiones de rendimiento.

- Restricción de los accesos no autorizados: cada usuario ha de tener unos permisos de acceso y autorización.

- Cumplimiento de las restricciones de integridad: el SGBD ha de ofrecer recursos para definir y garantizar el cumplimiento de las restricciones de integridad.

c) Relación entre las clases y el SGBD. El modelo de datos orientado a objetos es una extensión del paradigma de programación orientado a objetos. Los objetos entidad que se utilizan en los programas orientados a objetos son análogos a las entidades que se utilizan en las bases de datos orientadas a objetos puras, pero con una gran diferencia: los objetos del programa desaparecen cuando el programa termina su ejecución, mientras que los objetos de la base de datos permanecen. A esto se le denomina persistencia. Las bases de datos relacionales representan las relaciones mediante las claves ajenas. No tienen estructuras de datos que formen parte de la base de datos y que representen estos enlaces entre tablas. Las relaciones se utilizan para hacer concatenaciones (join) de tablas. Por el contrario, las bases de datos orientadas a objetos implementan sus relaciones incluyendo en cada objeto los identificadores de los objetos con los que se relaciona. Para garantizar la integridad de esta relación, un SGBD orientado a objetos puro deberá permitir que el diseñador de la base de datos pueda especificar donde debe aparecer el identificador del objeto inverso, como por ejemplo: relationship set<Obra> supervisa inverse Obra::es supervisada en la clase Aparejador y:

relationship Aparejador es supervisada inverse Aparejador::supervisa en la clase Obra. d) Diseño de consultas y reportes. Un generador de reportes es una herramienta de software que ofrece la posibilidad de crear plantillas de reportes para una base de datos. Aunque los usuarios finales también pueden utilizar los generadores de reportes, por lo general los diseñadores de la base de datos los emplean. Una plantilla para reportes contiene el resumen o las especificaciones generales para generar un reporte, lo que incluye elementos como título del reporte, los campos que deben incluirse, los campos para subtotalizar o totalizar y las especificaciones para el formato del reporte. Sin embargo, la plantilla no contiene los datos de la base de datos. Los datos se incluyen en la plantilla al generar el reporte. El diseñador de la base de datos puede crear.plantillas para reportes que presenten efectivamente la información de acuerdo con los siguientes lineamientos: Proporcionar solamente la información requerida. Demasiada información hará difícil identificar lo que realmente es esencial. Presentar la información en un formato utilizable. Por ejemplo, si se necesitan subtotales para tomar una decisión, entonces habrá que incluirlos. La gente que utiliza los reportes no debe efec~uarc álculos manuales adicionales. Presentar información oportuna. Los reportes tienen que llegar a tiempo para que puedan utilizarse y tomar decisiones efectivas. Algunas decisiones exigen información periódica (por ejemplo, los reportes de ventas mensuales); otras exigen información "continua", como los precios actuales de las acciones, la cual sería mejor colocarla en un desplegado continuo. Presentar la información en un formato claro y sin ambigüedades e incluir títulos, números de página, fechas, etiquetas y encabezados de columna necesarios. Presentar la información en el formato más apropiado para el usuario. En muchos casos un reporte tradicional organizado por filas y columnas es el más apropiado; en otros los gráficos pueden ser más efectivos. e) Pruebas de la consistencia de la base de datos.

Una base de datos está en un estado consistente si obedece todas las

restricciones de integridad (significa que cuando un registro en una tabla haga

referencia a un registro en otra tabla, el registro correspondientes debe existir)

definidas sobre ella.

Los cambios de estado ocurren debido a actualizaciones, inserciones y

supresiones de información. Por supuesto, se quiere asegurar que la base de

datos nunca entre en un estado de inconsistencia.

Sin embargo, durante la ejecución de una transacción, la base de datos puede

estar temporalmente en un estado inconsistente.

El punto importante aquí es asegurar que la base de datos regresa a un estado

consistente al fin de la ejecución de una transacción.

Actividades

1. Selecciona el SGBD más adecuado para la solución informática.

2. Crea la Base de datos relacional

3. Crea las Relaciones correspondientes

4. Realiza consultas a la base de datos para la toma de decisiones

5. Diseña Reportes y consultas a la Base de datos

6. Realiza las pruebas de consistencia en la Base de datos

Lista de Cotejo

COLEGIO DE BACHILERES

Soluciones_Informáticas_en_Lenguaje_POO

EVALUACIÓN DEL NÚCLEO TEMÁTICO II “Administrar base de datos relacionales mediante

el uso de un Sistema Gestor de Base de Datos (SGBD) y JAVA.”

NOMBRE: FECHA

No.

Indicador

SI

NO

Observaciones

1 Seleccionaste el SGBD más adecuado para la solución

informática.

2 Creaste la Base de datos relacional

3 Creaste las Relaciones correspondientes

4 Realizaste consultas a la base de datos para la toma

de decisiones

5 Diseñaste Reportes y consultas a la Base de datos

6 Realizaste las pruebas de consistencia en la Base de

datos

BLOQUE III. Desarrollar interfaces de usuario en JAVA. Propósito: Que el estudiante desarrolle interfaces de usuario en JAVA

apoyándose en la programación orientada a eventos y objetos.

Preguntas detonadoras

¿Qué se entiende por interfaz de usuario? ¿Cómo relacionamos un modelo de casos de uso desarrollado en UML con una Interfaz de Usuario? ¿Qué herramientas nos ofrece el lenguaje de programación orientado a objetos Java para desarrollar rápidamente y de la forma más simple una interfaz de usuario? ¿Qué diferencia hay entre la programación orientada a eventos y la programación orientada a objetos? ¿De qué herramientas se dispone en el IDE Java Netbeans para desarrollar programación orientada a eventos? ¿Cómo podemos cumplir con todos los requerimientos planteados por el usuario en el desarrollo de la aplicación?

Núcleo Temático a) Concepto de interfaz de usuario.

La interfaz de usuario es el medio con que el usuario puede comunicarse con una máquina, un equipo o una computadora, y comprende todos los puntos de contacto entre el usuario y el equipo. Normalmente suelen ser fáciles de entender y fáciles de accionar.

Las interfaces básicas de usuario son aquellas que incluyen elementos como menús, ventanas, teclado, ratón, los beeps y algunos otros sonidos que la computadora hace, y en general, todos aquellos canales por los cuales se permite la comunicación entre el ser humano y la computadora. La mejor interacción humano-máquina a través de una adecuada interfaz (Interfaz de Usuario), que le brinde tanto comodidad, como eficiencia.

Dentro de las Interfaces de Usuario se puede distinguir básicamente tres tipos: A) Una interfaz de hardware, a nivel de los dispositivos utilizados para ingresar, procesar y entregar los datos: teclado, ratón y pantalla visualizadora. B) Una interfaz de software, destinada a entregar información acerca de los procesos y herramientas de control, a través de lo que el usuario observa habitualmente en la pantalla. C) Una interfaz de Software-Hardware, que establece un puente entre la máquina y las personas, permite a la máquina entender la instrucción y a el hombre entender el código binario traducido a información legible.

b) Concepto de programación orientada a eventos.

La programación dirigida por eventos es un paradigma de programación en el que tanto la estructura como la ejecución de los programas van determinados por

los sucesos que ocurran en el sistema, definidos por el usuario o que ellos mismos provoquen.

Para entender la programación dirigida por eventos, podemos oponerla a lo que no es: mientras en la programación secuencial (o estructurada) es el programador el que define cuál va a ser el flujo del programa, en la programación dirigida por eventos será el propio usuario —o lo que sea que esté accionando el programa— el que dirija el flujo del programa. Aunque en la programación secuencial puede haber intervención de un agente externo al programa, estas intervenciones ocurrirán cuando el programador lo haya determinado, y no en cualquier momento como puede ser en el caso de la programación dirigida por eventos.

While (true){ Switch (event){ case mousse_button_down: case mouse_click: case keypressed: case Else: } } c) Relación entre un modelo desarrollado en UML y la interfaz de usuario. El intercambio de información de diseño e ideas usando la notación UML sería hecho en los medios que siempre han sido populares: Como una buena caja de herramientas, una buena herramienta de modelado ofrece todas las herramientas necesarias para conseguir hacer eficientemente varios trabajos, sin dejarte nunca sin la herramienta correcta. Dentro de la estructura de diseño de sistemas descrito en esta guía, esto incluye lo siguiente: Soporte para una cantidad considerable de técnicas de modelado y diagramas para complementar UML - incluyendo tarjetas CRC, modelado de datos, diagramas de flujo, y diseño de pantallas de usuario. Posibilidad de reutilizar información obtenida por otras ténicas todavía usadas, como modelado tradicional de procesos. e) Pruebas y corrección de errores en el código para la interfaz de usuario. f) Documentación técnica y manual de usuario de la aplicación llamada interfaz de

usuario.

Actividades

1. Diseñaste una interfaz de usuario acorde a las necesidades del cliente.

2. Generaste código orientado a eventos.

3. Empleaste las pruebas necesarias para corregir el código para la interfaz de

usuario

4. Elaboraste el Manual Técnico

5. Elaboraste el Manual del Usuario

Lista de Cotejo

COLEGIO DE BACHILERES

Soluciones_Informáticas_en_Lenguaje_POO

EVALUACIÓN DEL NÚCLEO TEMÁTICO II “Administrar base de datos relacionales mediante

el uso de un Sistema Gestor de Base de Datos (SGBD) y JAVA.”

NOMBRE: FECHA

No.

Indicador

SI

NO

Observaciones

1 Diseñaste una interfaz de usuario acorde a las

necesidades del cliente.

2 Generaste código orientado a eventos.

3 Empleaste las pruebas necesarias para corregir el

código para la interfaz de usuario

4 Elaboraste el Manual Técnico

5 Elaboraste el Manual del Usuario

Bibliografía

UML

http://es.wikipedia.org/wiki/Archivo:Notacion_Caso_de_Uso.svg

http://www.clikear.com/manuales/uml/diagramascasouso.aspx

http://www.monografias.com/trabajos-pdf4/diagramas-secuencia/diagramas-

secuencia.pdf

http://webdocs.cs.ualberta.ca/~pfiguero/soo/uml/colaboracion01.html

http://ldc.usb.ve/~martinez/cursos/ci3715/clase8_AJ2010.pdf

http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r33019.PDF

http://www.vico.org/aRecursosPrivats/UML_TRAD/talleres/mapas/UMLTRAD_101

A/LinkedDocuments/UML_diagActividad.pdf

http://es.scribd.com/doc/2568098/UML-Diagramas-de-actividad

http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r33018.PDF

http://www.sparxsystems.com.ar/download/ayuda/index.html?objectdiagram.htm

http://www.sparxsystems.com.ar/download/ayuda/index.html?objectdiagram.htm

http://webdocs.cs.ualberta.ca/~pfiguero/soo/uml/implementacion01.html

POO

http://msdn.microsoft.com/es-es/library/bb972232.aspx

http://courseware.ikor.org/java

http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos

http://fpsalmon.usc.es/genp/doc/cursos/poo/clases.html

http://es.wikipedia.org/wiki/NetBeans

http://www.lab.dit.upm.es/~lprg/material/apuntes/doc/doc.htm

http://gemini.udistrital.edu.co/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Pr

uebas/HTML%20-%20Pruebas%20de%20software/node37.html

BD Relacional

http://www.inegi.gob.mx/inegi/contenidos/espanol/prensa/Contenidos/Articulos/tec

nologia/relacional.pdf

http://www.escatep.ipn.mx/WPS/WCM/CONNECT/0FBD8A00412330A4AD2DBD0

27293106/LECTURA2_BASE_20DE_20DA_20DATOS.PDF?MOD=AJPERES

http://juanin.bligoo.com/content/view/609608/Concistencia-en-las-Bases-de-

Datos.html

http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/doc-modelado-sistemas-

uml.pdf