1 Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano http://zenon.etsii.urjc.es/grupo/docencia/as

2 Content Curso 09-10/Ing. Inf./Arquitectura del Software/ 2 Introducción Vistas de ejecución Modelos de la aplicación

3 Normativa de referencia

4 Curso 09-10/Ing. Inf./Arquitectura del Software/ 4 Normativa de referencia

5 Requisitos funcionales Las universidades son instituciones de enseñanza superior en las que se imparten titulaciones de grado y postgrado en distintas áreas de conocimiento. Para conseguir un título universitario en determinado plan de estudios los miembros de la comunidad deben matricularse en la correspondiente carrera de grado o máster. Las carreras de grado son gestionadas por una escuela o facultad de la universidad. Los másteres son gestionados por la escuelas o facultades, en el caso de másteres de orientación profesional, o por los departamentos de la universidad, en el caso de másteres asociados a un programa de doctorado. Los planes de estudios de las distintas titulaciones (de grado o posgrado) se estructuran en varios niveles, cada uno de los cuales consta de varias asignaturas (obligatorias, optativas y de libre elección) que tienen asignado un número determinado de créditos. Para superar la carrera los alumnos deben obtener una calificación de apto en todas la asignaturas obligatorias y superar un determinado número de créditos optativos y de libre elección. Los departamentos o facultades pueden nombrar coordinadores de distinto tipo para facilitar la gestión de las carreras.

6 Requisitos funcionales Cada curso académico, los alumnos se matriculan en los cursos donde se imparten las asignaturas que desean aprobar ese año. Para ello, los alumnos deberán superar las pruebas teóricas y prácticas especificadas por los profesores de la asignatura. Los profesores preparan a los alumnos para superar dichas pruebas por medio de clases teóricas y prácticas llevadas a cabo en las aulas docentes y laboratorios, respectivamente. Asimismo, los alumnos (individualmente o en grupo) pueden celebrar tutorías con los profesores, normalmente de forma presencial en sus despachos. Para cada práctica y examen los profesores deben definir el enunciado que establece los objetivos a alcanzar por los alumnos así como las normas de evaluación de la prueba correspondiente (plazos de entrega, puntuaciones parciales, etc.). Las pruebas teóricas suelen ser individuales y se realizan a través de una examinación presencial bajo la atenta vigilancia de los profesores. Por el contrario, las pruebas prácticas suelen ser realizadas por grupos de varias personas sin la presencia del evaluador; una vez realizadas, éstas son remitidas para su evaluación a los profesores responsables de la práctica. Una vez publicados los resultados de la evaluación (tanto de exámenes como prácticas), los alumnos disponen de un plazo de tiempo para solicitar la revisión de los mismos.

7 Requisitos funcionales Los profesores de una asignatura para el curso académico siguiente son elegidos por los departamentos responsables de la impartición de dicha asignatura antes de que finalice el curso académico actual. Los profesores elegidos deberán ser miembros del departamento (profesores ayudantes, colaboradores, contratados doctores, titulares de universidad o escuela universitaria, catedráticos, etc.). La aprobación del plan de ordenación docente se lleva a cabo en reunión del consejo de departamento a propuesta de su director. Los coordinadores de nivel, grado o máster también son elegidos entre los miembros de los departamentos (a iniciativa del director de escuela en el caso de los grados y másteres profesionales). La ordenación académica de toda la universidad es responsabilidad última del vicerrectorado correspondiente, cuyo vicerrector es nombrado por el rector de la universidad a propuesta del consejo de gobierno de la misma.

8 Curso 09-10/Ing. Inf./Arquitectura del Software/ 8 Content Introducción Vistas de ejecución Espacio de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Acciones comunicativas Atributos Eventos

9 Espacio de interacciones :ConsejoGobierno :Comunidad :Universidad :Escuela :Departamento :Vicerrectorado :Grado:MásterProf :MásterInv :ProgramaDoct :ConsejoDpt :Curso :Examen :Práctica :Evaluación :Revisión o :Reunión :Tutoría:Clase :GrupoTrabajo :CursoAcadémico :Examinación :Revisión :Matricula 9

10 Curso 09-10/Ing. Inf./Arquitectura del Software/ 10 Content Introducción Vistas de ejecución Espacio de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Acciones comunicativas Atributos Eventos

11 Jerarquías de roles :Matricula :ConsejoGobierno :Comunidad :Universidad :Escuela :Departamento :Vicerrectorado :Grado:MásterProf:MásterInv :ProgramaDoct :ConsejoDpt :Curso :Examen :Práctica :Evaluación :Revisión o :Reunión :Tutoría:Clase :GrupoTrabajo :CursoAcadémico :Agente :Examinación :Revisión : Alumno : Remitente : Evaluado : Coordinador :Alumno

12 Jerarquías de roles :Matricula :ConsejoGobierno :Comunidad :Universidad :Escuela :Departamento :Vicerrectorado :Grado:MásterProf:MásterInv :ProgramaDoct :ConsejoDpt :Curso :Examen :Práctica :Evaluación :Revisión o :Reunión :Tutoría:Clase :GrupoTrabajo :CursoAcadémico :Agente :Examinación :Revisión :Profesor : Evaluador : Revisor : Profesor : Vigilante : Evaluador : Tutor : Instructor

13 Jerarquías de roles :Departamento :Matricula :ConsejoGobierno :Comunidad :Universidad :Escuela :Vicerrectorado :Grado:MásterProf:MásterInv :ProgramaDoct :ConsejoDpt :Curso :Examen :Práctica :Evaluación :Revisión o :Reunión :Tutoría:Clase :GrupoTrabajo :CursoAcadémico :Agente :Examinación :Revisión : TEU :Profesor : Coordinador : TU : CU : Rector : Vicerrector : Director : Asistente : MiembroNato

14 Curso 09-10/Ing. Inf./Arquitectura del Software/ 14 Content Introducción Vistas de ejecución Espacio de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Acciones comunicativas Atributos Eventos

15 Recursos del entorno :Departamento :Matricula :ConsejoGobierno :Comunidad :Universidad :Escuela :Vicerrectorado :Grado:MásterProf:MásterInv :ProgramaDoct :ConsejoDpt :Curso :Examen :Práctica :Evaluación :Revisión o :Reunión :Tutoría:Clase :GrupoTrabajo :CursoAcadémico :Examinación :Revisión :Título :PlanEstudios :Asignatura :Calificación :Prueba :Aula :Laboratorio :Despacho :Enunciado :Títulación :Calificación

16 Curso 09-10/Ing. Inf./Arquitectura del Software/ 16 Content Introducción Vistas de ejecución Espacio de interacciones Modelo de la aplicación Jerarquía de roles Recursos del entorno Acciones comunicativas Atributos Eventos

17 Atributos estándar cam: Comunidad upm.cam: Universidad urjc.cam: Universidad escet.urjc.cam: Escuela etsii.urjc.cam: Escuela iinf.etsii.urjc.cam: Carrera {state= open, context= etsii.urjc.es, member= a 1,...,sub= 08-09.iinf.etsii.urjc.cam,... } 08-09.iinf.etsii.urjc.cam: CursoAcadémico : PCChair mar.08-09.iinf.etsii.urjc.cam: Curso as.08-09.iinf.etsii.urjc.cam: Curso {state= open, context= 08-09..., member= a 1 @as...,...} pp1.as....: Práctica a1@iinf...:Alumno : Enunciado a n : Alumno state= playing context= iinf... player= a 1 @cam satisfied= false a1@cam:Agente state= playing, context= cam, role= a 1 @iinf.... state= abandoned satisfied= true a 1 @as.08-09....: Alumno state= playing satisfied= false state= playing player= [email protected] [email protected]....: Profesor state= playing player= [email protected] [email protected]....: Profesor state= created creator= jms@as.. [email protected]...: Profesor Use Module" class="image_link uk-text-large uk-margin-small-left uk-margin-small-right"> 33 Modelos UML Los modelos UML editados con la ayuda del perfil Speech y la herramienta MagicDraw se encuentran almacenados en los ficheros fuente universidad.mdzip y grupo.mdzip El primero de ellos contiene la jerarquía global de interacciones, así como los tipos de agentes y recursos principales El segundo contiene los modelos de detalle correspondientes a los grupos de prácticas Tal y como se indica en las siguientes figuras, el fichero universidad.mdzip importa el módulo Grupo contenido en el fichero grupo.mdzip y, vicerversa, el fichero grupo.mdzip importa el módulo Universidad definido en el fichero universidad.mdzip De esta manera, ambos modelos pueden hacer referencia a los elementos de modelado incluidos en los dos ficheros (evitando al mismo tiempo las limitaciones de la versión de evaluación de la herramienta) Obsérvese también que cada fichero importa el módulo speech- profile.mdzip, el cual contiene la definición del perfil Speech Importar un módulo definido en otro fichero: File -> Use Module { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_33.jpg", "name": "Modelos UML Los modelos UML editados con la ayuda del perfil Speech y la herramienta MagicDraw se encuentran almacenados en los ficheros fuente universidad.mdzip y grupo.mdzip El primero de ellos contiene la jerarquía global de interacciones, así como los tipos de agentes y recursos principales El segundo contiene los modelos de detalle correspondientes a los grupos de prácticas Tal y como se indica en las siguientes figuras, el fichero universidad.mdzip importa el módulo Grupo contenido en el fichero grupo.mdzip y, vicerversa, el fichero grupo.mdzip importa el módulo Universidad definido en el fichero universidad.mdzip De esta manera, ambos modelos pueden hacer referencia a los elementos de modelado incluidos en los dos ficheros (evitando al mismo tiempo las limitaciones de la versión de evaluación de la herramienta) Obsérvese también que cada fichero importa el módulo speech- profile.mdzip, el cual contiene la definición del perfil Speech Importar un módulo definido en otro fichero: File -> Use Module", "description": "Modelos UML Los modelos UML editados con la ayuda del perfil Speech y la herramienta MagicDraw se encuentran almacenados en los ficheros fuente universidad.mdzip y grupo.mdzip El primero de ellos contiene la jerarquía global de interacciones, así como los tipos de agentes y recursos principales El segundo contiene los modelos de detalle correspondientes a los grupos de prácticas Tal y como se indica en las siguientes figuras, el fichero universidad.mdzip importa el módulo Grupo contenido en el fichero grupo.mdzip y, vicerversa, el fichero grupo.mdzip importa el módulo Universidad definido en el fichero universidad.mdzip De esta manera, ambos modelos pueden hacer referencia a los elementos de modelado incluidos en los dos ficheros (evitando al mismo tiempo las limitaciones de la versión de evaluación de la herramienta) Obsérvese también que cada fichero importa el módulo speech- profile.mdzip, el cual contiene la definición del perfil Speech Importar un módulo definido en otro fichero: File -> Use Module", "width": "800" } 34 Modelos UML Curso 09-10/Ing. Inf./Arquitectura del Software/ 34 universidad.mdzip grupo.mdzip { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_34.jpg", "name": "Modelos UML Curso 09-10/Ing. Inf./Arquitectura del Software/ 34 universidad.mdzip grupo.mdzip", "description": "Modelos UML Curso 09-10/Ing. Inf./Arquitectura del Software/ 34 universidad.mdzip grupo.mdzip", "width": "800" } 35 Modelos de la aplicación Los modelos incluidos en ambos paquetes se encuentran organizados en base a una jerarquía de paquetes UML estructurados de la siguiente manera: Por regla general, todos los elementos de modelado asociados a un tipo de entidad social se encuentran incluidos en un paquete UML con el mismo nombre que el tipo El paquete se puede omitir en caso de que el único elemento incluido en él sea el actor, caso de uso o clase que representa el tipo de entidad social Los modelos de los tipos de entidades sociales definidos en el ámbito de un contexto de interacción determinado serán incluidos en un sub-paquete del paquete asociado al contexto de interacción A excepción de los definidos en un fichero distinto { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_35.jpg", "name": "Modelos de la aplicación Los modelos incluidos en ambos paquetes se encuentran organizados en base a una jerarquía de paquetes UML estructurados de la siguiente manera: Por regla general, todos los elementos de modelado asociados a un tipo de entidad social se encuentran incluidos en un paquete UML con el mismo nombre que el tipo El paquete se puede omitir en caso de que el único elemento incluido en él sea el actor, caso de uso o clase que representa el tipo de entidad social Los modelos de los tipos de entidades sociales definidos en el ámbito de un contexto de interacción determinado serán incluidos en un sub-paquete del paquete asociado al contexto de interacción A excepción de los definidos en un fichero distinto", "description": "Modelos de la aplicación Los modelos incluidos en ambos paquetes se encuentran organizados en base a una jerarquía de paquetes UML estructurados de la siguiente manera: Por regla general, todos los elementos de modelado asociados a un tipo de entidad social se encuentran incluidos en un paquete UML con el mismo nombre que el tipo El paquete se puede omitir en caso de que el único elemento incluido en él sea el actor, caso de uso o clase que representa el tipo de entidad social Los modelos de los tipos de entidades sociales definidos en el ámbito de un contexto de interacción determinado serán incluidos en un sub-paquete del paquete asociado al contexto de interacción A excepción de los definidos en un fichero distinto", "width": "800" } 36 Modelos de la aplicación Los diagramas asociados a los distintos tipos de entidad serán incluidos en un sub-paquete denominado Diagrams Los diagramas globales asociados a un tipos de interacción social (es decir, relativos a esa interacción y a todas sus sub-interacciones) se incluirán en el sub-paquete Diagrams de la interacción social Las propiedades visuales de los elementos de modelado se pueden configurar en MagicDraw mediante ficheros de estilo Los diagramas contenidos en los ficheros universidad.mdzip y grupo.mdzip se encuentran formateados con las definiciones de estilo definidas en el fichero speech.stl Importar un fichero de estilo: Options -> Projects -> Symbols Properties Style Los diagramas pueden ilustrar uno o varios aspectos de la definición del tipo de entidad social Por ejemplo, un diagrama para un tipo de interacción social podría centrarse en las circunstancias de inicio (actos de habla SetUp, reglas automáticas de inicio, atributos de entrada, etc.); otro podría centrarse en las condiciones de finalización (reglas para el acto de habla Close, reglas de finalización automáticas, atributos de salida, etc.); y, por último, otro podría centrarse en las restricciones estructurales (tipos de miembros, recursos del entorno, sub-interacciones, etc.) No hay, sin embargo, ninguna regla fija para la organización de los diagramas { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_36.jpg", "name": "Modelos de la aplicación Los diagramas asociados a los distintos tipos de entidad serán incluidos en un sub-paquete denominado Diagrams Los diagramas globales asociados a un tipos de interacción social (es decir, relativos a esa interacción y a todas sus sub-interacciones) se incluirán en el sub-paquete Diagrams de la interacción social Las propiedades visuales de los elementos de modelado se pueden configurar en MagicDraw mediante ficheros de estilo Los diagramas contenidos en los ficheros universidad.mdzip y grupo.mdzip se encuentran formateados con las definiciones de estilo definidas en el fichero speech.stl Importar un fichero de estilo: Options -> Projects -> Symbols Properties Style Los diagramas pueden ilustrar uno o varios aspectos de la definición del tipo de entidad social Por ejemplo, un diagrama para un tipo de interacción social podría centrarse en las circunstancias de inicio (actos de habla SetUp, reglas automáticas de inicio, atributos de entrada, etc.); otro podría centrarse en las condiciones de finalización (reglas para el acto de habla Close, reglas de finalización automáticas, atributos de salida, etc.); y, por último, otro podría centrarse en las restricciones estructurales (tipos de miembros, recursos del entorno, sub-interacciones, etc.) No hay, sin embargo, ninguna regla fija para la organización de los diagramas", "description": "Modelos de la aplicación Los diagramas asociados a los distintos tipos de entidad serán incluidos en un sub-paquete denominado Diagrams Los diagramas globales asociados a un tipos de interacción social (es decir, relativos a esa interacción y a todas sus sub-interacciones) se incluirán en el sub-paquete Diagrams de la interacción social Las propiedades visuales de los elementos de modelado se pueden configurar en MagicDraw mediante ficheros de estilo Los diagramas contenidos en los ficheros universidad.mdzip y grupo.mdzip se encuentran formateados con las definiciones de estilo definidas en el fichero speech.stl Importar un fichero de estilo: Options -> Projects -> Symbols Properties Style Los diagramas pueden ilustrar uno o varios aspectos de la definición del tipo de entidad social Por ejemplo, un diagrama para un tipo de interacción social podría centrarse en las circunstancias de inicio (actos de habla SetUp, reglas automáticas de inicio, atributos de entrada, etc.); otro podría centrarse en las condiciones de finalización (reglas para el acto de habla Close, reglas de finalización automáticas, atributos de salida, etc.); y, por último, otro podría centrarse en las restricciones estructurales (tipos de miembros, recursos del entorno, sub-interacciones, etc.) No hay, sin embargo, ninguna regla fija para la organización de los diagramas", "width": "800" } 37 Modelos de la aplicación Curso 09-10/Ing. Inf./Arquitectura del Software/ 37 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_37.jpg", "name": "Modelos de la aplicación Curso 09-10/Ing. Inf./Arquitectura del Software/ 37", "description": "Modelos de la aplicación Curso 09-10/Ing. Inf./Arquitectura del Software/ 37", "width": "800" } 38 Curso 09-10/Ing. Inf./Arquitectura del Software/ 38 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_38.jpg", "name": "Curso 09-10/Ing.", "description": "Inf./Arquitectura del Software/ 38 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso.", "width": "800" } 39 Jerarquía de interacciones sociales (I) Curso 09-10/Ing. Inf./Arquitectura del Software/ 39 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_39.jpg", "name": "Jerarquía de interacciones sociales (I) Curso 09-10/Ing. Inf./Arquitectura del Software/ 39", "description": "Jerarquía de interacciones sociales (I) Curso 09-10/Ing. Inf./Arquitectura del Software/ 39", "width": "800" } 40 Jerarquía de interacciones sociales (II) Curso 09-10/Ing. Inf./Arquitectura del Software/ 40 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_40.jpg", "name": "Jerarquía de interacciones sociales (II) Curso 09-10/Ing. Inf./Arquitectura del Software/ 40", "description": "Jerarquía de interacciones sociales (II) Curso 09-10/Ing. Inf./Arquitectura del Software/ 40", "width": "800" } 41 Curso 09-10/Ing. Inf./Arquitectura del Software/ 41 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_41.jpg", "name": "Curso 09-10/Ing.", "description": "Inf./Arquitectura del Software/ 41 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso.", "width": "800" } 42 Jerarquías de agentes (I) Curso 09-10/Ing. Inf./Arquitectura del Software/ 42 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_42.jpg", "name": "Jerarquías de agentes (I) Curso 09-10/Ing. Inf./Arquitectura del Software/ 42", "description": "Jerarquías de agentes (I) Curso 09-10/Ing. Inf./Arquitectura del Software/ 42", "width": "800" } 43 Jerarquías de agentes (II) Curso 09-10/Ing. Inf./Arquitectura del Software/ 43 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_43.jpg", "name": "Jerarquías de agentes (II) Curso 09-10/Ing. Inf./Arquitectura del Software/ 43", "description": "Jerarquías de agentes (II) Curso 09-10/Ing. Inf./Arquitectura del Software/ 43", "width": "800" } 44 Jerarquías de agentes (III) Curso 09-10/Ing. Inf./Arquitectura del Software/ 44 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_44.jpg", "name": "Jerarquías de agentes (III) Curso 09-10/Ing. Inf./Arquitectura del Software/ 44", "description": "Jerarquías de agentes (III) Curso 09-10/Ing. Inf./Arquitectura del Software/ 44", "width": "800" } 45 Curso 09-10/Ing. Inf./Arquitectura del Software/ 45 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_45.jpg", "name": "Curso 09-10/Ing.", "description": "Inf./Arquitectura del Software/ 45 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso.", "width": "800" } 46 Recursos de la comunidad (I) Curso 09-10/Ing. Inf./Arquitectura del Software/ 46 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_46.jpg", "name": "Recursos de la comunidad (I) Curso 09-10/Ing. Inf./Arquitectura del Software/ 46", "description": "Recursos de la comunidad (I) Curso 09-10/Ing. Inf./Arquitectura del Software/ 46", "width": "800" } 47 Recursos de la comunidad (II) Curso 09-10/Ing. Inf./Arquitectura del Software/ 47 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_47.jpg", "name": "Recursos de la comunidad (II) Curso 09-10/Ing. Inf./Arquitectura del Software/ 47", "description": "Recursos de la comunidad (II) Curso 09-10/Ing. Inf./Arquitectura del Software/ 47", "width": "800" } 48 Curso 09-10/Ing. Inf./Arquitectura del Software/ 48 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_48.jpg", "name": "Curso 09-10/Ing.", "description": "Inf./Arquitectura del Software/ 48 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso.", "width": "800" } 49 La creación de un grupo de trabajo dentro del contexto de una práctica sólo puede ser llevada a cabo por un alumno que no haya aprobado aún la práctica, ni participe ya en ningún otro grupo de trabajo. Asimismo, para que la declaración pueda ser ejecutada el enunciado de la práctica debe haber sido publicado y no haber finalizado el plazo de entrega. Con respecto a su finalización, ésta se produce cuando se dan una de las dos circunstancias siguientes: (1) el grupo de trabajo se queda sin miembros; (2) el plazo de entrega de la práctica vence y los alumnos no han remitido aún la práctica para su evaluación. De acuerdo con la especificación del resto del sistema, la primera situación puede producirse por el abandono voluntario de todos los miembros del grupo (antes del vencimiento del plazo de entrega), o por la obtención de la calificación definitiva (una vez pasada la fecha de entrega). La finalización de un grupo de trabajo también puede ser forzada mediante la ejecución de una declaración de cierre por parte de uno de los profesores responsables de la práctica. La ejecución de esta declaración no requiere el cumplimiento de ninguna circunstancia especial. Grupos de prácticas Inicio y finalización { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_49.jpg", "name": "La creación de un grupo de trabajo dentro del contexto de una práctica sólo puede ser llevada a cabo por un alumno que no haya aprobado aún la práctica, ni participe ya en ningún otro grupo de trabajo.", "description": "Asimismo, para que la declaración pueda ser ejecutada el enunciado de la práctica debe haber sido publicado y no haber finalizado el plazo de entrega. Con respecto a su finalización, ésta se produce cuando se dan una de las dos circunstancias siguientes: (1) el grupo de trabajo se queda sin miembros; (2) el plazo de entrega de la práctica vence y los alumnos no han remitido aún la práctica para su evaluación. De acuerdo con la especificación del resto del sistema, la primera situación puede producirse por el abandono voluntario de todos los miembros del grupo (antes del vencimiento del plazo de entrega), o por la obtención de la calificación definitiva (una vez pasada la fecha de entrega). La finalización de un grupo de trabajo también puede ser forzada mediante la ejecución de una declaración de cierre por parte de uno de los profesores responsables de la práctica. La ejecución de esta declaración no requiere el cumplimiento de ninguna circunstancia especial. Grupos de prácticas Inicio y finalización.", "width": "800" } 50 Grupos de prácticas Inicio { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_50.jpg", "name": "Grupos de prácticas Inicio", "description": "Grupos de prácticas Inicio", "width": "800" } 51 Grupos de prácticas Finalización URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 51 Curso 09-10/Ing. Inf./Arquitectura del Software/ { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_51.jpg", "name": "Grupos de prácticas Finalización URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 51 Curso 09-10/Ing.", "description": "Inf./Arquitectura del Software/.", "width": "800" } 52 Grupos de trabajo Atributos y restricciones estructurales Los grupos de trabajo son procesos con las siguientes restricciones estructurales: (1) sólo pueden desarrollar su actividad en el contexto de una práctica de un curso; (2) deben ser iniciadas obligatoriamente por un alumno del curso, al que se denominará fundador; (3) sólo pueden participar en él alumnos del curso, uno como mínimo y tres como máximo; el fundador del grupo no tiene por qué ser uno de los participantes (es decir, el fundador podría abandonar el grupo si así lo desea); (4) los roles que desempeñan los alumnos del curso en el contexto del grupo de trabajo deben ser del tipo Grupo::Alumno; (5) en el entorno del grupo de trabajo sólo se podrá crear la solución de la práctica; y (6) las únicas sub- interacciones que se pueden crear en el contexto del grupo de prácticas son las relativas a las invitaciones de nuevos miembros del grupo. Por otra parte, además de los atributos estándar comunes a todo tipo de interacción, el estado de los grupos de práctica se caracteriza también por el atributo local booleano entregada, el cual indica si los alumnos del grupo han remitido la práctica para su evaluación { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_52.jpg", "name": "Grupos de trabajo Atributos y restricciones estructurales Los grupos de trabajo son procesos con las siguientes restricciones estructurales: (1) sólo pueden desarrollar su actividad en el contexto de una práctica de un curso; (2) deben ser iniciadas obligatoriamente por un alumno del curso, al que se denominará fundador; (3) sólo pueden participar en él alumnos del curso, uno como mínimo y tres como máximo; el fundador del grupo no tiene por qué ser uno de los participantes (es decir, el fundador podría abandonar el grupo si así lo desea); (4) los roles que desempeñan los alumnos del curso en el contexto del grupo de trabajo deben ser del tipo Grupo::Alumno; (5) en el entorno del grupo de trabajo sólo se podrá crear la solución de la práctica; y (6) las únicas sub- interacciones que se pueden crear en el contexto del grupo de prácticas son las relativas a las invitaciones de nuevos miembros del grupo.", "description": "Por otra parte, además de los atributos estándar comunes a todo tipo de interacción, el estado de los grupos de práctica se caracteriza también por el atributo local booleano entregada, el cual indica si los alumnos del grupo han remitido la práctica para su evaluación.", "width": "800" } 53 Grupos de trabajo Atributos y restricciones estructurales Curso 09-10/Ing. Inf./Arquitectura del Software/ 53 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_53.jpg", "name": "Grupos de trabajo Atributos y restricciones estructurales Curso 09-10/Ing.", "description": "Inf./Arquitectura del Software/ 53.", "width": "800" } 54 Curso 09-10/Ing. Inf./Arquitectura del Software/ 54 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_54.jpg", "name": "Curso 09-10/Ing.", "description": "Inf./Arquitectura del Software/ 54 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso.", "width": "800" } 55 Alumnos de grupos de trabajo Reglas de desempeño URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 55 El primer miembro de un grupo de trabajo es creado automáticamente para su fundador en el momento del inicio del grupo. El resto de miembros serán creados por medio de dos mecanismos principales: las invitaciones y las declaraciones de unión (Join). Las reglas que gobiernan el proceso de invitaciones para participar en un grupo de trabajo se encontrarían definidas por medio del tipo de interacción social Grupo::Invitation. Con respecto a las declaraciones de unión, los únicos agentes capacitados para realizar este tipo de acto de habla son todos aquellos alumnos del curso que no hayan aprobado aún la práctica y que no participen ya en ningún otro grupo. Si un alumno que cumpla estas condiciones realiza una declaración de este tipo, se pueden dar dos circunstancias: (1) si el plazo de entrega ya ha finalizado o el número de miembros del grupo es igual al máximo permitido, se prohibirá automáticamente la ejecución de la declaración; (2) en otro caso, el acto de habla quedará pendiente de ejecución hasta que uno cualquiera de los miembros actuales del grupo permita (Allow) o prohíba (Forbid) explícitamente la ejecución del mismo 55 Curso 09-10/Ing. Inf./Arquitectura del Software/ { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_55.jpg", "name": "Alumnos de grupos de trabajo Reglas de desempeño URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 55 El primer miembro de un grupo de trabajo es creado automáticamente para su fundador en el momento del inicio del grupo.", "description": "El resto de miembros serán creados por medio de dos mecanismos principales: las invitaciones y las declaraciones de unión (Join). Las reglas que gobiernan el proceso de invitaciones para participar en un grupo de trabajo se encontrarían definidas por medio del tipo de interacción social Grupo::Invitation. Con respecto a las declaraciones de unión, los únicos agentes capacitados para realizar este tipo de acto de habla son todos aquellos alumnos del curso que no hayan aprobado aún la práctica y que no participen ya en ningún otro grupo. Si un alumno que cumpla estas condiciones realiza una declaración de este tipo, se pueden dar dos circunstancias: (1) si el plazo de entrega ya ha finalizado o el número de miembros del grupo es igual al máximo permitido, se prohibirá automáticamente la ejecución de la declaración; (2) en otro caso, el acto de habla quedará pendiente de ejecución hasta que uno cualquiera de los miembros actuales del grupo permita (Allow) o prohíba (Forbid) explícitamente la ejecución del mismo 55 Curso 09-10/Ing. Inf./Arquitectura del Software/.", "width": "800" } 56 Alumnos de grupos de trabajo Reglas de desempeño URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 56 Curso 09-10/Ing. Inf./Arquitectura del Software/ { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_56.jpg", "name": "Alumnos de grupos de trabajo Reglas de desempeño URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 56 Curso 09-10/Ing.", "description": "Inf./Arquitectura del Software/.", "width": "800" } 57 Alumnos de grupos de trabajo Restricciones estructurales URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 57 Los agentes del tipo Grupo::Alumno solamente pueden ser miembros de un grupo de trabajo, y solamente pueden ser desempeñados por alumnos de un curso; además, un alumno de un curso no puede desempeñar más de un rol de este tipo en el contexto de un mismo grupo de trabajo. El propósito de cualquier miembro de un grupo de trabajo es aprobar la prueba práctica asociada al grupo de trabajo. Para conseguir este propósito, además de estar capacitados para crear soluciones de la práctica (de acuerdo a la especificación del tipo de recurso Grupo::Solución), los miembros de un grupo pueden desempeñar dos tipos de roles: el rol de Inviter en el contexto de una invitación a otro alumno o el rol Evaluación::Alumno en el contexto de la evaluación de la práctica. En el primer caso, el número de invitaciones que puede realizar un miembro del grupo, y por tanto el número de roles de ese tipo que puede desempeñar, es indeterminado; en el segundo, dicho rol será desempeñado solamente en caso de que la práctica sea remitida para su evaluación. 57 Curso 09-10/Ing. Inf./Arquitectura del Software/ { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_57.jpg", "name": "Alumnos de grupos de trabajo Restricciones estructurales URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 57 Los agentes del tipo Grupo::Alumno solamente pueden ser miembros de un grupo de trabajo, y solamente pueden ser desempeñados por alumnos de un curso; además, un alumno de un curso no puede desempeñar más de un rol de este tipo en el contexto de un mismo grupo de trabajo.", "description": "El propósito de cualquier miembro de un grupo de trabajo es aprobar la prueba práctica asociada al grupo de trabajo. Para conseguir este propósito, además de estar capacitados para crear soluciones de la práctica (de acuerdo a la especificación del tipo de recurso Grupo::Solución), los miembros de un grupo pueden desempeñar dos tipos de roles: el rol de Inviter en el contexto de una invitación a otro alumno o el rol Evaluación::Alumno en el contexto de la evaluación de la práctica. En el primer caso, el número de invitaciones que puede realizar un miembro del grupo, y por tanto el número de roles de ese tipo que puede desempeñar, es indeterminado; en el segundo, dicho rol será desempeñado solamente en caso de que la práctica sea remitida para su evaluación. 57 Curso 09-10/Ing. Inf./Arquitectura del Software/.", "width": "800" } 58 Alumnos de grupos de trabajo Restricciones estructurales URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 58 Curso 09-10/Ing. Inf./Arquitectura del Software/ { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_58.jpg", "name": "Alumnos de grupos de trabajo Restricciones estructurales URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 58 Curso 09-10/Ing.", "description": "Inf./Arquitectura del Software/.", "width": "800" } 59 Alumnos de grupos de trabajo Reglas de abandono URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 59 De acuerdo con la especificación del tipo Practica::Grupo, si los alumnos no entregan la práctica antes del vencimiento del plazo correspondiente el proceso finalizará automáticamente y con ello los miembros del grupo. Por otra parte, el alumno de un curso tiene la posibilidad de abandonar un grupo de trabajo antes de que venza el plazo de entrega, siempre y cuando no haya entregado aún la práctica. En caso de que los alumnos entreguen la práctica, la función de un alumno en el grupo sólo finalizará cuando finalice su evaluación, es decir, cuando finalice el desempeño de su rol Evaluación::Alumno. Este rol finalizará únicamente cuando se asigne una calificación al alumno para la práctica entregada, de acuerdo con la especificación de su atributo de salida calificación. 59 Curso 09-10/Ing. Inf./Arquitectura del Software/ { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_59.jpg", "name": "Alumnos de grupos de trabajo Reglas de abandono URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 59 De acuerdo con la especificación del tipo Practica::Grupo, si los alumnos no entregan la práctica antes del vencimiento del plazo correspondiente el proceso finalizará automáticamente y con ello los miembros del grupo.", "description": "Por otra parte, el alumno de un curso tiene la posibilidad de abandonar un grupo de trabajo antes de que venza el plazo de entrega, siempre y cuando no haya entregado aún la práctica. En caso de que los alumnos entreguen la práctica, la función de un alumno en el grupo sólo finalizará cuando finalice su evaluación, es decir, cuando finalice el desempeño de su rol Evaluación::Alumno. Este rol finalizará únicamente cuando se asigne una calificación al alumno para la práctica entregada, de acuerdo con la especificación de su atributo de salida calificación. 59 Curso 09-10/Ing. Inf./Arquitectura del Software/.", "width": "800" } 60 Alumnos de grupos de trabajo Reglas de abandono URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 60 Curso 09-10/Ing. Inf./Arquitectura del Software/ { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_60.jpg", "name": "Alumnos de grupos de trabajo Reglas de abandono URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 60 Curso 09-10/Ing.", "description": "Inf./Arquitectura del Software/.", "width": "800" } 61 61 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_61.jpg", "name": "61 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso", "description": "61 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso", "width": "800" } 62 Soluciones de prácticas URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 62 Las soluciones de prácticas son recursos que sólo pueden ser creados en el contexto de los grupos de prácticas. Asimismo, su creación sólo puede ser realizada por parte de los alumnos del grupo mediante las correspondientes declaraciones. La única restricción a la creación de soluciones en el contexto de un grupo viene dada por la especificación del tipo Práctica::Grupo, según la cual en un grupo de prácticas no puede haber más de un recurso de este tipo. Por tanto, si los alumnos quieren modificar una solución ya publicada, pueden destruir el recurso y volverlo a crear. Antes de la entrega de la práctica, los alumnos pueden crear y eliminar la solución todas las veces que quieran. Una vez entregada, por el contrario, cualquier intento de eliminar la solución quedará en suspenso a la espera de la correspondiente autorización del profesor responsable de la práctica 62 Curso 09-10/Ing. Inf./Arquitectura del Software/ { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.es/24/7267986/slides/slide_62.jpg", "name": "Soluciones de prácticas URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 62 Las soluciones de prácticas son recursos que sólo pueden ser creados en el contexto de los grupos de prácticas.", "description": "Asimismo, su creación sólo puede ser realizada por parte de los alumnos del grupo mediante las correspondientes declaraciones. La única restricción a la creación de soluciones en el contexto de un grupo viene dada por la especificación del tipo Práctica::Grupo, según la cual en un grupo de prácticas no puede haber más de un recurso de este tipo. Por tanto, si los alumnos quieren modificar una solución ya publicada, pueden destruir el recurso y volverlo a crear. Antes de la entrega de la práctica, los alumnos pueden crear y eliminar la solución todas las veces que quieran. Una vez entregada, por el contrario, cualquier intento de eliminar la solución quedará en suspenso a la espera de la correspondiente autorización del profesor responsable de la práctica 62 Curso 09-10/Ing. Inf./Arquitectura del Software/.", "width": "800" } 63 Soluciones de prácticas URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 63 Curso 09-10/Ing. Inf./Arquitectura del Software/

18 Curso 09-10/Ing. Inf./Arquitectura del Software/ 18 Atributos dependientes del dominio cam: Comunidad upm.cam: Universidad urjc.cam: Universidad escet.urjc.cam:Escuela etsii.urjc.cam: Escuela iinf.etsii.urjc.cam: Carrera {plan_estudios= pe 1 @etsii..., #egresados= 453,,... } 08-09.iinf.etsii.urjc.cam: CursoAcadémico mar.08-09.iinf.etsii.urjc.cam: Curso as.08-09.iinf.etsii.urjc.cam: Curso {asignatura= asig1@etsii...,...} pp1.as....: Práctica {prueba= pp1@as...,...} a1@iinf...:Alumno : Enunciado a n : Alumno #cr_tr= 186 #cr_obl= 97,5 #cr_opt= 42 #cr_le= 40,5 a1@cam:Agente nombre= “XXX” foto= “../mifoto.gif” título = “t1@cam” inicio= 03-04.iinf…, calificación= c 1 @03-04.iinf... calificación= c n @04-05.iinf... a 1 @as.08-09....: Alumno aprobó= pp 1 @as... aprobó= pp 2 @as... responsable_de= pp1@as... [email protected]....: Profesor responsable_de =pp2@as... [email protected]....: Profesor content =“…/pp1.pdf ” entrega= 15/4/09 [email protected]...: Profesor

19 Curso 09-10/Ing. Inf./Arquitectura del Software/ 19 Content Introducción Vistas de ejecución Espacio de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Acciones comunicativas Atributos Eventos

20 Acciones comunicativas Un alumno puede crear un grupo de prácticas mediante una declaración de tipo set up. Alternativamente, también podría tratar de unirse a grupos de prácticas ya existentes creados por otros compañeros mediante una declaración de tipo join. En este último caso, cualquier miembro del grupo puede permitir o prohibir su entrada (allow / forbid ). Por otra parte, cualquier miembro de un grupo de prácticas puede invitar (invite) a otros compañeros, los cuales pueden aceptar o rechazar la invitación (accept / decline). Un alumno podría abandonar un grupo de prácticas mediante una declaración de tipo leave. Con respecto al cierre de un grupo (close), los profesores de prácticas pueden forzar su cierre si así lo estiman conveniente. Los alumnos de un grupo de prácticas pueden crear la solución mediante una declaración del tipo create. Una vez creada la solución, pueden crear un proceso de evaluación (setup) y remitir la solución para que ésta sea evaluada por los profesores (submit). Los profesores, una vez creadas y revisadas las calificaciones correspondientes (create), notificarán a los alumnos de sus resultados (notify). Si estos no están de acuerdo con la evaluación, pueden iniciar un proceso de revisión (set up) y realizar la queja correspondiente (complain). El evaluador, una vez analizados los argumentos de los alumnos, realizará la notificación correspondiente de la revisión (notifiy).

21 Acciones comunicativas : Curso : Practica {publicado=true} : Grupo : Invitation :E valuación : Alumno : Calificación : Alumno : Inviter : Alumno : Invitee : SetUp : Alumno : Accept : Invite : Join : SetUp : Alumno : Join : Forbid : Allow : Solución : Create : Revisión : Evaluado : Submittee : Evaluador : Notify : Complain : Create : Submitter : Submit : SetUp : Profesor : Notify : Create : Publish : Enunciado : Leave

22 Procesamiento de attempts (unempowered) : Curso p 1 : Practica a 1 : Alumno :Component :Attempt performer= a 1 action=“... ” : Protocol rule=“Los alumnos que no hayan superado aún la prueba y no participen todavía en ningún grupo están capacitados para crear grupos de prácticas” aprobó(p 1 )=true empowered (“..” ) =false

23 Procesamiento de attempts (forbidden) : Curso p 1 : Practica {publicado=false} a 1 : Alumno α 1 : SetUp state= pending new= g 1 context= p 1 performer= a 1 permitted= false :Component :Attempt performer= a 1 action=“... ” : Protocol rule=“Los alumnos que no hayan superado aún la prueba y no participen todavía en ningún grupo están capacitados para crear grupos de prácticas” rule=“Se permite a un alumno crear un nuevo grupo de prácticas si el enunciado ha sido publicado y no ha vencido la fecha límite de entrega” aprobó(p 1 )=false empowered (“..” ) =true state= forbidden

24 Procesamiento de attempts (successful) : Curso p 1 : Practica {publicado=true} g 1 : Grupo {initiator=a 1 } a 1 : Alumno α 1 : SetUp state= pending new= g 1 context= p 1 performer= a 1 permitted= true :Component :Attempt performer= a 1, action=“... ” : Protocol rule=“Los alumnos que no hayan superado aún la prueba están capacitados para crear grupos de prácticas” rule=“Se permite a un alumno crear un nuevo grupo de prácticas si el enunciado ha sido publicado y no ha vencido la fecha límite de entrega” aprobó(p1)=false empowered (“..” ) =true :Initiate :Execute state= executed

25 Reglas de autorizaciones y permisos ACTIONEMPOWERMENTSPERMISSIONS Join a course as a student none- Set up a tutoring meeting with a course teacher Estudiantes del curso en el que imparte clase el profesor El profesor es el tutor designado para el alumno El estudiante no está participando actualmente en ninguna otra tutoría Set up a working group within an assignment process Estudiantes que no hayan aprobado aún la práctica y no participen todavía en ningún grupo El enunciado de la práctica ha sido publicado y el plazo para la entrega de soluciones no ha expirado aún Join a working group Estudiantes que no hayan aprobado aún la práctica no participen todavía en ningún grupo El plazo para la entrega de soluciones no ha expirado aún El número actual de miembros del grupo es inferior al máximo permitido

26 Reglas de autorizaciones y permisos ACTIONEMPOWERMENTSPERMISSIONS Alow/Forbid some student to join a working group Estudiantes del grupo de prácticas True (es decir, no hay restricciones de ningún tipo) Leave a working group El agente que desempeña el rol (condición predefinida) Si la práctica no ha sido remitida aún Close an assignment evaluation group Cualquier profesor responsable de la práctica True Leave a student role played within a course El agente que desempeña el rol (condición predefinida) Si no ha remitido ninguna práctica o participado en alguna examinación

27 Curso 09-10/Ing. Inf./Arquitectura del Software/ 27 Content Introducción Vistas de ejecución Espacio de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Acciones comunicativas Atributos Eventos

28 Publicación de eventos : Curso p 1 : Practica g 1 : Grupo a 1 : Alumno :Publish e1e1 e2e2 e3e3 α 1 : SetUp a 2 : Alumno :Publish 2008-02-02 T 15:05 g 1 member a 2 :Play :Initiate

29 Notificación de eventos : Curso : Practica a 1 : Alumno :Publish e1e1 :Notify α 1 : SetUp addressee= a 2 a 2 : Alumno event=e 1 :Notify : Protocol rule=“La realización de una acción comunicativa debe ser notificada al hablante y a todos los destinatarios”

30 Notificación de eventos : Curso p 1 : Practica g 1 : Grupo { initiator=a 1 event=e 1 } e1e1 :Publish : Profesor event=e 1 :Initiate a 1 : Alumno event=e 1 : Protocol rule=“Los profesores de prácticas monitorizan la creación y eliminación de grupos de prácticas” : Protocol rule=“El iniciador de una interacción debe ser notificado de su creación” : Protocol rule=“La creación de un grupo de prácticas conlleva la creación automática de un rol para su iniciador” :Notify

31 Procesamiento de eventos : Curso p 1 : Practica g 1 : Grupo { initiator=a 1 event=e 1 } e1e1 : Profesor event=e 1 a 1 : Alumno event=e 1 : Protocol rule=“La creación de un grupo de prácticas conlleva la creación automática de un rol para su iniciador” e1e1 :Component :Observe e1e1 :Component :Observe : Alumno :Play

32 Curso 09-10/Ing. Inf./Arquitectura del Software/ 32 Content Introducción Vistas de ejecución Modelos de la aplicación

33 Modelos UML Los modelos UML editados con la ayuda del perfil Speech y la herramienta MagicDraw se encuentran almacenados en los ficheros fuente universidad.mdzip y grupo.mdzip El primero de ellos contiene la jerarquía global de interacciones, así como los tipos de agentes y recursos principales El segundo contiene los modelos de detalle correspondientes a los grupos de prácticas Tal y como se indica en las siguientes figuras, el fichero universidad.mdzip importa el módulo Grupo contenido en el fichero grupo.mdzip y, vicerversa, el fichero grupo.mdzip importa el módulo Universidad definido en el fichero universidad.mdzip De esta manera, ambos modelos pueden hacer referencia a los elementos de modelado incluidos en los dos ficheros (evitando al mismo tiempo las limitaciones de la versión de evaluación de la herramienta) Obsérvese también que cada fichero importa el módulo speech- profile.mdzip, el cual contiene la definición del perfil Speech Importar un módulo definido en otro fichero: File -> Use Module

34 Modelos UML Curso 09-10/Ing. Inf./Arquitectura del Software/ 34 universidad.mdzip grupo.mdzip

35 Modelos de la aplicación Los modelos incluidos en ambos paquetes se encuentran organizados en base a una jerarquía de paquetes UML estructurados de la siguiente manera: Por regla general, todos los elementos de modelado asociados a un tipo de entidad social se encuentran incluidos en un paquete UML con el mismo nombre que el tipo El paquete se puede omitir en caso de que el único elemento incluido en él sea el actor, caso de uso o clase que representa el tipo de entidad social Los modelos de los tipos de entidades sociales definidos en el ámbito de un contexto de interacción determinado serán incluidos en un sub-paquete del paquete asociado al contexto de interacción A excepción de los definidos en un fichero distinto

36 Modelos de la aplicación Los diagramas asociados a los distintos tipos de entidad serán incluidos en un sub-paquete denominado Diagrams Los diagramas globales asociados a un tipos de interacción social (es decir, relativos a esa interacción y a todas sus sub-interacciones) se incluirán en el sub-paquete Diagrams de la interacción social Las propiedades visuales de los elementos de modelado se pueden configurar en MagicDraw mediante ficheros de estilo Los diagramas contenidos en los ficheros universidad.mdzip y grupo.mdzip se encuentran formateados con las definiciones de estilo definidas en el fichero speech.stl Importar un fichero de estilo: Options -> Projects -> Symbols Properties Style Los diagramas pueden ilustrar uno o varios aspectos de la definición del tipo de entidad social Por ejemplo, un diagrama para un tipo de interacción social podría centrarse en las circunstancias de inicio (actos de habla SetUp, reglas automáticas de inicio, atributos de entrada, etc.); otro podría centrarse en las condiciones de finalización (reglas para el acto de habla Close, reglas de finalización automáticas, atributos de salida, etc.); y, por último, otro podría centrarse en las restricciones estructurales (tipos de miembros, recursos del entorno, sub-interacciones, etc.) No hay, sin embargo, ninguna regla fija para la organización de los diagramas

37 Modelos de la aplicación Curso 09-10/Ing. Inf./Arquitectura del Software/ 37

38 Curso 09-10/Ing. Inf./Arquitectura del Software/ 38 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso

39 Jerarquía de interacciones sociales (I) Curso 09-10/Ing. Inf./Arquitectura del Software/ 39

40 Jerarquía de interacciones sociales (II) Curso 09-10/Ing. Inf./Arquitectura del Software/ 40

41 Curso 09-10/Ing. Inf./Arquitectura del Software/ 41 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso

42 Jerarquías de agentes (I) Curso 09-10/Ing. Inf./Arquitectura del Software/ 42

43 Jerarquías de agentes (II) Curso 09-10/Ing. Inf./Arquitectura del Software/ 43

44 Jerarquías de agentes (III) Curso 09-10/Ing. Inf./Arquitectura del Software/ 44

45 Curso 09-10/Ing. Inf./Arquitectura del Software/ 45 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso

46 Recursos de la comunidad (I) Curso 09-10/Ing. Inf./Arquitectura del Software/ 46

47 Recursos de la comunidad (II) Curso 09-10/Ing. Inf./Arquitectura del Software/ 47

48 Curso 09-10/Ing. Inf./Arquitectura del Software/ 48 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso

49 La creación de un grupo de trabajo dentro del contexto de una práctica sólo puede ser llevada a cabo por un alumno que no haya aprobado aún la práctica, ni participe ya en ningún otro grupo de trabajo. Asimismo, para que la declaración pueda ser ejecutada el enunciado de la práctica debe haber sido publicado y no haber finalizado el plazo de entrega. Con respecto a su finalización, ésta se produce cuando se dan una de las dos circunstancias siguientes: (1) el grupo de trabajo se queda sin miembros; (2) el plazo de entrega de la práctica vence y los alumnos no han remitido aún la práctica para su evaluación. De acuerdo con la especificación del resto del sistema, la primera situación puede producirse por el abandono voluntario de todos los miembros del grupo (antes del vencimiento del plazo de entrega), o por la obtención de la calificación definitiva (una vez pasada la fecha de entrega). La finalización de un grupo de trabajo también puede ser forzada mediante la ejecución de una declaración de cierre por parte de uno de los profesores responsables de la práctica. La ejecución de esta declaración no requiere el cumplimiento de ninguna circunstancia especial. Grupos de prácticas Inicio y finalización

50 Grupos de prácticas Inicio

51 Grupos de prácticas Finalización URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 51 Curso 09-10/Ing. Inf./Arquitectura del Software/

52 Grupos de trabajo Atributos y restricciones estructurales Los grupos de trabajo son procesos con las siguientes restricciones estructurales: (1) sólo pueden desarrollar su actividad en el contexto de una práctica de un curso; (2) deben ser iniciadas obligatoriamente por un alumno del curso, al que se denominará fundador; (3) sólo pueden participar en él alumnos del curso, uno como mínimo y tres como máximo; el fundador del grupo no tiene por qué ser uno de los participantes (es decir, el fundador podría abandonar el grupo si así lo desea); (4) los roles que desempeñan los alumnos del curso en el contexto del grupo de trabajo deben ser del tipo Grupo::Alumno; (5) en el entorno del grupo de trabajo sólo se podrá crear la solución de la práctica; y (6) las únicas sub- interacciones que se pueden crear en el contexto del grupo de prácticas son las relativas a las invitaciones de nuevos miembros del grupo. Por otra parte, además de los atributos estándar comunes a todo tipo de interacción, el estado de los grupos de práctica se caracteriza también por el atributo local booleano entregada, el cual indica si los alumnos del grupo han remitido la práctica para su evaluación

53 Grupos de trabajo Atributos y restricciones estructurales Curso 09-10/Ing. Inf./Arquitectura del Software/ 53

54 Curso 09-10/Ing. Inf./Arquitectura del Software/ 54 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso

55 Alumnos de grupos de trabajo Reglas de desempeño URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 55 El primer miembro de un grupo de trabajo es creado automáticamente para su fundador en el momento del inicio del grupo. El resto de miembros serán creados por medio de dos mecanismos principales: las invitaciones y las declaraciones de unión (Join). Las reglas que gobiernan el proceso de invitaciones para participar en un grupo de trabajo se encontrarían definidas por medio del tipo de interacción social Grupo::Invitation. Con respecto a las declaraciones de unión, los únicos agentes capacitados para realizar este tipo de acto de habla son todos aquellos alumnos del curso que no hayan aprobado aún la práctica y que no participen ya en ningún otro grupo. Si un alumno que cumpla estas condiciones realiza una declaración de este tipo, se pueden dar dos circunstancias: (1) si el plazo de entrega ya ha finalizado o el número de miembros del grupo es igual al máximo permitido, se prohibirá automáticamente la ejecución de la declaración; (2) en otro caso, el acto de habla quedará pendiente de ejecución hasta que uno cualquiera de los miembros actuales del grupo permita (Allow) o prohíba (Forbid) explícitamente la ejecución del mismo 55 Curso 09-10/Ing. Inf./Arquitectura del Software/

56 Alumnos de grupos de trabajo Reglas de desempeño URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 56 Curso 09-10/Ing. Inf./Arquitectura del Software/

57 Alumnos de grupos de trabajo Restricciones estructurales URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 57 Los agentes del tipo Grupo::Alumno solamente pueden ser miembros de un grupo de trabajo, y solamente pueden ser desempeñados por alumnos de un curso; además, un alumno de un curso no puede desempeñar más de un rol de este tipo en el contexto de un mismo grupo de trabajo. El propósito de cualquier miembro de un grupo de trabajo es aprobar la prueba práctica asociada al grupo de trabajo. Para conseguir este propósito, además de estar capacitados para crear soluciones de la práctica (de acuerdo a la especificación del tipo de recurso Grupo::Solución), los miembros de un grupo pueden desempeñar dos tipos de roles: el rol de Inviter en el contexto de una invitación a otro alumno o el rol Evaluación::Alumno en el contexto de la evaluación de la práctica. En el primer caso, el número de invitaciones que puede realizar un miembro del grupo, y por tanto el número de roles de ese tipo que puede desempeñar, es indeterminado; en el segundo, dicho rol será desempeñado solamente en caso de que la práctica sea remitida para su evaluación. 57 Curso 09-10/Ing. Inf./Arquitectura del Software/

58 Alumnos de grupos de trabajo Restricciones estructurales URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 58 Curso 09-10/Ing. Inf./Arquitectura del Software/

59 Alumnos de grupos de trabajo Reglas de abandono URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 59 De acuerdo con la especificación del tipo Practica::Grupo, si los alumnos no entregan la práctica antes del vencimiento del plazo correspondiente el proceso finalizará automáticamente y con ello los miembros del grupo. Por otra parte, el alumno de un curso tiene la posibilidad de abandonar un grupo de trabajo antes de que venza el plazo de entrega, siempre y cuando no haya entregado aún la práctica. En caso de que los alumnos entreguen la práctica, la función de un alumno en el grupo sólo finalizará cuando finalice su evaluación, es decir, cuando finalice el desempeño de su rol Evaluación::Alumno. Este rol finalizará únicamente cuando se asigne una calificación al alumno para la práctica entregada, de acuerdo con la especificación de su atributo de salida calificación. 59 Curso 09-10/Ing. Inf./Arquitectura del Software/

60 Alumnos de grupos de trabajo Reglas de abandono URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 60 Curso 09-10/Ing. Inf./Arquitectura del Software/

61 61 Content Introducción Vistas de ejecución Jerarquía de interacciones Modelos de la aplicación Jerarquía de roles Recursos del entorno Modelo detallado de un tipo de interacción social Modelo detallado de un tipo de agente Modelo detallado de un tipo de recurso

62 Soluciones de prácticas URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 62 Las soluciones de prácticas son recursos que sólo pueden ser creados en el contexto de los grupos de prácticas. Asimismo, su creación sólo puede ser realizada por parte de los alumnos del grupo mediante las correspondientes declaraciones. La única restricción a la creación de soluciones en el contexto de un grupo viene dada por la especificación del tipo Práctica::Grupo, según la cual en un grupo de prácticas no puede haber más de un recurso de este tipo. Por tanto, si los alumnos quieren modificar una solución ya publicada, pueden destruir el recurso y volverlo a crear. Antes de la entrega de la práctica, los alumnos pueden crear y eliminar la solución todas las veces que quieran. Una vez entregada, por el contrario, cualquier intento de eliminar la solución quedará en suspenso a la espera de la correspondiente autorización del profesor responsable de la práctica 62 Curso 09-10/Ing. Inf./Arquitectura del Software/

63 Soluciones de prácticas URJC/MOSTI/DASI/Bloque II/Gestión Universitaria 63 Curso 09-10/Ing. Inf./Arquitectura del Software/