Aula02 - Análise e Projeto Orientados A Objetos. UML

Edited with the trial version of
Foxit Advanced PDF Editor

To remove this notice, visit:
www.foxitsoftware.com/shopping
Aula 02
Curso: Tecnologia da Informao p/ Caixa Econmica Federal (tpicos 8,9, 10, 11, 12 e
14)
Professor: Diego Carvalho

Tecnologia da Informao para Caixa Econmica Federal
Curso de Teoria e Exerccios CEF
Prof. Diego Carvalho Aula 02
AULA 02
SUMRIO PGINA
Introduo 01
UML: Viso Geral, Modelos e Diagramas 02
Anlise e Projeto Orientados a Objetos 26
Arquitetura em Trs Camadas 30
Mtricas e Estimativas de Software 32
Exerccios (50) 34
Lista de Questes Apresentadas 48
Gabarito 54
Ol, pessoal! Essa aula sobre UML, Anlise e Projeto, Arquiteturas e Mtricas de Software. Bem,
A aula bem tranquila, mas estou disponvel para qualquer auxlio. Bons estudos ;D
Engenharia de Software. Noes sobre: Modelagem de processos, Ciclo de vida do software. Metodologias de desenvolvimento de
software. Processo unificado: disciplinas, fases, papis e atividades. Metodologias geis Anlise e projeto orientados a objetos. UML:
viso geral, modelos e diagramas. Padres de projeto. Arquitetura em trs camadas. Arquitetura orientada a servios. Mtricas e
estimativas de software. Anlise por pontos de funo. Conceitos bsicos e aplicaes. Engenharia de requisitos. Conceitos bsicos.
Noes sobre: tcnicas de elicitao de requisitos, especificao de requisitos e tcnicas de validao de requisitos. Prototipao.
Interoperabilidade de sistemas, SOA e Web Services, Padres XML, XSLT, UDDI, WSDL e Soap. Testes de software: conceitos e
aplicaes. Testes unitrios, de integrao e de aceitao: conceitos e aplicaes. Desenvolvimento orientado a testes: conceitos e
aplicaes. Gerncia de configurao: conceitos e prticas. Uso de ferramentas de gerncia de configurao. Controle de defeitos:
conceitos e prticas. Portais corporativos: arquitetura da informao, portlets e RSS. Ferramentas de Gesto de Contedos. Modelo
de Acessibilidade do Governo Eletrnico.
01176992910
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 1 de 54

UML: VISO GERAL, MODELOS E DIAGRAMAS
Vamos resumir o contexto histrico! Havia uma empresa chamada Rational Software Corporation.
Sim, pessoal... aquela mesma criadora do RUP! Em 1995, ela conseguiu reunir trs dos
pesquisadores de engenharia de software mais proeminentes do mundo: James Rumbaugh, Grady
Booch e Ivar Jacobson conhecidos como The Three Amigos.
Figura 1 - Booch, Jacobson e Rumbaugh.
James Rumbaugh era o criador da Tcnica de Modelagem de Objetos (TMO). J Grady Booch era
o criador do mtodo de Projeto Orientado a Objetos (POO). Por fim, Ivar Jacobson era o criador
do mtodo de Engenharia de Software Orientada a Objetos (ESOO). Os trs trabalhavam para a
empresa, mas cada um seguia seus mtodos e tcnica de modelagem.
Alis, naquela poca no havia uma linguagem dominante. Havia diversas linguagens, cada uma
com vantagens e desvantagens. Foi a que a Rational resolveu fazer uma srie de estudos a respeito
de uma pergunta: por que a moderna tecnologia de orientao a objetos estava demorando tanto
para ser adotada? A resposta foi, entre outras, que havia um excesso de linguagens de modelagem.
Ora, ela no gostou da resposta e requisitou aos seus notveis pesquisadores que encontrassem
uma soluo! E o que os trs camaradas fizeram? Reuniram-se, consultaram outros pesquisadores,
consolidaram seus mtodos com as informaes obtidas e padronizaram tudo em uma linguagem
de modelagem comum e no-proprietria designada: Unified Modeling Language.
Essa consolidao surgiu por meio de intensas discusses com representantes de tecnologias
concorrentes que fizeram diversas recomendaes. A UML o resultado de vrios mtodos e vises
distintas de modelagem, como mostra a Figura 2. Enfim, em agosto de 1997, foi publicada a UML
01176992910
1.1 e, posteriormente, ela foi editada como um padro internacional chamado ISO/IEC 19501:2005.

Figura 2 Metodologias que consolidaram a UML.
Com o passar do tempo, a linguagem passou a integrar conceitos de diversos outros mtodos de
orientao a objetos. Ademais, corrigiu diversos bugs e inconsistncias at alcanar maturidade
suficiente para avanar at a verso UML 2.0, em meados de 2005. A partir de ento, passou por
diversas atualizaes at chegar verso atual: UML 2.4.1.
Pessoal, naquela poca os fornecedores de ferramentas estavam com medo de que um padro
controlado pela Rational desse uma vantagem competitiva desleal empresa. Assim, eles incitaram
a Object Management Group (OMG) consrcio de empresas formado para estabelecer padres
que suportem interoperabilidade a tomar partido dessa padronizao.
Lembremos que a UML tambm contou com a participao de outras empresas, como IBM, HP,
Oracle, Texas Instruments, etc. Assim sendo, a OMG adotou a verso 1.1 como um padro oficial. A
reviso 1.2 foi somente para melhorar as aparncias, j a 1.3 foi mais significativa. A reviso 1.4
acrescentou conceitos de componentes e perfis, e a reviso 1.5 adicionou semntica de ao.
A UML pode ser definida como uma linguagem grfica 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: telecomunicaes,
defesa, aeroespacial, bancria, eletrnica, financeira, entre outras.
01176992910
Portanto, a UML no est limitada a modelagem de software. Alis, ela uma linguagem to
expressiva que pode modelar outros sistemas, tais como um fluxograma do sistema judicirio, a
estrutura e comportamento de um sistema de sade pblica ou um projeto de hardware. Se alguma
prova disser que ela uma linguagem exclusiva de software, vocs j sabem o que marcar! =)
Ok, professor! Mas porque utilizar a UML? Bem, Martin Fowler diz que principalmente por conta
da comunicao e do entendimento. Um bom diagrama frequentemente pode ajudar uma equipe
a entender um problema e transmitir uma ideia. Alis, a notao grfica um meio termo entre a
impreciso da linguagem natural e o detalhamento excessivo de uma linguagem de programao.
Pensem em como seria especificar um sistema inteiro apenas escrevendo ou falando! J

imaginaram a quantidade de inconsistncias e ambiguidades? A linguagem natural simples

demais! Agora imaginem como seria especificar um sistema usando C++! J imaginaram a reao
do usurio ao ver 400 linhas de cdigo para entender uma classe? Cdigos detalham demais!
Bem, esse j seria um excelente motivo para se utilizar a UML. Ora, mas se resume a isso? No, ela
uma linguagem completamente no-dependente de tecnologia. Professor, isso quer dizer que
possvel usar UML com Linguagem Estruturada? Sim, pessoal! Pode-se usar com C, Cobol, Pascal,
etc. independente de linguagem de programao, ferramentas, entre outros.
Hoje em dia, ela se tornou no somente a notao grfica mais dominante dentro do mundo
orientado a objetos, como tambm uma tcnica popular nos crculos no orientados a objetos. Por
fim, cabe salientar que a UML uma verdadeira ferramenta de planejamento. Ela ajuda a apresentar
uma viso geral do sistema atual e futuro.
Na dcada de noventa, a arquitetura de software padecia de alguns problemas graves. Muitas

vezes, enfatizava-se exageradamente apenas um aspecto do desenvolvimento de software e,
outras vezes, a arquitetura no se direcionava aos interesses de todas as partes interessadas. Ento,
em 1995, Philippe Kruchten publicou um artigo buscando solucionar essa questo.
Este artigo propunha organizar a descrio da arquitetura de software usando diversas vises
concorrentes, cada uma direcionada a um conjunto de interesses especficos. Sabe-se que a
arquitetura de software lida com abstraes e, para descrev-la, o autor se utilizou de cinco vises
ou perspectivas principais, como mostra a Figura 3.
01176992910
Figura 3 - Viso 4+1.
Viso Lgica (de Projeto): a viso da arquitetura do sistema sob o ponto de vista dos
usurios finais, apresentando os requisitos funcionais do software que suportam a arquitetura
e fornecem servios. Diagramas utilizados: Classe, Objetos e Pacotes.
Viso de Desenvolvimento (ou Implementao): a viso da arquitetura do sistema sob o

ponto de vista do programador, apresentando a organizao esttica dos mdulos que
formam o software. Diagramas utilizados: Componentes.
Viso de Processo: a viso da arquitetura do sistema sob o ponto de vista do integrador,

apresentando requisitos no-funcionais o software (Desempenho, Escalabilidade, etc).
Diagramas utilizados: Sequncia, Colaborao, Mquina de Estados e Atividade.

Viso Fsica (ou Implantao): a viso da arquitetura do sistema sob o ponto de vista do
engenheiro de sistema, apresentando a topologia ou distribuio fsica dos componentes.
Diagramas utilizados: Implantao e Componentes.
Viso de Casos de Uso (Cenrios): a viso da arquitetura do sistema sob o ponto de vista
de todos os usurios das outras vises e avaliadores, apresentando a consistncia e validade
do sistema. 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 so capazes de modelar
sistemas orientados a objetos e ns veremos um por um cada um dos catorze! Ateno nesse
assunto! A UML 2.2 descreve 14 tipos de diagramas oficiais como mostra a Figura 4:
Figura 4 - Diagramas da UML 2.2.
01176992910
Diagramas Estruturais: representam aspectos estticos do sistema sob diversas vises

diferentes. Em outras palavras, esses diagramas mostram a estrutura do sistema inalterada h
qualquer momento por no levarem em considerao o tempo em sua representao.
Diagramas Comportamentais: representam aspectos dinmicos do sistema como um conjunto

de mudanas no tempo. Em outras palavras, esses diagramas mostram como os processos do
programa se relacionam com o passar do tempo.
o Diagramas de Interao: so diagramas comportamentais que consideram o

relacionamento dinmico entre os objetos do sistema.
IMPORTANTE
Infelizmente, esses conceitos devem ser memorizados. Decorem o nome de todos os diagramas, respondendo quais
so estruturais,
Prof. comportamentais e dewww.estrategiaconcursos.com.br
Diego Carvalho interao! Faam isso nem que vocs tenham que tatuar o nome
Pg.de5cada um.
de 54
Decorem! Decorem! Decorem! Decorem! Decorem!
Professor, mas eu estou exausto de decorar coisas! Pessoal, eu vou dizer o que me ajudou um pouco
na hora de memorizar! Eu decorei o seguinte mnemnico: CPI CPI MST E COCA! Ele contm a letra
inicial de cada diagrama. A partir da, eu fiquei tentando lembrar o nome de todos os diagramas
incansavelmente at decorar (Ateno: a Letra E faz parte do mnemnico!).
CPI
CPI
MST E
01176992910

DIAGRAMAS ESTRUTURAIS
Diagrama de Classes:
Esse facilmente o diagrama mais conhecido de todos! Ele descreve as classes presentes no sistema
e os vrios tipos de relacionamentos estticos entre seus objetos. Representam-se tambm as
propriedades e as operaes de uma classe, assim como as restries que se aplicam maneira
como os objetos esto conectados.
Professor, o que uma classe? Classe uma estrutura que abstrai um conjunto de objetos com
caractersticas similares. Ela define, tambm, o comportamento de seus objetos atravs de mtodos
e os estados possveis destes objetos por meio de atributos. A Figura 5 apresenta as partes que
formam uma classe denominada Pessoa:
Figura 5 - Partes de uma Classe.
Mas s existe uma forma de representar classes? No! Pode-se representar de diversas formas. A
Figura 6 apresenta maneiras distintas de se representar uma classe: primeiro, apenas com nome da
classe; segundo, com nome da classe e suas propriedades (atributos); e terceiro, com nome da
classe, propriedades (atributos) e operaes.
01176992910
Figura 6 - Formas de representao de classes.
Professor, eu posso inserir detalhes de implementao da linguagem de programao que eu escolhi?

Sim, como na classe da Figura 6! Professor, e essa ltima classe estranha da Figura 6? Ela realmente
um pouco diferente! Essa a representao de uma Classe Ativa, que tem por objetivo
representar classes cujos objetos tm um ou mais processos/threads.
Vamos responder a algumas perguntas relevantes. Professor, como se representa um atributo

esttico na UML? Basta sublinhar o nome do atributo! Professor, como se representa uma operao
abstrata? Basta escrever seu nome em itlico! E como se representa uma operao esttica? Basta
escrever seu nome sublinhado!

Professor, e como se representa a visibilidade de atributos e operaes? Bem, a Tabela 1 mostra a
diferena entre a representao de visibilidade em JAVA e UML. Observem que h duas diferenas
sutis: na UML, um elemento protegido no visvel para elementos dentro do mesmo pacote; e o
nvel Pacote da UML tem o mesmo nome do nvel Default em JAVA! Pessoal, isso cai em prova!
Modificador Classe Subclasse Pacote Todos

UML: + Pblico X X X X
UML: # Protegido X X
UML: ~ Pacote X X
UML: - Privado X
JAVA: + Pblico X X X X
JAVA: # Protegido X X X
JAVA: ~ Default X X
JAVA: - ivado X
Tabela 1 - Comparao JAVA x UML
Pessoal, agora vamos falar sobre os tipos de relacionamentos em um diagrama de classes. Eles
representam as conexes entre classes, objetos, pacotes, tabelas, entre outros. H trs tipos de
relacionamentos entre classes: Dependncia, Generalizao e Associao. No entanto, eles se
desdobram em outros, como mostra a Figura 7.
01176992910
Figura 7 - Relacionamentos da UML.
Relacionamento de Dependncia: uma relao semntica entre dois ou mais elementos que
ocorre se mudanas na definio de um elemento (independente) causarem mudanas ao outro
elemento (dependente). Em outras palavras, quando a classe cliente dependente de algu
servio da classe fornecedora, como mostra a Figura 8.

Figura 8 - Relacionamento de Dependncia.
esquerda, uma Classe Login depende de uma Interface Base de Dados. Como assim, professor?
O diagrama esquerda indica que a Classe Login utiliza algum mtodo da Interface Base de Dados,
portanto caso esse mtodo 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 mtodo da Classe Item. Portanto, caso se modifique um
mtodo da Classe Item, pode haver danos na classe dependente, que a Classe Pedido. Logo,
Pedido a classe dependente e Item a classe independente.
IMPORTANTE
Observem que o Relacionamento de Dependncia representado por uma seta tracejada que aponta para classe
independente. Em outras palavras, a Classe Pedido depende da Classe Item.
Relacionamento de Generalizao/Especializao: indica que a subclasse uma especializao da

superclasse ou que a superclasse uma generalizao da subclasse. Qualquer instncia da
subclasse tambm uma instncia da superclasse. tambm conhecido como relacionamento de
01176992910
herana, relacionamento de extenso ou relacionamento -um.

Figura 9 - Relacionamento de Generalizao.
Observem que a Figura 9 apresenta um relacionamento em que Fruta uma generalizao de

Laranja, assim como Laranja uma generalizao de Laranja Lima e Laranja Pra. Tudo isso pode
ser dito em termos de especializao: Laranja Lima e Laranja Pra so especializaes de Laranja,
assim como Laranja uma especializao de Fruta.
IMPORTANTE
Observem que o Relacionamento de Generalizao/Especializao representado por uma linha com um tringulo
que aponta para a classe genrica.
01176992910
Relacionamento de Realizao: um 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 Figura
10 mostra uma Classe Marcelo que realiza uma Interface Pessoa.

Figura 10 - Relacionamento de Realizao.
IMPORTANTE
Observem que o Relacionamento de Realizao representado por uma linha tracejada com um tringulo que aponta
para a interface.
Relacionamento de Associao: um relacionamento estrutural entre instncias e especifica os

objetos de uma classe que esto ligados a objetos de outra classe. H quatro tipos de associao:
Simples: um tipo de relacionamento mais forte que o relacionamento de dependncia e que

indica que uma instncia de um elemento est ligado a uma instncia de outro elemento. So
representados por uma linha slida com ou sem setas unidirecionais ou bidirecionais de
navegabilidade. Ademais, pode haver nomes para a associao e indicao de multiplicidade.
01176992910
Figura 11 - Associao Simples.
Na Figura 11, h uma associao simples entre Carro e Marca. Trocando em midos, significa que
o carro de uma marca e a marca possui diversos carros. 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 associao simples.
IMPORTANTE
Observem que o Relacionamento de Associao Simples representado por uma linha slida que pode ou no ter
setas de navegabilidade.

Qualificada: um tipo de relacionamento similar a associao simples, contudo possui um

qualificador, que um atributo do elemento-alvo capaz de identificar uma instncia dentre as
demais. Ela ocorre em associaes um-para-muitos ou muitos-para-muitos em que se deseja
encontrar um elemento especfico dada uma chave.
Figura 12 - Associao Qualificada.
Na Figura 12, h uma associao qualificada entre NotaFiscal e Itens. Pensem comigo: uma nota
fiscal pode ter milhares de itens, mas e se eu quiser encontrar um item especfico? Ora, posso
utilizar um identificador de Itens como qualificador de NotaFiscal. Portanto, cada item est
associado a um cdigo de item e a uma nota fiscal.
IMPORTANTE
Observem que o Relacionamento de Associao Qualificada representado por uma linha slida com um retngulo
ao lado da classe de cardinalidade 1 contendo o qualificador.
Agregao: um tipo de associao, porm mais forte, em que o todo est relacionado s suas
partes de forma independente. Nesse tipo de relacionamento, as partes tm existncia prpria.
Portanto, elas existem por si s, isto , a parte existe sem o todo. representado por uma linha
com um diamante vazio em sua extremidade referente ao todo.
01176992910

Figura 13 - Associao do tipo Agregao.
Na Figura 13, h uma agregao entre Carro e Rodas, Carro e Motor, Rodas e Calotas, Rodas e
Pneus, Motor e Carburador, e Motor e Virabrequim. Vamos interpretar apenas a agregao entre
Carro (Todo) e Rodas (Partes). Respondam-me: a roda pode existir sem um carro? Sim, claro! Logo,
esse um relacionamento de agregao.
IMPORTANTE
Observem que o Relacionamento de Agregao representado por uma linha slida com um diamante vazio na
classe agregadora.
Composio: um tipo de agregao, porm mais forte, em que o todo est relacionado s
suas partes de forma dependente. Nesse tipo de relacionamento, as partes no tm existncia
prpria. Portanto, elas no existem por si s, isto , a parte no existe sem o todo.
representado por uma linha com um diamante cheio em sua extremidade referente ao todo.
01176992910
Figura 14 - Associao do tipo Composio.

Na Figura 14, h uma composio entre Carro e Pintura. Respondam-me: a pintura pode existir sem
o carro? No, no faz o menor sentido! A existncia do carro requisito fundamental para a
existncia da pintura. Ademais, essa pintura exclusiva daquele carro e no pode ser
compartilhada. Logo, na composio, o todo tem sempre cardinalidade 1!
IMPORTANTE
Observem que o Relacionamento de Composio representado por uma linha slida com um diamante cheio na
classe compositora. Pessoal, quando eu aprendi isso, decorei assim: Diamante Cheio = Composio. Portanto,
Diamante Vazio = Agregao.
Diagrama de Objetos
O Diagrama de Objetos uma variao do Diagrama de Classes. Contudo, aqui no se trata da

estrutura geral, mas de cada instncia especfica do sistema. Portanto, no diagrama de objetos no
h Pessoa, h Joo. No h Carro, h plio. No h Cachorro, h tot. Entenderam? No diagrama
de objetos, personaliza-se cada instncia com seus valores.
Costuma-se dizer que o diagrama de objetos representa uma fotografia esttica do sistema em um
dado momento de execuo, portanto esses diagramas no refletem o sistema genericamente,
mas de forma especfica em um instante. Como ele mostra instncias, em vez de classes, ele
frequentemente chamado Diagrama de Instncias.
Esses diagramas so teis para mostrar exemplos de objetos interligados. Em algumas situaes,
pode-se definir a estrutura de um sistema precisamente com um diagrama de classes, mas a
estrutura ainda difcil de entender. Neste momento, o diagrama de objetos pode ser bastante til
para facilitar a compreenso de um determinado domnio.
Os diagramas de objeto tm seu nome sublinhado e separados por dois pontos para identificar a
classe qual pertence. Ademais, ele possui todos os seus elementos personalizados, isto , seus
atributos contm seus valores; suas operaes contm seus parmetros e tipos de retorno; entre
outros. A Figura 15 apresenta essas caractersticas:
01176992910
Figura 15 - Diagrama de Objetos.
Diagrama de Componentes

O Diagrama de Componentes representa o sistema sob uma perspectiva funcional, expondo a

organizao de seus mdulos e as relaes entre seus componentes por meio de interfaces.
Professor, o que um componentes? uma unidade independente, que pode ser utilizada com
outros componentes para formar um sistema complexo.
Os componentes representam peas que podem ser adquiridas e atualizadas independentemente.

Ora, um sistema inteiro pode ser construdo baseado em componentes. Essa uma deciso tanto
de negcio quanto tcnica. Os componentes podem ser tabelas, documentos, outros sistemas, etc.
O conjunto de componentes ir compor o sistema como um todo.
Figura 16 - Diagrama de Componentes.
Como mostra a Figura 16, os componentes so representados como retngulos com o smbolo de
componentes no canto superior direito e com nome escrito dentro ou abaixo do componente.
Frequentemente, eles vm com esteretipos para definir seu tipo e seus relacionamentos. A grande
vantagem do uso de componentes a modularidade.
Diagrama de Pacotes
01176992910
O Diagrama de Pacotes representa os pacotes e suas dependncias. Professor, o que um pacote?

um agrupamento lgico que permite reunir elementos da UML em unidades de mais alto nvel.
Comumente, pacotes agrupam classes, mas pode-se agrupar qualquer coisa. Esses elementos
podem ser membros de um nico pacote, de modo a obter uma estrutura hierrquica.
Os pacotes de nvel superior so divididos em subpacotes que possuem seus prprios subpacotes
e assim por diante. Esses pacotes ilustram a arquitetura de um sistema como um agrupamento de
classes em um alto nvel de abstrao. Os pacotes so representados como uma pasta de arquivo
com uma aba, mas o diagrama pode ser uma pasta contendo vrias classes ou pastas hierrquicas.

Figura 17 - Diagrama de Pacotes.
Diagrama de Implantao
O Diagrama de Implantao mostra o layout fsico de um sistema, revelando quais partes do

software so executados em quais partes do hardware. Tambm conhecido como Diagrama de
Instalao, pode-se representar toda a estrutura de hardware e requisitos mnimos onde o sistema
ser executado.
Os diagramas contm ns (equipamento na qual o sistema ser implantado) e artefatos

(informao usada ou produzida por um sistema). Eles no so de responsabilidade do
programador, mas da equipe de implantao do sistema, que deve se preocupar com a
configurao e topologia dos elementos de software sobre os elementos d hardware.
01176992910
Figura 18 - Diagrama de Implantao.

Diagrama de Perfil
O Diagrama de Perfil permite definir novos elementos como tipos padronizados de esteretipos,
valores rotulados e restries. Ele permite adaptar ou personalizar modelos com construes
especficas para um domnio, plataforma ou mtodo de desenvolvimento de software particular.
Trocando em midos, um mecanismo de extenso do padro UML.
Figura 19 - Diagrama de Perfil.
A UML j oferece diversos esteretipos padronizados como <<interface>>, <<extends>> e

<<include>>. No entanto, vamos supor que h um relacionamento pessoa saca dinheiro. No h
um esteretipo <<sacar>>, mas ele pode ser criado e representado com vrios outros por meio
de diagramas de perfil.
Diagrama de Estrutura Composta
O Diagrama de Estrutura Composta utilizado para modelar colaboraes internas de classes,

interfaces e componentes para especificar uma funcionalidade. O que colaborao, professor?
uma viso de um conjunto de entidades cooperativas interpretadas por instncias que cooperam
entre si para executar uma operao especfica.
Esse diagrama fornece meios de definir a estrutura de um elemento e de focaliz-la no detalhe, na

01176992910
construo e em relacionamentos internos. um dos novos diagramas propostos na segunda

verso de UML, voltado a detalhar elementos de modelagem estrutural, como classes, pacotes e
componentes, descrevendo sua estrutura interna.
Figura 20 Diagrama de Estrutura Composta.

DIAGRAMAS COMPORTAMENTAIS
Diagrama de Casos de Uso
Casos de Uso so uma tcnica para captar os requisitos funcionais de um sistema. Eles servem para
descrever as interaes tpicas entre os usurios e o prprio sistema, fornecendo uma narrativa
sobre como o sistema utilizado. E o que um cenrio? Cenrio uma instncia de caso de uso,
i.e., uma sequncia de passos que descreve uma interao entre um usurio e o sistema.
Pensemos em uma loja virtual. O cenrio de compra de um produto poderia ser: o cliente navega
no catlogo e adiciona os itens desejados sua cesta de compras. Quando desejar pagar, descreve
o endereo de entrega, fornece as informaes do carto de crdito e confirma a compra. O
sistema verifica a autorizao do carto de crdito e confirma a venda imediatamente.
Caso haja alguma falha em um dos passos, cria-se outro cenrio. De todo modo, o Diagrama de
Casos de Uso descreve um conjunto de funcionalidades do sistema e as interaes com elementos
externos e entre si. Os Atores so esses elementos externos que interagem com o sistema e so
representados por um boneco (Stickman).
Professor, eu pensava que um ator s podia ser um humano. Pois , no assim! Ele pode ser um
humano, uma mquina ou outro sistema cuja interao executa uma ao significativa. Atores
especificam um papel de uma entidade externa que se associam somente entre si ou com casos
de uso. H quatro tipos de relacionamento relevantes no diagrama de casos de uso.
H dois tipos de casos de uso: Concreto e Abstrato. O primeiro iniciado por um ator e constitui
um fluxo completo de eventos, no sentido de que uma instncia do caso de uso executa a operao
inteira chamada pelo ator. O segundo jamais instanciado diretamente, eles includos ou
estendidos ou generalizados por outros casos de uso. Representa-se com nome em itlico.
Quando um caso de uso concreto iniciado, uma instncia do caso de uso criada. Ela tambm
exibe o comportamento especificado por seus casos de uso abstratos associados. Portanto,
nenhuma instncia separada criada de casos de uso abstratos. Essa distino entre casos de uso
importante, na medida em que os atores s podem enxergar casos de uso concretos.
01176992910
Relacionamento de Comunicao: tambm chamada de relacionamento de associao, o ator

se comunica com o sistema por meio do envio e recebimento de mensagens. A Figura 22
mostra a comunicao entre um ator e um caso de uso, representado por uma linha slida
com uma seta no sentido do ator para o caso de uso.

Figura 21 - Ator interagindo com caso de uso.
Relacionamento de Incluso: relacionamento utilizado quando um mesmo comportamento se

repete em mais de um caso de uso. A Figura 23 apresenta o domnio de um internet banking.
Observem que, para que se realize um pagamento ou e visualize o saldo, obrigatrio que se
faa Login no sistema. Portanto, um relacionamento obrigatrio.
Figura 22 Relacionamento de Incluso.
Relacionamento de Extenso: relacionamento utilizado quando se deseja modelar um

relacionamento alternativo. A Figura 24 apresenta o contexto de um frum de discusses.
Observem que quer se cadastrar um usurio: se ele for administrador, realiza o caso de uso de
cima; se ele for moderador, realiza-se o caso de uso de baixo.
01176992910
Figura 23 Relacionamento de Extenso.
Relacionamento de Herana: relacionamento entre atores, utilizado quando o ator filho um

uma especificao do ator genrico ou o ator pai uma generalizao do ator especfico.
bastante til para definir sobreposio de papis entre atores e representado com uma linha
slida com um tringulo no ator genrico. Na Figura 25, Vendedor especializao de Pessoa.

Figura 24 Relacionamento de Herana ou Generalizao.
Diagrama de Atividades
O Diagrama de Atividades descreve lgica de procedimento, processo de negcio e fluxos de

trabalho. De vrias 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 aes.
Notem que o diagrama de atividades tem um nvel de abstrao maior, isto , no se preocupa
com interaes entre objetos, mas entre processos de negcios de mais alto nvel. Os estados
mudam quando uma ao executada e podem ser representados por meio de swimlanes
(semelhante a raias de uma piscina olmpica).
Como apresenta a Figura 26, a Swimlane agrupa as atividades e as organizam de acordo com suas
responsabilidades. So 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 partio.
01176992910

Figura 25 Diagrama de Atividades
Diagrama de Mquina de Estados
Tambm conhecido como Diagrama de Transio de Estados, apresenta diversos estados possveis
de um objeto no decorrer da execuo de processos de um sistema. Dessa forma, um objeto pode
passar de um estado inicial para um estado final, por meio de uma transio, quando ocorre algum
evento interno ou externo ao sistema.
01176992910

Figura 26 Diagrama de Mquina de Estados.
O Diagrama de Mquina de Estados no mostra a interao entre objetos. Geralmente, ele mostra
estados possveis de um objeto especfico. O que um Estado? a condio de um objeto em um
determinado instante. O que uma Transio? a passagem de um estado para outro. O que
uma ao? uma atividade que efetua a transio de estados.
Esse diagrama permite representar o ciclo de vida de objetos e como eles so afetados por eventos,
como erros, mensagens e condies. Eles se iniciam com um estado inicial (crculo preto), mas
podem ter vrios estados finais. A Figura 27 apresenta um objeto que faz pedidos de venda,
observem como ele fcil de ler e auxilia a visualizar a complexidade do sistema de forma simples.
01176992910
Diagrama de Sequncia
O Diagrama de Sequncia uma espcie de diagrama de interao que captura o comportamento

de um nico cenrio, mostrando vrios exemplos de objetos e mensagens que so trocadas dentro
de caso de uso. Ele modela a interao entre os objetos, permitindo a visualizao da execuo de
um ponto especfico da aplicao, com nfase na ordem temporal.
O diagrama possui dois eixos: horizontal e vertical. O primeiro representa os objetos envolvidos e
o segundo representa o tempo em que a ao ocorre e representado por uma linha tracejada
chamada Linha de Vida. A Figura 28 apresenta o diagrama de sequncia de um caso de uso Sacar
e mostra desde a insero do carto at o momento em que o saldo gravado pelo banco.

Figura 27 Diagrama de Sequncia.
Eu disse que esse diagrama mostra a sequncia temporal de mensagens trocadas entre objetos em
um sistema. Mas o que uma mensagem? um servio solicitado de um objeto para outro e suas
respostas. Por exemplo, quando um objeto utiliza o mtodo definido por outro objeto, ele est
solicitando o servio oferecido por outro, portanto isso uma mensagem.
Diagrama de Comunicao
O Diagrama de Comunicao tambm uma espcie de diagrama de interao muito semelhante

ao diagrama de sequncia, porm com nfase na ordem estrutural e, no, temporal. Em verses
anteriores da UML, era conhecido como Diagrama de Colaborao. Mas se no tem linha da vida,
como possvel verificar a ordem? Ele possui nmeros que identificam a sequncia.
01176992910
Figura 28 Diagrama de Comunicao.

Geralmente, utiliza-se o diagrama de sequncia para cenrios mais complexos e o diagrama de
comunicao para cenrios mais simples. A Figura 29 apresenta um cenrio exatamente igual ao
da Figura Y, no entanto com foco na dinmica do sistema. Observem que no h indicao
cronolgica, apenas sequencial.
Diagrama de Tempo
O Diagrama de Tempo tambm uma espcie de diagrama de interao e descreve o

comportamento dos objetos no decorrer do tempo e a durao na qual eles permanecem em
determinados estados. Percebam que h um foco no tempo e na transio de estados, portanto
ele associa caractersticas do diagrama de sequncia com o diagrama de mquina de estados.
Figura 29 Diagrama de Tempo.

01176992910
Diagrama de Interao Geral
O Diagrama de Interao Geral tambm uma espcie de diagrama de interao e uma mistura
do Diagrama de Atividades e Sequncia. Ele fornece uma viso geral do controle de fluxo entre
objetos e engloba diversos tipos de diagramas de interao para demonstrar um processo geral.
Ele mostra a troca de mensagens entre objetos e o estado de atividades.

Figura 30 Diagrama de Interao Geral.
01176992910

ANLISE E PROJETO ORIENTADO A OBJETOS
Vamos comear nossa conversa distinguindo Anlise e Projeto. Para tal, eu preciso que vocs
memorizem, decorem, tatuem no brao, componham uma msica com essa frase:
Figura 34 - Mantra!
Pessoal, a Anlise consiste em atividades necessrias para entender o domnio do problema, i.e., o
que deve ser feito. uma atividade de investigao, com foco no cliente. J o Projeto consiste em
atividades necessrias para entender o domnio da soluo do problema, i.e., como deve ser feito.
uma atividade tcnica, com foco no programador.
Na Anlise, a tecnologia de implementao e os requisitos no-funcionais no so modelados. Essa

uma tarefa do Projeto! Tambm no se pensa sobre solues tcnicas, pensa-se apenas em
modelar funes, dados e relacionamentos do sistema. O modelo de anlise deve ser aprovado
pelo cliente e pode incluir at pequenas discusses sobre a soluo, como sobre Interface Grfica.
Vamos comear definindo um importante artefato chamado Modelo de Classes. Ele representa
conceitos de um determinado domnio de negcio. Como ? Pessoal, um exemplo de Modelo de
Classes um Diagrama de Classes (da UML). Ele representa visualmente conceitos de um
determinado domnio por meio de classes. H trs nveis:
01176992910
Modelo de Classes de Anlise (ou Domnio): construdo durante a atividade de anlise,

representa as classes de domnio do negcio em questo. No leva em considerao
restries inerentes tecnologia a ser utilizada na soluo de um problema.
Figura 35 - Exemplo de Classe de Anlise.

Modelo de Classes de Projeto (ou Especificao): construdo durante a atividade de projeto,
estende o modelo de classes de anlise e contm detalhes especficos inerentes soluo
de software escolhida.
Figura 36 - Exemplo de Classe de Projeto.
Modelo de Classes de Implementao: construdo durante a atividade de implementao,

estende o modelo de classes de projeto e contm detalhes especficos inerentes ao
desenvolvimento das classes em alguma linguagem de programao.
Figura 37 - Exemplo de Classe de Implementao.
medida que o sistema desenvolvido, o Modelo de Classes incrementado com novos detalhes.
O Modelo de Anlise enfatiza o desenho lgico, a viso externa, conceitual, abstrata, caixa-preta,
de alto nvel de abstrao. O Modelo de Projeto enfatiza o desenho fsico, a viso interna, de
implementao, concreta, caixa-branca, de baixo nvel de abstrao.
Sabe-se que o Modelo de Anlise mais estvel que o Modelo de Projeto. Sob a perspectiva
01176992910
organizacional, o modelo de anlise sofre bem menos com mudanas tecnolgicas, externas,
regulatrias, legais, entre outras. Agora um dado importante: na prtica, muitas pessoas no fazem
Anlise e j partem para o Projeto. Inclusive, ela uma disciplina opcional no RUP!
Professor, eu posso no faz-la? Pode, sim. Ento para que ela existe? Pessoal, imaginem se ocorre
uma revoluo tecnolgica e todas as organizaes comecem a implementar sistemas com um
novo paradigma. Com um modelo de anlise pronto, torna- muito mais fcil adaptar o modelo
de projeto. Caso contrrio, tem-se que refazer o modelo de projeto integralmente do incio.
Normalmente, as classes de anlise evoluem diretamente para classes de projeto. A meta da Anlise
identificar um esboo preliminar do comportamento do sistema. A meta do Projeto transformar
esse esboo preliminar em um conjunto implementvel. O resultado que h um refinamento
detalhado e preciso quando algum se move da Anlise para o Design.

Pessoal, a Anlise apresenta quatro atividades principais:
2. Identificar 3. Identificar 4. Identificar

1. Identificar Classes
Responsabilidades Atributos Relacionamentos
Em 1992, Ivar Jacobson (aquele mesmo da UML) props uma tcnica

denominada Anlise de Robustez, que propunha a categorizao das
classes em trs tipos, de acordo com sua responsabilidade: Classe de
Fronteira; Classe de Controle; e Classe de Entidade.
Classe de Fronteira: classe utilizada para modelar a interao entre um ator e o sistema.
Para cada ator, identificada pelo menos uma classe de fronteira para permitir sua
interao com o sistema. Ento, uma classe de fronteira existe para que o sistema se
comunique com o mundo exterior, portanto elas so altamente dependentes do ambiente.
Classe de Controle: classe utilizada para controlar a lgica de execuo correspondente a

cada caso de uso. Servem como uma ponte de comunicao entre objetos de fronteira e
objetos de entidade. Decidem o que o sistema deve fazer quando um evento externo
relevante ocorre, agindo como um coordenador para a realizao de casos de uso.
Classe de Entidade: classe utilizada para armazenar a informao que manipulada ou

processada pelo caso de uso, partindo do domnio do negcio. Geralmente, essas classes
armazenam informaes persistentes. H vrias instncias de uma mesma classe de
entidade coexistindo no sistema.
A segunda atividade se refere identificao de responsabilidades. Essa identificao e

consequente categorizao implica que cada classe seja especialista em realizar uma tarefa
especfica que compor o modelo de anlise: comunicar-se com atores (Fronteira); manter as
informaes do sistema (Entidade); e coordenar a realizao de um caso de uso (Controle).
As atividades seguintes so bastante intuitivas. A terceira atividade se refere identificao de

atributos, em que busca-se apenas descobrir quais so os atributos, sem nenhuma preocupao
01176992910
sobre qual seu tipo (String, Date, Time, Integer, etc). Um bom conhecimento do domnio do
problema extremamente til nesta fase.
Por fim, identificam-se os relacionamentos como associaes, agregaes, composies,

dependncias, generalizaes, especializaes, entre outros. Pessoal, findou-se a Anlise. Agora
ns sabemos o que fazer. Chegou a hora de saber como fazer. Partamos, ento, para o Projeto!
Vamos falar bastante sobre arquitetura de software, estrutura e comportamento de classes.
A Arquitetura de Software a organizao ou a estrutura dos componentes significativos do

sistema que interagem por meio de interfaces. Uma arquitetura bem projetada deve ser capaz de
atender aos requisitos funcionais e no-funcionais do sistema e ser suficientemente flexvel para
suportar requisitos volteis.

A arquitetura importante, na medida em que ela permite uma comunicao efetiva entre as partes
interessadas, abrangendo a compreenso, negociao e consenso. Ademais, permite decises
tempestivas, i.e., possibilita correo e validao do sistema antes da implementao. Por fim,
permite uma abstrao reutilizvel do sistema em sistemas diferentes com caractersticas similares.
Uma boa arquitetura deve ter componentes projetos com baixo acoplamento e alta coeso. Como
, professor? Pessoal, esse outro mantra para vocs memorizarem! Acoplamento trata do nvel de
dependncia entre mdulos de um software. J a Coeso trata do nvel de responsabilidade de um
mdulo em relao a outros.
Professor, por que bom ter baixo acoplamento? Porque se os mdulos pouco dependem um do
outro, modificaes de um no afetam os outros, alm de prejudicar o reso. Professor, por que
bom ter alta coeso? Porque se os mdulos tem responsabilidades claramente definidas, eles sero
altamente reusveis independentes e simples de entender.
01176992910

ARQUITETURA EM TRS CAMADAS
Uma forma de organizar a arquitetura de um sistema complexo em partes menores por meio de
camadas de software, em que cada camada corresponder a um conjunto de funcionalidades de
um sistema de software sendo que as funcionalidades de alto nvel dependero das
funcionalidades de baixo nvel.
A separao em camadas fornece um nvel de abstrao atravs do agrupamento lgico de

subsistemas relacionados. Parte-se do princpio de que as camadas de abstrao mais altas devem
depender das camadas de abstrao mais baixas. Isso permite que o sistema de software seja mais
portvel e modificvel.
importante salientar que mudanas em uma camada mais baixa, que no afetem a sua interface,
no implicaro mudanas nas camadas mais superiores. Assim como mudanas em uma camada
mais alta, que no impliquem a criao de um novo servio em uma camada mais baixa, no
afetaro as camadas mais inferiores.
A arquitetura em camadas permite melhor separao de responsabilidades; decomposio de

complexidade; encapsulamento de implementao; maior reso e extensibilidade. No entanto,
podem penalizar o desempenho do sistema e aumentar o esforo e complexidade de
desenvolvimento do software.
Sistemas Cliente-Servidor em duas camadas foram dominantes durante aproximadamente toda a

dcada de noventa e so utilizados at hoje. Todavia, para minimizar o impacto de mudanas nas
aplicaes, decidiu-se separar a camada de negcio da camada de interface grfica, gerando trs
camadas: Camada de Apresentao, Camada Lgica do Negcio e Camada de Acesso a Dados.
A Camada de Apresentao possui classes que contm funcionalidades para visualizao

dos dados pelos usurios (Ex: classes de fronteiras para atores humanos). Ela tem o objetivo
de exibir informaes ao usurio e traduzir aes do usurio em requisies s demais
partes do sistemas.
01176992910
A Camada Lgica de Negcio possui classes que implementam as regras de negcio no

qual o sistema ser implantado. Ela realiza computaes com base nos dados armazenados
ou nos dados de entrada, decidindo que parte da camada de acesso de ser atividade com
base em requisies provenientes da camada de apresentao.
A Camada de Acesso a Dados possui classes que se comunicam com outros sistemas para
realizar tarefas ou adquirir informaes para o sistema. Tipicamente, essa camada
implementada utilizando algum mecanismo de armazenamento persistente. Pode haver
uma subcamada dentro desta camada chamada Camada de Persistncia.
O padro de arquitetura em trs camadas mais utilizado no mercado designado Model-View-

Controler (MVC):

Modelo: responsvel por modelar os dados da aplicao e as regras de negcio. Tem o

foco voltado para o armazenamento, manipulao e gerao de dados. Objetos do Modelo
so geralmente reusveis, distribudos, persistentes e portveis para diversas plataformas.
Viso: responsvel pela apresentao dos dados aos usurios. Ele recebe entradas de dados
e apresenta resultados. Essa camada no persiste nenhum dado no sistema e tambm no
busca dados, apenas os renderiza em tela.
Controle: responsvel por definir o comportamento da aplicao. Processa e responde a

eventos, geralmente aes do usurio, e pode invocar alteraes no modelo. Realiza,
tambm, a validao de dados do usurio.
01176992910

MTRICAS E ESTIMATIVAS DE SOFTWARE
Sommerville diz: A medio de software se dedica a derivar um valor numrico para algum atributo
de um produto de software ou de um processo de software. Comparando-se esses valores uns
com os outros e aos padres que se aplicam em uma organizao, voc pode ser capaz de tirar
concluses sobre a qualidade de software ou dos processos de software.
As medies so teis sobre dois aspectos: primeiro, permitem fazer previses gerais sobre um
sistema, derivando estimativas genricas sobre num atributo do sistema; segundo, permitem
identificar componentes anmalos, i.e., aqueles cujas caractersticas desviem de alguma regra.
Galera, mtricas de software um assunto bastante genrico!
Trata-se de qualquer medida que se refira a um software, processo ou sua documentao, por
exemplo: ndice de Fog (mede a facilidade de leitura de uma passagem de um texto escrito);
Nmero de Defeitos de Software; Nmero de Linhas de Cdigo (LOC); ou Nmero de Pessoas-Dia
necessrios para implementar um componente de sistema.
A Mtrica de Software mais conhecida do mercado a Anlise de Pontos por Funo, que permite
medir o tamanho de uma funcionalidade de software no esquentem a cabea agora, teremos
uma aula s sobre ela! Essas outras mtricas que veremos adiante so bem menos comuns! E
agora, que tal v-las?
As Mtricas de Software podem ser de controle ou de predio! No primeiro caso, esto associadas
a processos de software (Ex: esforo mdico, tempo necessrio para reparao de defeitos, etc); e
no segundo caso, esto associadas a produtos de software (Ex: complexidade de um mdulo,
extenso dos identificadores, etc).
Pode-se classificar mtricas tambm em estticas ou dinmicas! No primeiro caso, so coletadas

por meio de medies realizadas em representaes do sistema, como projeto, programa ou
documentao; e no segundo caso, so coletadas por meio de medies realizadas em um
programa em execuo simples, no?!
01176992910
Outra classificao interessante em Orientadas a Tamanho e Orientadas a Funes! No primeiro

caso, so medidas diretas do tamanho dos artefatos de software associados ao processo por meio
do qual o software desenvolvido por exemplo: custo, nmero de linhas de cdigo, quantidade
de pginas de documentao, nmero de erros, etc.
No segundo caso, so medidas de software do ponto de vista do usurio, determinando de forma

consistente o tamanho e a complexidade funcional de um software por exemplo: anlise de
pontos por funo. Pessoal, vamos ver agora algumas da principais mtricas de software utilizadas
no mercado:
Fan-in/Fan-out: o primeiro uma medida do nmero de funes ou mtodos que chamam

alguma outra funo ou mtodo especfico; o segundo o nmero de funes chamadas pela
funo ou mtodo especfico.

Extenso de Cdigo: uma medida de tamanho de um software. Quanto maior for o tamanho
do cdigo, mais complexo e propenso a erros ele ser. Essa uma das mtricas mais confiveis
de previso de propenso a erros em componentes.
Complexidade Ciclomtica: uma medida de complexidade de controle de um programa. Essa

complexidade de controle pode estar relacionada facilidade de compreenso do programa.
Complexidade Ciclomtica = E - N + 2P (E = Arestas; N = Ns; P = Componentes Conectados).
Extenso de Identificadores: uma medida da extenso mdia de identificadores distintos em

um programa. Quanto maiores forem os identificadores, mais eles sero significativos e, por
isso, mais compreensvel ser o programa.
Profundidade de Aninhamento Condicional: uma medida da profundidade de aninhamento

de declaraes condicionais em um programa. As declaraes profundamente aninhadas so
difceis de compreender e so potencialmente propensas a erros.
ndice de Fog: uma medida de extenso mdia das palavras e das sentenas em documentos.
Quanto maior for o valor para o ndice de Fog, mais difcil ser a compreenso de documentos
e vice-versa.
Profundidade de rvore de Herena: representa o nmero de nveis discretos na rvore de

herana da qual as subclasses herdam atributos e operaes das superclasses. Quanto maior
fora a profundidade, mais complexo ser o projeto.
Nmero de Operaes Sobrescritas: o nmero de operaes, em um superclasse, sobrescritas

em uma subclasse. Um valor alto dessa mtrica indica que a superclasse usada pode no ser
uma classe-me apropriada para a subclasse.
COCOMO: acrnimo de Constructive Cost Model, um modelo de estimativa de tempo de

desenvolvimento de um produto foi baseado no estudo de 63 projetos com programas entre
2.000 e 100.000 linhas de cdigo em linguagens de programao de Assembly a PL/I.
Pode-se categorizar tambm em: mtricas de produtividade, de qualidade e tcnicas. A primeira

01176992910
se refere sada do processo de engenharia de software (ex: nmero de casos de uso); a segunda
se refere quanto um software se adequa s exigncias implcitas e explcitas do cliente (ex:
quantidade de erros); e a ltima se refere s caractersticas do software (ex: complexidade lgica).

(CESPE - 2011 - EBC - Analista - Engenharia de Software) Esteretipos so uma maneira de destacar ou
diferenciar um componente ou relacionamentos iguais, atribuindo-lhes caractersticas especiais ou
modificando-as de alguma forma.
Comentrios:
Questo perfeita! um dos mecanismos de extensibilidade.
Gabarito: C
(CESPE - 2008 - -RR - 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 relatrio assim que for concluda a atividade Preencher pedido ou a
atividade Elaborar relatrio; ser executada a atividade Elaborar relatrio se o pedido no for urgente.
01176992910
Comentrios:
Na verdade, a atividade Avaliar Relatrio ser executada assim que for concluda ambas as atividades:
Preencher Pedido e Elaborar Relatrio.
Gabarito: E
(CESPE - - MPE- - 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 contm comportamento comum

a dois casos de uso; o caso de uso Pagar projeto estende o comportamento Financiar projeto e Cancelar
projeto abstrato.
Comentrios:
O caso de uso Cancelar Projeto somente seria abstrato se estivesse escrito com nome em itlico.
Gabarito: E
(CESPE - 2010 - TRE- - Tcnico Judicirio - Programao de Sistemas) Um requisito uma caracterstica
de projeto, uma propriedade ou um comportamento de um sistema. Um diagrama de sequncia enfatiza
a ordenao temporal de mensagens.
Comentrios:
Questo perfeita!
Gabarito: C
(CESPE - 2011 - Correios - Analista de Correios - Analista de Sistemas - Desenvolvimento de Sistemas) O

diagrama de sequncia pode ser usado para descrever como alguns objetos de um caso de uso
colaboram em algum comportamento ao longo do tempo.
Comentrios:
De fato, o diagrama de interao trata da interao de objetos ao longo do tempo.

01176992910
Gabarito: C
(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. Ento, ao se executar o caso de uso A, executa-se tambm o B.
Comentrios:
Questo perfeita! Recomendo que decorem isto!
Gabarito: C
(CESPE - 2011 - TRE-ES - Tcnico - Programao de Sistemas - Especficos) Os modelos de casos de uso
enfatizam os objetivos e as perspectivas do usurio, demonstrando a viso de quem utiliza o sistema.

Comentrios:
Essa foi fcil! Caso de uso representa uma funcionalidade descrita pelo usurio.
Gabarito: C
(CESPE - 2011 - TRE-ES - Analista - Anlise de Sistemas - Especficos) Na figura, o tempo mostrado no
eixo vertical e os objetos envolvidos na sequncia de uma atividade, no eixo horizontal.
Comentrios:
Quase idntico ao que foi dito na aula. Na vertical o tempo e na horizontal so os objetos.
Gabarito: C
(CESPE - 2010 - DETRAN-ES - Analista de Sistemas) O uso da linguagem de modelagem unificada,

conhecida como UML, recomendado para a anlise orientada a objetos, mas no para o projeto
orientado a objetos, que deve ser realizado por meio do suporte de linguagens de programao
orientadas a objetos.
Comentrios:
Nada a ver! Ele recomendado tanto na fase de anlise quanto na fase de projeto.
Gabarito: E
01176992910
10. (CESPE - 2010 - ABIN - Oficial Tcnico De Inteligncia - rea De Desenvolvimento E Manuteno De
Sistemas) Um diagrama de implantao pode ser utilizado quando o software projetado para ser
executado sobre uma nica mquina individual que no se comunica com outro hardware. A modelagem
em conjunto com diagramas de componentes, como ilustrado na figura a seguir, no possvel na UML.

Comentrios:
Bem, executar sobre uma nica mquina individual no o objetivo mais frequente, mas nada impede que
isso ocorra. Porm a modelagem , sim, possvel em conjunto com diagramas de componentes.
Gabarito: E
(CESP - 2010 - TRE- - Analista Judicirio - Anlise de Sistemas) O propsito maior de um caso de uso
fornecer uma descrio do comportamento do sistema. Assim, em um processo de desenvolvimento
orientado a objetos, os objetivos de um caso de uso so: definir escopo, detalhar os processos e clculos
do sistema, organizar e dividir o trabalho, estimar o tamanho do projeto e direcionar os testes.
Comentrios:
Opa, casos de uso no detalham processos e clculos do sistema e nem estimam, por si s, o tamanho do
projeto!
Gabarito: E
12. (CESPE - 2010 - TCU - Auditor Federal de Controle Externo - Tecnologia da Informao - Parte II) UML
(Unified Modeling Language) uma tecnologia concorrente com o processo unificado, no que diz
respeito ao apoio prtica de engenharia de software orientada a objetos.
Comentrios:
01176992910
Na verdade, eu diria que uma tecnologia complementar e, no, concorrente. A UML extensivamente
utilizada no RUP.
Gabarito: E
13. (CESPE - 2010 - Banco da Amaznia - Tcnico Cientfico - Tecnologia da Informao - Anlise de
Sistemas) De acordo com as caractersticas da relao entre a classe Funcionario e a classe Curriculo, ao
se excluir um funcionrio desse sistema, tambm sero removidos os respectivos dados curriculares da
base de dados.

Comentrios:
Questo perfeita! Isso ocorre, porque h um relacionamento de composio (Diamante Cheio) entre
funcionrio e currculo.
Gabarito: C
14. (CESPE - 2008 - TRT - 5 Regio (BA) - Analista Judicirio - Tecnologia da Informao) No diagrama,
Bicicleta e Veiculo_motor so tipos de veculos e, dessa forma, tm relao de herana com veculo.
correto afirmar que veculo subclasse de Bicicleta e Veiculo_motor.
01176992910
Comentrios:
Opa, veculo superclasse de Bicicleta e Veculo_motor.
Gabarito: E
15. (CESP - - ANAC - Tcnico Administrativo - Informtica) Geradores de cdigo 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 cdigo.
Comentrios:

Questo perfeita! H ferramentas CASE que geram um programa a partir de diagramas da UML.
Gabarito: C
16. (CESPE - - SECONT-ES - Auditor do Estado Tecnologia da Informao) 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 descrio do fluxo de eventos de forma
suficientemente clara para que os seus usurios sejam capazes de compreend-lo. Nesse fluxo, devem
ser includas definies relacionadas forma de implementao, para que sejam diretamente utilizadas
pelos implementadores.
Comentrios:
No h definio relacionada forma de implementao em casos de uso. Tudo isso abstrado e mostra-
se o que fazer e, no, como fazer.
Gabarito: E
17. (CESPE - - SECONT-ES - Auditor do Estado Tecnologia da Informao) Diagramas de interao

so utilizados na UML para modelagem dos aspectos dinmicos do sistema. No diagrama de sequncia
- um diagrama de interao em que dada nfase ordenao temporal das mensagens -,
explicitamente representada a linha de vida do objeto, bem como o perodo durante o qual ele est
desempenhando uma ao.
Comentrios:
Essa questo foi muito mal escrita, porque ela d a entender que o diagrama ir explicitar o perodo durante
o qual ele est desempenhando uma ao. Na verdade, quem faz isso o Diagrama de Tempo! O Diagrama
de Sequncia d uma noo do perodo, mas no explicitado o perodo. De todo modo, o gabarito foi Item
Correto.
Gabarito: C
18. (CESPE - 2010 - EMBASA - Analista de Saneamento - Analista de Tecnologia da Informao -

Desenvolvimento) O diagrama de atividades tem por objetivo mostrar o fluxo de atividades em um nico
processo; entretanto, esse diagrama no mostra como as atividades dependem umas das outras, porque
01176992910
isso responsabilidade do diagrama de dependncias.
Comentrios:
Na verdade, ele mostra sim como as atividades dependem umas das outras. Alm disso, no existe
diagrama de dependncias na UML.
Gabarit E

Desenvolvimento) Um diagrama de estado capaz de mostrar os estados possveis de um objeto. Alm
disso, pode mostrar as transaes responsveis pelas suas mudanas de estado.
Comentrios:

Bem, nessa o CESPE vacilou! No se mostram transaes, mas transies! Pessoal, j cansei de ver o CESPE
errar essa palavra especfica e no mudar o gabarito como ocorreu nessa questo.
Gabarito: C

Desenvolvimento) O objetivo principal de um diagrama de pacotes agrupar os pacotes em classes.
Esse tipo de diagrama pode usar dependncias.
Comentrios:
Na verdade, agrupa classes (entre outros elementos) em pacotes.
Gabarito: E

Desenvolvimento) Um diagrama de casos de uso descreve um cenrio que mostra as funcionalidades do
sistema do ponto de vista do usurio. comum o uso de atores nesse diagrama.
Comentrios:
Questo muito tranquila!
Gabarito: C
22. (CESPE - 2010 - EMBASA - Analista de Saneamento - Analista de Tecnologia da Informao

Desenvolvimento) Os diagramas em UML podem ser estticos ou dinmicos. O diagrama de classes
um exemplo de um diagrama dinmico.
Comentrios:
Lembram que eu falei para decorar? Pois , a questo s quer saber se voc sabe que o diagrama de classe
esttico e, no, dinmico. Basta lembrar que mostra estrutura e troca de mensagens.
Gabarito: E

01176992910
Desenvolvimento) possvel criar um diagrama de transio de estados que descreva o ciclo de vida de
um objeto em nveis de detalhe arbitrariamente simples ou complexos, dependendo das necessidades,
pois no h a obrigao de ilustrar todos os eventos possveis.
Comentrios:
Questo perfeita! No h nenhuma obrigao em ilustrar todos os eventos.
Gabarito: C
24. (CESPE - - TCU - Analista de Controle Externo - Tecnologia da Informao - Prova 2) O mtodo
#Cadastrar( ) da classe Instrutor tem visibilidade do modo protegido tal que somente a classe possuidora
Instrutor pode utiliz-lo.

Comentrios:
Opa! Visibilidade protegida tambm pode ser acessada pelas classes filhas.
Gabarito: E
25. (CESPE - 2004 - TRE-AL - Analista Judicirio - Especialidade - Anlise de Sistemas - Desenvolvimento)
Na UML, um diagrama de estados mostra os vrios estados pelos quais passa um objeto e as transies
de um estado para outro.
Comentrios:
Questo perfeita!
Gabarito: C
26. (CESPE - 2011 - BRB - Analista de Tecnologia da Informao) O diagrama de atividade, considerado
independente do diagrama de mquina de estado, serve para descrever os passos a serem percorridos
01176992910
para a concluso de uma atividade especfica.
Comentrios:
Questo perfeita!
Gabarito: C
27. (CESPE - 2011 - BRB - Analista de Tecnologia da Informao) 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 compem.
Comentrios:
Questo perfeita! O diagrama de pacotes pode agrupar praticamente qualquer coisa.

Gabarito: C
28. (CESPE - 2010 - TRE-BA - Tcnico Judicirio - Programao de Sistemas) Um cenrio, tambm
denominado instncia de caso de uso, uma sequncia especfica de aes e interaes entre atores e
o sistema em discusso. Assim, um caso de uso uma coleo de cenrios relacionados de sucesso e
fracasso, que descrevem atores usando um sistema como meio para atingir um objetivo.
Comentrios:
Pessoal, comum pessoas acharem que este item est errado porque um caso de uso no uma coleo
de cenrios, mas de apenas um cenrio. No existe isso, h cenrios principais e cenrios alternativos em um
caso de uso!
Gabarito: C
29. (CESPE - 2010 - TRE-BA - Tcnico Judicirio - Programao de Sistemas) Os diagramas de classes podem
conter pacotes ou subsistemas, utilizados para agrupar elementos do modelo em um conjunto maior.
No nvel de visibilidade privado, uma caracterstica pode ser usada por qualquer descendente do
classificador; contudo, um classificador nem sempre capaz de visualizar outro classificador.
Comentrios:
No nvel de visibilidade privado, uma caracterstica pode ser usada somente pela prpria classe.
Gabarito: E
30. (CESPE - 2011 - -ES - Tcnico de Informtica - Especficos) A modelagem que permite a identificao
de funcionalidades, comportamento do sistema, ambiente, relaes entre agentes e detalhe de requisitos
funcionais representada por meio de diagrama de sequncia de atividades.
Comentrios:
Quem identifica funcionalidades o diagrama de casos de uso. Diagrama de sequncia est preocupado em
representar o comportamento de objetos de um nico caso de uso.
01176992910
Gabarito: E
31. (CESPE - 2011 - Correios - Analista de Correios - Analista de Sistemas - Desenvolvimento de Sistemas) O
diagrama de componentes deve ser utilizado para se representar a configurao e a arquitetura de um
sistema no qual estaro ligados todos os software e hardware, bem como sua interao com outros
elementos de suporte ao processamento.
Comentrios:
No, essa a exata descrio de um Diagrama de Implantao!
Gabarito: E

32. (CESPE - 2011 - TRE-ES - Tcnico - Programao de Sistemas - Especficos) RUP e UML so
interdependentes, isto , no h como se aplicar o RUP no desenvolvimento de um sistema se no se
utilizar o UML.
Comentrios:
Dizer que RUP e UML so interdependentes implica dizer que a UML depende do RUP, o que falso!
Gabarito: E
33. (CESPE - 2010 - MPU - Analista de Informtica - Desenvolvimento de Sistemas) Na UML, um diagrama
de atividades oferece uma notao para mostrar uma sequncia de atividades, inclusive atividades
paralelas. Ele pode ser aplicado em qualquer perspectiva ou propsito, no entanto, normalmente mais
utilizado para a visualizao de fluxos de trabalho, processos de negcios e casos de uso.
Comentrios:
Questo perfeita!
Gabarito: C
34. (CESPE - - CONT-ES - Auditor do Estado Tecnologia da Informao) UML um mtodo para
desenvolvimento de software que foi proposto para ser aplicado anlise e projeto de software
orientados a objetos.
Comentrios:
Opa! UML um mtodo para desenvolvimento de software? No!
Gabarito: E
35. (CESPE - - SECONT-ES - Auditor do Estado Tecnologia da Informao) UML (Universal Modeling
Language) uma linguagem de modelagem proprietria que pode ser utilizada no desenvolvimento de
sistemas de maneira intuitiva para visualizao de objetos.
Comentrios:
01176992910
UML no-proprietria!
Gabarito: E
36. (CESPE - 2011 - BRB - Analista de Tecnologia da Informao) O diagrama de casos de uso o mais
especfico e formal da UML, pois, alm de servir de referncia para a construo de outros diagramas,
utilizado nas fases de levantamento de sistemas e pode ser consultado durante todo o processo de
modelagem.
Comentrios:
Na verdade, ele bastante informal e pouco especfico!
Gabarito: E

37. (CESPE - 2010 - TRE-BA - Tcnico Judicirio - Programao de Sistemas) Na UML, os diagramas de
sequncia e os diagramas de atividade, tambm denominados diagramas de interao, auxiliam a
modelar os aspectos dinmicos de sistemas. Um diagrama de interao formado pelo conjunto de
objetos e seus relacionamentos e inclui as mensagens que podero ser enviadas entre eles.
Comentrios:
Mais uma vez, o CESPE vacilou! Diagrama de Atividade no um diagrama de interao, mas o gabarito se
manteve intacto como correto.
Gabarito: C
diagrama de classes define todas as classes de que o sistema necessita e a base para a construo dos
diagramas de sequncia e comunicao.
Comentrios:
Questo perfeita!
Gabarito: C
39. (CESPE - 2011 - TRE-ES - Tcnico - Programao de Sistemas - Especficos) Em um diagrama de

sequncia, esto representadas classes, que no so relacionadas por agregao e composio, entre
outros tipos de relaes presentes em diagramas de classe, mas relacionadas, diretamente, por meio de
mensagens.
Comentrios:
Diagrama de Sequncia no representa classes, mas objetos!
Gabarito: E
40. (CESPE - 2010 - ABIN - Oficial Tcnico De Inteligncia - rea De Desenvolvimento E Manuteno
Sistemas) Um caso de uso pode no gerar um diagrama de sequncia, a exemplo do que ocorre com
os de tipo <<extend>>. 01176992910
Comentrios:
Questo perfeita! Casos de Uso estendidos so opcionais, portanto podem no gerar um diagrama de
sequncia.
Gabarito: C
41. (CESPE - 2013 - TRT - 10 REGIO (DF e TO) - Analista Judicirio - Tecnologia da Informao) As mtricas
de software podem ser classificadas em medidas diretas ou quantitativas e medidas indiretas ou
qualitativas.
Comentrios:

Perfeito, isso mesmo! Diretas so aquelas que representam uma quantidade observada (custo, nmero de
linhas de cdigo, tempo de execuo, etc) e Indiretas so aquelas que exigem anlise e esto relacionadas
com a funcionalidade, qualidade, complexidade, etc.
Gabarito: C
42. (CESPE - 2013 - TRT - 10 REGIO (DF e TO) - Analista Judicirio - Tecnologia da Informao) Mtricas
quantitativas, normalmente, exigem anlise e esto relacionadas com a funcionalidade, a qualidade, a
complexidade e a manuteno do software.
Comentrios:
Na verdade, essas so as Mtricas Qualitativas!
Gabarito: E
43. (CESPE - 2011 - TRE-ES - Tcnico - Programao de Sistemas - Especficos As mtricas orientadas a
tamanho medem a funcionalidade entregue pela aplicao ao usurio como valor de normalizao.
entrios:
Na verdade, essas so as mtricas orientas funcionalidade as mtricas orientadas a tamanho consideram

o tamanho do software, geralmente em relao quantidade de linhas.
Gabarito: E
44. (CESPE - 2009 - ANTAQ - Analista Administrativo Informtica Mtricas de produto dinmicas so
coletadas por meio de medies realizadas em representaes do sistema, como projeto, programa ou
documentao, ao passo que mtricas de produto estticas so coletadas em programas em execuo.
Comentrios:
Na verdade, est invertido! Estticas so por meio do projeto, programa ou documentao; e Dinmicas so
por meio do programa em execuo.
Gabarito: E
01176992910
45. (CESPE - - ANTAQ - Analista Administrativo - Informtica Dois tipos de mtricas tm sido usados
para estimativas de produtividade do desenvolvimento de software: as relacionadas a tamanho de algum
resultado de uma atividade, como, por exemplo, linhas de cdigo fonte entregues, nmero de instrues
de cdigo objeto, nmero de pginas de documentao, e as relacionadas a funes - funcionalidade
geral do software entregue. A produtividade expressa em termos de quantidade de funcionalidade til
produzida em um dado tempo, como, por exemplo, pontos por funo, pontos por objeto.
Comentrios:
Perfeito, isso mesmo.
Gabarito: C

46. (CESPE - - TCU - Analista de Controle Externo - Tecnologia da Informao - Prova 2 A medida de
complexidade ciclomtica avalia o nmero de caminhos de execuo diferentes de um dado programa,
sendo diretamente relacionada facilidade de compreenso do programa. Calculada a partir da anlise
de um grafo dirigido, representa os possveis caminhos de execuo do programa, e desvios
incondicionais contribuem para o aumento de valor desse clculo.
Comentrios:
Desvios Condicionais contribuem mais para o aumento do clculo, na medida em que so novos caminhos
no grafo de execuo do programa. Os Desvios Incondicionais tambm contribuem para o aumento do
clculo, mas em menor escala.
M = E - N + 2P, em que M = Complexidade Ciclomtica; E = Quantidade de Arestas; N = Quantidade de

Ns; P = Quantidade de Componentes Conectados. Portanto, ao aumentar o nmero de arestas, aumenta-
se a Complexidade Ciclomtica - sendo Desvios Condicionais ou Incondicionais.
Gabarito: C
47. (CESPE - 2012 - Banco da Amaznia - Tcnico Cientfico - Anlise de Sistemas) Por meio da distribuio
da carga de processamento entre diferentes servidores, possvel aumentar a escalabilidade do sistema
computacional utilizando-se o modelo cliente-servidor multicamadas.
Comentrios:
Perfeito, uma das vantagens do modelo cliente-servidor multicamadas aumentar a escalabilidade do

sistema computacional.
Gabarito: C
48. (CESPE - 2012 - Banco da Amaznia - Tcnico Cientfico - Anlise de Sistemas Na arquitetura cliente-
servidor multicamada, a camada intermediria capaz de armazenar requisies de clientes em uma fila,
permitindo que o cliente requisite algo camada intermediria e desconecte-se, sem ter de ficar espera
da resposta, o que aumenta a velocidade de processamento do cliente.
Comentrios:
Perfeito, isso mesmo! 01176992910
Gabarito: C
49. (FCC - 2010 - TRT - 20 REGIO (SE) - Tcnico Judicirio - Tecnologia da Informao) A arquitetura
multicamadas divide-se em trs camadas lgicas. So elas: Apresentao, Negcio e Acesso a Dados.
Comentrios:
Perfeito, so esses os nomes das trs camadas.
Gabarito: C

50. (FCC - - TRF - 5 REGIO - Analista Judicirio - Tecnologia da Informao) Via de regra as divises
da arquitetura de software em trs camadas orientam para nveis que especificam a apresentao, as
regras de negcio e o armazenamento de dados.
Comentrios:
Exato! Apresentao, Regras de Negcio e Armazenamento de Dados.
Gabarito: C
01176992910

LISTA DE EXERCCIOS COMENTADOS
(CESPE - 2011 - EBC - Analista - Engenharia de Software) Esteretipos so uma maneira de destacar ou
diferenciar um componente ou relacionamentos iguais, atribuindo-lhes caractersticas especiais ou
modificando-as de alguma forma.
(CESPE - 2008 - -RR - 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 relatrio assim que for concluda a atividade Preencher pedido ou a
atividade Elaborar relatrio; ser executada a atividade Elaborar relatrio se o pedido no for urgente.
(CESPE - - MPE- - 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 contm comportamento comum
01176992910
a dois casos de uso; o caso de uso Pagar projeto estende o comportamento Financiar projeto e Cancelar
projeto abstrato.

(CESPE - 2010 - TRE- - Tcnico Judicirio - Programao de Sistemas) Um requisito uma caracterstica
de projeto, uma propriedade ou um comportamento de um sistema. Um diagrama de sequncia enfatiza
a ordenao temporal de mensagens.
(CESPE - 2011 - Correios - Analista de Correios - Analista de Sistemas - Desenvolvimento de Sistemas) O

diagrama de sequncia pode ser usado para descrever como alguns objetos de um caso de uso
colaboram em algum comportamento ao longo do tempo.
(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. Ento, ao se executar o caso de uso A, executa-se tambm o B.
(CESPE - 2011 - TRE-ES - Tcnico - Programao de Sistemas - Especficos) Os modelos de casos de uso
enfatizam os objetivos e as perspectivas do usurio, demonstrando a viso de quem utiliza o sistema.
(CESPE - 2011 - TRE-ES - Analista - Anlise de Sistemas - Especficos) Na figura, o tempo mostrado no
eixo vertical e os objetos envolvidos na sequncia de uma atividade, no eixo horizontal.
(CESPE - 2010 - DETRAN-ES - Analista de Sistemas) O uso da linguagem de modelagem unificada,

conhecida como UML, recomendado para a anlise orientada a objetos, mas no para o projeto
orientado a objetos, que deve ser realizado por meio do suporte de linguagens de programao
orientadas a objetos.
Sistemas) Um diagrama de implantao pode ser utilizado quando o software projetado para ser
executado sobre uma nica mquina individual que no se comunica com outro hardware. A modelagem
em conjunto com diagramas de componentes, como ilustrado na figura a seguir, no possvel na UML.
01176992910

(CESPE - 2010 - TRE- - Analista Judicirio - Anlise de Sistemas) O propsito maior de um caso de uso
fornecer uma descrio do comportamento do sistema. Assim, em um processo de desenvolvimento
orientado a objetos, os objetivos de um caso de uso so: definir escopo, detalhar os processos e clculos
do sistema, organizar e dividir o trabalho, estimar o tamanho do projeto e direcionar os testes.
12. (CESPE - 2010 - TCU - Auditor Federal de Controle Externo - Tecnologia da Informao - Parte II) UML
(Unified Modeling Language) uma tecnologia concorrente com o processo unificado, no que diz
respeito ao apoio prtica de engenharia de software orientada a objetos.
13. (CESPE - 2010 - Banco da Amaznia - Tcnico Cientfico - Tecnologia da Informao - Anlise de
Sistemas) De acordo com as caractersticas da relao entre a classe Funcionario e a classe Curriculo, ao
se excluir um funcionrio desse sistema, tambm sero removidos os respectivos dados curriculares da
base de dados.
14. (CESPE - 2008 - TRT - 5 Regio (BA) - Analista Judicirio - Tecnologia da Informao) No diagrama,
Bicicleta e Veiculo_motor so tipos de veculos e, dessa forma, tm relao de herana com veculo.
correto afirmar que veculo subclasse de Bicicleta e Veiculo_motor.
01176992910
15. (CESPE - - ANAC - Tcnico Administrativo - Informtica) Geradores de cdigo 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 cdigo.

16. (CESPE - - SECONT-ES - Auditor do Estado Tecnologia da Informao) 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 descrio do fluxo de eventos de forma
suficientemente clara para que os seus usurios sejam capazes de compreend-lo. Nesse fluxo, devem
ser includas definies relacionadas forma de implementao, para que sejam diretamente utilizadas
pelos implementadores.
17. (CESPE - - SECONT-ES - Auditor do Estado Tecnologia da Informao) Diagramas de interao

so utilizados na UML para modelagem dos aspectos dinmicos do sistema. No diagrama de sequncia
- um diagrama de interao em que dada nfase ordenao temporal das mensagens -,
explicitamente representada a linha de vida do objeto, bem como o perodo durante o qual ele est
desempenhando uma ao.

Desenvolvimento) O diagrama de atividades tem por objetivo mostrar o fluxo de atividades em um nico
processo; entretanto, esse diagrama no mostra como as atividades dependem umas das outras, porque
isso responsabilidade do diagrama de dependncias.
19. (CESPE - 2010 - EMBAS - Analista de Saneamento - Analista de Tecnologia da Informao -

Desenvolvimento) Um diagrama de estado capaz de mostrar os estados possveis de um objeto. Alm
disso, pode mostrar as transaes responsveis pelas suas mudanas de estado.

Desenvolvimento) O objetivo principal de um diagrama de pacotes agrupar os pacotes em classes.
Esse tipo de diagrama pode usar dependncias.

Desenvolvimento) Um diagrama de casos de uso descreve um cenrio que mostra as funcionalidades do
sistema do ponto de vista do usurio. comum o uso de atores nesse diagrama.
22. (CESPE - 2010 - EMBASA - Analista de Saneamento - Analista de Tecnologia da Informao

Desenvolvimento) Os diagramas em UML podem ser estticos ou dinmicos. O diagrama de classes
um exemplo de um diagrama dinmico.

Desenvolvimento) possvel criar um diagrama de transio de estados que descreva o ciclo de vida de
um objeto em nveis de detalhe arbitrariamente simples ou complexos, dependendo das necessidades,
01176992910
pois no h a obrigao de ilustrar todos os eventos possveis.
24. (CESPE - - TCU - Analista de Controle Externo - Tecnologia da Informao - Prova 2) O mtodo
#Cadastrar( ) da classe Instrutor tem visibilidade do modo protegido tal que somente a classe possuidora
Instrutor pode utiliz-lo.

25. (CESPE - 2004 - TRE-AL - Analista Judicirio - Especialidade - Anlise de Sistemas - Desenvolvimento)
Na UML, um diagrama de estados mostra os vrios estados pelos quais passa um objeto e as transies
de um estado para outro.
26. (CESPE - 11 - BRB - Analista de Tecnologia da Informao) O diagrama de atividade, considerado

independente do diagrama de mquina de estado, serve para descrever os passos a serem percorridos
para a concluso de uma atividade especfica.
27. (CESPE - 2011 - BRB - Analista de Tecnologia da Informao) 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 compem.
28. (CESPE - 10 - TRE-BA - Tcnico Judicirio - Programao de Sistemas) Um cenrio, tambm

denominado instncia de caso de uso, uma sequncia especfica de aes e interaes entre atores e
o sistema em discusso. Assim, um caso de uso uma coleo de cenrios relacionados de sucesso e
fracasso, que descrevem atores usando um sistema como meio para atingir um objetivo.
29. (CESPE - 2010 - TRE-BA - Tcnico Judicirio - Programao de Sistemas) Os diagramas de classes podem
conter pacotes ou subsistemas, utilizados para agrupar elementos do modelo em um conjunto maior.
01176992910
No nvel de visibilidade privado, uma caracterstica pode ser usada por qualquer descendente do
classificador; contudo, um classificador nem sempre capaz de visualizar outro classificador.
30. (CESPE - 2011 - -ES - Tcnico de Informtica - Especficos) A modelagem que permite a identificao
de funcionalidades, comportamento do sistema, ambiente, relaes entre agentes e detalhe de requisitos
funcionais representada por meio de diagrama de sequncia de atividades.
diagrama de componentes deve ser utilizado para se representar a configurao e a arquitetura de um
sistema no qual estaro ligados todos os software e hardware, bem como sua interao com outros
elementos de suporte ao processamento.

32. (CESPE - 2011 - TRE-ES - Tcnico - Programao de Sistemas - Especficos) RUP e UML so
interdependentes, isto , no h como se aplicar o RUP no desenvolvimento de um sistema se no se
utilizar o UML.
33. (CESPE - 2010 - MPU - Analista de Informtica - Desenvolvimento de Sistemas) Na UML, um diagrama
de atividades oferece uma notao para mostrar uma sequncia de atividades, inclusive atividades
paralelas. Ele pode ser aplicado em qualquer perspectiva ou propsito, no entanto, normalmente mais
utilizado para a visualizao de fluxos de trabalho, processos de negcios e casos de uso.
34. (CESPE - - SECONT-ES - Auditor do Estado Tecnologia da Informao) UML um mtodo para
desenvolvimento de software que foi proposto para ser aplicado anlise e projeto de software
orientados a objetos.
35. (CESPE - - SECONT-ES - Auditor do Estado Tecnologia da Informao) UML (Universal Modeling
Language) uma linguagem de modelagem proprietria que pode ser utilizada no desenvolvimento de
sistemas de maneira intuitiva para visualizao de objetos.
36. (CESPE - 2011 - BRB - Analista de Tecnologia da Informao) O diagrama de casos de uso o mais
especfico e formal da UML, pois, alm de servir de referncia para a construo de outros diagramas,
utilizado nas fases de levantamento de sistemas e pode ser consultado durante todo o processo de
modelagem.
37. (CESPE - 2010 - TRE-BA - Tcnico Judicirio - Programao de Sistemas) Na UML, os diagramas de
sequncia e os diagramas de atividade, tambm denominados diagramas de interao, auxiliam a
modelar os aspectos dinmicos de sistemas. Um diagrama de interao formado pelo conjunto de
objetos e seus relacionamentos e inclui as mensagens que podero ser enviadas entre eles.
diagrama de classes define todas as classes de que o sistema necessita e a base para a construo dos
diagramas de sequncia e comunicao.
39. (CESPE - 2011 - TRE-ES - Tcnico - Programao de Sistemas - Especficos) Em um diagrama de

sequncia, esto representadas classes, que no so relacionadas por agregao e composio, entre
outros tipos de relaes presentes em diagramas de classe, mas relacionadas, diretamente, por meio de
mensagens.
Sistemas) Um caso de uso pode no gerar um diagrama de sequncia, a exemplo do que ocorre com
01176992910
os de tipo <<extend>>.
41. (CESPE - 2013 - TRT - 10 REGIO (DF e TO) - Analista Judicirio - Tecnologia da Informao) As mtricas
de software podem ser classificadas em medidas diretas ou quantitativas e medidas indiretas ou
qualitativas.
42. (CESPE - 2013 - TRT - 10 REGIO (DF e TO) - Analista Judicirio - Tecnologia da Informao) Mtricas
quantitativas, normalmente, exigem anlise e esto relacionadas com a funcionalidade, a qualidade, a
complexidade e a manuteno do software.
43. (CESPE - 2011 - TRE-ES - Tcnico - Programao de Sistemas - Especficos) As mtricas orientadas a
tamanho medem a funcionalidade entregue pela aplicao ao usurio como valor de normalizao.

44. (CESPE - 2009 - ANTAQ - Analista Administrativo Informtica Mtricas de produto dinmicas so
coletadas por meio de medies realizadas em representaes do sistema, como projeto, programa ou
documentao, ao passo que mtricas de produto estticas so coletadas em programas em execuo.
45. (CESPE - - ANTAQ - Analista Administrativo - Informtica Dois tipos de mtricas tm sido usados
para estimativas de produtividade do desenvolvimento de software: as relacionadas a tamanho de algum
resultado de uma atividade, como, por exemplo, linhas de cdigo fonte entregues, nmero de instrues
de cdigo objeto, nmero de pginas de documentao, e as relacionadas a funes - funcionalidade
geral do software entregue. A produtividade expressa em termos de quantidade de funcionalidade til
produzida em um dado tempo, como, por exemplo, pontos por funo, pontos por objeto.
46. (CESPE - - TCU - Analista de Controle Externo - Tecnologia da Informao - Prova 2 A medida de
complexidade ciclomtica avalia o nmero de caminhos de execuo diferentes de um dado programa,
sendo diretamente relacionada facilidade de compreenso do programa. Calculada a partir da anlise
de um grafo dirigido, representa os possveis caminhos de execuo do programa, e desvios
incondicionais contribuem para o aumento de valor desse clculo.
47. (CESPE - 2012 - Banco da Amaznia - Tcnico Cientfico - Anlise de Sistemas) Por meio da distribuio
da carga de processamento entre diferentes servidores, possvel aumentar a escalabilidade do sistema
computacional utilizando-se o modelo cliente-servidor multicamadas.
48. (CESPE - 2012 - Banco da Amaznia - Tcnico Cientfico - Anlise de Sistemas Na arquitetura cliente-
servidor multicamada, a camada intermediria capaz de armazenar requisies de clientes em uma fila,
permitindo que o cliente requisite algo camada intermediria e desconecte-se, sem ter de ficar espera
da resposta, o que aumenta a velocidade de processamento do cliente.
49. (FCC - 2010 - TRT - 20 REGIO (SE) - Tcnico Judicirio - Tecnologia da Informao) A arquitetura
multicamadas divide-se em trs camadas lgicas. So elas: Apresentao, Negcio e Acesso a Dados.
50. (FCC - - TRF - 5 REGIO - Analista Judicirio - Tecnologia da Informao) Via de regra as divises
da arquitetura de software em trs camadas orientam para nveis que especificam a apresentao, as
regras de negcio e o armazenamento de dados.
01176992910
1 2 3 4 5 6 7 8 9 10
C E E C C C C C E E
11 12 13 14 15 16 17 18 19 20
E E C E C E C E C E
21 22 23 24 25 26 27 28 29 30
C E C E C C C C E E
31 32 33 34 35 36 37 38 39 40
E E C E E E C C E C
41 42 43 44 45 46 47 48 49 50
C E E E C C C C C C

Aula02 - Análise e Projeto Orientados A Objetos. UML

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aula02 - Análise e Projeto Orientados A Objetos. UML

Enviado por

Direitos autorais:

Formatos disponíveis

Edited with the trial version of

Foxit Advanced PDF Editor

Professor: Diego Carvalho

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 1 de 54

UML: VISO GERAL, MODELOS E DIAGRAMAS

Figura 1 - Booch, Jacobson e Rumbaugh.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 2 de 54

Figura 2 Metodologias que consolidaram a UML.

Pensem em como seria especificar um sistema inteiro apenas escrevendo ou falando! J

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 3 de 54

Na dcada de noventa, a arquitetura de software padecia de alguns problemas graves. Muitas

Figura 3 - Viso 4+1.

Viso de Desenvolvimento (ou Implementao): a viso da arquitetura do sistema sob o

Viso de Processo: a viso da arquitetura do sistema sob o ponto de vista do integrador,

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 4 de 54

Figura 4 - Diagramas da UML 2.2.

Diagramas Estruturais: representam aspectos estticos do sistema sob diversas vises

Diagramas Comportamentais: representam aspectos dinmicos do sistema como um conjunto

o Diagramas de Interao: so diagramas comportamentais que consideram o

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 6 de 54

Figura 5 - Partes de uma Classe.

Figura 6 - Formas de representao de classes.

Professor, eu posso inserir detalhes de implementao da linguagem de programao que eu escolhi?

Vamos responder a algumas perguntas relevantes. Professor, como se representa um atributo

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 7 de 54

Modificador Classe Subclasse Pacote Todos

Figura 7 - Relacionamentos da UML.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 8 de 54

Figura 8 - Relacionamento de Dependncia.

Relacionamento de Generalizao/Especializao: indica que a subclasse uma especializao da

herana, relacionamento de extenso ou relacionamento -um.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 9 de 54

Figura 9 - Relacionamento de Generalizao.

Observem que a Figura 9 apresenta um relacionamento em que Fruta uma generalizao de

Relacionamento de Realizao: um relacionamento entre dois elementos em que um elemento

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 10 de 54

Figura 10 - Relacionamento de Realizao.

Relacionamento de Associao: um relacionamento estrutural entre instncias e especifica os

Simples: um tipo de relacionamento mais forte que o relacionamento de dependncia e que

Figura 11 - Associao Simples.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 11 de 54

Qualificada: um tipo de relacionamento similar a associao simples, contudo possui um

Figura 12 - Associao Qualificada.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 12 de 54

Figura 13 - Associao do tipo Agregao.

Figura 14 - Associao do tipo Composio.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 13 de 54

O Diagrama de Objetos uma variao do Diagrama de Classes. Contudo, aqui no se trata da

Figura 15 - Diagrama de Objetos.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 14 de 54

O Diagrama de Componentes representa o sistema sob uma perspectiva funcional, expondo a

Os componentes representam peas que podem ser adquiridas e atualizadas independentemente.

Figura 16 - Diagrama de Componentes.

O Diagrama de Pacotes representa os pacotes e suas dependncias. Professor, o que um pacote?

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 15 de 54

Figura 17 - Diagrama de Pacotes.

O Diagrama de Implantao mostra o layout fsico de um sistema, revelando quais partes do

Os diagramas contm ns (equipamento na qual o sistema ser implantado) e artefatos

Figura 18 - Diagrama de Implantao.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 16 de 54

Figura 19 - Diagrama de Perfil.

A UML j oferece diversos esteretipos padronizados como <<interface>>, <<extends>> e

Diagrama de Estrutura Composta