Pre_y_Post_Condiciones_Teoria - Gloria Mendoza

Vista previa del material en texto

Pre y Post Condiciones - Introducción a la Práctica Profesional 
Autor: Ripani - Porta - Pizzarulli Versión: 1.05 - 26/04/2004 10:23 
Proyecto: GUC Process Introducción a la Práctica Profesional – UTN FRR 
 
 
1 / 9 
 
Plantilla : Hardwired � plantilla_Docs_HP_IPP.dot v. 1.01 [29/4/03] Campo word � Normal.dot Grabación: 10/05/04 23:25:00 
 
C:\Enrique\UTN\UTN_2008\IPP\CD_Material_Clases_IPP_2008_v1\Apuntes IPP\Pre y Post Condiciones Teoría.doc Impresión: 03/08/08 21:25:00 
 
 
 
 
 
Pre y Post Condiciones - Introducción a la Práctica Profesional 
Autor: Ripani - Porta - Pizzarulli Versión: 1.05 - 26/04/2004 10:23 
Proyecto: GUC Process Introducción a la Práctica Profesional – UTN FRR 
 
 
2 / 9 
 
Plantilla : Hardwired � plantilla_Docs_HP_IPP.dot v. 1.01 [29/4/03] Campo word � Normal.dot Grabación: 10/05/04 23:25:00 
 
C:\Enrique\UTN\UTN_2008\IPP\CD_Material_Clases_IPP_2008_v1\Apuntes IPP\Pre y Post Condiciones Teoría.doc Impresión: 03/08/08 21:25:00 
 
Indice 
INDICE ........................................................................................................................................ 2 
INTRODUCCIÓN....................................................................................................................... 3 
EL EFECTO COLATERAL DE USAR PRECONDICIONES. ..............................................................4 
• El uso de precondiciones puede reducir el número de casos de uso de validaciones. ..............4 
• El uso de las precondiciones puede llevar a la identificación de más casos de uso. ................4 
DESCRIBIENDO LAS PRECONDICIONES.......................................................................... 5 
DECIDIR SI UNA PRECONDICIÓN ES NECESARIA. .......................................................................5 
DESCRIBIENDO LAS PRECONDICIONES. ........................................................................................5 
DESCRIBIENDO LAS POSTCONDICIONES ....................................................................... 6 
DECIDIR SI LAS POSTCONDICIONES SON NECESARIAS.............................................................6 
DESCRIBIENDO LAS POSTCONDICIONES.......................................................................................7 
LAS PRE Y POST – CONDICIONES SEGÚN LA CÁTEDRA. ........................................... 8 
BIBLIOGRAFÍA......................................................................................................................... 9 
 
 
Pre y Post Condiciones - Introducción a la Práctica Profesional 
Autor: Ripani - Porta - Pizzarulli Versión: 1.05 - 26/04/2004 10:23 
Proyecto: GUC Process Introducción a la Práctica Profesional – UTN FRR 
 
 
3 / 9 
 
Plantilla : Hardwired � plantilla_Docs_HP_IPP.dot v. 1.01 [29/4/03] Campo word � Normal.dot Grabación: 10/05/04 23:25:00 
 
C:\Enrique\UTN\UTN_2008\IPP\CD_Material_Clases_IPP_2008_v1\Apuntes IPP\Pre y Post Condiciones Teoría.doc Impresión: 03/08/08 21:25:00 
 
Introducción 
A veces, el sistema debe estar en un estado en particular para que el caso de uso se ejecute: 
Un cajero automático debe tener fondos para administrar; un motor debe tener combustible; un 
usuario debe ser autenticado para usar el sistema. Algunas veces estas condiciones pueden 
validarse con un simple test, y otras habrá un caso de uso que valide o establezca la condición. 
Simplemente queremos declarar la condición requerida, o estado, en el cual debe estar el 
sistema; llamamos a esta declaración la precondición. 
 
Ejemplos de Precondiciones 
� El usuario debe estar autorizado para usar el sistema (o, el usuario debe estar 
logueado) 
� El sistema debe tener suficiente efectivo disponible para procesar una transacción 
típica. 
� El canal de comunicación al sistema host está abierto y disponible para usar. 
 
La precondición es una oración acerca de la condición o condiciones que son necesarias para 
que el caso de uso sea ejecutado. A menudo, estas precondiciones son establecidas por la 
ejecución de otros casos de uso. Entonces, ¿por qué usamos precondiciones escritas en 
términos del resultado deseado, en lugar de decir, “El caso de uso “Autenticar Usuario” ha sido 
ejecutado”? 
Hay tres razones. Primero, queremos hacer de las descripciones del caso de uso, tanto como 
sea posible, historias independientes de lo que el sistema hace para proveer valor a uno o más 
actores. Si uno de los casos de uso llega a ser dependiente de otros casos de uso, lo hará más 
difícil de entender. Segundo, sólo porque el caso de Autenticar Usuario se haya ejecutado, no 
quiere decir que el usuario ejecutando el actual caso de uso ha sido autenticado. Finalmente, 
puede haber más de una forma de que el sistema alcance el estado deseado. Podemos tener 
más de una forma de autenticar usuarios. Cada una de estas podría ser un caso de uso distinto 
con diferentes flujos de eventos, todos finalizando en el mismo estado – el usuario es 
autorizado para ejecutar transacciones en el sistema. 
Las precondiciones en sí mismas son “necesarias pero no suficientes” para que el caso de uso 
se ejecute. La precondición debe contener lo necesario para que el caso de uso sea iniciado, 
pero no va a terminar haciendo que el caso de uso se inicie automáticamente solo porque sea 
verdadera. Para comenzar un caso de uso se necesita un actor que haga algo. La precondición 
solamente establece las condiciones bajo las cuales el caso de uso puede iniciarse. Los 
estados a los que se refiere la precondición deberían ser también “externamente visibles”, en 
otras palabras, ser una condición que los actores podrían entender. Las precondiciones no 
deberían referirse al diseño del sistema, sino que deberían ser aplicables sin hacer caso de 
como el sistema se implemente. 
 
 
Pre y Post Condiciones - Introducción a la Práctica Profesional 
Autor: Ripani - Porta - Pizzarulli Versión: 1.05 - 26/04/2004 10:23 
Proyecto: GUC Process Introducción a la Práctica Profesional – UTN FRR 
 
 
4 / 9 
 
Plantilla : Hardwired � plantilla_Docs_HP_IPP.dot v. 1.01 [29/4/03] Campo word � Normal.dot Grabación: 10/05/04 23:25:00 
 
C:\Enrique\UTN\UTN_2008\IPP\CD_Material_Clases_IPP_2008_v1\Apuntes IPP\Pre y Post Condiciones Teoría.doc Impresión: 03/08/08 21:25:00 
 
Las postcondiciones son declaraciones del estado (o condición) en la cual el sistema se 
encuentra al finalizar el caso de uso. Las postcondiciones no son disparadores de otros casos 
de uso; son solo resúmenes de hechos. Ayudan a asegurar que el lector entiende cual ha sido 
el resultado de la ejecución del caso de uso. En el ejemplo de caso de uso que autentica al 
usuario, la postcondición de éxito sería el usuario es autorizado a ejecutar transacciones en el 
sistema y la de fracaso: Se ha evitado que el usuario use el sistema. 
El efecto colateral de usar precondiciones. 
El uso de precondiciones puede tener un efecto directo en la forma del modelo de casos de uso 
como conjunto tanto como en la forma de los casos de uso individuales. 
 El uso de precondiciones puede reducir el número de casos de uso de 
validaciones. 
La precondición define un estado en el cual el sistema debe estar antes de que el caso 
de uso se ejecute, como resultado, el flujo de eventos del caso de uso no chequea la 
precondición. Solo use las precondiciones donde ayuden a aclarar el comportamiento 
requerido. 
Los peligros de usar precondiciones para reducir el número de chequeos a ser hechos 
dentro del sistema incluyen 
� La especificación del chequeo a veces puede olvidarse. En la mayoría de 
los casos, es muy fácil deducir lo que debería chequearse. Lo que es más 
difícil de deducir es cual acción debería ser emprendida cuando la 
condición ocurre. Si el chequeo es llevado a cabo por el caso de uso, 
luego las acciones correctivas pueden definirse. 
� Casos de uso que pueden crearse y nunca ser iniciados. Hay que recordar 
que la precondición debe ser verdaderapara que el caso de uso sea 
ejecutado. Si las precondiciones son sobreusadas (en el sentido de evitar 
validaciones), no es inusual que a los casos de uso le sean dadas 
precondiciones que son imposibles que el sistema alcance. 
 
 El uso de las precondiciones puede llevar a la iden tificación de más 
casos de uso. 
El uso de precondiciones puede ayudar con la evaluación de la completitud del modelo 
de casos de uso por descubrir explícitamente importantes estados del sistema y 
hacerlos más visibles a los desarrolladores y revisores de casos de uso. 
Si vemos el ejemplo de un simple sistema telefónico, y miramos a la precondición del 
caso de uso Realizar una llamada local: 
 
Pre y Post Condiciones - Introducción a la Práctica Profesional 
Autor: Ripani - Porta - Pizzarulli Versión: 1.05 - 26/04/2004 10:23 
Proyecto: GUC Process Introducción a la Práctica Profesional – UTN FRR 
 
 
5 / 9 
 
Plantilla : Hardwired � plantilla_Docs_HP_IPP.dot v. 1.01 [29/4/03] Campo word � Normal.dot Grabación: 10/05/04 23:25:00 
 
C:\Enrique\UTN\UTN_2008\IPP\CD_Material_Clases_IPP_2008_v1\Apuntes IPP\Pre y Post Condiciones Teoría.doc Impresión: 03/08/08 21:25:00 
 
 
Para que las llamadas locales sean hechas: 
 El teléfono debe estar registrado a una cuenta activa. 
 
De la aplicación simple de una precondición surgen los siguientes puntos acerca de la 
completitud de nuestro modelo de caso de uso: 
1. ¿cómo queda registrado un teléfono en una cuenta? 
2. ¿cómo es una cuenta activada o desactivada? 
 
En este caso necesitaríamos agregar al menos un caso de uso para nuestro modelo de 
sistema telefónico. 
 
 
Ilustración 1: Caso de uso adicional que 
permite la administración de las cuentas de 
los clientes y las unidades asociadas. 
 
 
 
Describiendo Las Precondiciones 
Como ya se dijo antes, una precondición define el estado que el sistema debe tener o las 
condiciones que deben cumplirse antes de que el caso de uso se ejecute. Las siguientes 
secciones ayudaran a identificar y escribir precondiciones de casos de uso. 
Decidir si una precondición es necesaria. 
De lo primero que deberá darse cuenta es que podría no ser necesario definir una precondición 
para el caso de uso; podría ser posible ejecutar el caso de uso en cualquier circunstancia. Las 
precondiciones sólo son necesarias definirlas en situaciones donde el caso de uso no puede 
ser ejecutado a menos que ciertas condiciones sean verdaderas. Las precondiciones definen 
estas condiciones. 
Nota de la Cátedra 1: En realidad en estos casos lo que ocurre es que la precondición es 
vacía, no coincidimos con la opinión del autor de denominarla como no necesaria porque 
puede confundirse con una noción de opcionalidad. Para identificar precondiciones vacías 
deberá usarse la etiqueta <vacía>. 
Describiendo las precondiciones. 
Si ciertas condiciones deben ser satisfechas antes de que el caso de uso sea ejecutado, 
establézcalas en una forma clara y de fácil verificación. 
Mantener 
Cuentas 
Representante de 
Servicio al Cliente 
 
Pre y Post Condiciones - Introducción a la Práctica Profesional 
Autor: Ripani - Porta - Pizzarulli Versión: 1.05 - 26/04/2004 10:23 
Proyecto: GUC Process Introducción a la Práctica Profesional – UTN FRR 
 
 
6 / 9 
 
Plantilla : Hardwired � plantilla_Docs_HP_IPP.dot v. 1.01 [29/4/03] Campo word � Normal.dot Grabación: 10/05/04 23:25:00 
 
C:\Enrique\UTN\UTN_2008\IPP\CD_Material_Clases_IPP_2008_v1\Apuntes IPP\Pre y Post Condiciones Teoría.doc Impresión: 03/08/08 21:25:00 
 
Un error común es escribir en la precondición algo que a veces es verdadero, pero no es 
necesariamente cierto. 
 
Ejemplo de precondiciones (para un cajero automátic o) 
Caso de Uso: Retirar Dinero 
� La conexión a la red del sistema bancario debe estar activa. 
� El sistema debe tener al menos algo de dinero que pueda ser entregado. 
� El usuario debe ser autenticado para ejecutar la transacción solicitada. 
 
Se debe pensar que las precondiciones son requerimientos que deben ser satisfechos antes de 
que el caso de uso se ejecute. Las precondiciones deberían escribirse como oraciones simples 
del estado en que el sistema debe estar, este estado podría ser expresado en términos de 
condiciones que deben ser verdaderas antes de que el caso de uso se ejecute. 
Las precondiciones nunca deberían establecerse en términos de algún otro caso de uso que se 
ha ejecutado. Si lo ha hecho, probablemente signifique que se ha dividido a los casos de uso 
en pedazos que son demasiado pequeños para que tengan valor por sí mismos. Para resolver 
este problema, se puede hacer una de dos cosas: combinar los casos de uso o establecer la 
precondición en términos del estado en el cual el caso de uso predecesor dejará el sistema. La 
combinación de los casos de uso es casi obvia, pero para determinar el estado en el cual el 
caso de uso deja el sistema, pregúntese “¿cuál es el resultado del caso de uso predecesor?” 
Este resultado o condición debería ser la condición del caso de uso sucesor, no una 
declaración del hecho de que algún otro caso de uso ha sido ejecutado. 
Nota de la Cátedra 2: Esto estaría implicando que “no hay que mencionar en las 
postcondiciones estados no usados en otros casos de uso”. Este principio puede aplicarse 
como guía al momento de decidir cuales son los estados que deben incluirse o no en una 
postcondición. Dependiendo de la situación particular puede moderarse la aplicación de este 
principio para lograr un modelo de casos de uso con mayor extensibilidad. 
Describiendo Las Postcondiciones 
Como ya se dijo anteriormente, una postcondición define el estado en el que el sistema se 
encuentra una vez que el caso de uso se ha ejecutado. 
Decidir si las postcondiciones son necesarias. 
En muchos casos, podría ser aceptable la simple omisión de la postcondición por completo 
cuando el resultado del caso de uso es obvio o cuando no hay cambios de estado significativo 
en el sistema. 
 
Pre y Post Condiciones - Introducción a la Práctica Profesional 
Autor: Ripani - Porta - Pizzarulli Versión: 1.05 - 26/04/2004 10:23 
Proyecto: GUC Process Introducción a la Práctica Profesional – UTN FRR 
 
 
7 / 9 
 
Plantilla : Hardwired � plantilla_Docs_HP_IPP.dot v. 1.01 [29/4/03] Campo word � Normal.dot Grabación: 10/05/04 23:25:00 
 
C:\Enrique\UTN\UTN_2008\IPP\CD_Material_Clases_IPP_2008_v1\Apuntes IPP\Pre y Post Condiciones Teoría.doc Impresión: 03/08/08 21:25:00 
 
Las postcondiciones son sólo necesarias cuando el estado es importante para uno de los 
actores del caso de uso, tal como cuando el estado final del caso de uso ayuda a un 
stakeholder a alcanzar su meta. 
Para determinar si se debería agregar una postcondición, habrá que preguntarse lo siguiente: 
 ¿la terminación del caso de uso deja al sistema en un estado en particular que podría 
necesitar ser una precondición para otros casos de uso? Si es así, se registra esto 
como una postcondición. 
 ¿son las salidas posibles del caso de uso obvias, de forma que les será fácil de 
entender el resultado de la ejecución del caso de uso a los desarrolladores, testers, o 
usuarios? Si no lo es, se registra las salidas como postcondiciones del caso de uso. 
 
Especificar todas las postcondiciones para un caso de uso puede ser útil en casos donde es 
importante llamar la atención a diferentes condiciones posibles que pueden existir cuando el 
caso de uso se completa. La enumeración de las postcondiciones puede asistir a los testers a 
verificar que todas las posibles salidas sean consideradas en los casos de prueba. Puede 
ayudar también a los desarrolladores a considerar posibles salidas distintas del caso de uso. 
Nota de la Cátedra 3: En caso de optar por omitir la postcondición deberá completarse con 
<omitida> 
Describiendo las postcondiciones. 
Las postcondiciones son condiciones que deben cumplirse cuando el caso de uso se termina. 
Veamos el caso de uso Retirar Dinerode nuevo: 
 
Ejemplo de postcondiciones (para un cajero automáti co) 
Caso de Uso: Retirar Dinero 
Para este caso de uso podrían existir las siguientes postcondiciones: 
� El cajero ha devuelto la tarjeta y entregado el efectivo al Cliente y se registro el 
retiro en la cuenta del Cliente 
� El cajero ha devuelto la tarjeta al Cliente y no se registró retiro en la cuenta del 
cliente. 
� El cajero se queda con la tarjeta y no se registra el retiro en la cuenta del cliente. 
 
Como con las precondiciones, use oraciones simples del estado o condición en la que el 
sistema estará cuando se complete el caso de uso. Si el caso de uso alcanza alguna meta de 
un stakeholder, asegúrese de dejarlo en claro. Exprese la postcondición de un caso de uso en 
términos de un estado en el que el sistema se encuentre, o una condición que sea verdadera, 
cuando el caso de uso se complete. Si el sistema puede estar en diferentes estados 
dependiendo de los pasos llevados a cabo en el caso de uso, estos estados deben 
enumerarse. 
 
Pre y Post Condiciones - Introducción a la Práctica Profesional 
Autor: Ripani - Porta - Pizzarulli Versión: 1.05 - 26/04/2004 10:23 
Proyecto: GUC Process Introducción a la Práctica Profesional – UTN FRR 
 
 
8 / 9 
 
Plantilla : Hardwired � plantilla_Docs_HP_IPP.dot v. 1.01 [29/4/03] Campo word � Normal.dot Grabación: 10/05/04 23:25:00 
 
C:\Enrique\UTN\UTN_2008\IPP\CD_Material_Clases_IPP_2008_v1\Apuntes IPP\Pre y Post Condiciones Teoría.doc Impresión: 03/08/08 21:25:00 
 
Las pre y post – condiciones según la Cátedra. 
Las precondiciones se dividirán en precondiciones de sistema y de negocio. Las 
precondiciones de sistema serán aquellas condiciones o estados (alcance del sistema) que 
garantice el sistema que serán ciertas antes de la ejecución del caso de uso. Las de negocio, 
serán aquellas condiciones de alcance de negocio (*) que se garanticen como ciertas antes de 
la ejecución del caso de uso. Desde un punto estrictamente teórico éstas últimas corresponden 
a casos de uso de negocio, pero dado que según el estándar de la cátedra actualmente se 
documenta sólo los casos de uso de sistema, las precondiciones de negocio se agregarán a la 
descripción del mismo. 
Las precondiciones de sistema se clasificarán en primarias y complementarias. 
Las primarias serán aquellas que estén directamente relacionadas a la meta del caso de uso. 
Por ejemplo, para registrar una factura, deberá existir el pedido; para registrar la devolución de 
un libro, debe estar el préstamo del mismo registrado. 
Las complementarias serán aquellas no directamente relacionadas a la meta del caso de uso 
que requieren análisis detallado para ser descubiertas. Por ejemplo, para registrar el pago de 
los socios, previamente deben existir los socios; para registrar una factura a un cliente, 
previamente deben existir los datos del cliente y los datos de los artículos; para registrar el 
préstamo de un libro deberán existir los datos de los libros. 
Así como las precondiciones, las postcondiciones se clasificarán como de sistema y como de 
negocio. 
La postcondición de sistema será aquella en la que se asiente el estado en el que queda el 
sistema una vez que el caso de uso se termine. Esta a su vez se clasifica en postcondición de 
éxito, de fracaso y de éxito alternativo. 
Cuando se ejecuta sólo el camino básico del caso de uso se tiene una postcondición de 
éxito . 
Cuando se ejecuta un camino alternativo del caso de uso que termina en: 
a) el no cumplimiento de la meta, se tiene una postcondición de fracaso. 
b) el éxito de la meta, se tiene una postcondición de éxito alternativo. 
La postcondición de negocio será aquella en la que se asiente qué sucede en el alcance de 
negocio una vez que se ejecute el caso de uso. 
 
(*) El término alcance utilizado es este contexto corresponde al concepto tal como lo define Cockburn. 
 
Pre y Post Condiciones - Introducción a la Práctica Profesional 
Autor: Ripani - Porta - Pizzarulli Versión: 1.05 - 26/04/2004 10:23 
Proyecto: GUC Process Introducción a la Práctica Profesional – UTN FRR 
 
 
9 / 9 
 
Plantilla : Hardwired � plantilla_Docs_HP_IPP.dot v. 1.01 [29/4/03] Campo word � Normal.dot Grabación: 10/05/04 23:25:00 
 
C:\Enrique\UTN\UTN_2008\IPP\CD_Material_Clases_IPP_2008_v1\Apuntes IPP\Pre y Post Condiciones Teoría.doc Impresión: 03/08/08 21:25:00 
 
Bibliografía 
 
 Kurt Bittner – Ian Spence, USE CASE MODELING, 2003, Addison-Wesley, 
The Addison – Wesley Object Technology Series. 
 
 Alistair Cockburn, WRITING EFFECTIVE USE CASES Pre-Pub. Draft N°3 , 2000, 
Addison-Wesley.