Perfil Admon de Sistemas Informaticos
+-+copia.JPG)
- ROBINSON
- OTRO, CASANARE-YOPAL, Colombia
- De acuerdo a los estudios realizados estoy capacitado para desempeñar y realizar mantenimiento y reparación de computadores, configuración de redes LAN.
jueves, 16 de junio de 2011
ACTIVIDADES DE DESARROLLO DE INGENIERIA DE SOFTWARE
Desde la vista de un enfoque orientado a objetos a continuación se presenta una descripción a manera introductoria de las actividades de desarrollo de ingeniería de software.
OBTENCION DE REQUERIMIENTOS
En esta actividad el cliente y los ingenieros de software (analistas, desarrolladores) se colocan de acuerdo en el alcance y propósito del sistema. Generalmente se expresan las funcionalidades que debe soportar el sistema y de igual manera se deben registrar los requerimientos no funcionales.
Como resultado de esta actividad se debe construir una especificación del sistema a través de un modelo de casos de uso (diagrama de casos de uso + plantilla de especificación de cada caso de uso) complementado con un documento donde se especifiquen los requerimientos no funcionales.
ANALISIS
En esta actividad los ingenieros de software deben generar un modelo que describa el dominio de aplicación (entorno donde operara el sistema) denominado modelo de análisis compuesto por tres modelos individuales: el modelo funcional, el modelo de datos y el modelo dinámico. El modelo funcional se representa por medio de diagramas de casos de uso, el modelo de datos se representa a través de un diagrama de clases y el modelo dinámico se representa por medio de diagramas de secuencia.
DISEÑO DE SISTEMA
En esta actividad los ingenieros definen los objetivos de diseño del sistema a partir de los requerimientos no funcionales especificados en la etapa de obtención de requerimientos y de igual manera descomponen el sistema en subsistemas mas pequeños que puedan ser desarrollados por equipos individuales con el fin de reducir la complejidad del sistema. De igual forma, los ingenieros determinan estrategias generales para la construcción del sistema. Adicionalmente en esta etapa se debe tomar la decisión acerca de la plataforma de hardware y software sobre la que se construirá el sistema.
DISEÑO DE OBJETOS
En esta actividad se deben incluir las siguientes tareas:
Especificación de servicios: Se debe especificar cada uno de los métodos o funcionalidades de la interfaz de clase.
Selección de componentes: se deben identificar los componentes hechos que puedan soportar algún subsistema y objetos de solución adicionales para la integración del sistema.
Reestructuración y optimización del modelo de objetos (datos): Se debe transformar el modelo de objetos para mejorar aspectos como comprensibilidad, extensibilidad y criterios de diseño.
IMPLEMENTACION
En esta actividad los ingenieros traducen los modelos diseñados en las etapas anteriores a código fuente, en mayor grado se debe trabajar con el modelo de objetos con la implementación de atributos y métodos de cada objeto individual y luego con la integración de cada uno de ellos para que funcionen como un solo sistema que responda a los requerimientos del cliente.
MODELAMIENTO CON UML
El UML (lenguaje de modelado unificado [OMG 1998] ha sido aceptado como notación estándar en los diferentes sectores de la industria y adicionalmente proporciona un conjunto de elementos que permiten representar diferentes aspectos de un sistema a través de diagramas en forma precisa y resumida.
En este segmento del documento se describen tres notaciones del UML que se necesitan para modelar un sistema como son los diagramas de casos de uso, los diagramas de clase y los diagramas de secuencia.
DIAGRAMAS DE CASOS DE USO
Es una imagen que representa la funcionalidad del sistema desde el punto de vista del usuario y de igual manera permite determinar las fronteras del sistema.
En forma general, un diagrama de caso de uso está conformado por actores, casos de uso, relaciones de comunicación y un contenedor que permite identificar la frontera del sistema.
Los actores son entidades externas que interactúan con el sistema, en forma específica pueden ser personas (roles) u otro sistema con el cual debe interactuar el sistema propuesto.
Los actores se representan en el diagrama a través de un ícono que algunos autores denominan la figura de palillos y en la parte inferior se debe acompañar del identificador del actor.
Los casos de uso describen comportamientos, capacidades o funcionalidades de un sistema tal como es visto por el cliente y los desarrolladores (basados en acuerdos). También se le denomina comportamiento externo.
Un caso de uso describe una funcionalidad proporcionada por el sistema y se operacionaliza a través de un conjunto de eventos que producen un resultado. Los casos de uso por lo general son iniciados por los actores y posteriormente el caso de uso puede iniciar otros casos de uso.
En el diagrama los casos de uso se representan por óvalos en cuyo interior se debe escribir en texto el identificador del caso de uso el cual por lo general se escribe iniciando con un verbo ya que el caso de uso está expresando una funcionalidad.
Cada caso de uso se debe describir con una plantilla de texto que varía de acuerdo a los requerimientos de documentación de los clientes y a las políticas de documentación de las empresas desarrolladoras de software, pero en forma general se puede coincidir que las plantillas deben contener por lo menos los siguientes campos:
• Nombre: Debe ser único y debe ser expresado en términos de verbos.
• Actores participantes: Son los actores que interactúan con el caso de uso en descripción.
• Condiciones iníciales: Expresan las condiciones que deben cumplirse antes de dar inicio al caso de uso.
• Flujo de eventos: Describe la secuencia de acciones que se deben llevar a cabo en el flujo básico del caso de uso. Es posible que en la descripción aparezcan flujos excepcionales los cuales se deben describir en un caso de uso por separado.
• Condiciones de salida: Expresan las condiciones que se cumplen una vez terminado el caso de uso.
• Requerimientos especiales: Se refieren a aquellos requerimientos que no están relacionados con la funcionalidad del sistema y que corresponden a políticas de desempeño del sistema.
Los casos de uso se escriben en lenguaje natural, lo cual permite mejorar la comunicación entre clientes e ingenieros de software debido a que muchas veces los clientes no entienden notaciones formales de la ingeniería del software.
En un diagrama se representan intercambios de información entre actores y casos de uso, entre casos de uso con otros casos de uso, las cuales se simbolizan a través de líneas denominadas relaciones o asociaciones.
Existen cuatro tipos de relaciones: comunicación, extensión, inclusión y generalización.
• Relaciones de comunicación: Se representan con una línea continua y por lo general se emplean para indicar acceso a una funcionalidad y cuando existe un intercambio de información entre actores y casos de uso.
• Relaciones de inclusión: Se representan con una flecha de guiones entre dos casos de uso y cuyo inicio se da en el caso de uso que incluye al otro. Este tipo de relaciones se utiliza cuando en un diagrama existe comportamiento común ya definido lo cual se debe separar en un caso de uso adicional para evitar redundancia y este se incluye en otro caso de uso por medio de una relación de este tipo. Se debe acompañar con el estereotipo include.
• Relaciones de extensión: Indica que una instancia del caso de uso extendido puede incluir cuando se cumplan ciertas condiciones el comportamiento especificado por el caso de uso que extiende. Se representa por una flecha de guiones cuyo inicio esta en el caso de uso excepcional. Se debe acompañar con el estereotipo extend.
• Relaciones de generalización: Por lo general se utilizan para indicar herencia y se simbolizan con una línea dirigida con un triangulo hueco. Pueden ocurrir entre dos actores o entre dos casos de uso lo cual indica que el actor o el caso de uso hijo son un caso del actor o uso básico.
Los actores, casos de uso y relaciones se integran al interior de un contenedor que ayuda a identificar la frontera del sistema.
DIAGRAMAS DE CLASE
Otra vista del sistema diferente a la funcional es la del modelo de datos que se puede representar a través de un modelo de clases, también denominado modelo estático porque no describe acción; lo que hace es mostrar objetos o cosas y sus relaciones.
Los diagramas de clases se diseñan para mostrar todas las piezas del sistema solución y deben transmitir un sentido del sistema que se estructurará en reposo.
Las clases son abstracciones que especifican los atributos y métodos de un conjunto de objetos. Los objetos son instancias de las clases y tienen la misma estructura de la clase que actúa como patrón.
Las clases y objetos se simbolizan a través de cuadros con tres secciones horizontales, en la sección superior se especifica el nombre de la clase u objeto (los nombres de objetos deben ir subrayados), en la sección central especifican los atributos con su respectivo tipo y en la sección inferior muestra los métodos.
Las asociaciones son relaciones entre clases y representan grupos de vínculos (conexión entre dos objetos).
Para la construcción de los diagramas de clase se aplica la fundamentación teórica de la asignatura bases de datos.
DIAGRAMAS DE SECUENCIA
Describen patrones de comunicación entre objetos interactuantes. Un objeto interactúa con otro enviando mensajes. La recepción de un mensaje por parte de un objeto activa la ejecución de una operación, la cual puede enviar mensajes a otros objetos.
Los objetos se ubican en la parte superior del diagrama en la primera fila y cada columna representa un objeto que participa en la interacción. La columna representa el tiempo de arriba hacia abajo para el mismo objeto. Los mensajes se simbolizan a través de flechas con rótulos los cuales representan los mensajes.
Por lo general, la primera columna corresponde al actor que inicia la interacción entre los objetos.
Las columnas normalmente reciben el nombre de líneas de vida, que por definición es un rectángulo con una recta vertical que desciende de ese rectángulo. La línea de vida representa un ejemplo de una clase, y la línea que desciende en forma vertical es un lugar conveniente para sujetar mensajes entrantes y salientes. Agregar múltiples líneas de vida a un solo diagrama y adicionarle mensajes en forma ordenada en el tiempo permiten mostrar todas las clases y mensajes necesarios para completar un caso de uso.
Una línea de vida de objetos toma forma como un objeto que representa una parte de un papel en un caso de uso.
Desde la vista de un enfoque orientado a objetos a continuación se presenta una descripción a manera introductoria de las actividades de desarrollo de ingeniería de software.
OBTENCION DE REQUERIMIENTOS
En esta actividad el cliente y los ingenieros de software (analistas, desarrolladores) se colocan de acuerdo en el alcance y propósito del sistema. Generalmente se expresan las funcionalidades que debe soportar el sistema y de igual manera se deben registrar los requerimientos no funcionales.
Como resultado de esta actividad se debe construir una especificación del sistema a través de un modelo de casos de uso (diagrama de casos de uso + plantilla de especificación de cada caso de uso) complementado con un documento donde se especifiquen los requerimientos no funcionales.
ANALISIS
En esta actividad los ingenieros de software deben generar un modelo que describa el dominio de aplicación (entorno donde operara el sistema) denominado modelo de análisis compuesto por tres modelos individuales: el modelo funcional, el modelo de datos y el modelo dinámico. El modelo funcional se representa por medio de diagramas de casos de uso, el modelo de datos se representa a través de un diagrama de clases y el modelo dinámico se representa por medio de diagramas de secuencia.
DISEÑO DE SISTEMA
En esta actividad los ingenieros definen los objetivos de diseño del sistema a partir de los requerimientos no funcionales especificados en la etapa de obtención de requerimientos y de igual manera descomponen el sistema en subsistemas mas pequeños que puedan ser desarrollados por equipos individuales con el fin de reducir la complejidad del sistema. De igual forma, los ingenieros determinan estrategias generales para la construcción del sistema. Adicionalmente en esta etapa se debe tomar la decisión acerca de la plataforma de hardware y software sobre la que se construirá el sistema.
DISEÑO DE OBJETOS
En esta actividad se deben incluir las siguientes tareas:
Especificación de servicios: Se debe especificar cada uno de los métodos o funcionalidades de la interfaz de clase.
Selección de componentes: se deben identificar los componentes hechos que puedan soportar algún subsistema y objetos de solución adicionales para la integración del sistema.
Reestructuración y optimización del modelo de objetos (datos): Se debe transformar el modelo de objetos para mejorar aspectos como comprensibilidad, extensibilidad y criterios de diseño.
IMPLEMENTACION
En esta actividad los ingenieros traducen los modelos diseñados en las etapas anteriores a código fuente, en mayor grado se debe trabajar con el modelo de objetos con la implementación de atributos y métodos de cada objeto individual y luego con la integración de cada uno de ellos para que funcionen como un solo sistema que responda a los requerimientos del cliente.
MODELAMIENTO CON UML
El UML (lenguaje de modelado unificado [OMG 1998] ha sido aceptado como notación estándar en los diferentes sectores de la industria y adicionalmente proporciona un conjunto de elementos que permiten representar diferentes aspectos de un sistema a través de diagramas en forma precisa y resumida.
En este segmento del documento se describen tres notaciones del UML que se necesitan para modelar un sistema como son los diagramas de casos de uso, los diagramas de clase y los diagramas de secuencia.
DIAGRAMAS DE CASOS DE USO
Es una imagen que representa la funcionalidad del sistema desde el punto de vista del usuario y de igual manera permite determinar las fronteras del sistema.
En forma general, un diagrama de caso de uso está conformado por actores, casos de uso, relaciones de comunicación y un contenedor que permite identificar la frontera del sistema.
Los actores son entidades externas que interactúan con el sistema, en forma específica pueden ser personas (roles) u otro sistema con el cual debe interactuar el sistema propuesto.
Los actores se representan en el diagrama a través de un ícono que algunos autores denominan la figura de palillos y en la parte inferior se debe acompañar del identificador del actor.
Los casos de uso describen comportamientos, capacidades o funcionalidades de un sistema tal como es visto por el cliente y los desarrolladores (basados en acuerdos). También se le denomina comportamiento externo.
Un caso de uso describe una funcionalidad proporcionada por el sistema y se operacionaliza a través de un conjunto de eventos que producen un resultado. Los casos de uso por lo general son iniciados por los actores y posteriormente el caso de uso puede iniciar otros casos de uso.
En el diagrama los casos de uso se representan por óvalos en cuyo interior se debe escribir en texto el identificador del caso de uso el cual por lo general se escribe iniciando con un verbo ya que el caso de uso está expresando una funcionalidad.
Cada caso de uso se debe describir con una plantilla de texto que varía de acuerdo a los requerimientos de documentación de los clientes y a las políticas de documentación de las empresas desarrolladoras de software, pero en forma general se puede coincidir que las plantillas deben contener por lo menos los siguientes campos:
• Nombre: Debe ser único y debe ser expresado en términos de verbos.
• Actores participantes: Son los actores que interactúan con el caso de uso en descripción.
• Condiciones iníciales: Expresan las condiciones que deben cumplirse antes de dar inicio al caso de uso.
• Flujo de eventos: Describe la secuencia de acciones que se deben llevar a cabo en el flujo básico del caso de uso. Es posible que en la descripción aparezcan flujos excepcionales los cuales se deben describir en un caso de uso por separado.
• Condiciones de salida: Expresan las condiciones que se cumplen una vez terminado el caso de uso.
• Requerimientos especiales: Se refieren a aquellos requerimientos que no están relacionados con la funcionalidad del sistema y que corresponden a políticas de desempeño del sistema.
Los casos de uso se escriben en lenguaje natural, lo cual permite mejorar la comunicación entre clientes e ingenieros de software debido a que muchas veces los clientes no entienden notaciones formales de la ingeniería del software.
En un diagrama se representan intercambios de información entre actores y casos de uso, entre casos de uso con otros casos de uso, las cuales se simbolizan a través de líneas denominadas relaciones o asociaciones.
Existen cuatro tipos de relaciones: comunicación, extensión, inclusión y generalización.
• Relaciones de comunicación: Se representan con una línea continua y por lo general se emplean para indicar acceso a una funcionalidad y cuando existe un intercambio de información entre actores y casos de uso.
• Relaciones de inclusión: Se representan con una flecha de guiones entre dos casos de uso y cuyo inicio se da en el caso de uso que incluye al otro. Este tipo de relaciones se utiliza cuando en un diagrama existe comportamiento común ya definido lo cual se debe separar en un caso de uso adicional para evitar redundancia y este se incluye en otro caso de uso por medio de una relación de este tipo. Se debe acompañar con el estereotipo include.
• Relaciones de extensión: Indica que una instancia del caso de uso extendido puede incluir cuando se cumplan ciertas condiciones el comportamiento especificado por el caso de uso que extiende. Se representa por una flecha de guiones cuyo inicio esta en el caso de uso excepcional. Se debe acompañar con el estereotipo extend.
• Relaciones de generalización: Por lo general se utilizan para indicar herencia y se simbolizan con una línea dirigida con un triangulo hueco. Pueden ocurrir entre dos actores o entre dos casos de uso lo cual indica que el actor o el caso de uso hijo son un caso del actor o uso básico.
Los actores, casos de uso y relaciones se integran al interior de un contenedor que ayuda a identificar la frontera del sistema.
DIAGRAMAS DE CLASE
Otra vista del sistema diferente a la funcional es la del modelo de datos que se puede representar a través de un modelo de clases, también denominado modelo estático porque no describe acción; lo que hace es mostrar objetos o cosas y sus relaciones.
Los diagramas de clases se diseñan para mostrar todas las piezas del sistema solución y deben transmitir un sentido del sistema que se estructurará en reposo.
Las clases son abstracciones que especifican los atributos y métodos de un conjunto de objetos. Los objetos son instancias de las clases y tienen la misma estructura de la clase que actúa como patrón.
Las clases y objetos se simbolizan a través de cuadros con tres secciones horizontales, en la sección superior se especifica el nombre de la clase u objeto (los nombres de objetos deben ir subrayados), en la sección central especifican los atributos con su respectivo tipo y en la sección inferior muestra los métodos.
Las asociaciones son relaciones entre clases y representan grupos de vínculos (conexión entre dos objetos).
Para la construcción de los diagramas de clase se aplica la fundamentación teórica de la asignatura bases de datos.
DIAGRAMAS DE SECUENCIA
Describen patrones de comunicación entre objetos interactuantes. Un objeto interactúa con otro enviando mensajes. La recepción de un mensaje por parte de un objeto activa la ejecución de una operación, la cual puede enviar mensajes a otros objetos.
Los objetos se ubican en la parte superior del diagrama en la primera fila y cada columna representa un objeto que participa en la interacción. La columna representa el tiempo de arriba hacia abajo para el mismo objeto. Los mensajes se simbolizan a través de flechas con rótulos los cuales representan los mensajes.
Por lo general, la primera columna corresponde al actor que inicia la interacción entre los objetos.
Las columnas normalmente reciben el nombre de líneas de vida, que por definición es un rectángulo con una recta vertical que desciende de ese rectángulo. La línea de vida representa un ejemplo de una clase, y la línea que desciende en forma vertical es un lugar conveniente para sujetar mensajes entrantes y salientes. Agregar múltiples líneas de vida a un solo diagrama y adicionarle mensajes en forma ordenada en el tiempo permiten mostrar todas las clases y mensajes necesarios para completar un caso de uso.
Una línea de vida de objetos toma forma como un objeto que representa una parte de un papel en un caso de uso.
sábado, 11 de junio de 2011
sábado, 28 de mayo de 2011
ARQUITECTURA DEL SOFTWARE MULTICAPA
TALLER 1 ARQUITECTURA DEL SOFTWARE MULTICAPA
Defina:
1. ARQUITECTURA CLIENTE SERVIDOR
RTA: L a arquitectura cliente-servidor es un sistema donde el cliente y el servidor realizan comunicación, el cliente solicita información o servicios y el servidor suministra dicho proceso.
2. ARQUITECTURA DE 3 CAPAS
RTA: L a arquitectura de tres capas es un sistema que utiliza las capas de presentación, negocio y de datos. El usuario pide un proceso desde su terminal; el servidor de aplicaciones la direcciona y la base de datos la localiza y la devuelve para que el servidor de aplicaciones la visualice en un formato correcto.
3. CGI
RTA: CGI = Common Gateway Interfaz. Es un interfaz de entrada común, que funciona como una llave para ingresar o visualizar páginas web. El usuario solicita una dirección y el servidor lo presenta en la debida aplicación a través de CGI.
4. JAVA y que es un applet
RTA: JAVA es un lenguaje de programación que permite abrir cualquier aplicación sin importar el sistema operativo o hardware.
Un applet es un código, lenguaje u programa compilador para acceder a determinada función y servicio web.
5. SERVLETS. Y DONDE PUEDO EJECUTARLO. DAR EJEMPLO
RTA: Un servlet es un programa o aplicación JAVA que se ejecuta en un servidor. A continuación se da un ejemplo de código servlet que representa un formulario:
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class ParamServlet extends HttpServlet {
private static final long serialVersionUID = 1L;
public void doPost(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
// Obtenemos un objeto Print Writer para enviar respuesta
res.setContentType("text/html");
PrintWriter pw = res.getWriter();
pw.println("
pw.println("");
pw.println("
Leyendo parámetros desde un formulario html
");
pw.println("
- \n");
pw.println("Te llamas " + req.getParameter("NOM") + "
");
pw.println("y tienes " + req.getParameter("EDA") + " años
");
pw.println("");
pw.close();
}
}
6. CUAL ES LA VENTAJA DE UTILIZAR PÁGINAS DE SERVIDOR EN VEZ DE UN PROGRAMA SERVIDOR
RTA: Las páginas de servidor ejecutan códigos e instrucciones desde cualquier punto y con mayor facilidad.
7. SERVIDOR DE APLICACIONES
RTA: Un servidor de aplicaciones es un software que proporciona aplicaciones a los equipos o dispositivos cliente, por lo general a través de Internet y utilizando el protocolo http. Recibe la orden y el servidor de aplicaciones la visualiza en el programa adecuado.
8. EXPLIQUE LA MÉTRICA 3
RTA: Métrica es una metodología de planificación, desarrollo y mantenimiento de sistemas de información, en si son reglas que se están predeterminadas para la elaboración de software. Muestra las particiones y divisiones del sistema, también los componentes y elementos.
9. CUÁL ES LA IMPORTANCIA DE REALIZAR DIAGRAMAS DE RED?
RTA: La elaboración de diagramas de red ayudar a tener una idea concreta de la funcionabilidad, proceso y ejecución del sistema que se maneja dentro de la red.
10. VENTAJAS Y DESVENTAJAS DE ORGANIZAR POR CAPAS.
RTA: La organización por capas simplemente permite que apliquemos un sistema dependiendo de los requerimientos, si se maneja una red muy compleja se debe implementar una red de multicapas, mientras los sistemas cliente-servidor son sistemas pequeños.
11. EXPLIQUE LAS 3 CAPAS DE UN SISTEMA MULTINIVELES
RTA: Las tres capas son:
1. Capa de presentación: es la que ve el usuario (también se la denomina "capa de usuario"), presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo de proceso.
2. Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso en el programa y aplicación correcta.
3. Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos. Reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio y dan respuesta a través de la capa de negocio.
12. QUE SE DEBE TENER EN CUENTA PARA ELEGIR UN SERVIDOR DE APLICACIONES Y PORQUE ES IMPORTANTE QUE CUMPLA CON 24/365, ESCALABILIDAD
RTA: hace referencia a que un sistema debe estar funcionando las 24 horas del día los 365 días al año.
13. EXPLIQUE J2EE
RTA: J2EE es una plataforma de programación—parte de la Plataforma Java—para desarrollar y ejecutar software de aplicaciones en Lenguaje de programación Java con arquitectura de N capas distribuidas y que se apoya ampliamente en componentes de software modulares ejecutándose sobre un servidor de aplicaciones.
14. QUE ES UNA API
RTA: Una interfaz de programación de aplicaciones o API (del inglés Application Programming Interface) es el conjunto de funciones y procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción. Se trata del conjunto de llamadas a ciertas bibliotecas que ofrecen acceso a ciertos servicios desde los procesos y representa un método para conseguir abstracción en la programación.
15. QUE ES JSP CUÁLES SON SUS VENTAJAS? CUÁL ES LA ESTRUCTURA BÁSICA. DAR UN EJEMPLO
RTA: Java Server Pagés (JSP) es una tecnología que nos permite mezclar HTML estático con HTML, Las ventajas de JSP están duplicadas. Primero, la parte dinámica está escrita en Java, no en Visual Basic, otro lenguaje específico de MS, por eso es mucho más poderosa y fácil de usar. Segundo, es portable a otros sistemas operativos y servidores Web. Los JSP es un sistema universal que permite visualizar archivos HTML.
16. QUE ES UNA SESIÓN PARA QUE SE USA
RTA: Una sesión es una serie de comunicaciones entre un cliente y un servidor en la que se realiza un intercambio de información. Por medio de una sesión se puede hacer un seguimiento de un usuario a través de una aplicación.
a. getSession() Para obtener la sesión de un usuario
b. idSession() Sirve para identificar usuario
c. setAttribute() se utiliza para guardar un objeto en una sesión
d. get.Attribute() recupera un objeto de una sesión
e. (timeout) fija límite de tiempo de una función
f. invalidate() invalida cierto parámetro u orden
17. JAVABEAN. CARACTERÍSTICAS. DAR EJEMPLO
RTA: JavaBeans permite escribir componentes software en Java. Los componentes son unidades software reutilizables y auto-contenidas que pueden ser unirse visualmente en componentes compuestos, applets, aplicaciones y servlets utilizando herramientas visuales de desarrollo de aplicaciones.
EJEMPLO:
public class PersonaBean
implements java.io.Serializable {
private String nombre;
private int edad;
public PersonaBean() {
// Constructor sin argumentos
}
public void setNombre(String n) {
this.nombre = n;
}
public void setEdad(int e) {
this.edad = e;
}
public String getNombre() { return (this.nombre); }
public int getEdad() { return (this.edad); }
}
Suscribirse a:
Comentarios (Atom)