Questões

CERTO

ERRADO

Desenvolvimento evolucionário

Prototipação throwaway 

Ciclo de vida do software 

Engenharia de software baseada em componentes 

I;

I e IV;

I, II, III e IV;

I e II;

III e IV.

há um número máximo de componentes em cada sistema.

a substituição de um componente sempre obriga a realização de alterações de porte no sistema afetado.

componentes são independentes, no sentido de que não há interferência entre eles.

na substituição de um componente por outro, sua interface sempre requer alterações.

detalhes da implementação de cada componente são abertos, ou seja, conhecidos por todos os demais componentes do sistema.

CERTO

ERRADO

cada microsserviço deve conter um pipeline completo de treinamento & inferência, garantindo que modelos sejam recalibrados em tempo real. 

todos os microsserviços devem ser configurados para compartilhar estados por meio de sistemas de cache em memória como Redis, garantindo que os modelos de ML sejam consistentes. 

os modelos de ML devem ser desacoplados em microsserviços independentes que executem inferências, enquanto pipelines de treinamento permanecem centralizados. 

é necessário criar microsserviços independentes apenas para serviços de logging e monitoramento, mantendo os modelos acoplados ao backend principal. 

os microsserviços devem ser projetados exclusivamente para ingestão de dados, enquanto modelos de ML devem ser centralizados em um servidor de alto desempenho. 

a criação de componentes deve buscar o alcance do maior grau de variabilidade possível.

um domínio de componentes é formado pelos conceitos usados apenas pelos especialistas da área.

os componentes que formam um domínio de componentes são oportunisticamente reunidos, por meio de análises de variabilidade e dependências contextuais.

um componente de software é uma unidade de composição com interfaces e dependências de contexto contratualmente estabelecidas.

a criação de componentes é organizada de forma reativa.

Estratégia de Tabela por Classe Concreta (Table-per-Concrete-Class Strategy)

Estratégia de Tabela Única (Single-Table Strategy)

Estratégia de Tabela por Subclasse (Table Per Subclass Strategy)

Estratégia de Tabela por Classe Abstrata (Abstract Class Table Strategy)

Estratégia de Junção (Joined Strategy) 

Apenas I.

Apenas II, III e IV.

Apenas I e III.

Apenas I e IV.

I, II, III e IV.

Development React Structured.

Driven Component Divided.

Component Development Structured.

Work Driven Structured.

Component Driven Development.