Engenharia de Software LEIC/LERC, 3 o Ano, 2 o Semestre, Ano lectivo de 2009/2010

Transcrição

1 UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO Engenharia de Software LEIC/LERC, 3 o Ano, 2 o Semestre, Ano lectivo de 2009/2010 Primeiro Exame 28 de Junho de 2010, 9:00H 11:30H (Versão A) Nome: Número: Este exame tem um conjunto de 10 perguntas de escolha múltipla, e um conjunto de 9 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 entregar a lápis. Em cima da mesa devem estar: enunciado, caneta e cartão de aluno. Também pode usar lápis e borracha. Não é permitida a utilização de: folhas de rascunho, telemóveis, calculadoras, etc. Leia cuidadosamente as perguntas de escolha múltipla e indique na tabela seguinte a letra correspondente à resposta correcta para cada pergunta. Por favor, use apenas letras maiúsculas. Se não pretender responder a uma determinada pergunta, use um X para representar isso explicitamente. A classificação das perguntas de escolha múltipla é feita da seguinte forma: uma resposta correcta vale 0,5; uma resposta errada vale -0,2; e 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, a não ser que consiga claramente eliminar uma ou duas das respostas. Existe apenas uma única resposta possível para cada pergunta, pelo que deve escolher a que considera mais correcta. Indique na tabela seguinte as suas respostas às perguntas de escolha múltipla:

2 Número: Pág. 2/12 Perguntas de escolha múltipla 1. Uma das vantagens de se definir um modelo de processo de desenvolvimento de software que contempla vários marcos e produtos intermédios é: A) Acelerar o desenvolvimento de software, porque cada membro da equipa sabe o que tem a fazer em cada momento. B) Aumentar o paralelismo no desenvolvimento de software, porque podemos ter pessoas diferentes a produzir artefactos diferentes. C) Aumentar a eficiência da comunicação entre os membros da equipa, porque os produtos intermédios eliminam a necessidade de comunicação frequente entre os membros da equipa. D) Aumentar a capacidade de monitorização e gestão do processo de desenvolvimento, porque se aumenta a visibilidade sobre o que está a ser feito. 2. As actividades de um projecto podem ser apresentadas através de um grafo de dependências. Neste grafo de dependências, o Caminho Mais Crítico identifica: A) As actividades que devem ser terminadas a tempo para que o projecto não se atrase. B) As actividades que representam o maior risco para o projecto. C) As actividades que impedem a execução de frentes de trabalho paralelas. D) As actividades que implementam as funcionalidades mais críticas para o utilizador. 3. É frequente, durante o desenvolvimento de um sistema de software, que os requisitos do sistema tenham que ser alterados numa fase avançada do desenvolvimento. Isto acontece porque A) Não foram usadas as boas práticas de Engenharia de Software na passagem dos requisitos para a solução. B) O processo de desenvolvimento de software seguido pela equipa não é o mais correcto. C) É comum existir incerteza sobre as reais necessidades do sistema no início do seu desenvolvimento. D) O processo de levantamento de requisitos não validou os requisitos. 4. A lei de Brooks diz que Adicionar pessoas a um projecto que já se encontra atrasado só o vai atrasar mais. Isto acontece porque: A) Se aumentam os custos de comunicação entre os membros da equipa. B) Se aumenta o número de integrações de código que é necessário realizar diariamente. C) Se aumenta o número de testes de integração que é necessário implementar e executar. D) Se aumenta a probabilidade de haver erros na interpretação dos requisitos do sistema.

3 Número: Pág. 3/12 5. Na metodologia ágil Scrum, os ciclos são designados por sprints. Podemos dizer que um sprint se caracteriza fundamentalmente por: A) Ter uma duração fixa e conhecida à partida. B) Durante o seu planeamento, as histórias serem seleccionadas a partir do product backlog pelo product owner. C) Se efectuar a expansão das histórias em tarefas durante a sua execução. D) Todas as anteriores. 6. Na metodologia ágil Scrum, um dos instrumentos fundamentais para efectuar a monitorização é o Sprint Burndown Chart. Olhando para um Sprint Burndown Chart actualizado ao fim do dia, podemos ver: A) O progresso do sprint até esse mesmo dia. B) A velocidade da equipa. C) Os dias já trabalhados e a quantidade de trabalho que falta realizar. D) Todas as anteriores. 7. Suponha que a sua equipa está a usar um sistema de controlo de versões centralizado (como o CVS, por exemplo), e adoptou os padrões Sequência Principal (Mainline) e Linha de Desenvolvimento Activa (Active Development Line) como forma normal de trabalho. Em que situações devem ser criados ramos (branches) novos de desenvolvimento? A) Sempre que um erro é identificado na sequência principal. B) Sempre que duas pessoas da equipa quiserem colaborar no desenvolvimento de uma funcionalidade. C) Sempre que uma parte da equipa pretender efectuar um desenvolvimento que pode ser disruptivo ou longo. D) Sempre que se for dar início ao desenvolvimento de uma nova funcionalidade. 8. Um dos problemas de desenho que um sistema pode exibir é designado por code scattering, que diz respeito à forma como um determinado aspecto do sistema se encontra implementado. Quando isto acontece relativamente a um determinado aspecto do sistema, isso significa que A) A execução do sistema torna-se mais lenta no que diz respeito a esse aspecto. B) A reutilização desse aspecto noutros sistemas torna-se mais difícil. C) O código que implementa esse aspecto encontra-se intercalado com o código de outros aspectos nas várias funções do sistema. D) Os testes do sistema tornam-se mais difíceis de realizar.

4 Número: Pág. 4/12 9. O princípio de desenho orientado por objectos Segregação de interfaces (Interface Segregation Principle), diz que se devem criar interfaces específicas para cada um dos vários clientes de uma determinada classe. Seguindo este princípio de desenho A) Aumenta-se a coesão interna da classe que implementa as várias interfaces, tornando-a mais resistente a mudanças que existam noutras partes do sistema. B) Torna-se mais simples realizar testes unitários que verificam o correcto funcionamento das classes implementadas. C) Torna-se mais simples implementar cada classe, porque existe menos código para escrever. D) Diminui-se a ligação existente entre as várias classes, aumentando dessa forma a facilidade de modificação do sistema. 10. Um hipotético pedido para o sistema Fénix do tipo O sistema deve executar rapidamente todas as operações que sejam solicitadas pelos seus utilizadores : A) Não é um requisito porque não é passível de ser testado para aferir sobre a sua satisfação na fase de validação e verificação de software. B) Não é um requisito porque não descreve nenhuma funcionalidade que o sistema deva suportar. C) É um requisito perfeitamente válido, desejável, e aceitável para o sistema. D) Não é um requisito porque está escrito em língua natural.

5 Número: Pág. 5/12 Perguntas de resposta aberta 11. (1.5) Ao longo das últimas décadas assistimos à passagem de uma situação em que os maiores custos no desenvolvimento de um sistema informático eram os relacionados com o hardware, para uma situação em que os custos de hardware são marginais quando comparados com os de desenvolvimento do software. Isto deve-se, por um lado, ao enorme aumento do poder computacional disponível a preços cada vez mais baixos, e, por outro lado, ao aumento da complexidade dos problemas abordados. Discuta de que modo estas mudanças influenciaram a forma como os programas são desenvolvidos. 12. (1.5) Os modelos de processo de desenvolvimento de software mais recentes são todos eles iterativos, promovendo o desenvolvimento de um sistema ao longo de várias iterações, ao contrário de modelos como o de cascata. Explique duas das principais vantagens de se usar um processo iterativo.

6 Número: Pág. 6/ (1.5) Na metodologia Extreme Programming (XP), o princípio YAGNI (acrónimo para You ain t gonna need it ) indica que os programadores não devem adicionar funcionalidade a um programa até que ela seja estritamente necessária. Isto significa, em particular, que ao implementar uma determinada funcionalidade, o programa não deve ser feito de forma mais genérica para lidar com outras funcionalidades semelhantes que possam aparecer no futuro. No entanto, muitas vezes, essas funcionalidades semelhantes acabam por aparecer de facto mais tarde, não sendo possível acomodá-las no desenho já existente. Explique sucintamente como é que o XP lida com esta situação de modo a manter uma boa qualidade do programa. 14. (1.5) Um sistema de controlo de versões é uma ferramenta essencial no desenvolvimento de software, não só quando este é desenvolvido por uma equipa, mas também quando é desenvolvido apenas por uma pessoa. Indique, para cada um destes dois cenários, duas das principais razões pelas quais esta ferramenta é útil.

7 Número: Pág. 7/ (1.5) Em Java, a classe java.util.stack é implementada herdando a implementação da classe java.util.vector. Considere que a classe Vector está definida com os métodos void set(int index, Object elem) e Object get(int index) que atribuem e obtêm um elemento de uma determinada posição do vector, respectivamente (assuma que o método set aumenta a capacidade do vector automaticamente). Considere agora que a classe Stack implementa os métodos void push(object element) e Object pop() implementados como se segue: public class Stack extends Vector { private int pos = 0; public boolean isempty() { return pos == 0; } public void push(object item) { set(pos, item); pos += 1; } public Object pop() { if (!isempty()) { Object last = get(pos - 1); pos -= 1; return last; } else return null; } Reescreva a classe Stack de forma a que esta continue a usar a classe Vector, mas sem expor os métodos herdados set e get. Indique o nome da forma de reutilização que utilizou na sua solução.

8 Número: Pág. 8/ (1.5) Indique sucintamente de que forma a adopção de uma norma de codificação por uma equipa de desenvolvimento induz a produção de código com menos bugs. Perguntas sobre a componente prática Tendo como base o sistema FeaRS, alvo do projecto da disciplina, pretende-se introduzir a possibilidade de qualquer utilizador registado alterar a descrição de uma sugestão (mas não o seu nome), mantendo um histórico destas modificações e informação sobre o utilizador que efectuou a última modificação. Inicialmente uma sugestão é criada com data de modificação igual à data de criação, e com o autor da última modificação igual ao autor da sugestão em si. Quando uma alteração à descrição de uma sugestão é feita, deve ser criada uma nova entrada no histórico contendo a descrição anterior, bem como a data da modificação anterior e o autor dessa modificação. Uma vez esta informação guardada procede-se então à actualização da informação da sugestão e apresenta-se o histórico de alterações da sugestão. Deste modo será sempre possível saber: quem criou inicialmente a sugestão (o autor da sugestão) a descrição actual, data da última modificação e seu autor (mantida na sugestão) a descrição e data de qualquer versão anterior, bem como o seu autor (mantida na entrada respectiva do histórico)

9 Número: Pág. 9/ (2.0) Altere o domínio do Fears, com recurso à Fénix Framework, de forma a que a nova informação seja toda adequadamente persistida. NOTA: Os conceitos FeatureRequest e User já se encontram definidos no FeaRS original.

10 Número: Pág. 10/ (2.0) Tendo em conta as melhores práticas de desenvolvimento de aplicações com a STEP Framework, concretize/modifique todas as classes necessárias de forma a permitir que qualquer das interfaces com o utilizador que o FeaRS disponibiliza (Web e WebServices) possa fornecer a funcionalidade de alterar uma sugestão descrita acima. Não é necessário modificar qualquer das interfaces gráficas existentes, apenas garantir que a funcionalidade descrita está disponível para invocação por qualquer camada de apresentação e que retorna a informação adequada. NOTA: Assuma que qualquer classe de excepção que pretenda utilizar já se encontra implementada, não sendo assim necessário concretizá-la. Não precisa de considerar ainda como vai ser apresentada essa funcionalidade ao utilizador.

11 Número: Pág. 11/12

12 Número: Pág. 12/ (2.0) O FeaRS baseia-se no Google Web Toolkit para a sua interface com o utilizador. Assuma que a interface para introdução de dados relativa à alteração da descrição da sugestão já está definida em GWT, incluindo um botão Actualizar descrição sem comportamento associado. Descreva sucintamente o que precisa de fazer para que o utilizador, ao pressionar o botão Actualizar descrição veja numa janela GWT a informação de histórico gerada. Considere que o utilizador já está autenticado no sistema. NOTA: Deve incluir na descrição toda a informação que considerar relevante para que um programador possa concretizar o pedido, referindo as classes, interfaces e outros ficheiros envolvidos no desenvolvimento.