Exercícios Arquitetura de Sistemas

Prévia do material em texto

1.
		São características que levaram à especificação do Modelo de Componentes CORBA, EXCETO
	
	
	
	Falta de flexibilidade para estender as funcionalidades dos objetos
	
	
	Necessidade da especialização das interfaces (conexões) entre os objetos
	
	
	Dificuldade de configurar e utilizar aplicações em padrões anteriores
	
	
	Requisitos não funcionais eram usualmente especificados junto com o métodos do negócio (funcionais)
	
	
	Necessidade da existência de um mecanismo único de implementação
	
Explicação: 
CORBA (abreviado de Common Object Request Broker Architecture) é a arquitetura padrão criada pelo Object Management Group para estabelecer e simplificar a troca de dados entre sistemas distribuídos heterogêneos. Em face da diversidade de hardware e software que encontramos atualmente, a CORBA atua de modo que os objetos (componentes dos softwares) possam se comunicar de forma transparente ao usuário, mesmo que para isso seja necessário interoperar com outro software, em outro sistema operacional e em outra ferramenta de desenvolvimento. CORBA é um dos modelos mais populares de objetos distribuídos, juntamente com o DCOM, formato proprietário da Microsoft.
	
	
	
	 
		
	
		2.
		A metodologia de gestão deve contemplar quantas fases forem necessárias para conseguir que todas as áreas de conhecimento sejam abordadas de forma a garantir que escopo, tempo, custos e qualidade atinjam os níveis definidos pelas corporações como sendo os ideais. Qual o modelo de desenvolvimento, estas fases da metodologia devem seguir?
	
	
	
	Cascata
	
	
	Cascata com retroalimentação
	
	
	Incremental
	
	
	Espiral
	
	
	Iterativo e incremental
	
Explicação: No modelo Iterativo e Incremental, cada fase é dividida em uma ou mais iterações que visam uma entrega ao final.
	
	
	
	 
		
	
		3.
		Sobre os Componentes de um Sistema, as questões abaixo são verdadeiras, EXCETO:
	
	
	
	Seguindo o princípio da alta coesão, cada componente deve ter no máximo 3 interfaces
	
	
	Devem possuir interfaces bem definidas, preferencialmente uma para cada serviço solicitado
	
	
	Devem ser projetados buscando a alta coesão e o baixo acoplamento
	
	
	Podem ser definidos desde a primeira iteração do projeto de arquitetura
	
	
	O nível de abstração é, geralmente, alto.
	
Explicação: 
Acoplamento e Coesão talvez sejam as características mais importantes de qualquer sistema.
Muitos sistemas são como um Castelo de Cartas.
Assim como o baixo acoplamento, a alta coesão é um dos princípios que devem ser levados em consideração ao se construir um projeto.
Da mesma maneira que o baixo acoplamento, a alta coesão também é dividida em tipos:
Ø Coesão coincidental: o pior tipo de coesão, há nenhuma ou pouca relação construtiva entre os elementos de um módulo, em outras palavras é uma classe inchada, com um punhado de métodos, todos executando tarefas diferentes, sem nenhuma relação com a classe que os implementa.
Ø Coesão lógica: melhor do que a coincidental mas não menos pior em um projeto, semelhante ao acoplamento de controle, onde um módulo faz um conjunto de funções relacionadas e uma das quais é escolhida através de um parâmetro para controlá-lo.
Ø Coesão temporal: os elementos estão agrupados no mesmo módulo simplesmente porque são processados no mesmo intervalo de tempo, semelhante aos arquivos .ini do windows xp, ao iniciar o xp esses arquivos são carregados para iniciar serviços ou aplicativos.
Ø Coesão procedural: o módulo só tem sentido sobre a aplicação associada, sem ela, há dificuldade em entendê-lo, basicamente é a coesão relacionada aos procedimentos executados pelos elementos do módulo.
Ø Coesão de comunicação: um módulo tem coesão de comunicação se os seus elementos usam a mesma entrada ou a mesma saída.
Ø Coesão seqüencial: a saída de um elemento é a entrada de outro e a solução é decompor em módulos menores, isso nós já vimos em tópicos passados, chamado também de acoplamento de dados.
Ø Coesão funcional: Um módulo funcionalmente coeso contém todos os elementos e apenas aqueles necessários para realizar uma única tarefa bem definida.
	
	
	
	 
		
	
		4.
		O gerenciamento de processos refere-se ao conjunto de conhecimentos que serão utilizados para guiar a condução do projeto de desenvolvimento de software. A atividade de desenvolver o termo de abertura do projeto pertence ao gerenciamento de qual grupo de processos?
  
	
	
	
	Iniciação
	
	
	Planejamento
	
	
	Encerramento
	
	
	Execução 
	
	
	Monitoramento e Controle
	
Explicação: Tudo começa com a abertura do termo do projeto, por isso corresponde a primeira etapa que é Iniciação. Na etapa de Planejamento trabalhamos com o desenvolvimento de gerenciamento do projeto. A etapa de execução tem como foco orientar e gerenciar o trabalho do projeto. A etapa de Monitoramento e Controle tem com objetivo realizar o controle integrado de mudanças e Moniotar e controlar o trabalho do projeto. E a etapa de Encerramento visa encerrar o projeto ou fase.
	
	
	
	 
		
	
		5.
		Uma estratégia tradicional para a construção do projeto arquitetural envolve a análise do fluxo (workflow) do sistema. Sobre essa estratégia é correto afirmar:
	
	
	
	Nessa estratégia, as operações são usualmente representadas através de componentes, ordenados de acordo com a sequência dessas operações
	
	
	Todas as afirmações estão erradas
	
	
	Entre todos os cenários possíveis, a arquitetura de sistemas distribuídos não pode ser representada através da análise do fluxo.
	
	
	Essa estratégia dispensa o levantamento de requisitos
	
	
	O objetivo principal dessa análise é definir componentes reusáveis, isto é, componentes que possam ser utilizados também em outros sistemas
	
Explicação: 
Um sistema de gerenciamento de Workflow - WfMS (Workflow Management Systems) é um sistema que define, gerencia e executa workflows com o suporte de um software e cuja ordem de atividades é guiada por uma representação lógicoe ordenada de um fluxode no computador.
	
	
	
	 
		
	
		6.
		Workflow representa a metodologia de desenvolvimento de sistemas baseada na metodologia RUP. Assinale a alternativa que representa a sequência do processo de desenvolvimento.
	
	
	
	Especificação - Coleta de Requisitos- Análise - Codificação - Testes - Implantação
	
	
	Coleta de Requisitos - Análise - Especificação - Codificação - Implantação - Testes
	
	
	Especificação - Coleta de Requisitos - Análise - Codificação - Implantação - Testes
	
	
	Coleta de Requisitos -  Análise - Especificação - Codificação - Testes - Implantação
	
	
	Coleta de Requisitos - Especificação - Análise - Codificação - Testes - Implantação
	
Explicação: 
- Especificação refere-se a especificação das funcionalidades e interfaces do sistemas. Sendo assim, não pode vir antes de Análise.
- Devemos realizar todos os testes antes da implantação do sistema.
- A Especificação refere-se a especificação das funcionalidades e interfaces do sistemas. Sendo assim, não pode vir antes da coleta de requisitos.
- A Especificação refere-se a especificação das funcionalidades e interfaces do sistemas. Sendo assim, não pode vir antes da coleta de requisitos. Outra questão é que devemos realizar todos os testes antes da implantação do sistema.
		1.
		Uma empresa realizou um levantamento de requisitos de um Estacionamento, onde num primeiro momento destacou duas funcionalidades principais:
   - Atendente registra a entrada e saída do veículo, mas é importante frisar que quando o cliente estaciona o veículo ele recebe o ticket onde contém a data e hora de entrada, placa, a cor do veículo e o modelo do carro.
   - Quando o cliente retira o veículo do estacionamento ele recebe o comprovante de pagamento (fatura).
É correto afirmar que:
	
	
	
	Existe um relacionamento do tipo generalização docaso de uso Gerar Fatura para o caso de uso registrar Saída, onde define uma funcionalidade do sistema do ponto de vista do usuário.
	
	
	Existeum relacionamento do tipo include do caso de uso Gerar Fatura para o caso de uso Registrar Saída, onde este é opcional para o comportamento do caso de uso Registrar Entrada.
	
	
	Existe um relacionamento do tipo extend do caso de uso Gerar Fatura para o caso de uso Registrar Saída, onde este é essencial para o comportamento do caso de uso Registrar Entrada.
	
	
	Existe um relacionamento do tipo include do caso de uso Registrar Entrada para o caso de uso Gerar ticket impresso, onde este é essencial para o comportamento do caso de uso Registrar Entrada.
	
	
	Existe um relacionamento do tipo extend do caso de uso Registrar Entrada para o caso de uso Gerar ticket impresso, onde este é essencial para o comportamento do caso de uso Registrar Entrada.
	
Explicação: 
O relacionamento é do tipo include, uma vez que é obrigatório executar o caso de uso gerar ticket impresso, e este é chamado pelo caso de uso registrar entrada.
	
	
	
	 
		
	
		2.
		Considerando as seguintes afirmativas sobre processos de desenvolvimento de software conhecidos como Engenharia de Software Baseada em Componentes (ESBC): I- O ESBC tem ênfase no paralelismo entre tarefas. II- A atividade da Engenharia de Domínio produz uma lista de componentes que podem ser reutilizados. III- O modelo de troca de dados é um dos ingredientes arquiteturais necessários para a atividade de composição de componentes. As afirmativas verdadeiras são: 
	
	
	
	somente II
	
	
	I, II e III
	
	
	somente III
	
	
	somente I
	
	
	somente I e II
	
Explicação: Conseguir relacionar os conceitos de Engenharia de Software Baseada em Componentes (ESBC).
	
	
	
	 
		
	
		3.
		Qual modelo abaixo, sugere uma abordagem sequencial e sistemática para o desenvolvimento de software nos casos em que os requisitos de um problema são bem compreendidos e quando o trabalho flui de forma relativamente linear?
	
	
	
	Modelo Ágil
	
	
	Modelo em cascata
	
	
	Modelo prototipação
	
	
	modelo em espiral
	
	
	Nenhuma das alternativas
	
Explicação: 
O Modelo em Cascata é um modelo de desenvolvimento de software seqüencial no qual o processo é visto como um fluir constante para frente (como uma cascata) através das fases de análise de requisitos, projeto, implementação, testes (validação), integração, e manutenção de software.
	
	
	
	 
		
	
		4.
		Um Analista pretende desenvolver um projeto utilizando UML, e em seus propósitos, verificou a possibilidade de uso de alguns diagramas. Um deles é o Diagrama de Caso de Uso, cujo objetivo é:
	
	
	
	Descrever o modelo de negócio, suas interfaces e as regras de funcionalidades para essas interfaces.
	
	
	Definir as funcionalidades do sistema a ser desenvolvido
	
	
	Apresentar a interação entre componentes.
	
	
	Mapear a troca de mensagens entre objetos.
	
	
	Representar o domínio de dados a serem tratados e armazenados pelo sistema
	
Explicação: 
- O diagrama de funcionalidades de interface que descreve o modelo de negócio, suas interfaces e as regras de funcionalidades para essas interfaces.
- O diagrama de interação de componentes é um diagrama de colaboração utilizado para interação entre componentes.
- O diagrama de sequência representa a troca de mensagens entre os objetos.
- O diagrama de domínio representa o domínio de dados a serem tratados e armazenados pelo sistema
 
	
	
	
	 
		
	
		5.
		Qual o diagrama que permite que o Arquiteto de um sistema modele a estrutura de arquivos de uma aplicação e seus relacionamentos?
	
	
	
	Diagrama de Arquivos
	
	
	Diagrama de Objetos
	
	
	Diagrama de Classes
	
	
	diagrama de Componentes
	
	
	Diagrama de Software
	
Explicação: 
Na UML, os diagramas de componentes mostram a estrutura do sistema de software, que descreve os componentes do software, suas interfaces e suas dependências. É possível utilizar diagramas de componentes para modelar sistemas de software em um alto nível ou para mostrar componentes em um nível de pacote mais baixo.
Esse tipo de diagrama suporta o desenvolvimento com base em componentes no qual um sistema de software é dividido em componentes e interfaces que são reutilizáveis e substituíveis.
Os diagramas de componentes são úteis pelos seguintes motivos: 
· Definir os aspectos executáveis e reutilizáveis de um sistema de software
· Revelar problemas de configuração de software através de relacionamentos de dependência
· Mostrar uma representação precisa de um aplicativo de software antes de fazer alterações ou aprimoramentos
Também é possível utilizar os diagramas de componentes para descrever as seguintes peças físicas de um sistema de software: 
· Os arquivos de código fonte desenvolvidos em um ambiente de desenvolvimento integrado
· Os arquivos executáveis necessários para fornecer um sistema em execução
· Bancos de dados físicos que armazenam informações nas tabelas de um banco de dados relacional ou nas páginas de um banco de dados orientado a objetos
· Sistemas adaptáveis que possuem componentes que migram para equilíbrio de carga e recuperação de defeitos
		1.
		Uma empresa realizou um levantamento de requisitos de um Estacionamento, onde num primeiro momento destacou duas funcionalidades principais:
   - Atendente registra a entrada e saída do veículo, mas é importante frisar que quando o cliente estaciona o veículo ele recebe o ticket onde contém a data e hora de entrada, placa, a cor do veículo e o modelo do carro.
   - Quando o cliente retira o veículo do estacionamento ele recebe o comprovante de pagamento (fatura).
É correto afirmar que:
	
	
	
	Existe um relacionamento do tipo generalização docaso de uso Gerar Fatura para o caso de uso registrar Saída, onde define uma funcionalidade do sistema do ponto de vista do usuário.
	
	
	Existe um relacionamento do tipo include do caso de uso Gerar Fatura para o caso de uso Registrar Saída, onde este é opcional para o comportamento do caso de uso Registrar Entrada.
	
	
	Existe um relacionamento do tipo extend do caso de uso Gerar Fatura para o caso de uso Registrar Saída, onde este é essencial para o comportamento do caso de uso Registrar Entrada.
	
	
	Existe um relacionamento do tipo include do caso de uso Registrar Entrada para o caso de uso Gerar ticket impresso, onde este é essencial para o comportamento do caso de uso Registrar Entrada.
	
	
	Existe um relacionamento do tipo extend do caso de uso Registrar Entrada para o caso de uso Gerar ticket impresso, onde este é essencial para o comportamento do caso de uso Registrar Entrada.
	
Explicação: 
O relacionamento é do tipo include, uma vez que é obrigatório executar o caso de uso gerar ticket impresso, e este é chamado pelo caso de uso registrar entrada.
	
	
	
	 
		
	
		2.
		Considerando as seguintes afirmativas sobre processos de desenvolvimento de software conhecidos como Engenharia de Software Baseada em Componentes (ESBC): I- O ESBC tem ênfase no paralelismo entre tarefas. II- A atividade da Engenharia de Domínio produz uma lista de componentes que podem ser reutilizados. III- O modelo de troca de dados é um dos ingredientes arquiteturais necessários para a atividade de composição de componentes. As afirmativas verdadeiras são: 
	
	
	
	somente II
	
	
	I, II e III
	
	
	somente III
	
	
	somente I
	
	
	somente I e II
	
Explicação: Conseguir relacionar os conceitos de Engenharia de Software Baseada em Componentes (ESBC).
	
	
	
	 
		
	
		3.
		Qual modelo abaixo, sugere uma abordagem sequencial e sistemática para o desenvolvimento de software nos casos em que os requisitos de um problema são bem compreendidos e quando o trabalho flui de forma relativamente linear?
	
	
	
	Modelo Ágil
	
	
	Modelo em cascata
	
	
	Modelo prototipação
	
	
	modelo em espiral
	
	
	Nenhuma das alternativas
	
Explicação: 
O Modelo em Cascata é um modelo de desenvolvimento de software seqüencial no qual o processo é visto como um fluir constante para frente (como uma cascata) atravésdas fases de análise de requisitos, projeto, implementação, testes (validação), integração, e manutenção de software.
	
	
	
	 
		
	
		4.
		Um Analista pretende desenvolver um projeto utilizando UML, e em seus propósitos, verificou a possibilidade de uso de alguns diagramas. Um deles é o Diagrama de Caso de Uso, cujo objetivo é:
	
	
	
	Descrever o modelo de negócio, suas interfaces e as regras de funcionalidades para essas interfaces.
	
	
	Definir as funcionalidades do sistema a ser desenvolvido
	
	
	Apresentar a interação entre componentes.
	
	
	Mapear a troca de mensagens entre objetos.
	
	
	Representar o domínio de dados a serem tratados e armazenados pelo sistema
	
Explicação: 
- O diagrama de funcionalidades de interface que descreve o modelo de negócio, suas interfaces e as regras de funcionalidades para essas interfaces.
- O diagrama de interação de componentes é um diagrama de colaboração utilizado para interação entre componentes.
- O diagrama de sequência representa a troca de mensagens entre os objetos.
- O diagrama de domínio representa o domínio de dados a serem tratados e armazenados pelo sistema
 
	
	
	
	 
		
	
		5.
		Qual o diagrama que permite que o Arquiteto de um sistema modele a estrutura de arquivos de uma aplicação e seus relacionamentos?
	
	
	
	Diagrama de Arquivos
	
	
	Diagrama de Objetos
	
	
	Diagrama de Classes
	
	
	diagrama de Componentes
	
	
	Diagrama de Software
	
Explicação: 
Na UML, os diagramas de componentes mostram a estrutura do sistema de software, que descreve os componentes do software, suas interfaces e suas dependências. É possível utilizar diagramas de componentes para modelar sistemas de software em um alto nível ou para mostrar componentes em um nível de pacote mais baixo.
Esse tipo de diagrama suporta o desenvolvimento com base em componentes no qual um sistema de software é dividido em componentes e interfaces que são reutilizáveis e substituíveis.
Os diagramas de componentes são úteis pelos seguintes motivos: 
· Definir os aspectos executáveis e reutilizáveis de um sistema de software
· Revelar problemas de configuração de software através de relacionamentos de dependência
· Mostrar uma representação precisa de um aplicativo de software antes de fazer alterações ou aprimoramentos
Também é possível utilizar os diagramas de componentes para descrever as seguintes peças físicas de um sistema de software: 
· Os arquivos de código fonte desenvolvidos em um ambiente de desenvolvimento integrado
· Os arquivos executáveis necessários para fornecer um sistema em execução
· Bancos de dados físicos que armazenam informações nas tabelas de um banco de dados relacional ou nas páginas de um banco de dados orientado a objetos
· Sistemas adaptáveis que possuem componentes que migram para equilíbrio de carga e recuperação de defeitos
		1.
		Na especificação dos componentes, as Interfaces identificam como os elementos podem utilizar esses componentes. Entre os elementos que compõem essa identificação estão corretamente identificadas as afirmativas:
I A assinatura, que identifica a forma de acesso à Interface e o retorno esperado 
II A manipulação dos atributos para a realização do serviço oferecido
III A descrição do serviço que deve compor unicamente a Interface
	
	
	
	I, II e III estão corretas.
	
	
	Apenas I e III estão corretas.
	
	
	Apenas II e III estão corretas.
	
	
	I, II e III estão incorretas.
	
	
	Apenas I e II estão corretas.
	
Explicação: 
Todas as afirmativas estão corretas
	
	
	
	 
		
	
		2.
		Com relação aos Requisitos de Software, avalie se as afirmativas a seguir são falsas (F) ou verdadeiras (V):
(     ) Requisitos funcionais são as declarações de serviços que o sistema fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações.
(     ) Requisitos não funcionais são restrições sobre os serviços ou as funções oferecidas pelo sistema, incluindo restrições de timing, sobre o processamento de desenvolvimento e padrões, aplicam-se frequentemente ao sistema como um todo. 
(     ) Requisitos funcionais são aqueles não diretamente relacionados às funções fornecidas pelo sistema, enquanto que os não funcionais descrevem a função do sistema detalhadamente, incluindo as entradas e saídas.
As afirmativas são respectivamente:
	
	
	
	V, F e V. 
	
	
	F, F e V.
	
	
	F, V e F. 
	
	
	V, V e F.
	
	
	V, F e F.
	
Explicação: Requisitos funcionais descrevem a função do sistema detalhadamente, incluindo as entradas e saídas. Já os Requisitos não funcionais são aqueles não diretamente relacionados às funções fornecidas pelo sistema.
	
	
	
	 
		
	
		3.
		Visando obter os requisitos de forma consistente e sem gastar tempo em excesso, o trabalho de levantamento de requisitos deve conter como característica:
  
	
	
	
	Independente do departamento para o qual o sistema será desenvolvido, é necessário conversar com todos os responsáveis de cada departamento.
	
	
	Procure convocar todos os usuários (funcionários), mesmo que não consiga responder sobre cada uma das camadas.
	
	
	Não se preocupe com o tempo da reunião, podendo durar até 5 horas, o importante é o levantamento dos requisitos.
	
	
	Serão realizadas várias reuniões, e para um melhor aproveitamento separar as reuniões por camada de desenvolvimento.
	
	
	Procure realizar somente uma reunião para o levantamento de requisito, com os usuários que consigam responder sobre cada uma das camadas.
	
Explicação: No trabalho de levantamento de requisitos devemos levar em consideração as seguintes características: Duração máxima de 2 horas, No máximo 3 reuniões com cada grupo, Separar as reuniões por camada de desenvolvimento, conforme previsto no conceito de arquitetura de sistemas e Convocação de usuários que consigam responder sobre cada uma das camadas.
	
	
	
	 
		
	
		4.
		A Prototipação é um paradigma da Engenharia de Software que faz uso de protótipos durante o processo de desenvolvimento de software. Não representa uma afirmação verdadeira acerca da Prototipação:
	
	
	
	Permite o refinamento iterativo dos requisitos.
	
	
	Nenhuma das alternativas
	
	
	O cliente é apresentado ao produto nos estágios iniciais do desenvolvimento.
	
	
	Requisitos podem ser derivados dos protótipos.
	
	
	Os protótipos podem apontar funcionalidades que não foram contempladas.
	
Explicação: 
A arquitetura de um protótipo descartável favorece a evolução do protótipo para o produto final. O que não é verdade é que a arquitetura de um protótipo descartável favorece a evolução do protótipo para o produto final.
	
	
	
	 
		
	
		5.
		São requisitos funcionais, exceto
	
	
	
	Calcular faturamento mensalmente
	
	
	Fechamento da compra do cliente deve ter processamento inferior a 10 segundo
	
	
	Gerar gráfico de barra com evolução das despesas nos últimos 12 meses
	
	
	Gerar consulta ou relatório com 10 melhores clientes
	
	
	Registrar cada login e logout de usuário
	
	
	
	 
		
	
		6.
		No desenvolvimento de um software, um técnico se deparou com uma lista de requisitos, na qual identificou corretamente como requisito funcional:
	
	
	
	O sistema deve gerar diariamente, a lista de processos cadastrados naquele dia.
	
	
	O sistema deve estar disponível para o usuário 99% do tempo.
	
	
	Uma operação de inclusão deve ser realizada em no máximo 2 segundos após o usuário confirmá-la.
	
	
	O software deve ser fácil de usar, intuitivo e transparente para o usuário.
	
	
	O sistema deve respeitar as leis presentes na Constituição Federal.
	
Explicação: Todos os demais requisitos são não funcionais, uma vez que abordam performance, usabilidade,..
		1.
		Na especificação dos componentes, as Interfaces identificam como os elementos podem utilizar esses componentes. Entre os elementos que compõem essa identificação estão corretamente identificadas asafirmativas:
I A assinatura, que identifica a forma de acesso à Interface e o retorno esperado 
II A manipulação dos atributos para a realização do serviço oferecido
III A descrição do serviço que deve compor unicamente a Interface
	
	
	
	I, II e III estão corretas.
	
	
	Apenas I e III estão corretas.
	
	
	Apenas II e III estão corretas.
	
	
	I, II e III estão incorretas.
	
	
	Apenas I e II estão corretas.
	
Explicação: 
Todas as afirmativas estão corretas
	
	
	
	 
		
	
		2.
		Com relação aos Requisitos de Software, avalie se as afirmativas a seguir são falsas (F) ou verdadeiras (V):
(     ) Requisitos funcionais são as declarações de serviços que o sistema fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações.
(     ) Requisitos não funcionais são restrições sobre os serviços ou as funções oferecidas pelo sistema, incluindo restrições de timing, sobre o processamento de desenvolvimento e padrões, aplicam-se frequentemente ao sistema como um todo. 
(     ) Requisitos funcionais são aqueles não diretamente relacionados às funções fornecidas pelo sistema, enquanto que os não funcionais descrevem a função do sistema detalhadamente, incluindo as entradas e saídas.
As afirmativas são respectivamente:
	
	
	
	V, F e V. 
	
	
	F, F e V.
	
	
	F, V e F. 
	
	
	V, V e F.
	
	
	V, F e F.
	
Explicação: Requisitos funcionais descrevem a função do sistema detalhadamente, incluindo as entradas e saídas. Já os Requisitos não funcionais são aqueles não diretamente relacionados às funções fornecidas pelo sistema.
	
	
	
	 
		
	
		3.
		Visando obter os requisitos de forma consistente e sem gastar tempo em excesso, o trabalho de levantamento de requisitos deve conter como característica:
  
	
	
	
	Independente do departamento para o qual o sistema será desenvolvido, é necessário conversar com todos os responsáveis de cada departamento.
	
	
	Procure convocar todos os usuários (funcionários), mesmo que não consiga responder sobre cada uma das camadas.
	
	
	Não se preocupe com o tempo da reunião, podendo durar até 5 horas, o importante é o levantamento dos requisitos.
	
	
	Serão realizadas várias reuniões, e para um melhor aproveitamento separar as reuniões por camada de desenvolvimento.
	
	
	Procure realizar somente uma reunião para o levantamento de requisito, com os usuários que consigam responder sobre cada uma das camadas.
	
Explicação: No trabalho de levantamento de requisitos devemos levar em consideração as seguintes características: Duração máxima de 2 horas, No máximo 3 reuniões com cada grupo, Separar as reuniões por camada de desenvolvimento, conforme previsto no conceito de arquitetura de sistemas e Convocação de usuários que consigam responder sobre cada uma das camadas.
	
	
	
	 
		
	
		4.
		A Prototipação é um paradigma da Engenharia de Software que faz uso de protótipos durante o processo de desenvolvimento de software. Não representa uma afirmação verdadeira acerca da Prototipação:
	
	
	
	Permite o refinamento iterativo dos requisitos.
	
	
	Nenhuma das alternativas
	
	
	O cliente é apresentado ao produto nos estágios iniciais do desenvolvimento.
	
	
	Requisitos podem ser derivados dos protótipos.
	
	
	Os protótipos podem apontar funcionalidades que não foram contempladas.
	
Explicação: 
A arquitetura de um protótipo descartável favorece a evolução do protótipo para o produto final. O que não é verdade é que a arquitetura de um protótipo descartável favorece a evolução do protótipo para o produto final.
	
	
	
	 
		
	
		5.
		São requisitos funcionais, exceto
	
	
	
	Calcular faturamento mensalmente
	
	
	Fechamento da compra do cliente deve ter processamento inferior a 10 segundo
	
	
	Gerar gráfico de barra com evolução das despesas nos últimos 12 meses
	
	
	Gerar consulta ou relatório com 10 melhores clientes
	
	
	Registrar cada login e logout de usuário
	
	
	
	 
		
	
		6.
		No desenvolvimento de um software, um técnico se deparou com uma lista de requisitos, na qual identificou corretamente como requisito funcional:
	
	
	
	O sistema deve gerar diariamente, a lista de processos cadastrados naquele dia.
	
	
	O sistema deve estar disponível para o usuário 99% do tempo.
	
	
	Uma operação de inclusão deve ser realizada em no máximo 2 segundos após o usuário confirmá-la.
	
	
	O software deve ser fácil de usar, intuitivo e transparente para o usuário.
	
	
	O sistema deve respeitar as leis presentes na Constituição Federal.
	
Explicação: Todos os demais requisitos são não funcionais, uma vez que abordam performance, usabilidade,..
		1.
		O modelo mais tradicional de desenvolvimento de software é o modelo em cascata. Considerando a utilização desse modelo e suas fases, assinale a alternativa que apresenta uma afirmação verdadeira.
	
	
	
	Nenhuma das alternativas
	
	
	A especificação do sistema é produzida após o estágio de implementação e teste de unidade.
	
	
	A divisão dos requisitos para implementação do sistema em hardware ou software é feita na fase de operação e manutenção.
	
	
	Não há necessidade de se produzir qualquer tipo de documentação em suas fases.
	
	
	O primeiro estágio de desenvolvimento de um novo sistema consiste na definição de requisitos.
	
Explicação: 
O modelo cascata é utilizado principalmente quando os requisitos de um determinado problema são bem compreendidos. Uma forma de utilizar o modelo cascata é quando precisamos fazer adaptações ou aperfeiçoamentos em um sistema já existente. Por exemplo, quando temos um sistema já pronto e precisamos fazer uma adaptação porque alguma lei governamental foi alterada ou criada.
Também podemos utilizar o modelo cascata quando um software necessita de uma nova funcionalidade e os requisitos estão bem definidos e são estáveis.
O modelo cascata também é chamado de ciclo de vida clássico ou tradicional.
Este modelo sugere uma abordagem sequencial e sistemática para o desenvolvimento de software. Dessa forma, começamos com o levantamento de requisitos ou necessidades junto ao cliente, depois vamos para a fase de planejamento onde definimos estimativas, cronograma e acompanhamento, após isso partimos para a modelagem onde fazemos a análise e projeto, seguindo da construção onde codificamos e testamos, passamos para a implantação ou emprego onde efetuamos a entrega, suporte e feedback do software concluído.
	
	
	
	 
		
	
		2.
		Com relação a interação de componentes, avalie se as afirmativas a seguir são verdadeiras (V) ou falsas (F):
(     ) Refinar as interfaces é o subprocesso responsável por revistar o modelo de negócios, alterando e adaptando os elementos na medida das necessidades, já que agora temos as informações das operações de negócio mapeadas e definidas.
(     ) A  modelagem de interação de componentes é uma técnica de modelagem do comportamento dos componentes em relação ao problema a ser resolvido.
(     ) O artefato de operações de negócio é a parte da modelagem de processos de negócios focada nas operações resultantes deste negócio, pois fornece uma solução clara e adaptável para capturar as especificações operacionais dos processos de negócio.
As afirmativas são respectivamente:
	
	
	
	V, F e V. 
	
	
	F, F e V.
	
	
	V, F e F.
	
	
	F, V e V. 
	
	
	V, V e V.
	
Explicação: A primeira sentença é falsa uma vez que não é Refinar as interfaces e sim Refinar as Regras de Negócios. 
	
	
	
	 
		
	
		3.
		O modelo de negócio responde a 4 perguntas básicas: Como? O que? Quanto? Para quem?.
Baseado no modelo de CANVAS de modelo de negócio, identifique a sentença que está associada a pergunta: Como?
	
	
	
	Quais os benefícios se espera alcançar com o novo sistema?
	
	
	Qual o problema a ser resolvido?
	
	
	Quais os elementos de infraestrutura de hardware e Banco de Dados serão utilizados pelo sistema a ser desenvolvido?
	
	
	Quaisrecursos chaves a serem utilizados pelo sistema a ser desenvolvido?
	
	
	Quais são os principais usuários do sistema a ser desenvolvido?
	
Explicação: As sentenças: Quais são os principais usuários do sistema a ser desenvolvido? e Quais os elementos de infraestrutura de hardware e Banco de Dados serão utilizados pelo sistema a ser desenvolvido? estão associado a pergunta Para Quem? Já a sentença Quais os benefícios se espera alcançar com o novo sistema? está ligada a pergunta Quanto? E a sentença Qual o problema a ser resolvido? está relacionada a pergunta O Que?
	
	
	
	 
		
	
		4.
		A identificação de componentes está baseada nas boas práticas da arquitetura de sistemas. Analise as afirmativas abaixo.
I- O modelo conceitual de negócio permite a identificação de interface de sistemas e regras de negócio.
II- O passo seguinte após o desenvolvimento do modelo de negócio é a identificação das interfaces de negócio.
III- A identificação de interface de negócio é baseada no modelo de casos de uso.
De acordo com as afirmativas anteriores, marque a alternativa CORRETA:
	
	
	
	Somente a afirmativa I está correta.
	
	
	Somente a afirmativa III está correta.
	
	
	Somente a afirmativa II está correta.
	
	
	As afirmativas II e III estão corretas.
	
	
	As afirmativas I e III estão corretas.
	
Explicação: A sentença I está incorreta uma vez que é o Modelo de caso de uso que permite a identificação de interface de sistemas e regras de negócios. A sentença III está incorreta uma vez que a identificação de interface de negócio é baseada no modelo conceitual de negócio.
	
	
	
	 
		
	
		5.
		Baseado no modelo CANVAS de modelagem de negócios, separamos o modelo de negócio em grandes grupos que estão associados às seguintes perguntas:
	
	
	
	Por que?, Quando?, Quanto?
	
	
	Quem?, O que?, Quando?, Como?, Onde?
	
	
	Como?, O que?, Para quem?, Quanto?
	
	
	O que?, Onde? Como? Quanto?
	
	
	Como?, Por que?, Quanto?
	
Explicação: São 4 perguntas do modelo CANVAS: Como?, O que?, Para quem?, Quanto?
	
	
	
	 
		
	
		6.
		O processo de identificação de componentes tem como objetivo criar uma visualização inicial de todos os elementos envolvidos e como eles são integrados. Os artefatos gerados a partir desse processo são:
	
	
	
	Interface de Sistemas, Modelos de Casos de Uso, Modelo Conceitual de Negócios.
	
	
	Interface de Negócios, Padrões de Arquitetura, Modelo de Negócio.
	
	
	Interface de Negócios, Padrões de Arquitetura e Modelo Conceitual de Negócios.
	
	
	Modelo de Negócio, Especificação de Componentes e Padrões de Arquitetura.
	
	
	Interface de Negócios, Interface de Sistemas, Especificação de Componentes do Sistema e Modelo de Negócio.
	
Explicação: Modelo Conceitual de Negócio, Modelo de Casos de Uso e Padrões de Arquitetura não são artefatos gerados a partir do processo de identificação de componentes.
		1.
		O modelo mais tradicional de desenvolvimento de software é o modelo em cascata. Considerando a utilização desse modelo e suas fases, assinale a alternativa que apresenta uma afirmação verdadeira.
	
	
	
	Nenhuma das alternativas
	
	
	A especificação do sistema é produzida após o estágio de implementação e teste de unidade.
	
	
	A divisão dos requisitos para implementação do sistema em hardware ou software é feita na fase de operação e manutenção.
	
	
	Não há necessidade de se produzir qualquer tipo de documentação em suas fases.
	
	
	O primeiro estágio de desenvolvimento de um novo sistema consiste na definição de requisitos.
	
Explicação: 
O modelo cascata é utilizado principalmente quando os requisitos de um determinado problema são bem compreendidos. Uma forma de utilizar o modelo cascata é quando precisamos fazer adaptações ou aperfeiçoamentos em um sistema já existente. Por exemplo, quando temos um sistema já pronto e precisamos fazer uma adaptação porque alguma lei governamental foi alterada ou criada.
Também podemos utilizar o modelo cascata quando um software necessita de uma nova funcionalidade e os requisitos estão bem definidos e são estáveis.
O modelo cascata também é chamado de ciclo de vida clássico ou tradicional.
Este modelo sugere uma abordagem sequencial e sistemática para o desenvolvimento de software. Dessa forma, começamos com o levantamento de requisitos ou necessidades junto ao cliente, depois vamos para a fase de planejamento onde definimos estimativas, cronograma e acompanhamento, após isso partimos para a modelagem onde fazemos a análise e projeto, seguindo da construção onde codificamos e testamos, passamos para a implantação ou emprego onde efetuamos a entrega, suporte e feedback do software concluído.
	
	
	
	 
		
	
		2.
		Com relação a interação de componentes, avalie se as afirmativas a seguir são verdadeiras (V) ou falsas (F):
(     ) Refinar as interfaces é o subprocesso responsável por revistar o modelo de negócios, alterando e adaptando os elementos na medida das necessidades, já que agora temos as informações das operações de negócio mapeadas e definidas.
(     ) A  modelagem de interação de componentes é uma técnica de modelagem do comportamento dos componentes em relação ao problema a ser resolvido.
(     ) O artefato de operações de negócio é a parte da modelagem de processos de negócios focada nas operações resultantes deste negócio, pois fornece uma solução clara e adaptável para capturar as especificações operacionais dos processos de negócio.
As afirmativas são respectivamente:
	
	
	
	V, F e V. 
	
	
	F, F e V.
	
	
	V, F e F.
	
	
	F, V e V. 
	
	
	V, V e V.
	
Explicação: A primeira sentença é falsa uma vez que não é Refinar as interfaces e sim Refinar as Regras de Negócios. 
	
	
	
	 
		
	
		3.
		O modelo de negócio responde a 4 perguntas básicas: Como? O que? Quanto? Para quem?.
Baseado no modelo de CANVAS de modelo de negócio, identifique a sentença que está associada a pergunta: Como?
	
	
	
	Quais os benefícios se espera alcançar com o novo sistema?
	
	
	Qual o problema a ser resolvido?
	
	
	Quais os elementos de infraestrutura de hardware e Banco de Dados serão utilizados pelo sistema a ser desenvolvido?
	
	
	Quais recursos chaves a serem utilizados pelo sistema a ser desenvolvido?
	
	
	Quais são os principais usuários do sistema a ser desenvolvido?
	
Explicação: As sentenças: Quais são os principais usuários do sistema a ser desenvolvido? e Quais os elementos de infraestrutura de hardware e Banco de Dados serão utilizados pelo sistema a ser desenvolvido? estão associado a pergunta Para Quem? Já a sentença Quais os benefícios se espera alcançar com o novo sistema? está ligada a pergunta Quanto? E a sentença Qual o problema a ser resolvido? está relacionada a pergunta O Que?
	
	
	
	 
		
	
		4.
		A identificação de componentes está baseada nas boas práticas da arquitetura de sistemas. Analise as afirmativas abaixo.
I- O modelo conceitual de negócio permite a identificação de interface de sistemas e regras de negócio.
II- O passo seguinte após o desenvolvimento do modelo de negócio é a identificação das interfaces de negócio.
III- A identificação de interface de negócio é baseada no modelo de casos de uso.
De acordo com as afirmativas anteriores, marque a alternativa CORRETA:
	
	
	
	Somente a afirmativa I está correta.
	
	
	Somente a afirmativa III está correta.
	
	
	Somente a afirmativa II está correta.
	
	
	As afirmativas II e III estão corretas.
	
	
	As afirmativas I e III estão corretas.
	
Explicação: A sentença I está incorreta uma vez que é o Modelo de caso de uso que permite a identificação de interface de sistemas e regras de negócios. A sentença III está incorreta uma vez que a identificação de interface de negócio é baseada no modelo conceitual de negócio.
	
	
	
	 
		
	
		5.
		Baseado no modelo CANVAS de modelagem de negócios, separamos o modelo de negócio em grandes grupos que estão associados às seguintes perguntas:Por que?, Quando?, Quanto?
	
	
	Quem?, O que?, Quando?, Como?, Onde?
	
	
	Como?, O que?, Para quem?, Quanto?
	
	
	O que?, Onde? Como? Quanto?
	
	
	Como?, Por que?, Quanto?
	
Explicação: São 4 perguntas do modelo CANVAS: Como?, O que?, Para quem?, Quanto?
	
	
	
	 
		
	
		6.
		O processo de identificação de componentes tem como objetivo criar uma visualização inicial de todos os elementos envolvidos e como eles são integrados. Os artefatos gerados a partir desse processo são:
	
	
	
	Interface de Sistemas, Modelos de Casos de Uso, Modelo Conceitual de Negócios.
	
	
	Interface de Negócios, Padrões de Arquitetura, Modelo de Negócio.
	
	
	Interface de Negócios, Padrões de Arquitetura e Modelo Conceitual de Negócios.
	
	
	Modelo de Negócio, Especificação de Componentes e Padrões de Arquitetura.
	
	
	Interface de Negócios, Interface de Sistemas, Especificação de Componentes do Sistema e Modelo de Negócio.
	
Explicação: Modelo Conceitual de Negócio, Modelo de Casos de Uso e Padrões de Arquitetura não são artefatos gerados a partir do processo de identificação de componentes.
		1.
		O gerenciamento do ciclo de vida dos componentes de servidor é feito através de políticas que controlam o momento de ativação/desativação dos componentes. Associe a sentença abaixo ao respectivo conceito.
           " O container ativa o componente, quando for feita a primeira chamada a alguma de suas operações, e desativa, quando explicitamente requisitado pela aplicação, deslocando a memória utilizada pelo componente."
	
	
	
	Component
	
	
	Transaction
	
	
	Container
	
	
	Skeletons
	
	
	Method
	
Explicação: 
Method: Ativação/desativação a cada chamada de método, limitando o uso de memória ao tempo de duração da operação, mas acrescentando o custo de ativação e desativação do componente.
Transaction: Ativação/desativação a cada transação. Memória permanece alocada durante a transação. Container:
O container ativa o componente, quando for feita a primeira chamada a alguma de suas operações, e desativa, quando explicitamente requisitado pela aplicação, deslocando a memória utilizada pelo componente.
	
	
	
	 
		
	
		2.
		Em relação ao Framework CCM (CORBA Component Model) podemos afirmar que:
	
	
	
	O modelo abstrato especifica como os componentes e suas implementações devem ser empacotados.
	
	
	O nível básico provê um conjunto maior de ações, como as portas de comunicação que representam os elementos de conexão entre os componentes.
	
	
	O modelo de programação é Composto pela CIDL (Component Implementation Definition Language) e pelo CIF (Component Implementation Framework).
	
	
	O nível estendido provê uma forma simplificada de distribuir um objeto CORBA como componente.
	
	
	O modelo de Instalação define o ambiente de execução para as instâncias do componente.
	
Explicação: O nível básico provê uma forma simplificada de distribuir um objeto CORBA como componente. O nível estendido provê um conjunto maior de ações, como as portas de comunicação que representam os elementos de conexão entre os componentes. O modelo de empacotamento especifica como os componentes e suas implementações devem ser empacotados. O modelo de execução define o ambiente de execução para as instâncias do componente.
	
	
	
	 
		
	
		3.
		O CCM é um framework de componentes do lado do servidor, cuja finalidade é facilitar o desenvolvimento e a instalação de aplicações distribuídas que utilizam a arquitetura de sistemas por componentes. Dentre os tipos de modelos podemos destacar:
	
	
	
	Modelo Abstrato, Modelo de Análise, Modelo de Projeto, Modelo de Instalação e Modelo de Execução.
	
	
	Modelo Abstrato, Modelo de Programação, Modelo de Padrões, Modelo de Testes e Modelo de Execução.
	
	
	Modelo de Negócio, Modelo de Projeto, Modelo de Padrões e Modelo de Implementação.
	
	
	Modelo Abstrato, Modelo de Programação, Modelo de Empacotamento, Modelo de Instalação e Modelo de Execução.
	
	
	Modelo de Negócio, Modelos de Projeto, Modelo de Testes e Modelo de Implementação.
	
Explicação: 
Os cinco tipos de modelos são: Modelo Abstrato (Define os atributos, portas de comunicação e home dos componentes), Modelo de Programação (Composto pela CIDL (Component Implementation Definition Language) e pelo CIF (Component Implementation Framework), Modelo de Empacotamento (Especifica como os componentes e suas implementações devem ser empacotados), Modelo de Instalação (Define um mecanismo padrão para a instalação de aplicações) e Modelo de Execução (Define o ambiente de execução para as instâncias do componente).
	
	
	
	 
		
	
		4.
		O gerenciamento do ciclo de vida dos componentes de servidor é feito através de políticas que controlam o momento de ativação/desativação dos componentes. Quem é responsável pelo container ativar o componente quando for feita a primeira chamada a alguma de suas operações, e desativa quando explicitamente requisitado pela aplicação, desalocando a memória utilizada pelo componente?
	
	
	
	Transaction
	
	
	Session
	
	
	Method
	
	
	Service
	
	
	Component
	
Explicação: Method - Ativação/desativação a cada chamada de método, limitando o uso de memória ao tempo de duração da operação, mas acrescentando o custo de ativação e desativação do componente. Transaction - Ativação/desativação a cada transação. Memória permanece alocada durante a transação. Session e Service não fazem parte do gerenciamento do ciclo de vida dos componentes de servidor. 
	
	
	
	 
		
	
		5.
		Em relação ao provimento e construção de componentes, analise as afirmativas a seguir:
     I- O arquiteto de sistemas, baseado nos requisitos do novo sistema, vai executar o design da nova aplicação, identificando todos os componentes necessários e aplicando reuso aos componentes que já existirem. Somente serão construídos os componentes que não existirem.
     II- Quanto mais madura a organização (empresa) no conceito de arquitetura de sistemas  maior o conjunto de componentes reutilizáveis ela vai ter, e menor o conjunto de componentes a serem desenvolvidos para resolverem os problemas.
   III - Um componente reutilizado é um componente que já foi testado, é um componente que não tem problemas de desenvolvimentos a serem sanados. Sendo assim, quanto mais a reuzabilidade de código menor o custo , menor o tempo e maior a qualidade.
Assinale:
	
	
	
	se somente as afirmativas I e II estiverem corretas.
	
	
	se somente a afirmativa II e III estiverem corretas.
	
	
	se todas as afirmativas estiverem corretas.
	
	
	se somente a afirmativa I e III estiverem corretas.
	
	
	se somente a afirmativa I estiver correta.
	
Explicação: Todas as afirmativas são verdadeiras.
	
	
	
	 
		
	
		6.
		Os frameworks são os mais indicados para fornecer uma base mais sólida para a próxima geração de aplicativos baseados em componentes distribuídos, em escala empresarial, , avalie se as afirmativas a seguir são verdadeiras (V) ou  falsas (F):
(     ) O Microsoft COM+ possui o Windows como dependência de plataforma, mas não possui nenhuma dependência de Linguagem.
(     ) O Entreprise JavaBeans (EJB) possui tanto dependência de plataforma quanto dependência de Linguagem.
(     ) O Enterprise JavaBeans (EJB) possui a Linguagem Java como dependência de linguagem.
As afirmativas são respectivamente:
	
	
	
	F, V e V. 
	
	
	V, F e F.
	
	
	V, V e V.
	
	
	F, F e V.
	
	
	V, F e V. 
	
Explicação: O Entreprise JavaBeans (EJB) não possui tanto dependência de plataforma, mas possui dependência de Linguagem.
		1.
		Em sistemas distribuídos, componentes podem ser implantados em diversos servidores e sistemas operacionais. É correto afirmar que:
I- CCM descreve componentes e suas dependências usando Open Software Description (OSD), que é um XML Document Type Definition (DTD) definido pelo consórcio www.
II- Package descriptors são documentos OSD em conformidade com o XML e DTD (Document Type Definition),descrevendo o conteúdo da DLL e suas dependências.
III- CCM e OSD também definem component assembly descriptors, que descrevem instruções de implantação e topologia dos componentes, e têm como objetivo o suporte à implantação automática dos componentes.
Marque a opção correta:
  
	
	
	
	Somente a I é verdadeira
	
	
	Somente a III é verdadeira
	
	
	I e II são verdadeiras
	
	
	II e III são verdadeiras.
	
	
	I e III são verdadeiras
	
Explicação: A segunda sentença é falsa uma vez que Package descriptors são documentos XML e não OSD
	
	
	
	 
		
	
		2.
		Sobre heranças de interface e suporte de interfaces, analise as assertivas e assinale a alternativa que aponta a(s) correta(s). 
I. COM+ permite herança múltipla de interface.
II. EJB permite apenas herança única de interface.
      III. EJB permite que classes Java apoiem múltiplas interfaces, limitando apenas unicamente herança de classe.
	
	
	
	Apenas II e III.
	
	
	Apenas II.
	
	
	Apenas III.
	
	
	Apenas I e III.
	
	
	Apenas I.
	
Explicação: COM+ permite apenas herança única de interface. EJB permite herança múltipla de interface. 
	
	
	
	 
		
	
		3.
		Quando se trata de herança de interfaces  e suporte de interfaces é INCORRETO afirmar que:
	
	
	
	COM + permite apenas herança única de interface.
	
	
	No COM+ para permitir que objetos tenham múltiplas classificações, os componentes devem suportar múltiplas interfaces.
	
	
	EJB permite herança múltipla de interfaces e permite que classes Java apoiem múltiplas interfaces, limitando apenas unicamente herança de classe.
	
	
	Quando registramos uma classe Java como um EJB com um ambiente de componentes EJB, ficamos restritos à nomeação de uma interface (a chamada interface remota).
	
	
	Se quiser que seu componente suporte múltiplas interfaces, você vai precisar usar herança de interface múltipla para herdar toda a funcionalidade do componente de uma interface pai, que pode ser registrada no ambiente COM+. 
	
Explicação: 
O ambiente é EJB e não COM+
	
	
	
	 
		
	
		4.
		Marque a afirmativa correta, de acordo com seu material.
	
	
	
	No COM+, a fábrica é o objeto inicial.
	
	
	Tanto no EJB como no COM+ usamos uma abordagem de fábrica de objetos, onde este, é utilizado para criar instâncias de outro componente.
	
	
	No COM+ não há flexibilidade sobre qual  objeto é a fábrica.
	
	
	No COM+, uma propriedade de interface é a especificação abreviada para inout e um set, como um par de operações.
	
	
	No EJB, é objeto IClassFactory.
	
Explicação: 
No EJB, a fábrica é o objeto inicial. C) No COM+, é objeto IClassFactory.
No COM+ há muita flexibilidade sobre qual  objeto é a fábrica. e) No COM+, uma propriedade de interface é a especificação abreviada para um get e um set, como um par de operações.
	
	
	
	 
		
	
		5.
		Considere:
I- Os componentes são empacotados em Arquivos CIF e executados em servidores de componentes.  
II - Os componentes não precisam saber como tratar problemas, como a criação de hierarquia de POAs, e localizar serviços do CCM.
III- As implementações dos componentes dependem dos conceitos da programação orientada a aspectos para encaminhar requisições de clientes para os elementos de servidor.
Em relação à construção dos componentes, está correto o que consta em
 
	
	
	
	I e II, apenas
	
	
	II, apenas
	
	
	I, II e III apenas
	
	
	II e III, apenas
	
	
	I e III, apenas
	
Explicação: A primeira sentença é falsa, uma vez que os componentes são empacotados em arquivos DLL.
	
	
	
	 
		
	
		6.
		Considere as afirmações sobre  especificação de componentes x Construção de componentes:
I- Para lidar com especificação, nós adicionamos alguns estereótipos UML, como especificação de componentes, as classes e suas interfaces.
II- Uma especificação de componente oferece um ou mais tipos de interfaces, por isso há uma correspondência bastante simples entre os elementos de especificação e os elementos de execução.
III - UML também define a relação entre o componente e uma interface através de relacionamentos.
Está correto o que se afirma em
	
	
	
	II e III, apenas
	
	
	I e II, apenas
	
	
	I e III, apenas
	
	
	I, apenas
	
	
	I, II e III.
	
Explicação: 
Todas as afirmativas estão corretas.