Engenharia de Software

Transcrição

1 UNIVERSIDADE DE LISBOA INSTITUTO SUPERIOR TÉCNICO Engenharia de Software LEIC/LETI, 3 o Ano, 2 o Semestre 1 o Teste, 4 de Abril de 2017 Duração: 90 minutos Nome: Número: Este teste tem um conjunto de 8 perguntas de escolha múltipla, e um conjunto de 2 perguntas de resposta aberta. Escreva o seu número em todas as folhas da prova. O tamanho das respostas deve ser limitado ao espaço fornecido para cada questão. Pode responder a lápis. Em cima da mesa devem estar apenas: enunciado, material de escrita e cartão de aluno. Apenas são permitidas folhas de rascunho fornecidas pelos docentes que devem ser devolvidas no final. A utilização de de qualquer aparelho electrónico (tais como telemóveis, calculadoras, etc) implica a anulação imediata do teste. Leia cuidadosamente as perguntas de escolha múltipla e coloque na grelha a letra correspondente à resposta correta para cada pergunta. Por favor, use apenas letras maiúsculas. Se não responder a uma determinada pergunta, marque a resposta com um X. A classificação das perguntas de escolha múltipla é feita da seguinte forma: uma resposta correta vale 0,6; uma resposta errada vale -0,2; uma pergunta não respondida vale 0. Por isso, no caso de não saber responder a uma determinada pergunta é preferível deixar a pergunta por responder. Para cada pergunta deve escolher a que considera mais correta. Respostas às questões de escolha múltipla (componente teórica): Não preencher. Reservado para a correcção. 9: 10: 11:

2 Número: Pág. 2/8 Perguntas de escolha múltipla 1. A Engenharia de Software é uma disciplina da engenharia que se ocupa com os aspectos do desenvolvimento de software. Os métodos utilizados nesta disciplina A) São um conjunto de atividades cujo objetivo é apenas o desenvolvimento de software. B) São uma representação simplificada de um processo de desenvolvimento software, apresentada a partir de uma perspectiva específica. C) São abordagens estruturadas para o desenvolvimento de software, incluindo modelos e processos de desenvolvimento de software. D) Estudam apenas a teoria e os fundamentos de desenvolvimento de software. 2. Das seguintes frases, uma não descreve o funcionamento da metodologia Scrum. A) O Product Owner e o Scrum Master são elementos das equipas de desenvolvimento. B) O Scrum Master é o representante dos clientes (stakeholders) na equipa. C) Scrum é uma metodologia incremental e iterativa para desenvolvimento de software. D) Cada sprint começa com uma reunião, Sprint Planning, para definir o que vai ser implementado durante esse sprint. 3. Existem situações para as quais a Integração Contínua (Continuous Integration, CI) necessita de ser realizada de forma faseada, porque A) É necessário reduzir a colaboração através do aumento dos ciclos de desenvolvimento isolados. B) A integração contínua obriga a que o software seja testado frequentemente. C) Alguns sistemas demoram bastante tempo a compilar e a testar. D) A manutenção de infraestrutura de integração contínua própria requer custos elevados. 4. Sobre inspeções (inspections), qual das seguintes afirmações é verdadeira? A) Inspections são a forma menos eficaz de verificar a qualidade do software. B) Inspections é uma técnica de procura de defeitos em artefatos de software usando um processo bem definido (por exemplo, recorrendo a checklists). C) Inspections não podem ser usadas para analisar documentos de requisitos. D) É pouco provável que inspections ajudem a encontrar potenciais problemas em documentos de arquitetura de software.

3 Número: Pág. 3/8 5. Mocks vs. Stubs A) Mocks são utilizados para testes de comportamento (behavioral testing) e stubs para testes de estado (state testing) B) Stubs são utilizados para testes de comportamento (behavioral testing) e Mocks para testes de estado (state testing) C) A utilização de Stubs implica a especificação de um conjunto de expectativas. D) Apenas Mocks são considerados test doubles. 6. Qual a finalidade do seguinte comando git checkout -b teste A) Cria o branch teste, como uma cópia do branch actual, e move-se para esse branch. B) Verifica a existência de conflitos entre o branch actual, por exemplo o master, e o branch teste. C) Move-se para o branch teste que já existe no repositório local. D) Cria uma versão do branch teste no servidor remoto. 7. Na gestão de riscos, durante o desenvolvimento de software, a análise de riscos serve para A) Apenas listar os potenciais riscos do projeto. B) Priorizar e quantificar a probabilidade e o impacto dos riscos. C) Criar um plano de contingência para os riscos identificados. D) Monitorizar as alterações no impacto e probabilidade de o risco acontecer. 8. A Fénix Framework usa um dos Padrões em Aplicações Empresariais (Patterns of Enterprise Application Architecture) estudados A) Table Data Gateway. B) Row Data Gateway. C) Active Record. D) Data Mapper.

4 Número: Pág. 4/8 Perguntas sobre a componente prática O projeto ADVENTURE BUILDER que está a ser desenvolvido na disciplina de Engenharia de Software tem como funcionalidade principal a integração de diversos fornecedores de serviços com vista à oferta de atividades de lazer.

5 Número: Pág. 5/8 9. (1.7) Considere código abaixo que implementa o comportamento do método process da classe BookRoomState. Analisando esse método indique os casos de teste (não a sua implementação), utilizando as técnicas de partição de equivalência e análise de valores de fronteira. public void process() { try { getadventure().setroomconfirmation( HotelInterface.reserveRoom( Room.Type.SINGLE, getadventure().getbegin(), getadventure().getend())); catch (HotelException he) { getadventure().setstate(state.undo); return; catch (RemoteAccessException rae) { incnumofremoteerrors(); if (getnumofremoteerrors() == MAX_REMOTE_ERRORS) getadventure().setstate(state.undo); return; getadventure().setstate(state.confirmed); Solução: sucesso : HotelInterface.reserveRoom devolve uma String válida, o estado final é CONFIRMED. sucesso com máximo de falhas remotas : HotelInterface.reserveRoom devolve MAX_REMOTE_ERRORS - 1 RemoteAccessException seguido de uma String válida, o estado final é CONFIRMED. mesmo estado com uma falha remota : HotelInterface.reserveRoom devolve uma RemoteAccessException, o estado final é BOOK_ROOM. mesmo estado com máximo falhas remotas : HotelInterface.reserveRoom devolve MAX_REMOTE_ERRORS - 1 RemoteAccessException, o estado final é BOOK_ROOM. undo com uma excepção do hotel : HotelInterface.reserveRoom devolve uma HotelException, o estado final é UNDO. undo com máximo de falhas remotas : HotelInterface.reserveRoom devolve MAX_REMOTE_ERRORS RemoteAccessException, o estado final é UNDO. undo com uma falha remota e uma excepção do hotel : HotelInterface.reserveRoom devolve uma RemoteAccessException e uma HotelException, o estado final é UNDO.

6 Número: Pág. 6/8

7 Número: Pág. 7/8 10. (2.0) Implemente o caso de teste de sucesso que definiu na alínea anterior, aquele em que nunca acontece nenhum erro, e o caso de teste em que o número de RemoteAccessException é igual a MAX_REMOTE_ERRORS, recorrendo à framework JMockit considerando que HotelInterface é mocked. public void successbookroom(@mocked final HotelInterface hotelinterface) { String ROOM_CONFIRMATION = "ROOM_CONFIRMATION"; new StrictExpectations() { { HotelInterface.reserveRoom(Type.SINGLE, arrival, departure); this.result = ROOM_CONFIRMATION; ; this.adventure.process(); Assert.assertEquals(State.CONFIRMED, public void maxremoteaccessexception(@mocked final HotelInterface hotelinterface) { new StrictExpectations() { { HotelInterface.reserveRoom(Type.SINGLE, arrival, departure); this.result = new RemoteAccessException(); this.times = BookRoomState.MAX_REMOTE_ERRORS; ; for (int i = 0; i < BookRoomState.MAX_REMOTE_ERRORS; i++) { this.adventure.process(); Assert.assertEquals(State.UNDO, this.adventure.getstate().getvalue());

8 Número: Pág. 8/8 11. (1.5) Altere o domínio da aplicação do módulo Broker do ADVENTURE BUILDER, com recurso à Fénix Framework, de forma a que a informação seja adequadamente persistida. Modele a especificação do domínio usando a Domain Modeling Language (DML). NOTA: Necessita de modelar a relação das seguintes classes: Adventure e AdventureState, e as subclasses desta última, BookRoomState e ConfirmedState. Considere apenas os atributos de identificação e as datas de início e fim em Adventure, e o atributo com o número de erros em AdventureState. Não precisa de modelar operações (transações) por parte dos clientes nas contas. Solução: class Adventure { String ID; LocalDate begin; LocalDate end; class AdventureState { int numofremoteerrors; class ConfirmedState extends AdventureState; class BookRoomState extends AdventureState; relation AdventureHasState { Adventure playsrole adventure { multiplicity 0..1; AdventureState playsrole state { multiplicity 1..1; versão A C B C B A A B D B D A D A B D A B C A D A C D C D D D B C B D D B C A