1
UNIVERSIDAD AUTÓNOMA METROPOLITANA
CIENCIAS BÁSICAS E INGENIERÍA
LICENCIATURA EN COMPUTACIÓN
REPORTE DE PROYECTO TERMINAL
DESARROLLO DE UN SISTEMA DE BASE DE DATOS
PARA UNA RED INMOBILIARIA
2
AGRADECIMIENTOS
Gracias mi Dios por todas las bendiciones que me has dado,
pero sobre todo por haberme permitido terminar la
licenciatura y este reporte tan importante.
Gracias a mi madre, mi padre y a mamá Lola (
†
) por darme
la oportunidad de estudiar una carrera, por el impulso que
me dieron para llegar a donde estoy, por inculcarme los
mejores valores, por su paciencia, por levantarme cuando
me he caído, pero sobre todo porque parte del tiempo que
le dediqué a la Universidad y al reporte les correspondía a
ellos.
Gracias a mis hermanos y a mis tíos por el apoyo que me
brindaron y que me siguen dando para cumplir mis sueños,
sin ustedes no lo habría logrado.
Gracias Juan Alberto porque sino me hubieras insistido,
habría pasado mucho más tiempo para concluir el reporte.
Gracias a mis verdaderos amigos, que estuvieron conmigo
en los momentos fáciles y difíciles de la carrera.
Gracias a mis maestros que me enseñaron tantas cosas
valiosas, en especial, al profesor Joel que acepto
3
DEDICATORIAS
Primero que nada le dedico este trabajo a Dios, porque sin
él nada se logra.
A mi madre y a mi padre, por darme la mejor herencia que
unos padres le pueden dejar a su hija, por ser el mejor
modelo que puedo tener, espero no defraudarlos.
A mis hermanos, mamá Lola (
†
), mis tíos y a la pequeña
Fer, por su confianza en mí y en lo que hago.
A Juan Alberto y a mi bebé que viene en camino, por
convertirse en una parte primordial de mi vida e
impulsarme a terminar este reporte.
4
Agradecimientos……….2
Dedicatoria………..3
Índice………4
Introducción………..……….6
Metodologías, Herramientas y Técnicas………6
Modelo de Negocios en Internet………7
Software como servicio………..8
Software bajo demanda……….8
Características………8
Ventajas………..8
Desventajas………..9
Comercio electrónico……….9
Ventajas del comercio electrónico……….. 11
Tipos de empresas en comercio electrónico………11
Modelos basados en publicidad……….……….12
Modelos basados en la comunidad………..12
Modelos basados en tarifas………...12
RUP (Rational Unified Process o Proceso Unificado Racional)….12 Antecedentes………...12
Características……….13
Fases e iteraciones de RUP………15
UML(Unified Modeling Language).……….….17
Diagramas de estructura……….18
Diagramas de comportamiento………..22
Diagramas de iteración……….23
Lenguaje PHP………..………..…24
Características……….25
MySQL……….………..26
Lenguajes de programación………..26
Características distintivas………...26
Servidor Web…….……….…27
FileZilla Client.………....28
Descripción del Proyecto……….29
Características o Funcionalidades del Proyecto..………29
5
Descripción del Alcance del Proyecto……….30
Objetivos del Proyecto……….30
Requerimientos del Proyecto y/o Producto a Entregar.…………....31
Plan de Trabajo………..31
Productos del Proyecto.………..32
Restricciones y Consideraciones del Proyecto.……….33
Definición Inicial de Riesgos.………..33
Desarrollo………...33
Fase de Inicio……….………33
Modelo de Negocios de la Inmobiliaria……….………33
Análisis de Requerimientos….………35
Fase de Elaboración….……….35
Refinamiento del Análisis y Diseño de Requerimientos………36
Caso De Uso General………36
Diagrama de Entidad Relación de la Base de Datos.……..41
Diagramas de Actividad……….42
Diagrama de Navegación General…………...……….74
Modelo de Análisis……….………...75
Fase de Codificación………...77
Discusión………..………78
Conclusiones……….……….79
Bibliografía……….………….79
Apéndice A Guía de Instalación………..81
Apéndice B Manual de Usuario………..81
6
Desarrollo de un Sistema de Base de Datos para una
Red Inmobiliaria
INTRODUCCIÓN
En este proyecto lo que se hizo fue analizar la problemática por la que pasan las redes inmobiliarias para manejar los datos de las personas con las que trabajan, ya sean proveedores de bienes y/o servicios, y de los inmuebles con los que cuentan, una vez que se hizo esto, se procedió a hacer una investigación sobre comercio electrónico en México y cómo que características debe tener el producto que deseamos elaborar para que sea rentable en este ramo, al terminar estas dos fases, se contactó a un agente inmobiliario que nos proporcionó amablemente los requerimientos que debería de tener el sistema para ser de gran utilidad dentro de estas redes.
Después se pasó a modelar lo que sería el sistema utilizando UML y basándonos en la metodología RUP, una vez hecho esto se procedió a codificar el sistema utilizando MySQL para la base de datos y php para las interfaces.
Como últimos pasos el sistema se montó en un servidor web de libre acceso, se probó su funcionalidad; se hicieron algunas modificaciones posteriores que el profesor Joel consideró serían de gran utilidad y que al final dieron como resultado un sistema optimo y con buena funcionalidad.
Comenzaremos hablando de los recursos teóricos fundamentales que nos servirán para la realización de nuestro proyecto, así como de los diversos lenguajes de programación, gestores de sitios, técnicas, etc. que fueron de gran utilidad para el desarrollo del sistema, es decir, la infraestructura necesaria que nos ayudará durante el desarrollo del mismo.
7
METODOLOGÍAS, HERRAMIENTAS Y TÉCNICAS
MODELO DE NEGOCIOS EN INTERNET
Un modelo es el método de hacer negocios por el cual una compañía se puede mantener, esto es, generar ingresos. El modelo de negocios habla de cómo la compañía hace dinero especificando en que lugar se encuentra en la cadena de valor.
El comercio en Internet hará crecer nuevos tipos de modelos de negocios. Esto es muy cierto, pero la Web propiciará la reinvención de modelos probados y establecidos. Los tipos de modelo incluyen desde Corretaje hasta Servicio Público pasando por los de Publicidad, Intermediario de Información, Mercantil, Manufacturero y Suscripción entre otros.
Detallaremos en que consiste el Modelo de Suscripción por ser de gran ayuda para llevar a cabo este proyecto.
Modelo de
Suscripción Se hace un cargo a los usuarios de manera periódica (diario, mensual o anual) por suscribirse al servicio. No es raro en los sitios que combinen contenido libre con "contenido Premium". Las cuotas de suscripción son cobradas sin tomar en cuenta las tasas de uso. Los modelos de suscripción y publicidad son combinados frecuentemente.
Servicios de Contenido -- provee contenidos en texto, audio o video a los usuarios que se suscriben por una cuota para obtener acceso al servicio.
Servicios de Red de Persona a Persona -- son conducidos por la distribución de información enviada por usuarios, tal como individuos buscando antiguos compañeros de escuela.
Servicios de Confianza -- se dan en la forma de membresías que cumplen con un código explícito de conducta, y en el cual los miembros pagan una cuota de suscripción.
8
CAPÍTULO 1 SOFTWARE COMO SERVICIO
Software como Servicio (del inglés: Software as a Service, SaaS) es un modelo de distribución de software en donde la compañía de IT provee el servicio de mantenimiento, operación diaria, y soporte del software usado por el cliente. En otras palabras es tener la información, el procesamiento, los insumos y los resultados de la lógica de negocio del software. En palabras simples: El cliente tiene el sistema hospedado en la compañía de IT.
El software es un producto que se puede distribuir de varias maneras, de forma clásica es mediante una instalación directa en equipos del cliente. Normalmente si alguien quiere usar una aplicación de ventas, compra el CD de instalación, ejecuta un programa de configuración, da sus claves y listo, puede explotar al sistema. Pero si el usuario necesita que otra persona al extremo del globo terráqueo otro usuario viera su lista de clientes, pendientes o precios y los quisiera manipular con el mismo software, lo más seguro es que necesitaría otro CD o bajarlo del Web, otra licencia, una VPN o correo electrónico; o en cambio si tiene un software modelado como servicio los requerimientos pueden ser más simples.
SOFTWARE BAJO DEMANDA
Consiste en poder utilizar una aplicación desde una computadora cliente (ejemplo la computadora de un vendedor) hacia un servidor central colocado en la empresa proveedora de sistemas y no en la compañía del cliente.
CARACTERÍSTICAS
Es software donde el acceso es vía Internet. No necesariamente se da por medio de navegadores Web, la lógica de negocio reside en la localidad central del proveedor. Las actividades son administradas en lugares centrales y no en la oficina del cliente. La distribución de la aplicación tiene el modelo de uno a muchos es decir, se realiza un producto y el mismo lo usan varios clientes.
VENTAJAS
El cliente no necesariamente debe tener un área especializada para soportar el sistema, por lo que baja sus costos y su riesgo de inversión.
9
correcta funcionalidad, es parte del servicio que da la compañía proveedora del software.
La empresa IT no desatiende al cliente. El servicio y atención continua del proveedor al cliente es necesaria para que este último siga pagando el servicio.
La empresa IT provee los medios seguros de acceso en los entornos de la aplicación. Si una empresa IT quiere dar opciones en su cartera de productos debe ofrecer accesos seguros para que no se infiltren datos privados en la red pública.
No es necesaria la compra de una licencia para utilizar el software, sino el pago de un alquiler o renta por el uso del software.
Se le permite al cliente completa flexibilidad en el uso de los sistemas operativos de su preferencia, o al cual pueda tener acceso.
DESVENTAJAS
La persona usuaria no tiene acceso directo a sus contenidos, ya que están guardados en un lugar remoto, y en caso de no contar con mecanismos de cifrado y control disminuye el índice de privacidad, control y seguridad que ello supone, ya que la compañía TI podría consultarlos.
Al estar el servicio y el programa dependientes de la misma empresa no permite a la usuaria migrar a otro servicio utilizando el mismo programa (dependiendo de la modalidad del contrato de servicios con la compañía de TI).
Si el servicio de Internet no está disponible por parte del ISP, el usuario no tendrá acceso al programa, por lo que sus operaciones se verán afectadas hasta que dicho servicio se reestablezca.
CAPÍTULO 2 COMERCIO ELECTRÓNICO
El comercio electrónico, también conocido como e-commerce, consiste en la compra y venta de productos o de servicios a través de medios electrónicos, tales como el Internet y otras redes de ordenadores. Originalmente el término se aplicaba a la realización de transacciones mediante medios electrónicos tales como el Intercambio electrónico de datos, sin embargo con el advenimiento de la Internet y la World Wide Web a mediados de los años 90 comenzó a referirse principalmente a la venta de bienes y servicios a través de la Internet, usando como forma de pago medios electrónicos, tales como las tarjetas de crédito.
10
Una gran variedad de comercio se realiza de esta manera, estimulando la creación y utilización de innovaciones como la transferencia de fondos electrónica, la administración de cadenas de suministro, el marketing en Internet, el procesamiento de transacciones en línea (OLTP), el intercambio electrónico de datos (EDI), los sistemas de administración del inventario, y los sistemas automatizados de recolección de datos.
La mayor parte del comercio electrónico consiste en la compra y venta de productos entre personas y empresas, sin embargo un porcentaje considerable del comercio electrónico consiste en la adquisición de artículos virtuales (software y derivados en su mayoría), tales como el acceso a contenido "Premium" de un sitio Web.
El e-commerce origina muchos tipos nuevos de modelos de negocio y reinventa algunos modelos ya usados. La identificación del modelo de negocios es un intento de simplificar la dinámica de los negocios en la Web, pero no es absoluta ni suficiente, ya que muchos negocios tienen modelos mixtos, y queda mucho lugar -afortunadamente- para la aparición de nuevas categorías o modelos. Según los participantes que convocan y que son convocados, los modelos se clasifican en:
ە empresa-empresa (B2B) ە empresa-consumidor (B2C) ە empresa-inversor (B2I)
ە empresa-empresa-consumidor (B2B2C) ە consumidor-consumidor (C2C).
El modelo de negocio a utilizarse para nuestro proyecto es el B2C que se detalla a continuación:
B2C (BUSINESS- TO - CONSUMER )
B2C es la abreviatura de la expresión Business-to-Consumer («del negocio al consumidor», en inglés).B2C se refiere a la estrategia que desarrollan las empresas comerciales para llegar directamente al cliente o usuario final.
11
Transacciones directas (negocio-consumidor) o (negocio-cliente).
Los pioneros de esta estrategia B2C son: la empresa fabricante de ordenadores personales Dell y el mayorista, también estadounidense, de libros, música y otros productos Amazon.com.
El comercio electrónico B2C es una forma de venta con gran potencial a largo plazo; en la actualidad, lo están desarrollando los sectores de distribución de artículos de alimentación y consumo. Así, las grandes cadenas de distribución: supermercados, hipermercados, grandes almacenes ya disponen de portales propios para la venta a través de Internet.
B2C también se aplica a instituciones financieras y cualquier otro tipo de empresa que establezca relaciones comerciales directas con sus clientes a través de Internet.
El éxito de las transacciones electrónicas B2C depende de la fiabilidad de los sistemas de pago, que suelen ser a través de tarjetas de crédito, en otros casos se posibilitan otras formas de pago como contra reembolso, en efectivo o la utilización de servicios proporcionados por otras empresas como PayPal. En Colombia, una forma de pago adicional a las tarjetas de crédito es el débito on-line de las cuentas de ahorro y corrientes directamente en las entidades bancarias.
VENTAJAS DEL COMERCIO ELECTRÓNICO B2C
Se pueden destacar las siguientes ventajas:
ە La compra suele ser más rápida y más cómoda. ە Las ofertas y los precios están siempre actualizados. ە Los centros de atención al cliente están integrados en la
Web.
ە Las telecomunicaciones por banda ancha han mejorado la experiencia de compra .
TIPOS DE EMPRESAS EN COMERCIO ELECTRÓNICO B2C Intermediarios on-line
Los intermediarios on-line son compañías que facilitan las transacciones entre compradores y vendedores, como contraprestación económica reciben un porcentaje del valor de la transacción. La mayoría de las transacciones se realizan a través de estos intermediarios, que pueden ser brokers o «informediarios», genéricos o especializados, respectivamente.
12
En una publicidad basada en el sistema, las empresas tienen sitios Web de un inventario, que venden a las partes interesadas. Existen dos filosofías rectores para esta práctica: de alto tráfico o de nicho. Los anunciantes tienen un alto tráfico de enfoque al intentar llegar a un público más amplio. Estos anunciantes están dispuestos a pagar una prima por un sitio que puede ofrecer un número elevado, por ejemplo, anuncios en Yahoo! o Google. Cuando los anunciantes están tratando de llegar a un grupo más pequeño de compradores, se llevan a un nicho. Estos compradores están bien definidos, claramente identificados, y deseable. El nicho de enfoque se centra en la calidad, no cantidad. Por ejemplo, un anuncio de WSJ.com en el que principalmente quieren ser vistos por la gente de negocios y ejecutivos.
MODELOS BASADOS EN LA COMUNIDAD
En una comunidad basada en el sistema, las empresas permiten a los usuarios en todo el mundo el acceso a interactuar unos con otros sobre la base de áreas similares de interés. Estas empresas ganan dinero por medio de la acumulación leales usuarios y la orientación con la publicidad.
MODELOS BASADOS EN TARIFAS
En un sistema de pago basado en el sistema, una empresa cobra una tarifa de suscripción para ver su contenido. Existen diversos grados de restricción de contenidos y tipos de suscripción que van desde las tasas a tanto alzado a pay-as-you-go.
Más adelante veremos como impacta el modelo de negocios en el proyecto: Desarrollo de un Sistema de Base de Datos para una Red Inmobiliaria.
RUP (Rational Unified Process o Proceso Unificado Racional)
Es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos; un conjunto de metodologías adaptables al contexto y necesidades de cada organización.
ANTECEDENTES
13
en componentes, que introdujo el concepto de Caso de Uso.
Entre los años de 1987 a 1995 Jacobson fundó la compañía Objectory AB y lanza el proceso de desarrollo Objectory (abreviación de Object Factory).
En 1995 Rational Software Corporation adquiere Objectory AB y entre 1995 y 1997 se desarrolla Rational Objectory Process (ROP) a partir de Objectory 3.8 y del Enfoque Rational (Rational Approach) adoptando UML como lenguaje de modelado.
Desde entonces, Rational Software desarrolló e incorporó diversos elementos para expandir ROP, destacándose especialmente el flujo de trabajo conocido como modelado del negocio. En junio del 1998 se lanza Rational Unified Process.
CARACTERÍSTICAS
RUP cuenta con tres características principales:
Dirigido por los Casos de Uso
Los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar en términos de importancia para el usuario y no sólo en términos de funciones que sería bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor añadido. Los Casos de Uso representan los requisitos funcionales del sistema.
En RUP los Casos de Uso no son sólo una herramienta para especificar los requisitos del sistema, también guían su diseño, implementación y prueba. Los Casos de Uso constituyen un elemento integrador y una guía del trabajo.
Los Casos de Uso no sólo inician el proceso de desarrollo sino que proporcionan un hilo conductor, permitiendo establecer una relación entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo.
Centrado en la arquitectura
14
ayuda a determinar en qué orden. Además la definición de la arquitectura debe tomar en consideración elementos de calidad del sistema, rendimiento, reutilización y capacidad de evolución por lo que debe ser flexible durante todo el proceso de desarrollo.
La arquitectura se ve influenciada por la plataforma software, sistema operativo, gestor de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados. Muchas de estas restricciones constituyen requisitos no funcionales del sistema. RUP presta atención a atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento.
Cada modelo tiene tanto una función como una forma. La función corresponde a la funcionalidad reflejada en los Casos de Uso y la forma la proporciona la arquitectura. Existe una interacción entre los Casos de Uso y la arquitectura, los Casos de Uso deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos, actualmente y en el futuro. Esto provoca que tanto arquitectura como Casos de Uso deban evolucionar en paralelo durante todo el proceso de desarrollo de software.
Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el diseño por lo que la arquitectura se representa mediante varias vistas que se centran en aspectos concretos del sistema, abstrayéndose de los demás. Para RUP, todas las vistas juntas forman el llamado modelo 4+1 de la arquitectura, el cual recibe este nombre porque lo forman las vistas lógica, de implementación, de proceso y de despliegue, más la de Casos de Uso que es la que da cohesión a todas.
Al final de la fase de elaboración se obtiene una primera aproximación de la arquitectura donde fueron seleccionados una serie de Casos de Uso arquitectónicamente relevantes (aquellos que ayudan a mitigar los riesgos más importantes, aquellos que son los más importantes para el usuario y aquellos que cubran las funcionalidades significativas).
Iterativo e incremental
15
entre Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto, así durante todo el proceso de desarrollo.
Cada mini proyecto se puede ver como una iteración (un recorrido más o menos completo a lo largo de todos los flujos de trabajo fundamentales) del cual se obtiene un incremento que produce un crecimiento en el producto. Una iteración puede realizarse por medio de una cascada de etapas como se muestra en la Figura 6. Se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño, Implementación y Pruebas), también existe una planificación de la iteración, un análisis de la iteración y algunas actividades específicas de la iteración. Al finalizar se realiza una integración de los resultados con lo obtenido de las iteraciones anteriores.
El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada iteración se analiza cuando termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Durante la planificación de los detalles de la siguiente iteración, el equipo también examina cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de la iteración pasada permite reajustar los objetivos para las siguientes iteraciones. Se continúa con esta dinámica hasta que se haya finalizado por completo con la versión actual del producto.
FASES E ITERACIONES DE RUP
El ciclo de vida RUP es una implementación del desarrollo en
espiral. Fue creado ensamblando los elementos en secuencias
semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una primera aproximación o línea base de la arquitectura.
16
Fase de elaboración: las iteraciones se orientan al desarrollo de la línea base de la arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la línea base de la arquitectura.
Fase de construcción: se lleva a cabo la construcción del producto por medio de una serie de iteraciones (implementación, pruebas y muestra del sistema). Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementación deseada de la nueva versión del producto.
Fase de transición: se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios con el fin de que la prueben.
Como se puede observar en cada fase participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una disciplina o actividad varía.
En la siguiente figura se muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.
En RUP se identifican 6 prácticas con las que define una forma efectiva de trabajar para los equipos de desarrollo de software.
Gestión de requisitos: RUP brinda una guía para encontrar,
17
Desarrollo de software iterativo: Desarrollo del producto
mediante iteraciones con hitos bien definidos, en las cuales se repiten las actividades pero con distinto énfasis, según la fase del proyecto.
Desarrollo basado en componentes: La creación de sistemas
intensivos en software requiere dividir el sistema en componentes con interfaces bien definidas, que posteriormente serán ensamblados para generar el sistema. Esta característica en un proceso de desarrollo permite que el sistema se vaya creando a medida que se obtienen o se desarrollan sus componentes.
Modelado visual (usando UML): UML es un lenguaje para
visualizar, especificar, construir y documentar los artefactos de un sistema software. Es un estándar de la OMG. Utilizar herramientas de modelado visual facilita la gestión de dichos modelos, permitiendo ocultar o exponer detalles cuando sea necesario. El modelado visual también ayuda a mantener la consistencia entre los artefactos del sistema: requisitos, diseños e implementaciones. En resumen, el modelado visual ayuda a mejorar la capacidad del equipo para gestionar la complejidad del software.
Verificación continua de la calidad: Es importante que la calidad de todos los artefactos se evalúe en varios puntos durante el proceso de desarrollo, especialmente al final de cada iteración. En esta verificación las pruebas juegan un papel fundamental y se integran a lo largo de todo el proceso. Para todos los artefactos no ejecutables las revisiones e inspecciones también deben ser continuas.
Gestión de los cambios: Los cambios son un factor de riesgo crítico
en los proyectos de software. Los artefactos de software cambian no sólo debido a acciones de mantenimiento posteriores a la entrega del producto, sino que durante el proceso de desarrollo, especialmente importantes por su posible impacto son los cambios en los requisitos. Por otra parte, otro gran desafío que debe abordarse es la construcción de software con la participación de múltiples desarrolladores, posiblemente distribuidos geográficamente, trabajando a la vez en una entrega y quizás en distintas plataformas. La ausencia de una disciplina rápidamente conduciría al caos. La Gestión de Cambios y de Configuración es la disciplina de RUP encargada de este aspecto.
UML (Unified Modeling Language o Lenguaje Unificado de Modelado)
18
(Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.
UML cuenta con 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta, a veces es útil ordenarlos de la siguiente manera:
Los Diagramas de Estructura enfatizan en los elementos que
deben existir en el sistema modelado:
Diagrama de clases: Es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.
19
material, cantidad, ubicación. Generalmente se conoce como la información detallada del objeto.
Operaciones comúnmente llamados métodos, son aquellas
actividades o verbos que se pueden realizar con/para este objeto. De la misma manera que el nombre de un atributo, el nombre de una operación se escribe con minúsculas si consta de una sola palabra. Si el nombre contiene más de una palabra, cada palabra será unida a la anterior y comenzará con una letra mayúscula, a excepción de la primera palabra que comenzará en minúscula.
Interfaz es un conjunto de operaciones que permiten a un objeto comportarse de cierta manera, por lo que define los requerimientos mínimos del objeto. Hace referencia a polimorfismo.
Herencia se define como la reutilización de un objeto padre ya definido para poder extender la funcionalidad en un objeto hijo. Los objetos hijos heredan todas las operaciones y/o propiedades de un objeto padre. Por ejemplo: Una persona puede especializarse en Proveedores, Acreedores, Clientes, Accionistas, Empleados; todos comparten datos básicos como una persona, pero además cada uno tendrá información adicional que depende del tipo de persona, como saldo del cliente, total de inversión del accionista, salario del empleado, etc.
Al diseñar una clase se debe pensar en cómo se puede identificar un objeto real, como una persona, un transporte, un documento o un paquete. Estos ejemplos de clases de objetos reales, es sobre lo que un sistema se diseña. Durante el proceso del diseño de las clases se toman las propiedades que identifican como único al objeto y otras propiedades adicionales como datos que corresponden al objeto.
Diagrama de componentes: Representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.
20
En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del sistema. Uno de los usos principales es que puede servir para ver qué componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.
Diagrama de objetos: Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias específicas de clases en un momento particular del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notación es similar a los diagramas de clase. Una diferencia con los diagramas de clase es que el compartimiento de arriba va en la forma.
Diagrama de estructura compuesta: Es un tipo de diagrama de estructura estática en el Lenguaje de Modelado Unificado (UML), que muestra la estructura interna de una clase y las colaboraciones que esta estructura hace posibles. Esto puede incluir partes internas, puertas mediante las cuales, las partes interactúan con cada una de las otras o mediante las cuales, instancias de la clase interactúan con las partes y con el mundo exterior, y conectores entre partes o puertas. Una estructura compuesta es un conjunto de elementos interconectados que colaboran en tiempo de ejecución para lograr algún propósito. Cada elemento tiene algún rol definido en la colaboración.
o Parte: Representa un rol jugado en tiempo de ejecución por
una instancia de una clase o por una colección de instancias. La parte puede nombrar solamente un rol, una superclase abstracta, o puede nombrar una clase concreta específica. La parte puede incluir un factor de multiplicidad (cardinalidad), tal como el [0..*] mostrado para Viewer en el diagrama.
o Puerta: Es un punto de interacción que puede ser usado para
21
o Conector: Une dos o más entidades, permitiéndoles interactuar
en tiempo de ejecución. Un conector es representado por una línea que une una combinación de partes, puertas y clasificadores estructurados. El diagrama muestra tres conectores entre puertas, y un conector entre un clasificador estructurado y una parte.
o Colaboración: Es generalmente más abstracta que un
clasificador estructurado. Ésta es mostrada como un óvalo sin relleno conteniendo los roles que las instancias pueden jugar en la colaboración.
o Clasificador estructurado: Representa una clase,
frecuentemente una clase abstracta, cuyo comportamiento puede ser completa o parcialmente descrito mediante interacciones entre partes. Un ClasificadorEncapsulado es un tipo de clasificador estructurado que contiene puertas.
Diagrama de despliegue: Se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes. Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.
En UML los componentes ya no están dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo. Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o una base de datos construida o modificada en un proyecto. Estos artefactos implementan colecciones de componentes. Los nodos internos indican ambientes, un concepto más amplio que el hardware propiamente dicho, ya que un ambiente puede incluir al lenguaje de programación, a un sistema operativo, un ordenador o un cluster de terminales.
La mayoría de las veces el modelado de la vista de despliegue implica modelar la topología del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificación hardware de propósito general, se ha diseñado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del sistema.
22
Los Paquetes están normalmente organizados para maximizar la coherencia interna dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas líneas maestras sobre la mesa, los paquetes son buenos elementos de gestión. Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo requerido.
Los Diagramas de Comportamiento enfatizan en lo que debe
suceder en el sistema modelado:
Diagrama de actividades: Representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general.
Diagrama de casos de uso: Define una notación gráfica para representar casos de uso. UML no define estándares para el formato de casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso. El valor verdadero de un caso de uso reposa en dos áreas:
La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripción se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas.
La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de uso coherente, consistente promueve una imagen fácil del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.
23
Los Diagramas de Interacción son un subtipo de diagramas
de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:
Diagrama de secuencia: muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada método de la clase. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos.
Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si tienes modelada la descripción de cada caso de uso como una secuencia de varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.
Diagrama de comunicación: Modela las interacciones entre objetos o partes en términos de mensajes en secuencia. Los diagramas de comunicación representan una combinación de información tomada desde el diagrama de clases, secuencia, y diagrama de casos de uso describiendo tanto la estructura estática como el comportamiento dinámico de un sistema.
Los diagramas de comunicación y de secuencia describen información similar, y con ciertas transformaciones, pueden ser transformados unos en otros sin dificultad. Para mantener el orden de los mensajes en un diagrama de comunicación, los mensajes son etiquetados con un número cronológico y colocados cerca del enlace por el cual se desplaza el mensaje.
Diagrama de tiempos: es una gráfica de formas de onda digitales que muestra la relación temporal entre varias señales, y cómo varía cada señal en relación a las demás. Son una representación especial de interacción que se enfoca en el tiempo de los mensajes enviados entre objetos. Se pueden usar estos diagramas para mostrar restricciones detalladas sobre el tiempo, ó para mostrar los cambios con líneas de vida respecto al tiempo. Los diagramas de tiempo son generalmente utilizados con sistemas en tiempo real o en sistemas embebidos.
24
determinar los estados, nivel alto o nivel bajo, de cada una de las señales en cualquier instante de tiempo especificado, y el instante exacto en que cualquiera de las señales cambia de estado con respecto a las restantes.
El propósito primario del diagrama de tiempos es mostrar los cambios en el estado o la condición de una línea de vida (representando una Instancia de un Clasificador o un Rol de un clasificador) a lo largo del tiempo lineal. El uso más común es mostrar el cambio de estado de un objeto a lo largo del tiempo, en respuesta a los eventos o estímulos aceptados. Los eventos que se reciben se anotan, a medida que muestran cuándo se desea mostrar el evento que causa el cambio en la condición o en el estado.
Diagrama global de interacciones: Es un diagrama de comportamiento, más precisamente, uno de los cuatro diagramas de interacción. Muestra una cierta vista sobre los aspectos dinámicos de los sistemas modelados. Aunque un diagrama global de las interacciones es una representación gráfica de una interacción, éste se distingue fuertemente de los diagramas de secuencia y de comunicación, dos de los otros diagramas de interacción. De hecho, algunos elementos gráficos del diagrama global de las interacciones están tomados del diagrama de actividades, otro diagrama de comportamiento para el modelado de actividades.
Los modelos de interacción pueden llegar a ser muy grandes para sistemas complejos. Si el número de líneas de vida participantes y el número de mensajes intercambiados exceden una cierta medida, se impone “modularizar” las interacciones y dividir en partes pequeñas, más manejables, de acuerdo a principios universales del diseño de sistemas, que también pueden ser visualizadas con la ayuda de un clásico diagrama de secuencias. La visión de conjunto de toda la interacción, de manera que el cuadro global, puede entonces ser representada con la ayuda del diagrama global de las interacciones, provisto para eso.
LENGUAJE PHP
PHP es un lenguaje de programación interpretado, diseñado originalmente para la creación de páginas Web dinámicas. Es usado principalmente en interpretación del lado del servidor (server-side scripting) pero actualmente puede ser utilizado desde una interfaz de línea de comandos o en la creación de otros tipos de programas incluyendo aplicaciones con interfaz gráfica usando las bibliotecas Qt o GTK+.
25
creado originalmente por Rasmus Lerdorf en 1994; sin embargo la implementación principal de PHP es producida ahora por The PHP Group y sirve como el estándar de facto para PHP al no haber una especificación formal. Publicado bajo la PHP License, la Free Software Foundation considera esta licencia como software libre.
PHP es un lenguaje interpretado de propósito general ampliamente usado y que está diseñado al usar especialmente para desarrollo web y puede ser incrustado dentro de código HTML. Generalmente se ejecuta en un servidor web, tomando el código en PHP como su entrada y creando páginas web como salida. Puede ser desplegado en la mayoría de los servidores web y en casi todos los sistemas operativos y plataformas sin costo alguno.
CARACTERÍSTICAS DE PHP Ventajas
Es un lenguaje multiplataforma.
Completamente orientado al desarrollo de aplicaciones web dinámicas con acceso a información almacenada en una Base de Datos.
El código fuente escrito en PHP es invisible al navegador y al cliente ya que es el servidor el que se encarga de ejecutar el código y enviar su resultado HTML al navegador. Esto hace que la programación en PHP sea segura y confiable.
Capacidad de conexión con la mayoría de los motores de base de datos que se utilizan en la actualidad, destaca su conectividad con MySQL y PostgreSQL.
Capacidad de expandir su potencial utilizando la enorme cantidad de módulos (llamados ext's o extensiones).
Posee una amplia documentación en su página oficial, entre la cual se destaca que todas las funciones del sistema están explicadas y ejemplificadas en un único archivo de ayuda.
Es libre, por lo que se presenta como una alternativa de fácil acceso para todos.
Permite aplicar técnicas de programación orientada a objetos. Biblioteca nativa de funciones sumamente amplia e incluida. No requiere definición de tipos de variables aunque sus variables se pueden evaluar también por el tipo que estén manejando en tiempo de ejecución.
Tiene manejo de excepciones (desde PHP5).
26
los desarrollos que en PHP se han hecho del patrón de diseño Modelo Vista Controlador (o MVC), que permiten separar el tratamiento y acceso a los datos, la lógica de control y la interfaz de usuario en tres componentes independientes (ver más abajo Frameworks en PHP).
Desventajas
La ofuscación de código es la única forma de ocultar los códigos fuentes.
MySQL
MySQL es un sistema de gestión de base de datos relacional, multihilo y multiusuario con más de seis millones de instalaciones.
LENGUAJES DE PROGRAMACIÓN
Existen varias APIs que permiten, a aplicaciones escritas en diversos lenguajes de programación, acceder a las bases de datos MySQL, incluyendo C, C++, C#, Pascal, Delphi (via dbExpress), Eiffel, Smalltalk, Java (con una implementación nativa del driver de Java), Lisp, Perl, PHP, Python, Ruby,Gambas, REALbasic (Mac), (x)Harbour (Eagle1), FreeBASIC, y Tcl; cada uno de estos utiliza una API específica. También existe un interfaz ODBC, llamado MyODBC que permite a cualquier lenguaje de programación que soporte ODBC comunicarse con las bases de datos MySQL. También se puede acceder desde el sistema SAP, lenguaje ABAP.
MySQL es muy utilizado en aplicaciones web, como Drupal o
phpBB, en plataformas
(Linux/Windows-Apache-MySQL-PHP/Perl/Python), y por herramientas de seguimiento de errores como Bugzilla. Su popularidad como aplicación web está muy ligada a PHP, que a menudo aparece en combinación con MySQL. MySQL es una base de datos muy rápida en la lectura cuando utiliza el motor no transaccional MyISAM, pero puede provocar problemas de integridad en entornos de alta concurrencia en la modificación. En aplicaciones Web hay baja concurrencia en la modificación de datos y en cambio el entorno es intensivo en lectura de datos, lo que hace a MySQL ideal para este tipo de aplicaciones. Sea cual sea el entorno en el que va a utilizar MySQL, es importante adelantar monitoreos sobre el desempeño para detectar y corregir errores tanto de SQL como de programación.
CARACTERÍSTICAS DISTINTIVAS
27
Múltiples motores de almacenamiento (MyISAM, Merge, InnoDB, BDB, Memory/heap, MySQL Cluster, Federated, Archive, CSV, Blackhole y Example en 5.x), permitiendo al usuario escoger la que sea más adecuada para cada tabla de la base de datos.
Agrupación de transacciones, reuniendo múltiples transacciones de varias conexiones para incrementar el número de transacciones por segundo.
Tipos de compilación del servidor
Hay tres tipos de compilación del servidor MySQL:
Estándar: Los binarios estándar de MySQL son los recomendados para la mayoría de los usuarios, e incluyen el motor de almacenamiento InnoDB.
Max (No se trata de MaxDB, que es una cooperación con SAP): Los binarios incluyen características adicionales que no han sido lo bastante probadas o que normalmente no son necesarias. MySQL-Debug: Son binarios que han sido compilados con información de depuración extra. No debe ser usada en sistemas en producción porque el código de depuración puede reducir el rendimiento.
Especificaciones del código fuente
MySQL está escrito en una mezcla de C y C++.
SERVIDOR WEB
Un servidor web es un programa que está diseñado para transferir hipertextos, páginas web o páginas HTML (HyperText Markup Language): textos complejos con enlaces, figuras, formularios, botones y objetos incrustados como animaciones o reproductores de música. El programa implementa el protocolo HTTP (HyperText Transfer Protocol) que pertenece a la capa de aplicación del modelo OSI. El término también se emplea para referirse al ordenador que ejecuta el programa.
28
exhibe en pantalla. Como vemos con este ejemplo, el cliente es el encargado de interpretar el código HTML, es decir, de mostrar las fuentes, los colores y la disposición de los textos y objetos de la página; el servidor tan sólo se limita a transferir el código de la página sin llevar a cabo ninguna interpretación de la misma.
Además de la transferencia de código HTML, los Servidores Web pueden entregar aplicaciones Web. Éstas son porciones de código que se ejecutan cuando se realizan ciertas peticiones o respuestas HTTP. Hay que distinguir entre:
Aplicaciones en el lado del cliente: el cliente Web es el encargado de ejecutarlas en la máquina del usuario. Son las aplicaciones tipo Java o Javascript: el servidor proporciona el código de las aplicaciones al cliente y éste, mediante el navegador, las ejecuta. Es necesario, por tanto, que el cliente disponga de un navegador con capacidad para ejecutar aplicaciones (también llamadas scripts). Comúnmente, los navegadores permiten ejecutar aplicaciones escritas en lenguaje javascript y java, aunque pueden añadirse más lenguajes mediante el uso de plugins.
Aplicaciones en el lado del servidor: el servidor web ejecuta la aplicación; ésta, una vez ejecutada, genera cierto código HTML; el servidor toma este código recién creado y lo envía al cliente por medio del protocolo HTTP.
Las aplicaciones de servidor muchas veces suelen ser la mejor opción para realizar aplicaciones Web. La razón es que, al ejecutarse ésta en el servidor y no en la máquina del cliente, éste no necesita ninguna capacidad añadida, como sí ocurre en el caso de querer ejecutar aplicaciones javascript o java. Así pues, cualquier cliente dotado de un navegador Web básico puede utilizar este tipo de aplicaciones.
El hecho de que HTTP y HTML estén íntimamente ligados no debe dar lugar a confundir ambos términos. HTML es un lenguaje de marcas y HTTP es un protocolo.
FileZilla Client
29
son el Site Manager (Administrador de sitios), Message Log (Registro de mensajes), y Transfer Queue (Cola de transferencia).
El administrador de sitios permite a un usuario crear una lista de sitios FTP con sus datos de conexión, como el número de puerto a usar, o si se utiliza inicio de sesión normal o anónima. Para el inicio normal, se guarda el usuario y opcionalmente la contraseña.
El registro de mensajes se muestra en la parte de arriba de la ventana, en forma de consola, los comandos enviados por FileZilla y las respuestas del servidor remoto se observan aquí.
La vista de archivo y carpeta, situada debajo del registro de mensajes, proporciona una interfaz gráfica para FTP. Los usuarios pueden navegar por las carpetas, ver y alterar sus contenidos tanto en la máquina local como en la remota, utilizando una interfaz de tipo árbol de exploración. Los usuarios pueden arrastrar y soltar archivos entre los ordenadores local y remoto.
La cola de transferencia, situada en la parte de abajo de la ventana, muestra en tiempo real el estado de cada transferencia activa o en cola.
DESCRIPCIÓN DEL PROYECTO
La problemática que queremos resolver surge como parte de la modernización de los servicios que se ofrecen en algunas redes de condominios, en esta etapa se buscará implementar un sistema con los datos personales de los inquilinos de dichos condominios, así como información referente a los servicios con que cuenta cada departamento, el pago por cada uno de ellos y las fechas en que deben realizarse de tal manera que podamos tener un banco de información actualizable a corto plazo con la información más relevante.
Actualmente en muchos condominios o edificios esta información se encuentra administrada mediante papel o se carece de ella. Para los encargados que cuentan con ella, y tienen que utilizar ó actualizar cierta información de estas bases de datos, la tarea es muy tediosa pues se tiene que buscar un cierto archivo de forma manual.
CARACTERÍSTICAS O FUNCIONALIDADES DEL PROYECTO
30
pueda obtenerla de una manera sencilla por medio del portal o de la interfaz de inicio.
El Sistema debe permitirle al dueño y/o administrador el control de los pagos de servicios de los inquilinos (renta, teléfono, agua, etc.).
Si a un inquilino se le olvida realizar sus pagos en la fecha indicada el sistema debe enviar un mensaje de alerta que dicho inquilino no ha realizado su pago.
El sistema debe permitir la administración de los inquilinos que deseen realizar altas, bajas o cambios de servicios con los que cuentan, así como, darse de baja del sistema en caso de mudarse de domicilio o darse de alta a un nuevo inquilino. Si el inquilino decide adelantar algunos pagos de los servicios con los que cuenta y después desea cambiarse de domicilio entonces el sistema debe de hacer la diferencia de los pagos de los servicios de los meses que no se utilizaron.
El sistema debe ser capaz de actualizar y crear nuevos servicios.
El sistema es capaz de validar las claves de acceso del administrador del condominio y de los inquilinos así como generarlos.
PROPOSITO Y JUSTIFICACION DEL PROYECTO
1. Razones por las que se decidió desarrollar el proyecto.
o La razón principal por la que hemos decidido realizar este
proyecto es porque aplicaremos los conocimientos adquiridos a lo largo de la licenciatura.
o El sistema será aplicado de forma real, en los condominios que
lo deseen adquirir para modernizar sus servicios.
o Otra razón fundamental será la de realizar un sistema eficiente
para facilitar el trabajo de los administradores de los condominios.
2. Beneficios que el producto a obtener ofrece.
o Evitar perdidas monetarias en los pagos de servicios de los
inquilinos.
o Tener estricto control de los inquilinos que habitan el
condominio.
o Eficiente y fácil administración. o Control de pagos de los inquilinos.
DESCRIPCIÓN DEL ALCANCE DEL PROYECTO
31
Conexión entre los dos elementos anteriores por medio de php. Interacción adecuada con el usuario
OBJETIVOS DEL PROYECTO
Objetivo General
Se pretende la implementación de un sistema que gestione la información correspondiente a los inquilinos de una red de condominios.
El proyecto se realizará mediante la metodología RUP (Rational Unified Process) con sus cuatro etapas concepción, elaboración, construcción y transición, se utilizara php como lenguaje de programación y MySQL como administrador de base de datos, al final dicho sistema se colocará en un servidor FreeBSD, la administración de la aplicación será vía Web.
Objetivos Específicos
Manipulación del sistema para decisiones futuras.
Manipulación del sistema para realizar los pagos de los servicios.
Controlar las entradas y salidas de dinero.
Consulta de servicios y de los inquilinos que habitan el condominio.
REQUERIMIENTOS DEL PROYECTO Y/O PRODUCTO A GENERAR
1. Infraestructura necesaria para desarrollar el proyecto Procesador de texto
Herramienta StarUml
Manejador de base de datos(mysql)
Conexión e interfaz grafica entre (mysql php y html) Servidor gratuito http://www.000webhost.com/ Documento de visión
Diagrama E-R del sistema Casos de uso detallados Diagrama de navegabilidad
PLAN DE TRABAJO
1. Actividades necesarias para cumplir con los objetivos asignados al proyecto.
32
Investigación inicial del tema de negocios en Internet.
Investigación inicial del tema de negocios para comercio electrónico.
Modelo de negocios de los Condominios.
Análisis y diseño del negocio que se va a implementar. Implementación del prototipo inicial.
Instalación y pruebas.
Revisión y retroalimentación del sistema y pruebas finales.
2. Asignación de tiempo de las actividades.
ACTIVIDAD TIEMPO
Revisión de la Metodología RUP. Investigación inicial del tema de negocios en Internet.
Investigación inicial del tema de negocios para comercio electrónico. Modelo de negocios de los
Condominios.
2 semanas
Análisis y diseño del negocio que se
va a implementar. 2 semanas
Implementación del prototipo inicial. 2 semanas
Instalación y pruebas. 2 semanas
Revisión y retroalimentación del
sistema y pruebas finales. 3 semanas
PRODUCTOS DEL PROYECTO
ENTREGABLE FECHA
Investigación inicial del tema de negocios en Internet.
Investigación inicial del tema de negocios para comercio electrónico. Modelo de negocios.
Semana 2
Análisis y diseño del negocio que se
33
Implementación del prototipo inicial. Semana 6
Instalación y pruebas. Semana 8
Revisión y retroalimentación del
sistema y pruebas finales. Semana 11
RESTRICCIONES Y CONSIDERACIONES DEL PROYECTO
Riesgo de enfermedad del alumno.
Situación meteorológica que impida la realización de alguna de las etapas del proyecto.
Estados de alerta nacionales.
DEFINICIÓN INICIAL DE RIESGOS
El sistema se puede desarrollar de manera general para cualquier red de condominios, así que no hay ningún riesgo inicial.
DESARROLLO
Comenzamos con la aplicación del modelo de negocios, solicitando al cliente los requerimientos necesarios en cuanto diseño y funciones del sitio en cuestión.
En este apartado también, haremos una revisión de todas las etapas de la Metodología RUP aplicada al proyecto que hemos realizado, desmenuzando los aspectos más importantes que se llevaron a cabo en dichas fases, recordando primeramente cual es su función.
FASE DE INICIO
Las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de requerimientos.
MODELO DE NEGOCIOS DE LA INMOBILIARÍA
34
adecuan a todas las diferentes tipologías y niveles, desde las promociones de lujo hasta las más económicas. El Condominio Digital hace referencia a equipamiento e instalaciones con las que cuentan todos y cada uno de los inmuebles que se encuentran registrados dentro de la empresa.
El valor percibido por el usuario referente a los productos y servicios del Condominio Digital es muy superior al costeo real para el representante de la empresa. Y el comprador final prácticamente no tiene porque apreciar el pequeño incremento en el precio del sistema que conlleva para tener una promoción de software con el equipamiento y las instalaciones adaptadas a nuestro tiempo.
Los principales argumentos para el representante de la empresa para integrar y ofrecer productos y servicios de Condominio Digital son:
Diferenciarse de la competencia Agilizar la comercialización
Obtener un mayor beneficio económico Mejorar la imagen de empresa
La forma de empaquetar la oferta de Condominio Digital depende de cada promotor y cada promoción. Lo más aconsejable es ofrecer, por lo menos, un “mínimo de rendimiento” por defecto en todo sistema, lo que se suele denominar un “Paquete Básico”. Adicionalmente se puede ofrecer mejoras. Las mejoras pueden realizarse a la medida de cada cliente o empaquetarse en los “Paquetes de mejoras" habituales.
Para integrar estos servicios, sistemas y productos de Condominio Digital, basta con seguir el proceso normal de la promoción, construcción y comercialización. Lo que tiene que hacer el representante de la empresa es pedir al Administrador del sistema que incluya los productos, sistemas y servicios que desee, en el Proyecto (UML, memoria, mediciones y presupuesto). El Administrador del sistema puede realizar las mejoras y novedades para el correcto desarrollo del proyecto. Para proyectos con un nivel de integración más complejo e implementación de sistemas avanzados con un alto nivel de programación, puesta en marcha y mantenimiento, es recomendable contar con un “Integrador de sistemas”, un papel que puede ser propuesto y/o asumido por alguno de los programadores, proveedores de servicio o buscado directamente por el representante de la empresa.
35
la navegación por sus menús se realiza de forma intuitiva. Con el fin de prestar el mejor servicio, las empresas más consolidadas organizan cursos en los que forman a profesionales e instructores con gran competencia en tecnologías de sus Sistemas. Estas mismas empresas proveedoras cuentan con especialistas que se encargan de explicar el funcionamiento de los sistemas de Condominio Digital en el momento de la entrega e instalación del sistema, o puesta en marcha del equipo. A través del sus servicios postventa, ofrecen un servicio continuo de atención al usuario, personalizado y ágil, de manera que el representante de la empresa queda totalmente despreocupado por su mantenimiento.
Es importante que al establecer un sitio Web, se tenga previsto bajo cual de los modelos de negocio estará operando de tal manera que las expectativas de ingresos, participación y estrategias de mantenimiento sean apropiadas al requerido por el modelo seleccionado.
Generar un nuevo modelo de negocio significa crear un nuevo valor añadido a los clientes, siempre con la percepción de valor añadido desde el punto de vista de los clientes, no de la empresa. Así se percibe valor cuando un nuevo servicio o producto te ahorra tiempo, dinero, esfuerzo, ofrece un servicio personalizado, aporta nuevas soluciones, experiencias, sensaciones, emociones. En definitiva abre nuevas perspectivas respecto a lo existente en el mercado real o en el nuevo mercado virtual.
ANÁLISIS DE REQUERIMIENTOS
La problemática que queremos resolver surge como parte de la modernización de los servicios que se ofrecen en algunas redes de condominios, en esta etapa se buscó implementar un sistema con los datos personales de los inquilinos de dichos inmuebles, así como información referente a los servicios con que cuenta cada uno de ellos, quién los suministra, los pagos y las fechas en que deben realizarse de tal manera que podamos tener a la mano la información actualizable a corto plazo con los datos más relevantes.
Esta base de datos también podrá comunicarnos quién esta administrando tal o cual inmueble, su ubicación, quién y en cuanto lo renta o en su defecto nos dice si esta a la venta y cual es su costo de ser así.
36
En otras inmobiliarias, los sistemas no cumplen con todas las características que les permitan llevar un buen seguimiento del cliente, o bien, no se pueden consultar en internet por estar contenidos en un localhost.
Lo que buscamos al desarrollar este sistema en un entorno web, es lograr tener flexibilidad para ver el contenido desde cualquier lugar con acceso a Internet, así como evitar incompatibilidad con diferentes sistemas operativos.
FASE DE ELABORACIÓN
Las iteraciones se orientan al desarrollo de la línea base de la arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la línea base de la arquitectura.
REFINAMIENTO DEL ANÁLISIS Y DISEÑO DE REQUERIMIENTOS
Para el análisis y diseño de requerimientos, es decir, especificación de casos de uso, diagramas de clases y diagramas de secuencias utilizamos StarUML, por ser software libre y por ser una herramienta fundamental en el desarrollo de sistemas esto es porque permite generar diseños que capturan las ideas en forma convencional y fácil de comprender para comunicarlas a otras personas, pero esto se detallará a continuación.
CASO DE USO GENERAL
37 Fechas de pago
38 Inmuebles
En esta parte alta se encarga de registrar todos y cada uno de los inmuebles que serán manejados por la Inmobiliaria especificando si es para rentar o vender; baja será utilizado en caso de que el dueño de dicho inmueble ya no requiera los servicios de la empresa o bien si estaba a la venta ya se encuentre vendido; cambio es para modificar alguno de los datos de nuestro producto; y consulta es para que el empleado pueda saber que inmuebles están disponibles, su ubicación, su costo, los servicios con los que cuenta y el estado en el que se encuentra dicha propiedad.
Inquilinos
39 Proveedor
40 Rentas
41 Servicios
El apartado de servicios esta comisionado para que alta registre los nuevos servicios con que van a contar los inmuebles que maneja la empresa; baja se utilizará cuando dichos servicios ya no sean requeridos; cambios por las innovaciones que sean necesarias para la base en cuanto datos se refiere; consulta nos sirve para ver que con que servicios cuanta algún inmueble.
Status_ inmueble:
42 Trabajadores
Es importante contar con cierta información de los trabajadores que se encuentran afiliados a la empresa, este módulo se encarga de llevar ese control, alta se usa si un trabajador es de nuevo ingreso; baja por si deja de laborar en la agrupación; cambio por si es necesario modificar dichos datos; consulta nos sirve para saber quien labora con nosotros y que funciones desempeña.
DIAGRAMA DE ENTIDAD RELACION DE LA BASE DE DATOS
Para la Base de Datos de la Inmobiliaria se identificaron varias tablas de datos: una de ellas es la de Administración la cual contendrá los datos (usuario y contraseña) de los usuarios que podrán tener acceso a las pantallas de altas, bajas y cambios.
