Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería...
-
Upload
magdalena-martin-lozano -
Category
Documents
-
view
216 -
download
0
Transcript of Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería...
![Page 1: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/1.jpg)
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
![Page 2: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/2.jpg)
Content
Curso 09-10/Ing. Inf./Arquitectura del Software/2
Introducción
Vistas de ejecución
Modelos de la aplicación
![Page 3: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/3.jpg)
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
![Page 4: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/4.jpg)
Curso 09-10/Ing. Inf./Arquitectura del Software/4
Normativa de referencia
![Page 5: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/5.jpg)
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.
![Page 6: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/6.jpg)
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.
![Page 7: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/7.jpg)
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.
![Page 8: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/8.jpg)
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
![Page 9: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/9.jpg)
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
![Page 10: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/10.jpg)
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
![Page 11: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/11.jpg)
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
![Page 12: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/12.jpg)
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
![Page 13: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/13.jpg)
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
![Page 14: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/14.jpg)
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
![Page 15: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/15.jpg)
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
![Page 16: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/16.jpg)
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
![Page 17: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/17.jpg)
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
![Page 18: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/18.jpg)
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
![Page 19: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/19.jpg)
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
![Page 20: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/20.jpg)
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).
![Page 21: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/21.jpg)
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
![Page 22: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/22.jpg)
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
![Page 23: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/23.jpg)
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
![Page 24: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/24.jpg)
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
![Page 25: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/25.jpg)
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
![Page 26: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/26.jpg)
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
![Page 27: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/27.jpg)
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
![Page 28: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/28.jpg)
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
![Page 29: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/29.jpg)
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”
![Page 30: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/30.jpg)
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
![Page 31: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/31.jpg)
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
![Page 32: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/32.jpg)
Curso 09-10/Ing. Inf./Arquitectura del Software/32
Content
Introducción
Vistas de ejecuciónModelos de la aplicación
![Page 33: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/33.jpg)
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
![Page 34: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/34.jpg)
Modelos UML
Curso 09-10/Ing. Inf./Arquitectura del Software/34
universidad.mdzip
grupo.mdzip
![Page 35: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/35.jpg)
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
![Page 36: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/36.jpg)
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
![Page 37: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/37.jpg)
Modelos de la aplicación
Curso 09-10/Ing. Inf./Arquitectura del Software/37
![Page 38: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/38.jpg)
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
![Page 39: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/39.jpg)
Jerarquía de interacciones sociales (I)
Curso 09-10/Ing. Inf./Arquitectura del Software/39
![Page 40: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/40.jpg)
Jerarquía de interacciones sociales (II)
Curso 09-10/Ing. Inf./Arquitectura del Software/40
![Page 41: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/41.jpg)
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
![Page 42: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/42.jpg)
Jerarquías de agentes (I)
Curso 09-10/Ing. Inf./Arquitectura del Software/42
![Page 43: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/43.jpg)
Jerarquías de agentes (II)
Curso 09-10/Ing. Inf./Arquitectura del Software/43
![Page 44: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/44.jpg)
Jerarquías de agentes (III)
Curso 09-10/Ing. Inf./Arquitectura del Software/44
![Page 45: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/45.jpg)
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
![Page 46: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/46.jpg)
Recursos de la comunidad (I)
Curso 09-10/Ing. Inf./Arquitectura del Software/46
![Page 47: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/47.jpg)
Recursos de la comunidad (II)
Curso 09-10/Ing. Inf./Arquitectura del Software/47
![Page 48: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/48.jpg)
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
![Page 49: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/49.jpg)
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
![Page 50: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/50.jpg)
Grupos de prácticasInicio
![Page 51: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/51.jpg)
Grupos de prácticasFinalización
URJC/MOSTI/DASI/Bloque II/Gestión Universitaria5151 Curso 09-10/Ing. Inf./Arquitectura del Software/
![Page 52: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/52.jpg)
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
![Page 53: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/53.jpg)
Grupos de trabajoAtributos y restricciones estructurales
Curso 09-10/Ing. Inf./Arquitectura del Software/53
![Page 54: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/54.jpg)
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
![Page 55: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/55.jpg)
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/
![Page 56: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/56.jpg)
Alumnos de grupos de trabajoReglas de desempeño
URJC/MOSTI/DASI/Bloque II/Gestión Universitaria5656 Curso 09-10/Ing. Inf./Arquitectura del Software/
![Page 57: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/57.jpg)
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/
![Page 58: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/58.jpg)
Alumnos de grupos de trabajoRestricciones estructurales
URJC/MOSTI/DASI/Bloque II/Gestión Universitaria5858 Curso 09-10/Ing. Inf./Arquitectura del Software/
![Page 59: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/59.jpg)
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/
![Page 60: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/60.jpg)
Alumnos de grupos de trabajoReglas de abandono
URJC/MOSTI/DASI/Bloque II/Gestión Universitaria6060 Curso 09-10/Ing. Inf./Arquitectura del Software/
![Page 61: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/61.jpg)
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
![Page 62: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/62.jpg)
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/
![Page 63: Arquitectura del software Parte II- Arquitecturas multiagente Gestión de universidades Ingeniería Informática Curso 2009/2010 Juan Manuel Serrano .](https://reader035.fdocuments.mx/reader035/viewer/2022062500/5665b4e81a28abb57c94acd5/html5/thumbnails/63.jpg)
Soluciones de prácticas
URJC/MOSTI/DASI/Bloque II/Gestión Universitaria6363 Curso 09-10/Ing. Inf./Arquitectura del Software/