Engenharia de Software

Curso Regular de Engenharia de Software
Prof. Diego Carvalho – Aula 05
U L: 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 ngenharia e oftware is
proeminentes do ndo: 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 guia seus métodos e
técnicas de odelagem ró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 e moderna tecnologia de Orientação a Objetos
estava demorando tanto para ser adotada de fato? A resposta foi, entre outras, que
havia xcesso de guagens de delagem.
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 inguagem de odelagem 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. 4 de 220

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 mo adrão rnacional chamado
ISO/IEC 19501:2005.
Observem que a ntou com articipação de outras empresas (IBM, HP,

Oracle, etc). Sendo assim, a OMG adotou a versão 1.1 como um padrão oficial! A
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é alcançar idade s iciente ara vançar té rsão UML .0, em meados
de 2005. A partir de então, passou por diversas e pequenas atualizações até chegar
à versão atual: UML 2.4.1.

A UML pode ser definida como uma linguagem gráfica ara specificar, visualizar,
construir documentar artefatos primariamente e ma de oftware. 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 L ã está itada delagem de ftware. 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 efinem como a guagem padrão e delagem visual usada ara

modelagem de gócio e rocessos similares; além a nálise, projeto
implementação de istemas baseados m 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 ncionalmente dependente e rocessos, i.e., pode r plicada

contexto e rocessos diferentes Ex: ). 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 onta da omunicação
e o ntendimento. 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.
Pensem em como seria especificar um sistema só escrevendo ou falando! Já

imaginaram a quantidade de ambiguidades? A linguagem natural é s ples emais!
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

 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 m miúdos, é canismo de xtensão que dá s poder
flexibilidade L. 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 locar
nome o lemento delimitado pelos bolos >. Além disso, os estereótipos
podem ser definidos textualmente ou graficamente.
Os estereótipos ráficos ão epresentados or o e ue bre o s nificado

do nceito ao qual ele está ssociado. 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?
Rapaziada, vamos resumir o que vimos! Estereótipo é um mecanismo de uso geral

utilizado para aumentar as capacidades da Linguagem UML! Ora, antes era o
muito do, agora u tenho itas possibilidades para epresentar ma.
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 é ossível ter stereótipos gráficos ou textuais sendo
predefinidos ou definidos pela quipe e esenvolvimento. Ficou claro agora?

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 xageradamente só specto o esenvolvimento de
software , outras vezes, a rquitetura ão se irecionava aos interesses de odos
os interessados. Então, em 1995, Philippe Kruchten publicou um artigo buscando
solucionar essa questão.
Este artigo propunha organizar escrição a rquitetura e ftware do

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.
 Visão ógica (de ojeto): é 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 D senvolvimento ou Implementação): é a visão da arquitetura do

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

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

Componentes.
 Visão e ocesso: é 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 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 e Casos de 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 delagem Orientada a bjetos ocorre uase que sempre or io da

Unified deling anguage (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:

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 ara s estruturais e a ara s 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.

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 ai bastante m prova! demos ver xemplo abaixo:
Pessoal, agora vamos falar sobre os tipos de relacionamentos em um diagrama e

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...
Relacionamento e pendência: é um relacionamento direcionado e semântico

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

Um componente ode presentar um stereótipo, i.e., uma definição o ue ste

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 nterface o necida, que designa uma interface ue o próprio

componente ossui 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 ponentes? Use Diagramas de Componentes

quando você estiver dividindo seu sistema em componentes e quiser representar
seus relacionamentos por rmédio de rfaces ou também quando uiser
representar ecomposição e omponentes em uma strutura de l mais baixo.
Entendido, galera? Exercícios!

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

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

de um metamodelo. Já uma metaclasse é uma classe que pode ser estendida por
meio de um ou mais estereótipos. Trata-se de u a sse o etamodelo (classe,
interface, componente, associação, etc).
Em outras palavras, estereótipos podem ser plicados a lementos em um D grama

UML. Resumindo: um metamodelo é um modelo que modela outro modelo. A UML
é um metamodelo no sentido de que ela possui diversos diagramas capazes de
modelar a própria linguagem. Já uma metaclasse é uma classe capaz de especificar
características comuns de várias outras classes.

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 astante s ro m vocês, té oje esse diagrama o
emplacou e, verdade, sempre uve essa úvida ntre s membros do mitê
organizador a L.

Professor, eu pensava que um ator só podia ser um humano. Pois é, não é assim! Ele
pode r mano, uma quina u outro ma a raçã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 so de nta u a ria bre mo ário final interage m

sistema sob conjunto de c nstâ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á C sos de s C ncretos e A stratos. O primeiro é iniciado por um ator e

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 ela dentificação e de rimários.

Quando aso e ncreto c ado, uma ância o aso de c iada.

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 e C municação: também amada e elacionamento de

associação, o tor omunica m o stema or io do nvio ecebimento
de ensagens. 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 e nclusã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, é elacionamento brigatório,
representado or u a a jada om uma ta ponta5.
Explicando de uma forma mais simples de entender: quando o caso de uso A

“inclui” o caso de uso B, significa que sempre sempre sempre sempre sempre
que o caso de uso A for executado o caso de uso B também será executado. A
5
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.

Esse permite epresentar o de da de bjetos e mo les ão fetados por

eventos como rros, mensagens e ndiçõ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 istinguir grama de A dades e rama de ina de dos.

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 é epresentado m cada iagrama xatamente o
oposto o utro.
Quando utilizar Diagramas de Máquina de tados? Eles são bons para descrever o
comportamento de um objeto por intermédio de vários casos de uso. No ntanto,
esses diagramas muito ons mesmo ara descrever mportamento ue
envolva s objetos em olaboraçã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 o zar ara das as classes, mas apenaspara quelas que
exibem comportamento ressante judem a ntender problema.

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 o iagrama e municação g ão ntre bjetos.
Quando utilizar o Diagrama e unicação? A principal questão m os

diagramas de municação quando usá-los m lugar os 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 do que les uma oa stratégia ara xplorar alternativas.

Quando utilizar os Diagramas de emporizaçã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á ouquíssimos exercícios sobre le credito que lvez seja
diagrama menos cobrado m provas.

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

mostrar o fluxo de controle.
Quando izar os Diagramas de nteraçã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 cordo om o
autor, desenhe agrama de A idades ou use u grama de Sequência,
dependendo do ue lhor tender u propósito.

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
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 - 010 NMETRO - A sta e Sistemas Em um diagrama de

componentes em UML 2.0 contendo um conjunto de componentes que
modelam a arquitetura de uma aplicação web em três camadas, se três desses
conjuntos, nomeados por C1, C2 e C3, forem diretamente relacionados entre si
e representarem um componente, respectivamente, da camada de apresentação
de aplicação, da camada de negócios e da camada de persistência, então uma
relação direcional consistente que representa as dependências entre esses
conjuntos será: C3 depende de C2 e C2 depende de C3.
Comentários:
De acordo com a questão, temos que: C1 representa a Camada de Apresentação,

C2 representa a Camada de Negócios e C3 representa a Camada de Persistência. A
questão afirma que C3 depende de C2 e que C2 depende de C3, isto é, a Camada
de Persistência depende da Camada de Negócio e a Camada de Negócio depende
da Camada de Persistência, mas isso está errado. A Camada de Negócio depende
- sim - da Camada de Persistência, porque é de lá que vêm os dados de que ela
necessita; no entanto, a Camada de Persistência não depende da Camada de
Negócio, ela é independente!
Gabarito: E

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 013 RT/17 - ista de istemas) 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.
Comentários:
Não! Isso é claramente Diagrama de Implantação e, não, Diagrama de Componente.
Gabarito: E
46. (CESPE - 010 B SA alista de ologia a nformação) O objetivo

principal de um diagrama de pacotes é agrupar os pacotes em classes. Esse tipo
de diagrama pode usar dependências.
Comentários:
Na verdade, está invertido! Ele agrupa classes (entre outros elementos) em pacotes.
Gabarito: E
47. (CESPE - 011 C PA - A lista e S mas 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 - 011 RB alista e ologia a nformaçã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
arquitetura de uma linguagem, como ocorre com a própria UML.
Gabarito: C
49. (CESPE - 010 B - O al Técnico De nteligência senvolvimento

Manutenção e mas) Um diagrama de implantação pode ser utilizado
quando o software é projetado para ser executado sobre uma única máquina
individual que não se comunica com outro hardware. A modelagem em conjunto
com diagramas de componentes, como ilustrado na figura a seguir, não é
possível na UML.
Comentários:
Bem, executar sobre uma única máquina individual não é o objetivo mais frequente,
mas nada impede que isso ocorra! Porém a modelagem é, sim, possível em conjunto
com diagramas de componentes.
Gabarito: E

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 011 lista e ologia a nformaçã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
75. (CESPE 010 BN al Técnico De nteligência – ea

Desenvolvimento Manutenção De S s mas) 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
76. (CESPE – 010 a sta/RR sta e S s emas) 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:

Perfeito, são ambos diagramas de interação (atualmente, Diagramas de

Colaboração são os Diagramas de Comunicação).
Gabarito: C
108. (CESPE - 010 R MT sta e temas D O diagrama de

comunicação enfatiza a ordem temporal de mensagens, que reagem a eventos
externos e internos.
Comentários:
Ordem temporal? Diagrama de Sequência!
Gabarito: E
109. (CESPE - 2011 C – A lista e mas) 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
110. (CESPE - 013 B C N ista de mas) 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

estado de um objeto, ao longo do tempo decorrente de eventos externos.
Comentários:
Diagrama de Interação Geral é uma variação do Diagrama de Atividade que fornece

uma visão ampla dentro de um sistema ou processo de negócio. Esse diagrama
passou a existir somente a partir da UML 2.0 e costuma englobar diversos tipos de
diagramas de interação para demonstrar um processo geral. O Diagrama de
Estrutura Composta é utilizado para modelar Colaborações. Uma colaboração
descreve uma visão de um conjunto de entidades cooperativas interpretadas por
instâncias que cooperam entre si para executar uma função específica. O termo
estrutura desse diagrama refere-se a uma composição de elementos
interconectados, representando instâncias de tempo de execução colaboram, por
meio de vínculos de comunicação, para atingir algum objetivo comum. Esse
diagrama também pode ser utilizado para definir a estrutura interna de um
classificador. Portanto, os conceitos estão invertidos.
Gabarito: E
117. (CESPE - 015 - ista ciá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 elacionamentos 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
118. (CESPE - 015 - Analista diciá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

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 - 010 NMETRO - A sta e Sistemas 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 - 010 E/MT - ista de i temas Um diagrama de

componentes é do tipo estrutural, e mostra partes internas, conectores e portas
que implementam um componente.
42. (CESPE 013 UB - A lista e mas) 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 - 013 – RPRO - alista e mas) 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 - 013 7 alista de temas) 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.
45. (CESPE 013 RT/17 - A ista e mas) 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 - 010 B SA lista e ologia a nformação) O objetivo

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

127. (CESPE – 017 S /DF alista e s mas) Em um diagrama de classes,

as associações entre os objetos refletem as necessidades de comunicação
definidas no diagrama de sequência e resumidas no diagrama de colaboração.
128. (CESPE 017 /DF alista de S s mas) Em um gráfico de classes UML,

um relacionamento de extensão (extend) é uma relação estrutural na qual um
caso de uso maior é estendido por um caso de uso menor, que inclui serviços
especiais no caso de uso maior.

Engenharia de Software

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Engenharia de Software

Uploaded by

Copyright:

Available Formats

Curso Regular de Engenharia de Software

Prof. Diego Carvalho – Aula 05

U L: VISÃO GERAL, MODELOS E DIAGRAMAS

Rumbaugh era o criador da Técnica de Modelagem de Objetos (TMO). Já Booch

Naquela época, os fornecedores estavam com medo de que um padrão controlado

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

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

Essa consolidação surgiu por meio de intensas discussões com representantes de

Observem que a ntou com articipação de outras empresas (IBM, HP,

Com o passar do tempo, a linguagem passou a integrar conceitos de diversos outros

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

Portanto, a L ã está itada delagem de ftware. Aliás, ela é uma

Alguns a efinem como a guagem padrão e delagem visual usada ara

A UML ncionalmente dependente e rocessos, i.e., pode r plicada

Pensem em como seria especificar um sistema só escrevendo ou falando! Já

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

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

 Pacotes: mecanismo utilizado para agrupar elementos semanticamente

Estereótipos permitem adaptar ou personalizar modelos com construções

Estereótipos predefinidos já vêm nativamente na linguagem (Ex: <<interface>>,

Os estereótipos ráficos ão epresentados or o e ue bre o s nificado

Rapaziada, vamos resumir o que vimos! Estereótipo é um mecanismo de uso geral

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

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

Na década de 90, a arquitetura de software padecia de alguns problemas graves.

Este artigo propunha organizar escrição a rquitetura e ftware do

 Visão ógica (de ojeto): é a visão da arquitetura do sistema sob o ponto de

 Visão de D senvolvimento ou Implementação): é a visão da arquitetura do

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

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

 Visão e ocesso: é a visão da arquitetura do sistema sob o ponto de vista do

 Visão sica ou Implantação): é a visão da arquitetura do sistema sob o ponto

 Visão e Casos de Cenários): é a visão da arquitetura do sistema sob o

Galera, a delagem Orientada a bjetos ocorre uase que sempre or io da

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

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

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

Pessoal, agora vamos falar sobre os tipos de relacionamentos em um diagrama e

Relacionamento e pendência: é um relacionamento direcionado e semântico

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

Um componente ode presentar um stereótipo, i.e., uma definição o ue ste

 Arquivo: determina que o componente é um arquivo de dados do sistema;

Temos, também, a nterface o necida, que designa uma interface ue o próprio

Quando utilizar Diagramas de ponentes? Use Diagramas de Componentes

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

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

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

Em outras palavras, estereótipos podem ser plicados a lementos em um D grama

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

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

Um so de nta u a ria bre mo ário final interage m

Há C sos de s C ncretos e A stratos. O primeiro é iniciado por um ator e

Há também Casos de Uso Primários e Secundários. O primeiro representa os

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

Quando aso e ncreto c ado, uma ância o aso de c iada.

 Relacionamento e C municação: também amada e elacionamento de

 Relacionamento e nclusão: utilizado quando um mesmo comportamento se

Explicando de uma forma mais simples de entender: quando o caso de uso A

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

Esse permite epresentar o de da de bjetos e mo les ão fetados por

É necessário istinguir grama de A dades e rama de ina de dos.

Os nós do Diagrama de Estados representam o que está nos arcos do Diagrama de

Por exemplo, os Diagramas de Interação são bons para descrever o comportamento

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