Análise Orientada a Objetos II

Prévia do material em texto

2015
Análise OrientAdA A 
ObjetOs ii
Profa. Simone Cristina Aléssio
Copyright © UNIASSELVI 2015
Elaboração:
Profa. Simone Cristina Aléssio
Revisão, Diagramação e Produção:
Centro Universitário Leonardo da Vinci – UNIASSELVI
Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri 
UNIASSELVI – Indaial.
005.1
A372a Aléssio, Simone Cristina
 Análise orientada a objetos II/ Simone Cristina Aléssio. 
Indaial : UNIASSELVI, 2015.
 156 p. : il.
 
 ISBN 978-85-7830-934-3
 
 1. Programação Orientada a Objetos. 
 I. Centro Universitário Leonardo Da Vinci. 
III
ApresentAçãO
Prezado(a) acadêmico(a)! Seja bem-vindo(a) ao mundo da 
Programação Orientada a Objetos. 
Neste universo você vai se deparar com termos como atributos, 
métodos, abstração, encapsulamento, classes, hierarquia das classes, processo 
unificado, entre outros, que compõem o material de estudo desta disciplina e, 
por consequência, o dia a dia de um analista, desenvolvedor, programador, 
ou seja, o profissional da programação.
Este caderno pressupõe que você já possua alguma experiência 
anterior em programação, principalmente JAVA, afinal, muitos dos objetos, 
classes e diagramas apresentados neste material estão voltados a esta 
linguagem de programação. É essencial você fazer uso dos conhecimentos 
adquiridos em disciplinas anteriores para então conseguir acompanhar o 
desenvolvimento de um sistema e, assim, auxiliar você na construção do 
entendimento em programação orientada a objetos.
Aproveito a oportunidade para destacar a importância de desenvolver 
as autoatividades, afinal, cada exercício deste caderno foi desenvolvido para 
a fixação de conceitos por meio da prática. Em caso de dúvida na realização 
das atividades, sugiro que você entre em contato com seu tutor externo ou 
com a tutoria da UNIASSELVI, não prosseguindo as atividades sem ter 
sanado todas as dúvidas que irão surgindo.
Vale destacar a necessidade de dedicação e de muita determinação, 
afinal, a Programação Orientada a Objetos exige de você bem mais do que 
apenas este caderno para sua total compreensão. Aqui você recebe somente 
um início, ou seja, os conceitos de determinados pontos importantes na 
programação, porém, é somente na prática que você consegue compreender 
o mundo da programação como um todo.
Lembre-se de que o mundo da informática é encantador, assim, seu 
entusiasmo por este universo depende somente de você, destacando neste 
momento a compreensão da lógica envolvida no processo de construção de 
programas. Por este motivo, destaco uma frase que considero importante 
no caso da programação, afinal: “Para se ter sucesso, é amar de verdade o 
que se faz. Caso contrário, levando em conta apenas o lado racional, você 
simplesmente desiste. É o que acontece com a maioria das pessoas” (Steven 
Jobs – criador da Apple).
Bom estudo! Sucesso na sua trajetória acadêmica e profissional!
Simone Cristina Aléssio
IV
Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto 
para você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há 
novidades em nosso material.
Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é 
o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um 
formato mais prático, que cabe na bolsa e facilita a leitura. 
O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova 
diagramação no texto, aproveitando ao máximo o espaço da página, o que também 
contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo.
Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, 
apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade 
de estudá-lo com versatilidade nas telas do celular, tablet ou computador. 
 
Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para 
apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto 
em questão. 
Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas 
institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa 
continuar seus estudos com um material de qualidade.
Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de 
Desempenho de Estudantes – ENADE. 
 
Bons estudos!
NOTA
V
VI
VII
UNIDADE 1 – REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE 
CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: 
CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE 
MÁQUINA DE ESTADOS .......................................................................................... 1
TÓPICO 1 – REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE 
CONCEITOS DA UML .................................................................................................... 3
1 INTRODUÇÃO ..................................................................................................................................... 3
2 ORIENTAÇÃO A OBJETOS ............................................................................................................... 5
2.1 ABSTRAÇÃO .................................................................................................................................... 5
2.2 CLASSE ............................................................................................................................................. 6
2.2.1. Método .................................................................................................................................... 7
2.2.2 Responsabilidades .................................................................................................................. 7
2.2.3 Tipos de relacionamento entre classes ................................................................................. 8
2.2.4 Mensagem ................................................................................................................................ 10
2.2.5 Objeto........................................................................................................................................ 10
3 PROJETO ORIENTADO A OBJETOS .............................................................................................. 10
4 AS VÁRIAS OPÇÕES DA UML ........................................................................................................ 11
4.1 CONCEITOS DA ESTRUTURA DA UML ................................................................................... 12
4.1.1 Itens ........................................................................................................................................... 12
4.1.2 Itens estruturais ....................................................................................................................... 12
4.1.3 Itens comportamentais ........................................................................................................... 15
4.1.4 Itens de agrupamento ............................................................................................................ 15
4.1.5 Item anotacional ...................................................................................................................... 16
4.2 DIAGRAMAS ................................................................................................................................... 16
RESUMO DO TÓPICO 1........................................................................................................................ 19
AUTOATIVIDADE .................................................................................................................................20
TÓPICO 2 – MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, DIAGRAMA 
DE CASOS DE USO ......................................................................................................... 21
1 INTRODUÇÃO ..................................................................................................................................... 21
2 UML ......................................................................................................................................................... 22
3 DIAGRAMAS DA UML ...................................................................................................................... 23
3.1 DIAGRAMAS ESTRUTURAIS .................................................................................................. 25
3.2 DIAGRAMAS COMPORTAMENTAIS .................................................................................... 25
4 DIAGRAMAS COMPORTAMENTAIS .......................................................................................... 26
4.1 DIAGRAMA DE CASOS DE USO ................................................................................................ 27
4.2 ELEMENTOS DO DIAGRAMA DE CASOS DE USO ................................................................ 27
4.3 ELEMENTO ATORES ..................................................................................................................... 28
4.4 ELEMENTO CASOS DE USO ........................................................................................................ 28
4.4.1 Descrição .................................................................................................................................. 29
5 FLUXO DE EVENTOS ......................................................................................................................... 29
5.1 FLUXO BÁSICO ............................................................................................................................... 30
sumáriO
VIII
5.2 SUBFLUXO ....................................................................................................................................... 30
5.2.1 Pontos de extensão ................................................................................................................. 31
5.3 FLUXO ALTERNATIVO ................................................................................................................. 31
6 ELEMENTO RELAÇÕES ..................................................................................................................... 32
6.1 ASSOCIAÇÃO .................................................................................................................................. 32
6.2 ATOR X ATOR .................................................................................................................................. 32
6.3 ATOR X CASO .................................................................................................................................. 32
6.4 ELEMENTO DEPENDÊNCIA - INCLUSÃO E EXTENSÃO .................................................... 33
7 EXTENSÃO ............................................................................................................................................ 34
8 ELEMENTO GENERALIZAÇÃO/ESPECIALIZAÇÃO ................................................................ 34
9 DICAS IMPORTANTES ...................................................................................................................... 36
RESUMO DO TÓPICO 2........................................................................................................................ 39
AUTOATIVIDADE ................................................................................................................................. 40
TÓPICO 3 – DIAGRAMA DE ATIVIDADES E DIAGRAMA DE
 MÁQUINA DE ESTADOS .............................................................................................. 43
1 INTRODUÇÃO ..................................................................................................................................... 43
2 AÇÃO ...................................................................................................................................................... 45
3 ATIVIDADES ........................................................................................................................................ 45
4 EVENTOS ............................................................................................................................................... 45
5 NÓS DE CONTROLE .......................................................................................................................... 45
6 PONTOS DE EXTENSÃO ................................................................................................................... 45
7 OUTROS RECURSOS EM DIAGRAMAS DE ATIVIDADES .................................................... 47
8 RELAÇÃO COM OUTROS DIAGRAMAS ..................................................................................... 47
9 EXEMPLO DE CRIAÇÃO DE DIAGRAMA DE ATIVIDADES ................................................. 48
LEITURA COMPLEMENTAR ............................................................................................................... 53
RESUMO DO TÓPICO 3........................................................................................................................ 61
AUTOATIVIDADE ................................................................................................................................. 62
UNIDADE 2 – DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO) ...................................... 65
TÓPICO 1 – DIAGRAMAS DE INTERAÇÃO .................................................................................. 67
1 INTRODUÇÃO ..................................................................................................................................... 67
2 DIAGRAMA DE SEQUÊNCIA .......................................................................................................... 67
2.1 TIPOS DE MENSAGEM ................................................................................................................. 68
2.2 DIAGRAMA DE COMUNICAÇÃO ............................................................................................. 70
2.2.1 Principais componentes: objetos, mensagens e vínculo .................................................... 71
2.2.2 Notação: semelhante ao Diagrama de Sequência .............................................................. 72
2.2.3 Atores ........................................................................................................................................ 73
2.2.4 Condições ................................................................................................................................. 73
2.2.5 Autochamadas ........................................................................................................................ 74
2.2.6 Exemplo de Diagrama de Comunicação ............................................................................. 74
2.3 DIAGRAMA DE TEMPO ............................................................................................................... 75
2.4 DIAGRAMA DE VISÃO GERAL .................................................................................................. 76
RESUMO DO TÓPICO 1........................................................................................................................ 77
AUTOATIVIDADE ................................................................................................................................. 79
TÓPICO 2 – DIAGRAMAS ESTRUTURAIS: DE CLASSES E DE PACOTES
1 INTRODUÇÃO .....................................................................................................................................81
2 DIAGRAMA DE CLASSES ................................................................................................................ 81
2.1 CENÁRIO .......................................................................................................................................... 82
IX
2.2 IDENTIFICAR OS OBJETOS TANGÍVEIS ................................................................................... 84
2.3 AGRUPAR OS OBJETOS POR SEMELHANÇA ......................................................................... 85
2.4 DELIMITAR CLASSES REDUNDANTES OU QUE NÃO SÃO NECESSÁRIAS .................. 85
2.5 MONTANDO O DIAGRAMA DE CLASSE ................................................................................ 85
2.6 REALIZANDO AS PRIMEIRAS LIGAÇÕES ............................................................................... 86
3 DIAGRAMA DE CLASSE COMPLETO .......................................................................................... 88
3.1 DIAGRAMA DE PACOTES ........................................................................................................... 89
3.1.1 Definindo as classes de um Pacote ....................................................................................... 90
3.1.2 Principais componentes: pacotes .......................................................................................... 91
RESUMO DO TÓPICO 2........................................................................................................................ 93
AUTOATIVIDADE ................................................................................................................................. 95
TÓPICO 3 – DIAGRAMAS ESTRUTURAIS: DE OBJETOS E DE COMPONENTES .............. 97
1 INTRODUÇÃO ..................................................................................................................................... 97
2 PRINCIPAIS COMPONENTES: OBJETOS, RELACIONAMENTOS .................................... 97
3 DIAGRAMA DE COMPONENTES .................................................................................................. 99
3.1 PRINCIPAIS COMPONENTES: COMPONENTES, INTERFACES, CLASSES E 
RELACIONAMENTOS .................................................................................................................. 99
3.1.1 Componente ..........................................................................................................................100
3.1.2 Objetivos ................................................................................................................................100
3.1.3 Diagrama de Componentes .................................................................................................101
LEITURA COMPLEMENTAR .............................................................................................................103
RESUMO DO TÓPICO 3......................................................................................................................107
AUTOATIVIDADE ...............................................................................................................................108
UNIDADE 3 – DIAGRAMAS ESTRUTURAIS ...............................................................................109
TÓPICO 1 – DIAGRAMA DE IMPLANTAÇÃO E ESTRUTURA COMPOSTA ......................111
1 INTRODUÇÃO ...................................................................................................................................111
2 PRINCIPAIS COMPONENTES .......................................................................................................112
3 DIAGRAMA DE ESTRUTURA COMPOSTA ..............................................................................113
RESUMO DO TÓPICO 1......................................................................................................................117
AUTOATIVIDADE ...............................................................................................................................118
TÓPICO 2 – INTEGRAÇÃO DOS DIAGRAMAS – UMA VISÃO GERAL DO 
DESENVOLVIMENTO USANDO UML ..........................................................................................119
1 INTRODUÇÃO ...................................................................................................................................119
2 EXEMPLO DE DESENVOLVIMENTO DE PROJETOS USANDO UML ...............................119
RESUMO DO TÓPICO 2......................................................................................................................123
AUTOATIVIDADE ...............................................................................................................................124
TÓPICO 3 – ESTUDO DE CASO .......................................................................................................125
1 INTRODUÇÃO ...................................................................................................................................125
2 NECESSIDADE DE COMPREENDER OS PROCESSOS DA ORGANIZAÇÃO .................126
2.1 O MAPEAMENTO DE PROCESSOS .........................................................................................127
2.1.1 Fluxograma ...........................................................................................................................128
2.1.2 SADT (Structured Analysis and Design Technic) .................................................................129
2.1.3 IDEF3 .....................................................................................................................................129
2.1.4 UML (Unified Modeling Language) .......................................................................................130
2.1.5 Diagrama de Atividades ......................................................................................................130
2.1.6 Aplicação do Diagrama de Atividades da UML ..............................................................131
X
2.1.7 Avaliação da Aplicação do Diagrama de Atividades.......................................................136
2.1.8 Conclusões ............................................................................................................................137
LEITURA COMPLEMENTAR .............................................................................................................138
RESUMO DO TÓPICO 3......................................................................................................................150
AUTOATIVIDADE ...............................................................................................................................151
REFERÊNCIAS .......................................................................................................................................153
1
UNIDADE 1
REVISÃO DE CONCEITOS DE 
ORIENTAÇÃO A OBJETOS, REVISÃO 
DE CONCEITOS DA UML, DIAGRAMAS 
DE VISÃO COMPORTAMENTAL: CASOS 
DE USO, DIAGRAMA DE ATIVIDADES E 
DIAGRAMA DE MÁQUINA DE ESTADOS
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
A partir desta unidade, você será capaz de:
• revisar conceitos de Orientação a Objetos;
• revisar conceitos de UML;
• conhecer a visão comportamental dos diagramas da UML;
• elaborar diagramas de casos de uso, de atividades e máquina de estados.
Esta unidade de ensino contém três tópicos. Ao final de cada um deles você 
encontrará atividades que contribuirão para a apropriação dos conteúdos.
TÓPICO 1 – REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, 
REVISÃO DE CONCEITOS DA UML
TÓPICO 2 – MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, 
DIAGRAMA DE CASOS DE USO
TÓPICO 3 – DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA 
DE ESTADOS
2
3
TÓPICO 1
UNIDADE 1
REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, 
REVISÃO DE CONCEITOS DA UML
1 INTRODUÇÃO
Este tópico reapresenta conceitosque são o alicerce da disciplina, bem 
como os seus principais autores, conforme mostra a Figura 1. 
FIGURA 1 – ORIGEM E EVOLUÇÃO DA UML
Origem e evolução da UML
1962-1963
1962 - Krysten Nygaard e Ole-Johan
Dahl, pesquisadores do Centro de 
Computação da Noruega, em Oslo,
criam a linguagem Simula, derivada
do Algol, introduzindo os primeiros
conceitos de orientação a objetos.
1963 - Ivan Sutherland desenvolve,
no MIT (Massachusets Institute of
Tecnology), nos Estados Unidos, o
Sketchpad, primeiro editor gráfico
para desenhos orientado a objetos.
O Sketchpad usava conceitos de
instância e herança.
Ivan
Suthorland
Krysten
Nygaard
1969 1970 - 1983
Alan
Curtis Kay
Alan Curtis Kay apresenta sua tese
de doutorado intitulada The
Reactive Engine na Universidade
de Utah, na qual propõe
uma linguagem (Flex),
que contém conceitos
de orientação
a objetos.
É lançada linguagem de programação
Smaltalk, desenvolvida no centro de
pesquisas da Xerox em Palo Alto, Estados 
Unidos. Essa foi por muito tempo a única 
linguagem 100% orientada a objetos.
1980 - Surge a linguagem de programação
C++, que também pode ser
orientada a objetos.
1983 - Jean Ichbiah cria a linguagem
ADA a pedido do Departamento
de Defesa dos Estados Unidos,
também orientada a objetos.
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
4
1985 - 1989
Bertrand
Meyer
Bertrand Meyer lança a linguagem
Eifel, orientada a objetos.
1988 - Sally Shlaer e Stepen Mellor
publicam o livro Object-Oriented
Systems Analysis: Modeling the World in
Data, que propõe uma técnica para
análise e projetos orientados a objeto.
1989 - É criado o OMG (Object 
Management Group), que aprova
padrões para aplicações orientadas
a objeto.
Peter Coad e Ed Yourdon lançam o livro
Object - Oriented Analysis, também
contendo técnicas para análise e
projetos orientados a objeto.
Rebecca Wirfs - Brock, Brian Wilkerson
e Lauren Wiener publicam o livro
Designing Object - Oriented Software,
tratando de técnicas de modelagem
orientada a objetos.
1992 - Ivar Jacobson, Magnus Christerson,
Patrik Jonsson e Gunnar Overgaard
lançam o livro Object - Oriented
Software Enginnering: A Use Case Driven
1990 - 1993
1970 - 1983
Approach, também sobre técnicas
de orientação a objetos.
D. Embley, B. Kurtz, e S. Woodfield
publicam o livro Object - Oriented
System Analysis. A
Madel-Driven Approach.
1993 - Grady Booch
lança seu Booch Method
com técnicas para
análise e projeto
orientado a objetos.
É lançada linguagem de programação
Smaltalk, desenvolvida no centro de
pesquisas da Xerox em Palo Alto, Estados 
Unidos. Essa foi por muito tempo a única 
linguagem 100% orientada a objetos.
1980 - Surge a linguagem de 
programação C++, que também pode 
ser orientada a objetos.
1983 - Jean Ichbiah cria a linguagem
ADA a pedido do Departamento
de Defesa dos Estados Unidos,
também orientada a objetos.
James
Martin
James
Gosling
FONTE: Piva (2010)
Este tópico foi criado com o objetivo de revisar conceitos da disciplina 
de Análise Orientada a Objetos I, reapresentando os conceitos da UML, que 
possibilita visualização, especificação, construção e documentação de requisitos 
no desenvolvimento de software com orientação a objetos. Será exibido um 
pequeno histórico da UML e principais conceitos da metodologia orientada a 
objetos e sua representação na UML.
Três grandes nomes criaram a UML. Dois deles são norte-americanos: 
Grady Booch e James Rumbaugh, o terceiro é o suíço Ivar Jacobson. Juntos, em 
1995 lançaram a UML 0. Unificando os seus três métodos de estudos desenvolvidos 
individualmente:
Método de Booch: desenvolvido por Grady Booch, da Rational Software 
Corporation, expressivo principalmente nas fases de projeto e construção de 
sistemas.
OOSE (Object-Oriented Software Engineering), de Ivar Jacobson, que 
fornecia excelente suporte para casos de usos como forma de controlar a 
captura de requisitos, a análise e o projeto de alto nível.
TÓPICO 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML
5
OMT (Object Modeling Technique), de James Rumbaugh, que é um método 
de modelagem e projeto orientado a objetos publicado em 1991 por James 
Rumbaugh, Michael Blaha, Willian Premerlani, Frederick Eddy e Willian 
Lorensen, no livro Object-Oriented Modeling and Design.
FONTE: Disponível em: <http://issuu.com/geeadcps/docs/livro3_alta/81>. Acesso em: 5 out. 2015.
Kay foi considerado o pai da orientação a objetos. Foi ele quem definiu 
o computador como um organismo vivo, promovendo a independência das 
células, que, mesmo independentes, deveriam se relacionar ou juntar-se a outras, 
a fim de atingir um objetivo específico. 
À época do surgimento da linguagem Smalltalk, Kay era pesquisador da 
Xerox, e, em 1970, foi o primeiro a usar o termo “Orientação a Objetos”.
A UML oferece suporte em todas as etapas do desenvolvimento de software. 
Por este motivo, atualmente é considerada um padrão de desenvolvimento 
quando se utiliza da orientação a objetos.
2 ORIENTAÇÃO A OBJETOS
O objetivo da orientação a objetos é o de aproximar o desenvolvimento de 
software da realidade dos acontecimentos, do fluxo real da informação. Para isso, 
cria elementos e dados que tenham funcionalidades em si mesmos.
O conceito continua evoluindo, pois ainda existem limitações de hardware 
que se relacionam a problemas de acesso e armazenamento de dados, e de software 
relativas a processos do sistema operacional e a falta de sistemas gerenciadores 
de banco de dados orientados a objetos (PIVA, 2010).
2.1 ABSTRAÇÃO
Abstração é uma característica específica da entidade, fazendo com que a 
mesma se torne distinta de todas as outras entidades envolvidas em um modelo 
de dados.
A abstração foca o escopo da entidade. Por exemplo, ao pensarmos na 
entidade PRODUTO, não precisamos pensar em todos os atributos desta entidade. 
Posso focar a atenção apenas nos atributos principais e essenciais, os quais serão a 
característica desta entidade e que a tornarão exclusiva dentro de um modelo, na 
análise e desenvolvimento do sistema.
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
6
2.2 CLASSE
Para os autores Booch, Rumbaugh e Jacobson (2005), a classe descreve 
vários objetos, que juntos compartilham os mesmos atributos, operações, 
relacionamentos e semântica. A representação completa de uma classe tem quatro 
divisões, conforme podemos visualizar na Figura 2.
FIGURA 2 – REPRESENTAÇÃO DE UMA CLASSE 
Carro
- nomeFabricante: String
- nomeModelo: String
- cor: String
- numeroPortas: Int
- anoFabricação: Int
- velocidadeMaxima: double
+ abrirPortas( ): vold
+ fecharPortas( ): vold
+ ligar( ): vold
+ desligar( ): vold
+ acelerar( ): vold
+ frear( ): vold
+ trocarMarcha( ): vold
Responsabilidades
- Se locomover na
 velocidade e direção
 indicados pelo usuário.
- Acelerar quando
 solicitado.
- Frear quando
 solicitado.
Nome da classe
Responsabilidades
Métodos
Atributos
Defi nição da classe
segundo UML 2.
FONTE: Piva (2010)
FIGURA 3 – OUTRA FORMA DE REPRESENTAÇÃO DE CLASSE
Carro
- nomeFabricante: String
- nomeModelo: String
- cor: String
- numeroPortas: Int
- anoFabricação: Int
- velocidadeMaxima: double
+ abrirPortas( ): vold
+ fecharPortas( ): vold
+ ligar( ): vold
+ desligar( ): vold
+ acelerar( ): vold
+ frear( ): vold
+ trocarMarcha( ): vold
Carro
Outra forma de
representar uma
classe em UML 2.0.
FONTE: Piva (2010)
Nome da classe: Cada classe deve ter um nome único, que sejacapaz de 
diferenciar a mesma de outras classes (BOOCH; RUMBAUGH; JACOBSON, 2005).
TÓPICO 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML
7
Atributo: Pode ser entendido como um campo, uma propriedade que 
mantém valores cujas instâncias desse atributo podem apresentar (BOOCH; 
RUMBAUGH; JACOBSON, 2005).
2.2.1. Método
Para modificar o seu comportamento, um objeto da classe pode solicitar 
um serviço. É algo que muda o objeto e que pode afetar todos os objetos da classe 
(BOOCH; RUMBAUGH; JACOBSON, 2005). Relembre alguns dos principais 
métodos, conforme descrição abaixo:
Os métodos especiais
• Construtor: é o método que constrói, isto é, reserva o espaço em memória onde 
serão armazenadas as informações daquele objeto da classe.
• Get: é o método que apresenta o valor armazenado em determinado atributo 
de um objeto.
• Set: dá um valor a um atributo.
Os métodos Get e Set encapsulam os atributos de uma classe, garantindo 
que as alterações nos atributos sejam feitas única e exclusivamente por eles. Os 
atributos permanecem com visibilidade privada. Lembrando: 
Get (para retornar o valor que está no atributo). 
Set (para atribuir um valor a ele).
Normalmente, no processo de desenvolvimento são adotados um método 
Set e um método Get para cada atributo da classe.
• Destrutor: destrói o objeto criado da memória, liberando o espaço de memória 
alocado na sua criação. 
• Assinatura: é a primeira linha da definição de um método, no qual podemos 
observar sua visibilidade, seu nome, seus parâmetros de entrada e de retorno.
2.2.2 Responsabilidades
As responsabilidades remetem às obrigações das classes, que, quando 
criadas, estabelecem que todos os seus objetos terão o mesmo estado e tipo de 
comportamento. Por isso é possível representar uma classe apenas com seu nome 
ou com nome dos principais atributos e principais métodos, de acordo com o que 
se quer analisar ao iniciar a criação dos diagramas. 
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
8
2.2.3 Tipos de relacionamento entre classes
Dependência, associação e herança estabelecem os principais 
relacionamentos entre as classes.
1) Dependência: determina que um objeto de uma classe possa usar as informações 
e serviços de outra classe, que um objeto de uma classe use informações 
e serviços de um objeto de outra classe. A dependência é representada 
grafi camente por uma linha tracejada com uma seta indicando o sentido da 
dependência. Verifi que a representação na fi gura a seguir. A classe Janela é 
dependente da classe Evento. 
FIGURA 4 – DEPENDÊNCIA DA UML
Janela
- largura: double
- altura: double
+ abrir ( ): void
+ fechar ( ): void
+ tratarEvento ( ): void
Evento
- nome: String
+ start ( ): void
Representação de
uma dependência
em UML 2.0.
Exemplo de
associação entre
classes UML.
Funcionário
- salario: double
- nroCarteiraProfi ssional: String
Empresa
- nome: String
- ramoAtividade: String
- cnpj: String
Trabalha para ►
1..* *
empregadortrabalhador
FONTE: Piva (2010)
2) Associação: é um relacionamento de estrutura, que aponta os objetos de uma 
classe que estão conectados a objetos de outra classe estrutural que especifi ca 
objetos de uma classe conectados a objetos de outra classe. A associação é 
representada por uma linha interligando as duas classes.
FIGURA 5 – ASSOCIAÇÃO ENTRE CLASSES
FONTE: Piva (2010)
A fi gura a seguir apresenta um exemplo de agregação, que é um tipo de 
associação entre classes na qual é mostrada a relação todo-parte entre as classes. 
Uma classe é a parte, e a outra, o todo. 
TÓPICO 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML
9
FIGURA 6 – ASSOCIAÇÃO ENTRE CLASSES
Empresa
- nome: String
- ramoAtividade: String
- cnpj: String
Representação da
agregação entre
classes UML 2.0.
Representação de
uma composição
UML 2.0.
1
*
1
*
Departamento
- nome: String
ItemdePedido
-- descrição: String
- quantidade: Int
- precoUnitario: double
Pedido
- numero: Int
- data: Date
- valor Total: double
FONTE: Piva (2010)
Observe, na fi gura anterior, que uma empresa é formada por vários 
departamentos. Pode-se ver ainda que cada departamento está associado a 
uma empresa.
Não podemos esquecer-nos da composição, que nada mais é do que uma 
forma de agregação, tempo de vida semelhante entre as partes pelo todo. Pode-se 
afi rmar que numa relação de composição só faz sentido existir a parte se houver 
o todo (PIVA, 2010).
3) Herança: na herança, classes mais específi cas assumem a estrutura e o 
comportamento de classes mais gerais. A representação da Herança pode ser 
entendida pela representação da Figura 7, onde a classe Pessoa possui os atributos 
nome e cpf e pode executar os métodos de andar e falar. Já a classe Funcionario 
herda os atributos e métodos da classe Pessoa, possui nome, cpf, salário e 
nroCarteiraProfi ssional, podendo executar os métodos andar, falar e trabalhar. 
Logo, conclui-se que é a classe pai de Funcionario e que Funcionario é 
classe fi lha de Pessoa.
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
10
FIGURA 7 – REPRESENTAÇÃO DE HERANÇA
Pessoa
# nome: String
# cpf: String
+ andar ( ): void
+ falar ( ): void
Representação
de herança
utilizando UML.
Generalização
Especialização
Funcionario
- salario: double
- nroCarteiraProfi ssional: String
+ trabalhar ( ): void
FONTE: Piva (2010)
2.2.4 Mensagem
As mensagens confi guram uma forma de comunicação entre os objetos. Elas 
carregam informações de uma determinada atividade que está por ser executada. Os 
seja, objetos trocam informações para tornar possível o funcionamento dos sistemas.
2.2.5 Objeto
É pelo objeto que se concretiza a abstração, através de entidades bem 
defi nidas, entidades que encapsulam estados e comportamentos; é a instância 
de uma classe. Utilizando como exemplo um automóvel, podemos pensar nos 
atributos como sendo: o modelo, cor, ano de fabricação, combustível, e seus 
métodos como: andar, acelerar, frear, entre outros. Ao pensar nas responsabilidades 
do automóvel, podemos dizer que ele deve obedecer aos comandos que lhe são 
impostos, como aceleração, velocidade, trajeto etc. (PIVA, 2010).
3 PROJETO ORIENTADO A OBJETOS
Num projeto é necessário defi nir com precisão quais são as principais 
classes que irão compor a solução para a construção de determinado software. Em 
seguida, deve-se estabelecer como os objetos criados a partir dessas classes vão 
interagir entre si para atingir a solução proposta em termos de desenvolvimento 
de aplicação.
TÓPICO 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML
11
Deve-se projetar todo o funcionamento do sistema em detalhes. Um 
recurso satisfatório é proposto pela UML, através do uso dos seus diagramas, 
que permitem definir como funcionará cada um dos itens da solução, até, por 
exemplo, em que estrutura de hardware e software será implementada e como 
estarão dispostos componentes da rede envolvida na solução.
É comum, no decorrer do planejamento e desenvolvimento do projeto, o 
surgimento de novas classes. Estas, geralmente, são responsáveis pela interação 
do usuário com o sistema em si (PIVA, 2010). Além disso, são definidos e 
protocolados todos os requisitos necessários para a segurança das informações 
que serão mantidas pelo sistema. Tudo isso é possível de ser realizado mantendo-
se o uso e aplicação da UML, cujas ferramentas permitem o detalhamento de cadaum dos componentes da solução de software.
Na fase da análise do sistema (orientada a objetos) devemos concentrar 
nossos esforços a fim de mapear o funcionamento e comportamento das classes 
para que o sistema funcione da forma como foi projetado em termos de estrutura 
de rede, software e hardware (PIVA, 2010).
4 AS VÁRIAS OPÇÕES DA UML
Segundo Piva (2010), devemos estar atentos ao que é estático e dinâmico 
ao utilizarmos a UML.
Como estático podemos entender: 
• definição das classes;
• modularização;
• as camadas e a configuração do hardware.
 Como processo dinâmico podemos classificar as mudanças de estado que 
os itens podem sofrer no decorrer da execução do software, por exemplo, pelas 
alterações ocasionadas pelas trocas de mensagens entre os itens nesse momento. 
Ainda de acordo com o Piva (2010) podemos perceber cinco diferentes visões 
proporcionadas pela UML durante a construção de modelos de software. São elas:
• Visão de casos de uso: permite melhor compreensão do problema a ser 
resolvido, ajudando na definição das fronteiras do sistema, seus principais 
usuários e as principais funcionalidades a serem implementadas.
• Visão de projeto: auxilia na análise da estrutura e das funcionalidades esperadas 
da solução.
• Visão de processo: também chamada de visão de interação, foca o fluxo de 
controle entre os diversos componentes da solução, permitindo também 
a análise de seu desempenho, a sincronização e a concorrência entre seus 
componentes, necessária para o perfeito funcionamento da solução.
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
12
• Visão de implementação: ajuda a definir a estrutura da solução, isto é, os 
arquivos de instalação, seu controle de versões.
• Visão de implantação: trata da estrutura de hardware e software, ou seja, do 
ambiente em que a solução será implementada.
4.1 CONCEITOS DA ESTRUTURA DA UML
A formação da UML tem seu alicerce em três componentes básicos: 
• blocos de construção;
• regras que restringem como os blocos de construção podem ser associados 
entre si;
• mecanismos de uso geral, que dão mais clareza às definições criadas pelos 
blocos de construção. Estes, por sua vez, são de três tipos: itens, relacionamentos 
e diagramas (PIVA, 2010).
4.1.1 Itens
São as abstrações em si e a base da UML. Os itens mantêm relacionamentos, 
que são mantidos pelos diagramas. Existem diferentes tipos de itens, que podem 
ser classificados em quatro grupos: estruturais, comportamentais, de agrupamento 
e anotacionais, que serão estudados no decorrer deste caderno.
4.1.2 Itens estruturais
São responsáveis por definir a estrutura da solução. 
São formados por:
• classes;
• as interfaces;
• as colaborações;
• os casos de uso;
• os componentes;
• os artefatos;
• os nós. 
Para prosseguirmos, torna-se necessário o entendimento acerca dos 
elementos mencionados acima, conforme esclarecimento proposto por Piva 
(2010, p. 173):
Classes: são os elementos básicos da orientação a objetos e, 
consequentemente, da UML. 
TÓPICO 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML
13
Interfaces: são as funcionalidades a serem implementadas por uma 
classe ou por um componente. Demonstram o comportamento visível 
de uma classe, mas nunca a implementação de tal comportamento, 
pois contêm apenas a assinatura dos métodos, e sua implementação 
é feita pelas classes que herdam seu comportamento. Servem para 
defi nir comportamentos padronizados para conjuntos de classes e 
itens. As interfaces são representadas por um círculo.
Colaboração: são agrupamentos de classes, relacionamentos e 
interfaces que constituem uma unidade do sistema. Dizemos que 
essa unidade é maior que a soma das classes e relacionamentos 
implementados. São representados por uma elipse tracejada com o 
nome da colaboração ao centro. A colaboração serve também para nos 
dar uma visão em nível mais alto de abstração, quando não é necessário 
entrar em todos os detalhes de determinado item em análise.
FIGURA 8 – COLABORAÇÃO
Controle
de Estoque
Solicitar
Preço
FONTE: Piva (2010)
Casos de uso: descrevem uma sequência de ações a serem executadas 
pelos componentes da solução. São ativados por um ator, servem de 
base para defi nirmos comportamentos dos elementos da solução de 
software e são realizados por uma colaboração. São representados por 
uma elipse com o nome da operação que implementa no centro (PIVA, 
2010, p. 174).
FIGURA 9 – REPRESENTAÇÃO DE CASOS DE USO
FONTE: Piva (2010)
Componentes: são estruturas que instituem uma funcionalidade de 
uma solução de software por meio da implementação de uma ou mais 
interfaces defi nidas. Podem ser substituídos dentro de uma solução 
por outro componente que implemente todas as suas interfaces, sem 
prejuízo ao sistema como um todo (PIVA, 2010, p. 174).
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
14
FIGURA 10 – REPRESENTAÇÃO DE COMPONENTES
FormCliente
<<artefato>>
Cliente.class
imprimir
Nota Fiscal
FONTE: Piva (2010)
Artefato: é um elemento físico do sistema, que pode ser um programa 
(fonte ou executável), um script do sistema operacional e tudo o mais que pode ser 
transformado em bits e bytes. É representado por um retângulo com o estereótipo 
<<artefato>> e o seu nome (PIVA, 2010, p. 174).
FIGURA 11 – REPRESENTAÇÃO DE ARTEFATO
FONTE: Piva (2010)
Nó: representa um recurso de computação. Pode ser um servidor, 
um computador cliente, um switch, um hub etc. Qualquer elemento 
computacional que faça parte da arquitetura na qual será implementada 
a solução pode ser defi nido como um nó. Em UML é desenhado como 
um cubo com seu nome dentro (PIVA, 2010, p. 174).
FIGURA 12 – REPRESENTAÇÃO DE NÓ
Servidor
FONTE: Piva (2010)
Atividade: “é um comportamento que especifi ca a sequência de etapas 
realizadas por um processo computacional. É representada em UML por um 
retângulo de vértices arredondados” (PIVA, 2010, p. 174).
FIGURA 13 – REPRESENTAÇÃO DE HERANÇA
FONTE: Piva (2010)
TÓPICO 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML
15
EmEspera
4.1.3 Itens comportamentais
São os itens que defi nem as partes dinâmicas dos modelos UML. São 
também chamados de verbos do modelo. Constituem itens: interações, máquina 
de estados e atividades.
Interações: são os conjuntos de troca de mensagens entre objetos, também 
chamados de comportamento. Em UML as mensagens são representadas por 
uma seta traçada sob seu nome.
Máquina de estados: “especifi ca os diversos estados pelos quais pode 
passar um objeto ou uma interação em seu ciclo de vida. Sua defi nição inclui 
outros componentes, como estados, transições, eventos e atividades. Em UML é 
representada por um retângulo com os vértices arredondados” (PIVA, 2010, p. 174).
FIGURA 14 – REPRESENTAÇÃO DE MÁQUINA DE ESTADOS
FONTE: Piva (2010)
4.1.4 Itens de agrupamento
Servem para agrupar os demais itens da UML em bloco, permitindo uma 
melhor organização do projeto. É composto apenas pelo item pacote (PIVA, 2010).
Pacote: “permite a inclusão de itens em seu interior para organizar o 
projeto, tornando-o modular e mais organizado. É conceitual, não existindo em 
tempo de execução. É representado por uma pasta, que pode receber apenas seu 
nome ou a visualização dos itens que a compõem” (PIVA, 2010, p. 175).
FIGURA 15 – REPRESENTAÇÃO DE PACOTE
Controle
FONTE: Piva (2010)
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL:CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
16
4.1.5 Item anotacional
É o componente que permite a inserção de comentários nos modelos, 
tornando-os mais claros e inteligíveis. É composto apenas pelo item nota.
Nota: tem como objetivo inserir comentários em um modelo para deixá-
lo mais compreensível. É representado por um retângulo com a ponta 
superior direita dobrada para dentro. Em seu interior são inseridos 
os comentários pertinentes ao que se quer explicar melhor dentro do 
modelo. Também pode ser utilizada uma linha tracejada para apontar 
exatamente a que ponto do modelo se destina a explicação da nota 
(PIVA, 2010, p. 175).
FIGURA 16 – REPRESENTAÇÃO DE NOTA
Esta classe faz a conexão
entre o software aplicativo
e o sistema operacional.
FONTE: Piva (2010)
4.2 DIAGRAMAS
A versão 2.0 da UML traz consigo 13 diagramas, divididos em quatro 
grupos:
• diagramas estruturais;
• diagramas comportamentais;
• diagramas de interação;
• diagramas de implementação.
A fi gura a seguir permite uma melhor visualização dos diagramas e os 
grupos aos quais cada um pertence.
TÓPICO 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML
17
FIGURA 17 – DIAGRAMAS DA UML
Diagramas
da UML
Diagramas
Estruturais
Diagramas
Comportamentais
Diagrama
de Objetos
Diagrama de
Estrutura Composta
Diagrama de
implementação
Diagrama de
Componentes
Diagrama de
Implantação Diagrama
de Sequência
Diagrama de
Temporação
Diagrama de
Colaboração
Diagrama de Visão
Geral da Interação
Diagrama
de Interação
Diagrama de
Atividades
Diagrama
de Classes
Diagrama
de Pacotes
Diagrama de
Casos de Uso
Diagrama
de Transições
de Estados
Diagrama
de Objetos
Diagrama de
Diagrama
de Classes
Diagrama
de Pacotes
Comportamentais
Diagrama de
implementaçãoimplementação
FONTE: Piva (2010)
Adiante estudaremos em detalhes cada um dos diagramas apresentados. 
Para facilitar nosso entendimento acerca da elaboração de cada diagrama, 
precisamos estar atentos às cinco regras propostas pela UML para uma adequada 
construção dos mesmos.
São elas: 
• Nome: sempre devemos lembrar que o nome de um item deve deixar clara 
sua formação, suas ações e responsabilidades. Não devemos nos esquecer 
também de que esse nome é único dentro de um modelo.
• Escopo: todo item inserido em um modelo deve mostrar claramente quais 
são seus limites, o que implementa e quando pode ser utilizado.
• Visibilidade: indica que é necessário também que fi que claro quando um 
item estará disponível para ser utilizado e que ações estarão disponíveis por 
seu intermédio.
• Integridade: também é importante levar em conta na criação de um item a 
defi nição clara de como este se relaciona e a consistência de tal relacionamento.
• Execução: deve estar evidente ainda o que o modelo representa e/ou simula. 
O que queremos observar com a criação desse modelo.
FONTE: Disponível em: <http://issuu.com/geeadcps/docs/livro3_alta/81>. Acesso em: 7 out. 2015.
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
18
As regras definem que ao inserir um item em um diagrama, você tem de 
se preocupar com as características apresentadas acima, para que consiga criar 
modelos bem elaborados e consistentes. 
19
Neste tópico você aprendeu que:
• A UML oferece diversos subsídios para a criação de modelos claros que nos 
auxiliam na construção de soluções de software de qualidade. 
• A UML permite também a criação de modelos que simulam o comportamento 
do software em construção em diversos aspectos. Mas nunca se esqueça: sempre 
caberá ao desenvolvedor a responsabilidade de usar as informações de modo 
a obter soluções de qualidade de acordo com as expectativas do usuário e que 
sejam capazes de produzir os melhores resultados possíveis.
• Ao utilizar a UML precisamos de bom senso para oferecer soluções adequadas 
e no prazo esperado pelo usuário, criando modelos apenas para as partes que 
realmente demandam definição mais aprofundada.
RESUMO DO TÓPICO 1
20
1 Cite os objetivos da UML.
2 Defina classe.
3 Defina objeto.
4 O que você entende por pacote?
5 O que é um diagrama?
AUTOATIVIDADE
21
TÓPICO 2
MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, 
DIAGRAMA DE CASOS DE USO
UNIDADE 1
1 INTRODUÇÃO
Desenvolver um software exige do gestor do projeto a habilidade de 
equilibrar pessoas, atividades, tecnologias e metodologias. Projetos de softwares 
são cercados por riscos desde a sua fase embrionária. Com isso, os modelos 
surgem como uma alternativa ágil para tornar a correção mais rápida e com 
custo reduzido. O próprio uso de modelos já possibilita reduzir o custo do 
desenvolvimento das atividades, pois permite prever o comportamento do 
sistema quando o mesmo estiver finalizado e em uso.
Uma forma mais eficiente de pensar em modelagem e desenvolvimento de 
projetos é a proposta orientada a objetos, que organiza os problemas em torno de 
situações reais, ou seja, como elas de fato acontecem na prática, e isso impõe uma 
forma completamente diferente de pensar e organizar a solução, se comparado à 
forma como o pensamento estruturado apresenta a solução (BOOCH, 1994).
A grande vantagem da orientação a objetos é que os projetos são mais 
facilmente compreendidos, e em consequência, mais facilmente construídos, pelos 
profissionais envolvidos no projeto. A “partícula” fundamental desta metodologia 
é o objeto, que traz consigo o seu comportamento, que pode vir acrescido de 
regras, conhecimentos, responsabilidades e um ciclo de vida definido. Depois de 
modelado não sofre modificações, sendo agregado ao que já existe no sistema. A 
figura a seguir mostra as visões de um projeto orientado a objetos.
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
22
FIGURA 18 – VISÕES DE UM PROJETO COM UML
Visão de
Projeto
Funcionalidade
Vocabulário
Visão do
Processo
Desempenho
Escalabilidade
Throughput
Visão da
Implantação
Topologia do Sistema
Distribuição
Instalação
Visão da
Implementação
Codifi cação
Montagem
Visão de
Caso de Uso
Conceitual Físico
Workfl ow de Design (Arquitetura):
Introdução. UML, Visões:
D
es
en
ha
nd
o 
C
om
po
ne
nt
e 
de
 S
of
tw
ar
e 
co
m
 U
M
L
FONTE: Piva (2010)
2 UML
UML signifi ca Linguagem de Modelagem Unifi cada de projetos orientados 
a objetos. É uma linguagem, não podendo ser considerada um método.
A UML é uma linguagem padrão de notação de projetos.
Por notação entende-se especifi car, visualizar e documentar os elementos 
de um sistema OO. A UML é importante: serve como linguagem para expressar decisões 
de projeto que não são óbvias ou que não podem ser deduzidas do código; provê uma 
semântica que permite capturar as decisões estratégicas e táticas;provê uma forma concreta 
o sufi ciente para a compreensão das pessoas e para ser manipulada pelas máquinas.
NOTA
A UML não depende das ferramentas de programação utilizadas no 
desenvolvimento do projeto.
Além de dar suporte a todos os processos de engenharia de software 
necessários ao projeto, a UML pode ser defi nida como a linguagem de 
modelagem padrão no desenvolvimento de sistemas distribuídos, por exemplo, 
pois, basicamente, sua característica principal baseia-se em um conglomerado 
de técnicas de notação gráfi ca para criar a modelagem visual dos sistemas. É 
TÓPICO 2 | MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, 
23
FONTE: Disponível em: <http://issuu.com/geeadcps/docs/livro3_alta/81>.Acesso em: 7 out. 2015.
É uma linguagem de modelagem única e atualmente muito utilizada!
NOTA
A UML não tem a preocupação de demonstrar como o trabalho ou as 
atividades envolvidas no projeto serão executados. O objetivo da linguagem é 
descrever "o que fazer", “como fazer", "quando fazer" e "por que fazer".
A Linguagem Unificada de Modelagem utiliza diagramas que podem ser 
usados de forma combinada a fim de obter todas as visões e aspectos do sistema.
3 DIAGRAMAS DA UML
Diagramas, na verdade, são gráficos que permitem visualizar o sistema de 
formas diferentes. Pela notação dos diagramas da UML é possível descrever de 
forma ágil e objetiva todos os aspectos da modelagem de dados, sendo que cada 
diagrama tem seu significado, sua notação e a forma de ser utilizado (ANDRADE, 
2007). Os diagramas da UML estão classificados em dois grupos distintos: 
estruturais e comportamentais, sendo que o primeiro grupo mostra tudo o que não 
muda no sistema, e o segundo mostra as reações e evoluções do mesmo.
Cada diagrama analisa o sistema, ou parte dele, sob uma determinada ótica 
(GUEDES, 2007).
NOTA
uma ferramenta ágil, pois combina e suporta as melhores técnicas, que vão 
desde a modelagem dos dados até o levantamento e engrenagem de todos os 
componentes do sistema.
A figura a seguir mostra todos os diagramas da UML agrupados de acordo 
com sua classificação. Os diagramas estruturais tratam o aspecto estrutural do 
ponto de vista do sistema e das classes. São para visualizar, especificar, construir e 
documentar os aspectos que não são mutáveis (ANDRADE, 2007). Ainda de acordo 
com o autor, os aspectos estáticos de um sistema de software envolvem a existência e 
a colocação de itens como classes, interfaces, colaborações, componentes.
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
24
FIGURA 19 – MODELOS DE DIAGRAMAS DA UML
FONTE: Piva (2010)
D
ia
gr
am
as
da
 U
M
L
D
ia
gr
am
as
E
st
ru
tu
ra
is
D
ia
gr
am
a
de
 O
bj
et
os
D
ia
gr
am
a 
de
C
om
po
ne
nt
es
D
ia
gr
am
a 
de
Im
pl
an
ta
çã
o
D
ia
gr
am
a 
de
S
eq
uê
nc
ia
D
ia
gr
am
a 
de
Te
m
po
riz
aç
ão
D
ia
gr
am
a 
de
C
ol
ab
or
aç
ão
D
ia
gr
am
a 
de
 V
is
ão
G
er
al
 d
a 
In
te
ra
çã
o
D
ia
gr
am
a 
de
E
st
ru
tu
ra
C
om
po
st
a
D
ia
gr
am
a 
de
Im
pl
em
en
ta
çã
o
D
ia
gr
am
a
de
 C
la
ss
es
D
ia
gr
am
a
de
 P
ac
ot
es
D
ia
gr
am
as
C
om
po
rta
m
en
ta
is
D
ia
gr
am
a
de
 A
tiv
id
ad
es
D
ia
gr
am
as
 d
e
In
te
ra
çã
o
D
ia
gr
am
a 
de
Tr
an
si
çõ
es
de
 E
st
ad
os
D
ia
gr
am
a 
de
C
as
os
 d
e 
U
so
TÓPICO 2 | MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, 
25
Os diagramas da UML estão divididos em Estruturais e Comportamentais.
3.1 DIAGRAMAS ESTRUTURAIS
• De Classe: Este diagrama é fundamental e o mais utilizado na UML e serve 
de apoio aos outros diagramas. O Diagrama de Classe mostra o conjunto de 
classes com seus atributos e métodos e os relacionamentos entre classes.
• De Objeto: O Diagrama de Objeto está relacionado com o diagrama de classes 
e é praticamente um complemento dele. Fornece uma visão dos valores 
armazenados pelos objetos de um Diagrama de Classe em um determinado 
momento da execução do processo do software.
• De Componentes: Está associado à linguagem de programação e tem por 
finalidade indicar os componentes do software e seus relacionamentos.
• De Implantação: Determina as necessidades de hardware e características 
físicas do sistema.
• De Pacotes: Representa os subsistemas englobados de forma a determinar 
partes que o compõem.
• De Estrutura: Descreve a estrutura interna de um classificador.
FONTE: Disponível em: <http://issuu.com/geeadcps/docs/livro3_alta/81>. Acesso em: 7 out. 2015.
3.2 DIAGRAMAS COMPORTAMENTAIS
De Caso de Uso (Use Case): Geral e informal para fases de levantamento 
e análise de Requisitos do Sistema.
De Máquina de Estados: Procura acompanhar as mudanças sofridas 
por um objeto dentro de um processo.
De Atividades: Descreve os passos a serem percorridos para a conclusão 
de uma atividade.
De Interação: Dividem-se em:
 o De Sequência: Descreve a ordem temporal em que as mensagens são 
trocadas entre os objetos.
 o Geral interação: Variação dos diagramas de atividades que fornece visão 
geral dentro do sistema ou processo do negócio.
 o De comunicação: Associado ao diagrama de Sequência, complementando-o 
e concentrando-se em como os objetos estão vinculados.
 o De tempo: Descreve a mudança de estado ou condição de uma instância de 
uma classe ou seu papel durante o tempo.
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
26
FIGURA 20 – DIAGRAMAS COMPORTAMENTAIS
Diagramas
Comportamentais
Diagrama de
Atividades
Diagrama de
Transições
de Estados
Diagrama de
Interação
Diagrama de
Casos de Uso
Diagrama de
Sequência
Diagrama de
Temporização
Diagrama de Visão
Geral da Interação
Diagrama de
Colaboração
FONTE: Piva (2010)
Os diagramas comportamentais podem ser divididos em:
• Diagramas de Casos de Uso
• Diagrama de Atividades
• Diagrama de Máquina de Estados
• Diagramas de Interação:
o Diagrama de Sequência
o Diagrama de Comunicação
o Diagrama de Tempo
o Diagrama de Interação Geral
4 DIAGRAMAS COMPORTAMENTAIS 
Os diagramas de comportamento têm o mesmo objetivo da modelagem 
dinâmica do sistema. São usados para visualizar, especificar, construir e 
documentar os aspectos do sistema que sofrem mudanças ao longo do 
tempo, como, por exemplo, o fluxo de mensagens e a movimentação física de 
componentes em uma rede. 
FONTE: Disponível em: <http://issuu.com/geeadcps/docs/livro3_alta/81>. Acesso em: 7 out. 2015.
Cada diagrama citado acima será estudado posteriormente!
ESTUDOS FU
TUROS
TÓPICO 2 | MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, 
27
4.1 DIAGRAMA DE CASOS DE USO
O objetivo principal deste diagrama é propor uma visão de como os usuários 
interagem com o sistema.
NOTA
Estes diagramas especificam o que o sistema faz, mas não detalham como 
o trabalho deve ser feito.
FIGURA 21 – EXEMPLO DE DIAGRAMA DE CASO DE USO
Vender CDs
Administrar estoque
Atendente
Gerente
FONTE: Tacla (2010)
Diagrama de casos de uso é uma ferramenta de comunicação entre clientes, 
usuários e desenvolvedores para discutirem e definirem as funcionalidades que 
devem ser realizadas pelo sistema.
4.2 ELEMENTOS DO DIAGRAMA DE CASOS DE USO
• Atores 
• Casos de uso 
• Relacionamentos 
• Associação 
• Generalização
• Dependência: Extensão e Inclusão
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
28
De acordo com Tacla (2010), para encontrar os atores de um sistema deve-
se sempre examinar a situação, procurando por pessoas ou sistemas no entorno 
da situação. Para esse processo ser mais eficiente deve-se questionar: 
• Quais pessoas ou outras entidades interessam a um requisito funcional?
• Quem irá alimentar as informações do sistema e também quem será o receptor 
destas informações?
• Quais recursos externos são utilizados pelo sistema?
• Existem pessoas que desempenhampapéis diferentes no sistema?
• O sistema interage com outros sistemas que já existem e são usados pela 
organização?
4.4 ELEMENTO CASOS DE USO
“A coleção de casos de uso representa todos os modos de execução do sistema 
do ponto de vista do usuário. Um caso de uso é uma sequência de ações que produz 
um resultado significativo (com valor) para um ator” (TACLA, 2010, p. 17).
• Quais são as tarefas de cada ator?
• Que informações o ator obtém do sistema?
• Quem as fornece?
• Quem as captura?
• Algum ator precisa ser informado sobre eventos produzidos pelo sistema?
o Sim => casos de uso de registro e notificação
• Há eventos externos que devem ser notificados ao sistema?
o Sim => deve haver casos para que os atores possam notificar o sistema
4.3 ELEMENTO ATORES
Representam papéis desempenhados por usuários ou qualquer outra 
entidade externa ao sistema, por exemplo, hardware e outros sistemas. Podem 
iniciar casos de uso; podem prover e/ou receber informações dos casos de uso.
Gerente Contas Receber Scanner
FIGURA 22 – REPRESENTAÇÃO DE ATORES
FONTE: Tacla (2010)
TÓPICO 2 | MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, 
29
4.4.1 Descrição
5 FLUXO DE EVENTOS
Um fluxo de evento serve para descrever como o sistema e os atores 
cooperam entre si para entregar algo de valor aos atores e também descrevem 
o que pode impedir que isso aconteça. Na verdade, um fluxo de eventos faz a 
descrição de um caminho entre muitos, uma vez que um caso de uso pode ser 
representado e executado de formas distintas (TACLA, 2010).
Ainda segundo o mesmo autor, existem fluxos distintos: fluxos primários 
ou básicos e fluxo alternativo. Por esta visão, o fluxo básico se torna a explicação, 
enquanto que o fluxo alternativo é a alternativa. Tomemos como exemplo a situação 
proposta pelo autor citado onde uma pessoa explica um caminho para outra.
Há fluxos primários ou básicos (fluxo normal de eventos) e alternativos (o 
que fazer se…). Para descrevê-los, é possível se inspirar na situação em que uma 
pessoa explica um caminho a outra.
“Para ir ao churrasco, pegue a BR-116 na direção de São Paulo. Logo após o 
Clube Santa Mônica, tem um retorno por baixo da pista. Faça o retorno e continue reto 
(não retorne à BR). Continue nesta estradinha asfaltada por 1 km, no entroncamento 
pegue a estrada de terra à direita, ande cerca de 500m, você verá um grande eucalipto 
A UML não apresenta uma descrição padrão para casos de uso, sendo 
composta por diagramas informais. Vale lembrar que os diagramas de caso de 
uso facilitam a visualização, mas não são descritos detalhadamente, sendo que 
o uso deste diagrama apenas não é considerado suficiente para a compreensão e 
modelagem total da situação (TACLA, 2010, p. 17). 
De acordo com o autor, os casos de uso são facilmente descritos quando 
utilizados os seguintes elementos:
• Nome
• Descrição
• Requisitos (requirements): são os requisitos funcionais providos pelo caso de uso
• Restrições (constraints), tais como pré e pós-condições e condições invariantes:
o Precondições: “define o que deve ser verdadeiro para que o caso de uso seja 
iniciado. Por exemplo, num sistema bancário, para o caso de uso Abrir conta 
corrente, uma precondição é apresentar CPF sem restrições (aprovação do 
pedido)” (TACLA, 2010, p. 17).
o Pós-condições: “o que se torna verdadeiro pela execução do caso de uso. No 
mesmo caso de uso acima, o sistema pode se encontrar em um dos seguintes 
estados: conta aberta e com um depósito inicial ou conta não aberta por 
reprovação do CPF” (TACLA, 2010, p. 17).
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
30
e uma araucária. A entrada da chácara é entre os dois. Não se esqueça de trazer o 
pinhão” (TACLA, 2010, p. 18) // EXEMPLO DE FLUXO PRIMÁRIO
“Se estiver chovendo muito, os 500m na terra podem ser bem difíceis, 
porque o barro é mole. Neste caso, siga reto no entroncamento (ao invés de virar 
à direita) e na próxima à direita pegue a rua de paralelepípedos. Ande cerca de 1 
km e depois vire na segunda à direita que vai desembocar na frente da chácara” 
(TACLA, 2010, p. 18) // EXEMPLO DE FLUXO ALTERNATIVO 1
“Se você for comprar o pinhão no caminho, logo depois de fazer o retorno 
da BR tem uma venda. Se estiver fechada, um pouco mais à frente tem um 
senhor da Chácara Pinhais que também vende. Se não encontrar pinhão, não tem 
problema” (TACLA, 2010, p. 18) // EXEMPLO DE FLUXO ALTERNATIVO 2
Tacla (2010) sugere que nas fases iniciais de análise dos dados é importante 
manter o foco nos fluxos básicos, pois 80% do tempo de execução de um sistema são 
ocupados por casos primários. Mas não devemos nos esquecer de documentar os 
fluxos alternativos, uma vez que ambos documentam como as responsabilidades 
especificadas nos casos de uso são divididas entre sistema e atores. 
“No desenrolar do projeto, as responsabilidades atribuídas ao sistema devem ser 
distribuídas entre os objetos que compõem o sistema” (TACLA, 2010, p. 19).
IMPORTANT
E
5.1 FLUXO BÁSICO
Um fluxo básico demonstra o que acontece quando se executa o caso de 
uso. Para que isso seja possível, o mesmo deve conter o ator e o evento disparado 
para dar início ao caso; a iteração entre o ator e o sistema e a descrição de como o 
caso é finalizado. 
5.2 SUBFLUXO
Para melhor entendimento de um fluxo, este pode ser fragmentado em vários 
subfluxos.
NOTA
TÓPICO 2 | MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, 
31
“Um fluxo de eventos pode ser decomposto em subfluxos para melhorar 
a legibilidade. Importante evitar muitas decomposições para não dificultar o 
entendimento. Os subfluxos devem ser executados na totalidade, não podem ser 
executados pela metade” (TACLA, 2010, p. 19). 
5.2.1 Pontos de extensão
São pontos específicos do fluxo que permitem inserir comportamentos 
adicionais. Podem ser privados ou públicos (TACLA, 2010, p. 20).
Privados: caso sejam visíveis somente dentro do caso de uso onde foram criados.
Públicos: quando estendem o caso onde foram definidos.
NOTA
No exemplo Buscar produtos e fazer pedido, os pontos de extensão 
seguintes são encontrados (TACLA, 2010, p. 20):
_ {Mostrar catálogo de produtos}
_ {Escolher produto}
_ {Produto esgotado}
_ {Processar pedido}
_ {Informações de pagamento não válidas}
_ {Informações de envio não válidas}
Um ponto de extensão pode definir: 
• uma localização única dentro do fluxo, por exemplo, {Mostrar 
catálogo de produtos}, {Escolher produtos} e {Processar pedido};
• um conjunto de localizações que representam um certo estado do 
caso de uso, por exemplo, {Produto esgotado} que poderia aparecer 
em vários pontos do fluxo de eventos;
• uma região entre dois pontos de extensão, por exemplo, {Escolher 
produtos} e {Processar pedido} (TACLA, 2010, p. 20).
5.3 FLUXO ALTERNATIVO
“Um fluxo alternativo apresenta um comportamento opcional, de outra 
forma, que não é parte do comportamento normal de um caso de uso” (TACLA, 
2010, p. 21). Fluxos alternativos são fluxos que podem ser executados numa 
funcionalidade a partir de escolha do usuário, e não de erros do sistema. São três 
tipos de fluxos alternativos:
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
32
6 ELEMENTO RELAÇÕES
São várias as relações em Casos de Uso, mas as mesmas não representam 
a ordem de execução dos casos. E as mesmas devem melhorar a compreensão 
daquilo que o sistema deve executar.
6.1 ASSOCIAÇÃO
Associação é a mais comum das relações. Pode ser percebida entre dois 
atores ou entre um ator e um caso de uso. São representadas por uma linha cheia, 
comou sem direção.
6.2 ATOR X ATOR
Relações associativas podem conectar atores para representar 
comunicação entre atores. A relação pode receber um nome que 
identifica o conteúdo da mensagem, documento ou objeto que trafega 
entre os atores. A figura mostra uma associação entre o ator usuário de 
biblioteca que passa o livro ao atendente que realiza o empréstimo ou 
a devolução. Como não há flechas, assume-se que o atendente devolve 
algo ao usuário da biblioteca, provavelmente um comprovante não 
representado no diagrama. Não é recomendável colocar este tipo de 
relação no diagrama de casos de uso (TACLA, 2010, p. 22).
FIGURA 23 – REPRESENTAÇÃO DE RELAÇÕES EM CASOS DE USO
Usuário Biblioteca Atendente
livro
Realizar Empréstimo
Realizar Devolução
FONTE: Tacla (2010)
6.3 ATOR X CASO
Associações entre atores e casos de uso servem para indicar se quem 
dá início à comunicação é o ator ou o caso de uso, além de traçar o fluxo da 
informação, indicando quem alimenta quem com a informação.
• Específico: iniciam num ponto de extensão.
• Regional: podem ocorrer entre dois pontos de extensão.
• Geral: podem ocorrer em qualquer ponto do caso de uso.
TÓPICO 2 | MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, 
33
6.4 ELEMENTO DEPENDÊNCIA - INCLUSÃO E EXTENSÃO
Quando um caso de uso inclui outro caso de uso (considerado um 
subcaso) na sua execução, este está usando a relação de inclusão entre casos 
de uso. Um subcaso pode ser considerado como um subfluxo de um fluxo de 
eventos primário, que foi separado e deve ser executado por completo. A Figura 
24 mostra: 
Um caso onde se efetua uma matrícula que possui subfluxos escolher 
disciplinas, alocar alunos às turmas e emitir boleto. Este último é 
compartilhado com o caso Efetuar inscrição curso opcional e, portanto, 
deve ser representado no diagrama. Um erro comum que adiciona 
complexidade ao diagrama é incluir os subfluxos escolher disciplinas 
e alocar alunos às turmas no diagrama (TACLA, 2010, p. 22).
FIGURA 24 – RELAÇÃO DE INCLUSÃO
Aluno
Efetuar inscrição Curso Opcional
Alocar Alunos as Turmas
Escolher Disciplinas
Efetuar Matrícula
Emitir Boleto
<<Include>>
<<Include>>
<<Include>>
<<Include>>
FONTE: Tacla (2010)
A inclusão deve ser utilizada para administrar comportamentos comuns e não 
para estruturar funcionalmente o diagrama.
NOTA
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
34
7 EXTENSÃO
É uma indicação de que outros casos de uso poderão ser adicionados a um 
caso de uso específi co. Para Tacla (2010, p. 25): 
• Um caso de uso de extensão não requer modifi cações no caso base 
(aquele que é estendido). O comportamento básico do caso base 
permanece intacto. Um caso de uso que estende um caso base conhece 
este último (não é muito comum um caso de uso estender mais de um 
caso base).
• Uma extensão nasce como um fl uxo alternativo, mas nem todo fl uxo 
alternativo vira uma extensão.
• vCasos de uso que estendem assumem o controle no ponto de 
extensão e quando terminam devolvem o controle no mesmo ponto.
Pelo exemplo proposto na Figura 25, “a emissão de histórico escolar 
é estendida pelo caso imprimir comprovante de término quando o 
aluno solicitante for formado. Observa-se que é um comportamento 
opcional que pode não ser oferecido sem prejuízo ao comportamento 
básico emitir histórico escolar” (TACLA, 2010, p. 26).
FIGURA 25 – EXEMPLO DE EXTENSÃO
Aluno
Imprimir Comprovante Termino
aluno formado e um
ponto de extensão
Emitir Historico Escolar
aluno formado
values
<<extend>>
FONTE: Tacla (2010)
Nota-se no ponto de extensão público denominado {aluno formado} 
onde o comportamento opcional imprimir comprovante término é 
inserido. É provável que existam outros pontos de extensão privados 
defi nidos nos fl uxos de emitir histórico escolar, porém, no diagrama 
só os usados pelas extensões são listados (TACLA, 2010, p. 26).
8 ELEMENTO GENERALIZAÇÃO/ESPECIALIZAÇÃO
A relação de generalização/especialização pode ocorrer entre casos de uso 
ou entre atores.
Caso x Caso
TÓPICO 2 | MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, 
35
Generalização permite especificar comportamentos genéricos que 
podem ser especializados para atender necessidades específicas. Normalmente 
é utilizado quando se quer descrever famílias de sistemas. Por exemplo, uma 
empresa que desenvolve software para terminais bancários de autoatendimento 
quer expandir seus negócios para outras áreas, tais como pagamento direto 
em bombas de gasolina.
NOME: Realizar transação (caso abstrato).
DESCRIÇÃO: Permite ao usuário comprar mercadorias de um terminal 
automático, sendo o valor das mercadorias descontado de uma conta bancária.
PRECONDIÇÕES: (e) O cliente possui um cartão bancário; a conexão com o 
banco está ativa; o terminal deve ter mercadoria.
PÓS-CONDIÇÕES: (ou) O terminal retornou o cartão bancário ao cliente, 
entregou a mercadoria ao cliente e debitou o valor de sua conta. O terminal 
retornou o cartão bancário ao cliente, não entregou nenhuma mercadoria e 
nenhum valor foi debitado da sua conta.
FONTE: Disponível em: <https://www.passeidireto.com/arquivo/6299813/analise-e-projeto-oo-e-
uml/8>. Acesso em: nov. 2015.
Ator x Ator
Especialização de atores representa que um conjunto deles possui 
responsabilidades ou características em comum. Algumas dicas para evitar 
modelagens desnecessárias:
• Não utilizar atores para representar permissões de acesso.
• Não utilizar atores para representar organogramas (hierarquias) de cargos 
de uma empresa.
• Utilizar atores somente para definir papéis em relação ao sistema.
Por exemplo, se num sistema de matrículas de uma universidade há 
casos de usos especiais para alunos de ciências exatas e para alunos de humanas, 
então é sinal de que estes alunos são especializações de um ator genérico aluno. 
A Figura 26 ilustra a notação UML para este caso. Observar que alunos de 
ciências exatas e de humanas herdam todas as associações do ator aluno.
FONTE: Disponível em: <https://www.passeidireto.com/arquivo/6299813/analise-e-projeto-oo-e-
uml/8>. Acesso em: nov. 2015.
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
36
FIGURA 26 – REPRESENTAÇÃO DE HERANÇA
Aluno
Aluno C. Extas Aluno Humanas
FONTE: Tacla (2010)
9 DICAS IMPORTANTES
Casos de uso auxiliares
“Casos de uso auxiliares são frequentemente esquecidos, pois não são 
essenciais à funcionalidade do sistema. Porém, esquecê-los completamente pode 
conduzir a um sistema difícil de ser utilizado” (TACLA, 2010, p. 27).
“Lembrar de colocar casos de uso para executar, manter e configurar o 
sistema, tais como: lançar e parar o sistema, incluir novos usuários, fazer backup das 
informações, incluir novos relatórios e realizar configurações” (TACLA, 2010, p. 27).
Decomposição funcional
Tacla (2010, p. 28) explica a decomposição funcional desta forma:
• Não é necessário detalhar em excesso os casos de uso. Muitos 
detalhes levam à decomposição dos casos em funções. O objetivo é 
compreender o sistema através de cenários de utilização.
• Casos de uso não são feitos para analisar (no sentido de decompor) 
os requisitos em requisitos menores. É um processo de síntese ou 
elaboração (e não de análise) no qual o problema não é totalmente 
conhecido. Quebrá-lo em partes menores (análise) dificulta a obtenção 
de uma visão geral.
• Em equipes com forte competência em análise estruturada, há 
tendência em encontrar funções ao invés de casos de uso. Por exemplo, 
fazer pedido, revisar pedido, cancelar pedido e atender pedido 
podem parecerbons casos de uso. No fundo, todas estas funções estão 
relacionadas ao caso de uso realizar pedido.
• Decomposição funcional pode levar a um número intratável de casos, 
mesmo para pequenos sistemas, e à perda de foco no que realmente é 
importante no sistema (o que traz valor aos atores). 
• Casos de uso não chamam outros casos de uso ou se comunicam 
com outros casos.
TÓPICO 2 | MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, 
37
Estrutura e detalhamento
Ainda de acordo com Tacla (2010, p. 30):
• Não estruturar demais o diagrama de casos de uso, isto é, não 
inclua relações entre casos de uso a não ser que sejam extremamente 
necessárias. O uso em excesso destas relações pode fragmentar o 
diagrama, diminuindo a compreensão global.
• O modelo deve ser o mais simples e direto possível.
• Não descrever o que ocorre fora do sistema. Por exemplo, interação 
entre atores pode ser importante para o negócio, mas se o sistema não 
facilita esta interação, deixe-a fora. Se for necessário esclarecer estes 
pontos, faça um modelo do negócio e não um modelo de casos de uso.
• Não fazer casos tais como incluir, consultar, alterar e excluir (ICAE). 
Casos de uso que descrevem comportamentos ICAE não adicionam 
muito valor à descrição da funcionalidade do sistema. Para estes tipos 
de comportamentos, os requisitos são bastante claros e não se deve 
perder tempo especificando-os. 
Modelo de casos de uso é mais que um diagrama
O diagrama de casos de uso é uma visão panorâmica dos casos de uso e, 
portanto, apenas um dos componentes do modelo de casos de uso. A descrição 
textual dos mesmos é a parte mais importante do modelo. São elementos 
do modelo de casos de uso: glossário, modelo do domínio e diagramas de 
atividades. 
 
Um glossário e um modelo do domínio podem evitar o excesso de 
detalhes nas descrições dos casos de uso. Por exemplo, ao invés de descrever 
a validação da entrada de dados, os campos podem ser definidos no glossário 
com os respectivos valores possíveis.
Um modelo do domínio ajuda a entender as relações existentes entre as 
entidades do domínio e as restrições sobre as relações.
FONTE: Disponível em: <http://issuu.com/geeadcps/docs/livro3_alta/81>. Acesso em: 10 out. 2015.
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
38
Passos 
 Para elaborar um modelo de casos de uso, os seguintes passos podem ser 
seguidos (TACLA, 2010, p. 35):
• Recapitular a visão do sistema (estudo de viabilidade) aos envolvidos.
• Elaborar, se necessário, um diagrama de contexto para definir os 
limites do sistema (o que está dentro e o que está fora).
• Identificar os atores do sistema.
• Identificar os casos de uso: descrevê-los e rascunhar o fluxo de 
eventos. Não se preocupe com fluxos alternativos. Não gaste mais do 
que 10 minutos para descrever cada caso de uso.
• Esboçar o diagrama de casos de uso mostrando associações entre 
atores e casos de uso.
• Verificar os casos de uso.
• Há casos de uso sem conexão com requisitos funcionais? Caso haja, 
pode haver casos em excesso ou requisitos que não foram identificados!
• Há requisitos funcionais sem casos? Alguns casos podem ter sido 
esquecidos.
• Todos os requisitos não funcionais foram tratados (associados aos 
casos de uso quando são específicos)?
• Todos os tipos de usuários foram mapeados para um ator ao menos?
• Descrever os casos detalhadamente.
• Representar os subfluxos (<<include>>) e fluxos alternativos 
(<<extend>>) considerados importantes no diagrama.
• É possível eliminar os casos incluídos ou as extensões e ainda ser 
capaz de entender o que o sistema faz para as partes interessadas?
39
RESUMO DO TÓPICO 2
Neste tópico você viu que:
• Todos os diagramas da UML são úteis para análise de aspectos importantes do 
desenvolvimento de software, mas não é necessário aplicar todos os diagramas 
em um mesmo projeto. Escolha apenas aqueles que o ajudarão a entender 
melhor o sistema que está desenvolvendo e a deixar mais claras as soluções 
que irá implementar. 
• Não deve deixar que os diagramas fiquem grandes e complexos demais.
• Se perceber que isso está acontecendo, tente separá-los em mais de um, 
dividindo suas funcionalidades.
• Normalmente, todos os diagramas são desenvolvidos com auxílio de um 
software.
• Diagrama de casos de uso é um diagrama que mostra um conjunto de casos 
de uso, atores e seus relacionamentos. Abrange a visão estática de caso de uso 
de um sistema, ele é criado após o levantamento dos requisitos da solução 
imaginada, cada caso de uso é um de seus requisitos funcionais.
• Este diagrama permite visualizar os limites do sistema, sua relação com os 
demais sistemas, com seus componentes internos e as funções que deve realizar.
40
1 Explique a utilidade do diagrama de casos de uso para os testes do sistema.
2 Explique a utilidade do diagrama de casos de uso para criação dos manuais 
do usuário. 
3 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 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”.
FONTE: Disponível em: <http://ebrito.com.br/profa-elaine/ExGabarito.pdf>. Acesso em: 20 
out. 2015.
4 Qual é a notação da UML para um caso de uso? Qual é a notação da UML 
para um ator? Qual a notação utilizada na UML para o relacionamento de 
generalização entre casos de uso?
FONTE: Disponível em: <http://ebrito.com.br/profa-elaine/ExGabarito.pdf>. Acesso em: 20 
out. 2015.
5 Defina o que significa um ator. O que significa um ator estar associado a um 
caso de uso por um relacionamento de comunicação?
FONTE: Disponível em: <http://ebrito.com.br/profa-elaine/ExGabarito.pdf>. Acesso em: 20 
out. 2015.
6 Qual o objetivo dos casos de uso?
7 Considere a seguinte declaração obtida de um gerente de uma empresa 
que comercializa livros por correio durante o levantamento de requisitos 
para construção de um sistema de software: “Após a ordem de compra do 
cliente ter sido registrada, o vendedor envia uma requisição ao depósito 
com detalhes da ordem de compra”. Quais atores em potencial podem ser 
identificados a partir desse texto?
FONTE: Disponível em: <http://ebrito.com.br/profa-elaine/ExGabarito.pdf>. Acesso em: 20 
out. 2015.
AUTOATIVIDADE
41
8 Em uma empresa, vários projetos são realizados. Os 50 empregados da 
empresa trabalham em pelos menos um projeto. Há um sistema implantado 
na empresa que permite aos participantes de um determinado projeto 
marcarem suas horas de trabalho. Esse sistema também permite que outra 
pessoa, ao fim do mês, gere os relatórios com os totais de horas trabalhadas 
de cada participante. Quantos atores você definiria para esse sistema?
FONTE: Disponível em: <http://ebrito.com.br/profa-elaine/ExGabarito.pdf>. Acesso em: 20 
out. 2015.
9 Suponha que um sistema de vendas deve gerar de forma automática um 
conjunto de estatísticas para a diretoria da empresa no último dia útil de 
cada mês. Desenhe o diagrama de casos de uso para essa situação.
FONTE: Disponível em: <http://ebrito.com.br/profa-elaine/ExGabarito.pdf>. Acesso em: 20 
out. 2015.
42
43
TÓPICO 3
DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE 
ESTADOS
UNIDADE 1
1 INTRODUÇÃO
O diagrama de atividades é um gráfico de fluxo e mostra basicamente o 
fluxo de controle de uma atividade para outra, sendo utilizado para modelar o 
comportamento dos processos. É um dos diagramas que mais sofreu alterações 
desde o surgimento da UML, e abrange a visão dinâmica da UML (modelasituações que sofrem mudanças no sistema). Neste diagrama, uma atividade é 
modelada através de uma sequência estruturada de ações sendo controladas, na 
maioria das vezes, por nós de decisão. 
Veja na Figura 27 o exemplo do diagrama de atividades gerado pelo caso 
de uso Registrar compra produtos, proposto por Piva (2010).
44
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
FIGURA 27 – DIAGRAMA DE ATIVIDADES
Funcionário Sistema
Verifi car
Login,
Senha
Logar no
sistema
Solicitar
cartão do
Cliente
Verifi car
Existência
do Produto
Verifi car
Cartão do
Cliente
Verifi car
Saldo do
Produto
Funcionário
Cartão
Produto
ItemCompra
Passar
código da
Barra do
cartão do
cliente
Passar
código da
Barra do
Produto
Digitar a
quantidade
comprada
do Produto
Terminar
registro do
Produto
Atualizar
total da
empresa Criar
Compra
Compra
login inválido
login válido
cartão inválido
cartão válido
não existe
existe
não possui saldo sufi ciente
possui saldo sufi ciente
não existe
existe
Diagrama de atividades
do caso de uso Registrar
compra produtos.
FONTE: Piva (2010)
O diagrama de atividades apresenta de forma simples e clara as ações que 
são executadas em cada caso de uso. Este tipo de diagrama deve ser dividido com 
linhas verticais para identifi car o executor da ação. 
TÓPICO 3 | DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
45
2 AÇÃO
Uma ação é uma ação que não pode ser decomposta dentro de uma 
atividade. Já uma atividade é representada por ações ou subatividades. Uma 
ação não inicia sua execução até que todas as suas condições de entrada sejam 
satisfeitas. Somente quando uma ação é terminada é que a ação subsequente 
fica habilitada. 
FONTE: Disponível em: <http://issuu.com/geeadcps/docs/livro3_alta/81>. Acesso em: 10 out. 2015.
Ações também podem ser entendidas como precondições, que irão definir 
condições necessárias para que uma ação possa ser executada, e também pós-condições 
que vão definir o estado depois que a ação for executada.
NOTA
3 ATIVIDADES
Atividades podem ser representadas por sequências de ações e 
também de subatividades. Dessa forma, para representar uma 
subatividade dentro de uma atividade (ou seja, todo um conjunto de 
ações ou subatividades), utiliza-se uma representação semelhante à de 
uma ação, com um pequeno ícone no canto direito inferior. Disponível 
em: <www.dca.fee.unicamp.br/~gudwin/ftp/ea976/AtEst.pdf>. Acesso 
em: nov. 2015.
4 EVENTOS
São situações onde ocorrem mudanças de estado de forma muito rápidas 
e estabelecem o início de outra ação.
5 NÓS DE CONTROLE
Nós de controle existem para controlar o fluxo dos processos e os dados 
entre as ações.
6 PONTOS DE EXTENSÃO
Evitam que o diagrama fique muito poluído, pois permitem a partição das 
ações.
46
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
FIGURA 28 – EXTENSÕES
Sistema na
tela principal
Seleciona Opção
"Pagamento de
Contas "
Seleciona
opção
Solicita
cancelamento
Insere
Dados
Clica OK
Seleciona
opção
Solicita
cancelamento
Insere
password
Fecha tela de
pagamento
de contas
Fecha tela
de password
Efetua
pagamento
da conta
Verifi ca
password
Limpa tela
de password
Abre Janela
de password
Abre Janela
"Pagamento
de Contas"
[opção = cancela]
Usuário Sistema
[opção - continua]
[result - correto]
[result - incorreto]
[opção = continua]
[opção - cancela]
FONTE: Piva (2010)
Diagramas de atividade como os da fi gura são utilizados para detalhar 
os casos de uso levantados durante a especifi cação do sistema. Nesses 
diagramas, assume-se que o usuário do sistema realiza certas ações 
e o sistema, em resposta, reage realizando certas tarefas. Com isso, o 
comportamento do sistema pode ser especifi cado (PIVA, 2010, p. 191).
TÓPICO 3 | DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
47
7 OUTROS RECURSOS EM DIAGRAMAS DE ATIVIDADES
Os diagramas de atividades possuem ainda, de acordo com a versão 2.3 
da norma UML, outros recursos não apresentados aqui neste texto, que podem 
elevar sobremaneira a complexidade do diagrama. Dentre eles, o recurso de 
regiões de expansão, os pinos de entrada e saída, os nós estruturados, os 
conjuntos de parâmetros e outros podem ser consultados diretamente no texto 
da norma.
Um diagrama de atividades mostra um processo de negócios 
ou um software como um fluxo de trabalho por meio de uma série de 
ações. Computadores, componentes de software ou as pessoas podem executar 
essas ações.
Você pode usar um diagrama de atividades para descrever processos 
de diversos tipos, como os exemplos a seguir:
Um processo de negócios ou um fluxo de trabalho entre usuários e 
seu sistema. Para obter mais informações, consulte Requisitos de usuário do 
modelo.
As etapas executadas em um caso de uso. Para obter mais informações, 
consulte Diagramas de caso de uso UML: diretrizes.
Um protocolo de software, ou seja, as sequências permitidas de 
interações entre os componentes.
Um algoritmo de software.
FONTE: Disponível em: <https://msdn.microsoft.com/pt-br/library/dd409360.aspx>. Acesso em: 
30 set. 2015.
8 RELAÇÃO COM OUTROS DIAGRAMAS
Se você desenhar um diagrama de atividades para descrever um 
processo comercial ou uma forma em que os usuários poderão usar seu 
sistema, você pode desenhar um diagrama de caso de uso para mostrar uma 
exibição diferente das mesmas informações. No diagrama de caso de uso você 
pode desenhar as ações dos casos de uso. Dê aos casos de uso os mesmos 
nomes que as ações correspondentes. As vantagens da exibição de caso de uso 
é que você pode:
• Mostrar em um diagrama como maiores ações/casos de uso são compostos 
de pequenos, usando a relação inclui.
• Conecte cada caso de uso/ação explicitamente para os usuários ou sistemas 
externos envolvidos em sua execução.
• Desenhe limites em torno de ações/casos de uso com suporte pelo seu 
sistema ou cada componente principal.
48
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
Você também pode desenhar um diagrama de atividades para 
descrever o design detalhado de uma operação de software.
Em um diagrama de atividades você pode mostrar o fluxo de dados 
passados entre ações. Consulte descrevendo o fluxo de dados. Mas um diagrama 
de atividades não descreve a estrutura dos dados. Para essa finalidade, você 
pode desenhar um diagrama de classe UML. 
Para modelar processos/atividades, a UML (Unified Modeling Language) 
sugere a utilização do Diagrama de Atividades, que descreve os passos a serem 
percorridos para a conclusão de uma determinada situação.
FONTE: Disponível em: <http://www.purainfo.com.br/artigos/uml-diagrama-de-atividades/>. Acesso 
em: 30 set. 2015.
Para fluxos simples: Você pode demonstrar uma sequência de atividades 
com tomada de decisão, como, por exemplo:
FIGURA 29 – FLUXOS SIMPLES
Receber nº da conta
Emitir mensagem
de conta válida
Emitir mensagem
de conta válida
Conta existe?
Pesquisar conta
Início
1
2
3 4
5
Fim
(Não)
(Sim)
FONTE: Piva (2010)
9 EXEMPLO DE CRIAÇÃO DE DIAGRAMA DE ATIVIDADES
Exemplo 1: Considere o fluxo de trabalho associado à construção de 
uma casa. Primeiro, você seleciona um local. A seguir, contrata um arquiteto 
para projetar sua casa. Uma vez definida a planta, seu desenvolvedor 
TÓPICO3 | DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
49
determina os custos da casa. Após concordar com um preço e com uma forma 
de pagamento, a construção pode começar. As licenças são tiradas, o terreno 
é cavado, a fundação é cimentada, as estruturas são erguidas e assim por 
diante, até tudo fi car pronto. Você então recebe as chaves e um certifi cado de 
“habite-se” e toma posse da casa. Embora seja uma grande simplifi cação do 
que realmente acontece em um processo de construção, essa descrição capta o 
percurso crítico do fl uxo de trabalho correspondente.
FONTE: Disponível em: <http://www.purainfo.com.br/artigos/uml-diagrama-de-atividades/>. Acesso 
em: 30 set. 2015.
FIGURA 30 – DIAGRAMA DE ATIVIDADES
Construir construção Certifi cadoDeHabitse
[Concluído]
[rejeitado]
[else] Bifurcação concorrente
Fluxo de objetos
Selecionar local
Estado inicial
Contratar arquiteto
Desenvolver plano
Orçar plano
Estado de Ação
Fazer trabalho no local Fazer trabalho com
outros setores
Estado fi nal
Estado da atividade
com submáquina
União concorrente
FONTE: Disponível em: <http://www.purainfo.com.br/artigos/uml-diagrama-de-atividades/>. 
Acesso em: 5 set. 2015.
50
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
Características: 
• Um diagrama de atividades é essencialmente um fluxograma que dá ênfase 
à atividade que ocorre ao longo do tempo. 
• Você pode considerar um diagrama de atividades como um diagrama de 
sequência cujo interior é revelado.
• Um diagrama de sequência observa os objetos que passam mensagens.
• Um diagrama de atividades observa as operações passadas entre os objetos.
• Mostra o fluxo de uma atividade para outra.
• Uma atividade é uma execução em andamento.
• As atividades resultam em uma ação.
• As ações abrangem a chamada a outras operações, enviando um sinal, 
criando ou destruindo um objeto.
Exemplo 2: O diagrama a seguir mostra um diagrama de atividades 
para uma empresa de varejo, que especifica o fluxo de trabalho envolvido 
quando um cliente devolve um item de um pedido postal. O trabalho 
começa com a ação solicitar devolução do cliente e depois flui por televendas 
(receber número de devolução), retorna ao cliente (enviar item) e, a seguir, ao 
depósito (receber item e depois Incluir item novamente no estoque) e, por fim, 
terminando em contabilidade (creditar conta). Conforme o diagrama indica, 
um objeto significativo (i, uma instância de Item) também acompanha o fluxo 
do processo, mudando do estado devolvido para o estado disponível.
FONTE: Disponível em: <www.purainfo.com.br/artigos/uml-diagrama-de-atividades>. Acesso em: 
29 set. 2015.
TÓPICO 3 | DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
51
FIGURA 31 – EXEMPLO 2 – DIAGRAMA DE ATIVIDADES
Informa novo
código do Cliente
Verifica se o
cliente já existe
Exibe mensagem
ao usuário
Informa os dados
do novo cliente
Salva dados
do cliente
[Cliente já existe]
[Cliente Não existe]
FONTE: Disponível em: <www.purainfo.com.br/artigos/uml-diagrama-de-atividades>. 
Acesso em: 10 set. 2015.
Diagrama de máquina de estados: Esboça a visão dinâmica de um sistema 
(TACLA, 2010).
Principais componentes: estado, evento.
Esse diagrama mostra os estados que podem ser assumidos por um 
objeto em seu ciclo de vida. Geralmente o utilizamos para entender 
como tais mudanças acontecem, de modo a podermos definir as trocas 
de mensagens e os métodos que as controlam. O início da transição 
é representado por um círculo preenchido, e o final por um círculo 
preenchido, porém com um aro pintado de branco (PIVA, 2010, p. 193).
Utilizando o exemplo proposto pelo autor, atentemos para a situação 
da classe Produto da padaria do senhor João, que pode assumir três estados 
diferentes: 1 Ativo, 2 Ponto de encomenda e 3 Em falta. Esses valores são aplicados 
ao atributo situação quando a execução do caso de uso Registrar pagamento 
compra ou do caso de uso Registrar entrada de produtos.
52
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
FIGURA 32 - EXEMPLO DE DIAGRAMA DE MÁQUINA DE ESTADOS
Produto
Variação do atributo situação
recebeProduto( )
recebeProduto( )
recebeProduto( )
pagaCompra( )
pagaCompra( )
quantidadeEstoque+quantidadeEntrada>pontoEncomenda
quantidadeEstoque+quantidadeEntrada>pontoEncomenda
quantidadeEstoque<=pontoEncomenda
quantidadeEstoque<=pontoEncomenda
quantidadeEstoque - - 0
Ativo(I)
Em falta (3)
Ponto de encomenda (2)
FONTE: Piva (2010)
Pelo diagrama podemos perceber que, através de um estado ativo, 
o produto poderá mudar sua situação para “ENCOMENDA” ou 
“EM FALTA”, dependendo das suas saídas, sendo que a regra 
estabelecida para a situação de encomenda é seu saldo ser menor que 
o indicado para este campo. Observe também que somente os métodos 
pagarCompra e receberProduto alteram o estado do produto e que a 
baixa do estoque só se concretiza quando o pagamento da compra é 
efetivado (PIVA, 2010, p. 194).
TÓPICO 3 | DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
53
LEITURA COMPLEMENTAR
Usando a modelagem colaborativa no aprendizado da UML
Mauro C. Pichiliani1, Celso M. Hirata1 1
Divisão de Ciência da Computação – Instituto Tecnológico de 
Aeronáutica (ITA) 
Caixa Postal 12.228-900 - São José dos Campos - SP 
 {pichilia, hirata}@ita.br
Abstract. The design is an important task in the object-oriented software 
development. Collaborative tools has been considered to be used in software development, 
however little effort has been made in the assessment of usage of these tools for both 
productivity verification and ef ectiveness of collaborative learning. For the assessment 
of the effectiveness of collaborative learning, it is required the data collection for analysis. 
This article describes a study of data collection for the assessment of the effectiveness of 
learning of students groups where a collaborative tool was used to assist the learning 
of UML. 
Resumo. O projeto é uma tarefa importante no desenvolvimento de 
software orientado a objetos. Ferramentas colaborativas têm sido consideradas 
para serem utilizadas no desenvolvimento de software, contudo, pouco esforço 
tem sido feito na avaliação do uso dessas ferramentas tanto para a verificação de 
produtividade quanto para a eficácia do aprendizado colaborativo. Para avaliação 
da eficácia do aprendizado colaborativo existe uma necessidade de obtenção de 
dados para a análise. O presente artigo descreve um estudo da coleta de dados 
para a avaliação da eficácia do aprendizado de grupos de alunos onde uma 
ferramenta colaborativa foi empregada para auxiliar o aprendizado da UML.
1 INTRODUÇÃO
A área de Informática na Escola tem evoluído muito nessa década, 
principalmente pelo uso de ferramentas de groupware pedagógicas que exploram 
o uso de colaboração no aprendizado. De acordo com Stahl [STAHL, 2002], o uso 
de ferramentas de groupware na escola pode facilitar, dentre outras habilidades, o 
aprendizado colaborativo e a construção do conhecimento. Contudo, pouco esforço 
tem sido feito no sentido de avaliar quantitativamente a eficácia e produtividade 
do aprendizado dos alunos que utilizaram ferramentas colaborativas como 
instrumento pedagógico. 
Uma das maneiras de acompanhar a evolução do aprendizado de 
alunos que utilizam ferramentas colaborativas no aprendizado é analisar o 
aproveitamento dos estudantes por meio do histórico das interações dos alunos 
entre si e com o ambiente. O objetivo deste artigo é propor o uso de coleta de 
dados e umaalternativa de avaliação do aprendizado de grupos de alunos 
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
54
quando uma ferramenta colaborativa é empregada como instrumento pedagógico 
no aprendizado da UML (Unified Modeling Language) (BOOCH, 1998), por meio 
da análise do histórico das interações geradas durante o aprendizado. Neste 
contexto, este artigo apresenta uma análise das variáveis de coleta de dados do 
aprendizado de grupos de alunos em um experimento controlado. 
A partir desta análise dos dados coletados, o professor poderá dispor de 
um acompanhamento mais preciso do que o grupo realmente está aprendendo, 
assim como uma visão geral do processo ensino-aprendizagem. Este artigo está 
dividido em cinco seções. 
A Seção 2 descreve uma visão geral dos aspectos funcionais das ferramentas 
colaborativas e algumas abordagens de avaliação disponíveis na literatura. Na 
Seção 3 apresentam-se detalhes do grupo de alunos e do experimento realizado. Na 
Seção 4 apresenta-se uma alternativa de avaliação da eficácia de aprendizado dos 
grupos usando informações coletadas durante o uso da ferramenta colaborativa. 
Por fim, na Seção 5 são apresentadas algumas considerações finais.
2 FERRAMENTAS COLABORATIVAS
Uma ferramenta colaborativa que será empregada para auxiliar o ensino 
de algum conteúdo deve levar em consideração alguns aspectos funcionais 
para poder suportar a colaboração. Santoro et al. (2002) citam como principais 
aspectos funcionais a comunicação, a coordenação, a percepção (awareness), o 
compartilhamento de informações e a designação de papéis. A comunicação é de 
extrema importância em situações de trabalho em grupo, seja ela utilizada para 
trocar ideias, discutir, aprender, negociar ou para tomar decisões. 
A comunicação pode ser classificada em síncrona ou assíncrona, 
dependendo do momento no qual os membros receberam as mensagens 
enviadas pelo canal de comunicação. Diferentes canais de comunicação podem 
ser utilizados para tornar a comunicação mais eficiente e produtiva, como, por 
exemplo, chat ou audioconferência. Outra maneira de classificar a comunicação 
diz respeito à existência de ligações entre os participantes, através tanto de 
canais de comunicação direta, como troca de mensagens e reuniões, quanto por 
meio de um canal indireto através da memória de grupo, onde a construção e o 
compartilhamento do conhecimento comum podem ser considerados interfaces 
de comunicação. 
A coordenação do grupo que trabalha com uma ferramenta colaborativa 
síncrona pode exigir um sofisticado mecanismo de controle das ações para 
garantir o sucesso da colaboração. Mecanismos de controle de concorrência, 
como travas ou transformação operacional, são utilizados para garantir a 
consistência dos elementos que estão sendo manipulados pelos participantes da 
colaboração no documento compartilhado. Em situações onde a probabilidade 
de conflitos entre os usuários for baixa ou existir um moderador para coordenar 
as ações dos usuários, o controle de concorrência pode ser dispensado. Nestas 
TÓPICO 3 | DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
55
situações, a coordenação das ações pode ficar a cargo do chamado protocolo 
social, caracterizado pela ausência de mecanismos de controle explícitos entre 
as atividades e pela confiança nas habilidades dos participantes de mediar por si 
só as interações por meio de um canal de comunicação. Durante o trabalho em 
grupo a percepção representa grande importância e apresenta relacionamento 
com coordenação, comunicação e cooperação. 
Nas ferramentas colaborativas síncronas a percepção permite que um 
participante fisicamente separado esteja ciente da presença e das ações dos 
demais participantes da colaboração, facilitando o aprendizado em conjunto. 
A percepção também permite socializar virtualmente o ambiente e pode servir 
para indicar o esforço dos participantes em interagir com a ferramenta e com os 
demais participantes. A percepção, em geral, é implementada nas ferramentas 
colaborativas síncronas por meio de elementos de percepção que fornecem 
informações imediatas a respeito do estado dos participantes na colaboração e de 
suas interações com a ferramenta. 
Os elementos de percepção, apesar de vantajosos, não conseguem se 
aproximar da riqueza de informações proporcionadas pela interação face a face 
(SANTORO et al., 2002). A colaboração necessita que os participantes compartilhem 
informações a este aspecto, é essencial para os grupos devido à necessidade de 
prevenir esforços repetitivos e assegurar que todos os participantes do grupo 
estejam utilizando a mesma informação, de forma que não haja inconsistências. As 
ferramentas colaborativas geralmente fazem uso de documentos compartilhados, 
como mecanismo de compartilhamento de informações e de armazenamento 
da memória do grupo, que deve registrar todo o processo de interação, como 
a própria comunicação realizada e passos desencadeados, bem como todos os 
produtos gerados durante a colaboração. 
A utilização de papéis predefinidos em ferramentas colaborativas tem 
como objetivo principal estruturar as interações entre os participantes do grupo, 
definir tarefas e gerenciar o acesso aos elementos do documento compartilhado. 
Um papel descreve como um conjunto de indivíduos se relaciona com algum 
elemento compartilhado e com os outros participantes restantes do grupo por 
meio da especificação dos direitos e responsabilidades sobre diferentes tarefas 
dentro do processo de aprendizagem. A definição de papéis também é utilizada 
como um mecanismo de coordenação das atividades dos participantes, e 
ainda como um mecanismo de controle de acesso a elementos do documento 
compartilhado. No entanto, sua atribuição precipitada pode restringir o potencial 
criativo dos participantes, ou seja, cada indivíduo somente efetuaria as operações 
específicas de seu papel, sem que todo o seu potencial tenha sido alcançado. Além 
dos aspectos funcionais, o uso de uma ferramenta colaborativa como instrumento 
pedagógico deve levar em consideração a metodologia de ensino que está sendo 
aplicada. 
Várias metodologias de ensino já estão adaptadas para o uso de 
ferramentas colaborativas, e nestas metodologias o principal foco é na realização 
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
56
de tarefas por um grupo de alunos. Dentre essas metodologias, destacam-se: 
resolução de problemas, estudo de casos e abordagem dos sete passos (PADILHA 
et al., 2003). Os editores colaborativos CUTE (Collaborative UML Technique Editor) 
(DIAS e XEXÉO, 1997) e CO2DE (Collaborate to Design) (BORGES et al., 2003) são 
exemplos de iniciativas que permitem de edição colaborativa de diagramas da 
UML, assim como as ferramentas CASE (Computer Aided Software Engineering), 
comerciais Poseidon for UML (GENTLEWARE, 2006) e Magic Draw [No Magic 
2006]. O principal objetivo destas ferramentas é o produto final obtido pelas 
interações dos usuários, ao invés do processo de geração das interações. 
Devido a este objetivo, poucos recursos didáticos e pedagógicos foram 
implementados, tornando o suporte ao processo ensino-aprendizado limitado 
nestas ferramentas. Várias análises são sugeridas para avaliar a eficácia e o 
desempenho do aprendizado de alunos em atividades colaborativas. Lund e 
Baker (1999) analisam as interpretações de professores das interações dos alunos 
durante a resolução colaborativa de problemas. Padilha et al. (2003) propõem 
técnicas de Data Mining que detectam regras de associação por meio dos valores 
de variáveis observadas durante a colaboração.Avouris et al. (2003) descrevem 
um toolkit genérico para análise e processamento de dados coletados durante 
atividades de aprendizado colaborativas. Martinez et al. (2003) combinam 
avaliação qualitativa e análise da rede social para analisar as interações sociais e 
aspectos de participação no aprendizado colaborativo. Apesar de considerar os 
dados coletados a partir de experimentos colaborativos, nenhuma das análises 
citadas faz uso de índices quantitativos para auxiliar a avaliação da eficácia e 
produtividade do aprendizado colaborativo.
3 EXPERIMENTO REALIZADO
3.1 CONTEXTO DO EXPERIMENTO 
O intuito do estudo descrito neste artigo é apresentar ao professor uma 
análise da eficácia do aprendizado dos grupos de alunos que utilizaram uma 
ferramenta colaborativa para auxiliar a resolução de problemas. Um experimento 
controlado foi conduzido para analisar a eficácia do aprendizado de grupos 
de alunos que utilizaram uma ferramenta colaborativa no aprendizado da 
modelagem de diagramas da UML. A ferramenta colaborativa escolhida para 
realizar o experimento descrito neste artigo foi o ArgoUML (2006), que foi 
adaptada para suportar a edição colaborativa. As adaptações incluem um chat, um 
editor de diagramas da UML colaborativo e travas como mecanismo de controle 
de concorrência, além de elementos de percepção remota, como, por exemplo, 
telepointers e lista de elementos travados. A metodologia de ensino adotada 
durante o aprendizado dos grupos no experimento foi a resolução de problemas. 
Esta metodologia pode constituir tanto um conteúdo educativo como 
um modo de conceber as atividades educativas. O ensino baseado na resolução 
de problemas supõe fomentar nos alunos o domínio de procedimentos para dar 
respostas a situações distintas e mutáveis (POZO, 1998).
TÓPICO 3 | DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
57
3.2 AMBIENTE DO EXPERIMENTO
 O experimento foi conduzido com o objetivo principal de coletar dados 
para a análise da eficácia do aprendizado dos grupos de alunos. Este experimento 
constou da observação tanto das interações e o comportamento dos grupos de 
alunos, como também do modo no qual a ferramenta forneceu suporte para o 
processo de elaboração de diagramas desde a ideia conceitual até a versão do 
diagrama final. Para a realização do experimento, 12 alunos foram divididos, de 
forma aleatória, em seis pares, sem repetições. Os alunos eram estudantes do 
curso de pós-graduação com idades entre 23 e 34 anos (média de idade por volta 
de 26 anos com desvio padrão igual a 2,27, incluindo seis homens e seis mulheres). 
O experimento foi realizado entre novembro de 2005 e janeiro de 2006. 
Os alunos participantes foram divididos em dois conjuntos: no primeiro 
conjunto, os grupos 1, 2 e 3 utilizaram um chat como canal de comunicação, e no 
segundo conjunto, os grupos 4, 5 e 6 utilizaram um software de audioconferência 
para se comunicar. A divisão dos pares de alunos em dois conjuntos tem como 
objetivo identificar a influência de diferentes canais de comunicação na evolução 
do aprendizado. O ambiente utilizado no experimento foi composto de duas 
salas, onde os alunos utilizaram o ArgoUML em suas estações de trabalho, sem 
nenhum contato visual com seus parceiros. Em cada sala um experimentador 
observou o comportamento do aluno, enquanto uma câmera de vídeo fez a 
gravação das expressões faciais e do diálogo entre os alunos. 
Cada aluno preencheu um formulário sobre seu perfil antes de iniciar as 
tarefas que foram monitoradas no experimento. Em seguida, os alunos receberam 
um documento explicando o cenário fictício e o problema em questão para cada 
uma das três tarefas a serem completadas no experimento. Os alunos indicaram 
aos experimentadores quando chegaram a um consenso sobre o término de cada 
tarefa, para só então responderem a um questionário sobre o esforço requerido 
pela tarefa completada. Ao término das três tarefas, cada aluno recebeu um 
questionário de avaliação final e participou de uma breve entrevista com o 
experimentador. Os principais dados objetivos coletados durante o experimento 
foram registrados no log interno da ferramenta, que armazenou o histórico da 
interação dos alunos entre si e com o editor colaborativo.
 A gravação em vídeo das expressões faciais e do diálogo entre os alunos, 
as respostas dos questionários e as observações do experimentador forneceram 
informações subjetivas sobre o aprendizado.
3.3 VARIÁVEIS OBSERVADAS 
A definição das variáveis a serem observadas durante a execução das 
tarefas teve como base os recursos disponíveis no ambiente colaborativo para 
a resolução de problemas e nos aspectos que evidenciam a aprendizagem. Na 
Tabela 1 são apresentadas as variáveis observadas, bem como uma breve descrição 
do seu significado e seus valores discretos. O valor numérico colocado entre 
58
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
parênteses após o valor discreto da variável foi utilizado para o cálculo do índice 
de aproveitamento, descrito na próxima seção. Os valores contínuos das variáveis 
QtdElementos, QtdTravas, TempoGasto e QtdMensagens foram obtidos a partir 
dos dados armazenados no log da ferramenta. 
A transformação dos valores contínuos destas variáveis em valores discretos 
se baseia na observação e análise dos valores contínuos e no contexto no qual os 
pares executaram cada tarefa. Por exemplo, o valor discreto Alta para a variável 
QtdMensagens, atribuída a uma tarefa executada por um par, leva em consideração o 
valor contínuo da variável, o canal de comunicação utilizado e a comparação com os 
valores contínuos dos demais pares para esta mesma tarefa e variável. Para os valores 
das variáveis EsforçoPercebido e DificuldadeApontada nenhuma transformação 
foi necessária, pois eles foram coletados diretamente dos questionários de esforço 
requerido que continham perguntas cujas respostas apresentavam escalas de valores 
correspondentes aos da Tabela 1 para estas variáveis.
Nome da variável Descrição da variável Valores discretos
QtdsElementos
Quantidade de elementos 
criados
Alta(3), Média(2), Baixa(1)
QtdTravas
Quantidade de travas 
concedidas nos elementos do 
modelo
Alta(3), Média(2), Baixa (1)
TempoGasto
Tempo de duração total da 
tarefa
Longo(3), Médio (2), Curto(1)
EsforçoPercebido
Grau de esforço percebido 
pelo par durante a realização 
tarefa
Muito esforço(5), Algum 
esforço(4), Esforço razoável(3), 
Pouco esforço (2), Nenhum 
esforço(1)
DificuldadeApontada
Grau de dificuldade apontado 
pelo par durante a realização 
da tarefa
Muito difícil(5), Difícil(4), 
Nem difícil nem fácil(3), 
Fácil(2), Muito fácil(1)
QtdMensagens
Quantidade de mensagens 
relevantes enviadas durante a 
comunicação
Alta(3), Média(2), Baixa(1)
4 ALTERNATIVA DE AVALIAÇÃO DA EVOLUÇÃO DA EFICÁCIA
A análise da evolução da eficácia de aprendizado dos alunos, para a 
resolução dos problemas, é realizada considerando o conjunto de problemas, 
assim é possível ter um mapeamento superficial do desempenho dos alunos. Com 
os dados obtidos das variáveis, o professor pode medir a eficácia de aprendizado 
dos alunos baseado no aspecto que melhor lhe convir. Neste artigo sugerimos 
a utilização de um índice de aproveitamento que leva em consideração todas 
as variáveis observadas durante o experimento, com o objetivo de auxiliar na 
avaliação do desempenho do aprendizado dos grupos na resolução dos problemas 
de forma colaborativa. O cálculo do índice de aproveitamento dos pares na 
execução das tarefas foi baseado nas variáveis descritas na seção anterior. 
TÓPICO 3 | DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
59
O valor entre parênteses apresentado apóso valor discreto das variáveis 
na Tabela 1 é somado para cada tarefa de cada par. Deste modo, o índice considera 
que o par teve um bom aproveitamento se todas as variáveis apresentarem 
valores altos, tais como uma grande quantidade de elementos criados ou um 
maior tempo gasto durante a tarefa. O índice de aproveitamento é calculado em 
percentual com base no aproveitamento máximo possível obtido através da soma 
dos valores de todas as variáveis observadas. Um gráfico de colunas com o índice 
de aproveitamento calculado para cada par e tarefa é apresentado na Figura 1. 
Este gráfico apresenta, em colunas, o aproveitamento dos pares em cada uma das 
tarefas, considerando o índice de aproveitamento, em porcentagem. Analisando 
os dados do gráfico pode-se inferir que os alunos do par 5 foram os únicos alunos 
cujo aproveitamento foi constante nas tarefas 1 e 2, fato que pode ser explicado 
pelos valores discretos iguais para as variáveis QtdTravas e TempoGasto nas duas 
primeiras tarefas realizadas por estes pares. Já os pares 1, 4 e 6 mostraram um 
maior aproveitamento na tarefa 2, pois eles possuíram o valor discreto Alta para 
a variável QtdMensagens, valor este que provavelmente influenciou de forma 
direta os valores das outras variáveis. Os pares 2 e 3 possuem uma queda de 
aproveitamento em comum nas tarefas 2 e 3, que pode ser explicado pelo pouco 
tempo gasto na execução destas tarefas em conjunto e também devido ao pouco 
esforço gasto na execução destas tarefas.
61 61
4343
74
61
39 30
69
78
87
56
52 52
74
100
90
80
70
60
50
40
30
20
10
0
62 62 62
Par 1 Par 2 Par 3 Par 4 Par 5 Par 6
Pares
A
pr
ov
ei
ta
m
en
to
 (%
)
Tarefa 1
Tarefa 2
Tarefa 3
O índice de aproveitamento sugerido é uma proposta que auxilia a 
avaliação do aprendizado dos alunos e deve ser utilizado em conjunto com 
outros métodos de avaliação qualitativa, como, por exemplo, a nota que o 
professor atribui às soluções dos problemas apresentados. Este índice é relevante 
para pesquisados e educadores que estão envolvidos na análise e avaliação das 
atividades de aprendizado e na modelagem e criação de novas ferramentas e 
métodos para o estudo da eficácia de aprendizado em atividades colaborativas. 
Ele tem como objetivo fornecer uma ideia superficial da eficácia e produtividade 
do aprendizado dos grupos de alunos e ajudar o professor a detectar mais 
facilmente o aproveitamento no aprendizado.
60
UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE 
 VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS
5 CONSIDERAÇÕES FINAIS 
Este trabalho apresentou dados coletados a partir do uso de uma 
ferramenta de modelagem colaborativa e propôs uma alternativa de avaliação do 
aprendizado de grupos de alunos que utilizaram uma ferramenta colaborativa 
para auxiliar o aprendizado da UML em um experimento controlado. 
A utilização de ferramentas de groupware na instrução abre novas 
possibilidades de aprendizado. Entretanto, a medição e a avaliação do desempenho 
do aprendizado auxiliado por ferramentas colaborativas ainda carecem de estudos 
mais aprofundados. Por meio da análise das interações dos alunos entre si e com a 
ferramenta foi possível identificar os problemas que apresentaram maior ou menor 
grau de dificuldade aos grupos, e também identificar os aspectos que podem influenciar 
no aprendizado colaborativo. Com a possibilidade de coleta dos dados e do índice 
de desempenho apresentados neste artigo, espera-se auxiliar o professor na avaliação 
do desempenho do aprendizado dos grupos de alunos, além de fornecer recursos 
para que o professor possa acompanhar e conhecer as dificuldades no aprendizado 
dos alunos quando estes utilizam uma ferramenta colaborativa. Desta maneira, a 
atividade de avaliação geral do professor pode ser amenizada, principalmente no 
aspecto do acompanhamento do aprendizado do aluno. O ArgoUML adaptado para 
permitir a edição colaborativa síncrona está disponível para download no endereço: 
<http://www.comp.ita.br/~pichilia/argo.htm>. 
Agradecimentos. Os autores gostariam de agradecer aos revisores 
anônimos que contribuíram para a melhoria deste trabalho e a todos os envolvidos 
na elaboração do experimento. 
FONTE: Disponível em: <http://www.comp.ita.br/pichilia/argo.htm>. Acesso em: 10 out. 2015.
61
RESUMO DO TÓPICO 3
Neste tópico você viu que:
• Um diagrama de atividade mostra um processo de negócios ou um software 
como um fluxo de trabalho por meio de uma série de ações. Computadores, 
componentes de software ou as pessoas podem executar essas ações.
• Você pode usar um diagrama de atividades para descrever processos de 
diversos tipos, como os exemplos a seguir:
o Um processo de negócios ou um fluxo de trabalho entre usuários e seu 
sistema. Para obter mais informações, consulte Requisitos de usuário do 
modelo.
o As etapas executadas em um caso de uso. Para obter mais informações, 
consulte Diagramas de caso de uso UML: diretrizes.
o Um protocolo de software, ou seja, as sequências permitidas de interações 
entre os componentes.
o Um algoritmo de software.
 
• O diagrama de máquina de estados mostra os estados que podem ser assumidos 
por um objeto em seu ciclo de vida. Geralmente o utilizamos para entender 
como tais mudanças acontecem, de modo a podermos definir as trocas de 
mensagens e os métodos que as controlam.
62
1 Analise o Diagrama de Casos de Uso abaixo, referente a um módulo 
de matrícula, e construa um Diagrama de Atividades para demonstrar 
modelagem dos processos do negócio.
AUTOATIVIDADE
Aluno
Consultar
Informações
de Turmas
Manter Aluno RealizarMatrícula
Consultar
Informações
de Cursos
<<extend>>
<<extend>>
<<include>>
2 Construa um Diagrama de Atividades para o seguinte processo de negócio:
- A autorização do pagamento tem início após um pedido ter sido realizado 
pelo cliente. 
- Ao mesmo tempo, a disponibilidade para cada um dos itens do pedido é 
verificada pelo depósito. 
- Se a quantidade requisitada de um determinado item existe em estoque, 
tal quantidade é associada ao pedido, caso contrário, a quantidade do 
item será alterada (se houver em quantidade menor), se a quantidade em 
estoque for igual a zero, o item será excluído. 
- O pedido é enviado pelo depósito ao cliente quando todos os itens 
estiverem associados e o pagamento estiver autorizado. 
- O pedido será cancelado se a ordem de pagamento não tiver sido autorizada.
3 Desenhe o diagrama de estados de uma tostadeira. Defina os diferentes estados 
do pão na tostadeira, sem esquecer de especificar os necessários eventos, ações 
e condições com guarda.
4 Uma das formas de modelar o aspecto dinâmico de um sistema com a UML 
2.0 é através da utilização do diagrama de máquina de estado (state machine 
diagram). Nesse contexto, considere os dois diagramas de máquinas de 
estados representados a seguir, de acordo com a notação da UML. Considere 
que os eventos e as atividades homônimas em ambos os diagramas têm o 
mesmo significado.
63
entry/atividade00
evento01/atividade01
evento02/atividade02
A
B
evento03
entry/atividade00
evento01/atividade01
A
B
evento03
evento02/atividade02
Os dois diagramas de máquinas de estados apresentados são equivalentes 
entre si.
 
PORQUE
Modelar o evento02 com uma transição recursiva (conforme o diagrama 
da direita) é equivalente a modelar o evento02 com uma atividade interna 
(conforme o diagrama da esquerda).
 
Analisando-se as afirmações acima, conclui-se que:
a) As duas afirmações são verdadeiras, e a segunda justifica a primeira.
b) As duas afirmações são verdadeiras, e a segunda não justifica a primeira.
c) A primeira afirmação é verdadeira,e a segunda é falsa.
e) As duas afirmações são falsas.
64
65
UNIDADE 2
DIAGRAMAS COMPORTAMENTAIS 
(INTERAÇÃO)
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
Ao final desta unidade você será capaz de:
• conhecer as principais características dos diagramas compor-tamentais;
• elaborar diagramas comportamentais de interação;
• conhecer as principais características dos diagramas estruturais;
• elaborar diagramas estruturais.
Esta unidade de ensino contém três tópicos e no final de cada um deles você 
encontrará atividades que contribuirão para a apropriação dos conteúdos.
TÓPICO 1 – DIAGRAMAS DE INTERAÇÃO
 
TÓPICO 2 – DIAGRAMAS ESTRUTURAIS: DE CLASSES E DE PACOTES
 
TÓPICO 3 – DIAGRAMAS ESTRUTURAIS: DE OBJETOS E DE COMPO-
NENTES
66
67
TÓPICO 1
DIAGRAMAS DE INTERAÇÃO
UNIDADE 2
1 INTRODUÇÃO
Diagramas de Interação representam como o sistema age internamente para 
que um ator atinja seu objetivo na realização de um caso de uso, com o objetivo de obter 
informações adicionais para completar e aprimorar outros modelos (principalmente 
o modelo de classes), além de fornecer aos programadores uma visão detalhada dos 
objetos e mensagens envolvidos na realização dos casos de uso.
A mensagem é o componente principal da interação entre objetos. Um 
sistema orientado a objetos é uma rede de objetos que trocam mensagens. Objetos 
só podem interagir através de mensagens. Por exemplo: um objeto envia uma 
mensagem para outro objeto quando o primeiro deseja que o segundo realize 
alguma tarefa. Neste sentido, os Diagramas de Interação mostram como os 
objetos interagem uns com os outros, sendo usados tanto na análise quanto no 
desenvolvimento do projeto de forma geral.
Estes diagramas modelam aspectos dinâmicos do sistema, ou seja, as 
situações que sofrem mudanças ao longo do tempo.
Os Diagramas de Interação são: Diagrama de Sequência, Diagrama de 
Comunicação, Diagrama de Tempo e Diagrama de Visão Geral. 
2 DIAGRAMA DE SEQUÊNCIA
Detalham a sequência de um processo, representando os atores e objetos 
envolvidos num cenário e a sequência de troca de mensagens ao longo do tempo 
para realizar o cenário. É construído a partir do diagrama de casos de uso. Ordena 
de forma temporal as mensagens trocadas entre os objetos.
A notação para uma mensagem em um Diagrama de Sequência é uma 
flecha (geralmente desenhada na horizontal) ligando uma linha de vida à outra. 
O objeto do qual parte a seta é aquele que está enviando a mensagem (objeto 
remetente). O objeto para o qual a seta aponta é aquele que está recebendo a 
mensagem (objeto receptor). O formato da ponta da seta indica o tipo de 
mensagem sendo enviada (síncrona ou assíncrona). O rótulo da mensagem é 
posicionado acima dessa seta.
UNIDADE 2 | DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)
68
Um Diagrama de Sequência permite identificar os métodos e atributos de 
cada classe, assim como as responsabilidades de cada classe na realização de um 
caso de uso. Os elementos básicos de um Diagrama se Sequência são (TACLA, 
2010, p. 36): 
• Atores: São entidades externas que interagem com o sistema e que 
solicitam serviços. Normalmente, o ator primário é o responsável por 
enviar a mensagem inicial que inicia a interação entre os objetos.
• Objetos: Representam as instâncias das classes representadas no 
processo.
• Linha do tempo (uma para cada objeto e ator): As linhas de vida 
compõem a dimensão vertical. Uma linha de vida é composta de duas 
partes, a cabeça e a cauda. A cabeça é representada por um retângulo 
com dois compartimentos, no compartimento superior a identificação 
do objeto é exibida e no compartimento inferior (cuja utilização é 
opcional) aparecem valores para os atributos definidos na classe do 
objeto. A cauda corresponde a uma linha vertical tracejada.
• Comunicação: entre ator e objeto ou entre objetos.
• Interpretação das mensagens: por exemplo, evento do sistema operacional 
ou de uma interface, envio de mensagem ou chamada de método.
FIGURA 33 – REPRESENTAÇÃO DE DIAGRAMA DE SEQUÊNCIA
usuário
objeto
sincrona
resposta
assincrona
ativação|
Linha da
vida
:A :B
FONTE: Piva (2010)
2.1 TIPOS DE MENSAGEM
Há vários tipos de mensagem que podem ser utilizados num Diagrama 
de Sequência, sendo os mais comuns os seguintes:
TÓPICO 1 | DIAGRAMAS DE INTERAÇÃO
69
• Simples: quando o tipo de mensagem é irrelevante ou ainda não foi definido.
• Síncrona: quando enviada, o emissor fica bloqueado aguardando a resposta.
• Assíncrona: o emissor não bloqueia até que o receptor envie resposta para 
continuar seu processamento.
• Retorno ou resposta: resposta à mensagem síncrona; pode ser omitida. 
Uma mensagem é definida sintaticamente por:
• Expressão-sequência recorrência: v := mensagem
• Expressão-sequência: é um número sequencial de envio das mensagens. 
Por exemplo, 1: msg1 2: msg2 representando que a mensagem msg1 precede 
a msg2.
• Recorrência: indica um envio condicional ou uma repetição. Zero ou mais 
mensagens são enviadas dependendo da condição envolvida. As opções 
são:
*[cláusula-iteração] ou[guarda]
Não há sintaxe rígida definida pela UML, a cláusula de interação e 
a condição de guarda podem ser especificadas em pseudocódigo ou na 
linguagem-alvo. 
FONTE: Disponível em: <https://www.passeidireto.com/arquivo/6299813/analise-e-projeto-oo-e-
uml/12>. Acesso em: nov. 2015.
Utiliza-se um Diagrama de Sequência quando há a necessidade de 
representar o comportamento de vários objetos dentro de um contexto específico, 
a partir de mensagens que são trocadas entre eles. Os atores são os mesmos do 
diagrama de casos de uso. Um Diagrama de Sequência não representa atributos.
Passos para a criação de um Diagrama de Sequência:
• Escolher um caso de uso 
• Identificar os objetos que fazem parte da interação 
• Identificar o objeto que começa a interação 
• Identificar as mensagens trocadas entre os objetos 
• Identificar a sequência destas mensagens
Notação do Diagrama de Sequência
UNIDADE 2 | DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)
70
FIGURA 34 – NOTAÇÃO DO DIAGRAMA DE SEQUÊNCIA
Objeto
Ator
Mensagens
Tempo
FONTE: Disponível em: <http://www.dmo.fee.unicamp.br/henrique/
cursoc++/diagrama.pdf>. Acesso em: 10 out. 2015.
Exemplo de Diagrama de Sequência
FIGURA 35 – EXEMPLO DE DIAGRAMA DE SEQUÊNCIA
Cliente Atendente Gerente
Comunicar extravio de fita
Solicitar registro de aluguel
Retornar registro de aluguel
Retornar registro da fita
Buscar aluguel
Buscar fita
Solicitar registro da fita
Solicitar conversa com gerente.
Negociar Multa
Falar com Gerente
Pagar Multa
Sistema da
VideoLocadora
FONTE: Disponível em: <http://www.dmo.fee.unicamp.br/henrique/cursoc++/diagrama.pdf>. 
Acesso em: 10 out. 2015.
2.2 DIAGRAMA DE COMUNICAÇÃO
Antes da versão 2.0 era chamado de Diagrama de Colaboração. Contempla 
as mesmas informações que o Diagrama de Sequência, mas não considera a 
dimensão temporal. 
Considerando a sua estrutura, é semelhante a um Diagrama de Objetos, 
sendo que a principal diferença entre os dois é que são adicionados setas e rótulos 
TÓPICO 1 | DIAGRAMAS DE INTERAÇÃO
71
de mensagens nas ligações entre esses objetos. E as ligações (linhas que ligam 
objetos) remetem aos relacionamentos existentes entre os mesmos.
2.2.1 Principais componentes: objetos, mensagens e 
vínculo
Para Tacla (2010, p. 34) “o Diagrama de Comunicação mostra a relação 
entre os objetos, analisando a troca de mensagens entre eles. Mas não se preocupa 
necessariamente com a ordem em que elas ocorrem, e sim com quais objetos as 
mensagens são trocadas e quais são as mensagens”.
Diferente de um Diagrama de Sequência, um Diagrama de Comunicação 
mostra os relacionamentos entre os objetos. Os Diagramas de Sequência e 
os Diagramas de Comunicaçãoexpressam informações semelhantes, mas as 
mostram de maneiras diferentes. Os Diagramas de Comunicação mostram os 
relacionamentos entre os objetos e proporcionam uma melhor compreensão de 
todos os efeitos causados em determinado objeto e para design de procedimentos.
Observe a Figura 36. Verifique que a composição é basicamente a mesma de 
um Diagrama de Sequência, porém, em ordem diferente, com foco para as mensagens 
trocadas entre os objetos, não em quando estas mensagens foram trocadas.
Pode-se então escolher em usar o Diagrama de Sequência ou o Diagrama 
de Comunicação, podendo obviamente optar por criar os dois quando se tem 
uma situação atípica para analisar. 
UNIDADE 2 | DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)
72
FIGURA 36 – COMPONENTES DO DIAGRAMA DE COMUNICAÇÃO
:ItemCompra
:Compra
:Funcionario
Produto:Cliente :FRegistraProduto
1: verifi caFuncionario(cpf,senha): boolean
3: valorUnitario=verifi caProduto(produto,quantidade): double
4: ItemCompra(produto,quantidade,precoUnitarioVenda,
funcionario: boolean
5: atualizaTotalCompra(valorTotalItem: boolean
2: verifi caCartao(nroCartao): boolean
FONTE: Piva (2010)
• Também chamado de Diagrama de Colaboração. 
• Defi ne a estrutura de como os objetos estão vinculados. 
• Semelhante ao Diagrama de Classes. 
• Indica quais mensagens são trocadas entre objetos. 
• Semelhante ao Diagrama de Sequência S.
• Diagrama de Sequência se concentra na ordem temporal em que as mensagens 
são trocadas.
• Diagrama de Comunicação se preocupa com a organização estrutural dos 
objetos. 
2.2.2 Notação: semelhante ao Diagrama de Sequência
Um dos principais objetivos do Diagrama de Comunicação é identifi car 
os vínculos que são ligações existentes entre os objetos envolvidos no processo. 
Um vínculo é representado por uma linha unindo dois objetos.
Deve existir relacionamento equivalente no Diagrama de Classes. 
TÓPICO 1 | DIAGRAMAS DE INTERAÇÃO
73
FIGURA 37 – NOTAÇÃO
curso1: Curso turma1:Turma
FONTE: O autor
As notações são as mesmas definidas no Diagrama de Sequência e 
geralmente representam chamadas de métodos.
No Diagrama de Comunicação não existe a preocupação com a ordem, 
somente com quem dispara a mensagem, não existindo mensagens de retorno.
FIGURA 38 – REPRESENTAÇÃO DE MENSAGENS
curso1: Curso turma1:Turma
1: VisTurma( )
FONTE: O autor
2.2.3 Atores
São os mesmos do Diagrama de Sequência e Casos de Uso. Atores enviam 
e recebem mensagens através de vínculos, assim como ocorre com os objetos no 
Diagrama de Comunicação.
2.2.4 Condições
São condições que devem ser atendidas para que uma mensagem possa 
ser enviada. Notação: a condição vem entre colchetes antes da mensagem. 
FIGURA 39 – REPRESENTAÇÃO DE CONDIÇÕES
Gerente
minha_conta: Conta
[se saldo = 0] encerrarConta( )
FONTE: O autor
UNIDADE 2 | DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)
74
2.2.5 Autochamadas 
Objetos podem disparar mensagens para eles mesmos, como ocorre 
no Diagrama de Sequência. Esta situação indica que o objeto tem que fazer 
determinada tarefa para finalizar o serviço solicitado.
FIGURA 40 – REPRESENTAÇÃO DE AUTOCHAMADAS
fisica1:Fisica
1: valCPF0
FONTE: O autor
2.2.6 Exemplo de Diagrama de Comunicação
FIGURA 41 – DIAGRAMA DE COMUNICAÇÃO
:Banco
hist1: Históricoconta1: Conta Comum
fisica1:Fisica
1: conCPF0
2: [Se necessário] Gravar ( )
4: Gravar ( )
3: Abertura ( )
FONTE: O autor
Passos para criar um Diagrama de Comunicação
• Verificar a consistência dos diagramas de interação em relação aos Casos de 
Uso e ao modelo de classes.
• Cada cenário relevante para cada caso de uso deve ser considerado na 
modelagem de interações.
• Durante a construção do Diagrama de Interação pode-se identificar novas 
classes.
• Atributos, associações e operações também surgem como subproduto da 
construção dos Diagramas de Interação.
TÓPICO 1 | DIAGRAMAS DE INTERAÇÃO
75
2.3 DIAGRAMA DE TEMPO
O Diagrama de Temporização foi incluído a partir da UML 2.0 e apresenta 
o comportamento dos objetos e sua interação em uma escala de tempo, sempre 
com foco para as situações que mudam num determinado intervalo, além 
de descrever a interação e a evolução de estados, e de monitorar as restrições 
temporais do sistema (MELO, 2011). 
Colaborando, Guedes (2011, p. 76) complementa: “O Diagrama de 
Temporização ou de tempo apresenta a mudança no estado ou condição de uma 
instância de uma classe ou seu papel durante um período. Utilizado para mostrar 
a mudança no estado de um objeto no tempo em resposta a eventos externos”.
É um diagrama de interação, pois mostra os tempos reais em diferentes 
objetos e papéis, em vez de sequências de mensagens relativas. São geralmente 
utilizados em projetos de sistemas de tempo real, onde impera o tempo gasto na 
troca de mensagens e de estado na execução de todas as tarefas. Por este motivo, 
não são utilizados em todos os tipos de projetos, somente nos casos em que o 
tempo seja um fator determinante (TACLA, 2010).
Descreve a mudança no estado ou na condição de uma instância de uma 
classe ou seu papel durante um tempo. É tipicamente utilizado para demonstrar 
a mudança no estado de um objeto no tempo em resposta a eventos externos.
Os principais componentes do diagrama de tempo são: classes, linha de 
tempo, mensagens. A figura a seguir mostra um exemplo de diagrama de tempo.
td Sistema de Controle de Submissões - Estados do Congresso
Aceitando submissões
{03/01..31/03} {01/04..31/05} {01/06..15/06} {11/07..15/07}
Avaliando submissões
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100
Comunicando autores
Realizando congresso
:C
on
gr
es
so
FIGURA 42 – DIAGRAMA DE TEMPO
FONTE: Disponível em: <https://www.novatec.com.br/livros/uml2-2ed/capitulo9788575223857.
pdf>. Acesso em: 15 out. 2015.
UNIDADE 2 | DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)
76
2.4 DIAGRAMA DE VISÃO GERAL
Através do Diagrama de Visão Geral é possível aglomerar vários tipos 
distintos de diagramas. Podemos entendê-lo como uma variação dos diagramas de 
atividade e sequência, uma vez que sua notação é a mesma destes dois diagramas.
São utilizados em situações complexas, para simplificar determinadas 
situações. São eficazes em reuniões quando existe a necessidade de demonstrar 
cenários de alta complexidade. Uma particularidade é que, conforme mencionado 
acima, não possui uma notação específica.
Este diagrama permite capturar de uma perspectiva estática os fluxos 
de interação entre os componentes do sistema, de forma geral, do 
funcionamento global do sistema, de forma similar ao modelo expresso 
pelo Diagrama de Atividades, que mostra o fluxo de um subsistema, 
ou de uma dada funcionalidade em questão (TACLA, 2010, p. 45).
Ainda de acordo com o autor, o objetivo precípuo deste diagrama consiste 
em analisar as sequências necessárias para executar determinada funcionalidade 
do sistema que está sendo elaborado. Como exemplo de funcionalidade podem 
ser citados vários casos de uso. 
Os principais componentes do diagrama de visão geral são: diagramas de 
sequência, decisões, fluxos.
77
RESUMO DO TÓPICO 1
Neste tópico você aprendeu que:
• Os Diagramas de Interação constituem um passo importante nesta divisão, pois 
detalham os objetos das classes de análise e, por consequência, quais operações 
cada um deve realizar. Se um caso de uso possui vários fluxos, pode ser útil 
criar um diagrama de interação para cada cenário. Os diagramas de interação 
mais utilizados são o de Sequência e o de Comunicação (ex-colaboração).
• Diagramas de Interação são usados tanto na análise quanto no projeto. Na 
análise, as comunicações entre objetos são mais abstratas, não importando 
muito os argumentos e valores retornados. No projeto, o detalhamento é maior.
• Osdiagramas de Interação são: Diagrama de Sequência, Diagrama de 
Comunicação, Diagrama de Tempo e Diagrama de Visão Geral. 
• Um Diagrama de Sequência representa os atores e objetos envolvidos num cenário 
e a sequência de troca de mensagens ao longo do tempo para realizar o cenário.
• Um Diagrama de Sequência permite identificar os métodos e atributos de cada 
classe, assim como as responsabilidades de cada classe na realização de um 
caso de uso. Os elementos básicos de um Diagrama de Sequência são:
o	Atores
o	Objetos
o	Linha do tempo (uma para cada objeto e ator)
o	Comunicação entre ator e objeto ou entre objetos
o	Interpretação das mensagens: por exemplo, evento do sistema operacional ou 
de uma interface, envio de mensagem ou chamada de método.
• Diagrama de Comunicação (antes da versão 2.0 era chamado Colaboração) é 
outra forma de representar um cenário: contém as mesmas informações que o 
Diagrama de Sequência, mas não considera a dimensão temporal. Alguns autores 
recomendam utilizá-lo para analisar a colaboração das classes de realização de 
um caso de uso, pois facilita a identificação das classes que colaboram de forma 
mais próxima e, por consequência, a identificação de pacotes de análise.
	 o	Principais componentes: objetos, mensagens.
• O Diagrama de Comunicação mostra a relação entre os objetos, analisando a 
troca de mensagens entre eles. Mas não se preocupa necessariamente com a 
ordem em que elas ocorrem, e sim com quais objetos as mensagens são trocadas 
e quais são as mensagens.
78
• Em muitos projetos, usa-se ou o Diagrama de Sequência ou o Diagrama de 
Comunicação, mas também pode-se criar ambos para análise de alguma 
situação particular. 
• É um Diagrama de Interação, que mostra os tempos reais em diferentes objetos 
e papéis, em vez de sequências de mensagens relativas (BOOCH; RUMBAUGH; 
JACOBSON, 2005).
• O Diagrama de Temporização, como o nome diz, tem seu foco principal no estudo 
do tempo gasto nas trocas de mensagens entre os componentes do sistema.
• Esse é um diagrama de uso específico, que não se utiliza em todos os projetos.
	 o Principais componentes: classes, linha de tempo, mensagens.
• O Diagrama de Visão Geral Congrega uma determinada visão que pode 
englobar vários diagramas.
• Geralmente o Diagrama de Visão Geral de interação é uma variação do 
Diagrama de Atividades mais o Diagrama de Sequência, proposto na versão 
atual de UML. Seus elementos sintáticos são os mesmos dos Diagramas de 
Atividades e Sequência. 
• As interações que fazem parte do Diagrama de Visão Geral de interação podem 
ser referências a diagramas de interação existentes na especificação tratada.
• É necessário, em casos em que as sequências das interações se mostrarem 
tão complexas, que requisitem um resumo que possibilite uma visão geral 
daquela situação.
• É muito eficaz em reuniões e demonstrações de situações complexas, devemos 
utilizá-lo de forma intensiva, pois não existe outro diagrama que nos dê uma 
visão tão completa dos passos que uma situação, classe ou objeto possa passar.
• Não possui notações próprias. 
• Em geral usa as mesmas notações dos diagramas dos quais está englobando.
• Geralmente usa a mesma notação do Diagrama de Atividades. 
	 o Principais componentes: diagramas de sequência, decisões, fluxos.
79
AUTOATIVIDADE
1 Construa um Diagrama de Sequência para abrir uma conta, conforme a 
descrição abaixo: 
O cliente que deseja abrir uma conta no banco encaminha um pedido 
de abertura de conta, com a documentação necessária. O funcionário do banco, 
então, irá consultar o cadastro do cliente por meio do seu CPF, para determinar 
se o solicitante já se encontra cadastrado. Se o cliente já estiver cadastrado, 
a consulta retornará as informações do cliente, caso contrário retornará um 
valor significando que o cliente ainda não possui cadastro na instituição. 
Em seguida, o cadastro do cliente poderá ser atualizado, caso necessário, 
podendo gerar uma nova instância da classe Cliente, se o solicitante ainda não 
estiver registrado, ou simplesmente atualizar os dados do mesmo, se houver 
necessidade de alguma atualização. Antes de finalizar a atualização do cliente, 
algumas inconsistências devem ser levadas a efeito, uma delas é o disparo do 
método para validação do CPF pelo próprio objeto da classe Cliente. Após o 
término da atualização, o objeto da classe cliente retornará algum sinal para o 
funcionário do banco, para indicar que o cliente foi atualizado com sucesso ou 
se ocorreu algum erro. O banco então irá informar ao cliente se o seu pedido 
foi ou não aprovado. Em caso de aprovação, o cliente irá fornecer o valor 
inicial necessário para a abertura da conta e escolherá a senha. O funcionário 
irá disparar o método de abertura na classe ContaComum, ou seja, criará um 
novo objeto ContaComum. Após ter sido criado pela chamada do método 
abertura, o objeto de ContaComum irá disparar o método gravar para gerar 
uma nova instância da classe Historico, registrando o movimento gerado 
pela abertura da conta, pois, para abrir uma conta, a instituição exige que o 
cliente deposite algum valor na mesma. O método gravar retornará um sinal 
indicando que o movimento foi registrado com sucesso e o método abertura 
disparado na classe ContaComum, por sua vez, retornará o número da conta 
gerado, indicando que a conta foi criada com sucesso e finalizando o processo 
de abertura de conta.
FONTE: Disponível em: <http://professoralucelia.com.br/projSistemas/ExerciciosDiagramaDe
Sequencia03.pdf>. Acesso em: nov. 2015. 
2 Elabore um Diagrama de Comunicação para que um cliente possa abrir 
uma conta.
 Utilize as classes PessoaFisica, ContaComum e Histórico, conforme modelo 
abaixo.
 Como atores, considere Cliente e Banco.
80
PessoaFisica
+ ConsultaCP F( )
+ ValidaCPF ( )
+ Gravar ( )
: Int
: System .Boolean
: System .Boolean
Historico
+ Gravar ( ): System . Booelan
ContaComum
+ Abertura ( ) : Int
3 São diagramas de interação da UML que mostram um conjunto de objetos 
e as mensagens que poderão ser trocadas entre eles, enfatizando a ordem 
temporal de mensagens:
a) Diagrama de Atividades.
b) Diagrama de Objetos.
c) Diagrama de Comunicação.
d) Diagrama de Sequências.
4 Analise as seguintes afirmativas sobre os Diagramas de Interação da UML. 
I - Um Diagrama de Interação mostra a interação entre um conjunto de objetos 
e seus relacionamentos, incluindo as mensagens que poderãos ser trocada 
entre eles.
II - Diagramas de Sequência e Diagramas de Colaboração são Diagramas de 
Interação e modelam aspectos dinâmicos de sistemas.
III - Diagramas de Colaboração dão ênfase à ordenação temporal das mensagens 
trocadas entre os objetos.
 
Marque a alternativa CORRETA:
a) ( ) Apenas as afirmativas I e II são verdadeiras.
b) ( ) Apenas as afirmativas I e III são verdadeiras.
c) ( ) Apenas as afirmativas II e III são verdadeiras.
d) ( ) Todas as afirmativas são verdadeiras.
81
TÓPICO 2
DIAGRAMAS ESTRUTURAIS: DE CLASSES E DE PACOTES
UNIDADE 2
1 INTRODUÇÃO
Modelam as situações estáticas do sistema, ou seja, seu esqueleto e 
estruturas estáveis, que não sofrem mudanças (OMG, 2006).
Para Andrade (2007, p. 68), “a função dos diagramas estruturais é mostrar 
as características do sistema que não mudam ao longo do tempo. Os aspectos 
estáticos de um sistema de software envolvem a existência e a colocação de itens 
como classes, interfaces, colaborações, componentes”. A figura a seguir, ilustra os 
diagramas estruturais da UML. 
FIGURA 42 - DIAGRAMAS ESTRUTURAIS
Diagramas
Estruturais
Diagrama
de Objetos
Diagrama de 
Estrutura
Composta
Diagrama de
Componentes
Diagrama de
Implantação
Diagrama
de Pacotes
Diagrama
de Classes
Diagrama de
Implementação
FONTE: Piva (2010)
2 DIAGRAMA DE CLASSES
É apontadocomo sendo o diagrama mais utilizado, pois mostra o conjunto 
de classes, interfaces, colaborações e relacionamentos. Sua utilização é ampla, 
tendo início desde o momento da análise até o detalhamento da especificação 
(GUEDES, 2011). É considerado também o diagrama que possui o maior 
detalhamento quando pensamos em notações.
 É este diagrama que se aproxima mais da realidade de um código de 
programa, pois mostra conjunto de classes com seus atributos e métodos e os 
relacionamentos entre classes, amplamente utilizado no desenvolvimento de 
aplicações orientadas a objetos (LARMAN, 2007).
UNIDADE 2 | DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)
82
Apresenta as relações: 
• associação (mais comum);
• agregação (um tipo de associação);
• generalização/especialização.
FIGURA 43 – CLASSE CLIENTE
Clientes
- codPessoa
- num Cliente
+ setCadastrar ( )
+ getConsultar ( )
FONTE: O autor
A importância deste diagrama consiste no fato de que cada classe do 
diagrama representa uma tabela do banco de dados. Importante frisar que para 
identificar uma classe é necessário que antes se identifiquem os objetos que 
contenham características familiares ou semelhantes.
Quando se analisa uma situação real (cenário), é normal que se identifiquem 
vários objetos. Porém, nem todos farão parte do Diagrama de Classes. Para 
identificar os objetos essenciais deve-se colocar em prática o conceito de abstração, 
cuja finalidade é manter o foco somente nos aspectos relevantes da situação.
Como exemplo para o desenvolvimento do Diagrama de Classe, usaremos 
o cenário proposto por Tacla (2010, p. 65). Neste exemplo será possível identificar 
todas as classes para fazermos as ligações e determinarmos a cardinalidade.
2.1 CENÁRIO
Você trabalha para uma empresa de desenvolvimento como analista de 
sistemas. O responsável pelo setor onde você trabalha, em uma reunião, distribuiu 
tarefas para cada membro da equipe. Sua tarefa foi desenvolver um diagrama de 
classe para que seja iniciado o desenvolvimento de um novo software.
A empresa que nos contratou deseja adquirir o certificado ISO 9001 em 
qualidade, entretanto, uma das normas repassadas foi que deve ser obrigatório 
controlar os pedidos de suporte/serviço que são feitos pelos clientes.
O ramo da empresa é Service Desk[1] e o fluxo do processo segue abaixo:
TÓPICO 2 | DIAGRAMAS ESTRUTURAIS: DE CLASSES E DE PACOTES
83
Cliente entra em contato com a central através do telefone
Um atendente tem um prazo curto para registrar esta solicitação, 
informando os dados do cliente, o que foi solicitado, o nível de urgência, o 
grupo de atendimento, o técnico, um ou mais equipamentos envolvidos na 
manutenção. Anotar toda a interação realizada no equipamento, como, por 
exemplo: Se ele conectar remotamente ao equipamento, deve informar em um 
histórico, e suponhamos que três segundos depois ele reinicie o equipamento, 
deverá informar no histórico também. Resumindo: Toda interação deve ser 
anotada no registro com data e hora.
Caso ele consiga resolver o que foi solicitado, o técnico do Service Desk 
irá salvar o registro com a situação de “Resolvido” encerrando o caso, contudo, 
deverá, em um local específico do registro, definir como ele resolveu o caso, 
informando que se tratava de um Incidente[2], Problema[3] ou Solicitação[4]. O 
registro deve ser categorizado, escolhendo dentre três classificações: Categoria 
>>SubCategoria >> Item da categoria, onde a categoria é uma lista de tipo de 
serviço, como, por exemplo: Se foi Hardware ou Software. 
FONTE: Disponível em: <http://www.linhadecodigo.com.br/artigo/3219/orientacoes-basicas-na-
elaboracao-de-um-diagrama-de-classes.aspx>. Acesso em: nov. 2015.
A SubCategoria está relacionada com a categoria, pois dependendo 
do que foi escolhido na primeira lista, será mostrada na segunda que será 
uma SubCategoria, como, por exemplo: No caso da escolha de Hardware, seria 
informado na subcategoria algum tipo de peça do equipamento que o técnico 
interagiu, tipo DVD/R, no caso de Categoria ser Software a subcategoria deveria 
ser qual software, tipo: Word, Excel e etc... E no item da categoria deveria ser 
escolhido o que foi realizado pelo técnico, no caso de Hardware >> DVD/R, 
poderia ser SUBSTITUÍDO, LIMPADO... etc. No caso de Software >> Word >> 
INSTALADO, DESINSTALADO etc...
Caso o técnico do Service Desk não consiga resolver no seu prazo que 
será o mais curto, deverá enviar o registro para outro grupo de atendimento, 
onde existirão outros técnicos que poderão ir até o equipamento fisicamente 
para resolver o problema com um prazo mais extenso. Um grupo é composto 
por vários técnicos, no registro deve constar o grupo que atendeu e o técnico, 
pois cada registro conta como receita em reais para o grupo sendo apurado ao 
efetuar fechamento mensal. O pagamento para os grupos de atendimento é feito 
por quantidade de registros atendidos no prazo estipulado.
UNIDADE 2 | DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)
84
Se o mesmo grupo de atendimento físico tenta entrar em contato com o 
cliente, mas não obtiver sucesso, o técnico poderá deixar o registro agendado; para 
realizar esta tarefa devem ser informadas no registro a data e a hora em que será 
retornado o atendimento do chamado e definir a situação do registro para “Pendente 
pelo cliente”, definir também a data e hora para o próximo contato. Esta situação de 
pendência significa que o técnico não está atendendo por culpa do cliente e o tempo 
em que o registro fica nesta situação será debitado ao final da apuração, a fim de 
beneficiar o grupo que o atende, pois cada grupo tem um tempo para atender os 
registros, e se ultrapassar este prazo, recebe multa em cima do valor do chamado.
Ao final, caso o pedido tenha sido designado para outro grupo, ou esteja 
em andamento, pendente, cancelado ou resolvido, deve-se informar em um 
campo específico o que foi feito neste registro, resumidamente. Se a situação do 
registro estiver definida como “Resolvido”, uma pesquisa de satisfação deverá 
ser enviada para o solicitante.
FONTE: Disponível em: <http://www.linhadecodigo.com.br/artigo/3219/orientacoes-basicas-na-
elaboracao-de-um-diagrama-de-classes.aspx>. Acesso em: nov. 2015.
2.2 IDENTIFICAR OS OBJETOS TANGÍVEIS
Para identificar somente os objetos que interessam na situação detalhada 
acima, Tacla (2010) sugere que adotemos como regra o seguinte questionamento: 
“O objeto é algo tangível, que podemos percebê-lo à nossa frente, sendo possível 
encontrá-lo no mundo real ou virtual. Exemplos de objetos que podemos perceber 
ao ir a uma lanchonete: Mesa, Cadeira, Atendente, Lanche, Bebida e etc.”.
 
Analise frase a frase do cenário proposto, obedecendo à regra descrita acima. 
 Logo, você identificará os seguintes objetos:
Cliente
Telefone
Atendente
Solicitação
Grupo
Técnico
Equipamento
Histórico
Categoria
SubCategoria
Item da categoria
Pedido
Pesquisa de satisfação
Situações
Tipo de serviços
Prazos
TÓPICO 2 | DIAGRAMAS ESTRUTURAIS: DE CLASSES E DE PACOTES
85
Histórico não é algo tangível, porém, é algo que existe. Neste caso, 
podemos entender como o histórico de ocorrências envolvendo o cliente. 
2.3 AGRUPAR OS OBJETOS POR SEMELHANÇA
Todos os objetos encontrados devem ser agrupados quando houver 
semelhança. Exemplo:
Cliente, Atendente e Técnico = Pessoas
Solicitação, Histórico, Pedido e Pesquisa de Satisfação = Documentos
Telefone = Equipamentos
2.4 DELIMITAR CLASSES REDUNDANTES OU QUE NÃO SÃO 
NECESSÁRIAS
 Podemos observar que Pedido e Solicitação no cenário fazem referência a 
uma mesma coisa, assim, podemos então eliminar uma das duas. E Telefone é um 
item de equipamentos, podendo ser eliminado também.
Logo, a lista atualizada ficaria assim:
Pessoas
Cliente
Atendente
Grupo
Técnico
Equipamento
Histórico
Categoria
SubCategoria
Item da categoria
PedidoPesquisa de satisfação
Situações
Tipo de serviços
Prazos
2.5 MONTANDO O DIAGRAMA DE CLASSE
Veja, na figura a seguir, como deve ficar o esboço do Diagrama de Classe.
UNIDADE 2 | DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)
86
FIGURA 44 – REPRESENTAÇÃO DA MONTAGEM DO DIAGRAMA DE CLASSE
Itens_da_
Categoria
- coditem
- item
Sub_Categorias
- codCategoria
- subCategoria
Categorias
- codCategoria
- categoria
Grupos
- codGrupo
- codFuncionario
Tipos de Serviços
- codTipo
Clientes
- codPessoa
- numCliente
+ setCadastrar ( )
+ getConsultar ( )
Atendentes
- codPessoa
- numAtendente
Técnicos
- codPessoa
- numTecnico
Pessoas
- codPessoa
- Pessoa
Documentos
- codDoc
- documento
Pedidos
- codOrdem
- codDoc
- codCliente
- codFuncionario
- codGrupo
- codTipo
- codCategoria
- codsubCategoria
- codItem
FONTE: O autor
2.6 REALIZANDO AS PRIMEIRAS LIGAÇÕES
Para efetuarmos a primeira ligação, faremos com os objetos que agrupamos 
por características semelhantes, como, por exemplo: Clientes, Atendentes e 
Técnicos se relacionam com pessoas; Pedido se relaciona com Documentos. 
Verifique as ligações:
TÓPICO 2 | DIAGRAMAS ESTRUTURAIS: DE CLASSES E DE PACOTES
87
FIGURA 45 – LIGANDO AS CLASSES DE PESSOA
Atendentes
- codPessoa
- numAtendente
Pessoas
- codPessoa
- Pessoa
Técnicos
- codPessoa
- numTecnico
Clientes
- codPessoa
- numCliente
+ setCadastrar ( )
+ getConsultar ( )
FONTE: Tacla (2010)
Parte do Diagrama de Classe envolvendo Pedidos e Documentos: 
FIGURA 46 - LIGAÇÃO DE PEDIDOS E DOCUMENTOS
Pedidos
- codOrdem
- codDoc
- codCliente
- codFuncionario
- codGrupo
- codTipo
- codCategoria
- codsubCategoria
- codItem
Documentos
- codDoc
- documento
FONTE: Tacla (2010)
Para fazer as ligações, todas as classes devem ser testadas.
Sabemos que o cliente entra em contato com o atendente que gera um 
pedido. Com esta informação observamos que um pedido foi gerado da 
interação entre cliente e atendente, onde um cliente pode solicitar vários 
pedidos para um atendente e um atendente atende a vários clientes. 
Sua cardinalidade será N para N, onde N quer dizer muitos, sendo: 
Muitos para Muitos, quando ocorre esse tipo de cardinalidade nasce 
uma nova tabela ou classe, entre esses dois foi a classe pedidos, que já 
UNIDADE 2 | DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)
88
havíamos identificado antes. O importante sobre a N para N é que a 
classe que nasceu recebe os códigos da classe que o fez relação, ficando 
a classe “Pedido” com o código do cliente e o código da atendente. 
Sabemos também que esse pedido será repassado para um técnico que 
o atenderá, sendo assim, um técnico pode atender a vários pedidos e um 
pedido pode ser atendido por um técnico, sendo representado por 1-N, 
lembrando que a classe que recebe o N herda o campo-chave da outra 
classe como chave estrangeira, sendo assim ficará a tabela de pedidos 
com mais um campo, chamado: código do técnico. Faça o processo para 
todas as classes, use sempre a pergunta dessa forma:
Um “Nome de um objeto da classe” pode “nome da ligação (verbo)” 
um ou vários “nome da classe”
Como ficaria entre Pedidos e situação: Um pedido pode ter uma ou 
várias situações? Resposta: Várias, pois ao abrir está em andamento, 
em outro ponto do tempo pode ficar pendente e ser concluída ao final 
do serviço (TACLA, 2010, p. 76).
3 DIAGRAMA DE CLASSE COMPLETO
A figura a seguir mostra como ficaria o diagrama de classe completo, baseado 
na situação descrita nos itens anteriores.
TÓPICO 2 | DIAGRAMAS ESTRUTURAIS: DE CLASSES E DE PACOTES
89
FIGURA 47 – DIAGRAMA DE CLASSE COMPLETO
Equipamentos
- codEquipamento
Tipos de Serviços
- codTipo
Pedido_Situações
- codSituação
- codOrdem
- tempoNaSituação
Pedido_Equipamentos
- codPedido
- codEquipamento
Atendentes
- codPessoa
- numAtendente Grupos
- codGrupo
- codFuncionario
Categorias
- codCategoria
- categoria
Pedidos
- codOrdem
- codDoc
- codCliente
- codFuncionario
- codGrupo
- codTipo
- codCategoria
- codsubCategoria
- codItem
Sub_Categorias
- codCategoria
- subCategoria
Itens_da_Categoria
- codItem
- Item
Situações
- codSituação
- situação
Histórico_de_Atendimento
- codHistorico
- codDoc
Clientes
- codPessoa
- numCliente
+ set1Cadastrat ( )
+ getConsultar ( )
Pessoas
- codPessoa
- Pessoa
Tecnicos
- codPessoa
- numTecnico
FONTE: Piva (2010)
3.1 DIAGRAMA DE PACOTES
O termo Diagrama de Pacotes é utilizado para descrever um diagrama 
que mostra pacotes de classes e as dependências entre eles. Este diagrama 
oferece uma visão do sistema como um todo, sob tal perspectiva que se possa 
observar todos os subsistemas que o compõem. Tem como proposta apresentar 
a modelagem estrutural do sistema em divisões lógicas e suas interações em alto 
nível (SILVA, 2007).
UNIDADE 2 | DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)
90
• É uma construção de agrupamento que permite a você pegar qualquer 
construção na UML e agrupar seus elementos em unidades de nível alto. 
• Representa um grupo de classes (ou outros elementos) que se relaciona com 
outros pacotes através de uma relação de dependência.
Os pacotes também podem ser membros de outros pacotes, construindo 
uma estrutura hierárquica.
• Cada pacote representa um espaço de nomes, o que significa que toda classe 
deve ter um nome exclusivo dentro do pacote a que pertence. Se eu quiser 
criar uma classe Date e já existir uma classe Date dentro do pacote System, 
eu posso ter minha classe Date, desde que a coloque em um outro pacote. 
• É um mecanismo de agrupamento geral que serve para agrupar vários 
modelos. 
• Organiza elementos em grupo e costuma ser utilizado na modelagem de 
sistemas muito extensos.
• São utilizados para demonstrar os limites de cada subsistema e como eles se 
inter-relacionam.
• Pode conter qualquer diagrama da UML, inclusive outros pacotes. Mais 
comumente utilizado em Diagrama de Casos de Uso e Diagrama de Classes.
FONTE: Disponível em: <http://200.17.137.109:8081/novobsi/Members/giordano/aulas/2010.2/
modelagem-e-programacao-orientada-a-objetos/Diagrama%20de%20Pacotes.pptx.>. Acesso em: 
10 out. 2015.
FIGURA 47 – DIAGRAMA DE PACOTES
Sistema Seguradora Sistema Financeiro
FONTE: O autor
3.1.1 Definindo as classes de um Pacote
Para identificar as classes de um pacote, observe o seguinte:
• Classes que estejam na mesma árvore de herança.
• Classes que estejam em um mesmo jogo de agregação e composição.
• Classes que apareçam em um mesmo Diagrama de Sequência com muitas 
colaborações (alto acoplamento).
• Um pacote utilitário contém classes sem afinidade direta com o domínio do 
problema, porém necessárias.
TÓPICO 2 | DIAGRAMAS ESTRUTURAIS: DE CLASSES E DE PACOTES
91
FIGURA 48 – FORMAS DE REPRESENTAR DIAGRAMAS DE PACOTES
Date
java::util
Date
java
util
java::util::Date
util
util
Date
util
Date
Conteúdo listado
na caixa
Conteúdo diagramado
na caixa
Nome de pacote
totalmente qualificado
Nome de classe
totalmente qualificado
Pacotes aninhados
FONTE: O autor
É um diagrama estrutural que permite uma visão da organização interna 
da aplicação que está sendo projetada.
3.1.2 Principais componentes: pacotes
Verifique outro exemplo de Diagrama de Pacotes na figura a seguir. Um 
exemplo de pacote que organiza o projeto, pois separa as classes do projeto das 
interfaces do usuário.
UNIDADE 2 | DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)
92
FIGURA 49 – COMPONENTES DO DIAGRAMA DE PACOTES
Funcionario
AtendenteDono
Fornece
Caixa
Compra
Cliente Produto ItemFornece
ItemCompra
ItemCompra
GUI
Classes de Projeto
FManutençãoPagamentoCompra
FManutençãoCompra
Floguin
FManutençãoFornece
FONTE: Piva (2010)93
RESUMO DO TÓPICO 2
Neste tópico você aprendeu que:
• O Diagrama de Classes é possivelmente o diagrama mais utilizado e um dos 
mais importantes da UML. Serve de apoio para a maioria dos demais.
• É um diagrama que mostra um conjunto de classes, interfaces e colaborações 
e seus relacionamentos. O Diagrama de Classes é utilizado na construção do 
modelo de classes desde o nível de análise até o nível de especificação. 
• Um diagrama de classes ilustra as especificações para as classes de software e de 
interface de uma aplicação. Este diagrama mostra definições para entidades de 
software, e não conceitos do mundo real (LARMAN, 2007). 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 básicos do diagrama 
de classes (SILVA, 2007).
• O diagrama de classes é um dos principais diagramas da UML, representa a 
estrutura do sistema (elementos que foram selecionados para fazer parte do 
sistema). A partir dele, por exemplo, o esqueleto do código-fonte pode ser 
gerado automaticamente. 
• O comportamento requerido do sistema é alcançado pela colaboração entre 
objetos. O Diagrama de Classes fornece uma representação estática da 
colaboração por meio de relacionamentos. Os relacionamentos são utilizados 
no Diagrama de Classes que é refinado incrementalmente (modelo do domínio, 
análise e, posteriormente, no projeto).
• Em programação, um Diagrama de Classes é uma representação da estrutura 
e relações das classes que servem de modelo para objetos. Podemos afirmar, 
de maneira mais simples, que seria um conjunto de objetos com as mesmas 
características, assim saberemos identificar objetos e agrupá-los, de forma 
a encontrar suas respectivas classes. Na Unified Modeling Language (UML) 
em Diagrama de Classe, uma classe é representada por um retângulo com três 
divisões, são elas: O nome da classe, seus atributos e, por fim, os métodos. 
• Diagrama de Pacotes é uma construção de agrupamento que permite a você 
pegar qualquer construção na UML e agrupar seus elementos em unidades de 
nível alto. 
94
• Representa um grupo de classes (ou outros elementos) que se relaciona com 
outros pacotes através de uma relação de dependência.
• Os pacotes também podem ser membros de outros pacotes, construindo uma 
estrutura hierárquica.
o Cada pacote representa um espaço de nomes, o que significa que toda classe 
deve ter um nome exclusivo dentro do pacote a que pertence. Se eu quiser 
criar uma classe Date e já existir uma classe Date dentro do pacote System, eu 
posso ter minha classe Date, desde que a coloque em um outro pacote. 
o É um mecanismo de agrupamento geral que serve para agrupar vários 
modelos.
o Organiza elementos em grupo e costuma ser utilizado na modelagem de 
sistemas muito extensos.
o São utilizados para demonstrar os limites de cada subsistema e como eles se 
inter-relacionam.
o Pode conter qualquer diagrama da UML, inclusive outros pacotes. Mais 
comumente utilizado em Diagrama de Casos de Uso e Diagrama de Classes.
95
AUTOATIVIDADE
1 Em relação aos relacionamentos abaixo, responda:
a) Qual a representação mais correta – a primeira ou a segunda relação? Por 
quê?
Casa
Casa
Pessoa
Pessoa
é propriedade
0..*
0..*1..*
1
+propriedade +proprietário
class Casa
FONTE: Disponível em: <http://www.dainf.cefetpr.br/~tacla/UML/0070-DiagClasses-
ExerciciosSol.pdf>. Acesso em: nov. 2015. 
b) Qual a diferença de interpretação entre as duas representações? Qual seria a 
mais indicada para um tribunal eleitoral regional?
class eleições
Pessoa
eleitor 0..*
vota>
candidatoPresidente
0..1
Pessoa
eleitor 0..*
candidatoPresidente
0..1
FONTE: Disponível em: <http://www.dainf.cefetpr.br/~tacla/UML/0070-DiagClasses-
ExerciciosSol.pdf>. Acesso em: nov. 2015.
2 Represente um e-mail na forma de Diagrama de Classes. Identifique os 
componentes (destinatário, assunto etc...) e suas relações. 
3 Qual a diferença de interpretação entre os relacionamentos livro-sobrecapa 
e livro-páginas?
96
Livro Pagina Paragrafo
SobreCapa
0..1
1...* 1...*
4 Todo aluno matriculado em trabalho de diplomação será orientado por um 
professor. Alguns professores orientam vários alunos e outros, nenhum. 
Qual dos diagramas melhor representa esta relação?
Aluno
Aluno
Prof
Prof
Aluno Prof
Aluno Prof
1
11
10..*
0..*
orientador
orientadororientador
orientador
a) c)
d)b)
0..*
0..*
5 Construa a hierarquia de classes para os seguintes tipos de obras: romance, 
livro de ficção, livro de autoajuda, gibi, rock, filme ficção, comédia e MPB. 
6 Defina pacotes.
97
TÓPICO 3
DIAGRAMAS ESTRUTURAIS: DE OBJETOS E DE 
COMPONENTES
UNIDADE 2
1 INTRODUÇÃO
Este diagrama está amplamente associado ao Diagrama de Classes. 
Na verdade, o Diagrama de Objetos é praticamente um complemento do 
Diagrama de Classes, sendo bastante dependente deste. O Diagrama de Objetos 
fornece uma visão dos valores armazenados pelos objetos de um Diagrama de 
Classes em um determinado momento da execução de um processo. 
De acordo com Guedes (2011), o Diagrama de Objetos está amplamente 
associado ao Diagrama de Classes, podendo ser visto como uma instância de tal 
diagrama, assim como os objetos são instâncias de classes. Tal qual o Diagrama 
de Classes, o Diagrama de Objeto é formado por estruturas estáticas. Bezerra 
(2007) diz que um Diagrama de Objetos exibe uma fotografia do sistema em 
um determinado momento, exibindo ligações formadas entre objetos conforme 
interação entre eles e de acordo com valores de atributos.
Os Diagramas de Objetos abrangem a visão estática de projeto ou visão 
estática de processo de um sistema (BOOCH; RUMBAUGH; JACOBSON, 2005).
2 PRINCIPAIS COMPONENTES: OBJETOS, RELACIONAMENTOS 
Este diagrama nos dá uma visão de como ficarão os objetos em determinado 
momento da execução do sistema. É como se tirássemos uma fotografia do sistema 
em um momento para analisar os dados e os relacionamentos envolvidos.
98
UNIDADE 2 | DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)
FIGURA 50 – DIAGRAMA DE OBJETOS
fornec:Fornece
- dataEntrada:
 27/10/2009
- nroNF=123
- valorTotal=483.17
- lancadoPor=func
- dataLancamento=
 27/10/2009
- horaLancamento=11:35
- fornecedor=forn
fornec:Fornece
- codigo=46
- nome=Fulano de 
 Tal Ltda
- cnpj=12.345.678/
 0009-10
cart:Cartao
- nroCartao=123
- datainicioUso=
 23/12/208
- dataFimUso=null
prod:Produto
- codigo:|- d
- descricao=Leite: 
 Tipo A
- quantidadeEstoque
=38
- vllUnitarioVenda
= 2.65
- estoqueMinimo=
 30.00
- situacao=|
func:Funcionamento
- cpf=123.456.789-01
- nome=Olavo Petronio 
 Caz
- nroCarteiraProfissional
 = 12345
- dataAdmissão=
 13/05/1991
- dataDemissao=null
- senha=******
itl:llemFornece
- produto=prod
- quantidade=4.00
- valorUnitario=2.83
comp:Compra
- dataCompra=
 27/10/2009
- valorTotal=12.80
- terminada=true
- recebidoPor=func
itl:llemCompra
- qualidade=3.00
- data Registro=
 27/10/2009
- horaRegistro=12:05
- atendidoPor.func
- cliente=cart
FONTE: Piva (2010)
Observe a notação desse diagrama: o objeto possui a mesma estrutura 
de uma classe, porém seu nome vem antes do nome da classe. func: Funcionario 
quer dizer objeto func da classe funcionário.
Podemos assim analisar as relações entre os objetos em um determinado 
ponto da execução do sistema.
TÓPICO 3 | DIAGRAMAS ESTRUTURAIS: DE OBJETOS E DE COMPONENTES
99
3 DIAGRAMA DE COMPONENTES
Booch, Rumbaugh e Jacobson (2005) narram que um Diagrama 
de Componentes mostra a organização e as dependências entre os vários 
componentes de um sistema. Um componente representaum módulo físico 
do código. As dependências entre os componentes mostram como mudanças 
em um componente podem causar mudanças em outros componentes. Este 
diagrama fornece uma visão modelada entre os módulos do próprio código-
fonte, bibliotecas e formulários, arquivos de banco de dados e demais arquivos 
de sistema. Além de determinar como cada um desses elementos estará disposto 
na organização do sistema e como interagem entre si (GUEDES, 2011). Mostra a 
organização e as dependências existentes em um conjunto de componentes; os 
diagramas de componentes abrangem a visão estática de implementação de um 
sistema (BOOCH; RUMBAUGH; JACOBSON, 2005).
O Diagrama de Componentes é um diagrama estrutural que nos ajuda 
a analisar as partes do sistema que podem ser substituídas por outras que 
implementem as mesmas interfaces (de entrada e/ou de saída) sem alterar o seu 
funcionamento.
3.1 PRINCIPAIS COMPONENTES: COMPONENTES, 
INTERFACES, CLASSES E RELACIONAMENTOS
Todo componente, geralmente, pode ser substituído por uma classe, 
que implementa suas interfaces. Por isso é bastante difícil separar um do outro. 
Mas costumamos utilizar o Diagrama de Componentes quando precisamos 
documentar um componente que pode ser substituído no sistema.
Um claro exemplo de uso de componente e, consequentemente, do 
Diagrama de Componentes no estudo de caso da padaria do senhor João, é a 
representação da balança que pesa os produtos comercializados na padaria.
Como a balança vai interagir com os componentes do software, 
alimentando o sistema com informações sobre o produto vendido, como 
peso e valor, o senhor João poderá substituir a balança apenas por outra que 
possibilite as mesmas interfaces, tanto de entrada quanto de saída. 
FONTE: Disponível em: <http://dicasdeinformatica.xyz/diagramas-uml/>. Acesso em: nov. 2015. 
100
UNIDADE 2 | DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)
FIGURA 51 – COMPONENTES DO DIAGRAMA DE PACOTES
itemCompraBalançaProduto
Código do produto
e preço por quilo
Código do produto,
quantidade comparada
e preço por quilo.
BalançaProduto BalançaItemCompra
FONTE: Piva (2010)
Podemos aproveitar e defi nir as interfaces de entrada e saída da balança e 
deixá-las documentadas nesse diagrama.
3.1.1 Componente
É uma parte do sistema que é física e substituível e que está em 
conformidade com um conjunto de interfaces (fornecidas e/ou requeridas). Um 
componente é parte do sistema e é reutilizável. 
Os diagramas de componentes capturam a estrutura física da 
implementação.
3.1.2 Objetivos
• Organizar o código-fonte (ambiente de desenvolvimento).
• Construir um release executável (ambiente de produção).
• Especifi car componentes como base de dados etc. 
• Contém componentes, interfaces e relações entre componentes.
• Os pacotes de componentes podem ser utilizados para modelar a arquitetura 
física.
• Identifi car as principais peças do sistema. 
Um pedaço de software reutilizável, bem encapsulado e “facilmente” 
substituível. 
• São blocos (peças) que combinados constroem o sistema pretendido. 
• A dimensão dos componentes não é homogênea, existindo, num mesmo 
sistema, componentes de diferentes dimensões. 
• Quais são os bons candidatos a serem componentes do sistema? 
• Itens que desempenham uma funcionalidade que é utilizada recorrentemente 
no sistema. Exemplos: componentes de logging, parsers de XML, componentes 
de gestão de carrinhos de compra (shopping carts) etc. 
TÓPICO 3 | DIAGRAMAS ESTRUTURAIS: DE OBJETOS E DE COMPONENTES
101
• Em UML um componente pode efetuar as mesmas funcionalidades que uma 
classe faz: 
	 o Generalização 
	 o Associação com outros componentes ou classes
	 o Implementação de interfaces 
• Um componente representa um empacotamento físico de elementos 
relacionados logicamente (normalmente classes). 
FONTE: Disponível em: <http://slideplayer.com.br/slide/1584624/>. Acesso em: nov. 2015.
Os componentes existem no mundo material, de bits. São um elemento 
importante na modelagem dos aspectos físicos de um sistema. Um 
componente é uma parte física e substituível de um sistema, que 
realiza um conjunto de interfaces. Exemplos de componentes são 
código-fonte, executáveis, bibliotecas, tabelas, arquivos e documentos. 
Um componente, tipicamente, é uma versão física de elementos 
lógicos, como classes e interfaces. Disponível em:
<http://www.cin.ufpe.br/~eng_soft/eti901/NotasdeAulas/a8_1-
UMLImplementacao.pdf>. Acesso em: nov. 2015. 
Diagramas de componentes são usados para modelar os aspectos 
físicos de um sistema: o código-fonte de um aplicativo, uma API 
etc. Nos Diagramas de Componentes são mostrados componentes e 
os relacionamentos entre eles. Dependências entre componentes são 
mostradas. A única restrição é que o que está sendo modelado deve 
ser físico (formado por bits) e não conceitual (ou lógico). Disponível 
em: <http://slideplayer.com.br/slide/3691521/>. Acesso em: nov. 2015.
Na UML 2 
• Uma parte modular de um sistema que encapsula seu conteúdo e cuja 
manifestação seja substituível dentro de seu ambiente.
• Um componente define seu comportamento em termos de interfaces fornecidas 
e requeridas. 
3.1.3 Diagrama de Componentes
• Especificação de um conjunto de componentes e suas interdependências.
• Representam de forma estática aspectos físicos do sistema que está sendo 
modelado.
• São importantes para visualizar, especificar e documentar sistemas baseados 
em componentes.
• Eles mostram um conjunto de componentes e seus relacionamentos.
• São tipicamente usados para: 
102
UNIDADE 2 | DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)
o Modelar a organização do código-fonte.
o Modelar lançamento de executáveis (release).
o Modelar fisicamente um banco de dados.
o Modelar sistemas adaptativos. 
o Modelar a organização do código-fonte.
• Na implementação das classes definidas durante a modelagem, o código 
gerado será armazenado fisicamente em arquivos, o Diagrama de 
Componentes serve como forma de gerenciamento destes arquivos. 
o Modelar lançamento de executáveis (releases).
• Uma versão de um sistema envolve combinações específicas de diversas 
partes. O Diagrama de Componentes pode modelar os diversos componentes 
necessários para uma determinada versão do sistema. 
o Modelar fisicamente um banco de dados.
• Considerando-se que as informações do sistema serão armazenadas em 
arquivos ou tabelas de um banco de dados, um Diagrama de Componentes 
pode mostrar os arquivos (ou tabelas) do banco de dados e seus 
relacionamentos. 
o Modelar sistemas adaptativos.
• A execução de alguns sistemas baseia-se no uso de componentes dinâmicos 
(carga dinâmica, agentes móveis etc.), que podem ser descritos através de um 
Diagrama de Componentes conjuntamente com outros diagramas da UML. 
• O principal elemento sintático deste diagrama é o componente.
• O principal objetivo deste diagrama, segundo Scott Ambler, é possibilitar a 
construção de artefatos para o perfil de arquitetura da solução, seja para a 
arquitetura técnica ou a de negócios.
FONTE: Disponível em: <https://www.google.com.br/url?sa=t&rct=j&q=&esrc=s&source=web&c
d=1&cad=rja&uact=8&ved=0ahUKEwiVn9CI2J_JAhVGPZAKHSE2AwUQFggeMAA&url=http%3
A%2F%2F200.17.137.109%3A8081%2Fnovobsi%2FMembers%2Fgiordano%2Faulas%2F2010.2%2F
modelagem-e-programacao-orientada-a-objetos%2FDiagrama%2520de%2520Componentes.
pptx&usg=AFQjCNHjrdTLZ5fjTY_uQhdE5xZC1z0nIA>. Acesso em: nov. 2015. 
TÓPICO 3 | DIAGRAMAS ESTRUTURAIS: DE OBJETOS E DE COMPONENTES
103
LEITURA COMPLEMENTAR
Uma reflexão sobre Banco de Dados Orientados a Objetos
Clodis Boscarioli
Anderson Bezerra
Marcos de Benedicto
Gilliard Delmiro
Até meados dos anos 60, os dados eram mantidos aleatoriamente em 
arquivos, geralmente como partes integrantes da aplicação. A partir dessa época, 
surgiram os primeiros SistemasGerenciadores de Bancos de Dados (SGBDs) 
comerciais, provendo armazenamento dos dados de forma independente da 
aplicação, contudo, sem mecanismos de acesso eficientes. 
Codd (1970) propôs a criação de linguagens de alto nível, permitindo 
manipulação eficiente. A partir dos anos 80 as aplicações computacionais 
evoluíram, juntamente com o poder de processamento das máquinas, surgindo 
a necessidade de tratar dados mais complexos, não convencionais. Devido a 
esse aumento na complexidade dos dados, surgiu a necessidade de formas 
mais adequadas de representação e armazenamento, como as bases de dados 
orientadas a objetos. 
Durante a década de 80, como resultado das inovações de hardware, 
emergiram novas aplicações com utilização intensiva de dados. Para essas 
aplicações, os modelos de dados tradicionais, baseados no modelo relacional, não 
eram adequados. Alguns exemplos de aplicações desse tipo incluem sistemas de 
design e produção, como CAD (Computer-Aided Design) e CAM (Computer-
Aided Manufacturing), sistemas para as áreas científica e médica, sistemas de 
informação geográfica e bases de dados com informações multimídia. Essas 
aplicações possuem requisitos e características, tais como dados altamente 
estruturados, transações longas, dados em multimídia e operações fora do padrão, 
específicas da aplicação, que as tornam diferentes das aplicações tradicionais 
(CHAUDRI & ZICARI, 2001, p. 3). 
Silberchatz et al. (2001, p. 307) afirmam que: 
À medida que as bases de dados foram sendo utilizadas em um âmbito 
maior de aplicações, as limitações impostas pelo modelo relacional 
emergiram como obstáculos. Como resultado, pesquisadores da 
área de bancos de dados inventaram novos modelos de dados que 
superassem as restrições do modelo relacional. [...] Nos últimos anos a 
demanda por maneiras de tratar dados mais complexos tem crescido.
 
Existe um grande interesse relativo às tecnologias orientadas a objetos na 
comunidade de desenvolvimento de software, sobretudo no tocante à facilidade de 
alteração de implementações de acordo com mudanças solicitadas nos requisitos. 
104
UNIDADE 2 | DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)
A capacidade que esse paradigma possui de representar dados complexos uniu-
se à tecnologia de banco de dados, gerando os Bancos de Dados Orientados a 
Objeto (BDOO), que suportam modelagem e criação de dados como objetos 
(ODBMS, 2006). O objetivo desse artigo é prover uma visão geral sobre sistema 
de BDOO, uma tecnologia não tão nova (BANCIIHON, 1988; ATKINSON, et al., 
1989), contudo considerada ainda pouco explorada. Para tal, está organizado 
como segue: Conceitos básicos sobre Banco de Dados Relacionais (BDR) e BDOO 
são abordados na Seção 2. A Seção 3 diz respeito à modelagem no paradigma 
orientado a objetos, mostrando como um mesmo modelo pode ser usado em 
ambas as camadas, de banco de dados e da aplicação. 
2 Bancos de Dados Relacionais versus Bancos de Dados Orientados a Objetos 
BDRs e BDOOs possuem características distintas, mas basicamente 
servem ao mesmo propósito: persistir dados necessários para a manutenção do 
negócio para o qual são aplicados, possibilitando a recuperação, comparação e 
tratamento desses dados a fim de produzir resultados tangíveis. Em BDR, uma 
coleção de tabelas, todas com nomes únicos, compõe a base de dados, podendo 
estar relacionada a uma ou mais tabelas. Conceitos como integridade referencial 
de dados – que garantem que um dado referenciado em uma tabela esteja presente 
na tabela que está sendo referenciada – e chaves primárias estão presentes e 
garantem que um conjunto de informações possa ser representado de maneira 
consistente, independente da forma de acesso. 
Já um BDOO possui três pilares principais: herança, polimorfismo e 
encapsulamento, discutidos a seguir. Este modelo apresenta maior flexibilidade na 
manipulação de seu conteúdo e, por meio de identificadores de objetos, manipula os 
dados de forma consistente. Silbeschatz et al. (2001) concluem que as bases de dados 
tradicionais são bastante eficientes para tarefas ligadas ao processamento de dados. A 
geração de folhas de pagamento e o gerenciamento de contas correntes são exemplos. 
Esse tipo de aplicação trabalha basicamente com tipos de dados simples: numéricos, 
texto e datas. Além disso, essas aplicações possuem itens de dados que podem ser 
representados como registros razoavelmente pequenos e campos atômicos. 
Apesar do conceito de bancos de dados orientados a objetos ser bastante 
distinto do modelo relacional, o mesmo resulta da integração entre a orientação a 
objetos e a tecnologia de banco de dados tradicionais. Enquanto na programação 
orientada a objetos, os objetos existem apenas enquanto o programa que os criou 
está em execução, os bancos de dados orientados a objetos podem criar objetos 
que sejam persistentes e compartilhados entre diferentes aplicativos.
[...]
4 Principais SGBDOOs no Mercado Atual 
Os sistemas gerenciadores de bancos de dados orientados a objetos não 
possuem grandes discrepâncias em termos de funcionalidades exigidas quando 
relacionados aos SGBDs relacionais. Entretanto, torna-se necessário levantar 
105
alguns pontos de diferenciação. Uma das principais exigências de um SGBDOO é 
o armazenamento de objetos e suas operações de forma a prover uma integração 
transparente com a aplicação, sem a necessidade de uma camada de tradução dos 
dados. A Tabela 1 traz uma comparação entre três grandes SGBDOOs disponíveis 
no mercado, o Objectivity/DB, o GemStone e o Jasmine, evidenciando que suas 
funcionalidades não diferem muito com relação aos aspectos mais importantes 
dos SGBDOOs.
Para Chaudri & Zicari (2001), a oferta de SGBDOOs tem aumentado, 
principalmente, como consequência do crescimento da utilização da plataforma 
Java. O mesmo afirmam Dan Lo et al. (2002). Segundo estes autores, o impacto 
desta linguagem de programação no mundo dos SGBDOOs tem sido considerável 
e diversos SGBDOOS realizaram modificações para oferecer suporte nativo 
para o armazenamento de objetos Java. Ferramentas como POET e ObjectStore, 
inicialmente desenvolvidas para persistência de objetos C++, disponibilizaram 
versões com capacidade de persistir objetos Java. Como resultado do aumento 
da popularidade do desenvolvimento de sistema em Java, a segunda versão 
do padrão ODMG adicionou elementos de ligação Java. Isto também refletiu 
em algumas mudanças no modelo de objetos, como a noção de interface e a 
introdução de dois tipos diferentes de hierarquias.
Principais SGBDOOOs do mercado
Nome
Open 
Source
Sistema 
Operacional
Fabricante Site Oficial
EntrepriseDB SIM
Linux, MacOs, 
Solaris e 
Windows
EnterpriseDB http://www.enterprisedb.com/
Objectivity/DB NÂO
Linux, 
Windows e 
Unix Posix
Objectivity 
Database 
Systems
http://www.objectivity.com
GemStone NÂO
WIndows, 
UNIX e Linux
GemStone 
System Inc.
http://www.gemsotne.com
ConteXT NÃO
WIndows e 
UNIX
Unixspace http://www.contextsoft.com/
Versant NÃO
Windows, 
Linux e UNIX
Versant Corp. http://www.versant.com
Caché NÃO
Windows, 
Linux e UNIX
Intersystems 
Software
http://www.intersystems.com.br
EyeDB SIM Linux e UNIX
Sysra 
Informatique
http://www.eyedb.org/
Jasmine NÃO
Windows, 
Linux e UNIX
Computer 
Associates
http://www.3.ca.com/
ORION SIM Linux e UNIX
Orion Group 
(Purdue 
University)
http://orion.cs.purdue.edu/
ObjectStore NÃO
Windows, 
Linux e UNIX
Progress 
Software
http://www.objectstore.com
106
5 Tendências 
Algumas tendências referentes à orientação a objetos aplicada a bancos 
de dados estão sendo discutidas há certo tempo, sem terem amadurecido muito 
nesse período. Existe hoje a possibilidade de avaliar quais tendências serão de 
fato concretizadas, levando em consideração o histórico da tecnologia? Entreas 
tendências emergentes neste contexto está o armazenamento em memória. Um 
exemplo de armazenamento em memória é o Prevayler (2006). 
Produzido independentemente por um grupo de brasileiros, essa 
ferramenta consiste em um repositório de objetos com desempenho de acesso 
bastante superior aos bancos de dados tradicionais, principalmente pela 
característica de manter os objetos em memória no servidor de aplicações. Essa 
tecnologia ainda tem limitações, principalmente ligadas à recuperação dos dados 
em caso de falha e aumento da necessidade de memória. Existem, e bem aceitos 
no mercado atual, os sistemas de banco de dados objeto-relacionais. Estes podem 
ser vistos como uma tentativa de estender sistemas de banco de dados relacionais 
com funcionalidades dos bancos de dados orientados a objetos, necessárias para 
dar suporte a uma classe mais ampla de aplicações e, de certa forma, prover uma 
ligação entre esses paradigmas. 
Além dos sistemas gerenciadores de banco de dados objeto-relacionais, 
como Oracle (2006) e PostgreSQL (2006), já bastante difundidos no mercado, outra 
tendência são as interfaces objeto-relacionais que consistem em uma abstração 
do modelo relacional para uma camada que provê interface de banco de dados 
orientado a objetos para uma aplicação e pode ser exemplificada por ferramentas 
como o Hibernate (2006). Essa tecnologia permite que as aplicações persistam os 
dados de forma transparente em quaisquer tipos de bancos, inclusive arquivos-
texto, cuidando de toda a complexidade inerente à tarefa. 
Para a aplicação é como se existisse um banco de dados orientado a objeto 
servindo de repositório. As novas arquiteturas orientadas a serviço, como a 
SOA (Service Oriented Architecture) (GUPTA, 2005; COHEN, 2006), também estão 
forçando os desenvolvedores a produzirem sistemas com um aproveitamento 
cada vez maior de componentes e, consequentemente, com menor acoplamento. 
Por esse motivo, as bases de dados relacionais, onde até o momento os dados são 
persistidos, deixam de atender a esse tipo de requerimento, tornando as bases de 
dados orientadas a objetos uma escolha mais interessante para uma escala ainda 
maior de aplicações. 
Com isso, a possibilidade do surgimento de novas tecnologias ligadas 
ao paradigma da orientação a objeto, que tenham como missão auxiliar na 
persistência dos dados de cada um dos objetos, tende a crescer nos próximos 
anos.
107
RESUMO DO TÓPICO 3
Neste tópico você aprendeu que:
• O Diagrama de Objetos está amplamente associado ao Diagrama de Classes. Na 
verdade, o Diagrama de Objetos é praticamente um complemento do Diagrama 
de Classes, sendo bastante dependente deste.
• Os Diagramas de Objetos abrangem a visão estática de projeto ou visão estática 
de processo de um sistema.
• Este diagrama nos dá uma visão de como ficarão os objetos em determinado 
momento da execução do sistema.
	 o Principais componentes: objetos, relacionamentos.
• O Diagrama de Componentes é um diagrama estrutural que nos ajuda a analisar 
as partes do sistema que podem ser substituídas por outras que implementem as 
mesmas interfaces (de entrada e/ou de saída) sem alterar o seu funcionamento.
	 o Principais componentes: componentes, interfaces, classes e relacionamentos.
	 o Objetivos:
	 o Organizar o código-fonte (ambiente de desenvolvimento).
	 o Construir um release executável (ambiente de produção).
	 o Especificar componentes como base de dados etc. 
	 o Contém componentes, interfaces e relações entre componentes.
	 o Os pacotes de componentes podem ser utilizados para modelar a arquitetura 
 física.
	 o Identificar as principais peças do sistema.
108
1 Defina Componente.
2 Quais as vantagens/motivações para a construção de modelos de 
componentes?
3 Defina Diagrama de Objetos. 
AUTOATIVIDADE
109
UNIDADE 3
DIAGRAMAS ESTRUTURAIS
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
Ao final desta unidade você será capaz de:
• conhecer os diagramas estruturais de implantação e estrutura composta;
• ter uma visão da integração dos diagramas;
• conhecer as principais ferramentas UML.
Esta unidade de ensino contém três tópicos e no final de cada um deles você 
encontrará atividades que contribuirão para a apropriação dos conteúdos.
TÓPICO 1 – DIAGRAMAS DE IMPANTAÇÃO E ESTRUTURA COMPOSTA
TÓPICO 2 – INTEGRAÇÃO DOS DIAGRAMAS – UMA VISÃO GERAL DO 
DESENVOLVIMENTO USANDO UML
TÓPICO 3 - ESTUDO DE CASO
110
111
TÓPICO 1
DIAGRAMA DE IMPLANTAÇÃO E ESTRUTURA COMPOSTA
UNIDADE 3
1 INTRODUÇÃO
Os Diagramas de Implantação mostram a topologia do sistema em 
tempo de execução, representando a configuração e a arquitetura do mesmo 
em relação aos seus componentes (BOOCH; RUMBAUGH; JACOBSON, 2006). 
Ainda, na percepção dos autores, este tipo de diagrama modela a visão estática 
da implantação do sistema, expressando o conjunto de hardware e demais 
tecnologias físicas relacionadas com sua instalação. Também podem ser usados 
para especificar os módulos do sistema que deverão ser instalados no cliente.
Estes diagramas são compostos por nós e associações, mais conhecidos 
como relacionamentos de comunicação. Os nós podem ser reconhecidos como 
sendo um computador, uma rede, um HD. Diagramas de Implantação são mais 
utilizados por equipes de desenvolvimento, integração e testes. Também são 
usados para mapear os programas que são executados em cada computador.
FIGURA 52 – EXEMPLO DE DIAGRAMA DE IMPLANTAÇÃO
FONTE: Disponível em: <http://www.cin.ufpe.br/~eng_soft/eti901/NotasdeAulas/a8_1-
UMLImplementacao.pdf:>. Acesso em: 20 out. 2015.
UNIDADE 3 | DIAGRAMAS ESTRUTURAIS
112
FIGURA 53 – EXEMPLO DE DIAGRAMA DE IMPLANTAÇÃO
FONTE: Disponível em: <http://www.cin.ufpe.br/~eng_soft/eti901/NotasdeAulas/a8_1-
UMLImplementacao.pdf:> Acesso em: 20 out. 2015.
2 PRINCIPAIS COMPONENTES
Os nós podem representar dispositivos computacionais, como um 
computador ou um celular, ou um recurso de computação, como um sistema 
operacional, quaisquer outros softwares que integrem a estrutura da aplicação. 
Possuem um nome e podem receber um estereótipo. Um nó é representado por 
um cubo. Os nós executam os artefatos.
Uma associação entre dois nós representa uma conexão física entre os nós, 
como uma conexão Ethernet, uma linha serial ou um link de satélite.
Artefatos são os elementos executados pelos nós, geralmente os 
programas da solução criada possuem um nome e podem possuir um estereótipo. 
Os relacionamentos são utilizados para representar o tipo de ligação entre os 
componentes do diagrama. Podem possuir estereótipos.
Veja que, na figura a seguir, demonstramos em detalhes a arquitetura da 
solução proposta.
TÓPICO 1 | DIAGRAMA DE IMPLANTAÇÃO E ESTRUTURA COMPOSTA
113
FIGURA 54 – EXEMPLO DE DIAGRAMA DE IMPLANTAÇÃO
<<sevidor>>
servidor web
<<banco operacional>>
:Linux
<<banco de aplicação>>
:Apache
<<web container>>
:Tomcat
<<artefato>>
:vendeTudo.war
<<navegador web>>
:Internet Explorer
Computador Cliente
<<servidor>>
Servidor de Banco de Dados
<<sistema operacional>>
:windows server
<<banco de dados>>
:SQLServer
<<artefato>>
:vendeTudoBD
<<10-T Ethernet>>
<<HTTP>>
FONTE: Piva (2010)
3 DIAGRAMA DE ESTRUTURA COMPOSTA
O Diagrama de Estrutura Composta é utilizado para modelar 
colaborações. Uma colaboração descreve uma visão de um conjunto de entidades 
cooperativas interpretadas por instâncias que cooperam entre si para executar 
uma função específica.
O termo estrutura se refere à composição dos elementos estruturais 
interconectados de forma a atingir algum objetivo comum. O exemplo 
acima mostra como as instâncias das classes autor, submissão, tema e tipo 
colaboram entre si para submeter à submissão. As colaborações podem 
também possuir multiplicidade, se as regras seguidas pelas classes utilizaremmúltiplas instâncias. Este é um diagrama que não é muito utilizado na UML e 
provavelmente é mais um diagrama teórico do que um diagrama utilizado nos 
processos de desenvolvimento.
FONTE: Disponível em: <http://www.novatec.com.br>. Acesso em: 5 nov. 2015.
UNIDADE 3 | DIAGRAMAS ESTRUTURAIS
114
Nos modelos UML, um Diagrama de Estrutura Composta mostra a 
estrutura interna dos classificadores estruturados utilizando peças, portas 
e conectores. Um classificador estruturado define a implementação de 
um classificador e pode incluir uma classe, um componente ou um nó de 
implementação. Você pode utilizar o Diagrama de Estrutura Composta para 
mostrar os detalhes internos de um classificador e descrever os objetos e funções 
que trabalham juntos para executar o comportamento do classificador contido.
FONTE: Disponível em: <http://www.novatec.com.br>. Acesso em: 5 nov. 2015.
Um Diagrama de Estrutura Composta é similar a um Diagrama de 
Classes, mas ele representa peças individuais em vez de classes inteiras. Antes 
de definir a estrutura interna de um classificador, você deve mostrar seu 
compartimento de estrutura ou abrir um Diagrama de Estrutura Composta. 
Então, você pode modelar as peças que representam as instâncias que o 
classificador contido possui. Você pode incluir conectores para vincular duas 
ou mais peças em um relacionamento de associação ou dependência.
Em Diagramas de Estrutura Composta, as portas definem o ponto de 
interação entre um classificador e seu ambiente ou entre um classificador e 
suas peças internas. Você pode utilizar uma porta para especificar os serviços 
que um classificador fornece e requer de seu ambiente.
Você também pode modelar colaborações e usos de colaborações em 
Diagramas de Estrutura Composta. Uma colaboração descreve as funções e os 
atributos que definem um comportamento específico do classificador. Um uso 
de colaboração representa um uso específico da colaboração para explicar os 
relacionamentos entre as propriedades de um classificador. Para identificar as 
funções das peças no uso de colaboração, você anexa um uso de colaboração a 
uma colaboração e, em seguida, inclui o uso de colaboração em um diagrama 
de estrutura composta.
FONTE: Disponível em: <http://www-01.ibm.com/support/knowledgecenter/SS5JSH_9.1.1/com.
ibm.xtools.modeler.doc/topics/ccompstruc.html?lang=pt-br>. Acesso em: nov. 2015.
Os seguintes tópicos descrevem elementos de modelo em Diagramas de 
Estrutura Composta:
Peças
Em Diagramas de Estrutura Composta, uma peça é um elemento de 
diagrama que representa um conjunto de uma ou mais instâncias que um 
classificador estruturado contido possui. Uma peça descreve a função de uma 
instância em um classificador. Você pode criar peças no compartimento de 
estrutura de um classificador e em vários diagramas UML, como estrutura 
composta, classe, objeto, componente, implementação e Diagramas de Pacote.
TÓPICO 1 | DIAGRAMA DE IMPLANTAÇÃO E ESTRUTURA COMPOSTA
115
Portas
Em Diagramas de Estrutura Composta, uma porta define o ponto 
de interação entre uma instância do classificador e seu ambiente ou entre o 
comportamento do classificador e suas peças internas.
Colaborações
Nos diagramas UML, uma colaboração é um tipo de classificador 
estruturado no qual as funções e atributos cooperam para definir a estrutura 
interna de um classificador. Você utiliza uma colaboração quando deseja 
definir apenas as funções e conexões que são requeridas para executar um 
objetivo específico da colaboração. Por exemplo, o objetivo de uma colaboração 
pode definir as funções ou os componentes de um classificador. Ao isolar 
as funções principais, uma colaboração simplifica a estrutura e esclarece o 
comportamento em um modelo.
Usos de Colaboração
Nos Diagramas de Estrutura Composta, um uso de colaboração é um 
elemento de modelo que representa um uso de uma colaboração para explicar 
os relacionamentos entre as partes de um classificador estruturado. Você 
utiliza um uso de colaboração para aplicar um padrão, que é descrito por uma 
colaboração, para uma situação específica que envolve classes ou instâncias 
que desempenham as funções de colaboração especificadas. Você pode ter 
vários usos de colaboração, cada um envolvendo um conjunto diferente de 
funções e conectores para uma colaboração determinada.
Conectores em Classificadores Estruturados
Em diagramas UML, um conector é uma linha que representa um 
relacionamento em um modelo. Ao modelar a estrutura interna de um 
classificador, você pode utilizar um conector para indicar um link entre duas 
ou mais instâncias de uma peça ou porta. O conector define o relacionamento 
entre os objetos ou instâncias que são ligados a funções no mesmo classificador 
estruturado e identifica a comunicação entre essas funções. O produto 
especifica automaticamente o tipo de conector a ser criado
FONTE: Disponível em: <http://www-01.ibm.com/support/knowledgecenter/SS5JSH_9.1.1/com.
ibm.xtools.modeler.doc/topics/ccompstruc.html?> Acesso em: 21out. 2015.
UNIDADE 3 | DIAGRAMAS ESTRUTURAIS
116
FIGURA 55 – EXEMPLO DE DIAGRAMA DE ESTRUTURA COMPOSTA 
controles:
ApresentadordeTV
:Gerador [1]
multiplicidade
conector de delegação
IU do controle da TV
API do controle da TV
Visualizador
de TV
tela
fluxo de imagenssintonia
parte
conector
1
FONTE: Disponível em: <http://regissimao.com.br/wp-content/uploads/2014/03/
UML-08-Diagrama-de-Estruturas-Compostas.pdf>. Acesso em: 23 out. 2015.
117
Neste tópico você aprendeu que:
• O Diagrama de Implantação representa a configuração e a arquitetura do 
sistema em que estarão ligados os respectivos componentes. Booch, Rumbaugh 
e Jacobson (2006) dizem que este diagrama exibe a configuração dos nós de 
processamento em tempo de execução e os componentes que nele existem.
• Neste diagrama também pode ser representada toda a estrutura de hardware 
e requisitos mínimos onde o sistema será executado. Este diagrama modela a 
visão estática da implantação de um sistema. Dado um determinado sistema 
de software, o Diagrama de Implantação vai expressar o conjunto de hardware e 
toda a tecnologia física relacionada com a instalação do sistema. Os Diagramas 
de Implantação também podem ser usados para especificar os módulos do 
sistema que deverão ser instalados no cliente.
• São usados para modelar a topologia do ambiente no qual o software será 
executado.
• São compostos por nós e associações (relacionamentos de comunicação).
• Um nó pode ser, por exemplo, um computador, uma rede, um disco rígido, 
um sensor etc. Usado para as equipes de: desenvolvimento, integração e testes. 
Também mapeiam como os componentes são distribuídos na arquitetura física.
• O Diagrama de Estrutura Composta é utilizado para modelar colaborações. 
Uma colaboração descreve uma visão de um conjunto de entidades cooperativas 
interpretadas por instâncias que cooperam entre si para executar uma função 
específica.
• O termo estrutura se refere à composição dos elementos estruturais 
interconectados de forma a atingir algum objetivo comum. O exemplo 
acima mostra como as instâncias das classes autor, submissão, tema e tipo 
colaboram entre si para submeter à submissão. As colaborações podem 
também possuir multiplicidade, se as regras seguidas pelas classes utilizarem 
múltiplas instâncias. Este é um diagrama que não é muito utilizado na UML e 
provavelmente é mais um diagrama teórico do que um diagrama utilizado nos 
processos de desenvolvimento.
RESUMO DO TÓPICO 1
118
1 É empregado para a modelagem dos aspectos físicos de um sistema OO. 
Mostra a configuração dos nós de processamento em tempo de execução e 
os artefatos que nele existem. Trata-se do diagrama de:
a) Comunicação
b) Componentes
c) Implantação
d) Estrutura Composta
FONTE: Disponível em: <https://www.qconcursos.com/questoes-de-concursos/questao/22be5843-46>. Acesso em: nov. 2015.
2 Considere C = comportamental e E = estrutural. Os diagramas de componentes, 
objetos, comunicação e estrutura composta são, respectivamente, 
categorizados como:
a) C; C; E; C
b) C; C; E; E
c) E; E; C; E
d) E; E; C; C. 
FONTE: Disponível em: <https://www.qconcursos.com/questoes-de-concursos/questao/22b
e5843-46>. Acesso em: nov. 2015.
AUTOATIVIDADE
119
TÓPICO 2
INTEGRAÇÃO DOS DIAGRAMAS – UMA VISÃO GERAL DO 
DESENVOLVIMENTO USANDO UML
UNIDADE 3
1 INTRODUÇÃO
Neste tópico, será apresentada uma situação real tendo como cenário uma 
padaria. Com isso, será possível visualizar de forma bem clara a interação de 
vários diagramas e a sequência de criação dos mesmos. 
2 EXEMPLO DE DESENVOLVIMENTO DE PROJETOS USANDO 
UML
Geralmente, desenvolvemos os diagramas de casos de uso para 
agrupar as funcionalidades mais importantes a serem implementadas. Sobre 
tais funcionalidades criamos o Diagrama de Classes, que será a estrutura de 
nossa aplicação ou o que chamamos de classes de projeto. No caso de uma 
padaria, por exemplo, as classes de projeto são as classes de cliente, produto, 
funcionário, compra, fornece e suas classes filhas.
Definimos seus principais atributos e então fazemos o Diagrama de 
Sequência para os casos de uso mais relevantes – no exemplo da padaria, os 
casos de uso registrar compra, pagar compra, receber mercadoria. Usamos 
esse diagrama para definir os principais métodos de nossas classes e as trocas 
de mensagens entre elas. Com isso definido, voltamos ao Diagrama de Classes 
e o complementamos com os métodos definidos nos Diagramas de Sequência. 
Começamos então a nos preocupar com a interface e com o usuário 
e escolhemos quais formulários serão necessários para o funcionamento 
de nossa aplicação. Com as classes definidas, começamos a separá-las para 
melhor organizar a aplicação.
Utilizamos para isso o padrão MVC. Esse padrão, muito utilizado 
pelos desenvolvedores orientados a objeto, foi criado com a linguagem de 
programação Smalltalk80. Consiste basicamente em dividir as classes da 
aplicação em três grupos, que chamamos de model, view e controller. Criamos 
um pacote para cada um desses itens. No model, em geral, inserimos as classes 
de projeto, seguindo o modelo de nossa aplicação. 
120
UNIDADE 3 | DIAGRAMAS ESTRUTURAIS
No view criamos as classes de interface com o usuário (telas) e no 
controller inserimos as classes que implementarão as funcionalidades de cada 
classe, desde uma simples consistência até o acesso ao banco de dados. Essas 
classes que implementam o acesso ao banco de dados levam o nome de classes 
de persistência, muitos desenvolvedores as colocam em outro pacote.
Dentro do view voltamos a separar as classes em pacotes para 
implementar a modulação do sistema, criando pacotes para cadastro, 
movimentação, consultas, relatórios e demais rotinas da execução do sistema, 
às quais chamamos de ferramentas. Com isso organizamos internamente as 
classes nos mesmos padrões utilizados na aplicação.
Terminada a separação das classes, criamos os diagramas de atividade 
para os casos de uso cujo procedimento e funcionamento pretendemos deixar 
documentados.
Verificamos então se é necessário documentar as interfaces de algum 
componente de software e elaboramos diagramas de componentes para isso. 
Se houver classes que mudam de estado no decorrer da execução do sistema, 
desenvolvemos o Diagrama de Máquinas de Estados para demonstrar qual a 
ideia da mudança de estado para cada uma delas.
Por fim, se o ambiente de implantação for um ambiente heterogêneo, 
isto é, que envolve arquitetura com vários servidores, como servidor de 
banco de dados e servidor de aplicações, entre outros, criamos o Diagrama 
de Implantação para demonstrar a arquitetura de software e hardware onde a 
aplicação deverá ser instalada.
Veja que nessa forma de desenvolvimento utilizamos os diagramas de 
casos de uso, os de classes, os de sequência, os de pacotes, os de atividades, 
os de máquina de estados, os de componentes e o de implantação. Tudo 
depende do tamanho da aplicação a ser desenvolvida e das dificuldades que 
encontramos nas fases de análise e projeto de software.
É comum também surgirem alterações nos modelos na fase de 
programação do software. Nesse caso, voltamos ao modelo e incluímos as 
alterações que fizemos na fase de programação e testes. Mesmo depois de 
implantada a solução, sempre que for necessário fazer alguma alteração no 
sistema, devemos voltar ao modelo e fazer a inclusão, para que o modelo 
nunca fique diferente do sistema criado.
FONTE: Piva (2010, p. 164)
TÓPICO 2 | INTEGRAÇÃO DOS DIAGRAMAS – UMA VISÃO GERAL DO DESENVOLVIMENTO USANDO UML
121
Verifique a situação no Diagrama de Visão Geral, proposto abaixo.
FIGURA 56 – DIAGRAMA DE VISÃO GERAL
122
UNIDADE 3 | DIAGRAMAS ESTRUTURAIS
FONTE: Piva (2010)
123
Neste tópico você:
• Visualizou a interação entre todos os diagramas envolvidos em uma modelagem 
orientada a objetos. 
RESUMO DO TÓPICO 2
124
AUTOATIVIDADE
1 Descreva os passos para a visualização da integração dos diagramas.
125
TÓPICO 3
ESTUDO DE CASO
UNIDADE 3
1 INTRODUÇÃO
Uma empresa é formada por um conjunto de processos inter-
relacionados. Logo, o aumento da eficiência da empresa deve ser obtido em 
função da compreensão e melhoria destes processos. Um processo dispõe de 
inputs, outputs, tempo, espaço, ordenação, objetivos e valores que, interligados 
logicamente, irão resultar em uma estrutura para fornecer produtos ou serviços 
ao cliente. Quase toda a operação de uma empresa pode ser traduzida como 
um conjunto harmônico de processos e subprocessos que interagem para que 
os produtos e serviços sejam entregues com eficiência, qualidade e nos prazos 
desejados pelos clientes.
 Todos os processos podem (e devem) ser melhorados ao longo do 
tempo para que os resultados sejam cada vez mais satisfatórios. Segundo 
Barbalho et al. (2002), um dos principais requisitos para o tratamento adequado 
de processos de negócio é sua efetiva compreensão, pois estando dispersos por 
várias áreas funcionais, é necessário que o gestor do processo conheça muito 
bem seus limites e abrangência.
Tal questão pode ser tratada com sucesso através da modelagem de 
processos, existindo até então diversas abordagens que se propõem a realizar 
tal intento. Faremos um estudo de caso aplicando a Linguagem de Modelagem 
Unificada (UML – em inglês Unified Modeling Language) para modelar um 
processo de negócio. A UML já é considerada um padrão para o modelamento 
de sistemas de informação, e caminha para especificações cada vez mais 
consistentes acerca do modelamento de processos de negócio. 
FONTE: Disponível em: <http://www.abepro.org.br/biblioteca/enegep2008_tn_sto_069_496_11902.
pdf>. Acesso em: nov. 2015. 
UNIDADE 3 | DIAGRAMAS ESTRUTURAIS
126
FONTE: Disponível em: <http://www.abepro.org.br/biblioteca/enegep2008_tn_
sto_069_496_11902.pdf>. Acesso em: 10 nov. 2015.
2 NECESSIDADE DE COMPREENDER OS PROCESSOS DA 
ORGANIZAÇÃO
O mapeamento de processos é útil para as empresas manterem-se 
competitivas através do contínuo aperfeiçoamento de seus processos, uma 
vez que proporciona uma metodologia estruturada para a busca da melhoria 
contínua. Segundo Hammer et al. (1999), a gestão por processos de negócio para 
as organizações aparece como alternativa vantajosa, desde que as ferramentas 
TÓPICO 3 | ESTUDO DE CASO
127
para análise e mapeamento dos processos sejam de domínio do corpo técnico 
e gerencial da organização. O conhecimento dos processos de negócio evolui 
de forma contínua e altera consideravelmente a visão da organização, baseada 
em conceitos tradicionais que fragmentam as tarefas por níveis hierárquicos e 
por áreas funcionais.
Werneck et al. (2003)afirmam que a gestão por processos permite às 
empresas uma melhor visibilidade das atividades, o que propicia ações que 
promovam maior desempenho no fornecimento de seus produtos ou serviços, 
maior capacidade de adaptação a mudanças, uso otimizado de recursos e 
possibilidade de aprendizado. O mapeamento dos processos gera um modelo 
da realidade, permitindo analisar a estrutura e o comportamento da empresa, 
comparar, simular e propor melhorias destes processos.
 Dessa forma, o mapeamento contribui para uma melhor compreensão 
das atividades da empresa e suas interações. Dentro deste contexto está a 
proposta deste trabalho, que vai utilizar o Diagrama de Atividades da UML 
para modelar e analisar um processo de negócio, usufruindo as vantagens 
deste diagrama na representação das atividades do processo. Além disso, o 
uso da UML permite aproximar a modelagem e a análise de processos com a 
Engenharia de Sistemas. 
2.1 O MAPEAMENTO DE PROCESSOS 
Barbalho (2002) afirma que um importante elemento de um modelo 
de processos de negócio é sua navegabilidade. Uma boa navegabilidade 
significa que é possível a um usuário do modelo caminhar entre as visões 
de uma maneira lógica, sem que seja necessário quebrar o raciocínio, mas ao 
contrário, construindo uma teia de relações que permita uma visão holística 
do processo modelado. Algumas técnicas de mapeamento de processo, como 
o fluxograma, apresentam-se consagradas na literatura, porém, novas técnicas 
de mapeamento estão sendo discutidas, dentro de suas limitações e alcances. 
A seguir apresenta-se uma breve descrição das técnicas mais utilizadas para 
mapeamento e análise de processos. 
UNIDADE 3 | DIAGRAMAS ESTRUTURAIS
128
2.1.1 Fluxograma 
O fluxograma é um gráfico que demonstra a sequência operacional do 
desenvolvimento de um processo, que caracteriza: o trabalho que está sendo 
realizado, o tempo necessário para sua realização, a distância percorrida 
pelos documentos, quem está realizando o trabalho e como ele flui entre os 
participantes deste processo.
O quadro a seguir mostra os principais símbolos utilizados pelos 
profissionais de Processamento de Dados na elaboração de fluxogramas de 
processo. 
QUADRO 1 - NOTAÇÃO – SIMBOLOGIA BÁSICA
Terminal - símbolo utilizado como ponto para indicar o início e/ou fim do fluxo 
de um programa.
Seta de fluxo de dados - permite indicar o sentido do fluxo de dados. Serve 
exclusivamente para conectar os símbolos ou blocos existentes.
Processamento - símbolo ou bloco que se utiliza para indicar cálculos 
(algoritmos) a efetuar, atribuições de valores ou qualquer manipulação de 
dados que tenha um bloco específico para sua descrição.
Entrada de dados - utilizado para ler os dados necessários ao programa.
Decisão - indica a decisão que deve ser tomada, indicando a possibilidade de 
desvios para diversos outros pontos do fluxo, dependendo do resultado de 
comparação e de acordo com situações variáveis.
Conector - utilizado quando é preciso particionar o diagrama. Quando ocorrer 
mais de uma partição, é colocada uma letra ou número dentro do símbolo de 
conexão para identificar os pares de ligação.
O fluxograma originou-se a partir do aperfeiçoamento do diagrama de 
blocos e do fluxograma utilizado na área de processamento de dados. Como 
instrumento de múltiplas funções, o fluxograma, mediante sua representação 
gráfica, permite visualizar e compreender melhor os processos de trabalho em 
execução, as diversas fases operacionais, a interligação com outros processos e 
todos os documentos envolvidos. 
TÓPICO 3 | ESTUDO DE CASO
129
2.1.2 SADT (Structured Analysis and Design Technic)
O SADT “nasceu pelas mãos” de Douglas T. Ross num projeto de 
desenvolvimento de uma linguagem estruturada para programação de máquinas-
ferramenta, no fim da década de 60. Este formalismo trazia algumas características 
revolucionárias, como a decomposição funcional e o fato de ser baseado numa 
representação esquemática simples, que auxiliou sobremaneira a descrição e o 
desenvolvimento dos sistemas de software complexos que começavam a aparecer 
(VERNADAT, 1996). Estas características disseminaram a aplicação deste formalismo 
e também o seu desenvolvimento em direção a abordagens estruturadas completas 
destinadas a diferentes aplicações, principalmente para a análise de sistemas. 
O SADT e o IDEF0 são apresentados juntos, pois têm origens e uma 
vida tão próximas que seus nomes até mesmo são fundidos na prática. 
2.1.3 IDEF3 
À medida que as técnicas de representação de processos foram evoluindo, 
técnicas mais sofisticadas foram sendo aplicadas em processos de serviços. Um 
bom exemplo é a aplicação do IDEF3. O IDEF3 é um dos integrantes da família 
de técnicas IDEF (Integrated ComputerAided Manufacturing), que foi desenvolvida 
pela Força Aérea dos Estados Unidos com o objetivo de descrever, especificar e 
modelar sistemas de manufatura (ALMEIDA et al., 2003). 
De modo geral, o IDEF3 fornece um mecanismo coletando e 
documentando processos. Ele captura relações da precedência e de causalidade 
entre situações e eventos em um formulário natural aos peritos do domínio, 
fornecendo um método estruturado para expressar o conhecimento sobre 
como um sistema ou um processo atua na organização. Segundo Costa (2002), 
as descrições IDEF3 podem:
• Gravar os dados cruzando resultados das entrevistas fact-finding (fato-
encontrado) em atividades da análise dos sistemas. 
• Determinar o impacto do recurso da informação de uma organização nos 
cenários principais da operação de uma empresa. 
• Documentar os procedimentos da decisão que afetam os estados e o ciclo 
de vida de dados compartilhados críticos, particularmente manufaturar, 
projetar, e dados da definição de produto da manutenção. 
• Controlar a configuração dos dados e mudar a definição da política do 
controle.
• Fazer o sistema projetar a análise do trade-off (fim de negócio).
• Fornecer a geração do modelo da simulação. 
UNIDADE 3 | DIAGRAMAS ESTRUTURAIS
130
2.1.4 UML (Unified Modeling Language)
A UML está emergindo como a notação-padrão para modelagem, 
sendo assim é importante compreendê-la. Segundo Furlan (1998), a UML vai 
além de uma simples padronização em busca de uma notação unificada, uma 
vez que contém conceitos novos que não são encontrados em outros métodos 
orientados a objeto. 
A UML é uma linguagem padrão para especificar, visualizar, 
documentar e construir artefatos de um sistema e pode ser utilizada com todos 
os processos ao longo do ciclo de desenvolvimento de software e através de 
diferentes tecnologias de implementação. Alguns autores, como Wilcox et al. 
(2003), defendem a utilização da UML, destacando as seguintes vantagens: 
• Simplicidade nas notações.
• Alta padronização encontrada nas aplicações publicadas.
• Alta aplicabilidade nos processos reais.
• Notação flexível às diversas situações. 
Para aplicação neste trabalho foi escolhida a UML, pois, como é uma 
linguagem utilizada no desenvolvimento de software, seu uso se justifica no 
sentido de integrar a análise do processo e a concepção do sistema (software). 
2.1.5 Diagrama de Atividades
 O modo para descrever os vários aspectos de modelagem pela UML é através 
da notação definida pelos seus vários tipos de diagramas. Um diagrama é uma 
apresentação gráfica de uma coleção de elementos de um modelo, frequentemente 
mostrado como um gráfico conectado de arcos e vértices (FURLAN, 1998). 
Os diagramas usados pela UML são: Diagrama de Casos de Uso, 
Diagrama de Classes, Diagrama de Objetos, Diagrama de Gráfico de Estados, 
Diagrama de Atividades, Diagrama de Sequências, Diagrama de Colaborações, 
Diagrama de Componentes e Diagrama de Implantação. 
Esses diagramas permitem a modelagem de todas as fases de um 
projeto de software. Utilizaremos apenas o Diagrama de Atividades, queé um diagrama de estado especial onde a maioria dos estados é estado de 
ação e a maioria das transições é ativada por conclusão das ações nos estados 
precedentes, mostrando o fluxo de uma atividade para outra. 
Este diagrama é importante quando se pretende descrever um 
comportamento paralelo, pois nem sempre os procedimentos se caracterizam por 
TÓPICO 3 | ESTUDO DE CASO
131
uma sequência mecânica de passos. Um Diagrama de Atividades é essencialmente 
um fluxograma que dá ênfase à atividade que ocorre ao longo do tempo.
 Um Diagrama de Atividades é composto por: 
• Início: Representado por um círculo preenchido.
• Estado de Atividade ou Atividade: Representado por um retângulo com 
bordas arredondadas.
• Transição: quando uma atividade termina, o fluxo de controle passa 
imediatamente para a atividade seguinte. Representado por uma linha 
orientada. 
• Desvio: Representado por um losango. Indica caminhos alternativos a tomar 
em um diagrama, mediante alguma expressão. 
• Intercalação: Também representado por um losango, é utilizada para marcar 
o final de um comportamento condicional iniciado por um desvio, ou seja, 
tem múltiplas entradas e uma única saída. 
• Separação: Representado por um traço horizontal, quando temos 
comportamento paralelo, ou seja, temos uma entrada e várias transições de 
saída que são executadas em paralelo. 
• Junção: Representado por um traço horizontal, utilizamos para completar a 
separação, ou seja, quando temos um processamento paralelo, precisamos 
sincronizar. 
• Raias: Representada por retângulos que englobam todos os objetos que estão 
ligados a um departamento. São usadas para indicar as entidades responsáveis pela 
execução das atividades, em geral estruturas organizacionais. Com o conjunto de 
elementos do Diagrama de Atividades é possível representar qualquer processo 
que tenha como base uma sequência de atividades inter-relacionadas. 
2.1.6 Aplicação do Diagrama de Atividades da UML
 Para o estudo de caso deste trabalho foi escolhida uma empresa que 
atua no mercado desde 2006. Os serviços desenvolvidos pela empresa são 
projetos e execução de pavimentação, passeios e reformas em escolas e praças. 
Por ser uma empresa criada há pouco mais de um ano, ela vem passando por 
uma série de adequações e melhorias contínuas em seus processos, ainda não 
tendo atingido um modelo considerado como “ideal”. 
Assim surgiu a oportunidade de aplicar a UML em um dos processos 
da empresa, visando à identificação de pontos críticos e propondo melhorias 
de performance/qualidade, modelando o processo escolhido através do 
Diagrama de Atividades. O processo escolhido para análise neste trabalho foi 
a execução de pavimentos. Apresenta-se abaixo a descrição do procedimento 
para que seja dado início a este processo. 
UNIDADE 3 | DIAGRAMAS ESTRUTURAIS
132
O diagrama correspondente é mostrado na figura adiante.
Primeiramente deve haver interesse por parte dos moradores da rua 
a ser beneficiada, visto que eles participam financeiramente da obra. Um 
destes moradores deve ir até à empresa e retirar o “termo de adesão” para 
colher as assinaturas dos vizinhos. Havendo interesse de, pelo menos, 70% 
dos moradores da referida rua, é aberto um protocolo de pavimentação. No 
Diagrama de Atividades mostrado na figura a seguir o processo inicia-se com 
a abertura deste protocolo (1). 
Um protocolo também é aberto para solicitações de vereadores, sendo 
que neste caso não é exigido o termo de adesão, apenas o pedido é enviado ao 
diretor-presidente, para que seja analisado (2).
Este protocolo, seja pedido de clientes ou de vereadores, é enviado ao 
Departamento Comercial, para análise do referido trecho (3), e posteriormente 
repassado à Engenharia, para que verifique se o trecho em questão já não foi 
orçado anteriormente (4). 
Assim, tem-se duas possibilidades: se o trecho já foi orçado este é 
enviado diretamente ao arquivo (5), e o processo é finalizado; caso o trecho não 
tenha sido orçado, o protocolo é enviado à Topografia para que seja realizado 
o levantamento e feito o anteprojeto da rua (6). 
Isto feito, o protocolo retorna à Engenharia para que sejam feitos o 
orçamento e o projeto definitivo do trecho (7). Juntamente com o projeto e o 
orçamento, o protocolo é enviado ao Departamento Comercial para que seja 
feito o croqui com os dados da rua e dos respectivos moradores (8). 
A partir deste momento, o mesmo departamento entra em contato com 
o vendedor da região em questão, para repassar-lhe a pasta da rua, com o 
croqui e o valor a ser pago pelos clientes para viabilização da obra (9). De posse 
disto, o vendedor deve visitar cada morador, e oferecer-lhe a pavimentação 
(10). Após as visitas, tem-se novamente duas situações: a rua pode ter atingido 
70% de adesão, que é a exigência mínima para que seja executado o trecho, ou 
não. Caso ocorra a última opção, o processo é arquivado (11). Se a rua atingir 
os 70% de adesão, o vendedor solicita a documentação de cada morador e 
preenche a ficha cadastral (12). 
De posse de todos os documentos, o vendedor envia estes dados ao 
Departamento Comercial para analisar toda a documentação da rua (13). Após 
esta análise, a documentação pode estar completa (14), ou os clientes podem 
ter impossibilidade de apresentar algum tipo de documento exigido, como 
comprovante de renda, por exemplo. Neste caso, o protocolo é enviado ao 
diretor-presidente para que ele avalie a documentação pendente (15).
TÓPICO 3 | ESTUDO DE CASO
133
Após a análise, a documentação pode ser reprovada (16), sendo o 
processo arquivado, ou aprovada (17). Se a documentação for aprovada, ou 
se ela já estivesse completa desde o início, o Departamento Comercial redige 
os contratos (18). Pode-se ter dois tipos de contratos, quando o cliente financia 
diretamente com a empresa (em até 30 vezes) (19), ou quando o financiamento 
é feito pelo Banco do Brasil (em até 48 vezes) (20). 
Os clientes que optarem por financiar com o Banco do Brasil recebem 
um desconto de 15%, pois para a empresa o recebimento é à vista. Como o 
Departamento de Engenharia só insere o trecho no cronograma de obras 
quando a rua atinge 50% de recebimento, o trecho vendido é repassado ao 
Departamento Financeiro, para aguardar esta porcentagem de recebimento 
(21). Quando o financiamento acontece direto com a empresa, existe a consulta 
ao SPC (22). Após a consulta tem-se novamente duas situações: o cliente pode 
estar com a documentação regular ou pendente. Se a situação estiver regular 
(23), o processo é encaminhado à Recepção, para que sejam impressos os 
boletos (24).
Caso o cliente esteja com pendência no SPC, o Departamento Comercial 
entra em contato com o vendedor (25), que avisa o cliente sobre a pendência no 
SPC e verifica a possibilidade de regularizar a situação. Estes clientes podem 
regularizar a situação, dando andamento ao processo e gerando os boletos 
(26), ou não, continuando com a situação irregular (27). Neste caso, cabe à 
presidência verificar se, retirando este cliente inadimplente, a rua continua 
com 70% de adesão. Caso afirmativo, o processo segue, sendo repassado à 
Recepção para que sejam impressos os boletos (28). 
Se retirarmos este cliente, e a rua ficar com adesão inferior a 70%, este 
protocolo é arquivado por falta de adesão (29). Com os boletos gerados, e os 
clientes efetuando os pagamentos mensais, a rua é repassada ao Departamento 
Financeiro (30) para que este realize o controle de recebimentos (21). Tão logo 
a rua atinja os 50% de recebimento (31), esta é enviada ao Departamento de 
Engenharia para que seja inserida no cronograma de obras (32). Para facilitar o 
deslocamento dos maquinários, o cronograma de obras é dividido por regiões 
da cidade, chamadas lotes. 
Quando é iniciado um determinado lote, todas as ruas vendidas 
desta região que estejam 50%pagas são pavimentadas. Buscando aumentar 
a produtividade, pode-se executar a obra (33) ou terceirizar a obra (34). 
No último caso, a empresa passa de executora a fiscalizadora, porém, o 
procedimento é realizado da mesma forma. Quando a obra é finalizada, o 
protocolo é arquivado (35).
UNIDADE 3 | DIAGRAMAS ESTRUTURAIS
134
RECEPÇÃO COMERCIAL ENGENHARIA TOPOGRAFIA PRESIDÊNCIA FINANCEIRO ARQUIVOVENDAS
Abrir
Protocolo
Analisar
pedido
Analisar
o trecho
Verificar os
trechos já
usados
Encaminhar
para
levantamento
topográfico
Fazer croqui
com dados
da rua e
respectivos
moradores
Relizar
levanta-
mento e
anteprojeto
Conectar
vendedor da
região
Protocolo
arquivado
(1)
(1)
(3)
(4)
Solic.
de
Cliente
Solicitação de Vereadores (2)
Trecho
não
orçado (6)
(7)
(8)
(9)
(10)
Trecho já orçado (5)
Orçar e
projetar o
trecho
Visitar
moradores
Protocolo
arquivado
Solicitar
a doc. de
cada
morador
Preencher
a ficha
cadastral
Analisar a
documentação
Analisar a
documentação
pendente
não atingiu
70%
de adesão
(11)
Rua c/
no mín.
70% de
adesão
(12)
(13)
Doc.
Impossibilidade
de
apresentar um documento
(15)
Protocolo
arquivado
TÓPICO 3 | ESTUDO DE CASO
135
Redigir contratos
Executar
a obra
Fazer
boletos
Ok
(14)
(18) Cont.
Doc.
Doc.
Apro-
vada
reprovada
(17)
(16)
Cont.(18)
(21)
Presidente
Regular
(25)
(23)
(19)
(22)
(20)
(27)
(26)
(28)
(29)
Sit.
Sim
Não
Sit.
irreg.
Reg.
(24)
(30)
(32)
(3
(2
Financ.
c/BB
Financ.
c/ a
Empresa
Empresa
recebe
a vista
Consulta
SPC
Avisar
cliente
sobre
pendência
no SPC
Verificar a
possibilidade de
regularizar a
situação
Verificar se
retirando este
cliente a rua
continua com 
70% de adesão
Protocolo
arquivado
Aguardar
50% de
recebimento
Rua atingida
50% de
recebimento
Inserir o
trecho no
cronograma
de obras
UNIDADE 3 | DIAGRAMAS ESTRUTURAIS
136
Terceirizar
a obra
Protocolo
arquivado
(33)(34)
(35)
Figura 1 - Diagrama de Atividades
2.1.7 Avaliação da Aplicação do Diagrama de Atividades
Após o mapeamento verificou-se que o Diagrama de Atividades da 
UML permitiu a visualização do processo, possibilitando uma representação 
padronizada das informações com um nível de detalhamento adequado. A 
aplicação do Diagrama de Atividades no processo leva a organização a reconhecer 
os pontos fracos ou gargalos da empresa. Neste estudo de caso, após o mapeamento 
do processo, foram intensificadas as seguintes possibilidades de melhorias: 
• Após ser aberto um protocolo, o Departamento Comercial o envia à 
Engenharia, para que seja verificado se este trecho de rua já foi orçado ou 
não (4), sendo que isto poderia ser feito pelos funcionários da recepção 
antes mesmo de um protocolo ser aberto. Muitas vezes são abertos vários 
protocolos para um mesmo trecho de rua, e isto só é verificado quando o 
processo passa pelo Departamento de Engenharia. 
• Se a Recepção procedesse conforme descrito acima, esta poderia repassar 
o protocolo diretamente à Topografia, eliminando diversas etapas e 
diminuindo o prazo entre a solicitação de clientes interessados e a visita de 
um vendedor, já com o orçamento da rua.
• Quando o cliente financia direto com a empresa (22), é feita a consulta ao 
SPC e, em diversos casos, os clientes estão com a situação pendente (25). Esta 
consulta poderia ser efetuada diretamente pelo vendedor, antes de repassar 
a documentação e as fichas cadastrais ao Departamento Comercial (13).
• Após a obra concluída é importante que um representante da empresa 
retorne ao local para obter o feedback do serviço executado e também para 
verificar se a obra está em perfeitas condições de uso e limpeza. É necessário 
que se visite cada morador para que se possa obter um indicador de clientes 
satisfeitos/insatisfeitos e propor uma meta a ser alcançada, preocupando-se 
sempre em atingir resultados melhores. A principal vantagem da utilização 
de um diagrama associado a UML é que após a análise e identificação de 
possíveis melhorias em um processo, o modelo poderá ser aproveitado 
integralmente para iniciar o desenvolvimento do sistema de informações 
que dará suporte ao processo. 
TÓPICO 3 | ESTUDO DE CASO
137
2.1.8 Conclusões 
Observou-se que o mapeamento do processo através do Diagrama 
de Atividades trouxe resultados importantes, como o entendimento e a 
visualização global do processo por toda a organização, apresentando 
as informações de forma clara e padronizada e mostrando o fluxo de uma 
atividade para outra. 
O Diagrama de Atividades também possibilitou encontrar os pontos 
críticos e gargalos da empresa, e assim, propor sugestões de melhorias, que 
certamente levarão a um aumento da eficiência e da qualidade do processo 
como um todo, possibilitando o aumento de sua competitividade no mercado. 
Conclui-se, tendo como base este estudo de caso, que o Diagrama de Atividades 
da UML atendeu ao objetivo deste trabalho, permitindo o mapeamento de um 
processo de negócio de maneira satisfatória, contribuindo para uma melhor 
compreensão das atividades da empresa e suas interações, podendo ser utilizado 
para modelagem de processos e não apenas para modelagem de softwares. 
FONTE: Disponível em: <http://www.abepro.org.br/biblioteca/enegep2008_tn_sto_069_496_11902.
pdf>. Acesso em: nov. 2015.
UNIDADE 3 | DIAGRAMAS ESTRUTURAIS
138
LEITURA COMPLEMENTAR
O uso de software de apoio à modelagem é muito importante, por dois 
motivos: primeiro porque os modelos começarão a ficar tão longos que a folha 
de papel ficará pequena, segundo porque é uma ótima maneira de checar as 
associações entre os modelos. [5]. O principal objetivo da tecnologia CASE é 
separar o projeto da implementação do código. Existem várias ferramentas de 
modelagem, algumas suportando a UML, porém muitas apoiam um método 
particular que em si atende a um tipo de projeto. É essencial avaliar os benefícios 
das ferramentas e suas limitações, evitando problemas posteriores no processo de 
desenvolvimento.
 Com um grande número existente de ferramentas CASE, com vários 
recursos característicos que proporcionam, é necessário conhecer quais delas 
apoiam melhor a UML. Entretanto, para que isto seja possível é preciso 
fazer uma verificação das ferramentas disponíveis e avaliar suas principais 
características.
Atualmente existem várias ferramentas de apoio à UML. O site Objects by 
Design [7] apresenta, aproximadamente, 115 ferramentas com informações sobre 
seus fabricantes, versões, datas, plataformas e preços (nem sempre disponível). O 
139
presente artigo apresenta um modelo para avaliação de ferramentas de suporte 
à UML, baseado em requisitos funcionais, não funcionais, bem como em normas 
de qualidade. Inicialmente apresenta-se as categorias definidas no modelo de 
avaliação, bem como os critérios que formam cada categoria. Apresenta-se a 
seguir o estudo de caso que foi definido e realizado a fim de validar o modelo 
proposto. Posteriormente, são apresentados os principais resultados obtidos com 
o estudo de caso, algumas observações complementares constatadas na avaliação 
e, finalmente, a conclusão. 
2. O Modelo Proposto 
O site anteriormente mencionado apresenta, também, uma lista comentada 
de itens que devem ser considerados nas ferramentas. Porém, a lista não aponta 
quais tipos de respostas devem ser buscados e nem uma organização precisa dos 
itens (classificação), o que dificulta, em parte, sua aplicação. Além disso, os itens 
não são relacionados com normas de qualidade. Sendo assim, a finalidade do 
modelo proposto é estabelecer um conjunto de critérios, baseados em normas de 
qualidade e classificadosem requisitos funcionais e não funcionais, que permitam 
a avaliação de ferramentas de apoio à UML.
 Após a avaliação, segundo os critérios propostos, as informações obtidas 
poderão auxiliar o futuro usuário na escolha da ferramenta de apoio à UML 
mais adequada às suas necessidades. Os critérios definidos no modelo permitem 
especificar como as ferramentas trabalham, se realmente executam o que seu 
fabricante anuncia e se atendem aos requisitos dos usuários com qualidade. 
Porém, não é objetivo do modelo indicar qual ferramenta é a melhor. A opção 
será feita pelo usuário a partir dos resultados obtidos. 
Para uma melhor definição dos critérios, investigou-se algumas normas 
de qualidade existentes. As normas de qualidade investigadas foram: ISO/IEC 
9126 - Engenharia de Software - Qualidade de produto de software, ISO/IEC 14598 
- Tecnologia de informação – Guias para avaliação de produto de software, NBR 
ISO/IEC 12119 - Tecnologia de informação - Pacotes de software - Testes e requisitos 
de qualidade [4] e ISO/IEC 14102 - Tecnologia de informação – Orientação para 
avaliação e seleção de ferramentas CASE. A lista de critérios para avaliação das 
ferramentas foi criada para direcionar a avaliação. Os 57 critérios foram divididos 
em funcionais e não funcionais e apresentam duas formas de resposta, como 
mostra a Tabela 1. 
Para uma melhor organização dos critérios, os mesmos foram classificados 
em categorias que servem para agrupar os critérios que possuem características 
semelhantes. Apresenta-se, a seguir, as oito categorias de critérios que foram 
criadas, bem como os objetivos principais de cada uma delas:
• Baseados na norma ISO/IEC 9126: verificar nas ferramentas a existência de 
características relacionadas a esta norma.
140
• Baseados em características de hardware e software: verificar em quais plataformas 
de hardware e software as ferramentas podem ser utilizadas.
• Baseados no repositório de dados: verificar quais são as funções do repositório 
nas ferramentas.
• Baseados na documentação: verificar que tipos de documentação acompanham 
as ferramentas e se as mesmas auxiliam os desenvolvedores no uso das 
ferramentas. 
• Baseados no uso da ferramenta com relação ao computador utilizado: verificar 
qual o desempenho das ferramentas com relação ao computador utilizado para 
avaliação.
• Baseados na UML: verificar quais funções executadas pelas ferramentas 
correspondem com as características da UML.
• Baseados no fornecedor: possibilitar informações detalhadas sobre o fornecedor, 
produtos e suporte aos mesmos.
• Baseados nas necessidades identificadas com a utilização das ferramentas: 
verificar se as ferramentas atendem às necessidades dos usuários.
Tabela 1 - Tipos de Resposta
Critério Tipo de resposta Código
É possível gerar código fonte 
a a partir da modelagem?
Sim/Não/Em parte, 
justificando se necessário.
1
Quais os bancos de dados 
apoiados pela ferramenta?
Resposta descritiva 2
Nas próximas seções serão apresentados os critérios de cada categoria, 
bem como a motivação da criação de cada uma das categorias. Nas tabelas, a 
coluna “Resp” refere-se ao tipo de resposta do critério, conforme Tabela 1, e a 
coluna “Req” (Requisito) corresponde a F (Funcional) ou NF (Não Funcional). 
2.1 Critérios baseados na norma ISO/IEC 9126 
Os critérios desta categoria foram criados com base na norma ISO/IEC 9126. 
O objetivo é descobrir como as ferramentas atendem algumas características desta 
norma. Foram consideradas as características manutenibilidade (subcaracterísticas 
modificabilidade e analisabilidade), confiabilidade (subcaracterística maturidade), 
funcionalidade (subcaracterística interoperabilidade) e apreensibilidade. Nesta 
categoria foram criados 22 critérios, sendo que a Tabela 2 apresenta alguns 
exemplos.
141
Tabela 2 - Critérios baseados na norma ISO/IEC 9126
Critério Objetivo Resp Req
É possível incluir, excluir, 
mover, agrupar, desagrupar 
e redimensionar objetos?
Avalia a possibilidade de manipulação dos 
objetos na ferramenta depois de criados. 
O objetivo é verificar se após os elementos 
serem criados, os mesmos podem ser 
modificados.
1 F
Possui opções para análise 
dos diagramas?
Verificar se a ferramenta auxilia o 
desenvolvedor na depuração da modelagem, 
analisando todos os elementos criados.
1 F
É possível gerar código, 
fonte a partir da 
modelagem criada?
Verificar se o usuário poderá gerar 
código para a aplicação que está sendo 
desenvolvida.
1 F
É possível fazer engenharia 
reversa de dados?
Verificar se a ferramenta possui este recurso. 1 F
É possível importar e 
exportar dados?
Verificar quais ferramentas importam/exportam 
arquivos do projeto que está sendo criado.
1 NF
Na ferramenta é possível 
valer-se de informações de 
outras ferramentas?
Avaliar se é possível utilizar subsídios de 
outras ferramentas.
1 NF
Os arquivos criados na 
ferramenta são portáveis 
para a mesma ferramenta 
em outra plataforma?
Avaliar se os arqeuivos criados na ferramenta 
podem ser utilizados nas versões da 
ferramenta criadas para outras platafromas.
1 NF
A ferramenta possui 
restrição quanto ao número 
de objetos criados pela 
mesma na modelagem?
Avaliar se a ferramenta possui alguma 
restrição quanto a criação de elementos na 
ferramenta.
1 NF
Existe maneira de prevenir 
falhas originadas por 
hardware ou software?
Verificar se a ferramenta possui recuperação 
de dados por meio de defeitos de hardware 
e/ou software
1 NF
A organização gráfica dos 
elementos visuais promove 
a compreensão do usuário 
na utilização da ferramenta?
Avaliar se a ferramenta é fácil de ser 
manipulada, verificando se o usuário terá 
facilidade para utilização da ferramenta a 
partir da visualização dos elementos.
1 NF
2.2 Critérios baseados na UML 
Esta categoria é composta de quatro critérios que permitem avaliar 
a relação da ferramenta com características especiais da UML, como 
possibilidade de definição de herança múltipla, possibilidade de criação de 
todos os diagramas propostos pela linguagem e possibilidade de armazenar 
tarefas intermediárias dos casos de uso. A Tabela 3 apresenta os critérios 
definidos para esta categoria.
142
Tabela 3 - Critérios baseados na UML
Critério Objetivo Resp Req
Permite definir tarefas 
intermediárias em casos de 
uso?
Verificar se é possível documentar tarefas 
intermediárias dos casos de uso.
1 F
Permite definição de 
herança múltipla?
Verificar se a ferramenta possui esta opção no 
diagrama de classes.
1 F
Permite a criação de todos 
os diagramas propostos 
pela UML?
Verificar se é possível criar todos os 
diagramas da UML.
1 F
Qual é a versão da UML 
suportada pela ferramenta?
Informar ao usuário qual é a versão da UML 
suportada pela ferramenta.
2 NF
2.3 Critérios baseados no fornecedor 
Com os critérios desta categoria é possível obter-se informações mais 
detalhadas sobre os fornecedores das ferramentas, como tempo de existência, 
forma de comercialização dos produtos, suporte oferecido etc. Foram definidos 11 
critérios e todos correspondem a requisitos não funcionais. A Tabela 4 apresenta 
exemplos de critérios definidos para esta categoria.
Tabela 4 - Critérios baseados no fornecedor
Critério Objetivo Resp
Há quanto tempo o fornecedor 
está no mercado?
Informar há quanto tempo o fornecedor está 
atuando no mercado.
2
O fornecedor comercializa outros 
produtos?
Verificar se existem outros produtos 
desenvolvidos pelo fornecedor.
2
Há quanto tempo a ferramenta 
está disponível?
Verificar há quanto tempo a ferramenta está 
disponível para utilização.
2
Como é possível adquirir a 
ferramenta?
Verificar quais são as possibilidades de aquisição 
da ferramenta.
2
Como éfeito o suporte aos 
clientes?
Verificar como é realizado o atendimento ao 
usuário
2
O produto possui alguma 
certificação de qualidade?
Verificar se a ferramenta possui alguma certificação 
de qualidade ou se existe alguma preocupação por 
parte do fabricante quanto a isto.
1
143
Tabela 5 - Critérios baseados nas necessidades identificadas com a utilização da ferramenta
2.4 Critérios baseados nas necessidades identificadas com a utilização da 
ferramenta
 A partir dos seis critérios definidos nesta categoria é possível verificar se 
as ferramentas atendem às necessidades dos usuários na utilização das mesmas. 
A Tabela 5 apresenta exemplos de critérios definidos para esta categoria.
Critério Objetivo Resp Req
É possível gerar histórico 
das ações executadas?
Avaliar se disponibiliza registros do que é 
criado.
1 F
É possível abortar/desfazer 
ações executadas?
Avaliar se existe controle para determinadas 
ações, verificando se é possível desfazer ou 
abortar ações facilitando a criação dos modelos.
1 F
Existe alguma forma de 
controle e gerencimaneto 
de usuários?
Avaliar se existe controle e gerenciamento de 
usuários.
1 F
Quais são os conhecimentos 
mínimos para usar?
Identificar e informar quais devem ser os 
conhecimentos básicos de utilização.
2 NF
2.5 Critérios baseados em características de hardware e software 
A partir dos critérios desta categoria é possível verificar as necessidades de 
hardware e software das ferramentas. Foram definidos cinco critérios nesta categoria 
e todos correspondem a requisitos não funcionais. Alguns exemplos são:
• É possível executar a ferramenta em quais sistemas operacionais? O objetivo 
deste critério é identificar para quais sistemas operacionais as ferramentas estão 
disponíveis. A resposta para este critério é descritiva (tipo 2), ou seja, uma lista 
de sistemas operacionais. 
• Quais são os requisitos mínimos aconselhados pelo fornecedor para a utilização 
da ferramenta? Busca-se verificar quais os requisitos (memória, espaço em disco, 
processador, etc.) mínimos para a utilização das ferramentas. A resposta informa 
ao usuário qual deve ser a capacidade mínima do seu computador para que 
ele possa utilizar a ferramenta satisfatoriamente. A resposta para este critério é 
descritiva (tipo 2), ou seja, a configuração mínima sugerida pelo fabricante.
• É preciso uma base de dados específica para a ferramenta? Com este critério é 
possível investigar se as ferramentas necessitam de alguma base de dados para 
a criação dos diagramas. A resposta para este critério é do tipo 1.
2.6 Critérios baseados no repositório de dados 
Nesta categoria buscou-se informações que permitissem avaliar as 
funções dos repositórios de dados das ferramentas. Para atingir este objetivo 
foram criados três critérios: 
144
• Existe repositório? O objetivo deste critério é avaliar de que forma a ferramenta 
armazena os dados. 
• Através do repositório é possível criar informações (classes, atributos, ligações)? 
Com este critério busca-se avaliar se os repositórios das ferramentas permitem 
a criação dos elementos dos diagramas a partir das informações salvas. 
• É possível recuperar os dados do repositório? Busca-se informações para avaliar 
se os repositórios das ferramentas permitem a recuperação dos elementos 
dos diagramas a partir das informações salvas. Os critérios desta categoria 
correspondem a requisitos funcionais e possuem tipo de resposta 1. 
2.7 Critérios baseados na documentação 
Os critérios desta categoria demonstram a relação das ferramentas com 
a respectiva documentação. O objetivo é verificar se existe uma preocupação 
quanto à documentação e como a mesma é disponibilizada. Foram criados 
quatro critérios nesta categoria, todos correspondem a requisitos não funcionais 
e possuem resposta do tipo 1. A seguir são apresentados alguns exemplos de 
critérios desta categoria: 
• Existe help, manuais e documentação que auxilie o usuário a esclarecer 
dúvidas? A partir da resposta a este critério é possível verificar a existência 
de documentação, de que tipo é a mesma e se realmente auxilia o usuário na 
utilização da ferramenta. 
• Existe documentação que esclarece dúvidas quando à instalação? O objetivo 
é verificar se existe alguma documentação que auxilie a instalação da 
ferramenta. 
• É possível configurar a forma como a documentação será gerada? Com este 
critério é possível verificar se o usuário poderá alterar a documentação gerada 
pela ferramenta de acordo com suas necessidades. 
2.8 Critérios baseados na utilização da ferramenta com relação ao computador 
utilizado para avaliação 
Nesta categoria busca-se informações que permitam avaliar as ferramentas 
com relação ao computador utilizado para avaliação das mesmas. Para atingir 
este objetivo foram criados dois critérios: 
• Possui tempo de resposta apropriado? A partir da resposta a este critério 
pretende-se detectar como foi a resposta aos processos feitos na ferramenta. 
• Qual o desempenho no computador utilizado? A intenção é indicar a viabilidade 
da utilização, orientando o usuário se poderá utilizá-la com a tecnologia que 
possui ou deverá utilizar mais recursos. Os critérios desta categoria correspondem 
a requisitos não funcionais e possuem resposta descritiva (tipo 2). 
145
3. Aplicação do modelo 
A fim de validar o modelo proposto, foi definido e elaborado um estudo 
de caso. Escolheu-se algumas ferramentas e elaborou-se os diagramas da UML 
com base em um Controle de Simpósio. Inicialmente foram identificados os atores 
e, logo após, realizou-se um levantamento das responsabilidades de cada um. 
As responsabilidades foram descritas como pequenas tarefas. A análise destas 
tarefas intermediárias possibilitou a identificação de prováveis casos de uso que 
serviram de base para a construção do diagrama correspondente. Em seguida, 
tornou-se possível a identificação das classes, bem como suas características e 
relacionamentos, dando origem ao Diagrama de Classes. 
A partir da descrição das tarefas intermediárias de cada diagrama de caso 
de uso foram desenvolvidos os diagramas de sequência. A seguir, com base na 
classe Participante, criou-se o Diagrama de Estados e o Diagrama de Atividades 
baseou-se na classe Cancelamento. A Figura 1 apresenta uma parte do Diagrama 
de Classes construído. 
Todos os diagramas elaborados encontram-se em [2]. As ferramentas 
escolhidas para este estudo foram a Rational Rose C++ Demo2 da IBM/Rational, 
PowerDesigner 9.03 da Sybase, Together ControlCenter 6.14 da Borland, 
AllFusion Component Modeler 4.15 da CA (Computer Associates), Enterprise 
Architect 3.516 da Sparx Systems, Poseidon for UML Community Edition 1.67 e 
ArgoUML 0.148. A Rational Rose foi escolhida por ser desenvolvida pela mesma 
empresa da UML; a PowerDesigner 9.0 por ser uma ferramenta de modelagem 
muito utilizada no meio acadêmico em geral; a Poseidon e a ArgoUml por serem 
ferramentas de código aberto; a Together ControlCenter, a AllFusion Modeler 
e a Enterprise Architect por serem ferramentas encontradas nas referências 
utilizadas. 
Além disso, foi possível encontrar cópias de demonstração de todas as 
ferramentas acima citadas. A avaliação das ferramentas foi realizada através da 
aplicação do estudo de caso nas mesmas e consulta a informações disponibilizadas 
pelo seu fornecedor por meio da documentação de cada uma delas. 
3.1 Resumo dos Resultados 
Durante a avaliação foi possível criar a modelagem de acordo com 
as exigências da UML. Constatou-se que cada ferramenta possui padrões e 
características diferentes. Os principais resultados constatados com a avaliação 
são mostrados na Tabela 6. 
146
3.2 Observações finais sobre a avaliação 
Através da avaliação verificou-se que cada ferramenta possui 
características e padrõesdiferentes que devem ser ressaltados. Identificou-se que 
em todas as ferramentas é possível criar a modelagem conforme a UML, porém, 
dependendo da ferramenta isto pode ser feito com maior ou menor dificuldade. 
Todas as ferramentas estudadas oferecem várias formas de documentar os 
projetos, reforçando uma das principais características da UML, que é de ser 
uma linguagem de documentação. Além dos diagramas da UML, constatou-
se que algumas ferramentas, como a Together ControlCenter, Enterprise 
Architect e Allfusion Component Modeler, oferecem modelagem de negócios, 
e a PowerDesigner possibilita modelagem física e conceitual. Observou-se, 
com exceção da versão da Rational Rose estudada, que todas as ferramentas 
preocupam-se com a portabilidade dos seus modelos, mesmo as que não possuem 
versões para outros sistemas operacionais, pois elas oferecem exportação de seus 
modelos em XML. A maioria das ferramentas é bem construída graficamente, 
a Poseidon e a Together ControlCenter possuem ícones com os desenhos na 
forma dos diagramas correspondentes, facilitando a compreensão e agilizando 
a construção dos mesmos. Além disto, com exceção da AllFusion Component 
Modeler, todos os diagramas podem ser visualizados facilmente através do 
browser, pois são agrupados conforme o tipo de diagrama de acordo com a UML. 
As empresas que não possuem recursos financeiros ou não desejam gastar para 
adquirir uma ferramenta podem utilizar a Argouml e a Poseidon, porque são de 
código aberto e distribuídas gratuitamente.
4. Conclusões 
A UML é uma tendência entre desenvolvedores de aplicações baseadas 
em modelos orientados a objetos, entretanto, há uma grande dificuldade de 
encontrar experiências práticas e exemplos mais realistas na literatura, tornando 
lento o processo de inserção desta metodologia no mercado de trabalho. Existem 
grandes esforços para mudar este panorama. A prova disto é o investimento do 
OMG em melhorias na UML lançando constantemente novas versões. Atualmente, 
existem várias ferramentas de apoio à UML. A fim de facilitar a avaliação destas 
ferramentas, definiu-se um modelo composto por um conjunto de critérios 
baseados em requisitos funcionais, não funcionais e normas de qualidade. O 
objetivo do modelo é auxiliar o usuário para que ele obtenha informações sobre 
cada ferramenta a fim de que, a partir destas informações, possa escolher a 
que melhor atenda às suas necessidades ou, valendo-se dos dados do estudo, 
criar uma nova avaliação. Não é objetivo deste modelo indicar qual a melhor 
ferramenta, bem como abordar custos de aquisição e manutenção. Sugere-se que 
após a realização da avaliação, o usuário estabeleça prioridades aos critérios de 
acordo com suas necessidades. Para os critérios podem ser atribuídas faixas de 
valores, por exemplo 0 a 5, que demonstrará em que grau a ferramenta atende 
àquele critério. Assim, a ferramenta que melhor atender as necessidades é a que 
147
totalizar mais pontos. Cabe enfatizar que, na seleção de ferramentas, é importante 
considerar tanto os requisitos funcionais como os não funcionais. Por esta razão, 
na elaboração dos critérios do modelo proposto teve-se a preocupação em fazer 
esta distinção. 
O crescente aumento de novas ferramentas disponíveis, incluindo 
algumas de código aberto e uso livre, e a constante atualização das mesmas para 
versões superiores, motivam a complementação deste trabalho abrangendo mais 
características das ferramentas avaliadas, com a elaboração de novos critérios. 
Também é possível estender a avaliação realizada para um maior número de 
ferramentas.
148
Vagas
 codvaga: integrar
 qtdisp: integer
 qtvaga: integer
 Evento: string
 Periodo: string
Estudante
 matricula: string
 nivel: string
Outro
 Atividade: string
Categoria
 codcat: integer
 descat: string
 valor: float
Professor
 area: string
 codinst: instituição
Profissional da Area
 codemp: string
 codcargo: string
Cidade
 codcid: string
 nomecid: string
 UF: string
Cancelamento
 codpant: Participante
 dtcancel: string
1
1
Participante
ccodpart
nome: string
endereco: string
drinscircao: string
dtpgto: string
Cep: string
Fone: string
codcid: Cidade
status: string
codcat: Categoria
(from Use Case View
0...*
0...*
Tabela 5 - Critérios baseados nas necessidades identificadas com a utilização da ferramenta
Item Resultado
Importação e 
Exportação de Arquivos
Com exceção da Rational, todas exportam dados em XML, A 
PowerDesigner importa os modelos criados na Rational, mas o 
diagrama de classes fica com os objetos e ligações confusos na 
ferramenta, após a importação. A Poseidon abre modelos criados na 
Argouml e vice-versa.
Portabilidade
A Enterprise Architect e Allfasion possuem versões apenas para o 
WIndows, as demias (exceto a PowerDesigner que não identificou-se) 
contém versões para outros sistemas operacionais. A Poseidon e a 
Argouml inpedem do mesmo.
Harware e Software 
Necessários
128 MB de RAM recomendada pelo fornecedor é insuficiente para a 
utilização da Poseidon e da Argouml. Para a Together é recomendado 
no mínimo 512MB. As ferramentas Together e Allfusion requerem 
grande espaço em disco (a partir de 100 MB); par Enterprise Architect 
Argouml e Rational Rose é necessário até 15 MB e par Poseidon e 
PowerDesigner não foi possível identificar, porém o tamanho do 
arquivo de instalação das mesmas e superior a 60MB. O drive de 
CD só é necessário para instalação das ferramentas. Recomenda-se 
uma placa de vídeo com resolução mínima de 800x600, exceto para a 
Together pois o fornecedor recomenda 1024x768.
149
Reposi´torio de Dados
Somente a Allfusion necessita de instalação de uma base de dados 
específica (MS SQL Sever). A PoqerDesigner, Enterprise Architect e 
AllFusion Component Modeler possuem repositórios de dados que 
permitem controlar uusários ou grupos de usuários, atribuindo-
lhes permissões para os projetos; a Together também contém este 
controle, porém como acontece com as demais, o repositório de 
dados é utilizado apenas como um browser para visualização dos 
elementos dos diagramas. Com exceção da Poseidon e da Rational 
Rose (que não foi possível identificar), todas têm suporte a algum 
banco de dados.
Interface
Com exceção da AllFusion Component Modeler, todas são muito 
bem organizadas graficamente.
Documentação
Todas são acompanhadas de documentação, sendo também 
disponibilizadas na página correspondente.
Conhecimentos Prévios
COm execção da AllFusion Component Modeler, não houve 
dificuldades na manipulação das ferramentas.
FONTE: Disponível em: <http://www.abepro.org.br/biblioteca/enegep2008_tn_sto_069_496_11902.
pdf>. Acesso em: 10 nov. 2015.
150
Neste tópico você:
• Observou que o mapeamento do processo através do Diagrama de Atividades 
trouxe resultados importantes, como o entendimento e a visualização global do 
processo por toda a organização, apresentando as informações de forma clara e 
padronizada e mostrando o fluxo de uma atividade para outra. 
• O Diagrama de Atividades também possibilitou encontrar os pontos críticos e 
gargalos da empresa e, assim, propor sugestões de melhorias, que certamente 
levarão a um aumento da eficiência e da qualidade do processo como um todo, 
possibilitando o aumento de sua competitividade no mercado. 
RESUMO DO TÓPICO 3
151
AUTOATIVIDADE
1 Descreva os passos do Diagrama de Atividades proposto no Estudo de Caso 
abordado acima.
152
153
REFERÊNCIAS
ANDRADE, C. A. V. Metodologia de Análise de Sistemas. 8. Módulo. ESAB – 
Escola Superior Aberta do Brasil: Vila Velha, 2007. 
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. Rio de 
Janeiro: Elsevier, 2007. 
BIGERSTAFF, T; RICHTER C. Re-usabilityFramework, Assessment and 
Directions. Tutorial: Software Reuse - Emerging Technology. IEEE Computer 
Society, EH0278-2, p. 3-11. 1989.
BLAHA, M.; RUMBAUGH, J. Modelagem e projetos baseados em objetos com 
UML 2. 2. ed. Rio de Janeiro: Elsevier, 2006. 
BOOCH, G. Object-Oriented Analysis and Design with Applications. USA: 
Redwood City, Benjamin, 2006.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. 
Rio de Janeiro: Elsevier, 2005.
BROOKS, F. P. No Silver Bullet: Essence and Accidents of Software 
Engineering. Computer, New York, vol. 20, n.4, p. 10-19, Apr. 1987.
FRANK, A U., EGENHOFER, M. J. Computer Cartography For GIS: An Object-
Oriented View On The Display Transformation. Computers & Geosciences, 
Oxford, v. 18, n. 8, p. 975-987, 1992.
GRAHAM, I. Object Oriented Methods. Addison-Wesley: Wokingham, 
England, 1994.
GUEDES, G. T. A. Uml 2: Uma Abordagem Prática. 2. ed. São Paulo: Novatec, 
2011. 
______. Uml 2: Guia Prático. São Paulo: Novatec, 2007. 
HAMILTON, K.; MILES, R. Learning UML 2.0. O’Reilly, 2006. 
HERRING, J. A Data Model For An Object-Oriented Geographic Information 
System. Computers 
& Geosciences, Oxford, v. 18, n. 4, p. 443-452, 1992.
LARMAN, C. Utilizando UML e padrões. 3. ed. Porto Alegre: Bookman, 2007. 
154
MANHANI, D. M. da S.; SCHIMIGUEL, J. Ferramentas case para modelagem 
de banco de dados. Codificando .net e-magazine. Rio de Janeiro, ano 4, v. 14, 1º 
fev. 2010. 
MARTINS, D. M. S. et al. Projeto de software com astah*. Engenharia de 
software magazine. Rio de Janeiro, ano 3, v. 30, 11 mar. 2010. 
MELO, A. C. Desenvolvendo Aplicações com UML 2.2. 3. ed. Rio de Janeiro: 
Brasport, 2011. 
PIVA, G. D. Análise e Gerenciamento de Dados. Manual de Informática 
Centro Paula Souza, v. 3, São Paulo, 2010.
PRIETO R.; FREEMAN, P. Classifying software for reusability. IEEE Software, 
[S. l.], v. l4, n.1, p. 6-16, 1987.
RUMABAUGH, J. E. et al. Object-Oriented Modeling and Design. Englewood 
Cliffs, New Jersey: Prentice Hall, 1991.
SILVA, R. P. e. UML 2 em Modelagem Orientada a Objetos. Florianópolis: 
Visual Books, 2007. 
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Addison Wesley, 
2011. 
SOMMERVILLE, I. Software Engineering. Wokingham, England: Addison-
Wesley, 1989.
TACLA, C. A. ANÁLISE E PROJETO OO E UML 2.0. Apostila: Departamento 
Acadêmico de Informática. Universidade Federal Tecnológica do Paraná, 2010.
TONSIG, S. L. Engenharia de software: Análise e Projeto de Sistemas. 2. ed. Rio 
de Janeiro: Ciência Moderna, 2008.
VIDEIRA, C. A. E. UML, metodologias e ferramentas case. 2. ed. Lisboa: Centro 
Atlântico, 2008. 
ZHANG, H. BJORNERUD, M. A Macintosh Application Program for Simulating 
Shear-Sense Indicators Using Object-Oriented Programming. Computers & 
Geosciences, Oxford, v. 21, n. 3, p. 365-375, 1995.
155
ANOTAÇÕES
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
156
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________