Respuesta de los comentarios Reviewer A



Descargar 25,25 Kb.
Fecha de conversión03.02.2017
Tamaño25,25 Kb.
  1. Respuesta de los comentarios

    1. Reviewer A:


El trabajo no respeta las 15 páginas y en parte no cumple con el formato requerido.”

TBD: hay que cortar una pagina

"La metodología plantea 3 ciclos e indica que en cada uno de ellas se itera sobre el framework M&S, sin embargo no se indica cómo se realiza esta iteración en el ciclo de exploración. Además, este ciclo no es abordado en el caso de estudio."

En la seccion 3.2 se incluyé:

“El caso de estudio no muestra iteraciones sobre el ciclo de exploración ya que este se esta comenzando al momento de escribir este documento”

(el ciclo de exploración y sus resultados preliminares quedan fuera del alcance de este trabajo).



"Tampoco queda claro cómo la metodología permite lograr una ventaja sobre metodologías actuales para el desarrollo basado en M&S"

En la seccion 3.2 se incluyé:

“La metodología propuesta presenta la ventaja de poseer conceptos de simulación formal (tal como el marco experimental, separación entre sistema/modelo/simulador, verificación y validación, etc) fusionándolos con prácticas conocidas para proyectos de desarrollo ágiles (iteraciones, entregas frecuentes, comunicación constante con de los requerimientos, adaptabilidad, etc). Por otro lado, en proyectos exclusivamente de desarrollo de software no es usual modificar las herramientas utilizadas. Sin embargo, en proyectos de M&S el simulador y las herramientas de visualización son claves para éxito del proyecto por lo que deben actualizarse a la par del modelo, desarrollando nuevas técnicas que permitan adaptarse a los requerimientos. La metodología propuesta tiene estos cambios de las herramientas en consideración brindando un marco para que las mejoras que se introduzcan en este sentido se realicen en forma genérica, beneficiando no sólo al proyecto en cuestión sino también a toda la comunidad de M&S.“

Sin embargo, ninguna de las metodologías mencionadas contempla aspectos formales de M&S provistos por DEVS: separación estricta entre formalismo de modelado, mecanismo abstracto de simulación, código de implementación de los modelos y código de implementación de los motores de simulación. Esto presenta la ventaja de poder manejar marcos experimentales específicos para el trabajo con el sistema real, el modelo, y el simulador. Además, en proyectos típicos de desarrollo de software no es usual modificar las herramientas de base utilizadas durante del proceso. Sin embargo, en proyectos científicos basados en M&S, las propias herramientas de modelado, simulación y visualización son dispositivos cruciales que demandan sus propios requerimientos a la par del modelo. Aún más, las mejoras incorporadas en las herramientas deben ser de carácter genérico, reusables para proyectos similares. Nuestra metodología cubre naturalmente esta necesidad.

"cómo se obtienen y emplean los requerimientos a lo largo del proceso"

En la seccion 3.1 se incluye:

"Adicionalmente, a lo largo del proyecto se definen requerimientos puntuales y específicos sobre el comportamiento que se desea reproducir en la simulación a través de reuniones de análisis técnicos con los científicos expertos en cada área. Es habitual que estos requeri-mientos cambien a lo largo del proyecto e incluso que diferentes áreas de TDAQ estén interesados en comportamientos distintos. Por ejemplo, expertos en DataFlow solicitaron reproducir el comportamiento de los emuladores del ROS que utilizan tamaños de fragmentos uniformes para todos los nodos. En la actualidad, se están utilizando fragmentos diferentes según el nodo del ROS más realistas obtenidos del Run2 para evaluar el efecto de enco-lamiento en nuevos switches (en el capitulo 4 se explican brevemente la implementación y parámetros del modelo de simulación). Es por esto que el modelo se simulación debe ser flexible para adaptarse a requerimientos diversos y poder ser configurado con facilidad para reproducir el comportamiento en distintas condiciones. "




Los requerimientos sobre los comportamientos que se desean reproducir mediante simulación son elicitados en reuniones de análisis con científicos expertos en cada área. Dichos requerimientos cambian a lo largo del proyecto y distintos especialistas pueden tener requerimientos diferentes sobre las mismas partes de un modelo. Esto demanda flexibilidad y sencillez de configuración por parte del modelo de simulación.

"Además, no se evalúa, ni analiza, cómo la metodología propuesta permite alcanzar las mejoras planteadas en el trabajo."

En el capitulo 3 se incluye la subseccion "Beneficios de la metodología propuesta"



En el capitulo 5 se incluye:

"Nuestra metodología permitió alcanzar las mejoras y cubrir los requerimientos planteados mediante Ciclos de Construcción, para desarrollar entregables de calidad incremental en períodos cortos, obteniendo un modelo de simulación que reproduce el comportamiento del sistema real en diferentes condiciones. La herramienta de simulación implementada probó ser flexible ante cambios en el sistema real y ajustarse a los requerimientos de partida. Mediante Ciclos de Hipotetización, fue posible utilizar M&S para diseñar y evaluar mejoras a los algoritmos de control de TDAQ antes de su puesta en producción, donde el modelo de simulación pudo proveer predicciones acertadas. Utilizando Fases de Desarrollo de Herramienta se desarrollaron mejoras al simulador de base PowerDEVS, se implementó infraestructura para desacoplar el manejo de memoria de la lógica en los modelos atómicos y un nuevo framework para la ejecución de múltiples simulaciones en máquinas paralelas. Adicionalmente se mejoraron las herramientas de visualización e integración PowerDEVS-Scilab. El valor central de la metodología fue proveer un caso de éxito en tiempos cortos, de manera ordenada, y en un contexto exigente donde los usuarios de los modelos (principalmente científicos) requieren reportes minuciosos para justificar cada próximo paso. "




Nuestra metodología permitió alcanzar las mejoras y cubrir los requerimientos planteados mediante Ciclos de Construcción para desarrollar entregables de calidad incremental en períodos cortos, obteniendo un modelo de simulación que reproduce el comportamiento del sistema real en diferentes condiciones. La herramienta de simulación implementada probó ser flexible ante cambios en el sistema real y ajustarse a los requerimientos de partida.

"En el caso de estudio siempre se considera al caso real como factible de medir y experimentar, es realmente cierta esa hipótesis?"

En la seccion 4.1 se incluye:

"Como fue descripto anteriormente, en TDAQ no es factible medir y experimentar sobre el sistema real en todo momemento, por lo que se aprovecharon las semanas de testing disponibles para el grupo TDAQ. Aprovechando la separación clara en diferentes etapas y fases de la metodología, durante el tiempo en que no era factible realizar mediciones del HLT se enforcaron los esfuerzos en tareas referentes a mejorar el simulador o implementar el modelo. "


Tiene razón, para el caso general tal vez hay sistemas reales contra los que no se puede experimentar. Seguramente la metodología DEVS ya tenga esto ya estudiado, que se puede citar?

En el caso no se puede medir (que es sinónimo de obvervar) estas jugado... como modelas/verificas algo que no podes observar?

Footnote 2:



Asumimos que se tendrá acceso (al menos esporádico) al sistema real para tomar mediciones. En proyectos donde esto no se cumple, se modela en base a hipótesis de diseño y/o a leyes universales.

Comentarios menores:

página 1, Falta punto seguido en "...[4,5] Además ....

corregido



página 3, se referencia a la Fig 1 a), sería Fig 1.

corredido



si se incluye la Fig 2, debería ser referenciada en el texto.

Referencia incluida en la sección 2.2



página 4, revisar donde dice "ns2[18¡Error! No se encuentra el origen de

la referencia.]"

corregido



página 5, falta punto en el último párrafo de la sección 2.2

corregido



página 7, revisar donde dice "se quieren contestar sobre del Sistema de

partida"

corregido: del



página 9, revisar donde dice "[26]. :"

corregido



página 9, revisar donde dice "Si bien estos componentes del sistema real

son emulados todos los componentes de la red son, en cambio, los elementos

reales y finales que se utilizarán cuando TDAQ reingrese a su próxima fase

productiva"

no encontré error

ver orden de figuras 5 y 6

ver si las queremos cambiar: se menciona la fig 6 antes que la 5, pero es porque la 6 tiene la comparacion de resultados y para mi queda mejor mas abajo. No es gran cosa...

página 11, revisar donde dice "Finalmente se realizaron pruebas exhaustivas

sobre este modelo de TCP para verificar que su comportamiento deseado"

corregido: sea EL deseado



Fig 6, sería interesante emplear la misma escala en ambas gráficas a y b.

corregido. También en la figura 8.



ver orden de figuras 7 y 8

idem anterior



página 14, revisar donde dice "al cabo de un tiempo se vuelve es

equivalente a RANDOM"

corregido: “se vuelve equivalente a RANDOM”


    1. REVIEWER B:


"Realmente no se presenta muy claramente los aspectos metodológicos que se reivindican en el trabajo."

Consideramos que con los cambios incorporados producto de los comentarios de los revisores se mejoró la claridad acerca de aspectos metodológicos.

QUIERO DECIR: “Si tirás mala onda “en general”, te respondo también “en general” y te vas a cagar”



"Además el proceso iterativo-incremental involucra no solamente la construcción del modelo sino que también incluye la modificación de la herramienta de simulación, lo cual no es muy usual en los procesos de desarrollo."

En la seccion 3.2 se incluyé:

“Por otro lado, en proyectos exclusivamente de desarrollo de software no es usual modificar las herramientas utilizadas. Sin embargo, en proyectos de M&S el simulador y las herramientas de visualización son claves para éxito del proyecto por lo que deben actualizarse a la par del modelo, desarrollando nuevas técnicas que permitan adaptarse a los requerimientos. La metodología propuesta tiene estos cambios de las herramientas en consideración brindando un marco para que las mejoras que se introduzcan en este sentido se realicen en forma genérica, beneficiando no sólo al proyecto en cuestión sino también a toda la comunidad de M&S.”

YA ESTÁ RESPONDIDO. ACTUALIZAR CON MI NUEVA VERSIÓN DE ESTO MISMO

"Si bien el trabajo tiene una fuerte orientación a la construcción del modelo de simulación, no estrictamente vinculado con el análisis del software sino más bien orientado a la arquitectura de red y servidores."

En la seccion 4 se incluye:

"En esta sección se presentan brevemente los detalles técnicos de TDAQ más relevantes utilizados a lo largo del proyecto para crear el modelo de simulación. Los detalles de im-plementación, arquitectura y análisis de software quedan fuera del alcance de este documen-to para hacer hincapié en las decisiones metodológicas y de modelado. ".

Seccion 4.1 Implementacion del modelo: "Omitimos detalles de implementación, focalizando en decisiones de método y modelado."



    1. Otras actualizaciones:


- Se actualizaron las figuras 4,6,7,8 y 9 para mejorar su resolución, eliminar los textos en inglés, corregir escala en los ejes, etc.


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal