arquitectura del software parte ii- arquitecturas multiagente gestión de universidades ingeniería...

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


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.


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.


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.


Content

Introducción

Vistas de ejecuciónEspacio de interacciones


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


Content

Introducción





Eventos

Jerarquías de roles

:Matricula

:ConsejoGobierno

:Comunidad

:Universidad


: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


:Matricula

:ConsejoGobierno

:Comunidad

:Universidad



: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


:Departamento

:Matricula

:ConsejoGobierno

:Comunidad

:Universidad

:Escuela :Vicerrectorado


: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


Content

Introducción





Eventos

Recursos del entorno

:Departamento

:Matricula

:ConsejoGobierno

:Comunidad

:Universidad

:Escuela :Vicerrectorado


: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


Content

Introducción


Modelo de la aplicación



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


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


Content

Introducción





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>”


: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>”


: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


Content

Introducción





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


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


universidad.mdzip

grupo.mdzip


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


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


Content

Introducción


Jerarquía de interaccionesModelos de la aplicación


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)


Jerarquía de interacciones sociales (II)



Content

Introducción





Jerarquías de agentes (I)


Jerarquías de agentes (II)


Jerarquías de agentes (III)



Content

Introducción





Recursos de la comunidad (I)


Recursos de la comunidad (II)



Content

Introducció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.

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



Content

Introducción





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


Alumnos de grupos de trabajoRestricciones estructurales


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.


Alumnos de grupos de trabajoRestricciones estructurales


Alumnos de grupos de trabajoReglas de abandono


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.


Alumnos de grupos de trabajoReglas de abandono



Content

Introducción





Soluciones de prácticas


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


Soluciones de prácticas


arquitectura del software parte ii- arquitecturas multiagente gestión de universidades ingeniería...

Documents