Toegepaste notatiewijzen DLA software Bert Dingemans info@dla-architect.nl
Inleiding In de DLA Software wordt gebruik gemaakt van een aantal notatiewijzen voor het opstellen van een object- en procesmodel. Hierbij geldt de methodologie Merode als uitgangspunt. Echter binnen Merode wordt het functionele model met een andere notatie afgebeeld. Binnen DLA wordt voor een andere oplossing gekozen. Er wordt gepoogd om van drie standaard notatiewijzen gebruik gemaakt, te weten: Boomstructuur Matrix Netwerkgraaf Voordeel van deze opzet is dat de modellen eenvoudiger te begrijpen zijn. Want ken je de basisopzet dan is deze basis in de andere modellen goed herkenbaar en snel toe te passen. Binnen DLA wordt uitgegaan van drie lagen. In dit document zijn de notatiewijzen per laag beschreven, van onderen naar boven. Mensen die geinteresseerd zijn in het toepassen van de notatiewijze wil ik verwijzen naar de website www.dla-architect.nl waar een aantal voorbeelden te vinden zijn van objectmodellen op basis van deze notatiewijzen. In de afbeelding wordt een samenvatting getoond van het onderliggende model.
In onderstaande tabel wordt aangegeven in welke laag en in welk diagram de afzonderlijke entiteiten gebruikt worden Entiteit Laag Diagram Class Bedrijfsdomeinlaag ER diagram, Bestaansafhankleijkheiddiagram Object-Gebeurtenis tabel Property Bedrijfsdomeinlaag ER diagram, Bestaansafhankleijkheiddiagram Method Gebruikerslaag Object-Gebeurtenis tabel Volgorde diagram Object_Event Gebruikerslaag Object-Gebeurtenis tabel Event Gebruikerslaag Object-Gebeurtenis tabel Volgorde diagram Service Presentatielaag Service diagram Interaction diagram Interaction Presentatielaag Interaction diagram Process Presentatielaag Process diagram
Domeinlaag Entiteit Relatie Diagram In het ER diagram worden de statische relaties tussen de verschillende objecten gemodelleerd. Relaties worden weergegeven in een netwerkgraaf waarbij een relatie altijd aan beide kanten verbonden is aan een object. Dit mag hetzelfde object zijn. Bij relaties kunnen verder de minimum en maximum cardinaliteit opgeven worden bij de objectkoppeling. In onderstaande tabel staan de cardinaliteiten van de afbeelding weergegeven Object Min. Card. Max. Card. Object Min. Card Max. Card. A 1 1 B 0 N (veel) C 1 1 D 0 1
Let op dat de minimumcardiniteit overeenkomt met de optionaliteit in de relatie. Dit houdt in dat het weergegeven wordt aan de andere zijde van de relatie. Minimum cardinaliteit één is een gesloten rondje en Minimum Cardinaliteit nul is een open rondje. Toelichting op het model Naast relaties tussen objecttypen kan ook overerving (inheritance) gemodelleerd worden. Overerving is een begrip dat in de object oriëntatie veel toegepast wordt. Eenvoudig gezien bestaat een Object uit toestand en gedrag. Een object heeft toestand, door het gedrag verandert de toestand. Bijvoorbeeld een dossier heeft als toestand actief. Door het gedrag (een methode) afsluiten_dossier verandert de toestand (status) van actief naar gesloten. Overerving maakt het mogelijk om met name toestand her te gebruiken. Bijvoorbeeld binnen een informatiesysteem komen de objecten Medewerker en Jeugdige voor. Beide objecten bezitten een aantal gemeenschappelijke eigenschappen zoals naam, adres, postcode, woonplaats geslacht. Het is beter dit in een object persoon op te nemen. Van dit object persoon kunnen dan zowel Medewerker als Jeugdige overerven. Voordeel is dat als er iets aan de definitie van Persoon verandert dit direct geldt voor Medewerker en Jeugdige. Binnen DLA bestaan twee soorten overerving. Met een concreet Super object of met een abstract super object. Bij een concreet superobject (A) kan dit object bestaan als entiteit. Bij een abstract superobject (C) kan dit niet. Bijvoorbeeld Persoon als abstract objecttype is niet zichtbaar in het informatiesysteem terwijl het als concreet type wel zichtbaar is. Binnen IJ is het een concreet objecttype omdat het zichtbaar is in de vorm van een invul/mutatiescherm.
Bestaansafhankelijkheidsdiagram In het bestaansafhankelijkheidsdiagram worden de statische relaties weergegeven, net als in het ER diagram. Echter er zijn een aantal beperkingen. In dit diagram worden de bestaansafhankelijke relaties gemodelleerd. Bestaansafhanklelijk houdt in dat het afhankelijke object niet kan bestaan als het master object niet reeds bestaat. Dit is het soort relaties wat veel voorkomt binnen administratieve toepassingen. Een contactjournaal zal altijd bij een persoon horen met wie men het contact heeft. Een orderregel hoort altijd bij zowel een artikel als een order. Een orderregel kan niet bestaan zonder het artikel en de order. De order is weer bestaansafhankelijk van een klant etc. In onderstaande tabel een opsomming van de bestaansafhankelijkheden in de afbeelding Object Min. Card. Max. Card. Object Min. Card Max. Card. A 1 1 B 0 N (veel) C 1 1 D 0 1
Gebruikerslaag Volgorde Diagram Het volgordediagram ligt op de grens van domein- en gebruikerslaag modellering. Het toont de dynamiek van een object, ook wel genoemd de levensloop van een object. Zoals reeds is gezegd bestaat een object uit toestand en gedrag. In het volgorde diagram wordt getoond wat de volgorde is waarin een object van toestand veranderd. Vaak is het zo dat de volgorde van toestandverandering niet willekeurig is. Bijvoorbeeld een dossier kan pas gesloten worden als het geopend is. Een ander voorbeeld zou kunnen zijn een jeugdige kan pas gescreend worden zodra er een aanmelding is geweest. Of na het opstellen van een hulpverleningsplan kan dit in een aantal evaluaties geëvalueerd worden. Met het volgorde diagram is dit te modelleren met behulp van de volgende opties: Sequentie (>) (A-Root) de ene stap volgt de andere op. Selectie (o) (A-Body) er wordt een keuze gemaakt uit één van de kinderen Iteratie (*) (A-Begin) de kindstap wordt 0 tot veel keer uitgevoerd Elementair ( ) (1,2,3) deze stap past de toestand van een object aan of voert de daadwerkelijke bewerking uit. De andere stappen dienen als navigatiestap.
Object Gebeurtenis Tabel In de object-gebeurtenis tabel worden gebeurtenissen gekoppeld aan de objecten. Een gebeurtenis is een functionele gebeurtenis binnen de organisatie. Een gebeurtenis kan een aantal effecten op één of meerdere objecten hebben. Bijvoorbeeld een aanmelding heeft tot gevolg dat het object Jeugdige en het object Aanmelding ontstaan. Het afsluiten van een dossier kan een wijziging of het einde van een object Dossier inhouden (afhankelijk van de werkwijze binnen de organisatie. In de object-event table wordt dit gemodelleerd op basis van een matrix waarin codes geplaatst worden. De volgende codes zijn van belang C (create) het object wordt door deze gebeurtenis aangemaakt M (modify) het object wordt door deze gebeurtenis gewijzigd. E (end) het object eindigt door deze gebeurtenis. Daarnaast zijn een aantal extra codes mogelijk (bij detail modellering) O (own) het is een eigen gebeurtenis van dit object. Het is een gebeurtenis die geinitieerd is door dit object A (acquired) het is een gebeurtenis die door propagatie van bestaansafhankelijkheid gekoppeld wordt aan dit object
I (inherit) het is een gebeurtenis die door propagatie van overerving gekoppeld wordt aan dit object De bovenste opsomming is essentieel voor het modelleren met een object-gebeurtenistabel. De tweede opsomming wordt eigenlijk alleen gebruikt bij zeer grote objectmodellen en zorgen voor een betere leesbaarheid van een grote object-gebeurtenistabel.
Presentatielaag Servicediagram Binnen DLA worden twee soorten services onderscheiden. De eerste zijn de gegevensbewerkende services. Deze passen de toestand aan van de objecten door het aanroepen van één of meerdere gebeurtenissen. Er ontstaat hierin een soort boomstructuur van bewerkende services via gebeurtenissen naar methoden op de afzonderlijke objecten. De methoden passen de eigenschappen aan van een object. Voor de gegevensverstrekkende services kunnen service diagrammen gemaakt worden. Verstrekkende services bieden gegevens uit het objectmodel aan aan de interacties. Binnen een gegevensverstrekkende service kunnen de gegevens uit meerdere objecten opgehaald worden vandaar dat er ook associaties gemodelleerd worden. Als er vanuit de servicecontrol lijnen lopen naar een objecttype houdt dit in dat er eigenschappen binnen de service gebruikt worden. Dit kan zijn als conditie en als element van de resultset. Aan de eigenschap zijn hiertoe trefwoorden toegevoegd voor zowel de conditie als de resultset.
Interactiediagram Over het interactiediagram kunnen we kort zijn. Er kan een schermschets van een verstrekkende service gemaakt worden. Eventueel kan het gebruikt worden om opgenomen te worden in een ontwerpdocument. Ervaring is dat met de prototyper routines een sneller resultaat mogelijk is.
Procesdiagram Het procesdiagram. Het toont de opzet van de toepassing. Hierbij kan gedacht worden aan navigatiestructuren zoals menu s, zoekschermen, wizards, maar ook de flow van een object door een organisatiemodel. Dit kan met behulp van de volgende opties: Sequentie (Z) (A-Root) de ene stap volgt de andere op. Selectie (o) (Y) er wordt een keuze gemaakt uit één van de kinderen Iteratie (*) (X) de kindstap wordt 0 tot veel keer uitgevoerd Elementair ( ) (1,2,3) deze stap past roept één of meerdere interacties uit. De andere stappen dienen als navigatiestap.