INSTITUTO SUPERIOR TÉCNICO
Engenharia de Software
LEIC/LERC, 3
oAno, 2
oSemestre, 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:
1. 6. 2. 7. 3. 8. 4. 9. 5. 10.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 desenvolvi-mento do sistema e se tem mais conhecidesenvolvi-mento 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 é bem-vinda.
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.
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 dispen-diosas.
B)Permitir efectuar commits frequentes dispensando a integração privada.
C)Permitir a qualquer membro da equipa de desenvolvimento criar rapida-mente o seu próprio ramo.
D)Permitir a qualquer membro da equipa de desenvolvimento inicializar rapi-damente 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ís-ticas.
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 manu-tenção.
9.Um requisito diz-se rastreável se é facilitador da sua identificação em versões subsequen-tes 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 algo-ritmo.
Perguntas de resposta aberta
11.(1.5) Muitas das práticas propostas na área de Engenharia de Software correspondem à adap-taçã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 dife-renç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 in-dividualmente ou em pequenos grupos, antes de serem integrados, para facilitar a iden-tificaçã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.
13.(1.5) Uma das soluções de desenho mais usada ao nível da arquitectura de software é a ar-quitectura de camadas. Indique duas das principais vantagens de uma arar-quitectura 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.
15.(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 deco-rator 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 simpli-ficada 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.
16.(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.
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, po-dendo 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 univo-camente) e um único utilizador responsável, podendo também estar por sua vez organi-zada 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 infor-mação seja toda adequadamente persistida.
18.(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 re-lativa à unidade orgânica criada ou as excepções NameAlreadyExistsException e UserCannotManageUnitExceptionrespectivamente quando o nome da unidade or-gânica já existe, ou o utilizador não pode ser responsável pela unidade oror-gânica.
NOTA: Não precisa de considerar ainda como vai ser disponibilizada essa funcionali-dade ao utilizador final, nem concretizar as classes de excepção descritas.
19.(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 utili-zador 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 defi-niu 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 selec-cionar 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 re-sultado da operação.
