UNIVERSIDADE DE LISBOA INSTITUTO SUPERIOR TÉCNICO Engenharia de Software LEIC/LETI, 3 o Ano, 2 o Semestre, Ano letivo de 2014/2015 Exame de 11 de Junho (Versão A) Nome: Número: Este exame tem um conjunto de 20 perguntas de escolha múltipla, e um conjunto de 5 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 exame. 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,5; uma resposta errada vale -0,1; 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): 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Não preencher. Reservado para a correcção. 21: 22: 23: 24: 25:
Número: Pág. 2/11 Perguntas de escolha múltipla 1. Um sistema do tipo P é aquele em que se constrói um modelo do problema. A) Este modelo vai permitir validar que o sistema tem o comportamento que se pretende. B) Pode vir a verificar-se que a abstração do problema, contida no modelo, não é a mais adequada para resolver o problema. C) O modelo constitui uma formalização completa do problema, pelo que a validação do sistema será igual à sua verificação. D) O modelo faz parte do mundo onde o problema se insere, pelo que a sua concretização alterará o próprio problema. 2. A definição de interfaces claras entre módulos A) Permite reduzir o número de canais de comunicação entre os membros da equipa de desenvolvimento. B) Obriga a uma organização da equipa centrada na tecnologia. C) Obriga a uma organização da equipa centrada na funcionalidade. D) Obriga à constituição de uma equipa plana. 3. Em GIT, após a operação commit, um ficheiro no estado Staged A) Passa para o estado Unmodified B) Passa para o estado Untracked. C) Passa para o estado Modified D) Permanece no estado Staged 4. De acordo com os padrões de construção de sistema um smoke test A) Pode levar bastante tempo a executar pois tem como objetivo descobrir o maior número de falhas possível. B) Inclui todos os testes regressivos do sistema. C) Invoca os testes de unidade assim como os testes regressivos. D) Deve levar pouco tempo a executar pois é executado durante as construções privadas (private system build). 5. Considere as seguintes três técnicas de estimação do esforço de desenvolvimento de um sistema de software: experiência dos peritos, algorítmica, e tempo-do-dia anterior (yesterday s weather). A) Os projetos orientados ao plano seguem a técnica do tempo-do-dia anterior. B) Estas três técnicas são empíricas. C) A técnica algorítmica não é empírica. D) Os projetos ágeis seguem a técnica da experiência dos peritos.
Número: Pág. 3/11 6. Nas técnicas de gestão do risco a prioritização dos riscos é efetuada com base A) Na sua probabilidade de ocorrência. B) No efeito da sua ocorrência. C) Na relação entre a probabilidade da sua ocorrência e o seu efeito. D) Usando um método algorítmico. 7. Num projeto SCRUM, o SCRUM master é responsável por A) Definir a arquitetura do sistema. B) Garantir que os programadores estão focados em terminar o sprint. C) Atribuir tarefas aos programadores. D) Definir quais as histórias a serem implementadas no próximo sprint. 8. Os testes de componente (component) podem integrar os módulos de diversas formas. A) Na integração bottom-up são necessários duplos para teste. B) Na integração top-down é necessário que todos os módulos tenham sido implementados. C) A integração bottom-up permite testar a funcionalidade final do sistema. D) A integração top-down pode requerer a utilização de duplos para teste. 9. Suponha que durante uma refactorização se substitui três utilizações de uma variável temporária pela expressão usada para calcular o valor que contém, técnica replace temp with query. A) Esta substituição vai necessariamente reduzir o desempenho do programa pois a expressão passa a ser calculada 3 vezes. B) Após esta substituição o desempenho do programa é o mesmo pois o compilador irá otimizar o código. C) Esta substituição apenas é possível se a expressão não tiver efeitos colaterais. D) Esta substituição deve ser sempre efetuada pois aumenta a legibilidade do código.
Número: Pág. 4/11 10. Considere o seguinte código da framework JUnit. A) Os programadores devem redefinir a classe TestResult sempre que seja necessário haver uma nova forma de apresentação de resultados. B) As exceções AssertFailedError correspondem a erros do tipo null pointer. C) A invocação do método run nunca deve falhar para que todos os testes possam executar. D) O método teardown apenas necessita de ser invocado quando o teste falha para repor o estado inicial. 11. Considere o padrão de desenho State. A) A classe Context está fortemente ligada à classe State. B) Existe coesão forte no método Handle(). C) As classes ConcreteState são fortemente coesas. D) As concretizações da classe State apenas podem possuir um método.
Número: Pág. 5/11 12. O requisito de que os acessos a um sistema apenas devem ser feitos por utilizadores autenticados A) Leva à identificação de requisitos funcionais associados ao login de utilizadores. B) É um requisito de safety. C) É um requisito funcional. D) É um requisito de fiabilidade. 13. Considere a especificação de requisitos não funcionais de fiabilidade. A métrica mais adequada a um sistema em que os danos associados a uma falha sejam significativos é: A) Taxa de ocorrência de falhas durante um determinado período. B) Probabilidade de falha por pedido efetuado. C) Tempo médio para falhar. D) Probabilidade de responder a um pedido. 14. O padrão arquitetural repositório A) É usado na arquitetura do Eclipse. B) Obriga a que as aplicações comuniquem entre si sem ser através do repositório. C) Faz com que as aplicações que acedem ao repositório sejam independentes do modelo de dados do mesmo. D) É fácil de distribuir o repositório. 15. Diversidade e redundância são as duas principais técnicas arquiteturais usadas para garantir a confiabilidade dos sistemas A) A diversidade é uma técnica que aplica ao hardware apenas. B) Os sistemas que efetuam auto-monitorização (self-monitoring) utilizam diversidade de software apenas. C) A diversidade segue o princípio do controlo da visibilidade da informação num programa. D) A redundância permite reduzir o risco através de técnicas de recuperação. 16. Dentro da barricada, nas zonas seguras, podem ser usadas asserções (asserts) para A) Tratar as situações de erro de forma que a execução não termine. B) Ajudar a detetar erros quando o sistema está em produção. C) Ajudar a detetar erros durante o desenvolvimento. D) Integrar a técnica test-first com depuração de programas.
Número: Pág. 6/11 17. Os elevados custos de manutenção de um sistema são devidos A) Aos constantes pedidos de alteração. B) Ao facto de ter um funcionamento errático. C) A uma perda de conhecimento acerca das suas funcionalidades e estrutura. D) A ser muito importante para o negócio. 18. Considerando as forças de estabilidade e progresso de uma linha de código, quando se pretende experimentar uma alteração arquitetural A) Deve ser criada uma nova linha de código onde se procede a essas alterações e que tenha maior estabilidade do que a linha de desenvolvimento ativa. B) Deve ser criada uma nova linha de código onde se procede a essas alterações e que tenha maior progresso do que a linha de desenvolvimento ativa. C) O desenvolvimento deve continuar na linha de desenvolvimento ativa mas com maior estabilidade. D) O desenvolvimento deve continuar na linha de desenvolvimento ativa mas com menor estabilidade. 19. O modelo Incremental de processo de desenvolvimento de software A) Define atividades explícitas de gestão do risco. B) Estabelece como milestone a verificação se foi atingido o necessário nível de conhecimento. C) Associa a cada etapa uma entrega. D) Não se aplica a desenvolvimento ágil. 20. A programação aos pares sugerida pela abordagem XP é uma forma de A) Garantir que, no caso de necessidade, a velocidade real da equipa é igual ao dobro daquela que é calculada quando se faz programação aos pares. B) Melhorar a qualidade dos testes, pois enquanto um programador escreve o código o outro define os casos de teste. C) Dar ênfase às vantagens da revisão do código. D) Reduzir a metade o número de pessoas que necessitam de participar no stand up meeting.
Número: Pág. 7/11 Perguntas sobre a componente prática O projeto BUBBLEDOCS desenvolvido durante a execução da disciplina de Engenharia de Software permite a criação e gestão de folhas de cálculo, em que cada folha de cálculo tem um dono e dois conjuntos de utilizadores: os que podem alterar a folha de cálculo e os que podem ler a folha de cálculo. Suponha agora que se pretende acrescentar os seguintes requisitos: A aplicação deve suportar um segundo tipo de documento, o documento de texto. Um documento de texto tem um nome, dono e o conjunto de utilizadores que podem alterar o documento. Por razões de simplificação, o texto de um documento de texto é representado simplesmente por uma cadeia de caracteres. O número de utilizadores que pode alterar um documento de texto é limitado. Este limite pode ser alterado em qualquer momento. Cada documento tem um dado tamanho. No caso de um documento de texto, o tamanho é igual ao número de caracteres do texto associado ao documento. No caso de uma folha de cálculo, o tamanho é determinado pela dimensão da folha de cálculo, sendo portanto igual ao produto do número de colunas da folha pelo número de linhas da folha.
Número: Pág. 8/11 21. (1.5) Altere o domínio da aplicação BUBBLEDOCS, com recurso à Fénix Framework, de forma a que a nova informação respeitante aos novos requisitos seja toda adequadamente persistida. Modele as alterações ao domínio usando a Domain Modeling Language (DML). NOTA: Os conceitos de User, SpreadSheet, BubbleDocs, Function, Cell e Content já se encontram definidos na aplicação desenvolvida pelo que não é necessário defini-los outra vez, a não ser que tenham que ser alterados. Neste caso escreva apenas as alterações a realizar, não sendo necessário concretizar totalmente a entidade em causa. Solução: Atenção: esta resposta é apenas um esboço da resposta a dar.
Número: Pág. 9/11 22. (1.0) Assuma que a aplicação atual representa os utilizadores em modo de escrita e leitura de uma folha de cálculo como duas associações distintas de muitos para muitos entre as entidades SpreadSheet e User. Aplicando a técnica de refatorização de código, indique os vários passos a seguir para introduzir o conceito de documento de texto na aplicação por forma as que as funcionalidades atuais da aplicação nunca deixem de funcionar. Solução: Atenção: esta resposta é apenas um esboço da resposta a dar. 23. (2.0) Tendo em conta a arquitetura em camadas aplicada no desenvolvimento da aplicação BUBBLEDOCS, altere a camada de domínio (o que inclui novos métodos, classes e alteração de métodos já existentes, caso seja necessário) por forma a concretizar os seguintes novos/alterados requisitos: Cálculo do espaço ocupado pelos documentos de um utilizador. Este valor é igual ao somatório do tamanho dos documentos criados pelo utilizador em causa. NOTA: Assuma nesta e nas restantes perguntas que qualquer classe de exceção que pretenda utilizar já se encontra concretizada, não sendo assim necessário concretizá-la. Pode também utilizar métodos que já tenha definido no seu projeto, necessitando apenas de indicar o que eles fazem. Solução: Atenção: esta resposta é apenas um esboço da resposta a dar. No exame seria necessário escrever o código. Aplicando os conhecimentos adquiridos nas aulas de laboratório relativas à Fénix Framework, deve alterar-se a camada de restrições definidas no domínio do problema. Isto passa por substituir os métodos corretos para associar as entidades envolvidas nesta funcionalidade por forma a concretizar as restrições requeridas.
Número: Pág. 10/11 24. (3.5) Tendo em conta a arquitetura em camadas aplicada no desenvolvimento da aplicação BUBBLEDOCS, altere a camada de serviços (e também a de domínio, caso seja necessário) da aplicação por forma a concretizar o serviço AddWriteUserToDocument. Este serviço é responsável por adicionar um novo utilizador ao conjunto de utilizadores que podem escrever no documento. Este serviço recebe o username do utilizador a adicionar e o identificador do documento. Por razões de simplificação, não se recebe o token do utilizador mas sim o seu username. Não é necessário verificar que o utilizador tem uma sessão válida. Solução: Atenção, esta resposta é apenas um esboço da resposta a dar. No exame seria necessário escrever o código. Aplicando os conhecimentos adquiridos nas aulas de laboratório é necessário definir uma classe serviço, e que pertencerá à camada fina de serviços, semelhante às várias classes serviços definidas durante o projeto. Esta classe será responsável por determinar o número de pratos em que cada cliente VIP registou interesse utilizando as funcionalidades disponibilizadas pela camada de domínio.
Número: Pág. 11/11 25. (2.0) Considere o serviço desenvolvido na questão anterior. Indique os vários casos de teste que devem ser desenvolvidos para testar este serviço. Solução: Atenção, esta resposta é apenas um esboço da resposta a dar. Aplicando os conhecimentos adquiridos nas aulas de laboratório é necessário indicar quais os vários casos de teste a desenvolver. Cada caso de teste deve exercitar uma situação potencilamente distinta do serviço a testar. Não é necessário indicar o código do teste, apenas a descrição de cada situação a testar.