Linguagem de modelagem unificada - UML (NPG1399)

Prévia do material em texto

LINGUAGEM DE MODELAGEM UNIFICADA (UML) 1 
Apresentação ............................................................................................................................ 5 
Aula 1: Paradigma Orientado a objeto ............................................................................... 7 
Introdução ............................................................................................................................. 7 
Conteúdo ................................................................................................................................ 8 
Contextualização ............................................................................................................... 8 
Conceituação do modelo OO ......................................................................................... 8 
Os elementos básicos do modelo OO ........................................................................... 9 
Os pilares do modelo OO ............................................................................................... 10 
Conclusões do modelo OO ........................................................................................... 14 
Conceitos importantes ................................................................................................... 15 
A análise para o desenvolvimento de software ......................................................... 15 
Relacionando a análise e o projeto .............................................................................. 16 
Um breve histórico da UML ........................................................................................... 16 
A UML hoje........................................................................................................................ 17 
Entendendo melhor a UML ............................................................................................ 18 
Principais características da UML ................................................................................. 18 
Os diagramas da atual versão da UML ........................................................................ 19 
Entenda onde começar com a UML ............................................................................ 21 
Implementando a UML ................................................................................................... 22 
O que envolve o processo de desenvolvimento de softwares ............................... 23 
Entenda os processos iterativos ................................................................................... 23 
A UML e os resultados em cada fase ........................................................................... 24 
O fluxo de trabalho entre os diagramas da UML ....................................................... 26 
Atividade proposta .......................................................................................................... 29 
Referências........................................................................................................................... 30 
Exercícios de fixação ......................................................................................................... 31 
Chaves de resposta ..................................................................................................................... 35 
Aula 2: Casos de Uso: Diagrama e especificações ........................................................ 36 
Introdução ........................................................................................................................... 36 
Conteúdo .............................................................................................................................. 37 
Levantamento de requisitos .......................................................................................... 37 
Exemplos dos requisitos a serem levantados............................................................. 38 
Principal finalidade do diagrama de casos de uso .................................................... 38 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 2 
Outra finalidade do diagrama de casos de uso ......................................................... 39 
Elementos do diagrama de casos de uso ................................................................... 39 
Ilustração do diagrama de casos de uso ..................................................................... 40 
Entendendo o ator........................................................................................................... 41 
Identificando atores ........................................................................................................ 43 
Entendendo o caso de uso ............................................................................................ 44 
Identificando casos de uso ............................................................................................ 44 
Atividade proposta ........................................................................................................ 45 
Relacionamentos entre atores ...................................................................................... 49 
Relacionamentos entre casos de uso .......................................................................... 51 
Relacionamentos entre casos de uso – inclusão ...................................................... 52 
Exemplo de inclusão ....................................................................................................... 53 
Relacionamentos entre casos de uso – extensão ..................................................... 54 
Exemplos de extensão .................................................................................................... 54 
Relacionamentos entre casos de uso – generalização ............................................ 56 
Exemplo de generalização ............................................................................................. 57 
A importância da especificação de casos de uso ...................................................... 57 
Os formatos para especificar casos de uso ................................................................ 58 
Diferenciando os três tipos de especificação ............................................................. 59 
O formato resumido ....................................................................................................... 60 
O formato informal ......................................................................................................... 60 
O formato completo ....................................................................................................... 61 
Como especificar casos de include.............................................................................. 65 
Especificação do caso "incluir dependente" ............................................................... 65 
Como especificar casos de extends ............................................................................. 66 
Especificação do caso “registrar devolução de DVD” ............................................... 67 
Considerações finais sobre especificações ................................................................ 68 
Dicas sobre especificações de casos de uso .............................................................. 69 
Quadro comparativo entre ações do ator e do sistema .......................................... 70 
Referências........................................................................................................................... 71 
Exercícios de fixação ......................................................................................................... 72 
Chaves de resposta .....................................................................................................................77 
Aula 5: Linguagem unificada de modelagem ................................................................ 79 
Introdução ............................................................................................................................... 79 
Conteúdo .............................................................................................................................. 80 
Conceitos do diagrama de classes ............................................................................... 80 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 3 
Finalidades do diagrama de classes ............................................................................. 80 
A evolução do diagrama de classes ............................................................................. 80 
Principais classes .............................................................................................................. 81 
Diagrama de classes de implementação .................................................................... 82 
A classe .............................................................................................................................. 82 
Classe e objeto ................................................................................................................. 83 
Visão geral do diagrama de classes e seus elementos ............................................. 84 
Classes com seus atributos e operações .................................................................... 85 
Conceito de método ....................................................................................................... 86 
Associação entre classes ................................................................................................ 86 
Formas de associação entre classes ............................................................................ 87 
Multiplicidade nos relacionamentos ............................................................................ 89 
Possibilidades da multiplicidade ................................................................................... 91 
A multiplicidade do diagrama de classes .................................................................... 91 
Visibilidade de atributos e métodos ............................................................................. 91 
Possibilidades de visibilidade ......................................................................................... 92 
Diretrizes relevantes sobre visibilidade ....................................................................... 93 
Outros relacionamentos entre classes ........................................................................ 93 
Classe de associação ....................................................................................................... 94 
Generalização/especialização ....................................................................................... 95 
Diferenciando agregação e composição .................................................................... 98 
Composição ...................................................................................................................... 98 
Agregação ......................................................................................................................... 99 
Dependência ................................................................................................................... 101 
Nome e papel de um relacionamento ...................................................................... 102 
Navegabilidade nos relacionamentos de Associação ............................................ 103 
Notas e comentários no diagrama de classes e UML ............................................. 104 
Atividade proposta ........................................................................................................ 105 
Referências......................................................................................................................... 108 
Exercícios de fixação ....................................................................................................... 109 
Chaves de resposta ................................................................................................................... 113 
Aula 6: Diagramas de interação e diagrama de transição de estados .................. 115 
Introdução ......................................................................................................................... 115 
Conteúdo ............................................................................................................................ 116 
Diagramas de interação................................................................................................ 116 
O tripé da análise ........................................................................................................... 117 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 4 
O diagrama de sequência ............................................................................................ 119 
O diagrama de sequência e seus elementos ........................................................... 122 
Decisões e repetições no diagrama de sequência .................................................. 123 
Criação de destruição de objetos ............................................................................... 125 
Tipos de mensagens: síncronas e assíncronas ........................................................ 126 
Responsabilidade das classes ...................................................................................... 127 
Atividade proposta ........................................................................................................ 128 
O diagrama de máquina de estados .......................................................................... 131 
Estados, evento e transição ......................................................................................... 131 
O diagrama de estados e seus elementos básicos.................................................. 132 
Detalhando a transição ................................................................................................. 133 
Ações de entrada e saída, transições internas e atividades................................... 134 
Superestados .................................................................................................................. 135 
Passo a passo para construção do DTE..................................................................... 137 
Contribuições do DTE ao diagrama de classes ....................................................... 139 
Referências......................................................................................................................... 140 
Exercícios de fixação ....................................................................................................... 141 
Chaves de resposta ................................................................................................................... 146 
Conteudista ............................................................................................................................... 148 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 5 
Com os sistemas de informação cada vez mais complexos nas organizações, 
torna-se cada vez mais necessário o planejamento e organização prévios para 
desenvolver sistemas de informação. A modelagem de sistemas possibilita que 
pensemos, planejemos e organizemos as soluções antes de implementarmos 
(programação) o software. Ou seja, definir o escopo do problema, entender e 
modelar os requisitos dos usuários, definir como resolver o problema, que 
tecnologias usar, o que programar, que técnicas usar, comotestar, são 
necessidades que antecedem a programação. Além disso, a modelagem ganha 
relevância também na medida em que possibilita que os membros da equipe de 
desenvolvimento possam se comunicar entre si e com os usuários, através de 
diagramas (desenhos) padronizados. 
 
Dentro do contexto da orientação a objetos, a linguagem de modelagem 
unificada (UML) tornou-se mundialmente aceita para a documentação de 
projetos de software. A UML é independente de tecnologia e de processo de 
desenvolvimento de software, ou seja, ela define os diagramas com respectivas 
finalidades e elementos, porém não define quais e em que ordem os diagramas 
devem ser usados durante o processo de desenvolvimento de software. Cada 
empresa pode adequar o uso da UML dentro de seus processos de 
desenvolvimento de software. 
 
A UML oferece uma gama de diagramas em várias visões do processo de 
desenvolvimento de software; por exemplo, oferece diagrama para 
levantamento de requisitos junto aos usuários, outro modelo para captar os 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 6 
objetos do domínio do problema e os relacionamentos entre eles, outro para 
mostrar as interações entre os diferentes objetos na realização das 
funcionalidades que o sistema terá. Dispõe ainda de diagramas que mostram 
como será a solução física através de componentes, como o hardware integrará 
a solução e outros diagramas com diferentes objetivos. 
 
Sendo assim, essa disciplina tem como objetivos: 
 
1. Proporcionar conhecimento dos conceitos de análise e projeto orientado a 
objetos, com seus pilares de embasamento teórico. 
2. Apresentar os principais diagramas da UML, com seus respectivos objetivos e 
elementos. 
3. Capacitar os profissionais a modelarem sistemas usando os diagramas da 
Linguagem de Modelagem Unificada (UML), sob a perspectiva da orientação a 
objetos. 
4. Proporcionar conhecimento sobre o fluxo de trabalho e resultados das fases 
de: análise de requisitos, análise e projeto do sistema. 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 7 
Introdução 
A modelagem de sistemas consiste na criação de modelos (diagramas) capazes 
de representar o mundo real, sob a perspectiva do desenvolvimento de 
sistemas e está intimamente relacionado a dois fatores: ao paradigma de 
desenvolvimento e ao processo de desenvolvimento em uso. 
 
Um sistema desenvolvido sob o paradigma da orientação a objetos representa 
os objetos que encontramos no mundo real, relacionados ao problema que 
estamos tratando, no negócio para o qual estamos desenvolvendo o sistema. O 
foco da equipe de desenvolvimento passa a ser a identificação e modelagem 
dos objetos do mundo real que afetam o sistema. 
 
A orientação a objetos está balizada em três princípios fundamentais, o 
encapsulamento que protege o acesso aos atributos, a herança e o 
polimorfismo. Juntos, eles permitem que classes sejam reaproveitadas, 
otimizando tempo e custo de desenvolvimento, além da segurança no reuso de 
classes já usadas e testadas. 
 
Preparado para iniciar a aula? 
Bons estudos! 
 
 
 
 
Objetivos: 
1. Fundamentar as principais características e os pilares do paradigma 
orientado a objeto; 
2. Discutir os principais conceitos inerentes à Linguagem de Modelagem 
Unificada. 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 8 
Conteúdo 
 
Contextualização 
 
Quando modelamos sistemas usando o paradigma orientado a objeto a tarefa 
passa a ser a identificação dos objetos do mundo real envolvidos no contexto 
do sistema e a relação entre esses objetos. Por exemplo, considerando o 
contexto de um sistema bancário (ilustrado pela imagem a seguir), podemos 
citar os objetos agencia, cliente e conta, e a relação “Cliente possui uma conta 
em uma agencia”. Ao identificar os objetos, são identificados também os dados 
(atributos) e as funcionalidades (funções) inerentes àquele objeto, conforme 
ilustrado na imagem abaixo. O objeto Cliente possui os dados Nome, Endereço, 
Telefone e CPF e sobre ele podem ser realizadas, por exemplo, as funções de 
Incluir Novo Cliente, Excluir Cliente Inativo, Inativar Cliente. 
 
OBJETO = DADOS + FUNÇÕES 
 
Conceituação do modelo OO 
Na medida em que são identificados todos os objetos pertinentes a um sistema, 
já teremos os dados e procedimentos relacionados. 
 
Um modelo Orientado a Objeto (OO) tem como entidade fundamental o 
objeto, que recebe e envia mensagens, executa procedimentos e possui um 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 9 
estado que, por proteção, apenas o próprio objeto pode modificar. Problemas 
são resolvidos por meio de objetos, que enviam mensagens uns aos outros. 
 
 
Os elementos básicos do modelo OO 
Um modelo OO é formado por alguns elementos básicos. São eles: 
 
OBJETO 
É o principal elemento do modelo OO. Os objetos representam as “coisas” a 
serem modeladas do mundo real. Um objeto pode ser algo concreto como um 
carro, um aluno ou algo abstrato como uma disciplina. Cada objeto possui os 
dados inerentes a ele, como por exemplo, Nome (José) e Matrícula 
(201101272201) de um aluno e possui as operações que ele executa, como 
incluir novo aluno ou alterar dados de um aluno existente. 
 
MENSAGENS 
As mensagens são enviadas entre os objetos. Quando um objeto deseja que 
seja executada uma operação, da responsabilidade de outro objeto, ele manda 
uma mensagem a esse outro objeto informando o que ele deseja que seja feito. 
A operação desejada será implementada por meio de um método. 
 
ATRIBUTOS 
São dados que caracterizam o objeto. 
 
MÉTODOS 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 10 
São procedimentos (implementados por uma rotina ou função) que executam 
uma operação em um objeto e definem parte de seu comportamento. 
 
CLASSES 
São conjuntos de objetos com as mesmas características (atributos e métodos). 
Por exemplo, os objetos IX35 e Sportage são objetos da classe CARRO, cujas 
características em comuns são: 
• Atributos: modelo, fabricante, ano de fabricação, portas, entre outros. 
• Métodos: incluir carro, vender carro etc. 
 
Atenção 
 Aqui, um exemplo da diferença entre o conceito de classes e 
de objetos. Ou seja, é habitual dizermos que o “objeto é uma 
instância de uma classe”, logo, a classe é o molde e o objeto a 
“coisa real”. 
 
 
 
Os pilares do modelo OO 
Dentre as principais características do paradigma orientado a objeto (OO), 
destacamos: 
 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 11 
ENCAPSULAMENTO 
Encapsular significa esconder, ou seja, o objeto esconde seus dados (atributos) 
do acesso indevido de outros objetos e somente permite que eles sejam 
acessados por operações implementadas pelos seus próprios métodos 
(funcionalidades que implementam o comportamento do objeto). Com isso, o 
encapsulamento protege os dados do objeto do uso arbitrário ou não 
intencional, o que pode ser visualizado na figura apresentada aqui. O 
encapsulamento é uma técnica para minimizar a interdependência entre as 
classes, pois apenas os métodos da respectiva classe podem alterar seus dados 
(atributos), facilitando a identificação de erros e a alteração dos programas. 
 
 
HERANÇA 
Trata-se de um mecanismo para derivar novas classes a partir da definição de 
classes existentes, que se dá por meio de um processo de refinamento. Uma 
classe derivada ou descendente herda os dados (atributos) e comportamento 
(métodos) da classe base ou ancestral ou ascendente. A implementação da 
herança garante a reutilização de código que, além de economizar tempo e 
dinheiro, propicia mais segurança ao processo de desenvolvimento, postoque 
as funcionalidades da classe base já foram usadas e testadas. 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 12 
 
Conforme ilustrado na figura abaixo, as classes Conta Poupança e Conta 
Investimento herdam da classe Conta, os atributos e métodos que são 
permitidos. A classe Conta é chamada Classe base, uma vez que é a base da 
herança. 
 
 
POLIMORFISMO 
A palavra polimorfismo deriva do grego e significa “muitas formas”. A partir do 
momento em que uma classe herda atributos e métodos de uma (herança 
simples) ou mais (herança múltipla) classes base, ela tem o poder de alterar o 
comportamento de cada um desses procedimentos (métodos). Isso amplia o 
poder do reaproveitamento de código promovido pela herança, permitindo que 
se aproveite alguns métodos e se altere (redefina) outros. Dessa forma, um 
método com mesmo nome, em classes distintas, pode ter diferentes 
comportamentos. Acompanhe o exemplo da figura apresentada aqui, onde 
identificamos a seguinte herança: Pagamento em Dinheiro, Pagamento em CC 
(Cartão de crédito) e Pagamento em Cheque herdam da classe Pagamento o 
atributo valor e o método Pagar. Observe que em cada classe filha (Pagamento 
em Dinheiro, Pagamento em Cartão e Pagamento em Cheque) escreve-se 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 13 
novamente o método Pagar. Essa possibilidade ocorre pelo princípio do 
encapsulamento. 
 
VISIBILIDADE 
Outro conceito fundamental é a visibilidade entre as classes. Esta diz respeito 
ao que uma classe pode visualizar da outra. Como princípio devemos garantir o 
encapsulamento, ou seja, os atributos devem ser privados (acessíveis apenas 
por métodos da própria classe) e determinados métodos públicos (acessíveis 
por todas as classes) devem acessar esses dados. Por outro lado, se 
mantivermos todos os métodos como privados, a classe perde o sentido, pois 
nenhuma outra poderá usar seus métodos. Então, devemos usar a visibilidade 
com equilíbrio e sabedoria. Outra visibilidade possível, além da privada e da 
pública, é a protegida, onde os atributos e métodos somente podem ser vistos 
dentro da estrutura de herança, ou seja, pelas classes filhas. Na figura abaixo o 
atributo Valor e o método Pagar_Conta (Valor : int) da classe Pagamento 
somente podem ser acessados pelas classes Pagamento em Dinheiro, 
Pagamento por Cartão e Pagamento em Cheque. 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 14 
 
Conclusões do modelo OO 
O modelo Orientado a Objeto surgiu (na década de 80) como um modelo 
promissor para o desenvolvimento de software mais confiável, devido às 
características inerentes ao modelo de objetos. São elas: 
 
• O conceito de encapsulamento, que permite a construção de classes 
independentes umas das outras, facilitando o desenvolvimento e a manutenção 
do software (alterações e melhorias na classe); 
• A herança e o polimorfismo, que permitem e facilitam a reutilização de 
código, úteis nas fases de implementação e manutenção. 
 
O uso de técnicas orientadas a objetos facilita o controle da complexidade, uma 
vez que promove uma melhor estruturação de seus componentes e também 
permite que componentes já usados e validados possam ser reaproveitados. 
 
Cabe ressaltar que uma das principais razões para a baixa produtividade no 
desenvolvimento de software é a dificuldade de reutilização de código usando o 
paradigma funcional. As hierarquias de classes (herança) são componentes 
portáveis entre aplicações, que se bem projetados podem ser reutilizados em 
vários sistemas, sem modificação, e, além disso, podem ser estendidos 
(polimorfismo) sem corromper o que já existe. 
 
Assim sendo, podemos dizer que o modelo de objetos proporciona 
modularidade, trazendo os seguintes benefícios: 
• Reusabilidade: softwares podem ser escritos com base em componentes já 
existentes; 
• Extensibilidade: novos componentes de software podem ser desenvolvidos 
a partir de outros já existentes sem afetar o comportamento do componente de 
origem. 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 15 
Sabe-se que softwares são intrinsecamente complicados devido aos novos 
requisitos das aplicações modernas: alta confiabilidade, alto desempenho, 
desenvolvimento de software rápido e barato, alta complexidade e tamanhos 
grandes. 
 
O modelo OO veio para combater os problemas derivados da Crise do Software, 
termo cunhado em 1968, na Europa, e caracterizado pelos seguintes problemas 
do software: baixa confiabilidade, baixa qualidade, alto custo de manutenção e 
duplicação de esforços na sua construção (tempo e dinheiro). 
 
Um sistema desenvolvido com as características do modelo OO tende a ser bem 
estruturado, posto que os objetos são unidades coesas dotados de interfaces 
simples que escondem as suas implementações. 
 
Conceitos importantes 
A orientação a objetos enfatiza a identificação, representação e 
organização dos objetos necessários a um sistema. 
Antes de adentrarmos no universo da análise e do projeto, sob o enfoque do 
paradigma Orientado a Objeto, vamos tecer rápidos comentários acerca do que 
sejam as atividades de análise e projeto, dentro do contexto de 
desenvolvimento de software. 
 
A análise para o desenvolvimento de software 
Análise de sistemas significa uma investigação dos problemas e dos requisitos 
de um contexto, em particular, com vistas ao desenvolvimento de um sistema 
automatizado. A ideia básica seria identificar quais seriam as funções que esse 
sistema precisa ter, de forma a atender eficientemente as necessidades de seus 
usuários. 
 
A atividade de análise, por ser muito abrangente, costuma ser dividida em 
análise de requisitos (investigação dos requisitos) e análise do domínio do 
problema. 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 16 
 
Relacionando a análise e o projeto 
A atividade de projeto denota uma solução, voltada ao atendimento dos 
requisitos, considerando aspectos de tecnologia. Em geral, o projeto enfoca a 
arquitetura do sistema, definindo suas partes e as relações entre elas. 
A análise pode ser traduzida em “faça a coisa certa” e o projeto em “faça 
certo a coisa”. 
 
No contexto específico da orientação a objetos, análise implica em identificar e 
descrever os conceitos, no domínio do problema. Já na atividade de análise, 
foca-se na definição dos objetos de software e como eles colaboram para que 
os requisitos dos usuários sejam plenamente satisfeitos. 
 
Um breve histórico da UML 
A partir deste ponto, você iniciará com o assunto central de nossa disciplina, a 
Linguagem de Modelagem Unificada (UML). 
 
A Linguagem de Modelagem Unificada (UML) nasceu da integração de três 
métodos emergentes orientados a objeto que, na década de 90, eram os mais 
populares entre os profissionais de desenvolvimento de sistemas: 
 
• O Método OMT (Object Modeling Technique) de Jacobson; 
• O Método OOSE (Object-Oriented Software Engineering) de Rumbaugh; 
• O Método de Booch. 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 17 
 
A UML hoje 
Finalmente, em 1997, a UML foi adotada pela OMG (Object Management Group 
ou Grupo de Gerenciamento de Objetos), como uma linguagem padrão de 
modelagem. 
 
Atualmente A UML encontra-se em sua versão 2.0 (2.4.1, já existindo a 2.5 em 
release BETA) e trouxe grandes novidades em relação à estrutura geral da 
linguagem. Entre as principais se encontram a abordagem de quatro 
camadas e a possibilidade de se desenvolver “perfis” particulares 
(oficial no site da OMG em http://www.uml.org) 
 
Desde a versão inicial a UML sofreu mudanças substanciais. 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 18 
 
Entendendomelhor a UML 
A UML (Unified Modeling Language) é uma linguagem padrão para construção 
de projetos de sistemas, voltada para a visualização, especificação, construção 
e documentação de artefatos de um sistema. A UML foi projetada para ser 
independente do método de desenvolvimento a ser utilizado. 
 
A UML é uma linguagem de modelagem. Não se trata de um método de 
desenvolvimento, nem tampouco de uma metodologia ou de um processo de 
desenvolvimento de sistemas. Isso porque ela não determina a ordem e nem 
como os diagramas devem ser usados. A UML simplesmente disponibiliza os 
diagramas, sob as várias visões necessárias ao desenvolvimento de sistemas. 
 
Cada empresa utiliza-a da forma como lhe convém, ou seja, adequando a 
linguagem ao seu processo de desenvolvimento de sistema. 
 
Principais características da UML 
A UML é uma linguagem destinada à: 
 
Visualização: a modelagem gráfica tende a facilitar a compreensão, 
permitindo sua interpretação sem ambiguidades. 
 
Especificação: permite a construção de modelos precisos, completos e sem 
ambiguidades. A UML atende a esses quesitos sob o ponto de vista da análise, 
do projeto e da implementação. 
 
Construção: os diagramas UML podem ser diretamente integrados a várias 
linguagens de programação tais como Java e C++. 
 
Documentação: a UML abrange a documentação da arquitetura do sistema e 
de todos os seus detalhes. 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 19 
Os diagramas da atual versão da UML 
Os diagramas da UML são divididos em 2 grupos: 
1. Diagramas de Estruturas; 
2. Diagramas de Comportamentos. 
Os diagramas somam um total de 14, conforme demonstra a imagem a seguir. 
 
 
Veja a especificação de cada um dos diagramas da UML: 
 
Diagrama Especificação 
Diagrama de Perfil Diagrama mais recente e bastante abstrato. Permite a 
criação de perfis que adapte a UML a plataformas, 
tecnologias ou domínios específicas, para os quais a 
linguagem não foi projetada originalmente. 
Diagrama de Classes O mais popular dos diagramas. Tem muitas 
informações, mas a principal finalidade é apresentar 
os tipos de objetos presentes no sistema e os vários 
tipos de relacionamentos existentes entre eles. 
Descreve para cada classe suas propriedades 
(atributos e métodos). 
Diagrama de Abrange um novo conceito, criado com a UML 2.0, 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 20 
Estruturas Compostas que é a capacidade de decompor hierarquicamente 
uma classe. 
Diagrama de 
Componentes 
Apresenta diferentes componentes de um sistema, 
além de possíveis dependências entre eles. O conceito 
de componente diz respeito a uma parte física de um 
sistema de componente, englobando outras estruturas 
relacionadas (como classes, interfaces etc.). 
Diagrama de 
Implantação 
Determina o ambiente físico sobre o qual o sistema vai 
operar. Determina as necessidades de hardware do 
sistema, evidenciando características físicas dos 
servidores, estações, protocolos de comunicação, 
redes etc. 
Diagrama de Objetos É um diagrama de classes, instanciado, ou seja, 
mostra exemplos de objetos de cada classe, 
mostrando os relacionamentos. 
Diagrama de Pacotes Pacotes são elementos que englobam outros. O mais 
comum são classes, mas têm sido usados para outros 
elementos, especialmente casos de uso. Representam 
a divisão de um sistema grande em partes menores 
(modularização). 
Diagrama de 
Atividades 
Descrevem a lógica de procedimentos, processos de 
negócios e fluxos de trabalho, suportando 
processamento sequencial e paralelo. 
Diagrama de Casos de 
Uso 
Mostra as funcionalidades do sistema e os atores que 
com elas interagem. 
Diagrama de Estados Mostra, para cada objeto do sistema, o 
comportamento do seu ciclo de vida. 
Diagrama de 
Sequência 
Mostra como os objetos interagem para a realização 
de um caso de uso, detalhando a troca de mensagem 
entre os objetos. 
Diagrama de São os antigos Diagramas de Colaboração, que junto 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 21 
Comunicação com o Diagrama de Sequência forma os diagramas de 
interação. Tem a mesma finalidade do diagrama de 
sequência, porém não focam a temporalidade 
(sequência). 
Diagrama de Visão 
Geral de Interação 
Novidade da versão 2.0. Misturam num único 
diagrama conceitos e elementos do diagrama de 
Atividades e do Diagrama de Sequência. 
Diagrama de Tempo Novidade da versão 2.0. Outro tipo de Diagrama de 
Interação, onde o foco está nas restrições de 
temporização. Usado para demonstrar a mudança no 
estado de um objeto no tempo em resposta a eventos 
externos. 
 
 
Entenda onde começar com a UML 
Nem mesmo os idealizadores da UML conseguem usar todos os diagramas. 
Geralmente as empresas escolhem um subconjunto deles e implementam nas 
fases de seus processos de desenvolvimento de sistemas. O ideal é que você 
encontre o seu conjunto de diagramas que funcione para o tipo de sistema que 
desenvolve. 
 
Como a UML não determina quais diagramas usar e por onde começar, cada 
um pode começar por onde desejar. Por exemplo, muitos começam pelo 
Diagrama de Classes, na medida em que o consideram o mais relevante. 
Porém, muitos começam pelo Diagrama de Casos de Uso, cuja finalidade é 
modelar as principais funcionalidades do sistema para atender às necessidades 
de seus usuários. 
 
Ambos estão usando a UML de forma correta e expressando a forma como 
visualizam a sequência mais adequada para desenvolver sistemas. 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 22 
 
 
Implementando a UML 
Martin Fowler e Steve Mellor propuseram três modos para se usar a UML no 
desenvolvimento de sistemas. 
 
UML como esboço – o modo mais usado, onde os desenvolvedores usam a 
UML como forma de expressar aspectos relevantes de um sistema, esboçando 
ideias e alternativas do que se pretende fazer. É uma possibilidade de discussão 
com a equipe de desenvolvedores. Seu foco é a comunicação seletiva em vez 
de especificação completa. Geralmente são usados desenhos informais, sem 
ferramentas e cujo foco é a discussão de ideias visando à construção de 
software de forma colaborativa. 
 
O modo UML como esboço está mais compatível com as metodologias ágeis, 
que preconizam mais código e menos documentação. 
 
UML como projeto – foca a completeza. Aqui a ideia é construir um projeto 
completo para ser codificado por programadores, valendo-se de ferramentas 
CASE para melhor entendimento dos modelos, pela equipe. 
O modo UML como projeto está mais alinhado com os processos de 
desenvolvimento mais complexos, como processos iterativos e incrementais, 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 23 
como o PU (processo unificado) implementado através da ferramenta RUP 
(Rational Unifiec Process). 
Obs.: Será esse o tipo de UML abordado em nossas aulas! 
 
UML como linguagem de programação – onde os desenvolvedores 
desenham os diagramas que são compilados para o código executável e a UML 
se torna o código-fonte. Exige ferramentas mais sofisticadas. 
Por fim, o modo UML como linguagem de programação tende a ser mais usado 
em modelos de desenvolvimento de prototipação. 
 
O que envolve o processo de desenvolvimento de softwares 
Um processo de desenvolvimento de software descreve a abordagem para 
organizar as atividades relacionadas com a construção, implantação e 
manutenção de sistemas. 
 
Os processos mais populares hoje são os iterativos, como o PU (Processo 
Unificado), em particular o RUP (Processo Unificado da Rational) e as 
metodologias ágeis, como o XP (eXtreming Programming) e SCRUM. 
 
Entendaos processos iterativos 
Mas o que são processos iterativos, afinal? São processos onde o ciclo de vida 
do sistema é dividido em uma série de miniprojetos, curtos, preferencialmente 
de duração fixa (por exemplo 3 meses), denominados iterações. Cada iteração 
contém um subconjunto das funcionalidades do sistema. 
Em cada iteração temos as atividades de levantamento de requisitos, análise de 
requisitos, projeto, implementação, testes e implantação, conforme ilustrado 
pela imagem a seguir. 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 24 
 
O ciclo de vida iterativo é baseado em incrementos sucessivos do sistema, pelas 
iterações do processo. A cada iteração um pedaço do software é incrementado, 
daí o nome processo iterático e incremental. 
Claro que entre um incremento e outro teremos feedbacks e ajustes na iteração 
encerrada. 
 
 
Atenção 
 Como já mencionado, a UML não define um processo padrão. 
Seus autores reconhecem que uma linguagem de modelagem 
e um processo robusto são importantes. Eles ofereceram sua 
orientação sobre o que constitui um processo adequado em 
publicações separadas daquelas exclusivamente dedicadas à 
UML, porque a padronização de um processo estava fora do 
escopo da definição de UML. 
 
A UML e os resultados em cada fase 
Usar a UML em um processo de desenvolvimento de sistemas não implica, 
necessariamente, na elaboração de documentos ou uso de uma ferramenta 
CASE. Muitas equipes usam UML para desenhos à mão em reuniões, para 
discussão de ideias. 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 25 
Veja, a seguir, uma proposta de fluxo de trabalho e os resultados em cada fase, 
usando a UML em um processo iterativo. 
 
Levantamento de requisitos 
• Diagrama de Casos de Uso, para identificação, informal, dos requisitos e 
funcionalidades do sistema; 
• Diagrama de Classes Conceitual, de alto nível, com modelagem apenas das 
classes, com, talvez, os atributos mais relevantes. 
 
Análise de Requisitos 
• Casos de uso, que descrevem como as pessoas interagem com o sistema; 
• Diagrama de Classes Conceitual; 
• Diagrama de Estados, caso seja necessário elucidar algum ciclo de vida de um 
objeto relevante para o sistema; 
• Diagrama de Atividades, com algum fluxo de trabalho relevante, ou um caso 
de uso mais complexo. 
 
Projeto 
• Diagrama de Classes, já a partir de uma perspectiva de software; 
• Diagrama de Sequência, para cenários relevantes e comuns; 
• Diagrama de Estados; 
• Diagrama de Componentes, com a arquitetura do software; 
• Diagrama de Implantação, para definição do ambiente físico e distribuição dos 
componentes. 
 
 
 
 
 
 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 26 
 
Atenção 
 Nas duas fases primeiras fases (levantamento de requisitos e 
análise de requisitos), o aspecto mais relevante é a efetiva 
comunicação com os usuários e com a equipe de 
desenvolvimento. 
 
Conforme já mencionado, a UML não define uma ordem para 
elaboração de cada um de seus diagramas. Cada um usa os 
diagramas da UML da forma como deseja e dentro do processo 
de desenvolvimento considerado mais adequado à sua equipe 
e estilo de desenvolvimento, como ficou sinalizado nesta tela, 
quando identificamos os diagramas que podem (devem) ser 
modelados em cada fase de qualquer processo de 
desenvolvimento de software. 
 
O fluxo de trabalho entre os diagramas da UML 
Nossa proposta de uso da UML para esta disciplina é: 
 
Aula 2 
 
1. Modelo de Casos de Uso (aula 2): 
• Levantamento e identificação dos requisitos do sistema; 
• Construção do Diagrama de Casos de Uso; 
• Elaboração das descrições textuais de cada caso de uso. 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 27 
 
Aula 5 
 
2. Modelo Conceitual de Classes (Aula 5): 
• Com base nos casos de uso, identificar os atores e as classes, elaborando a 
primeira versão do Modelo Conceitual de Classes; 
• Identificação dos relacionamento entre as classes; 
• Refinar o Modelo Conceitual de Classes. 
 
 
 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 28 
Aula 6 
 
3. Diagrama de Sequência (Aula 6): 
• Com base nas especificações no Diagrama de Casos de Uso, bem como no 
Diagrama Conceitual de Classes, elaborar o Diagrama de Sequência para cada 
cenário de uso, em cada caso de uso relevante; 
• Alterar os Modelos de Casos de Uso (diagrama e descrições textuais), com 
novas funcionalidades ou visões mais apropriadas das funcionalidades já 
existentes; 
• Alterar os modelos de classes, com a inserção de novos métodos para classes 
existentes e até de novas classes. 
 
4. Diagrama de Estados (Aula 6): 
• Para toda classe com mais de 1 estado, elaborar o modelo base do Diagrama 
de Transição de Estados; 
• Refinar o Modelo de Estados; 
• Proceder a eventual alteração no modelo de classes, com alterações em 
métodos ou atributos das classes propostas. 
 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 29 
Atividade proposta 
Imagine a seguinte cena. Um gerente está em sua mesa, trabalhando, quando 
se aproxima outra pessoa e se apresenta: 
– Bom dia, sou o Analista de Sistemas que veio fazer o trabalho encomendado. 
Ele continua – que conjunto de atividades são desenvolvidas nesse 
departamento? 
O gerente responde: 
– Bem, nós fazemos a liberação de pagamento de notas fiscais, o controle das 
notas fiscais em relação aos pedidos e o controle de estoque com os itens 
descritos na nota fiscal. 
O analista pergunta: 
– Quem faz a liberação dos pagamentos de notas fiscais? 
O empresário: 
– A secretária, dona Sílvia. – e chama a dona Sílvia para maiores 
esclarecimentos. 
Entrevistando dona Sílvia, o analista pergunta, para completar : 
– Dona Sílvia, o que faz a senhora iniciar o seu trabalho? 
Ela responde: 
– Quando chega uma nota fiscal carimbada pelo pessoal do estoque. 
– Dona Sílvia, quando encerra o seu trabalho? – pergunta o analista. 
– Meu trabalho encerra quando gero a guia de liberação de pagamento. – 
responde Dona Sílvia. 
 
Com base no texto acima, identifique as funcionalidades que o sistema precisa 
ter para atender às necessidades do gerente e da Dona Sílvia. 
 
Chave de resposta: As funcionalidades são: liberar pagamento, gerir notas 
fiscais e controlar estoque. 
 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 30 
Referências 
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com 
UML, 2/E. 2. ed. Rio de Janeiro: Campus, 2006. cap. 1. 
 
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML - guia do usuário. 2. ed. Rio 
de Janeiro: Elsevier, 2005. cap. 1 e 2. 
 
FOWLER, M. UML Essencial. Um breve guia para a linguagem-padrão de 
modelagem de objetos. 3. ed. Porto Alegre, RS: Artmed, 2005. 
 
 
 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 31 
 
Exercícios de fixação 
Questão 1 
Como se chama o princípio que diz que o acesso aos atributos de uma classe 
deve ser somente pelos métodos da classe e não diretamente por outra classe? 
a) Encapsulamento 
b) Herança 
c) Polimorfismo 
d) Entropia 
e) Visibilidade 
 
Questão 2 
No que se refere aos conceitos de Herança e Polimorfismo, analise as sentenças 
a seguir: 
I – A herança garante reuso e consequente economia de tempo e dinheiro. 
II – O polimorfismo diz que os atributos devem ter visibilidade privada. 
III – Sem herança não há como ter polimorfismo. 
IV – O encapsulamento visa garantir o desenvolvimento de classes 
independentes. 
Com base em sua análise, assinale a assertiva correta: 
a) Estão corretas apenas I, III e IV. 
b) Estão corretas apenas I e III. 
c) Estão corretasI, II, III e IV. 
d) Estão corretas apenas I e IV. 
e) Está correta apenas a III. 
 
Questão 3 
Quando um objeto se comunica com outro, ele envia ao destino: 
a) Uma mensagem 
b) Uma herança 
c) Um atributo 
d) Um método 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 32 
e) Um sinal 
 
Questão 4 
A propriedade que prega que novos componentes de software podem ser 
desenvolvidos a partir de outros, já existentes, sem afetar o comportamento do 
componente de origem, se relaciona: 
a) À herança 
b) Ao polimorfismo 
c) À reusabilidade 
d) À extensibilidade 
e) Ao atributo 
 
Questão 5 
Marque a alternativa com a qual a atividade de análise se relaciona: 
a) Faça a coisa certa. 
b) Faça certo a coisa. 
c) Faça sempre o melhor. 
d) Faça a coisa. 
e) Faça com cuidado. 
 
Questão 6 
No que se refere à UML (Linguagem Unificada de modelagem), assinale a única 
alternativa INCORRETA: 
a) É independente de processo de desenvolvimento de software. 
b) Contém um conjunto de diagramas com diferentes visões. 
c) É voltada especificamente para a modelagem de requisitos. 
d) Destina-se à visualização, especificação, construção e documentação de 
sistemas orientados a objeto. 
e) Nasceu da união de métodos usados, na época, pelos principais profissionais do 
mercado. 
 
Questão 7 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 33 
Como se chama o diagrama que mostra as funcionalidades do sistema e os 
atores que com elas interagem? 
a) Diagrama de Classes 
b) Diagrama de Estados 
c) Diagrama de Casos de Uso 
d) Diagrama de Componentes 
e) Diagrama de Sequência 
 
Questão 8 
Assinale a opção que apresenta o diagrama da UML que mostra o 
comportamento do ciclo de vida de cada objeto: 
a) Diagrama de Estado 
b) Diagrama de Classes 
c) Diagrama de Colaboração 
d) Diagrama de Objetos 
e) Diagrama de Implantação 
 
Questão 9 
Sobre os modelos de desenvolvimento de software dito interativos, analise as 
assertivas. 
I – São processos onde o ciclo de vida do sistema é dividido em uma série de 
miniprojetos e de curta duração. 
II – Cada iteração contém um subconjunto das funcionalidades do sistema. 
III – Em cada iteração temos as atividades de levantamento de requisitos, 
análise de requisitos, projeto, implementação, testes e implantação. 
IV – São modelos ultrapassados e pouco adequados para uso da UML. 
Com base nas assertivas, assinale a única alternativa CORRETA: 
a) Estão corretas apenas I, II e III. 
b) Estão corretas apenas I e II. 
c) Estão corretas I, II, III e IV. 
d) Estão corretas apenas II e IV. 
e) Estão corretas apenas I, III e IV. 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 34 
 
Questão 10 
Durante a fase de análise de requisitos e análise do sistema, pode ser 
necessária a modelagem de algum fluxo de trabalho relevante, ou um caso de 
uso mais complexo. Nesse caso, qual diagrama da UML é o mais indicado? 
a) Diagrama de Atividades 
b) Diagrama de Estados 
c) Diagrama de Comunicação 
d) Diagrama de Implantação 
e) Diagrama de Componentes 
 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 35 
Aula 1 
Exercícios de fixação 
Questão 1 - A 
Justificativa: O encapsulamento garante a inviolabilidade dos métodos e 
consequentemente do estado de um objeto. Apenas métodos da própria classe 
podem acessar seus atributos, garantindo a proteção dos dados. 
 
Questão 2 - A 
Justificativa: I – Correta; II – Incorreta, de acordo com o conceito de 
encapsulamento; III – Correta; IV - Correta. 
 
Questão 3 - A 
Justificativa: Os objetos se relacionam por mensagens. 
 
Questão 4 - D 
Justificativa: Estender uma classe significa agregar funcionalidade com base no 
que já existe. 
 
Questão 5 - A 
Justificativa: A atividade de análise compreende “o que fazer”, ou seja, “faça a 
coisa certa”. 
 
Questão 6 - C 
Justificativa: A UML especifica diagramas para modelagem com várias visões, 
em diferentes momentos do processo de desenvolvimento e não apenas na 
modelagem de requisitos. 
 
 
 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 36 
Questão 7 - C 
Justificativa: Os casos de uso retratam as funcionalidades do sistema e como os 
atores interagem com essas funcionalidades. O diagrama que agrupa os casos 
de uso chama-se Diagrama de Casos de Uso. 
 
Questão 8 - A 
Justificativa: O ciclo de vida de um objeto é representado pelos estados que o 
mesmo possui e todas as transições de estados que ocorrem. 
 
Questão 9 - A 
Justificativa: I – Correta, é o conceito de processo iterativo; II – Correta, a ideia 
é justamente dividir as iterações no desenvolvimento de um pedaço do sistema 
III – Correta, em cada iteração há um ciclo completo de desenvolvimento; IV – 
Incorreta, são modelos muito usados hoje e, como já vimos, a UML não está 
voltada para nenhum processo específico, adaptando-se a qualquer modelo. 
 
Questão 10 - A 
Justificativa: O Diagrama de Atividades é útil para descrever a lógica de 
procedimentos, processos de negócios e fluxos de trabalho, suportando 
processamento sequencial e paralelo. Podemos incluir aqui ajuda no 
entendimento de um caso de uso de maior complexidade, cuja lógica pode ser 
mais bem visualizada sob a forma de diagrama. 
Introdução 
O levantamento e mapeamento adequado dos requisitos de um sistema são 
fundamentais para o sucesso do produto final a ser gerado: o software. 
O sistema precisa ter as funções adequadas para satisfazer as necessidades de 
seus usuários. Portanto, durante o processo de desenvolvimento de software, é 
preciso ter cuidado e, se possível, garantias de que os requisitos estão sendo 
corretamente capturados e compreendidos pelos analistas de sistemas. 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 37 
A UML (linguagem unificada de modelagem) disponibiliza para esse fim o 
diagrama de casos de uso, cuja finalidade é mapear as funcionalidades do 
sistema, evidenciando os atores que com elas interagem. 
 
Os casos de uso, ou seja, as funcionalidades do sistema, sendo textualmente 
descritas, servem de base para que o sistema possa atender a essas 
necessidades. 
Preparado para iniciar a aula? 
Bons estudos! 
 
Objetivos: 
1. Apresentar o diagrama de casos de uso, conforme definições da UML; 
2. Demonstrar as formas de especificar os casos de uso. 
 
 
 
Conteúdo 
 
Levantamento de requisitos 
A atividade de levantar requisitos é de fundamental importância para todo o 
processo de desenvolvimento de sistemas. O sucesso do produto final, o 
software que será desenvolvido, depende de um correto levantamento de 
requisitos. 
 
Levantar requisitos implica em sabermos o que o sistema precisa fazer para 
atender as necessidades de seus usuários. A qualidade do levantamento de 
requisitos influenciará todo o processo de desenvolvimento, especialmente as 
validações junto aos usuários, necessárias ao longo do processo de 
desenvolvimento e sobretudo na adequação do software. 
 
O levantamento de requisitos visa identificar dois tipos de requisitos: 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 38 
Requisitos funcionais: são as funções que o sistema precisa ter. 
 
Requisitos não funcionais: são os atributos e propriedades do sistema. 
 
Exemplos dos requisitos a serem levantados 
Requisitos funcionais 
Como exemplos de requisitos funcionais para um sistema de folha de 
pagamento, podemos enumerar: 
 
• Cálculo da folha de pagamento; 
• Cadastramento de funcionários; 
• Cadastramento da tabela de imposto de renda; 
• Emissão do recibo de pagamento, entre outras funções necessárias aosistema. 
 
 
Requisitos não funcionais 
Como exemplos de requisitos não funcionais , que, obviamente, não são 
funções do sistema, podemos citar: 
• Tempo de resposta – o cálculo da folha de pagamento não pode demorar 
mais que 15 segundos; 
• Interface – deve ser composta de janelas de diálogo de fácil entendimento; 
• Tipo de ambiente – o sistema precisa estar acessível 24h por dia, nos 365 
dias do ano, denotando que precisa ser um sistema voltado para a internet. 
 
Principal finalidade do diagrama de casos de uso 
O diagrama de casos de uso é um dos mais informais e simples dentre os 
propostos pela UML. Sua principal finalidade é apresentar as principais 
funcionalidades que o sistema precisa ter; em outras palavras, apresentar os 
requisitos funcionais do sistema. Ou seja, é um diagrama que começa a ser 
usado após o levantamento de requisitos de forma a mapear as funcionalidades 
do sistema, documentar o que o sistema faz. 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 39 
 
Esse diagrama é, geralmente, derivado do documento de especificação de 
requisitos (que não pertence à UML) ou de outro documento que relacione as 
principais necessidades dos usuários do sistema. 
 
 
 
Outra finalidade do diagrama de casos de uso 
Outra finalidade do diagrama de casos de uso é possibilitar que os requisitos 
possam ser validados junto aos usuários para se certificar que: 
• Todos os requisitos funcionais tenham sido identificados; 
• O entendimento da equipe de desenvolvimento, no que tange aos requisitos 
identificados, esteja correto e corresponda à realidade. 
 
Elementos do diagrama de casos de uso 
Por ser simples, o diagrama de casos de uso possui poucos elementos passíveis 
de representação, que são: 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 40 
 
 
Ilustração do diagrama de casos de uso 
Por ser simples, o diagrama de casos de uso possui poucos elementos passíveis 
de representação, que são: 
 
 
 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 41 
 
 
Entendendo o ator 
O ator é algo com comportamento, que interage diretamente com o sistema. 
Um ator participa (realiza) de um ou mais casos de uso do sistema. 
 
 
 
No diagrama de casos de uso, a representação do ator é o boneco, chamado 
stickman, conforme figura ao lado. O ator é o papel que o agente desempenha 
em relação ao sistema. 
 
Um ator pode representar papéis internos (gerente de compras) e papéis 
externos (cliente e fornecedor) de acordo com o ilustrado na figura abaixo. 
 
 
 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 42 
 
 
 
Um ator pode também representar setores e departamentos da empresa 
(contabilidade e contas a pagar), bem como funções desempenhadas na 
empresa (almoxarifado), tal qual ilustrado pela figura a seguir. 
 
 
 
 
Abaixo exemplo de Ator como setor e função desempenhada. 
 
 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 43 
Um ator pode ser dispositivos eletrônicos, como, por exemplo, hardwares, 
servidores ou dispositivos lógicos, como sistemas, de acordo com a imagem a 
seguir. 
 
 
 
 
 
Identificando atores 
O primeiro passo para a construção do modelo de casos de uso é a 
identificação de atores. Algumas perguntas são úteis nessa situação: 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 44 
1 - Quais órgãos, empresas ou pessoas farão uso desse sistema de 
informação? 
2 - Quais sistemas ou equipamentos se comunicarão com o sistema que será 
desenvolvido? 
3 - Quem deve ser informado de alguma ocorrência no sistema? 
4 - A quem pode interessar os requisitos funcionais do sistema? 
 
 
Entendendo o caso de uso 
Segundo Jacobson, um dos criadores da UML, “um caso de uso é uma 
descrição narrativa de uma sequência de eventos que ocorre quando um ator 
usa um sistema para realizar uma tarefa”. Representam, através de elipses, as 
funcionalidades do sistema, conforme imagem ilustrativa a seguir. 
Sendo uma funcionalidade, o nome do caso de uso deve ser composto de um 
[verbo no infinitivo] + [complemento verbal], como, por exemplo, 
[matricular] + [em curso]. 
 
 
 
• Um caso de uso é um conjunto de cenários. 
• Um caso de uso descreve uma sequência de ações do ator e do 
sistema. 
• Cada sequência de ações é chamada de cenário. 
Em suma, um cenário é uma sequência específica de ações que ilustra 
o comportamento do caso de uso. 
 
Identificando casos de uso 
Após a identificação dos atores, podemos passar ao reconhecimento dos casos 
de uso. Em primeiro lugar, podemos pensar nos casos de uso que representam 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 45 
os objetivos dos atores e/ou os processos da empresa. Assim sendo, as 
seguintes perguntas são úteis neste momento: 
 
1 - Quais as necessidades e objetivos de cada ator em relação ao sistema? 
2 - Quais informações serão produzidas pelo sistema? 
3 - O sistema realizará alguma ação que ocorra de forma regular no tempo? 
4 - Existe um caso de uso para atender cada requisito funcional? 
 
 
Atenção 
 Em seguida, podemos pensar nos casos de uso que não 
representam um benefício direto para os atores, mas são 
necessários para o funcionamento do sistema. Tais casos de uso 
englobam manutenções de: cadastros, usuários e seus perfis, 
informações provenientes de outros sistemas. 
 
Atividade proposta 
Imagine a seguinte cena: uma clínica oftalmológica precisa de um sistema de 
agendamento de consultas e exames. 
• Um paciente contata a clínica, por telefone ou pessoalmente, e solicita a 
marcação de uma consulta com seu médico de preferência, informando data e 
hora desejadas; 
• A atendente verifica na agenda do médico a disponibilidade mais próxima de 
data e hora e marca a consulta; 
• Na data e hora agendadas, o paciente realizou a consulta, onde o médico 
solicitou exames e prescreveu medicamentos; 
• Após a consulta, o paciente solicita à atendente a marcação de seus exames, 
informando data e hora pretendidas. A atendente verifica a disponibilidade 
próxima à solicitada e agenda o exame para o paciente; 
• A qualquer momento, o paciente pode solicitar o cancelamento, não apenas 
da consulta, mas, também, do exame. 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 46 
Com base nas descrições anteriores, identifique os atores, os casos de uso 
envolvidos e desenhe o esboço do diagrama de casos de uso. 
 
Chave de resposta: 
Atores: paciente, atendente e médico. 
Casos de uso: seguem identificados por ator. 
 Atendente: Agendar Consulta, Agendar Exame, Cancelar Consulta e Cancelar 
Exame; 
 Médico: Consultar Paciente; 
 O paciente, embora extremamente relevante nesse processo, não interage 
diretamente com nenhuma funcionalidade do sistema, embora todas os dados 
imputados no sistema sejam fornecidos por ele. Em princípio não é considerado 
um ator, do ponto de vista da interação com o sistema. Todavia, muitos 
autores consideram-no ator, juntamente com os verdadeiros atores de cada 
caso de uso. 
Assim sendo podemos ter 2 soluções, representada nos 2 diagramas de casos 
de uso a seguir. 
 A primeira mais alinhada com o conceito de ator, onde o Paciente não figura 
entre os atores. 
 A segunda mais alinhada com a situação real, onde o Atendente e Médico 
interagem com o sistema, baseado no que lhes diz o Paciente. 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 47 
 
 
 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 48 
Relacionamentos entre ator e caso de uso 
Como você já viu, o diagrama de casos de uso possibilita relacionamentos 
entre: 
• Atores e casos deuso; 
• Atores; 
• Casos de uso. 
 
O mais comum é o relacionamento entre atores e casos de uso indicado por 
uma linha sólida, que liga o ator ao caso de uso, denotando a interação entre 
ambos. Nos termos técnicos, dizemos que o ator realiza o caso de uso. A figura 
abaixo ilustra esse relacionamento. Entenda que a comunicação nesse 
relacionamento é bidirecional; ou seja, além de o ator informar dados ao caso 
de uso, também recebe informações por ele processadas. 
 
 
 
 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 49 
Relacionamentos entre atores 
Entre atores, é possível haver o relacionamento de generalização/especialização 
representado por uma linha sólida, com uma seta que aponta para o ator geral, 
conforme ilustrado na imagem abaixo. Perceba, então, que o ator geral é o 
funcionário, e o ator especialista, o gerente. O gerente também exerce as 
atividades de um funcionário; porém, como gerente, possui tarefas específicas 
a essa função. 
 
 
 
Como você já viu, o diagrama de casos de uso possibilita relacionamentos 
entre: 
• Atores e casos de uso; 
• Atores; 
• Casos de uso. 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 50 
 
 
Observe o diagrama de casos de uso ilustrado na figura a seguir, onde temos 
exemplificada a generalização/especialização de atores. A leitura desse 
diagrama é a seguinte: 
 
• O ator geral é usuário, e os atores especializados são aluno e atendente; 
• Aluno e atendente relacionam-se com todos os casos de uso associados ao 
ator usuário; 
• No entanto, apenas o ator atendente se relaciona com cancelar matrícula em 
curso; ou seja, apenas atendente realiza esse caso de uso. 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 51 
 
 
 
Atenção 
 Essa última é uma associação (ou um relacionamento) útil para 
definir sobreposição de papéis entre atores, onde: 
• O ator especializado interage com o caso de uso ao qual está 
associado diretamente e com todos os casos de uso com os 
quais o ator generalizado se associa; 
• Já o inverso não ocorre: o ator generalizado não interage com 
os casos de uso associados ao ator generalizado. 
 
Relacionamentos entre casos de uso 
Casos de uso podem ser organizados em três tipos de relacionamentos: 
inclusão, extensão e generalização (sendo que cada um deles é 
representado de uma maneira específica). 
Agora, na sequência, você entenderá um pouco melhor sobre eles. 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 52 
 
Como você já viu, o diagrama de casos de uso possibilita relacionamentos 
entre: 
• Atores e casos de uso; 
• Atores; 
• Casos de uso. 
 
 
 
 
Relacionamentos entre casos de uso – inclusão 
Inclusão (include ou uses): 
Um caso de uso (caso de uso principal) incorpora, explicitamente, o 
comportamento de outro caso de uso (caso de uso incluído). O caso de uso 
incluído é parte integrante do caso de uso principal, e a fatoração acontece, 
pois outros casos de uso também poderão incorporar o caso de uso incluído e, 
assim, evitar repetições de fluxos. 
 
 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 53 
Exemplo de inclusão 
Observe no diagrama desta tela que o caso de uso validar disciplina é usado 
por dois casos de uso: incluir disciplina e eliminar disciplina. Isso significa que o 
caso de uso validar disciplina está contido em ambos; ou seja, se formos 
descrever as interações que ocorrem no caso de uso, perceberemos que tanto 
incluir disciplina quanto eliminar disciplinas possuirão uma mesma parte. 
 
O caso de uso validar disciplina será obrigatoriamente executado em algum 
ponto da execução do caso de uso incluir disciplina, como também em algum 
ponto na execução do caso de uso eliminar disciplina. 
 
 
 
 
 
 
 
 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 54 
 
Atenção 
 Normalmente, essa percepção da necessidade de fatoração 
ocorre quando estamos descrevendo os casos de uso, assunto 
que trataremos adiante. 
 
O cenário comum a mais de um caso de uso é capturado em 
outro caso de uso. No caso deste último exemplo, validar 
disciplina agrega o que é comum a incluir disciplina e a eliminar 
disciplina. 
 
Relacionamentos entre casos de uso – extensão 
Extensão (extends): 
Usado para descrever cenários opcionais em um caso de uso, uma variação do 
comportamento normal. 
 
Um caso B (caso de uso estendido) estende-se a A (caso de uso principal) 
quando alguma condição interrompe a execução do caso A (caso de uso 
principal) para que B (caso de uso estendido) execute e retorne, ao final, ao 
caso de uso A (caso de uso principal). A interrupção é feita no chamado ponto 
de extensão. A imagem desta tela ilustra o relacionamento de extensão. 
 
 
 
Exemplos de extensão 
Observe no diagrama desta tela que o caso de uso enviar informe de dívida 
estende o caso de uso cancelar matrícula em curso. Este poderá ou não solicitar 
a execução do caso de uso enviar informe de dívida, que somente será 
executado se o cancelamento do curso implicar no pagamento da dívida do 
aluno; se o aluno tiver quitado essa dívida, o caso de uso não será executado. 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 55 
 
 
 
Existe outra conotação e leitura do uso do extends, que está ilustrado no 
diagrama de caso de uso demonstrado aqui. 
 
Observe que os casos de uso pagar em cheque e pagar em cartão estendem o 
caso de uso pagar mensalidade. Neste exemplo, haverá uma condição a ser 
avaliada, que é a forma de pagamento e, de acordo com ela, será executado 
um ou outro caso de uso: apenas um deles será executado. 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 56 
 
 
 
Relacionamentos entre casos de uso – generalização 
Generalização: 
Quando um caso de uso é semelhante a outro, mas executa algumas funções a 
mais. É pouco usado, pois seu uso confunde-se com o extends na medida em 
que este também pode resolver esta questão da variação de comportamento; 
neste caso, um comportamento com adição de funcionalidade. 
 
 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 57 
Exemplo de generalização 
Observe o exemplo desta tela, onde existe a especialização do caso de uso 
solicitar produtos, que pode ser pela internet ou pelo telefone. De acordo com a 
forma de solicitação, o comportamento do caso de uso variará; porém, existem 
partes comuns, que estão especificadas em solicitar produtos (caso mais geral). 
 
 
 
A importância da especificação de casos de uso 
O diagrama de caso de uso é útil na medida em que nos fornece uma visão 
geral das funcionalidades do sistema (conjunto de casos de uso) e dos atores 
que com elas se relacionam. Todavia, é pobre na medida em que não nos 
permite entender como a interação ocorre em cada caso de uso. Podemos dizer 
que o diagrama é um sumário gráfico do conjunto de casos de uso 
(funcionalidades) de um sistema. 
 
No entanto, o real valor da técnica está na adequada descrição textual de cada 
caso de uso, que permite ver, com clareza, como os atores utilizam o sistema, 
no detalhamento. Mas a UML nada define sobre o texto narrativo, que descreve 
o caso de uso. 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 58 
Por exemplo, o processo unificado – PU define o modelo de casos de uso 
dentro da disciplina de requisitos, onde essencialmente se escreve o 
comportamento de todos os casos de uso. 
 
 
Atenção 
 Em suma, se o tempo destinado ao modelo de casos de uso for 
pouco, concentre-se na especificação ou descrição dos casos de 
uso e esqueça o diagrama. Mas, se tiver oportunidade, modele o 
diagrama, pois é umaótima ferramenta de diálogo com o 
usuário devido à sua simplicidade. 
 
Os formatos para especificar casos de uso 
No livro Utilizando UML e Padrões – uma introdução à análise e ao projeto 
orientados a objeto e ao desenvolvimento iterativo, de Craig Larman, são 
classificados três formatos para descrever casos de uso: 
 
Formato resumido 
O formato resumido trata-se de um resumo de um parágrafo, geralmente 
contendo o cenário principal do caso de uso, o cenário de sucesso. 
Quando usar? 
Utilizar o formato resumido na análise de requisitos inicial para obter uma ideia 
do assunto e escopo do caso de uso. 
 
Formato informal 
O formato informal consta de múltiplos parágrafos que cobrem vários cenários 
de uso. 
Quando usar? 
Utilizar o formato informal na mesma condição do formato resumido. 
 
 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 59 
Formato completo 
No formato completo, todos os passos e variantes são descritos em detalhes, 
com seções adicionais, complementando a especificação, como pré e pós-
condições. 
 
Quando usar? 
Utilizar o formato completo depois que muitos casos de uso tiverem sido 
descritos no formato resumido ou informal, durante a fase de análise de 
requisitos e de sistemas. Em suma, para os casos de uso relevantes, deve-se 
usar esse formato. 
 
 
Atenção 
 Em essência, a especificação ou descrição textual de um caso de 
uso deve mostrar a interação entre o ator e o sistema (caso de 
uso em questão); ou seja, a “conversa” entre ator e sistema na 
realização do caso de uso. 
 
Diferenciando os três tipos de especificação 
Para mostrar a diferença entre os três tipos de especificação, vamos usar como 
exemplo o caso de uso registrar venda, com o seguinte trecho de diagrama de 
casos de uso: 
 
 
 
Observe que, no diagrama acima, foram considerados ator tanto o caixa quanto 
o cliente. O motivo de considerá-los atores é que o cliente também interage 
com o sistema quando o pagamento é em cartão, por exemplo. 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 60 
O formato resumido 
Caso de Uso: Registrar Venda 
O cliente chega em um ponto de pagamento da loja com os itens que deseja 
adquirir. O caixa registra cada item desejado. Ao final, o sistema apresenta o 
total a pagar e a relação de itens comprados. O cliente informa, e o caixa 
registra os dados do pagamento, que são validados e registrados pelo sistema, 
que atualiza o estoque. O cliente recebe o recibo das compras e sai com os 
itens adquiridos. 
 
O formato informal 
Caso de uso: Registrar Venda 
Cenário Principal (de sucesso) 
O cliente chega ao ponto de pagamento da loja com os itens a serem 
adquiridos. O caixa usa o sistema PDV para registrar todos os itens comprados. 
Ao final, o sistema apresenta o total a pagar e a relação de itens comprados. O 
cliente informa e o caixa registrar os dados do pagamento, que são validados e 
registrados pelo sistema. O sistema atualiza o estoque. O cliente recebe o 
recibo das compras e sai com os itens adquiridos. 
 
Cenários Alternativos 
Se o identificador do item adquirido não for encontrado no sistema, esse 
notifica o caixa e sugere que esse entre manualmente com a identificação do 
item (que talvez esteja corrompido). 
Se o cliente informou pagamento em cartão e a operadora não aprova a 
transação, informe o cliente e solicite nova forma de pagamento; 
Se o sistema não consegue atualiza o estoque, sugere que o caixa registre no 
formulário de problemas do dia, para balanço ao final do dia. 
 
 
 
 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 61 
O formato completo 
Caso de uso (registrar venda) 
Vários gabaritos e padrões de formatos estão disponíveis para casos de uso 
relevantes que precisam de especificações detalhadas. Abaixo, descrevemos as 
principais seções que compõem o formato completo. 
 
Seção da especificação Significado 
Nome do caso de uso (*) Verbo no infinitivo + complemento verbal 
Escopo (*) O nome do sistema/projeto 
Nível 
Objetivo do usuário ou sub-função 
(include, extends e especialização) 
Atores (*) Atores envolvidos: principal e secundários 
Interessados e interesses 
Quem se importa com esse caso de uso e o que 
eles desejam 
Pré-condição (*) 
O que precisa ser verdade para esse caso de uso 
acontecer 
Pós-condição ou garantia 
de sucesso (*) 
O que precisa ser verdade quando da finalização 
bem-sucedida desse caso de uso 
Cenário principal (*) 
O cenário de sucesso, um caminho típico, 
incondicional 
Cenários alternativos ou 
extensões (*) 
Cenários alternativos, quando o cenário principal 
tem uma variação do fluxo bem-sucedido. 
Requisitos especiais Requisitos não funcionais relacionados 
 
(*) São as seções mais usadas pela maioria dos autores e analistas de 
sistemas. 
Nome do caso de uso: registrar venda 
Escopo: sistema de vendas – PDV 
Nível: usuário 
Atores: caixa 
Interessados e interesses: 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 62 
– Caixa: deseja que o sistema seja eficiente, sem erros e de fácil 
utilização; 
– Cliente: deseja adquirir os produtos desejados de forma rápida, sem 
muito esforço, bem como encontrar o que precisa e, ao final, um comprovante 
do que comprou; 
– Órgãos fiscais: desejam cobrar os impostos de cada venda realizada; 
– Operadoras de cartão: desejam receber solicitações de autorização de 
crédito no formato e protocolo corretos; 
– Etc. 
Pré-condição: todos os produtos registrados no sistema, contendo os 
respectivos preços; caixa autenticado e PDF registrado. 
Pós-condições: venda salva, impostos calculados, estoques atualizados, 
autorizações de pagamento registradas e recibo gerado. 
 
Cenário principal (ou fluxo básico) 
1. Cliente chega ao PDV com os itens que deseja adquirir; 
2. Caixa inicia uma nova venda; 
3. Para cada item de venda do cliente, faça: 
a) Caixa insere o identificador do item; 
b) Sistema localiza o item; 
c) Sistema registra e apresenta a linha do item de venda, com o identificador, 
nome e valor unitário do produto; 
d) Sistema calcula os impostos do item. 
4. Sistema apresenta o valor total da venda com impostos calculados; 
5. Caixa informa total ao cliente e solicita pagamento; 
6. Caixa informa o pagamento do cliente; 
7. Sistema registra e trata o pagamento do cliente; 
8. Sistema finaliza a venda e apresenta o recibo; 
9. Sistema contabiliza a baixa no estoque de cada item vendido. 
 
Cenários alternativos (extensões) 
2.a. Sistema não inicializa: 
 
 LINGUAGEM DE MODELAGEM UNIFICADA (UML) 63 
1. Caixa inicia a venda em planilha manual (contingência), registrando cada item e 
o pagamento em planilha eletrônica, e encerra o caso de uso. 
3.a. Sistema não localiza o identificador do item: 
1. Sistema avisa o erro e rejeita a entrada; 
2. Caixa responde ao erro: 
 2.a. Existe ID do item legível: 
 1. Caixa insere o identificador do item; 
 2. Sistema mostra descrição e preço. 
 2.b. Existe preço na etiqueta: 
 1. Caixa solicita ao gerente executar operação de correção; 
 2. Gerente realiza correção; 
3. Caixa indica entrada manual de preço, insere preço e solicita o imposto 
padrão para essa quantia. 
2.c. Caixa invoca ajuda no sistema para localizar produto a fim de obter 
identificação e preço real do item. 
2.d. Caso contrário, caixa pergunta a um funcionário o preço, e o identificador 
do item executa entrada manual do identificador (ver acima, 2.a) ou do preço 
do item (ver acima 2.b). 
 3-4 a. Cliente solicita o cancelamento de um item da venda: 
1. Caixa insere o identificador do item a ser removido; 
2. Sistema