De wereld van objectoriëntatie staat aan de vooravond van de introductie van UML 2.0. Het is de eerste 'major release' in de jonge geschiedenis van deze taal. Critici laten zich verschillend uit over UML 2.0. De meningen variëren van 'significante verbeteringen' tot 'blijvende inherente structurele inconsistenties'. Wat kunnen we verwachten van UML 2.0, en wat zijn de gevolgen voor de software-industrie? Een it-architect blikt vooruit.
Unified Modeling Language is een taal voor het visualiseren, specificeren, construeren en documenteren van softwaresystemen. UML wordt toegepast bij de meeste objectgeoriënteerde en ‘component based development’ (cbd) methoden. UML 1.1 is in 1997 geaccepteerd door de Object Management Group (OMG). De huidige versie, UML 1.4, is sinds begin 2001 door de OMG geaccepteerd. Van UML zijn tot nog toe slechts ‘minor releases’ uitgebracht en dit betroffen voornamelijk tekstuele wijzigingen, herstellen van de inconsistentie en omissies.
Het binnenkort te verschijnen UML 2.0 is de eerste ‘major release’. De behoefte aan UML 2.0 komt enerzijds voort uit beperkingen, omissies en inconsistenties van UML, anderzijds is er een discrepantie ontstaan tussen moderne technologieën en UML. De taal is namelijk onvoldoende geëvolueerd met technologieën zoals cbd. Het grote en complexe metamodel is moeilijk onderhoudbaar waardoor de noodzakelijke evolutie is uitgebleven. Daarnaast kampt de OMG met inconsistenties tussen andere OMG-standaarden.
Alle grote wijzigingsvoorstellen voor UML 2.0 zijn verzameld door de OMG en verdeeld over vier taakgroepen. De taakgroep Infrastructure heeft als doel het verbeteren van de consistentie tussen de OMG-modelleerstandaarden en het uitbreiden van UML naar specifieke domeinen. De taakgroep Superstructure definieert gebruiksconstructies voor cbd en ‘run-time’-architecturen. De taakgroep OCL (Object Constraint Language) houdt zich bezig met wijzigingsvoorstellen rondom OCL. Het is een taal die gebruikt wordt om regels in het metamodel van UML te definiëren om precieze beperkende voorwaarden (constraints) in UML-modellen uit te drukken. De taakgroep Diagram Interchange houdt zich bezig met wijzigingsvoorstellen rondom de grafische representatie en uitwisselingen van diagrammen via tools.
Uitbreidingsmechanisme
De OMG-metamodellen – UML, mda (model-driven architecture), cwm (common warehouse meta-model) en mof (meta object facility) – zijn gebaseerd op een kernel waarbinnen alle basisfunctionaliteit is gedefinieerd. Om de consistentie tussen deze metamodellen te herstellen is deze kernel geherdefinieerd. Door een uitbreidingsmechanisme – profiel (profile) is een subklasse geworden van ‘package’ in het metamodel – kunnen ontwerpers en toolleveranciers UML verder uitbreiden naar een specifiek domein, zoals system engineering (UML-se). UML-se is een serieuze ontwikkeling van de OMG, waarbij inmiddels synchronisatie plaats vindt met Incose (International council on systems engineering). UML voor agent-technologie zou een mogelijk volgende uitbreiding kunnen zijn. De verwachting is dat UML blijft uitbreiden en dat nieuwe profielen worden toegevoegd aan de reeks van corba idl, corba component model (ccm), enterprise integration architecture (eia), enterprise distributed object computing (edoc) en express. Als gevolg van het herstructureren (‘refactoren’) van het metamodel is UML compatible met andere OMG-metamodellen. Daarnaast vormen deze metamodellen samen een krachtiger geheel en kennen ze flexibele uitbreidingsmechnismen. Dit laatste heeft te maken met de eenvoudige wijze waarop profielen uitgebreid kunnen worden.
Aan de beperkte basisconstructies in UML voor componententechnologie zijn verbeteringen doorgevoerd voor component en interface. Twee nieuwe elementen zijn toegevoegd: poort en connector. UML komt hiermee tegemoet aan bijvoorbeeld Enterprise Java Beans (EJB), J2EE, Corba, .Net en COM+. Aanvankelijk was het wel mogelijk om componentarchitecturen te modelleren door profielen te definiëren. Maar aangezien architectuur zo essentieel is voor de meeste software domeinen is de kernel van UML hiervoor aangepast. Het componentdiagram is geen losstaand implementatiediagram meer. Een expliciete relatie is gelegd tussen de specificatie, en component en gebruiksdiagram. Het symbool van ‘component’ is gewijzigd: de twee kleine rechthoeken zijn verdwenen. De samenwerking tussen componenten is via interactiediagrammen te modelleren. Een interface, de specificatie van een contract waaraan instanties moeten voldoen, heeft een uitgebreide semantiek gekregen: een ‘protocol state machine’. Deze specificeert de gedragskarakteristieken van instanties via preconditie, actie en postconditie. Hiermee komt de interface tegemoet aan de ‘object management architecture’ (oma). Interfaces mogen onderling associaties hebben, waardoor objecten via delegatie langs een keten van interfaces kunnen navigeren. Daarnaast zijn delen van de interface hiërarchisch te (de)componeren. Een poort is een specifieke vorm van een interface op een component en biedt hiervoor ‘plug-and-play’ faciliteiten. Interfaces met een poort zijn voorzien van het stereotype <
Overerving en ‘activity’
In het metamodel is expliciet gemaakt welke elementen worden overgeërfd per model door het toevoegen van ‘refinable element’ aan het metamodel. Behalve associaties, attributen, methodes betreft dit nu ook ‘state machines’. ‘State machines’ van een superklasse gelden nu ook voor subklassen. Volgens Liskov geldt: “een instantie van een subklasse moet ook een instantie kunnen zijn van de superklasse”. Maar hoe zit dat met ‘state machines’? Is de toegestane volgorde van methodes in de subklasse altijd identiek met de superklasse? De ‘observable’- en ‘invocable’-regel bieden hier uitkomst. Deze regels doen uitspraken over de compatibiliteit van ‘object life-cycles’ tussen super- en subklasse en duiden de sterkte van de overerving aan. Onduidelijk is nog hoe het zit met de overerving van intern gedrag (intra concurrentie) en communicatie.
‘Activity’ vervangt de ‘activity’-graaf. Activity’s zijn gebaseerd op petrinet-achtige netwerken, een krachtig mechanisme voor het specificeren van parallellisme. Activity’s hebben een interrupt-regio. Hiermee kan bij het optreden van een ‘event’ een transitie gespecificeerd worden naar een andere toestand, zonder de oorspronkelijke toestand daadwerkelijk te verlaten. Bij het specificeren van complex gedrag kunnen activity’s de ‘sequence’-diagrammen decomponeren en deze combineren met geavanceerde constructies (parallel, optioneel, herhaling). Dit maakt UML ook schaalbaar vanuit het gedragsperspectief.
Kleine verbeteringen
Naast grote structurele wijzigingen op de UML-architectuur zijn ook vele kleine verbeteringen doorgevoerd. Het gaat te ver om deze alle in dit artikel te noemen en daarom worden er slechts drie uitgelicht.
Was het eerst alleen mogelijk om ‘packages’ te importeren, met UML 2.0 is het mogelijk om ook ‘elementen’ te importeren. Daarnaast zijn de importmogelijkheden vereenvoudigd. Het is alleen nog toegestaan om <
Nieuw in OCL
OCL 2.0 is voorzien van een metamodel. Dit metamodel definieert de OCL-concepten en legt de semantiek eenduidig vast. De semantiek is gebaseerd op UML en heeft hetzelfde uitbreidingsmechanisme uit de kernel. Hierdoor is het mogelijk om OCL voor bijvoorbeeld Java of visuele diagrammen te realiseren. De OCL 2.0-grammatica gebruikt een ander formalisme dan OCL 1.4, maar beschrijft dezelfde concrete syntaxis. OCL 2.0 is terugwaarts compatibel, waardoor OCL 1.4-expressies geldig blijven in OCL 2.0.
Nieuw in OCL is het OCL-bericht om gedrags-‘constraints’ van te versturen berichten bij componenten te specificeren. Naast een ‘constraint’-taal is OCL nu ook een volledige query-taal met dezelfde expressiviteit als SQL, doordat het concept van ’tuple’ is toegevoegd. Daarnaast zijn alle voorgedefinieerde types en operaties gedefinieerd in de OCL Standard Library.
Het wachten is nog op de ondersteuning van case-tools voor OCL-expressies en het genereren van invarianten en ‘constraints’ in code.
Gegevensuitwisseling en representatie
Het metamodel van UML is van meer detail voorzien voor een verbeterde grafische representatie, en om diagrammen volwaardig uit te wisselen met andere tools zonder informatieverlies. Posities van elementen zoals coördinaten zijn dan wel leverancierspecifiek en geen echte uitwisselingen, maar zijn wel belangrijk voor het representeren van de modellen en het exporteren naar andere tools. De OMG combineert hiervoor twee standaarden: OMG XML Metadata Interchange (XMI) en Scalable Vector Graphics (SVG). XMI definieert een datastructuur om UML-modellen in XML te representeren. XMI is de standaard voor het uitwisselen van UML-modellen tussen tools en repositories. SVG is een opkomende platformonafhankelijke taal voor het beschrijven en representeren van 2-dimensionale grafische symbolen in XML. SVG bevat alle noodzakelijke grafische symbolen voor UML. Voor het representeren en uitwisselen van informatie maakt de OMG gebruik van drie lagen: een semantisch model met de UML-notaties, een grafische model met SVG-notaties en een intermediair tussen de andere twee lagen. Alle lagen gebruiken XML, maar wel met een verschillende structuur. Door het gebruik van deze lagen ontstaat er een standaardisatie van het uitwisselen van informatie via tools. Bij het uitwisselen van de diagrammen exporteren de UML 2.0-gecertificeerde tools: het semantisch UML-model (zoals attributen van de klasse) en de visuele diagrammen (lijnen, symbolen, strings, coördinaten, iconen, bitmaps). In UML is SVG gedefinieerd als een profiel.
Met deze lagenarchitectuur is nog niet opgelost hoe case-tools vaststellen of bij ‘reverse engineering’ de relatie een compositie, aggregatie of associatierelatie betreft. Het blijft nog wachten op een meta-case-tool waarmee men zelf het metamodel kan aanpassen gebruiken in een case-tool.
Door het introduceren van de drie lagen en het gebruik van XMI en SVG zijn UML- modellen vollediger uit te wisselen tussen UML 2.0 gecertificeerde tools van verschillende leveranciers. Onduidelijk is nog hoe het zit met de certificering van UML 2.0-tools.
Betere integratie
UML 2.0 is consistent gemaakt met de andere OMG-metamodellen. Daarnaast heeft UML een volwaardigere aansluiting met de huidige technologieën en zijn de belangrijkste ontwerpfouten eruit gehaald. Ondanks dit alles kan de ontwikkelaar de taal via profielen uitbreiden. Door het metamodel van OCL ontstaat een betere integratie met UML, wat de ontwerper meer precisie biedt en waardoor kwalitatief betere en volwaardigere systemen te specificeren zijn. Voor het uitwisselen van UML-diagrammen en de grafische representatie is een standaardisatie ingezet.
De consequentie van deze wijzigingen is dat de tool-leveranciers de case-tools tijdig moeten aanpassen om UML 2.0 daadwerkelijk toe te kunnen passen in projecten. Volgens de huidige prognose zijn de tools rond half 2003 gereed. Organisaties moeten hun trainingen aanpassen en ontwikkelaars zullen zich snel de veranderingen ten opzichte van de vorige versie eigen moeten maken, want UML 2.0 dient zich al aan. Wij moeten tenslotte ook onze wijze van spelling aanpassen aan nieuwe spellingsregels, conform het ‘groene boekje’.
Omdat UML 2.0 nog niet definitief is, kunnen er discrepanties bestaan tussen dit artikel en de uiteindelijke versie van UML.
Relevante sites:
http://wiht.link/uml-info
http://www.celigent.com/omg/UMLrtf
http://www.w3.org/Graphics/SVG
René Krouwel, ict-architect CMG
