INSTITUTO TECNOLGICO SUPERIOR DE TEPEACA

CREATIVIDAD TECNOLGICA Y CALIDAD EDUCATIVA, PILARES PARA LA EXCELENCIA HUMANA

INGENIERA EN SISTEMAS COMPUTACIONALES (CARRERA)

DESARROLLO DE PROYECTO DE SOFTWARE (MATERIA)

TAREA POR EQUIPO

ING. CLAUDIA NELLY LOPEZ MORALES (CATEDRATICO)

INTEGRANTES:

JUAN SERGIO PEREZ TAPIA

JOSE RICARDO RAMIREZ BENITEZ

MARTIN JIMENEZ MARTINEZ

8 A

MODELO 4 + 1 VISTAS

El modelo de 4+1 vistas fue desarrollado para remediar este problema. El modelo 4+1 describe la arquitectura del software usando cinco vistas concurrentes. Tal como se muestra en la Figura 1, cada vista se refiere a un conjunto de intereses de diferentes stakeholders del sistema. La vista logica describe el modelo de objetos del diseo cuando se usa un metodo de diseo orientado a objetos. Para disenar una aplicacion muy orientada a los datos, se puede usar un enfoque alternativo para desarrollar algun otro tipo de vista logica, tal como diagramas de entidad-relacion. La vista de procesos describe los aspectos de concurrencia y sincronizacion del diseo. La vista fsica describe el mapeo del software en el hardware y refleja los aspectos de distribucion. La vista de desarrollo describe la organizacion estatica del software en su ambiente de desarrollo.

2. Diseo orientado a objetos 2.1 Diseo del sistema en base a procesos La primera actividad en el proceso de desarrollo de sistemas involucra al equipo de trabajo en el conocimiento del problema para establecer los requerimientos en trminos confiables y especificaciones formales y concretas. El proceso de anlisis de requerimientos pretende acelerar las curvas de aprendizaje mediante subprocesos que permitan extraer el conocimiento clave de

los usuarios hacia estructuras incrementales de conocimiento, de tal forma que los miembros del equipo de desarrollo, puedan llegar ms rpidamente a la parte acelerada de la curva de aprendizaje. Sin embargo, sta adquisicin de conocimientos no ser slo capacitacin, sino tambin, debe aprovecharse para establecer los requerimientos bsicos del sistema. El Modelo de Requerimientos se constituye a su vez de tres modelos: Modelo de casos Modelo de Interfaz Modelo de Dominio del Problema

Cada uno contempla parte del conocimiento del usuario orientado a la especificacin de las funciones bsicas del sistema. El Modelo de Casos extrae el conocimiento funcional fundamental del problema de una forma estructurada y progresiva, siendo la base para establecer la estructura del sistema. Este modelo orienta todos las dems procesos del mtodo. El modelo de Interfaz establece el vnculo visual entre el desarrollador y el usuario para concretar aspectos de la interaccin que el sistema pudiese tener con su entorno externo, permitiendo la retroalimentacin temprana de aspectos fundamentales para el conocimiento de la aplicacin. En el Modelo del Dominio del Problema se establecern los principales objetos que constituirn al sistema y las relaciones que tienen entre s.

2.1.1 Actividades y casos de uso. Modelado de casos de uso Un caso real de uso describe el diseo concreto del caso de uso a partir de una tecnologa particular de entrada y salida, as como de su implementacin global. Por ejemplo, si interviene una interfaz grfica para el usuario, el caso de uso real incluir diagramas de las ventanas en cuestin y una explicacin de la interaccin de bajo nivel con los artefactos de la interfaz. Los diagramas de casos de uso pueden llegar a ser bastante grandes esto no es malo con los modelos grandes, siempre y cuando se agregue valor al esfuerzo global. El hecho es que se puede llegar a crear un modelo de gran tamao que describe los requisitos para su sistema, y puede incluir un modelo de casos de uso general que se han creado durante meses o aos de trabajo evolutivo. No deben ser creados todos por adelantado antes de empezar a programar. La asociacin entre el estudiante e inscrito en seminario seala que el caso de uso es invocado, inicialmente por un estudiante y no por un encargado de admisin (el encargado de admisin es tambin un actor y est involucrado en este caso de uso). Entendiendo que las asociaciones no representan flujo de informacin es importante, simplemente indican que un actor es de alguna manera involucrado en un caso de uso. La informacin fluye de ida y vuelta entre el actor y el caso de uso, por ejemplo, los estudiantes deben indicar a qu seminarios quieren inscribirse en el sistema y tendra que indicar a los estudiantes si han sido inscritos.

Los Diagramas de casos de uso dan una visin general muy buena de los requisitos. A menudo se dibuje un diagrama de casos de uso mientras se estn identificando los actores del caso de uso y las asociaciones entre ellos. (Schneider y Winters, 2001) sugieren que los diagramas de casos de uso deben ser desarrollados desde el punto de vista del usuario y no del desarrollador. Suobjetivo es modelar los requisitos de comportamiento para el sistema y cmo los usuarios trabajan con el sistema para satisfacer sus necesidades, no lo que los desarrolladores creen que deben construir. Identificacin de los actores Un actor representa a cualquier cosa o alguien que interacta con el sistema. Esto puede incluir a las personas (no slo el usuario final), los sistemas externos, y otras organizaciones. Los actores son siempre externos al sistema que est siendo modelado, ellos nunca son parte del sistema. Para ayudar a encontrar a los actores en el sistema, debe hacerse las siguientes preguntas (Schneider y Winters 2001; Leffingwell y Widrig 2000): Quin es el principal cliente de su sistema? Quin obtiene la informacin de este sistema? Quin proporciona informacin al sistema? Quin instala el sistema? Quin opera el sistema? Quin apaga el sistema? Qu otros sistemas interactan con este sistema? Hay algo que suceder de forma automtica a una hora predeterminada? Quin suministro, utilizacin, o eliminar la informacin del sistema? De dnde viene el sistema de obtener informacin? Un caso de uso es una secuencia de acciones que proporcionen un valor medible para un actor. Otra forma de verlo es un caso de uso es, describe una manera en la que un actor del mundo real interacta con el sistema.

Identificacin de casos de uso

Una forma en preguntando a sus interesados las siguientes preguntas desde el punto de vista de los actores: Cules son los usuarios de este rol tratando de realizar? Qu deben ser capaces los usuarios de hacer? Cules son las principales tareas de los usuarios en este papel? Qu informacin necesitan examinar, crear o cambiar los usuarios de este perfil? Qu informacin necesitan los usuarios de este perfil del sistema? Qu hacen los usuarios en este perfil que necesitan informar al sistema? Los sistemas y sus fronteras Un caso de uso describe la interaccin con un "sistema". Las fronteras ordinarias del sistema son: la frontera hardware/software de un dispositivo o sistema de cmputo el departamento de una organizacin la organizacin entera

Es importante definir la frontera del sistema como se muestra en la figura 2.4, para identificar lo que es interno o externo, as como las responsabilidades del sistema. El ambiente externo est representado nicamente por actores. Casos de uso primario, secundario y opcional. Los casos deberan clasificarse en primarios, secundarios u opcionales. Ms adelante, a partir de estas designaciones, clasificaremos nuestro conjunto de casos de uso para establecer prioridades en su desarrollo. Los casos primarios de uso representan los procesos comunes ms importantes, como Comprar productos. 2.1.2 Interfaz de usuario Un caso real de uso describe el diseo concreto del caso de uso a partir de una tecnologa particular de entrada y salida, as como de su implementacin global. Por ejemplo, si interviene una interfaz grfica para el usuario, el caso de uso real incluir diagramas de las ventanas en cuestin y una explicacin de la interaccin de bajo nivel con los artefactos de la interfaz.

Una alternativa podra consistir en que el diseador realizara storyboards o secuencias de las pantallas de la interfaz general para el usuario y despus incorporar los detalles durante la implementacin. Los storyboards son de gran utilidad, si antes de la implementacin los diseadores o el cliente necesitan descripciones rigurosamente detalladas. La interfaz de usuario UI2es la parte del software con el que un usuario interacta directamente. Un prototipo de interfaz de usuario es un modelo de baja fidelidad de la interfaz de usuario para el sistema. Representa las ideas generales de la IU, pero no los detalles exactos. Esencialmente los prototipos de IU representan los requisitos de una manera independiente de la tecnologa, al igual que los modelos de casos de uso esenciales para hacer sus necesidades conductuales. Un prototipo de IU es realmente el estado inicial, el inicio de la interfaz para el sistema. Estos modelos de requisitos de interfaz de usuario, evolucionan a travs del anlisis y diseo para dar lugar a la interfaz de usuario final para su sistema. Cuando un equipo est creando un elemento esencial del prototipo de interfaz de usuario, este itera entre las siguientes tareas: Explorar el uso del sistema. Su equipo explorar el uso del sistema a travs de diversos medios. Modelo de los elementos principales de la IU. Elementos de la interfaz, como las pantallas de informes potenciales, se puede modelar usando papel de rota folio. Modelo de elementos menores de la IU. Tales como campos de entrada, las listas, y los contenedores (elementos de la IU que se agregan otros elementos de menor importancia. La creacin de un prototipo de interfaz de usuario es una tcnica de anlisis iterativo en el que los usuarios participan activamente en el bosquejo en marcha de la interfaz de usuario para un sistema como se muestra en la figura 2.5. Los prototipos de interfaz de usuario tienen varios propsitos: Como el anlisis de un artefacto que le permite explorar el espacio del problema con las partes interesadas; Como un artefacto de diseo que le permite explorar el espacio de la solucin de su sistema;

 Como un vehculo para que usted se comunique el posible diseo de la interfaz de usuario (s) de su sistema, y Como un fundamento potencial desde donde continuar desarrollando el sistema.

Mientras se estn determinando las necesidades de los stakeholders se puede decidir transformar sus prototipos de interfaz de usuario, si ha creado bocetos. Figura 2.6 que representa un esquema de dos pantallas potenciales o pginas HTML basado en el prototipo de interfaz de usuario figura. 2.5. Transformar en realidad no es la palabra aqu, ya que estoy usando una tecnologa de de modelizacin completamente diferente (una pizarra en lugar de papel) por lo que en efecto se est reemplazando lo esencial del prototipo de interfaz de usuario con los bocetos. Una vez que entienda las necesidades de la interfaz de usuario de sus stakeholders, el siguiente paso es construir en realidad un prototipo. Usando una herramienta de creacin de prototipos o lenguaje de alto nivel como Java .Net u otro, se desarrolla la pantalla, pginas y los informes que necesitan los usuarios. Con la plataforma de interfaz de usuario seleccionada, puede iniciar la conversin de los aspectos individuales de su interfaz de usuario. Es posible que desee crear bocetos, como se ve en la figura. 2.6 o ir directamente a una aplicacin concreta, como la pgina HTML que se muestra en la figura 2.7. Los dibujos son ms inclusivos, y sus partes interesadas pueden participar activamente en su creacin, a pesar de que la actual pgina HTML es mucho ms cercana al cdigo de trabajo. Es fundamental comprender que no es necesario crear un prototipo para todo el sistema. Es muy comn que al prototipo de una pequea porcin de la interfaz de usuario, tal vez una sola pantalla o la pgina HTML, antes de pasar a su aplicacin.

2.2 Diseo de la lgica.

2.2.1 Clases y Objetos. En un caso de uso conducido por Modelado de objetos con UML se describen una tcnica llamada anlisis de robustez, algo que el(RUP) se refiere a su uso como anlisis de casos (IBM 2003). La idea bsica es que usted puede analizar los pasos de un caso de uso para validar la lgica de negocio dentro de l y garantizar que la terminologa es consistente con otros casos de uso que ha analizado anteriormente. En otras palabras, usted lo puede utilizar para asegurarse de que sus casos de uso son lo suficientemente robustos para representar los requisitos de uso para el sistema que estamos construyendo. Otro uso es el de identificar objetos potenciales o responsabilidades de objeto para apoyar la lgica en el caso de uso, actuando efectivamente como un puente hacia otros diagramas tales como diagramas de secuencia UML y los diagramas de clases UML. Un modelo conceptual explica (a sus creadores) los conceptos significativos en un dominio del problema; es el artefacto ms importante a crear durante el anlisis orientado a objetos. Una cualidad esencial que debe ofrecer un modelo conceptual es que representa cosas del mundo real, no componentes del software. Una de las primeras actividades centrales de un ciclo de desarrollo consiste en crear un modelo conceptual para los casos de uso del ciclo actual. Esto no puede hacerse si no se cuentan con los casos y con otros documentos que permitan identificar los conceptos (objetos). La creacin no siempre es lineal; por ejemplo, el modelo conceptual puede formularse en paralelo con el desarrollo de los casos de uso. El paso esencial de un anlisis o investigacin orientado a objetos es descomponer el problema en conceptos u objetos individuales: las cosas que sabemos. Un modelo conceptual es una representacin de conceptos en un dominio del problema. En UML, se ilustra con un grupo de diagramas de estructura esttica donde no se define ninguna operacin. La designacin de modelo conceptual ofrece la ventaja de subrayar fuertemente una concentracin en los conceptos del dominio, no en las entidades del software.

Puede mostrarnos: conceptos asociaciones entre conceptos atributos de conceptos

El modelo del dominio es un diccionario visual de abstracciones; visualiza y relaciona algunas palabras o clases conceptuales del dominio. Tambin describe una abstraccin de las clases conceptuales, porque hay muchas cosas que uno podra comunicar. El modelo muestra una vista parcial, o abstraccin, e ignora detalles sin inters (para el modelador). La informacin que se presenta (utilizando la notacin UML) podra, de manera alternativa haberse expresado en prosa, mediante sentencias en el glosario o en algn otro sitio. Pero es fcil entender los distintos elementos y sus relaciones mediante este lenguaje visual, puesto que un porcentaje significativo del cerebro toma parte en el procesamiento visual que es una cualidad de los humanos. Por tanto, el modelo del dominio podra considerarse como un diccionario visual de las abstracciones relevantes, vocabulario del dominio e informacin del dominio Un modelo del dominio, es una representacin de las cosas del mundo real del dominio de inters, no de componentes software, como una clase Java o C u objetos software con responsabilidades. Por tanto, los siguientes elementos no son adecuados en un modelo del dominio: El modelo del dominio muestra las clases conceptuales o vocabulario del dominio. Informalmente, una clase conceptual es una idea, cosa u objeto. Ms formalmente, una clase conceptual podra considerarse en trminos de su smbolo, intensin, y extensin. Smbolo: palabras o imgenes que representan una clase conceptual. Intensin: la definicin de una clase conceptual. Extensin: el conjunto de ejemplos a los que se aplica la clase conceptual.

Tener una declaracin vaga no es muy poco comn al comenzar proyectos reales. Sin embargo, debemos ser capaces construir un diagrama de clases fcilmente usando nuestros conocimientos adecuados acerca de los conceptos habituales. Por lo tanto, iniciamos por la identificacin de dos clases: Marcador y la pluma, que tienen un nmero de caractersticas comunes (color, marca) Sin embargo tambin estn las diferencias (vase, por ejemplo, que los marcadores tienen una tapa, mientras que las plumas tienen una punta retrctil). Alguien que est modelando ve de inmediato la posibilidad de una relacin de generalizacin/especializacin. Por lo tanto, introduce una clase abstracta para excluir caractersticas comunes Tome nota de las multiplicidades entre marcador y tapn: un marcador puede perder su tapn, y un tapn el cuerpo de su marcador origen. Esta nocin de cuerpo es interesante y compartida para los bolgrafos y marcadores. En aras de mantener la coherencia con el tapn, hay que agregarlo.

2.2.2 Interaccin.

Los diagramas de interaccin son modelos que describen la manera en que colaboran grupos de objetos para cierto comportamiento. Habitualmente, un diagrama de interaccin capta el comportamiento de un solo caso de uso. El diagrama muestra cierto nmero de ejemplos de objetos y los mensajes que se pasan entre estos objetos dentro del caso de uso. Ejemplo: enfoque mediante un caso de uso simple que exhibe el comportamiento siguiente: La ventana Entrada de pedido enva un mensaje "prepara" a Pedido. El Pedido enva entonces un mensaje "prepara" a cada Lnea de pedido dentro del Pedido. Cada Lnea de pedido revisa el Artculo de inventario correspondiente. - Si esta revisin devuelve "verdadero", la Lnea de pedido descuenta la cantidad apropiada de Artculo de inventario del almacn.

- Si no sucede as, quiere decir que la cantidad del Artculo de inventario ha cado ms abajo del nivel de reorden y entonces dicho Artculo de inventario solicita una nueva entrega.

Hay dos tipos de diagramas de interaccin: diagramas de secuencia y diagramas de colaboracin. Diagramas de secuencia En un diagrama de secuencia, un objeto se muestra como caja en la parte superior de una lnea vertical punteada Esta lnea vertical punteada se llama lnea de vida del objeto. La lnea de vida representa la vida del objeto durante la interaccin. Cada mensaje se representa mediante una flecha entre las lneas de vida de dos objetos. El orden en el que se dan estos mensajes transcurre de arriba hacia abajo. Cada mensaje es etiquetado por el nombre del mensaje; pueden incluirse los argumentos y alguna informacin de control, y se puede mostrar la autodelegacin (accin recursiva), que es un mensaje que un objeto se enva a s mismo, regresando la flecha de mensaje de vuelta a la misma lnea de vida. Dos partes de la informacin de control son valiosas. Primero, hay una condicin, que indica cundo se enva un mensaje. El mensaje se enva slo si la condicin es verdadera. El segundo marcador de control til es el marcador de iteracin, que muestra que un mensaje se enva muchas veces a varios objetos receptores, corno sucedera cuando se itera sobre una coleccin. La base de la iteracin se puede mostrar entre corchetes (como en *[para cada lnea de pedido]).

Una de las cuestiones ms difciles de comprender en un programa orientado a objetos es el flujo de control general. Un buen diseo tiene muchsimos pequeos mtodos en diferentes clases, y a veces resulta muy complicado determinar la secuencia global de comportamiento.

Podr acabar leyendo el cdigo, tratando de encontrar dnde est el programa. Esto ocurre as, en especial, para todos aquellos que comienzan a trabajar con objetos. Los diagramas de secuencia le ayudan a ver la secuencia. Este proceso permitir aadir con facilidad otros procesos de revisin, porque cada registro es llamado asincrnicamente y opera en paralelo. Cuando termina un Revisor de transaccin, se lo notifica al Coordinador de transaccin. El coordinador comprueba si todos los revisores respondieron; de no ser as, no hace nada. Si todos han respondido indicando terminaciones exitosas, como en el presente caso, entonces el coordinador notifica a la Transaccin que todo est bien. El borrado de un objeto se muestra con una X grande. Los objetos pueden autodestruirse Se pueden mostrar con ms claridad las consecuencias de la auto delegacin cuando se tienen activaciones. Sin ellas, o sin la notacin de apilamiento que se usa aqu, es difcil decir dnde ocurrirn ms llamadas tras una auto delegacin: en el mtodo invocador o en el invocado. Las activaciones de apilamientos dejan en claro este aspecto. Descubro que, en algunas ocasiones, sta es una razn para utilizar activaciones en una interaccin de procedimiento, aun cuando por lo comn no uso las activaciones en estos casos. Una tcnica muy til es insertar descripciones textuales de lo que sucede; en el diagrama de secuencia al lado izquierdo de este. Ello implica la alineacin de cada bloque de texto con el mensaje apropiado dentro del diagrama. Esto ayuda a comprender el diagrama se realiza con aquellos documentos que se conservaran, pero no con bosquejos desde cero.

2.2.3 Estados y transicin.

Los diagramas de estados son una tcnica conocida para describir el comportamiento de un sistema. Describen todos los estados posibles en los que

puede entrar un objeto particular y la manera en que cambia el estado del objeto, como resultado de los eventos que llegan a l. En la mayor parte de las tcnicas OO, los diagramas de estados se dibujan para una sola clase, mostrando el comportamiento de un solo objeto durante todo su ciclo de vida. Los diagramas UML de mquina de estados representan los diferentes estados que el objeto puede tener y las transiciones entre los estados. Un estado representa una etapa en el patrn de comportamiento de un objeto, y es posible tener un estado inicial y un estado final. Un estado inicial, tambin llamado estado de creacin, es cuando un objeto es creado por primera vez, mientras que un estado final es aquel en el que no se llevan a cabo ninguna transicin ms. Una transicin es una progresin de un estado a otro y se activar por un evento ya sea interna o externo al objeto. El nombre de un evento tiene alcance dentro del paquete en el cual est definido, no es local a la clase que lo nombre. Envo de mensajes adems de mostrar la transicin de estados por medio de eventos, puede representarse el momento en el cual se envan mensajes a otros Las acciones: especifican la solicitud de un servicio a otro objeto como consecuencia de la transicin. Se puede especificar el ejecutar una accin como consecuencia de entrar, salir, estar en un estado, o por la ocurrencia de un evento. Generalizacin de Estados: Podemos reducir la complejidad de estos diagramas usando la generalizacin de estados. Distinguimos as entre superestado y subestados. Un estado puede contener varios subestados disjuntos. Los subestados heredan las variables de estado y las transiciones externas. La agregacin de estados es la composicin de un estado a partir de varios estados independientes.

La composicin es concurrente por lo que el objeto estar en alguno de los estados de cada uno de los subestados concurrentes. La destruccin de un objeto

es efectiva cuando el flujo de control del autmata alcanza un estado final no anidado. La llegada a un estado final anidado implica la subida al superestado asociado, no el fin del objeto. Un estado puede descomponerse en subestados, con transiciones entre ellos y conexiones al nivel superior. Las conexiones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel inmediatamente superior. Una transicin compleja relaciona tres o ms estados en una transicin de mltiples fuentes y/o mltiples destinos. Representa la subdivisin en tareas del control del objeto o una sincronizacin. Se representa como una lnea vertical de la cual salen o entran varias lneas de transicin de estado. Una transicin de hacia un estado complejo (descrito mediante estados anidados) significa la entrada al estado inicial del su diagrama. Las transiciones que salen del estado complejo se entienden como transiciones desde cada uno de los subestados hacia afuera (a cualquier nivel de profundidad). Transiciones temporizadas

DIAGRAMACION DIAGRAMAS DE INTERACCION Son diagramas que describen como grupos de objetos colaboran para conseguir algn fin. Estos diagramas muestran objetos asi como los mensajes que se pasan entre ellos dentro del caso de uso. Se expresa de 2 formas: Diagrama de colaboracin y diagramas de secuencia. Diagramas de colaboracin:

Muestra las relaciones entre los objetos y los mensajes que intercambian. Diagramas de secuencia: Muestra las interacciones expresadas en funcin de secuencias temporales. DIAGRAMAS DE ESTADO La estructura esttica y del comportamiento dinmico, las vistas funcionales se pueden utilizar para describir a los sistemas. Las vistas funcionales ilustran la funcionalidad que proporciona un sistema. Los casos de uso son las descripciones funcionales del sistema. Normalmente, son modelados en la etapa de anlisis de requisitos para describir y capturar cmo los actores podran utilizar un sistema. Los diagramas de casos de uso deberan capturar solamente cmo un actor puede usar un sistema, pero no cmo debe ser construido dicho sistema. Los diagramas de estado muestran el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicacin en respuesta a eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones. Tambin ilustran qu eventos pueden cambiar el estado de los objetos de la clase. Normalmente contienen: estados y transiciones. Como los estados y las transiciones incluyen, a su vez, eventos, acciones y actividades, vamos a ver primero sus definiciones. Al igual que otros diagramas, en los diagramas de estado pueden aparecer notas explicativas y restricciones. Diagramas de Casos de Uso Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto de vista del usuario. Por lo tanto los casos de uso determinan los requisitos funcionales del sistema, es decir, representan las funciones que un sistema puede ejecutar. Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente

tiles en la comunicacin con el cliente. Elementos bsicos Actores: Los actores representan un tipo de usuario del sistema. Se entiendo como usuario cualquier cosa externa que interacta con el sistema. No tiene por qu ser un ser humano, puede ser otro sistema informtico o unidades organizativas o empresas. Siempre hay que intentar independizar los actores de la forma en que se interacta con el sistema. Por ejemplo un teclado no es un actor en la mayor parte de los casos, slo un medio para introducir informacin al sistema. Suele ser til mantener una lista de los usuarios reales para cada actor. Un actor en un diagrama de casos de uso representa un rol que alguien puede estar jugando, no un individuo particular por lo tanto puede haber personas particulares que puedan estar usando el sistema de formas diferentes en diferentes ocasiones: socio de biblioteca y bibliotecario.

Caso de uso: Es una tarea que debe poder llevarse a cabo con el apoyo del sistema que se est desarrollando. Se representan mediante un vulo. Cada caso de uso debe detallarse, habitualmente mediante una descripcin textual. Socio Biblioteca

SISTEMAS En el Sistema de Informacin en Lnea (SIL), usted encontrar novedades relacionados con los temas de su inters, promociones, noticias y complementos de los libros de nuestro fondo editorial. Ingresando a nuestro sistema usted podr:

Obtener informacin adicional, complementaria sobre los libros adquiridos de nuestro fondo.

El derecho de consultar y bajar actualizaciones permanentes de los textos. Bajar complementos y adiciones de libros que lo requieran.

BENEFICIOS PARA LAS PERSONAS QUE SE REGISTRAN EN EL SISTEMA SIL 1.- Los usuarios que se registren al Sistema de Informacin en Lnea SIL de ECOE Ediciones sin que hayan adquirido un libro de nuestra editorial, tendrn los siguientes beneficios:

Descargar documentos de dominio pblico que se encuentren en la seccin de descargas generales.

Servicio de informacin permanente sobre el tema de su especializacin o inters.

Noticias de eventos acadmicos, seminarios cursos de su rea.

2.- Servicios de informacin para el cliente que registre la compra de un libro. En elSistema de Informacin en Lnea SIL de ECOE Ediciones tendr acceso a los siguientes servicios:

Noticias y aplicativos y software va internet. Derecho a bajar complementos de los libros adquiridos. Derecho a las actualizaciones digitales de los libros que adquiera de nuestro sello editorial.

Descargar documentos de dominio pblico y que se encuentren en la seccin de descargas generales.

Servicio de informacin permanente sobre el tema de su especializacin o inters.

Noticias de eventos acadmicos, seminarios cursos de su rea. Descuentos especiales por compra de nuestros libros.

SISTEMA EN TIEMPO REAL Un sistema de tiempo real es aquel en el que se establecen restricciones temporales para la obtencin de resultados o la realizacin de operaciones. El funcionamiento correcto del sistema requiere, por tanto, no solo que las operaciones se realicen correctamente, si no que se realicen en el momento y con la duracin adecuada.1 Si se cumple esta condicin se dice que el sistema es predecible. Tiempo real no es necesariamente sinnimo de rapidez; un sistema de tiempo real garantiza que el rendimiento temporal del sistema es el suficiente para resolver el problema al que est dedicado. Los procesos en que el fallo al cumplir una restriccin temporal

tienen consecuencias severas se denominan de tiempo real duro o sistemas de tiempo real de misin crtica. Si no hay ninguna restriccin temporal de estas caractersticas y se puede permitir que las restricciones temporales sean vulneradas en ocasiones se dice que estamos ante un sistema de tiempo real suave.1 Un ejemplo que ilustra los puntos anteriores es el de un robot que necesita tomar una pieza de una banda sinfn. Si el robot llega tarde, la pieza ya no estar donde deba recogerla. Por lo tanto el trabajo se llev a cabo incorrectamente, aunque el robot haya llegado al lugar adecuado. Si el robot llega antes de que la pieza llegue, la pieza an no estar ah y el robot puede bloquear su paso.

Anlisis y diseo de sistemas en tiempo real Las caractersticas especiales de los sistemas en tiempo real diferentes a los dems tipos de sistemas introducen en la definicin del sistema una serie requerimientos no funcionales, que no se refieren directamente a las

funciones especficas si no a propiedades emergentes como por ejemplo, requisitos de fiabilidad, eficiencia o implementacin.

SISTEMA DE INFORMACION

Un sistema de informacin (SI) es un conjunto de elementos orientados al tratamiento y administracin de datos e informacin, organizados y listos para su uso posterior, generados para cubrir una necesidad u objetivo. Dichos elementos formarn parte de alguna de las siguientes categoras:

Personas Datos Actividades o tcnicas de trabajo Recursos materiales en general (generalmente recursos informticos y de comunicacin, aunque no necesariamente).

Todos estos elementos interactan para procesar los datos (incluidos los procesos manuales y automticos) y dan lugar a informacin ms elaborada, que se distribuye de la manera ms adecuada posible en una determinada organizacin, en funcin de sus objetivos.

Habitualmente el trmino se usa de manera errnea como sinnimo de sistema de informacin informtico, en parte porque en la mayor parte de los casos los recursos materiales de un sistema de informacin estn constituidos casi en su totalidad por sistemas informticos. Estrictamente hablando, un sistema de

informacin no tiene por qu disponer de dichos recursos (aunque en la prctica esto no suela ocurrir). Se podra decir entonces que los sistemas de informacin informticos son una subclase o un subconjunto de los sistemas de informacin en general.

SISTEMAS MOVILES CON CONEXIN A INTERNET

Una aplicacin mvil es un programa que usted puede descargar y al que puede acceder directamente desde su telfono o desde algn otro aparato mvil como por ejemplo una tablet o un reproductor MP3.

Usted necesita un smartphone o algn otro aparato mvil con acceso a internet. No todas las aplicaciones funcionan en todos los aparatos mviles. Cuando usted compra uno de estos aparatos debe usar el sistema operativo y el tipo de aplicaciones que corresponde a ese aparato. Los sistemas operativos mviles Android, Apple, Microsoft y BlackBerry tienen tiendas de aplicaciones que operan en lnea en las cuales usted puede buscar, descargar e instalar las aplicaciones. Algunos comerciantes minoristas tambin operan tiendas de aplicaciones en internet. Usted tendr que usar una tienda que le ofrezca las aplicaciones que funcionen con el sistema operativo de su aparato. Para establecer una cuenta, es posible que tenga que suministrar el nmero de una tarjeta de crdito, especialmente si va a descargar una aplicacin que no es gratis.

Cuando usted se registra en una tienda de aplicaciones o cuando descarga aplicaciones individuales, es posible que le pidan su autorizacin para que permita que se acceda a la informacin de su aparato. Desde algunas aplicaciones se puede acceder a:

Su lista de contactos de telfono y de email.

Al registro de llamadas. A los datos transmitidos por internet. A la informacin de su calendario. A llos datos de localizacin del aparato. Al cdigo de identificacin exclusivo de su aparato. A informacin que indica la manera en que usted usa la aplicacin propiamente dicha.

Algunas aplicaciones solamente pueden acceder a los datos necesarios para su funcionamiento. Otras pueden acceder a datos que no estn relacionados con el propsito de la aplicacin. Si mientras usted usa su aparato mvil est suministrando informacin, alguien puede recolectarla ya sea el creador de la aplicacin, la tienda de aplicaciones, un anunciante o una red de publicidad. Y si recolectan sus datos, es posible que los compartan con otras compaas.

3. CONSTRUCCIN. El anlisis da como resultado el modelo de requerimientos descrito por los siguientes productos: Un conjunto de requisitos no funcionales y las limitaciones, tales como el tiempo mximo de respuesta, rendimiento mnimo, confiabilidad, plataforma de sistema operativo, y as sucesivamente Un modelo de casos de uso, que describe la funcionalidad del sistema desde el punto de vista de los actores Un modelo de objetos, que describe las entidades manipuladas por el sistema Un diagrama de secuencia para cada caso de uso, que muestra la secuencia de interacciones entre los objetos que participan en el caso de uso

El modelo de anlisis describe el sistema completo desde el punto de los actores de vista y sirve como base de la comunicacin entre el cliente y los desarrolladores. El modelo de anlisis, sin embargo, no contiene informacin

sobre la estructura interna del sistema, su configuracin de hardware o, en trminos generales, la manera en que se debe realizar. El diseo del sistema es el primero paso en esta direccin. El diseo del sistema da como resultado los siguientes productos: Una lista de objetivos de diseo, que describe las cualidades del sistema que los desarrolladores deben optimizar Una arquitectura de software, que describe la descomposicin del subsistema en subsistemas desde el punto de vista de responsabilidades del subsistema, dependencias entre subsistemas, correspondencias de los subsistema con el hardware, y decisiones polticas principales, como el flujo de control, control de acceso y almacenamiento de datos.

Los objetivos de diseo se derivan de los requisitos no funcionales. Los objetivos de diseo guan las decisiones que deben tomar los desarrolladores, en especial cuando hay compromisos. La descomposicin en subsistemas constituye la mayor parte del diseo del sistema. Los desarrolladores dividen el sistema en piezas manejables para hacer frente a la complejidad: Cada subsistema se asigna a un equipo y se realiza en forma independiente. Sin embargo para que esto sea posible, los desarrolladores necesitan atacar asuntos en el nivel de sistema cuando descomponen el sistema.

3.1 DESPLIEGUE DE COMPONENTES Y ARQUITECTNICO.

Los grandes sistemas siempre se descomponen en subsistemas que proporcionan algn conjunto de servicios relacionados. El proceso de diseo inicial que identifica estos subsistemas y establece un marco para el control y comunicacin de los subsistemas se llama diseo arquitectnico. El resultado de este proceso de diseo es una descripcin de la arquitectura del software.

El proceso de diseo arquitectnico est relacionado con el establecimiento de un marco estructural bsico que identifica los principales componentes de un sistema y las comunicaciones entre estos componentes Con el fin de reducir la complejidad del dominio de aplicacin, se identificaron partes ms pequeas llamadas clases y las organiz en paquetes. Del mismo modo, para reducir la complejidad del dominio de solucin, se descomponen un sistema en partes ms simples, llamados subsistemas, que estn constituidos por una serie de clases de del dominio solucin.

3.2

TCNICAS

DE

DESARROLLO

DE

LAS

ARQUITECTURAS

DE

REFERENCIA EN DIFERENTES DOMINIOS.

Los grandes sistemas siempre se descomponen en subsistemas que proporcionan algn conjunto de servicios relacionados. El proceso de diseo inicial que identifica estos subsistemas y establece un marco para el control y comunicacin de los subsistemas se llama diseo arquitectnico. El resultado de este proceso de diseo es una descripcin de la arquitectura del software. El diseo arquitectnico es la primera etapa en el proceso de diseo y representa un enlace crtico entre los procesos de ingeniera de diseo y de requerimientos. El proceso de diseo arquitectnico est relacionado con el establecimiento de un marco estructural bsico que identifica los principales componentes de un sistema y las comunicaciones entre estos componentes El resultado del proceso de diseo arquitectnico es un documento de diseo arquitectnico. ste puede incluir varias representaciones grficas del sistema junto con texto descriptivo asociado. Debera describir cmo se estructura el sistema en subsistemas, la aproximacin adoptada y cmo se estructura cada subsistema en mdulos. Los modelos grficos del sistema presentan diferentes perspectivas de la arquitectura. Los modelos arquitectnicos que pueden desarrollarse pueden incluir: a) Un modelo estructural esttico que muestre los subsistemas o componentes que han sido desarrollados como unidades separadas.

b) Un modelo de proceso dinmico que muestre cmo se organiza el sistema en procesos en tiempo de ejecucin. Este modelo puede ser diferente del modelo esttico. c) Un modelo de interfaz: que defina los servicios ofrecidos por cada subsistema a travs de su interfaz pblica. d) Modelos de relaciones que muestren las relaciones. Tales como el flujo de datos, entre los subsistemas. e) Un modelo de distribucin, que muestre cmo se distribuyen los subsistemas entre las computadoras.

Los modelos informales y las notaciones tales como UML son las notaciones comnmente usadas para la descripcin arquitectnica.

3.2.1 LOS MODELOS DE COMPONENTES

De acuerdo con el UML, un componente es un mdulo de software ejecutable con su propia identidad e interfaces definidas, es decir, que se define en trminos muy generales y abstractos. En relacin con las tecnologas de componentes populares, tales como Enterprise Java Beans, donde la definicin es muy concreta y tecnolgicamente especfica. Un componente consiste en una o ms clases y tiene interfaces definidas. Una instancia de componente, como un objeto, tiene su propia identidad. Para alcanzar este objetivo, sin embargo, deben cumplirse diversas condiciones: Las interfaces deben ser tcnicamente Las interfaces deben ser compatibles a nivel de dominio especfico Las dependencias entre los distintos componentes se deben mantener al mnimo.

Esto tiene las siguientes consecuencias para los componentes de software: Las interfaces de un componente, en la medida de lo posible, slo contienen tipos primitivos (Integer, String, etc.).

 Las normas apropiadas del dominio especfico son necesarios para la compatibilidad del dominio especfico. Las asociaciones entre los componentes, en la medida de lo posible, se sustituir por mensajes y mecanismos de observacin.

3.2.2 ARQUITECTURA DE REFERENCIA PARA SISTEMAS DE TIEMPO REAL FUENTE DE ALIMENTACIN

En su forma ms simple, un sistema informtico consta de una CPU y la memoria interconectados por un bus. Hay tres buses en todo el sistema: el de corriente elctrica, direcciones y datos. Al crear sistemas en tiempo real empotrados no hay margen para el error. La naturaleza demanda de un producto final que ser poderoso, eficiente y confiable. Los desarrolladores sofisticados confan en las soluciones de patrones de diseo que proveen soluciones a cambios recurrentes de diseo para la construccin de sistemas de evaluacin en tiempo real y a prueba de fallos. Los patrones de diseo en tiempo real es la referencia ms importante para los desarrolladores que buscan emplear esta tcnica de gran alcance. El UML es ampliamente aceptado como el lenguaje estndar de facto para la especificacin y diseo de sistemas intensivos en software utilizando un enfoque orientado a objetos. Al reunir a los "mejores de su clase" en tcnicas de especificacin. Con respecto a los sistemas en tiempo real son los modelos de comportamiento UML los que son de inters. Un Sistema de Tiempo Real (STR) puede definirse como aqul que debe completar sus actividades en plazos de tiempo predeterminados. Un campo clsico de aplicacin de los Sistemas de Tiempo Real es el de los sistemas de control. No obstante, muchos sistemas de tiempo real no pertenecen a los denominados sistemas de control.

Un ejemplo tpico de un sistema de control es un controlador remoto de la temperatura de un horno de fundicin de aceros especiales que acta en funcin de la temperatura del mismo. El sistema de control (controlador) puede leer los sensores de temperatura del horno cada los valores recibidos, del instante de tiempo considerado y de la situacin del horno decide incrementar o decremento la temperatura actuando sobre el sistema de calentamiento. Para controlar o monitorizar un sistema externo, el diseador del STR deber construir un modelo del sistema a controlar en el que incluya la informacin necesaria para poder controlar la evolucin dinmica del mismo. A esta informacin se le denomina estado.

3.2.3 ARQUITECTURA DE REFERENCIA PARA SISTEMAS MVILES CON CONEXIN A INTERNET.

La arquitectura bsica de una aplicacin web incluye navegadores, una red y un servidor web Figura 3.16. Navegadores solicitan "pginas web" desde el servidor. Cada pgina es una mezcla de contenido y el formato de instrucciones, expresada con HTML. Algunas pginas incluyen secuencias de comandos de cliente que son interpretados por el navegador. Estas secuencias de comandos definen 62 62 comportamiento dinmico adicional para la pgina de presentacin y a menudo interactan con el navegador, pginas de contenido y controles adicionales (Applets, controles ActiveX y plug-ins). El usuario ve e interacta con el contenido de la pgina. A veces el usuario introduce informacin en elementos de campo de la pgina y la entrega al servidor para su procesamiento. El usuario tambin puede interactuar con sistema desplazndose a diferentes pginas del sistema a travs de hipervnculos. En cualquier caso, el usuario es el suministro de entrada al sistema que puede alterar el "Estado del negocio" del sistema. Los servidores web de hoy han mejorado el diseo bsico. Hoy estn mucho ms conscientes de la seguridad e incluir caractersticas como administracin de

estado de cliente en el servidor, integracin de procesamiento de transaccin, administracin remota y recursos agrupacin para mencionar slo algunas. Los servidores web de hoy en da se pueden dividir en tres categoras principales: secuencias de comandos, pginas y pginas compiladas un hbrido de los dos. Modelando pginas Web Pginas, Web ya sea mediante secuencias de comandos o compilado, mapea uno a uno a los componentes de UML. Un componente es una parte "fsica" y reemplazable del sistema. La vista de aplicacin (vista de componentes) del modelo describe los componentes del sistema y sus relaciones. En un nivel, un diagrama de componentes de un sistema web es como un mapa del sitio. Como los componentes representan slo la presentacin fsica de interfaces, no son adecuados para modelar las colaboraciones dentro de las pginas. Este nivel de abstraccin, extremadamente importante para el diseador y ejecutor, y debe ser parte del modelo. Podramos decir que cada pgina web es una clase UML en la vista de diseo del modelo (vista lgica), y que sus relaciones con otras pginas (asociaciones) representan hipervnculos.

3.2.4 ARQUITECTURA DE REFERENCIA PARA SISTEMAS DE INFORMACIN

Una arquitectura de sistemas de informacin consta de los sistemas de informacin bsicos requeridos por las organizaciones para coordinar el comercio mundial y otras actividades. La figura 3.21 ilustra el razonamiento que seguimos e ilustra las principales dimensiones de una arquitectura de sistemas de informacin internacionales. Las aplicaciones empresariales suelen tener datos complejos y la perdida de estos para trabajar, junto con las reglas del negocio que rompen todas las pruebas de razonamiento lgico. Aunque algunas tcnicas y patrones son pertinentes para todo tipo de software, muchos son pertinentes slo para una rama en particular.

Las aplicaciones empresariales suelen referirse a datos persistentes. Los datos son persistentes porque deben ser ms o menos utilizados entre varias ejecuciones de programas. Durante ese tiempo habr muchos cambios en la estructura de los datos para almacenar piezas de informacin sin alterar las piezas antiguas. Incluso si hay un cambio fundamental y la empresa instala una aplicacin completamente nueva para manejar un proceso, los datos tienen que migrar a la nueva aplicacin. Por lo general hay una gran cantidad de datos hasta el punto de que su gestin es una parte importante del sistema. Los sistemas ms antiguos utilizan estructuras de archivos indexados como VSAM IBM y ISAM. Los sistemas modernos suelen utilizar bases de datos relacionales en su mayora.

3.2.5 ARQUITECTURA DE REFERENCIA PARA AMBIENTES VIRTUALES DE APRENDIZAJE

Con la aparicin de la Inteligencia Artificial (IA) a principios de los 60 y su aplicacin al desarrollo de sistemas de enseanza se acuo el termino Sistema Inteligente de Tutora (SIT). Un SIT (Sleeman y Brown, 1982) tiene como objetivo actuar como un tutor humano inteligente, de manera que sea capaz de orientar y ensear a un estudiante en el proceso de aprendizaje de una materia dada, detectar los errores que el estudiante comete, tratar de determinar el punto en que ste falla para corregirlo y aclarar confusiones o dudas que se le presenten, considerando las peculiaridades de cada estudiante y permitiendo, de esta forma, una enseanza mas individualizada. Para poder alcanzar dicho objetivo, durante el desarrollo de un sistema de este tipo deben abordarse cuestiones como la representacin en el sistema de la materia objeto de estudio, la representacin del conocimiento acerca del estudiante, la estrategia de comunicacin con el estudiante, y las estrategias de tutora a seguir. La arquitectura ms general de un SIT (Wenger, 1987),

comprende cuatro componentes principales, cada uno de los cuales viene a dar respuesta a una de las cuestiones anteriores: Modulo Experto: contiene el conocimiento que el estudiante debe adquirir, y sirve para comprobar el grado de correccin de las acciones y respuestas del estudiante. Modelo del Estudiante: contiene toda la informacin que el SIT posee acerca del estudiante: el estado de sus conocimientos actuales, la naturaleza de sus problemas de aprendizaje o su historial desde que empez a utilizar el sistema. Se emplea para predecir el nivel de comprensin del estudiante y reconocer su forma particular de aprendizaje. Mdulo de Comunicacin: soporta la interfaz con el estudiante, proporcionando salidas de la forma ms adecuada para cada estudiante e interpretando sus respuestas segn las clasificaciones a las que el mdulo de tutora es sensible. Mdulo de Tutora: contiene las estrategias, reglas y procesos que dirigen las interacciones del sistema con el estudiante, y que permiten al SIT tomar decisiones acerca del material que debe presentar, qu preguntas o ejemplos sugerir y por qu y cundo se debe interrumpir al estudiante. Se basa en la informacin proporcionada por el modelo del estudiante. La manera ms clsica de construir un SIT utilizando esta arquitectura se puede asimilar con una tpica arquitectura en tres capas, donde el Mdulo de Comunicacin hace las veces de interfaz de usuario, el Mdulo de Tutora contiene la lgica de la aplicacin y los Mdulos Experto y del Estudiante sern sendas bases de datos, una con el conocimiento del experto y otra con la informacin que se posee sobre el estudiante. Esta arquitectura, aunque su cliente para un SIT tradicional, no se ajusta a los requisitos de un EV (Entorno virtual) por varios motivos: Un EV debe servir para poder entrenar a un grupo de estudiantes al mismo tiempo, y no a uno solo, y debe ser capaz de adaptar el entrenamiento a las necesidades de cada alumno, lo cual no est contemplado en la arquitectura. El Mdulo del Estudiante debe modelar el conocimiento de cada estudiante, pero tambin el del grupo completo.

El estudiante no queda fuera de los lmites del sistema, ya que la interaccin con el EV se realiza a travs de un avatar que se encuentra dentro del propio EV y que est controlado con dispositivos de Realidad Virtual como guantes o sensores. Adems, cada estudiante tiene una visin distinta del entorno dependiendo del punto en el que se encuentre. Aunque ser muy intuitivo considerar que el EV forma parte de la interfaz grfica de usuario, existe una razn que impide hacer esta consideracin. Cuando se utiliza una interfaz grfica clsica, la interaccin con la aplicacin se realiza a travs de mens, botones y controles similares, pero el fin no es aprender a utilizar esos controles, sino que son un medio para comunicarse con la aplicacin. Por contra, cuando se utiliza un EV, el fin que se persigue si es aprender a manipular lo que aparece dentro de l. Por este motivo, es necesario que el SIT tenga conocimiento de lo que ocurre dentro del EV, su estado y las posibilidades de interaccin Aunque para el desarrollo de la arquitectura conceptual de un sistema software no es necesario especificar la forma en que se construir (e.g. utilizando objetos o agentes figura 3.26), en este punto se considera adecuado y necesario introducir los agentes en el diseo arquitectnico. Esto se debe a que sus caractersticas particulares pueden obligar a la modificacin de la arquitectura si su utilizacin se deja para ms adelante.

3.2.6 ARQUITECTURAS DE REFERENCIA PARA LNEAS DE PRODUCTOS

Qu es una Lnea de Productos de Software (LPS) La idea bsica es el ensamblaje de partes de software previamente elaboradas e inspirada en los procesos de produccin de sistemas fsicos. Produccin de aviones, vehculos, computadores, aparatos electrnicos, etc., fundamentada en la reutilizacin de Software y asumiendo la existencia de una industria de partes Antecedentes La reutilizacin de software es el proceso de imp lementar o actualizar sistemas de software usando activos de software existentes (Sodhi y Sodhi, 1999)

"Reutilizacin de software es el proceso de crear sistemas de software a partir de software existente, en lugar de desarrollarlo desde el comienzo" (Sametinger, 1997) Existen varias modalidades de reutilizacin utilizadas en empresas de software: Individual Oportunista Gestionada: o Institucionalizada, sistemtica, planificada, mejorada

Tradicionalmente, la reutilizacin ha estado basada en oportunidad. Los componentes que se almacenan en un repositorio a la espera de una oportunidad de reutilizacin.

Documentacin de proyecto

Instituto Tecnolgico Superior de Tepeaca

Ingeniera en Sistemas Computacionales

Proyecto: Sistema de pedidos para restaurantes CATEDRATICO: Claudia Nelly Lpez Morales MATERIA: Desarrollo de proyectos de software SEMESTRE: Octavo A INTEGRANTES: JUAN SERGIO PEREZ TAPIA 09791013 elmiguelon740@hotmail.com JOSE RICARDO RAMIREZ BENITEZ 09791014 ramirez_ricardo6@hotmail.com MARTIN JIMENEZ MARTINEZ 08791175 martin-and-mvo@hotmail.com

PERIODO: Feb-jun. 2013

TEPEACA DE NEGRETE, A 2 DE MAYO 2013

NDICE

INTRODUCCIN .................................................................................................... 36 PLANTEAMIENRO DEL PROBLEMA ..................................................................... 38 OBJETIVOS ............................................................................................................ 39 JUSTIFICACION ..................................................................................................... 40 LIMITACION ............................................................................................................ 40 MODELO 4+1 VISTAS ............................................................................................ 41 MARCO TEORICO.................................................................................................. 42 HIPOTESIS ............................................................................................................. 43 MODELO DE ANALISIS .......................................................................................... 44 MODELO DE REQUISITOS .................................................................................... 45 DIAGRAMA DE COMPONENTES .......................................................................... 47 INTERFACES DE ALTA FIDELIDAD ...................................................................... 47 PLAN DE PRUEBAS ............................................................................................... 49 CONCLUSIONES.................................................................................................... 57 BIBLIOGRAFIA ....................................................................................................... 81

INTRODUCCIN La incorporacin de la tecnologa en las necesidades de la vida diaria permite potenciar cambios significativos en la sociedad por ello se han desarrollado diversos software dedicados a facilitar las tareas de las personas, programas didcticos como sinnimos para designar genricamente los programas para ordenador creados con la finalidad especfica de ser utilizados como medio didctico, es decir, para facilitar los procesos que se realizan el da a da. El desarrollo logrado por la tecnologa de la informacin y la comunicacin ha puesto al alcance de la sociedad una serie de herramientas que potencian resultados significativos. . No obstante, el objetivo ms concreto es llevar a cabo la implementacin utilizando un concepto innovador. Este concepto consiste en que el cliente tenga acceso a dicha aplicacin desde su propia mesa y pueda seleccionar los

productos que desee directamente desde sta, sin tener que necesitar al mesero para realizar su pedido. Para el punto de vista del desarrollador, es adquirir experiencia en la implementacin de este tipo de sistemas y aplicaciones, que cada vez estn ms extendidos en la sociedad. El sistema de pedidos consistir en comunicar en tiempo real al cliente con el operador para que este tome su pedido a distancia pero a la misma vez este pedido no sea llevado a una mesa distinta de la que recibi la orden.

PLANTEAMIENRO DEL PROBLEMA Determinacin de aspectos de optimizacin de la atencin, servicio y otros factores que inciden en el rendimiento que los restaurantes prestan a sus clientes en el da a da de su labor y los efectos que estos causan sobre ellos,

OBJETIVOS General Implementar un sistema eficaz, confiable, en tiempo real y de fcil manejo que gestione los pedidos un restaurante desde el punto de vista de los usuarios administrador y cliente Especficos Limitar las tareas de los meseros a solo tener que llevar el pedido y limpiar las mesas. Agilizar las entradas y salidas de pedidos Eliminar las posibilidades de error en la entrega de pedidos

JUSTIFICACION Dado que la reputacin de algunos restaurantes estn decayendo, se pretende dar un impulso o reintegracin al mbito social para brindar un mejor servicio como mayor atencin y un apoyo ecolgico lo la reduccin de papel en los pedidos

LIMITACION Solo el administrador podr cancelar las rdenes ya enviadas.

MODELO 4+1 VISTAS LOGICA DESARROLLO FISCA PROCESO ADMINISTRADOR (resturate) ING. MARTIN JIMENEZ, ANDRES AGUILAR ING. RICARDO RAMIREZ, JUAN SERGIO CLIENTES Y ADMINISTRADORES

Programadores administracin del software o aplicacin

MARCO TEORICO Se ha detectado en restaurantes ms frecuentados que en este ltimo semestre ha venido aumentando considerablemente la insatisfaccin de los clientes, adems de un insuficiente desempeo de los meseros debido a que dichos restaurantes o comedores no cuentan con un sistema de control de pedidos, ya que todo el control de varias mesas son tomadas por el mismo mesero y esto ocasiono un aumento considerable en la posibilidad de error en la entrega de los pedidos y el aumento del tiempo para recibir la orden deseada La implementacin de un sistema de rdenes de pedidos a distancia y en tiempo real ayuda a que esta tenga un impulso no tanto con el cumplimiento que se pretende obtener por parte de los en cargados del restaurante o comedor, sino que al mismo tiempo esto se ver reflejado en un mayor nmero de clientes satisfechos que por la mejor atencin no dudaran en regresar.

HIPOTESIS La creacin de un sistema de pedidos ayudara a que el personal (meseros) se reserven el discutir con lis clientes por no entregar el pedido correcto

MODELO DE ANALISIS El sistema atencin al cliente se desarrollara para el restaurant APETITO est elaborado para usarlo en dos opciones EL BUEN que son

ADMINISTRADOR y CLIENTE donde: ADMINISTRADOR: activa mesa desactiva mesa distribucin de mesa tipo de pago liquidacin de cuenta

CLIENTE: men yuhjn ,benviar pedido cancelar pedido

1.1 SISTEMA GENERAL Muestra el men general de ambos (administrador y cliente)

FIGURA 1.1 SISTEMA GENERAL

1.2 Menu de administrador: Es el sistema general donde administra la activacion y deactivacion de mesa

FIGURA 1.2 Menu de administrador

1.3 Menu de cliente: En este menu antes mencionado el cliente tendra la oportunidad de ver el menu de comida y enviar el pedido y cancelar

Figura 1.3 Menu de cliente: Diagrama de clases

MODELO DE REQUISITOS Tabla de Acceso del Administrador Nombre del archivo Descripcin Campo Usuario Contrasea Fecha de creacin Tabla de Administrador Tipo Varchar Varchar Longitud Descripcin 30 15 Nombre del Administrador Contrasea de acceso al sistema Relaciones Campos llave Administrador

Tabla de Clientes Nombre del archivo Cliente Fecha de creacin Descripcin Campo No Cliente No Pedido No_Mesa Pedidos del Cliente Tipo Varchar Varchar Varchar Longitud Descripcin 25 20 15 Nmero del Cliente Nmero del Pedido del Cliente Numero de Mesa Asignada al Cliente

Relaciones Cliente Tabla de

Campos llave

Cliente

Control Tabla de Meseros Nombre del archivo Mesero Fecha de creacin Descripcin Informacin bsica del Mesero Campo Mesero Nombre_Mesero Apellido_Paterno Tipo Varchar Varchar Varchar Longitud Descripcin 20 20 15 Nombre del Mesero Nombre del Mesero que acceso Apellido paterno del Mesero

Apellido_materno

Varchar

15

Apellido materno del Mesero

Fecha_nac Lug_Proc

Varchar Varchar

15 30

Fecha de Nacimiento del Mesero Lugar de Procedencia del Mesero

Edo_Civ

Decimal

15

Estado Civil del Mesero Mesero

Relaciones Mesero de la tabla acceso al sistema

Campos llave

DIAGRAMA DE COMPONENTES

Elemento

Descripcin

Interfaz cliente Interfaz

Es la forma con la que el cliente interacta con el administrador Para pedir los alimento que desea ingerir El administrador recibe los pedidos de los clientes, adems de

administrador asignar el mesero correspondiente Base de datos mesero cocina Se almacenara todos los pedidos y todo lo relacionado con los datos de informacin El mesero atender la mesa que le ha sido asignada Recibir la orden delo que se prepara

INTERFACES DE ALTA FIDELIDAD

El administrador se le asignara un usuario y un password para la seguridad y administracin del restaurante.

El administrador en esta interfaz tendr la opcin de alta y baja de mesa, mesero, asignar mesa y asignar mesero.

En esta interfaz podrn dar de alta y baja de mesa ya que el restaurante solo tiene 25 mesas y sern las nicas que podr dar de alta y baja de mesa.

En la interfaz podrn dar de alta y baja de mesero.

Esta interfaz es para el usuario ya que en esta podr ingresar el platillo, bebidas y postres mostrando a mano izquierda su pedido, si el cliente no le gusta el platillo tendr la opcin de limpiar platillo no deseado.

Diagrama de base de datos

PLAN DE PRUEBAS

TIPOS

DEFINICIN Las unitarias como verificar funcionalidad estructura pruebas tienen objetivo

OBJETIVOS

ESTRATEGIA *Se realizarn pruebas para cada parte del proyecto empezando por el diseo de interfaz, hasta la unificacin de todos los componentes del sistema. Generar pruebas que identificar: *Vialidad *Funcionabilidad casos de

la * Comprobar la y Funcionabilidad de parte por parte del

Pruebas Unitarias

cada componente proyecto para individualmente corroborar la

del sistema una funcionabilidad del vez que ha sido mismo y verificas codificado. los posibles errores.

necesarios permitan

Las pruebas de sistema buscan

diferencias entre la solucin *Realizar Set de Pruebas a en partir de los no

desarrollada y los requerimientos, enfocndose la

Requerimientos funcionales en el sistema.

identificacin Corroborar que el

detectados

de los errores que sistema est en se Pruebas de Sistema puedan ptimas

generar entre la Condiciones para especificacin funcional diseo sistema, y poderse ejecutar el de manera del completa y as efectiva.

*Realizar

pruebas

de

carga: Altos volmenes de informacin y del

productividad sistema empleado.

como, el negocio objeto de la Identificar cuellos de posibles botella o de

aplicacin.

problemas

rendimiento del sistema

El objetivo de las pruebas integracin verificar correcto de es el Comprobar correctamente las

ensamblaje entre interfaces del los mdulos componen distintos sistema que no que tengan errores y la que estn

solucin una vez establecidas para que han sido ejecutarse. *Combinacin de

probados Pruebas de Integracin unitariamente con el fin de que

mdulos de bajo nivel en grupos que realicen una misma subsuncin funcin o

comprobar interactan correctamente travs de

especfica,

con el fin de reducir el a sus nmero de pasos de integracin. *Se eliminan los mdulos y que la impulsores sustituyen mdulos y por de se los nivel

interfaces internas externas, cubren funcionalidad establecida y se

superior en la jerarqua.

ajustan requisitos

los no

funcionales especificados en las verificaciones correspondientes.

En esta prueba se valida que el sistema comunique manera Pruebas de Interoperabilidad se de exitosa

Prueba directa con los servicios que se encuentren disponibles en un ambiente de pruebas controlado suministrado por Agenda de conectividad de red

con los sistemas Validar la externos con que interoperabilidad se requiera, a de de la solucin con los sistemas

acuerdo

requerimientos no externos. funcionales. En esta prueba se valida que el sistema mantenga correcta funcionalidad despus de la de su

incorporacin un correccin nuevo Pruebas de Regresin

ajuste, o

requerimiento. Es una prueba

funcional

tcnica que valida que el sistema

siga funcionando perfectamente despus de que las correcciones

sean aplicadas.

La

prueba

funcional es un proceso procurar encontrar discrepancias entre el software desarrollado y la especificacin funcional. La para

prueba funcional normalmente es

una actividad de caja negra. Esta prueba validar: Pruebas Funcionales Los procesos y reglas de negocio establecidas, Que cumplan se los permite

requerimientos funcionales establecidos

Las pruebas de usabilidad una medir forma que son de tan

bien puede una persona usar un objeto hecho por el hombre, como puede pgina una interfaz Pruebas de Usabilidad usuario, ser una web, de un

documento o un dispositivo.

Estas tienen enfoques:

pruebas dos

Pruebas

de

seguridad de la aplicacin; donde se verifica que un actor solo pueda acceder a las

funciones y datos Pruebas de que su usuario

Seguridad

tiene permitido. Pruebas seguridad de del

sistema; donde se verificar que solo los actores con acceso al sistema y a la aplicacin estn habilitados para accederla.

El propsito esta prueba

de es y la

establecer mantener

integridad de los Pruebas de Configuracin productos de

software a travs del ciclo de vida del proceso del mismo. Estas pruebas

aseguran que el software pueda a de

recuperarse fallas hardware, software o

mal

funcionamiento de la red sin

prdida de datos

o de integridad de los datos.

El esta Pruebas de Recuperacin a Fallas

objetivo prueba

de es

verificar que los procesos recuperacin (manual automticos) realice apropiadamente: las datos, base de las o se de

aplicaciones y el sistema a un

estado conocido y deseado.

El objetivo de las pruebas de aceptacin es validar que la solucin desarrollada cumpla con el funcionamiento Pruebas de Aceptacin esperado y permitir al usuario de dicho sistema determine su

aceptacin, desde el punto de vista de su funcionalidad y de su rendimiento. Esta prueba se realiza mediante el proceso de validacin de caja negra.

Plan de Pruebas

Introduccin

Propsito del Plan El propsito de este plan es planificar, estructurar y documentar la planificacin de las pruebas de aceptacin del sistema a realizar, as como la estrategia a utilizar para su ejecucin. Alcance Luego de finalizar las pruebas de sistema, el programa se encuentra completamente ensamblado, y se han encontrado y corregido los errores entre los mdulos, mtodos, clases y objetos. En este punto se comienza con la etapa de las pruebas de validacin de requerimientos ms conocida como pruebas de aceptacin. stas se enfocan en las acciones que realiza el usuario adems de las salidas del sistema que puedan ser reconocidas por l; dichas acciones y salidas engloban las expectativas del usuario, y estn definidas en las especificaciones de los requerimientos del software.

Las pruebas de aceptacin, se realizan a los requerimientos funcionales, y a los no-funcionales como facilidad de uso, recuperacin, eficiencia, entre otros; y se pretende lograr: correccin, vale decir, carencia de ambigedad; completitud, es decir, especificacin completa y clara del problema; y por ltimo pero no menos importante, consistencia, quiere decir, que no haya requisitos contradictorios.

El plan que a continuacin se detalla pretende dar una visin general sobre las actividades a realizar; sobre las pruebas consideradas; adems de una explicacin global que se consider para la realizacin de los documentos a entregar, ya que darn una mayor informacin relacionada a la evaluacin y reportes de este tipo de pruebas.

Definiciones y Acrnimos

No se utilizan en este plan. Referencias Especificacin de Requisitos de Software v1.0, 2007 Visin General del Plan Este documento consta de las siguientes secciones: una introduccin, los requerimientos de pruebas que son obtenidos del ERS y luego la estrategia de pruebas a seguir.

Requerimientos de Pruebas Introduccin Este captulo documenta los requerimientos de prueba durante la Fase de Pruebas del Sistema e Integracin para el Sistema de Gestin de Club de Tenis. Filosofa de la prueba Generalidades

El objetivo principal de las pruebas unitarias del sistema ser el de establecer un nivel de confianza que nos permitir asegurar la aceptacin del sistema por los usuarios (profesor, jefe de prctica) en las posteriores pruebas de aceptacin.

Se probar que la aplicacin cumpla con los requerimientos de alto nivel que fueron especificados previamente, verificando que se cumple satisfactoriamente con las funcionalidades y caractersticas necesarias para que los usuarios satisfagan estos.

reas funcionales

Esta seccin describe las reas funcionales generales que debern ser probadas como parte de la fase de pruebas del sistema.

Funcionalidad especificada en el ERS. Manejo de los datos y transacciones involucradas en las funcionalidades del punto anterior. Rendimiento al ejecutar las funcionalidades del primer punto.

Categoras de resultados de prueba

Esta seccin describe las categoras que pueden ser asignadas los resultados de prueba en un Caso de Prueba.

1. xito: El resultado de la prueba es conforme al resultado esperado. 2. Aceptable: El resultado de la prueba indica que el sistema difiere de la especificacin aceptada pero es aceptable, no son necesarios cambios en la aplicacin, pero requiriendo un cambio en la Especificacin Funcional. 3. Tolerable: El resultado de la prueba es incorrecto, la aplicacin en prueba trabaja y podra ser aceptada, pero la falla deber ser rectificada en el periodo de tiempo acordado. 4. Intolerable: El resultado de la prueba es incorrecto, y la falla debe ser corregida antes de concluir la fase de prueba. 5. Error: El resultado de la prueba observado es correcto, pero el resultado esperado de acuerdo a los scripts de prueba son incorrectos.

Entorno de la prueba Generalidades

En esta seccin se da una breve descripcin del entorno de prueba:

Las pruebas se realizarn principalmente en el laboratorio de Desarrollo de Programas 2 (V201). El nmero de computadoras con que se contar ser de acuerdo al tipo

de prueba, entre una y cuatro computadoras. En los laboratorios se cuenta con acceso al Servidor y definicin de Datos del Sistema de Gestin de Club de Tenis

Hardware

Recursos del sistema Recurso Nombre/Tipo/Nmero de serie Servidor Proporcionado por el laboratorio de ingeniera Sistemas Computacionales PCs Desarrollo de pruebas 4 Proporcionadas por el laboratorio de ingeniera en Sistemas computacionales

Software

En las PCs de prueba debern estar instaladas las siguientes aplicaciones de software:

Sistema Operativo Windows 7 o Windows 8 JAVA2 v1.5.1 o mayor Eclipse SDK v3.2 o mayor Base de Datos SQL Server

Datos de prueba Se desarrollarn y especificarn conjuntos de datos de prueba, tomando las muestras necesarias para la ejecucin de las pruebas, de manera que se verifique que cumple con diversos tipos de datos.

Roles y responsabilidades del equipo de pruebas

Cargo Administrador de pruebas

Recursos humanos Recursos mnimos Responsabilidades especficas / necesarios comentarios Juan Sergio Prez Proporcionar atencin especial al Tapia funcionamiento correcto de las tareas principales del sistema. Responsabilidades: Proporcionar direccin tcnica. Adquirir los recursos apropiados. Administracin de reportes. Jos Ricardo Ramrez Identificar, asignar la prioridad, e Bentez implementar los casos de la prueba a ejecutar. Responsabilidades: Generar el plan de prueba. Generar la especificacin de los distintos tipos de prueba. Generar el modelo de prueba. Evaluar la eficacia del esfuerzo en la prueba. Jimnez Realizar las pruebas Responsabilidades: Ejecutar pruebas.

Diseador de pruebas

Ejecutores de prueba

Martin Martnez

Administrador del sistema de pruebas

Juan Tapia

Sergio

Registrar resultados. Recuperacin despus de errores. Documentacin de errores. Prez Asegurar el ambiente de prueba, as como mantener y manejar sus ventajas. Responsabilidades: Administrar el manejo de pruebas del sistema. Controlar el acceso de los integrantes del equipo a los sistemas de prueba.

Administrador Martin de la Definicin Martnez de Datos

Jimnez Asegurar el ambiente de los datos de prueba, as como manejar y mantener sus ventajas. Responsabilidades: Administrar los datos de prueba.

Identificacin de la prueba

Scripts de prueba

Cada caso de prueba individual deber tener un script que describa los pasos y los resultados esperados de cada prueba individual. En particular un script contiene la siguiente informacin:

Identificador de la prueba. Descripcin del objetivo de la prueba.

Descripcin del estado de la aplicacin antes de la prueba o precondiciones de la misma. Pasos precisos y no ambiguos para ejecutar la prueba. Descripcin de los resultados esperados.

Reporte de resultados

Los resultados de la prueba son registrados en un formulario de Registro de Resultados de Prueba, el cual contiene la siguiente informacin:

Nombre y versin de la aplicacin a prueba. Fase de Prueba. Fecha de Prueba. Identificador nico de prueba. Hora de ejecucin de cada Caso de Prueba. Resultado observado durante la prueba. Categora de resultado de prueba. Descripcin del error. Firma del ejecutor y del observador de la prueba.

Criterios de aceptacin

Esta seccin documenta la frecuencia de las categoras de los resultados de prueba que son consideradas para aceptar la aplicacin y pasar con xito la fase de prueba. Identificamos los siguientes criterios los cuales deben ser evaluados progresivamente.

Requerimientos de Prueba: Todos los requerimientos del sistema han sido probados? Pruebas Cubiertas: Todas las partes del software han sido probadas, incluyendo manejo de errores? Medida de Casos de Prueba: Cuntos Casos de Prueba han sido planeados, diseados, implementados, ejecutados y pasaron con xito o falla? Defectos detectados en Casos de Prueba: Es importante tener un ratio de los defectos encontrados en los casos de prueba, y de los defectos corregidos y mantenidos.

Errores de prueba

Esta seccin especfica los procesos para alcanzar la correccin de los errores observados y registrados durante la prueba.

Para cada error observado que requiera correccin de la aplicacin o de la especificacin de funcionalidades, el lder del equipo de prueba y el lder de desarrollo y sus respectivos equipos, deben de estar de acuerdo en lo siguiente:

El mbito de trabajo adicional y escalas de tiempo para la correccin. El Caso de Prueba requerido para ser re-ejecutado despus de la correccin. Dada una falla, el principal responsable de realizar la correccin es el que se encarg de desarrollar dicho componente.

Establecer prioridades de acuerdo a una serie de fallas.

Documentacin de la prueba

Esta seccin describe los documentos que deben ser generados durante la actividad de prueba. Estos documentos son los siguientes:

Scripts de pruebas y Casos de Prueba. Resultados de Pruebas siguiendo el formato especificado. Reporte consolidado de pruebas por mdulo. Certificado de prueba para formalizar el hecho de que la aplicacin en prueba ha pasado la prueba con xito.

La lista que se muestra a continuacin identifica los requerimientos especificados en el ERS que se probarn.

Pruebas Funcionales Revisar la implementacin del caso de uso Actualizar Personal. Revisar la implementacin del caso de uso Actualizar Accesorios. Revisar la implementacin del caso de uso Actualizar solicitudes Revisar la implementacin del caso de uso Actualizar Pagos. Revisar la implementacin del caso de uso Validad Usuario.

Estrategia de Pruebas Los tipos de prueba a realizar son pruebas de caso de uso, y pruebas unitarias. Pruebas por Caso de Uso

Para las pruebas de casos de uso se probarn en el siguiente orden: Validar Usuario, Actualizar personal, Actualizar socio, Actualizar Accesorios, Actualizar Instalaciones, Actualizar Curso, Actualizar Pagos, Actualizar solicitudes, Buscar Instalacin, Buscar Socio, Buscar Curso, Consultar Informacin del club, Consultar movimientos del socio, Inscribir Curso, Reservar Instalaciones. Este orden no es aleatorio, los ltimos casos de uso dependen de los primeros. Pruebas de integracin Se realizarn de manera implcita al realizar las pruebas del caso de uso. Pruebas del caso de uso Se verificar la correcta implementacin de los flujos bsicos y alternativos de todos los casos de uso a implementar en la iteracin.

Casos de Prueba

Caso de uso Validad Usuario.

Prueba 1 Objetivo Prueba: Precondicin: Descripcin la prueba: Resultados Esperados: Probar el funcionamiento del flujo bsico Validar Usuario. de Ingresar al sistema con su usuario y su contrasea.

Logra entrar al sistema. Exitoso

Prueba 2 Objetivo Prueba: Precondicin: Descripcin la prueba: Resultados Esperados: Probar el funcionamiento del flujo alternativo Cambiar Contrasea. de Seleccionar Cambiar Contrasea, e ingresar la nueva contrasea. Se muestra mensaje de confirmacin aceptando que la contrasea ha sido cambiada. Exitoso

Caso de uso Actualizar Personal.

Prueba 1 Objetivo Prueba: Precondicin: Descripcin la prueba: Probar el funcionamiento del flujo bsico Registrar Personal de Ir a Actualizar Personal, seleccionar Nuevo e ingresar todos los datos necesarios para registrar un nuevo empleado Se muestra un mensaje de confirmacin aceptando el nuevo registro. Exitoso

Resultados Esperados:

Prueba 2 Objetivo Prueba: Precondicin: Descripcin la prueba: Probar el funcionamiento del flujo para Modificar Personal. Haber creado un empleado de Ir a Actualizar Personal, seleccionar Modificar y buscar al empleado a modificar. Modificar los campos deseados Se muestra un mensaje de confirmacin aceptando la modificacin de los datos del personal. Exitoso

Resultados Esperados:

Prueba 3 Objetivo Prueba: Probar el funcionamiento del flujo para Eliminar Personal.

Precondicin: Descripcin la prueba:

Haber creado al menos un empleado. de Ir a Actualizar Personal, luego Eliminar Personal y buscar al personal a eliminar. Verificar que ese era el empleado a eliminar e internamente se le cambia el estado. Se muestra un mensaje de confirmacin que se ha eliminado el personal. Exitoso

Resultados Esperados:

Caso de uso Actualizar Curso.

Prueba 1 Objetivo Prueba: Precondicin: Descripcin la prueba: Probar el funcionamiento del flujo bsico Registrar Curso de Ir a Actualizar Curso, seleccionar Nuevo e ingresar todos los datos necesarios para registrar un nuevo curso Se muestra un mensaje de confirmacin aceptando el nuevo registro. Tolerable

Resultados Esperados:

Prueba 2 Objetivo Prueba: Probar el funcionamiento del flujo para Modificar Curso.

Precondicin: Descripcin la prueba: Resultados Esperados:

Haber creado un Curso de Ir a Actualizar Curso, seleccionar Modificar y buscar al curso a modificar. Modificar los campos deseados Se muestra un mensaje de confirmacin aceptando la modificacin de los datos del curso. Tolerable

Prueba 3 Objetivo Prueba: Precondicin: Descripcin la prueba: Probar el funcionamiento del flujo para Eliminar Curso.

Haber creado al menos un curso. de Ir a Actualizar Curso, luego Eliminar Curso y buscar al curso a eliminar. Verificar que ese era el curso a eliminar e internamente se le cambia el estado. Se muestra un mensaje de confirmacin que se ha eliminado el curso. Tolerable

Resultados Esperados:

Caso de uso Actualizar Pagos.

Prueba 1 Objetivo Prueba: Precondicin: Descripcin la prueba: Resultados Esperados: Probar el funcionamiento del flujo bsico Actualizar Pagos. Haber creado al menos un socio. de Ir a Actualizar Pagos, buscar al socio, verificar que sea el socio y luego la opcin Grabar Se muestra un mensaje de confirmacin que el pago ha sido realizado Error

Casos de uso Actualizar Solicitudes.

Prueba 1 Objetivo Prueba: Precondicin: Descripcin la prueba: Resultados Esperados: Probar el funcionamiento del flujo bsico de Actualizar Solicitudes. Ingresar al sistema como administrador. de Seleccionar Actualizar Solicitudes, y verificar que se puedan actualizar las solicitudes Se muestra un mensaje de confirmacin que se ha actualizado la solicitud. Error

Caso de uso Buscar Instalacin

Prueba 1 Objetivo Prueba: Precondicin: Descripcin la prueba: Resultados Esperados: Constatar que la bsqueda se realice de acuerdo a los filtros. de Seleccionar Buscar Instalacin e ingresar los filtros deseados. Se muestra las instalaciones que coinciden con la bsqueda. Tolerable

Caso de uso Buscar Curso.

Prueba 1 Objetivo Prueba: Precondicin: Descripcin la prueba: Resultados Esperados: Constatar que la bsqueda se realice de acuerdo a los filtros. de Seleccionar Buscar Curso e ingresar los filtros deseados. Se muestra los cursos que coinciden con la bsqueda. Tolerable

Caso de uso Consultar Informacin del club

Prueba 1 Objetivo Prueba: Precondicin: Descripcin la prueba: Resultados Esperados: Constatar que navegabilidad de la web sea accesible.

de Probar toda la web donde se muestre la informacin del club, seas socio o no socio. Se pueda acceder a toda la informacin del club Exitoso

Caso de uso Inscribir Curso.

Prueba 1 Objetivo Prueba: Precondicin: Descripcin la prueba: Resultados Esperados: Lograr que un socio pueda inscribirse en un curso determinado. Haber creado uno o ms cursos. de Seleccionar Inscribirse en Curso, e inscribirse en los cursos que desee. Se muestra un mensaje de confirmacin que el socio se inscribi en el curso. Error

Caso de uso Reservar Instalaciones.

Prueba 1 Objetivo Prueba: Precondicin: Lograr que un socio pueda realizar una reserva de una instalacin. Haber creado una o ms instalaciones

Descripcin la prueba:

de Seleccionar Reservar Instalaciones, luego buscar las instalaciones disponibles y reservar aquella que se desee. Se muestra un mensaje de confirmacin que se ha reservado una instalacin Tolerable

Resultados Esperados:

Requerimientos del Ambiente de Pruebas A continuacin se enumeran las caractersticas mnimas del ambiente para probar el Sistema de Gestin de Club de Tenis. Hardware

Intel inside de 1.40 GHz. Memoria RAM de 1 GB Se recomienda contar con 3 GB para un mejor rendimiento. Disco Duro con capacidad libre de 20Gb.

Sistema Operativo Windows 7 Windows 8.

IMPLEMENTACION

Nuestra aplicacin est construida sobre dos servidores, dos de cdigo abierto: un servidor HTTP visual tudio y un servidor de base de datos SQL server. Utilizamos el lenguaje ASP.NET (con VISUAL C#), AJAX para crear pginas web dinmicas. Resulta importante destacar tambin la utilizacin del protocolo HTTPS, que permite enviar informacin entre pginas de manera segura mediante cifrado SSL, as que cuando nos autentificamos en la aplicacin web ya sea como cliente, las pginas se muestran utilizando este protocolo seguro. A continuacin describiremos dichos componentes, as como tambin las tecnologas en las que se sustentan.

SQL server. Es uno de los SGBD ms empleados del mercado para aplicaciones web debido a su sencillez. Es relacional, multihilo y multiusuario. Pertenece a Sun Microsystems.

HTML. (lenguaje de marcas de hipertexto), es un lenguaje de marcacin diseado para estructurar textos y presentarlos en forma de hipertexto, que es el formato estndar de las pginas web. Gracias a Internet y a los navegadores del tipo Internet Explorer, Opera, Firefox o Netscape, el HTML se ha convertido en uno de los formatos ms populares que existen para la construccin de documentos y tambin de los ms fciles de aprender.

ASP.NET. ASP.NET es un conjunto de tecnologas de desarrollo de aplicaciones web comercializado por Microsoft. Es usado para construir sitios web domsticos, aplicaciones web y servicios XML. Forma parte de la plataforma .NET de Microsoft y es la tecnologa sucesora de la tecnologa Active Server Pages (ASP).

Ajax es una tecnologa asncrona, en el sentido de que los datos adicionales se requieren al servidor y se cargan en segundo plano sin interferir con la visualizacin ni el comportamiento de la pgina. JavaScript es el lenguaje interpretado en el que normalmente se efectan las funciones de llamada de Ajax mientras que el acceso a los datos se realiza mediante, objeto disponible en los navegadores actuales. En cualquier caso, no es necesario que el contenido asncrono est formateado en XML.

Las pginas principales permiten definir el aspecto, el diseo y el comportamiento estndar que se desea que tengan todas las pginas (o un grupo de pginas) de la aplicacin en una sola pgina principal. A partir de ella se pueden crear pginas de contenido individuales que incluyan lo que se desea mostrar. Cuando los usuarios solicitan las pginas de contenido, stas se combinan con la pgina principal para dar como resultado una pgina con el diseo de la pgina principal y el contenido de la pgina de contenido. 66

En definitiva, su utilizacin nos da muchas ventajas, ya que proporcionan una funcionalidad que tradicionalmente los programadores creaban copiando el cdigo, el texto y los elementos de control existentes repetidamente, archivos de inclusin de elementos comunes, controles de usuario de ASP.NET, etc. Entre las ventajas de las pginas principales se incluyen las siguientes: Permiten centralizar las funciones comunes de las pginas para que las actualizaciones puedan llevarse a cabo en un solo lugar.

Facilitan la creacin de un conjunto de controles y cdigo, y aplican los resultados en un conjunto de pginas. Por ejemplo, se pueden utilizar los controles en la pgina principal para crear un men que se aplique a todas las pginas.

Proporcionan un modelo de objetos que permite personalizar la pgina principal a partir de pginas de contenido individuales.

CONCLUSIONES La principal conclusin que obtengo de la realizacin de este Proyecto es la

importancia de seguir una metodologa de desarrollo correcta, siguiendo fases bien definidas (especificacin de requisitos, anlisis, diseo, implementacin y pruebas), y en las que se ha incidido tanto en respetar, ya no slo en el orden, sino en la dedicacin a cada una de ellas. A lo largo de mi corta experiencia laboral ya he aprendido que la existencia de diagramas es vital para un correcto desarrollo, sobre todo para el mantenimiento de una aplicacin de gran envergadura y, su utilizacin, en general, en el mundo del software, evitara muchos contratiempos. Por otro lado, analizando el proceso de desarrollo y centrndome en la configuracin del servidor web, he de decir que he llegado a la conclusin de que combinar ASP.NET con el servidor web Apache no me parece una buena idea. Decid llevarlo a cabo como un experimento, ya que, ya haba desarrollado varias veces con ASP.NET contra el servidor de Microsoft IIS, y consider que no estara de ms probar sobre Apache, para saber de primera mano cmo funciona. No obstante, la configuracin fue complicada y, a medida que fui avanzando en la implementacin me encontr con que algunos controles no funcionaban correctamente debido a este hecho y haba que de alguna manera arreglarlos. Conclusin: bajo mi experiencia de este proyecto no es nada recomendable. Siguiendo con las tecnologas utilizadas, he de decir que nunca haba utilizado AJAX, no tena ningn conocimiento, y, para realizar este PFC he tenido que aprenderlo. La verdad es que la diferencia entre el sitio web sin y con AJAX es muy grande, los tiempos de respuesta son mucho mejores con AJAX y la aplicacin se vuelve mucho ms gil y usable. En cuanto a posibles ampliaciones destacara ampliar la funcionalidad del cliente, permitiendo que pueda realizar pedido. Para finalizar, he de decir que estoy satisfecha con la realizacin de un sistema de estas caractersticas, ya que este tipo de aplicaciones estn cada vez ms

extendidos, as que tener experiencia en este campo creo que es altamente positivo.

BIBLIOGRAFIA

Web oficial de Microsoft: MSDN para ASP.NET. http://msdn.microsoft.com/es-es/asp.net/default.aspx Blog de ASP.NET, VB.NET y desarrollo web en general

http://www.blog-de.net/ Guas sobre CSS de la web del consorcio W3C.

http://www.w3c.es/Divulgacion/GuiasReferencia/CSS21/ Web oficial Mercury Mail.

http://www.pmail.com/ Artculo sobre instalacin de ssl en Apache.

http://www.symantec.com/connect/es/articles/apache-2-ssltls-step-step-part-2 Artculo sobre la seguridad en Apache.

http://www.tufuncion.com/configuracion_apache Wikipedia.

http://www.wikipedia.org/