Documento de Arquitectura

de Software

VERSIÓN 0.3

Dirigido a:
Ingeniera luisa Fernanda barrera león

Autor:
Katherine Espíndola Buitrago

PONTIFICIA UNIVERSIDAD JAVERIANA

Departamento de ingeniería de sistemas
Bogotá, Colombia
Noviembre, 2015

Documento de Arquitectura de Software 1

 Historial de cambios
SECCIÓN DEL DESCRIPCIÓN DE
VERSIÓN FECHA RESPONSABLE
DOCUMENTO CAMBIOS
Documento de
13 de
Arquitectura de Creación estructura del
Noviembre Katherine Espíndola
Software documento.
de 2015
versión 0.1
Documento de Adición sección 1
19 de
Arquitectura de Adición sección 2
Noviembre 1, 2, 3, 4 Katherine Espíndola
Software Adición sección 3
de 2015
versión 0.2 Adición sección 4
Documento de
16 de
Arquitectura de Modificación sección 3
Diciembre de 3, 4 Katherine Espíndola
Software Modificación sección 4
2015
versión 0.3

Documento de Arquitectura de Software 2

Tabla de contenido
Historial de cambios ............................................................................................................................ 2

Introducción ........................................................................................................................................ 5

1. Diseño ......................................................................................................................................... 5

2. Restricciones Técnicas y de negocio ........................................................................................... 7

3. Representación Arquitectural ...................................................................................................... 8

3.1. Drivers de la Arquitectura ................................................................................................... 8

3.2. Funcionalidades Encapsuladas ............................................................................................ 8

3.3. Representación Contextual .................................................................................................. 9

3.4. Estilo arquitectónico.......................................................................................................... 10

3.5. Overview de la Arquitectura ............................................................................................. 10

4. Vistas ......................................................................................................................................... 11

4.1. Casos de Uso ..................................................................................................................... 11

4.2. Vista Lógica ...................................................................................................................... 13

4.3. Vista Implementación ....................................................................................................... 14

4.4. Vista de Despliegue........................................................................................................... 17

Trabajos citados ................................................................................................................................ 18

Documento de Arquitectura de Software 3

Figuras
Figura 1: El método ABD en el Ciclo de Vida.................................................................................... 5
Figura 2: Modelo “4+1” de Kruchten ................................................................................................. 6
Figura 3: Preferencia de despliegue de los stakeholders ..................................................................... 7
Figura 4: Funcionalidades encapsuladas de Know&Share.................................................................. 9
Figura 5: Representación contextual de Know&Share........................................................................ 9
Figura 6: Arquitectura Cliente – Servidor ......................................................................................... 10
Figura 7: Overview de la arquitectura ............................................................................................... 10
Figura 8: Actores ............................................................................................................................... 11
Figura 9: Diagrama de Casos de Uso ................................................................................................ 12
Figura 10: Vista Lógica ..................................................................................................................... 13
Figura 11: Vista de Implementación. Los colores y las convenciones realizar la trazabilidad de los
componentes a los casos de uso (ver sección 4.1). ............................................................................ 14
Figura 12: Priorización de Componentes Arquitectónicos................................................................ 16
Figura 13: Vista de Despliegue ......................................................................................................... 17

Tablas
Tabla 1: Funcionamiento Aval de Profesores y Estudiantes ............................................................. 15

Documento de Arquitectura de Software 4

 Introducción
Este documento presenta el diseño de la arquitectura de Know&Share, en el cual se documentan las
decisiones arquitectónicas por medio de las vistas del sistema donde se identifican componentes y las
interacciones entre sí.

1. Diseño
Para el diseño de la arquitectura de Know&Share se adaptó el método de Diseño Basado en
Arquitectura (ABD) [1] el cual provee una estructura para producir la arquitectura de conceptual de
un sistema. Este método depende de determinar los drivers arquitecturales del sistema (ver sección
3.1)

El método ABD tiene tres fundamentos:

 Descomposición de funcionalidad
 Realización de requerimientos de calidad y negocio a través de la elección de un estilo
arquitectónico
 El uso de plantillas de software

Figura 1: El método ABD en el Ciclo de Vida

Como lo evidencia la Figura 1, el método ABD asume que la fase de requerimientos esta al menos
parcialmente completa, la cual incluye los requerimientos descritos en el Anexo L. La salida del
método ABD es una colección de componentes conceptual en tres vistas: lógica, concurrencia y

Documento de Arquitectura de Software 5

despliegue, pero para este proyecto se utilizan las vistas definidas en el modelo “4+1” de Kruchten
[2] omitiendo la vista de procesos como se muestra en la Figura 2.

Figura 2: Modelo “4+1” de Kruchten

Los pasos del método ABD adaptados para este proyecto son:

1. Encapsular funcionalidad (ver sección 3.2)

2. Escoger un estilo arquitectural (ver sección 3.4)
3. Asignar funcionalidad al estilo elegido (ver sección 3.5)
4. Generar vista lógica (ver sección 4.2)
5. Generar vista de implementación (ver sección 4.3)
6. Generar vista despliegue (ver sección 4.4)

Documento de Arquitectura de Software 6

2. Restricciones Técnicas y de negocio
En esta sección presenta las restricciones técnicas y de negocio de la arquitectura de Know&Share.

 Restricciones de negocio: Debido a que Know&Share realiza recomendaciones basadas en

el perfil del usuario, este proyecto tiene las mismas restricciones de los sistemas de
recomendación como lo son: el problema del nuevo usuario, el problema de la escasez, el
exceso de la especialización y el análisis limitado al contenido. Por otro lado, teniendo en
cuenta la Figura 3, Know&Share debe permitir el acceso desde dispositivos móviles y
computadores.

¿Preferiría que la red social fuera para móvil o para PC?

77%
80%
72% 72%

70%

60%

50%

40%

30%

19% 19%
20%
11% 11%
9% 9%
10%

0%
Móvil PC Ambas

Profesores Estudiantes Egresados

Figura 3: Preferencia de despliegue de los stakeholders

 Restricciones técnicas: Teniendo en cuenta la representación de la información de

Know&Share, la información de cada usuario debe almacenarse en un archivo XML. Por lo
tanto, Know&Share debe contar con un repositorio centralizado en donde se almacenen todos
los archivos de los usuarios. Por otro lado, la autenticación de usuarios debe ser por medio
del directorio activo de la Pontificia Universidad Javeriana.

Documento de Arquitectura de Software 7

3. Representación Arquitectural
Esta sección detalla cómo se representa la arquitectura de Know&Share:

 Representación Contextual: representa el sistema completo como una entidad o proceso

único e identifica las interfaces entre el sistema y las entidades externas [3].
 Overview de la Arquitectura: provee una visión global de los elementos claves de la
arquitectura, como los principales elementos estructurales, comportamientos importantes y
decisiones significantes [3].

Adicionalmente esta sección presenta los drivers de la arquitectura, las funcionalidades encapsuladas
y el estilo arquitectónico seleccionado.

3.1. Drivers de la Arquitectura

Los drivers de la arquitectura se identificaron en la justificación del problema que Know&Share
soluciona, estos son:

 Permitir la divulgación de ideas de temas de trabajo de grado para que el estudiante pueda
elegir un tema de manera informada.
 Permitir la creación de una red de conocimiento personal la cual permita la co creación de
ideas entre expertos y principiantes, de tal forma que se cree un espacio de cooperación
interdisciplinar colombiano de expresión propia que propicie el dialogo y debate donde se
puedan divulgar, compartir y buscar ideas de temas de trabajo de grado.
 Ofrecer servicios personalizados de tal forma que se pueda asegurar la relevancia de
Know&Share.

3.2. Funcionalidades Encapsuladas

Para encapsular las funcionalidades, cada uno de los requerimientos (ver Anexo L) fueron asociados
a los bloques de construcción de la social media, las características de redes sociales y de los
ambientes para compartir conocimiento materializando así los conceptos del mapa de integración
conceptual de Know&Share. Teniendo en cuenta lo anterior, en la Figura 4 se puede ver la división
de las funcionalidades.

Documento de Arquitectura de Software 8

 Figura 4: Funcionalidades encapsuladas de Know&Share

3.3. Representación Contextual

En la Figura 5 se presenta el diagrama de contexto del sistema. Know&Share interactúa con 5
entidades, las cuales se explican a continuación:

 Dispositivo Móvil: dispositivos móviles desde los cuales se puede acceder a Know&Share.
 PC: computador personal desde el cual se puede acceder a Know&Share.
 Pontificia Universidad Javeriana: En este entorno encontramos los actores del sistema, es
decir, el estudiante, profesor y egresado.

Figura 5: Representación contextual de Know&Share

Documento de Arquitectura de Software 9

 3.4. Estilo arquitectónico
Teniendo en cuenta la representación contextual y las funcionalidades encapsuladas esta sección
presenta el estilo arquitectónico seleccionado para la arquitectura de Know&Share. El estilo
seleccionado para Know&Share es cliente – servidor (ver Figura 6) [4] debido a que el sistema será
accedido por la población estudiantil y profesorado de la Pontificia Universidad Javeriana desde
múltiples ubicaciones así como desde diferentes dispositivos. Adicionalmente, en cada componente
se utilizara un estilo por capas [5] donde se asignará las funcionalidades encapsuladas.

Figura 6: Arquitectura Cliente – Servidor

3.5. Overview de la Arquitectura

Teniendo en cuenta las funcionalidades encapsuladas de la sección anterior, esta sección presenta el
overview de la arquitectura (ver Figura 7), donde se han asignado las funcionalidades al estilo
arquitectónico seleccionado en la sección 3.4.

Figura 7: Overview de la arquitectura

Documento de Arquitectura de Software 10

Como se puede ver en la Figura 7, en el servidor se definieron tres capas: presentación, lógica y
acceso a datos. Como se puede ver en la capa lógica se asignaron los servicios ofrecidos por
Know&Share.

4. Vistas
Esta sección presenta las vistas de la arquitectura de Know&Share: vista de casos de uso (ver sección
4.1), vista lógica (ver sección 4.2), vista de implementación (ver sección 4.3), y vista de despliegue
(ver sección 4.4).

4.1. Casos de Uso

Esta sección presenta los casos de uso de Know&Share. El diagrama de casos de uso [6] permitió
formalizar el Modelo de Integración Conceptual y de dominio en forma de funcionalidades como lo
muestra la Figura 9. Adicionalmente, en la Figura 8 se pueden visualizar los actores del sistema.

Figura 8: Actores

Cabe resaltar que cada uno de los colores y las convenciones en el diagrama están asociados a un
componente de la arquitectura (ver sección 4.3), lo que permite realizar la trazabilidad de estos a los
casos de uso.

Documento de Arquitectura de Software 11

 Figura 9: Diagrama de Casos de Uso

Documento de Arquitectura de Software 12

 4.2. Vista Lógica
La vista lógica (ver Figura 10) permite visualizar que el estilo arquitectónico seleccionado en la
sección 3.4 es el que domina la arquitectura. Por un lado se puede ver que al cliente se le asignó un
componente de validación de datos, por otro lado, se puede ver que en el servidor, se le asignó a la
capa lógica los servicios tanto estándar como personalizados de Know&Share.

Figura 10: Vista Lógica

Documento de Arquitectura de Software 13

 4.3. Vista Implementación
En la vista de implementación (ver Figura 11) se puede ver la descomposición de componentes
descrita en la sección 3.2 de los servicios de Know&Share.

Figura 11: Vista de Implementación. Los colores y las convenciones realizar la trazabilidad de los componentes a
los casos de uso (ver sección 4.1).

Documento de Arquitectura de Software 14

Como se puede ver en la Figura 11, al Cliente se le asignó un subsistema de validación de los datos,
el cual se encarga de confirmar que los valores ingresados por el usuario sean compatibles con la
representación de la información. Por otro lado, a la Capa Lógica del Servidor se le asignó el
subsistema de servicios estándar y el de servicios personalizados, el cual se le asignaron el
componente de usuarios y el de ideas, los cuales permiten ofrecer los servicios personalizados de
Know&Share definidos por el sistema de reglas. Con respecto a los servicios estándar, se le asignaron
8 componentes, descritos a continuación:

 Identidad: le permite al usuario registrar y almacenar toda la información relacionada con el

Perfil de Usuario.
 Seguridad: se encarga de la autenticación y autorización de usuarios.
 Contenido generado por el usuario: le permite al usuario divulgar sus ideas describiéndolas
por medio de tags como se estableció en el Modelo de Idea. Además le permite crear
habilidades para estudiantes y cualidades para profesores.
 Herramientas: le permite al usuario editar y visualizar su perfil así como el de otros usuarios.
 Comunicación entre iguales: le permite al usuario compartir y retroalimentar las ideas de
otros por medio de comentarios.
 Gamification: se encarga de motivar el uso de Know&Share según lo establecido en el
Modelo de Gamification. Teniendo esto en cuenta, este componente se divide en 3
subcomponentes:
 Status: se encarga de crear el leaderboard de carreras, así como los rankings
semestrales de estudiantes y profesores, de los cuales dependen las insignias
especiales. Además, permite la visualización de lights de una idea.
 Poder: le permite al usuario visualizar el número de amigos y de seguidores de todos
los usuarios.
 Acceso y Herramientas: le permite al usuario avalar las características de otros
usuarios de acuerdo con lo determinado en la Tabla 1.

Usuario Cualidad/Habilidad Avalado por

Como Profesor Estudiante
Profesor Como Profesional Profesor
Como Director Egresado
Profesionales Profesor
Estudiante
Personales Estudiante

Tabla 1: Funcionamiento Aval de Profesores y Estudiantes

Documento de Arquitectura de Software 15

  Conectar expertos y principiantes: le permite al usuario agregar nodos relevantes
(siguiendo a otro usuario) y de confianza (enviando una solicitud de amistad) a su red de
conocimiento personal. Para esto, utiliza el subcomponente de recomendación de usuarios
que se encarga de sugerir usuarios dependiendo de la distancia entre ellos.
 Buscar conocimiento: le permite al usuario buscar conocimiento, es decir, usuarios e ideas.
Para esto, hace uso de los subcomponentes de búsquedas personalizadas, es decir, el
subcomponente de búsqueda de usuarios y búsqueda de ideas.

De acuerdo con la descripción de cada uno de los subsistemas y componentes de la vista de

implementación, se puede ver que cada uno de estos materializar los conceptos del Error! Reference
source not found. de tal forma que la arquitectura pueda satisfacer los drivers arquitectónicos
definidos en la sección 3.1. Cabe resaltar que debido al bajo acoplamiento entre los componentes la
arquitectura podrá ser modificada cuando surjan nuevos requerimientos. Por otro lado, la Figura 12
permite ver la priorización de los componentes mencionados previamente teniendo en cuenta la
priorización de los requerimientos asociados a cada uno de estos. De la figura se puede concluir que
los componentes más críticos son: identidad, conectar expertos y principiantes, contenido generado
por el usuario y recomendación de usuarios.

Priorización de Componentes Arquitectónicos

Must Have Should Have Could Have Won’t Have this time
Identidad
Recomendación de ideas Seguridad

Contenido generado por el

Búsqueda de ideas
usuario

Recomendación de usuarios Herramientas

Búsqueda de usuarios Comunicación entre iguales

Acceso y Herramientas Buscar conocimiento

Conectar expertos y
Poder
principiantes
Status

Figura 12: Priorización de Componentes Arquitectónicos

Documento de Arquitectura de Software 16

 4.4. Vista de Despliegue
En la Figura 13 se puede ver el estilo arquitectónico cliente – servidor en el cual se pueden visualizar
las capas y los componentes asignados a cada una.

Figura 13: Vista de Despliegue

Documento de Arquitectura de Software 17

Trabajos citados

[1] F. Bachmann, L. Bass, G. Chastek, P. Donohoe y F. Peruzzi, The architecture based design
method, CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING
INST, 2000.

[2] P. Kruchten, Architectural Blueprints - The "4+1" View Model of Software Architecture,
Rational Software Corp..

[3] P. Eeles, The process of software architecting, Addison-Wesley, 2010.

[4] R. N. Taylor, N. Medvidovic y E. M. Dashofy, Software Architecture: Foundations, Theory, and

Practice, John Wiley & Sons, Inc, 2008.

[5] F. Buschmann, R. Meunier, H. Rohnert, P. Sornmerlad y M. Stal, Pattern-Oriented Software

Architecture: A System of Patterns, John'Wiley & Sons Ltd., 2001.

[6] G. Booch, Rumbaught y I. Jacobson, UML: El Lenguaje Unificado de Modelado, Addison-

Wesley, 2006.

[7] DSDM Consortium, «MoSCoW Prioritisation,» 2015. [En línea]. Available:

http://www.dsdm.org/content/10-moscow-prioritisation. [Último acceso: 10 06 2015].

[8] I. Gorton, Essential Software Architecture, Springer, 2006.

Documento de Arquitectura de Software 18