Engenharia de Software LEIC/LETI, 3 o Ano, 2 o Semestre, Ano letivo de 2014/2015

Transcrição

1 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 3 de Julho (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): Não preencher. Reservado para a correcção. 21: 22: 23: 24: 25:

2 Número: Pág. 2/12 Perguntas de escolha múltipla 1. Por vezes afirma-se que no desenvolvimento de software existe uma mistura entre perceber qual é o problema e desenvolver uma solução para o mesmo. A) Esta é a perspetiva adequada quando se desenvolve um sistema do tipo P. B) Esta é a perspetiva dos modelos de processo de desenvolvimento em cascata. C) Esta é a perspetiva adequada quando se desenvolve um sistema do tipo S. D) Esta situação verifica-se pois não foi efetuado um bom trabalho de levantamento e especificação de requisitos. 2. A organização de uma equipa de desenvolvimento baseada na tecnologia A) Não é o tipo de organização aconselhado pelas metodologias ágeis. B) Permite que a equipa de desenvolvimento fique focada no cliente. C) Obriga à constituição de uma equipa plana. D) Aumenta o número de canais de comunicação. 3. Em GIT, a operação add aplicada a um ficheiro no estado Untracked A) Mantém o ficheiro no estado Untracked. B) Passa o ficheiro para o estado Unmodified. C) Passa o ficheiro o estado Modified. D) Passa o ficheiro para o estado Staged. 4. De acordo com os padrões de construção de sistema um integration build A) Deve ser feito em cada período de uma hora. B) Pode ocorrer num servidor dedicado, pois pode ter uma duração longa. C) Deve ter uma curta duração. D) Só executa os testes de unidade. 5. Nas abordagens ágeis o planeamento A) É efetuado apenas uma vez, o que acontece no início do projeto. B) Usa a estimativa dada pelo tempo-do-dia anterior (yesterday s weather). C) Não permite a alteração de histórias a implementar durante a execução de um sprint. D) Deve manter-se mesmo que algumas pessoas abandonem o projeto.

3 Número: Pág. 3/12 6. As técnicas de gestão de risco efetuam a prioritização dos riscos durante a fase de A) Identificação do risco. B) Análise do risco. C) Planeamento do risco. D) Monitorização do risco. 7. Num projeto SCRUM, o product owner é responsável por A) Definir a arquitetura do sistema. B) Indicar quais as histórias de maior valor para serem implementadas no próximo sprint. C) Atribuir tarefas aos programadores. D) Definir a data de término do projeto. 8. Os testes de unidade podem usar técnicas de partições de equivalência e análise de valores de fronteira para testar os métodos das classes. A) Estas técnicas são técnicas de teste de caixa-preta. B) A análise de valores de fronteira identifica um valor em cada fronteira entre dois módulos. C) O número de partições de equivalência depende da implementação do método. D) Com uma boa escolha de partições de equivalência consegue-se cobertura de alternativa. 9. A abordagem Test-driven development A) Pode ser definida como uma junção de Test-first com refactorização, em que ora se está a introduzir funcionalidade ou a alterar a estrutura do código. B) Pode ser definida como aplicação da técnica refactorização a uma abordagem top-down de desenho de software. C) Permite uma identificação logo no início do projeto de quais as abstrações que satisfazem todos os requisitos. D) Tem como único objetivo aumentar a legibilidade do código.

4 Número: Pág. 4/ Considere a construção interna da framework JUnit. A utilização do padrão de desenho template method A) Permite que o programador apenas necessite de definir o método run. B) Usa reflexão para garantir a ordem de execução. C) Garante que no início de cada teste é invocado o seu setup e no fim o teardown. D) Define a ordem pela qual executam os casos de teste. 11. Considere o padrão de desenho Composite. A) Existe ligação fraca entre Composite e Leaf. B) Existe ligação forte entre Client e Component. C) Operation() é uma entidade com coesão forte. D) Não existe coesão forte nos elementos deste padrão pois a estrutura está dividida em muitas sub-classes. 12. As descrições dos requisitos funcionais, usando histórias, nas abordagens ágeis A) Servem para guiar o trabalho de implementação dos programadores, dessa forma a descrição da história é suficiente para implementar o requisito. B) Servem para desencadear comunicação entre o cliente e a equipa de desenvolvimento. C) Nunca necessitam de ser alteradas pois a abordagem é ágil. D) Podem ser alteradas mas os requisitos não podem ser removidos pois a abordagem é ágil.

5 Número: Pág. 5/ Considere a especificação de requisitos de segurança. A) A análise da viabilidade de uma técnica de controlo do ataque tem como objetivo identificar novas ameaças. B) Se não se seguir uma abordagem ágil a identificação de ameaças apenas deve ser efetuada antes de implementar o sistema. C) A atividade de identificação de ameaças é permanente, deve ocorrer desde a fase de engenharia de requisitos até à operação do sistema. D) Os requisitos de não-repudiação garantem a integridade dos dados. 14. O padrão arquitetural cliente-servidor A) Tem como ideia principal que os servidores conheçam o endereço dos clientes. B) Tem como desvantagem ser vulnerável a ataques de denial of service. C) Os servidores não podem ser replicados. D) Não suporta facilmente a qualidade da disponibilidade. 15. Proteção e distribuição são as duas principais técnicas arquiteturais usadas para garantir a segurança das aplicações A) Se o objetivo principal de segurança for a confidencialidade dos dados, a proteção sobrepõe-se à distribuição. B) Se o objetivo principal de segurança for a integridade dos dados, a proteção não se aplica. C) Se o objetivo principal de segurança for a disponibilidade, a proteção sobrepõe-se à distribuição. D) Se o objetivo principal de segurança for a usabilidade, a distribuição sobrepõe-se à proteção. 16. Para tratar erros (error handling) podem ser usadas técnicas baseadas em exceções ou em notificações A) A técnica baseada em notificações polui as interfaces dos módulos pois é necessário passar um objeto que recolha os erros. B) A técnica baseada em notificações não permite reportar mais do que um erro de cada vez. C) A técnica baseada em notificações foi a aconselhada para ser usada no projeto. D) A técnica baseada em exceções tem sempre vantagem sobre a técnica baseada em notificações.

6 Número: Pág. 6/ A lei de Lehman de complexidade crescente de um sistema, que indica que com as alterações a estrutura de um programa tende a ficar mais complexa, resulta A) Da equipa de manutenção ter uma grande dimensão. B) De serem efetuadas com frequência atividades de engenharia inversa. C) Dos elementos da equipa de manutenção terem um profundo conhecimento do código do sistema. D) De não serem feitas atividades de refatorização do código. 18. Considerando as forças de estabilidade e progresso de uma linha de código, quando se está a preparar a entrega de uma versão de software e, simultaneamente, se pretende começar a implementar as funcionalidades da entrega seguinte A) Deve ser criada uma nova linha de código que tenha maior estabilidade que a linha de desenvolvimento ativa para a entrega, sendo as novas funcionalidades implementadas na linha de desenvolvimento ativa. B) Deve haver maior estabilidade na linha de desenvolvimento ativa para lá se proceder à preparação da entrega. C) Deve haver maior progresso na linha de desenvolvimento ativa para lá se proceder à preparação da entrega. D) Deve ser criada uma nova linha de código que tenha maior progresso que a linha de desenvolvimento ativa para lá se implementarem as novas funcionalidades. 19. O modelo Cascata de processo de desenvolvimento de software A) Associa a cada etapa a geração de um artefacto de software, ainda que intermédio. B) Melhora a comunicação entre os diferentes stakeholders. C) Promove o feedback rápido por parte dos utilizadores. D) Adapta-se a equipas multi-funcionais. 20. A forma como a abordagem XP lida com o risco de haver uma derrapagem na calendarização A) É fazendo entregas frequentes de curta duração pois assim pode-se detetar a derrapagem imediatamente. B) É fazendo entregas frequentes de curta duração pois assim pode-se acrescentar mais pessoas ao projeto se ele atrasar. C) É testando do ponto de vista do utilizador pois assim sabe-se a qualidade do código e se o projeto está a atingir os objetivos. D) É permitindo que o utilizador altere funcionalidade pois assim o projeto termina sempre na data prevista.

7 Número: Pág. 7/12 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. Uma célula pode ter como conteúdo um literal, uma referência para outra célula da mesma folha ou uma função. Suponha agora que se pretende acrescentar os seguintes requisitos: Noção de grupo. Um grupo representa um conjunto de utilizadores e cada utilizador pertence a um ou mais grupos. Cada grupo tem um nome, a data de criação do grupo e o utilizador que o criou. O nome do grupo identifica univocamente o grupo. A aplicação tem que conhecer todos os grupos que existem. Um utilizador pode criar vários grupos. Um documento pode estar associado (ou não) a um grupo. Caso esteja associado a um grupo, isso significa que os utilizadores que pertencem ao grupo em causa podem ler ou escrever no documento.

8 Número: Pág. 8/ (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, Content, Reference e Range 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. Para representar datas deve ser utilizado a entidade org.joda.time. LocalDateTime. O construtor desta classe cria uma instância que representa a hora actual.

9 Número: Pág. 9/ (1.0) A classe Range definida no projecto representa um intervalo de células de uma folha de cálculo. Considere que a concretização actual desta classe suporta os vários tipos de intervalos: ponto (uma só célula), linha, coluna ou matriz. O seguinte método da classe Range permite indicar o tipo de intervalo: public enum Shape {POINT, LINE, COLUMN, MATRIX}; public Shape getshape() { if (getfirstcell() == getlastcell()) return Shape.POINT; if (getfirstcell().getrow() == getlastcell().getrow()) return Shape.LINE; if (getfirstcell().getcolumn() == getlastcell().getcolumn()) return Shape.COLUMN; } return Shape.MATRIX; Suponha ainda que existem testes de software definidos para esta classe e que a criação de objetos de Range é atualmente feita recorrendo apenas a 4 métodos estáticos (CreatePoint, CreateLine, CreateColumn e CreateMatrix) desta classe. Pretende-se definir 3 subclasses de Range (Point, Line e Column) que irão representar três tipos específicos de Range. A classe Range passará a representar o caso genérico, matriz, de um intervalo. Tendo apenas em conta a funcionalidade do método getshape, indique os vários passos a seguir, de acordo com a técnica de refatorização, para introduzir estas 3 novas subclasses sem que as funcionalidades atuais da aplicação deixem de funcionar.

10 Número: Pág. 10/ (2.5) 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: Criação de um grupo, dado o seu nome e utilizador que o vai criar. Obtenção da instância que representa o grupo com um dado nome. NOTA: Para a concretização desta pergunta, releia com atenção os novos requisitos a concretizar 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.

11 Número: Pág. 11/ (3.0) 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 AddUserToGroup. Este serviço é responsável adicionar um utilizador ao grupo indicado. Este serviço recebe o username do utilizador a adicionar, o nome do grupo e devolve um inteiro com o novo número de elementos que pertencem ao grupo em causa. Por razões de simplificação não é necessário verificar que o utilizador tem uma sessão válida. No caso de o utilizador indicado já pertencer ao grupo referido deve ser lançada a excepção UserAlreadyInGroupException.

12 Número: Pág. 12/ (2.0) Considere o serviço concretizado na pergunta anterior. Indique os vários casos de teste que devem ser desenvolvidos para testar esta funcionalidade.