Historial de cambios - Trabajos de Grado de la...
Transcript of 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
Documento de Arquitectura de Software versión 0.2
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
Katherine Espíndola
Documento de Arquitectura de Software versión 0.3
16 de Diciembre de 2015
3, 4Modificación sección 3Modificación sección 4
Katherine Espíndola
Documento de Arquitectura de Software 2
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
Documento de Arquitectura de Software 3
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
Documento de Arquitectura de Software 4
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
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 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.
Documento de Arquitectura de Software 7
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.
Documento de Arquitectura de Software 8
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
Documento de Arquitectura de Software 9
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
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. 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.
Documento de Arquitectura de Software 11
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
Documento de Arquitectura de Software 13
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).
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
ProfesorComo Profesor EstudianteComo Profesional ProfesorComo Director Egresado
EstudianteProfesionales ProfesorPersonales 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.
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
Documento de Arquitectura de Software 16
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
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