proyecto práctico de análisis y diseño orientado a … · 22-mar semana santa 23-mar 24-mar...
Post on 12-Oct-2018
221 Views
Preview:
TRANSCRIPT
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 1
Ingeniería del Software IIIngeniería Informática, 4°Curso
Proyecto Práctico de Análisis y Diseño Orientado a Objetos
Curso 2004-2005
Gonzalo Génova y Vicente Palacios
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 2
Presentación
• Profesores (despacho 2.1 B08)– Gonzalo Génova (ggenova@inf.uc3m.es)– Vicente Palacios (palacios@di.uc3m.es)– Omar Hurtado (ohurtado@inf.uc3m.es)
• http://www.ie.inf.uc3m.es�Docencia, Reglada, Ingeniería del Software II
• Relación con otras asignaturas– Ing. Téc. Inf. Gestión: Ingeniería del Software II– Ing. Informática (1° y 2° Ciclo): Ingeniería del Software I
• Modelado OO (principios, lenguaje) � Proyecto AyD OO (práctica)
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 3
Objetivos de la asignatura
• Aplicar las técnicas del análisis y diseño orientado a objetos para mejorar el proceso de desarrollo de software– Conocimientos adquiridos en Ingeniería del Software I
• Aprender...– Redacción de un documento completo de requisitos, análisis y diseño– Desarrollo dirigido por modelos (MDA-MDD-MDE), evolución de USDP– Estándares de documentación de proyectos
• Desarrollar capacidades– Abstracción– Resolución de problemas– Trabajo en equipo– Exposición de resultados propios– Revisión de trabajos ajenos– Aprendizaje a partir de errores propios y ajenos
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 4
Programa de la asignatura: teoría
• Tema I – Requisitos del usuario (captura de requisitos)– Unidad 1 – Presentación / Estándares de documentación en el SDP– Unidad 2 – Introducción a la ingeniería de requisitos– Unidad 3 – Obtención y descripción de requisitos de usuario
• Tema II – Requisitos del software (análisis de requisitos)– Unidad 4 – Tipos de requisitos– Unidad 5 – Propiedades deseables– Unidad 6 – Organización y calidad
• Tema III – Diseño arquitectónico (diseño de alto nivel)– Unidad 7 – Descomposición, marcos y patrones– Unidad 8 – Estilos arquitectónicos (1)– Unidad 9 – Estilos arquitectónicos (2)
• Tema IV – Diseño detallado (diseño de bajo nivel)– Unidad 10 – Técnicas generales– Unidad 11 – Patrones de diseño (1)– Unidad 12 – Patrones de diseño (2)
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 5
Programa de la asignatura: prácticas
• Grupos de 4 alumnos • Actividades
– Desarrollo y documentación del proyecto (4 fases)– Revisiones cruzadas (4 fases)– Exposiciones en público y defensa del proyecto (fase conclusiva)– Propuesta de preguntas teóricas para el examen de test
• Documentación entregada (9 documentos en total)– Documentos parciales: ej. URD-G05.doc [URD / SRD / ADD / DDD]
• envío por correo a profesores y miembros del grupo revisor– Documentos de revisión: ej. URD-G05-R07.doc
• envío por correo a profesores y miembros del grupo revisado– Documento final del proyecto con revisiones: ej. IS2-G05.doc
• envío por correo a profesores• ejemplar impreso, encuadernado en espiral, tapas duras
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 6
Descripción de la práctica
• “Necesito algo para organizar mejor mis actividades, una agenda para llevar al día mi horario, mis compromisos, etc.”
• No teléfonos, ni contactos... sólo organización de calendario.• Libertad para escoger plataforma e interacción con el usuario• Extensión de los documentos (orientativa):
– URD: 5 a 10 páginas.– SRD: 10 a 20 páginas.– ADD: 10 a 20 páginas.– DDD: 10 a 20 páginas.– TOTAL: 35 a 70 páginas
Calidad, no cantidad
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 7
Programa de la asignatura: calendario
• Formación de grupos: 28 febrero• Entrega de documentos parciales
– 14 marzo, 4 abril, 18 abril, 4 mayo
• Entrega de documentos de revisión– 28 marzo, 11 abril, 25 abril, 9 mayo
• Entrega de documentos finales– 16 mayo
• Exposiciones en público y defensa del proyecto– 17 mayo a 2 junio
Entregas 22-feb Presentación 23-feb 24-feb URD - TeoríaGrupos: 28-feb 1-mar URD - Teoría 2-mar 3-mar SRD - Teoría
8-mar SRD - Teoría 9-mar 10-mar SRD - TeoríaURD: 14-mar 15-mar ADD - Teoría 16-mar 17-mar ADD - Teoría
22-mar Semana Santa 23-mar 24-mar Semana SantarURD: 28-mar 29-mar URD - Revisión 30-mar 31-mar URD - RevisiónSRD: 4-abr 5-abr ADD - Teoría 6-abr 7-abr DDD - TeoríarSRD: 11-abr 12-abr SRD - Revisión 13-abr 14-abr SRD - RevisiónADD: 18-abr 19-abr DDD - Teoría 20-abr 21-abr DDD - TeoríarADD: 25-abr 26-abr ADD - Revisión 27-abr 28-abr ADD - RevisiónDDD: 4-may 3-may Fiesta 4-may 5-may Repaso - LibrerDDD: 9-may 10-may DDD - Revisión 11-may 12-may DDD - RevisiónFinal: 16-may 17-may Exposición 18-may 19-may Exposición
24-may Exposición 25-may 26-may Exposición31-may (Exposición) 1-jun 2-jun (Exposición)
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 8
Evaluación de la asignatura
• 70% Parte práctica de la calificación– A. 40% Evaluación de la documentación presentada
• corrección formal (estándar) y material (contenido)– B. 20% Evaluación de las presentaciones en público
• preparación y ejecución, respuesta a las preguntas del público
– C. 10% Evaluación de los informes de revisión• ayuda para el grupo revisado, no influye en su calificación
• 30% Parte teórica de la calificación– D. 10% Evaluación de la propuesta de preguntas de test (3 preguntas cada grupo)– E. 20% Calificación del examen final de test
• Calificaciones de grupo e individuales– 60% calificación global de grupo: A, C y D
– 40% calificación individual de cada alumno: B y E
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 9
Bibliografía
• Eric Braude. Software Engineering. An Object-OrientedPerspective. John Wiley & Sons, 2001.– Capítulos 3, 4, 5 y 6
• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns. Elements of reusable Object-Orientedsoftware. Addison-Wesley, 1994.
• ESA Board for Software Standardisation and Control (BSSC). ESA Software Engineering Standards. European Space Agency, February 1991.
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 10
Tema IRequisitos del Usuario
Unidad 1 –Estándares de documentación en el SDP
Unidad 2 – Introducción a la ingeniería de requisitosUnidad 3 –Obtención y descripción de requisitos de usuario
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 11
Flujos de trabajo vs. Documentos
+ Implementación, Pruebas, Mantenimiento...
Detailed DesignDocument
Diseño detallado
Software RequirementsDocument
DocumentosFlujos de trabajo
Architectural DesignDocument
User RequirementsDocument
ESA
Software DesignDocument
(IEEE 1016-1987)
IEEE
Software RequirementsSpecification
(IEEE 830-1993)
Diseño arquitectónico
Diseño
Análisis
Análisis de requisitos
Requisitos
ClásicaUSDP
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 12
El Estándar de la ESA
Guide to applying the ESA standards to small software projectsESA Lite
Guide to software quality assurance
Guide to software verification and validation
Guide to software configuration
Guide to software project management management
Guide to the software operations and maintenance phasePROCEDURES
Guide to the software transfer phase
Guide to the software detailed design and production phase
Guide to the software architectural design phase
Guide to the software requirements definition phase
Guide to the user requirements definition phasePRODUCTS
Guide to the software engineering standards
European Space Agency software engineering standardsGENERAL
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 13
Introducción a la ingeniería de requisitos
• Qué es la Ingeniería de Requisitos– Captura y Análisis– Resultado del proceso: el documento de requisitos
• Necesidad de la Ingeniería de Requisitos– Para construir algo, antes hay que entender qué es ese “algo”
• Dos niveles en los requisitos– Requisitos del Usuario, Requisitos del Software
• Por qué es necesario escribir los requisitos– Sin requisitos escritos es imposible... – No hay ingeniería profesional sin requisitos escritos
• Dificultades de la Ingeniería de Requisitos– El precio pagado: es una necesidad, no un lujo
• La Ingeniería de Requisitos en el contexto del proyecto– Pre-proyecto: valor contractual, viabilidad, planificación, estimación...
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 14
Requisitos del Usuario vs. Requisitos del Software
Requisitos del usuario
Diseño detallado
Diseño arquitectónico
Requisitos del software
IMPLEMENTACIÓN
ANÁLISIS
DISEÑO
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 15
Obtención y descripción de requisitos del usuario
• Las fuentes de los requisitos • Plan de trabajo para obtener los requisitos• Identificación de stakeholders
– ¿Quiénes tienen interés en el producto? – ¿Quién es el cliente?– Intereses contrapuestos, requisitos
contradictorios– Negociar el equilibrio
• Cómo llevar adelante una entrevista– Antes, durante, después...
Identificar
Entrevistar
(D)escribir
Revisar
[conforme]
[no conforme]Requisitos Calidad
Presupuesto Recursos
Planificación Tiempo
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 16
Técnicas para la obtención y descripción de requisitos
• Textuales– Relativamente accesibles a un cliente sin formación específica
• Texto en prosa común y corriente• Texto estructurado, lenguaje técnico• Casos de uso
• Gráficas– Requieren un cierto grado de formación técnica en el cliente– Tienen el peligro de convertir el análisis de requisitos en diseño
• Diagramas de flujo de datos• Diagramas de estados
• Prototipos– No confundir con diseño, valorar la inversión
• Interfaces de usuario• Protipado rápido
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 17
Beneficio de la inversión en prototipos
Beneficio obtenido (ahorro / gasto)
Gasto efectuado 100%
Adaptado de E. Braude,Software Engineering: An Object-Oriented Perspective
0%
Beneficio óptimo
Recursos malgastados
GUI simplificada
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 18
Los requisitos del usuario en el Estándar ESA
• ESA software engineering standards (PSS-05-0)– Chapter 2. The user requirements definition phase
• 2.3. Actividades: nociones importantes
• Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1)– Chapter 3. Using Object-Oriented Methods with PSS-05
• No afecta
• Guide to the user requirements definition phase (PSS-05-02)– Chapter 2. The user requirements definition phase
• 2.3. Determinación del entorno operacional• 2.4. Requisitos de capacidad / Requisitos de restricción• 2.7. Revisión de los requisitos del usuario
– Chapter 5. The user requirements document
• 5.1. Introducción: lo que debe ser, lo que no debe ser• 5.3. Estilo: claridad, consistencia, modificabilidad
• 5.6. Contenido
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 19
Introducción a los requisitos del software
• Qué son los requisitos del software– Descripción de la naturaleza exacta de la aplicación– Diferencia con los requisitos del usuario
• punto de vista del cliente, punto de vista del desarrollador
• Clasificación de requisitos del software– Requisitos funcionales
• Requisitos de información / Requisitos de operación• Modelo de análisis (PIM: Platform Independent Model)
– Modelo conceptual– Modelo de casos de uso
– Requisitos no funcionales
• Características distintivas• Ejemplos• Análisis y documentación
– Separación de incumbencias
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 20
Diferentes puntos de vista – Diferentes documentos
Lo que yo necesito es...
Lo que él necesita es... Lo que tienes
que hacer es...
Lo que tengo que hacer es...
Cliente
Analista Arquitecto
Diseñador
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 21
Requisitos no funcionales
• Consumo de recursos– memoria, capacidad de tráfico...
• Rendimiento– velocidad, tiempo de respuesta...
• Fiabilidad y disponibilidad– cuatificación de fallos permitidos
• Manejo de errores– errores del entorno, errores internos
• Requisitos de interfaz– comunicación con usuarios, con otras aplicaciones
• Restricciones– exactitud, lenguajes, arquitectura, estándares, plataformas...
• Seguridad– seguridad del sistema, seguridad de las personas
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 22
Propiedades deseables de los requisitos del software
• Propiedades globales– Completitud
• organización por tipos de requisitos– Consistencia
• tabla de referencias cruzadas• Propiedades individuales
– Claridad– Trazabilidad (funcionales / no funcionales)
• matrices de trazabilidad (hacia atrás, hacia adelante)– Necesidad
• esencial, deseable, opcional– Prioridad
• alta, baja– Riesgo
• alto, moderado, bajo– Comprobabilidad
• validación y verificación– Condiciones de error
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 23
Consistencia de requisitos: conflictos y solapamientos
• Solapamientos (+)– R1 y R3
– R3 y R4– R3 y R6
• Requisitos independientes– R2
+xR6
xxR5
x+R4
+++R3
R2
xx+R1
R6R5R4R3R2R1
• Conflictos (x)– R1 y R5
– R1 y R6– R4 y R5
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 24
Métodos para organizar los requisitos del software
• Técnicas ya mencionadas– Tablas de referencias cruzadas– Matrices de trazabilidad– Modularidad y anidamiento de requisitos
• Organizar los requistos funcionales según el modelo de análisis– Por caso de uso
• clases mencionadas• operaciones utilizadas
– Por clase• atributos• operaciones• existencia de objetos
– Por estado
• Uso de herramientas para analizar y organizar requisitos
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 25
Métricas de calidad en los requisitos del software
• Qué sentido tiene realizar medidas de calidad – personal– coste
• Métricas de calidad: cómo de bien están escritos los requisitos – propiedades globales– propiedades individuales
• Métricas de calidad: cómo de efectivos son los procesos– medidas de la efectividad de la inspección de requisitos– medidas de la efectividad del proceso de análisis de requisitos
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 26
Los requisitos del software en el Estándar ESA
• ESA software engineering standards (PSS-05-0)– Chapter 3. The software requirements definition phase
• 3.3. Actividades: modelo lógico; tipos de requisitos y propiedades
• Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1)– Chapter 3. Using Object-Oriented Methods with PSS-05
• 3.4. Modelo lógico = modelo de casos de uso + modelo conceptual
• Guide to the software requirements definition phase (PSS-05-03)– Chapter 2. The software requirements definition phase
• 2.3. Construcción del modelo lógico (rendimiento, riesgos, protopipado)• 2.4. Tipos y propiedades de los requisitos del software• 2.6. Revisión de los requisitos del software
– Chapter 5. The software requirements document
• 5.1. Introducción: lo que debe ser, lo que no debe ser• 5.3. Estilo: claridad, consistencia, modificabilidad
• 5.6. Contenido
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 27
Introducción al diseño arquitectónico
• La transición del análisis al diseño– significados equívocos de “análisis”– niveles de abstracción en el diseño
• Arquitectura del software– analogía con la arquitectura civil: requisitos � diseño– madurez de la arquitectura del software
• Criterios para la selección de una arquitectura– extensibilidad– modificabilidad– simplicidad– eficiencia
• ¿Cómo lograr una descomposición modular eficaz?– cohesión y acoplamiento– diseñar para el mantenimiento
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 28
Cohesión y acoplamiento
1
2 3 4
5 6Alta cohesión Bajo acoplamientoPuente
componente
componente
Adaptado de E. Braude,Software Engineering: An Object-Oriented Perspective
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 29
Estilos arquitectónicos (Shaw & Garlan)
• Flujo de datos– Tuberías y filtros– Secuencial por lotes
• Componentes independientes– Sistemas cliente-servidor– Procesos paralelos – Sistemas de eventos
• Máquinas virtuales• Repositorios
– Bases de datos– Entornos de desarrollo– Editores– Sistemas hipertexto
• Arquitectura en capas
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 30
Arquitectura de flujo de datos: DFDs
account #& deposit
balancequery
account #& deposit
account #
User
Make
inquiry
account
database
deposittransaction
accountdata
Get
deposit
Get
inquiry
Validate
inquiry
Do
deposit
transaction
Create
account
summary
Validate
deposit
errorerror
Printer
member
banks
bank name
Display
account
account #
accountdata
accountdisplay
Adaptado de E. Braude,Software Engineering: An Object-Oriented Perspective
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 31
Arquitectura de tuberías y filtros
filter
filter
filter
filter filter
filter
pipe
< stream
stream >
pipe
Adaptado de E. Braude,Software Engineering: An Object-Oriented Perspective
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 32
Adaptado de E. Braude,Software Engineering: An Object-Oriented Perspective
Arquitectura de tuberías y filtros: clases y métodos
Modelo de clases
Arquitectura
Bank
datarecord Logtransaction
analyze
deposit
deposit data
withdraw
withdrawal
account data
bank address
transaction result
transaction result
transaction
account data
account data
Comm
account data
Transactionanalyze()record()
Accountwithdraw()deposit()*
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 33
Arquitectura de procesos paralelos
Customer:customer n
withdraw
Customer:customer n+1
Session:session k
Session:session m
deposit
create
Account:customer n+1 saving
Account:customer nchecking
create retrieve
retrieve
Adaptado de E. Braude,Software Engineering: An Object-Oriented Perspective
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 34
Arquitectura de máquina virtual
260Mhz & 64MB
400Mhz & 128MB
260Mhz & 32MB
assemble {{ 260MHz & 64MB }and{ { 400MHz & 128MB } and { 260MHz & 32MB } }
}
Adaptado de E. Braude,Software Engineering: An Object-Oriented Perspective
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 35
Arquitectura en capas
Definición de reglas
del juego
Jugador TurnoMovimiento
Lanzamiento
de Dado
Selección
de Ficha
Avance y Captura
Ejecución de movimientos
Representación
gráfica
«uses»
«uses»
Adaptado de E. Braude,Software Engineering: An Object-Oriented Perspective
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 36
El diseño arquitectónico en el Estándar ESA
• ESA software engineering standards (PSS-05-0)– Chapter 4. The architectural design phase
• 4.3. Actividades: modelo físico (estático y dinámico)
• Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1)– Chapter 3. Using Object-Oriented Methods with PSS-05
• 3.5. Modelo físico, reutilización, criterios de calidad del diseño
• Guide to the software architectural design phase (PSS-05-04)– Chapter 2. The architectural design phase
• 2.3. Construcción del modelo físico (descomposición, NFR, calidad...)• 2.4. Especificación del diseño arquitectónico (funciones – componentes)• 2.7. Revisión de los requisitos del software
– Chapter 5. The architectural design document
• 5.1. Introducción: lo que debe ser, lo que no debe ser• 5.2. Estilo: claridad, consistencia, modificabilidad
• 5.6. Contenido
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 37
Patrones Arquitectónicos: Arquitectura en Cuatro Capas
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 38
Patrones Arquitectónicos: Arquitectura en Tres Escalones
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 39
Patrones de Diseño
Creación Estructura Comportamiento
Abstract Factory Builder Factory Method
Prototype Singleton
Adapter Bridge Composite
Decorator Façade
Flyweight Proxy
Chain of Responsibility Command Interpreter
Iterator Mediator
Memento Observer State
Strategy Template Method
Visitor
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 40
Herencia vs. Delegación
c.x( ) c.x( )
A
x( )
B
x( )
C
x( )
1
c
1
c
Dos formas de reutilizar / refactorizar
A B
C
x( )
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 41
Patrones de Diseño: Abstract Factory
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 42
Patrones de Diseño: Decorator
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 43
Patrones de Diseño: Command
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 44
El diseño detallado en el Estándar ESA
• ESA software engineering standards (PSS-05-0)– Chapter 5. The detailed design and production phase
• 5.3. Actividades: diseño detallado / no producción– 5.3.1. Descomponer componentes arquitectónicos en módulos programables
• 5.4. Salidas: omitir código y manual de usuario
• Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1)– Chapter 3. Using Object-Oriented Methods with PSS-05
• 3.6. Conversión automática modelo ⇔ código (round-trip engineering)
• Guide to the software detailed design and production phase (PSS-05-05)– Chapter 2. The detailed design and production phase
• 2.3. Descomposición, diseño defensivo, optimización, etc.
– Chapter 5. The detailed design and production document
• 5.1. Introducción: lo que debe ser, lo que no debe ser• 5.2. Estilo: claridad, consistencia, modificabilidad
• 5.6. Contenido
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 45
Entrega final de documentación
• Estructura del documento único final del proyecto– Documento principal del proyecto (ej. IS2-G05.doc)
• Capítulos 1-4: URD + SRD + ADD + DDD (últimas versiones)• Anexo I: revisiones recibidas del equipo revisor y respuestas a las revisiones
– URD (r + rr) + SRD (r + rr) + ADD (r + rr) + DDD (r + rr)
• Anexo II: revisiones enviadas al equipo revisado– URD (r) + SRD (r) + ADD (r) + DDD (r)
• Anexo III: transparencias de la exposición pública (sólo impreso, 2xP)
– Exposición pública del proyecto (ej. IS2-G05.ppt): aprox. 15-16 transparencias– Recuento de horas del proyecto (ej. IS2-G05.xls)
• Fecha límite– 16 mayo: envío por correo a profesores
– 17 mayo: ejemplar impreso (doc+ppt), espiral, tapas duras
• Calendario de exposiciones
Proyecto Práctico de Análisis y Diseño Orientado a Objetos 46
Examen final
• 30% Parte teórica de la calificación– 10% Evaluación de la propuesta de preguntas de test– 20% Calificación del examen final de test – ELIMINATORIO
• Cada equipo propone tres preguntas– Cada pregunta tiene cuatro posibles respuestas (a, b, c, d)– Sólo una respuesta acertada por cada pregunta– Las respuestas equivocadas no puntúan negativamente– Fecha límite para el envío: 6 junio
– Formato del envío
• Examen = selección definitiva de preguntas• ¿Por qué no conviene “filtrar” las preguntas?
top related