Livro Michel LiComp-UFJF v1.1

Universidade Federal de Juiz de Fora
Departamento de Cincia da Computao

Curso de Licenciatura em Computao
MODELAGEM DE
SISTEMAS
AUTORES:
MICHEL HELUEY FORTUNA
VERSO 1.0
AGOSTO DE 2012
Direitos: Esta obra foi disponibilizada sob uma Licena Creative Commons Atribuio Uso no-comercial 3.0
Brasil.
Direitos de distribuio e publicao: CAPES/MEC, conforme Pargrafo nico, do Artigo 5, da Resoluo
CD/FNDE n 24 de 04 de Junho de 2008.
Universidade Federal de Juiz de Fora

Reitor: Henrique Duque de Miranda Chaves Filho
Instituto de Cincias Exatas
Diretor: Rubens de Oliveira
Departamento de Cincia da Computao
Chefe: Stnio S Rosrio Furtado Soares
Curso de Licenciatura em Computao
Coordenao: Fernanda Claudia Alves Campos
Organizao
Michel Heluey Fortuna
Comisso Editorial
Eduardo Barrre
Fernanda Claudia Alves Campos
Reviso Gramatical
Hortncia Cezar Pinto
Editorao Eletrnica
Eduardo Barrre
Fortuna, Michel Heluey.

Modelagem de Sistemas / Michel Heluey Fortuna 2012.
73 f. : il.
Material Didtico Curso de Licenciatura em Computao
da Universidade Federal de Juiz de Fora, Juiz de Fora, 2012.
1. Educao Distncia. 2. Engenharia de Software. 3.
Modelagem de Sistemas. 4. UML. 5. Orientao a Objetos. I.
Ttulo.
Apresentao
Este material de estudo versa sobre modelagem de sistemas,
especialmente, sistemas de software. Ele foi elaborado para servir de
apoio disciplina de mesmo nome, com carga horria de 30 horas,
do curso de Licenciatura em Computao da Universidade Federal
de Juiz de Fora (UFJF).
Uma vez que a disciplina-alvo deste material no tem pr-requisito
formal, o objetivo foi faz-lo autocontido. Isso significa, entre outras
coisas, que alguns conceitos de orientao a objetos, necessrios ao
entendimento do contedo aqui apresentado sobre modelagem,
foram incorporados ao longo do texto.
Apenas
uma
parte
do
rol
de
modelos
existentes
para
representao das diferentes vises de um sistema e, em particular,

do rol de modelos preconizados pela Unified Modeling Language
(UML), foi coberta aqui. Isso se deveu, principalmente, limitao de
carga horria da disciplina-alvo. Pelo mesmo motivo, nem todos os
detalhes dos modelos cobertos foram includos. De qualquer forma,
tanto os modelos cobertos, quanto os detalhes de cada um, esto
entre os mais bsicos, estveis e frequentemente utilizados no
desenvolvimento de software.
[Sobre o autor]
O autor deste material de estudo doutor em Engenharia de
Sistemas e Computao pela Universidade Federal do Rio de
Janeiro (COPPE/UFRJ) e professor do Departamento de Cincia da
Computao da Universidade Federal de Juiz de Fora (UFJF).
Durante um bom tempo atuou tambm como analista de sistemas
em empresas privadas e estatais. Sua principal rea de interesse a
modelagem de sistemas de informao.
Iconografia
Conhea os diversos cones utilizados nos materiais didticos desenvolvidos pelos
professores e tutores do curso de Licenciatura em Computao DCC/UFJF:
Pesquise.
Exerccios.
Material complementar
(texto, vdeo, etc.)
disponvel na Internet.
Leitura Complementar.
Comentrio do Autor.
Tome nota.
Concluso ou sntese
de contedo.
Fique atento.
Sumrio
1.
Introduo.................................................................................................................................... 9
O que so modelos? ................................................................................................................. 11
Linguagens x Modelos............................................................................................................... 12
O paradigma OO ....................................................................................................................... 13
UML ........................................................................................................................................... 14
2.
Modelo de Casos de Uso .......................................................................................................... 16

2.1.
Introduo........................................................................................................................... 16
2.2.
Diagrama de UCs ............................................................................................................... 17
2.3.
Descrio dos UCs............................................................................................................. 18
Sumrio ..................................................................................................................................... 19
Fluxo de Eventos ....................................................................................................................... 20
2.4.
Relacionamentos entre UCs............................................................................................... 22
Incluso ..................................................................................................................................... 23
Extenso.................................................................................................................................... 23
Consideraes sobre Include e Extend ..................................................................................... 24
Generalizao ........................................................................................................................... 26
3.
Diagrama de Classes de Objetos .............................................................................................. 29

3.1.
Introduo........................................................................................................................... 29
Classe Objeto ......................................................................................................................... 30

3.2.
Associaes entre classes ................................................................................................. 31
Associao reflexiva .................................................................................................................. 33

Classe de associao................................................................................................................ 34
Agregao e Composio ......................................................................................................... 34
Generalizao/especializao ................................................................................................... 37
4.
Diagrama de Estados ................................................................................................................ 39

4.1.
Introduo........................................................................................................................... 39
4.2.
Elementos de um DE.......................................................................................................... 41
Estados...................................................................................................................................... 41
Eventos...................................................................................................................................... 42
Transies ................................................................................................................................. 44
Atividades .................................................................................................................................. 44
Aes......................................................................................................................................... 45
Estados compostos e subestados sequenciais ......................................................................... 46
4.3.
5.
Relao com outros modelos ............................................................................................. 47
Diagrama de Sequncia ............................................................................................................ 49

5.1.
Introduo........................................................................................................................... 49
5.2.
DS DSS ........................................................................................................................... 49
5.3.
Elementos do DS................................................................................................................ 51
Linha de vida e barras de ativao............................................................................................ 51

Mensagens ................................................................................................................................ 52
Fragmentos de sequncia ......................................................................................................... 55
5.4.
6.
7.
Relao com os outros modelos ........................................................................................ 57
Diagrama de Comunicao ....................................................................................................... 58

6.1.
Introduo........................................................................................................................... 58
6.2.
Comparao com outros modelos...................................................................................... 59
6.3.
Comparao: DCom DS.................................................................................................. 60
6.4.
Traduzindo um DS em um DCom ...................................................................................... 61
Diagrama de Atividade .............................................................................................................. 63

7.1.
Introduo........................................................................................................................... 63
7.2.
Elementos do DA................................................................................................................ 65
Ao .......................................................................................................................................... 65
Transies ................................................................................................................................. 65
N objeto ................................................................................................................................... 65
N Incio da Atividade................................................................................................................ 66
Deciso e Aglutinao ............................................................................................................... 66
Ns de finalizao ..................................................................................................................... 67
Ramificao e Juno ............................................................................................................... 68
Evento temporal ........................................................................................................................ 69
Eventos externos ....................................................................................................................... 69
Subatividade .............................................................................................................................. 70
N conector ............................................................................................................................... 72
7.3.
Relao com outros modelos / diagramas ......................................................................... 72
Bibliografia ........................................................................................................................................ 73
Lista de Figuras e Tabelas

Figuras:
Figura 1.1: Como se constri (e se cobra por) software!?.................................................................. 9
Figura 1.2: Requisitos iniciais do Sistema Restaurante.................................................................... 11
Figura 1.3: Planta baixa (modelo) de uma residncia destacando uma janela ................................ 13
Figura 1.4: Diagramas da UML 2.4................................................................................................... 14
Figura 2.1: Exemplo de diagrama de casos de uso.......................................................................... 17
Figura 2.2: Nveis mais comuns de detalhamento na descrio de UCs ......................................... 19
Figura 2.3: Fluxo de eventos do UC Pagar a nota (Sistema Restaurante)....................................... 20
Figura 2.4: Fluxo de eventos do UC Abrir conta (sistema bancrio) ................................................ 21
Figura 2.5: Fluxo de eventos com alternativa (UC Pagar a nota)..................................................... 21
Figura 2.6: Representao do relacionamento de incluso entre UCs ............................................ 23
Figura 2.7: Representao do relacionamento de extenso entre UCs ........................................... 24
Figura 2.8: Efeito de A includes B sobre o fluxo de eventos dos UCs A e B.................................... 25
Figura 2.9: Efeito de A extends B sobre o fluxo de eventos dos UCs A e B .................................... 26
Figura 2.10: Representao do relacionamento de generalizao entre UCs ................................. 27
Figura 2.11: Exemplo de relacionamento generalizao entre dois UCs ......................................... 27
Figura 3.1: Exemplo de diagrama de classes de objetos ................................................................. 29
Figura 3.2: Uma classe (de objetos) Pessoa e um objeto dessa classe .......................................... 31
Figura 3.3: Associao, ligaes e multiplicidades........................................................................... 32
Figura 3.4: Associao reflexiva e papis ........................................................................................ 33
Figura 3.6: Exemplos de associaes do tipo agregao ................................................................ 35
Figura 3.7: Exemplos de associaes do tipo composio .............................................................. 35
Figura 3.8: Generalizao / especializao entre classes................................................................ 37
Figura 3.9: Metamodelo (parcial) de um DC..................................................................................... 38
Figura 4.1: DE de um sistema de porto de garagem automatizado ............................................... 39
Figura 4.2: Elementos de um DE e sua representao grfica ........................................................ 41
Figura 4.3: DE (protocolo) da classe Pedido do sistema Restaurante ............................................. 43
Figura 4.4: DE do negcio de um restaurante .................................................................................. 45
Figura 4.5: Estados civis de uma pessoa (utilizando estados compostos)....................................... 46
Figura 5.1: DS de sistema (DSS) Caso de uso Pedir a nota (sistema Restaurante)..................... 49
Figura 5.2: Diagrama de sequncia Caso de uso Pedir a nota (sistema Restaurante)................. 50
Figura 5.3: Linha de vida e barras de ativao................................................................................. 51
Figura 5.4: Tipos de mensagens ...................................................................................................... 52
Figura 5.5: Exemplo de utilizao de mensagem assncrona .......................................................... 53
Figura 5.6: Formas equivalentes de retorno de mensagem ............................................................. 54
Figura 5.7: Exemplos de fragmentos de sequncia.......................................................................... 56

Figura 5.8: Forma alternativa para fragmento opt simples ............................................................... 56
Figura 5.9: Forma alternativa para o fragmento loop simples .......................................................... 57
Figura 6.1: Exemplo de diagrama de comunicao (DCom) ............................................................ 58
Figura 6.2: Tipos de mensagens ...................................................................................................... 59
Figura 6.3: Respostas fora de ordem em mensagens assncronas ................................................. 60
Figura 6.4: DS a traduzir para DCom ............................................................................................... 61
Figura 6.5: Primeiro passo de traduo Objetos ........................................................................... 62
Figura 6.6: Segundo passo de traduo Ligaes ........................................................................ 62
Figura 6.7: Terceiro passo de traduo Mensagens ..................................................................... 62
Figura 7.1: Exemplo de diagrama de atividade (DA) venda por telefone ...................................... 64
Figura 7.2: Representao grfica dos ns e transies de um DA................................................. 65
Figura 7.3: (a) Combinao de aglutinao e deciso; (b) Significado da combinao ................... 67
Figura 7.4: (a) Combinao de juno e ramificao; (b) Significado da combinao..................... 68
Figura 7.5: Exemplo de evento temporal recorrente......................................................................... 69
Figura 7.6: Envio e recebimento de sinais........................................................................................ 69
Figura 7.7: Espera desde o incio da atividade................................................................................. 70
Figura 7.8: Exemplo de utilizao do n de subatividade Subatividade Libera pedido ................. 71
Figura 7.9: DA da subatividade Libera pedido.................................................................................. 71
Figura 7.10: Utilizao de conector em um DA ................................................................................ 72
Tabelas:
Tabela 3.1: Comparao entre agregao e composio ................................................................ 36
Tabela 5.1: Exemplos vlidos de mensagens (sintaxe).................................................................... 55
Tabela 5.2: Alguns operadores de fragmentos de sequncia .......................................................... 55
Tabela 6.1: Comparao entre o DCom e o DS ............................................................................... 60
Modelagem de Sistemas
1.
Captulo 1: Introduo
Introduo
Observe atentamente a Figura 1.1 abaixo; o que ela lhe diz?
Figura 1.1: Como se constri (e se cobra por) software!?1

A primeira reao figura acima pode ser rir... De fato, ela engraada! Mas logo se
percebe o quanto ela reflete a realidade dos problemas enfrentados por aqueles que se
envolvem com a tarefa de desenvolver um sistema computacional, com o seu componente
de software. Eu mesmo j acompanhei diversos projetos de desenvolvimento de software e
pude observar muitos desses problemas. Nas prximas linhas vou tentar expressar o que
essa figura me diz ou recorda, com base na minha experincia como analista de sistemas.
Meu objetivo que voc conhea e saiba utilizar o ferramental descrito neste material de
estudo, pois ele poder lhe ajudar a resolver, ou pelo menos contornar, parte das
dificuldades enfrentadas por todos que se dedicam a desenvolver software.
O processo de desenvolvimento de software envolve a participao de, pelo menos,
dois grupos distintos de profissionais, normalmente com formao muito distinta: o grupo
dos clientes ou usurios (do futuro sistema) e o grupo dos desenvolvedores. O grupo dos
usurios costuma envolver pessoas das mais diversas reas de atuao profissional, tais
como, administradores, engenheiros, profissionais de sade, de educao, tcnicos, etc. O
outro grupo, o dos desenvolvedores, normalmente tem formao em computao so,
principalmente, os analistas de sistemas e os programadores. Os analistas consultam os
clientes e projetam um sistema para atend-los e os programadores elaboram o software
necessrio ao funcionamento do sistema.
1
Autoria desconhecida.
Captulo 1: Introduo
O cliente nem sempre tem uma ideia clara do que seria uma soluo adequada para
as suas necessidades. Como todo profissional, ele est em contnuo processo de
aprendizagem, procurando melhorar suas prticas e obter solues que atendam essas
necessidades. Alm disso, com raras excees, o cliente no est a par de todas as
possibilidades que as tecnologias de informao, comunicao e computao oferecem.
Portanto, o analista no deve aceitar passivamente tudo o que ele prope, mas sim
investigar em parceria com o seu cliente, a qualidade da soluo sugerida por ele e, juntos,
confirmar, aperfeioar, ou eventualmente chegar a outro tipo de soluo. Se o analista no
adotar essa atitude proativa na definio do sistema, ele corre o srio risco de projetar um
sistema incapaz de atender os propsitos do cliente. Infelizmente, esse erro muito comum
entre analistas inexperientes.
Essa parceria entre cliente e analista pressupe alguns requisitos bsicos, dos quais, o
mais importante talvez seja que exista uma linguagem comum capaz de permitir uma
comunicao efetiva entre as diferentes categorias de profissionais envolvidos. Em
primeiro lugar, essa linguagem deve incluir os termos e conceitos do domnio de trabalho
do cliente, para que o analista possa entender os problemas que o cliente enfrenta e espera
ver resolvidos com o sistema a ser desenvolvido. No entanto, essa linguagem comum
tambm precisa incluir termos, conceitos e estruturas prprias das tecnologias de
informao, comunicao e computao, para que o cliente possa acompanhar e contribuir
com o analista, na busca pela soluo de software capaz de atender plenamente os seus
anseios. nesse requisito que o material ora apresentado para estudo pode contribuir. Ele
apresenta uma proposta de linguagem, que parte de uma linguagem maior padronizada
mundialmente sob a denominao de UML (Unified Modeling Language), a ser utilizada
no levantamento das necessidades dos clientes, na anlise dessas necessidades e no projeto
de uma soluo para atend-las. Com essa linguagem, os analistas constroem modelos que
vo sendo aperfeioados e detalhados aos poucos, parte deles com a ajuda dos clientes, at
refletirem com razovel preciso o sistema a ser construdo. Depois, esses modelos so
entregues aos programadores para que eles desenvolvam o software conforme projetado.
Erros introduzidos na definio de um sistema repercutem negativamente em todas
as etapas posteriores do seu desenvolvimento (isso est ilustrado muito bem na Figura 1.1)
e tem custo maior de correo. Da a importncia de se conseguir a participao efetiva de
clientes e desenvolvedores logo no incio do processo.
[O sistema Restaurante]
Suponha que voc foi contratado para desenvolver um sistema. O que voc deve fazer em
primeiro lugar?
O primeirssimo passo no desenvolvimento de qualquer sistema o levantamento das
necessidades que os futuros usurios do sistema esperam ver atendidas ou seja, preciso
levantar os requisitos do sistema. Um bom ponto de partida entrevistar as pessoas que
usaro o sistema. No caso do sistema para o restaurante, poderiam ser feitas entrevistas
com o dono do restaurante, com o gerente do restaurante, com a pessoa que fica no caixa,
com os garons e at com alguns clientes habituais.
10
Captulo 1: Introduo
O resultado dessas entrevistas seria uma srie de anotaes como as mostradas na

Figura 1.2, que serviro de base para a modelagem do sistema:
Resumo descritivo do sistema Restaurante
Deseja-se um sistema para o controle do funcionamento do restaurante. O Caixa do
restaurante dever, a cada nova refeio, registrar no sistema os pratos e as bebidas
solicitadas pelo cliente. Com isso, o Caixa poder emitir a notinha (ticket) no encerramento
da refeio, a qual entregue pelo garom ao cliente, para que o mesmo possa conferir e
efetuar o pagamento da refeio. Essa notinha dever conter o nmero da mesa onde a
refeio foi servida, as quantidades e valores de tudo o que foi consumido, e o total a
pagar.
Pode acontecer o caso em que o cliente cancela a refeio, antes de ela ter sido
tomada. Neste caso, o Caixa registra isso no sistema.
O restaurante possui, dentre todos os clientes, alguns habituais, ou seja, que
regularmente tomam refeies no restaurante. O sistema dever manter um registro dos
clientes habituais. da responsabilidade do gerente do restaurante eleger e registrar no
sistema os clientes habituais. A esses clientes permitida a pendura das notinhas (para
pagamento posterior no final do ms, por exemplo), que deve ser registrada no sistema
pelo Caixa. As notinhas dos clientes habituais devem conter o nome e o telefone do cliente.
O Caixa quem registra no sistema o pagamento de uma notinha em aberto (ainda
no paga ou pendurada). O sistema dever auxiliar o Caixa computando o valor do troco a
ser devolvido ao cliente. O restaurante s aceita pagamento em dinheiro.
O gerente dever manter um cadastro dos itens de consumo (bebidas e pratos)
servidos no restaurante, indicando seu preo unitrio e sua disponibilidade atual (se o prato
ou bebida pode ser servido). Alm disso, ser importante que o gerente possa consultar no
sistema e repassar ao dono do restaurante, as seguintes informaes:
O consumo (quantidade de cada prato ou bebida) em um dia de funcionamento do

restaurante; essas informaes ajudaro o gerente a planejar a reposio de
ingredientes na cozinha do restaurante.
A receita (valor monetrio) obtida entre duas datas, pelo pagamento de refeies
nesse perodo.
Informaes sobre as penduras (nome do cliente, telefone, valor pendurado, data da

pendura), bem como o valor total pendurado, entre duas datas. Com isso, o gerente
poder efetuar a cobrana das penduras mais antigas, que j deveriam ter sido pagas.
O restaurante serve, em mdia, 250 refeies por dia. O restaurante possui,
atualmente, 30 mesas, mas esse nmero poder variar.
Figura 1.2: Requisitos iniciais do Sistema Restaurante
A partir desse levantamento inicial dos requisitos do sistema, pode-se analisar e
propor uma organizao e estrutura adequadas para o sistema, que atenda esses requisitos.
ai que os modelos entram: eles nos ajudam a planejar e estruturar todas as partes do
sistema a ser construdo.
O que so modelos?
Para construir uma casa, primeiro se faz a planta baixa da mesma. A planta baixa vai
mostrar quantos cmodos a casa tem, de que tipo eles so (quarto, sala, banheiro, ...), como
eles esto dispostos, como se comunicam, onde esto posicionadas as portas e janelas, etc.
Trata-se de um modelo da casa; ou seja, no a casa em si, mas apenas uma representao
11
Captulo 1: Introduo
abstrata da mesma. O termo abstrao est na essncia de qualquer modelo, pois toda
representao (por definio) mostra apenas uma parte das propriedades ou detalhes
daquilo que representa, ou seja, abstrai muitos detalhes do objeto modelado. o caso da
planta baixa da casa, que embora inclua informaes importantes sobre a mesma, no
inclui outras tambm relevantes, como por exemplo, os materiais a serem utilizados nas
paredes, pisos, portas e janelas.
Para o engenheiro que vai construir a casa, ter em mos somente a planta baixa
insuficiente para executar a obra. Ele precisa saber mais detalhes sobre ela. Muito antes de
construir as paredes, ele dever se preocupar com a posio, tamanho e composio das
sapatas de fundao, pilares e vigas que sustentaro a casa. Logo, vemos que sero
necessrios outros modelos para complementar a informaes representadas na planta
baixa. Entre esses modelos, podemos citar a planta de estrutura responsvel por
descrever (abstratamente) os elementos estruturais da casa, a planta de fachada que
fornece uma viso de como ser a aparncia da casa por fora, a planta eltrica que
apresenta todas as informaes necessrias construo da rede eltrica da casa, a planta
hidrulica, etc.
Mas porque no colocar tudo em uma nica planta e evitar a manipulao de vrias
delas? Simplesmente porque cada planta utilizada (lida) por um tipo de profissional
diferente, em momentos diferentes. Por exemplo, para o futuro morador da casa, interessa
conhecer, principalmente, a disposio e tamanho dos espaos que compem o interior da
casa (planta baixa) e como ela ser vista por fora (planta de fachada). A menos que seja
engenheiro, ele dificilmente se interessar (ou compreender) a representao dos detalhes
da estrutura da casa (planta de estrutura). Alm disso, uma nica planta que contivesse
todas as informaes necessrias execuo da obra tenderia a ser muito complexa e,
consequentemente, difcil de ser lida e compreendida.
Resumindo... comum, nas diversas reas do conhecimento, representar um objeto
por um conjunto de vises ou modelos complementares e consistentes entre si. Dois
modelos so consistentes entre si quando um no contradiz o outro. Na Cincia da
Computao no diferente. Os sistemas so materializados a partir de diversos modelos
que se complementam mutuamente e so consistentes uns com os outros.
Linguagens x Modelos
Vimos que modelos so representaes ou descries abstratas de alguma coisa que
precisamos estudar, compreender e/ou construir. E, para descrever algo, sempre temos de
lanar mo de uma linguagem. Nossa linguagem natural, o Portugus, uma possibilidade.
Entretanto, para construirmos modelos tcnicos, como os empregados em engenharia em
geral, e na Engenharia de Software em particular, normalmente se utiliza uma linguagem
especializada, ou seja, mais restrita, com smbolos e regras especficas para o universo de
discurso da rea. Por exemplo, para descrever uma casa, devemos falar de quartos, salas,
jardins, janelas, portas, vigas, pilares, etc. Normalmente, no precisamos nos referir a
coisas como carros, livros, laranjas, etc. Por isso, a Engenharia Civil emprega uma
linguagem especializada, que possui smbolos especiais pr-definidos para representar as
coisas do seu universo de discurso. A Figura 1.3 mostra a planta baixa de uma residncia e,
em destaque, o smbolo utilizado para representar uma janela da mesma.
O exemplo da Figura 1.3 evidencia outra caracterstica das linguagens utilizadas nas
engenharias: so linguagens grficas, ou seja, que utilizam principalmente smbolos
grficos no lugar de textuais. O Portugus, como qualquer outra linguagem natural,
textual, ou seja, os smbolos utilizados so smbolos textuais. Por exemplo, se queremos
descrever uma casa em Portugus, utilizamos os smbolos casa, quarto, janela, etc.
12
Captulo 1: Introduo
Vemos, portanto, que as engenharias levaram ao p da letra um conhecido provrbio: uma

figura vale mais do que mil palavras.
Figura 1.3: Planta baixa (modelo) de uma residncia destacando uma janela
O paradigma2 OO
Uma linguagem especfica para modelar sistemas computacionais deve focar o universo
das coisas que precisam ser consideradas na descrio desses sistemas. Na dcada de 1970,
conceitos tais como fluxos e depsitos (ou arquivos) de dados, processos, rotinas, mdulos,
subsistemas, etc., eram quase sempre empregados nos modelos. Posteriormente, na dcada
de 1980, com o surgimento da programao orientada a objetos (POO), logo amplamente
adotada pela academia e pela indstria de software, passou-se a falar de objetos, classes,
atributos, mtodos, mensagens, pacotes, etc. Na POO, os programas de computador so
organizados como um conjunto de (tipos ou classes) de objetos que se comunicam
trocando mensagens. Esses objetos possuem atributos (dados) que podem ser consultados
ou alterados, e mtodos (operaes) que podem ser executados, em resposta s mensagens
enviadas de um objeto para outro.
Uma das consequncias importantes dessa mudana na forma de programar foi a
reviso dos modelos que, at ento, eram utilizados na modelagem de sistemas
computacionais. Inicialmente, diversos autores propuseram, cada um, o seu prprio
conjunto de modelos orientados a objetos (modelos OO). Mas essa diversidade de
propostas exigia dos profissionais mais um passo antes de comear a desenvolver um
sistema: a escolha criteriosa do conjunto mais adequado de modelos. Alm disso,
dificultava o compartilhamento dos modelos entre equipes acostumadas a trabalhar com
modelos distintos.
Conjunto de ideias que rompe com um estado de coisas vigente e fundamenta um novo caminho para o
desenvolvimento cientfico ou tecnolgico.
13
Captulo 1: Introduo
UML
Em 1996, trs dos principais proponentes de modelos OO se juntaram para propor um
conjunto unificado de modelos que pudesse ser adotado por todos ou seja, um padro de
modelagem OO, a ser compartilhado por todos os desenvolvedores de software. Esse
padro deu certo e passou a ser conhecido por UML Unified Modeling Language, ou
linguagem de modelagem unificada. A UML uma linguagem de modelagem
eminentemente grfica, sempre presente nos currculos dos cursos de graduao em
computao, e muito utilizada na indstria de software, razes pelas quais, ser descrita em
detalhe nos prximos captulos.
A UML uma linguagem para especificar, descrever e representar os artefatos de um
sistema, especialmente sistemas que envolvem uma componente intensiva de software. Em
outras palavras, uma linguagem para descrever modelos de sistemas e, em especial,
sistemas computacionais.
A UML padronizada mundialmente pela OMG (Object Management Group)3, que
se encarrega de mant-la evoluindo com base na experincia e necessidades da
comunidade de usurios, que inclui a indstria, universidades, governo, especialistas, etc.
A UML pode ser utilizada ao longo de todas as etapas do desenvolvimento de um
sistema de software: modelagem de negcio, requisitos de software, anlise e projeto. Ela
abrange as mais diversas reas de aplicao, tais como administrao, engenharia,
medicina, etc.
[Diagramas da UML]
Todos os modelos em UML tem um forte componente grfico, j que a linguagem define
diversos diagramas, divididos em trs categorias: diagramas estruturais, diagramas
comportamentais e, como uma subcategoria dessa ltima, os diagramas de interao. A
Figura 1.4 apresenta o conjunto de diagramas da UML.
Figura 1.4: Diagramas da UML 2.4

Os diagramas estruturais (de classes, de objetos, de pacotes, de estrutura composta,
de componentes, de implantao e de perfil) definem os elementos do sistema e suas inter3
http://www.omg.org
14
Captulo 1: Introduo
relaes estruturais. So tambm chamados de diagramas estticos, pois eles representam

vises estticas do sistema, ou seja, vises que independem do transcurso do tempo. A
varivel tempo no considerada na elaborao dos diagramas estruturais.
Dos diagramas estruturais, o mais utilizado , de longe, o diagrama de classes. Por
isso, nos concentraremos no estudo dele. Os demais diagramas estruturais podem ser
facilmente encontrados na literatura sobre UML e, em particular, na bibliografia indicada
no final deste material.
Os diagramas comportamentais incluem o diagrama de casos de uso, o diagrama de
atividade, o diagrama de estados e, dentro da subcategoria dos diagramas de interao, o
diagrama de sequncia, o diagrama de comunicao, o diagrama de temporizao e o
diagrama de panorama de interao. So tambm conhecidos como diagramas dinmicos,
pois apresentam vises dinmicas do sistema, ou seja, vises que levam em conta a
passagem do tempo (varivel tempo).
Dos diagramas comportamentais, os mais utilizados so o diagrama de casos de uso,
o de estados, o de atividade, o de sequncia e o de comunicao. Por isso, esses so os
diagramas tratados neste material de estudo.
[Ferramentas UML]
Graas padronizao da UML pela OMG e a grande aceitao que essa linguagem teve e
tem, muitos so os fabricantes de software que desenvolveram ferramentas computacionais
para apoiar a modelagem com UML. Isso muito importante pois, como a UML uma
linguagem eminentemente grfica e normalmente os modelos passam por diversas verses
antes de atingirem um grau de perfeio aceitvel, a elaborao a mo dos modelos fica
impraticvel.
Existem diversas ferramentas de apoio elaborao de modelos UML, algumas
pagas e outras gratuitas. Por exemplo, os modelos apresentados neste material de estudo
foram desenvolvidos utilizando a ferramenta Astah, na verso gratuita, denominada verso
Community. Essa ferramenta pode ser encontrada na web. Para utiliz-la basta fazer o
download do arquivo de instalao e execut-lo.
[Organizao deste material]
O restante deste material est organizado em mais seis captulos, dedicados aos principais
modelos da UML: Captulo 2 Modelo de Casos de Uso; Captulo 3 Diagrama de
Classes de Objetos; Captulo 4 Diagrama de Estados; Captulo 5 Diagrama de
Sequncia; Captulo 6 Diagrama de Colaborao; e Captulo 7 Diagrama de Atividade.
15
2.
Modelo de Casos de Uso
2.1.
Introduo
Captulo 2: Modelo de Casos de Uso
Nosso objetivo neste tpico estudar o modelo de casos de uso (ou, abreviadamente,
modelo de UCs do ingls Use Cases) e aprender a utiliz-lo para o levantamento e
especificao dos requisitos de um sistema de software.
Um caso de uso (UC) de um sistema, como o prprio nome diz, uma forma de se
usar o sistema com o objetivo de realizar algo, segundo o ponto de vista de um usurio do
sistema.
A importncia desse modelo reside no fato de que ele , normalmente, o primeiro a
ser elaborado quando se deseja desenvolver um sistema, servindo de base para os demais
modelos posteriores. Um modelo de UCs bem feito meio caminho andado no sentido de
se ter um bom projeto do sistema a desenvolver (o contrrio tambm verdade!). Portanto,
que tal se empenhar ao mximo em aprend-lo bem?
[Para que serve]
O modelo de casos de uso serve para especificar os requisitos funcionais de um sistema, ou
seja, ele especifica:
O que o sistema deve fazer;
Que funes os atores (usurios) podero executar ao utilizar o sistema (por isso o
nome casos de uso).
Pesquisa:
a) Defina requisitos funcionais;
b) Que outros tipos de requisitos existem?
Saiba mais:
Casos de uso no se aplicam apenas a sistemas de software, mas tambm
servem para descrever um negcio, um equipamento, etc.
[Composio do modelo]
Um modelo de UCs composto de, pelo menos, duas partes: o diagrama de UCs (DUC) e
o conjunto das descries dos UCs que aparecem no diagrama. A Figura 2.1 apresenta um
exemplo de diagrama de UCs simplificado, para o funcionamento do sistema de um
telefone celular.
16
2.2.
Diagrama de UCs
Figura 2.1: Exemplo de diagrama de casos de uso

O diagrama da Figura 2.1 evidencia os principais elementos grficos e textuais
utilizados na elaborao do DUC:
Atores: Designam papis de pessoas ou outros sistemas que interagem com o sistema
que est sendo modelado. No caso do sistema Celular, temos dois atores o ator
Usurio, que representa uma pessoa no papel de quem usa o celular e o ator Rede,
que representa o sistema da operadora do celular. So atores porque interagem
diretamente (trocando sinais e/ou informaes) com o sistema Celular.
Casos de uso: O diagrama contm trs UCs Efetuar chamada, Receber chamada e
Usar a agenda. Cada UC representa um objetivo a ser alcanado por um ator ao
utilizar o sistema.
Associao de comunicao: representada por uma linha que une o ator ao UC,
significando que o ator interage (ou se comunica) com o sistema para realizar aquele
UC.
Fronteira do sistema (com o seu ambiente): representada pelo retngulo que

envolve todos os UCs do sistema. O que est dentro do retngulo (os UCs) faz parte
do sistema, e o que est fora (os atores), constitui o ambiente do sistema. Apresenta,
no canto superior esquerdo, o nome do sistema.
[UC-Lab1: Atores e stakeholders]

Identifique os atores do sistema Restaurante, com base na descrio dos
requisitos desse sistema, apresentada na Figura 1.2. Lembre-se, atores
so pessoas ou sistemas que interagem diretamente com o sistema a ser
construdo. Por exemplo, podemos dizer que (a pessoa no papel de)
Caixa ator do sistema Restaurante, pois ele vai usar diretamente o
17
sistema para realizar diversas funes, tais como registrar pedidos, emitir notinhas, etc. E o
dono do restaurante? A descrio inicial do sistema no indica qualquer ao direta dessa
pessoa no sistema. Se esse for realmente o caso, ento o dono no um ator e, portanto,
no aparecer no diagrama de UCs do sistema.
Saiba mais:
Se o dono do restaurante no um ator, o que ento? Resposta: um
stakeholder (pronuncia-se isteiquirrolder). Esse um termo em ingls
para designar aquelas pessoas que, embora no interajam diretamente com
o sistema, utilizam ou so afetadas, de alguma forma, pelos resultados
produzidos por ele. Portanto, devemos incluir os stakeholders tambm
entre as pessoas entrevistadas para o levantamento de requisitos do
sistema.
[UC-Lab2: DUC]
Construa um diagrama de UCs para o sistema Restaurante, com base na
descrio dos requisitos desse sistema (Figura 1.2) e considerando os
atores identificados no laboratrio anterior (UC-Lab1).
Lembre-se que os UCs de um sistema so os grandes objetivos que
os atores tm ao utilizar o sistema. No caso do sistema Restaurante, o
ator Caixa vai querer usar o sistema para registrar um pedido de refeio. Em outro
momento, o mesmo ator utilizar o sistema para registrar o pagamento da refeio.
Portanto, podemos incluir no diagrama de UCs desse sistema o UC Registrar pedido e o
UC Pagar a nota, certo? Que outros objetivos o ator Caixa teria ao utilizar o sistema? E
os outros atores do sistema?
Observao: Sempre comece o nome do UC com um verbo no infinitivo (como
Registrar pedido). Essa padronizao adequada, pois refora a ideia de que UCs so
funcionalidades desempenhadas com o uso do sistema.
2.3.
Descrio dos UCs
Aps a identificao dos atores e UCs, e a elaborao do DUC do sistema, deve-se

descrever os UCs. Existem diferentes nveis de detalhamento para se descrever um UC.
Para cada UC, a escolha do nvel de detalhamento mais adequado depende da
complexidade do UC e deve resultar de um compromisso entre o esforo requerido para se
descrever o UC naquele nvel e a preciso/clareza que a descrio resultante proporciona
aos seus leitores-alvo atores, stakeholders e desenvolvedores. A Figura 2.2 apresenta os
nveis de detalhamento mais comumente utilizados na descrio de UCs, alm de indicar
uma ordem de utilizao desses nveis: primeiramente se faz um sumrio do UC, para
depois, em uma segunda etapa e caso seja necessrio, descrever o fluxo de eventos do UC.
18
Figura 2.2: Nveis mais comuns de detalhamento na descrio de UCs
Sumrio
O mais alto nvel de descrio de um UC denominado Sumrio. Trata-se de uma breve4
descrio textual de como alcanar o objetivo do UC, atravs da descrio do uso do
sistema pelos atores envolvidos no UC. Por exemplo, considere o UC Abrir conta, dentro
do contexto de um sistema bancrio. O sumrio desse UC poderia ser:
O funcionrio consulta o Cliente no sistema, pelo CPF. Se necessrio, atualiza os
dados dele. Aps o Cliente informar uma senha, a conta aberta (criada) pelo Sistema. O
Funcionrio verifica com o Cliente o valor a depositar, obtm esse valor e efetua o
depsito dele na conta que acabou de ser criada. Por fim, o Sistema emite o carto da nova
conta.
Observe que esse sumrio descreve como abrir uma conta bancria (objetivo do ator
Funcionrio), atravs da interao entre o sistema e os atores Funcionrio e Cliente.
Considere agora o sistema Restaurante. Possveis sumrios para os UCs Abrir pedido
e Pagar a nota so:
Sumrio do UC Abrir pedido:
O Caixa informa os dados para a abertura do pedido (o nmero da mesa e os itens
pedidos, com respectivas quantidades). Uma vez concluda essa entrada de dados, o
sistema registra o novo pedido em seus arquivos.
Sumrio do UC Pagar a nota:
O Caixa identifica o pedido a pagar. O sistema exibe o total a pagar e solicita ao
Caixa que informe a quantia entregue pelo cliente para o pagamento. O Caixa informa essa
quantia. Se ela for maior do que a quantia a pagar, o sistema calcula e apresenta o troco.
Aps a confirmao do Caixa de que o pagamento foi efetuado, o sistema registra que a
nota foi paga.
[UC-Lab3: Sumrio dos UCs]
Faa o sumrio dos demais UCs do sistema Restaurante.
Normalmente, apenas um pargrafo.
19
Fluxo de Eventos
Para uma descrio mais detalhada de um UC, pode-se utilizar o segundo nvel de
detalhamento, denominado fluxos de eventos. Evento todo acontecimento gerado por um
ator ou pelo sistema. Consequentemente, qualquer evento tem como atributo ou
propriedade a posio da sua ocorrncia no tempo, em relao aos demais eventos. O fluxo
de eventos mostra onde cada evento, de um conjunto de eventos, est posicionado no
tempo, em relao aos demais eventos do conjunto.
[Exemplo: UC Pagar a nota (Sistema Restaurante)]
Para exemplificar fluxo de eventos, considere novamente o UC Pagar a nota, cujo sumrio
est reproduzido abaixo:
O Caixa identifica o pedido a pagar. O sistema exibe o total a pagar e solicita ao
Caixa que informe a quantia entregue pelo cliente para o pagamento. O Caixa informa essa
quantia. Se ela for maior do que a quantia a pagar, o sistema calcula e apresenta o troco.
Aps a confirmao do Caixa de que o pagamento foi efetuado, o sistema registra que a
nota foi paga.
Nesse UC, podemos identificar diversos eventos gerados pelo ator Caixa, tais como:
Identifica o pedido a pagar;
Informa a quantia (entregue pelo Cliente para pagamento do pedido);
Confirma que o pagamento foi efetuado;
Por sua vez, o sistema gera os seguintes eventos:

Exibe o total a pagar;
Solicita ao Caixa que informe a quantia entregue pelo cliente para o pagamento;
Calcula e apresenta o troco;
Registra o pagamento em seus arquivos;
A descrio do fluxo de eventos desse UC colocaria cada evento na sua posio

correta no tempo, em relao aos demais:
1.
2.
3.
4.
5.
6.
7.
8.
O Caixa identifica o pedido a pagar;

O sistema exibe o total a pagar;
O sistema solicita ao Caixa que informe a quantia entregue pelo cliente para o
pagamento;
O Caixa informa a quantia (entregue pelo Cliente);
O sistema calcula e apresenta o troco;
O Caixa confirma que o pagamento foi efetuado;
O sistema registra o pagamento em seus arquivos;
O sistema informa ao Caixa a concluso com sucesso da operao.
Figura 2.3: Fluxo de eventos do UC Pagar a nota (Sistema Restaurante)
20
[Exemplo: UC Abrir conta (sistema bancrio)]

Outro exemplo a descrio do fluxo de eventos do UC Abrir conta, cujo sumrio foi
apresentado anteriormente nessa seo:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
O Sistema pede o CPF do cliente;

O Funcionrio informa o CPF;
O Sistema apresenta os dados cadastrais do Cliente e solicita que o Funcionrio os
atualize, se necessrio;
O Gerente atualiza o cadastro do Cliente;
O Sistema pede uma senha de acesso para o Cliente;
O Cliente informa a senha;
O Sistema abre a conta;
O Sistema solicita o valor do depsito inicial;
O Gerente informa o valor e confirma seu recebimento;
O Sistema registra o depsito e emite o carto da nova conta.
Figura 2.4: Fluxo de eventos do UC Abrir conta (sistema bancrio)
[Fluxo de eventos com situaes alternativas]

De certa maneira (menos estruturada e, normalmente, menos detalhada), o sumrio de um
UC tambm d uma ideia dos eventos gerados pelos atores e pelo sistema, bem como da
ordem em que os eventos ocorrem. Entretanto, em uma descrio de fluxo de eventos,
alm dessa informao estar melhor estruturada e mais detalhada, tambm possvel
destacar situaes alternativas que representam comportamento de carter opcional,
excepcional ou alternativo. Por exemplo, considere o fluxo de eventos do UC Pagar a nota
(Sistema Restaurante Figura 2.3). E se o cliente entregar (e o Caixa informar ao sistema)
uma quantia inferior ao valor devido para pagamento da refeio? Como o sistema deveria
se comportar? Veja na Figura 2.5, uma sugesto de como incluir o tratamento dessa
situao no fluxo de eventos do UC.
1.
2.
3.
4.
5.
6.
7.
8.
O Caixa identifica o pedido a pagar;

O sistema exibe o total a pagar;
O sistema solicita ao Caixa que informe a quantia entregue pelo cliente para o
pagamento;
O Caixa informa a quantia (entregue pelo Cliente);
O sistema calcula e apresenta o troco;
O Caixa confirma que o pagamento foi efetuado;
O sistema registra o pagamento em seus arquivos;
O sistema informa ao Caixa a concluso com sucesso da operao.
Situaes Alternativas:
A1. Quantia dada para pagamento da nota da refeio inferior ao valor devido: O
sistema deve informar ao Caixa essa situao e permitir que ele entre com outra
quantia ou finalize o UC.
Figura 2.5: Fluxo de eventos com alternativa (UC Pagar a nota)
O exemplo acima mostra a descrio do fluxo de eventos de um UC com apenas uma
situao alternativa. Mas essa no a regra geral. A seguir, apresentada uma lista de
21
situaes alternativas que poderiam estar previstas na descrio do fluxo de eventos do UC

Retirar dinheiro, de um sistema de terminal de autoatendimento bancrio.
A1.
A2.
A3.
A4.
A5.
A6.
A7.
A8.
A9.
Carto no pode ser identificado;

Cliente no pode ser identificado;
Cliente deseja retirar quantia distinta daquelas pr-definidas;
Saldo na conta do Cliente insuficiente para retirar a quantia solicitada;
Limite dirio de retirada ultrapassado;
Link de comunicao com o Sistema do Banco est fora do ar;
Carto roubado - o carto est na lista negra;
O terminal no tem dinheiro suficiente;
O carto agarrou no leitor de cartes do terminal;
[Cenrios de um UC]
A existncia de situaes alternativas na descrio de um UC mostra que, a cada realizao
de um UC, uma sequncia diferente de eventos pode ocorrer. Por exemplo, no UC anterior
(Retirar dinheiro), se a quantia solicitada para retirada for superior ao limite dirio, ento
em vez de disponibilizar o dinheiro ao usurio, o terminal bancrio emitir uma mensagem
para esclarecer a situao e permitir que o usurio escolha outra quantia. Cada sequncia
especfica de eventos ocorridos durante a realizao de um UC um cenrio do UC.
Portanto, um UC pode expressar um conjunto de cenrios.
Saiba mais:
Existe ainda uma forma mais detalhada de se descrever o fluxo de eventos
de um UC, denominada fluxo completo de eventos, em contraposio
quela que foi vista nesta seo, que normalmente denominada de
resumo (outline, em ingls) de eventos. Entretanto, para a maioria dos
UCs, o sumrio ou a fluxo resumido de eventos mais do que suficiente.
[UC-Lab4: Fluxo de eventos dos UCs]

Elabore os fluxos (resumidos) de eventos para os UCs do sistema
Restaurante, incluindo o tratamento de situaes alternativas, se houver.
2.4.
Relacionamentos entre UCs
Vimos que o diagrama de UCs mostra o relacionamento de comunicao entre os atores e

os UCs, atravs de linhas que unem cada ator aos UCs com os quais ele troca sinais e
informaes. Agora vamos ver que os UCs tambm podem se relacionar. Abaixo esto
listados os trs tipos de relacionamentos entre UCs, sendo os dois primeiros os mais
comuns:
Relacionamento de incluso (um UC inclui o outro);
Relacionamento de extenso (um UC estende o outro); e
Relacionamento de generalizao (um UC generaliza o outro).
22
Incluso
O relacionamento de incluso (include, em ingls) entre dois UCs expressa que o
comportamento (fluxo de eventos) de um UC inclui, incondicionalmente, o comportamento
(fluxo de eventos) do outro UC. Por exemplo, no diagrama da Figura 2.6, o
(comportamento descrito no) UC Emitir histrico escolar sempre inclui, em algum ponto
do seu fluxo de eventos, o (comportamento descrito no) UC Efetuar login. Isso expresso
atravs da seta tracejada com o rtulo <<include>>, partindo do UC que inclui e
chegando no UC que includo.
Figura 2.6: Representao do relacionamento de incluso entre UCs
Extenso
O relacionamento de extenso (extend, em ingls) entre dois UCs expressa que o
comportamento (fluxo de eventos) de um UC estende, condicionalmente, o comportamento
(fluxo de eventos) do outro UC. Por exemplo, no contexto de um sistema de
videolocadora, o diagrama da Figura 2.7 mostra que o (comportamento descrito no) UC
Registrar pagamento estende condicionalmente o (comportamento descrito no) UC Fazer
emprstimo, assim como tambm estende (condicionalmente) o UC Fazer devoluo. Isso
porque, quando se toma um filme emprestado, o pagamento do emprstimo pode ou no
ser feito no ato do emprstimo (UC Fazer emprstimo); caso no seja feito, o emprstimo
deve ser pago no momento em que ele devolvido (UC Devolver emprstimo) a deciso
do cliente da videolocadora. Consequentemente, os relacionamentos do UC Registrar
pagamento com os outros dois UCs so do tipo extend; s seriam include se Registrar
pagamento devesse ser realizado sempre que Fazer emprstimo e Fazer devoluo fossem
realizados. O relacionamento extend expresso atravs de uma seta tracejada com o rtulo
<<extend>>, partindo do UC que estende e chegando ao UC estendido (ou seja, no
sentido inverso de um include).
23
Figura 2.7: Representao do relacionamento de extenso entre UCs

Saiba mais:
O diagrama da Figura 2.7 exibe uma novidade o relacionamento de
herana de comportamento entre atores5. Herana de comportamento, no
contexto do modelo de UCs, significa herana de UCs, ou seja, um ator
herda a capacidade de realizar os UCs de outro ator. Esse relacionamento
desenhado como uma seta contnua e com a ponta fechada, partindo do
ator que herda o comportamento e chegando no outro ator, aquele que
fornece o comportamento herdado. Portanto, pela Figura 2.7, podemos
dizer que o Cliente online pode realizar todos os UCs ligados diretamente
a ele (no caso, apenas o UC Reservar filme) e mais os UCs herdados do
ator Usurio online (UC Consultar acervo). Por sua vez, Balconista pode
realizar todos os UCs do sistema, graas ao relacionamento de herana
entre atores.
Consideraes sobre Include e Extend

Uma coisa a se ter sempre em mente que os UCs includos em outros UCs, ou aqueles
que estendem outros UCs, devem poder ser ativados independentemente desses outros
(melhor dizendo: devem poder ser realizados mesmo que esses outros no estejam sendo
realizados). Os UCs das Figuras 2.6 e 2.7, que so includos em outros (Efetuar login,
Consultar acervo), ou que estendem outros (Registrar pagamento, Informar filme
disponvel) satisfazem essa condio. Por exemplo, o UC Consultar acervo (Figura 2.7)
pode ser ativado (realizado) mesmo sem a realizao do UC Reservar filme, que o inclui;
igualmente, o UC Registrar pagamento (Figura 2.7) pode ser ativado mesmo que os UCs
Fazer emprstimo e Fazer devoluo no estejam acontecendo (pois um cliente pode, a
5
Tambm conhecido como relacionamento de generalizao/especializao entre atores.
24
qualquer momento, entre o emprstimo e a devoluo do filme, ir videolocadora e efetuar

o pagamento do filme). Essa observao importante porque ela impede a utilizao
desses relacionamentos para fazer, no diagrama de UCs, a decomposio funcional do
sistema um erro frequente entre modeladores inexperientes. Essa independncia entre
UCs pode ser verificada graficamente: no diagrama, todos os UCs devem estar associados
a pelo menos algum ator6.
1.
2.
Duas diferenas importantes entre os relacionamentos de incluso e de extenso so:

No relacionamento de incluso, a seta aponta o UC cujo comportamento vai ser
inserido no outro UC, enquanto que no relacionamento de extenso, a seta aponta o
UC que recebe a insero (de comportamento) do outro UC.
O relacionamento de incluso incondicional, ou seja, sempre ocorrer a insero do
comportamento do UC includo, no UC que o inclui. Diferentemente, o
relacionamento de extenso condicional, ou seja, a insero do comportamento do
UC que estende, no UC que estendido, depende de uma condio ser verdadeira.
Portanto, a extenso modela comportamento opcional, alternativo ou de exceo.
[Efeito do include e do extend sobre a descrio dos UCs]

Voc deve estar pensando: Que efeito a introduo (no diagrama de UCs) de um
relacionamento de incluso ou de extenso entre dois UCs tem sobre a descrio do fluxo
de eventos desses UCs?
A Figura 2.8 mostra que o UC A (aquele que recebe a insero de comportamento)
o responsvel por chamar o UC B. O fluxo de eventos do UC B (aquele que includo
no UC A) no sofre qualquer alterao.
Figura 2.8: Efeito de A includes B sobre o fluxo de eventos dos UCs A e B

A Figura 2.9 mostra que o UC B (aquele que estende o comportamento) o
responsvel por especificar duas coisas: 1) A condio que deve ser verdadeira para que a
6
Condio necessria, mas no suficiente, j que as associaes entre atores e UCs no esclarecem se um
ator ativa (inicia) um UC, ou apenas interage (se comunica) com ele.
25
extenso (insero) ocorra; e 2) O ponto do fluxo de eventos do UC A (ponto de extenso)

em que deve ocorrer a insero.
Um ponto de extenso um rtulo que marca um lugar dentro do fluxo de eventos de
um UC, de forma que se possa referir a ele quando necessrio por exemplo, quando se
tem de inserir comportamento naquele ponto do fluxo de eventos. Essa a nica alterao
necessria no fluxo de eventos do UC A7.
Figura 2.9: Efeito de A extends B sobre o fluxo de eventos dos UCs A e B

O relacionamento de extenso entre UCs, por sua caracterstica de afetar apenas a
descrio do UC que estende (e no a do UC que estendido) 8, mais adequado do que o
relacionamento de incluso como mecanismo de especificao de funcionalidades que so
introduzidas em uma nova verso de um software pr-existente. Isso porque, nesse caso,
essas funcionalidades so especificadas atravs de novos UCs que estendem os j
existentes, evitando-se, assim, alterar esses ltimos.
Generalizao
Imagine a seguinte situao: Uma empresa planeja desenvolver e comercializar um sistema
de contabilidade. Entretanto, como essa empresa buscar clientes nos diversos ramos de
atividade indstria, comrcio e servios, ela chegou concluso que precisar ter uma
verso do sistema para cada ramo. As trs verses do sistema tero muito em comum, se
diferindo apenas em alguns pontos. Como organizar os UCs do sistema, de forma a refletir
essa situao?
7
8
Caso o ponto de extenso ainda no exista.

Exceto pela introduo de um ponto de extenso, se necessrio.
26
Pesquisa:
Essa situao exemplifica o conceito de famlia de sistemas. Procure saber
mais sobre ele...
Uma boa opo lanar mo do relacionamento de generalizao (generalization,

em ingls) entre dois ou mais UCs, que expressa a relao entre um UC geral e os demais
UCs cujas descries de comportamento especializam o comportamento descrito no UC
geral. Ou seja, o sistema da nossa empresa hipottica poderia ser modelado atravs de
diversos UC gerais descrevendo o comportamento comum (genrico) s trs verses do
sistema, e trs outros UCs para cada UC geral (um para cada ramo de atividade),
responsveis por descrever o comportamento especializado para cada ramo. Cada UC geral
estaria ento ligado aos seus trs UCs especializados, atravs do relacionamento de
generalizao (Figura 2.10).
Figura 2.10: Representao do relacionamento de generalizao entre UCs
Algumas outras caractersticas do relacionamento de generalizao entre UCs so:

O comportamento exibido na realizao de um UC que especializa um UC geral no
est todo descrito nele, mas resulta de se estender o UC geral com o comportamento
descrito no UC especializado, em pontos de extenso existentes no fluxo de eventos do
UC geral. Essa uma vantagem do relacionamento de generalizao: o comportamento
genrico fatorado no UC geral, e os UCs que o especializam contm apenas o
comportamento especfico a ser acrescentado ao comportamento geral.
O UC geral no tem, necessariamente, que ser completo ou poder ser executado, mas
sim os UCs que o especializam. Este o caso dos UCs gerais do sistema da nossa
empresa hipottica, pois no faz sentido ter uma verso executvel do sistema que
incorpore apenas o comportamento comum aos trs ramos de atividade (no haver
cliente interessado nela, certo?). Mas a Figura 2.11 exemplifica uma situao onde
razovel supor que tanto o UC geral quanto o UC especializado podero ser
executados.
Figura 2.11: Exemplo de relacionamento generalizao entre dois UCs
27
[UC-Lab5: Relacionamentos entre UCs]

Considere a seguinte descrio do comportamento para a abertura de
uma conta bancria: O funcionrio consulta o Cliente no sistema, pelo
CPF. Se necessrio, atualiza os dados cadastrais dele. Aps o Cliente
informar uma senha, a conta criada pelo Sistema. O Funcionrio
verifica com o Cliente o valor a depositar, obtm esse valor e efetua o
depsito dele na conta que acabou de ser criada. Por fim, o Sistema
emite o carto da nova conta.
Em conformidade com a descrio acima, complete o diagrama abaixo introduzindo
um relacionamento de incluso e outro de extenso.
28
Captulo 3: Diagrama de Classes de Objetos
3.
Diagrama de Classes de Objetos
3.1.
Introduo
Este captulo apresenta outro modelo da UML: o Diagrama de Classes de Objetos (ou
abreviadamente, Diagrama de Classes - DC). Ele largamente utilizado, em conjunto com
o Modelo de Casos de Uso, para modelar praticamente todo tipo de sistema. Normalmente,
o DC elaborado depois do modelo de UCs, embora isso no seja imprescindvel. O mais
importante que os dois modelos no se contradigam, isto , eles devem ser consistentes
entre si.
Assim como a planta estrutural de uma casa modela a estrutura da casa, ou seja, os
elementos que garantem a sua sustentao, o DC modela a estrutura de um sistema os
elementos (classes, associaes, atributos, operaes) que possibilitam a realizao do
comportamento descrito nos UCs do sistema. Da, sua grande importncia.
[Exemplo de DC]
Figura 3.1: Exemplo de diagrama de classes de objetos

A Figura 3.1 apresenta um exemplo de diagrama de classes. Nela, pode-se observar os
principais elementos utilizados na construo desse diagrama: classes (tipos) de objetos,
atributos e operaes de classe, e associaes entre classes. Uma leitura de parte desse
diagrama seria: Todo (objeto da classe) Carro possuir (os atributos) modelo, placa e
potncia, e poder ser solicitado a (executar as operaes) imprimirProprietario( ) e
imprimirDados( ). Alm disso, todo (objeto da classe) Carro estar ligado a um nico
(objeto da classe) Proprietrio, enquanto que um (objeto da classe) Proprietrio estar
ligado a um ou mais objetos (da classe) Carro.
29
Um DC nos diz muita coisa sobre a estrutura e o comportamento do sistema que ele
modela. A estrutura do sistema definida pelas classes e seus atributos, e pelas associaes
entre as classes; ambos, atributos e associaes, representam as informaes que o sistema
armazenar. J o comportamento previsto nos UCs do sistema, esse dever resultar da
execuo (possivelmente encadeada) de operaes das classes.
Classe Objeto
Como vimos no Captulo 1, toda representao de alguma coisa, como por exemplo, uma
pessoa, envolve abstrao, ou seja, selecionar as propriedades das pessoas que so
relevantes para o sistema a ser desenvolvido. Desde a adoo do paradigma da orientao a
objetos, essas propriedades passaram a incluir, alm de propriedades estticas ou de estado
(atributos), como por exemplo, nome, data de nascimento, sexo, estado civil, etc., tambm
propriedades dinmicas ou de comportamento (operaes ou mtodos), tais como nascer,
casar, etc. Uma classe de objetos a estrutura formada pelos atributos e operaes
selecionados para representar objetos de um mesmo tipo, no contexto de um dado sistema.
A Figura 3.2 mostra a representao grfica de uma possvel classe (de objetos) Pessoa:
um retngulo dividido em trs partes ou compartimentos: o compartimento de cima contm
o nome da classe, o do meio, os atributos da classe e o inferior, as operaes da classe.
Observe que, juntamente com o nome de cada atributo ou operao, tambm pode ser
especificado o tipo (de dados) do valor que o atributo pode receber ou que a operao
retorna (void se a operao no retorna valor), e a visibilidade dos atributos e das
operaes:
- : O atributo (ou operao) privado(a), ou seja, s pode ser utilizado9 (invocada)

pelas operaes da prpria classe;
#: O atributo (ou operao) protegido(a), ou seja, s pode ser utilizado

(invocada) pelas operaes da prpria classe ou pelas operaes de uma subclasse
dela; e
+: O atributo (ou operao) pblico(a), ou seja, pode ser utilizado (invocada)

pelas operaes de qualquer classe do sistema.
Em geral, os atributos devem ser privados, e as operaes, pblicas. Esse esquema de
visibilidade cria um encapsulamento dos dados da classe, pois qualquer acesso a eles de
fora da classe s pode ser feito atravs da invocao de alguma operao nela definida. O
encapsulamento importante porque mantm baixo o acoplamento entre as classes e, por
consequncia, o custo de se fazer modificaes nas mesmas. Em outras palavras, se uma
classe est encapsulada, uma modificao nela produz menor propagao de modificaes
em outras classes do sistema.
A partir da classe Pessoa, pode-se criar (instanciar) objetos com valores especficos
para os atributos da classe e com o mesmo comportamento invocvel (operaes) nela
previsto. Portanto, uma classe funciona como um molde (modelo) para a criao de
objetos similares as instncias ou exemplares da classe. A Figura 3.2 exibe um objeto
criado a partir a classe Pessoa.
Para consultar ou alterar o seu valor.
30
Figura 3.2: Uma classe (de objetos) Pessoa e um objeto dessa classe
Todo objeto possui ainda outra caracterstica que independe do seu estado (i.e., dos
valores dos seus atributos): a sua identidade. Por exemplo, podemos distinguir duas folhas
de papel A4, mesmo que tenham os mesmos valores dos atributos (identidade no espao);
tambm, se pintarmos uma folha de amarelo (ou seja, mudar um de seus atributos a cor),
ela continua sendo a mesma folha de papel (identidade no tempo).
3.2.
Associaes entre classes
Alm das classes de um sistema, o DC tambm mostra as associaes existentes entre elas.
Essas associaes so, em sua grande maioria, relaes binrias, isto , relacionam duas
classes, e esto representadas por linhas que ligam as classes.
Saiba mais:
Tambm podem aparecer no DC associaes ternrias, quaternrias, etc.,
embora isso seja pouco comum. Consulte a bibliografia do curso ou
pesquise em sites da Internet se quiser saber mais sobre essas associaes.
As associaes especificam como os objetos das classes associadas podero estar

ligados entre si. Por exemplo, se existe uma associao entre a classe A e a classe B, ento
podero existir ligaes entre os objetos da classe A e os objetos da classe B. Assim como
um objeto uma instncia de uma classe, uma ligao uma instncia de uma associao.
A Figura 3.3 apresenta uma associao de nome leciona, entre a classe Professor e a classe
Curso, cujo significado Professor leciona em Curso10. Portanto, objetos representando
professores podero estar ligados a objetos representando cursos, e cada ligao entre um
objeto-professor e um objeto-curso indicar que o professor leciona naquele curso. Por
exemplo, o professor p3 est ligado a (ou leciona em) dois cursos (c2 e c3), enquanto que o
professor p1 s leciona em um curso (c1) e o professor p2 no leciona em nenhum curso.
Quando representamos uma associao entre duas classes no DC, podemos
especificar as multiplicidades de cada classe naquela associao, da maneira indicada na
Figura 3.3. Nela, n e m especificam o nmero mnimo e mximo de objetos da classe
Professor que um objeto da classe Curso pode estar ligado, enquanto p e q especificam o
10
Caso exista mais de uma associao entre um mesmo par de classes, elas devem ter nomes distintos (e,
obviamente, significados distintos).
31
nmero mnimo e mximo de objetos da classe Curso que um objeto da classe Professor
pode estar ligado. A propsito, quais seriam os valores de n, m, p e q na Figura 3.3?
Figura 3.3: Associao, ligaes e multiplicidades
As multiplicidades que mais aparecem nas associaes so as apresentadas a seguir:

0..1 : no mnimo zero e no mximo um;
1..1 (ou, abreviadamente, 1): no mnimo um e no mximo um (ou: exatamente um);
esta a multiplicidade default, ou seja, aquela que vigora quando no se indica nada
em uma extremidade da associao;
0..* (ou, abreviadamente *): no mnimo zero e no mximo vrios;
1..* : no mnimo um e no mximo vrios;
Existem ainda outras formas de se especificar a multiplicidade, como por exemplo:

3..5 (no mnimo trs e no mximo cinco), ou 1, 3..5 (exatamente um, ou, no mnimo trs e
no mximo cinco).
[DC-Lab1: Associaes e suas multiplicidades (1)]
Especifique as multiplicidades das associaes mostradas na figura a
seguir.
32
[DC-Lab2: Associaes e suas multiplicidades (2)]

Qual das trs associaes a seguir a correta?
[DC-Lab3: Atributos x Associaes]

Considere o seguinte:
errado incluir em uma classe um atributo que designa um objeto de
outra classe presente no DC; o correto nesse caso introduzir uma
associao entre as duas classes, com o significado correspondente.
Entre um par de classes pode-se ter mais de uma associao (com
nomes distintos).
Com base nas duas observaes acima, faa um DC para representar pases e suas
cidades, a capital de cada pas, e os nomes dos pases e das cidades.
Associao reflexiva
Uma associao pode envolver apenas objetos de uma mesma classe, como mostrado na
Figura 3.4. Esse tipo de associao recebe o nome de associao reflexiva.
Figura 3.4: Associao reflexiva e papis
33
Em uma associao reflexiva, uma outra propriedade das associaes se torna

bastante til: o papel (do objeto) de cada classe, na associao. Por exemplo, o DC da
Figura 3.4 nos diz que, se existir uma ligao entre duas pessoas segundo a associao ter,
uma delas estar no papel de pai e a outra no papel de filho.
Classe de associao
Uma associao tambm pode ter atributos e operaes. Por exemplo, considere uma
associao matriculado entre objetos da classe Aluno e da classe Disciplina. A nota que
obtida por um determinado aluno em uma disciplina na qual est matriculado, no
atributo da classe Aluno nem da classe Disciplina, mas sim da associao entre elas (ou
seja, a nota no descreve um aluno ou uma disciplina isoladamente, mas sim a associao
do aluno com a disciplina). Nesse caso, a associao ganha status de classe uma classe
de associao, j que ela no apenas associa dois tipos de objetos, mas tambm representa
ou descreve um novo tipo de objeto que possui estado (atributos) e comportamento
(operaes). A Figura 3.5 mostra como se desenha uma classe de associao no DC. A
classe de associao recebe o mesmo nome da associao que a origina. Essa figura
tambm mostra uma classe de associao derivada de uma associao reflexiva.
Figura 3.5: Exemplos de classes de associao
Agregao e Composio
O que existe de diferente entre uma associao entre as classes Aluno e Disciplina e outra
entre as classes Time e Jogador? Uma resposta razovel seria: um jogador parte de um
time, mas o mesmo no se pode dizer com relao associao entre disciplina e aluno
(uma disciplina no parte de um aluno, nem um aluno parte de uma disciplina). Esse
tipo especial de associao que relaciona o todo a suas partes, com o significado de que o
todo contm as (ou constitudo pelas) partes, recebe o nome de agregao. A Figura 3.6
mostra dois exemplos de agregao e como diferenciar uma associao comum de uma
agregao: colocando um losango na extremidade correspondente classe que representa o
todo.
34
[Agregao]
Figura 3.6: Exemplos de associaes do tipo agregao
[Composio]
As situaes modeladas na Figura 3.6 tm caractersticas em comum, mas tambm se
diferem em alguns aspectos. Primeiramente, tanto um time constitudo por jogadores,
quanto um pedido constitudo por itens de pedido (produtos, com suas quantidades e
preos unitrios). Entretanto, um jogador pode existir sem estar ligado a um time; por
exemplo, um jogador de futebol com passe livre ou desempregado. J um item de pedido
no pode existir sem estar ligado a um pedido. Alm disso, um mesmo jogador pode
participar de mais de um time, como quando faz parte do time de um clube de futebol mas
tambm do time da seleo brasileira, o que no acontece com um item de pedido, que s
pode fazer parte de um nico pedido. E mais: se um time for desfeito (deixar de existir),
faz sentido que os jogadores continuem a existir, certo? Mas, e os itens de um pedido, se o
pedido for apagado? Portanto, percebemos que as duas situaes modeladas da mesma
forma (atravs de agregao) na Figura 3.6 so, de fato, diferentes. Levando em conta isso,
a UML definiu um tipo especial de agregao, denominado composio, que traduz as
caractersticas de uma agregao mais forte, como o caso da agregao entre Pedido e
Item de pedido. A Figura 3.7 mostra exemplos de composio. Observe que, graficamente,
uma composio se difere de uma agregao pelo preenchimento do losango com a cor
preta.
Figura 3.7: Exemplos de associaes do tipo composio
35
[Comparao entre Agregao e Composio]

Outra caracterstica tanto da agregao quanto da composio que uma ao sobre
o todo tende a se propagar nas partes. Por exemplo, se um time viaja, os jogadores tambm
viajam. Entretanto, tem um tipo de ao que s se propaga na composio: apenas na
composio, a eliminao do todo resulta, necessariamente, na eliminao das partes. Em
outras palavras, enquanto na composio o tempo de vida dos objetos-parte sempre no
mximo igual ao tempo de vida do seu objeto-todo, na agregao um objeto-parte pode
durar mais do que o seu objeto-todo (ou seja, pode continuar a existir mesmo depois do
objeto-todo ser eliminado). Por exemplo, quando se um time deixa de existir, normalmente
os jogadores que compunham aquele time permanecem existindo. Por outro lado, quando
um pedido eliminado, os itens que compunham aquele pedido no tm porque continuar
a existir. Igualmente no relacionamento entre Empresa e Departamento (Figura 3.7),
quando a empresa deixa de existir, no faz sentido querer manter os seus departamentos
existindo. Essa diferena entre composio e agregao se reflete na multiplicidade do lado
da classe-todo: enquanto na agregao essa multiplicidade normalmente 0..1 (veja na
Figura 3.6), na composio ela ser sempre 1 (isto , 1..1 veja na Figura 3.7). A
multiplicidade do lado da classe-parte pode variar, tanto na agregao quanto na
composio. Normalmente, considera-se que um objeto-todo possa ser criado antes da
criao dos seus objetos-parte (multiplicidade 0..*, ou simplesmente *).
A seguir apresentado um quadro comparativo entre agregao e composio.
Tabela 3.1: Comparao entre agregao e composio
Caracterstica
Agregao
Composio
Relao todo-parte
Tem
Tem
Propagao de ao no objeto-todo a seus objetosSim
Sim
parte (exceto, eliminao do objeto-todo)
Propagao de eliminao do objeto-todo a seus
No
Sim
objetos-parte
Existncia do objeto-parte independentemente do seu
Sim
No
objeto-todo
Tempo de vida do objeto-parte em relao ao seu
Pode ser maior Menor ou igual
objeto-todo
Participao do (mesmo) objeto-parte na composio
Pode
No pode
de mais de um objeto-todo
Multiplicidade (usual) no lado da classe-todo
0..1 ou 0..*
1
Multiplicidade (usual) no lado da classe-parte
*
*
[DC-Lab4: Agregao e composio]

Considere as classes Microcomputador, Monitor, Teclado e Gabinete.
Desenhe um DC com essas classes e estabelea as associaes entre elas
que julgar pertinentes (justifique).
36
Generalizao/especializao
Existe ainda um outro tipo de associao entre classes, denominada associao de
generalizao/especializao. Quando duas ou mais classes so muito semelhantes, para se
evitar a declarao dos mesmos atributos e operaes repetidamente em cada classe, criase uma classe geral onde so declarados os atributos e operaes comuns a todas as classes
envolvidas, as quais so ento declaradas como especializaes da classe geral. Em cada
classe especializada ficam apenas os atributos e operaes especficas dela, j que ela
herda todos os atributos e operaes declarados na classe geral qual est associada. Essa
uma medida que, normalmente, contribui para melhorar a legibilidade e a compreenso
do DC. Veja na Figura 3.8, exemplos desse tipo de associao entre classes.
Na Figura 3.8, o diagrama da esquerda estabelece que Conta poupana uma
especializao de Conta corrente; consequentemente, herda todos os atributos (agencia e
nrConta) e todas as operaes (depositar( ) e obterSaldo( )) dela, e acrescenta um atributo
seu prprio, especfico para contas de poupana (diaDeposito) e uma operao especfica
(obterRendimento( )). Ou seja, a classe Conta corrente possui 2 atributos e duas operaes,
e a classe Conta poupana possui 3 atributos (dois herdados e um prprio) e 3 operaes
(duas herdadas e uma prpria). No diagrama da direta, esto representados os
relacionamentos entre associaes comuns, agregaes e composies, de acordo com o
significado visto anteriormente para esses conceitos: composio uma especializao de
agregao, que por sua vez uma especializao de associao. Assim, agregao herda
todas as propriedades de associao (comum), como por exemplo, ter um nome, e
acrescenta outras que lhe so especficas, como por exemplo, a identificao de qual classe
est no papel da classe-todo. Composio, por sua vez, herda todas as propriedades de
agregao (e tambm, indiretamente, de associao comum) e acrescenta as que lhe so
prprias, como por exemplo, uma operao que propaga a eliminao do objeto-todo para
seus objetos-parte.
Figura 3.8: Generalizao / especializao entre classes
[DC-Lab5: Interpretao de um DC]

Redija um texto para descrever o metamodelo11 especificado atravs do
DC da Figura 3.9.
11
Metamodelo um modelo que descreve outro modelo; neste caso, um modelo que descreve um diagrama
de classes qualquer.
37
Figura 3.9: Metamodelo (parcial) de um DC
[DC-Lab6: Construo de um DC]

Elaborar um DC para o sistema Restaurante, com base no modelo de UCs
do sistema.
38
4.
Diagrama de Estados
4.1.
Introduo
Captulo 4: Diagrama de Estados
[O que o DE]
O Diagrama de Estados (DE) um diagrama dinmico12 da UML, que serve para modelar
o comportamento de um sistema ou parte dele (por exemplo, um objeto), mostrando os
estados em que ele pode estar e como ele pode evoluir entre os estados, ao longo toda a sua
existncia.
A importncia do DE no deve ser subestimada. Mais de uma vez vi o processo de
modelagem de um sistema emperrado, sem conseguir avanar. Cada reunio com os
usurios, em vez de ajudar, parecia trazer mais confuso para os analistas alocados ao
projeto. A soluo desse impasse s veio quando algum se lembrou de utilizar DEs para
explicitar e estudar os possveis estados de partes complexas do sistema e o
comportamento associado a cada um deles. A partir da, o projeto deslanchou. Essa a
importncia do DE!
Tudo que possui estados e comportamento varivel de acordo com o estado em vigor
passvel de descrio atravs de um DE. Quando o nmero de estados grande e/ou o
efeito de cada estado sobre o comportamento complexo, a elaborao do DE torna-se
imprescindvel. Por isso, importante conhecer bem essa ferramenta de modelagem.
[Exemplo de DE]
Figura 4.1: DE de um sistema de porto de garagem automatizado

Qualquer tipo de sistema pode ser descrito por um DE, e no apenas sistemas
computacionais. Por exemplo, a Figura 4.1 apresenta um exemplo de DE para um sistema
12
Diagrama que considera a varivel tempo, relacionando os elementos modelados com a passagem do
tempo.
39
de porto de garagem automatizado13. Procure interpret-lo com base nos comentrios

inseridos em itlico e no conhecimento que voc tem desse tipo de sistema, muito comum
nas residncias em geral (edifcios e casas). Depois, confira com a descrio dada a seguir.
O DE acima poderia ser lido assim: Quando o porto acabar de ser montado, ele
iniciar o seu funcionamento no estado Fechado (estado apontado pelo n indicador de
estado inicial), correspondendo situao em que o porto est fechado e aguarda o
acionamento manual do controle. Na entrada desse estado (evento entry), o passo do motor
configurado para o sentido abrir, atravs da ao Motor sentido abrir (isso para que, ao
ser ligado, o motor abra o porto). Quando o evento de acionar o controle ocorrer (controle
acionado), haver uma transio de estado o sistema sai do estado Fechado e vai para o
estado Abrindo. No momento dessa transio, a ao nela indicada ligar sinalizador,
executada14. Na entrada do estado Abrindo (evento entry), executada a ao Ligar motor,
o que faz com que a porto inicie sua abertura. Nesse estado, existem dois estados de
destino possveis - o estado Aberto e o estado Entreaberto, dependendo do evento que
ocorrer primeiro: abertura completada ou acionamento do controle, respectivamente.
Observe que, na sada do estado Abrindo (evento exit), ser executada a ao Desligar
motor. Caso ocorra a transio para o estado Aberto, a entrada nesse estado (evento entry)
determina a execuo da ao Motor sentido fechar, enquanto que se a transio for para o
estado Entreaberto, a ao a ser executada na entrada do estado ser Inverter sentido do
motor. No estado Entreaberto, existem duas transies de sada uma para o estado
Abrindo e outra para o estado Fechado. Ambas so acionadas mediante o mesmo evento
Controle acionado. Ento, o que vai determinar qual delas ocorrer a condio de
guarda: se, no momento do acionamento do controle, o motor estiver no sentido abrir, o
estado de destino ser Abrindo; j se o motor estiver no sentido fechar, o estado de destino
ser Fechando. Observe que apenas uma das duas condies ser verdadeira, o que garante
o determinismo do DE15. Se durante o fechamento do porto (portanto, enquanto o porto
est no estado Fechando), ocorrer o evento de ser detectado um obstculo, haver uma
transio de retorno direto ao estado Abrindo, antecedida da execuo da ao de mudar o
sentido do motor para abrir. Se no for detectado nenhum obstculo durante o fechamento,
ele ser completado e ocorrer uma transio para o estado Fechado, antecedida pela ao
desligar sinalizador.
[DE-Lab1]
O sistema de porto automtico descrito no DE da Figura 4.1 deve
passar a incluir um dispositivo de segurana que comande
automaticamente o fechamento do porto, caso ele permanea mais de
20 segundos aberto (ou entreaberto) sem que o controle seja acionado.
Altere o DE para refletir essa mudana no sistema (Obs.: Caso sinta
dificuldade em obter o novo DE, no se preocupe; estude primeiro o
contedo da prxima seo, e ento retorne tarefa).
13
14
15
Os comentrios em itlico no fazem parte do diagrama, servindo apenas para identificar os principais
elementos do mesmo.
O sinalizador aquele sistema de alerta sonoro e visual (luzes piscando), que fica do lado de fora da
garagem e serve para indicar aos transeuntes que o porto est aberto (ou entreaberto).
Um DE determinstico quando em qualquer estado apenas uma transio de sada pode ser acionada.
40
4.2.
Elementos de um DE
A Figura 4.2 mostra os elementos bsicos que compem um DE: estados, eventos,
transies, atividades, aes, e condies de guarda.
Figura 4.2: Elementos de um DE e sua representao grfica

[Sequncia de mudana de estado]
Para que uma transio ocorra preciso que a condio de guarda seja verdadeira (caso
exista). Ento, no momento em que uma transio ocorre, a sequncia de eventos,
atividades e aes obedece seguinte ordem:
1.
Ocorre o evento associado transio;
2.
interrompida a atividade associada ao estado de origem (Estado 1), caso ela no
tenha j terminado;
3.
executada a ao sada (exit) do estado de origem;
4.
executada a ao associada transio;
5.
executada a ao entrada (entry) do estado de destino (Estado 2);
6.
iniciada a atividade associada ao estado de destino.
O texto a seguir detalha cada um dos elementos bsicos de um DE.
Estados
Um estado uma condio ou situao na vida de um objeto16, durante a qual o objeto
satisfaz alguma condio, realiza alguma atividade ou espera por algum evento. Por
exemplo, os estados civis de uma pessoa: solteira, casada, viva, separada, divorciada, etc.
Desde a instante de sua criao, at a sua eliminao, um objeto passar por diversos
estados distintos, mostrando uma evoluo ao longo do tempo. O DE o diagrama que se
incumbe de mostrar os estados em que o objeto pode estar em cada instante e como ele
passa de um estado a outro, durante o sua existncia.
Uma questo que o modelador deve responder logo de incio : que estados devem
estar representados no DE de um sistema? Os estados a considerar so aqueles que
produzem respostas diferentes aos eventos do sistema. Para exemplificar, considere o DE
da Figura 4.1. Ele no pode ter apenas o estado Fechado (correspondente situao na
qual o porto se encontra fechado), pois o evento de acionamento do controle em uma
situao diferente como aquela em que o porto est aberto, produz uma resposta
diferente do sistema: em vez do porto comear a abrir, ele comea a fechar. Dessa forma,
conclui-se pela necessidade de acrescentar um novo estado: o estado Aberto, que
16
Objeto aqui, tomado em um sentido amplo: um sistema ou parte dele.
41
representa a situao do porto se encontrar aberto. E o mesmo tipo de raciocnio justifica

a introduo dos demais estados visualizados na Figura 4.1.
Quando se considera especificamente um objeto de software, podemos assumir uma
interpretao mais precisa para o conceito de estado: o estado do objeto dado pelo
conjunto dos valores de seus atributos e pelo conjunto das ligaes dele com outros objetos
do sistema, em um instante considerado. Como se pode imaginar, essa definio, embora
precisa, traz dificuldades operacionais ao conduzir, em geral, a um nmero demasiado
elevado de estados em que o objeto pode estar, pois basta mudar o valor de um atributo do
objeto ou alterar algo em uma de suas ligaes com outros objetos, para se obter um novo
estado. Felizmente, o mesmo critrio apresentado anteriormente ou seja, aquele de
considerar apenas os estados que produzem respostas distintas para os eventos do sistema
reduz esse amplo conjunto de estados possveis a uns poucos efetivamente relevantes para
o DE do objeto.
Eventos
Um evento uma ocorrncia significativa que tem uma localizao no tempo. Considerase que todo evento instantneo, ou seja, no tem durao ou ela insignificante (do que
decorre, por exemplo, que um evento no pode ser interrompido).
O DE da Figura 4.1 mostra diversos eventos, tais como, controle acionado, abertura
completada, fechamento completado, eventos de entrada (entry) e de sada (exit) dos
estados, etc. Vemos, portanto, que um evento sempre motiva uma resposta do sistema, que
pode ser uma transio (mudana) de estado como o caso do evento abertura
completada, ou simplesmente a execuo de uma ao17 como no caso dos eventos entry
e exit presentes nos diversos estados do DE, ou ambos como no evento fechamento
completado, que causa a transio do estado Fechando para o estado Fechado e a execuo
da ao desligar sinalizador.
Um evento , comumente, um sinal enviado de uma parte do sistema a outra parte
dele (por exemplo, de um objeto a outro do sistema) que, ao ser recebido, aciona a
execuo de uma operao prevista no (objeto) receptor. Exemplificando com a Figura 4.1:
quando o evento abertura completada enviado pelo (objeto) sensor de abertura e chega
ao (objeto) controlador do motor, esse ltimo executa uma operao capaz de mudar o
sentido do motor para fechar.
[DE (protocolo) de uma classe]
Quando o DE se refere a uma classe de objetos de software, normalmente os eventos nele
presentes correspondem a operaes daquela classe, e portanto, esses eventos podem ser
especificados como mensagens no formato nome-operao(parmetros). Isso ilustrado
na Figura 4.3, que mostra o DE elaborado para modelar o comportamento dos objetos da
classe Pedido, do sistema Restaurante.
17
Ou de uma atividade, caso o estado especifique uma atravs da clusula do (vide Figura 4.2).
42
Figura 4.3: DE (protocolo) da classe Pedido do sistema Restaurante

Pelo DE da Figura 4.3, todo pedido comea no estado Aberto (a partir do momento
de sua criao no sistema). Quando um pedido est no estado Aberto, quatro eventos
exigem resposta do sistema: a) cancelarPedido(), que causa a transio do pedido para o
subestado18 Cancelado se a refeio ainda no tiver sido servida19; b)
pendurarNota(cliente), que causa a transio do pedido para o subestado Pendurado; c)
pagarNota(vlEntregue, dtPagto), que causa a transio do pedido para o subestado Pago; e
d) pedirNota(cliente), que causa uma transio reflexiva. Uma transio reflexiva
quando seus estados origem e destino so o mesmo estado. Por fim, para um pedido no
estado Pendurado, o evento associado execuo da operao pagarNota(vlEntregue,
dtPagto) causa a transio para o estado Pago.
Um DE como o exemplificado na Figura 4.3, que descreve uma classe do sistema e
tem os eventos associados s transies nomeando operaes dessa classe, define o
protocolo de utilizao, ou o ciclo de vida, dos objetos da classe. Ou seja, ele especifica
que operaes da classe podem ser chamadas em cada estado e em que condies, e
portanto, especifica as sequncias permitidas de chamadas de operaes da classe.
Normalmente, um DE desse tipo no possui eventos/aes ou atividades internos aos
estados (entry, exit, do).
Nem todas as operaes previstas em uma classe aparecem no DE que define o
protocolo dela, mas apenas aquelas que causam mudana de estado em objetos da classe,
ou que tem como pr-condio um estado do DE. Um exemplo desse ltimo caso a
operao pedirNota(cliente), no DE da classe Pedido (Figura 4.3): embora ela no cause
mudana de estado em objetos da classe Pedido, ela aparece no DE dessa classe por ter
como pr-condio o (objeto) pedido estar no estado Aberto.
18
19
Subestado um estado contido dentro de outro estado o estado composto. Maiores informaes sobre
subestados e estados compostos so fornecidas mais adiante nesse captulo.
Caso contrrio, ou seja, se a refeio j tiver sido servida, o evento no produzir a transio.
43
[Um parnteses... Estados compostos]

A Figura 4.3 apresenta ainda outra novidade: o estado composto Fechado, que engloba os
subestados Cancelado, Pago e Pendurado. Como a transio associada ao evento delete()
tem esse estado composto como estado origem, pode-se afirmar que um pedido para ser
apagado (deletado) precisa estar em um desses subestados. Maiores informaes sobre
estados compostos sero dadas mais adiante.
[Evento temporal ou de mudana]
Alm dos eventos disparados pelo prprio sistema em anlise, um evento pode utilizar o
tempo, ou o teste de um condio qualquer, para definir o momento do seu disparo. So,
respectivamente, os chamados eventos temporais e os eventos de mudana, explicados a
seguir.
Um evento temporal pode ser relativo ou absoluto. Um evento temporal relativo
especifica que o seu disparo acontece aps o transcurso de um certo perodo de tempo.
expresso da forma after(perodo-de-tempo), como por exemplo, after(5 segundos), ou da
forma after timeout, quando no se deseja precisar o perodo de tempo. Um evento
temporal absoluto utiliza a chegada de um certo instante de tempo (data e/ou hora) como
disparador do evento. A forma geral desse tipo de evento when(instante-de-tempo), como
por exemplo em when(11:59).
Um evento de mudana um evento cujo disparo depende de uma dada condio se
tornar verdadeira, como em when(altitude < 1000m). Sua forma geral : when(expressobooleana).
Transies
Uma transio uma relao entre dois estados, indicando que um objeto no estadoorigem (estado de onde parte a transio) realizar uma certa ao (opcional) e passar ao
estado-destino quando um evento ocorrer e se uma condio (de guarda) (opcional) for
satisfeita.
[Transio automtica]
Eventualmente, uma transio pode no ter um evento especificado para o seu disparo,
caso em que o evento est implicitamente definido como sendo o trmino da execuo da
atividade (do/atividade) associado ao estado-origem da transio. Tais transies so
denominadas automticas.
Duas transies saindo de um mesmo estado-origem devem ter eventos distintos ou
condies mutuamente exclusivas, para que o DE seja determinstico.
Se em um dado estado, ocorrer um evento que no corresponde a qualquer das
transies que partem daquele estado, nenhuma transio ser disparada e o evento ser
ignorado.
Atividades
Uma atividade um processo de execuo continuada, no atmico. Disso decorrem as
seguintes caractersticas: tem durao no tempo e pode ser interrompida (diferentemente
das aes, que no tem durao e, portanto, no podem ser interrompidas).
Toda atividade no DE est associada a um estado atravs da clusula do/atividade.
Sua execuo comea na entrada do estado e termina por ela prpria ou interrompida na
sada do estado (ou seja, interrompida pelo evento que causa a transio para outro
estado).
44
O DE da Figura 4.4 descreve o (sistema de) negcio de um restaurante e ilustra a

utilizao de atividades.
Figura 4.4: DE do negcio de um restaurante

Uma possvel leitura para o diagrama da Figura 4.4 seria: Desde sua abertura pela
primeira vez, e a cada dia, quando chega a hora de funcionar, o restaurante entra em
funcionamento no estado Preparando abertura. Ao entrar nesse estado, executada
primeiramente a ao Ligar energia e depois se inicia a atividade de Preparar atendimento
(reveja a Figura 4.2 e recorde a sequncia em que eventos, atividades e aes ocorrem).
Quando ocorrer o evento temporal chega a hora de abrir, a atividade Preparar
atendimento ser interrompida (se no tiver terminado ainda) e, em seguida, a ao Abrir
portas ser executada. O restaurante passa, ento, ao estado Aberto ao pblico e a
atividade Atender clientes se inicia imediatamente. Quando ocorrer o evento temporal
chega a hora de fechar, primeiramente a atividade Atender clientes interrompida, depois
a ao Fechar portas executada e, por fim, o restaurante entra no estado Preparando
fechamento. Assim que ocorre a entrada nesse estado, inicia-se a atividade Arrumar o
restaurante e o restaurante passa a aguardar a sada do ltimo cliente. Quando ocorrer de
sair o ltimo cliente e a atividade de arrumao estiver completada, primeiramente ser
executada a ao Desligar energia, depois a ao de Fechar o restaurante e, em seguida, o
restaurante passar ao estado Fechado. nesse estado que, um dia, o restaurante encerrar
definitivamente a sua existncia.
Aes
Uma ao um processo atmico de execuo instantnea (sem durao), que resulta em
uma mudana de estado ou no retorno de um valor. Por no ter durao, no pode ser
interrompida.
Ocorre em resposta a um evento, seja dentro dos estados ou nas transies entre
estados. As aes internas aos estados so de trs tipos (Figura 4.2, pg. 41):
45
Ao entrada do estado: especificada atravs da clasula entry/ao, a ao

executada imediatamente aps a entrada no estado. Equivale a associar a ao a cada
transio que entra no estado.
Ao sada do estado: especificada atravs da clusula exit/ao, a ao
executada imediatamente antes da sada do estado. Equivale a associar a ao a cada
transio que sa do estado.
Ao em resposta a um evento interno ao estado: especificada atravs da clusula
evento/ao, onde evento a designao de um evento. Nesse caso, a ao ser
executada toda vez que o evento ocorrer, enquanto o sistema ou objeto permanecer
no estado. Se uma atividade estiver sendo executada, ela no interrompida.
Estados compostos e subestados sequenciais

As figuras 4.3 e 4.4, apresentadas anteriormente, mostraram a utilizao de estados
compostos aqueles que contm subestados. o caso do estado Fechado no DE da Figura
4.3 e do estado Em funcionamento no DE da Figura 4.4. A Figura 4.5 (adiante) acrescenta
outros exemplos de estados compostos (o texto em itlico so comentrios que no fazem
parte do diagrama).
Figura 4.5: Estados civis de uma pessoa (utilizando estados compostos)

A denominao subestados sequenciais pode ser justificada assim: so subestados
porque esto encaixados dentro de um estado maior o estado composto, e so sequenciais
por no ser possvel estar em dois subestados do estado composto simultaneamente. Estar
no estado composto estar em algum dos seus subestados sequenciais. Por outro lado,
estar em um subestado estar tambm no estado composto que o contm; ou seja, o estado
composto pode ser visto como uma generalizao (superestado) dos seus subestados.
46
Saiba mais:
Na verdade, possvel estar em dois subestados de um estado composto
ao mesmo tempo, mas para isso, o estado composto deve ser subdividido
em duas ou mais regies de concorrncia. Dois subestados dentro da
mesma regio de concorrncia so sequenciais, mas se cada um estiver em
uma regio diferente, so concorrentes (consulte a bibliografia ou a web
para maiores informaes sobre esse assunto).
Um estado composto tem ainda as seguintes caractersticas:

Pode ser estado inicial do DE (como na Figura 4.4) ou final (como nas figuras 4.3 e
4.5);
Pode-se definir transies com origem no estado composto (como na Figura 4.5), o
que equivale a vrias transies, cada uma com origem em um subestado do estado
composto; isso contribui para a legibilidade do DE, pois tende a reduzir
consideravelmente o nmero de transies do diagrama;
Pode-se definir transies com destino no estado composto (como na Figura 4.4), o
que equivale a definir a mesma transio com destino no estado inicial do estado
composto aquele apontado pelo n indicador de estado inicial, o qual precisa estar
definido;
Pode-se tambm definir transies que atravessam o estado composto, ou seja, que
tem origem ou destino em seus subestados (como nas figuras 4.3, 4.4 e 4.5);
Pode-se detalhar o estado composto separadamente, ou seja, exercitar abstrao
durante a elaborao de um DE;
Um estado composto pode ter todas as propriedades dos estados simples, mas
normalmente s tem o nome, que mesmo assim opcional:
Pode ter ao de entrada (entry) e de sada (exit): ao entrar no estado composto, a

ao de entrada nele executada primeiro, para depois se executar a ao de entrada
no subestado de destino; ao sair do estado composto, a ao de sada do subestado de
origem executada primeiro, para depois se executar a ao de sada do estado
composto;
A atividade do estado composto definida pelos subestados e transies entre eles,

ou seja, pelo DE que ele contm; entretanto, pode-se dar um nome atividade do
estado composto (com a clusula do/atividade), e detalhar essa atividade
separadamente (ou seja, detalhar o estado composto separadamente).
Saiba mais:
Existem ainda outros elementos que podem fazer parte de um DE, embora
menos comumente utilizados do que aqueles vistos at agora, tais como:
subestados concorrentes, variveis de um estado, transies complexas,
eventos deferidos, estados histricos, etc. Voc pode aprender sobre eles
atravs da bibliografia sugerida ou da web.
4.3.
Relao com outros modelos
O DE se relaciona com os modelos estudados at aqui. No que diz respeito ao modelo de

UCs, como o DE expressa os estados e as transies entre os estados de um objeto ao
longo de toda a sua existncia, ento o DE descreve a evoluo desse objeto ao longo de
todos os (casos de) usos do sistema. Ou seja, cada DE tem uma ligao com todos os UCs
nos quais o objeto descrito no DE tem participao. Portanto, a seguinte regra de
47
consistncia deve ser satisfeita por esses modelos: todas as transies entre estados do DE
devem poder ser mapeadas em passos ou eventos descritos em um ou mais UCs e, no
sentido inverso, os passos descritos nos UCs devem corresponder a transies no DE ou se
deve constatar que tais passos mantm o objeto em estados do DE previamente alcanados
por ele. Essa verificao pode levar descoberta de inconsistncias entre os modelos ou
omisses neles.
No que diz respeito ao diagrama de classes, a relao com o DE mais direta e
simples: os eventos nas transies devem corresponder a operaes definidas na classe
modelada pelo DE e, no sentido inverso, toda operao definida na classe do DE deve
corresponder a um evento de transio no DE ou se deve constatar que a operao mantm
o objeto em um estado previamente alcanado por ele.
[DE-Lab2]
Modele, atravs de um diagrama de estados, o funcionamento do
seguinte sistema de portas:
entrada de um edifcio existem duas portas uma porta interior
e uma porta exterior. Por razes de segurana, as duas portas no podem
estar abertas simultaneamente. De ambos os lados (interior e exterior) de
cada porta, h um boto de abrir. Quando se aberta o boto de abrir uma porta, se a outra
porta estiver trancada, a porta destrancada durante 5 segundos, permitindo a sua abertura
manual. As portas fecham-se por ao de molas e ficam imediatamente trancadas. Em cada
porta h um sensor que detecta o seu fechamento.
[DE-Lab3]
Elaborar um DE para a classe de objetos Mesa, do sistema Restaurante.
48
5.
Diagrama de Sequncia
5.1.
Introduo
Captulo 5: Diagrama de Sequncia
O Diagrama de Sequncia (DS) estabelece uma ponte entre o modelo de UCs e o modelo
de classes de objetos, pois explica como os objetos do sistema devem interagir para
realizar os requisitos funcionais especificados em um caso de uso.
Da mesma forma que o diagrama de estado, o DS est entre os diagramas
comportamentais da UML, isto , modela aspectos dinmicos, que levam em conta a
passagem do tempo.
5.2.
DS DSS
O DS detalha um cenrio de caso de uso20 e pode ser de dois tipos:
DS caixa-preta ou de sistema (DSS): mostra a interao entre os atores e o sistema,
para a realizao do cenrio do caso de uso;
DS caixa-branca: mostra a interao entre os objetos do sistema, para a realizao
do cenrio do caso de uso.
[Exemplo de DS de Sistema]
Figura 5.1: DS de sistema (DSS) Caso de uso Pedir a nota (sistema Restaurante)
O diagrama da Figura 5.1 exemplifica um DS de sistema (DSS) para o caso de uso Pedir a
nota, do sistema Restaurante. O cenrio descrito no DSS aquele em que o cliente ao qual
a nota se destina um cliente habitual do restaurante. Segue uma breve leitura desse
diagrama:
1.
O ator Caixa solicita ao sistema a emisso de uma nota (de refeio), atravs do
envio da mensagem emitirNota.
20
Um cenrio de caso de uso uma sequncia especfica de aes que realiza um caso de uso (vide seo
pgina 22).
49
2.
3.
4.
O sistema retorna uma mensagem solicitando a identificao do pedido cuja nota

deve ser emitida. A varivel ped representa a resposta a essa mensagem, ou seja, a
identificao desse pedido, fornecida pelo Caixa.
O sistema envia uma mensagem solicitando a identificao do cliente habitual para o
qual a nota ser emitida. A varivel cli representa a identificao desse cliente,
fornecida pelo Caixa.
O sistema emite a nota.
[Exemplo de DS]
O diagrama da Figura 5.2 exemplifica um DS caixa-branca para o mesmo cenrio de caso
de uso (Pedir a nota, para um cliente habitual) descrito na figura anterior. Diferentemente
do DSS, esse diagrama detalha a interao entre os objetos do sistema, para a realizao do
cenrio: os objetos mandam mensagens entre si, que correspondem a chamadas de
operaes. Os objetos so representados por retngulos que aparecem na parte superior do
diagrama, enquanto que as mensagens so representadas por setas que vo de um objeto a
outro.
objeto
mensagem
Figura 5.2: Diagrama de sequncia Caso de uso Pedir a nota (sistema Restaurante)
Uma leitura parcial do diagrama da Figura 5.2 :
O objeto ped (da classe Pedido) recebe a mensagem pedirNota(cli). Essa mensagem
do tipo chamada de operao e faz com que o objeto execute a operao pedirNota(),
com o argumento cli contendo a identificao do (objeto) cliente ao qual a nota se destina.
O objeto ped envia a mensagem vlNota() para ele mesmo, o que causa a ativao da
operao de mesmo nome, com o objetivo de calcular o valor da nota a ser emitida.
O objeto ped envia ao objeto inclui uma sequncia de mensagens vlItem(), uma para
cada item de consumo (prato ou bebida) includo no pedido. A presena da varivel vl
indica o valor retornado pelo objeto inclui, como resultado de cada execuo da operao
vlItem().
... etc.
50
Outros elementos mostrados no diagrama da Figura 5.2 sero explicados mais

adiante.
[DS-Lab1]
a) Estabelea a correspondncia correta entre as colunas da esquerda e
da direita:
( ) Diagrama de sequncia
( ) Mostra o comportamento de um nico objeto ao

longo da realizao de vrios UCs.
( ) Diagrama de estados
( ) Mostra o comportamento de vrios objetos durante

a realizao de um nico UC.
b) Responda: como a varivel tempo est representada no diagrama da Figura 5.2?
5.3.
Elementos do DS
A seguir so descritos diversos elementos grficos utilizados em um DS:
Linha de vida e barras de ativao

O DS fornece indicaes sobre o status dos objetos ao longo do tempo, atravs da
linha de vida e de barras de ativao de um objeto (Figura 5.3). A linha de vida de um
objeto aparece no DS como uma linha tracejada que se estende abaixo do objeto e
representa o tempo de existncia dele, ou seja, o tempo em que o objeto permanece
acessvel na memria do computador. Como voc j deve ter percebido, a sequncia
temporal das mensagens dada pela sua posio vertical no diagrama se a mensagem B
est posicionada abaixo da mensagem A, ento B emitida depois de A.
Figura 5.3: Linha de vida e barras de ativao

51
Durante o tempo de vida de um objeto, haver perodos em que ele estar ativo e
perodos em que ele estar inativo. Um objeto se torna ativo quando tem incio a execuo
de uma de suas operaes, e permanece assim at que essa execuo termine. Isso inclui a
situao em que, durante a execuo da operao, feita uma chamada a outra operao
(de outro objeto) e a operao original fica aguardando o retorno dessa chamada.
No DS, os perodos de atividade de cada objeto so indicados por barras de ativao
retngulos desenhados sobre a linha de vida do objeto, delimitando os perodos de tempo
em que o objeto est ativo. Por exemplo, na Figura 5.3, o objeto i (da classe Inclui) fica
ativo em dois momentos: primeiramente, ao receber a mensagem A, e depois, ao receber a
mensagem B.
Quando um objeto envia uma mensagem para ele prprio, ocorre o empilhamento de
barras de ativao (veja a barra de ativao resultante da mensagem C, na Figura 5.3).
Mensagens
Uma ao de um objeto, capaz de provocar uma resposta de outro objeto, pode ser
modelada como uma mensagem do primeiro para o segundo objeto. Uma mensagem uma
comunicao entre objetos participantes (emissor e receptor), que veicula informao na
expectativa de provocar uma resposta (ao ou atividade). Denotam eventos ou invocao
de operaes. As operaes invocveis para um objeto so aquelas previstas na classe do
objeto, conforme especificado no diagrama de classes.
Uma mensagem representada por uma seta horizontal, do emissor para o receptor,
juntamente com o seu nome e possveis argumentos. Os vrios tipos de mensagens esto
descritos a seguir e ilustrados na Figura 5.4.
Figura 5.4: Tipos de mensagens

52
Mensagem sncrona: O emissor fica parado espera da resposta. Resulta tipicamente

na chamada de uma operao no receptor (e, portanto, inicia uma barra de ativao
nele).
Mensagem assncrona: O emissor no fica parado espera da resposta, mas
prossegue executando aes. Corresponde tipicamente a um envio de sinal entre dois
objetos concorrentes. So utilizadas em ambientes multi-threaded, tais como .NET e
Java, para criar um novo thread (linha de execuo concorrente).
Para compreender a utilidade desse tipo de mensagem, imagine um sistema que

necessite disparar um cronmetro e prosseguir realizando outras aes. Quando o
cronmetro indicar o transcurso de um dado perodo de tempo, algo mais deve ser
realizado antes de finalizar. Um DS descrevendo isso poderia ser o da Figura 5.5. Nele, o
objeto da classe Disparador cria um objeto da classe Cronmetro, atravs de uma
mensagem sncrona de criao de objeto. Como a mensagem enviada sncrona, o objeto
(da classe) Disparador fica aguardando a mensagem de retorno do objeto recm-criado.
Uma vez recebida essa mensagem de retorno, o objeto Disparador envia a mensagem
assncrona disparar para o objeto Cronmetro. Isso iniciar a operao desse objeto
responsvel pela contagem de tempo e, como a mensagem enviada assncrona, o objeto
Disparador prosseguir executando outras aes enquanto o cronmetro conta o tempo.
Quando a contagem de tempo for concluda, o Cronmetro enviar uma mensagem
assncrona para indicar isso e, aps mais algumas aes para arrumar a casa, ter sua
existncia finalizada. Enquanto isso, o Disparador, tendo recebido a mensagem assncrona
(sinal) de tempo esgotado, executa as aes dela decorrentes e se torna inativo.
Figura 5.5: Exemplo de utilizao de mensagem assncrona
53
Mensagem de retorno (de mensagem sncrona): Serve para indicar ao emissor que o
tratamento da mensagem recebida foi concludo e, se necessrio, apresentar um valor
resultante desse tratamento. Esse tipo de mensagem no precisa aparecer no DS
quando se usam barras de ativao, pois a concluso do tratamento da uma
mensagem recebida e, consequentemente, a mensagem de retorno associada, esto
implcitos no final da barra. Alm disso, o valor retornado como resultado do
tratamento da mensagem recebida, se existir, pode estar indicado nessa mesma
mensagem. A Figura 5.6 mostra as duas formas equivalentes de se indicar o valor
retornado ao final do tratamento de uma mensagem.
Figura 5.6: Formas equivalentes de retorno de mensagem
Mensagem de criao: Indica que o receptor um objeto que est sendo criado como
resultado da mensagem. A interpretao tpica (em linguagens como Java e C#) de
uma mensagem de criao sncrona invocar o operador new e chamar a operao
construtora, para a classe indicada na mensagem. Observe a posio mais para
baixo do objeto criado (Objeto 2 Figura 5.4), indicando que o mesmo passa a
existir em um momento posterior ao da criao do emissor (Objeto 1).
Mensagem encontrada (found): Mensagem sem emissor identificado.
Mensagem perdida (lost): Mensagem que no chega a seu receptor de destino.
Mensagem de eliminao (destroy): Mensagem que causa a eliminao do (objeto)
receptor.
Mensagem self: Mensagem de um objeto para ele prprio.
O formato geral (sintaxe) das mensagens :
<retorno> = <nome_da_mensagem>(<parmetro>: <tipo_do_parmetro>, ...):
<tipo_do_retorno>
54
Das partes que compem o formato geral acima, apenas <nome_da_mensagem>

obrigatria. Portanto, so exemplos vlidos de mensagens (Tabela 5.1):
Tabela 5.1: Exemplos vlidos de mensagens (sintaxe)
Mensagem
Comentrio
initialize
Apenas o <nome_da_mensagem>
initialize(code)
<nome_da_mensagem>(<parmetro>)
d = getDescricaoProduto(id)
<retorno> = <nome_da_mensagem>(<parmetro>)
d = getDescricaoProduto(id:ItemID) <retorno> = <nome_da_mensagem>(<parmetro>:
<tipo_do_parmetro>)
d = getDescricaoProduto(id:ItemID): Sintaxe completa (com todas as partes)
DescricaoProduto
Fragmentos de sequncia
Fragmentos de sequncia so trechos delimitados de interaes (mensagens) entre objetos,
aos quais se aplicam operadores que determinam, por exemplo, se o trecho opcional ou
alternativo, ou se deve ser repetido em certo nmero de vezes, etc. A Figura 5.2 (anterior)
mostra dois fragmentos de sequncia, ambos submetidos ao operador loop. O primeiro
deles possui condio (de guarda) para cata item includo no pedido e, portanto, a
interao nele especificada deve ser repetida tantas vezes quanto for o nmero de itens
includos no pedido. Uma condio de guarda uma expresso booleana21 entre colchetes.
Fragmentos de sequncia servem para simplificar diagramas de sequncia complexos.
A Tabela 5.2 apresenta alguns operadores comuns utilizados na especificao de
fragmentos de sequncia:
Tabela 5.2: Alguns operadores de fragmentos de sequncia
Operador
Significado
alt
Alternativa: O fragmento contm duas ou mais sequncias de interao. A
cada sequncia est associada uma condio22. Essas condies devem ser
mutuamente exclusivas e, portanto, apenas uma das sequncias ser
executada: aquela cuja condio for verdadeira.
loop
Iterao: A sequncia de interao contida no fragmento repetida enquanto
a condio de guarda for verdadeira.
opt
Opo: A sequncia de interao condicional, ou seja, sua execuo
depende da condio de guarda ser verdadeira.
ref
Referncia: Faz referncia a um fragmento definido em outro ponto do DS
(reutilizao de fragmento).
par
Paralelismo: O fragmento contm duas ou mais sequncias de interao que
executam em paralelo.
A Figura 5.7 apresenta mais exemplos de fragmentos de sequncia. Observe nela, a
possibilidade de se aninhar um fragmento dentro de outro.
21
22
Expresso cujo resultado da avaliao verdadeiro ou falso.

Tambm denominada condio de guarda.
55
Figura 5.7: Exemplos de fragmentos de sequncia

Os fragmentos opt e loop que envolvem apenas uma mensagem podem ser
substitudos por formas mais simples. No caso do fragmento opt, basta anteceder a
mensagem com uma condio de guarda especificando a condicionalidade. A Figura 5.8
mostra como substituir, de forma equivalente, o fragmento opt exibido na Figura 5.7. No
caso do fragmento loop, basta anteceder a mensagem com um * (asterisco) e,
opcionalmente, com uma condio de guarda especificando quantas vezes, ou at quando,
o loop deve ser repetido. A Figura 5.9 mostra como especificar dessa forma o fragmento
loop exibido na Figura 5.2.
Figura 5.8: Forma alternativa para fragmento opt simples
56
Figura 5.9: Forma alternativa para o fragmento loop simples
Pesquisa:
Procure na bibliografia sugerida ou na web um exemplo de utilizao do
fragmento par e procure interpret-lo.
Saiba mais:
Existem ainda outros operadores para fragmentos de sequncia.
5.4.
Relao com os outros modelos
importante considerar a relao do DS com os demais modelos e diagramas j estudados:

casos e de uso, diagrama de classes e diagrama de estados.
A um nico UC podem corresponder diversos DSs, um para cada cenrio do UC
cenrio bsico e cenrios alternativos. Os objetos utilizados no DS so instncias das
classes previstas no DC. Finalmente, enquanto um DS apresenta o comportamento de
vrios objetos para a realizao de um UC, um diagrama de estados apresenta o
comportamento de um nico objeto, ao longo de todo o seu ciclo de vida, envolvendo,
possivelmente, a realizao de vrios UCs.
[DS-Lab2]
Fazer um diagrama de sequncia (DS) para um cenrio do UC Pagar a
conta do sistema Restaurante. O DS deve utilizar os elementos j
modelados no diagrama de classes: objetos e operaes.
57
6.
Diagrama de Comunicao
6.1.
Introduo
Captulo 6: Diagrama de Comunicao
[O que ]
O Diagrama de Comunicao (DCom) um grafo com objetos (instncias de classes) e
ligaes (instncias de associaes), atravs das quais fluem mensagens numeradas
(diferentemente do DS, onde no se mostra ligaes, mas apenas objetos e mensagens
fluindo entre eles). Nas verses que antecederam a UML 2.0, o DCom era conhecido como
diagrama de colaborao.
O DCom um diagrama comportamental, isto , utiliza a varivel tempo (leva em
conta a passagem do tempo). Compe o grupo dos diagramas de interao da UML,
juntamente com o DS, o diagrama de interao geral e o diagrama de tempo (esses dois
ltimos no estudados aqui).
A Figura 6.1 mostra um exemplo de DCom.
[Exemplo de um DCom e seus elementos]
Figura 6.1: Exemplo de diagrama de comunicao (DCom)

Uma ligao uma conexo entre dois objetos, que possibilita o envio ou
recebimento de mensagens entre eles. Apenas objetos que possuam ligao um com o
outro podem trocar mensagens. Isso vale tanto para o DCom como para o DS, embora
nesse ltimo as ligaes no sejam explicitadas.
Vrias mensagens podem fluir em uma mesma ligao. Cada mensagem entre
objetos especificada atravs de uma expresso e uma pequena seta indicando a direo da
mensagem. A expresso segue o mesmo formato padro utilizado para mensagens no DS
(Captulo 5), mas inclui adicionalmente um nmero de sequncia, para mostrar a ordem de
envio das mensagens:
<nmero_sequncia:> <retorno> = <nome_da_mensagem>(<parmetro>:
<tipo_do_parmetro>, ...): <tipo_do_retorno>
58
Por exemplo, na Figura 6.1 acima, atravs da ligao existente entre os objetos (das
classes) Linha de Pedido e Item de Estoque, fluem duas mensagens do primeiro para o
segundo objeto: 1.1.1: e= existe?(q) e
1.1.2 [e=sim] retirar(q). Os nmeros de
sequncia dessas mensagens (1.1.1 e 1.1.2) indicam um aninhamento de interao e podem
ser explicados da seguinte maneira: o objeto Linha de Pedido recebe a mensagem 1.1 e
envia trs outras; como essas mensagens so enviadas pela operao ativada pela
mensagem 1.1, elas devem ser numeradas como 1.1.1, 1.1.2 e 1.1.3. A ltima parte da
numerao (1, 2, 3) reflete a ordem de envio das mensagens.
A Figura 6.1 mostra ainda trs mensagens condicionais, assim indicadas pela
condio de guarda entre colchetes, colocada aps o nmero de sequncia (1.1.2:
[e=sim] retirar(q), 1.1.2.2: [b=sim] criar() e 1.1.3: [e=no] criar()). Mensagens
condicionais s so enviadas se a condio correspondente for satisfeita. A figura tambm
inclui uma mensagem recorrente ou iterativa, indicada pelo * (asterisco) acrescentado aps
o nmero de sequncia (1.1: * tratar()). Mensagens recorrentes podem ainda ter,
opcionalmente, aps o asterisco, uma condio de guarda para controlar a iterao.
Exemplo: 1.1: *[para cada linha do pedido] tratar(). Nesse caso, a mensagem tratar()
enviada tantas vezes quanto for o nmero de linhas do pedido.
Assim como no DS, as setas que representam mensagens no DCom podem ter uma
das quatro formas apresentadas na Figura 6.2 (embora, mensagens de retorno no sejam
normalmente especificadas no DCom).
Figura 6.2: Tipos de mensagens
[DCom-Lab1]
Em que ordem as mensagens da Figura 6.1 sero enviadas?
6.2.
Comparao com outros modelos
O DCom descreve praticamente o mesmo tipo de informao que o DS, mas d nfase s
relaes entre os objetos que enviam e recebem mensagens (atravs das ligaes),
enquanto que o DS enfatiza a ordem temporal das mensagens. A semelhana com o DS faz
com que o DCom tenha exatamente a mesma finalidade, ou seja, detalhar a interao (a
troca de mensagens) entre objetos, para, por exemplo, verificar se o sistema capaz de
realizar um dado cenrio de UC23. Isso significa que, como os objetos e ligaes que
aparecem no DCom devem ser instncias das classes e associaes presentes no DC, a
elaborao de um DCom (como tambm um DS), serve para verificar a completude do DC,
isto , se ele prev todas as classes e operaes necessrias realizao de um dado
cenrio de UC. Por isso, a elaborao de um DCom pode levar descoberta de novas
classes e operaes no DC.
23
Em um nvel mais baixo de abstrao, tambm pode ser usado para mostrar a interao necessria
execuo de uma operao.
59
Saiba mais:
Uma ligao entre dois objetos no precisa sempre corresponder a uma
associao entre as respectivas classes no DC. Isso porque, dois objetos
de classes no associadas no DC podem se ligar temporariamente durante
a execuo do sistema, atravs de ligaes dinmicas. o caso, por
exemplo, da ligao que se estabelece entre dois objetos, quando um deles
argumento de uma mensagem enviada ao outro objeto.
6.3.
Comparao: DCom DS
O DCom apresenta, alm dos objetos e mensagens trocadas por eles, tambm as ligaes
que os unem, sejam ligaes estticas (previstas no DC) ou dinmicas (estabelecidas
durante a execuo). A Tabela 6.1 estende a comparao entre os dois diagramas,
resumindo os pontos fortes e fracos de cada um.
Diagrama
Sequncia
Comunicao
Tabela 6.1: Comparao entre o DCom e o DS

Pontos Fortes
Pontos Fracos
Mostra claramente a
Cresce obrigatoriamente para a
sequncia e a ordenao, no
direita a cada novo objeto;
tempo, das mensagens;
Consumo desbalanceado de espao
Conjunto maior de opes
(mais horizontal do que vertical).
notacionais.
Economiza espao pode
Maior dificuldade de se perceber a
crescer tanto horizontal
sequncia das mensagens;
quanto verticalmente.
Menos opes de notao.
O DS tem maior poder de expresso do que o DCom, ou seja, nem todo DS tem um
DCom equivalente, mas todo DCom tem um DS equivalente. Notadamente, no DCom no
se pode representar o recebimento de respostas fora de ordem, decorrentes de mensagens
assncronas (Figura 6.3).
Figura 6.3: Respostas fora de ordem em mensagens assncronas

60
[DCom-Lab2]
Quem o melhor (DS ou DCom) quando se trata de:
1.
2.
3.
4.
5.
6.
7.
Quesito
Efetividade na apresentao dos participantes
Apresentao dos links entre participantes
Apresentao da assinatura das mensagens
Suporte a mensagens concorrentes
Suporte a mensagens assncronas
Facilidade de percepo da ordenao das mensagens
Facilidade de criar e manter atualizado o diagrama
6.4.
Vencedor
Traduzindo um DS em um DCom
Normalmente, possvel traduzir um DS em um DCom e vice-versa. Para facilitar, basta

seguir os passos abaixo indicados:
1.
Desenhar os mesmos objetos;
2.
Desenhar as ligaes entre objetos que se comunicam, ou seja, que trocam
mensagens;
3.
Desenhar as mensagens enviadas entre os objetos participantes, na ordem temporal
indicada no DS, numerando-as de acordo com essa ordem.
Para exemplificar a traduo de um DS no DCom equivalente, seguindo os passos
acima, considere o seguinte DS (Figura 6.4):
Figura 6.4: DS a traduzir para DCom

1.
2.
3.
Antes de iniciar a traduo, vejamos como o DS acima poderia ser lido:

A mensagem fazerPgto(vlEntregue), onde vlEntregue o valor ou montante entregue
para o pagamento, enviada a um objeto (annimo) instncia da classe Registrador.
O transmissor no est identificado (mensagem found).
O objeto de Registrador envia a mensagem fazerPgto(vlEntregue) para um objeto
instncia da classe Venda.
O objeto de Venda cria uma nova instncia da classe Pagamento, passando
vlEntregue como argumento para o mtodo construtor dessa classe.
61
Agora, vamos aplicar os passos indicados acima para a traduo do DS da Figura 6.4
no DCom equivalente:
1 passo: Desenhar os mesmos objetos (Figura 6.5)
Figura 6.5: Primeiro passo de traduo Objetos

2 passo: Desenhar as ligaes entre objetos que se comunicam (Figura 6.6)
Figura 6.6: Segundo passo de traduo Ligaes

3 passo: Introduzir as mensagens (Figura 6.7)
Figura 6.7: Terceiro passo de traduo Mensagens
[DCom-Lab3]
Elabore um roteiro de passos (como o apresentado acima) para a
traduo de um DCom no DS equivalente.
[DCom-Lab4]
Desenhe o DCom equivalente ao DS da Figura 5.2 (do captulo anterior).
62
7.
Diagrama de Atividade
7.1.
Introduo
Captulo 7: Diagrama de Atividade
[O que ]
O Diagrama de Atividade (DA) descreve os fluxos de aes de uma atividade 24. Uma
atividade composta de passos a serem executados para levar algo (negcio, sistema,
objeto, etc.) de um estado a outro. As aes so os passos de uma atividade. Executar uma
atividade executar um fluxo de aes descrito no DA da atividade. Portanto, o DA
descreve como executar uma atividade, ou seja, quais so as aes envolvidas e em que
ordem elas devem ser executadas.
A atividade descrita no DA pode ser de um nvel qualquer de abstrao: processo de
negcio, UC de um sistema, operao do DC, etc.
O DA um diagrama comportamental da UML, pois leva em conta a passagem do
tempo, atravs do ordenamento (no tempo) das aes para a execuo de uma atividade.
Ele constitui uma forma alternativa ao lado do diagrama de sequncia e do diagrama de
comunicao, para se descrever o comportamento de um sistema.
[Exemplo de DA]
A Figura 7.1 mostra um exemplo de DA que descreve um processo de negcio: como
realizar uma venda por telefone.
24
Ou processo.
63
Figura 7.1: Exemplo de diagrama de atividade (DA) venda por telefone

O DA da Figura 7.1 poderia ser lido, resumidamente, assim: O vendedor, ao atender
um cliente que deseja adquirir um ou mais produtos, deve em primeiro lugar consultar os
dados do cliente. Pode ser que o cliente ainda no possua cadastro junto loja, caso em
que esse cadastro deve ser providenciado antes da abertura do pedido. Para cada produto
solicitado pelo cliente, caso ele exista em estoque, ele adicionado ao pedido. Uma vez
concludo o pedido, um boleto de pagamento gerado e enviado por e-mail ao cliente. O
cliente tem at trs dias teis para efetuar o pagamento na rede bancria; depois disso, o
boleto perde a validade. O departamento financeiro fica aguardando a confirmao do
pagamento, enquanto o setor de entregas embala os produtos. Se o pagamento for efetuado,
o departamento financeiro emite a nota fiscal e a envia ao setor de entregas para que ele
despache os produtos e d baixa no estoque dos mesmos. Caso contrrio, o pedido
cancelado pelo departamento financeiro e o setor de entregas deve retornar os produtos ao
almoxarifado.
64
7.2.
Elementos do DA
Um DA pode estar dividido em parties, com o objetivo de indicar de quem a

responsabilidade pela execuo das aes que compem a atividade. O DA da Figura 7.1,
por exemplo, possui quatro parties: Cliente, Vendedor, Depto. Financeiro e Setor
Entregas. O Cliente responsvel pela execuo de algumas aes da atividade, incluindo
as seguintes: Liga e fornece identificao, Escolhe produto, Faz pagamento. Se o DA
estiver descrevendo um negcio, as parties podem representar unidades, divises ou
organizaes do negcio; se ele estiver descrevendo um sistema, as parties podem ser
outros sistemas, subsistemas, ou mesmo objetos do sistema.
Um DA contm diferentes tipos de ns e transies entre os ns. A Figura 7.2 mostra
a representao grfica de cada um dos principais tipos de ns e transies de um DA.
Com exceo dos ns de subatividade e de conexo, os demais esto exemplificados na
Figura 7.1. Todos eles so comentados no texto a seguir.
Figura 7.2: Representao grfica dos ns e transies de um DA
Ao
Uma ao representa um passo nico dentro de uma atividade, no sentido em que no
ser decomposto em passos menores, na descrio da atividade. Pode ser um clculo (por
exemplo: calcular imposto) ou um procedimento (por exemplo: fazer cadastro).
Quando a execuo de uma ao termina, ocorre automaticamente uma transio
para outro n do diagrama. O n de destino indicado por uma transio de fluxo de
controle ou de fluxo de dados.
Transies
[Transio de controle]
Uma transio de controle indica, para cada n do DA, o prximo n a ser executado.
Pode ou no estar associada a uma condio de guarda que expressa uma condio para
que a transio ocorra. Transies de controle so representas por setas contnuas (Figura
7.2).
[Transio de dados]
Uma transio de dados responsvel por transmitir informao til usualmente objetos
a atores (titulares das parties) ou aes. So representadas por setas tracejadas (Figura
7.2).
N objeto
Representa um objeto que criado, utilizado ou modificado pelas aes a ele ligadas.
65
Por exemplo, na Figura 7.1 vemos que o objeto Boleto criado pela ao Gera e
envia boleto e utilizado na ao Faz pagamento. Outro objeto representado naquela
figura o objeto Nota fiscal, criado na ao Emite nota fiscal e utilizado em duas outras
aes: Despacha pedido e D baixa no estoque.
Saiba mais:
Existem alguns tipos especficos de objetos, dentre os quais se destaca o
depsito de dados. Um objeto desse tipo armazena (copia) todos os
objetos que passam por ele. Consulte a bibliografia sugerida para saber
mais detalhes sobre esse tipo de objeto.
N Incio da Atividade
Indica a primeira ao a ser executada na atividade. No exemplo da Figura 7.1, esse n
aponta a ao Liga e fornece identificao, executada pelo Cliente, como sendo a primeira
ao a ser executada quando se inicia a atividade de Venda por telefone.
Deciso e Aglutinao
[N de deciso]
Um n de deciso representado graficamente por um losango (Figura 7.2) e significa um
ponto de deciso, onde apenas um dos fluxos de sada ser ativado com base na deciso
tomada. A deciso descrita atravs de condies de guarda colocadas junto aos fluxos de
sada.
A atividade modelada no exemplo da Figura 7.1 tem, logo no incio, um n de
deciso com as condies de guarda [cliente j cadastrado] e [no cadastrado], indicando
que a deciso a ser tomada pelo Vendedor se o cliente j possui ou no cadastro com ele.
Caso possua, a prxima ao a ser realizada ser a escolha, pelo Cliente, de um produto a
adquirir; caso contrrio, a prxima ao o Vendedor fazer o cadastro do cliente.
[N de aglutinao]
Um n de aglutinao serve para aglutinar25 dois ou mais fluxos de entrada, em um nico
fluxo de sada. Apesar de compartilhar com o n de deciso o mesmo smbolo grfico o
losango, o n de aglutinao se diferencia do n de deciso pelo nmero de fluxos
entrando e saindo do losango. Em um n de deciso chega um nico fluxo e saem dois ou
mais, enquanto que em um n de aglutinao chegam dois ou mais fluxos e sai apenas um.
Existem vrios ns de aglutinao na descrio da atividade da Figura 7.1, como por
exemplo, aquele que aglutina os dois fluxos alternativos decorrentes da deciso sobre se o
cliente j possui ou no cadastro. Essa aglutinao estabelece que, em ambos os casos, a
prxima ao a ser executada Escolhe produto.
No h espera ou sincronizao em um n de aglutinao, ou seja, quando a
execuo da atividade atinge o n atravs de um dos fluxos de entrada, a execuo
prossegue imediatamente atravs do fluxo de sada. Se a execuo atingir o n de
aglutinao por mais de um fluxo de entrada, a ao apontada pela transio de sada ser
executada mais de uma vez.
25
Em ingls, merge.
66
possvel combinar aglutinao e deciso em um nico losango, conforme indicado

na Figura 7.3.
(a)
(b)
Figura 7.3: (a) Combinao de aglutinao e deciso; (b) Significado da combinao

Observe que essa combinao caracterizada pela existncia de mais de um fluxo de
entrada, juntamente com mais de um fluxo de sada, no mesmo losango (Figura 7.3a). Tal
combinao pode ser considerada uma forma de se abreviar o modelo ilustrado na Figura
7.3b, ou seja, equivalente a um n de aglutinao com todos os fluxos de entrada
mostrados na Figura 7.3a, seguido por um n de deciso com todos os fluxos de sada
mostrados na Figura 7.3a.
Um exemplo dessa combinao pode ser visto na atividade da Figura 7.1: o n
associado s condies de guarda [pedido concludo] e [pedido no concludo] uma
combinao de aglutinao e deciso.
Ns de finalizao
Existem dois tipos de ns de finalizao: n final de ramo (de execuo) e n final (de
atividade) (ver Figura 7.2). O n final de ramo de execuo finaliza um ramo de
execuo26 dentro da atividade (que pode ter outros ramos de execuo acontecendo de
forma concorrente). Apenas o ramo que contm esse n finalizado; os demais ramos de
execuo concorrente continuam ativos. J o n final de atividade finaliza todos os ramos
de execuo porventura ativos e, portanto, finaliza a atividade.
Na Figura 7.1 vemos que se o Cliente resolver no pagar o boleto referente ao seu
pedido, o sua participao na atividade cessa, mas a atividade continua com dois outros
ramos de execuo concorrente um ramo onde o Departamento Financeiro cancela o
pedido (aps 3 dias teis sem receber a confirmao do pagamento) e o Setor de Entregas
retorna os produtos do pedido ao almoxarifado, e o outro ramo onde o Setor de Entregas
embala os produtos do pedido e fica aguardando a chegada da nota fiscal (o que no
ocorre, j que estamos considerando o caso em que o Ciente resolveu no efetuar o
pagamento do pedido).
[DA-Lab1]
Por que seria errado substituir o n final de ramo de execuo, mostrado
na partio do Cliente da Figura 7.1, por um n final de atividade?
26
Em ingls: thread.
67
Ramificao e Juno
[N de ramificao]
O n de ramificao (em ingls, fork) representado graficamente por uma barra (Figura
7.2) aonde chega um nico fluxo de entrada e saem dois ou mais fluxos de sada. Nesse
aspecto anlogo a um n de deciso, mas, enquanto este seleciona e ativa um nico fluxo
de sada, o n de ramificao ativa ao mesmo tempo (concorrentemente) todos os fluxos
que saem dele.
A Figura 7.1 tem dois ns de ramificao. O primeiro segue a ao Gera e envia
boleto e dispara trs fluxos de sada concorrentes: (1) enquanto o Cliente decide se ir ou
no efetuar o pagamento do boleto e, eventualmente, realiza esse pagamento, (2) o Depto.
Financeiro fica aguardando a confirmao do pagamento do pedido ou at vencer o prazo
de validade do boleto (trs dias teis), para ver se conclui a transao com a emisso da
nota fiscal ou se cancela o pedido, respectivamente; paralelamente a isso tudo, (3) o Setor
de entregas embala os produtos e, uma vez de posse da nota fiscal do pedido, despacha e
d baixa dos produtos no estoque. Essas duas ltimas aes (Despacha o pedido e D
baixa no estoque) podem ser realizadas em paralelo (ao mesmo tempo) pelo Setor de
entregas, uma vez que esto em fluxos distintos que saem do segundo n de ramificao
presente na Figura 7.1.
[N de juno]
Um n de juno (em ingls, join) serve para juntar dois ou mais fluxos de entrada
concorrentes, ou seja, que esto executando em paralelo, em um nico fluxo de sada. Ele
compartilha com o n de ramificao o mesmo smbolo grfico a barra, mas se diferencia
deste pelo nmero de fluxos que entram e saem dela. Em um n de ramificao chega um
nico fluxo e saem dois ou mais, enquanto que em um n de juno chegam dois ou mais
fluxos e sai apenas um. Nesse aspecto anlogo ao n de aglutinao, mas, enquanto este
no espera ou sincroniza os diversos fluxos de entrada, o n de juno fica esperando que a
execuo concorrente em todos os seus fluxos de entrada termine, para que o seu fluxo de
sada seja disparado. Assim, por exemplo, na atividade descrita pelo DA da Figura 7.1, a
transio para o n final s ocorrer quando o pedido tiver sido despachado (ao
Despacha produto concluda) e a baixa no estoque dos produtos includos no pedido tiver
sido realizada (ao D baixa no estoque concluda).
O mesmo tipo de combinao de aglutinao e deciso, mostrada na Figura 7.3,
tambm pode ser utilizada para juno e ramificao (Figura 7.4).
(a)
(b)
Figura 7.4: (a) Combinao de juno e ramificao; (b) Significado da combinao
68
Evento temporal
Pode ser necessrio modelar um perodo de espera por exemplo, esperar trs dias teis
pela confirmao do pagamento de um pedido. Ou ento, pode ser necessrio representar o
disparo de um processo em intervalos regulares, como quando se faz o backup dos
arquivos de um computador a cada semana. Para essas situaes, deve-se lanar mo de
eventos de tempo. Eventos de tempo so representados graficamente por uma pequena
ampulheta.
O DA da Figura 7.1 mostra um evento de tempo que expressa uma espera de trs dias
teis pela confirmao do pagamento de um pedido. Aps o transcurso desse tempo, ocorre
automaticamente a transio de sada desse evento.
Quando existe um fluxo de entrada para o evento de tempo, o evento ativado uma
nica vez (time out). Este o caso do evento de tempo que aparece na Figura 7.1. Caso
contrrio, o evento recorrente se repete de acordo com a indicao textual que pode ser
colocada prxima ampulheta (Figura 7.5).
Figura 7.5: Exemplo de evento temporal recorrente
Eventos externos
Eventos externos ou sinais so mensagens trocadas com entidades externas ao DA, tais
como pessoas, outros sistemas, etc. Por exemplo, a aprovao do pagamento de uma
compra com carto de crdito requer uma interao (troca de mensagem) com o sistema de
aprovao de crdito da administradora do carto (Figura 7.6).
Figura 7.6: Envio e recebimento de sinais

O processo descrito pelo DA da Figura 7.6 poderia ser lido assim: Inicialmente
calcula-se o total da compra e, em seguida, enviado um sinal administradora do carto
de crdito solicitando a aprovao do crdito para o pagamento. Segue-se uma espera pela
resposta da administradora, que, quando chega, utilizada para atualizar o status da
compra.
A recepo de um sinal desperta uma ao (no caso do exemplo da Figura 7.6, a
ao despertada Atualiza o status da compra). Normalmente, o receptor sabe reagir ao
sinal e espera sua chegada em algum momento (sem saber exatamente quando). A reao
das entidades externas (nesse caso, a administradora do carto) no modelada no DA.
69
Outro exemplo de utilizao de sinais pode ser visto na Figura 7.1, apresentada
anteriormente. Nessa figura, quando o Cliente paga o boleto referente ao seu pedido,
ocorre o envio de um sinal rede bancria (entidade externa) solicitando a confirmao do
pagamento. Quando essa confirmao recebida pelo Depto. Financeiro, ele pode dar
prosseguimento venda. Se o Cliente no pagar o boleto, no ocorrer o envio de sinal
rede bancria e, consequentemente, o Depto. Financeiro no receber a confirmao do
pagamento. Nesse caso, transcorrido o prazo de espera de trs dias teis (evento temporal),
a venda ser cancelada pelo Depto. Financeiro.
Nos exemplos anteriores de troca de sinais, o n de recepo tem um fluxo de
entrada, significando que a espera pelo recebimento do sinal s se inicia quando a
execuo atinge o n atravs desse fluxo. Quando inexiste tal fluxo de entrada em um n
de recepo de sinal, o n estar sempre esperando pelo sinal, isto , desde o incio da
atividade. Por exemplo, na Figura 7.7, a atividade inicia com a espera pelo sinal de pedido
recebido e, toda vez um pedido for recebido, o pedido ser processado e despachado.
Figura 7.7: Espera desde o incio da atividade
Subatividade
O n de subatividade representa uma parte da atividade que detalhada em outro DA. Para
exemplificar a utilizao do n de subatividade, considere novamente o DA da Figura 7.1.
Podemos simplificar esse DA, substituindo as aes do Setor de Entregas referentes
liberao de um pedido (envio do pedido e baixa no estoque) por uma subatividade
denominada Libera pedido, cujo detalhamento passa a ser feito em outro DA. A Figura
7.8(a) destaca a parte do DA da Figura 7.1 que ser substituda por uma subatividade, e a
Figura 7.8(b) mostra o resultado dessa substituio. A Figura 7.9 apresenta o DA
construdo para descrever a subatividade criada. Observe a presena de um quadro
envolvendo o DA, com o nome da subatividade.
70
(a)
(b)
Figura 7.8: Exemplo de utilizao do n de subatividade Subatividade Libera pedido
Figura 7.9: DA da subatividade Libera pedido
71
N conector
Ns conectores podem ser usados para subdividir um DA, facilitando a sua construo e
melhorando a sua legibilidade. A Figura 7.10 ilustra a utilizao de um conector. Ela
mostra que a Ao 4 ativada assim que a Ao 3 termina.
Figura 7.10: Utilizao de conector em um DA
[DA-Lab2]
Dentre os casos de uso elaborados no UC-Lab4 (Captulo 2), para o
sistema Restaurante, escolha um deles e faa o DA para descrev-lo.
7.3.
Relao com outros modelos / diagramas
O DS e o DCom focam a comunicao entre objetos, para a realizao de um nico UC,

enquanto que o DA foca as aes realizadas em um contexto mais flexvel: sistema,
subsistema, UC (ou conjunto deles), operao, etc.
72
Bibliografia
Bibliografia
BEZERRA, E. Princpios de Anlise e Projeto de Sistemas UML. Campus, 2006.
GUEDES, G. UML 2 Uma abordagem Prtica. Novatec, 2009.
MELO, A. C. Exercitando Modelagem em UML. BRASPORT, 2007.
73

Livro Michel LiComp-UFJF v1.1

Enviado por

Dados do documento

Descrição original:

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

Livro Michel LiComp-UFJF v1.1

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade Federal de Juiz de Fora

Departamento de Cincia da Computao

Universidade Federal de Juiz de Fora

Fortuna, Michel Heluey.

representao das diferentes vises de um sistema e, em particular,

Modelo de Casos de Uso .......................................................................................................... 16

Diagrama de UCs ............................................................................................................... 17

Descrio dos UCs............................................................................................................. 18

Relacionamentos entre UCs............................................................................................... 22

Diagrama de Classes de Objetos .............................................................................................. 29

Classe Objeto ......................................................................................................................... 30

Associaes entre classes ................................................................................................. 31

Associao reflexiva .................................................................................................................. 33

Diagrama de Estados ................................................................................................................ 39

Relao com outros modelos ............................................................................................. 47

Diagrama de Sequncia ............................................................................................................ 49

Linha de vida e barras de ativao............................................................................................ 51

Relao com os outros modelos ........................................................................................ 57

Diagrama de Comunicao ....................................................................................................... 58

Comparao com outros modelos...................................................................................... 59

Comparao: DCom DS.................................................................................................. 60

Traduzindo um DS em um DCom ...................................................................................... 61

Diagrama de Atividade .............................................................................................................. 63

Relao com outros modelos / diagramas ......................................................................... 72

Lista de Figuras e Tabelas

Figura 5.7: Exemplos de fragmentos de sequncia.......................................................................... 56

Observe atentamente a Figura 1.1 abaixo; o que ela lhe diz?

Figura 1.1: Como se constri (e se cobra por) software!?1

O resultado dessas entrevistas seria uma srie de anotaes como as mostradas na

O consumo (quantidade de cada prato ou bebida) em um dia de funcionamento do

Informaes sobre as penduras (nome do cliente, telefone, valor pendurado, data da

Vemos, portanto, que as engenharias levaram ao p da letra um conhecido provrbio: uma

Figura 1.4: Diagramas da UML 2.4

relaes estruturais. So tambm chamados de diagramas estticos, pois eles representam

Modelo de Casos de Uso

Captulo 2: Modelo de Casos de Uso

O que o sistema deve fazer;

Captulo 2: Modelo de Casos de Uso

Figura 2.1: Exemplo de diagrama de casos de uso

Fronteira do sistema (com o seu ambiente): representada pelo retngulo que

[UC-Lab1: Atores e stakeholders]

Captulo 2: Modelo de Casos de Uso

Descrio dos UCs

Aps a identificao dos atores e UCs, e a elaborao do DUC do sistema, deve-se

Captulo 2: Modelo de Casos de Uso

Figura 2.2: Nveis mais comuns de detalhamento na descrio de UCs

Normalmente, apenas um pargrafo.

Captulo 2: Modelo de Casos de Uso

Por sua vez, o sistema gera os seguintes eventos:

A descrio do fluxo de eventos desse UC colocaria cada evento na sua posio

O Caixa identifica o pedido a pagar;

Captulo 2: Modelo de Casos de Uso

[Exemplo: UC Abrir conta (sistema bancrio)]

O Sistema pede o CPF do cliente;

[Fluxo de eventos com situaes alternativas]

O Caixa identifica o pedido a pagar;

Captulo 2: Modelo de Casos de Uso

situaes alternativas que poderiam estar previstas na descrio do fluxo de eventos do UC

Carto no pode ser identificado;

[UC-Lab4: Fluxo de eventos dos UCs]

Relacionamentos entre UCs

Vimos que o diagrama de UCs mostra o relacionamento de comunicao entre os atores e