Sei sulla pagina 1di 14

UNIVERSIDAD DE CHILE DEPARTAMENTO DE CIENCIAS DE LA COMPUTACION

Arquitectura de Software

Sistema de Venta Imobiliaria de Constru-Home


Prof. Sergio T. Ochoa
9 de julio de 2007.

Alejandra Isabel Su arez Ram rez

INDICE

INDICE

Indice
1. Enunciado 1.1. Requisitos Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Contexto de la Soluci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Solicitud 3. Soluci on 3.1. Supuestos . . . . . . . . . . . . . . . . 3.2. Requisitos de Calidad . . . . . . . . . 3.2.1. Funcionalidad . . . . . . . . . . 3.2.2. Usabilidad . . . . . . . . . . . . 3.2.3. Mantenibilidad . . . . . . . . . 3.2.4. Portabilidad . . . . . . . . . . . 3.2.5. Conabilidad . . . . . . . . . . 3.2.6. Eciencia . . . . . . . . . . . . 3.3. Dise no del Ambiente Operacional . . . 3.4. Estructuraci on B asica . . . . . . . . . 3.4.1. Modelo de Repositorio . . . . . 3.4.2. Modelo Cliente-Servidor . . . . 3.4.3. Modelo de Maquina Abstracta 3.4.4. Estructuraci on Funcional . . . 3.5. Descomposici on Modular . . . . . . . . 3.5.1. Sistema de ventas . . . . . . . 2 3 4 5 5 5 5 6 6 6 6 7 7 8 9 9 9 10 12 13 13

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

ENUNCIADO

1.

Enunciado

Una empresa constructora Constru-Home, dedicada a la construcci on de grandes proyectos habitacionales, lo ha contratado a usted para que realice el dise no arquitect onico de un sistema de ventas de sus propiedades. Las propiedades que tiene a la venta Constru-Home pueden ser: (a) inmuebles construidos por la empresa o (b) inmuebles que la empresa recibe como parte de pago de otra propiedad. Constru-Home desea implementar un portal de venta preliminar de sus propiedades (lograr acuerdo entre comprador y vendedor) a trav es de Internet. Esto involucra el ofrecer las propiedades que est an a la venta, la recepci on de ofertas por una propiedad, la iteraci on entre un potencial comprador y Constru- Home (consultas, negociaci on de precio y forma de pago, etc.) y la realizaci on de reservas. Para interactuar con el sistema, los potenciales clientes y los empleados de la empresa necesitan estar registrados. Cuando se realiza una venta preliminar (hay un acuerdo entre el comprador y el vendedor), ambas partes, concurren a una notar a para llevar a cabo la operaci on de venta. Una vez realizada la operaci on, dicha venta debe se registrada en el sistema. Para efectos del sistema, todas las ventas son al contado. Por otra parte, Constru-Home est a a cargo de registrar la propiedad vendida, en el conservador de bienes ra ces, y de entregar la correspondiente escritura al nuevo propietario de un inmueble. Se espera que el sistema permita dar seguimiento al proceso de escrituraci on de una propiedad, a partir de una operaci on de venta. El sistema debe enviar un correo al comprador, una vez que la escritura est a disponible para ser retirada en las ocinas de Constru-Home. Se espera que el sistema le permita a los potenciales clientes, agendar visitas a las propiedades en venta, dentro de los horarios de visita denidos por la empresa. Despu es de una visita, un potencial cliente puede hacer una reserva de la propiedad, siempre que esta no est e ya reservada a otro cliente. Al realizar una reserva, el sistema vericar a la conducta del potencial comprador contra los sistemas de DiCom. Las reservas no tienen costo alguno si la conducta del potencial comprador es buena. En caso contrario, la reserva s olo se llevar a a cabo si la persona abona el 1 % del precio de venta de la propiedad. La reserva le asegura al potencial comprador la exclusividad para negociar la compra de la casa por un per odo de 1 semana. El pago puede hacerse con cargo a una cuenta corriente. Como parte de una pol tica de expansi on de sus ventas, Constru-Home desea que inmobiliarias m as chicas distribuidas a lo largo de todo el pa s, puedan vender sus productos a cambio de una comisi on del 3 % sobre el precio de venta de la propiedad. S olo inmobiliarias debidamente autorizadas pueden realizar estas ventas. Para ello, se espera que el sistema tambi en ayude a que: (1) nuevas inmobiliarias puedan postular para vender las propiedades de Constru-Home, (2) se pueda autorizar a una nueva inmobiliaria a vender propiedades, en base a sus antecedentes, y (3) las inmobiliarias registradas puedan informar cada venta u oferta. El sistema debe ser muy vers atil en lo que respecta a b usqueda de propiedades por caracter sticas como: ubicaci on, edad, tipo de construcci on, precio, estado, servicios que posee, metros cuadrados de terreno y de construcci on, comodidades, tipo de pago, etc. Los usuarios del sistema deber an poder acceder v a Internet, a trav es de cualquier browser. El sistema tiene que ser f acil de usar pues la poblaci on destinataria es muy amplia y variada. En caso de que un cliente no encuentre en el portal el tipo de propiedad que anda buscando, 2

1.1

Requisitos Funcionales

ENUNCIADO

puede especicar su solicitud e ingresarla al sistema. Luego, un empleado de la empresa estar a pendiente de dicho pedido se encargar a de ofrecerle propiedades que se ajusten a lo que la persona andaba buscando. Los empleados del area de ventas y los gerentes de la empresa quieren poder analizar todo el espectro de datos (propiedades disponibles, ofertas realizadas, ventas hechas, pedidos pendientes, etc.) a n de identicar oportunidades de negocio. Por esa raz on se comprar a una herramienta de datamining y se espera que usted indique c omo deber a conectarse esta herramienta. Se espera alcanzar los 50.000 usuarios registrados en el per odo de 2 a nos. Se espera tambi en que el sistema sea capaz de atender hasta 800 usuarios simult aneos (entre empleados y clientes). Actualmente Constru-Home se encuentra en un proceso de conversaci on con otra gran empresa constructora a n de integrarse para dominar el mercado Chileno. Si esto llegara a llevarse a cabo, se espera que este sistema sirva tambi en para apoyar a la empresa partner. Debido a que el futuro es a un incierto, se espera que el sistema de software sea sucientemente exible como para ser adaptado a otras realidades sin incurrir en un esfuerzo mayor. Si la fusi on se lleva a cabo, posiblemente los sistemas de informaci on y los datos de ambas empresas se fusionen tambi en. Si esta fusi on se lleva a cabo, la poblaci on de usuarios crecer a a 150.000 aproximadamente, y el sistema deber a soportar una carga de 2.500 usuarios conectados.

1.1.

Requisitos Funcionales
11. Permitir a los clientes agendar visitas a las propiedades en venta. 12. Permitir al cliente realizar una reserva de una propiedad. 13. La reserva se puede realizar solamente cuando la propiedad no se encuentre reservada anteriormente. 14. Al realizar una reserva, el sistema vericar a la conducta del potencial comprador ante los sistemas de DiCom. 15. Permitir el pago en l nea con cargo a una cuenta corriente. 16. Cobrar un 5 % de comisi on por ventas de otras inmobiliarias m as peque nas ( estas u ltimas debidamente autorizadas). 17. Ayudar en la selecci on de inmobiliarias para integrar sus ventas. 18. Ayudar en la autorizaci on de inmobiliarias m as peque nas. 19. Manejar los registros de las inmobiliarias integrantes de ofertas u/o ventas. 3

1. Permitir la venta de propiedades a trav es de un portal Web. 2. Recibir ofertas por parte de los clientes. 3. Realizar distintas consultas sobre las distintas caracter sticas de los productos. 4. Mostrar el disponibles. catalogo de las propiedades

5. mostrar el detalle de cada una de las propiedades. 6. Efectuar reservas. 7. Lograr un acuerdo entre el comprador y el vendedor. 8. Las ventas deben ser registradas una vez realizadas. 9. Realizar un seguimiento al proceso de escituraci on de una propiedad. 10. Enviar un correo al comprador una vez que la escritura est e disponible para ser retiradas en las ocinas de Constru-Home.

1.2

Contexto de la Soluci on

ENUNCIADO

1.2.

Contexto de la Soluci on

1. Las inmobiliarias peque nas no quieren experimentar cambios en su infraestructura para adaptarse al portal. 2. Las inmobiliarias peque nas quieren mantener la independencia de datos, respecto al portal. 3. Las inmobiliarias peque nas quieren que las ventas a trav es del portal sean transparentes para sus sistemas. 4. Las inmobiliarias peque nas quieren mantener la privacidad de negocios (dentro de lo posible).

SOLUCION

2.

Solicitud

Se solicita a usted que presente (proponer y justicar), como parte del documento de dise no arquitect onico, los siguientes tems: 1. En base a la descripci on del problema, identicar cu ales requisitos de calidad son relevantes y cu ales son cr ticos. 2. Realizar el dise no del ambiente operacional del sistema, determinando el tipo de soluci on de hardware que sera utilizada para soportar la soluci on. 3. Realizar un dise no arquitect onico del sistema (estructura y din amica), determinando las funciones principales de los macro-componentes de la arquitectura. 4. Realizar la descomposici on modular de un macrocomponente no-trivial escogido por usted. Justique las decisiones de dise no que usted tome.

3.
3.1.

Soluci on
Supuestos
Las inmobiliarias peque nas con motivo de asegurar su privacidad de informaci on y no exponer la base de datos propia crear a una interfaz para comunicarse con el sistema. Solo clientes previamente registrados pueden acceder y realizar transacciones en el sistema.

3.2.

Requisitos de Calidad

Basandonos en los criterios de: Funcionalidad Conabilidad Usabilidad Eciencia Mantenibilidad Portabilidad destacaremos cuales son los requisitos de calidad que son cr ticos y enunciaremos los requisitos relevantes.

3.2

Requisitos de Calidad

SOLUCION

3.2.1.

Funcionalidad

La funcionalidad se reere al conjunto de requisitos existentes referidos a la capacidad de un software. Como estamos efectuando transacciones en el sistema donde est a involucrado en: el acuerdo entre el comprador y el vendendor,las transacciones monetarias como la posibilidad de pago en una cuenta corriente y el seguimiento de escrituraci on es necesario considerar la seguridad. Adem as tenemos que tomar en cuenta que el sistema se conectar a con distintas interfaces de sistemas para acceder a los datos proporcionados por las peque nas inmoviliarias que forman parte de Constru-Home, es por eso que la Interoperabilidad toma un caracter cr tico. Funcionalidad Pertinencia Presici on Interoperabilidad Seguridad 3.2.2. Usabilidad

En el caso de la usabilidad (atributos y/o requisitos relacionados con el esfuerzo o evaluaci on de uso) los conceptos relacionados no son un problema mayor (puesto que la empresa es dedicada al comercio de inmuebles), no se requiere un nivel de destreza para operar y la idea es que no tome mayor problema poder operar el software, sin embargo, como se trata de un sistema de ventas toma el car acter de crucial que el sistema tenga una buena impresi on por parte del cliente porque esto favorece la decisi on de compra. Usabilidad Entendibilidad Operabilidad Aceptaci on de Uso

3.2.3.

Mantenibilidad

Debemos considerar que dentro de las expectativas de la empresa esta considerado el crecimiento de la empresa enfocado en una fusi on otra gran empresa. Es por eso que es importante considerar la extensibilidad porque esta directamente relacionado con las expectativas de la empresa. Mantenibilidad Analizabilidad Estabilidad Extensibilidad 3.2.4. Portabilidad

De acuerdo a lo que hemos pensado anteriormente, no es relevante la migraci on a distintas tecnologias o ambientes. 6

3.2

Requisitos de Calidad

SOLUCION

3.2.5.

Conabilidad

Como se trata de un sistema de transacci on, se debe considerar la conabilidad ( capacidad de mantener un nivel adecuado de servicio). Conabilidad Tolerancia a Fallas Adecuaci on Recuperabilidad 3.2.6. Eciencia

Como estamos tratando con sistemas externos (como las interfaces de las bases de datos de las inmobiliarias peque nas) debemos considerar el tiempo de uso pues es posible que se generen timeout u otros inconvenientes. Eciencia Rendimiento Uso del tiempo

3.3

Dise no del Ambiente Operacional

SOLUCION

3.3.

Dise no del Ambiente Operacional

El ambiente operacional consta de un rewall que sirve de monitoreo de puertos y actividad en las conexiones entrantes al sistema, luego tenemos un servidor dedicado (puede ser perfectamente un Cluster) donde se aloja el servidor Web y las aplicaciones que gestionan la conexi on de la transacci on con las dem as interfaces y con la aplicaci on que gestiona las transacciones, en la tercera maquina tenemos los servicios de datos proporcionado por la base de datos y la interfaz para acceder a los datos. Externamente tenemos las conexiones provenientes de las distintas empresas inmobiliarias que nos proporcionan su oferta a trav es de una conexi on protegida por aplicaciones que maquinas de las mismas inmobiliarias proveen y cuyas conexiones pasan a trav es de un rewall a un router el cual gestiona la conexi on al servidor de aplicaci on y as poder integrar los datos (la oferta) de las empresas que se vayan integrando con el tiempo. A nuestro sistema tambi en se le agregar an los servicios proporcionados por DiCom el cual monitorear a la actividad de los potenciales compradores en sus bases de datos. Ademas debemos contar con una interfaz de conexi on con el sistema bancario para realizar las consultas y las transacciones a la cuenta corriente de los usuarios. Los clientes acceden al sistema a trav es de un navegador Web (Web Browser) y sus actividades son procesadas por un servidor de transacciones el cual accede al servidor de aplicaciones para realizar consultas. El usuario gerencial puede hacer un analisis de las transacciones realizadas durante la ejecuci on del sistema a trav es de herramientas de data-mining las que se ejecutar an desde afuera en la base de datos.

c Figura 1: Esquema General del Ambiente Operacional

3.4

Estructuraci on B asica

SOLUCION

3.4.

Estructuraci on B asica

Principalmente tenemos tres modelos de estructuraci on de un sistema (modelos generales) y son: Modelo de Repositorio. Modelo Cliente/Servidor. Modelo de Maquina Abstracta. Al respecto podemos rescatar distintas caracter sticas de estos modelos para considerar en la implementaci on de nuestro sistema. 3.4.1. Modelo de Repositorio

El modelo de repositorio es bueno cuando no tenemos tantas bases de datos distribuidas como en nuestro caso. Al quedar centralizado el acceso a los datos quedamos desprotegidos ante una eventual ca da del repositorio. No garantiza la privacidad del negocio al mantener los datos centralizados (riesgo de exposici on de datos condenciales). Los subsistemas quedan forzados a unicar las pol ticas de administraci on de los datos lo que no concuerda con el contexto de soluci on. Sin embargo dentro de sus ventajas est a la de compartir ecientemente grandes cantidades de datos, sin embargo, sus ventajas tienden a la centralizaci on de los datos, lo que facilita su administraci on pero no garantiza la condencialidad del negocio cuando el sistema se compone de diversas bases de datos de empresas que compiten entre s . 3.4.2. Modelo Cliente-Servidor

El modelo cliente servidor tiene ciertas ventajas, y una de ellas es que la distribuci on de datos es directa (utilizando sockets), sin embargo, las empresas que se adhieren a nuestro sistema tienen una tasa de volatilidad, eso quiere decir, que en alg un momento podr an desagregarse y asimismo integrarse a nuestro sistema, lo que produce un re-dise no del c odigo especicando las conexiones que se requieran con las distintas interfaces que provean las bases de datos de las empresas que conforman parte del sistema. Tambi en debido a que la comunicaci on es directa se vuelve engorroso al momento de querer intercambiar datos (streaming de los sockets) a diversos empleados en la organizaci on. Otro aspecto fundamental para no decidirse exclusivamente por este modelo es que no permite datamining, el cual es un requisito para nuestro sistema.

3.4

Estructuraci on B asica

SOLUCION

3.4.3.

Modelo de Maquina Abstracta

El modelo de Maquina Abstracta permite modelar las interfaces entre los subsistemas y organizar el sistema en base a un conjunto de capas (o de maquinas abstractas) estableciendo relaciones de un solo nivel a la modicaci on de las capas lo que nos permite realizar un modelo hibrido de nuestro sistema utilizando distintos modelos de estructuraci on. En nuestro sistema implementaremos una maquina descentralizada compuesta por capas para asegurar los requerimientos en el contexto de la soluci on previstas para las empresas inmobiliarias donde la condencialidad de datos exigidas en el contexto de soluci on estar a a disposici on del modelo de cliente-servidor. Para evitar que las inmobiliarias peque nas se adapten al portal sufriendo las consecuencias de adaptarse a un modelo de repositorio (esto signica unicar los servicios que las componen) se propone que los datos sean manejados a trav es de una interfaz de servicios, lo que promete mayor seguridad en los datos y privacidad en cada inmobiliaria y se pueden implementar t ecnicas de autenticaci on en la conexi on (encriptaci on, uso de certicados y llaves p ublicas) donde se puede especicar los criterios de operaci on sobre el sistema de la inmobiliaria. Esta interfaz permite manejar la volatilidad de los servicios de las inmobiliarias que componen el sistema sin necesidad de realizar cambios en el c odigo del portal.

Figura 2: Sistema de Estructuraci on Basica

10

3.4

Estructuraci on B asica

SOLUCION

Nivel de Aplicaci on: En este nivel las aplicaciones son las encargadas de ofrecer la interfaz donde el usuario (ya sea cliente, usuarios gerenciales y administradores de datos) acceden a los servicios del sistema, en el caso de los clientes estos pueden acceder a realizar las operaciones ya sea de consulta, reserva, compra, etc. y los usuarios gerenciales pueden hacer uso de las herramientas de datamining con la base de datos del sistema (ojal a un datawarehouse), tambien el administrador puede hacer uso del sistema administrador de base de datos y del DAO. Nivel de L ogica de Negocio: En este nivel se implementar a la soluci on que permita gestionar el uso de las funcionalidades del sistema y mejoras como el manejo de perles de usuario, carritos de compra etc. En esta etapa es importante la implementaci on de los m etodos para realizar las compras y la emisi on de comprobantes de transacci on hacia el usuario. Nivel de Servicios: El modelo de datos virtual es muy u til ya que sin afectar a la funcionalidad real del portal provee de un modelo de datos virtual al portal de Constru-Home el cual puede modicar el modelo de datos real. El nivel de servicios es el encargado de lograr la integraci on de los componentes del sistema externos a su nucleo como lo es el sistema DiCom y el sistema de gesti on de transacciones del banco. Nivel de Datos: El nivel de datos es el encargado de proveer la persistencia de datos y contiene todas las fuentes de datos disponibles en el sistema, es importante destacar que los datos de las distintas inmobiliarias, as como los sistemas de DiCom son paralelos a la base de datos de Constru-Home y no existe relaci on entre ellos a ese nivel por lo que se pueden considerar independientes y ajenos.

11

3.4

Estructuraci on B asica

SOLUCION

3.4.4.

Estructuraci on Funcional

El sistema general se comprende de estos sub-sistemas, en donde esta descompuesto el sub-sistema de ventas.

Figura 3: Esquema de Soluci on (Nivel 0)

La interacci on entre estos tres sub-sistemas es a trav es de datos, en este caso analizaremos el sistema de venta que est a previamente descompuesto.

12

3.5

Descomposici on Modular

SOLUCION

3.5.
3.5.1.

Descomposici on Modular
Sistema de ventas

Figura 4: Esquema de Soluci on (Nivel 0)

13

Potrebbero piacerti anche