UNIDADE-MODELAGEM 2

Prévia do material em texto

43
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
Unidade II
3 Modelo ConCeitual da uMl
3.1 introdução
O Object Management Group (OMG) adotou a UML em novembro de 1997. Essa adoção ocorreu 
em um evento histórico e marcante, pois assinalou a aceitação de uma linguagem padronizada de 
modelagem de sistemas baseada nas melhores práticas atuais para a análise, projeto e construção de 
software orientado a objetos.
 Saiba mais
A Object Management Group, ou OMG, é uma organização internacional 
que aprova padrões abertos para aplicações orientadas a objetos. O Object 
Management Group foi fundado em 1989. Constantemente, a OMG publica 
o documento dos padrões e normativos sobre a UML no seu portal cuja URL 
é: <http://www.omg.org/spec/UML/2.3/Infrastructure>.
A UML é a primeira notação que atingiu o concenso entre a maioria dos profissionais, 
vendedores e acadêmicos como o padrão real para expressar um domínio comercial da solução 
de software.
Grady Booch (2000) diz que a modelagem deve atingir quatro objetivos para se tornar efetiva em 
um ambiente de desenvolvimento de software:
• ajudar a equipe de projeto a visualizar um sistema como ele é ou como ele pretende ser;
• ajudar a especificar a estrutura ou comportamento do sistema;
• proporcionar um modelo que sirva de guia na construção do sistema;
• documentar as decisões tomadas pela equipe de desenvolvimento de projeto (REED JR., 2000).
3.2 Visão geral da uMl
A UML não é um modelo de processo/metodologia de software. É uma notação, um mecanismo para 
“mostrar o problema” de forma a expor a essência do domínio de um aplicativo.
44
Unidade II
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
A combinação da UML com um bom modelo de processo, tais como, o RUP (Rational Unified Process) 
ou o processo ágil SCRUM, resulta em uma poderosa combinação para a criação de aplicativos bem-
sucedidos (REED JR., 2000).
A linguagem de modelos UML tem dois objetivos: um deles é proporcionar consistência, informando 
o cliente ou patrocinador do projeto de que o domínio do problema está bem entendido pela equipe 
de desenvolvedores. O outro objetivo é proporcionar um modelo de consistência para a equipe de 
implementação (arquitetos e programadores), que assim poderão fazer uma implementação adequada 
do software.
 lembrete
Todavia, deve ficar claro que somente os diagramas da UML não 
conseguem garantir o processo de desenvolvimento. Um bom modelo de 
processo e um plano adequado do projeto são fundamentais para que o 
projeto não falhe.
Todos os artefatos propostos pela UML são rastreáveis e, se construídos ao longo de um processo 
de desenvolvimento padronizado na empresa, os modelos podem se completar uns aos outros. Esse 
elemento da rastreabilidade é fundamental para o projeto.
Esses artefatos construídos ao longo do desenvolvimento com a UML servirão como um ponto 
de controle da qualidade do modelo anterior, já que se completam. Como os modelos UML são inter-
relacionados na sua criação, é mais fácil identificar quando um componente está faltando ou está incorreto.
Todavia, a UML não resolve diretamente alguns aspectos de um projeto e, se necessário, deve-se 
utilizar outros diagramas auxiliares, como a interface gráfica de usuário (GUI), a distribuição do processo 
(processamento distribuído) e a distribuição dos dados (BDs distribuídos).
3.3 arquitetura da uMl
Uma arquitetura de sistema de software pode ser descrita por cinco visões interconectadas. Cada 
visão é uma projeção na organização e estrutura do sistema, focando em um aspecto particular desse.
As cinco visões da arquitetura UML são: visão de análise, visão de design, visão de implementação, 
visão do processo e visão da implantação. Para a UML, o modelo ou visão que interconecta essas visões 
se dá pelo modelo de caso de uso.
A visão de caso de uso de um sistema compreende os que descrevem o comportamento do sistema 
como visto pelos usuários finais, analistas e testadores.
Essa visão não especifica a organização do sistema de software. Na UML, os aspectos estáticos do 
sistema são capturados no diagrama de caso de uso.
45
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
Os 13 diagramas da UML estão divididos em três categorias: estático, dinâmico e arquitetural:
• Os diagramas estáticos mostram a esturutra do sistema e as responsabilidades. Esses diagramas 
mostram a estrutura física dos elementos e não envolvem a passagem do tempo. Isto é, 
eles não mostram a dinâmica das coisas, simplesmente sua organização. Os três principais 
diagramas estáticos da UML são: o modelo de caso de uso, o modelo de classes e o modelo 
de objetos.
• Um diagrama dinâmico mostra a interação ativa que o sistema suporta e detalha a interação 
entre os elementos estruturais dos diagramas estáticos.
• Essas interações dinâmicas são descobertas nos casos de uso como caminhos executados 
em resposta a alguns estímulos externos ao sistema. Os diagramas dinâmicos mostram o 
comportamento pretendido do sistema. Os principais diagramas dinâmicos são: atividades, 
comunicação, sequência e estado.
• Um diagrama arquitetural mostra a realização do sistema em componentes funcionais e 
executáveis. Eles também diferenciam a localização física da execução e os nós de armazenamento 
e uma estrutura dentro da qual eles podem interagir.
• Os principais diagramas estruturais são: componentes e implantação.
3.4 Modelagem estrutural
Na UML, o principal diagrama que mostra a estrutura de um sistema é o diagrama de classes.
Todavia, outros diagramas também permitem visualizar a estrutura do sistema, tais como, o diagrama 
de pacotes, o diagrama de componentes, o diagrama de objetos e o diagrama deployment (implantação).
3.4.1 Classes de objetos
Uma classe de objetos é uma coleção de objetos que podem ser descritos com os mesmos atributos 
e as mesmas operações.
Representa uma idéia ou um conceito simples e categoriza objetos que possuem propriedades 
similares, configurando-se em um modelo para a criação de novas instâncias (outros objetos).
Uma classe de objetos na UML possui três segmentos: nome, atributos e operações.
A representação ou notação de uma classe é um retângulo com os três segmentos. Cada classe deve 
ter um nome que a distingue de outras classes. Um nome é um texto.
Uma classe possui diversos atributos. Um atributo é uma propriedade do objeto que descreve a faixa 
de valores que as instâncias do objeto podem ter.
46
Unidade II
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
O terceiro segmento da classe são as operações. Uma operação é a implementação de um serviço 
ou funcionalidade que pode ser requisitado de qualquer objeto da classe para afetar o comportamento 
do objeto.
3.4.2 Relacionamentos entre classes de objetos/instâncias
As classes de objetos, no modelo de classes, se relacionam ou se associam de acordo com as 
necessidades do sistema. Esses relacionamentos são denominados “associação entre classes”.
Um relacionamento define as regras da associação que, por seu lado, são impostas pelas regras de 
negócio da aplicação, sendo modelada.
A criação de um objeto, baseado em uma classe, recebe um nome especial: instância. Quando 
é necessário manipular um determinado objeto, a classe é carregada na memória, e os objetos são 
instanciados, isto é, são criados na memória e podem ser manipulados.
A instanciação de objetos depende da linguagem OO utilizada, mas, em geral, possuem uma função 
especial que cuida das instâncias dos objetos, denominada construtora.
Quando o objeto já não é mais necessário, outra função especial chamada de destrutora da classe 
elimina as instâncias criadas. Por exemplo: para uma classe funcionário, o objeto tipo funcionario “João 
Carlos da Silva” seria uma instância na memória.
3.4.3 Mecanismos comuns
A UML é feita simplesmentepela presença de mecanismos comuns que garantem a consistência a 
partir da linguagem, tais como: especificação, adornos e mecanismo de extensibilidade.
A especificação refere-se aos padrões das descrições dos componentes dos modelos: como 
nomear os componentes, como descrever a lógica de um cenário de um caso de uso, e assim 
por diante.
Adornos são itens gráficos e textuais que são adicionados a uma notação de um elemento básico e 
são usados para visualizar detalhes da especificação do elemento. Por exemplo, no símbolo de nó de um 
diagrama de implantação, pode ser interessante colocar os componentes executáveis dentro de uma 
caixa extra do desenho.
O mecanismo de extensibilidade da UML permite extender a linguagem de uma maneira controlada. 
Esse mecanismo inclui estereótipos, valores marcados e restrições.
Um estereótipo extende o vocabulário da UML, permitindo que se criem novos tipos 
de blocos de construção que são derivados de outros existentes, mas especifícos para um 
determinado problema.
47
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
3.4.4 Diagramas da UML
Com um modelo, é possível um melhor entendimento dos sistemas que estão em desenvolvimento. 
Com a UML, pode-se construir modelos a partir de um conjunto de blocos básicos, tais como, classes, 
interfaces, colaborações, componentes, nós, dependências, generalizações e associações.
 lembrete
Quando o homem modela qualquer coisa, ele está criando uma 
simplificação da realidade.
A UML propõe 13 diagramas, conforme mostra a quadro 2:
Quadro 2 – Diagramas da UML
Diagramas
Número UML 1.X UML 2.3
1 Atividade Atividade
2 Caso de uso Caso de uso
3 Classe de objetos Classe de objetos
4 Objetos Objetos
5 Sequência Sequência
6 Colaboração Comunicação
7 Estado Estado
8 Componentes Componentes
9 Implantação Implantação (deployment)
10 ------------- Pacotes
11 ------------- Interação
12 ----------- Tempo
13 ---------- Estrutura composta
 lembrete
Com relação ao ciclo de desenvolvimento de software:
• Cada diagrama da UML, ou modelo, pode ser usado em um 
determinado momento do ciclo de desenvolvimento de software.
• Um diagrama da UML deve ser usado para resolver ou mostrar 
aspectos específicos do problema sendo modelado.
• Um diagrama da UML pode ser usado para especificar artefatos 
diferentes em atividades diferentes do processo de software. Por 
48
Unidade II
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
exemplo, o diagrama de atividade pode ser usado para detalhar uma 
funcionalidade, como mostrar um determinado fluxo do problema 
que está sendo estudado etc.
3.4.4.1 Diagrama de atividade
Os diagramas de atividades são usados para modelar o comportamento de um sistema, e a forma em 
que esses comportamentos estão relacionados em um fluxo geral desse.
O fluxo mostra os caminhos de um processo lógico a seguir, com base em várias condições, 
processamento simultâneo, acesso a dados, interrupções e outras distinções do caminho lógico.
São usados para construir um sistema, um processo, ou um procedimento.
3.4.4.2 Diagrama de caso de uso
Um diagrama de caso de uso captura as funcionalidades do sistema e as relações entre os atores e o 
sistema. Ele descreve os requisitos funcionais do sistema, a maneira pela qual as coisas de fora (atores) 
interagem no limite do sistema e a resposta desse aos usuários.
 lembrete
O diagrama de caso de uso, ou modelo de caso de uso, é um dos mais 
importantes modelos da UML e será detalhado na Unidade 3.
3.4.4.3 Diagrama de objetos
Um diagrama de objetos está intimamente relacionado a um diagrama de classes de objetos, 
com a distinção de que retrata instâncias de objetos das classes e seus relacionamentos em um 
ponto no tempo.
Isso pode parecer semelhante a um diagrama de estrutura composta, que também modela 
comportamentos em tempo de execução. A diferença é que os diagramas de objetos exemplificam os 
diagramas de classes estáticas, enquanto que os diagramas de estrutura composta refletem arquiteturas 
em tempo de execução.
Eles são úteis na compreensão de um diagrama de classes complexas, criando diferentes casos em 
que os relacionamentos e as classes são aplicados.
Um diagrama de objeto também pode ser uma espécie de diagrama de comunicação, que 
também modela as conexões entre os objetos, mas adiciona sequências de eventos ao longo de 
cada caminho.
49
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
3.4.4.4 Diagrama de sequência
O diagrama de sequência é um dos quatro tipos de diagrama de interação. Um diagrama de sequência 
é uma representação estruturada de comportamento com uma série de etapas sequenciais ao longo do 
tempo.
Ele é usado para descrever o fluxo de trabalho, passagem de mensagens. Cada elemento da sequência 
é organizado em uma sequência horizontal, com mensagens que passam para trás e para frente entre 
os elementos.
Um elemento de ator pode ser usado para representar o usuário que inicia o fluxo de eventos. 
Elementos estereotipados, como limite, controle e entidade, podem ser usados para ilustrar as telas, os 
controladores e os itens de banco de dados, respectivamente. Cada elemento tem uma linha pontilhada 
tronco chamada de linha-de-vida, na qual o elemento existe e, potencialmente, participa das interações.
3.4.4.5 Diagrama de comunicação
Um dos quatro tipos de diagrama de interação. Um diagrama de comunicação mostra as interações 
entre os elementos em tempo de execução da mesma maneira que um diagrama de sequência.
No entanto, os diagramas de comunicação são usados para visualizar as relações entre objetos, enquanto 
os diagramas de sequência são mais eficazes na visualização de processamento ao longo do tempo.
Os diagramas de comunicação empregam associações rotuladas e ordenadas para ilustrar o 
processamento. A numeração é importante para indicar a ordem e a nodificação de processamento.
Um esquema de numeração pode ser: 1, 1.1, 1.1.1, 1.1.2, 1.2 e assim por diante.
3.4.4.6 Diagrama de estado (máquina de estado)
Os diagramas de estado da máquina eram anteriormente conhecidos como diagramas de estado. 
Esse diagrama ilustra como um elemento (geralmente uma classe) pode mover-se entre os estados, 
classificando o seu comportamento de acordo com gatilhos de transição ou guardas de restrição.
Outros aspectos do diagrama de máquina de estado ajudam a descrever e explicar os movimentos e 
comportamentos dos sistemas.
3.4.4.7 Diagrama de componentes
Um diagrama de componentes mostra os pedaços de software, controladores embutidos que formam 
um sistema, sua organização e as dependências.
Um diagrama de componente tem um nível maior de abstração do que um diagrama de classes. Geralmente, 
um componente é implementado por uma ou mais classes (ou objetos) em tempo de execução.
50
Unidade II
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
Eles são blocos de construção, construídos de modo que, eventualmente, um componente pode 
abranger uma grande parte de um sistema.
3.4.4.8 Diagrama de implantação
Um diagrama de implantação (deployment) mostra como e onde o sistema será implantado, ou seja, 
sua arquitetura de execução.
Dispositivos de hardware, processadores e ambientes de software de execução (artefatos do sistema) 
são refletidos como nós, e a construção interna pode ser representada incorporando nós no desenho. 
Como os artefatos são alocados para os nós do modelo de implantação do sistema, a alocação é guiada 
pela utilização das especificações de implantação.
3.4.4.9 Diagrama de pacotes
O diagrama de pacotes (pakage) mostra a organização dos elementos de um modelo em pacotes 
(agrupamentos) e as dependências entre esses pacotes, incluindo pacotes importados e extensões de 
pacotes.
3.4.4.10 Diagrama de interação (visão geral)
Um diagrama geral de interação visualiza a cooperaçãoentre os diagramas de interação para ilustrar 
um fluxo de controle que serve a um propósito abrangente.
Como os diagramas gerais de interação são uma variante de diagramas de atividades, a maioria da 
notação do diagrama é a mesma, como é o processo de construção do diagrama.
Pontos de decisão, forks, junções, pontos iniciais e finais são os mesmos. Em vez de elementos 
de atividade, no entanto, elementos retangulares são usados . Existem dois tipos desses elementos: 
elementos de interação e e elementos de ocorrência.
3.4.4.11 Diagrama de tempo
Um diagrama de tempo define o comportamento de objetos diferentes dento de uma escala de 
tempo. Ele fornece uma representação visual da mudança dos objetos, mudando de estado e interagindo 
todo o tempo.
Ele pode ser usado para definir os componentes e softwares embutidos. Também pode ser utilizado 
para especificar processos de negócio orientados pelo tempo.
3.4.4.12 Diagrama estrutura composta
Um diagrama de estrutura composta reflete a colaboração interna de classes, interfaces ou 
componentes (e suas propriedades) para descrever a funcionalidade do sistema.
51
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
Eles são similares aos diagramas de classe, exceto pelo fato de que eles modelam um uso específico 
da estrutura. Um diagrama de estrutura composta é usado para expressar o tempo de execução das 
arquiteturas, padrões e relacionamentos dos elementos participantes, que não podem ser refletidos por 
meio de diagramas estáticos.
4 diagraMa de ClaSSeS de objetoS da uMl
Entre esses diagramas, o diagrama de classes é considerado um dos principais e será detalhado a 
seguir.
4.1 introdução
O diagrama de classes mostra a estrutura estática do sistema por meio de suas classes e objetos e 
também como eles se relacionam.
É considerado por alguns autores como o mais importante diagrama no desenvolvimento orientado 
a objetos e, portanto, também da UML.
 observação
A meta na construção de um modelo de objetos é incorporar os 
conceitos do mundo real que sejam importantes para a aplicação.
A figura 12 mostra um exemplo de modelo de classes de objetos na notação da UML.
Nome da classe de objetos
Mundo real
Modelo de objeto
Realidade de interesse 
(Observado)
Atributos
Operações ( )
Figura 12 – Visão do mundo real x a OO
52
Unidade II
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
A figura 13 mostra um exemplo de diagrama de objetos com um metamodelo de classe, uma classe 
e duas instâncias da classe “José da Silva” e “Maria Rodrigues”.
Nome da classe de objetos
O nome da classe (metamodelo) 
representa o agrupamento de 
objetos do mesmo tipo.
Objetos com valores da 
classe pessoa.
Pessoa
Nome dos atributos Nome 
idade
Operações ( ) Mudar_endereço ( )
José da Silva 
32
Maria de Tal 
26
Figura 13 – Exemplo de uma classe e suas instâncias na notação UML
Alguns meios de implementação (linguagens de programação e sistemas gerenciadores de banco de 
dados) exigem que um objeto tenha um identificador explícito para cada objeto. Esses identificadores 
explícitos não são obrigatórios em um modelo de objetos.
A figura 14 mostra um uso incorreto de identificadores internos.
Pessoa
Nome 
idade
Pessoa
Cod_Pessoa 
Nome
Correto
Figura 14 – Uso incorreto de identificador interno
Os identificadores internos (gerados pelas linguagens) não podem ser confundidos com atributos 
do mundo real e não devem fazer parte do modelo conceitual. O “número_telefone” e “número_placa_
carro” não são identificadores internos porque têm significado no mundo real.
Uma classe sempre deve representar um mesmo assunto, isto é, ela encapsula conhecimentos sobre 
algo. Não teria sentido colocarmos dados sobre a empresa em que trabalha na classe pessoa.
Pessoa e empresa são assuntos diferentes ou objetos diferentes e, portanto, devem estar em classes 
distintas. Uma classe tem responsabilidade por tudo o que lhe diz respeito. Não é de responsabilidade da 
pessoa/funcionário incluir ou manter os dados da empresa.
Uma classe poder ter visibilidade pública, protegida, privada:
• Uma classe pública indica que qualquer outra classe poderá acessar seus atributos e solicitar a 
execução de suas operações.
53
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
• Uma classe é denominada de privada quando restringe totalmente o acesso a seus atributos e as 
suas operações.
• Uma classe com visibilidade protegida somente permite a ela e aos seus herdeiros o acesso a seus 
atributos e suas operações.
As operações ou comportamentos de uma classe de objetos recebem e devolvem valores que 
são passados numa lista de argumentos, dentro de um padrão específico que cada linguagem 
adota.
O diagrama do modelo conceitual deve ser independente da tecnologia, e quando da implementação 
é que se considera os padrões específicos.
A figura 15 mostra um exemplo de chamada de uma operação com a lista de argumentos.
Exemplo: mudar_endereço (novo_endereço, ok)
Operação Parâmetro 
de entrada
Parâmetro 
de saída
Figura 15 – Exemplo de uma operação e a lista de argumentos
Em um modelo de classes, existem diversas classes do domínio da aplicação que precisam se 
relacionar dentro das regras de negócio.
Elas, quando estão relacionadas, podem trocar mensagens para que uma determinada tarefa que 
envolve diversos objetos possa ser realizada com sucesso.
Os relacionamentos das classes no modelo de classes podem ser de três tipos: associação, agregação 
e composição e generalização/especialização.
4.2 associação
Associação é uma relação semântica entre classes. Uma associação acontece quando uma 
determinada instância de uma classe se associa a uma ou mais instâncias de outra ou da 
mesma classe.
Ligações e associações são os meios para estabelecermos relacionamentos entre objetos e classes. As 
ligações são conexões entre instâncias de objetos.
A figura 16 mostra o metamodelo de associação de classes e um exemplo prático.
54
Unidade II
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
Classe A Classe B
Papel 1
Papel 2
associação
João da Silva Telesp
Pessoa Empresa
trabalha_para
ligação
Figura 16 – Exemplo de uma associação entre duas classes. O modelo apresentado 
é o modelo de objetos no qual o objeto pessoa trabalha para uma empresa
As associações ainda podem ser binárias, unárias, ternárias e assim por diante. Uma 
associação é dita binária quando duas classes estão envolvidas na associação, conforme mosta 
a figura 17.
Cidade
Nome
Pais tem_capital
0.1 1Nome
Figura 17 – Associação binária
Uma associação é dita unária quando o relacionamento de uma classe é consigo própria.
A figura 18 mostra um exemplo de associação unária. Uma peça pode compor outras peças maiores, 
mas também pode ser composta de outras peças menores.
0..*
1..*
Componente
Composta
Peça
Figura 18 – Um exemplo de associação unária
Uma associação é dita ternária quando três classes fazem parte da associação. Na figura 19, tem-se 
que um projeto tem várias pessoas trabalhando nele e pode ser implementado em várias linguagens 
diferentes.
A nomeação das associações são opcionais para associações ternárias ou de ordem superior 
(n-árias).
55
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
A figura 19 mostra um exemplo de associação ternária.
Projeto Linguagem
Pessoa
Símbolo de associação ternária ou de ordem superior
1..* 1..*
1..*
Figura 19 – Exemplo de uma associação ternária
4.3 Papéis em associação
A UML possui uma notação específica para representar as regras de uma associação entre os objetos 
das classes.
A notação denomina-se cardinalidade ou multiplicidade e deve ser descrita no diagrama, como 
mostra a tabela 1.
Tabela 1 – Cardinalidades ou multiplicidades das associaçõesentre classes
Cardinalidade Descrição
0..1 Opcional e único
0..* Opcional e múltiplo
1 Obrigatório e único
1..* Obrigatório e múltiplo
* O mesmo que 0..*
2..4 De 2 a 4
1..2,5,7..14 1 e 2, 5 e 7 a 14
Quando se quer ressaltar que um dado elemento da associação deve estar classificado, deve-se 
utilizar a palavra-chave {ordenado}, como mostra a figura 20.
Classe A Classe B
Papel 1
Papel 2
{ordenado}
Figura 20 – Uso da palavra chave {ordenado}
Quando se quer declarar a visibilidade da associação, deve-se colocar os símbolos em frente ao nome 
do papel (“+” público, ”#” protegido, “-“ privado). Isso declara a visibilidade da associação em direção 
àquele papel.
56
Unidade II
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
Por exemplo: na figura 9, se for colocado em frente do papel 1 o símbolo “+”, está declarado que esse 
papel na associação é de uso público.
Quando existir a necessidade de mostrar o sentido da navegação em uma determinada 
associação, deve-se colocar uma seta na extremidade da associação para indicar a direção 
suportada pelo modelo.
A figura 21 mostra um exemplo do uso da navegação em uma associação entre duas classes de 
objetos.
Cidade
Nome
Pais tem capital
0..1 1Nome
Figura 21 – Navegação (restrição de acionamento de classes)
A seta indica o sentido em que a navegação é suportada no modelo, dessa forma não é possível 
operações da classe cidade acessarem as operações da classe país.
4.4 Classe de associação
Em alguns modelos, devido às regras de negócio, torna-se necessária a colocação de atributos em 
uma determinada associação. Um atributo é uma propriedade dos objetos de uma classe.
Como uma associação também é um objeto, é perfeitamente possível colocar nela atributos. Então, 
um atributo de ligação é uma propriedade de uma associação.
A figura 22 apresenta a classe “depto de uma empresa” e a classe funcionário, nas quais ficam os 
funcionários da empresa.
Funcionário
Cod_func 
nome
Depto Chefia
1
0..1
Nome
Figura 22 – O uso de atributos de associação
A questão que se coloca no modelo é: onde colocar a data de posse da chefia, em departamento 
ou em funcionário? Todavia, a data de posse é uma propriedade da associação “chefia” e deve 
pertencer a ela.
A data de posse não é propriedade nem do departamento e nem do funcionário.
Uma das soluções seria colocar a data em uma das classes associadas. A escolha fica a critério do 
analista, já que esse atributo não é natural nem para departamento e nem para funcionário.
57
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
O problema decorrente da colocação dos atributos de ligação em uma das classes ligadas é a 
flexibilidade futura do modelo. Caso haja qualquer dúvida com relação ao futuro, como regra, cria-se 
uma “classe de associação”.
Como mostra a figura 23, criou-se uma classe nova denominada “classe de associação” para permitir 
a colocação do atributo específico da associação.
A classe de objetos “chefia”, possui atributos próprios e provavelmente operações para tratar esses 
atributos e as associações.
Funcionário
Cod_func 
nome
Depto
1
0..1
Nome
Chefia
Data_posse
Figura 23 – O uso da classe de associação
A figura 24 mostra outro exemplo de classe de associação para um modelo mais sofisticado. Temos 
um modelo que mostra uma empresa, seus funcionários e o grau de desempenho desses.
0..*
1..*
Funcionário
Endereço
Nome 
RG
Trabalha para
Admite_funcionário ( )
Salário 
Cargo
Empresa
Nome 
Endereço
Gerencia
Grau de 
desempenho
Trabalha_para
Figura 24 – Classes de associação
Note que o grau de desempenho pertence à associação, já que o atributo somente tem sentido 
enquanto o funcionário ocupa o cargo de gerência.
A classe “trabalha para” indica que o salário e o cargo do funcionário são atributos que dependem 
da empresa em que trabalha, já que o modelo permite que um funcionario trabalhe em mais de uma 
empresa.
58
Unidade II
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
4.5 agregação e composição
Agregação é um tipo especial de associação em que um objeto contém o(s) outro(s). É também 
chamado de relacionamento “todo/parte”. Agregação é um modo de associação na qual um objeto 
agregado é feito de componentes. Os componentes fazem parte do agregado.
A figura 25 mostra um exemplo de agregação. Uma publicação possui artigos obrigatoriamente no 
modelo. Isso significa que uma publicação é composta necessariamente de artigos.
O diamante vazio indica que a ligação é fraca, já que uma publicação pode existir sem nenhum 
artigo, mas um artigo não existe sem uma publicação associada.
0..*
1..*
Publicação
Artigo
Figura 25 – Exemplo de uma agregação entre classes associadas
As agregações incluem explosões das partes e expansões de um objeto em suas partes constituintes. 
A figura 26 mostra outro exemplo de agregação entre classes de objetos.
0..*
0..1 0..*
0..*
1
1
Empresa FuncionárioTrabalha_para
Divisão
Departamento
Figura 26 – Exemplo de agregação
Uma empresa é uma agregação de suas divisões, que são, por sua vez, agregações de seus 
departamentos. Uma empresa não é uma agregação de seus funcionários, uma vez que empresa e 
pessoa são objetos distintos e independentes.
59
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
Uma composição é uma agregação forte em que as partes estão fisicamente contidas dentro do 
todo. Os componentes não podem ser compartilhados por outros compostos. Uma exclusão do todo 
desencadeia uma exclusão em cascata das partes, portanto, o ciclo de vida das classes em composição 
coincidem.
A figura 27 mostra um exemplo de composição.
0..*
1
Livro
Capítulo
Figura 27 – Exemplo de composição (associação forte)
A exclusão de um livro acarreta a exclusão de todos os seus capítulos, e a exclusão dos capítulos do 
livro implica a elimincação do livro.
4.6 generalização/especialização
A generalização é uma forma de se estruturar a visibilidade de um elemento global com uma visão 
mais detalhada desse. Isso é feito adicionando características específicas ao elemento na visão detalhada 
e aproveitando as características gerais.
generalização
especialização
Figura 28 – Generalização x especialização
A generalização/especialização pode ser usada para diversos outros modelos da UML, como em 
diagramas de pacotes e diagramas de casos de uso.
60
Unidade II
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
As classes superiores são chamadas superclasses, e as inferiores subclasses. Tanto a superclasse como 
as subclasses referem-se às características de um único objeto.
Com a generalização, um objeto é simultaneamente instância da superclasse e instância da 
subclasse.
0..1 0..*
Empresa Funcionário
Masculino Feminino
Trabalha_para
Associação de 
generalização
Divisão
Departamento
Figura 29 – Exemplo de generalização
Uma árvore de generalização é composta por classes que descrevem um objeto. No exemplo da figura 
19, a classe funcionário foi especializada em masculino e feminimo, devido a características específicas 
de cada um, mas o modelo garante que as características comuns estão representadas somente uma 
vez na superclasse funcionário.
Diz-se que masculino é um “tipo_de” funcionário ou masculino “é um” funcionário. Um funcionário 
ou é masculino ou é feminino.
4.7 Herança
Na UML, herança é um mecanismo por meio do qual uma instância de uma classe assume os atributos 
e os comportamentos dos objetos de outra classe (antepassados ou antecedentes).
Os objetos subordinados herdam atributos e serviços da classe superior. A propriedade herança 
permite que novas classes sejam construídas pela herança de classes existentes. A figura 30 mostra um 
exemplo de herança.
61
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-08-
20
12
ModelageM de Processos
Classe ou superclasse
Subclasse
Aeronave
Jato Planador
Figura 30 – Exemplo de aplicação do mecanismo de herança
No exemplo da figura 30, as classes jato e planador são subclasses de aeronave. As classes subordinadas 
podem ter atributos e ou métodos próprios. O conceito de herança reforça a extensibilidade característica 
que sempre se procurou na programação.
Uma classe descendente/subclasse não pode omitir ou suprimir um atributo da superclasse, senão 
não seria uma instância antecessora. As subclasses também são chamadas de classes derivadas ou 
classes-filho na hierarquia de classes.
As classes que ficam mais altas na hierarquia são denominadas de superclasses.
Funcionário
Funcionário 
feminino
nome solteira 
registrar licença 
maternindade
Funcionário 
masculino
Figura 31 – Exemplo de herança
Pode acontecer de uma subclasse possuir alguma operação diferente de seu antecessor. Isso 
é chamado de extensão. Uma subclasse pode restringir atributos do antecessor. Isso é chamado de 
“restrição”, pois restringe os valores que aquela instância pode assumir.
 lembrete
O mecanismo de herança se tornou sinônimo de reutilização de código 
no projeto orientado a objetos.
62
Unidade II
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
A figura 32 mostra um exemplo completo do uso de herança.
Equipamento
nome
fabricante
preço
peso
Bomba
pressão de sucção
pressão de descarga
taxa de fluxo
Bomba centrífuga
eixo de rotação
Tanque esférico
diâmetro
Bomba de diafragma
material do diafragma
Tanque
Volume
pressão
Bomba de imersão
diâmetro de pistão
número de cilindros
Tanque pressurizado
diâmetro
altura
Tanque de teto flutuante
diâmetro
altura
Tipo de equipamento
Tipo de bomba
Tipo de tanque
Figura 32 – Exemplo completo do uso de herança
A quadro 3 mostra o conteúdo dos objetos da classe “bomba centrífuga” e da classe “tanque de teto 
flutuante” com suas características específicas apesar de serem ambas equipamento.
Diversos atributos e operações são válidos para os dois objetos e possuem atributos e operações 
específicos.
Quadro 3 – Conteúdo das classes
Bomba de diafragma Tanque de teto flutuante
Nome = P101 Nome = T111
Fabricante = Simplex Fabricante = Simplex
Peso = 100 kg Peso = 10.000 kg 
Preço = R$ 5.000,00 Preço = R$ 50.000,00 
Pressão sucção = 1,1 atm Volume = 400.000 l
Pressão de descarga = 3,3 atm Pressão = 1,1 atm
Taxa de fluxo = 300 l/hora Diâmetro = 8 m
Mat. diafragma = teflon Altura = 9 m
63
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
Herança é um mecanismo da OO que permite criar novas classes a partir de classes já 
existentes, aproveitando-se das características existentes na classe a ser extendida.
Este mecanismo é muito interessante, pois promove um grande reuso e reaproveitamento 
de código existente. Com a herança é possível criar classes derivadas (subclasses) a partir de 
classes bases (superclasses). As subclasses são mais especializadas do que as suas superclasses, 
mais genéricas. As subclasses herdam todas as características de suas superclasses, como 
suas variáveis e métodos.
Imagine que dentro de uma organização empresarial, o sistema de RH tenha que 
trabalhar com os diferentes níveis hierárquicos da empresa, desde o funcionário de baixo 
escalão até o seu presidente.
Todos são funcionários da empresa, porém cada um com um cargo diferente. Mesmo 
a secretária, o pessoal da limpeza, o diretor e o presidente possuem um número de 
identificação, além de salário e outras características em comum. Essas características em 
comum podem ser reunidas em um tipo de classe em comum, e cada nível da hierarquia ser 
tratado como um novo tipo, mas aproveitando-se dos tipos já criados, a partir da herança.
Os subtipos, além de herdarem todas as características de seus supertipos, também 
podem adicionar mais características, seja na forma de variáveis e/ou métodos adicionais, 
bem como reescrever métodos já existentes na superclasse (polimorfismo).
A herança permite vários níveis na hierarquia de classes, podendo criar tantos subtipos 
quanto necessário, até se chegar no nível de especialização desejado. Podemos tratar 
subtipos como se fossem seus supertipos, por exemplo, o sistema de RH pode tratar uma 
instância de presidente como se fosse um objeto do tipo funcionário, em determinada 
funcionalidade.
Porém, não é possível tratar um supertipo como se fosse um subtipo, a não ser que o 
objeto em questão seja realmente do subtipo desejado e a linguagem suporte este tipo de 
tratamento, seja por meio de conversão de tipos ou outro mecanismo.
Fonte: <http://www.softechnetwork.com.br/java/CursoOO.pdf>. Acesso em: 15 jun. 2012.
4.8 Conceitos avançados envolvendo classes
4.8.1 Herança múltipla
Herança múltipla é uma extensão da análise orientada a objetos que permite uma classe ter mais de 
uma superclasse e herdar todas as características (atributos e operações) de todos os seus pais.
É considerada a mais complicada forma de generalização, e nem todas as linguagens de programação 
dão suporte diretamente. A figura 33 mostra um exemplo de herança múltipla.
64
Unidade II
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
Janela Texto
Tela
Árvore
Figura 33 – Herança múltipla
Com a herança múltipla a classe tela herda todas as caracerísticas de suas três classes-pai ou superclasses. 
A classe janela possui as propriedades das janelas e as operações para mostrá-las e movimentá-las pela tela.
A classe texto oferece as propriedades textuais das janelas, com operações/métodos para manipular 
linhas de texto etc.
A herança múltipla aumenta o potencial de uma linguagem orientada a objetos, mas a um custo na 
complexidade da programação, bem como um overhead de compilação e de tempo de execução.
Uma classe com mais de uma superclasse é chamada de classe-de-junção.
Veículo
Terrestre Aquático
Carro Anfíbio Barco
Figura 34 – Classe-de-junção anfíbia
Uma característica proveniente da mesma classe ancestral encontrada em mais de um caminho é 
herdada apenas uma vez.
No exemplo da figura 34, a característica “cor” da classe veículo é herdada tanto por veículo terrestre 
como por veículo aquático, mas a subclasse veículo anfíbio, que possui herança múltipla, herda a 
característica “cor” de apenas uma das suas superclasses.
65
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
As subclasses provenientes de generalizações podem ou não ser disjuntas. No exemplo da figura 34, 
as classes terrestre e aquático não são disjuntas nesse nível, porque elas se sobrepõem, isto é, algum 
veículo pode andar na terra e na água.
4.8.2 Classes abstratas
Uma classe abstrata é uma classe que não possui instâncias diretamente, mas cujos descendentes 
possuem instâncias diretas. Esse tipo de classe é útil durante um projeto OO, para facilitar a programação 
e a manutenção dos sistemas.
Às vezes, é útil criar superclasses abstratas para encapsular classes que participam em uma mesma 
associação. Algumas classes abstratas aparecem naturalmente no domínio da aplicação, outras são 
artificialmente criadas como um mecanismo para permitir reuso de código.
As classes abstratas são usadas frequentemente para definir métodos para serem abordados por subclasses.
Uma classe abstrata não é uma classe concreta já que não pode ser instanciada diretamente. Para 
ser instanciável a classe abstrata deve possuir descendentes concretos.
Já uma classe concreta pode ser uma classe de folhas (último nível da hierarquia). Uma classe abstrata 
não pode ser classe de folha já que precisa de descendentes para ser instanciável.
A figura 35 mostra uma hierarquia de classes concretas e dessa forma todas podem ser instanciáveis 
diretamente.
Trabalhador
CobradorPedreiro Açougueiro
{incompleto}
Figura 35 – hierarquia de classesconcretas
A classe trabalhador também pode ser classe concreta, pois algumas ocupações podem estar contidas 
nelas. Dessa forma, a hierarquia é {incompleto}.
Todavia, uma classe concreta pode ser refinada em várias subclasses concretas e se tornar abstrata. 
Quando isso acontece, a hierarquia passa a ser {completo}.
O exemplo da figura 36 mostra uma superclasse empregado que se tornou abstrata no momento em 
que foram criadas diversas subclasses concretas, que herdaram a operação Calcular_Salario( ) e que 
serão programadas com lógicas específicas.
66
Unidade II
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
Trabalhador
Mensalista
Calcular_Salário( )
Horista
Calcular_Salário ()
Autônomo
Calcular_Salário()
{completo}
Figura 36 – Exemplo de classe abstrata
Nesse exemplo, a classe empregado não possui instâncias diretas, e a operação Calcular_Salario( ) 
será implementada por métodos diferentes em cada subclasse. A classe de origem de qualquer estrutura 
é a classe definidora de mais alto nível.
Ela define o “protocolo” ou “assinatura” da estrutura (tipo de um atributo, número e tipo de 
argumentos e tipo de resultado de uma operação). As classes descendentes podem refinar o protocolo, 
restringindo os tipos ou refazendo a inicialização ou a codificação do método, mas não podem ampliar 
ou modificar o protocolo.
Por exemplo: se um atributo foi definido na classe de origem, as classes descendentes podem 
restringir os valores que aceitam no atributo, mas não podem modificar seu tipo.
O discriminador {completo} indica que qualquer instância da superclasse empregado será uma 
instância de um dos seus filhos, e a superclasse se torna abstrata.
Já o discriminador {incompleto} indica que o conjunto pode esperar novas subclasses, e a 
superclasse é concreta. Dessa forma, a superclasse pode ser instanciada diretamente.
4.8.3 Polimorfismo (ocultamento de informações)
O polimorfismo implica que uma mesma operação pode comportar-se de maneira diferente em 
classes distintas, apesar de possuir o mesmo nome. É a propriedade de se utilizar um mesmo nome para 
fazer coisas diferentes.
 observação
Por exemplo: mandar alguém correr. Se a pessoa estiver parada, irá 
sair correndo. Se a pessoa estiver no volante de um carro, irá aumentar a 
pressão do pé no acelerador.
O polimorfismo é estimulado pelo paradigma da hereditariedade, exclusivo da OO. Dentro do 
polimorfismo, pode-se ter a sobreposição, a redefinição (overriding) de método: o método deve ter a 
mesma assinatura (nome, argumentos e valor de retorno) e código diferente.
67
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
Já na sobrecarga (overloading), usa-se o mesmo nome e mais alguma característica para se fazer a 
mesma coisa. Dependendo dos argumentos da chamada, será chamado o método adequado.
4.8.4 Interfaces tipos e papéis
A herança múltipla não é permitida em algumas de programação OO diretamente. Para facilitar a 
necessidade do uso desse tipo de herança, aparece o uso da interface.
Uma interface, por exemplo, na linguagem Java não é uma classe, é um arquivo que define valores 
constantes, e as operações que outra classe deve implementar. Ela não tem operações/métodos, apenas 
seus protótipos.
Dessa forma, quando uma classe expõe apenas constantes e operações sem implementação, também 
é chamada de interface.
4.8.5 Pacotes lógicos
A UML define um diagrama de pacotes como sendo um modelo que descreve como os elementos são 
organizados dentro de pacotes e suas dependências. Um pacote pode estar contido em outros pacotes.
Em um diagrama de pacotes, esses são ligados por setas pontilhadas, que têm seu estereótipo 
alterado de acordo com a necessidade.
Um pacote pode ter qualquer diagrama da UML, porém são mais comuns em diagrama de casos 
de uso, para ajudar a abstração do domínio do problema, e em classes, para ajudar na organização das 
classes construídas em sistemas médios e grandes.
Uma classe também pode ser declarada com “em pacote” e, dessa forma, terá a sua visibilidade 
restrita ao pacote em que reside. Classes fora desse pacote não poderão sequer saber de sua existência 
e, por isso, não poderá acessar classes do pacote.
Uma classe dentro de um pacote sem visibilidade definida assume a visibilidade padrão do pacote.
Existe uma notação especial na UML para designar um pacote. Essa notação não deixa dúvidas ao 
implementador que está usando o diagrama sobre a intenção do uso do pacote.
pktLogin
Figura 37 – Exemplo de um pacote
68
Unidade II
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
Nesse exemplo, todas as classes referentes ao login estão contidas nesse pacote. O acesso a essas 
classes internas vai depender da visibilidade do pacote.
4.8.6 Objetivos do diagrama de classes
1. Mostrar a estrutura estática do sistema.
2. Montar essa estrutura com as classes de objetos e também como seus relacionamentos.
3. Mapear os objetos a partir das classe de objetos com seus nomes, atributos e operações.
4. Aplicar as propriedades e características da tecnologia OO por meio dos mecanismos de associação, 
herança, polimorfismo e abstração.
4.9 estudo de caso aplicando modelo de classes
Para demonstração do uso de um dos mais importantes modelos da UML, será utilizada a descrição 
de um sistema de vendas simples, com algumas funcionalidades fundamentais.
Como ferramenta de apoio à preparação do estudo de caso, foi utilizada a ferramenta Case Enterprise 
Architect (EA).
 Saiba mais
O estudo de caso foi adaptado do exemplo apresentado no livro 
Modelagem de Objetos, do autor José Davi Furlan, publicado pela editora 
Makron Books (FURLAN, 1998).
4.9.1 Descrição do sistema
O sistema de vendas tem o objetivo de fornecer informações unificadas, abrangentes e atualizadas 
aos vendedores, incluindo a situação dos pedidos tirados, a posição de crédito dos clientes, a programação 
de apresentação de produtos e a eficiência de vendas.
A força de vendas está estruturada em filiais, zonas e setores. Uma filial atua em uma área geográfica. 
Os vendedores das filiais atuam em zonas de vendas e um deles é o responsável pela tal. A estrutura de 
visitas aos clientes pelos vendedores é definida por essas zonas de vendas e distribuída aos vendedores. 
As visitas ainda são organizadas semanalmente e representam períodos semanais, quinzenais e mensais.
A partir da data e do período de visita, o sistema encarrega-se de gerar automaticamente o roteiro 
diário que deve ser seguido pelo vendedor para cumprir sua programação de vendas.
69
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
4.9.2 Requisitos do sistema
A partir da descrição do sistema existem diversas alternativas de solução. De qualquer maneira, os 
requisitos independem de outra solução específica, mais simples ou mais complexa, já que eles mapeiam 
as necessidades dos clientes em forma de sentenças.
A figura 38 apresenta o diagrama de requisitos do sistema a ser modelado.
 observação
Os requisitos são organizados em dois grupos ou pacotes. O pacote de 
requisitos funcionais e o pacote de requisitos não funcionais:
• O pacote que contém os requisitos funcionais apresentam 
as características que representam o comportamento das 
funcionalidades ou regras de negócio que o sistema deve apoiar.
 
• O pacote de requisitos não funcionais contém os requisitos condicionantes 
e níveis de desempenho que o sistema deve atender. Por exemplo: tempo 
de resposta do sistema, transações de segurança etc.
No nosso estudo, somente serão abordados os requisitos funcionais.
Requisitos funcionais
req Modelo de requisitos
RF01 – O sistema deve manter atualizada a posição do cliente
RF03 – Sistema emite informações adicionais sobre os clientes
RF06 – Análise do histórico de vendas
RF02 – O sistema deve elaborar o roteiro de visita do dia
RF05 – Analisasituação financeira do cliente
RF04 – Gera informações sobre filial
RF07 – Registra pedido de venda
Figura 38 – Requisitos do sistema modelado na ferramenta EA
70
Unidade II
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
4.9.3 Modelo de classe do sistema
Após uma análise dos requisitos e reuniões com a área de vendas, o analista de sistemas aprova o 
modelo de requisitos e detalha as funcionalidades usando o modelo de casos de uso.
A partir dos cenários e das funcionalidades, são descobertas as entidades envolvidas com o problema 
e que serão usuárias do sistema, e as entidades de dados que serão modeladas e colocadas no banco de 
dados desse.
As principais classes obtidas com essa análise são:
1. filial de venda;
2. zona de venda;
3. setor de venda;
4. cliente;
5. produto;
6. produto em cliente;
7. preço do produto;
8. pedido;
9. item de pedido;
10. nota fiscal;
11. fatura.
A figura 39 apresenta o diagrama de classes proposto para o sistema, contendo os principais atributos.
Esse modelo/diagrama é denominado de modelo de domínio, já que não contém as classes de objetos 
da solução tecnológica do sistema, tais como: classes de interface, classes de comunicação, classes de 
padrões e classes de banco de dados.
Essas classes completarão o modelo de domínio na fase de design do projeto.
71
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
class Diagrama de Classes
Filial de venda
- numero: int
- nome: char
Zona de venda
- numero: int
- nomeDoVendedor: char
Cliente
- codigo: int
- nomeCompleto: char
- nomeReduzido: char
- endereco: char
- IRPJ: char
- telefone: char
- horarioDeVisita: int
- CondicaoDePagamento: int
- dataDaUltimaVisita: date
Pedido
- numero: int
- data: date
- situacao: int
- tipoDePedido: int
Item de pedido
- numero: int
- quantidade: date
- precoNegociado: int
- situacao: int
- condicaoDeEntrega: int
Fatura
- numero: int
- dataDeEmissao: date
- dataDeVencimento: date
- valor: int
- dataEfetivaPagamento: date
Nota fiscal
- numero: int
- dataDeEmissao: date
- situacao: boolean
Produto em cliente
- data: date
- quantidade: int
- tipo: int
Produto
- codigo: int
- descricao: int
- faixaDePreco: int
- valorUnitario: int
Setor de venda
- nome: char
- dataDaUltimaVisita: date
- periodoDeVisita: date
*
*
1
1 1
1
0..* 0..*
0..*
0..*
1
0..*
0..*
0..*
0..*
0..* 0..*
0..*
Figura 39 – Diagrama de classes preliminar
Nesse diagrama, temos as principais classes juntamente com seus relacionamentos.
O modelo, nesse momento, ainda não sofreu quaisquer questionamentos conceituais profundos, ou 
mesmo foi promovida uma normalização visando à sua estabilidade e integridade.
As operações dessas classes são obtidas a partir do estudo das funcionalidades descritas nos modelos 
de caso de uso e diagramas de sequência das transações necessárias, para que o sistema atenda aos 
requisitos, que não serão mostrados nesse exemplo, já que se pretende apresentar somente um exemplo 
de aplicação do modelo de classes.
A figura 40 apresenta o mesmo diagrama de classes, mas com as principais operações necessárias 
para resolver o sistema.
72
Unidade II
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
class Diagrama de Classes
Filial de venda
- numero: int
- nome: char
+ obter_Nome_Filial(): void
Zona de venda
- numero: int
- nomeDoVendedor: char
Cliente
- codigo: int
- nomeCompleto: char
- nomeReduzido: char
- endereco: char
- IRPJ: char
- telefone: char
- horarioDeVisita: int
- CondicaoDePagamento: int
- dataDaUltimaVisita: date
+ obte_Clientes_Ativos() : void
+ obter_Limite_Credito() : void
+ obter_Condicao_Entrega : void
+ obter_Condicao_Pagamento() : void
+ obter_dia_Entrega() : void
Pedido
- numero: int
- data: date
- situacao: int
- tipoDePedido: int
+ obter_Pedido() : void
+ incluir_Pedido() : void
Item de pedido
- numero: int
- quantidade: date
- precoNegociado: int
- situacao: int
- condicaoDeEntrega: int
+ obter_Descricao_Produto() : void
+ obter_Preco_Produto() : void
Fatura
- numero: int
- dataDeEmissao: date
- dataDeVencimento: date
- valor: int
- dataEfetivaPagamento: date
+ obter_Faturas_Vencidas() : void
+ obter_Faturas_A_Vencer
Nota fiscal
- numero: int
- dataDeEmissao: date
- situacao: boolean
+ obter_NF_Cliente() : void
Produto em cliente
- data: date
- quantidade: int
- tipo: int
+ registrar_Estoque_Cliente() : void
+ registrr_Produto_Recolhodo() : void
Produto
- codigo: int
- descricao: int
- faixaDePreco: int
- valorUnitario: int
+ obter_Descricao_Produto() : void
+ obter_Preco_Produto() : void
Setor de venda
- nome: char
- dataDaUltimaVisita: date
- periodoDeVisita: date
+ atualizar_Data_Ultima_Visita() : void
*
*
1 1
1
0..* 0..*
0..*
0..*
1
0..*
0..*
0..*
0..*
0..*
0..*
1
0..*
Figura 40 – Diagrama/modelo de classes com algumas operações
O modelo de classes, quando completo, incluindo atributos e operações, pode ser implementado em 
um banco de dados e em uma linguagem de programação orientada a objetos.
Outras classes serão necessárias, tanto para o banco de dados, como para a implementação em uma 
linguagem específica nas próximas fases do desenvolvimento.
Para a fase de design, deverão ser desenvolvidos os modelos de interface homem versus máquina, 
que indicará as interações dos usuários com o sistema. Para isso deverão ser montados os modelos de 
casos de uso com os atores e as funcionalidades.
73
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
Por meio do modelo de caso de uso e do protótipo, os diagramas de sequência indicarão as mensagens 
que serão trocadas entre os objetos. A partir dessas mensagens, o modelo de classe será aumentado, e 
todas as operações ou métodos deverão ser incluídos nas classes específicas.
 resumo
Esta unidade apresentou uma visão da estrutura da UML. Foi discutido 
que, de acordo com os autores a UML, não é um modelo de processo/
metodologia de software.
Ela é considerada uma linguagem padrão de modelagem de sistemas e, 
por isso, tem uma notação e um mecanismo para “mostrar o problema”, de 
forma a expor a essência do domínio de um aplicativo.
Também se detalhou os conceitos envolvidos com todos os diagramas 
apresentados na linguagem UML, principalmente o diagrama de classes de 
objetos. O detalhamento desse modelo se justifica devido à sua importância 
na tecnologia orientada a objetos.
A partir desse modelo de classes detalhado, são derivadas as soluções 
de banco de dados e as classes que serão implementadas em linguagens 
específicas. O diagrama de classes é a entrada para os processos de 
arquitetura e implentação, tanto do banco de dados como do aplicativo.
Uma das mensagens mais importantes é com relação ao reuso de 
software. Quando se trabalha com os conceitos envolvidos com o reuso de 
software, o modelo de classes é fundamental e apresenta os mecanismos 
de herança e polimorfismo que permite um avanço considerável em direção 
à reusabilidade.
 exercícios
Questão 1. De acordo com a IBM-Rational, a Unified Modeling Language (UML) é uma linguagem 
de modelagem não proprietária adotada pela OMG, e não uma metodologia de desenvolvimento. Ela 
não diz como desenvolver ou manter um sistema ou software, mas auxilia a visualizar seu desenho 
e a comunicação entre os objetos envolvidos com o sistema. Também permite que desenvolvedores 
vejam os produtos de seus trabalhos em diagramas ou gráficos padronizados, oferecendo uma notação 
gráfica, especificando os significados, isto é, ela é uma liguagem com uma semântica predefinida. É 
uma notação independente de metodologias ou processos, embora muitas delas, como o RUP (Rational 
Unified Process), tenham sido especificamente desenvolvidos utilizando a UML. Outro fator importante 
é a diferença entre um modelo UML e um diagrama (ou conjunto de diagramas) de UML; um diagramaou gráfico é uma representação gráfica da informação de um determinado sistema, e o modelo pode 
74
Unidade II
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
existir independentemente. Considerando-se os conceitos sobre a UML, analise as afirmações a seguir e 
assinale a alternativa incorreta:
A) A visão de caso de uso de um sistema descreve as fucionalidades ou o comportamento do sistema 
assim como os analistas e programadores de sistemas.
B) De acordo com diversos autores, o diagrama de classes de objetos é o mais importante dos 
diagramas da UML, pois uma classe de objetos é uma coleção de objetos que podem ser descritos 
com os mesmos atributos e as mesmas operações. Também representam as entidades envolvidas 
em um sistema de informação.
C) Para que um sistema seja executado, as classes de objetos precisam estar relacionadas ou 
associadas no modelo de classes. Esse relacionamento ou associação deve estar de acordo com 
as necessidades do sistema e deve cobrir as regras de negócio envolvidas com as funcionalidades 
que o sistema executará.
D) Sistema é a representação abstrata do mundo real; quanto mais complexo, mais necessita de 
descrições de seus vários aspectos. Ele deve mostrar: a estrutura estática dos objetos e a interação 
dinâmica entre eles; as características do tipo de tempo de processamento, de confiabilidade, de 
usabilidade etc.; e, por último, o mapeamento do modelo organizacional em termos da organização 
do trabalho, mapeamento e os códigos.
E) Herança é o mecanismo de reutilização de atributos e operações definidos em superclasses por 
classes mais específicas, podendo ser usada para expressar tanto generalização como associação.
Resposta: Alternativa A.
De acordo com a OMG, a UML apresenta 4 grandes objetivos: especificação de um sistema, 
documentação de todos os artefatos produzidos no processo, estruturação para subvisualização 
e maior visão lógica do desenvolvimento completo de um sistema de informação. A UML é uma 
linguagem padronizada de se modelar sistemas de informação desenvolvidos na tecnologia da 
Orientação a Objetos.
Análise das alternativas
A) Incorreta. A visão de caso de uso de um sistema realmente descreve as funcionalidades ou o 
comportamento de um sistema, mas tem como princípio fundamental entender os requisitos do 
sistema e interpretá-los graficamente. Outro fator fundamental é que os Casos de Uso são como 
uma linguagem de comunicação entre os usuários e os desenvolvedores de um determinado 
sistema.
B) Correta. Uma classe de objetos representa uma ideia ou um conceito simples e categoriza objetos 
que possuem propriedades similares, configurando-se em um modelo para a criação de novas 
instâncias. Exemplo: uma classe que represente um Cliente pode ser instanciada para representar 
75
Re
vi
sã
o:
 V
irg
ín
ia
 -
 D
ia
gr
am
aç
ão
: M
ár
ci
o 
- 
14
-0
8-
20
12
ModelageM de Processos
um cliente pessoa física ou um cliente pessoa jurídica, os quais possuem características semelhantes 
e específicas.
C) Correta. Esses relacionamentos ou associações definem as regras que são impostas pelas regras de 
negócio da aplicação sendo modelada.
D) Correta. Cada visão apresentada em um diagrama da UML é descrita por um ou mais diagramas, 
que contêm informações referentes a um aspecto específico do sistema sendo modelado.
E) Correta. Quando se usa o paradigma da herança na OO, uma classe de menor nível (subclasse) 
é considerada uma classe especializada ou uma classe de extensão da classe de maior nível 
(superclasse).
Questão 2. Dentro da UML, o diagrama de classe de objetos tem por objetivo descrever um grupo 
de objetos com propriedades similares, relacionamentos comuns com outros objetos e uma semântica 
comum. As propriedades são: os atributos e as operações. Estas são encapsuladas no objeto. Exemplo: 
em um sistema ERP, o cliente e o fornecedor são classes de objetos. Cada cliente tem um nome e 
um endereço; estes seriam os atributos comuns da classe cliente. Fornecedores também podem ter os 
mesmos atributos, nomes e endereços definidos. Entretanto, elas podem não estar definidas em uma 
mesma estrutura de objetos devido à distinção semântica. Como se pode observar, o agrupamento em 
classes não leva em conta apenas o compartilhamento de propriedades, senão essas classes deveriam 
ser sempre agrupadas na mesma estrutura. Considerando-se os conceitos apresentados sobre a UML 
nesta unidade, examine as afirmações a seguir e assinale a alternativa incorreta:
A) Com a hierarquia de classes de objetos que são apresentadas no diagrama de classes e com o 
mecanismo de herança, o modelo de classes de objetos potencializa o reuso no desenvolvimento 
de software OO.
B) Para se ter herança múltipla em um modelo de classes, necessita-se que uma subclasse herde 
atributos e operações de mais de uma superclasse.
C) Quando um modelo de classes apresenta herança múltipla e vai ser implementado em uma 
linguagem de programação OO e em banco de dados, pode-se ter problemas na transição, devido 
a que esses ambientes podem não suportar a herança múltipla.
D) O uso de herança múltipla deve ser evitado a todo custo nos projetos de sistema OO, haja visto ele 
nunca aparecer na modelagem do mundo real.
E) Uma classe abstrata possui a mesma estrutura de uma classe concreta, a única diferença é que 
tem um modificador abstract em sua definição de atributo ou de operação. Ela não pode ser 
instanciada, ou seja, não é possível obter objetos. Classes abstratas podem ser herdadas por outras 
classes abstratas ou concretas, e isso possibilita o polimorfismo.
Resolução desta questão na plataforma.