historial de cambios - trabajos de grado de la...

Documento de Arquitectura de Software

VERSIÓN 0.3

Dirigido a:Ingeniera luisa Fernanda barrera león

Autor:Katherine Espíndola Buitrago

PONTIFICIA UNIVERSIDAD JAVERIANADepartamento de ingeniería de sistemas

Bogotá, ColombiaNoviembre, 2015

Documento de Arquitectura de Software 1

Historial de cambios

VERSIÓN FECHASECCIÓN DEL DOCUMENTO

DESCRIPCIÓN DE CAMBIOS

RESPONSABLE

Documento de Arquitectura de Software versión 0.1

13 de Noviembre de 2015

Creación estructura del documento.

Katherine Espíndola


19 de Noviembre de 2015

1, 2, 3, 4

Adición sección 1Adición sección 2Adición sección 3Adición sección 4



16 de Diciembre de 2015

3, 4Modificación sección 3Modificación sección 4



Tabla de contenidoHistorial 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


FigurasFigura 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

TablasTabla 1: Funcionamiento Aval de Profesores y Estudiantes..............................................................15


IntroducciónEste 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ñoPara 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


http://pegasus.javeriana.edu.co/~CIS1530IN01/TG/Anexos/Anexo%20L.%20Software%20Requirement%20Specification%20V.0.2.xlsx

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)


2. Restricciones Técnicas y de negocioEn 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.

Móvil PC Ambas0%

10%

20%

30%

40%

50%

60%

70%

80%

19%

9%

72%

19%

9%

72%

11% 11%

77%

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

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.


3. Representación ArquitecturalEsta 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 ArquitecturaLos 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 EncapsuladasPara 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.


http://pegasus.javeriana.edu.co/~CIS1530IN01/TG/Anexos/Anexo%20D.%20Modelo%20De%20Integraci%C3%B3n%20Conceptual/MapaIntegracionNivel4%20V.0.6.png


http://pegasus.javeriana.edu.co/~CIS1530IN01/TG/Anexos/Anexo%20L.%20Software%20Requirement%20Specification%20V.0.2.xlsx

Figura 4: Funcionalidades encapsuladas de Know&Share

3.3. Representación ContextualEn 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


3.4. Estilo arquitectónicoTeniendo 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 ArquitecturaTeniendo 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


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. VistasEsta 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 UsoEsta 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.



Figura 9: Diagrama de Casos de Uso


4.2. Vista LógicaLa 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


4.3. Vista ImplementaciónEn 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).


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

ProfesorComo Profesor EstudianteComo Profesional ProfesorComo Director Egresado

EstudianteProfesionales ProfesorPersonales Estudiante

Tabla 1: Funcionamiento Aval de Profesores y Estudiantes


http://pegasus.javeriana.edu.co/~CIS1530IN01/TG/Anexos/Anexo%20E.%20Modelo%20de%20Dominio/Modelo%20de%20Gamification%20V.0.3.png

http://pegasus.javeriana.edu.co/~CIS1530IN01/TG/Anexos/Anexo%20E.%20Modelo%20de%20Dominio/Modelo%20de%20Idea%20V.0.6.png

http://pegasus.javeriana.edu.co/~CIS1530IN01/TG/Anexos/Anexo%20E.%20Modelo%20de%20Dominio/Perfil%20de%20Usuario%20V.0.3.png

http://pegasus.javeriana.edu.co/~CIS1530IN01/TG/Anexos/Anexo%20K.%20Sistema%20de%20Reglas%20V.0.3.pdf

http://pegasus.javeriana.edu.co/~CIS1530IN01/TG/Anexos/Anexo%20J.%20Ontologia/Grafo%20RDF%20V.0.5.png

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.

IdentidadSeguridad

Contenido generado por el usuario

Herramientas

Comunicación entre iguales

Buscar conocimiento

Conectar expertos y principiantesStatus

Poder

Acceso y Herramientas

Búsqueda de usuarios

Recomendación de usuarios

Búsqueda de ideas

Recomendación de ideas

Priorización de Componentes Arquitectónicos

Must Have Should Have Could Have Won’t Have this time

Figura 12: Priorización de Componentes Arquitectónicos


4.4. Vista de DespliegueEn 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


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.


historial de cambios - trabajos de grado de la...

Documents