Dentro del análisis y diseño orientado a objetos de software, con notación UML, una parte de la descripción del comportamiento del Sistema se realiza mediante los diagramas de secuencia que estudian su comportamiento y la interacción entre sus objetos desde una perspectiva temporal.
Una vez se tienen las operaciones del sistema identificadas en este tipo de diagramas, se puede describir el comportamiento esperado del sistema en cada operación mediante lo que denominamos contratos.
Qué es un contrato de operaciones
Un contrato es un documento que describe qué es lo que se espera de una operación, enfatizando más en el análisis que en el diseño, es decir, más en el qué que en el cómo. Lo más común es expresar los contratos en forma de pre y postcondiciones en torno a los cambios de estado.
De hecho, un contrato de operación describe cambios en el estado del sistema cuando invocamos precisamente esa operación. Se puede escribir un contrato para un método individual de una clase software, o para una operación del sistema completa. En esta ocasión se verá únicamente éste último caso.
Algunos de los posibles apartados de un contrato de operaciones, según autores como Craig Larman, serían:
- Nombre: Nombre de la operación y parámetros.
- Responsabilidades: Una descripción informal de las responsabilidades que la operación debe desempeñar.
- Referencias cruzadas: Números de referencia en los requisitos funcionales del sistema, casos de uso, etc.
- Notas: Comentarios de diseño, algoritmos, etc.
- Excepciones: Casos excepcionales. Situaciones que debemos tener en cuenta que pueden pasar. Se indica también qué se hace cuando ocurre la excepción.
- Salida: Salidas que no corresponden a la interfaz de usuario, como mensajes o registros que se envían fuera del sistema. (En la mayor parte de las operaciones del sistema este apartado queda vacío)
- Precondiciones: Aspectos que debemos tener presente sobre el estado del sistema antes de ejecutar la operación. Algo que no tenemos en cuenta que pueda ocurrir cuando se llama a esta operación del sistema.
- Postcondiciones: El estado en el queda el sistema después de completar la operación.
Cabe destacar que la elaboración de estos contratos no es obligatoria, puede ser complementaria, incluso puede suprimirse. Muchas veces con una descripción o especificación detallada de casos de uso es más que suficiente. Además, habitualmente únicamente se modelan diagramas de secuencia y/o diagramas de colaboración (o comunicación a partir de UML 2) para estudiar la dinámica del sistema y representar las interacciones entre sus objetos.
Una vez más debemos recordar que UML es simplemente un lenguaje de modelado y no una metodología, por ello el uso de este tipo de contratos dependerá del tipo de sistema que estemos modelando y de la metodología que estemos empleando en su desarrollo.
Si quieres conocer más sobre objetos UML, solicita información sin compromiso de nuestro Curso de Análisis y Diseño Orientado a Objetos UML.
SEAS es el centro de formación online del Grupo San Valero, especializado en el ámbito técnico, industrial y de empresa. Visita www.seas.es para consultar nuestra oferta formativa de cursos y másteres. Formación profesional para el empleo de calidad y accesible para todos.
