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 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 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 relacionada
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. 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 Software
Development” de acuerdo a la duración del proyecto), 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, 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 veremos el proceso de desarrollo adaptable de 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 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.

o Segunda iteración 20/08/2004

A medida que se obtuvo más información acerca del 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.

o 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.

o 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 Quinta iteración 16/10/2004
Se corrigieron algunas actividades y componentes de los ciclos de
análisis, diseño e implementación.

o Sexta iteración 18/10/2004

Corrección de algunas de las actividades y componentes de los ciclos
de implementación.

o 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 Primera iteración 24/09/2004

Se realizó una primera versión del documento (borrador) propuesto en
el 1 ciclo

o 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

o Tercera iteración 02/10/2004

Se corrigió la documentación de los casos de uso y se cambio el
tiempo de respuesta

o Cuarta iteración 04/10/2004

Se agregaron comentarios referentes al desarrollo del Framework, se
corrigió documentación de los casos de uso

o 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

o Sexta iteración 11/10/2004

Se corrigieron errores en la documentación

o 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 Primera iteración 26/10/2004

Se realizó una primera versión del documento (borrador) propuesto en
el 1 ciclo
o Segunda iteración 28/10/2004
Se completo la descomposición por entidades
o Tercera iteración 31/10/2004
Se agregaron más entidades, y una descripción de componentes J2EE
o Cuarta iteración 10/11/2004
Se agrego el modelo de datos y su documentación, se corrigieron
algunos errores en la arquitectura
o Quinta iteración 11/11/2004
Se corrigió el modelo de
datos
o Sexta iteración 20/11/2004
Se agregaron componentes J2EE (SessionsEJB y EntitiesEJB) y
Patrones de Software a la arquitectura
o 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
o Octava iteración
24/11/2004 Se corrigió el
modelo de datos

o Novena iteración 26/11/2004

Se cambio el diagrama de arquitectura, y cambio el diagrama de
componentes J2EE

o 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 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

o Segunda iteración 18/11/2004

Se corrigieron errores de configuración del Service Locator
o Tercera iteración 22/11/2004
Se corrigieron errores de conectividad del Service Locator
o Cuarta iteración 26/11/2004
Se implementaron los Session EJB y las bases de datos
o 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
o Sexta iteración 15/12/2004
Se corrigieron problemas en la funcionalidad de los Session Bean
o Séptima iteración 20/012005
Se modificaron algunos atributos de las tablas debido a
desbordamiento de información
o 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 Primera iteración 28/11/2004

Se implementaron las clases DAO, los Entities CMP y la clase
Business Delegate

o Segunda iteración 3/12/2004

Se corrigieron errores de conectividad y consultas en los DAO

40
 o Tercera iteración 10/12/2004
Se corrigieron errores en la transaccionalidad de los CMP
o Cuarta iteración 15/12/2004
Se agregaron métodos a la clase Business Delegate
o Quinta iteración 07/01/2005
Se integraron todos los componentes del Framework y la lógica del negocio
o 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.

o Primera iteración 08/01/2005

Se realizó una primera versión del documento (borrador) propuesto
en el 1 ciclo
o Segunda iteración 22/01/2005
Se realizaron el manual de usuario y el manual de instalación y
configuración
o Tercera iteración 25/01/2005
Se realizó la guía de extensión del Framework
o Cuarta iteración 30/01/2005
Se cambio la estructura de algunas pruebas
o Quinta iteración 15/02/2005
Se corrigieron errores en los manuales y la guía del Framework

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 FRAMEWORK

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 Highsmith26 - de
acuerdo a la duración del proyecto, hasta obtener el producto final acorde a los
41
requerimientos 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 pasos27, 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 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 último, se definió una lista de actividades
que cubriría todo el proyecto.

Para finalizar el documento se definió 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 dominios28.
 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:

o Agregar o eliminar productos del carro de compras
o Agregar o modificar productos del sistema
o Agregar Tipos de Tarjeta
o Consultar detalle orden de compra
o Consultar Inventario de productos
o Consultar ordenes de compra
o Consultar productos
o Consultar clientes
o Desactivar clientes no deseados
o Generar una orden de compra
o Modificar el stock de productos del inventario (Agregar o Disminuir)
o Modificar información del cliente
o Registrar la fecha de backup de la información
o Registrar una orden de compra enviada
o Registrar usuarios en el sistema
o Seleccionar forma de pago
o Validación y autenticación de usuarios
o Ver los detalles del producto
o Manejar Carro de Compras
o El tiempo de respuesta deberá ser menor a 7 segundos
o 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 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 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:

o Un modelo de desarrollo de aplicaciones basado en componentes

o Un modelo de desarrollo de aplicaciones distribuidas
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):

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 del tipo de producto que se quiera
vender, es decir es configurable según las necesidades del cliente.
Además dependiendo del 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:

o Business Delegate
Para la aplicación se utilizó una clase Business Delegate30 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.

 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 Objetos31, 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