- Ce sujet a 6 réponses, 2 voix, et a été mis à jour pour la dernière fois 5 ans, 3 mois depuis par
.
-
Des postes
-
[Ce message a été initialement publié en réponse à cette discussion]
Bonjour Frank, tout
Est-il correct de dire qu'un EQ est nécessairement lié à un FEI?
En d'autres termes, est-il possible d'avoir un EQ qui ne lit / interroge pas les données permanentes gérées par l'application externe?
Et ça, peu importe comment la requête est techniquement faite (ws, accès direct à la base de données, …)?
Désolé si c'est une question idiote, Je suis un peu novice 🙂
Merci déjà pour votre aide
Cher Gram JS,
Il n'y a pas de question idiote lorsque vous essayez de maîtriser FPA, alors merci pour la question.La réponse courte à la question est NON.
Un OE présente des informations à un utilisateur qui ont été manipulées et / ou la quantité d'informations est inconnue.
- Par exemple, quand je demande au registre du site Web Nesma pour tous les utilisateurs qui portent le nom de “Gramme” le registre n'a pas à traiter les données, mais je ne peux pas savoir à l'avance combien d'utilisateurs seront présentés. C’est un exemple d’OE.
- Un autre exemple est un système de personnel qui contient votre date de naissance. Je peux demander au système ton âge. Je recevrai toujours une réponse, mais la réponse a été dérivée des données de naissance, il faut donc d'abord le manipuler.”
- Il est même concevable qu'aucune ILF ou ELF ne soit impliquée. Prenons par exemple une interface batch ou un service web capable de lire des fichiers Excel ou CSV avec plusieurs enregistrements. Le traitement du lot est un ou plusieurs EI. Un rapport indiquant le nombre d'enregistrements traités est un EO.
Pour l'EQ uniquement le nombre de fichiers logiques de référence (Types de fichiers référencés) est pertinent, qu'ils soient internes ou externes.
(Vous avez peut-être remarqué que j'ai utilisé ELF au lieu de FEI. C'est la nouvelle Nesma 2.3 terminologie.)
Explication très claire Frank, Merci beaucoup.
En fait, j'essaye de faire un "indicatif’ la mesure (qui est basé uniquement sur le nombre de fichiers logiques). Et je suis un peu perdu maintenant parce que je ne sais pas quand j'ai compté un ELF pour le (futur) application que j'essaie de dimensionner lorsqu'elle interroge (principalement via ws) données permanentes d'autres applications. Aussi, Je n'ai pas de modèle de données conceptuel ou quoi que ce soit à ma disposition. Avez-vous un indice?
Cela dépend un peu de l'échelle de l'estimation de la taille que vous faites.
La méthode indicative convient à toute une application. Vous essayez ensuite de construire un modèle conceptuel de votre propre application et des données qu'il doit interroger à partir des applications environnantes. Dans ce cas, vous pouvez utiliser l'ELF comme élément conceptuel pour les données des applications environnantes.
Lorsque vous faites une estimation de la taille d'un nombre limité de services Web, puis le haut niveau (ou estimé comme Nesma l'appelait) méthode. Alors vous ne vous souciez pas d'ELF, puisque vous communiquerez via EI et EO avec les applications environnantes.
J'espère que cela t'aides.
….pourquoi ne pas compter les ELF lors de l'utilisation des services web?
Je pensais que le moyen utilisé par l'application pour consommer les données (ws, accès direct à la base de données, etc) de l'application externe n'avait pas d'importance?Selon ma connaissance, un type d'entité externe répond aux critères suivants:
• Il est utilisé par l'application pour être compté.
• Il n'est pas maintenu par l'application pour être compté.
• Il est maintenu par une application différente.
• Il est directement disponible pour l'application pour être compté..Utilisé signifie que les données sont également réellement utilisées dans le processus de l'application.
Maintenu indique qu'il est possible d'ajouter, changement, ou supprimer des données.
Directement disponible signifie que l'application concernée dispose en permanence des données actuelles, même si une application différente maintient ce type d'entité.Est-ce que l'utilisation de ws change quelque chose à cela? Considérons-nous par exemple que les données ne sont pas “directement” disponible lors de l'accès via ws?
Merci déjà pour votre aide
Lorsque vous récupérez des données au moyen d'un service Web, cela n'est pas considéré comme directement disponible. C'est pourquoi la communication avec un webservice dans une analyse de haut niveau est comptée comme une paire d'EI et d'EO, plutôt qu'un ELF. Dans un compte indicatif, vous ne vous souciez pas de ce type de détails et vous comptez une source de données en dehors de votre application comme ELF.
J'espère que cela t'aides.
Salut Frank,
Tout le meilleur pour cette nouvelle année. 🙂
Identifier les ILF et ELF est en effet ce que j'essaie de faire ici.
N'y a-t-il pas toujours un ELF derrière un ws?
Pourquoi n'est-il pas considéré comme directement disponible?
….J'ai pensé à la façon dont l'application récupère les informations (ici via un ws) n'avait pas d'importance
….Je ne vois pas fondamentalement la différence entre accéder aux informations via un JDBC ou via un ws…Aussi, vous mentionnez qu'un ws est plutôt considéré comme un EI / EO. Même lorsque les informations récupérées via le ws ne servent qu'à (est significatif pour) une transaction plus importante?
Parce qu'en lisant la définition d'un “Processus élémentaire (EP)” ici-bas, il semble que dans mon cas, la requête ws n'est pas une transaction complète en elle-même car elle ne fournit des informations qu'à une transaction plus importante, qui est en soi significatif pour l'utilisateur.
Un EP est la plus petite unité d'exigence fonctionnelle de l'utilisateur qui -
Est significatif pour l'utilisateur.
Constitue une transaction complète.
Est autonome et laisse l'activité de l'application comptée dans un état cohérent.Merci encore pour le partage de vos connaissances et de votre expérience et pour votre temps.
Meilleures salutations
JS
- Vous devez être connecté pour répondre à ce sujet.