KNOWLEDGE BASE

UML

Unified Modeling Language (UML) is zowel een taal om diagrammen te maken als een notatiewijze om modellen van objectgeoriënteerde softwaresystemem te specificeren, te visualiseren en te beschrijven. UML dient twee doelen: (1) visualisatie van het softwaresysteem en (2) te dienen als communicatiemiddel.

Oorsprong

UML vind zijn wortels in het object-georienteerde programmeren, dat in de 80'er jaren aan populariteit won. UML staat onder toezicht van de Object Management Group (OMG), die UML in 1997 standardiseerde. In 2000 werd UML door de International Organization for Standardization (ISO) geaccepteerd als standaard voor het modelleren van softwaresystems. Sinds 1997 heeft het OMG de taal steeds verbeterd; inmiddels is 2.4.1, daterend van juli 2011, de meest recente versie.

Gebruik van use case diagrams

Use case diagrams worden in de volgende situaties gebruikt: 1. bij het bepalen van business requirements; bij het opstellen en uitwerken van nieuwe use cases stuit men dikwijls op nieuwe eisen communicatie met klanten; 2. omdat use cases relatief eenvoudig zijn, vormen zij voor de use case ontwikkelaars een goed middel om te communiceren met betrokkenen als klanten en gebruikers. 3. ontwikkelen van test cases; een verzameling van use cases vormt een goede basis voor testcase scenario's.

Terminologie

1. Een model is een abstractie van een onderliggend probleem 2. Het domein is de werkelijke wereld waarin problemen zich voordoen 3. Een model bestaat uit objecten die met elkaar communiceren via boodschappen 4. Een object bestaat uit attributes (zaken die het object weet) en behaviors (zaken die het object kan) 5. Een attribute kan een bepaalde waarde hebben, de state 6. Een class is een blauwdruk voor een object; in een class zijn zowel attributes als behaviors opgenomen. Een object kan gezien worden als een instance van een class.

Hierarchisch opbouw van UML

UML bestaat uit hierarchische een set van 13 verschillende diagrammen, verdeeld over 6 diagrammen die iets over het systeem zelf vertellen (de structural modeling diagrams) en 7 diagrammen die iets over het systeem en relatie met zijn omgeving vertellen (de behavioral modeling diagrams). structural modeling diagram o class diagram toont het model in een statische situatie geeft de relaties tussen de classes in het systeem aan wordt weergegeven door een rechthoek met drie lagen: eerste laag : class name tweede laag : class attribute derde laag: class methode (een + betekent: public; een - betekent: private) o object diagram speciale vorm van een class diagram toont de relatie tussen classes op een bepaald moment wordt weergeven als gekoppelde rechthoeken o component diagram componenten zijn te vergelijken met classes en zijn te onderscheiden door component diagram teken systemen worden opgebouwd aan de hand van components componenten communiceren onderling door middel van interfaces o package diagram wordt gebruikt het systeem op een hoger abstractieniveau te kunnen tonen classes worden hiertoe gegroepeerd in packages in het package diagram worden alleen de relaties tussen de packages getoond o composite structure diagram o deployment diagram behavioral modeling diagram o use case diagram toont hoe een buitenstaander tegen het systeem aankijkt het gaat om wat het systeem doet en niet om hoe het systeem het doet use case diagram bestaat uit meerdere scenario's een use case scenario is een voorbeeld van wat er gebeurt als iemand of iets (de Actor) met het systeem interacteert o activity diagram o state machine diagram o communication diagram o sequence diagram o timing diagram o interaction overview diagram Vanuit BPM in het algemeen en requirements management in het bijzonder, vormen de use case diagrams de belangrijkste typen. Deze kijken immers vanuit de optiek van de klant of de gebruiker naar het systeem. Reden om de use case diagram verder uit te werken. Een use case diagram bestaat uit de volgende elementen (constructs): use case; Een reeks van activiteiten en alternatieven waarmee een systeem interacteert met een actor actor; persoon of systeem die interacteert met een systeem system boundary; toont de grenzen tussen het systeem en de actor association; de wijze waarop een actor participeert in een use case exclude; relatie tussen een andere, externe use case en de use case zelf generalization; hierarchische relatie tussen een algemene en een specifieke use case include; relatie tussen een de use case en een ingesloten use case Exclude en include

Exclude en Include

Extent en include zijn in een use case dikwijls lastige begrippen. Included use cases worden gebruikt om te voorkomen dat eenzelfde use case meerdere keren wordt beschrijven. Hiermee wordt redundantie in de use case voorkomen. Als dezelfde stappen in meerdere use cases gebruikt worden, dan worden deze in een een afzonderlijke use case opgenomen en aangeroepen vanuit de oorspronkelijke use cases. Een included use case is onderdeel van zijn aanroepende use cases. Samenvattend; een included use case wordt gebruikt indien: twee of meer use cases maken gebruik van de included use case; alleen het resultaat van de included use case wordt gebruikt; gebruik van de included use case is niet optioneel; de opsplitsing in meerdere use cases de leesbaarheid van het diagram wordt verbeterd. Door middel van een extending use case kan er functionaliteit in een use case toegevoegd worden. De oorspronkelijke use case blijft ongewijzigd. In de volgende situaties kan er gebruik worden gemaakt van een exclude uses case: een deel van de use case is optioneel en een deel van de use use wordt alleen in bepaalde omstandigheden uitgevoerd. Voorbeelden Bij het plaatsen van een order wordt een kredietwaardigheidstoets uitgevoerd en de klant blijkt niet kredietwaardig. De use case roept een exclude use case aan, waarin niet kredietwaardige klanten worden verwerkt; de actor van deze excluded use case is niet de klant, maar bijvoorbeeld een sales manager. Een sales order systeem kent twee use cases (check order status en place order) waarvoor de actor (in casu: de klant) moeten inloggen. De twee use cases roepen daarom een include use case 'login' aan. Voorbeeld van een use case diagram (pin automaat)
Invoeren verkeerde pin
Rapporteren systeem
Uitvoeren onderhoud
Afsluiten systeem
Inloggen pinautomaat
Uitvoeren transactie
Controleren saldo
Opnemen geld
Printen ontvangstbewijs
Onderhouds-monteur
Klant
Bank
<<include>>
<<include>>
<<extend>>
KNOWLEDGE BASE

UML

Unified Modeling Language (UML) is zowel een taal om diagrammen te maken als een notatiewijze om modellen van objectgeoriënteerde softwaresystemem te specificeren, te visualiseren en te beschrijven. UML dient twee doelen: (1) visualisatie van het softwaresysteem en (2) te dienen als communicatiemiddel.

Oorsprong

UML vind zijn wortels in het object-georienteerde programmeren, dat in de 80'er jaren aan populariteit won. UML staat onder toezicht van de Object Management Group (OMG), die UML in 1997 standardiseerde. In 2000 werd UML door de International Organization for Standardization (ISO) geaccepteerd als standaard voor het modelleren van softwaresystems. Sinds 1997 heeft het OMG de taal steeds verbeterd; inmiddels is 2.4.1, daterend van juli 2011, de meest recente versie.

Gebruik van use case diagrams

Use case diagrams worden in de volgende situaties gebruikt: 1. bij het bepalen van business requirements; bij het opstellen en uitwerken van nieuwe use cases stuit men dikwijls op nieuwe eisen communicatie met klanten; 2. omdat use cases relatief eenvoudig zijn, vormen zij voor de use case ontwikkelaars een goed middel om te communiceren met betrokkenen als klanten en gebruikers. 3. ontwikkelen van test cases; een verzameling van use cases vormt een goede basis voor testcase scenario's.

Terminologie

1. Een model is een abstractie van een onderliggend probleem 2. Het domein is de werkelijke wereld waarin problemen zich voordoen 3. Een model bestaat uit objecten die met elkaar communiceren via boodschappen 4. Een object bestaat uit attributes (zaken die het object weet) en behaviors (zaken die het object kan) 5. Een attribute kan een bepaalde waarde hebben, de state 6. Een class is een blauwdruk voor een object; in een class zijn zowel attributes als behaviors opgenomen. Een object kan gezien worden als een instance van een class.

Hierarchisch opbouw van UML

UML bestaat uit hierarchische een set van 13 verschillende diagrammen, verdeeld over 6 diagrammen die iets over het systeem zelf vertellen (de structural modeling diagrams) en 7 diagrammen die iets over het systeem en relatie met zijn omgeving vertellen (de behavioral modeling diagrams). structural modeling diagram o class diagram toont het model in een statische situatie geeft de relaties tussen de classes in het systeem aan wordt weergegeven door een rechthoek met drie lagen: eerste laag : class name tweede laag : class attribute derde laag: class methode (een + betekent: public; een - betekent: private) o object diagram speciale vorm van een class diagram toont de relatie tussen classes op een bepaald moment wordt weergeven als gekoppelde rechthoeken o component diagram componenten zijn te vergelijken met classes en zijn te onderscheiden door component diagram teken systemen worden opgebouwd aan de hand van components componenten communiceren onderling door middel van interfaces o package diagram wordt gebruikt het systeem op een hoger abstractieniveau te kunnen tonen classes worden hiertoe gegroepeerd in packages in het package diagram worden alleen de relaties tussen de packages getoond o composite structure diagram o deployment diagram behavioral modeling diagram o use case diagram toont hoe een buitenstaander tegen het systeem aankijkt het gaat om wat het systeem doet en niet om hoe het systeem het doet use case diagram bestaat uit meerdere scenario's een use case scenario is een voorbeeld van wat er gebeurt als iemand of iets (de Actor) met het systeem interacteert o activity diagram o state machine diagram o communication diagram o sequence diagram o timing diagram o interaction overview diagram Vanuit BPM in het algemeen en requirements management in het bijzonder, vormen de use case diagrams de belangrijkste typen. Deze kijken immers vanuit de optiek van de klant of de gebruiker naar het systeem. Reden om de use case diagram verder uit te werken. Een use case diagram bestaat uit de volgende elementen (constructs): use case; Een reeks van activiteiten en alternatieven waarmee een systeem interacteert met een actor actor; persoon of systeem die interacteert met een systeem system boundary; toont de grenzen tussen het systeem en de actor association; de wijze waarop een actor participeert in een use case exclude; relatie tussen een andere, externe use case en de use case zelf generalization; hierarchische relatie tussen een algemene en een specifieke use case include; relatie tussen een de use case en een ingesloten use case Exclude en include

Exclude en Include

Extent en include zijn in een use case dikwijls lastige begrippen. Included use cases worden gebruikt om te voorkomen dat eenzelfde use case meerdere keren wordt beschrijven. Hiermee wordt redundantie in de use case voorkomen. Als dezelfde stappen in meerdere use cases gebruikt worden, dan worden deze in een een afzonderlijke use case opgenomen en aangeroepen vanuit de oorspronkelijke use cases. Een included use case is onderdeel van zijn aanroepende use cases. Samenvattend; een included use case wordt gebruikt indien: twee of meer use cases maken gebruik van de included use case; alleen het resultaat van de included use case wordt gebruikt; gebruik van de included use case is niet optioneel; de opsplitsing in meerdere use cases de leesbaarheid van het diagram wordt verbeterd. Door middel van een extending use case kan er functionaliteit in een use case toegevoegd worden. De oorspronkelijke use case blijft ongewijzigd. In de volgende situaties kan er gebruik worden gemaakt van een exclude uses case: een deel van de use case is optioneel en een deel van de use use wordt alleen in bepaalde omstandigheden uitgevoerd. Voorbeelden Bij het plaatsen van een order wordt een kredietwaardigheidstoets uitgevoerd en de klant blijkt niet kredietwaardig. De use case roept een exclude use case aan, waarin niet kredietwaardige klanten worden verwerkt; de actor van deze excluded use case is niet de klant, maar bijvoorbeeld een sales manager. Een sales order systeem kent twee use cases (check order status en place order) waarvoor de actor (in casu: de klant) moeten inloggen. De twee use cases roepen daarom een include use case 'login' aan. Voorbeeld van een use case diagram (pin automaat)
Invoeren verkeerde pin Rapporteren systeem Uitvoeren onderhoud Afsluiten systeem Inloggen pinautomaat Uitvoeren transactie Controleren saldo Opnemen geld Printen ontvangstbewijs Onderhouds-monteur Klant Bank <<include>> <<include>> <<extend>>
KNOWLEDGE BASE

UML

Unified Modeling Language (UML) is zowel een taal om diagrammen te maken als een notatiewijze om modellen van objectgeoriënteerde softwaresystemem te specificeren, te visualiseren en te beschrijven. UML dient twee doelen: (1) visualisatie van het softwaresysteem en (2) te dienen als communicatiemiddel.

Oorsprong

UML vind zijn wortels in het object-georienteerde programmeren, dat in de 80'er jaren aan populariteit won. UML staat onder toezicht van de Object Management Group (OMG), die UML in 1997 standardiseerde. In 2000 werd UML door de International Organization for Standardization (ISO) geaccepteerd als standaard voor het modelleren van softwaresystems. Sinds 1997 heeft het OMG de taal steeds verbeterd; inmiddels is 2.4.1, daterend van juli 2011, de meest recente versie.

Gebruik van use case diagrams

Use case diagrams worden in de volgende situaties gebruikt: 1. bij het bepalen van business requirements; bij het opstellen en uitwerken van nieuwe use cases stuit men dikwijls op nieuwe eisen communicatie met klanten; 2. omdat use cases relatief eenvoudig zijn, vormen zij voor de use case ontwikkelaars een goed middel om te communiceren met betrokkenen als klanten en gebruikers. 3. ontwikkelen van test cases; een verzameling van use cases vormt een goede basis voor testcase scenario's.

Terminologie

1. Een model is een abstractie van een onderliggend probleem 2. Het domein is de werkelijke wereld waarin problemen zich voordoen 3. Een model bestaat uit objecten die met elkaar communiceren via boodschappen 4. Een object bestaat uit attributes (zaken die het object weet) en behaviors (zaken die het object kan) 5. Een attribute kan een bepaalde waarde hebben, de state 6. Een class is een blauwdruk voor een object; in een class zijn zowel attributes als behaviors opgenomen. Een object kan gezien worden als een instance van een class.

Hierarchisch opbouw van UML

UML bestaat uit hierarchische een set van 13 verschillende diagrammen, verdeeld over 6 diagrammen die iets over het systeem zelf vertellen (de structural modeling diagrams) en 7 diagrammen die iets over het systeem en relatie met zijn omgeving vertellen (de behavioral modeling diagrams). structural modeling diagram o class diagram toont het model in een statische situatie geeft de relaties tussen de classes in het systeem aan wordt weergegeven door een rechthoek met drie lagen: eerste laag : class name tweede laag : class attribute derde laag: class methode (een + betekent: public; een - betekent: private) o object diagram speciale vorm van een class diagram toont de relatie tussen classes op een bepaald moment wordt weergeven als gekoppelde rechthoeken o component diagram componenten zijn te vergelijken met classes en zijn te onderscheiden door component diagram teken systemen worden opgebouwd aan de hand van components componenten communiceren onderling door middel van interfaces o package diagram wordt gebruikt het systeem op een hoger abstractieniveau te kunnen tonen classes worden hiertoe gegroepeerd in packages in het package diagram worden alleen de relaties tussen de packages getoond o composite structure diagram o deployment diagram behavioral modeling diagram o use case diagram toont hoe een buitenstaander tegen het systeem aankijkt het gaat om wat het systeem doet en niet om hoe het systeem het doet use case diagram bestaat uit meerdere scenario's een use case scenario is een voorbeeld van wat er gebeurt als iemand of iets (de Actor) met het systeem interacteert o activity diagram o state machine diagram o communication diagram o sequence diagram o timing diagram o interaction overview diagram Vanuit BPM in het algemeen en requirements management in het bijzonder, vormen de use case diagrams de belangrijkste typen. Deze kijken immers vanuit de optiek van de klant of de gebruiker naar het systeem. Reden om de use case diagram verder uit te werken. Een use case diagram bestaat uit de volgende elementen (constructs): use case; Een reeks van activiteiten en alternatieven waarmee een systeem interacteert met een actor actor; persoon of systeem die interacteert met een systeem system boundary; toont de grenzen tussen het systeem en de actor association; de wijze waarop een actor participeert in een use case exclude; relatie tussen een andere, externe use case en de use case zelf generalization; hierarchische relatie tussen een algemene en een specifieke use case include; relatie tussen een de use case en een ingesloten use case Exclude en include

Exclude en Include

Extent en include zijn in een use case dikwijls lastige begrippen. Included use cases worden gebruikt om te voorkomen dat eenzelfde use case meerdere keren wordt beschrijven. Hiermee wordt redundantie in de use case voorkomen. Als dezelfde stappen in meerdere use cases gebruikt worden, dan worden deze in een een afzonderlijke use case opgenomen en aangeroepen vanuit de oorspronkelijke use cases. Een included use case is onderdeel van zijn aanroepende use cases. Samenvattend; een included use case wordt gebruikt indien: twee of meer use cases maken gebruik van de included use case; alleen het resultaat van de included use case wordt gebruikt; gebruik van de included use case is niet optioneel; de opsplitsing in meerdere use cases de leesbaarheid van het diagram wordt verbeterd. Door middel van een extending use case kan er functionaliteit in een use case toegevoegd worden. De oorspronkelijke use case blijft ongewijzigd. In de volgende situaties kan er gebruik worden gemaakt van een exclude uses case: een deel van de use case is optioneel en een deel van de use use wordt alleen in bepaalde omstandigheden uitgevoerd. Voorbeelden Bij het plaatsen van een order wordt een kredietwaardigheidstoets uitgevoerd en de klant blijkt niet kredietwaardig. De use case roept een exclude use case aan, waarin niet kredietwaardige klanten worden verwerkt; de actor van deze excluded use case is niet de klant, maar bijvoorbeeld een sales manager. Een sales order systeem kent twee use cases (check order status en place order) waarvoor de actor (in casu: de klant) moeten inloggen. De twee use cases roepen daarom een include use case 'login' aan. Voorbeeld van een use case diagram (pin automaat)
Invoeren verkeerde pin Rapporteren systeem Uitvoeren onderhoud Afsluiten systeem Inloggen pinautomaat Uitvoeren transactie Controleren saldo Opnemen geld Printen ontvangstbewijs Onderhouds-monteur Klant Bank <<include>> <<include>> <<extend>>