Arquitectura del softwareParte II- Arquitecturas multiagente
Gestión de universidades
Ingeniería InformáticaCurso 2009/2010
Juan Manuel Serranohttp://zenon.etsii.urjc.es/grupo/docencia/as
Content
Curso 09-10/Ing. Inf./Arquitectura del Software/2
Introducción
Vistas de ejecución
Modelos de la aplicación
Normativa de referencia
COMPROBACION DOCUMENTACION
COMPULSA O COTEJO SI PROCEDE
REGISTRO GENERALo REGISTROS AUXILIARES
RESGUARDO DE ENTREGA INTERESADO
ASIENTO REGISTRAL
RECEPCION DE ENTREGA
UNIDADES ADMINISTRATIVA
S
REGISTRO GENERAL
CERTIFICACION DOCUMENTACION
ARCHIVO RECEPCIONES
DOCUMENTO PARA REGISTRAR
COMPROBACION DOCUMENTACION
COMPULSA O COTEJO SI PROCEDE
REGISTRO GENERALo REGISTROS AUXILIARES
RESGUARDO DE ENTREGA INTERESADO
ASIENTO REGISTRAL
RECEPCION DE ENTREGA
UNIDADES ADMINISTRATIVA
S
REGISTRO GENERAL
CERTIFICACION DOCUMENTACION
ARCHIVO RECEPCIONES
DOCUMENTO PARA REGISTRAR
Curso 09-10/Ing. Inf./Arquitectura del Software/4
Normativa de referencia
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.
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.
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.
Curso 09-10/Ing. Inf./Arquitectura del Software/8
Content
Introducción
Vistas de ejecuciónEspacio de interacciones
Modelos de la aplicación
Jerarquía de rolesRecursos del entorno
Acciones comunicativasAtributos
Eventos
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
Curso 09-10/Ing. Inf./Arquitectura del Software/10
Content
Introducción
Vistas de ejecuciónEspacio de interacciones
Modelos de la aplicación
Jerarquía de rolesRecursos del entorno
Acciones comunicativasAtributos
Eventos
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
:Alumno
:Alumno :Alumno
:Alumno:Remitente
:Evaluado
:Coordinador
:Alumno
:Alumno
:Alumno:Alumno
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
:Profesor
:Evaluador
:Revisor
:Profesor
:Vigilante:Evaluador
:Tutor:Instructor
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 :Director
:Asistente
:MiembroNato
Curso 09-10/Ing. Inf./Arquitectura del Software/14
Content
Introducción
Vistas de ejecuciónEspacio de interacciones
Modelos de la aplicación
Jerarquía de rolesRecursos del entorno
Acciones comunicativasAtributos
Eventos
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:PlanEstudios
:Asignatura:Asignatura
:Calificación
:Prueba
:Aula
:Laboratorio:Despacho
:Enunciado :Enunciado
:Títulación
:Calificación
:Calificación
Curso 09-10/Ing. Inf./Arquitectura del Software/16
Content
Introducción
Vistas de ejecuciónEspacio de interacciones
Modelo de la aplicación
Jerarquía de rolesRecursos del entorno
Acciones comunicativasAtributos
Eventos
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= a1, ... ,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= a1@as..., ...}
pp1.as....:Práctica
a1@iinf...:Alumno
:Enunciado
an:Alumno
state= playingcontext=iinf...player=a1@camsatisfied=false
a1@cam:Agentestate= playing,context=cam,role=a1@iinf....
state= abandonedsatisfied=true
[email protected]....:Alumno
state= playingsatisfied=false
state= playingplayer= [email protected]
[email protected]....:Profesor
state= playingplayer= [email protected]
[email protected]....:Profesorstate= createdcreator= jms@as..
[email protected]...:Profesor
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=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..., ...}
pp1.as....:Práctica{prueba=pp1@as...,...}
a1@iinf...:Alumno
:Enunciado
an:Alumno
#cr_tr=186#cr_obl=97,5#cr_opt=42#cr_le=40,5
a1@cam:Agentenombre= “XXX”foto=“../mifoto.gif”título=“t1@cam”
inicio=03-04.iinf…,calificació[email protected]ó[email protected]...
[email protected]....:Alumno
aprobó[email protected]ó=pp2@as...
responsable_de=pp1@as...
[email protected]....:Profesor
responsable_de=pp2@as...
[email protected]....:Profesorcontent=“…/pp1.pdf”entrega=15/4/09
[email protected]...:Profesor
Curso 09-10/Ing. Inf./Arquitectura del Software/19
Content
Introducción
Vistas de ejecuciónEspacio de interacciones
Modelos de la aplicación
Jerarquía de rolesRecursos del entorno
Acciones comunicativasAtributos
Eventos
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).
Acciones comunicativas
:Curso
:Practica{publicado=true}
:Grupo
:Invitation
:Evaluación
:Alumno
:Calificación
:Alumno
:Alumno
:Inviter
:Alumno
:Invitee
:SetUp
:SetUp
:Alumno
:Accept:Invite
:Join
:SetUp
:Alumno
:Alumno
:Join
:Forbid
:Allow
:Solución
:Create
:Revisión
:Evaluado
:Submittee
:Evaluador
:Notify:Complain
:Create
:Submitter
:Submit:SetUp
:Profesor
:Profesor
:Notify
:Create:Publish
:Enunciado
:Leave
Procesamiento de attempts (unempowered)
:Curso
p1:Practica
a1:Alumno
:Component
:Attempt performer= a1
action=“<say>...</say>”
<say> <dictum> <setUp context=“p1”> <new><interaction type=“Practica::Grupo”/></new> </setUp> </dictum></say>
:Protocolrule=“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ó(p1)=trueempowered (“<say>..” ) =false
Procesamiento de attempts (forbidden)
:Curso
p1:Practica{publicado=false}
a1:Alumno
α1:SetUpstate=pendingnew=g1context=p1
performer=a1permitted=false
:Component
:Attempt performer= a1
action=“<say>...</say>”
<say> <dictum> <setUp context=“p1”> <new><interaction type=“Practica::Grupo”/></new> </setUp> </dictum></say>
:Protocolrule=“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ó(p1)=false empowered (“<say>..” ) =true
state=forbidden
Procesamiento de attempts (successful)
:Curso
p1:Practica{publicado=true}
g1:Grupo{initiator=a1}
a1:Alumno
α1:SetUpstate=pendingnew=g1context=p1
performer=a1permitted=true
:Component
:Attempt performer= a1, action=“<say>...</say>”
<say> <dictum> <setUp context=“p1”> <new><interaction type=“Practica::Grupo”/></new> </setUp> </dictum></say>
:Protocolrule=“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 (“<say>..” ) =true
:Initiate
:Execute
state=executed
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 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
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
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
Curso 09-10/Ing. Inf./Arquitectura del Software/27
Content
Introducción
Vistas de ejecuciónEspacio de interacciones
Modelos de la aplicación
Jerarquía de rolesRecursos del entorno
Acciones comunicativasAtributos
Eventos
Publicación de eventos
:Curso
p1:Practica
g1:Grupoa1:Alumno
:Publish
e1
e2
:Publish
e3
α1:SetUp
a2:Alumno
:Publish
<event character=“positive”> <timestamp>2008-02-02 T 15:05</timestamp> <entity>g1</entity> <attribute>member</attribute> <value>a2</value> <cause rule=“…”/></event>
:Play
:Initiate
Notificación de eventos
:Curso
:Practica
a1:Alumno
:Publish
e1
:Notify
α1:SetUpaddressee=a2
a2:Alumno
event=e1
event=e1
:Notify
:Protocolrule=“La realización de una acción comunicativa debe ser notificada al hablante y a todos los destinatarios”
Notificación de eventos
:Curso
p1:Practica
g1:Grupo{ initiator=a1
event=e1 }
e1:Publish
:Profesor
event=e1
:Initiate
a1:Alumno
event=e1
:Protocolrule=“Los profesores de prácticas monitorizan la creación y eliminación de grupos de prácticas”
:Protocolrule=“El iniciador de una interacción debe ser notificado de su creación”
:Protocolrule=“La creación de un grupo de prácticas conlleva la creación automática de un rol para su iniciador”
:Notify
:Notify:Notify
Procesamiento de eventos
:Curso
p1:Practica
g1:Grupo{ initiator=a1
event=e1 }
e1
:Profesor
event=e1
a1:Alumno
event=e1
:Protocolrule=“La creación de un grupo de prácticas conlleva la creación automática de un rol para su iniciador”
e1
:Component:Observe
e1
:Component
:Observe
:Alumno
:Play
Curso 09-10/Ing. Inf./Arquitectura del Software/32
Content
Introducción
Vistas de ejecuciónModelos de la aplicación
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
Modelos UML
Curso 09-10/Ing. Inf./Arquitectura del Software/34
universidad.mdzip
grupo.mdzip
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
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
Modelos de la aplicación
Curso 09-10/Ing. Inf./Arquitectura del Software/37
Curso 09-10/Ing. Inf./Arquitectura del Software/38
Content
Introducción
Vistas de ejecución
Jerarquía de interaccionesModelos de la aplicación
Jerarquía de rolesRecursos del entorno
Modelo detallado de un tipo de interacción socialModelo detallado de un tipo de agenteModelo detallado de un tipo de recurso
Jerarquía de interacciones sociales (I)
Curso 09-10/Ing. Inf./Arquitectura del Software/39
Jerarquía de interacciones sociales (II)
Curso 09-10/Ing. Inf./Arquitectura del Software/40
Curso 09-10/Ing. Inf./Arquitectura del Software/41
Content
Introducción
Vistas de ejecución
Jerarquía de interaccionesModelos de la aplicación
Jerarquía de rolesRecursos del entorno
Modelo detallado de un tipo de interacción socialModelo detallado de un tipo de agenteModelo detallado de un tipo de recurso
Jerarquías de agentes (I)
Curso 09-10/Ing. Inf./Arquitectura del Software/42
Jerarquías de agentes (II)
Curso 09-10/Ing. Inf./Arquitectura del Software/43
Jerarquías de agentes (III)
Curso 09-10/Ing. Inf./Arquitectura del Software/44
Curso 09-10/Ing. Inf./Arquitectura del Software/45
Content
Introducción
Vistas de ejecución
Jerarquía de interaccionesModelos de la aplicación
Jerarquía de rolesRecursos del entorno
Modelo detallado de un tipo de interacción socialModelo detallado de un tipo de agenteModelo detallado de un tipo de recurso
Recursos de la comunidad (I)
Curso 09-10/Ing. Inf./Arquitectura del Software/46
Recursos de la comunidad (II)
Curso 09-10/Ing. Inf./Arquitectura del Software/47
Curso 09-10/Ing. Inf./Arquitectura del Software/48
Content
Introducción
Vistas de ejecución
Jerarquía de interaccionesModelos de la aplicación
Jerarquía de rolesRecursos del entorno
Modelo detallado de un tipo de interacción socialModelo detallado de un tipo de agenteModelo detallado de un tipo de recurso
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ácticasInicio y finalización
Grupos de prácticasInicio
Grupos de prácticasFinalización
URJC/MOSTI/DASI/Bloque II/Gestión Universitaria5151 Curso 09-10/Ing. Inf./Arquitectura del Software/
Grupos de trabajoAtributos 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
Grupos de trabajoAtributos y restricciones estructurales
Curso 09-10/Ing. Inf./Arquitectura del Software/53
Curso 09-10/Ing. Inf./Arquitectura del Software/54
Content
Introducción
Vistas de ejecución
Jerarquía de interaccionesModelos de la aplicación
Jerarquía de rolesRecursos del entorno
Modelo detallado de un tipo de interacción socialModelo detallado de un tipo de agenteModelo detallado de un tipo de recurso
Alumnos de grupos de trabajoReglas de desempeño
URJC/MOSTI/DASI/Bloque II/Gestión Universitaria55
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/
Alumnos de grupos de trabajoReglas de desempeño
URJC/MOSTI/DASI/Bloque II/Gestión Universitaria5656 Curso 09-10/Ing. Inf./Arquitectura del Software/
Alumnos de grupos de trabajoRestricciones estructurales
URJC/MOSTI/DASI/Bloque II/Gestión Universitaria57
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/
Alumnos de grupos de trabajoRestricciones estructurales
URJC/MOSTI/DASI/Bloque II/Gestión Universitaria5858 Curso 09-10/Ing. Inf./Arquitectura del Software/
Alumnos de grupos de trabajoReglas de abandono
URJC/MOSTI/DASI/Bloque II/Gestión Universitaria59
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/
Alumnos de grupos de trabajoReglas de abandono
URJC/MOSTI/DASI/Bloque II/Gestión Universitaria6060 Curso 09-10/Ing. Inf./Arquitectura del Software/
Curso 09-10/Ing. Inf./Arquitectura del Software/61
Content
Introducción
Vistas de ejecución
Jerarquía de interaccionesModelos de la aplicación
Jerarquía de rolesRecursos del entorno
Modelo detallado de un tipo de interacción socialModelo detallado de un tipo de agenteModelo detallado de un tipo de recurso
Soluciones de prácticas
URJC/MOSTI/DASI/Bloque II/Gestión Universitaria62
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/
Soluciones de prácticas
URJC/MOSTI/DASI/Bloque II/Gestión Universitaria6363 Curso 09-10/Ing. Inf./Arquitectura del Software/