0 - Apostila UML Completa I

Projeto de Software
usando UML

Pg.: 2
Sumrio

Captulo I : Casos de Uso .....................................................................................................3
1. Modelo de Casos de Uso ............................................................................................ 3
2. Diagramas de Casos de Uso ...................................................................................... 3
3. Exemplo ...................................................................................................................... 9
4. Concluso ................................................................................................................... 13

Captulo II : Levantamento de Classes ................................................................................15
1. Conceito de Classe e Objeto ........................................................................................ 15
2. Notao UML para Classes e Objetos .......................................................................... 20
3. Levantamento das Classes ...........................................................................................24
4. Exemplo de Levantamento de Classes ......................................................................... 26
5. Concluso ......................................................................................................................28

Capitulo III : Estudo das Interaes entre Objetos .............................................................29
1. Diagrama de Seqncia ................................................................................................29
2. Diagrama de Colaborao .............................................................................................40
3. Exemplos de Diagramas de Seqncia e Colaborao .................................................42

Captulo IV : Relacionamentos entre Classes ..................................................................... 45
1. Associao entre Classes ............................................................................................. 45
2. Agregao entre Classes ..............................................................................................48
3. Generalizao/Especializao entre Classes ............................................................... 51
4. Concluso ......................................................................................................................54

Captulo V : Especificao do Comportamento de Objetos .............................................. 55
1. Diagrama de Estados ....................................................................................................55
2. Diagrama de Atividades .................................................................................................65
3. Concluso ......................................................................................................................69

Pg.: 3

1 Modelo de Casos de Uso

O modelo de Casos de Uso foi proposto por I. Jacobson como um instrumento para
descrio das intenes ou requisitos para um sistema computacional. A construo do Modelo
de Casos de Uso corresponde a uma das fases iniciais de um projeto de software pois envolve
a determinao dos usos que o sistema ter, ou seja, do que ele dever fornecer como
servios.
O modelo de Casos de Uso diferente da viso funcional utilizada no passado nas
abordagens de projeto estrututado. Ao invs de focalizar as funes (atribuies tcnicas) do
sistema, o modelo de Casos de Uso captura os usos ou aplicaes completas do sistema. Este
modelo busca responder a questo: Que usos o sistema ter? ou Para que aplicaes o
sistema ser empregado?
Os modelos de Casos de Uso so descritos atravs de Diagramas de Casos de Uso na
UML. De uma forma geral, cada projeto de software conter um Diagrama de Casos de Uso.
Para sistemas mais extensos, possvel decompor o diagrama em um conjunto de
subdiagramas.
Uma vez construdo o modelo de Casos de Uso, o restante do projeto pode ser guiado
baseando-se neste modelo. Dito de outra forma, a partir do modelo de Casos de Uso, o
restante do projeto ir se preocupar com a forma de realizao dos casos de uso (que classes
e objetos so necessrios, como e quando cada um atuar, etc).
O modelo de Casos de Uso um instrumento eficiente para determinao e
documentao dos servios a serem desempenhados pelo sistema. Ele tambm um bom
meio para comunicao com os clientes no processo de definio dos requisitos do sistema.

2 Diagramas de Casos de Uso

Os casos de uso de um projeto de software so descritos na linguagem UML atravs de
Diagramas de Casos de Uso. Estes diagramas utilizam como primitivas Atores, Casos de Uso
e Relacionamentos. Como ocorre tambm com outros diagramas, pode-se ainda utilizar as
primitivas Pacote e Nota nos diagramas de casos de uso. As subsees a seguir descrevem
estas primitivas.

2.1 Atores

Atores so representaes de entidades externas mas que interagem com o sistema
durante sua execuo. Basicamente, a interao de atores com o sistema se d atravs de
comunicaes (troca de mensagens). As entidades externas representadas pelos atores
podem ser :
Pessoas: usurio, secretria, aluno, professor, administrador,etc.
Dispositivos: impressora, mquina ou outro equipamentos externo.
Hardwares: placa de modem, placa de controle, etc.
Software: sistema de banco de dados, aplicativos, etc.
Capt ulo I : Casos de Uso
Pg.: 4
importante observar que atores representam, na verdade, papis desempenhados por
pessoas, dispositivos ou outros softwares quando estiverem interagindo com o sistema. Por
exemplo, um ator cujo identificador seja Aluno no representa um aluno especfico mas sim um
aluno qualquer, ou seja, uma pessoa qualquer que esteja interagindo com o sistema na
qualidade de aluno. Desta forma, um ator pode representar um entre vrios indivduos,
equipamentos ou softwares. De forma anloga, uma entidade externa pode ser representada
na forma de vrios atores. Isto ocorre quando a entidade tem mais de um papel (tipo de
participao ou interao) no sistema. Por exemplo, o indivduo Joo da Silva poderia ser
representado em um sistema na forma do ator Usurio, pois ele interage com o sistema nesta
qualidade, e tambm na forma do ator Administrador, pois ele tambm interage com o sistema
para este outro fim que a administrao do software.
Atores so representados atravs de retngulos (notao genrica para classe) usando a
simbologia padro da UML ou atravs de cones humanos. As duas notaes so
sintaticamente equivalentes, porm a segunda seguramente mais intuitiva. A desvantagem
do uso de cones humanos ocorre quando o ator representa equipamentos, dispositivos de
hardware ou outros softwares. Neste caso, a figura humana no coincide com a natureza do
ator. possvel, entretanto, atravs de mecanismos de extenso, criar grafismos especiais ou
especializados na UML para indicar tipos de atores.

Usurio
Administrador
<<ator>>
Secretria Impressora

Figura I.1 Exemplos de Atores

Observe que a notao usando retngulos exige a insero de um classificador para
indicar a natureza daquilo que se est representando. No caso de atores, deve-se incluir o
classificador (ou esteretipo) <<ator>> antes do nome do ator. Quando se utiliza o cone
humano, basta indicar o nome do ator abaixo do cone.
O levantamento dos atores que interagem com um certo sistema depende de um trabalho
de estudo que envolve discusses com os clientes. Procura-se neste estudo levantar as
pessoas que sero beneficiadas e que usaro o sistema. Alm disso, deve-se levantar os
dispositivos e softwares com os quais o sistema dever se comunicar. Para muitos projetos,
pode no ser fcil levantar corretamente o conjunto de atores na primeira tentativa. O estudo
dos casos de uso e dos relacionamentos com atores pode permitir refinar o conjunto de atores
definidos. O estudo das classes do sistema, a ser feito na prxima fase, tambm ir contribuir
para o refinamento do levantamento de atores.
Embora a UML no imponha restries, costuma-se considerar determinados atores
como atores implcitos. Desta forma estes atores no aparecem no diagrama de casos de uso
embora eles estejam presentes e participem da execuo dos casos de uso. Os atores
implcitos representam essencialmente dispositivos e softwares que so sempre usados e que
no impem protocolos especiais de comunicao. Desta forma, a supresso deste atores no
traz nenhum efeito significativos sobre os modelos e simplifica as representaes. Os exemplos
mais comuns de atores que se pode considerar como impl citos so : monitor de vdeo, teclado,
mouse, auto-falante, microfone, unidade de disco e sistema operacional. Estas entidades sero
atores legtimos mas cuja incluso no modelo de casos de uso no traz contribuio para a
modelagem.

Pg.: 5

2.2 Casos de Uso

A descrio dos servios a serem oferecidos pelo sistema feita na UML discriminando-
se os Casos de Usos do sistema. Cada Caso de Uso descreve uma aplicao ou uso completo
do software. O conceito de caso de uso no deve ser confundido com o de mdulo j que um
caso de uso no um componente do sistema mas sim um de seus empregos possveis.
Tambm no se deve confundir o conceito de caso de uso com o de funo que possui um
escopo muito mais limitado, traduzindo freqentemente apenas um recurso ou utilidade do
sistema. Um caso de uso muito mais abrangente, envolvendo todo um conjunto de
transaes que juntas constituem um servio completo oferecido pelo sistema.
A especificao das funcionalidades de um sistema na forma de casos de uso permite
uma viso mais abrangente das aplicaes do sistema favorizando um levantamento mais
completo e preciso de suas atribuies.

2.3 Relacionamentos entre Atores e Casos de Uso

Os relacionamentos em um diagrama de casos de uso podem envolver dois atores, dois
casos de uso ou um ator e um caso de uso, conforme descrito nas subsees seguintes.
2.3.1 Relacionamentos entre Atores

Como os atores so entidades externas, os relacionamentos entre eles sero relaes
externas ao sistema. Embora estas relaes possam ser desprezadas, pois no fazem parte do
sistema e nem so de conhecimento do sistema, possvel inclu-las no modelo de casos de
uso. De certa forma, estas relaes descrevem parte do modelo de negcios da empresa.
As duas relaes mais comuns entre atores so a comunicao (ou associao) e a
especializao (ou generalizao). Um relacionamento de comunicao indica que os dois
atores, de forma uni ou bidirecional, realizam uma comunicao (troca de informao ou de
mensagem) que possui um significado formal para o sistema modelado. No exemplo da figura
I.2, o ator Aluno comunica-se com o ator Secretaria no sentido que transmitir uma Solicitao
de Histrico Escolar. Trata-se de uma comunicao explcita cuja ocorrncia deve ter alguma
repercusso ou significado para o sistema. Um relacionamento de generalizao, por outro
lado, representa uma relao conceitual entre atores indicando que um ator um caso especial
de outro ator mais genrico. Esta relao indica que o ator especializado inclui todos os
atributos do ator genrico e inclui ainda atributos adicionais. Como ilustra a figura I.2, o ator
Administrador um ator especializado do ator Usurio. Isto significa que o Administrador um
Usurio com atributos ou caractersticas extras. De certa forma, o ator especializado estende o
ator genrico.

Aluno Secretaria
Solicita Historico
Usurio Administrador

Figura I.2 Exemplos de Relaces entre Atores

Pg.: 6
2.3.2 Relacionamentos entre Atores e Casos de Uso

O relacionamento entre um ator e um caso de uso expressa sempre uma comunicao
entre eles, pois o ator sendo uma entidade externa no poderia possuir qualquer
relacionamento estrutural com o sistema computacional. A notao UML para este tipo de
relacionamento um segmento de reta ligando ator e caso de uso, como ilustrado na figura I.3.
Em diagramas mais complexos pode-se utilizar cadeias de segmentos de retas para se evitar
cruzamentos.
Como atores podem ter vrios propsitos, no que diz respeito a suas interaes com o
sistema, podem existir mais de um relacionamento de um ator com diferentes casos de usos.
De forma anloga, um mesmo caso de uso pode envolver a participao de mais de um ator. A
figura I.3 ilustra estas situaes. O caso de uso Emitir Histrico Escolar envolve a participao
de dois atores : Secretaria e Impressora. O ator Secretaria participa em dois casos de uso:
Emitir Histrico e Registrar Novo Aluno.

Secretaria
Registrar Novo Aluno
Emitir Histrico Escolar
Impressora

Figura I.3 Exemplos de Relaces entre Atores e Casos de Uso

A utilizao de setas nas relaes entre atores e casos de uso pode ter duas
interpretaes distintas. Na primeira, utilizam-se setas para indicar qual ator ativa o caso de
uso. Ativao neste caso significa, quem lana ou inicia a execuo do caso de uso. Para
sistemas interativos, freqentemente o ator Usurio quem ativa o caso de uso. Na situao
mais comum, cada caso de uso s teria um ator contendo uma seta em seu relacionamento de
comunicao. possvel, entretanto, haver mais de um ator ativador para um mesmo caso de
uso significando que um deles ativaria este caso de uso. O exemplo na figura I.3 aplica esta
interpretao das setas. A segunda interpretao para as setas a indicao do sentido do
fluxo de dados nas comunicaes. Neste caso todas as relaes entre atores e casos de uso
teriam setas em uma ou nas duas extremidades descrevendo o sentido da comunicao com
cada ator. As duas interpretaes so possveis mas deve-se optar por uma delas em cada
projeto e indicar explicitamente a interpretao adotada.
2.3.3 Relacionamentos entre Casos de Uso

Ao contrrio do relacionamento entre ator e caso de uso, as relaes entre casos de uso
nunca sero do tipo comunicao. Isto ocorre porque casos de uso so aplicaes completas
do sistema e, por conseqncia, no existe sentido em fazer-se comunicar dois usos do
sistema. Todas as relaes entre casos de uso sero sempre estruturais. Existem trs tipos
de relaes entre casos de uso (incluso, extenso e generalizao) conforme descritos a
seguir.

Relacionamento de Incluso

Um relacionamento de incluso uma relao estrutural atravs da qual um caso de uso
insere em seu interior um outro caso de uso. O caso de uso includo (subcaso de uso) no
Pg.: 7

representa um servio completo do sistema mas uma poro de um servio. Isoladamente, um
subcaso de uso no teria sentido. Ele ser sempre um integrante de um caso de uso maior e
completo.
O relacionamento de incluso se aplica a duas situaes principais. A primeira aplicao
da Incluso para o detalhamento de casos de uso atravs de decomposio. Nesta situao,
extraem-se partes significativas de um caso de uso criando-se subcasos de uso ligados ao
caso de uso maior atravs de relaes de incluso. Embora raro, possivel ainda decompor
subcasos de uso em outros subcasos de uso. Uma segunda aplicao do relacionamento de
incluso a de colocar em evidncia partes comuns a dois ou mais casos de uso. Nesta
situao o subcaso de uso includo por mais de um caso de uso maior. A figura I.4 ilustra
estas duas situaes.
Secretaria
Impressora
Acessar Dados
Montar Formulrio
Emitir Histrico
Escolar
Registrar Novo Aluno
Efetuar Login
inclui
inclui
inclui
inclui

Figura I.4 Exemplo de Relacionamento de Inclusao entre Casos de Uso

Relacionamento de Extenso

Um relacionamento de extenso uma relao estrututal entre dois casos de uso atravs
da qual um caso de uso maior estendido por um caso de uso menor. A extenso significa que
o caso de uso que estende inclui servios especiais em um caso de uso maior. A definio de
um relacionamento de extenso inclui a especificao de uma condio de extenso. Esta
condio habilita a extenso, ou seja, indica quando aplicar o relacionamento. A notao para
o relacionamento de extenso ilustrada na figura I.5.

Imprimir Dados de
Concluso de Curso
Secretaria
Emitir Histrico
Escolar
se Situao=Formado
<<estende>>

Figura I.5 Exemplo de Relacionamento de Extensao entre Casos de Uso

A diferena principal entre os relacionamentos de incluso e extenso o carter de
excepcionalidade da extenso. Extenses so usadas para modelar casos especiais e de
exceo que ocorrem somente em certas situaes (dado pela condio). Desta forma, para a
maioria das ocorrncias do caso de uso estendido, a extenso no se aplicar.
Pg.: 8

Relacionamento de Generalizao

Um relacionamento de generalizao uma relao estrutural entre um caso de uso mais
geral e um caso de uso mais especfico. O caso de uso mais geral representa o caso genrico
cujo servio se aplica a vrias situaes. O caso de uso mais especfico representa a aplicao
do caso uso mais geral em uma situao particular incluindo elementos adicionais ou
estendendo este caso. Visto no outro sentido, o caso de uso mais geral uma generalizao
(abstrao) do ou dos casos de uso mais especficos. Neste sentido, o caso de uso geral,
representa as partes comuns de casos de uso especializados.
A notao UML para a generalizao envolve a ligao dos dois casos de uso atravs de
um segmento de reta e a colocao de um tringulo na extremidade do caso de uso mais geral.
A figura I.6 apresenta um exemplo de relacionamento de generalizao.

Emitir Histrico
Escolar de Concluso
Secretaria
Emitir Histrico
Escolar

Figura I.6 Exemplo de Relacionamento de Generalizacao entre Casos de Uso

No exemplo da figura I.6, tem-se um caso de uso mais geral, chamado Emitir Histrico
Escolar, que permite a secretaria imprimir histricos de alunos. Quando o aluno conclui na
totalidade o curso, ele pode solicitar um histrico de concluso. Este histrico semelhante ao
histrico normal mas mais detalhado incluindo informaes adicionais. O caso de uso Emitir
Histrico Escolar de Concluso portanto semelhante ao caso de uso Emitir Histrico Escolar
mas com alguns elementos adicionais. Pode-se, como feito no exemplo, estabelecer uma
relao de especializao entre os dois casos de uso.
A relao estrutural definida por um relacionamento de generalizao implica a
incorporao (herana) dentro do caso de uso especializado de todo o servi o especificado
pelo caso de uso geral, incluindo, adaptando ou excluindo alguns servios oferecidos pelo caso
de uso geral.
O relacionamento de generalizao no pode ser confundido com os de incluso e
extenso pois a generalizao se aplica, na maior parte dos casos, a compartilhamentos de
maior dimenso. A incluso e extenso envolvem partes menores de casos de usos. A
natureza da generalizao tambm distinta pois trata-se de especificar modelos (casos de
uso) genricos aplicveis a diferentes situaes. A incluso e a extenso apenas pem em
evidncia partes de casos de uso maiores.

2.4 Decomposio de Diagramas de Casos de Uso
Um projeto de software, normalmente, conter um nico Diagrama de Casos de Uso
descrevendo o conjunto de servios oferecidos pelo sistema. Para sistemas maiores ou mais
complexos, entretanto, possvel a construo de vrios diagramas de casos de uso
elaborados a partir da decomposio de um diagrama principal.
A decomposio de um diagrama de casos de uso pode ser feita em UML utilizando o
conceito de Pacote (package). Um pacote um encapsulador que no possui uma semntica
especfica dentro dos projetos. Ele usado essencialmente para separar ou agrupar elementos
do projeto sem criar necessariamente com isso algum vnculo entre os elementos.
Utilizando pacotes pode-se criar um primeiro diagrama contendo todos os pacotes
maiores do sistema e, a seguir, tomar cada pacote e expand-lo em um novo diagrama. Pode-
Pg.: 9

se construir uma hierarquia com vrios nveis de decomposio conforme a dimenso do
sistema e o nmero de casos de uso e atores.
Os elementos (casos de uso e atores) dentro de um pacote podem ter relacionamentos
com elementos de outros pacotes. Neste caso existe uma dependncia entre pacotes. As
dependncias devem ser explicitamente definidas utilizando como notao um segmento de
reta tracejado com uma seta no sentido do pacote que depende para o pacote que contm as
dependncias. A figura I.7 ilustra a notao utilizada para pacotes e dependncias.

Casos de Uso
Administrativos
Casos de Uso
Acadmicos
Casos de Uso
Gerais

Figura I.7 Exemplo de Pacotes e Dependencias

No existe uma norma para separao dos casos de uso e atores em pacotes. Pode-se,
por exemplo, agrupar dentro de um pacote casos de uso de naturezas semelhantes (casos de
uso de cadastro, casos de uso de emisso de relatrios, etc) ou casos de uso envolvendo os
mesmos atores. De forma geral, procura-se reunir casos de uso que possuem relacionamentos
em um mesmo pacote.
Quando um ator ou caso de uso tiver que aparecer em mais de um pacote, define-se
este ator ou caso de uso em um pacote e copia-se o ator ou caso de uso nos demais pacotes.
Neste caso, deve-se indicar nos demais pacotes qual o pacote de origem daquele ator ou caso
de uso.

3 Exemplo

Para ilustrar a aplicao do conceito de caso de uso, desenvolve-se nesta seo um
exemplo de modelagem para um sistema de controle acadmico. Embora, o desenvolvimento
completo de um modelo de casos de uso possa envolver vrias iteraes de refinamento, para
fins didticos o exemplo deste seo apresentar a modelagem atravs de 4 fases.

Fase 1 : Levantamento dos Atores

O sistema de controle acadmico considerado neste exemplo ser utilizado na secretaria
de um determinado curso. No que diz respeito aos indivduos envolvidos, somente o pessoal
da secretaria ter acesso ao sistema. Entre as pessoas que atuam na secretaria e poderiam
utilizar o sistema esto o chefe da secretaria, a secretria, alguns professores e alguns
estagirios. Na verdade, apesar de se tratarem de indivduos diferentes, quando estiverem
utilizando o sistema todos assumiro o mesmo papel, ou seja, todos atuaro na forma de um
ator abstrato que pode ser denominado Secretaria.
Pg.: 10
Preliminarmente, supe-se que alguns documentos devero ser impressos pelo sistema, o
que sugere a criao de um ator denominado Impresora com o qual o sistema ir interagir para
a impresso de documentos (histrico escolar, dirio de classe, etc). O ator impressora poderia
ser considerado um ator implcito mas pode ser ilustrativo faz-lo aparecer explicitamente no
modelo.
Como o volume de informaes (alunos, professores, disciplinas, etc) pode ser grande
optou-se pelo uso de um Sistema Gerenciador de Banco de Dados para armazenamento dos
dados acadmicos. Como se trata de um sistema computacional independente com o qual o
sistema de controle acadmico ir interagir, ele deve ser considerado tambm como um ator.
Neste exemplo, este ator ser denominado SGBD.
Portanto, os atores que foram inicialmente levantados so:

Secretaria Impressora SGBD

Figura I.8 Atores do sistema de controle academico.

Na prtica, nem sempre possvel determinar todos os atores e defin-los corretamente na
primeira tentativa. Se for considerada uma abordagem de projeto por refinamentos sucessivos,
a lista de atores poderia ser melhorada, assim como a definio deste atores, a medida que o
projeto avance quando mais informaes estiverem disponveis.

Fase 2 : Levantamento dos Casos de Uso Principais

Nesta fase busca-se definir a lista dos grandes servios que o sistema dever oferecer. O
levantamento dos casos de uso corresponde a uma anlise de requisitos e deve ser
desenvolvido a partir de informaes coletadas dos clientes. Atravs de questionrios e
reunies com os clientes procura-se definir quais so as aplicaes ou usos desejados para o
sistema a ser desenvolvido.
Para o sistema de controle acadmico considera-se que os clientes (usurios, professores
e administrao da escola) desejam que o sistema oferea os seguintes servios :
possibilidade de cadastramento de todos os alunos matriculados no curso. Isto implica
um servio para incluso de novos alunos e para manuteno da base de dados dos
alunos. Este uso do sistema ser representado pelo caso de uso Cadastrar Aluno.
possibilidade de cadastramento de todos os professores que ministram disciplinas no
curso. Isto implica um servio para incluso de novos professores e para manuteno
da base de dados de professores. Este uso do sistema ser representado pelo caso de
uso Cadastrar Professor.
possibilidade de registro das disciplinas oferecidas no curso incluindo o registro de
novas disciplinas e a manuteno da base de dados de disciplinas. Este servio ou uso
do sistema ser representado pelo caso de uso Cadastrar Disciplina.
possibilidade de registro da matrcula de alunos em disciplinas a cada semestre. Este
servio ser representado pelo caso de uso Registrar Matrcula.
possibilidade de emisso da confirmao de matrcula para cada aluno contendo a lista
de disciplinas nas quais um aluno se matriculou para aquele semestre. Este servio
ser representado pelo caso de uso Emitir Confirmao de Matrcula.

Pg.: 11

possibilidade de emisso do dirio de classe para cada disciplina contendo a lista de
alunos matriculados naquele semestre. Este servio ser representado pelo caso de
uso Emitir Dirio de Classe.
possibilidade de lanamento das notas obtidas pelos alunos em cada disciplina ao final
de cada semestre. Este servio ser representado pelo caso de uso Registrar Nota.
possibilidade de emisso do histrico escolar para cada aluno contendo a lista de
disciplinas cursadas e respectivas notas. Este servio ser representado pelo caso de
uso Emitir Histrico Escolar.
O conjunto de casos de uso levantados representa os servios ou usos esperado pelos
clientes que utilizaro o sistema. Assim como para os atores, nem sempre possvel efetuar
um levantamento completo e definitivo dos casos de uso em uma primeira tentativa. Ao longo
do processo de refinamento, novos casos de uso poderiam aparecer ou outros sofrerem
alteraes.
A figura I.9 ilustra os casos de uso definidos para o sistema acadmico.

Cadastrar Aluno Cadastrar Professor Cadastrar Disciplina Registrar Matrcula
Emitir Confirmao
de Matrcula
Emitir Dirio
de Classe
Registrar Nota Emitir Histrico Escolar

Figura I.9 Casos de Uso do sistema de controle academico.

Fase 3 : Definio dos Relacionamentos

Nesta fase so estabelecidos os relacionamentos de comunicao entre os atores e os
casos de uso indicando quais atores participam (se comunicam) com quais casos de uso. Para
o exemplo em estudo, o resultado seria aquele apresentado na figura I.10. Neste diagrama de
casos de uso, adotou-se o uso de setas nas relaes para indicar qual ator responsvel pela
ativao dos casos de uso.

Fase 4 : Detalhamento dos Casos de Uso

Nesta fase feito um detalhamento dos casos de uso atravs de decomposies ou
especializaces. O grau de detalhamento necessrio um aspecto subjetivo. Cabe ao
projetista julgar qual o bom nvel de detalhamento para cada projeto. No se deve exagerar nas
decomposies sob o risco de se estar influenciando ou direcionando o processo de projeto.
Deve-se lembrar que os diagramas de casos de uso so especificaes do que o sistema deve
fazer e no de como ele dever realizar os servios.

Como abordagem geral para esta fase existem as seguintes sugestes:

Procure estimar a dimenso de cada caso de uso. Para casos de uso muito extensos,
crie subcasos de uso que identifiquem partes do processo envolvido naquele caso de
Pg.: 12
uso. Relacione os subcasos de uso com caso de uso maior atravs de relaes de
incluso.

Para o sistema de controle acadmico, considerou-se que os trs casos de uso para
cadastramento (aluno, professores e disciplinas) tm uma dimenso maior e incluem
servios internos (incluso, consulta, alterao e excluso) que podem ser destacados.
Assim, optou-se por decompor cada um destes casos de uso em quatro subcasos de
uso.

Compare par a par os casos de uso tentando identificar partes comuns nos servi os
associados a cada caso de uso. Quando dois ou mais casos de uso possuem parte em
comum de dimenso significativa, esta parte em comum pode ser colocada em
evidncia atravs de um subcaso de uso.

Para o sistema de controle acadmico, foi decidido que o usurio dever se identificar
atravs de nome e senha para ter acesso aos servios de cadastramento e registro de
matrcula e notas. Assim, todos os casos de uso associados teriam uma fase inicial
idntica em seus processos que corresponderia a realizao de login. Esta parte
comum pode ser indicada atravs de um subcaso de uso comum.

Quando dois ou mais casos de uso tiverem grande parte de seus servios semelhante,
verifique a possibilidade de definio de um caso de uso geral que cubra a parte
comum deste casos de uso. Especifique, ento, um relacionamento de generalizao
entre o caso de uso geral e os casos de uso especializados.

Secretaria
Cadastrar Aluno
Cadastrar Professor
Cadastrar Disciplina
Registrar Matrcula
Registrar Nota
SGBD
Emitir Confirmao
de Matrcula
Emitir Dirio de Classe
Impressora

Figura I.10 Relacionamentos entre Atores e Casos de Uso.

Pg.: 13

A figura I.11 apresenta o diagrama de casos de uso final para o sistema de controle
acadmico. Na verdade, este diagrama poderia ser melhorado e detalhado a partir das
primeiras iteraes do projeto. medida que o projeto avance e a forma de realizao dos
casos de uso seja definida, pode-se verificar a necessidade de alterao ou adaptao do
diagrama de casos de uso.

Cadastrar Aluno
Cadastrar Professor
Cadastrar Disciplina
Registrar Matrcula
Incluir Aluno
Alterar Aluno Excluir Aluno
Incluir Professor Excluir Professor Alterar Professor
Incluir Disciplina
Excluir DisciplinaAlterar Disciplina
Secretaria
SGBD
Registrar Nota
Emitir Confirmao
de Matrcula
Impressora
Realizar Login
<<inclui>>
<<inclui>>
<<inclui>>
<<inclui>>
<<inclui>>
<<inclui>>

Figura I.10 Diagrama de casos de uso final para o sistema de controle academico.

4 Concluso

O modelo de casos de uso uma ferramenta til na descrio dos requisitos funcionais de um
sistema computacional. Ele permite especificar o conjunto de funcionalidades ou servios que
um software deve oferecer e as relaes do sistema com entidades externa (atores)
necessrias para a realizao destes servios.

A notao UML para diagramas de casos de uso em grande parte intuitiva permitindo que os
modelos gerados possam ser apresentados aos clientes para discusses e revises.
Pg.: 14
Deve-se sempre observar que o modelo de casos de uso diferente da viso funcional no
sentido que ele no apresenta encadeamentos de funes (por conseqncia, no descreve
processos) e se limita a uma viso macroscpica dos servios do sistema sem induzir a forma
de realizao (projeto) do software. O modelo de casos de uso oferece uma viso mais
abstrata das funcionalidades do sistema favorizando um trabalho de especificao mais
abrangente.

Por fim, o modelo de casos de uso pode tambm ser til como ferramenta para planejamento
do desenvolvimento de sistemas computacionais (estimativas por caso de uso) e como base
para o desenvolvimento de projetos de software (projeto baseado em casos de uso).

Prof. Paulo Czar Stadzisz Crditos:
Pg.: 15

1 Conceito de Classe e Objeto

As classes e objetos so as principais primitivas ou elementos de composio de softwares
orientados a objetos. Na verdade, um sistema orientado a objetos composto por classes e
por um conjunto de objetos que colaboram ou interagem para execuo dos servios (casos de
uso) oferecidos pelo sistema. As sees seguintes apresentam resumidamente os conceitos de
objeto e de classe.

1.1 Objetos

Um objeto pode ser visto ou entendido segundo uma viso conceitual e segundo uma viso de
implementao. Estas duas vises no so antagnicas, na realidade, elas se complementam
apresentando duas formas de interpretao dos objetos.

Viso conceitual

A viso conceitual uma forma mais abstrata de se observar um objeto. Nesta viso um objeto
um elemento componente de um sistema computacional que representa, dentro do sistema,
alguma entidade ou coisa do mundo real ou que define uma poro do sistema com limites e
atribuies bem definidos.

Uma das intenes da orientao a objetos tentar aproximar as representaes internas de
um sistema computacional da forma como as entidades existem e se relacionam no mundo
real, sejam elas materiais ou abstratas. Considerando-se um sistema de controle acadmico,
por exemplo, existem no sistema de controle acadmico no mundo real entidades materiais
(secretria, professores, alunos, dirios de classe, etc) e entidades abstratas (disciplina, notas,
freqncia, etc) envolvidas. Quando se desenvolve um sistema orientado a objetos procura-se
criar no interior do software representaes das entidades externas na forma de objetos.
Assim, poderiam ser criados objetos como aluno, dirio de classe e disciplina para
representarem entidades externas dentro do sistema. A inteno desta aproximao entre
entidades externas e representao interna facilitar a interpretao da estrutura do sistema
computacional e agrupar informaes que juntas tm um significado comum.

Objetos no representam apenas informaes em um sistema computacional. Eles podem
tambm representar, e implementar, processos (ou seja, algoritmos ou procedimentos).
Considerando novamente o sistema de controle acadmico, o trabalho manual de composio
de um dirio de classe poderia ser representado no sistema computacional por um objeto
responsvel por este processamento.

Alm das responsabilidades individuais, as entidades no mundo real praticamente sempre se
relacionam de forma a juntas cooperarem para a execuo de tarefas. Por exemplo, os dados
dos alunos (entidades) so utilizados pela secretaria (entidade) para compor (processo) o
dirio de classe (entidade) para uma disciplina (entidade). De forma anloga, os objetos que
representam estas entidades iro se relacionar para juntos cooperarem na execuo de
servios (casos de uso). Um exemplo de relacionamento a comunicao, atravs da qual um
objeto pode trocar informaes ou comandar outro objeto.
Capt ulo I I : Lev ant ament o de Cl asses
Pg.: 16
Um objeto possui trs caractersticas :
Identidade : cada objeto possui um nome ou identificador que o distingue dos demais
objetos e que permite que os outros objetos o reconheam e o enderecem.
Atributos : cada objeto pode possuir informaes que so registradas na forma de um
conjunto de atributos.
Comportamento : cada objeto pode possuir um conjunto de habilidades de
processamento que juntas descrevem seu comportamento.

Como exemplo considere um objeto que represente uma disciplina de matemtica. A
identidade deste objeto poderia ser Clculo Numrico. Seus atributos poderiam ser Carga
Horria, Pr-requisitos, Ementa, Alunos Matriculados e Notas. Seu comportamento
poderia incluir a capacidade de Calcular a Mdia da Turma, Inscrever um Novo Aluno e
Registrar Notas dos Alunos.

Viso de Implementao

Em termos de implementao, um objeto pode ser entendido como um pequeno mdulo de
software. Neste sentido, um objeto pode ser executado como qualquer mdulo de software,
pode receber dados de entrada e pode produzir resultados. Na orientao a objetos, procura-
se construir estes mdulos de software (objetos) de forma que eles tenham um alto grau de
modularidade (pequena dependncia entre um mdulo e outro) e que cada mdulo possua
atribuies ou responsabilidades prprias que o caracterize.

Enquanto nas linguagens de programao procedurais como Pascal e C, os programas so
construdos como conjuntos de funes ou procedimentos e variveis, nas linguagens
orientadas a objetos os programas so construdos pensando-se em agrupamentos de funes
e variveis formando objetos. Pode-se considerar que na orientao a objetos foi introduzido
um novo nvel de estruturao nos programas conforme discutido na prxima seo.

Em termos de implementao, um objeto pode interagir com outros objetos. Por exemplo, um
objeto poderia se comunicar com outro. Esta comunicao, como ser vista em detalhes na
seo 3, poderia ser realizada atravs de chamada de funo ou procedimento do objeto para
algum outro ou atravs de um mecanismo de envio de mensagem suportado pela maioria dos
sistema operacionais. Desta forma, a execuo de um software orientado a objetos seria feita
atravs da execuo em cadeia ou em concorrncia do conjunto de seus objetos que
permanentemente estariam se comunicando para trocar informaes ou comandar a execuo
de funes. Pode-se dizer, ento, que a execuo de um software orientado a objetos se d
pela colaborao de um conjunto de objetos.

As trs caractersticas de um objeto (identidade, atributos e comportamento) se traduzem da
seguinte forma na implementao :

A identidade do objeto ser determinada por um nome ou identificador inventado pelo
programador para cada objeto. Por exemplo, um objeto que representa uma disciplina de
matemtica poderia ser nomeado objMatematica. Qualquer nome pode ser utilizado,
desde que se respeite as normas para criao de identificadores da linguagem de
programao utilizada.
Os atributos de um objeto so traduzidos na forma de variveis internas do objeto. Pode-se
definir variveis de qualquer tipo para composio dos atributos dos objetos. Por exemplo,
um objeto representando um aluno poderia ter os atributos nome (texto com 30
caracteres), sexo (um caracter, M ou F), coeficiente de rendimento (valor real), entre
Pg.: 17

outros. No se deve confundir aqui atributo com valor do atributo. Neste exemplo, nome
um atributo cujo valor pode ser Marcia ou Carlos.
O comportamento do objeto descrito por uma ou mais funes ou procedimentos. Estas
funes descrevem os procedimentos ou habilidades do objeto. Por exemplo, o objeto
objMatematica poderia ter uma funo para clculo da mdia das notas dos alunos
matriculados.

1.2 Classes

As classes so elementos fundamentais na composio de softwares orientados a objetos.
Elas so empregadas tanto na composio do projeto dos sistemas computacionais quanto em
sua implementao. Entretanto, ao contrrio dos objetos, as classes no se traduzem em
elementos executores no cdigo de implementao. O entendimento do conceito de classe
pode ser feito tambm segundo um ponto de vista conceitual e um ponto de vista de
implementao.

Viso conceitual

Em um ponto de vista conceitual, as classes podem ser entendidas como descries genricas
ou coletivas de entidades do mundo real. Mantm-se aqui a inteno de aproximar entidades
externas de representaes internas. Desta forma, a definio das classes de um sistema
dever procurar inspirao nas entidades do mundo real.

Ao contrrio dos objetos, que representam entidades individualizadas, as classes so
representaes genricas. Elas so abstraes de um coletivo de entidades do mundo real.
Isto significa que elas representam um modelo comum para um conjunto de entidades
semelhantes. Imaginando, por exemplo, os alunos envolvidos em um sistema acadmico, cada
aluno (Marcia, Vinicius, Cludia, etc) uma entidade individualizada que poderia ser
representada por um objeto. Observando-se estes objetos e comparando-os, pode-se constatar
que o conjunto de seus atributos (nome, sexo, idade) e seus comportamentos so anlogos,
embora obviamente os valores dos atributos sejam diferentes.

A partir da observao de atributos e comportamento comum a um conjunto de entidades
similares, possvel estabelecer um modelo genrico para este coletivo de entidades. Este
modelo conteria os atributos e comportamento comuns a este coletivo. Desta forma, seria
possvel definir um modelo genrico para todos os alunos no exemplo anterior. Este modelo
genrico , em conseqncia, uma abstrao dos alunos que denomina-se Classe na
orientao a objetos.

Considera-se uma classe um modelo genrico porque ela estabelece um formato padro para
a representao, na forma de objetos, de todas as entidades externas associadas. A definio
das classes de um sistema passa necessariamente pela observao das entidades externas
buscando-se determinar coletivos de entidades semelhantes que possam ser abstradas em
uma representao genrica.

Viso de Implementao

A implementao de classes se faz atravs da criao de tipos, de maneira semelhante aos
tipos de dados. As linguagens de programao, de uma forma geral, oferecem um conjunto de
tipos de dados padres, como inteiro, real, caracter, booleano e cadeia de caracteres, e
permitem que o programador crie novos tipos como enumeraes, estruturas, unies e
registros. A partir de um tipo de dado possvel, ento, criar-se instncias que so as variveis
dos programas. A figura II.1 mostra exemplos de variveis criadas a partir de vrios tipos de
dados da linguagem C e a definio de um novo tipo chamado Aluno.
Pg.: 18

/* definicao de um novo tipo de dado */
struct Aluno {
int codigo;
char nome[30];
float coeficiente;
char sexo;
};

/* definicao de variveis */
int valor;
float resultado;
char texto[10];
Aluno al;

Figura II.1 Exemplo de definio de variveis na linguagem C.

Embora possam conter mais do que apenas variveis, as classes so tambm tipos e, por
conseqncia, no so por elas prprias elementos executveis ou que possam armazenar
dados dentro de um programa. As classes, assim como os tipos de dados, so modelos para a
criao de variveis. Desta forma, a partir da criao de uma classe possvel criar instncias
ou variveis desta classe. As variveis criadas a partir de uma classe so denominadas
objetos. Isto coincide com a viso conceitual vista anteriormente onde definiu-se que classes
eram modelos para objetos semelhantes. Em termos de implementao, uma classe , de fato,
um modelo (ou tipo) usado para criao de objetos.

Na orientao a objetos, impe-se que todo objeto seja criado a partir de uma classe. Assim, a
declarao das classes de um sistema deve ocorrer antes da definio dos objetos. A figura
II.2 apresenta um trecho de programa na linguagem C++, ilustrando a declarao de uma
classe (CAluno) e a definio de dois objetos (al e estudante) desta classe. Observe que a
classe CAluno possui quatro atributos (nome, coeficiente, sexo e codigo) e uma funo
(definir). Na sintaxe da linguagem C++, a definio do corpo das funes feita fora da
declarao da classe. Desta forma, a funo definir aparece declarada dentro da classe mas
sua definio completa s aparece a seguir. Aps a declarao da classe, objetos podem ser
criados livremente, como o caso dos objetos al e estudante.

/* definicao de uma classe */
class CAluno {
char nome[30];
float coeficiente;
char sexo;
public:
int codigo;
void definir(char *n, float c, char s, int i);
};

void Caluno::definir(char *n, float c, char s, int cod)
{
strcpy(nome, n);
coeficiente = c;
sexo = s;
codigo = cod;
}
/* definicao de objetos */
CAluno al;
CAluno estudante;
Figura II.2 Exemplo de definio de uma classe e de objetos na linguagem C++.
Pg.: 19

Em termos de implementao pode-se considerar que a orientao a objetos introduziu um
nvel adicional de estruturao nos programas. Na programao procedural os programas so
organizados essencialmente em trs nveis de estruturao: instrues, funes (ou
procedimentos) e arquivos. Assim, o cdigo fonte de uma programa distribudo primeiramente
em arquivos (.c, .h, .pas, etc), que por sua vez contm conjuntos de funes, que finalmente
so descritas por um conjunto de instrues, conforme ilustrado na figura II.3. Na orientao a
objetos os programas so organizados em arquivos, que contm classes, que incluem funes
que so descritas por conjuntos de instrues, conforme ilustra a figura II.4.

Programa em C
/*Declaraes Globais */
#include stdio.h
int valor;
/* Definio de Funo */
int Calcular(int v1, int v2)
{
return(v1+v2);
}
void Mostrar(int val)
{
printf(Valor=%d\n, val);
}
#include stdio.h
int res;
int Verificar(int senha)
{ int res;
return(res);
}
void main(l)
{ res=Calcular(10+20);
Mostrar(res);
}
Arquivo : p1.c Arquivo : p2.c
...

Figura II.3 Exemplo de estruturao de um programa em linguagem C.

Programa em C++
#include stdio.h
int valor;
#include stdio.h
int res;
Arquivo : p1.c
Class CValor {

};
Arquivo : p2.c
...
int Calcular(int v1, int v2)
{
return(v1+v2);
}
void Mostrar(int val)
{
printf(Valor=%d\n, val);
}
Class CVerificador {

};
int Verificar(int senha)
{ int res;
return(res);
}
void main(l)
{ Cvalor obValor;
res=obValor.Calcular(10+20);
obValor.Mostrar(res);
}

Figura II.4 Exemplo de estruturao de um programa em linguagem C++.
Pg.: 20

2 Notao UML para Classes e Objetos

2.1 Notao para Classes

A notao para classes em UML um retngulo com trs compartimentos conforme ilustrado
na figura II.5. Quando no se desejar mostrar detalhes da classe em um certo diagrama, pode-
se suprimir a apresentao dos atributos e mtodos, conforme ilustrado na classe da direita na
figura II.5.

Identificao da Classe
Atributos
Mtodos
<<interface>>
CJanela
De PacoteCadastro
Atributos
Mtodos
<<interface>>
CJanela
De PacoteCadastro

Figura II.5 Notao UML para classes.

2.1.1 Compartimento de Identificao

O compartimento superior utilizado para identificao da classe. Nele dever aparecer,
necessariamente, o nome da classe e, opcionalmente, um esteretipo e um identificador de
pacote. O nome da classe uma cadeia de caracteres que identifica exclusivamente esta
classe dentro do sistema. Como sugesto, o nome da classe deveria utilizar apenas letras e
palavras concatenadas mantendo-se a primeira letra de cada palavra em maiscula. Muitos
projetistas e programadores utilizam tambm a letra C (de classe) como prefixo para todos os
nomes de classes.

Exemplos de nomes de classes :
CAluno
CturmaEspecial
CJanelaDeInterfaceComUsuario

Um esteretipo pode ser includo no compartimento de identificao de uma classe conforme
ilustrado na figura II.5. Esteretipos so classificadores utilizados para indicar, neste caso, tipos
de classes. Pode-se, por exemplo, criar classes do tipo interface ou do tipo controle. Para
indicar o tipo de uma classe atravs de um esteretipo inclui-se o tipo da classe entre os sinais
<< >> acima de seu nome. No exemplo da figura II.5, a classe Cjanela foi definida como sendo
do tipo <<interface>>.

Por fim, o compartimento de identificao pode incluir tambm o encapsulamento da classe, ou
seja, o pacote dentro do qual a classe est declarada. O conceito de pacote o mesmo que
aquele discutido no captulo 2.4. A especificao do pacote includa abaixo do nome da
classe e escrita em itlico na forma de nome-do-pacote.

Pg.: 21

2.1.2 Compartimento de Definio de Atributos

Neste segundo compartimento so definidos todos os atributos da classe. Atributos so
variveis membro da classe que podem ser usadas por todos os seus mtodos tanto para
acesso quanto para escrita. Em linguagem de programao, os atributos da classe so
definidos a partir dos tipos padres da linguagem e de tipos definidos pelo programador. Na
UML tem-se uma notao similar a das linguagens de programao.

Notao para definio de atributos :

[Visibilidade] Nome-Atributo [Multiplicidade]:[Tipo]=[Valor] [{Propriedades}]

Visibilidade
A visibilidade indica se o atributo pode ou no ser acessado do exterior da classe por
funes que no sejam membro da classe. Existem trs especificadores de visibilidade :
+ : indica visibilidade pblica. Neste caso o atributo visvel no exterior da classe.
Tanto funes membro da classe quanto funes externas podem acessar o
atributo.
: indica visibilidade privada. Neste caso o atributo no visvel no exterior da
classe. Somente funes membro da classe podem acessar o atributo.
# : indica visibilidade protegida. Neste caso o atributo tambm privado mas
funes membro de classes derivadas tambm tm acesso ao atributo.
A definio da visibilidade do atributo opcional. Entretanto, se ela no for especificada,
assume-se por padro visibilidade privada.

Nome-do-Atributo

O nome do atributo definido por uma cadeia de caracteres que identificam
exclusivamente o atributo dentro da classe. Sugere-se o emprego unicamente de letras
comeando-se por uma letra minscula e concatenando-se palavras mantendo a primeira letra
em maisculo.

Exemplo : valorDoPagamento
nomeDoAluno

Alguns autores utilizam o prefixo m_ (de minha) para todos os nomes de atributos.

Exemplo : m_valorDoPagamento
m_nome_doAluno

Multiplicidade

A multiplicidade uma especificao opcional na definio de um atributo. Na verdade, a
multiplicidade utilizada somente quando se tratar de atributo mltiplo ou seja vetores e
matrizes. A multiplicidade indica portanto a dimenso de atributos e descrita entre
colchete.

Exemplo: valores[5] vetor de 5 valores
matrizDeValores[10,20] matriz de 10 linhas e 20 colunas

Pg.: 22
Tipo

O tipo de um atributo um classificador que indica o formato (classe ou tipo de dado) dos
valores que o atributo pode armazenar. Pode-se, aqui, utilizar os tipos padres da linguagem
de programao que se pretende usar.

Exemplo: resultado: int
salario: float
sexo : char

Valor Inicial

O valor inicial indica o valor ou contedo do atributo imediatamente aps a sua criao.
Deve-se observar que algumas linguagens de programao (como C++) no suportam
esta atribuio inicial.

Exemplo: resultado: int = 10

Propriedades

As propriedades podem ser utilizadas para incluir comentrios ou outras indicaes sobre
o atributo como por exemplo se o seu valor constante. As propriedades so indicadas
entre chaves.

Exemplo :
<<entidade>>
CAluno
De PacoteCadastro
- nome[30] : char
- coeficiente : float
- sexo : char
+ codigo : int
Mtodos

Figura II.6 Exemplo de definio de atributos de uma classe
2.1.3 Compartimento de Definio de Mtodos

Neste compartimento so declarados os mtodos (ou seja, as funes) que a classe possui. A
sintaxe da declarao pode seguir aquela da linguagem de programao que se pretende
utilizar na implementao do sistema.

Notao para definio de atributos :

[Visibilidade] Nome-Mtodo (Parmetros):[Valor-de-Retorno] [{Propriedades}]

Visibilidade

A visibilidade indica se o mtodo pode ou no ser chamado do exterior da classe por
funes que no sejam membro da classe. Existem trs especificadores de visibilidade:
Pg.: 23

+ indica visibilidade pblica. Neste caso o mtodo visvel no exterior da classe.
Tanto funes membro da classe quanto funes externas podem acessar ao
mtodo.
indica visibilidade privada. Neste caso o mtodo no visvel no exterior da
classe. Somente funes membro da classe podem acessar ao mtodo.
# indica visibilidade protegida. Neste caso o mtodo tambm privado mas
funes membro de classes derivadas tambm tm acesso ao mtodo.
A definio da visibilidade do mtodo opcional. Entretanto, se ela no for especificada,
assume-se por padro visibilidade privada.

Nome-do-Mtodo

O nome do mtodo definido por uma cadeia de caracteres que identificam
exclusivamente o mtodo dentro da classe. Sugere-se o emprego unicamente de letras
comeando-se por uma letra maiscula e concatenando-se palavras mantendo a primeira letra
em maisculo.

Exemplo: CalcularValor
ArmazenarDados

Parmetros

Os parmetros so variveis definidas junto aos mtodos e que so utilizadas pelos
mtodos para recebimento de valores no momento da ativao. Os parmetros podem tambm
ser utilizados para retorno de valores aps a execuo do mtodo. Cada parmetro
especificado usando a notao :

Nome-do-Parmetro:Tipo=Valor-Padro

O Nome-do-Parmetro uma cadeia de caracteres que identifica o parmetro dentro do
mtodo. Tipo um especificador de tipo de dado padro da linguagem de programao. Valor-
Padro a especificao de uma constante cujo valor ser atribudo ao parmetro se em uma
chamada ao mtodo no for especificado um valor para o parmetro.

Exemplo: CalcularValor( val1:int, val2:float=10.0)
ArmazenarDados( nome:char[30], salario:float=0.0)

Valor-de-Retorno

O Valor-de-Retorno indica se o mtodo retorna algum valor ao trmino de sua execuo
e qual o tipo de dado do valor retornado. Pode-se utilizar aqui os tipos padres da linguagem
de programao que se pretende utilizar ou novos tipos definidos no projeto (inclusive classes).

Exemplo: CalcularValor():int // retorna um valor inteiro
ArmazenarDados(nome:char[30]): bool // retorna verdadeiro ou falso

2.2 Notao para Objetos

A notao UML para um objeto um retngulo com a identificao do objeto em seu interior. A
figura II.7 ilustra objetos representados na UML. A identificao do objeto composta pelo
nome do objeto, seguida de dois-pontos (:) e a indicao da classe do objeto. Esta
indentificao deve ser sublinhada. Na verdade, o nome do objeto opcional. Quando o nome
Pg.: 24
no for indicado, entende-se que se est fazendo referncia a um objeto qualquer de
determinada classe.

Figura II.7 Exemplo da notao UML para objetos

3 Levantamento das Classes

Uma vez identificados os Atores e Casos de Uso do sistema, pode-se iniciar efetivamente o
projeto do software. Do ponto de vista estrutural o projeto deve definir os componentes do
sistema e as relaes necessrias entre eles. Em um sistema orientado a objetos, os
componentes estruturais do sistema so as classes.

A definio das classes necessrias para a realizao de todas as funcionalidades do sistema
envolve um processo de sntese, ou seja, de criao. No existe um algoritmo ou tcnica
precisa para o estabelecimento de classes. Cabe ao projetista, baseado em sua experincia e
criatividade determinar quais classes iro compor o sistema. A definio das classes exige um
estudo detalhado dos requisitos do sistema e das possibilidades de separao dos dados e
processos em classes.

Existem trs tcnicas bsicas para enfrentar a dificuldade de definio de classes: (i) definir as
classes por partes, (ii) proceder por refinamentos e (iii) utilizar esteretipos.

3.1 Definio das Classes por Caso de Uso

A definio de classes por partes significaria, em uma abordagem estruturada, estudar as
classes dividindo-se o sistema em mdulos ou subsistema. Na orientao a objetos, e em
particular na UML, sugere-se que o levantamento das classes do sistema seja feita por caso de
uso. Desta forma, tomaria-se isoladamente cada caso de uso para definio das classes
necessrias a sua implementao.

Nesta abordagem, no se deve considerar os casos de uso como subsistemas. Embora, o
levantamento das classes seja feito por caso de uso, elas no so exclusivas de certos casos
de uso. Uma mesma classe pode ser empregada em mais de um caso de uso com o mesmo
ou com papis diferentes.

3.2 Definio das Classes por Refinamentos

Para sistemas maiores ou mais complexos, pode ser muito difcil fazer um levantamento
completo das classes em uma primeira tentativa. Pode-se, ento, empregar uma tcnica por
refinamentos na qual define-se, inicialmente, grandes classes (tambm chamadas classes de
anlise) e em refinamentos seguintes retorna-se para decompor estas classes em classes mais
detalhadas e menores. Segue-se, nesta viso, uma abordagem top-down partindo-se de
classes mais abstratas em direo a classes mais refinadas ou detalhadas.

3.3 Esteretipos para Classes

possvel utilizar o conceito de esteretipo para auxiliar no levantamento de classes. A UML
define trs esteretipos padres para classes de anlise :

Estudante:CAluno JanEntrada:CJanela :CJanela

Pg.: 25

entidade : identifica classes cujo papel principal armazenar dados que juntos possuem
uma identidade. Este tipo de classe freqentemente representa entidades do
mundo real como aluno, professor, disciplina, etc.
controle : identifica classes cujo papel controlar a execuo de processos. Estas classes
contm, normalmente, o fluxo de execuo de todo ou de parte de casos de uso e
comandam outras classes na execuo de procedimentos.
fronteira : identifica classes cujo papel realizar o interfaceamento com entidades externa
(atores). Este tipo de classe contm o protocolo necessrio para comunicao
com atores como impressora, monitor, teclado, disco, porta serial, modem, etc.

Existem algumas regras gerais que, se utilizadas, podem auxiliar no levantamento das classes
necessrias para cada caso de uso e permitir uma boa distribuio de papis entre as classes.

Regras para definio de classes para um caso de uso:

Definir uma classe do tipo fronteira para cada ator que participe do caso de uso
Considerando que atores so entidades externas, necessrio que o sistema
comunique-se com eles utilizando protocolos especficos. Cada ator pode exigir um protocolo
prprio para comunicao. Desta forma, um bom procedimento criar uma classe especfica
para tratar a comunicao com cada ator. Assim, seriam definidas, por exemplo, uma classe
para interface com o usurio, uma classe para interface com a impressora, uma classe para
interface com a porta serial, etc.

Definir pelo menos uma classe do tipo controle para cada caso de uso
Cada caso de uso implica um encadeamento de aes a serem realizadas pelo sistema.
O algoritmo ou conhecimento do processo a ser realizado dever estar definido em alguma
parte do sistema. Este conhecimento pode estar distribudo em vrios componentes do
sistema, ou centralizado em um ou poucos componentes. A vantagem de centralizar o
processo em um ou poucos componentes a maior facilidade de entendimento do processo e
sua modificao futura. Neste sentido pode-se criar uma classe de controle para cada caso de
uso de forma que ela contenha a descrio e comando do processo associado ao caso de uso.

Definir classes de controle auxiliares
Em certos casos de uso o processo nas classes de controle pode ser longo ou conter
subprocessos. Nestes casos, pode-se extrair partes do processo da classe de controle principal
e atribu-los a classes de controle auxiliares. Assim, o fluxo principal do processo ficaria sob a
responsabilidade da classe de controle principal e os subprocessos seriam controlados ou
executados pelas classes de controle auxiliares.

Definir uma classe do tipo entidade para cada grupo de dados
Grupos de dados que junto definem entidades abstratas ou do mundo real deveriam ser
representados por classes. Sugere-se, portanto, que para cada caso de uso faa-se uma
anlise dos dados manipulados e identifique-se grupos que sero representados, cada um, por
uma classe. Trata-se aqui de identificar dados que so manipulados no caso de uso e que, por
conseqncia, devem estar em memria. Grupos de dados armazenados em arquivos ou
bancos de dados no precisam possuir classes que os representem na totalidade. As classes
do tipo entidade esto associadas unicamente a dados em memria.

Pg.: 26
4 Exemplo de Levantamento de Classes

Nesta seo ser considerado o sistema de controle acadmico, discutido no captulo IV, para
ilustrar o processo de levantamento de classes. Ser feito o levantamento para dois dos casos
de uso daquele sistema: Cadastrar Aluno e Emitir Dirio de Classe.

4.1 Classes para o Caso de Uso Cadastrar Aluno

Conforme ilustrado na figura II.8, a realizao do caso de uso Cadastrar Aluno envolve a
comunicao com dois atores : Secretaria e SGBD. Desta forma, pode-se identificar duas
classes do tipo fronteira para implementar o interfaceamento com estes dois atores. Estas duas
classes poderiam se chamar : CInterfaceSecretaria e CIntefaceSGBD.

Cadastrar Aluno
Secretaria SGBD

Figura II.8 Caso de uso Cadastrar Aluno

Para descrever o processo do caso de uso e comandar as demais classes ser definida uma
classe de controle denominada CControleCadastrarAluno. Como para este caso de uso
existem trs subprocessos (incluso, alterao e excluso) poderiam ser criadas trs classes
de controle auxiliares, uma para cada subprocesso, que sero: CControleInclusaoCadAluno,
CControleAlteracaoCadAluno e CControleExclusaoCadAluno.

Por fim, analisando-se os dados manipulados pelo caso de uso, percebe-se a existncia de
apenas um grupo de dados referentes s informaes do aluno de est sendo includo,
alterado ou excludo. Desta forma, apenas uma classe do tipo entidade ser definida e ser
denominada CAluno.

<<fronteira>>
CInterfaceSecretaria
<<fronteira>>
CInterfaceSGBD
<<controle>>
CControleInclusaoCadAluno
<<entidade>>
CAluno
<<controle>>
CControleCadastrarAluno
<<controle>>
<<controle>>

Figura II.9 Classes para o caso de uso Cadastrar Aluno

Pg.: 27

4.2 Classes para o Caso de Uso Emitir Dirio de Classe

Conforme ilustrado na figura II.10, a realizao do caso de uso Emitir Dirio de Classe envolve
a comunicao com dois atores: Secretaria e SGBD. Desta forma, pode-se identificar duas
classes do tipo fronteira para implementar o interfaceamento com estes dois atores. Estas duas
classes poderiam se chamar: CInterfaceSecretaria e CIntefaceSGBD.

Nota-se que estas duas classes j foram definidas para o caso de uso Cadastrar Aluno. Neste
ponto haveriam duas possibilidades: utilizar as mesmas classes de interface para os dois casos
de uso ou definir novas classes para interfaceamento com os dois atores em cada caso de uso.
A deciso por uma desta duas solues dependeria, basicamente, da dimenso que
alcanariam estas classes se elas agrupassem o interfaceamento em ambos os casos de uso.
Como sugesto para este tipo de situao, sugere-se comear com uma soluo unificada e na
seqncia, a partir de um conhecimento melhor dos papis das classes, estudar a
possibilidade de decompor estas classes em classes mais especializadas.

Secretaria SGBD

Figura II.10 Caso de uso Cadastrar Aluno

Para descrever o processo do caso de uso e comandar as demais classes ser definida uma
classe de controle denominada CControleEmitirDiario. No se observa, neste momento,
subprocessos neste caso de uso. Por conseqncia no sero definidas classes de controle
auxiliares.

Com relao s classes do tipo entidade, deve-se considerar quais dados compem o
documento a ser impresso. Um dirio de classe normalmente contm o cdigo e nome da
disciplina, cdigo e nome do professor, carga horria, e a lista de alunos com o nome e nmero
de registro. Vrias possibilidades se apresentam para representao em memria destes
dados. Poderiam, inclusive, ser utilizadas aqui tcnicas de normalizao de Entidades e
Relacionamentos.

Uma primeira alternativa para representao dos dados do caso de uso Emitir Dirio de Classe
seria a criao de uma nica classe contendo todos os dados necessrios para a composio
do documento impresso. Esta classe poderia se chamar CDiarioClasse. Outra possibilidade
seria extrair desta classe os dados sobre disciplina, professor e alunos, e coloc-los em trs
outras classes como ilustrado na figura II.11.

<<entidade>>
CDiarioClasse
<<entidade>>
CDisciplina
<<entidade>>
CProfessor
codigoTurma: char[8]
listaAlunos
cargaHoraria:int
codigoDisciplina:char[10]
nomeDisciplina:char[30]
codigo:int
nome:char[30]
categoria:char
<<entidade>>
CAluno
registro:int
nome:char[30]
curso:char

Figura II.11 Classes de entidade para o caso de uso Emitir Dirio de Classe.

Pg.: 28
5 Concluso

Como discutido neste captulo, as classes e objetos so elementos de grande importncia pois
so os elementos constitutivos em sistemas computacionais orientados a objetos. A notao
UML para classes e objetos segue, basicamente, a sintaxe j utilizada em outras linguagens
orientadas a objetos.

Com relao ao projeto de softwares orientados a objetos, uma grande dificuldade est na
definio de quais classes so necessrias para a realizao dos casos de uso. Existem
algumas dicas gerais que podem ser seguidas que no diminuem, entretanto, a
responsabilidade do projetista no processo inventivo associado ao estabelecimento do conjunto
de classes de um sistema.

Pg.: 29

Em um sistema computacional orientado a objetos os servios (casos de uso) so fornecidos
atravs da colaborao de grupos de objetos. Os objetos interagem atravs de comunicaes
de forma que juntos, cada um com suas responsabilidades, eles realizem os casos de uso.
Neste captulo discute-se a interao entre os objetos de um sistema computacional e
apresentam-se duas notaes para a descrio destas interaes: os diagramas de seqncia
e os diagramas de colaborao.
1 Diagrama de Seqncia

O diagrama de seqncia uma ferramenta importante no projeto de sistemas orientados a
objetos. Embora a elaborao dos diagramas de seqncia possa consumir um tempo
considervel para sistemas maiores ou mais complexos, eles oferecem a seguir as bases para
a definio de uma boa parte do projeto como: os relacionamentos necessrios entre as
classes, mtodos e atributos das classes e comportamento dinmico dos objetos.

1.1 Utilizao do Diagrama de Seqncia

Um diagrama de seqncia um diagrama de objetos, ou seja, ele contm com primitiva
principal um conjunto de objetos de diferentes classes. O objetivo dos diagramas de seqncia
descrever as comunicaes necessrias entre objetos para a realizao dos processos em
um sistema computacional. Os diagramas de seqncia tm este nome porque descrevem ao
longo de uma linha de tempo a seqncia de comunicaes entre objetos.

Como podem existir muitos processos em um sistema computacional, sugere-se proceder a
construo dos diagramas de seqncia por caso de uso. Assim, tomaria-se separadamente
cada caso de uso para a construo de seu ou seus diagramas de seqncia. De uma forma
geral, para cada caso de uso constri-se um diagrama de seqncia principal descrevendo a
seqncia normal de comunicao entre objetos e diagramas complementares descrevendo
seqncias alternativas e tratamento de situaes de erro.

Utiliza-se tambm o termo cenrio associado com os diagramas de seqncia. Um cenrio
uma forma de ocorrncia de um caso de uso. Como o processo de um caso de uso pode ser
realizado de diferentes formas, para descrever a realizao de um caso de uso pode ser
necessrio estudar vrios cenrios. Cada cenrio pode ser descrito por um diagrama de
seqncia. No exemplo do caso de uso Cadastrar Aluno do sistema de controle acadmico,
pode-se considerar os cenrios de incluso, alterao e excluso de aluno.

1.2 Notao UML para Diagramas de Seqncia

Notao Bsica

A notao UML para descrio de diagramas de seqncia envolve a indicao do conjunto de
objetos envolvidos em um cenrio e a especificao das mensagens trocadas entre estes
objetos ao longo de uma linha de tempo. Os objetos so colocados em linha na parte superior
do diagrama. Linhas verticais tracejadas so traadas da base dos objetos at a parte inferior
do diagrama representando a linha de tempo. O ponto superior destas linhas indica um instante
Capt ulo I I I : Est udo das I nt er aoes
ent r e Obj et os
Pg.: 30
inicial e, medida que se avana para baixo evolui-se o tempo. Retngulos colocados sobre as
linhas de tempo dos objetos indicam os perodos de ativao do objeto. Durante um perodo de
ativao, o objeto respectivo est em execuo realizando algum processamento. Nos
perodos em que o objeto no est ativo, ele est alocado (ele existe) mas no est
executando nenhuma instruo. A figura III.1 ilustra a estrutura bsica de um diagrama de
seqncia para o cenrio Incluso de Aluno do caso de uso Cadastrar Aluno.

:CInterfaceSecretaria :CControleCadastarAluno
Secretaria
:CAluno
:CInterfaceSGBD
SGBD
objetos
linha de
tempo
ativacao

Figura III.1 Estrutura bsica de um diagrama de sequencia.

Outra primitiva importante dos diagramas de seqncia a troca de mensagem. Esta primitiva
utilizada para indicar os momentos de interao ou comunicao entre os objetos. Utiliza-se
como notao para trocas de mensagens segmentos de retas direcionados da linha de tempo
de um objeto origem para a linha de tempo de um objeto destino. Uma seta colocada na
extremidade do objeto destino. As linhas representando troca de mensagens so desenhadas
na horizontal pois presume-se que a troca de uma mensagem consome um tempo desprezvel.

O objeto destino de uma mensagem deve receber a mensagem e process-la. Desta forma, no
recebimento de uma mensagem o objeto destino ativado para tratamento da mensagem. A
figura III.2 ilustra a troca de mensagens entre objetos e entre atores e objetos.

:CInterfaceSecretaria
:CControleCadastarAluno
Secretaria
:CAluno
MostrarJanela
Janela
Dados
Registrar(Dados)
Acessar(codigo)

Figura III.2 Exemplo de troca de mensagens em um diagrama de sequencia.
Pg.: 31

Significado das Mensagens

As mensagens trocadas entre um objeto e outro ou entre um objeto e um ator podem ter trs
significados:

Chamada de Funo ou Procedimento
Uma das interaes mais freqentes entre objetos a chamada de funo. Uma
chamada de funo significa que um objeto est solicitando a execuo de uma funo
(um mtodo) de um outro objeto. Este conceito segue estritamente o processo de
chamada de funo ou de procedimento utilizado nas linguagens de programao.
Obviamente, para que um objeto possa chamar um mtodo de outro objeto
necessrio que o mtodo seja declarado como pblico na classe respectiva. Como ser
visto a seguir, a sintaxe, no caso de mensagens que representem chamadas de funo,
semelhante quela das linguagens de programao.

Envio de Mensagem

Objetos tambm podem comunicar-se com outros objetos atravs do envio explcito de
uma mensagem. O envio de uma mensagem, ao contrrio da chamada de funo, no
uma interao direta entre dois objetos. Na verdade, quando um objeto envia uma
mensagem a outro objeto, a mensagem roteada ou encaminhada por algum
mecanismo de entrega de mensagens. Normalmente, este servio prestado pelo
sistema operacional atravs de mecanismos como Message Queues (filas de
mensagens) ou servios de notificao.

Ocorrncia de Evento

Existem tambm outras formas de interao entre objetos atravs de eventos. Esta
tambm a forma padro de interao entre objetos e atores. Basicamente, um evento
algum acontecimento externo ao software mas que a ele notificado pois lhe diz
respeito. A notificao, ou seja, a indicao de que um determinado evento ocorreu ,
na maioria dos casos, feita pelo sistema operacional. Eventos podem tambm ser
gerados pelo software para o sistema operacional. Exemplos so as sadas para
dispositivos (monitor, porta serial, disco) feita atravs de servios do sistema
operacional.

Alguns exemplos de eventos so:

Evento Origem Destino
Clique do mouse mouse algum objeto
Movimentao do mouse mouse algum objeto
Dados no buffer do teclado teclado algum objeto
Dados no buffer da serial porta serial algum objeto
Projeo de dados no monitor algum objeto monitor
Bip do autofalante algum objeto autofalante
Colocao de dados no buffer da serial algum objeto porta serial
Interrupo dispositivo de
hardware
algum objeto
Eventos do sistema operacional (timer) sistema operacional algum objeto

Pg.: 32
Sintaxe das Mensagens

A sintaxe geral para mensagens em diagramas de seqncia :

Predecessor/ *[Condio] Seqncia: Retorno:= Nome_Mensagem(Argumentos)

Predecessor/
As mensagens em um diagrama de seqncia podem ser numeradas para indicar a
ordem de ocorrncia (ver adiante). Toda mensagem para ser enviada depende de que a
mensagem imediatamente anterior tenha sido enviada indicando, assim, uma
dependncia temporal que define a ordem de envio das mensagens. A mensagem
imediatamente anterior o predecessor natural de cada mensagem e no precisa ser
indicada pois entende-se isto implicitamente.
Algumas mensagens dependem de mais de um predecessor. Na verdade isto s ocorre
em processos concorrentes. Quando houver mais de um objeto ativo (mais de uma
thread) em execuo algumas mensagens podem depender de seu predecessor
imediato mas tambm de algum predecessor associado outro objeto ativo. Tem-se,
desta forma, um conjunto de mensagens que no seguem uma seqncia. Neste caso
pode-se indicar o predecessor no imediato indicando-se sua numerao de seqncia
seguida de uma barra inclinada (/). Se houverem vrios predecessores no imediatos
deve-se separ-los com vrgulas.

Condio
Pode-se, opcionalmente, incluir uma condio entre colchetes em uma mensagem.
Desta forma, para que a mensagem seja enviada necessrio que a condio seja
satisfeita. Uma condio descrita por uma expresso de igualdade envolvendo
atributos do objeto ou outras variveis locais e constantes.
Exemplos: [x<10], [res=OK], [valor=5], [flag=true].
A incluso de um asterisco (*) antes de uma condio permite especificar iteraes ou
repeties. Neste caso, a condio representa uma expresso lgica de controle da
repetio. A condio ser avaliada e, se for verdadeira, a mensagem ser enviada
uma primeira vez. Ao trmino do envio, a condio ser reavaliada. Enquanto a
condio for verdadeira a mensagem continuar a ser enviada e a expresso de
condio reavaliada. Quando a condio se tornar falsa, a mensagem no enviada e
avana-se para a prxima mensagem no diagrama. Note que a mensagem pode nunca
ser enviada se j na primeira avaliao da condio o resultado for falso. possvel,
tambm, utilizar a prpria varivel de retorno (ver adiante) como membro da expresso
de condio.
Exemplo: *[x<10] calcular(x)
Neste exemplo, enquanto o valor da varivel x for menor do que dez, a mensagem
calcular(x) ser enviada.

Seqncia
As mensagens em um diagrama de seqncia ocorrem em uma determinada seqncia
indicada pela ordem de aparecimento no diagrama. Pode-se incluir junto s mensagens
uma numerao de seqncia para indicar explicitamente a ordenao de ocorrncia
das mensagens. As mensagens so enviadas na ordem indicada por seus nmeros de
seqncia. Esta informao , na maioria das vezes desnecessrio pois o grafismo dos
diagramas de seqncia j indica a cronologia de ocorrncia das mensagens. Em
diagramas de colaborao, entretanto, a indicao do nmero de seqncia pode ser
Pg.: 33

til. O uso da numerao de seqncia tambm til quando existem concorrncias no
diagrama de seqncia pela existncia de mais de uma thread.
A notao para seqncia a colocao de um valor inteiro seguido de dois-pontos (:)
antes do nome da mensagem.
Pode-se utilizar nveis na numerao das mensagens. Isto pode ser til para a
identificao de blocos de mensagens. Por exemplo, todas as mensagens com nmero
de seqncia prefixado com 1. representam a fase de inicializao e todas as
mensagens com nmero de seqncia prefixado com 2. representam a fase de
processamento.
Quando houver mais de um objeto ativo, indicando um fluxo de mensagens no
seqencial, pode-se utilizar letras na numerao das mensagens. Cada letra prefixando
um conjunto de nmeros de seqncia indicaria mensagens de um certa thread.

Retorno
Determinadas mensagens podem produzir um valor de retorno ao trmino de seu
tratamento. Este valor deve ser retornado ao objeto que enviou a mensagem. O caso
mais comum de valor de retorno ocorre na chamada de funes. Muitas funes
permitem produzir um valor que retornado ao objeto que fez sua chamada. O objeto
chamador, neste caso, deve indicar uma varivel para receber o valor de retorno.
A notao para valor de retorno a indicao de um nome de varivel seguida de dois-
pontos antes do nome da mensagem.
Exemplo: res:=registrar(codigo)
Neste exemplo a varivel res receber o valor de retorno da funo registrar. Deve-se
notar que a varivel res uma varivel do objeto que est enviado a mensagem
(fazendo a chamada) e que ela deve ter sido declarada como um atributo do objeto ou
como uma varivel local.

Nome_Mensagem
O nome da mensagem o identificador da mensagem ou funo que est sendo
chamada. Quando se tratar de chamada de funo necessrio que a funo seja
declarada como uma das funes membro do objeto de destino da mensagem.

Argumentos
Os argumentos de uma mensagem so valores (constantes ou variveis) enviados junto
com a mensagem. No caso de chamadas de funo os argumentos devem coincidir
com os parmetros definidos para a funo na classe do objeto destino. No
necessrio indicar o tipo de dado do argumento pois os tipos so definidos na classe do
objeto de destino.

Tipos de Mensagens

Nos exemplos das figuras III.1 e III.2 utilizou-se como notao grfica para as trocas de
mensagens segmentos de reta com um seta aberta em uma das extremidades. Esta a
notao genrica para mensagens que pode ser utilizada nas primeiras verses dos diagramas
de seqncia. Em diagramas mais detalhados, entretanto, ser utilizada outra notao de
forma a indicar tambm o tipo das mensagens. Existem dois tipos de mensagens chamadas
mensagens sncronas e assncronas.

Pg.: 34
Mensagens Sncronas
Mensagens sncronas so mensagens que implicam um sincronismo rgido entre os
estados do objeto que envia a mensagem e os do objeto de destino da mensagem. Um
sincronismo entre objetos podem ser entendido, de uma forma geral, como uma
dependncia na evoluo de estado de um objeto sobre o estado de um segundo
objeto. De uma forma mais direta, pode-se dizer que uma mensagem sncrona implica
que o objeto que enviou a mensagem aguarde a concluso do processamento da
mensagem (entendida como um sinal de sincronismo) feito pelo objeto destino, para
ento prosseguir seu fluxo de execuo.
O exemplo mais comum de mensagem sncrona a chamada de funo. Em uma
chamada de funo o objeto que faz a chamada empilhado e fica neste estado at a
concluso do processamento da funo chamada. Trata-se, portanto, de um
sincronismo rgido entre o objeto chamador e o objeto chamado. Alguns sistemas
operacionais oferecem tambm mecanismos de troca de mensagens sncronas de
forma que o objeto que envia a mensagem fique em estado de espera at a concluso
do tratamento da mensagem.
A notao UML para uma mensagem sncrona a de um segmento de reta com uma
seta cheia em uma das extremidades (figura III.3).

Mensagens Assncronas
Mensagens assncronas so mensagens enviadas de um objeto a outro sem que haja
uma dependncia de estado entre os dois objetos. O objeto de origem envia a
mensagem e prossegue seu processamento independentemente do tratamento da
mensagem feita no objeto destino. Os mecanismos de envio de mensagens suportados
pelos sistemas operacionais so o exemplo mais comum deste tipo de mensagem.
Alm disso, de uma forma geral, todas as comunicaes entre atores e objetos
representam trocas de mensagem assncronas. Considere, por exemplo, uma operao
para apresentao de uma mensagem no monitor. Um objeto executa uma instruo
printf (ou print ou write) e o sistema despacha a mensagem para o ator (o monitor). O
objeto prossegue seu processamento independentemente do desfecho na operao.
Observe que os softwares no bloqueiam quando o monitor no apresenta alguma
informao.
A notao UML para uma mensagem assncrona a de um segmento de reta com uma
meia seta em uma das extremidades (figura III.3).

Alm desta diferenciao entre mensagens sncronas e assncronas, pode-se tambm indicar
quando uma mensagem consome tempo. A notao UML para mensagens deste tipo
ilustrada na figura III.3.

Pg.: 35

Secretaria
Janela
Dados
InformarCodigo(c)
SGBD
MostrarJanela
mensagens
assncronas
mensagem
sncrona
mensagem
consumindo
tempo

Figura III.3 Notacao para mensagens sncronas, assncronas e que consomem tempo.

Notao Complementar

Alm da notao vista nas sees anteriores existem ainda alguns elementos complementares
da notao, conforme descrito a seguir.

Criao e Destruio de Objetos
Objetos que participam de um caso de uso e que aparecem nos diagramas de
seqncia podem no existir desde o incio da execuo do caso de uso e podem
no permanecer existindo at a concluso do caso de uso. Dito de outra forma,
objetos podem ser criados (alocados) e destrudos (desalocados) ao longo da
execuo de um caso de uso. Existem duas formas de se representar estas
situaes.
A primeira forma de especificar criao e destruio de objetos incluindo-se o
objeto no alinhamento de objetos na parte superior do diagrama de seqncia e
indicando os eventos de criao e destruio atravs de mensagens sncronas. A
figura III.4 ilustra esta forma de especificao.
:CControleCadastarAluno :CAluno
criar
destruir

Figura III.4 Notacao bsica para criacao e destruicao de objetos.
Pg.: 36

Outra forma de especificar a criao e destruio de um objeto faz-lo aparacer no
diagrama somente aps sua criao e eliminar sua linha de tempo aps sua
destruio, conforme ilustrado na figura III.5. Utiliza-se neste caso um smbolo de X
para indicar o ponto de destruio do objeto.
:CAluno
criar
destruir

Figura III.5 Notacao altenativa para criacao e destruicao de objetos.

Nas duas notaes possvel incluir parmetros na mensagem criar. Isto
correponderia aos argumentos passados para a funo construtora do objeto.

Autodelegao

Um objeto pode enviar mensagens para outros objetos e pode, tambm enviar
mensagens para ele prprio. Uma mensagem enviada de um objeto para ele prprio
chama-se uma autodelegao. Mensagens de autodelegao podem ser sncronas
ou assncronas. O caso mais comum de mensagens assncronas o envio de uma
mensagem de um objeto para ele mesmo atravs de mecanismos de envio de
mensagens do sistema operacional. O caso mais comum de mensagens de
autodelegao sncronas a chamada de funo de um objeto pelo prprio objeto.
A notao UML para autodelegao ilustrada na figura III.6.

Calcular(valor)
FimProcesso

Figura III.6 Notacao UML para autodelegacao.

Pg.: 37

Objeto Ativo
Um objeto ativo um objeto que est em execuo em uma thread prpria. Isto
significa que o objeto tm um fluxo de execuo distinto do fluxo de execuo dos
demais objetos e est em execuo concorrente. Este tipo de ocorrncia cada vez
mais comum em sistema operacionais multitarefa como o Windows da Microsoft.
A notao UML para objetos ativos a indicao com borda larga do objeto ativo.
Esta notao pode ser utilizada em qualquer diagrama de objetos inclusive nos
diagramas de seqncia.
Deve-se observar que objetos ativos introduzem um comportamento diferente e
mais complexo nos diagramas de seqncia. Os diagramas passam a incluir
concorrncia. Tipicamente, a comunicao entre um objeto ativo e outros objetos se
faz atravs de mensagens assncronas. A figura III.7 apresenta um pequeno
exemplo de uso de um objeto ativo.
:CControle :CInterface
Enviar(msg)
:CSerial
mensagem
ack

Figura III.7 Exemplo de objeto ativo

Retorno de Mensagem Sncrona
Uma notao existente na UML, embora em desuso, a de retorno de mensagem
sncrona. Esta notao utilizada para indicar o trmino de uma chamada sncrona
e representaria o sinal de retorno da chamada. No se trata, entretanto, de uma
mensagem explcita de algum objeto mas de um sinal de controle. Na prtica este
retorno significa o desempilhamento da funo chamada ou o desbloqueio da
instruo de envio no caso de mensagens sncronas.
A notao UML para retorno de mensagem sncrona uma linha tracejada no
sentido contrrio do da chamada sncrona com a indicao retorno. A figura III.8
ilustra o uso de retorno de mensagem sncrona.
Pg.: 38
Registrar(c,n)
retorno

Figura III.8 Notacao UML para retorno de mensagem sncrona.

Notaes No Padronizadas

Sobreativao
Uma sobreativao a ativao de um objeto que j estava ativado. Em termos de
programa, uma sobreativao representa um empilhamento de funo de um
mesmo objeto. Um caso simples de sobreativao a autodelegao, em particular
a chamada de funo de um objeto pelo prprio objeto. A funo que fez a chamada
empilhada e a funo chamada ativada. Outro exemplo de sobreativao ocorre
quando um objeto chama uma funo de outro objeto e empilhado aguardando a
concluso da chamada. O segundo objeto, ento, faz uma chamada de funo ao
primeiro objeto ativando uma funo de um objeto que j estava ativado (embora
empilhado).
A UML no apresenta uma notao para sobreativao. Uma notao especial
proposta no sistema CASE Together que utiliza um retngulo adicional para indica a
sobreativao. A figura III.9 ilustra esta notao.

Calcular(v)
Registrar()
Processar()

Figura III.9 Notacao para sobreativacao.

Pg.: 39

Teste condicional
Segundo a norma UML, testes condicional so sempre associados s mensagens e
so especificados como expresses lgicas entre colchetes antes do nome da
mensagem. No sistema CASE Together, utiliza-se a instruo if (expressao)
then else para indicar testes condicionais e blocos de comandos associados.
Esta soluo permite a construo efetiva de algoritmos atravs de diagramas de
seqncia. A figura III.10 ilustra o uso desta notao. Deve-se observar que este
artifcio permite contornar um deficincia da UML que a especificao de vrias
mensagens sob uma mesma condio.
:CControle :ClasseA
if (x>10)
Processar(x)
:ClasseB
else
Armazenar(x)
Calcular()

Figura III.10 Notacao para teste condicional.

Laos
Laos so estruturas de repetio controladas utilizadas em diversos tipos de
processamentos. A UML inclui como especificador de repetio a notao *[cond].
Esta notao, entretanto, s permite indicar repeties sobre uma nica mensagem.
No sistema CASE Together, adotou-se uma notao adicional permitindo especificar
repeties sobre blocos utilizando a noo de sobreativao. Utiliza-se para controle
da repetio uma instruo while ou repeat com uma expresso condicional tal
como ocorre nas linguagens de programao. A figura III.11 ilustra uma repetio
utilizando esta notao.
:CControleCadastarAluno :ClasseA
while(i<10)
Incrementar()
Processar()

Figura III.11 Notacao para lacos.
Pg.: 40
Mltiplos aninhamentos
Mltiplos aninhamentos ocorrem quando existem mltiplas sobreativaes de um
objeto. Em termos de programa isto significa mltiplo empilhamento, ou seja,
diversas funes de um objeto so chamadas sem que as precedentes tenham
concludo sua execuo. Estes aninhamentos podem ocorrer em chamadas de
funo, dentro de blocos condicionais e dentro de repeties. A figura III.12
apresenta um exemplo de mltiplo aninhamento. Deve-se observar que
aninhamentos com um nmero indefinido de nveis (como nas recursividades) no
podem ser representados diretamente com esta notao.

:CControleCadastarAluno :ClasseA
while(i<10)
Incrementar()
Acessar()

Figura III.12 Mltiplo aninhamento.

2 Diagrama de Colaborao

Os diagramas de colaborao derivam dos diagramas de seqncia. Eles podem, inclusive, ser
gerados automaticamente a partir dos diagramas de seqncia (como ocorre no software
Rational Rose). Os diagramas de colaborao descrevem grupos de objetos que colaboram
atravs de comunicaes.

2.1 Utilizao dos Diagramas de Colaborao

Os diagramas de colaborao so diagramas de objetos. As primitivas neste tipo de diagrama
so os objetos, atores e comunicaes. As comunicaes so conexes entre objetos e entre
objetos e atores indicando que este elementos se comunicam e relacionando as mensagens
trocadas entre eles.

Pode-se considerar que um diagrama de colaborao um diagrama de seqncia sem as
linhas de tempo. Eles apresentam, portanto, todas as mensagens entre pares de objetos de
forma agrupadas sem especificar a cronologia de ocorrncia.

O objetivo na construo de diagramas de colaborao exatamente agrupar as mensagens
entre pares de objetos de forma a fazer-se um levantamento das necessidades de
comunicao. Na seqncia esta informao ser utilizada para a definio das relaes
estruturais entre as classes de forma a se estabelecer canais f sicos de comunicao para os
objetos. Atravs destes canais (relacionamentos) todas as mensagens sero trocas entre os
objetos das classes respectivas.

Pg.: 41

2.2 Notao para Diagramas de Colaborao

A notao UML para diagramas de colaborao inclui a notao para objetos e atores, como j
foi visto anteriormente, e a notao para comunicaes. Um comunicao especificada
atravs de um segmento de reta ligando um objeto outro ou um objeto a um ator. Sobre este
segmento de reta relaciona-se, separadamente, as mensagens enviadas em cada sentido.
Observa-se que as comunicaes podem ser uni ou bidirecionais conforme o sentido do
conjunto de mensagens trocas entre os objetos.

A figura III.13 apresenta um exemplo de diagrama de colaborao correspondendo ao exemplo
da figura III.2. Observe que costuma-se numerar as mensagens de maneira a indicar a ordem
de ocorrncia. Nos diagramas de seqncia costuma-se no fazer esta numerao pois o
prprio diagrama j indicar o ordenamento pelo seu grafismo.

Secretaria
:CAluno
1:MostrarJanela
2:Janela
3:Dados
4:Registrar(Dados)
5:Acessar(codigo
)

Figura III.13 Exemplo de diagrama de colaboracao.

Pg.: 42
3 Exemplos de Diagramas de Seqncia e Colaborao

A figura III.14 apresenta um exemplo de diagrama de seqncia para o caso de uso Cadastrar
Disciplina do sistema de controle acadmico discutido nos captulos anteriores. O diagrama
mostra o cenrio de Incluso de uma Disciplina no Cadastro.

:CcontroleCadastar
Disciplina
Secretaria
disc:CDisciplina
MostrarJanelaIncDisc()
Janela
Dados
Registrar(cod,n,ch)
GravarDisc(disc)
SGBD
:CInterfSGBD
Acessar(cod,n,ch)
Save(cod,n,ch)
MostrarFimIncDisc()
Fim

Figura III.14 Diagrama de sequencia do caso de uso Cadastrar Disciplina.

A figura III.15 apresenta o diagrama de colaborao obtido a partir do diagrama de seqncia
da figura III.14.
5:GravarDisc(disc)
:CcontroleCadastrar
Disciplina
Secretaria
disc:CDisciplina
1:MostrarJanelaIncDisc()
8:MostrarFimIncDisc()
2:Janela
9:Fim
3:Dados
4:Registrar(cod,n,ch)
6:Acessar(cod,n,ch)
SGBD
:CInterfSGBD
7:Save(cod,n,ch)

Figura III.15 Diagrama de colaboracao do diagrama de sequencia da figura III.14.

A figura III.16 apresenta o diagrama de seqncia para o caso de uso Emitir Dirio de Classe
do sistema de controle acadmico discutido nos captulos anteriores.
Pg.: 43

Figura III.16 Diagrama de sequencia do caso de uso Emitir Dirio de Classe.

O diagrama na figura III.16 foi elaborado utilizando a ferramenta CASE Together 5.02. As
descontinuidades na ativao de certos objetos so devidas aos automatismos da prpria
ferramenta. Note, por exemplo, que o objeto da classe CCtrlDiario deveria estar ativo ao longo
de todo o diagrama pois ele comanda a execuo do caso de uso.

A figura III.17 apresenta o diagrama de colaborao obtido a partir do diagrama de seqncia
da figura III.16.
Pg.: 44

Figura III.17 Diagrama de colaboracao do diagrama de sequencia da figura III.16.


Pg.: 45

Neste captulo discute-se os relacionamentos estruturais entre classes. Estes relacionamentos
existem em todo sistema orientado a objetos e so eles que permitem a interao entre os
objetos para a realizao dos casos de uso. Estes relacionamentos precisam ser
criteriosamente definidos durante o projeto do software. Como ser discutido, os
relacionamentos necessrios podem ser, e em grande parte so, obtidos a partir de anlise dos
diagramas de colaborao e dos papis das classes.
A definio das classes e dos relacionamentos iro compor os diagramas de classes do
sistema. Este um dos principais diagramas da UML e dos projetos de software, pois eles
descrevem o esqueleto do sistema sendo projetado. A partir do diagrama de classes j
possvel, por exemplo, a gerao (parcial) de cdigo fonte.
Existem, basicamente, trs tipos de relacionamentos entre classes : associao, agregao e
generalizao. As sees seguintes discutem estes tipos de relacionamentos e apresentam a
notao UML utilizada para diagramas de classes.

1 Associao entre Classes

A associao o tipo de relacionamento mais comum e mais importante em um sistema
orientado a objetos. Praticamente todo sistema orientado a objetos ter uma ou mais
associaes entre suas classes. Uma associao um relacionamento ou ligao entre duas
classes permitindo que objetos de uma classe possam comunicar-se com objetos de outra
classe.

O objetivo essencial da associao possibilitar a comunicao entre objetos de duas classes.
A associao aplica-se a classes independentes que precisam comunicar-se de forma uni ou
bidirecional de maneira a colaborarem para a execuo de algum caso de uso. Uma classe
pode associar-se a uma ou mais classes para fins de comunicao. No existe um limite
mximo de associaes que uma classe pode possuir com outras classes.

1.1 Notao UML para Associaes

Nome e sentido

A notao UML para uma associao um segmento de reta ligando as duas classes. Se a
associao for unidirecional, inclui-se uma seta na extremidade de destino da associao.
Opcionalmente, mas fortemente sugerido, pode-se incluir um nome na associao. Este nome
colocado sobre o segmento de reta e tem como propsito indicar a natureza da associao.
Embora associaes sirvam sempre para comunicaes, atravs do seu nome pode-se indicar
com mais clareza a natureza ou finalidade da comunicao. O nome, entretanto, serve apenas
como elemento de documentao no possuindo uma semntica mais importante. A figura IV.1
ilustra a notao bsica para relacionamentos de associao.
Capt ulo I V : Rel aci onament os ent r e
Cl asses
Pg.: 46
CInterfSecretaria CAluno
Registra

Figura IV.1 Notacao bsica para relacionamentos de associacao.

No exemplo da figura IV.1, a associao Registra unidirecional indicando que objetos da
classe CInterfSecretaria podem se comunicar com objetos da classe CAluno. Observe que
neste caso, a associao no pode ser navegada no sentido contrrio, ou seja, objetos da
classe CAluno no podem se comunicar com objetos da classe CInterfSecretaria.

Papis das classes

Pode-se, ainda, incluir uma indicao dos papis das classes nas associaes. Uma
especificao de papel indica qual a participao ou atribuio de cada classe na associao.
A indicao de papel feita colocando-se a especificao do papel na forma de um texto nos
extremos da associao de forma a indicar, para cada classe, qual o seu papel. No comum
indicar o nome da associao e os papis das classes para uma mesma associao.
Normalmente, opta-se por uma ou outra especificao. A figura IV.2 ilustra um relacionamento
de associao com papis.

CInterfSecretaria
CAluno
registra registrado

Figura IV.2 Notacao bsica para relacionamentos de associacao.

Cardinalidade

A cardinalidade uma indicao que especifica o nmero de objetos de cada classe envolvidos
com a associao. Quando no h uma especificao de cardinalidade, entende-se que a
cardinalidade 1. Isto significa que apenas um objeto de cada classe est envolvido com a
associao.

A especificao de cardinalidade feita em cada extremo da associao e utiliza-se a seguinte
notao :

Notao Significado Exemplo
Constante numrica Indica um nmero fixo de objetos 5
Faixa de valores Indica um nmero varivel de objetos dentro
da faixa de valores especificada
1..4
Presena ou Ausncia Indica nenhum ou um (ou mais) objetos 0..1
Indefinido Indica um nmero qualquer de objetos *

A figura IV.3 ilustra uma associao para a qual indica-se a cardinalidade.

CTurma CAluno
40
*
Registra

Figura IV.3 Associacao com cardinalidade.

Pg.: 47

A interpretao da cardinalidade exige alguma ateno. Na verdade existe uma forma correta
de leitura da cardinalidade. Deve-se fazer a leitura da cardinalidade de forma distinta para os
dois sentidos da associao (mesmo que ela seja unidirecional). Para cada um dos sentidos
deve-se esquecer a cardinalidade no extremo de incio da leitura e considerar que existe uma
associao de UM objeto da classe de incio da leitura com tantos objetos quanto estiver
especificado pela cardinalidade da classe na outra extremidade da associao. Para o exemplo
da figura IV.3, deve-se fazer a seguinte leitura:
Um objeto da classe Cturma se associa com 40 objetos da classe CAluno, e um objeto
da classe CAluno se associa com um nmero indefinido (inclusive zero) de objetos da classe
CTurma.

1.2 Levantamento de Associaes

Associaes so definidas conforme seja necessrio estabelecer um canal para comunicao
entre objetos de duas classes. Basicamente, as associaes so estabelecidas observando-se
as necessidades de comunicao definidas nos diagramas de seqncia e resumidas nos
diagramas de colaborao. Para cada par de classes, verifica-se em todos os diagramas de
colaborao de todos os casos de uso, se existem mensagens trocadas entre objetos destas
classes. Sempre que houverem mensagens trocadas, estabelece-se uma associao uni ou
bidirecional conforme o sentido das mensagens. Procedendo-se desta forma para todas as
classes do sistema, constri-se uma rede de comunicao entre as classes.

Embora este procedimento de levantamento permita uma definio bem fundamentada das
associaes entre classes, ainda necessrio um trabalho de complementao deste
processo. Como os diagramas de seqncia e de colaborao retratam cenrios dos casos de
uso, eles podem no cobrir a totalidade de situaes de comunicao que podem se
apresentar. Desta forma, importante estudar o conjunto de associaes que foram definidas
para sua complementao (incluso de eventuais associaes extras) e para uma boa
especificao de nomes e cardinalidades.

A figura IV.4 ilustra o resultado do levantamento de associaes considerando o diagrama de
colaborao da figura III.16.

Figura IV.4 Levantamento de Associaces.
Pg.: 48
2 Agregao entre Classes

A agregao um relacionamento pertinncia entre classes que permite estabelecer a incluso
de objetos de uma classe no interior de objetos de outra classe. A agregao tambm dita
uma relao parte-de j que o objeto agregado passa a constituir ou fazer parte do objeto que
agrega. Deve-se observar que no se trata de incluir (ou agregar) uma classe dentro de outra
mas de objetos dentro de outros objetos. A relao de agregao permite criar composies de
objetos, o que bastante til quando se deseja definir hierarquias de dados ou procedimentos.

A agregao fornece tambm um canal de comunicao entre o objeto que contm e o objeto
contido. Note que esta comunicao unidirecional do objeto que agrega para o objeto
agregado. O objeto agregado no conhece, a princpio, o objeto que agrega. Desta forma, ele
no pode comunicar-se com o objeto que agrega.

2.1 Notao UML para Agregaes

A notao UML para agregaes a de um segmento de reta ligando a classe dos objetos que
agregam classe dos objetos agregados. Na extremidade da classe dos objetos que agregam
inclui-se um losngulo, conforme ilustrado na figura IV.5.

CEscola CDepartamento
contm

Figura IV.5 Notacao para agregaces.

Nome e papis

Pode-se incluir nomes e papis nas agregaes como ocorre para as associaes. Entretanto,
como trata-se sempre de uma relao de pertinncia, a incluso de nomes e papis torna-se
desnecessria pois os nomes seriam sempre inclui, contm ou outro equivalente e os papis
seriam sempre contm e est contido, ou equivalente.

Cardinalidade

A definicao de cardinalidade tem nas agregaes a mesma finalidade do que nas
associaes. Determina-se atravs dela o nmero de objetos envolvidos na relao. Deve-se
observar que embora um objeto possa incluir vrios outros objetos, um objeto no pode estar
contido em mais de um objeto. Desta forma, a cardinalidade no lado da classe dos objetos que
agregam ser sempre 1, podendo ser suprimida.

A figura IV.6 ilustra um exemplo de agregao com cardinalidades. Neste exemplo, defini-se
que um objeto da classe CCarro contm 4 objetos da classe CRoda e 5 objetos da classe
CPorta.

Pg.: 49

CCarro CRoda
CPorta
4
5

Figura IV.6 Agregaces com cardinalidade.

2.2 Definio de Agregaes

O levantamento e definio das agregaes em um certo sistema realizado a partir de
diferentes anlises. No existe uma tcnica precisa para se definir as agregaes em um
sistema. De uma forma geral, pode-se utilizar certos raciocnios como sugesto para a
definio de agregaes, conforme apresentado a seguir.

Definio de agregaes a partir de decomposies
Durante o levantamento e especificao de classes no projeto de um sistema, pode-se
perceber que determinada classe tem um conjunto extenso de responsabilidades fazendo
com que a classe tenha uma dimenso considervel. Uma tentativa para melhorar a
interpretao da classe e, talvez, sua organizao seria desmembrar a classe em classes
menores. As classes, ento, passariam a se comunicar para atender aos servios originais
da classe maior. Esta soluo traz como inconveniente o fato de a classe original, que
provavelmente tinha uma identidade, se desmembrar perdendo esta identidade. Por
exemplo, se tivssemos a classe CCarro se desmembrando em classes como Crodas,
Cmotor e Ccarroceria, a figura e identidade da classe carro se dispersaria.
Uma alternativa para o desmembramento a decomposio da classe atravs de
agregaes. Neste caso, matm-se a classe original e criam-se classes adicionais que
descrevem partes da classe principal. Atravs das agregaes mantm-se a identidade da
classe maior indicando que ela composta por partes que so descritas separadamente.

Definio de agregaes a partir de composies
Um raciocnio para definio de agregaes exatamente contrrio ao da decomposio o
da composio de objetos. Nesta viso, procura-se identificar conjuntos de objetos que
juntos compem objetos maiores (objetos agregados possuindo uma identidade). Nestas
circunstncias, pode-se criar novas classes definidas sobre relaes de agregao com
classes que representam suas partes. Deve-se observar que as agregaes atravs de
composio precisam ser definidas em funo dos casos de uso do sistema pois, embora
possvel, nem todas as agregaes podem interessar a um determinado sistema.

Pg.: 50

Definio de agregaes a partir de partes comuns

Agregaes podem tambm ser obtidas atravs da identificao de partes comuns a duas ou
mais classes. Isto se aplica quando percebe-se dentro de duas ou mais classes um conjunto
de atributos e/ou mtodos semelhantes. Se estes atributos e/ou mtodos juntos possuem
alguma identidade, ento poderia ser criada uma nova classe extraindo-se a parte comum
das classes originais e definindo-se relaes de agregao com esta nova classe.
A figura IV.7 apresenta um exemplo de definio de agregaes a partir da identificao de
partes comuns. Neste exemplo, percebeu-se que os atributos Rua, Numero, Cidade, UF e
CEP so os mesmos nas classes CAluno e CProfessor. Como mostra o exemplo, optou-se
por criar uma nova classe chamada CEndereco incluindo os atributos comuns citados.
Atravs de relaes de agregao as classes CAluno e CProfessor incorporam novamente
os atributos de endereo a suas listas de atributos.

CAluno
CEndereco
CProfessor
Nome
Rua
Numero
Cidade
UF
CEP
Nome
Rua
Numero
Cidade
UF
CEP
CAluno
CProfessor
Nome

Nome

Rua
Numero
Cidade
UF
CEP

Figura IV.7 Definicao de agregaces a partir de partes comuns.
Deve-se observar no exemplo da figura IV.7 que embora a classe CEndereco possua uma
agregao com ambas as classes CAluno e CProfessor, isto no significa que um mesmo
objeto desta classe esteja contido nas duas classes que agregam. Tratam-se de dois objetos
distintos, um agregado classe CAluno e outro classe CProfessor.

2.3 Tipos de Agregao

A linguagem UML permite a definio de dois tipos de agregao chamadas agregao por
composio e agregao por associao, conforme descrito a seguir.

Agregao por Composio
Uma agregao por composio uma agregao de fato. Isto significa que realmente
feita a criao ou alocao de um objeto dentro de um outro objeto. A alocao do objeto
interno feita estaticamente pela instanciao do objeto. A figura IV.8 mostra um trecho de
cdigo em C++ ilustrando a definio de uma agregao por composio. O objeto ender da
classe CEndereco est sendo instanciado dentro da classe CAluno. Deve-se observar que
na agregao por composio necessrio que o nmero de objetos agregados seja fixo
uma vez que eles so alocados estaticamente.
Pg.: 51

A notao UML para agregaes por composio um retngulo preenchido como ilustrado
na figura IV.8.

CEndereco CAluno
Nome

Rua
Numero
Cidade
UF
CEP
class CAluno
{
char nome[30];
CEndereco ender;

...
};

Figura IV.8 Exemplo de agregacao por composicao.

Agregao por Associao
A agregao por associao tem a mesma interpretao do que a agregao por
composio, ou seja, entende-se que o objeto agregado um componente do objeto que
agrega. A grande diferena est na forma de alocao do objeto agregado. Na agregao
por associao a alocao do objeto agregado no ocorre de forma esttica no interior da
classe do objeto que agrega. A alocao do objeto ocorre de forma esttica fora do objeto
que agrega ou de forma dinmica em seu interior. O objeto que agrega guarda apenas o
identificador ou endereo do objeto agregado. Por conseqncia, uma agregao por
associao no rigorosamente uma agregao.
As agregaes por associao tm este nome pois sua implementao ocorre atravs de
associaes. Elas so consideradas agregaes quando realiza-se um controle de escopo
para os objetos agregados. Desta forma, os objetos agregados deveriam ser criados,
acessados e destrudos unicamente pelo objeto que agrega estabelecendo assim laos de
agregao. Note que em termos de implementao no existe diferena entre a associao
e a agregao por associao.
A agregao por associao necessria quando deseja-se estabelecer uma agregao
envolvendo um nmero varivel de objetos. Como dito anteriormente, a agregao por
composio s pode ser definida para um nmero fixo de objetos.
A figura IV.9 ilustra um trecho de cdigo em C++ e a respectiva representao em UML de
uma agregao por associao de um nmero varivel de objetos. Note que, como na
associao, a implementao da agregao por associao feita atravs de ponteiros em
C++.

CAluno CTurma
codigo

Nome
ender
class CTurma
{
char codigo[8];
CAluno *aluno[45];

...
};
0..45

Figura IV.9 Exemplo de agregacao por composicao.

Pg.: 52
3 Generalizao/Especializao de Classes

3.1 Notao UML

A generalizao ou especializao um relacionamento que ocorre efetivamente em termos
estruturais entre duas classes. Das duas classes envolvidas, uma ser considerada uma
classe base (ou superclasse) e a outra ser considerada uma classe derivada (ou subclasse).
O significado deste relacionamento depende do sentido de leitura da relao. Lendo-se a
relao no sentido da classe base para a classe derivada entende-se a relao como uma
especializao, ou seja, a classe derivada seria uma classe especial definida a partir da classe
base. Lendo-se a relao no sentido da classe derivada para a classe base, entende-se a
relao como uma generalizao, ou seja, a classe base representa um caso geral da classe
derivada.
Independentemente do significado da relao, a implementao da generalizao ou
especializao ocorre sempre na forma de uma herana da classe base para a classe
derivada. A herana um processo atravs do qual a classe derivada incorpora em seu interior
todos os atributos e mtodos da classe base. A classe derivada pode incluir atributos e
mtodos adicionais alm daqueles herdados da classe base. Note que a herana diferente da
agregao no sentido em que na agregao inclua-se um objeto dentro do outro preservando-
se o objeto que foi includo. Na herana a classe base no se mantm no interior da classe
derivada. Apenas os atributos e mtodos so incorporados dentro da classe derivada onde
passam a ser considerados como atributos e mtodos normais.
A notao UML para generalizao ou especializao um segmento de reta ligando as
classes, com um tringulo colocado no extremo da classe base. A figura IV.10 ilustra um
relacionamento de generalizao entre as classes CAutomovel e CCarro e apresenta o cdigo
C++ correspondente. Observe que no cdigo C++, na especificao da classe derivada
(CCarro) que se define a herana. Neste exemplo, um objeto da classe CCarro teria, alm dos
atributos n_portas e placa, todos aqueles da classe CAutomovel. O mesmo ocorreria para os
mtodos.

CAutomovel
modelo
fabricante
ano
cor

class CAutomovel
{ char modelo[30];
char fabricante[30];
int ano;
char cor;
public:
DefineAuto(char,char,char,int);
};

class CCarro::public CAutomovel
{ int n_portas;
int placa;
public:
DefineCar(char,char,char,int,int,int)
};

DefineAuto(char,char,char,int)
CCarro
n_portas
placa


Figura IV.10 Exemplo de heranca.
Observe que para relacionamentos de herana no necessrio definir um nome pois a
interpretao do relacionamento nica e por conseqncia o nome torna-se desnecessrio.
De forma semelhante, no se especifica cardinalidade para relacionamentos de herana pois
ela sempre uma relao de uma nica classe para outra classe.

Pg.: 53

3.2 Herana Mltipla

A herana mltipla ocorre quando uma classe deriva de mais de uma classe base. Mantm-se
exatamente os mesmos princpios da herana porm a classe derivada passa a incorporar em
seu interior os atributos e mtodos de mais de uma classe base. A figura IV.11 ilustra o cdigo
e notao UML para uma herana mltipla.

CAutomovel
modelo
fabricante
ano
cor

class CAutomovel
{ char modelo[30];
char fabricante[30];
int ano;
char cor;
public:
DefineAuto(char,char,char,int);
};

class CBemMovel
{ int numPatrimonio;
float preco;
int depreciacao;
int anoCompra;
public:
DefineBem(int, float, int, int);
};

class CCarro::public CAutomovel, public
CBemMovel
{ int n_portas;
int placa;
public:
};

DefineAuto()
CCarro
n_portas
placa

DefineCar()
CBemMovel
numPatrimonio
preco
depreciacao
anoCompra

DefineBem()

Figura IV.11 Exemplo de heranca mltipla.

O conceito de generalizao se perde, em parte, no caso da herana mltipla pois cada classe
base no representa mais um caso geral de toda a classe derivada, mas sim um caso geral de
uma parte da classe derivada. No exemplo da figura IV.11 no se pode mais afirmar que a
classe CAutomovel seja uma generalizao completa de CCarro. CAutomovel , na verdade,
uma generalizao parcial pois s considera aspectos especficos de CCarro. O conceito de
especializao se matm na herana mltipla. No exemplo da figuta IV.11, CCarro um caso
especial de CAutomovel e tambm um caso especial de CBemMovel.

3.3 Levantamento de Generalizaes

O levantamento da generalizaes apropriadas para um determinado sistema envolve um
trabalho de anlise e de abstrao sobre as classes. Existem duas formas principais de se
estabelecer generalizaes em um sistema, conforme descrito abaixo:

Identificao de partes comuns entre classes
Comparando-se classes, pode-se peceber que duas ou mais possuem partes (atributos e/ou
mtodos) em comum. Quando estas partes em comum possuem uma dimenso considervel
(por exemplo, representam mais da metade da classe) e ao mesmo tempo as partes em
comum definem a essncia das classes, pode-se criar uma classe base contendo as partes
comuns e utilizar herana para integr-las nas classes derivadas. A classe base definiria, neste
caso, uma classe geral para as classes derivadas. Este exatamente o raciocnio da
generalizao, tomar classes especfica e tentar estabelecer classes mais gerais.
Pg.: 54
Sntese de classes base
Outra forma de definio de relacionamentos de herana realizar a concepo das classes a
partir de classes abstratas. Estas classes representariam, sempre, solues gerais. A seguir,
atravs de um raciocnio de especializao, classes mais especficas seriam geradas atravs
da herana. Este procedimento de sntese de classes base freqntemente utilizado quando
controem-se bibliotecas de classes. A maior parte das classes nestas bibliotecas so classes
gerais utilizadas para criao de classes derivadas.
Na prtica, utilizam-se as duas abordagens descritas durante os projetos de software
orientados a objetos.

4 Concluso

Neste captulo fez-se uma apresentao resumida dos relacionamentos entre classes em
softwares orientados a objetos. Um bom conhecimento do significado e aplicao destes
relacionamentos absolutamente necessrio para os projetistas de software. Os
relacionamentos entre classes fazem parte da definio da estrutura do sistema e sero
mapeados diretamente em cdigo durante a fase de programao. , portanto, necessrio que
todos os relacionamentos estejam corretamente definidos dentro do projeto do sistema.

Os relacionamentos de associao podem, em grande parte, ser obtidos a partir do estudo dos
relacionamentos entre objetos feito atravs de diagramas de seqncia e colaborao. Os
relacionamentos de agregao e herana exigem uma reflexo sobre a constituio das
classes de forma a que se possa identificar partes comuns e partes destacveis.

Pg.: 55

Os estudos e especificaes feitos at este ponto permitiram definir a estrutura do
sistema computacional. Basicamente, definiu-se os componentes do sistema (classes) e
seus relacionamentos. Para cada classe definiu-se um conjunto inicial (mas talvez ainda
incompleto) de atributos e mtodos. Embora estas informaes j permitam a codificao
(programao) do esqueleto do sistema, elas so ainda insuficientes para a codificao
do interior das classes (dos mtodos em particular).
De fato, necessrio desenvolver algum estudo sobre o comportamento interno das
classes de maneira a permitir a especificao da dinmica, ou seja, da forma como os
objetos de cada classe se comportam. Isto corresponde a uma especificao de como as
classes devem ser implementadas.

1 Diagrama de Estados

Segundo a UML, a especificao da dinmica do sistema deve ser feita atravs de
diagramas de estados. Constri-se um diagrama de estados descrevendo o
comportamento de cada classe e eventuais diagramas complementares para descrever a
dinmica de todo o sistema ou de certos mdulos. Deve-se observar que, no caso das
classes, o diagrama de estados deve reunir o comportamento de uma classe com todas
as suas responsabilidades, ou seja, com o seu comportamento completo em todos os
casos de uso. Desta forma, o diagrama de estados de uma classe uma descrio global
do comportamento dos objetos desta classe em todo o sistema.

1.1 Notao Bsica

A UML utiliza como notao para diagramas de estados a notao proposta por Harel.
Nesta notao, um diagrama de estados um grafo dirigido cujos nodos representam
estados e cujos arcos representam transies entre estados. Estados so representados
graficamente por elipses ou retngulos com bordas arredondadas e transies so
representadas por segmentos de retas dirigidos (com uma seta em uma das
extremidades). Descreve-se a seguir os conceitos de estado e transio de estado.

Estado de um Objeto
Um estado pode ser entendido como um momento na vida de um objeto. Neste
momento (ou estado) o objeto encontra-se em uma certa situao. Assim, ao
longo da vida de um objeto, desde sua criao at seu desaparecimento, ele pode
passar por vrios momentos diferentes: momento em que foi criado, momento em
que fez uma inicializao, momento em que fez uma certa solicitao, etc at o
momento de seu desaparecimento. Dito de forma anloga, um objeto ao longo de
Capt ulo 5 : Def i ni ao da Di nmi ca
dos Obj et os
Pg.: 56
sua vida passa por um conjunto de diferentes estados. Nos diagramas de estados
procura-se descrever este conjunto de estados e seu encadeamento.
Os estados em um diagrama de estados so identificados por um nome. O nome
pode ser uma palavra ou um conjunto de palavras que descreva adequadamente a
situao representada pelo estado. Com alguma freqncia, os estados so
identificados com nomes comeados por um verbo no gerndio ou particpio.
Deve-se observar que um mesmo estado pode ser repetido em um diagrama de
estados. Neste caso os nomes se repetem em mais de um posio do diagrama.
Existem duas notaes grficas especiais para dois estados particulares
existentes em diagramas de estados. Utiliza-se a notao de um crculo
preenchido para indicar o estado inicial do diagrama de estados. O estado inicial
um estado de partida do objeto. Pode-se entender que ele representa o momento
de criao ou alocao do objeto. Utiliza-se a notao de dois crculos
concntricos para representar o estado final de um objeto. O estado final
representa o momento de destruio ou desalocao do objeto.
Exemplos de estados de um objeto :
Calculando
Valor
Dados
Recebidos
Estado Inicial Estado Final Estados Intermedirios

Figura V.1 Exemplos de estados de um objeto.

Transio de Estado
Como se pode deduzir do conceito de estado, um objeto no fica
permanentemente em um nico estado. Os objetos tendem a avanar de um certo
estado para algum outro medida que executem seus processamentos. Este
avano de uma situao (estado) para outra denomina-se uma transio de
estado. Assim, em um diagrama de estados descreve-se o conjunto de estados de
um objeto e tambm o conjunto de transies de estados existentes. Observe que
a partir de um certo estado do objeto ele s pode evoluir para certos estados
(normalmente, no para todos os outros) criando assim caminhos que
representam o ou os fluxos de execuo daquele objeto.
Uma transio pode possuir um rtulo com a seguinte sintaxe :

Evento : indica o nome de um sinal, mensagem ou notificao recebida pelo
objeto e que torna a transio habilitada podendo, por conseqncia,
ocorrer levando o objeto a um novo estado. Exemplos de eventos so: o
recebimento de uma mensagem encaminhada pelo sistema operacional,
o recebimento de uma notificao (timer, interrupo, entrada de dados)
gerada pelo sistema operacional e a chamada de uma funo feita por
outro objeto.
Evento(Argumentos) [Condio] / Ao
Pg.: 57
Argumentos : so valores recebidos junto com o evento.
[Condio] : uma expresso lgica que avaliada quando o evento, se houver,
associado a uma transio ocorrer. Uma transio s ocorre se o evento
acontecer e a condio associada for verdadeira.
/ Ao : indica uma ao (clculo, atribuio, envio de mesagem, etc) que
executada durante a transio de um estado a outro.

A figura V.2 ilustra um diagrama de estados com cinco estados e quatro
transies. Observe que as duas transies mais esquerda e a transio
direita no possuem nenhum rtulo. Por conseqncia, estas transies ocorrem
imediantamente aps a realizao das eventuais aes associadas aos estados
imediatamente anteriores. A terceira transio possui como rtulo o nome de um
evento chamado dados. Este evento representa a chegada de dados de algum
canal de entrada (teclado por exemplo) notificada pelo sistema operacional. Neste
caso, a transio s ocorrer quando o evento dados acontecer. Enquanto o
evento no acontecer, o objeto permanecer no estado anterior que
Aguardando Dados. Note que comum nomear o estado anterior a uma
transio com evento utilizando-se um verbo no gerndio e nomear o estado
seguinte com um verbo no particpio como no exemplo da figura V.2.

Mostrando
Janela
Dados
Recebidos
Aguardando
Dados
dados

Figura V.2 Exemplos de transies de estados.

1.2 Fluxo de Estados e Transies

A partir das primitivas Estado e Transio pode-se construir uma grande variedade de
diagramas de maior ou menor complexidade. Os encadeamentos de estados e transies
podem estabelecer certas construes tpicas como descrito a seguir.

Seqncias
Seqncias so fluxos de estados representados por encadeamentos de um estado e
uma transio. O comportamento do objeto segue, por conseqncia, uma srie de
estados bem determinados. O diagrama na figura V.2 descreve um fluxo seqencial
de estados e transies. As transies podem ou no possuir rtulos com eventos,
condies e aes.

Bifurcaes e Junes
Uma bifurcao representada por duas ou mais transies partindo de um mesmo
estado. Nesta situao, tem-se mais de uma possibilidade de continuao do fluxo
comportamental do objeto. A partir do estado de bifurcao, o objeto poderia alcanar
algum outro estado conforme a transio que ocorrer. Uma juno representada por
duas ou mais transies conduzindo a um mesmo estado. A figura V.3 ilustra um
exemplo de diagrama de estados com bifurcao e juno.
Pg.: 58
Mostrando
Janela
Dados
Recebidos
Aguardando
Dados
dados
Mostrando
Mensagem
fim

Figura V.3 Exemplo de bifurcacao e juncao em diagrama de estado.
Deve-se ter especial ateno na definio das bifurcaes de forma a evitar conflitos.
Um conflito ocorre quando duas ou mais transies partindo de um mesmo estado
esto em habilitadas. Neste caso, existe uma indefinio sobre o comportamento do
objeto. Para evitar conflitos, deve-se assegurar que as condies para ocorrncia de
cada transio so mutuamente exclusivas. A figura V.4 ilustra dois casos de conflito.
No diagrama esquerda, duas transies sem rtulo partem de um mesmo estado
indicando claramente um conflito. No diagrama direita, tem-se condies nas duas
transies mas estas condies no so mutuamente exclusivas. Quando o valor da
varivel x for igual 10 existir um conflito.
Mostrando
Janela
Dados
Recebidos
Aguardando
Dados
Mostrando
Mensagem
conflitos
Mostrando
Janela
Gravando
Aguardando
Dado
Mostrando
Mensagem
[X<11] [X>9]

Figura V.4 Exemplos de conflito entre transices.

Repeties
Uma repetio ou lao representado por um encadeamento cclico de estados e
transies contendo, na maioria dos casos, alguma forma de controle sobre a
repetio dos ciclos. A figura V.5 ilustra um diagrama de estados com uma repetio.
Neste exemplo os trs estados sero alcanados vrias vezes at que o valor da
varivel de controle x ultrapasse o valor 10.
[x>10]
[x<=10] /x++
Mostrando
Janela
Dados
Recebidos
Aguardando
Dados
dados /x=0

Figura V.5 Exemplo de repeticao em um diagrama de estados.
Pg.: 59
1.3 Notao Complementar

Clusula de Envio
Uma clusula de envio uma ao de envio de uma mensagem do objeto que se est
modelando para algum outro objeto. O envio da mensagem pode ser sncrono (como
no caso de chamadas de funes) ou assncronos (como no envio de mensagens via
sistema de mensagens).
Em diagramas de estados, indica-se que o objeto est enviando uma mensagem a
outro objeto colocando-se uma clusula de envio como uma ao em uma transio.
Como notao para especificao da clusula de envio coloca-se um acento
circunflexo seguido do nome do objeto e do nome da mensagem separados por um
smbolo de ponto.

A figura V.6 mostra um exemplo de diagrama de seqncia e de um diagrama de
estados da classe CCtrl com as mensagens enviadas.

Inicializando
Comunicao
Iniciando
Processo
Processo
Encerrado
înterf.Inicializar
înterf.Processar
:CCtrl interf:CInterf
Inicializar
Processar
Classe : CCtrl

Figura V.6 Exemplos de clusulas de envio.

Transies Reflexivas
Uma transio reflexiva uma transio que parte de um estado e alcana o mesmo
estado de partida. Transies reflexivas representam situaes em que ocorre algum
evento ou alcana-se alguma condio a partir de um determinado estado produzindo,
eventualmente, alguma ao mas sem afetar o estado no qual o objeto se encontra.
Transies reflexivas podem ser utilizadas tambm para indicar que o objeto recebe
certas mensagens ou percebe certos eventos sem, entretanto, alterar seu estado
comportamental. A figura V.7 ilustra um caso de transio reflexiva.
^nome-do-objeto.nome-da-mensagem

Pg.: 60
reiniciar / flag=false iniciar
Aguardando Processando Inicializado
fim iniciar processar

Figura V.7 Exemplo de transices reflexivas.

Aes nos Estados
Como visto at este ponto, pode-se especificar aes em um diagrama de estados
indicando-as junto s transies de estado. Outra possibilidade incluir a
especificao de aes no interior dos estados. A definio das aes no interior de
um estado significa que sempre que aquele estado for alcanado, as aes sero
realizadas. Graficamente, divide-se o retngulo de representao de um estado em
dois compartimentos: o compartimento de identificao, que contm o nome do
estado, e o compartimento das aes com a lista das aes realizadas no interior do
estado. Para cada ao existe um prefixo indicando a categoria da ao conforme
descrito a seguir.
Categorias de aes :
Entrada : uma ao de entrada uma ao realizada exatamente no momento em
que se alcana o estado. Esta ou estas aes so realizadas antes de qualquer outra
ao. Na verdade, aes de entrada seriam aes que estariam nas transies que
conduzem a certo estado e que, por conseqncia, seriam executadas antes de se
alcanar efetivamente o estado. Note que colocando-se uma ao de entrada
entende-se que ela ser executada independente da transio que conduz ao estado.
A figura V.8 mostra um exemplo com dois diagramas de estados equivalentes onde
esquerda especifica-se uma ao nas transies e no outro especifica-se a mesma
ao no interior do estado.
Processando
Dados
Recebidos
Mostrando
Mensagem
entrada/ x=0
Dados
Recebidos
Mostrando
Mensagem
x=0
Processando
x=0

Figura V.8 Exemplo de definicao de acao de entrada.

Sada : uma ao de sada uma ao realizada exatamente no momento de
abandono de um estado. Aes de sada seriam aes que estariam em todas as
transies que partem de um determinado estado. A figura V.9 ilustra a especificao
de uma ao de sada.
Pg.: 61
Processando
sada/ x=0
Dados
Recebidos
Mostrando
Mensagem
evento a
/x=0
Processando
evento b
/x=0
Dados
Recebidos
Mostrando
Mensagem
evento a evento b

Figura V.9 Exemplo de definicao de acao de sada.

Fazer : o prefixo fazer (em ingls, do) permite especificar uma atividade no atmica
(composta por mais de uma instruo) realizada no interior do estado. Isto significa
que quando o objeto alcanar o estado e tiver concludo as eventuais aes de
entrada, ele passar a executar a atividade indicada enquanto permanecer neste
estado.

Evento : uma ao prefixada com um nome de evento ser realizada quando o objeto
estiver no estado correspondente e ocorrer o evento indicado. Como o evento
tratado sem mudana de estado pode-se considerar este tipo de especificao
equivalente s transies reflexivas com aes. possvel utilizar-se tambm a
palavra reservada difer (diferir) no lugar da ao. Neste caso, entende-se que se o
evento ocorrer ele ser diferido para tratamento posterior. Isto equivaleria a uma
bufferizao do evento para tratamento posterior.

Estados Compostos
Um estado composto um estado constitudo de um conjunto de subestados. Cada
subestado pode, por sua vez, ser tambm um estado composto constitudo por
subestados. Utiliza-se o conceito de estado composto para construes
hierarquizadas que apresentam nos nveis iniciais, estados maiores (mais abstratos) e
em nveis seguintes estados mais especficos (menos abstratos).
Os subestados so encadeados no interior de um estado composto na forma de um
diagrama de estado. Desta forma, tem-se um estado inicial, estados intermedirios e
um estado final. A figura V.10 ilustra um estado composto mostrado seus subestados
interiores. Note que esta ilustrao mostra uma viso expandida do diagrama de
estados. Em uma viso normal, o estado composto Processando Entrada de Dados
seria mostrado sem seus subestados.
Aguardando Processando
dados
Processando Entrada de Dados
Inicializando
Finalizando
Figura V.10 Exemplo de estado composto.
Pg.: 62
1.4 Concorrncias
Estados compostos podem descrever em seu interior concorrncias. Estas concorrncias
representam dois ou mais encadeamentos de estados e transies que so percorridos
simultaneamente. Em termos de programao, a concorrncia dentro de um objeto
significa que ele possui mais de um fluxo de controle implementado atravs de threads e
utilizando servios de multitarefa ou multiprocessamento do sistema operacional.
A representao de concorrncia se faz atravs da diviso de um estado composto em
regies que so separadas por linhas tracejadas. Cada regio descreve um fluxo
concorrente atravs de um subdiagrama de estados. A figura V.11 ilustra um estado
composto com uma concorrncia entre dois encadeamentos de estados.
Existem dois pontos de sincronismo explcitos em estados compostos com concorrncia.
O primeiro representado pelo estado inicial. Quando um objeto alcana o estado
composto, imediatamente abre-se a concorrncia alcanando-se igualmente os estados
iniciais de todas as concorrncias. A partir deste ponto perde-se o sincronismo das
concorrncias pois cada uma ir evoluir no encadeamento de seus subestados conforme
as condies que se apresentarem. O segundo ponto de sincronismo explcito entre as
concorrncias est no estado final de cada uma. O estado composto s poder evoluir
para estados seguintes quando todas as suas concorrncias tiverem alcanado seus
estados finais. Dito de outra forma, aguarda-se que todas as concorrncias alcancem
seus estados finais para que o objeto possa evoluir do estado composto atual para algum
prximo estado.

Estado 1a Estado 1b
Estado Composto
Estado 2a Estado 2b

Figura V.11 Exemplo de concorrencia em um estado composto.

Em algumas circunstncias pode ser desejado estabelecer sincronismos entre os estados
intermedirios de duas ou mais concorrncias. Isto representaria uma dependncia de
estado entre as concorrncias. Uma dependncia de estado significa que alguma
transio de estado em uma concorrncia depende do estado em que se encontra outra
concorrncia. A notao UML para indicar sincronismo de estados a de um estado
especial de sincronismo representado por um crculo colocado sobre a linha tracejada de
diviso de concorrncias. Na verdade, o estado de sincronismo no deve ser interpretado
Pg.: 63
verdadeiramente como um estado mas sim como um contador ou fila agindo como uma
condio.
A figura V.12 ilustra a notao para sincronismo entre concorrncias. O crculo sobre a
linha tracejada indica um estado de sincronismo. O nmero 1 dentro do estado indica a
capacidade de armazenamento de marcas de sincronismo no estado (corresponderia ao
limite do contador). No exemplo, sempre que o estado 1a for alcanado e concluir suas
aes, uma marca ser colocada no estado de sincronismo, ou seja, o contador ser
incrementado. O estado 1a um estado especial pois representa uma disjuno (um
fork) atravs da qual as duas transies seguinte ocorrem. Sempre que a transio entre
os estados 2a e 2b ocorrer, uma marca ser retirada do estado de sincronismo, ou seja, o
contador ser decrementado. Quando o estado de sincronismo j contiver o nmero
mximo de marcas, as transies seguintes ao estado 1a no podero mais ocorrer at
que alguma marca seja retirada do estado de sincronismo. Neste caso, o contador teria
alcanado seu limite mximo. A transio entre os estados 2a e 2b no poder ocorrer se
no houverem marcas no estado de sincronismo pois o estado 2b depende do sinal de
sincronismo representado por uma marca no estado de sincronismo.
Para representar capacidade infinita para a capacidade do estado de sincronismo utiliza-
se o smbolo * no interior do estado. Neste caso, o contador pode ser incrementado
infinitamente (pelo menos teoricamente).

Estado 1b
Estado Composto
Estado 2a Estado 2b
Estado 1a
e
1

Figura V.12 Exemplo de sincronismo entre concorrencias.

1.5 Exemplos de Diagramas de Estados

Nesta seo sero apresentados trs exemplos de diagramas de estados com o propsito
de ilustrar a aplicao deste tipo de diagrama. Considera-se nestes exemplos apenas o
diagrama de seqncia da figura II.16.

Pg.: 64
Diagrama de estados da classe CDiarioClasse

Inicializando Pronto
Disciplina
Registrada

Aluno
Registrado
Aluno
Acessado

Disciplina
Acessada

Pronto
destruir
RegistrarDisciplina()
RegistrarAluno() AcessarDisciplina()
AcessarAluno()
Registrando
Disciplina
Registrando
Aluno
Acessando
Aluno
Acessando
Disciplina
Registrando
Professor
Registrando
Disciplina
^CDisciplina.Registrar
(cod, nome, ch)
^CProfessor.Registrar
(nome)
^CAluno.Registrar
(cod, nome)
^CDisciplina.Acessar
(cod, nome, ch)
^CProfessor.Acessar
(nome)
^CAluno.Acessar
(cod, nome)
Figura V.13 Diagrama de estados para a classe CDiarioClasse

Diagrama de estados da classe CInterfSGBD

Inicializando Pronto
Acessando
Aluno
Registrando
Aluno
destruir
BuscarDisciplina(c,d)
Acessando
Disciplina
Armazenando
Dados
n, ch, prof
/^CDiarioClasse.RegistrarDisciplina(c,n,ch,prof)
Verificando
Dados
cod, nome
[cod!=NULL]
/^CDiarioClasse.RegistrarAluno(c,n)
Pronto
[cod=NULL]

Figura V.14 Diagrama de estados para a classe CInterfSGBD
Pg.: 65
Deve-se notar que o diagrama de estados da Figura V.14 est provavelmente
incompleto pois s se considerou o caso de uso Emitir Dirio de Classe.

Diagrama de estados da classe CctrlEmitirDiario

/^CInterfSecretaria.MostrarMagFimDiario(d)
Inicializando
Mostrando
Janela
Mostrando
Msg Fim
Concludo
/^CInterfSecretaria.MostrarJanDiario()
Acessando
Disciplina
Imprimindo
Diario
/^CInterfSGBD.BuscarDisciplina(c,d)
/^CInterfImp.ImprimirDiario(d)

Figura V.15 Diagrama de estados para a classeCEmitirDiario.

2 Diagramas de Atividades

2.1 Notao Bsica

Um diagrama de atividades um diagrama de estado no qual considera-se que todos ou
a grande maioria dos estados representam a execuo de aes ou atividades. A notao
UML para diagramas de atividades utiliza as mesmas primitivas dos diagramas de
estados e inclui algumas notaes adicionais.

As novas primitivas includas nos diagramas de atividades so:

Estado de Bifurcao e de Convergncia
Um estado de bifurcao um estado do qual partem duas (eventualmente mais)
transies. Estados deste tipo so representados em diagramas de atividades utilizando-
se uma notao especial na forma de um losango. Observe que para evitar um conflito
entre as transies necessria a colocao de condies ou eventos mutuamente
exclusivos nas transies. A figura V.16 ilustra um diagrama de estados com um estado
de bifurcao.
A mesma notao utilizada para estados de bifurcao pode ser utilizada para estados de
convergncia. Um estado de convergncia um estado que possui mais de uma
transio de entrada representando, desta forma, um ponto de juno de fluxos
alternativos dentro de um diagrama de estados. A figura V.16 ilustra um estado de
convergncia.
Pg.: 66
Esperando
Opo
Iniciando
Processo1
Processo1
Encerrado
opcao
înterf.Processo1
Iniciando
Processo2
Processo2
Encerrado
înterf.Process2
Encerrando
Ativao
[opcao=2] [opcao=1]
Estado de Convergncia
Estado de Bifurcao

Figura V.16 Exemplo de estados de bifurcacao e de convergencia.

Sincronismo de Concorrncias
Os diagramas de atividade empregam uma nova notao permitindo a especificao de
sincronismo de concorrncias. A mesma notao, na forma de uma barra preenchida,
utilizada tanto para abertura de sincronismo quanto para sincronismo de concorrncias.
Na abertura, entende-se que os fluxos seguintes avanaro concorrentemente. O
sincronismo de encerramento de concorrncias representa um ponto de aguardo at que
todos os fluxos concorrentes alcancem o ponto de sincronismo. A figura V.17 ilustra um
diagrama de atividades com concorrncia.

Pg.: 67

Inicializando
Iniciando
Processo1
Processo1
Encerrado
Iniciando
Processo2
Processo2
Encerrado
Encerrando
Ativao
Sincronismo de Fim de
Concorrncia
Abertura de concorrncia

Figura V.17 Exemplo de abertura e sincronismo de encerramento de concorrencias.

2.2 Notao Complementar

Recebimento de mensagens ou sinais
A UML oferece uma notao alternativa para especificao de situaes de recebimento
de mensagens ou sinais. Utiliza-se um pentgono cncavo com o nome da mensagem ou
sinal em seu interior. Pode-se denominar este pentgono como sendo um estado de
recebimento de sinal. Esta notao utilizada no lugar de apenas uma transio com o
nome da mensagem ou sinal. Opcionalmente, pode-se incluir, prximo ao estado de
recebimento de sinal, o objeto gerador do sinal ligado ao estado atravs de um seta
tracejada. A figura V.18 apresenta uma ilustrao que compara a representao normal
de recebimento de sinal e a notao atravs de estado de recebimento.

Pg.: 68
Pronto
Iniciando
Processo
Processando
Processar
Encerrando
Ativao
Estado de recebimento
Parar
controle
Objeto de origem do sinal
Pronto
Iniciando
Processo
Processando
Processar
Encerrando
Ativao
Parar

Figura V.18 Exemplo da notacao UML para estado de recebimento de sinal.

Envio de mensagens ou sinais
De forma semelhante ao estado de recebimento de sinal, a UML oferece uma notao
especial para representar situaes de envio de mensagens ou sinais. Utiliza-se um
pentgono convexo com o nome do sinal no interior para representar esta situao. Pode-
se entender esta representao como um estado de envio de sinal. Opcionalmente, pode-
se especificar o objeto de destino do sinal. A figura V.19 ilustra a notao UML para
estado de envio de sinal.
Pronto
Iniciando
Processo
Processando
Processar
Encerrando
Ativao
Estado de envio
Encerrar controle
Objeto de destino do sinal
Pronto
Iniciando
Processo
Processando
Processar
Encerrando
Ativao
^controle.Encerrar

Figura V.19 Exemplo da notacao UML para estado de envio de sinal.
Pg.: 69

3 Concluso

Neste captulo apresentou-se a notao utilizada na UML para a modelagem da dinmica
interna de objetos. Essencialmente, utiliza-se a notao de Harel para diagramas de
estados.

A principal utilizao dos diagramas de estados a modelagem individual do
comportamento dos objetos de cada classe. O modelo construdo permite estudar e
especificar o comportamento dos objetos e serve como referncia para sua codificao na
fase de implantao.

Em muitos aspectos a notao por diagramas de estados se assemelha a notao
procedural (como os fluxogramas e diagramas de ao). Os diagramas de estados,
entretanto, so mais poderosos pois incluem notaes especficas para comunicao
entre objetos (como as clusulas de envio), para concorrncias e para nveis de
abstrao.


0 - Apostila UML Completa I

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

0 - Apostila UML Completa I

Enviado por

Direitos autorais:

Formatos disponíveis

Projeto de Software

Você também pode gostar