UML - Diagrama de Sequência

Pensaram que eu iria parar com a sequencia de artigos sobre UML não é campeões? Posso achar um saco UML mas eu vou terminar sim com esses artigos, hoje vamos falar do Diagrama de Sequência que particularmente é um dos melhores(ou menos piores) da UML! Apenas para refrescar sua memória, a UML é dividida basicamente em 2 tipos de diagramas os de estrutura (Diagrama de classe...etc..) e os de comportamento (diagrama de atividade...etc..) e onde vc acha que e o de sequencia esta acoplado? (R: Comportamento claro)

Antes de explicar técnicamente eu vou dar uma resumida; O diagrama de sequencia tem como objetivo exibir o comportamento dos métodos baseado em uma ação. Ta mas que ação? Vamos imaginar uma consulta de funcionário em um determinado sistema. Veja:

Explicando:  Vejo que nesse diagrama de sequencia temos um ATOR, uma Camada de Apresentação (View), Camada de Negócio (Uma camada para a regra de negócio, controller por exemplo) e uma camada de persistência no banco(ORM).

E divido assim em camada podemos mostrar a sequencia no comportamento delas quando existe a consulta de um funcionário.

IMPORTANTE: O diagrama de sequencia não existe um padrão de nomes, nesse caso utilizamos camada mas vc poderia nomear com as classes por exemplo "consulta.html , consultaNegocio , Banco" isso depende da sua necessidade.

 

Explicação formal

Este diagrama procura determinar a sequência de eventos que ocorrem em um determinado processo, ou seja, quais condições devem ser satisfeitas e quais métodos devem ser disparados entre os objetos envolvidos e em que ordem durante um processo específico. Assim, determinar a ordem em que os eventos ocorrem, e as mensagens que são enviadas, os métodos que são chamados e como os objetos interagem entre si dentro de um determinado processo é o objetivo principal deste diagrama. Pensando de uma forma mais clara seu objetivo é entender a sequencia em que os métodos se comportam baseado em uma ação. Mas quem define essa ação?

O Diagrama de Sequência baseia-se no Diagrama de Casos de Uso. No entanto deve-se ter em mente que o fato de haver normalmente um único Diagrama de Casos de Uso não significa em absoluto que deva haver um único Diagrama de Sequencia. Normalmente existem diversos Diagramas de Sequência em um projeto, um para cada processo específico do sistema ou seja, talvez exista um uma parte, módulo, componente do sistema que tem apenas um caso de uso principal, um diagrama de caso de uso e ‘n’ de sequencia pois a tendencia é realmente o de atividade e o de sequência possuierem um pouco mais diagramas. Mas claro que isso não é regra e cada caso é um caso mas se você sempre estiver fazendo um diagrama de sequencia de um componente grande eu recomendo que vc pare, pense e veja quais ações estão faltando.

---

---

Um Diagrama de Sequência na maioria das vezes se identifica com um Caso de Uso específico, porque um Caso de Uso, em geral, refere-se a um processo disparado por um usário. Assim um Diagrama de Sequência também também permite documentar um Caso de Uso. Na verdade, muitas ferramentas CASE permitem gerar um Diagrama de Sequencia diretamente a partir de um Caso de Uso.

Nem sempre um Caso de Uso gera um Diagrama de Sequência, como é, muitas vezes, o que ocorre com os Casos de Uso do tipo <<include>>, porque este têm que ser executados juntamente com outros Casos de Uso que os utilizam e, por isso muitas vezes suas etapas são descritas nos diagramas de Sequência relativos aos Casos de Uso que os Utilizam. Porém nada impede que se defina um Diagrama de Sequência exclusivo para um Caso de Uso utilizado por outros Casos de Uso através da associação <<include>>.
Obviamente, o Diagrama de Sequência depende também do Diagrama de Classes,

Os atores são os mesmos descritos no Diagrama de Casos de Uso, ou seja entidades externas que geram ações e disparam eventos.

Os atores não são obrigatórios no diagrama de sequencia mas são utilizados frequentemente

Objetos representam as instâncias das classes envolvidas no processo ilustrado pelo Diagrama de Sequencia. Os objetos são apresentados como retângulos contendo um texto que identifica primeiramente o nome do objeto, em minúsculo, e depois o nome da classe, com as letras iniciais maiúsculas, a qual o objeto pertence. Essas duas informações são separadas por um simbolo de (:) dois pontos. Veja um exemplo de objeto:

 
Veja como exemplo nessa figura um exemplo de objeto onde Paulo é o nome do objeto seguido de Pessoa que é a classe pessoa, ou seja, Paulo é uma instância da classe Pessoa.

Abaixo do retangulo existe uma linhda pontilhada e ela representa o tempo de vida o objeto, olhando dessa maneira não existe uma forma de medir um tempo de vida real nele isso só será possível quando o diagrama completo estiver pronto.

A e tem outra coisa, não existe diagrama que veja o tempo em horas/minutos/segundos de um objeto não ta? Quando digo linha do tempo me refiro a linha da vida, ao tempo que ele vai estar vivo durante um processo.


Um objeto pode existir desde o início do processo ou ser criado durante o decorrer da execução do mesmo.

Mensagens
As ,mensagens são utilizadas no Diagrama de Sequencia para demonstrar a ocorrência de eventos, que normalmente forçam a chamada de um método em algum dos objetos envolvidos no processo. Veja um exemplo:



A mensagem investimento entra no controller JAVoiceController e ele executa seu método vote().


Veja um exemplo completo de um diagrama de sequência para aluguel de carro:



Bem, por hoje é só. Espero ter ajudado e se não acharam que ficou claro me avisem.
Obrigado!

Intranet e a redundância das terminologias na TI

Vou deixar um pouco o desenvolvimento, a engenharia, a analise e as dicas para falar sobre algo que a algum tempo vem “confundindo” a cabeça de muita gente, inclusive a minha. E quando eu me refiro muita gente estou falando de todas as pessoas que de um jeito ou de outro tem a tecnologia como fiel companheira. 

Você alguma vez já se deparou com algum termo da TI sendo utilizado para mais de um significado? Provavelmente sim, caso contrário vou refrescar sua memória. 

Me explique o que é “portabilidade” ?

Para a informática portabilidade refere-se à característica das aplicações serem executáveis (ou facilmente recompiladas) em outras plataformas além daquela de origem, ou seja, tornar algo multiplataforma de acesso geral, como um tablet acessar um aplicativo que tem outro sistema operacional. Entendeu? Legal não é? Mas portabilidade também é um processo ou grupo de processos que permitem que um cliente de um prestador de serviço transite para outro prestador mantendo o mesmo número de telefone. E ai gostou? E se isso cai em uma prova de concurso público o que você faz ? A verdade é, se você estudou desenvolvimento de software, se é um desenvolvedor, analista ou da área você se fode e erra, se você for de outra área você provavelmente vai acertar pois sua ligação com uma empresa de telefonia é muito maior do que com um livro do Kent Beck por exemplo. 

Esse é um exemplo verdadeiro, minha namorada é da área jurídica (aliás ela é a melhor), foi criada com a tecnologia a sua volta e ela sabe que portabilidade é o caso do telefone pois já fez em seu celular logo, ela acertaria fácil essa questão, não posso dizer o mesmo sobre mim.

O problema disso é que o verdadeiro domínio sobre tudo que engloba a TI é genérico. Não se sabe dividir as coisas. Nesse caso é simples, a primeira portabilidade que eu expliquei é portabilidade na informática, e a segunda é portabilidade em telefomunicações.

Mas isso é perigoso pois para que aqueles que formulam as provas por exemplo não existe critério ou estudo aprofundado para se fazer uma questão, cabe a você entender sobre o assunto real abordado e se muito genérico pense no mais simples e prático(se existir).

E as intranets? Outro termo perigoso.

Quando lançaram o microondas por exemplo, muita gente ficou desnorteada. O troço mais parecia uma televisão, mas cozinhava como um forno…. e sem fogo!

Detalhe: ele serve não só para esquentar uma fatia de pizza que dormiu na geladeira, mas também para descongelar alimentos e até para preparar um almoço completo. Mas você conhece alguém que utilize todas estas funcionalidades?

Com as intranets vem acontecendo coisa parecida. Elas podem fazer um banquete, mas muita gente usa mesmo para “fazer pipoca”. Para piorar, o termo “intranet” pode significar várias coisas, aumentando a confusão…

Novas ideias, antigos ideais
Sempre que não temos referenciais claras para algo novo, a tendência é enquadrá–lo nos paradigmas pré–existentes. Embora seja algo natural, comprovado pela psicologia e pelos estudos de comportamento do consumidor, representa uma ameaça à evolução. Portanto, conhecer toda a potencialidade do que quer que seja amplia nossas chances de compreensão, de aceitação e de progresso. 
Vamos começar tentando responder uma pergunta que volta e meia me fazem: o que é uma intranet, afinal? Um portal corporativo?
Ao invés de ficar detalhando funcionalidades – uma enrolação completa… – , o melhor caminho me parece ser justamente o comparativo, buscando os tais referenciais que todos nós temos dentro da cabeça, formando os modelos mentais. Melhor seria olhar para os benefícios do que para as características.


Intranet é diferente de internet?
Se você conversar com um cara de infraestrutura de TI, ele certamente te dirá que intranet é… uma rede fechada de computadores. Coloque dois ou mais pcs interligados entre si, mesmo sem qualquer programa de compartilhamento, e está formada uma intranet – do ponto de vista restrito da área de redes.
Se você perguntar para um cara de desenvolvimento de sistemas, ele certamente te dirá que intranet é... atualmente um portal na internet com acesso fechado para a empresa.
Normalmente, baseadas em uma estrutura web, com um site centralizando tudo, as intranets são usadas de forma pontual, para apoiar um projeto específico (com começo, meio e fim) ou como mera porta de acesso a sistemas desenvolvidos também pontualmente. Há algo de errado nisso? Claro que não – para cada necessidade, uma solução…


Faca, o pão e o sangue
Não seria nada demais afirmar que uma intranet não é, ela pode ser… Complicado? Nem tanto. Pense numa faca. O que ela é? Se usada para passar manteiga no pão, posso afirmar que é um utensílio doméstico. Se utilizada para apunhalar alguém, torna–se uma arma mortal. Bem diferente, não?
Intranets são assim: não raro, refletem o perfil da empresa, são uma espécie de simulacro da estrutura e da cultura corporativa. Como “cada um é cada um”, cada intranet é uma intranet, não existem duas iguais e muito menos receita de bolo para o sucesso.
Assim, empresas muito “caretas” (ou seja, ainda muito presas ao modelo industrial, onde prevalece o controle, a hierarquia e a departamentalização) usam a intranet para… controlar! Ou para esquentar a pizza, como queiram.


Outras, mais arejadas, já começam a incluir produtos, serviços e a caminhar em direção a um maior empowerment dos funcionários/colaboradores. Existem até algumas empresas que conheço que criaram redes sociais da empresa e sim, isso é uma intranet.


“E os portais corporativos?”, você deve estar se perguntando. “São a mesma coisa”, eu respondo de pronto. Algumas empresas adotam outros nomes para não se tornar algo chato e afastar os colaboradores, o governo por exemplo pode chamar algo de intranet e acoplar todos seus sistemas nele pois quero ver um polícial deixar de registrar um boletim de ocorrência porque não gosta da intranet rsrs...
Portanto, pensar em intranets e portais nos levará sempre a pensar também em administração de empresas, endomarketing, processos, comunicação interna, cultura organizacional, gestão do conhecimento e afins. É neste contexto que ela ganha destaque e deixa de ser “mais um sisteminha”. Queremos ver até onde os microondas podem ir, muito embora seja ótimo poder esquentar a pizza e fazer pipoca rapidinho…


Abordei dois exemplos sobre a redundância dos nomes que engloba a TI, mas ainda existem milhões como proxy por exemplo que na verdade é uma definição dos intermediários entre um usuario e seu servidor e as pessoas associam como “um programa que abre sites bloqueados” não que o proxy não faça isso afinal, ele é um intermediário e se em um intermediário não existir bloqueio é lógico que vc irá “furar” a segurança... existe ainda mais e mais palavras como  framework, biblioteca, plugin, módulo, componente, orientação(aaaaa estou ficando loucoooo) Parei! :) ... o importante é você saber sobre o assunto a que se trata esse nome e ai sim entender o seu significado.

UML - Diagrama de classes

Sem dúvida alguma o mais importante diagrama da UML, o seu objetivo principal é permitir a visualização das classes que comporão o sistema com seus respectivos métodos e atributos bem como em demonstrar como as classes do diagrama se relacionam, complementam e transmitem informações entre si.

O diagrama de classes serve como base para construir a maioria dos diagramas da UML pois ele é uma “visão” das estruturas das classes de forma simples.
Veja um exemplo da classe pessoa

E ai ? Entendeu? Sinceramente isso é intuitivo não acha? Para vc é que do contra vou explicar melhor; O nome “Pesso” é o nome da classe, os ‘Nome’ e ‘Sexo’ são os atributos da classe e o o ‘Falar(),Pensar()’ e etc são métodos, ou seja, funções dessa classe.
Ainda criamos a classe ‘Engenheiro’ que herda tudo que a classe Pessoa tem com um método a mais que é o ‘ganharDinheiro’ rsrs... tudo bem que se fosse a classe ‘Político brasileiro’ iriam existir mais método como ‘corrompimento’ e o valor recebido do ganharDinheiro seria um long double max plus alfa int mas não vamos entrar nesse mérito ok?

Persistência
O diagrama de classe foi interncionalmente projetado para ser uma evolução do MER (modelo entidade relacionamento) e pode ser utilizado para modelar a estrutura lógica das tabelas que comporão um banco de dados

Relacionamentos
As classes costumam possuir relacionamentos entre si, com o intuito de compartilhar informações e colaborarem afim de permitir a execução de seus processos.

Associações
Vínculo que ocorre entre duas classes, uma classe pode estar associada a si mesma, chamado de associação unária, ou uma mesma associação para várias classes que é chamada de ternária seu uso é muito raro e complexo.
A associação determina que uma instância de uma classe esteja de alguma forma ligadas a instâncias das outras classes envolvidas podendo haver troca de informações.

As associação são o mair próximo dos relacionamento utilizados no MER, ou seja, seu objetivo é definir como as classes estão unidas.





Veja um exemplo de associação;

Associação unária ou Reflexiva
Este tipo de associação ocorre quando existe um relacionamento de uma classe para consigo mesma. Um exemplo de associação unária pode ser observado abaixo;

Note que na classe acima temos o nome “Funcionário” com os atributos Codigo, Nome e Codigo do chefe. O chefe do funcionário também é, por sua vez, um funcionário da empresa e, portanto também se constitui em uma instância da classe Funcionário. Logo a associação chamada “Chefia” indica uma possível relação entre uma ou mais instâncias da classe Funcionário com outras instâncias da própria classe Funcionário, ou seja, esta associação determina que um funcionario pode ou não chefia outros funcionários.

Assim, é preciso existir uma associação da classe funcionário com ela mesma, o que força que a classe possua o atributo Codigo_Chefe para armazenar o código do funcionário que é responsável pela instância do funcionário em questão.

Percebam que existe outra informação na associação, além de seu próprio nome, representada pelo valor “0...*”, esta informação é conhecida como multiplicidade. A multiplicidade, ela é extremamente igual o conceito de cardinalidade no MER, pois procura determinar qual das classes envolvidas em uma associaçção fornece informações para as outras, além de permitir especificar o nível de dependência de uma classe para com as outras envolvidas na associação.

No classo da figura acuna a multiplicidade 0...* indica que um determinado funcionário pode chefiar nenhum (0) ou muitos (*) funcionários, ou seja, um funcipnário pode não chefiar ninguém ou pode chefiar um o mais funcionários. Pode-se perceber que só existe multiplicidade em uma das extremidades, po default, quando não existe multiplicidade explícita entende-se que a multiplicidade é “1...1” .

A tabela abaixo demonstra laguns dos diversos valores de multiplicidade que podem ser utilizados em uma associação :

Associação Binária
A mais utilizada ocorre quando são indentificados relacionamentos entre duas classes, veja um exemplo;

 

Simples n é? um Objeto da classe sócio pode possuir 0 ou vários dependentes.

O diagrama de classe ainda tem outros tipos de relação como Agregação e composição mas já que a idéia é explicar a UML de maneira mais rápida se eu continuar vou ficar até o mês que vem escrevendo. O importante é entender essa estrutura e depois(se achar interessante ir a fundo).

Obrigado e até a próxima.

UML - Diagrama de Caso de Uso

Agora chegou a hora de avaliar melhor, explicar a fundo e PRATICAR, afinal, só conseguimos aprender direito se treinarmos certo?

Hoje vamos falar a fundo sobre o Diagrama de Casos de Uso para alguns desenvolvedores, "engenheiros" e funções o caso de uso é tão genérico que fazer caso de uso é perda de tempo mas não é verdade o caso de uso apesar de genérico é uma "bússola" para entender o sistema.

O diagrama de Casos de Uso procura, por meio de uma linguagem simples, possibilitar a compreensão do comportamento externo do sistema por qualquer pessoa, tentando apresentar o sistema através de uma perspectiva do usuário. É, dentre todos os diagramas da UML o mais abstrato e, portanto o mais fléxivel e informal. Ele costuma ser utilizado principalmente no início da modelagem do sistema, principalmente nas etapas de levantamento e Análise de Requisitos, embora venha a ser consultado e possivelmente modificado durante todo o processo de engenharia e sirva de base para a modelagem de outros diagramas.
Por mais abstrato que seja ele é de grande ajuda para auxiliar o engenheiro de software a dar um ‘rumo’ ao sistema.

Veja o nosso pequeno exemplo que mostra um caso de uso da funcionalidade de administrar novidades de um sistema:


Este diagrama tem por objetivo apresentar uma visão externa geral das funções e serviços que o sistema deverá oferecer aos usuários, sem se preocupar com como essas funções serão implementadas. O Diagrama de Casos de Uso é de grande auxílio na etapa de Análise de Requisitos, ajudando a especificar, visualizar e documentar as características, funções e serviços do sistema desejados pelo usuário. O Diagrama de Casos de Uso tenta identificar os tipos de usuários que irão interagir com o sistema, quais papéis esses usuários irão assumir e quais funções serão requisitadas por cada usuário específico.

Por utilizar uma linguagem informal e apresentar uma visão geral do comportamento do sistema a ser desenvolvido, o Diagrama de Casos de Uso pode e deve ser apresentado durante as reuniões iniciais com os clientes como uma forma de ilustrar o comportamento do sistema, facilitar a compreensão dos usuários e auxiliar na identificação de possíveis falhas de especificação é recomendado que junto com o caso de uso o cliente tenha acesso a um protótipo para que assim um complemente o outro.

Atores
O Diagrama de Casos de Uso concentra-se em dois itens principais: Atores e Casos de Uso. Os atores representam os papéis desempenhados pelos diversos usuários que poderão utilizar de alguma maneira os serviços e funções do sistema; eventualmente um Ator pode representar algum hardware especial ou mesmo um outro software que interaja com o sistema. Resumindo tudo isso que falei um Ator pode ser qualquer elemento externo que interaja com o sistema.
Os atores são representado por símbolos de bonecos que eu sei desenhar, é eu sei desenhar apenas aqueles bonequinhos de pauzinho sabe? Então, esses são os atores, em alguns livros e artigos os chamam de “bonecos magros” mas da na mesma pois pra mim são uns alienígenas veto rizados, rsrs.

E os casos de uso que refere-se aos serviços, tarefas ou funções que podem ser utilizados de alguma maneira pelos usuários do sistema, como emitir um relatório, cadastrar a venda de um produto qualquer, administrar usuários, emitir boleto bancário e etc... Os casos de uso são utilizados para expressar e documentar os comportamentos pretendidos para as funções do sistema.
Não existe regra para definir ao que se refere exatamente um caso de uso por exemplo, posso fazer um caso de uso que represente uma tela do sistema, ou uma ação especifica do usuário ou ainda várias ações, o indicado é criar algo que fique claro as funções do sistema por exemplo, veja esse diagrama de caso de uso para um modulo de novidades

Um usuário com uma ação “administra novidades” e nessa função existem várias ações. Para reforçar melhor a idéia do caso de uso ele basicamente oferece instruções gerais de como será seu funcionamento, quais atividades deverão ser executadas, qual eventos forçará sua execução, quais Atores os poderão utilizar, quais suas possíveis restrições entre outras.



Documentação de Casos de Uso
A documentação de um Caso de Uso costuma descrever por meio de uma linguagem bastante simples, a função em linhas gerais do Caso de Uso, quais Atores interagem com o mesmo, quais etapas devem ser executadas pelo Ator e pelo sistema para que o Caso de Uso execute sua função, quais parâmetros devem ser fornecidos e quais restrições e validações o Caso de Uso deve possuir.

No entanto, não existe um formato específico de documentação para Casos de Uso definido pela UML, o que está de acordo com a característica do próprio diagrama, ou seja, o formato de documentação de um Caso de Uso é bastante flexível, permitindo que se documente o caso de Uso da forma que se considerar melhor, até mesmo através do uso de pseudo-código ou da utilização do código de alguma linguagem de programação propriamente dita, embora isto fuja bastante do objetivo principal do Diagrama de Casos de Uso, que é utilizar uma linguagem simples que até mesmo usuários leigos possam entendê-la.

Por esse motivo não é recomendado utilizar pseudo-código na documentação de Casos de Uso, isto é mais adequado em outros diagramas como o Diagrama de Atividades, por exemplo.

Vamos mostrar um breve exemplo de Documentação de Caso de Uso do administrar novidades OK? Apenas para inserir novidade.

Documentação do Caso de Uso Inserir novidade

Nome do Caso de Uso	Inserir novidade
Caso de Uso Geral	Administar novidades
Ator principal	Usuario
Resumo	Este caso de uso descreve as etapas percorridas por um usuario para inserir uma novidade
Pré-condições	Ser um usuario do sistema com permissão para utilizar esse modulo
Ações do Ator	Ações do sistema
1. Preencher campos
	2. Receber dados de novidade
	3. Validar campos
	4. tratar imagem
6. definir tempo de transição dos slides
	7. Verificar se tempo é valido e registrar
Restrições/Validações	1. A imagem inserida deve ter extensão jpg, gif ou png. 2. Titulo e descrição são obrigatórios 3.  Titulo deve ter no máximo 90 caracteres 4. Descrição deve ter no máximo 160 caracteres 5. Não permitir tags html

A documentação em si parece ser bem simples mas devemos prestar atenção na parte que mostra Caso de Uso Geral e colocamos como valor Administrar novidades, isso acontece pq esse caso de uso é o Insere novidades que fica abaixo do Administrar novidades (veja na imagem), esse é chamado de caso de uso especializado que herda as características do Caso de uso geral.

O campo ator principal identifica o ator que mais interage com o Caso de Uso ou que está mais interessado nos resultados produzidos pelo mesmo. Ainda existe o Ator secundário que são aqueles que interagem em um nível menor com o Caso de Uso ou que não tem tanto interesse em seus resultados.Existe também o Resumo que apresenta um breve resumo explicando seu objetivo. Em seguida são descritas as possíveis pré-condições para que o Caso de Uso seja executado ou concluído, existe tambem as pós-condições, ou seja, tarefas que devem ser realizar depois que as etapas do Caso de Uso tiverem sido concluídas. Na documentação deste Caso de Uso as ações tomadas pelo Ator Usuario aparecem no lado esquerdo e as do sistema no lado direito. Em seguida, a documentação apresenta as ações realizadas quando o serviço representado pelo Caso de Uso for solicitado. As ações são divididas em ações realizadas pelo Ator que interage com o sistema e em ações realizadas pelo próprio sistema, numeradas em ordem sequencial. Finalmente é apresentada uam lista de possíveis restrições e validações do Caso de Uso, com o objetivo de tornar o processo mais consistente.

Alguns autores sugerem ainda o acréscimo de FLuxos Alternativos ou Cenários Alternativos, como uma maneira de prever ações que devem ser realizadas quando da ocorrência de possíveis exceções. Nestes casos deve-se determinar o FLuxo ou Cenário Principal que será normalmente executado e cada um dos possíveis fluxos ou cenários alternativos, dependendo do número de exceções que possam vir a ocorrer no Caso de Uso em questão.


Associações
As associações representam as interações ou relacionamentos entre os Atores que fazem parte do diagrama, entre os Atores e os Casos de Uso ou os relacionamentos entre os Casos de Uso e outros Casos de Uso. Os relacionamentos entre casos de uso recebem nomes especiais, como Inclusão, Extensão e Generalização. Todos esses relacionamento serão examinados aqui.

A associação entre um Ator e um Caso de Uso é representada por uma reta ligando o Ator ao Caso de Uso, podendo ocorrer que as extremidades da reta contenham setas, indicando a navegabilidade de Associação, o que demonstra o sentido em que as informações trafegam, ou seja, se estas são fornecidas pelo Ator ao Caso de Uso, se são transmitidas pelo Caso de Uso ao Ator ou ambos (neste ultimo caso a reta não possue setas demonstrando que as informações são transmitidas nas duas direções). Além disso uma associação pode possuir uma descrição própria, quando há necessidade de esclarecer a natureza da informação que está sendo transmitida, ou para das um nome à Associação, se isto for considerado necessário.

A imagem abaixo representa uma Associação entre um Ator e um Caso de Uso;


Examinando essa associação percebemos que o Ator Cliente utiliza, de alguma forma, o serviço Abertura de Conta, representado pelo Caso de Uso e que a informação referente a este processo trafega nas duas direções.


Especialização/Generalização

O relacionamento de Especialização/Generalização é uma forma de Associação entre Casos de Uso no qual existem dois o mais Casos de Uso com características semelhantes, apresentando pequenas diferenças entre si. Quando isso acontece definimos um Caso de Uso Geral que descreve as características compartilhadas por todos os Casos de Uso em questão e então relacioná-lo com os outros casos de uso envolvidos.
A associação de Generalização/Especialização é representada por uma reta com uma seta mais grossa, que indica qual o Caso de Uso Feral (para o qual a seta aponta) e quais os Casos de Uso Especializados(os que estão na outra extremidade da seta) veja um exemplo abaixo;

Embora não seja comum a especialização pode ser aplicada a atores tambem e funciona da mesma forma.

Inclusão
A Associação de Inclusão costuma ser utilizada quando existe um serviço, situação ou torina comum a mais de um Caso de Uso. Quando isso acontece, a documentação dessa rotina é mcolocada em um Caso de Uso específico para que outros Casos de Uso utilizem-se desse serviço, evitando-se descrever uma mesma sequência de passos em vários Casos de Uso.  Uma inclusão em um caso de uso comporta-se da mesma forma que uma chamada de função na programação. Uma associação de inmclusão é representada por uma reta tracejada contendo uma seta em uma de suas extremidades que aponta para o Caso de Uso incluído no caso de uso posicionado na outra extremidade da reta. As associações de inclusão costumam apresentar também um EStereótopo contendo o texto “include”, entre dois sinais de menor (<) e dois de maior (>). Os Estereotipos serão melhor detalhados em breve. Veja um exemplo de inclusão abaixo;



Nessa imagem percebemos que feito qualquer ação (Saque ou depósito) é necessário registrar o movimento.

Extensão
Associação de Extensão são utilizadas para descrever cenários opcionais de um Caso de Uso. Os Casos de uso estendidos descrevem cenários que somente ocorrerão em uma situação específica, se uma determinada condição for satisfeita.
As associações de Extensão indicam a necessidade de um teste para determinar se é necessário executar também o Caso de Uso estendido ou não. Relacionamentos de Extensão representam eventos que não ocorrem sempre, o que não significa que eles sejam incomuns. As associações de Extensão possuem uma representação semelhante a de inclusão, utilizando também a reta tracejada diferenciando-se pelo fato da seta apontar para o Caso de Uso que utiliza o Caso de Uso estendido e por possuir um Estereótipo contendo o texto “extend” ao invés de “include” a imagem abaixo representa muito bem uma extensão:

O certo no banco é que quando vc va cancelar a conta fique com saldo igual a zero ou seja, não esteja nem devendo para o banco e também não tenha dinheiro, então para encerrar a conta é necessário se o saldo positivo sacar o dinheiro e se negativo “pagar” depositar dinheiro.

 

UFÁ! Pensei que seria menor o caso de uso mas finalmente terminamos essa parte.

Bem no próximo post vamos falar de diagrama de classes, até la!