Aula 05: Engenharia de Software para Concursos - Curso Regular

Aula 05
Engenharia de Software para Concursos - Curso Regular

Professor: Diego Carvalho
Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05
AULA 05
SUMÁRIO PÁGINA
Apresentação 01
- UML: Visão Geral, Modelos E Diagramas 03
Lista de Exercícios Comentados 173
Gabarito 230
16712855225
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 1 de 231

Engenharia de Software. Conceitos Básicos ou Gerais. Ciclo de vida do software. Modelos,

Metodologias ou Processos de Desenvolvimento de Software: Modelo em Cascata. Modelo Orientado
a Reuso. Modelo em Prototipagem, Modelo Evolucionário, Modelo Espiral, Modelo Formal, RAD, Modelo
Iterativo e Incremental. Processo Unificado: Conceitos Básicos, Dimensões Dinâmica, Estática e
Prática, Gráfico das Baleias, Fases (Iniciação, Elaboração, Construção e Transição), Disciplinas ou
Fluxo de Processos (Modelagem de Negócio, Requisitos, Análise e Projeto, Implementação, Teste,
Implantação, Gestão de Configuração e Mudança, Gestão de Projetos, Ambiente), Artefatos,
Atividades, Melhores Práticas, Principais Marcos, Princípios Chaves. Metodologias Ágeis de
Desenvolvimento de Software: Scrum, eXtreme Programming (XP), Feature-driven Development
(FDD), Test-driven Development (TDD), Acceptance Test-driven Development (ATDD), Kanban.
Definição de Requisito, Classificação de Requisitos (Funcional, Não- Funcional, Domínio; Produto,
Organizacional, Externo; Confiabilidade, Proteção, Desempenho, etc); Engenharia de Requisitos:
Estudo de Viabilidade, Elicitação e Análise de Requisitos, Especificação de Requisitos, Validação de
Requisitos, Gestão de Requisitos. Técnicas de Elicitação e Técnicas de Validação. Linguagem de
Modelagem: Unified Modeling Language (UML) 2.x – Contexto Histórico, Conceitos Básicos, Tipos de
Diagramas (Estruturais, Comportamentais, Interação). Diagramas de Classes, Componentes,
Implantação, Perfil, Objetos, Estrutura Composta, Pacotes, Máquina de Estados, Casos de Uso,
Atividades, Sequência, Comunicação, Interação Geral e Tempo. Conceitos Básicos do Paradigma
Estruturado. Conceitos Básicos de Orientação a Objetos: Classes, Objetos, Atributos, Métodos,
Mensagens, Abstração, Encapsulamento, Polimorfismo, Herança, Relacionamentos). Análise e
Projeto: Conceitos Básicos, Diferenças, Modelos, Classes de Fronteira, Controle e Entidade. Análise
de Pontos de Função: IFPUG – Definição e Contexto, Benefícios e Vantagens, Componentes de Dados
(AIE, ALI) e Transação (EE, SE, CE), Etapas do Procedimento de Contagem: Determinar Tipo de
Contagem, Determinar Escopo e Fronteira, Cálculo dos Pontos de Função Não-Ajustados, Cálculo do
Fator de Ajuste, Cálculo dos Pontos de Função Ajustados. NESMA - Tipos de Contagem e Deflatores.
Qualidade de Software: Garantia e Controle, Principais Características, Verificação & Validação,
Erro, Falha, Falta e Defeito. Testes de Software: Conceitos Básicos, Processo de Testes, Técnicas de
Testes (Teste Caixa Banca, Cinza e Preta), Níveis de Testes (Teste de Unidade, Módulo, Componente;
16712855225
Teste de Integração; Teste de Aceitação, Validação, Release; Teste de Sistema/Funcional). Tipos de

Testes: Carga, Estresse, Volume, Desempenho, Usabilidade, Cenários, Regressão, Back-to-Back,
Comparação, Recuperação, Alfa, Beta, Compatibilidade, Estático, Dinâmico). Arquitetura de
Software. Arquitetura em Camadas (Cliente/Servidor). Arquitetura MVC. Arquitetura Distribuída.
Arquitetura Hub. Arquitetura Microsserviços. Arquitetura Mainframe. Arquitetura Orientada a
Serviços (SOA): Conceitos Básicos, SOAP, WSDL, UDDI. REST. WS-Security. Interoperabilidade de
Sistemas. e- PING: Conceitos Básicos, Interoperabilidade, Escopo, Políticas Gerais, Segmentação,
Gestão. Acessibilidade de Sistemas. e-MAG 3.1: Conceitos Básicos, Acessibilidade, Acesso, Passos
para um Sítio Acessível, Segmentos, Recomendações. Engenharia de Usabilidade. Gerenciamento
Eletrônico de Documentos (GED). Portais Corporativos e Colaborativos.

UML: VISÃO GERAL, MODELOS E DIAGRAMAS
Vamos primeiro resumir o contexto histórico! Havia uma empresa chamada Rational
Software Corporation. Sim, pessoal... é aquela mesma criadora do RUP! Em 1995, ela
conseguiu reunir três dos pesquisadores de Engenharia de Software mais
proeminentes do mundo: James Rumbaugh, Grady Booch e Ivar Jacobson –
conhecidos como The Three Amigos (imagem abaixo).
Rumbaugh era o criador da Técnica de Modelagem de Objetos (TMO). Já Booch

era o criador do método de Projeto Orientado a Objetos (POO). Por fim, Jacobson
era o criador do método de Engenharia de Software Orientada a Objetos (ESOO).
Esses três caras trabalhavam para a Rational, mas cada um seguia seus métodos e
técnicas de modelagem próprios.
Aliás, naquela época não havia uma linguagem de modelagem dominante. Havia
diversas linguagens, cada uma com vantagens e desvantagens. Foi aí que a Rational
se perguntou: Por que a famosa moderna tecnologia de Orientação a Objetos estava
demorando tanto para ser adotada de fato? A resposta foi, entre outras, que havia
um excesso de linguagens de modelagem.16712855225
Ora, ela não gostou da resposta e requisitou aos seus notáveis pesquisadores que
encontrassem uma solução! E o que eles fizeram? Reuniram-se, consultaram outros
pesquisadores, consolidaram seus métodos com as informações obtidas e
padronizaram tudo em uma linguagem de modelagem não-proprietária: Unified
Modeling Language (UML).
Naquela época, os fornecedores estavam com medo de que um padrão controlado

pela Rational desse uma vantagem competitiva desleal à empresa. Então, eles
incitaram a Object Management Group (OMG) – consórcio de empresas

responsável por estabelecer padrões que suportem interoperabilidade – a tomar

partido dessa padronização.
Essa consolidação surgiu por meio de intensas discussões com representantes de

tecnologias concorrentes. A UML é o resultado de vários métodos e visões distintas
de modelagem, como mostra a imagem abaixo. Em agosto de 1997, foi publicada a
UML 1.1 e, posteriormente, foi editada como um padrão internacional chamado
ISO/IEC 19501:2005.
Observem que a UML contou com a participação de outras empresas (IBM, HP,
Oracle, etc). Sendo assim, a OMG adotou a versão 1.1 como um padrão oficial! A
16712855225
revisão 1.2 foi só para melhorar as aparências, já a versão 1.3 trouxe mudanças mais
significativas. A revisão 1.4 acrescentou conceitos de componentes e perfis, e a
revisão 1.5 adicionou a semântica de ação.
Com o passar do tempo, a linguagem passou a integrar conceitos de diversos outros

métodos de orientação a objetos. Ademais, corrigiu diversos bugs e inconsistências
até cançar maturidade suficiente para avançar até a versão UML 2.0, em meados
de 2005. A partir de então, passou por diversas e pequenas atualizações até chegar
à versão atual: UML 2.4.1.

A UML pode ser definida como uma linguagem gráfica para especificar, visualizar,
construir e documentar artefatos primariamente de um sistema de software. Por que
primariamente, professor? Porque ela tem sido usada efetivamente em diversas
outras áreas, a saber: telecomunicações, defesa, aeroespacial, bancária, eletrônica,
financeira, entre outras.
Portanto, a UML não está limitada a modelagem de software. Aliás, ela é uma
linguagem tão expressiva que pode modelar outros sistemas, tais como um
fluxograma do sistema judiciário, o comportamento de um sistema de saúde pública
ou um projeto de hardware. Se a prova disser que é uma linguagem exclusiva de
software, vocês já sabem o que marcar!
Alguns a definem como uma linguagem padrão de modelagem visual usada para
modelagem de negócio e processos similares; além da análise, projeto e
implementação de sistemas baseados em software. Trata-se de uma linguagem
comum para analistas de negócio, arquitetos de software e desenvolvedores usada
em sistemas de software já existentes ou novos.
A UML é intencionalmente independente de processos, i.e., pode ser aplicada no

contexto de processos diferentes (Ex: RUP). Ademais, ela não é linguagem completa,
ou seja, dado apenas um diagrama, não é possível entender completamente o
comportamento do sistema; e não é completamente visual, ou seja, alguns conceitos
não têm notação gráfica alguma.
Mas por que utilizar a UML? Bem, Martin Fowler diz que é por conta da comunicação
e do entendimento. Um bom diagrama frequentemente pode ajudar uma equipe a
entender um problema e transmitir uma ideia. A notação gráfica é um meio termo
entre a imprecisão da linguagem natural e o detalhamento excessivo de uma
16712855225
linguagem de programação.
Pensem em como seria especificar um sistema só escrevendo ou falando! Já

imaginaram a quantidade de ambiguidades? A linguagem natural é simples demais!
Agora imaginem como seria especificar um sistema usando C++! Já imaginaram a
reação do usuário ao ver 400 linhas de código para entender uma classe? Códigos
detalham demais!
Bem, esse já seria um excelente motivo para se utilizar a UML. Ora, mas se resume
a isso? Não, ela é uma linguagem completamente não-dependente de tecnologia.
Professor, isso quer dizer que é possível usá-la com Linguagem Estruturada? Sim, com

C, Cobol, Pascal, etc. É independente de linguagem de programação, ferramentas,

entre outros.
Hoje em dia, ela se tornou não somente a notação gráfica mais dominante dentro
do mundo orientado a objetos, como também uma técnica popular nos círculos não
orientados a objetos. Por fim, cabe salientar que a UML é uma verdadeira
ferramenta de planejamento. Ela ajuda a apresentar uma visão geral do sistema
atual e futuro.
Na UML, existe a definição de uma linguagem formal utilizada para especificar as

restrições sobre os elementos de um modelo. Quem é capaz de me responder como
se chama essa linguagem? Chama-se Object Constraint Language (OCL). Trata-
de uma linguagem declarativa para descrever regras que se aplicam aos modelos
UML. Pode-se dividir a UML em quatro especificações:
 Infraestrutura da UML: especificação que contém o core da arquitetura, perfis

e estereótipos.
 Superestrutura da UML: especificação que contém os elementos de

modelagem estáticos e dinâmicos.
 Object Constraint Language (OCL): especificação que contém a linguagem

formal usada para descrever expressões em Modelos UML.
 Intercâmbio: especificação que contém formatos de intercâmbio de

diagramas para a UML.
A UML contém alguns mecanismos de uso geral muito importantes, tais como:
estereótipos, notas explicativas, tagged values, restrições e pacotes:
16712855225
 Estereótipo: mecanismo utilizado para estender o significado de determinado

elemento em um diagrama.
 Notas Explicativas: mecanismo utilizado para definir informação que comenta

ou esclarece alguma parte de um diagrama.
 Tagged Values: mecanismo utilizado para predefinir propriedades para

determinados elementos.

 Restrições: mecanismo utilizado para especificar restrições sobre um ou mais

valores de um ou mais elementos de um modelo.
 Pacotes: mecanismo utilizado para agrupar elementos semanticamente

relacionados (mais detalhes quando virmos Diagrama de Pacotes).
Estereótipos permitem adaptar ou personalizar modelos com construções

específicas para um domínio, plataforma ou método de desenvolvimento particular.
Trocando em miúdos, é um mecanismo de extensão que dá mais poder e
flexibilidade à UML. Podemos ter estereótipos de dois tipos: predefinidos pela
linguagem ou definidos pela equipe de desenvolvimento. Como assim, professor?
Estereótipos predefinidos já vêm nativamente na linguagem (Ex: <<interface>>,

<<document>>, <<control>>, <<entity>>). No entanto, a equipe de
desenvolvimento pode criar seus próprios estereótipos! Como? Basta colocar o
nome do elemento delimitado pelos símbolos << e >>. Além disso, os estereótipos
podem ser definidos textualmente ou graficamente.
Os estereótipos gráficos são representados por um ícone que lembre o significado

do conceito ao qual ele está associado. Na imagem acima, os dois estereótipos à
esquerda são predefinidos pela própria linguagem; já os dois à direita são exemplos
de possíveis estereótipos que podem ser construídos pela equipe de
desenvolvimento. Bacana?
16712855225
Rapaziada, vamos resumir o que vimos! Estereótipo é um mecanismo de uso geral

utilizado para aumentar as capacidades da Linguagem UML! Ora, antes era tudo
muito limitado, agora eu tenho infinitas possibilidades para representar um sistema.
Há duas classificações para estereótipos: podem ser predefinidos ou definidos pela
equipe de desenvolvimento.
Pode ser classificado também em estereótipos textuais e gráficos: os primeiros

devem vir delimitados pelos símbolos << e >>; os segundos devem vir com um
ícone que lembre o conceito sendo representado. Essas duas classificações são
independentes, logo é possível ter estereótipos gráficos ou textuais sendo
predefinidos ou definidos pela equipe de desenvolvimento. Ficou claro agora?

Notas explicativas são utilizadas para definir informação que comenta ou esclarece
alguma parte de um diagrama. Podem ser descritas em texto livre; também podem
corresponder a uma expressão formal utilizando a linguagem de restrição de
objetos da UML (OCL). Graficamente, as notas são representadas por um retângulo
com uma “orelhinha” – como é mostrado na imagem abaixo.
O conteúdo da nota é inserido no interior do retângulo e este é ligado ao elemento

que se quer esclarecer ou comentar através de uma linha tracejada. Ao contrário
dos estereótipos, as notas textuais não modificam nem estendem o significado do
elemento ao qual estão associadas, i.e., não criam algo novo – apenas explicam um
elemento do modelo sem modificar sua estrutura ou semântica.
Elementos UML possuem propriedades predefinidas! As classes, por exemplo,

possuem: Nome, Lista de Atributos e Lista de Operações. As Tagged Values (ou
Etiquetas Valoradas) são utilizadas para definir outras propriedades para
determinados elementos de um diagrama. A partir da UML 2.0, só é possível utilizá-
las em conjunto com estereótipos!
16712855225
A todo elemento da UML está associada alguma semântica. Isso quer dizer que cada
elemento gráfico dessa linguagem possui um significado bem definido que, uma
vez entendido, fica implícito na utilização do elemento em algum diagrama.
restrições permitem estender ou alterar a semântica natural de um elemento gráfico.
Bacana? Entendido?
Esse mecanismo geral especifica restrições sobre um ou mais valores de um ou mais

elementos de um modelo. Restrições podem ser especificadas tanto formal quanto
informalmente. A especificação formal se dá pela OCL e a especificação informal se

dá por texto livre ou linguagem natural; devem vir delimitadas por chaves e aparecer
dentro das notas explicativas.
Na década de 90, a arquitetura de software padecia de alguns problemas graves.

Muitas vezes, enfatizava-se exageradamente só um aspecto do desenvolvimento de
software e, outras vezes, a arquitetura não se direcionava aos interesses de todos
os interessados. Então, em 1995, Philippe Kruchten publicou um artigo buscando
solucionar essa questão.
Este artigo propunha organizar a descrição da arquitetura de software usand

diversas visões concorrentes, cada uma direcionada a um conjunto de interesses
específicos. Sabe-se que a arquitetura de software lida com abstrações e, para
descrevê-la, o autor se utilizou de cinco visões ou perspectivas principais, como
mostra a imagem abaixo.
16712855225
 Visão Lógica (de Projeto): é a visão da arquitetura do sistema sob o ponto de

vista dos usuários finais, apresentando os requisitos funcionais do software que
suportam a arquitetura e fornecem serviços. Principais diagramas utilizados:
Classe, Objetos e Pacotes.
 Visão de Desenvolvimento (ou Implementação): é a visão da arquitetura do

sistema sob o ponto de vista do programador, apresentando a organização

estática dos módulos que formam o software. Principais diagramas utilizados:

Componentes.
 Visão de Processo: é a visão da arquitetura do sistema sob o ponto de vista do

integrador, apresentando requisitos não-funcionais (Desempenho,
Escalabilidade, etc). Principais diagramas utilizados: Sequência, Estrutura
Composta, Máquina de Estados e Atividade.
 Visão Física (ou Implantação): é a visão da arquitetura do sistema sob o ponto

de vista do engenheiro de sistemas, apresentando a topologia ou distribuição
física dos componentes. Principais diagramas utilizados: Implantação e
Componentes.
 Visão de Casos de Uso (Cenários): é a visão da arquitetura do sistema sob o

ponto de vista de todos os usuários das outras visões e avaliadores,
apresentando a consistência e validade do sistema. Principais diagramas
utilizados: Casos de Uso.
Galera, a Modelagem Orientada a Objetos ocorre quase que sempre por meio da
Unified Modeling Language (UML). Portanto, nosso foco aqui será nos Diagramas
UML! Eles são capazes de modelar sistemas orientados a objetos e nós veremos um
por um cada um dos catorze! Atenção nesse assunto! A UML 2.4.1 descreve 14 tipos
de diagramas oficiais como mostra a imagem abaixo:
16712855225

Diagramas Estruturais: representam aspectos estáticos do sistema sob diversas

visões diferentes. Em outras palavras, esses diagramas apresentam a estrutura do
sistema inalterada há qualquer momento por não levarem em consideração o
tempo em sua representação. São eles: Componente, Classes, Implantação, Perfil,
Objetos, Estrutura Composta e Pacotes.
Diagramas Comportamentais: representam aspectos dinâmicos do sistema como

um conjunto de mudanças. Podemos dizer, em outras palavras, que esses
diagramas apresentam como os processos e funcionalidades do programa se
relacionam. São eles: Máquina de Estados, Casos de Uso, Atividade, Sequência,
Comunicação, Interação Geral e Tempo.
 Diagramas de Interação: são diagramas comportamentais que consideram o

relacionamento dinâmico e colaborativo entre os objetos do sistema e suas
trocas de informações. Eles enfatizam o controle de fluxo e dados entre as coisas
do sistema que estão sendo modeladas (Ex: Objetos). São eles: Sequência,
16712855225

IMPORTANTE
IMPORTANTE
Infelizmente,
Infelizmente, esses
esses conceitos
conceitos devem
devem ser
ser memorizados.
memorizados. Decorem
Decorem oo nomenome dede todos
todos osos
diagramas,
diagramas,respondendo
respondendoquais
quaissão
sãoestruturais,
estruturais,comportamentais
comportamentaiseededeinteração!
interação!Façam
Façamisso
isso
nem
nemquequevocês
vocêstenham
tenhamque
quetatuar
tatuaroonome
nomededecada
cadaum
umemempartes
partesdodocorpo.
corpo.Decorem!
Decorem!
Decorem!
Decorem!Decorem!
Decorem!Decorem!
Decorem!Decorem!
Decorem!Decorem!
Decorem!
Professor, eu estou exausto de tanto decorar coisas! Pessoal, eu vou dizer o que me
ajudou um pouco no momento de memorizar esses diagramas! Eu decorei as duas
frases acima (uma para os estruturais e uma para os comportamentais). Elas contêm
as letras iniciais de cada diagrama. A partir daí, eu fiquei tentando lembrar o nome
de todos os diagramas incansavelmente até decorar.
16712855225

DIAGRAMAS ESTRUTURAIS
DIAGRAMA DE CLASSES
Esse é facilmente o diagrama mais conhecido de todos! Ele descreve as classes

interfaces presentes no sistema, suas características, restrições e os vários tipos de
relacionamentos estáticos entre seus objetos. Representam-se também as
propriedades e as operações de uma classe, assim como as restrições que se
aplicam à maneira como os objetos estão conectados.
Professor, o que é uma classe? Classe é uma estrutura classificadora que abstrai um
conjunto de objetos que compartilham características, restrições e semânticas
similares. Ela define, também, o comportamento de seus objetos através de
métodos e o estado por meio de atributos. A imagem abaixo apresenta as partes
de um Diagrama de Classe (Classe, Interface, Relacionamentos, etc):
16712855225
Professor, estou confuso! Quantas classes existem na imagem acima? Bem... quando
vamos representar o nome de uma classe, temos algumas opções! Podemos
informar apenas seu nome (Ex: Preview) ou podemos informar seu nome após o

pacote ao qual pertence separado por duplo dois-pontos (Ex:

android.hardware::Camera). Portanto, temos cinco classes e duas interfaces!
Mas só existe uma forma de representar classes? Não! Pode-se representar de

diversas formas, dependendo do nível de abstração. A imagem abaixo apresenta
maneiras distintas de se representar uma classe: primeiro, apenas com nome da
classe (mais abstrata); segundo, com nome da classe e suas propriedades; e terceiro,
com nome da classe, propriedades e operações (mais concreta).
Professor, e essa última classe estranha? Bem, essa é a representação de uma Classe
Ativa, que tem por objetivo representar classes cujos objetos têm um ou mais
processos (threads). Eu posso inserir detalhes de implementação da linguagem de
programação que eu escolhi? Sim, você pode inserir peculiaridades de uma
linguagem de programação particular.
Galera, agora vamos responder a algumas perguntas relevantes. Professor, como se

representa um atributo estático na UML? Bem, basta sublinhar o nome do atributo!
Professor, como se representa uma operação abstrata? Bem, basta escrever seu
nome em itálico! E como se representa uma operação estática? Bem, basta escrever
seu nome sublinhado!
MODIFICADOR CLASSE SUBCLASSE PACOTE TODOS

PÚBLICO + X 16712855225
X X X
PROTEGIDO # X X
UML
PACOTE ~ X X
PRIVADO – X
PÚBLICO + X X X X
PROTEGIDO # X X X
JAVA
DEFAULT ~ X X
PRIVADO - X

E como se representa a visibilidade de atributos e operações? A tabela acima

apresenta a diferença de visibilidade em JAVA e UML. Observem duas diferenças
sutis: na UML, um elemento protegido não é visível para elementos dentro do
mesmo pacote; e o nível Pacote da UML tem o mesmo nome do nível Default em
JAVA! Pessoal, isso cai bastante em prov Podemos ver um exemplo abaixo:
Pessoal, agora vamos falar sobre os tipos de relacionamentos em um diagrama de

classes. Eles representam as conexões entre classes, objetos, pacotes, tabelas, entre
outros. Há três tipos de relacionamentos entre classes: Dependência, Generalização
e Associação, como mostra a imagem abaixo. No entanto, eles se desdobram em
vários outros! Vejamos...
16712855225
Relacionamento de Dependência: é um relacionamento direcionado e semântico

entre dois ou mais elementos que ocorre se mudanças na definição de um elemento

(independente) causarem mudanças ao outro elemento (dependente). Em outras

palavras, é quando a classe cliente é dependente de algum serviço da classe
fornecedora, como mostra a imagem abaixo.
À esquerda, uma Classe Login depende de uma Interface Base de Dados. Como
assim, professor? O diagrama indica que a Classe Login utiliza algum método da
Interface Base de Dados, logo caso esse método seja modificado, pode haver danos
à Login. Lembrando que esse relacionamento pode ocorrer entre duas classes ou
entre uma classe e uma interface.
À direita, uma Classe Pedido depende de uma Classe Item. Como assim, professor?
O diagrama indica que a Classe Pedido utiliza algum método da Classe Item.
Portanto, caso se modifique um método da Classe Item, pode haver danos na classe
dependente, que é a Classe Pedido. Logo, Pedido é a classe dependente e Item é a
classe independente.
16712855225
IMPORTANTE
Observem que o Relacionamento de Dependência é representado por uma seta

tracejada que aponta para classe independente. Em outras palavras, a Classe Pedido
depende da Classe Item. Os relacionamentos <include> e <extend> também são
relacionamentos de dependência.

Relacionamento de Generalização/Especialização (Herança): indica que a subclasse

é uma especialização da superclasse ou que a superclasse é uma generalização da
subclasse. Qualquer instância da subclasse é também uma instância da superclasse.
É conhecido como relacionamento de herança, relacionamento de extensão ou
relacionamento “é-um”.
Observem que a imagem acima apresenta um relacionamento em que Fruta é uma

generalização de Laranja, assim como Laranja é uma generalização de Laranja Lima
e Laranja Pêra. Tudo isso pode ser dito em termos de especialização: Laranja Lima
e Laranja Pêra são especializações de Laranja, assim como Laranja é uma
especialização de Fruta.
16712855225
IMPORTANTE
Observem que o Relacionamento de Generalização/Especialização é representado por

uma linha com um triângulo que aponta para a classe genérica.
Relacionamento de Realização: relacionamento entre dois elementos em que

elemento realiza (implementa/executa) o comportamento que o outro elemento
especifica. Costuma-se dizer que um dos elementos especifica um contrato e o
outro elemento realiza esse contrato. A imagem abaixo mostra a Classe Marcelo,
que realiza uma Interface Pessoa.

IMPORTANTE
Observem que o Relacionamento de Realização é representado por uma linha tracejada

com um triângulo que aponta para a interface.
Relacionamento de Associação: relacionamento estrutural entre objetos e especifica
os objetos de uma classe que estão ligados a objetos de outra classe. São eles:
 Simples: é um tipo de relacionamento mais forte que o relacionamento de

dependência e indica que uma instância de um elemento está ligada à instância
de outro elemento. São representados por uma linha sólida com ou sem setas
de navegabilidade. Ademais, pode haver nomes para a associação e indicação
de multiplicidade1.
16712855225
Na imagem acima, há uma associação simples entre Carro e Marca. Trocando em

miúdos, significa que o carro é de uma marca e a marca possui diversos carros.
1
Multiplicidades permitem representar a informação dos limites inferior e superior da quantidade de objetos
aos quais outro objeto pode estar associado.

Observem que se excluir-se um carro, a marca continua a existir. Assim como se

excluir-se uma marca, o carro continua a existir. Portanto, esse é um relacionamento
de associação simples.
IMPORTANTE
Observem que o Relacionamento de Associação Simples é representado por uma linha

sólida que pode ou não ter setas de navegabilidade unidirecionais ou bidirecionais.
 Qualificada: é um tipo de relacionamento similar à associação simples, contudo

possui um qualificador, que é um atributo do elemento-alvo capaz de identificar
uma instância dentre as demais. Ela ocorre em associações um-para-muitos ou
muitos-para-muitos em que se deseja encontrar um elemento específico dada
uma chave.
Na imagem acima, há uma associação qualificada entre NotaFiscal e Itens. Pensem

comigo: uma nota fiscal pode ter milhares de itens, mas e se por acaso eu quiser
encontrar um item específico? Ora, eu posso utilizar um identificador de itens como
qualificador de NotaFiscal. Portanto, cada item está associado a um código de item
e a uma nota fiscal.
16712855225
IMPORTANTE
Observem que o Relacionamento de Associação Qualificada é representado por uma

linha sólida com um retângulo ao lado da classe de cardinalidade 1 contendo o
qualificador.
 Agregação: é um tipo de associação, porém mais forte, em que o todo está

relacionado às suas partes de forma independente. Nesse tipo de
relacionamento, as partes têm existência própria. Portanto, elas existem por si

só, isto é, a parte existe sem o todo. É representado por uma linha com um
diamante vazio na extremidade referente ao todo.
Na imagem acima, há uma agregação entre Carro e Rodas, Carro e Motor, Rodas e
Calotas, Rodas e Pneus, Motor e Carburador, e Motor e Virabrequim. Vamos
interpretar apenas a agregação entre Carro (Todo) e Rodas (Partes). Respondam-
me: a roda pode existir sem um carro? Sim, claro! Logo, esse é um relacionamento
de agregação.
IMPORTANTE
Observem que o Relacionamento de Agregação é representado por uma linha sólida com
um diamante vazio na classe agregadora.
16712855225
 Composição: é um tipo de agregação, porém mais forte, em que o todo está

relacionado às partes de forma dependente. Nesse relacionamento, as partes
não têm existência própria. Logo, não existem por si só, i.e., a parte não existe
sem o todo. É representado por uma linha com um diamante cheio na
extremidade referente ao todo.

Na imagem acima, há uma composição entre Carro e Pintura. Respondam-me: a

pintura pode existir sem o carro? Não, não faz o menor sentido! A existência do carro
é requisito fundamental para a existência da pintura. Ademais, essa pintura é
exclusiva daquele carro e não pode ser compartilhada. Logo, na composição, o todo
tem sempre cardinalidade 1!
IMPORTANTE
Observem que o Relacionamento de Composição é representado por uma linha sólida

com um diamante cheio na classe compositora. Pessoal, quando eu aprendi isso, decorei
assim: Diamante Cheio = Composição. Portanto, Diamante Vazio = Agregação.
Quando utilizar Diagramas de Classe? Os Diagramas de Classe são a espinha dorsal

da UML; portanto, você irá utilizá-los o tempo todo. O maior problema é que eles
16712855225
são tão ricos que podem ser complexos demais para usar. Dessa forma, não tente
utilizar todas as notações de que você dispõe; uso de diagramas de classes
conceituais são muito uteis na exploração da linguagem do negócio.
Busque manter o software fora da discussão e manter a notação mais simples; não
desenhe modelos para tudo; em vez disso, concentre-se nas áreas principais.
melhor ter poucos diagramas que você utiliza e os mantém atualizados do que ter
muitos modelos esquecidos e obsoletos. O maior perigo é que você pode focalizar
exclusivamente a estrutura e ignorar o comportamento.

Portanto, ao desenhar diagramas de classe para entender o software, sempre os

faça em conjunto com alguma forma de técnica comportamental. Se você estiver
indo bem, vai ficar trocando entre as técnicas frequentemente. Galera, é possível
fazer uma aula inteira somente sobre os diagramas de classe, mas aqui temos que
ser mais objetivo, abordando os assuntos mais frequentes.
16712855225

DIAGRAMA DE OBJETOS
O Diagrama de Objetos (ou Diagrama de Instâncias) é uma variação do Diagrama

de Classes. Contudo, aqui não se trata da estrutura geral, mas de cada instância
específica do sistema. Portanto, no diagrama de objetos não há Pessoa, há “João”.
Não há Carro, há “Pálio”. Não há Cachorro, há “Totó”. Entenderam? No diagrama
de objetos, personaliza-se cada instância com seus valores.
Costuma-se dizer que o diagrama de objetos representa uma fotografia estática do

sistema em um dado momento de execução, portanto esses diagramas não
refletem o sistema genericamente, mas de forma específica – em um determinado
instante. Como ele mostra instâncias, em vez de classes, ele é frequentemente
chamado Diagrama de Instâncias.
Esses diagramas são úteis para mostrar exemplos de objetos interligados. Em

algumas situações, pode-se definir a estrutura de um sistema precisamente com um
diagrama de classes, mas a estrutura ainda é difícil de entender. Neste momento,
diagrama de objetos pode ser bastante útil para facilitar a compreensão de um
determinado domínio.
Ele é um instantâneo dos objetos em um sistema em um determinado ponto no

tempo. Você pode usar um diagrama de objetos para mostrar um exemplo de
configuração de objetos. Você pode dizer que os elementos de um diagrama de
objetos são instâncias caso os nomes estejam sublinhados. Cada nome assume a
forma nome de instância : nome da classe.
As duas partes do nome são opcionais. Se você usar apenas o nome da classe, deve
incluir os dois-pontos. Você pode mostrar valores para atributos e vínculos também.
Rigorosamente, elementos de um diagrama de objetos são especificações de
16712855225
instâncias, em vez de instâncias verdadeiras. O motivo é que é válido deixar atributos

obrigatórios vazios ou mostrar especificações de instâncias de classes abstratas.
Esses diagramas são raramente utilizados. A única utilidade prática e direta dos
diagramas de objetos é a de ilustrar a formação de relacionamentos complexos de
um diagrama de classes, como associações reflexivas. Com o objetivo de facilitar a
atividade de validação, podemos construir diagramas de objetos para ilustrar e
esclarecer certos aspectos de um diagrama de classes.

Rapaziada, podemos representar o nome de um objeto de diversas formas:
Representação do Nome Descrição

: Significa que se trata de uma instância anônima de uma
classe anônima;
:Cliente Significa que se trata de uma instância anônima da classe
Cliente;
novoCliente: Significa que se trata de uma instância novoCliente de
uma classe anônima;
novoCliente:Cliente Significa que se trata de uma instância novoCliente de
uma classe Cliente;
novoCliente:Clientes::Cliente Significa que se trata de uma instância novoCliente de
16712855225
uma classe Cliente de um pacote Clientes;
Quando utilizar o Diagrama de Objetos? Os Diagramas de Objeto são úteis para

mostrar exemplos de objetos interligados. Eventualmente, define-se uma estrutura
precisamente com um diagrama de classes, mas a estrutura pode ser ainda é difícil
de entender. Nesses casos, exemplos de diagrama de objetos podem auxiliar. Eles
podem ser vistos como um diagrama de comunicação sem as mensagens.

DIAGRAMA DE COMPONENTES
O Diagrama de Componentes representa o sistema sob uma perspectiva funcional,

expondo a organização de seus módulos e as relações entre seus componentes por
meio de interfaces. Professor, o que é são os componentes? É uma unidade
independente, que pode ser utilizada ou substituída com/por outros componentes
para formar um sistema complexo.
Os componentes representam peças que podem ser adquiridas e atualizadas

independentemente. Ora, um sistema inteiro pode ser construído baseado em
componentes e essa é uma decisão tanto de negócio quanto técnica. Existe,
inclusive, um modelo de desenvolvimento de software baseado em componentes.
Os componentes podem ser tabelas, documentos, etc.
16712855225
Como mostra a imagem acima, os componentes são representados como

retângulos com o símbolo de componente no canto superior direito e com nome
escrito dentro ou abaixo do componente. Frequentemente, eles vêm com
estereótipos para definir seu tipo e seus relacionamentos. A grande vantagem do
uso de componentes é a modularidade.
Galera, é possível representar componentes das seguintes três formas:

Um componente pode apresentar um estereótipo, i.e., uma definição do que é este

componente. Os principais estereótipos são:
 Arquivo: determina que o componente é um arquivo de dados do sistema;

 Biblioteca: determina que o componente é uma biblioteca de código;
 Documento: determina que o componente é um documento de sistema;
 Executável: determina que o componente é um arquivo executável;
 Tabela: determina que o componente é uma tabela de um banco de dados.
Temos, também, a Interface Fornecida, que designa uma interface que o próprio
componente possui e oferece para outros componentes – o componente só pode
ser acessado pela interface fornecida; e Interface Requerida, que designa uma
interface necessária para que componente se comunique com outros componentes.
Esta interface será conectada em uma interface fornecida de outro sistema.
Quando utilizar Diagramas de Componentes? Use Diagramas de Componentes

16712855225
quando você estiver dividindo seu sistema em componentes e quiser representar

seus relacionamentos por intermédio de interfaces ou também quando quiser
representar a decomposição de componentes em uma estrutura de nível mais baixo.
Entendido, galera? Exercícios!

DIAGRAMA DE PACOTES
Ele representa os pacotes e suas dependências. Professor, o que é um pacote? É um

agrupamento lógico que permite reunir elementos da UML em unidades de mais
alto nível. Comumente, pacotes agrupam classes, mas pode-se agrupar qualquer
coisa. Esses elementos podem ser membros de um único pacote com uma estrutura
hierárquica.
Os pacotes de nível superior são divididos em subpacotes que possuem seus

próprios subpacotes e assim por diante. Esses pacotes ilustram a arquitetura de um
sistema como um agrupamento de classes em um alto nível de abstração. O
diagrama pode ser desenhado como uma pasta contendo várias classes ou pastas
hierárquicas.
16712855225
Quando utilizar Diagramas de Pacote? São extremamente úteis em sistemas de

grande porte, para obter uma visão das dependências entre os principais
elementos de um sistema. Esses diagramas correspondem bem às estruturas
usuais de programação. A representação de diagramas de pacotes e
dependências o ajuda a manter as dependências de uma aplicação sob controle.
Os Diagramas de Pacotes representam um mecanismo de agrupamento em

tempo de compilação. Para mostrar como os objetos são compostos em tempo
de execução, recomenda-se a utilização do Diagrama de Estrutura Composta.

Percebam que não é um diagrama que cai bastante em prvoa, mas é importante
saber o básico sobre ele.
16712855225

DIAGRAMA DE IMPLANTAÇÃO (OU INSTALAÇÃO)
O Diagrama de Implantação apresenta layout físico de um sistema, revelando

quais partes do software são executadas em quais partes do hardware. Também
conhecido como Diagrama de Instalação ou também Diagrama de Distribuição,
pode representar toda a estrutura de hardware e requisitos mínimos onde o sistema
será de fato executado.
Os itens principais do diagrama são nós conectados por caminhos de comunicação.

Um nó é algo que pode conter algum software. Um dispositivo é um hardware, que
pode ser um computador ou uma peça de hardware mais simples conectada a um
sistema; um ambiente de execução é um software que contém a si mesmo ou
contém outro software (Ex: Sistema operacional ou processo contêiner).
Os nós contêm artefatos, que são manifestações físicas do software: normalmente,

arquivos. Esses arquivos podem ser executáveis (Ex: .exe, binários, entre outros) ou
arquivos de dados, arquivos de configuração, documentos HTML, etc. A listagem
de um artefato dentro de um nó mostra que ele está instalado nesse nó do sistema
que está em execução.
Você pode mostrar artefatos como caixas de classe ou listando o nome dentro de
um nó. Se você os mostrar como caixas de classe, poderá adicionar um ícone de
documento ou a palavra-chave <<artifact>>. Você pode rotular nós ou artefatos com
valores para indicar diversas informações interessantes a respeito do nó, tais como
fornecedor, sistema operacional, localização ou qualquer coisa que você desejar.
Frequentemente, você terá vários nós físicos executando a mesma tarefa lógica.
Você pode mostrar isso com várias caixas de nó ou declarar o número como um
valor afixado. Muitas vezes, os artefatos são a implementação de um componente.
16712855225
Para mostrar isso, você pode usar um valor indicado na caixa do artefato. Os
caminhos de comunicação entre os nós indicam como as coisas se comunicam.
Você pode rotular esses caminhos com informações sobre os protocolos de

comunicação utilizados. Os nós e artefatos não são de responsabilidade do
programador, mas da equipe de implantação do sistema, que deve se preocupar
com a configuração e topologia dos elementos de software sobre os elementos de
hardware.
Quanto usar os Diagramas de Implantação (ou Instalação). Bem, eles são úteis para
mostrar o que é instalado e onde; portanto, qualquer instalação mais complicada

pode fazer bom uso deles (Ex: uma configuração e arquitetura de sistema em que
estarão ligados componentes, representados pela arquitetura física de hardware,
processadores, entre outros).
16712855225

DIAGRAMA DE PERFIL
Frequentemente, vale a pena definir uma versão de UML adequada a uma

determinada finalidade ou área de domínio. Por exemplo, se você deseja usar um
modelo de UML personalizado para geração de código em uma determinada
linguagem, é útil definir estereótipos que possam ser aplicados aos elementos para
fornecer dicas ao gerador de código.
Entretanto, os estereótipos definidos seriam diferentes para, por exemplo, Java e

C++. Da mesma forma, você poderia usar a UML para modelar bancos de dados –
é possível ajustar a UML utilizando perfis. Professor, o que é um perfil? Trata-se de
uma UML com um conjunto de estereótipos predefinidos, valores atribuídos,
restrições e classes de base.
Ele também seleciona um subconjunto dos tipos de elementos da UML para uso e
define uma versão especializada da UML para uma determinada área. Como o perfil
é criado sobre elementos comuns, ele não representa uma nova linguagem e pode
ser suportado por ferramentas comuns da UML. A maioria dos modeladores não
construirá seus próprios perfis.
A maioria dos perfis será construída por criadores de ferramentas, criadores de

frameworks e projetistas similares aos recursos gerais. Entretanto, muitos
modeladores usarão os perfis. São como as bibliotecas de sub-rotina tradicionais –
alguns especialistas as criam, mas muitos programadores as usam. Sacaram?
Portanto há bastante reusabilidade.
O Diagrama de Perfil permite representar esses novos elementos, operando no nível

de metamodelos. Imaginem que eu quero utilizar a UML para representar uma rede
de computadores. A UML tem símbolos para representar roteadores, switches, etc?
16712855225
Não! Para tal, podem-se utilizar estereótipos. Como? Ora, eu desenho um retângulo
e escrevo nele a expressão <<roteador>> ou <<switch>>.

A UML oferece diversos estereótipos padronizados, podemos

citar <<interface>>, <<extends>> e <<include>>. No entanto, vamos supor
que haja um relacionamento Pessoa saca Dinheiro. Não há um
estereótipo <<sacar>>, todavia ele pode ser criado e representado
usando Diagramas de Perfil por meio da expressão
<<estereótipo>>. Continuando: se eu não quiser representar
um ator por meio de um stickman, eu posso utilizar um
retângulo com o nome <<ator>> ou <<stickman>>.
16712855225

DIAGRAMA DE ESTRUTURA COMPOSTA
O Diagrama de Estrutura Composta é utilizado para modelar colaborações internas

de classes, interfaces e componentes para especificar uma funcionalidade. O que é
colaboração, professor? É uma visão de um conjunto de entidades cooperativas
interpretadas por instâncias que cooperam entre si para executar uma operação
específica. Inclusive, uma colaboração pode conter outras colaborações.
Esse diagrama fornece meios de definir a estrutura de um elemento e de focalizá-

la no detalhe, na construção e em relacionamentos internos. É um dos novos
diagramas propostos na segunda versão de UML, voltado a detalhar elementos de
modelagem estrutural, como classes, pacotes e componentes, descrevendo sua
estrutura interna.
16712855225
Quando utilizar o Diagrama de Estrutura Composta? As estruturas compostas

entraram na UML 2.0, embora alguns métodos antigos tivessem algumas ideias
semelhantes. Uma boa maneira de pensar a respeito da diferença entre pacotes e
estruturas compostas é que os pacotes são um agrupamento em tempo de
compilação e estruturas compostas mostram em tempo de execução.

Dessa forma, elas servem naturalmente para mostrar componentes e como eles são
divididos em partes; assim, grande parte dessa notação é usada em diagramas de
componentes. Sendo bastante sincero com vocês, até hoje esse diagrama não
emplacou e, na verdade, sempre houve essa dúvida entre os membros do comitê
organizador da UML.
16712855225

DIAGRAMAS COMPORTAMENTAIS
DIAGRAMA DE CASOS DE USO
Casos de Uso são uma técnica para captar os requisitos funcionais de um sistema.
Eles servem para descrever as interações de usuários com o sistema, fornecendo
uma narrativa sobre como o sistema é utilizado. E o que é um cenário? Cenário é
uma instância de caso de uso, i.e., uma sequência de passos que descreve uma
interação entre um usuário e o sistema.
Pensemos em uma loja virtual. O cenário de compra de um produto poderia ser: o

cliente navega no catálogo e adiciona itens desejados à sua cesta de compras.
Quando desejar pagar, descreve o endereço de entrega, fornece as informações do
cartão de crédito e confirma a compra. O sistema verifica a autorização do cartão e
confirma a venda.
Caso haja alguma falha em um dos passos, cria-se outro cenário. De todo modo,
Diagrama de Casos de Uso descreve um conjunto de funcionalidades do sistema e
interações com elementos externos e entre si. Os Atores são os elementos externos
que interagem com o sistema e são representados por um boneco (Stickman). Nas
imagens abaixo, temos dois Diagramas de Casos de Uso (Sistema e Negócio):
16712855225

Professor, eu pensava que um ator só podia ser um humano. Pois é, não é assim! Ele
pode ser um humano, uma máquina ou outro sistema cuja interação executa uma
ação significativa. Atores especificam um papel de uma entidade externa que se
associam só entre si ou com casos de uso. Há quatro tipos de relacionamento
relevantes!
Um caso de uso conta uma história sobre como o usuário final interage com o
sistema sob um conjunto de circunstâncias específicas. A história pode ser um texto
narrativo, uma descrição geral de tarefas ou interações, uma descrição baseada em
gabaritos ou uma representação esquemática. Independentemente de sua forma,
um caso de uso representa o software ou sistema do ponto de vista do usuário final.
Há Casos de Uso Concretos e Abstratos. O primeiro é iniciado por um ator e

16712855225
constitui um fluxo completo de eventos, i.e., uma instância do caso de uso executa
a operação inteira chamada pelo ator. O segundo jamais é instanciado diretamente,
são incluídos, estendidos ou generalizados por outros casos de uso. Representa-se
com nome em itálico!
Há também Casos de Uso Primários e Secundários. O primeiro representa os

objetivos dos atores. Esses casos de uso representam os processos da empresa que
estão sendo automatizados pelo sistema de software. O segundo não traz benefício
direto para os atores mas é necessário para que o sistema funciona adequadamente.
Evidentemente, inicia-se pela identificação de casos de uso primários.

Quando um caso de uso concreto é iniciado, uma instância do caso de uso é criada.
Ela também exibe o comportamento especificado por seus casos de uso abstratos
associados. Logo, nenhuma instância separada é criada a partir de casos de uso
abstratos. Essa distinção é importante, visto que os atores só podem enxergar casos
de uso concretos.
 Relacionamento de Comunicação: também chamada de relacionamento de

associação, o ator se comunica com o sistema por meio do envio e recebimento
de mensagens. A imagem abaixo mostra a comunicação entre um ator e um
caso de uso, representado por uma linha sólida no sentido do ator (Usuário) para
o caso de uso (Navegar).
 Relacionamento de Inclusão: utilizado quando um mesmo comportamento se

repete em mais de um caso de uso. A imagem abaixo apresenta o domínio de
um internet banking. Observem que, para realizar um pagamento ou visualizar
o saldo, é obrigatório que fazer Login. Logo, é um relacionamento obrigatório,
representado por uma linha tracejada com uma seta na ponta2.
16712855225
 Relacionamento de Extensão: utilizado quando se deseja modelar um

relacionamento alternativo. A imagem abaixo apresenta o contexto de um fórum
de discussões. Observem que para cadastrar um usuário, há duas opções:
2
A leitura é: o Caso de Uso Pagar e o Caso de Uso Ver Saldo incluem o Caso de Uso Logar, i.e., tanto para realizar
pagamentos quanto para visualizar saldos, é obrigatório logar-se.

moderador ou administrador. Logo, é um relacionamento opcional,

representado por uma linha tracejada com uma seta na ponta3.
 Relacionamento de Herança: relacionamento entre atores, utilizado quando o

ator filho é um uma especificação do ator genérico. É bastante útil para definir
sobreposição de papéis entre atores e é representado com uma linha sólida com
um triângulo no ator genérico. Na imagem abaixo, Vendedor é especialização
de Pessoa. É representado por uma linha com um triângulo.
Abaixo segue uma tabela com as possibilidades de relacionamentos entre os

16712855225
elementos do modelo de casos de uso.
Comunicação Extensão Inclusão Herança

Entre Casos de Uso X X X
Entre Atores X
Entre Casos de Uso e Atores X
Quando utilizar Diagramas de Casos de Uso? Os casos de uso sã uma ferramenta

valiosa para ajudar no entendimento dos requisitos funcionais de um sistema. Uma
3
A leitura é: o Caso de Uso Cadastrar Administrador e o Caso de Uso Cadastrar Moderador estendem a
funcionalidade de Cadastrar Usuário, i.e., pode-se cadastrar usuário de duas maneiras distintas.

primeira passagem nos casos de uso deve ser feita no início. Versões mais
detalhadas dos casos de uso devem ser elaboradas apenas antes do
desenvolvimento desse caso de uso.
É importante lembrar que casos de uso representam uma visão externa do sistema.
Como tal, não espere quaisquer correlações entre eles e as classes dentro do
sistema. Com os casos de uso, concentra-se energia mais no texto do que no
diagrama. A despeito de a UML não dizer nada sobre o texto do caso de uso, é esse
texto que contém todo o valor da técnica.
Um grande perigo dos casos de uso é que as pessoas os tornam complicados

demais e não conseguem prosseguir. Normalmente, você terá menos problemas
fazendo pouco do que fazendo demais. Umas duas páginas por caso de uso está
bom, para a maioria das situações. Se você tiver muito pouco, pelo menos terá um
documento curto e legível; se tiver demais, dificilmente alguém o lerá e entenderá.
16712855225

DIAGRAMA DE ATIVIDADES
O Diagrama de Atividades descreve lógica de procedimento, processo de negócio

e fluxos de trabalho. De várias formas, eles desempenham um papel semelhante
aos fluxogramas, mas se diferenciam, pois suportam comportamentos paralelos.
Mas o que é uma atividade? É um comportamento parametrizado representado
como um fluxo coordenado de ações.
Notem que o diagrama de atividades tem um nível de abstração maior. Em outras

palavras, pode-se dizer que ela não se preocupa com interações entre objetos, mas
entre processos de negócios de mais alto nível. Os estados mudam quando uma
ação é executada, ademais podem ser representados por meio de swimlanes
(semelhante a raias de uma piscina olímpica).
Como apresenta a imagem abaixo, a Swimlane agrupa as atividades e as organizam

de acordo com suas respectivas responsabilidades, com o auxílio de ações,
bifurcações, fluxos e ramificações. São representadas como duas linhas paralelas,
horizontais ou verticais, e seu nome em uma das extremidades. Qualquer nó de
atividade entre essas linhas é considerado contido dentro de uma partição.
16712855225
As ramificações especificam caminhos alternativos baseados em expressões

booleanas – é representado com um diamante. A bifurcação é a divisão de um
mesmo fluxo de controle em dois ou mais fluxos concorrentes: poderá ter uma única
transição de entrada e duas ou mais transições de saída; abaixo da bifurcação, as
atividades associadas com cada um dos caminhos prosseguem paralelamente.
Além da bifurgação, também temos a união. O que seria isso, professor? É a

sincronização de dois ou mais fluxos de controle concorrentes: poderá ter duas ou
mais transições de entrada e uma única transição de saída; uma barra de

sincronização é usada para especificar bifurcação e união dos fluxos paralelos de

controle. Vocês entenderam?
Quando utilizar o Diagrama de Atividades? A maior qualidade dos Diagramas de

Atividades está no fato de que eles suportam e estimulam o comportamento
paralelo. Isso os torna uma excelente ferramenta para modelagem de fluxos de
trabalho e de processos. Na verdade, grande parte do avanço da UML 2.x é devido
às pessoas envolvidas com fluxo de trabalho.
Você também pode usar um diagrama de atividades como um fluxograma

compatível com a UML (mas suporta comportamento paralelo). A principal
vantagem fica para as pessoas que usam a UML como linguagem de programação.
Dessa forma, eles representam uma técnica importante para representar lógica
comportamental. Frequentemente, eles são utilizados para descrever casos de uso.
16712855225

DIAGRAMA DE MÁQUINA DE ESTADOS
Também conhecido como Diagrama de Transição de Estados, apresenta diversos

estados possíveis de um objeto no decorrer da execução de processos de um
sistema. Dessa forma, um objeto pode passar de um estado inicial para um estado
final, por meio de uma transição, quando ocorre algum evento ou estímulo interno
ou externo ao sistema.
16712855225
O Diagrama de Máquina de Estados não mostra a interação entre objetos.

Geralmente, ele mostra estados possíveis de um objeto específico. O que é um
Estado? É a condição de um objeto em um determinado instante. O que é uma
Transição? É a passagem de um estado para outro. O que é uma ação? É uma
atividade que efetua a transição de estados.

Esse permite representar o ciclo de vida de objetos e como eles são afetados por
eventos como erros, mensagens e condições. Eles se iniciam com um único estado
inicial, mas podem ter vários estados finais. A imagem acima apresenta um objeto
que faz pedidos de venda. Observem como é fácil de ler e auxilia a visualizar a
complexidade do sistema.
É necessário distinguir Diagrama de Atividades e Diagrama de Máquina de Estados.

No primeiro, o comportamento está expresso fundamentalmente nos nós do
diagrama com cada nó representando um pedaço de comportamento. No segundo
ocorre o contrário, ou seja, todo o comportamento se encontra nos arcos do
diagrama.
Os nós do Diagrama de Estados representam o que está nos arcos do Diagrama de

Atividades, e os nós dos Diagramas de Atividades representam o que está nos arcos
dos Diagramas de Estado. Assim, apesar de visualmente bastante similares, do
ponto de vista semântico, o que é representado em cada diagrama é exatamente o
oposto um do outro.
Quando utilizar Diagramas de Máquina de Estados? Eles são bons para descrever o
comportamento de um objeto por intermédio de vários casos de uso. No entanto,
esses diagramas são muito bons mesmo para descrever um comportamento que
envolva vários objetos em colaboração. Para tal, é útil combinar diagramas de
estados com outras técnicas.
Por exemplo, os Diagramas de Interação são bons para descrever o comportamento

de vários objetos em um único caso de uso e os Diagramas de Atividades são bons
para mostrar a sequência geral de atividades para vários objetos e casos de uso.
Recomenda-se não o utilizar para todas as classes, mas apenaspara aquelas que
exibem comportamento interessante e ajudem a entender o problema.
16712855225

DIAGRAMA DE SEQUÊNCIA
O Diagrama de Sequência é um diagrama de interação que captura o

comportamento de um único cenário, mostrando vários exemplos de objetos e
mensagens que são trocadas dentro de caso de uso. Ele modela a interação entre
os objetos, permitindo a visualização da execução de um ponto específico da
aplicação, com ênfase na ordem temporal.
O diagrama de sequência possui dois eixos: horizontal e vertical. O primeiro

representa os objetos envolvidos e o segundo representa o tempo em que a ação
ocorre e é representado por uma linha tracejada (Linha de Vida). A imagem abaixo
apresenta o diagrama de sequência de um caso de uso Sacar desde a inserção do
cartão até o saldo ser gravado pelo banco.
16712855225
Eu disse que esse diagrama mostra a sequência temporal de mensagens trocadas

entre objetos em um sistema. Mas o que é uma mensagem? É um serviço solicitado
de um objeto para outro e suas respostas. Por exemplo, quando um objeto deseja
utilizar um método definido por outro objeto, ele solicitando o serviço oferecido
pelo outro enviando uma mensagem.

Quando utilizar os Diagramas de Sequência? Você deve utilizá-lo quando quiser

observar o comportamento de vários objetos dentro de um único caso de uso. Eles
são bons para mostrar as colaborações entre os objetos, mas não são tão bons para
uma definição precisa do comportamento. Se quiser observar comportamento de
um objeto em muitos casos de uso, utilize um Diagrama de Estados.
Se quiser observar o comportamento em muitos casos ou em muitas linhas de

execução, considere o Diagrama de Atividades; se quiser explorar múltiplas
interações alternativas rapidamente, talvez seja melhor usar cartões CRC, pois isso
evita desenhar e apagar muitas vezes. Você explora alternativas de projeto com CRC
e depois utiliza diagramas de sequência para capturar todas as interações.
16712855225

DIAGRAMA DE COMUNICAÇÃO
O Diagrama de Comunicação também é uma espécie de diagrama de interação

muito semelhante ao diagrama de sequência, mas com ênfase na ordem estrutural
e, não, temporal. Em versões anteriores da UML, era conhecido como Diagrama de
Colaboração4. Mas como é possível verificar a ordem? Ele possui números que
identificam a sequência.
16712855225
Geralmente, utiliza-se o diagrama de sequência para cenários mais complexos e o

diagrama de comunicação para cenários mais simples. A imagem acima apresenta
um cenário exatamente igual ao do Diagrama de Sequência, no entanto com foco
na parte dinâmica do sistema. Observem que não há indicação cronológica, apenas
sequencial (1, 2, 3, 4, 5...).
4
Cuidado: O Diagrama de Comunicação era conhecido como Diagrama de Colaboração, mas ele não modela
colaborações. Quem modela colaborações, professor? O Diagrama de Estrutura Composta!

Sendo um tipo de diagrama de interação, o diagrama de comunicação mostra as

mensagens trocadas entre objetos. Podemos dizer, inclusive, que o diagrama de
comunicação é bastante semelhante estruturalmente ao diagrama de objetos,
porém com setas e rótulos de mensagens nas ligações entre esses objetos. Um
elemento particular do diagrama de comunicação é a ligação entre objetos.
Quando utilizar o Diagrama de Comunicação? A principal questão com os

diagramas de comunicação é quando usá-los em lugar dos diagramas de
sequência, mais comuns. Grande parte da decisão é questão de preferência pessoal:
algumas pessoas gostam mais de um do que do outro. Frequentemente, isso
direciona a escolha mais do que tudo.
Em geral, a maioria das pessoas parece preferir o Diagrama de Sequência. Uma

abordagem mais racional diz que os diagramas de sequência são melhores quando
você quer salientar a sequência de chamadas e que os Diagramas de Comunicação
são melhores quando se quer salientar os vínculos. Os últimos são mais fáceis de
alterar, de modo que eles são uma boa estratégia para explorar alternativas.
16712855225

DIAGRAMA DE TEMPO
O Diagrama de Tempo (ou Temporização) também é uma espécie de diagrama de

interação e descreve o comportamento dos objetos no decorrer do tempo e a
duração na qual eles permanecem em determinados estados. Percebam que há um
foco no tempo e na transição de estados, logo ele associa características do
Diagrama de Sequência com o Diagrama de Máquina de Estados.
Os Diagramas de Tempo se focam nas restrições de temporização entre mudanças

16712855225
de estado em diferentes objetos: ou para um único objeto ou, de forma mais útil,
para vários objetos. Esses diagramas são particularmente conhecidos dos
engenheiros de hardware há um longo tempo. A imagem acima apresenta as
restrições de tempo do diagrama.
O Diagrama de Tempo, ou de Temporização, descreve a mudança no estado ou na

condição de uma instância de uma classe ou seu papel durante um tempo. É
tipicamente utilizado para demonstrar a mudança no estado de um objeto no
tempo em resposta a eventos externos. Esse diagrama somente passou a existir a
partir da versão 2.0.

Quando utilizar os Diagramas de Temporização? Os Diagramas de Temporização

são úteis para mostrar restrições de temporização entre mudanças de estado em
diferentes objetos os diagramas são particularmente conhecidos dos Engenheiros
de hardware. Há pouquíssimos exercícios sobre ele – acredito que talvez seja o
diagrama menos cobrado em provas.
16712855225

DIAGRAMA DE INTERAÇÃO GERAL
O Diagrama de Interação Geral (ou Visão Geral) é uma espécie de diagrama de

interação que mistura o Diagrama de Atividades e o Diagrama de Sequência. Ele
fornece uma visão geral do controle de fluxo entre objetos e engloba diversos tipos
de diagramas de interação para demonstrar um processo geral. Ele mostra a troca
de mensagens entre objetos e o estado de atividades.
16712855225
Galera, os diagramas de interação preexistentes (Diagrama de Sequência e

Diagrama de Comunicação) servem para representar as interações que ocorrem em
um certo cenário de um caso de uso. Por outro lado, como seu próprio nome deixa
transparecer, o Diagrama de Interação Geral tem o objetivo de dar uma visão geral
dos diversos cenários de um caso de uso.
O renomado autor Martin Fowler afirma que pode-se considerar os diagramas de

interação geral como diagramas de atividades nos quais as atividades são
substituídas por pequenos diagramas de sequência ou como um diagrama de

sequência fragmentado, com a notação de diagrama de atividades usada para

mostrar o fluxo de controle.
Quando utilizar os Diagramas de Interação Geral? Esses diagramas surgiram a partir

da UML 2.0. Martin Fowler diz em seu livro que não gosta muito deles, pois acredita
que eles misturam dois estilos que não se encaixam muito bem. De acordo com o
autor, desenhe um Diagrama de Atividades ou use um Diagrama de Sequência,
dependendo do que melhor atender seu propósito.
16712855225

(CESPE - 2010 - DETRAN-ES - Analista de Sistemas) O uso da linguagem de

modelagem unificada, conhecida como UML, é recomendado para a análise
orientada a objetos, mas não para o projeto orientado a objetos, que deve ser
realizado por meio do suporte de linguagens de programação orientadas a
objetos.
Comentários:
Não, ele é recomendado tanto na fase de análise quanto na fase de projeto, i.e.,
tanto para desenhar o problema quanto para desenhar sua solução.
Gabarito: E
(CESPE - 2010 - TCU - Auditor Federal de Controle Externo - Tecnologia da

Informação - Parte II) UML (Unified Modeling Language) é uma tecnologia
concorrente com o processo unificado, no que diz respeito ao apoio à prática
de engenharia de software orientada a objetos.
Comentários:
Na verdade, ela é uma tecnologia complementar e, não, concorrente! A UML

inclusive é extensivamente utilizada junto do RUP.
16712855225
Gabarito: E
(CESPE - - ANAC - Técnico Administrativo - Informática) Geradores de

código em ferramentas CASE (Computer Aided Software Engineering) podem
ser embasados em modelos UML. Nesse caso, o gerador pode gerar um
programa ou componente completo ou um esqueleto de código.
Comentários:

Bem... um componente completo? Pegou pesado! De fato, existem Ferramentas

CASE que geram um programa a partir de Diagramas UML! No entanto, a geração
de componentes completos não faz sentido. Acredito que a banca vacilou, mas o
gabarito se manteve como verdadeiro.
Gabarito: C
(CESPE - 2011 - TRE-ES - Programação de Sistemas) RUP e UML são

interdependentes, isto é, não há como se aplicar o RUP no desenvolvimento de
um sistema se não se utilizar o UML.
Comentários:
Dizer que eles são interdependentes implica dizer que o RUP depende da UML
assim como a UML depende do RUP! Isso é válido? Claro que não! De fato, RUP
depende da UML, porém UML não depende do RUP!
barito: E
(CESPE - 2009 - SECONT-ES - Auditor do Estado – Tecnologia da Informação)

UML é um método para desenvolvimento de software que foi proposto para ser
aplicado à análise e projeto de software orientados a objetos.
Comentários:
UML é um método proposto para desenvolvimento de software? Não! É uma

ferramenta de modelagem visual que auxilia o desenvolvimento de software.
16712855225
Gabarito: E

UML (Universal Modeling Language) é uma linguagem de modelagem
proprietária que pode ser utilizada no desenvolvimento de sistemas de maneira
intuitiva para visualização de objetos.
Comentários:
Universal Modeling Language? Não, é Unified Modeling Language! Ademais, UML é

não-proprietária!

Gabarito: E
(CESPE - 2009 – INPI – Analista de Sistemas - V) Diagramas UML podem enfatizar

aspectos comportamentais e estruturais de sistemas de informação, como
diagramas de atividade (activity) e de classe (class), respectivamente.
Comentários:
Perfeito! Diagramas de Atividade são comportamentais e Diagramas de Classe são

estruturais.
Gabarito: C
(CESPE - – MPE/AM – Analista de Sistemas) Na abordagem de análise UML

(unified modelling language), a visão de modelo comportamental representa o
sistema do ponto de vista dos comportamentos e interações do sistema com o
usuário.
Comentários:
Perfeito! Representa a interação entre os objetos do sistema e a dinâmica do sistema

nas interações entre seus diversos elementos estruturais. Lembrando que aspectos
dinâmicos incluem também alterações em fluxos de mensagens ao longo do tempo,
movimentação física de componentes em uma rede, entre outros – não restringindo
apenas às interações com os usuários.
Gabarito: C
(CESPE - 2011 – PC/PA – Analista de Sistemas) Similarmente ao diagrama de

16712855225
classes, os diagramas UML de casos de uso e de estados (statechart) são usados

para representar aspectos estruturais de um sistema, conforme preconiza o
processo unificado.
Comentários:
Não! Primeiro, isso não é preconizado pelo Processo Unificado. Segundo, Diagrama
de Classes são estruturais e Diagramas de Casos de Uso e Diagrama de Estados são
comportamentais.
Gabarito: E

10. (CESPE - – PM/RB – Analista de Sistemas) UML foi desenvolvida

especificamente para o desenvolvimento de software, não sendo possível a sua
utilização por outros sistemas ou áreas diferentes da tecnologia da informação.
Comentários:
Não! UML não se limita a modelagem de software. Ela é uma linguagem de

modelagem de propósito geral.
Gabarito: E
11. (CESPE – – SAD/PE – Analista de Sistemas – D) Na especificação da UML

2.0, destaca-se a existência da sublinguagem OCL (Object Constraint Language),
linguagem imperativa que, com variáveis e comandos de controle de fluxo, é
usada para complementar diagramas UML.
Comentários:
Não! OCL é uma linguagem imperativa, mas declarativa!
Gabarito: E
12. (CESPE - 2009 - ANAC - Analista Administrativo - Tecnologia da Informação) A

UML - Unified Modeling Language é um conjunto de especificações do OMG -
Object Management Group. O conjunto completo da UML, em sua versão 2.0,
está distribuída em três especificações: a Especificação de Intercâmbio de
Diagramas, a Infraestrutura UML, e a Linguagem de Restrição de Objeto - OCL.
A Especificação de Intercâmbio de Diagramas possibilita o compartilhamento de
16712855225
modelos entre diferentes ferramentas de modelagem. A infraestrutura define os

conceitos fundamentais, sendo considerada um metamodelo, é utilizada para
construir as demais especificações da UML. Por isto a infraestrutura UML é
tipicamente utilizada pelo usuário final.
Comentários:
Primeiro, são quatro estruturas. Segundo, UML não é tipicamente utilizada pelo
usuário final, só isso já matava a questão!
Gabarito: E

13. (CESPE - 2011 - -ES - Técnico de Informática - Específicos) A linguagem de

restrição de objetos, ou OCL, é utilizada para especificar restrições existentes em
um modelo UML de sistema que esteja sendo projetado, como é o caso das
precondições e pós-condições.
Comentários:
A UML permite que você use qualquer coisa para descrever restrições. A única regra
é que você as coloque entre chaves { }. Você pode utilizar linguagem natural, uma
linguagem de programação ou a linguagem formal de restrições de objetos de UML
(OCL – Object Constraint Language), que é baseada no cálculo de predicados.
Gabarito: C
14. (CESPE - – UNIPAMPA/RS – Análise de Sistemas) Na UML 2.0, a OCL (object

constraint language) é uma linguagem formal usada para descrever restrições
em modelos UML, podendo ser também utilizada em classificadores.
Comentários:
Perfeito, é exatamente isso!
Gabarito: C
15. (CESPE - – CENSIPAM – Análise de Sistemas) A UML (unified modeling

language) define uma metodologia orientada a objetos para a análise de
sistemas e processos.
16712855225
Comentários:
UML não é exatamente uma metodologia para análise de sistemas e processo; é

uma linguagem de modelagem de propósito geral. No entanto, esse não é o foco
do item! Vocês têm que pegar esse cacoete: o item busca do aluno o conhecimento
de que a UML é orientada a objetos! Ok?
Gabarito: C

16. (CESPE - – CENSIPAM – Análise de Sistemas) Dentro da UML, existe uma

série de diagramas, entre os quais, citam-se: diagrama de fluxo de dados,
diagrama de objetos, casos de uso e outros.
Comentários:
Não, Diagrama de Fluxo de Dados (DFD) não é um dos diagramas da UML!
Gabarito: E
17. (CESPE - 2013 – MPU – Análise de Sistemas) Diagrama de caso de uso, diagrama
de sequência, diagrama de comunicação, diagrama de atividades e diagrama de
classes são diagramas comportamentais da UML.
Comentários:
Não! Diagramas de Classe são estruturais...
Gabarito: E
18. (CESPE - 2010 - Banco da Amazônia - 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.
16712855225
Comentários:
Perfeito! Trata-se de um relacionamento de Composição (Diamante Cheio) entre

Funcionário e Currículo. Logo, as partes são dependentes, i.e., não existe funcionário
sem currículo e não existe currículo sem funcionário.

Gabarito: C
19. (CESPE - 2010 - EMBASA - Analista de Saneamento - Analista de Tecnologia da

Informação – Desenvolvimento) Os diagramas em UML podem ser estáticos ou
dinâmicos. O diagrama de classes é um exemplo de um diagrama dinâmico.
Comentários:
Não, trata-se de um diagrama estático (ou estrutural)!
Gabarito: E
(CESPE - - TCU - Analista de Controle Externo - Tecnologia da Informação

- Prova 2) O método #Cadastrar( ) da classe Instrutor tem visibilidade do modo
protegido tal que somente a classe possuidora Instrutor pode utilizá-lo.
16712855225
Comentários:
De fato, ele tem visibilidade protegida. No entanto, essa visibilidade permite que o
método possa ser acessado por suas classes filhas.
Gabarito: E

21. (CESPE - - TRT - 5ª Região (BA) - Analista Judiciário - Tecnologia da

Informação) No diagrama, Bicicleta e Veiculo_motor são tipos de veículos e,
dessa forma, têm relação de herança com veículo. É correto afirmar que veículo
é subclasse de Bicicleta e Veiculo_motor.
Comentários:
Na verdade, Veículo é superclasse de Bicicleta e Veículo_motor!
Gabarito: E
(CESPE - 2010 - TRE-BA - Técnico Judiciário - Programação de Sistemas) Os

diagramas de classes podem conter pacotes ou subsistemas, utilizados para
agrupar elementos do modelo em um conjunto maior. No nível de visibilidade
privado, uma característica pode ser usada por qualquer descendente do
16712855225
classificador; contudo, um classificador nem sempre é capaz de visualizar outro

classificador.
Comentários:
Não, a visibilidade privada permite que uma característica possa ser usada somente
pela própria classe.
Gabarito: E

(CESPE - 2011 - Correios - Analista de Correios - Analista de Sistemas -

Desenvolvimento de Sistemas) O diagrama de classes define todas as classes de
que o sistema necessita e é a base para a construção dos diagramas de
sequência e comunicação.
Comentários:
Perfeito, é exatamente isso! Ele é a base para a construção dos diagramas de

comunicação, sequência e máquina de estados.
Gabarito: C
24. (CESPE - 2011 – AL/ES - Análise de Sistemas - E) O diagrama de classes, além de

definir a estrutura das classes utilizadas pelo sistema, determinando os atributos
e métodos de cada classe, estabelece como as classes se relacionam e trocam
informações entre si.
Comentários:
Gabarito: C
(CESPE - – IGEPREV - Análise de Sistemas - E) A multiplicidade de um

diagrama de classes corresponde à quantidade total de relacionamentos
existentes nesse diagrama.
Comentários:
16712855225
Não, ela especifica a quantidade de objetos de cada classe envolvidos em um

relacionamento.
Gabarito: E
(CESPE - – MPE/AM - Análise de Sistemas) Na UML, uma relação de

generalização-especialização entre elementos de um sistema é representada
com um diagrama de representação da herança entre uma classe e suas
subclasses.
Comentários:

Pessoal, essa questão tem uma redação completamente confusa! A relação é

representada por meio do diagrama de classes em que uma classe e suas subclasses
são conectadas por meio de uma linha sólida e um triângulo. Portanto, não existe
um diagrama de representação de herança, é o próprio diagrama de classes.
Gabarito: E
27. (CESPE - – MPE/AM - Análise de Sistemas) Na UML, uma agregação é um

relacionamento que estabelece que uma classe define objetos que são parte de
um objeto definido por outra classe.
Comentários:
Perfeito, é exatamente essa a definição de agregação! Lembrando que o

relacionamento de agregação é o do diamante vazio.
Gabarito: C
(CESPE - – MPE/AM - Análise de Sistemas) Em um diagrama de classes

UML, uma associação entre classes pode ser documentada em termos da
multiplicidade da associação.
Comentários:
Perfeito, é exatamente isso! A multiplicidade documentará a relação entre a

quantidade de objetos envolvidos no relacionamento.
16712855225
Gabarito: C
(CESPE - – PM/RB - Análise de Sistemas) As classes em um diagrama de

classes são compostas basicamente de três partes: um nome, atributos e
operações.
Comentários:
Perfeito, é exatamente isso! As classes são compostas por um nome, um conjunto

de atributos e um conjunto de operações.
Gabarito: C

(CESPE - – PM/RB - Análise de Sistemas) Em um diagrama de classes UML,

só é possível criar relacionamentos do tipo 1:1 porque uma classe apenas
implementa funções.
Comentários:
Não, esse item não faz nenhum sentido! É possível criar relacionamentos com
quaisquer multiplicidades.
Gabarito: E
31. (CESPE - – PM/RB - Análise de Sistemas) A generalização é uma

funcionalidade de um diagrama de classes utilizada quando duas classes são
similares.
Comentários:
Perfeito, um conjunto de funcionalidades similares de diversas classes podem ser

agrupadas em uma generalização.
Gabarito: C
(CESPE - 2007 – PRB/AC - Análise de Sistemas) Multiplicidade refere-se à

definição de quantas classes podem participar em um relacionamento.
Comentários:
Discordo veementemente do gabarito! A multiplicidade refere-se à definição de

16712855225
quantos objetos (ou instâncias) podem participar em um relacionamento. No

entanto, a banca não entendeu dessa maneira!
Gabarito: C
(CESPE - 2000 – TJDFT - Análise de Sistemas) Um diagrama de classes descreve

um conjunto de classes, interfaces e colaborações e suas relações. Esse diagrama
é capaz de descrever tanto o processo estático do sistema quanto o dinâmico,
em tempo de execução, sendo esse último estado também chamado de
diagrama de objetos.

Comentários:
Diagrama de Classes não descreve o aspecto dinâmico! Ademais, Diagrama de

Objetos é como uma fotografia das classes instanciadas em determinado momento
e, não, um estado do Diagrama de Classes.
Gabarito: E
34. (CESPE - 2010 – UNIPAMPA - Análise de Sistemas) O diagrama de objetos está

amplamente associado ao diagrama de classes, sendo que o primeiro consiste
em uma instância do segundo, em determinado momento da execução, ou seja,
um diagrama de objetos descreve os objetos, os métodos, os atributos e seus
valores, além dos vínculos entre os objetos, sendo ambos diagramas estruturais.
Comentários:
Eduardo Bezerra afirma: “Diagramas de objetos podem ser vistos como instâncias de
diagramas de classes, da mesma forma que objetos são instâncias de classes”. No
entanto, a primeira parte da questão não é o problema! O maior entrave é que a
documentação é omissa! Onde diz que não se pode representar operações? Lugar
algum!
No entanto, vamos pensar um pouco: é um Diagrama de Objetos, logo é estrutural.

Qual a utilidade de se representar métodos se o seu interesse é saber o estado de um
conjunto de objetos em um determinado instante? Não faz muito sentido! No
entanto, não está escrito que é proibido! Logo, algumas pessoas representam
também as operações/métodos com seus parâmetros e tipos de retorno, como essa
imagem no tópico de Diagrama de Objetos.
16712855225
Observe que a maioria dos objetos possui apenas atributos, mas um deles
representa também um método (+createUserCookie). Fazendo uma engenharia
reversa, essa questão com toda certeza não tem nenhum outro erro, logo o erro
para a banca é que Diagrama de Objetos não representa operações. Um bocado
de gente entrou com recurso porque nenhum lugar diz isso, mas não adiantou :-(
Gabarito: E

Desenvolvimento de Sistemas) O diagrama de componentes deve ser utilizado
para se representar a configuração e a arquitetura de um sistema no qual estarão

ligados todos os software e hardware, bem como sua interação com outros
elementos de suporte ao processamento.
Comentários:
Não! Essa é a exata descrição de um Diagrama de Implantação!
Gabarito: E
(CESPE - 2007 – TRE/TO - Analista de Sistemas) Um diagrama de componentes

permite mostrar componentes de um sistema e as dependências entre eles. As
dependências entre os componentes podem ser, por exemplo, dependências de
compilação ou de comunicação.
Comentários:
Perfeito! Podem ser quaisquer dependências...
Gabarito: C
37. (CESPE - 2013 - TRT - 10ª REGIÃO (DF e TO) - Analista Judiciário - Tecnologia da
Informação) O diagrama de implementação é um tipo de diagrama de
componente.
Comentários:
Não! Alguns autores inserem os Diagramas de Componentes e Diagramas de

Implantação em um conjunto maior chamado Diagrama de Implementação. Essa
não é uma classificação consagrada, mas é importante saber que ela existe.
16712855225
Gabarito: E

(CESPE - - TCU - Analista de Sistemas) Na figura, um diagrama UML de

implantação é modelado juntamente com um diagrama de componentes,
ambos voltados para a modelagem de aspectos físicos e estáticos de sistemas
orientados a objetos.
Comentários:
De fato, a questão mostra o Diagrama de Componentes (mais interno), com suas

interfaces, classes de fronteira, etc; e mostra o Diagrama de Implantação (mais
externo), com seus componentes de hardware e software. Ambos são voltados para
modelagem de aspectos estáticos ou estruturais de sistemas orientados a objetos,
mas apenas o Diagrama de Implantação é voltado para aspectos físicos, enquanto
o Diagrama de Componentes é claramente voltado para aspectos lógicos. Por essa
razão, discordo do gabarito!
Gabarito: C
(CESPE - - UNIPAMPA - Analista de Sistemas) Na UML 2.0, é possível, em

um único modelo, modelar os componentes de um software e descrever onde
eles são executados dentro de um nó, usando notação, respectivamente, do
diagrama de componentes e do diagrama de implantação, e, ainda, descrever
essa relação entre nós e componentes em subsistemas, utilizando a notação do
diagrama de pacotes. Todos esses diagramas são estruturais.
Comentários:
Na UML 2.0 já existe Diagramas de Componentes e Implantação? Sim! É possível

colocar dois diagramas em um único modelo? Sim! O Diagrama de Componentes
modela os componentes de um software? Sim! O Diagrama de Implantação descreve
16712855225
onde são executados os componentes dentro de um nó? Sim, eles possuem uma
relação estreita, visto que um nó contém um ou mais componentes. É possível
descrever essa relação entre nós e subsistemas utilizando Diagramas de Pacotes? Sim,
ele agrupa praticamente qualquer coisa! Os três diagramas são estruturais? Sim!
Logo, está tudo certo!
Gabarito: C
40. (CESPE - 2010 - INMETRO - Analista de Sistemas – D) Em um diagrama de

componentes em UML 2.0 contendo um conjunto de componentes que
modelam a arquitetura de uma aplicação web em três camadas, se três desses

conjuntos, nomeados por C1, C2 e C3, forem diretamente relacionados entre si

e representarem um componente, respectivamente, da camada de apresentação
de aplicação, da camada de negócios e da camada de persistência, então uma
relação direcional consistente que representa as dependências entre esses
conjuntos será: C3 depende de C2 e C2 depende de C3.
Comentários:
De acordo com a questão, temos que: C1 representa a Camada de Apresentação,

C2 representa a Camada de Negócios e C3 representa a Camada de Persistência. A
questão afirma que C3 depende de C2 e que C2 depende de C3, isto é, a Camada
de Persistência depende da Camada de Negócio e a Camada de Negócio depende
da Camada de Persistência, mas isso está errado. A Camada de Negócio depende
- sim - da Camada de Persistência, porque é de lá que vêm os dados de que ela
necessita; no entanto, a Camada de Persistência não depende da Camada de
Negócio, ela é independente!
Gabarito: E
41. (CESPE - 2010 – TRE/MT - Analista de Sistemas – C) Um diagrama de

componentes é do tipo estrutural, e mostra partes internas, conectores e portas
que implementam um componente.
Comentários:
De acordo com Booch: “Um diagrama de componentes mostra as partes internas,

os conectores e as portas que implementam um componente. Quando o componente
é instanciado, as cópias de suas partes internas também são instanciadas”.
16712855225
Gabarito: C
42. (CESPE - 2013 – FUB - Analista de Sistemas) Ao desenhar um diagrama de

componentes, exige-se que os componentes tenham a característica de serem
executáveis. Assim, somente as partes executáveis de um sistema estão presentes
em um diagrama de componente.
Comentários:
Não há exigência de que sejam executáveis.

Gabarito: E
43. (CESPE - 2013 – SERPRO - Analista de Sistemas) Com a utilização do diagrama

de componentes da UML (unified modeling language) podem ser modelados os
processos de negócio da empresa.
Comentários:
Não! Diagramas de Componentes são estáticos ou estruturais. Para modelar os

processos de negócio de uma organização, recomenda-se a utilização do Diagrama
de Atividades.
Gabarito: E
44. (CESPE - 2013 – TRT/17 - Analista de Sistemas) Ao se analisar um software e

desenhar o diagrama de componentes, deve-se considerar a linguagem que será
utilizada para implementar o sistema, pois ela determina o modo como os
componentes interagirão para o sistema funcionar corretamente.
Comentários:
Discordo do gabarito! Ora, UML é independente de linguagens de programação

específicas! Pode até depender na prática, mas na teoria não.
Gabarito: C
45. (CESPE - 2013 – TRT/17 - Analista de Sistemas) Caso seja necessário implantar
um sistema em mais de um servidor, o diagrama de componentes determinará
as necessidades e as características físicas de implementação de acordo com a
16712855225
UML.
Comentários:
Não! Isso é claramente Diagrama de Implantação e, não, Diagrama de Componente.
Gabarito: E
46. (CESPE - 2010 - EMBASA - Analista de Tecnologia da Informação) O objetivo

principal de um diagrama de pacotes é agrupar os pacotes em classes. Esse tipo
de diagrama pode usar dependências.

Comentários:
Na verdade, está invertido! Ele agrupa classes (entre outros elementos) em pacotes.
Gabarito: E
47. (CESPE - 2011 – PC/PA - Analista de Sistemas – B) O uso de packages UML não
possui relação direta com o conceito de modularização em desenvolvimento de
sistemas.
Comentários:
Não, possui claramente uma relação direta com o conceito de modularização em

desenvolvimento de sistemas.
Gabarito: E
48. (CESPE - 2011 - BRB - Analista de Tecnologia da Informação) O diagrama de

pacotes, usado, por exemplo, para demonstrar a arquitetura de uma linguagem,
tem por objetivo representar os subsistemas englobados por um sistema, de
forma a determinar as partes que o compõem.
Comentários:
Perfeito, o Diagrama de Pacotes tem por objetivo representar os subsistemas ou

submódulos englobados por um sistema de forma a determinar as partes que o
compõem. Pode ser utilizado de maneira independente ou associado com outros
diagramas. Este diagrama pode ser utilizado também para ajudar a demonstrar a
16712855225
arquitetura de uma linguagem, como ocorre com a própria UML.
Gabarito: C
49. (CESPE - 2010 - ABIN - Oficial Técnico De Inteligência - Desenvolvimento e

Manutenção de Sistemas) Um diagrama de implantação pode ser utilizado
quando o software é projetado para ser executado sobre uma única máquina
individual que não se comunica com outro hardware. A modelagem em conjunto
com diagramas de componentes, como ilustrado na figura a seguir, não é
possível na UML.

Comentários:
Bem, executar sobre uma única máquina individual não é o objetivo mais frequente,
mas nada impede que isso ocorra! Porém a modelagem é, sim, possível em conjunto
com diagramas de componentes.
Gabarito: E
(CESPE - 2010 – INMETRO – Análise de Sistemas – E) O diagrama de implantação

e o diagrama de classes pertencem ao modelo dinâmico.
Comentários:
Não, ambos são diagramas estáticos ou estruturais.
Gabarito: E
51. (CESPE - 2010 – TRE/MT – Análise de Sistemas – B) Exemplos de diagramas de

modelagem UML que expressam partes dinâmicas de um sistema são: diagrama
de caso de uso e diagrama de implantação.
16712855225
Comentários:
Não! Diagramas de Implantação são estáticos ou estruturais.
Gabarito: E
(CESPE - 2011 – MEC – Análise de Sistemas) Em um diagrama de implantação

com componentes, é possível indicar o protocolo na ligação entre dois nós, bem
como mostrar relações de dependência entre componentes.

Comentários:
Perfeito! Perfeito! Perfeito!
Gabarito: C
(CESPE - 2012 – MPE/PI – Análise de Sistemas) O diagrama de implantação da

UML é irrelevante para a representação de um sistema embutido, pois, nesse
processo, considera-se um único nó de hardware.
Comentários:
De fato, ele é bem mais útil para sistemas distribuídos do que para sistemas
embutidos! No entanto, um único nó de hardware pode ter vários nós de
processamento. Lembrando que Sistema Embutido é uma coleção complexa de
software para o hardware que interage com o mundo físico.
Gabarito: E
54. (CESPE - 2011 - EBC - Engenheiro de Software) Estereótipos são uma maneira de
destacar ou diferenciar um componente ou relacionamentos iguais, atribuindo-
lhes características especiais ou modificando-as de alguma forma.
Comentários:
Perfeito, é um dos mecanismos de extensibilidade!
Gabarito: C
16712855225
(CESPE - 2011 – AL/ES - Análise de Sistemas - D) O diagrama de casos de uso é

utilizado para modelar colaborações e descrever a estrutura interna de um
classificador.
Comentários:
Na verdade, quem modela colaborações e descreve a estrutura interna de um

classificador é o Diagrama de Estrutura Composta.
Gabarito: E

(CESPE - 2011 - EBC - Analista - Engenharia de Software) O diagrama de estrutura

composta é similar ao denominado diagrama de classes, porém este último
apresenta uma visão estática da estrutura de classes, enquanto o primeiro tenta
expressar arquiteturas de tempo de execução.
Comentários:
Gabarito: C
57. ESPE - 2010 – UNIPAMPA - Analista de Sistemas) Na UML 2.0, o diagrama de

estrutura composta (composite structure diagram) descreve a estrutura interna
de um classificador modelando as colaborações, no qual uma colaboração
descreve uma visão de um conjunto de instâncias que cooperam entre si para
executar uma função específica entre instâncias de classes, objetos ou interfaces.
Comentários:
Gabarito: C
(CESPE – – MPE-RR – Analista de Sistemas) No diagrama UML ao lado, o

ator Presidente está relacionado ao caso de uso Criar projeto; o caso de uso
Informar dados contém comportamento comum a dois casos de uso; o caso de
uso Pagar projeto estende o comportamento Financiar projeto e Cancelar
projeto é abstrato.
16712855225
Comentários:

O caso de uso Cancelar Projeto somente seria abstrato se estivesse escrito com
nome em itálico. A questão lhe oferece outra chance de acertar, visto que Financiar
Projeto estende o comportamento de Pagar Proteto e, não, o contrário.
Gabarito: E
(CESPE – 2011 – Correios – Analista de Correios – Analista de Sistemas –

Desenvolvimento de Sistemas) Um relacionamento include de um caso de uso A
para um caso de uso B indica que B é essencial para o comportamento de A.
Então, ao se executar o caso de uso A, executa-se também o B.
Comentários:
Questão perfeita! Recomendo que decorem isto!
Gabarito: C
(CESPE – 2011 – TER-ES – Técnico – Programação de Sistemas – Específicos) Os

modelos de casos de uso enfatizam os objetivos e as perspectivas do usuário,
demonstrando a visão de quem utiliza o sistema.
Comentários:
Essa foi fácil! Caso de uso representa uma funcionalidade descrita pelo usuário.
Gabarito: C
61. (CESPE – 2010 – TER-BA – Analista Judiciário – Análise de Sistemas) O propósito

16712855225
maior de um caso de uso é fornecer uma descrição do comportamento do

sistema. Assim, em um processo de desenvolvimento orientado a objetos, os
objetivos de um caso de uso são: definir escopo, detalhar os processos e cálculos
do sistema, organizar e dividir o trabalho, estimar o tamanho do projeto e
direcionar os testes.
Comentários:
Opa, casos de uso não detalham processos e cálculos do sistema e nem estimam,
por si só, o tamanho do projeto!

Gabarito: E
(CESPE – – SECONT-ES – Auditor do Estado – Tecnologia da Informação)

Casos de uso podem ser empregados para captar o comportamento de um
sistema ou de parte de um sistema. O comportamento do caso de uso pode ser
especificado pela descrição do fluxo de eventos de forma suficientemente clara
para que os seus usuários sejam capazes de compreendê-lo. Nesse fluxo, devem
ser incluídas definições relacionadas à forma de implementação, para que sejam
diretamente utilizadas pelos implementadores.
Comentários:
Não há definição relacionada à forma de implementação em casos de uso. Tudo

isso é abstraído e mostra-se o que fazer e, não, como fazer.
Gabarito: E
(CESPE – 2010 – EMBASA – Analista de Saneamento – Analista de Tecnologia da

Informação – Desenvolvimento) Um diagrama de casos de uso descreve um
cenário que mostra as funcionalidades do sistema do ponto de vista do usuário.
É comum o uso de atores nesse diagrama.
Comentários:
Questão muito tranquila!
Gabarito: C
64. (CESPE – 2010 – TER-BA – Técnico Judiciário – Programação de Sistemas) Um

16712855225
cenário, também denominado instância de caso de uso, é uma sequência

específica de ações e interações entre atores e o sistema em discussão. Assim,
um caso de uso é uma coleção de cenários relacionados de sucesso e fracasso,
que descrevem atores usando um sistema como meio para atingir um objetivo.
Comentários:
Pessoal, é comum pessoas acharem que este item está errado porque um caso de
uso não é uma coleção de cenários, mas de apenas um cenário. Não existe isso, há
cenários principais e cenários alternativos em um caso de uso!

Gabarito: C
(CESPE – 2011 – BRB – Analista de Tecnologia da Informação) O diagrama de

casos de uso é o mais específico e formal da UML, pois, além de servir de
referência para a construção de outros diagramas, é utilizado nas fases de
levantamento de sistemas e pode ser consultado durante todo o processo de
modelagem.
Comentários:
Na verdade, ele é bastante informal e pouco específico!
Gabarito: E
(CESPE – 2010 – ABIN – Oficial Técnico De Inteligência – Área De

Desenvolvimento E Manutenção De Sistemas) Um caso de uso pode não gerar
um diagrama de sequência, a exemplo do que ocorre com os de tipo
<<extend>>.
Comentários:
Questão perfeita! Casos de Uso estendidos são opcionais, portanto podem não
gerar um diagrama de sequência.
Gabarito: C
67. (CESPE – 2010 – Boa Vista/RR – Analista de Sistemas) Para a modelagem do

sistema usando UML (Unified Modeling Language), diagrama de casos de uso
permitirão modelar a sequência de ações e eventos de processamento do
16712855225
sistema de acordo com a participação dos atores do modelo.
Comentários:
Diagramas de Caso de Uso não permitem modelar a sequência de ações e eventos

de processamento do sistema.
Gabarito: E

(CESPE – 2009 – IE/MA – Análise de Sistemas) Um caso de uso é uma coleção

de cenários relacionados de sucesso e fracasso, que descrevem atores que usam
um sistema como meio para atingir um objetivo.
Comentários:
Gabarito: C
(CESPE – – IE/MA – Análise de Sistemas) Ator é uma entidade – pessoa ou

sistema –, com comportamento, que interage com o sistema que se está
projetando.
Comentários:
Perfeito, um ator é um elemento que interage com o sistema.
Gabarito: C
70. (CESPE – – IGEPREV – Análise de Sistemas – A) Na unified modelling

language (UML), um caso de uso representa as mudanças de estado sofridas por
determinado módulo de software à medida que ocorrem eventos direcionados
a tal módulo.
Comentários:
Na verdade, quem representa mudanças de estados é o Diagrama de Máquina de

Estados. 16712855225
Gabarito: E
71. (CESPE – – INPI – Análise de Sistemas – III) Diagramas de caso de uso

(use case) são adequados para expressar aspectos estruturais da organização
de um sistema de informação.
Comentários:
Não, como um Diagrama Comportamental, ele expressa aspectos dinâmicos da

organização de um sistema de informação.

Gabarito: E
72. (CESPE – – MPE/AM – Análise de Sistemas) Em um diagrama de casos de

uso da UML, um ator é definido como um usuário humano do sistema.
Comentários:
Não, pode ser um humano, uma máquina ou outro sistema cuja interação executa
uma ação significativa.
Gabarito: E

Comentários:
Pessoal, é comum pessoas acharem que este item está errado porque um caso de
uso não é uma coleção de cenários, mas de apenas um cenário. Não existe isso, há
cenários principais e cenários alternativos em um caso de uso!
Gabarito: C
74. (CESPE – 2011 – BRB – Analista de Tecnologia da Informação) O diagrama de

casos de uso é o mais específico e formal da UML, pois, além de servir
16712855225
de
modelagem.
Comentários:
Na verdade, ele é bastante informal e pouco específico!
Gabarito: E

75. (CESPE – 2010 – ABIN – Oficial Técnico De Inteligência – Área De

<<extend>>.
mentários:
Questão perfeita! Casos de Uso estendidos são opcionais, portanto podem não
gerar um diagrama de sequência.
Gabarito: C

Comentários:
Diagramas de Caso de Uso não permitem modelar a sequência de ações e eventos

de processamento do sistema.
Gabarito: E

Comentários: 16712855225
Gabarito: C
78. (CESPE – – IE/MA – Análise de Sistemas) Ator é uma entidade – pessoa ou

projetando.
Comentários:

Perfeito, um ator é um elemento que interage com o sistema.
Gabarito: C

a tal módulo.
Comentários:
Na verdade, quem representa mudanças de estados é o Diagrama de Máquina de

Estados.
Gabarito: E
(CESPE – – INPI – Análise de Sistemas – III) Diagramas de caso de uso

Comentários:
Não, como um Diagrama Comportamental, ele expressa aspectos dinâmicos da

organização de um sistema de informação.
Gabarito: E

16712855225
Comentários:
Não, pode ser um humano, uma máquina ou outro sistema cuja interação executa
uma ação significativa.
Gabarito: E
(CESPE - - MPE- - Analista de Sistemas) No diagrama UML abaixo, há

duas raias; há um estado final; as atividades Preencher pedido e Avaliar proposta
podem ser executadas concorrentemente; será executada a atividade Avaliar

relatório assim que for concluída a atividade Preencher pedido ou a atividade

Elaborar relatório; será executada a atividade Elaborar relatório se o pedido não
for urgente.
Comentários:
Na verdade, a atividade Avaliar Relatório será executada assim que for concluída
ambas as atividades: Preencher Pedido e Elaborar Relatório.
Gabarito: E
(CESPE - 2010 - EMBASA - Analista de Saneamento - Analista de Tecnologia da

Informação - Desenvolvimento) O diagrama de atividades tem por objetivo
16712855225
mostrar o fluxo de atividades em um único processo; entretanto, esse diagrama

não mostra como as atividades dependem umas das outras, porque isso é
responsabilidade do diagrama de dependências.
Comentários:
Na verdade, ele mostra – sim – como as atividades dependem umas das outras.
Além disso, não existe diagrama de dependências na UML.
Gabarito: E


atividade, considerado independente do diagrama de máquina de estado, serve
para descrever os passos a serem percorridos para a conclusão de uma atividade
específica.
Comentários:
Perfeito, é exatamente isso.
Gabarito: C
(CESPE - 2010 - MPU - Analista de Informática - Desenvolvimento de Sistemas)

Na UML, um diagrama de atividades oferece uma notação para mostrar uma
sequência de atividades, inclusive atividades paralelas. Ele pode ser aplicado em
qualquer perspectiva ou propósito, no entanto, é normalmente mais utilizado
para a visualização de fluxos de trabalho, processos de negócios e casos de uso.
Comentários:
Por mais estranho que isso possa soar, os Diagramas de Atividade são
frequentemente utilizados para representar fluxos de atividades dos diagramas de
caso de uso complexos. Quando temos um fluxo de eventos linear - i.e., contém
pouca ou nenhuma iteração ou lógica condicional -, um texto é suficiente para
capturar e representar as informações de um caso de uso.
No entanto, quando há uma lógica complexa no fluxo de eventos de um caso de

uso, condicionais, iterações, etc, pode ser bem difícil de acompanhar. Nesses casos,
é recomendável utilizar Diagramas de Atividade como uma alternativa para modelar
o fluxo de eventos de um caso de uso. Além disso, obviamente ele ajuda a visualizar
16712855225
fluxos de trabalho e processos de negócio. Bacana?
Gabarito: C
(CESPE - 2010 - TRE-BA - Técnico Judiciário - Programação de Sistemas) Na UML,

os diagramas de sequência e os diagramas de atividade, também denominados
diagramas de interação, auxiliam a modelar os aspectos dinâmicos de sistemas.
Um diagrama de interação é formado pelo conjunto de objetos e seus
relacionamentos e inclui as mensagens que poderão ser enviadas entre eles.
Comentários:

CESPE vacilando de novo! Diagrama de Atividade não é um diagrama de interação,

mas o gabarito se manteve intacto como correto.
Gabarito: C
87. (CESPE - 2011 – AL/ES - Análise de Sistemas - C) O diagrama de atividade

descreve as mensagens que são trocadas no processo, não se preocupando com
a temporalidade.
Comentários:
O Diagrama de Atividades não é um Diagrama de Interação, logo não descreve a

troca de mensagens entre objetos no processo.
Gabarito: E
(CESPE - 2012 – ANP - Análise de Sistemas) O diagrama de atividades da UML é

utilizado para documentar um processo com suas ações e tomadas de decisões.
Comentários:
Gabarito: C

Informação - Desenvolvimento) Um diagrama de estado é capaz de mostrar os
estados possíveis de um objeto. Além disso, pode mostrar as transações
16712855225
responsáveis pelas suas mudanças de estado.
Comentários:
Bem, nessa o CESPE vacilou! Não se mostram transações, mas transições! Pessoal,
já cansei de ver o CESPE errar essa palavra específica e não mudar o gabarito –
como ocorreu nessa questão.
Gabarito: C

(CESPE - 2010 - EMBASA - Analista de Saneamento - Analista de Tecnologia d

Informação - Desenvolvimento) É possível criar um diagrama de transição de
estados que descreva o ciclo de vida de um objeto em níveis de detalhe
arbitrariamente simples ou complexos, dependendo das necessidades, pois não
há a obrigação de ilustrar todos os eventos possíveis.
Comentários:
Questão perfeita! Não há nenhuma obrigação em ilustrar todos os eventos.
Gabarito: C
91. (CESPE - 2004 - TRE-AL - Analista Judiciário - Especialidade - Análise de Sistemas

- Desenvolvimento) Na UML, um diagrama de estados mostra os vários estados
pelos quais passa um objeto e as transições de um estado para outro.
Comentários:
Gabarito: C
(CESPE - 2011 – AL/ES - Análise de Sistemas - A) O diagrama de estados tem a

finalidade de descrever os passos a serem percorridos para a conclusão de uma
tarefa específica, representando os estados dos objetos.
Comentários:
Não, quem descreve passos para conclusão de uma tarefa é o Diagrama de

16712855225
Atividades.
Gabarito: E
(CESPE - – IE/MA – Analista de Sistemas) Um diagrama de estado é uma

representação pró-ativa dos estados e eventos de um sistema, ou seja,
representa a previsão do estado interno do sistema em resposta aos possíveis
eventos futuros que poderão ocorrer no sistema.
Comentários:

Os diagramas de gráficos de estados são empregados para a modelagem dos

aspectos dinâmicos de um sistema. Na maior parte, isso envolve a modelagem do
comportamento de objetos reativos. Um objeto reativo é aquele cujo
comportamento é mais bem caracterizado por sua resposta a eventos ativados
externamente ao seu contexto. Um objeto reativo tem um claro tempo de vida cujo
comportamento atual é afetado pelo seu passado.
Gabarito: E
94. (CESPE - 2009 – INPI – Analista de Sistemas - I) Diagramas de estado (statechart)

podem ser usados para especificar, sob a perspectiva do usuário, requisitos de
sistemas de informação.
Comentários:
Perfeito, podem sim!
Gabarito: C
(CESPE - 2013 – MPU – Analista de Sistemas) No contexto da máquina de

estados, o evento, que pode ser tanto externo quanto interno, constitui um
estímulo capaz de ativar a transição de um estado.
Comentários:
Perfeito! Perfeito! Perfeito! Os eventos podem ser externos ou internos. Os eventos

externos são aqueles passados entre o sistema e seus atores. Os eventos internos
são aqueles passados entre os objetos que vivem no interior do sistema.
16712855225
Gabarito: C
(CESPE - 2010 - TRE-BA - Técnico Judiciário - Programação de Sistemas) Um

requisito é uma característica de projeto, uma propriedade ou um
comportamento de um sistema. Um diagrama de sequência enfatiza a
ordenação temporal de mensagens.
Comentários:
Questão perfeita! É isso mesmo...

Gabarito: C
97. (CESPE - 2011 - Correios - Analista de Correios - Analista de Sistemas -

Desenvolvimento de Sistemas) O diagrama de sequência pode ser usado para
descrever como alguns objetos de um caso de uso colaboram em algum
comportamento ao longo do tempo.
Comentários:
De fato, o Diagrama de Sequência trata da interação de objetos ao longo do tempo.
Gabarito: C
(CESPE - 2011 - TRE-ES - Analista - Análise de Sistemas - Específicos) Na figura,

o tempo é mostrado no eixo vertical e os objetos envolvidos na sequência de
uma atividade, no eixo horizontal.
Comentários:
Quase idêntico ao que foi dito na aula. Na vertical é o tempo e na horizontal são os
objetos. 16712855225
Gabarito: C

Diagramas de interação são utilizados na UML para modelagem dos aspectos
dinâmicos do sistema. No diagrama de sequência - um diagrama de interação
em que é dada ênfase à ordenação temporal das mensagens -, é explicitamente
representada a linha de vida do objeto, bem como o período durante o qual ele
está desempenhando uma ação.
Comentários:

Essa questão foi muito mal escrita, porque ela dá a entender que o diagrama irá
explicitar o período durante o qual ele está desempenhando uma ação. Na verdade,
quem faz isso é o Diagrama de Tempo! O Diagrama de Sequência dá uma noção
do período, mas não é explicitado o período. De todo modo, o gabarito foi Item
Correto.
Gabarito: C
100. (CESPE - 2011 - -ES - Técnico de Informática - Específicos) A modelagem

que permite a identificação de funcionalidades, comportamento do sistema,
ambiente, relações entre agentes e detalhe de requisitos funcionais é
representada por meio de diagrama de sequência de atividades.
Comentários:
Quem identifica funcionalidades é o diagrama de casos de uso. Diagrama de

sequência está preocupado em representar o comportamento de objetos de um
único caso de uso.
Gabarito: E
101. (CESPE - 2011 - TRE-ES - Técnico - Programação de Sistemas - Específicos)

Em um diagrama de sequência, estão representadas classes, que não são
relacionadas por agregação e composição, entre outros tipos de relações
presentes em diagramas de classe, mas relacionadas, diretamente, por meio de
mensagens.
Diagrama de Sequência não representa classes, mas objetos!
Gabarito: E
102. (CESPE - 2011 – AL/ES - Análise de Sistemas - B) O diagrama de sequência

evidencia as tarefas a serem executadas em um caso de uso, sem descrever as
mensagens trocadas entre os objetos.
Comentários:

Na verdade, é o Diagrama de Atividades.
Gabarito: E
103. (CESPE - – IE/MA - Análise de Sistemas) Diagrama de Sequência

apresenta uma visão estática do sistema, ou seja, por meio dele não é possível a
representação de iterações entre atores e sistema para um conjunto específico
de casos de uso.
Comentários:
Diagrama de Sequência é comportamental, portanto apresenta uma visão dinâmica

do sistema.
Gabarito: E
104. (CESPE - 2010 – MPU - Análise de Sistemas) Na convenção de notação usada

na UML, a chamada por mensagens assíncronas é representada no diagrama de
sequência por meio de seta cheia (não pontilhada).
Comentários:
A mensagem Assíncrona é representada por uma seta Aberta e a mensagem

síncrona é representada por uma seta fechada (cheia ou não-pontilhada).
Gabarito: E
105. (CESPE - – MPM/AM – Analista de Sistemas) Um diagrama de seqüência

da UML apresenta tanto as interações entre atores e objetos quanto interações
16712855225
de objeto para objeto.
Comentários:
Gabarito: C
106. (CESPE - 2013 - ANCINE – Analista de Sistemas) Com relação à UML 2.0, o
diagrama de colaboração pode ser utilizado para modelagem de um conjunto
de funcionalidades que cooperam entre si para executar uma função específica.

Comentários:
Pessoal, o Diagrama de Colaboração é não existe mais na UML 2.0! Ele mudou de
nome para Diagrama de Comunicação! Ademais, quem modela colaborações é o
Diagrama de Estrutura Composta.
Gabarito: E
107. (CESPE - 2009 – IE/MA – Analista de Sistemas) Diagramas de colaboração

ilustram as interações entre objetos em forma de grafo ou rede, na qual os
objetos podem ser colocados em qualquer lugar do diagrama.
Comentários:
Atualmente chamado Diagrama de Comunicação, é muito semelhante ao Diagrama

de Sequência e preocupa-se com a organização estrutural dos objetos, em como
os objetos estão vinculados e as mensagens que estes trocam entre si, ilustrando
interações em forma de grafo ou rede.
Gabarito: C
108. (CESPE - 2009 – INPI – Analista de Sistemas) Diagramas de seqüência

(sequence) e colaboração (collaboration) envolvem a troca de mensagens entre
instâncias de classes.
Comentários:
Perfeito, são ambos diagramas de interação (atualmente, Diagramas de

16712855225
Colaboração são os Diagramas de Comunicação).
Gabarito: C
109. (CESPE - 2010 – TRE/MT – Analista de Sistemas – D) O diagrama de

comunicação enfatiza a ordem temporal de mensagens, que reagem a eventos
externos e internos.
Comentários:
Ordem temporal? Diagrama de Sequência!

Gabarito: E
110. (CESPE - 2011 – MEC – Analista de Sistemas) As informações mostradas no

diagrama de comunicação são, com frequência, praticamente as mesmas
apresentadas no diagrama de sequência, porém com um enfoque diferente: no
diagrama de sequência, não há preocupação com a temporalidade do processo,
isto é, ele se concentra no modo como os objetos estão vinculados e nas
mensagens que trocam entre si durante o processo.
Comentários:
Na verdade, é o Diagrama de Comunicação que não se preocupa com a

temporalidade do processo.
Gabarito: E
111. (CESPE - 2013 – BACEN – Analista de Sistemas) O diagrama de comunicação

mostra a sequência de interações entre os elementos, de acordo com a
temporalidade com que os processos acontecem.
Comentários:
Não! Não! Não! Diagrama de Comunicação se importa com a estrutura e o

Diagrama de Sequência se importa com a temporalidade.
Gabarito: E
112. (CESPE - 2009 – TCU – Analista de Sistemas) Na UML 2.0, o diagrama de

16712855225
interação geral é utilizado para modelar colaborações, conjunto de instâncias

que cooperam entre si para uma função específica; o diagrama de máquina de
estados representa estados de um caso de uso de um subsistema ou de um
sistema completo; e o diagrama de tempo demonstra a mudança de estado de
um objeto, ao longo do tempo decorrente de eventos externos.
Comentários:
Vamos reescrever da maneira correta: “Na UML 2.0, o diagrama de interação geral
estrutura composta é utilizado para modelar colaborações, conjunto de instâncias

estados representa estados de um caso de uso objeto de um subsistema ou de um

sistema completo; e o diagrama de tempo máquina de estados demonstra a
mudança de estado de um objeto, ao longo do tempo decorrente de eventos externos”
Gabarito: E
113. (CESPE - 2009 – UNIPAMPA – Analista de Sistemas) O diagrama de tempo é

um diagrama de interação na UML 2.0 e tem como objetivo descrever o
comportamento de objetos, representando a situação em que um objeto se
encontra, dentro de um processo, em determinado momento.
Comentários:
Na verdade, descreve o estado de objetos!
Gabarito: E
114. (CESPE - 2011 – MEC – Analista de Sistemas) O diagrama de tempo,

tipicamente utilizado para acompanhar os estados por que passa uma instância
de uma classe, descreve a mudança no estado ou condição de uma instância de
uma classe, ou o seu papel durante um tempo.
Comentários:
Gilleanes afirma: "O Diagrama de Tempo descreve a mudança no estado ou condição

de uma instância de uma classe ou seu papel durante um tempo. É tipicamente
utilizado para demonstrar a mudança no estado de um objeto no tempo em resposta
a eventos externos". No entanto, a questão foi considerada errada! Não faço ideia
de onde se encontra o erro – caso alguém encontre, avise-me ;)
16712855225
Gabarito: E
diagrama de interação geral é uma variação do diagrama de sequência que
fornece uma visão geral de um sistema ou processo de negócio.
Comentários:

Gilleanes afirma que: "O diagrama de visão geral de interação é uma variação do
diagrama de atividade que fornece uma visão geral dentro de um sistema ou processo
de negócio". A questão foi retirada literalmente daí!
No entanto, Martin Fowler afirma: “Os diagramas de visão geral da interação são
uma mistura de diagramas de atividades e diagramas de sequência”. Ora, se é uma
mistura de ambos, podemos dizer que é uma variação do diagrama de sequência.
Porém, não foi assim que a banca interpretou! Ela entendeu que ele é uma variação
do diagrama de atividades, somente.
Gabarito: E
116. (CESPE - 2013 - TRT - 10ª REGIÃO (DF e TO) - Analista Judiciário - Tecnologia
da Informação) O diagrama de atividade é composto pelos diagramas de estado
e de sequência.
Comentários:
Isso não existe! Na verdade, o Diagrama de Interação Geral é um híbrido de um

Diagrama de Sequência e o Diagrama de Atividades.
Gabarito: E
117. (CESPE – – TCU - Auditor Federal de Controle Externo) Na UML 2.0, o

diagrama de interação geral é utilizado para modelar colaborações, conjunto de
instâncias que cooperam entre si para uma função específica; o diagrama de
máquina de estados representa estados de um caso de uso de um subsistema
ou de um sistema completo; e o diagrama de tempo demonstra a mudança de
16712855225
estado de um objeto, ao longo do tempo decorrente de eventos externos.
Comentários:
Diagrama de Interação Geral é uma variação do Diagrama de Atividade que fornece

uma visão ampla dentro de um sistema ou processo de negócio. Esse diagrama
passou a existir somente a partir da UML 2.0 e costuma englobar diversos tipos de
diagramas de interação para demonstrar um processo geral. O Diagrama de
Estrutura Composta é utilizado para modelar Colaborações. Uma colaboração
descreve uma visão de um conjunto de entidades cooperativas interpretadas por
instâncias que cooperam entre si para executar uma função específica. O termo

estrutura desse diagrama refere-se a uma composição de elementos

interconectados, representando instâncias de tempo de execução colaboram, por
meio de vínculos de comunicação, para atingir algum objetivo comum. Esse
diagrama também pode ser utilizado para definir a estrutura interna de um
classificador. Portanto, os conceitos estão invertidos.
Gabarito: E
118. (CESPE - 2015 - STJ - Analista Judiciário) No diagrama de caso de uso, as

formas corretas de se ligar um ator a um caso de uso são por meio de associação,
que demonstra a utilização, pelo ator, da função representada pelo caso de uso,
e por meio da generalização, que demonstra a relação de herança entre ambos.
Comentários:
Pessoal, agora vamos falar sobre os tipos de relacionamentos em um diagrama de

classes. Eles representam as conexões entre classes, objetos, pacotes, tabelas, entre
outros. Há três tipos de relacionamentos entre classes: Dependência, Generalização e
Associação, como mostra a imagem abaixo. No entanto, eles se desdobram em vários
outros! Vejamos...
Conforme vimos em aula, esses são tipos de relacionamento do Diagrama de

Classes e, não, Casos de Uso.
Gabarito: E
119. (CESPE - 2015 - - Analista Judiciário) No diagrama de estrutura composta,

a denominação de uma ocorrência de colaboração possui a mesma notação
utilizada na denominação de um objeto, e essa ocorrência representa a aplicação
16712855225
do padrão descrito por uma colaboração a uma situação específica que envolve
classes ou instâncias que executam papéis específicos da colaboração, em que
uma colaboração pode conter outras colaborações dentro de si.
Comentários:
O Diagrama de Estrutura Composta é utilizado para modelar colaborações internas

de classes, interfaces e componentes para especificar uma funcionalidade. O que é
colaboração, professor? É uma visão de um conjunto de entidades cooperativas
interpretadas por instâncias que cooperam entre si para executar uma operação
específica. Inclusive, uma colaboração pode conter outras colaborações.

Conforme vimos em aula, os diagramas de estrutura composta realmente modelam

colaborações. Além disso, a notação é realmente a mesma dos diagramas de
objetos. E, por fim, uma colaboração pode conter outras colaborações.
Gabarito: C
120. (CESPE - 2015 - STJ - Analista Judiciário) No diagrama de classe, os símbolos

#, + e -, que precedem atributos e métodos para indicar nível de acessibilidade,
significam, respectivamente, protegida, pública e privada.
Comentários:

PÚBLICO + X X X X
PROTEGIDO # X X
UML
PACOTE ~ X X
PRIVADO – X
PÚBLICO + X X X X
PROTEGIDO # X X X
JAVA
DEFAULT ~ X X
PRIVADO - X
Conforme vimos em aula, a questão está perfeita!
Gabarito: C
16712855225
ACERTEI ERREI

(FCC - 2010 – DPE/SP – Análise de Sistemas) Na UML os diagramas servem para

capturar diferentes visões do sistema. NÂO é um diagrama UML:
a) Diagrama de Métodos.
b) Diagrama de Classes.
c) Diagrama de Objetos.
d) Diagrama de Sequência.
e) Diagrama de Estados.
Comentários:
16712855225
Conforme vimos em aula, não existe Diagrama de Métodos.
Gabarito: A
(FCC- 2012 – TRE/PI – Análise de Sistemas – IV) Um diagrama de objetos é um

tipo especial de diagrama, composto por objetos e seus vínculos, que
compartilha as mesmas propriedades comuns a todos os outros diagramas.

Comentários:
Diagramas de Objetos podem ser vistos como especiais por serem uma instância
do Diagrama de Classes ou por conterem valores específicos ao objeto em si. Ele,
de fato, é composto de objetos e seus vínculos e compartilha as mesmas
propriedades comuns a todos os outros diagramas. Professor, que propriedades?
Grady Booch afirma:
“Um diagrama de objetos é um tipo especial de diagrama e compartilha as mesmas

propriedades comuns a todos os outros diagramas – ou seja, um nome e o conteúdo
gráfico que formam uma projeção em um modelo. O que distingue um diagrama de
objetos de todos os outros tipos de diagramas é o seu conteúdo particular”.
Gabarito: C
(FC – – TCE/AL - Análise de Sistemas) Um diagrama de objetos:
a) tem a mesma função que um diagrama de atividades diferenciando deste

apenas na representação gráfica.
b) capta um conjunto de abstrações como um grupo de interesse e em tal

contexto expõe sua semântica e seus relacionamentos com outras abstrações
existentes nesse grupo da mesma forma que em um diagrama de classes.
c) exibe um único conjunto de objetos relacionados uns com os outros em um

determinado momento.
d) mostra a seqüência de execução de atividades entre objetos relacionados, no

16712855225
tempo, e a duração de cada objeto por meio de linhas de vida.
e) exibe diversos conjuntos de objetos relacionados uns com os outros em um

Comentários:
(a) Não, completamente errado! Um diagrama é estrutural com o objetivo de

modelar o fluxo de atividades de um sistema e o outro é comportamental com o
objetivo de modelar o relacionamento entre objetos de um sistema em um dado
instante de execução; (b) Galera... já ouviram falar em gerador de lero-lero? Pois é,

nada nesse item faz sentido! (c) Perfeito, é exatamente isso! Por que ele diz um único
conjunto de objetos? Porque são apenas aqueles objetos instanciados em um dado
momento da modelagem; (d) Sequência de execução de atividades? No tempo?
Linhas de vida? Trata-se de Diagrama de Sequência; (e) Na verdade, é apenas um
conjunto de objetos relacionados em um determinado momento.
Gabarito: C
(FCC- 2009 – MEC – Análise de Sistemas) A UML define em sua versão 2.0, treze
tipos de diagramas. Acerca do Diagrama de Objetos da UML, assinale a
alternativa correta:
a) O Diagrama de Objetos mostra a configuração de nós de processamento em

tempo de execução.
b) O Diagrama de Objetos representa retratos estáticos de instâncias de itens

encontrados em diagramas de classes.
c) O Diagrama de Objetos representa uma visão dinâmica da interface entre

objetos e funcionalidades do sistema.
d) O Diagrama de Objetos tem por propósito focalizar um fluxo de atividades

que ocorrem internamente em um processamento, dentro de um período de
tempo.
e) O Diagrama de Objetos descreve o comportamento de objetos como reação

a eventos discretos, por meio de sequências de estados e ações que ocorrem
durante sua vida.
16712855225
Comentários:

sistema em um dado momento de execução, portanto esses diagramas não refletem
o sistema genericamente, mas de forma específica – em um determinado instante.
Como ele mostra instâncias, em vez de classes, ele é frequentemente chamado
Diagrama de Instâncias.
(a) Diagrama de Implantação; (b) Perfeito; (c) Diagrama de Estrutura Composta; (d)
Diagrama de Tempo; (e) Diagrama de Máquina de Estados.

Gabarito: B
(FCC - 2011 - TCE-PR - Analista de Controle - Informática) Em UML 2.3, o

Diagrama de Perfil é um diagrama pertencente à categoria Diagrama de:
a) Estrutura estática, sendo usado para mostrar a estrutura de um sistema sob o

nível mais baixo dos classificadores.
b) Comportamento e mostra a estrutura interna de um classificador e o

comportamento de uma colaboração.
c) Comportamento, descrevendo a estrutura interna de uma classe e as

colaborações que esta estrutura torna possível.
d) Comportamento, sendo utilizado para descrever o hardware utilizado em

implementações de sistemas e os ambientes de execução.
e) Estruturas, que opera no nível metamodelo permitindo definir estereótipos

personalizados, valores etiquetados e restrições.
Comentários:
Diagramas Estruturais: representam aspectos estáticos do sistema sob diversas visões

diferentes. Em outras palavras, esses diagramas apresentam a estrutura do sistema
inalterada há qualquer momento por não levarem em consideração o tempo em sua
representação. São eles: Componente, Classes, Implantação, Perfil, Objetos, Estrutura
Composta e Pacotes.

16712855225
Conforme vimos em aula, trata-se de um Diagrama Estrutural! Ademais, ele

realmente opera no nível de metamodelo para definir estereótipos, etc.
Gabarito: E

(FCC – 2014 – TRT/1 – Analista de Sistemas) Diagramas de casos de uso

constituem-se em um tipo de diagrama definido na UML. Segundo a UML 2.4.1,
em um diagrama de casos de uso,
a) um ator pode ser representado apenas pelo símbolo do “stick man”.
b) só pode haver representado um único ator.
c) o número de atores e de casos de uso sempre deve ser o mesmo.
d) só pode haver representado um único caso de uso.
e) um ator pode ser representado pelo “stick man” ou por um retângulo com a
expressão <<actor>>.
Comentários:
A UML oferece diversos estereótipos padronizados, podemos citar

<<interface>>, <<extends>> e <<include>>. No entanto, vamos supor que
haja um relacionamento Pessoa saca Dinheiro. Não há um
estereótipo <<sacar>>, todavia ele pode ser criado e representado
usando Diagramas de Perfil por meio da expressão
<<estereótipo>>. Continuando: se eu não quiser representar um
ator por meio de um stickman, eu posso utilizar um retângulo
com o nome <<ator>> ou <<stickman>>.
Conforme vimos em aula, um Diagrama de Casos de Uso pode ter diversos atores
e diversos casos de uso, inclusive pode ter mais de um ator por caso de uso! E como
representar um caso de uso? Ora, através de um stickman ou através de estereótipos,
16712855225
i.e., um retângulo com o nome <<actor>>.
Gabarito: E
(FCC - 2013 – TRT/12 - Análise de Sistemas A UML é utilizada para modelar

sistemas orientados a objetos. Um de seus diagramas é usado como técnica para
descrever lógica de procedimento, processo de negócio e fluxo de trabalho. Esse
diagrama, de várias formas, desempenha um papel semelhante aos fluxogramas,
mas a principal diferença entre esse diagrama e a notação de fluxograma é que
o diagrama suporta comportamento paralelo. O diagrama citado é o de:

a) Máquina de Estados.
b) Atividades
c) Sequência.
d) Distribuição
e) Componentes.
Comentários:
O Diagrama de Atividades descreve lógica de procedimento, processo de negócio e

fluxos de trabalho. De várias formas, eles desempenham um papel semelhante aos
fluxogramas, mas se diferenciam, pois suportam comportamentos paralelos. Mas o
que é uma atividade? É um comportamento parametrizado representado como um
fluxo coordenado de ações.
Conforme vimos em aula, trata-se claramente do Diagrama de Atividades.
Gabarito: B
(FCC - 4 – AL/PE - Análise de Sistemas Visibilidade refere-se à capacidade

de um método referenciar uma característica de outra classe. Num diagrama de
classes da UML 2.0 a visibilidade é indicada com um prefixo representado pelos
caracteres:
I. #
II. +
III. ~
IV. -
Os tipos de visibilidade definidos de I a IV são correta e respectivamente:

16712855225
a) private - public - protected - package

b) public - private - package - protected
c) private - package - public - protected
d) protected - public - package - private
e) package - protected - private - public
Comentários:

UML PÚBLICO + X X X X

PROTEGIDO # X X
PACOTE ~ X X
PRIVADO – X
PÚBLICO + X X X X
PROTEGIDO # X X X
JAVA
DEFAULT ~ X X
PRIVADO - X
Conforme vimos em aula, já é possível matar a questão pelo primeiro item –

Protegido (#).
Gabarito: D
(FCC - 2013 – TRT/12 - Análise de Sistemas A especificação UML 2.5 define dois
tipos principais de diagramas UML: structure diagrams e behavior diagrams.
Behavior diagrams mostram o comportamento dinâmico dos objetos em um
sistema, que pode ser descrito como uma série de mudanças no sistema no
decorrer do tempo. São exemplos de Behavior diagrams os diagramas de
a) Comunicação, Fluxo de Informação e Objeto.

b) Comunicação, Deployment e Máquina de Estado.
c) Temporização, Componente e Atividade.
d) Sequência, Caso de Uso e Atividade.
e) Classe, Atividade e Sequência.
Comentários:
16712855225
Diagramas Comportamentais: representam aspectos dinâmicos do sistema como um

conjunto de mudanças no tempo. Podemos dizer em outras palavras que esses
diagramas apresentam como os processos do programa se relacionam com o passar
do tempo. São eles: Máquina de Estados, Casos de Uso, Atividade, Sequência,
Conforme vimos em aula, são Diagramas Comportamentais: Sequência, Casos de

Uso e Atividade.
Gabarito: D

10. (FCC - 2013 – AL/RN - Análise de Sistemas Os diagramas UML podem ser
divididos em dois grandes grupos, Diagramas Estruturais e Diagramas
Comportamentais. Analise a lista de diagramas abaixo:
I. Componentes.
II. Comunicação.
III. Implantação.
IV. Caso de Uso.
V. Classes.
VI. Estados.
São Diagramas Comportamentais APENAS os descritos em
a) III, IV e V.
b) I, IV e V.
c) II, V e VI.
d) I, II e V.
e) II, IV e VI.
Comentários:

Conforme vimos em aula, são Diagramas Comportamentais: Comunicação, Caso de

Uso e Estados. 16712855225
Gabarito: E
11. (FCC - 2 – TRF/2 - Análise de Sistemas Uma classe pode relacionar-se com
outras de diferentes maneiras, utilizando notações gráficas, tais como:

I, II e III referem-se, respectivamente, aos tipos:
a) associação, composição e generalização.

b) generalização, composição e associação.
c) composição, generalização e agregação.
d) associação, agregação e composição.
e) agregação, associação e generalização.
Comentários:
IMPORTANTE
Observem que o Relacionamento de Composição é representado por uma linha sólida com
um diamante cheio na classe compositora. Pessoal, quando eu aprendi isso, decorei assim:
Diamante Cheio = Composição. Portanto, Diamante Vazio = Agregação.
Conforme vimos em aula, Diamante Cheio é Composição; Diamante Vazio é

Agregação; e sem diamante algum é associação.
Gabarito: D
12. (FCC - 2 – TRF/2 - Análise de Sistemas A UML 2.0 divide os diagramas em

duas categorias, estruturais e de comportamento. São exemplos de diagramas
estruturais e de comportamento, respectivamente, os diagramas de:
a) classe e atividades.
b) comunicação e sequência. 16712855225
c) componentes e objetos.
d) máquinas de estado e casos de uso.
e) casos de uso e sequência.
Comentários:

Composta e Pacotes.


Conforme vimos em aula, Diagrama de Classes é Estrutural e Diagrama de

Atividades é Comportamental.
Gabarito: A
13. (FCC - 2 – TJ/PE - Análise de Sistemas Considere C = comportamental e E =

estrutural. Os diagramas de componentes, objetos, comunicação e estrutura
composta são, respectivamente, categorizados como:
a) C; C; E; C.
b) C; C; E; E.
c) C; E; E; C.
d) E; E; C; C.
e) E; E; C; E.
Comentários:

Composta e Pacotes. 16712855225

Conforme vimos em aula, os Diagramas de Componente (E); Objetos (E);

Comunicação (C); e Estrutura Composta (E).
Gabarito: E

14. (FCC - 1 – TRT/19 - Análise de Sistemas Considere: E = estruturais e C =

comportamentais. Os diagramas de comunicação, pacotes, implantação e
componentes são, respectivamente,
a) C; E; E; E.
b) C; C; E; E.
c) C; E; E; C.
d) E; C; C; C.
e) E; C; E; C.
Comentários:

Composta e Pacotes.

Conforme vimos em aula, os Diagramas de Comunicação (C); Pacotes (E);

Implantação (E); e Componentes (E).
16712855225
Gabarito: A
15. (FCC - 2 – TJ/PE - Análise de Sistemas Considere o seguinte diagrama UML:
O número 1 e símbolo 1..* que aparecem ao lado das classes Nota Fiscal e Itens
se referem à restrição de:
a) herança.

b) agregação.
c) identidade.
d) multiplicidade.
e) polimorfismo.
Comentários:
Relacionamento de Associação: relacionamento estrutural entre objetos e especifica

os objetos de uma classe que estão ligados a objetos de outra classe. São eles:
 Simples: é um tipo de relacionamento mais forte que o relacionamento de

dependência e indica que uma instância de um elemento está ligada à instância
de outro elemento. São representados por uma linha sólida com ou sem setas de
navegabilidade. Ademais, pode haver nomes para a associação e indicação de
multiplicidade.
Conforme vimos na nota de rodapé da aula, trata-se da multiplicidade – responsável

por representar a informação dos limites inferior e superior da quantidade de
objetos aos quais outro objeto pode estar associado.
Gabarito: D
16. (FCC - 2 – TRE/CE - Análise de Sistemas Na UML 2.0, representam

comportamentos de um sistema, os diagramas de:
a) comunicação e de caso de uso.

b) sequência e de implantação.
c) componentes e de atividades.
d) pacotes e de componentes. 16712855225
e) atividades e de implantação.
Comentários:


Conforme vimos em aula, trata-se de Diagramas Comportamentais: Comunicação

e Casos de Uso.
Gabarito: A
17. (FCC - 2 – TRE/CE - Análise de Sistemas Em UML, os diagramas de Caso de

Uso tem por objetivo:
a) representar os atributos e operações de uma classe ou objeto.
b) mostrar o fluxo de mensagens de uma atividade do sistema para outra.
c) capturar funcionalidades e requerimentos do sistema.
d) exibir uma interação entre um conjunto de objetos e seus relacionamentos.
e) representar o estado ou situação em que um objeto pode se encontrar no

decorrer da execução de processos de um sistema.
Comentários:
Eles servem para descrever as interações de usuários com o sistema, fornecendo uma
narrativa sobre como o sistema é utilizado. E o que é um cenário? Cenário é uma
instância de caso de uso, i.e., uma sequência de passos que descreve uma interação
entre um usuário e o sistema.
Conforme vimos em aula, os Diagramas de Caso de Uso capturam funcionalidades

e requerimentos do sistema. Vamos às outras opções: (a) Diagrama de Classes; (b)
16712855225
Diagrama de Atividades; (d) Diagrama de Comunicação; (e) Diagrama de Máquina

de Estados.
Gabarito: C
18. (FCC - 1 – TRT/19 - Análise de Sistemas Na versão 2.0 da UML, costuma

conter elementos tais como: ações, bifurcações, ramificações e fluxos. Trata-se
do diagrama de:
a) máquina de estados.
b) implantação.

c) sequência.
d) atividades.
e) artefatos.
Comentários:
Como apresenta a imagem abaixo, a Swimlane agrupa as atividades e as organizam

de acordo com suas respectivas responsabilidades, com o auxílio de ações,
bifurcações, fluxos e ramificações. São representadas como duas linhas paralelas,
horizontais ou verticais, e seu nome em uma das extremidades. Qualquer nó de
atividade entre essas linhas é considerado contido dentro de uma partição.
Conforme vimos em aula, trata-se do Diagrama de Atividades.
Gabarito: D
19. (FCC - 1 – TRE/AP - Análise de Sistemas São, respectivamente, dois

diagramas estruturais e dois comportamentais:
a) Package, Interaction Overview, Timing e Deployment.

b) Component, Deployment, Activity e State Machine.
c) Composite Structure, Package, Component e Communication.
d) State Machine, Object, Use Case e Composite Structure.
e) Object, Interaction Overview, Use Case e Activity.
Comentários:

16712855225

Composta e Pacotes.


Conforme vimos em aula, são dois Diagramas Estruturais: Component

(Componente) e Deployment (Implantação). São dois Diagramas Comportamentais:
Activity (Atividade) e State Machine (Máquina de Estados).
Gabarito: B
(FCC - 1 – TRE/AP - Análise de Sistemas Os casos de uso podem ser

organizados pela especificação de relacionamentos de:
a) evento, ramificação e inclusão.

b) composição, inclusão e extensão.
c) agregação, extensão e bifurcação.
d) generalização, inclusão e extensão.
e) herança, composição e autorrelacionamento.
Comentários:
Comunicação Extensão Inclusão Herança

Entre Casos de Uso X X X
Entre Atores X
Entre Casos de Uso e Atores X
Conforme vimos em aula, trata-se da Extensão, Inclusão e Herança (Generalização).
Gabarito: D
21. (FCC - 2011 – INFRAERO - Análise de Sistemas Para captar os requisitos

funcionais de um sistema pode- se utilizar a UML. O diagrama mais adequado
16712855225
para essa finalidade é o diagrama de:
a) casos de uso.
b) atividades.
c) colaboração.
d) classes.
e) comunicações.
Comentários:

Conforme vimos em aula, para capturar requisitos funcionais, recomenda-se utilizar

o Diagrama de Casos de Uso.
Gabarito: A
(FCC - 2011 – INFRAERO - Análise de Sistemas Na notação UML, um nome entre

ângulos (ex. <<nome>>), colocado acima do nome de outro elemento, é
utilizado para a representação gráfica de:
a) objeto.
b) função.
c) multiplicidade.
d) operação.
e) estereótipo.
Comentários:
Estereótipos permitem adaptar ou personalizar modelos com construções específicas

para um domínio, plataforma ou método de desenvolvimento particular. Trocando
em miúdos, é um mecanismo de extensão que dá mais poder e flexibilidade à UML.
Podemos ter estereótipos de dois tipos: predefinidos pela linguagem ou definidos pela
equipe de desenvolvimento. Como assim, professor?
16712855225

desenvolvimento pode criar seus próprios estereótipos! Como? Basta colocar o nome
do elemento delimitado pelos símbolos << e >>. Além disso, os estereótipos podem
ser definidos textualmente ou graficamente.
Conforme vimos em aula, essa notação representa um estereótipo.
Gabarito: E

(FCC - 2011 – INFRAERO - Análise de Sistemas Qualquer descendente do

classificador é capaz de usar a característica; sua especificação é antecedida pelo
símbolo #. A definição trata da visibilidade usada na notação UML, de nível:
a) público.
b) privado.
c) pacote.
d) protegido.
e) dependente.
Comentários:

PÚBLICO + X X X X
PROTEGIDO # X X
UML
PACOTE ~ X X
PRIVADO – X
PÚBLICO + X X X X
PROTEGIDO # X X X
JAVA
DEFAULT ~ X X
PRIVADO - X
Conforme vimos em aula, trata-se da Visibilidade Protegida.
Gabarito: D
24. (FCC - 1 – INFRAERO - Análise de Sistemas Como exemplo, a classe

16712855225
CarroImportado (em itálico) é escrita desta forma na UML para especificar que
tal classe:
a) é concreta.
b) pode não apresentar instâncias diretas.
c) herda características de mais de uma classe mãe.
d) herda características de apenas uma classe mãe.
e) se relaciona com ela mesma.
Comentários:


Professor, como se representa uma operação abstrata? Bem, basta escrever seu nome
em itálico! E como se representa uma operação estática? Bem, basta escrever seu
nome sublinhado!
Conforme vimos em aula, itálico significa que é uma classe abstrata, logo ela não
pode apresentar instâncias diretas.
Gabarito: B
(FCC - 1 – TRT/01 - Análise de Sistemas Na UML 2.0, os diagramas de objeto,

de componente, de atividade e de comunicação são, respectivamente, do tipo
(considere E para Estrutural e C para Comportamental):
a) C; C; C; E.
b) C; C; E; E.
c) C; E; E; C.
d) E; C; E; C.
e) E; E; C; C.
Comentários:

Composta e Pacotes.
16712855225

Conforme vimos em aula, os Diagramas de Objeto (E); Componente (E); Atividade

(C); e Comunicação (C).
Gabarito: E

(FCC - 1 – TRT/24 - Análise de Sistemas Na UML, o relacionamento entre

uma superclasse e suas subclasses é denominado:
a) generalização.
b) decomposição.
c) agregação composta.
d) agregação não composta.
e) dependência.
Comentários:
Relacionamento de Generalização/Especialização (Herança): indica que a subclasse é

uma especialização da superclasse ou que a superclasse é uma generalização da
Conforme vimos em aula, trata-se da Generalização/Especialização (Herança).
Gabarito: A
27. (FCC - 1 – TRT/24 - Análise de Sistemas Na UML, especifica-se que uma

classe é abstrata escrevendo seu nome:
a) só com a inicial em letra maiúscula.

b) todo com letras maiúsculas.
c) em itálico.
d) em negrito.
e) grifado. 16712855225
Comentários:

nome sublinhado!
Conforme vimos em aula, deve vir em itálico.

Gabarito: C
(FCC - 1 – TRE/RN - Análise de Sistemas Frequentemente usado para

modelagem de sistemas de tempo real. Descreve como um sistema responde
aos estímulos internos e externos. Mostra as diferentes situações do sistema e os
estímulos que provocam transições de uma para outra situação. Trata-se do
modelo de:
a) eventos.
b) agregação de objetos.
c) dados.
d) fluxo de dados.
e) máquina de estado.
Comentários:

estados possíveis de um objeto no decorrer da execução de processos de um sistema.
Dessa forma, um objeto pode passar de um estado inicial para um estado final, por
meio de uma transição, quando ocorre algum evento ou estímulo interno ou externo
ao sistema.
Conforme vimos em aula, trata-se do Modelo (ou Diagrama) de Máquina de

Estados.
Gabarito: E
(FCC - 1 – TRE/RN - Análise de Sistemas São organizadas em uma hierarquia,

com as classes de objetos mais genéricas no topo, as quais legam seus atributos
16712855225
às classes mais especializadas.
Trata-se:
a) da hierarquia de herança.
b) do modelo relacional.
c) da gestão hierárquica.
d) do modelo sequencial.
e) da especificação funcional.
Comentários:

 Relacionamento de Herança: relacionamento entre atores, utilizado quando o ator

filho é um uma especificação do ator genérico. É bastante útil para definir
um triângulo no ator genérico. Na imagem abaixo, Vendedor é especialização de
Pessoa. É representado por uma linha com um triângulo.
Conforme vimos em aula, trata-se da hierarquia de herança.
Gabarito: A
(FCC - 1 – CAIXA - Análise de Sistemas Um detalhe importante que deve ser

especificado para os atributos e operações das classes é a visibilidade. Desta
forma, os símbolos: + (sinal de mais), # (sinal de número), - (sinal de menos) e ~
(til) correspondem respectivamente a:
a) público, pacote, privado e protegido.

b) público, protegido, privado e pacote.
c) privado, protegido, público e pacote.
d) privado, pacote, público e protegido.
e) pacote, protegido, privado e público.
Comentários:

PÚBLICO + X X X X
PROTEGIDO # X X
UML
PACOTE ~ X X
PRIVADO – X
16712855225
PÚBLICO + X X X X
PROTEGIDO # X X X
JAVA
DEFAULT ~ X X
PRIVADO - X
Conforme vimos em aula, é Público, Protegido, Privado e Pacote.
Gabarito: B

31. (FCC - 0 – TRT/22 - Análise de Sistemas A modelagem de instâncias de itens

contidos em diagramas de classes é feita pelo diagrama de:
a) sequência.
b) pacotes.
c) casos de uso.
d) objetos.
e) componentes.
Comentários:

Conforme vimos em aula, trata-se do Diagrama de Objetos.
Gabarito: D
(FCC - 0 – TRT/22 - Análise de Sistemas Na UML 2.0 NÃO se trata de um

dos diagramas de interação, o:
a) Sequence.
b) Deployment.
c) Interaction Overview.
d) Timing.
e) Communication. 16712855225
Comentários:

relacionamento dinâmico e colaborativo entre os objetos do sistema e suas trocas
de informações. Eles enfatizam o controle de fluxo e dados entre as coisas do
sistema que estão sendo modeladas (Ex: Objetos). São eles: Sequência,
Conforme vimos em aula, o Diagrama de Implantação (Deployment) não é um

Diagrama de Interação.

Gabarito: B
(FCC - 0 – TRT/22 - Análise de Sistemas Na taxonomia dos diagramas de

estrutura (S) e de comportamento (C) da UML, os diagramas de Pacote, Classe,
Sequência e Objeto são, respectivamente, de
a) S, S, C e S.
b) S, S, C e C.
c) S, C, S e C.
d) C, S, C e S.
e) C, C, S e C.
Comentários:

Composta e Pacotes.

Conforme vimos em aula, os Diagramas de Pacote (S); Classe (S); Sequência (C); e
Objeto (S). 16712855225
Gabarito: A
34. (FCC - 0 – MPE/RN - Análise de Sistemas Na UML, um relacionamento entre

superclasses (classesmãe) e subclasses (classes-filha), é uma:
a) associação.
b) dependência.
c) composição.
d) agregação.
e) generalização.

Comentários:

Gabarito: E
(FCC - 0 – MPE/RN - Análise de Sistemas Na UML, um relacionamento entre

a) associação.
b) dependência.
c) composição.
d) agregação.
e) generalização.
Comentários:

16712855225
Gabarito: E
(FCC - 0 – BAHIAGÁS - Análise de Sistemas Na UML é uma forma de

agregação com propriedade bem definida e tempo de vida coincidente da parte
com o todo. Trata-se de:
a) Generalização.
b) Estereótipo.
c) Visibilidade.

d) Composição
e) Herança.
Comentários:

relacionado às partes de forma dependente. Nesse relacionamento, as partes não
têm existência própria. Logo, não existem por si só, i.e., a parte não existe sem o
todo. É representado por uma linha com um diamante cheio na extremidade
referente ao todo.
Quando ele diz que o tempo de vida da parte coincide com o todo, ele quer dizer
que não existe parte sem o todo. Logo, trata-se de composição.
Gabarito: D
37. (FCC - 2010 – BAHIAGÁS - Análise de Sistemas É um tipo de diagrama

comportamental da UML. Trata-se do Diagrama de:
a) Casos de Uso.
b) Pacotes.
c) Objetos.
d) Componentes.
e) Classes.
Comentários:

16712855225

Conforme vimos em aula, trata-se do Diagrama de Casos de Uso.
Gabarito: A
(FCC - 2010 – TRF/4 - Análise de Sistemas Em UML, ele é uma variação do

diagrama de classes e utiliza quase a mesma notação, exceto que os objetos são

escritos com seus nomes sublinhados e todas as instâncias num relacionamento

são mostradas. Trata-se do diagrama de:
a) Estado.
b) Objetos.
c) Sequência.
d) Colaboração.
e) Atividade.
Comentários:
O Diagrama de Objetos (ou Diagrama de Instâncias) é uma variação do Diagrama

de Classes. Contudo, aqui não se trata da estrutura geral, mas de cada instância
específica do sistema. Portanto, no diagrama de objetos não há Pessoa, há “João”.
Não há Carro, há “Pálio”. Não há Cachorro, há “Totó”. Entenderam? No diagrama de
objetos, personaliza-se cada instância com seus valores.
Gabarito: B
(FCC - 0 – SGSA - Análise de Sistemas Em UML, são diagramas feitos para

facilitar a comunicação com os futuros usuários do sistema, e com o cliente,
sendo especialmente úteis para determinar os recursos necessários que o
sistema deve ter, mas não são adequados para representar o desenho e não
podem descrever os mecanismos internos de um sistema. São diagramas de:
a) Sequência.
b) Colaboração. 16712855225
c) Distribuição.
d) Caso de Uso.
e) Atividade.
Comentários:

Gabarito: D
40. (FCC - 2010 – AL/SP - Análise de Sistemas Na UML 2.0, o Diagrama de

Comunicação e o de Sequência são dois tipos de diagrama de:
a) Estrutura Composta.
b) Componente.
c) Interação.
d) Máquina de Estado.
e) Objeto.
Comentários:

Conforme vimos em aula, são Diagramas de Interação.
Gabarito: C
41. (FCC - 0 – METRÔ/SP - Análise de Sistemas São os meios utilizados para a

visualização dos blocos de construção da UML e representam graficamente um
conjunto de elementos, além de permitir visualizar o sistema sob diferentes
16712855225
perspectivas. Essa é a definição de:
a) Eventos.
b) Classes.
c) Objetos.
d) Relacionamentos.
e) Diagrama.
Comentários:

Conforme vimos em aula, a questão trata dos diagramas.
Gabarito: E
42. (FCC - 0 – TRT/20 - Análise de Sistemas São os meios utilizados para a

conjunto de elementos, além de permitir a visualização do sistema sob diferentes
a) Relacionamentos.
b) Diagrama.
c) Eventos.
d) Classes.
e) Objetos.
Comentários:
16712855225
Conforme vimos em aula, a questão trata dos diagramas.
Gabarito: B
43. (FCC - 2010 – TCM/PA - Análise de Sistemas De acordo com a OMG, especifica
a coordenação de execuções de comportamentos usando um modelo de fluxo
de controle e de dados. Modela o comportamento do sistema denotando os
caminhos lógicos que um processo pode seguir. Compõe a visão dinâmica da
UML o diagrama de:
a) estado composto.

b) atividades.
c) objetos.
d) entidades.
e) composição.
Comentários:

Conforme vimos em aula, a visão dinâmica é dada por diversos diagramas – dentro
os quais, o diagrama de atividades.
Gabarito: B
44. (FCC - 0 – TCM/P - Análise de Sistemas Na UML, a linha de vida (lifeline) é

parte integrante do diagrama de:
a) artefatos.
b) sequência.
c) pacotes.
d) componentes.
e) gráfico de estados.
Comentários:
16712855225

Conforme vimos em aula, trata-se do Diagrama de Sequência.
Gabarito: B

45. (FCC - 0 – TCM/PA - Análise de Sistemas Um relacionamento do tipo todo-

parte, no qual a vida da parte depende da vida do todo, é do tipo:
a) composição.
b) especialização.
c) dependência.
d) enumeração.
e) cardinalidade.
Comentários:

referente ao todo.
Conforme vimos em aula, quando a questão afirma que a parte depende da vida
do todo, ela está dizendo que as partes não têm existência própria. Logo, trata-se
de uma composição.
Gabarito: A
46. (FCC - 2010 – TCM/PA - Análise de Sistemas O antigo diagrama de colaboração

é adotado na UML 2.0 como diagrama de:
a) objeto.
b) estado.
c) iteração. 16712855225
d) implantação.
e) comunicação.
Comentários:
O Diagrama de Comunicação também é uma espécie de diagrama de interação

muito semelhante ao diagrama de sequência, mas com ênfase na ordem estrutural
e, não, temporal. Em versões anteriores da UML, era conhecido como Diagrama de
Colaboração. Mas como é possível verificar a ordem? Ele possui números que
identificam a sequência.

Conforme vimos em aula, a questão trata do Diagrama de Comunicação.
Gabarito: E
47. (FCC - – TRT/3 - Análise de Sistemas Um relacionamento entre classes que

usa como notação um diamante preenchido associando, por exemplo, as classes
Janela e Moldura, representa:
a) um legado.
b) um polimorfismo.
c) uma generalização.
d) uma dependência.
e) uma composição.
Comentários:
IMPORTANTE
Observem que o Relacionamento de Composição é representado por uma linha sólida com
um diamante cheio na classe compositora. Pessoal, quando eu aprendi isso, decorei assim:
Diamante Cheio = Composição. Portanto, Diamante Vazio = Agregação.
Conforme vimos em aula, a questão trata da composição.
Gabarito: E
48. (FCC - – TRT/3 - Análise de Sistemas Como extensão do vocabulário UML,

a representação gráfica de um nome entre ângulos (<< >>), colocado acima do
16712855225
nome de outro elemento, representa:
a) um pacote.
b) um desvio.
c) um estereótipo.
d) uma agregação.
e) uma especialização.
Comentários:

Pode ser classificado também em estereótipos textuais e gráficos: os primeiros devem

vir delimitados pelos símbolos << e >>; os segundos devem vir com um ícone que
lembre o conceito sendo representado. Essas duas classificações são independentes,
logo é possível ter estereótipos gráficos ou textuais sendo predefinidos ou definidos
pela equipe de desenvolvimento. Ficou claro agora?
Conforme vimos em aula, a questão trata dos estereótipos.
Gabarito: C
49. (FCC - – TRT/7 - Análise de Sistemas Uma parte física e substituível de um

sistema com o qual está em conformidade e proporciona a realização de um
conjunto de artefatos (UML) é um:
a) componente.
b) atributo.
c) método.
d) caso de uso.
e) objeto.
Comentários:

Conforme vimos em aula, a questão trata dos componentes.

16712855225
Gabarito: A
(FCC - – TRE/PI - Análise de Sistemas No diagrama de classes da UML uma

superclasse, com uma ou mais subclasses, representa um relacionamento do
tipo:
a) composição.
b) agregação.
c) generalização.
d) associação.

e) modularização.
Comentários:

Conforme vimos em aula, a questão trata da generalização.
Gabarito: C
51. (FCC - – TJ/SE - Análise de Sistemas NÃO se trata de um relacionamento

especificado na UML:
a) o encapsulamento.
b) a dependência.
c) a generalização.
d) a associação.
e) a realização.
Comentários:
Galera, encapsulamento é um relacionamento? Jamais!
Gabarito: A
16712855225
(FCC - – TJ/SE - Análise de Sistemas Uma classe abstrata, de acordo com

a UML,
a) tem seu nome escrito em itálico.

b) pode ser instanciada diretamente.
c) não tem atributos.
d) não tem operações.
e) não pode ter classes-filha.
Comentários:


nome sublinhado!
Conforme vimos em aula, ela tem seu nome escrito em itálico.
Gabarito: A
(FCC - – TJ/15 - Análise de Sistemas Na UML, a visibilidade declarada aos

atributos e operações de classificadores define que quando a um deles antecede
o símbolo - (sinal de menos) este é somente:
a) privado.
b) protegido.
c) público protegido.
d) público.
e) pacote público.
Comentários:

PÚBLICO + X X X X
PROTEGIDO # X X
UML
PACOTE ~ X X
PRIVADO – X
PÚBLICO + X X X X
16712855225
PROTEGIDO # X X X
JAVA
DEFAULT ~ X X
PRIVADO - X
Conforme vimos em aula, trata-se da visibilidade privada.
Gabarito: A
54. (FCC - – TJ/15 - Análise de Sistemas Cobre um conjunto de instâncias dos

itens encontrados nos diagramas de classe, expressa a parte estática de uma

interação composta pelos objetos que colaboram entre si, mas sem qualquer
uma das mensagens passadas entre eles e, também, congela um momento no
tempo. Na UML, trata-se do diagrama de:
a) atividade.
b) comunicação.
c) sequência.
d) tempo.
e) objetos.
Comentários:

Gabarito: E
(FCC - – TJ/16 - Análise de Sistemas Considere diversas agências (classe

Agencia) de atendimento a reclamações trabalhistas espalhadas em vários
pontos do Estado. Uma delas, a central (classe AgenciaCentral), tem atributos
diferenciados, porém herda os demais atributos e operações de Agencia. O
relacionamento entre essas classes é definido na UML como:
a) inclusão. 16712855225
b) composição.
c) específico.
d) generalização.
e) encapsulamento.
Comentários:

uma especialização da superclasse ou que a superclasse é uma generalização d


Gabarito: D
(FCC - – TJ/16 - Análise de Sistemas São diagramas comportamentais da

UML:
a) Component e Activity.
b) Timing e Deployment.
c) Composite Structure e Use Case.
d) State Machine e Object.
e) Use Case e Sequence.
Comentários:

Conforme vimos em aula, trata-se dos Diagramas de Casos de Uso e Sequência.
Gabarito: E
57. (FCC - – TJ/16 - Análise de Sistemas São diagramas estruturais da UML:

16712855225
a) Package e Activity.
b) Communication e Activity.
c) Communication e Object.
d) Class e Use Case.
e) Composite Structure e Deployment.
Comentários:



Composta e Pacotes.
Conforme vimos em aula, trata-se dos Diagramas de Estrutura Composta e

Implantação.
Gabarito: E
(FCC - – TJ/PA - Análise de Sistemas Na especificação de operações de

uma classe, o nível de visibilidade indicado pelo símbolo ~ (til) significa:
a) escopo de instância.
b) escopo de estática.
c) pacote.
d) privado.
e) protegido.
Comentários:

PÚBLICO + X X X X
PROTEGIDO # X X
UML
PACOTE ~ X X
PRIVADO – X
PÚBLICO + X X X X
PROTEGIDO # X X X
JAVA 16712855225
DEFAULT ~ X X
PRIVADO - X
Conforme vimos em aula, trata-se dos da visibilidade Pacote.
Gabarito: C
(FCC - 2009 – TJ/PA - Análise de Sistemas) Considere o enunciado: Uma escola

(todo) tem um ou mais departamentos (parte). Cada departamento pertence
exatamente a uma única escola. No âmbito da UML, este enunciado especifica
um relacionamento de:

a) agregação por composição.

b) realização.
c) dependência.
d) herança.
e) recursão.
Comentários:

referente ao todo.
Se cada departamento percence exatamente a uma única escola, então temos um

relacionamento de agregação por composição. Por que? Porque um departamento
não existe sem uma escola!
Gabarito: A
(FCC - – TJ/PA - Análise de Sistemas) Considere:
I. Modelagem do aspecto dinâmico de um sistema;

II. Exibição da concorrência de atividades;
III. Exibição das ramificações de controle de fluxo.
O Diagrama de Atividades da UML contempla corretamente o que consta em

16712855225
a) I, apenas.
b) II, apenas.
c) III, apenas.
d) II e III, apenas.
e) I, II e III.
Comentários:
As ramificações especificam caminhos alternativos baseados em expressões

booleanas – é representado com um diamante. A bifurcação é a divisão de um
mesmo fluxo de controle em dois ou mais fluxos concorrentes: poderá ter uma única

transição de entrada e duas ou mais transições de saída; abaixo da bifurcação, as

atividades associadas com cada um dos caminhos prosseguem paralelamente.
(a) Correto, ele é um diagrama comportamental, logo modela aspectos dinâmicos

do sistema; (b) Correto, ele apresenta elementos que permitem representar fluxos
concorrentes; (c) Correto, ele possui ramificações que especificam alternativos
baseados em expressões booleanas.
Gabarito: E
61. (FCC - – TJ/PA - álise de Sistemas) Nos relacionamentos entre Casos de

Uso:
a) um include significa que o caso de uso base incorpora implicitamente o

comportamento de outro, sob certas condições.
b) não é permitida a generalização.
c) somente include é considerado um estereótipo.
d) somente extend é considerado um estereótipo.
e) tanto include quanto extend são considerados estereótipos.
Comentários:
(a) Errado, isso é extensão; (b) Errado, é permitida a generalização/especialização;

(c) Errado, extend também é um estereótipo; (d) Errado, include também é um
estereótipo; (e) Correto, ambos são estereótipos.
16712855225
Gabarito: E
(FCC - 2009 – MPE/SE - Análise de Sistemas) Uma instância de classe em um

determinado momento é
a) uma cardinalidade.
b) uma operação.
c) um atributo.
d) um objeto.
e) uma sequência de operações.

Comentários:

Conforme vimos em aula, um objeto é uma instância de uma classe.
Gabarito: D
(FCC - – MPE/SE - Análise de Sistemas) Considerando os tipos COM =

comportamental e EST = estrutural na UML 2.0, classifique correta e
respectivamente os seguintes diagramas UML:
I. State Machine Diagram

II. Sequence Diagram
III. Composite Structure Diagram
a) EST - COM - COM.

b) COM - EST - EST.
c) COM - COM - EST.
d) COM - EST - COM.
e) EST - EST - COM.
Comentários:
16712855225

Composta e Pacotes.


Conforme vimos em aula, diagrama de máquina de estados é comportamental;

diagrama de sequência é comportamental; e diagrama de estrutura composta é
estrutural.
Gabarito: C
64. (FCC - – MPE/SE - Análise de Sistemas) Considere uma operação de classe

escrita da seguinte forma:
+ adicionarMensagem(m: Mensagem): Status
O símbolo de soma no início do texto e o termo entre parênteses significam,

respectivamente:
a) público e assinatura.
b) protegido e método.
c) assinatura e privado.
d) privado e método.
e) método e público.
Comentários:

PÚBLICO + X X X X
PROTEGIDO # X X
UML
PACOTE ~ X X
PRIVADO – X
16712855225
PÚBLICO + X X X X
PROTEGIDO # X X X
JAVA
DEFAULT ~ X X
PRIVADO - X
Conforme vimos em aula, o sinal significa visibilidade pública e o termo entre

parênteses é apenas a assinatura do método.
Gabarito: A

(FCC - 2009 – PGE/RJ - Análise de Sistemas) No âmbito da UML, é o mais

importante detalhe que pode ser especificado para atributos e operações de um
classificador e cuja especificidade, que pode ser de quatro níveis diferentes (ex.
pacote), é utilizável por outros. Trata-se de:
a) usabilidade.
b) parâmetro.
c) instância.
d) visibilidade.
e) escopo de efeito.
mentários:

PÚBLICO + X X X X
PROTEGIDO # X X
UML
PACOTE ~ X X
PRIVADO – X
PÚBLICO + X X X X
PROTEGIDO # X X X
JAVA
DEFAULT ~ X X
PRIVADO - X
Conforme vimos em aula, trata-se da visibilidade.
Gabarito: D
16712855225
(FCC - 8 – TRT/18 - Análise de Sistemas) Se em algum ponto de um Caso de

Uso houver a necessidade de inserir incondicionalmente um cenário contido em
outro Caso, deve-se usar o relacionamento de dependência estereotipado
como:
a) <<realize>>.
b) <<extend>>.
c) <<generalize>>.
d) <<enumeration>>.
e) <<include>>.

Comentários:

repete em mais de um caso de uso. A imagem abaixo apresenta o domínio de um
internet banking. Observem que, para realizar um pagamento ou visualizar o
saldo, é obrigatório que fazer Login. Logo, é um relacionamento obrigatório,
representado por uma seta tracejada com uma seta na ponta.
Conforme vimos em aula, o relacionamento de inclusão deve ser utilizado quando

o relacionamento é obrigatório (incondicional).
Gabarito: E
67. (FCC - 8 – TRT/18 - Análise de Sistemas) Atividade, Caso de Uso e

Componente são diagramas da UML 2.0 classificados, respectivamente, no
âmbito:
a) comportamental, comportamental e comportamental.

b) comportamental, estrutural e estrutural.
c) comportamental, comportamental e estrutural.
d) estrutural, comportamental e estrutural.
e) estrutural, estrutural e comportamental.
Comentários:

16712855225
Composta e Pacotes.

Conforme vimos em aula, atividade é Comportamental, Casos de Uso é

comportamento e Componente é estrutural.

Gabarito: C
(FCC - 8 – TRT/18 - Análise de Sistemas) Na notação original da UML 2.0, os

símbolos + (mais) e # (jogo da velha), antecedendo as operações de uma classe,
caracterizam tais operações, respectivamente, como:
a) pública e protegida.
b) protegida e privada.
c) pública e privada.
d) pacote e protegida.
e) pública e pacote.
Comentários:

PÚBLICO + X X X X
PROTEGIDO # X X
UML
PACOTE ~ X X
PRIVADO – X
PÚBLICO + X X X X
PROTEGIDO # X X X
JAVA
DEFAULT ~ X X
PRIVADO - X
Conforme vimos em aula, o primeiro é público e o segundo, protegido.
16712855225
Gabarito: A
(FCC - 8 – TCE/AL - Análise de Sistemas) Os diagramas UML da categoria

comportamental são os de:
a) classes, objetos e componentes.

b) casos de uso, sequência e classes.
c) classes, atividades e sequência.
d) casos de uso, atividades e máquinas de estados.
e) objetos, estrutura composta e máquinas de estado.
Comentários:


Conforme vimos em aula, trata-se do caso de uso, atividades e máquina de estados.
Gabarito: D
70. (FCC - 8 – TRF/5 - Análise de Sistemas) Na UML 2.0, são dois diagramas
comportamentais:
a) Use Case e Package.

b) Sequence e Component.
c) State Machine e Communication.
d) Timing e Component.
Comentários:

Conforme vimos em aula, trata-se da máquina de estados e comunicação.

16712855225
Gabarito: C
71. (FCC - 8 – METRÔ/SP - Análise de Sistemas) Considere:
I. Farol ligado.
II. Comprar produto.
III. Máquina elétrica.
Os itens acima são representados em diagramas UML, respectivamente, como

a) estado, caso de uso e classe.

b) estado, classe e caso de uso.
c) caso de uso, estado e classe.
d) caso de uso, classe e estado.
e) classe, estado e caso de uso.
Comentários:
Essa é uma questão bacana! Farol ligado é um estado booleano (ligado/desligado),

logo pode ser representado por um Diagrama de Máquina de Estados. Comprar
um produto é uma funcionalidade, logo pode ser representada por um Diagrama
de Casos de Uso. Máquina Elétrica é um objeto ou uma classe, logo pode ser
representada por um Diagrama de Classes.
Gabarito: A
72. (FCC - 7 – TRT/4 - Análise de Sistemas) Na versão mais atual da UML, a "linha
de vida" de um objeto é representada no diagrama de:
a) Objetos.
b) Atividades.
c) Comunicação.
d) Máquina de Estados.
e) Seqüência.
Comentários:

16712855225
Gabarito: E

a) Objetos.
b) Atividades.
c) Comunicação.
e) Seqüência.
Comentários:

Gabarito: E
74. (FCC - – TRT/15 - Análise de Sistemas) A documentação de um caso de uso

costuma descrever, por meio de uma linguagem simples, informações sobre ele.
Na UML 2.0, essa documentação:
a) não possui um formato específico definido.

b) deve ser feita por meio de fluxogramas.
c) não pode ser feita por meio de outros diagramas.
d) costuma descrever apenas, em linhas gerais, a função do caso de uso
e) não costuma deixar claro quais atores interagem com os casos de uso.
Um caso de uso conta uma história sobre como o usuário final interage com o sistema
sob um conjunto de circunstâncias específicas. A história pode ser um texto narrativo,
uma descrição geral de tarefas ou interações, uma descrição baseada em gabaritos
ou uma representação esquemática. Independentemente de sua forma, um caso de
uso representa o software ou sistema do ponto de vista do usuário final.
Conforme vimos em aula, a documentação não possui uma forma específica – é

mais aberto! Muitos ficam em dúvida no quarto item, mas ele está errado porque
ele diz que deve descrever apenas a função do caso de uso.

Gabarito: A
75. (FCC - – TJ/PA - Análise de Sistemas) Considere o processo de negócio e o

diagrama abaixo.
É correto afirmar:
a) Trata-se de um diagrama de atividades da UML.

b) Não há relação entre o processo e o diagrama.
c) Um processo não pode ser modelado por um diagrama UML.
d) O processo pode ser modelado apenas por um diagrama de caso de uso da
UML.
e) Trata-se de um diagrama de classes da UML.
16712855225
Comentários:
(a) Correto, basta notar o estado inicial e final, as swimlanes, as ramificações, etc; (b)
Errado, há clara relação entre o processo e o diagrama; (c) Errado, tanto pode que
foi modelado por um diagrama de atividades; (d) Errado, tanto errado que foi
modelado por um diagrama de atividades; (e) Errado, trata-se de um diagrama de
atividades.
Gabarito: A

76. (FCC - – TJ/PA - Análise de Sistemas) Um analista judiciário do Tribunal de

Justiça do Amapá precisa utilizar um diagrama que permite adaptar o
metamodelo UML para diversas plataformas como Java EE ou .NET ou para
diferentes domínios como aplicações em tempo real e modelagem de processos
de negócio. Este diagrama precisa permitir a definição de estereótipos
customizados e restrições. Dentre os diagramas da UML 2.5, o que melhor
atende estas necessidades é o Diagrama de:
a) Perfil.
b) Deployment.
c) Estruturas Compostas.
d) Componentes.
e) Colaboração.
Comentários:

Conforme vimos em aula, a questão trata do Diagrama de Perfil.
Gabarito: A
(FCC - – TCE/GO - Análise de Sistemas) A UML especifica um conjunto de

diagramas para modelar sistemas orientados a objeto em suas várias
perspectivas. Dois destes diagramas podem ser muito úteis para apresentar uma
16712855225
visão de nível mais alto do sistema, como:
I. adequado para captar os requisitos funcionais de um sistema, ajudando no

entendimento destes requisitos.
II. suporta e estimula o comportamento paralelo, sendo útil para modelagem de
fluxo de trabalho e de processos, principal- mente, processos de negócio.
Os diagramas descritos em I e II são, correta e respectivamente, de
a) Casos de Uso e de Sequência.

b) Comunicação e de Atividades.

c) Componentes e de Sequência.
d) Casos de Uso e de Atividades.
e) Interação e de Distribuição.
Comentários:

Conforme vimos em aula, trata-se do Diagrama de Casos de Uso e de Atividades.
Gabarito: D
78. (FCC - – TRT/13 - Análise de Sistemas) Este diagrama da UML pode ser
usado para modelar processos de negócio. Suporta comportamento paralelo e
permite que, quem está seguindo o processo, escolha a ordem na qual fazer as
coisas. Em outras palavras, ele simplesmente determina as regras essenciais de
sequência que se deve seguir. São geralmente usados para mostrar o que
acontece, mas não quem faz o que, já que faz sentido se concentrar no que é
feito, em vez de em quem realiza quais partes do comportamento.
16712855225
O diagrama descrito é o diagrama de:
a) sequência.
b) atividades.
c) casos de uso.
d) comunicação.
e) distribuição.
Comentários:


Conforme vimos em aula, trata-se do Diagrama de Atividades. Bastava observar que

a questão fala em modelo de processos de negócio e que suporta comportamento
paralelo.
Gabarito: B
79. (FCC - – TRT/13 - Análise de Sistemas) Observando os processos em trâmite

no Tribunal, João observou que as situações pelas quais os processos passavam
poderiam ser classificadas em: "abrindo", "aberto", "em trâmite", "encerrando" e
"arquivado". Do ponto de vista da orientação a objetos ele percebeu que poderia
modelar mais adequadamente as condições ou situações da vida do objeto
processo utilizando, para representá-las, o diagrama UML denominado:
a) Interface.
b) Pacote.
c) Caso de uso.
d) Máquina de estados.
e) Classes.
Comentários:

estados possíveis de um objeto no decorrer da execução de processos de um sistema.
16712855225
Dessa forma, um objeto pode passar de um estado inicial para um estado final, por
meio de uma transição, quando ocorre algum evento ou estímulo interno ou externo
ao sistema.
Conforme vimos em aula, a questão trata do Diagrama de Máquina de Estados.

Bastava obversar que os processos passam por diversos estados.
Gabarito: D
(FCC - – AL/PE - Análise de Sistemas) Considere o diagrama UML para a

classe Conta ilustrado abaixo.

É correto afirmar:
a) A figura apresenta um diagrama de sequência, usado para representar o

comportamento dinâmico de uma classe. O diagrama de sequência pode ser
utilizado para ajudar a originar as sequências de testes que vão exercitar o
comportamento dinâmico da classe e daquelas classes que colaboram com ela.
b) As sequências iniciais movem-se entre os objetos Conta vazia e Conta

estabelecida. A maior parte dos comportamentos da classe ocorre enquanto se está
no objeto Conta ativa. Uma retirada final e fechamento da conta para a classe Conta
fazem com que se estabeleçam mensagens para os objetos Conta inativa e Conta
morta, respectivamente.
c) Os testes projetados devem cobrir apenas os objetos centrais do diagrama, quais

sejam, Conta estabelecida, Conta ativa e Conta inativa, já que Conta vazia e Conta
morta não contêm dados a serem validados.
d) O modelo de estados pode ser percorrido em forma de inclusão progressiva.

16712855225
Neste contexto, inclusão progressiva implica um caso de teste exercitar uma única
transição e, quando uma nova transição tiver de ser testada, são usadas apenas
aquelas previamente testadas.
e) O caso de teste: Abrir • EstabelecerConta • FazerDepósito(inicial) •

FazerRetirada(final) • Fechar é denominado sequência máxima de teste e a este caso
de teste não podem ser acrescentadas outras sequências de teste.
Comentários:

(a) Errado, a figura representa um diagrama de máquina de estados; (b) Errado,

Conta Vazia e Conta Estabelecida são estados e, não, objetos; (c) Errado, eles
contêm dados a serem validados e os testes devem cobrir todos os estados; (d)
Correto, esse é o contexto exato de inclusão progressiva; (e) Errado, podem ser
acrescentados Retirar, Depositar, Saldo/Crédito/Informação da Conta.
Gabarito: D
81. (FCC - – AL/PE - Análise de Sistemas) Considere o diagrama da UML 2.0:
Trata-se de um diagrama de I e nele podem ser identificados II , III e IV. As lacunas

de I a IV são correta e respectivamente preenchidas por:
a) interfaces - componentes - relacionamentos de realização - conexões

b) implantação - elementos de hardware - nós - vias de comunicação
c) instalação - elementos de infraestrutura - nós - estereótipos de nós
d) modelagem cliente/servidor - servidor - clientes - interfaces de banco de dados
e) componentes - interfaces - componentes - relacionamentos de dependência
16712855225
Comentários:


Conforme vimos em aula, trata-se de um Diagrama de Componentes! Estão vendo

a bolinha? É a interface! Estão vendo os retângulos com um símbolo no canto superior
direito? São os componentes! Estão vendo a seta tracejada? É uma dependência.
Gabarito: E
(FCC - – TRT/13 - Análise de Sistemas) Marcelo trabalha como Analista

Legislativo na Assembleia Legislativa do Estado de Pernambuco e recebeu a
tarefa de elaborar um diagrama da UML 2.0 que seja capaz de modelar o que
pode ocorrer em partes de um sistema orientado a objetos, como: fluxos de
controle e de dados, situações de decisão em que haja uma entrada e diversas
saídas, diferentes ações que podem ser executadas por objetos ou entidades
quando um método for executado, como um conjunto de ações relacionadas
pode ser executado e como afetará objetos ao redor, situações em que mais de
uma atividade pode acontecer ao mesmo tempo.
Marcelo optou por usar o diagrama de:
a) Classes.
b) Atividades.
c) Colaboração.
d) Objetos.
e) Casos de Uso.
Comentários:

16712855225

Conforme vimos em aula, trata-se do Diagrama de Atividades.
Gabarito: B
(FCC - – TRT/13 - Análise de Sistemas) Embora BPMN e UML tenham

abordagens diferentes em relação à modelagem de processos de negócios,
diagramas UML que modelam o comportamento dinâmico podem ser usados

na modelagem de alguns processos de negócio, como os diagramas de__I__ e

de___II___ .
As lacunas I e II são correta e respectivamente preenchidas com:
a) Classes - Objetos
b) Estados - Implantação
c) Componentes - Objetos
d) Casos de Uso - Atividades
e) Classes - Sequência
Comentários:

Diagramas Estruturais não modelam o comportamento dinâmico do sistema, logo

podemos eliminar os itens que contenham o Diagrama de Classes, Diagrama de
Objetos, Diagrama de Componentes e Diagrama de Implantação. Sobra apenas
uma opção: Casos de Uso e Atividades.
Gabarito: D
84. (FCC - – TRT/2 - Análise de Sistemas) UML é uma linguagem visual para
modelagem de sistemas orientados a objeto. Considere o diagrama UML:
16712855225

Uma primitiva importante dos diagramas de ..I... é a troca de mensagem, como na

figura acima, que ilustra a troca de mensagens entre objetos e entre atores e
objetos. Estas mensagens, utilizadas para indicar interação ou comunicação, podem
ter diferentes significados:
- Chamada: significa que um objeto está solicitando a execução de ...II.... de um

outro objeto. Para isso, é necessário que ele seja declarado como público ..III......
correspondente.
- Ocorrência de Evento: um evento é algum acontecimento externo ao software,

mas que é a ele notificado, pois lhe diz respeito. Exemplos são as saídas para
dispositivos (como disco ou monitor) feitos através de serviços do sistema
operacional. Esta é a forma padrão de interação entre ...IV..... .
As lacunas I, II, III e IV são, correta e respectivamente, preenchidas em:
a) sequência - um método - na classe - objetos e atores.

b) atividades - um procedimento - no método - classes e objetos.
c) objetos - uma mensagem - no método - objetos e métodos.
d) sequência - um método - no método construtor - classes e métodos.
e) atividades - uma classe - na superclasse - objetos e atores.
Comentários:

mensagens que são trocadas dentro de caso de uso. Ele modela a interação entre os
objetos, permitindo a visualização da execução de um ponto específico da aplicação,
16712855225
com ênfase na ordem temporal.
Conforme vimos em aula, trata-se do Diagrama de Sequência (vejam as Linhas de

Vida). A chamada é a solicitação de execução de um método, sendo público na
classe correspondente. Atores e objetos interagem por meio de eventos.
Gabarito: A
(FCC - – SABESP - Análise de Sistemas) Considere a imagem abaixo:

Na UML 2.0, o conceito de modelagem de classes que pode ser observado na

imagem é:
a) Herança.
b) Propagação.
c) Agregação.
d) Composição.
e) Associação Simples.
Comentários:

relacionado às suas partes de forma independente. Nesse tipo de relacionamento,
as partes têm existência própria. Portanto, elas existem por si só, isto é, a parte
existe sem o todo. É representado por uma linha com um diamante vazio na
Conforme vimos em aula, trata-se da Agregação. Vejam o diamante vazio (se fosse
cheio, seria Composição).
Gabarito: C
16712855225
(FCC - – TRT/13 - Análise de Sistemas) Em um diagrama de sequência UML

2.0, o símbolo utilizado para denotar uma mensagem perdida é:
a)
b)
c)
d)
e)
Comentários:

(a) Errado, isso é uma Mensagem Achada e representa uma mensagem localizada
– é um ponto na origem da mensagem, indicando uma mensagem localizada com
um remetente desconhecido; (b) Errado, essa não é uma notação existente; (c)
Errado, essa não é uma notação existente; (d) Correto, isso é uma Mensagem
Achada – é um ponto na extremidade da ponta da seta para indicar que o destino
é desconhecido; (e) Errado, essa não é uma notação existente.
Gabarito: B
87. (FCC - – TRT/9 - Análise de Sistemas) Nos diagramas de classe da UML, o

termo visibilidade refere-se à capacidade de um método de referenciar uma
característica de outra classe. Sobre os valores possíveis para definir a visibilidade
das características de uma classe,
a) apenas métodos da classe que contém o modificador private e de classes

contidas no mesmo pacote podem acessar características privadas. O caractere
“-” precede as características privadas.
b) os métodos das classes definidas no mesmo pacote da classe em questão

podem acessar as características dessa classe definidas como pacote. O caractere
“§” precede as características de pacote.
c) qualquer método pode acessar livremente as características públicas, exceto

métodos de classes envolvidas em relações de herança ou implementação de
interface. O caractere “+” precede características públicas.
d) apenas métodos presentes no mesmo pacote ou em classes que possuem

relação de herança ou implementação de interface podem acessar características
default. O caractere “*” precede características default.
16712855225
e) somente os métodos da classe que contém o modificador protected e seus

descendentes via herança podem acessar características protegidas (em Java
características protegidas também possuem acessibilidade de pacote). O
caractere “#” precede as características protegidas.
Comentários:

PÚBLICO + X X X X
UML
PROTEGIDO # X X

PACOTE ~ X X
PRIVADO – X
PÚBLICO + X X X X
PROTEGIDO # X X X
JAVA
DEFAULT ~ X X
PRIVADO - X
(a) Errado, métodos de classes contidas no mesmo pacote não podem visualizar; (b)
Errado, o caractere “~” precede as características de pacote; (c) Errado, não há essa
exceção; (d) Errado, default é o modificador do Java e o caractere é “~”; (e) Correto,
basta olhar a tabela.
Gabarito: E
(FCC - – MPE/MA - Análise de Sistemas) Em UML, casos de uso mais

complexos podem ser construídos de partes menores por meio de relações.
Analise as descrições destas relações.
I. Incorpora um caso de uso dentro da sequência de comportamento de outro

caso de uso. A notação UML 2 para esta relação é uma seta tracejada indo do
caso de uso origem para o caso de uso destino com o nome da relação indicado
na seta entre << >>.
II. Nesta relação um caso de uso pai tem o comportamento comum e os casos
de uso filhos acrescentam variações a ele. A UML 2 indica esta relação por uma
seta de traço contínuo partindo do caso de uso filho com a ponta triangular
chegando ao caso de uso pai. 16712855225
III. Acrescenta comportamento incremental a um caso de uso. Representa a

situação em que alguma capacidade inicial é definida e mais tarde recursos são
acrescentados. A notação UML 2 para esta relação é uma seta tracejada do caso
de uso estendido até o caso de uso básico com o nome da relação indicado na
seta entre << >>.
As relações I, II e III são correta e respectivamente definidas como:
a) generalização - especialização - extensão.

b) private - public - protected.

c) include - generalização - extend.

d) derived - generalization - added.
e) extend - generalização - include.
Comentários:

repete em mais de um caso de uso. A imagem abaixo apresenta o domínio de um
internet banking. Observem que, para realizar um pagamento ou visualizar o
saldo, é obrigatório que fazer Login. Logo, é um relacionamento obrigatório,
representado por uma linha tracejada com uma seta na ponta.
 Relacionamento de Extensão: utilizado quando se deseja modelar um

relacionamento alternativo. A imagem abaixo apresenta o contexto de um fórum
de discussões. Observem que para cadastrar um usuário, há duas opções:
moderador ou administrador. Logo, é um relacionamento opcional, representado
por uma linha tracejada com uma seta na ponta.
 Relacionamento de Herança: relacionamento entre atores, utilizado quando o ator

filho é um uma especificação do ator genérico. É bastante útil para definir
um triângulo no ator genérico. Na imagem abaixo, Vendedor é especialização de
Pessoa. É representado por uma linha com um triângulo.
(I) Observem que a questão fala em incorporação de um caso de uso dentro da

sequência de comportamento de outro caso de uso, logo é um relacionamento de
inclusão; (II) Observem que a questão fala em um relacionamento pai/filho, logo
trata-se de generalização/especialização (herança); (III) Observem que a questão
fala em acrescentar um comportamento incremental. Além disso, diz que a notação
16712855225
é do caso de uso estendido até o caso de uso básico, então é um relacionamento

de extensão.
Gabarito: C
(FCC - – TRF/2 - Análise de Sistemas) Atributos estáticos são atributos da

classe em vez de serem atributos de uma instância da classe. Em UML um
atributo estático é representado ao se utilizar em sua transcrição o:
a) modo sublinhado
b) símbolo #

c) símbolo /
d) modo itálico
e) símbolo ~
Comentários:

nome sublinhado!
Conforme vimos em aula, deve-se sublinhar o nome do atributo.
Gabarito: A
(FCC - – TJ/PE - Análise de Sistemas) É empregado para a modelagem dos

aspectos físicos de um sistema OO. Mostra a configuração dos nós de
processamento em tempo de execução e os artefatos que nele existem. Trata-
se do diagrama de:
a) sequência.
b) atividades.
c) implantação.
d) pacotes.
e) comunicação.
Comentários:
16712855225
O Diagrama de Implantação apresenta o layout físico de um sistema, revelando quais

partes do software são executadas em quais partes do hardware. Também conhecido
como Diagrama de Instalação ou também Diagrama de Distribuição, pode
representar toda a estrutura de hardware e requisitos mínimos onde o sistema será
de fato executado.
Conforme vimos em aula, trata-se do Diagrama de Implantação.
Gabarito: C
91. (FCC - – TRE/AP - Análise de Sistemas) São diagramas de interação os de

a) componentes e de implantação.
b) sequência e de máquina de estados.
c) comunicação e de sequência.
d) atividades e de implantação.
e) interação e de componentes.
Comentários:

Conforme vimos em aula, são comunicação e sequência.
Gabarito: C
(FCC - – TRE/RN - Análise de Sistemas) Na modelagem de Caso de Uso,

<<include>> e <<extend>> são relacionamentos de:
a) dependência.
b) agregação.
c) especialização.
d) atores entre si.
e) atores com os casos de uso.
IMPORTANTE
Observem que o Relacionamento de Dependência é representado por uma seta tracejada

que aponta para classe independente. Em outras palavras, a Classe Pedido depende da
Classe Item. Os relacionamentos <include> e <extend> também são relacionamentos de
dependência.
Conforme vimos em aula, são relacionamentos de dependência. Bastava lembrar da

notação – o relacionamento de dependência utilizar uma seta tracejada.

Gabarito: A
(FCC - – TRE/RN - Análise de Sistemas) Um relacionamento semântico entre

classificadores, no qual um deles especifica um contrato cujo cumprimento é
assegurado pelo outro. Na UML, trata-se de:
a) herança múltipla.
b) realização.
c) multiplicidade.
d) composição.
e) visibilidade.
Comentários:
Relacionamento de Realização: relacionamento entre dois elementos em que um

elemento realiza (implementa/executa) o comportamento que o outro elemento
especifica. Costuma-se dizer que um dos elementos especifica um contrato e o outro
elemento realiza esse contrato. A imagem abaixo mostra a Classe Marcelo, que
realiza uma Interface Pessoa.
Conforme vimos em aula, trata-se do relacionamento de realização.
Gabarito: B
94. (FCC - – TRE/RN - Análise de Sistemas) Por um mecanismo de ampliação

de seu vocabulário, a UML permite que sejam criados novos blocos de
construção derivados dos já existentes, todavia específicos a determinados
problemas. Esse mecanismo é definido como:
16712855225
a) persistência.
b) derivação.
c) polimorfismo.
d) estereótipo.
e) operação.
Comentários:
Estereótipos permitem adaptar ou personalizar modelos com construções específicas

para um domínio, plataforma ou método de desenvolvimento particular. Trocando

em miúdos, é um mecanismo de extensão que dá mais poder e flexibilidade à UML.

Podemos ter estereótipos de dois tipos: predefinidos pela linguagem ou definidos pela
equipe de desenvolvimento. Como assim, professor?

desenvolvimento pode criar seus próprios estereótipos! Como? Basta colocar o nome
do elemento delimitado pelos símbolos << e >>. Além disso, os estereótipos podem
ser definidos textualmente ou graficamente.
Conforme vimos em aula, trata-se de estereótipos.
Gabarito: D
(FCC - – TRT/8 - Análise de Sistemas) Para demonstrar elementos

estruturais e comportamentais de um sistema, a UML pode utilizar,
respectivamente, os diagramas de:
a) Atividade e de Sequência.
b) Caso de Uso e de Comunicação.
c) Sequência e de Objeto.
d) Classe e de Pacote.
e) Pacote e de Atividade.
mentários:

16712855225

Composta e Pacotes.

Conforme vimos em aula, a única opção que mostra respectivamente um diagrama

estrutural e um comportamento é: Pacote e Atividade.

Gabarito: E
(FCC - – TRE/RS - Análise de Sistemas) Um dos mais importantes detalhes

que se pode especificar para os atributos e operações de uma classe é a sua
visibilidade. Na UML, os níveis de visibilidade podem ser representados pelos
símbolos:
a) + (público), - (privado), # (pacote), ~ (protegido).

b) + (privado), - (público), # (pacote), ~ (protegido).
c) + (público), - (privado) e # (protegido), somente.
d) + (público) e - (privado), somente.
e) + (público), - (privado), # (protegido), ~ (pacote).
mentários:

PÚBLICO + X X X X
PROTEGIDO # X X
UML
PACOTE ~ X X
PRIVADO – X
PÚBLICO + X X X X
PROTEGIDO # X X X
JAVA
DEFAULT ~ X X
PRIVADO - X
Conforme vimos em aula, + (público), - (privado), # (protegido) e ~ (pacote).

16712855225
Gabarito: E
97. (FCC - – MPE/RN - Análise de Sistemas) Caso particular de associação

binária utilizado para expressar um relacionamento todo-parte. Entretanto, a
parte pode não ser exclusiva de um único todo. No diagrama de classes é uma:
a) Generalização.
b) Composição.
c) Estereotipagem.
d) Agregação.

e) Dependência.
mentários:

relacionado às suas partes de forma independente. Nesse tipo de relacionamento,
as partes têm existência própria. Portanto, elas existem por si só, isto é, a parte
existe sem o todo. É representado por uma linha com um diamante vazio na
Conforme vimos em aula, se a parte não é exclusiva de um único todo, ela tem
existência própria – logo é uma agregação.
Gabarito: D
(FCC - – TRT/14 - Análise de Sistemas) Um relacionamento todo-parte onde

o todo controla a vida das partes; todavia as partes podem ser removidas explici-
tamente antes da morte do todo. Trata-se de:
a) particionamento.
b) abstração.
c) enumeração.
e) agregação por composição.
mentários:

16712855225
referente ao todo.
Conforme vimos em aula, se a parte não é exclusiva de um único todo, ela tem
existência própria – logo é uma agregação.
Gabarito: E
(FCC - – TRT/20 - Análise de Sistemas) Na UML, o diagrama que serve para

organizar o comportamento do sistema é o diagrama de:

a) sequência.
b) estados.
c) caso de uso.
d) classes.
e) objetos.
mentários:
Caso haja alguma falha em um dos passos, cria-se outro cenário. De todo modo,
Diagrama de Casos de Uso descreve um conjunto de funcionalidades do sistema e
interações com elementos externos e entre si. Os Atores são os elementos externos
que interagem com o sistema e são representados por um boneco (Stickman). Nas
imagens abaixo, temos dois Diagramas de Casos de Uso (Sistema e Negócio):
Gabarito: C
100. (FCC – 10 – AL/SP - Análise de Sistemas) Um relacionamento estendido

entre dois casos de uso é um relacionamento de:
a) associação.
b) composição.
c) generalização.
d) estado.
e) dependência.
IMPORTANTE
Observem que o Relacionamento de Dependência é representado por uma seta tracejada

que aponta para classe independente. Em outras palavras, a Classe Pedido depende da
Classe Item. Os relacionamentos <include> e <extend> também são relacionamentos de
dependência.
Conforme vimos em aula, são relacionamentos de dependência.

Gabarito: E
ACERTEI ERREI
16712855225

(FGV - – MEC – Análise de Sistema A UML define em sua versão 2.0, treze
tipos de diagramas, divididos em duas categorias: diagramas estruturais e
diagramas dinâmicos.
Assinale a alternativa que não indique um diagrama estrutural da UML.
a) Diagrama de Visão Geral.

b) Diagrama de Implantação.
c) Diagrama de Pacotes.
d) Diagrama de Classes.
e) Diagrama de Objetos.
Comentários:
Lembrando que na UML 2.4.1, temos 14 diagramas! O Diagrama de Visão Geral (ou
Interação Geral) é um diagrama comportamental!
Gabarito: A
(CESGRANRIO - 2010 – PETROBRÁS - Analista de Sistemas – B) O diagrama de

pacotes enfatiza a apresentação das classes do ambiente modelado, de acordo
com um conjunto de eventos.
Comentários:
Não! O Diagrama de Pacotes não enfatiza nada disso...
Gabarito: E
16712855225
(CESGRANRIO - 2010 – PETROBRÁS – Análise de Sistemas – C) O diagrama de

implantação é usado para sistemas distribuídos e permite apresentar a topologia
de uma rede de máquinas e qual processo cada máquina vai rodar.
Comentários:
Gabarito: C

(CESGRANRIO - 2010 - Petrobrás - Analista de Sistemas Júnior - Engenharia de

Software - A) O diagrama de estrutura composta serve para ilustrar a arquitetura
de um sistema, mostrando o agrupamento de suas classes.
Comentários:
Na verdade, essa é a função do Diagrama de Pacotes.
Gabarito: E
(CESGRANRIO - 2013 – LIQUIGÁS – Analista de Sistemas) Seja o seguinte

diagrama UML 2:
Que tipo de diagrama é esse?
a) Diagrama de objetos
b) Diagrama de tempo
c) Diagrama de estados
d) Diagrama de comunicação 16712855225
e) Diagrama de colaboração
Comentários:
Bem... tá meio feio! Não está seguindo todas as regras, mas se trata de um Diagrama
de Comunicação.
Gabarito: D
(ESAF - – BACEN – Analista de Sistemas) A UML inclui diagramas de

interação para ilustrar como os objetos interagem por meio de mensagens. Os

diagramas de interação constituem uma generalização de dois tipos de

diagramas especializados na UML: Diagrama de Seqüência e Diagrama de
Comunicação.
Assinale a sentença que se refere exclusivamente a um Diagrama de

Comunicação.
a) Cada mensagem entre objetos é representada com uma expressão de

mensagem em linha sólida, com seta cheia, entres as linhas de vida verticais.
b) A notação UML para chamadas assíncronas é uma mensagem com seta
traçada.
c) Os participantes da linha da vida devem representar um objeto, não uma
coleção.
d) A ordem das mensagens é ilustrada com números de seqüência.
e) A barra de especificação de execução indica o foco de controle.
Comentários:
(a) Linha de Vida é exclusividade do Diagrama de Sequência; (b) Notação para

chamadas assíncronas se referem exclusivamente ao Diagrama de Sequência; Linha
de Vida novamente é exclusividade do Diagrama de Sequência; (d) Perfeito, a ordem
das mensagens é ilustrada com números de sequência; (e) Barra de Especificação é
exclusiva do Diagrama de Sequência.
Gabarito: D
(PUC/PR - 2010 – URBS – Analista de Sistemas - I) A Unified Modeling Language

(UML) é uma linguagem de programação orientada a objetos.
16712855225
Comentários:
UML é uma linguagem de modelagem visual e, não, de programação.
Gabarito: E
(ESAF - 2010 – SUSEP – Analista de Sistemas O Diagrama de Estado mostra:
a) os estados expressos que os objetos de uma dada classe podem assumir e as

transformações entre pares de classes

b) os estados admissíveis que os atributos de uma dada classe podem modificar

e os pares de estados mais relevantes.
c) os estados de atualização que os objetos de qualquer classe podem assumir

e as transições permitidas entre instâncias.
d) os estados admissíveis que os objetos de uma dada classe podem assumir e

as transições permitidas entre pares de estados.
e) os estados coerentes com os objetos priorizados e as restrições de transições

entre pares de estados.
Comentários:
Conforme vimos em aula, ele mostra os estados admissíveis que os objetos de uma
dada classe podem assumir e as transições permitidas entre pares de estados.
Gabarito: D
(ESAF - 2012 – CGU – Analista de Sistemas Para indicar a visibilidade da

propriedade, a UML:
a) incorpora um prefixo a um nome de atributo ou nome de operação.
b) incorpora um sufixo a um nome de atributo ou origem de operação.
c) gera um nome de atributo e nome de transação totalmente distinto do

anterior. 16712855225
d) duplica nome de atributo ou nome de operação.
e) sublinha o nome de atributo ou nome de operação.
Comentários:
A UML incorpora um prefixo (+, -, ~, #) a um nome de atributo ou nome de

operação (método).
Gabarito: A

10. (ESAF - 2010 – MPOG – Analista de Sistemas Na UML – Unified Modelling

Language:
a) um atributo representa operações entre objetos.

b) um atributo representa informações sobre um objeto.
c) um atributo possui várias classes.
d) não existem atributos não numéricos.
e) atributos são classes abstratas.
Comentários:
Um atributo representa informações (dados) sobre um objeto – trata-se do estado

de um objeto.
Gabarito: B
11. (ESAF - 2012 – CGU – Analista de Sistemas Uma associação em UML representa:
a) uma população variada de relações (engagements) de redundâncias entre

instâncias de classe.
b) uma população variada de vínculos (links) de relacionamentos entre instâncias

de classe.
c) uma classificação de vínculos (links) de relacionamentos entre classes de

atributos.
d) uma população constante de valores (values) de relacionamentos

16712855225
quantitativos entre atributos de instâncias.
e) uma estrutura de equivalências (equal features) entre relacionamentos de

instâncias de posicionamento de classes.
Comentários:
Conforme vimos em aula, uma associação é um relacionamento estrutural entre

objetos e especifica os objetos de uma classe que estão ligados a objetos de outra
classe. Em outras palavras, uma população variada de vínculos (links) de
relacionamentos entre instâncias de classes (objetos).

Gabarito: B
12. (ESAF - 2012 – CGU – Analista de Sistemas Quanto ao uso de diagramas na UML
para a modelagem de objetos é correto afirmar que o Diagrama de Seqüência:
a) descreve a funcionalidade do sistema percebida por atores externos.
b) apresenta a interação de seqüência de tempo dos objetos que participam na

interação.
c) apresenta a interação de seqüência de atores que participam na interação.
d) descreve a funcionalidade do sistema percebida por atores internos.
e) apresenta a interação de seqüência estática de pacotes, relacionamentos e

instâncias.
Comentários:

mensagens que são trocadas dentro de caso de uso. Ele modela a interação entre os
objetos, permitindo a visualização da execução de um ponto específico da aplicação,
com ênfase na ordem temporal.
Conforme vimos em aula, ele apresenta a interação de sequência de tempo dos

objetos que participam na interação.
16712855225
Gabarito: B
13. (FGV – – Senado Federal – Analista de Sistemas) Considere o caso de uso

ilustrado na figura utilizando a notação UML.
A descrição do cenário que melhor descreve esse caso de uso é:

a) o atendente verifica o histórico dos pacientes que possuem consultas

agendadas.
b) um paciente liga para a clínica para marcar uma consulta. A atendente verifica
o histórico do paciente, busca um horário vazio e agenda a consulta.
c) o atendente inclui os pacientes que têm consulta agendada e não possuem

um histórico de atendimento.
d) o paciente liga para a clínica para agendar uma consulta e para alterar o seu
histórico.
e) o atendente não marca consultas para pacientes que não tenham histórico na
clínica.
Comentários:
A descrição que faz mais sentido é que um paciente liga para a clínica para marcar
uma consulta. A atendente verifica o histórico do paciente, busca um horário vazio
e agenda a consulta. Observem que há um relacionamento de inclusão (lembrem-
se que ele é obrigatório), ou seja, deve-se verificar o histórico do paciente.
Gabarito: B
14. (FGV – – Senado Federal – Analista de Sistemas) Uma série de modelos

pode ser produzida durante um projeto orientado a objetos. O projeto inclui
modelos estáticos e dinâmicos.
16712855225
Um modelo que é considerado dinâmico é o de:
a) seqüência.
b) classe.
c) associação.
d) contexto.
e) generalização.
Comentários:

O que a questão chama de modelos são os diagramas! O único diagrama dinâmico

da questão é o Diagrama de Sequência.
Gabarito: A
15. (FGV – 2015 – ANA – Analista de Sistemas) João está preparando uma palestra
sobre diagramas de classe da UML, e criou um slide com a figura:
O título correto para esse slide deve ser “Relacionamento de”:
a) agregação;
b) correspondência;
c) dependência;
d) especialização;
e) generalização.
Comentários:
Diamante Cheio é Composição. E o diamante vazio? Agregação!
Gabarito: A
16. (FGV – 2015 – AL – Analista de Sistemas) Linguagens gráficas de modelagem são

úteis para descrever e especificar sistemas computacionais porque oferecem
notações próprias para representar conceitos e características estruturais e
comportamentais do projeto de software.
16712855225
Assinale a opção que indica o diagrama da UML recomendado para modelar

característica comportamental com ênfase nos vínculos entre os vários objetos
de um projeto de software.
a) Diagrama de objetos.
b) Diagrama de componentes.
c) Diagrama de implantação.
d) Diagrama de comunicação.
e) Diagrama de classes.

Comentários:
Todos os diagramas são estruturais, exceto: Diagrama de Comunicação.
Gabarito: D
17. (FGV – 2015 – TJ/RO – Analista de Sistemas) O diagrama da UML mais adequado
para representar o comportamento de vários objetos dentro de um único caso
de uso, de modo a evidenciar como esses objetos colaboram em algum
comportamento ao longo do tempo, é o diagrama de:
a) estruturas compostas;
b) objetos;
c) componentes;
d) tempo;
e) sequência.
Comentários:
Todos os diagramas são comportamentais, exceto: Diagrama de Tempo e

Sequência. Não confundam: o diagrama de tempo exibe o tempo da execução de
software e, não, como os objetos colaboram ao longo do tempo; e o diagrama de
sequência, sim, exibe o comportamento dos objetos.
Gabarito: E
18. (FGV – 2015 – Fiscal de Niterói – Analista de Sistemas) A UML (Unified Modeling
Language) estabelece uma série de artefatos que auxiliam desenvolvedores de
sistemas a modelar e documentar seu trabalho. A funcionalidade de um sistema,
16712855225
do ponto de vista dos seus usuários, é representada pelo Diagrama de:
a) atividade;
b) casos de uso;
c) classes;
d) estado;
e) sequência.
Comentários:

Galera, a questão fala de funcionalidade de um sistema, logo trata-se do diagrama

de casos de uso.
Gabarito: B
19. (FGV - 2015 – PGE/RO - Análise de Sistemas) NÃO é um diagrama utilizado pela
UML 2.0:
a) Diagrama de casos de uso.

b) Diagrama de classes.
c) Diagrama de objetos.
d) Diagrama de blocos múltiplos.
e) Diagrama de sequência.
Comentários:
16712855225
Conforme vimos em aula, não existe esse Diagrama de Blocos Múltiplos.
Gabarito: D
(FGV - – MEC - Análise de Sistemas) Na UML o diagrama que descreve
uma sequência de ações que representam um cenário principal e cenários

alternativos, com o objetivo de demonstrar o comportamento de um sistema,

por meio de interações com atores, é o diagrama de:
b) Caso de Uso.
c) Implantação.
d) Atividades.
e) Pacotes.
Comentários:
Galera, falou em cenário principal/secundário e em comportamento do sistema só

opode estar falando sobre o diagrama de... casos de uso!
Gabarito: B
21. (FGV - 2009 – MEC - Análise de Sistemas) A UML (Unified Modeling Language)
possui vários tipos de diagramas que em conjunto são utilizados para descrever
a visão estática e dinâmica de um sistema. Assinale a alternativa em que todos
os diagramas listados descrevem uma visão dinâmica de um sistema.
a) Classes, Objetos, Implantação e Pacotes.

b) Classes, Objetos, Casos de Uso e Sequência.
c) Implantação, Pacotes, Sequência e Atividades.
d) Implantação, Pacotes, Casos de Uso e Atividades.
e) Casos de Uso, Sequência, Visão Geral e Atividades.
16712855225
Comentários:

Conforme vimos em aula, os diagramas comportamentais tratam da visão dinâmica

de um sistema, portanto Diagramas de Casos de Uso, Sequência, Visão Geral
(interação geral) e Atividades.
Gabarito: B
ACERTEI ERREI
16712855225

LISTA DE EXERCÍCIOS COMENTADOS (CESPE)

UNIFIED MODELING LANGUAGE (UML)
(CESPE - 2010 - DETRAN-ES - Analista de Sistemas) O uso da linguagem de

modelagem unificada, conhecida como UML, é recomendado para a análise
orientada a objetos, mas não para o projeto orientado a objetos, que deve ser
realizado por meio do suporte de linguagens de programação orientadas a
objetos.
(CESPE - 2010 - TCU - Auditor Federal de Controle Externo - Tecnologia da

Informação - Parte II) UML (Unified Modeling Language) é uma tecnologia
concorrente com o processo unificado, no que diz respeito ao apoio à prática
de engenharia de software orientada a objetos.
(CESPE - - ANAC - Técnico Administrativo - Informática) Geradores de

código em ferramentas CASE (Computer Aided Software Engineering) podem
ser embasados em modelos UML. Nesse caso, o gerador pode gerar um
programa ou componente completo ou um esqueleto de código.
(CESPE - 2011 - TRE-ES - Programação de Sistemas) RUP e UML são

interdependentes, isto é, não há como se aplicar o RUP no desenvolvimento de
um sistema se não se utilizar o UML.

UML é um método para desenvolvimento de software que foi proposto para ser
aplicado à análise e projeto de software orientados a objetos.

16712855225
UML (Universal Modeling Language) é uma linguagem de modelagem

proprietária que pode ser utilizada no desenvolvimento de sistemas de maneira
intuitiva para visualização de objetos.
(CESPE - 2009 – INPI – Analista de Sistemas - V) Diagramas UML podem enfatizar

aspectos comportamentais e estruturais de sistemas de informação, como
diagramas de atividade (activity) e de classe (class), respectivamente.
(CESPE - – MPE/AM – Analista de Sistemas) Na abordagem de análise UML

(unified modelling language), a visão de modelo comportamental representa o

sistema do ponto de vista dos comportamentos e interações do sistema com o

usuário.
(CESPE - 2011 – PC/PA – Analista de Sistemas) Similarmente ao diagrama de

classes, os diagramas UML de casos de uso e de estados (statechart) são usados
para representar aspectos estruturais de um sistema, conforme preconiza o
processo unificado.
10. (CESPE - – PM/RB – Analista de Sistemas) UML foi desenvolvida

especificamente para o desenvolvimento de software, não sendo possível a sua
utilização por outros sistemas ou áreas diferentes da tecnologia da informação.
11. (CESPE – – SAD/PE – Analista de Sistemas – D) Na especificação da UML

2.0, destaca-se a existência da sublinguagem OCL (Object Constraint Language),
linguagem imperativa que, com variáveis e comandos de controle de fluxo, é
usada para complementar diagramas UML.
12. (CESPE - 2009 - ANAC - Analista Administrativo - Tecnologia da Informação) A

UML - Unified Modeling Language é um conjunto de especificações do OMG -
Object Management Group. O conjunto completo da UML, em sua versão 2.0,
está distribuída em três especificações: a Especificação de Intercâmbio de
Diagramas, a Infraestrutura UML, e a Linguagem de Restrição de Objeto - OCL.
A Especificação de Intercâmbio de Diagramas possibilita o compartilhamento de
modelos entre diferentes ferramentas de modelagem. A infraestrutura define os
conceitos fundamentais, sendo considerada um metamodelo, é utilizada para
construir as demais especificações da UML. Por isto a infraestrutura UML é
tipicamente utilizada pelo usuário final.
13. (CESPE - 2011 - -ES - Técnico de Informática - Específicos) A linguagem de

16712855225
restrição de objetos, ou OCL, é utilizada para especificar restrições existentes em

um modelo UML de sistema que esteja sendo projetado, como é o caso das
precondições e pós-condições.
14. (CESPE - – UNIPAMPA/RS – Análise de Sistemas) Na UML 2.0, a OCL (object

constraint language) é uma linguagem formal usada para descrever restrições
em modelos UML, podendo ser também utilizada em classificadores.
15. (CESPE - – CENSIPAM – Análise de Sistemas) A UML (unified modeling

language) define uma metodologia orientada a objetos para a análise de
sistemas e processos.

16. (CESPE - – CENSIPAM – Análise de Sistemas) Dentro da UML, existe uma

série de diagramas, entre os quais, citam-se: diagrama de fluxo de dados,
diagrama de objetos, casos de uso e outros.
17. (CESPE - 2013 – MPU – Análise de Sistemas) Diagrama de caso de uso, diagrama
de sequência, diagrama de comunicação, diagrama de atividades e diagrama de
classes são diagramas comportamentais da UML.
18. (CESPE - 2010 - Banco da Amazônia - 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.
19. (CESPE - 2010 - EMBASA - Analista de Saneamento - Analista de Tecnologia da

Informação – Desenvolvimento) Os diagramas em UML podem ser estáticos ou
dinâmicos. O diagrama de classes é um exemplo de um diagrama dinâmico.
(CESPE - - TCU - Analista de Controle Externo - Tecnologia da Informação

16712855225
- Prova 2) O método #Cadastrar( ) da classe Instrutor tem visibilidade do modo

protegido tal que somente a classe possuidora Instrutor pode utilizá-lo.

21. (CESPE - - TRT - 5ª Região (BA) - Analista Judiciário - Tecnologia da

Informação) No diagrama, Bicicleta e Veiculo_motor são tipos de veículos e,
dessa forma, têm relação de herança com veículo. É correto afirmar que veículo
é subclasse de Bicicleta e Veiculo_motor.
16712855225
(CESPE - 2010 - TRE-BA - Técnico Judiciário - Programação de Sistemas) Os

diagramas de classes podem conter pacotes ou subsistemas, utilizados para
agrupar elementos do modelo em um conjunto maior. No nível de visibilidade
privado, uma característica pode ser usada por qualquer descendente do
classificador; contudo, um classificador nem sempre é capaz de visualizar outro
classificador.


Desenvolvimento de Sistemas) O diagrama de classes define todas as classes de
que o sistema necessita e é a base para a construção dos diagramas de
sequência e comunicação.
24. (CESPE - 2011 – AL/ES - Análise de Sistemas - E) O diagrama de classes, além de

definir a estrutura das classes utilizadas pelo sistema, determinando os atributos
e métodos de cada classe, estabelece como as classes se relacionam e trocam
informações entre si.
(CESPE - – IGEPREV - Análise de Sistemas - E) A multiplicidade de um

diagrama de classes corresponde à quantidade total de relacionamentos
existentes nesse diagrama.
(CESPE - – MPE/AM - Análise de Sistemas) Na UML, uma relação de

generalização-especialização entre elementos de um sistema é representada
com um diagrama de representação da herança entre uma classe e suas
subclasses.
27. (CESPE - – MPE/AM - Análise de Sistemas) Na UML, uma agregação é um

relacionamento que estabelece que uma classe define objetos que são parte de
um objeto definido por outra classe.
(CESPE - – MPE/AM - Análise de Sistemas) Em um diagrama de classes

UML, uma associação entre classes pode ser documentada em termos da
multiplicidade da associação.
(CESPE - – PM/RB - Análise de Sistemas) As classes em um diagrama de

classes são compostas basicamente de três partes: um nome, atributos e
16712855225
operações.
(CESPE - – PM/RB - Análise de Sistemas) Em um diagrama de classes UML,

só é possível criar relacionamentos do tipo 1:1 porque uma classe apenas
implementa funções.
31. (CESPE - – PM/RB - Análise de Sistemas) A generalização é uma

funcionalidade de um diagrama de classes utilizada quando duas classes são
similares.

(CESPE - 2007 – PRB/AC - Análise de Sistemas) Multiplicidade refere-se à

definição de quantas classes podem participar em um relacionamento.
(CESPE - 2000 – TJDFT - Análise de Sistemas) Um diagrama de classes descreve

um conjunto de classes, interfaces e colaborações e suas relações. Esse diagrama
é capaz de descrever tanto o processo estático do sistema quanto o dinâmico,
em tempo de execução, sendo esse último estado também chamado de
diagrama de objetos.
34. (CESPE - 2010 – UNIPAMPA - Análise de Sistemas) O diagrama de objetos está

amplamente associado ao diagrama de classes, sendo que o primeiro consiste
em uma instância do segundo, em determinado momento da execução, ou seja,
um diagrama de objetos descreve os objetos, os métodos, os atributos e seus
valores, além dos vínculos entre os objetos, sendo ambos diagramas estruturais.

Desenvolvimento de Sistemas) O diagrama de componentes deve ser utilizado
para se representar a configuração e a arquitetura de um sistema no qual estarão
ligados todos os software e hardware, bem como sua interação com outros
elementos de suporte ao processamento.
(CESPE - 2007 – TRE/TO - Analista de Sistemas) Um diagrama de componentes

permite mostrar componentes de um sistema e as dependências entre eles. As
dependências entre os componentes podem ser, por exemplo, dependências de
compilação ou de comunicação.
37. (CESPE - 2013 - TRT - 10ª REGIÃO (DF e TO) - Analista Judiciário - Tecnologia da
Informação) O diagrama de implementação é um tipo de diagrama de
componente. 16712855225
(CESPE - - TCU - Analista de Sistemas) Na figura, um diagrama UML de

implantação é modelado juntamente com um diagrama de componentes,
ambos voltados para a modelagem de aspectos físicos e estáticos de sistemas
orientados a objetos.
(CESPE - - UNIPAMPA - Analista de Sistemas) Na UML 2.0, é possível, em

um único modelo, modelar os componentes de um software e descrever onde
eles são executados dentro de um nó, usando notação, respectivamente, do
diagrama de componentes e do diagrama de implantação, e, ainda, descrever

essa relação entre nós e componentes em subsistemas, utilizando a notação do

diagrama de pacotes. Todos esses diagramas são estruturais.
40. (CESPE - 2010 - INMETRO - Analista de Sistemas – D) Em um diagrama de

componentes em UML 2.0 contendo um conjunto de componentes que
modelam a arquitetura de uma aplicação web em três camadas, se três desses
conjuntos, nomeados por C1, C2 e C3, forem diretamente relacionados entre si
e representarem um componente, respectivamente, da camada de apresentação
de aplicação, da camada de negócios e da camada de persistência, então uma
relação direcional consistente que representa as dependências entre esses
conjuntos será: C3 depende de C2 e C2 depende de C3.
41. (CESPE - 2010 – TRE/MT - Analista de Sistemas – C) Um diagrama de

componentes é do tipo estrutural, e mostra partes internas, conectores e portas
que implementam um componente.
42. (CESPE - 2013 – FUB - Analista de Sistemas) Ao desenhar um diagrama de

componentes, exige-se que os componentes tenham a característica de serem
executáveis. Assim, somente as partes executáveis de um sistema estão presentes
em um diagrama de componente.
43. (CESPE - 2013 – SERPRO - Analista de Sistemas) Com a utilização do diagrama

de componentes da UML (unified modeling language) podem ser modelados os
processos de negócio da empresa.
44. (CESPE - 2013 – TRT/17 - Analista de Sistemas) Ao se analisar um software e

desenhar o diagrama de componentes, deve-se considerar a linguagem que será
utilizada para implementar o sistema, pois ela determina o modo como os
componentes interagirão para o sistema funcionar corretamente.
16712855225
45. (CESPE - 2013 – TRT/17 - Analista de Sistemas) Caso seja necessário implantar
um sistema em mais de um servidor, o diagrama de componentes determinará
as necessidades e as características físicas de implementação de acordo com a
UML.
46. (CESPE - 2010 - EMBASA - Analista de Tecnologia da Informação) O objetivo

principal de um diagrama de pacotes é agrupar os pacotes em classes. Esse tipo
de diagrama pode usar dependências.

47. (CESPE - 2011 – PC/PA - Analista de Sistemas – B) O uso de packages UML não
possui relação direta com o conceito de modularização em desenvolvimento de
sistemas.

pacotes, usado, por exemplo, para demonstrar a arquitetura de uma linguagem,
tem por objetivo representar os subsistemas englobados por um sistema, de
forma a determinar as partes que o compõem.
49. (CESPE - 2010 - ABIN - Oficial Técnico De Inteligência - Desenvolvimento e

Manutenção de Sistemas) Um diagrama de implantação pode ser utilizado
quando o software é projetado para ser executado sobre uma única máquina
individual que não se comunica com outro hardware. A modelagem em conjunto
com diagramas de componentes, como ilustrado na figura a seguir, não é
possível na UML.
(CESPE - 2010 – INMETRO – Análise de Sistemas – E) O diagrama de implantação

e o diagrama de classes pertencem ao modelo dinâmico.
16712855225
51. (CESPE - 2010 – TRE/MT – Análise de Sistemas – B) Exemplos de diagramas de

modelagem UML que expressam partes dinâmicas de um sistema são: diagrama
de caso de uso e diagrama de implantação.
(CESPE - 2011 – MEC – Análise de Sistemas) Em um diagrama de implantação

com componentes, é possível indicar o protocolo na ligação entre dois nós, bem
como mostrar relações de dependência entre componentes.
(CESPE - 2012 – MPE/PI – Análise de Sistemas) O diagrama de implantação da

UML é irrelevante para a representação de um sistema embutido, pois, nesse
processo, considera-se um único nó de hardware.

54. (CESPE - 2011 - EBC - Engenheiro de Software) Estereótipos são uma maneira de
destacar ou diferenciar um componente ou relacionamentos iguais, atribuindo-
lhes características especiais ou modificando-as de alguma forma.
(CESPE - 2011 – AL/ES - Análise de Sistemas - D) O diagrama de casos de uso é

utilizado para modelar colaborações e descrever a estrutura interna de um
classificador.
(CESPE - 2011 - EBC - Analista - Engenharia de Software) O diagrama de estrutura

composta é similar ao denominado diagrama de classes, porém este último
apresenta uma visão estática da estrutura de classes, enquanto o primeiro tenta
expressar arquiteturas de tempo de execução.
57. (CESPE - 2010 – UNIPAMPA - Analista de Sistemas) Na UML 2.0, o diagrama de

estrutura composta (composite structure diagram) descreve a estrutura interna
de um classificador modelando as colaborações, no qual uma colaboração
descreve uma visão de um conjunto de instâncias que cooperam entre si para
executar uma função específica entre instâncias de classes, objetos ou interfaces.
(CESPE – – MPE-RR – Analista de Sistemas) No diagrama UML ao lado, o

ator Presidente está relacionado ao caso de uso Criar projeto; o caso de uso
Informar dados contém comportamento comum a dois casos de uso; o caso de
uso Pagar projeto estende o comportamento Financiar projeto e Cancelar
projeto é abstrato.
16712855225
(CESPE – 2011 – Correios – Analista de Correios – Analista de Sistemas –

Desenvolvimento de Sistemas) Um relacionamento include de um caso de uso A
para um caso de uso B indica que B é essencial para o comportamento de A.
Então, ao se executar o caso de uso A, executa-se também o B.

(CESPE – 2011 – TER-ES – Técnico – Programação de Sistemas – Específicos) Os

modelos de casos de uso enfatizam os objetivos e as perspectivas do usuário,
demonstrando a visão de quem utiliza o sistema.
61. (CESPE – 2010 – TER-BA – Analista Judiciário – Análise de Sistemas) O propósito

maior de um caso de uso é fornecer uma descrição do comportamento do
sistema. Assim, em um processo de desenvolvimento orientado a objetos, os
objetivos de um caso de uso são: definir escopo, detalhar os processos e cálculos
do sistema, organizar e dividir o trabalho, estimar o tamanho do projeto e
direcionar os testes.
(CESPE – – SECONT-ES – Auditor do Estado – Tecnologia da Informação)

Casos de uso podem ser empregados para captar o comportamento de um
sistema ou de parte de um sistema. O comportamento do caso de uso pode ser
especificado pela descrição do fluxo de eventos de forma suficientemente clara
para que os seus usuários sejam capazes de compreendê-lo. Nesse fluxo, devem
ser incluídas definições relacionadas à forma de implementação, para que sejam
diretamente utilizadas pelos implementadores.
(CESPE – 2010 – EMBASA – Analista de Saneamento – Analista de Tecnologia da

Informação – Desenvolvimento) Um diagrama de casos de uso descreve um
cenário que mostra as funcionalidades do sistema do ponto de vista do usuário.
É comum o uso de atores nesse diagrama.

16712855225
(CESPE – 2011 – BRB – Analista de Tecnologia da Informação) O diagrama de

modelagem.
(CESPE – 2010 – ABIN – Oficial Técnico De Inteligência – Área De

<<extend>>.



(CESPE – – IE/MA – Análise de Sistemas) Ator é uma entidade – pessoa ou

projetando.

a tal módulo.
71. (CESPE – – INPI – Análise de Sistemas – III) Diagramas de caso de uso



16712855225
74. (CESPE – 2011 – BRB – Analista de Tecnologia da Informação) O diagrama de

modelagem.
75. (CESPE – 2010 – ABIN – Oficial Técnico De Inteligência – Área De



<<extend>>.


78. (CESPE – – IE/MA – Análise de Sistemas) Ator é uma entidade – pessoa ou

projetando.

a tal módulo.
(CESPE – – INPI – Análise de Sistemas – III) Diagramas de caso de uso


(CESPE - - MPE- - Analista de Sistemas) No diagrama UML abaixo, há

16712855225
duas raias; há um estado final; as atividades Preencher pedido e Avaliar proposta

podem ser executadas concorrentemente; será executada a atividade Avaliar
relatório assim que for concluída a atividade Preencher pedido ou a atividade
Elaborar relatório; será executada a atividade Elaborar relatório se o pedido não
for urgente.


Informação - Desenvolvimento) O diagrama de atividades tem por objetivo
mostrar o fluxo de atividades em um único processo; entretanto, esse diagrama
não mostra como as atividades dependem umas das outras, porque isso é
responsabilidade do diagrama de dependências.

atividade, considerado independente do diagrama de máquina de estado, serve
para descrever os passos a serem percorridos para a conclusão de uma atividade
específica.
(CESPE - 2010 - MPU - Analista de Informática - Desenvolvimento de Sistemas)

Na UML, um diagrama de atividades oferece uma notação para mostrar uma
16712855225
sequência de atividades, inclusive atividades paralelas. Ele pode ser aplicado em

qualquer perspectiva ou propósito, no entanto, é normalmente mais utilizado
para a visualização de fluxos de trabalho, processos de negócios e casos de uso.
(CESPE - 2010 - TRE-BA - Técnico Judiciário - Programação de Sistemas) Na UML,

os diagramas de sequência e os diagramas de atividade, também denominados
diagramas de interação, auxiliam a modelar os aspectos dinâmicos de sistemas.
Um diagrama de interação é formado pelo conjunto de objetos e seus
relacionamentos e inclui as mensagens que poderão ser enviadas entre eles.

87. (CESPE - 2011 – AL/ES - Análise de Sistemas - C) O diagrama de atividade

descreve as mensagens que são trocadas no processo, não se preocupando com
a temporalidade.
(CESPE - 2012 – ANP - Análise de Sistemas) O diagrama de atividades da UML é

utilizado para documentar um processo com suas ações e tomadas de decisões.

Informação - Desenvolvimento) Um diagrama de estado é capaz de mostrar os
estados possíveis de um objeto. Além disso, pode mostrar as transações
responsáveis pelas suas mudanças de estado.

Informação - Desenvolvimento) É possível criar um diagrama de transição de
estados que descreva o ciclo de vida de um objeto em níveis de detalhe
arbitrariamente simples ou complexos, dependendo das necessidades, pois não
há a obrigação de ilustrar todos os eventos possíveis.
91. (CESPE - 2004 - TRE-AL - Analista Judiciário - Especialidade - Análise de Sistemas

- Desenvolvimento) Na UML, um diagrama de estados mostra os vários estados
pelos quais passa um objeto e as transições de um estado para outro.
(CESPE - 2011 – AL/ES - Análise de Sistemas - A) O diagrama de estados tem a

finalidade de descrever os passos a serem percorridos para a conclusão de uma
tarefa específica, representando os estados dos objetos.
(CESPE - – IE/MA – Analista de Sistemas) Um diagrama de estado é uma

representação pró-ativa dos estados e eventos de um sistema, ou seja,
representa a previsão do estado interno do sistema em resposta aos possíveis
16712855225
eventos futuros que poderão ocorrer no sistema.
94. (CESPE - 2009 – INPI – Analista de Sistemas - I) Diagramas de estado (statechart)

podem ser usados para especificar, sob a perspectiva do usuário, requisitos de
sistemas de informação.
(CESPE - 2013 – MPU – Analista de Sistemas) No contexto da máquina de

estados, o evento, que pode ser tanto externo quanto interno, constitui um
estímulo capaz de ativar a transição de um estado.

(CESPE - 2010 - TRE-BA - Técnico Judiciário - Programação de Sistemas) Um

requisito é uma característica de projeto, uma propriedade ou um
comportamento de um sistema. Um diagrama de sequência enfatiza a
ordenação temporal de mensagens.
97. (CESPE - 2011 - Correios - Analista de Correios - Analista de Sistemas -

Desenvolvimento de Sistemas O diagrama de sequência pode ser usado para
descrever como alguns objetos de um caso de uso colaboram em algum
comportamento ao longo do tempo.
(CESPE - 2011 - TRE-ES - Analista - Análise de Sistemas - Específicos) Na figura,

o tempo é mostrado no eixo vertical e os objetos envolvidos na sequência de
uma atividade, no eixo horizontal.

Diagramas de interação são utilizados na UML para modelagem dos aspectos
dinâmicos do sistema. No diagrama de sequência - um diagrama de interação
em que é dada ênfase à ordenação temporal das mensagens -, é explicitamente
representada a linha de vida do objeto, bem como o período durante o qual ele
está desempenhando uma ação.
16712855225
100. (CESPE - 2011 - -ES - Técnico de Informática - Específicos) A modelagem

que permite a identificação de funcionalidades, comportamento do sistema,
ambiente, relações entre agentes e detalhe de requisitos funcionais é
representada por meio de diagrama de sequência de atividades.
101. (CESPE - 2011 - TRE-ES - Técnico - Programação de Sistemas - Específicos)

Em um diagrama de sequência, estão representadas classes, que não são
relacionadas por agregação e composição, entre outros tipos de relações
presentes em diagramas de classe, mas relacionadas, diretamente, por meio de
mensagens.

102. (CESPE - 2011 – AL/ES - Análise de Sistemas - B) O diagrama de sequência

evidencia as tarefas a serem executadas em um caso de uso, sem descrever as
mensagens trocadas entre os objetos.
103. (CESPE - – IE/MA - Análise de Sistemas) Diagrama de Sequência

apresenta uma visão estática do sistema, ou seja, por meio dele não é possível a
representação de iterações entre atores e sistema para um conjunto específico
de casos de uso.
104. (CESPE - 2010 – MPU - Análise de Sistemas) Na convenção de notação usada

na UML, a chamada por mensagens assíncronas é representada no diagrama de
sequência por meio de seta cheia (não pontilhada).
105. (CESPE - 2009 – MPM/AM – Analista de Sistemas) Um diagrama de

seqüência da UML apresenta tanto as interações entre atores e objetos quanto
interações de objeto para objeto.
diagrama de colaboração pode ser utilizado para modelagem de um conjunto
de funcionalidades que cooperam entre si para executar uma função específica.
107. (CESPE - 2009 – IE/MA – Analista de Sistemas) Diagramas de colaboração

ilustram as interações entre objetos em forma de grafo ou rede, na qual os
objetos podem ser colocados em qualquer lugar do diagrama.
108. (CESPE - – INPI – Analista de Sistemas) Diagramas de seqüência

(sequence) e colaboração (collaboration) envolvem a troca de mensagens entre
instâncias de classes.
16712855225
109. (CESPE - 2010 – TRE/MT – Analista de Sistemas – D) O diagrama de

comunicação enfatiza a ordem temporal de mensagens, que reagem a eventos
externos e internos.
110. (CESPE - 2011 – MEC – Analista de Sistemas) As informações mostradas no

diagrama de comunicação são, com frequência, praticamente as mesmas
apresentadas no diagrama de sequência, porém com um enfoque diferente: no
diagrama de sequência, não há preocupação com a temporalidade do processo,
isto é, ele se concentra no modo como os objetos estão vinculados e nas
mensagens que trocam entre si durante o processo.

111. (CESPE - 2013 – BACEN – Analista de Sistemas) O diagrama de comunicação

mostra a sequência de interações entre os elementos, de acordo com a
temporalidade com que os processos acontecem.
112. (CESPE - 2009 – TCU – Analista de Sistemas) Na UML 2.0, o diagrama de

interação geral é utilizado para modelar colaborações, conjunto de instâncias
estados representa estados de um caso de uso de um subsistema ou de um
sistema completo; e o diagrama de tempo demonstra a mudança de estado de
um objeto, ao longo do tempo decorrente de eventos externos.
113. (CESPE - – UNIPAMPA – Analista de Sistemas) O diagrama de tempo

é um diagrama de interação na UML 2.0 e tem como objetivo descrever o
comportamento de objetos, representando a situação em que um objeto se
encontra, dentro de um processo, em determinado momento.
114. (CESPE - – MEC – Analista de Sistemas) O diagrama de tempo,

tipicamente utilizado para acompanhar os estados por que passa uma instância
de uma classe, descreve a mudança no estado ou condição de uma instância de
uma classe, ou o seu papel durante um tempo.
diagrama de interação geral é uma variação do diagrama de sequência que
fornece uma visão geral de um sistema ou processo de negócio.
116. (CESPE - 2013 - TRT - 10ª REGIÃO (DF e TO) - Analista Judiciário - Tecnologia
da Informação) O diagrama de atividade é composto pelos diagramas de estado
e de sequência.
16712855225
117. (CESPE – – TCU - Auditor Federal de Controle Externo) Na UML 2.0, o

diagrama de interação geral é utilizado para modelar colaborações, conjunto de
instâncias que cooperam entre si para uma função específica; o diagrama de
máquina de estados representa estados de um caso de uso de um subsistema
ou de um sistema completo; e o diagrama de tempo demonstra a mudança de
estado de um objeto, ao longo do tempo decorrente de eventos externos.
118. (CESPE - 2015 - STJ - Analista Judiciário) No diagrama de caso de uso, as

formas corretas de se ligar um ator a um caso de uso são por meio de associação,
que demonstra a utilização, pelo ator, da função representada pelo caso de uso,
e por meio da generalização, que demonstra a relação de herança entre ambos.

119. (CESPE - 2015 - STJ - Analista Judiciário) No diagrama de estrutura composta,

a denominação de uma ocorrência de colaboração possui a mesma notação
utilizada na denominação de um objeto, e essa ocorrência representa a aplicação
do padrão descrito por uma colaboração a uma situação específica que envolve
classes ou instâncias que executam papéis específicos da colaboração, em que
uma colaboração pode conter outras colaborações dentro de si.
120. (CESPE - 2015 - STJ - Analista Judiciário) No diagrama de classe, os símbolos

#, + e -, que precedem atributos e métodos para indicar nível de acessibilidade,
significam, respectivamente, protegida, pública e privada.
16712855225

LISTA DE EXERCÍCIOS COMENTADOS (FCC)

UML
(FCC - 2010 – DPE/SP – Análise de Sistemas) Na UML os diagramas servem para

capturar diferentes visões do sistema. NÂO é um diagrama UML:
a) Diagrama de Métodos.
b) Diagrama de Classes.
c) Diagrama de Objetos.
d) Diagrama de Sequência.
e) Diagrama de Estados.
(FCC- 2012 – TRE/PI – Análise de Sistemas – IV) Um diagrama de objetos é um

tipo especial de diagrama, composto por objetos e seus vínculos, que
compartilha as mesmas propriedades comuns a todos os outros diagramas.
(FCC – – TCE/AL - Análise de Sistemas) Um diagrama de objetos:
a) tem a mesma função que um diagrama de atividades diferenciando deste

apenas na representação gráfica.
b) capta um conjunto de abstrações como um grupo de interesse e em tal

contexto expõe sua semântica e seus relacionamentos com outras abstrações
existentes nesse grupo da mesma forma que em um diagrama de classes.
c) exibe um único conjunto de objetos relacionados uns com os outros em um

determinado momento. 16712855225
d) mostra a seqüência de execução de atividades entre objetos relacionados, no

tempo, e a duração de cada objeto por meio de linhas de vida.
e) exibe diversos conjuntos de objetos relacionados uns com os outros em um

(FCC- 2009 – MEC – Análise de Sistemas) A UML define em sua versão 2.0, treze
tipos de diagramas. Acerca do Diagrama de Objetos da UML, assinale a
alternativa correta:

a) O Diagrama de Objetos mostra a configuração de nós de processamento em

tempo de execução.
b) O Diagrama de Objetos representa retratos estáticos de instâncias de itens

encontrados em diagramas de classes.
c) O Diagrama de Objetos representa uma visão dinâmica da interface entre

objetos e funcionalidades do sistema.
d) O Diagrama de Objetos tem por propósito focalizar um fluxo de atividades

que ocorrem internamente em um processamento, dentro de um período de
tempo.
e) O Diagrama de Objetos descreve o comportamento de objetos como reação

a eventos discretos, por meio de sequências de estados e ações que ocorrem
durante sua vida.
(FCC - 2011 - TCE-PR - Analista de Controle - Informática) Em UML 2.3, o

Diagrama de Perfil é um diagrama pertencente à categoria Diagrama de:
a) Estrutura estática, sendo usado para mostrar a estrutura de um sistema sob o

nível mais baixo dos classificadores.
b) Comportamento e mostra a estrutura interna de um classificador e o

comportamento de uma colaboração.
c) Comportamento, descrevendo a estrutura interna de uma classe e as

colaborações que esta estrutura torna possível.
16712855225
d) Comportamento, sendo utilizado para descrever o hardware utilizado em

implementações de sistemas e os ambientes de execução.
e) Estruturas, que opera no nível metamodelo permitindo definir estereótipos

personalizados, valores etiquetados e restrições.
(FCC – 2014 – TRT/1 – Analista de Sistemas) Diagramas de casos de uso

constituem-se em um tipo de diagrama definido na UML. Segundo a UML 2.4.1,
em um diagrama de casos de uso,
a) um ator pode ser representado apenas pelo símbolo do “stick man”.

b) só pode haver representado um único ator.
c) o número de atores e de casos de uso sempre deve ser o mesmo.
d) só pode haver representado um único caso de uso.
e) um ator pode ser representado pelo “stick man” ou por um retângulo com a
expressão <<actor>>.
(FCC - 2013 – TRT/12 - Análise de Sistemas A UML é utilizada para modelar

sistemas orientados a objetos. Um de seus diagramas é usado como técnica para
descrever lógica de procedimento, processo de negócio e fluxo de trabalho. Esse
diagrama, de várias formas, desempenha um papel semelhante aos fluxogramas,
mas a principal diferença entre esse diagrama e a notação de fluxograma é que
o diagrama suporta comportamento paralelo. O diagrama citado é o de:
b) Atividades
c) Sequência.
d) Distribuição
e) Componentes.
(FCC - 4 – AL/PE - Análise de Sistemas Visibilidade refere-se à capacidade

de um método referenciar uma característica de outra classe. Num diagrama de
classes da UML 2.0 a visibilidade é indicada com um prefixo representado pelos
caracteres:
I. # 16712855225
II. +
III. ~
IV. -
Os tipos de visibilidade definidos de I a IV são correta e respectivamente:
a) private - public - protected - package

b) public - private - package - protected
c) private - package - public - protected
d) protected - public - package - private
e) package - protected - private - public

(FCC - 2013 – TRT/12 - Análise de Sistemas A especificação UML 2.5 define dois
tipos principais de diagramas UML: structure diagrams e behavior diagrams.
Behavior diagrams mostram o comportamento dinâmico dos objetos em um
sistema, que pode ser descrito como uma série de mudanças no sistema no
decorrer do tempo. São exemplos de Behavior diagrams os diagramas de
a) Comunicação, Fluxo de Informação e Objeto.

b) Comunicação, Deployment e Máquina de Estado.
c) Temporização, Componente e Atividade.
d) Sequência, Caso de Uso e Atividade.
e) Classe, Atividade e Sequência.
10. (FCC - 2013 – AL/RN - Análise de Sistemas Os diagramas UML podem ser
divididos em dois grandes grupos, Diagramas Estruturais e Diagramas
Comportamentais. Analise a lista de diagramas abaixo:
I. Componentes.
II. Comunicação.
III. Implantação.
IV. Caso de Uso.
V. Classes.
VI. Estados.
São Diagramas Comportamentais APENAS os descritos em
a) III, IV e V.
b) I, IV e V.
c) II, V e VI. 16712855225
d) I, II e V.
e) II, IV e VI.
11. (FCC - 2 – TRF/2 - Análise de Sistemas Uma classe pode relacionar-se com
outras de diferentes maneiras, utilizando notações gráficas, tais como:

I, II e III referem-se, respectivamente, aos tipos:
a) associação, composição e generalização.

b) generalização, composição e associação.
c) composição, generalização e agregação.
d) associação, agregação e composição.
e) agregação, associação e generalização.
12. (FCC - 2 – TRF/2 - Análise de Sistemas A UML 2.0 divide os diagramas em

duas categorias, estruturais e de comportamento. São exemplos de diagramas
estruturais e de comportamento, respectivamente, os diagramas de:
a) classe e atividades.
b) comunicação e sequência.
c) componentes e objetos.
d) máquinas de estado e casos de uso.
e) casos de uso e sequência.
13. (FCC - 2 – TJ/PE - Análise de Sistemas Considere C = comportamental e E =

estrutural. Os diagramas de componentes, objetos, comunicação e estrutura
composta são, respectivamente, categorizados como:
a) C; C; E; C.
b) C; C; E; E.
c) C; E; E; C.
d) E; E; C; C.
e) E; E; C; E.
16712855225
14. (FCC - 1 – TRT/19 - Análise de Sistemas Considere: E = estruturais e C =

comportamentais. Os diagramas de comunicação, pacotes, implantação e
componentes são, respectivamente,
a) C; E; E; E.
b) C; C; E; E.
c) C; E; E; C.
d) E; C; C; C.
e) E; C; E; C.
15. (FCC - 2 – TJ/PE - Análise de Sistemas Considere o seguinte diagrama UML:

O número 1 e símbolo 1..* que aparecem ao lado das classes Nota Fiscal e Itens
se referem à restrição de:
a) herança.
b) agregação.
c) identidade.
d) multiplicidade.
e) polimorfismo.
16. (FCC - 2 – TRE/CE - Análise de Sistemas Na UML 2.0, representam

comportamentos de um sistema, os diagramas de:
a) comunicação e de caso de uso.

b) sequência e de implantação.
c) componentes e de atividades.
d) pacotes e de componentes.
e) atividades e de implantação.
17. (FCC - 2 – TRE/CE - Análise de Sistemas Em UML, os diagramas de Caso de

Uso tem por objetivo:
a) representar os atributos e operações de uma classe ou objeto.
b) mostrar o fluxo de mensagens de uma atividade do sistema para outra.

16712855225
c) capturar funcionalidades e requerimentos do sistema.
d) exibir uma interação entre um conjunto de objetos e seus relacionamentos.
e) representar o estado ou situação em que um objeto pode se encontrar no

decorrer da execução de processos de um sistema.
18. (FCC - 1 – TRT/19 - Análise de Sistemas Na versão 2.0 da UML, costuma

conter elementos tais como: ações, bifurcações, ramificações e fluxos. Trata-se
do diagrama de:

a) máquina de estados.
b) implantação.
c) sequência.
d) atividades.
e) artefatos.
19. (FCC - 1 – TRE/AP - Análise de Sistemas São, respectivamente, dois

diagramas estruturais e dois comportamentais:
a) Package, Interaction Overview, Timing e Deployment.

b) Component, Deployment, Activity e State Machine.
c) Composite Structure, Package, Component e Communication.
d) State Machine, Object, Use Case e Composite Structure.
e) Object, Interaction Overview, Use Case e Activity.
(FCC - 1 – TRE/AP - Análise de Sistemas Os casos de uso podem ser

organizados pela especificação de relacionamentos de:
a) evento, ramificação e inclusão.

b) composição, inclusão e extensão.
c) agregação, extensão e bifurcação.
d) generalização, inclusão e extensão.
e) herança, composição e autorrelacionamento.
21. (FCC - 2011 – INFRAERO - Análise de Sistemas Para captar os requisitos

funcionais de um sistema pode- se utilizar a UML. O diagrama mais adequado
para essa finalidade é o diagrama de:
16712855225
a) casos de uso.
b) atividades.
c) colaboração.
d) classes.
e) comunicações.
(FCC - 1 – INFRAERO - Análise de Sistemas Na notação UML, um nome entre

ângulos (ex. <<nome>>), colocado acima do nome de outro elemento, é
utilizado para a representação gráfica de:
a) objeto.

b) função.
c) multiplicidade.
d) operação.
e) estereótipo.
(FCC - 2011 – INFRAERO - Análise de Sistemas Qualquer descendente do

classificador é capaz de usar a característica; sua especificação é antecedida pelo
símbolo #. A definição trata da visibilidade usada na notação UML, de nível:
a) público.
b) privado.
c) pacote.
d) protegido.
e) dependente.
24. (FCC - 1 – INFRAERO - Análise de Sistemas Como exemplo, a classe

CarroImportado (em itálico) é escrita desta forma na UML para especificar que
tal classe:
a) é concreta.
b) pode não apresentar instâncias diretas.
c) herda características de mais de uma classe mãe.
d) herda características de apenas uma classe mãe.
e) se relaciona com ela mesma.
(FCC - 1 – TRT/01 - Análise de Sistemas Na UML 2.0, os diagramas de objeto,

de componente, de atividade e de comunicação são, respectivamente, do tipo
(considere E para Estrutural e C para Comportamental):
16712855225
a) C; C; C; E.
b) C; C; E; E.
c) C; E; E; C.
d) E; C; E; C.
e) E; E; C; C.
(FCC - 1 – TRT/24 - Análise de Sistemas Na UML, o relacionamento entre

uma superclasse e suas subclasses é denominado:
a) generalização.
b) decomposição.

c) agregação composta.
e) dependência.
27. (FCC - 1 – TRT/24 - Análise de Sistemas Na UML, especifica-se que uma

classe é abstrata escrevendo seu nome:
a) só com a inicial em letra maiúscula.

b) todo com letras maiúsculas.
c) em itálico.
d) em negrito.
e) grifado.
(FCC - 1 – TRE/RN - Análise de Sistemas Frequentemente usado para

modelagem de sistemas de tempo real. Descreve como um sistema responde
aos estímulos internos e externos. Mostra as diferentes situações do sistema e os
estímulos que provocam transições de uma para outra situação. Trata-se do
modelo de:
a) eventos.
b) agregação de objetos.
c) dados.
d) fluxo de dados.
e) máquina de estado.
(FCC - 1 – TRE/RN - Análise de Sistemas São organizadas em uma hierarquia,

com as classes de objetos mais genéricas no topo, as quais legam seus atributos
às classes mais especializadas.
16712855225
Trata-se:
a) da hierarquia de herança.
b) do modelo relacional.
c) da gestão hierárquica.
d) do modelo sequencial.
e) da especificação funcional.
(FCC - 1– IXA - Análise de Sistemas Um detalhe importante que deve ser

especificado para os atributos e operações das classes é a visibilidade. Desta

forma, os símbolos: + (sinal de mais), # (sinal de número), - (sinal de menos) e ~

(til) correspondem respectivamente a:
a) público, pacote, privado e protegido.

b) público, protegido, privado e pacote.
c) privado, protegido, público e pacote.
d) privado, pacote, público e protegido.
e) pacote, protegido, privado e público.
31. (FCC - 0 – TRT/22 - Análise de Sistemas A modelagem de instâncias de itens

contidos em diagramas de classes é feita pelo diagrama de:
a) sequência.
b) pacotes.
c) casos de uso.
d) objetos.
e) componentes.
(FCC - 0 – TRT/22 - Análise de Sistemas Na UML 2.0 NÃO se trata de um

dos diagramas de interação, o:
a) Sequence.
b) Deployment.
c) Interaction Overview.
d) Timing.
e) Communication.
(FCC - 0 – TRT/22 - Análise de Sistemas Na taxonomia dos diagramas de

estrutura (S) e de comportamento (C) da UML, os diagramas de Pacote, Classe,
16712855225
Sequência e Objeto são, respectivamente, de
a) S, S, C e S.
b) S, S, C e C.
c) S, C, S e C.
d) C, S, C e S.
e) C, C, S e C.
34. (FCC - 0 – MPE/RN - Análise de Sistemas Na UML, um relacionamento entre


a) associação.
b) dependência.
c) composição.
d) agregação.
e) generalização.
(FCC - 0 – MPE/RN - Análise de Sistemas Na UML, um relacionamento entre

a) associação.
b) dependência.
c) composição.
d) agregação.
e) generalização.
(FCC - 0 – BAHIAGÁS - Análise de Sistemas Na UML é uma forma de

agregação com propriedade bem definida e tempo de vida coincidente da parte
com o todo. Trata-se de:
a) Generalização.
b) Estereótipo.
c) Visibilidade.
d) Composição
e) Herança.
37. (FCC - 2010 – BAHIAGÁS - Análise de Sistemas É um tipo de diagrama

comportamental da UML. Trata-se do Diagrama de:
a) Casos de Uso. 16712855225
b) Pacotes.
c) Objetos.
d) Componentes.
e) Classes.
(FCC - 2010 – TRF/4 - Análise de Sistemas Em UML, ele é uma variação do

diagrama de classes e utiliza quase a mesma notação, exceto que os objetos são
escritos com seus nomes sublinhados e todas as instâncias num relacionamento
são mostradas. Trata-se do diagrama de:
a) Estado.

b) Objetos.
c) Sequência.
d) Colaboração.
e) Atividade.
(FCC - 0 – SGSA - Análise de Sistemas Em UML, são diagramas feitos para

facilitar a comunicação com os futuros usuários do sistema, e com o cliente,
sendo especialmente úteis para determinar os recursos necessários que o
sistema deve ter, mas não são adequados para representar o desenho e não
podem descrever os mecanismos internos de um sistema. São diagramas de:
a) Sequência.
b) Colaboração.
c) Distribuição.
d) Caso de Uso.
e) Atividade.
40. (FCC - 10 – AL/SP - Análise de Sistemas Na UML 2.0, o Diagrama de

Comunicação e o de Sequência são dois tipos de diagrama de:
a) Estrutura Composta.
b) Componente.
c) Interação.
d) Máquina de Estado.
e) Objeto.
41. (FCC - 0 – METRÔ/SP - Análise de Sistemas São os meios utilizados para a

conjunto de elementos, além de permitir visualizar o sistema sob diferentes
16712855225
a) Eventos.
b) Classes.
c) Objetos.
d) Relacionamentos.
e) Diagrama.
42. (FCC - 0 – TRT/20 - Análise de Sistemas São os meios utilizados para a


conjunto de elementos, além de permitir a visualização do sistema sob diferentes

a) Relacionamentos.
b) Diagrama.
c) Eventos.
d) Classes.
e) Objetos.
43. (FCC - 2010 – TCM/PA - Análise de Sistemas De acordo com a OMG, especifica
a coordenação de execuções de comportamentos usando um modelo de fluxo
de controle e de dados. Modela o comportamento do sistema denotando os
caminhos lógicos que um processo pode seguir. Compõe a visão dinâmica da
UML o diagrama de:
a) estado composto.
b) atividades.
c) objetos.
d) entidades.
e) composição.
44. (FCC - 0 – TCM/PA - Análise de Sistemas Na UML, a linha de vida (lifeline) é

parte integrante do diagrama de:
a) artefatos.
b) sequência.
c) pacotes.
d) componentes.
e) gráfico de estados. 16712855225
45. (FCC - 0 – TCM/PA - Análise de Sistemas Um relacionamento do tipo todo-

parte, no qual a vida da parte depende da vida do todo, é do tipo:
a) composição.
b) especialização.
c) dependência.
d) enumeração.
e) cardinalidade.

46. (FCC - 2010 – TCM/PA - Análise de Sistemas O antigo diagrama de colaboração

é adotado na UML 2.0 como diagrama de:
a) objeto.
b) estado.
c) iteração.
d) implantação.
e) comunicação.
47. (FCC - – TRT/3 - Análise de Sistemas Um relacionamento entre classes que

usa como notação um diamante preenchido associando, por exemplo, as classes
Janela e Moldura, representa:
a) um legado.
b) um polimorfismo.
c) uma generalização.
d) uma dependência.
e) uma composição.
48. (FCC - – TRT/3 - Análise de Sistemas Como extensão do vocabulário UML,

a representação gráfica de um nome entre ângulos (<< >>), colocado acima do
nome de outro elemento, representa:
a) um pacote.
b) um desvio.
c) um estereótipo.
d) uma agregação.
e) uma especialização.
16712855225
49. (FCC - – TRT/7 - Análise de Sistemas Uma parte física e substituível de um

sistema com o qual está em conformidade e proporciona a realização de um
conjunto de artefatos (UML) é um:
a) componente.
b) atributo.
c) método.
d) caso de uso.
e) objeto.

(FCC - – TRE/PI - Análise de Sistemas No diagrama de classes da UML uma

superclasse, com uma ou mais subclasses, representa um relacionamento do
tipo:
a) composição.
b) agregação.
c) generalização.
d) associação.
e) modularização.
51. (FCC - – TJ/SE - Análise de Sistemas NÃO se trata de um relacionamento

especificado na UML:
a) o encapsulamento.
b) a dependência.
c) a generalização.
d) a associação.
e) a realização.
(FCC - – TJ/SE - Análise de Sistemas Uma classe abstrata, de acordo com

a UML,
a) tem seu nome escrito em itálico.

b) pode ser instanciada diretamente.
c) não tem atributos.
d) não tem operações.
e) não pode ter classes-filha.
(FCC - – TJ/15 - Análise de Sistemas Na UML, a visibilidade declarada aos

16712855225
atributos e operações de classificadores define que quando a um deles antecede

o símbolo - (sinal de menos) este é somente:
a) privado.
b) protegido.
c) público protegido.
d) público.
e) pacote público.
54. (FCC - – TJ/15 - Análise de Sistemas Cobre um conjunto de instâncias dos

itens encontrados nos diagramas de classe, expressa a parte estática de uma

interação composta pelos objetos que colaboram entre si, mas sem qualquer
uma das mensagens passadas entre eles e, também, congela um momento no
tempo. Na UML, trata-se do diagrama de:
a) atividade.
b) comunicação.
c) sequência.
d) tempo.
e) objetos.
(FCC - – TJ/16 - Análise de Sistemas Considere diversas agências (classe

Agencia) de atendimento a reclamações trabalhistas espalhadas em vários
pontos do Estado. Uma delas, a central (classe AgenciaCentral), tem atributos
diferenciados, porém herda os demais atributos e operações de Agencia. O
relacionamento entre essas classes é definido na UML como:
a) inclusão.
b) composição.
c) específico.
d) generalização.
e) encapsulamento.
(FCC - – TJ/16 - Análise de Sistemas São diagramas comportamentais da

UML:
a) Component e Activity.
b) Timing e Deployment.
c) Composite Structure e Use Case.
d) State Machine e Object. 16712855225
e) Use Case e Sequence.
57. (FCC - – TJ/16 - Análise de Sistemas São diagramas estruturais da UML:
a) Package e Activity.
b) Communication e Activity.
c) Communication e Object.
d) Class e Use Case.

(FCC - – TJ/PA - Análise de Sistemas Na especificação de operações de

uma classe, o nível de visibilidade indicado pelo símbolo ~ (til) significa:
a) escopo de instância.
b) escopo de estática.
c) pacote.
d) privado.
e) protegido.
(FCC - 2009 – TJ/PA - Análise de Sistemas) Considere o enunciado: Uma escola

(todo) tem um ou mais departamentos (parte). Cada departamento pertence
exatamente a uma única escola. No âmbito da UML, este enunciado especifica
um relacionamento de:
a) agregação por composição.

b) realização.
c) dependência.
d) herança.
e) recursão.
(FCC - – TJ/PA - Análise de Sistemas) Considere:
I. Modelagem do aspecto dinâmico de um sistema;

II. Exibição da concorrência de atividades;
III. Exibição das ramificações de controle de fluxo.
O Diagrama de Atividades da UML contempla corretamente o que consta em
a) I, apenas. 16712855225
b) II, apenas.
c) III, apenas.
d) II e III, apenas.
e) I, II e III.
61. (FCC - – TJ/PA - Análise de Sistemas) Nos relacionamentos entre Casos de

Uso:
a) um include significa que o caso de uso base incorpora implicitamente o

comportamento de outro, sob certas condições.

b) não é permitida a generalização.
c) somente include é considerado um estereótipo.
d) somente extend é considerado um estereótipo.
e) tanto include quanto extend são considerados estereótipos.
(FCC - 2009 – MPE/SE - Análise de Sistemas) Uma instância de classe em um

determinado momento é
a) uma cardinalidade.
b) uma operação.
c) um atributo.
d) um objeto.
e) uma sequência de operações.
(FCC - – MPE/SE - Análise de Sistemas) Considerando os tipos COM =

comportamental e EST = estrutural na UML 2.0, classifique correta e
respectivamente os seguintes diagramas UML:
I. State Machine Diagram

II. Sequence Diagram
III. Composite Structure Diagram
a) EST - COM - COM.

b) COM - EST - EST.
c) COM - COM - EST.
d) COM - EST - COM. 16712855225
e) EST - EST - COM.
64. (FCC - – MPE/SE - Análise de Sistemas) Considere uma operação de classe

escrita da seguinte forma:
+ adicionarMensagem(m: Mensagem): Status
O símbolo de soma no início do texto e o termo entre parênteses significam,

respectivamente:
a) público e assinatura.

b) protegido e método.
c) assinatura e privado.
d) privado e método.
e) método e público.
(FCC - 2009 – PGE/RJ - Análise de Sistemas) No âmbito da UML, é o mais

importante detalhe que pode ser especificado para atributos e operações de um
classificador e cuja especificidade, que pode ser de quatro níveis diferentes (ex.
pacote), é utilizável por outros. Trata-se de:
a) usabilidade.
b) parâmetro.
c) instância.
d) visibilidade.
e) escopo de efeito.
(FCC - 8 – TRT/18 - Análise de Sistemas) Se em algum ponto de um Caso de

Uso houver a necessidade de inserir incondicionalmente um cenário contido em
outro Caso, deve-se usar o relacionamento de dependência estereotipado
como:
a) <<realize>>.
b) <<extend>>.
c) <<generalize>>.
d) <<enumeration>>.
e) <<include>>.
67. (FCC - 8 – TRT/18 - Análise de Sistemas) Atividade, Caso de Uso e

Componente são diagramas da UML 2.0 classificados, respectivamente, no
16712855225
âmbito:
a) comportamental, comportamental e comportamental.

b) comportamental, estrutural e estrutural.
c) comportamental, comportamental e estrutural.
d) estrutural, comportamental e estrutural.
e) estrutural, estrutural e comportamental.
(FCC - 8 – TRT/18 - Análise de Sistemas) Na notação original da UML 2.0, os

símbolos + (mais) e # (jogo da velha), antecedendo as operações de uma classe,
caracterizam tais operações, respectivamente, como:

a) pública e protegida.
b) protegida e privada.
c) pública e privada.
d) pacote e protegida.
e) pública e pacote.
(FCC - 8 – TCE/AL - Análise de Sistemas) Os diagramas UML da categoria

comportamental são os de:
a) classes, objetos e componentes.

b) casos de uso, sequência e classes.
c) classes, atividades e sequência.
d) casos de uso, atividades e máquinas de estados.
e) objetos, estrutura composta e máquinas de estado.
70. (FCC - 8 – TRF/5 - Análise de Sistemas) Na UML 2.0, são dois diagramas
comportamentais:
a) Use Case e Package.

b) Sequence e Component.
c) State Machine e Communication.
d) Timing e Component.
71. (FCC - 8 – METRÔ/SP - Análise de Sistemas) Considere:
I. Farol ligado.
II. Comprar produto. 16712855225
III. Máquina elétrica.
Os itens acima são representados em diagramas UML, respectivamente, como
a) estado, caso de uso e classe.

b) estado, classe e caso de uso.
c) caso de uso, estado e classe.
d) caso de uso, classe e estado.
e) classe, estado e caso de uso.

a) Objetos.
b) Atividades.
c) Comunicação.
e) Seqüência.
a) Objetos.
b) Atividades.
c) Comunicação.
e) Seqüência.
74. (FCC - – TRT/15 - Análise de Sistemas) A documentação de um caso de uso

costuma descrever, por meio de uma linguagem simples, informações sobre ele.
Na UML 2.0, essa documentação:
a) não possui um formato específico definido.

b) deve ser feita por meio de fluxogramas.
c) não pode ser feita por meio de outros diagramas.
d) costuma descrever apenas, em linhas gerais, a função do caso de uso
e) não costuma deixar claro quais atores interagem com os casos de uso.
75. (FCC - – TJ/PA - Análise de Sistemas) Considere o processo de negócio e

16712855225
o diagrama abaixo.

É correto afirmar:
a) Trata-se de um diagrama de atividades da UML.

b) Não há relação entre o processo e o diagrama.
c) Um processo não pode ser modelado por um diagrama UML.
d) O processo pode ser modelado apenas por um diagrama de caso de uso da
UML.
e) Trata-se de um diagrama de classes da UML.
76. (FCC - – TJ/PA - Análise de Sistemas) Um analista judiciário do Tribunal de

Justiça do Amapá precisa utilizar um diagrama que permite adaptar o
metamodelo UML para diversas plataformas como Java EE ou .NET ou para
diferentes domínios como aplicações em tempo real e modelagem de processos
de negócio. Este diagrama precisa permitir a definição de estereótipos
16712855225
customizados e restrições. Dentre os diagramas da UML 2.5, o que melhor

atende estas necessidades é o Diagrama de:
a) Perfil.
b) Deployment.
c) Estruturas Compostas.
d) Componentes.
e) Colaboração.
(FCC - – TCE/GO - Análise de Sistemas) A UML especifica um conjunto de

diagramas para modelar sistemas orientados a objeto em suas várias

perspectivas. Dois destes diagramas podem ser muito úteis para apresentar uma
visão de nível mais alto do sistema, como:
I. adequado para captar os requisitos funcionais de um sistema, ajudando no

entendimento destes requisitos.
II. suporta e estimula o comportamento paralelo, sendo útil para modelagem de
fluxo de trabalho e de processos, principal- mente, processos de negócio.
Os diagramas descritos em I e II são, correta e respectivamente, de
a) Casos de Uso e de Sequência.

b) Comunicação e de Atividades.
c) Componentes e de Sequência.
d) Casos de Uso e de Atividades.
e) Interação e de Distribuição.
78. (FCC - – TRT/13 - Análise de Sistemas) Este diagrama da UML pode ser
usado para modelar processos de negócio. Suporta comportamento paralelo e
permite que, quem está seguindo o processo, escolha a ordem na qual fazer as
coisas. Em outras palavras, ele simplesmente determina as regras essenciais de
sequência que se deve seguir. São geralmente usados para mostrar o que
acontece, mas não quem faz o que, já que faz sentido se concentrar no que é
feito, em vez de em quem realiza quais partes do comportamento.
O diagrama descrito é o diagrama de:
a) sequência.
b) atividades.
c) casos de uso. 16712855225
d) comunicação.
e) distribuição.
79. (FCC - – TRT/13 - Análise de Sistemas) Observando os processos em trâmite

no Tribunal, João observou que as situações pelas quais os processos passavam
poderiam ser classificadas em: "abrindo", "aberto", "em trâmite", "encerrando" e
"arquivado". Do ponto de vista da orientação a objetos ele percebeu que poderia
modelar mais adequadamente as condições ou situações da vida do objeto
processo utilizando, para representá-las, o diagrama UML denominado:
a) Interface.

b) Pacote.
c) Caso de uso.
d) Máquina de estados.
e) Classes.
(FCC - – AL/PE - Análise de Sistemas) Considere o diagrama UML para a

classe Conta ilustrado abaixo.
É correto afirmar:
a) A figura apresenta um diagrama de sequência, usado para representar o

comportamento dinâmico de uma classe. O diagrama de sequência pode ser
utilizado para ajudar a originar as sequências de testes que vão exercitar o
comportamento dinâmico da classe e daquelas classes que colaboram com ela.
b) As sequências iniciais movem-se entre os objetos Conta vazia e Conta

estabelecida. A maior parte dos comportamentos da classe ocorre enquanto se está
no objeto Conta ativa. Uma retirada final e fechamento da conta para a classe Conta
fazem com que se estabeleçam mensagens para os objetos Conta inativa e Conta
16712855225
morta, respectivamente.
c) Os testes projetados devem cobrir apenas os objetos centrais do diagrama, quais

sejam, Conta estabelecida, Conta ativa e Conta inativa, já que Conta vazia e Conta
morta não contêm dados a serem validados.
d) O modelo de estados pode ser percorrido em forma de inclusão progressiva.

Neste contexto, inclusão progressiva implica um caso de teste exercitar uma única
transição e, quando uma nova transição tiver de ser testada, são usadas apenas
aquelas previamente testadas.

e) O caso de teste: Abrir • EstabelecerConta • FazerDepósito(inicial) •

FazerRetirada(final) • Fechar é denominado sequência máxima de teste e a este caso
de teste não podem ser acrescentadas outras sequências de teste.
81. (FCC - – AL/PE - Análise de Sistemas) Considere o diagrama da UML 2.0:
Trata-se de um diagrama de I e nele podem ser identificados II , III e IV. As lacunas

de I a IV são correta e respectivamente preenchidas por:
a) interfaces - componentes - relacionamentos de realização - conexões

b) implantação - elementos de hardware - nós - vias de comunicação
c) instalação - elementos de infraestrutura - nós - estereótipos de nós
d) modelagem cliente/servidor - servidor - clientes - interfaces de banco de dados
e) componentes - interfaces - componentes - relacionamentos de dependência
(FCC - – TRT/13 - Análise de Sistemas) Marcelo trabalha como Analista

Legislativo na Assembleia Legislativa do Estado de Pernambuco e recebeu a
tarefa de elaborar um diagrama da UML 2.0 que seja capaz de modelar o que
16712855225
pode ocorrer em partes de um sistema orientado a objetos, como: fluxos de

controle e de dados, situações de decisão em que haja uma entrada e diversas
saídas, diferentes ações que podem ser executadas por objetos ou entidades
quando um método for executado, como um conjunto de ações relacionadas
pode ser executado e como afetará objetos ao redor, situações em que mais de
uma atividade pode acontecer ao mesmo tempo.
Marcelo optou por usar o diagrama de:
a) Classes.
b) Atividades.

c) Colaboração.
d) Objetos.
e) Casos de Uso.
(FCC - – TRT/13 - Análise de Sistemas) Embora BPMN e UML tenham

abordagens diferentes em relação à modelagem de processos de negócios,
diagramas UML que modelam o comportamento dinâmico podem ser usados
na modelagem de alguns processos de negócio, como os diagramas de__I__ e
de___II___ .
As lacunas I e II são correta e respectivamente preenchidas com:
a) Classes - Objetos
b) Estados - Implantação
c) Componentes - Objetos
d) Casos de Uso - Atividades
e) Classes - Sequência
84. (FCC - – TRT/2 - Análise de Sistemas) UML é uma linguagem visual para
modelagem de sistemas orientados a objeto. Considere o diagrama UML:
16712855225
Uma primitiva importante dos diagramas de ..I... é a troca de mensagem, como na

figura acima, que ilustra a troca de mensagens entre objetos e entre atores e
objetos. Estas mensagens, utilizadas para indicar interação ou comunicação, podem
ter diferentes significados:

- Chamada: significa que um objeto está solicitando a execução de ...II.... de um

outro objeto. Para isso, é necessário que ele seja declarado como público ..III......
correspondente.
- Ocorrência de Evento: um evento é algum acontecimento externo ao software,

mas que é a ele notificado, pois lhe diz respeito. Exemplos são as saídas para
dispositivos (como disco ou monitor) feitos através de serviços do sistema
operacional. Esta é a forma padrão de interação entre ...IV..... .
As lacunas I, II, III e IV são, correta e respectivamente, preenchidas em:
a) sequência - um método - na classe - objetos e atores.

b) atividades - um procedimento - no método - classes e objetos.
c) objetos - uma mensagem - no método - objetos e métodos.
d) sequência - um método - no método construtor - classes e métodos.
e) atividades - uma classe - na superclasse - objetos e atores.
(FCC - – SABE - Análise de Sistemas) Considere a imagem abaixo:
Na UML 2.0, o conceito de modelagem de classes que pode ser observado na

imagem é:
16712855225
a) Herança.
b) Propagação.
c) Agregação.
d) Composição.
e) Associação Simples.
(FCC - – TRT/13 - Análise de Sistemas) Em um diagrama de sequência UML

2.0, o símbolo utilizado para denotar uma mensagem perdida é:
a)
b)

c)
d)
e)
87. (FCC - – TRT/9 - Análise de Sistemas) Nos diagramas de classe da UML, o

termo visibilidade refere-se à capacidade de um método de referenciar uma
característica de outra classe. Sobre os valores possíveis para definir a visibilidade
das características de uma classe,
a) apenas métodos da classe que contém o modificador private e de classes

contidas no mesmo pacote podem acessar características privadas. O caractere
“-” precede as características privadas.
b) os métodos das classes definidas no mesmo pacote da classe em questão

podem acessar as características dessa classe definidas como pacote. O caractere
“§” precede as características de pacote.
c) qualquer método pode acessar livremente as características públicas, exceto

métodos de classes envolvidas em relações de herança ou implementação de
interface. O caractere “+” precede características públicas.
d) apenas métodos presentes no mesmo pacote ou em classes que possuem

relação de herança ou implementação de interface podem acessar características
default. O caractere “*” precede características default.
e) somente os métodos da classe que contém o modificador protected e seus

descendentes via herança podem acessar características protegidas (em Java
características protegidas também possuem acessibilidade de pacote). O
caractere “#” precede as características protegidas.
16712855225
(FCC - – MPE/MA - Análise de Sistemas) Em UML, casos de uso mais

complexos podem ser construídos de partes menores por meio de relações.
Analise as descrições destas relações.
I. Incorpora um caso de uso dentro da sequência de comportamento de outro

caso de uso. A notação UML 2 para esta relação é uma seta tracejada indo do
caso de uso origem para o caso de uso destino com o nome da relação indicado
na seta entre << >>.

II. Nesta relação um caso de uso pai tem o comportamento comum e os casos
de uso filhos acrescentam variações a ele. A UML 2 indica esta relação por uma
seta de traço contínuo partindo do caso de uso filho com a ponta triangular
chegando ao caso de uso pai.
III. Acrescenta comportamento incremental a um caso de uso. Representa a

situação em que alguma capacidade inicial é definida e mais tarde recursos são
acrescentados. A notação UML 2 para esta relação é uma seta tracejada do caso
de uso estendido até o caso de uso básico com o nome da relação indicado na
seta entre << >>.
As relações I, II e III são correta e respectivamente definidas como:
a) generalização - especialização - extensão.

b) private - public - protected.
c) include - generalização - extend.
d) derived - generalization - added.
e) extend - generalização - include.
(FCC - – TRF/2 - Análise de Sistemas) Atributos estáticos são atributos da

classe em vez de serem atributos de uma instância da classe. Em UML um
atributo estático é representado ao se utilizar em sua transcrição o:
a) modo sublinhado
b) símbolo #
c) símbolo /
d) modo itálico
e) símbolo ~
16712855225
(FCC - – TJ/PE - Análise de Sistemas) É empregado para a modelagem dos

aspectos físicos de um sistema OO. Mostra a configuração dos nós de
processamento em tempo de execução e os artefatos que nele existem. Trata-
se do diagrama de:
a) sequência.
b) atividades.
c) implantação.
d) pacotes.
e) comunicação.

91. (FCC - – TRE/AP - Análise de Sistemas) São diagramas de interação os de
a) componentes e de implantação.
b) sequência e de máquina de estados.
c) comunicação e de sequência.
d) atividades e de implantação.
e) interação e de componentes.
(FCC - – TRE/RN - Análise de Sistemas) Na modelagem de Caso de Uso,

<<include>> e <<extend>> são relacionamentos de:
a) dependência.
b) agregação.
c) especialização.
d) atores entre si.
e) atores com os casos de uso.
(FCC - – TRE/RN - Análise de Sistemas) Um relacionamento semântico entre

classificadores, no qual um deles especifica um contrato cujo cumprimento é
assegurado pelo outro. Na UML, trata-se de:
a) herança múltipla.
b) realização.
c) multiplicidade.
d) composição.
e) visibilidade.
94. (FCC - – TRE/RN - Análise de Sistemas) Por um mecanismo de ampliação

de seu vocabulário, a UML permite que sejam criados novos blocos de
16712855225
construção derivados dos já existentes, todavia específicos a determinados

problemas. Esse mecanismo é definido como:
a) persistência.
b) derivação.
c) polimorfismo.
d) estereótipo.
e) operação.

(FCC - – TRT/8 - Análise de Sistemas) Para demonstrar elementos

estruturais e comportamentais de um sistema, a UML pode utilizar,
respectivamente, os diagramas de:
a) Atividade e de Sequência.
b) Caso de Uso e de Comunicação.
c) Sequência e de Objeto.
d) Classe e de Pacote.
e) Pacote e de Atividade.
(FCC - – TRE/RS - Análise de Sistemas) Um dos mais importantes detalhes

que se pode especificar para os atributos e operações de uma classe é a sua
visibilidade. Na UML, os níveis de visibilidade podem ser representados pelos
símbolos:
a) + (público), - (privado), # (pacote), ~ (protegido).

b) + (privado), - (público), # (pacote), ~ (protegido).
c) + (público), - (privado) e # (protegido), somente.
d) + (público) e - (privado), somente.
e) + (público), - (privado), # (protegido), ~ (pacote).
97. (FCC - – MPE/RN - Análise de Sistemas) Caso particular de associação

binária utilizado para expressar um relacionamento todo-parte. Entretanto, a
parte pode não ser exclusiva de um único todo. No diagrama de classes é uma:
a) Generalização.
b) Composição.
c) Estereotipagem.
d) Agregação. 16712855225
e) Dependência.
(FCC - – TRT/14 - álise de Sistemas) Um relacionamento todo-parte onde

o todo controla a vida das partes; todavia as partes podem ser removidas explici-
tamente antes da morte do todo. Trata-se de:
a) particionamento.
b) abstração.
c) enumeração.
e) agregação por composição.

(FCC - – TRT/20 - Análise de Sistemas) Na UML, o diagrama que serve para

organizar o comportamento do sistema é o diagrama de:
a) sequência.
b) estados.
c) caso de uso.
d) classes.
e) objetos.
100. (FCC – 10 – AL/SP - Análise de Sistemas) Um relacionamento estendido

entre dois casos de uso é um relacionamento de:
a) associação.
b) composição.
c) generalização.
d) estado.
e) dependência.
16712855225

LISTA DE EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)

(FG - – MEC – Análise de Sistemas) A UML define em sua versão 2.0, treze
tipos de diagramas, divididos em duas categorias: diagramas estruturais e
diagramas dinâmicos.
Assinale a alternativa que não indique um diagrama estrutural da UML.
a) Diagrama de Visão Geral.

b) Diagrama de Implantação.
c) Diagrama de Pacotes.
d) Diagrama de Classes.
e) Diagrama de Objetos.
(CESGRANRIO - 2010 – PETROBRÁS - Analista de Sistemas – B) O diagrama de

pacotes enfatiza a apresentação das classes do ambiente modelado, de acordo
com um conjunto de eventos.
(CESGRANRIO - 2010 – PETROBRÁS – Análise de Sistemas – C) O diagrama de

implantação é usado para sistemas distribuídos e permite apresentar a topologia
de uma rede de máquinas e qual processo cada máquina vai rodar.
(CESGRANRIO - 2010 - Petrobrás - Analista de Sistemas Júnior - Engenharia de

Software - A) O diagrama de estrutura composta serve para ilustrar a arquitetura
de um sistema, mostrando o agrupamento de suas classes.
(CESGRANRIO - 2013 – LIQUIGÁS – Analista de Sistemas) Seja o seguinte

16712855225
diagrama UML 2:

Que tipo de diagrama é esse?
a) Diagrama de objetos
b) Diagrama de tempo
c) Diagrama de estados
d) Diagrama de comunicação
e) Diagrama de colaboração
(ESAF - – BACEN – Analista de Sistemas) A UML inclui diagramas de

interação para ilustrar como os objetos interagem por meio de mensagens. Os
diagramas de interação constituem uma generalização de dois tipos de
diagramas especializados na UML: Diagrama de Seqüência e Diagrama de
Comunicação.
Assinale a sentença que se refere exclusivamente a um Diagrama de

Comunicação.
a) Cada mensagem entre objetos é representada com uma expressão de

mensagem em linha sólida, com seta cheia, entres as linhas de vida verticais.
b) A notação UML para chamadas assíncronas é uma mensagem com seta
traçada.
c) Os participantes da linha da vida devem representar um objeto, não uma
coleção.
d) A ordem das mensagens é ilustrada com números de seqüência.
e) A barra de especificação de execução indica o foco de controle.
(PUC/PR - 2010 – URBS – Analista de Sistemas - I) A Unified Modeling Language

(UML) é uma linguagem de programação orientada a objetos.
16712855225
(ESAF - 2010 – SUSEP – Analista de Sistemas O Diagrama de Estado mostra:
a) os estados expressos que os objetos de uma dada classe podem assumir e as

transformações entre pares de classes
b) os estados admissíveis que os atributos de uma dada classe podem modificar

e os pares de estados mais relevantes.
c) os estados de atualização que os objetos de qualquer classe podem assumir

e as transições permitidas entre instâncias.

d) os estados admissíveis que os objetos de uma dada classe podem assumir e

as transições permitidas entre pares de estados.
e) os estados coerentes com os objetos priorizados e as restrições de transições

entre pares de estados.
(ESAF - 2012 – CGU – Analista de Sistemas Para indicar a visibilidade da

propriedade, a UML:
a) incorpora um prefixo a um nome de atributo ou nome de operação.
b) incorpora um sufixo a um nome de atributo ou origem de operação.
c) gera um nome de atributo e nome de transação totalmente distinto do

anterior.
d) duplica nome de atributo ou nome de operação.
e) sublinha o nome de atributo ou nome de operação.
10. (ESAF - 2010 – MPOG – Analista de Sistemas Na UML – Unified Modelling

Language:
a) um atributo representa operações entre objetos.

b) um atributo representa informações sobre um objeto.
c) um atributo possui várias classes.
d) não existem atributos não numéricos.
e) atributos são classes abstratas.16712855225
11. (ESAF - 2012 – CGU – Analista de Sistemas Uma associação em UML representa:
a) uma população variada de relações (engagements) de redundâncias entre

instâncias de classe.
b) uma população variada de vínculos (links) de relacionamentos entre instâncias

de classe.
c) uma classificação de vínculos (links) de relacionamentos entre classes de

atributos.

d) uma população constante de valores (values) de relacionamentos

quantitativos entre atributos de instâncias.
e) uma estrutura de equivalências (equal features) entre relacionamentos de

instâncias de posicionamento de classes.
12. (ESAF - 2012 – CGU – Analista de Sistemas Quanto ao uso de diagramas na UML
para a modelagem de objetos é correto afirmar que o Diagrama de Seqüência:
a) descreve a funcionalidade do sistema percebida por atores externos.
b) apresenta a interação de seqüência de tempo dos objetos que participam na

interação.
c) apresenta a interação de seqüência de atores que participam na interação.
d) descreve a funcionalidade do sistema percebida por atores internos.
e) apresenta a interação de seqüência estática de pacotes, relacionamentos e

instâncias.
13. (FGV – – Senado Federal – Analista de Sistemas) Considere o caso de uso

ilustrado na figura utilizando a notação UML.
16712855225
A descrição do cenário que melhor descreve esse caso de uso é:
a) o atendente verifica o histórico dos pacientes que possuem consultas

agendadas.
b) um paciente liga para a clínica para marcar uma consulta. A atendente verifica
o histórico do paciente, busca um horário vazio e agenda a consulta.
c) o atendente inclui os pacientes que têm consulta agendada e não possuem

um histórico de atendimento.

d) o paciente liga para a clínica para agendar uma consulta e para alterar o seu
histórico.
e) o atendente não marca consultas para pacientes que não tenham histórico na
clínica.
14. (FGV – – Senado Federal – Analista de Sistemas) Uma série de modelos

pode ser produzida durante um projeto orientado a objetos. O projeto inclui
modelos estáticos e dinâmicos.
Um modelo que é considerado dinâmico é o de:
a) seqüência.
b) classe.
c) associação.
d) contexto.
e) generalização.
15. (FGV – 2015 – ANA – Analista de Sistemas) João está preparando uma palestra
sobre diagramas de classe da UML, e criou um slide com a figura:
O título correto para esse slide deve ser “Relacionamento de”:
a) agregação;
b) correspondência; 16712855225
c) dependência;
d) especialização;
e) generalização.
16. (FGV – 2015 – AL – Analista de Sistemas) Linguagens gráficas de modelagem são

úteis para descrever e especificar sistemas computacionais porque oferecem
notações próprias para representar conceitos e características estruturais e
comportamentais do projeto de software.

Assinale a opção que indica o diagrama da UML recomendado para modelar

característica comportamental com ênfase nos vínculos entre os vários objetos
de um projeto de software.
a) Diagrama de objetos.
b) Diagrama de componentes.
c) Diagrama de implantação.
d) Diagrama de comunicação.
e) Diagrama de classes.
17. (FGV – 2015 – TJ/RO – Analista de Sistemas) O diagrama da UML mais adequado
para representar o comportamento de vários objetos dentro de um único caso
de uso, de modo a evidenciar como esses objetos colaboram em algum
comportamento ao longo do tempo, é o diagrama de:
a) estruturas compostas;
b) objetos;
c) componentes;
d) tempo;
e) sequência.
18. (FGV – 2015 – Fiscal de Niterói – Analista de Sistemas) A UML (Unified Modeling
Language) estabelece uma série de artefatos que auxiliam desenvolvedores de
sistemas a modelar e documentar seu trabalho. A funcionalidade de um sistema,
do ponto de vista dos seus usuários, é representada pelo Diagrama de:
a) atividade;
b) casos de uso;
c) classes; 16712855225
d) estado;
e) sequência.
19. (FGV - 2015 – PGE/RO - Análise de Sistemas) NÃO é um diagrama utilizado pela
UML 2.0:
a) Diagrama de casos de uso.

b) Diagrama de classes.
c) Diagrama de objetos.
d) Diagrama de blocos múltiplos.

e) Diagrama de sequência.
(FGV - – MEC - Análise de Sistemas) Na UML o diagrama que descreve

uma sequência de ações que representam um cenário principal e cenários
alternativos, com o objetivo de demonstrar o comportamento de um sistema,
por meio de interações com atores, é o diagrama de:
b) Caso de Uso.
c) Implantação.
d) Atividades.
e) Pacotes.
21. (FGV - 2009 – MEC - Análise de Sistemas) A UML (Unified Modeling Language)
possui vários tipos de diagramas que em conjunto são utilizados para descrever
a visão estática e dinâmica de um sistema. Assinale a alternativa em que todos
os diagramas listados descrevem uma visão dinâmica de um sistema.
a) Classes, Objetos, Implantação e Pacotes.

b) Classes, Objetos, Casos de Uso e Sequência.
c) Implantação, Pacotes, Sequência e Atividades.
d) Implantação, Pacotes, Casos de Uso e Atividades.
e) Casos de Uso, Sequência, Visão Geral e Atividades.
16712855225
GABARITO DOS EXERCÍCIOS COMENTADOS (CESPE)


1 2 3 4 5 6 7 8 9 10
E E C E E E C C E E
11 12 13 14 15 16 17 18 19 20
E E C C C E E C E E
21 22 23 24 25 26 27 28 29 30
E E C C E E C C C E
31 32 33 34 35 36 37 38 39 40
C C E E E C E C C E
41 42 43 44 45 46 47 48 49 50
C E E C E E E C E E
51 52 53 54 55 56 57 58 59 60
E C E C E C C E C C
61 62 63 64 65 66 67 68 69 70
E E C C E C E C C E
71 72 73 74 75 76 77 78 79 80
E E C E C E C C E E
81 82 83 84 85 86 87 88 89 90
E E E C C C E C C C
91 92 93 94 95 96 97 98 99 100
C E E C C C C C C E
101 102 103 104 105 106 107 108 109 110
E E E E C E C C E E
111 112 113 114 115 116 117 118 119 120
E E E E E E E E C C
16712855225
GABARITO DOS EXERCÍCIOS COMENTADOS (FCC)

1 2 3 4 5 6 7 8 9 10
A C C B E E B D D E
11 12 13 14 15 16 17 18 19 20
D A E A D A C D B D
21 22 23 24 25 26 27 28 29 30
A E D B E A C E A B
31 32 33 34 35 36 37 38 39 40

D B A E E D A B D C
41 42 43 44 45 46 47 48 49 50
E B B B A E E C A C
51 52 53 54 55 56 57 58 59 60
A A A E D E E C A E
61 62 63 64 65 66 67 68 69 70
E D C A D E C A D C
71 72 73 74 75 76 77 78 79 80
A E E A A A D B D D
81 82 83 84 85 86 87 88 89 90
E B D A C B E C A C
91 92 93 94 95 96 97 98 99 100
C A B D E E D E C E
GABARITO DOS EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)

1 2 3 4 5 6 7 8 9 10
A E C E D D E D A B
11 12 13 14 15 16 17 18 19 20
B B B A A D E B D B
21 22 23 24 25 26 27 28 29 30
B
16712855225

Aula 05: Engenharia de Software para Concursos - Curso Regular

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Aula 05: Engenharia de Software para Concursos - Curso Regular

Transféré par

Droits d'auteur :

Formats disponibles

Aula 05

Engenharia de Software para Concursos - Curso Regular

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 1 de 231

Engenharia de Software. Conceitos Básicos ou Gerais. Ciclo de vida do software. Modelos,

Teste de Integração; Teste de Aceitação, Validação, Release; Teste de Sistema/Funcional). Tipos de

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 2 de 231

UML: VISÃO GERAL, MODELOS E DIAGRAMAS

Rumbaugh era o criador da Técnica de Modelagem de Objetos (TMO). Já Booch

Naquela época, os fornecedores estavam com medo de que um padrão controlado

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 3 de 231

responsável por estabelecer padrões que suportem interoperabilidade – a tomar

Essa consolidação surgiu por meio de intensas discussões com representantes de

Com o passar do tempo, a linguagem passou a integrar conceitos de diversos outros

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 4 de 231

A UML é intencionalmente independente de processos, i.e., pode ser aplicada no

Pensem em como seria especificar um sistema só escrevendo ou falando! Já

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 5 de 231

C, Cobol, Pascal, etc. É independente de linguagem de programação, ferramentas,

Na UML, existe a definição de uma linguagem formal utilizada para especificar as

 Infraestrutura da UML: especificação que contém o core da arquitetura, perfis

 Superestrutura da UML: especificação que contém os elementos de

 Object Constraint Language (OCL): especificação que contém a linguagem

 Intercâmbio: especificação que contém formatos de intercâmbio de

 Estereótipo: mecanismo utilizado para estender o significado de determinado

 Notas Explicativas: mecanismo utilizado para definir informação que comenta

 Tagged Values: mecanismo utilizado para predefinir propriedades para

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 6 de 231

 Restrições: mecanismo utilizado para especificar restrições sobre um ou mais

 Pacotes: mecanismo utilizado para agrupar elementos semanticamente

Estereótipos permitem adaptar ou personalizar modelos com construções

Estereótipos predefinidos já vêm nativamente na linguagem (Ex: <<interface>>,

Os estereótipos gráficos são representados por um ícone que lembre o significado

Rapaziada, vamos resumir o que vimos! Estereótipo é um mecanismo de uso geral

Pode ser classificado também em estereótipos textuais e gráficos: os primeiros

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 7 de 231

O conteúdo da nota é inserido no interior do retângulo e este é ligado ao elemento

Elementos UML possuem propriedades predefinidas! As classes, por exemplo,

Esse mecanismo geral especifica restrições sobre um ou mais valores de um ou mais

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 8 de 231

Na década de 90, a arquitetura de software padecia de alguns problemas graves.

Este artigo propunha organizar a descrição da arquitetura de software usand

 Visão Lógica (de Projeto): é a visão da arquitetura do sistema sob o ponto de

 Visão de Desenvolvimento (ou Implementação): é a visão da arquitetura do

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 9 de 231

estática dos módulos que formam o software. Principais diagramas utilizados:

 Visão de Processo: é a visão da arquitetura do sistema sob o ponto de vista do

 Visão Física (ou Implantação): é a visão da arquitetura do sistema sob o ponto

 Visão de Casos de Uso (Cenários): é a visão da arquitetura do sistema sob o

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 10 de 231

Diagramas Estruturais: representam aspectos estáticos do sistema sob diversas

Diagramas Comportamentais: representam aspectos dinâmicos do sistema como

 Diagramas de Interação: são diagramas comportamentais que consideram o

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 11 de 231

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 12 de 231

Esse é facilmente o diagrama mais conhecido de todos! Ele descreve as classes

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 13 de 231

pacote ao qual pertence separado por duplo dois-pontos (Ex:

Mas só existe uma forma de representar classes? Não! Pode-se representar de

Galera, agora vamos responder a algumas perguntas relevantes. Professor, como se

MODIFICADOR CLASSE SUBCLASSE PACOTE TODOS

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 14 de 231

E como se representa a visibilidade de atributos e operações? A tabela acima