MODELAGEM DO SISTEMA COM A ANÁLISE ORIENTADA A OBJETOS - LEITURA DIGITAL

Prévia do material em texto

MODELAGEM DO SISTEMA 
COM A ANÁLISE ORIENTADA 
 A OBJETOS
W
B
A
04
48
_v
1.
0
2
Iolanda Cláudia Sanches Catarino
Londrina 
Editora e Distribuidora Educacional S.A. 
2020
MODELAGEM DO SISTEMA COM A ANÁLISE 
ORIENTADA A OBJETOS
1ª edição
3
2020
Editora e Distribuidora Educacional S.A.
Avenida Paris, 675 – Parque Residencial João Piza
CEP: 86041-100 — Londrina — PR
e-mail: editora.educacional@kroton.com.br
Homepage: http://www.kroton.com.br/
Presidente
Rodrigo Galindo
Vice-Presidente de Pós-Graduação e Educação Continuada
Paulo de Tarso Pires de Moraes
Conselho Acadêmico
Carlos Roberto Pagani Junior
Camila Braga de Oliveira Higa
Carolina Yaly
Giani Vendramel de Oliveira
Henrique Salustiano Silva
Juliana Caramigo Gennarini
Mariana Gerardi Mello
Nirse Ruscheinsky Breternitz
Priscila Pereira Silva
Tayra Carolina Nascimento Aleixo
Coordenador
Henrique Salustiano Silva
Revisor
Rogério Colpani
Editorial
Alessandra Cristina Fahl
Beatriz Meloni Montefusco
Gilvânia Honório dos Santos
Mariana de Campos Barroso
Paola Andressa Machado Leal 
Dados Internacionais de Catalogação na Publicação (CIP)__________________________________________________________________________________________ 
Catarino, Iolanda Cláudia Sanches.
C357m Modelagem do sistema com a análise orientada a 
 objetos/ Iolanda Cláudia Sanches Catarino. – Londrina: 
Editora e Distribuidora Educacional S.A., 2020.
 44 p.
 ISBN 978-65-87806-19-8
1. Modelagem 2. Sistema 3. Objeto I. Título.
 
CDD 005
____________________________________________________________________________________________
Raquel Torres – CRB 6/2786
© 2020 por Editora e Distribuidora Educacional S.A.
Todos os direitos reservados. Nenhuma parte desta publicação poderá ser 
reproduzida ou transmitida de qualquer modo ou por qualquer outro meio, 
eletrônico ou mecânico, incluindo fotocópia, gravação ou qualquer outro tipo de 
sistema de armazenamento e transmissão de informação, sem prévia autorização, 
por escrito, da Editora e Distribuidora Educacional S.A.
4
SUMÁRIO
Análise e Desenvolvimento de Software Orientado a Objetoss ______ 05
Linguagem de Modelagem Unificada (UML): modelagem 
comportamental e estrutural de software __________________________ 21
Modelagem comportamental da análise com a Linguagem de 
Modelagem Unificada (UML) ________________________________________ 40
Modelagem estrutural da análise com a Linguagem de Modelagem 
Unificada (UML) ____________________________________________________ 57
MODELAGEM DO SISTEMA COM A ANÁLISE ORIENTADA A 
OBJETOS
5
Análise e Desenvolvimento de 
Software Orientado a Objetos
Autoria: Iolanda Cláudia Sanches Catarino
Leitura crítica: Rogério Colpani
Objetivos
• Conhecer e compreender a evolução dos 
paradigmas da análise e desenvolvimento de 
software.
• Conhecer e compreender as características dos 
métodos orientados a objetos.
• Conhecer e compreender as características, 
conceitos e pilares do paradigma orientado a 
objetos.
6
1. Evolução da análise e desenvolvimento de 
software
Na era da transformação digital, o desenvolvimento de sistemas de 
software se tornou uma atividade ágil, a partir da definição de uma 
metodologia de desenvolvimento que assegure as boas práticas da 
engenharia de software, principalmente a garantia da qualidade do 
software.
O processo de engenharia de software abrange todas as decisões 
tomadas quanto ao planejamento de execução do projeto, a definição 
do método com suas fases e técnicas de modelagem, ferramentas de 
desenvolvimento, tecnologias de implementação e testes e demais 
padrões necessários, decorrentes da complexidade e domínio de um 
sistema de software.
Esta Leitura Digital contempla, primeiramente, uma fundamentação 
sobre a evolução histórica dos paradigmas da análise e desenvolvimento 
de software e uma descrição das características dos principais métodos 
orientados a objetos que se destacaram na década de 1990. Na 
sequência, serão apresentadas as características, conceitos e pilares que 
sustentam o paradigma orientado a objetos.
1.1 Análise estruturada e orientada a objetos
A evolução histórica dos paradigmas da análise e desenvolvimento de 
software fundamenta-se nas análises estruturada, essencial e orientada 
a objetos, a partir da década de 1970. Os paradigmas que categorizam 
as técnicas e métodos usados na fase de análise têm relação com 
os paradigmas de programação, decorrentes das linguagens de 
programação surgirem antes das técnicas de modelagem adotadas para 
documentarem as fases de análise e projeto de um sistema.
7
A análise estruturada, no início da década de 1970, tem como foco os 
elementos processos e dados em estruturas separadas, abstraindo o 
mundo real, a partir de processos e fluxos de dados com detalhamento 
top-down, ou seja, do nível macro para os menores detalhes. Diante da 
demanda de mercado por sistemas de softwares complexos e robustos, 
a abordagem da análise estruturada trouxe a ideia da documentação 
do sistema, a partir de diagramas com a perspectiva em processos e 
depósitos de dados, destacando o Diagrama de Fluxo de Dados (DFD), 
contudo, a programação era implementada de forma modular com 
refinamentos sucessivos, acarretando problemas de decomposição 
funcional.
A análise estruturada essencial ou moderna, na década de 1980, 
caracteriza-se por ser uma evolução da análise estruturada e recomenda 
que a especificação do sistema seja apresentada em três perspectivas 
que se complementam e enfatizam os eventos que afetam o sistema: 
modelo de processos ou funcional; modelo de dados; e o modelo de 
controle, descrevendo o sistema de maneira independente de restrições 
tecnológicas, reforçando o conjunto de requisitos essenciais de um 
sistema, contudo, não enfatizando o comportamento temporal dos 
processos definidos. Os problemas que se evidenciaram com a análise 
estruturada moderna estão relacionados com a dificuldade de conexão 
do DFD com as demais técnicas de modelagem entre a transição da 
fase de análise para a fase de projeto, além dos mesmos problemas de 
decomposição funcional na programação.
A análise orientada a objetos emergiu entre meados da década de 1980 
e 1990, acompanhando a evolução das linguagens de programação 
orientadas a objetos, consolidando-se um novo paradigma de 
desenvolvimento de software. A orientação a objetos concentra-
se no elemento objeto, considerado uma unidade autônoma, que 
contém tanto a estrutura dos dados como seu comportamento, que é 
representado pelas operações, assim realizando suas tarefas de forma 
8
colaborativa, resultando nas funcionalidades do sistema de software. 
Segundo Bezerra (2014):
Um sistema de software orientado a objetos consiste em objetos em 
colaboração com o objetivo de realizar as funcionalidades desse sistema. 
Cada objeto é responsável por tarefas específicas. É graças à cooperação 
entre objetos que a computação do sistema se desenvolve. (BEZERRA, 
2014, p. 7)
Na década de 1990, surgiram diversos métodos para apoiar o paradigma 
orientado a objetos, sendo que as técnicas de modelagem específicas 
para documentar as fases de análise e projeto se relacionam e são 
consistentes, enfatizando as perspectivas estática e dinâmica da 
modelagem do software. De forma geral, a modelagem da fase de 
análise documenta a visão lógica do software, ou seja, a identificação 
e definição do domínio do problema, especificando os requisitos de 
sistema. A modelagem da fase de projeto documenta a visão física do 
software, a partir de um refinamento da documentação elaborada na 
fase de análise, complementando-a com definições das tecnologias 
de linguagens de programação, frameworks, patterns, componentes de 
software e banco de dados que serão adotados para implementação do 
software, ou seja, define o domínio da solução. Das principais técnicas 
de modelagem da análise e projeto orientado a objetos, destacam-se o 
diagrama de use cases (casosde uso), o diagrama de classes, o diagrama 
de atividades, o diagrama de máquina de estados e o diagrama de 
sequência.
1.2 Principais métodos da análise orientada a objetos
Os métodos de modelagem de análise e projeto orientados a objeto 
surgiram entre meados da década de 1980, acompanhando a evolução 
das linguagens de programação orientadas a objetos e, na década de 
1990, evidenciaram-se no âmbito acadêmico e de mercado.
9
Os métodos de modelagem orientados a objetos suportam os mesmos 
princípios e conceitos básicos da orientação a objetos, consistindo em 
um conjunto de técnicas de modelagem aplicadas, principalmente, 
às atividades de requisitos e análise e projeto de um processo de 
desenvolvimento de software, com um propósito especifico para 
representarem modelos estáticos e dinâmicos do sistema, especificados 
graficamente por diagramas, na maioria, ou de forma descritiva. Há 
vários métodos de desenvolvimento orientados a objetos que se 
destacaram na literatura. Veremos, a seguir, uma descrição sucinta de 
alguns métodos orientados a objetos que se destacaram.
Em 1988, foi lançado o método de Shlaer e Mellor (Sally Shlaer e Stephen 
Mellor), denominado como Object-Oriented Systems Analysis (OOSA) 
ou Object-Oriented Analysis (OOA), que enfatiza a modelagem consistente 
dos objetos e seus agrupamentos, a partir de mecanismos que facilitam 
a representação de modelos dinâmicos dos objetos, permitindo 
que a especificação dos modelos de análise seja traduzida para 
implementação. O método contempla técnicas de modelagem aplicadas 
às fases de análise, projeto e implementação, sendo as principais: 
diagrama de objetos, diagrama de estados, diagrama de fluxo de dados 
e diagrama de ações.
Em 1990, foi lançado o método de Rebecca Wirfs-Brock, o primeiro 
a enfatizar a modelagem orientada a objetos para a fase de projeto 
(design), contemplando técnicas de modelagem para especificação das 
fases de requisitos, projeto, implementação e testes. O método enfatiza 
o princípio de gerenciamento por responsabilidades, por meio da 
técnica Class-Resposability-Collaboration (CRV), cartões que permitem o 
mapeamento de classes para execução de responsabilidades, a partir de 
colaboração mútua dos objetos identificados.
Em 1991, foi lançado o método de Grady Booch, considerado um dos 
mais autênticos métodos de desenvolvimento orientado a objetos, 
definindo que o sistema é analisado a partir de visões, onde cada visão 
10
é descrita por modelos e diagramas. O método contempla técnicas de 
modelagem aplicadas às fases de análise e projeto, nas perspectivas 
estática e dinâmica, a partir de modelos lógicos e físicos. A principal 
técnica de modelagem estática do método é o diagrama de classes. 
para modelar a perspectiva dinâmica do software, o método abrange o 
diagrama de máquina de estados, o diagrama de interação e o diagrama 
de processos.
Em 1991, foi lançado o método de James Rumbaugh, Michael Blaha, 
William Premerlani, Frederick Eddy e William Lorensen, nomeado 
como Object Modelling Technique (OMT). É um método conservador no 
uso da teoria de objetos, contemplando técnicas de modelagem para 
especificação da análise de requisitos, análise, projeto e implementação. 
A modelagem se inicia com a descrição do enunciado do problema, 
na sequência, especifica-se a modelagem de objetos, a modelagem 
dinâmica e a modelagem funcional, destacando o tratamento dos 
processos. Durante a fase de projeto, consiste a especificação em 
projeto de objetos e projeto do sistema.
Em 1992, foram lançados os métodos de Ivar Jacobson, denominados 
como Object-Oriented Software Enginneering (OOSE) e o Objectory, que 
enfatizam a modelagem baseada em requerimentos, especificada por 
meio de use cases (casos de uso), que definem os requisitos iniciais 
do sistema. O método OOSE é um método orientado a objetos, com 
abordagem dirigida a cenários, e o método Objectory é aplicado a 
diferentes domínios de sistemas, principalmente, para modelagem 
organizacional. O método OOSE contempla as fases de análise, projeto e 
implementação. Na fase de análise, os principais modelos são o modelo 
de requisitos e o modelo de objetos.
Em 1992, foi lançado o método de Coad e Yourdon (Peter Coad e Edward 
Yourdon), que enfatiza a modelagem dirigida a dados, contemplando as 
mesmas técnicas de modelagem aplicadas às fases de análise e projeto, 
com refinamentos iterativos entre as fases. A principal técnica de 
11
modelagem é o modelo de objetos, não particionado, complementado 
com o modelo de especificação de classe-objeto e dos diagrama de 
estado de objeto e do diagrama de serviço.
Em 1993, foi lançado o método de Martin e Odell (James Martin e 
James J. Odell), que apresenta a modelagem de dados e seus serviços, 
enfatizando a reutilização dos objetos. Além disso, contempla a 
modelagem de Análise da Estrutura do Objeto (AEO), a partir da 
especificação do diagrama de objeto-relacionamento; a modelagem 
de Análise do Comportamento do Objeto (ACO), a partir do diagrama 
de fluxo de objetos; e a modelagem de Projeto da Estrutura do Objeto 
(PEO) e do Projeto do Comportamento do Objeto (PCO), a partir da 
especificação de esquemas de atividades que representam os eventos, 
processos, fluxo de objetos e a transição de estados dos objetos.
Em 1994, foi lançado o método de Derek Coleman, denominado de 
método Fusion, que consiste em uma abordagem sistemática para o 
desenvolvimento de software orientado a objetos, contemplando as 
etapas de produção e montagem. A etapa de produção abrange as 
fases de análise, projeto e implementação; e a etapa montagem enfatiza 
assegurar a qualidade do software, a partir da detecção e remoção 
de erros. As principais técnicas de modelagem da fase de análise são 
os modelos de objeto e de interface, que se complementam com as 
técnicas de modelagem da fase de projeto, os grafos de interação entre 
objetos, grafos de visibilidade, descrições de classes e os grafos de 
herança.
Diante da diversidade de métodos que surgiram para apoiar o 
desenvolvimento orientado a objetos, no início da década de 1990, 
Grady Booch, Ivar Jacobson e James Rumbaugh uniram as melhores 
práticas, características e aplicabilidade de suas técnicas de modelagem 
e construíram um padrão de referência para modelagem orientada a 
objetos, lançando oficialmente a Linguagem de Modelagem Unificada 
(Unified Modeling Language–UML), em 1997.
12
2. Paradigma orientado a objetos
O Paradigma Orientado a Objetos (POO) é uma estratégia consistente 
de desenvolvimento de sistemas de software, utilizando modelos 
organizados a partir de conceitos do mundo real para organizar o 
software como uma coleção de objetos. O desenvolvimento orientado 
a objetos assegura o aumento da produtividade e da qualidade 
do processo de software. De acordo com Bezerra (2014), o termo 
paradigma da orientação a objetos é uma forma de abordar um 
problema, visualizando um sistema de software como uma coleção 
de agentes interconectados chamados objetos, sendo cada objeto 
responsável por realizar tarefas específicas e a partir da interação entre 
os objetos que as tarefas computacionais são realizadas.
De acordo com Booch, Rumbaugh e Jacobson (2006), a principal 
característica do POO é a uniformização dos formalismos, conceitos 
utilizados nas fases de análise, projeto e implementação. Destacam 
também as seguintes características:
a. Reusabilidade: refere-se à reutilização de componentes de 
software na implementação das funcionalidades, proporcionando 
a diminuição de custos e tempo de desenvolvimento do software.
b. Extensibilidade: refere-se à aplicação do conceito de herança, 
sendo que partes do software têm seu uso estendido a objetos 
herdados, assim, as classes genéricas podem ser acrescidas de 
funcionalidades comuns às classes especializadas.
c. Confiabilidade: refere-se a um controle de organização 
e segurança que é estabelecido aos objetos a partir do 
encapsulamento das classes, que torna o acesso às estruturasde 
dados privado aos objetos.
d. Manutenibilidade: refere-se ao grau de impacto de alterações 
corretivas e evolutivas no software, decorrentes da realização de 
13
mudanças pontuais dos objetos, que não acarreta a propagação 
descontroladas por todo o software.
2.1 Conceitos da orientação a objetos
A orientação a objetos é uma maneira natural de identificar os 
elementos do mundo real, abstraindo os grupos de objetos e suas 
relações para mundo computacional. Para assegurar o sucesso do 
desenvolvimento orientado a objetos, é importante compreender os 
conceitos básicos que fundamentam o paradigma, entre eles, os pilares 
da programação orientação a objetos, os conceitos de abstração, 
encapsulamento, herança e polimorfismo. A seguir, apresenta-se uma 
definição dos principais conceitos do POO, suas correlações e exemplos.
Um objeto pode ser definido como qualquer coisa concreta ou abstrata 
do mundo real, com características e comportamento próprio em uma 
única estrutura, sendo possível identificá-lo. Na definição de Booch, 
Jacobson e Rumbaugh (2006, p. 456), um objeto é “uma entidade com 
uma fronteira bem definida e uma identidade que encapsula o estado 
e comportamento”. São exemplos de objetos concretos do mundo real, 
como automóvel, edifício, produto, cliente e objetos abstratos como 
contrato, ingresso, evento cultural.
O conceito de abstração consiste na concentração dos aspectos 
importantes e relevantes dos objetos, considerando o contexto 
analisado e o domínio do sistema.
Para Bezerra (2014):
A abstração é um processo mental pelo qual nós, seres humanos, nos 
atentamos aos aspectos mais importantes (relevantes) de alguma coisa, 
ao mesmo tempo em que ignoramos os aspectos menos importantes. [...] 
Note que uma abstração de algo é dependente da perspectiva (contexto) 
14
sobre a qual uma coisa é analisada: o que é importante em um contexto 
pode não ser importante em outro. (BEZERRA, 2014, p. 8)
Para elaborar a documentação de um software, aplica-se abstração 
em diferentes níveis de perspectivas. Primeiramente, identificam-se 
os objetos conceituais a partir de objetos do mundo real, descrevendo 
as características e comportamentos comuns entre os objetos e 
definem-se as classes para representarem o conjunto desses objetos. 
Posteriormente, verifica se, entre as classes identificadas, é possível 
classificá-las como pertencentes a um mesmo tipo, sempre projetando 
no contexto do mundo real do domínio do sistema e, se possível, define-
se uma hierarquia entre as classes. Podem-se definir vários níveis de 
hierarquias entre as classes.
Uma classe representa um grupo de objetos do mundo real que 
possui tipos de características e de comportamento em comum. Cada 
ocorrência de um objeto representa uma instância da classe. Na 
definição de Booch, Jacobson e Rumbaugh (2006, p. 49), uma classe 
é “uma descrição de um conjunto de objetos que compartilham os 
mesmos atributos, operações, relacionamentos e semântica”. Para 
Rumbaugh (1997, p. 32), uma classe “descreve um grupo de objetos 
com propriedades semelhantes (atributos), o mesmo comportamento 
(operações), os mesmos relacionamentos com outros objetos e a mesma 
semântica”. É importante enfatizar que uma classe é uma abstração das 
características e comportamentos relevantes de um conjunto de objetos. 
Assim, as características descrevem os atributos ou propriedades dos 
objetos de uma classe e o comportamento descreve as operações.
Um atributo descreve uma característica possuída por todos os objetos 
de uma classe, assumindo valores específicos para cada objeto. Na 
definição de Booch, Jacobson e Rumbaugh (2006, p. 50), um atributo é 
“uma propriedade nomeada de uma classe que descreve um intervalo 
de valores que as instâncias da propriedade podem apresentar. 
Uma classe pode ter qualquer número de atributos ou mesmo 
15
nenhum atributo”. Para Guedes (2018), os atributos representam as 
características relevantes de uma classe que costumam variar de um 
objeto para outro, permitindo diferenciar os objetos da mesma classe.
Uma operação descreve uma ação que o próprio objeto executa ou uma 
ação que o objeto pode executar, a partir do disparo de um evento, ou 
seja, é uma ordem que faz o objeto reagir decorrente do acontecimento 
de um evento, sendo compartilhada por todos os objetos da mesma 
classe. Na definição de Booch, Jacobson e Rumbaugh (2006, p. 51), uma 
operação é “uma abstração de algo que pode ser feito com um objeto e 
que é compartilhado por todos os objetos dessa classe. Uma classe pode 
ter qualquer número de operações ou até não ter nenhuma operação”.
O mecanismo de invocação de uma operação representa uma 
mensagem enviada, sendo a forma de conseguir executar um método. 
A implementação de uma operação é chamada de método. Assim, um 
método representa o conjunto de passos lógicos, os comandos de uma 
linguagem de programação, que um objeto executa para descrever 
a operação. A Figura 1 ilustra a representação das classes aluno e 
funcionário, com seus atributos relevantes ao contexto e as operações 
básicas. O nome da classe é representado na primeira divisão da classe, 
os atributos são representados na segunda divisão da classe e as 
operações são representadas na terceira divisão da classe.
16
Figura 1 – Classes aluno e funcionário
Fonte: elaborada pela autora.
Eventos são os acontecimentos que provocam a mudança de estado 
dos objetos. Um evento, ao ser disparado, envia uma mensagem, 
invocando uma operação dos objetos de uma classe, assim provocando 
a mudança de estado do objeto. Na definição de Rumbaugh (1997), 
um evento é um estímulo individual de um objeto para outro, ou seja, 
é algo que acontece em certo momento, disparando uma transmissão 
ou informação unidirecional de um objeto para outro, sendo uma 
ocorrência única.
Um estado representa a abstração de uma forma de apresentação dos 
objetos em um instante de tempo com uma duração, demonstrando a 
reação de um objeto em resposta a um evento. Na definição de Booch, 
Jacobson e Rumbaugh (2006, p. 290), um estado é “uma condição ou 
situação na vida de um objeto durante a qual o objeto satisfaz alguma 
condição, realiza alguma atividade ou aguarda um evento. Um objeto 
permanece em um estado por uma quantidade finita de tempo”. 
17
Considere como exemplo um objeto do tipo trem que, num instante 
de tempo (t1), encontra-se no estado repouso e, a partir de um evento 
disparado, como, por exemplo, um botão acionado por uma ação 
humana, o objeto reage e muda seu estado para movimento, no instante 
de tempo seguinte (t2).
Uma transição de estado representa a mudança de estado de um objeto 
em resposta um evento disparado. Para Booch, Jacobson e Rumbaugh 
(2006, p. 291), uma transição é “um relacionamento entre dois estados, 
indicando que um objeto no primeiro estado realizará certas ações e 
entrará no segundo estado quando um evento especificado ocorrer e as 
condições especificadas forem satisfeitas”.
O conceito de encapsulamento representa o ato de reunir em uma 
estrutura chamada classe, os atributos e operações dos objetos, 
permitindo que um objeto proteja a integridade de suas partes. O 
objetivo do encapsulamento é restringir a visibilidade ou escopo das 
informações dos objetos de uma classe, sendo que a única maneira de 
acessar as operações de um objeto é por meio de interfaces fornecidas 
pelo objeto. Assim, uma interface é o modo de se comunicar com 
os objetos, conhecendo o que ele sabe fazer, contudo, não sabendo 
como ele faz. Na definição de Rumbaugh (1997, p. 10), o conceito de 
encapsulamento é “também chamado de ocultamento de informações, 
consiste na separação dos aspectos externos de um objeto, acessíveis 
por outros objetos, dos detalhes internos da implementação daquele 
objeto, que ficam ocultos dos demais objetos”.
O conceito de generalização, também denominado de herança, 
representa a propriedade pela qual uma classe pode herdar atributos 
e operações de uma classe que generaliza as característicase 
comportamentos comuns de um grupo de objetos. Na definição de 
Booch, Jacobson e Rumbaugh (2006, p. 454), herança é “o mecanismo 
pelo qual elementos mais específicos incorporam a estrutura e o 
comportamento de elementos mais gerais”. De acordo com Rumbaugh 
18
(1997, p. 4), o conceito de herança é “o compartilhamento de atributos e 
operações entre classes com base em um relacionamento hierárquico. 
Uma classe pode ser definida de forma abrangente e depois refinada em 
sucessivas subclasses mais definidas”.
Em um contexto, a partir da abstração das classes, o reconhecimento 
da similaridade entre classes é demonstrado em uma hierarquia de 
classes, surgindo os conceitos de superclasse e subclasses. Superclasses 
representam abstrações generalizadas e subclasses representam 
abstrações especializadas, com atributos e operações específicas. 
Quando a herança acontece de uma única superclasse, é denominada 
herança simples; sendo de várias superclasses, é denominada herança 
múltipla. A Figura 2 ilustra um exemplo de classes semelhantes que 
foram agrupadas em uma hierarquia, representado pelo relacionamento 
de generalização entre as classes pessoa (superclasse) e Aluno e 
Funcionario (subclasses). Fazendo a leitura da figura, aluno é um tipo de 
pessoa, no mundo real, e funcionário também é um tipo de pessoa. A 
herança define uma relação entre classes do tipo é-um (a).
Figura 2 – Exemplo de herança (generalização)
Fonte: elaborada pela autora.
19
O conceito de polimorfismo significa que a mesma operação pode 
atuar de diversas formas em classes distintas. Uma operação 
polimórfica possui o mesmo nome em classes distintas, mas em cada 
classe o método implementado é diferente. O polimorfismo está 
associado ao conceito de herança. Para Guedes (2018), o polimorfismo 
consiste na redeclaração de operações herdadas por uma classe, 
que são semelhantes na nomenclatura, contudo, diferem de alguma 
forma da implementação utilizada na superclasse, sendo, assim, 
necessário reimplementá-las na subclasse. Conforme Bezerra (2014), 
o polimorfismo refere-se à capacidade de duas ou mais classes 
responderem à mesma mensagem, cada uma de uma forma, ou seja, 
um objeto pode enviar a mesma mensagem para objetos semelhantes, 
mas os objetos receptores respondem de maneiras distintas.
A Figura 3 representa um exemplo de polimorfismo, em que a 
superclasse ContaBancaria possui o atributo saldo, herdado pelos 
objetos das subclasses ContaCorrente e ContaPoupança. Isso sendo 
que, a partir de uma mensagem para executar a operação sacar conta, 
da subclasse ContaCorrente, define-se como parâmetros os atributos 
numero, saldo e limite, ou seja, diminui-se o valor a ser debitado do saldo 
da conta e, se necessário, utiliza-se o valor extra, referente ao valor 
do atributo limite. Na execução da operação sacarConta, da subclasse 
ContaPoupança, define-se como parâmetros apenas os atributos numero 
e saldo, assim, caso o objeto não possua saldo suficiente, a operação 
será recusada.
20
Figura 3 – Exemplo de polimorfismo
Fonte: elaborada pela autora.
Os vários métodos de desenvolvimento de sistemas de software 
abrangem um conjunto de técnicas de modelagem específicas para 
documentarem as principais fases de um processo de desenvolvimento, 
em consonância com o modelo de processo de software adotado e com 
os princípios do paradigma de desenvolvimento. A análise de sistemas 
é uma das principais fases de um processo de desenvolvimento de 
software.
Referências Bibliográficas
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 3. ed. 
Rio de Janeiro: Elsevier, 2014.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. 2. ed. 
Rio de Janeiro: Campus, 2006.
GUEDES, Gilleanes T. A. UML: uma abordagem prática. 3. ed. São Paulo: Novatec, 
2018.
RUMBAUGH, James et al.Modelagem e projetos baseados em objetos. Rio de 
Janeiro: Campus, 1997.
21
Linguagem de Modelagem 
Unificada (UML): modelagem 
comportamental e estrutural de 
software
Autoria: Iolanda Cláudia Sanches Catarino
Leitura crítica: Rogério Colpani
Objetivos
• Conhecer a Linguagem de Modelagem Unificada 
(UML) para o desenvolvimento de software 
orientado a objetos.
• Compreender as técnicas de modelagem 
comportamental da UML.
• Compreender as técnicas de modelagem estrutural 
da UML.
22
1. Visão Geral da Linguagem de Modelagem 
Unificada
A Linguagem de Modelagem Unificada (UML–Unified Modeling Language) 
descreve uma notação padrão para ser utilizada no desenvolvimento 
de softwares orientados a objetos. As técnicas de modelagem da UML, 
os diagramas, apoiam o desenvolvimento incremental, a partir de 
modelos que podem evoluir com a inclusão de novos detalhes, contudo, 
não estão vinculadas exclusivamente a uma fase do processo de 
desenvolvimento de software, definindo quem deve fazer o que, quando 
e como.
A UML consiste da união dos métodos de Grady Booch, James 
Rumbaugh (OMT- Object Modeling Technique) e Ivar Jacobson (OOSE – 
Object-Oriented Software Engineering), contudo, teve a contribuição de 
vários autores da década de 1990. A construção da UML iniciou-se com 
as boas práticas dos métodos de Rumbaugh e Booch, surgindo, em 
1995, o Unified Method 0.8. Em meados de 1996, Jacobson integrou-
se ao grupo e lançaram a UML versão 0.9. A partir daí, criaram forças 
com a cooperação de grandes empresas e com a aprovação da Agência 
Americana de Padrões–Object Management Group (OMG), lançando, em 
julho de 1997, a UML como uma linguagem visual para modelagem de 
softwares orientados a objetos. Atualmente, a OMG é a organização 
internacional responsável em manter e administrar a UML e desde seu 
lançamento, várias atualizações foram feitas, sendo que a versão 2.0 
foi oficialmente apresentada em 2005 e, atualmente, a versão 2.5.1 foi 
lançada em dezembro de 2017.
De acordo com Booch, Jacobson e Rumbaugh (2006, p. 13), a UML é 
“uma linguagem padrão para a elaboração da estrutura de projetos 
de software. A UML é uma linguagem para visualização, especificação, 
construção e documentação de artefatos que façam uso de sistemas 
complexos de software”.
23
A UML contempla uma representação gráfica para os vários elementos 
que permitem representar os conceitos do paradigma orientado a 
objetos, a partir de uma sintaxe e uma semântica. Segundo Bezerra 
(2014, p. 15), “a sintaxe de um elemento corresponde à forma 
predeterminada de desenhar o elemento. A semântica define o que 
significa o elemento e com que objetivo ele deve ser utilizado”.
Booch, Jacobson e Rumbaugh (2006) consideram as principais 
características da UML:
a. Centrada na arquitetura: a arquitetura do sistema incorpora os 
aspectos estáticos e dinâmicos mais importantes do sistema e é 
utilizada como principal artefato para a conceituação, construção, 
gerenciamento e evolução do sistema em desenvolvimento, 
representando uma visão do projeto como um todo.
b. Orientada a casos de uso: os casos de uso representam os 
requisitos funcionais do sistema e são utilizados como o principal 
artefato para definir o comportamento do sistema.
c. Processo iterativo: consiste no gerenciamento de sequências de 
versões executáveis e incrementais, definidas como iteração, 
sendo que cada nova versão incorpora os aprimoramentos 
incrementais em relação às demais.
Dependendo das características e da complexidade dos sistemas de 
software, é importante fornecer múltiplas visões da modelagem do 
sistema sob diferentes aspectos de análise e detalhamento. A UML 
privilegia a descrição da modelagem de sistemas de software em três 
perspectivas principais de visões: a estrutural, que enfatiza a visão 
estática do sistema, ou seja, os dados; a funcional, que prioriza as 
funcionalidades do sistema, enfatizando os requisitos funcionais; e a 
temporal, que prioriza a especificação dos eventos, representando o 
comportamento dos objetos em tempo de execução.
24
A UML 2.0 abrange as técnicas de modelagem classificadas em 
estrutural e comportamental.As técnicas de modelagem estruturais 
demonstram a estrutura dos elementos, a partir da identificação 
dos objetos, representando a modelagem com a visão estática do 
sistema. As técnicas de modelagem comportamentais representam 
o comportamento e a interação entre os elementos do sistema, 
representando a modelagem com a visão dinâmica do sistema. A 
perspectiva de interação representa um subgrupo dos diagramas 
comportamentais, que mostra a interação de como os objetos 
do sistema agem internamente para apoiarem a realização das 
funcionalidades representadas pelos casos de uso, conforme ilustra a 
Figura 1 a seguir.
Figura 1 – Classificação dos diagramas da UML
Fonte: elaborada pela autora.
25
A UML não faz grande distinção entre a modelagem das fases de análise 
e projeto de um processo de desenvolvimento de software. A atividade 
de projeto é uma extensão refinada dos diagramas elaborados na fase 
de análise, com detalhes de implementação. A seguir, será apresentada 
uma visão geral das técnicas de modelagem comportamentais e 
estruturais da UML.
1.1 Diagramas comportamentais da UML
As técnicas de modelagem comportamentais representam o 
comportamento e a interação entre os elementos do sistema, 
colaborando para modelagem da visão dinâmica do sistema. A seguir, 
será apresentado o objetivo de cada diagrama comportamental e um 
exemplo.
1.1.1 Diagrama de casos de uso
O diagrama de casos de uso (use cases) é o diagrama mais geral e 
informal da UML, que representa as funcionalidades ou serviços do 
software e suas interações com os atores do sistema. O diagrama 
apresenta uma linguagem de fácil compreensão para os usuários 
conhecerem como o sistema se comportará e serve de base para 
a especificação dos demais diagramas da UML, principalmente os 
diagramas comportamentais. Segundo Booch, Jacobson e Rumbaugh 
(2006), o diagrama de casos de uso representa os aspectos dinâmicos 
do sistema, mostrando um conjunto de casos de uso, atores e seus 
relacionamentos, tendo um papel central para a modelagem do 
comportamento de sistemas, subsistemas ou de classe.
O diagrama de casos de uso demonstra um conjunto de casos de uso, 
atores e seus relacionamentos, como mostra a Figura 2, como, por 
exemplo, o ator candidato, interagindo com os casos de uso manter 
26
candidato, manter currículo, manter instituição de ensino, realizar inscrição 
para vaga, realizar entrevista e emitir contrato de estágio.
Figura 2 – Exemplo de diagrama de casos de uso
Fonte: elaborada pela autora.
A representação do diagrama de casos de uso é complementada com 
a documentação de casos de uso, que pode ser demonstrada em 
formatos distintos, descrevendo os eventos que são disparados durante 
a execução do caso de uso, de forma textual detalhada ou não, contudo, 
respeitando uma sequência lógica temporal de execução dos eventos.
1.1.2 Diagrama de atividades
O diagrama de atividades demonstra o fluxo de controle de um conjunto 
de atividades que representa a execução de um procedimento, caso 
de uso, processo de negócio, subsistema ou até o sistema completo. 
Segundo Guedes (2018), o diagrama de atividades descreve os passos 
a serem percorridos para a realização de uma atividade específica, 
27
representando os métodos, algoritmos, ou até mesmo, um processo 
completo, concentrando-se na representação do fluxo de controle e de 
objetos que participam de uma atividade.
A Figura 3 ilustra um diagrama de atividade correspondente a um 
caso de uso realizar login, representando o fluxo das ações, a partir da 
primeira ação receber login e senha e finalizando com a ação acessar 
sistema e o nó final.
Figura 3 – Exemplo de diagrama de atividades
Fonte: elaborada pela autora.
1.1.3 Diagrama de máquina de estados
O diagrama de máquina de estados demonstra o comportamento de 
um elemento, por meio de um conjunto de transições de estados. Até a 
versão 1.5, da UML, o diagrama era conhecido como diagrama de gráfico 
de estados ou como diagrama de estados. Conforme Guedes (2018), o 
diagrama de máquina de estados demonstra o comportamento de um 
28
elemento, a partir de um conjunto finito de transições de estado que 
expressam o comportamento de um caso de uso ou de uma instância de 
uma classe, por exemplo.
A Figura 4 ilustra um diagrama de máquina de estados correspondente 
aos estados agendando, realizando, aprovando, reprovando e cancelando e 
suas transições de estados de uma instância da classe entrevista.
Figura 4 – Exemplo de diagrama de máquina de estados
Fonte: elaborada pela autora.
1.1.4 Diagrama de sequência
O diagrama de sequência representa a ordem temporal em que as 
mensagens são trocadas entre os objetos envolvidos na execução de um 
processo. O diagrama de sequência baseia-se no diagrama de casos de 
uso, elaborando, normalmente, um diagrama de sequência para cada 
caso de uso e apoiando-se no diagrama de classes para determinar 
os objetos das classes envolvidas no processo. Segundo Guedes 
29
(2018), o diagrama de sequência descreve a ordem temporal em que 
as mensagens são trocadas entre os objetos envolvidos na execução 
de um processo que representa um caso de uso, bem como no ator 
responsável pela interação com os objetos.
A Figura 5 ilustra um Diagrama de Sequência correspondente ao caso de 
uso realizar entrevista, representado o ator entrevistador, interagindo pela 
interface Form_Realizar Entrevista, que troca mensagens com os objetos 
das classes funcionário, candidato, vaga e entrevista.
Figura 5 – Exemplo de diagrama de sequência
Fonte: elaborada pela autora.
1.1.5 Diagrama de comunicação
O diagrama de comunicação representa o inter-relacionamento entre 
os objetos envolvidos na execução de um processo, a partir da troca 
de mensagens. Até a versão 1.5 da UML, o diagrama de comunicação 
30
era conhecido como o diagrama de colaboração. Segundo Guedes 
(2018), o diagrama de comunicação complementa o diagrama de 
sequência, concentrando-se na representação de como os elementos 
do diagrama estão vinculados e a ocorrência das mensagens que esses 
elementos trocam entre si durante a execução de um processo, não se 
preocupando com a temporalidade do processo.
A Figura 6 ilustra um diagrama de comunicação correspondente ao caso 
de uso realizar entrevista, demostrando a direção da troca de mensagens 
entre os objetos das classes funcionário, candidato, vaga e entrevista com 
a interface Form_Realizar Entrevista, e esta com o ator entrevistador.
Figura 6 – Exemplo de diagrama de comunicação
Fonte: elaborada pela autora.
1.1.6 Diagrama de visão geral de interação
O diagrama de visão geral de interação é uma variação do diagrama 
de atividades que integra diferentes tipos de diagramas de interação, 
demonstrando um processo geral. É um novo diagrama da UML 2.0. 
Nesse diagrama são utilizados dois tipos de quadros: os quadros de 
31
interação, que contém a representação completa de qualquer tipo 
de diagrama de interação; e os quadros de ocorrência de interação, 
que fazem uma referência a um diagrama de interação, contudo não 
apresentam seu detalhamento. Segundo Guedes (2018), o diagrama de 
visão geral de interação demonstra uma visão geral de um sistema ou 
processo, envolvendo vários subprocessos que interagem entre si, a 
partir de um fluxo, similar ao diagrama de atividades, utilizando quadros 
no lugar dos nós de ação.
A Figura 7 ilustra um diagrama de visão geral de interação, integrando 
quadros de ocorrência de interação dos seguintes diagramas de 
sequência: realizar inscrição para vaga, realizar entrevista, efetivar contrato 
de estágio e emitir contrato de estágio.
Figura 7 – Exemplo de diagrama de visão geral de interação
Fonte: elaborada pela autora.
32
1.1.7 Diagrama de tempo
O diagrama de tempo representa de forma concisa e simples à 
mudança no estado de um objeto durante um período de tempo. É 
um diagrama novo da UML 2.0. A Figura 8 ilustra um diagrama de 
tempo correspondente aos estados ElaborandoEdital, AbrindoInscrições, 
AplicandoProvaSeleção,AnalisandoProvas e PublicandoResultados, de 
um processo do contexto com a duração de cada estado, indicando o 
período das datas e para o estado AplicadoProvasSeleção, e também o 
horário de início e término.
Figura 8 – Exemplo de diagrama de tempo
Fonte: Guedes (2018, posição 810)
Segundo Guedes (2018), o diagrama de tempo ou de temporização 
demonstra a mudança no estado de um objeto, em um período 
específico de tempo em que um objeto executa algo importante, em 
resposta aos eventos disparados.
1.2 Diagramas Estruturais da UML
As técnicas de modelagem estruturais da UML demonstram a estrutura 
das classes e do software, a partir da identificação dos objetos do 
sistema, representando a modelagem com visão estática do sistema. A 
seguir, será apresentado o objetivo de cada diagrama estrutural e um 
exemplo.
33
1.2.1 Diagrama de pacotes
O diagrama de pacotes demonstra como os elementos do sistema estão 
organizados em pacotes e suas dependências, ou seja, categorizados 
em grupos de elementos que representam as partes do sistema, 
sendo que um pacote pode se subdividir em outros pacotes. Segundo 
Guedes (2018), o diagrama de pacotes representa como os elementos 
de um modelo estão divididos logicamente em pacotes, sendo que os 
elementos demonstram subsistemas, componentes ou as camadas que 
compõem o sistema. O diagrama pode ser especificado de maneira 
independente ou associado a outros diagramas da UML.
A Figura 9 exemplifica um diagrama de pacotes correspondentes aos 
pacotes negócio, consultas e relatórios e suas dependências, de um 
modelo de casos de uso.
Figura 9 – Exemplo de diagrama de pacotes
Fonte: elaborada pela autora.
34
1.2.2 Diagrama de classes
O diagrama de classes representa um conjunto de classes com seus 
atributos, operações e relacionamentos, demonstrando a modelagem 
da visão estática do projeto de um sistema. De acordo com Guedes 
(2018), o diagrama de classes demonstra uma visão estática das 
classes, com seus atributos e métodos, definindo-se a estrutura lógica 
e relacionamento entre as classes do sistema. O diagrama é um dos 
mais importantes e utilizados, servindo de apoio para especificação dos 
demais diagramas da UML.
A Figura 10 exemplifica um diagrama de classes com as classes cargo, 
vaga, empresa, inscrição, funcionário, entrevista, candidato e contrato 
e seus relacionamentos, sendo apenas relacionamentos do tipo 
associação binária entre as classes representadas.
Figura 10 – Exemplo de diagrama de classes
Fonte: elaborada pela autora.
35
1.2.3 Diagrama de objetos
O diagrama de objetos representa instâncias do diagrama de classes, 
a partir da descrição dos valores dos atributos dos objetos e os 
vínculos estabelecidos entre os objetos. A utilização deste diagrama é 
opcional. Segundo Guedes (2018), o diagrama de objetos representa 
uma visão dos valores armazenados pelos objetos de uma classe 
em um determinado instante de tempo. O diagrama está associado 
exclusivamente ao diagrama de classes.
A Figura 11 apresenta um exemplo do diagrama de objetos, 
representando um objeto do tipo pessoa física, vinculado a um objeto do 
tipo conta especial.
Figura 11 – Exemplo de diagrama de objetos
Fonte: Guedes (2018, posição 4790) .
1.2.4 Diagrama de estrutura composta
O diagrama de estrutura composta representa as colaborações entre 
elementos que cooperam entre si para executarem uma função 
específica. É um novo diagrama da UML 2.0. De acordo com Guedes 
(2008), o diagrama de estrutura composta representa a estrutura interna 
de uma classe, componente ou uma colaboração entre um conjunto 
de instâncias que coopera entre si para realizar uma tarefa, a partir da 
descrição das partes que o compõem e se comunicam.
36
A Figura 12 ilustra um diagrama de estrutura composta, considerando 
a colaboração realizar entrevista com as instâncias – funcionário, vaga, 
candidato, contrato e entrevista, que cooperam para realizar a tarefa.
Figura 12 – Exemplo de diagrama de estrutura composta
Fonte: elaborada pela autora.
1.2.5 Diagrama de componentes
O diagrama de componentes representa os aspectos físicos do sistema, 
demonstrando a visão estática de implementação do sistema, a partir 
da reutilização de componentes. De acordo com Guedes (2018), o 
diagrama de componentes representa os componentes que fazem parte 
de um sistema ou mesmo os componentes ou classes internas de um 
componente lógico ou físico.
37
A Figura 13 ilustra um exemplo do diagrama de componentes, com os 
componentes de software pessoa e candidato e as três interfaces do 
componente candidato.
Figura 13 – Exemplo de diagrama de componentes
Fonte: elaborada pela autora.
1.2.6 Diagrama de implantação
O diagrama de implantação demonstra a organização da arquitetura 
física do sistema, a partir da representação de nós e suas ligações 
físicas. Um nó pode representar um item de hardware do sistema ou 
um outro dispositivo integrado ao sistema e também os ambientes de 
execução que integram o sistema. Segundo Guedes (2018), o diagrama 
de implantação representa o aparato físico necessário para executar o 
sistema, demonstrando os elementos de hardware do sistema, como 
os servidores, estações, topologias e protocolos de comunicação, bem 
como a comunicação entre esses elementos. O diagrama também 
pode representar a distribuição dos módulos do sistema quando são 
executados em servidores distintos.
38
A Figura 14 representa a associação entre o nó do tipo dispositivo, 
hardware do candidato, com os nós do tipo ambiente de execução 
servidor de comunicação, servidor firewall, servidor de aplicação e servidor 
de BD.
Figura 14 – Exemplo de diagrama de implantação
Fonte: elaborada pela autora.
1.2.7 Diagrama de perfil
O diagrama de perfil demonstra a criação de uma extensão da notação 
da UML para domínios de software com características específicas, 
representadas por estereótipos. O diagrama foi introduzido na UML 2.5. 
Segundo Guedes (2018), o diagrama de perfil é um diagrama abstrato 
que permite adaptar a notação da UML a uma nova plataforma com 
características, tecnologias ou domínio específico, a partir da criação de 
perfis que representam a extensão da linguagem para criação de novas 
metaclasses e estereótipos, permitindo, assim, a modelagem desses 
novos domínios.
A Figura 15 mostra um diagrama de perfil que exemplifica a criação do 
estereótipo InternetActor, específico para o domínio de aplicações web, 
associada a metaclasse Actor da notação padrão da UML.
39
Figura 15 – Exemplo de diagrama de perfil
Fonte: Guedes (2018, posição 7706)
Referências Bibliográficas
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com 
UML. 3. ed. Rio de Janeiro: Elsevier, 2014.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do 
usuário. 2. ed. Rio de Janeiro: Campus, 2006.
GUEDES, Gilleanes T. A. UML: uma abordagem prática. 3. ed. São Paulo: 
Novatec, 2018.
40
Modelagem comportamental 
da análise com a Linguagem de 
Modelagem Unificada (UML)
Autoria: Iolanda Cláudia Sanches Catarino
Leitura crítica: Rogério Colpani
Objetivos
• Compreender as principais técnicas de modelagem 
comportamentais da UML para documentar a fase 
de análise de um processo de desenvolvimento de 
software.
• Aplicar as principais técnicas de modelagem 
comportamentais da UML para documentar a 
perspectiva da visão dinâmica do software.
• Compreender a integração e consistência entre as 
principais técnicas de modelagem comportamentais 
da UML.
41
1. Diagrama de casos de uso
Independente do modelo de processo de engenharia de software, 
tradicionais ou ágeis, que indica um fluxo de trabalho organizado para o 
desenvolvimento de sistemas de software, a Linguagem de Modelagem 
Unificada (UML – Unified Modeling Language) não define quais de 
suas técnicas de modelagem devem ser adotadas para documentar 
exatamente uma fase ou atividade de um processo de desenvolvimento. 
Toda definição do que, quando e como será desenvolvido um sistema, 
faz parte decada metodologia que uma empresa ou equipe de 
desenvolvimento estabelece, em consonância com as boas práticas 
da engenharia de software, para atender os diferentes domínios de 
aplicações e soluções computacionais.
A técnica de modelagem comportamental, diagrama de casos de 
uso (use cases), pode ser adotada para documentar a modelagem de 
negócio do sistema, a modelagem conceitual de análise de requisitos 
e, principalmente, a modelagem lógica e funcional da fase de análise, 
representando um refinamento da especificação dos requisitos 
funcionais do sistema com o objetivo de representar os serviços, tarefas 
ou funcionalidades do software.
A técnica de modelagem de casos de uso foi idealizada, em 1970, pelo 
cientista da computação, Ivar Jacobson. A partir da incorporação da 
notação do diagrama de casos de uso à UML, esta técnica tornou-se 
cada vez mais popular na representação dos requisitos funcionais de um 
software, devido sua notação gráfica ser simples, de fácil compreensão e 
sua documentação ser apresentada em linguagem natural, o que facilita 
a comunicação entre a equipe técnica e os usuários do domínio do 
sistema, segundo Bezerra (2014).
Segundo Booch, Rumbaugh e Jacobson (2006, p. 232) o diagrama de 
caso de uso pode ser aplicado “para visualizar o comportamento de um 
42
sistema, subsistema ou classe, para que os usuários possam entender 
como utilizar esse elemento e os desenvolvedores possam implementá-
lo” e representa os aspectos dinâmicos do sistema, mostrando um 
conjunto de casos de uso, atores e seus relacionamentos. De acordo 
com Guedes (2018), o diagrama de casos de uso representa uma visão 
externa das funcionalidades do sistema, sem demonstrar a forma como 
tais funcionalidades são implementadas, a partir da indicação dos atores 
que interagem com os casos de uso. Para Bezerra (2014), o Modelo de 
Casos de Uso (MCU):
A documentação do diagrama de casos de uso é complementada com a 
documentação de casos de uso, descrevendo os cenários de execução de cada 
caso de uso, geralmente, de forma textual ou tabulada. A UML não padroniza um 
único formato dessa documentação e nem o nível de detalhamento da descrição 
da funcionalidade.
O diagrama de casos de uso serve de base para a especificação 
dos demais diagramas da UML, principalmente os diagramas 
comportamentais. Na elaboração do diagrama de casos de uso, os casos 
de usos podem ser categorizados e agrupados em pacotes, dependendo 
da quantidade de casos de uso identificados, representando um 
diagrama para cada pacote e, assim, consistindo em um modelo de 
casos de uso, ou seja, um conjunto de diagrama de casos de uso.
Os elementos básicos da notação do diagrama de casos de uso são:
• Sistema: representa a modelagem da fronteira do sistema, sendo 
que os atores são desenhados do lado de fora e os casos de 
uso são desenhados dentro do retângulo, indicando uma ideia 
visual clara da fronteira do sistema. A fronteira do sistema é 
representada por retângulo grande.
• Ator: representa qualquer elemento externo ao sistema que 
interage com as funcionalidades do sistema, podendo ser 
pessoas, hardware, dispositivo, outro sistema etc. Os atores são 
43
representados por símbolos de bonecos magros, identificados 
com um nome que representa qual o papel que o ator assume no 
contexto do sistema, sendo que cada ator deve representar um 
único papel.
• Caso de uso: representa um relato de uso de uma funcionalidade 
do sistema, sem revelar seu comportamento interno. Os casos 
de uso são representados por uma elipse com um nome dentro 
do seu símbolo, identificando qual serviço o caso de uso assume. 
Recomenda-se nomear os casos de uso com verbo no infinitivo 
mais substantivo(s). Exemplo: manter cliente, reservar veículo, 
gerar relatório de clientes.
• Associação: representa um relacionamento de comunicação entre 
ator e os casos de uso, indicando uma interação com o sistema.
• Generalização: é um tipo de relacionamento que representa o 
reuso de comportamento existente entre casos de uso ou entre 
atores. A generalização de atores é uma representação abstrata de 
papéis que assumem como função no sistema.
• Extensão: é um tipo de relacionamento de dependência existente 
somente entre casos de uso. O caso de uso estendido é uma 
descrição completa de uma sequência de interações, com 
significado em si mesmo. O relacionamento de dependência, 
representado pelo estereótipo <<extend>>, é indicado por uma 
seta que parte do caso de uso estendido para o caso de uso base, 
que tem interação com o ator.
• Inclusão: é um tipo de relacionamento existente somente entre 
casos de uso para indicar a continuidade de execução obrigatória 
entre os casos de uso. O relacionamento de dependência, 
representado pelo estereótipo <<include>>, é representado por 
uma seta que parte do caso de uso base para o caso de uso 
incluído.
44
A Figura 1 ilustra um exemplo de diagrama de casos de uso com a 
indicação de seus elementos. O elemento indicado com o número 1 
representa a fronteira do sistema. O elemento 2 representa o ator 
coordenador. O elemento 3 representa um caso de uso nomeado como 
manter evento de extensão. O elemento 4 representa um relacionamento 
do tipo generalização de casos de uso, já o elemento 5 representa 
um relacionamento do tipo generalização de atores. O elemento 6 
representa um relacionamento de dependência entre casos de uso do 
tipo inclusão; e o elemento 7 indica um relacionamento de dependência 
do tipo extensão.
Figura 1 – Exemplo de diagrama de casos de uso e seus elementos
Fonte: elaborada pela autora.
45
2. Diagrama de atividades
A técnica de modelagem comportamental, diagrama de atividades, 
demonstra o fluxo de controle de um conjunto de atividades que 
representa a execução de procedimentos, casos de uso, processos 
de negócio, subsistemas ou até o sistema completo. Considerando 
que os casos de uso foram especificados, é importante evoluir com a 
modelagem comportamental do software para melhor compreensão da 
lógica de funcionamento dos serviços do sistema.
Segundo Guedes (2018), o diagrama de atividades descreve os passos 
a serem percorridos para a realização de uma atividade específica, 
representando os métodos, algoritmos, ou até mesmo um processo 
completo, concentrando-se na representação do fluxo de controle e 
de objetos que participam de uma atividade. Para Bezerra (2014, p. 
307), o diagrama de atividades “pode ser visto como uma extensão 
dos fluxogramas. Além de possuir toda a semântica existente em um 
fluxograma, o diagrama de atividade possui notação para representar 
ações concorrentes, juntamente com a sua sincronização”.
Os elementos de um diagrama de atividades podem ser divididos para 
demonstrarem fluxos de controle sequenciais ou simples e os fluxos de 
controle paralelos, também denominados de simultâneos. Nesse caso, 
deve-se utilizar as barras de sincronização do tipo bifurcação (fork) ou 
barra de união (join). O diagrama também pode ser representado com o 
uso de raias (swinlanes), equivalentes a compartimentos, que dividem o 
diagrama com o fluxo de suas atividades ou ações sendo realizadas por 
um ator específico em cada compartimento.
Os elementos básicos da notação do diagrama de atividades são:
• Atividade: representa a sequência de tarefas em um fluxo de 
trabalho que resulta em um comportamento de um processo. Uma 
atividade é composta por um conjunto de ações e representada 
46
por um retângulo grande com bordas arredondadas, com um 
nome que descreve a atividade na perspectiva de execução do 
sistema, geralmente, usa-se um verbo no infinitivo.
• Nó de ação: representa um único passo de execução imediata de 
uma atividade, sendo o elemento mais básico de uma atividade, 
ou seja, não pode ser decomposto. Um nó de ação é representado 
por um retângulo pequeno com bordas arredondadas, com um 
nome que também descreve a ação na perspectiva de execução do 
sistema, geralmente, usa-se um verbo no infinitivo.
• Nó inicial: representao início do fluxo da atividade, indicando a 
primeira ação executada da atividade, sendo representado por um 
círculo preenchido. O diagrama de atividades deve ter um nó inicial 
obrigatoriamente.
• Nó final: representa o fim do fluxo de uma atividade, é 
representado por um círculo preenchido dentro de um círculo 
vazio. Um diagrama de atividades pode ter um ou mais nós finais.
• Nó de decisão: representa uma escolha entre dois ou mais fluxos, 
a partir de uma entrada e duas ou mais saídas. Um nó de decisão 
é acompanhado, obrigatoriamente, por condições de guarda que 
indicam a condição para que um fluxo possa ser escolhido. Um 
nó de decisão é representado por um losango com dois ou mais 
fluxos de escolha, cada um acompanhando pela descrição da 
condição de guarda entre colchetes.
• Nó de objeto: representa uma instância de uma classe gerada 
ou acessada pela atividade, a partir de um fluxo de objeto. São 
representados como um retângulo com o nome do objeto.
• Fluxo de controle: representa um conector com direcionamento 
que liga dois nós, enviando sinais de controle do fluxo sequencial 
de execução da atividade. É representado por uma reta contendo 
47
uma seta, podendo conter uma descrição, uma condição de guarda 
ou uma restrição.
• Fluxo de objeto: representa um conector com direcionamento, 
indicado objetos ou dados enviados por meio dele, ou seja, entre 
o nó de ação e o nó de objeto. O fluxo de objeto pode ser utilizado 
para modificar o estado de um objeto.
• Nó de bifurcação (fork): ocorre quando há um fluxo de entrada 
e vários fluxos de saída concorrentes. O nó de bifurcação é 
representado por uma barra espessa na horizontal ou vertical, com 
a indicação de seus fluxos.
• Nó de união (join): ocorre quando há dois ou mais fluxos de 
entrada e um único fluxo de saída. O nó de união também é 
representado por uma barra espessa na horizontal ou vertical, com 
a indicação dos seus fluxos.
• Partições de atividade (swinlanes): permitem representar o fluxo 
de um processo que interage por diferentes atores que participam 
das atividades. As partições são representadas por retângulos 
longos no formato de compartimentos.
A Figura 2 ilustra um exemplo de diagrama de atividades 
correspondente a atividade processar pedido com a indicação de seus 
elementos.
48
Figura 2 – Exemplo de diagrama de atividades e seus elementos
Fonte: elaborada pela autora.
O elemento indicado com o número 1 representa a atividade processar 
pedido, sendo composta por um conjunto de ações. O elemento 2 
representa o nó inicial da atividade. O elemento 3 representa um nó de 
ação nomeado de receber pedido, que acessa um nó de objeto ordem de 
pedido, representado pelo elemento número 4, a partir de um fluxo de 
objeto. O elemento 5 representa o elemento fluxo de controle, indicando 
a próxima ação a ser executada. O elemento 6 representa um nó de 
decisão com duas decisões, cada uma indicada por uma condição de 
guarda. O elemento 7 representa um nó de bifurcação com uma entrada 
e dois fluxos de saída concorrentes; já o elemento 8, representa um nó 
de união, indicando dois fluxos de entrada e um único fluxo de saída. 
Por fim, o elemento 9 representa o nó final que indica o fim do fluxo da 
atividade.
3. Diagrama de máquina de estados
A técnica de modelagem comportamental, diagrama de máquina de 
estados, demonstra o comportamento dinâmico de um elemento, 
49
por meio de um conjunto de transições de estados realizadas entre 
os estados finitos de objetos de uma classe, de um caso de uso, ou 
mesmo de sistema completo. Geralmente, o diagrama é adotado nas 
fases de análise e projeto de desenvolvimento de um software, que 
é recomendável que seja utilizado para documentar a mudança de 
estados dos objetos de classes com estados representativos.
Segundo Booch, Jacobson e Rumbaugh (2006, p. 285), o diagrama de 
máquina de estados representa “um comportamento que especifica as 
sequências de estados pelos quais um objeto passa durante seu tempo 
de vida em resposta a eventos, juntamente com suas respostas a esses 
eventos”. De acordo com Guedes (2018), o diagrama de máquina de 
estados demonstra o comportamento de um elemento, geralmente, 
uma instância de uma classe, a partir de um conjunto finito de transições 
de estado. No entanto, pode-se usar o diagrama para modelar também 
o comportamento de um caso de uso. E para Bezerra (2018, p. 287), o 
diagrama de máquina de estados “permite descrever o ciclo de vida de 
objetos de uma classe, os eventos que causam a transição de um estado 
para outro e a realização de operações resultantes”.
Na elaboração do diagrama de máquina de estados, é importante 
identificar as regras de negócio aplicadas ao contexto dos objetos, a 
fim de auxiliar na definição dos seus estados e transições, que são os 
elementos básicos do diagrama. Um estado representa a abstração de 
uma forma de apresentação dos objetos por uma quantidade finita de 
tempo. Na definição de Booch, Rumbaugh e Jacobson (2006, p. 290), 
um estado é “uma condição ou situação na vida de um objeto durante 
a qual o objeto satisfaz alguma condição, realiza alguma atividade ou 
aguarda um evento”. A transição de estado demonstra a mudança 
de estado de um objeto como resposta a um evento, sendo que as 
transições de estados podem indicar condições de guarda e descrições. 
Os eventos são os acontecimentos que provocam a transição de estado. 
Na definição de Rumbaugh (1997), um evento é um estímulo individual 
50
de um objeto para outro, sendo uma transmissão ou informação 
unidirecional que acontece em certo momento.
Os elementos básicos da notação do diagrama de máquina de estados 
são:
• Estado: representa uma situação durante a manipulação de um 
objeto, por um instante finito de tempo, que satisfaz alguma 
condição ou realiza alguma atividade. Um estado é representado 
por um retângulo com bordas arredondadas com um nome único, 
com ações de entrada e saída, se necessário, e de representação 
não obrigatória, indicadas pelas cláusulas entry, que representa as 
ações realizadas no momento em que o objeto assume o estado. 
A cláusula exit representa as ações executadas antes do objeto 
mudar de estado e a cláusula do representa uma atividade do 
estado executada durante o tempo em que o objeto se encontra 
no estado, e pode conter também transições internas que indicam 
operações que não causam alteração na situação do estado.
• Transição: representa um relacionamento entre dois estados, 
indicando a mudança de estado a partir da ocorrência de um 
evento. A transição é representada por uma linha com uma seta na 
extremidade, apontando para um dos estados.
• Estado inicial: representa o estado inicial da máquina de estados, 
sendo único. É representado por um círculo preenchido.
• Estado final: representa o fim do ciclo dos estados que compõem a 
máquina de estados. Este estado é opcional e pode conter mais de 
um estado final em um mesmo diagrama. É representado por um 
círculo preenchido dentro de um círculo vazio.
• Pseudoestado de escolha: representa uma decisão com a indicação 
dos estados, que podem ser gerados a partir de uma condição 
de guarda. Um pseudoestado de escolha é representado por um 
51
losango com duas ou mais transições, cada uma acompanhada 
pela descrição da condição de guarda entre colchetes.
• Estado composto: indica que um estado contém internamente dois 
ou mais estados com suas transições, gerados independentes ou 
não. É uma forma de simplificar a representação da máquina de 
estados, a partir do detalhamento de um estado principal.
A Figura 3 ilustra um exemplo de diagrama de máquina de estados 
correspondente aos objetos da classe inscrição, com a indicação de seus 
elementos.
Figura 3 – Exemplo de diagrama de máquina de estados e seus 
elementos
Fonte: elaborada pela autora.
52
O elemento 1 representa o estado inicial, que indica o primeiro estado 
que os objetos assumem. O elemento 2 representa o estado realizando 
inscrição, com a indicaçãode uma transição de estado, representada 
pelo número 3, para um pseudoestado de escolha, indicado pelo 
elemento 4. Por fim, o elemento 5 representa o estado final, indicando o 
final do ciclo da máquina de estados.
4. Diagrama de sequência
A técnica de modelagem comportamental, diagrama de sequência, 
é uma técnica do subgrupo de diagramas de interação da UML, que 
representa a ordem temporal em que as mensagens são trocadas 
para darem suporte à realização de um caso de uso. Na modelagem 
da fase de análise, recomenda-se utilizar o diagrama de sequência 
para descrever o cenário dos casos de uso e identificar os objetos 
que colaboram entre si, além das mensagens e informações que 
são enviadas nas mensagens de um objeto a outro. Geralmente, na 
modelagem da fase de projeto, refina-se a notação dos diagramas de 
sequência em conformidade com a arquitetura do sistema e padrões de 
implementação.
Segundo Guedes (2018), o diagrama de sequência descreve a ordem 
temporal em que as mensagens são trocadas entre os objetos 
envolvidos na execução de um processo que representa um caso de 
uso, bem como, no ator responsável pela interação com os objetos. 
Conforme Bezerra (2018, p. 193), “o objetivo do diagrama de sequência é 
apresentar as interações entre objetos na ordem temporal em que elas 
acontecem”. Para Booch, Jacobson e Rumbaugh (2006), o diagrama de 
sequência:
É um diagrama de interação que dá ênfase à ordenação temporal das 
mensagens. Graficamente, um diagrama de sequência é uma tabela que 
53
mostra objetos distribuídos no eixo X e mensagens, em ordem crescente 
no tempo, no eixo Y. (BEZERRA, 2006, p. 243) 
Os elementos básicos da notação do diagrama de sequência são:
• Linha de vida: representa a existência de um elemento (objeto ou 
ator) participante da realização do caso de uso em um período de 
tempo. É representada por uma linha vertical tracejada abaixo do 
elemento.
• Ator: os atores são os mesmos já criados no diagrama de casos 
de uso, são apoiados por uma linha de vida e enviam mensagens 
para os objetos como uma forma de interação para solicitarem 
a execução de uma operação ou simplesmente o envio de 
informações.
• Objeto: representa os objetos que participam da realização 
do caso de uso também apoiados por uma linha de vida, que 
juntamente com os atores formam um cabeçalho para o diagrama. 
Um objeto pode existir desde o início da interação ou ser criado ao 
longo da interação. Um objeto é representado por um retângulo 
com um nome único, conforme o padrão da notação de objeto, ou 
também pode ser representado por ícones que representam os 
estereótipos do tipo: fronteira <<boundary>>; classe <<entity>>; ou 
controlador <<control>>.
• Foco de controle: representa o período de tempo durante o 
qual um elemento executa uma ação, diretamente ou não. É 
representado por um retângulo estreito na vertical sobre a linha de 
vida, podendo aparecer diversas vezes ao longo da linha de vida.
• Mensagem ou estímulo: representa a solicitação que um 
elemento envia para o outro, com o objetivo de executar uma 
ação, demonstrando a ocorrência de eventos. Uma mensagem 
é representada por uma linha horizontal com uma seta na 
54
extremidade. A troca de mensagens pode acontecer entre os 
elementos: ator e ator, indica uma comunicação entre os atores; 
ator e objeto, geralmente o ator provoca um evento, enviando 
uma mensagem que dispara uma operação, contudo, o ator 
pode simplesmente transmitir uma informação sem disparar 
uma operação; objeto e objeto, indica o envio de uma mensagem, 
disparando uma operação, sendo que um objeto pode enviar 
uma mensagem para si mesmo, denominada de autochamada; e 
objeto e ator, que indica o retorno de uma mensagem com o seu 
resultado. As mensagens de retorno são representadas por uma 
linha tracejada com a seta na extremidade, apontando para o 
elemento que recebe a resposta.
• Mensagem síncrona: a mensagem é síncrona quando o emissor 
aguarda o retorno para continuar com a interação. Geralmente, 
são as mensagens comumente utilizadas no diagrama de 
sequência. É representada com a seta sólida.
• Mensagem assíncrona: a mensagem é assíncrona quando o 
emissor continua enviando mensagens sem aguardar o retorno, 
com isso, o elemento receptor da mensagem assíncrona não 
precisa atendê-la imediatamente. É representada por uma seta 
aberta.
A Figura 4 ilustra um exemplo de diagrama de sequência 
correspondente ao cenário principal do caso de uso realizar inscrição do 
evento, com a indicação de seus elementos. O elemento 1 representa o 
ator participante, já indicado no diagrama de casos de uso. O elemento 2 
representa o elemento linha de vida, que acompanha cada objeto ou ator 
do diagrama. O elemento 3 representa o objeto evento e, na sequência, 
os demais objetos pessoa e inscrição. O elemento 4 representa o foco 
de controle sobre a linha de vida do ator participante. O elemento 5 
representa uma mensagem enviada pelo ator participante e recebida 
pelo objeto tela inscrição, que não dispara nenhuma operação, contudo, 
a mensagem identificada pela numeração 3.1 carregarEvento( ), enviada 
55
pelo objeto Tela Inscrição para o objeto ControladorInscricao, é uma 
mensagem síncrona que dispara a operação carregarEvento( ).
Figura 4 – Exemplo de diagrama de sequência e seus elementos
Fonte: elaborada pela autora.
Na representação do diagrama de sequência, também é possível utilizar 
fragmentos combinados ou fragmentos de interação que possibilitam 
o alinhamento de interações, sendo que cada fragmento representa 
uma interação independente. Recomenda-se representar os fragmentos 
apenas se de fato contribuírem com a compreensão da interação. 
Segundo Guedes (2018), os fragmentos combinados são representados 
por um retângulo que determina a área de abrangência do fragmento 
no diagrama, contendo uma subdivisão no canto superior esquerda, a 
56
fim de identificar a descrição do fragmento e seu operador de interação, 
que define o tipo de fragmento.
Referências Bibliográficas
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com 
UML. 3. ed. Rio de Janeiro: Elsevier, 2014.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do 
usuário.  2. ed. Rio de Janeiro: Campus, 2006.
GUEDES, Gilleanes T. A. UML: uma abordagem prática. 3. ed. São Paulo: 
Novatec, 2018.
RUMBAUGH, James et al. Modelagem e projetos baseados em 
objetos. Rio de Janeiro: Campus, 1997. 
57
Modelagem estrutural da análise 
com a Linguagem de Modelagem 
Unificada (UML)
Autoria: Iolanda Cláudia Sanches Catarino
Leitura crítica: Rogério Colpani
Objetivos
• Compreender as principais técnicas de modelagem 
estruturais da UML para documentar a fase de 
análise de um processo de desenvolvimento de 
software.
• Aplicar as principais técnicas de modelagem 
estruturais da UML para documentar a perspectiva 
da visão estática do software.
• Compreender a integração e consistência entre as 
principais técnicas de modelagem estrutural da UML.
58
1. Diagrama de pacotes
As técnicas de modelagem estruturais da Linguagem de Modelagem 
Unificada (UML) representam a perspectiva da visão estática dos 
objetos do sistema, enfatizando a estrutura das classes e do software. 
Na análise, a partir da compreensão do domínio do problema, é 
fundamental delimitar o escopo do projeto de software e, com isso, 
dimensionar as partes que integram o sistema.
A técnica de modelagem estrutural, diagrama de pacotes, demonstra 
os elementos do sistema agrupados e organizados em pacotes lógicos 
ou físicos, com o objetivo de representar os componentes ou módulos 
que integram um sistema e suas dependências. O diagrama de pacotes 
também pode ser utilizado para compor outros diagramas da UML em 
modelos, como, por exemplo, a partir da identificação da quantidade de 
casos de uso do sistema, pode-se optar em classificá-los por assunto e 
dividi-los em pacotes, dessa forma, para cada pacote especifica-se um 
diagrama de casos de uso.
Segundo Booch, Jacobson e Rumbaugh(2006, p. 169), “um pacote é um 
mecanismo de propósito geral para a organização de elementos em 
grupos. Um pacote é representado graficamente como uma pasta com 
uma guia”. Para Bezerra (2014), um pacote é um mecanismo utilizado 
para agrupar elementos semanticamente relacionados, inclusive 
outros pacotes, sendo que as ligações entre pacotes são indicadas pelo 
relacionamento de dependência entre pacotes.
A notação do diagrama de pacotes consiste na representação dos 
pacotes e suas ligações, que é demonstrado pelo relacionamento do tipo 
dependência, sendo uma linha tracejada com direção. Cada pacote deve 
ser identificado por um nome único e um pacote pode agrupar outros 
pacotes.
59
A Figura 1 exemplifica um diagrama de pacotes, demonstrando o 
conteúdo e as dependências entre os pacotes. É ilustrado um pacote 
nomeado de evento, identificado pelo número 1, composto pelos 
pacotes Usuario e negocio, sendo que o pacote Usuario contém as classes 
empresa, Funcionario, visitante, participante e InstituiEensino, e o pacote 
negocio depende de algum elemento do pacote usuário, identificado pelo 
número 2, que representa o relacionamento de dependência entre os 
dois pacotes. A figura ainda representa a dependência entre os pacotes 
evento e curso, em que o pacote curso contém os pacotes Formacao e 
Extensao, indicado pelo ícone de pacote, identificado pelo número 3, 
sendo outra forma de exibir o agrupamento de pacotes.
Figura 1 – Exemplo de diagrama de pacotes
Fonte: elaborada pela autora.
2. Diagrama de classes
A partir da especificação dos casos de uso, inicia-se a identificação e 
definição das classes de objetos e a elaboração do modelo de classes 
para demonstrar o aspecto estático das colaborações, que permite 
compreender como o sistema está estruturado internamente. O 
modelo de classes abrange um conjunto de diagramas de classes, que 
60
é considerada a principal técnica de modelagem estrutural da UML, e 
é utilizada durante a maior parte do desenvolvimento iterativo de um 
software orientado a objetos.
Durante a atividade de análise e projeto de um modelo de processo 
de software, como, por exemplo, o processo unificado, recomenda-se 
que, na medida em que o sistema é desenvolvido, o modelo de classes 
seja incrementado com novos detalhes de notação, refinando-o até a 
atividade de implementação. Dessa forma, o modelo de classes pode 
apresentar vários níveis de abstração ou versões.
Segundo Guedes (2018), o diagrama de classes permite a visualização 
das classes utilizadas pelo sistema e como estas se relacionam. Esse 
diagrama apresenta uma visão estática de como as classes estão 
organizadas, preocupando-se em definir sua estrutura lógica. Para 
Bezerra (2014), o diagrama de classes é utilizado na construção 
do modelo de classes, iniciando no nível de análise até o nível da 
especificação, sendo considerado o mais rico em termos de notação.
A seguir, será apresentada a estrutura das classes, bem como os tipos 
de relacionamentos entre as classes.
2.1 Classes
Uma classe representa um grupo de objetos do mundo real que 
compartilha os mesmos atributos, operações e semântica, e é 
representada graficamente por um retângulo com três partes, no 
máximo.
Na primeira parte, exibe-se o nome da classe, geralmente, um 
substantivo ou expressões breves, devendo ser único no modelo de 
classes. Por convenção, o nome é apresentado no singular e com as 
palavras compostas, usa-se concatená-las, começando cada palavra 
por letra maiúscula. Na segunda parte, são declarados os atributos que 
61
representam os dados do objeto, sendo nomeados por substantivos ou 
expressões que representam alguma propriedade da classe, tipicamente 
em letra minúscula, e, para palavras compostas, usa-se concatená-las, 
sendo que, a partir da segunda palavra, inicia-se com letra maiúscula, 
por exemplo, estadoCivil e razaoSocial. Na terceira parte, são declaradas 
as operações que correspondem às ações dos objetos, nomeadas por 
um verbo ou uma locução verbal breve, usando a mesma convenção 
de letras minúsculas e maiúsculas dos atributos, como, por exemplo, 
criarCliente e validarCpf.
A Figura 2 ilustra a notação de classes e suas formas de representação, 
suprimindo alguma parte ou não.
Figura 2 – Exemplo de representação de classes
Fonte: elaborada pela autora.
Na representação dos atributos e operações de uma classe, indica-se 
também, à esquerda do nome dos mesmos, o símbolo da visibilidade 
que determina o nível de acessibilidade de um atributo ou operação por 
outros objetos. Existem basicamente quatro tipos de visibilidade, sendo:
• Privada: é representada por um símbolo de menos (-) e indica que 
somente os objetos da própria classe podem enxergá-la.
• Pública: é representada por um símbolo de mais (+) e indica que 
qualquer objeto pode utilizar o objeto acessado.
62
• Protegida: é representada pelo símbolo de sustenido (#) e indica 
que além dos objetos da própria classe, os objetos das subclasses 
também podem ter acesso ao objeto da superclasse.
• Pacote: é representado pelo símbolo de til (~) e indica que o 
atributo ou operação é visível por qualquer objeto do mesmo 
pacote.
Na elaboração de cada versão do diagrama de classes, a partir da 
identificação e definição das classes, deve-se verificar a consistência 
entre as classes e os casos de usos já especificados e, assim, 
observar a necessidade de novas classes ou eliminar redundâncias e 
inconsistências. Algumas técnicas que se destacam para identificação 
das classes são:
• Análise de casos de uso: preconizada pelo modelo de processo 
de software Rational Unified Process (RUP), seguindo os passos 
de: fazer a descrição de cada caso de uso; para cada caso de uso, 
identificam-se as classes, a partir do comportamento do caso de 
uso, descrevendo suas responsabilidades, atributos e associações; 
unificam-se as classes de análise identificadas em um ou mais 
diagramas de classes.
• Análise textual de Abbott: utilizam-se diversas fontes de 
informação sobre o sistema, como, por exemplo, documento de 
requisitos e modelo de negócio, sendo que, para cada um desses 
documentos, destacam-se os nomes com substantivos e adjetivos 
e os sinônimos são removidos. Cada termo remanescente pode se 
tornar uma classe candidata, um atributo ou ser descartado. Nos 
documentos, os termos que indicam verbos são destacados para 
identificar as operações e associações de uma classe.
• Cartões Classes, Responsabilidades e Colaboradores (CRC): 
utiliza-se de cartão CRC, no formato de tabela, para representar 
as classes identificadas, a partir do comportamento dos objetos, 
63
especificando as características e responsabilidades de cada 
objeto.
• Taxonomia de conceitos: identificam-se e analisam-se conceitos 
abstratos e concretos, papéis desempenhados por seres humanos, 
eventos que representam ocorrências em um determinado 
período de tempo, indicação de lugares e ambientes, organizações 
que demonstram coleções de pessoas ou de recursos etc.
2.2 Relacionamentos
Na UML, os modos pelos quais os itens elementos dos diagramas podem 
estar conectados a outros, isto é, logicamente ou fisicamente, são 
modelados como relacionamentos, sendo representados graficamente 
como um caminho, com tipos diferentes de linhas utilizadas para 
diferenciar os relacionamentos (Booch, Jacobson e Rumbaugh, 2006).
No diagrama de classes, além da representação das classes, 
estabelecem-se os relacionamentos entre as classes, que indicam o 
compartilhamento de informações entre os objetos das classes, por 
meio da troca de mensagens entre os objetos, em tempo de execução 
do sistema. Na modelagem orientada a objetos, existem quatro tipos de 
relacionamentos, que são os mais importantes, sendo:
• Associação: são relacionamentos estruturais que conectam os 
objetos entre as classes, podendo ser associação do tipo: unária 
(também denominada de reflexiva ou auto-associação), binária, 
ternária classe associativa (também denominada de classe de 
associação)