Architectuurscan OO API Gegevensuitwisseling: verschil tussen versies

Uit ROSA Wiki
Naar navigatie springen Naar zoeken springen
(Nieuwe pagina aangemaakt met ' {{#Element: |Elementtype=Architectuurscanonderdeel |ROSA onderdeel=Gegevensuitwisseling in de keten |Scanbevindingen='''Ketenpartijen bieden wederzijdse services:'...')
 
Geen bewerkingssamenvatting
Regel 14: Regel 14:


Voorbeelden:
Voorbeelden:
"Educational departments" = The educational departments of an organization.
"Educational departments" = The educational departments of an organization.
Faculty = The organizational parts of an organization.
Faculty = The organizational parts of an organization.
Regel 29: Regel 30:
Building is een attribuut van “Schedule”, maar de verwijzing ontbreekt. Wat is de ontwerpbeslissing hierachter?
Building is een attribuut van “Schedule”, maar de verwijzing ontbreekt. Wat is de ontwerpbeslissing hierachter?


'''Behoeftegerichte en doelgebonden gegevensuitwisseling:''' Het is niet duidelijk hoe de OO API borgt dat er niet meer (maar ook niet minder) informatie dan nodig uitgewisseld wordt.  
'''Behoeftegerichte en doelgebonden gegevensuitwisseling:''' Het is niet duidelijk hoe de OO API borgt dat er niet meer (maar ook niet minder) informatie dan nodig uitgewisseld wordt.
|Relatie met ROSA=Onbepaald
|Relatie met ROSA=Onbepaald
|Toelichting relatie met ROSA=Verdere ontwerp- en implementatiekeuzes bepalen hoe de gegevensuitwisseling afdoende kan worden geborgd
|Toelichting relatie met ROSA=Verdere ontwerp- en implementatiekeuzes bepalen hoe de gegevensuitwisseling afdoende kan worden geborgd
}}
}}

Versie van 6 apr 2018 14:00


Onbepaald.png ROSA Architectuurscan OO API

Gegevensuitwisseling in de keten: Onbepaald

Hier ziet u een samenvatting van de architectuurscan van het onderwerp OO API op het onderdeel . De scan is uitgevoerd op 18 januari 2018.

Bevindingen "Gegevensuitwisseling in de keten" (OO API)[bewerken]

Ketenpartijen bieden wederzijdse services - De OO API is weliswaar geen webservicespecificatie, maar biedt desalniettemin een (REST) endpoint voor data consumers om gegevens uit de bron op te halen. Op die manier geeft de OO API een goede invulling hieraan.

Registreer de betekenis van nieuwe gegevens - Het is niet duidelijk welke OO API begrippen nieuw zijn. Sommige begrippen zijn niet scherp gedefinieerd

Serviceinformatie wordt samenhangend openbaar gemaakt - Het is niet duidelijk hoe een gebruiker of ontwikkelaar weet dat er een endpoint bestaat

Classificeer alle gegevens- en domeinobjecten met het Kernmodel Onderwijsinformatie - Het is onbekend hoe de semantiek van de OO API zich tot de semantiek van het KOI verhoudt.

Sommige gegevens, attributen en relaties zijn niet scherp gedefinieerd

Voorbeelden:

"Educational departments" = The educational departments of an organization. Faculty = The organizational parts of an organization. Wat is het verschil tussen educational departments en faculty? Waarom is Organization niet gedefinieerd? Hoe weet je over welke organisatie het gaat?

"Affiiation" The affiliations of how this person is associated with the organization Student/Employee/Staff/Member/Affiliate/Organization Het verschil tussen employee, staff en member is onduidelijk. Er lijkt ook een, verder niet beschreven, relatie te zijn met filters en autorisatie (Zie ook de bevindingen over filters bij IBP)

"Building" Dit gegeven staat los van de rest. Building is een attribuut van “Schedule”, maar de verwijzing ontbreekt. Wat is de ontwerpbeslissing hierachter?

Behoeftegerichte en doelgebonden gegevensuitwisseling - Het is niet duidelijk hoe de OO API borgt dat er niet meer (maar ook niet minder) informatie dan nodig uitgewisseld wordt.

Relatie met ROSA[bewerken]

Onbepaald - Verdere ontwerp- en implementatiekeuzes bepalen hoe de gegevensuitwisseling afdoende kan worden geborgd

terug naar de ROSA Architectuurscan