Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades

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

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

3. Normativa de referencia

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

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

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

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

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

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

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

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

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

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

17. Atributos estándar cam:Comunidad a1@cam:Agente state= playing, context=cam, role=a1@iinf.... 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= a1, ... ,sub=08-09.iinf.etsii.urjc.cam,...} 08-09.iinf.etsii.urjc.cam:CursoAcadémico mar.08-09.iinf.etsii.urjc.cam:Curso as.08-09.iinf.etsii.urjc.cam:Curso {state= open, context=08-09..., member= a1@as..., ...} a1@iinf...:Alumno state= playing context=iinf... player=a1@cam satisfied=false pp1.as....:Práctica jms@as.08-09....:Profesor state= playing player= jms@dcc.urjc.cam a1@as.08-09....:Alumno :Enunciado state= playing satisfied=false jms@pp1.as...:Profesor state= created creator= jms@as.. an:Alumno ss@as.08-09....:Profesor state= abandoned satisfied=true state= playing player= ss@dcc.urjc.cam :PCChair

18. Atributos dependientes del dominio escet.urjc.cam:Escuela cam:Comunidad a1@cam:Agente nombre= “XXX” foto=“../mifoto.gif” título=“t1@cam” upm.cam:Universidad urjc.cam:Universidad etsii.urjc.cam:Escuela iinf.etsii.urjc.cam:Carrera {plan_estudios=pe1@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..., ...} a1@iinf...:Alumno #cr_tr=186 #cr_obl=97,5 #cr_opt=42 #cr_le=40,5 pp1.as....:Práctica {prueba=pp1@as...,...} jms@as.08-09....:Profesor responsable_de=pp1@as... a1@as.08-09....:Alumno :Enunciado aprobó=pp1@as... aprobó=pp2@as... jms@pp1.as...:Profesor content=“…/pp1.pdf” entrega=15/4/09 an:Alumno ss@as.08-09....:Profesor responsable_de=pp2@as... inicio=03-04.iinf…, calificación=c1@03-04.iinf... calificación=cn@04-05.iinf... Curso 09-10/Ing. Inf./Arquitectura del Software/

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

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 :SetUp :Leave :Practica {publicado=true} :Alumno :Alumno :Enunciado :SetUp :Grupo :SetUp :Allow :Invite :Accept :Invitation :Join :Alumno :Alumno :Forbid :Inviter :Invitee :Create :Create :Profesor :Publish :Alumno :Alumno :Solución :Join :Profesor :Evaluación :Alumno :Calificación :Create :Submit :Notify :SetUp :Complain :Notify :Submitter :Revisión :Submittee :Evaluado :Evaluador

22. Procesamiento de attempts (unempowered) <say> <dictum> <setUp context=“p1”> <new><interaction type=“Practica::Grupo”/></new> </setUp> </dictum> </say> :Attempt performer= a1 action=“<say>...</say>” :Component :Curso p1:Practica :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” a1:Alumno aprobó(p1)=true empowered (“<say>..”) =false

23. Procesamiento de attempts (forbidden) <say> <dictum> <setUp context=“p1”> <new><interaction type=“Practica::Grupo”/></new> </setUp> </dictum> </say> :Attempt performer= a1 action=“<say>...</say>” :Component α1:SetUp state=pending new=g1 context=p1 performer=a1 permitted=false :Curso state=forbidden p1:Practica {publicado=false} :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” a1:Alumno aprobó(p1)=false empowered (“<say>..”) =true

24. Procesamiento de attempts (successful) <say> <dictum> <setUp context=“p1”> <new><interaction type=“Practica::Grupo”/></new> </setUp> </dictum> </say> :Attempt performer= a1, action=“<say>...</say>” :Execute :Component α1:SetUp state=pending new=g1 context=p1 performer=a1 permitted=true :Curso state=executed p1:Practica {publicado=true} :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” :Initiate g1:Grupo {initiator=a1} a1:Alumno aprobó(p1)=false empowered (“<say>..”) =true

25. Reglas de autorizaciones y permisos ACTION EMPOWERMENTS PERMISSIONS 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 upa 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 Joina 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 ACTION EMPOWERMENTS PERMISSIONS 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 Leavea 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. Content Introducción Vistas de ejecución Espacio de interacciones Jerarquía de roles Recursos del entorno Atributos Acciones comunicativas Eventos Modelos de la aplicación Curso 09-10/Ing. Inf./Arquitectura del Software/

28. Publicación de eventos <event character=“positive”> <timestamp>2008-02-02 T 15:05</timestamp> <entity>g1</entity> <attribute>member</attribute> <value>a2</value> <cause rule=“…”/> </event> :Curso :Publish p1:Practica :Initiate e1 e2 :Publish α1:SetUp g1:Grupo a1:Alumno :Play :Publish e3 a2:Alumno

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

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

31. Procesamiento de eventos e1 :Curso :Observe :Observe e1 :Component p1:Practica :Component e1 a1:Alumno g1:Grupo { initiator=a1 event=e1 } event=e1 :Profesor :Play event=e1 :Protocol rule=“La creación de un grupo de prácticas conlleva la creación automática de un rol para su iniciador” :Alumno

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

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 grupo.mdzip universidad.mdzip Curso 09-10/Ing. Inf./Arquitectura del Software/

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/

38. Content Introducción Vistas de ejecución Modelos de la aplicación Jerarquía de interacciones 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 Curso 09-10/Ing. Inf./Arquitectura del Software/

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

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

41. Content Introducción Vistas de ejecución Modelos de la aplicación Jerarquía de interacciones 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 Curso 09-10/Ing. Inf./Arquitectura del Software/

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

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

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

45. Content Introducción Vistas de ejecución Modelos de la aplicación Jerarquía de interacciones 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 Curso 09-10/Ing. Inf./Arquitectura del Software/

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

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

48. Content Introducción Vistas de ejecución Modelos de la aplicación Jerarquía de interacciones 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 Curso 09-10/Ing. Inf./Arquitectura del Software/

49. Grupos de prácticasInicio y finalización 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.

50. Grupos de prácticasInicio