Apostila de AP

Etec de Hortolndia
Rua Capito Lourival Mey, 750-Jd. Santana.

Fone: (019) 38973727
Fone: (019) 38973727
Introduo Anlise e Projeto

de Sistemas
Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau
Captulo 1
Definio
A UML (Unified Modeling Language, ou, traduzindo, Linguagem de Modelagem
Unificada) uma linguagem que serve para especificar, construir, visualizar e documentar os
artefatos de um sistema.
Viso Histrica
Na primeira dcada de 1990, houve uma proliferao de mtodos e notaes para a
modelagem segundo a abordagem orientada a objetos. Foi quando se percebeu a necessidade
de existncia de uma linguagem que viesse a torna-se norma, sendo aceita e utilizada quer
pela indstria, quer pelos ambientes acadmicos.
Surgiram, dessa forma, alguns esforos no sentido de normalidade, sendo que a UML
apareceu, em 1996, mais bem posicionada como a linguagem unificadora de notaes,
diagramas, e formas de representao.
Resumo histrico
- 1994 Rumbaugh (OMT) se uniu ao Grady Booch inteno de integrar seus
mtodos
- Conferencia OOPSLA95 1 descrio de seu mtodo unificado
- Ivar Jacobson (OOSE) se uniu a eles
- 1996 Trs amigos 1 Verso da UML
- OMG padronizao do mtodo
- Varias propostas de outras organizaes Rational Software - verso 1.0 da UML
- Verso 1.1 da UML adotada como padro
- 1999 verso 1.3 torna-se publica
O que linguagem de Modelagem?

Vocabulrio e regras voltadas para a representao conceitual e fsica de um sistema a
ser desenvolvido.
A UML indica como criar e ler modelos, mas no aponta quais modelos devero ser
criados. Esta tarefa cabe ao processo de desenvolvimento de sistemas
Modelagem: Objetivos
Guia para a construo do sistema modelos documentam as decises tomadas
Linguagem comum entre desenvolvedores
Uso de UML
CASE Aderir ao padro da ferramenta
Uso de diagrama para comunicao
Ferramentas Case
Rational Rose
TogetherSoft
ArgoUML
Poseidon
Jude
Por que fazer Anlise e Projeto?

O produto final do processo de desenvolvimento de sistema o cdigo executvel
Documentao: facilita a comunicao Viso geral do sistema
Orientao a Objetos
Orientao a objetos uma nova maneira de pensar os problemas de linguagens de
informao utilizando modelos organizados a partir do mundo rela. O artefato-base o
objeto, capaz de combinar estrutura e comportamento em uma nica entidade. A
orientao a objetos uma metodologia de programao, assim como a procedimental,
orientada a eventos e outros fenmenos. Tudo o que podemos ver no mundo real
considerado um objeto com atributos e procedimentos.
Objeto (ou instncia)

So elementos que pertencem ao mundo real, ou imaginrio, e que podemos de
alguma forma, identificar, como uma pedra, uma caneta, um copo ou mesmo uma fada. Um
objeto possui, armazenada em si mesmo, determinadas propriedades de um objeto so
chamadas, tambm, de atributos.
O objeto interage com o meio e, em funo das excitaes a que exposto, realiza
determinadas aes que alteram o seu estado (seus atributos). Os atributos de um objeto no
so estticos; eles sofrem alteraes com o tempo.
Para a implementao do paradigma OO, um objeto uma entidade nica capaz de
reunir atributos e mtodos, ou seja, ele rene as propriedades dos objetos e as reaes s
excitaes sofridas.
Classe
Representa um conjunto de objetos com caractersticas semelhantes. Uma classe
define o comportamento dos objetos por meio de mtodos, definindo, os estados que ele
capaz de manter mediante atributos. Por exemplo, a classe Pessoa poderia ter os objetos
(instncias) Carolina, Izilda, Lucas, Ricardo e Paulo.
Atributos (ou Propriedades)

A todo objeto podemos relacionar alguns atributos (propriedades). Por exemplo, em
um relgio, a hora e a data so os principais atributos. Na programao orientada a objetos, os
atributos so definidos na classe e armazenados de forma individual ou coletiva.
Atributos de classe (coletivos) so os divididos entre todos os objetos criados, sendo
armazenados na classe. Um bom exemplo seria um contador para relgios criados. Por outro
lado, os atributos de objeto (individuais) funcionam quando um atributo individual,
armazenado no objeto. Um bom exemplo p horrio marcado em um relgio. Cada relgio
tem uma hora, que pode ou no estar certa.
Mtodos (ou Aes)

A todo objeto, podemos relacionar determinados comportamentos, aes e reaes.
As aes ou os comportamentos dos objetos so chamados de mtodos, assim, um mtodo
uma funo um servio fornecido pelo objeto.
Os comportamentos dos objetos so definidos por meio dos mtodos e servem para
manipular e alterar os atributos de um objeto (alteram seu estado).
Como alguns exemplos, podemos citar os objetos e suas aes:
Um automvel tem o comportamento de se locomover;
Um computador, o de processar programas;
Uma edificao, o de dar abrigo.
Captulo 2
Diagrama de Caso de Uso
Um caso de uso descreve uma seqncia de aes que representam um cenrio
principal (perfeito) e cenrios alternativos, com o objetivo de demonstrar o comportamento
de um sistema (ou parte dele), atravs de interaes com atores.
Uma vez que o desenvolvedor levante os requisitos com o usurio, h a necessidade
de document-los, no s para entendimento e validao de ambas as partes, como para
servir de base. A documentao dos requisitos evita que informaes importantes no se
percam, sendo descobertas apenas ao apresentar o produto final ao usurio.
Utilizando a modelagem de casos de uso, o primeiro passo do desenvolvedor separar
as funcionalidades do sistema. Destas funcionalidades, devemos agrupar um conjunto de
aes que tenham um objetivo bem definido.
Suponhamos, num sistema de vendas de uma loja de roupa, que sejam tarefas
distintas e bem definidas: consultar informaes sobre o produto, efetuar reserva, emitir
comprovante de reserva, efetuar venda, emitir nota fiscal, realizar fechamento dirio do caixa,
etc. Cada uma destas tarefas possui um conjunto de aes que precisam ser executadas para
que o objetivo da tarefa seja alcanado. No caso de efetuar venda, preciso informar a
identificao da vendedora, a identificao do produto, quantidade vendida, etc. Ao
pensarmos nessas aes realizadas numa rotina sem problemas, estamos lidando com um
cenrio perfeito, que ser o nosso cenrio principal.
O cenrio principal descreve uma seqncia de aes que sero executadas
considerando que nada de errado ocorrer durante a execuo da seqncia.
Exemplo: Emitir saldo em um terminal caixa eletrnico
Cenrio Principal
1.
O sistema realiza a leitura do carto magntico do correntista.
2.
O sistema solicita a digitao da senha. O correntista digita a senha.
3.
O sistema valida a senha.
4.
O correntista seleciona a opo de saldo
5.
O sistema questiona o tipo de saldo: conta corrente, poupana e aplicaes.
6.
O sistema processa e mostra o saldo solicitado pelo cliente
No exemplo, temos um cenrio perfeito, no qual nada ocorre de errado. Todavia, o
mundo no perfeito, muito menos as transaes de um sistema. As excees so
representadas com cenrios alternativos. Por exemplo: considerando o cenrio principal da
emisso de saldo em um Caixa Eletrnico, poderamos modelar os cenrios alternativos.
Alternativa: Problemas na leitura do carto magntico
1a) Se o sistema no conseguir ler os dados do carto magntico, tentar nova leitura
por, no mximo, mais duas vezes.
Alternativa: Senha invalida
3a) Se a senha digitada pelo correntista no for igual a senha cadastrada no sistema,
informar ao mesmo e solicitar nova digitao. Esse processo pode ser repetido por no mximo
trs tentativas (incluindo a primeira). Aps a terceira tentativa, a conta dever ser bloqueada e
o caso de uso encerrado. Include Bloquear Conta.
Alternativa: Conta inexistente

6a) Se o correntista no possuir o tipo de conta selecionada, informar ao mesmo.
No exemplo as alternativas so apresentadas como subitens do cenrio principal (1
1a; 3 3a; 6 6a). Esse procedimento facilita a associao da alternativa com o fluxo principal.
O caso de uso, por expressar os requisitos do sistema nada mais do que a essncia
deste -, utilizado durante todo o processo de desenvolvimento. Os requisitos alm de serem
base para a criao dos modelos de anlise, projeto e implementao, tambm so usados
como base para a criao de testes do sistema.
Ao modelarmos um sistema, necessitamos saber at que ponto devemos nos
preocupar. Estes pontos-limites so a fronteira do sistema. Por exemplo: um sistema de
controle de vendas emitir em alguns momentos o faturamento semanal ou mensal de cada
vendedor para o Departamento Pessoal. Todavia, no responsabilidade do sistema o que o
Departamento Pessoal far com essa informao.
Os sistemas recebem e enviam informaes para o mundo externo atravs de suas
fronteiras. Logicamente que essas informaes no podem cair num buraco negro, na sada,
nem surgem por mgica, na entrada. Algum ou algo deve ser responsvel por enviar e/ou
receber informaes do sistema.
Na modelagem de casos de uso, esse papel externo exercido por um ator. Na
realidade, esse ator, que pode ser tanto uma pessoa, como um grupo ou ainda um sistema,
representa um conjunto de papeis. Um caso de uso pode ser relacionar com mais de um ator.
Um ator representa um conjunto de papeis exercido por um usurio do sistema ao
interagir com um determinado caso de uso.
Exemplo: Num determinado sistema acadmico, a rotina de atualizar a freqncia dos
alunos pode ser executada por quem? Pelos funcionrios da Secretaria, pelo prprio Professor
ou pelo Sistema de Avaliao on-line. Esses papeis so representados por Atores.
Essa comunicao sistema-ator (e vice-versa) consiste da interao entre sistema e
atores.
responsabilidade do caso de uso demonstrar com quais atores o sistema interage.
Essa identificao na fase de analise fornece ao projetista, no futuro, base para a criao dos
perfis de acesso ao sistema.
Conceitos
1 - Ator: representa um papel que o usurio vai desempenhar em relao ao sistema.
Representao:
Exemplos:
2 Caso de Uso: uma descrio da maneira do usurio usar o sistema.

Representao:
Exemplos:
Obs.: O nome do caso de usado pode ser colocado dentro ou abaixo dele.
Dicas:
Dar como nome aos casos de uso, frases verbais curtas no infinitivo (emprestar
material) ou gerndio (emprestando material). Pode ser utilizada qualquer uma dessas formas
de nomenclatura, porm, deve-se prezar pela padronizao, ou seja, se for escolhido uma das
formas, deve-se utilizar em toda a modelagem.
3 Associao de Extenso: um tipo de associao que pode ser utilizado em
diagramas de caso de uso. Neste relacionamento, a descrio de caso de uso pode ser
estendida para outros casos de uso, atravs de associao de extenso.
Representao:
Exemplos:
Relacionamento entre casos de uso e atores

Os casos de uso representam conjuntos bem definidos de funcionalidade do sistema,
que no podem trabalhar sozinhas no contexto do sistema. Portanto, esses casos de uso
precisam se relacionar com outros casos de uso e com atores que enviaro e recebero
mensagens destes.
Para um relacionamento de casos de uso, entre si, temos os tipos: generalizao,
extenso e incluso.
Para relacionamento de atores, entre si, temos um nico tipo, que o relacionamento
de generalizao.
Para relacionamentos entre atores e casos de uso, temos apenas a associao.
Associao
Representa a interao do ator com o caso de uso, ou seja, a comunicao entre
atores e casos de uso, por meio do envio e recebimento de mensagens.
Generalizao
Ocorre entre casos de uso e atores.
considerado quando temos dois elementos semelhantes, mas como um deles
realizando algo a mais.
Extenso (Extend)
Um relacionamento de extenso entre casos de uso indica que um deles ter seu
procedimento acrescido, em um ponto de extenso, de outro caso de uso, identificado como
base.
Os pontos de extenso so rtulos que aparecem nos cenrios do caso de uso base.
permitido colocar diversos pontos de extenso num mesmo caso de uso, inclusive repetir um
mesmo ponto de extenso.
Utilizada para expressar rotinas de exceo e pra descrever cenrios opcionais de um
Caso de Uso. Os Casos estendidos descrevem cenrios que somente ocorrero em uma
situao especfica, se uma determinada condio for satisfeita.
Incluso (Include)
Indica que um deles ter seu procedimento copiado num local especificado no outro
caso de uso. Esse tipo de relacionamento utilizado quando existirem cenrios cujas aes
servem a mais de um caso de uso.
Mais do que evitar a cpia de trechos idnticos, ganhamos tempo de modelagem e
tambm de implementao ao trabalhar com casos de uso de incluso.
Utilizada para expresso rotinas de fluxo alternativo.
Exerccio: Desenvolver um caso de uso para um sistema de vdeo-locadora.
Captulo 3
Diagrama de classe
Aps extrairmos dos requisitos os objetos da aplicao, precisaremos separar e
classificar suas caractersticas, modelando, por conseguinte, as classes do sistema. Entretanto
a essncia de um sistema no est apenas em suas classes, mas principalmente em seus
relacionamentos.
As classes so declaradas no diagrama de classes, mas so usadas em muitos outros
diagramas. Uma classe representada como um retngulo subdividido em trs
compartimentos, separados por linhas horizontais que nesta ordem armazenam:
O nome da classe e outras propriedades gerais da mesma, incluindo
esteretipos;
Lista de atributos;
Lista de operaes
Classes podem se relacionar com outras atravs de diversas maneiras: associao
(conectadas entre si), dependncia (uma classe depende ou usa outra classe), especializao
(uma classe uma especializao de outra classe), ou em pacotes (classes agrupadas por
caractersticas similares).
Todos estes relacionamentos so mostrados no diagrama de classes juntamente com
as suas estruturas internas, que so os atributos e operaes. O diagrama de classes
considerado esttico j que a estrutura descrita sempre vlida em qualquer ponto do ciclo de
vida do sistema. Um sistema normalmente possui alguns diagramas de classes, j que no so
todas as classes que esto inseridas em um nico diagrama e uma certa classe pode participar
de vrios diagramas de classes.
Visibilidade
A visibilidade identifica por quem uma propriedade (atributo ou operao) pode ser
utilizada.
O conceito semelhante definio de variveis (pblica, local, privada, etc.), mas

agora ns lidamos com escopo dentro de classes, objetos, pacotes, etc.
+ ou public
# ou protected
- ou private
~ ou package
A propriedade ser vista e usada dentro da classe na qual foi

declarada, em qualquer elemento externo e nas classes
descendentes.
A propriedade ser vista e usada apenas dentro da classe na
qual foi declarada e pelas classes descendentes.
A propriedade ser vista e usada apenas dentro da classe na
qual foi declarada.
A propriedade poder ser vista e usada por elementos que
estejam declarados dentro do mesmo pacote no qual est
inserida a classe que a declarou. como a pblica, s que no
generalizada a qualquer elemento externo, mas apenas aos
elementos externos localizados no mesmo pacote.
Atributos e Operaes
Depois de identificar os objetos (ou conceitos) interessantes, temos que definir as
propriedades deles que queremos representar. Estas propriedades podem ser dados
(atributos) ou operaes.
Um atributo representa uma propriedade que todos os objetos da classe tm (por
exemplo, todas as mesas tm uma altura, numero de pernas, posio da mesa na sala, etc.).
Mas cada objeto ter valores particulares para seus atributos (algumas mesas so baixas,
outras so altas, etc.). O valor de um atributo pode mudar com o tempo (posio da mesa na
sala), a lista de atributos geralmente no muda.
Dentro de uma classe todos os atributos devem ter nomes diferentes. Classes
diferentes podem possuir atributos com o mesmo nome (em duas classes diferentes) devem
identificar a mesma coisa. Por exemplo, um professor e uma sala ambos podem ter um
atributo numero porque ele significa a mesma coisa nas duas classes, mas a nota que um
aluno consegue numa disciplina e um atributo para gravas anotaes sobre uma sala (ex.: luz
no funciona nesta sala), no podem ambos ser chamados de nota porque as duas coisas so
diferentes.
O nome de um atributo um texto contendo letras, dgitos e algumas marcas de
pontuao. A UML sugere capitalizar todas as primeiras letras das palavras, exceto a primeira
palavra (ex.: nome; codigoPessoaFisica).
Conceitos
1 Classe
uma abstrao de informaes da realidade.
Exemplo:
2 Associao Simples
um relacionamento ou conexo entre duas classes
Exemplo:
3 Papel
o papel do relacionamento
Exemplo:
4 Multiplicidade
Exatamente uma 1
Vrios (zero ou mais) 0..*
Opcional (zero ou uma) 0..1
Especificada Numericamente n..m
5 Direcionamento de Leitura
Direita para esquerda
Esquerda para direita
Exemplo:
6 Agregao
um relacionamento de todo-parte, onde o todo no precisa das partes para existir.
Exemplo:
7 Composio
um relacionamento de todo-parte, onde o todo precisa das partes para existir.
Exemplo:
Obs.: A composio e a agregao pode ser demonstrado juntos.

8 Generalizao/Especializao
um relacionamento onde as classes especficas herdam as caractersticas e aes da
classe geral.
Exemplo:
9 Restries
Representa restries relacionadas s classes.
Exemplo:
10 Nota
Trata-se de colocao de textos, informaes e descries importantes com relao s
classes.
Exemplo:
11 Classe de associao
Trata-se de uma associao modelada com uma classe.
A classe de associao s existe se existir o relacionamento entre duas classes que
geram informaes que no podem ser armazenadas nas mesmas.
Exemplo:
Exemplo geral: Diagrama de uma rede hospitais.
Captulo 4
Diagrama de Objetos
Um diagrama de objetos consiste numa instancia do diagrama de classes, no qual para
cada classe temos um objeto (sua instancia) em um determinado ponto do tempo e so muito
teis para facilitar a modelagem de estruturas complexas de dados.
O diagrama de objetos pode tambm auxiliar o desenvolvedor no momento de
identificar problemas na execuo de uma aplicao. Durante o debugging, pode-se parar a
execuo e paralelamente mapear, num diagrama de objetos, os objetos que esto sendo
manipulados, expandindo seus relacionamentos e alguns objetos vizinhos.
A representao grfica de um objeto similar de uma classe. Consiste num
retngulo com di compartimentos. O primeiro mostra o nome do objeto e o segundo mostra
os atributos, um em cada linha, com seus valores.
O nome do objeto deve ser sublinhado, na seguinte notao:
nome do objeto: nome da classe
Por exemplo:
coordenadaFigura1: Coordenada
possvel ainda omitir o nome do objeto (preservando os dois pontos), representando
um objeto annimo ou omitir o nome da classe (juntamente com os dois pontos). Em qualquer
um desses casos, mantm-se o sublinhado.
Por exemplo:
: Coordenada
coordenadaFigura1:
Exemplo com os atributos:
Atributos cujos valores no sejam relevantes para a modelagem pode ser omitidos.
Captulo 5
Diagramas de Interao
Interao corresponde a um conjunto de mensagens trocadas entre objetos, com o
objetivo de alcanar determinado propsito, respeitando-se o contexto do sistema.
Um diagrama de interao mostra as interaes por meio de uma viso dinmica do
sistema. Por representar um sistema, subsistema, operao, classe ou cenrio de caso de uso,
sendo essa ultima representao a mais freqente. Um diagrama de interao formado
basicamente, por objetos, relacionamentos e mensagens. Os diagramas de interao se
apresentam em duas formas:
Diagrama de seqncia
Diagrama de colaborao
Esses diagramas possuem cada qual alguns aspectos que os diferenciam. O diagrama
de seqncia enfatiza a seqncia de mensagens dentro de uma linha de tempo, enquanto
que o de colaborao enfatiza o relacionamento estrutural entre os objetos, sem se preocupar
com o tempo determinado para cada interao.
Diagrama de seqncias
Para melhor ilustrar a interao de um Diagrama de Seqncias, vamos imaginar um
processo X qualquer de uma empresa, na qual trabalham os funcionrios Antnio, Joo e
Carlos. Num dado instante, o Gerente da empresa solicita ao Antnio que prepare um relatrio
de comisses para um determinado ms. Entretanto, para que o Antnio consiga preparar
esse relatrio, ele precisa do total de cada vendedor, obtido no ms em foco, e essa
informao quem tem o Joo. Ento, Antnio passa um e-mail para o Joo pedindo essa
informao.
Joo quando recebe essa mensagem (eletrnica) inicia os procedimentos necessrios
para relacionar as vendas de cada vendedor. Todavia, ele s possui em mos a matrcula de
cada vendedor e seu total vendido. Mas ele pode conseguir o nome de cada vendedor com o
Carlos. Assim, Joo passa um e-mail para o Carlos, enviando no corpo da mensagem a lista de
matrculas que ele possui, solicitando que seu colega diga a quem pertence.
Carlos, ao receber a mensagem, procura em suas fichas os nomes dos vendedores. De
posse desses nomes, ele responde ao e-mail de Joo, acrescentando os nomes dos
vendedores. Joo, ao receber a resposta de Carlos, responde a mensagem original de Antnio,
acrescentando no corpo da mensagem a lista de vendedores (com matrcula e nome)
acompanhada dos totais de vendas de cada um.
Antnio, feliz da vida pois a equipe bem entrosada, abre a mensagem de resposta,
pega as informaes recebidas e coloca em seu relatrio. Nada como uma empresa que
funciona! Guardadas as devidas propores, se trocarmos os funcionrios Antnio, Joo e
Carlos pelas responsabilidades que eles possuem, temos a encenao da troca de mensagens
entre objetos em um diagrama de seqncias.
Antnio um captador e transmissor de informaes; ser nossa tela de Relatrio.
Joo responsvel por controlar as vendas do ms; ser nosso objeto Vendas. Carlos
responsvel por controlar o cadastro dos vendedores; ser nosso objeto vendedor.
A representao grfica de um diagrama de seqncias baseada em duas dimenses.
A primeira dimenso vertical e representa as mensagens trocadas no decorrer de um tempo
de vida (eixo Y). A segunda dimenso horizontal e representa os objetos participantes das
interaes (eixo X). As mensagens correspondem a chamadas de servios dos objetos, ou seja,
a chamadas de suas operaes.
Assim, estabelecemos uma interao que corresponde representao de um

elemento do modelo (por exemplo: Diagrama de Seqncias para o caso de uso Cadastro de
Funcionrio) e para tal relacionamos os objetos envolvidos e desenhamos cada chamada de
operao como o disparo de uma mensagem, partindo do objeto chamador para o objeto
executor da operao.
A representao dos objetos em um diagrama de seqncias feita com um retngulo

alinhado no topo do diagrama, partindo dele uma linha vertical tracejada denominada linha de
vida, que desenhada at o fim do diagrama. A linha de vida representar a vida deste objeto
dentro de um determinado perodo de tempo.
Um objeto, que j existe quando a transao do diagrama tem incio, mostrado

alinhado ao topo do diagrama, de forma a ficar acima da primeira seta de mensagem. Por
outro lado, um objeto que continuar a existir, mesmo aps a finalizao da transao do
diagrama, tem sua linha de vida estendida para alm da ltima seta de mensagem.
A criao ou destruio de um objeto dentro do perodo de tempo total representado
pelo diagrama so mostradas desenhando-se o incio ou fim da linha de vida do objeto no
ponto determinado pela criao ou destruio. No caso da criao, a seta que representa essa
mensagem desenhada de forma a apontar sua cabea para o smbolo do objeto. No caso da
destruio, a seta que carrega essa mensagem direcionada a um grande "X" colocado no fim
da linha de vida. As mensagens de criao e destruio podem ser estereotipadas com
<<create>> e <<destroy>>, respectivamente.
As mensagens so enviadas de um objeto a outro, por meio de setas que partem de

uma linha de vida para outra. Essas setas so identificadas com o nome da operao que est
sendo chamada. As mensagens podem carregar a solicitao de um processamento, a
comunicao de um evento ou outras informaes relevantes para o cumprimento de
responsabilidades. A seqncia de mensagens pode ser numerada, mas seu uso
desnecessrio nesse tipo de diagrama. Na figura acima voc pode ver as mensagens
numeradas sendo que os nmeros ajudam no entendimento da ordem das mensagens.
Ao alcanar o outro lado, a seta d incio ativao, que corresponde ao perodo de
tempo durante o qual um determinado procedimento de um objeto est sendo executado.
Essa ativao mostrada graficamente como um retngulo fino e comprido, que tem sua parte
superior alinhada ao final da seta ativadora e se estende at o fim do processamento, que
pode ter uma representao extra com uma mensagem de retorno. A mensagem de retorno
no obrigatria. Os retornos so dados por uma linha pontilhada com uma seta partindo do
receptor da mensagem para quem a chamou.
A seta de mensagem, alm do nome da operao, tambm pode conter uma condio
e/ou uma expresso de iterao (seqncia repetida de mensagens). Textos de identificao
como restries de tempo, descries de aes durante uma ativao, entre outros, tambm
podem ser mostrados na margem esquerda do diagrama ou perto dos elementos que eles
identificam.
Condies so colocadas dentro de colchetes e determinam que a mensagem s ser
disparada se a condio for verdadeira. Por exemplo:
[instrutorOk] agendarCurso()
A iterao representa o envio da mesma mensagem diversas vezes para o mesmo
objeto, sendo comum no tratamento de colees de objetos. Vamos supor que tenho que
chamar a operao calculaMedia() dos alunos da turma. Marcando a iterao para a
mensagem calculaMedia(), indicamos que ela deve ser chamada vrias vezes. A representao
da iterao feita dentro de colchetes, incluindo antes do colchete inicial o smbolo (*) A
notao de condio e iterao a mesma para o diagrama de iterao. O texto dentro dos
colchetes indica a condio que determinar quantas vezes a mensagem ser passada. Por
exemplo:
*[para cada aluno da turma] calcularMedia()
*[para cada instrutor] instrutorOk := disponivel(data)
No caso de chamada recursiva (um objeto passa mensagem para si prprio), o segundo
smbolo de ativao desenhado levemente direita do primeiro, dando a impresso de que
esto empilhados. Essa chamada recursiva denominada auto-chamada.
Num fluxo de controle procedural, a mensagem de retorno pode ser omitida, pois fica
implcito que, ao final da ativao, o retomo ocorrer, ou seja, assume-se que toda mensagem
de chamada faz par com uma mensagem de retorno. Para fluxos de controle no-procedurais
(como mensagens de processamento paralelo), mensagens de retorno devem ser mostradas
explicitamente.
Na arrumao dos objetos, deve-se colocar como o primeiro objeto exatamente
aquele que d incio interao.
No diagrama de seqncias tambm representamos uma ramificao para condies
ou concorrncias, que mostrada por mltiplas setas partindo de um ponto simples, sendo
cada ramo identificado por uma condio. Dependendo de como as condies so
mutuamente exclusivas, essa construo pode representar condicionalidade ou concorrncia.
Veja a figura abaixo:
Diagrama de colaborao
Os objetos so distribudos no diagrama de colaborao na ordem similar do
diagrama de seqncias, obedecendo seqncia de mensagens. A colaborao entre objetos
representada por uma ligao simples acompanhada de uma numerao seqencial e de
outras informaes como condies e iteraes.
Em virtude da forma como um diagrama de colaborao apresentado, identificamos
a seqncia temporal das mensagens por meio de seqncias numricas. A autochamada do
diagrama de seqncias identificado como autodelegao no diagrama de colaborao e
representado como um arco ligado ao objeto.
Na figura abaixo, a primeira mensagem a chamada do mtodo obterGrade() para o
objeto cursoX. O cdigo deste mtodo para ser concludo necessita de informaes das
disciplinas do referido curso e das turmas ativas. Ento, para cada disciplina chamado o
mtodo obterInfDisciplina() do objeto disc1. O objeto disc1, por sua vez, necessita de
informaes dos pr-requisitos das disciplinas. Ento, passa uma mensagem para si mesmo,
chamando o mtodo obterPreRequisito(). O objeto cursoX, depois que recebe a resposta de
sua mensagem n 2, chama o mtodo obterTurmasAtivas() que pertence ao objeto turma 1.
Repare que uma grande diferena entre o Diagrama de Colaborao e o de Seqncias
exatamente o que ocorre com o objeto cursoX. No fica explcito no diagrama as mensagens
de retorno e o momento em que isso ocorre.
Captulo 6
Diagrama de Estados
O diagrama de grfico de estados descreve o comportamento de objetos como reao
a eventos discretos (como por exemplo sinais e invocao de operaes), por meio de
seqncias de estados e aes que ocorrem durante a sua vida.
Um diagrama de grfico de estados tem por objetivo mostrar uma mquina de estado.
Uma mquina de estado consiste num comportamento que especifica a seqncia de estados
que um objeto atravessa durante sua vida, em resposta a eventos, junto com suas
responsabilidades e aes.
Estado
Um estado uma condio ou situao existente na vida de um objeto durante a qual
o estado satisfaz alguma condio, executa alguma atividade ou espera por algum evento.
Um estado representado graficamente como um retngulo com cantos arredondados. O nome do estado colocado no centro do mesmo, caso ele no esteja
subdividido em compartimentos. Veja na figura abaixo a representao de um estado:
Um estado pode ser opcionalmente subdividido em compartimentos separados cada

qual por uma linha horizontal. So eles:
Compartimento de nome: armazena o nome do estado, como uma string. possvel
desenharmos estados sem nomes. Estes so estados annimos, distintos em si.
Compartimento de transies internas: este compartimento armazena uma lista de
aes ou atividades internas que so executadas enquanto o objeto se apresenta no estado
em foco.
Essas transies internas so representadas por expresses que identificam as circunstncias sobre as quais a ao associada ser invocada. A ao associada ao tipo de
transio externa pode fazer uso de quaisquer atributos e links, que esto no escopo do objeto
proprietrio. Uma transio interna no modifica o estado do objeto.
Por exemplo: quando um objeto OperacaoBancaria entra no estado de "Liberando
dinheiro de saque", ele pode chamar uma ao que bloqueie na conta do correntista o valor
designado para saque. Na sada desse estado, ele pode chamar a ao de debitar o valor da
conta. Durante o estado, estar sendo executada a operao de contagemCedulas().
Existem algumas palavras reservadas que representam as transies internas. Veja
quais so e seus significados:
entry: identifica uma ao que executada na entrada do estado.
exit: identifica uma ao que executada na sada do estado.
do: identifica uma atividade em andamento, ou seja, que executada continuamente
durante o tempo em que o objeto permanece nesse estado.
include: usado para identificar a invocao de uma submquina, cujo nome est ligado
expresso.
As expresses citadas identificam, cada qual, o evento que dispara a expresso

correspondente associada.
O formato geral para qualquer item da lista :
nome-do-evento (lista de parmetros separada por vrgula ) [ condio-de-guarda ] /
expresso-ao
Cada nome de evento pode aparecer mais de uma vez por estado se as condies de
guarda forem diferentes. Os parmetros do evento e as condies de guarda so opcionais.
Vou utilizar em seguida um exemplo do nosso mundo real para que vocs possam
abstrair mais facilmente o conceito de estados.
Vamos pensar na vida de uma pessoa do nascimento at a terceira idade. Veja, de
forma sucinta, como seria parte do nosso diagrama de estados.
Para assumirmos o primeiro estado de nossa existncia, precisamos do evento nascer.
J nascemos como beb e a primeira ao que temos reconhecer nossa me, pelo toque, voz
e/ou cheiro. Durante esse perodo inicial, o beb, alm de dormir e mamar, tambm
desenvolve suas habilidades - principalmente motoras: aprende a sentar, engatinhar, falar e
andar. S que ao final dessa fase, quando ele j tem uma personalidade bem formada, j
podemos considerar nosso beb como uma pequenina criana. Nesse perodo no "estado de
criana", recebemos muitos estmulos e executamos muitas aes. Mas pelo foco que quero
dar nesse primeiro exemplo, coloquei como atividade principal: brincar. At que chega a dita
puberdade, que transforma nossas crianas em adolescentes. Na sada do estado de criana,
algumas atitudes so tomadas: se criana do sexo feminino, abandonar as bonecas; se do sexo
masculino, abandonar os carrinhos (ou as bolinhas de gude).
J ao entrar na fase de adolescncia, a primeira ao de nossa "ps-criana" estabelecer seu territrio: o quarto deles, as coisas deles, os direitos deles, etc. No estado de
adolescente h vrias coisas que podem ser feitas, mas decidi colocar a operao namorar. Em
determinado momento da vida (que no sei precisar qual e no sei se algum consegue
determinar), o adolescente passa para o estado adulto. Ou, ento, por uma precipitao da
sua ao principal (namorar), casa-se sem se tornar adulto.
Durante sua permanncia no estado adulto, essa pessoa exerce a ao Trabalhar .

Finalizarei o exemplo com uma separao do estado Adulto (como solteiro) para um estado de
Casado.
Estado Inicial e Estado Final

Um estado inicial um tipo de estado que indica o local de incio na mquina de estados ou em um subestado. representado graficamente como um crculo preenchido.
Um estado final um tipo de estado que indica que a mquina de estados ou um

estado composto concluiu sua execuo. representado graficamente como ura crculo
envolvendo um pequeno crculo preenchido.
Transies
Uma transio um relacionamento entre dois estados indicando que houve uma
mudana de estado e determinadas aes sero executadas, quando um evento especfico
ocorrer, garantindo que condies foram satisfeitas. A transio disparada quando ocorre a
mudana de estado.
representada graficamente como uma linha slida na qual o estado de partida
identificado como estado de origem e o estado-alvo o estado de destino. A linha da transio
finaliza com uma seta. Pode ser identificada por uma string que possui o seguinte formato:
assinatura-do-evento [ condio-de-guarda ] / expresso-ao
A assinatura-do-evento descreve um evento com seus argumentos, no seguinte
formato:
nome-do-evento (lista de parmetros separada por vrgula )
Exemplo: ChecarEstoque(produto)
A condio de guarda uma expresso booleana que determina, quando verdadeira, o

incio da transio. Pode ser escrita com parmetros do evento disparador ou ainda atributos e
links do objeto proprietrio da mquina de estados. S avaliada depois que o evento de
ativao ocorre. possvel termos vrias transies a partir do mesmo estado de origem,
identificadas com o mesmo evento, diferenciando apenas na sua condio de guarda.
Exemplo: [estoqueAtual <= estoqueMinimo]
A expresso-ao somente executada no incio da transio, se esta ocorrer. Pode
ser escrita com operaes, atributos e links do objeto proprietrio da mquina de estados,
parmetros do evento disparador ou qualquer outro elemento visvel no mesmo escopo.
Exemplo: DataPagamento:= DataPagamento + 3
Veja por exemplo a figura abaixo. O objeto est no estado Aguardando Nota, at que o
evento Nota lanada ocorra. Nesse momento, temos duas possibilidades para o mesmo
evento. A primeira representada na transio para o estado Atualizando Mdia, que s ser
iniciada se a sua condio de guarda for satisfeita, ou seja, que nota >= 0. Outra possibilidade
ocorre na transio para o estado Habilitando Segunda Chamada, que s ter incio se a
condio de guarda nota = "FT" for verdadeira, ou seja, se no tiver havido nota pois o aluno
faltou.
Um evento a especificao de um tipo de ocorrncia observvel. Para propsitos

prticos em diagramas de estado, ele uma ocorrncia que pode disparar uma transio de
estado. Eventos podem ser processados um de cada vez. Se um evento no disparar uma
transio, esta descartada. Eventos podem ser de vrios tipos (no necessariamente
mutuamente exclusivos):
Quando uma condio (descrita por uma expresso booleana) tem seu valor
modificado de falso para verdadeiro;
Quando h recepo de um sinal explcito de um objeto para outro;
Quando h recepo da chamada de uma operao implementada como uma
transio por um objeto;
Quando a passagem de um perodo de tempo especfico depois da ocorrncia de outro
evento representa um evento de tempo. Pode ser representado pela palavra chave after
seguida pela expresso a ser avaliada (ex: after 10 minutos). Outra palavra-chave que pode ser
usada when (ex: when (dataAdmissao >= 01/01/1987)).
Estado composto
Um estado composto um estado que possui uma decomposio grfica em dois ou
mais subestados concorrentes (sobrepostos) ou sequenciais (disjuntos).Cada regio de um
estado pode possuir estados inicial e final.
Uma transio para um estado composto representa uma transio para o estado
inicial do referido estado composto. Uma transio para um estado final representa a
concluso da atividade na regio do estado composto. Vamos supor um sistema de avaliao
no qual o aluno responda as questes de sua prova on-line. Vamos pensar para esse sistema
em um objeto Prova (veja figura abaixo). Durante a vida deste objeto, no momento que o
aluno responde s questes, o objeto estar passando do estado Aguardando Escolha de
Questo para Aguardando Resposta de Questo e assim por diante. Todavia, em paralelo com
essas respostas, temos o estado Checando Trmino da Prova, que ocorre quando o tempo
decorrido de prova se iguala ao valor do atributo tempoProva. Neste caso, estamos diante de
subestados concorrentes, nos quais os estados ocorrem simultaneamente.
Quando Utilizar Diagramas de Estados?

Diagramas de estados so bons para descrever o comportamento de um objeto,
atravs de vrios casos de uso. Esses diagramas no so muito bons para descrever um
comportamento que envolve vrios objetos em colaborao. Para tal, til combinar
diagramas de estados com outras tcnicas.
Por exemplo, diagramas de interao (vistos mais adiante neste curso) so bons para
descrever o comportamento de vrios objetos em um nico caso de uso, e diagramas de
atividades (visto anteriormente) so bons para mostrar a seqncia geral de aes para vrios
objetos e casos de uso.
Nem todo mundo considera que os diagramas de estados sejam naturais. Fique atento
ao modo que as pessoas trabalham com eles. Pode ser que sua equipe no considere
diagramas de estados teis para seu tipo de trabalho. Isso no um grande problema; como
sempre, voc deve lembrar-se de usar uma combinao das tcnicas que funcionam para voc.
Se voc utilizar diagramas de estados, no tente projet-los para cada classe no

sistema. Embora este mtodo seja freqentemente usado por perfeccionistas de muita
formalidade, ele quase sempre um desperdcio de trabalho. Use diagramas de estados
somente para aquelas classes que exibem comportamento interessante, para as quais a
construo do diagrama de estados ajude a compreender o que est acontecendo. Muitas
pessoas acreditam que Interface de Usurios e objetos de controle tm o tipo de
comportamento que til descrever com diagramas de estados.
Captulo 7
Diagrama de Atividade
Um diagrama de atividades um caso especial do diagrama de estados no qual todos
(ou pelo menos a maioria) os estados so aes ou subatividades e no qual todas (ou pelo
menos a maioria) as transies so disparadas pela concluso de aes ou subatividades nos
estados de origem. Este diagrama tem por propsito focalizar um fluxo de atividades que
ocorrem internamente em um processamento, dentro de um perodo de tempo.
Atividade
Na figura abaixo se pode ver o smbolo de uma atividade, este smbolo o estado de
atividade, ou simplesmente atividade. Uma atividade um estado de estar fazendo algo:
tanto um processo de mundo real, tal como datilografar uma carta, ou a execuo de uma
rotina de software, tal como um mtodo em uma classe.
O diagrama de atividades descreve a seqncia de atividades, com suporte para

comportamento condicional e paralelo. Um diagrama de atividades uma variante de um
diagrama de estados no qual a maioria, se no todos, dos estados estado de atividade.
Portanto, muito da terminologia segue a mesma terminologia de diagrama de estados.
Incio do diagrama
O incio do diagrama de atividades marcado com um sinal de um crculo preenchido.
Este smbolo o mesmo para o diagrama de estados. Veja abaixo o smbolo grfico:
Fim do diagrama
Assim como para indicar o incio do diagrama de atividades h um smbolo para indicar
o fim deste diagrama e este smbolo utilizado tanto para o diagrama de atividades como para
o diagrama de estados. A representao um crculo preenchido com um circulo contornando
o mesmo. Veja abaixo o smbolo grfico:
Transies
Para ligar as atividades e indicar a seqncia utilizamos fechas que representam as
transies entre as atividades bem como a transio entre o incio e a primeira atividade, bem
como das atividades para o fim do diagrama. Veja abaixo a representao grfica juntamente
com outros itens do diagrama.
Desvios
Comportamento condicional delineado por desvios (branches) e intercalaes
(merges).
Um desvio (branch) uma transio de entrada nica e vrias transies de sada
guardadas. Somente uma transio de sada pode ser tomada, de modo que os guardas devem
ser mutuamente exclusivos. A utilizao de [else] como um guarda indica que a transio
"else" dever ser usada se todos os outros guardas do desvio forem falsos. Veja na figura
abaixo a representao grfica de um desvio (branch):
Uma intercalao (merge) tem mltiplas transies de entrada e uma nica sada. Um
merge marca o final de um comportamento condicional iniciado por um branch. Veja abaixo a
representao grfica:
Voc no precisa mostrar explicitamente o losango para desvios e intercalaes. Um

estado de atividade, como qualquer estado, pode ter mltiplas transies de sada guardadas e
mltiplas transies de entrada. Use o losango se voc quiser deixar claros os desvios e as
intercalaes em um diagrama.
Abaixo temos outro exemplo de um diagrama de atividades completo para representar

a atividade de entrega de um material didtico.
Separao e Unio
Comportamento paralelo indicado por separao (Forks) e unies (Joins). Iremos
agora ver este tipo de elemento pertencente ao diagrama de atividades.
Uma separao (Fork) tem uma transio de entrada e vrias transies de sada.
Quando uma transio de entrada acionada (triggered), todas as transies de sada so
executadas em paralelo. Veja o diagrama abaixo:
O diagrama mostra que as atividades de Carregar texto e Exibindo texto podem

ocorrer em paralelo. Essencialmente, isso significa que a seqncia entre elas irrelevante.
Essas atividades tambm podem ser executadas intercaladamente. Por exemplo, uma parte do
texto carregada e ento exibida, depois se carrega outra parte do texto a exibe. Tambm
estas atividades podem acontecer em paralelo, de forma que as duas sero executadas
exatamente ao mesmo tempo, mas sabemos que para este exemplo dado acima isto no
possvel. No podemos carregar e ao mesmo tempo exibir as informaes.
O diagrama de atividades permite que voc escolha a ordem em que faz as coisas. Em
outras palavras, ele simplesmente determina as regras essenciais de seqncia que voc deve
seguir. Esta a diferena-chave entre um diagrama de atividades e um fluxograma: os
fluxogramas so normalmente limitados a processos seqenciais, enquanto que os diagramas
de atividades podem lidar com processos paralelos.
Isso importante para modelagem de negcios. Os negcios tm, freqentemente,
processos no necessariamente seqenciais. Uma tcnica como esta que encoraja
comportamento paralelo valiosa nestas situaes porque ela encoraja as pessoas a se
afastarem de seqencias desnecessrias nos seus comportamentos e a identificar
oportunidades para fazer coisas em paralelo. Isso pode melhorar a eficincia e o retorno de
processos de negcio.
Os diagramas de atividades tambm so teis para programas concorrentes, uma vez
que voc pode projetar graficamente quais caminhos (threads) voc tem e quando eles
precisam ser sincronizados. Quando voc tem comportamento paralelo, precisa sincronizar.
No podemos liberar a edio do arquivo at que ele seja completamente carregado.
Mostramos isso com a unio (join) antes da atividade Liberar edio do arquivo.
Com a unio (join), a transio seguinte efetuada somente quando todos os estados
nas transies de entrada tenham completado suas atividades.
Separao e unio devem se completar. No caso mais simples, isso significa que toda
vez que voc tiver uma separao, deve ter uma unio que una os threads iniciadas por
aquelas separaes. (Esta regra vem do fato de que um diagrama de atividades , atualmente,
uma forma de diagrama de estados).
Entretanto, existem vrias extenses para esta regra.
Um thread que sai de uma separao pode abrir-se em uma nova separao, com os
novos threads juntando-se antes de alcanar a unio da primeira separao.
Se um thread saindo de uma separao vai direto para outra separao, voc pode
remover a segunda separao e somente ter os threads da segunda separao saindo da
primeira separao. De modo semelhante, se uma unio vai direto para outra unio, voc
pode eliminar a primeira unio e ter as threads indo direto para a segunda. Isso uma forma
de simplificar o diagrama; ela tem o mesmo significado semntico como se as separaes e
unies extras estivessem l.
Existe uma exceo para a regra de que todos os estados de entrada em uma unio
devem ter terminado suas atividades, antes que a unio possa ser efetuada. Voc pode
acrescentar uma condio para um thread saindo de uma separao. O resultado um thread
condicional. Durante a execuo, se a condio de um thread condicional for falsa, este thread
e considerado completado no que diz respeito a unio. Veja na figura abaixo um exemplo:
Raias (Swimlanes)
Os diagramas de atividades dizem o que acontece, mas no dizem quem faz o que. Em
programao, isso significa que o diagrama no representa qual classe responsvel para cada
atividade.
Em modelagem de domnio, isso significa que o diagrama no representa que pessoas
ou departamentos so responsveis por cada atividade. Uma soluo, aqui, rotular cada
atividade com a classe ou pessoa responsvel. Isso funciona, mas no oferece a mesma clareza
que os diagramas de interao (estudaremos mais tarde) para mostrar a comunicao entre
objetos.
Raias so uma soluo para isso. Para usar raias, voc deve organizar seus diagramas
de atividades em zonas verticais separadas por linhas. Cada zona representa as
responsabilidades de uma classe especifica ou, um departamento especfico.
As raias so teis porque elas combinam a descrio de lgica do diagrama de
atividades com a descrio de responsabilidade do diagrama de interao. Entretanto, elas
podem ser difceis de serem projetadas em um diagrama complexo. Veja abaixo a
representao das raias.
Quando Utilizar Diagramas de Atividades?

Como a maioria das tcnicas de modelagem comportamental, os diagramas de
atividades tm qualidades e fraquezas definidas, por isso a melhor maneira de us-los em
combinao com outras tcnicas.
A maior qualidade dos diagramas de atividades est no fato de que eles suportam e
encorajam comportamento paralelo. Isso os torna uma grande ferramenta para modelagem
de workflow, e, em princpio, para programao concorrente. A maior desvantagem destes
diagramas que eles no deixam muito claras as ligaes entre aes e objetos.
Voc pode definir uma ligao para um objeto rotulando uma atividade com um nome
de objeto ou usando raias que dividem um diagrama de atividades em base em
responsabilidades, mas isso no tem a clareza simples de diagramas de interao
(estudaremos estes diagramas mais adiante no curso). Por esta razo, algumas pessoas sentem
que diagramas de atividades no so orientados a objetos e, portanto, so maus.
A tcnica pode ser muito til nas seguintes situaes:
Analisando um caso de uso. Neste estgio, no estou interessado em alocar aes aos
objetos; eu preciso simplesmente compreender que aes precisam acontecer e quais
so as dependncias comportamentais.
Compreendendo o workflow. Mesmo antes de iniciar os casos de uso, acredito que os
diagramas de atividades so muito teis para compreenso de um processo de
negcio. Posso, facilmente, projetar estes diagramas junto com especialistas do
negcio para compreender como o negcio funciona e como ele pode mudar.
Descrevendo um algoritmo seqencial complicado. Neste caso, um diagrama de
atividades no nada mais do que um flowchart em notao UML. Os prs e contras
comuns de flowcharts se aplicam aqui.
Lidando com aplicaes de processamento paralelo. Este tipo de diagrama, como j
foi mostrado pode ser utilizado para demonstrar atividades que devem ou podem
acontecer em paralelo.
No use diagramas de atividades nas seguintes situaes:
Tentando ver como os objetos colaboram. Um diagrama de interao mais simples e

lhe d uma viso mais clara das colaboraes.
Tentando ver como um objeto se comporta durante o ciclo de vida. Use um diagrama
de estados para isso (Estudaremos mais adiante no curso).

Apostila de AP

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Apostila de AP

Transféré par

Droits d'auteur :

Formats disponibles

Etec de Hortolndia

Rua Capito Lourival Mey, 750-Jd. Santana.

Fone: (019) 38973727

Introduo Anlise e Projeto

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

O que linguagem de Modelagem?

Por que fazer Anlise e Projeto?

Objeto (ou instncia)

Atributos (ou Propriedades)

Mtodos (ou Aes)

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Alternativa: Conta inexistente

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

2 Caso de Uso: uma descrio da maneira do usurio usar o sistema.

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Relacionamento entre casos de uso e atores

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Exerccio: Desenvolver um caso de uso para um sistema de vdeo-locadora.

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

O conceito semelhante definio de variveis (pblica, local, privada, etc.), mas

A propriedade ser vista e usada dentro da classe na qual foi

Obs.: A composio e a agregao pode ser demonstrado juntos.

Exemplo geral: Diagrama de uma rede hospitais.

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Exemplo com os atributos:

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Assim, estabelecemos uma interao que corresponde representao de um

A representao dos objetos em um diagrama de seqncias feita com um retngulo

Um objeto, que j existe quando a transao do diagrama tem incio, mostrado

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

As mensagens so enviadas de um objeto a outro, por meio de setas que partem de

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Um estado pode ser opcionalmente subdividido em compartimentos separados cada

As expresses citadas identificam, cada qual, o evento que dispara a expresso

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Durante sua permanncia no estado adulto, essa pessoa exerce a ao Trabalhar .

Estado Inicial e Estado Final

Um estado final um tipo de estado que indica que a mquina de estados ou um

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

A condio de guarda uma expresso booleana que determina, quando verdadeira, o

Um evento a especificao de um tipo de ocorrncia observvel. Para propsitos

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Quando Utilizar Diagramas de Estados?

Se voc utilizar diagramas de estados, no tente projet-los para cada classe no

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

O diagrama de atividades descreve a seqncia de atividades, com suporte para

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Voc no precisa mostrar explicitamente o losango para desvios e intercalaes. Um

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Abaixo temos outro exemplo de um diagrama de atividades completo para representar

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

O diagrama mostra que as atividades de Carregar texto e Exibindo texto podem

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Quando Utilizar Diagramas de Atividades?

Apostila da disciplina de Anlise de Programa elaborada pela professora Juliana Frau

Tentando ver como os objetos colaboram. Um diagrama de interao mais simples e