Conforme descrito por Fugita e Hirama (2012), a orientação ...

Próximas questões
Com base no mesmo assunto
Q831029 Arquitetura de Software

Conforme descrito por Fugita e Hirama (2012), a orientação a serviços é um paradigma de construção e integração de soluções de software compostas por elementos modulares, chamados serviços, que se baseiam em princípios os quais caracterizam uma arquitetura SOA (Service Oriented Architecture), tais como:


- a implementação de um serviço pode ser substituída, modificada ou evoluída ao longo do tempo sem causar impactos aos consumidores desse serviço.

- é exigido que a lógica de processamento encapsulada por um serviço fique restrita dentro de certa fronteira estabelecida, o que evita a dependência com relação a outros serviços.


Tais características correspondem, respectivamente, aos seguintes princípios:

Alternativas

Gabarito comentado

Confira o gabarito comentado por um dos nossos professores

A alternativa correta é a D - baixo acoplamento e autonomia.

Vamos entender o porquê:

A questão aborda os princípios fundamentais da arquitetura orientada a serviços, a Service Oriented Architecture (SOA). Esse paradigma de construção e integração de soluções de software é baseado em serviços modulares, que possuem características essenciais para garantir flexibilidade e eficiência no desenvolvimento e manutenção de sistemas.

Para resolver a questão, é necessário compreender dois princípios-chave de SOA:

Baixo acoplamento: Refere-se à capacidade de modificar ou substituir a implementação de um serviço sem impactar seus consumidores. Isso é vital para a evolução dos sistemas, permitindo que mudanças internas não afetem a comunicação com outros serviços ou aplicações. Este conceito é essencial para a modularidade e flexibilidade dos sistemas SOA.

Autonomia: Este princípio assegura que a lógica do processamento de um serviço é encapsulada dentro de limites bem definidos, minimizando dependências externas. Isso significa que um serviço deve operar de maneira independente, sem precisar se preocupar com o estado ou a operação de outros serviços. Essa característica é crucial para garantir que as mudanças em um serviço não causem efeitos colaterais indesejados.

Agora, vamos analisar por que as outras alternativas são incorretas:

A - reusabilidade e granularidade: Estes são princípios também importantes em SOA, mas não são os que correspondem à descrição dada na questão. Reusabilidade se refere à capacidade de um serviço ser utilizado em diferentes contextos, enquanto granularidade está relacionada ao nível de detalhe ou tamanho dos serviços.

B - capacidade de composição e independência de estado: Capacidade de composição é a habilidade de combinar serviços para formar processos mais complexos. Independência de estado diz respeito a como um serviço gerencia seu estado interno. Embora relevantes, não se aplicam diretamente à descrição.

C - contrato padronizado e abstração: Contrato padronizado assegura que os serviços interajam de forma consistente, enquanto abstração esconde detalhes de implementação dos consumidores. Esses princípios não são o foco da questão.

E - interoperabilidade e visibilidade: Interoperabilidade é a capacidade de diferentes sistemas trabalharem juntos, e visibilidade refere-se à capacidade de um serviço ser descoberto e monitorado. Apesar de importantes, não se alinham com a descrição dada.

Esses conceitos são fundamentais para garantir que os sistemas SOA sejam flexíveis, escaláveis e adaptáveis às mudanças ao longo do tempo.

Gostou do comentário? Deixe sua avaliação aqui embaixo!

Clique para visualizar este gabarito

Visualize o gabarito desta questão clicando no botão abaixo

Comentários

Veja os comentários dos nossos alunos

O gabarito é a letra D.

 

Baixo acoplamento: a implementação de um serviço pode ser substituída, modificada ou evoluída ao longo do tempo sem causar impactos aos consumidores desse serviço. 

 

Autonomia: é exigido que a lógica de processamento encapsulada por um serviço fique restrita dentro de certa fronteira estabelecida, o que evita a dependência com relação a outros serviços. 

Baixo acoplamento. No modelo de projeto, é necessário que as classes de projeto colaborem umas com as outras. No entanto, a colaboração deverá ser mantida em um nível mínimo aceitável. Se um modelo de projeto é altamente acoplado (todas as classes de projeto colaboram com todas as outras classes de projeto), o sistema é difícil de implementar, testar e manter com o decorrer do tempo. Um projeto deve levar a componentes que apresentem características funcionais independentes (baixo acoplamento).

Autonomia controlada. A interface deve facilitar a movimentação do usuário pela WebApp, mas deve fazê-lo de forma que faça valer convenções de navegação estabelecidas para a aplicação. Por exemplo, a navegação em trechos de segurança da WebApp deve ser controlada por meio de identificação e senhas de usuário e não deve existir nenhum mecanismo de navegação que possibilite a um usuário evitar tais controles.

Interoperabilidade. Esforço necessário para integrar um sistema a outro.

Reusabilidade. O quanto um programa [ou partes de um programa] pode ser reutilizado em outras aplicações — relacionado com o empacotamento e o escopo das funções que o programa executa.

Correção. O quanto um programa satisfaz a sua especificação e atende aos objetivos da missão do cliente.

Confiabilidade. O quanto se pode esperar que um programa realize a função pretendida com a precisão exigida.

Eficiência. A quantidade de recursos computacionais e código exigidos por um programa para desempenhar sua função.

Integridade. O quanto o acesso ao software ou dados por pessoas não autorizadas pode ser controlado.

Usabilidade. Esforço necessário para aprender, operar, preparar a entrada de dados e interpretar a saída de um programa.

Facilidade de manutenção. Esforço necessário para localizar e corrigir um erro em um programa. [Trata-se de uma definição muito limitada.]

Flexibilidade. Esforço necessário para modificar um programa em operação.

Testabilidade. Esforço necessário para testar um programa de modo a garantir que ele desempenhe a função destinada.

Portabilidade. Esforço necessário para transferir o programa de um ambiente de hardware e/ou software para outro.

TRABALHA E CONFIA!!

Clique para visualizar este comentário

Visualize os comentários desta questão clicando no botão abaixo