Comentarios a nivel de
especificación
Tipos de datos abstractos. Cada tipo de datos abstractos
(clase o interfaz) debería tener:
- Una sección de visión general que dé una explicación de una o dos líneas sobre qué objetos del tipo representan y si son mutables.
- Una lista de campos de especificación. Podría haber sólo uno; por ejemplo, un conjunto podría tener el campo elems representando al conjunto de elementos. Cada campo debería tener un nombre, un tipo y una breve explicación. Podría resultarle útil definir campos derivados adicionales que facilitaran la escritura de las especificaciones de los métodos; para cada uno de éstos, debería indicar que es derivado y explicar cómo se ha obtenido a partir de los otros campos. Puede que haya invariantes de especificación que restrinjan los posibles valores de los campos de la especificación; si es así, debería precisarlos.
Especificaciones del método. Todos los métodos públicos de las
clases deberían tener especificaciones; los métodos privados complicados
también deberían especificarse. Las especificaciones del método deberían seguir
la estructura requires (requiere), modifies (modifica),
throws (lanza), effects (resulta), returns (devuelve)
que aparece descrita en el boletin de especificaciones.
Me gustaria señalar que una buena documentacion del codigo permitirá conocer detalles importantes de éste y con lo cual se espera tener mayor facilidad a la hora de leer las instrucciones de la aplicación ya sea por parte del creador o por otra persona.
ResponderEliminarcabe resaltar sobre este tipo de documentación interna que se hace del codigo, es fundamental para que el cliente entienda todo el sistema si domina el area, y si existe la futura necesidad de hacer hacer modificación por nuevos requerimientos facilita al programador el entendimiento de todo el sistema desde su codigo, indifirentemente si fue el creador del mismo o un nuevo integrante del equipo de trabajo
ResponderEliminar