Apostila - Análise e Modelagem de Objetos com UML

Prévia do material em texto

Análise e Modelagem de Objetos com UML
1
P
ó
s-
G
ra
d
u
aç
ão
 a
 D
is
tâ
n
ci
a
Análise e Modelagem 
de Objetos com UML
João Caldas Júnior
Elisamara de Oliveira
Análise e Modelagem de Objetos com UML
2
CONTEÚDO
APRESENTAÇÃO ........................................................................................................4
FUNDAMENTOS DA ORIENTAÇÃO A OBJETOS .......................................................4
1.1. Processo de Software e Modelos de Ciclo de Vida ...........................................4
1.2. Introdução à Orientação a Objetos ....................................................................6
1.2.1. Abstração .....................................................................................................7
1.2.2. Objetos e Classes ........................................................................................7
1.2.3. Atributos .......................................................................................................8
1.2.4. Operações e Métodos ..................................................................................9
1.2.5. Encapsulamento ..........................................................................................9
1.2.6. Herança .........................................................................................................9
1.2.7. Polimorfismo ..............................................................................................10
1.3. RUP - Rational Unified Process .......................................................................10
UML – UNIFIED MODELING LANGUAGE ............................................................... 11
2.1. Breve Histórico da UML .................................................................................. 11
2.2. Organização dos Diagramas da UML ..............................................................13
2.3. Diagramas da UML ..........................................................................................14
2.3.1. Diagrama de Casos de Uso ........................................................................14
2.3.2 Diagrama de Classes ...................................................................................14
2.3.3. Diagrama de Objetos ..................................................................................14
2.3.4. Diagrama de Pacotes ..................................................................................14
2.3.5. Diagrama de Sequência ..............................................................................14
2.3.6. Diagrama de Comunicação .........................................................................14
2.3.7. Diagrama de Atividades ..............................................................................15
2.3.8. Diagrama de Estrutura Composta ...............................................................15
2.3.9. Diagrama de Componentes .......................................................................15
2.3.10. Diagrama de Implantação ........................................................................15
2.3.11. Diagrama de Tempo .................................................................................15
2.3.12. Diagrama de Máquina de Estados ...........................................................15
2.3.13. Diagrama de Interação Geral ...................................................................16
2.4. O Futuro da UML ..............................................................................................16
DIAGRAMA DE CASOS DE USO ..............................................................................17
3.1. Análise de Requisitos e Diagramas de Casos de Uso ....................................17
3.2. Componentes de um Diagrama de Casos de Uso ...........................................17
3.2.1. Atores e Casos de uso ...............................................................................17
3.2.2. Relacionamentos ........................................................................................18
3.2.2. Documentação de um Caso de Uso ...............................................................
19
DIAGRAMA DE CLASSES .........................................................................................21
4.1. O Modelo Entidade-Relacionamento e o Diagrama de Classes ......................21
4.2. Componentes de um Diagrama de Classes ....................................................22
4.2.1. Classes ......................................................................................................22
4.2.2. Relacionamentos ........................................................................................22
4.2.3. Estereótipo ..................................................................................................23
4.2.4. Interface .....................................................................................................23
4.2.5. Classes de Associação ..............................................................................24
4.2.6. Enumeração ...............................................................................................24
4.2.7. Associação Reflexiva .................................................................................24
4.2.8. Escopo de Classe (visibilidade) .................................................................24
4.2.9. Classe Abstrata ...........................................................................................25
Análise e Modelagem de Objetos com UML
3
4.3. Construindo um Diagrama de Classes ............................................................25
4.4. Estereótipos da Classe ....................................................................................26
4.4.1. Classes de Fronteira .................................................................................26
4.4.2. Classes de Controle ...................................................................................28
4.4.3. Classes de Entidade ..................................................................................29
DIAGRAMAS DE INTERAÇÃO ..................................................................................30
5.1. Os Diagramas de Interação .............................................................................30
5.2. Diagrama de Sequência ..................................................................................30
5.3. Componentes de um Diagrama de Sequência ................................................31
5.3.1. Objetos ........................................................................................................31
5.3.2. Atores ........................................................................................................31
5.3.3. Mensagens ................................................................................................32
5.4. Distribuição de Fluxo de Controle em Diagramas de Sequência ...................32
5.5. Diagramas de Comunicação ............................................................................33
DIAGRAMA DE MÁQUINA DE ESTADOS E DIAGRAMA DE ATIVIDADES ..............36
6.1. Máquina de Estados e Atividades ....................................................................36
6.2. Diagrama de Máquina de Estados ...................................................................36
6.3.1. Estados .....................................................................................................37
6.3.2. Transições ..................................................................................................38
6.3.3. Condições de Guarda ................................................................................39
6.3.4. Ações .........................................................................................................39
6.4. Construindo um Diagramade Máquina de Estado .........................................39
6.5. Diagrama de Atividades .................................................................................39
6.6. Componentes de um Diagrama de Atividades .................................................39
6.7. Construindo um Diagrama de Atividades ..............................................................
41
6.8. Diagramas de Atividades Aninhados ..............................................................42
CONSIDERAÇÕES FINAIS .......................................................................................43
RESPOSTAS COMENTADAS DOS EXERCÍCIOS ....................................................44
Capítulo 1 ................................................................................................................44
Capítulo 2 ................................................................................................................44
Capítulo 3 ................................................................................................................44
Capítulo 4 ................................................................................................................45
Capítulo 5 ...............................................................................................................46
Capítulo 6 ................................................................................................................47
BIBLIOGRAFIA ...........................................................................................................49
Análise e Modelagem de Objetos com UML
4
APRESENTAÇÃO
Com o advento da modelagem de software, que é a 
atividade de construir modelos que expliquem as caracte-
rísticas ou o comportamento de um software ou sistema, 
surgiu a necessidade de transcrever elementos do mundo 
real para o mundo conceitual, de modo a se construir mo-
delos de software capazes de serem compreendidos por 
profissionais dos mais diversos segmentos. Para melhor 
se construir um projeto, podem ser utilizados diversos pa-
radigmas de modelagem, ou seja, diferentes “formas de 
abordar um problema”. 
Nesta disciplina vamos estudar o paradigma orientado 
a objetos, que é um paradigma de análise, projeto e de-
senvolvimento de sistemas de software baseado na com-
posição e interação entre diversas unidades de software 
chamadas de “objetos”.
O paradigma de orientação a objetos visualiza um sis-
tema de software como uma coleção de agentes interco-
nectados denominados objetos. Cada objeto é responsá-
vel por realizar tarefas específicas. É através da interação 
entre objetos que uma tarefa computacional é realizada. A 
principal vantagem da técnica orientada a objetos para a 
modelagem de sistemas é a diminuição da diferença se-
mântica entre a realidade sendo modelada e os modelos 
construídos.
Para apresentar o modelo de objetos é necessário o 
uso de uma ferramenta de modelagem. Utilizaremos nes-
ta disciplina o modelo proposto pela UML. A UML - Unified 
Modeling Language é uma linguagem de modelagem que 
permite que os desenvolvedores visualizem o produto de 
seu trabalho através de diagramas padronizados. Jun-
to com a notação gráfica, a UML também especifica os 
significados, isto é, a semântica dos modelos. Assim, a 
UML não é uma metodologia de desenvolvimento, o que 
significa que ela não diz o que se deve fazer primeiro e 
em seguida como projetar seu sistema, mas ela auxilia 
a visualizar o desenho e a comunicação entre objetos do 
sistema sendo modelado. 
Nós lhe convidamos a conhecer o mundo da mode-
lagem de software por meio das técnicas da modelagem 
unificada baseada na UML, caro aluno. Os aspectos teó-
ricos e os conceitos da UML serão mesclados com a no-
tação, modelagem e relacionamento entre os diagramas. 
Você terá, além dos fundamentos teóricos, a possibilidade 
de ver exemplos práticos nos quais os diagramas foram 
aplicados na modelagem. Então, prepare-se, e venha jun-
to conosco conhecer este tema interessante nas próximas 
páginas deste material!
João Caldas Júnior 
Elisamara de Oliveira 
FUNDAMENTOS DA ORIENTAÇÃO A 
OBJETOS
Caro aluno, neste capítulo falaremos sobre a 
importância do processo de desenvolvimento de 
software no ambiente da Engenharia de Softwa-
re, relembraremos os conceitos sobre os ciclos 
de vida e abordaremos os conceitos básicos da 
Orientação a Objetos, bem como a relevância 
desses conceitos no cenário atual de desenvol-
vimento de software. Exemplificaremos alguns 
dos principais problemas no que se refere ao 
desenvolvimento de sistemas OO. 
1.1. Processo de Software e Modelos 
de Ciclo de Vida
Caro aluno, para entendermos melhor os conceitos 
fundamentais que envolvem a modelagem de um softwa-
re, faremos uma pequena introdução sobre a importância 
do processo de desenvolvimento de software, seu contex-
to e os modelos de ciclo de vida. 
Como vimos na disciplina Engenharia de Software e de 
Requisitos, um processo de desenvolvimento de software, 
ou simplesmente processo de software, pode ser defini-
do como um conjunto de disciplinas, atividades e tarefas 
necessárias para a geração de um produto de software, 
abordando desde sua concepção até o seu estado opera-
cional entregue ao usuário. 
Análise e Modelagem de Objetos com UML
5
Fonte: http://imasters.com.br/artigo/3834/software/inovacao-do-
processo-de-software
Um processo de software deve contemplar todo o 
acompanhamento e controle da produção do software, 
abordando os aspectos gerenciais que se fazem neces-
sários no transcorrer do desenvolvimento. As atividades 
de gerenciamento de um projeto de software prezam pelo 
correto andamento das atividades e tarefas executadas, 
bem como pela administração de falhas, imprevistos e 
mudanças que possam ocorrer em qualquer uma das dis-
ciplinas do processo. 
Pressman (2006) define processo como sendo “uma 
série de etapas que envolvem atividades, restrições e re-
cursos para alcançar a saída desejada”. Sua abordagem 
sobre o significado de processo é ampla e cita algumas 
características que, segundo ele, estão presentes em to-
dos os processos: 
 ● O processo prescreve todas as suas principais 
atividades;
 ● O processo utiliza recursos, está sujeito a um 
conjunto de restrições (como um cronograma) e 
gera produtos intermediários e finais;
 ● O processo pode ser composto de sub proces-
sos de algum modo relacionados. Ele pode ser 
definido como uma hierarquia de processos, or-
ganizados de tal maneira que cada sub proces-
so tenha seu próprio modelo de processo;
 ● Cada atividade do processo tem critérios de en-
trada e saída, de modo que seja possível saber 
quando o processo começa e quando termina;
 ● As atividades são organizadas em uma sequ-
ência, para que a ordem de execução de uma 
atividade em relação às outras seja clara;
 ● Todo processo tem um conjunto de diretrizes 
que explicam os objetivos de cada atividade. 
A forma como se encadeiam as etapas em um pro-
cesso de desenvolvimento é conhecida como modelo de 
processo ou modelo de ciclo de vida. Existe, porém, o 
ciclo de vida do projeto de software e o ciclo de vida do 
produto de software. Este último estende-se além do pro-
jeto e acompanha o produto de software da sua operação 
inicial, passando por possíveis manutenções até quando 
o software entra em desuso. O ciclo de vida do processo, 
por sua vez, é temporário e acaba ao final do projeto de 
desenvolvimento, porém deve ser maduro e capaz de ser 
repetido com o mesmo padrão de qualidade a cada novo 
produto que seja desenvolvido.
Há diversos modelos de ciclo de vida, no entanto, é 
consenso que não existe um modelo único que atenda 
a todos os projetos. O ciclo de vida deve ser escolhido 
de acordo com a natureza e características do projeto.Os 
modelos de ciclo de vida diferemum do outro na forma 
em que as diversas etapas de processo de software se 
relacionam entre si. 
Caro aluno, você já viu diversos processos de softwa-
re na disciplina Engenharia de Software e de Requisitos. 
Sugiro que você volte àquele material e revise o Modelo 
Cascata e o Modelo Iterativo Incremental, que são 2 dos 
modelos mais conhecidos e utilizados nas empresas de 
desenvolvimento de software. 
Leia o artigo “Conquistando Qualidade para o Pro-
jeto” de Marcelo Jacintho
Disponível em: http://www.internativa.com.br/artigo_
gestao.html
“...O ciclo de vida a ser adotado será uma das tônicas 
agora, pois dependendo das características do projeto, do 
cliente e da própria equipe, alguns modelos de ciclo de 
vida não são recomendáveis. Ainda, o famigerado e tão 
perseguido ciclo de vida Cascata, se estiver com grandes 
chances de ser escolhido, precisará sempre passar por 
uma crítica muito severa, haja vista que as estatísticas de 
desempenho da indústria mundial de TI, largamente divul-
gadas pelo Standish Group, apontam para um sucesso 
menor que 30% no resultado dos projetos, e, pesquisas 
Análise e Modelagem de Objetos com UML
6
1.2. Introdução à Orientação a 
Objetos
O termo OO- Orientação a Objetos pressupõe uma or-
ganização de software em termos de coleção de objetos 
discretos incorporando estrutura e comportamento pró-
prios. Esta abordagem de organização é essencialmen-
te diferente do desenvolvimento tradicional de software, 
onde estruturas de dados e rotinas são desenvolvidas de 
forma apenas fracamente acopladas. 
O paradigma OO tem como sua entidade essencial o 
objeto que recebe e envia mensagens, executa proces-
samentos e pode mudar de estado. Problemas são resol-
vidos através de objetos enviando mensagens a objetos.
A tabela 1 mostra, de forma simplificada, um paralelo 
entre a programação OO e a programação tradicional.
Tabela 1 – Programação OO x Pro-
gramação Tradicional
Programação OO Programação 
Tradicional
Métodos Procedimentos 
ou funções
Atributos Variáveis e dados
Mensagens Chamadas a 
procedimentos 
ou funções
Classes Tipos abstratos 
de dados
Hereditariedade -
Chamadas sob o 
controle do sistema
Chamadas sob o 
controle do programador
Na OO as funções e os dados são fundidos para formar 
a entidade objeto. Os objetos, diferentemente dos dados 
passivos das linguagens tradicionais, podem atuar. Suas 
ações são ativadas pelas mensagens enviadas e depois 
processadas por funções chamadas métodos.
Uma coleção de objetos similares é chamada classe. 
Uma instância de uma classe é um objeto. A maior abstra-
ção é conseguida pelo uso da hierarquia de classes. Para 
reutilizar métodos, as hierarquias de classe recorrem ao 
mecanismo exclusivo da OO que é a herança ou heredi-
tariedade.
Quando um programa OO é executado ocorrem 3 
eventos:
 ● Os objetos são criados de acordo com a neces-
sidade.
 ● As mensagens movimentam-se de um objeto 
para outro.
 ● Quando os objetos não são mais necessários, 
eles são apagados e a área na memória recu-
perada.
Fonte: http://ccsourcecode.blogspot.com.br/2011/05/o-que-e-
orientacao-objetos.html
correlatas apontam que a utilização de um ciclo de vida 
que não permite uma antecipação de riscos, nem testes 
de parciais do sistema em desenvolvimento, e que ignora 
a natureza mutável dos requisitos, está ligada a este ciclo 
e a este resultado. É claro que não podemos esquecer 
que é possível ser bem sucedido utilizando o Cascata, po-
rém o mercado vem sinalizando muito forte para a utiliza-
ção de modelos diferentes. ...”
Análise e Modelagem de Objetos com UML
7
O paradigma de orientação a objetos favorece a apli-
cação de diversos conceitos considerados fundamentais 
para o desenvolvimento de bons programas, tais como 
abstração, encapsulamento, herança e polimorfismo. 
Alguns conceitos não são exclusivos desta abordagem, 
mas são suportados de forma melhor no desenvolvimento 
orientado a objetos do que em outras metodologias.
Técnicas de orientação a objetos promovem o com-
partilhamento de recursos em diversos níveis distintos. 
Herança de estruturas de dados e comportamento per-
mite que estruturas comuns sejam compartilhadas entre 
diversas classes derivadas similares sem redundância. O 
compartilhamento de código usando herança é uma das 
grandes vantagens da orientação a objetos. Ainda mais 
importante que a economia de código é a clareza concei-
tual de reconhecer que operações sobre objetos diferen-
tes podem ser a mesma coisa, o que reduz o número de 
casos distintos que devem ser entendidos e analisados. 
O desenvolvimento orientado a objetos não apenas 
permite que a informação dentro de um projeto seja com-
partilhada como também oferece a possibilidade de rea-
proveitar projetos e código em projetos futuros. As ferra-
mentas para alcançar este compartilhamento, tais como 
abstração, encapsulamento, polimorfismo e herança, es-
tão presentes na metodologia; uma estratégia de reuso 
entre projetos é a definição de bibliotecas de elementos 
reusáveis. Entretanto, orientação a objetos não é uma fór-
mula mágica para se alcançar reusabilidade; para tanto, 
é preciso planejamento e disciplina para se pensar em 
termos genéricos, não voltados simplesmente para a apli-
cação corrente. 
No que se segue vamos estudar um pouco mais sobre 
os principais conceitos ligados à OO.
1.2.1. Abstração 
Abstração consiste em focalizar nos aspectos essen-
ciais inerentes a uma entidade e ignorar propriedades 
“acidentais”. Em termos de desenvolvimento de sistemas, 
isto significa concentrar-se no que um objeto é e faz antes 
de se decidir como ele será implementado. O uso de abs-
tração dá ao programador a liberdade de tomar decisões 
de desenvolvimento ou de implementação apenas quando 
há um melhor entendimento do problema a ser resolvido. 
Muitas linguagens de programação modernas supor-
tam o conceito de abstração de dados, porém, o uso de 
abstração juntamente com polimorfismo e herança, como 
suportado em orientação a objetos, é um mecanismo mui-
to mais poderoso. 
O uso apropriado de abstração permite que um mes-
mo modelo conceitual (orientação a objetos) seja utilizado 
para todas as fases de desenvolvimento de um sistema, 
desde sua análise até sua documentação. 
Na modelagem orientada a objetos uma das questões 
mais importantes consiste na identificação de abstrações 
que melhor descrevem o domínio do problema. É a capa-
cidade de identificação de aspectos semelhantes quanto 
à forma e ao comportamento que permitem a organização 
das classes.
1.2.2. Objetos e Classes 
Um objeto é definido como uma entidade concreta 
com limites e significados bem definidos para a aplicação 
sendo desenvolvida. Um objeto possui: 
 ● Identidade: característica que o distingue dos 
demais objetos
 ● Estado: conjunto de valores de seus atributos 
em um determinado instante
 ● Comportamento: reação apresentada às soli-
citações feitas por outros objetos com os quais 
se relaciona 
Os objetos têm dois propósitos: promover o entendi-
mento do mundo real e suportar uma base prática para 
uma implementação computacional. Não existe uma ma-
neira “correta” de decompor um problema em objetos; 
esta decomposição depende do julgamento do projetista e 
da natureza do problema. Todos os objetos têm identidade 
própria e são distinguíveis. 
Uma classe descreve um grupo de objetos com pro-
priedades (atributos) similares, comportamento (opera-
ções) similares, relacionamentos comuns com outros ob-
Análise e Modelagem de Objetos com UML
8
jetos e uma semântica comum. Por exemplo, considere 
que PessoaFisica e PessoaJuridica sejam classes de 
objetos. Entretanto, devido à distinção semântica, elas 
provavelmente estariam agrupadas em outra classe como 
Entidade.A figura 1 mostra outro exemplo de classe e objeto. 
Na figura 1 existe a classe Pessoa e uma enfermeira, um 
musico e um jogador seriam objetos desta classe.
Figura 1 – Exemplo de Classe e Objeto
Como se pode observar, o agrupamento em classes 
não leva em conta apenas o compartilhamento de proprie-
dades. O agrupamento de objetos em classes é um pode-
roso mecanismo de abstração. Desta forma, é possível 
generalizar definições comuns para uma classe de obje-
tos, ao invés de repeti-las para cada objeto em particular. 
Esta é uma das formas de reutilização e economia que a 
abordagem de orientação a objetos suporta. 
Nas classes são encontrados atributos e métodos que 
resumem as características comuns de vários objetos.
1.2.3. Atributos 
Um atributo é um valor de dado assumido pelos objetos 
de uma classe. É um dado ou informação de estado, para 
o qual cada objeto em uma classe tem seu próprio valor. 
Por exemplo, um objeto da classe PessoaFisica tem um 
nome e uma idade; cada objeto da classe PessoaJuridica 
também tem um nome e uma idade a partir da sua data de 
fundação; estes seriam atributos comuns das duas classes. 
Se considerarmos uma outra classe Transportes, por 
exemplo, cor, fabricante e modelo seriam possíveis atri-
butos de objetos Carro, que seriam instâncias da classe 
Transporte. 
Cada atributo tem um valor para cada instância de ob-
jeto. Diferentes instâncias de objetos podem ter o mesmo 
valor para um dado atributo. A figura 2 mostra um exemplo 
de atributos de objetos da classe Pessoa mostrada na figu-
ra 1. Estes atributos: nome, rg e idade são comuns a todos 
os objetos, mas seus valores são diferentes, neste caso.
Figura 2 – Exemplo de Atributos dos Objetos da Classe Pessoa
Diferença fundamental entre classes e objetos: 
• um objeto constitui uma entidade concreta com 
tempo e espaço de existência 
• a classe é somente uma abstração (tipo de dado 
definido pelo usuário)
Análise e Modelagem de Objetos com UML
9
1.2.4. Operações e Métodos 
Uma operação é uma função ou transformação que 
pode ser aplicada a objetos em uma classe. Por exemplo, 
abrir, salvar e imprimir são operações que podem ser apli-
cadas a objetos da classe Arquivo. Todos os objetos em 
uma classe compartilham as mesmas operações. 
Toda operação tem um objeto-alvo como um argumen-
to implícito. O comportamento de uma operação depende 
da classe de seu alvo. Como um objeto “sabe” qual é sua 
classe, é possível escolher a implementação correta da 
operação. Além disto, outros argumentos (parâmetros) 
podem ser necessários para uma operação. 
Uma mesma operação pode se aplicar a diversas 
classes diferentes. Quando isso acontece, uma operação 
como esta é chamada de polimórfica, ou seja, ela pode 
assumir distintas formas em classes diferentes. 
Um método é a implementação de uma operação para 
uma classe. Por exemplo, a operação imprimir pode ser 
implementada de forma distinta, dependendo se o arquivo 
a ser impresso contém apenas texto não formatado, é um 
arquivo de um processador de texto ou um arquivo biná-
rio. Todos estes métodos executam a mesma operação 
-- imprimir o arquivo; porém, cada método será implemen-
tado por um diferente código. 
Voltando ao exemplo da classe Pessoa, a figura 3 
mostra alguns métodos que poderiam ser aplicados aos 
seus objetos, como cadastrar, alterar, excluir.
Figura 3 – Exemplo de Métodos da Classe Pessoa
A assinatura de um método é dada pelo número e tipos 
de argumentos do método, assim como por seu valor de 
retorno. Uma estratégia de desenvolvimento recomendá-
vel é manter assinaturas coerentes para métodos imple-
mentando uma dada operação, assim como um compor-
tamento consistente entre as implementações. 
1.2.5. Encapsulamento 
Encapsular, ou “esconder informação”, consiste em 
separar os aspectos externos de um objeto, que são 
acessíveis a outros objetos, dos detalhes internos de sua 
implementação, que permanecem escondidos. O uso de 
encapsulamento evita que um programa torne-se interde-
pendente de tal maneira que uma pequena mudança pos-
sa provocar grandes efeitos colaterais. 
O uso de encapsulamento permite que a implementa-
ção de um objeto possa ser modificada sem afetar as apli-
cações que utilizam este objeto. Motivos para modificar 
a implementação de um objeto podem ser, por exemplo, 
melhoria de desempenho, correção de erros, mudança de 
plataforma de execução, dentre outros. 
Assim como a abstração, o conceito de encapsula-
mento não é exclusivo da abordagem de orientação a ob-
jetos. Entretanto, a habilidade de se combinar estrutura 
de dados e comportamento em uma única entidade, torna 
o encapsulamento mais elegante e mais poderoso do que 
em paradigmas convencionais que separam estruturas de 
dados e comportamento. 
1.2.6. Herança
Herança e generalização são abstrações poderosas 
para compartilhar similaridades entre classes e ao mes-
mo tempo preservar suas diferenças. Generalização é o 
relacionamento entre uma classe e uma ou mais versões 
refinadas (especializadas) desta classe. A classe sendo 
refinada é chamada de superclasse ou classe base, en-
quanto que a versão refinada da classe é chamada uma 
subclasse ou classe derivada. Atributos e operações co-
muns a um grupo de classes derivadas são colocadas 
como atributos e operações da classe base, sendo com-
partilhados por cada classe derivada. Diz-se que cada 
classe derivada herda as características de sua classe 
Análise e Modelagem de Objetos com UML
10
base. Algumas vezes, generalização é chamada de re-
lacionamento is-a (é-um), porque cada instância de uma 
classe derivada é também uma instância da classe base. 
Herança e generalização são transitivas, isto é, podem 
ser recursivamente aplicadas a um número arbitrário de 
níveis. Cada classe derivada não apenas herda todas as 
características de todos seus ancestrais como também 
pode acrescentar seus atributos e operações específicos. 
A herança é uma característica exclusiva da OO e per-
mite ao programador criar novas classes programando 
apenas as diferenças entre elas e a classe-pai, já que her-
dam dados e métodos desta. É o fruto de um mecanismo 
de hierarquia entre as classes, onde uma classe mais es-
pecializada (classe-filha) herda as propriedades da clas-
se mais geral (classe-pai) a que ela está imediatamente 
subordinada. Como falamos antes, a classe mais geral é 
denominada superclasse (ou classe base) e a classe mais 
especializada é chamada de subclasse (ou classe deriva-
da). Através da herança pode-se compartilhar automatica-
mente métodos e atributos entre diferentes classes.
A figura 4 mostra um exemplo de herança na classe 
Pessoa mostrada nas figuras 1, 2 e 3. No exemplo, nome, 
rg e idade são atributos da classe base Pessoa, que serão 
herdados pelas classes derivadas Aluno e Professor.
Figura 4 – Exemplo de Herança 
1.2.7. Polimorfismo 
Objetos agem em resposta às mensagens que rece-
bem. A mesma mensagem pode resultar em ações di-
ferentes quando recebidas por objetos diferentes. Esse 
fenômeno é conhecido como polimorfismo, que permite 
que um usuário possa enviar uma mensagem genérica e 
deixar os detalhes de implementação para o objeto recep-
tor. Uma mensagem de impressão, por exemplo, quando 
enviada a uma figura pode acessar métodos diferentes 
daqueles acessados quando é enviada para um texto. 
Polimorfismo significa “várias formas”. Para se aplicar 
polimorfismo é necessário que haja uma relação de he-
rança entre classes. Consiste em utilizar o mesmo método 
em situações diferentes, de acordo com a classe em que 
foi definido. O polimorfismo em uma mesma classe é cha-
mado de sobrecarga de método (overloading).
Como exemplo, consideremos a figura 6, em que o 
exemplo da classe Pessoa apresentado na figura 5 é re-
tomado.
Nafigura 5 podemos observar que os métodos cadas-
trar, alterar e excluir são os mesmos herdados da classe 
Pessoa, mas certamente estas operações relacionadas 
com Aluno e Professor têm implementações bastante dis-
tintas, em função dos dados associados a cada um deles.
Figura 5 – Exemplo de Polimorfismo
1.3. RUP - Rational Unified Process
Caro aluno, você também já estudou sobre o Processo 
Unificado na disciplina Engenharia de Software e de Re-
quisitos. Vamos retomar um pouco este tema aqui. Apro-
veite e volte ao material para relembrar...
Análise e Modelagem de Objetos com UML
11
O IBM Rational Unified Process®, ou RUP®, é uma 
plataforma de processo de desenvolvimento de software 
configurável que oferece melhores práticas comprovadas 
e uma arquitetura configurável. O RUP é baseado na me-
todologia orientada a objetos que define claramente quem 
é responsável pelo quê, como e quando as atividades de-
vem ser feitas e descreve todas as metas de desenvolvi-
mento para que sejam alcançadas. 
O RUP suporta a customização e autoria de processos 
e uma grande variedade de processos, ou de configura-
ção de processos, podem ser montadas em sua platafor-
ma. Essas configurações do RUP podem ser criadas para 
suportar tanto equipes grandes quanto pequenas, que 
trabalhem com técnicas de desenvolvimento bem discipli-
nadas ou menos formais. O produto RUP contém várias 
configurações e visões de processos prontas que guiam 
analistas, desenvolvedores, testadores, gerentes de pro-
jeto, gerentes de configuração, analistas de dados, e ou-
tros membros da equipe de desenvolvimento, em como 
desenvolver o software. Ele tem sido utilizado por muitas 
empresas em diferentes setores da indústria.
Para apresentarmos exemplos compreensíveis utili-
zando a UML ou Linguagem Unificada de Modelagem te-
remos de utilizar alguma noção de processo, visto que a 
UML não define a relação entre os diagramas. Portanto, 
em nossos exemplos, para especificar, modelar e docu-
mentar a relação entre os diagramas apresentados, utili-
zaremos conceitos relacionados ao processo RUP.
UML – UNIFIED MODELING 
LANGUAGE 
Caro aluno, neste capítulo falaremos sobre a 
UML, uma ferramenta essencial na modelagem 
de sistemas orientados a objetos. Abordaremos 
os conceitos básicos da modelagem unificada, 
como e quando ela surgiu, sua estrutura e seu 
futuro.
2.1. Breve Histórico da UML 
A sigla UML é o acrônimo de Unified Modeling Langua-
ge ou Linguagem de Modelagem Unificada de projetos 
 Leia mais sobre RUP – Rational Unified Process 
online e utilize-o!
UP significa Unified Process ou Processo Unificado e 
é um processo que define quem (papel funcional) faz o 
quê (artefato), como (atividades) e quando (disciplina) em 
um projeto de software. O RUP – Rational Unified Process 
é uma instância detalhada do UP. Possui uma grande 
quantidade de materiais para ajudar a melhorar a produ-
tividade da equipe. O RUP é um produto proprietário da 
Rational (IBM), mas no site colaborativo abaixo pode-se 
usá-lo e usufruir muitas das características do processo.
http://www.wthreex.com/rup/portugues/index.htm (em 
português)
http://www.wthreex.com/rup/smallprojects/index.htm 
(em inglês)
Exercícios do Capítulo 1 
1) O que é um Modelo de Ciclo de Vida de um 
software?
2) Quais as restrições à utilização do Modelo 
Cascata?
3) Categorize os relacionamentos listados a 
seguir. Atenção, podem existir associações 
binárias ou agregações na lista, portanto não 
presuma que todo relacionamento seja uma 
generalização. 
a. Um país possui uma capital 
b. Um filósofo à mesa de jantar está usando 
uma faca 
c. Uma conta corrente pode ser Normal ou 
Especial
d. Uma pessoa utiliza uma linguagem de pro-
gramação em um projeto 
Análise e Modelagem de Objetos com UML
12
orientados a objetos. Como o próprio nome diz, UML é 
uma linguagem de modelagem e não um método, meto-
dologia, processo ou linguagem de programação! 
A UML é uma lingua-
gem padrão de notação de 
projetos OO. Notação se 
refere aos instrumentos 
para especificar, visualizar 
e documentar os elemen-
tos de um sistema OO. A UML é importante, pois:
 ● serve como linguagem para expressar decisões 
de projeto que não são óbvias ou que não po-
dem ser deduzidas do código;
 ● provê uma semântica que permite capturar as 
decisões estratégicas e táticas do projeto;
 ● provê uma forma concreta o suficiente para a 
compreensão das pessoas e para ser manipula-
da pelas máquinas;
 ● é independente das linguagens de programação 
e dos métodos de desenvolvimento 
Além de fornecer a tecnologia necessária para apoiar 
a prática de Engenharia de Software orientada a objetos, 
a UML pode ser, também, a linguagem de modelagem pa-
drão para modelar sistemas concorrentes e distribuídos.
Nos anos 1990, conhecida como a época da “guerra 
dos métodos”, vários métodos coexistiam com notações 
muitas vezes conflitantes entre si. Dentre estes, os mais 
conhecidos eram:
 ● OMT- Object Modeling Technique, de Rumbaugh
 ● Método de Booch
 ● OOSE - Object Oriented Software Engineering, 
de Jacobson
Inicialmente, Rumbaugh e Booch fundiram seus mé-
todos (e notações) resultando no Método Unificado. em 
1995. quando trabalhavam juntos na Rational Software 
(atualmente uma divisão da IBM). Jacobson juntou-se a 
eles mais tarde e seu método OOSE foi incorporado ao 
novo processo denominado RUP - Rational Unified Pro-
cess. Além do método, eles unificaram a notação de pro-
jeto e a chamaram de UML – Unified Modeling Langua-
ge. Assim, UML representa a unificação das notações de 
Booch, Rumbaugh e Jacobson. 
Fonte:http://anaclaudiarocha.eti.br/imagens/Charge%20historico%20
da%20UML.JPG
A UML também agrega as ideias de vários outros auto-
res, tais como Harel e seu diagramas de estados, Shlaer-
-Mellor e o ciclo de vida dos objetos. Em resumo, a UML 
é o resultado da busca pela padronização dos artefatos 
de análise e projeto, quais sejam: modelos semânticos, 
sintaxe de notação e diagramas. 
Na década de 1990, surge uma organização importan-
te no mundo do paradigma orientado a objetos, a OMG 
- Object Management Group, uma entidade sem fins lu-
crativos da qual participam empresas e academias para 
definirem padrões de tecnologias OO.
No que se segue, apresentamos os principais marcos 
do desenvolvimento da UML:
 ● Em outubro de 1995 é lançada a primeira versão 
rascunho, versão 0.8 draft.
 ● Em Julho de 1996 é feita uma revisão devido ao 
ingresso de Jacobson, versão 0.9 draft.
 ● Parceiros da UML - HP, IBM, Microsoft, Oracle e 
Rational Software- desenvolveram a versão 1.1 
e a propuseram para a OMG
Análise e Modelagem de Objetos com UML
13
 ● Em novembro de 1997 a OMG aceita a proposta 
e assume a responsabilidade de realizar a ma-
nutenção e a revisão da UML
 ● Em março de 2003 a OMG lança a versão 1.5
 ● Em outubro de 2004 a OMG lança a versão 2.0
2.2. Organização dos Diagramas da 
UML
A UML utiliza-se de um conjunto de técnicas de nota-
ção gráfica para criar modelos visuais de software, com-
binando técnicas de modelagem de dados, negócios, ob-
jetos e componentes. É uma linguagem de modelagem 
unificada, comum e amplamente utilizável.
Embora possibilite representar o software através de 
modelos orientados a objetos, a UML não mostra que tipo 
de implementação deve ser feita, ou seja, não possui um 
processo que define detalhes de como o trabalho tem que 
ser desenvolvido. O seu objetivo é descrever “o que fa-
zer”, “como fazer”, “quando fazer” e “porque deve ser fei-
to”. É necessária a elaboração completa de um dicionário 
de dados para descrever todas as entidades envolvidas. 
Este processo permite que se realize o refinamento dos 
requisitos funcionais do software.
A Linguagem Unificadade Modelagem possui modelos 
ou diagramas (representações gráficas do modelo parcial 
de um sistema) que são usados, de forma combinada, 
com a finalidade de obter todas as visões e aspectos do 
sistema. Os diagramas da UML (veja figura 6) estão di-
vididos em Estruturais e Comportamentais e são os se-
guintes:
 ● Diagramas Estruturais
 - Diagrama de Classe
 - Diagrama de Objeto 
 - Diagrama de Componentes
 - Diagrama de Implantação
 - Diagrama de Pacotes 
 - Diagrama de Estrutura Composta
 ● Diagramas Comportamentais
 - Diagrama de Caso de Uso 
 - Diagrama de Máquina de Estados
 - Diagrama de Atividades
 - Diagramas de Interação, que dividem-se em:
 » Diagrama de Sequência
 » Diagrama de Interação Geral
 » Diagrama de Comunicação
 » Diagrama de Tempo
Figura 6 – Diagramas da UML
Fonte: http://www.infoescola.com/wp-content/uploads/2010/03/DiagramasdaUML.jpg
Análise e Modelagem de Objetos com UML
14
2.3. Diagramas da UML
Um diagrama é uma representação gráfica de um con-
junto de elementos, como classes, interfaces, colabora-
ções, componentes, nós, etc. Os diagramas são usados 
para visualizar o sistema sob diferentes perspectivas. A 
UML define um grande número de diagramas que permite 
dirigir o foco para aspectos diferentes do sistema de manei-
ra independente. Se bem usados, os diagramas facilitam 
a compreensão do sistema que está sendo desenvolvido. 
Nas próximas seções serão apresentados, de forma 
resumida, os diagramas que compõem a linguagem UML 
em sua versão 2.0. Nos próximos capítulos deste mate-
rial, os principais diagramas serão abordados separada-
mente e com maior detalhamento.
2.3.1. Diagrama de Casos de Uso
O diagrama de casos de uso especifica um conjunto de 
funcionalidades, através do elemento sintático “casos de 
uso”, e os elementos externos que interagem com o sis-
tema, através do elemento sintático “ator”. [SILVA, 2007] 
Além de casos de uso e atores, este diagrama contém 
relacionamentos de dependência, generalização e asso-
ciação.
Estes diagramas são basicamente usados para fazer a 
modelagem de visão estática dos casos de uso do siste-
ma. Essa visão proporciona suporte principalmente para 
o comportamento de um sistema, ou seja, os serviços ex-
ternamente visíveis que o sistema fornece no contexto de 
seu ambiente. Os diagramas de caso de uso são usados 
para fazer a modelagem do contexto de um sistema e fa-
zer a modelagem dos requisitos de um sistema.
2.3.2 Diagrama de Classes
Um diagrama de classes é um modelo fundamental de 
uma especificação orientada a objetos. Produz a descri-
ção mais próxima da estrutura do código de um programa, 
ou seja, mostra o conjunto de classes com seus atributos 
e métodos e os relacionamentos entre classes. Classes e 
relacionamentos constituem os elementos sintáticos bási-
cos do diagrama de classes. [SILVA, 2007]
2.3.3. Diagrama de Objetos
O diagrama de objetos consiste em uma variação do 
diagrama de classes em que são representadas instân-
cias e ligações entre instâncias de classes, que consti-
tuem os objetos. A finalidade é descrever um conjunto de 
objetos e seus relacionamentos em um ponto no tempo. 
Contém objetos e vínculos e são usados para fazer a mo-
delagem da visão de projeto estática de um sistema a par-
tir da perspectiva de instâncias reais.
2.3.4. Diagrama de Pacotes
Um pacote, em orientação a objetos, funciona como 
um “agrupador” que une e organiza um conjunto de clas-
ses, diagramas, arquivos ou mesmo outros pacotes de um 
sistema. Um diagrama de pacotes tem por finalidade tratar 
a modelagem estrutural do sistema particionando o mode-
lo em divisões lógicas, descrevendo as interações entre 
os pacotes e mostrando as dependências entre eles, uma 
vez que pacotes podem depender de outros pacotes. 
Este diagrama é muito utilizado para representar a 
arquitetura de um sistema mostrando o agrupamento de 
suas classes, já que um pacote pode representar um gru-
po de classes que se relacionam com outros pacotes atra-
vés de uma relação de dependência. 
2.3.5. Diagrama de Sequência
O diagrama de sequência mostra a troca de mensagens 
entre diversos objetos, em uma situação específica e deli-
mitada no tempo. Dá ênfase à ordenação temporal em que 
as mensagens são trocadas entre os objetos de um siste-
ma. Mensagens são os serviços solicitados de um objeto 
a outro e as respostas desenvolvidas para as solicitações.
O diagrama de sequência descreve a maneira como os 
grupos de objetos colaboram em algum comportamento 
ao longo do tempo. Geralmente registra o comportamento 
de um único caso de uso e exibe os objetos e as mensa-
gens passadas entre eles no caso de uso.
2.3.6. Diagrama de Comunicação
O diagrama de comunicação normalmente é utilizado 
como complemento do diagrama de sequência, embo-
ra possua um enfoque diferente já que concentra-se em 
como os objetos estão vinculados através de mensagens. 
Assim, pode ser gerado a partir do diagrama de sequência 
por representar os mesmos dados.
Análise e Modelagem de Objetos com UML
15
Este diagrama descreve objetos interagindo e seus 
principais elementos sintáticos são “objeto” e “mensagem”. 
Apresenta um formato alternativo para descrever a intera-
ção entre objetos. Ao contrário do diagrama de sequência, 
o tempo não é modelado explicitamente, uma vez que a 
ordem das mensagens é definida através de enumeração. 
Vale ressaltar que tanto o diagrama de comunicação como 
o diagrama de sequência são diagramas de interação.
2.3.7. Diagrama de Atividades
O diagrama de atividades representa a execução das 
ações e as transições que são acionadas pela conclusão 
de outras ações ou atividades. Diagramas de atividade 
são similares aos diagramas de fluxo de dados, com a 
diferença que as atividades são relacionadas aos objetos. 
Estes diagramas estão sempre associados a uma Classe, 
uma Operação ou um Caso de Uso.
Os diagramas de atividade suportam atividades sequen-
ciais e paralelas. Para as atividades executadas em parale-
lo não é importante a ordem na qual elas são executadas, já 
que podem ser executadas ao mesmo tempo ou uma após 
a outra. As atividades sequenciais são registradas através 
de ações e transições que seguem um ordenamento.
2.3.8. Diagrama de Estrutura Composta
O diagrama de estrutura composta detalha elementos 
de modelagem estrutural, como classes, pacotes e com-
ponentes, descrevendo sua estrutura interna. 
Este diagrama é utilizado essencialmente para mode-
lar colaborações. Uma colaboração descreve uma visão 
de um conjunto de entidades representadas por instâncias 
que cooperam entre si para executar uma função específi-
ca. Reflete a colaboração interna das classes para descre-
ver uma funcionalidade. O termo estrutura desse diagrama 
refere-se a uma composição de elementos interconecta-
dos, representando instâncias que colaboram, na linha do 
tempo de execução, por meio de vínculos de comunicação, 
para atingir algum objetivo comum. [GUEDES, 2007]
2.3.9. Diagrama de Componentes
O Diagrama de Componentes tem por finalidade indi-
car os componentes do software e seus relacionamentos. 
Um componente define seu comportamento em termos 
de interfaces fornecidas e requeridas. O diagrama pode 
ilustrar como as classes devem se encontrar organizadas 
através da noção de componentes de trabalho, podendo-
-se explicitar, para cada componente, qual das classes 
que ele representa. Este diagrama mostra os componen-
tes, como arquivos de código fonte, bibliotecas de progra-
mação ou tabelas de bancos de dados. As interfaces é 
que possibilitam as associações entre os componentes. 
 2.3.10. Diagrama de Implantação
O diagrama de implantação, também denominado 
diagrama de instalação, consiste na organização do con-
junto de elementos de um sistema para a sua execução. 
Descreve os componentesde hardware e software e sua 
interação com outros elementos de suporte ao processa-
mento. O principal elemento deste diagrama é o nó, que 
representa um recurso computacional. Podem ser repre-
sentados tanto os nós como as instâncias de nós. O dia-
grama de implantação é útil em projetos onde há muita 
interdependência entre partes de hardware e software.
2.3.11. Diagrama de Tempo
O diagrama de tempo consiste na modelagem de restri-
ções temporais do sistema. Apresenta o comportamento dos 
objetos e sua interação em uma escala de tempo, enfatizan-
do as condições que mudam no decorrer desse período.
Este diagrama descreve a mudança no estado ou con-
dição de uma instância de uma classe durante um período 
de tempo. É tipicamente utilizado para mostrar a mudança 
no estado de um objeto no tempo em resposta a eventos 
externos. 
2.3.12. Diagrama de Máquina de Estados
O diagrama de máquina de estados tem como elemen-
tos principais o estado, que modela uma situação na qual 
o elemento modelado pode estar ao longo de sua existên-
cia, e a transição, que leva o elemento modelado de um 
estado para o outro. O diagrama procura acompanhar 
as mudanças sofridas por um objeto dentro de um deter-
minado processo. Como o diagrama de sequência, este 
diagrama muitas vezes baseia-se em um Caso de Uso 
descrito em um diagrama de caso de uso e apoia-se no 
diagrama de classes. 
Análise e Modelagem de Objetos com UML
16
O diagrama de máquina de estados é utilizado geralmente para acompanhar os estados pelos quais uma instância 
de uma classe (objeto) passa. No entanto, pode ser utilizado para representar os estados de um caso de uso, os esta-
dos gerais de um subsistema ou mesmo de um sistema completo.
2.3.13. Diagrama de Interação Geral
O diagrama de interação geral é uma variação do diagrama de atividades e seus elementos sintáticos são os mes-
mos do diagrama de atividades. Fornece uma visão geral dentro de um sistema ou processo de negócio. As interações 
que fazem parte deste diagrama podem ser referências a diagramas de interação existentes na especificação do sis-
tema sendo modelado.
2.4. O Futuro da UML
Um sistema de software é inerentemente muito abstrato e, portanto, difícil de ser vi-
sualizado. Uma linguagem de modelagem, como a UML, contribui para se quebrar este 
alto nível de abstração, permitindo que o software possa ser visualizado em diferentes 
dimensões, de forma que o sistema possa ser compreendido antes de ser implementado. 
Além disso, a UML pode ser usada para produzir vários modelos do sistema com níveis 
crescentes de detalhamento.
 Um aspecto muito interessante, também, é que não somente sistemas novos podem ser modelados. A UML pode 
ser utilizada para modelar um sistema já existente, fornecendo uma visão mais adequada do mesmo para facilitar sua 
manutenção ou atualização. Além disso, a UML documenta um sistema. Um software bem documentado apresenta 
grande vantagem, já que o torna visível e transparente, facilitando sua compreensão e manutenção. 
Exercícios do Capítulo 2
1) Assinale “F” para falso ou “V” para verdadei-
ro:
( ) A UML pode ser utilizada somente para 
modelagem de sistemas ligados à área de 
Informática. 
( ) UML é uma linguagem para especificação, 
documentação, visualização e desenvolvi-
mento de sistemas orientados a objetos. 
( ) Ao se modelar um sistema utilizando a 
UML, segundo normas do grupo gestor da 
UML (Object Management Group - OMG), 
tem-se que utilizar pelo menos quatro de 
seus diagramas. 
( ) A UML é um método de desenvolvimen-
to, o que significa que ela diz o que fazer 
primeiro e em seguida como desenhar seu 
sistema.
A UML é uma linguagem unificada e universal e pode 
ser aplicada em muitas áreas de desenvolvimento de sof-
tware, já que foi concebida para fornecer mecanismos de 
especialização e extensão que permitem a modelagem de 
requisitos específicos de diferentes sistemas. Adicional-
mente, a UML é independente das linguagens de progra-
mação usadas e dos processos de desenvolvimento.
Com todas estas vantagens, a UML vem se tornando 
um padrão mundialmente utilizado para a modelagem de 
sistemas. Embora seu uso e sua aceitação sejam cres-
centes, o seu desenvolvimento não está estagnado e seus 
mecanismos estão sujeitos a aperfeiçoamentos. Além dis-
so, novas técnicas de modelagem podem ser definidas 
usando a própria UML como base.
Cada vez mais ferramentas de integração e padrões 
de implementação estão sendo criados baseados na 
UML. Isso vem facilitando o trabalho dos desenvolvedo-
res e disseminando, cada vez mais, o desenvolvimento 
de sistemas orientados a objetos.
Análise e Modelagem de Objetos com UML
17
DIAGRAMA DE CASOS DE USO
Caro aluno, neste capítulo descreveremos os 
diagramas de casos de uso da UML. Casos de 
uso são elementos classificadores que repre-
sentam uma unidade funcional coerente provida 
pelo sistema, subsistema, ou classe manifesta-
da por sequências de mensagens intercambiá-
veis entre os sistemas e um ou mais usuários. 
Os casos de uso podem possuir narrativas em 
texto, descrevendo a unidade funcional, e são 
amplamente utilizados para descobrir e registrar 
requisitos de sistemas.
3.1. Análise de Requisitos e Diagramas 
de Casos de Uso 
A criação dos diagramas de Casos de Uso acontece 
comumente na fase de Análise de Requisitos. Conforme 
estudamos na disciplina Engenharia de Software e de Re-
quisitos, é a fase responsável por manter a concordância 
entre os clientes e stakeholders sobre o que o sistema de-
verá fazer, além de possibilitar que a equipe de desenvol-
vimento compreenda os requisitos elencados e delimite o 
sistema e suas fronteiras. O profissional responsável por 
identificar os requisitos junto ao cliente, modelar casos de 
uso,e delimitar o sistema, expondo suas funcionalidades, 
é o Analista de Requisitos.
A Análise de Requisitos consiste em determinar os 
serviços que o usuário espera do sistema e as condições 
(restrições) sob as quais o sistema que será desenvolvido 
deva operar. As necessidades do usuário podem ser mui-
to variadas e o analista deve ser capaz de extrair os re-
quisitos funcionais e não-funcionais destas necessidades:
 ● Os requisitos funcionais expressam o com-
portamento de um software. As informações de 
entrada, o processamento e a saída emitida por 
uma funcionalidade são informações necessá-
rias para especificar seus requisitos.
 ● Os requisitos não funcionais mapeiam os as-
pectos qualitativos de um software, por exemplo: 
performance (tempo de resposta); segurança 
(restrições de acesso, privilégios); perspectiva 
do usuário (padrão das cores, disposição dos 
objetivos na tela); comunicabilidade (e-mail, 
VoIP, browser); usabilidade e portabilidade (a 
aplicação deve rodar em vários tipos de aplicati-
vos: móveis, desktop, note). 
Os Casos de Uso representam funcionalidades com-
pletas para o usuário e não funcionalidades internas do 
sistema. O diagrama de casos de uso é um artefato de 
comunicação entre cliente, usuários e desenvolvedores. 
Por ser extremamente simples e, consequentemente, de 
fácil compreensão, incentiva a participação do cliente e 
usuários no processo de desenvolvimento. Também serve 
como um contrato entre a equipe/empresa desenvolvedo-
ra e o cliente.
3.2. Componentes de um Diagrama de 
Casos de Uso
O Diagrama de Casos de Uso tem o objetivo de auxiliar 
a comunicação entre os analistas e o cliente. Um diagra-
ma de Caso de Uso descreve um cenário que mostra as 
funcionalidades do sistema do ponto de vista do usuário. 
Assim, o cliente deve ver no diagrama de Casos de Uso 
as principais funcionalidades de seu sistema. 
2) Faça a relação entre os conceitos e os dia-
gramas:
Análise e Modelagem de Objetos com UML
18
3.2.1. Atores e Casos de uso 
O diagrama de Casode Uso é representado por:
 ● atores
 ● casos de uso
 ● relacionamentos entre estes elementos 
Os casos de uso podem, opcionalmente, estar envol-
vidos por um retângulo que representa os limites do siste-
ma. No que se segue, estes elementos são apresentados 
em detalhes.
Atores
Um ator é representado por um boneco e 
um rótulo com o nome do ator. Um ator é um 
usuário do sistema, que pode ser um usuário 
humano ou um outro sistema computacional.
Caso de uso
Um caso de uso é repre-
sentado por uma elipse e um 
rótulo com o nome do caso 
de uso. Um caso de uso de-
fine uma grande função do sistema. A implicação é que 
uma função pode ser estruturada em outras funções e, 
portanto, um caso de uso pode ser estruturado.
3.2.2. Relacionamentos
Os relacionamentos nos diagramas de caso de uso po-
dem ser:
 ● associações entre atores e casos de uso
 ● generalizações entre os atores
 ● generalizações, extends e includes entre os ca-
sos de uso. 
Associação (entre um ator e um caso de uso)
 Define uma funcionalidade do sistema do ponto de vis-
ta do usuário.
Generalização (entre atores)
 Os casos de uso do Ator A são também casos de uso 
do Ator B.
O ator B tem seus próprios casos de uso.
Include (entre casos de uso)
Um relacionamento include de um caso de uso A para 
um caso de uso B indica que B é essencial para o compor-
tamento de A. Pode ser dito também que B é_parte_de A.
Extend (entre casos de uso)
Um relacionamento extend de um caso de uso B para 
um caso de uso A indica que o caso de uso B pode ser 
Análise e Modelagem de Objetos com UML
19
acrescentado para descrever o comportamento de A (não 
é essencial). A extensão é inserida em um ponto de exten-
são do caso de uso A.
Ponto de extensão em um caso de uso é uma indica-
ção de que outros casos de uso poderão ser adicionados 
a ele. Quando o caso de uso for invocado, ele verificará se 
suas extensões devem ou não serem invocadas.
Você entendeu?! Provavelmente, não. O extend é con-
siderado um conceito obscuro. Vamos a novas explica-
ções. Quando se especifica B extends A, a semântica é:
 ● Dois casos de uso são definidos: A e A extended 
by B;
 ● B é uma variação de A: contém eventos adicio-
nais, para certas condições;
 ● Tem que ser especificado onde B é inserido em A.
Generalização ou Especialização (é_um) 
Um caso de uso B é um tipo específico do caso de uso 
A (A é uma generalização de B, ou B é uma especializa-
ção de A).
Representa um relacionamento entre um caso de uso 
genérico para um mais específico, que herda todas as ca-
racterísticas de seu pai.
A figura 7 mostra um exemplo de um Caso de Uso. Este diagrama se refere ao projeto Casa Segura.
 Figura 7 - Diagrama de Caso de Uso para o Sistema Casa Segura
Análise e Modelagem de Objetos com UML
20
3.2.2. Documentação de um Caso de Uso 
O diagrama de casos de uso é apenas um panorama visual das funcionalidades 
do sistema; é necessária uma descrição textual para detalhar os casos de uso. 
Vejamos, como exemplo, o caso de uso “Autorizar Proprietário” apresentado no 
diagrama da figura 7. Para que este caso de uso fique mais bem esclarecido e do-
cumentado, criamos a tabela 2. A tabela 2 ilustra a documentação para este caso 
de uso contido no diagrama do sistema Casa Segura. A figura 8 ilustra uma possível 
interface para este sistema.
Tabela 2 – Documentação do Caso de Uso “Autorizar Proprietário” do sistema Casa Segura
Caso de Uso Autorizar Proprietário
Caso de Uso Geral Realizar a autorização de um proprietário
Ator Principal Proprietário
Pré-condição Sistema estar Ligado
Fluxo Principal 1) O proprietário digita seu username 
2) O proprietário digita sua senha
3) O proprietário pressiona o botão “Autorizar”
4) O sistema verifica as informações de login
5) O sistema apresenta a tela inicial da aplicação
Fluxos Alternativos 6) Numa situação de Exceção - A partir do passo 4
7) O sistema apresenta a tela de login
8) O proprietário digita seu username 
9) O proprietário digita sua senha
10) O sistema verifica que a senha e/ou username estão incorretos
11) O sistema mostra mensagem de erro
12) O proprietário re-digita o username e a senha
Pós-condição Proprietário Autorizado
Com base no que estudamos, podemos concluir que a saída da fase de análise de requisitos deve ser composta por:
 ● Lista de requisitos funcionais e não-funcionais;
 ● Diagrama de casos de uso e documentações textuais dos casos.
Figura 8 – Exemplo de uma interface para o sistema Casa Segura
Fonte: http://www.sraengenharia.blogspot.com.br/
Análise e Modelagem de Objetos com UML
21
DIAGRAMA DE CLASSES
Caro aluno, neste capítulo descreveremos o Diagrama de Classes que é um dos mais importantes diagramas 
da UML. Este diagrama está no centro da arquitetura de um sistema OO e é a partir dele que outros dia-
gramas são elaborados. O diagrama de classes é uma importante ferramenta para a documentação de um 
sistema ou produto de software OO. 
4.1. O Modelo Entidade-Relacionamento e o Diagrama de Classes
Um Diagrama de Classes é uma representação da estrutura e das relações das classes que servem de modelo para 
objetos de um sistema OO. O diagrama de classes é similar ao Modelo de Entidade-Relacionamento (MER) utilizado 
em banco de dados relacional, porém, ele se encontra em um nível de abstração de mais alto nível. Além disso, possui 
uma importante diferença em relação ao MER, pois representa o comportamento da classe através de suas operações 
ou métodos. A persistência é uma importante característica no conceito desse diagrama, uma vez que algumas classes 
podem representar, no projeto do sistema, entidades físicas que serão futuramente implementadas no banco de dados. 
Guedes (2008, p. 75) fornece um interessante relato comparando o MER com o diagrama de classes: “em muitos 
casos pode ser necessário preservar de maneira permanente os objetos de uma Classe, ou seja, esta deve ser per-
sistente. Uma classe persistente apresenta muitas semelhanças com uma entidade como aquelas definidas no antigo 
Modelo Entidade-Relacionamento utilizado para definir as estruturas de tabelas em bancos de dados relacionais. [...] 
Na verdade, o diagrama de classes foi intencionalmente projetado para ser uma evolução do Modelo Entidade-Relacio-
namento e pode ser utilizado para modelar a estrutura lógica das tabelas que irão compor um banco de dados.”
A figura 9 apresenta, a título de curiosidade, um exemplo de um MER.
No que se segue apresentaremos os principais componentes do diagrama de classes, juntamente com um exemplo 
ilustrativo.
Exercícios do Capítulo 3Descreva a posição do diagramas de casos de uso no processo de desenvolvimento incremental 
e iterativo. 
1) Faça uma tabela que mostre que tipos de relacionamentos são possíveis entre um ator e um caso de uso. 
Que tipo de relacionamento pode haver entre casos de uso? Que tipo de relacionamento pode haver entre 
atores?
2) Construa um modelo de casos de uso para a seguinte situação fictícia: “Estamos criando um serviço 
de entregas. Nossos clientes podem nos requisitar via portal do sistema a entrega de volumes. Alguns 
volumes são considerados de maior valor por nossos clientes, e, portanto, eles querem ter tais volumes 
segurados durante o transporte. Contratamos uma companhia de seguro para segurar volumes de valor
Análise e Modelagem de Objetos com UML
22
4.2. Componentes de um Diagrama de 
Classes
Segundo Fowler (2000, p. 57) “um diagrama de classes 
descreve os tipos de objetos no sistema e os vários tipos 
de relacionamentos estáticos que existem entre eles”. As 
classes representam as propriedades e o comportamento 
de um conjunto de objetos em um sistema. Como essas 
classes não existem sozinhas, é importante também re-
presentar os seus relacionamentos.4.2.1. Classes
As classes, no diagrama de classes, são representadas 
por um retângulo com, normalmente, três divisões, a saber: 
o nome da classe, os atributos e as operações; esses dois 
últimos, com os seus tipos e respectivos escopos. 
É importante que o nome da classe seja uma pala-
vra única, preferencialmente, sem caracteres especiais e 
acentuados, isso evitará problemas na geração do código 
fonte do diagrama.
Em uma classe, os atributos representam as proprie-
dades da classe e as operações, representam os métodos 
desta classe.
4.2.2. Relacionamentos
Associação
As associações representam as relações entre as 
ocorrências das classes. É um tipo de relacionamento es-
trutural e estático entre as classes. As associações, em 
um diagrama de classe, definem os tipos de ligações em 
que os objetos participam. Booch (2005) usa o termo “as-
sociação binária” para se referir a uma associação entre 
duas classes.
Figura 9 – Exemplo de um MER- Modelo Entidade-Relacionamento
Fonte: http://itsolutionsproject.wordpress.com/banco-de-dados-i/
Análise e Modelagem de Objetos com UML
23
Agregação
Descreve uma relação de dependência entre duas 
classes, é a descrição de um relacionamento todo-parte 
ou “parte de”, também conhecido como um relacionamen-
to do tipo “tem-um”. É um caso particular de associação. 
Esse tipo de relacionamento traz os conceitos de respon-
sabilidades entre classes. 
 A agregação é um tipo de relacionamento que não for-
ça a destruição do conjunto, ou seja, uma vez destruído 
o “objeto todo”, não há obrigatoriedade da destruição do 
“objeto parte”, assim, na figura, mesmo se uma equipe “X” 
acabar, o jogador poderá fazer parte de outra equipe.
Composição
A composição também é a descrição de um relaciona-
mento todo-parte ou “parte de”, é conhecido como “tem-
-um”, mas neste caso o “objeto parte” pertence somente 
a um “objeto todo”, ou seja, esse é um tipo de relaciona-
mento mais forte entre duas classes ou entidades. Esse 
tipo de relacionamento traz, assim como a Agregação, os 
conceitos de responsabilidades entre as classes, porém 
de forma mais acentuada.
 Segundo Sommerville (2007, p. 123), “nas agrega-
ções/composições, as partes são normalmente criadas e 
destruídas pelo todo. Na classe do objeto todo, são defi-
nidas as operações para adicionar e remover as partes”.
Multiplicidade
Multiplicidade é a indicação de quantos objetos podem 
participar de um relacionamento.
Nome do Papel
É uma descrição (rótulo explicativo) inserida na ponta 
de uma associação.
Generalização
A generalização é um relacionamento em que temos 
uma classe ancestral (supertipo) e outras classes herda-
das (subtipos). O subtipo deve incluir todos os elementos 
(atributos e operações) do supertipo. Na implementação 
física corresponde a um processo de herança. 
Esse tipo de generalização pode ser restringido de vá-
rias maneiras. Segundo Sommerville (2007), as restrições 
podem ser: 
 ● sobrepostas, para representar herança múltipla; 
Análise e Modelagem de Objetos com UML
24
 ● disjuntas, para subclasses que só poderão her-
dar de uma única classe; 
 ● completas, quando todas as classes herdadas 
possíveis foram definidas; 
 ● incompletas, quando nem todas as subclasses 
foram definidas.
4.2.3. Estereótipo
Segundo Booch (2005, p. 455) estereótipo trata-se de 
“uma extensão do vocabulário da UML, que permite a cria-
ção de novos tipos de blocos de construção derivados dos 
já existentes, mas que são específicos ao seu problema”. 
Os estereótipos são representados por aspas francesas 
<<nome do estereótipo>>. São normalmente predefinidos 
na própria linguagem UML mas, por outro lado, a equipe 
de desenvolvimento pode definir os seus próprios estere-
ótipos, assim esclarece Sommerville (2007). A UML tam-
bém permite que o usuário defina os estereótipos a serem 
utilizados em determinada situação de modelagem. Des-
sa forma, podemos ter estereótipos de dois tipos: predefi-
nidos ou definidos pela equipe de desenvolvimento.
4.2.4. Interface
A interface define apenas a assinatura dos métodos da 
classe sem apresentar sua implementação. Normalmen-
te, nas linguagens de programação orientadas a objetos, 
as interfaces não apresentam atributos. 
A interface implementa a programação por contrato. A fi-
gura ao lado apresenta duas representações de interface e 
o seu relacionamento com uma classe. No segundo exem-
plo note o uso do estereótipo para evidenciar a interface.
4.2.5. Classes de Associação 
O conceito de Classe de Associação permite acrescen-
tar atributos, operações e outras características às asso-
ciações. Esse tipo de associação traz a ideia de associa-
ção enésima. Nesse sentido, Booch (2005) lembra que a 
“associação enésima” se refere a uma associação entre 
três ou mais classes. 
Na figura abaixo, observe que, se um fornecedor pode 
oferecer mais de um produto e um produto pode ser ofere-
cido por mais de um fornecedor, temos um relacionamen-
to N para N. Caso o cliente deseje verificar a data e o valor 
total de um fornecimento, isso poderá ser resolvido facil-
mente por uma classe associativa de nome Fornecimento.
4.2.6. Enumeração
Enumeração é um recurso usado em várias linguagens 
de programação. São listas (literais) que podem ser arma-
zenadas como valores ou passadas como parâmetros. 
Para representá-las usa-se o estereótipo <<enumera-
ted>> ou <<enumeration>>. 
4.2.7. Associação Reflexiva
A Associação Reflexiva é também conhecida como 
auto-associação. Sua função é associar objetos de uma 
mesma classe. As associações reflexivas trazem o con-
ceito de “papéis assumidos por”. No exemplo ilustrativo a 
seguir vemos uma associação reflexiva na classe Funcio-
nário. Isso não significa dizer que o funcionário gerencia 
a si mesmo, mas que, em um determinado momento, um 
determinado objeto dessa classe assume o papel de Ge-
Análise e Modelagem de Objetos com UML
25
renciador (gerente) e em outro momento, outro objeto desta mesma classe, assume o papel de gerenciado (o vende-
dor, por exemplo).
Guedes (2008) denomina as associações reflexivas 
como associações unárias. Segundo esse autor, ocorre 
uma associação unária ou reflexiva quando “existe um re-
lacionamento de uma classe para consigo mesma”. 
A descrição do nome da associação reflexiva no dia-
grama de classe é importante, pois esclarece dúvidas so-
bre aquele tipo de associação, uma vez que apenas uma 
classe é envolvida. Melo (2002, p. 102) afirma que “....o 
nome da associação é mais usado quando pode haver 
dúvidas sobre o tipo de associação ou nas associações que envolvem uma única classe”. 
Nessa mesma linha de raciocínio, Sommerville (2007) relata que, para melhor esclarecer o significado das associa-
ções no diagrama de classes, a UML fornece, além do nome da associação, o direcionamento de leitura e o papel.
4.2.8. Escopo de Classe (visibilidade)
As propriedades, o comportamento das classes e a própria classe são definidos por identificadores específicos para 
cada situação. São eles:
 ● “+” ou público: especifica acesso dentro da classe, por elementos externos, e em classes descendentes; 
 ● “#” ou protegido: especifica acesso dentro da classe e por classes descendentes; 
 ● “-“ ou privado: especifica acesso somente dentro da classe que foi criada; 
 ● “~” ou pacote: especifica acesso dentro do pacote.
4.2.9. Classe Abstrata
É uma classe que não possui uma instância imediata. A classe abstrata fornece os elementos para que classes 
descendentes possam instanciar seus próprios objetos, cada um com suas particularidades. No Diagrama de Classes 
a classe abstrata é definida pelo estereótipo <<abstract>>.
4.3. Construindo um Diagrama de Classes
Agora vamos construir um Diagrama de Classe completo, usando as informaçõesque aprendemos nas seções an-
teriores. No sistema Casa Segura, quando o proprietário deseja selecionar uma câmera ele deve selecioná-la a partir da 
parede, segmento de parede, porta ou janela em que a mesma está instalada. Para esta seleção, o proprietário deve usar 
a planta baixa da casa, logo esta PlantaBaixa poderá ser modelada como uma classe que é composta por outra classe 
chamada Parede, que, por conseguinte possui associações binárias com as classes SegmentoDeParede, Porta e Janela. 
As câmeras também serão modeladas por classes que deverão estar associadas à classe PlantaBaixa. A figura 10 mostra 
uma proposta de solução de Diagrama de Classes para o sistema Casa Segura.
Análise e Modelagem de Objetos com UML
26
4.4. Estereótipos da Classe
Para dar prosseguimento à documentação de um sis-
tema, iniciada com os casos de uso, muitas vezes, em um 
projeto, existe a necessidade de representar elementos 
em um diagrama de classe que descrevam os mais va-
riados tipos de participações. Uma classe e seus objetos 
normalmente participam de formas diferentes no trans-
correr de um caso de uso. Ao representar uma classe, é 
importante definir que tipo de estereótipo se pode usar 
para qualificar esta participação. De acordo com o tutorial 
RUP (2001), os estereótipos de classe podem ser defini-
dos como: 
 ● Classes de Fronteira
 ● Classes de Controle
 ● Classes de Entidade
As classes de fronteira modelam as partes do sistema 
que dependem do ambiente. As classes de controle e de 
entidade modelam as partes que são independentes de 
fatores externos ao sistema. 
Além de fornecer orientações mais específicas do 
processo para se identificar classes, a criação de este-
reótipos é um modelo de objetos muito importante, pois 
permite que mudanças no modelo afetem somente uma 
área específica. Com esta modelagem, as mudanças na 
interface do usuário, por exemplo, irão afetar somente as 
classes de fronteira. As mudanças no fluxo de controle 
irão afetar somente as classes de controle. As mudanças 
em informações de longo prazo irão afetar somente as 
classes de entidade. 
Esses estereótipos são especialmente úteis para iden-
tificar classes em análise no projeto inicial. É muito prová-
vel que, em fases posteriores do projeto, seja necessário 
utilizar um conjunto de estereótipos ligeiramente diferente 
para fazer uma correlação melhor com o ambiente de im-
plementação, com o tipo de aplicativo, e assim por diante. 
No que se segue, estas três categorias de classes serão 
melhor explicadas e dicas serão fornecidas para que você 
consiga identificá-las e modelar o seu sistema, caro aluno.
Figura 10 - Diagrama de Classes para o Sistema Casa Segura
Análise e Modelagem de Objetos com UML
27
4.4.1. Classes de Fronteira 
A classe de fronteira é uma classe 
usada para modelar a interação entre o 
ambiente do sistema e seus trabalhos in-
ternos. Essa interação envolve transformar e converter 
eventos, bem como observar mudanças na apresentação 
do sistema (como a interface).
Portanto, alterar a GUI – Graphic User Interface (In-
terface Gráfica com o Usuário) ou o protocolo de comuni-
cação significa alterar somente as classes de fronteira, e 
não as classes de entidade e de controle.
As classes de fronteira também facilitam a compreen-
são do sistema, pois definem suas fronteiras. Elas aju-
dam no projeto, fornecendo um bom ponto de partida para 
identificar serviços relacionados. Por exemplo, se você 
identificar uma interface de impressora logo no início do 
projeto, perceberá de imediato que também deve modelar 
a formatação das impressões.
Algumas classes de fronteira comuns são janelas, pro-
tocolos de comunicação, interfaces de impressora, sen-
sores e terminais. Se você estiver usando um construtor 
GUI, não será necessário modelar partes da interface de 
rotinas (botões, por exemplo) como classes de frontei-
ra separadas. Geralmente, a janela inteira é o objeto de 
fronteira mais refinado. As classes de fronteira também 
são úteis para capturar interfaces para APIs – Application 
Program Interface (Interface de Programas de Aplicação) 
possivelmente não orientadas a objetos (como um código 
mais antigo, por exemplo).
Você deve modelar as classes de fronteira de acordo 
com o tipo de fronteira que elas representam. A comunica-
ção com outro sistema e a comunicação com um ator hu-
mano (através de uma interface do usuário) têm objetivos 
diferentes. Durante a modelagem da interface do usuário, 
a principal preocupação deve ser a forma como a inter-
face será apresentada a ele. Durante a modelagem da 
comunicação do sistema, a principal preocupação deve 
ser o protocolo de comunicação.
Um objeto de fronteira (uma instância de uma classe 
de fronteira) poderá durar mais que uma instância de caso 
de uso se, por exemplo, precisar ser exibido em uma tela 
entre o desempenho de dois casos de uso. Os objetos 
de fronteira, porém, costumam ter a mesma duração da 
instância de caso de uso.
Identificação de Classes de Fronteira 
Uma classe de fronteira faz a intermediação entre a 
interface e algo fora do sistema. Os objetos de fronteira 
isolam o sistema de mudanças externas (mudanças nas 
interfaces com outros sistemas, nos requisitos do usuário, 
etc.), impedindo que elas afetem o restante do sistema.
Um sistema pode ter vários tipos de classes de fronteira: 
 ● Classes de interface do usuário - classes que 
intermediam a comunicação com usuários hu-
manos do sistema, como um painel de controle 
que recebe a interação do usuário.
 ● Classes de interface do sistema - classes que 
intermediam a comunicação com outro sistema, 
como uma biblioteca que permite a troca de in-
formações com a internet.
 ● Classes de interface de dispositivo - classes 
que fornecem a interface para dispositivos (como 
sensores) que detectam eventos externos.
Identificação de Classes de Interface do Usuário
Podem existir classes de fronteira que representem a 
interface do usuário a partir de atividades de modelagem 
dessa interface. Quando apropriado, reutilize essas clas-
ses nessa atividade. Caso a modelagem de interface de 
Saiba Mais sobre Engenharia Reversa lendo o artigo 
“O que é Engenharia Reversa” de Oliver Hautsch publi-
cado em 28/09/2009
Disponível em:
http://www.tecmundo.com.br/pirataria/2808-o-que-e-
-engenharia-reversa-.htm
Análise e Modelagem de Objetos com UML
28
usuário não tenha sido feita, a discussão a seguir ajudará 
a localizar (ou identificar) essas classes.
Existe pelo menos um objeto de fronteira para cada 
par de atores de caso de uso. Esse objeto pode ser visto 
como tendo a responsabilidade de coordenar a interação 
com o ator. 
Ele também pode ter objetos secundários, aos quais 
delega algumas de suas responsabilidades. Isso é verda-
deiro para aplicativos GUI baseados em janela, nos quais 
geralmente existe um objeto de fronteira para cada janela 
ou para cada formulário. 
Identificação de Classes de Interface do Sistema
Uma classe de fronteira que se comunica com um sis-
tema externo e é responsável pelo gerenciamento do diá-
logo com esse sistema é chamada de classe de interface 
do sistema. Ela fornece a interface entre o sistema exter-
no e o sistema que está sendo criado.
A interface com um sistema existente pode já estar 
bem definida. Se estiver, as responsabilidades serão de-
rivadas diretamente da definição da interface. Se existir 
uma definição formal de interface, ela pode ser obtida por 
meio de engenharia reversa e isso precisa estar formal-
mente definido aqui. Simplesmente anote o fato de que a 
interface existente será reutilizada durante o projeto.
Identificação de Classes de Interface de Dispositivo
O sistema pode conter elementos que agem como se 
fossem externos, ou seja, podem ter seus valores altera-