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 Segundo Exame 16 de Julho 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. A parte do planeamento de projecto que inclui a identificação das tarefas a realizar, quais as suas pré-condições, âmbito, e duração: A) Só é útil para processos de desenvolvimento clássicos (não ágeis), em que é necessário fazer estimativas de custos à partida e atribuição de trabalho. B) Não se aplica a processos de desenvolvimento ágeis iterativos e incrementais quando cada ciclo de desenvolvimento é inferior a duas semanas. C) É feita no Scrum apenas na fase inicial do processo de desenvolvimento, quando se constrói o product backlog. D) Deve ser realizada em todos os processos de desenvolvimento em que estejam envolvidas várias pessoas. 2. A monitorização de um projecto de desenvolvimento de software: A) Permite comparar o progresso real face ao planeado. B) Permite ao cliente determinar a data-fim do projecto. C) Permite aos programadores determinar as tarefas que têm pendentes. D) Todas as anteriores. 3. Na metodologia de gestão de projecto e desenvolvimento de software Scrum, os sprints: A) Devem ter todos a mesma duração, para facilitar a calibração da velocidade da equipa. B) Devem ir aumentando de duração à medida que se avança no desenvolvimento do sistema e se tem mais conhecimento sobre a velocidade da equipa. C) Devem ter uma duração que depende das funcionalidades que se pretendem implementar nesse sprint. D) Devem ter uma duração mais curta nas fases finais do projecto para permitir maior velocidade na correcção dos erros identificados pelos testes. 4. Um dos princípios subjacentes às metodologias ágeis de desenvolvimento de software é que: A) A mudança dos requisitos durante o desenvolvimento do sistema é bemvinda. B) Não se deve produzir qualquer tipo de documentação do sistema, para não atrasar o processo de desenvolvimento. C) O código deve ser desenvolvido rapidamente para aumentar a satisfação do cliente. D) A etapa de desenho da arquitectura do sistema é desnecessária porque em qualquer momento se pode alterar a arquitectura do sistema.

3 Número: Pág. 3/12 5. Nas metodologias de desenvolvimento de software ágeis, como o Scrum ou o XP: A) Não se realizam testes ao sistema, visto que cada iteração é muita curta. B) Apenas se realizam testes unitários para evitar regressões em novas iterações. C) Realizam-se testes de aceitação em cada iteração. D) Realizam-se testes funcionais mas não testes aos requisitos de qualidade. 6. Na gestão de configurações de software, a utilização de uma Linha Principal Activa (Active Mainline) tem por objectivo: A) Minimizar as operações de fusão de ramos (merges) visto estas serem dispendiosas. B) Permitir efectuar commits frequentes dispensando a integração privada. C) Permitir a qualquer membro da equipa de desenvolvimento criar rapidamente o seu próprio ramo. D) Permitir a qualquer membro da equipa de desenvolvimento inicializar rapidamente o seu repositório privado. 7. Duas importantes métricas da qualidade do desenho são a coesão (cohesion) e a ligação (coupling). Um sistema de software em que os módulos exibem uma coesão alta mas que tenham uma ligação fraca: A) Tem um custo de manutenção elevado e necessita de refactoring para baixar a coesão. B) É mais fácil de manter por comparação a outro que não tenha estas características. C) Não pode ser facilmente testado devido à sua baixa ligação, face a outro que tenha ligação mais elevada. D) Todas as anteriores. 8. Pode afirmar-se que existe um conjunto de princípios que promovem a qualidade do desenho de software. Um destes princípios é o princípio Aberto-Fechado. Segundo este princípio: A) Os módulos devem ser abertos para extensão e fechados para alteração. B) Os módulos devem ser abertos para manutenção e fechados para alteração. C) Os módulos devem ser abertos para desenvolvimento e fechados para manutenção. D) Os módulos devem ser abertos para extensão e fechados para teste.

4 Número: Pág. 4/12 9. Um requisito diz-se rastreável se é facilitador da sua identificação em versões subsequentes da documentação e do código. Para ser rastreável cada requisito: A) Deve evitar referir explicitamente os documentos que lhe dão origem. B) Deve possuir um título e um identificador único. C) Deve ser completo e verificável. D) Todas as anteriores. 10. A utilização de protótipos é uma prática comum no desenvolvimento de software, que pode ser utilizada para A) Ajudar no processo de levantamento de requisitos. B) Ajudar na determinação do grau de risco associado ao desenvolvimento de uma parte do sistema. C) Explorar diferentes alternativas de implementação de um determinado algoritmo. D) Todas as anteriores.

5 Número: Pág. 5/12 Perguntas de resposta aberta 11. (1.5) Muitas das práticas propostas na área de Engenharia de Software correspondem à adaptação, com mais ou menos alterações, de práticas utilizadas noutras engenharias. Os primeiros modelos de processo de desenvolvimento de software, tais como o modelo de cascata, são inspirados nos modelos de processos usados na realização de projectos de engenharia de outras áreas. No entanto, hoje em dia, o modelo de cascata é considerado inadequado para a maior parte dos projectos de desenvolvimento de software. Que diferenças existem entre a engenharia de software e as outras engenharias para explicar esta inadequação? 12. (1.5) Em sistemas complexos, é comum que os vários módulos do sistema sejam testados individualmente ou em pequenos grupos, antes de serem integrados, para facilitar a identificação de erros. No entanto, testar um módulo individualmente nem sempre é fácil porque o seu funcionamento depende muitas vezes de outros módulos. Explique como é que o planeamento dos testes de um sistema deve ser feito para minorar este problema. Explique ainda como é que, nos casos em que o problema não pode ser completamente eliminado, se pode testar um módulo que depende de outros módulos que não foram ainda testados.

6 Número: Pág. 6/ (1.5) Uma das soluções de desenho mais usada ao nível da arquitectura de software é a arquitectura de camadas. Indique duas das principais vantagens de uma arquitectura de camadas, relacionando-as com o tipo de ligação (coupling) existente entre as camadas. 14. (1.5) Num desenho object-oriented as duas formas principais de reutilização de código são a herança e a composição. Favorecer a composição face à herança leva, tipicamente, à criação de desenhos mais robustos (i.e., mais resistentes a alterações). Indique porque razão a composição deve ser preferida face à herança.

7 Número: Pág. 7/ (1.5) Suponha que uma equipa de especialistas do IST está a desenvolver o seu próprio driver JDBC. Neste momento estão a implementar a classe ResultSetDecorator, um decorator que implementa a interface java.sql.resultset. Para aumentar a qualidade do código e do desenho, pretendem eliminar o teste com null da implementação de todos os métodos getxxx(int columnindex). Considere a implementação simplificada da interface ResultSet da classe ResultSetDecorator com o método Date getdate(int columnindex) como se segue: public interface ResultSet { Date getdate(int columnindex); // outros métodos getxxx... } public class ResultSetDecorator implements ResultSet { public static final DEFAULT_DATE = new Date(0); // outras declarações... private ResultSet decoratedinstance; ResultSetDecorator(ResultSet s) { decoratedinstance = s; } public Object getdate(int columnindex) { if (decoratedinstance!= null) { return decoratedinstance.getdate(columnindex); } else { return DEFAULT_DATE; } } // outros métodos getxxx... } Refactorize a classe ResultSetDecorator de forma a n ão efectuar a comparação com null. Apresente outras classes que considere necessárias. Indique o nome do padrão de refactorização que utilizou na sua solução.

8 Número: Pág. 8/ (1.5) A maior parte das metodologias ágeis valorizam a colaboração contínua com o cliente. Explique que vantagens tem esta abordagem quer para o cliente, quer para a equipa de desenvolvimento.

9 Número: Pág. 9/12 Perguntas sobre a componente prática O sistema FeaRS permite agrupar sugestões relacionadas em projectos. No entanto, esta organização é plana, não contemplando a estrutura organizacional da instituição em que se insere o sistema. Pretende-se assim introduzir uma hierarquia no sistema FeaRS, podendo um projecto ser responsabilidade directa da instituição (tal como actualmente), ou de uma unidade orgânica da mesma. A instituição em que o sistema FeaRS é instalada passa assim a poder ser organizada em unidades orgânicas. Uma unidade orgânica tem um nome (que a identifica univocamente) e um único utilizador responsável, podendo também estar por sua vez organizada em unidades orgânicas. Um utilizador registado só pode ser responsável por uma única unidade orgânica. Um projecto passa agora a existir no âmbito da unidade orgânica a que diz respeito (ou no âmbito da instituição, se diz respeito directamente à instituição) mantendo-se toda a informação que já lhe estava associada. 17. (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 Project 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 nas diferentes camadas de forma a permitir adicionar a funcionalidade que permite a criação de uma unidade orgânica no contexto de uma unidade orgânica já existente e devolve informação relativa à unidade orgânica criada ou as excepções NameAlreadyExistsException e UserCannotManageUnitException respectivamente quando o nome da unidade orgânica já existe, ou o utilizador não pode ser responsável pela unidade orgânica. NOTA: Não precisa de considerar ainda como vai ser disponibilizada essa funcionalidade ao utilizador final, nem concretizar as classes de excepção descritas.

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. Uma vez desenvolvida a funcionalidade descrita nas alíneas anteriores foi também definida uma interface com o utilizador para que seja possível criar novas unidades orgânicas, recorrendo mais uma vez ao GWT. A interface consiste numa caixa de diálogo em que o utilizador introduz o nome da nova unidade orgânica e escolhe a unidade orgânica de que faz parte (ou nenhuma, caso seja uma unidade orgânica de topo) de entre as várias já definidas; e o utilizador responsável, de entre todos os registados na instituição. Uma vez a informação introduzida o utilizador pode seleccionar o botão Cancelar para anular a operação e fechar a caixa de diálogo, ou Continuar para executar a operação. Caso a invocação seja bem sucedida, a caixa de diálogo será simplesmente fechada, podendo o utilizador continuar a interacção normal com o sistema, caso contrário, será apresentada, na mesma caixa de diálogo uma mensagem de erro indicando o sucedido, mantendo-se a caixa de diálogo visível para que o utilizador possa alterar os dados introduzidos e tentar de novo. Considere a situação em que o FeaRS instalado no IST tem como unidades orgânicas de topo os Departamentos (DEI, DEEC, etc). O utilizador responsável pelo DEEC definiu uma unidade orgânica adicional, chamada Biblioteca, uma vez que é um serviço disponibilizado directamente aos alunos e que pode ser alvo de sugestões de melhoria específicas. No DEI, não tinham sido criadas inicialmente unidades orgânicas, mas, em conversa com o seu homólogo do DEEC, o responsável do DEI chega à conclusão que faz todo o sentido adicionar a unidade orgânica Biblioteca, dado que o DEI também gere a sua própria biblioteca. Indique qual o comportamento observado pelo responsável do DEI no browser ao seleccionar o botão Continuar. Descreva ainda em detalhe qual o fluxo de controlo, desde que o utilizador selecciona o botão Continuar até que é apresentado no browser o resultado da operação.