- Dit onderwerp heeft 6 antwoorden, 2 stemmen, en is voor het laatst bijgewerkt 5 jaar, 3 maanden geleden door
.
-
Berichten
-
[Dit bericht is oorspronkelijk geplaatst als antwoord op deze discussie]
Hallo Frank, alle
Is het juist om te zeggen dat een EQ noodzakelijkerwijs gerelateerd is aan een EIF?
Met andere woorden, is het mogelijk om een EQ te hebben die geen permanente gegevens leest/opvraagt, beheerd door de externe applicatie??
En dit, ongeacht hoe de vraag technisch is gemaakt technical (ws, directe db-toegang, …)?
Sorry als het een domme vraag is, Ik ben een beetje een newbie
Thx voor je hulp al
Beste Gram JS,
Er bestaat niet zoiets als een domme vraag als je FPA onder de knie probeert te krijgen, dus bedankt voor de vraag.Het korte antwoord op de vraag is: NEE.
Een EO presenteert informatie aan een gebruiker die is gemanipuleerd en/of de hoeveelheid informatie is onbekend.
- Bijvoorbeeld, wanneer ik het Nesma-websiteregister vraag naar alle gebruikers met de naam “Gram” het register hoeft de gegevens niet te verwerken, maar ik kan niet van tevoren weten hoeveel gebruikers zullen worden gepresenteerd. Dat is een voorbeeld van een EO.
- Een ander voorbeeld is een personeelssysteem dat je geboortedatum vasthoudt. Ik kan het systeem je leeftijd vragen. Ik krijg altijd één antwoord, maar het antwoord is afgeleid van de geboortegegevens, dus het moet eerst worden gemanipuleerd.”
- Het is zelfs denkbaar dat er geen ILF of ELF bij betrokken is. Neem bijvoorbeeld een batchinterface of een webservice die Excel- of CSV-bestanden met meerdere records kan lezen. Het verwerken van de batch is een of meer EI. Een rapport van hoeveel records zijn verwerkt, is een EO.
Voor de EQ alleen het aantal logische referentiebestanden (Bestandstypen waarnaar wordt verwezen) is relevant, of deze nu intern of extern zijn.
(Je hebt misschien gemerkt dat ik ELF heb gebruikt in plaats van EIF. Dit is de nieuwe Nesma 2.3 terminologie.)
Hele duidelijke uitleg Frank, heel erg bedankt.
Eigenlijk probeer ik een ‘indicatieve’’ meting (die is gebaseerd op het tellen van alleen logische bestanden). En ik ben nu een beetje de weg kwijt omdat ik niet weet wanneer ik een ELF heb geteld voor de for (toekomst) applicatie Ik probeer de grootte te bepalen wanneer het vraagt (meestal via ws) permanente gegevens van andere toepassingen. Ook, Ik heb geen conceptueel datamodel of wat dan ook tot mijn beschikking. Heb je een hint??
Het hangt een beetje af van de schaal van de schatting van de grootte die u maakt.
De indicatieve methode is geschikt voor een hele toepassing. Vervolgens probeer je een conceptueel model te construeren van je eigen applicatie en de gegevens die het moet opvragen uit omliggende applicaties. In dat geval kun je het ELF gebruiken als conceptueel element voor de data uit omringende applicaties.
Wanneer u een schatting maakt van de omvang van een beperkt aantal webservices, dan de High-level (of geschat zoals Nesma het noemde) methode. Dan heb je geen last van ELF, aangezien je door middel van EI en EO communiceert met de omliggende applicaties.
Ik hoop dat dit helpt.
….waarom niet de ELF's tellen bij het gebruik van webservices??
Ik dacht dat het gemiddelde dat de applicatie gebruikt om de gegevens te consumeren (ws, directe db-toegang, enzovoort) van de externe applicatie deed er niet toe?Volgens mijn weten, een type externe entiteit voldoet aan de volgende criteria::
•Het wordt gebruikt door de toepassing die moet worden geteld.
•Het wordt niet onderhouden door de applicatie die moet worden geteld.
•Het wordt onderhouden door een andere applicatie.
•Het is direct beschikbaar voor de toepassing die moet worden geteld..Gebruikt betekent dat de gegevens ook daadwerkelijk worden gebruikt in het proces van de aanvraag.
Behouden geeft aan dat het mogelijk is om toe te voegen, verandering, of verwijder gegevens.
Direct beschikbaar betekent dat de betreffende applicatie altijd over de actuele gegevens beschikt, ook al handhaaft een andere toepassing dit entiteitstype.Verandert het gebruik van ws daar iets aan?? Denken we bijvoorbeeld dat de gegevens niet? “direct” beschikbaar bij toegang via ws?
Alvast bedankt voor je hulp
Wanneer u gegevens ophaalt door middel van een webservice, wordt dit niet beschouwd als direct leverbaar. Daarom wordt communicatie met een webservice in een analyse op hoog niveau geteld als een paar EI en EO, in plaats van een ELF. Bij een indicatieve telling bemoei je je niet met dit soort details en reken je een databron buiten je applicatie als ELF.
Ik hoop dat dit helpt.
Hallo Frank,
Alle goeds voor dit nieuwe jaar. 🙂
Het identificeren van de ILF's en ELF's is inderdaad wat ik hier probeer te doen.
Zit er niet altijd een ELF achter een ws?
Waarom wordt het niet als direct beschikbaar beschouwd??
….Ik dacht dat de manier waarop de applicatie de informatie ophaalt (hier via een ws) maakte niet uit
….Ik zie niet fundamenteel het verschil tussen toegang tot de informatie via een JDBC of via een ws…Ook, je zegt dat een ws eerder wordt gezien als een EI/EO. Zelfs wanneer de via de ws opgehaalde informatie alleen dient (is zinvol om) een grotere transactie?
Omdat bij het lezen van de definitie van een “Elementair proces (EP)” hier onder, het lijkt erop dat in mijn geval de ws-query geen volledige transactie op zich is, omdat deze alleen informatie naar een grotere transactie voedt, die op zichzelf betekenisvol is voor de gebruiker.
Een EP is de kleinste eenheid van functionele gebruikersvereiste die −
Is zinvol voor de gebruiker.
Vormt een volledige transactie.
Is op zichzelf staand en laat het bedrijf van de applicatie die wordt geteld in een consistente staat.Nogmaals bedankt voor het delen van je kennis en ervaring en voor je tijd.
Met vriendelijke groet
JS
- Je moet ingelogd zijn om op dit onderwerp te reageren.