Compilación de finales viejos IngSoft2

General

> Cuál es la diferencia entre técnicas de verificación estáticas y dinámicas? De ejemplos concretos de técnicas para ambas categorías. Verificación Dinámica: intenta ejecutar y observar el comportamiento de un producto. No suele generar falso positivo, pero si mucho falso negativo. (ej. testing, run-time monitoring, run-time verification, valgrind, etc).

Verificación Estatica: intenta analizar una representación estatica del sistema para detectar problemas y extraer conclusiones. No se ejecuta nada. (ej. chequeo de tipos, code review, demostracion formal, model checking, etc). Puede generar falso positivo.

> Enumere y detalle tres atributos de calidad del software. Confiabilidad. Usabilidad. Correccion. Facilidad de mantenimiento. Robustez. Reusabilidad. Seguridad. Verificabilidad + claridad. Funcionalidad. Interoperabilidad.

> En el contexto de Especificación, que es un escenario implicado? Ejemplifique. Formalmente, se define un escenario como un conjunto de trazas tal que, combinada con todos los otros escenarios, proveen una descripcion completa del sistema. Uno en principio esperaria que dada uno un proceso correcto de sintesis, la FSM tenga las mismas trazas (se comporten de igual manera). Sin embargo, dado que las componentes solo poseen una vision local del sistema puede suceder que se comporten incorrectamente en terminos de trazas del sistema. Es posible que algunos escenarios se combinen en formas no esperadas y que induzcan que ciertos comportamientos no presentes en la especificacion del escenario aparezcan en todas las posibles implementaciones del sistema. A estos comportamientos se los llama escenarios implicados. La existencia de escenarios implicados es un indicador de comportamiento no deseado en el sistema.

> De argumentos para la aserción: 'La ingeniería de software no puede reducirse a un proceso formal (en el sentido de limitarse a la manipulación de descripciones formales'. De la definicion de validacion: "... Dado que involucra la realidad, necesariamente tiene que lidiar con informalidad ..."

> Cual es la diferencia entre verificacion y validacion? Ejemplifique. La validacion es un proceso cuyo objetivo es aumentar la confianza en que la denotacion del modelo es correcta. O sea que su descripcion formal se corresponda con la realidad. Dado que involucra la realidad, necesariamente tiene que lidiar con informalidad. Mas aun, debe establecer una nocion de correctitud entre un modelo formal y algo informal. La verificacion es un proceso cuyo objetivo es garantizar que una descripcion formal es correcta con respecto a otra. A diferencia de la validacion, solo involucra modelos formales. Sin embargo, la vinculacion de los modelos no es trivial de formalizar. Si bien una vez formalizado se podrian generar pruebas automaticas, la complejidad (tanto espacial como temporal) de estas puede ser excesiva. Validacion: es el proceso de evaluacion de software durante o al final del proceso de desarrollo para determinar si satisface los requisitos especificados. Se basa en el uso de modelos. Intenta responder la pregunta: “¿estamos construyendo el producto correcto? ” Verificacion: es el proceso de evaluacion de software para determinar si los productos de una fase de desarrollo dada cumplen con los requisitos impuestos al inicio de dicha fase. Necesariamente se trabaja en relacion a un componente anterior que describe nuestro producto. Intenta responder la pregunta: “¿Estamos haciendo el producto correctamente? ”.

Ingeniería de requerimientos

> Explique que es pertinencia y completitud de requerimientos y cómo un modelo de objetivos ayuda a lograr ambos. Pertinencia de un conjunto de requerimientos: no existe requerimientos que no ayuden a lograr los objetivos. Completitud de un conjunto de requerimientos: estan todos los requerimientos necesarios para lograr los objetivos. Esto se logra con el modelo de objetivos siempre que (D suposiciones de dominio, R los requerimientos, G objetivos): .) Dado D, R se garantiza G. .) G captura adecuadamente las necesidades de los stakeholders. .) D representa presunciones validas acerca del mundo.

> Explique los riesgos asociados a la definición de alcance en Ingeniería de Requerimientos en términos de la relación que existe entre síntoma y problema más general. Ejemplifique.

> A que nos referimos cuando decimos que los requerimientos, tanto funcionales como no funcionales, deben ser refutables de manera objetiva. Que un req. sea refutable de manera objetiva habla de un req. con el que se pueda trabajar, ya que si aceptamos req. que no lo sean estaremos atados a la subjetividad de quien lo escribe. Ejemplo: “la interfaz de la aplicacion será linda”, este es requerimiento no funcional, ok, ¿Pero que sería lindo? ¿Cómo se refuta esto de manera objetiva?

> Explique que es un stakeholder en el contexto de Ingeniería de Requerimientos. De la definición de elicitación: “… clientes, usuarios y otros stakeholders … no siempre los stakeholders tienen claro lo que quieren y muchas veces, aun cuando lo tienen claro no saben expresarlo” Un stakeholder es un grupo de individuos que se ven afectados por el sistema a construir. Suelen tener un papel importante a la hora de la aceptación y son una fuente importante de informacion en la ingenieria de requerimientos

> Como impacta en la ingeniería de requerimientos considerar al equipo de desarrollo de un proyecto de software como parte de los stakeholders. > Explique el modelo Twin Peaks utilizado para la Ingeniería de Requerimientos. Dentro del contexto de Modelos de Desarrollo (modelo en V, modelo en cascada, modelo en espiral). El modelo Twin Peaks, propone un modelo de exploración alternada entre la definición del problema y la definición de la solución, incrementando en cada salto, el nivel de detalle de cada una de las definiciones.

> Cual es el argumento económico que pretende justificar la Ingeniería de requerimientos? Uno de los usos de la ingenierıa de requerimientos es el de encontrar errores tempranamente en el desarrollo del software. Esto es extremadamente importante porque la deteccion de errores en forma temprana redunda en costos muy inferiores para su arreglo. Un error detectado, por ejemplo, durante el perıodo de mantenimiento puede tener un costo 200 veces mas elevado para su reparacion que detectado en la etapa de requerimientos. [El testing] Se le atribuye de 30% a 50% del costo de un software confiable.

> Segun Jackson, cual es la relacion entre monitoreabilidad/controlabilidad y la noción de requerimientos? Un requerimiento es un objetivo uni-agente que tiene que cumplir el sistema. Se dice que un objetivo es realizable por un agente si: .) El agente puede monitorear los fenomenos necesarios para satisfacer el objetivo. .) El agente puede controlar los fenomenos cuya ocurrencia necesita ser restringida para satisfacer el objetivo. .) No es necesario que el agente pueda conocer el futuro para garantizar el objetivo en el presente.

> El modelo de Jackson distingue entre aserciones descriptivas y prescriptivas. Explique por qué esta distinción es relevante al momento de hacer verificación y validación del documento de requerimientos. Aserciones descriptivas: definen cosas que son o presumimos ciertas en el mundo sobre el que trabajamos. En general son del tipo de restricciones de dominio. Taxonomia de aserciones descriptivas: si son propiedades fisicas son Propiedades del Dominio; si son caracteristicas aunque sujetas a cambios (por ejemplo: “la moneda argentina es el peso”) se denominan Hipotesis del Dominio.

Aserciones prescriptivas: definen cosas que esperamos que vayan a ser ciertas una vez que sea afectado por nuestro sistema. (incluye Objetivos y Requerimientos). Objetivos: cosas que esperamos que vayan a ser ciertas en el mundo una vez que sea afectado por nuestro sistema (objetivos multiagente). Requerimientos: cosas que debemos hacer que sean ciertas en la interfaz (objetivos uniagentes). Taxonomia de requerimientos: expectativa (si el requerimiento es una asignacion de responsabilidades a un agente externo) o requerimientos (nuestro sistema debera encargarse de cumplirlos). Las aserciones prescriptivas son relevantes para la verificacion, ya que contienen informacion sobre el resultado esperado. Las descriptivas son utiles para validar, ya que contienen informacion sobre el entorno donde estara el sistema a construir. Es comun validar propiedades del dominio con un experto de dominio para ver si tienen sentido, por ejemplo avion sobre pista <=> ruedas en movimiento . Las prescriptivas tambien son utiles para corrobar con el experto ( o stakeholders) ya que son estos quienes conocen lo que se espera obtener del sistema. En resumen, tienen informacion relevante (y muy importante) para poder realizar la verificacion y validacion, recordando que la validacion es contra el problema y la verificacion es contra otra especificacion.

Diagramas y modelos > Explique el vínculo entre una composición en paralelo de maquinas de estado y sus trazas con los modelos de agentes y de objetivos. Ejemplifique. > Explique diferencias entre objetivos de comportamiento y objetivos blandos. Un objetivo se puede categorizar como de comportamiento o blandos. Un objetivo se dice de comportamiento cuando recorta el espacio de comportamiento permitido del software. La comprobacion del objetivo es una funcion binaria que toma una traza o ejecucion y devuelve si el objetivo se satisfizo. Para un sistema debo prohibir cualquier ejecucion del mundo que no satisfaga alguno de mis objetivos. Los objetivos de comportamiento tienen un correlato con modelos operacionales de comportamiento (FSM y diagrama de secuencia). Son los de tipo lograr, mantener y evitar. Los objetivos blandos, en cambio son aquellos que denotan preferencia entre comportamientos. Permiten expresar ventajas y desventajas en cuanto a aspectos puntuales en o-refinamientos. Su satisfaccion no puede establecerse mirando un sistema o una traza, deben compararse al menos dos. Es muy dificil vincular con modelos de comportamiento. Son los objetivos de tipo objetivo blando. Pueden categorizarse en cosas del tipo maximizar, incrementar, mejorar, etc.

> Diferencias entre objetivos blandos y duros. > Que relacion existe entre objetivos blandos y no funcionales? Ejemplifique. Son dos clasificaciones ortogonales. Los no funcionales responden si o no, mientras que los blandos sirven para comparar alternativas. No-funcional : La respuesta al comando debe ser menor a 50 milisegundos. Objetivo blando : La respuesta al comando debe ser rapida (Minimizar[tiempo de respuesta al comando])

> ¿Qué son y qué rol juegan los obstáculos en la elaboración del modelo de objetivos? > V o F: Los objetivos de alto nivel son más estables? > Qué significa que un objetivo sea medible? Ejemplifique para tres aspectos no funcionales cubriendo objetivos blandos y de comportamiento. > Que patrón de refinamiento del modelo de objetivos está fuertemente vinculado con la noción de interfaz del modelo de Jackson. Explique y dé un ejemplo. > Explique en general la relación entre las hojas de un grafo de objetivos y las operaciones en un modelo de operaciones y en particular la multiplicidad de dicha relación. Ejemplifique. Las hojas de un grafo de objetivos son aquellos objetivos de mas bajo nivel y los cuales estan asignados a agentes (en general a un solo agente). Segun el agente asignado se categorizan en expetativas o requerimiento. Los requerimientos inducen operaciones del software. Las expetativas inducen operacion de agentes. No siempre es una relacion uno a uno. Los casos de uso son o agrupan operaciones.Los casos de uso operacionalizan expectativas.Requerimientos inducen operacionen. Ejemplo, objetivo si nivel bajo de stock => activar alarma podria refinarse en Mantener[Contabilizacion de stock] (asignado a el agente software) y Sonar alarma si nivel bajo (asignado a la alarma) en un CU podrian estar los dos objetivos a un mismo CU.

> Cuando un objetivo es realizable por un agente? De ejemplos de objetivos realizables y objetivos no realizables. Un objetivo es realizable por a un agente si el agente: .) puede monitorear los fenómenos necesarios para satisfacer el objetivo .) el agente puede controlar los fenómenos cuya ocurrencia necesita ser restringida para satisfacer el objetivo .) no es necesario conocer el futuro para garantizar el objetivo en el presente Ejemplo no realizable: Falta de controlabilidad – “Aceleración de reversa estará habilitada si y solo si hay pulsos en las ruedas” no puede asignarse al sensor de pulsos.

> Como refina el modelo de objetivos la taxonomía de aserciones de Jackson? El modelo de objetivos refina las taxonomias de las aserciones en dos ramas principales que son las funcionales y las no-funcionales. Las funcionales son aquellas que definen como se comporta el requerimientos con el entorno. Las no-Funcionales son restricciones sobre el como los requerimientos funcionales satisfacen los requerimientos funcionales o en la forma que deben ser desarollados.

> En el contexto de un modelo de objetivos, qué es un objetivo de alto nivel? Cómo se vinculan estos con la estabilidad o evolución de objetivos. Los objetivos pueden ser categorizados en alto o bajo nivel en funcion de su grado de abstraccion. Un objetivo de alto nivel es mas estrategico, de negocios. Por el contrario, los objetivos de bajo nivel suelen ser mas tecnicos, ser mas cercanos a las decisiones de diseño e involucrar menos agentes para su realizacion. En el caso extremo, en el que un objetivo tenga asociado un solo agente externo se lo llama objetivo uni-agente o expectativa.

> V o F. La elaboración del modelo de objetivos se realiza de manera top-down, es decir refinando los objetivos de alto nivel en objetivos de más bajo nivel. El proceso de elicitacion de objetivos puede realizarse temprana- o tardia- mente. En el primer caso, se indaga sobre los problemas y deficiencias del sistema actual (suponiendo que haya uno) y los objetivos de mejora y estrategia del cliente a futuro. Esto se puede realizar mediante distintas tecnicas de elicitacion, tales como basadas en stakeholders (entrevistar stakeholders, tanto individual- como grupal- mente) o basadas en documentacion (revisar documentacion del sistema existente). Es frecuente utilizar checklists de categorias de objetivos. En el caso de elicitacion tardia (llamada elicitacion posterior) se puede realizar por tres tecnicas: .) Por abstraccion (bottom-up): se pregunta “¿por que?” sobre distintos elementos (objetivos de bajo nivel, escenarios, descripciones operaciones, FSMs, manuales de procedimientos, etc). Por ejemplo, se indaga por algun objetivo puntual y conocido de bajo nivel (o conjunto de) y se pregunta “¿Por que se hace esto? ¿con que fin?”. La respuesta a esto induce a descubrir uno o mas objetivos a los que este objetivo contribuye, de nivel un poco mas alto. Iterando este proceso, se puede ir planteando “desde abajo hacia arriba” un posible diagrama de objetivos. El alcance acota los objetivos. Se intenta relevancia de todos los fenomenos y propiedades en otros modelos. Se evita el riesgo de regresion de objetivos. .) Por refinamiento (top-down): se pregunta “¿como?” sobre objetivos disponibles. Similarmente al caso anterior, se indaga por algun objetivo pero de alto nivel y se pregunta: “¿y como se logra esto? ¿hay otra opcion?”. La respuesta permite plantear objetivos de mas bajo nivel que contribuyan a lograrlo. Iterando, se puede plantear “desde arriba hacia abajo” un posible diagrama de objetivos. En general uno detiene el proceso cuando logra objetivos uni-agente (expectativas) o propiedades del entorno. .) Por resolucion de conflictos y obstaculos: se plantea el diagrama a medida que van surgiendo conflictos, basandose en las soluciones planteadas.

> A que se refiere la siguiente aserción: El análisis de obstáculos permite desidealizar objetivos. Se refiere a que los objetivos a veces suelen ser de un grado de idealización alto y el analisis de objetivos trata de encontrar situaciones donde estos no se hacen verdaderos. Desidealizar un objetivo permite que este sea mas fuerte (hay menos contra ejemplos que prohiben cumplir objetivos de alto nivel). El analisis de obstaculos tambien sirve para la completitud, ya que la negacion de los obstaculos , junto con las propiedades del dominio deberia implicar el objetivo de mas alto nivel. not(O1),not(O2),...,not(On) Dominio |= G Ejemplo de objetivo muy ideal , Lograr[Ambulancia en lugar de incidente en 15 minutos]. Este objetivo es demasiado ideal, por ejemplo si una ambulancia se rompe en el camino, o si hay trafico hacen que el objetivo no sea verdadero. El que se rompa la ambulancia o el trafico serian los obstaculos. Una posible desidealizacion seria Lograr[Ambulancia en lugar de incidente].

> ¿Cuándo paro de refinar los objetivos en un grafo de objetivos? De dos explicaciones una de un punto de vista teórico y el otro práctico. > Explique los diversos vínculos que pueden establecerse entre el modelo de Agentes y el de Objetivos. > Explique qué vínculos semánticos deberían existir entre un modelo objetivos y uno de operaciones (a la pre/post-condición). > Explique de qué manera se vincula el modelo conceptual con el modelo de objetivos y el modelo de agentes. > V o F. Un Y-refinamiento que no es mínimo es una forma adecuada de modelar requerimientos para un sistema robusto. > Definir y comprar un refinamiento por casos y un o-refinamiento? Los o-refinamientos permiten vincular un objetivo con un conjunto de y-refinamientos, proveyendo “caminos” alternativos para contribuir a lograr un objetivo dado. Refinamiento por casos: caso particular de y-refinamiento, que permite introducir objetivos complementarios ... una particion completa (aunque no necesariamente disjunta) en casos

> Definir los tres tipos de relación en el modelo conceptual. Asociacion, agregacion y composicion. .) Asociacion es un tipo bidireccional que relacion dos clases conceptuales en el modelo. Existen varios tipos uno a uno, uno a muchos y muchos a muchos. .) Agregacion es un tipo especial de asociacion que trata de modelar “todo/parte de”. Suele usarse con la idea de modelar la pertenencia de una clase a un conjunto. Una clase puede componenerse con muchas. .) Composicion tipo especial de composicion mas fuerte. Modela “parte de”. es mas fuerte que la agregacion porque : ..) marca el ciclo de vida de una entidad ..) una entidad solo puede pertenecer a una composicion

> Asumiendo que en el modelo conceptual no se asignan operaciones a clases conceptuales, como se diferencia la noción de herencia de un diagrama de clases en el contexto de modelado conceptual y diseño. > A que nos referimos cuando hablamos de relaciones derivadas en modelos conceptuales? Son relaciones que no estan almacenadas y puede obtenerse en base a otras relaciones existentes en el modelo.

> Explique las posibles cardinalidades del modelo conceptual y como se relacionan con OCL. > Elabore un pequeño modelo conceptual respecto del modelo de agentes y el diagrama de contexto. > En el análisis de condiciones de borde, qué heurísticas pueden aplicarse en base al modelo conceptual? > Qué significa que un modelo tenga semántica de prunning? Mencionar un modelo de la materia que tenga esa semántica. La semantica de recorte o prunning define que a medida que agregamos restricciones y especificaciones el espacio de interpretaciones validas se va achicando (justamente, lo estamos recortando). Tanto el modelo de operaciones (con pre- y post-condiciones) como el de objetivos (mediante objetivos de comportamiento que deban cumplirse) utilizan semantica de prunning.

> Como se le puede dar semántica a un diagrama de secuencia? La semántica de un diagrama de secuencias está dada por las trazas que genera, definiendo un orden parcial entre los mensajes enviados o recibidos por un componente. En el caso de que los mensajes se consideren asincrónicos, los eventos sobre los cuales se define el orden son el envío y recepción de los mensajes y no los mensajes en sí.

> Cual es la diferencia entre un diagrama de flujo de datos (DFD) y un diagrama de actividad. Los DFD representan el flujo de datos entre componentes de un sistemas. Cada nodo es un componente del sistema y las transicion representa el flujo de datos. Mientras que los diagramas de actividad se utilizan para representar en los nodos actividades y los ejes se utilizan para representar la secuencia o lo que sigue a la siguiente actividad.

> Explique que significa que los Diagramas de secuencia tengan una semántica de ordenes parciales. En pocas palabras significa que la semantica es de secuencia de eventos. Algunos eventos o mensajes tienen restricciones entre ellos, pero por ejemplo en el grafico siguiente entre a y c no hay orden y permite tener las siguientes secuencias de eventos que no contradicen el diagrama : a,c,b,c,a,b. El diagrama dice que no puede ocurrir b si todavia no ocurrio a.

> Compare, mencionando similitudes y diferencias, los diagramas de secuencia y los de colaboración. > V o F. En un diagrama de agentes, flechas denotan flujo de datos. > Explique y ejemplifique cómo se le da semántica a un diagrama de clases (cubra la notación básica, clases, asociaciones, herencia y multiplicidades). > Qué es el scope y span de un modelo? Ejemplifique con modelos vistos en clase. > Explique que modelan las cajas y las flechas en un modelo de contexto. La relación de monitoreabilidad y controlabilidad entre agentes del mundo y entre agentes del mundo y la máquina.

> Explicar con qué modelo de los vistos está asociado OCL y por qué. A veces uno quiere recortar las interpretaciones posibles al modelo conceptual. OCL es la herramienta para recortar el modelo (esto se lo suele llamar semantica de prunning).

> Explique la diferencia entre lenguajes de especificación de comportamiento basados en interacciones y estados. De ejemplos de notaciones concretas de ambas categorías. Los de interacción describen escenarios de intercambios de mensajes, mientras que los basados en estado muestran las acciones que deben ocurrir para cambiar de estado. Los de interaccion tienen semantica de orden parcial y los de estado tienen la lineal y arborea. La mas importante me parece es que los basado en estado modelan todos los comportamientos posibles, mientras que los de interaccion no lo hacen Esto es el motivo de los escenarios implicados. Ademas los de interaccion podrian no describir ciertas situaciones, osea son lenguajes limitados y los de estados no es asi (creo). Tambien los de interaccion tiene un vision global, mientras que los de estados tiene un vision mas aislada ya que solo modelan un agente (claro en la composicion no es asi). Ejemplos: .) Basado en estados : LTS,Maquinas de estados .) Basado en interacciones : Diagramas de secuencia.

> En el contexto de modelos de comportamiento, que significa que una semántica sea ejecutable? Ejemplifique. > Explique la noción de herencia y sus usos en los diagramas de casos de uso. > Cómo relacionaría OCL con casos de uso? Mencione qué supuestos necesita que se cumplan (si es que los necesita). > Explique y ejemplifique en el contexto de modelos de casos de uso el problema de los elementos foráneos. > Cómo relaciona el modelo de Jackson con la técnica de casos de uso? > Qué actividades de verificación haría entre una especificación de casos de uso y una de LTS? > Explique informalmente en relación a conjuntos de trazas, la semántica de 'includes' y 'extends' en un diagrama de casos de uso. A --- incluye --- > B Semantica : Sea s un escenario denotado por A, entonces una porcion de s contiene un escenario denotado por B A <--- extiende --- B Semantica : existe almenos un escenario s denotado por A, que contiene un escenario denotado por B.

> En el Diagrama de Casos de Uso, la definición de relación 'participa en' entre un actor y un caso de uso está dada en función de la sintaxis de la descripción detallada del caso de uso. Explique cuál es esta definición y por qué no da garantías semánticas. > Explique la diferencia entre una alternativa al curso normal de un caso de uso y una extensión de un caso de uso. > Dado un caso de uso simple con precondición y una descripción detallada sin condicionales, ciclos, puntos de extensión e inclusión, explique qué condiciones impone sobre el sistema final a implementar. El caso de uso es una propiedad lineal o arbórea? Justifique. > Suponga que un dominio ha sido descrito utilizando una composición de máquinas de estado y un diagrama de contexto. Qué vínculos esperaría encontrar entre ellos? > Explique el vínculo entre diagramas de secuencia y máquinas de estado. > Explique la relación entre no-determinismo en modelos de maquinas de estado y la noción de equivalencia dada por bisimulación. > Tenés dos FSM deadlock free, y te dan las trazas de ellos, pero no la estructura. Alcanza sólo con las trazas para garantizar que la composición de esos dos FSM es deadlock free? > Cómo relacionaría OCL con FSM? Mencione que supuestos necesita que se cumplan (si es que los necesita). > Dar 3 similitudes y 3 diferencias entre diagrama de actividad y LTS. > V o F. 'Para dos LTS deterministicas, son equivalentes la bisimulación fuerte y la equivalencia por trazas'. > Explique qué significa y cómo puede darse semántica a autómatas temporizados usando LTS. Explicando automatas temporales en terminos de otra notacion conocida, como LTS. Una LTS es una tupla (S,L,SxLxS,s0) Un automata temporal es una tupla del estidlo (S,L,SxL + Reales X S, s0). La semantica de TA hereda una nocion de bisimulacion y la operacion de composicion en paralelo. Semantica informal : .) Un estado es un par (s,v) con s \in S y v \in V y Is[v] =true. .) El tiempo solo transcurre en los nodos. .) El tiempo de transicion como despreciable. .) El tiempo avanza uniformemente en los relojes .) Se puede pasar a una transicion si su guarda es true. .) Siempre que el valor de los relojes sea verdadero se puede estar en el estado (ojo una transicion podria hacer que salga).

> V o F. La composición en paralelo de LTS permite modelar la ocurrencia simultánea de eventos. > A que nos referimos con que los LTS tienen un semantica arborea. Ejemplifique.

> V o F. 'Aunque la semántica de LTS no puede describir de manera directa la ocurrencia de eventos simultáneos, es posible hacerlo mediante algunos trucos de modelado.' > Qué quiere decir que la semántica de la composición en paralelo de LTS es asíncrona y de 'interleaving'. > V o F. La composición en paralela es simétrica. > La semántica de diagramas de actividad puede definirse en términos de redes de Petri. Explique y ejemplifique. > En redes de Petri, explique que es un Marking, un marking alcanzable y que una red sea N-safe. Un marking es una asignacion de token a un place. Un marking se dice que es alcanzable cuando existe una secuencia de transiciones desde el marking inicial que resulta de un marking (el alcanzable). Un marking se dice N-safe cuando no es posible alcanzar ningun marking que contengan mas de N tokens.

> Cuales son las diferencias fundamentales entre los LTS y las redes Petri. Sintacticas Las redes petri tienen asignacion de tokens, mientras que las LTS no tienen esto. Las redes petri pueden pasar tokens si el valor de sus ejes lo permite (y tambien su direccion). Las LTS tienen la idea de siguen_a, que intentan modelar como se mueve el sistema (o cambia de estado) segun los eventos o operaciones que se aplican.

Semanticas Las redes de petri modelan la simultaneidad, mientras que las LTS modelan concurrencia por interleave de labels. Redes petri tienen un vision global, mientras que las LTS cada agente se modela aparte y luego se componen. Redes petri tienen semantica de ordenes parciales mientras que LTS lineal/arborea

> Cuál es la diferencia entre la denotación y la semántica de un lenguaje. Ejemplifique. > Defina composición en paralelo y ejemplifique cómo funciona cuando las máquinas tienen distintos alfabetos. > Que es una relación de bisimulación? Por que adoptarla como criterio de equivalencia en vez de equivalencia por trazas? Es una relacion de equivalencia que permite comparar LTS. Informalmente se podria decir que intenta capturar que las dos LTS se mueven hacia el mismo estado, dando la sensacion de que las maquinas son equivalente para un observador. Depende, pero la bisimulacion es mejor criterio que la de trazas al momento de detectar no-determinismo por ejemplo, algo que trazas no puede ver.

> A que nos referimos cuando decimos que la bisimulación es una congruencia? Congruencia : Dado un contexto para P, se quiere poder cambiar P por un proceso equivalente sin alterar el sistema. La semantica informal de bisimulacion es que las dos maquinas se mueven a los mismos estados, y esto para un observador equivale a que son iguales (observa lo mismo para las dos maquinas). Osea que existe una relacion entre los estados de las dos maquinas.

Testing

> Explique de qué manera modifica el uso de grafos causa y efecto la explosión combinatoria de tests generados en técnicas de partición de categorías. > Explique que es un grafo de causa-efecto y para qué sirve en el contexto de testing. TL;DR: Un grafo de causa efecto es una tecnica de generacion de tests que se basa en testear todas los outputs posibles de una unidad a testear. Mas en detalle es una heuristica que permite generar estos casos con complejidad O(n*k*o). En el contexto de testing sirve para la generacion automatica de casos de test. La tecnica de grafos causa-efecto nos permite definir combinaciones relevantes de categorias binarias sobre inputs para definir casos. Alli difiere de la parte combinatoria de Category-Partition. Sirve para especificaciones de I/O complejas (en las que hay mucha dependencia entre Inputs, entre Outputs y entre I/O). Provee un display visual de las relaciones entre una causa y la otra. Ayuda a detectar ambiguedades o incompletitud en la especificacion. Esta tecnica permite generar todos los outputs admisibles con la siguiente heuristica: .) Si hay un “or” (todas las opciones con solo una senal en True). .) Si hay un “and” (todas con solo una en False). Esta heuristica logra una complejidad de O(n ∗ k ∗ o) en lugar de O(2^n) donde n es la cantidad de categorias binarias sobre el input, k la profundidad del DAG y o la cantidad de combinaciones del output validas.

> Explique diferencias entre falla, defecto y error. Explique qué rol juega cada uno de estos términos en testing. Falla: es una diferencia en tiempo de ejecucion entre lo que hace el software y lo que uno quiere que haga (diferencia entre resultados esperados y reales). Es la exteriorizacion o manifestacion efectiva de un defecto. Defecto: es un problema en el codigo de un programa, en una especificacion o un diseño que puede (o no) dar lugar a una falla. Error: es una equivocacion humana, el motivo por el cual se introduce uno o mas defectos. "... un conjunto de tests apropiado debe ser suficientemente grande como para abarcar todo el dominio y maximizar la probabilidad de encontrar defectos ..." Un error lleva a una o mas defectos. Un defecto lleva a cero, una o mas fallas. La falla es la manifestacion del error.

> Es un test por random es mas efectivo que un test de particion de dominio? Esto depende de la distribucion de los errores. Cuando hay particiones donde la mayoria de sus elementos producen fallas se maximiza la probabilidad de encontrar errores. Pero podria pasar que al realizar las particiones da igual (uniforme) o podria ser peor. Es peor cuando hay muchos subdominios pero las fallas estan concentradas en solo uno y este es muy grande.

> Qué es un oráculo en testing y para qué se usa? Un oraculo es una entidad que nos puede brindar informacion del comportamiento esperado del programa. Puede ser un humano, una especificacion, otro sistema (que ya se sepa que funciona), etc.

> Explique que es Data Flow Testing y ejemplifique con una técnica de testing concreta. Data-flow testing is a control-flow testing technique which also examines the lifecycle of data variables. The primary purpose of dynamic data-flow testing is to uncover possible bugs in data usage during the execution of the code. To achieve this, test cases are created which trace every definition to each of its use and every use is traced to each of its definition. Various strategies are employed for the creation of the test cases. All-du paths (ADUP), All-Uses (AU), All-p-uses (APU), All-c-uses (ACU), All-p-uses/Some-c-uses (APU+C).

> En el contexto de testing estructural , que son y cual es el problema de caminos no factibles? Se denomina camino no factible a un camino en un flowgraph para el cual no existe input del programa que fuerce su ejecucion.

> V o F. El testing es un tecnica de verificacion. Verdadero. La verificacion trata sobre la comparacion de una funcion, metodo, procedimiento contra una especificacion (que puede ser texto, un modelo,etc). El testing no puede garantizar la inexistencia de errores,pero si podria mostrar la existencia de uno o mas fallas.

> Explique el uso de arreglos ortogonales para testing. Indique relación entre fuerza, niveles y factores. La tecnica de arreglos ortogonales consiste en elegir 2 parametros (la 2-wise ) independientes y con estos dos armar todas las Combinaciones. Esto es valido bajo el supuesto de que los parametros tienen una cantidad finita de choices. El uso en testing es para reducir la cantidad (o la explosión combinatoria) de casos de test. .) Factor: columnas que son los parametros. .) Nivel: es la cantidad de eleccion que tiene cada columna (choices). .) Fuerza: Cantidad de columnas tales que las X=nivel^fuerza posibilidades aparecen la misma cantidad de veces. Esta tecnica es ideal cuando hay parametros de configuracion. Como por ejemplo un sistema que corre sobre distintos sistemas operativos, distintas resoluciones y procesadores. Quiza un ejemplo podria ser un web, que corre bajo PCs, celulares,etc. Tambien se utiliza en programacion orientada a objetos para testear metodos cuando hay una herencia compleja.

> Teniendo muchos parametros que tienen poca dependencia entre si. Se puede usar arreglos ortogonales? Si, siempre y cuando se cumpla que existen parametros independendientes entre si (osea sin dependencia) y ademas son enumerados finitos (cantidad de choices).

> Que son y cual es el rol de stubs y drivers en testing? Test de integracion: esta orientado a verificar que las partes de un sistema que funcionan bien aisladamente, tambien lo hagan en conjunto. Se testea la interaccion y comunicacion entre las partes, uniendolas. La “estrategia” de union depende del tipo de sistema (puede ser organizado jerarquicamente, batch de procesamiento secuencial o un sistema sin jerarquıa). Pueden programarse “accesorios” para simplificar este testing, tales como drivers (simula las llamadas) o stubs (simula subprogramas). Stubs : Se utilizan en testing de integracion cuando hay una relacion de jerarquia (por ejemplo modulos) de lo que se quiere testear. Se necesitan los stubs cuando se empieza el testing top-down y los stubs simulan subprogramas los cuales no estan todavia implementados o no se tienen. Drivers : Se utilizan en testing de integracion ideam anterior pero cuando es bottom-up.

> Justifique por que decimos que el testing estructural (o de caja blanca) complementa al testing funcional (o de caja negra). Cualquier tecnica de seleccion de casos que no esta basada en el comportamiento funcional, esta mal guiada desde el comienzo porque los usuarios no usan el software para ejecutar sus instrucciones, sino para invocar sus funcionalidades ... sin embargo ... el testing basado en codigo encuentra muchos errores.

> Explique similitudes y diferencias entre el control flow graph y un def-use graph en el contexto de testing. Para realizar un test estructural de unidades de programas es necesario realizar un analisis en el que se representa el flujo de control de un programa a traves de un grafo de flujo, flowchart o Control Flow Graph (CFG). Solo sirve con programas secuenciales, con un unico punto de ingreso y un unico punto de terminacion. Cada instruccion se grafica en un nodo y, si es una instruccion que altera el flujo de control, se une a otros nodos de diversas formas. El def-use graph es un CFG aumentado con indicadores de definición (de una variable), usos computacionales, y usos de predicado. Se procede con el criterio de la siguiente manera: .) Por cada definicion de x, el nodo asociado se etiqueta con una definicion de x. .) Por cada c-uso, el nodo asociado se etiqueta con un uso de x. .) Por cada p-uso todos los arcos salientes del nodo asociado se etiquetan con un uso de x.

> Dé tres heurísticas que puedan utilizarse en la partición del dominio en categorías en el contexto de generación de tests. .) Los casos de test que exploran los bordes de las clases de equivalencia producen mejor resultado. Cada margen de la clase de equivalencia debe quedar sujeto a un test. .) Si una condicion de input especifica un rango de valores (intervalo), identificar una clase valida, dos invalidas y dos casos borde. Por ejemplo, si especifica que el parametro puede variar entre 0 y 99, poner como clase valida el rango 0 < v < 99, como invalidas v < 0 y 99 < v y como borde v = 0 y v = 99. .) Si una condicion de input especifica un conjunto de valores, y hay razones para pensar que cada uno es manejado por el programa en forma distinta, identificar una clase valida por cada elemento y una clase invalida. .) Si una condicion de input especifica una situacion que debe ocurrir, identificar una clase valida y una clase invalida (una que verifique la situacion y otra que no). .) Probar el ingreso de valores de otro tipo que la clase. .) Probar alterando caracteristicas propias de los tipos de datos de entrada y salida de la funcionalidad testeada. (Ejemplo, fechas futuras, dias de semana inexistentes, etc). .) Verificar la cardinalidad del modelo de datos. La cardinalidad minima/maxima define cuantas instancias hay como minimo/como maximo de una entidad por cada instancia de una entidad rela- cionada con ella. Probar un caso de test que viole estos limites de cardinalidad (por ejemplo una cuenta con 3 firmantes, siendo su cardinalidad maxima 2). .) Ciclo de vida de las entidades: Vision temporal del modelo de datos: a partir de un diagrama del ciclo de vida de una entidad debo probar transiciones validas asi como transiciones invalidas.

> Que significa que un criterio de test subsume a otro? Formalmente, decimos que un criterio C 1 subsume a un criterio C 2 si para todo conjunto de datos de test T que satisface a C 1 , satisface a C 2 (para todo par (P, S)). Informalmente el predicado de C 1 es mas fuerte que el de C 2 (o sea, implica a su predicado trivialmente). Branch subsume a Statement. Alluses subsume a Branch (y, por transitividad, a Statement).

> Suponiendo que tenemos un criterio de test C que subsume a otro criterio de test D. ¿Es cierto que la probabilidad de encontrar una falla con un criterio que verifique C es mayor o igual que la probabilidad de encontrar una falla con un criterio que verifique D? C subsume a D. Cualquier conjunto de datos de test que satisfaga C, también satisface D; pero pueden existir conjuntos de datos de test que satisfagan D, y no satisfagan C. Creo que la respuesta se deduce de esto, pero no me queda claro lo que pregunta.

> En que se diferencia el test de integración del de sistema y del de unidad. Mencione y ejemplifique alguna estrategia de integración. .) Test de unidad: se realiza sobre una unidad de codigo 7 pequena, claramente definida. En general es llevado a cabo por los propios desarrolladores. Su dificultad radica en que posiblemente muchas piezas necesarias para un test completo de una unidad no esten construidas. .) Test de integracion: esta orientado a verificar que las partes de un sistema que funcionan bien aisladamente, tambien lo hagan en conjunto. Se testea la interaccion y comunicacion entre las partes, uniendolas. Estrategias: ..) Estrategia Jerarquica : Cuando hay jerarquias (usualmente con modulos), se utilizan tecnicas top-down,bottom-up o mixta. En estas entran en juego los stub y drivers. Los drivers se utilizan para tecnicar bottom-up, ya que simulan las llamadas a los subprogramas y tambien verifican la salida. Los stubs se utilizan para tecnicas topdown y simulan subprogramas. Tanto el driver como los stubs consumen tiempo de desarrollo importante. ..) Estrategia Libre : Usualmente se da cuando se utiliza programacion orientada a objetos. ..) Estrategia batch de procesamiento secuencial : Se separan por partes del flow de corrida

> Que significa que un criterio de test sea completo? Y consistente? .) Se dice que un criterio es consistente si todo par de test sets que lo satisfacen, uno de ellos es exitoso si y solo si el otro lo es. Formalmente, T 1 y T 2 satisfacen C ⇒ T 1 exitoso ⇔ T 2 exitoso. .) Se dice que un criterio es completo si en caso de que el programa sea incorrecto, entonces existe un test set que satisface al criterio para el que no va a ser exitoso. Cuando uno recorta casos de testing, en general pone en riego la completitud del criterio. Formalmente P incorrecto ⇒ ∃T : T no es exitoso para P.

> V o F. Si tengo un criterio de test ideal (completo y consistente) entonces ejecutar cualquier test suite que satisface ese criterio me alcanza para saber si el programa es correcto. Repasando definiciones de testing: .) Test Suite T: conjunto de datos de test con los que se testea el programa. .) Si P es correcto para todo elemento de T, se dice que T es exitoso para P. .) Un criterio es un subconjunto de conjuntos finitos del dominio de Inputs del programa P . .) Se dice que un conjunto de datos T satisface un criterio C sii T pertenece a C. .) Un Criterio C es Consistente para P sii para todo par T1 y T2 de test sets que satisfacen C, T1 es exitoso para P sii T2 lo es. .) Un Criterio C es Completo para P sii si P es incorrecto entonces hay un test set T que no es exitoso para P. Suponiendo que el programa es correcto, entonces cualquier test T perteneciente a C indicará que es correcto, pues el criterio es consistente. Si el programa no es correcto, entonces tiene que existir un test T perteneciente a C tal que no sea exitoso. Suponiendo que pruebo con el test T1 y obtengo que es incorrecto, listo. Si pruebo con T2 y obtengo que es correcto, quiere decir que cualquier otro test tiene que dar que es correcto, lo cual es falso porque existe un test para el que no lo es por completitud. Por lo tanto, la afirmación es verdadera. La gracia está en que es imposible hallar un criterio completo y consistente.

> V o F. Si una unidad de software pasa un test suite que garantiza cobertura total de caminos, entonces la unidad de software no tiene fallas. Falso. Aunque un test suite all-path subsume a muchos otros criterios, el testing no garantiza la inexistencia de errores (dijkstra) sino que puede confirmar la existencia de fallas (aunque podria decir que no se encontraron errores, eso no significa que podrian existir). Ademas, la seleccion de casos no esta basada en el comportamiento funcional asi que esta mal guiada del principio.

> Para qué sirven los criterios de cobertura en testing?

> Explique cómo se vinculan los siguientes criterios de acuerdo a la relación 'subsume a': Todos-los-caminos, Todos-los- caminos-Def/Use, Todas-las-Defs, Todas-las-Decisiones, Todas-las-Sentencias.

> Caracterizar los subdominios del criterio de Statements.

> Explique la relación que existe entre los criterios de cobertura por sentencia y por condiciones.

> Qué relación de subsunción existe entre cobertura por condiciones y por ramas (branch).

> A qué se refiere Beizer (en el ámbito del Testing) con la paradoja del pesticida? Si las pruebas se repiten una y otra vez, con el tiempo el mismo conjunto de casos de prueba ya no encuentran nuevos errores. Todas las técnicas de prueba se dirigen a un conjunto diferente de bugs. Si los programadores responden a las pruebas y la información de los errores mediante la reducción o eliminación de tales errores, se deduce que como su software mejora, la eficacia de las pruebas anteriores se daña, es decir, las pruebas se desgastan y tendrán que aprender, crear y utilizar nuevas pruebas basadas en las nuevas técnicas para captar nuevos errores.

> Qué es un mutante y cómo se usa en testing? Mutation testing involves modifying a program in small ways.[1] Each mutated version is called a mutant and tests detect and reject mutants by causing the behavior of the original version to differ from the mutant. This is called killing the mutant. Test suites are measured by the percentage of mutants that they kill.