PROPUESTA DE UNA FAMILIA DE ARQUITECTURA PARA UN PORTAL COOPERATIVO

ALVARO FERNANDO QUINTERO GONZALEZ

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA

DEPARTAMENTO DE INGENIERIA DE SISTEMAS Y COMPUTACIÓN 2003

PROPUESTA DE UNA FAMILIA DE ARQUITECTURA PARA UN PORTAL COOPERATIVO

ALVARO FERNANDO QUINTERO GONZALEZ

Trabajo de grado presentado como requisito para optar al título de Magíster en Ingeniería de Sistemas y Computación

Asesor: Germán Bravo

Jurados:

Alberto García Francisco Rueda Maria del Pilar Villamil

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA

DEPARTAMENTO DE INGENIERIA DE SISTEMAS Y COMPUTACIÓN 2003

A mi Dios a quien todo le debo, y cuya prueba mas grande de su existencia son mis padres. A mis padres por su apoyo incondicional.

AGRADECIMIENTOS Al Departamento de Ingeniería de Sistemas y Computación de la Universidad de los Andes. A Germán por su ayuda y colaboración. A mis amigos.

CONTENIDO

pág.

0 INTRODUCCIÓN................................................................................................................... 11

1 OBJETIVOS DEL PROYECTO............................................................................................. 12

1.1 OBJETIVO GENERAL .................................................................................................... 12 1.2 Objetivos Específicos ........................................................................................................ 12

2 ANTECEDENTES .................................................................................................................. 13

3 ALCANCE .............................................................................................................................. 14

4 MARCO TEORICO ................................................................................................................ 15

4.1 MERCADOS B2B............................................................................................................. 15 4.2 EVOLUCION DE LAS APLICACIONES E-COMMERCE ........................................... 16 4.3 ARQUITECTURA DE SOFTWARE ............................................................................... 19 4.3.1 Metodología para implementar una arquitectura............................................................ 21 4.3.1.1 Creación de los casos del negocio para el sistema. ..................................................... 22 4.3.1.2 Entendimiento de los requerimientos. ......................................................................... 22 4.3.1.3 Creación o selección de la arquitectura. ...................................................................... 22 4.3.1.4 Representación y publicación de la arquitectura. ........................................................ 22 4.3.1.5 Análisis y evaluación de la arquitectura. ..................................................................... 22 4.3.1.6 Diseño del sistema basado en la arquitectura. ............................................................. 22 4.3.2 Estilos organizacionales del software............................................................................. 23 4.3.2.1 Dispositivos de Acceso................................................................................................ 23 4.3.2.2 Aplicaciones de acceso................................................................................................ 23 4.3.2.2.1 Web Servers............................................................................................................... 23 4.3.2.3.2 Interactive Voice Response (IVR) Gateways. ........... ¡Error! Marcador no definido. 4.3.2.3.3 Internet Telephony Gateways. ................................................................................... 25 4.3.2.3.4 Gateways inalámbricos para Accesos Web. .............................................................. 26 4.3.2.3.5 E-Mail Gateways ....................................................................................................... 26 4.3.2.3.6 Webcasting ................................................................................................................ 26 4.3.2.3 Middleware.................................................................................................................. 26 4.3.2.3.1 Database Middleware: ............................................................................................... 27 4.3.2.3.2 Application Middleware: ........................................................................................... 27 4.3.2.4 Aplicaciones y Servicios Orientados a las Transacciones........................................... 29 4.3.2.4.1 Open Buying On the Internet..................................................................................... 29 4.3.2.4.2 Open Financial Exchange.......................................................................................... 29 4.3.2.5 Repositorios de Conocimiento .................................................................................... 29 4.3.2.6 Servicios de Agentes ................................................................................................... 29

4.3.3 Estructuras de las arquitecturas ...................................................................................... 30 4.3.3.1 Estructura modular: ..................................................................................................... 30 4.3.3.2 Estructura conceptual o lógica..................................................................................... 30 4.3.3.3 Estructura de coordinación o de la organización de los procesos. .............................. 30 4.3.3.4 Estructura física. .......................................................................................................... 30 4.3.3.5 Estructura de usos. ....................................................................................................... 30 4.3.3.6 Estructura de llamados................................................................................................. 31 4.3.3.7 Flujo de datos. ............................................................................................................. 31 4.3.3.8 Estructura de clases. .................................................................................................... 31 4.3.4 Principales estilos de arquitectura .................................................................................. 32 4.3.4.1 Tuberías y Filtros (Pipes and Filtres). ......................................................................... 33 4.3.4.2 Abstracción de datos y enfoque orientado a objetos. .................................................. 34 4.3.4.3 Basado en eventos e Invocación implícita................................................................... 35 4.3.4.4 Sistemas por Capas...................................................................................................... 36 4.3.4.5 Repositorios ................................................................................................................. 37 4.3.4.6 Intérpretes .................................................................................................................... 38 4.3.4.7 Control de Procesos ..................................................................................................... 38 4.3.4.8 Procesos Distribuidos .................................................................................................. 38 4.3.4.9 Organización Rutina Principal / Subrutinas. ............................................................... 39 4.4 FAMILIAS DE ARQUITECTURA.................................................................................. 39 4.5 LENGUAJES DE DESCRIPCIÓN DE ARQUITECTURAS (ADL) .............................. 39 4.5.1 Componentes .................................................................................................................. 40 4.5.2 Conectores ...................................................................................................................... 40 4.5.3 Sistemas.......................................................................................................................... 40 4.5.4 Propiedades..................................................................................................................... 40 4.5.5 Restricciones................................................................................................................... 40 4.5.6 Estilos ............................................................................................................................. 40 4.5.7 Representaciones ............................................................................................................ 40

5 CASO DE ESTUDIO: PORTAL COOPERATIVO. ............................................................. 41

5.1 CONTEXTO...................................................................................................................... 41 5.1.1 Clasificación de las cooperativas dentro de los tipos de negocios B2B......................... 41 5.1.2 Justificacion .................................................................................................................... 42 5.1.3 Origen del proyecto ........................................................................................................ 42 5.1.4 Restricciones................................................................................................................... 42 5.1.5 Uso de internet en colombia ........................................................................................... 43 5.1.6 Ventas a traves de internet en Colombia y latinoamérica .............................................. 43 5.1.7 Beneficios del proyecto .................................................................................................. 44 5.2 DESCRIPCIÓN DEL PORTAL COOPERATIVO. ......................................................... 45 5.2.1 Participantes del servicio ................................................................................................ 45 5.2.2 Descripción del funcionamiento del servicio ................................................................. 46 5.2.2.1 Servicios de valor agregado......................................................................................... 47 5.2.2.2 Ejecución de transacciones.......................................................................................... 48

5.2.2.3 Logística de entrega..................................................................................................... 50 5.2.3 Casos de uso ................................................................................................................... 50 5.2.3.1 Casos de Uso del Asociado. ........................................................................................ 50 5.2.3.2 Casos de uso del Administrador de la Cooperativa..................................................... 51 5.2.3.3 Casos de Uso del visitante o cliente. ........................................................................... 52 5.2.3.4 Casos de Uso del Administrador del Portal................................................................. 53

6 DEFINICIÓN DE UNA FAMILIA DE ARQUITECTURAS PARA PORTALES COOPERATIVOS Y DE UNA METODOLOGÍA PARA SU DEFINICIÓN............................. 55

6.1 ESTILO ORGANIZACIONAL DEL SOFTWARE ......................................................... 56 6.2 ARQUITECTURA ESTRUCTURAL .............................................................................. 57 6.2.1 Estructura modular ......................................................................................................... 57 6.2.1.1 Módulo De Tienda Virtual .......................................................................................... 59 6.2.1.2 Módulo De Usuarios.................................................................................................... 59 6.2.1.3 Módulo De Catálogos.................................................................................................. 60 6.2.1.4 Módulo De Transacciones Financieras........................................................................ 60 6.2.1.5 Módulo De Servicios ................................................................................................... 61 6.2.1.6 Módulo De Apoyo A Las Compras............................................................................. 61 6.2.1.7 Módulo De Búsquedas ................................................................................................ 62 6.2.1.8 Módulo De Pagos ........................................................................................................ 62 6.2.1.9 Modulo De Logística ................................................................................................... 63 6.2.1.10 Módulo De Administración ......................................................................................... 63 6.2.1.11 Módulo De Apoyo A La Bodega De Datos................................................................. 63 6.2.1.12 Modulo De Auditoría .................................................................................................. 64 6.3 PARÁMETROS DE FUNCIONAMIENTO..................................................................... 64 6.4 MODELO DE DATOS PARCIAL ................................................................................... 70 6.5 DEFINICION DE UNA FAMILIA DE PORTALES COOPERATIVOS........................ 74 6.5.1 Elaborar los diagramas de caso de uso. .......................................................................... 76 6.5.2 Establecer el contexto del sistema. ................................................................................. 76 6.5.3 Construcción de los arquetipos....................................................................................... 77 6.6 INSTANCIA DE LA FAMILIA ....................................................................................... 87 6.6.1 Escoger casos de uso. ..................................................................................................... 87 6.6.2 Tomar diagramas de secuencia....................................................................................... 88

7 IMPLEMENTACIÓN DE UN PROTOTIPO ......................................................................... 94

7.1 EVALUACIÓN DE LA ARQUITECTURA .................................................................... 98

8 CONCLUSIONES Y TRABAJO FUTURO......................................................................... 100

BIBLIOGRAFIA......................................................................................................................... 102

LISTA DE TABLAS Tabla 1. Soporte de diferente tipos de tipos de aplicación en diferentes dominios del comercio

electrónico durante la era de los Mainframe. ........................................................................ 17 Tabla 2. Soporte de diferente tipos de tipos de aplicación en diferentes dominios del comercio

electrónico durante la era cliente/servidor............................................................................. 18 Tabla 3. Soporte de diferente tipos de tipos de aplicación en diferentes dominios del comercio

electrónico durante la era e-commerce. ................................................................................. 19 Tabla 4. Utilización de Servidores Web...................................................................................... 24 Tabla 5. Comparación entre servidores web. ............................................................................... 24 Tabla 6. Tipos de Estructura de Arquitecturas. ........................................................................... 31 Tabla 7. Uso de Internet en Colombia........................................................................................... 43 Tabla 8. Comercio electrónico negocio a consumidor en millones de dólares. ............................ 43 Tabla 9. Navegantes compradores en América Latina en 1999. ................................................... 44

LISTA DE FIGURAS

Figura 1. Relación entre la arquitectura y el ambiente .................................................................. 20 Figura 2 Netcraft Web Server Survey .......................................................................................... 24 Figura 3. Estilo pipes and filters.................................................................................................... 34 Figura 4. Estilo enfoque orientado a objetos ................................................................................. 35 Figura 5. Estilo sistema por capas ................................................................................................. 37 Figura 6. Repositorios ................................................................................................................... 38 Figura 7. Funcionamiento del Servicio en el portal ..................................................................... 46 Figura 8. Proceso de Compra – Venta. ......................................................................................... 49 Figura 9. Casos de Uso de Asociado ............................................................................................ 51 Figura 10. Casos de Uso de Administrador de Cooperativa ........................................................ 52 Figura 11. Casos de Uso de Visitantes ......................................................................................... 53 Figura 12. Casos de Uso de Administrador del portal.................................................................. 54 Figura 13. Estilo Organizacional del Portal.................................................................................. 57 Figura 14. Estructura Modular...................................................................................................... 58 Figura 15. Conversión de requerimientos en código.................................................................... 75 Figura 16. Contexto del sistema. .................................................................................................. 76 Figura 17. Componente de Transacciones.................................................................................... 82 Figura 18. Componente de Servicios............................................................................................ 82 Figura 19. Componente de Transacciones.................................................................................... 83 Figura 20. Componente de Inclusión............................................................................................ 84 Figura 21. Componente de Borrado ............................................................................................. 85 Figura 22. Componente de Consulta ............................................................................................ 85 Figura 23. Familia Portal Cooperativo ......................................................................................... 86 Figura 24. Caso de uso. ................................................................................................................ 88 Figura 26. Caso de uso en ADL . ................................................................................................. 90

LISTA DE ANEXOS

ANEXO 1 DESCRIPCION DE LA ARQUITECTURA EN SU PRIMERA APROXIMACIÓN...................................................................................................................................................... 106 ANEXO NO 2 . DESCRIPCIÓN DE LA FAMILIA PORTALES COOPERATIVOS EN LENGUAJE ADL. ...................................................................................................................... 112 ANEXO 3. INSTANCIA DE LA FAMILIA PORTAL COOPERATIVO ............................... 116

MISC-02-2-13

11

0 Introducción

Con la globalización de la economía, los progresos tecnológicos de la humanidad y la cada día mayor automatización de los procesos, las grandes compañías adquieren mayores ganancias, los clientes mejores y más variados productos y servicios. Pero esto no tiene que ser un resultado exclusivo de los llamados países industrializados, o de las grandes compañías, debe ser un proceso que tiene que darse al interior de nuestros países tercermundistas, y al interior de medianas y pequeñas empresas. Concientes de esta necesidad dentro de la Universidad de los Andes se ha querido establecer una propuesta para acercar la tecnología a cooperativas colombianas. En el proceso de plantear una solución, son muchos los factores que deben ser tenidos en cuenta, uno de ellos es plantear una arquitectura para esta solución, pero por que plantear una arquitectura?. La diferencia entre un sistema con una arquitectura definida se podría semejar a la diferencia entre una expansión urbana descontrolada que crece de cualquier manera sin tener en cuenta normas de seguridad, de urbanismo y desarrollo , y una ciudad donde se ha tenido en cuenta estas normas de forma tal que la comunidad se vea como un todo y sirva a las necesidades de los habitantes de una forma eficiente y segura. Esta tesis tiene como propósito ofrecer a los pequeños negocios integrantes de cooperativas o portales electrónicos de cooperativas, que puede ser extendidos a otros negocios con características similares, una propuesta de una arquitectura, que atrape la complejidad del desarrollo de una solución de esta naturaleza, y permita servir de base para determinar la forma correcta de posteriormente construir un portal.

MISC-02-2-13

12

1 OBJETIVOS DEL PROYECTO 1.1 OBJETIVO GENERAL Plantear una familia para los portales cooperativos y que sirva como estructura para representar cualquier instancia de un portal cooperativo. 1.2 OBJETIVOS ESPECÍFICOS

• Identificar los diferentes componentes que formarán parte de esta familia y establecer las propiedades de los mismos .

• Diseñar el modelo de la organización e interacción de los diferentes

componentes que se han determinado como necesarios dentro de la arquitectura.

• Utilizar un lenguaje formal de especificación de la arquitectura propuesta.

MISC-02-2-13

13

2 Antecedentes En nuestro medio las cooperativas, no están haciendo presencia en Internet. No están haciendo presencia de ningún tipo no se encuentran páginas web de muchas de ellas, y como portal cooperativo no existe ninguna. Es necesario poner al servicio de nuestras cooperativas, la tecnología , que les permita sobrevivir en un mercado donde día a día es necesario hacer presencia en la Web, y esta presencia debe ser flexible, escalable y montada sobre una arquitectura, que permita soportar esta flexibilidad, esta escalabilidad, que tome ventaja de las nuevas tecnologías, y que sea fácil de personalizar. El concepto de arquitectura de software es un concepto en el cual hoy en día hay un gran acercamiento por parte de los constructores de software, pero aun así, no se puede encontrar una verdad que sea considerada absoluta, o una definición en la cual toda la comunidad esté de acuerdo, pero aun así, es un gran paso en el diseño de software, ya que durante décadas, la construcción de software se limitó exclusivamente a los requerimientos técnicos. No se puede considerar una arquitectura como algo exacto pues aunque dos arquitectos tengan el mismo conjunto de requerimientos pueden presentar dos propuestas muy diferentes de arquitectura. Hoy en día la construcción de una arquitectura para un software es más común, a partir de la década de los 90 surgió esta idea que poco a poco se ha ido consolidando, hasta ser considerada hoy en día como parte esencial en la construcción de cualquier software o de cualquier tecnología de la información. A pesar de los avances que se han logrado en el campo de la definición de arquitecturas este es un proceso que aun está en desarrollo, y hacia el cual se han interesado diferentes organismos tanto de carácter académico como comercial.

MISC-02-2-13

14

3 Alcance El alcance del actual proyecto, es definir una propuesta de arquitectura que pueda servir de guía en el proceso de entendimiento, funcionamiento e implementación de un portal para pequeñas y medianas empresas cooperativas. Dentro de este proceso determinar cómo sería la propuesta de una familia para este tipo de portales. Con el objeto de validar la arquitectura planteada antes, se desarrolla un prototipo que permita llevar a la práctica algunos de los componentes determinados en la arquitectura y algunas de las funciones de esos componentes.

MISC-02-2-13

15

4 MARCO TEORICO En este capítulo se mencionan aspectos teóricos que son necesarios para un mejor entendimiento del trabajo que se lleva a cabo. Los aspectos involucrados son los mercados negocio a negocio (B2B), la evolución que se ha presentado en las aplicaciones de comercio electrónico, y conceptos básicos de arquitectura de software. La profundización sobre cada uno de estos aspectos se lleva a cabo a continuación. 4.1 MERCADOS B2B. Dentro de los mercados B2B, o mercados electrónicos o simplemente e-hubs, Kaplan y Sawhney [KAPLAN 2000] determinaron dos grandes factores que determinan el tipo de mercado que se va a llevar a cabo. Estos dos factores son el tipo de productos o productos que se ofrecen por parte de los vendedores, y cómo estos productos son comprados. Dentro de la distinción de qué tipo de productos o servicios son los que se ofrecen se hacen dos grandes distinciones, aquellos que venden materia prima para y/o componentes que están involucrados directamente en otros productos o en procesos. Estos tipos de negocios son llamados negocios de entradas manufacturadas. A diferencia de aquellos negocios donde están involucradas materias primas, existen aquellos donde se puede encontrar servicios, reparaciones, bienes operativos, partes de repuesto, tiquetes de aerolíneas y servicios. Estos tipos de negocios son llamados negocios de entradas operativas. Dentro de la forma en la cual se compran los productos es posible encontrar mercados en los cuales suministro de productos o servicios involucra contratos con proveedores calificados. En este tipo de mercados los contratos tienden a ser a largo plazo y los vendedores y compradores casi siempre desarrollan una relación muy estrecha. Es conocido como systematic sourcing. A diferencia de los mercados en los cuales el objetivo del comprador es satisfacer una necesidad inmediata al más bajo costo, este tipo de relaciones entre los compradores y vendedores no es una relación estrecha, es más muchas veces no se llega a saber quién le está comprando a quién. Es conocido como spot sourcing.

MISC-02-2-13

16

Dentro de estas dos grandes clasificaciones, por tipo de producto y/o servicio, y por la forma en que se llevan a cabo estos negocios, se pueden encontrar cuatro tipos de negocios resultantes de la combinación de las clasificaciones anteriores. MRO hubs: Son mercados horizontales que permiten negocios tipo systematic sourcing de entradas de manufactura. Yield Manager: Son mercados horizontales que permiten negocios tipo spot sourcing de entradas operativas. Exchanges: Son mercados verticales en los cuales se permiten negocios tipo spot sourcing de entradas manufacturadas. Catalog Hub: Son mercados verticales que permiten systematic sourcing de entradas manufacturadas. 4.2 EVOLUCION DE LAS APLICACIONES E-COMMERCE Dentro de la evolución que se ha presentado en las aplicaciones e-commerce se encuentran 3 principales eras[Rajput 2000]. Estas eras son:

• Era del Mainframe. • Era Cliente/servidor. • Era del comercio electrónico.

En el comienzo del uso de aplicaciones informáticas para las empresas se desarrollaron en lenguajes tradicionales como COBOL y residían baja ambientes con procesadores CISC y otros, en Mainframes. (Ver tabla 1)

MISC-02-2-13

17

Tabla 1. Soporte de diferente tipos de tipos de aplicación en diferentes dominios del comercio electrónico durante la era de los Mainframe. TRANSACTIONAL

APPLICATIONS INQUIRY APPLICATIONS

CONSULTATIVE APPLICATIONS

Business to Business

Limited (Dumb terminal applications for EDI)

Limited (Dumb terminal applications for EDI)

!

Business to Consumer

! ! Limited (call-centers)

Intrabusiness " " Limited (e-mail applications)

[Rajput 2000] Con este tipo de aplicaciones se pudieron automatizar muchos procesos en el interior de la organización, pero el alcance de estas aplicaciones estaba limitado a ser empleadas únicamente allí, pero al hablar del interior de la organización se hace referencia no sólo a la parte organizacional sino física pues no se contaba con accesos remotos, los terminales eran terminales brutas que debían estar conectadas a un mainframe para poder funcionar, por eso se empezó a trabajar en estos problemas lo que llevó a la siguiente fase. Durante la segunda fase las empresas desearon integrar sus procesos de negocios permitiendo flujos de información más rápidos y más efectivos entre los procesos del negocio y manejar los enlaces internos y externos de la empresa. Es cuando aparecen las aplicaciones cliente servidor y los sistemas que se manejaron hasta ese momento migran hacia ERP (enterprise resource planning) (Ver Tabla 2)

MISC-02-2-13

18

Tabla 2. Soporte de diferente tipos de tipos de aplicación en diferentes dominios del comercio electrónico durante la era cliente/servidor. TRANSACTIONAL

APPLICATIONS INQUIRY APPLICATIONS

CONSULTATIVE APPLICATIONS

Business to Business

Limited (dedicated connections)

Limited (dedicated connections)

!

Business to Consumer

! ! " enhanced call-centers

Intrabusiness " " (data warehouses)

" (enabled byclient/server groupware)

[Rajput 2000]. Con la aparición de las aplicaciones cliente / servidor se permitió a las empresas fortalecer los vínculos con socios establecidos e impulsarlos a explorar otros vínculos estratégicos, posibilitaron a las empresas a utilizar los datos almacenados en las bases de datos de una forma eficiente, apareció el desarrollo de las bodegas de datos, pero cuál fue el problema que seguía sin resolverse?, el problema radicaba en el hecho que los consumidores finales tenían un acceso limitado, y por qué un acceso limitado?, pues son varias las respuestas, entre ellas , equipos como computadores , PDAs, teléfonos celulares, eran de muy difícil acceso o simplemente aun no existían, a su vez acceder a una red pública para el acceso a Internet era muy restringido. Ante todas estos requerimientos sin resolver llega la era e-commerce. En la era e-commerce se empieza a aprovechar al máximo el desarrollo de aplicaciones basadas en Internet, pues ya es accesible para mucha gente, ya no es privilegio de unas cuantas universidad y de algunos cuantos organismos gubernamentales acceder a una red de datos pública, o la Internet, por esa razón, el crecimiento de la presencia de empresas en la red es exponencial al comienzo de una forma tímida en la cual simplemente se perseguía hacer presencia, de una manera sencilla, y sin mayores pretensiones, pero poco a poco, las empresas empiezan a descubrir el verdadero potencial y es así como empiezan a surgir empresas virtuales y se empiezan a realizar transacciones no sólo entre empresas y por medio de líneas dedicadas sino con clientes , y estos clientes tienen la ventaja de ser cualquier tipo de clientes, por lo que las empresas ven incrementado el número de posibles clientes de una manera directamente proporcional al crecimiento de los usuarios de la Internet. A su vez la popularización de los

MISC-02-2-13

19

computadores el ingreso al mercado de nuevos mecanismos como los teléfonos celulares, las PDAs llevaron a que se incrementara la forma de acceder y compartir información sin importar el lugar del mundo en el cual se encuentre el cliente, el socio o simplemente las personas que desean conocer las organizaciones. (ver Tabla 3) Tabla 3. Soporte de diferente tipos de tipos de aplicación en diferentes dominios del comercio electrónico durante la era e-commerce. TRANSACTIONAL

APPLICATIONS INQUIRY APPLICATIONS

CONSULTATIVE APPLICATIONS

Business to Business

! (e.g., Internet EDI, OBI protocol)

! ! (Internet groupware)

Business to Consumer

! (Available through Web, IVRs, wireless telephones)

! (Available through Web, IVRs, wireless telephones)

! (Available through Internet, pagers, wireless telephones, Web-enabled call-centers, etc.)

Intrabusiness ! ! (Enabled by knowledge repositories)

!

[Rajput 2000]. 4.3 ARQUITECTURA DE SOFTWARE En la definición de una arquitectura de un software determinado se podría pensar que ante un conjunto de requerimientos los resultados obtenidos por dos ingenieros que estén pensando en una arquitectura pero se encuentran trabajando separadamente serían los mismos, pero esto nunca ocurrirá. ¿A qué se debe esto?. Se debe a que hay otros factores que influyen en la creación de una arquitectura como son las influencias técnicas sociales y del negocio que influye en los ingenieros. Por esta razón podría plantearse que existen un ciclo de influencia entre el ambiente formado por estas tres influencias y la arquitectura como se muestra en la figura uno.

MISC-02-2-13

20

Figura 1. Relación entre la arquitectura y el ambiente

Pero qué es la arquitectura de un software?. Se encuentran muchas definiciones dentro de ellas una de las más aceptadas es aquella expresada por BASS, CLEMENTS Y KAZMAN [BASS 1998] “La arquitectura de software de un programa o de un sistema de cómputo es la estructura de las estructuras del sistema, la cual abarca los componentes software, las propiedades externas que son visibles de esos componentes y las relaciones que hay entre ellos”. Cuando se habla de las propiedades externas que son visibles se entiende como lo que otros componentes pueden asumir de los otros. También se podría preguntar qué es una arquitectura dentro del ambiente computacional. Dentro de este ambiente el Open Group Arquitectural Framework [TOGAF 2001], define la arquitectura de un sistema desde dos puntos de vista

1. La descripción formal de un sistema o un plan detallado del sistema a nivel de componentes que guiará su implementación.

2. La estructura de los componentes, su interrelación y los principios y las guías que dirigen su diseño y evolución en el tiempo.

A su vez la definición de arquitectura dada por el estándar 1471-2000 del ANSI/IEEE [ANSI/IEEE 2000] es “la organización fundamental de un sistema, envuelto en sus componentes, las relaciones que hay entre ellos y el ambiente y los principios que gobiernan su diseño y evolución”. Existen conceptos importantes que deben ser tenidos en cuenta en la creación de la arquitectura de software como son:

• Metodologías de construcción de arquitecturas. • Estilos organizacionales del software. • Estilos de arquitectura. • Estructuras de las arquitecturas • Modelos de referencia. • Arquitecturas de referencia.

MISC-02-2-13

21

Estos aspectos se profundizan a continuación. 4.3.1 Metodología para implementar una arquitectura. Existen diferentes propuestas de metodologías para implementar arquitecturas entre ellas tenemos:

• Philippe Krutchen [Krutchen 1995] • Shlaer Sally [Shlaer 1997] • Jan Bosch y Peter Molin [Bosch 1999] • Bass, Clements y Kazman [Bass 1998]

Krutchen sugiere llevar un proceso que abarca cinco vistas:

• Vista lógica. La cual describe el modelo de objetos del diseño, en caso de ser orientado a objetos.

• Vista de procesos. • Vista física. Describe la equivalencia entre el software dentro del hardware, • Vista de desarrollo. Describe la organización estática del software en su

ambiente de desarrollo • Vista de escenarios. Basada en algunos casos de uso que lleven a cabo las

cuatro vistas anteriores. Shlaer y Mellor sugieren un proceso de siete pasos.

• Caracterizar el sistema. Se elige qué características del sistema se tomarán en cuenta para la arquitectura.

• Definir las entidades conceptuales. Se definen y describen las entidades conceptuales de la arquitectura.

• Definir la teoría de las operaciones. Se describe cómo el sistema trabaja como un todo.

• Recolectar datos de existencias. Se analiza si ya existe algo de lo que se necesitaría en la arquitectura.

• Llenar la arquitectura. Aquellos objetos que necesitan información son alimentados con ella.

• Construir arquetipo. Sirve como base para probar la arquitectura planteada. • Generar código. Construir scripts para el sistema.

Bosch y Molin sugieren:

• Identificar las entidades de la arquitecturas, las cuales están relacionadas con la definición del dominio, pero ellos mismo concluyen que las entidades generalmente no se encuentran en el dominio, ya que “una diferencia entre

MISC-02-2-13

22

el diseño de la arquitectura y el análisis del dominio , es que la arquitectura de un sistema generalmente cubre múltiples dominios”.

Bass, Clements y Kazman proponen. Esta metodología analiza siete pasos a seguir en este proceso.

• Creación de los casos del negocio para el sistema. • Entendimiento de los requerimientos. • Creación o selección de la arquitectura. • Representación y publicación de la arquitectura. • Análisis y evaluación de la arquitectura. • Implementación del sistema basado en la arquitectura. • Aseguramiento que la implementación se de conforme a la arquitectura.

4.3.1.1 Creación de los casos del negocio para el sistema. Crear los casos del negocio analiza cuestiones como cuánto debería costar, cuál es el mercado, hacia el cuál está enfocado, cuál es el tiempo estipulado para incursionar en el mercado, si este sistema necesita interactuar con otros sistemas y definir frontera del mismo. 4.3.1.2 Entendimiento de los requerimientos. Hay una variedad de técnicas para representar los requerimientos de los usuarios y de los clientes. Una de ellas los casos de uso. En sistemas críticos una alternativa es la máquina de estados finitos. 4.3.1.3 Creación o selección de la arquitectura. Dentro de la creación o selección de la arquitectura está el uso de estilos de arquitectura, modelos de referencia y arquitecturas de referencia. 4.3.1.4 Representación y publicación de la arquitectura. La arquitectura debe ser dada a conocer a todos los involucrados en el proyecto que pueden estar interesados, con el fin que cumpla los requisitos de todos los involucrados. 4.3.1.5 Análisis y evaluación de la arquitectura. Al no existir una única forma de crear una arquitectura, así mismo tampoco existe “la técnica” ni el “el método” para evaluarla. Este análisis debe darse a la luz de si la arquitectura cumple los requerimientos que los usuarios plantearon. 4.3.1.6 Diseño del sistema basado en la arquitectura. Esta actividad está relacionada con llevar a cabo el desarrollo, la implementación utilizando como referencia la arquitectura propuesta.

MISC-02-2-13

23

4.3.2 Estilos organizacionales del software Los estilos de arquitectura pueden ser pensados como un conjunto de restricciones sobre una arquitectura. Estas restricciones están dadas sobre los tipos de los componentes y sus patrones de interacción, estas restricciones definen un conjunto o familia de arquitecturas que las satisfacen. Dentro de los principales componentes que soportan cualquier estilo de organización se encuentran:

• Dispositivos de acceso. • Aplicaciones de Acceso. • Aplicaciones Interpuestas entre dos aplicaciones (Middleware). • Aplicaciones y Servicios Orientados a las transacciones. • Repositorios de Conocimiento. • Servicios de Agentes.

4.3.2.1 Dispositivos de Acceso Los dispositivos por medio de los cuales se puede tener acceso al portal estará limitado inicialmente a los PC’s y Notebooks, que es el medio más común en nuestro pais. A medida que sistemas como los GSM/telefonos celulares, Pagers, HPCs, WebTVs y Car Devices tengan una mayor acogida en nuestro medio podría pensarse en una solucion para estos dispositivos de acceso. Otra de las ventajas de plantear una arquitectura es que los detalles de cómo implementar cada una de los componentes de la misma pasa a un segundo plano, al poder extraer conceptualmente cómo se debe llevar a cabo cada uno de los procesos. 4.3.2.2 Aplicaciones de acceso. Las aplicaciones de acceso proveen la interfaz para que los usuarios y los sistemas que requieren acceder los recursos y sistemas de computo propios de la empresa. Estas aplicaciones interactúan con los equipos que reciben sus requerimientos y los enruta hacia los servicios de información de la empresa. Entre las aplicaciones de acceso que se proponen se encuentran: 4.3.2.2.1 Web Servers. Le permite a los usuarios acceder paginas HTML por medio de sus navegadores. Los servidores web interactúan con los navegadores por medio del protocolo http. Apache es el más popular como se puede apreciar en la tabla y figura siguientes.

MISC-02-2-13

24

Figura 2 Netcraft Web Server Survey

[NETCRAFT 2002] Tabla 4. Utilización de Servidores Web Developer November 2002 Percent December

2002 Percent

Change Apache 10729462 64.69 11065427 66.54 1.85 Microsoft4244842 25.59 4113590 24.74 -0.85 Zeus 271753 1.64 258367 1.55 -0.09 SunONE 230902 1.39 229081 1.38 -0.01 [NETCRAFT 2002] También se puede decir que Apache es un servidor http open-source, que es gratuito y de código abierto, como se aprecia en la siguiente tabla, en la cual se encuentra una comparación entre algunos de los servidores, por versión, sistemas operativos para los que existe versión, y su rango de precios. Tabla 5. Comparación entre servidores web.

Server Version Operating System Price Range

AOLserver 3.1 Digital UNIX, SCO, HPUX, Windows NT, Linux, Windows 95, FreeBSD, Windows 98, IRIX, Solaris

Free

Amiga Web Server 1.0 Amiga Free

MISC-02-2-13

25

Server Version Operating System Price Range

Apache 1.3.17 NetBSD, Digital UNIX, AIX, OS/2, Windows 3.x, SCO, HPUX, Novell NetWare, Macintosh, Be OS, Windows NT, Linux, VMS, AS/400, Windows 95, FreeBSD, IRIX, Solaris

Free

Commerce Server/400 1.0D AS/400 $4995 (suggested retail)

Internet Information Server

4.0 Windows NT Free with NT 4.0 option pack

Java Server 1.1 OS/2, HPUX, Windows NT, Linux, Windows 95, IRIX, Solaris

$295

Lotus Domino Go Webserver

4.6.1 Digital UNIX, AIX, OS/2, HPUX, Windows NT, Windows 95, IRIX, Solaris

$495; free demo

[WEBCOMPARE 2002] Se puede ver que es soportado por un gran número de plataformas. 4.3.2.2.2 Interactive Voice Response (IVR) Gateways. Permite a los clientes llamar a través del PSTN y proveer un menú llamado call tree de opciones basado en un script preprogramado y predefinido. Los IVR son programas especiales de software que requieren una tarjeta hardware y pueden correr sobre NT o Uníx. 4.3.2.2.3 Internet Telephony Gateways. A medida que se ha incrementado el uso de Internet y la disponibilidad de redes de banda ancha se ha incrementado el uso de la telefonía internet. La telefonía internet está basada en paquetes. Se usa el estándar H.323 para transmitir voz sobre Internet.

MISC-02-2-13

26

4.3.2.2.4 Gateways inalámbricos para Accesos Web. El principal problema en el acceso a Internet a través de aparatos móviles son:

• Ventana muy pequeña de los aparatos móviles. • Ancho de banda limitado de las redes inalámbricas que inhiben el transporte

de contenido rico en imágenes, texto, videos, etc. 4.3.2.2.5 E-Mail Gateways Uno de los servicios originales de Internet ha evolucionado hasta convertirse en uno de los principales medios de comunicación entre los usuarios de Internet. Se encuentran los llamados e-mail gateways inteligentes los cuales ofrecen:

• Identificar la intención del mail haciendo un análisis del asunto. • Enrutar el e-mail al departamento o servicio representativo más calificado. • Identificar el tipo del mensaje haciendo un análisis del cuerpo del mail y

disparando una apropiada respuesta. • Enrutar los e-mail de resultados. • Hacer seguimiento a los e-mail.

4.3.2.2.6 Webcasting Conjunto de tecnologías que facilitan la entrega de contenido de audio/video y multimedia a través de Internet. 4.3.2.3 Middleware El middleware es uno de los componentes que ofrece servicios auxiliares tales como seguridad, procesamiento de transacciones, y todo los elementos necesitados para la construcción de sistemas e-commerce complejos. Los componentes middleware también incluyen el software que pueden ejecutar las aplicaciones backend. La tecnología middleware también facilita la integración con los servicios backend de la empresa, aunque en este punto vale resaltar que la presencia que hoy en día hacen las cooperativas en Internet es casi nula, aun yendo más lejos, muchas de ellas, ni siquiera tienen aplicaciones al interior de la organización que automaticen los procesos. Dentro de los conceptos planteados para el middleware se analizan los siguiente.

• Gateways de acceso. • Interfaces de bases de datos. • Interfaces de comunicación y redes.

MISC-02-2-13

27

• Interfaces de aplicación para facilitar la interoperabilidad entre aplicaciones distribuidas.

• Servicios de aplicación y redes, por ejemplo servicios de seguridad, servicios de directorio y servicios de transacciones.

• Capas lógicas implementadas usando tecnologías de software tradicionales o estructuras de objetos como Enterprise Java Beans (EJB).

• Aplicaciones de servicios tales como soporte a un gran número de usuarios, tolerancia a fallas, manejo de sesiones , accesos múltiples entre otros.

También se necesario mencionar que el middleware, provee los siguientes servicios a las sistemas de comercio electrónico.

• Soporte de diversos ambientes del lado del cliente, tales como los clientes java, los clientes Actives, y otros ambientes gráficos.

• Soporte de varios tipos de dispositivos de información. • Manejo de flujos complejos de transacciones. • Interactuar con diversidad de plataformas. • Incorporar detección de fallas y capacidades de recuperación.

4.3.2.3.1 Database Middleware: El database middleware “esconde” las complejidades del acceso a la base de datos por parte de las aplicaciones, y también “esconde” las diferencias de implementación de varias bases de datos. Dentro de los estándares más populares de database Middleware esta el Java Database Connectivity (JDBC) y el Open Database Connectivity (ODBC).

• JDBC: Esta es una especificación que permite a los clientes java acceder el backend de las bases de datos.

• ODBC: Es una especificación desarrollada por Microsoft que permite el acceso a bases de datos a través de diferentes vendedores.

4.3.2.3.2 Application Middleware: Las diferentes tecnologías de las aplicaciones middleware y los productos permiten que se ejecuten otras aplicaciones, extender la funcionalidad de las aplicaciones, y proveer varias servicios de cada una de las rutinas de las aplicaciones en tiempo de ejecución. Dentro de las principales aplicaciones de middleware se encuentran:

4.3.2.3.2.1 Common Gateway Interface (CGI). Los programas CGI pueden ser considerados como la forma tradicional en la cual se invocaban los programas residentes en el servidor, generalmente esos programas CGI son scripts PERL que invocan programas que se encuentran en el servidor y que

MISC-02-2-13

28

pueden estar desarrollados en cualquier lenguaje. Los programas CGI interfasan con el servidor web usando variables de ambiente que el servidor web recibe por medio del URL del browser. El programa CGI interactúa con las aplicaciones backend o las bases de datos, consigue los resultados, los formatea en un apropiado formato y los presenta dentro del servidor web. Los CGI son usualmente adecuados para aplicaciones de comercio electrónico no tan cargadas. Los programas CGI son programas completos que invocan un proceso por cada solicitud.

4.3.2.3.2.2 FastCGI: El fastCGI fue desarrollado por Open Market para resolver algunos de los problemas en rendimiento de los CGI. Los fastCGI facilitan esto permitiendo que los programas permanezcan activos en memoria. Los programas FastCGI mantienen conexiones persistentes con las aplicaciones y esperando por las solicitudes del servidor incrementando de esta manera el desarrollo de las aplicaciones.

4.3.2.3.2.3 Apis de los vendedores: Los desarrolladores han podido usar las APIs propias de cada producto, como una alternativa a los scripts CGI, para invocar los programas residentes en el servidor. Estas APIs extienden la funcionalidad de varios servidores web permitiendo escribir los módulos adicionales necesitados para la ejecución de los aplicaciones y programas backend.

4.3.2.3.2.4 Servidores de aplicación. El servidor de aplicaciones involucra varias servicios de bases de datos, redes y aplicaciones. Algunos de las aplicaciones para desarrollo e implementación incluye las siguientes características:

• Software funcional de servidor web. • Funciones y servicios de groupware. • Funciones para el servicio de transacciones. • Ambientes de ejecución para aplicaciones lógicas, tales como EJBs, COM

servers y otros. • Ambientes visuales como IDE para el desarrollo de aplicaciones en el lado del

servidor. • Interfaces para las aplicaciones y para los datos que se encuentre en el sitio. • Un ambiente integrado que permite el desarrollo, implementación e

integración de aplicaciones en el lado del servidor.

MISC-02-2-13

29

• Servidor de aplicaciones que soporten solicitudes de browser y otros medios de acceso.

• Facilidad para el desarrollo de aplicaciones escalables a través de múltiples servidores y sistemas. El desarrollo escalable usualmente requiere poder trasladar varios módulos a varios servidores y construir apropiadas interfaces entre las aplicaciones y los módulos del sistema. Los servidores de aplicaciones proveen los fundamentos básicos que permiten un desarrollo de aplicaciones flexible.

4.3.2.4 Aplicaciones y Servicios Orientados a las Transacciones. Las aplicaciones en el comercio electrónico, deben estar basadas en las tecnologías basadas en Internet. Estas tecnologías incluyen HTML y http, obviamente Internet, redes. El protocolo de negocios basados en Internet incluyen Open business On the Internet (OBI), Open Financial Exhange (OFX), and EDI. 4.3.2.4.1 Open Buying On the Internet Son especificaciones técnicas y no técnicas para permitir comprar y vender bienes de bajo costo sobre Internet. Se ha enfocado en la adquisición de materiales indirectos. 4.3.2.4.2 Open Financial Exchange Es la especificación para el intercambio de información financiera en Internet. 4.3.2.5 Repositorios de Conocimiento El manejo del conocimiento es una disciplina emergente que se enfoaca en impulsar las ventajas de la información de la organización y el capital intelectual para permitir a las organizaciones operar más efectivamente. 4.3.2.6 Servicios de Agentes En la actualidad existen numerosas definiciones de lo que se entiende como agente inteligente, algunos les atribuyen más propiedades que otros, pero en general integrando y unificando dos de ellas la pronunciado por Weiss [Weiss 1999] y Bradshaw [Bradshaw 1999] se puede decir que un agente de software inteligente, es una entidad de software que funciona continua y autónomamente para cumplir con sus objetivos de diseño, en un ambiente particular, con frecuencia habitado por otros agentes y procesos.

MISC-02-2-13

30

4.3.3 Estructuras de las arquitecturas Las estructuras de cualquier sistema, en este caso de arquitecturas, son los diferentes puntos de vista desde los cuales se puede describir el funcionamiento de un sistema. Dentro de las principales estructuras de arquitecturas se encuentran:

• Estructura modular. • Estructura conceptual o lógica. • Estructura de coordinación y organización de procesos. • Estructura física. • Estructura de usos. • Estructura de llamados. • Flujo de datos. • Estructura de clases.

A continuación está una descripción general de cada una de estos puntos de vista. 4.3.3.1 Estructura modular: En la estructura modular las unidades son asignaciones de trabajo (tales como especificación de interfaces, código, estrategias de prueba, etc.)y tienen productos asociadas por cada una de estas unidades. Esta estructura modular es usada para adjudicar las labores a realizar en un proyecto y otros recursos durante el mantenimiento aunque también puede ser considerados dentro del desarrollo. 4.3.3.2 Estructura conceptual o lógica. Las unidades son abstracciones de los requerimientos funcionales del sistema. 4.3.3.3 Estructura de coordinación o de la organización de los procesos. Esta vista es ortogonal a la vista de las estructuras conceptual y modular y tiene que ver con la parte con los aspectos dinámicos del sistema cuando ya está en ejecución. Las unidades son procesos o hilos. 4.3.3.4 Estructura física. Esta vista muestra como el software hace uso del hardware. Esto es particularmente de interés para los sistemas distribuidos y paralelos. 4.3.3.5 Estructura de usos. Las unidades son procedimientos o módulos. La estructura de usos es usada para sistemas de ingeniería que pueden ser fácilmente un subconjunto o extenderse a un sistema más grande.

MISC-02-2-13

31

4.3.3.6 Estructura de llamados. Las unidades son usualmente (sub)procedimientos. La estructura de llamados es usada para hacer un seguimiento del flujo de la ejecución del programa. 4.3.3.7 Flujo de datos. Las unidades son programas, módulos o estados del sistema. Esta vista es de ayuda para verificar la funcionalidad en el comportamiento del sistema. Si el único mecanismo para la transferencia de control es el llamado a los programas este tipo de estructura se convierte en la estructura de llamados. 4.3.3.8 Estructura de clases. Las unidades son objetos. Esta vista soporta colecciones de comportamiento similar por ejemplo las clases, herencias y demás conceptos de la teoría de objetos. Estos tipos de estructuras pueden resumirse en la tabla seis que es tomada de BASS, CLEMENTS Y KAZMAN Tabla 6. Tipos de Estructura de Arquitecturas.

Estructura Unidades Relación Representada por los enlaces

Util Para

Modular Asignaciones de trabajo

-Es un submódulo de. -Comparte secreto con

Localización recursos, planeamiento y estructuración de proyectos. Ocultamiento de información. Encapsulamiento Control de configuración.

Conceptual Funciones Comparte datos con

Entender el espacio del problema.

Procesos Programas Ejecuta concurrentemente con. Puede ejecutarse concurrentemente con. Excluye, precede, etc.

Análisis de ejecución. Análisis de Desarrollo. Análisis de Planeación.

MISC-02-2-13

32

Física Hardware Comunica con Análisis de Seguridad, disponibilidad y ejecución.

Uso Programas Requiere la presencia correcta de

Subconjuntos de diseño. Extensiones de diseño.

Llamados Programas Invoca con parámetros

Eliminación de cuellos de botella. Perfilamiento de Ejecución. Seguimiento de requerimientos funcionales

Flujo de datos Tareas Funcionales

Puede enviarle datos a

Seguir requerimientos funcionales.

Flujo de control Estados o modos del sistema

Transición a, sujeto a los eventos y condiciones enmarcados en los enlaces.

Puede ser base para la simulación automática y verificación del comportamiento funcional y la sincronización.

Clase Objetos Es una instancia de. Comparte métodos de acceso de

En los sistemas diseñados orientados a objetos, produce implementaciones fáciles.

[Bass 1998] 4.3.4 Principales estilos de arquitectura Los estilos son la forma en la cual cualquier arquitectura está organizada, se puede decir que son los patrones de organización del sistema. Dentro de los principales estilos de arquitectura se encuentran

• Tuberías y Filtros (Pipes and Filters). • Abstracción de datos y enfoque orientado a objetos. • Basado en eventos e invocación implícita. • Sistemas por capas. • Repositorios.

MISC-02-2-13

33

• Intérpretes. • Control de procesos. • Procesos Distribuidos. • Organización Rutina principal/subrutinas. A continuación se especifica cada uno de ellos.

4.3.4.1 Tuberías y Filtros (Pipes and Filtres). Cada componente tiene un conjunto de entradas y un conjunto de salidas. Cada componente lee una secuencia de datos a la entrada y produce otra secuencia a la salida. Esto proceso involucra muchas veces aplicar una transformación local a los datos de entrada. Estos componentes que realizan este proceso de recibir los datos y muchas veces transformarlos son llamados filtros. Los conectores dentro de este estilo de arquitectura los cuales pasan los datos de un filtro a otro son llamados tuberías. Dentro de las ventajas de este estilo de arquitectura están:

• Permite al diseñador entender el comportamiento total de entradas y salidas como una simple composición del comportamiento de filtros individuales.

• Permite la reutilización, ya que dos filtros cualquiera pueden ser relacionarse, siempre que ellos estén de acuerdo con los datos que están siendo transmitidos entre ellos.

• Los sistemas son fáciles de mantener y enriquecidos, nuevos filtros pueden ser adicionados a los sistemas existentes y los viejos filtros pueden ser reemplazados por nuevos.

• Permite cierto tipo de análisis especializado, tales como análisis de rendimiento y cuellos de botella.

• Soporta ejecución concurrente. • Cada filtro puede ser implementado como una tarea separada y

potencialmente se puede ejecutar en paralelo con otros filtros. Pero como toda solución también hay algunas desventajas como son:

• Sistemas de filtro y tuberías tienden generalmente a procesamiento en batch. • Aunque filtros pueden procesar datos incrementalmente ellos son

independientes, así el diseñador debe pensar en cada filtro como aquel elemento que provee una transformación completa de los datos de entrada en los datos de salida.

• Este tipo de sistemas puede ser obstaculizado por tener que mantener correspondencia entre dos secuencia de datos separados pero que a su vez están relacionados.

• Dependiendo de la implementación, puede llegar a ser necesario tener un común denominador en la trasmisión de los datos, que puede terminar en

MISC-02-2-13

34

incrementar el trabajo en cada filtro puesto que debe analizar cada uno de los datos que recibe de los demás filtros.

Una representación gráfica de este estilo es mostrada a continuación en la figura 3 Figura 3. Estilo pipes and filters.

[Shaw 1996] 4.3.4.2 Abstracción de datos y enfoque orientado a objetos. En este estilo la representación de los datos y sus operaciones primitivas son encapsuladas en un tipo de dato de dato abstracto o en objetos. Los componentes de este estilo son los objetos, y las instancias de tipos de datos abstractos. Los objetos interactúan a través de la invocación de funciones y procedimientos. En este estilo cada objeto es responsable por preservar la integridad de su representación y esta representación es desconocida para los otros objetos. Algunas ventajas de este estilo son:

• Como el objeto oculta su representación de los demás objetos es posible cambiar su implementación sin afectar los clientes.

• Se puede descomponer los problemas en colección de agentes interactuando. Así mismo algunas de las desventajas encontradas son:

• Para que un objeto interactúe con otro es necesario conocer la identidad del otro objeto. Este es un contraste con el estilo de filtros y tuberías, donde los filtros no necesitan conocer que otros filtros se encuentran en el sistema para interactuar con ellos.

Filters

Pipes

MISC-02-2-13

35

• En el sistema orientado a objetos cuando la identidad de un objeto cambia es necesario modificar a todos los objetos que lo invoquen explícitamente.

Una representación gráfica de este estilo es mostrada a continuación en la figura 4 Figura 4. Estilo enfoque orientado a objetos

[Shaw 1996] 4.3.4.3 Basado en eventos e Invocación implícita. En un sistema en el cual la interfaz de cada componente da una colección de procedimientos y funciones, así mismo como en un sistema orientado a objetos, los componentes interactúan con los demás invocando explícitamente algunas rutinas, sin embargo, recientemente, ha crecido el interés en una técnica de integración alternativa. La idea detrás de invocación implícita es que en vez de invocar un procedimiento directamente, un componente puede anunciar a hacer un broadcast de uno o más eventos. Otro componente en el sistema puede registrar un interés en un evento asociando un procedimiento con él. Cuando el evento es anunciado el sistema invoca todos los procedimientos que han sido registrados para el evento, de esta forma el anuncio de un evento implícitamente causa la invocación de procedimientos en otros módulos. Dentro de los beneficios de este estilo de arquitectura se cuentan:

objobj

obj

ob

obj

obj

obj

obj op

op

op opop

op

opop

op

op

op

opop

op

opop

Proc Call

Manager (ADT)

MISC-02-2-13

36

• Hay un gran soporte para la reutilización de componentes, ya que estas invocaciones implícitas facilitan el crecimiento del sistema.

• Los componentes pueden ser reemplazados por otros sin afectar a los demás componentes.

Dentro de las desventajas están:

• Los componentes están supeditados al control computacional sobre el sistema, si este control no funciona ellos no funcionaran.

• Cuando un componente anuncia un evento puede ser que ningún componente responda a este requerimiento, ya que no se garantiza que exista un componente que lo cumpla.

• Otro problema está en el intercambio de datos. Algunas veces los datos pueden ser intercambiados mediante eventos, pero en otras ocasiones los eventos en el sistema deben depositarlos en un repositorio que se debe compartir para la interacción.

• El tratamiento de la confiabilidad puede ser complicado ya que el significado de un procedimiento que anuncia los eventos dependerá del contexto en el cual es invocado.

4.3.4.4 Sistemas por Capas Un sistema por capas es organizado jerárquicamente y cada capa provee un servicio a la capa superior y sirve como cliente a la capa inferior como se muestra en la figura 5. (tomado de SHAW, GARLAN [Shaw 1996]) Dentro de las ventajas se encuentra:

• Soporta el diseño basado en el incremento de niveles de abstracción. • Soporta escalabilidad. • Soporta reutilización.

Dentro de las ventajas se encuentran:

• No todos los sistemas son fácilmente representados por un sistema multicapas.

• Si se logra analizar el software como un sistema multicapas, la consideración sobre el desarrollo puede requerir un acoplamiento muy grande entre las funciones de alto nivel y los detalle específicos en el momento de la implementación.

• Puede llegar a ser difícil encontrar los niveles adecuados de abstracción. Una representación gráfica de este estilo es mostrada a continuación en la figura 5

MISC-02-2-13

37

Figura 5. Estilo sistema por capas

[Shaw 1996] 4.3.4.5 Repositorios En este estilo hay dos clases muy diferentes de componentes, una estructura central de datos que representa el estado actual, y una colección de componentes independientes que operan sobre ese almacén central de datos. La interacción entre el repositorio y sus componentes externos puede variar significativamente entre sistemas. Una representación gráfica de este estilo es mostrada a continuación en la figura 6.

CoreLevel

Base utility

Useful systems

UsersComposites of various elements

Usually procedure calls

MISC-02-2-13

38

Figura 6. Repositorios

[Shaw 1996] 4.3.4.6 Intérpretes En una organización de intérpretes el software es representado como una máquina virtual. Un interprete incluye el seudo programa que está siendo interpretado y la interpretación que hace la máquina del mismo. En este estilo generalmente se encuentran cuatro componentes como son un motor que interpreta el trabajo que se debe realizar, una memoria que contiene el seudo código que va a ser interpretado, una representación del control de estado y la representación del estado actual del programa que está siendo simulado. 4.3.4.7 Control de Procesos Otro estilo de arquitecturas es basado en el proceso de control de ciclos. Este sistema es poco reconocido en la comunidad de ingeniería de software. En este estilo lo importante son los procesos y las variables que están involucradas en estos procesos. 4.3.4.8 Procesos Distribuidos Este estilo es principalmente usado por las organizaciones en las cuales están involucrados proyectos de software en los cuales están presentes aplicaciones multiprocesos. Su característica primaria está dada por sus características topológicas, tales como estrella, anillo u otras. De otra parte también puede

MISC-02-2-13

39

considerarse en términos de protocolos interprocesos que son usados para la comunicación entre los mismos. 4.3.4.9 Organización Rutina Principal / Subrutinas. Este estilo fue de los primeros en ser considerados cuando evolucionaron los lenguajes de programación. Un problema se presentaba cuando estos lenguajes no soportaban la construcción de módulos, con lo que el resultado obtenido era un programa principal y un conjunto de subrutinas que debían estar presentes tantas veces como fuera necesario. 4.4 FAMILIAS DE ARQUITECTURA. Las familias de arquitectura son una clase muy especial de estilo de arquitectura razón por la cuál se menciona en un ítem aparte y no como un estilo más. Una familia de arquitectura es un estilo en el cual se pueden definir :

• Un conjunto de propiedades . • Un conjunto de restricciones. • Una estructura por defecto.

Las propiedades ofrecen el vocabulario que será utilizado en el diseño. Las restricciones determinan cómo las instancias de las propiedades pueden ser usadas. La estructura por defecto determina el mínimo conjunto de instancias que deben aparecer en cualquier sistema de una familia. Las familias de arquitectura también conocidas como familia de sistemas son parte fundamental en la construcción de líneas de productos, los cuales son un conjunto de sistemas, que comparten un características en común que satisfacen las necesidades específicas de un segmento particular del mercado [CLEMENTS 2002a] 4.5 LENGUAJES DE DESCRIPCIÓN DE ARQUITECTURAS (ADL) La arquitectura del software de un sistema define su estructura en un nivel muy general, exponiendo de forma global cómo están organizados los componentes que interactúan al interior del mismo. La práctica del diseño de arquitecturas en los años anteriores estuvo dada de una forma que podría considerarse ad hoc, informal e informal. Buscando que esta informalidad no existiera más se crearon los

MISC-02-2-13

40

lenguajes de descripción de arquitecturas (ADL). Ejemplos de ADL incluyen Acme [Garlan 97],Aesop[Garlan 94], Armani [Monroe 98] , Rapide[Rapide 96] , UniCon[Shaw 96] ,Wright[Allen 97]. En los lenguajes ADL a pesar de que existen algunas diferencias entre ellos es posible encontrar elementos comunes que son tenidos en cuenta como son [Garlan 95]. 4.5.1 Componentes Representan los elementos computacionales primarios y los almacenes de datos de un sistema. Ellos corresponden a las cajas en las descripciones que se hacía de cajas y líneas en la arquitectura de software. 4.5.2 Conectores Representan interacciones entre componentes. Los conectores median las actividades de coordinación y comunicación entre componentes. 4.5.3 Sistemas Representa configuraciones (grafos) de componentes y conectores. 4.5.4 Propiedades Representan Información Semántica sobre el sistema y sus componentes que van en la parte interna de la estructura. 4.5.5 Restricciones Representan la restricción sobre el diseño de la arquitectura que debería ser cierto aun en la evolución en el tiempo. 4.5.6 Estilos Representan familias o sistemas relacionados. Un estilo de arquitectura define un vocabulario de diseño de elementos y reglas para la composición de los mismos. 4.5.7 Representaciones Son objetos que contienen sistemas, que anteriormente se conocía como subsistemas. Se utiliza para describir un elemento en términos de otros componentes interconectados.

MISC-02-2-13

41

5 CASO DE ESTUDIO: PORTAL COOPERATIVO. El caso de estudio es un portal cooperativo, el cual se encarga de la ventas de productos que son fabricados, por los asociados a dicho ente. Dentro del análisis de la organización y funcionamiento del portal en este capítulo se incluye un aparte sobre el contexto en el cual se lleva a cabo, una descripción de quienes forman el portal, la manera en la cual opera, que servicios ofrece, y que actividades lleva a cabo. A continuación se especifica cada uno de ellos. 5.1 CONTEXTO 5.1.1 Clasificación de las cooperativas dentro de los tipos de negocios B2B. De acuerdo a lo planteado Kaplan y Sawhney [Kaplan 2000] sobre los dos grandes factores que determinan el tipo de mercado que se va a llevar a cabo1 es posible encontrar que las cooperativas manejan los dos tipos de mercados, aquellos en los que se ofrecen materias primas, como es el caso de las cooperativas agrarias españolas, y aquellos que ofrecen componentes y servicios como copime en nuestro país. De acuerdo a la clasificación por tipo de producto y/o servicio planteada por Kaplan y Sawhney [Kaplan 2000] el portal de la cooperativa no sería un mercado neutral, ya que estaría controlado por la cooperativa. Este seria un caso especial de un negocio B2B, ya que seria un modelo “forward aggregators”, pues favorecería a los vendedores, ya que todos ellos serian presentados a todos los clientes, a diferencia del modelo “reverse aggregator” en el cual el favorecido es el cliente y en el cual para un solo cliente se le presentan muchas opciones de venta. Dentro del portal se encuentran clientes y asociados, la cooperativa que seria el e-hub. Los clientes serian a su vez compradores y vendedores con lo cual se esta adoptando un modelo de negocios poderoso como es el “matching mechanism”. Es un modelo poderoso ya que los roles de los actores pueden ser variados. Los compradores pueden ser vendedores y viceversa. Esto se da gracias a que los asociados de la cooperativa desarrollarían ambas funciones, de modo tal que al ingresar un nuevo asociado, no solamente ganan los vendedores que contaran con un cliente potencial, sino también los compradores pues contaran con un potencial proveedor.

1 Ver seccion 4.1

MISC-02-2-13

42

5.1.2 Justificacion En un mercado donde día a día la economía crece y las barreras se derrumban, los negocios B2B han crecido de una forma sorprendente y las cooperativas colombianas no pueden y no deben ser ajenas a esta situación. Comenzar a implementar soluciones B2B en nuestro medio, no es un camino fácil. Pues están involucrados factores como web sites de las cooperativas, redes, equipos tecnológicos, pero si es un paso necesario pues se crean nuevas oportunidades de negocio. 5.1.3 Origen del proyecto Los departamentos de Ingeniería de Sistemas y Computación, de Ingeniería Eléctrica y Electrónica y de Ingeniería Industrial de la Universidad de los Andes, interesados en el tema de comercio electrónico han unido sus esfuerzos para explorar metodológicamente esta tecnología y desarrollar un proyecto piloto para mostrar a compañías y/o negocios las ventajas y metodologías para el manejo de interacciones de comercio electrónico e incentivar su adopción. El proyecto plantea la creación de un Portal Transaccional para dinamizar la interacción comercial entre pequeños negocios, basado en tecnología de comercio electrónico. 5.1.4 Restricciones El primer gran reto al que es necesario enfrentarse está en que la gran mayoría de estas instituciones no tienen presencia en el mundo virtual de Internet, por lo que este trabajo ayuda a dar una luz sobre como empezar a usar la tecnología en campos donde todavía no existe. Dentro de los sistemas externos con que debe interactuar nuestro sistema esta el sistema financiero. Este estudio fue realizado por Roberto Arbelaez [ARBELAEZ R 2001], quién en su trabajo sobre el módulo de transacciones financieras para un portal cooperativo da como la mejor alternativa para el sistema de pagos el sistema de transición colombiano de quien dice “El sistema de transición colombiana es un mecanismo provisional aprobado por Credibanco Visa Colombia, y es plenamente funcional en el momento de elaboración de esta tesis. Este sistema permanecerá en funcionamiento mientras se implementa completamente el sistema SET en el país”. Mas adelante llega a la siguiente conclusión “Sin embargo es el método más eficiente (refiriéndose al sistema de transición colombiano) para efectuar transacciones electrónicas en línea, por lo que es el método recomendado para la implementación del módulo de transacciones electrónicas en línea, de un portal de comercio electrónico en Internet”.

MISC-02-2-13

43

5.1.5 Uso de internet en colombia En la divulgación del estudio TGI[TGI 2000] realizado en Colombia a finales del 2000 sobre el uso de la Internet. Este estudio se efectuó con base en entrevistas personales en varias ciudades del país (ver tabla 7). Tabla 7. Uso de Internet en Colombia.

Por Sexo Sexo TotalNal 1999 2000 hombres 46.90% 56.60% 63.60%

mujeres 53.10% 43.40% 36.40%

Por Estrato Estrato Total Nal 1999 2000 4 5 6 15.60% 33.20% 35.30%

3 45.70% 42.50% 44.80%

2 38.70% 24.40% 19.90%

[TGI 2000] 5.1.6 Ventas a traves de internet en Colombia y latinoamérica Las estadísticas presentadas por FENALCO1 en el año 2000, donde se observa un crecimiento anual en Colombia de mas del 100% en ventas hechas a través de Internet (ver Tabla 8) , este informe está basado en un estudio del IDC2[TGI 2001] Tabla 8. Comercio electrónico negocio a consumidor en millones de dólares.

Año AméricaLatina Colombia

1997 36 2.3

1998 167 7.7

1999 459 22.4

2000 1,059 56.2

2001 2,390 134.2

2002 4,649 269.8

2003 8,021 475.3 [TGI 2001]

1 Federación Nacional de Comerciantes de Colombia 2 http://www.idc.com

MISC-02-2-13

44

Así mismo en América Latina, Colombia ocupa el cuarto lugar (Tabla 9) después de Argentina, Brasil y Chile, en la cantidad de compradores virtuales, lo cual deja ver la inmensa capacidad, oportunidad y potencial, que representan estos mercados para la explotación y diversificación del comercio electrónico. Tabla 9. Navegantes compradores en América Latina en 1999.

País Navegantes Compradores

Argentina 9%

Brasil 17%

Chile 12%

Colombia 14%

México 15%

Venezuela 13%

Otros Países 13%

Total Región 16% IDC Latin America 1999 Internet and e-commerce strategies 5.1.7 Beneficios del proyecto Los beneficios del proyecto están expresados en la propuesta desarrollada por la Universidad de los Andes y son “El proyecto presentado tiene como fin mejorar la administración y competitividad de estas pequeñas y medianas empresas y de ofrecerles un nuevo canal para sus productos y servicios, basándose en cooperativas ya establecidas como de otras que pueden llegar a formarse, ingresándolas en el mundo del comercio electrónico a través de un portal de negocios, facilitando esta labor que antes por factor costos había sido casi prohibitivo para ellas por tratarse de empresas separadas. El proyecto reduce la pobreza a través de la consolidación de las empresas medianas y pequeñas, promoviendo la generación de empleo, que en Colombia constituye un aspecto importante, por cuanto los niveles de desocupación sobrepasan el 20%. De otra parte, la tecnología de punta proporciona ventaja competitiva a las empresas colombianas, por cuanto, a partir de una estructura centralizada pueden coordinarse cientos de proveedores y clientes.”

MISC-02-2-13

45

5.2 DESCRIPCIÓN DEL PORTAL COOPERATIVO. De acuerdo con su funcionamiento, el portal no es una extranet, pero tampoco proporciona acceso irrestricto a toda la información publicada. Esto significa que el conjunto de páginas Web que conforma el portal es de dos tipos: páginas de acceso libre y páginas de acceso restringido. La presencia de páginas de acceso libre es importante, ya que facilita la promoción del portal a través de la publicación de listas de asociados, clientes y artículos y servicios ofrecidos. 5.2.1 Participantes del servicio El funcionamiento del portal considera la existencia de usuarios (clientes y asociados), una cooperativa (que se encarga de coordinar y desarrollar todas las transacciones y procesos que se efectúen a través del portal) y las entidades financieras, que desempeñan un papel pasivo pero determinante en el éxito de las transacciones. Usuarios: Hacen parte de esta categoría clientes y asociados. Debido a que los requerimientos en cuanto a información y servicios de valor agregado difieran para cada uno, se plantea la necesidad de diseñar dos conjuntos de páginas Web (una para cada tipo de usuario). Cooperativa: Constituye el núcleo del servicio, y básicamente le competen dos actividades: administrar el sitio Web y coordinar las transacciones. Administrar el sitio Web hace referencia a la publicación y actualización de información relevante, mientras que la coordinación de transacciones se refiere al seguimiento de los pedidos realizados por los clientes. Esta actividad únicamente se termina cuando el cliente recibe la mercancía solicitada y el flujo de dinero entre clientes, cooperativas y asociados se ha realizado transparentemente, es decir, en las sumas establecidas y en el tiempo estipulado. Esta es la parte más compleja del servicio, por lo que su tratamiento se efectúa en una sección especial (ejecución de transacciones). Entidades Financieras: El servicio no se puede concebir sin considerar este tipo de participantes, ya que su funcionamiento implica el pago de productos. En términos generales, debe tenerse en cuenta la compatibilidad entre las entidades financieras de los clientes, cooperativa y asociados.

MISC-02-2-13

46

5.2.2 Descripción del funcionamiento del servicio La interfaz del servicio es el portal, a través del cual, mediante un conjunto de páginas Web, los usuarios (asociados y clientes) pueden vender y comprar productos. Debido a que posee dos tipos de información – pública y restringida – y a que las necesidades de clientes y usuarios son diferentes, se plantea el siguiente esquema: Figura 7. Funcionamiento del Servicio en el portal

. Para establecer los dos niveles en cuanto a la disponibilidad de información (para futuros usuarios potenciales y registrados) es necesario implementar el servicio de valor agregado Conexión para usuarios, que permite, a través de la asignación de un nombre y una contraseña, limitar el acceso a información clasificada, a los usuarios con los que la cooperativa ha entablado una relación comercial seria. Cuando el usuario ingresa al nivel dos de información tiene acceso a una serie de servicios tales como:

• Para asociados: Pronósticos de ventas, registro histórico de transacciones, cuentas por cobrar, cuentas por pagar

• Para clientes: catálogos de productos disponibles, solicitud de pedidos e historial de los mismos, cuentas por pagar.

De otra parte, común a clientes y asociados, se brinda el servicio de “motor de búsqueda”. Estos servicios se explican detalladamente en la sección servicios de valor agregado.

U S U A R I O S

SERVIDOR(ES) DE LA COOPERATIVA

I N F P O Ú R B M L A I C C I A Ó N

Clientes

Usuarios

MISC-02-2-13

47

5.2.2.1 Servicios de valor agregado Solicitud de ingreso: Este servicio se presta en el primer nivel de información. Es decir, a él pueden acceder todos los usuarios potenciales (clientes y asociados que deseen inscribirse al servicio). Su operación consiste en un vínculo, que dirija al cliente a diligenciar un formulario, que se envía al sistema de información de la cooperativa, donde se procesan las solicitudes, entablándose si es necesario, comunicación telefónica o personal entre los representantes de la cooperativa y el usuario (cliente o asociado) para que ambas partes cumplan los requisitos necesarios. Conexión para usuarios: Este servicio constituye la transición entre un sitio público (sin restricción alguna) y una extranet. Consiste en la solicitud de un nombre y una contraseña, que se proporciona a los usuarios que están inscritos en el servicio, para ofrecer información específica y privada (como pudiera ser el registro de transacciones realizadas). Es importante destacar que el direccionamiento de los clientes es diferente al de los asociados, ya que los difieren en sus necesidades. Registro Histórico de Transacciones: Se presta tanto a clientes como asociados. En el caso de clientes, se relaciona con el historial de pedidos, y en el de asociados con historial de ventas. Pronósticos de ventas Este servicio se relaciona directamente con los asociados. Es importante tener estadísticas en este sentido, ya que permite ajustar la producción de éstos de acuerdo con la variabilidad de la demanda en tiempo real. Buscador Este servicio consiste en la posibilidad de implementar un motor de búsqueda local, que estará disponible a todos los usuarios: clientes y asociados. Disponibilidad de productos (catálogo)

MISC-02-2-13

48

Este servicio se presta a los clientes y consiste en la presentación sistemática y organizada de los productos que se ofrecen (que los clientes pueden comprar). Esta presentación incluye precio y características técnicas. 5.2.2.2 Ejecución de transacciones La ejecución de transacciones se estudia separadamente del funcionamiento del portal, ya que constituye la parte más importante y delicada del aspecto operativo. Las transacciones que se ejecutan a través del portal son procesos de compra – venta, en los que la cooperativa “comunica” compradores (clientes) y vendedores (asociados). Para poder realizar un pedido, los clientes deben estar previamente registrados y emplear el servicio “conexión para usuarios”. Una vez se encuentran en el segundo nivel de información, pueden acceder al vínculo solicitud de pedido. Este vínculo dirige al cliente hacia una pantalla en la que aparecen varios cuadros combinados con la información de los productos necesarios. El pedido debe especificarse totalmente, no sólo en cuanto a las características del producto o productos deseados, sino también en lo referente a la forma de pago y tiempo de espera. El proceso de compra consta de varias etapas que se explican a continuación:

• Recepción del pedido: Esta etapa se refiere al correcto almacenamiento del pedido en el sistema de información de la cooperativa. De igual forma, se considera importante remitir una copia del pedido realizado al cliente respectivo, como manera de indicar el inicio del procesamiento de éste.

• Desagregación del pedido y envío de órdenes a los asociados: Esta etapa se

debe realizar, por cuanto puede darse el caso de que un pedido contenga artículos que deben encargarse a diferentes asociados. Básicamente consiste en clasificar los artículos solicitados por cada cliente, remitiendo a los asociados involucrados las respectivas órdenes.

• Verificación con las entidades financieras: Anterior a la entrega del pedido,

debe entablarse relación con las entidades financieras para realizar la transferencia electrónica de las cuentas de los clientes a las de los asociados y/o cooperativa.

• Actualización del portal: Algunos servicios tales como Cuentas por pagar,

cuentas por cobrar y pronósticos de ventas deben actualizarse de manera paralela al desarrollo de los procesos de compra venta. Es de esperarse que una vez se haya realizado la verificación ante las entidades financieras, se proceda a actualizar esta información en el portal.

MISC-02-2-13

49

• Agregación de los pedidos: Como resultado de la desagregación, puede darse el caso de que un asociado supla la demanda de varios clientes, por lo que se hace necesario programar la recolección de los artículos teniendo en cuenta la “reconstrucción” de cada pedido.

• Entrega de los pedidos: como resultado final del proceso de compra – venta,

debe emitirse un correo electrónico en el que se certifique el recibo de los pedidos por parte de los clientes. Sin embargo, la forma más práctica, aunque no electrónica, consiste en hacer firmar a un representante del cliente, en el momento de entregar el pedido.

El proceso de compra – venta, puede apreciarse en el siguiente esquema: Figura 8. Proceso de Compra – Venta.

1: Recepción de los pedidos 2: Envío de copia del pedido al cliente: forma de dar inicio formal a su procesamiento

.

.

COOPERATIVA

CLIENTES

ASOCIADO

1

ENTIDADES FINANCIERAS

1

2

3

ASOCIADO

2

ASOCIADO

n

3’

4 4’

6

Recolección de artículos

7

5

MISC-02-2-13

50

3 y 3’: Desagregación del pedido por asociado involucrado y envío de la solicitud respectiva 4 y 4’: Verificación con entidades financieras 5: Actualización del portal: pronósticos de ventas, cuentas por pagar, cuentas por cobrar 6: Agregación de los pedidos 7: Entrega de los artículos a los clientes y verificación de recibo de los mismos. 5.2.2.3 Logística de entrega. En este caso, el aspecto logístico está relacionado con el proceso de agregación de los pedidos previa a su entrega. Para que este aspecto se realice de forma eficiente y económica, debe contarse con un soporte informático robusto, a través del cual se tenga acceso a información real sobre los pedidos a entregar cada día. Sin embargo, para que el proceso minimice costos, debe considerarse el número de unidades distribuidoras (camiones), y su capacidad, para determinar el tamaño de lote óptimo (lot size). De esta manera, se tiene que la entrega de un pedido no está supeditada únicamente a que la entidad financiera autorice el flujo electrónico de dinero, sino también a que se presente una serie de pedidos que garanticen este tamaño de lote. De otra parte, la logística interviene activamente en el proceso de registrar clientes y asociados, ya que la inclusión de un nuevo usuario, implica necesariamente que la red de distribución va a aumentar en complejidad, por lo que puede darse el caso de clientes que por su ubicación no es conveniente su ingreso al servicio: así financieramente satisfagan las condiciones. 5.2.3 Casos de uso Dentro del ambiente del portal cooperativo es posible identificar cuatro actores importantes, los cuales son:

• Visitante o Cliente. • Asociado. • Administrador del Portal. • Administrador de la Cooperativa.

Para cada uno de estos usuarios se detectan una actividades que son consideradas fundamentales y las cuales se muestran a continuación. 5.2.3.1 Casos de Uso del Asociado. Las actividades más importantes del asociado están relacionadas con utilizar los servicios que son ofrecidos para el portal, para ellos como asociados, así como de manejar el catálogo de sus productos, y las promociones que se pueden hacer de los mismos. A continuación se puede apreciar cuales serían estas actividades.

MISC-02-2-13

51

Figura 9. Casos de Uso de Asociado

5.2.3.2 Casos de uso del Administrador de la Cooperativa. El Administrador de la Cooperativa es quien está encargado de desarrollar todas las actividades relacionados con todos los asociados, pues es quien coordina las funciones que ellos pueden llevar a cabo, al igual que manejar las políticas globales de la cooperativa. A continuación se muestra cuáles son estas actividades.

MISC-02-2-13

52

Figura 10. Casos de Uso de Administrador de Cooperativa

5.2.3.3 Casos de Uso del visitante o cliente. Las actividades que puede desarrollar una persona cuando ingresa un portal abarca aquellas que puede realizar cuando aún no se ha registrado ni ha adquirido algún producto o servicio, hasta el momento en que ya es cliente del portal. Estas actividades se muestran a continuación.

MISC-02-2-13

53

Figura 11. Casos de Uso de Visitantes

5.2.3.4 Casos de Uso del Administrador del Portal El administrador del portal, es quien está encargado del correcto funcionamiento de todo el sitio. Sus principales actividades se muestran a continuación.

MISC-02-2-13

54

Figura 12. Casos de Uso de Administrador del portal

MISC-02-2-13

55

6 DEFINICIÓN DE UNA FAMILIA DE ARQUITECTURAS PARA PORTALES COOPERATIVOS Y DE UNA METODOLOGÍA PARA SU DEFINICIÓN.

Dentro del trabajo llevado a cabo en la creación o selección de la arquitectura, no se limitó a encontrar “una arquitectura” que expresara, de manera absoluta la forma de construir un portal cooperativo. Así como en una construcción de un apartamento o una obra civil, existen diferentes planos que nos muestran diferentes formas de ver una misma estructura, igual sucede con la arquitectura de aplicaciones que serán utilizadas en el comercio electrónico. Como se mencionó en el marco teórico existen diferentes tipos de arquitecturas, ante estas múltiples opciones la pregunta que surge es cuál de ellas debe tenerse, porqué se debe aceptar o rechazar alguna de ellas?. Y un punto más crítico que el mencionado en el párrafo anterior es encontrar cómo hallar una metodología para construir una familia de arquitecturas para el caso de estudio que se menciona. Entre las propuestas halladas para llegar a plantear una arquitectura con base en unos requerimientos funcionales se encuentran entre otras las planteadas por:

• Philippe Krutchen [Krutchen 1995]. • Jan Bosch y Peter Molin [Bosch 1999]. • Bass-Clements [Bass 1998] • Shlaer Sally [Shlaer 1997]. 1

En estos tres enfoques se encuentran algunas dificultades como son: Enfoque Analiza la

Creación de Familias

Metodología sobre la creación de componentes.

Independencia del Hardware.

Independencia del Software.

Soporte ADL

Bass-Clements

NO NO SI SI SI

Krutchen NO NO NO NO NO Shlaer-Mellor

NO NO SI SI NO

Bosch NO NO SI SI NO 1 Ver Marco Teórico. Sección Arquitectura de Software-Metodología para Implementar una arquitectura.

MISC-02-2-13

56

Estas características que son necesarias, pero no están establecidas de una manera formal llevaron a que se planteara una metodología para la construcción de familias de portales, debido a esto fue necesaria plantear una metodología que cubriera esas falencias. En esta metodología se contemplan cinco pasos importantes como son.

• Definición del Estilo Organizacional del Software. • Estructura Modular del sistema, y modelo de datos parcial. • Definición de la familia. • Instanciamiento de la arquitectura. • Evaluación de la arquitectura.

A continuación se amplia cada uno de estos conceptos. 6.1 ESTILO ORGANIZACIONAL DEL SOFTWARE La era cliente-servidor y el desarrollo paralelo de aplicaciones ERP no resolvieron de una forma efectiva el problema de manejar apropiadamente enlaces externos con clientes y socios de negocios. Teniendo en cuenta las características de las aplicaciones de comercio electrónico, hoy en día se utilizan organizaciones como la que se sugiere para este caso de estudio, ver figura 13.

MISC-02-2-13

57

Figura 13. Estilo Organizacional del Portal

Dispositivos de acceso

Gateways de acceso (Websites, e-mail processor, IVRUs, EDI gateways, etc.

Middleware Aplicaciones y servicios orientados a las transacciones Repositorios de Datos e informacion Servicios de Agentes

sesiones orientadas a transaccion

sesiones de consulta

sesiones de comunicacion interactivas y no interactivas

6.2 ARQUITECTURA ESTRUCTURAL Dentro de la escogencia de la(s) arquitectura(s) la primera en ser tenida en cuenta después de establecer el estilo organizacional del software fue la estructura modular. Esta estructura permite un nivel de abstracción necesario, para manejar la planeación, localización de recursos y planeamiento, como realmente ocurrió en la elaboración de la propuesta elaborada por la Universidad de los Andes. Con este tipo de estructura es posible establecer de una forma sencilla, como puede estructurarse la arquitectura de acuerdo con las responsabilidades que pueden encontrarse en el portal. También puede ser posible cambiar la implementación de cada uno de los módulos sin preocuparse por la forma en que los demás módulos están implementados. Facilita la extensibilidad del sistema al permitir plantear módulos posteriores a los inicialmente establecidos. 6.2.1 Estructura modular Dentro de esta estructura Modular se plantean las siguientes estructuras que serían los módulos y los submódulos que estarían formando parte del portal. Ver fig. 14.

MISC-02-2-13

58

• Módulo de tienda virtual • Módulo de usuarios. • Módulo de catálogos. • Módulo de transacciones financieras. • Módulo de servicios. • Módulo de apoyo a las compras. • Módulo de búsquedas. • Módulo de pagos. • Módulo de logística. • Módulo de administración. • Módulo de apoyo a la bodega de datos. • Módulo de auditoria.

Figura 14. Estructura Modular.

BD Portal BD

Banca

Catálogos Transacciones Indicadores Clientes Socios Reglas

BBBD Soci

Catálogos

Tienda Virtual

Editor Catálogo

Man. Transacciones

Profiling

Socio

Client

Servicios

Mail Páginas Amarillas Noticias

Entidad Certificador

Mercadeo Personaliza

MISC-02-2-13

59

6.2.1.1 Módulo De Tienda Virtual El módulo de tienda virtual permite consultar la información asociada a los productos o servicios de cada empresa e interactúa con los otros módulos para poder realizar pedidos y pagos, recolecta la información, la envía y recibe la confirmación por parte del módulo correspondiente [Arbelaez J 2001]. El módulo de tienda virtual tiene los siguientes submódulos. SUBMODULO FUNCIONES Administración de clientes Mantener actualizada la información sobre un

socio o cliente. Permitir cambiar los datos del cliente. Capturar la información del cliente cuando compra por primera vez En caso que el usuario este registrado en nuestro portal, comprobar su identificación. Comprobar que los datos ingresados sean coherentes en las diferentes etapas de la compra.

Consulta de productos Ofrecer al usuario una interfaz para realizar búsqueda sobre los diferentes productos.

Carro de compras Permitir llevar una lista de los productos que el usuario desea. Permitir agregar un producto a esa lista. Permitir retirar un producto de esa lista. Permitir realizar la reserva de los productos que se deseen, para ser adquiridos posteriormente.

Compras Realizar el check out y enviar la información al modulo de pagos. Recibir la información del modulo de pagos sobre el estado de la transacción.

6.2.1.2 Módulo De Usuarios El módulo de clientes tiene como objeto administrar la información sobre un cliente o socio, mantener el registro de los clientes o socios con sus perfiles, preferencias y datos [Arbelaez J 2001]. SUBMODULOS FUNCIONES Administración de clientes Mantener actualizada la información sobre un

socio o cliente. Permitir cambiar los datos del cliente.

Registro de clientes Capturar la información del cliente cuando compra

MISC-02-2-13

60

por primera vez Validación En caso que el usuario este registrado en nuestro

portal, comprobar su identificación. Comprobar que los datos ingresados sean coherentes en las diferentes etapas de la compra.

Toma de datos Permitir a los usuarios dar información básica Ingreso de preferencias Permitir ingresar temas de interés posterior al

ingreso de la información básica Actualización de información Dar al usuario la oportunidad de actualizar la

información que considere conveniente 6.2.1.3 Módulo De Catálogos El módulo de catálogos (MACEC) busca permitir que una cooperativa pueda manejar el catálogo de los productos y servicios de todos sus asociados. Dentro del módulo de catálogos se ha trabajado en El Modelo de Publicación de Productos en Internet en un ambiente Cooperativo - MPPC, permite que una cooperativa logre realizar el catálogo de los productos y servicios de todos los Asociados existentes, de tal forma que los clientes puedan visualizarlo a través de un browser. [Florez 2002] SUBMÓDULOS FUNCIONES Modelo de Publicación de Productos en Internet en un ambiente Cooperativo –MPPC

Permitir que una cooperativa logre realizar el catálogo de los productos y servicios de todos los Asociados existentes, de tal forma que los clientes puedan visualizarlo a través de un browser.

6.2.1.4 Módulo De Transacciones Financieras El módulo de transacciones financieras que permite realizar la conexión del portal con los bancos o corporaciones para dar una respuesta sobre la solicitud de transacción que la ejecuta el módulo de clientes mencionado anteriormente [Arbelaez R 2001]. SUBMODULOS FUNCIONES Encriptación de la información Encriptar los datos recibidos del

modulo de pagos. Envío y Recibo de información Enviar información a través de una

conexión a la entidad bancaria.

MISC-02-2-13

61

Seguridad Generar llaves publicas y privadas, durante el proceso de autenticación.

6.2.1.5 Módulo De Servicios El módulo de servicios cuyo propósito es permitir realizar el manejo de comunicaciones entre los distintos usuarios de un portal cooperativo, y que a su vez se encuentran ubicados sobre la misma plataforma de red. [Trompetero 2001]. SUBMODULO FUNCIONES Envío de mensajes Enviar mensajes tipo texto a usuarios que

estén o no en línea. Administración de mensajes Dar la persistencia de los mensajes enviados

por un tiempo determinado. Correo electrónico Enviar y recibir correo electrónico. Administración de correo electrónico

Dar persistencia a los correos enviados y recibidos.

Envío de archivos Permite enviar y recibir archivos de usuarios que se encuentre en línea y acepten su envío.

Chat Poder establecer “conversación” con uno o más de sus contactos.

Noticias Enviar noticias a los usuarios, inscritos previamente en un tema especifico de noticias

Inscripción Registrar al usuario en alguno de los servicios prestados por el portal

Contactos Permitir a cada usuario administrar sus contactos a través de una estructura de grupos y contactos.

Soporte a usuarios Permitir a los usuarios establecer comunicación con el portal utilizando cualquiera de los submódulos que determine el usuario

6.2.1.6 Módulo De Apoyo A Las Compras El módulo del sistema multiagentes busca ofrecer una serie de herramientas que faciliten y apoyen los procesos de decisión, negociación y compra de los productos que se ofrecen en un portal electrónico, también busca formar parte activa de todo el proceso que involucra una compra de algún producto en este medio, desde el proceso de la identificación de una necesidad de compra, hasta la elección y negociación del producto que mejor se ajuste a los requerimientos solicitados. [Castellanos 2002].

MISC-02-2-13

62

SUBMODULO FUNCIONES Toma información Tomar información para poder

establecer grupos de usuarios Recomendaciones Presentar información sobre las

recomendaciones a los usuarios Negociación Establecer negociaciones entre el

usuario y los clientes. Creación de perfiles Establecer perfiles de acuerdo a la

información persistente 6.2.1.7 Módulo De Búsquedas El módulo de búsquedas tiene como objeto permitir realizar consultas de forma interactiva con el usuario sobre cualquier tópico que él desee. SUBMODULO FUNCIONES Búsqueda Permitir realizar la búsqueda sobre cualquier asunto

deseado. Refinamiento de búsqueda

Permitir realizar un refinamiento sobre una consulta inicialmente realizada

6.2.1.8 Módulo De Pagos El módulo de pagos es el encargado de servir de puente entre el módulo de compras y el módulo de transacciones financieras. Recibe la información del módulo de compras, captura su propia información, envía la información que el módulo de transacciones financieras y luego recibe una respuesta de este último. Luego de recibir la respuesta del módulo de transacciones financiera, él también envía una respuesta al módulo de compras. SUBMODULO FUNCIONES Envío de Información Enviar información al módulo de logística.

Enviar información al módulo de transacciones financieras.

Recepción de información Recibir información del módulo de transacciones financieras. Recibir información del módulo tienda virtual

Cancelación Compra Validar los datos para determinar si una compra puede realizarse o no, antes de enviar los datos al modulo de transacciones financieras

MISC-02-2-13

63

6.2.1.9 Modulo De Logística El módulo de logística permite controlar todo lo referente al envío de los productos y/o prestación de servicios que ofrece el portal. SUBMODULO FUNCIONES Selección de servicios Permitir al usuario escoger que tipo de servicio desea

utilizar para el envío de sus compras. Seguimiento envíos Permitir al usuario llevar un control sobre el estado de

su compra. Reclamos y/o sugerencias

Dar al usuario la oportunidad de realizar al usuario un reclamo y/o sugerencia

Cancelación pedido Permitir al usuario suspender un envío. 6.2.1.10 Módulo De Administración El módulo de administración, corresponde a la interfaz propia que se la va a brindar al administrador para manejar la información que se necesita para manejar los indicadores que más adelante se van a tratar. SUBMODULO FUNCIONES Módulo de Estadísticas

Entregar Información sobre la forma en que se esta utilizando el sitio. Dar consolidados sobre la forma en que se comporta el negocio.

Módulo de Administración

Administrar la estructura de la Base de Datos Administrar la actividad de los datos Administrar el Sistema Manejador de Base de Datos Establecer el Diccionario de Datos Asegurar la confiabilidad de la Base de Datos Confirmar la seguridad de la Base de Datos.

6.2.1.11 Módulo De Apoyo A La Bodega De Datos El modulo de apoyo a la bodega de datos, nos permite, manejar la información que será requerida por la bodega de datos. SUBMODULO FUNCIONES Toma de Información Toma de información desde el

sistema OLTP

MISC-02-2-13

64

Modulo de selección de información Pemitir hacer una estandarización de la información para ser utilizada en el submodulo de cargue.

Modulo de Cargue Permitir cargar los datos después de haber sido depurados

6.2.1.12 Modulo De Auditoría El módulo de auditoría nos va a permitir controlar todos los cambios que se efectúen en nuestro portal, también se llevará un control de las transacciones financieras que se lleven a cabo. SUBMODULO FUNCIONES Búsqueda Consultar información sobre cualquier ítem que se

desea Registrar actividades sobre los datos

Dar persistencia a los cambios que se llevan a cabo sobre cualquiera de los datos del portal

Registrar información sobre transacciones financieras

Dar persistencia al control llevado a cabo sobre los datos de las transacciones financieras.

6.3 PARÁMETROS DE FUNCIONAMIENTO. Cada uno de estos módulos maneja cierta información que es detallada en cada una de los trabajos realizado por los autores arriba referenciados, pero también hay información que es importante para el sitio, esa información que es importante para el sitio es mencionada a continuación, así como cuál módulo es el encargado de obtener esta información. Toda esta información va a ser importante en el momento de establecer indicadores que posteriormente se mencionarán. Dentro de los indicadores que se han considerado importantes para poder conocer cuál ha sido el funcionamiento del sitio están:

MISC-02-2-13

65

PARÁMETRO OBJETIVO INFORMACIÓN REQUERIDA

Fecha última visita del cliente

Conocer cuáles pueden ser las recomendaciones que se pueden ofrecer. En caso de no recibir la visita desde hace mucho tiempo se puede enviar promociones al correo, o dirección en caso de ser un cliente ya registrado.

Usuario Sesión

Número de visitas por período de tiempo para cada cliente

Gracias a este parámetro, al anterior y al que se menciona a continuación es posible conformar clusters que serán de gran utilidad (técnica de minería de datos).

Usuario Sesión

Valor en ventas por período de tiempo de cada cliente

Conocer la cantidad de compras en pesos de cada cliente, y poder ofrecer promociones de acuerdo con este comportamiento

Compras

Valor en ventas por asociado

Con este parámetro se puede determinar cuáles productos de cada asociado están teniendo mas aceptación, se podrá hacer una comparación entre las ventas realizadas a través del sitio y las ventas realizadas en la forma tradicional

Compras Productos Asociados

Valor en ventas por producto

Determinar que productos son rentables, cuáles están teniendo aceptación y se puede determinar el valor en ingresos por ventas a través del sitio.

Compras Productos

Relación entre ventas sin promoción y ventas con promoción

Determinar si las promociones tienen el efecto deseado. Determinar si las ventas aumentaron o si simplemente se paso de vender la misma cantidad de artículos pero a un precio menor. También es importante para determinar si a pesar que las ventas fueron similares, en cuanto al dinero recaudado, se logro ampliar el mercado pues fueron otros clientes los que utilizaron el sitio.

Compras Productos promoción

MISC-02-2-13

66

PARÁMETRO OBJETIVO INFORMACIÓN REQUERIDA

Numero de productos que los clientes han visitado por periodo de tiempo

Poder determinar que productos han sido revisados, que tan larga es la descripción de estos productos que fueron revisados, para determinar posibles grupos de artículos que por su facilidad de presentación son mas vistos, con este parámetro se puede entrar a mejorar parte de la interfaz con el usuario.

Sesión Páginas Producto

relación entre productos visitados y productos comprados

Que productos llegan a interesar al cliente, para así poder determinar perfiles de compras, y también determinar que productos tienen aceptación y cual puede ser la causa de su aceptación.

Sesión Páginas Productos Compras

Numero de páginas visitadas por un cliente nuevo antes de ordenar algo

Determinar qué tan eficientes son las interfases de usuario y cuál es el camino mas frecuente que lleva a un cliente nuevo a hacer una compra.

Usuario Sesión Páginas Productos

Numero de páginas visitadas por un cliente antiguo antes de comprar algo

Determinar si pueden llevarse a cabo mejoras en la forma de navegación de nuestros usuarios.

Usuario Sesión Páginas Productos

Numero de sesiones por periodo de tiempo en las que se ordena un producto y no se terminan exitosamente

Conocer cuál es la tasa de sesiones que terminan de forma exitosa y poder encontrar formas de mejorar este número en caso de no ser aceptable para el sitio.

Sesión Páginas Productos Compras Usuario Carro

Forma de Navegación en el sitio

Determinar qué tan apropiada es la interfase que se le ofrece a los usuarios y si es necesario cambiar la ubicación de las páginas, ya que por ejemplo los productos mas comprados no pueden estar “escondidos” detrás de una gran cantidad de páginas.

Sesión Páginas

MISC-02-2-13

67

PARÁMETRO OBJETIVO INFORMACIÓN REQUERIDA

Clasificación de los clientes de acuerdo con cuantos días ha pasado desde su ultima visita, cuantas veces ha estado el cliente en nuestro web-site, y cual ha sido el total de compras de cada cliente

Para este parámetro se utilizan los tres parámetros anteriores y se puede construir un cluster como el sugerido por Kimball [Kimball 2000]. De acuerdo a este cluster se determinan ocho grandes grupos de usuarios

•Grupo número Uno: conformado por aquellos clientes que visitan mucho nuestro sitio, compra mucho (en valor) y hace mucho no visita nuestro sitio. • Grupo número dos: Aquellos clientes que visitan mucho nuestro sitio compran mucho y hace poco visitaron nuestro sitio. • Grupo número tres: Aquellos que visitan mucho nuestro sitio, compran poco y hace poco visitaron nuestro sitio. • Grupo número cuatro: Aquellos que visitan mucho nuestro sitio, compran poco y visitaron nuestro sitio hace poco. • Grupo número cinco: Aquellos clientes que visitan poco nuestro sitio, pero compran mucho y hace poco visitaron el sitio. • Grupo número seis: aquellos clientes que visitan poco nuestro sitio, compran mucho, pero hace mucho tiempo no visitan nuestro sitio. • Grupo número siete: aquellos clientes que visitan poco nuestro sitio, compran mucho y hace poco visitaron el sitio. • Grupo número ocho: Aquellos clientes que visitan poco nuestro sitio, compran poco, y hace mucho no visitan el sitio.

En el caso de los clientes fue importante determinar una buena descripción demográfica pues sobre estos cluster se pueden entrar a aplicar alguna de las técnicas de minería de datos para determinar por que razón se están presentando estos comportamientos.

Usuario Sesión Compras Productos

MISC-02-2-13

68

PARÁMETRO OBJETIVO INFORMACIÓN REQUERIDA

Numero de contactos que solicita el cliente por periodo de tiempo

Poder armar una lista de F.A.Q (frecuently asked questions), que permitirán resolver las consultas mas frecuentas y ponerlas a disposición de los demás usuarios.

Sesión Contacto Medios Empleados Asociados

Motivo de contactos por periodo de tiempo

Determinar cuál o cuáles son los aspectos en que los clientes tienen mas dificultades, y poder establecer medidas correctivas, en esos ítem que los usuarios consultan.

Sesión Contacto Medio Empleados Asociados

Numero de visitas desde Ad u otros sitios

Poder determinar la efectividad de la publicidad que se está pautando en otros sitios.

Sesión Páginas

Tiempo que gasta el servidor para responder a una solicitud http

Determinar cuál es el comportamiento del servidor, en cuanto a respuesta a solicitudes de páginas por parte del navegador de los usuarios, de acuerdo a este número determinar si las páginas deben ser más livianas de contenido, pues un usuario no va a esperar mas de 10 segundos por una página web, al menos en 10 segundos se debe mostrar la información básica de la página, y después de esto si mejorar la calidad de los gráficos, tablas o demás información que pueda demorar la presentación de la página.

Sesión Páginas

Eventos que se llevan a cabo antes de una compra exitosa

Determinar que perfil de usuarios llevan a cabo compras exitosas y cómo es la forma que estos usuarios utilizan nuestro sitio, cual es su forma de desplazarse a través del sitio.

Usuario Sesión Páginas Productos Compras Carro

MISC-02-2-13

69

PARÁMETRO OBJETIVO INFORMACIÓN REQUERIDA

Eventos que se llevan a cabo en una venta cancelada, incompleta o sin éxito

Determinar qué perfil de usuarios llevaron a cabo compras que finalmente se cancelaron, o no fueron concluidas de una forma exitosa y como es la forma que estos usuarios utilizan nuestro sitio, cual es su forma de desplazarse a través del sitio, con este parámetro es posible entrar a determinar cuál es si fue una falla del sito, la cual llevó a esta cancelación, pues es importante ya que si la razón fue esta es necesario corregirla para no perder más compras y más clientes.

Usuario Sesión Páginas Productos Compras Carro

Eventos que se ejecutaron y terminaron en el abandono del portal

Determinar en que página el cliente abandonó el sitio, y que llevó a que lo hiciera, pues se puede determinar que su abandono, corresponde a una búsqueda que no arrojó ningún resultado, a un url mal direccionado.

Usuario Sesión Páginas Recomendaciones Búsqueda Palabras

Información que se mostró de forma incompleta pero se continuó en el portal

Determinar si la forma en que se está mostrando facilita, que no se tenga que esperar el cargue total de la página, o si nuestro usuario es un usuario que ya sabe exactamente lo que desea y dónde puede encontrarlo.

Sesión Páginas

Información que se mostró de forma incompleta y se abandonó el portal

Determinar, posibles causas de abandono del portal.

Sesión Páginas

Compras Rechazadas

Determinar las causas más frecuentes por las que las compras son rechazadas.

Compras Productos

Número de entradas a otros sitios desde nuestro portal

Cuál es la efectividad que tiene la publicidad de los diferentes sitios que tienen enlaces en nuestro sitio.

Sesión Páginas

MISC-02-2-13

70

PARÁMETRO OBJETIVO INFORMACIÓN REQUERIDA

Número de entrada desde las recomendaciones

Determinar la efectividad de los agentes de recomendación y si están cumpliendo su objetivo.

Usuario Recomendaciones Sesión Páginas

6.4 MODELO DE DATOS PARCIAL A continuación se describe parte de la información que se maneja en el portal cooperativo. Usuario. Identificación. Nombres. Apellidos. E-mail. Password. Sexo. Fecha

Nacimiento. Tipo de documento de identificación.

Documento de Identificación.

......

El campo de Identificación del usuario es importante pues de acuerdo con las recomendaciones de Kimball [Kimball 2000] los usuarios que visitan la web desean ser anónimos, van a mentir sobre su identidad si esta es solicitada, no se van a conectar siempre desde el mismo sitio, y no solamente se va a conectar una persona por equipo, sino por el contrario varias personas pueden utilizar el mismo equipo. En el momento en que la persona desee efectuar una compra en ese momento es cuando la información que se maneja se captura. Para poder manejar un perfil del futuro cliente, y de aquellos que ya han realizado compras se ha implementado un mecanismo que a pesar de no formar parte del estándar del protocolo http se ha adoptado universalmente: COOKIES. Los cookies buscan compensar la falta del concepto de sesiones en el protocolo http. Los cookies van a ser la primera forma de identificar un usuario que ingrese o retorne a nuestro sitio. El contenido de un cookie estándar está determinado por los siguientes valores: Nombre: Es una cadena cualquiera la cual dará nombre al cookie. Valor: En un valor que es almacenado en el cookie. Exp: Es la fecha en la cual el cookie expira. Dominio: Es el nombre del servidor de dominio que puede leer el cookie. Path: Es el camino en el dominio para el cual el cookie es valido. Seguridad: Especifica que la información debe ser transmitida vía SSL al servidor.

MISC-02-2-13

71

Por lo anterior es posible decir que la información de identificación es capturada por el sitio en la primera visita, y los demás campos, entre ellos los que se encuentran en la siguiente tabla, son obtenidos por el módulo de usuarios en el momento que ya el usuario desee registrarse. Usuario ... Direcciones Código Dirección Teléfono La siguiente información es capturada por el módulo de tienda virtual, en el momento en que el usuario ya a llevar a cabo una compra. Barrio Código Nombre .... Ciudad Código Nombre .... Profesión Código Nombre. .... Dentro de las políticas utilizadas en el módulo de tienda virtual [ARB 2001], está determinada que las compras deben pasar primero por el “carro de compras”, por tanto la información del carro de compras es suministrada por el módulo de tienda virtual. Carro Identificación Fecha de creación. Fecha de eliminación. Motivo. Estado. .... La información perteneciente a productos, categorías y asociados es tomada por el módulo de carga, de acuerdo con los archivos que llegan por parte de cada uno de los asociados. Estos archivos son el resultado del módulo MACEC el cual fue mencionado anteriormente. Productos Código Nombre Precio Garantía Referencia ...

MISC-02-2-13

72

Categorías Código Nombre .... Asociados Código Nombre Dirección Teléfono .... En este portal cooperativo también se manejaran promociones las cuáles serán manejadas por el módulo de tienda virtual. Dentro de esta categoría nos interesa tener la siguiente información. Promoción Código Nombre Fecha de Inicio Fecha de terminación. ... La información de las compras que se desean llevar a cabo es manejada por el módulo de tienda virtual. Este módulo no se encarga de los pagos, su responsabilidad llega hasta recolectar la información, enviarla y recibir la confirmación por parte del módulo de pagos, quien a su vez interactúa con el módulo de transacción financiera quien se encarga de la comunicación con los bancos y/o entidades financieras. Compras Código Total Impuesto .... Dentro de la identificación que se lleva a cabo de los usuarios, también es necesario establecer cada una de las formas en que el usuario interactúa con el sitio, y para esto es necesario establecer el concepto de sesión. Este concepto de sesión está ligado con la acción de ingreso y abandono de sitio por cada uno de los usuario. Sesión Identificación. Fecha Ingreso. Fecha Salida. Valor Cookie. Host. ...... Dentro de cada una de estas sesiones, en el sitio se manejaran diferentes formas por las cuales el usuario puede solicitar información sobre cualquier tópico que desee. Dentro de esas diferentes formas mencionadas están: IVR (Interactive Voice Response), procesamiento inteligente de e-mail, e-mail, llamadas telefónicas. Contacto Identificación Fecha ....

MISC-02-2-13

73

Empleados Código Nombre E-mail. ... Medio de Soporte Código Nombre .... Motivo Soporte Código Nombre .... Dentro de las páginas que van a formar parte del sitio nos interesa saber cuáles van a ser estas páginas, cuáles son las referencias que hace cada página en el servidor. Páginas Código Nombre Bytes ..... Referencias Código URL File path. ..... En el momento en que el módulo de tienda virtual ha enviado la información al módulo de pagos, y este a su vez ha utilizado de transacciones financieras, si el resultado de la actividad anterior es correcto, es decir, se pudo llevar a cabo con éxito, la compra como tal, esta información es enviada al módulo de logística para el envío del producto o servicio. Envíos Código Fecha Compra Fecha envío Fecha entrega ..... Políticas envío Código Nombre Tiempo Precio Garantía ..... Como pueden ocurrir errores en la entrega de los productos o estos no corresponden a lo solicitado por el usuario, también se contemplan los rechazos. Rechazos Código Fecha ..... Motivos de Rechazo Código Nombre .....

MISC-02-2-13

74

Compañías transportadoras Código Nombre ..... Gracias al módulo de sistemas multiagentes se pueden dar recomendaciones de compras a los usuarios, para esto es importante, almacenar esta información. Para darle persistencia a esta información se necesita la siguiente estructura: Recomendaciones Código Fecha Estado ..... También es importante manejar las búsquedas y guardar esta información. Búsqueda Código Fecha .... Palabras Código Descripción ..... Otro aspecto importante sobre el que se trabaja es la forma de llevar un control, una auditoría sobre los cambios que se llevan a cabo en el sitio. Para solucionar esto, sobre las tablas más importantes, se ha determinado utilizar triggers, para determinar cuál ha sido la fuente de esta información. Esta es una de las formas tradicionales en las cuales se puede plantear una arquitectura aunque hasta hace algún tiempo no se le diera el nombre de arquitectura, hasta este momento sólo se tiene un enfoque tradicional, pero el cual servirá para ver la gran diferencia que existe entre este enfoque y uno basado en un lenguaje de definición, con herramientas que lo soporten. 6.5 DEFINICION DE UNA FAMILIA DE PORTALES COOPERATIVOS Una arquitectura debe servir de puente, como se muestra en la figura número 15, entre los requerimientos y la implementación [Garlan2000]. El planteamiento tradicional visto no cumple estos objetivos pues se menciona una serie de módulos, pero el cómo debe ser la relación entre ellos, el cómo debe llevarse a cabo de la implementación está muy lejos de su alcance.

MISC-02-2-13

75

Figura 15. Conversión de requerimientos en código.

REQUERIMIENTOS

ARQUITECTURA DEL SOFTWARE

CODIGO

Uno de los procesos más difíciles es llevar a cabo fue el convertir esos requerimientos en una arquitectura que pudiera servir de puente para la conversión a código. Esta dificultad radica en que no existe una metodología que se adapte a los diferentes sistemas para los cuales se desea construir una arquitectura. Una de estas metodologías es planteada por [Bosch 1999] la cual se dirige exclusivamente a los requerimientos no funcionales del sistema, por lo que es necesario utilizar otros enfoques como el utilizado tradicionalmente en la arquitectura de software como es el caso de los casos de uso, y los diagramas de secuencia. Ante la inexistencia de una metodología que permitiera crear las familias de arquitecturas se plantea una que permita crearlas. Esta metodología contempla la utilización de cuatro pasos los cuales se ilustran a continuación.

MISC-02-2-13

76

6.5.1 Elaborar los diagramas de caso de uso. En este momento es necesario elaborar los diagramas de caso de uso, los cuáles ya están registrado en el capitulo anterior. 6.5.2 Establecer el contexto del sistema. En el contexto del sistema se definen las interfaces del sistema. Esta será la primera aproximación a la arquitectura del sistema. En este punto se estable los componente externos con los cuales tiene comunicación el sistema que se desea construir. Este contexto se muestra en la figura 16. Figura 16. Contexto del sistema.

Aunque sea considerado un paso tal vez un poco innecesario es un paso fundamental , ya que como señala Bosch [2000] las propiedades externas visibles de un sistema son lo que importa ya que todos los esfuerzos de los arquitectos de software son juzgados desde esa perspectiva, aunque es difícil mantener ese punto de vista ya que todos los esfuerzos son invertidos en la parte interna del sistema. El

MISC-02-2-13

77

papel del arquitecto de software es convertir los requerimientos de los interesados en utilizar el sistema en una arquitectura que facilita que esos requerimientos sean llevados a cabo. En el Anexo Numero 1 se encuentra la primera descripción de esta arquitectura en ADL. Los lenguajes de descripción de arquitectura surgieron como respuesta de los investigadores de la industria y de la academia a la informalidad que se presentaba en la definición de la arquitectura. Algunos ejemplos de ADL son:

• Adage permite la descripción de arquitecturas enfocadas a equipos de navegación aeronáutica. [Coglianese 1993]

• Aesop esta enfocado al uso de estilos de arquitectura. [Garlan 1994] • C2 soporta la descripción de sistemas en los cuales se describe la interacción

del usuario con el sistema utilizando la teoría orientada a eventos. [Medvidovic 1996]

• Darwin soporta el análisis de sistemas que utilizan el paso de mensajes en un ambiente distribuido. [Magee 1995]

• Meta-H da una guía para diseñadores de software de control aéreo. [Bins 1993] • Rapide permite que los diseños de arquitecturas sean simulados. [Luckham

1995] • SADL da una base para el refinamiento de la arquitectura. [Moriconi 1995] • UniCon tiene un compilador para diseños de arquitecturas que soporten una

mezcla de componentes heterogéneos y diferentes tipos de conectores. [Shaw 1995]

• Wright soporta la especificación forma y análisis de interacciones entre componentes de la arquitectura. [Allen 1997]

Ante estos enfoques tan diversos que dificultaban el paso de una arquitectura especificada en el lenguaje X a otra especificada en el lenguaje Y, surgió ACME el cual en un lenguaje de descripción de arquitecturas el cual es utilizado como un ADL neutral el cual es compatible con múltiples ADL [Garlan 1997], puede ser visto como el XML de la descripción de arquitecturas. Por esta razón la arquitectura del portal cooperativo fue desarrollada en ACMESTUDIO, el cual se basa en lenguaje de descripción de Arquitectura genérico ACME [ACMESTUDIO 2000]. 6.5.3 Construcción de los arquetipos. Se elabora una lista con estos casos de uso como se muestra a continuación. En esta lista se incluye la operación que se realiza sobre los datos, sobre la información que es considerada el factor más importante en el portal.

MISC-02-2-13

78

ACTOR CASO DE USO ACTIVIDADES OPERACIÓN SOBRE LA INFORMACION

Visitante Manejar Preferencias

Actualizar Base de datos Actualizar Consultar Insertar Eliminar

Visitante Administrar Carro de compras

Agregar Productos en el carro de compras Actualizar Base de datos

Agregar Modificar Eliminar Consultar

Administrador Cooperativa

Administrar Clientes

Agregar Cliente Actualizar Base de datos

Agregar Modificar Eliminar Consultar

Visitante Registrarse Incluir datos del usuario Actualizar Base de datos

Agregar

Visitante Manejar Preferencias

Incluir preferencias Actualizar Base de datos

Agregar Modificar Eliminar Buscar

Asociado Manejar Catálogo

Actualizar Base de datos Agregar Modificar Eliminar Buscar

Administrador Cooperativa

Manejar Plantillas

Actualizar Base de datos Agregar Modificar Eliminar Buscar

Administrador de Cooperativa

Manejar Plantillas

Actualizar Base de datos Agregar Modificar Eliminar Consultar

Administrador de la cooperativa

Manejar Taxonomías

Actualizar Base de datos Agregar Modificar Eliminar Consultar

Administrador Cooperativa

Administrar Publicidad

Actualizar Base de datos Agregar Modificar Eliminar Consultar

Administrador Cooperativa

Administrar Publicidad

Establecer enlaces a sitios asociados

Agregar Modificar

MISC-02-2-13

79

ACTOR CASO DE USO ACTIVIDADES OPERACIÓN SOBRE LA INFORMACION

Interna Eliminar Consultar

Administrador Cooperativa Asociados

Manejar Promociones

Actualizar Base de datos Agregar Modificar Eliminar Consultar

Visitante Modificar Registro

Actualizar Datos del visitante Actualizar Base de datos

Buscar Modificar

Sistema CrearPerfilesComportamiento

Crear los perfiles de acuerdo al comportamiento

Buscar Modificar Insertar

Visitante Consultar productos

Ver detalles de los productos Consultar base de datos

Consultar

Visitante Buscar Productos

Consulta en base de datos Visualización de la consulta

Consultar

Visitante Empresa transportadora

Tracear Pedido Consultar Base de datos Consultar

Administrador del portal

Generar Estadísticas

Crear y mostrar estadísticas Consultar Base de datos

Consultar Insertar

Visitante Comprar Inclusión en carro de compras

Insertar Actualizar

Sistema Manejar Comportamiento

Registrar movimientos del usuario Registrar comportamiento Actualizar Base de datos

Insertar Modificar

Administrador cooperativa

Registrar Asociados

Actualizar Base de datos Insertar

Administrador del portal

Registrar Administradores Cooperativa

Actualizar Base de datos Insertar

Asociado Incluir Productos

Actualizar Base de datos Insertar

Visitante Hacer Reclamos

Entablar un reclamo sobre un servicio prestado

Insertar

Visitante Hacer Capturar Sugerencias Insertar

MISC-02-2-13

80

ACTOR CASO DE USO ACTIVIDADES OPERACIÓN SOBRE LA INFORMACION

Asociados Sugerencias Insertar información Administrador Portal

Administrar Publicidad Externa

Guardar procedencia del enlace

Insertar

Visitante Asociados

Generar Información Auditoria

Actualizar Base de datos Insertar

Administrador Portal

Generar Logs Actualizar Base de datos Insertar

Administrador de Cooperativa, Empresa Transportadora

Manejar Políticas de Envío

Actualizar Base de datos Modificar Eliminar Buscar

Asociado Enviar Archivos

Manejar sus propios archivos, y los que desea enviar a los demás asociados

Servicio

Asociado Enviar Mensajes

Enviar Mensaje a otro Asociado

Servicio

Asociado Manejar Correo Electrónico

Realizar operaciones relacionadas con el correo electrónico

Servicio

Asociado Administrar Mensajes

Realizar operaciones relacionadas con el manejo de los propios mensajes del asociado así como con otros asociados

Servicio

Asociado Manejar Contactos

Manejar contactos propios de cada asociado

Servicio

Asociados Manejar Servicios

Utilizar Servicios dados por el administrador del portal

Servicios

Asociado Manejar Chat Establecer conexión con otro asociado

Servicios

Administrador Cooperativa

Enviar Noticias Establecer asociados o usuarios a enviarles noticias

Servicios

Administrador del portal

Crear Servicios

Establecer Servicios para los diferentes usuarios

Servicios

MISC-02-2-13

81

ACTOR CASO DE USO ACTIVIDADES OPERACIÓN SOBRE LA INFORMACION

Visitante Pagar Compras

Validar identificación

Transacción

El siguiente paso en la metodología es plantear los arquetipos, que son abstracciones del núcleo del problema. Estas abstracciones son los llamados arquetipos. Los arquetipos son diferentes de los subsistema, ya que estos últimos descomponen la funcionalidad en un gran número de partes, mientras que los arquetipos representan unidades abstractas que son funcionales y estables. Este es un proceso difícil ya que no existe una metodología que pueda ser utilizada en este asunto. En el proceso de descubrir los arquetipos se nota que no existe un mecanismo para hacerlo, en los diferentes trabajos dichos arquetipo simplemente “aparecen”. La propuesta realiza es en este paso del proceso integrar el enfoque dado en UML sobre los casos de uso y ver si existe una generalización dentro de estos casos de uso. Este es un mecanismo propuesto el cual nos lleva a detectar arquetipos no “sacados del sombrero” como ocurre en muchos de los trabajos realizados en desarrollo de la arquitectura en los cuales se encuentra que los arquetipos propuestos simplemente aparecen sin ningún proceso anterior y sin ningún fundamento sólido. Esta es una de los aportes interesantes en este trabajo ya que hasta este momento el proceso de detectar los arquetipos era un asunto ad-hoc, se sugiere darle un enfoque dependiendo del tipo de operación que se lleve a cabo. Gracias a este enfoque se detectan 3 grandes grupos como son.

• Actividades en las cuales se desarrollan transacciones. • Actividades que involucran manejo de información que puede estar residente

en una base de datos. • Actividades que involucran la utilización de servicios.

Dentro de ACME existen descripciones más detalladas, a más bajo nivel de los componentes llamados representaciones. Estas representaciones son utilizados en el proceso para lograr esta segunda aproximación como se muestra a continuación.

MISC-02-2-13

82

Figura 17. Componente de Transacciones

Figura 18. Componente de Servicios

MISC-02-2-13

83

Figura 19. Componente de Transacciones

Dentro de estos tres componentes se puede atrapar la complejidad del sitio de la cooperativa. Todo nuevo componente aparte de los ya considerados puede ser catalogado dentro de uno de estos tres componentes. Dentro del componente de manejo de información existen oportunidades en la cuales es necesario permitir sólo alguna de estas operaciones por este motivo es necesario considerar la operación de borrado como un componente diferente, la de consulta, la de inclusión y actualización dentro de otro como se muestra a continuación.

MISC-02-2-13

84

Figura 20. Componente de Inclusión.

MISC-02-2-13

85

Figura 21. Componente de Borrado

Figura 22. Componente de Consulta

En este punto se incluye una segunda mejora al proceso mediante el cual se construye una arquitectura pues se utilizan estos arquetipos para formar una familia que nos permita determinar las bases de cualquier portal cooperativo que ofrezca productos.

MISC-02-2-13

86

Figura 23. Familia Portal Cooperativo

Esta sería la definición de la familia llamada “portalcooperativo”. Esta familia está basada en los arquetipos que se mencionaron anteriormente. A su vez se encuentran nuevos elementos que no habían sido considerados anteriormente. Cuáles son estos nuevos componentes?. El componente que no había sido incluido anteriormente esta dado por el lugar donde se almacena la información que en este caso fue llamado almacenamiento_de_información. Esta familia fue construida con AcmeStudio. También fueron incluidos dentro de esta familia los conectores que nos permitirán lograr la comunicación entre estos componentes. Los conectores declarados son:

• Consulta_información. • Conexión_al_front_end. • Conexión_a_modulos.

MISC-02-2-13

87

• Borrado_información. • Insercion_y_Actualizacion_información • Respuesta de información.

Dentro de cada uno de estos componentes y conectores fueron establecidas algunas propiedades, para una mayor claridad la descripción se realizará utilizando el ADL de Acme (Ver anexo 2). Dentro del lenguaje de definición de arquitectura para cada uno de los componentes fueron declarados algunas propiedades, una de las falencias es que todavía no existe una metodología que nos permita nombrar cada una de estas propiedades, pero si después de tantos años no existe un estándar para nombrar los atributos de una tabla en una base de datos, sería normal pensar que es un proceso difícil de llevar a cabo y más aun en una forma de pensar que lleva poco tiempo utilizándose. Con base en esta familia se puede declarar cualquier operación que se lleve a cabo en el portal cooperativo. 6.6 INSTANCIA DE LA FAMILIA En este punto se particulariza sobre el caso de estudio en particular. El hecho de tener la familia ya definida, permite que si se quisiera realizar para diferentes portales cooperativos no sería necesario realizar los tres pasos anteriores, este sería el punto de partida, gracias a que ya se tiene una definición de los componentes, conectores, propiedades y demás atributos propios de la familia. Para llevar a cabo esta instancia de la familia, es necesario llevar a cabo los siguientes pasos. 6.6.1 Escoger casos de uso. Un ejemplo sobre como se lleva a cabo este proceso se muestra a continuación. Se toma uno de los Casos de Uso.

MISC-02-2-13

88

Figura 24. Caso de uso.

Visitantes Conectarse

Solicita Conexion

El caso de uso mostrado es del visitante quien realiza una conexión al portal. 6.6.2 Tomar diagramas de secuencia. Se elige una operación que se lleva a cabo dentro del portal cooperativo, como es aquella cuando un visitante llega al mismo. Se toma esta operación para plantear cual seria la operación en ADL, y cómo se convierte esta arquitectura en un verdadero puente al código como se planteó anteriormente. Se plantea cual es el diagrama de secuencias, el cual se muestra a continuación:

MISC-02-2-13

89

Figura 25. Diagrama de secuencia.

En este diagrama de secuencia se pueden encontrar ocho elementos como son el portal, usuarios, recomendaciones, perfiles de comportamiento, preferencias de usuarios, catálogos, productos y plantillas. Ahora esta secuencia se expresa con base en los componentes de la familia portal cooperativo.

MISC-02-2-13

90

Figura 26. Caso de uso en ADL .

En el anexo 3 se muestra este suceso en ADL y después se da una explicación del mismo. Vale la pena resaltar que esto no es código, no es software, es la descripción de cómo se debe llevar a cabo esta operación, en un lenguaje formal como es ADL. A continuación se analiza la parte concerniente a las recomendaciones, para explicar un poco mejor como es la descripción en este lenguaje. Primero está un componente llamado recomendaciones.

1. Component recomendaciones : Consultas = new Consultas extended with { 2. Properties {

a. resultado_operacion : boolean;

MISC-02-2-13

91

b. tiempo_de_respuestas : float; c. numero_maximo_de_registros_retornados : int; d. visualizacion_directa : boolean; e. dejar_log : boolean; f. sentencia : string = ""; g. tipo_de_consulta : string = ""; h. metodo_utilizado : string = ""; i. nombre_fuente : string = ""; j. tipo_de_fuente : string = ""; k. valor_retornado_por_registro : string = "";

3. }; 4. Port p = {

a. Properties { b. };

5. }; 6. Port p1 = {

a. Properties { b. };

7. }; 8. Port p2 = {

a. Properties { b. };

9. }; 10.};

Este componente llamado recomendaciones pertenece a la familia portalcoperativo, y es una instancia del componente consultas, como se aprecia en la línea 1. En la línea 2 se pueden ver las propiedades propias del componente que se declaró en la familia, la diferencia importante radica en que como es una instancia de ese componente las propiedades, las cuales haciendo una analogía con la teoría de objetos, pueden compararse con los atributos, toma unos valores para estas propiedades como se muestra en los incisos del a hasta la k de este línea 2. A continuación se explican dos conectores que están unidos a este componente, los componentes seleccionados para esto se declaran a continuación.

1. Connector consigue_recomendaciones : Consulta_informacion = new Consulta_informacion extended with {

2. Properties { a. fuente_de_datos : string = "base de datos"; b. existen_parametros : string = "true"; c. numero_de_parametros : string = "1"; d. parametros : string = "identificacion usuario";

MISC-02-2-13

92

e. valor_de_los_parametros : string = ""; 3. }; 4. Role Viene_de = {

a. Properties { b. };

5. }; 6. Role va_a = {

a. Properties { b. };

7. }; 8. };

En este primer conector llamado consigue recomendaciones pertenece al componente Consulta_información de la familia ya mencionada. Al igual que el componente anterior existen unas propiedades que en este momento toman un valor determinado, tal como se muestra en los incisos de la a hasta la e de la línea 2.

a. fuente_de_datos : string = "base de datos"; b. existen_parametros : string = "true"; c. numero_de_parametros : string = "1"; d. parametros : string = "identificacion usuario"; e. valor_de_los_parametros : string = "";

La fuente de datos de la cual se va a extraer la información es una base de datos. Se determina que si existen parámetros que se van a enviar, por eso este atributo existen_parámetros es verdadero. El tipo debería ser booleano pero existe un problema en AcmeStudio con los valores boléanos, al asignarle un valor debería ser true o false, pero no permite la asignación de estos valores, pues genera una excepción que ocasiona que el programa termine abruptamente, por esta razón todos los tipos son tratados como string. La cantidad de parámetros es uno, y el parámetro que se va a pasar es la identificación del usuario. El segundo conector llamado devuelve_recomendaciones.

1) Connector devuelve_recomendaciones : Respuesta_consulta = new Respuesta_consulta extended with {

2) Properties { a. fuente_de_datos : string = "base de datos"; b. devuelve_valores : string = "true";

MISC-02-2-13

93

c. numero_de_valores_de_retorno : string = ""; d. valores_de_retorno : string = ""; e. retornos : string = "";

3) }; 4) Role viene_de_bd = {

a. Properties { b. };

5) }; 6) Role va_a = {

a. Properties { b. };

7) }; 8) };

En este conector al igual que el conector pasado y el componente pasado es del tipo Respuesta_consulta

a. fuente_de_datos : string = "base de datos"; b. devuelve_valores : string = "true"; c. numero_de_valores_de_retorno : string = ""; d. valores_de_retorno : string = ""; e. retornos : string = "";

Acá también se aprecia que la fuente de datos es una base de datos, que debe devolver un valor no existe un numero máximo de valores de retorno. Si se establece como política de la cooperativa que existe un máximo de valores de retorno, esto se vería reflejado en este campo.

MISC-02-2-13

94

7 IMPLEMENTACIÓN DE UN PROTOTIPO Dentro de la implementación del sistema basada en la arquitectura propuesta fueron varias las opciones analizadas como fueron: En los gateways de acceso fue tomada como punto inicial del proyecto los web servers, que le van permitir a los usuarios acceder las paginas del sitio por medio de sus navegadores. Dentro de los servidores web las opciones más populares en el mercado son: Apache, Microsoft, iPlanet, NCSA. Dentro de estas opciones la de mayor aceptación es Apache, como se señala en el marco teórico. Dentro de las opciones de middleware la opción seleccionada fue el oracle9ias que ofrece una infraestructura que incluye: Plataforma completa de J2EE. Desarrollo en Java, Perl, PL/SQL, XML, Forms. Oracle Portal. Wireless. Cache. Manejo de actividad del sitio. La base de datos seleccionada fue Oracle8i. Esta decisión fue tomada teniendo en cuenta la posibilidad de reutilización de código que es una de las características interesantes de esta herramienta, pues debido al desarrollo de un concepto llamado portlets, estos pueden ser utilizados por cualquier usuario que tenga el perfil de administrador. Sin embargo se debe resaltar que de las herramientas ofrecidas por el oracle aplication server solamente se utilizo una de ellas que fue el Oracle Portal. La escogencia de esta herramienta también ofrecía la posibilidad de combinar la potencia de los procedimientos almacenados de oracle ya que pueden ser llamados desde los portlets. También permite la integración con el lenguaje html. El primer punto es ver cómo el componente recomendaciones se convierte en una página dinámica por eso es su propiedad nombre_fuente está registrado el D3. D3 es el nombre que se le dió a esta página dinámica que construye las recomendaciones. El conector que enlaza al componente front_end con el

MISC-02-2-13

95

componente recomendaciones es el llamado a una dirección http como se puede apreciar en la propiedad mencionada. href="SCOTT.D3.show?p_arg_names=_title&p_arg_values=D3" Si no se hubiera utilizado oracle portal el cual se dan direcciones relativas, una de las diferencias que se presentaría es la forma en la cual serían expresadas estas propiedades, pero es bueno resaltar que lo importante no es la implementación, es la definición de la arquitectura, que es quién facilita la construcción y la codificación. El siguiente componente recomendaciones

1. Component recomendaciones : Consultas = new Consultas extended with { 2. Properties {

a. resultado_operacion : boolean; b. tiempo_de_respuestas : float; c. numero_maximo_de_registros_retornados : int; d. visualizacion_directa : string = "TRUE"; e. dejar_log : string = "true"; f. sentencia : string =

"href=\"SCOTT.D3.show?p_arg_names=_title&p_arg_values=D3\""; g. tipo_de_consulta : string = "DINAMICA"; h. metodo_utilizado : string = "pagina dinamica"; i. nombre_fuente : string = "D3"; j. tipo_de_fuente : string = "BASE DE DATOS"; k. valor_retornado_por_registro : string = "";

3. }; 4. Port p = {

a. Properties { 1. };

5. }; 6. Port p1 = {

a. Properties { 1. };

7. }; 8. Port p2 = {

a. Properties { 1. };

9. }; 10.};

En este momento cada una de estas propiedades toma un valor especifico como se muestra a continuación.

MISC-02-2-13

96

resultado_operacion : boolean; El resultado de la operación, en este momento no tiene ningún valor. tiempo_de_respuestas : float; El tiempo de respuestas. Debe tener un valor en el momento en que se implemente cual debe ser el tiempo máximo de respuesta para ver sus recomendaciones. numero_maximo_de_registros_retornados : int; Si de acuerdo nuevamente a las políticas se determina cual debe ser el máximo numero de registros que se deben retornar. Por el momento no hay limites por eso no tiene visualizacion_directa : string = "TRUE"; Esta visualización directa nos permite saber que el componente tendra la capacidad de mostrar directamente los resultados una vez obtenida la consulta. dejar_log : string = "true"; Esta propiedad determina que la operación de consulta debe dejar un registra en la base de datos. sentencia : string = "href=\"SCOTT.D3.show?p_arg_names=_title&p_arg_values=D3\""; La sentencia nos indica la forma en la cual debe ser llamada la página dinámica dentro del oracle portal. Esto es propia de cada forma de implementación . tipo_de_consulta : string = "DINAMICA"; Es una consulta de tipo Dinámica pues se arma de acuerdo a las preferencias, al perfil de comportamiento y a la identificación del usuario. metodo_utilizado : string = "pagina dinamica"; Se utilizo una pagina web dinámica. nombre_fuente : string = "D3"; El nombre donde se encuentra la aplicación es D3.

MISC-02-2-13

97

tipo_de_fuente : string = "BASE DE DATOS"; De donde serán extraidos los datos es una base de datos. valor_retornado_por_registro : string = ""; No está limitado que tipos de datos debe retornar. Los siguientes elementos a analizar serian el conector que permite retornar los datos de la base de datos, y el conector que permite regresarlos. La forma cómo se instancian los componentes sucede de la misma forma que la mostrada en el componente anterior. Esta descripción nos sirve para ver que es posible convertir este lenguaje en código, como se muestra a continuación. El componente FrontEnd sería la página que está visualizando el usuario, en este caso una pagina web. En la descripción (lo que esta señalado con rojo) se puede ver que el componente usuario esta conectado con el frontend. Desde el frontend se hace un llamado al componente usuario, como la herramienta que se escogió (la cual como se menciono anteriormente es independiente de la arquitectura) fue Oracle Portal desde la página se utiliza el siguiente comando scott.lee_galleta('cookie_name29'); el cual es el llamado que se hace al componente usuarios que conoce la funcion lee_galleta. Esta función lee_galleta pertenece al componente usuario y se muestra continuación create or replace function lee_galleta(galleta in varchar2) return integer as valor integer; read_cookie_value owa_cookie.cookie; l_domain varchar2(2000); begin read_cookie_value:=owa_cookie.get(galleta); valor:=read_cookie_value.vals(1); return valor; end; /

MISC-02-2-13

98

Esta es una función que devuelve un valor, el cual en el lenguaje de descripción de arquitectura está representada por la segunda conexión que existe entre el componente usuarios y frontend. Con esto se utiliza la arquitectura como un verdadero puente y un aporte de este trabajo es dejar las bases para que en ellas se pueda construir un portal cooperativo, independiente del lenguaje y sirva de estructura del mismo. Sin embargo se nota que falta una mejor documentación de las propiedades, ya que la herramienta no ofrece esta posibilidad, pues es decisión del arquitecto de software utilizar el nombre que quiera darle a la propiedad pero queda el vacío, que no exista forma que otra persona revise esta arquitectura e interprete exactamente que quería dar a entender quien las definió. 7.1 EVALUACIÓN DE LA ARQUITECTURA La evaluación de la arquitectura es todavía un campo en el cual falta mucha investigación y metodologías para llevarla a cabo, esto es comprensible debido a que si en la definición e implementación existen muchas vertientes es aun más difícil encontrar la forma de evaluar cualquier arquitectura de software. En este punto es bueno resaltar la siguiente frase “La evaluación de una arquitectura, no nos dice si o no, bueno o malo, o 6.75 sobre 10 solamente nos dice donde se tienen riesgos” [CLEMENTS 2002]. En ese mismo trabajo nos sugiere como forma de evaluar una arquitectura analizar si se tuvieron en cuenta los siguientes aspectos. Rendimiento. El rendimiento se refleja en las propiedades como tiempo de respuesta, número máximo de registros que debe retornar. Confiabilidad y Disponibilidad. La arquitectura propuesta presenta fallas en este sentido pues no se elaboraron estrategias para prever casos como la caída de la base de datos, no se tuvieron en cuenta planes de emergencia. Seguridad. Existen propiedades que determinan qué tipo de usuario puede realizar que operación así como existe unos componentes propios para cada tipo de usuario. Así como existen propiedad que garantizar dejar logs de las actividades que se lleven a cabo. Portabilidad y Variabilidad. Las componentes fueron pensados de una forma lo suficiente general de forma tal que no estén enlazados a una herramienta en

MISC-02-2-13

99

particular sino que sea posible desarrollar la implementación en cualquier herramienta. Producción de subconjuntos. Los componentes dan la facilidad de plantear portales que sean un subconjunto, pues se puede construir un portal que solamente permita la exhibición de productos, sin permitir ventas o cosas por el estilo. En términos generales la arquitectura cumple con los parámetros a observar, hay una falla en la parte de confiabilidad y disponibilidad que debió haberse tenido en cuenta.

MISC-02-2-13

100

8 CONCLUSIONES Y TRABAJO FUTURO Este proyecto propone una arquitectura para portales cooperativos, el cual puede extenderse para cualquier portal que ofrezca productos a un grupo de clientes. En la investigación sobre como plantear una arquitectura, las opciones encontradas son muy variadas, pero todas ellas coinciden en que una arquitectura es una descripción global de la organización del sistema. Los avances que se han tenido en la definición de arquitecturas de sistemas han sido diversos, pero su a su vez un poco dispersos, pues hasta hace muy poco cada universidad, centro de investigación o empresa desarrollo sus avances de una forma aislada hoy en dia se ha tratado de unificar algunas cosas, entre ellas el Lenguaje de descripción de arquitectura ADL, y ACME ha sido creado en este sentido. Existen muchos procesos dentro de la construcción de arquitecturas que aun son un poco imprecisos o dependen en un gran porcentaje de lo que el arquitecto de software considera, en este trabajo se busca darle un poco mas de formalidad y se propone integrar procesos llevados a cabo en la metodología de lenguaje unificado de modelado (UML), lo cual es una innovación en el mismo. Con esta integración se busca que conceptos como casos de uso y diagrama de secuencias formen parte del proceso mediante el cual se llegan a crear arquitecturas de software. Se quiso plantear dos vistas diferentes de la arquitectura. Un estilo organizacional y una arquitectura estructural. También se llevo a plantear formalmente mediante el uso de un lenguaje de definición de arquitectura (ADL). Este planteamiento es importante para determinar cómo será la interacción entre los diferentes componentes del sistema. El hecho de haber escogió oracle9ias y Oracle portal el cual permitió llevar a cabo el prototipo para el desarrollo del portal, es independiente de la arquitectura planteada, pues como se mencionó en el capitulo dos, la arquitectura debe ser independiente de la implementación. Aunque los progresos que se han tenido han sido muy grandes en la definición de arquitecturas todavía es un tema que se encuentra en evolución y el cual se está mejorando, aun hay aspectos que pueden ser considerados falencias dentro del mismo, como es el caso de desligar complementa de la implementación, hoy en día las herramientas de desarrollo, pueden llegar a forzar una forma de desarrollo que no fue considerada en la arquitectura o a la vez permitir un manejo muy sencillo de la misma. La arquitectura puede ser un puente efectivo entre los requerimientos y la codificación como se mostró anteriormente, a su vez esto permitirá darle un mejor

MISC-02-2-13

101

mantenimiento a la aplicación pues se tiene conciencia de cómo es la relación entre los componentes, cual es el llamado, el tipo de llamado, los parámetros, en fin todos los factores que están involucrados en la construcción de una aplicación web. Esto facilitará su mantenimiento, su adaptabilidad pues al instanciar cada propiedad, se estará haciendo una descripción general del funcionamiento propio de cada portal cooperativo, sin embargo en este mismo proceso de determinar cuáles son las propiedades, es necesario tener un amplio conocimiento de las diferentes alternativas que se pueden presentar, y que muchas veces dependen de las herramientas de desarrollo, este es un aspecto que aunque de cierto modo va en contra de la teoria es una realidad que no debe dejarse a un lado. Como trabajo futuro, podría plantearse la arquitectura en el lenguaje ADML, que es un lenguaje para definición de arquitecturas basado en XML. Se puede avanzar en las aplicaciones de acceso e implementar en el prototipo un acceso a través de los teléfonos móviles, y el uso de J2EE en la parte de implementación.

MISC-02-2-13

102

BIBLIOGRAFIA [ACME] The Acme Architectural Description Language. http://www-2.cs.cmu.edu/~acme/ . Fecha Ultima visita Diciembre 2002. [ACMESTUDIO 2000] Kompanek Andrew, Schmerl Bradley. Scholl of Cumputer Science. Carnegie Mellon University. [ACMESTUDIO].AcmeStudio. A Graphical Design Environment for Acme. http://www-2.cs.cmu.edu/~acme/AcmeStudio/index.html. Fecha ultima visita Diciembre 2002. [Allen 1997] Allen, R. Garlan D. A formal basis for architectural connection. ACM transactions on Software Engineering and Methodology, July 1997. [ANSI/IEEE 2000]. IEEE Recommended Practice for Architectural Description of Software-Intensive Systems (IEEE Std 1471). [Arbelaez J 2001]. ARBELAEZ JOSE FERNANDO. Documento de Análisis de Requerimientos y Diseño de Alto Nivel para el Modulo de Tienda Virtual y Cliente de un Portal Transaccional para Pequeños Negocios. Universidad de los Andes. Bogota Colombia. 2001. [Arbelaez R 2001] Arbelaez Roberto. Módulo de transacciones electrónicas para un portal de comercio electrónico. Universidad de los Andes. Bogotá Colombia 2001. [Bass 1998]. Bass Len, Clements Paul Y Kazman Rick. Software Architecture in Practice. Adisson Wesley. [Binns 1993]. Binns P, Vestal S. Formal real-time architecture specification and analysis. 10th IEEE Workshop on Real-Time Operating Systems and Software. [Bosch 2000]. Bosch Jan. Design et Use of Software Architecures. Addison-Wesley Pub Co. Mayo 2000. [Bradshaw.1999] Software Agents, Jeffrey M. Bradshaw.1999 [Bravo 2001]. Bravo German, Caicedo Carlos, García Alberto, Rueda Francisco. Propuesta de desarrollo de un portal cooperativo. Universidad de los Andes. 2001.

MISC-02-2-13

103

[Castellanos 2002]. Castellanos Sandra. Modelo de un Sistema Multiagentes de apoyo al Comercio Electrónico. Universidad de los Andes. Bogotá Colombia 2001. [Clements 2002]. Clements Paul, Kazman Rick, Klein Mark. Evaluating Software Architectures. Carnegie Mellon. Software Engineering Institute. Addison-Wesley 2002. [Clements 2002a]. Clements Paul, Northrop Linda. Software Product Lines. Addison-Wesley 2002. [Coglianese 1993]. Coglilanese L, Szymanski R. DSSA-ADAGE: An Environment for Architecture-based Avionecs Development. In Proceedings of AGARD’93, May 1993. [Florez 2001] Florez Angélica. Modelo de Publicación de Productos en Internet en un ambiente Cooperativo. Universidad de los Andes, 2001. [Garlan 1994]. Garlan D, Allen R, Ockerbloom R. Exploiting style in architectural design environments. In Proc of SIGSOFT’94. The second ACM SIGSOFT Symposium on the Foundations of Software Engineering. ACM Press, December 1994. [Garlan 1995]. Garlan, David. Proceedings of the First International Workshop on Architectures for Software Systems, Seattle, WA, April 1995. [Garlan 1997]. Garlan David. Monroe Robert, Wile David. ACME An Architecture Description Interchange Language. January 1997. [Garlan 2000] Garlan, D., Monroe Robert, Wile David. ACME. Architectural Description de Component-Based Systems. Computer Science Department. Carnegie Mellon University y USC /Inf. Sciences Institute. Enero de 1997. [Garlan 2000]. Garlan David. Software Architecture: a Roadmap. "The Future of Software Engineering" , Anthony Finkelstein (Ed.), ACM Press 2000 [Garlan 1994] Garlan, D., Allen, R., y Ocerbloon, J. Exploiting style in architectural design environments. The Second ACM SIGSOFT Symposium on the Foundation of Software Engineering. ACM Press, Diciembre 1994. [Garlan 1995] Garlan, D. First International Workshop on Architectures for Software Systems. Abril 1995.

MISC-02-2-13

104

[Garlan 1997] Garlan, D., Monroe Robert, Wile David. ACME. Architecture Description Interchange Language. Computer Science Department. Carnegie Mellon University y USC /Inf. Sciences Institute. Enero de 1997. [Kaplan 2000]. Kaplan Steven, Mohanbir Sawhney. E-Hubs: The New B2B marketplaces. Harvard Business Review. May-June 2000. [Kimball 2000] Kimball Ralph, Richard Merz. The Data Webhouse Toolkit.John Wiley & Sons. USA 2000. [Krutchen 1995]. Kruchten Philippe. The 4+1 view model of architecture. IEEE Software, pages 42-50. November 1995. [Luckhan 1995]. Luckhan D, Augustin L, Kenny J, Veera J, Bryan D, Mann W. Specification and analysis of system architecture using Rapide. IEEE Transactions on Software Enginnering. April 1995. [Magee 1995]. Magee J, Dulay N, Eisenbach S, Kramer J. Specifying distributed software architectures. In Proceedings of the Fifth European Software Engineering Conference, ESEC’95, September 1995. [Medvidovic 1996]. Medvidovic N, Oreizy P, Robbins J, Taylor R. Using object-orinted typing to support architectural design in the C2 style. In SIGSOFT’96: Proceedings of the 4th ACM Symposium on the Foundations of Software Engineering. ACM Press. Oct 1996. [Medvidovic 1997]. Medvidovic, N. Oreizy, P., Robbins, J.E., and Taylor, R.N. Using object-oriented typing to support architectural design in the C2 style. In SIGSOFT’96 : Proceedings of the Fourth ACM Symposium on the foundations of software Engineering. ACM Press, October 1996. [Monroe 1998] Monroe R. Capturing Software Architecture Design Expertise with Armani. Technical Report, CMU-CS. [Moriconi 1995]. Moriconi M, Qian X, Riemenschneider R. Correct architecture refinement. IEEE Transactions on Software Engineering, Special Issue on Software Architecture, April 1995. [NETCRAFT 2002] Netcraft Web Server Survey. http://www.netcraft.com/Survey/ Fecha ultima visita Julio de 2002. [Rajput 2000]. Rajput, Wasim E. E-Commerce Systems Architecture and Applications. Artech House telecommunications library. 2000.

MISC-02-2-13

105

[Rapid 96] Rapide Design Team. Rapide 1.0 Language Reference Manual Program Analysis and Verification Group, Computer Systems Lab, Stanford University, Enero 1996. [Shaw 1995]. Shaw M, DeLine R, Klein V, Ross T, Young D. Zelesnick G. Abstractions for software architecture and tools to support them. IEEE trans on Software Engineering. April 1995. [Shaw 1995]. Shaw Mary. Architectural Issues in Software Reuse. It’s not just the funclitionality. It’s the packing, in Proceedings of the Symposium on Software Reusability SSR’95, Software Engineering Notes, Special Issue, ACM Press, 1995. [Shaw 1996]. Shaw Mary, Garlan David. Software architecture: perspectives on an emerging discipline. 1996. [Shaw 96] Shaw M, Deline R, Zelesnik G. Abstractions and Implementations for Architectural Connections. Third International Conference on Configurable Distributed Systems. Mayo 1996. [Shlaer 1997] Shlaer Sally, Mellor Stephen, IEEE Software pag 61-72. January 1997. [TGI 2000]. El Reporte Delta. Número 109 – Abril 6/2000. http://delta.hypermart.net/ERD109.html [TGI 2001]. El Reporte Delta. Número 147 – Febrero 22 /2001. http://delta.hypermart.net/ERD147.html [TOGAF 2001]. Open Group Arquitectural Framework. Open Group 2001. Version 7. [Trompetero 2001]. Trompetero Alejandro. Pager cooperativo : software para manejar el área de servicios agregados de un portal de comercio electrónico entre cooperativas. Universidad de los Andes. Bogotá Colombia 2001. [Webcompare 2002]. Webserver Quick Compare. http:// http://webcompare.internet.com/cgi-bin/quickcompare.pl Fecha Ultima visita Junio 2002. [Weiss 1999] Weiss, Gerhard ed. Multiagents Systems : A modern Approach to Distributed Artificial Intelligence. The MIT press, 1999. IEEE Conference and Workshop on Engineering of Computer-Based SystemsMarch 07 - 12, 1999 Nashville, Tennessee

MISC-02-2-13

106

ANEXO 1 DESCRIPCION DE LA ARQUITECTURA EN SU PRIMERA

APROXIMACIÓN.

System ClipboardData = { Component Sitios_Asociados = { Properties {}; Port ingreso = { Properties {}; }; Port enlace_salida = { Properties {}; }; }; Component Entidad_Bancaria = { Properties {}; Port solicitud_de_informacion = { Properties {}; }; Port recepcion_de_informacion = { Properties {}; }; }; Component Asociado = { Properties {}; Port recepcion_de_informacion = { Properties {}; }; Port solicitud_de_informacion = { Properties {}; }; }; Component Administrador_Cooperativa = { Properties {}; Port solicitud_de_informacion = { Properties {}; }; Port recepcion_de_informacion = { Properties {}; }; }; Component Administrador_Portal = { Properties {}; Port solicitud_de_informacion = { Properties {};

MISC-02-2-13

107

}; Port recepcion_de_informacion = { Properties {}; }; }; Component Visitante = { Properties {}; Port solicitud_de_informacion = { Properties {}; }; Port recepcion_de_informacion = { Properties {}; }; }; Component Portal_Cooperativo = { Properties {}; Port envio_de_informacion_4 = { Properties {}; }; Port recepcion_de_informacion_2 = { Properties {}; }; Port envio_de_informacion_5 = { Properties {}; }; Port envio_de_informacion_2 = { Properties {}; }; Port recepcion_de_informacion_3 = { Properties {}; }; Port envio_de_informacion_3 = { Properties {}; }; Port recepcion_de_informacion_4 = { Properties {}; }; Port recepcion_de_informacion_5 = { Properties {}; }; Port recepcion_de_informacion_1 = { Properties {}; }; Port envio_de_informacion_1 = {

MISC-02-2-13

108

Properties {}; }; Port ingreso = { Properties {}; }; Port enlace_salida = { Properties {}; }; }; Connector Accede_a_Asociado = { Properties {}; Role llamado = { Properties {}; }; Role llama = { Properties {}; }; }; Connector Accede_desde_asociado = { Properties {}; Role llamado = { Properties {}; }; Role llama = { Properties {}; }; }; Connector Envia_Informacion_Encriptada = { Properties {}; Role llama = { Properties {}; }; Role llamado = { Properties {}; }; }; Connector Envio_Informacion_Adm_Coo = { Properties {}; Role llama = { Properties {}; }; Role llamado = { Properties {}; };

MISC-02-2-13

109

}; Connector Accede_Informacion_Aso = { Properties {}; Role llamado = { Properties {}; }; Role llama = { Properties {}; }; }; Connector Accede_Inf_Adm_Por = { Properties {}; Role llama = { Properties {}; }; Role llamado = { Properties {}; }; }; Connector Envia_Informacion_Aso = { Properties {}; Role llama = { Properties {}; }; Role llamado = { Properties {}; }; }; Connector Envio_Informacion_Vis = { Properties {}; Role llama = { Properties {}; }; Role llamado = { Properties {}; }; }; Connector Accede_Ent_Ban = { Properties {}; Role llama = { Properties {}; }; Role llamado = { Properties {};

MISC-02-2-13

110

}; }; Connector Accede_Adm_Coo = { Properties {}; Role llama = { Properties {}; }; Role llamado = { Properties {}; }; }; Connector Accede_Vis = { Properties {}; Role llama = { Properties {}; }; Role llamado = { Properties {}; }; }; Connector Accede_Adm_Por = { Properties {}; Role llama = { Properties {}; }; Role llamado = { Properties {}; }; }; Attachments { Visitante.solicitud_de_informacion to Accede_Vis.llama; Portal_Cooperativo.envio_de_informacion_1 to Accede_Vis.llamado; Portal_Cooperativo.recepcion_de_informacion_2 to Accede_Adm_Por.llamado; Administrador_Portal.recepcion_de_informacion to Accede_Adm_Por.llama; Portal_Cooperativo.recepcion_de_informacion_3 to Envia_Informacion_Aso.llama; Asociado.recepcion_de_informacion to Envia_Informacion_Aso.llamado; Administrador_Cooperativa.solicitud_de_informacion to Accede_Adm_Coo.llama; Portal_Cooperativo.envio_de_informacion_4 to Accede_Adm_Coo.llamado; Entidad_Bancaria.solicitud_de_informacion to Accede_Ent_Ban.llamado; Portal_Cooperativo.envio_de_informacion_5 to Accede_Ent_Ban.llama; Visitante.recepcion_de_informacion to Envio_Informacion_Vis.llamado;

MISC-02-2-13

111

Portal_Cooperativo.recepcion_de_informacion_1 to Envio_Informacion_Vis.llama; Administrador_Portal.solicitud_de_informacion to Accede_Inf_Adm_Por.llama; Portal_Cooperativo.envio_de_informacion_2 to Accede_Inf_Adm_Por.llamado; Asociado.solicitud_de_informacion to Accede_Informacion_Aso.llama; Portal_Cooperativo.envio_de_informacion_3 to Accede_Informacion_Aso.llamado; Administrador_Cooperativa.recepcion_de_informacion to Envio_Informacion_Adm_Coo.llamado; Portal_Cooperativo.recepcion_de_informacion_4 to Envio_Informacion_Adm_Coo.llama; Portal_Cooperativo.recepcion_de_informacion_5 to Envia_Informacion_Encriptada.llamado; Entidad_Bancaria.recepcion_de_informacion to Envia_Informacion_Encriptada.llama; Sitios_Asociados.ingreso to Accede_desde_asociado.llama; Portal_Cooperativo.enlace_salida to Accede_desde_asociado.llamado; Sitios_Asociados.enlace_salida to Accede_a_Asociado.llamado; Portal_Cooperativo.ingreso to Accede_a_Asociado.llama; }; }; /* end system */

MISC-02-2-13

112

ANEXO NO 2 . DESCRIPCIÓN DE LA FAMILIA PORTALES COOPERATIVOS EN

LENGUAJE ADL.

// This Acme description was saved from AcmeStudio // Property Type Armani-AnalysisT = String; Property Type Armani-InvariantT = String; Property Type Armani-HeuristicT = String; Family portalcooperativo = { Property Type tipo_de_usuario = String; Component Type Actualizacion_e_Insercion = { Properties { sentencia_sql : string = ""; resultado_operacion : boolean; dejar_log : boolean; tipo_de_estructura : string = ""; nombre_de_la_estructura : string = ""; operacion : string = ""; }; }; Component Type Borrado = { Properties { sentencia_sql : string = ""; resultado_de_operacion : boolean; dejar_log : boolean; }; }; Component Type Servicios = { Properties { tipo_de_servicio : string = ""; numero_de_participantes : int; dejar_log : boolean; }; }; Component Type Transaccion = { v Properties { dejar_log : boolean; tipo_de_estructura : string = ""; nombre_estructura : string = ""; operacion : string = ""; }; Port conexion_segura = { Properties { }; }; }; Component Type almacenamiento_de_informacion = {

MISC-02-2-13

113

Properties { motor : string; maximo_numero_de_conexiones : int; sid : string; descripcion_del_repositorio : string = ""; }; }; Component Type Consultas = { Properties { resultado_operacion : boolean; tiempo_de_respuestas : float; numero_maximo_de_registros_retornados : int; visualizacion_directa : boolean; dejar_log : boolean; sentencia : string = ""; tipo_de_consulta : string = ""; metodo_utilizado : string = ""; nombre_fuente : string = ""; tipo_de_fuente : string = ""; valor_retornado_por_registro : string = ""; tipo_de_estructura : string = ""; nombre_de_estructura : string = ""; operacion : string = ""; }; }; Connector Type conexion_a_modulos = { Properties { tipo_de_usuario_permitido : string = ""; numero_de_parametros : string = ""; parametros_a_pasar : string = ""; }; Role desde = { Properties { }; }; Role hacia = { Properties { }; }; }; Connector Type Conexion_al_front_end = { Properties { direccion_http : string; tipo_de_conexion : string = ""; }; Role va_a_direccion_http = { Properties { }; }; Role viene_de_usuario = { Properties { }; };

MISC-02-2-13

114

}; Connector Type Respuesta_consulta = { Properties { fuente_de_datos : string = ""; devuelve_valores : string = ""; numero_de_valores_de_retorno : string = ""; valores_de_retorno : string = ""; retornos : string = ""; }; Role viene_de_bd = { Properties { }; }; Role va_a = { Properties { }; }; }; Connector Type Consulta_informacion = { Properties { fuente_de_datos : string = ""; existen_parametros : string = ""; numero_de_parametros : string = ""; parametros : string = ""; valor_de_los_parametros : string = ""; }; Role Viene_de = { Properties { }; }; Role va_a = { Properties { }; }; }; Connector Type Borrado_informacion = { Properties { }; Role viene_de = { Properties { }; }; Role llega_a = { Properties { }; }; }; Connector Type Insercion_y_Actualizacion_informacion = { Properties { }; Role viene_de = { Properties { }; }; Role llega_a = {

MISC-02-2-13

115

Properties { }; }; }; Connector Type respuesta_de_operacion = { Properties { respuesta : string = ""; error : string = ""; }; Role viene_de_fuente_de_informacion = { Properties { }; }; Role va_hacia = { Properties { }; }; }; Properties { }; Attachments { }; };

MISC-02-2-13

116

ANEXO 3. INSTANCIA DE LA FAMILIA PORTAL COOPERATIVO System copime : portalcooperativo = { Component Visitante = { Properties { }; Port p = { Properties { }; }; }; Component front_end = { Properties { }; Port p = { Properties { }; }; Port p1 = { Properties { }; }; Port p2 = { Properties { }; }; Port p3 = { Properties { }; }; Port p4 = { Properties { }; }; Port p5 = { Properties { }; }; }; Component identificacion : Consultas = new Consultas extended with { Properties { resultado_operacion : boolean;

MISC-02-2-13

117

tiempo_de_respuestas : float; numero_maximo_de_registros_retornados : string = "1"; visualizacion_directa : string = "no"; dejar_log : string = "true"; sentencia : string = "pl/sql web toolkit"; tipo_de_consulta : string = ""; metodo_utilizado : string = "leer cookie"; nombre_fuente : string = "cookie"; tipo_de_fuente : string = "cookie"; valor_retornado_por_registro : string = "identificacion del usuario"; }; Port punto_de_acceso = { Properties { }; }; Port punto_de_respuesta = { Properties { }; }; }; Component Promociones : Consultas = new Consultas extended with { Properties { resultado_operacion : boolean; tiempo_de_respuestas : string = "<5sg"; numero_maximo_de_registros_retornados : int; visualizacion_directa : string = "true"; dejar_log : string = "true"; sentencia : string = "sql"; tipo_de_consulta : string = "sql"; metodo_utilizado : string = "llamada a sentencia sql"; nombre_fuente : string = "scottf1.sql"; tipo_de_fuente : string = "base de datos"; valor_retornado_por_registro : string = ""; }; Port p = { Properties { }; }; Port p1 = { Properties { }; }; Port p2 = { Properties {

MISC-02-2-13

118

}; }; }; Component base_de_datos : almacenamiento_de_informacion = new almacenamiento_de_informacion extended with { Properties { motor : string = "oracle"; maximo_numero_de_conexiones : int; sid : string = "papadio"; descripcion_del_repositorio : string = "base de datos "; }; Port puerto_de_conexion = { Properties { }; }; Port p = { Properties { }; }; Port p1 = { Properties { }; }; Port p2 = { Properties { }; }; Port p3 = { Properties { }; }; Port p4 = { Properties { }; }; }; Component recomendaciones : Consultas = new Consultas extended with { Properties { resultado_operacion : boolean; tiempo_de_respuestas : float; numero_maximo_de_registros_retornados : int; visualizacion_directa : boolean; dejar_log : boolean; sentencia : string = "";

MISC-02-2-13

119

tipo_de_consulta : string = ""; metodo_utilizado : string = ""; nombre_fuente : string = ""; tipo_de_fuente : string = ""; valor_retornado_por_registro : string = ""; }; Port p = { Properties { }; }; Port p1 = { Properties { }; }; Port p2 = { Properties { }; }; }; Component propagandas : Consultas = new Consultas extended with { Properties { resultado_operacion : boolean; tiempo_de_respuestas : float; numero_maximo_de_registros_retornados : int; visualizacion_directa : boolean; dejar_log : boolean; sentencia : string = ""; tipo_de_consulta : string = ""; metodo_utilizado : string = ""; nombre_fuente : string = ""; tipo_de_fuente : string = ""; valor_retornado_por_registro : string = ""; }; Port p = { Properties { }; }; Port p1 = { Properties { }; }; Port p2 = { Properties { };

MISC-02-2-13

120

}; }; Connector devuelve_identificacion : Respuesta_consulta = new Respuesta_consulta extended with { Properties { fuente_de_datos : string = "cookie"; devuelve_valores : string = "true"; numero_de_valores_de_retorno : string = "1"; valores_de_retorno : string = "cadena"; retornos : string = "nombre del usuario"; sDelayTime : float = 0.000; sVisits : float = 0.000; vis-validchildren : sequence<string> = <> ; vis-validattachments : sequence<string> = <> ; }; Role viene_de_bd = { Properties { }; }; Role va_a = { Properties { }; }; }; Connector consigue_identificacion : Consulta_informacion = new Consulta_informacion extended with { Properties { fuente_de_datos : string = "cookie"; existen_parametros : string = "si"; numero_de_parametros : string = "1"; parametros : string = "valor de la galleta "; valor_de_los_parametros : string = "cookie_name29"; sDelayTime : float = 0.000; sVisits : float = 0.000; }; Role Viene_de = { Properties { };

MISC-02-2-13

121

}; Role va_a = { Properties { }; }; }; Connector solicita_conexion : Conexion_al_front_end = new Conexion_al_front_end extended with { Properties { direccion_http : string = "http://copime.com.co"; tipo_de_conexion : string = "via web "; }; Role va_a_direccion_http = { Properties { }; }; Role viene_de_usuario = { Properties { }; }; }; Connector consulta_promociones : conexion_a_modulos = new conexion_a_modulos extended with { Properties { fuente_de_datos : string = ""; existen_parametros : string = "true"; numero_de_parametros : string = "1"; parametros : string = "identificacion del usuario"; valor_de_los_parametros : string = "entero"; }; Role Viene_de = { Properties { }; }; Role va_a = { Properties { }; }; }; Connector seleccion_de_promociones : Consulta_informacion = new Consulta_informacion extended with { Properties {

MISC-02-2-13

122

fuente_de_datos : string = "respuesta de identificacion"; existen_parametros : string = "true"; numero_de_parametros : string = "1"; parametros : string = "identificacion usuario"; valor_de_los_parametros : string = "entero"; }; Role Viene_de = { Properties { }; }; Role va_a = { Properties { }; }; }; Connector promociones_vigentes : Respuesta_consulta = new Respuesta_consulta extended with { Properties { fuente_de_datos : string = "base de datos"; devuelve_valores : string = "true"; numero_de_valores_de_retorno : string = ""; valores_de_retorno : string = ""; retornos : string = ""; }; Role viene_de_bd = { Properties { }; }; Role va_a = { Properties { }; }; }; Connector recomendaciones1 : conexion_a_modulos = new conexion_a_modulos extended with { Properties { tipo_de_usuario_permitido : string = "todos"; numero_de_parametros : string = "1"; parametros_a_pasar : string = "identificacion"; }; Role desde = { Properties { }; };

MISC-02-2-13

123

Role hacia = { Properties { }; }; }; Connector propagandas1 : conexion_a_modulos = new conexion_a_modulos extended with { Properties { tipo_de_usuario_permitido : string = "todos"; numero_de_parametros : string = "1"; parametros_a_pasar : string = "identificacion usuario"; }; Role desde = { Properties { }; }; Role hacia = { Properties { }; }; }; Connector consigue_recomendaciones : Consulta_informacion = new Consulta_informacion extended with { Properties { fuente_de_datos : string = "base de datos"; existen_parametros : string = "true"; numero_de_parametros : string = "1"; parametros : string = "identificacion usuario"; valor_de_los_parametros : string = ""; }; Role Viene_de = { Properties { }; }; Role va_a = { Properties { }; }; }; Connector devuelve_recomendaciones : Respuesta_consulta = new Respuesta_consulta extended with { Properties { fuente_de_datos : string = "base de datos"; devuelve_valores : string = "true";

MISC-02-2-13

124

numero_de_valores_de_retorno : string = ""; valores_de_retorno : string = ""; retornos : string = ""; }; Role viene_de_bd = { Properties { }; }; Role va_a = { Properties { }; }; }; Connector consigue_propagandas : Consulta_informacion = new Consulta_informacion extended with { Properties { fuente_de_datos : string = "base de datos"; existen_parametros : string = "true"; numero_de_parametros : string = "1"; parametros : string = "identificacion usuario"; valor_de_los_parametros : string = "entero"; }; Role Viene_de = { Properties { }; }; Role va_a = { Properties { }; }; }; Connector devuelve_propagandas : Respuesta_consulta = new Respuesta_consulta extended with { Properties { fuente_de_datos : string = ""; devuelve_valores : string = ""; numero_de_valores_de_retorno : string = ""; valores_de_retorno : string = ""; retornos : string = ""; }; Role viene_de_bd = { Properties { }; };

MISC-02-2-13

125

Role va_a = { Properties { }; }; }; Attachments { front_end.p to solicita_conexion.va_a_direccion_http; Visitante.p to solicita_conexion.viene_de_usuario; identificacion.punto_de_acceso to consigue_identificacion.va_a; front_end.p1 to consigue_identificacion.Viene_de; identificacion.punto_de_respuesta to devuelve_identificacion.viene_de_bd; front_end.p2 to devuelve_identificacion.va_a; Promociones.p to consulta_promociones.va_a; front_end.p3 to consulta_promociones.Viene_de; Promociones.p1 to seleccion_de_promociones.Viene_de; base_de_datos.puerto_de_conexion to seleccion_de_promociones.va_a; base_de_datos.p to promociones_vigentes.viene_de_bd; Promociones.p2 to promociones_vigentes.va_a; propagandas.p to propagandas1.hacia; front_end.p5 to propagandas1.desde; recomendaciones.p to recomendaciones1.hacia; front_end.p4 to recomendaciones1.desde; recomendaciones.p1 to consigue_recomendaciones.Viene_de; base_de_datos.p1 to consigue_recomendaciones.va_a; base_de_datos.p2 to devuelve_recomendaciones.viene_de_bd; recomendaciones.p2 to devuelve_recomendaciones.va_a; propagandas.p1 to consigue_propagandas.Viene_de; base_de_datos.p3 to consigue_propagandas.va_a; base_de_datos.p4 to devuelve_propagandas.viene_de_bd; propagandas.p2 to devuelve_propagandas.va_a; }; }; /* end system */ /* End of Design */