- Este tema tiene 6 respuestas, 2 voces, y fue actualizado por última vez 5 años, 3 meses hace por
.
-
Publicaciones
-
[Esta publicación se publicó originalmente como respuesta a esta discusión]
Hola frank, todas
¿Es correcto decir que un EQ está necesariamente relacionado con un EIF??
En otras palabras, ¿Es posible tener un EQ que no lea / consulte datos permanentes administrados por la aplicación externa??
Y esto, no importa cómo se haga técnicamente la consulta (ws, acceso directo a la base de datos, …)?
Lo siento si es una pregunta tonta, Soy algo novato 🙂
Gracias por tu ayuda ya
Estimado Gram JS,
No existe una pregunta tonta cuando intentas dominar FPA, entonces gracias por la pregunta.La respuesta corta a la pregunta es NO.
Una EO presenta información a un usuario que ha sido manipulada y / o se desconoce la cantidad de información..
- Por ejemplo, cuando pregunto al registro del sitio web de Nesma por todos los usuarios que se llaman “Gramo” el registro no tiene que procesar los datos, pero no puedo saber de antemano cuántos usuarios se presentarán. Ese es un ejemplo de EO.
- Otro ejemplo es un sistema de personal que mantiene su fecha de nacimiento.. Puedo preguntarle al sistema tu edad. Siempre recibiré una respuesta, pero la respuesta se ha derivado de los datos de nacimiento, por lo que primero hay que manipularlo.”
- Incluso es concebible que no intervenga ILF o ELF. Tomemos, por ejemplo, una interfaz por lotes o un servicio web que pueda leer archivos Excel o CSV con varios registros.. Procesar el lote es uno o más EI. Un informe de cuántos registros se han procesado es un EO.
Para el EQ solo el número de archivos lógicos de referencia (Tipos de archivo referenciados) es relevante, ya sean internos o externos.
(Es posible que haya notado que usé ELF en lugar de EIF. Esta es la nueva Nesma 2.3 terminología.)
Explicación muy clara Frank, Muchísimas gracias.
En realidad, estoy tratando de hacer un "indicativo’ medición (que se basa en el recuento de archivos lógicos solamente). Y ahora estoy un poco perdido porque no sé cuándo contaré un ELF para el (futuro) aplicación que estoy tratando de dimensionar cuando consulta (principalmente a través de ws) datos permanentes de otras aplicaciones. también, No tengo ningún modelo de datos conceptual ni nada a mi disposición. Tienes una pista?
Depende un poco de la escala de la estimación de tamaño que esté haciendo..
El método indicativo es adecuado para una aplicación completa.. Luego, intenta construir un modelo conceptual de su propia aplicación y los datos que debe consultar de las aplicaciones circundantes.. En ese caso, puede utilizar ELF como elemento conceptual para los datos de las aplicaciones circundantes..
Cuando realiza una estimación del tamaño de un número limitado de servicios web, luego el de alto nivel (o estimado como solía llamarlo Nesma) método. Entonces no te preocupes por ELF, ya que se comunicará mediante EI y EO con las aplicaciones circundantes.
Espero que esto ayude.
….¿Por qué no contar los ELF cuando se utilizan servicios web??
Pensé que la media que usa la aplicación para consumir los datos (ws, acceso directo a la base de datos, etc) de la aplicación externa no importaba?Según mi conocimiento, un tipo de entidad externa cumple con los siguientes criterios:
• Es utilizado por la aplicación para ser contado..
• No es mantenido por la aplicación para ser contado..
• Se mantiene mediante una aplicación diferente..
• Está disponible directamente para que la aplicación sea contada..Usado significa que los datos también se utilizan en el proceso de solicitud..
Mantenido indica que es posible agregar, cambio, o borrar datos.
Disponible directamente significa que la aplicación en cuestión siempre tiene los datos actuales a su disposición., aunque una aplicación diferente mantiene este tipo de entidad.¿El uso de ws cambia algo a eso?? ¿Consideramos, por ejemplo, que los datos no son “directamente” disponible cuando se accede a través de ws?
Gracias ya por tu ayuda
Cuando recupera datos mediante un servicio web, esto no se considera directamente disponible. Es por eso que la comunicación con un servicio web en un análisis de alto nivel se cuenta como un par de EI y EO, en lugar de un ELF. En un recuento indicativo, no se preocupa por este tipo de detalles y cuenta una fuente de datos fuera de su aplicación como ELF..
Espero que esto ayude.
Hola frank,
Todo lo mejor para este nuevo año. 🙂
Identificar los ILF y ELF es de hecho lo que estoy tratando de hacer aquí.
¿No siempre hay un ELF detrás de una w??
¿Por qué no se considera directamente disponible?
….Pensé que la forma en que la aplicación recupera la información (aquí a través de un ws) no importaba
….No veo fundamentalmente la diferencia entre acceder a la información a través de un JDBC o mediante un ws…también, usted menciona que un ws se ve más bien como un EI / EO. Incluso cuando la información recuperada a través de ws solo sirve (es significativo para) una transacción más grande?
Porque al leer la definición de un “Proceso elemental (EP)” aquí abajo, parece que en mi caso, la consulta ws no es una transacción completa en sí misma, ya que solo alimenta información a una transacción más grande, que en sí mismo es significativo para el usuario.
Un EP es la unidad más pequeña de requisito de usuario funcional que:
Es significativo para el usuario.
Constituye una transacción completa.
Es autónomo y deja el negocio de la aplicación contabilizado en un estado consistente.Gracias nuevamente por compartir su conocimiento y experiencia y por su tiempo..
Atentamente
JS
- Debes iniciar sesión para responder a este tema.