22 documentación y reutilización de código · enviarse una copia del programa para ser...
TRANSCRIPT
Estructuras de datos (Prof. Edgardo A. Franco)
1
Tema 22: Documentación y reutilización de código
M. en C. Edgardo Adrián Franco Martínez http://[email protected]
@edfrancom edgardoadrianfrancom
Contenido• Software
• Ingeniería del software• Ciclo de vida del software
• Documentación de software• Documentación externa• Documentación interna
• Código autodocumentado• Comentarios efectivos• Técnicas para comentar código• Reutilización de código
• Tipos de reutilización• Copiar y pegar
• Reutilizar código en C• Concepto de Librería en Programación• Biblioteca estándar de C• Creación de bibliotecas para C
• Generación de código ejecutable• Generando una librería para C
2
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Software• Comúnmente se asocia el termino Software se
asocia con Programa de computadora. Sin embragouna definición más adecuada dentro del contextode la ingeniería en sistemas computacionales sería:
Programa de computadora y la documentación asociada a este. [Ian Sommerville, 2005]
• Nota: Los productos de software se puedendesarrollarse para algún cliente en particular o paraun mercado general. 3
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Ingeniería del software• La ingeniería del software es un disciplina de
ingeniería que comprende todos los aspectos de laproducción de software.
• ¿Cuál es la diferencia entre ingeniería de softwarey ciencia de la computación?
• La ciencia de la computación comprende la teoría ylos fundamentos; la ingeniería de softwarecomprende las formas practicas para desarrollar yentregar un software útil.
4
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
• ¿Cuál es la diferencia entre ingeniería de softwaree ingeniería de sistemas?
• La ingeniería de sistemas se refiere a todos losaspectos del desarrollo de sistemas informáticos,incluyendo hardware, software e ingeniería deprocesos. La ingeniería de software es parte de esteproceso
5
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Ciclo de vida del software
6
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Definición de necesidades
• Los clientes e ingenieros definen el software aproducir y las restricciones de su operación.
• Se solicitan y recopilan los requerimientos ynecesidades a satisfacer.
7
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Análisis
• Con base en las necesidades considerarrestricciones, flujo y procesamiento de lainformación así como las arquitecturas y tecnologíasmás adecuadas para su construcción.
8
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Diseño
• Construcción del sistema en papel, incluyendo todala documentación y representaciones graficasnecesarias para construir el software por un equipode trabajo.
9
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Codificación
• Implementar el diseño apoyándose de lasherramientas de programación necesarias.
• Es importante que conforme la codificación vaavanzando, se documente en el la relacióncodificación-diseño.
10
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Pruebas
• Las pruebas de software, son los procesos quepermiten verificar y revelar la calidad de unproducto software. Son utilizadas para identificarposibles fallos de implementación, calidad, ousabilidad de un programa.
11
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Validación
• Las pruebas de validación en la ingeniería desoftware son el proceso de revisión que el sistemade software producido cumple con lasespecificaciones y que cumple su cometido. Esnormalmente una parte del proceso de pruebas desoftware de un proyecto, que también utilizatécnicas tales como evaluaciones, inspecciones, ytutoriales. La validación es el proceso de comprobarlo que se ha especificado es lo que el usuariorealmente quería.
12
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Mantenimiento y evolución
• El mantenimiento del software contempla lamodificación de un producto de software despuésde la entrega para corregir averías, para mejorarfuncionamiento u otras cualidades, o para adaptarel producto a nuevas utilidades y funciones.
• Mantenimiento correctivo: La modificación reactivade un producto de software se realizó después deentrega para corregir problemas descubiertos.
13
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
• Mantenimiento adaptante: La modificación de unproducto de software se realizó después de entregapara mantener un producto de software usable unambiente cambiante o que cambiaba.
• Mantenimiento de perfectivo: Modificación de unproducto de software después de la entrega paramejorar funcionamiento o capacidad demantenimiento.
• Mantenimiento preventivo: Modificación de unproducto de software después de que entrega paradetectar y para corregir averías latentes en el productode software antes de que se conviertan en averíaseficaces. 14
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Documentación del software• Aunque muchas veces es omitida por los
principiantes y los que se dedican a producirresultados rápidos debido a que no es tan atractivacomo la codificación, la documentación --al igualque el diseño-- es una marca del orgullo profesionalque el programador pone en sus creaciones.
• Existen dos clases de documentación:
• Documentación externa
• Documentación interna15
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
• En esta categoría están no sólo los más visibles para losusuarios tales como los manuales de operación y deinstalación del software, sino también los documentosde diseño utilizados durante el desarrollo del software:copia de los requerimientos, copia del algoritmoempleado así como de las alternativas consideradas,diagramas de flujo, copia de los documentos que seutilizan para el diseño de las entradas y salidas visualeso impresas, copia de los estándares de desarrollo,listado más actual del código fuente, documentosrelacionados con las modificaciones hechas al proyecto,así como notas importantes de diseño usadas por losdesarrolladores durante el diseño y la implementación,entre otras.
Documentación Externa
16
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Documentación Interna• A diferencia de la documentación externa, la
documentación interna se encuentra dentro del códigomismo y es la más detallada de las dos. Puesto que es lamás cercana al código, la documentación interna es laque se suele mantener más actualizada y correcta amedida que el código se modifica.
• La documentación interna es muy importante puestoque facilita grandemente la lectura y comprensión delcódigo, tanto para el propio programador como paratodos los que necesiten leerlo, y es especialmente útil enlas fases de prueba y mantenimiento de los programas. 17
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
• Es importante la relación que se mantenga entre ladocumentación interna con el diseño y parte de ladocumentación externa.
• El principal contribuyente de la documentación anivel de código no son los comentarios, sino el buenestilo de programación, el cual incluye una buenaestructura de programa, el uso de un acercamientodirecto y fácilmente comprensible, buenos nombresde variables y de rutinas, uso de constantesnombradas en lugar de valores literales, un esquemaclaro y la minimización de la complejidad del controlde flujo y de las estructuras de datos. 18
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
• El código de los programas escritos con un estilopobre de programación casi siempre es críptico.
• Aún cuando se le trate de explicar usandocomentarios, su calidad no se ve mejorada:permanece oscuro, difícil de leer y de modificar.
• La única manera de clarificarlo es rescribiéndolousando un mejor estilo de programación.
• De este modo el código será más legible, aún si noposee comentarios que lo expliquen. 19
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
• El código que es legible por sí solo se denominacódigo autodocumentado, y es una característicadeseable para cualquier programa de software.
• Tal código descansa en el buen estilo deprogramación utilizado en su creación parasobrellevar la mayor parte de la documentacióninterna.
• En un código bien escrito, los comentarios son piezasde información realmente necesarias quecomplementan la legibilidad y no una carga extraque, aunque de utilidad, hace que se incremente eltamaño del código fuente. 20
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Código autodocumentado• Si al escribir el código se cumple con los siguientes
cuestionamientos, es posible indicar que un códigoen C es autoexplicativo.
Funciones• ¿El nombre describe exactamente lo que hace?
• ¿Desempeña una procedimiento o función bien definido?
• ¿Las variables y datos estructurados de cada función corresponden a dicha función?
• ¿Es obvio y claro el prototipo de cada función?
21
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Variables
• ¿Los nombres son lo suficientemente descriptivos?
• ¿Son las variables usadas únicamente para elpropósito para el cual fueron nombradas?
• ¿Se utilizan constantes nombradas en lugar deconstantes literales?
• ¿La convención de nombres de identificadoresempleada distingue entre los nombres de tipos dedatos, los tipos enumerados, las constantesnombradas, las variables locales y las variablesglobales?
22
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Flujo del programa
• ¿Es claro el flujo de ejecución a través del código?
• ¿Están las sentencias de código relacionadasagrupadas o cercanas entre sí?
• ¿Son las estructuras de control lo suficientementesimples, tal que minimizan la complejidad?
• ¿Cada ciclo desempeña una y solo una función, comodebería hacerlo una rutina bien diseñada?
• ¿Se ha minimizado el anidamiento (de ciclos y rutinaspor ejemplo)?
23
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Comentarios efectivos• Los comentarios erróneos al código pueden
confundir a sus lectores, incluso si el código se haescrito usando un buen estilo de programación. Elcódigo con este tipo de comentario es peor que elcódigo sin comentarios. Por otro lado, si loscomentarios son correctos pero sólo repitenverbosamente las sentencias de código, no añadenvalor al código mismo.
• Los comentarios pobres o crípticos no son de muchaayuda y tienden a ser mal entendidos o pasados poralto debido a que obstruyen la correctacomprensión del código. 24
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
• El comentar efectivamente no consume muchotiempo. Los comentarios excesivos son tan maloscomo la existencia de pocos de ellos, por lo quelograr el equilibrio es importante.
• Puede tomar mucho tiempo escribir comentarios pordos razones comunes. La primera, el estilo decomentarios puede consumir demasiado tiempo oser tedioso.
• Un estilo que requiera mucho trabajo mantener es undolor de cabeza: Si los comentarios son difíciles decambiar, no se cambiarán: se volverán imprecisos yllevarán a confusión, lo cual es peor que no tenercomentarios del todo.
25
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
• El comentar podría ser difícil debido a que laspalabras para describir lo que el programa estáhaciendo no surgen fácilmente.
• Eso usualmente es una señal de que no se entiendebien lo que hace el programa.
• El tiempo que se invierte en “comentar” es enrealidad tiempo invertido en comprender mejor elprograma, lo cual es tiempo que necesita invertirsesin importar si lo comentas o no.
26
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
• El ir comentando el código a medida que se escribetiene la ventaja de que se va introduciendo mientrasmás frescos se tienen los detalles de programación.Comentar al final, por el contrario, consume mástiempo puesto que se deben recordar los detalles ylas sutiles suposiciones de la programación, o leerde nuevo el código para comprenderlo, antes deescribir los comentarios, haciendo que estos seanmenos precisos.
• Si el código requiere mucha concentración es unaclara señal de que es complejo, pero una alternativasería utilizar el algoritmo como punto de partidapara la codificación e ir convirtiendo las frases encomentarios a medida que codificamos.
27
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
• Si el diseño es difícil de codificar, hay que simplificarlo antes depreocuparse del código o los comentarios.
• Si se usa un algoritmo (diagrama de flujo, pseudocódigo, etc.) paraclarificar ideas, la codificación será directa y los comentariosautomáticos.
• Los comentarios incrementan el tamaño de los archivos de códigofuente.
• Aunque los compiladores modernos son capaces de obviar loscomentarios al momento de traducirlos a código objeto y a programasejecutables, en algunos ambientes como la Internet donde debeenviarse una copia del programa para ser interpretado en máquinasclientes (código ASP y applets de Java y JavaScript, por ejemplo) eltiempo invertido en enviar la información extra que representan loscomentarios a través de la red puede ser prohibitivo pues penaliza eldesempeño de las aplicaciones, aún si éstas se ejecutan en hardwareremoto eficiente. Sin embargo, eso no quiere decir que no se debacomentar el código. 28
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
• Aún así, una solución práctica para este problema estener dos versiones del código: una comentada yotra en producción. El truco consiste en escribir unprograma que filtre los comentarios de los archivosfuente (que busque y deseche del código todo eltexto que se halla protegido por las secuenciassintácticas que el lenguaje usa para los comentarios)antes de pasar al proceso de compilación oimplantación en los servidores de las aplicacionesremotas.
• El utilizar el algoritmo o el seudocódigo como puntode partida para la codificación tendrá como efectocolateral comentarios muy precisos.
29
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Técnicas para comentar código• Comentarios por bloques: comentarios de una o dos
líneas que describan bloques de código.
• Escribe comentarios que describan la intención delcódigo: en lugar de repetir el código, escribircomentarios que describen el propósito del código.
• Enfoca tus esfuerzos de documentación en el códigomismo: el código mismo debería ser la mejordocumentación.
• Enfoca el comentario del bloque en el por qué en lugardel cómo: los comentarios que explican cómo se hacealgo están a un nivel de programación, algo técnicos, enlugar de estar a nivel del problema.
30
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
• Evita las abreviaturas: los comentarios no deben serambiguos, sino fácilmente legibles sin el trabajo deadivinar abreviaturas.
• Documenta las sorpresas: si hay lago que no esobvio a partir del código mismo. Cada truco técnicoque se use debería ser comentado.
• Comenta cualquier truco que evite un error o unafuncionalidad no documentada en un lenguaje oentorno: si es un error, probablemente no estédocumentado. Aún si está documentado en algunaparte, no daña el documentarlo de nuevo en tucódigo. Si es una funcionalidad indocumentada,debería estarlo en tu código
31
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
• Comenta las unidades de datos numéricos: cadavariable o campo que vaya a contener cantidadesnuméricas que representen unidades de medidadebería tener documentada la unidad de medidaque representa. Así, si una variable representarálongitud debería documentarse si representarácentímetros, pulgadas, metros, kilómetros, etc. Sison coordenadas, si indicarán latitud, longitud oaltitud, y si está en grados o radianes; No asumasque las unidades son obvias pues para un nuevoprogramador u otro que esté trabajando en otraparte del programa/sistema, no lo serán.
32
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
• Coloca un comentario antes de cada estructura decontrol: las estructura de control a menudonecesitan explicación, y el mejor lugar paradocumentarlas es justo el espacio antes de ellas. Enel caso de una sentencia de selección, debe incluirsela razón para la decisión y un resumen del resultado.Si es un ciclo, debe indicarse su propósito y aspectosimportantes de su ejecución.
• Describe cada función con una o dos oraciones en lalínea anterior a ella: un comentario descriptivobreve permitirá conocer rápidamente el propósito dela función. Si tienes dificultades en crear unadescripción corta para la rutina es una clara señal deque el diseño de tu programa no es tan bueno comodebería.
33
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
• Documenta los parámetros de entrada y salida: la formamás práctica de documentar variables de entrada ysalida de una función es colocar esos comentarios justobajo la línea de encabezado de la rutina misma.
• Comenta las limitaciones de la función: si la funcióndevuelve un resultado numérico, indica su precisión. Si larutina funciona sólo para estructuras de datos de ciertotamaño, indícalo. Si se sabe de modificaciones que haránque la rutina deje de funcionar, documentarlas también.Documenta los efectos globales de las modificacionesque realiza la rutina
• Si dentro de la rutina se modifica una variable oestructura de datos global: debe describirse de formaexplícita esta modificación.
34
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Reutilización de código
• La reutilización de código se refiere alcomportamiento y a las técnicas que garantizan queuna parte o la totalidad de un programa informáticoexistente se puedan emplear en la construcción deotro programa. De esta forma se aprovecha eltrabajo anterior, se economiza tiempo, y se reducela redundancia.
35
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Tipos de reutilización
• Reutilización oportunistas
• Ocurre cuando al iniciar un proyecto, el programadorse da cuenta de que hay componentes existentes quese puede reutilizar.
• Reutilización planificada
• Sucede cuando un equipo planea estratégicamentelos diseños de componentes que serán reutilizablesen futuros proyectos.
36
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Copiar y pegar• La manera más fácil de reutilizar código es copiarlo total o
parcialmente desde el programa antiguo al programa endesarrollo. Pero es trabajoso mantener múltiples copias delmismo código, por lo que en general se elimina laredundancia dejando el código reusable en un único lugar, yllamándolo desde los diferentes programas. Este proceso seconoce como abstracción procedimental.
• La abstracción de procedimientos y funciones puede verseclaramente en las bibliotecas de software, en las que seagrupan varias operaciones comunes a cierto dominio parafacilitar el desarrollo de programas nuevos. Hay bibliotecaspara convertir información entre diferentes formatosconocidos, acceder a dispositivos de almacenamientoexternos, proporcionar una interfaz con otros programas,manipular información de manera conocida (como números,fechas, o cadenas de texto).
37
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Reutilizar código en C• Para que el código existente se pueda reutilizar,
debe definirse alguna forma de comunicación ointerfaz. Esto se puede dar por llamadas a unafunción o procedimiento.
• En lenguaje C como sabemos únicamente podemosmodelar los procedimientos con funciones queretornan un dato tipo void, estas funciones deberánestar siempre bien diseñadas para poder reutilizarlasen más programas. Si además las agrupamos segúnsu comportamiento puede formarse nuestraspropias librerías de funciones útiles para variosdesarrollos distintos.
38
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Concepto de Librería en Programación
• Es un conjunto de subprogramas utilizados paradesarrollar software.
• Las bibliotecas contienen código y datos, queproporcionan servicios a programas independientes,es decir, pasan a formar parte de estos. Esto permiteque el código y los datos se compartan y puedanmodificarse de forma modular.
39
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
• Algunos programas ejecutables pueden ser a la vezprogramas independientes y bibliotecas, pero lamayoría de estas no son ejecutables.
• Ejecutables y bibliotecas hacen referencias (enlaces)entre sí a través de un proceso conocido comoenlace, que por lo general es realizado por unsoftware denominado enlazador.
• Las bibliotecas o librerías, pueden ser clasificadas según el tipo de enlace que se realice para ser parte de un programa final en:• Bibliotecas estáticas
• Bibliotecas dinámicas40
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Biblioteca estándar de C
• La biblioteca estándar de C es una recopilación dearchivos cabecera y bibliotecas con funciones,estandarizadas por un comité de la OrganizaciónInternacional para la Estandarización (ISO), queimplementan operaciones comunes, tales como lasde entrada y salida o el manejo de cadenas. Adiferencia de otros lenguajes como COBOL, Fortran,o PL/1, C no incluye palabras clave para estas tareas,por lo que prácticamente todo programaimplementado en C se basa en la biblioteca estándarpara funcionar
41
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Creación de bibliotecas para C
• Es posible generar biblioteca para C generando nuestrospropios archivos cabecera y bibliotecas con funciones.
Archivos cabecera
• Es un archivo, que el compilador incluye al procesaralgún código fuente, este contiene, normalmente, unadeclaración directa funciones, variables, u otrosidentificadores. Aquellos programadores que deseandeclarar identificadores estándares en más de un archivofuente pueden colocar esos identificadores en un únicoheader file, que se incluirá cuando el código quecontiene sea requerido por otros archivos.
42
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Bibliotecas con funciones
• Son los códigos fuentes que definen las funciones delos archivos de cabecera y son independientes. Estospueden ser compilados por separados y tenersecomo el código fuente original o códigos objetoscapaces de ser enlazados por otros códigos fuentesque hagan uso de estas definiciones y programas.
CompiladorCódigo objeto
EnlazadorPrograma ejecutable
Biblioteca / Otros códigos objeto
Archivos de Cabecera / Cabeceras
independientes
Código fuente
43
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Generación de código ejecutable
• Como se ve en la etapa de compilación de unlenguaje compilado, se obtiene un código objeto, elcuál contiene sólo la traducción del código fuente.Esto no es suficiente para ejecutar realmente elprograma. Es necesario incluir los archivos debiblioteca o módulos compilados de maneraindependiente.
Compilador Código objeto EnlazadorPrograma ejecutable
Biblioteca / Otros códigos objeto
Archivos de Cabecera / Cabeceras
independientes
Código fuente
44
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
Generando una librería para C• Generar los siguientes archivos, con los contenidos que se
muestran y guardarlos con los nombres dados.
#include <stdio.h>
#include "mi_libreria.h"
int main (void)
{
int n,res;
printf("\nIntroduce un número entero")
scanf("%d",n);
res=mi_funcion01(n);
printf("\nEl resultado es: %d",res)
return 0;
}
programa.c 45
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez
def_mi_libreria.c
#include "mi_libreria.h"
int mi_funcion01(int numero)
{
return numero*CONSTANTE;
}
#define CONSTANTE 100
int mi_funcion01(int numero);
mi_libreria.h
• Generar el código objeto de la librería
gcc def_mi_libreria.c –c
• Compilar el programa
gcc programa.c def_mi_libreria.o –o programa
46
22
Do
cum
enta
ció
n y
reu
tiliz
ació
n d
e có
dig
o
Alg
ori
tmia
y p
rogr
amac
ión
est
ruct
ura
da
Pro
f. Ed
gard
o A
dri
án F
ran
co M
artí
nez