ex amenes

Ingeniera del Software Examen 13 septiembre 2006 2,15 horas

Sistema informtico de calificaciones

Un Departamento de la Escuela Universitaria de Informtica desea desarrollar un sistema informtico que le permita publicar en Internet las calificaciones de las asignaturas que imparte a partir de las siguientes especificaciones de usuario. Deber mantenerse una relacin de asignaturas impartidas por el departamento, as como de profesores que las imparten. De esta manera durante el proceso de conexin (login) se comprobar si el profesor puede o no acceder a determinadas asignaturas. Cada profesor debe disponer de un nombre de usuario, una contrasea, y su nombre completo, adems de la relacin de asignaturas que imparte, mientras de cada asignatura interesa conocer su nombre, que podra ser compartido entre varias asignaturas en funcin de si se imparte en el sistema ECTS o en el convencional. El proceso de publicacin de notas se divide en varios pasos. En primer lugar, a peticin de un profesor de la asignatura, la nueva aplicacin deber descargar la relacin de alumnos matriculados que deben aparecer en la convocatoria actual (que viene determinada por curso acadmico y mes). Este listado deber proporcionarlo el Sistema de Matrcula de la Escuela y su formato es el siguiente: NIF MATRCULA NOMBRE APELLIDO1 APELLIDO2 11111111F AZ0007 JUAN LOPEZ AGUIRRE 22222222H AV9999 MARTA GOMEZ GARCIA ......... ...... ..... ..... ....... Donde el NIF contiene 8 dgitos ms una letra, el nmero de matrcula se compone de dos caracteres y 4 dgitos, el nombre tiene una longitud mxima de 50 caracteres y cada uno de los apellidos hasta 100 caracteres. Tras la descarga se actualiza la base de datos, asignando dichos alumnos a la convocatoria actual de la asignatura deseada. Es importante conocer de qu convocatoria se trata. En este momento el profesor o profesores pueden comenzar a transcribir las notas, rellenando las columnas de un listado que aparecer en pantalla. A cada alumno le pueden corresponder hasta tres notas por convocatoria. A cada una de estas tres notas les corresponde una ponderacin, de forma que la suma de ponderaciones sea igual a 100 y la mxima calificacin total posible sea un 10. Si no se desea utilizar alguna de las tres notas posibles se ponderar como 0, si bien es obligatorio que al menos la primera de ellas sea utilizada en cada convocatoria. Las ponderaciones pueden ser diferentes para cada una de las convocatorias y debe mantenerse el histrico de las mismas. El sistema deber calcular la calificacin final y adems asignar la calificacin no numrica que corresponda sabiendo que:

Nota vaca NO PRESENTADO Nota < 5 SUSPENSO 5 Nota < 7 APTO 7 Nota < 9 NOTABLE 9 Nota


Sistema informtico de calificaciones

alumnos puedan consultarlas. Las calificaciones pueden modificarse en cualquier momento en el tiempo, incluso despus de haber sido publicadas. Los alumnos, por su parte, podrn consultar sus calificaciones una vez se publiquen. Para ello dispondrn de un certificado digital que garantice su identidad, y asegure que nadie puede ver las calificaciones de otros compaeros. El certificado digital contiene un identificador nico, una fecha de caducidad y otra de emisin, el NIF del interesado y otras informaciones que no resultan relevantes. Cuando un alumno entra en el sistema, ste recuperar el certificado digital, verificando que es vlido al contrastar la fecha de caducidad con la del sistema, y con la lista de revocacin de la Entidad Certificadora. Si resulta vlido, obtendr de dicho certificado el NIF y buscar en la base de datos, mostrando en pantalla las asignaturas y convocatorias del alumno en cuestin, de forma que pueda seleccionar una de las asignaturas y convocatorias y visualizar su calificacin. Adems se desea que el sistema de publicacin de notas permita obtener listados impresos de las calificaciones y estadsticas de aprobados, suspensos y no presentados de cada convocatoria. Se pide: 1) Casos de uso

a) Identificar todos los actores involucrados en el sistema de publicacin de calificaciones y definir los casos de uso y las relaciones entre los distintos elementos. (1.5 puntos)

b) Especificar el caso de uso extendido del proceso de visualizacin de calificaciones por parte de un alumno. (0.5 puntos)

2) Entidad Relacin

a) Definir el modelo de datos del sistema propuesto segn la notacin de Chen (2 puntos) b) Transformar el modelo de datos Chen a la notacin Martin (1 punto)

3) Tomando como punto de partida la informacin sobre el proceso de obtencin de la relacin de

alumnos matriculados en una asignatura, determinar justificadamente las particiones de equivalencia necesarias para realizar las pruebas de caja negra. Exponga al menos un ejemplo del conjunto de elementos de cada una de las particiones. (2 puntos)

Normas:

o Todas las hojas de examen debern llevar el nombre escrito a bolgrafo y el nmero de orden de la asignatura

o Cada ejercicio deber ser resuelto en hojas independientes. o Aunque un ejercicio no vaya a ser resuelto, deber entregarse una hoja en blanco

con el nombre. o Durante la primera media hora no se podr abandonar el examen.

Revisin examen 27 de septiembre de 2006

Solucin al ejercicio 3 de Ingeniera del Software. Convocatoria de septiembre 2006

Enunciado relacionado con el apartado: El proceso de publicacin de notas se divide en varios pasos. En primer lugar, a peticin de un profesor de la asignatura, la nueva aplicacin deber descargar la relacin de alumnos matriculados que deben aparecer en la convocatoria actual (que viene determinada por curso acadmico y mes). Este listado deber proporcionarlo el Sistema de Matrcula de la Escuela y su formato es el siguiente: NIF MATRCULA NOMBRE APELLIDO1 APELLIDO2 11111111F AZ0007 JUAN LOPEZ AGUIRRE 22222222H AV9999 MARTA GOMEZ GARCIA ......... ...... ..... ..... ....... Donde el NIF contiene 8 dgitos ms una letra, el nmero de matrcula se compone de dos caracteres y 4 dgitos, el nombre tiene una longitud mxima de 50 caracteres y cada uno de los apellidos hasta 100 caracteres. Se pide: 3) Tomando como punto de partida la informacin sobre el proceso de obtencin de la relacin de alumnos matriculados en una asignatura, determinar justificadamente las particiones de equivalencia necesarias para realizar las pruebas de caja negra. Exponga al menos un ejemplo del conjunto de elementos de cada una de las particiones. (2 puntos) Solucin: Las particiones de equivalencia representan un mtodo de prueba de Caja Negra que divide los campos de entrada de un programa en clases de datos a partir de los cuales se pueden derivar los casos de prueba. La particin equivalente se dirige a una definicin de casos de prueba que descubran clases de errores reduciendo el nmero total de casos de prueba que hay que desarrollar. Para el diseo de los casos de prueba hay que desarrollar dos pasos:

1. Identificar las clases de equivalencia 2. Identificar los casos de prueba

Una clase de equivalencia representa un conjunto de estados vlidos y no vlidos para las condiciones de entrada de un programa. Las clases de equivalencia se identifican examinando cada condicin de entrada y dividindola en dos o ms grupos. Se definien dos grupos de clases de equivalencia: vlidas y no vlidas. Las primeras representan entradas vlidas para el programa y las segundas representan valores de entrada errneos.

Condicin de entrada Clases de equivalencia vlidas Clases de equivalencia no vlidasNIF 1. 00000000A

Revisin examen 27 de septiembre de 2006

Solucin Problema 3 2 Examen de Ingeniera del Software. Septiembre 2006

Derivacin de los casos de prueba. Para generar los casos de prueba, se considerar la tcnica de anlisis de valores lmite. Esta tcnica hace que para determinadas clases de equivalencia se generen ms de un caso de prueba en el caso de los valores acotados por rangos, donde se evaluarn los lmites de los rangos. En el ejemplo del ejercicio, no hay ningn valor de este tipo, por lo que para cada clase de equivalencia slo hay que generar un nico caso de prueba. Los casos de prueba derivados se muestran en la siguiente tabla:

Id. caso

Clases de equivalencia NIF

Nmero Matrcula Nombre Apellido1 Apellido2 Resultado

1 1,4,7,9,11 00000000A AA0000 Agustin Yage Panadero Lnea correcta

2 2,4,7,9,11 9999999Z ZZ9999 Agustn Yage Panadero Error NIF con nmero errneo de dgitos

3 3,4,7,9,11 000000000A AA5555 Cadena de 50 caracteres

Cadena de 100 caracteres


Error NIF con nmero errneo de dgitos

4 1,5,7,9,11 12345678A ZZ999 Cadena de 50 caracteres



Formato incorrecto de Nmero de matrcula

5 1,6,7,9,11 87654321Z AA00000 Cadena de 50 caracteres



Formato incorrecto de Nmero de matrcula

6 1,5,8,9,11 11111111A AB1234 Cadena de 51 caracteres



Error nombre demasiado largo

7 1,5,7,10,11 22222222A ZY4321 Cadena de 50 caracteres

Cadena con 101 caracteres


Error apellido1 demasiado largo

8 1,5,7,9,12 33333333A AA1111 Cadena de 50 caracteres


Cadena con 101 caracteres

Error apellido2 demasiado largo

Ingeniera del Software 10 de diciembre de 2007 Examen 30 min. Apellidos Nombre

Nmero de Matrcula Nmero de orden 0000000000000 1. Desde el punto de vista de responsabilidad profesional del ingeniero de software, la confidencialidad,

a. Hay que supeditarla a las necesidades comerciales de la empresa si no existe un acuerdo de confidencialidad

b. Hay que supeditarla a las necesidades las necesidades financieras de la empresa siempre c. No debe ser supeditada a las necesidades financieras de la empresa d. Es funcin del software de control de acceso que tenga la empresa

2. Gestin de la configuracin (CM) es el proceso encargado de aplicar procedimientos tcnicos y administrativos a lo largo del ciclo de vida del software para identificar, definir y congelar elementos software de un sistema. a. Esta definicin suele ser cierta, salvo que se ponga especial nfasis en la generacin de cdigo b. Esta definicin no es cierta pues no contempla la generacin de cdigo c. Esta definicin es cierta, aunque CM tambin implica aspectos de gestin de los cambios en el

software d. Esta definicin es cierta, aunque no mencione que CM es casi exclusivamente aplicable durante

las pruebas de unidad 3. Los estudios de viabilidad

a. Se debe hacer un estudio de viabilidad slo si no queda mas remedio, o sea el cliente lo solicita b. Se debe hacer un estudio de viabilidad slo cuando el coste supere el umbral Boehm c. Se debe hacer un estudio de viabilidad slo cuando el coste est por debajo del umbral Boehm d. Se debe hacer un estudio de viabilidad como una de la etapas iniciales del ciclo de vida

4. En los proyectos es ms que conveniente establecer un plan de gestin de los requisitos a. Es cierto y con el objetivo de determinar cmo se gestiona el cambio de los requisitos y la

trazabilidad de los requisitos b. Es cierto y con el objetivo de determinar la funcionalidades del nuevo sistema de forma clara c. Es cierto y as lo define el principio de separacin de aspectos d. Es cierto pues es el documento donde tambin se deben definir los requisitos no funcionales

5. El grado de una relacin a. Se refiere al nmero de entidades distintas que intervienen en una relacin b. Se refiere al nmero de entidades que intervienen en una relacin c. Se refiere al nmero medio de entidades que intervienen en una relacin d. Se refiere al nmero de ocurrencias que intervienen en una relacin

6. La cardinalidad de una relacin a. Se refiere al nmero de ocurrencias de entidad que se pueden asociar a otra a travs de una

relacin b. Se refiere al nmero de entidades que se pueden asociar a otra a travs de una relacin c. Se refiere al nmero de atributos que se pueden asociar a otra a travs de una relacin d. En el modelo entidad-relacin tenemos cardinalidad mxima, mnima y media.

7. En el modelo entidad-relacin la dependencia de existencia define a. La existencia de una ocurrencia de entidad que depende de la existencia de otra b. La existencia de una ocurrencia de relacin que depende de la existencia de otra c. La existencia de un atributo que depende de la existencia de una entidad d. Las otras respuestas son falsas

8. Al analizar un sistema encontramos que el modelo expresa que un edificio tiene ventanas y puertas; para expresar en el modelo de clases de UML que las ventanas y puertas forman parte del edificio a. Podramos utilizar dos asociaciones: edificio tiene ventanas y edificio tiene puertas, pero no se

puede ser ms preciso b. Utilizaremos una relacin de identificacin: edificio se identifica por ventana y puerta c. No es posible modelarlo con el modelo de clases de UML d. Podramos utilizar dos asociaciones: edificio tiene ventanas y edificio tiene puertas; aunque

deberamos ser ms precisos y utilizar otro tipo de relacin


Nmero de Matrcula Nmero de orden 0000000000000 9. Los diagramas de secuencia de UML son un formalismo que nos permite establecer el comportamiento

del sistema a. Desde ese punto de vista son complementarios a los diagramas de clases, que expresan una

visin esttica b. Desde ese punto de vista son complementarios a los diagramas de eventos, que expresan una

visin esttica c. Desde ese punto de vista son complementarios a los diagramas de flujo, que expresan una

visin esttica d. Los diagramas de secuencia no complementan a los diagramas de clases, sino que son su

fundamento 10. Al realizar el diseo de un sistema partiendo de un modelo de clases podemos utilizar clases de

control y de entidad a. Eso se realiza por separar aspectos de control de la gestin de datos de forma que el diseo del

sistema final ser mejor b. Eso se realiza para seguir la escuela de diseo clsica pero no hay ventajas claras de separar

aspectos de control y de datos c. Eso se realiza para seguir la escuela de diseo clsica que indica que es mejor tener mdulos

pequeos que grandes d. Eso se realiza pues las clases de entidad se implementan con el modelo entidad-implementacin

de forma automtica 11. Las pruebas de integracin se ejecutan

a. Antes de las de unidad b. Al tiempo que la integracin c. Al terminar la integracin d. Al terminar las de caja blanca

12. Las pruebas de caja blanca pueden detectan fallos considerando la estructura del cdigo a. Slo se deben ejecutar si se va a entregar los fuentes al cliente b. Slo hay que ejecutarlas con software crtico c. No aportan informacin til, ya que la informacin til la aportan las pruebas de caja negra d. Las pruebas de caja blanca deberan estar descritas en el plan de pruebas previamente a su

ejecucin 13. Las pruebas de validacin

a. Se ejecutan cuando el sistema est terminado y cercano a la entrega al cliente b. Se ejecutan habitualmente entre las de unidad y las de integracin c. Son el paso previo a las pruebas de integracin en metodologas giles d. Slo se ejecutan en sistemas de software crtico

14. La trazabilidad entre tems del proceso de desarrollo a. Es una funcionalidad de las antiguas herramientas que se mantiene por compatibilidad hacia

atrs b. Es una funcionalidad de las antiguas herramientas que se mantiene por inters comercial c. Permite valorar, por ejemplo, el impacto de un cambio en un requisito, cuando el cdigo ya est

avanzado d. Slo los nuevos modelos de trazabilidad Web2.0 permiten navegar adecuadamente entre tems

15. Las pruebas de resistencia a. Nos permitirn saber si en situaciones de sobrecarga el sistema software se comporta

adecuadamente b. Nos permitirn saber si en situaciones de ataque el sistema software se comporta

adecuadamente c. Nos permitirn saber si en situaciones de fallo de tensin elctrica el sistema software se

comporta adecuadamente d. Nos permitirn saber si en situaciones de error generalizado el sistema software se comporta

adecuadamente

Ingeniera del Software Examen 10 diciembre 2007 2,15 horas

Sistema de gestin de reparaciones de

electrodomsticos

Una empresa de reparaciones de electrodomsticos desea informatizar parte de la gestin de su negocio. En particular la gestin del stock de piezas de recambio que son empleadas para sustituir, en las reparaciones, piezas defectuosas o deterioradas. A da de hoy el stock se controla mediante un estadillo semanal en el que se listan por cada marca de electrodomstico sus modelos y para cada uno de ellos la cantidad que existe en stock de sus piezas, ordenadas alfabticamente. El nuevo sistema informtico deber sustituir este estadillo, permitiendo conocer el stock de las piezas bien por marca, modelo o nombre de pieza. Adems, aprovechando la automatizacin, se aadir la informacin de la informacin de contacto para las marcas: direccin de la central, incluyendo pas y ciudad, el telfono y, en su caso, el nombre del importador y su telfono. Debe tenerse en cuenta que si bien un modelo (del que ahora se incluir tambin una descripcin y un precio) slo puede ser de una marca es posible que distintas piezas tengan el mismo nombre para distintas marcas y modelos. De las piezas se incluir informacin referente a su descripcin, dimensiones y precio. Adems para cada pieza se consignar la cantidad mnima de stock admitida. El nuevo sistema deber, asimismo, conservando en un histrico, proporcionar informacin sobre el consumo de cada pieza en los periodos temporales que determine la seccin de compras para facilitar la reposicin de las mismas, y deber producir una alerta en forma de mensaje cuando el stock de una pieza est por debajo de la cantidad mnima admitida. Estas alertas se producirn slo cuando la aplicacin empiece a ser utilizada por un usuario del departamento de compras. En ese momento, el sistema registrar los cambios en el stock realizados por este tipo de usuarios, es decir, se incluir en el histrico quien modific la cantidad almacenada de cada pieza en qu fecha. Para ello el sistema aparte de conservar los nombres de los usuarios y sus palabras clave deber conocer el departamento a que pertenece un usuario, que siempre ser nico y no podrn existir usuarios que no pertenezcan a un departamento. De los departamentos se almacenar tambin una descripcin, fecha de inicio de su actividad y nmero de usuarios asignados. Se pide:

1. Realizar un diagrama de Entidad/Relacin del sistema en notacin de P.P.Chen y su transformacin en notacin Martin. (3 puntos)

2. Realizar el diagrama de clases de diseo (2 puntos) y el diagrama de secuencia de diseo correspondiente a la entrada en la aplicacin en el escenario de xito en el que se produzca una alerta de stock (2 puntos)

Normas:



con el nombre.

Las soluciones siguientes tienen sentido dentro del contexto de la asignatura y considerando la materia impartida y su enfoque tcnico

modifica

MODELO CodM nombre descripcin precio

tiene (1,N)

MARCA CodM nombre pas ciudad direccin importador tel importador

(1,1) tiene (1,N) (1,N)

STOCK fecha cantidad

(1,N)

(0,N) (1,1)DEPARTAMENTO CodD nombre fecha

tiene (0,N) USUARIO CodU

nombre clave

(1,1)

Tiene

PIEZA CodP nombre descripcin dimensiones precio cantidad_min

(1,1)

Marca

getCodM() : int

setCodM(codM : int) : void

codM : int

nombre : String

pais : String

ciudad : String

direccion : String

importador : String

telImportador : String

Pieza

codP : int

nombre : String

descripcion : String

dimensiones : String

precio : float

cantidadMin : int

Departamento

codD : int

nombre : String

fecha : Date

Modelo

nombre : String

descripcion : String

precio : float

codM : int

Stock

fecha : Date

cantidad : int

Tiene

Usuario

codU : int

nombre : String

clave : String

1..*

1

1..*

1

1..*

1

1..*

1

0..*

1

10..*

GestorMarcas

insertar() : void

modificar() : void

borrar() : void

buscar() : List

GestorModelos

GestorPiezasPorModelo

GestorPiezas

GestorStock

GestorUsuarios

GestorDepartamentos

TiendaReparaciones

login() : void

consultaConsumoPiezas() : List

modificarStockPieza() : void

10..*

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

1

1

1

1

1 1

1

1

1

1

1

1

1

1

InterfazMarcas

mostrar() : void

ocultar() : void

capturarDatos() : void

1 1

1

1

InterfazModelos

InterfazPiezas

InterfazStock

InterfazUsuarios

InterfazDepartamentos

1 1

1 1

1 1

1 1

1

1

1 1

1 1

1

1

1

1

1

1

1

1

Todas las clases de entidad han de disponer del correspondiente getter y setter para cada uno de sus atributos segn el patrn mostrado en Marca.

Todos los atributos han de ser privados, y en la solucion propuesta todos los mtodos son pblicos a pesar de que la herramienta utilizada no muestre los simbolos + -.

Los gestores siguen el modelo mostrado en GestorMarcas y los interfaces el mostrado en InterfazMarcas.

LaTiendaReparaciones requerira adems mtodos para el mantenimiento de informacin (crear, modificar, borrar y buscar Marca, Modelo, Pieza, Stock, Usuario y Departamento.

InterfazLogin

1

1

1 1

1 1

GestorUsuarios: Usuario:TiendaReparaciones: InterfazLogin:UsuarioDptoCompras: GestorStock: Stock:

login()

mostrar()

capturarDatos()

buscar(login, password)

getNombre()

getClave()

buscar(stockBajoMinimos)

getFecha()

Pieza:

getCantidad()

getPieza()

getCantidadMin()

mostrar(listaPiezasAlerta)

Ingeniera del Software 8 de junio de 2007 Examen 30 min. Apellidos Nombre

Nmero de Matrcula Nmero de orden REF ABC3JK56 1. En atencin a sus obligaciones ticas el ingeniero de software debe considerar confidencial

cualquier informacin relativa a sus clientes a) Es conveniente pero cuando se trata de obtener un nuevo contrato todo vale b) En algunos casos puede ser conveniente pero no necesariamente como regla general c) En cualquier caso d) Slo en el caso de que se haya firmado un acuerdo de confidencialidad

2. Cuando un sistema software se modifica tras su entrega al cliente es normal que

a) Sea fcil que las modificaciones nunca sirvan para mejorar la calidad del cdigo. b) Sea fcil que las modificaciones nunca sirvan para empeorar la calidad del cdigo, ms

que nada porque dado que estamos sumidos en la crisis del software la calidad del cdigo ser un desastre en cualquier caso

c) Sea fcil que las modificaciones no empeoren la calidad del cdigo salvo que los ingenieros de software sean algo torpes

d) Sea fcil que las modificaciones vayan empeorando la calidad del cdigo salvo que se establezcan acciones correctivas concretas

3. Referente a la arquitectura de un sistema software sera bueno imponer que la relacin USA

entre mdulos sea jerrquica a) Siempre que sea posible pues la existencia de ciclos puede implicar un alto

acoplamiento b) A veces no, pero lo ptimo desde el punto de vista de complejidad es que el rbol de

mdulos sea un grafo no dirigido cclico (GnDC) c) Esto no es cierto pues la potencia de la recursividad compensa con creces la

complejidad derivada de los ciclos d) A veces s, pero lo ptimo desde el punto de vista de complejidad es que el rbol de

mdulos sea un grafo dirigido cclico (GDC) 4. Los mdulos conductores permiten integrar un sistema con una estrategia top-down

a) Estrictamente hablando esta afirmacin es cierta cuando los conductores se combinan con los llamados mdulos cobradores

b) Estrictamente hablando esta afirmacin es cierta cuando los conductores se combinan con los llamados mdulos conducidos

c) Estrictamente hablando, esta afirmacin no es cierta d) Estrictamente hablando, esta afirmacin es cierta

5. Tenemos un mtodo M1 asociada a la clase C1. Un anlisis del mtodo nos depara un

diseo alternativo. En este nuevo diseo M1 estara integrado por tres componentes nuevos: M11, M12 y M13. Cada nuevo componente implementa una funcin concreta. a) Podemos estar casi seguros de que el nuevo diseo tiene una cohesin ms alta b) No tenemos informacin suficiente para estimar cualitativamente la cohesin c) Podemos estar casi seguros de que el nuevo diseo tiene una cohesin ms baja d) No tenemos ninguna razn para pensar que el nuevo diseo tiene una cohesin ms alta

6. Tenemos un mtodo M1 asociada a la clase C1. Un anlisis del mtodo nos depara que un

diseo alternativo. En este nuevo diseo M1 estara integrado por tres componentes nuevos: M11, M12 y M13. Cada nuevo componente implementa una funcin concreta. a) Podemos estar casi seguros de que el nuevo diseo tiene un acoplamiento ms alto b) No tenemos informacin suficiente para estimar cualitativamente el acoplamiento c) Podemos estar casi seguros de que el nuevo diseo tiene un acoplamiento ms bajo d) No tenemos ninguna razn para pensar que el nuevo diseo tiene un acoplamiento ms

alto


Nmero de Matrcula Nmero de orden REF ABC3JK56 7. En un proyecto se crea una baseline con un documento de requisitos, y una serie de clases.

Mientras se estn implementando los mtodos se cambia la especificacin de la cabecera del mtodo Met1 debido a una versin ampliada de los requisitos que dar lugar a la segunda generacin del producto. a) Los ingenieros de software deben, en cuanto tengan noticia de la existencia de la

segunda especificacin de Met1, empezar a construir dos versiones del cdigo, una que deber funcionar con la especificacin antigua, y otra con la nueva de Met1 para ganar tiempo. Deben informar de ello al responsable de gestin de la configuracin, aunque ste an no haya creado la baseline de la segunda generacin del producto.

b) Los ingenieros de software deben presentar una queja al responsable de gestin de la configuracin en cuanto tengan noticia de la existencia de la segunda especificacin de Met1, incluso sin esperar a que se cree la baseline; es importante agilizar el desarrollo lo ms posible.

c) Los ingenieros de software que estn construyendo el cdigo deberan incluir la nueva especificacin de Met1 en cuanto tuvieran noticias de la existencia de la segunda especificacin de Met1 pues, si no, debern modificar sus fuentes antes o despus.

d) Los ingenieros de software que estn construyendo el cdigo no tienen por qu darse por enterados sobre la nueva especificacin de Met1 hasta que tengan informacin oficial. En cualquier caso no ser aplicable en la versin actual del cdigo.

8. Un parmetro de entrada, "dia_de_reunion", de una funcin es de tipo "dia de la semana";

los valores vlidos son lunes y martes. Desde el punto de vista de pruebas, y considerando las particiones equivalentes, el siguiente de caso de prueba es el adecuado: a) Juego 1: dia_de_reunion := martes; juego 2: dia_de_reunion := martes b) Juego 1: dia_de_reunion := mircoles; juego 2: dia_de_reunion := jueves c) Juego 1: dia_de_reunion := lunes; juego 2:dia_de_reunion := martes d) Juego 1: dia_de_reunion := lunes; juego 2:dia_de_reunion := mircoles

9. Un componente A de un sistema tiene un fan-in de 20 y un fan-out de 30; otro, B, tiene un

fan-in de 3 y fan-out de 4. Con esa informacin exclusivamente podemos afirmar lo siguiente sin equivocarnos: a) B tiene una cohesin mayor que A b) A tiene un cdigo con mayor nivel de reutilizacin que B c) Para un componente dado cualquiera, fan-in y fan-out estn correlados d) A est ms acoplado con el resto del sistema que B

10. Las caractersticas de los usuarios finales del sistema

a) Afectan a las conclusiones obtenidas en el anlisis de un producto, ya que lo importante es que el producto funcione al final. El perfil de los usuarios, sin embargo, no es relevante a la hora de disear la formacin que recibirn los usuarios

b) Afectan a las conclusiones obtenidas en el anlisis de un producto, aunque tambin es importante que funcione el producto al final. El perfil de los usuarios tambin es relevante a la hora de disear la formacin que recibirn los usuarios

c) No tienen por qu afectar a las conclusiones obtenidas en el anlisis y el diseo de un producto, ya que lo importante es que el producto funcione al final. El perfil de los usuarios, sin embargo, s es relevante a la hora de disear la formacin que recibirn los usuarios

d) No tienen por qu afectar a las conclusiones obtenidas en el anlisis de un producto, ya que lo importante es que el producto funcione al final. El perfil de los usuarios, sin embargo, s es relevante a la hora de disear la formacin que recibirn los usuarios


Nmero de Matrcula Nmero de orden REF ABC3JK56 11. A la hora de disear una sistema de informacin para una empresa se llega a la conclusin de que habr un nodo en Madrid y otro en Pars. La velocidad de transmisin para la conexin entre nodos es bsica dado el gran volumen de informacin que se debe intercambiar entre los dos nodos. Tras negociar con las compaas telefnicas sta puede ser 1 GB/s, pues 10 GB/s exceda en precio

a) 1 GB/s es un requisito de rendimiento que ser relevante a la hora de codificar la aplicacin

b) 1 GB/s es un restriccin de diseo que ser relevante a la hora de codificar la aplicacin c) 1 GB/s es un restriccin de diseo que empezar a ser relevante a la hora de codificar la

aplicacin, nunca antes, por cierto d) 1 GB/s es un requisito de rendimiento que empezar a ser relevante a la hora de

codificar la aplicacin, nunca antes, por cierto 12. Los requisitos de mantenimiento deben especificar cmo se debe adaptar el

producto a los cambios necesarios una vez que ya est en funcionamiento. a) Los requisitos de mantenimiento hay que tenerlos en cuenta a partir de que se comience

la implementacin b) Los requisitos de mantenimiento podran afectar al diseo del producto c) Los requisitos de mantenimiento empiezan a ser importantes una vez que el producto ha

sido entregado al usuario d) Los requisitos de mantenimiento, importantes, importantes no lo son nunca del todo.

Los importantes de verdad son los funcionales.

13. En el modelo de desarrollo en espiral de Bohem a) Hay que hacer anlisis de riesgos al comenzar el desarrollo del proyecto y justo cuando

se va a comenzar la implementacin del producto b) El anlisis de riesgos es recomendable pero opcional c) Se debe realizar un anlisis de riesgos cada vez que se va a comenzar un nuevo ciclo d) Se debe realizar un anlisis de riesgos cada vez que se considere necesario; podramos

decir que llevara asociado un mecanismo para levantar excepciones; cuando una excepcin se levanta hay que hacer el anlisis de riesgos

14. Los diagramas de casos de uso estn orientados

a) A la estructura b) A la funcin c) Al objeto; es parte de UML d) A la funcin o al objeto; depende de si son diagramas de casos de uso bsicos o

extendidos

15. Tenemos dos versiones distintas, A y B, de un mtodo que implementa una funcin concreta y adecuadamente especificada. Las dos versiones han sido verificadas, son correctas y funcionalmente iguales. Sin embargo la implementacin A tiene una complejidad ciclomtica de 20 y B de 60. Podemos afirmar que:

a) La cohesin de B es mayor que la de A, al tiempo que B es ms compleja que A b) No tenemos informacin para comparar la cohesin de las dos versiones c) La cohesin de A es mayor que la de B al tiempo que B es ms compleja que A d) La cohesin de las dos versiones es la misma, aunque B es ms compleja que A

Puntuacin: Cada respuesta correcta suma 0.2 puntos. Cada respuesta contestada de forma incorrecta descuenta 0,09 puntos


Nmero de Matrcula Nmero de orden REF ABC3JK56

a a b b c c d

1

9

d a a b b c c d

2

10

d a a b b c c d

3

11

d a a b b c c d

4

12

d a a b b c c d

5

13

d a a b b c c d

6

14

d a a b b c c d

7

15

d a a b b c c d

8

d

NO FORMA PARTE DE LA SOLUCION; SIMPLEMENTE ACLARA

Cliente

Reserva devehculo bsica

Cliente

Reserva vehculo -usuario registrado

Cliente

Reserva vehculo -usuario no registrado

Cliente

registro bsico(datos)

1

*


extends


extends


include

uses

1 *

1*

1

*

Cliente

registro deusuarios1

*


include

uses


Sistema de gestin de alquileres de coches

Una empresa de alquiler de coches prepara un sistema de reserva web de coches. Este sistema se basa en que los usuarios pueden reservar un coche en una ciudad concreta indicando la ciudad en que devolvern el coche. Lgicamente tambin es necesario saber el da de comienzo de alquiler y el que retornarn el coche y la hora. La empresa oferta perfiles de coches y para perfil tiene coches de un modelo y marca concretos. Los clientes quedan identificados por su nombre, DNI, domicilio y telfono. El sistema slo lo pide para usuarios no registrados. La forma de acceder a la aplicacin, inicialmente, es diferente para usuarios registrados y no registrados. Los clientes pueden elegir la que ms les convenga. Los registrados entran por medio de un log-in y una palabra de acceso. Puede ocurrir que para un perfil de vehiculo no queden disponibles unidades. En ese caso el sistema, bien decide ofertar modelos de nivel superior o informar que no quedan unidades disponibles. Cuando existen unidades el cliente debe elegir el modelo, aceptar el alquiler, y cuando lo hace se le ofrecen las posibilidades de seguro; el SOV debe contratarlo siempre y luego tiene una serie de opciones: terceros, todo riesgo, etc. Cada opcin tiene una tarifa vigente en todo momento. Se almacena el coste inicial del alquiler y el coste real cuando devuelve el coche. El cliente debe aceptar tambin las opciones de seguro elegidas y cuando hace esto la reserva queda en firme. Al cliente se le realiza un cargo con el coste inicialmente previsto contra su tarjeta de crdito, que debe aportar caso de que el sistema no la tenga (el cliente puede cambiar su nmero de tarjeta en cualquier momento). Finalmente, tras volver a confirmar el alquiler, el sistema terminar la transaccin. Se pide:

1. Identificar los casos de uso, realizar el diagrama de los casos de uso en formato conciso y extendido. Indicar cules se consideran primarios y cules secundarios u opcionales (3 puntos).

2. Modelar la secuencia de anlisis correspondiente a la reserva de un vehculo para el perfil del vehculo econmico, incluyendo el diagrama de clases (4 puntos).

Normas:



con el nombre.

NO FORMA PARTE DE LA SOLUCION; SIMPLEMENTE ACLARA

Cliente


Cliente

Reserva vehculo -usuario registrado

Cliente

Reserva vehculo -usuario no registrado

Cliente


1

*


extends


extends


include

uses

1 *

1*

1

*

Cliente

registro deusuarios1

*


include

uses

SOLUCION EJERCICIO 1

Nombre Reserva vehculo bsica Actores Cliente Tipo Secundario Precondiciones Curso tpico de eventos Cliente Sistema 1. Rellenar de ciudad origen y destino 2. Validar

origen y destino

3. Rellenar dia inicial y final y horas 4. Validar dias

y horas

5. Rellenar perfil 6. validar perfil 7. comprobar

disponiblidad

8. ofrecer vehiculo

9. confirmar vehiculo 10. asignar

vehiculo

11. contratar SOV 12. ofertar

posibilidades de seguro voluntario

13 contratar voluntario 14 comprobar

opciones elegidas

15 generar precio alquiler y realizar cargo

16 dar tarjeta 17 comprobar

tarjeta

18 confirmar alquiler 19 Cerrar

transaccin

Nombre Registro bsico (datos) Actores Cliente Tipo Secundario Precondiciones Curso tpico de eventos Cliente Sistema 1. Rellenar nombre 2. Validar

nombre

3. Rellenar domicilio 4. Validar

domicilio

5. Rellenar DNI 6. validar DNI 7. Rellenar tarjeta de crdito 8 validar tarjeta

de crdito

Nombre Reserva vehculo usuario no registrado Actores Cliente Tipo primario Precondiciones Usuario previamente registrado Curso tpico de eventos Cliente Sistema Pasos 1-15 de caso de uso Reserva bsica

Pasos 1.-7 de caso de uso Registro bsico (datos) Passos 18-19 de caso de uso Reserva bsica

Nombre Reserva vehculo usuario registrado Actores Cliente Tipo primario Precondiciones Curso tpico de eventos Cliente Sistema 1. Dar cdigo de usuario y palabra de paso 2. comprobar usuario y palabra de

paso

Pasos 1-15 de caso de uso Reserva bsica

Pasos 16-17 (si el cliente desea cambiar la tarjeta almacenada) Pasos 18-19 de caso de uso Reserva bsica

Ciudad

nombre : String

Cliente

nombre : Stringdni : Stringdomicilio : Stringtelefono : Stringlogin : Stringpassword : Stringtarjeta : String

Vehiculo

marca : Stringmodelo : Stringmatricula : String

PerfilVehiculo

tarifa : floatdescripcion : String

float getTarifa()void setTarifa(tarifa : String)

1..10..*

Alquiler

fechaInicio : DatefechaFinalizacion : DatecosteFinal : floatcosteInicial : floattarjeta : String

1..1

1..*

1..1

0..*

1..1

0..*

1..10..*

OpcionSeguro


1..1

0..*

-recogida-entrega

1..1

0..*

1..1

1..*

1..1

0..* 1..1

0..*

1..10..*

1..10..*

get y set para todos los atributos de todas las clases con este mismo estereotipo

File: D:\Prjs\Docencia\IS\ExamenSep2007\SolucionEj2.mdl 18:03:31 jueves, 20 de septiembre de 2007 Class Diagram: Logical View / Main Page 1

jkjkCuadro de textoEJERCICIO 2

: Cliente : AlquilerCliente : Cliente

: PerfilVehiculo : Vehiculo : Ciudad : OpcionSeguro

getDescripcion()

getTarifa()

getFechaInicio()

getFechaFinalizacion()

getVehiculo()

getPerfil()

getMarca()

getModelo()

getDescripcion()

getTarifa()

Alquiler()

setNombre()

setDni()

setDomicilio()

setTelefono()

setTarjetaPreferida()

setCliente()

setFechaInicio()

setFechaFinalizacion()

setCosteInicial()

getNombre()

setEntrega()

setRecogida()

Secuencia de anlisis para reserva de vehculos por usuarios no registrados.La solucin, de haber seleccionado el caso de usuarios registrados, difiere en lo siguiente:

La secuencia comienza buscando en Cliente con getLogin() y getPassword().

No es necesario crear un Cliente con Cliente() ni cumplimentar sus datos, pero si crear el Alquiler y permitir modificar tarjeta preferida y tarjeta.

setTarjeta()

File: D:\Prjs\Docencia\IS\ExamenSep2007\SolucionEj2.mdl 18:03:31 jueves, 20 de septiembre de 2007 Sequence Diagram: Logical View / ReservaVehiculoEconomico Page 2

Ciudad

nombre : String

Cliente

nombre : Stringdni : Stringdomicilio : Stringtelefono : Stringlogin : Stringpassword : Stringtarjeta : String

Vehiculo

marca : Stringmodelo : Stringmatricula : String

PerfilVehiculo


float getTarifa()void setTarifa(tarifa : String)

1..10..*

Alquiler

fechaInicio : DatefechaFinalizacion : DatecosteFinal : floatcosteInicial : floattarjeta : String

1..1

1..*

1..1

0..*

1..1

0..*

1..10..*

OpcionSeguro


1..1

0..*

-recogida-entrega

1..1

0..*

1..1

1..*

1..1

0..* 1..1

0..*

1..10..*

1..10..*

get y set para todos los atributos de todas las clases con este mismo estereotipo

File: D:\Prjs\Docencia\IS\ExamenSep2007\SolucionEj2.mdl 18:03:31 jueves, 20 de septiembre de 2007 Class Diagram: Logical View / Main Page 1

: Cliente : AlquilerCliente : Cliente

: PerfilVehiculo : Vehiculo : Ciudad : OpcionSeguro

getDescripcion()

getTarifa()

getFechaInicio()

getFechaFinalizacion()

getVehiculo()

getPerfil()

getMarca()

getModelo()

getDescripcion()

getTarifa()

Alquiler()

setNombre()

setDni()

setDomicilio()

setTelefono()

setTarjetaPreferida()

setCliente()

setFechaInicio()

setFechaFinalizacion()

setCosteInicial()

getNombre()

setEntrega()

setRecogida()

Secuencia de anlisis para reserva de vehculos por usuarios no registrados.La solucin, de haber seleccionado el caso de usuarios registrados, difiere en lo siguiente:

La secuencia comienza buscando en Cliente con getLogin() y getPassword().

No es necesario crear un Cliente con Cliente() ni cumplimentar sus datos, pero si crear el Alquiler y permitir modificar tarjeta preferida y tarjeta.

setTarjeta()

File: D:\Prjs\Docencia\IS\ExamenSep2007\SolucionEj2.mdl 18:03:31 jueves, 20 de septiembre de 2007 Sequence Diagram: Logical View / ReservaVehiculoEconomico Page 2

Ingeniera del Software 13 de septiembre de 2007 Examen 30 min. Apellidos Nombre

Nmero de Matrcula Nmero de orden 0000000000000 1. Los aspectos ticos, siendo aspectos importantes en la profesin del ingeniero de software,

a) Hay que supeditarlos a las necesidades comerciales de la empresa b) Hay que supeditarlos a las necesidades las necesidades financieras de la empresa: si no se factura la empresa muere c) No deben ser supeditados a las necesidades financieras de la empresa d) Exclusivamente, hay que supeditarlos a las necesidades estructurales de la empresa

2. Si medimos el nmero de errores del cdigo, ste no suele disminuir conforme se va modificando tras ser enviado a produccin a) Suele ser cierto pues, salvo que se ponga especial nfasis en evitarlo, la calidad del cdigo se va degradando conforme se le

modifica durante su mantenimiento b) Al mantener el cdigo lo normal es que mejore la calidad siempre. En esto se diferencia del hardware c) Al mantener el cdigo lo normal es que mejore la calidad siempre. En esto se parece al hardware d) Al mantener el cdigo lo normal es que mejore la calidad siempre, mas cuando se ha desarrollado con lenguajes avanzadosa) 3.

3. Si numeramos los mdulos de uno en uno empezando por el mdulo principal de un sistema (mdulo 1), la integracin top-down a) Permite probar los mdulos impares nicamente b) Permite probar los mdulos pares nicamente c) Permite probar tantos los mdulos impares como los pares d) A priori no podemos decir qu mdulos se podrn probar pues estamos hablando de una estrategia de integracin

4. La integracin bottom-up es una alternativa a la top-down a la hora de integrar sistemas a) Bottom-up simplemente es una alternativa en los casos de sistemas con muchos componentes b) Bottom-up simplemente es una alternativa en los casos de sistemas con pocos componentes c) Bottom-up simplemente es una alternativa al otro y se aplicar uno u otro dependiendo de un estudio a realizar en el plan

de integracin d) Siempre se aplica top-down salvo que se ignore la tcnica para construir mdulos conductores

5. La medida de la cohesin nos indica si un mdulo hace una o varias funciones a) La cohesin alta de un mdulo nos indica que un mdulo hace muchas funciones y eso quiere decir que se reutilizar

mucho lo que es positivo b) La cohesin alta de un mdulo nos indica que un mdulo hace una funcin concreta y puede ocurrir que ese mdulo se

reutilice mucho lo que es positivo c) La cohesin alta de un mdulo nos indica que un mdulo hace muchas funciones lo que es especialmente positivo en el

caso de estn relacionadas (la salida de una es la entrada de la siguiente, por ejemplo) d) La cohesin baja de un mdulo nos indica que un mdulo hace muchas funciones lo que es especialmente positivo en el

caso de estn relacionadas (la salida de una es la entrada de la siguiente, por ejemplo) 6. La gestin de la configuracin es necesaria y cuesta implementarla adecuadamente en un proyecto.

a) Los mtodos giles han dado por terminado el auge de la gestin de la configuracin dado el coste que tiene b) Los mtodos giles la utilizan por ser til y necesaria, aunque mal montada puede ser excesivamente burocrtica c) El coste de su implementacin procede de que los proyectos se organizan mal, y si estn bien organizados la hacen

innecesaria d) El coste de su implementacin es tan alto que muchas veces es preferible no implementarla en un proyecto y a cambio

tener "una o dos noches difciles de trabajo" 7. El nmero de caminos independientes nos aporta informacin del nmero de pruebas que como mnimo tenemos

que definir para asegurarnos que al menos, una vez, se han ejecutado todas las sentencias de un mdulo a) La anterior afirmacin es cierta nicamente para mdulos con cdigo realizado con programacin estructurada b) La anterior afirmacin es cierta nicamente para mdulos con cdigo no estructurado c) La anterior afirmacin es cierta para mdulos con cdigo estructurado y no estructurado d) La anterior afirmacin es falsa

8. Dados dos mdulos A y B, tenemos que A USA B; la entrada de B es una variable tipo fecha, que le pasa A cuando le invoca. Una segunda versin de B tiene como entrada una variable tipo fecha y otra tipo coste, que igualmente le pasa A. Considerando el acoplamiento exclusivamente: a) El diseo de la primera versin es mejor b) El diseo de la segunda versin es mejor c) No tenemos informacin para juzgar el diseo con la informacin aportada d) El diseo de la primera versin no es ni mejor ni peor que el de la segunda

9. Conocer el Fan-in y fan-out de cada mdulo y la media para un sistema software nos permite: a) Razonar sobre la bondad del diseo de un sistema


Nmero de Matrcula Nmero de orden 0000000000000

b) Conocer exactamente el acoplamiento de un sistema c) Conocer exactamente la cohesin de un sistema d) Conocer exactamente tanto la cohesin como el acoplamiento de un sistema

10. Las caractersticas de los usuarios finales del sistema a) Son una entrada importante para el diseo lgico de la arquitectura b) Son una entrada importante a los requisitos c) Son una entrada importante para el diseo fsico de la arquitectura d) Son una entrada importante para la preparacin de las pruebas de integracin

11. Pensando en trminos de requisitos, los casos de uso de UML nos permiten a) Simular el comportamiento de la aplicacin b) Especificar lo que el usuario necesitara de la aplicacin en un lenguaje de especificacin que permite comprobar la

completitud de los dilogos usuario/sistema c) Especificar lo que el usuario necesitara de la aplicacin en un lenguaje ejecutable (include y extend) d) Describir los requisitos funcionales por medio de modelar la interaccin del usuario con la aplicacin

12. Los requisitos de mantenimiento deben especificar cmo se debe adaptar el producto a los cambios necesarios una vez que ya est en funcionamiento. a) De acuerdo con ISO/IEC 12207 slo seran necesarios en aplicaciones que superen un ao como posible vida b) De acuerdo con ISO/IEC 12207 slo seran necesarios en aplicaciones que superen cinco aos como posible vida c) De acuerdo con ISO/IEC 12207 slo seran necesarios en aplicaciones de software que realmente se piense que van a

requerir mantenimiento d) ISO/IEC 12207 no entra a describir los requisitos de mantenimiento, sino los procesos del ciclo de vida

13. En los modelos de desarrollo giles a) Se da ms importancia relativa a las pruebas que en modelos ms clsicos como el ciclo en V b) Se da menos importancia relativa a las pruebas que en modelos ms clsicos como el ciclo en V c) Se da igual importancia relativa a las pruebas que en modelos ms clsicos como el ciclo en V d) No es posible decir a priori si se da igual importancia relativa o no a las pruebas que en modelos ms clsicos como el ciclo

en V 14. Los diagramas de secuencia

a) Describen el comportamiento de la aplicacin b) Describen el comportamiento de cada clase del diagrama de clases c) Describen el comportamiento de cada mtodo de forma individual del diagrama de clases d) Especifican un modelo de datos complementario al modelo de clases

15. Tenemos dos versiones distintas, A y B, de un mtodo que implementa una funcin concreta y adecuadamente especificada. Las dos versiones han sido verificadas, son correctas y funcionalmente iguales. Sin embargo la implementacin A tiene una complejidad ciclomtica de 20 y B de 60. Podemos afirmar que:

a) La cohesin de A es mayor que la de B al tiempo que B es ms compleja que A b) La cohesin de las dos versiones es la misma, aunque B es ms compleja que A c) La cohesin de B es mayor que la de A, al tiempo que B es ms compleja que A d) No tenemos informacin para comparar la cohesin de las dos versiones

Puntuacin: Cada respuesta correcta suma 0.2 puntos. Cada respuesta contestada de forma incorrecta descuenta 0,1 puntos Durante la primera media hora no se podr abandonar el examen.



a a b b c c d

1

9

d a a b b c c d

2

10

d a a b b c c d

3

11

d a a b b c c d

4

12

d a a b b c c d

5

13

d a a b b c c d

6

14

d a a b b c c d

7

15

d a a b b c c d

8

d

IngenieradelSoftware 9dediciembrede2008 Examen 2horasApellidos Nombre

NmerodeMatrcula Nmerodeorden

Ejercicio

Conmotivode lasfiestasnavideas,enunapequeapoblacinseorganizaelrepartode losregalosde losReyesMagosalosnios.DesdeprincipiosdeNoviembre,enloscomerciosdelpuebloseponenunosbotesdonde la gente deposita dinero para la compra de los regalos. Con estos fondos, los organizadores delrepartocompran lo juguetesquesedistribuirna losnios.Paraevitarquenohayaniossin juguetesnifamiliasquequedensinvisitar,sehacenecesariaunabasededatosquecontroleelreparto.

En primer lugar, existirn unos voluntarios que harn las veces de ReyesMagos, repartidos en distintosgruposdeReyes.De losvoluntarios sealmacenar suNIF,nombre,apellidosyedad.Estosvoluntarios seorganizanengrupos.Delosgrupossealmacenaruncdigodegrupoylazonadelpuebloquevanacubrir.CadagrupotendrunnicovoluntarioqueactecomoMelchor,unnicovoluntarioqueactecomoGasparyunnicovoluntarioqueactecomoBaltasar.Cadavoluntarioslopodrestarenungrupo.

Cada grupo visita una serie de familias.De las familias se almacenar un cdigo, apellido del cabeza defamilia, ladirecciny lahoraprevistadevisita.Ademssedebedejarconstanciadesi lafamiliayahasidovisitadaono.Porsupuesto,aunafamiliaslolavisitaungrupodeReyes.Lasfamiliasaservisitadastienenunosnios.De losniossealmacenaruncdigodenio,elnombrey laedad.Unnioslopodrestarregistradoenunafamilia.

EsrepartoderegalosseplanificardemaneraquecadaniorecibirunsolojugueteporpartedelosReyes.De los juguetes sealmacenaruncdigode juguete,nombre,descripcin,edad recomendada (puede serparatodaslasedades)yunidadescompradas.Unjuguetepuedeserregalodevariosnios,porejemplo,tresunidades de Camin articulado puede ir a tres nios distintos. El sistema realizar este reparto de lamanerasiguiente:paracadanio,secomprobarsiesmenorde5aos.Siesmenordeestaedad,siquedaalgnjugueterecomendadoparamenoresde5aos,seleasigna.Sinnoquedandesuedad,secompruebasiquedan juguetespara todas lasedades. Siquedande todas lasedades se le asignauno. Sinoquedanjuguetesparasuedadnidelosdetodaslasedades,elsistemadebedarunaviso,diciendoqueesnecesariocomprarmsjuguetesparalosdemenosde5aosoparatodaslasedades.Paralosniosde5aosoms,elsistemaactuardeformaanloga.

Finalmente,pararealizarsurondadevisitas,cadagrupotienequepoderconocerqu juguetes,ycuantos,tienenquemeteressussacos.

1. RealizarelDiagramaEntidad/RelacinparalaaplicacindegestindeproyectosparasoportarMDD(3puntos)

2. ConrespectoNICAMENTEalastransformacionesdemodelos:a. Identificarydescribirenformatodealtonivelloscasosdeusorelacionados(1,5puntos)b. Realizareldiagramadesecuenciadeanlisisparalarealizacindeunatransformacin(1,5

puntos)

Ejercicio2

a.Flujogramanormalizadoeindicarlacomplejidadciclomtica(1punto)

Para resolver este apartado el punto de partida ser el psudocdigo relacionado con el reparto dejueguetes/regalos.Debetenerseencuentaquecadaniorecibenicamenteunregaloyqueelrepartodejuguetesimplicalaasignacinatodoslosniosdesucorrespondienteregalo.

Pseudocdigo

Paracadanio Siedad

Hayjuguetestodasedades

1

5

7

6

4

3

10

19

18

2

Inicio

Paracada

b.1punto

1.)1,2,19

2.)1,2,3,4,5,10,18,2

3.)1,2,3,4,6,7,9,10,18,2

4.)1,2,3,4,6,8,9,10,18,2

5.)1,2,3,11,12,17,18,2

6.)1,2,3,11,13,14,16,17,18,2

7.)1,2,3,11,13,15,16,17,18,2

c.1punto

1.)Nohaynios.Num_Nios=0

2.)Num_Nios>1;Edad=3;Juguetes_Menos_5>0

3.)Num_Nios>1;Edad=3;Juguetes_Menos_5=0;Juguetes_Todas_Edades>0

4.)Num_Nios>1;Edad=3;Juguetes_Menos_5=0;Juguetes_Todas_Edades=0

5.)Num_Nios>1;Edad=7;Juguetes_Mas_5>0

6.)Num_Nios>1;Edad=7;Juguetes_Mas_5=0;Juguetes_Todas_Edades>0

7.)Num_Nios>1;Edad=7;Juguetes_Mas_5=0;Juguetes_Todas_Edades=0


Nmero de Matrcula Nmero de orden 010101010 1) Las funcionalidades que implementa un producto

a) Deben satisfacer las necesidades del cliente b) Deben ser funcin del ciclo de vida c) Deben ser funcin de las necesidades de la empresa contratista que desarrolla d) A priori no se puede afirmar si dependern ms de las necesidades del cliente o de la empresa contratista que desarrolla

2) El ciclo de vida en espiral a) Sirve para obtener productos de forma ms eficiente que el ciclo de vida en cascada b) Sirve para obtener productos de forma menos eficiente que el ciclo de vida en cascada c) Sirve para obtener productos de forma ms rpida que el ciclo de vida en cascada d) Sirve para obtener productos de forma alternativa al ciclo de vida en cascada

3) Tenemos dos implementaciones de un mismo conjunto de requisitos funcionales A y B a) Si A tiene un acoplamiento mayor que B, A ser ms fcil de modificar que B b) Si A tiene un acoplamiento mayor que B, A ser ms difcil de modificar que B c) No podemos decir cul ser ms fcil de modificar d) Si A tiene un acoplamiento mayor que B, A y B sern igualmente difciles de modificar

4) La utilizacin de normas en ingeniera del software a) Causa siempre problemas de entendimiento en el equipo b) Facilita la definicin de un marco comn de trabajo c) Es til slo en proyectos de software crtico d) Procede de una falta de lenguajes de programacin realmente avanzados

5) Tenemos una especificacin de requisitos, y un modelo de clases realizado a partir de esta especificacin. Aparece una clase que no podemos trazar con ningn requisito a) Eso es normal; no hay que preocuparse b) Habr que estudiar lo que ocurre: falta un requisito, sobra la clase? c) Hay que eliminar la clase en cualquier caso d) Hay que introducir un nuevo requisito en cualquier caso

6) Un diagrama de casos de uso describe a) Un actor, el usuario final, que interacciona con clases b) Un actor, el usuario final, que interacciona con mtodos c) Un actor, el usuario final, que interacciona con entidades d) Las otras respuestas son falsas

7) Las pruebas de caja negra a) Son excluyentes con las de caja blanca; si realizamos unas no tenemos que realizar las otras b) Han de ser planificadas en funcin de la estructura del cdigo en general c) Han de ser planificadas en funcin del grafo de caminos bsicos d) Las otras son falsas

8) Dado el mdulo M(a:int, b:int, c:string) cuando diseamos un conjunto de pruebas de caja negra para ste mdulo a) Somos conscientes de que podra haber ms; al disearlas elegimos un subconjunto b) No sabemos si podra haber ms c) No debera haber ms pues los mtodos de diseo de pruebas, como el de las clases de equivalencia, tienen como objetivo

encontrar todas las pruebas posibles d) Todas las otras respuestas son falsas

9) Un sistema se ha modelado con un diagrama de clases y varios de secuencia; un mtodo no se usa en ningn diagrama de secuencia a) Ese mtodo se llama supermtodo e implementa el acceso a un conjunto de mtodos b) Ese mtodo pertenece a una clase llamada superclase, que agrupa mtodos que no se usan en los diagramas de secuencia c) Simplemente se eliminar ese mtodo por ser redundante d) Las otras son falsas

10) La gestin de configuracin a) Es un proceso de apoyo al ciclo de vida b) Es un proceso prescindible del ciclo de vida c) Es un proceso que aumenta, en general, el tiempo de implementacin para llegar al producto final d) Es un proceso superado por la metodologas giles

11) El efecto de no separar las clases de control de las de entidad al disear una arquitectura a) Nos lleva a una arquitectura con un nivel de acoplamiento mayor b) Nos lleva a una arquitectura con un nivel de acoplamiento menor c) Nos lleva a una arquitectura ms compleja pero ms fcilmente implementable d) Nos lleva a una arquitectura menos compleja y ms fcilmente implementable


Nmero de Matrcula Nmero de orden 010101010 12) Las pruebas de aceptacin se ejecutan antes de las unidad

a) En el caso del ciclo de vida espiral b) En ningn caso c) En el caso de que estemos desarrollando con metodologas giles d) En el caso del ciclo de vida incremental

13) Una relacin 1:N, al introducir el aspecto temporal, suele pasar a ser M:N. Es el caso de la relacin entre empresa y empleado contemplando la visin a lo largo de los aos a) Eso es cierto para el modelo entidad-relacin, pero no en el modelo de clases de UML b) Eso es cierto para el modelo de clases de UML, pero no en el modelo entidad relacin c) Eso es cierto slo en el caso de que podamos contar con entidades asociativas d) Eso es cierto para el modelo entidad-relacin, y para el modelo de clases de UML

14) Si tenemos establecida adecuadamente la trazabilidad en un proyecto para un mtodo podemos a) Saber qu pruebas de unidad le corresponden y de qu requisito(s) se deriva b) Recorrer sus caminos bsicos, y saber qu pruebas de unidad le corresponden y de qu requisito(s) se deriva c) Generar automticamente las pruebas de unidad, y saber de qu requisito(s) se deriva d) Generar automticamente las pruebas de unidad, y saber cules son estas pruebas

15) Las revisiones tcnicas nos permiten localizar errores aunque simplemente leamos documentos a) Las revisiones tcnicas son una tcnica no muy til y obsoleta b) Es til siempre que la complejidad ciclomtica sea menor de 20 c) Es til siempre que la complejidad ciclomtica sea mayor de 20 d) Las revisiones tcnicas son una tcnica til pero dura para el que realiza la revisin

16) Podemos asegurar sin duda que el nmero de fallos o bugs de un sistema software es cero si se han realizado todas las pruebas de caja blanca y negra y han sido ejecutadas de forma exitosa a) La afirmacin es cierta siempre b) La afirmacin es falsa siempre c) La afirmacin es cierta en el caso de requisitos funcionales d) La afirmacin es cierta en el caso de requisitos de rendimiento

17) Si los programadores P1 y P2 estn modificando el mdulo M bajo un sistema de gestin de versiones que funcione bien a) Si P1 hace check-out de M a las 10:15, se perdern las actualizaciones que hizo P2 a las 10:00 b) Si P1 hace check-out de M a las 10:15, no se perdern las actualizaciones que hizo P2 a las 10:00 c) Si P1 hace check-out de M a las 10:15, no sabemos si se perdern las actualizaciones que hizo P2 a las 10:00 d) Los sistemas de gestin de versiones no estn pensados para gestionar este tipo de cosas

18) Los aspectos ticos pueden entrar en conflicto con los comerciales a) Eso no tiene por qu ocurrir nunca b) Eso puede ocurrir si un ingeniero trabaja para dos clientes del mismo sector, por ejemplo c) Eso puede ocurrir pero los aspectos comerciales siempre deben primera frente a los ticos d) Eso puede ocurrir pero en ese caso hay que aplicar el modelo econmico de Boehm

19) La especificacin de requisitos, tenga la forma externa que tenga a) Es una informacin que cada vez tiene menos relevancia en el ciclo de vida b) Es una informacin cuya importancia radicaba en los ciclos de vida en cascada c) Es una informacin superada por la utilizacin de modelos como UML d) Es una informacin que conserva su relevancia incluso en metodologas giles

Puntuacin: Cada respuesta correcta suma 0.2 puntos. Cada respuesta contestada de forma incorrecta descuenta 0,1 puntos Durante la primera media hora no se podr abandonar el examen. Si un alumno desea que no le cuente la convocatoria deber abandonar el examen antes de que se distribuyan los ejercicios prcticos Las calificaciones provisionales se publicarn el da 17 de diciembre La revisin tendr lugar el da 18 de diciembre



a a b b c c d

1

11

d a a b b c c d

2

12

d a a b b c c d

3

13

d a a b b c c d

4

14

d a a b b c c d

5

15

d a a b b c c d

6

16

d a a b b c c d

7

17

d a a b b c c d

8

18

d a a b b c c d

9

19

d a a b b c c d

10

20

d

Ingeniera del Software Examen 6 junio 2008 2,15 horas

Sistema de gestin de proyectos y comercial

La oficina comercial de una empresa de ingeniera quiere implantar un nuevo sistema informtico para la gestin de proyectos. La empresa quiere mantener la informacin de los proyectos para los clientes actuales as como los que ha llevado a cabo en los ltimos aos. Un papel importante en la gestin de los proyectos lo desarrollan los comerciales. De los cuales se quiere conocer su nombre, direccin, telfono fijo y telfono mvil; adems los comerciales tienen un cdigo interno asignado cuando pasan a formar parte de la empresa y se quiere conocer en cuntas comunidades autnomas han tenido clientes. Los clientes se identifican por un cdigo de cliente y adems se quiere almacenar informacin sobre su nombre, telfono, domicilio, comunidad autnoma de las oficinas centrales y el tipo de cliente: empresa o particular. Dado que los clientes pueden cambiar su domicilio fiscal en funcin de las subvenciones para la realizacin de proyectos que las comunidades autnomas otorgan, es muy importante que el sistema a implantar soporte dichos cambios de domicilio. Para la empresa de ingeniera slo es relevante conocer la comunidad autnoma en la que actualmente se encuentran las oficinas centrales del cliente; por lo tanto no es necesario almacenar informacin de las diferentes comunidades por las que ha pasado la empresa. Es muy importante conocer la fecha en la que se estableci la sede en la nueva comunidad. De las comunidades se quiere conocer su nombre y el porcentaje de subvencin que aplican a los proyectos. Los comerciales, en cada momento, slo tienen asignada una comunidad autnoma para la bsqueda de proyectos, aunque en una comunidad puede haber ms de un comercial. Por supuesto los comerciales, durante su estancia en la empresa, han podido trabajar en diferentes comunidades autnomas siendo sta informacin relevante. Es importante conocer la fecha de inicio y de finalizacin de la asignacin a cada comunidad. El proceso de cambio de comunidad es bastante complejo por lo que se quiere que est automatizado en el nuevo sistema informtico. Se llama cartera de clientes a la lista de los clientes que tiene un comercial. Las carteras de clientes no pueden tener clientes repetidos, es decir, bajo ningn concepto un cliente puede pertenecer a ms de una cartera. Si bien, cuando una empresa se cambia de comunidad autnoma, puede quedar fuera de las carteras clientes en el caso de que la empresa no tenga comercial asignado para dicha comunidad. En cualquier caso, la cartera deber reflejar la fecha en que se incorporado o borrado el cliente. Cuando un comercial cambia de comunidad, si tiene algn cliente en su cartera, lo primero que se hace es comprobar si en la comunidad hay algn otro comercial asignado. Si no existe ninguno, los clientes de su cartera quedarn sin asignar a ningn comercial y se anotar dicha fecha como fecha de variacin. En el caso de existir comerciales asignados, se comprobar si slo hay uno. En este caso se le asigna la cartera completa. Cuando hay ms de uno, la cartera se asigna de forma equitativa entre todos los comerciales. En el caso de no tener clientes en su cartera se realiza el cambio sin ms. Un comercial slo puede visitar a las empresas clientes de su comunidad autnoma y cuando cambia de comunidad autnoma pierde su cartera de clientes, aunque a la empresa le interesa conocer el historial de contactos (pero no de las visitas) de cada comercial. Tambin es posible que un comercial pueda ceder de forma voluntaria parte de su cartera. En este caso, slo es importante que no se pierda ningn cliente de las carteras de clientes.

Ingeniera del Software Examen 6 junio 2008 2,15 horas

Sistema de gestin de proyectos y comercial

Lo ms importante para la empresa es almacenar informacin de los proyectos activos, es decir, los que actualmente se estn llevando a cabo. Cada proyecto tiene asignado un nmero de proyecto (denominado nmero de contrato), un presupuesto, una fecha de inicio y una fecha lmite de realizacin. Los proyectos estn activos durante el tiempo transcurrido entre el inicio y la fecha lmite de realizacin y pasan, de forma automtica, a ser no activos, en cualquier otra fecha. Es importante conocer el da en el que se realiz la firma del contrato entre la empresa y el cliente y por supuesto es importante conocer el comercial que ha posibilitado la firma del contrato. Se quiere conocer en todo momento la lista de proyectos activos que tiene la empresa. Se pide:

1. ObtenereldiagramaEntidad /Relacin con lanotacindeChen (2,25puntos).RealizarelpasoaMartin(0,75puntos)

2. Identificarloscasosdeusoconlasaccionesarealizarporelsistemayquenosecorrespondenconaltas y bajas de los datos del modelo. Especificar los casos de uso en formato de alto nivel yrepresentar el diagrama de casos de uso (2 puntos). Representar en pseudocdigo asociado alcambiodecomunidadporpartedeuncomercial,obtener loscaminos independientesparadichocdigoeindicarlascondicionesquehacenposiblelaexploracindeloscaminos(1punto).

Normas:



con el nombre. o Durante la primera media hora no se podr abandonar el examen.

Ejercicio2

Casosdeuso:Formatodealtonivel:

Nombre Listar_Activos

Tipo Primario

Actores Usuario

DescripcinMuestraaquellosproyectosqueseencuentranactualmenteactivos.Unproyectoestactivoduranteeltiempotranscurridoentreelinicioylafechalmitederealizacin

Nombre Mover_Sede_Cliente

Tipo Primario

Actores Usuario

DescripcinDadoquelosclientespuedecambiarsudomiciliofiscalenfuncindelassubvencionesparalarealizacindeproyectosquelascomunidadesautnomasotorgan,esmuyimportantequeelsistemaaimplantarsoportedichoscambiosdedomicilio.

Nombre Cambiar_Comunidad

Tipo Primario

Actores Usuario

Descripcin

Los comercialesdurante suestanciaen laempresahanpodido trabajarendiferentes comunidadesautnomas siendo esta informacin relevante. Es importante conocer la fecha de inicio y definalizacin de la asignacin a cada comunidad. El proceso de cambio de comunidad es bastantecomplejopor loque sequierequeestautomatizadoenelnuevo sistema informtico.Cuandouncomercialcambiadecomunidadcedelatotalidaddelosclientes

Nombre Listar_Activos

Tipo Primario

Actores Comercial

Descripcin

Tambinesposiblequeuncomercialpuedacederde formavoluntariapartede sucartera.Enestecaso, slo es importante que no se pierda ningn cliente de las carteras de clientes. Cuando uncomercialcambiadecomunidad,secompruebasienlacomunidadhayalgnotrocomercialasignado.Sinoexisteninguno, losclientesseleccionadosquedarnsinasignaraningncomercialyseanotardichafechacomofechadevariacin.Enelcasodeexistircomercialesasignados,secomprobarsislohayuno.Enestecasoseleasignalacarteracompleta.Cuandohaymsdeuno,lacarteraseasignadeformaequitativaentretodosloscomerciales.Enelcasodenotenerclientesensucarteraserealizaelcambiosinmas.

Diagramadecasosdeuso:

Gestion_Proyectos Gestion_Proyectos

UsuarioUsuario

Mover_sede_cliente

Mover_sede_cliente

Cambiar_comunidad

Cambiar_comunidad

Comercial

Ceder_Cartera

Ceder_Cartera

Listar_Activos

Listar_Activos

Puedenaparacermascasosdeusoperonotienenespecialrelevanciaconrespectoalenunciado.

Pseudocdigo

Obtener_Cartera(Comercial)

Si(Clientes(cartera)==0)

Cambiarcomunidad

Else

Obtener_comunidad(Comercial,fecha)

Si(Asignado(Comunidad,fecha)==0)

Poner_Nulo_Comercial(Clientes,hoy)

Else

Si(Asignado(Comunidad,fecha)==1)

Obtener_Comercial(Comunidad)

Poner_Comercial(Clientes,Comercial,hoy)

3

4 5

6 7

8

9

2NO

NO

Asignado ==1

SI

Asignado ==0

NO

SI

SI

10

1 Cartera==0

Else

Obtener(Comerciales,Comunidad)

Repartir(Clientes,Comerciales,hoy)

EndSi

EndSi

EndSi

Caminosindependientes:

1. 1,2,10 Comercialsincartera2. 1,3,4,9,10 ComercialconcarterayComunidadsincomercialasignado3. 1,3,5,6,8,9,10 ComercialconcarterayComunidadconuncomercialasignado4. 1,3,5,7,8,9,10 ComercialconcarterayComunidadconmsdeuncomercialasignado

(0,N)

(1,1)

Fecha

COMERCIAL Cod. Comerci. Nombre Dir. Fijo Mvil

tiene (0,N)

CC.AA Cod Comu. nombre Subvencin

(1,N)

F. Fin F. Ini

Firma (0,N)(1,1)

CLIENTE Cod Cliente Nombre Domicilio Tipo Telfono

Esta

tiene

(0,N)

(0,N)

tiene

PROYECTO Num. Proyecto Presupuesto F. Inicio F. Fin F. Firma

(0,N)

(0,N) (1,1)

COMUNIDAD COMERCIAL

CLIENTE PROYECTOfirma

firmaesta_en

SITUACION_COM.

DETALLE_CARTERAparece_en

tiene

tiene

tiene


Nmero de Matrcula Nmero de orden 010101010 1. Las funcionalidades que debe implementar un producto para satisfacer al usuario

a. Dependern principalmente del ciclo de vida elegido b. Dependern principalmente de las necesidades del cliente que contrata su desarrollo c. Dependern principalmente de las necesidades de la empresa contratista que desarrolla d. A priori no se puede afirmar si dependern ms de las necesidades del cliente o de la empresa

contratista que desarrolla 2. El ciclo de vida en espiral llega tras la primera iteracin a un conjunto de requisitos estable

a. Nunca b. A veces c. Normalmente si d. Depende de la visin estratgica del jefe de proyecto

3. Escenario 1: El mdulo A usa B y C; B usa a E Y F. Una instruccin en F tiene un efecto lateral en C Escenario 2: El mdulo A usa B y C; B usa a E Y F. Se ha eliminado el efecto lateral de F sobre C a. La medida de acoplamiento es mayor en el escenario 1 que el 2 b. La medida de acoplamiento es menor en el escenario 1 que el 2 c. La medida de acoplamiento es mayor en el escenario 1 que el 2 y la de la cohesin mayor d. La medida de acoplamiento es menor en el escenario 1 que el 2 y la de la cohesin mayor

4. A partir de un documento de especificacin de requisitos realizado de acuerdo con IEEE 830 se realiza un modelo de clases. Cuando se termine el proyecto, tras un anlisis de trazabilidad nos encontraremos con escenarios en los que a. Es deseable que exista un nmero bajo de clases que no se puedan "trazar" desde un requisito

funcional b. Es exigible que no haya clases que no se puedan "trazar" desde un requisito funcional c. Cada clase se "trazar" a todos los requisitos funcionales d. Cada clase se "trazar" a todos los requisitos de interfaz de usuario

5. Un diagrama de casos de uso describe la interaccin de a. Un actor con algunas clases seleccionadas del diagrama de clases (p.ej. la clase sistema) b. Actores directamente entre ellos (cliente y administrador) c. Un actor con algunas entidades seleccionadas del diagrama entidad relacin d. Todas las anteriores son falsas

6. Un conjunto de pruebas de caja blanca producidos para el sistema A a. Su ejecucin exitosa garantiza la ausencia de errores provenientes de bucles mal programados b. Su ejecucin exitosa garantiza la ausencia de errores provenientes de bucles mal programados

slo si el conjunto es completo c. Su ejecucin exitosa garantiza la ausencia de errores provenientes de bucles mal programados

slo si el conjunto es completo y cerrado d. Su ejecucin exitosa garantiza el buen comportamiento de A con esas pruebas

7. Un mtodo tiene un parmetro de entrada G de graduacin de alcohol, de tipo entero. Puede tomar valores de 0 a 100. La ejecucin de unas pruebas se ha hecho con los valores 0, y 101. a. El sistema se comporta bien para esos dos casos de prueba y poco ms b. Hemos realizado todas las pruebas de caja negra que debamos realizar y podemos asegurar

que el mtodo no tiene errores c. Hemos realizado el nmero mnimo todas las pruebas de caja negra que debamos realizar d. Hemos realizado el conjunto completo de pruebas de caja negra que debamos realizar

8. Un sistema se ha modelado con un diagrama de clases y varios de secuencia. a. Al terminarlos podemos encontrar mtodos en los de secuencia que no estn en el de clases b. Al terminarlos podemos encontrar mtodos en el de clases que no estn en ninguno de los de

secuencia c. Al terminarlos no debemos encontrar mtodos en el de clases que no estn en ninguno de los

de secuencia d. Las otras son falsas


Nmero de Matrcula Nmero de orden 010101010 9. Un mtodo incluye dos procedimientos que comparten un variable global. El acoplamiento es de

a. Control b. Contenido c. Datos d. Comn

10. Al disear la arquitectura de un sistema la introduccin de clases de control nos permiten a. Aislar aspectos del comportamiento de la aplicacin, lo que mejora el diseo b. Controlar la ejecucin de la aplicacin, lo que no sera posible de otra manera c. Controlar el acceso desde otras aplicaciones d. Las otras son falsas

11. El diseo del plan de integracin incluir las pruebas de integracin. Para ello es necesario a. Definir una infraestructura software slo en el caso de que la estrategia sea top-down b. Definir una infraestructura software slo el caso de que la estrategia sean bottom-up c. Definir una infraestructura software slo el caso de que la estrategia sea big-bang d. Las otras son falsas

12. Cuando transformamos una relacin M:N del modelo de Chen al de Martin a. Siempre introducimos una entidad nueva, que no tendr atributos, y dos relaciones 1:N b. Siempre introducimos una entidad nueva, que es una entidad virtual, y dos relaciones 1:N c. Siempre introducimos una entidad nueva, que es una entidad asociativa, y dos relaciones 1:N d. Siempre introducimos una entidad nueva, que es una entidad virtual, dos relaciones 1:N y

migramos claves 13. Si tenemos establecida trazabilidad adecuadamente en un proyecto, podemos

a. Saber el impacto de que cambie un requisito en trminos de los mtodos que habr que modificar b. Recorrer los caminos bsicos c. Evaluar la ejecucin de un conjunto de pruebas de caja negra d. Evaluar la ejecucin de un conjunto de pruebas de caja blanca y negra

14. Si recorremos todos los caminos bsicos de un mtodo con un conjunto de pruebas a. No ser preciso realizar ms pruebas de caja blanca b. Podemos realizar algunos otros tipos de pruebas, pero sern redundantes c. Podemos afirmar que no hay ramas que no se puedan ejecutar d. Podemos afirmar que la complejidad ciclomtica ser menor que el nmero Bohm de valor 20

15. Las revisiones tcnicas nos permiten localizar errores aunque simplemente leamos documentos a. Sabemos que son muy eficientes en su objetivo b. Localizar se localizan errores, pero no pueden competir con las pruebas c. No tenemos indicios para saber cul es mejor d. Es una tcnica obsoleta

16. La calidad de un producto software, en cualquier caso a. Tiene relacin directa con el tiempo de respuesta: a ms rpido, mayor calidad b. Tiene relacin directa con el tiempo de respuesta: a ms rpido, menor calidad c. Tiene relacin directa con el tiempo de respuesta: sigue el modelo de Brooks d. No tiene que tener relacin con el tiempo de respuesta

Puntuacin: Cada respuesta correcta suma 0.25 puntos. Cada respuesta contestada de forma incorrecta descuenta 0,12 puntos Durante la primera media hora no se podr abandonar el examen. Si un alumno desea que no le cuente la convocatoria deber abandonar el examen antes de que se distribuyan los ejercicios prcticos Las calificaciones provisionales se publicarn el da 23 de junio



a a b b c c d

1

9

d a a b b c c d

2

10

d a a b b c c d

3

11

d a a b b c c d

4

12

d a a b b c c d

5

13

d a a b b c c d

6

14

d a a b b c c d

7

15

d a a b b c c d

8

16

d

IngenieradelSoftware 19deseptiembrede2008 Examen 2horasApellidos Nombre


Ejercicio

EldepartamentodeIngenieradeunaempresainformticahadecididoactualizarlagestindesusproyectosteniendoencuentaqueseestnadaptandoalasnuevastendenciaseneldesarrollodesoftwaremediantelaaplicacindeDesarrolloDirigidoporModelos(MDD).ElDepartamentohadecididoquequieredisponerdeunrepositoriocon losactivosde laempresarelacionadosconeldesarrollo.Estosactivossecorresponden,entreotros, con losdatosde losproyectosque se llevan a cabo, las instancias, losmodelosque se hanutilizadoparalarealizacindelosproyectos,

TeniendoencuentaMDD,unproyectoestformadoporunaseriedeinstanciasquerepresentanunaseriedemodelosquesevanrefinandoytransformandohastaque,finalmente,seobtieneelcdigofuentequelosoporta.Desdeelpuntodevistade lagestindeproyectos losdatos relevantesdecadaproyectosonsucdigodeproyecto,acrnimo,nombrecompleto,fechadeinicioyfechadefinalizacin.

Algunosmodelossepuedenrepresentarmediante instancias,aunquehaymodelosquenotienenninguna.Cadainstanciaestidentificadaporuncdigonicoyporunaimagenquemuestraelcontenidodelamismay,porsupuesto,perteneceaunnicomodelo.

Cadainstanciaperteneceauntipoespecficoderepresentacinyestasociadaauntipodemodelos.Comoexistenmltiplestiposderepresentacin,laempresahadecididoquecadaunotengauncdigoparticularyun nombre, adems sedeberndescribir las tcnicasnecesariaspara crearlos ymostraruna imagendeejemplodeltipodeinstancia.Cadatipoderepresentacinestasociadoaunnicotipodemodelo,aunqueuntipodemodelopuedetenermltiplestiposderepresentacin.

Cada tipodemodelo se reconoceporuncdigode tipodemodelo,unnombreyelnivelMDDalque secorresponde(CIM,PIM,PSM,Cdigo).Unmodeloperteneceaunnicotipodemodeloyporsupuesto,paracadatipodemodelopuedenexistirmuchosmodelos.Hayquetenerencuentaqueexistencompatibilidadesentre tipos de modelos. Estas compatibilidades permitirn posteriormente guiar el proceso detransformacindemodelos.Cadatipodemodelopuedesercompatibleconmsdeuntipodemodelos.

Conrespectoalosmodelos,cadamodeloestidentificadoporuncdigodemodelo,unnombredemodelo,un nivel de modelo (MDD trabaja con modelos a diferentes niveles: metametamodelo, metamodelo,modelo, instancia),eltipodemodelodequesetratay lostiposderepresentacinutilizados.Aplicando lafilosofadereutilizacin,unmismomodelo,sincambios,puedeaplicarseamltiplesproyectos.

EnMDD, son fundamentales las transformacionesdemodelos.Una transformacin siempre afecta adosmodelos, unmodelo origen y otro destino (que deben ser distintos) y pertenece a un tipo determinado(PIM2PIM,PIM2PSM,PSM2PSM,PSM2Code,).Cadatransformacinllevaasociadaunficherodetextoqueindicalospasosdelamismaylafechademodificacindelatransformacin.

Con respecto a las transformaciones, adems de la definicin de nuevas transformaciones de modelos,puedenmodificarse y ejecutarse las existentes. Tambin esnecesario conocerparaunmodelosdado lastransformacionesdelasqueesorigenascomo,lastransformacionesdelasqueesdestino.

Cuando se va a definir una transformacin, se elegir el nivel al que pertenece el modelo origen de latransformacin (CIM, PIM, PSM, Cdigo). A continuacin, semostrarn aquellosmodelos disponibles dedichonivelparapoderseleccionaruno.Unavezelegidoelmodeloorigensehace lomismoconelmodelo

IngenieradelSoftware 19deseptiembrede2008 Examen 2horasApellidos Nombre


Ejercicio

destino.Unavezelegidoslosmodelosorigenydestino,habrquecomprobarqueambostiposdemodelossoncompatiblesentresparapoderdefinirlastransformaciones.

Unavezquesehacomprobadoquelastransformacionessoncompatibles,yquelosmodelossondistintos.Seasignaunnombredeficheroalatransformacinquedependedelmodeloorigenyelmodelodestino.Acontinuacin, sealmacena la transformacinen labasededatos.Conelnombrede ficherodefinido, seabrireleditordetransformacionesadquiridopor laempresa.staesunaaplicacinexternaquepermite,dadosunmodeloorigen yotrodestino, escribir el cdigoquedescribe la transformacin entre ellos. Sufuncionamientonoesrelevanteparalaaplicacindegestindeproyectos.Unavezescritalatransformacin,sealmacenaenunficherodetexto.

Sepide:

1. Realizarel

ex amenes

Documents