Ingeniería en Desarrollo de Software Diseño y Arquitectura de Software 4to Semestre Alumno: Daniel Pineda de la Riva Matricula: es162006588 Docente: Mtra. Lluvia Lorena Salas Téllez Unidad 3 Actividad 3: Sistemas adaptables.
1.- Describe detalladamente el caso ejemplo seleccionado para los sistemas adaptables identificando claramente los requerimientos funcionales y no funcionales. Para lo anterior deberás publicar tu propuesta en éste Foro 2.- Identifica los elementos arquitectónicos-modulares del caso con base en el patrón Proxy de los sistemas adaptables. 3.-Representa los objetos (locales o remotos) y los elementos proxy que se pueden agregar en base al caso: a. Remoto b. Virtual c. Protección
4. Identifica a los participantes conforme al sistema (según sea): a. Remoto b. Virtual c. Protección
5. Plasma tu propuesta en una arquitectura base integrando los elementos de un sistema adaptable. El resultado de este punto será una nueva propuesta arquitectónica en formato de imagen digital. Puedes utilizar herramientas como Visio, PowerDesigner, entre otros, o un lenguaje descriptor de arquitectura u otra de tu elección. 6. Explica la aplicación del patrón arquitectónico.
A continuación continuación veremos una breve descripción general del proyecto con el fin de ubicarnos, y poder hacer un mejor seguimiento de las partes que lo componen. El proyecto de investigación se dividirá en 3 etapas: Investigación Desarrollo Adaptable de Software y desarrollo desarroll o de Framework Desarrollo de Framework utilizando DAS Desarrollo de Aplicación Venta DVD utilizando el Framework y DAS
La primera etapa de la investigación comenzó después de entregada la propuesta y se continuó a medida que el proyecto avanzaba, ya que la información rela cionada con estos temas es muy nueva y surgía constantemente. La segunda etapa consistió en la construcción de un Framework para el desarrollo de aplicaciones e-commerce, para la venta o alquiler de bienes materiales, a consumidores individuales. individual es. La tercera etapa consiste en el desarrollo e implantación de una aplicación específica de e-commerce, utilizando el Framework elaborado en la etapa anterior. Esta aplicación estará orientada a la venta y alquiler de DVDs, todo esto se hará basado en la metodología Desarrollo Adaptable de Software. De acuerdo a los resultados obtenidos en cuanto a tiempo de desarrollo, calidad del software, dificultades, ventajas y desventajas del DAS para este tipo de aplicaciones, se podrá obtener una aplicación tangible de e- commerce la cual podrá ser utilizada en el mercado colombiano, incluyendo el desarrollo del Framework el cual podrá ser usado para el desarrollo de otro tipo de aplicaciones e- commerce diferente a la desarrollada por nosotros. Para la construcción del Framework , nos basaremos en la metodología del desarrollo adaptable de software. La implementación del mismo tendrá 3 etapas generales, la especulación en la cual se realiza el análisis y el diseño, la colaboración la cual cubre el desarrollo componentes (diseño del Framework , y la instanciación del mismo), y por último el aprendizaje el cual se refiere al control de calidad y la entrega final del Framework . Estas 3 actividades se llevaron a cabo de manera iterativa, pero no necesariamente lineal, se realizaron 6 ciclos (el número de ciclos es el aconsejado por James Highsmith en su libro “ Adaptive “ Adaptive Software Development ” de acuerdo a la duración del proyecto), p royecto), hasta obtener el producto final acorde a los requerimientos establecidos.
DESARROLLO ADAPTABLE DE SOFTWARE
Se investigaron las empresas de desarrollo de software colombianas, con el fin de conocer si alguna trabajaba o había trabajado con el desarrollo adaptable de software en alguno de sus procesos de desarrollo, para esto se seleccionaron 8 empresas al azar estas empresas se nombran a continuación Incubeit En esta compañía se utiliza una metodología de cascada, no se utiliza ni se conoce nada sobre DAS
Asesoftware Se utiliza la metodología RUP, no se utiliza ni se conoce nada sobre DAS
Bisa Corporation Se utiliza UML, bajo un estándar propio de la compañía, no se utiliza ni se conoce nada sobre DAS
DataSixx Se utiliza una metodología propia basada en SAP Blueprint no se utiliza ni se conoce nada sobre DAS
Heinsohn Se utiliza UML, bajo un estándar propio de la compañía, no se utiliza ni se conoce nada sobre DAS
EDS
Se utiliza RUP y se están realizando investigaciones para la utilización de XP (Programación extrema), no se utiliza DAS
CSI- Complex Systems Inc. Se utiliza una metodología propia de la compañía, no se utiliza ni se conoce nada sobre DAS Alpha GL Se utiliza UML, bajo un estándar propio, pr opio, no se utiliza ni se conoce nada sobre DAS
Sybase No se conoce nada sobre DAS, en cuanto a la metodología utilizada la información no fue suministrada
TinySoft No se conoce nada sobre DAS, en cuanto a la metodología utilizada la información no fue suministrada
De acuerdo con la información ninguna de las 10 empresas seleccionadas había trabajado ni conocía el desarrollo adaptable de software. En conclusión son muy pocas las empresas las cuales utilizan metodologías de desarrollo ágil de software. A continuación continuación veremos el proceso de desarrollo desarrollo adaptable adaptable de software software que se utilizó en la realización del framework. 1 Ciclo
Para el Plan de Ciclos de desarrollo adaptable se realizaron 7 iteraciones en total. o
o
o
o
Primera iteración 15/08/2004 Corresponde a la especulación, se definieron el número de ciclos que se realizarían y sus correspondientes actividades, esta información era tentativa, ya que se tenía muy poco conocimiento e información del desarrollo del Framework en general. Segunda iteración 20/08/2004 A medida que se obtuvo más información información acerca del desarrollo desarrollo del Framework, Se replantearon los ciclos que debían llevarse acabo, en consecuencia se cambiaron el nombre, actividades y objetivos de los ciclos 2, 3, 4, 5, 6. Al redefinirse los ciclos, las actividades y el cronograma cambiaron acorde al documento Gracias al DAS estos cambios no causaron ningún trauma en el desarrollo del proyecto. Tercera iteración 21/08/2004 Se encontró un problema en las actividades a realizarse en el ciclo 3, ya que estas no estaban bien definidas. Cuarta iteración 15/10/2004 Debido a cambios en el análisis y el diseño del Framework , se cambiaron algunos componentes de los ciclos de implementación, se realizó la correspondiente corrección de la lista de actividades y el cronograma. Se redefinió el ciclo 6, igual que sus objetivos y componentes. 37
o
o
o
Quinta iteración 16/10/2004 Se corrigieron algunas actividades y componentes de los ciclos de análisis, diseño e implementación. Sexta iteración 18/10/2004 Corrección de algunas de las actividades y componentes de los ciclos de implementación. Séptima iteración 28/03/2005 De acuerdo a la recomendación del comité de investigación se cambió el término e-business por e-commerce
2 Ciclo
Para el ciclo de Análisis se realizaron 8 iteraciones. o
o
o
o
o
o
o
Primera iteración 24/09/2004 Se realizó una primera versión del documento (borrador) propuesto en el 1 ciclo Segunda iteración 28/09/2004 Se complemento el documento de análisis, se agregaron diagramas de casos de uso y su correspondiente documentación Tercera iteración 02/10/2004 Se corrigió la documentación de los casos de uso y se cambio el tiempo de respuesta Cuarta iteración 04/10/2004 Se agregaron comentarios referentes al desarrollo del Framework , se corrigió documentación de los casos de uso Quinta iteración 10/10/2004 Se agregaron casos de uso, y se realizó una identificación de objetos inicial, con su correspondiente diagrama de dominio Sexta iteración 11/10/2004 Se corrigieron errores en la documentación Séptima iteración 30/10/2004 Se corrigieron los requerimientos del sistema de acuerdo a la implementación, además se agregaron casos de uso y su 38
correspondiente documentación o
Octava iteración 28/03/2005 De acuerdo a la recomendación del comité de investigación se cambió el término e-business por e-commerce.
3 Ciclo
Para el ciclo de Diseño se realizaron 11 iteraciones. o
o
o
o
o
o
o
o
o
o
Primera iteración 26/10/2004 Se realizó una primera versión del documento (borrador) propuesto en el 1 ciclo Segunda iteración 28/10/2004 Se completo la descomposición por entidades Tercera iteración 31/10/2004 Se agregaron más entidades, y una descripción de componentes J2EE Cuarta iteración 10/11/2004 Se agrego el modelo de datos y su documentación, se corrigieron algunos errores en la arquitectura Quinta iteración 11/11/2004 Se corrigió el modelo de datos Sexta iteración 20/11/2004 Se agregaron componentes J2EE ( SessionsEJB y EntitiesEJB) y Patrones de Software a la arquitectura Séptima iteración 23/11/2004 Se agregó un ejemplo de creación de tablas (script) de acuerdo al modelo de datos, se agregaron diagrama de clases de los componentes J2EE y diagrama de clases Octava iteración 24/11/2004 Se corrigió el modelo de datos Novena iteración 26/11/2004 Se cambio el diagrama de arquitectura, y cambio el diagrama de componentes J2EE Décima iteración 27/11/2004 Se mejoro la descripción de la arquitectura, y algunos diagramas de componentes, se corrigió el modelo de datos 39
o
Undécima iteración 28/03/2005 De acuerdo a la recomendación del comité de investigación se cambió el término e-business por e-commerce.
4 Ciclo
Para el ciclo de Implementación I se realizaron 8 iteraciones. o
o
o
o
o
o
o
o
Primera iteración 16/11/2004 Se implementaron las clases correspondientes a la lógica del negocio, la clase ProductoCreator(Factory) y la clase Service Locator Segunda iteración 18/11/2004 Se corrigieron errores de configuración del Service Locator Tercera iteración 22/11/2004 Se corrigieron errores de conectividad del Service Locator Cuarta iteración 26/11/2004 Se implementaron los Session EJB y las bases de datos Quinta iteración 10/12/2004 Se corrigieron errores en la conectividad de los Session Bean , se modificaron algunas tablas de la base de datos de acuerdo a cambios en el diseño Sexta iteración 15/12/2004 Se corrigieron problemas en la funcionalidad de los Session Bean Séptima iteración 20/012005 Se modificaron algunos atributos de las tablas debido a desbordamiento de información Octava iteración 31/01/2005 Se realizaron ajustes de acuerdo a las pruebas realizadas.
5 Ciclo
Para el ciclo de Implementación II se realizaron 6 iteraciones. o
o
Primera iteración 28/11/2004 Se implementaron las clases DAO, los Entities CMP y la clase Business Delegate Segunda iteración 3/12/2004 Se corrigieron errores de conectividad y consultas en los DAO 40
o
o
o
o
Tercera iteración 10/12/2004 Se corrigieron errores en la transaccionalidad de los CMP Cuarta iteración 15/12/2004 Se agregaron métodos a la clase Business Delegate Quinta iteración 07/01/2005 Se integraron todos los componentes del Framework y la lógica del negocio Sexta iteración 31/01/2005 Se realizaron ajustes de acuerdo a las pruebas realizadas.
6 Ciclo
Para el ciclo de Pruebas se realizaron 5 iteraciones. Primera iteración 08/01/2005 Se realizó una primera versión del documento (borrador) propuesto en el 1 ciclo Segunda iteración 22/01/2005 o Se realizaron el manual de usuario y el manual de instalación y configuración Tercera iteración 25/01/2005 o Se realizó la guía de extensión del Framework o Cuarta iteración 30/01/2005 Se cambio la estructura de algunas pruebas Quinta iteración 15/02/2005 o Se corrigieron errores en los manuales y la guía del Framework o
Estas iteraciones fueron realizadas de una manera no lineal y se basaron en el aprendizaje de la iteración previa. Además los ciclos y sus actividades se fueron modificando de acuerdo al avance del proyecto.
DESARROLLO DEL F R A M E W O R K
Como se dijo anteriormente la 1 etapa se baso en investigación, ahora describiremos mas detalladamente las siguientes 2 etapas. La segunda etapa de nuestro proyecto como ya se dijo consistió en la construcción de un Framework para el desarrollo de aplicaciones e-commerce, para la venta de bienes materiales, a consumidores individuales. Aplicando la metodología ágil DAS, se definieron el número de ciclos que tendría el desarrollo del Framework . Se realizaron 6 ciclos - el número de ciclos aconsejado por James Highsmith 26 - de acuerdo a la duración del proyecto, hasta obtener el producto final acorde a los 41
requerimientos establecidos. establecidos . PLAN DE CICLOS DE DESARROLLO ADAPTABLE
Una vez definido el número de ciclos, se realizó el plan de ciclos de desarrollo adaptable (ver Anexo A Plan de Ciclos de Desarrollo Adaptable Framework), aquí se siguieron los siguientes pasos 27, se definió una misión ya que el ciclo de vida del desarrollo adaptable, debe estar enfocado en esta, después se definieron los marcos de tiempo de cada ciclo de trabajo lo l o cual dependió de los componentes que se desarrollarían en cada uno de ellos. Se definió un objetivo para cada uno de los ciclos, y un entregable para cada uno de ellos, de igual manera se definieron las herramientas tecnológicas que se usarían y cada uno de los componentes que se desarrollaría en cada uno de los ciclos, por p or último, se definió una lista de actividades act ividades que cubriría todo el proyecto. Para finalizar el documento se definió defi nió un cronograma tentativo para cada una de las actividades. Este plan de desarrollo de ciclos fue sometido a varias revisiones, ya que el desarrollo adaptable de software se desarrolla de una forma iterativa, esto nos ayudo a controlar los cambios que fueron surgiendo en el proyecto, en este caso surgieron varios cambios debido al poco conocimiento que se tenia sobre el tema al iniciar el proyecto. El desarrollo adaptable de software permite seleccionar cualquier estándar para el desarrollo de las aplicaciones, ya que se enfoca en la administración de software, y no en una metodología de desarrollo específica. Para la documentación nos basamos en los estándares de la IEEE, y se manejo un control de versiones para cada uno de ellos. Después de definido y aprobado el plan de ciclos de desarrollo adaptable, empezaron los ciclos y las actividades definidas allí.
42
ANALISIS
Primero se empezó con el ciclo de análisis de la aplicación, este ciclo nos plantea las siguientes actividades: Definir el dominio del Framework : Esta actividad es muy importante, ya que aquí se definió el alcance a nivel funcional que tendrá nuestro Framework , además este factor es de vital importancia para el éxito del desarrollo ya que es imposible intentar cubrir todos los requerimientos de todas las aplicaciones en todos los dominios 28. Análisis de Requerimientos: Después de observar varias tiendas de comercio electrónico, en Latinoamérica y en el mundo (DeRemate.com, ebay, exitovirtual.com, TowerRecords, Amazon) se sacó una lista preliminar de requerimientos de acuerdo a la funcionalidad y transaccionalidad que manejan en común estas tiendas. Esta lista se fue refinando, a medida que avanzaba el proyecto.
Los requerimientos obtenidos fueron los siguientes: Agregar o eliminar productos productos del carro carro de compras compras o Agregar o Agregar Agregar o modificar modificar productos productos del sistema sistema Agregar Tipos de Tarjeta o Agregar Consultar detalle orden de compra o Consultar Inventario de productos o o Consultar ordenes de compra Consultar productos o Consultar clientes o o Desactivar clientes no deseados Generar una orden de compra o Modificar el stock de productos del inventario (Agregar o Disminuir) o o Modificar información del cliente Registrar la fecha de backup de la información o Registrar una orden de compra enviada o Registrar usuarios en el sistema o o Seleccionar forma de pago Validación y autenticación de usuarios o Ver los detalles del producto o Manejar Carro de Compras o o El tiempo de respuesta deberá ser menor a 7 segundos El tiempo de disponibilidad de la base de datos deberá ser de un 90% anual. o Deberá soportar hasta 1000 clientes al mismo tiempo. o o El sistema deberá ser seguro, confiable y protegido.
43
Después de esto se identificaron los actores del sistema, estos fueron el administrador y el cliente.
Diagrama de Casos de Uso
En este punto se definieron los casos de uso de la aplicación en su primera versión de acuerdo a los requerimientos obtenidos, y se documentaron de acuerdo a la plantilla de Alistair Cockburn. 29.
44
Para una información mas detallada acerca del análisis del Framework (Ver Anexo B Análisis Framework). Con esto se finalizo el segundo ciclo, del desarrollo del Framework , este ciclo fue revisado y corregido a medida que se fueron implementando los otros ciclos. DISEÑO
El tercer ciclo de la aplicación, se dedicó al diseño de Framework , en esta etapa se definió el modelo de datos que se usaría, la arquitectura del sistema, y los diagramas de clases correspondientes a la aplicación. Las actividades que se llevaron a cabo en este ciclo son las siguientes: Definición Modelo de Datos: De De acuerdo a los requerimientos definidos en el ciclo de análisis se diseño un modelo de datos para la aplicación, en este se especificaron las entidades y sus correspondientes relaciones. El modelo de datos puede verse a continuación.
45
Arquitectura del Framework : Para este desarrollo utilizaremos una arquitectura J2EE, se escogió este tipo debido a que es una de las arquitecturas mas utilizadas para el desarrollo de aplicaciones empresariales de e-commerce. Esta arquitectura nos provee: Un modelo de desarrollo de aplicaciones basado en componentes component es Un modelo de desarrollo de aplicaciones distribuidas o basado en múltiple capas y multired. o Esta constituido por un conjunto de tecnologías estándar, Servlets, EJB, JSP etc. De acuerdo con esto tendríamos la siguiente arquitectura (Ilustración 4): o
46
En este diagrama tenemos que nuestro cliente accedería al sistema por medio de el Business Delegate para obtener la lógica del negocio del sistema, esto puede ser mediante interfaces graficas, JSP dependiendo de las necesidades del cliente, es decir nos da acceso a los servicios del negocio, este a su vez hace una petición al ServiceLocator el cual es el encargado de ubicar los servicios, este realiza la conexión con la tienda (SessionEJB), Tienda es de tipo Stateless y Carro de compras StateFul , debido a que necesitamos que este guarde su estado dependiendo de la sesión (cliente), es decir necesitamos que los productos que estén en el carro de algún cliente se mantengan si se presenta algún problema en la sesión (error de conexión), estos productos se eliminarán una vez el cliente haya terminado su sesión. A su vez el Session Tienda se comunica con un Session Cliente y un Session administrador dependiendo la clase de usuario, estos dos Session a su vez se comunican y administran los Entities Cliente, Administrador, Tarjeta, Orden de compra y ProductoFisico, encargados de la comunicación con la Base de Datos. El producto depende depen de del tipo de producto que se quiera vender, es decir es configurable según las necesidades del cliente. Además dependiendo dependiendo del servicio servicio que se necesite la tienda puede acceder a la base de datos mediante un DAO, el cual es el encargado de realizar consultas, y/o peticiones ( Querys) que no pueden hacer los EntitiesEJB. En el caso del Framework este producto es configurable, además que no tiene que ser solo uno pueden ser varios, por lo cual el usuario debe implementar tantos BMP EntitiesEJB como productos desee vender en su tienda, todo esto depende de las necesidades del usuario. De la misma forma la Base de datos que se vaya usar también es configurable por parte del cliente según el motor de Base de Datos que se vaya a utilizar, como Oracle, SQL Server, Point Base etc. También es necesario que al utilizar el Framework se defina y utilice un Servidor de Aplicaciones (Application Server) acorde a las necesidades del usuario, tales como JBoss, Sun One Application Server, Websphere etc. En cada uno de estos debe configurarse una fuente de datos (DataSource), un correspondiente Pool de conexiones (Connection Pool) y un administrador de persistencia (Persistence Manager), con el fin de 47
que la aplicación pueda acceder a la Base de Datos. Además de esto el servidor de aplicaciones esta encargado de realizar el Despliegue (‘deploy’ ) de la aplicación. El Framework cuenta con una clase, NombreReferencia, la cual nos permite configurar los JNDI Names, de la aplicación. Patrones: Con el fin de fortalecer el diseño y la implementación de la aplicación, se seleccionó una serie de patrones acorde al desarrollo del Framework . Dentro de estos patrones se encuentran:
Business Delegate Para la aplicación se utilizó una clase Business Delegate 30 la cual es la encargada de proporcionar el acceso a la lógica del negocio, esta a su vez es la encargada de comunicarse con el Session tienda. El cliente utiliza a esta clase para acceder a todos los métodos de la lógica del negocio. o
Service Locator Es el encargado de realizar las conexiones entre los Beans, la base de datos, Data Source, y demás componentes que requieran un servicio. o
Data Access Object (DAO) Estas son varias clases ya que se implementa de acuerdo a las tablas a las cuales se va a acceder. Son los encargados de realizar las consultas y Querys, las cuales no puedan ser manejadas por los Entity Beans. o
Factory (ProductoCreator) Esta clase permite crear varias clases de productos específicos a través de la herencia de la clase producto. Para este, las clases de productos específicos que se vayan a crear deben extender de la clase producto, la cual maneja unos atributos y métodos generales de los productos. o
Módulos: El sistema se dividió en 4 módulos de acuerdo a su funcionalidad, la interfaz cliente, la interfaz administrador, la tienda, y el carro de compras, correspondientes a ClienteMgr 48
Bean, AdministradorMgr Bean, TiendaMgr Bean y KartMgr Bean respectivamente.
Diagrama de Clases: Para el diseño de las clases se siguió la metodología propuesta por Bernd Bruegge en su libro Ingeniería de Software Orientada a Objetos 31, la cual nos dice que deben definirse unas entidades correspondientes a la aplicación y de acuerdo a las entidades definidas, se construyó un diagrama de clase que podemos ver en el disco anexo en la carpeta de gráficos.
49
REFERENCIAS: Fernando Alonso Amo. (2005). Introducción a la Ingeniería de Software. España: Delta María Isabel Alfonso Galipienso. (2005). Ingeniería del software. Madrid: Pearson. Guillermo Pantaleo. (2016). Ingeniería de Software. Argentina: Alfaomega.
50
