Modelagem de Processos

Unidade II
3 Modelo Conceitual da UML
3.1 Introduo

O Object Management Group (OMG) adotou a UML em novembro de 1997. Essa adoo ocorreu
em um evento histrico e marcante, pois assinalou a aceitao de uma linguagem padronizada de
modelagem de sistemas baseada nas melhores prticas atuais para a anlise, projeto e construo de
software orientado a objetos.

Saiba mais
A Object Management Group, ou OMG, uma organizao internacional
que aprova padres abertos para aplicaes orientadas a objetos. O Object
Management Group foi fundado em 1989. Constantemente, a OMG publica
o documento dos padres e normativos sobre a UML no seu portal cuja URL
: <http://www.omg.org/spec/UML/2.3/Infrastructure>.
A UML a primeira notao que atingiu o concenso entre a maioria dos profissionais,
vendedores e acadmicos como o padro real para expressar um domnio comercial da soluo
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 construo do sistema;
documentar as decises tomadas pela equipe de desenvolvimento de projeto (REED JR., 2000).
3.2 Viso geral da UML

A UML no um modelo de processo/metodologia de software. uma notao, um mecanismo para

mostrar o problema de forma a expor a essncia do domnio de um aplicativo.
43

Unidade II
A combinao da UML com um bom modelo de processo, tais como, o RUP (Rational Unified Process)
ou o processo gil SCRUM, resulta em uma poderosa combinao para a criao de aplicativos bemsucedidos (REED JR., 2000).
A linguagem de modelos UML tem dois objetivos: um deles proporcionar consistncia, informando
o cliente ou patrocinador do projeto de que o domnio do problema est bem entendido pela equipe
de desenvolvedores. O outro objetivo proporcionar um modelo de consistncia para a equipe de
implementao (arquitetos e programadores), que assim podero fazer uma implementao adequada
do software.
Lembrete
Todavia, deve ficar claro que somente os diagramas da UML no
conseguem garantir o processo de desenvolvimento. Um bom modelo de
processo e um plano adequado do projeto so fundamentais para que o
projeto no falhe.
Todos os artefatos propostos pela UML so rastreveis e, se construdos 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 construdos ao longo do desenvolvimento com a UML serviro como um ponto
de controle da qualidade do modelo anterior, j que se completam. Como os modelos UML so interrelacionados na sua criao, mais fcil identificar quando um componente est faltando ou est incorreto.
Todavia, a UML no resolve diretamente alguns aspectos de um projeto e, se necessrio, deve-se
utilizar outros diagramas auxiliares, como a interface grfica de usurio (GUI), a distribuio do processo
(processamento distribudo) e a distribuio dos dados (BDs distribudos).
3.3 Arquitetura da UML

Uma arquitetura de sistema de software pode ser descrita por cinco vises interconectadas. Cada
viso uma projeo na organizao e estrutura do sistema, focando em um aspecto particular desse.
As cinco vises da arquitetura UML so: viso de anlise, viso de design, viso de implementao,
viso do processo e viso da implantao. Para a UML, o modelo ou viso que interconecta essas vises
se d pelo modelo de caso de uso.
A viso de caso de uso de um sistema compreende os que descrevem o comportamento do sistema
como visto pelos usurios finais, analistas e testadores.
Essa viso no especifica a organizao do sistema de software. Na UML, os aspectos estticos do
sistema so capturados no diagrama de caso de uso.
44

Modelagem de Processos
Os 13 diagramas da UML esto divididos em trs categorias: esttico, dinmico e arquitetural:
Os diagramas estticos mostram a esturutra do sistema e as responsabilidades. Esses diagramas
mostram a estrutura fsica dos elementos e no envolvem a passagem do tempo. Isto ,
eles no mostram a dinmica das coisas, simplesmente sua organizao. Os trs principais
diagramas estticos da UML so: o modelo de caso de uso, o modelo de classes e o modelo
de objetos.
Um diagrama dinmico mostra a interao ativa que o sistema suporta e detalha a interao
entre os elementos estruturais dos diagramas estticos.
Essas interaes dinmicas so descobertas nos casos de uso como caminhos executados
em resposta a alguns estmulos externos ao sistema. Os diagramas dinmicos mostram o
comportamento pretendido do sistema. Os principais diagramas dinmicos so: atividades,
comunicao, sequncia e estado.
Um diagrama arquitetural mostra a realizao do sistema em componentes funcionais e
executveis. Eles tambm diferenciam a localizao fsica da execuo e os ns de armazenamento
e uma estrutura dentro da qual eles podem interagir.
Os principais diagramas estruturais so: componentes e implantao.
3.4 Modelagem estrutural

Na UML, o principal diagrama que mostra a estrutura de um sistema o diagrama de classes.

Todavia, outros diagramas tambm permitem visualizar a estrutura do sistema, tais como, o diagrama
de pacotes, o diagrama de componentes, o diagrama de objetos e o diagrama deployment (implantao).
3.4.1 Classes de objetos
Uma classe de objetos uma coleo de objetos que podem ser descritos com os mesmos atributos
e as mesmas operaes.
Representa uma idia ou um conceito simples e categoriza objetos que possuem propriedades
similares, configurando-se em um modelo para a criao de novas instncias (outros objetos).
Uma classe de objetos na UML possui trs segmentos: nome, atributos e operaes.
A representao ou notao de uma classe um retngulo com os trs 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 instncias do objeto podem ter.
45

Unidade II
O terceiro segmento da classe so as operaes. Uma operao a implementao de um servio
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/instncias
As classes de objetos, no modelo de classes, se relacionam ou se associam de acordo com as
necessidades do sistema. Esses relacionamentos so denominados associao entre classes.
Um relacionamento define as regras da associao que, por seu lado, so impostas pelas regras de
negcio da aplicao, sendo modelada.
A criao de um objeto, baseado em uma classe, recebe um nome especial: instncia. Quando
necessrio manipular um determinado objeto, a classe carregada na memria, e os objetos so
instanciados, isto , so criados na memria e podem ser manipulados.
A instanciao de objetos depende da linguagem OO utilizada, mas, em geral, possuem uma funo
especial que cuida das instncias dos objetos, denominada construtora.
Quando o objeto j no mais necessrio, outra funo especial chamada de destrutora da classe
elimina as instncias criadas. Por exemplo: para uma classe funcionrio, o objeto tipo funcionario Joo
Carlos da Silva seria uma instncia na memria.
3.4.3 Mecanismos comuns
A UML feita simplesmente pela presena de mecanismos comuns que garantem a consistncia a
partir da linguagem, tais como: especificao, adornos e mecanismo de extensibilidade.
A especificao refere-se aos padres das descries dos componentes dos modelos: como
nomear os componentes, como descrever a lgica de um cenrio de um caso de uso , e assim
por diante.
Adornos so itens grficos e textuais que so adicionados a uma notao de um elemento bsico e
so usados para visualizar detalhes da especificao do elemento. Por exemplo, no smbolo de n de um
diagrama de implantao, pode ser interessante colocar os componentes executveis dentro de uma
caixa extra do desenho.
O mecanismo de extensibilidade da UML permite extender a linguagem de uma maneira controlada.
Esse mecanismo inclui esteretipos, valores marcados e restries.
Um esteretipo extende o vocabulrio da UML, permitindo que se criem novos tipos
de blocos de construo que so derivados de outros existentes, mas especifcos para um
determinado problema.
46

Modelagem de Processos
3.4.4 Diagramas da UML
Com um modelo, possvel um melhor entendimento dos sistemas que esto em desenvolvimento.
Com a UML, pode-se construir modelos a partir de um conjunto de blocos bsicos, tais como, classes,
interfaces, colaboraes, componentes, ns, dependncias, generalizaes e associaes.
Lembrete
Quando o homem modela qualquer coisa, ele est criando uma
simplificao da realidade.
A UML prope 13 diagramas, conforme mostra a quadro 2:
Quadro 2 Diagramas da UML
Nmero

Diagramas

UML 1.X

UML 2.3

Atividade

Atividade

Caso de uso

Caso de uso

Classe de objetos

Classe de objetos

Objetos

Objetos

Sequncia

Sequncia

Colaborao

Comunicao

Estado

Estado

Componentes

Componentes

Implantao

Implantao (deployment)

10

-------------

Pacotes

11

-------------

Interao

12

-----------

Tempo

13

----------

Estrutura composta

Lembrete
Com relao 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 especficos do problema sendo modelado.
Um diagrama da UML pode ser usado para especificar artefatos
diferentes em atividades diferentes do processo de software. Por
47

Unidade II
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 so usados para modelar o comportamento de um sistema, e a forma em
que esses comportamentos esto relacionados em um fluxo geral desse.
O fluxo mostra os caminhos de um processo lgico a seguir, com base em vrias condies,
processamento simultneo, acesso a dados, interrupes e outras distines do caminho lgico.
So 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 relaes 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 usurios.
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 distino de que retrata instncias de objetos das classes e seus relacionamentos em um
ponto no tempo.
Isso pode parecer semelhante a um diagrama de estrutura composta, que tambm modela
comportamentos em tempo de execuo. A diferena que os diagramas de objetos exemplificam os
diagramas de classes estticas, enquanto que os diagramas de estrutura composta refletem arquiteturas
em tempo de execuo.
Eles so teis na compreenso de um diagrama de classes complexas, criando diferentes casos em
que os relacionamentos e as classes so aplicados.
Um diagrama de objeto tambm pode ser uma espcie de diagrama de comunicao, que
tambm modela as conexes entre os objetos, mas adiciona sequncias de eventos ao longo de
cada caminho.
48

Modelagem de Processos
3.4.4.4 Diagrama de sequncia
O diagrama de sequncia um dos quatro tipos de diagrama de interao. Um diagrama de sequncia
uma representao estruturada de comportamento com uma srie de etapas sequenciais ao longo do
tempo.
Ele usado para descrever o fluxo de trabalho, passagem de mensagens. Cada elemento da sequncia
organizado em uma sequncia horizontal, com mensagens que passam para trs e para frente entre
os elementos.
Um elemento de ator pode ser usado para representar o usurio 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 interaes.
3.4.4.5 Diagrama de comunicao
Um dos quatro tipos de diagrama de interao. Um diagrama de comunicao mostra as interaes
entre os elementos em tempo de execuo da mesma maneira que um diagrama de sequncia.
No entanto, os diagramas de comunicao so usados para visualizar as relaes entre objetos, enquanto
os diagramas de sequncia so mais eficazes na visualizao de processamento ao longo do tempo.
Os diagramas de comunicao empregam associaes rotuladas e ordenadas para ilustrar o
processamento. A numerao importante para indicar a ordem e a nodificao de processamento.
Um esquema de numerao pode ser: 1, 1.1, 1.1.1, 1.1.2, 1.2 e assim por diante.
3.4.4.6 Diagrama de estado (mquina de estado)
Os diagramas de estado da mquina 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 transio ou guardas de restrio.
Outros aspectos do diagrama de mquina 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 pedaos de software, controladores embutidos que formam
um sistema, sua organizao e as dependncias.
Um diagrama de componente tem um nvel maior de abstrao do que um diagrama de classes. Geralmente,
um componente implementado por uma ou mais classes (ou objetos) em tempo de execuo.
49

Unidade II
Eles so blocos de construo, construdos de modo que, eventualmente, um componente pode
abranger uma grande parte de um sistema.
3.4.4.8 Diagrama de implantao
Um diagrama de implantao (deployment) mostra como e onde o sistema ser implantado, ou seja,
sua arquitetura de execuo.
Dispositivos de hardware, processadores e ambientes de software de execuo (artefatos do sistema)
so refletidos como ns, e a construo interna pode ser representada incorporando ns no desenho.
Como os artefatos so alocados para os ns do modelo de implantao do sistema, a alocao guiada
pela utilizao das especificaes de implantao.
3.4.4.9 Diagrama de pacotes
O diagrama de pacotes (pakage) mostra a organizao dos elementos de um modelo em pacotes
(agrupamentos) e as dependncias entre esses pacotes, incluindo pacotes importados e extenses de
pacotes.
3.4.4.10 Diagrama de interao (viso geral)
Um diagrama geral de interao visualiza a cooperao entre os diagramas de interao para ilustrar
um fluxo de controle que serve a um propsito abrangente.
Como os diagramas gerais de interao so uma variante de diagramas de atividades, a maioria da
notao do diagrama a mesma, como o processo de construo do diagrama.
Pontos de deciso, forks, junes, pontos iniciais e finais so os mesmos. Em vez de elementos
de atividade, no entanto, elementos retangulares so usados. Existem dois tipos desses elementos:
elementos de interao e e elementos de ocorrncia.
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 representao visual da mudana dos objetos, mudando de estado e interagindo
todo o tempo.
Ele pode ser usado para definir os componentes e softwares embutidos. Tambm pode ser utilizado
para especificar processos de negcio orientados pelo tempo.
3.4.4.12 Diagrama estrutura composta
Um diagrama de estrutura composta reflete a colaborao interna de classes, interfaces ou
componentes (e suas propriedades) para descrever a funcionalidade do sistema.
50

Modelagem de Processos
Eles so similares aos diagramas de classe, exceto pelo fato de que eles modelam um uso especfico
da estrutura. Um diagrama de estrutura composta usado para expressar o tempo de execuo das
arquiteturas, padres e relacionamentos dos elementos participantes, que no podem ser refletidos por
meio de diagramas estticos.
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 Introduo

O diagrama de classes mostra a estrutura esttica do sistema por meio de suas classes e objetos e
tambm como eles se relacionam.
considerado por alguns autores como o mais importante diagrama no desenvolvimento orientado
a objetos e, portanto, tambm da UML.
Observao
A meta na construo de um modelo de objetos incorporar os
conceitos do mundo real que sejam importantes para a aplicao.
A figura 12 mostra um exemplo de modelo de classes de objetos na notao da UML.

Mundo real

Realidade de interesse
(Observado)

Modelo de objeto
Nome da classe de objetos
Atributos
Operaes ( )
Figura 12 Viso do mundo real x a OO

51

Unidade II
A figura 13 mostra um exemplo de diagrama de objetos com um metamodelo de classe, uma classe
e duas instncias da classe Jos da Silva e Maria Rodrigues.
Nome da classe de objetos

Pessoa

Nome dos atributos

Nome
idade

Operaes ( )

Mudar_endereo ( )

Jos da Silva
32

Maria de Tal
26

Objetos com valores da

classe pessoa.

O nome da classe (metamodelo)

representa o agrupamento de
objetos do mesmo tipo.
Figura 13 Exemplo de uma classe e suas instncias na notao UML

Alguns meios de implementao (linguagens de programao e sistemas gerenciadores de banco de

dados) exigem que um objeto tenha um identificador explcito para cada objeto. Esses identificadores
explcitos no so obrigatrios em um modelo de objetos.
A figura 14 mostra um uso incorreto de identificadores internos.

Pessoa
Cod_Pessoa
Nome

Pessoa
Correto

Nome
idade

Figura 14 Uso incorreto de identificador interno

Os identificadores internos (gerados pelas linguagens) no podem ser confundidos com atributos
do mundo real e no devem fazer parte do modelo conceitual. O nmero_telefone e nmero_placa_
carro no so identificadores internos porque tm significado no mundo real.
Uma classe sempre deve representar um mesmo assunto, isto , ela encapsula conhecimentos sobre
algo. No teria sentido colocarmos dados sobre a empresa em que trabalha na classe pessoa.
Pessoa e empresa so assuntos diferentes ou objetos diferentes e, portanto, devem estar em classes
distintas. Uma classe tem responsabilidade por tudo o que lhe diz respeito. No de responsabilidade da
pessoa/funcionrio incluir ou manter os dados da empresa.
Uma classe poder ter visibilidade pblica, protegida, privada:
Uma classe pblica indica que qualquer outra classe poder acessar seus atributos e solicitar a
execuo de suas operaes.
52

Modelagem de Processos
Uma classe denominada de privada quando restringe totalmente o acesso a seus atributos e as
suas operaes.
Uma classe com visibilidade protegida somente permite a ela e aos seus herdeiros o acesso a seus
atributos e suas operaes.
As operaes ou comportamentos de uma classe de objetos recebem e devolvem valores que
so passados numa lista de argumentos, dentro de um padro especfico que cada linguagem
adota.
O diagrama do modelo conceitual deve ser independente da tecnologia, e quando da implementao
que se considera os padres especficos.
A figura 15 mostra um exemplo de chamada de uma operao com a lista de argumentos.
Exemplo: mudar_endereo (novo_endereo, ok)
Operao

Parmetro
de entrada

Parmetro
de sada

Figura 15 Exemplo de uma operao e a lista de argumentos

Em um modelo de classes, existem diversas classes do domnio da aplicao que precisam se

relacionar dentro das regras de negcio.
Elas, quando esto 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 trs tipos: associao, agregao
e composio e generalizao/especializao.
4.2 Associao

Associao uma relao semntica entre classes. Uma associao acontece quando uma
determinada instncia de uma classe se associa a uma ou mais instncias de outra ou da
mesma classe.
Ligaes e associaes so os meios para estabelecermos relacionamentos entre objetos e classes. As
ligaes so conexes entre instncias de objetos.
A figura 16 mostra o metamodelo de associao de classes e um exemplo prtico.

53

Unidade II
Papel 1
Classe A

Classe B

Papel 2
associao

Pessoa

Empresa

trabalha_para

Joo da Silva

Telesp

ligao
Figura 16 Exemplo de uma associao entre duas classes. O modelo apresentado
o modelo de objetos no qual o objeto pessoa trabalha para uma empresa

As associaes ainda podem ser binrias, unrias, ternrias e assim por diante. Uma
associao dita binria quando duas classes esto envolvidas na associao, conforme mosta
a figura 17.
tem_capital

Pais

Cidade

0.1

Nome

Nome

Figura 17 Associao binria

Uma associao dita unria quando o relacionamento de uma classe consigo prpria.
A figura 18 mostra um exemplo de associao unria. Uma pea pode compor outras peas maiores,
mas tambm pode ser composta de outras peas menores.
Pea

1..*
Componente

Composta

0..*

Figura 18 Um exemplo de associao unria

Uma associao dita ternria quando trs classes fazem parte da associao. Na figura 19, tem-se
que um projeto tem vrias pessoas trabalhando nele e pode ser implementado em vrias linguagens
diferentes.
A nomeao das associaes so opcionais para associaes ternrias ou de ordem superior
(n-rias).
54

Modelagem de Processos
A figura 19 mostra um exemplo de associao ternria.
1..*

Projeto

1..*

Linguagem

1..*
Pessoa
Smbolo de associao ternria ou de ordem superior
Figura 19 Exemplo de uma associao ternria

4.3 Papis em associao

A UML possui uma notao especfica para representar as regras de uma associao entre os objetos
das classes.
A notao denomina-se cardinalidade ou multiplicidade e deve ser descrita no diagrama, como
mostra a tabela 1.
Tabela 1 Cardinalidades ou multiplicidades das associaes entre classes
Cardinalidade

Descrio

0..1

Opcional e nico

0..*

Opcional e mltiplo

Obrigatrio e nico

1..*

Obrigatrio e mltiplo

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 associao deve estar classificado, deve-se
utilizar a palavra-chave {ordenado}, como mostra a figura 20.
Classe A

Papel 2
Papel 1

{ordenado}

Classe B

Figura 20 Uso da palavra chave {ordenado}

Quando se quer declarar a visibilidade da associao, deve-se colocar os smbolos em frente ao nome
do papel (+ pblico, # protegido, - privado). Isso declara a visibilidade da associao em direo
quele papel.
55

Unidade II
Por exemplo: na figura 9, se for colocado em frente do papel 1 o smbolo +, est declarado que esse
papel na associao de uso pblico.
Quando existir a necessidade de mostrar o sentido da navegao em uma determinada
associao, deve-se colocar uma seta na extremidade da associao para indicar a direo
suportada pelo modelo.
A figura 21 mostra um exemplo do uso da navegao em uma associao entre duas classes de
objetos.
tem capital

Pais
Nome

0..1

Cidade
1

Nome

Figura 21 Navegao (restrio de acionamento de classes)

A seta indica o sentido em que a navegao suportada no modelo, dessa forma no possvel
operaes da classe cidade acessarem as operaes da classe pas.
4.4 Classe de associao

Em alguns modelos, devido s regras de negcio, torna-se necessria a colocao de atributos em

uma determinada associao. Um atributo uma propriedade dos objetos de uma classe.
Como uma associao tambm um objeto, perfeitamente possvel colocar nela atributos. Ento,
um atributo de ligao uma propriedade de uma associao.
A figura 22 apresenta a classe depto de uma empresa e a classe funcionrio, nas quais ficam os
funcionrios da empresa.
Depto
Nome

Chefia

Funcionrio
0..1

Cod_func
nome

Figura 22 O uso de atributos de associao

A questo que se coloca no modelo : onde colocar a data de posse da chefia, em departamento
ou em funcionrio? Todavia, a data de posse uma propriedade da associao chefia e deve
pertencer a ela.
A data de posse no propriedade nem do departamento e nem do funcionrio.
Uma das solues seria colocar a data em uma das classes associadas. A escolha fica a critrio do
analista, j que esse atributo no natural nem para departamento e nem para funcionrio.
56

Modelagem de Processos
O problema decorrente da colocao dos atributos de ligao em uma das classes ligadas a
flexibilidade futura do modelo. Caso haja qualquer dvida com relao ao futuro, como regra, cria-se
uma classe de associao.
Como mostra a figura 23, criou-se uma classe nova denominada classe de associao para permitir
a colocao do atributo especfico da associao.
A classe de objetos chefia, possui atributos prprios e provavelmente operaes para tratar esses
atributos e as associaes.
0..1
Depto

Funcionrio

Cod_func
nome

Nome

Chefia
Data_posse

Figura 23 O uso da classe de associao

A figura 24 mostra outro exemplo de classe de associao para um modelo mais sofisticado. Temos
um modelo que mostra uma empresa, seus funcionrios e o grau de desempenho desses.
Funcionrio
Nome
RG

0..* Trabalha_para

1..*

Empresa
Nome
Endereo

Endereo
Gerencia
Grau de
desempenho

Trabalha para
Salrio
Cargo
Admite_funcionrio ( )

Figura 24 Classes de associao

Note que o grau de desempenho pertence associao, j que o atributo somente tem sentido
enquanto o funcionrio ocupa o cargo de gerncia.
A classe trabalha para indica que o salrio e o cargo do funcionrio so atributos que dependem
da empresa em que trabalha, j que o modelo permite que um funcionario trabalhe em mais de uma
empresa.
57

Unidade II
4.5 Agregao e composio

Agregao um tipo especial de associao em que um objeto contm o(s) outro(s). tambm
chamado de relacionamento todo/parte. Agregao um modo de associao na qual um objeto
agregado feito de componentes. Os componentes fazem parte do agregado.
A figura 25 mostra um exemplo de agregao. Uma publicao possui artigos obrigatoriamente no
modelo. Isso significa que uma publicao composta necessariamente de artigos.
O diamante vazio indica que a ligao fraca, j que uma publicao pode existir sem nenhum
artigo, mas um artigo no existe sem uma publicao associada.
Publicao
1..*
0..*
Artigo

Figura 25 Exemplo de uma agregao entre classes associadas

As agregaes incluem exploses das partes e expanses de um objeto em suas partes constituintes.
A figura 26 mostra outro exemplo de agregao entre classes de objetos.
Empresa

Trabalha_para
0..1

Funcionrio
0..*

1
0..*
Diviso

1
0..*
Departamento

Figura 26 Exemplo de agregao

Uma empresa uma agregao de suas divises, que so, por sua vez, agregaes de seus
departamentos. Uma empresa no uma agregao de seus funcionrios, uma vez que empresa e
pessoa so objetos distintos e independentes.

58

Modelagem de Processos
Uma composio uma agregao forte em que as partes esto fisicamente contidas dentro do
todo. Os componentes no podem ser compartilhados por outros compostos. Uma excluso do todo
desencadeia uma excluso em cascata das partes, portanto, o ciclo de vida das classes em composio
coincidem.
A figura 27 mostra um exemplo de composio.
Livro

1
0..*
Captulo

Figura 27 Exemplo de composio (associao forte)

A excluso de um livro acarreta a excluso de todos os seus captulos, e a excluso dos captulos do
livro implica a elimincao do livro.
4.6 Generalizao/especializao

A generalizao uma forma de se estruturar a visibilidade de um elemento global com uma viso
mais detalhada desse. Isso feito adicionando caractersticas especficas ao elemento na viso detalhada
e aproveitando as caractersticas gerais.
generalizao

especializao

Figura 28 Generalizao x especializao

A generalizao/especializao pode ser usada para diversos outros modelos da UML, como em
diagramas de pacotes e diagramas de casos de uso.
59

Unidade II
As classes superiores so chamadas superclasses, e as inferiores subclasses. Tanto a superclasse como
as subclasses referem-se s caractersticas de um nico objeto.
Com a generalizao, um objeto simultaneamente instncia da superclasse e instncia da
subclasse.

Trabalha_para

Empresa
0..1

Diviso

Funcionrio

Associao de
generalizao

0..*

Masculino

Feminino

Departamento

Figura 29 Exemplo de generalizao

Uma rvore de generalizao composta por classes que descrevem um objeto. No exemplo da figura
19, a classe funcionrio foi especializada em masculino e feminimo, devido a caractersticas especficas
de cada um, mas o modelo garante que as caractersticas comuns esto representadas somente uma
vez na superclasse funcionrio.
Diz-se que masculino um tipo_de funcionrio ou masculino um funcionrio. Um funcionrio
ou masculino ou feminino.
4.7 Herana

Na UML, herana um mecanismo por meio do qual uma instncia de uma classe assume os atributos
e os comportamentos dos objetos de outra classe (antepassados ou antecedentes).
Os objetos subordinados herdam atributos e servios da classe superior. A propriedade herana
permite que novas classes sejam construdas pela herana de classes existentes. A figura 30 mostra um
exemplo de herana.

60

Modelagem de Processos
Aeronave
Classe ou superclasse

Jato

Planador
Subclasse

Figura 30 Exemplo de aplicao do mecanismo de herana

No exemplo da figura 30, as classes jato e planador so subclasses de aeronave. As classes subordinadas
podem ter atributos e ou mtodos prprios. O conceito de herana refora a extensibilidade caracterstica
que sempre se procurou na programao.
Uma classe descendente/subclasse no pode omitir ou suprimir um atributo da superclasse, seno
no seria uma instncia antecessora. As subclasses tambm so chamadas de classes derivadas ou
classes-filho na hierarquia de classes.
As classes que ficam mais altas na hierarquia so denominadas de superclasses.
Funcionrio

Funcionrio
feminino
nome solteira
registrar licena
maternindade

Funcionrio
masculino

Figura 31 Exemplo de herana

Pode acontecer de uma subclasse possuir alguma operao diferente de seu antecessor. Isso
chamado de extenso. Uma subclasse pode restringir atributos do antecessor. Isso chamado de
restrio, pois restringe os valores que aquela instncia pode assumir.
Lembrete
O mecanismo de herana se tornou sinnimo de reutilizao de cdigo
no projeto orientado a objetos.
61

Unidade II
A figura 32 mostra um exemplo completo do uso de herana.
Equipamento
nome
fabricante
preo
peso
Bomba

Tanque
Volume
presso

Tipo de equipamento

presso de suco
presso de descarga
taxa de fluxo

Tipo de tanque
Tipo de bomba

Tanque esfrico
Bomba centrfuga

dimetro

eixo de rotao

Tanque pressurizado
dimetro
altura

Tanque de teto flutuante

dimetro
altura

Bomba de imerso

Bomba de diafragma

dimetro de pisto
nmero de cilindros

material do diafragma

Figura 32 Exemplo completo do uso de herana

A quadro 3 mostra o contedo dos objetos da classe bomba centrfuga e da classe tanque de teto
flutuante com suas caractersticas especficas apesar de serem ambas equipamento.
Diversos atributos e operaes so vlidos para os dois objetos e possuem atributos e operaes
especficos.
Quadro 3 Contedo das classes
Bomba de diafragma

62

Tanque de teto flutuante

Nome = P101

Nome = T111

Fabricante = Simplex

Fabricante = Simplex

Peso = 100 kg

Peso = 10.000 kg

Preo = R$ 5.000,00

Preo = R$ 50.000,00

Presso suco = 1,1 atm

Volume = 400.000 l

Presso de descarga = 3,3 atm

Presso = 1,1 atm

Taxa de fluxo = 300 l/hora

Dimetro = 8 m

Mat. diafragma = teflon

Altura = 9 m

Modelagem de Processos
Herana um mecanismo da OO que permite criar novas classes a partir de classes j
existentes, aproveitando-se das caractersticas existentes na classe a ser extendida.
Este mecanismo muito interessante, pois promove um grande reuso e reaproveitamento
de cdigo existente. Com a herana possvel criar classes derivadas (subclasses) a partir de
classes bases (superclasses). As subclasses so mais especializadas do que as suas superclasses,
mais genricas. As subclasses herdam todas as caractersticas de suas superclasses, como
suas variveis e mtodos.
Imagine que dentro de uma organizao empresarial, o sistema de RH tenha que
trabalhar com os diferentes nveis hierrquicos da empresa, desde o funcionrio de baixo
escalo at o seu presidente.
Todos so funcionrios da empresa, porm cada um com um cargo diferente. Mesmo
a secretria, o pessoal da limpeza, o diretor e o presidente possuem um nmero de
identificao, alm de salrio e outras caractersticas em comum. Essas caractersticas em
comum podem ser reunidas em um tipo de classe em comum, e cada nvel da hierarquia ser
tratado como um novo tipo, mas aproveitando-se dos tipos j criados, a partir da herana.
Os subtipos, alm de herdarem todas as caractersticas de seus supertipos, tambm
podem adicionar mais caractersticas, seja na forma de variveis e/ou mtodos adicionais,
bem como reescrever mtodos j existentes na superclasse (polimorfismo).
A herana permite vrios nveis na hierarquia de classes, podendo criar tantos subtipos
quanto necessrio, at se chegar no nvel de especializao desejado. Podemos tratar
subtipos como se fossem seus supertipos, por exemplo, o sistema de RH pode tratar uma
instncia de presidente como se fosse um objeto do tipo funcionrio, em determinada
funcionalidade.
Porm, no possvel tratar um supertipo como se fosse um subtipo, a no ser que o
objeto em questo seja realmente do subtipo desejado e a linguagem suporte este tipo de
tratamento, seja por meio de converso de tipos ou outro mecanismo.
Fonte: <http://www.softechnetwork.com.br/java/CursoOO.pdf>. Acesso em: 15 jun. 2012.

4.8 Conceitos avanados envolvendo classes

4.8.1 Herana mltipla

Herana mltipla uma extenso da anlise orientada a objetos que permite uma classe ter mais de
uma superclasse e herdar todas as caractersticas (atributos e operaes) de todos os seus pais.
considerada a mais complicada forma de generalizao, e nem todas as linguagens de programao
do suporte diretamente. A figura 33 mostra um exemplo de herana mltipla.
63

Unidade II
Janela

Texto

rvore

Tela

Figura 33 Herana mltipla

Com a herana mltipla a classe tela herda todas as caracersticas de suas trs classes-pai ou superclasses.
A classe janela possui as propriedades das janelas e as operaes para mostr-las e moviment-las pela tela.
A classe texto oferece as propriedades textuais das janelas, com operaes/mtodos para manipular
linhas de texto etc.
A herana mltipla aumenta o potencial de uma linguagem orientada a objetos, mas a um custo na
complexidade da programao, bem como um overhead de compilao e de tempo de execuo.
Uma classe com mais de uma superclasse chamada de classe-de-juno.
Veculo

Terrestre

Carro

Aqutico

Anfbio

Barco

Figura 34 Classe-de-juno anfbia

Uma caracterstica proveniente da mesma classe ancestral encontrada em mais de um caminho

herdada apenas uma vez.
No exemplo da figura 34, a caracterstica cor da classe veculo herdada tanto por veculo terrestre
como por veculo aqutico, mas a subclasse veculo anfbio, que possui herana mltipla, herda a
caracterstica cor de apenas uma das suas superclasses.
64

Modelagem de Processos
As subclasses provenientes de generalizaes podem ou no ser disjuntas. No exemplo da figura 34,
as classes terrestre e aqutico no so disjuntas nesse nvel, porque elas se sobrepem, isto , algum
veculo pode andar na terra e na gua.
4.8.2 Classes abstratas
Uma classe abstrata uma classe que no possui instncias diretamente, mas cujos descendentes
possuem instncias diretas. Esse tipo de classe til durante um projeto OO, para facilitar a programao
e a manuteno dos sistemas.
s vezes, til criar superclasses abstratas para encapsular classes que participam em uma mesma
associao. Algumas classes abstratas aparecem naturalmente no domnio da aplicao, outras so
artificialmente criadas como um mecanismo para permitir reuso de cdigo.
As classes abstratas so usadas frequentemente para definir mtodos para serem abordados por subclasses.
Uma classe abstrata no uma classe concreta j que no pode ser instanciada diretamente. Para
ser instancivel a classe abstrata deve possuir descendentes concretos.
J uma classe concreta pode ser uma classe de folhas (ltimo nvel da hierarquia). Uma classe abstrata
no pode ser classe de folha j que precisa de descendentes para ser instancivel.
A figura 35 mostra uma hierarquia de classes concretas e dessa forma todas podem ser instanciveis
diretamente.
Trabalhador
{incompleto}

Pedreiro

Cobrador

Aougueiro

Figura 35 hierarquia de classes concretas

A classe trabalhador tambm pode ser classe concreta, pois algumas ocupaes podem estar contidas
nelas. Dessa forma, a hierarquia {incompleto}.
Todavia, uma classe concreta pode ser refinada em vrias 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 operao Calcular_Salario( ) e que
sero programadas com lgicas especficas.
65

Unidade II

Trabalhador

{completo}
Horista
Calcular_Salrio ()

Mensalista
Calcular_Salrio( )

Autnomo
Calcular_Salrio()

Figura 36 Exemplo de classe abstrata

Nesse exemplo, a classe empregado no possui instncias diretas, e a operao Calcular_Salario( )

ser implementada por mtodos diferentes em cada subclasse. A classe de origem de qualquer estrutura
a classe definidora de mais alto nvel.
Ela define o protocolo ou assinatura da estrutura (tipo de um atributo, nmero e tipo de
argumentos e tipo de resultado de uma operao). As classes descendentes podem refinar o protocolo,
restringindo os tipos ou refazendo a inicializao ou a codificao do mtodo, mas no 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 no podem modificar seu tipo.
O discriminador {completo} indica que qualquer instncia da superclasse empregado ser uma
instncia 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 informaes)
O polimorfismo implica que uma mesma operao 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.
Observao
Por exemplo: mandar algum correr. Se a pessoa estiver parada, ir
sair correndo. Se a pessoa estiver no volante de um carro, ir aumentar a
presso do p no acelerador.
O polimorfismo estimulado pelo paradigma da hereditariedade, exclusivo da OO. Dentro do
polimorfismo, pode-se ter a sobreposio, a redefinio (overriding) de mtodo: o mtodo deve ter a
mesma assinatura (nome, argumentos e valor de retorno) e cdigo diferente.
66

Modelagem de Processos
J na sobrecarga (overloading), usa-se o mesmo nome e mais alguma caracterstica para se fazer a
mesma coisa. Dependendo dos argumentos da chamada, ser chamado o mtodo adequado.
4.8.4 Interfaces tipos e papis
A herana mltipla no permitida em algumas de programao OO diretamente. Para facilitar a
necessidade do uso desse tipo de herana, aparece o uso da interface.
Uma interface, por exemplo, na linguagem Java no uma classe, um arquivo que define valores
constantes, e as operaes que outra classe deve implementar. Ela no tem operaes/mtodos, apenas
seus prottipos.
Dessa forma, quando uma classe expe apenas constantes e operaes sem implementao, tambm
chamada de interface.
4.8.5 Pacotes lgicos
A UML define um diagrama de pacotes como sendo um modelo que descreve como os elementos so
organizados dentro de pacotes e suas dependncias. Um pacote pode estar contido em outros pacotes.
Em um diagrama de pacotes, esses so ligados por setas pontilhadas, que tm seu esteretipo
alterado de acordo com a necessidade.
Um pacote pode ter qualquer diagrama da UML, porm so mais comuns em diagrama de casos
de uso, para ajudar a abstrao do domnio do problema, e em classes, para ajudar na organizao das
classes construdas em sistemas mdios e grandes.
Uma classe tambm pode ser declarada com em pacote e, dessa forma, ter a sua visibilidade
restrita ao pacote em que reside. Classes fora desse pacote no podero sequer saber de sua existncia
e, por isso, no poder acessar classes do pacote.
Uma classe dentro de um pacote sem visibilidade definida assume a visibilidade padro do pacote.
Existe uma notao especial na UML para designar um pacote. Essa notao no deixa dvidas ao
implementador que est usando o diagrama sobre a inteno do uso do pacote.
pktLogin

Figura 37 Exemplo de um pacote

67

Unidade II
Nesse exemplo, todas as classes referentes ao login esto 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 esttica do sistema.
2. Montar essa estrutura com as classes de objetos e tambm como seus relacionamentos.
3. Mapear os objetos a partir das classe de objetos com seus nomes, atributos e operaes.
4. Aplicar as propriedades e caractersticas da tecnologia OO por meio dos mecanismos de associao,
herana, polimorfismo e abstrao.
4.9 Estudo de caso aplicando modelo de classes

Para demonstrao do uso de um dos mais importantes modelos da UML, ser utilizada a descrio
de um sistema de vendas simples, com algumas funcionalidades fundamentais.
Como ferramenta de apoio preparao 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 Descrio do sistema
O sistema de vendas tem o objetivo de fornecer informaes unificadas, abrangentes e atualizadas
aos vendedores, incluindo a situao dos pedidos tirados, a posio de crdito dos clientes, a programao
de apresentao de produtos e a eficincia de vendas.
A fora de vendas est estruturada em filiais, zonas e setores. Uma filial atua em uma rea geogrfica.
Os vendedores das filiais atuam em zonas de vendas e um deles o responsvel pela tal. A estrutura de
visitas aos clientes pelos vendedores definida por essas zonas de vendas e distribuda aos vendedores.
As visitas ainda so organizadas semanalmente e representam perodos semanais, quinzenais e mensais.
A partir da data e do perodo de visita, o sistema encarrega-se de gerar automaticamente o roteiro
dirio que deve ser seguido pelo vendedor para cumprir sua programao de vendas.
68

Modelagem de Processos
4.9.2 Requisitos do sistema
A partir da descrio do sistema existem diversas alternativas de soluo. De qualquer maneira, os
requisitos independem de outra soluo especfica, mais simples ou mais complexa, j que eles mapeiam
as necessidades dos clientes em forma de sentenas.
A figura 38 apresenta o diagrama de requisitos do sistema a ser modelado.
Observao
Os requisitos so organizados em dois grupos ou pacotes. O pacote de
requisitos funcionais e o pacote de requisitos no funcionais:
O pacote que contm os requisitos funcionais apresentam
as caractersticas que representam o comportamento das
funcionalidades ou regras de negcio que o sistema deve apoiar.
O pacote de requisitos no funcionais contm os requisitos condicionantes
e nveis de desempenho que o sistema deve atender. Por exemplo: tempo
de resposta do sistema, transaes de segurana etc.
No nosso estudo, somente sero abordados os requisitos funcionais.
req Modelo de requisitos

Requisitos funcionais
RF01 O sistema deve manter atualizada a posio do cliente
RF02 O sistema deve elaborar o roteiro de visita do dia
RF03 Sistema emite informaes adicionais sobre os clientes
RF04 Gera informaes sobre filial
RF05 Analisa situao financeira do cliente
RF06 Anlise do histrico de vendas
RF07 Registra pedido de venda

Figura 38 Requisitos do sistema modelado na ferramenta EA

69

Unidade II
4.9.3 Modelo de classe do sistema
Aps uma anlise dos requisitos e reunies 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 cenrios e das funcionalidades, so descobertas as entidades envolvidas com o problema
e que sero usurias do sistema, e as entidades de dados que sero modeladas e colocadas no banco de
dados desse.
As principais classes obtidas com essa anlise so:
1. filial de venda;
2. zona de venda;
3. setor de venda;
4. cliente;
5. produto;
6. produto em cliente;
7. preo 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 domnio, j que no contm as classes de objetos
da soluo tecnolgica do sistema, tais como: classes de interface, classes de comunicao, classes de
padres e classes de banco de dados.
Essas classes completaro o modelo de domnio na fase de design do projeto.

70

Modelagem de Processos
class Diagrama de Classes

Cliente

Filial de venda
- numero: int
- nome: char

*
Zona de venda

- codigo: int
- nomeCompleto: char
- nomeReduzido: char
- endereco: char
- IRPJ: char
1
- telefone: char
- horarioDeVisita: int
- CondicaoDePagamento: int
- dataDaUltimaVisita: date
1

- numero: int
- nomeDoVendedor: char

- numero: int
- data: date
- situacao: int
- tipoDePedido: int

0..*

0..*

0..*
Item de pedido

0..*

Nota fiscal
- numero: int
- numero: int
- quantidade: date
- dataDeEmissao: date
- precoNegociado: int
0..* 0..* - situacao: boolean
- situacao: int
- condicaoDeEntrega: int
0..*
0..*

0..*

Setor de venda
- nome: char
- dataDaUltimaVisita: date
- periodoDeVisita: date

Pedido

Produto em cliente
- data: date
- quantidade: int
- tipo: int

0..*

0..*

Produto

Fatura

- codigo: int
- descricao: int
- faixaDePreco: int
- valorUnitario: int

- numero: int
- dataDeEmissao: date
- dataDeVencimento: date
- valor: int
- dataEfetivaPagamento: date

Figura 39 Diagrama de classes preliminar

Nesse diagrama, temos as principais classes juntamente com seus relacionamentos.

O modelo, nesse momento, ainda no sofreu quaisquer questionamentos conceituais profundos, ou
mesmo foi promovida uma normalizao visando sua estabilidade e integridade.
As operaes dessas classes so obtidas a partir do estudo das funcionalidades descritas nos modelos
de caso de uso e diagramas de sequncia das transaes necessrias, para que o sistema atenda aos
requisitos, que no sero mostrados nesse exemplo, j que se pretende apresentar somente um exemplo
de aplicao do modelo de classes.
A figura 40 apresenta o mesmo diagrama de classes, mas com as principais operaes necessrias
para resolver o sistema.

71

Unidade II
class Diagrama de Classes

Cliente
- codigo: int
- nomeCompleto: char
- nomeReduzido: char
- endereco: char
- IRPJ: char
- telefone: char
- horarioDeVisita: int
- CondicaoDePagamento: int
- dataDaUltimaVisita: date

Filial de venda
- numero: int
- nome: char

+ obte_Clientes_Ativos() : void
+ obter_Limite_Credito() : void
+ obter_Condicao_Entrega : void
+ obter_Condicao_Pagamento() : void
+ obter_dia_Entrega() : void

+ obter_Nome_Filial(): void

- numero: int
0..* - data: date
- situacao: int
- tipoDePedido: int
+ obter_Pedido() : void
+ incluir_Pedido() : void

0..*

Zona de venda
- numero: int
- nomeDoVendedor: char

Pedido

0..*

0..*

Item de pedido
- numero: int
- quantidade: date
- precoNegociado: int
- situacao: int
- condicaoDeEntrega: int

0..*

Nota fiscal
- numero: int
- dataDeEmissao: date
0..* 0..* - situacao: boolean
+ obter_NF_Cliente() : void

+ obter_Descricao_Produto() : void
+ obter_Preco_Produto() : void

Setor de venda

0..*

0..*

- nome: char
- dataDaUltimaVisita: date
- periodoDeVisita: date

0..*
0..*

+ atualizar_Data_Ultima_Visita() : void

Produto em cliente
- data: date
- quantidade: int
- tipo: int
+ registrar_Estoque_Cliente() : void
+ registrr_Produto_Recolhodo() : void

Fatura

1
Produto

- codigo: int
- descricao: int
- faixaDePreco: int
- valorUnitario: int
+ obter_Descricao_Produto() : void
+ obter_Preco_Produto() : void

- numero: int
- dataDeEmissao: date
- dataDeVencimento: date
- valor: int
- dataEfetivaPagamento: date
+ obter_Faturas_Vencidas() : void
+ obter_Faturas_A_Vencer

Figura 40 Diagrama/modelo de classes com algumas operaes

O modelo de classes, quando completo, incluindo atributos e operaes, pode ser implementado em
um banco de dados e em uma linguagem de programao orientada a objetos.
Outras classes sero necessrias, tanto para o banco de dados, como para a implementao em uma
linguagem especfica nas prximas fases do desenvolvimento.
Para a fase de design, devero ser desenvolvidos os modelos de interface homem versus mquina,
que indicar as interaes dos usurios com o sistema. Para isso devero ser montados os modelos de
casos de uso com os atores e as funcionalidades.
72

Modelagem de Processos
Por meio do modelo de caso de uso e do prottipo, os diagramas de sequncia indicaro as mensagens
que sero trocadas entre os objetos. A partir dessas mensagens, o modelo de classe ser aumentado, e
todas as operaes ou mtodos devero ser includos nas classes especficas.
Resumo
Esta unidade apresentou uma viso da estrutura da UML. Foi discutido
que, de acordo com os autores a UML, no um modelo de processo/
metodologia de software.
Ela considerada uma linguagem padro de modelagem de sistemas e,
por isso, tem uma notao e um mecanismo para mostrar o problema, de
forma a expor a essncia do domnio de um aplicativo.
Tambm 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 importncia
na tecnologia orientada a objetos.
A partir desse modelo de classes detalhado, so derivadas as solues
de banco de dados e as classes que sero implementadas em linguagens
especficas. O diagrama de classes a entrada para os processos de
arquitetura e implentao, tanto do banco de dados como do aplicativo.
Uma das mensagens mais importantes com relao 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 herana e polimorfismo que permite um avano considervel em direo
reusabilidade.
Exerccios
Questo 1. De acordo com a IBM-Rational, a Unified Modeling Language (UML) uma linguagem
de modelagem no proprietria adotada pela OMG, e no uma metodologia de desenvolvimento. Ela
no diz como desenvolver ou manter um sistema ou software, mas auxilia a visualizar seu desenho
e a comunicao entre os objetos envolvidos com o sistema. Tambm permite que desenvolvedores
vejam os produtos de seus trabalhos em diagramas ou grficos padronizados, oferecendo uma notao
grfica, especificando os significados, isto , ela uma liguagem com uma semntica predefinida.
uma notao 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 diferena entre um modelo UML e um diagrama (ou conjunto de diagramas) de UML; um diagrama
ou grfico uma representao grfica da informao de um determinado sistema, e o modelo pode
73

Unidade II
existir independentemente. Considerando-se os conceitos sobre a UML, analise as afirmaes a seguir e
assinale a alternativa incorreta:
A) A viso 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 coleo de objetos que podem ser descritos
com os mesmos atributos e as mesmas operaes. Tambm representam as entidades envolvidas
em um sistema de informao.
C) Para que um sistema seja executado, as classes de objetos precisam estar relacionadas ou
associadas no modelo de classes. Esse relacionamento ou associao deve estar de acordo com
as necessidades do sistema e deve cobrir as regras de negcio envolvidas com as funcionalidades
que o sistema executar.
D) Sistema a representao abstrata do mundo real; quanto mais complexo, mais necessita de
descries de seus vrios aspectos. Ele deve mostrar: a estrutura esttica dos objetos e a interao
dinmica entre eles; as caractersticas do tipo de tempo de processamento, de confiabilidade, de
usabilidade etc.; e, por ltimo, o mapeamento do modelo organizacional em termos da organizao
do trabalho, mapeamento e os cdigos.
E) Herana o mecanismo de reutilizao de atributos e operaes definidos em superclasses por
classes mais especficas, podendo ser usada para expressar tanto generalizao como associao.
Resposta: Alternativa A.
De acordo com a OMG, a UML apresenta 4 grandes objetivos: especificao de um sistema,
documentao de todos os artefatos produzidos no processo, estruturao para subvisualizao
e maior viso lgica do desenvolvimento completo de um sistema de informao. A UML uma
linguagem padronizada de se modelar sistemas de informao desenvolvidos na tecnologia da
Orientao a Objetos.
Anlise das alternativas
A) Incorreta. A viso de caso de uso de um sistema realmente descreve as funcionalidades ou o
comportamento de um sistema, mas tem como princpio fundamental entender os requisitos do
sistema e interpret-los graficamente. Outro fator fundamental que os Casos de Uso so como
uma linguagem de comunicao entre os usurios 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 criao de novas
instncias. Exemplo: uma classe que represente um Cliente pode ser instanciada para representar
74

Modelagem de Processos
um cliente pessoa fsica ou um cliente pessoa jurdica, os quais possuem caractersticas semelhantes
e especficas.
C) Correta. Esses relacionamentos ou associaes definem as regras que so impostas pelas regras de
negcio da aplicao sendo modelada.
D) Correta. Cada viso apresentada em um diagrama da UML descrita por um ou mais diagramas,
que contm informaes referentes a um aspecto especfico do sistema sendo modelado.
E) Correta. Quando se usa o paradigma da herana na OO, uma classe de menor nvel (subclasse)
considerada uma classe especializada ou uma classe de extenso da classe de maior nvel
(superclasse).
Questo 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 semntica
comum. As propriedades so: os atributos e as operaes. Estas so encapsuladas no objeto. Exemplo:
em um sistema ERP, o cliente e o fornecedor so classes de objetos. Cada cliente tem um nome e
um endereo; estes seriam os atributos comuns da classe cliente. Fornecedores tambm podem ter os
mesmos atributos, nomes e endereos definidos. Entretanto, elas podem no estar definidas em uma
mesma estrutura de objetos devido distino semntica. Como se pode observar, o agrupamento em
classes no leva em conta apenas o compartilhamento de propriedades, seno essas classes deveriam
ser sempre agrupadas na mesma estrutura. Considerando-se os conceitos apresentados sobre a UML
nesta unidade, examine as afirmaes a seguir e assinale a alternativa incorreta:
A) Com a hierarquia de classes de objetos que so apresentadas no diagrama de classes e com o
mecanismo de herana, o modelo de classes de objetos potencializa o reuso no desenvolvimento
de software OO.
B) Para se ter herana mltipla em um modelo de classes, necessita-se que uma subclasse herde
atributos e operaes de mais de uma superclasse.
C) Quando um modelo de classes apresenta herana mltipla e vai ser implementado em uma
linguagem de programao OO e em banco de dados, pode-se ter problemas na transio, devido
a que esses ambientes podem no suportar a herana mltipla.
D) O uso de herana mltipla 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 diferena que
tem um modificador abstract em sua definio de atributo ou de operao. Ela no pode ser
instanciada, ou seja, no possvel obter objetos. Classes abstratas podem ser herdadas por outras
classes abstratas ou concretas, e isso possibilita o polimorfismo.
Resoluo desta questo na plataforma.
75