Vous êtes sur la page 1sur 232

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


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 2 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 3 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 4 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 5 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 6 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

 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?

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 7 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 8 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 9 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 10 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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,
Comunicação, Interação Geral e Tempo.

16712855225

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 11 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 12 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 13 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 14 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 15 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 16 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 17 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 18 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 19 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 20 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 21 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 22 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 23 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 24 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 25 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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!

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 26 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 27 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

16712855225

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 28 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 29 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 30 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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>>.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 31 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 32 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 33 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 34 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 35 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 36 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 37 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 38 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 39 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 40 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 41 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 42 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 43 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 44 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 45 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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!

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 46 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 47 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 48 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 49 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 50 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 51 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 52 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

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


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!

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 53 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 54 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 55 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 56 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 57 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 58 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 59 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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:

Perfeito, é exatamente isso!

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 60 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 61 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 62 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

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


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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 63 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 64 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 65 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 66 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 67 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 68 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 69 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 70 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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:

Perfeito, é exatamente isso!

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:

Perfeito, é exatamente isso!

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 71 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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!

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 72 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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!

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 73 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 74 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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:

Perfeito, é exatamente isso!

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 75 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

73. (CESPE – 2010 – TER-BA – Técnico Judiciário – Programação de Sistemas) Um


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

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
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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 76 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

75. (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>>.

mentários:

Questão perfeita! Casos de Uso estendidos são opcionais, portanto podem não
gerar um diagrama de sequência.

Gabarito: C

76. (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
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: 16712855225

Perfeito, é exatamente isso!

Gabarito: C

78. (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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 77 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Gabarito: C

79. (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.

Gabarito: E

(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

81. (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.
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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 78 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 79 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

84. (CESPE - 2011 - BRB - Analista de Tecnologia da Informação) O diagrama de


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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 80 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

Perfeito, é exatamente isso!

Gabarito: C

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


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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 81 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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:

Perfeito, é exatamente isso!

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 82 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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...

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 83 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

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


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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 84 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Comentários: 16712855225

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 85 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

Perfeito, é exatamente isso!

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 86 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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!

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 87 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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
que cooperam entre si para uma função específica; o diagrama de máquina de

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 88 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

115. (CESPE - 2013 - ANCINE – Analista de Sistemas) Com relação à UML 2.0, o
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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 89 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 90 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 91 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

MODIFICADOR CLASSE SUBCLASSE PACOTE TODOS


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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 92 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 93 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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


determinado momento.

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 é,

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 94 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

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.

(a) Diagrama de Implantação; (b) Perfeito; (c) Diagrama de Estrutura Composta; (d)
Diagrama de Tempo; (e) Diagrama de Máquina de Estados.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 95 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

O Diagrama de Perfil permite representar esses novos elementos, operando no nível


16712855225

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?
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>>.

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 96 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 97 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

MODIFICADOR CLASSE SUBCLASSE PACOTE TODOS


UML PÚBLICO + X X X X

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 98 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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,
Comunicação, Interação Geral e Tempo.

Conforme vimos em aula, são Diagramas Comportamentais: Sequência, Casos de


Uso e Atividade.

Gabarito: D

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 99 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

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,
Comunicação, Interação Geral e Tempo.

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 100 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 101 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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,
Comunicação, Interação Geral e Tempo.

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:

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

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,
Comunicação, Interação Geral e Tempo.

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


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

Gabarito: E

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 102 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

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 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,
Comunicação, Interação Geral e Tempo.

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 103 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

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,
Comunicação, Interação Geral e Tempo.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 104 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

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.

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 105 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

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


diferentes. Em outras palavras, esses diagramas apresentam a estrutura do sistema
16712855225

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 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,
Comunicação, Interação Geral e Tempo.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 106 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 107 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

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

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.

Conforme vimos em aula, essa notação representa um estereótipo.

Gabarito: E

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 108 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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:

MODIFICADOR CLASSE SUBCLASSE PACOTE TODOS


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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 109 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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!

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:

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

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,
Comunicação, Interação Geral e Tempo.

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


(C); e Comunicação (C).

Gabarito: E

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 110 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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
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”.

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:

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!

Conforme vimos em aula, deve vir em itálico.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 111 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

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.

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 112 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

 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.

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:

MODIFICADOR CLASSE SUBCLASSE PACOTE TODOS


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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 113 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

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.

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:

 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,
Comunicação, Interação Geral e Tempo.

Conforme vimos em aula, o Diagrama de Implantação (Deployment) não é um


Diagrama de Interação.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 114 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

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 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,
Comunicação, Interação Geral e Tempo.

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 115 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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
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”.

Conforme vimos em aula, trata-se da Generalização/Especialização (Herança).

Gabarito: E

(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:

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”.
16712855225

Conforme vimos em aula, trata-se da Generalização/Especialização (Herança).

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 116 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

d) Composição
e) Herança.

Comentários:

 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.

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:

Diagramas Comportamentais: representam aspectos dinâmicos do sistema como um


conjunto de mudanças no tempo. Podemos dizer em outras palavras que esses
16712855225

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,
Comunicação, Interação Geral e Tempo.

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 117 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Conforme vimos em aula, trata-se do Diagrama de Objetos.

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:

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 118 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

Conforme vimos em aula, trata-se do Diagrama de Casos de Uso.

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:

 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,
Comunicação, Interação Geral e Tempo.

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 119 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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
linguagem de programação.

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


visualização dos blocos de construção da UML e representam graficamente um
conjunto de elementos, além de permitir a visualização do sistema sob diferentes
perspectivas. Essa é a definição de:

a) Relacionamentos.
b) Diagrama.
c) Eventos.
d) Classes.
e) Objetos.

Comentários:

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
linguagem de programação.
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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 120 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

b) atividades.
c) objetos.
d) entidades.
e) composição.

Comentários:

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,
Comunicação, Interação Geral e Tempo.

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

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.

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

Gabarito: B

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 121 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

 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.

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 122 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 123 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

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.

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 124 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

e) modularização.

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
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”.

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 125 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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!

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:

MODIFICADOR CLASSE SUBCLASSE PACOTE TODOS


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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 126 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

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.

Conforme vimos em aula, trata-se do Diagrama de Objetos.

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:

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


uma especialização da superclasse ou que a superclasse é uma generalização d
subclasse. Qualquer instância da subclasse é também uma instância da superclasse.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 127 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

É conhecido como relacionamento de herança, relacionamento de extensão ou


relacionamento “é-um”.

Conforme vimos em aula, trata-se da Generalização/Especialização (Herança).

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:

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,
Comunicação, Interação Geral e Tempo.

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:

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


diferentes. Em outras palavras, esses diagramas apresentam a estrutura do sistema

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 128 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

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:

MODIFICADOR CLASSE SUBCLASSE PACOTE TODOS


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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 129 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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


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

Comentários:

 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.

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 130 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 131 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

Comentários:

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.

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

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 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,
Comunicação, Interação Geral e Tempo.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 132 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

MODIFICADOR CLASSE SUBCLASSE PACOTE TODOS


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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 133 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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:

MODIFICADOR CLASSE SUBCLASSE PACOTE TODOS


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>>.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 134 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

Comentários:

 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 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:

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
16712855225

Composta e Pacotes.

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,
Comunicação, Interação Geral e Tempo.

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


comportamento e Componente é estrutural.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 135 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

MODIFICADOR CLASSE SUBCLASSE PACOTE TODOS


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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 136 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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,
Comunicação, Interação Geral e Tempo.

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.
e) Composite Structure e Deployment.

Comentários:

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,
Comunicação, Interação Geral e Tempo.

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 137 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

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
16712855225

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.

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

Gabarito: E

73. (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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 138 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

a) Objetos.
b) Atividades.
c) Comunicação.
d) Máquina de Estados.
e) Seqüência.

Comentários:

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.

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

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.

Comentários: 16712855225

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 139 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 140 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

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?
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>>.

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 141 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Comentários:

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.

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 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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 142 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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 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:

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.
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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 143 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

É 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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 144 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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:

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 145 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

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
16712855225

que é uma atividade? É um comportamento parametrizado representado como um


fluxo coordenado de ações.

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 146 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

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.

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 147 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

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,
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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 148 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

 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.

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 149 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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:

MODIFICADOR CLASSE SUBCLASSE PACOTE TODOS


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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 150 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 151 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

c) include - generalização - extend.


d) derived - generalization - added.
e) extend - generalização - include.

Comentários:

 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 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
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.

(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 #

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 152 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Comentários:

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!

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 153 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

 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,
Comunicação, Interação Geral e Tempo.

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.

Comentários: 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.

Conforme vimos em aula, são relacionamentos de dependência. Bastava lembrar da


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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 154 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 155 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

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:

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
16712855225

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 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,
Comunicação, Interação Geral e Tempo.

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


estrutural e um comportamento é: Pacote e Atividade.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 156 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

MODIFICADOR CLASSE SUBCLASSE PACOTE TODOS


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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 157 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

e) Dependência.

mentários:

 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.

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.
d) agregação não composta.
e) agregação por composição.

mentários:

 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
16712855225

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.

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 158 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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):

Conforme vimos em aula, trata-se do Diagrama de Casos de Uso.

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.

Comentários: 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.

Conforme vimos em aula, são relacionamentos de dependência.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 159 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

Gabarito: E

ACERTEI ERREI

16712855225

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 160 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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:

Perfeito, é exatamente isso!

Gabarito: C

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 161 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 162 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 163 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 164 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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).

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 165 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

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.

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 é:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 166 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 167 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 168 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 169 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 170 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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


por meio de interações com atores, é o diagrama de:

a) Máquina de Estados.
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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 171 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 172 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

(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.

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


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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 173 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 174 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 175 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 176 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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.

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 177 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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.

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


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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 178 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 179 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

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.

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 180 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 181 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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.

64. (CESPE – 2010 – TER-BA – Técnico Judiciário – Programação de Sistemas) Um


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.
16712855225

(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.

(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>>.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 182 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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
sistema de acordo com a participação dos atores do modelo.

(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.

(CESPE – – IE/MA – Análise de Sistemas) Ator é uma entidade – pessoa ou


sistema –, com comportamento, que interage com o sistema que se está
projetando.

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.

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.

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.

73. (CESPE – 2010 – TER-BA – Técnico Judiciário – Programação de Sistemas) Um


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,
16712855225

que descrevem atores usando um sistema como meio para atingir um objetivo.

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 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.

75. (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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 183 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

um diagrama de sequência, a exemplo do que ocorre com os de tipo


<<extend>>.

76. (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
sistema de acordo com a participação dos atores do modelo.

(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.

78. (CESPE – – IE/MA – Análise de Sistemas) Ator é uma entidade – pessoa ou


sistema –, com comportamento, que interage com o sistema que se está
projetando.

79. (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.

(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.

81. (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.

(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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 184 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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


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.

84. (CESPE - 2011 - BRB - Analista de Tecnologia da Informação) O diagrama de


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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 185 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

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


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.

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


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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 186 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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.

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


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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 187 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

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.

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 188 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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
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.

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.

115. (CESPE - 2013 - ANCINE – Analista de Sistemas) Com relação à UML 2.0, o
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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 189 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 190 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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


determinado momento.

(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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 191 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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”.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 192 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

a) Máquina de Estados.
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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 193 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 194 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 195 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 196 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 197 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 198 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

c) agregação composta.
d) agregação nã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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 199 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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


superclasses (classesmãe) e subclasses (classes-filha), é uma:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 200 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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


superclasses (classesmãe) e subclasses (classes-filha), é uma:

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 201 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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


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.

42. (FCC - 0 – TRT/20 - Análise de Sistemas São os meios utilizados para a


visualização dos blocos de construção da UML e representam graficamente um

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 202 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

conjunto de elementos, além de permitir a visualização do sistema sob diferentes


perspectivas. Essa é a definição de:

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 203 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 204 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 205 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.
e) Composite Structure e Deployment.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 206 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 207 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 208 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 209 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.
e) Composite Structure e Deployment.

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 210 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

73. (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.

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 211 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

É 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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 212 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 213 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 214 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 215 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 216 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

- 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)

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 217 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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 << >>.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 218 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 219 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 220 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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.
d) agregação não composta.
e) agregação por composição.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 221 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

(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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 222 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

LISTA DE EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)


UNIFIED MODELING LANGUAGE (UML)

(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:

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 223 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 224 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 225 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 226 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 227 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 228 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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:

a) Máquina de Estados.
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)

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 229 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

UNIFIED MODELING LANGUAGE (UML)


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)


UNIFIED MODELING LANGUAGE (UML)
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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 230 de 231


Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 05

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)


UNIFIED MODELING LANGUAGE (UML)
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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 231 de 231