APLICACION TAXISTAS TWITTEROS DE BOGOTA

FABIO ANDRÉS GIRALDO TORRES

UNIVERSIDAD CATÓLICA DE PEREIRA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍAS

PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES PRACTICAS ACADÉMICAS

PEREIRA 2012

APLICACION TAXISTAS TWITTEROS DE BOGOTA

FABIO ANDRÉS GIRALDO TORRES

TUTOR ING. RICARDO ALONSO HURTADO

UNIVERSIDAD CATÓLICA DE PEREIRA

FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍAS PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES

PRACTICAS ACADÉMICASPEREIRA

2012

DEDICATORIA Les dedico este trabajo a todas las personas

Que apoyaron la realización de este proyecto, También a mi familia parte fundamental en mi vida

Y a Dios por darme la entrega y dedicación.

AGRADECIMIENTOS Primero gracias a Dios por permitirme ser persona responsable con mis labores, A mi familia agradecerles el apoyo moral y económico. A mis docentes por inculcarme lineamientos y valores para ser persona profesional en mi oficio y también a muchos de mis compañeros, que de una u otra forma ayudaron en la realización de este proyecto con su apoyo intelectual y moral.

TABLA DE CONTENIDO

1 INTRODUCCIÓN ................................................................................................................. 8

2 ASPECTOS GENERALES DE LA ORGANIZACIÒN ................................................................. 9

2.1 Etapa Junior: ........................................................................................................... 10

2.2 Etapa Advanced: ..................................................................................................... 10

2.3 Etapa Senior: ........................................................................................................... 10

2.4 NÚMERO DE TRABAJADORES ................................................................................. 11

2.5 ÁREAS CON QUE CUENTA LA ORGANIZACIÓN: ....................................................... 11

2.6 RESEÑA HISTÓRICA: ................................................................................................ 11

3 DEFINICIÓN DE LAS LÍNEAS DE INTERVENCIÓN .............................................................. 13

4 DESCRIPSION DEL PROBLEMA ......................................................................................... 14

5 JUSTIFICACION ................................................................................................................ 15

6 OBJETIVOS ....................................................................................................................... 16

6.1 Objetivo general:..................................................................................................... 16

6.2 Objetivos específicos: ............................................................................................. 16

7 CRONOGRAMA DE ACTIVIDADES. ................................................................................... 17

8 MARCO TEORICO ............................................................................................................ 18

8.1 BASE DE DATOS ....................................................................................................... 18

8.1.1 Modelo Entidad-Relación ................................................................................ 18

8.1.2 Entidades vs Atributos ................................................................................... 20

8.1.3 Entidad vs Atributos multivaluados ................................................................ 20

8.1.4 Entidad vs Interrelaciones ............................................................................... 20

8.1.5 Notaciones ...................................................................................................... 21

8.1.6 Sistema Gestor de base de Datos: .................................................................. 24

8.1.7 PostgreSQL: ..................................................................................................... 24

8.1.8 BitNami: .......................................................................................................... 25

8.1.9 BitNamiStacks: ................................................................................................ 25

8.2 HTML ....................................................................................................................... 25

8.2.1 ¿Qué es HTML? ............................................................................................... 25

8.3 Estructura Cliente/Servidor .................................................................................... 27

8.4 PHP .......................................................................................................................... 29

8.4.1 ¿Qué es PHP? .................................................................................................. 29

8.4.2 ¿Qué se puede hacer con PHP? ...................................................................... 30

8.4.3 Scripts del lado-servidor. ................................................................................ 30

9 PRESENTACION Y ANÁLISIS DE LOS RESULTADOS .......................................................... 31

9.1 MODELO DE REQUISITOS. ....................................................................................... 31

9.1.1 Descripción del problema. .............................................................................. 32

9.1.2 Modelo de casos de uso. ................................................................................. 32

9.1.3 Modelo de interfaces. ..................................................................................... 33

9.2 MODELO DE ANALISIS. ............................................................................................ 35

9.3 MODELO DEL DISEÑO. ............................................................................................ 36

9.3.1 Descripción de los casos de uso. ..................................................................... 36

9.3.2 Definición de la estructura de almacenamiento de datos .............................. 38

9.3.3 Definición de la plataforma tecnológica. ........................................................ 39

RECOMENDACIONES. .............................................................................................................. 40

BIBLIOGRAFIA .......................................................................................................................... 41

SÍNTESIS

Síntesis Abstract

En este trabajo se observa el proceso de ingeniería de un proyecto software el cual consiste en el envió de solicitudes para un servicio de taxi por parte de los pasajeros y los taxistas podrán acudir a esa solicitud si ellos lo desean y si no lo podrán cancelar. Palabras clave: aplicaciones móviles, servicios web, desarrollo para móviles Keywords: mobile applications, web services, mobile development

This paper looks at the process of engineering a software project which involves sending requests to a taxi service by taxi drivers and passengers can go to that request if they wish and if they can cancel.

1 INTRODUCCIÓN

Un servicio de transporte dentro de una sociedad es severamente importante, ofrecer un medio de transporte a una comunidad ayuda a que dicha sociedad tenga facilidad de trasladarse rápidamente de un lado a otro. Un taxi es un medio de transporte público que permite desplazamientos rápidos, confortables y directos principalmente en áreas urbanas; el usuario paga una tarifa al conductor a cambio del servicio de transporte prestado. Cada conductor tiene su metodología para gestionar un pasajero. Pero especialmente, existe una comunidad de taxistas que tienen una forma muy particular de gestionar sus propios pasajeros. La comunidad de taxistas twitteros está compuesta por un conjunto de taxistas de la ciudad de Bogotá que se dedican a promover un servicio de calidad a sus usuarios por medio de una de las redes sociales más populares en el momento. Básicamente hacen un ofrecimiento del servicio de taxi desde Twitter, con el fin de brindar un servicio confiable, amable y respetuoso. No todos los taxistas de la ciudad pueden ser taxistas twitteros, para ser miembro de la comunidad deben pasar por un proceso de selección hecho por profesionales idóneos para garantizar que los conductores ofrecerán un buen servicio. Esta comunidad marca la diferencia con las empresas convencionales, ya que para elloslo primordiales la seguridad del usuario, el comportamiento de gente de bien por parte del conductor, quien es el que presta sus servicios. Se pretende construir una aplicación para la comunidad de taxistas twitteros y sus pasajeros, con el fin de notificar a los taxistas sobre una petición de algún pasajero en particular. Generando entre ellos un sistema de comunicación para determinar la confirmación de dicha solicitud.

2 ASPECTOS GENERALES DE LA ORGANIZACIÒN

NOMBRE DE LA ORGANIZACIÓN: ParqueSofte Pereira DIRECCIÓN:

Cra 31 # 15-87 CDV Barrio San Luis TELÉFONO:

3216899 Ext 229 - 3206712776 PÁGINA WEB DE LA ORGANIZACIÓN:

www.parquesoftpereira.com NIT: 900028215-3 SECTOR AL QUE PERTENECE LA ORGANIZACIÒN:

Sector Servicios. ACTIVIDAD A LA CUAL SE DEDICA LA ORGANIZACIÒN Y LÍNEAS QUEPRODUCE O SERVICIOS QUE PRESTA: ParqueSoft es una fundación sin ánimo de lucro cuyo propósito es facilitar a jóvenes emprendedores la creación y desarrollo de empresas de base tecnológica que provean al mercado de productos y servicios de tecnología informática. El proceso de crecimiento y desarrollo de la actividad empresarial de los emprendedores está apoyada por 3 etapas, éstas con el fin de representar el nivel de evolución y responsabilidad que va adquiriendo cada empresa según los logros y experiencias adquiridas.

2.1 Etapa Junior: Tiene duración de 6 meses e inicia al momento del ingreso a la comunidad ParqueSoft. Es la primera etapa y representa el proceso inicial de todo emprendedor en donde se consolida, se da forma a la idea de negocio y se desarrolla el producto o servicio.

2.2 Etapa Advanced: Se inicia una vez culminada la etapa Junior y tiene duración de año y medio. Esta etapa representa el nivel de evolución de la actividad empresarial, en la que se tiene un prototipo del producto o servicio y se está preparado para realizar prueba piloto.

2.3 Etapa Senior: Se considera la etapa de mayor nivel y tiene duración indefinida, ya que culmina únicamente con la desvinculación del parque. En esta etapa, las empresas están plenamente consolidadas, en donde su producto o servicio ya está probado y en la que ya se cuenta con varios clientes. La práctica se llevará a cabo en una de las 48 empresas vinculadas llamada Somvi, empresa dedicada a la creación de experiencias de usuario a través aplicaciones móviles en plataformas RIM, Android, iOS y HTML5. En las aplicaciones móviles podemos generar entretenimiento, información, interactividad, portabilidad y finalmente experiencia de usuario directa. Trabajamos sobre las tres (3) principales plataformas a nivel mundial RIM (BlackBerry), Android y iOS (iPhone), sin embargo utilizamos HTML5 para proyectos especiales. Las soluciones móviles son impactadas desde: Aplicaciones corporativas, comerciales, de gestión de contenidos y/o entretenimiento, acceso a bases de datos, integración a redes sociales, geolocalización, medios de pagos como NFC, web para móviles, entre otras. El proceso con nuestros clientes inicia con una etapa de consultoría con el fin de realizar el acompañamiento necesario para la toma de requerimientos inicial que transformará una idea o necesidad a una Aplicación Móvil. Nuestras soluciones son testeadas y pensadas para generar Apps óptimas, la creación y desarrollo de la interfaz gráfica de nuestros desarrollos son elaboradas profesional y cuidadosamente, teniendo en cuenta el tamaño de las pantallas, el tipo de aplicación requerida, el público objetivo y la(s) plataforma(s) requerida.

2.4 NÚMERO DE TRABAJADORES Siete (7) Empleados

2.5 ÁREAS CON QUE CUENTA LA ORGANIZACIÓN:

1. Área ejecutiva y comercial. 2. Área de proyectos 3. Área administrativa y financiera.

2.6 RESEÑA HISTÓRICA: En el año de 1999 surgió en Cali bajo el liderazgo de Orlando Rincón una iniciativa cuyo objeto era la creación de un espacio para jóvenes emprendedores de la industria del Software. Orlando Rincón, un reconocido líder de la industria, había fundado en 1984 Open Systems Ltda., una de las empresas más representativas de la industria de software colombiana. Durante todos estos años acumuló experiencias y conocimiento acerca de cómo consolidar una empresa de software. En 1997 visitó dos países transformados en líderes globales de esta industria y con condiciones similares a Colombia: Irlanda y la India. Orlando observó que era viable construir, con muy poca inversión, un Parque Tecnológico de Software y que ésta podría ser una excelente oportunidad para la ciudad de Cali, sumida entonces en una grave crisis económica y de identidad social, debido al funesto impacto del narcotráfico. Para ello, en junio de 1999 y aprovechando el cambio de sede de Open Systems, Orlando acordó con ésta la donación de la infraestructura avaluada en USD $30.000 para el inicio del Parque Tecnológico de Software de Cali. En años anteriores, Orlando había desarrollado un proceso de incubación de dos empresas de software: VIANet, dedicada a crear páginas y software WEB y Apedi, empresa a la cual Open había entregado su software de propósito comercial cuando decidió especializarse en software para servicios públicos y telecomunicaciones, brindándoles apoyo económico, coaching y asesoría permanente en tecnología y situaciones de negocios. En 1998 se había incorporado Innova Systems, especializada en el desarrollo de software para gestión documental. Estas empresas se trasladaron en septiembre de 1999 a las instalaciones donadas por Open Systems, en calidad de empresas base, fundadoras de este proyecto. En diciembre de ese mismo año se creó la Fundación Parque Tecnológico del Software con el objetivo de facilitar la creación

de empresas de software por parte de emprendedores jóvenes en la ciudad de Cali, en ese entonces con capacidad para residenciar 11 proyectos de emprendimiento con espacio para tres personas por proyecto, así nació ParqueSoft. Actualmente, ParqueSoft a consolidando un corredor de ciencia y tecnología en las ciudades de Cali, Popayán, Pasto, Buga, Tuluá, Palmira, Armenia, Manizales, Pereira, Buenaventura, Ibagué, Villavicencio y Sincelejo. En la ciudad de Pereira, ParqueSoft inició labores hace cinco (7) años, gracias al empuje de varios emprendedores de la empresa Fastec de Colombia, quienes luego de conocer y valorar el modelo implementado en Cali, fueron vinculados como miembros de la Fundación Parque Tecnológico de Software en Agosto de 2002. En el 2004, el proyecto fue vinculado al plan de desarrollo de la administración de Juan Manuel Arango, alcalde de Pereira de ese entonces; también fue incorporado en la Política de Desarrollo Regional del programa Ciencia, Tecnología e innovación, bajo la cual se proporcionaron rubros económicos para los primeros tres años de funcionamiento de ParqueSoft. En alianza entre Alcaldía de Pereira y la Universidad Tecnológica de Pereira (UTP) se entregó en comodato a la UTP el espacio físico en el cual a la fecha, opera la Fundación, fue así como el 15 de Marzo de 2005, se constituyó la Fundación Parque Tecnológico de Pereira –ParqueSoft Pereira- siguiendo los lineamientos filosóficos de ParqueSoft Cali. Hoy ParqueSoft Pereira cuenta con un total de cuarenta y ocho (48) empresas y Noventa y cuatro (94) emprendedores y colaboradores, desarrollando proyectos de base tecnológica e investigación en el área de software. Sigue siendo apoyado por la Alcaldía de Pereira y la Universidad Tecnológica de Pereira, además de Media Commerce, Cámara de Comercio de Pereira, entre otros.

3 DEFINICIÓN DE LAS LÍNEAS DE INTERVENCIÓN

El proyecto se enfoca en permitir a los pasajeros realizar solicitudes de servicios de taxis en la ciudad de Bogotá, estos por medio de la aplicación deberán enviar su información exacta al taxista, para que el taxista sea notificado y pueda realizar su servicio con unexcelente calidad. Por esta razón es que el proyecto se enfoca en un sistema de información.

4 DESCRIPSION DEL PROBLEMA

En la ciudad de Bogotá existe una comunidad de taxistas que se conocen como Taxistas Twitteros, y tienen una forma de ofrecer servicios de transporte usando una de las redes sociales más usadas a nivel mundial, twitter. Básicamente esta comunidad está compuesta por un número de taxistas que poseen cada uno su cuenta en twitter, donde son visibles para cualquier usuario que desee solicitarlos por un medio diferente al radio-teléfono tradicional. Twitter es una red social que posee demasiados usuarios, y ofrece servicios como medio de comunicación rápido entre sus mismos usuarios, por esta razón es que la comunidad de taxistas twitteros recurre a usar twitter, para lograr una comunicación directa con sus pasajeros con el fin de divulgar que son un conjunto de taxistas dispuestos a ofrecer sus servicios con calidad. El problema de esto es que en muchas ocasiones los pasajeros no pueden tener un servicio de forma inmediata si no que deben programarse para determinada fecha y hora y algunos pasajeros no desearían que fuera a si ya que en algunos momentos les gustaría que fuera de forma inmediata ya que salen de sus trabajos, universidades o de algunas otras partes cansados y con hambre y preferirían llegar a su sitio de una forma inmediata.

5 JUSTIFICACION

Desde un tiempo atrás, las redes sociales se han convertido de gran importancia para toda clases de personas, con el uso de ellas se puede encontrar amigos, gestionar información, buscar trabajo, etc. Por estas razones es que la gran mayoría de personas acude a esta clase de tecnología, con el fin de obtener empleo y/o ir en busca de posibilidades de trabajo. La comunidad de los taxistas Twitteros de Bogotá optaron por abrir campo en "Twitter", una de las redes sociales más populares en el momento, con el objetivo de interactuar con posibles pasajeros y ofrecerles sus servicios de taxi con calidad. Desafortunadamente en el uso que ellos le dan a “Twitter” existen ciertas

implicaciones que no permiten ofrecer una buena alternativa. Por eso, han querido mejorar su método de comunicación directa con los pasajeros y decidieron inclinarse por un sistema que pudiese atender solicitudes de una forma más rápida y directa.

6 OBJETIVOS

6.1 Objetivo general:

Construir una aplicación móvil para Android que permite a los pasajeros solicitar servicios de taxi cuando estos los requieran.

6.2 Objetivos específicos:

Determinar los requerimientos que el cliente especifique para la construcción de la aplicación

Diseñar la arquitectura del sistema Realizar la construcción de la aplicación con su respectivo ejecutable. Realizar pruebas de la aplicación.

7 CRONOGRAMA DE ACTIVIDADES.

meses actividad

agosto

septiembre

octubre

Noviembre

Diciembre

Enero

Introducción a la organización

X

X

Formulación y definición del problema

X

X

X

Modelación de análisis

X

X

X

X

Modelación de diseño de arquitectura

X

X

X

X

Elaboración de la aplicación

X

X

X

X

X

X

X

X

X

pruebas

X

X

X

X

8 MARCO TEORICO

8.1 BASE DE DATOS “Un sistema de bases de datos es básicamente un sistema computarizado para llevar registros. Es posible considerar a la propia base de datos como una especie de armario electrónico para archivar, es decir, es un deposito o contenedor de una colección de archivos de datos computarizados. Los usuarios del sistema pueden realizar una variedad de operaciones sobre dichos archivos, por ejemplo:

Agregar nuevos archivos vacios a la base de datos. Insertar datos dentro de los archivos existentes Recuperar datos de los archivos existentes Modificar datos en archivos existentes Eliminar datos de los archivos existentes Eliminar archivos existentes de la base de datos”. (Date, 2001)

8.1.1 Modelo Entidad-Relación

Las entidades: Son los Objetos principales sobre los que se debe recogerse información y generalmente denotan personas, lugares, cosas o eventos de interés. Las entidades aparecerán reflejadas en el enunciado habitualmente como nombres. A cada una de las posibles ocurrencias (cada persona, lugar, cosa o evento concreto) de la entidad se le denomina ejemplar.

Los atributos: Se utilizan para detallar las entidades asignándoles propiedades descriptivas tales como nombre, color y peso. Existen dos tipos de atributos: identificadores y descriptores. Los primeros se utilizan para distinguir de manera única cada una de las ocurrencias de una entidad (distinguiéndose entre identificadores principales e identificadores alternativos), mientras que los descriptores se utilizan para describir una ocurrencia de entidad. No solo es posible especificar atributos en las entidades si no también en las interrelaciones (en este caso solo tiene sentido hablar de atributos descriptores y no identificadores).

También hay que tener en cuenta que aparte de atributos identificadores y descriptores, hay atributos obligatorios/opcionales (si un atributo debe tomar o no un valor), atributos univaluados/multivaluados(si un atributo toma un único valor o varios), atributos derivados (si su valor se obtiene a partir de otros elementos del esquema E/R) atributos compuestos/simples (dependiendo de si un atributo es o no un agregado de otros atributos). A su vez, estas restricciones se pueden combinar entre sí (pueden existir en un esquema E/R atributos multivaluados simples opcionales, univaluados compuestos opcionales, multivaluados obligatorios, multivaluados compuestos, etc.)

Las entidades también pueden clasificarse por la fuerza de sus atributos identificadores, es decir, por su dependencia o no dependencia respecto a otras entidades. Las entidades fuertes tienen existencia propia, es decir, poseen identificadores internos que determinan de manera única la existencia de sus ocurrencias. Las entidades débiles pueden serlo por dos motivos: bien porque su existencia en la BD depende de una entidad fuerte, bien porque requieran para su identificación de los atributos identificadores (algunas veces llamados atributos externos) de otra entidad, por ejemplo, no poseen atributos identificadores internos que permitan la identificación de cada una de sus ocurrencias y requieren la presencia de atributos externos.

Las interrelaciones representan asociaciones del mundo real entre uno o más entidades. Las interrelaciones se caracterizan por su nombre, el grado (número de entidades que participan en la interrelación), el tipo de correspondencia (número máximo de ejemplares de una entidad asociados a una combinación de ejemplares de las otras entidades en la interrelación, que puede ser de 1 a N). Esta es la cardinalidad, uno a uno, uno a varios, varios a uno y varios a varios. Se definen las cardinalidades máximas y mínimas de las entidades que participan en una interrelación como el número máximo y mínimo de ejemplares de una entidad que pueden relacionarse con un único ejemplar de la otra, u otras entidades que participan en la interrelación.

8.1.2 Entidades vs Atributos

Los atributos no tienen existencia por sí mismas si no que tienen sentido en cuanto a que pertenecen a una determinada entidad o interrelación. Una entidad debe de estar caracterizada por algo más que su identificador principal. Si existe información descriptiva sobre un concepto u objeto, entonces debería clasificarse como entidad. Si solo se necesita un identificador para un objeto, el objeto debería clasificarse como un atributo. Las entidades poseen información descriptiva y los atributos no.

Por otro lado podría ocurrir que aun teniendo un concepto para el que solo existe un identificador principal, este se relacione con más de una entidad. En ese caso podría aparecer como una entidad en el esquema E/R.

8.1.3 Entidad vs Atributos multivaluados

En este aspecto existen discrepancias. Hay propuestas que prefieren incorporar en los esquemas E/R u atributo multivaluado como una entidad y otras prefieren representarlo como atributo. En nuestro caso, con independencia de que el atributo sea simple o compuesto, si se sabe que tendrá número limitado y no muy elevado de ocurrencias, entonces formara parte de la entidad que describe (simple y cuando el concepto que represente no esté relacionado con otras entidades del esquema E/R).

8.1.4 Entidad vs Interrelaciones

Lo habitual es no tener problemas en la diferenciación entre entidades e interrelaciones. Las interrelaciones asocian una o varias entidades, mientras que las entidades no. Sin embargo, en cualquier interrelación puede realizarse un proceso de nominalizaciones. Aun cuando la nominalización puede resultar útil en un proceso de diseño complejo, en especial para tratar de reducir el grado de una interrelación muy compleja o para encontrar elementos de interés para el sistema que inicialmente no se habían tenido en cuenta, en nuestro caso, evitaremos las nominalizaciones que no se encuentran presentes en los enunciados o que no resultan evidentes en el universo del discurso.

8.1.5 Notaciones

A continuación se muestran las convenciones seguidas en los problemas para la representación grafica de los distintos constructores de un diagrama E/R

Entidad (Fuerte)

Entidad Debil

Identificador Principal (IP)

Identificador Alternativo (IA)

Atributo

Atributo Multivaluado

Atributo Compuesto

Atributo Multivaluado Compuesto

Atributo Opcional

Atributo derivado

Interrelacion

Interrelacion con dependencia en Existencia

Interrelacion con dependencia en identificación

Dominio

Jerarquia solapada y parcial

Jerarquia solapada y total

Jerarquia exclusiva y parcial

Jerarquia exclusiva y total

8.1.6 Sistema Gestor de base de Datos:

Es un conjunto de programas diseñado para facilitar el establecimiento y utilización de una base de datos. Normalmente, los sistemas gestores de base de datos incluyen programas que organizan y cargan los datos del usuario en discos u otros soportes de almacenamiento de acceso directo, al mismo tiempo que establecen y mantienen varios índices de los datos almacenados. El sistema gestor de base de datos forma parte de lo que se conoce como software de base. Puede adaptarse a los requerimientos específicos de un sistema concreto de proceso de datos. (Saffady, 1986)

8.1.7 PostgreSQL:

Este es un lenguaje de bases de datos que lo utilizamos para poder recuperar (consultas) definir y manipular todos los datos del usuario.

Cuenta con más de 15 años de desarrollo activo y una arquitectura probada que se ha ganado una sólida reputación de confiabilidad, integridad de datos y corrección. Funciona en todos los principales sistemas operativos. También es compatible con el almacenamiento de objetos binarios, incluyendo imágenes, sonidos o vídeo. Tiene interfaces de programación nativo de C / C + +, Java, .NET, Perl, Python, Ruby, entre otros.

PostgreSQL cuenta con sofisticadas funciones como la versión multi-Control de concurrencia (MVCC), punto en el tiempo de recuperación, tablespaces, replicación asincrónica, transacciones anidadas (puntos de retorno), en línea / backups en caliente, un planificador de consultas sofisticadas / optimizador, y escribir por delante de registro para la tolerancia a fallos. Es compatible con conjuntos de caracteres internacionales, codificación de caracteres multibyte, Unicode, y es consciente de la configuración regional para la clasificación, caso-sensibilidad, y el formato. Es

altamente escalable, tanto en la enorme cantidad de datos que puede manejar y en el número de usuarios concurrentes que puede acomodar. (PostgreSQL, 2010)

8.1.8 BitNami:

El objetivo de BitNami es simplificar el despliegue de aplicaciones web, como los wikis o los blogs, con el fin de hacerlos más accesibles. Hay un montón de paquetes de software de código abierto de calidad que no se usan tanto como podría ser, porque conseguir que funcionen puede ser un proceso complejo. Queremos cambiar eso.

8.1.9 BitNamiStacks:

Es un paquete de software integrado que incluye una aplicación web y todos sus componentes necesarios (servidor web, base de datos, tiempo de ejecución de idiomas), así que está listo para funcionar fuera de la caja. Las pilas se pueden implementar como tradicionales instaladores nativos, la Máquina virtual de imágenes o imágenes de las nubes. Instaladores nativos son ejecutables que se descarga en el equipo. Cuando hace doble clic, caminan a través de cada paso del proceso de instalación automatizada. Están disponibles para Windows, Mac OS X, Linux y Solaris. BitNami Virtual Machine imágenes son pre-configuradas e incluyen una instalación mínima de Linux y una pila BitNami. Están disponibles para VMware y la última versión de VirtualBox. BitNami Cloud imágenes le permiten ejecutar una pila BitNami en un entorno de computación nube en un "pay-as-you-go base, y la programación de inicio y parada de ellos. (Bitnami.org)

8.2 HTML

8.2.1 ¿Qué es HTML?

(Lenguaje de composición de Hipertexto). Es un sistema para componer, etiquetar, un documento de modo que pueda ser publicado en la web. El lenguaje HTML define la información que se transmite entre los nodos de una red. Es un lenguaje de documentos simples, aunque potente, e independiente de la plataforma.

“HTML fue originalmente desarrollado por Tim Berners-Lee mientras estaba en el CERN, pero fue estandarizado en noviembre de 1995 como documento RFC 1866 de IETF(Internet EngineeringTaskForce), versión a la que normalmente se le denomina HTML version2.” (Thomas M. Connolly, 2005)

Este lenguaje fue desarrollado para que los diversos tipos de dispositivos pudieran utilizar la información de la Web: PC con pantallas graficas de resolución y profundidad de color variables, teléfonos móviles, dispositivos con entrada y salida de voz, dispositivos de mano, etc.

HTML es una aplicación del lenguaje SGML (lenguaje estándar de composición generalizado), un sistema para definir tipos de documentos estructurados y lenguajes de composición para representar instancias de dichos tipos de documentos.

Es un tipo especial de documento de texto que utilizan los navegadores web para presentar textos y gráficos. El texto incluye etiquetas de marcas tales como <p> para indicar el inicio de un párrafo, y </p> para indicar el final de un párrafo. Los documentos HTML se refieren a menudo como "páginas Web". El navegador recupera las páginas Web de los servidores Web que gracias a Internet, puede ser casi en cualquier lugar en el Mundo.

Muchas personas siguen escribiendo HTML a mano utilizando herramientas como el Bloc de notas en Windows o TextEdit en Mac. Esta guía te puede poner en marcha. Incluso si usted no tiene intención de editar el código HTML directamente y en su lugar va a utilizar un editor HTML como Netscape Composer, o Amaya de W3C, esta guía le permitirá comprender lo suficiente como para hacer un mejor uso de estas herramientas y cómo hacer que sus documentos HTML accesible en una amplia gama de navegadores

HTML tiene una cabeza y un cuerpo, el documento en general, comienza con una declaración de la que HTML ha sido la versión de utilizar, y es seguido por un <html> etiqueta seguida de <head> y al final por </html>.

El <html>... </html> actúa como un contenedor para el documento.

El <head>... </head> contiene el título, e información sobre las hojas de estilo y scripts, mientras que el <body>... </body> contiene el marcado con el contenido visible.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <title>replace with your document's title</title> </head> <body> replace with your document's content </body> </html>

8.3 Estructura Cliente/Servidor “La arquitectura cliente-servidor es una arquitectura en la que el sistema de base de datos se divide en dos partes: el servidor (llamado también parte dorsal) y los clientes (llamados también partes frontales).

Esta estructura es en estos días uno de los sistemas más populares para distribuir computadoras y datos en las redes; estas redes permiten a los clientes ingresar los datos e cualquier servidor en donde cuenten con el permiso adecuado.

Esta estructura surgió a partir de las capacidades limitadas que tenían los sistemas operativos de las computadoras personales. Los primeros sistemas operativos no proporcionaban controles de seguridad ni podían soportar usuarios múltiples. Por esta razón se instalaron poderosos sistemas operativos en servidores que manejaban todas las tareas que requerían compartir hardware y datos. Esta estructura es mucho más fácil de de controlar y manejar que cientos de computadoras personales.

Un ejemplo de una base de datos puede ser almacenar tablas de datos en un servidor, pero ejecutar los formularios en computadoras personales. Los formularios manejan eventos de usuarios con una interfaz grafica; sin embargo, todos los datos se transfieren al servidor.

El servidor está formado precisamente por el DBMS, llevando a cabo la administración y la manipulación de las bases de datos que controla. Los clientes son las diversas aplicaciones que trabajan con la información que está en la base de datos,

tanto aplicaciones escritas por usuarios como aplicaciones integradas (proporcionadas por el fabricante del DBMS o por terceros). Los clientes hacen peticiones al servidor (el DBMS), éste las recibe y las procesa, y envía las respuestas de vuelta a los clientes.

Aunque ésta arquitectura se puede seguir si están todos los componentes del sistema en una misma computadora, por lo general el termino cliente-servidor se aplica cuando los clientes se ubican en sitios (computadoras) distintas al del servidor. Es común usar computadoras personales o estaciones de trabajo sencillas del lado de los clientes, y estaciones de trabajo poderosas o mainframes del lado del servidor. Debe existir una red y un software de comunicación para que los clientes y el servidor puedan intercambiar información y así poder implementar este tipo de arquitectura. “

Modelo

Estructura

Cliente-

Servidor

Podemos concluir que una estructura cliente/servidor es una técnica que nos permite organizar sistemas en donde algunas computadoras deben contener casi todos los datos, los cuales son recuperados por personas que utilizan computadoras personales como clientes.

8.4 PHP

8.4.1 ¿Qué es PHP?

PHP (acrónimo de PHP: HypertextPreprocessor) es un lenguaje de script de código abierto que se incrusta en HTML, y que muchos de los servidores web lo soportan, incluidos entre estos el servidor HTTP Apache y el servidor Internet Information Server de Microsoft.

El objetivo principal del lenguaje PHP es permitir a los desarrolladores web escribir rápidamente páginas HTML dinámicas.

Un ejemplo introductorio <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <title>Example</title> </head> <body> <?php echo "Hola, ¡soy un script PHP!"; ?> </body> </html>

En lugar de usar muchos comandos para mostrar HTML (como en C o Perl), páginas PHP contienen HTML con código incluido en el mismo que hace "algo" (en este caso, mostrar "Hola ¡soy un script PHP!). El código PHP está entre medio de etiquetas de comienzo y final especiales<?php y ?> que nos permitirán entrar y salir del "modo PHP".

Lo que distingue a PHP de algo lado-cliente como Javascript, es que el código es ejecutado en el servidor, generando HTML y enviándolo al cliente. El cliente recibirá los resultados de ejecutar el script, sin ninguna posibilidad de determinar qué código

ha producido el resultado recibido. El servidor web puede ser incluso configurado para que procese todos los archivos HTML con PHP. (PHP, PHP .NET, 2010)

Lenguaje de Script: “los lenguajes de Script permiten la creación de funciones incrustadas dentro del código HTML. Esto permite automatizar diversos procesos y manipular y acceder a diversos objetos.” (Thomas M. Connolly, 2005)

Una de las grandes ventajas del lenguaje PHP es su ampliabilidad, y existen diversos módulos de extensión para poder soportar cosas tales como la comunicación por correo electrónico, la conectividad a bases de datos y el lenguaje XML.

8.4.2 ¿Qué se puede hacer con PHP?

PHP puede hacer cualquier cosa que se pueda hacer con un script, como procesar la información de formularios, generar páginas con contenidos dinámicos, o enviar y recibir cookies.

Existen principalmente tres campos en los que se usan scripts en PHP.

8.4.3 Scripts del lado-servidor.

Este es el campo más tradicional y el principal foco de trabajo. Se necesitan tres cosas para que esto funcione. El intérprete PHP (CGI módulo), un servidor web y un navegador. Es necesario hacer funcionar el servidor, con PHP instalado. El resultado del programa PHP se puede obtener a través del navegador, conectándose con el servidor web.

Scripts en la línea de comandos. Puede crear un script PHP y correrlo sin necesidad de un servidor web o navegador. Solamente necesita el intérprete PHP para usarlo de esta manera. Este tipo de uso es ideal para scripts ejecutados regularmente desde cron (en *nix o Linux) o el Planificador de tareas (en Windows). Estos scripts también pueden ser usados para tareas simples de procesamiento de texto.

Escribir aplicaciones de interfaz gráfica. Probablemente PHP no sea el lenguaje más apropiado para escribir aplicaciones gráficas, pero si conoce bien PHP, y quisiera utilizar algunas características avanzadas en programas clientes, puede utilizar PHP-GTK para escribir dichos programas. También es posible escribir aplicaciones independientes de una plataforma. PHP-GTK es una extensión de PHP, no disponible en la distribución principal. (PHP, PHP .NET, 2010)

9 PRESENTACION Y ANÁLISIS DE LOS RESULTADOS

Para suplir la problemática que se presenta en este proyecto sobre la imposibilidad de controlar el tráfico de solicitudes que deben atender los miembros de la comunidad de taxistas llamada "TaxistasTwitteros" por medio de la red social Twitter; se escogió la metodología de ingeniería de software orientada a objetos que plantea el autor del libro “INGENIERÍA DE SOFTWARE ORIENTADA A OBJETOS CON

UML, JAVA, E INTERNET”, Alfredo Weitzenfeld. El autor propone una serie de

actividades o modelos básicos a seguir para lograr las metas dentro del proceso de desarrollo ingeniería de un proyecto de software; los modelos son: modelos de requisitos, modelos de análisis, modelos de diseño, modelos de implementación, modelos de integración, modelos de pruebas. El objetivo de usar la propuesta clásica que nos presenta Weitzendfeld, es documentar el proceso de ingeniería de software para cada uno de los modelos; teniendo en cuenta que se seguirá el modelo de ciclo de vida cascada.

Para este proyecto se optó por utilizar 3 del total de actividades planteadas, estas actividades son: Modelo de requisitos, Modelo de análisis, Modelo de Diseño; de las cuales cada modelo está definido por un conjunto de sub-modelos que ayudan a describir el proceso entendible para el equipo de trabajo.

Para el modelo de requisitos se trabajó con los siguientes sub-modelos.

9.1 MODELO DE REQUISITOS.

Descripción del problema. Modelo de casos de uso. Modelo de interfaces.

El propósito del modelo de requisitos es comprender en su totalidad el problema y sus implicaciones. Los demás modelos, análisis, diseño, implementación, y pruebas dependen directa o indirectamente del modelo de requisitos. Asimismo, este modelo sirve de base para el desarrollo de las instrucciones operacionales y los manuales, ya que todo lo que el sistema deba hacer se describe aquí desde la perspectiva del usuario. (Weitzenfeld, 2005)

9.1.1 Descripción del problema.

En la descripción del problema, se hizo un resumen preliminar de las necesidades que sirvieron como punto de partida para comprender los requisitos del sistema.

9.1.2 Modelo de casos de uso.

En el modelo de casos de uso se describe en términos gráficos, las posibles formas en el que

los usuarios interactúan con el sistema. Cada usuario se representa como actor, que

corresponden a: Pasajero, Taxista, Administrador, como lo muestra el siguiente gráfico.

Cada uno de estos actores ejerce una interacción con al menos un caso de uso.

9.1.3 Modelo de interfaces.

EL modelo de interfaces describe la presentación de información entre los actores y el sistema. Se especifica en detalle cómo se verán las interfaces de usuario al ejecutar cada uno de los casos de uso por parte del administrador. (Weitzenfeld, 2005)

INICIO DE SESION

MENU

CAMBIAR CONTRASEÑA ADMI

REGISTRO TAXISTA

ELIMINAR USUARIO

MODIFICAR USUARIO

9.2 MODELO DE ANALISIS.

Luego de definir el modelo de casos de uso, concretar qué acciones iba a realizar los

diferentes usuarios, y todo lo que abarca el modelo de requisitos se inicia el desarrollo del

modelo de análisis, cuyo objetivo es comprender y generar una estructura del sistema con

base a lo especificado en el modelo de requisitos.

Cuando se desarrolla el modelo de análisis, normalmente se trabaja con un caso de uso a la

vez. (Weitzenfeld, 2005)

Para cada caso de uso se definió un conjunto de clases necesarias, cada clase corresponde a

un estereotipo diferente, ya sea estereotipo borde, estereotipo de control, o estereotipo de

Modelo. Y cada una tiene definido explícitamente que comportamiento es responsable

dentro del caso de uso. Se comienza identificando los objetos borde necesario, continuando

con los objetos de entidad (Modelo) y finalmente, los objetos de control. Este proceso se

aplica a los demás casos de uso.

La elección de los diferentes estereotipos por cada caso de uso se hizo con el fin de separar

la presentación del procesamiento y de la persistencia de los datos. Si por alguna

circunstancia se requiere hacer un cambio en el proyecto, que normalmente los cambios

más comunes ocurren en las clases de funcionalidad (Control) y las clases que definen

interfaces (Borde), podrá hacerse únicamente a la clase que necesite hacer el cambio, sin

que sea afectado todo el proyecto.

9.3 MODELO DEL DISEÑO. Una vez definido el modelo de análisis, y tener especificado parcialmente todo el sistema,

pasamos a realizar el modelo del diseño, donde prácticamente se concretó más

detalladamente cada interacción de los actores con el funcionamiento del sistema. También

logró concretarse la manera en que se generaba la comunicación entre las diferentes

partes (Sistema central y terminales).

9.3.1 Descripción de los casos de uso.

La primera actividad con la que se comenzó, fue haciendo una descripción minuciosa de la

interacción del actor con los diferentes casos de uso; narrando el flujo de eventos que

debían realizarse, y estipulando cual era la respuesta del sistema según cada acción

ejecutada, también se debía especificar una seria de pasos como flujo alternativo, que

describían las acciones en el momento que no se siguiera el flujo de eventos normal.

Toda la información detallada que se pudo recolectar para obtener un buen flujo de eventos

fue gracias al siguiente formato. Para cada caso de uso se realizó el mismo procedimiento

de descripción, pero como ejemplo se mostrará la descripción del mismo caso de uso citado

anteriormente.

CU1: Registrar taxista. Descripción: Permitir al actor crear un nuevo perfil de taxista dentro del sistema. Actores: Administrador. Flujo de Eventos: Información previa:

Para que el actor llegue al formulario de registro de taxista, es necesario que

navegue por las opciones, desde la página principal, seleccionando la opción de

registrar taxista, hasta llegar al formulario.

Acción de los actores Respuesta del sistema

1. El actor comienza el registro llenando los datos del taxista correspondientes a: Nombre, Cuenta de usuario Twitter, empresa en la que está suscrito el

taxi, número de placa del carro, número del taxi, contraseña, confirmación de contraseña.

2. El actor presionar el botón "guardar".

3. El sistema capturar la información de las casillas: Nombre, Twitter, Nombre de empresa, No. placa, No. de taxi, contraseña de los campos de texto.

4. El sistema verifica que no haya casillas vacías.

5. El sistema verifica que los campos donde se introdujeron la contraseña y la confirmación de la contraseña tenga exactamente el mismo contenido.

6. El sistema almacena los datos en la base de datos.

Tabla #1. Flujo de eventos –Registrar taxista

Si se cumple el flujo de eventos, saldrá un mensaje que anuncia el registro

satisfactorio.

Flujos Alternativos: 4. El sistema verifica que no haya casillas vacías, si alguna casilla está vacía se

avisa al actor que hace falta llenar información en alguna de las casillas.

5. El sistema verifica que los campos donde se introdujeron la contraseña y la confirmación de la contraseña tenga exactamente el mismo contenido. Si los datos no coinciden, se avisa al actor que la información ingresada en los campos de contraseña no son exactos y debe ingresarlos nuevamente.

6. El sistema almacena los datos en la base de datos. Si no los almacena es porque existen fallas en la conexión.

Precondiciones: El conductor del taxi debe pasar por un proceso de selección que realiza la comunidad taxistas Twitteros.

Pos condiciones: El conductor pasa a ser usuario de la aplicación y podrá iniciar sesión para interactuar con ella.

9.3.2 Definición de la estructura de almacenamiento de datos

9.3.3 Definición de la plataforma tecnológica.

Para construir el sistema:

Para la construcción de la aplicación, se necesitó todas las herramientas necesarias para

construir aplicaciones en la plataforma Android, el entorno de desarrollo más adecuado es

Eclipse, ya que la documentación sobre Android esta soportada para este IDE. También se

trabajó con lenguajes de programación java y XML, java para realizar la lógica de

procesamiento y manejadores lógicos necesarios, y XML para declarar la capa de

presentación y construir toda la interfaz. Por lado de la administración y de gestión del

servidor se utilizaron tecnologías como PHP, HTML, CSS, Javascript.

Hardware:

Para que el sistema funcione:

Los dispositivos que se necesitan para hacer uso del sistema móvil, son dispositivos

celulares de gamas Smartphone, algunos de los muchos manufactureros son: LG, Samsung,

HTC.

Comunicaciones: Para lograr una comunicación entre el sistema móvil, y el sistema central, se utilizó un

protocolo de comunicación que consiste en envío de mensajes SOAP, (Protocolo SOAP) por

medio de servicios web.

RECOMENDACIONES.

Al momento de realizar desarrollo de software ya sea desarrollo web o desarrollo móvil etc. Es muy importante tener unos aspectos muy importantes entre estos la recolección de requerimientos por parte del cliente, es indispensable que estos requerimientos queden plasmados en un documento ya que a la hora de implementar el código no pueden haber cambios, puesto que antes de implementar el código se tuvo que realizar todo un proceso de ingeniería en base a los primeros requerimientos y si estos tienen algún cambio se perdería todo ese proceso y retardaría el desarrollo.

Otro punto que recomiendo en un desarrollo de software es la estimación, recordemos que la estimación lo que nos indica es, número de personas que trabajaran en el desarrollo, coste del desarrollo y tiempo que se demorara el desarrollo. Esto no puede ser dicho sin utilizar alguna técnica de estimación por eso existen las técnicas y como tal debemos hacer huso de ellas.

BIBLIOGRAFIA

Bitnami.org. (s.f.). Acerca de Bitnami. Recuperado el 12 de 10 de 2012, de Bitnami:

http://www.bitnami.org/learm_more

(2001). En C. Date, Introduccion a los sistemas de bases de datos (pág. 2).

(2008). Andrés Gómez De Silva Garza ,Ignacio de Jesús Ania Briseño, Introducción a la

programacion (págs. 126, 135, 136).

PHP, PHP .NET. (2010).

PostgreSQL. (2010).

Saffady, W. (1986). Informatica documental.

(2005). En C. E. Thomas M. Connolly, Sistemas de Bases de Datos 4 Edición (págs. 904, 913).

Weitzenfeld. (2005). INGENIERIA DE SOFTWARE ORIENTADA A OBJETOS CON UML JAVA E

INTERNET.