Apostila de AP

8/17/2019 Apostila de AP

1/39

Apostila da disciplina de Análise de Programa elaborada pela professora Juliana Frau

IInnttr r oodduuççããoo àà AAnnáálliissee ee PPr r oo j jeettoo ddee SSiisstteemmaass

Etec de Hortolândia

Rua Capitão Lourival Mey, 750-Jd. Santana.

Fone: (019) 3897 –3727


2/39


Capítulo 1

Definição

A UML (Unified Modeling Language, ou, traduzindo, Linguagem de ModelagemUnificada) é uma linguagem que serve para especificar, construir, visualizar e documentar osartefatos de um sistema.

Visão Histórica

Na primeira década de 1990, houve uma proliferação de métodos e notações para amodelagem segundo a abordagem orientada a objetos. Foi quando se percebeu a necessidadede existência de uma linguagem que viesse a torna-se norma, sendo aceita e utilizada querpela indústria, quer pelos ambientes acadêmicos.

Surgiram, dessa forma, alguns esforços no sentido de normalidade, sendo que a UML

apareceu, em 1996, mais bem posicionada como a linguagem “unificadora” de nota ções,diagramas, e formas de representação.

Resumo histórico

- 1994 – Rumbaugh (OMT) se uniu ao Grady Booch – intenção de integrar seusmétodos

- Conferencia OOPSLA’95 – 1ª descrição de seu método unificado- Ivar Jacobson (OOSE) se uniu a eles- 1996 – “Três amigos” – 1ª Versão da UML- OMG – padronização do método

- Varias propostas de outras organizações – Rational Software - versão 1.0 da UML- Versão 1.1 da UML adotada como padrão- 1999 – versão 1.3 torna-se publica

O que é linguagem de Modelagem?

Vocabulário e regras voltadas para a representação conceitual e física de um sistema aser desenvolvido.

A UML indica como criar e ler modelos, mas não aponta quais modelos deverão sercriados. Esta tarefa cabe ao processo de desenvolvimento de sistemas

Modelagem: Objetivos

Guia para a construção do sistema modelos documentam as decisões tomadasLinguagem comum entre desenvolvedores

Uso de UML

CASE – Aderir ao padrão da ferramentaUso de diagrama para comunicação

Ferramentas Case


3/39


Rational Rose

TogetherSoft

ArgoUML

Poseidon

Jude

Por que fazer Análise e Projeto?

O produto final do processo de desenvolvimento de sistema é o código executávelDocumentação: facilita a comunicação – Visão geral do sistema

Orientação a Objetos

Orientação a objetos é uma nova maneira de pensar os problemas de linguagens deinformação utilizando modelos organizados a partir do mundo rela. O artefato-base é o“objeto”, capaz de combinar estrutura e comportamento em uma única entidade. A

orientação a objetos é uma metodologia de programação, assim como a procedimental,orientada a eventos e outros fenômenos. Tudo o que podemos ver no mundo real éconsiderado um objeto com atributos e procedimentos.

Objeto (ou instância)

São elementos que pertencem ao mundo real, ou imaginário, e que podemos dealguma forma, identificar, como uma pedra, uma caneta, um copo ou mesmo uma fada. Umobjeto possui, armazenada em si mesmo, determinadas propriedades de um objeto sãochamadas, também, de atributos.

O objeto interage com o meio e, em função das excitações a que é exposto, realizadeterminadas ações que alteram o seu estado (seus atributos). Os atributos de um objeto nãosão estáticos; eles sofrem alterações com o tempo.

Para a implementação do paradigma OO, um objeto é uma entidade única capaz dereunir atributos e métodos, ou seja, ele reúne as propriedades dos objetos e as reações àsexcitações sofridas.

Classe

Representa um conjunto de objetos com características semelhantes. Uma classedefine o comportamento dos objetos por meio de métodos, definindo, os estados que ele é

capaz de manter mediante atributos. Por exemplo, a classe “Pessoa” poderia ter os objetos(instâncias) “Carolina”, “Izilda”, ”Lucas”, ”Ricardo” e “Paulo”.

Atributos (ou Propriedades)

A todo objeto podemos relacionar alguns atributos (propriedades). Por exemplo, emum relógio, a hora e a data são os principais atributos. Na programação orientada a objetos, osatributos são definidos na classe e armazenados de forma individual ou coletiva.

Atributos de classe (coletivos) são os divididos entre todos os objetos criados, sendoarmazenados na classe. Um bom exemplo seria um contador para relógios criados. Por outrolado, os atributos de objeto (individuais) funcionam quando um atributo é individual,

armazenado no objeto. Um bom exemplo é pó horário marcado em um relógio. Cada relógiotem uma hora, que pode ou não estar certa.


4/39


Métodos (ou Ações)

A todo objeto, podemos relacionar determinados comportamentos, ações e reações.As ações ou os comportamentos dos objetos são chamados de métodos, assim, um método é

uma função um serviço fornecido pelo objeto.Os comportamentos dos objetos são definidos por meio dos métodos e servem para

manipular e alterar os atributos de um objeto (alteram seu estado).Como alguns exemplos, podemos citar os objetos e suas ações:

Um automóvel tem o comportamento de se locomover;

Um computador, o de processar programas;

Uma edificação, o de dar abrigo.


5/39


Capítulo 2

Diagrama de Caso de Uso

Um caso de uso descreve uma seqüência de ações que representam um cenárioprincipal (perfeito) e cenários alternativos, com o objetivo de demonstrar o comportamentode um sistema (ou parte dele), através de interações com atores.

Uma vez que o desenvolvedor levante os requisitos com o usuário, há a necessidadede documentá-los, não só para entendimento e validação de ambas as partes, como paraservir de base. A documentação dos requisitos evita que informações importantes não sepercam, sendo descobertas apenas ao apresentar o produto final ao usuário.

Utilizando a modelagem de casos de uso, o primeiro passo do desenvolvedor é separaras funcionalidades do sistema. Destas funcionalidades, devemos agrupar um conjunto deações que tenham um objetivo bem definido.

Suponhamos, num sistema de vendas de uma loja de roupa, que sejam tarefas

distintas e bem definidas: consultar informações sobre o produto, efetuar reserva, emitircomprovante de reserva, efetuar venda, emitir nota fiscal, realizar fechamento diário do caixa,etc. Cada uma destas tarefas possui um conjunto de ações que precisam ser executadas paraque o objetivo da tarefa seja alcançado. No caso de efetuar venda, é preciso informar aidentificação da vendedora, a identificação do produto, quantidade vendida, etc. Aopensarmos nessas ações realizadas numa rotina sem problemas, estamos lidando com umcenário perfeito, que será o nosso cenário principal.

O cenário principal descreve uma seqüência de ações que serão executadasconsiderando que nada de errado ocorrerá durante a execução da seqüência.

Exemplo: Emitir saldo em um terminal caixa eletrônico

Cenário Principal1. O sistema realiza a leitura do cartão magnético do correntista.2. O sistema solicita a digitação da senha. O correntista digita a senha.3. O sistema valida a senha.4.

O correntista seleciona a opção de saldo5.

O sistema questiona o tipo de saldo: conta corrente, poupança e aplicações.6. O sistema processa e mostra o saldo solicitado pelo cliente

No exemplo, temos um cenário perfeito, no qual nada ocorre de errado. Todavia, omundo não é perfeito, muito menos as transações de um sistema. As exceções sãorepresentadas com cenários alternativos. Por exemplo: considerando o cenário principal da

emissão de saldo em um Caixa Eletrônico, poderíamos modelar os cenários alternativos.

Alternativa: Problemas na leitura do cartão magnético1a) Se o sistema não conseguir ler os dados do cartão magnético, tentar nova leitura

por, no máximo, mais duas vezes.

Alternativa: Senha invalida3a) Se a senha digitada pelo correntista não for igual a senha cadastrada no sistema,

informar ao mesmo e solicitar nova digitação. Esse processo pode ser repetido por no máximotrês tentativas (incluindo a primeira). Após a terceira tentativa, a conta deverá ser bloqueada eo caso de uso encerrado. Include Bloquear Conta.


6/39


Alternativa: Conta inexistente6a) Se o correntista não possuir o tipo de conta selecionada, informar ao mesmo.

No exemplo as alternativas são apresentadas como subitens do cenário principal (1 – 1a; 3 – 3a; 6 – 6a). Esse procedimento facilita a associação da alternativa com o fluxo principal.

O caso de uso, por expressar os requisitos do sistema – nada mais do que a essênciadeste -, é utilizado durante todo o processo de desenvolvimento. Os requisitos além de serembase para a criação dos modelos de análise, projeto e implementação, também são usadoscomo base para a criação de testes do sistema.

Ao modelarmos um sistema, necessitamos saber até que ponto devemos nospreocupar. Estes pontos-limites são a fronteira do sistema. Por exemplo: um sistema decontrole de vendas emitirá em alguns momentos o faturamento semanal ou mensal de cadavendedor para o Departamento Pessoal. Todavia, não é responsabilidade do sistema o que oDepartamento Pessoal fará com essa informação.

Os sistemas recebem e enviam informações para o mundo externo através de suasfronteiras. Logicamente que essas informações não podem cair num “buraco negro”, na saída,

nem surgem por mágica, na entrada. Alguém ou algo deve ser responsável por enviar e/oureceber informações 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 usuário do sistema aointeragir com um determinado caso de uso.

Exemplo: Num determinado sistema acadêmico, a rotina de atualizar a freqüência dosalunos pode ser executada por quem? Pelos funcionários da Secretaria, pelo próprio Professorou pelo Sistema de Avaliação on-line. Esses papeis são representados por Atores.

Essa comunicação sistema-ator (e vice-versa) consiste da interação entre sistema eatores.

É responsabilidade do caso de uso demonstrar com quais atores o sistema interage.Essa identificação na fase de analise fornece ao projetista, no futuro, base para a criação dosperfis de acesso ao sistema.

Conceitos

1 - Ator: representa um papel que o usuário vai desempenhar em relação ao sistema.Representação:

Exemplos:


7/39


2 – Caso de Uso: é uma descrição da maneira do usuário usar o sistema.Representação:

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 (emprestarmaterial) ou gerúndio (emprestando material). Pode ser utilizada qualquer uma dessas formasde nomenclatura, porém, deve-se prezar pela padronização, ou seja, se for escolhido uma dasformas, deve-se utilizar em toda a modelagem.

3 – Associação de Extensão: é um tipo de associação que pode ser utilizado emdiagramas de caso de uso. Neste relacionamento, a descrição de caso de uso pode ser

estendida para outros casos de uso, através de associação de extensão.Representação:


8/39


9/39


Generalização

Ocorre entre casos de uso e atores.É considerado quando temos dois elementos semelhantes, mas como um deles

realizando algo a mais.

Extensão (Extend)

Um relacionamento de extensão entre casos de uso indica que um deles terá seuprocedimento acrescido, em um ponto de extensão, de outro caso de uso, identificado comobase.

Os pontos de extensão são rótulos que aparecem nos cenários do caso de uso base. Épermitido colocar diversos pontos de extensão num mesmo caso de uso, inclusive repetir um

mesmo ponto de extensão.Utilizada para expressar rotinas de exceção e pra descrever cenários opcionais de um

Caso de Uso. Os Casos estendidos descrevem cenários que somente ocorrerão em umasituação específica, se uma determinada condição for satisfeita.

Inclusão (Include)

Indica que um deles terá seu procedimento copiado num local especificado no outrocaso de uso. Esse tipo de relacionamento é utilizado quando existirem cenários cujas açõesservem a mais de um caso de uso.

Mais do que evitar a cópia de trechos idênticos, ganhamos tempo de modelagem etambém de implementação ao trabalhar com casos de uso de inclusão.

Utilizada para expressão rotinas de fluxo alternativo.


10/39


Exercício: Desenvolver um caso de uso para um sistema de vídeo-locadora.


11/39


Capítulo 3

Diagrama de classe

Após extrairmos dos requisitos os objetos da aplicação, precisaremos separar eclassificar suas características, modelando, por conseguinte, as classes do sistema. Entretantoa essência de um sistema não está apenas em suas classes, mas principalmente em seusrelacionamentos.

As classes são declaradas no diagrama de classes, mas são usadas em muitos outrosdiagramas. Uma classe é representada como um retângulo subdividido em trêscompartimentos, separados por linhas horizontais que nesta ordem armazenam:

O nome da classe e outras propriedades gerais da mesma, incluindoestereótipos;

Lista de atributos;

Lista de operações

Classes podem se relacionar com outras através de diversas maneiras: associação(conectadas entre si), dependência (uma classe depende ou usa outra classe), especialização(uma classe é uma especialização de outra classe), ou em pacotes (classes agrupadas porcaracterísticas similares).

Todos estes relacionamentos são mostrados no diagrama de classes juntamente comas suas estruturas internas, que são os atributos e operações. O diagrama de classes éconsiderado estático já que a estrutura descrita é sempre válida em qualquer ponto do ciclo devida do sistema. Um sistema normalmente possui alguns diagramas de classes, já que não sãotodas as classes que estão inseridas em um único diagrama e uma certa classe pode participar

de vários diagramas de classes.

Visibilidade

A visibilidade identifica por quem uma propriedade (atributo ou operação) pode ser

utilizada.


12/39


O conceito é semelhante à definição de variáveis (pública, local, privada, etc.), masagora nós lidamos com escopo dentro de classes, objetos, pacotes, etc.

+ ou public A propriedade será vista e usada dentro da classe na qual foideclarada, em qualquer elemento externo e nas classes

descendentes.# ou protected A propriedade será vista e usada apenas dentro da classe na

qual foi declarada e pelas classes descendentes.

- ou private A propriedade será vista e usada apenas dentro da classe naqual foi declarada.

~ ou package A propriedade poderá ser vista e usada por elementos queestejam declarados dentro do mesmo pacote no qual estáinserida a classe que a declarou. É como a pública, só que nãogeneralizada a qualquer elemento externo, mas apenas aoselementos externos localizados no mesmo pacote.

Atributos e Operações

Depois de identificar os objetos (ou conceitos) interessantes, temos que definir aspropriedades deles que queremos representar. Estas propriedades podem ser dados(atributos) ou operações.

Um atributo representa uma propriedade que todos os objetos da classe têm (porexemplo, todas as mesas têm uma altura, numero de pernas, posição da mesa na sala, etc.).Mas cada objeto terá valores particulares para seus atributos (algumas mesas são baixas,outras são altas, etc.). O valor de um atributo pode mudar com o tempo (posição da mesa nasala), a lista de atributos geralmente não 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) devemidentificar a mesma coisa. Por exemplo, um professor e uma sala ambos podem ter umatributo “numero” porque ele significa a mesma coisa nas duas classes, mas a “nota” que umaluno consegue numa disciplina e um atributo para gravas anotações sobre uma sala (ex.: luznão funciona nesta sala), não podem ambos ser chamados de “nota” porque as duas coisas são

diferentes.O nome de um atributo é um texto contendo letras, dígitos e algumas marcas de

pontuação. A UML sugere capitalizar todas as primeiras letras das palavras, exceto a primeirapalavra (ex.: “nome”; “codigoPessoaFisica”).

Conceitos

1–

ClasseÉ uma abstração de informações da realidade.Exemplo:

2 – Associação Simples

É um relacionamento ou conexão entre duas classes


13/39


Exemplo:

3 – Papel

É o papel do relacionamentoExemplo:

4 – Multiplicidade

Exatamente uma – 1

Vários (zero ou mais) – 0..*

Opcional (zero ou uma) – 0..1

Especificada Numericamente – n..m

5 – Direcionamento de Leitura

Direita para esquerdaEsquerda para direita

Exemplo:

6 – Agregação

É um relacionamento de todo-parte, onde o todo não precisa das partes para existir.Exemplo:

7 – Composição

É um relacionamento de todo-parte, onde o todo precisa das partes para existir.Exemplo:


14/39


Obs.: A composição e a agregação pode ser demonstrado juntos.

8 – Generalização/Especialização

É um relacionamento onde as classes específicas herdam as características e ações daclasse geral.

Exemplo:

9 – Restrições

Representa restrições relacionadas às classes.Exemplo:

10 – Nota

Trata-se de colocação de textos, informações e descrições importantes com relação àsclasses.

Exemplo:

11 – Classe de associação

Trata-se de uma associação modelada com uma classe.A classe de associação só existe se existir o relacionamento entre duas classes que

geram informações que não podem ser armazenadas nas mesmas.


15/39


Exemplo:

Exemplo geral: Diagrama de uma rede hospitais.


16/39


Capítulo 4

Diagrama de Objetos

Um diagrama de objetos consiste numa instancia do diagrama de classes, no qual paracada classe temos um objeto (sua instancia) em um determinado ponto do tempo e são muitoúteis para facilitar a modelagem de estruturas complexas de dados.

O diagrama de objetos pode também auxiliar o desenvolvedor no momento deidentificar problemas na execução de uma aplicação. Durante o debugging, pode-se parar aexecução e paralelamente mapear, num diagrama de objetos, os objetos que estão sendomanipulados, expandindo seus relacionamentos e alguns objetos vizinhos.

A representação gráfica de um objeto é similar à de uma classe. Consiste numretângulo com dói compartimentos. O primeiro mostra o nome do objeto e o segundo mostraos atributos, um em cada linha, com seus valores.

O nome do objeto deve ser sublinhado, na seguinte notação:

nome do objeto: nome da classe

Por exemplo:

coordenadaFigura1: Coordenada

É possível ainda omitir o nome do objeto (preservando os dois pontos), representandoum objeto anônimo ou omitir o nome da classe (juntamente com os dois pontos). Em qualquerum desses casos, mantém-se o sublinhado.

Por exemplo:

: Coordenada

coordenadaFigura1:

Exemplo com os atributos:

Atributos cujos valores não sejam relevantes para a modelagem pode ser omitidos.


17/39


Capítulo 5

Diagramas de Interação

Interação corresponde a um conjunto de mensagens trocadas entre objetos, com oobjetivo de alcançar determinado propósito, respeitando-se o contexto do sistema.Um diagrama de interação mostra as interações por meio de uma visão dinâmica do

sistema. Por representar um sistema, subsistema, operação, classe ou cenário de caso de uso,sendo essa ultima representação a mais freqüente. Um diagrama de interação é formadobasicamente, por objetos, relacionamentos e mensagens. Os diagramas de interação seapresentam em duas formas:

Diagrama de seqüência

Diagrama de colaboraçãoEsses diagramas possuem cada qual alguns aspectos que os diferenciam. O diagrama

de seqüência enfatiza a seqüência de mensagens dentro de uma linha de tempo, enquanto

que o de colaboração enfatiza o relacionamento estrutural entre os objetos, sem se preocuparcom o tempo determinado para cada interação.

Diagrama de seqüências

Para melhor ilustrar a interação de um Diagrama de Seqüências, vamos imaginar umprocesso X qualquer de uma empresa, na qual trabalham os funcionários Antônio, João eCarlos. Num dado instante, o Gerente da empresa solicita ao Antônio que prepare um relatóriode comissões para um determinado mês. Entretanto, para que o Antônio consiga prepararesse relatório, ele precisa do total de cada vendedor, obtido no mês em foco, e essainformação quem tem é o João. Então, Antônio passa um e-mail para o João pedindo essa

informação.João quando recebe essa mensagem (eletrônica) inicia os procedimentos necessários

para relacionar as vendas de cada vendedor. Todavia, ele só possui em mãos a matrícula decada vendedor e seu total vendido. Mas ele pode conseguir o nome de cada vendedor com oCarlos. Assim, João passa um e-mail para o Carlos, enviando no corpo da mensagem a lista dematrículas que ele possui, solicitando que seu colega diga a quem pertence.

Carlos, ao receber a mensagem, procura em suas fichas os nomes dos vendedores. Deposse desses nomes, ele responde ao e-mail de João, acrescentando os nomes dosvendedores. João, ao receber a resposta de Carlos, responde a mensagem original de Antônio,acrescentando no corpo da mensagem a lista de vendedores (com matrícula e nome)acompanhada dos totais de vendas de cada um.

Antônio, feliz da vida pois a equipe é bem entrosada, abre a mensagem de resposta,pega as informações recebidas e coloca em seu relatório. Nada como uma empresa quefunciona! Guardadas as devidas proporções, se trocarmos os funcionários Antônio, João eCarlos pelas responsabilidades que eles possuem, temos a encenação da troca de mensagensentre objetos em um diagrama de seqüências.

Antônio é um captador e transmissor de informações; será nossa tela de Relatório.João é responsável por controlar as vendas do mês; será nosso objeto Vendas. Carlos éresponsável por controlar o cadastro dos vendedores; será nosso objeto vendedor.

A representação gráfica de um diagrama de seqüências é baseada em duas dimensões.A primeira dimensão é vertical e representa as mensagens trocadas no decorrer de um tempode vida (eixo Y). A segunda dimensão é horizontal e representa os objetos participantes das

interações (eixo X). As mensagens correspondem a chamadas de serviços dos objetos, ou seja,a chamadas de suas operações.


18/39


Assim, estabelecemos uma interação que corresponde à representação de umelemento do modelo (por exemplo: Diagrama de Seqüências para o caso de uso Cadastro deFuncionário) e para tal relacionamos os objetos envolvidos e desenhamos cada chamada deoperação como o disparo de uma mensagem, partindo do objeto chamador para o objetoexecutor da operação.

A representação dos objetos em um diagrama de seqüências é feita com um retânguloalinhado no topo do diagrama, partindo dele uma linha vertical tracejada denominada linha devida, que é desenhada até o fim do diagrama. A linha de vida representará a vida deste objeto

dentro de um determinado período de tempo.

Um objeto, que já existe quando a transação do diagrama tem início, é mostradoalinhado ao topo do diagrama, de forma a ficar acima da primeira seta de mensagem. Por


19/39


outro lado, um objeto que continuará a existir, mesmo após a finalização da transação dodiagrama, tem sua linha de vida estendida para além da última seta de mensagem.

A criação ou destruição de um objeto dentro do período de tempo total representadopelo diagrama são mostradas desenhando-se o início ou fim da linha de vida do objeto noponto determinado pela criação ou destruição. No caso da criação, a seta que representa essa

mensagem é desenhada de forma a apontar sua cabeça para o símbolo do objeto. No caso dadestruição, a seta que carrega essa mensagem é direcionada a um grande "X" colocado no fimda linha de vida. As mensagens de criação e destruição podem ser estereotipadas com e , respectivamente.


20/39



21/39


As mensagens são enviadas de um objeto a outro, por meio de setas que partem deuma linha de vida para outra. Essas setas são identificadas com o nome da operação que estásendo chamada. As mensagens podem carregar a solicitação de um processamento, acomunicação de um evento ou outras informações relevantes para o cumprimento deresponsabilidades. A seqüência de mensagens pode ser numerada, mas seu uso é

desnecessário nesse tipo de diagrama. Na figura acima você pode ver as mensagensnumeradas sendo que os números ajudam no entendimento da ordem das mensagens.Ao alcançar o outro lado, a seta dá início à ativação, que corresponde ao período de

tempo durante o qual um determinado procedimento de um objeto está sendo executado.Essa ativação é mostrada graficamente como um retângulo fino e comprido, que tem sua partesuperior alinhada ao final da seta ativadora e se estende até o fim do processamento, quepode ter uma representação extra com uma mensagem de retorno. A mensagem de retornonão é obrigatória. Os retornos são dados por uma linha pontilhada com uma seta partindo doreceptor da mensagem para quem a chamou.

A seta de mensagem, além do nome da operação, também pode conter uma condiçãoe/ou uma expressão de iteração (seqüência repetida de mensagens). Textos de identificação

como restrições de tempo, descrições de ações durante uma ativação, entre outros, tambémpodem ser mostrados na margem esquerda do diagrama ou perto dos elementos que elesidentificam.

Condições são colocadas dentro de colchetes e determinam que a mensagem só serádisparada se a condição for verdadeira. Por exemplo:

[instrutorOk] agendarCurso()

A iteração representa o envio da mesma mensagem diversas vezes para o mesmoobjeto, sendo comum no tratamento de coleções de objetos. Vamos supor que tenho quechamar a operação calculaMedia() dos alunos da turma. Marcando a iteração para a

mensagem calculaMedia(), indicamos que ela deve ser chamada várias vezes. A representaçãoda iteração é feita dentro de colchetes, incluindo antes do colchete inicial o símbolo (*) – Anotação de condição e iteração é a mesma para o diagrama de iteração. O texto dentro doscolchetes indica a condição que determinará quantas vezes a mensagem será passada. Porexemplo:

*[para cada aluno da turma] calcularMedia()*[para cada instrutor] instrutorOk := disponivel(data)

No caso de chamada recursiva (um objeto passa mensagem para si próprio), o segundosímbolo de ativação é desenhado levemente à direita do primeiro, dando a impressão de que

estão empilhados. Essa chamada recursiva é denominada auto-chamada.Num fluxo de controle procedural, a mensagem de retorno pode ser omitida, pois fica

implícito que, ao final da ativação, o retomo ocorrerá, ou seja, assume-se que toda mensagemde chamada faz par com uma mensagem de retorno. Para fluxos de controle não-procedurais(como mensagens de processamento paralelo), mensagens de retorno devem ser mostradasexplicitamente.

Na arrumação dos objetos, deve-se colocar como o primeiro objeto exatamenteaquele que dá início à interação.

No diagrama de seqüências também representamos uma ramificação para condiçõesou concorrências, que é mostrada por múltiplas setas partindo de um ponto simples, sendocada ramo identificado por uma condição. Dependendo de como as condições são

mutuamente exclusivas, essa construção pode representar condicionalidade ou concorrência.Veja a figura abaixo:


22/39


Diagrama de colaboração

Os objetos são distribuídos no diagrama de colaboração na ordem similar à dodiagrama de seqüências, obedecendo à seqüência de mensagens. A colaboração entre objetosé representada por uma ligação simples acompanhada de uma numeração seqüencial e deoutras informações como condições e iterações.

Em virtude da forma como um diagrama de colaboração é apresentado, identificamosa seqüência temporal das mensagens por meio de seqüências numéricas. A autochamada dodiagrama de seqüências é identificado como autodelegação no diagrama de colaboração erepresentado como um arco ligado ao objeto.

Na figura abaixo, a primeira mensagem é a chamada do método obterGrade() para o

objeto cursoX. O código deste método para ser concluído necessita de informações dasdisciplinas do referido curso e das turmas ativas. Então, para cada disciplina é chamado ométodo obterInfDisciplina() do objeto disc1. O objeto disc1, por sua vez, necessita deinformações dos pré-requisitos das disciplinas. Então, passa uma mensagem para si mesmo,chamando o método obterPreRequisito(). O objeto cursoX, depois que recebe a resposta desua mensagem n° 2, chama o método obterTurmasAtivas() que pertence ao objeto turma 1.Repare que uma grande diferença entre o Diagrama de Colaboração e o de Seqüências éexatamente o que ocorre com o objeto cursoX. Não fica explícito no diagrama as mensagensde retorno e o momento em que isso ocorre.


23/39



24/39



25/39


Capítulo 6

Diagrama de Estados

O diagrama de gráfico de estados descreve o comportamento de objetos como reaçãoa eventos discretos (como por exemplo sinais e invocação de operações), por meio deseqüências de estados e ações que ocorrem durante a sua vida.

Um diagrama de gráfico de estados tem por objetivo mostrar uma máquina de estado.Uma máquina de estado consiste num comportamento que especifica a seqüência de estadosque um objeto atravessa durante sua vida, em resposta a eventos, junto com suasresponsabilidades e ações.

Estado

Um estado é uma condição ou situação existente na vida de um objeto durante a qual

o estado satisfaz alguma condição, executa alguma atividade ou espera por algum evento.Um estado é representado graficamente como um retângulo com cantos ar-

redondados. O nome do estado é colocado no centro do mesmo, caso ele não estejasubdividido em compartimentos. Veja na figura abaixo a representação de um estado:

Um estado pode ser opcionalmente subdividido em compartimentos separados cada

qual por uma linha horizontal. São eles:

Compartimento de nome: armazena o nome do estado, como uma string. É possíveldesenharmos estados sem nomes. Estes são estados anônimos, distintos em si.

Compartimento de transições internas: este compartimento armazena uma lista deações ou atividades internas que são executadas enquanto o objeto se apresenta no estadoem foco.

Essas transições internas são representadas por expressões que identificam as cir-cunstâncias sobre as quais a ação associada será invocada. A ação associada ao tipo detransição externa pode fazer uso de quaisquer atributos e links, que estão no escopo do objetoproprietário. Uma transição interna não modifica o estado do objeto.

Por exemplo: quando um objeto OperacaoBancaria entra no estado de "Liberandodinheiro de saque", ele pode chamar uma ação que bloqueie na conta do correntista o valordesignado para saque. Na saída desse estado, ele pode chamar a ação de debitar o valor daconta. Durante o estado, estará sendo executada a operação de contagemCedulas().

Existem algumas palavras reservadas que representam as transições internas. Vejaquais são e seus significados:

entry: identifica uma ação que é executada na entrada do estado.exit: identifica uma ação que é executada na saída do estado.do: identifica uma atividade em andamento, ou seja, que é executada continuamentedurante o tempo em que o objeto permanece nesse estado.include: usado para identificar a invocação de uma submáquina, cujo nome está ligadoà expressão.


26/39


27/39


Durante sua permanência no estado adulto, essa pessoa exerce a ação Trabalhar .Finalizarei o exemplo com uma separação do estado Adulto (como solteiro) para um estado deCasado.

Estado Inicial e Estado Final

Um estado inicial é um tipo de estado que indica o local de início na máquina de esta-dos ou em um subestado. É representado graficamente como um círculo preenchido.

Um estado final é um tipo de estado que indica que a máquina de estados ou umestado composto concluiu sua execução. É representado graficamente como ura círculoenvolvendo um pequeno círculo preenchido.


28/39


Transições

Uma transição é um relacionamento entre dois estados indicando que houve umamudança de estado e determinadas ações serão executadas, quando um evento específicoocorrer, garantindo que condições foram satisfeitas. A transição é disparada quando ocorre a

mudança de estado.É representada graficamente como uma linha sólida na qual o estado de partida é

identificado como estado de origem e o estado-alvo é o estado de destino. A linha da transiçãofinaliza com uma seta. Pode ser identificada por uma string que possui o seguinte formato:

assinatura-do-evento [ condição-de-guarda ] / expressão-ação

A assinatura-do-evento descreve um evento com seus argumentos, no seguinteformato:

nome-do-evento (lista de parâmetros separada por vírgula )

Exemplo: ChecarEstoque(produto)

A condição de guarda é uma expressão booleana que determina, quando verdadeira, oinício da transição. Pode ser escrita com parâmetros do evento disparador ou ainda atributos elinks do objeto proprietário da máquina de estados. Só é avaliada depois que o evento deativação ocorre. É possível termos várias transições a partir do mesmo estado de origem,identificadas com o mesmo evento, diferenciando apenas na sua condição de guarda.

Exemplo: [estoqueAtual = 0. Outra possibilidade


29/39


30/39


Estado composto

Um estado composto é um estado que possui uma decomposição gráfica em dois oumais subestados concorrentes (sobrepostos) ou sequenciais (disjuntos).Cada região de umestado pode possuir estados inicial e final.

Uma transição para um estado composto representa uma transição para o estadoinicial do referido estado composto. Uma transição para um estado final representa aconclusão da atividade na região do estado composto. Vamos supor um sistema de avaliaçãono qual o aluno responda as questões de sua prova on-line. Vamos pensar para esse sistemaem um objeto Prova (veja figura abaixo). Durante a vida deste objeto, no momento que oaluno responde às questões, o objeto estará passando do estado Aguardando Escolha deQuestão para Aguardando Resposta de Questão e assim por diante. Todavia, em paralelo comessas respostas, temos o estado Checando Término da Prova, que ocorre quando o tempodecorrido de prova se iguala ao valor do atributo tempoProva. Neste caso, estamos diante desubestados concorrentes, nos quais os estados ocorrem simultaneamente.

Quando Utilizar Diagramas de Estados?

Diagramas de estados são bons para descrever o comportamento de um objeto,através de vários casos de uso. Esses diagramas não são muito bons para descrever umcomportamento que envolve vários objetos em colaboração. Para tal, é útil combinardiagramas de estados com outras técnicas.

Por exemplo, diagramas de interação (vistos mais adiante neste curso) são bons paradescrever o comportamento de vários objetos em um único caso de uso, e diagramas deatividades (visto anteriormente) são bons para mostrar a seqüência geral de ações para váriosobjetos e casos de uso.

Nem todo mundo considera que os diagramas de estados sejam naturais. Fique atentoao modo que as pessoas trabalham com eles. Pode ser que sua equipe não considere

diagramas de estados úteis para seu tipo de trabalho. Isso não é um grande problema; comosempre, você deve lembrar-se de usar uma combinação das técnicas que funcionam para você.


31/39


Se você utilizar diagramas de estados, não tente projetá-los para cada classe nosistema. Embora este método seja freqüentemente usado por perfeccionistas de muitaformalidade, ele é quase sempre um desperdício de trabalho. Use diagramas de estadossomente para aquelas classes que exibem comportamento interessante, para as quais aconstrução do diagrama de estados ajude a compreender o que está acontecendo. Muitas

pessoas acreditam que Interface de Usuários e objetos de controle têm o tipo decomportamento que é útil descrever com diagramas de estados.


32/39


Capítulo 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 são ações ou subatividades e no qual todas (ou pelomenos a maioria) as transições são disparadas pela conclusão de ações ou subatividades nosestados de origem. Este diagrama tem por propósito focalizar um fluxo de atividades queocorrem internamente em um processamento, dentro de um período de tempo.

Atividade

Na figura abaixo se pode ver o símbolo de uma atividade, este símbolo é o estado deatividade, ou simplesmente atividade. Uma atividade é um estado de estar fazendo algo:tanto um processo de mundo real, tal como datilografar uma carta, ou a execução de uma

rotina de software, tal como um método em uma classe.

O diagrama de atividades descreve a seqüência de atividades, com suporte paracomportamento condicional e paralelo. Um diagrama de atividades é uma variante de umdiagrama de estados no qual a maioria, se não todos, dos estados é estado de atividade.Portanto, muito da terminologia segue a mesma terminologia de diagrama de estados.

Início do diagrama

O início do diagrama de atividades é marcado com um sinal de um círculo preenchido.Este símbolo é o mesmo para o diagrama de estados. Veja abaixo o símbolo gráfico:

Fim do diagrama

Assim como para indicar o início do diagrama de atividades há um símbolo para indicaro fim deste diagrama e este símbolo é utilizado tanto para o diagrama de atividades como parao diagrama de estados. A representação é um círculo preenchido com um circulo contornandoo mesmo. Veja abaixo o símbolo gráfico:


33/39


Transições

Para ligar as atividades e indicar a seqüência utilizamos fechas que representam as

transições entre as atividades bem como a transição entre o início e a primeira atividade, bemcomo das atividades para o fim do diagrama. Veja abaixo a representação gráfica juntamentecom outros itens do diagrama.

Desvios

Comportamento condicional é delineado por desvios (branches) e intercalações

(merges).Um desvio (branch) é uma transição de entrada única e várias transições de saídaguardadas. Somente uma transição de saída pode ser tomada, de modo que os guardas devemser mutuamente exclusivos. A utilização de [else] como um guarda indica que a transição"else" deverá ser usada se todos os outros guardas do desvio forem falsos. Veja na figuraabaixo a representação gráfica de um desvio (branch):


34/39


Uma intercalação (merge) tem múltiplas transições de entrada e uma única saída. Ummerge marca o final de um comportamento condicional iniciado por um branch. Veja abaixo arepresentação gráfica:

Você não precisa mostrar explicitamente o losango para desvios e intercalações. Umestado de atividade, como qualquer estado, pode ter múltiplas transições de saída guardadas emúltiplas transições de entrada. Use o losango se você quiser deixar claros os desvios e asintercalações em um diagrama.


35/39


36/39


Separação e União

Comportamento paralelo é indicado por separação (Forks) e uniões (Joins). Iremosagora ver este tipo de elemento pertencente ao diagrama de atividades.

Uma separação (Fork) tem uma transição de entrada e várias transições de saída.

Quando uma transição de entrada é acionada (triggered), todas as transições de saída sãoexecutadas 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 seqüência entre elas é irrelevante.Essas atividades também podem ser executadas intercaladamente. Por exemplo, uma parte dotexto é carregada e então é exibida, depois se carrega outra parte do texto a exibe. Tambémestas atividades podem acontecer em paralelo, de forma que as duas serão executadasexatamente ao mesmo tempo, mas sabemos que para este exemplo dado acima isto não épossível. Não podemos carregar e ao mesmo tempo exibir as informações.

O diagrama de atividades permite que você escolha a ordem em que faz as coisas. Emoutras palavras, ele simplesmente determina as regras essenciais de seqüência que você deveseguir. Esta é a diferença-chave entre um diagrama de atividades e um fluxograma: osfluxogramas são normalmente limitados a processos seqüenciais, enquanto que os diagramasde atividades podem lidar com processos paralelos.

Isso é importante para modelagem de negócios. Os negócios têm, freqüentemente,processos não necessariamente seqüenciais. Uma técnica como esta que encoraja

comportamento paralelo é valiosa nestas situações porque ela encoraja as pessoas a seafastarem de seqüencias desnecessárias nos seus comportamentos e a identificar


37/39


oportunidades para fazer coisas em paralelo. Isso pode melhorar a eficiência e o retorno deprocessos de negócio.

Os diagramas de atividades também são úteis para programas concorrentes, uma vezque você pode projetar graficamente quais caminhos (threads) você tem e quando elesprecisam ser sincronizados. Quando você tem comportamento paralelo, precisa sincronizar.

Não podemos liberar a edição do arquivo até que ele seja completamente carregado.Mostramos isso com a união (join) antes da atividade “Liberar edição do arquivo”.Com a união (join), a transição seguinte é efetuada somente quando todos os estados

nas transições de entrada tenham completado suas atividades.Separação e união devem se completar. No caso mais simples, isso significa que toda

vez que você tiver uma separação, deve ter uma união que una os threads iniciadas poraquelas separações. (Esta regra vem do fato de que um diagrama de atividades é, atualmente,uma forma de diagrama de estados).

Entretanto, existem várias extensões para esta regra.Um thread que sai de uma separação pode abrir-se em uma nova separação, com os

novos threads juntando-se antes de alcançar a união da primeira separação.

Se um thread saindo de uma separação vai direto para outra separação, você poderemover a segunda separação e somente ter os threads da segunda separação saindo daprimeira separação. De modo semelhante, se uma união vai direto para outra união, vocêpode eliminar a primeira união e ter as threads indo direto para a segunda. Isso é uma formade simplificar o diagrama; ela tem o mesmo significado semântico como se as separações euniões extras estivessem lá.

Existe uma exceção para a regra de que todos os estados de entrada em uma uniãodevem ter terminado suas atividades, antes que a união possa ser efetuada. Você podeacrescentar uma condição para um thread saindo de uma separação. O resultado é um threadcondicional. Durante a execução, se a condição de um thread condicional for falsa, este threade considerado completado no que diz respeito a união. Veja na figura abaixo um exemplo:


38/39


Raias (Swimlanes)

Os diagramas de atividades dizem o que acontece, mas não dizem quem faz o que. Emprogramação, isso significa que o diagrama não representa qual classe é responsável para cadaatividade.

Em modelagem de domínio, isso significa que o diagrama não representa que pessoasou departamentos são responsáveis por cada atividade. Uma solução, aqui, é rotular cadaatividade com a classe ou pessoa responsável. Isso funciona, mas não oferece a mesma clarezaque os diagramas de interação (estudaremos mais tarde) para mostrar a comunicação entreobjetos.

Raias são uma solução para isso. Para usar raias, você deve organizar seus diagramasde atividades em zonas verticais separadas por linhas. Cada zona representa asresponsabilidades de uma classe especifica ou, um departamento específico.

As raias são úteis porque elas combinam a descrição de lógica do diagrama deatividades com a descrição de responsabilidade do diagrama de interação. Entretanto, elaspodem ser difíceis de serem projetadas em um diagrama complexo. Veja abaixo a

representação das raias.

Quando Utilizar Diagramas de Atividades?

Como a maioria das técnicas de modelagem comportamental, os diagramas deatividades têm qualidades e fraquezas definidas, por isso a melhor maneira de usá-los é emcombinação com outras técnicas.

A maior qualidade dos diagramas de atividades está no fato de que eles suportam eencorajam comportamento paralelo. Isso os torna uma grande ferramenta para modelagemde workflow, e, em princípio, para programação concorrente. A maior desvantagem destesdiagramas é que eles não deixam muito claras as ligações entre ações e objetos.


39/39

Você pode definir uma ligação para um objeto rotulando uma atividade com um nomede objeto ou usando raias que dividem um diagrama de atividades em base emresponsabilidades, mas isso não tem a clareza simples de diagramas de interação(estudaremos estes diagramas mais adiante no curso). Por esta razão, algumas pessoas sentemque diagramas de atividades não são orientados a objetos e, portanto, são maus.

A técnica pode ser muito útil nas seguintes situações:

Analisando um caso de uso. Neste estágio, não estou interessado em alocar ações aosobjetos; eu preciso simplesmente compreender que ações precisam acontecer e quaissão as dependências comportamentais.

Compreendendo o workflow. Mesmo antes de iniciar os casos de uso, acredito que osdiagramas de atividades são muito úteis para compreensão de um processo denegócio. Posso, facilmente, projetar estes diagramas junto com especialistas donegócio para compreender como o negócio funciona e como ele pode mudar.

Descrevendo um algoritmo seqüencial complicado. Neste caso, um diagrama deatividades não é nada mais do que um flowchart em notação UML. Os prós e contras

comuns de flowcharts se aplicam aqui. Lidando com aplicações de processamento paralelo. Este tipo de diagrama, como já

foi mostrado pode ser utilizado para demonstrar atividades que devem ou podemacontecer em paralelo.

Não use diagramas de atividades nas seguintes situações:

Tentando ver como os objetos colaboram. Um diagrama de interação é mais simples elhe dá uma visão mais clara das colaborações.

Tentando ver como um objeto se comporta durante o ciclo de vida. Use um diagramade estados para isso (Estudaremos mais adiante no curso).

Documents

Apostila de AP