La domanda non ammette risposta univoca, come d'altronde molte altre questioni inerenti UML e i numerosi contributi sui quali si basa - come già ripetuto, si tratta di metodi semiformali, non caratterizzati da una specifica formale rigorosa e non ambigua.
In casi come questo, oltre all'ovvio ricorso a dettagliate MSC per una ulteriore e migliore specificazione, occorre mettersi a cavalcioni di un caprone e afferrare ambedue i corni del dilemma: in primo luogo, apprendere quale possa essere la convinzione del docente in merito (salvo poi eventualmente dimenticarsene un istante dopo la conclusione dell'esame). Secondo: cercare di avvicinarsi autonomamente alla verità, ossia al modo in cui nelle singole realtà aziendali e nei vari package tuttofare la notazione UML viene ri-specificata e applicata sulla base di corpose norme e convenzioni interne, rigorosamente non divulgate.
Una buona spinta in questa seconda direzione può provenire da
questa lettura, ad esempio.
Risulta ovvio a tutti, spero, che proprio in casi come questo l'uso di un linguaggio logico e rigoso come Z a latere dei disegnini UML (use cases e message sequence charts in particolare) possa finalmente specificare in modo non ambiguo, a prova d'errore, la vera relazione che intercorre tra gli use cases coinvolti. Non dimenticate mai che la Matematica, e sua zia la Logica, sono per eccellenza le scienze delle relazioni formali tra enti astratti!
Ecco quindi in sintesi come nasce OCL, una ibridazione tra un vero linguaggio formale (Z) e i comodi simbolismi UML.
Messaggi recenti
