Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Engenharia de Software > Teste 2 - Teoria > Flashcards

Teste 2 - Teoria Flashcards

1
Q

O que é um requisito?

A

Descrição de alto-nível de um serviço, restrição ou especificação funcional.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Para que servem os requisitos?

A

Servem de base a negociações e aos próprios contratos

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Quais são as classes de requisitos?

A

Classe de utilizador e classe de sistema

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Defina a classe de utilizador (requisitos)

A

Serviços e restrições operacionais sob a forma de diagramas ou língua natural para clientes.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Defina a classe de sistema dos requisitos.

A

Documento detalhado das funções do sistema, serviços e restrições operacionais, definindo o que deve ser realizado como parte do contrato.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Nos métodos ágeis, que tipos de requisitos temos?

A

Requisitos incrementais. Devido ao facto de estes mudarem muito frequentemente.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Descreva o desenvolvimentos dos requisitos

A

Análise de requisitos:(Descrever requisitos para clientes e utilizadores
Especificação de requisitos: (detalhar os requisitos e relacioná-los com o desenho da solução)
Verificação de requisitos: Compara o resultado da especificação com a análise inicial.
Representação de requisitos: Axiomática, meta-linguagem, blablabla

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Quais os tipos de requisitos?

A

Requisitos FUNCIONAIS: (Descrevem serviços e funcionalidade e devem ser completos, precisos e consistentes para evitar erros de interpretação.
Requisitos NÃO FUNCIONAIS: (definem propriedades e restrições como fiabilidade, robustez, tempo de resposta…)
Requisitos DE PROCESSO: (definem ambiente de desenvolvimento, linguagem, ferramentas, metodologia de desenvolvimento.
Requisitos DE DOMÍNIO: (ambiente de operação, organizacionais ou externos)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Descreva como se medem os requisitos NÃO FUNCIONAIS:

A 
Velocidade
Dimensão
Fiabilidade
Robustez
Portabilidade
Facilidade de utilização
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Descreva o processo de extração de requisitos

A

Procurar saber dos clientes qual o domínio, serviços e restrições operacionais.
Pode envolver clientes finais, gestores, equipa, peritos…
Actividades do processo (cíclico) [Descoberta, classificação e organização]

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Diga tudo sobre entrevistas

A

ENTREVISTAS NÃO AJUDAM NA COMPREENSÃO DO DOMÍNIO
Entrevistas fechadas ou abertas.
Misturar perguntas de rsp fechada ou aberta
Manter uma perspectiva aberta, ouvir e esclarecer o que é transmitido.
Tentar envolver o entrevistado e usar uma linguagem adaptada.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Diga tudo sobre Etnografia

A

Passar algum tempo a observar e a analisar
regsitar comportamentos sociais e organizacionais
as pessoas n gostam de mudar hábitos de trabalho

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Como se divide a Documentação de requisitos

A 
Prefácio
Introdução
Glossário
Requisitos do utilizador
Arquitectura do sistema
Especificação de requisitos
modelo do sistema
Evolução do sistema
Apêndices
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Porque é importante a validação de requisitos

A

A validação é importante pois erros nos requisitos são caros de corrigir. A validação permite esclarecer e demonstrar o que cliente pretende.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Quais são as perspectivas pelas quais um sistema pode ser visto.

A

EXTERNA: define o que faz parte e o que fica de fora
INTERAÇÃO: entre os componentes do sistema, ou entre o sistema e o seu ambiente
ESTRUTURAL: organização do sistema e estrutura dos dados
COMPORTAMENTAL: comportamento dinâmico (como responde a acontecimentos)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Vantagens da modulação

A

Custo de alteração
Propagação da alteração
Localidade da alteração
Bom desempenho (alta coesão[uma só responsabilidade por módulo] baixa ligação [reduz dependências entre módulos])

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Em que consiste o Princípio de desempenho

A

Os módulos devem estar abertos para extensão e fechados para modificação.
Inversão da dependência(módulos dependem de abstracções)
Segregação da interface
responsabilidade única

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Defina Lei de Demeter

A

Princípio do menor conhecimento(baixa ligação).
A entidade deve lidar com os amigo mais próximos.
Nunca encadear .’s
evitar a.b().c().d()

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Complexidade do sistema

A 
C = S + D
S = SUM( f^2out)
D = SUM( vertice(entradas+saidas)/(Fout + 1))

C: complexidade do sistema
S: complexidade estrutural
D: complexidade dos dados

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Fale sobre abstracções

A

As abstracções dependem do contexto e são independentes da linguagem.
Podem encapsular ou não e podem ter ou não dados partilhados.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Construção de abstracção TOP-DOWN

A 
A partir dos requisitos, do problema para a solução.
Contexto e interação do sistema
desenho da arquitectura
classificação dos objectos em classes
modelos de desenho
especificação da interface
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Construção de abstracção BOTTOM-UP

A

◮ Identificar abstrações: refatorizando a realização (bottom-up)
Generalização a partir de exemplos de código
Evolução da abstracção: quantos mais casos melhor a abstracção
Refatorização: construir abstracções a partir de exemplos do código.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

O que é um padrão de desenho

A

É uma solução normalizada para um problema comum, esta descreve boas práticas, bons desenhos e experiências anteriores.

(O padrão deve ser suficientemente abstracto e combinar herança e polimorfismo)

24
Q

Descreva o padrão Observer

A

Permite a notificação da alteração do estado do objecto a vários clientes.

Um subject mantém uma lista de seus dependentes, chamados de “observers”, e os notifica automaticamente de eventuais mudanças de estado, geralmente, chamando um dos seus métodos

Read more: http://www.linhadecodigo.com.br/artigo/3643/padroes-em-java-observer.aspx#ixzz4AEvCCZy9

25
Q

Padrões de criação

A

◮ Abstract factory: instância de famílias de classes
◮ Builder: separa construção da representação
◮ Factory method: instância de classes derivadas
◮ Object pool: guarda e recicla objetos
◮ Prototype: instância copiada ou clonada
◮ Singleton: classe com uma só instância

26
Q

Padrões estruturais

A

◮ Composite: composição rescursiva de elementos simples e compostos
◮ Decorator: adiciona responsabilidade dinamicamente
◮ Proxy: um objeto em representação de outro
◮ Façade: uma classe representa o sistema todo
◮ Bridge: separa interface de realização
◮ Adapter: emparelha interfaces distintas
◮ Flyweight: partilha eficiente de pequenos objetos
◮ Private class data: restringe acesso a leitura

27
Q

Padrões de comportamento

A

◮ Command: encapsula pedido como objeto
◮ Interpreter: processar elementos de uma linguagem
◮ Null object: funciona como valor por omissão
◮ Observer: notifica classes de alterações
◮ State: altera comportamento com mudanças de estado
◮ Strategy: encapsula algoritmo numa classe
◮ Template method: delega passos de algoritmo
◮ Visitor: define nova operação sem alterar classe
◮ Chain of resposability: passar pedido numa cadeia de objetos
◮ Iterator: acesso sequencial a objetos de coleção
◮ Mediator: simplifica comunicação entre objetos
◮ Memento: guarda e repoe estado interno

28
Q

O que são sistemas legados(legacy systems)

A

São sistemas antigos suportados por linguagens ou tecnologia que deixou de estar disponível.

(dependem de hardware/bibliotecas/merdas fora de uso)

29
Q

Porque motivos a alteração ou substituição de legacy systems é dispendiosa?

A

Substituição:
Ausência de especificação completa || separação entre sistema e negócio || documentação das regras de negócio

Alteração:
utilização de linguagens e ambientes obsoletos
erros, duplicação ou inconsistência dos dados
dificuldade em compreender optimizações.

30
Q

Estratégias de gestão de sistemas legados

A

◮ Estratégias de evolução:
◮ eliminar o sistema e modificar o negócio para que o Sistema não seja necessário (qv)
◮ continuar em operação com manutenção normal (QV)
◮ continuar a manter o sistema ou substituir, se existir substituto (qV)
◮ eliminar, manter ou substituir (Qv)

31
Q

Fórmula para medir a maturidade da instalação

A

A maturidade da instalação = [ Mt−(Fa+Fc+Fd ) ] / Mt
◮ Mt = número de componentes da instalação atual.
◮ Fc = número de componentes modificados na nova instalação.
◮ Fa = número de componentes adicionados na instalação.
◮ Fd = número de componentes removidos na instalação.

32
Q

O que é a Re-engenharia de software

A

Reconstruir ou re-escrever parte de um sistema sem alterar a sua funcionalidade.

Só é aplicável a sistemas que exigem manutenção frequente. [Obriga a um esforço adicional]

33
Q

Quais são as actividades do processo de re-engenharia

A

◮ tradução de código: para uma nova linguagem.
◮ engenharia inversa: analisar o programa.
◮ estruturação: melhoria da estrutura.
◮ modularização: dividir e reorganizar os componentes.
◮ organização dos dados: re-estruturação e limpeza dos dados.

34
Q

O que é o TDD

A

desenvolvimento orientado aos testes (TDD): corrige o código na hora evitando propagação do erro;

35
Q

Enuncie os fluxos de refactorização:

A

◮ desenvolvimento orientado aos testes (TDD): corrige o código na hora evitando propagação do erro;
◮ remover o lixo: deixar o ’local’ sempre mais limpo que quando o encontrou.
◮ simplificação: de código complexo quando já se conseguiu compreender o faz.
◮ preparatório: melhorar o código antes de começar a alterá-lo.
◮ planeado: quando refatorizar é uma história.
◮ longo prazo: quando as alterações são demasiado grandes procurar dividir em refatorizações incrementais ao longo de vários dias.

36
Q

Descreva o processo de refactorização

A

Dividir a alteração em pequenos passos, o mais pequenos possível em que cada passo mantém o sistema a funcionar e fica mais próximo da solução.
◮ testar para garantir que se partiu de um estado funcional
◮ fazer o primeiro passo e testar o resultado
◮ se os testes regressivos falharam, voltar a trás
◮ se todos os testes passaram, passar ao passo seguinte

37
Q

Quando refactorizar abstracções?

A

Deve-se factorizar quando acontece isto:
◮ contrução de abstrações em bottom-up a partir de exemplos de código.
◮ mover partes do código para a abstração dos casos já realizados.

38
Q

Quando refactorizar código?

A

◮ código duplicado;
◮ métodos longos (dividir em métodos menores);
◮ instruções switch/case (usar polimorfismo);
◮ reduzir dependências (entre classes, separar apresentação do domínio);
◮ melhorar a coesão (tirar partido da localidade);
◮ aglutinação de dados (repetição de grupos de atributos em classes ou de grupos de argumentos em métodos);
◮ generalidade especulativa (generalizações não usadas).

39
Q

Quais são os indicadores de refactorização?

A

◮ EXAGEROS: método longo, classe grande, longa lista de parâmetros, abuso de primitivas (defines), grupos semelhantes de variáveis (data clumps);
◮ ABUSOS: instruções switch, atributos temporários, promessas falhadas, classes semelhantes com interfaces distintas;
◮ INIBIDORES: métodos divergentes, hierarquias paralelas, alteração implica mudanças em muitas classes (shotgun surgery);
◮ DISPENSÁVEIS: comentários, código duplicado, código morto, generalidade
especulativa, classes de dados, classes ociosas
◮ AGREGADORES: cadeias de mensagens (lei de Demeter), intermediário, bibliotecas desatualizadas, intimidade exagerada, inveja de atributos

40
Q

Diga (e descreva) as várias técnicas de Refactorização

A

◮ Composição: de métodos (extração, inline), temporários(inline, query, split), substituição (algoritmo, método por objeto), …
◮ Movimentação: mover (método, atributo), classe (extração, inline), …
◮ Organização: nomear constante, encapsular atributo ou coleção, alterar direcionalidade de associações, substituir tipo por state/strategy, …
◮ Expressões condicionais: remover flag, substituir condições por polimorfismo, introduzir asserções e objetos nulos, …
◮ Invocações: adicionar ou remover parâmetro, renomear ou proteger método,
substituir código de erro por exceção, exceção por teste,
◮ Generalização: subir ou descer atributo ou método, extrair subclasse ou superclasse, colapsar hierarquia, substituir herança por delegação (ou vice-versa), …

41
Q

Vantagens da reutilização de código em ES

A

Desenvolvimento mais rápido e confiável, (caso o código seja escrito por especialistas).
Menores custos de desenvolvimento (redução do risco e em conformidade com normas e regras)

42
Q

Desvantagens da reutilização em ES

A

Dificuldade em encontrar e compreender(código/documentação)
Custos de manutenção em especial se o código fonte n for disponibilizado
Tendência para reescrever código

43
Q

Quais as grandes áreas de reutilização

A

Application Frameworks
Software product lines
Commercial off-the-shelf (COTS)
Component based software engineering (CBSE)

44
Q

O que é uma framework?

A

Arquitetura reutilizável de componentes, em geral orientados por objetos, para uma família de aplicações

45
Q

O que é uma Software Product Line?

A

Aplicação genérica, para um domínio específico, que pode ser adaptada ou configurada.

Tem 3 componentes base
◮ Componentes do núcleo: oferecem infraestrutura e não são modificáveis.
◮ Componentes configuráveis: comportamento alterado por parametrização.
◮ Componentes especializáveis: modificáveis ou substituíveis por outras instâncias.

46
Q

Como é feito o desenvolvimento de Product Lines?

A

São desenvolvidas diferentes versões da aplicação para cada plataforma, ambiente (S.O.), processo de negócio ou requisitos dos clientes.

Deve-se optar por uma versão JÁ DESENVOLVIDA, próxima DOS REQUISITOS, RENEGOCIAR requisitos e finalmente ADAPTAR a versão desenvolvendo novos módulos e docs.

47
Q

O que é o Commercial-off-the-shelf (COTS)

A

COTS adapta-se sem modificar código fonte.

Software com caraterísticas genéricas para reutilização em diferentes ambientes.

48
Q

Delegação e herança

A

white-box (herança) ou black-box (delegation)

◮ herança: facilidade de realização.
◮ delegação: número reduzido de dependências na realização.

49
Q

O que é a Component-based Software Engineering (CBSE)

A

Os CBSE’s são fornecedores de serviços autónomos.

Princípios de desenho:
◮ Componentes são independentes e não interferem.
◮ Comunicam por interfaces be definidas, com realização encapsulada.
◮ Substituição de componentes com igual interface.

50
Q

Para que servem as Interfaces Orientadas aos Serviços?

A

Simplificam a integração de aplicações, visto que o acesso `funcionalidade da aplicação se faz através de uma interface normalizada.

[1 Serviço para cada Funcionalidade]

51
Q

Características dos componentes…

A

◮ AGREGABILIDADE: todas as interações exteriores realizam-se através de interfaces públicas.
◮ INSTALÁVEL: opera como fornecedor de serviço autónomo.
◮ DOCUMENTADO: especificação sintática (e semântica) das interfaces.
◮ INDEPENDENTE: dependências devem ser explicitamente indicadas.
◮ NORMALIZADO: modelo de meta-dados, inteface, composição, instalação e
documentação.
(Java Beans, Microsoft COM e .NET, …)

52
Q

Identifique e descreva os Modelos de Processos de Desenvolvimento.

A

◮ Modelos PLANEADOS: atividades são planeadas antecipadamente e o progresso é medido face ao plano.
◮ Modelo da QUEDA DE ÁGUA (WATERFALL): modelo planeado com fases de
especificação e desenvolvimento separadas.
◮ Modelo INCREMENTAL: desenvolvimento, especificação e validação são alternados, podendo ser planeado ou ágil.
◮ Modelo de INTEGRAÇÃO e CONFIGURAÇÃO: o sistema é montado a partir de componentes configuráveis, podendo ser planeado ou ágil.

53
Q

Descreva o modelo Queda de Água(Waterfall)

A

Fases distintas e sequenciais (análise;testes unitários; testes sistema(integração);operação/manutenção)
Cada fase deve estar completa antes de avançar para a seguinte:

54
Q

Descreva o modelo incremental

A

Reduz o custo de incluir alterações com o processo em execução
É difícil medir o progresso, a estrutura tende a degradar-se, contudo, produz resultados mesmo que incompletos mais cedo.

55
Q

Descreva o modelo de Integração e Configuração

A

Baseia-se na reutilização de componentes, que podem ser alterados para cumprir requisitos.
Usa-se frameworks para reutilização de colecções e webservices.

56
Q

Descreva o modelo em Espiral

A

Baseia-se na análise de risco.
O Planeamento é realizado em cada ciclo, sendo que se define restrições, riscos e alternativas em cada fase.
O desenvolvimento/abordagem varia consoante o risco.

57
Q

Falta esta merda do RUM (Rational Unified Modeling)

A

Perspetivas:
◮ dinâmica: fases ao longo do tempo;
◮ estática: processo dentro de cada atividade;
◮ prática: regras de boas práticas a usar;
Fases:
◮ Conceção: identificação de entidades exteriores e suas interações;
◮ Elaboração: conceção do problema, definição da arquitetura, identificação
dos risco e planeamento;
◮ Construção: desenho, teste, programação e documentação do sistema;
◮ Transição: movimentação do sistema para o ambiente real;

Engenharia de Software (3 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions