Desarrollo de una Línea de Producto Software de comercio electrónico

Presentación del tema: "Desarrollo de una Línea de Producto Software de comercio electrónico"— Transcripción de la presentación:

1 Desarrollo de una Línea de Producto Software de comercio electrónico
Ingeniería Técnica Informática de Gestión Desarrollo de una Línea de Producto Software de comercio electrónico Autores: Juan Carlos Álvarez Izquierdo Cristina García Gil Tutor: Miguel Ángel Laguna Serrano Buenas tardes/buenos días a todos. Con el permiso del tribunal vamos a proceder a la presentación del proyecto fin de carrera. Opcional: [que lleva por nombre “Desarrollo de una Línea de Producto Software de comercio electrónico”.] 26 de Mayo del 2008

2 CONTENIDO Visión general y objetivos
Conceptos importantes en líneas de producto Requisitos y Casos de Uso Análisis y Diseño del sistema Implementación de la línea de producto Presentación de la aplicación Conclusiones El contenido de la presentación lo desarrollaremos en estos 8 apartados: •Visión general y objetivos marcados. •Conceptos a destacar sobre las líneas de producto •Descripción de requisitos, actores y Casos de Uso identificados. •Análisis y Diseño del sistema. •Implementación de la línea, donde explicaremos las soluciones aportadas para conseguir los objetivos •Tras este apartado abandonaremos temporalmente la presentación powerpoint para hacer una breve demostración de la aplicación. •Y por último, conclusiones.

3 CONTENIDO Visión general y objetivos
Conceptos importantes en líneas de producto Requisitos y Casos de Uso Análisis y Diseño del sistema Implementación de la línea de producto Presentación de la aplicación Conclusiones

4 Líneas de producto software (LPS)
Las Líneas de Producto Software son probablemente el enfoque de reutilización de mayor éxito Surgen por la necesidad de crear productos más industrializados y personalizados. Grupo de productos relacionados entre sí con una parte común y donde cada uno posee características propias. Ofrecen la infraestructura para crear familias de aplicaciones en lugar de aplicaciones individuales, ofreciendo: Reducción en los costes Menor tiempo de entrega Mayor calidad en los productos Una vez detallado el contenido de la presentación, comenzamos dando una visión general para comprender mejor lo que es una línea de producto En los últimos años en el desarrollo del software ha surgido cierta problemática respecto a las versiones, evolución y personalización de las aplicaciones. Por otra parte se tiende cada vez más a la industrialización del software con el fin de conseguir productos con menor coste en un menor tiempo. Por ello la reutilización busca nuevos caminos centrándose en las líneas de producto software, que son probablemente el enfoque de reutilización de mayor éxito Una Línea de producto en términos generales se entiende como un grupo de productos relacionados entre si, los cuales tienen una parte común que será compartida por todos ellos y unas características propias de cada uno. Centrándonos en nuestro ámbito, una línea de producto software ofrece la infraestructura necesaria para desarrollar familias de aplicaciones en lugar de aplicaciones individuales, de esta forma se consigue un menor tiempo de entrega en el producto, una reducción en los costos de ingeniería, y una mayor calidad en los productos, es decir, que en un mismo proyecto al final del proceso de desarrollo no se obtiene una sola aplicación, sino que se obtienen 2^n aplicaciones distintas, siendo n el número de variantes de la línea.

5 Objetivos Desarrollo de una LPS de comercio electrónico
Encontrar soluciones para manejar su variabilidad. Proporcionar mecanismos para la configuración de la aplicación final. Desarrollo del núcleo de la línea que dará lugar a una aplicación funcional por sí misma. Conseguir un número aceptable de productos finales. Una vez explicado de forma breve en que consiste una línea de producto, pasamos a especificar los objetivos planteados: -Desarrollo de una LPS de comercio electrónico, concretamente la parte común de todas las aplicaciones sobre la que se construirán una serie de características adicionales agrupadas en paquetes (que serán desarrollados también en este proyecto y en futuras ampliaciones), y que darán como resultado un numero suficiente de aplicaciones finales diferentes. Por otra parte, quizás el objetivo mas importante, sea proporcionar mecanismos para la configuración de los distintos productos conseguidos así como encontrar soluciones para manejar la variabilidad de la línea a lo largo del desarrollo Es importante decir que este proyecto es el primero de una serie de proyectos propuestos por el grupo GIRO enmarcado dentro del dominio de transacciones electrónicas y que por lo tanto no se ha pretendido realizar una aplicación con muchas funciones, sino que la labor más importante ha sido aportar soluciones para las dificultades planteadas en el desarrollo de una línea de productos, poder combinar unas características adicionales con otras, sin generar incompatibilidades entre ellas, y así obtener productos distintos de forma inmediata.

6 CONTENIDO Conceptos importantes en líneas de producto
Visión general y objetivos Conceptos importantes en líneas de producto Requisitos y Casos de Uso Análisis y Diseño del sistema Implementación de la línea de producto Presentación de la aplicación Conclusiones

7 Trabajos anteriores Basado en el Modelo de Características propuesto en la tesis de maestría de Lau, Waterloo 2006 Mecanismo para manejar la variabilidad Se detallan características obligatorias y opcionales En nuestra propuesta, se han tomado Partes obligatorias de catálogo de productos y proceso de compra Partes opcionales respecto al catálogo Este proyecto toma como referencia el modelo de características de una línea de producto de comercio electrónico completamente detallado propuesto por la tesis de maestría de Lau, Universidad de Waterloo, 2006 Un modelo de características es un mecanismo que se utiliza para manejar la variabilidad donde se detallan las características o funciones obligatorias y opcionales de la línea. En nuestro caso, hemos tomado las funciones obligatorias de la parte referente al catálogo de productos de una tienda, además de las partes necesarias para realizar un proceso de compra completo, como disponer de un carrito de la compra o poder realizar un pago real. Además hemos creído necesario/conveniente realizar la parte de administración del catálogo de productos. Por otra parte, para generar variabilidad en la línea, hemos seleccionado también cuatro funciones opcionales del modelo de caracteristicas ligadas al catalogo de productos y agrupadas en paquetes que detallaremos en los requisitos. La razón de que las clases y sus atributos y metodos están en ingles es por mantener la coherencia con este modelo

8 Variabilidad en modelos UML: <<merge>>
Necesitamos mecanismo para mostrar variabilidad en tiempo de configuración, no sólo en ejecución Mecanismo UML 2, “combinación de paquetes” Añade detalles de forma incremental a los modelos “Relación entre dos modelos que indica que los contenidos de ambos se combinan” Como se ha llevado a cabo el desarrollo completo de una línea de producto, ha sido necesario encontrar soluciones para manejar la variabilidad en todas las fases del desarrollo. En las primeras fases se ha utilizado Uml como lenguaje de modelado, sus modelos convencionales tienen mecanismos para mostrar la variabilidad, pero estas variantes se refieren por defecto a aplicaciones especificas y no a Lineas de Producto. Por ejemplo la relación de casos de uso <<extend>> permite diferentes formas de pago en un sistema típico de ventas. Todas estas formas de pago pueden ser validas en tiempo de ejecución y estarán presentes en una solución especifica. El problema es que necesitamos mecanismos que muestren la variabilidad en tiempo de ejecución ( aplicación especifica) y en tiempo de configuración (una línea de producto) El mecanismo de "package merge", consiste básicamente en añadir detalles al modelo de una forma incremental. Según la especificación de UML2, es definido como una relación entre dos paquetes que indica que el contenido de ambos se combina. Es muy similar a la generalización y es usado cuando elementos de diferentes paquetes tienen el mismo nombre y representan el mismo concepto, partiendo de una base común. La aplicación de este mecanismo a nuestro problema consiste en establecer para cada modelo de UML, un paquete base que agrupa la parte común de la línea de productos, el cual se asocia a cada una de las características opcionales construyendo así un paquete opcional. Dicho paquete es conectado a través de la relación <<merge>> con el paquete base. Esta relación expresa la dependencia entre ambos paquetes, es decir, el nuevo paquete es una extensión del paquete base y puede ser únicamente incluido si el paquete base está también seleccionado. Esta es exactamente la forma en que el experto decide que características están incluidas o no durante el proceso de configuración.

9 CONTENIDO Requisitos y Casos de Uso Visión general y objetivos
Conceptos importantes en líneas de producto Requisitos y Casos de Uso Análisis y Diseño del sistema Implementación de la línea de producto Presentación de la aplicación Conclusiones

10 Requisitos No Funcionales
Sistema final compuesto por paquetes Sistema flexible ante nuevas funciones Integración de paquetes de forma automática Paquetes independientes La toma de requisitos se ha llevado a cabo mediante entrevistas con el tutor. Entre los requisitos no funcionales se encuentran: -Línea de productos compuesto por varios paquetes, uno de ellos el basico. -El sistema debe ser flexible ante nuevas funciones. -La integración de los distintos paquetes se tiene que hacer de forma automática. -Los paquetes lógicamente deben de ser totalmente independientes

11 Requisitos Funcionales
Paquete Base Acceso al catálogo de productos Ver detalle de productos Realizar una compra y su pago Gestión interna del catálogo de productos Los requisitos funcionales los hemos dividido según los paquetes desarrollados, El paquete base será el núcleo común a toda la línea de producto, por lo tanto debera estar siempre presente en todas las aplicaciones finales y sus características obligatorias son: -Acceso publico al catálogo de productos de ventas, con categorías de primer nivel para clasificar los productos Ver el detalle de cada uno de los productos Realizar una compra y el pago de la misma. - En cuanto a labores de administración, la gestión interna del catálogo

12 Requisitos Funcionales
Paquete CategoryMultilevel Dar soporte a categorías de varios niveles (subcategorías) Paquete Search Realizar búsquedas de productos disponibles a la venta Paquete DirectDownload Permitir la descarga automática de un producto electrónico, tras comprobar su pago Paquete PlugginShoppingCart Visualizar el detalle de los productos agregados al carrito desde cualquier página Los cuatro paquetes opcionales que hemos desarrollado son los siguientes. Paquete CategoryMultilevel, da soporte a categorias de varios niveles, es decir, clasifica los productos de forma mas exhaustiva pudiendo dividir las categorias en nuevas subcategorias. Paquete Search, es el buscador de productos disponibles a la venta en la tienda. Paquete DirectDownload, se pretende automatizar el proceso de compra de productos electronicos, permitiendo una descarga directa tras pagar la compra. Por ultimo, paquete PluginShoppingCart, que es un paquete de interfaz que permite visualizar el detalle del carrito de la compra desde cualquier pagina.

13 Casos de uso En cuanto a los casos de uso se identifican dos actores, y hemos utilizado el package merge mencionado anteriormente. Del paquete base, el usuario puede realizar el caso de uso consultar catalogo, ver producto, comprar y pagar. Por parte del administrador, realiza los casos de uso añadir y eliminar catalogo, categoría y producto. En el paquete CategoriesMultilevel,el usuario puede consultar catalogo con nuevas subcategorias, y el administrador añadir subcategoria. En el paquete Search, el usuario puede buscar productos. Y en el paquete DirectDownload, el usuario puede descargar productos electrónicos.

14 CONTENIDO Análisis y Diseño del sistema Visión general y objetivos
Conceptos importantes en líneas de producto Requisitos y Casos de Uso Análisis y Diseño del sistema Implementación de la línea de producto Presentación de la aplicación Conclusiones El contenido de la presentación lo desarrollaremos en estos 8 apartados: •Visión general del problema y objetivos marcados. •Descripción de la metodología que se ha seguido durante el proceso. •Elicitación de requisitos, actores y Casos de Uso identificados. •Análisis del sistema. •Arquitectura y diseño del sistema. •Veremos las tecnologías utilizadas para la implementación de la aplicación. •Tras este apartado abandonaremos temporalmente la presentación powerpoint para hacer una breve demostración de la aplicación. •Y por último, conclusiones.

15 Análisis y Diseño Aquí se puede ver el diagrama general de todos los paquetes con la relación merge, respecto del paquete base. Cabe destacar que entre los tres paquetes de tipos de producto, sólose ha desarrollado el ElectronicProduct, que además se ha incluido en el paquete base, ya que es obligatorio su uso, porque con los otros dos tipos de productos no se podía realizar un proceso de compra completo, porque se necesitaban caracteristicas adiconales como embalaje y envio. Sin embargo con ElectronicProduct, este problema queda solucionado cuando el administrador le envia un al comprador para remitimirle su producto. Pasamos a ver el diagrama de clases de estos paquetes

16 Paquete Base: ElectronicProduct
Estos diagramas corresponden al diagrama de clases de diseño

17 Paquete CategoryMultilevel
Paquete DirectDownload Paquete Search

18 Modelo relacional Catalog (id_catalogo, name,description,icon,active)
Category (id_category,id_catalogo, name, descripcion,icon, active) Product (id_producto,id_catalogo,name,description,icon,active,longDescription,standardDescription,suggestedRetailPrice,price, size,link) Prod_agrupa_Cat (id_categoria,id_producto) OrderItem (itemId,orderId,id_producto,name, price,status) Orders (orderId, date, ,status,total) PaymentInfo (id_payment,orderId,status,price,tipo) Paypal (id_payment, )

19 CONTENIDO Implementación de la línea de producto
Visión general y objetivos Conceptos importantes en líneas de producto Requisitos y Casos de Uso Análisis y Diseño del sistema Implementación de la línea de producto Tecnología utilizada Soluciones generales para una aplicación de comercio electrónico Soluciones de la Línea de Producto en un entorno web Presentación de la aplicación Conclusiones

20 Tecnología utilizada Lenguaje C# , permite clases parciales
Package merge  clases parciales  C# ASP.NET, utiliza C# de forma nativa Visual Studio 2005, entorno de desarrollo de .NET SQL Server Express, como gestor de base de datos Como estamos ante el desarrollo de una línea de producto, las exigencias en cuanto a tecnología son mayores, por ejemplo debemos encontrar el mecanismo para definir distintas funciones en paquetes diferentes (es decir en archivos diferentes tal y como el mecanismo de package merge lo hacía en diseño).la solución en la implementación es lo que se denomina clases parciales, y el lenguaje que da soporte es C# y la plataforma .NET Por otra parte estamos en un entorno web y visto que era necesario el uso de la plataforma .NET, utilizamos ASP.NET junto a C# .NET también permite el desarrollo de aplicaciones de ventana, por lo que hemos creido conveniente realizar dos pequeñas aplicaciones para configuración. Como entorno de desarrollo hemos utilizado visual studio 2005 porque se integra perfectamente y como gestor de base de datos el SQL Server 2005 por la misma razón y en su versión express porque es gratuita.

21 CONTENIDO Implementación de la línea de producto
Visión general y objetivos Conceptos importantes en líneas de producto Requisitos y Casos de Uso Análisis y Diseño del sistema Implementación de la línea de producto Tecnología utilizada Soluciones generales para una aplicación de comercio electrónico Soluciones de la Línea de Producto en un entorno web Presentación de la aplicación Conclusiones El contenido de la presentación lo desarrollaremos en estos 8 apartados: •Visión general del problema y objetivos marcados. •Descripción de la metodología que se ha seguido durante el proceso. •Elicitación de requisitos, actores y Casos de Uso identificados. •Análisis del sistema. •Arquitectura y diseño del sistema. •Veremos las tecnologías utilizadas para la implementación de la aplicación. •Tras este apartado abandonaremos temporalmente la presentación powerpoint para hacer una breve demostración de la aplicación. •Y por último, conclusiones.

22 Diseño de la interfaz Master.page
Plantilla que especifica el formato de todas las páginas de la parte visible de la tienda Albergará partes comunes de todas las páginas Facilita el trabajo de diseño de la interfaz Hojas de estilo CSS Definen reglas para determinar la apariencia (tamaño y tipo de letra, colores, etc) Facilitan cualquier cambio en la forma de mostrar los distintos elementos Ventajosas para trabajos desarrollados en grupo y para futuras ampliaciones Para el diseño de la interfaz hemos utilizado el recurso de .NET de master.page, que es una plantilla que define el mismo formato en todas las paginas web que la usen. Con esta plantilla todas las paginas tendrán el mismo aspecto y tendrán siempre un contenido común. De esta forma se facilita el trabajo del diseño de la interfaz, ya que este se realiza una sola vez y en un único archivo. Por otra parte tambien hemos utilizado hojas de estilo CSS, que definen reglas para determinar la apariencia de los elementos de las paginas, como el tamaño o tipo de letra, colores, etc De esta forma es muy fácil realizar algún cambio en la forma de mostrar los distintos elementos y por lo tanto muy ventajosa a la hora de trabajos desarrollados en grupos y futuras ampliaciones como esta previsto que se va suceder en este proyecto.

23 Gestión interna Necesaria para la gestión del catálogo de productos
La realiza el administrador, debe identificarse como tal. Se ha utilizado la seguridad propia de .NET Autenticación de formularios Web.config Algoritmo SHA1 para cifrar la contraseña Uno de los requisitos que tenía que cumplir nuestro sistema, era la gestión del catálogo de productos realizado por el administrador de la tienda. De esta forma podrá realizar los casos de uso de añadir, eliminar catálogos, categorías y productos. Como solo lo puede realizar el usuario administrador, este tendrá que identificarse como tal y para ello hemos usado la seguridad que proporciona asp.net, concretamente mediante autenticación de formularios. No hemos usado registro de usuarios, ya que ese sería un paquete opcional que esta siendo desarrollado en otro proyecto. Para la autenticación de formularios se han especificado una serie de líneas de código, entre las cuales están las del ejemplo de la diapositiva en el archivo de configuración de cada aplicación que se denomina web.config. En el se especifican las paginas restringidas y que sólo puede utilizar el usuario administrador y además también se guarda el nombre del administrador y su contraseña cifrada por el algoritmo SHA1. Este archivo web.config es configurado cuando se ejecute la aplicación de configuración del usuario o la aplicación de la configuración de los paquetes.

24 Paypal como forma de pago
Necesitamos forma de pago real y segura (cifrado de datos) Facilidad de uso y de reconocimiento internacional Fácil integración a un sistema de ventas particular Servicio gratuito, en contraposición de las pasarelas de los bancos Todo proceso de compra lleva asociado un pago, entre los requisitos de nuestro sistema, estaba encontrar un método de pago seguro y real y que su uso fuera sencillo. Elegimos a paypal como método de pago porque cumplía todas estas características, y además su servicio es gratuito y dan bastante soporte a los desarrolladores en contraposición a los sistemas de pago de los bancos que si cobran por este servicio y su soporte es menor. Cuando haces una compra en nuestro sistema, este manda una serie de datos que identifican la compra a paypal y directamente te redirecciona con su servidor seguro donde te tendrás que identificar o registrar como usuario de paypal y seguir los pasos para realizar de forma segura. Una vez finalizado el pago, paypal te la da opción de volver al sistema, y si lo haces, nuestro sistema informará de que el pago ha sido registrado y te proporciona el id de tu compra. Un paquete opcional que podría ser desarrollado en futuras ampliaciones sería el envío de un de confirmación por parte de nuestro sistema de la compra realizada

25 CONTENIDO Implementación de la línea de producto
Visión general y objetivos Conceptos importantes en líneas de producto Requisitos y Casos de Uso Análisis y Diseño del sistema Implementación de la línea de producto Tecnología utilizada Soluciones generales para una aplicación de comercio electrónico Soluciones de la Línea de Producto en un entorno web Presentación de la aplicación Conclusiones Una vez vistas las soluciones generales de una aplicación normal de comercio electrónico, pasamos a detallar las soluciones propias para manejar la variabilidad en una línea de productos para un entorno web.

26 Variabilidad en capa de lógica: Clases parciales
Clases parciales de C# para tratar la variabilidad Definición de las clases en uno o más archivos de código fuente Archivos de código fuente en paquetes diferentes, añadiendo funcionalidad a la clase Como hemos introducido, C# permite el mecanismo de clases parciales para manejar la variabilidad en implementación, es decir, permite definir las características de una misma clase en archivos diferentes. Por ejemplo, si en paquete base está definida la clase category con todos los atributos y operaciones que dan soporte a la funcionalidad básica Pero si añadimos el paquete categorymultilevel, tendríamos que implementar ciertas funciones o atributos que no estaban incluidos en un principio, por eso en este nuevo paquete incluiríamos un nuevo archivo de la clase category que dieran soporte a esta nueva funcionalidad. Y al compilar los dos paquetes, se compilarían los dos archivos obteniendo una sóla clase con la funcionalidad completa de ambos paquetes.

27 Variabilidad en Interfaz: Controles de usuario
Recurso de ASP.NET, crea elementos reutilizables similares a los formularios web, tienen extensión .ascx Porciones de código HTML Se incrustan a páginas web de ASP.NET Solución a la variabilidad en la interfaz de usuario cuando se agregan dinámicamente Otro de los problemas que plantea el desarrollo de la línea de productos es manejar la variabilidad en la capa de interfaz en este caso en un entorno web. El recurso utilizado esta vez, son los controles de usuario que crean elementos reutilizables de codigo html. Es decir, crea porciones de página que se pueden reutilizar en tantas páginas como se desee [click] y si los agregamos de forma dinámica cambia el aspecto de una misma página dependiendo de si se incluyen más o menos controles de usuario.

28 Controles de usuario dinámicos
Aportan la interfaz necesaria para obtener las funciones extra que ofrecen los paquetes opcionales Se añaden o no de forma dinámica a las páginas de ASP.NET cuando el sistema reconoce los paquetes instalados Incrustados en los denominados PlaceHolder (huecos contenedores) Para agregarlos o no de forma dinámica, el sistema final debe reconocer aquellos controles de usuario que se deben insertar según los paquetes seleccionados Para ello en cada página web, se debe de incluir un “hueco contenedor”, al que se le podrán agregar estos controles y que se denomina placeholder. En la imagen hemos marcado en rojo, los 4 controles de usuario que son opcionales y que aparecerán o no según la versión de la aplicación final.

29 Controles de usuario dinámicos
Cada PlaceHolder puede alojar tantos controles de usuario como se desee Los PlaceHolder se ubican en el lugar preciso de la página según el diseño de interfaz deseado Para facilitar trabajos futuros, se ha incluido al menos un PlaceHolder en todas las páginas del proyecto En comparación con la anterior imagen, aquí se puede ver la misma página en la herramienta de diseño. Como podemos ver que sólo hay 2 huecos macados en rojo, y no hay nada mas que un “contendor” o placeholder, donde se incrustarán los controles de usuario que correspondan. e Estos contenedores se ubican en el lugar precios de la pagina según el diseño de la interfaz, y ara facilitar trabajos futuros hemos ncluidos un placeholder en cada página del proyecto aqunque en nuestro caso no fuera necesario

30 Agregar controles de forma automática
<?xml version="1.0" encoding="utf-8" ?> <paquetes> <paquete> <nombre>../Search</nombre> <activado>true</activado> <archivos> <archivo>MasterSearchBox.ascx</archivo> </archivos> </paquete> <nombre>../CategoryMultilevel</nombre> <archivo>CatalogCategoriesTree.ascx</archivo> <archivo>ProductoCategoriesTree.ascx</archivo> <archivo>AdmCategoryAddSubcategory.ascx</archivo> <nombre>../PlugginShoppingCart</nombre> <archivo>LeftMasterCartSummary.ascx</archivo> El sistema reconoce los paquetes instalados mediante un archivo XML (paquetes.xml) Incluye información sobre los paquetes incluidos y los controles de usuario que interactúan con el paquete base, así como su ubicación Páginas del sistema leen este archivo y reconocen si debe agregar algún control en ellas Nombrados de forma especial para saber en qué paginas se agregan: “Nombre_páginaNombreControl.ascx” Para que el sistema reconozca que controles de usuario debe agregar en los placeholder según los paquetes seleccionados, cada página web deberá de leer un archivo XML, donde se recoge información de los paquetes instalados, los controles de usuario que interactúan con el paquete base y su localización física. Además los controles de usuario que interactúan con el paquete base, se deben de nombrar de una forma específica para conocer en que páginas se debe de incluir. La forma es : nombre de la página donde se deberán incluir y el nombre del control que se le puede dar cualquier nombre y la extensión ascx que es la que llevan este tipo de archivos. Aquí vemos un ejemplo real del xml utilizado. Donde vemos el nombre y ubicación del paquete, si esta activado o no, y los controles de usuario que interactúan con el paquete base. Este archivo no recoge todos los archivos de un paquete, sino sólo los que interactúa con el paquete base.

31 Configuración de la aplicación final
Compilar solamente los elementos necesarios de los paquetes elegidos Archivo .csproj de Visual Studio, controla los elementos a compilar -> NombredelProyecto.csproj Modificamos este archivo a nuestro gusto para compilar los elementos de cada paquete (clases, páginas web, controles de usuario) <ItemGroup> <Compile Include=“Search/Search.cs" /> <Compile Include="Search\Searching.aspx. cs"> <DependentUpon>Searching.aspx</DependentUpon> <SubType>ASPXCodeBehind</SubType> </Compile> <Compile Include="Search\Searching.aspx.designer.cs"> </ItemGroup> <Content Include="Search\Searching.aspx" /> Una vez explicada como hemos manejado la variabilidad tanto en las fases de diseño, como en implementación e interfaz. Sólo nos quedaría configurar la aplicación final para poder aplicar todos estos recursos. Para ello solamente tenemos que compilar los elementos contenidos en los paquetes elegidos. En nuestro entorno de desarrollo existe un archivo que controla los elementos que debe compilar, que se llama el nombredelproyecto.csproj Y que se va actualizando automáticamente según se van creando nuevos elementos dentro de la aplicación. Nuestra tarea sería modificar este archivo a nuestro gusto para compilar solamente aquellos elementos que deseamos, es decir aquellos elementos que pertenezcan a los paquetes que queremos seleccionar. Para hacer esto de una forma automática hemos creado una pequeña aplicación de ventana que modifica tanto este archivo como parámetros típicos de la tienda

32 Configuración de la aplicación final
Pasos a seguir 1. Abrir la solucion en Visual Studio 2. Ejecutar proyecto de Configuracion Elegir los paquetes de la aplicación web final Modificar el .csproj y XML Configurar los parámetros de la tienda Nombre de la tienda Productos por página receptor del pago Moneda utilizada Datos del administrador Modificar Web.config Seleccionar Base de Datos a utilizar Servidor Nombre de la base de datos Posibilidad de crear una nueva Entonces, los pasos a seguir para la configuración de la aplicación de comercio electrónico final, serían. Abrir la solución en visual studio ejecutamos el proyecto de configuración y en la aplicación de ventana tenemos 3 partes Primero, los paquetes que queremos seleccionar y que modificarán el csproj y el archivo XML que hemos explicado antes Segundo, podemos configurar los parámetro de personalización de cada tienda, (nombre, productos por pagina, cuenta receptora del pago, moneda utilizada, y los datos relativos al administrador) Y por último, lo relacionado con la base de datos a utilizar, primero elegiríamos un servidor de base de datos de los instalados en la máquina, y una vez elegido este, leerá las bases de datos que contienen y nos las mostrará para seleccionar una de ellas, si no tenemos base de datos o queremos crear una nueva, también nos da esta posibilidad con todas las tablas vacías.

33 Configuración de la aplicación final
3. Volver a cargar Proyecto Tienda 4. Generar el archivo autoinstalable mediante el proyecto WebInstall Una vez escogida la configuración, y puesto que se ha modificado el archivo .csproj, el visual studio nos avisa de ello y nos dice si queremos volver a cargar el proyecto con los nuevos parámetros. Aceptamos y para acabar generamos el archivo autoinstalable de la tienda final, que podremos llevar a cualquier máquina.

34 CONTENIDO Presentación de la aplicación Visión general y objetivos
Conceptos importantes en líneas de producto Requisitos y Casos de Uso Análisis y Diseño del sistema Implementación de la línea de producto Presentación de la aplicación Conclusiones

35 CONTENIDO Conclusiones Visión general y objetivos
Conceptos importantes en líneas de producto Requisitos y Casos de Uso Análisis y Diseño del sistema Implementación de la línea de producto Presentación de la aplicación Conclusiones El contenido de la presentación lo desarrollaremos en estos 8 apartados: •Visión general del problema y objetivos marcados. •Descripción de la metodología que se ha seguido durante el proceso. •Elicitación de requisitos, actores y Casos de Uso identificados. •Análisis y Diseño del sistema. •Implementación de la línea •Veremos las tecnologías utilizadas para la implementación de la aplicación. •Tras este apartado abandonaremos temporalmente la presentación powerpoint para hacer una breve demostración de la aplicación. •Y por último, conclusiones.

36 Objetivos cumplidos Desarrollar una línea de producto de comercio electrónico, que tras ser configurada y compilada, da como resultado una familia de aplicaciones funcionales por sí mismas. Núcleo de la línea y cuatro paquetes opcionales distintos compatibles entre sí, que nos proporcionan una variabilidad de dieciséis productos diferentes. Soluciones tales como clases parciales, compilar sólo los paquetes elegidos o agregar controles de usuario dinámicamente para manejar la variabilidad de la línea en un entorno web Configurar los distintos productos finales de la línea de forma inmediata Añadir funciones adicionales, Aplicación de configuración de cada tienda para incluir personalizaciones Autoinstalación para cada tienda

37 Trabajos futuros Desarrollo de nuevos paquetes opcionales que complementen la línea de comercio electrónico Registro de clientes Historial de compras Gestión de ventas Nuevos métodos de pago […] Proporcionar soluciones a la variabilidad en la base de datos Configuración de la aplicación final a través de su modelo de características de forma automática

38 Desarrollo de una Línea de Producto Software de comercio electrónico
Ingeniería Técnica Informática de Gestión Desarrollo de una Línea de Producto Software de comercio electrónico Autores: Juan Carlos Álvarez Izquierdo Cristina García Gil Tutor: Miguel Ángel Laguna Serrano Buenas tardes/buenos días a todos. Con el permiso del tribunal vamos a proceder a la presentación del proyecto fin de carrera. Opcional: [que lleva por nombre “Desarrollo de una Línea de Producto Software de comercio electrónico”.] 26 de Mayo del 2008