Aula 01 - Questoes Comentadas

Noções de Informática INSS/TEINF
Questões comentadas
Prof. Alexandre Lênin Aula 1
AULA 1: Análise e Projeto de Sistemas.
SUMÁRIO PÁGINA
1. Resumo 02
2. Questões comentadas 17
3. Lista das questões comentadas na aula 64
4. Gabaritos 79
Prezados amigos,
Sejam bem-vindos ao nosso curso de Conhecimentos específicos

para o certame do INSS - formação em Tecnologia da Informação (código
TEINF). É um curso em EXERCÍCIOS COMENTADOS específico para o
certame do INSS. É um grande prazer poder participar da jornada de
vocês rumo ao serviço público. Primeiramente:
Desejo muito sucesso a todos!!!
Este curso possui o formato de questões comentadas e
recomendo que primeiramente resolvam as questões, utilizando-se da
lista de questões comentadas. Depois, verifiquem os erros e acertos e
leiam os comentários.
Ainda que este curso não tenha a parte teórica, eu gosto de
enviar um resumo ou texto que considero importante para a prova.
Aproveite!
Sempre que precisar, utilize o fórum do nosso curso para enviar
suas dúvidas, críticas e sugestões.
Para refletir:
"Dar menos do que o seu melhor é sacrificar o dom".
Steve Prefontaine
Forte abraço,
Prof. Lênin
Prof. Alexandre Lênin www.estrategiaconcursos.com.br 1/79

1. Resumo
Aspectos da Orientação a Objetos
A expressão “orientado a objetos" significa que o software é organizado

como uma coleção de objetos separados que incorporam tanto a
estrutura quanto o comportamento dos componentes do sistema. Isso
é diferente da programação convencional, em que a estrutura e o
comportamento dos dados têm poucos vínculos entre si.
A orientação a objetos possui diferentes aspectos que a definem, os quais
podem variar de acordo com o autor.
a. Classificação
Classificação significa que os objetos com a mesma estrutura de dados
(chamados atributos) e o mesmo comportamento (chamados operações
ou métodos) são agrupados em uma classe. Classe é uma abstração que
descreve propriedades importantes para uma aplicação e ignora o
restante.
A escolha de classes depende da aplicação. Cada classe descreve um
conjunto possivelmente infinito de objetos individuais e cada objeto é uma
instância de sua classe.
Uma instância da classe tem seu próprio valor para cada atributo,
mas compartilha os nomes de atributos e operações com outras instâncias
da mesma classe.
b. Identidade
Identidade é a subdivisão dos dados em entidades discretas e distintas,
que são objetos. Cada objeto tem sua própria identidade, ou seja, são
distintos mesmo que todos os valores de seus atributos sejam idênticos,
como nome e tamanho, por exemplo.
No mundo real, um objeto limita-se a existir, mas no que se refere a
linguagem de programação, cada objeto possui um único indicador, pelo
qual ele pode ser referenciado sem erros.
c. Ênfase na Estrutura de Objetos

O desenvolvimento baseado em objetos dá maior ênfase na estrutura de
dados (em comparação com a estrutura de procedimentos) do que as
metodologias tradicionais de decomposição funcional.
O desenvolvimento baseado em objetos é similar às técnicas de
modelagem de informações utilizadas no projeto de bancos de dados,
acrescentando o conceito de comportamento dependente da classe.
d. Compartilhamento
O compartilhamento (herança) da estrutura de dados e do seu
comportamento permite que a estrutura comum seja compartilhada por
diversas subclasses semelhantes, sem redundâncias. O desenvolvimento
baseado em objetos não somente permite que as informações sejam

compartilhadas como também oferece a possibilidade da reutilização de

modelos e códigos em projetos futuros.
Uma das principais vantagens das linguagens baseadas em objetos é o
compartilhamento de código com utilização de herança, a qual reduz o
trabalho de codificação e mostra o conceito proveniente de que as
diferentes operações são, na realidade, as mesmas.
e. Polimorfismo
É quando a MESMA operação pode atuar de modos diversos em
classes diferentes. Uma operação é uma ação (ou transformação) que
um objeto executa (ou a que ele está sujeito). Uma implementação
específica de uma operação por uma determinada classe é chamada de
método.
Pode haver mais de um método para a implementação de um operador
baseado em objetos, pois ele é polimórfico.
f. Combinação de dados e o Comportamento

Ao se chamar uma operação, não é necessário considerar quantas
implementações de uma determinada operação existem. O polimorfismo
transfere a responsabilidade da decisão de qual implementação deve ser
utilizada da rotina de chamada para a hierarquia de classes.
g. Encapsulamento
Também conhecido como ocultamento de informações, consiste na
separação dos aspectos externos de um objeto, acessíveis por outros
objetos, dos detalhes internos da implementação daquele objeto.
O encapsulamento impede que um programa se torne tão dependente que
uma pequena modificação possa causar grandes efeitos de propagação.
MODELAGEM ORIENTADA A OBJETOS

A UML (Unified Modeling Language) está formalmente em
desenvolvimento desde 1994, porém, a UML não é uma ideia que partiu
do zero, a UML é uma consolidação de renomadas técnicas retiradas de
metodologias já existentes e bastante praticadas até então.
Devido ao grande uso de suas metodologias, James Rumbaugh (OMT),
Grady Booch e Ivar Jacobson (OOSE, Objectory) uniram-se na Rational
Software para produzir um padrão que unificasse suas notações. Surgiu
então, em 1995, o Unified Method que passou a chamar-se Unified
Modeling Language, ao ser lançada a versão 1.0 em 1997.
A Unified Modeling Language (UML) é a linguagem mais utilizada
atualmente para especificação e projeto de software na abordagem
orientada a objetos. A UML é o instrumento que permite a modelagem do
software “visualmente”, tornando fácil partir dos requisitos do sistema à
implementação de uma forma amigável.
Com a adesão maciça de empresas como IBM, Microsoft, HP, Oracle e
outras, a UML ganhou status de padrão e foi adotada pelo OMG (Object

Management Group, www.omg.org) como linguagem padrão para

modelagem de sistema orientada a objetos em 1997.
O OMG é uma organização mantida por diversas empresas de renome
internacional que administra o padrão UML. A função do OMG é organizar
e divulgar as especificações da linguagem, controlando as solicitações do
que deve ou não ser incluído na arquitetura da linguagem.
1 Utilização da UML
Os principais objetivos da UML são:
 Fornecer aos usuários uma linguagem de modelagem visual
expressiva e pronta para o uso, visando o desenvolvimento de
modelos de produtos de software.
 Fornecer mecanismos para apoiar conceitos essenciais.
 Ser independente de linguagens de programação e processos de
desenvolvimento.
 Encorajar o crescimento no número de ferramentas orientadas a
objeto no mercado.
 Suportar conceitos de desenvolvimento de nível mais elevado tais
como colaborações, estrutura de trabalho, padrões e componentes.
 Integrar no projeto as melhores práticas de desenvolvimento
Orientado a Objetos.
A UML abrange todas as etapas da produção de software, mas
principalmente é utilizada para traduzir os requerimentos do sistema (em
alto nível e mais próximos do usuário) em componentes codificáveis (mais
próximos da aplicação). Mesmo estando entre essas duas camadas, a UML
pretende ser fácil de entender para todos os envolvidos. A UML é uma
linguagem, e como tal, é um meio de comunicação. Através de diagramas
gráficos é mais fácil discutir e visualizar as ideias e soluções entre a
equipe, ou com o usuário.
A utilização da UML permite visualizar melhor as fronteiras de um sistema
e suas funções principais utilizando atores e casos de uso, ilustrar a
realização de casos de uso com diagramas de interação, representar a
estrutura estática de um sistema utilizando diagramas de classe, modelar
o comportamento de objetos com diagramas de estado, e ainda,
representar a arquitetura de implementação física com diagramas de
componente e de implantação.
A UML é, então, uma linguagem destinada a visualizar, especificar,
construir e documentar sistemas complexos de software. Estes sistemas
podem ser empregados em diferentes áreas, como: telecomunicações,
vendas, bancos, Web, entre outros.
2 Diagramas na UML
Um diagrama é a representação gráfica de um conjunto de elementos do
sistema sob uma determinada perspectiva, criando uma projeção do
sistema. Logo, ele representa um modelo (representação abstrata) de
algo real.

b) Visão de Projeto – apresenta como a funcionalidade do sistema será

implementada, ou seja, os serviços que o sistema irá oferecer aos seus
usuários finais. Descreve e especifica a estrutura estática do sistema
(classes, objetos e relacionamentos) e as colaborações dinâmicas quando
os objetos enviarem mensagens uns para os outros para realizarem as
funções do sistema.
c) Visão de Interação – mostra o fluxo de controle entre várias partes

de um sistema, incluindo concorrência e sincronização. Permite assim uma
melhor avaliação do ambiente onde o sistema se encontrará em relação
ao desempenho, escalabilidade e throughput.
d) Visão de Implementação - mostra a organização física

(componentes e artefatos) utilizados na montagem e fornecimento do
sistema e a gerência destes componentes.
e) Visão de Implantação - é a descrição da topologia (nós) em que o

sistema será utilizado, mostrando os computadores e outros periféricos e
como eles se conectam.
4 Análise Orientada a Objetos

O objetivo da Análise Orientada a Objetos é desenvolver uma série de
modelos que descrevem como o software irá se “comportar” para
satisfazer seus requisitos. Logo, a preocupação maior desta fase é
representar “o que” o sistema irá fazer, sem considerar “como”.
Como na Análise Estruturada, constroem-se modelos que representam
diversas perspectivas, descrevendo o fluxo de informações, as funções e o
comportamento do sistema dentro do contexto dos elementos do sistema.
No entanto, diferentemente da Análise Estruturada, aplica-se aqui os
conceitos do paradigma da Orientação a Objetos para realizar-se o estudo
do sistema, buscando-se um desenvolvimento mais adequado.
Seguindo os modelos do processo de software, a Análise Orientada a
Objetos é realizada a partir dos documentos de Especificação de
Requisitos do software, os quais descrevem, principalmente, as
funcionalidades esperadas do sistema.
Nesta fase produz-se um conjunto de diagramas que descrevem as
características do software. Deve-se ressaltar que o emprego dos
diagramas difere de acordo com as características do sistema. Pode-se
ainda desenvolver um Dicionário de Dados descrevendo os componentes
dos diagramas.
Ao final desta fase, se possível, deve-se revisar os documentos
juntamente com representantes do cliente.
Os diagramas produzidos nesta fase são modelos gráficos representativos
do sistema.
 Estrutura Estática;
 Estrutura Dinâmica;

 Comportamento.
Os diagramas gerados podem (e devem) ser empregados para a
prototipação do sistema, podendo-se avaliar se ele cumpre realmente
seus requisitos. Na Análise Orientada a Objetos, podem-se empregar
diferentes diagramas da UML, de acordo com a necessidade do projeto.
Os diferentes diagramas permitem ao Analista observar o software sob
diferentes aspectos – Visões. O emprego de cada diagrama é
determinado de acordo com as características do sistema. A seguir são
estudados alguns destes diagramas.
5 - Diagramas de Caso de Uso

Os Diagramas de Caso de Uso representam um conjunto de sequências de
ações que um sistema desempenha para produzir um resultado
observável de valor para um ator específico.
Os casos de uso descrevem a funcionalidade do sistema percebida por
atores externos. Um ator interage com o sistema, podendo ser um
usuário, dispositivo ou outro sistema.
O Diagrama de Casos de Uso é empregado visando:
 Definir Escopo: um conjunto de Casos de Uso define o escopo do

sistema de uma maneira simples.
 Organizar e dividir o trabalho: o Caso de Uso é uma importante
unidade de organização do trabalho dentro do projeto. A unidade do
Caso de Uso divide o trabalho da equipe entre as pessoas, fora isso, é
comum dizer que o Caso de Uso está em Análise, em Programação ou
em Teste. Casos de Uso também são entregues separadamente aos
usuários em conjuntos divididos em fases ou iterações no projeto.
Então, dizemos que a primeira iteração (ou entrega) terá os seguintes
Casos de Uso e na segunda iteração terá os outros.
 Estimar o tamanho do projeto: o Caso de Uso fornece métricas para
definir o tempo de desenvolvimento.
 Direcionar os testes: os testes do sistema (essencialmente os
funcionais que são os mais importantes) são derivados do Caso de Uso.
A partir dos Casos de Uso, Casos de Teste são criados para validar o
funcionamento do software.
Uma das questões em aberto sobre os Casos de Uso é a confusão que

fazem com o diagrama e a narrativa (texto) do Caso de Uso. Isso porque
a UML define somente como deve ser o Diagrama de Casos de Uso, e não
a narrativa. Desse modo, não há um consenso geral sobre como descrever
a narrativa, existem muitas técnicas e é difícil julgar que uma técnica é
certa e a outra errada, depende muito do projeto, dos seus processos e
ferramentas que você tem à disposição.
Componentes do Diagrama de Casos de Uso

 Atores;
 Casos de Uso; e

6 - Diagrama de Classes
No Diagrama de Classes representa-se a estrutura estática do sistema. O
diagrama é considerado estático porque a estrutura descrita é sempre
válida em qualquer ponto do ciclo de vida do sistema. Este diagrama é
considerado o principal da OOA. Geralmente, a implementação do
software é feita baseando-se no Diagrama de Classes.
O diagrama de classes da UML é o resultado de uma combinação dos
diagramas propostos pela OMT, Booch e vários outros métodos. Consiste
em uma estrutura lógica estática em uma superfície de duas
dimensões mostrando uma coleção de elementos declarativos de modelo,
como classes, tipos e seus respectivos conteúdos e relações.
6.1 Classes
Uma classe é a descrição de um grupo de objetos com propriedades
similares (atributos), comportamento comum (operações ou
métodos), relacionamentos comuns com outros objetos (associações) e
semânticas idênticas.
As classes individuais são representadas na UML como um retângulo
sólido com um, dois ou três compartimentos. O primeiro compartimento é
para o nome da classe e é obrigatório, o segundo e o terceiro
compartimento são opcionais e podem ser usados para listar
respectivamente os atributos e as operações definidas para a classe.
A figura a seguir apresenta uma classe na notação UML.
Nome da Classe
Atributo
atributo: tipo do dado
atributo: tipo do dado = valor inicial
...
Operação
operação (lista de argumentos)
...
Classes são componentes do contexto no qual o software está

inserido. Analisando-se a Especificação de requisitos, deve-se identificar
todos os nomes ou cláusulas nominais. Estes nomes são possíveis classes,
que podem ser:
 Entidades Externas;
 “Coisas”;
 Ocorrências;

 Funções;
 Unidades Organizacionais;
 Lugares; e
 Estruturas.
Após identificar as possíveis classes, deve-se analisá-las para
determinar aquelas que realmente são válidas, de acordo com as
seguintes informações:
 Informação Retida;
 Serviços necessários;
 Múltiplos Atributos;
 Atributos Comuns;
 Operações Comuns;
 Requisitos Essenciais.
Os atributos descrevem um objeto de uma classe em um certo domínio,

contendo informações de estado que precisam ser lembradas. Eles podem
também ser atômicos ou agrupamentos de elementos de dados.
Um atributo é a menor unidade que em si possui significância
própria e é inter-relacionada com o conceito lógico da classe à qual
pertence. Ele é uma característica da classe e não possui comportamento,
pois não é objeto. Nomes de atributos são substantivos simples ou frases
substantivas, devendo ser únicos dentro da classe. Cada atributo deve ter
uma definição clara e concisa.
Cada objeto tem um valor para cada atributo definido dentro de sua
classe. Uma assinatura de atributo representa o tipo de informação que
será armazenado no atributo.
Para identificar os atributos de uma classe determine os nomes da
especificação de requisitos que se relacionam às características de
objetos.
Pergunta básica:
Quais itens de dados (composto e/ou elementares) definem plenamente
esse objeto no contexto em que ele está inserido?
Os métodos realizam diferentes ações nos objetos. Existem 3 categorias
básicas:
 Operações que modificam e descrevem dados;
 Operações que realizam computação;
 Operações de controle.
Para que os métodos de uma classe possam ser identificados devem-se
analisar as ações executadas por objetos das classes (verbos) da
especificação de requisitos.
6.2 Relacionamentos
Os relacionamentos ligam as classes/objetos entre si criando relações
lógicas entre estas entidades. Os tipos principais de relacionamentos no
diagrama de classes:

 Associação - é uma conexão entre classes, e também significa que

existe uma conexão entre objetos daquelas classes. Em UML, uma
associação é definida com um relacionamento que descreve uma
série de ligações, onde a ligação é definida como a semântica entre
as duplas de objetos ligados. Uma associação representa que duas
classes possuem uma ligação (link) entre elas, significando, por
exemplo, que elas “conhecem uma a outra”, “estão conectadas
com”, “para cada X existe um Y” e assim por diante;
 Agregação - tipo especial de associação, em que um objeto é parte

do outro;
 Generalização - é um relacionamento de um elemento mais geral e

outro mais específico. O elemento mais específico pode conter
apenas informações adicionais. Uma instância (um objeto é uma
instância de uma classe) do elemento mais específico pode ser
usada onde o elemento mais geral seja permitido.
Todos estes relacionamentos são mostrados no diagrama de classes

juntamente com suas estruturas internas, que são os atributos e
operações. O diagrama de classes é considerado estático já que a
estrutura descrita é sempre válida em qualquer ponto do ciclo de vida do
sistema.
7 - Diagrama de Sequência
O Diagrama de Sequência representa as interações do sistema como uma
série contínua de mensagens entre os objetos, que colaboram entre si
para produzir um resultado esperado. Este diagrama é utilizado também
para mostrar uma instância de um Caso de Uso.
Dentro de um diagrama de sequência, um objeto é desenhado como um
retângulo no topo de uma linha vertical tracejada projetada para baixo,
chamada linha de vida do objeto.
Cada mensagem é representada por uma linha com seta dirigida
horizontalmente entre as linhas de vida dos objetos. A ordem na qual
estas mensagens acontecem (fluxo de tempo) é mostrada do topo da
página para baixo.
As mensagens são etiquetadas com o seu nome e podem também conter
informações como condições para execução, parâmetros e informações de
controle. A figura a seguir apresenta um exemplo da notação do Diagrama
de Sequência.

2. Questões Comentadas
1. (FUNRIO/2009/FURNAS/Engenheiro da Computação) Um
estereótipo em UML é
A) uma forma de organizar diversos elementos de um modelo em
grupos.
B) a especificação de uma condição que deve ser satisfeita por um
sistema.
C) um mecanismo usado para estender o significado de um elemento
em um diagrama.
D) um papel desempenhado por um usuário ou sistema quando
participa de um caso de uso.
E) uma relação estrutural pela qual classes ou objetos estão
interconectados.
Comentários
A resposta correta é o item C, é através do mecanismo estereótipo em
UML que podemos incluir um ou mais novos elementos de um
determinado modelo. Desta forma você poderá gerar recursos que não
estejam presentes originalmente na linguagem, ou como indicado na
questão, você pode estender o significado de um elemento em um
diagrama.
GABARITO: C.
2. (FUNRIO/2008/Analista de Sistemas) Julgue os itens a seguir

referentes aos diagramas da notação UML e assinale a alternativa
correta:
I. O Diagrama de Classe captura a estrutura estática do sistema e
serve de base para os outros diagramas;
II. O Diagrama de Casos de Uso pode ser facilmente compreendido
pelo usuário do sistema e é utilizado para modelar as interações entre
os atores e o sistema;
III. O Diagrama de Estado apresenta uma visão dinâmica do sistema e
é usado para modelar os fluxos de atividades de negócio em uma
aplicação.
A) Nenhuma alternativa está correta.
B) Apenas as alternativas I e II estão corretas.
C) Apenas as alternativas I e III estão corretas.
D) Apenas as alternativas II e III estão corretas.
E) Todas as alternativas estão corretas.

Comentários
O item I está correto, pois os Diagramas de Classes são os diagramas
encontrados com mais frequência na modelagem de sistemas orientados a
objetos, ele mostra um conjunto de classes, interfaces e colaborações com
seus relacionamentos. E este diagrama é usado para fazer a modelagem
da visão estática do projeto de um sistema.
O Item II também está correto, uma vez que os diagramas de casos de
uso são um dos diagramas disponíveis na UML para a modelagem de
aspectos dinâmicos de sistemas, o seu papel central é a modelagem do
comportamento de um sistema, de um subsistema ou de uma classe,
onde, cada um mostra um conjunto de casos de uso e interações entre
atores e seus relacionamentos.
O item III está errado, o diagrama de atividade é o diagrama que modela
os fluxos de atividades de negócio em uma aplicação. O diagrama de
estados mostra quais os estados os objetos podem assumir e quais os
eventos que provocam as mudanças de estado, enquanto o diagrama de
atividade é uma variação do diagrama de estados, mas com propósito
diferente. Ele se preocupa com as ações (trabalhos e atividades que serão
executados) e os resultados.
Desta forma, temos os itens I e II corretos e o III errado. O gabarito,
portanto, é a letra B.
GABARITO: B.
3. (FUNRIO/2008/Analista de Sistemas) Generalização é um conceito

de análise orientada a objetos que consiste:
A) Em definir propriedades ou métodos adicionais, tornando uma nova
classe semelhante à classe que lhe deu origem, mas com propriedades
e métodos específicos.
B) No processo de agrupar diversas classes em uma superclasse de
acordo com suas propriedades comuns.
C) Na habilidade de duas ou mais classes responderem à mesma
solicitação, cada uma a seu modo.
D) No processo de abstração por meio do qual as classes e objetos são
identificados univocamente.
E) Na abstração pela qual os relacionamentos são tratados como
entidades de nível superior.
Comentários
Generalização é a capacidade de identificar as similaridades entre várias
classes, com isso criamos uma superclasse que encapsula todas as
funcionalidades comuns às demais classes filhas. Baseado neste conceito,
podemos afirmar que o item B é o correto, onde ele afirma que a

generalização consiste no processo de agrupar diversas classes em uma

superclasse de acordo com suas propriedades comuns.
GABARITO: B.
4. (FUNRIO/2008/Analista de Sistemas)
O diagrama acima na notação UML é denominado:

A) diagrama de colaboração
B) diagrama de fluxo de dados
C) diagrama de transição de estados
D) diagrama de casos de uso
E) diagrama de contexto
Comentários
Os diagramas de Caso de Uso mostram um relacionamento, uma
interação entre um ser humano ou uma máquina (conhecidos como Ator)
com um sistema, no diagrama mostrado nesta questão podemos ver os
Atores Juiz Estudante, Instrutor, Juiz Candidato, Administrador do
Programa e Juiz Examinador, interagindo com o sistema de certificação
através de uma ação.
Segundo Ivar Jacobson, podemos dizer que um Caso de Uso é um
“documento narrativo que descreve a sequência de eventos de um ator
que usa um sistema para completar um processo”.
A resposta correta é o item D.
GABARITO: D.

5. (FUNRIO/2008/Analista de Sistemas) Na orientação a objetos,

classes que NÃO geram instâncias diretas (objetos) são denominadas
classes
A) derivadoras
B) primárias.
C) virtuais.
D) básicas.
E) abstratas.
Comentários
Na orientação a objetos, as classes abstratas, como indicado no item E,
não permitem a instância direta, elas são consideradas superclasse, uma
classe que possui as características mais comuns de um grupo de classes
do mesmo tipo. As classes abstratas são destinadas apenas a servir como
base para a criação de outras classes, ou seja, elas podem ser herdadas.
Como exemplo pode-se observar as classes 'cliente' e 'fornecedor', onde
ambas possuem atributos como nome, endereço e telefone. Nesse caso
pode-se criar uma nova classe chamada, por exemplo, 'pessoa', que
contenha as semelhanças entre as duas classes, fazendo com que cliente
e fornecedor herdem as características de pessoa, desta maneira pode-se
dizer que cliente e fornecedor são subclasses de pessoa.
GABARITO: E.
6. (FUNRIO/2008/Analista de Sistemas) São exemplos de diagramas

comportamentais da UML, os diagramas
A) de Pacotes e de Fluxos de Dados.
B) de Classes e de Objetos.
C) de Componentes e de Implantação.
D) de Casos de Uso e de Atividades.
E) de Estruturas e de Entidades Relacionamentos.
Comentários
Diagramas comportamentais são aqueles onde o comportamento das
classes são representados, ou seja, usados para visualizar, especificar,
construir e documentar aspectos dinâmicos de um sistema.
São os principais diagramas comportamentais:
 Diagrama de Caso de Uso
 Diagrama de Sequência
 Diagrama de Colaboração
 Diagrama de Estados

 Diagrama de Atividades
Dentre as opções listadas na questão, a letra D contém apenas itens de
diagramas comportamentais.
GABARITO: D.
7. (FUNRIO/2009/Analista de Sistemas V) Um estereótipo em UML é

A) um mecanismo usado para estender o significado de um elemento
em um diagrama.
sistema.
C) uma forma de organizar diversos elementos de um modelo em
grupos.
interconectados.
Comentários
A resposta correta é o item A, é através do mecanismo estereótipo em
UML que podemos incluir um ou mais novos elementos de um
determinado modelo. Desta forma você poderá gerar recursos que não
estejam presentes originalmente na linguagem, ou como indicado na
questão, você pode estender o significado de um elemento em um
diagrama.
GABARITO: A.
8. (FUNRIO/2009/Analista de Sistemas V) Considere uma classe

ContaBancária e suas duas subclasses ContaCorrente e
ContaPoupança, cada uma das três com o método AplicarJuros. A
redefinição do método AplicarJuros nas duas subclasses, cada uma com
detalhes de implementação diferentes com a mesma interface,
caracteriza o princípio denominado na orientação a objetos como
A) herança.
B) encapsulamento.
C) polimorfismo.
D) unificação.
E) abstração.
Comentários
Polimorfismo é a capacidade que um mesmo método pode se comportar
de diferentes maneiras em diferentes classes. Enquanto a herança é

voltada mais as classes, o polimorfismo está voltado aos métodos e a

questão questiona exatamente isso, a existência de um mesmo método
chamado AplicarJuros em cada uma das três classes, mas cada uma com
detalhes de implementação diferentes. Caracterizando o princípio
denominado na orientação a objetos como Polimorfismo, resposta do item
C.
GABARITO: C.
9. (FUNRIO/2009/Analista de Sistemas V) São tipos de relacionamentos

entre casos de uso
A) extensão e inclusão.
B) agregação e composição.
C) participação e derivação.
D) conexão e colaboração.
E) interação e navegação.
Comentários
A UML define que no diagrama de caso de uso, um ator deve estar
relacionado a um ou mais casos de uso do sistema. Mas pode haver
relacionamentos entre os atores e entre os casos de uso para realizar um
refinamento do modelo. Neste caso podemos encontrar os possíveis
relacionamentos:
 Inclusão - é aquele que inclui o comportamento de outro caso de
uso; só pode ser usando entre casos de uso.
 Extensão - O relacionamento de extensão é utilizado para modelar
situações em que diferentes sequências de interações podem ser
inseridas em um mesmo caso de uso.
 Generalização - O relacionamento de Generalização pode ocorrer
entre dois casos de uso ou entre dois atores. Ele permite que um
caso de uso (ou um ator) herde características de um caso de uso
(ou um ator) mais genérico, este último chamado de caso de uso
(ou ator) base.
 Comunicação – é aquele relacionamento entre um ator e um caso de
uso.
Encontramos itens válidos neste contexto apenas na letra A.
GABARITO: A.
10. (FUNRIO/2009/Tecnologia em Sistemas) O diagrama da modelagem

de sistemas que é usado na modelagem dos fluxos de trabalho de um
processo de negócio é o diagrama de
A) classes.

B) sequência.
C) estados.
D) atividades.
E) componentes.
Comentários
A resposta correta é o item D, um diagrama de atividade mostra um
processo de negócios ou um processo de software como um fluxo de
trabalho por meio de uma série de ações. Pessoas, computadores ou
componentes de software podem executar essas ações. Vale apena
lembrar que este diagrama é um dos 5(cinco) diagramas
comportamentais disponíveis na UML.
GABARITO: D.
11. (FUNRIO/2009/Tecnologia em Sistemas) Na terminologia da

UML, o dado sobre limites inferior e superior da quantidade de objetos
aos quais um outro objeto pode estar associado (por exemplo, um
cliente pode estar associado a 0 ou vários pedidos) é denominado
A) multiplicidade.
B) participação.
C) associatividade.
D) conectividade.
E) responsabilidade.
Comentários
O item A representa a resposta correta, a multiplicidade define a
quantidade de instâncias de um objeto que uma classe pode ter em
relação à outra classe. Se a multiplicidade não for definida na associação o
seu valor padrão é de 1..1 (um para um). Existem diversas formas de
expressar a multiplicidade em uma associação, por exemplo:
 0..1 – zero para um
 0..* - zero para vários
 1..* - um para vários
E assim por diante.
GABARITO: A.
12. (FUNRIO/2009/Tecnologia em Sistemas) Considere a

sentença: “Uma equipe é formada por diversos jogadores”. Que tipo de
associação caracteriza o relacionamento entre equipe e jogadores?
A) Classificação.

B) Composição.
C) Agregação.
D) Generalização.
E) Pertinência.
Comentários
Uma associação representa que duas classes possuem uma ligação (link)
entre elas, ou seja, estão associadas. A associação mais comum é a
associação Normal, que é apenas uma conexão entre as classes, temos a
associação Recursiva, que possibilita a conexão de uma classe a ela
mesma através de uma associação, associação Ternária, onde mais de
duas classes podem ser associadas entre si e por último a associação de
Agregação, citada no item C, o item correto, ela é um caso particular da
associação que indica que uma das classes do relacionamento é uma
parte, ou está contida em outra classe. As palavras chaves usadas para
identificar uma agregação são: "consiste em", "contém", "é parte de". Na
questão podemos substituir a expressão “é formada por” na frase “Uma
equipe é formada por diversos jogadores” por “Uma equipe contém
diversos jogadores” ou “Uma equipe consiste em diversos jogadores”,
assim identificamos uma agregação.
GABARITO: C.
13. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) Um modelo é

uma abstração de algo com a finalidade de entendê-lo antes de
construí-lo. Todo sistema desenvolvido deve ser modelado e, nesse
sentido, existem pontos de vista distintos, porém relacionados, cada
qual capturando aspectos importantes e necessários para uma
descrição completa. Enquanto o modelo de interações representa a
colaboração de objetos individuais, os aspectos de “interações” de um
sistema representam os aspectos estáticos, estruturais de “dados” e
também podem representar os aspectos temporais e comportamentais,
de “controle” desse mesmo sistema. Esses dois últimos são
denominados, respectivamente, modelos de:
A) Classes e Estados
B) Dados e Controle
C) Eventos e Estados
D) Dados e Estados
E) Classes e Controle
Comentários
Os dois últimos modelos “dados” e “controle” correspondem aos modelos
de Classes e Estados, letra A.

Classificação significa que os objetos com a mesma estrutura de dados

(chamados atributos) e o mesmo comportamento (chamados operações
ou métodos) são agrupados em uma classe. Classe é uma abstração que
descreve propriedades importantes para uma aplicação e ignora o
restante. O objetivo de um diagrama de classes é descrever os vários
tipos de objetos no sistema e o relacionamento entre eles.
Um diagrama de classes pode oferecer três perspectivas, cada uma para
um tipo de observador diferente. São elas:
 Conceitual
o Representa os conceitos do domínio em estudo.
o Perspectiva destinada ao cliente.
 Especificação
o Tem foco nas principais interfaces da arquitetura, nos
principais métodos, e não como eles irão ser implementados.
o Perspectiva destinada as pessoas que não precisam saber
detalhes de desenvolvimento, tais como gerentes de projeto.
 Implementação - a mais utilizada de todas
o Aborda vários detalhes de implementação, tais como
navegabilidade, tipo dos atributos, etc.
o Perspectiva destinada ao time de desenvolvimento.
Um diagrama de classes contém:
* Entidades
* Relacionamentos
Os Diagramas de Máquinas de Estados, ou simplesmente Diagramas

de Estados, descrevem o comportamento dinâmico do sistema,
representando os estados que um objeto passa durante a execução do
sistema e como ele muda de estado em respostas aos eventos. Cada
diagrama representa uma classe única.
Em um diagrama de estado, um objeto possui um comportamento e um
estado. O estado de um objeto depende da atividade na qual ele está
processando. Um diagrama de estado mostra os possíveis estados de um
objeto e as transações responsáveis pelas suas mudanças de estado.
GABARITO: A.
14. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) A Engenharia

de Requisitos fornece o mecanismo apropriado para entender o que o
cliente deseja, analisando as necessidades, avaliando a exequibilidade,
negociando uma condição razoável, especificando a solução de forma
clara, validando a especificação e gerindo os requisitos à medida que

GABARITO: D.
15. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) No que tange

aos paradigmas da Orientação a Objetos (OO), um princípio está
diretamente relacionado às operações realizadas por um objeto e ao
modo como as operações são executadas, constituindo uma forma de
restringir o acesso ao comportamento interno de um objeto. Nesse
processo, um objeto que precise da colaboração de outro para realizar
alguma tarefa deve enviar uma mensagem a este último. Além disso,
separa os aspectos externos de um objeto dos detalhes internos da
implementação. Considerando esse contexto, observe a figura abaixo.

Além disso, ele – o encapsulamento – promove uma maior estabilidade,

uma vez que clientes do objeto só conhecem sua interface e que podemos
alterar a implementação de uma operação sem afetar o restante do
sistema.
GABARITO: E.
16. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) A UML é uma

linguagem de modelagem visual, podendo ser definida como um
conjunto de notações e semântica correspondente para representar
visualmente uma ou mais perspectivas de um sistema. Dentre os
diagramas da UML, um diagrama foca os requisitos funcionais de um
sistema, forçando os desenvolvedores a moldarem o sistema de acordo
com o usuário, e não o usuário de acordo com o sistema,
representando as especificações de uma sequência de interações entre
um sistema e os agentes externos que utilizam esse sistema, por meio
dos atores e relacionamentos entre eles. Esse diagrama é denominado:
A) Casos de uso
B) Casos de negócios
C) Processos e funções
D) Entidades e relacionamentos
E) Processos e relacionamentos
Comentários
O diagrama que foca os requisitos funcionais de um sistema é o diagrama
de casos de uso.
Os casos de uso descrevem funcionalidades do sistema percebidas por
atores externos. Um ator é uma pessoa (ou dispositivo, ou outro sistema)
que interage com o sistema.
GABARITO: A.
17. (ESAF/2008/MPOG) Os requisitos de um sistema são descrições

dos serviços fornecidos pelo sistema e as suas restrições operacionais.
Indique a opção que corretamente se relaciona com a análise ou
gerenciamento de requisitos.

a) Requisitos de sistema são declarações do usuário que definem,

detalhadamente, as funções, os serviços e as restrições operacionais
do sistema.
b) As representações de dados usadas nas interfaces de sistemas são
exemplos de requisitos funcionais.
c) A exigência de que o sistema deva fornecer telas apropriadas para o
usuário ler os documentos no repositório de documentos é um exemplo
de requisito funcional.
d) A exigência de que o sistema não deva revelar quaisquer
informações pessoais sobre os usuários do sistema ao pessoal de
vendas que o utiliza, com exceção do nome e cargo, é um exemplo de
requisito funcional.
e) Avaliar se os requisitos associados ao desempenho, ao
comportamento e às características operacionais do sistema foram
explicitamente declaradas é uma tarefa de especificação de requisitos.
Comentários
Item a. Existem diferentes definições encontradas na literatura técnica
para requisitos:
• Um requisito é uma característica do sistema ou a descrição de
algo que o sistema é capaz de realizar para atingir os seus
objetivos;
• As descrições das funções e restrições são os requisitos do sistema;
• Um requisito é uma propriedade que o software deve exibir para
resolver algum problema no mundo real;
• Uma condição ou uma capacidade que deve ser alcançada ou estar
presente em um sistema para satisfazer um contrato, padrão,
especificação ou outro documento formalmente imposto.
Percebe-se que as citações encontradas definem o mesmo conceito sob
diferentes perspectivas. Podemos entender requisitos como sendo o
conjunto de necessidades explicitadas pelo cliente que deverão ser
atendidas para solucionar um determinado problema do negócio
no qual o cliente faz parte. É importante estar atento para esta
definição: embora o requisito seja definido pelo cliente, nem sempre o que
o cliente quer é o que o negócio precisa. Cabe à equipe de consultores
identificar a real necessidade do negócio.
Neste contexto, requisitos são importantes para:
• estabelecer uma base de concordância entre o cliente e o fornecedor
sobre o que o software fará;
• fornecer uma referência para a validação do produto final;
• reduzir o custo de desenvolvimento (como vimos anteriormente,
requisitos mal definidos causam retrabalho).

Na questão, podemos observar que a letra A está INCORRETA, pois

informa que requisitos do sistema são declarações do usuário, e estes
descrevem apenas requisitos funcionais e não funcionais. Conforme visto,
o conceito de requisito do sistema é muito mais abrangente; requisitos
de sistema são versões expandidas dos requisitos de usuário usados pelos
engenheiros de software como ponto de partida para o projeto do
sistema. Eles adicionam detalhes e explicam como os requisitos de
usuário devem ser fornecidos pelo sistema. Deve ser uma especificação
completa e consistente de todo o sistema. São definidos pelas
preferências dos usuários, além das questões políticas e
organizacionais.
Item b. Entendida a definição de requisitos, é preciso conhecer seus tipos.
funcionais
São requisitos diretamente ligados à funcionalidade do software,
descrevem as funções que o software deve executar.
Thayer (1990) corrobora a definição anterior, ao especificar que requisito
funcional é um requisito de sistema de software que especifica uma
função que o sistema ou componente deve ser capaz de realizar. Estes
são requisitos de software que definem o comportamento do sistema, ou
seja, o processo ou transformação que componentes de software ou
hardware efetuam sobre as entradas para gerar as saídas. Esses
requisitos capturam as funcionalidades sob o ponto de vista do usuário.
Alguns exemplos são:
• O software deve permitir o cadastro de clientes;
• O software deve permitir a geração de relatórios sobre o desempenho
de vendas no semestre;
• O software deve permitir o pagamento das compras através de cartão
de crédito.
Requisitos não funcionais

São requisitos que expressam condições que o software deve atender ou
qualidades específicas que o software deve ter. Em vez de informar o que
o sistema fará, os requisitos não-funcionais colocam restrições no
sistema.
Segundo Thayer (1990) em engenharia de sistemas de software, um
requisito não funcional de software é aquele que descreve não o que o
sistema fará, mas COMO ele fará. Assim, por exemplo, têm-se requisitos
de desempenho, requisitos da interface externa do sistema, restrições de
projeto e atributos da qualidade. A avaliação dos requisitos não funcionais

é feita, em parte, por meio de testes, enquanto que outra parte é avaliada
de maneira subjetiva.
Requisitos não funcionais são aqueles que não estão diretamente
relacionados à funcionalidade de um sistema. O termo requisitos não
funcionais é também chamado de atributos de qualidade. Se tais
requisitos não são levados em consideração, então o sistema de software
poderá ser inconsistente e de baixa qualidade. Para tanto, quanto mais
cedo forem definidos os critérios arquiteturais, mais cedo o projetista
pode identificar o estilo, ou combinação de estilos, mais apropriado ao
sistema considerado.
Alguns exemplos são:
• O software deve ser compatível com os browsers IE (versão 8.0 ou
superior) e Firefox (1.0 ou superior);
• O software deve garantir que o tempo de retorno das consultas não
seja maior do que 5 segundos.
Considere, por exemplo, o padrão IEEE-Std 830-1993 [IEEE 1993] que
lista um conjunto de 13 requisitos não funcionais a serem considerados no
documento de especificação de requisitos de software. Este padrão inclui,
dentre outros, requisitos de desempenho, confiabilidade, portabilidade e
segurança. Embora haja um conjunto de propostas, consideradas como
complementares, concentraremos nossas atenções num conjunto de
requisitos diretamente associados a um sistema de software e,
especificamente, à arquitetura de software. Este conjunto é baseado
numa classificação apresentada por Sommerville (2007), em que é feita a
distinção entre requisitos externos, de produto, e de processo.
A figura seguinte é uma adaptação da proposta de Sommerville, onde
consideramos os requisitos de produto, associados à arquitetura de
software, bem como adicionamos outros não presentes na proposta
original de Sommerville. É importante observar que a figura mostra um
subconjunto de requisitos não funcionais, denominados de requisitos de
produtos os quais estão associados à arquitetura de um sistema de
software.
Note que a classificação apresentada em Sommerville (2007) ainda
considera os requisitos de processo e requisitos externos como sendo
requisitos não funcionais, além dos requisitos de produtos. A figura
seguinte exibe um conjunto de 7 requisitos não funcionais, sendo alguns
destes ainda decompostos.

Figura. Tipos de requisitos não funcionais

Fonte: Engenharia de Software Magazine, Ed. 3. Ano I.
Requisitos de domínio
São requisitos derivados do domínio da aplicação e descrevem
características do sistema e qualidades que refletem o domínio. Podem ser
requisitos funcionais novos, restrições sobre requisitos existentes ou
computações específicas. Dois exemplos de requisitos do domínio são:
• O cálculo da média final de cada aluno é dado pela fórmula:

(Nota1 * 2 + Nota2 *3)/5;

• Um aluno pode se matricular em uma disciplina desde que ele tenha
sido aprovado nas disciplinas consideradas pré-requisitos.
A letra b está INCORRETA, pois menciona as representações de dados
como exemplo de requisitos funcionais, e estas não fazem parte da
especificação.
Item c. Pode ser exigido que o sistema ofereça uma forma para o usuário
ler um documento. Isso pode ser definido como uma funcionalidade
OBRIGATÓRIA para o sistema, o que torna o mesmo um requisito
Funcional. Item CERTO.
Item d. A letra D está INCORRETA, pois se trata de um requisito não

funcional, em que suas características principais são as restrições sobre os
serviços ou as funções oferecidas pelo sistema. Incluem restrições de
tempo, restrições sobre o processo de desenvolvimento e padrões.
Item e. Está INCORRETO, pois características operacionais do sistema
não fazem parte do escopo de requisitos do sistema (SOMMERVILLE,
2007).
GABARITO: C.
18. (CESPE/2010/BANCO DA AMAZÔNIA/Técnico Científico —

Área: Tecnologia da Informação) A abordagem embasada em
objetos preocupa-se primeiro em identificar os objetos contidos no
domínio da aplicação e, em seguida, em estabelecer os procedimentos
relativos a eles.
Comentários
A questão afirma que na orientação a objetos são identificados primeiro os
componentes da aplicação (classes e objetos) e depois os métodos. Como
os métodos são de responsabilidade dos objetos, deve-se primeiro
identificar os objetos para depois alocarem-se os métodos a eles. Logo a
alternativa é verdadeira. A orientação a objetos possui os principais
componentes:
a) Objeto: um objeto simplesmente é algo (coisa ou pessoa) que faz
sentido no contexto de uma aplicação. O objeto é um conceito, uma
abstração, algo com limites nítidos e significado em relação ao problema
em causa. Eles facilitam a compreensão do mundo real e oferecem uma
base real para ser implementada no computador. Todos os objetos têm
identidade e são distinguíveis. Identidade significa que os objetos se
distinguem pela sua própria existência, e não por suas propriedades.

b) Classe: uma classe de objetos descreve um grupo de objetos com

propriedades semelhantes (atributos), o mesmo comportamento
(operações), os mesmos relacionamentos com outros objetos e a mesma
semântica. A maioria dos objetos deriva sua individualidade das
diferenças entre os valores de seus atributos e relacionamentos com
outros objetos, mas também é possível a existência de objetos com
idênticos valores de atributos e relacionamentos. As linguagens de
programação orientadas a objeto podem determinar a classe de um objeto
em tempo de execução. A classe de um objeto é uma propriedade
implícita do objeto. Ao se agrupar objetos em classe generalizam-se
definições comuns, como nome da classe e nomes dos atributos, sendo
armazenados uma vez por classe ao invés de por instância, isto é a
abstração.
Principais Componentes da Classe:
 Um atributo é um valor de dado guardado pelos objetos de uma
classe, e cada atributo possui um valor para cada instância de objeto.
Diferentes instâncias de objetos podem ter valores iguais ou diferentes
para um dado atributo e é importante frisar que cada nome de atributo
é único dentro de uma classe. Um atributo deve ser um puro valor de
dado, e não um objeto. Diferentemente dos objetos, os valores puros
de dados não tem identidade.
 O Método é uma função ou transformação que pode ser aplicada a
objetos ou por estes a uma classe, e todos os objetos de uma classe
compartilham as mesmas operações. Cada operação tem um objeto-
alvo, seu comportamento depende da classe de seu alvo. A mesma
operação pode se aplicar a muitas classes diferentes, sendo assim ela é
polimórfica, isto é, a mesma operação toma formas diferentes em
classes diferentes. Uma operação pode ter argumentos além de um
objeto-alvo. Esses argumentos servem como parâmetros para a
operação, mas não afetam a escolha do método.
Quando uma operação possui métodos em várias classes, é importante
que todos esses métodos tenham a mesma assinatura, a quantidade e
tipos de argumentos e o tipo do valor resultante.
c) Associação: é uma conexão física ou conceitual entre instâncias de

objetos. Pode ser definida como uma lista ordenada de instâncias de
objetos. Uma associação descreve um grupo de ligações com estrutura e
semântica comuns, ou seja, descreve um conjunto de potenciais ligações
(da mesma maneira que uma classe descreve um conjunto de potenciais
objetos), e as associações são intrinsecamente bidirecionais. As
associações muitas vezes são implementadas em linguagens de
programação como ponteiros de um objeto para outro. As associações
não são simplesmente construções de banco de dados, embora os

bancos de dados relacionais sejam construídos sobre os conceitos de

associações.
d) Multiplicidade: especifica quantas instâncias de uma classe

relacionam-se a uma única instância de uma classe associada. A
multiplicidade restringe a quantidade de objetos relacionados.
A multiplicidade depende de pressupostos e de como são definidas as
fronteiras de um problema. A mais importante distinção de multiplicidade
é a existente entre "um" e "muitos". A subestimação da multiplicidade
pode restringir a flexibilidade de aplicação.
e) Herança: é o compartilhamento de atributos e operações entre classes

com base num relacionamento hierárquico. Uma classe pode ser dividida
em subclasses mais definidas. Cada subclasse herda todas as
propriedades de sua superclasse e acrescenta suas próprias e exclusivas
características. As propriedades da superclasse não precisam ser repetidas
em cada subclasse. A herança é uma das principais características (ou
mesmo vantagem) dos sistemas baseados em objetos. A capacidade de
identificar propriedades comuns a várias classes de uma superclasse
comum e de fazê-las herdar as propriedades da sua superclasse pode
reduzir substancialmente as repetições nos projetos e programas.
GABARITO: CERTO.

Área: Tecnologia da Informação — ANÁLISE DE SISTEMAS) Na
modelagem de classes, a hierarquia entre elas é representada por meio
de um relacionamento chamado generalização.
Comentários
Explicando um pouco mais a generalização, ela é um relacionamento
entre um elemento geral e um outro mais específico. O elemento mais
específico possui todas as características do elemento geral e contém
ainda mais particularidades. Um objeto mais específico pode ser usado
como uma instância do elemento mais geral.
A generalização, também chamada de herança, permite a criação de
elementos especializados em outros.
Na generalização normal a classe mais específica, chamada de subclasse,
herda tudo que for público ou protegido da classe mais geral, chamada de
superclasse. Os atributos, operações e todas as associações são
herdados pela subclasse.

A generalização normal é representada por uma linha entre as duas

classes que fazem o relacionamento, sendo que se coloca uma seta no
lado da linha onde se encontra a superclasse indicando a generalização.
A figura a seguir apresenta um exemplo de generalização normal.
Conta Corrente Poupança
GABARITO: CERTO.

Área: Tecnologia da Informação — ANÁLISE DE SISTEMAS) A
modelagem do comportamento dos objetos de um sistema pode ser
feita por meio do modelo de objetos do sistema.
Comentários
Um diagrama é a representação gráfica de um conjunto de elementos do
sistema sob uma determinada perspectiva, criando uma projeção do
sistema. Logo, ele representa um modelo (representação abstrata) de
algo real.
Com os diagramas, visamos representar a realidade, para possibilitar que
esta seja estudada quanto ao seu comportamento. Esses modelos
permitem focalizar a atenção nas características importantes do sistema,
dando menos atenção às coisas menos importantes. Seu uso torna o
estudo mais barato e seguro: é muito mais rápido e barato construir um
modelo do que construir a coisa “real”.
A UML possui diversos diagramas, que podem ser divididos em três
grandes grupos:
Diagramas de Comportamento: descrevem a perspectiva
comportamental de um sistema descrita pelos seus processos de
negócios. Possui os seguintes diagramas:
Atividades
Máquina de Estados
Casos de Uso
Diagramas de Estrutura: descrevem elementos estáticos de um
sistema:
Classes
Estrutura
Componentes
Distribuição

Objetos
Pacotes
Diagramas de Interação: representam a interação que ocorre entre
os objetos.
Comunicação
Sequência
Sincronismo
GABARITO: ERRADO.

análise orientada a objetos é inadequada a situações em que os dados
do sistema devam ser armazenados em um sistema de banco de dados
relacional.
Comentários
A orientação a objetos é um paradigma para desenvolvimento de
software. Já o modelo relacional é uma forma de estruturar o banco de
dados. A aplicação de um não impede a utilização de outro! Existem
atualmente formas de mapeamento objeto-relacional que possibilitam que
um aplicativo orientado a objetos utilize um banco de dados relacional.
GABARITO: ERRADO.

Área: Tecnologia da Informação — ANÁLISE DE SISTEMAS) O
comportamento de um objeto é definido em sua respectiva classe, por
meio da implementação de métodos que são executados quando tal
objeto recebe uma mensagem.
Comentários
Uma classe é a descrição de um grupo de objetos com propriedades
similares (atributos), comportamento comum (operações ou
métodos), relacionamentos comuns com outros objetos (associações) e
semânticas idênticas.
As classes individuais são representadas na UML como um retângulo
sólido com um, dois ou três compartimentos. O primeiro compartimento é
para o nome da classe e é obrigatório, o segundo e o terceiro
compartimento são opcionais e podem ser usados para listar
respectivamente os atributos e as operações definidas para a classe.
A figura a seguir apresenta uma classe na notação UML.

é uma lista que indica os tipos de todos os seus argumentos, sendo assim
métodos com mesmo nome são considerados diferentes se recebem um
diferente número ou tipo de argumentos e tem, portanto, uma assinatura
diferente.
A seguir, apresenta-se um exemplo de sobrecarga.
Da mesma forma que podemos sobrecarregar métodos de uma classe, o

mesmo pode ser feito com seus construtores, ou seja, uma classe pode
possuir mais de um construtor onde cada um deles é diferenciado por sua
assinatura. O compilador determina qual dos construtores utilizar através
dos argumentos utilizados na chamada do construtor. Obviamente deve
existir um construtor cuja lista de argumentos seja a utilizada na criação
de um novo objeto, caso contrário será indicado o erro.
Na questão, a banca visa induzir o erro do candidato ao afirmar que com a
sobrecarga “as subclasses podem implementar um comportamento
específico para um método herdado da sua superclasse”. Este é o conceito
de polimorfismo.
GABARITO: ERRADO.

Área: Tecnologia da Informação — ANÁLISE DE SISTEMAS)
Objetos têm identidade própria. Isso garante que, mesmo tendo os
mesmos valores de variáveis e pertencendo à mesma classe, dois
objetos sejam considerados diferentes.
Comentários
Na orientação a objetos, o conceito de identidade define que um objeto é
uma instância única de uma classe, ocupando uma posição de memória
específica. Então, podemos ter dois objetos não-idênticos (ocupam
posições de memória distintas) mas iguais (são da mesma classe e
possuem os mesmos valores para os atributos).

Estes conceitos são apresentados no código abaixo:

Integer x = new Integer(JOptionPane.showInputDialog("1 numero"));
Integer y = new Integer(JOptionPane.showInputDialog("2 numero"));
JOptionPane.showMessageDialog(null, "Identidade: "+(x==y) + "\n"
+ "Igualdade: "+x.equals(y));
GABARITO: CERTO.

Área: Tecnologia da Informação — ANÁLISE DE SISTEMAS) Em
um programa orientado a objetos, determinada mensagem a objeto
sempre leva à execução do mesmo método, todas as vezes que o
programa é executado.
Comentários
Devido à sobrecarga, uma mensagem deve avaliar a assinatura do
método para identificar qual implementação será executada. Ou seja, de
acordo com o tipo e/ou a quantidade de parâmetros que forem
informados, será executada uma determinada implementação de um
método (caso exista).
GABARITO: ERRADO.
Considerando o diagrama acima, julgue os itens seguintes.
26. (CESPE/2010/ IJSN/ES/ Informática e Gestão da

Informação) Considerando apenas a questão semântica do diagrama,
a existência do elemento requisição pressupõe uma cardinalidade N
para N entre os elementos sujeito e monitor de referência.
Comentários
Uma Associação é uma conexão entre classes, e também significa que
existe uma conexão entre objetos daquelas classes. Em UML, uma
associação é definida com um relacionamento que descreve uma série de

Os atributos da classe Funcionário (matrícula, nome, cpf, dataNascimento,

salario) são protegidos (símbolo # junto ao nome do atributo), e como tal
só podem ser acessados diretamente pelas subclasses Programador e
Gerente.
GABARITO: ERRADO.

classe Gerente, ocorre a sobrecarga do método calculaSalario().
Comentários
O método calculaSalario da superclasse Funcionario é sobreposto
(overhided) na subclasse Gerente. Logo, o comportamento deste método
pode ser diferente em cada uma das subclasses, no entanto através da
superclasse podemos genericamente usar tal método, que produz um
resultado distinto para cada classe utilizada. Nesta situação foi aplicado o
conceito de polimorfismo.
Assim o polimorfismo também significa que uma mesma operação pode se
comportar de forma diferente em classes diferentes. Para a orientação a
objetos uma operação é uma ação ou transformação que um objeto pode
realizar ou está sujeito e, desta forma, os métodos são implementações
específicas das operações desejadas para uma certa classe.
GABARITO: ERRADO.

Área: Tecnologia da Informação — ANÁLISE DE SISTEMAS) De
acordo com as características da relação entre a classe Funcionario e a
classe Curriculo, ao se excluir um funcionário desse sistema, também
serão removidos os respectivos dados curriculares da base de dados.
Comentários
Como existe uma composição entre as classes, a exclusão de funcionário
leva também à exclusão dos respectivos currículos.
GABARITO: CERTO.

Área: Tecnologia da Informação — Arquitetura de Tecnologia) O
desenvolvedor deve utilizar herança múltipla para agilizar os processos
de busca e execução dos processos.
Comentários
A herança múltipla entre classes ocorre quando uma subclasse possui
mais de uma superclasse imediata. Empregando-se a herança múltipla é

possível combinar as características (atributos e métodos) de diversas

superclasses para a criação de uma nova classe.
Como a herança múltipla é um mecanismo de relacionamento entre
classes, não podemos afirmar que a aplicação da mesma permita que

processos de busca e execução dos processos sejam agilizados.
GABARITO: ERRADO.

Área: Tecnologia da Informação — Arquitetura de Tecnologia)
Em diversos casos de orientação a objetos, é necessário realizar
alguma(s) ação(ões) para o objeto poder ser destruído. Um exemplo
disso é a desalocação dinâmica de memória.
Comentários
A classe é simplesmente uma “forma” para criação de objetos, chamada
de instanciação. Para criar um objeto, deve-se utilizar um tipo especial de
método chamado construtor. Um construtor aloca uma posição de
memória para guardar os dados do objeto. De forma análoga, existem os
métodos finalizadores, os quais removem os objetos da memória,
liberando dinamicamente a posição de memória. Algumas linguagens de
programação mais recentes possuem também recursos de limpeza
automática de memória.
GABARITO: CERTO.

Tendo o diagrama UML da figura acima como referência, julgue os

seguintes itens.
34. (CESPE/2009/TCU/AUDITOR FEDERAL DE CONTROLE

EXTERNO/ÁREA: TI) O método #Cadastrar() da classe Instrutor tem
visibilidade do modo protegido tal que somente a classe possuidora
Instrutor pode utilizá-lo.
Comentários
A visibilidade Protegido permite que seja observado pelas classes e sub-
classes. A visibilidade que permite apenas para a classe é a privada. Já a
pública, permite que seja observada por todas as outras classes.
GABARITO: ERRADO.

EXTERNO/ÁREA: TI) Na associação do tipo agregação composta
identificado por #2, uma instância da classe Departamento pertence
exclusivamente a uma única instância composta em Escola, e um
objeto da classe Escola pode relacionar-se com, no máximo, três
objetos da classe Departamento.
Comentários
A afirmação está correta, visto que existe realmente uma composição
entre as classes Departamento e Escola. Lembre-se que se existe a
composição, o Departamento pertence somente a uma Escola. E ainda, de
acordo com a cardinalidade 1..3, uma escola possui no máximo 3
Departamentos.

GABARITO: CERTO.
36. (FUMARC/2009/PREFEITURA DE GOVERNADOR

VALADARES/Analista de Sistemas) Sobre os princípios de análise e
projeto orientados para objetos e a UML, assinale a alternativa
INCORRETA:
a) Cenário ou instância de caso de uso: é uma sequência de ações e
interações entre atores e o sistema em discussão.
b) Modelo de Dados: inclui os esquemas de Bancos de Dados e as
estratégias de mapeamento entre as representações baseadas em
objeto e as representações não baseadas em objetos.
c) Modelo de Domínio: e a representação visual das classes conceituais
no domínio do problema. É também chamado de modelo conceitual.
d) Modelo Comportamental: especificação de todos os processos que
irão compor o sistema. Os processos são representados no DFD.
Comentários
Os três primeiros itens estão corretos. Porém, na “letra D” encontramos
uma afirmação sobre a relação do Diagrama de Fluxo de Dados (DFD) e o
Modelo Comportamental. Não existe DFD (Diagrama de Fluxo de Dados)
no Modelo Comportamental da UML. Na verdade o DFD é uma ferramenta
para a modelagem de sistemas, que fornece a visão ESTRUTURADA das
funções (o fluxo dos dados). Segundo Yourdon: “Um DFD é uma
ferramenta de modelagem que nos permite imaginar um sistema como
uma rede de processos funcionais, interligados por “dutos” e “tanques de
armazenamento de dados”.
Outros nomes são usados para o Diagrama de Fluxo de Dados: Diagrama
de bolhas, DFD (abreviatura), Modelo de processo, Diagrama de fluxo de
trabalho e Modelo funcional.
Já o Modelo Comportamental busca simular o comportamento e troca de
mensagens de vários tipos de sistema. A ideia é estudar a parte dinâmica
do sistema. Este modelo é composto por diagramas que visam visualizar,
especificar, construir e documentar aspectos dinâmicos de um sistema.
São os diagramas deste modelo:
 De Caso de Uso (Use Case): Geral e informal para fases de
levantamento e análise de Requisitos do Sistema.
 De Máquina de Estados: Procura acompanhar as mudanças sofridas
por um objeto dentro de um processo.
 De Atividades: Descreve os passos a serem percorridos para a
conclusão de uma atividade.
 De Interação: Dividem-se em:
 De Sequência: Descreve a ordem temporal em que as mensagens
são trocadas entre os objetos.

 Geral interação: Variação dos diagramas de atividades que

fornece visão geral dentro do sistema ou processo do negócio.
 De comunicação: Associado ao diagrama de Seqüência,
complementando-o e concentrando-se em como os objetos estão
vinculados.
 De tempo: Descreve a mudança de estado ou condição de uma
instância de uma classe ou seu papel durante o tempo.
GABARITO: D.

VALADARES/Analista de Sistemas) Sobre o Diagrama de Casos de
Uso e a UML, assinale a alternativa CORRETA:
a) Um ator é algo ou alguém com algum comportamento, tal como
uma pessoa (identificada por um papel), um sistema de computador,
ou uma organização.
b) O Diagrama de casos de uso determina a relação entre os atores e
os requisitos funcionais do sistema, substituindo a representação
textual dos casos de uso.
c) Os relacionamentos existentes entre os elementos usados no modelo
de casos de uso incluem: comunicação, inclusão, extensão, herança,
agregação, composição, encapsulamento e polimorfismo.
d) Casos de uso são representações em baixo nível das funções que
um ator deseja executar no sistema, incluindo a forma de
representação dos atributos e operadores necessários a esta execução.
Comentários
Item a. A “letra A” é a única correta. “Um ator especifica um papel
executado por um usuário ou outro sistema que interage com o assunto
(sistema)”. Ator é algo que interage com o sistema, mas sobre o qual não
se tem controle. Ele está fora da influência do sistema. Os atores têm um
papel externo e são quem iniciam (e quem respondem) aos casos de uso.
Por exemplo: fazem o pedido num restaurante, comem, bebem ou pagam.
Tipicamente, um ator representa um papel que um ser humano, um
processo, um sistema, ou até um dispositivo de hardware, desempenha
ao interagir com o sistema.
Item b. Item errado. Segundo Larman, um diagrama de caso de uso

ilustra um conjunto de casos de uso para um sistema, os atores e a
relação entre os atores e os casos de uso. Os casos de uso são usados
para modelar como um sistema ou empresa funciona, ou como os
usuários desejam que ele funcione. Os casos de uso geralmente são o
ponto de partida da análise orientada a objetos utilizando a UML.

Também cabe destacar que os Diagramas de Casos de Uso podem ser

complementados (e não substituídos, como informado na questão!) pela
documentação dos Casos de Uso. Segundo Guedes (2008) “a
documentação de um Caso de Uso costuma descrever, por meio de uma
linguagem bastante simples, a função em linhas gerais do Caso de Uso,
quais Atores interagem com o mesmo, quais etapas devem ser
executadas pelo Ator e pelo sistema para que o Caso de Uso execute sua
função, quais parâmetros devem ser fornecidos e quais restrições e
validações o Caso de Uso deve ter“.
Item c. Item errado. Vejamos os relacionamentos existentes entre os

elementos de um modelo de casos de uso, conforme Revista Engenharia
de Software (edição 9, Ano I, pág. 22):
 para relacionamentos de casos de uso entre si temos:
generalização, extensão e inclusão.
 para relacionamentos de atores entre si temos um único tipo:
generalização.
 Para relacionamentos entre atores e casos de uso temos apenas a
associação. Nesse caso teremos um ator fazendo a chamada de uma
instância do caso de uso.
Item d. Item errado. Os Casos de Uso referem-se aos serviços, tarefas ou

funções que podem ser utilizados de alguma maneira pelos usuários do
sistema, como emitir um relatório ou cadastrar a venda de algum produto.
Os Casos de Uso são utilizados para expressar e documentar os
comportamentos pretendidos para as funções do sistema. O objetivo
principal da documentação de um Caso de Uso é fornecer ao cliente um
relatório explicando qual o comportamento pretendido para um
determinado Caso de Uso e quais funções ele executará quando for
solicitado. O engenheiro de software também poderá inserir detalhes de
implementação em linguagem mais técnica, se achar necessário, mas isso
não é comum.
GABARITO: A.

VALADARES/Analista de Sistemas) Um processo administrativo na
prefeitura pode se encontrar nas seguintes situações: iniciado, em
execução, pendente ou finalizado. O instrumento da UML que melhor
representa o fluxo de passagem de um estado para o outro no
processo acima é:
a) diagrama entidades-relacionamentos.
b) diagrama de atividade.

c) diagrama de transições de estado.

d) diagrama de fluxo de dados.
Comentários
Essa é fácil, não é? O diagrama que bem representa as mudanças de
estado em processos é o diagrama de transições de estado.
Um diagrama de transição de estados é uma representação do estado ou
situação em que um objeto pode se encontrar no decorrer da execução de
processos de um sistema. Com isso, o objeto pode passar de um estado
inicial para um estado final através de uma transição.
GABARITO: C.

VALADARES/Analista de Sistemas) Quanto ao Processo Unificado e
a UML, assinale a alternativa INCORRETA:
a) Associações implementam relações unidirecionais entre classes,
sendo necessárias duas associações para implementar uma relação
bidirecional entre duas entidades.
b) Se toda instância da classe C for obrigatoriamente uma instância de
uma subclasse de C, então C é uma classe conceitualmente abstrata.
c) A presença de uma associação com cardinalidade de muitos-para-
muitos é um forte indicativo de que será necessário criar uma classe de
associação.
d) A composição é um tipo de associação com dependência de tempo
de vida entre a classe que representa a parte e a classe que representa
o todo.
Comentários
Os relacionamentos ligam classes/objetos entre si criando relações lógicas
entre estas entidades. Existem três tipos de relacionamentos: associação,
generalização e Dependência/Refinamentos.
 Associação: É uma conexão entre classes, e também significa que é
uma conexão entre objetos daquelas classes. Em UML, uma
associação é definida com um relacionamento que descreve uma
série de ligações, onde a ligação é definida como a semântica entre
as duplas de objetos ligados.
 Generalização: É um relacionamento de um elemento mais geral e
outro mais específico. O elemento mais específico pode conter
apenas informações adicionais. Uma instância (um objeto é uma
instância de uma classe) do elemento mais específico pode ser
usada onde o elemento mais geral seja permitido.
 Dependência e Refinamentos: Dependência é um relacionamento
entre elementos, um independente e outro dependente. Uma
modificação é um elemento independente afetará diretamente

elementos dependentes do anterior. Refinamento é um

relacionamento entre duas descrições de uma mesma entidade, mas
em níveis diferentes de abstração.
Segundo Furlan, a associação é uma relação que descreve um conjunto de
vínculos entre elementos de modelo. Representa a ligação entre classes
ou objetos de classes, podendo ambas conhecer-se. Uma associação é
definida em UML como relacionamento. Pode-se colocar uma seta no final
da associação indicando que esta só pode ser usada para o lado onde a
seta aponta. Mas associações também podem possuir dois nomes,
significando um nome para cada sentido da associação. A seguir, alguns
exemplos de associações.
Associação normal (bidirecional)
Associação Recursiva
Associação Qualificada
Portanto, tem-se que a “letra A” é o item incorreto.

GABARITO: A.
40. (FUMARC/2009/PREFEITURA DE GOVERNADOR VALADARES/

Analista de Sistemas) Sobre UML e padrões, assinale a alternativa
INCORRETA:

a) A UML define responsabilidade como um contrato ou obrigação de

um objeto em termos do seu comportamento. Os tipos básicos de
responsabilidade previstos são a responsabilidade de fazer e a
responsabilidade de saber.
b) Os padrões GRASP descrevem princípios fundamentais de projeto
baseado em objetos e atribuição de responsabilidades aos mesmos. Os
cinco padrões GRAPS fundamentais são: Especialista da Informação
(Information Expert), Criador (Creator), Alta coesão (High Cohesion),
Baixo acoplamento (Low Coupling), Controlador (Controller).
c) Diagrama de atividade modela aspectos dinâmicos do sistema.
Enquanto os diagramas de interação dão ênfase ao fluxo de controle de
um objeto para outro, os diagramas de atividades dão ênfase ao fluxo
de controle de uma atividade para outra.
d) Diagramas de implementação modelam a visão estática e dinâmica
da implementação de um sistema. Isso envolve a modelagem da
topologia do hardware em que o sistema é executado e todo o fluxo de
atividades a serem realizadas no processo de distribuição e
implantação do sistema.
Comentários
Vamos concentrar nosso comentário na letra D, que é a INCORRETA. As
demais possuem afirmações verdadeiras.
Os diagramas de implementação representam a arquitetura física do
sistema. Eles mapeiam a arquitetura lógica de classes em termos de nós
de processamento e comunicação e a dependência entre eles. Eles, ainda,
representam o hardware e o relacionamento entre o hardware e o
software.
São dois os diagramas de implementação:
 Diagrama de Componentes – mostra aspectos sobre a estrutura em
termos de código fonte; e
 Diagrama de Implantação – mostra aspectos sobre a estrutura em
termos de tempo de execução.
Não podemos dizer que os diagramas de implementação são empregados
para a modelagem de aspectos dinâmicos do sistema. Os diagramas de
implementação modelam aspectos estáticos!
Vamos destacar, ainda, o padrão GRASP (General Responsibility
Assignment Software Patterns), que pode gerar alguma dúvida. Os
padrões GRASP descrevem os princípios fundamentais para a atribuição
de responsabilidades em projetos orientados a objetos. São 5 os
principais:
 Especialista na informação: Padrão mais utilizado para atribuir
responsabilidades, é aquele que atribui responsabilidades a quem
realmente detêm a informação necessária para preencher os
requisitos daquela responsabilidade.

 Padrão Criador: qual a classe responsável por criar instâncias de

outra?
 Baixo Acoplamento: responsável por minimizar dependências entre
as classes e maximizar o reuso.
 Alta Coesão: responsável por manter a alta coesão entre as classes,
ou seja, delegar responsabilidades e não deixar que certas classes
assumam responsabilidades de outras.
 Controlador: responsável por tratar eventos do sistema, eventos são
operações geradas por um ator externo do sistema.
GABARITO: D.
41. (FUMARC/2008/SEPLAG/Gestor Governamental Tecnologia

da Informação) Em relação aos casos de uso, analise as afirmativas
abaixo e assinale a opção CORRETA:
I – Um caso de uso descreve uma seqüência de ações que agregam
valor para um ator.
II – Um ator é uma pessoa, organização ou sistema externo que exerce
um papel em uma ou mais interações com o sistema.
III – Uma associação entre um ator e um caso de uso existe se um ator
está envolvido com alguma interação descrita por um caso de uso.
a) As afirmativas I, II e III são verdadeiras.
b) Apenas as afirmativas I e II são verdadeiras.
c) Apenas as afirmativas I e III são verdadeiras.
d) Apenas as afirmativas II e III são verdadeiras.
Comentários
Todas as assertivas estão corretas.
Item a. Os casos de uso descrevem a funcionalidade do sistema percebida
por atores externos.
Item b. Um ator é algo ou alguém com algum comportamento, tal como
uma pessoa (identificada por um papel), um sistema de computador, ou
uma organização. A figura seguinte ilustra um caso de uso com mais de
um ator interagindo.
Figura. Caso de uso com mais de um ator interagindo.

Fonte: Revista Engenharia de Software, ano 1, edição 3
Item c. A associação entre um ator e um caso de uso existirá se o ator

estiver envolvido com alguma interação descrita pelo caso de uso.
GABARITO: A.

da Informação) Em relação aos diagramas UML, analise as
afirmativas abaixo e assinale a opção CORRETA:
I – Diagramas de atividades podem ser usados para modelar processos
de negócio.
II – Diagramas de seqüência podem ser usados para detalhar cenários
de casos de uso.
III – Diagramas de tempo representam o encadeamento de atividades
de um projeto.
Comentários
Item A. Item correto. Os diagramas de atividades são representados por
um grafo orientado cíclico, podendo conter nós de diferentes tipos. As
arestas do grafo definem a ordem de execução entre as atividades e
objetos representados no grafo. Existem diferentes tipos de nós, cada um
possuindo uma semântica específica.
Abaixo tem-se a descrição de alguns deles, e na figura seguinte a
representação gráfica:
Figura. Elementos do Diagrama de Atividades

 Nó inicial: o círculo negro que marca o início do diagrama. Todo

diagrama possui apenas um estado inicial que é onde o fluxo se inicia.
 Nó final: é representado por um círculo negro com outro círculo por
fora. O diagrama pode possuir múltiplos nós finais, que são onde
determinado fluxo de execução se encerra.
 Atividade: os retângulos com cantos arredondados representam as
atividades. Uma atividade é a unidade em que alguma tarefa é
executada.
 Divisão: uma barra negra (horizontal ou vertical) com uma seta
entrando e múltiplas saindo. A divisão é um ponto do diagrama em que
dois ou mais fluxos concorrentes são criados.
 Junção: uma barra negra (horizontal ou vertical) com múltiplas setas
entrando e apenas uma saindo. A Junção é um ponto em que dois ou
mais fluxos se juntam novamente em um único fluxo.
 Decisão: um losango com uma seta chegando e diversas saindo. As
setas de saída normalmente incluem condições. Por isso, após uma
decisão apenas um destes fluxos é selecionado.
 Junção da Decisão: um losango com múltiplas setas entrando e
apenas uma saída. Marca o ponto em que os diversos fluxos que saem
de uma decisão são unidos novamente.
 Emissão de Evento / Recebimento de Evento: um evento ocorre
quando o fluxo de execução passa de uma parte do diagrama para
outra. Quando o fluxo chega em um objeto de emissão de evento ele
automaticamente passa para o ponto em que se encontra o objeto de
recebimento de evento associado a ele.
 Produto / Recurso: representa um produto produzido pela execução
de uma atividade, ou um recurso necessário para executá-la. É
representado por um quadrado, e pode estar associado a uma
atividade por setas pontilhadas (Fluxo de Objetos).
 Raias: definem partições do diagrama. São muito utilizadas para
identificação de responsabilidades. Atividades localizadas na mesma
raia utilizariam o mesmo tipo de recurso.
Um exemplo de diagrama de atividades pode ser visualizado na figura
seguinte. O exemplo retrata um diagrama de atividades que utiliza os
objetos definidos acima, para representar um processo simplificado de
desenvolvimento de software.

Item b. Item correto. Os diagramas de sequência podem ser usados para

detalhar casos de uso ao mostrar possíveis sequências de eventos no
sistema.
Item c. Item errado. O Diagrama de Tempo é semelhante ao diagrama de

Máquina de Estados, porém enfoca as mudanças de estado de um objeto
ao longo do tempo, útil para modelagem de sistemas de tempo real.
GABARITO: B.


da Informação) São diagramas da UML, EXCETO:
a) Diagrama de classes.
b) Diagrama de colaboração.
c) Diagrama de componentes.
d) Diagrama de procedimentos.
Comentários
Item a. Item correto. O Diagrama de Classes permite a visualização das
classes utilizadas pelo sistema e como estas se relacionam.
Item b. Item correto. O Diagrama de Colaboração dá ênfase à ordenação
estrutural em que as mensagens são trocadas entre os objetos de um
sistema.
Figura. Exemplo de um diagrama de Colaboração

Fonte:
http://pt.wikipedia.org/wiki/Diagrama_de_colabora%C3%A7%C3%A3o
Item c. Item correto. O Diagrama de Componentes identifica os
componentes que fazem parte de um sistema, um subsistema ou mesmo
os componentes ou classes internas de um componente individual.
Item d. Item errado, não se trata de um diagrama da UML.
GABARITO: D.

da Informação) Em relação aos relacionamentos na UML, analise as
afirmativas abaixo e escolha a opção CORRETA:
I – Composição é um tipo especial de associação que modela um
relacionamento “todo/parte” entre classes em que a parte é
dependente do todo.

Conta Corrente Poupança
GABARITO: B.
45. (CESPE/2009/ANATEL) O método de análise de pontos de função

descreve como calcular as dez características gerais de um sistema, as
quais são usadas para produzir, juntamente com outras informações, a
contagem de pontos de função ajustados.
Comentários
A APF utiliza o fator de ajuste com o objetivo de corrigir eventuais
distorções no cálculo do tamanho funcional da aplicação. A forma de
cálculo do tamanho funcional é a mesma para vários sistemas com
características diferentes e estas divergências são corrigidas pelo fator de
ajuste. O tamanho funcional pode ser o mesmo, mas algumas
características de um determinado sistema pode torná-lo mais complexo
do que outro:
1. Comunicação de dados;
2. Funções distribuídas;
3. Performance;
4. Configuração do equipamento;
5. Volume de transações;
6. Entrada de dados on-line;
7. Interface com o usuário;
8. Atualização on-line;
9. Processamento complexo;
10. Reusabilidade;
11. Facilidade de implantação;
12. Facilidade operacional;
13. Múltiplos locais;
14. Facilidade de mudanças.
Estas características gerais do sistema (14) podem modificar o tamanho

em um intervalo de –35% a +35%. O que leva a um fator de ajuste de
0,65 a 1,35.
Processo de cálculo do fator de ajuste:

 Avaliar o impacto de cada uma das 14 características em relação ao

sistema que está sendo avaliado, atribuindo pontuação de 0 a 5
para cada característica.
 Calcular o nível de influência através da soma dos pontos obtidos
em cada uma das 14 características.
 Aplica-se a fórmula: Fator de Ajuste = (NI * 0,01) + 0,65
GABARITO: ERRADO.
46. (CESPE/2009/TCE-RN) Na análise de ponto de funções, a

contagem de pontos relativos aos arquivos lógicos internos que se
referem a grupo de dados ou informações de controle logicamente
relacionados, reconhecidos pelo usuário e mantidos dentro da fronteira
da aplicação, é contabilizada como pontos não ajustados.
Comentários
O Manual de Práticas de Contagem do International Function Point Users
Group (IFPUG) identifica cinco tipos de funções que são contadas e
avaliadas:
1. Arquivo Lógico Interno (ALI)
2. Arquivo de Interface Externa (AIE)
3. Entrada Externa (EE)
4. Saída Externa (SE)
5. Consulta Externa (CE)
Etapas para avaliação
1. Identificação do tipo de contagem a ser utilizado
2. Definição da fronteira da aplicação
3. Contagem de pontos de função não ajustados
4. Cálculo do fator de ajuste
5. Contagem de pontos de função ajustados
GABARITO: CERTO.
47. (CESPE/2009/ANATEL) A análise de pontos de função de um

programa produz estimativas de tamanho funcional de um produto de
software embasada em cinco parâmetros-chave: entradas externas,
saídas externas, consultas externas, arquivos lógicos internos e
arquivos de interface externos. Os três primeiros parâmetros são
funções transacionais, enquanto os dois últimos são funções de dados.
As operações CRUD (create, read, update e delete) são consideradas
pertencentes às entradas externas.

Comentários
A questão está errada por conta da parte final: “As operações CRUD
(create, read, update e delete) são consideradas pertencentes às entradas
externas”. Naverdade apenas create, update e delete são entradas
externas, uma vez que atualizam arquivos lógicos internos. Mas a
operação Read é consulta externa, pois objetiva recuperar dados
armazenados nos arquivos lógicos.
GABARITO: item ERRADO.

3. Lista das Questões Comentadas
1. (FUNRIO/2009/FURNAS/Engenheiro da Computação) Um
estereótipo em UML é
A) uma forma de organizar diversos elementos de um modelo em
grupos.
sistema.
C) um mecanismo usado para estender o significado de um elemento
em um diagrama.
interconectados.
2. (FUNRIO/2008/Analista de Sistemas) Julgue os itens a seguir

referentes aos diagramas da notação UML e assinale a alternativa
correta:
I. O Diagrama de Classe captura a estrutura estática do sistema e
serve de base para os outros diagramas;
II. O Diagrama de Casos de Uso pode ser facilmente compreendido
pelo usuário do sistema e é utilizado para modelar as interações entre
os atores e o sistema;
III. O Diagrama de Estado apresenta uma visão dinâmica do sistema e
é usado para modelar os fluxos de atividades de negócio em uma
aplicação.
A) Nenhuma alternativa está correta.
B) Apenas as alternativas I e II estão corretas.
C) Apenas as alternativas I e III estão corretas.
D) Apenas as alternativas II e III estão corretas.
E) Todas as alternativas estão corretas.
3. (FUNRIO/2008/Analista de Sistemas) Generalização é um conceito

de análise orientada a objetos que consiste:
A) Em definir propriedades ou métodos adicionais, tornando uma nova
classe semelhante à classe que lhe deu origem, mas com propriedades
e métodos específicos.
B) No processo de agrupar diversas classes em uma superclasse de
acordo com suas propriedades comuns.

C) Na habilidade de duas ou mais classes responderem à mesma

solicitação, cada uma a seu modo.
D) No processo de abstração por meio do qual as classes e objetos são
identificados univocamente.
E) Na abstração pela qual os relacionamentos são tratados como
entidades de nível superior.
4. (FUNRIO/2008/Analista de Sistemas)
O diagrama acima na notação UML é denominado:

A) diagrama de colaboração
B) diagrama de fluxo de dados
C) diagrama de transição de estados
D) diagrama de casos de uso
E) diagrama de contexto
5. (FUNRIO/2008/Analista de Sistemas) Na orientação a objetos,

classes que NÃO geram instâncias diretas (objetos) são denominadas
classes
A) derivadoras
B) primárias.
C) virtuais.
D) básicas.
E) abstratas.

6. (FUNRIO/2008/Analista de Sistemas) São exemplos de diagramas

comportamentais da UML, os diagramas
A) de Pacotes e de Fluxos de Dados.
B) de Classes e de Objetos.
C) de Componentes e de Implantação.
D) de Casos de Uso e de Atividades.
E) de Estruturas e de Entidades Relacionamentos.
7. (FUNRIO/2009/Analista de Sistemas V) Um estereótipo em UML é

A) um mecanismo usado para estender o significado de um elemento
em um diagrama.
sistema.
C) uma forma de organizar diversos elementos de um modelo em
grupos.
interconectados.
8. (FUNRIO/2009/Analista de Sistemas V) Considere uma classe

ContaBancária e suas duas subclasses ContaCorrente e
ContaPoupança, cada uma das três com o método AplicarJuros. A
redefinição do método AplicarJuros nas duas subclasses, cada uma com
detalhes de implementação diferentes com a mesma interface,
caracteriza o princípio denominado na orientação a objetos como
A) herança.
B) encapsulamento.
C) polimorfismo.
D) unificação.
E) abstração.
9. (FUNRIO/2009/Analista de Sistemas V) São tipos de relacionamentos

entre casos de uso
A) extensão e inclusão.
B) agregação e composição.
C) participação e derivação.

D) conexão e colaboração.
E) interação e navegação.
10. (FUNRIO/2009/Tecnologia em Sistemas) O diagrama da modelagem

de sistemas que é usado na modelagem dos fluxos de trabalho de um
processo de negócio é o diagrama de
A) classes.
B) sequência.
C) estados.
D) atividades.
E) componentes.
11. (FUNRIO/2009/Tecnologia em Sistemas) Na terminologia da

UML, o dado sobre limites inferior e superior da quantidade de objetos
aos quais um outro objeto pode estar associado (por exemplo, um
cliente pode estar associado a 0 ou vários pedidos) é denominado
A) multiplicidade.
B) participação.
C) associatividade.
D) conectividade.
E) responsabilidade.
12. (FUNRIO/2009/Tecnologia em Sistemas) Considere a

sentença: “Uma equipe é formada por diversos jogadores”. Que tipo de
associação caracteriza o relacionamento entre equipe e jogadores?
A) Classificação.
B) Composição.
C) Agregação.
D) Generalização.
E) Pertinência.
13. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) Um modelo é

uma abstração de algo com a finalidade de entendê-lo antes de
construí-lo. Todo sistema desenvolvido deve ser modelado e, nesse
sentido, existem pontos de vista distintos, porém relacionados, cada
qual capturando aspectos importantes e necessários para uma
descrição completa. Enquanto o modelo de interações representa a
colaboração de objetos individuais, os aspectos de “interações” de um

A) Funcional
B) De Classes
C) De Contexto
D) De Atividades
E) Comportamental
15. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) No que tange

aos paradigmas da Orientação a Objetos (OO), um princípio está
diretamente relacionado às operações realizadas por um objeto e ao
modo como as operações são executadas, constituindo uma forma de
restringir o acesso ao comportamento interno de um objeto. Nesse
processo, um objeto que precise da colaboração de outro para realizar
alguma tarefa deve enviar uma mensagem a este último. Além disso,
separa os aspectos externos de um objeto dos detalhes internos da
implementação. Considerando esse contexto, observe a figura abaixo.
O princípio da OO é conhecido por:

A) Compartilhamento
B) Acoplamento
C) Herança
D) Polimorfismo
E) Encapsulamento

16. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) A UML é uma

linguagem de modelagem visual, podendo ser definida como um
conjunto de notações e semântica correspondente para representar
visualmente uma ou mais perspectivas de um sistema. Dentre os
diagramas da UML, um diagrama foca os requisitos funcionais de um
sistema, forçando os desenvolvedores a moldarem o sistema de acordo
com o usuário, e não o usuário de acordo com o sistema,
representando as especificações de uma sequência de interações entre
um sistema e os agentes externos que utilizam esse sistema, por meio
dos atores e relacionamentos entre eles. Esse diagrama é denominado:
A) Casos de uso
B) Casos de negócios
C) Processos e funções
D) Entidades e relacionamentos
E) Processos e relacionamentos
17. (ESAF/2008/MPOG) Os requisitos de um sistema são descrições

dos serviços fornecidos pelo sistema e as suas restrições operacionais.
Indique a opção que corretamente se relaciona com a análise ou
gerenciamento de requisitos.
a) Requisitos de sistema são declarações do usuário que definem,
detalhadamente, as funções, os serviços e as restrições operacionais
do sistema.
b) As representações de dados usadas nas interfaces de sistemas são
exemplos de requisitos funcionais.
c) A exigência de que o sistema deva fornecer telas apropriadas para o
usuário ler os documentos no repositório de documentos é um exemplo
de requisito funcional.
d) A exigência de que o sistema não deva revelar quaisquer
informações pessoais sobre os usuários do sistema ao pessoal de
vendas que o utiliza, com exceção do nome e cargo, é um exemplo de
requisito funcional.
e) Avaliar se os requisitos associados ao desempenho, ao
comportamento e às características operacionais do sistema foram
explicitamente declaradas é uma tarefa de especificação de requisitos.

Área: Tecnologia da Informação) A abordagem embasada em
objetos preocupa-se primeiro em identificar os objetos contidos no
domínio da aplicação e, em seguida, em estabelecer os procedimentos
relativos a eles.


modelagem de classes, a hierarquia entre elas é representada por meio
de um relacionamento chamado generalização.

modelagem do comportamento dos objetos de um sistema pode ser
feita por meio do modelo de objetos do sistema.

análise orientada a objetos é inadequada a situações em que os dados
do sistema devam ser armazenados em um sistema de banco de dados
relacional.

Área: Tecnologia da Informação — ANÁLISE DE SISTEMAS) O
comportamento de um objeto é definido em sua respectiva classe, por
meio da implementação de métodos que são executados quando tal
objeto recebe uma mensagem.

Área: Tecnologia da Informação — ANÁLISE DE SISTEMAS) Por
meio do recurso da sobrecarga de métodos, as subclasses podem
implementar um comportamento específico para um método herdado
da sua superclasse.

Área: Tecnologia da Informação — ANÁLISE DE SISTEMAS)
Objetos têm identidade própria. Isso garante que, mesmo tendo os
mesmos valores de variáveis e pertencendo à mesma classe, dois
objetos sejam considerados diferentes.

Área: Tecnologia da Informação — ANÁLISE DE SISTEMAS) Em
um programa orientado a objetos, determinada mensagem a objeto
sempre leva à execução do mesmo método, todas as vezes que o
programa é executado.

Considerando o diagrama acima, julgue os itens seguintes.
26. (CESPE/2010/ IJSN/ES/ Informática e Gestão da

Informação) Considerando apenas a questão semântica do diagrama,
a existência do elemento requisição pressupõe uma cardinalidade N
para N entre os elementos sujeito e monitor de referência.
27. (CESPE/2010/IJSN/ES/Informática e Gestão da Informação)

Entre os elementos conjunto_regras_autorização e autorização existe
um relacionamento do tipo agregação.
Com base no diagrama UML acima, julgue os itens a seguir.

Área: Tecnologia da Informação — ANÁLISE DE SISTEMAS) Está

representada uma relação de composição entre a classe Funcionario e

a classe Curriculo.

Área: Tecnologia da Informação — ANÁLISE DE SISTEMAS) Os
atributos de objetos da classe Funcionario poderiam ser diretamente
acessados por objetos da classe Curriculo.

classe Gerente, ocorre a sobrecarga do método calculaSalario().

Área: Tecnologia da Informação — ANÁLISE DE SISTEMAS) De
acordo com as características da relação entre a classe Funcionario e a
classe Curriculo, ao se excluir um funcionário desse sistema, também
serão removidos os respectivos dados curriculares da base de dados.

Área: Tecnologia da Informação — Arquitetura de Tecnologia) O
desenvolvedor deve utilizar herança múltipla para agilizar os processos
de busca e execução dos processos.

Área: Tecnologia da Informação — Arquitetura de Tecnologia)
Em diversos casos de orientação a objetos, é necessário realizar
alguma(s) ação(ões) para o objeto poder ser destruído. Um exemplo
disso é a desalocação dinâmica de memória.

Tendo o diagrama UML da figura acima como referência, julgue os

seguintes itens.

EXTERNO/ÁREA: TI) O método #Cadastrar() da classe Instrutor tem
visibilidade do modo protegido tal que somente a classe possuidora
Instrutor pode utilizá-lo.

EXTERNO/ÁREA: TI) Na associação do tipo agregação composta
identificado por #2, uma instância da classe Departamento pertence
exclusivamente a uma única instância composta em Escola, e um
objeto da classe Escola pode relacionar-se com, no máximo, três
objetos da classe Departamento.

VALADARES/Analista de Sistemas) Sobre os princípios de análise e
projeto orientados para objetos e a UML, assinale a alternativa
INCORRETA:
a) Cenário ou instância de caso de uso: é uma sequência de ações e
interações entre atores e o sistema em discussão.
b) Modelo de Dados: inclui os esquemas de Bancos de Dados e as
estratégias de mapeamento entre as representações baseadas em
objeto e as representações não baseadas em objetos.
c) Modelo de Domínio: e a representação visual das classes conceituais
no domínio do problema. É também chamado de modelo conceitual.

d) Modelo Comportamental: especificação de todos os processos que

irão compor o sistema. Os processos são representados no DFD.

VALADARES/Analista de Sistemas) Sobre o Diagrama de Casos de
Uso e a UML, assinale a alternativa CORRETA:
a) Um ator é algo ou alguém com algum comportamento, tal como
uma pessoa (identificada por um papel), um sistema de computador,
ou uma organização.
b) O Diagrama de casos de uso determina a relação entre os atores e
os requisitos funcionais do sistema, substituindo a representação
textual dos casos de uso.
c) Os relacionamentos existentes entre os elementos usados no modelo
de casos de uso incluem: comunicação, inclusão, extensão, herança,
agregação, composição, encapsulamento e polimorfismo.
d) Casos de uso são representações em baixo nível das funções que
um ator deseja executar no sistema, incluindo a forma de
representação dos atributos e operadores necessários a esta execução.

VALADARES/Analista de Sistemas) Um processo administrativo na
prefeitura pode se encontrar nas seguintes situações: iniciado, em
execução, pendente ou finalizado. O instrumento da UML que melhor
representa o fluxo de passagem de um estado para o outro no
processo acima é:
a) diagrama entidades-relacionamentos.
b) diagrama de atividade.
c) diagrama de transições de estado.
d) diagrama de fluxo de dados.

VALADARES/Analista de Sistemas) Quanto ao Processo Unificado e
a UML, assinale a alternativa INCORRETA:
a) Associações implementam relações unidirecionais entre classes,
sendo necessárias duas associações para implementar uma relação
bidirecional entre duas entidades.
b) Se toda instância da classe C for obrigatoriamente uma instância de
uma subclasse de C, então C é uma classe conceitualmente abstrata.
c) A presença de uma associação com cardinalidade de muitos-para-
muitos é um forte indicativo de que será necessário criar uma classe de
associação.

d) A composição é um tipo de associação com dependência de tempo

de vida entre a classe que representa a parte e a classe que representa
o todo.
40. (FUMARC/2009/PREFEITURA DE GOVERNADOR VALADARES/

Analista de Sistemas) Sobre UML e padrões, assinale a alternativa
INCORRETA:
a) A UML define responsabilidade como um contrato ou obrigação de
um objeto em termos do seu comportamento. Os tipos básicos de
responsabilidade previstos são a responsabilidade de fazer e a
responsabilidade de saber.
b) Os padrões GRASP descrevem princípios fundamentais de projeto
baseado em objetos e atribuição de responsabilidades aos mesmos. Os
cinco padrões GRAPS fundamentais são: Especialista da Informação
(Information Expert), Criador (Creator), Alta coesão (High Cohesion),
Baixo acoplamento (Low Coupling), Controlador (Controller).
c) Diagrama de atividade modela aspectos dinâmicos do sistema.
Enquanto os diagramas de interação dão ênfase ao fluxo de controle de
um objeto para outro, os diagramas de atividades dão ênfase ao fluxo
de controle de uma atividade para outra.
d) Diagramas de implementação modelam a visão estática e dinâmica
da implementação de um sistema. Isso envolve a modelagem da
topologia do hardware em que o sistema é executado e todo o fluxo de
atividades a serem realizadas no processo de distribuição e
implantação do sistema.

da Informação) Em relação aos casos de uso, analise as afirmativas
abaixo e assinale a opção CORRETA:
I – Um caso de uso descreve uma seqüência de ações que agregam
valor para um ator.
II – Um ator é uma pessoa, organização ou sistema externo que exerce
um papel em uma ou mais interações com o sistema.
III – Uma associação entre um ator e um caso de uso existe se um ator
está envolvido com alguma interação descrita por um caso de uso.


da Informação) Em relação aos diagramas UML, analise as
afirmativas abaixo e assinale a opção CORRETA:
I – Diagramas de atividades podem ser usados para modelar processos
de negócio.
II – Diagramas de seqüência podem ser usados para detalhar cenários
de casos de uso.
III – Diagramas de tempo representam o encadeamento de atividades
de um projeto.

da Informação) São diagramas da UML, EXCETO:
a) Diagrama de classes.
b) Diagrama de colaboração.
c) Diagrama de componentes.
d) Diagrama de procedimentos.

da Informação) Em relação aos relacionamentos na UML, analise as
afirmativas abaixo e escolha a opção CORRETA:
I – Composição é um tipo especial de associação que modela um
relacionamento “todo/parte” entre classes em que a parte é
dependente do todo.
II – Associação é um relacionamento estrutural que especifica objetos
de um item conectados a objetos de outro item.
III – Generalização é o relacionamento que caracteriza a herança entre
classes e a seta deve ser representada sempre em direção à classe-
filha.
a) Apenas a afirmativa I é verdadeira.

45. (CESPE/2009/ANATEL) O método de análise de pontos de função

descreve como calcular as dez características gerais de um sistema, as
quais são usadas para produzir, juntamente com outras informações, a
contagem de pontos de função ajustados.
46. (CESPE/2009/TCE-RN) Na análise de ponto de funções, a

contagem de pontos relativos aos arquivos lógicos internos que se
referem a grupo de dados ou informações de controle logicamente
relacionados, reconhecidos pelo usuário e mantidos dentro da fronteira
da aplicação, é contabilizada como pontos não ajustados.
47. (CESPE/2009/ANATEL) A análise de pontos de função de um

programa produz estimativas de tamanho funcional de um produto de
software embasada em cinco parâmetros-chave: entradas externas,
saídas externas, consultas externas, arquivos lógicos internos e
arquivos de interface externos. Os três primeiros parâmetros são
funções transacionais, enquanto os dois últimos são funções de dados.
As operações CRUD (create, read, update e delete) são consideradas
pertencentes às entradas externas.

4. Gabaritos
01 02 03 04 05 06 07 08 09 10
C B B D E D A C A D
11 12 13 14 15 16 17 18 19 20
A C A D E A C C C E
21 22 23 24 25 26 27 28 29 30
E C E C E C E C E E
31 32 33 34 35 36 37 38 39 40
C E C E C D A C A D
41 42 43 44 45 46 47 48 49 50
A B D B E C E

Aula 01 - Questoes Comentadas

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aula 01 - Questoes Comentadas

Enviado por

Direitos autorais:

Formatos disponíveis

Noções de Informática INSS/TEINF

AULA 1: Análise e Projeto de Sistemas.

3. Lista das questões comentadas na aula 64

Sejam bem-vindos ao nosso curso de Conhecimentos específicos

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 1/79

Aspectos da Orientação a Objetos

A expressão “orientado a objetos" significa que o software é organizado

c. Ênfase na Estrutura de Objetos

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 2/79

compartilhadas como também oferece a possibilidade da reutilização de

f. Combinação de dados e o Comportamento

MODELAGEM ORIENTADA A OBJETOS

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 3/79

Management Group, www.omg.org) como linguagem padrão para

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 4/79

b) Visão de Projeto – apresenta como a funcionalidade do sistema será

c) Visão de Interação – mostra o fluxo de controle entre várias partes

d) Visão de Implementação - mostra a organização física

e) Visão de Implantação - é a descrição da topologia (nós) em que o

4 Análise Orientada a Objetos

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 6/79

5 - Diagramas de Caso de Uso

 Definir Escopo: um conjunto de Casos de Uso define o escopo do

Uma das questões em aberto sobre os Casos de Uso é a confusão que

Componentes do Diagrama de Casos de Uso

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 7/79

Classes são componentes do contexto no qual o software está

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 11/79

Os atributos descrevem um objeto de uma classe em um certo domínio,

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 12/79

 Associação - é uma conexão entre classes, e também significa que

 Agregação - tipo especial de associação, em que um objeto é parte

 Generalização - é um relacionamento de um elemento mais geral e

Todos estes relacionamentos são mostrados no diagrama de classes

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 13/79

2. (FUNRIO/2008/Analista de Sistemas) Julgue os itens a seguir

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 17/79

3. (FUNRIO/2008/Analista de Sistemas) Generalização é um conceito

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 18/79

generalização consiste no processo de agrupar diversas classes em uma

O diagrama acima na notação UML é denominado:

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 19/79

5. (FUNRIO/2008/Analista de Sistemas) Na orientação a objetos,

6. (FUNRIO/2008/Analista de Sistemas) São exemplos de diagramas

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 20/79

7. (FUNRIO/2009/Analista de Sistemas V) Um estereótipo em UML é

8. (FUNRIO/2009/Analista de Sistemas V) Considere uma classe

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 21/79

voltada mais as classes, o polimorfismo está voltado aos métodos e a

9. (FUNRIO/2009/Analista de Sistemas V) São tipos de relacionamentos

10. (FUNRIO/2009/Tecnologia em Sistemas) O diagrama da modelagem

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 22/79

11. (FUNRIO/2009/Tecnologia em Sistemas) Na terminologia da

12. (FUNRIO/2009/Tecnologia em Sistemas) Considere a

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 23/79

13. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) Um modelo é

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 24/79

Classificação significa que os objetos com a mesma estrutura de dados

Os Diagramas de Máquinas de Estados, ou simplesmente Diagramas

14. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) A Engenharia

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 25/79

15. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) No que tange

Prof. Alexandre Lênin www.estrategiaconcursos.com.br 27/79