| Respuesta: Practica programacion en c :)
SEGUIMOS
Una vez el programa funcione se puede analizar su eficiencia para ver que si se ordenan
los datos se mejora la eficiencia de ejecución. Si se analiza e implementa esta
optimización se valorará extra. Se espera que se analice el proceso y se ordenen todos
los datos que puedan hacer que la ejecución sea más rápida. El programa generará una
versión ordenada de los ficheros de entrada para que la siguiente ejecución pueda usar
los ficheros ordenados. Estos ficheros ordenados se llamarán igual que los ficheros de
entrada, pero con la terminación _ord añadida al fichero producido. Por ejemplo el
fichero ordenado del fichero asignaturas.txt se llamaría asignaturas_ord.txt. Estos
ficheros ordenados se generaran sólo cuando los ficheros de entrada no estén ordenados.
Se recomienda diseñar las funciones para cada fichero, de forma que la misma función
pueda ser utilizada para entrada y para salida de datos. Para ello, estas funciones
deberían tener un parámetro adicional, que indique si se realizará una llamada de lectura
o de escritura
Estructuración del código y buenas prácticas
Se pide separar el código en al menos 5 ficheros:
1. un fichero de cabecera (.h),
2. una librería de funciones de gestión de entrada y salida de datos a ficheros,
3. una librería de funciones de ordenación y búsqueda,
4. una librería de funciones de horarios,
5. un fichero con solo el main del programa.
No importa si alguna de estas librerías (2, 3 y 4) solo contiene una función. Recordad
también que en algunos casos, una función puede tener sentido aunque contenga una –
unica línea de código. Esto permitirá darle un nombre a esta funcionalidad y nos forzará
a parametrilizarla para generalizarla, de forma que pueda ser fácilmente usada por uno
mismo o por otros programadores, en otros programas.
Se pide elaborar el banco de pruebas y entregar las ejecuciones. Esto significa que se
tiene que entregar tantos ficheros de entrada distintos como casos diferentes se necesite
ejecutar por separado para verificar exhaustivamente el código. Se debe intentar diseñar
las pruebas de tal forma que con las mínimas ejecuciones se verifiquen el máximo
número de casos y por tanto intentar que el banco de pruebas sea pequeño (aunque
exhaustivo). Los ficheros de entrada deben ser entregados con su correspondiente
fichero de salida resultante de la ejecución. Asegurar que los nombres de ficheros
permiten relacionar los ficheros de una prueba al completo. Estos ficheros de salida
contendrán toda la información necesaria para comprobar que la ejecución es correcta.
Al menos una de las ejecuciones tiene que aportarse el fichero de salida con las trazas
activadas para ver el diseño y uso de las mismas. Estas trazas deberán ser activadas en
los casos que parezcan relevantes para demostrar que la ejecución es exhaustiva y
correcta.
Recordad las buenas prácticas:
1. Cada fichero tiene que tener una cabecera de comentario que relacione los
distintos ficheros de un programa y que incluya descripción, uso, autor, fecha,
actualizaciones…
2. Cada función tiene que tener una cabecera de comentario que explique su
definición y uso (i.e. que hace, si fuera complejo cómo lo hace, que parámetros
define y como se deben usar).
3. El código tiene que estar comentado de forma útil.
4. El main() del programa tiene que ser poco más que una lista de llamadas a
funciones (no debe contener casi código, y se asemejará casi a una definición en
pseudo-codigo de los grandes procesos del programa).
5. Incluid un documento adicional (memoria del programa) que documente el
diseño y justifique las decisiones más relevantes (si en un futuro reutilizáis este
código en otra práctica, vais a necesitar esta documentación).
Esta memoria deberá entregarse en formato editable (Word o RTF) así como en PDF.
Constará de dos partes. La primera parte de un máximo de 3 páginas, incluirá una
explicación del funcionamiento general del código, junto con la justificación de las
estructuras de datos y las funciones utilizadas, y una breve descripción de cada fichero
de código y de cada función. La segunda parte de la memoria de un máximo de 2
páginas, describará el proceso de verificación del código, indicando el diseño de las
trazas, el banco de pruebas y sus correspondientes ejecuciones. La memoria debe ir
acompañada de una portada con el nombre y NIA de los miembros del grupo, fecha de
entrega y profesor de prácticas.
Respecto a las cabeceras de comentarios, es conveniente que adoptéis un formato
estándar y lo utilicéis en todos los programas de la asignatura. Os recomendamos mirar
el código fuente de aplicaciones de programación libre para ver distintos ejemplos.
De ahora en adelante, NO se aceptarán programas que no estén bien comentados y
que no incluyan las cabeceras de fichero y funciones mencionadas, así como las
justificaciones necesarias y adecuadas en la memoria del programa.
Criterios de evaluación
Al evaluar la práctica se tendrán en cuenta los 6 aspectos que se listan a continuación:
- Memoria (15%)
- Estilo/claridad del código (15%)
- Estructuras de datos (10%)
- Descomposición funcional (20%)
- Ejecución (20%)
- Verificación de código (Trazas y banco de pruebas) (20%)
- Análisis e implementación de optimización de la eficiencia del programa por la
ordenación de datos (10% adicional)
ARCHIVOS
matricula.txt
NIA, grado, lista_asig
227788,000200,(200100, 200101, 200102, 200103, 250104)
227788,000200,(200100, 200101, 200102, 200103, 250104, 300126)
227788,000200,(200100, 200101, 200102, 200103, 250104)
227788,000200,(200100, 200101, 200102, 200103, 250104)
profesores.txt
código_prof, lista_restricciones_horarias
000230, (16/07/2014,M), (23/07/2014,M), (19/07/2014,E), (21/07/2014, E), (22/07/2014, E)
033454, (25/07/2014,E), (19/07/2014,T), (22/07/2014,E), (18/07/2014, M)
033487, (18/07/2014,M), (19/07/2014,T), (16/07/2014,E), (17/07/2014, M)
030811, (18/07/2014,M), (19/07/2014,E)
145320, (16/07/2014,E), (17/07/2014,E), (19/07/2014,E), (18/07/2014, E)
asignaturas.txt
asig, grado, tipo, curso, trimestre, franja, num_alumnes, lista_profs
200100, 000200, B, 2, 1, M, 40, (000230)
200101, 000200, B, 2, 1, M, 67, (033454, 000230)
200102, 000200, B, 2, 1, M, 50, (033454)
200103, 000200, B, 2, 1, M, 150, (000230)
250104, 000200, P, 2, 1, M, 70, (000230)
250105, 000200, P, 2, 1, M, 39, (033487)
250106, 000200, P, 2, 1, M, 65, (030811)
300126, 000200, B, 3, 1, T, 53, (030811)
300125, 000200, B, 3, 1, T, 58, (145320)
300123, 000200, B, 3, 1, T, 43, (145320, 033454)
300124, 000200, B, 3, 1, T, 61, (145320)
350129, 000200, P, 3, 1, T, 20, (000230)
350127, 000200, P, 3, 1, T, 43, (145320)
350128, 000200, P, 3, 1, T, 23, (033487)
100109, 000200, B, 1, 1, T, 324, (033487)
100110, 000200, B, 1, 1, T, 412, (145320)
100111, 000200, B, 1, 1, T, 301, (030811, 033454)
100108, 000200, B, 1, 1, T, 180, (033454)
150132, 000200, P, 1, 1, T, 70, (033454, 033487)
150131, 000200, P, 1, 1, T, 53, (030811, 000230)
150130, 000200, P, 1, 1, T, 92, (033487)
aules.txt
Código_aula, edificio, planta, capacidad
52.119, 52, 1, 120
52.019, 52, 0, 120
52.209, 52, 0, 120
52.105, 52, 1, 70
horario_examenes.txt
código_asig, fecha, franja, lista_aulas
100109, 000200, 23/07/2014, B, (52.109, 52.119)
100110, 000200, 22/07/2014, B, (52.109, 52.209) |