WBA0448_v1.

MODELAGEM DO SISTEMA
COM A ANÁLISE ORIENTADA
A OBJETOS
 Iolanda Cláudia Sanches Catarino

MODELAGEM DO SISTEMA COM A ANÁLISE

ORIENTADA A OBJETOS
1ª edição

Londrina
Editora e Distribuidora Educacional S.A.
2020

2
 © 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.

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
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/

3
MODELAGEM DO SISTEMA COM A ANÁLISE ORIENTADA A
OBJETOS

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

4
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.

5
 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.

6
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

7
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 (casos de 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.

8
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

9
é 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

10
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.

11
 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 estruturas de
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

12
 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)

13
 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

14
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.

15
 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”.

16
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ísticas e
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

17
(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.

18
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.

19
 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.

20
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.

21
 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”.

22
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.

23
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.

24
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

25
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,

26
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

27
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

28
(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

29
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

30
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.

31
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.

32
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.

33
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.

34
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.

35
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.

36
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.

37
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.

38
 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.

39
 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.

40
 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 de cada 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

41
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

42
 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.

43
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.

44
 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

45
 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: representa o 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

46
 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.

47
 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,

48
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

49
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

50
 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.

51
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ção de 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

52
 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

53
 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

54
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

55
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.

56
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.

57
 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.

58
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

59
é 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

60
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.

61
 • 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,

62
 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) e agregação. Uma associação é representada por
uma linha, ligando as classes às quais pertencem os objetos
relacionados. Para melhor compreensão do significado de uma
associação entre os objetos, deve-se indicar a multiplicidade em
cada extremidade da associação e opcionalmente, representar o
nome da associação, direção de leitura e papéis, como mostra a

63
 Figura 3, sendo: o número 1 em vermelho, indica o papel que os
objetos das classes Professor e MaterialDidatico assumem nessa
associação; o número 2 indica o nome da associação; e o número 3
indica a direção da leitura da associação.

Figura 3 – Exemplo de associação com nome, direção e papel

Fonte: elaborada pela autora.

• Generalização: relacionamento entre classes generalizadas,

chamada de superclasse ou classe-mãe, a outras mais
especializadas, chamada de subclasse ou classe-filha, ou seja,
conectam classes generalizadas a outras mais especializadas,
caracterizando a herança entre classes. Uma generalização é
representada graficamente por uma seta fechada na extremidade
que aponta para a superclasse.

• Dependência: relacionamento de utilização entre casos de uso,

classes, pacotes e anotações, indicando que uma alteração na
especificação de um elemento pode afetar outro elemento que a
utilize. Uma dependência é representada graficamente por uma
linha tracejada, apontando o item de que o outro depende.

• Realização: relacionamento que modela a conexão existente entre

uma interface e uma classe ou componente, ou entre um caso
de uso e uma colaboração, no qual um dos elementos especifica
um contrato de uso com o outro elemento. Uma realização é
representada graficamente por uma linha tracejada com uma
grande seta vazia, apontando para o elemento que especifica o
contrato.

64
A definição da multiplicidade em uma associação depende de
pressupostos e das regras de negócio, em conformidade com o contexto
do domínio do sistema. Segundo Bezerra (2014, p. 114), “as associações
permitem representar a informação dos limites inferior e superior da
quantidade de objetos aos quais outro objeto pode estar associado.
Esses limites são chamados de multiplicidade na terminologia da UML”.
Assim, a multiplicidade determina o número mínimo e máximo de
objetos envolvidos em uma associação. O Quadro 1 a seguir, representa
as possíveis multiplicidades e sua notação.

Quadro 1 – Tipos de multiplicidades

Notação Multiplicidade
0..1 Zero ou Um. Indica mínimo zero e máximo um.
0..* ou * Zero ou Muitos. Indica mínimo zero e máximo
muitos.

1..1 ou 1 Apenas Um. Indica mínimo e máximo um.

1..* Um ou Muitos. Indica mínimo um e máximo muitos.

li..ls Intervalo Específico. Indica uma lista de intervalos

válidos entre o limite inferior e o limite superior,
como por exemplo, 3..8.
Fonte: elaborada pela autora.

A Figura 4 exemplifica uma associação reflexiva, também denominada

de auto-associação. Ocorre quando existe um relacionamento entre
objetos da mesma classe, sendo que cada objeto assume um papel
na associação. A associação reflexiva é representada por uma linha,
iniciando e terminando na mesma classe. A figura abaixo demonstra que
um objeto funcionário, no papel de gestor, pode ser responsável por um
ou mais funcionários; e um funcionário, no papel de colaborador, pode
ter nenhum ou um funcionário gestor.

65
 Figura 4 – Exemplo de associação reflexiva

Fonte: elaborada pela autora.

A Figura 5 demostra a associação binária, que ocorre entre objetos de

duas classes, como, por exemplo, entre as classes Disciplina e Professor,
e entre as classes Professor e MaterialDidatico. Uma associação binária é
representada por uma linha reta, ligando as classes às quais pertencem
os objetos relacionados, podendo também possuir setas em suas
extremidades, indicando a navegabilidade da associação, que representa
o sentido em que as informações são transmitidas entre os objetos.

Figura 5 – Exemplo de associação binária

Fonte: elaborada pela autora.

A Figura 6 exemplifica uma associação ternária ou N-ária, que ocorre

quando relacionam objetos de mais de duas classes. São representadas
por um losango para onde convergem todas as ligações da associação.
A figura a seguir representa a relação entre objetos das classes Turma,
Disciplina e Professor.

66
 Figura 6 – Exemplo de associação ternária

Fonte: elaborada pela autora.

A Figura 7 exemplifica uma classe associativa, também denominada

de classe de associação. É uma classe conectada diretamente na
associação entre as classes relacionadas. Normalmente, a classe
associativa é representada para demonstrar os atributos específicos do
relacionamento estabelecido entre as classes associadas. Uma classe
associativa é representada por uma seta tracejada, partindo do meio
da associação até a classe associativa. A figura a seguir representa a
classe associativa Participacao, indicando que um objeto projeto pode
ter um ou mais professores participantes e que um professor pode
participar de nenhum ou mais projetos, mantido além da relação projeto
e professor, caso o professor seja responsável ou não pelo projeto e as
datas de início e término em que permanecem no projeto.

Figura 7 – Exemplo de classe associativa

Fonte: elaborada pela autora.

67
A Figura 8 exemplifica uma associação do tipo agregação, conhecida
como associação Todo-Parte. Demonstra que as informações de um
objeto (objeto-todo) precisam ser complementadas pelas informações
contidas nos objetos da outra classe (objetos-partes) relacionada,
representando que ambos os objetos das classes podem viver de
forma independente, ou seja, não existe uma ligação forte entre eles,
contudo, são partes de um único todo. A notação da agregação é
representada por um losango na extremidade da classe que contém
o objeto-todo. O exemplo a seguir, demonstra que um objeto país é
composto por nenhum ou vários objetos estados, sendo que um país
pode ser registrado sem vínculo com os estados, ou seja, não existe uma
dependência total entre os objetos, contudo, para registrar um objeto
estado, precisa referenciar a qual país pertence.

Figura 8 – Exemplo de Agregação

Fonte: elaborada pela autora.

Um tipo especial da agregação é a chamada composição. Segundo

Guedes (2011), essa associação é uma variação da agregação, onde
é apresentado um vínculo mais forte entre o objeto-todo e os objetos-
partes, demonstrando que os objetos-parte integram um único objeto-
todo, constituindo um vínculo forte entre os objetos. Assim, os objetos-
partes não podem viver quando o objeto-todo for destruído. Utiliza-se um
losango sólido para indicar a composição.

A Figura 9 ilustra um exemplo de composição, identificado pelo

número 1, em vermelho, representando que um objeto orçamento é
composto de um ou muitos objetos itens de serviço, sendo obrigatório
existir no mínimo um objeto itens de serviço, assim, estabelece-se um
vínculo forte entre ambos os objetos. Todo objeto orçamento também

68
é composto por nenhum ou muitos objetos itens de peça, ou seja,
o objeto orçamento pode existir sem nenhum objeto itens de peça,
assim, não existe um vínculo forte entre os objetos Todo-Parte, sendo
uma associação do tipo agregação, representada pelo número 2, em
vermelho.

Figura 9 – Exemplo de composição e agregação

Fonte: elaborada pela autora.

A Figura 10 exemplifica o relacionamento do tipo generalização,

que caracteriza o conceito de herança. Na representação desse
relacionamento, a classe generalizada é chamada de superclasse,
e as classes especializadas são chamadas de subclasses. Ainda na
representação desse relacionamento, pode ocorrer que uma subclasse
herde atributos e operações de duas ou mais superclasses, o que
indica uma herança múltipla. A figura a seguir demonstra a herança
entre a superclasse Curso e suas subclasses Graduacao, PosGraduacao
e Extensao; e a herança múltipla da subclasse Extensao, que herda
atributos e operações das duas superclasses Curso e Evento.

69
 Figura 10 – Exemplo de generalização

Fonte: elaborada pela autora.

A Figura 11 exemplifica o diagrama de classes de análise, referente ao

pacote locação, do domínio de uma locadora de veículos. O diagrama
ilustra uma primeira versão do diagrama de classes, demonstrando a
relação dos atributos, operações e os relacionamentos entre as classes.
Os tipos de relacionamentos estabelecidos entre as classes, na maioria,
são associações binárias, sendo que as multiplicidades representadas
em cada associação foram definidas, a partir das regras de negócio do
contexto do domínio do sistema.

No diagrama de classes, observa-se uma associação do tipo agregação

entre as classes Pais e Estado. É importante enfatizar que as associações
do tipo agregação são estabelecidas sempre que se aplica o conceito
de Todo-Partes entre os objetos associados. No diagrama, considera-se
a seguinte leitura dessa associação: um país é composto de estados?
Ou ainda, um estado pode ser considerado como uma parte de um
país? Analisando esse contexto e projetando esses objetos no mundo
real, pode-se afirmar que um país (objeto Todo) é composto de
estados (objetos Partes), então, está correto estabelecer a associação
do tipo agregação. Observa-se também um relacionamento do tipo
generalização na hierarquia representada entre as classes Pessoa,
ClienteFisico e ClienteJuridico. Nessa generalização, representou-se os

70
atributos e operações comuns aos objetos cliente físico e cliente jurídico
na superclasse Pessoa, e os atributos e operações específicas em cada
subclasse ClienteFisico e ClienteJuridico.

Figura 11 – Exemplo de diagrama de classes

Fonte: elaborada pela autora.

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.

71
 Bons estudos!

72