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 parecer