Universidad El Bosque

Programa: Ingeniería de Sistemas

Documentación de Código & GRASP

PROGRAMACIÓN 1
2021-10
Documentación de Código  Contrato de SW
Condiciones para que un método tenga éxito y
su(s) resultado(s)
Ejemplo

¿Qué suposiciones se deberían establecer

antes de ejecutar el método?
Ejemplo

• La lista de socios ya fue creada

• La cédula no es null ni vacía
• No se ha verificado si ya existe un soco con esa
cédula
• El nombre no es null ni vacío
Ejemplo

¿Cuál debería ser el resultado después de

ejecutar el método?
Ejemplo

• Todo funcionó bien y el socio se afilió al club.

• Se produjo un error y se informó del problema
con una excepción. El socio no quedó afiliado al
club.
Precondiciones
Exigencia para poder resolver el problema planteado a un método

Conjunto de suposiciones, expresadas como condiciones

• El estado del objeto que va a ejecutar el método (el valor de sus

atributos).
• El estado de algún elemento del mundo con el cual el objeto tenga
una asociación.
• Condiciones sobre los parámetros de entrada entregados al método.
Postcondiciones
Descripción del resultado obtenido después de ejecutar un método

Conjunto de condiciones que DEBEN ser verdaderas después de que el
método ha sido ejecutado, siempre y cuando NO se haya lanzado una
excepción.

• Una descripción del valor de retorno

• Una descripción del estado del objeto después de haber ejecutado el

método
 Precondiciones - Postcondiciones

Condiciones que se Compromisos que

impone en un método asume la ejecución de
para su cumplimiento dicho método

Si todas las condiciones de la precondición se cumplen

antes de llamar el método, éste asume el compromiso
de llegar a cumplir todas las condiciones incluidas en la
postcondición
 ¿Un método debe verificar en algún punto las
condiciones que hacen parte de la Precondición?

¿Qué lugar ocupan las excepciones en los

contratos?
¿Qué lugar ocupan las excepciones en los
contratos?
 Javadoc
Herramienta que busca dentro de TODAS las clases,
comentarios delimitados por los caracteres /** … */

Genera a partir de lo anterior, un conjunto de archivos

HTML de documentación de las clases involucradas en
un programa.
 Ejemplo de cómo documentar ….
/**
* Este método afilia a un nuevo socio al club
* <b>pre</b> La lista de socios está inicializada (no es
null). <br>
* <b>post</b> Se ha afiliado un nuevo socio en el club con los
Precondición
datos dados <br>
* @param cedula Es la cédula del nuevo socio. cedula != null,
cedula != " "
* @param nombre Es el nombre del nuevo socio. nombre != null,
nombre != " "
* @throws Exception si un socio con la misma cédula ya estaba
afiliado al club, dispara una excepción indicando que la nueva
afiliación no se pudo llevar a cabo

*/

public void afiliarSocio(String cedula, String nombre) throws

Exception{

}
 Ejemplo de cómo documentar ….
/**
* Este método afilia a un nuevo socio al club
* <b>pre</b> La lista de socios está inicializada (no es
null). <br>
* <b>post</b> Se ha afiliado un nuevo socio en el club con los
datos dados <br>
* @param cedula Es la cédula del nuevo socio. cedula != null,
Postcondición
cedula != " "
* @param nombre Es el nombre del nuevo socio. nombre != null,
nombre != " "
* @throws Exception si un socio con la misma cédula ya estaba
afiliado al club, dispara una excepción indicando que la nueva
afiliación no se pudo llevar a cabo

*/

public void afiliarSocio(String cedula, String nombre) throws

Exception{

}
 Ejemplo de cómo documentar ….
/**
* Este método afilia a un nuevo socio al club
* <b>pre</b> La lista de socios está inicializada (no es
null). <br>
Definición de
* <b>post</b> Se ha afiliado un nuevo socio en el club con los
datos dados <br> Parámetros
* @param cedula Es la cédula del nuevo socio. cedula != null,
cedula != " "
* @param nombre Es el nombre del nuevo socio. nombre != null,
nombre != " "
* @throws Exception si un socio con la misma cédula ya estaba
afiliado al club, dispara una excepción indicando que la nueva
afiliación no se pudo llevar a cabo
El método NO va a hacer
ninguna verificación de
*/
@param !=null, !=“ ”.
public void afiliarSocio(String cedula, String nombre) throws Aquel que haga el
Exception{ llamado DEBE garantizarlo
}
 Ejemplo de cómo documentar ….
/**
* Este método afilia a un nuevo socio al club
* <b>pre</b> La lista de socios está inicializada (no es
null). <br>
* <b>post</b> Se ha afiliado un nuevo socio en el club con los
datos dados <br>
* @param cedula Es la cédula del nuevo socio. cedula != null,
cedula != " "
* @param nombre Es el nombre del nuevo socio. nombre != null,
nombre != " "
* @throws Exception si un socio con la misma cédula ya estaba
afiliado al club, dispara una excepción indicando que la nueva
Lanzamiento
afiliación no se pudo llevar a cabo
de Excepciones
*/

public void afiliarSocio(String cedula, String nombre) throws

Exception{

}
 Ejemplo de cómo documentar ….
/**
* Este método afilia a un nuevo socio al club
* <b>pre</b> La lista de socios está inicializada (no es Si el método NO
null). <br>
* <b>post</b> Se ha afiliado un nuevo socio en el club con los fuera de tipo
datos dados <br>
* @param cedula Es la cédula del nuevo socio. cedula != null,
void
cedula != " "
* @param nombre Es el nombre del nuevo socio. nombre != null,
nombre != " "
* @throws Exception si un socio con la misma cédula ya estaba
afiliado al club, dispara una excepción indicando que la nueva
afiliación no se pudo llevar a cabo

*/
@return antes de
definir el Lanzamiento
public void afiliarSocio(String cedula, String nombre) throws de Excepciones
Exception{

}
Generando el Javadoc desde Eclipse…
Javadoc generado
 ¿Patrón?
Los PATRONES son una descripción de un problema y su solución que
recibe un nombre y que puede aplicarse en nuevos contextos.
Los patrones tienen nombres sugerentes que ayudan a identificarlos y
facilitan la comunicación.
Los patrones de diseño pretenden:
• Proporcionar catálogos de elementos reusables en el diseño de
sistemas software.
• Evitar la reiteración en la búsqueda de soluciones a problemas ya
conocidos y solucionados anteriormente.
• Formalizar un vocabulario común entre diseñadores.
• Estandarizar el modo en que se realiza el diseño.
• Facilitar el aprendizaje de las nuevas generaciones de diseñadores
condensando conocimiento ya existente.
 CARACTERÍSTICAS DE LOS
PATRONES DE DISEÑO
Un patrón de diseño resulta ser una solución a un problema de diseño.

Para que una solución sea considerada un patrón debe poseer ciertas
características.
• EFECTIVIDAD: Se debe haber comprobado esto resolviendo
problemas similares en ocasiones anteriores.
• REUTILIZABLE: Es aplicable a diferentes problemas de diseño en
distintas circunstancias.
 GRASP
General Responsability Assignment Software
Principles (or Patterns)

“Patrones Generales de Software para Asignación de

Responsabilidades”
Objetivo de GRASP
Ayudar a entender el diseño de objetos esencial,
aplicando el razonamiento de diseño de una
manera metódica, racional y explicable
Listado de Principios GRASP
• Experto en Información
• Creador
• Controlador
• Alta Cohesión
• Bajo Acoplamiento
• Polimorfismo
• Fabricación Pura
• Indirección
• Variaciones Protegidas
Listado de Principios GRASP
• Experto en Información
• Creador
• Controlador
• Alta Cohesión
• Bajo Acoplamiento
• Polimorfismo
• Fabricación Pura
• Indirección
• Variaciones Protegidas
EXPERTO EN INFORMACIÓN

“Todas las clases de dominio deberían tener

lógica de acceso a datos”

Genera problemas de separación de intereses, cohesión,

acoplamiento y duplicación
EXPERTO EN INFORMACIÓN

Mantiene el encapsulamiento de la información, ya que los

objetos usan su propia información para realizar las tareas. Esto
ayuda a tener un bajo acoplamiento

El comportamiento es distribuido a través de las clases que

tienen la información requerida, propiciando clases más
cohesivas, fáciles de entender y mantener.
Aplicación: EXPERTO EN INFORMACIÓN

En un negocio de ventas, se necesita conocer el importe total de una

venta. ¿Quién es el responsable de conocer el importe total de la
venta?
 CREADOR Y CONTROLADOR

MODELO - CONTROLADOR

Se recomienda dividir los eventos del sistema en el

mayor número de controladores para poder aumentar la
cohesión y disminuir el acoplamiento.
Controlador
Se asocia a operaciones del sistema => respuestas a los eventos del
sistema .

Por ejemplo: cuando un cajero oprime el botón “Terminar Venta” , está

generando un evento sistémico que indica que “la venta ha terminado”.
ALTA COHESIÓN y BAJO ACOPLAMIENTO
Los conceptos
de cohesión y acoplamiento NO
están íntimamente relacionados

Es la idea de tener las clases lo menos

ACOPLAMIENTO
ligadas entre sí que se pueda.

Nos dice que la información que almacena

COHESIÓN una clase debe ser coherente y debe estar
(en la medida de lo posible) relacionada con
la clase.
ALTA COHESIÓN y BAJO ACOPLAMIENTO
Se tiene menor dependencia y se especifican los
propósitos de cada objeto en el sistema.

Es la idea de tener las clases lo menos

ACOPLAMIENTO
ligadas entre sí que se pueda.

Nos dice que la información que almacena

COHESIÓN una clase debe ser coherente y debe estar
(en la medida de lo posible) relacionada con
la clase.
 Esta navaja tiene muchas funciones
Cohesión (responsabilidades en nuestros términos).

En este caso decimos que esta navaja no es

muy “cohesiva” ya que se ocupa de demasiadas
funciones distintas en el mismo aparato. Esas
funciones no están relacionadas entre sí.

¿Qué hace la navaja?

Entre más relacionadas estén las responsabilidades

de una clase más fácil será entender la clase y en
general todo el sistema. Significa que cuando el
sistema se deba cambiar, más fácil será encontrar
dónde hacer el cambio.
Acoplamiento
Acoplamiento es la medida de cuánto una clase esta conectada (tiene
conocimiento) de otras clases.

Un alto acoplamiento en un sistema es problemático porque, debido a la

cantidad de relaciones entre las clases, va a se más difícil:
• Entender el sistema
• Cambiar el sistema Cuando se necesite cambiar un sistema muy acoplado,
por ejemplo, cambiar una clase

Reduce el impacto de los cambios y aumenta la reutilización.

POLIMORFISMO
POLI = “muchos”
MORFISMO =“forma ”
Las muchas formas que puede
tomar un objeto dependiendo
del contexto en donde se utilice
¡EFICIENCIA DE UN PROGRAMA!
BONO # 1 (Únicamente la primera persona …. )

¿Cómo sería el Contrato de Software válido para JavaDoc?

BONO # 2 (Únicamente la primera persona …. )

¿Cohesión y Acoplamiento?
¿Por qué?
BONO # 3 (Únicamente la primera persona …. )

¿Responsabilidades?¿GRASP?
BONO # 4 (Únicamente la primera persona …. )

¿Qué principios GRASP

se pueden identificar a
simple vista?¿Por qué?
¿Preguntas?