Teste 2 - Teoria

Question 1

O que é um requisito?

Answer 1

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

Question 2

Para que servem os requisitos?

Answer 2

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

Question 3

Quais são as classes de requisitos?

Answer 3

Classe de utilizador e classe de sistema

Question 4

Defina a classe de utilizador (requisitos)

Answer 4

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

Question 5

Defina a classe de sistema dos requisitos.

Answer 5

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

Question 6

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

Answer 6

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

Question 7

Descreva o desenvolvimentos dos requisitos

Answer 7

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

Question 8

Quais os tipos de requisitos?

Answer 8

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)

Question 9

Descreva como se medem os requisitos NÃO FUNCIONAIS:

Answer 9

Velocidade
Dimensão
Fiabilidade
Robustez
Portabilidade
Facilidade de utilização

Question 10

Descreva o processo de extração de requisitos

Answer 10

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]

Question 11

Diga tudo sobre entrevistas

Answer 11

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.

Question 12

Diga tudo sobre Etnografia

Answer 12

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

Question 13

Como se divide a Documentação de requisitos

Answer 13

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

Question 14

Porque é importante a validação de requisitos

Answer 14

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

Question 15

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

Answer 15

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)

Question 16

Vantagens da modulação

Answer 16

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])

Question 17

Em que consiste o Princípio de desempenho

Answer 17

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

Question 18

Defina Lei de Demeter

Answer 18

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()

Question 19

Complexidade do sistema

Answer 19

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

Question 20

Fale sobre abstracções

Answer 20

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.

Question 21

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

Answer 21

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

Question 22

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

Answer 22

◮ 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.

Question 23

O que é um padrão de desenho

Answer 23

É 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)

Question 24

Descreva o padrão Observer

Answer 24

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

Question 25

Padrões de criação

Answer 25

◮ 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

Question 26

Padrões estruturais

Answer 26

◮ 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

Question 27

Padrões de comportamento

Answer 27

◮ 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

Question 28

O que são sistemas legados(legacy systems)

Answer 28

São sistemas antigos suportados por linguagens ou tecnologia que deixou de estar disponível. (dependem de hardware/bibliotecas/merdas fora de uso)

Question 29

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

Answer 29

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.

Question 30

Estratégias de gestão de sistemas legados

Answer 30

◮ 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)

Question 31

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

Answer 31

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.

Question 32

O que é a Re-engenharia de software

Answer 32

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]

Question 33

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

Answer 33

◮ 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.

Question 34

O que é o TDD

Answer 34

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

Question 35

Enuncie os fluxos de refactorização:

Answer 35

◮ 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.

Question 36

Descreva o processo de refactorização

Answer 36

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

Question 37

Quando refactorizar abstracções?

Answer 37

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.

Question 38

Quando refactorizar código?

Answer 38

◮ 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).

Question 39

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

Answer 39

◮ 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

Question 40

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

Answer 40

◮ 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), ...

Question 41

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

Answer 41

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)

Question 42

Desvantagens da reutilização em ES

Answer 42

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

Question 43

Quais as grandes áreas de reutilização

Answer 43

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

Question 44

O que é uma framework?

Answer 44

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

Question 45

O que é uma Software Product Line?

Answer 45

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.

Question 46

Como é feito o desenvolvimento de Product Lines?

Answer 46

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.

Question 47

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

Answer 47

COTS adapta-se sem modificar código fonte. | Software com caraterísticas genéricas para reutilização em diferentes ambientes.

Question 48

Delegação e herança

Answer 48

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.

Question 49

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

Answer 49

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.

Question 50

Para que servem as Interfaces Orientadas aos Serviços?

Answer 50

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]

Question 51

Características dos componentes...

Answer 51

◮ 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, ...)

Question 52

Identifique e descreva os Modelos de Processos de Desenvolvimento.

Answer 52

◮ 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.

Question 53

Descreva o modelo Queda de Água(Waterfall)

Answer 53

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:

Question 54

Descreva o modelo incremental

Answer 54

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.

Question 55

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

Answer 55

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.

Question 56

Descreva o modelo em Espiral

Answer 56

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.

Question 57

Falta esta merda do RUM (Rational Unified Modeling)

Answer 57

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;