Tópicos Avançados - Diagrama de Sequência - Parte III

Olá sejam bem-vindos ao canal engenharia de software com ênfase um ml Eu sou professor de Denis gedes e eu já atu na área de modernagem de software há vários anos eu tenho quatro livros publicados sobre o assunto e eu já ministrei diversos palestras e cursos técnicos sobre a modelagem de software com a linguagem UMF na aula de hoje eu pretendo dar continuidade ao tema sobre o diagrama de sequência enfocando tópicos avançados Então vamos dar início a nossa então como eu falei essa terceira aula sobre o diagrama de sequência na primeira aula eu introduzi alguns conceitos

básicos na segunda aula eu falei sobre fragmentos de interação e fragmentos combinados nessa aula eu vou abordar alguns tópicos mais avançados sobre esse diagrama ah antes de mais nada Eu sempre gosto de fazer uma pequena propaganda como eu falei eu já ministrei eu já publiquei eh quatro livros sobre o assunto o meu primeiro livro foi o m uma abordagem prática que na época tratava da .5 mas já abordaram o ml2 no final do livro O meu segundo livro foi o ml2 guia de consulta rápida que era exclusivo sobre a ml2 poucos anos depois eu transformei

esse guia no livro ml2 Guia prática e finalmente eu lancei o meu livro mais completo que foi o ml2 uma abordagem prática que se encontra na terceira Edição mas eu já Já estou trabalhando na quarta Edição Mas vamos ao conteúdo Então primeiramente vou falar sobre mensagens assíncronas nós já vimos mensagens síncronas nas outras aulas uma mensagem síncrona ela precisa esperar pelo retorno da mensagem já as mensagens síncronas não precisam aliás nas mensagens assíncronas não é necessário a lifeline não precisa eh esperar que a mensagem seja concluída para executar dar outras ações então Eh e outra

Além disso O a lifeline que recebe a mensagem assíncrona ela não precisa atender essa mensagem executar essa mensagem imediatamente bom Aqui nós temos o exemplo de mensagem assíncrona que essa seta hum com a com a flecha com a ponta não preenchida as mensagens síncronas são representadas por setas com a com a ponta preenchida então Aqui nós temos um processo que enfoca uma venda de produtos onde eu tenho quatro lifelines uma lifeline representando uma Instância do autor cliente uma lifeline representando uma Instância da classe de Fronteira visão vendas uma lifeline representando uma instância da classe controle

controladora a vendas e uma lifeline representando uma Instância da classe operadora cartão Lembrando que lifelines Como já foi visto em vídeos anteriores eh representam uma Instância que existe durante um processo ela pode ser criada ao longo do processo ou pode ser destruída durante esse processo bom mas esse processo se inicia com cliente confirmando a compra esse trecho do processo se inicia com o cliente confirmando a compra como representado por essa mensagem então essa mensagem recebida pela lifeline divisão vendas ela Repassa esse evento paraa controladora e a controladora em resposta solicita que a operadora do cartão

Execute o método autorizar autorizar pagamento porém essa é uma mensagem assíncrona a controladora pode fazer outras coisas enquanto essa mensagem ela é processada ela é recebida pela operadora do então bom vou falar sobre restrição de duração ah eventualmente pode ser necessário estabelecer detalhes de tempo para uma determinada mensagem Ah esses detalhes podem ser por exemplo o tempo máximo de espera até que a mensagem seja disparada então quando nós precisamos fazer esse tipo de coisa nós utilizamos restrições de duração Aqui nós temos um exemplo de restrição de duração aqui eu estou utilizando uma mensagem que ela

é uma mensagem que leva em consideração o tempo por isso ela não está representada na horizontal e sim na diagonal e ela tem uma restrição de duração se passarem mais de 60 segundos de espera então ela vai ser disparada Não antes quer dizer o tempo mínimo para que a mensagem seja seja disparada é que se passe em 60 segundos a partir daí vai ser disparado essa mensagem no caso vai ser disparado eh o método para cancelar o pedido porque o tempo para autorização de pagamento se esgotou então isso aqui é um exemplo de restrição de

duração e de uma mensagem que levea em consideração o tempo para ser disparado e a forma como ela é representada Diferentemente das ã mensag normais Além disso pode notar que essa é uma mensagem destrutora uma vez que ela eliminou essa lifeline da classe pedido como nós podemos perceber por esse X no final da linha de vida dessa lifeline bom nós temos também a observação de duração a observação de duração estabelece o tempo válido para que uma mensagem possa ser executada basicamente ela estabelece uma janela de tempo durante a qual a mensagem pode ser executada depois

de passado esse tempo ela não pode mais ser executada então aqui nós continuamos complementando o exemplo de autorização de compra onde nós temos uma observação de duração sobre o foco de controle da operadora de cartão então foi disparada uma mensagem assíncrona autorizar pagamento e essa mensagem assíncrona ela tem 60 segundos para ser respondida Ou seja a operadora do cartão tem 60 segundos para autorizar o pagamento então a a observação de duração é representado como uma restrição uma restrição representada entre colchetes aqui eu estou dizendo que o tempo para execução desse desse método é de menos

de 60 segundos e tem eh uma seta dupla sobre o foco de controle eh que surge após a solicitação do método de autorizar pagamento então isso aqui representa um tempo um tempo que precisa ser observado para que a mensagem possa ser disparada se ela for executada Se houver uma resposta em menos de 60 segundos então o fluxo continua normal o pagamento autorizado e a controladora pede para visão avisar ao cliente que a compra foi autorizada caso contrário vai ser disparada uma mensagem para cancelar o pedido uma vez que se passaram mais de 60 segundos de

espera bom ah existe também mensagens perdidas e mensagens encontradas uma mensagem perdida ela identifica uma mensagem que foi enviada mas não houve confirmação de recebimento então isso pode significar que a mensagem ela não chegou ao seu destino ou que o destino não está representado no diagrama e a mensagem encontrada ela identifica o recebimento de uma mensagem enviada por um elemento que não é conhecido ou que não faz parte do diagrama ã também eventualmente ela pode representar o recebimento de uma mensagem que foi dada anteriormente como perdido então Aqui nós temos o exemplo de mensagens perdidas

e mensagens encontradas eu tenho uma lifeline da classe transmissora e uma lifeline da classe receptora Aqui nós temos um exemplo de mensagem perdida eh o transmissor ele envia uma mensagem e essa mensagem atinge um círculo ã Preto um círculo preenchido não atinge o receptor Isso significa que a mensagem foi perdida e Aqui nós temos uma mensagem encontrada uma mensagem parte de um no círculo preto e atinge a linha de vida da lifeline transmissor is significa que essa é uma mensagem encontrada então uma mensagem que foi julgada perdida que talvez não tivesse sido recebido talvez tenha

sido recebida então H apesar de demorar um tempo maior do que esperado há uma mensagem de resposta então isso aqui são exemplos de mensagens perdidas e mensagens encontradas ainda vou falar sobre corregi a corre região é uma alternativa para a representação de paralelismo nós apresentamos exemplos de paralelismo no V no vídeo anterior no no momento em que nós explicamos fragmentos combinados do tipo par mas nós também podemos representar paralelismo por meio de cor regiões embora na minha opinião ah seja uma forma mais pobre de representar paralelismo basicamente uma corregi especifica uma situação em que está

ocorrendo paralelismo e a ordem de execução das mensagens não é determinada ou não é importante então Aqui nós temos o mesmo exemplo ou ainda um exemplo semelhante ao que nós utilizamos no vídeo anterior para representar paralelismo só que antes nós utilizávamos fragmentos combinados do tipo par aqui nós estamos utilizando uma corregi uma corregi é identificada por esses colchetes horizontais certo então aqui nós estamos identificando a corregi que ocorre sobre o controle de sobre a a lifeline controle de pesquisa então aqui eu tenho uma lifeline da da do ator usuário uma lifeline de uma classe bounder

chamada visão pesquisa uma lifeline de uma classe de controle chamada controle pesquisa e duas lifelines de classe de entidade chamada chamadas informação e oferta então isso representa uma situação de pesquisa por meio de navegador web onde o usuário solicita a uma pesquisa sua informação e a controladora em resposta ela ao mesmo tempo que pesquisa as informações solicitadas ela também pesquisa por ofertas associadas ao tema e ela vai retornar tanto a às informações retornadas como as ofertas descobertas então como isso ocorre em paralelo nós podemos representar isso por meio de uma corre região lembrando Voltando a

falar Eu considero o uso de fragmentos cados do tipo par mais úteis do que utilizar cor regiões mas a corregi é uma alternativa talvez em situações em que o espaço é importante o fragmento combinado utiliza ocupa mais espaço talvez em situações mais simples possa utilizar cor regiões ao invés de fragmentos combinados existe essa alternativa e nós temos as iterações as iterações elas representam uma situação em que uma menagem pode ser executada pode ser enviada muitas vezes então elas são semelhantes a laços ah laços também podem ser representados por meio de fragmentos combinados do tipo loop

Como já foi ensinado no vídeo anterior mas existe a opção de iterações as interações elas são representadas por um asterisco que é colocado na frente da mensagem e na maioria das vezes elas são apoiadas por condições de guarda condições de guarda como também já foi ensinado anteriormente é um texto entre colchetes que estabelece uma condição Nessa situação a condição para que a interação ocorra então aqui de novo nós tomamos um exemplo semelhante a já explicado ah na aula anterior para representar laços por meio de fragmentos combinados tipo loop dessa vez utilizando iterações então nós temos

um processo em que pode ser feita uma atualização de um determinado conjunto de produtos então nós temos uma lifeline da do ator funcionário uma lifeline de uma classe de Fronteira chamada visão autorização produtos representa essencialmente a interface entre o funcionário e o resto do sistema uma lifeline de uma classe de controle chamado controle autorização produtos e uma live de uma classe de entidade chamada produto eu sei que os tipos de de de classe por meio dos estereótipos aplicados a cada lifeline Este é um estereótipo de Fronteira ou boundary Este é o estereótipo de controle ou

control e este é o estereótipo de entidade ou entity Lembrando que um estereótipo de Fronteira representa classes que intermediam as interações dos atores com o resto do sistema ah classes do tipo control são classes que interpretam os eventos que ocorrem sobre a visão e se achar necessário solicit a execução de métodos por classe de entidade entre outras funções e classe entidade são classes que estão H ligadas diretamente ao domínio do problema contém a lógica do negócio vão ter muitos objetos e eles provavelmente serão persistentes Então nesse processo o funcionário ele informa percentual de aumento esse

evento é representado por uma mensagem que é recebida pela lifeline divisão ela Repassa o percentual de aumento para a controladora a controladora então inicia um laço ela vai disparar o m atualizar valor do produto para cada produto e Aqui nós temos um asterisco significa então que essa situação vai se repetir muitas vezes enquanto houverem produtos a serem a terem seu valor atualizado como demonstra a condição de guarda que é esse texto entre colches nós temos também o conceito de portas Como já foi visto nos vídeos sobre diagramas de classes uma porta ela é um ponto

de comunicação entre os elementos internos de uma classe e o ambiente externo então Aqui nós temos um exemplo de de portas utilizando classes eh a classe teclado placa mãe e monitor Então essas portas são esses quadradinhos que representam os pontos de interface entre a placa mãe e a e a classe teclado ou a classe monitor bom então eu posso representar portas também por meio de lifelines dessa forma vai existir uma linha de vida para cada porta Aqui nós temos o exemplo de lifelines para as portas de cada uma daquelas classes onde eu tenho uma lifeline

representando a porta da classe teclado duas lifelines Para representar as portas da placa mãe e uma lifeline para representar a porta da da da classe monitor além de lifelines para as próprias classes para as instâncias das próprias ele disparam uma mensagem contendo fluxo teclado em uma porta a porta Repassa para a Instância da classe placa mãe e a placa mãe resposta solicita a para sua porta de comunicação com a com a classe monitor que dispara uma mensagem solicitando que a placa ã que é o monitor Apresente o o resultado do do processamento feito pela placa

mãe e nós temos também a invariante de estado que ela representa uma restrição que é aplicada aos participantes da interação ela estabelece uma condição para que o comportamento seja ah executado e essa condição ela precisa ser avaliada em tempo de execução então Aqui nós temos um exemplo de parentese estado onde eu tenho um processo de gerar pedito onde eu tenho uma lifeline da classe de uma classe controladora e uma lifeline de uma classe de entidade chamada produto eu tenho fragmento combinado tipo loop que estabelece que de acordo com a condição de guarda para cada produto

deve-se consultar a sua quantidade se dispara aqui o método consultar a quantidade e aqui eu tenho fragmento combinado tipo opt que representa uma opção né onde através de uma condição de guarda se estabelece que se a quantidade estiver abaixo do mínimo então deve-se gerar um novo pedido e se é a quantidade abaixo do mínimo é representado por uma invariante de Estado então se a quantidade de produto for menor que 10 Então esse Ah deve se gerar um pedido para aquele produto aqui eu tenho um fragmento combinado tipo opt estabelece que se for o primeiro item

do pedido então vai se gerar um novo pedido aqui uma mensagem Construtora Caso contrário vai se vai se adicionar o item ao pedido vai se registrar um item novo para aquele para aquele pedido um pedido pode tem muitos itens isso aqui também é uma uma uma classe Construtora Então sempre que um produto estiver abaixo do do mínimo vai se gerar um item pedido se for o primeiro item vai se gerar um uma lifeline da classe pedido também e é isso nós terminamos esse tópico eu espero que vocês tenham gostado da aula se a aula foi

for útil eu eh peço que vocês curtem compartilhem eh esse conteúdo se inscreva no canal e nós nos vemos na próxima aula obrigado pela atenção