Engenharia de Software

Transcrição

1 UNIVERSIDADE DE LISBOA INSTITUTO SUPERIOR TÉCNICO Engenharia de Software LEIC/LETI, 3 o Ano, 2 o Semestre Repescagem do 1 o Teste, 1 de Julho de 2016 Nome: Número: Este teste tem um conjunto de 10 perguntas de escolha múltipla, e um conjunto de 3 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 teste. 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,2; 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. 11: 12: 13:

2 Número: Pág. 2/7 Perguntas de escolha múltipla 1. Na gestão de configurações de Software, uma configuração é: A) Um conjunto de versões relacionadas de diferentes artefactos. B) Um conjunto de versões relacionadas do mesmo artefacto. C) Um conjunto de todas as credenciais relacionadas com os membros de uma mesma equipa. D) O conjunto dos parâmetros de ferramentas relacionadas, empregues na tarefa de construção privada do sistema. 2. Durante a execução de um sprint na metodologia ágil Scrum: A) O cliente não pode fazer nenhuma alteração dos requisitos do sistema. B) O cliente pode fazer alterações aos requisitos mas essas alterações não são consideradas no sprint actual. C) Alterações aos requisitos feitas pelo cliente são bem-vindas e são incorporadas no sprint actual. D) Não existe qualquer restrição ou indicação sobre a possibilidade de o cliente fazer alterações aos requisitos. 3. Indique qual das seguintes frases é verdadeira: A) Nos sistemas de tipo P o problema varia ao longo do tempo. B) Quando um sistema do tipo E termina de ser desenvolvido e entra em produção é necessário desenvolver um novo sistema. C) Nos sistemas de tipo S é necessário definir uma abstração. D) É possível especificar formalmente o problema de um sistema do tipo E. 4. É vantajoso utilizar um sistema de gestão de configurações num projecto que tenha um único programador: A) Para se manter habituado a usar este tipo de ferramentas. B) Para tirar partido dos mecanismos de reversão de código. C) Para evitar acessos ao sistema de ficheiros. D) Para permitir distribuir o código pelos clientes do projeto. 5. No modelo de gestão de uma equipa de desenvolvimento Ágil, o código tipicamente tem uma qualidade elevada uma vez que: A) Existe uma divisão clara entre o código de cada programador. B) Existem testers na equipa que indicam como melhorar o código. C) Existem code reviewers que são responsáveis por manter o código. D) O código é mantido colectivamente.

3 Número: Pág. 3/7 6. Indique qual das seguintes frases é verdadeira: A) Testes de aceitação são realizados pela equipa de desenvolvimento e aceites pelo cliente. B) Não se devem testar entradas inválidas, só se deve considerar para os testes entradas válidas do componente que está a ser testado. C) O facto de os testes executados sobre um sistema não falharem não implica que o sistema esteja correto. D) Todas as frases anteriores são falsas. 7. A utilização de asserções e a utilização de exceções distinguem-se pois: A) Nas asserções pode ser incluído código de funcionalidade. B) O objetivo das asserções é serem usadas para identificar casos de teste para o programa. C) As exceções podem ser usadas quando se pretende que o programa trate de uma situação de erro. D) As exceções devem ser usadas para implementar funcionalidade no bloco de tratamento de exceção (catch). 8. No projeto deste ano da disciplina Engenharia de Software, MyDrive, foram aplicados os seguintes padrões arquiteturais: A) Repositório e camadas. B) Cliente-servidor, camadas, repositório e canais-e-filtros. C) Arquitectura empresarial. D) Modelo-vista-controlador, repositório, cliente-servidor e camadas. 9. As normas de software para o controlo de qualidade: A) Em geral, são bem recebidas pelas equipas pois não implicam mais trabalho. B) Embora identifiquem erros do passado, não são aplicáveis a projetos em desenvolvimento. C) Permitem assegurar a continuidade do projeto face a alterações da equipa. D) A norma ISO9001 é muito utilizada por permitir garantir uma bateria de testes completa. 10. É vantajoso efectuar uma análise Post-Mortem para: A) Identificar quais os elementos da equipa do projecto que são menos produtivos. B) Poder dizer ao cliente qual foi o custo de cada uma das tarefas realizadas. C) Definir os próximos passos de levantamento de requisitos. D) Identificar possíveis riscos em projectos futuros.

4 Número: Pág. 4/7 Perguntas sobre a componente prática O projeto MYDRIVE desenvolvido durante a execução da disciplina de Engenharia de Software permite a criação e gestão de um sistema de ficheiros transacional hierárquico onde os utilizadores manipulam ficheiros e diretorias. Suponha agora que se pretende acrescentar os seguintes requisitos: A aplicação deve suportar proteções de grupo nos ficheiros. Para tal, passa a existir o conceito de grupo, com um nome de grupo único no sistema, constituído por uma cadeia de carateres com pelo menos 5 carateres. Um grupo tem de pertencer a pelo menos um utilizador. Cada ficheiro pertence a um só grupo e cada utilizador pode pertencer no máximo a 10 grupos.

5 Número: Pág. 5/7 11. (2) Altere o domínio da aplicação MYDRIVE, 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, File, Manager, Dir e Plain 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: class Group { String name; String permission; relation UserHasGroup { User playsrole user { multiplicity 1..*; Group playsrole group { multiplicity 0..10; relation ManagerHasGroup { Manager playsrole manager; Group playsrole group { multiplicity *; relation FileHasGroup { File playsrole file { multiplicity *; Group playsrole group;

6 Número: Pág. 6/7 12. (2.0) Tendo em conta a arquitetura em camadas aplicada no desenvolvimento da aplicação MYDRIVE, 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 novos requisitos. O código realizado no domínio da aplicação deve estar protegido contra utilização indevida por parte dos programadores que utilizam as classes do domínio. NOTA: Assuma 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: public class Group extends Group_Base { public Group(String name, User u) { setname(name); adduser(u); setmanager(u.getmanager()); public void removeuser(user u) { // if not in DML if (getuserset().size() == 1) throw new RuntimeException("Can not remove last user of group"); super.removeuser(u); public void setpermission(string perm) { if (perm.length()!= 4!perm.matches("[r-][w-][x-][d-]")) throw new RuntimeException("Invalid permissions"); super.setpermission(perm); public void setmanager(manager m) { m.addgroup(this); public void setname(string name) { if (name.length() < 5) throw new RuntimeException("Group name too short: "+ name); super.setname(name); public class Manager extends Manager_Base { /*... */ public void addgroup(group grp) { for (Group g: getgroupset()) if (grp.getname().equals(g.getname())) throw new RuntimeException("Duplicate group name: "+grp.getname()); super.addgroup(grp);

7 Número: Pág. 7/7 13. (1) Considere os requisitos concretizados na pergunta anterior em conjunto com os definidos no projeto que se aplicam à criação de um grupo. Indique os vários casos de teste que devem ser desenvolvidos para testar esta funcionalidade. Solução: sucesso : criar grupo com nome não existente, com 5 ou mais carateres, associado a um utilizador com menos de 10 grupos; nome muito curto : criar com nome de comprimento inferior a 5 carateres; nome de grupos duplicado : criar um grupo com nome já existente; sem utilizador : criar um grupo sem utilizador válido (null User or nonexisting username); número de grupos excedidos : adicionar o grupo a um utilizador que já contém 10 grupos. Matriz das perguntas de escolha múltipla (4 versões): pergunta A B C D 1 A C B D 2 B A C D 3 B A C C 4 B A D C 5 D B C A 6 C D A B 7 C D A B 8 A D C B 9 C D A B 10 D B D A